Re: [Intel-gfx] [patch 27/30] xen/events: Only force affinity mask for percpu interrupts
On 11/12/2020 21:27, Thomas Gleixner wrote: > On Fri, Dec 11 2020 at 09:29, boris ostrovsky wrote: > >> On 12/11/20 7:37 AM, Thomas Gleixner wrote: >>> On Fri, Dec 11 2020 at 13:10, Jürgen Groß wrote: On 11.12.20 00:20, boris.ostrov...@oracle.com wrote: > On 12/10/20 2:26 PM, Thomas Gleixner wrote: >> Change the implementation so that the channel is bound to CPU0 at the XEN >> level and leave the affinity mask alone. At startup of the interrupt >> affinity will be assigned out of the affinity mask and the XEN binding >> will >> be updated. > If that's the case then I wonder whether we need this call at all and > instead bind at startup time. After some discussion with Thomas on IRC and xen-devel archaeology the result is: this will be needed especially for systems running on a single vcpu (e.g. small guests), as the .irq_set_affinity() callback won't be called in this case when starting the irq. >> On UP are we not then going to end up with an empty affinity mask? Or >> are we guaranteed to have it set to 1 by interrupt generic code? > An UP kernel does not ever look on the affinity mask. The > chip::irq_set_affinity() callback is not invoked so the mask is > irrelevant. > > A SMP kernel on a UP machine sets CPU0 in the mask so all is good. > >> This is actually why I brought this up in the first place --- a >> potential mismatch between the affinity mask and Xen-specific data >> (e.g. info->cpu and then protocol-specific data in event channel >> code). Even if they are re-synchronized later, at startup time (for >> SMP). > Which is not a problem either. The affinity mask is only relevant for > setting the affinity, but it's not relevant for delivery and never can > be. > >> I don't see anything that would cause a problem right now but I worry >> that this inconsistency may come up at some point. > As long as the affinity mask becomes not part of the event channel magic > this should never matter. > > Look at it from hardware: > > interrupt is affine to CPU0 > > CPU0 runs: > > set_affinity(CPU0 -> CPU1) > local_irq_disable() > > --> interrupt is raised in hardware and pending on CPU0 > > irq hardware is reconfigured to be affine to CPU1 > > local_irq_enable() > > --> interrupt is handled on CPU0 > > the next interrupt will be raised on CPU1 > > So info->cpu which is registered via the hypercall binds the 'hardware > delivery' and whenever the new affinity is written it is rebound to some > other CPU and the next interrupt is then raised on this other CPU. > > It's not any different from the hardware example at least not as far as > I understood the code. Xen's event channels do have a couple of quirks. Binding an event channel always results in one spurious event being delivered. This is to cover notifications which can get lost during the bidirectional setup, or re-setups in certain configurations. Binding an interdomain or pirq event channel always defaults to vCPU0. There is no way to atomically set the affinity while binding. I believe the API predates SMP guest support in Xen, and noone has fixed it up since. As a consequence, the guest will observe the event raised on vCPU0 as part of setting up the event, even if it attempts to set a different affinity immediately afterwards. A little bit of care needs to be taken when binding an event channel on vCPUs other than 0, to ensure that the callback is safe with respect to any remaining state needing initialisation. Beyond this, there is nothing magic I'm aware of. We have seen soft lockups before in certain scenarios, simply due to the quantity of events hitting vCPU0 before irqbalance gets around to spreading the load. This is why there is an attempt to round-robin the userspace event channel affinities by default, but I still don't see why this would need custom affinity logic itself. Thanks, ~Andrew ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [patch 15/30] pinctrl: nomadik: Use irq_has_action()
On Thu, Dec 10, 2020 at 8:42 PM Thomas Gleixner wrote: > Let the core code do the fiddling with irq_desc. > > Signed-off-by: Thomas Gleixner > Cc: Linus Walleij > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-g...@vger.kernel.org Reviewed-by: Linus Walleij I suppose you will funnel this directly to Torvalds, else tell me and I'll apply it to my tree. Yours, Linus Walleij ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [patch 27/30] xen/events: Only force affinity mask for percpu interrupts
Andrew, On Fri, Dec 11 2020 at 22:21, Andrew Cooper wrote: > On 11/12/2020 21:27, Thomas Gleixner wrote: >> It's not any different from the hardware example at least not as far as >> I understood the code. > > Xen's event channels do have a couple of quirks. Why am I not surprised? > Binding an event channel always results in one spurious event being > delivered. This is to cover notifications which can get lost during the > bidirectional setup, or re-setups in certain configurations. > > Binding an interdomain or pirq event channel always defaults to vCPU0. > There is no way to atomically set the affinity while binding. I believe > the API predates SMP guest support in Xen, and noone has fixed it up > since. That's fine. I'm not changing that. What I'm changing is the unwanted and unnecessary overwriting of the actual affinity mask. We have a similar issue on real hardware where we can only target _one_ CPU and not all CPUs in the affinity mask. So we still can preserve the (user) requested mask and just affine it to one CPU which is reflected in the effective affinity mask. This the right thing to do for two reasons: 1) It allows proper interrupt distribution 2) It does not break (user) requested affinity when the effective target CPU goes offline and the affinity mask still contains online CPUs. If you overwrite it you lost track of the requested broader mask. > As a consequence, the guest will observe the event raised on vCPU0 as > part of setting up the event, even if it attempts to set a different > affinity immediately afterwards. A little bit of care needs to be taken > when binding an event channel on vCPUs other than 0, to ensure that the > callback is safe with respect to any remaining state needing > initialisation. That's preserved for all non percpu interrupts. The percpu variant of VIRQ and IPIs did binding to vCPU != 0 already before this change. > Beyond this, there is nothing magic I'm aware of. > > We have seen soft lockups before in certain scenarios, simply due to the > quantity of events hitting vCPU0 before irqbalance gets around to > spreading the load. This is why there is an attempt to round-robin the > userspace event channel affinities by default, but I still don't see why > this would need custom affinity logic itself. Just the previous attempt makes no sense for the reasons I outlined in the changelog. So now with this new spreading mechanics you get the distribution for all cases: 1) Post setup using and respecting the default affinity mask which can be set as a kernel commandline parameter. 2) Runtime (user) requested affinity change with a mask which contains more than one vCPU. The previous logic always chose the first one in the mask. So assume userspace affines 4 irqs to a CPU 0-3 and 4 irqs to CPU 4-7 then 4 irqs end up on CPU0 and 4 on CPU4 The new algorithm which is similar to what we have on x86 (minus the vector space limitation) picks the CPU which has the least number of channels affine to it at that moment. If e.g. all 8 CPUs have the same number of vectors before that change then in the example above the first 4 are spread to CPU0-3 and the second 4 to CPU4-7 Thanks, tglx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [patch 27/30] xen/events: Only force affinity mask for percpu interrupts
On 12/11/20 7:37 AM, Thomas Gleixner wrote: > On Fri, Dec 11 2020 at 13:10, Jürgen Groß wrote: >> On 11.12.20 00:20, boris.ostrov...@oracle.com wrote: >>> On 12/10/20 2:26 PM, Thomas Gleixner wrote: All event channel setups bind the interrupt on CPU0 or the target CPU for percpu interrupts and overwrite the affinity mask with the corresponding cpumask. That does not make sense. The XEN implementation of irqchip::irq_set_affinity() already picks a single target CPU out of the affinity mask and the actual target is stored in the effective CPU mask, so destroying the user chosen affinity mask which might contain more than one CPU is wrong. Change the implementation so that the channel is bound to CPU0 at the XEN level and leave the affinity mask alone. At startup of the interrupt affinity will be assigned out of the affinity mask and the XEN binding will be updated. >>> >>> If that's the case then I wonder whether we need this call at all and >>> instead bind at startup time. >> After some discussion with Thomas on IRC and xen-devel archaeology the >> result is: this will be needed especially for systems running on a >> single vcpu (e.g. small guests), as the .irq_set_affinity() callback >> won't be called in this case when starting the irq. On UP are we not then going to end up with an empty affinity mask? Or are we guaranteed to have it set to 1 by interrupt generic code? This is actually why I brought this up in the first place --- a potential mismatch between the affinity mask and Xen-specific data (e.g. info->cpu and then protocol-specific data in event channel code). Even if they are re-synchronized later, at startup time (for SMP). I don't see anything that would cause a problem right now but I worry that this inconsistency may come up at some point. -boris > That's right, but not limited to ARM. The same problem exists on x86 UP. > So yes, the call makes sense, but the changelog is not really useful. > Let me add a comment to this. > > Thanks, > > tglx > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] dma-buf: begin/end_cpu might lock the dma_resv lock
Hi Daniel,
I love your patch! Yet something to improve:
[auto build test ERROR on next-20201211]
[also build test ERROR on v5.10-rc7]
[cannot apply to tegra-drm/drm/tegra/for-next linus/master v5.10-rc7 v5.10-rc6
v5.10-rc5]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Daniel-Vetter/dma-buf-Remove-kmap-kerneldoc-vestiges/20201212-40
base:3cc2bd440f2171f093b3a8480a4b54d8c270ed38
config: powerpc64-randconfig-r035-20201210 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
5ff35356f1af2bb92785b38c657463924d9ec386)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install powerpc64 cross compiling tool for clang build
# apt-get install binutils-powerpc64-linux-gnu
#
https://github.com/0day-ci/linux/commit/24d4fcf0e09c80974556c7639cb630f86a544378
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Daniel-Vetter/dma-buf-Remove-kmap-kerneldoc-vestiges/20201212-40
git checkout 24d4fcf0e09c80974556c7639cb630f86a544378
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross
ARCH=powerpc64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
>> drivers/dma-buf/dma-buf.c:1121:14: error: use of undeclared identifier
>> 'dma_buf'
might_lock(&dma_buf->resv.lock);
^
>> drivers/dma-buf/dma-buf.c:1121:14: error: use of undeclared identifier
>> 'dma_buf'
>> drivers/dma-buf/dma-buf.c:1121:14: error: use of undeclared identifier
>> 'dma_buf'
drivers/dma-buf/dma-buf.c:1156:14: error: use of undeclared identifier
'dma_buf'
might_lock(&dma_buf->resv.lock);
^
drivers/dma-buf/dma-buf.c:1156:14: error: use of undeclared identifier
'dma_buf'
drivers/dma-buf/dma-buf.c:1156:14: error: use of undeclared identifier
'dma_buf'
6 errors generated.
vim +/dma_buf +1121 drivers/dma-buf/dma-buf.c
1093
1094 /**
1095 * dma_buf_begin_cpu_access - Must be called before accessing a dma_buf
from the
1096 * cpu in the kernel context. Calls begin_cpu_access to allow
exporter-specific
1097 * preparations. Coherency is only guaranteed in the specified range
for the
1098 * specified access direction.
1099 * @dmabuf: [in]buffer to prepare cpu access for.
1100 * @direction: [in]length of range for cpu access.
1101 *
1102 * After the cpu access is complete the caller should call
1103 * dma_buf_end_cpu_access(). Only when cpu access is braketed by both
calls is
1104 * it guaranteed to be coherent with other DMA access.
1105 *
1106 * This function will also wait for any DMA transactions tracked through
1107 * implicit synchronization in &dma_buf.resv. For DMA transactions with
explicit
1108 * synchronization this function will only ensure cache coherency,
callers must
1109 * ensure synchronization with such DMA transactions on their own.
1110 *
* Can return negative error values, returns 0 on success.
1112 */
1113 int dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
1114 enum dma_data_direction direction)
1115 {
1116 int ret = 0;
1117
1118 if (WARN_ON(!dmabuf))
1119 return -EINVAL;
1120
> 1121 might_lock(&dma_buf->resv.lock);
1122
1123 if (dmabuf->ops->begin_cpu_access)
1124 ret = dmabuf->ops->begin_cpu_access(dmabuf, direction);
1125
1126 /* Ensure that all fences are waited upon - but we first allow
1127 * the native handler the chance to do so more efficiently if it
1128 * chooses. A double invocation here will be reasonably cheap
no-op.
1129 */
1130 if (ret == 0)
1131 ret = __dma_buf_begin_cpu_access(dmabuf, direction);
1132
1133 return ret;
1134 }
1135 EXPORT_SYMBOL_GPL(dma_buf_begin_cpu_access);
1136
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/11] drm/i915: migrate skl planes code new file
Hi Dave, I love your patch! Perhaps something to improve: [auto build test WARNING on drm-intel/for-linux-next] [also build test WARNING on drm-tip/drm-tip next-20201211] [cannot apply to v5.10-rc7] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Dave-Airlie/drm-i915-display-move-needs_modeset-to-an-inline-in-header/20201211-163119 base: git://anongit.freedesktop.org/drm-intel for-linux-next config: x86_64-randconfig-s022-20201210 (attached as .config) compiler: gcc-9 (Debian 9.3.0-15) 9.3.0 reproduce: # apt-get install sparse # sparse version: v0.6.3-179-ga00755aa-dirty # https://github.com/0day-ci/linux/commit/a5c9dca8844730c679e9716efd016bfe04f9d002 git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Dave-Airlie/drm-i915-display-move-needs_modeset-to-an-inline-in-header/20201211-163119 git checkout a5c9dca8844730c679e9716efd016bfe04f9d002 # save the attached .config to linux build tree make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=x86_64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot "sparse warnings: (new ones prefixed by >>)" >> drivers/gpu/drm/i915/display/intel_gen9_plane.c:1396:5: sparse: sparse: >> symbol 'skl_plane_ctl_crtc' was not declared. Should it be static? >> drivers/gpu/drm/i915/display/intel_gen9_plane.c:1416:5: sparse: sparse: >> symbol 'skl_plane_ctl' was not declared. Should it be static? >> drivers/gpu/drm/i915/display/intel_gen9_plane.c:1455:5: sparse: sparse: >> symbol 'glk_plane_color_ctl_crtc' was not declared. Should it be static? >> drivers/gpu/drm/i915/display/intel_gen9_plane.c:1472:5: sparse: sparse: >> symbol 'glk_plane_color_ctl' was not declared. Should it be static? Please review and possibly fold the followup patch. --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC PATCH] drm/i915: skl_plane_ctl_crtc() can be static
Reported-by: kernel test robot
Signed-off-by: kernel test robot
---
intel_gen9_plane.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_gen9_plane.c
b/drivers/gpu/drm/i915/display/intel_gen9_plane.c
index d547edabb5ce7..8549b262f095e 100644
--- a/drivers/gpu/drm/i915/display/intel_gen9_plane.c
+++ b/drivers/gpu/drm/i915/display/intel_gen9_plane.c
@@ -1393,7 +1393,7 @@ static u32 cnl_plane_ctl_flip(unsigned int reflect)
return 0;
}
-u32 skl_plane_ctl_crtc(const struct intel_crtc_state *crtc_state)
+static u32 skl_plane_ctl_crtc(const struct intel_crtc_state *crtc_state)
{
struct drm_i915_private *dev_priv = to_i915(crtc_state->uapi.crtc->dev);
u32 plane_ctl = 0;
@@ -1413,8 +1413,8 @@ u32 skl_plane_ctl_crtc(const struct intel_crtc_state
*crtc_state)
return plane_ctl;
}
-u32 skl_plane_ctl(const struct intel_crtc_state *crtc_state,
- const struct intel_plane_state *plane_state)
+static u32 skl_plane_ctl(const struct intel_crtc_state *crtc_state,
+const struct intel_plane_state *plane_state)
{
struct drm_i915_private *dev_priv =
to_i915(plane_state->uapi.plane->dev);
@@ -1452,7 +1452,7 @@ u32 skl_plane_ctl(const struct intel_crtc_state
*crtc_state,
return plane_ctl;
}
-u32 glk_plane_color_ctl_crtc(const struct intel_crtc_state *crtc_state)
+static u32 glk_plane_color_ctl_crtc(const struct intel_crtc_state *crtc_state)
{
struct drm_i915_private *dev_priv = to_i915(crtc_state->uapi.crtc->dev);
u32 plane_color_ctl = 0;
@@ -1469,8 +1469,8 @@ u32 glk_plane_color_ctl_crtc(const struct
intel_crtc_state *crtc_state)
return plane_color_ctl;
}
-u32 glk_plane_color_ctl(const struct intel_crtc_state *crtc_state,
- const struct intel_plane_state *plane_state)
+static u32 glk_plane_color_ctl(const struct intel_crtc_state *crtc_state,
+ const struct intel_plane_state *plane_state)
{
struct drm_i915_private *dev_priv =
to_i915(plane_state->uapi.plane->dev);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [patch 03/30] genirq: Move irq_set_lockdep_class() to core
On Fri, Dec 11 2020 at 22:08, Thomas Gleixner wrote:
> On Fri, Dec 11 2020 at 19:53, Andy Shevchenko wrote:
>
>> On Thu, Dec 10, 2020 at 10:14 PM Thomas Gleixner wrote:
>>>
>>> irq_set_lockdep_class() is used from modules and requires irq_to_desc() to
>>> be exported. Move it into the core code which lifts another requirement for
>>> the export.
>>
>> ...
>>
>>> + if (IS_ENABLED(CONFIG_LOCKDEP))
>>> + __irq_set_lockdep_class(irq, lock_class, request_class);
>
> You are right. Let me fix that.
No. I have to correct myself. You're wrong.
The inline is evaluated in the compilation units which include that
header and because the function declaration is unconditional it is
happy.
Now the optimizer stage makes the whole thing a NOOP if CONFIG_LOCKDEP=n
and thereby drops the reference to the function which makes it not
required for linking.
So in the file where the function is implemented:
#ifdef CONFIG_LOCKDEP
void __irq_set_lockdep_class()
{
}
#endif
The whole block is either discarded because CONFIG_LOCKDEP is not
defined or compile if it is defined which makes it available for the
linker.
And in the latter case the optimizer keeps the call in the inline (it
optimizes the condition away because it's always true).
So in both cases the compiler and the linker are happy and everything
works as expected.
It would fail if the header file had the following:
#ifdef CONFIG_LOCKDEP
void __irq_set_lockdep_class();
#endif
Because then it would complain about the missing function prototype when
it evaluates the inline.
Thanks,
tglx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [patch 14/30] drm/i915/pmu: Replace open coded kstat_irqs() copy
From: Thomas Gleixner > Sent: 11 December 2020 21:11 > > On Fri, Dec 11 2020 at 14:19, David Laight wrote: > > From: Thomas Gleixner > >> You can't catch that. If this really becomes an issue you need a > >> sequence counter around it. > > > > Or just two copies of the high word. > > Provided the accesses are sequenced: > > writer: > > load high:low > > add small_value,high:low > > store high > > store low > > store high_copy > > reader: > > load high_copy > > load low > > load high > > if (high != high_copy) > > low = 0; > > And low = 0 is solving what? You need to loop back and retry until it's > consistent and then it's nothing else than an open coded sequence count. If it is a counter or timestamp then the high:0 value happened some time between when you started trying to read the value and when you finished trying to read it. As such it is a perfectly reasonable return value. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/11] drm/i915: migrate skl planes code new file
Hi Dave,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on drm-tip/drm-tip next-20201211]
[cannot apply to v5.10-rc7]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Dave-Airlie/drm-i915-display-move-needs_modeset-to-an-inline-in-header/20201211-163119
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-randconfig-s002-20201209 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.3-179-ga00755aa-dirty
#
https://github.com/0day-ci/linux/commit/a5c9dca8844730c679e9716efd016bfe04f9d002
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Dave-Airlie/drm-i915-display-move-needs_modeset-to-an-inline-in-header/20201211-163119
git checkout a5c9dca8844730c679e9716efd016bfe04f9d002
# save the attached .config to linux build tree
make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=i386
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
>> drivers/gpu/drm/i915/display/intel_gen9_plane.c:1396:5: error: no previous
>> prototype for 'skl_plane_ctl_crtc' [-Werror=missing-prototypes]
1396 | u32 skl_plane_ctl_crtc(const struct intel_crtc_state *crtc_state)
| ^~
>> drivers/gpu/drm/i915/display/intel_gen9_plane.c:1416:5: error: no previous
>> prototype for 'skl_plane_ctl' [-Werror=missing-prototypes]
1416 | u32 skl_plane_ctl(const struct intel_crtc_state *crtc_state,
| ^
>> drivers/gpu/drm/i915/display/intel_gen9_plane.c:1455:5: error: no previous
>> prototype for 'glk_plane_color_ctl_crtc' [-Werror=missing-prototypes]
1455 | u32 glk_plane_color_ctl_crtc(const struct intel_crtc_state
*crtc_state)
| ^~~~
>> drivers/gpu/drm/i915/display/intel_gen9_plane.c:1472:5: error: no previous
>> prototype for 'glk_plane_color_ctl' [-Werror=missing-prototypes]
1472 | u32 glk_plane_color_ctl(const struct intel_crtc_state *crtc_state,
| ^~~
cc1: all warnings being treated as errors
vim +/skl_plane_ctl_crtc +1396 drivers/gpu/drm/i915/display/intel_gen9_plane.c
1395
> 1396 u32 skl_plane_ctl_crtc(const struct intel_crtc_state *crtc_state)
1397 {
1398 struct drm_i915_private *dev_priv =
to_i915(crtc_state->uapi.crtc->dev);
1399 u32 plane_ctl = 0;
1400
1401 if (crtc_state->uapi.async_flip)
1402 plane_ctl |= PLANE_CTL_ASYNC_FLIP;
1403
1404 if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
1405 return plane_ctl;
1406
1407 if (crtc_state->gamma_enable)
1408 plane_ctl |= PLANE_CTL_PIPE_GAMMA_ENABLE;
1409
1410 if (crtc_state->csc_enable)
1411 plane_ctl |= PLANE_CTL_PIPE_CSC_ENABLE;
1412
1413 return plane_ctl;
1414 }
1415
> 1416 u32 skl_plane_ctl(const struct intel_crtc_state *crtc_state,
1417const struct intel_plane_state *plane_state)
1418 {
1419 struct drm_i915_private *dev_priv =
1420 to_i915(plane_state->uapi.plane->dev);
1421 const struct drm_framebuffer *fb = plane_state->hw.fb;
1422 unsigned int rotation = plane_state->hw.rotation;
1423 const struct drm_intel_sprite_colorkey *key =
&plane_state->ckey;
1424 u32 plane_ctl;
1425
1426 plane_ctl = PLANE_CTL_ENABLE;
1427
1428 if (INTEL_GEN(dev_priv) < 10 && !IS_GEMINILAKE(dev_priv)) {
1429 plane_ctl |= skl_plane_ctl_alpha(plane_state);
1430 plane_ctl |= PLANE_CTL_PLANE_GAMMA_DISABLE;
1431
1432 if (plane_state->hw.color_encoding ==
DRM_COLOR_YCBCR_BT709)
1433 plane_ctl |=
PLANE_CTL_YUV_TO_RGB_CSC_FORMAT_BT709;
1434
1435 if (plane_state->hw.color_range ==
DRM_COLOR_YCBCR_FULL_RANGE)
1436 plane_ctl |=
PLANE_CTL_YUV_RANGE_CORRECTION_DISABLE;
1437 }
1438
1439 plane_ctl |= skl_plane_ctl_format(fb->format->format);
1440 plane_ctl |= skl_plane_ctl_tiling(fb->modifier);
1441 plane_ctl |= skl_plane_ctl_rotate(rotation &
DRM_MODE_ROTATE_MASK);
1442
1443 if (INTEL_GEN(dev_priv) >= 10)
1444 plan
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v5,1/2] drm/i915/display: Support PSR Multiple Transcoders
== Series Details == Series: series starting with [v5,1/2] drm/i915/display: Support PSR Multiple Transcoders URL : https://patchwork.freedesktop.org/series/84853/ State : success == Summary == CI Bug Log - changes from CI_DRM_9477_full -> Patchwork_19127_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_19127_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@preservation-s3@rcs0: - shard-kbl: [PASS][1] -> [DMESG-WARN][2] ([i915#180]) +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9477/shard-kbl4/igt@gem_ctx_isolation@preservation...@rcs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19127/shard-kbl7/igt@gem_ctx_isolation@preservation...@rcs0.html * igt@gem_exec_capture@pi@rcs0: - shard-skl: [PASS][3] -> [INCOMPLETE][4] ([i915#2369]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9477/shard-skl7/igt@gem_exec_capture@p...@rcs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19127/shard-skl10/igt@gem_exec_capture@p...@rcs0.html * igt@gem_exec_create@forked: - shard-tglb: [PASS][5] -> [INCOMPLETE][6] ([i915#2583]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9477/shard-tglb2/igt@gem_exec_cre...@forked.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19127/shard-tglb2/igt@gem_exec_cre...@forked.html * igt@gem_exec_params@no-vebox: - shard-skl: NOTRUN -> [SKIP][7] ([fdo#109271]) +73 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19127/shard-skl4/igt@gem_exec_par...@no-vebox.html * igt@gem_exec_reloc@basic-many-active@rcs0: - shard-hsw: [PASS][8] -> [FAIL][9] ([i915#2389]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9477/shard-hsw6/igt@gem_exec_reloc@basic-many-act...@rcs0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19127/shard-hsw6/igt@gem_exec_reloc@basic-many-act...@rcs0.html * igt@gem_userptr_blits@process-exit-mmap@gtt: - shard-kbl: NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#1699]) +3 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19127/shard-kbl3/igt@gem_userptr_blits@process-exit-m...@gtt.html * igt@gen9_exec_parse@allowed-single: - shard-skl: [PASS][11] -> [DMESG-WARN][12] ([i915#1436] / [i915#716]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9477/shard-skl8/igt@gen9_exec_pa...@allowed-single.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19127/shard-skl4/igt@gen9_exec_pa...@allowed-single.html * igt@gen9_exec_parse@bb-start-param: - shard-tglb: NOTRUN -> [SKIP][13] ([fdo#112306]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19127/shard-tglb1/igt@gen9_exec_pa...@bb-start-param.html * igt@i915_pm_rpm@dpms-mode-unset-non-lpsp: - shard-tglb: NOTRUN -> [SKIP][14] ([fdo#111644] / [i915#1397] / [i915#2411]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19127/shard-tglb1/igt@i915_pm_...@dpms-mode-unset-non-lpsp.html * igt@i915_selftest@live@hangcheck: - shard-iclb: [PASS][15] -> [INCOMPLETE][16] ([i915#926]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9477/shard-iclb3/igt@i915_selftest@l...@hangcheck.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19127/shard-iclb4/igt@i915_selftest@l...@hangcheck.html * igt@kms_async_flips@test-time-stamp: - shard-tglb: [PASS][17] -> [FAIL][18] ([i915#2574]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9477/shard-tglb3/igt@kms_async_fl...@test-time-stamp.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19127/shard-tglb6/igt@kms_async_fl...@test-time-stamp.html * igt@kms_atomic_transition@3x-modeset-transitions: - shard-kbl: NOTRUN -> [SKIP][19] ([fdo#109271]) +22 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19127/shard-kbl3/igt@kms_atomic_transit...@3x-modeset-transitions.html * igt@kms_big_joiner@basic: - shard-skl: NOTRUN -> [SKIP][20] ([fdo#109271] / [i915#2705]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19127/shard-skl3/igt@kms_big_joi...@basic.html * igt@kms_chamelium@dp-crc-multiple: - shard-kbl: NOTRUN -> [SKIP][21] ([fdo#109271] / [fdo#111827]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19127/shard-kbl3/igt@kms_chamel...@dp-crc-multiple.html * igt@kms_chamelium@vga-hpd: - shard-skl: NOTRUN -> [SKIP][22] ([fdo#109271] / [fdo#111827]) +10 similar issues [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19127/shard-skl4/igt@kms_chamel...@vga-hpd.html * igt@kms_color_chamelium@pipe-c-ctm-blue-to-red: - shard-tglb: NOTRUN -
Re: [Intel-gfx] [patch 27/30] xen/events: Only force affinity mask for percpu interrupts
On Fri, Dec 11 2020 at 09:29, boris ostrovsky wrote: > On 12/11/20 7:37 AM, Thomas Gleixner wrote: >> On Fri, Dec 11 2020 at 13:10, Jürgen Groß wrote: >>> On 11.12.20 00:20, boris.ostrov...@oracle.com wrote: On 12/10/20 2:26 PM, Thomas Gleixner wrote: > Change the implementation so that the channel is bound to CPU0 at the XEN > level and leave the affinity mask alone. At startup of the interrupt > affinity will be assigned out of the affinity mask and the XEN binding > will > be updated. If that's the case then I wonder whether we need this call at all and instead bind at startup time. >>> After some discussion with Thomas on IRC and xen-devel archaeology the >>> result is: this will be needed especially for systems running on a >>> single vcpu (e.g. small guests), as the .irq_set_affinity() callback >>> won't be called in this case when starting the irq. > > On UP are we not then going to end up with an empty affinity mask? Or > are we guaranteed to have it set to 1 by interrupt generic code? An UP kernel does not ever look on the affinity mask. The chip::irq_set_affinity() callback is not invoked so the mask is irrelevant. A SMP kernel on a UP machine sets CPU0 in the mask so all is good. > This is actually why I brought this up in the first place --- a > potential mismatch between the affinity mask and Xen-specific data > (e.g. info->cpu and then protocol-specific data in event channel > code). Even if they are re-synchronized later, at startup time (for > SMP). Which is not a problem either. The affinity mask is only relevant for setting the affinity, but it's not relevant for delivery and never can be. > I don't see anything that would cause a problem right now but I worry > that this inconsistency may come up at some point. As long as the affinity mask becomes not part of the event channel magic this should never matter. Look at it from hardware: interrupt is affine to CPU0 CPU0 runs: set_affinity(CPU0 -> CPU1) local_irq_disable() --> interrupt is raised in hardware and pending on CPU0 irq hardware is reconfigured to be affine to CPU1 local_irq_enable() --> interrupt is handled on CPU0 the next interrupt will be raised on CPU1 So info->cpu which is registered via the hypercall binds the 'hardware delivery' and whenever the new affinity is written it is rebound to some other CPU and the next interrupt is then raised on this other CPU. It's not any different from the hardware example at least not as far as I understood the code. Thanks, tglx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [patch 14/30] drm/i915/pmu: Replace open coded kstat_irqs() copy
On Fri, Dec 11 2020 at 14:19, David Laight wrote: > From: Thomas Gleixner >> You can't catch that. If this really becomes an issue you need a >> sequence counter around it. > > Or just two copies of the high word. > Provided the accesses are sequenced: > writer: > load high:low > add small_value,high:low > store high > store low > store high_copy > reader: > load high_copy > load low > load high > if (high != high_copy) > low = 0; And low = 0 is solving what? You need to loop back and retry until it's consistent and then it's nothing else than an open coded sequence count. Thanks, tglx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [patch 03/30] genirq: Move irq_set_lockdep_class() to core
On Fri, Dec 11 2020 at 19:53, Andy Shevchenko wrote: > On Thu, Dec 10, 2020 at 10:14 PM Thomas Gleixner wrote: >> >> irq_set_lockdep_class() is used from modules and requires irq_to_desc() to >> be exported. Move it into the core code which lifts another requirement for >> the export. > > ... > >> + if (IS_ENABLED(CONFIG_LOCKDEP)) >> + __irq_set_lockdep_class(irq, lock_class, request_class); You are right. Let me fix that. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for gpu: drm: i915: convert comma to semicolon
== Series Details == Series: gpu: drm: i915: convert comma to semicolon URL : https://patchwork.freedesktop.org/series/84845/ State : success == Summary == CI Bug Log - changes from CI_DRM_9476_full -> Patchwork_19125_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_19125_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@preservation-s3@vecs0: - shard-kbl: [PASS][1] -> [DMESG-WARN][2] ([i915#180]) +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9476/shard-kbl1/igt@gem_ctx_isolation@preservation...@vecs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19125/shard-kbl6/igt@gem_ctx_isolation@preservation...@vecs0.html * igt@gem_ctx_persistence@smoketest: - shard-hsw: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#1099]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19125/shard-hsw7/igt@gem_ctx_persiste...@smoketest.html * igt@gem_exec_reloc@basic-wide-active@vcs1: - shard-iclb: NOTRUN -> [FAIL][4] ([i915#2389]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19125/shard-iclb2/igt@gem_exec_reloc@basic-wide-act...@vcs1.html * igt@gem_userptr_blits@process-exit-mmap-busy@uc: - shard-skl: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#1699]) +3 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19125/shard-skl9/igt@gem_userptr_blits@process-exit-mmap-b...@uc.html * igt@gem_userptr_blits@process-exit-mmap@wc: - shard-hsw: NOTRUN -> [SKIP][6] ([fdo#109271]) +51 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19125/shard-hsw7/igt@gem_userptr_blits@process-exit-m...@wc.html * igt@kms_chamelium@dp-crc-multiple: - shard-hsw: NOTRUN -> [SKIP][7] ([fdo#109271] / [fdo#111827]) +2 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19125/shard-hsw7/igt@kms_chamel...@dp-crc-multiple.html * igt@kms_chamelium@vga-frame-dump: - shard-skl: NOTRUN -> [SKIP][8] ([fdo#109271] / [fdo#111827]) +8 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19125/shard-skl6/igt@kms_chamel...@vga-frame-dump.html * igt@kms_cursor_crc@pipe-b-cursor-128x42-random: - shard-skl: [PASS][9] -> [FAIL][10] ([i915#54]) +4 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9476/shard-skl2/igt@kms_cursor_...@pipe-b-cursor-128x42-random.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19125/shard-skl10/igt@kms_cursor_...@pipe-b-cursor-128x42-random.html * igt@kms_cursor_crc@pipe-c-cursor-64x64-onscreen: - shard-skl: NOTRUN -> [FAIL][11] ([i915#54]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19125/shard-skl9/igt@kms_cursor_...@pipe-c-cursor-64x64-onscreen.html * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic: - shard-hsw: [PASS][12] -> [FAIL][13] ([i915#96]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9476/shard-hsw1/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-atomic.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19125/shard-hsw8/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-atomic.html * igt@kms_fbcon_fbt@fbc-suspend: - shard-kbl: [PASS][14] -> [INCOMPLETE][15] ([i915#155] / [i915#180] / [i915#636]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9476/shard-kbl6/igt@kms_fbcon_...@fbc-suspend.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19125/shard-kbl4/igt@kms_fbcon_...@fbc-suspend.html * igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-pri-indfb-draw-blt: - shard-skl: NOTRUN -> [SKIP][16] ([fdo#109271]) +55 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19125/shard-skl9/igt@kms_frontbuffer_track...@fbc-2p-scndscrn-pri-indfb-draw-blt.html * igt@kms_pipe_crc_basic@hang-read-crc-pipe-d: - shard-skl: NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#533]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19125/shard-skl8/igt@kms_pipe_crc_ba...@hang-read-crc-pipe-d.html * igt@kms_plane_alpha_blend@pipe-c-alpha-opaque-fb: - shard-skl: NOTRUN -> [FAIL][18] ([fdo#108145] / [i915#265]) +1 similar issue [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19125/shard-skl5/igt@kms_plane_alpha_bl...@pipe-c-alpha-opaque-fb.html * igt@kms_psr@psr2_cursor_blt: - shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109441]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9476/shard-iclb2/igt@kms_psr@psr2_cursor_blt.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19125/shard-iclb7/igt@kms_psr@psr2_cursor_blt.html Possible fixes * igt@gem_huc_copy@huc-copy:
Re: [Intel-gfx] [patch 16/30] mfd: ab8500-debugfs: Remove the racy fiddling with irq_desc
On Thu, Dec 10, 2020 at 9:57 PM Thomas Gleixner wrote: > > First of all drivers have absolutely no business to dig into the internals > of an irq descriptor. That's core code and subject to change. All of this > information is readily available to /proc/interrupts in a safe and race > free way. > > Remove the inspection code which is a blatant violation of subsystem > boundaries and racy against concurrent modifications of the interrupt > descriptor. > > Print the irq line instead so the information can be looked up in a sane > way in /proc/interrupts. ... > - seq_printf(s, "%3i: %6i %4i", > + seq_printf(s, "%3i: %6i %4i %4i\n", Seems different specifiers, I think the intention was something like seq_printf(s, "%3i: %4i %6i %4i\n", >line, > + line + irq_first, >num_interrupts[line], >num_wake_interrupts[line]); -- With Best Regards, Andy Shevchenko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [patch 09/30] ARM: smp: Use irq_desc_kstat_cpu() in show_ipi_list()
On Thu, 10 Dec 2020 19:25:45 +, Thomas Gleixner wrote: > > The irq descriptor is already there, no need to look it up again. > > Signed-off-by: Thomas Gleixner > Cc: Marc Zyngier > Cc: Russell King > Cc: linux-arm-ker...@lists.infradead.org > --- > arch/arm/kernel/smp.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > --- a/arch/arm/kernel/smp.c > +++ b/arch/arm/kernel/smp.c > @@ -550,7 +550,7 @@ void show_ipi_list(struct seq_file *p, i > seq_printf(p, "%*s%u: ", prec - 1, "IPI", i); > > for_each_online_cpu(cpu) > - seq_printf(p, "%10u ", kstat_irqs_cpu(irq, cpu)); > + seq_printf(p, "%10u ", irq_desc_kstat_cpu(ipi_desc[i], > cpu)); > > seq_printf(p, " %s\n", ipi_types[i]); > } > > Acked-by: Marc Zyngier -- Without deviation from the norm, progress is not possible. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [patch 10/30] arm64/smp: Use irq_desc_kstat_cpu() in arch_show_interrupts()
On Thu, 10 Dec 2020 19:25:46 +, Thomas Gleixner wrote: > > The irq descriptor is already there, no need to look it up again. > > Signed-off-by: Thomas Gleixner > Cc: Mark Rutland > Cc: Catalin Marinas > Cc: Will Deacon > Cc: Marc Zyngier > Cc: linux-arm-ker...@lists.infradead.org > --- > arch/arm64/kernel/smp.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > --- a/arch/arm64/kernel/smp.c > +++ b/arch/arm64/kernel/smp.c > @@ -809,7 +809,7 @@ int arch_show_interrupts(struct seq_file > seq_printf(p, "%*s%u:%s", prec - 1, "IPI", i, > prec >= 4 ? " " : ""); > for_each_online_cpu(cpu) > - seq_printf(p, "%10u ", kstat_irqs_cpu(irq, cpu)); > + seq_printf(p, "%10u ", irq_desc_kstat_cpu(ipi_desc[i], > cpu)); > seq_printf(p, " %s\n", ipi_types[i]); > } > > > Acked-by: Marc Zyngier -- Without deviation from the norm, progress is not possible. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v5,1/2] drm/i915/display: Support PSR Multiple Transcoders
== Series Details ==
Series: series starting with [v5,1/2] drm/i915/display: Support PSR Multiple
Transcoders
URL : https://patchwork.freedesktop.org/series/84853/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9477 -> Patchwork_19127
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19127/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_19127:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_psr@primary_mmap_gtt:
- {fi-tgl-dsi}: [SKIP][1] ([fdo#110189]) -> [SKIP][2] +3 similar
issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9477/fi-tgl-dsi/igt@kms_psr@primary_mmap_gtt.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19127/fi-tgl-dsi/igt@kms_psr@primary_mmap_gtt.html
Known issues
Here are the changes found in Patchwork_19127 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_linear_blits@basic:
- fi-tgl-y: [PASS][3] -> [DMESG-WARN][4] ([i915#402]) +1 similar
issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9477/fi-tgl-y/igt@gem_linear_bl...@basic.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19127/fi-tgl-y/igt@gem_linear_bl...@basic.html
* igt@i915_selftest@live@gt_timelines:
- fi-apl-guc: [PASS][5] -> [INCOMPLETE][6] ([i915#2750])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9477/fi-apl-guc/igt@i915_selftest@live@gt_timelines.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19127/fi-apl-guc/igt@i915_selftest@live@gt_timelines.html
Possible fixes
* igt@kms_chamelium@dp-edid-read:
- fi-kbl-7500u: [DMESG-WARN][7] ([i915#165]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9477/fi-kbl-7500u/igt@kms_chamel...@dp-edid-read.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19127/fi-kbl-7500u/igt@kms_chamel...@dp-edid-read.html
* igt@prime_self_import@basic-with_two_bos:
- fi-tgl-y: [DMESG-WARN][9] ([i915#402]) -> [PASS][10] +1 similar
issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9477/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19127/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#110189]: https://bugs.freedesktop.org/show_bug.cgi?id=110189
[i915#165]: https://gitlab.freedesktop.org/drm/intel/issues/165
[i915#2601]: https://gitlab.freedesktop.org/drm/intel/issues/2601
[i915#2750]: https://gitlab.freedesktop.org/drm/intel/issues/2750
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
Participating hosts (42 -> 40)
--
Missing(2): fi-bdw-samus fi-hsw-4200u
Build changes
-
* Linux: CI_DRM_9477 -> Patchwork_19127
CI-20190529: 20190529
CI_DRM_9477: a1296778faa59a7f07c82146c763088db545b725 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5889: 3e63914556947974bd2d1cf92dda5b83e36848e4 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_19127: 2e9c022e19567cf0e2766a417d519d1170213b81 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
2e9c022e1956 drm/i915/display: Support Multiple Transcoders' PSR status on
debugfs
c3088251ff36 drm/i915/display: Support PSR Multiple Transcoders
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19127/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [patch 03/30] genirq: Move irq_set_lockdep_class() to core
On Thu, Dec 10, 2020 at 10:14 PM Thomas Gleixner wrote: > > irq_set_lockdep_class() is used from modules and requires irq_to_desc() to > be exported. Move it into the core code which lifts another requirement for > the export. ... > + if (IS_ENABLED(CONFIG_LOCKDEP)) > + __irq_set_lockdep_class(irq, lock_class, request_class); Maybe I missed something, but even if the compiler does not warn the use of if IS_ENABLED() with complimentary #ifdef seems inconsistent. > +#ifdef CONFIG_LOCKDEP ... > +EXPORT_SYMBOL_GPL(irq_set_lockdep_class); > +#endif -- With Best Regards, Andy Shevchenko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.DOCS: warning for series starting with [v5,1/2] drm/i915/display: Support PSR Multiple Transcoders
== Series Details == Series: series starting with [v5,1/2] drm/i915/display: Support PSR Multiple Transcoders URL : https://patchwork.freedesktop.org/series/84853/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 Error: Cannot open file ./drivers/gpu/drm/i915/gt/intel_lrc.c WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -sphinx-version 1.7.9 -function Logical Rings, Logical Ring Contexts and Execlists ./drivers/gpu/drm/i915/gt/intel_lrc.c' failed with return code 1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v5,1/2] drm/i915/display: Support PSR Multiple Transcoders
== Series Details == Series: series starting with [v5,1/2] drm/i915/display: Support PSR Multiple Transcoders URL : https://patchwork.freedesktop.org/series/84853/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/i915/gt/intel_reset.c:1310:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +drivers/gpu/drm/i915/gt/selftest_reset.c:100:20:expected void *in +drivers/gpu/drm/i915/gt/selftest_reset.c:100:20:got void [noderef] __iomem *[assigned] s +drivers/gpu/drm/i915/gt/selftest_reset.c:100:20: warning: incorrect type in assignment (different address spaces) +drivers/gpu/drm/i915/gt/selftest_reset.c:101:46:expected void const *src +drivers/gpu/drm/i915/gt/selftest_reset.c:101:46:got void [noderef] __iomem *[assigned] s +drivers/gpu/drm/i915/gt/selftest_reset.c:101:46: warning: incorrect type in argument 2 (different address spaces) +drivers/gpu/drm/i915/gt/selftest_reset.c:136:20:expected void *in +drivers/gpu/drm/i915/gt/selftest_reset.c:136:20:got void [noderef] __iomem *[assigned] s +drivers/gpu/drm/i915/gt/selftest_reset.c:136:20: warning: incorrect type in assignment (different address spaces) +drivers/gpu/drm/i915/gt/selftest_reset.c:137:46:expected void const *src +drivers/gpu/drm/i915/gt/selftest_reset.c:137:46:got void [noderef] __iomem *[assigned] s +drivers/gpu/drm/i915/gt/selftest_reset.c:137:46: warning: incorrect type in argument 2 (different address spaces) +drivers/gpu/drm/i915/gt/selftest_reset.c:98:34:expected unsigned int [usertype] *s +drivers/gpu/drm/i915/gt/selftest_reset.c:98:34:got void [noderef] __iomem *[assigned] s +drivers/gpu/drm/i915/gt/selftest_reset.c:98:34: warning: incorrect type in argument 1 (different address spaces) +drivers/gpu/drm/i915/gvt/mmio.c:295:23: warning: memcpy with byte count of 279040 +drivers/gpu/drm/i915/i915_perf.c:1448:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1502:15: warning: memset with byte count of 16777216 +./include/linux/seqlock.h:838:24: warning: trying to copy expression type 31 +./include/linux/seqlock.h:838:24: warning: trying to copy expression type 31 +./include/linux/seqlock.h:864:16: warning: trying to copy expression type 31 +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write32' - different lock contexts for basic block +./include/linux/spinl
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v5,1/2] drm/i915/display: Support PSR Multiple Transcoders
== Series Details == Series: series starting with [v5,1/2] drm/i915/display: Support PSR Multiple Transcoders URL : https://patchwork.freedesktop.org/series/84853/ State : warning == Summary == $ dim checkpatch origin/drm-tip c3088251ff36 drm/i915/display: Support PSR Multiple Transcoders -:1704: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'intel_dp' - possible side-effects? #1704: FILE: drivers/gpu/drm/i915/display/intel_psr.h:21: +#define CAN_PSR(intel_dp) (HAS_PSR(dp_to_i915(intel_dp)) && intel_dp->psr.sink_support) total: 0 errors, 0 warnings, 1 checks, 1737 lines checked 2e9c022e1956 drm/i915/display: Support Multiple Transcoders' PSR status on debugfs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 2/2] drm/i915/display: Support Multiple Transcoders' PSR status on debugfs
In order to support the PSR state of each transcoder, it adds
i915_psr_status to sub-directory of each transcoder.
v2: Change using of Symbolic permissions 'S_IRUGO' to using of octal
permissions '0444'
v5: Addressed JJani Nikula's review comments
- Remove checking of Gen12 for i915_psr_status.
- Add check of HAS_PSR()
- Remove meaningless check routine.
Signed-off-by: Gwan-gyeong Mun
Cc: José Roberto de Souza
Cc: Jani Nikula
Cc: Anshuman Gupta
---
.../gpu/drm/i915/display/intel_display_debugfs.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 041053167d7f..d2dd61c4ee0b 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -2224,6 +2224,16 @@ static int i915_hdcp_sink_capability_show(struct
seq_file *m, void *data)
}
DEFINE_SHOW_ATTRIBUTE(i915_hdcp_sink_capability);
+static int i915_psr_status_show(struct seq_file *m, void *data)
+{
+ struct drm_connector *connector = m->private;
+ struct intel_dp *intel_dp =
+ intel_attached_dp(to_intel_connector(connector));
+
+ return intel_psr_status(m, intel_dp);
+}
+DEFINE_SHOW_ATTRIBUTE(i915_psr_status);
+
#define LPSP_CAPABLE(COND) (COND ? seq_puts(m, "LPSP: capable\n") : \
seq_puts(m, "LPSP: incapable\n"))
@@ -2399,6 +2409,12 @@ int intel_connector_debugfs_add(struct drm_connector
*connector)
connector, &i915_psr_sink_status_fops);
}
+ if (HAS_PSR(dev_priv) &&
+ connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
+ debugfs_create_file("i915_psr_status", 0444, root,
+ connector, &i915_psr_status_fops);
+ }
+
if (connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
connector->connector_type == DRM_MODE_CONNECTOR_HDMIA ||
connector->connector_type == DRM_MODE_CONNECTOR_HDMIB) {
--
2.25.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 1/2] drm/i915/display: Support PSR Multiple Transcoders
It is a preliminary work for supporting multiple EDP PSR and
DP PanelReplay. And it refactors singleton PSR to Multi Transcoder
supportable PSR.
And this moves and renames the i915_psr structure of drm_i915_private's to
intel_dp's intel_psr structure.
It also causes changes in PSR interrupt handling routine for supporting
multiple transcoders. But it does not change the scenario and timing of
enabling and disabling PSR.
v2: Fix indentation and add comments
v3: Remove Blank line
v4: Rebased
v5: Rebased and Addressed Anshuman's review comment.
- Move calling of intel_psr_init() to intel_dp_init_connector()
Signed-off-by: Gwan-gyeong Mun
Cc: José Roberto de Souza
Cc: Juha-Pekka Heikkila
Cc: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_ddi.c | 3 +
drivers/gpu/drm/i915/display/intel_display.c | 4 -
.../drm/i915/display/intel_display_debugfs.c | 111 ++--
.../drm/i915/display/intel_display_types.h| 38 ++
drivers/gpu/drm/i915/display/intel_dp.c | 23 +-
drivers/gpu/drm/i915/display/intel_psr.c | 585 ++
drivers/gpu/drm/i915/display/intel_psr.h | 14 +-
drivers/gpu/drm/i915/display/intel_sprite.c | 6 +-
drivers/gpu/drm/i915/i915_drv.h | 38 --
drivers/gpu/drm/i915/i915_irq.c | 49 +-
10 files changed, 491 insertions(+), 380 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 6863236df1d0..4b87f72cb9c0 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -4320,7 +4320,10 @@ static void intel_ddi_update_pipe_dp(struct
intel_atomic_state *state,
intel_ddi_set_dp_msa(crtc_state, conn_state);
+ //TODO: move PSR related functions into intel_psr_update()
+ intel_psr2_program_trans_man_trk_ctl(intel_dp, crtc_state);
intel_psr_update(intel_dp, crtc_state, conn_state);
+
intel_dp_set_infoframes(encoder, true, crtc_state, conn_state);
intel_edp_drrs_update(intel_dp, crtc_state);
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 761be8deaa9b..f26d9bcd722c 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -15869,8 +15869,6 @@ static void commit_pipe_config(struct
intel_atomic_state *state,
if (new_crtc_state->update_pipe)
intel_pipe_fastset(old_crtc_state, new_crtc_state);
-
- intel_psr2_program_trans_man_trk_ctl(new_crtc_state);
}
if (dev_priv->display.atomic_update_watermarks)
@@ -17830,8 +17828,6 @@ static void intel_setup_outputs(struct drm_i915_private
*dev_priv)
intel_dvo_init(dev_priv);
}
- intel_psr_init(dev_priv);
-
for_each_intel_encoder(&dev_priv->drm, encoder) {
encoder->base.possible_crtcs =
intel_encoder_possible_crtcs(encoder);
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index cd7e5519ee7d..041053167d7f 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -249,18 +249,17 @@ static int i915_psr_sink_status_show(struct seq_file *m,
void *data)
"sink internal error",
};
struct drm_connector *connector = m->private;
- struct drm_i915_private *dev_priv = to_i915(connector->dev);
struct intel_dp *intel_dp =
intel_attached_dp(to_intel_connector(connector));
int ret;
- if (!CAN_PSR(dev_priv)) {
- seq_puts(m, "PSR Unsupported\n");
+ if (connector->status != connector_status_connected)
return -ENODEV;
- }
- if (connector->status != connector_status_connected)
+ if (!CAN_PSR(intel_dp)) {
+ seq_puts(m, "PSR Unsupported\n");
return -ENODEV;
+ }
ret = drm_dp_dpcd_readb(&intel_dp->aux, DP_PSR_STATUS, &val);
@@ -280,12 +279,13 @@ static int i915_psr_sink_status_show(struct seq_file *m,
void *data)
DEFINE_SHOW_ATTRIBUTE(i915_psr_sink_status);
static void
-psr_source_status(struct drm_i915_private *dev_priv, struct seq_file *m)
+psr_source_status(struct intel_dp *intel_dp, struct seq_file *m)
{
u32 val, status_val;
const char *status = "unknown";
+ struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
- if (dev_priv->psr.psr2_enabled) {
+ if (intel_dp->psr.psr2_enabled) {
static const char * const live_status[] = {
"IDLE",
"CAPTURE",
@@ -300,7 +300,7 @@ psr_source_status(struct drm_i915_private *dev_priv, struct
seq_file *m)
"TG_ON"
};
val = intel_de_read(dev_priv,
-
Re: [Intel-gfx] [PATCH 09/11] drm/i915: migrate skl planes code new file
Hi Dave,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-tip/drm-tip next-20201211]
[cannot apply to v5.10-rc7]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Dave-Airlie/drm-i915-display-move-needs_modeset-to-an-inline-in-header/20201211-163119
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-randconfig-a003-20201210 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
5ff35356f1af2bb92785b38c657463924d9ec386)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
#
https://github.com/0day-ci/linux/commit/a5c9dca8844730c679e9716efd016bfe04f9d002
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Dave-Airlie/drm-i915-display-move-needs_modeset-to-an-inline-in-header/20201211-163119
git checkout a5c9dca8844730c679e9716efd016bfe04f9d002
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/i915/display/intel_gen9_plane.c:1396:5: warning: no previous
>> prototype for function 'skl_plane_ctl_crtc' [-Wmissing-prototypes]
u32 skl_plane_ctl_crtc(const struct intel_crtc_state *crtc_state)
^
drivers/gpu/drm/i915/display/intel_gen9_plane.c:1396:1: note: declare
'static' if the function is not intended to be used outside of this translation
unit
u32 skl_plane_ctl_crtc(const struct intel_crtc_state *crtc_state)
^
static
>> drivers/gpu/drm/i915/display/intel_gen9_plane.c:1416:5: warning: no previous
>> prototype for function 'skl_plane_ctl' [-Wmissing-prototypes]
u32 skl_plane_ctl(const struct intel_crtc_state *crtc_state,
^
drivers/gpu/drm/i915/display/intel_gen9_plane.c:1416:1: note: declare
'static' if the function is not intended to be used outside of this translation
unit
u32 skl_plane_ctl(const struct intel_crtc_state *crtc_state,
^
static
>> drivers/gpu/drm/i915/display/intel_gen9_plane.c:1455:5: warning: no previous
>> prototype for function 'glk_plane_color_ctl_crtc' [-Wmissing-prototypes]
u32 glk_plane_color_ctl_crtc(const struct intel_crtc_state *crtc_state)
^
drivers/gpu/drm/i915/display/intel_gen9_plane.c:1455:1: note: declare
'static' if the function is not intended to be used outside of this translation
unit
u32 glk_plane_color_ctl_crtc(const struct intel_crtc_state *crtc_state)
^
static
>> drivers/gpu/drm/i915/display/intel_gen9_plane.c:1472:5: warning: no previous
>> prototype for function 'glk_plane_color_ctl' [-Wmissing-prototypes]
u32 glk_plane_color_ctl(const struct intel_crtc_state *crtc_state,
^
drivers/gpu/drm/i915/display/intel_gen9_plane.c:1472:1: note: declare
'static' if the function is not intended to be used outside of this translation
unit
u32 glk_plane_color_ctl(const struct intel_crtc_state *crtc_state,
^
static
4 warnings generated.
vim +/skl_plane_ctl_crtc +1396 drivers/gpu/drm/i915/display/intel_gen9_plane.c
1395
> 1396 u32 skl_plane_ctl_crtc(const struct intel_crtc_state *crtc_state)
1397 {
1398 struct drm_i915_private *dev_priv =
to_i915(crtc_state->uapi.crtc->dev);
1399 u32 plane_ctl = 0;
1400
1401 if (crtc_state->uapi.async_flip)
1402 plane_ctl |= PLANE_CTL_ASYNC_FLIP;
1403
1404 if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
1405 return plane_ctl;
1406
1407 if (crtc_state->gamma_enable)
1408 plane_ctl |= PLANE_CTL_PIPE_GAMMA_ENABLE;
1409
1410 if (crtc_state->csc_enable)
1411 plane_ctl |= PLANE_CTL_PIPE_CSC_ENABLE;
1412
1413 return plane_ctl;
1414 }
1415
> 1416 u32 skl_plane_ctl(const struct intel_crtc_state *crtc_state,
1417const struct intel_plane_state *plane_state)
1418 {
1419 struct drm_i915_private *dev_priv =
1420 to_i915(plane_state->uapi.plane->dev);
1421 const struct drm_framebuffer *fb = plane_state->hw.fb;
1422 unsigned int rotation
Re: [Intel-gfx] [PATCH 28/65] drm/ttm: WARN_ON non-empty lru when disabling a resource manager
On Fri, Oct 23, 2020 at 04:56:20PM +0200, Daniel Vetter wrote:
> On Fri, Oct 23, 2020 at 4:54 PM Christian König
> wrote:
> >
> > Am 23.10.20 um 14:21 schrieb Daniel Vetter:
> > > ttm_resource_manager->use_type is only used for runtime changes by
> > > vmwgfx. I think ideally we'd push this functionality into drivers -
> > > ttm itself does not provide any locking to guarantee this is safe, so
> > > the only way this can work at runtime is if the driver does provide
> > > additional guarantees. vwmgfx does that through the
> > > vmw_private->reservation_sem. Therefore supporting this feature in
> > > shared code feels a bit misplaced.
> > >
> > > As a first step add a WARN_ON to make sure the resource manager is
> > > empty. This is just to make sure I actually understand correctly what
> > > vmwgfx is doing, and to make sure an eventual subsequent refactor
> > > doesn't break anything.
> > >
> > > This check should also be useful for other drivers, to make sure they
> > > haven't leaked anything.
> > >
> > > Signed-off-by: Daniel Vetter
> > > Cc: Christian Koenig
> > > Cc: Huang Rui
> >
> > I'm pretty sure that this will trigger for vmwgfx. But that's what it is
> > supposed to do, isn't it?
>
> Yeah, this is an accidental dump of my wip pile, and it's not done yet
> at all. Please disregard (at least for now).
> -Daniel
>
> > Reviewed-by: Christian König
Ok decided to submit these 3 patches finally, including the 2 vmwgfx fixes
which should avoid the splat. I included your r-b, pls complain if that's
not ok anymore.
Thanks, Daniel
> >
> > > ---
> > > include/drm/ttm/ttm_resource.h | 4
> > > 1 file changed, 4 insertions(+)
> > >
> > > diff --git a/include/drm/ttm/ttm_resource.h
> > > b/include/drm/ttm/ttm_resource.h
> > > index f48a70d39ac5..789ec477b607 100644
> > > --- a/include/drm/ttm/ttm_resource.h
> > > +++ b/include/drm/ttm/ttm_resource.h
> > > @@ -191,6 +191,10 @@ struct ttm_resource {
> > > static inline void
> > > ttm_resource_manager_set_used(struct ttm_resource_manager *man, bool
> > > used)
> > > {
> > > + int i;
> > > +
> > > + for (i = 0; i < TTM_MAX_BO_PRIORITY; i++)
> > > + WARN_ON(!list_empty(&man->lru[i]));
> > > man->use_type = used;
> > > }
> > >
> >
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [1/4] dma-buf: Remove kmap kerneldoc vestiges
== Series Details == Series: series starting with [1/4] dma-buf: Remove kmap kerneldoc vestiges URL : https://patchwork.freedesktop.org/series/84849/ State : failure == Summary == CALLscripts/checksyscalls.sh CALLscripts/atomic/check-atomics.sh DESCEND objtool CHK include/generated/compile.h CC drivers/dma-buf/dma-buf.o In file included from ./include/linux/kernel.h:15, from ./include/linux/list.h:9, from ./include/linux/wait.h:7, from ./include/linux/wait_bit.h:8, from ./include/linux/fs.h:6, from drivers/dma-buf/dma-buf.c:14: drivers/dma-buf/dma-buf.c: In function ‘dma_buf_begin_cpu_access’: drivers/dma-buf/dma-buf.c:1134:14: error: ‘dma_buf’ undeclared (first use in this function) might_lock(&dma_buf->resv.lock); ^~~ ./include/linux/typecheck.h:11:9: note: in definition of macro ‘typecheck’ typeof(x) __dummy2; \ ^ drivers/dma-buf/dma-buf.c:1134:2: note: in expansion of macro ‘might_lock’ might_lock(&dma_buf->resv.lock); ^~ drivers/dma-buf/dma-buf.c:1134:14: note: each undeclared identifier is reported only once for each function it appears in might_lock(&dma_buf->resv.lock); ^~~ ./include/linux/typecheck.h:11:9: note: in definition of macro ‘typecheck’ typeof(x) __dummy2; \ ^ drivers/dma-buf/dma-buf.c:1134:2: note: in expansion of macro ‘might_lock’ might_lock(&dma_buf->resv.lock); ^~ ./include/linux/typecheck.h:12:18: warning: comparison of distinct pointer types lacks a cast (void)(&__dummy == &__dummy2); \ ^~ ./include/linux/lockdep.h:542:2: note: in expansion of macro ‘typecheck’ typecheck(struct lockdep_map *, &(lock)->dep_map); \ ^ drivers/dma-buf/dma-buf.c:1134:2: note: in expansion of macro ‘might_lock’ might_lock(&dma_buf->resv.lock); ^~ drivers/dma-buf/dma-buf.c: In function ‘dma_buf_end_cpu_access’: drivers/dma-buf/dma-buf.c:1169:14: error: ‘dma_buf’ undeclared (first use in this function) might_lock(&dma_buf->resv.lock); ^~~ ./include/linux/typecheck.h:11:9: note: in definition of macro ‘typecheck’ typeof(x) __dummy2; \ ^ drivers/dma-buf/dma-buf.c:1169:2: note: in expansion of macro ‘might_lock’ might_lock(&dma_buf->resv.lock); ^~ ./include/linux/typecheck.h:12:18: warning: comparison of distinct pointer types lacks a cast (void)(&__dummy == &__dummy2); \ ^~ ./include/linux/lockdep.h:542:2: note: in expansion of macro ‘typecheck’ typecheck(struct lockdep_map *, &(lock)->dep_map); \ ^ drivers/dma-buf/dma-buf.c:1169:2: note: in expansion of macro ‘might_lock’ might_lock(&dma_buf->resv.lock); ^~ scripts/Makefile.build:279: recipe for target 'drivers/dma-buf/dma-buf.o' failed make[2]: *** [drivers/dma-buf/dma-buf.o] Error 1 scripts/Makefile.build:496: recipe for target 'drivers/dma-buf' failed make[1]: *** [drivers/dma-buf] Error 2 Makefile:1805: recipe for target 'drivers' failed make: *** [drivers] Error 2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for gpu: drm: i915: convert comma to semicolon
== Series Details == Series: gpu: drm: i915: convert comma to semicolon URL : https://patchwork.freedesktop.org/series/84845/ State : success == Summary == CI Bug Log - changes from CI_DRM_9476 -> Patchwork_19125 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19125/index.html Known issues Here are the changes found in Patchwork_19125 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@cs-compute: - fi-cfl-guc: NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19125/fi-cfl-guc/igt@amdgpu/amd_ba...@cs-compute.html * igt@i915_selftest@live@execlists: - fi-skl-6600u: [PASS][2] -> [INCOMPLETE][3] ([CI#80] / [i915#1037]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9476/fi-skl-6600u/igt@i915_selftest@l...@execlists.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19125/fi-skl-6600u/igt@i915_selftest@l...@execlists.html * igt@runner@aborted: - fi-skl-6600u: NOTRUN -> [FAIL][4] ([i915#1436] / [i915#2426] / [i915#2722]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19125/fi-skl-6600u/igt@run...@aborted.html Possible fixes * igt@debugfs_test@read_all_entries: - fi-tgl-y: [DMESG-WARN][5] ([i915#402]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9476/fi-tgl-y/igt@debugfs_test@read_all_entries.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19125/fi-tgl-y/igt@debugfs_test@read_all_entries.html * igt@i915_selftest@live@execlists: - fi-cfl-guc: [INCOMPLETE][7] ([i915#1037]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9476/fi-cfl-guc/igt@i915_selftest@l...@execlists.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19125/fi-cfl-guc/igt@i915_selftest@l...@execlists.html [CI#80]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/80 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#1037]: https://gitlab.freedesktop.org/drm/intel/issues/1037 [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436 [i915#2426]: https://gitlab.freedesktop.org/drm/intel/issues/2426 [i915#2722]: https://gitlab.freedesktop.org/drm/intel/issues/2722 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 Participating hosts (42 -> 40) -- Missing(2): fi-bdw-samus fi-hsw-4200u Build changes - * Linux: CI_DRM_9476 -> Patchwork_19125 CI-20190529: 20190529 CI_DRM_9476: d8abf7202ace9d800683176aab8df3137790a00c @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5889: 3e63914556947974bd2d1cf92dda5b83e36848e4 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_19125: 6e021cbcae75d2f5ef4182a1dbb5f98fe2760576 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 6e021cbcae75 gpu: drm: i915: convert comma to semicolon == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19125/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [patch 27/30] xen/events: Only force affinity mask for percpu interrupts
On 11.12.20 00:20, boris.ostrov...@oracle.com wrote: On 12/10/20 2:26 PM, Thomas Gleixner wrote: All event channel setups bind the interrupt on CPU0 or the target CPU for percpu interrupts and overwrite the affinity mask with the corresponding cpumask. That does not make sense. The XEN implementation of irqchip::irq_set_affinity() already picks a single target CPU out of the affinity mask and the actual target is stored in the effective CPU mask, so destroying the user chosen affinity mask which might contain more than one CPU is wrong. Change the implementation so that the channel is bound to CPU0 at the XEN level and leave the affinity mask alone. At startup of the interrupt affinity will be assigned out of the affinity mask and the XEN binding will be updated. If that's the case then I wonder whether we need this call at all and instead bind at startup time. After some discussion with Thomas on IRC and xen-devel archaeology the result is: this will be needed especially for systems running on a single vcpu (e.g. small guests), as the .irq_set_affinity() callback won't be called in this case when starting the irq. Juergen OpenPGP_0xB0DE9DD628BF132F.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4] dma-buf: begin/end_cpu might lock the dma_resv lock
At least amdgpu and i915 do, so lets just document this as the rule. Signed-off-by: Daniel Vetter Cc: Thomas Zimmermann Cc: Sumit Semwal Cc: "Christian König" Cc: linux-me...@vger.kernel.org Cc: linaro-mm-...@lists.linaro.org --- drivers/dma-buf/dma-buf.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index e1fa6c6f02c4..00d5afe904cc 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -1118,6 +1118,8 @@ int dma_buf_begin_cpu_access(struct dma_buf *dmabuf, if (WARN_ON(!dmabuf)) return -EINVAL; + might_lock(&dma_buf->resv.lock); + if (dmabuf->ops->begin_cpu_access) ret = dmabuf->ops->begin_cpu_access(dmabuf, direction); @@ -1151,6 +1153,8 @@ int dma_buf_end_cpu_access(struct dma_buf *dmabuf, WARN_ON(!dmabuf); + might_lock(&dma_buf->resv.lock); + if (dmabuf->ops->end_cpu_access) ret = dmabuf->ops->end_cpu_access(dmabuf, direction); -- 2.29.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/4] dma-buf: doc polish for pin/unpin
Motivated by a discussion with Christian and Thomas: Try to untangle a
bit what's relevant for importers and what's relevant for exporters.
Also add an assert that really only dynamic importers use the api
function, anything else doesn't make sense.
Signed-off-by: Daniel Vetter
Cc: Thomas Zimmermann
Cc: Sumit Semwal
Cc: "Christian König"
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
---
drivers/dma-buf/dma-buf.c | 19 ---
include/linux/dma-buf.h | 8 +---
2 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 00d5afe904cc..1065545e9ca1 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -809,9 +809,15 @@ EXPORT_SYMBOL_GPL(dma_buf_detach);
/**
* dma_buf_pin - Lock down the DMA-buf
- *
* @attach:[in]attachment which should be pinned
*
+ * Only dynamic importers (who set up @attach with dma_buf_dynamic_attach())
may
+ * call this, and only for limited use cases like scanout and not for temporary
+ * pin operations. It is not permitted to allow userspace to pin arbitrary
+ * amounts of buffers through this interface.
+ *
+ * Buffers must be unpinned by calling dma_buf_unpin().
+ *
* Returns:
* 0 on success, negative error code on failure.
*/
@@ -820,6 +826,8 @@ int dma_buf_pin(struct dma_buf_attachment *attach)
struct dma_buf *dmabuf = attach->dmabuf;
int ret = 0;
+ WARN_ON(!dma_buf_attachment_is_dynamic(attach));
+
dma_resv_assert_held(dmabuf->resv);
if (dmabuf->ops->pin)
@@ -830,14 +838,19 @@ int dma_buf_pin(struct dma_buf_attachment *attach)
EXPORT_SYMBOL_GPL(dma_buf_pin);
/**
- * dma_buf_unpin - Remove lock from DMA-buf
- *
+ * dma_buf_unpin - Unpin a DMA-buf
* @attach:[in]attachment which should be unpinned
+ *
+ * This unpins a buffer pinned by dma_buf_pin() and allows the exporter to move
+ * any mapping of @attach again and inform the importer through
+ * &dma_buf_attach_ops.move_notify.
*/
void dma_buf_unpin(struct dma_buf_attachment *attach)
{
struct dma_buf *dmabuf = attach->dmabuf;
+ WARN_ON(!dma_buf_attachment_is_dynamic(attach));
+
dma_resv_assert_held(dmabuf->resv);
if (dmabuf->ops->unpin)
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index 43802a31b25d..628681bf6c99 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -86,13 +86,15 @@ struct dma_buf_ops {
* @pin:
*
* This is called by dma_buf_pin() and lets the exporter know that the
-* DMA-buf can't be moved any more.
+* DMA-buf can't be moved any more. The exporter should pin the buffer
+* into system memory to make sure it is generally accessible by other
+* devices.
*
* This is called with the &dmabuf.resv object locked and is mutual
* exclusive with @cache_sgt_mapping.
*
-* This callback is optional and should only be used in limited use
-* cases like scanout and not for temporary pin operations.
+* This is called automatically for non-dynamic importers from
+* dma_buf_attach().
*
* Returns:
*
--
2.29.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] dma-buf: some kerneldoc formatting fixes
Noticed while reviewing the output. Adds a bunch more links and fixes
the function interface quoting.
Signed-off-by: Daniel Vetter
Cc: Thomas Zimmermann
Cc: Sumit Semwal
Cc: "Christian König"
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
---
drivers/dma-buf/dma-buf.c | 31 ++-
include/linux/dma-buf.h | 6 +++---
2 files changed, 21 insertions(+), 16 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index a12fdffa130f..e1fa6c6f02c4 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -480,7 +480,7 @@ static struct file *dma_buf_getfile(struct dma_buf *dmabuf,
int flags)
*
* 4. Once a driver is done with a shared buffer it needs to call
*dma_buf_detach() (after cleaning up any mappings) and then release the
- *reference acquired with dma_buf_get by calling dma_buf_put().
+ *reference acquired with dma_buf_get() by calling dma_buf_put().
*
* For the detailed semantics exporters are expected to implement see
* &dma_buf_ops.
@@ -496,9 +496,10 @@ static struct file *dma_buf_getfile(struct dma_buf
*dmabuf, int flags)
* by the exporter. see &struct dma_buf_export_info
* for further details.
*
- * Returns, on success, a newly created dma_buf object, which wraps the
- * supplied private data and operations for dma_buf_ops. On either missing
- * ops, or error in allocating struct dma_buf, will return negative error.
+ * Returns, on success, a newly created struct dma_buf object, which wraps the
+ * supplied private data and operations for struct dma_buf_ops. On either
+ * missing ops, or error in allocating struct dma_buf, will return negative
+ * error.
*
* For most cases the easiest way to create @exp_info is through the
* %DEFINE_DMA_BUF_EXPORT_INFO macro.
@@ -584,7 +585,7 @@ struct dma_buf *dma_buf_export(const struct
dma_buf_export_info *exp_info)
EXPORT_SYMBOL_GPL(dma_buf_export);
/**
- * dma_buf_fd - returns a file descriptor for the given dma_buf
+ * dma_buf_fd - returns a file descriptor for the given struct dma_buf
* @dmabuf:[in]pointer to dma_buf for which fd is required.
* @flags: [in]flags to give to fd
*
@@ -608,10 +609,10 @@ int dma_buf_fd(struct dma_buf *dmabuf, int flags)
EXPORT_SYMBOL_GPL(dma_buf_fd);
/**
- * dma_buf_get - returns the dma_buf structure related to an fd
- * @fd:[in]fd associated with the dma_buf to be returned
+ * dma_buf_get - returns the struct dma_buf related to an fd
+ * @fd:[in]fd associated with the struct dma_buf to be returned
*
- * On success, returns the dma_buf structure associated with an fd; uses
+ * On success, returns the struct dma_buf associated with an fd; uses
* file's refcounting done by fget to increase refcount. returns ERR_PTR
* otherwise.
*/
@@ -653,8 +654,7 @@ void dma_buf_put(struct dma_buf *dmabuf)
EXPORT_SYMBOL_GPL(dma_buf_put);
/**
- * dma_buf_dynamic_attach - Add the device to dma_buf's attachments list;
optionally,
- * calls attach() of dma_buf_ops to allow device-specific attach functionality
+ * dma_buf_dynamic_attach - Add the device to dma_buf's attachments list
* @dmabuf:[in]buffer to attach device to.
* @dev: [in]device to be attached.
* @importer_ops: [in]importer operations for the attachment
@@ -663,6 +663,9 @@ EXPORT_SYMBOL_GPL(dma_buf_put);
* Returns struct dma_buf_attachment pointer for this attachment. Attachments
* must be cleaned up by calling dma_buf_detach().
*
+ * Optionally this calls &dma_buf_ops.attach to allow device-specific attach
+ * functionality.
+ *
* Returns:
*
* A pointer to newly created &dma_buf_attachment on success, or a negative
@@ -769,12 +772,13 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf
*dmabuf,
EXPORT_SYMBOL_GPL(dma_buf_attach);
/**
- * dma_buf_detach - Remove the given attachment from dmabuf's attachments list;
- * optionally calls detach() of dma_buf_ops for device-specific detach
+ * dma_buf_detach - Remove the given attachment from dmabuf's attachments list
* @dmabuf:[in]buffer to detach from.
* @attach:[in]attachment to be detached; is free'd after this call.
*
* Clean up a device attachment obtained by calling dma_buf_attach().
+ *
+ * Optionally this calls &dma_buf_ops.detach for device-specific detach.
*/
void dma_buf_detach(struct dma_buf *dmabuf, struct dma_buf_attachment *attach)
{
@@ -1061,11 +1065,12 @@ EXPORT_SYMBOL_GPL(dma_buf_move_notify);
* shootdowns would increase the complexity quite a bit.
*
* Interface::
+ *
* int dma_buf_mmap(struct dma_buf \*, struct vm_area_struct \*,
*unsigned long);
*
* If the importing subsystem simply provides a special-purpose mmap call to
- * set up a mapping in userspace, calling do_mmap with dma_buf->file will
+ * set up a mapping in userspace, calling do_m
[Intel-gfx] [PATCH 1/4] dma-buf: Remove kmap kerneldoc vestiges
Also try to clarify a bit when dma_buf_begin/end_cpu_access should
be called.
Signed-off-by: Daniel Vetter
Cc: Thomas Zimmermann
Cc: Sumit Semwal
Cc: "Christian König"
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
---
drivers/dma-buf/dma-buf.c | 20 ++--
include/linux/dma-buf.h | 25 +
2 files changed, 23 insertions(+), 22 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index e63684d4cd90..a12fdffa130f 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -1001,15 +1001,15 @@ EXPORT_SYMBOL_GPL(dma_buf_move_notify);
* vmalloc space might be limited and result in vmap calls failing.
*
* Interfaces::
+ *
* void \*dma_buf_vmap(struct dma_buf \*dmabuf)
* void dma_buf_vunmap(struct dma_buf \*dmabuf, void \*vaddr)
*
* The vmap call can fail if there is no vmap support in the exporter, or if
- * it runs out of vmalloc space. Fallback to kmap should be implemented. Note
- * that the dma-buf layer keeps a reference count for all vmap access and
- * calls down into the exporter's vmap function only when no vmapping exists,
- * and only unmaps it once. Protection against concurrent vmap/vunmap calls
is
- * provided by taking the dma_buf->lock mutex.
+ * it runs out of vmalloc space. Note that the dma-buf layer keeps a
reference
+ * count for all vmap access and calls down into the exporter's vmap function
+ * only when no vmapping exists, and only unmaps it once. Protection against
+ * concurrent vmap/vunmap calls is provided by taking the &dma_buf.lock
mutex.
*
* - For full compatibility on the importer side with existing userspace
* interfaces, which might already support mmap'ing buffers. This is needed
in
@@ -1098,6 +1098,11 @@ static int __dma_buf_begin_cpu_access(struct dma_buf
*dmabuf,
* dma_buf_end_cpu_access(). Only when cpu access is braketed by both calls is
* it guaranteed to be coherent with other DMA access.
*
+ * This function will also wait for any DMA transactions tracked through
+ * implicit synchronization in &dma_buf.resv. For DMA transactions with
explicit
+ * synchronization this function will only ensure cache coherency, callers must
+ * ensure synchronization with such DMA transactions on their own.
+ *
* Can return negative error values, returns 0 on success.
*/
int dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
@@ -1199,7 +1204,10 @@ EXPORT_SYMBOL_GPL(dma_buf_mmap);
* This call may fail due to lack of virtual mapping address space.
* These calls are optional in drivers. The intended use for them
* is for mapping objects linear in kernel space for high use objects.
- * Please attempt to use kmap/kunmap before thinking about these interfaces.
+ *
+ * To ensure coherency users must call dma_buf_begin_cpu_access() and
+ * dma_buf_end_cpu_access() around any cpu access performed through this
+ * mapping.
*
* Returns 0 on success, or a negative errno code otherwise.
*/
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index cf72699cb2bc..7eca37c8b10c 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -183,24 +183,19 @@ struct dma_buf_ops {
* @begin_cpu_access:
*
* This is called from dma_buf_begin_cpu_access() and allows the
-* exporter to ensure that the memory is actually available for cpu
-* access - the exporter might need to allocate or swap-in and pin the
-* backing storage. The exporter also needs to ensure that cpu access is
-* coherent for the access direction. The direction can be used by the
-* exporter to optimize the cache flushing, i.e. access with a different
+* exporter to ensure that the memory is actually coherent for cpu
+* access. The exporter also needs to ensure that cpu access is coherent
+* for the access direction. The direction can be used by the exporter
+* to optimize the cache flushing, i.e. access with a different
* direction (read instead of write) might return stale or even bogus
* data (e.g. when the exporter needs to copy the data to temporary
* storage).
*
-* This callback is optional.
+* Note that this is both called through the DMA_BUF_IOCTL_SYNC IOCTL
+* command for userspace mappings established through @mmap, and also
+* for kernel mappings established with @vmap.
*
-* FIXME: This is both called through the DMA_BUF_IOCTL_SYNC command
-* from userspace (where storage shouldn't be pinned to avoid handing
-* de-factor mlock rights to userspace) and for the kernel-internal
-* users of the various kmap interfaces, where the backing storage must
-* be pinned to guarantee that the atomic kmap calls can succeed. Since
-* there's no in-kernel users of the kmap interfaces yet this isn't a
-* real problem.
[Intel-gfx] ✗ Fi.CI.DOCS: warning for gpu: drm: i915: convert comma to semicolon
== Series Details == Series: gpu: drm: i915: convert comma to semicolon URL : https://patchwork.freedesktop.org/series/84845/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 Error: Cannot open file ./drivers/gpu/drm/i915/gt/intel_lrc.c WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -sphinx-version 1.7.9 -function Logical Rings, Logical Ring Contexts and Execlists ./drivers/gpu/drm/i915/gt/intel_lrc.c' failed with return code 1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.DOCS: warning for HDCP 2.2 and HDCP 1.4 Gen12 DP MST support (rev7)
== Series Details == Series: HDCP 2.2 and HDCP 1.4 Gen12 DP MST support (rev7) URL : https://patchwork.freedesktop.org/series/82998/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 Error: Cannot open file ./drivers/gpu/drm/i915/gt/intel_lrc.c WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -sphinx-version 1.7.9 -function Logical Rings, Logical Ring Contexts and Execlists ./drivers/gpu/drm/i915/gt/intel_lrc.c' failed with return code 1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for HDCP 2.2 and HDCP 1.4 Gen12 DP MST support (rev7)
== Series Details == Series: HDCP 2.2 and HDCP 1.4 Gen12 DP MST support (rev7) URL : https://patchwork.freedesktop.org/series/82998/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:257:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:261:49: error: static assertion failed: "amd_sriov_msg_pf2vf_info must be 1 KB" +drivers/gpu/drm/i915/gt/intel_reset.c:1310:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +drivers/gpu/drm/i915/gt/selftest_reset.c:100:20:expected void *in +drivers/gpu/drm/i915/gt/selftest_reset.c:100:20:got void [noderef] __iomem *[assigned] s +drivers/gpu/drm/i915/gt/selftest_reset.c:100:20: warning: incorrect type in assignment (different address spaces) +drivers/gpu/drm/i915/gt/selftest_reset.c:101:46:expected void const *src +drivers/gpu/drm/i915/gt/selftest_reset.c:101:46:got void [noderef] __iomem *[assigned] s +drivers/gpu/drm/i915/gt/selftest_reset.c:101:46: warning: incorrect type in argument 2 (different address spaces) +drivers/gpu/drm/i915/gt/selftest_reset.c:136:20:expected void *in +drivers/gpu/drm/i915/gt/selftest_reset.c:136:20:got void [noderef] __iomem *[assigned] s +drivers/gpu/drm/i915/gt/selftest_reset.c:136:20: warning: incorrect type in assignment (different address spaces) +drivers/gpu/drm/i915/gt/selftest_reset.c:137:46:expected void const *src +drivers/gpu/drm/i915/gt/selftest_reset.c:137:46:got void [noderef] __iomem *[assigned] s +drivers/gpu/drm/i915/gt/selftest_reset.c:137:46: warning: incorrect type in argument 2 (different address spaces) +drivers/gpu/drm/i915/gt/selftest_reset.c:98:34:expected unsigned int [usertype] *s +drivers/gpu/drm/i915/gt/selftest_reset.c:98:34:got void [noderef] __iomem *[assigned] s +drivers/gpu/drm/i915/gt/selftest_reset.c:98:34: warning: incorrect type in argument 1 (different address spaces) +drivers/gpu/drm/i915/gvt/mmio.c:295:23: warning: memcpy with byte count of 279040 +drivers/gpu/drm/i915/i915_perf.c:1448:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1502:15: warning: memset with byte count of 16777216 +./include/linux/seqlock.h:838:24: warning: trying to copy expression type 31 +./include/linux/seqlock.h:838:24: warning: trying to copy expression type 31 +./include/linux/seqlock.h:864:16: warning: trying to copy expression type 31 +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning
[Intel-gfx] [PATCH i-g-t v2] i915/perf_pmu: Verify RC6 measurements before/after suspend
RC6 should work before suspend, and continue to increment while idle
after suspend. Should.
v2: Include a longer sleep after suspend; it appears we are reticent to
idle so soon after waking up.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
tests/i915/perf_pmu.c | 42 ++
1 file changed, 34 insertions(+), 8 deletions(-)
diff --git a/tests/i915/perf_pmu.c b/tests/i915/perf_pmu.c
index cb7273142..389e7bf46 100644
--- a/tests/i915/perf_pmu.c
+++ b/tests/i915/perf_pmu.c
@@ -170,6 +170,7 @@ static unsigned int measured_usleep(unsigned int usec)
#define TEST_RUNTIME_PM (8)
#define FLAG_LONG (16)
#define FLAG_HANG (32)
+#define TEST_S3 (64)
static igt_spin_t * __spin_poll(int fd, uint32_t ctx,
const struct intel_execution_engine2 *e)
@@ -1578,7 +1579,7 @@ test_frequency_idle(int gem_fd)
"Actual frequency should be 0 while parked!\n");
}
-static bool wait_for_rc6(int fd)
+static bool wait_for_rc6(int fd, int timeout)
{
struct timespec tv = {};
uint64_t start, now;
@@ -1594,7 +1595,7 @@ static bool wait_for_rc6(int fd)
now = pmu_read_single(fd);
if (now - start > 1e6)
return true;
- } while (!igt_seconds_elapsed(&tv));
+ } while (igt_seconds_elapsed(&tv) <= timeout);
return false;
}
@@ -1636,15 +1637,37 @@ test_rc6(int gem_fd, unsigned int flags)
}
}
- igt_require(wait_for_rc6(fd));
+ igt_require(wait_for_rc6(fd, 1));
/* While idle check full RC6. */
- prev = __pmu_read_single(fd, &ts[0]);
- slept = measured_usleep(duration_ns / 1000);
- idle = __pmu_read_single(fd, &ts[1]);
- igt_debug("slept=%lu perf=%"PRIu64"\n", slept, ts[1] - ts[0]);
+ for (int pass = 0; pass < 3; pass++) {
+ prev = __pmu_read_single(fd, &ts[0]);
+ slept = measured_usleep(duration_ns / 1000);
+ idle = __pmu_read_single(fd, &ts[1]);
+
+ igt_debug("slept=%lu perf=%"PRIu64"\n", slept, ts[1] - ts[0]);
+ assert_within_epsilon(idle - prev, ts[1] - ts[0], tolerance);
+ }
+
+ if (flags & TEST_S3) {
+ prev = __pmu_read_single(fd, &ts[0]);
+ igt_system_suspend_autoresume(SUSPEND_STATE_MEM,
+ SUSPEND_TEST_NONE);
+ idle = __pmu_read_single(fd, &ts[1]);
+ igt_debug("suspend=%"PRIu64"\n", ts[1] - ts[0]);
+ //assert_within_epsilon(idle - prev, ts[1] - ts[0], tolerance);
+ }
- assert_within_epsilon(idle - prev, ts[1] - ts[0], tolerance);
+ igt_assert(wait_for_rc6(fd, 5));
+
+ for (int pass = 0; pass < 3; pass++) {
+ prev = __pmu_read_single(fd, &ts[0]);
+ slept = measured_usleep(duration_ns / 1000);
+ idle = __pmu_read_single(fd, &ts[1]);
+
+ igt_debug("slept=%lu perf=%"PRIu64"\n", slept, ts[1] - ts[0]);
+ assert_within_epsilon(idle - prev, ts[1] - ts[0], tolerance);
+ }
/* Wake up device and check no RC6. */
fw = igt_open_forcewake_handle(gem_fd);
@@ -2245,6 +2268,9 @@ igt_main
igt_subtest("rc6-runtime-pm-long")
test_rc6(fd, TEST_RUNTIME_PM | FLAG_LONG);
+ igt_subtest("rc6-suspend")
+ test_rc6(fd, TEST_S3);
+
/**
* Check render nodes are counted.
*/
--
2.29.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 4/5] drm/dp: Extract i915's eDP backlight code into DRM helpers
On Wed, 09 Dec 2020, Lyude Paul wrote:
> Since we're about to implement eDP backlight support in nouveau using the
> standard protocol from VESA, we might as well just take the code that's
> already written for this and move it into a set of shared DRM helpers.
>
> Note that these helpers are intended to handle DPCD related backlight
> control bits such as setting the brightness level over AUX, probing the
> backlight's TCON, enabling/disabling the backlight over AUX if supported,
> etc. Any PWM-related portions of backlight control are explicitly left up
> to the driver, as these will vary from platform to platform.
>
> The only exception to this is the calculation of the PWM frequency
> pre-divider value. This is because the only platform-specific information
> required for this is the PWM frequency of the panel, which the driver is
> expected to provide if available. The actual algorithm for calculating this
> value is standard and is defined in the eDP specification from VESA.
>
> Note that these helpers do not yet implement the full range of features
> the VESA backlight interface provides, and only provide the following
> functionality (all of which was already present in i915's DPCD backlight
> support):
>
> * Basic control of brightness levels
> * Basic probing of backlight capabilities
> * Helpers for enabling and disabling the backlight
Overall I like where this is going. Again, not a full review yet, just a
few notes below.
>
> Signed-off-by: Lyude Paul
> Cc: Jani Nikula
> Cc: Dave Airlie
> Cc: greg.depo...@gmail.com
> ---
> drivers/gpu/drm/drm_dp_helper.c | 332 ++
> .../drm/i915/display/intel_display_types.h| 5 +-
> .../drm/i915/display/intel_dp_aux_backlight.c | 304 ++--
> include/drm/drm_dp_helper.h | 48 +++
> 4 files changed, 419 insertions(+), 270 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 5bd0934004e3..06fdddf44e54 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -2596,3 +2596,335 @@ void drm_dp_vsc_sdp_log(const char *level, struct
> device *dev,
> #undef DP_SDP_LOG
> }
> EXPORT_SYMBOL(drm_dp_vsc_sdp_log);
> +
> +/**
> + * drm_edp_backlight_set_level() - Set the backlight level of an eDP panel
> via AUX
> + * @aux: The DP AUX channel to use
> + * @bl: Backlight capability info from drm_edp_backlight_init()
> + * @level: The brightness level to set
> + *
> + * Sets the brightness level of an eDP panel's backlight. Note that the
> panel's backlight must
> + * already have been enabled by the driver by calling
> drm_edp_backlight_enable().
> + *
> + * Returns: %0 on success, negative error code on failure
> + */
> +int drm_edp_backlight_set_level(struct drm_dp_aux *aux, const struct
> drm_edp_backlight_info *bl,
> + u16 level)
I think I'd go for s/backlight/brightness/g function naming thoughout,
to account for OLED. "Backlight" unnecessarily underlines the
technology.
> +{
> + int ret;
> + u8 buf[2] = { 0 };
> +
> + if (bl->lsb_reg_used) {
> + buf[0] = (level & 0xFF00) >> 8;
> + buf[1] = (level & 0x00FF);
> + } else {
> + buf[0] = level;
> + }
> +
> + ret = drm_dp_dpcd_write(aux, DP_EDP_BACKLIGHT_BRIGHTNESS_MSB, buf,
> sizeof(buf));
> + if (ret != sizeof(buf)) {
> + DRM_ERROR("%s: Failed to write aux backlight level: %d\n",
> aux->name, ret);
I'd really like to have a way to get from struct drm_dp_aux to struct
drm_device to retain the device specific logging here. It'd be useful in
the lower level dpcd access functions too.
> + return ret < 0 ? ret : -EIO;
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_edp_backlight_set_level);
> +
> +static int
> +drm_edp_backlight_set_enable(struct drm_dp_aux *aux, const struct
> drm_edp_backlight_info *bl,
> + bool enable)
> +{
> + int ret;
> + u8 buf;
> +
> + /* The panel uses something other then DPCD for enabling it's backlight
> */
> + if (!bl->aux_enable)
> + return 0;
> +
> + ret = drm_dp_dpcd_readb(aux, DP_EDP_DISPLAY_CONTROL_REGISTER, &buf);
> + if (ret != 1) {
> + DRM_ERROR("%s: Failed to read eDP display control register:
> %d\n", aux->name, ret);
> + return ret < 0 ? ret : -EIO;
> + }
> + if (enable)
> + buf |= DP_EDP_BACKLIGHT_ENABLE;
> + else
> + buf &= ~DP_EDP_BACKLIGHT_ENABLE;
> +
> + ret = drm_dp_dpcd_writeb(aux, DP_EDP_DISPLAY_CONTROL_REGISTER, buf);
> + if (ret != 1) {
> + DRM_ERROR("%s: Failed to write eDP display control register:
> %d\n", aux->name, ret);
> + return ret < 0 ? ret : -EIO;
> + }
> +
> + return 0;
> +}
> +
> +/**
> + * drm_edp_backlight_enable() - Enable an eDP panel's backlight using DPCD
> + * @aux: The DP AUX channel to use
> + * @bl: Ba
Re: [Intel-gfx] [RFC 3/5] drm/i915/dp: Remove redundant AUX backlight frequency calculations
On Wed, 09 Dec 2020, Lyude Paul wrote:
> Noticed this while moving all of the VESA backlight code in i915 over to
> DRM helpers: it would appear that we calculate the frequency value we want
> to write to DP_EDP_BACKLIGHT_FREQ_SET twice even though this value never
> actually changes during runtime. So, let's simplify things by just caching
> this value in intel_panel.backlight, and re-writing it as-needed.
This isn't a full review, just something I spotted so far. Please see
inline.
BR,
Jani.
>
> Signed-off-by: Lyude Paul
> Cc: Jani Nikula
> Cc: Dave Airlie
> Cc: greg.depo...@gmail.com
> ---
> .../drm/i915/display/intel_display_types.h| 1 +
> .../drm/i915/display/intel_dp_aux_backlight.c | 64 ++-
> 2 files changed, 19 insertions(+), 46 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 5bc5bfbc4551..133c9cb742a7 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -259,6 +259,7 @@ struct intel_panel {
>
> /* DPCD backlight */
> u8 pwmgen_bit_count;
> + u8 pwm_freq_pre_divider;
>
> struct backlight_device *device;
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> index 4fd536801b14..94ce5ca1affa 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> @@ -129,50 +129,6 @@ intel_dp_aux_set_backlight(const struct
> drm_connector_state *conn_state, u32 lev
> }
> }
>
> -/*
> - * Set PWM Frequency divider to match desired frequency in vbt.
> - * The PWM Frequency is calculated as 27Mhz / (F x P).
> - * - Where F = PWM Frequency Pre-Divider value programmed by field 7:0 of the
> - * EDP_BACKLIGHT_FREQ_SET register (DPCD Address 00728h)
> - * - Where P = 2^Pn, where Pn is the value programmed by field 4:0 of the
> - * EDP_PWMGEN_BIT_COUNT register (DPCD Address 00724h)
> - */
> -static bool intel_dp_aux_set_pwm_freq(struct intel_connector *connector)
> -{
> - struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> - struct intel_dp *intel_dp = intel_attached_dp(connector);
> - const u8 pn = connector->panel.backlight.pwmgen_bit_count;
> - int freq, fxp, f, fxp_actual, fxp_min, fxp_max;
> -
> - freq = dev_priv->vbt.backlight.pwm_freq_hz;
> - if (!freq) {
> - drm_dbg_kms(&dev_priv->drm,
> - "Use panel default backlight frequency\n");
> - return false;
> - }
> -
> - fxp = DIV_ROUND_CLOSEST(KHz(DP_EDP_BACKLIGHT_FREQ_BASE_KHZ), freq);
> - f = clamp(DIV_ROUND_CLOSEST(fxp, 1 << pn), 1, 255);
> - fxp_actual = f << pn;
> -
> - /* Ensure frequency is within 25% of desired value */
> - fxp_min = DIV_ROUND_CLOSEST(fxp * 3, 4);
> - fxp_max = DIV_ROUND_CLOSEST(fxp * 5, 4);
> -
> - if (fxp_min > fxp_actual || fxp_actual > fxp_max) {
> - drm_dbg_kms(&dev_priv->drm, "Actual frequency out of range\n");
> - return false;
> - }
> -
> - if (drm_dp_dpcd_writeb(&intel_dp->aux,
> -DP_EDP_BACKLIGHT_FREQ_SET, (u8) f) < 0) {
> - drm_dbg_kms(&dev_priv->drm,
> - "Failed to write aux backlight freq\n");
> - return false;
> - }
> - return true;
> -}
> -
> static void intel_dp_aux_enable_backlight(const struct intel_crtc_state
> *crtc_state,
> const struct drm_connector_state
> *conn_state)
> {
> @@ -213,9 +169,13 @@ static void intel_dp_aux_enable_backlight(const struct
> intel_crtc_state *crtc_st
> break;
> }
>
> - if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_FREQ_AUX_SET_CAP)
> - if (intel_dp_aux_set_pwm_freq(connector))
> + if (panel->backlight.pwm_freq_pre_divider) {
> + if (drm_dp_dpcd_writeb(&intel_dp->aux,
> DP_EDP_BACKLIGHT_FREQ_SET,
> +panel->backlight.pwm_freq_pre_divider)
> == 1)
> new_dpcd_buf |= DP_EDP_BACKLIGHT_FREQ_AUX_SET_ENABLE;
> + else
> + drm_dbg_kms(&i915->drm, "Failed to write aux backlight
> frequency\n");
> + }
>
> if (new_dpcd_buf != dpcd_buf) {
> if (drm_dp_dpcd_writeb(&intel_dp->aux,
> @@ -236,6 +196,14 @@ static void intel_dp_aux_disable_backlight(const struct
> drm_connector_state *old
>false);
> }
>
> +/*
> + * Compute PWM frequency divider value based off the frequency provided to
> us by the vbt.
> + * The PWM Frequency is calculated as 27Mhz / (F x P).
> + * - Where F = PWM Frequency Pre-Divider value programmed by field 7:0 of the
> + * EDP_BACKLIGHT_FREQ_SET register (DPCD
[Intel-gfx] [PATCH i-g-t] i915/perf_pmu: Verify RC6 measurements before/after suspend
RC6 should work before suspend, and continue to increment while idle
after suspend. Should.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
tests/i915/perf_pmu.c | 36 +++-
1 file changed, 31 insertions(+), 5 deletions(-)
diff --git a/tests/i915/perf_pmu.c b/tests/i915/perf_pmu.c
index cb7273142..29119b236 100644
--- a/tests/i915/perf_pmu.c
+++ b/tests/i915/perf_pmu.c
@@ -170,6 +170,7 @@ static unsigned int measured_usleep(unsigned int usec)
#define TEST_RUNTIME_PM (8)
#define FLAG_LONG (16)
#define FLAG_HANG (32)
+#define TEST_S3 (64)
static igt_spin_t * __spin_poll(int fd, uint32_t ctx,
const struct intel_execution_engine2 *e)
@@ -1639,12 +1640,34 @@ test_rc6(int gem_fd, unsigned int flags)
igt_require(wait_for_rc6(fd));
/* While idle check full RC6. */
- prev = __pmu_read_single(fd, &ts[0]);
- slept = measured_usleep(duration_ns / 1000);
- idle = __pmu_read_single(fd, &ts[1]);
- igt_debug("slept=%lu perf=%"PRIu64"\n", slept, ts[1] - ts[0]);
+ for (int pass = 0; pass < 3; pass++) {
+ prev = __pmu_read_single(fd, &ts[0]);
+ slept = measured_usleep(duration_ns / 1000);
+ idle = __pmu_read_single(fd, &ts[1]);
+
+ igt_debug("slept=%lu perf=%"PRIu64"\n", slept, ts[1] - ts[0]);
+ assert_within_epsilon(idle - prev, ts[1] - ts[0], tolerance);
+ }
+
+ if (flags & TEST_S3) {
+ prev = __pmu_read_single(fd, &ts[0]);
+ igt_system_suspend_autoresume(SUSPEND_STATE_MEM,
+ SUSPEND_TEST_NONE);
+ idle = __pmu_read_single(fd, &ts[1]);
+ igt_debug("suspend=%"PRIu64"\n", ts[1] - ts[0]);
+ //assert_within_epsilon(idle - prev, ts[1] - ts[0], tolerance);
+ }
- assert_within_epsilon(idle - prev, ts[1] - ts[0], tolerance);
+ igt_assert(wait_for_rc6(fd));
+
+ for (int pass = 0; pass < 3; pass++) {
+ prev = __pmu_read_single(fd, &ts[0]);
+ slept = measured_usleep(duration_ns / 1000);
+ idle = __pmu_read_single(fd, &ts[1]);
+
+ igt_debug("slept=%lu perf=%"PRIu64"\n", slept, ts[1] - ts[0]);
+ assert_within_epsilon(idle - prev, ts[1] - ts[0], tolerance);
+ }
/* Wake up device and check no RC6. */
fw = igt_open_forcewake_handle(gem_fd);
@@ -2245,6 +2268,9 @@ igt_main
igt_subtest("rc6-runtime-pm-long")
test_rc6(fd, TEST_RUNTIME_PM | FLAG_LONG);
+ igt_subtest("rc6-suspend")
+ test_rc6(fd, TEST_S3);
+
/**
* Check render nodes are counted.
*/
--
2.29.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [patch 27/30] xen/events: Only force affinity mask for percpu interrupts
On 12/10/20 2:26 PM, Thomas Gleixner wrote: > All event channel setups bind the interrupt on CPU0 or the target CPU for > percpu interrupts and overwrite the affinity mask with the corresponding > cpumask. That does not make sense. > > The XEN implementation of irqchip::irq_set_affinity() already picks a > single target CPU out of the affinity mask and the actual target is stored > in the effective CPU mask, so destroying the user chosen affinity mask > which might contain more than one CPU is wrong. > > Change the implementation so that the channel is bound to CPU0 at the XEN > level and leave the affinity mask alone. At startup of the interrupt > affinity will be assigned out of the affinity mask and the XEN binding will > be updated. If that's the case then I wonder whether we need this call at all and instead bind at startup time. -boris > Only keep the enforcement for real percpu interrupts. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [patch 12/30] s390/irq: Use irq_desc_kstat_cpu() in show_msi_interrupt()
On Thu, Dec 10, 2020 at 08:25:48PM +0100, Thomas Gleixner wrote: > The irq descriptor is already there, no need to look it up again. > > Signed-off-by: Thomas Gleixner > Cc: Christian Borntraeger > Cc: Heiko Carstens > Cc: linux-s...@vger.kernel.org > --- > arch/s390/kernel/irq.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Acked-by: Heiko Carstens ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH -next] gpu: drm: i915: convert comma to semicolon
Replace a comma between expression statements by a semicolon. Signed-off-by: Zheng Yongjun --- drivers/gpu/drm/i915/display/intel_hdmi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c b/drivers/gpu/drm/i915/display/intel_hdmi.c index 3f2008d845c2..9737a8604fc7 100644 --- a/drivers/gpu/drm/i915/display/intel_hdmi.c +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c @@ -1323,8 +1323,8 @@ static int intel_hdmi_hdcp_write(struct intel_digital_port *dig_port, memcpy(&write_buf[1], buffer, size); msg.addr = DRM_HDCP_DDC_ADDR; - msg.flags = 0, - msg.len = size + 1, + msg.flags = 0; + msg.len = size + 1; msg.buf = write_buf; ret = i2c_transfer(adapter, &msg, 1); -- 2.22.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [patch 24/30] xen/events: Remove unused bind_evtchn_to_irq_lateeoi()
On 12/10/20 2:26 PM, Thomas Gleixner wrote:
> Signed-off-by: Thomas Gleixner
> Cc: Boris Ostrovsky
> Cc: Juergen Gross
> Cc: Stefano Stabellini
> Cc: xen-de...@lists.xenproject.org
> ---
> drivers/xen/events/events_base.c |6 --
> 1 file changed, 6 deletions(-)
>
> --- a/drivers/xen/events/events_base.c
> +++ b/drivers/xen/events/events_base.c
> @@ -1132,12 +1132,6 @@ int bind_evtchn_to_irq(evtchn_port_t evt
> }
> EXPORT_SYMBOL_GPL(bind_evtchn_to_irq);
>
> -int bind_evtchn_to_irq_lateeoi(evtchn_port_t evtchn)
> -{
> - return bind_evtchn_to_irq_chip(evtchn, &xen_lateeoi_chip);
> -}
> -EXPORT_SYMBOL_GPL(bind_evtchn_to_irq_lateeoi);
include/xen/events.h also needs to be updated (and in the next patch for
xen_set_affinity_evtchn() as well).
-boris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [patch 14/30] drm/i915/pmu: Replace open coded kstat_irqs() copy
From: Thomas Gleixner > Sent: 11 December 2020 12:58 .. > > After my failed hasty sketch from last night I had a different one which > > was kind of heuristics based (re-reading the upper dword and retrying if > > it changed on 32-bit). > > The problem is that there will be two seperate modifications for the low > and high word. Several ways how the compiler can translate this, but the > problem is the same for all of them: > > CPU 0 CPU 1 > load low > load high > add low, 1 > addc high, 0 > store low load high > --> NMI load low > load high and compare > store high > > You can't catch that. If this really becomes an issue you need a > sequence counter around it. Or just two copies of the high word. Provided the accesses are sequenced: writer: load high:low add small_value,high:low store high store low store high_copy reader: load high_copy load low load high if (high != high_copy) low = 0; The read value is always stale, so it probably doesn't matter that the value you have is one that is between the value when you started and that when you finished. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [patch 27/30] xen/events: Only force affinity mask for percpu interrupts
On 11.12.20 11:13, Thomas Gleixner wrote:
On Fri, Dec 11 2020 at 07:17, Jürgen Groß wrote:
On 11.12.20 00:20, boris.ostrov...@oracle.com wrote:
On 12/10/20 2:26 PM, Thomas Gleixner wrote:
All event channel setups bind the interrupt on CPU0 or the target CPU for
percpu interrupts and overwrite the affinity mask with the corresponding
cpumask. That does not make sense.
The XEN implementation of irqchip::irq_set_affinity() already picks a
single target CPU out of the affinity mask and the actual target is stored
in the effective CPU mask, so destroying the user chosen affinity mask
which might contain more than one CPU is wrong.
Change the implementation so that the channel is bound to CPU0 at the XEN
level and leave the affinity mask alone. At startup of the interrupt
affinity will be assigned out of the affinity mask and the XEN binding will
be updated.
If that's the case then I wonder whether we need this call at all and instead
bind at startup time.
This binding to cpu0 was introduced with commit 97253eeeb792d61ed2
and I have no reason to believe the underlying problem has been
eliminated.
"The kernel-side VCPU binding was not being correctly set for newly
allocated or bound interdomain events. In ARM guests where 2-level
events were used, this would result in no interdomain events being
handled because the kernel-side VCPU masks would all be clear.
x86 guests would work because the irq affinity was set during irq
setup and this would set the correct kernel-side VCPU binding."
I'm not convinced that this is really correctly analyzed because affinity
setting is done at irq startup.
switch (__irq_startup_managed(desc, aff, force)) {
case IRQ_STARTUP_NORMAL:
ret = __irq_startup(desc);
irq_setup_affinity(desc);
break;
which is completely architecture agnostic. So why should this magically
work on x86 and not on ARM if both are using the same XEN irqchip with
the same irqchip callbacks.
I think this might be related to _initial_ cpu binding of events and
changing the binding later. This might be handled differently in the
hypervisor.
Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/1] drm/i915/dp: optimize pps_lock wherever required
On Fri, 04 Dec 2020, Anshuman Gupta wrote:
> Reading backlight status from PPS register doesn't require
> AUX power on the platform which has South Display Engine on PCH.
> It invokes a unnecessary power well enable/disable noise.
> optimize it wherever is possible.
Three aspects here:
1. What's the root cause for the glitches, really? AFAICT this is still
an open question, judging from the discussion in previous versions.
2. See why we end up here in the first place for brightness
updates. It's a long story (*), but maybe the fix isn't to optimize this
path, but to avoid calling this function for regular brightness updates
to begin with?
3. The implementation here seems like a hack, to be honest. Considering
the points above, it really has a bad vibe of papering over something
else.
BR,
Jani.
(*)
It was a Chrome OS requirement originally to be able to quickly switch
off backlight through the backlight sysfs interface, without switching
off the display through the KMS API. For whatever reason. We can't just
set the PWM to 0, because that may an invalid thing to do on some boards
out there. (On some device it ended up pulling other lanes on the eDP
connector to 0 V, but I digress.)
So the hack is we have a way to switch the eDP power sequencer backlight
bit off/on, as a substate of enabled backlight, through using the
backlight sysfs to set the brightness to 0 or using bl_power.
>
> Signed-off-by: Anshuman Gupta
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 47 +++--
> 1 file changed, 45 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 2d4d5e95af84..7e18e4ff50f4 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -892,6 +892,47 @@ pps_unlock(struct intel_dp *intel_dp, intel_wakeref_t
> wakeref)
> return 0;
> }
>
> +/*
> + * Platform with PCH based SDE doesn't require to enable AUX power
> + * for simple PPS register access like whether backlight is enabled.
> + * use pch_pps_lock()/pch_pps_unlock() wherever we don't require
> + * aux power to avoid unnecessary power well enable/disable back
> + * and forth.
> + */
> +static intel_wakeref_t
> +pch_pps_lock(struct intel_dp *intel_dp)
> +{
> + struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> + intel_wakeref_t wakeref;
> +
> + if (!HAS_PCH_SPLIT(dev_priv))
> + wakeref = intel_display_power_get(dev_priv,
> +
> intel_aux_power_domain(dp_to_dig_port(intel_dp)));
> + else
> + wakeref = intel_runtime_pm_get(&dev_priv->runtime_pm);
> +
> + mutex_lock(&dev_priv->pps_mutex);
> +
> + return wakeref;
> +}
> +
> +static intel_wakeref_t
> +pch_pps_unlock(struct intel_dp *intel_dp, intel_wakeref_t wakeref)
> +{
> + struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> +
> + mutex_unlock(&dev_priv->pps_mutex);
> +
> + if (!HAS_PCH_SPLIT(dev_priv))
> + intel_display_power_put(dev_priv,
> +
> intel_aux_power_domain(dp_to_dig_port(intel_dp)),
> + wakeref);
> + else
> + intel_runtime_pm_put(&dev_priv->runtime_pm, wakeref);
> +
> + return 0;
> +}
> +
> #define with_pps_lock(dp, wf) \
> for ((wf) = pps_lock(dp); (wf); (wf) = pps_unlock((dp), (wf)))
>
> @@ -3453,8 +3494,10 @@ static void intel_edp_backlight_power(struct
> intel_connector *connector,
> bool is_enabled;
>
> is_enabled = false;
> - with_pps_lock(intel_dp, wakeref)
> - is_enabled = ilk_get_pp_control(intel_dp) & EDP_BLC_ENABLE;
> + wakeref = pch_pps_lock(intel_dp);
> + is_enabled = ilk_get_pp_control(intel_dp) & EDP_BLC_ENABLE;
> + pch_pps_unlock(intel_dp, wakeref);
> +
> if (is_enabled == enable)
> return;
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v8 19/19] drm/i915/hdcp: Enable HDCP 2.2 MST support
Enable HDCP 2.2 MST support till Gen12. Cc: Ramalingam C Tested-by: Karthik B S Signed-off-by: Anshuman Gupta --- drivers/gpu/drm/i915/display/intel_hdcp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c b/drivers/gpu/drm/i915/display/intel_hdcp.c index 768a6218b9c4..20c8d8f63566 100644 --- a/drivers/gpu/drm/i915/display/intel_hdcp.c +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c @@ -2233,7 +2233,7 @@ int intel_hdcp_init(struct intel_connector *connector, if (!shim) return -EINVAL; - if (is_hdcp2_supported(dev_priv) && !connector->mst_port) + if (is_hdcp2_supported(dev_priv)) intel_hdcp2_init(connector, dig_port, shim); ret = -- 2.26.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v8 18/19] drm/i915/hdcp: Configure HDCP2.2 MST steram encryption status
Authenticate and enable port encryption only once for
an active HDCP 2.2 session, once port is authenticated
and encrypted enable encryption for each stream that
requires encryption on this port.
Similarly disable the stream encryption for each encrypted
stream, once all encrypted stream encryption is disabled,
disable the port HDCP encryption and deauthenticate the port.
v2:
- Add connector details in drm_err. [Ram]
- 's/port_auth/hdcp_auth_status'. [Ram]
- Added a debug print for stream enc.
v3:
- uniformity for connector detail in DMESG. [Ram]
Cc: Ramalingam C
Reviewed-by: Uma Shankar
Tested-by: Karthik B S
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 51 ++-
1 file changed, 50 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 2fd8b0453b1d..768a6218b9c4 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -1700,6 +1700,36 @@ static int hdcp2_authenticate_sink(struct
intel_connector *connector)
return ret;
}
+static int hdcp2_enable_stream_encryption(struct intel_connector *connector)
+{
+ struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
+ struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+ struct intel_hdcp *hdcp = &connector->hdcp;
+ enum transcoder cpu_transcoder = hdcp->cpu_transcoder;
+ enum port port = dig_port->base.port;
+ int ret = 0;
+
+ if (!(intel_de_read(dev_priv, HDCP2_STATUS(dev_priv, cpu_transcoder,
port)) &
+ LINK_ENCRYPTION_STATUS)) {
+ drm_err(&dev_priv->drm, "[%s:%d] HDCP 2.2 Link is not
encrypted\n",
+ connector->base.name, connector->base.base.id);
+ return -EPERM;
+ }
+
+ if (hdcp->shim->stream_2_2_encryption) {
+ ret = hdcp->shim->stream_2_2_encryption(connector, true);
+ if (ret) {
+ drm_err(&dev_priv->drm, "[%s:%d] Failed to enable HDCP
2.2 stream enc\n",
+ connector->base.name, connector->base.base.id);
+ return ret;
+ }
+ drm_dbg_kms(&dev_priv->drm, "HDCP 2.2 transcoder: %s stream
encrypted\n",
+ transcoder_name(hdcp->stream_transcoder));
+ }
+
+ return ret;
+}
+
static int hdcp2_enable_encryption(struct intel_connector *connector)
{
struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
@@ -1838,7 +1868,7 @@ static int hdcp2_authenticate_and_encrypt(struct
intel_connector *connector)
drm_dbg_kms(&i915->drm, "Port deauth failed.\n");
}
- if (!ret) {
+ if (!ret && !dig_port->hdcp_auth_status) {
/*
* Ensuring the required 200mSec min time interval between
* Session Key Exchange and encryption.
@@ -1853,6 +1883,8 @@ static int hdcp2_authenticate_and_encrypt(struct
intel_connector *connector)
}
}
+ ret = hdcp2_enable_stream_encryption(connector);
+
return ret;
}
@@ -1898,11 +1930,26 @@ static int _intel_hdcp2_disable(struct intel_connector
*connector)
struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
struct drm_i915_private *i915 = to_i915(connector->base.dev);
struct hdcp_port_data *data = &dig_port->hdcp_port_data;
+ struct intel_hdcp *hdcp = &connector->hdcp;
int ret;
drm_dbg_kms(&i915->drm, "[%s:%d] HDCP2.2 is being Disabled\n",
connector->base.name, connector->base.base.id);
+ if (hdcp->shim->stream_2_2_encryption) {
+ ret = hdcp->shim->stream_2_2_encryption(connector, false);
+ if (ret) {
+ drm_err(&i915->drm, "[%s:%d] Failed to disable HDCP 2.2
stream enc\n",
+ connector->base.name, connector->base.base.id);
+ return ret;
+ }
+ drm_dbg_kms(&i915->drm, "HDCP 2.2 transcoder: %s stream
encryption disabled\n",
+ transcoder_name(hdcp->stream_transcoder));
+ }
+
+ if (dig_port->num_hdcp_streams > 0)
+ return ret;
+
ret = hdcp2_disable_encryption(connector);
if (hdcp2_deauthenticate_port(connector) < 0)
@@ -1926,6 +1973,7 @@ static int intel_hdcp2_check_link(struct intel_connector
*connector)
int ret = 0;
mutex_lock(&hdcp->mutex);
+ mutex_lock(&dig_port->hdcp_mutex);
cpu_transcoder = hdcp->cpu_transcoder;
/* hdcp2_check_link is expected only when HDCP2.2 is Enabled */
@@ -2003,6 +2051,7 @@ static int intel_hdcp2_check_link(struct intel_connector
*connector)
}
out:
+ mutex_unlock(&dig_port->hdcp_mutex);
[Intel-gfx] [PATCH v8 17/19] drm/i915/hdcp: Support for HDCP 2.2 MST shim callbacks
Add support for HDCP 2.2 DP MST shim callback.
This adds existing DP HDCP shim callback for Link Authentication
and Encryption and HDCP 2.2 stream encryption
callback.
v2:
- Added a WARN_ON() instead of drm_err. [Uma]
- Cosmetic changes. [Uma]
v3:
- 's/port_data/hdcp_port_data' [Ram]
- skip redundant link check. [Ram]
v4:
- use pipe instead of port to access HDCP2_STREAM_STATUS
Cc: Ramalingam C
Reviewed-by: Uma Shankar
Tested-by: Karthik B S
Signed-off-by: Anshuman Gupta
---
.../drm/i915/display/intel_display_types.h| 4 +
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 89 +--
2 files changed, 85 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 63de25b40eff..da91e3f4ff27 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -378,6 +378,10 @@ struct intel_hdcp_shim {
int (*config_stream_type)(struct intel_digital_port *dig_port,
bool is_repeater, u8 type);
+ /* Enable/Disable HDCP 2.2 stream encryption on DP MST Transport Link */
+ int (*stream_2_2_encryption)(struct intel_connector *connector,
+bool enable);
+
/* HDCP2.2 Link Integrity Check */
int (*check_2_2_link)(struct intel_digital_port *dig_port,
struct intel_connector *connector);
diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
index 9ade1ad3a80c..f372e25edab4 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
@@ -698,18 +698,14 @@ intel_dp_mst_hdcp_stream_encryption(struct
intel_connector *connector,
return 0;
}
-static
-bool intel_dp_mst_hdcp_check_link(struct intel_digital_port *dig_port,
- struct intel_connector *connector)
+static bool intel_dp_mst_get_qses_status(struct intel_digital_port *dig_port,
+struct intel_connector *connector)
{
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
- struct intel_dp *intel_dp = &dig_port->dp;
struct drm_dp_query_stream_enc_status_ack_reply reply;
+ struct intel_dp *intel_dp = &dig_port->dp;
int ret;
- if (!intel_dp_hdcp_check_link(dig_port, connector))
- return false;
-
ret = drm_dp_send_query_stream_enc_status(&intel_dp->mst_mgr,
connector->port, &reply);
if (ret) {
@@ -726,6 +722,78 @@ bool intel_dp_mst_hdcp_check_link(struct
intel_digital_port *dig_port,
return reply.auth_completed && reply.encryption_enabled;
}
+static
+bool intel_dp_mst_hdcp_check_link(struct intel_digital_port *dig_port,
+ struct intel_connector *connector)
+{
+ if (!intel_dp_hdcp_check_link(dig_port, connector))
+ return false;
+
+ return intel_dp_mst_get_qses_status(dig_port, connector);
+}
+
+static int
+intel_dp_mst_hdcp2_stream_encryption(struct intel_connector *connector,
+bool enable)
+{
+ struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
+ struct drm_i915_private *i915 = to_i915(connector->base.dev);
+ struct hdcp_port_data *data = &dig_port->hdcp_port_data;
+ struct intel_hdcp *hdcp = &connector->hdcp;
+ enum transcoder cpu_transcoder = hdcp->stream_transcoder;
+ enum pipe pipe = (enum pipe)cpu_transcoder;
+ enum port port = dig_port->base.port;
+ int ret;
+
+ drm_WARN_ON(&i915->drm, enable &&
+ !!(intel_de_read(i915, HDCP2_AUTH_STREAM(i915,
cpu_transcoder, port))
+ & AUTH_STREAM_TYPE) != data->streams[0].stream_type);
+
+ ret = intel_dp_mst_toggle_hdcp_stream_select(connector, enable);
+ if (ret)
+ return ret;
+
+ /* Wait for encryption confirmation */
+ if (intel_de_wait_for_register(i915,
+ HDCP2_STREAM_STATUS(i915,
cpu_transcoder, pipe),
+ STREAM_ENCRYPTION_STATUS,
+ enable ? STREAM_ENCRYPTION_STATUS : 0,
+ HDCP_ENCRYPT_STATUS_CHANGE_TIMEOUT_MS)) {
+ drm_err(&i915->drm, "Timed out waiting for transcoder: %s
stream encryption %s\n",
+ transcoder_name(cpu_transcoder), enable ? "enabled" :
"disabled");
+ return -ETIMEDOUT;
+ }
+
+ return 0;
+}
+
+/*
+ * DP v2.0 I.3.3 ignore the stream signature L' in QSES reply msg reply.
+ * I.3.5 MST source device may use a QSES msg to query downstream status
+ * for a particular stream.
+ */
+static
+int intel_dp_mst_hdcp2_check_link(struct intel_digita
[Intel-gfx] [PATCH v8 16/19] drm/i915/hdcp: Add HDCP 2.2 stream register
Add HDCP 2.2 DP MST HDCP2_STREAM_STATUS
and HDCP2_AUTH_STREAM register in i915_reg header.
B.Spec: 21780
B.Spec: 14410
B.Spec: 50573
v2
- Modified naming convention of HDCP2_STREAM_STATUS
for pre-gen12 platforms inline with B.Spec.
Cc: Ramalingam C
Reviewed-by: Uma Shankar
Reviewed-by: Ramalingam C
Tested-by: Karthik B S
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/i915_reg.h | 39 +
1 file changed, 39 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index b448e507d41e..cade0a7a97b2 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -9873,6 +9873,7 @@ enum skl_power_gate {
_PORTD_HDCP2_BASE, \
_PORTE_HDCP2_BASE, \
_PORTF_HDCP2_BASE) + (x))
+
#define PORT_HDCP2_AUTH(port) _PORT_HDCP2_BASE(port, 0x98)
#define _TRANSA_HDCP2_AUTH 0x66498
#define _TRANSB_HDCP2_AUTH 0x66598
@@ -9912,6 +9913,44 @@ enum skl_power_gate {
TRANS_HDCP2_STATUS(trans) : \
PORT_HDCP2_STATUS(port))
+#define _PIPEA_HDCP2_STREAM_STATUS 0x668C0
+#define _PIPEB_HDCP2_STREAM_STATUS 0x665C0
+#define _PIPEC_HDCP2_STREAM_STATUS 0x666C0
+#define _PIPED_HDCP2_STREAM_STATUS 0x667C0
+#define PIPE_HDCP2_STREAM_STATUS(pipe) _MMIO(_PICK((pipe), \
+
_PIPEA_HDCP2_STREAM_STATUS, \
+
_PIPEB_HDCP2_STREAM_STATUS, \
+
_PIPEC_HDCP2_STREAM_STATUS, \
+
_PIPED_HDCP2_STREAM_STATUS))
+
+#define _TRANSA_HDCP2_STREAM_STATUS0x664C0
+#define _TRANSB_HDCP2_STREAM_STATUS0x665C0
+#define TRANS_HDCP2_STREAM_STATUS(trans) _MMIO_TRANS(trans, \
+
_TRANSA_HDCP2_STREAM_STATUS, \
+ _TRANSB_HDCP2_STREAM_STATUS)
+#define STREAM_ENCRYPTION_STATUS BIT(31)
+#define STREAM_TYPE_STATUS BIT(30)
+#define HDCP2_STREAM_STATUS(dev_priv, trans, port) \
+ (INTEL_GEN(dev_priv) >= 12 ? \
+TRANS_HDCP2_STREAM_STATUS(trans) : \
+PIPE_HDCP2_STREAM_STATUS(pipe))
+
+#define _PORTA_HDCP2_AUTH_STREAM 0x66F00
+#define _PORTB_HDCP2_AUTH_STREAM 0x66F04
+#define PORT_HDCP2_AUTH_STREAM(port) _MMIO_PORT(port, \
+ _PORTA_HDCP2_AUTH_STREAM, \
+ _PORTB_HDCP2_AUTH_STREAM)
+#define _TRANSA_HDCP2_AUTH_STREAM 0x66F00
+#define _TRANSB_HDCP2_AUTH_STREAM 0x66F04
+#define TRANS_HDCP2_AUTH_STREAM(trans) _MMIO_TRANS(trans, \
+ _TRANSA_HDCP2_AUTH_STREAM, \
+ _TRANSB_HDCP2_AUTH_STREAM)
+#define AUTH_STREAM_TYPE BIT(31)
+#define HDCP2_AUTH_STREAM(dev_priv, trans, port) \
+ (INTEL_GEN(dev_priv) >= 12 ? \
+TRANS_HDCP2_AUTH_STREAM(trans) : \
+PORT_HDCP2_AUTH_STREAM(port))
+
/* Per-pipe DDI Function Control */
#define _TRANS_DDI_FUNC_CTL_A 0x60400
#define _TRANS_DDI_FUNC_CTL_B 0x61400
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v8 15/19] drm/i915/hdcp: Pass connector to check_2_2_link
This requires for HDCP 2.2 MST check link.
As for DP/HDMI shims check_2_2_link retrieves the connector
from dig_port, this is not sufficient or DP MST connector,
there can be multiple DP MST topology connector associated
with same dig_port.
Cc: Ramalingam C
Reviewed-by: Uma Shankar
Reviewed-by: Ramalingam C
Tested-by: Karthik B S
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_display_types.h | 3 ++-
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 3 ++-
drivers/gpu/drm/i915/display/intel_hdcp.c | 2 +-
drivers/gpu/drm/i915/display/intel_hdmi.c | 3 ++-
4 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index b37a02a73de6..63de25b40eff 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -379,7 +379,8 @@ struct intel_hdcp_shim {
bool is_repeater, u8 type);
/* HDCP2.2 Link Integrity Check */
- int (*check_2_2_link)(struct intel_digital_port *dig_port);
+ int (*check_2_2_link)(struct intel_digital_port *dig_port,
+ struct intel_connector *connector);
};
struct intel_hdcp {
diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
index 3f23f8b53dcd..9ade1ad3a80c 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
@@ -585,7 +585,8 @@ int intel_dp_hdcp2_config_stream_type(struct
intel_digital_port *dig_port,
}
static
-int intel_dp_hdcp2_check_link(struct intel_digital_port *dig_port)
+int intel_dp_hdcp2_check_link(struct intel_digital_port *dig_port,
+ struct intel_connector *connector)
{
u8 rx_status;
int ret;
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index e26a63f0c189..2fd8b0453b1d 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -1947,7 +1947,7 @@ static int intel_hdcp2_check_link(struct intel_connector
*connector)
goto out;
}
- ret = hdcp->shim->check_2_2_link(dig_port);
+ ret = hdcp->shim->check_2_2_link(dig_port, connector);
if (ret == HDCP_LINK_PROTECTED) {
if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
intel_hdcp_update_value(connector,
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 25d76460f8f9..977e6b6c35c7 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -1733,7 +1733,8 @@ int intel_hdmi_hdcp2_read_msg(struct intel_digital_port
*dig_port,
}
static
-int intel_hdmi_hdcp2_check_link(struct intel_digital_port *dig_port)
+int intel_hdmi_hdcp2_check_link(struct intel_digital_port *dig_port,
+ struct intel_connector *connector)
{
u8 rx_status[HDCP_2_2_HDMI_RXSTATUS_LEN];
int ret;
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v8 14/19] drm/i915/hdcp: MST streams support in hdcp port_data
Add support for multiple mst stream in hdcp port data
which will be used by RepeaterAuthStreamManage msg and
HDCP 2.2 security f/w for m' validation.
Security f/w doesn't have any provision to mark the stream_type
for each stream separately, it just take single input of
stream_type while authenticating the port and applies the
same stream_type to all streams. So driver mark each stream_type
with common highest supported content type for all streams
in DP MST Topology.
Security f/w supports RepeaterAuthStreamManage msg and m'
validation only once during port authentication and encryption.
Though it is not compulsory, security fw should support dynamic
update of content_type and should support RepeaterAuthStreamManage
msg and m' validation whenever required.
v2:
- Init the hdcp port data k for HDMI/DP SST stream.
v3:
- Cosmetic changes. [Uma]
v4:
- 's/port_auth/hdcp_port_auth'. [Ram]
- Commit log improvement.
v5:
- Comment and commit log improvement. [Ram]
Cc: Ramalingam C
Reviewed-by: Uma Shankar
Reviewed-by: Ramalingam C
Tested-by: Karthik B S
Signed-off-by: Anshuman Gupta
---
.../drm/i915/display/intel_display_types.h| 4 +-
drivers/gpu/drm/i915/display/intel_hdcp.c | 113 +++---
2 files changed, 102 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index b74c10c8b01c..b37a02a73de6 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1502,10 +1502,12 @@ struct intel_digital_port {
enum phy_fia tc_phy_fia;
u8 tc_phy_fia_idx;
- /* protects num_hdcp_streams reference count, hdcp_port_data */
+ /* protects num_hdcp_streams reference count, hdcp_port_data and
hdcp_auth_status */
struct mutex hdcp_mutex;
/* the number of pipes using HDCP signalling out of this port */
unsigned int num_hdcp_streams;
+ /* port HDCP auth status */
+ bool hdcp_auth_status;
/* HDCP port data need to pass to security f/w */
struct hdcp_port_data hdcp_port_data;
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 2bec26123a05..e26a63f0c189 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -26,6 +26,74 @@
#define KEY_LOAD_TRIES 5
#define HDCP2_LC_RETRY_CNT 3
+static int intel_conn_to_vcpi(struct intel_connector *connector)
+{
+ /* For HDMI this is forced to be 0x0. For DP SST also this is 0x0. */
+ return connector->port ? connector->port->vcpi.vcpi : 0;
+}
+
+/*
+ * intel_hdcp_required_content_stream selects the most highest common possible
HDCP
+ * content_type for all streams in DP MST topology because security f/w doesn't
+ * have any provision to mark content_type for each stream separately, it marks
+ * all available streams with the content_type proivided at the time of port
+ * authentication. This may prohibit the userspace to use type1 content on
+ * HDCP 2.2 capable sink because of other sink are not capable of HDCP 2.2 in
+ * DP MST topology. Though it is not compulsory, security fw should change its
+ * policy to mark different content_types for different streams.
+ */
+static int
+intel_hdcp_required_content_stream(struct intel_digital_port *dig_port)
+{
+ struct drm_connector_list_iter conn_iter;
+ struct intel_digital_port *conn_dig_port;
+ struct intel_connector *connector;
+ struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
+ struct hdcp_port_data *data = &dig_port->hdcp_port_data;
+ bool enforce_type0 = false;
+ int k;
+
+ if (dig_port->hdcp_auth_status)
+ return 0;
+
+ drm_connector_list_iter_begin(&i915->drm, &conn_iter);
+ for_each_intel_connector_iter(connector, &conn_iter) {
+ if (!intel_encoder_is_mst(intel_attached_encoder(connector)))
+ continue;
+
+ conn_dig_port = intel_attached_dig_port(connector);
+ if (conn_dig_port != dig_port)
+ continue;
+
+ if (connector->base.status == connector_status_disconnected)
+ continue;
+
+ if (!enforce_type0 && !intel_hdcp2_capable(connector))
+ enforce_type0 = true;
+
+ data->streams[data->k].stream_id =
intel_conn_to_vcpi(connector);
+ data->k++;
+
+ /* if there is only one active stream */
+ if (dig_port->dp.active_mst_links <= 1)
+ break;
+ }
+ drm_connector_list_iter_end(&conn_iter);
+
+ if (drm_WARN_ON(&i915->drm, data->k > INTEL_NUM_PIPES(i915) || data->k
== 0))
+ return -EINVAL;
+
+ /*
+* Apply common protection level across all streams in DP MST Topology.
+* Use
[Intel-gfx] [PATCH v8 13/19] drm/hdcp: Max MST content streams
Let's define Maximum MST content streams up to four generically which can be supported by modern display controllers. Cc: Sean Paul Cc: Ramalingam C Acked-by: Maarten Lankhorst Reviewed-by: Uma Shankar Reviewed-by: Ramalingam C Tested-by: Karthik B S Signed-off-by: Anshuman Gupta --- include/drm/drm_hdcp.h | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h index fe58dbb46962..ac22c246542a 100644 --- a/include/drm/drm_hdcp.h +++ b/include/drm/drm_hdcp.h @@ -101,11 +101,11 @@ /* Following Macros take a byte at a time for bit(s) masking */ /* - * TODO: This has to be changed for DP MST, as multiple stream on - * same port is possible. - * For HDCP2.2 on HDMI and DP SST this value is always 1. + * TODO: HDCP_2_2_MAX_CONTENT_STREAMS_CNT is based upon actual + * H/W MST streams capacity. + * This required to be moved out to platform specific header. */ -#define HDCP_2_2_MAX_CONTENT_STREAMS_CNT 1 +#define HDCP_2_2_MAX_CONTENT_STREAMS_CNT 4 #define HDCP_2_2_TXCAP_MASK_LEN2 #define HDCP_2_2_RXCAPS_LEN3 #define HDCP_2_2_RX_REPEATER(x)((x) & BIT(0)) -- 2.26.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v8 12/19] misc/mei/hdcp: Fix AUTH_STREAM_REQ cmd buffer len
Fix the size of WIRED_REPEATER_AUTH_STREAM_REQ cmd buffer size. It is based upon the actual number of MST streams and size of wired_cmd_repeater_auth_stream_req_in. Excluding the size of hdcp_cmd_header. v2: - hdcp_cmd_header size annotation nitpick. [Tomas] Cc: Tomas Winkler Cc: Ramalingam C Acked-by: Tomas Winkler Reviewed-by: Uma Shankar Reviewed-by: Ramalingam C Tested-by: Karthik B S Signed-off-by: Anshuman Gupta --- drivers/misc/mei/hdcp/mei_hdcp.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c index 9ae9669e46ea..3506a3534294 100644 --- a/drivers/misc/mei/hdcp/mei_hdcp.c +++ b/drivers/misc/mei/hdcp/mei_hdcp.c @@ -569,8 +569,7 @@ static int mei_hdcp_verify_mprime(struct device *dev, verify_mprime_in->header.api_version = HDCP_API_VERSION; verify_mprime_in->header.command_id = WIRED_REPEATER_AUTH_STREAM_REQ; verify_mprime_in->header.status = ME_HDCP_STATUS_SUCCESS; - verify_mprime_in->header.buffer_len = - WIRED_CMD_BUF_LEN_REPEATER_AUTH_STREAM_REQ_MIN_IN; + verify_mprime_in->header.buffer_len = cmd_size - sizeof(verify_mprime_in->header); verify_mprime_in->port.integrated_port_type = data->port_type; verify_mprime_in->port.physical_port = (u8)data->fw_ddi; -- 2.26.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v8 11/19] drm/i915/hdcp: Encapsulate hdcp_port_data to dig_port
hdcp_port_data is specific to a port on which HDCP
encryption is getting enabled, so encapsulate it to
intel_digital_port.
This will be required to enable HDCP 2.2 stream encryption.
v2:
- 's/port_data/hdcp_port_data'. [Ram]
Cc: Ramalingam C
Reviewed-by: Uma Shankar
Reviewed-by: Ramalingam C
Tested-by: Karthik B S
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_ddi.c | 2 +
.../drm/i915/display/intel_display_types.h| 5 +-
drivers/gpu/drm/i915/display/intel_hdcp.c | 56 +++
3 files changed, 39 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 046c49931b98..54418a6cc3d4 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -4965,6 +4965,8 @@ static void intel_ddi_encoder_destroy(struct drm_encoder
*encoder)
intel_dp_encoder_flush_work(encoder);
drm_encoder_cleanup(encoder);
+ if (dig_port)
+ kfree(dig_port->hdcp_port_data.streams);
kfree(dig_port);
}
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index f0aeba9a222a..b74c10c8b01c 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -406,7 +406,6 @@ struct intel_hdcp {
* content can flow only through a link protected by HDCP2.2.
*/
u8 content_type;
- struct hdcp_port_data port_data;
bool is_paired;
bool is_repeater;
@@ -1503,10 +1502,12 @@ struct intel_digital_port {
enum phy_fia tc_phy_fia;
u8 tc_phy_fia_idx;
- /* protects num_hdcp_streams reference count */
+ /* protects num_hdcp_streams reference count, hdcp_port_data */
struct mutex hdcp_mutex;
/* the number of pipes using HDCP signalling out of this port */
unsigned int num_hdcp_streams;
+ /* HDCP port data need to pass to security f/w */
+ struct hdcp_port_data hdcp_port_data;
void (*write_infoframe)(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state,
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 4ad086e7ec3c..2bec26123a05 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -15,6 +15,7 @@
#include
#include
+#include "i915_drv.h"
#include "i915_reg.h"
#include "intel_display_power.h"
#include "intel_display_types.h"
@@ -1025,7 +1026,8 @@ static int
hdcp2_prepare_ake_init(struct intel_connector *connector,
struct hdcp2_ake_init *ake_data)
{
- struct hdcp_port_data *data = &connector->hdcp.port_data;
+ struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
+ struct hdcp_port_data *data = &dig_port->hdcp_port_data;
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct i915_hdcp_comp_master *comp;
int ret;
@@ -1054,7 +1056,8 @@ hdcp2_verify_rx_cert_prepare_km(struct intel_connector
*connector,
struct hdcp2_ake_no_stored_km *ek_pub_km,
size_t *msg_sz)
{
- struct hdcp_port_data *data = &connector->hdcp.port_data;
+ struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
+ struct hdcp_port_data *data = &dig_port->hdcp_port_data;
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct i915_hdcp_comp_master *comp;
int ret;
@@ -1081,7 +1084,8 @@ hdcp2_verify_rx_cert_prepare_km(struct intel_connector
*connector,
static int hdcp2_verify_hprime(struct intel_connector *connector,
struct hdcp2_ake_send_hprime *rx_hprime)
{
- struct hdcp_port_data *data = &connector->hdcp.port_data;
+ struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
+ struct hdcp_port_data *data = &dig_port->hdcp_port_data;
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct i915_hdcp_comp_master *comp;
int ret;
@@ -1106,7 +1110,8 @@ static int
hdcp2_store_pairing_info(struct intel_connector *connector,
struct hdcp2_ake_send_pairing_info *pairing_info)
{
- struct hdcp_port_data *data = &connector->hdcp.port_data;
+ struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
+ struct hdcp_port_data *data = &dig_port->hdcp_port_data;
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct i915_hdcp_comp_master *comp;
int ret;
@@ -1132,7 +1137,8 @@ static int
hdcp2_prepare_lc_init(struct intel_connector *connector,
struct hdcp2_lc_init *lc_init)
{
- struct hdcp_port_data *data = &conn
[Intel-gfx] [PATCH v8 10/19] drm/i915/hdcp: Pass dig_port to intel_hdcp_init
Pass dig_port as an argument to intel_hdcp_init()
and intel_hdcp2_init().
This will be required for HDCP 2.2 stream encryption.
Cc: Ramalingam C
Reviewed-by: Uma Shankar
Reviewed-by: Ramalingam C
Tested-by: Karthik B S
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 4 ++--
drivers/gpu/drm/i915/display/intel_hdcp.c| 12 +++-
drivers/gpu/drm/i915/display/intel_hdcp.h| 4 +++-
drivers/gpu/drm/i915/display/intel_hdmi.c| 2 +-
4 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
index 94c5462fa037..3f23f8b53dcd 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
@@ -755,10 +755,10 @@ int intel_dp_init_hdcp(struct intel_digital_port
*dig_port,
return 0;
if (intel_connector->mst_port)
- return intel_hdcp_init(intel_connector, port,
+ return intel_hdcp_init(intel_connector, dig_port,
&intel_dp_mst_hdcp_shim);
else if (!intel_dp_is_edp(intel_dp))
- return intel_hdcp_init(intel_connector, port,
+ return intel_hdcp_init(intel_connector, dig_port,
&intel_dp_hdcp_shim);
return 0;
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index fce444d69521..4ad086e7ec3c 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -1979,12 +1979,13 @@ static enum mei_fw_tc intel_get_mei_fw_tc(enum
transcoder cpu_transcoder)
}
static int initialize_hdcp_port_data(struct intel_connector *connector,
-enum port port,
+struct intel_digital_port *dig_port,
const struct intel_hdcp_shim *shim)
{
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct intel_hdcp *hdcp = &connector->hdcp;
struct hdcp_port_data *data = &hdcp->port_data;
+ enum port port = dig_port->base.port;
if (INTEL_GEN(dev_priv) < 12)
data->fw_ddi = intel_get_mei_fw_ddi_index(port);
@@ -2057,14 +2058,15 @@ void intel_hdcp_component_init(struct drm_i915_private
*dev_priv)
}
}
-static void intel_hdcp2_init(struct intel_connector *connector, enum port port,
+static void intel_hdcp2_init(struct intel_connector *connector,
+struct intel_digital_port *dig_port,
const struct intel_hdcp_shim *shim)
{
struct drm_i915_private *i915 = to_i915(connector->base.dev);
struct intel_hdcp *hdcp = &connector->hdcp;
int ret;
- ret = initialize_hdcp_port_data(connector, port, shim);
+ ret = initialize_hdcp_port_data(connector, dig_port, shim);
if (ret) {
drm_dbg_kms(&i915->drm, "Mei hdcp data init failed\n");
return;
@@ -2074,7 +2076,7 @@ static void intel_hdcp2_init(struct intel_connector
*connector, enum port port,
}
int intel_hdcp_init(struct intel_connector *connector,
- enum port port,
+ struct intel_digital_port *dig_port,
const struct intel_hdcp_shim *shim)
{
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
@@ -2085,7 +2087,7 @@ int intel_hdcp_init(struct intel_connector *connector,
return -EINVAL;
if (is_hdcp2_supported(dev_priv) && !connector->mst_port)
- intel_hdcp2_init(connector, port, shim);
+ intel_hdcp2_init(connector, dig_port, shim);
ret =
drm_connector_attach_content_protection_property(&connector->base,
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.h
b/drivers/gpu/drm/i915/display/intel_hdcp.h
index b912a3a0f5b8..8f53b0c7fe5c 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.h
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.h
@@ -18,13 +18,15 @@ struct intel_connector;
struct intel_crtc_state;
struct intel_encoder;
struct intel_hdcp_shim;
+struct intel_digital_port;
enum port;
enum transcoder;
void intel_hdcp_atomic_check(struct drm_connector *connector,
struct drm_connector_state *old_state,
struct drm_connector_state *new_state);
-int intel_hdcp_init(struct intel_connector *connector, enum port port,
+int intel_hdcp_init(struct intel_connector *connector,
+ struct intel_digital_port *dig_port,
const struct intel_hdcp_shim *hdcp_shim);
int intel_hdcp_enable(struct intel_connector *connector,
const struct intel_crtc_state *pipe_config, u8
content_type);
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index e072
[Intel-gfx] [PATCH v8 09/19] drm/i915/hdcp: Enable Gen12 HDCP 1.4 DP MST support
Enable HDCP 1.4 over DP MST for Gen12.
v2:
- Enable HDCP for <= Gen12 platforms. [Ram]
v3:
- Connector detials in debug msg. [Ram]
Cc: Ramalingam C
Reviewed-by: Ramalingam C
Tested-by: Karthik B S
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_dp_mst.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 47beb442094f..f76e2c2a83b8 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -829,12 +829,11 @@ static struct drm_connector
*intel_dp_add_mst_connector(struct drm_dp_mst_topolo
intel_attach_force_audio_property(connector);
intel_attach_broadcast_rgb_property(connector);
-
- /* TODO: Figure out how to make HDCP work on GEN12+ */
- if (INTEL_GEN(dev_priv) < 12) {
+ if (INTEL_GEN(dev_priv) <= 12) {
ret = intel_dp_init_hdcp(dig_port, intel_connector);
if (ret)
- DRM_DEBUG_KMS("HDCP init failed, skipping.\n");
+ drm_dbg_kms(&dev_priv->drm, "[%s:%d] HDCP MST init
failed, skipping.\n",
+ connector->name, connector->base.id);
}
/*
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v8 08/19] drm/i915/hdcp: Configure HDCP1.4 MST steram encryption status
Enable HDCP 1.4 DP MST stream encryption.
Enable stream encryption once encryption is enabled on
the DP transport driving the link for each stream which
has requested encryption.
Disable stream encryption for each stream that no longer
requires encryption before disabling HDCP encryption on
the link.
v2:
- Added debug print for stream encryption.
- Disable the hdcp on port after disabling last stream
encryption.
v3:
- Cosmetic change, removed the value less comment. [Uma]
v4:
- Split the Gen12 HDCP enablement patch. [Ram]
- Add connector details in drm_err.
v5:
- uniformity for connector detail in DMESG. [Ram]
- comments improvement. [Ram]
Cc: Ramalingam C
Reviewed-by: Uma Shankar
Reviewed-by: Ramalingam C
Tested-by: Karthik B S
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 38 +++
1 file changed, 25 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 6e6465b4ecfa..fce444d69521 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -766,10 +766,17 @@ static int intel_hdcp_auth(struct intel_connector
*connector)
return -ETIMEDOUT;
}
- /*
-* XXX: If we have MST-connected devices, we need to enable encryption
-* on those as well.
-*/
+ /* DP MST Auth Part 1 Step 2.a and Step 2.b */
+ if (shim->stream_encryption) {
+ ret = shim->stream_encryption(connector, true);
+ if (ret) {
+ drm_err(&dev_priv->drm, "[%s:%d] Failed to enable HDCP
1.4 stream enc\n",
+ connector->base.name, connector->base.base.id);
+ return ret;
+ }
+ drm_dbg_kms(&dev_priv->drm, "HDCP 1.4 transcoder: %s stream
encrypted\n",
+ transcoder_name(hdcp->stream_transcoder));
+ }
if (repeater_present)
return intel_hdcp_auth_downstream(connector);
@@ -791,18 +798,23 @@ static int _intel_hdcp_disable(struct intel_connector
*connector)
drm_dbg_kms(&dev_priv->drm, "[%s:%d] HDCP is being disabled...\n",
connector->base.name, connector->base.base.id);
+ if (hdcp->shim->stream_encryption) {
+ ret = hdcp->shim->stream_encryption(connector, false);
+ if (ret) {
+ drm_err(&dev_priv->drm, "[%s:%d] Failed to disable HDCP
1.4 stream enc\n",
+ connector->base.name, connector->base.base.id);
+ return ret;
+ }
+ drm_dbg_kms(&dev_priv->drm, "HDCP 1.4 transcoder: %s stream
encryption disabled\n",
+ transcoder_name(hdcp->stream_transcoder));
+ }
+
/*
-* If there are other connectors on this port using HDCP, don't disable
-* it. Instead, toggle the HDCP signalling off on that particular
-* connector/pipe and exit.
+* If there are other connectors on this port using HDCP, don't disable
it
+* until it disabled HDCP encryption for all connectors in MST topology.
*/
- if (dig_port->num_hdcp_streams > 0) {
- ret = hdcp->shim->toggle_signalling(dig_port,
- cpu_transcoder, false);
- if (ret)
- DRM_ERROR("Failed to disable HDCP signalling\n");
+ if (dig_port->num_hdcp_streams > 0)
return ret;
- }
hdcp->hdcp_encrypted = false;
intel_de_write(dev_priv, HDCP_CONF(dev_priv, cpu_transcoder, port), 0);
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v8 07/19] drm/i915/hdcp: HDCP stream encryption support
Both HDCP_{1.x,2.x} requires to select/deselect Multistream HDCP bit
in TRANS_DDI_FUNC_CTL in order to enable/disable stream HDCP
encryption over DP MST Transport Link.
HDCP 1.4 stream encryption requires to validate the stream encryption
status in HDCP_STATUS_{TRANSCODER,PORT} register driving that link
in order to enable/disable the stream encryption.
Both of above requirement are same for all Gen with respect to
B.Spec Documentation.
v2:
- Cosmetic changes function name, error msg print and
stream typo fixes. [Uma]
v3:
- uniformity for connector detail in DMESG. [Ram]
Cc: Ramalingam C
Reviewed-by: Uma Shankar
Reviewed-by: Ramalingam C
Tested-by: Karthik B S
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_ddi.c | 10 +--
drivers/gpu/drm/i915/display/intel_ddi.h | 6 +-
.../drm/i915/display/intel_display_types.h| 4 +
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 90 ---
drivers/gpu/drm/i915/display/intel_hdmi.c | 14 +--
drivers/gpu/drm/i915/i915_reg.h | 1 +
6 files changed, 97 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 14c2c0a15464..046c49931b98 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -2029,9 +2029,9 @@ void intel_ddi_disable_transcoder_func(const struct
intel_crtc_state *crtc_state
}
}
-int intel_ddi_toggle_hdcp_signalling(struct intel_encoder *intel_encoder,
-enum transcoder cpu_transcoder,
-bool enable)
+int intel_ddi_toggle_hdcp_bits(struct intel_encoder *intel_encoder,
+ enum transcoder cpu_transcoder,
+ bool enable, u32 hdcp_mask)
{
struct drm_device *dev = intel_encoder->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
@@ -2046,9 +2046,9 @@ int intel_ddi_toggle_hdcp_signalling(struct intel_encoder
*intel_encoder,
tmp = intel_de_read(dev_priv, TRANS_DDI_FUNC_CTL(cpu_transcoder));
if (enable)
- tmp |= TRANS_DDI_HDCP_SIGNALLING;
+ tmp |= hdcp_mask;
else
- tmp &= ~TRANS_DDI_HDCP_SIGNALLING;
+ tmp &= ~hdcp_mask;
intel_de_write(dev_priv, TRANS_DDI_FUNC_CTL(cpu_transcoder), tmp);
intel_display_power_put(dev_priv, intel_encoder->power_domain, wakeref);
return ret;
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.h
b/drivers/gpu/drm/i915/display/intel_ddi.h
index dcc711cfe4fe..a4dd815c 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.h
+++ b/drivers/gpu/drm/i915/display/intel_ddi.h
@@ -50,9 +50,9 @@ u32 bxt_signal_levels(struct intel_dp *intel_dp,
const struct intel_crtc_state *crtc_state);
u32 ddi_signal_levels(struct intel_dp *intel_dp,
const struct intel_crtc_state *crtc_state);
-int intel_ddi_toggle_hdcp_signalling(struct intel_encoder *intel_encoder,
-enum transcoder cpu_transcoder,
-bool enable);
+int intel_ddi_toggle_hdcp_bits(struct intel_encoder *intel_encoder,
+ enum transcoder cpu_transcoder,
+ bool enable, u32 hdcp_mask);
void icl_sanitize_encoder_pll_mapping(struct intel_encoder *encoder);
#endif /* __INTEL_DDI_H__ */
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 729a9792051f..f0aeba9a222a 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -343,6 +343,10 @@ struct intel_hdcp_shim {
enum transcoder cpu_transcoder,
bool enable);
+ /* Enable/Disable stream encryption on DP MST Transport Link */
+ int (*stream_encryption)(struct intel_connector *connector,
+bool enable);
+
/* Ensures the link is still protected */
bool (*check_link)(struct intel_digital_port *dig_port,
struct intel_connector *connector);
diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
index 03424d20e9f7..94c5462fa037 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
@@ -16,6 +16,30 @@
#include "intel_dp.h"
#include "intel_hdcp.h"
+static unsigned int transcoder_to_stream_enc_status(enum transcoder
cpu_transcoder)
+{
+ u32 stream_enc_mask;
+
+ switch (cpu_transcoder) {
+ case TRANSCODER_A:
+ stream_enc_mask = HDCP_STATUS_STREAM_A_ENC;
+ break;
+ case TRANSCODER_B:
+ stream_enc_mask = HDCP_STATUS_STREAM_B_ENC;
+ break;
+ case TRAN
[Intel-gfx] [PATCH v8 06/19] drm/i915/hdcp: Move HDCP enc status timeout to header
DP MST stream encryption status requires time of a link frame
in order to change its status, but as there were some HDCP
encryption timeout observed earlier, it is safer to use
ENCRYPT_STATUS_CHANGE_TIMEOUT_MS timeout for stream status too,
it requires to move the macro to a header.
It will be used by both HDCP{1.x,2.x} stream status timeout.
Related: 'commit 7e90e8d0c0ea ("drm/i915: Increase timeout for Encrypt
status change")'
Cc: Ramalingam C
Reviewed-by: Uma Shankar
Reviewed-by: Ramalingam C
Tested-by: Karthik B S
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 9 -
drivers/gpu/drm/i915/display/intel_hdcp.h | 2 ++
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 293f72d1d215..6e6465b4ecfa 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -23,7 +23,6 @@
#include "intel_connector.h"
#define KEY_LOAD_TRIES 5
-#define ENCRYPT_STATUS_CHANGE_TIMEOUT_MS 50
#define HDCP2_LC_RETRY_CNT 3
static
@@ -762,7 +761,7 @@ static int intel_hdcp_auth(struct intel_connector
*connector)
if (intel_de_wait_for_set(dev_priv,
HDCP_STATUS(dev_priv, cpu_transcoder, port),
HDCP_STATUS_ENC,
- ENCRYPT_STATUS_CHANGE_TIMEOUT_MS)) {
+ HDCP_ENCRYPT_STATUS_CHANGE_TIMEOUT_MS)) {
drm_err(&dev_priv->drm, "Timed out waiting for encryption\n");
return -ETIMEDOUT;
}
@@ -809,7 +808,7 @@ static int _intel_hdcp_disable(struct intel_connector
*connector)
intel_de_write(dev_priv, HDCP_CONF(dev_priv, cpu_transcoder, port), 0);
if (intel_de_wait_for_clear(dev_priv,
HDCP_STATUS(dev_priv, cpu_transcoder, port),
- ~0, ENCRYPT_STATUS_CHANGE_TIMEOUT_MS)) {
+ ~0, HDCP_ENCRYPT_STATUS_CHANGE_TIMEOUT_MS))
{
drm_err(&dev_priv->drm,
"Failed to disable HDCP, timeout clearing status\n");
return -ETIMEDOUT;
@@ -1641,7 +1640,7 @@ static int hdcp2_enable_encryption(struct intel_connector
*connector)
HDCP2_STATUS(dev_priv, cpu_transcoder,
port),
LINK_ENCRYPTION_STATUS,
- ENCRYPT_STATUS_CHANGE_TIMEOUT_MS);
+ HDCP_ENCRYPT_STATUS_CHANGE_TIMEOUT_MS);
return ret;
}
@@ -1665,7 +1664,7 @@ static int hdcp2_disable_encryption(struct
intel_connector *connector)
HDCP2_STATUS(dev_priv, cpu_transcoder,
port),
LINK_ENCRYPTION_STATUS,
- ENCRYPT_STATUS_CHANGE_TIMEOUT_MS);
+ HDCP_ENCRYPT_STATUS_CHANGE_TIMEOUT_MS);
if (ret == -ETIMEDOUT)
drm_dbg_kms(&dev_priv->drm, "Disable Encryption Timedout");
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.h
b/drivers/gpu/drm/i915/display/intel_hdcp.h
index bc51c1e9b481..b912a3a0f5b8 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.h
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.h
@@ -8,6 +8,8 @@
#include
+#define HDCP_ENCRYPT_STATUS_CHANGE_TIMEOUT_MS 50
+
struct drm_connector;
struct drm_connector_state;
struct drm_i915_private;
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v8 05/19] drm/i915/hdcp: DP MST transcoder for link and stream
Gen12 has H/W delta with respect to HDCP{1.x,2.x} display engine
instances lies in Transcoder instead of DDI as in Gen11.
This requires hdcp driver to use mst_master_transcoder for link
authentication and stream transcoder for stream encryption
separately.
This will be used for both HDCP 1.4 and HDCP 2.2 over DP MST
on Gen12.
Cc: Ramalingam C
Reviewed-by: Uma Shankar
Reviewed-by: Ramalingam C
Tested-by: Karthik B S
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_ddi.c | 2 +-
.../gpu/drm/i915/display/intel_display_types.h| 2 ++
drivers/gpu/drm/i915/display/intel_dp_mst.c | 2 +-
drivers/gpu/drm/i915/display/intel_hdcp.c | 15 +++
drivers/gpu/drm/i915/display/intel_hdcp.h | 2 +-
5 files changed, 16 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 6863236df1d0..14c2c0a15464 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -4252,7 +4252,7 @@ static void intel_enable_ddi(struct intel_atomic_state
*state,
if (conn_state->content_protection ==
DRM_MODE_CONTENT_PROTECTION_DESIRED)
intel_hdcp_enable(to_intel_connector(conn_state->connector),
- crtc_state->cpu_transcoder,
+ crtc_state,
(u8)conn_state->hdcp_content_type);
}
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 5bc5bfbc4551..729a9792051f 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -436,6 +436,8 @@ struct intel_hdcp {
* Hence caching the transcoder here.
*/
enum transcoder cpu_transcoder;
+ /* Only used for DP MST stream encryption */
+ enum transcoder stream_transcoder;
};
struct intel_connector {
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 27f04aed8764..47beb442094f 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -569,7 +569,7 @@ static void intel_mst_enable_dp(struct intel_atomic_state
*state,
if (conn_state->content_protection ==
DRM_MODE_CONTENT_PROTECTION_DESIRED)
intel_hdcp_enable(to_intel_connector(conn_state->connector),
- pipe_config->cpu_transcoder,
+ pipe_config,
(u8)conn_state->hdcp_content_type);
}
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 7d63e9495956..293f72d1d215 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -2095,7 +2095,7 @@ int intel_hdcp_init(struct intel_connector *connector,
}
int intel_hdcp_enable(struct intel_connector *connector,
- enum transcoder cpu_transcoder, u8 content_type)
+ const struct intel_crtc_state *pipe_config, u8
content_type)
{
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
@@ -2117,10 +2117,17 @@ int intel_hdcp_enable(struct intel_connector *connector,
drm_WARN_ON(&dev_priv->drm,
hdcp->value == DRM_MODE_CONTENT_PROTECTION_ENABLED);
hdcp->content_type = content_type;
- hdcp->cpu_transcoder = cpu_transcoder;
+
+ if (intel_crtc_has_type(pipe_config, INTEL_OUTPUT_DP_MST)) {
+ hdcp->cpu_transcoder = pipe_config->mst_master_transcoder;
+ hdcp->stream_transcoder = pipe_config->cpu_transcoder;
+ } else {
+ hdcp->cpu_transcoder = pipe_config->cpu_transcoder;
+ hdcp->stream_transcoder = INVALID_TRANSCODER;
+ }
if (INTEL_GEN(dev_priv) >= 12)
- hdcp->port_data.fw_tc = intel_get_mei_fw_tc(cpu_transcoder);
+ hdcp->port_data.fw_tc =
intel_get_mei_fw_tc(hdcp->cpu_transcoder);
/*
* Considering that HDCP2.2 is more secure than HDCP1.4, If the setup
@@ -2240,7 +2247,7 @@ void intel_hdcp_update_pipe(struct intel_atomic_state
*state,
if (desired_and_not_enabled || content_protection_type_changed)
intel_hdcp_enable(connector,
- crtc_state->cpu_transcoder,
+ crtc_state,
(u8)conn_state->hdcp_content_type);
}
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.h
b/drivers/gpu/drm/i915/display/intel_hdcp.h
index 1bbf5b67ed0a..bc51c1e9b481 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.h
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.h
@@ -25,7 +25,7 @@
[Intel-gfx] [PATCH v8 04/19] drm/i915/hdcp: No HDCP when encoder is't initialized
There can be situation when DP MST connector is created without
mst modeset being done, in those cases connector->encoder will be
NULL. MST connector->encoder initializes after modeset.
Don't enable HDCP in such cases to prevent any crash.
Cc: Ramalingam C
Cc: Juston Li
Tested-by: Karthik B S
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index b9d8825e2bb1..7d63e9495956 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -2106,6 +2106,12 @@ int intel_hdcp_enable(struct intel_connector *connector,
if (!hdcp->shim)
return -ENOENT;
+ if (!connector->encoder) {
+ drm_err(&dev_priv->drm, "[%s:%d] encoder is not initialized\n",
+ connector->base.name, connector->base.base.id);
+ return -ENODEV;
+ }
+
mutex_lock(&hdcp->mutex);
mutex_lock(&dig_port->hdcp_mutex);
drm_WARN_ON(&dev_priv->drm,
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v8 03/19] drm/i915/hotplug: Handle CP_IRQ for DP-MST
Handle CP_IRQ in DEVICE_SERVICE_IRQ_VECTOR_ESI0
It requires to call intel_hdcp_handle_cp_irq() in case
of CP_IRQ is triggered by a sink in DP-MST topology.
Cc: "Ville Syrjälä"
Cc: Ramalingam C
Reviewed-by: Uma Shankar
Reviewed-by: Ramalingam C
Tested-by: Karthik B S
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_dp.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index b2bc0c8c39c7..501b9a8a2f45 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5783,6 +5783,17 @@ static void intel_dp_handle_test_request(struct intel_dp
*intel_dp)
"Could not write test response to sink\n");
}
+static void
+intel_dp_mst_hpd_irq(struct intel_dp *intel_dp, u8 *esi, bool *handled)
+{
+ drm_dp_mst_hpd_irq(&intel_dp->mst_mgr, esi, handled);
+
+ if (esi[1] & DP_CP_IRQ) {
+ intel_hdcp_handle_cp_irq(intel_dp->attached_connector);
+ *handled = true;
+ }
+}
+
/**
* intel_dp_check_mst_status - service any pending MST interrupts, check link
status
* @intel_dp: Intel DP struct
@@ -5827,7 +5838,8 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
drm_dbg_kms(&i915->drm, "got esi %3ph\n", esi);
- drm_dp_mst_hpd_irq(&intel_dp->mst_mgr, esi, &handled);
+ intel_dp_mst_hpd_irq(intel_dp, esi, &handled);
+
if (!handled)
break;
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v8 02/19] drm/i915/hdcp: Get conn while content_type changed
Get DRM connector reference count while scheduling a prop work
to avoid any possible destroy of DRM connector when it is in
DRM_CONNECTOR_REGISTERED state.
Fixes: a6597faa2d59 ("drm/i915: Protect workers against disappearing
connectors")
Cc: Sean Paul
Cc: Ramalingam C
Reviewed-by: Uma Shankar
Reviewed-by: Ramalingam C
Tested-by: Karthik B S
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index eee8263405b9..b9d8825e2bb1 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -2210,6 +2210,7 @@ void intel_hdcp_update_pipe(struct intel_atomic_state
*state,
if (content_protection_type_changed) {
mutex_lock(&hdcp->mutex);
hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
+ drm_connector_get(&connector->base);
schedule_work(&hdcp->prop_work);
mutex_unlock(&hdcp->mutex);
}
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v8 01/19] drm/i915/hdcp: Update CP property in update_pipe
When crtc state need_modeset is true it is not necessary
it is going to be a real modeset, it can turns to be a
fastset instead of modeset.
This turns content protection property to be DESIRED and hdcp
update_pipe left with property to be in DESIRED state but
actual hdcp->value was ENABLED.
This issue is caught with DP MST setup, where we have multiple
connector in same DP_MST topology. When disabling HDCP on one of
DP MST connector leads to set the crtc state need_modeset to true
for all other crtc driving the other DP-MST topology connectors.
This turns up other DP MST connectors CP property to be DESIRED
despite the actual hdcp->value is ENABLED.
Above scenario fails the DP MST HDCP IGT test, disabling HDCP on
one MST stream should not cause to disable HDCP on another MST
stream on same DP MST topology.
v2:
- Fixed connector->base.registration_state == DRM_CONNECTOR_REGISTERED
WARN_ON.
v3:
- Commit log improvement. [Uma]
- Added a comment before scheduling prop_work. [Uma]
Fixes: 33f9a623bfc6 ("drm/i915/hdcp: Update CP as per the kernel internal
state")
Cc: Ramalingam C
Reviewed-by: Uma Shankar
Reviewed-by: Ramalingam C
Tested-by: Karthik B S
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index b2a4bbcfdcd2..eee8263405b9 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -2221,6 +2221,14 @@ void intel_hdcp_update_pipe(struct intel_atomic_state
*state,
desired_and_not_enabled =
hdcp->value != DRM_MODE_CONTENT_PROTECTION_ENABLED;
mutex_unlock(&hdcp->mutex);
+ /*
+* If HDCP already ENABLED and CP property is DESIRED, schedule
+* prop_work to update correct CP property to user space.
+*/
+ if (!desired_and_not_enabled &&
!content_protection_type_changed) {
+ drm_connector_get(&connector->base);
+ schedule_work(&hdcp->prop_work);
+ }
}
if (desired_and_not_enabled || content_protection_type_changed)
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v8 00/19] HDCP 2.2 and HDCP 1.4 Gen12 DP MST support
This v8 version has fixed the cosmetics eview comment from ram. No functional change. It has been tested manually with below IGT series on TGL and ICL. https://patchwork.freedesktop.org/series/82987/ [PATCH v8 12/19] misc/mei/hdcp: Fix AUTH_STREAM_REQ cmd buffer len has an Ack from Tomas to merge it via drm-intel. [PATCH v8 13/19] drm/hdcp: Max MST content streams has an Ack from drm-misc maintainer to merge it via drm-intel. Test-with: 20201126050320.2434-2-karthik@intel.com Anshuman Gupta (19): drm/i915/hdcp: Update CP property in update_pipe drm/i915/hdcp: Get conn while content_type changed drm/i915/hotplug: Handle CP_IRQ for DP-MST drm/i915/hdcp: No HDCP when encoder is't initialized drm/i915/hdcp: DP MST transcoder for link and stream drm/i915/hdcp: Move HDCP enc status timeout to header drm/i915/hdcp: HDCP stream encryption support drm/i915/hdcp: Configure HDCP1.4 MST steram encryption status drm/i915/hdcp: Enable Gen12 HDCP 1.4 DP MST support drm/i915/hdcp: Pass dig_port to intel_hdcp_init drm/i915/hdcp: Encapsulate hdcp_port_data to dig_port misc/mei/hdcp: Fix AUTH_STREAM_REQ cmd buffer len drm/hdcp: Max MST content streams drm/i915/hdcp: MST streams support in hdcp port_data drm/i915/hdcp: Pass connector to check_2_2_link drm/i915/hdcp: Add HDCP 2.2 stream register drm/i915/hdcp: Support for HDCP 2.2 MST shim callbacks drm/i915/hdcp: Configure HDCP2.2 MST steram encryption status drm/i915/hdcp: Enable HDCP 2.2 MST support drivers/gpu/drm/i915/display/intel_ddi.c | 14 +- drivers/gpu/drm/i915/display/intel_ddi.h | 6 +- .../drm/i915/display/intel_display_types.h| 20 +- drivers/gpu/drm/i915/display/intel_dp.c | 14 +- drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 186 +-- drivers/gpu/drm/i915/display/intel_dp_mst.c | 9 +- drivers/gpu/drm/i915/display/intel_hdcp.c | 303 ++ drivers/gpu/drm/i915/display/intel_hdcp.h | 8 +- drivers/gpu/drm/i915/display/intel_hdmi.c | 19 +- drivers/gpu/drm/i915/i915_reg.h | 40 +++ drivers/misc/mei/hdcp/mei_hdcp.c | 3 +- include/drm/drm_hdcp.h| 8 +- 12 files changed, 510 insertions(+), 120 deletions(-) -- 2.26.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Use cmpxchg64 for 32b compatilibity
== Series Details == Series: drm/i915: Use cmpxchg64 for 32b compatilibity URL : https://patchwork.freedesktop.org/series/84831/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9474_full -> Patchwork_19123_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_19123_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_19123_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_19123_full: ### IGT changes ### Possible regressions * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: - shard-kbl: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9474/shard-kbl4/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-c.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19123/shard-kbl7/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-c.html Known issues Here are the changes found in Patchwork_19123_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@preservation-s3@rcs0: - shard-kbl: [PASS][3] -> [DMESG-WARN][4] ([i915#180]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9474/shard-kbl1/igt@gem_ctx_isolation@preservation...@rcs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19123/shard-kbl2/igt@gem_ctx_isolation@preservation...@rcs0.html * igt@gem_exec_create@basic: - shard-glk: [PASS][5] -> [DMESG-WARN][6] ([i915#118] / [i915#95]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9474/shard-glk9/igt@gem_exec_cre...@basic.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19123/shard-glk8/igt@gem_exec_cre...@basic.html * igt@gem_exec_reloc@basic-many-active@rcs0: - shard-apl: [PASS][7] -> [FAIL][8] ([i915#2389]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9474/shard-apl2/igt@gem_exec_reloc@basic-many-act...@rcs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19123/shard-apl3/igt@gem_exec_reloc@basic-many-act...@rcs0.html * igt@gem_exec_reloc@basic-wide-active@vcs1: - shard-iclb: NOTRUN -> [FAIL][9] ([i915#2389]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19123/shard-iclb4/igt@gem_exec_reloc@basic-wide-act...@vcs1.html * igt@gem_huc_copy@huc-copy: - shard-tglb: [PASS][10] -> [SKIP][11] ([i915#2190]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9474/shard-tglb5/igt@gem_huc_c...@huc-copy.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19123/shard-tglb6/igt@gem_huc_c...@huc-copy.html * igt@kms_ccs@pipe-c-crc-sprite-planes-basic: - shard-skl: NOTRUN -> [SKIP][12] ([fdo#109271] / [fdo#111304]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19123/shard-skl5/igt@kms_...@pipe-c-crc-sprite-planes-basic.html * igt@kms_color_chamelium@pipe-d-ctm-0-75: - shard-skl: NOTRUN -> [SKIP][13] ([fdo#109271] / [fdo#111827]) +2 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19123/shard-skl8/igt@kms_color_chamel...@pipe-d-ctm-0-75.html * igt@kms_cursor_crc@pipe-b-cursor-64x21-offscreen: - shard-skl: [PASS][14] -> [FAIL][15] ([i915#54]) +3 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9474/shard-skl2/igt@kms_cursor_...@pipe-b-cursor-64x21-offscreen.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19123/shard-skl1/igt@kms_cursor_...@pipe-b-cursor-64x21-offscreen.html * igt@kms_cursor_legacy@flip-vs-cursor-legacy: - shard-skl: [PASS][16] -> [FAIL][17] ([i915#2346]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9474/shard-skl9/igt@kms_cursor_leg...@flip-vs-cursor-legacy.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19123/shard-skl10/igt@kms_cursor_leg...@flip-vs-cursor-legacy.html * igt@kms_flip@flip-vs-expired-vblank@a-dp1: - shard-apl: [PASS][18] -> [FAIL][19] ([i915#79]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9474/shard-apl3/igt@kms_flip@flip-vs-expired-vbl...@a-dp1.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19123/shard-apl4/igt@kms_flip@flip-vs-expired-vbl...@a-dp1.html * igt@kms_hdr@bpc-switch-dpms: - shard-skl: [PASS][20] -> [FAIL][21] ([i915#1188]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9474/shard-skl7/igt@kms_...@bpc-switch-dpms.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19123/shard-skl2/igt@kms_...@bpc-switch-dpms.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes: - shard-kbl
Re: [Intel-gfx] [PATCH] drm/i915/display/tc: Only WARN once for bogus tc port flag
On Wed, 09 Dec 2020, Rodrigo Vivi wrote: > On Wed, Dec 09, 2020 at 04:16:36PM -0500, Sean Paul wrote: >> From: Sean Paul >> >> No need to spam syslog/console when we can ignore/fix the flag. > > besides that we are calling from multiple places anyway.. > >> >> Signed-off-by: Sean Paul > > > Reviewed-by: Rodrigo Vivi Thanks, pushed to din. BR, Jani. > > > >> --- >> drivers/gpu/drm/i915/display/intel_tc.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/gpu/drm/i915/display/intel_tc.c >> b/drivers/gpu/drm/i915/display/intel_tc.c >> index 4346bc1a747a..27dc2dad6809 100644 >> --- a/drivers/gpu/drm/i915/display/intel_tc.c >> +++ b/drivers/gpu/drm/i915/display/intel_tc.c >> @@ -262,7 +262,7 @@ static u32 tc_port_live_status_mask(struct >> intel_digital_port *dig_port) >> mask |= BIT(TC_PORT_LEGACY); >> >> /* The sink can be connected only in a single mode. */ >> -if (!drm_WARN_ON(&i915->drm, hweight32(mask) > 1)) >> +if (!drm_WARN_ON_ONCE(&i915->drm, hweight32(mask) > 1)) >> tc_port_fixup_legacy_flag(dig_port, mask); >> >> return mask; >> -- >> Sean Paul, Software Engineer, Google / Chromium OS >> >> ___ >> dri-devel mailing list >> dri-de...@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [patch 14/30] drm/i915/pmu: Replace open coded kstat_irqs() copy
On Fri, Dec 11 2020 at 10:13, Tvrtko Ursulin wrote: > On 10/12/2020 19:25, Thomas Gleixner wrote: >> >> Aside of that the count is per interrupt line and therefore takes >> interrupts from other devices into account which share the interrupt line >> and are not handled by the graphics driver. >> >> Replace it with a pmu private count which only counts interrupts which >> originate from the graphics card. >> >> To avoid atomics or heuristics of some sort make the counter field >> 'unsigned long'. That limits the count to 4e9 on 32bit which is a lot and >> postprocessing can easily deal with the occasional wraparound. > > After my failed hasty sketch from last night I had a different one which > was kind of heuristics based (re-reading the upper dword and retrying if > it changed on 32-bit). The problem is that there will be two seperate modifications for the low and high word. Several ways how the compiler can translate this, but the problem is the same for all of them: CPU 0 CPU 1 load low load high add low, 1 addc high, 0 store low load high --> NMI load low load high and compare store high You can't catch that. If this really becomes an issue you need a sequence counter around it. > But you are right - it is okay to at least start > like this today and if later there is a need we can either do that or > deal with wrap at PMU read time. Right. >> +/* >> + * Interrupt statistic for PMU. Increments the counter only if the >> + * interrupt originated from the the GPU so interrupts from a device which >> + * shares the interrupt line are not accounted. >> + */ >> +static inline void pmu_irq_stats(struct drm_i915_private *priv, > > We never use priv as a local name, it should be either i915 or > dev_priv. Sure, will fix. >> +/* >> + * A clever compiler translates that into INC. A not so clever one >> + * should at least prevent store tearing. >> + */ >> +WRITE_ONCE(priv->pmu.irq_count, priv->pmu.irq_count + 1); > > Curious, probably more educational for me - given x86_32 and x86_64, and > the context of it getting called, what is the difference from just doing > irq_count++? Several reasons: 1) The compiler can pretty much do what it wants with cnt++ including tearing and whatever. https://lwn.net/Articles/816850/ for the full set of insanities. Not really a problem here, but 2) It's annotating the reader and the writer side and documenting that this is subject to concurrency 3) It will prevent KCSAN to complain about the data race, i.e. concurrent modification while reading. Thanks, tglx >> --- a/drivers/gpu/drm/i915/i915_pmu.c >> +++ b/drivers/gpu/drm/i915/i915_pmu.c >> @@ -423,22 +423,6 @@ static enum hrtimer_restart i915_sample( >> return HRTIMER_RESTART; >> } > > In this file you can also drop the #include line. Indeed. Thanks, tglx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [patch 27/30] xen/events: Only force affinity mask for percpu interrupts
On Fri, Dec 11 2020 at 13:10, Jürgen Groß wrote: > On 11.12.20 00:20, boris.ostrov...@oracle.com wrote: >> >> On 12/10/20 2:26 PM, Thomas Gleixner wrote: >>> All event channel setups bind the interrupt on CPU0 or the target CPU for >>> percpu interrupts and overwrite the affinity mask with the corresponding >>> cpumask. That does not make sense. >>> >>> The XEN implementation of irqchip::irq_set_affinity() already picks a >>> single target CPU out of the affinity mask and the actual target is stored >>> in the effective CPU mask, so destroying the user chosen affinity mask >>> which might contain more than one CPU is wrong. >>> >>> Change the implementation so that the channel is bound to CPU0 at the XEN >>> level and leave the affinity mask alone. At startup of the interrupt >>> affinity will be assigned out of the affinity mask and the XEN binding will >>> be updated. >> >> >> If that's the case then I wonder whether we need this call at all and >> instead bind at startup time. > > After some discussion with Thomas on IRC and xen-devel archaeology the > result is: this will be needed especially for systems running on a > single vcpu (e.g. small guests), as the .irq_set_affinity() callback > won't be called in this case when starting the irq. That's right, but not limited to ARM. The same problem exists on x86 UP. So yes, the call makes sense, but the changelog is not really useful. Let me add a comment to this. Thanks, tglx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Use cmpxchg64 for 32b compatilibity
== Series Details == Series: drm/i915: Use cmpxchg64 for 32b compatilibity URL : https://patchwork.freedesktop.org/series/84831/ State : success == Summary == CI Bug Log - changes from CI_DRM_9474 -> Patchwork_19123 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19123/index.html Known issues Here are the changes found in Patchwork_19123 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@gt_heartbeat: - fi-kbl-soraka: [PASS][1] -> [DMESG-FAIL][2] ([i915#2291] / [i915#541]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9474/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19123/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html * igt@vgem_basic@create: - fi-tgl-y: [PASS][3] -> [DMESG-WARN][4] ([i915#402]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9474/fi-tgl-y/igt@vgem_ba...@create.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19123/fi-tgl-y/igt@vgem_ba...@create.html Possible fixes * igt@gem_mmap_gtt@basic: - fi-tgl-y: [DMESG-WARN][5] ([i915#402]) -> [PASS][6] +2 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9474/fi-tgl-y/igt@gem_mmap_...@basic.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19123/fi-tgl-y/igt@gem_mmap_...@basic.html [i915#2291]: https://gitlab.freedesktop.org/drm/intel/issues/2291 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 [i915#541]: https://gitlab.freedesktop.org/drm/intel/issues/541 Participating hosts (43 -> 40) -- Missing(3): fi-ilk-m540 fi-bdw-samus fi-hsw-4200u Build changes - * Linux: CI_DRM_9474 -> Patchwork_19123 CI-20190529: 20190529 CI_DRM_9474: f982ee792667f5f2d70901f49a70021415241c07 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5888: c79d4e88f4162905da400360b6fa4940122f3a2c @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_19123: ea506800e7fd45f0b11e1964e982d1c4f5fc754e @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == ea506800e7fd drm/i915: Use cmpxchg64 for 32b compatilibity == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19123/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.DOCS: warning for drm/i915: Use cmpxchg64 for 32b compatilibity
== Series Details == Series: drm/i915: Use cmpxchg64 for 32b compatilibity URL : https://patchwork.freedesktop.org/series/84831/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 Error: Cannot open file ./drivers/gpu/drm/i915/gt/intel_lrc.c WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -sphinx-version 1.7.9 -function Logical Rings, Logical Ring Contexts and Execlists ./drivers/gpu/drm/i915/gt/intel_lrc.c' failed with return code 1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/20] drm/i915/gt: Shrink the critical section for irq signaling
Quoting Matthew Brost (2020-12-10 17:37:13)
> On Mon, Dec 07, 2020 at 07:38:11PM +, Chris Wilson wrote:
> > Let's only wait for the list iterator when decoupling the virtual
> > breadcrumb, as the signaling of all the requests may take a long time,
> > during which we do not want to keep the tasklet spinning.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 2 ++
> > drivers/gpu/drm/i915/gt/intel_breadcrumbs_types.h | 1 +
> > drivers/gpu/drm/i915/gt/intel_lrc.c | 3 ++-
> > 3 files changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
> > b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
> > index 63900edbde88..ac1e5f6c3c2c 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
> > @@ -239,6 +239,7 @@ static void signal_irq_work(struct irq_work *work)
> > intel_breadcrumbs_disarm_irq(b);
> >
> > rcu_read_lock();
> > + atomic_inc(&b->signaler_active);
> > list_for_each_entry_rcu(ce, &b->signalers, signal_link) {
> > struct i915_request *rq;
> >
> > @@ -274,6 +275,7 @@ static void signal_irq_work(struct irq_work *work)
> > }
> > }
> > }
> > + atomic_dec(&b->signaler_active);
> > rcu_read_unlock();
> >
> > llist_for_each_safe(signal, sn, signal) {
> > diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs_types.h
> > b/drivers/gpu/drm/i915/gt/intel_breadcrumbs_types.h
> > index a74bb3062bd8..f672053d694d 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs_types.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs_types.h
> > @@ -35,6 +35,7 @@ struct intel_breadcrumbs {
> > spinlock_t signalers_lock; /* protects the list of signalers */
> > struct list_head signalers;
> > struct llist_head signaled_requests;
> > + atomic_t signaler_active;
> >
> > spinlock_t irq_lock; /* protects the interrupt from hardirq context */
> > struct irq_work irq_work; /* for use from inside irq_lock */
> > diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > index b3db16b2a5a4..35cded25c6c1 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > @@ -1401,7 +1401,8 @@ static void kick_siblings(struct i915_request *rq,
> > struct intel_context *ce)
> >* ce->signal_link.
> >*/
> > i915_request_cancel_breadcrumb(rq);
> > - irq_work_sync(&engine->breadcrumbs->irq_work);
> > + while (atomic_read(&engine->breadcrumbs->signaler_active))
> > + cpu_relax();
>
> Would a 'cond_resched' be better here? I trust your opinion on which to
> use but thought I'd mention it.
While by this point we've removed the spinlock from around us, we are
still inside a softirq bh. That will disallow sleeping. Fortunately,
we only have to busy wait on the list iteration.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for Introduce Intel PXP component - Mesa single session (rev8)
== Series Details == Series: Introduce Intel PXP component - Mesa single session (rev8) URL : https://patchwork.freedesktop.org/series/84620/ State : success == Summary == CI Bug Log - changes from CI_DRM_9474_full -> Patchwork_19122_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_19122_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_reloc@basic-wide-active@vcs1: - shard-iclb: NOTRUN -> [FAIL][1] ([i915#2389]) +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19122/shard-iclb2/igt@gem_exec_reloc@basic-wide-act...@vcs1.html * igt@gem_userptr_blits@huge-split: - shard-skl: [PASS][2] -> [INCOMPLETE][3] ([i915#2502]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9474/shard-skl4/igt@gem_userptr_bl...@huge-split.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19122/shard-skl10/igt@gem_userptr_bl...@huge-split.html * igt@i915_selftest@live@gt_heartbeat: - shard-skl: [PASS][4] -> [DMESG-FAIL][5] ([i915#2291] / [i915#541]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9474/shard-skl1/igt@i915_selftest@live@gt_heartbeat.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19122/shard-skl4/igt@i915_selftest@live@gt_heartbeat.html * igt@kms_ccs@pipe-c-crc-sprite-planes-basic: - shard-skl: NOTRUN -> [SKIP][6] ([fdo#109271] / [fdo#111304]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19122/shard-skl6/igt@kms_...@pipe-c-crc-sprite-planes-basic.html * igt@kms_color_chamelium@pipe-d-ctm-0-75: - shard-skl: NOTRUN -> [SKIP][7] ([fdo#109271] / [fdo#111827]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19122/shard-skl4/igt@kms_color_chamel...@pipe-d-ctm-0-75.html * igt@kms_cursor_crc@pipe-a-cursor-suspend: - shard-skl: [PASS][8] -> [INCOMPLETE][9] ([i915#2295] / [i915#300]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9474/shard-skl1/igt@kms_cursor_...@pipe-a-cursor-suspend.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19122/shard-skl4/igt@kms_cursor_...@pipe-a-cursor-suspend.html * igt@kms_cursor_crc@pipe-c-cursor-64x21-random: - shard-skl: [PASS][10] -> [FAIL][11] ([i915#54]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9474/shard-skl9/igt@kms_cursor_...@pipe-c-cursor-64x21-random.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19122/shard-skl8/igt@kms_cursor_...@pipe-c-cursor-64x21-random.html * igt@kms_cursor_legacy@flip-vs-cursor-atomic: - shard-skl: [PASS][12] -> [FAIL][13] ([i915#2346]) +1 similar issue [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9474/shard-skl5/igt@kms_cursor_leg...@flip-vs-cursor-atomic.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19122/shard-skl3/igt@kms_cursor_leg...@flip-vs-cursor-atomic.html * igt@kms_flip@flip-vs-expired-vblank@c-dp1: - shard-apl: [PASS][14] -> [FAIL][15] ([i915#79]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9474/shard-apl3/igt@kms_flip@flip-vs-expired-vbl...@c-dp1.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19122/shard-apl3/igt@kms_flip@flip-vs-expired-vbl...@c-dp1.html * igt@kms_flip@plain-flip-fb-recreate-interruptible@a-dp1: - shard-kbl: [PASS][16] -> [FAIL][17] ([i915#2122]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9474/shard-kbl1/igt@kms_flip@plain-flip-fb-recreate-interrupti...@a-dp1.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19122/shard-kbl6/igt@kms_flip@plain-flip-fb-recreate-interrupti...@a-dp1.html * igt@kms_hdr@bpc-switch-suspend: - shard-skl: [PASS][18] -> [FAIL][19] ([i915#1188]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9474/shard-skl8/igt@kms_...@bpc-switch-suspend.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19122/shard-skl7/igt@kms_...@bpc-switch-suspend.html * igt@kms_plane_lowres@pipe-d-tiling-yf: - shard-skl: NOTRUN -> [SKIP][20] ([fdo#109271]) +26 similar issues [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19122/shard-skl6/igt@kms_plane_low...@pipe-d-tiling-yf.html * igt@kms_psr2_su@page_flip: - shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109642] / [fdo#111068]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9474/shard-iclb2/igt@kms_psr2_su@page_flip.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19122/shard-iclb6/igt@kms_psr2_su@page_flip.html * igt@kms_psr@psr2_cursor_render: - shard-iclb: [PASS][23] -> [SKIP][24] ([fdo#109441]) +1 similar issue [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9474/shard-iclb2/igt@kms_psr@psr2_cursor_render.html [24]: https://
[Intel-gfx] [PATCH] drm/i915: Use cmpxchg64 for 32b compatilibity
By using the double wide cmpxchg64 on 32bit, we can use the same algorithm on both 32/64b systems. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_active.c | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_active.c b/drivers/gpu/drm/i915/i915_active.c index 10a865f3dc09..ab4382841c6b 100644 --- a/drivers/gpu/drm/i915/i915_active.c +++ b/drivers/gpu/drm/i915/i915_active.c @@ -159,8 +159,7 @@ __active_retire(struct i915_active *ref) GEM_BUG_ON(ref->tree.rb_node != &ref->cache->node); /* Make the cached node available for reuse with any timeline */ - if (IS_ENABLED(CONFIG_64BIT)) - ref->cache->timeline = 0; /* needs cmpxchg(u64) */ + ref->cache->timeline = 0; /* needs cmpxchg(u64) */ } spin_unlock_irqrestore(&ref->tree_lock, flags); @@ -256,7 +255,6 @@ static struct active_node *__active_lookup(struct i915_active *ref, u64 idx) if (cached == idx) return it; -#ifdef CONFIG_64BIT /* for cmpxchg(u64) */ /* * An unclaimed cache [.timeline=0] can only be claimed once. * @@ -267,9 +265,8 @@ static struct active_node *__active_lookup(struct i915_active *ref, u64 idx) * only the winner of that race will cmpxchg return the old * value of 0). */ - if (!cached && !cmpxchg(&it->timeline, 0, idx)) + if (!cached && !cmpxchg64(&it->timeline, 0, idx)) return it; -#endif } BUILD_BUG_ON(offsetof(typeof(*it), node)); -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v7 17/18] drm/i915/hdcp: Support for HDCP 2.2 MST shim callbacks
On 2020-12-11 at 12:49:35 +0530, Ramalingam C wrote:
> On 2020-12-10 at 11:56:39 +0530, Anshuman Gupta wrote:
> > Add support for HDCP 2.2 DP MST shim callback.
> > This adds existing DP HDCP shim callback for Link Authentication
> > and Encryption and HDCP 2.2 stream encryption
> > callback.
> >
> > v2:
> > - Added a WARN_ON() instead of drm_err. [Uma]
> > - Cosmetic changes. [Uma]
> > v3:
> > - 's/port_data/hdcp_port_data' [Ram]
> > - skip redundant link check. [Ram]
> > v4:
> > - use pipe instead of port to access HDCP2_STREAM_STATUS
> How this missed the functional test till now?
> Always true because port's stream status was referred?
> >
> > Cc: Ramalingam C
> > Reviewed-by: Uma Shankar
> > Tested-by: Karthik B S
> > Signed-off-by: Anshuman Gupta
> > ---
> > .../drm/i915/display/intel_display_types.h| 4 +
> > drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 89 +--
> > 2 files changed, 85 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> > b/drivers/gpu/drm/i915/display/intel_display_types.h
> > index 63de25b40eff..da91e3f4ff27 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > @@ -378,6 +378,10 @@ struct intel_hdcp_shim {
> > int (*config_stream_type)(struct intel_digital_port *dig_port,
> > bool is_repeater, u8 type);
> >
> > + /* Enable/Disable HDCP 2.2 stream encryption on DP MST Transport Link */
> > + int (*stream_2_2_encryption)(struct intel_connector *connector,
> > +bool enable);
> > +
> > /* HDCP2.2 Link Integrity Check */
> > int (*check_2_2_link)(struct intel_digital_port *dig_port,
> > struct intel_connector *connector);
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> > b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> > index 9ade1ad3a80c..f372e25edab4 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> > @@ -698,18 +698,14 @@ intel_dp_mst_hdcp_stream_encryption(struct
> > intel_connector *connector,
> > return 0;
> > }
> >
> > -static
> > -bool intel_dp_mst_hdcp_check_link(struct intel_digital_port *dig_port,
> > - struct intel_connector *connector)
> > +static bool intel_dp_mst_get_qses_status(struct intel_digital_port
> > *dig_port,
> > +struct intel_connector *connector)
> > {
> > struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> > - struct intel_dp *intel_dp = &dig_port->dp;
> > struct drm_dp_query_stream_enc_status_ack_reply reply;
> > + struct intel_dp *intel_dp = &dig_port->dp;
> > int ret;
> >
> > - if (!intel_dp_hdcp_check_link(dig_port, connector))
> > - return false;
> > -
> > ret = drm_dp_send_query_stream_enc_status(&intel_dp->mst_mgr,
> > connector->port, &reply);
> > if (ret) {
> > @@ -726,6 +722,78 @@ bool intel_dp_mst_hdcp_check_link(struct
> > intel_digital_port *dig_port,
> > return reply.auth_completed && reply.encryption_enabled;
> > }
> >
> > +static
> > +bool intel_dp_mst_hdcp_check_link(struct intel_digital_port *dig_port,
> > + struct intel_connector *connector)
> > +{
> > + if (!intel_dp_hdcp_check_link(dig_port, connector))
> > + return false;
> this also could be optimised for the connector with port authentication
> only?
Can we take this up in different series? With HDCP 1.4 POV this series just
focused to enable HDCP 1.4 stream encryption and HDCP for Gen12.
Currently HDCP 1.4 port authentication and encryption is done of each DP MST
connector, we can take up this work while optimizing HDCP 1.4.
Thanks,
Anshuman Gupta.
> > +
> > + return intel_dp_mst_get_qses_status(dig_port, connector);
> > +}
> > +
> > +static int
> > +intel_dp_mst_hdcp2_stream_encryption(struct intel_connector *connector,
> > +bool enable)
> > +{
> > + struct intel_digital_port *dig_port =
> > intel_attached_dig_port(connector);
> > + struct drm_i915_private *i915 = to_i915(connector->base.dev);
> > + struct hdcp_port_data *data = &dig_port->hdcp_port_data;
> > + struct intel_hdcp *hdcp = &connector->hdcp;
> > + enum transcoder cpu_transcoder = hdcp->stream_transcoder;
> > + enum pipe pipe = (enum pipe)cpu_transcoder;
> > + enum port port = dig_port->base.port;
> > + int ret;
> > +
> > + drm_WARN_ON(&i915->drm, enable &&
> > + !!(intel_de_read(i915, HDCP2_AUTH_STREAM(i915,
> > cpu_transcoder, port))
> > + & AUTH_STREAM_TYPE) != data->streams[0].stream_type);
> > +
> > + ret = intel_dp_mst_toggle_hdcp_stream_select(connector, enable);
> > + if (ret)
> > + return ret;
> > +
> > + /* Wait for encryption confirmation */
> >
Re: [Intel-gfx] [PATCH v4 2/2] drm/i915/display: Support Multiple Transcoders' PSR status on debugfs
On Fri, 2020-12-04 at 21:36 +0530, Anshuman Gupta wrote:
> On 2020-11-18 at 16:42:29 +0530, Jani Nikula wrote:
> > On Fri, 06 Nov 2020, Gwan-gyeong Mun
> > wrote:
> > > In order to support the PSR state of each transcoder, it adds
> > > i915_psr_status to sub-directory of each transcoder.
> > >
> > > v2: Change using of Symbolic permissions 'S_IRUGO' to using of
> > > octal
> > > permissions '0444'
> > >
> > > Signed-off-by: Gwan-gyeong Mun
> > > Cc: José Roberto de Souza
> > > ---
> > > .../drm/i915/display/intel_display_debugfs.c | 23
> > > +++
> > > 1 file changed, 23 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > > b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > > index 8402e6ac9f76..37805615a221 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > > @@ -2093,6 +2093,23 @@ static int
> > > i915_hdcp_sink_capability_show(struct seq_file *m, void *data)
> > > }
> > > DEFINE_SHOW_ATTRIBUTE(i915_hdcp_sink_capability);
> > >
> > > +static int i915_psr_status_show(struct seq_file *m, void *data)
> > > +{
> > > + struct drm_connector *connector = m->private;
> > > + struct intel_dp *intel_dp =
> > > + intel_attached_dp(to_intel_connector(connector));
> > > + struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > > +
> > > + if (connector->status != connector_status_connected)
> >
> > How's this possible for eDP, btw?
> >
When I wrote the code first it was considered PanelReplay of DP spec.
for now it is not needed for edp.
> > BR,
> > Jani.
> >
> > > + return -ENODEV;
> > > +
> > > + if (!HAS_PSR(dev_priv))
> > > + return -ENODEV;
> > > +
> > > + return intel_psr_status(m, intel_dp);
> > > +}
> > > +DEFINE_SHOW_ATTRIBUTE(i915_psr_status);
> > > +
> > > #define LPSP_CAPABLE(COND) (COND ? seq_puts(m, "LPSP:
> > > capable\n") : \
> > > seq_puts(m, "LPSP: incapable\n"))
> > >
> > > @@ -2268,6 +2285,12 @@ int intel_connector_debugfs_add(struct
> > > drm_connector *connector)
> > > connector,
> > > &i915_psr_sink_status_fops);
> > > }
> > >
> > > + if (INTEL_GEN(dev_priv) >= 12 &&
> > > + connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
> Hi GG
> IMHO this should connector->connector_type == DRM_MODE_CONNECTOR_eDP
> || connector->connector_type == DRM_MODE_SUBCONNECTOR_DisplayPort
> to support DP Panel Reply, i read somewere DP panel reply is PSR with
> Link Full ON ?
> I believe this would be the reason to keep file name as
> "i915_psr_status" instead of i915_edp_psr_status?
Hi Anshuman,
Yes, the file name (i915_psr_status) was considered for DP PanelReplay
too.
But for now, i915 is not supported PanelReplay yet, it would be better
to limit it to edp.
When the PanelReplay is ready I'll update here too.
> Thanks,
> Anshuman.
> > > + debugfs_create_file("i915_psr_status", 0444, root,
> > > + connector, &i915_psr_status_fops);
> > > + }
> > > +
> > > if (connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort
> > > ||
> > > connector->connector_type == DRM_MODE_CONNECTOR_HDMIA ||
> > > connector->connector_type == DRM_MODE_CONNECTOR_HDMIB) {
> >
> > --
> > Jani Nikula, Intel Open Source Graphics Center
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 2/2] drm/i915/display: Support Multiple Transcoders' PSR status on debugfs
On Wed, 2020-11-18 at 13:11 +0200, Jani Nikula wrote:
> On Fri, 06 Nov 2020, Gwan-gyeong Mun
> wrote:
> > In order to support the PSR state of each transcoder, it adds
> > i915_psr_status to sub-directory of each transcoder.
> >
> > v2: Change using of Symbolic permissions 'S_IRUGO' to using of
> > octal
> > permissions '0444'
> >
> > Signed-off-by: Gwan-gyeong Mun
> > Cc: José Roberto de Souza
> > ---
> > .../drm/i915/display/intel_display_debugfs.c | 23
> > +++
> > 1 file changed, 23 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > index 8402e6ac9f76..37805615a221 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > @@ -2093,6 +2093,23 @@ static int
> > i915_hdcp_sink_capability_show(struct seq_file *m, void *data)
> > }
> > DEFINE_SHOW_ATTRIBUTE(i915_hdcp_sink_capability);
> >
> > +static int i915_psr_status_show(struct seq_file *m, void *data)
> > +{
> > + struct drm_connector *connector = m->private;
> > + struct intel_dp *intel_dp =
> > + intel_attached_dp(to_intel_connector(connector));
> > + struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > +
> > + if (connector->status != connector_status_connected)
> > + return -ENODEV;
> > +
> > + if (!HAS_PSR(dev_priv))
> > + return -ENODEV;
> > +
> > + return intel_psr_status(m, intel_dp);
> > +}
> > +DEFINE_SHOW_ATTRIBUTE(i915_psr_status);
> > +
> > #define LPSP_CAPABLE(COND) (COND ? seq_puts(m, "LPSP: capable\n")
> > : \
> > seq_puts(m, "LPSP: incapable\n"))
> >
> > @@ -2268,6 +2285,12 @@ int intel_connector_debugfs_add(struct
> > drm_connector *connector)
> > connector,
> > &i915_psr_sink_status_fops);
> > }
> >
> > + if (INTEL_GEN(dev_priv) >= 12 &&
>
> I'd add this for all generations to unify the debugfs, and eventually
> phase out the non connector specific debugfs file.
>
> And I'd add HAS_PSR() check here to not create the file if it's not
> possible instead of having the check in i915_psr_status_show().
>
Hi Jani,
Thank you for checking the patch.
I'll update the code as per your recommendations.
> BR,
> Jani.
>
> > + connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
> > + debugfs_create_file("i915_psr_status", 0444, root,
> > + connector, &i915_psr_status_fops);
> > + }
> > +
> > if (connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort
> > ||
> > connector->connector_type == DRM_MODE_CONNECTOR_HDMIA ||
> > connector->connector_type == DRM_MODE_CONNECTOR_HDMIB) {
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 1/2] drm/i915/display: Support PSR Multiple Transcoders
On Fri, 2020-12-04 at 22:08 +0530, Anshuman Gupta wrote:
> On 2020-11-06 at 15:44:42 +0530, Gwan-gyeong Mun wrote:
> > It is a preliminary work for supporting multiple EDP PSR and
> > DP PanelReplay. And it refactors singleton PSR to Multi Transcoder
> > supportable PSR.
> > And this moves and renames the i915_psr structure of
> > drm_i915_private's to
> > intel_dp's intel_psr structure.
> > It also causes changes in PSR interrupt handling routine for
> > supporting
> > multiple transcoders. But it does not change the scenario and
> > timing of
> > enabling and disabling PSR.
> Could you please break this patch, it can be break in following
> parts.
> 1. psr init path
> 2. atomic commit path
> 3. irq path
> 3. debugfs path
>
Hi,
Thank you for checking the patch.
Because the i915_psr structure of drm_i915_private's has moved to
intel_dp's intel_psr structure,
In order to be able to compile the patch, all of the affected code has
been included.
So it's hard to split what you mentioned.
therefore this patch does not include a new feature except supporting
multiple transcoder's psr.
> There are couple of comments, see below.
> > v2: Fix indentation and add comments
> > v3: Remove Blank line
> > v4: Rebased
> >
> > Signed-off-by: Gwan-gyeong Mun
> > Cc: José Roberto de Souza
> > Cc: Juha-Pekka Heikkila
> > ---
> > drivers/gpu/drm/i915/display/intel_ddi.c | 5 +
> > drivers/gpu/drm/i915/display/intel_display.c | 4 -
> > .../drm/i915/display/intel_display_debugfs.c | 111 ++--
> > .../drm/i915/display/intel_display_types.h| 38 ++
> > drivers/gpu/drm/i915/display/intel_dp.c | 23 +-
> > drivers/gpu/drm/i915/display/intel_psr.c | 585 ++--
> > --
> > drivers/gpu/drm/i915/display/intel_psr.h | 14 +-
> > drivers/gpu/drm/i915/display/intel_sprite.c | 6 +-
> > drivers/gpu/drm/i915/i915_drv.h | 38 --
> > drivers/gpu/drm/i915/i915_irq.c | 47 +-
> > 10 files changed, 491 insertions(+), 380 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > index 19b16517a502..983781ce3683 100644
> > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > @@ -4127,7 +4127,10 @@ static void intel_ddi_update_pipe_dp(struct
> > intel_atomic_state *state,
> >
> > intel_ddi_set_dp_msa(crtc_state, conn_state);
> >
> > + //TODO: move PSR related functions into intel_psr_update()
> > + intel_psr2_program_trans_man_trk_ctl(intel_dp, crtc_state);
> > intel_psr_update(intel_dp, crtc_state, conn_state);
> > +
> > intel_dp_set_infoframes(encoder, true, crtc_state, conn_state);
> > intel_edp_drrs_update(intel_dp, crtc_state);
> >
> > @@ -5275,6 +5278,8 @@ void intel_ddi_init(struct drm_i915_private
> > *dev_priv, enum port port)
> > goto err;
> >
> > dig_port->hpd_pulse = intel_dp_hpd_pulse;
> > +
> > + intel_psr_init(&dig_port->dp);
> IMHO this should be called from intel_dp_init_connector.
Your recommendation seems better, I'll update it.
> > }
> >
> > /* In theory we don't need the encoder->type check, but leave
> > it just in
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 8c4687b19814..466923a54370 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -15506,8 +15506,6 @@ static void commit_pipe_config(struct
> > intel_atomic_state *state,
> >
> > if (new_crtc_state->update_pipe)
> > intel_pipe_fastset(old_crtc_state,
> > new_crtc_state);
> > -
> > - intel_psr2_program_trans_man_trk_ctl(new_crtc_state);
> > }
> >
> > if (dev_priv->display.atomic_update_watermarks)
> > @@ -17435,8 +17433,6 @@ static void intel_setup_outputs(struct
> > drm_i915_private *dev_priv)
> > intel_dvo_init(dev_priv);
> > }
> >
> > - intel_psr_init(dev_priv);
> > -
> > for_each_intel_encoder(&dev_priv->drm, encoder) {
> > encoder->base.possible_crtcs =
> > intel_encoder_possible_crtcs(encoder);
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > index cfb4c1474982..8402e6ac9f76 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > @@ -248,18 +248,17 @@ static int i915_psr_sink_status_show(struct
> > seq_file *m, void *data)
> > "sink internal error",
> > };
> > struct drm_connector *connector = m->private;
> > - struct drm_i915_private *dev_priv = to_i915(connector->dev);
> > struct intel_dp *intel_dp =
> > intel_attached_dp(to_intel_connector(connector));
> > int ret;
> >
> > - if (!CAN_PSR(dev_priv)) {
> > - seq_pu
Re: [Intel-gfx] [patch 27/30] xen/events: Only force affinity mask for percpu interrupts
On 11.12.20 00:20, boris.ostrov...@oracle.com wrote: On 12/10/20 2:26 PM, Thomas Gleixner wrote: All event channel setups bind the interrupt on CPU0 or the target CPU for percpu interrupts and overwrite the affinity mask with the corresponding cpumask. That does not make sense. The XEN implementation of irqchip::irq_set_affinity() already picks a single target CPU out of the affinity mask and the actual target is stored in the effective CPU mask, so destroying the user chosen affinity mask which might contain more than one CPU is wrong. Change the implementation so that the channel is bound to CPU0 at the XEN level and leave the affinity mask alone. At startup of the interrupt affinity will be assigned out of the affinity mask and the XEN binding will be updated. If that's the case then I wonder whether we need this call at all and instead bind at startup time. This binding to cpu0 was introduced with commit 97253eeeb792d61ed2 and I have no reason to believe the underlying problem has been eliminated. Juergen OpenPGP_0xB0DE9DD628BF132F.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [patch 14/30] drm/i915/pmu: Replace open coded kstat_irqs() copy
On 10/12/2020 19:25, Thomas Gleixner wrote:
Driver code has no business with the internals of the irq descriptor.
Aside of that the count is per interrupt line and therefore takes
interrupts from other devices into account which share the interrupt line
and are not handled by the graphics driver.
Replace it with a pmu private count which only counts interrupts which
originate from the graphics card.
To avoid atomics or heuristics of some sort make the counter field
'unsigned long'. That limits the count to 4e9 on 32bit which is a lot and
postprocessing can easily deal with the occasional wraparound.
After my failed hasty sketch from last night I had a different one which
was kind of heuristics based (re-reading the upper dword and retrying if
it changed on 32-bit). But you are right - it is okay to at least start
like this today and if later there is a need we can either do that or
deal with wrap at PMU read time.
So thanks for dealing with it, some small comments below but overall it
is fine.
Signed-off-by: Thomas Gleixner
Cc: Tvrtko Ursulin
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: David Airlie
Cc: Daniel Vetter
Cc: intel-gfx@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
---
drivers/gpu/drm/i915/i915_irq.c | 34 ++
drivers/gpu/drm/i915/i915_pmu.c | 18 +-
drivers/gpu/drm/i915/i915_pmu.h |8
3 files changed, 43 insertions(+), 17 deletions(-)
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -60,6 +60,24 @@
* and related files, but that will be described in separate chapters.
*/
+/*
+ * Interrupt statistic for PMU. Increments the counter only if the
+ * interrupt originated from the the GPU so interrupts from a device which
+ * shares the interrupt line are not accounted.
+ */
+static inline void pmu_irq_stats(struct drm_i915_private *priv,
We never use priv as a local name, it should be either i915 or dev_priv.
+irqreturn_t res)
+{
+ if (unlikely(res != IRQ_HANDLED))
+ return;
+
+ /*
+* A clever compiler translates that into INC. A not so clever one
+* should at least prevent store tearing.
+*/
+ WRITE_ONCE(priv->pmu.irq_count, priv->pmu.irq_count + 1);
Curious, probably more educational for me - given x86_32 and x86_64, and
the context of it getting called, what is the difference from just doing
irq_count++?
+}
+
typedef bool (*long_pulse_detect_func)(enum hpd_pin pin, u32 val);
static const u32 hpd_ilk[HPD_NUM_PINS] = {
@@ -1599,6 +1617,8 @@ static irqreturn_t valleyview_irq_handle
valleyview_pipestat_irq_handler(dev_priv, pipe_stats);
} while (0);
+ pmu_irq_stats(dev_priv, ret);
+
enable_rpm_wakeref_asserts(&dev_priv->runtime_pm);
return ret;
@@ -1676,6 +1696,8 @@ static irqreturn_t cherryview_irq_handle
valleyview_pipestat_irq_handler(dev_priv, pipe_stats);
} while (0);
+ pmu_irq_stats(dev_priv, ret);
+
enable_rpm_wakeref_asserts(&dev_priv->runtime_pm);
return ret;
@@ -2103,6 +2125,8 @@ static irqreturn_t ilk_irq_handler(int i
if (sde_ier)
raw_reg_write(regs, SDEIER, sde_ier);
+ pmu_irq_stats(i915, ret);
+
/* IRQs are synced during runtime_suspend, we don't require a wakeref */
enable_rpm_wakeref_asserts(&i915->runtime_pm);
@@ -2419,6 +2443,8 @@ static irqreturn_t gen8_irq_handler(int
gen8_master_intr_enable(regs);
+ pmu_irq_stats(dev_priv, IRQ_HANDLED);
+
return IRQ_HANDLED;
}
@@ -2514,6 +2540,8 @@ static __always_inline irqreturn_t
gen11_gu_misc_irq_handler(gt, gu_misc_iir);
+ pmu_irq_stats(i915, IRQ_HANDLED);
+
return IRQ_HANDLED;
}
@@ -3688,6 +3716,8 @@ static irqreturn_t i8xx_irq_handler(int
i8xx_pipestat_irq_handler(dev_priv, iir, pipe_stats);
} while (0);
+ pmu_irq_stats(dev_priv, ret);
+
enable_rpm_wakeref_asserts(&dev_priv->runtime_pm);
return ret;
@@ -3796,6 +3826,8 @@ static irqreturn_t i915_irq_handler(int
i915_pipestat_irq_handler(dev_priv, iir, pipe_stats);
} while (0);
+ pmu_irq_stats(dev_priv, ret);
+
enable_rpm_wakeref_asserts(&dev_priv->runtime_pm);
return ret;
@@ -3941,6 +3973,8 @@ static irqreturn_t i965_irq_handler(int
i965_pipestat_irq_handler(dev_priv, iir, pipe_stats);
} while (0);
+ pmu_irq_stats(dev_priv, IRQ_HANDLED);
+
enable_rpm_wakeref_asserts(&dev_priv->runtime_pm);
return ret;
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -423,22 +423,6 @@ static enum hrtimer_restart i915_sample(
return HRTIMER_RESTART;
}
In this file you can also drop the #include line.
-static u64 count_interrupts(struct drm_i915_private *i915)
-{
- /* open-coded kstat_irqs() *
Re: [Intel-gfx] [patch 27/30] xen/events: Only force affinity mask for percpu interrupts
On Fri, Dec 11 2020 at 07:17, Jürgen Groß wrote:
> On 11.12.20 00:20, boris.ostrov...@oracle.com wrote:
>>
>> On 12/10/20 2:26 PM, Thomas Gleixner wrote:
>>> All event channel setups bind the interrupt on CPU0 or the target CPU for
>>> percpu interrupts and overwrite the affinity mask with the corresponding
>>> cpumask. That does not make sense.
>>>
>>> The XEN implementation of irqchip::irq_set_affinity() already picks a
>>> single target CPU out of the affinity mask and the actual target is stored
>>> in the effective CPU mask, so destroying the user chosen affinity mask
>>> which might contain more than one CPU is wrong.
>>>
>>> Change the implementation so that the channel is bound to CPU0 at the XEN
>>> level and leave the affinity mask alone. At startup of the interrupt
>>> affinity will be assigned out of the affinity mask and the XEN binding will
>>> be updated.
>>
>>
>> If that's the case then I wonder whether we need this call at all and
>> instead bind at startup time.
>
> This binding to cpu0 was introduced with commit 97253eeeb792d61ed2
> and I have no reason to believe the underlying problem has been
> eliminated.
"The kernel-side VCPU binding was not being correctly set for newly
allocated or bound interdomain events. In ARM guests where 2-level
events were used, this would result in no interdomain events being
handled because the kernel-side VCPU masks would all be clear.
x86 guests would work because the irq affinity was set during irq
setup and this would set the correct kernel-side VCPU binding."
I'm not convinced that this is really correctly analyzed because affinity
setting is done at irq startup.
switch (__irq_startup_managed(desc, aff, force)) {
case IRQ_STARTUP_NORMAL:
ret = __irq_startup(desc);
irq_setup_affinity(desc);
break;
which is completely architecture agnostic. So why should this magically
work on x86 and not on ARM if both are using the same XEN irqchip with
the same irqchip callbacks.
Thanks,
tglx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Introduce Intel PXP component - Mesa single session (rev8)
== Series Details == Series: Introduce Intel PXP component - Mesa single session (rev8) URL : https://patchwork.freedesktop.org/series/84620/ State : success == Summary == CI Bug Log - changes from CI_DRM_9474 -> Patchwork_19122 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19122/index.html Known issues Here are the changes found in Patchwork_19122 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@gt_heartbeat: - fi-tgl-y: [PASS][1] -> [DMESG-FAIL][2] ([i915#2601]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9474/fi-tgl-y/igt@i915_selftest@live@gt_heartbeat.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19122/fi-tgl-y/igt@i915_selftest@live@gt_heartbeat.html * igt@prime_self_import@basic-with_two_bos: - fi-tgl-y: [PASS][3] -> [DMESG-WARN][4] ([i915#402]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9474/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19122/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html Possible fixes * igt@gem_mmap_gtt@basic: - fi-tgl-y: [DMESG-WARN][5] ([i915#402]) -> [PASS][6] +2 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9474/fi-tgl-y/igt@gem_mmap_...@basic.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19122/fi-tgl-y/igt@gem_mmap_...@basic.html [i915#2601]: https://gitlab.freedesktop.org/drm/intel/issues/2601 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 Participating hosts (43 -> 39) -- Missing(4): fi-ilk-m540 fi-bdw-samus fi-tgl-dsi fi-hsw-4200u Build changes - * Linux: CI_DRM_9474 -> Patchwork_19122 CI-20190529: 20190529 CI_DRM_9474: f982ee792667f5f2d70901f49a70021415241c07 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5888: c79d4e88f4162905da400360b6fa4940122f3a2c @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_19122: 8e852e077594ab190386c155f4428b35dfd08dbb @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 8e852e077594 drm/i915/pxp: Enable the PXP ioctl for protected session bcc9b977b876 mei: pxp: add vtag parameter to mei_pxp_send/receive interface b6503a960d6a mei: bus: add vtag support 7ec0ed17ce84 drm/i915/pxp: Add PXP-related registers into allowlist b84477cc8080 drm/i915/pxp: Termiante the session upon app crash 9b1fa8b3b954 drm/i915/pxp: Implement ioctl action to query PXP tag 52012be29790 drm/i915/pxp: Implement ioctl action to send TEE commands 56d25d4e32a4 drm/i915/pxp: Implement ioctl action to terminate the session cf7bd29b94d9 drm/i915/pxp: Implement ioctl action to set session in play ec0265ec5383 drm/i915/pxp: Implement ioctl action to reserve session slots 72b03056fdd8 drm/i915/pxp: Add plane decryption support 7cfdaae63c4e drm/i915/pxp: User interface for Protected buffer 6f0f2a9fad54 drm/i915/uapi: introduce drm_i915_gem_create_ext fe8a87fd99d9 mei: pxp: export pavp client to me client bus 47d3aeafecbe drm/i915/pxp: Expose session state for display protection flip b96bf7e80a28 drm/i915/pxp: Enable PXP power management 8a0aff60049e drm/i915/pxp: Destroy arb session upon teardown 9db73c188015 drm/i915/pxp: Enable PXP irq worker and callback stub 3e513275f2c4 drm/i915/pxp: Func to send hardware session termination 01a5ed146b56 drm/i915/pxp: Create the arbitrary session after boot 38e3c5114511 drm/i915/pxp: Implement funcs to create the TEE channel bf809419dacc drm/i915/pxp: set KCR reg init during the boot time 69d2fc1c153b drm/i915/pxp: Introduce Intel PXP component == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19122/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [patch 16/30] mfd: ab8500-debugfs: Remove the racy fiddling with irq_desc
On Thu, 10 Dec 2020, Thomas Gleixner wrote: > First of all drivers have absolutely no business to dig into the internals > of an irq descriptor. That's core code and subject to change. All of this > information is readily available to /proc/interrupts in a safe and race > free way. > > Remove the inspection code which is a blatant violation of subsystem > boundaries and racy against concurrent modifications of the interrupt > descriptor. > > Print the irq line instead so the information can be looked up in a sane > way in /proc/interrupts. > > Signed-off-by: Thomas Gleixner > Cc: Linus Walleij > Cc: Lee Jones > Cc: linux-arm-ker...@lists.infradead.org > --- > drivers/mfd/ab8500-debugfs.c | 16 +++- > 1 file changed, 3 insertions(+), 13 deletions(-) Acked-by: Lee Jones -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [patch 14/30] drm/i915/pmu: Replace open coded kstat_irqs() copy
On Thu, 10 Dec 2020, Thomas Gleixner wrote:
> Driver code has no business with the internals of the irq descriptor.
>
> Aside of that the count is per interrupt line and therefore takes
> interrupts from other devices into account which share the interrupt line
> and are not handled by the graphics driver.
>
> Replace it with a pmu private count which only counts interrupts which
> originate from the graphics card.
>
> To avoid atomics or heuristics of some sort make the counter field
> 'unsigned long'. That limits the count to 4e9 on 32bit which is a lot and
> postprocessing can easily deal with the occasional wraparound.
I'll let Tvrtko and Chris review the substance here, but assuming they
don't object,
Acked-by: Jani Nikula
for merging via whichever tree makes most sense.
>
> Signed-off-by: Thomas Gleixner
> Cc: Tvrtko Ursulin
> Cc: Jani Nikula
> Cc: Joonas Lahtinen
> Cc: Rodrigo Vivi
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> ---
> drivers/gpu/drm/i915/i915_irq.c | 34 ++
> drivers/gpu/drm/i915/i915_pmu.c | 18 +-
> drivers/gpu/drm/i915/i915_pmu.h |8
> 3 files changed, 43 insertions(+), 17 deletions(-)
>
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -60,6 +60,24 @@
> * and related files, but that will be described in separate chapters.
> */
>
> +/*
> + * Interrupt statistic for PMU. Increments the counter only if the
> + * interrupt originated from the the GPU so interrupts from a device which
> + * shares the interrupt line are not accounted.
> + */
> +static inline void pmu_irq_stats(struct drm_i915_private *priv,
> + irqreturn_t res)
> +{
> + if (unlikely(res != IRQ_HANDLED))
> + return;
> +
> + /*
> + * A clever compiler translates that into INC. A not so clever one
> + * should at least prevent store tearing.
> + */
> + WRITE_ONCE(priv->pmu.irq_count, priv->pmu.irq_count + 1);
> +}
> +
> typedef bool (*long_pulse_detect_func)(enum hpd_pin pin, u32 val);
>
> static const u32 hpd_ilk[HPD_NUM_PINS] = {
> @@ -1599,6 +1617,8 @@ static irqreturn_t valleyview_irq_handle
> valleyview_pipestat_irq_handler(dev_priv, pipe_stats);
> } while (0);
>
> + pmu_irq_stats(dev_priv, ret);
> +
> enable_rpm_wakeref_asserts(&dev_priv->runtime_pm);
>
> return ret;
> @@ -1676,6 +1696,8 @@ static irqreturn_t cherryview_irq_handle
> valleyview_pipestat_irq_handler(dev_priv, pipe_stats);
> } while (0);
>
> + pmu_irq_stats(dev_priv, ret);
> +
> enable_rpm_wakeref_asserts(&dev_priv->runtime_pm);
>
> return ret;
> @@ -2103,6 +2125,8 @@ static irqreturn_t ilk_irq_handler(int i
> if (sde_ier)
> raw_reg_write(regs, SDEIER, sde_ier);
>
> + pmu_irq_stats(i915, ret);
> +
> /* IRQs are synced during runtime_suspend, we don't require a wakeref */
> enable_rpm_wakeref_asserts(&i915->runtime_pm);
>
> @@ -2419,6 +2443,8 @@ static irqreturn_t gen8_irq_handler(int
>
> gen8_master_intr_enable(regs);
>
> + pmu_irq_stats(dev_priv, IRQ_HANDLED);
> +
> return IRQ_HANDLED;
> }
>
> @@ -2514,6 +2540,8 @@ static __always_inline irqreturn_t
>
> gen11_gu_misc_irq_handler(gt, gu_misc_iir);
>
> + pmu_irq_stats(i915, IRQ_HANDLED);
> +
> return IRQ_HANDLED;
> }
>
> @@ -3688,6 +3716,8 @@ static irqreturn_t i8xx_irq_handler(int
> i8xx_pipestat_irq_handler(dev_priv, iir, pipe_stats);
> } while (0);
>
> + pmu_irq_stats(dev_priv, ret);
> +
> enable_rpm_wakeref_asserts(&dev_priv->runtime_pm);
>
> return ret;
> @@ -3796,6 +3826,8 @@ static irqreturn_t i915_irq_handler(int
> i915_pipestat_irq_handler(dev_priv, iir, pipe_stats);
> } while (0);
>
> + pmu_irq_stats(dev_priv, ret);
> +
> enable_rpm_wakeref_asserts(&dev_priv->runtime_pm);
>
> return ret;
> @@ -3941,6 +3973,8 @@ static irqreturn_t i965_irq_handler(int
> i965_pipestat_irq_handler(dev_priv, iir, pipe_stats);
> } while (0);
>
> + pmu_irq_stats(dev_priv, IRQ_HANDLED);
> +
> enable_rpm_wakeref_asserts(&dev_priv->runtime_pm);
>
> return ret;
> --- a/drivers/gpu/drm/i915/i915_pmu.c
> +++ b/drivers/gpu/drm/i915/i915_pmu.c
> @@ -423,22 +423,6 @@ static enum hrtimer_restart i915_sample(
> return HRTIMER_RESTART;
> }
>
> -static u64 count_interrupts(struct drm_i915_private *i915)
> -{
> - /* open-coded kstat_irqs() */
> - struct irq_desc *desc = irq_to_desc(i915->drm.pdev->irq);
> - u64 sum = 0;
> - int cpu;
> -
> - if (!desc || !desc->kstat_irqs)
> - return 0;
> -
> - for_each_possible_cpu(cpu)
> - sum += *per_cpu_ptr(desc->kstat_irqs, cpu);
> -
> - return sum;
> -}
> -
> static void i915_pmu_event_destr
Re: [Intel-gfx] [patch 13/30] drm/i915/lpe_audio: Remove pointless irq_to_desc() usage
On Thu, 10 Dec 2020, Ville Syrjälä wrote:
> On Thu, Dec 10, 2020 at 08:25:49PM +0100, Thomas Gleixner wrote:
>> Nothing uses the result and nothing should ever use it in driver code.
>>
>> Signed-off-by: Thomas Gleixner
>> Cc: Jani Nikula
>> Cc: Joonas Lahtinen
>> Cc: Rodrigo Vivi
>> Cc: David Airlie
>> Cc: Daniel Vetter
>> Cc: Pankaj Bharadiya
>> Cc: Chris Wilson
>> Cc: Wambui Karuga
>> Cc: intel-gfx@lists.freedesktop.org
>> Cc: dri-de...@lists.freedesktop.org
>
> Reviewed-by: Ville Syrjälä
Thomas, I presume you want to merge this series as a whole.
Acked-by: Jani Nikula
for merging via whichever tree makes most sense. Please let us know if
you want us to pick this up via drm-intel instead.
>
>> ---
>> drivers/gpu/drm/i915/display/intel_lpe_audio.c |4
>> 1 file changed, 4 deletions(-)
>>
>> --- a/drivers/gpu/drm/i915/display/intel_lpe_audio.c
>> +++ b/drivers/gpu/drm/i915/display/intel_lpe_audio.c
>> @@ -297,13 +297,9 @@ int intel_lpe_audio_init(struct drm_i915
>> */
>> void intel_lpe_audio_teardown(struct drm_i915_private *dev_priv)
>> {
>> -struct irq_desc *desc;
>> -
>> if (!HAS_LPE_AUDIO(dev_priv))
>> return;
>>
>> -desc = irq_to_desc(dev_priv->lpe_audio.irq);
>> -
>> lpe_audio_platdev_destroy(dev_priv);
>>
>> irq_free_desc(dev_priv->lpe_audio.irq);
>>
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for Introduce Intel PXP component - Mesa single session (rev7)
== Series Details == Series: Introduce Intel PXP component - Mesa single session (rev7) URL : https://patchwork.freedesktop.org/series/84620/ State : success == Summary == CI Bug Log - changes from CI_DRM_9474_full -> Patchwork_19121_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_19121_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_reloc@basic-wide-active@vcs1: - shard-iclb: NOTRUN -> [FAIL][1] ([i915#2389]) +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19121/shard-iclb4/igt@gem_exec_reloc@basic-wide-act...@vcs1.html * igt@i915_pm_rc6_residency@rc6-idle: - shard-hsw: [PASS][2] -> [WARN][3] ([i915#1519]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9474/shard-hsw2/igt@i915_pm_rc6_reside...@rc6-idle.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19121/shard-hsw1/igt@i915_pm_rc6_reside...@rc6-idle.html * igt@kms_ccs@pipe-c-crc-sprite-planes-basic: - shard-skl: NOTRUN -> [SKIP][4] ([fdo#109271] / [fdo#111304]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19121/shard-skl7/igt@kms_...@pipe-c-crc-sprite-planes-basic.html * igt@kms_color_chamelium@pipe-d-ctm-0-75: - shard-skl: NOTRUN -> [SKIP][5] ([fdo#109271] / [fdo#111827]) +2 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19121/shard-skl9/igt@kms_color_chamel...@pipe-d-ctm-0-75.html * igt@kms_cursor_crc@pipe-b-cursor-64x21-offscreen: - shard-skl: [PASS][6] -> [FAIL][7] ([i915#54]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9474/shard-skl2/igt@kms_cursor_...@pipe-b-cursor-64x21-offscreen.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19121/shard-skl8/igt@kms_cursor_...@pipe-b-cursor-64x21-offscreen.html * igt@kms_flip@flip-vs-expired-vblank-interruptible@c-edp1: - shard-skl: [PASS][8] -> [FAIL][9] ([i915#79]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9474/shard-skl1/igt@kms_flip@flip-vs-expired-vblank-interrupti...@c-edp1.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19121/shard-skl2/igt@kms_flip@flip-vs-expired-vblank-interrupti...@c-edp1.html * igt@kms_flip@flip-vs-expired-vblank@b-hdmi-a1: - shard-glk: [PASS][10] -> [FAIL][11] ([i915#79]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9474/shard-glk7/igt@kms_flip@flip-vs-expired-vbl...@b-hdmi-a1.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19121/shard-glk5/igt@kms_flip@flip-vs-expired-vbl...@b-hdmi-a1.html * igt@kms_hdr@bpc-switch-suspend: - shard-skl: [PASS][12] -> [FAIL][13] ([i915#1188]) +1 similar issue [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9474/shard-skl8/igt@kms_...@bpc-switch-suspend.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19121/shard-skl4/igt@kms_...@bpc-switch-suspend.html * igt@kms_plane_lowres@pipe-d-tiling-yf: - shard-skl: NOTRUN -> [SKIP][14] ([fdo#109271]) +32 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19121/shard-skl7/igt@kms_plane_low...@pipe-d-tiling-yf.html * igt@kms_psr2_su@page_flip: - shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#109642] / [fdo#111068]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9474/shard-iclb2/igt@kms_psr2_su@page_flip.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19121/shard-iclb8/igt@kms_psr2_su@page_flip.html * igt@kms_psr@psr2_cursor_plane_move: - shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#109441]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9474/shard-iclb2/igt@kms_psr@psr2_cursor_plane_move.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19121/shard-iclb8/igt@kms_psr@psr2_cursor_plane_move.html Possible fixes * igt@kms_async_flips@test-time-stamp: - shard-tglb: [FAIL][19] ([i915#2597]) -> [PASS][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9474/shard-tglb5/igt@kms_async_fl...@test-time-stamp.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19121/shard-tglb2/igt@kms_async_fl...@test-time-stamp.html * igt@kms_cursor_crc@pipe-a-cursor-256x85-onscreen: - shard-skl: [FAIL][21] ([i915#54]) -> [PASS][22] +6 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9474/shard-skl3/igt@kms_cursor_...@pipe-a-cursor-256x85-onscreen.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19121/shard-skl9/igt@kms_cursor_...@pipe-a-cursor-256x85-onscreen.html * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy: - shard-hsw: [FAIL][23] ([i915#96]) -> [PASS][24] +1 similar issue [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9474/shard-hsw6/igt@kms_c
[Intel-gfx] ✗ Fi.CI.DOCS: warning for Introduce Intel PXP component - Mesa single session (rev8)
== Series Details == Series: Introduce Intel PXP component - Mesa single session (rev8) URL : https://patchwork.freedesktop.org/series/84620/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 Error: Cannot open file ./drivers/gpu/drm/i915/gt/intel_lrc.c WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -sphinx-version 1.7.9 -function Logical Rings, Logical Ring Contexts and Execlists ./drivers/gpu/drm/i915/gt/intel_lrc.c' failed with return code 1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Introduce Intel PXP component - Mesa single session (rev8)
== Series Details == Series: Introduce Intel PXP component - Mesa single session (rev8) URL : https://patchwork.freedesktop.org/series/84620/ State : warning == Summary == $ dim checkpatch origin/drm-tip 69d2fc1c153b drm/i915/pxp: Introduce Intel PXP component -:111: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #111: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 175 lines checked bf809419dacc drm/i915/pxp: set KCR reg init during the boot time 38e3c5114511 drm/i915/pxp: Implement funcs to create the TEE channel -:8: WARNING:TYPO_SPELLING: 'defualt' may be misspelled - perhaps 'default'? #8: (defualt) session. -:85: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #85: new file mode 100644 total: 0 errors, 2 warnings, 0 checks, 248 lines checked 01a5ed146b56 drm/i915/pxp: Create the arbitrary session after boot -:68: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #68: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 297 lines checked 3e513275f2c4 drm/i915/pxp: Func to send hardware session termination -:25: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #25: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 181 lines checked 9db73c188015 drm/i915/pxp: Enable PXP irq worker and callback stub -:51: WARNING:LONG_LINE_COMMENT: line length of 113 exceeds 100 columns #51: FILE: drivers/gpu/drm/i915/i915_reg.h:7970: +#define GEN11_CRYPTO_INTR_MASK _MMIO(0x1900f0) /* crypto mask is in bit31-16 (Engine1 Interrupt Mask) */ total: 0 errors, 1 warnings, 0 checks, 210 lines checked 8a0aff60049e drm/i915/pxp: Destroy arb session upon teardown b96bf7e80a28 drm/i915/pxp: Enable PXP power management -:90: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #90: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 148 lines checked 47d3aeafecbe drm/i915/pxp: Expose session state for display protection flip fe8a87fd99d9 mei: pxp: export pavp client to me client bus -:32: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #32: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 277 lines checked 6f0f2a9fad54 drm/i915/uapi: introduce drm_i915_gem_create_ext -:12: ERROR:BAD_SIGN_OFF: Unrecognized email address: 'Joonas Lahtinen joonas.lahti...@linux.intel.com' #12: Cc: Joonas Lahtinen joonas.lahti...@linux.intel.com -:13: ERROR:BAD_SIGN_OFF: Unrecognized email address: 'Matthew Auld matthew.a...@intel.com' #13: Cc: Matthew Auld matthew.a...@intel.com -:46: ERROR:CODE_INDENT: code indent should use tabs where possible #46: FILE: drivers/gpu/drm/i915/i915_gem.c:265: +struct drm_i915_private *i915;$ -:46: WARNING:LEADING_SPACE: please, no spaces at the start of a line #46: FILE: drivers/gpu/drm/i915/i915_gem.c:265: +struct drm_i915_private *i915;$ -:50: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #50: FILE: drivers/gpu/drm/i915/i915_gem.c:269: +static int __create_setparam(struct drm_i915_gem_object_param *args, + struct create_ext *ext_data) -:95: CHECK:LINE_SPACING: Please don't use multiple blank lines #95: FILE: drivers/gpu/drm/i915/i915_gem.c:317: + + -:107: WARNING:LONG_LINE: line length of 120 exceeds 100 columns #107: FILE: include/uapi/drm/i915_drm.h:394: +#define DRM_IOCTL_I915_GEM_CREATE_EXT DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_CREATE, struct drm_i915_gem_create_ext) -:155: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV) #155: FILE: include/uapi/drm/i915_drm.h:1735: +#define I915_OBJECT_PARAM (1ull<<32) ^ total: 3 errors, 2 warnings, 3 checks, 136 lines checked 7cfdaae63c4e drm/i915/pxp: User interface for Protected buffer 72b03056fdd8 drm/i915/pxp: Add plane decryption support ec0265ec5383 drm/i915/pxp: Implement ioctl action to reserve session slots -:62: WARNING:PREFER_PACKED: __packed is preferred over __attribute__((packed)) #62: FILE: drivers/gpu/drm/i915/pxp/intel_pxp.c:39: +} __attribute__((packed)); -:254: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #254: new file mode 100644 -:345: WARNING:MSLEEP: msleep < 20ms can sleep for up to 20ms; see Documentation/timers/timers-howto.rst #345: FILE: drivers/gpu/drm/i915/pxp/intel_pxp_sm.c:87: + msleep(10); total: 0 errors, 3 warnings, 0 checks, 437 lines checked cf7bd29b94d9 drm/i915/pxp: Implement ioctl action to set session in play 56d25d4e32a4 drm/i915/pxp: Implement ioctl action to terminate the session 52012be29790 drm/i915/pxp: Implement ioctl action to send TEE commands 9b1fa8b3b954 drm/i915/pxp: Implement ioctl action to query PXP tag b84477cc8080 drm/i915/pxp: Termiante the session upon app crash 7e
Re: [Intel-gfx] [PATCH v7 17/18] drm/i915/hdcp: Support for HDCP 2.2 MST shim callbacks
On 2020-12-11 at 12:49:35 +0530, Ramalingam C wrote:
> On 2020-12-10 at 11:56:39 +0530, Anshuman Gupta wrote:
> > Add support for HDCP 2.2 DP MST shim callback.
> > This adds existing DP HDCP shim callback for Link Authentication
> > and Encryption and HDCP 2.2 stream encryption
> > callback.
> >
> > v2:
> > - Added a WARN_ON() instead of drm_err. [Uma]
> > - Cosmetic changes. [Uma]
> > v3:
> > - 's/port_data/hdcp_port_data' [Ram]
> > - skip redundant link check. [Ram]
> > v4:
> > - use pipe instead of port to access HDCP2_STREAM_STATUS
> How this missed the functional test till now?
Earlier it was tested on ICL with exisitng content protection igt tests
becuase DP-MST modeset were failing due to MST bandwidht related issue.
> Always true because port's stream status was referred?
It was passing when DDI_A being passed as port instead Pipe A (Used only MST
panels)
but when we connected an eDP panel, it uses DDI_A for eDP and DP_MST
connectors uses DDI_B. So this time it fails as issue surfaced
out becuase we have passed DDI_B as port instead of Pipe A.
Thanks,
Anshuman Gupta.
> >
> > Cc: Ramalingam C
> > Reviewed-by: Uma Shankar
> > Tested-by: Karthik B S
> > Signed-off-by: Anshuman Gupta
> > ---
> > .../drm/i915/display/intel_display_types.h| 4 +
> > drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 89 +--
> > 2 files changed, 85 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> > b/drivers/gpu/drm/i915/display/intel_display_types.h
> > index 63de25b40eff..da91e3f4ff27 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > @@ -378,6 +378,10 @@ struct intel_hdcp_shim {
> > int (*config_stream_type)(struct intel_digital_port *dig_port,
> > bool is_repeater, u8 type);
> >
> > + /* Enable/Disable HDCP 2.2 stream encryption on DP MST Transport Link */
> > + int (*stream_2_2_encryption)(struct intel_connector *connector,
> > +bool enable);
> > +
> > /* HDCP2.2 Link Integrity Check */
> > int (*check_2_2_link)(struct intel_digital_port *dig_port,
> > struct intel_connector *connector);
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> > b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> > index 9ade1ad3a80c..f372e25edab4 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> > @@ -698,18 +698,14 @@ intel_dp_mst_hdcp_stream_encryption(struct
> > intel_connector *connector,
> > return 0;
> > }
> >
> > -static
> > -bool intel_dp_mst_hdcp_check_link(struct intel_digital_port *dig_port,
> > - struct intel_connector *connector)
> > +static bool intel_dp_mst_get_qses_status(struct intel_digital_port
> > *dig_port,
> > +struct intel_connector *connector)
> > {
> > struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> > - struct intel_dp *intel_dp = &dig_port->dp;
> > struct drm_dp_query_stream_enc_status_ack_reply reply;
> > + struct intel_dp *intel_dp = &dig_port->dp;
> > int ret;
> >
> > - if (!intel_dp_hdcp_check_link(dig_port, connector))
> > - return false;
> > -
> > ret = drm_dp_send_query_stream_enc_status(&intel_dp->mst_mgr,
> > connector->port, &reply);
> > if (ret) {
> > @@ -726,6 +722,78 @@ bool intel_dp_mst_hdcp_check_link(struct
> > intel_digital_port *dig_port,
> > return reply.auth_completed && reply.encryption_enabled;
> > }
> >
> > +static
> > +bool intel_dp_mst_hdcp_check_link(struct intel_digital_port *dig_port,
> > + struct intel_connector *connector)
> > +{
> > + if (!intel_dp_hdcp_check_link(dig_port, connector))
> > + return false;
> this also could be optimised for the connector with port authentication
> only?
> > +
> > + return intel_dp_mst_get_qses_status(dig_port, connector);
> > +}
> > +
> > +static int
> > +intel_dp_mst_hdcp2_stream_encryption(struct intel_connector *connector,
> > +bool enable)
> > +{
> > + struct intel_digital_port *dig_port =
> > intel_attached_dig_port(connector);
> > + struct drm_i915_private *i915 = to_i915(connector->base.dev);
> > + struct hdcp_port_data *data = &dig_port->hdcp_port_data;
> > + struct intel_hdcp *hdcp = &connector->hdcp;
> > + enum transcoder cpu_transcoder = hdcp->stream_transcoder;
> > + enum pipe pipe = (enum pipe)cpu_transcoder;
> > + enum port port = dig_port->base.port;
> > + int ret;
> > +
> > + drm_WARN_ON(&i915->drm, enable &&
> > + !!(intel_de_read(i915, HDCP2_AUTH_STREAM(i915,
> > cpu_transcoder, port))
> > + & AUTH_STREAM_TYPE) != data->streams[0].stream_type);
> > +
> > + ret = intel_dp_mst_toggle_h
[Intel-gfx] [RFC-v8 11/23] drm/i915/uapi: introduce drm_i915_gem_create_ext
From: Bommu Krishnaiah
Same old gem_create but with now with extensions support. This is needed
to support various upcoming usecases. For now we use the extensions
mechanism to support PAVP.
Signed-off-by: Bommu Krishnaiah
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen joonas.lahti...@linux.intel.com
Cc: Matthew Auld matthew.a...@intel.com
Cc: Telukuntla Sreedhar
---
drivers/gpu/drm/i915/i915_drv.c | 2 +-
drivers/gpu/drm/i915/i915_gem.c | 42 -
include/uapi/drm/i915_drm.h | 47 +
3 files changed, 89 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index af06c85e6ba7..3dbda949bf71 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1733,7 +1733,7 @@ static const struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_GEM_THROTTLE, i915_gem_throttle_ioctl,
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_ENTERVT, drm_noop,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
DRM_IOCTL_DEF_DRV(I915_GEM_LEAVEVT, drm_noop,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
- DRM_IOCTL_DEF_DRV(I915_GEM_CREATE, i915_gem_create_ioctl,
DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(I915_GEM_CREATE_EXT, i915_gem_create_ioctl,
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_PREAD, i915_gem_pread_ioctl,
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_PWRITE, i915_gem_pwrite_ioctl,
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_MMAP, i915_gem_mmap_ioctl, DRM_RENDER_ALLOW),
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 58276694c848..41698a823737 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -53,6 +53,7 @@
#include "i915_drv.h"
#include "i915_trace.h"
#include "i915_vgpu.h"
+#include "i915_user_extensions.h"
#include "intel_pm.h"
@@ -260,6 +261,35 @@ i915_gem_dumb_create(struct drm_file *file,
&args->size, &args->handle);
}
+struct create_ext {
+struct drm_i915_private *i915;
+};
+
+static int __create_setparam(struct drm_i915_gem_object_param *args,
+ struct create_ext
*ext_data)
+{
+ if (!(args->param & I915_OBJECT_PARAM)) {
+ DRM_DEBUG("Missing I915_OBJECT_PARAM namespace\n");
+ return -EINVAL;
+ }
+
+ return -EINVAL;
+}
+
+static int create_setparam(struct i915_user_extension __user *base, void *data)
+{
+ struct drm_i915_gem_create_ext_setparam ext;
+
+ if (copy_from_user(&ext, base, sizeof(ext)))
+ return -EFAULT;
+
+ return __create_setparam(&ext.param, data);
+}
+
+static const i915_user_extension_fn create_extensions[] = {
+ [I915_GEM_CREATE_EXT_SETPARAM] = create_setparam,
+};
+
/**
* Creates a new mm object and returns a handle to it.
* @dev: drm device pointer
@@ -271,10 +301,20 @@ i915_gem_create_ioctl(struct drm_device *dev, void *data,
struct drm_file *file)
{
struct drm_i915_private *i915 = to_i915(dev);
- struct drm_i915_gem_create *args = data;
+ struct create_ext ext_data = { .i915 = i915 };
+ struct drm_i915_gem_create_ext *args = data;
+ int ret;
i915_gem_flush_free_objects(i915);
+ ret = i915_user_extensions(u64_to_user_ptr(args->extensions),
+ create_extensions,
+ ARRAY_SIZE(create_extensions),
+ &ext_data);
+ if (ret)
+ return ret;
+
+
return i915_gem_create(file,
intel_memory_region_by_type(i915,
INTEL_MEMORY_SYSTEM),
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 6edcb2b6c708..e918ccc81c74 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -391,6 +391,7 @@ typedef struct _drm_i915_sarea {
#define DRM_IOCTL_I915_GEM_ENTERVT DRM_IO(DRM_COMMAND_BASE +
DRM_I915_GEM_ENTERVT)
#define DRM_IOCTL_I915_GEM_LEAVEVT DRM_IO(DRM_COMMAND_BASE +
DRM_I915_GEM_LEAVEVT)
#define DRM_IOCTL_I915_GEM_CREATE DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_CREATE, struct drm_i915_gem_create)
+#define DRM_IOCTL_I915_GEM_CREATE_EXT DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_CREATE, struct drm_i915_gem_create_ext)
#define DRM_IOCTL_I915_GEM_PREAD DRM_IOW (DRM_COMMAND_BASE +
DRM_I915_GEM_PREAD, struct drm_i915_gem_pread)
#define DRM_IOCTL_I915_GEM_PWRITE DRM_IOW (DRM_COMMAND_BASE +
DRM_I915_GEM_PWRITE, struct drm_i915_gem_pwrite)
#define DRM_IOCTL_I915_GEM_MMAPDRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_MMAP, struct drm_i915_gem_mmap)
@@ -728,6 +729,27 @@ struct drm_i915_gem_create {
__u32 pad;
};
+struct drm_i915_gem_create_ext {
+ /**
+* Requested size fo
[Intel-gfx] [RFC-v8 15/23] drm/i915/pxp: Implement ioctl action to set session in play
With this ioctl action, userspace driver can set the session in
state "session in play", after dirver reserved the session slot/id
from kernel PXP, and sent the TEE commands to activate the
corresponding hardware session. Session state "session in play"
means this session is ready for secure playback.
Signed-off-by: Huang, Sean Z
---
drivers/gpu/drm/i915/pxp/intel_pxp.c| 11 +-
drivers/gpu/drm/i915/pxp/intel_pxp_sm.c | 51 +
drivers/gpu/drm/i915/pxp/intel_pxp_sm.h | 2 +
3 files changed, 63 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index e294134fef78..e000a78b782e 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -16,7 +16,13 @@
#define KCR_INIT_ALLOW_DISPLAY_ME_WRITES (BIT(14) | (BIT(14) <<
KCR_INIT_MASK_SHIFT))
#define PXP_ACTION_SET_SESSION_STATUS 1
-#define PXP_REQ_SESSION_ID_INIT 0
+
+enum pxp_session_req {
+ /* Request KMD to allocate session id and move it to IN INIT */
+ PXP_REQ_SESSION_ID_INIT = 0x0,
+ /* Inform KMD that UMD has completed the initialization */
+ PXP_REQ_SESSION_IN_PLAY,
+};
/*
* struct pxp_set_session_status_params - Params to reserved, set or destroy
@@ -228,6 +234,9 @@ int i915_pxp_ops_ioctl(struct drm_device *dev, void *data,
struct drm_file *drmf
pxp_info.sm_status = ret;
ret = 0;
}
+ } else if (params->req_session_state ==
PXP_REQ_SESSION_IN_PLAY) {
+ ret = intel_pxp_sm_ioctl_mark_session_in_play(pxp,
params->session_type,
+
params->pxp_tag);
} else {
ret = -EINVAL;
}
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_sm.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_sm.c
index e30be334d0dd..a657c5c7f013 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_sm.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_sm.c
@@ -12,6 +12,9 @@
#define GEN12_KCR_TSIP _MMIO(0x32264) /* KCR type1 session in play 0-63 */
+#define SESSION_TYPE_MASK BIT(7)
+#define SESSION_ID_MASK (BIT(7) - 1)
+
static inline int session_max(int session_type)
{
return (session_type == SESSION_TYPE_TYPE0) ?
@@ -148,6 +151,17 @@ static int create_session_entry(struct intel_pxp *pxp,
struct drm_file *drmfile,
return 0;
}
+static int pxp_get_session_index(u32 session_id, int *index_out, int *type_out)
+{
+ if (!index_out || !type_out)
+ return -EINVAL;
+
+ *type_out = (session_id & SESSION_TYPE_MASK) ? SESSION_TYPE_TYPE1 :
SESSION_TYPE_TYPE0;
+ *index_out = session_id & SESSION_ID_MASK;
+
+ return 0;
+}
+
/**
* intel_pxp_sm_ioctl_reserve_session - To reserve an available protected
session.
* @pxp: pointer to pxp struct
@@ -192,3 +206,40 @@ int intel_pxp_sm_ioctl_reserve_session(struct intel_pxp
*pxp, struct drm_file *d
return PXP_SM_STATUS_SESSION_NOT_AVAILABLE;
}
+
+/**
+ * intel_pxp_sm_ioctl_mark_session_in_play - Put an reserved session to
"in_play" state
+ * @pxp: pointer to pxp struct
+ * @session_type: Type of the session to be updated. One of enum
pxp_session_types.
+ * @session_id: Session identifier of the session, containing type and index
info
+ *
+ * Return: status. 0 means update is successful.
+ */
+int intel_pxp_sm_ioctl_mark_session_in_play(struct intel_pxp *pxp, int
session_type,
+ u32 session_id)
+{
+ int ret;
+ int session_index;
+ int session_type_in_id;
+ struct intel_pxp_sm_session *curr, *n;
+ struct intel_gt *gt = container_of(pxp, struct intel_gt, pxp);
+
+ ret = pxp_get_session_index(session_id, &session_index,
&session_type_in_id);
+ if (ret)
+ return ret;
+
+ if (session_type != session_type_in_id)
+ return -EINVAL;
+
+ lockdep_assert_held(&pxp->ctx.mutex);
+
+ list_for_each_entry_safe(curr, n, session_list(pxp, session_type),
list) {
+ if (curr->index == session_index) {
+ curr->is_in_play = true;
+ return 0;
+ }
+ }
+
+ drm_err(>->i915->drm, "Failed to %s couldn't find active session\n",
__func__);
+ return -EINVAL;
+}
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_sm.h
b/drivers/gpu/drm/i915/pxp/intel_pxp_sm.h
index 75fffb7d8b0e..aaa44d365f39 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_sm.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_sm.h
@@ -40,4 +40,6 @@ struct intel_pxp_sm_session {
int intel_pxp_sm_ioctl_reserve_session(struct intel_pxp *pxp, struct drm_file
*drmfile,
int session_type, int protection_mode,
u32 *pxp_tag);
+int intel_pxp_sm_ioctl_mark_session_in_play(struct intel_
[Intel-gfx] [RFC-v8 19/23] drm/i915/pxp: Termiante the session upon app crash
PXP should terminate the hardware session and cleanup the software
state gracefully when the application has established the
protection session, but doesn't close the session correctly due to
some cases like application crash.
Signed-off-by: Huang, Sean Z
---
drivers/gpu/drm/i915/i915_drv.c | 3 +++
drivers/gpu/drm/i915/pxp/intel_pxp.c| 15 +++
drivers/gpu/drm/i915/pxp/intel_pxp.h| 5 +
drivers/gpu/drm/i915/pxp/intel_pxp_sm.c | 25 +
drivers/gpu/drm/i915/pxp/intel_pxp_sm.h | 1 +
5 files changed, 49 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 3dbda949bf71..e74201e81369 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -69,6 +69,7 @@
#include "gt/intel_rc6.h"
#include "pxp/intel_pxp_pm.h"
+#include "pxp/intel_pxp.h"
#include "i915_debugfs.h"
#include "i915_drv.h"
@@ -1026,6 +1027,8 @@ static void i915_driver_postclose(struct drm_device *dev,
struct drm_file *file)
/* Catch up with all the deferred frees from "this" client */
i915_gem_flush_free_objects(to_i915(dev));
+
+ intel_pxp_close(&(to_i915(dev)->gt.pxp), file);
}
static void intel_suspend_encoders(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index 46ad2ab229c1..3a49dd97cab2 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -320,3 +320,18 @@ int i915_pxp_ops_ioctl(struct drm_device *dev, void *data,
struct drm_file *drmf
ret = -EFAULT;
return ret;
}
+
+void intel_pxp_close(struct intel_pxp *pxp, struct drm_file *drmfile)
+{
+ int ret;
+ struct intel_gt *gt = container_of(pxp, typeof(*gt), pxp);
+
+ if (pxp->ctx.id == 0 || !drmfile)
+ return;
+
+ mutex_lock(&pxp->ctx.mutex);
+ ret = intel_pxp_sm_close(pxp, drmfile);
+ if (ret)
+ drm_err(>->i915->drm, "Failed to %s, ret=[%d]\n", __func__,
ret);
+ mutex_unlock(&pxp->ctx.mutex);
+}
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h
b/drivers/gpu/drm/i915/pxp/intel_pxp.h
index 133e3df9b1f6..ffb460327315 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
@@ -64,6 +64,7 @@ int intel_pxp_init(struct intel_pxp *pxp);
void intel_pxp_uninit(struct intel_pxp *pxp);
bool intel_pxp_gem_object_status(struct drm_i915_private *i915);
int i915_pxp_ops_ioctl(struct drm_device *dev, void *data, struct drm_file
*drmfile);
+void intel_pxp_close(struct intel_pxp *pxp, struct drm_file *drmfile);
#else
static inline void intel_pxp_irq_handler(struct intel_pxp *pxp, u16 iir)
{
@@ -97,6 +98,10 @@ static inline int i915_pxp_ops_ioctl(struct drm_device *dev,
void *data, struct
{
return 0;
}
+
+static inline void intel_pxp_close(struct intel_pxp *pxp, struct drm_file
*drmfile)
+{
+}
#endif
#endif /* __INTEL_PXP_PM_H__ */
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_sm.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_sm.c
index c4b55e1531c1..e03c2b039192 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_sm.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_sm.c
@@ -460,3 +460,28 @@ int intel_pxp_sm_ioctl_query_pxp_tag(struct intel_pxp *pxp,
return 0;
}
+
+int intel_pxp_sm_close(struct intel_pxp *pxp, struct drm_file *drmfile)
+{
+ int ret;
+ struct intel_pxp_sm_session *curr, *n;
+
+ list_for_each_entry_safe(curr, n, session_list(pxp,
SESSION_TYPE_TYPE0), list) {
+ if (curr->drmfile && curr->drmfile == drmfile &&
+ curr->pid == pid_nr(drmfile->pid)) {
+ ret = pxp_terminate_hw_session(pxp, curr->type,
+ curr->index);
+ if (ret)
+ return ret;
+
+ ret = pxp_set_pxp_tag(pxp, curr->type, curr->index,
+ PROTECTION_MODE_NONE);
+ if (ret)
+ return ret;
+
+ list_del(&curr->list);
+ kfree(curr);
+ }
+ }
+ return 0;
+}
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_sm.h
b/drivers/gpu/drm/i915/pxp/intel_pxp_sm.h
index 09a26bb7a1a4..d2acbd1298b4 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_sm.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_sm.h
@@ -50,4 +50,5 @@ int intel_pxp_sm_ioctl_query_pxp_tag(struct intel_pxp *pxp,
bool intel_pxp_sm_is_hw_session_in_play(struct intel_pxp *pxp,
int session_type, int session_index);
int intel_pxp_sm_terminate_all_sessions(struct intel_pxp *pxp, int
session_type);
+int intel_pxp_sm_close(struct intel_pxp *pxp, struct drm_file *drmfile);
#endif /* __INTEL_PXP_SM_H__ */
--
2.17.1
___
Intel-
[Intel-gfx] [RFC-v8 20/23] drm/i915/pxp: Add PXP-related registers into allowlist
Add several PXP-related reg into allowlist to allow user space
driver to read the those register values.
Signed-off-by: Huang, Sean Z
---
drivers/gpu/drm/i915/i915_reg.h | 6
drivers/gpu/drm/i915/intel_uncore.c | 50 -
2 files changed, 41 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 0ea7e2a402ae..bcb7eb7a0e3c 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -12425,4 +12425,10 @@ enum skl_power_gate {
#define TGL_ROOT_DEVICE_SKU_ULX0x2
#define TGL_ROOT_DEVICE_SKU_ULT0x4
+/* Registers for allowlist check */
+#define PXP_REG_01_LOWERBOUND _MMIO(0x32260)
+#define PXP_REG_01_UPPERBOUND _MMIO(0x32268)
+#define PXP_REG_02_LOWERBOUND _MMIO(0x32670)
+#define PXP_REG_02_UPPERBOUND _MMIO(0x32678)
+
#endif /* _I915_REG_H_ */
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 9ac501bcfdad..dc97ec240571 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1990,16 +1990,34 @@ void intel_uncore_fini_mmio(struct intel_uncore *uncore)
}
static const struct reg_whitelist {
- i915_reg_t offset_ldw;
+ i915_reg_t offset_ldw_lowerbound;
+ i915_reg_t offset_ldw_upperbound;
i915_reg_t offset_udw;
u16 gen_mask;
u8 size;
-} reg_read_whitelist[] = { {
- .offset_ldw = RING_TIMESTAMP(RENDER_RING_BASE),
+} reg_read_whitelist[] = {
+ {
+ .offset_ldw_lowerbound = RING_TIMESTAMP(RENDER_RING_BASE),
+ .offset_ldw_upperbound = RING_TIMESTAMP(RENDER_RING_BASE),
.offset_udw = RING_TIMESTAMP_UDW(RENDER_RING_BASE),
.gen_mask = INTEL_GEN_MASK(4, 12),
.size = 8
-} };
+ },
+ {
+ .offset_ldw_lowerbound = PXP_REG_01_LOWERBOUND,
+ .offset_ldw_upperbound = PXP_REG_01_UPPERBOUND,
+ .offset_udw = {0},
+ .gen_mask = INTEL_GEN_MASK(4, 12),
+ .size = 4
+ },
+ {
+ .offset_ldw_lowerbound = PXP_REG_02_LOWERBOUND,
+ .offset_ldw_upperbound = PXP_REG_02_UPPERBOUND,
+ .offset_udw = {0},
+ .gen_mask = INTEL_GEN_MASK(4, 12),
+ .size = 4
+ }
+};
int i915_reg_read_ioctl(struct drm_device *dev,
void *data, struct drm_file *file)
@@ -2012,18 +2030,22 @@ int i915_reg_read_ioctl(struct drm_device *dev,
unsigned int flags;
int remain;
int ret = 0;
+ i915_reg_t offset_ldw;
entry = reg_read_whitelist;
remain = ARRAY_SIZE(reg_read_whitelist);
while (remain) {
- u32 entry_offset = i915_mmio_reg_offset(entry->offset_ldw);
+ u32 entry_offset_lb =
i915_mmio_reg_offset(entry->offset_ldw_lowerbound);
+ u32 entry_offset_ub =
i915_mmio_reg_offset(entry->offset_ldw_upperbound);
GEM_BUG_ON(!is_power_of_2(entry->size));
GEM_BUG_ON(entry->size > 8);
- GEM_BUG_ON(entry_offset & (entry->size - 1));
+ GEM_BUG_ON(entry_offset_lb & (entry->size - 1));
+ GEM_BUG_ON(entry_offset_ub & (entry->size - 1));
if (INTEL_INFO(i915)->gen_mask & entry->gen_mask &&
- entry_offset == (reg->offset & -entry->size))
+ entry_offset_lb <= (reg->offset & -entry->size) &&
+ (reg->offset & -entry->size) <= entry_offset_ub)
break;
entry++;
remain--;
@@ -2033,23 +2055,21 @@ int i915_reg_read_ioctl(struct drm_device *dev,
return -EINVAL;
flags = reg->offset & (entry->size - 1);
+ offset_ldw = _MMIO(reg->offset - flags);
with_intel_runtime_pm(&i915->runtime_pm, wakeref) {
if (entry->size == 8 && flags == I915_REG_READ_8B_WA)
reg->val = intel_uncore_read64_2x32(uncore,
- entry->offset_ldw,
+ offset_ldw,
entry->offset_udw);
else if (entry->size == 8 && flags == 0)
- reg->val = intel_uncore_read64(uncore,
- entry->offset_ldw);
+ reg->val = intel_uncore_read64(uncore, offset_ldw);
else if (entry->size == 4 && flags == 0)
- reg->val = intel_uncore_read(uncore, entry->offset_ldw);
+ reg->val = intel_uncore_read(uncore, offset_ldw);
else if (entry->size == 2 && flags == 0)
- reg->val = intel_uncore_read16(uncore,
- entry->offset_ldw);
+ reg->val = intel_uncore_read16(uncore, offset_ldw
[Intel-gfx] [RFC-v8 04/23] drm/i915/pxp: Create the arbitrary session after boot
Create the arbitrary session, with the fixed session id 0xf, after
system boot, for the case that application allocates the protected
buffer without establishing any protection session. Because the
hardware requires at least one alive session for protected buffer
creation. This arbitrary session needs to be re-created after
teardown or power event because hardware encryption key won't be
valid after such cases.
Signed-off-by: Huang, Sean Z
---
drivers/gpu/drm/i915/Makefile| 1 +
drivers/gpu/drm/i915/pxp/intel_pxp.c | 1 +
drivers/gpu/drm/i915/pxp/intel_pxp.h | 16 +++
drivers/gpu/drm/i915/pxp/intel_pxp_arb.c | 134 +++
drivers/gpu/drm/i915/pxp/intel_pxp_arb.h | 38 ++
drivers/gpu/drm/i915/pxp/intel_pxp_context.h | 6 +
drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 38 ++
drivers/gpu/drm/i915/pxp/intel_pxp_tee.h | 6 +
8 files changed, 240 insertions(+)
create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_arb.c
create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_arb.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 57447887d352..2c84f75b41da 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -258,6 +258,7 @@ i915-y += i915_perf.o
# Protected execution platform (PXP) support
i915-$(CONFIG_DRM_I915_PXP) += \
pxp/intel_pxp.o \
+ pxp/intel_pxp_arb.o \
pxp/intel_pxp_context.o \
pxp/intel_pxp_tee.o
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index 4104dd89ca7f..67bdaeb79b40 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -6,6 +6,7 @@
#include "intel_pxp.h"
#include "intel_pxp_context.h"
#include "intel_pxp_tee.h"
+#include "intel_pxp_arb.h"
/* KCR register definitions */
#define KCR_INIT_MMIO(0x320f0)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h
b/drivers/gpu/drm/i915/pxp/intel_pxp.h
index 7c3d49a6a3ab..1841a9aa972d 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
@@ -8,6 +8,22 @@
#include "intel_pxp_context.h"
+enum pxp_session_types {
+ SESSION_TYPE_TYPE0 = 0,
+ SESSION_TYPE_TYPE1 = 1,
+
+ SESSION_TYPE_MAX
+};
+
+enum pxp_protection_modes {
+ PROTECTION_MODE_NONE = 0,
+ PROTECTION_MODE_LM = 2,
+ PROTECTION_MODE_HM = 3,
+ PROTECTION_MODE_SM = 6,
+
+ PROTECTION_MODE_ALL
+};
+
struct intel_pxp {
struct pxp_context ctx;
};
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_arb.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_arb.c
new file mode 100644
index ..9611cd53d3a4
--- /dev/null
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_arb.c
@@ -0,0 +1,134 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright(c) 2020, Intel Corporation. All rights reserved.
+ */
+
+#include "gt/intel_context.h"
+#include "gt/intel_engine_pm.h"
+
+#include "intel_pxp_arb.h"
+#include "intel_pxp.h"
+#include "intel_pxp_context.h"
+#include "intel_pxp_tee.h"
+
+#define GEN12_KCR_SIP _MMIO(0x32260) /* KCR type0 session in play 0-31 */
+
+/* Arbitrary session */
+#define ARB_SESSION_INDEX 0xf
+#define ARB_SESSION_TYPE SESSION_TYPE_TYPE0
+#define ARB_PROTECTION_MODE PROTECTION_MODE_HM
+
+static bool is_hw_arb_session_in_play(struct intel_pxp *pxp)
+{
+ u32 regval_sip = 0;
+ intel_wakeref_t wakeref;
+ struct intel_gt *gt = container_of(pxp, struct intel_gt, pxp);
+
+ with_intel_runtime_pm(>->i915->runtime_pm, wakeref) {
+ regval_sip = intel_uncore_read(gt->uncore, GEN12_KCR_SIP);
+ }
+
+ return regval_sip & BIT(ARB_SESSION_INDEX);
+}
+
+/* wait hw session_in_play reg to match the current sw state */
+static int wait_arb_hw_sw_state(struct intel_pxp *pxp)
+{
+ const int max_retry = 10;
+ const int ms_delay = 10;
+ int retry = 0;
+ int ret;
+ struct pxp_protected_session *arb = &pxp->ctx.arb_session;
+
+ ret = -EINVAL;
+ for (retry = 0; retry < max_retry; retry++) {
+ if (is_hw_arb_session_in_play(pxp) ==
+ arb->is_in_play) {
+ ret = 0;
+ break;
+ }
+
+ msleep(ms_delay);
+ }
+
+ return ret;
+}
+
+static void arb_session_entry_init(struct intel_pxp *pxp)
+{
+ struct pxp_protected_session *arb = &pxp->ctx.arb_session;
+
+ arb->context_id = pxp->ctx.id;
+ arb->type = ARB_SESSION_TYPE;
+ arb->protection_mode = ARB_PROTECTION_MODE;
+ arb->index = ARB_SESSION_INDEX;
+ arb->is_in_play = false;
+}
+
+int intel_pxp_arb_reserve_session(struct intel_pxp *pxp)
+{
+ int ret;
+
+ lockdep_assert_held(&pxp->ctx.mutex);
+
+ arb_session_entry_init(pxp);
+ ret = wait_arb_hw_sw_state(pxp);
+
+ return ret;
+}
+
+/**
+ * intel_pxp_arb_mark_session_in_play - To put an reserved protected sessi
[Intel-gfx] [RFC-v8 23/23] drm/i915/pxp: Enable the PXP ioctl for protected session
In the previous commits, we have implemented the PXP ioctl
functions. Now we enable those handlers and expose them as PXP
ioctl, so allow the userspace driver can establish, set, or
destory the protected session via this ioctl.
Signed-off-by: Huang, Sean Z
---
drivers/gpu/drm/i915/i915_drv.c | 1 +
drivers/gpu/drm/i915/pxp/intel_pxp.c | 53
include/uapi/drm/i915_drm.h | 72
3 files changed, 73 insertions(+), 53 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index e74201e81369..201550ffb353 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1766,6 +1766,7 @@ static const struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_QUERY, i915_query_ioctl, DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_VM_CREATE, i915_gem_vm_create_ioctl,
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_VM_DESTROY, i915_gem_vm_destroy_ioctl,
DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(I915_PXP_OPS, i915_pxp_ops_ioctl, DRM_RENDER_ALLOW),
};
static const struct drm_driver driver = {
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index 3a49dd97cab2..51e09224d7c6 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -31,59 +31,6 @@ enum pxp_session_req {
PXP_REQ_SESSION_TERMINATE
};
-/*
- * struct pxp_sm_query_pxp_tag - Params to query the PXP tag of specified
- * session id and whether the session is alive from PXP state machine.
- */
-struct pxp_sm_query_pxp_tag {
- u32 session_is_alive;
- u32 pxp_tag; /* in - Session ID, out pxp tag */
-};
-
-/*
- * struct pxp_set_session_status_params - Params to reserved, set or destroy
- * the session from the PXP state machine.
- */
-struct pxp_set_session_status_params {
- u32 pxp_tag; /* in [optional], out pxp tag */
- u32 session_type; /* in, session type */
- u32 session_mode; /* in, session mode */
- u32 req_session_state; /* in, new session state */
-};
-
-/*
- * struct pxp_tee_io_message_params - Params to send/receive message to/from
TEE.
- */
-struct pxp_tee_io_message_params {
- u8 __user *msg_in; /* in - message input */
- u32 msg_in_size; /* in - message input size */
- u8 __user *msg_out; /* in - message output buffer */
- u32 msg_out_size; /* out- message output size from TEE */
- u32 msg_out_buf_size; /* in - message output buffer size */
-};
-
-/* struct pxp_info - Params for PXP operation. */
-struct pxp_info {
- u32 action; /* in - specified action of this operation */
- u32 sm_status; /* out - status output for this operation */
-
- union {
- /* in - action params to query PXP tag */
- struct pxp_sm_query_pxp_tag query_pxp_tag;
- /* in - action params to set the PXP session state */
- struct pxp_set_session_status_params set_session_status;
- /* in - action params to send TEE commands */
- struct pxp_tee_io_message_params tee_io_message;
- };
-} __attribute__((packed));
-
-struct drm_i915_pxp_ops {
- /* in - user space pointer to struct pxp_info */
- struct pxp_info __user *info_ptr;
- /* in - memory size that info_ptr points to */
- u32 info_size;
-};
-
static void intel_pxp_write_irq_mask_reg(struct intel_gt *gt, u32 mask)
{
lockdep_assert_held(>->irq_lock);
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index d6085a328b2c..17cf25bdc3c4 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -359,6 +359,7 @@ typedef struct _drm_i915_sarea {
#define DRM_I915_QUERY 0x39
#define DRM_I915_GEM_VM_CREATE 0x3a
#define DRM_I915_GEM_VM_DESTROY0x3b
+#define DRM_I915_PXP_OPS 0x3c
/* Must be kept compact -- no holes */
#define DRM_IOCTL_I915_INITDRM_IOW( DRM_COMMAND_BASE +
DRM_I915_INIT, drm_i915_init_t)
@@ -423,6 +424,7 @@ typedef struct _drm_i915_sarea {
#define DRM_IOCTL_I915_QUERY DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_QUERY, struct drm_i915_query)
#define DRM_IOCTL_I915_GEM_VM_CREATE DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_VM_CREATE, struct drm_i915_gem_vm_control)
#define DRM_IOCTL_I915_GEM_VM_DESTROY DRM_IOW (DRM_COMMAND_BASE +
DRM_I915_GEM_VM_DESTROY, struct drm_i915_gem_vm_control)
+#define DRM_IOCTL_I915_PXP_OPS DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_PXP_OPS, struct drm_i915_pxp_ops)
/* Allow drivers to submit batchbuffers directly to hardware, relying
* on the security mechanisms provided by hardware.
@@ -1964,6 +1966,76 @@ struct drm_i915_gem_vm_control {
__u32 vm_id;
};
+/*
+ * struct pxp_sm_query_pxp_tag - Params to query the PXP tag of specified
+ * session id and whether the session is alive from PXP state machine.
+ */
+s
[Intel-gfx] [RFC-v8 03/23] drm/i915/pxp: Implement funcs to create the TEE channel
Implement the funcs to create the TEE channel, so kernel can
send the TEE commands directly to TEE for creating the arbitrary
(defualt) session.
Signed-off-by: Huang, Sean Z
---
drivers/gpu/drm/i915/Makefile| 3 +-
drivers/gpu/drm/i915/i915_drv.c | 1 +
drivers/gpu/drm/i915/i915_drv.h | 6 ++
drivers/gpu/drm/i915/pxp/intel_pxp.c | 5 +
drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 132 +++
drivers/gpu/drm/i915/pxp/intel_pxp_tee.h | 14 +++
include/drm/i915_component.h | 1 +
include/drm/i915_pxp_tee_interface.h | 45
8 files changed, 206 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_tee.h
create mode 100644 include/drm/i915_pxp_tee_interface.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 53be29dbc07d..57447887d352 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -258,7 +258,8 @@ i915-y += i915_perf.o
# Protected execution platform (PXP) support
i915-$(CONFIG_DRM_I915_PXP) += \
pxp/intel_pxp.o \
- pxp/intel_pxp_context.o
+ pxp/intel_pxp_context.o \
+ pxp/intel_pxp_tee.o
# Post-mortem debug and GPU hang state capture
i915-$(CONFIG_DRM_I915_CAPTURE_ERROR) += i915_gpu_error.o
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 5708e11d917b..9299a456adb0 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -322,6 +322,7 @@ static int i915_driver_early_probe(struct drm_i915_private
*dev_priv)
mutex_init(&dev_priv->wm.wm_mutex);
mutex_init(&dev_priv->pps_mutex);
mutex_init(&dev_priv->hdcp_comp_mutex);
+ mutex_init(&dev_priv->pxp_tee_comp_mutex);
i915_memcpy_init_early(dev_priv);
intel_runtime_pm_init_early(&dev_priv->runtime_pm);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5d04b282c060..2e997f753054 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1215,6 +1215,12 @@ struct drm_i915_private {
/* Mutex to protect the above hdcp component related values. */
struct mutex hdcp_comp_mutex;
+ struct i915_pxp_comp_master *pxp_tee_master;
+ bool pxp_tee_comp_added;
+
+ /* Mutex to protect the above pxp_tee component related values. */
+ struct mutex pxp_tee_comp_mutex;
+
I915_SELFTEST_DECLARE(struct i915_selftest_stash selftest;)
/*
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index c4815950567d..4104dd89ca7f 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -5,6 +5,7 @@
#include "i915_drv.h"
#include "intel_pxp.h"
#include "intel_pxp_context.h"
+#include "intel_pxp_tee.h"
/* KCR register definitions */
#define KCR_INIT_MMIO(0x320f0)
@@ -24,6 +25,8 @@ int intel_pxp_init(struct intel_pxp *pxp)
intel_uncore_write(gt->uncore, KCR_INIT,
KCR_INIT_ALLOW_DISPLAY_ME_WRITES);
+ intel_pxp_tee_component_init(pxp);
+
drm_info(>->i915->drm, "Protected Xe Path (PXP) protected content
support initialized\n");
return 0;
@@ -31,5 +34,7 @@ int intel_pxp_init(struct intel_pxp *pxp)
void intel_pxp_uninit(struct intel_pxp *pxp)
{
+ intel_pxp_tee_component_fini(pxp);
+
intel_pxp_ctx_fini(&pxp->ctx);
}
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
new file mode 100644
index ..ca6b61099aee
--- /dev/null
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
@@ -0,0 +1,132 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright(c) 2020 Intel Corporation.
+ */
+
+#include
+#include "drm/i915_pxp_tee_interface.h"
+#include "drm/i915_component.h"
+#include "i915_drv.h"
+#include "intel_pxp.h"
+#include "intel_pxp_context.h"
+#include "intel_pxp_tee.h"
+
+static int intel_pxp_tee_io_message(struct intel_pxp *pxp,
+ void *msg_in, u32 msg_in_size,
+ void *msg_out, u32 *msg_out_size_ptr,
+ u32 msg_out_buf_size)
+{
+ int ret;
+ struct intel_gt *gt = container_of(pxp, typeof(*gt), pxp);
+ struct drm_i915_private *i915 = gt->i915;
+ struct i915_pxp_comp_master *pxp_tee_master = i915->pxp_tee_master;
+
+ if (!pxp_tee_master || !msg_in || !msg_out || !msg_out_size_ptr)
+ return -EINVAL;
+
+ lockdep_assert_held(&i915->pxp_tee_comp_mutex);
+
+ if (drm_debug_enabled(DRM_UT_DRIVER))
+ print_hex_dump(KERN_DEBUG, "TEE input message binaries:",
+ DUMP_PREFIX_OFFSET, 4, 4, msg_in, msg_in_size,
true);
+
+ ret = pxp_tee_master->ops->send(pxp_tee_master->tee_dev, msg_in,
msg_in_size);
+ if (ret) {
+
[Intel-gfx] [RFC-v8 13/23] drm/i915/pxp: Add plane decryption support
From: Anshuman Gupta
Add support to enable/disable PLANE_SURF Decryption Request bit.
It requires only to enable plane decryption support when following
condition met.
1. PAVP session is enabled.
2. Buffer object is protected.
v2:
- Rebased to libva_cp-drm-tip_tgl_cp tree.
- Used gen fb obj user_flags instead gem_object_metadata. [Krishna]
Cc: Bommu Krishnaiah
Cc: Huang, Sean Z
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_sprite.c | 21 ++---
drivers/gpu/drm/i915/i915_reg.h | 1 +
2 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
b/drivers/gpu/drm/i915/display/intel_sprite.c
index b7e208816074..273bdc031e8d 100644
--- a/drivers/gpu/drm/i915/display/intel_sprite.c
+++ b/drivers/gpu/drm/i915/display/intel_sprite.c
@@ -39,6 +39,8 @@
#include
#include
+#include "pxp/intel_pxp.h"
+
#include "i915_drv.h"
#include "i915_trace.h"
#include "i915_vgpu.h"
@@ -767,6 +769,11 @@ icl_program_input_csc(struct intel_plane *plane,
PLANE_INPUT_CSC_POSTOFF(pipe, plane_id, 2), 0x0);
}
+static bool intel_fb_obj_protected(const struct drm_i915_gem_object *obj)
+{
+ return obj->user_flags & I915_BO_PROTECTED ? true : false;
+}
+
static void
skl_plane_async_flip(struct intel_plane *plane,
const struct intel_crtc_state *crtc_state,
@@ -803,6 +810,7 @@ skl_program_plane(struct intel_plane *plane,
u32 surf_addr = plane_state->color_plane[color_plane].offset;
u32 stride = skl_plane_stride(plane_state, color_plane);
const struct drm_framebuffer *fb = plane_state->hw.fb;
+ const struct drm_i915_gem_object *obj = intel_fb_obj(fb);
int aux_plane = intel_main_to_aux_plane(fb, color_plane);
int crtc_x = plane_state->uapi.dst.x1;
int crtc_y = plane_state->uapi.dst.y1;
@@ -813,7 +821,7 @@ skl_program_plane(struct intel_plane *plane,
u8 alpha = plane_state->hw.alpha >> 8;
u32 plane_color_ctl = 0, aux_dist = 0;
unsigned long irqflags;
- u32 keymsk, keymax;
+ u32 keymsk, keymax, plane_surf;
u32 plane_ctl = plane_state->ctl;
plane_ctl |= skl_plane_ctl_crtc(crtc_state);
@@ -889,8 +897,15 @@ skl_program_plane(struct intel_plane *plane,
* the control register just before the surface register.
*/
intel_de_write_fw(dev_priv, PLANE_CTL(pipe, plane_id), plane_ctl);
- intel_de_write_fw(dev_priv, PLANE_SURF(pipe, plane_id),
- intel_plane_ggtt_offset(plane_state) + surf_addr);
+ plane_surf = intel_plane_ggtt_offset(plane_state) + surf_addr;
+
+ if (intel_pxp_gem_object_status(dev_priv) &&
+ intel_fb_obj_protected(obj))
+ plane_surf |= PLANE_SURF_DECRYPTION_ENABLED;
+ else
+ plane_surf &= ~PLANE_SURF_DECRYPTION_ENABLED;
+
+ intel_de_write_fw(dev_priv, PLANE_SURF(pipe, plane_id), plane_surf);
if (plane_state->scaler_id >= 0)
skl_program_scaler(plane, crtc_state, plane_state);
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 1e8dfe435ca8..0ea7e2a402ae 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7209,6 +7209,7 @@ enum {
#define _PLANE_SURF_3(pipe)_PIPE(pipe, _PLANE_SURF_3_A, _PLANE_SURF_3_B)
#define PLANE_SURF(pipe, plane)\
_MMIO_PLANE(plane, _PLANE_SURF_1(pipe), _PLANE_SURF_2(pipe))
+#define PLANE_SURF_DECRYPTION_ENABLEDREG_BIT(2)
#define _PLANE_OFFSET_1_B 0x711a4
#define _PLANE_OFFSET_2_B 0x712a4
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
