Re: [PATCH v2] drm/i915/hdcp: Add additional R0' wait

[Ramalingam C]

On 2020-05-20 at 15:50:15 -0400, Sean Paul wrote:
> On Wed, May 20, 2020 at 9:08 AM Sean Paul  wrote:
> >
> > From: Sean Paul 
> >
> > We're seeing some R0' mismatches in the field, particularly with
> > repeaters. I'm guessing the (already lenient) 300ms wait time isn't
> > enough for some setups. So add an additional wait when R0' is
> > mismatched.
> >
> 
> I think my guess was wrong and now suspect this issue is fixed with
> "drm/i915/hdcp: Avoid duplicate HDCP enables".
> 
> While this patch probably still has some value in cases where R0' is
> slow to update, I don't have any concrete examples where it helps.
Sean, completely agree it will help to authenticate the slower hdcp sink,
as this is not breaking the spec too. But could we please introduce extra
delays when we encounter such needs?

As you mentioned, We already have a 3 * 100 mSec,
where spec says HDCP sink should keep the R0' ready after the 100mSec
from aksv write.

-Ram
> 
> Sean
> 
> 
> > Signed-off-by: Sean Paul 
> >
> > Changes in v2:
> > - Actually add the delay in R0` wait (Ram)
> > ---
> >
> > Apologies, v1 was generated from a forward port from the CrOS kernel and
> > patch got confused and put the diff in V' wait instead of R0' wait.
> >
> > Pay closer attention, Sean.
> >
> >  drivers/gpu/drm/i915/display/intel_hdcp.c | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c 
> > b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > index 2cbc4619b4ce..3c2d8c0a6da6 100644
> > --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > @@ -743,6 +743,9 @@ static int intel_hdcp_auth(struct intel_connector 
> > *connector)
> > if (!wait_for(intel_de_read(dev_priv, HDCP_STATUS(dev_priv, 
> > cpu_transcoder, port)) &
> >   (HDCP_STATUS_RI_MATCH | HDCP_STATUS_ENC), 1))
> > break;
> > +
> > +   /* Maybe the sink is lazy, give it some more time */
> > +   usleep_range(1, 5);
> > }
> >
> > if (i == tries) {
> > --
> > Sean Paul, Software Engineer, Google / Chromium OS
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/i915/hdcp: Avoid duplicate HDCP enables

[Ramalingam C]

On 2020-05-20 at 15:47:44 -0400, Sean Paul wrote:
> From: Sean Paul 
> 
> If userspace sets the CP property to DESIRED while it's already ENABLED,
> the driver will try to re-enable HDCP. On some displays, this will
> result in R0' mismatches. I'm guessing this is because the display is
> still sending back Ri instead of re-authenticating.
> 
> At any rate, we can fix this inefficiency easily enough by just nooping
> the DESIRED property set if HDCP is already ENABLED.
Sean,

This will skip the hdcp enable.

But at present too we will be getting below WARN_ON from intel_hdcp_enable,
to indicate userspace is going wrong with request.
drm_WARN_ON(_priv->drm,
hdcp->value == DRM_MODE_CONTENT_PROTECTION_ENABLED);

And if we need to filter this out, could we validate the incoming hdcp request 
at
drm_atomic_connector_set_property() itself? No point in going into the
atomic commit without a valid request. something like

diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index a1e5e262bae2..d98b2eeae78d 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -746,6 +746,12 @@ static int drm_atomic_connector_set_property(struct 
drm_connector *connector,
DRM_DEBUG_KMS("only drivers can set CP Enabled\n");
return -EINVAL;
}
+   if (config->content_protection_property ==
+   DRM_MODE_CONTENT_PROTECTION_ENABLED &&
+   val == DRM_MODE_CONTENT_PROTECTION_DESIRED) {
+   DRM_DEBUG_KMS("Redundant req for content protection\n");
+   return -EINVAL;
+   }
state->content_protection = val;
} else if (property == config->hdcp_content_type_property) {
state->hdcp_content_type = val;

-Ram

> 
> Signed-off-by: Sean Paul 
> ---
> 
> I suspect this is the actual root cause I was chasing with
> "drm/i915/hdcp: Add additional R0' wait". I was able to reproduce the
> R0` messages by marking HDCP desired while it was already enabled. This
> _should_ work, but it seems like some displays handle it more graciously
> than others.
> 
> 
>  drivers/gpu/drm/i915/display/intel_hdcp.c | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c 
> b/drivers/gpu/drm/i915/display/intel_hdcp.c
> index 2cbc4619b4ce..f770fe0c5595 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> @@ -2156,12 +2156,16 @@ void intel_hdcp_atomic_check(struct drm_connector 
> *connector,
>   }
>  
>   /*
> -  * Nothing to do if the state didn't change, or HDCP was activated since
> -  * the last commit. And also no change in hdcp content type.
> +  * Nothing to do if content type is unchanged and one of:
> +  *  - state didn't change
> +  *  - HDCP was activated since the last commit
> +  *  - attempting to set to desired while already enabled
>*/
>   if (old_cp == new_cp ||
>   (old_cp == DRM_MODE_CONTENT_PROTECTION_DESIRED &&
> -  new_cp == DRM_MODE_CONTENT_PROTECTION_ENABLED)) {
> +  new_cp == DRM_MODE_CONTENT_PROTECTION_ENABLED) ||
> + (old_cp == DRM_MODE_CONTENT_PROTECTION_ENABLED &&
> +  new_cp == DRM_MODE_CONTENT_PROTECTION_DESIRED)) {
>   if (old_state->hdcp_content_type ==
>   new_state->hdcp_content_type)
>   return;
> -- 
> Sean Paul, Software Engineer, Google / Chromium OS
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[GIT PULL v3] mediatek drm next for 5.8

[Chun-Kuang Hu]

Hi, Dave & Daniel:

This include dpi pin mode swap, config mipi_tx current and impedance,
and some fixup. I drop backmerge patches and related fixup in this version.

The following changes since commit 8f3d9f354286745c751374f5f1fcafee6b3f3136:

  Linux 5.7-rc1 (2020-04-12 12:35:55 -0700)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git 
tags/mediatek-drm-next-5.8

for you to fetch changes up to 3852489c79abe31101f07e395c63cce64de0c6d6:

  drm/mediatek: Eliminate the magic number in array size (2020-05-21 00:10:08 
+0800)


Mediatek DRM Next for Linux 5.8


Anand K Mistry (1):
  drm/mediatek: Stop iterating dma addresses when sg_dma_len() == 0

Bernard Zhao (2):
  drm/mediatek: Cleanup coding style in mediatek a bit
  drm/mediatek: Eliminate the magic number in array size

Jitao Shi (6):
  dt-bindings: display: mediatek: control dpi pins mode to avoid leakage
  drm/mediatek: set dpi pin mode to gpio low to avoid leakage current
  dt-bindings: display: mediatek: add property to control mipi tx drive 
current
  dt-bindings: display: mediatek: get mipitx calibration data from nvmem
  drm/mediatek: add the mipitx driving control
  drm/mediatek: config mipitx impedance with calibration data

 .../bindings/display/mediatek/mediatek,dpi.txt |  6 +++
 .../bindings/display/mediatek/mediatek,dsi.txt | 10 
 drivers/gpu/drm/mediatek/mtk_dpi.c | 31 +
 drivers/gpu/drm/mediatek/mtk_drm_gem.c |  3 ++
 drivers/gpu/drm/mediatek/mtk_hdmi.c| 18 +++-
 drivers/gpu/drm/mediatek/mtk_mipi_tx.c | 54 ++
 drivers/gpu/drm/mediatek/mtk_mipi_tx.h |  4 ++
 drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c  | 28 +++
 8 files changed, 143 insertions(+), 11 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 1/2] drm/ioctl: Add a ioctl to set and get a label on GEM objects

[Emil Velikov]

On Thu, 21 May 2020 at 01:07, Rohan Garg  wrote:
>
> Hey Emil
> I've applied all the suggestions except the ones I discuss below.
>
> >
> > As a high-level question: how does this compare to VC4_LABEL_BO?
> > Is it possible to implement to replace or partially implement the vc4
> > one with this infra?
> >
> > IMHO this is something to aim for.
> >
>
> Yep, the intention is to replace the VC4 specific labeling with a more generic
> framework that all drivers can use.
>
>From a quick look the VC4 labeling combines user-space labels + in-kernel ones.
Seems like msm also has labeling - although in-kernel only.

So this series will help quite a bit, but in-kernel bits will remain.
Pretty sure we can live with that.

> > A handful of ideas and suggestions below:
> >
> > On Thu, 14 May 2020 at 16:05, Rohan Garg  wrote:
> > > Signed-off-by: Rohan Garg 
> > > Reported-by: kbuild test robot 
> > > Reported-by: Dan Carpenter 
> >
> > New functionality usually has suggested-by tags. Reported-by tags are
> > used when the feature isn't behaving as expected.
> >
>
> This was suggested as part of the previous review process [1].
>
The tag is used for bugfixes, not new features.
See the relevant section in Documentation/process/5.Posting.rst


> > > +
> > > +   kfree(gem_obj->label);
> > > +
> > > +   gem_obj->label = adopted_label;
> >
> > Do we have any protection of ->label wrt concurrent access? Say two
> > writers, attempting to both set the label.
> >
>
> Great catch. I'll protect this from concurrent access.
>
> >
> > > +
> > > +   if (!dev->driver->set_label || args->len > PAGE_SIZE)
> >
> > AFAICT the PAGE_SIZE check should be a EINVAL.
> >
> > Additionally, It would be better, to use the default implementation
> > when the function pointer is not explicitly set.
> > That should allow for more consistent and easier use.
> >
> > Think about the time gap (esp. for some distributions) between the
> > kernel feature landing and being generally accessible to userspace.
> >
>
> This is intentional since vmgfx uses TTM and the DRM helpers would not work.
> Sure, we could simply add a patch to the series that hooks up the relevant
> code to vmgfx and then calls the DRM label helper for all other drivers, but
> I'd rather have driver developers explicitly opt into this functionality.
>
How about we add a simple drm_core_check_feature(dev, DRIVER_GEM)
check + return appropriate errno.
Grep ^^ for examples.

The check will trigger on vmwgfx and some UMS drivers.

> > > +   return -EOPNOTSUPP;
> > > +
> > > +   if (!args->len)
> > > +   label = NULL;
> > > +   else if (args->len && args->label)
> > > +   label = strndup_user(u64_to_user_ptr(args->label),
> > > args->len); +   else
> >
> > Might be worth throwing EINVAL for !len && label... or perhaps not. In
> > either case please document it.
> >
>
> Hm, I'm not entirely sure what documentation I should add here since we
> already document the drm_handle_label struct in the relevant header.
>
Hmm brain fart - the comment should be for the getter. Will elaborate below.

> >
> > > +
> > > +   if (args->label)
> > > +   ret = copy_to_user(u64_to_user_ptr(args->label),
> > > +  label,
> > > +  args->len);
> > > +
> >
> > Consider the following - userspace allocates less memory than needed
> > for the whole string.
> > Be that size concerns or simply because it's interested only in the
> > first X bytes.
> >
> > If we're interested in supporting that, a simple min(args->len, len)
> > could be used.
> >
>
> I wouldn't be opposed to this if such a need arises in the future.
>
This cannot be changed in the future I'm afraid. The change is pretty
trivial although I haven't seen many ioctls do this.
Perhaps it's not worth it. Here's a quick example, esp for the
DRIVER_GEM thingy.

{
  ...

  if (dev->driver->get_label)
label = dev->driver->get_label(...);
  else if (drm_core_check_feature(dev, DRIVER_GEM)
label = generic_gem_impl(...);
  else
return -EOPNOTSUPP;

  if (!label)
return -EFAULT;

  args->len = strlen(label) + 1;

  if (args->label)
return copy_to_user(u64_to_user_ptr(args->label), label, args->len);

  return 0;
}

> > s/int/__u32/ + comment, currently no flags are defined.
> > > +#define DRM_IOCTL_HANDLE_SET_LABEL  DRM_IOWR(0xCF, struct
> > > drm_handle_label)
> > Pretty sure that WR is wrong here, although I don't recall we should
> > be using read or write only.
> > Unfortunately many drivers/ioctls get this wrong :-\
> >
>
> From a quick read of the IO{W,R} documentation, I suppose we should be marking
> SET_LABEL as DRM_IOW and GET_LABEL as DRM_IOR.
>
Are you sure GET_LABEL is unidirectional? The ioctl reads data from
userspace _and_ writes the string length back to userspace.

-Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org

Re: [PATCH v5 1/2] drm/ioctl: Add a ioctl to set and get a label on GEM objects

[Rohan Garg]

Hey Emil
I've applied all the suggestions except the ones I discuss below.

> 
> As a high-level question: how does this compare to VC4_LABEL_BO?
> Is it possible to implement to replace or partially implement the vc4
> one with this infra?
> 
> IMHO this is something to aim for.
> 

Yep, the intention is to replace the VC4 specific labeling with a more generic 
framework that all drivers can use.

> A handful of ideas and suggestions below:
> 
> On Thu, 14 May 2020 at 16:05, Rohan Garg  wrote:
> > Signed-off-by: Rohan Garg 
> > Reported-by: kbuild test robot 
> > Reported-by: Dan Carpenter 
> 
> New functionality usually has suggested-by tags. Reported-by tags are
> used when the feature isn't behaving as expected.
> 

This was suggested as part of the previous review process [1].

> > +
> > +   kfree(gem_obj->label);
> > +
> > +   gem_obj->label = adopted_label;
> 
> Do we have any protection of ->label wrt concurrent access? Say two
> writers, attempting to both set the label.
> 

Great catch. I'll protect this from concurrent access.

> 
> > +
> > +   if (!dev->driver->set_label || args->len > PAGE_SIZE)
> 
> AFAICT the PAGE_SIZE check should be a EINVAL.
> 
> Additionally, It would be better, to use the default implementation
> when the function pointer is not explicitly set.
> That should allow for more consistent and easier use.
> 
> Think about the time gap (esp. for some distributions) between the
> kernel feature landing and being generally accessible to userspace.
> 

This is intentional since vmgfx uses TTM and the DRM helpers would not work.
Sure, we could simply add a patch to the series that hooks up the relevant 
code to vmgfx and then calls the DRM label helper for all other drivers, but 
I'd rather have driver developers explicitly opt into this functionality.

> > +   return -EOPNOTSUPP;
> > +
> > +   if (!args->len)
> > +   label = NULL;
> > +   else if (args->len && args->label)
> > +   label = strndup_user(u64_to_user_ptr(args->label),
> > args->len); +   else
> 
> Might be worth throwing EINVAL for !len && label... or perhaps not. In
> either case please document it.
> 

Hm, I'm not entirely sure what documentation I should add here since we 
already document the drm_handle_label struct in the relevant header.

> 
> > +
> > +   if (args->label)
> > +   ret = copy_to_user(u64_to_user_ptr(args->label),
> > +  label,
> > +  args->len);
> > +
> 
> Consider the following - userspace allocates less memory than needed
> for the whole string.
> Be that size concerns or simply because it's interested only in the
> first X bytes.
> 
> If we're interested in supporting that, a simple min(args->len, len)
> could be used.
> 

I wouldn't be opposed to this if such a need arises in the future.

> s/int/__u32/ + comment, currently no flags are defined.
> > +#define DRM_IOCTL_HANDLE_SET_LABEL  DRM_IOWR(0xCF, struct
> > drm_handle_label)
> Pretty sure that WR is wrong here, although I don't recall we should
> be using read or write only.
> Unfortunately many drivers/ioctls get this wrong :-\
> 

>From a quick read of the IO{W,R} documentation, I suppose we should be marking 
SET_LABEL as DRM_IOW and GET_LABEL as DRM_IOR.

Thanks!
Rohan Garg

[1] https://patchwork.freedesktop.org/patch/335508/?
series=66752=4#comment_621167

signature.asc
Description: This is a digitally signed message part.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/exynos: Fix dma_parms allocation

[kbuild test robot]

Hi Marek,

I love your patch! Perhaps something to improve:

[auto build test WARNING on drm-exynos/exynos-drm-next]
[also build test WARNING on drm-intel/for-linux-next 
tegra-drm/drm/tegra/for-next v5.7-rc6 next-20200519]
[cannot apply to drm/drm-next]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:
https://github.com/0day-ci/linux/commits/Marek-Szyprowski/drm-exynos-Fix-dma_parms-allocation/20200521-015443
base:   https://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git 
exynos-drm-next
config: alpha-allyesconfig (attached as .config)
compiler: alpha-linux-gcc (GCC) 9.3.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=alpha 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot 

All warnings (new ones prefixed by >>, old ones prefixed by <<):

drivers/gpu/drm/exynos/exynos_drm_dma.c: In function 'drm_iommu_attach_device':
>> drivers/gpu/drm/exynos/exynos_drm_dma.c:47:6: warning: variable 'ret' set 
>> but not used [-Wunused-but-set-variable]
47 |  int ret;
|  ^~~

vim +/ret +47 drivers/gpu/drm/exynos/exynos_drm_dma.c

67fbf3a3ef84436c Andrzej Hajda2018-10-12  33  
67fbf3a3ef84436c Andrzej Hajda2018-10-12  34  /*
67fbf3a3ef84436c Andrzej Hajda2018-10-12  35   * drm_iommu_attach_device- 
attach device to iommu mapping
67fbf3a3ef84436c Andrzej Hajda2018-10-12  36   *
67fbf3a3ef84436c Andrzej Hajda2018-10-12  37   * @drm_dev: DRM device
67fbf3a3ef84436c Andrzej Hajda2018-10-12  38   * @subdrv_dev: device to be 
attach
67fbf3a3ef84436c Andrzej Hajda2018-10-12  39   *
67fbf3a3ef84436c Andrzej Hajda2018-10-12  40   * This function should be 
called by sub drivers to attach it to iommu
67fbf3a3ef84436c Andrzej Hajda2018-10-12  41   * mapping.
67fbf3a3ef84436c Andrzej Hajda2018-10-12  42   */
67fbf3a3ef84436c Andrzej Hajda2018-10-12  43  static int 
drm_iommu_attach_device(struct drm_device *drm_dev,
07dc3678bacc2a75 Marek Szyprowski 2020-03-09  44
struct device *subdrv_dev, void **dma_priv)
67fbf3a3ef84436c Andrzej Hajda2018-10-12  45  {
67fbf3a3ef84436c Andrzej Hajda2018-10-12  46struct 
exynos_drm_private *priv = drm_dev->dev_private;
67fbf3a3ef84436c Andrzej Hajda2018-10-12 @47int ret;
67fbf3a3ef84436c Andrzej Hajda2018-10-12  48  
67fbf3a3ef84436c Andrzej Hajda2018-10-12  49if 
(get_dma_ops(priv->dma_dev) != get_dma_ops(subdrv_dev)) {
6f83d20838c09936 Inki Dae 2019-04-15  50
DRM_DEV_ERROR(subdrv_dev, "Device %s lacks support for IOMMU\n",
67fbf3a3ef84436c Andrzej Hajda2018-10-12  51  
dev_name(subdrv_dev));
67fbf3a3ef84436c Andrzej Hajda2018-10-12  52return -EINVAL;
67fbf3a3ef84436c Andrzej Hajda2018-10-12  53}
67fbf3a3ef84436c Andrzej Hajda2018-10-12  54  
1698f69d5f384fad Marek Szyprowski 2020-05-20  55
dma_set_max_seg_size(subdrv_dev, DMA_BIT_MASK(32));
67fbf3a3ef84436c Andrzej Hajda2018-10-12  56if 
(IS_ENABLED(CONFIG_ARM_DMA_USE_IOMMU)) {
07dc3678bacc2a75 Marek Szyprowski 2020-03-09  57/*
07dc3678bacc2a75 Marek Szyprowski 2020-03-09  58 * Keep the 
original DMA mapping of the sub-device and
07dc3678bacc2a75 Marek Szyprowski 2020-03-09  59 * restore it 
on Exynos DRM detach, otherwise the DMA
07dc3678bacc2a75 Marek Szyprowski 2020-03-09  60 * framework 
considers it as IOMMU-less during the next
07dc3678bacc2a75 Marek Szyprowski 2020-03-09  61 * probe (in 
case of deferred probe or modular build)
07dc3678bacc2a75 Marek Szyprowski 2020-03-09  62 */
07dc3678bacc2a75 Marek Szyprowski 2020-03-09  63*dma_priv = 
to_dma_iommu_mapping(subdrv_dev);
07dc3678bacc2a75 Marek Szyprowski 2020-03-09  64if (*dma_priv)
67fbf3a3ef84436c Andrzej Hajda2018-10-12  65
arm_iommu_detach_device(subdrv_dev);
67fbf3a3ef84436c Andrzej Hajda2018-10-12  66  
67fbf3a3ef84436c Andrzej Hajda2018-10-12  67ret = 
arm_iommu_attach_device(subdrv_dev, priv->mapping);
67fbf3a3ef84436c Andrzej Hajda2018-10-12  68} else if 
(IS_ENABLED(CONFIG_IOMMU_DMA)) {
67fbf3a3ef84436c Andrzej Hajda2018-10-12  69ret = 
iommu_attach_device(priv->mapping, subdrv_dev);
67fbf3a3ef84436c Andrzej Hajda2018-10-12  70}
67fbf3a3ef84436c Andrzej Hajda2018-10-12  71  
67fbf3a3ef84436c Andrzej Hajda2018-10-12  72return 

Re: [PATCH 2/2] drm/amd/display: Enable fp16 also on DCE-11.0 - DCE-12.

[Mario Kleiner]

On Wed, May 20, 2020 at 9:07 PM Kazlauskas, Nicholas <
nicholas.kazlaus...@amd.com> wrote:

> On 2020-05-20 2:44 p.m., Mario Kleiner wrote:
> > On Wed, May 20, 2020 at 8:25 PM Alex Deucher  > > wrote:
> >
> > On Wed, May 20, 2020 at 12:39 PM Harry Wentland  > > wrote:
> >  >
> >  > On 2020-05-15 1:19 a.m., Mario Kleiner wrote:
> >  > > Testing on a Polaris11 gpu with DCE-11.2 suggests that it
> >  > > seems to work fine there, so optimistically enable it for
> >  > > DCE-11 and later.
> >  > >
> >  > > Signed-off-by: Mario Kleiner  > >
> >  > > ---
> >  > >  drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c | 2 +-
> >  > >  drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c | 2 +-
> >  > >  drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c | 2 +-
> >  > >  3 files changed, 3 insertions(+), 3 deletions(-)
> >  > >
> >  > > diff --git
> > a/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
> > b/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
> >  > > index 9597fc79d7fa..a043ddae5149 100644
> >  > > --- a/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
> >  > > +++ b/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
> >  > > @@ -410,7 +410,7 @@ static const struct dc_plane_cap plane_cap
> = {
> >  > >   .pixel_format_support = {
> >  > >   .argb = true,
> >  > >   .nv12 = false,
> >  > > - .fp16 = false
> >  > > + .fp16 = true
> >  >
> >  > Carrizo (DCE 11.0) has a HW bug where FP16 scaling doesn't work. I
> >  > recommend we leave it off here.
> >
> > I'll drop this hunk for upstream.
> >
> > Alex
> >
> >
> > Ok, no fixup patch needed from myself, thanks Alex. Does the scaling bug
> > refer to scaling the planes (those max_downscale_factor /
> > max_upscale_factor definitions seem to be unused) or the fp16 values
> itself?
> >
> > What about DCE 8 and DCE 10 hw capabilities wrt. fp16? Should i send
> > fp16 enable patches for those as well?
> >
> > -mario
>
> Yeah, the upscale and downscale factors were intended to block FP16
> accepted and reject the commit but I guess nobody ever added those to
> atomic check.
>
> I reviewed the patch with the idea in mind that we already blocked this
> on a DC level. We can re-enable it in the caps after this is in I think.
>
> Off the top of my head I don't remember what DCE8/DCE10 supports, but
> I'm also not sure if they even support sending the SDP message for those
> to really be usable.
>

While HDR is the typical user for fp16, even on SDR displays, without any
HDR signalling, fp16 should give an additional bit of precision ~ 11 bpc
effective in standard 0.0 - 1.0 unorm range on a 12 bit pipeline with a 12
bpc panel or even on a 10 bpc panel with dithering. Useful for
neuroscience/medical research applications or the color precision obsessed
people. I take every bit i can get ;)

-mario



> Regards,
> Nicholas Kazlauskas
>
> >
> >  >
> >  > Harry
> >  >
> >  > >   },
> >  > >
> >  > >   .max_upscale_factor = {
> >  > > diff --git
> > a/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c
> > b/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c
> >  > > index 4a7796de2ff5..51b3fe502670 100644
> >  > > --- a/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c
> >  > > +++ b/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c
> >  > > @@ -411,7 +411,7 @@ static const struct dc_plane_cap plane_cap
> = {
> >  > >   .pixel_format_support = {
> >  > >   .argb = true,
> >  > >   .nv12 = false,
> >  > > - .fp16 = false
> >  > > + .fp16 = true
> >  > >   },
> >  > >
> >  > >   .max_upscale_factor = {
> >  > > diff --git
> > a/drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c
> > b/drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c
> >  > > index 9a9764cbd78d..8f362e8c1787 100644
> >  > > --- a/drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c
> >  > > +++ b/drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c
> >  > > @@ -516,7 +516,7 @@ static const struct dc_plane_cap plane_cap
> = {
> >  > >   .pixel_format_support = {
> >  > >   .argb = true,
> >  > >   .nv12 = false,
> >  > > - .fp16 = false
> >  > > + .fp16 = true
> >  > >   },
> >  > >
> >  > >   .max_upscale_factor = {
> >  > >
> >  > ___
> >  > dri-devel mailing list
> >  > 

Re: [PATCH v2] drm/i915/hdcp: Add additional R0' wait

[Sean Paul]

On Wed, May 20, 2020 at 9:08 AM Sean Paul  wrote:
>
> From: Sean Paul 
>
> We're seeing some R0' mismatches in the field, particularly with
> repeaters. I'm guessing the (already lenient) 300ms wait time isn't
> enough for some setups. So add an additional wait when R0' is
> mismatched.
>

I think my guess was wrong and now suspect this issue is fixed with
"drm/i915/hdcp: Avoid duplicate HDCP enables".

While this patch probably still has some value in cases where R0' is
slow to update, I don't have any concrete examples where it helps.

Sean


> Signed-off-by: Sean Paul 
>
> Changes in v2:
> - Actually add the delay in R0` wait (Ram)
> ---
>
> Apologies, v1 was generated from a forward port from the CrOS kernel and
> patch got confused and put the diff in V' wait instead of R0' wait.
>
> Pay closer attention, Sean.
>
>  drivers/gpu/drm/i915/display/intel_hdcp.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c 
> b/drivers/gpu/drm/i915/display/intel_hdcp.c
> index 2cbc4619b4ce..3c2d8c0a6da6 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> @@ -743,6 +743,9 @@ static int intel_hdcp_auth(struct intel_connector 
> *connector)
> if (!wait_for(intel_de_read(dev_priv, HDCP_STATUS(dev_priv, 
> cpu_transcoder, port)) &
>   (HDCP_STATUS_RI_MATCH | HDCP_STATUS_ENC), 1))
> break;
> +
> +   /* Maybe the sink is lazy, give it some more time */
> +   usleep_range(1, 5);
> }
>
> if (i == tries) {
> --
> Sean Paul, Software Engineer, Google / Chromium OS
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/i915/hdcp: Avoid duplicate HDCP enables

[Sean Paul]

From: Sean Paul 

If userspace sets the CP property to DESIRED while it's already ENABLED,
the driver will try to re-enable HDCP. On some displays, this will
result in R0' mismatches. I'm guessing this is because the display is
still sending back Ri instead of re-authenticating.

At any rate, we can fix this inefficiency easily enough by just nooping
the DESIRED property set if HDCP is already ENABLED.

Signed-off-by: Sean Paul 
---

I suspect this is the actual root cause I was chasing with
"drm/i915/hdcp: Add additional R0' wait". I was able to reproduce the
R0` messages by marking HDCP desired while it was already enabled. This
_should_ work, but it seems like some displays handle it more graciously
than others.


 drivers/gpu/drm/i915/display/intel_hdcp.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c 
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 2cbc4619b4ce..f770fe0c5595 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -2156,12 +2156,16 @@ void intel_hdcp_atomic_check(struct drm_connector 
*connector,
}
 
/*
-* Nothing to do if the state didn't change, or HDCP was activated since
-* the last commit. And also no change in hdcp content type.
+* Nothing to do if content type is unchanged and one of:
+*  - state didn't change
+*  - HDCP was activated since the last commit
+*  - attempting to set to desired while already enabled
 */
if (old_cp == new_cp ||
(old_cp == DRM_MODE_CONTENT_PROTECTION_DESIRED &&
-new_cp == DRM_MODE_CONTENT_PROTECTION_ENABLED)) {
+new_cp == DRM_MODE_CONTENT_PROTECTION_ENABLED) ||
+   (old_cp == DRM_MODE_CONTENT_PROTECTION_ENABLED &&
+new_cp == DRM_MODE_CONTENT_PROTECTION_DESIRED)) {
if (old_state->hdcp_content_type ==
new_state->hdcp_content_type)
return;
-- 
Sean Paul, Software Engineer, Google / Chromium OS

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/amd/amdkfd: Fix large framesize for kfd_smi_ev_read()

[Felix Kuehling]

Am 2020-05-20 um 9:53 a.m. schrieb Aurabindo Pillai:
> The buffer allocated is of 1024 bytes. Allocate this from
> heap instead of stack.
>
> Also remove check for stack size since we're allocating from heap
>
> Signed-off-by: Aurabindo Pillai 
> Tested-by: Amber Lin 

See one comment inline. With that fixed, the patch is

Reviewed-by: Felix Kuehling 


> ---
>  drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c | 26 +++--
>  1 file changed, 19 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c 
> b/drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c
> index f5fd18eacf0d..5aebe169f8c6 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c
> @@ -77,9 +77,11 @@ static ssize_t kfd_smi_ev_read(struct file *filep, char 
> __user *user,
>   int ret;
>   size_t to_copy;
>   struct kfd_smi_client *client = filep->private_data;
> - unsigned char buf[MAX_KFIFO_SIZE];
> + unsigned char *buf;
>  
> - BUILD_BUG_ON(MAX_KFIFO_SIZE > 1024);
> + buf = kzalloc(MAX_KFIFO_SIZE * sizeof(*buf), GFP_KERNEL);

kzalloc is not necessary here, you could use kmalloc. The part of that
allocation that matters will be overwritten by kfifo_out.

Regards,
  Felix


> + if (!buf)
> + return -ENOMEM;
>  
>   /* kfifo_to_user can sleep so we can't use spinlock protection around
>* it. Instead, we kfifo out as spinlocked then copy them to the user.
> @@ -88,19 +90,29 @@ static ssize_t kfd_smi_ev_read(struct file *filep, char 
> __user *user,
>   to_copy = kfifo_len(>fifo);
>   if (!to_copy) {
>   spin_unlock(>lock);
> - return -EAGAIN;
> + ret = -EAGAIN;
> + goto ret_err;
>   }
>   to_copy = min3(size, sizeof(buf), to_copy);
>   ret = kfifo_out(>fifo, buf, to_copy);
>   spin_unlock(>lock);
> - if (ret <= 0)
> - return -EAGAIN;
> + if (ret <= 0) {
> + ret = -EAGAIN;
> + goto ret_err;
> + }
>  
>   ret = copy_to_user(user, buf, to_copy);
> - if (ret)
> - return -EFAULT;
> + if (ret) {
> + ret = -EFAULT;
> + goto ret_err;
> + }
>  
> + kfree(buf);
>   return to_copy;
> +
> +ret_err:
> + kfree(buf);
> + return ret;
>  }
>  
>  static ssize_t kfd_smi_ev_write(struct file *filep, const char __user *user,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm/amd/display: Enable fp16 also on DCE-11.0 - DCE-12.

[Kazlauskas, Nicholas]

On 2020-05-20 2:44 p.m., Mario Kleiner wrote:
On Wed, May 20, 2020 at 8:25 PM Alex Deucher > wrote:


On Wed, May 20, 2020 at 12:39 PM Harry Wentland mailto:hwent...@amd.com>> wrote:
 >
 > On 2020-05-15 1:19 a.m., Mario Kleiner wrote:
 > > Testing on a Polaris11 gpu with DCE-11.2 suggests that it
 > > seems to work fine there, so optimistically enable it for
 > > DCE-11 and later.
 > >
 > > Signed-off-by: Mario Kleiner mailto:mario.kleiner...@gmail.com>>
 > > ---
 > >  drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c | 2 +-
 > >  drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c | 2 +-
 > >  drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c | 2 +-
 > >  3 files changed, 3 insertions(+), 3 deletions(-)
 > >
 > > diff --git
a/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
b/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
 > > index 9597fc79d7fa..a043ddae5149 100644
 > > --- a/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
 > > +++ b/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
 > > @@ -410,7 +410,7 @@ static const struct dc_plane_cap plane_cap = {
 > >               .pixel_format_support = {
 > >                               .argb = true,
 > >                               .nv12 = false,
 > > -                             .fp16 = false
 > > +                             .fp16 = true
 >
 > Carrizo (DCE 11.0) has a HW bug where FP16 scaling doesn't work. I
 > recommend we leave it off here.

I'll drop this hunk for upstream.

Alex


Ok, no fixup patch needed from myself, thanks Alex. Does the scaling bug 
refer to scaling the planes (those max_downscale_factor / 
max_upscale_factor definitions seem to be unused) or the fp16 values itself?


What about DCE 8 and DCE 10 hw capabilities wrt. fp16? Should i send 
fp16 enable patches for those as well?


-mario


Yeah, the upscale and downscale factors were intended to block FP16 
accepted and reject the commit but I guess nobody ever added those to 
atomic check.


I reviewed the patch with the idea in mind that we already blocked this 
on a DC level. We can re-enable it in the caps after this is in I think.


Off the top of my head I don't remember what DCE8/DCE10 supports, but 
I'm also not sure if they even support sending the SDP message for those 
to really be usable.


Regards,
Nicholas Kazlauskas



 >
 > Harry
 >
 > >               },
 > >
 > >               .max_upscale_factor = {
 > > diff --git
a/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c
b/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c
 > > index 4a7796de2ff5..51b3fe502670 100644
 > > --- a/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c
 > > +++ b/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c
 > > @@ -411,7 +411,7 @@ static const struct dc_plane_cap plane_cap = {
 > >       .pixel_format_support = {
 > >                       .argb = true,
 > >                       .nv12 = false,
 > > -                     .fp16 = false
 > > +                     .fp16 = true
 > >       },
 > >
 > >       .max_upscale_factor = {
 > > diff --git
a/drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c
b/drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c
 > > index 9a9764cbd78d..8f362e8c1787 100644
 > > --- a/drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c
 > > +++ b/drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c
 > > @@ -516,7 +516,7 @@ static const struct dc_plane_cap plane_cap = {
 > >       .pixel_format_support = {
 > >                       .argb = true,
 > >                       .nv12 = false,
 > > -                     .fp16 = false
 > > +                     .fp16 = true
 > >       },
 > >
 > >       .max_upscale_factor = {
 > >
 > ___
 > dri-devel mailing list
 > dri-devel@lists.freedesktop.org

 > https://lists.freedesktop.org/mailman/listinfo/dri-devel




___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm/amd/display: Enable fp16 also on DCE-11.0 - DCE-12.

[Mario Kleiner]

On Wed, May 20, 2020 at 8:25 PM Alex Deucher  wrote:

> On Wed, May 20, 2020 at 12:39 PM Harry Wentland  wrote:
> >
> > On 2020-05-15 1:19 a.m., Mario Kleiner wrote:
> > > Testing on a Polaris11 gpu with DCE-11.2 suggests that it
> > > seems to work fine there, so optimistically enable it for
> > > DCE-11 and later.
> > >
> > > Signed-off-by: Mario Kleiner 
> > > ---
> > >  drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c | 2 +-
> > >  drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c | 2 +-
> > >  drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c | 2 +-
> > >  3 files changed, 3 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
> b/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
> > > index 9597fc79d7fa..a043ddae5149 100644
> > > --- a/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
> > > +++ b/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
> > > @@ -410,7 +410,7 @@ static const struct dc_plane_cap plane_cap = {
> > >   .pixel_format_support = {
> > >   .argb = true,
> > >   .nv12 = false,
> > > - .fp16 = false
> > > + .fp16 = true
> >
> > Carrizo (DCE 11.0) has a HW bug where FP16 scaling doesn't work. I
> > recommend we leave it off here.
>
> I'll drop this hunk for upstream.
>
> Alex
>
>
Ok, no fixup patch needed from myself, thanks Alex. Does the scaling bug
refer to scaling the planes (those max_downscale_factor /
max_upscale_factor definitions seem to be unused) or the fp16 values itself?

What about DCE 8 and DCE 10 hw capabilities wrt. fp16? Should i send fp16
enable patches for those as well?

-mario

>
> > Harry
> >
> > >   },
> > >
> > >   .max_upscale_factor = {
> > > diff --git a/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c
> b/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c
> > > index 4a7796de2ff5..51b3fe502670 100644
> > > --- a/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c
> > > +++ b/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c
> > > @@ -411,7 +411,7 @@ static const struct dc_plane_cap plane_cap = {
> > >   .pixel_format_support = {
> > >   .argb = true,
> > >   .nv12 = false,
> > > - .fp16 = false
> > > + .fp16 = true
> > >   },
> > >
> > >   .max_upscale_factor = {
> > > diff --git a/drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c
> b/drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c
> > > index 9a9764cbd78d..8f362e8c1787 100644
> > > --- a/drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c
> > > +++ b/drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c
> > > @@ -516,7 +516,7 @@ static const struct dc_plane_cap plane_cap = {
> > >   .pixel_format_support = {
> > >   .argb = true,
> > >   .nv12 = false,
> > > - .fp16 = false
> > > + .fp16 = true
> > >   },
> > >
> > >   .max_upscale_factor = {
> > >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3] drm/amdgpu: off by one in amdgpu_device_attr_create_groups() error handling

[Alex Deucher]

Applied.  Thanks!

Alex

On Wed, May 20, 2020 at 11:33 AM Christian König 
wrote:

> Am 20.05.20 um 17:31 schrieb Ruhl, Michael J:
> >> -Original Message-
> >> From: Dan Carpenter 
> >> Sent: Wednesday, May 20, 2020 11:26 AM
> >> To: Alex Deucher ; Kevin Wang
> >> ; Ruhl, Michael J 
> >> Cc: Christian König ; David Airlie
> >> ; Daniel Vetter ; Evan Quan
> >> ; Rui Huang ; Kenneth Feng
> >> ; Yintian Tao ; Hawking Zhang
> >> ; amd-...@lists.freedesktop.org; dri-
> >> de...@lists.freedesktop.org; linux-ker...@vger.kernel.org; kernel-
> >> janit...@vger.kernel.org
> >> Subject: [PATCH v3] drm/amdgpu: off by one in
> >> amdgpu_device_attr_create_groups() error handling
> >>
> >> This loop in the error handling code should start a "i - 1" and end at
> >> "i == 0".  Currently it starts a "i" and ends at "i == 1".  The result
> >> is that it removes one attribute that wasn't created yet, and leaks the
> >> zeroeth attribute.
> >>
> >> Fixes: 4e01847c38f7 ("drm/amdgpu: optimize amdgpu device attribute
> code")
> >> Signed-off-by: Dan Carpenter 
> >> ---
> >> v2: style change
> >> v3: Fix embarrassing typo in the subject
> > 
> >
> > Acked-by: Michael J. Ruhl 
>
> Reviewed-by: Christian König 
>
> >
> > m
> >> drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c   | 3 +--
> >> 1 files changed, 1 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
> >> b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
> >> index b75362bf0742..e809534fabd4 100644
> >> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
> >> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
> >> @@ -1942,9 +1942,8 @@ static int amdgpu_device_attr_create_groups(struct
> >> amdgpu_device *adev,
> >>  return 0;
> >>
> >> failed:
> >> -for (; i > 0; i--) {
> >> +while (i--)
> >>  amdgpu_device_attr_remove(adev, [i]);
> >> -}
> >>
> >>  return ret;
> >> }
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm/amd/display: Enable fp16 also on DCE-11.0 - DCE-12.

[Alex Deucher]

On Wed, May 20, 2020 at 12:39 PM Harry Wentland  wrote:
>
> On 2020-05-15 1:19 a.m., Mario Kleiner wrote:
> > Testing on a Polaris11 gpu with DCE-11.2 suggests that it
> > seems to work fine there, so optimistically enable it for
> > DCE-11 and later.
> >
> > Signed-off-by: Mario Kleiner 
> > ---
> >  drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c | 2 +-
> >  drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c | 2 +-
> >  drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c | 2 +-
> >  3 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c 
> > b/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
> > index 9597fc79d7fa..a043ddae5149 100644
> > --- a/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
> > +++ b/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
> > @@ -410,7 +410,7 @@ static const struct dc_plane_cap plane_cap = {
> >   .pixel_format_support = {
> >   .argb = true,
> >   .nv12 = false,
> > - .fp16 = false
> > + .fp16 = true
>
> Carrizo (DCE 11.0) has a HW bug where FP16 scaling doesn't work. I
> recommend we leave it off here.

I'll drop this hunk for upstream.

Alex

>
> Harry
>
> >   },
> >
> >   .max_upscale_factor = {
> > diff --git a/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c 
> > b/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c
> > index 4a7796de2ff5..51b3fe502670 100644
> > --- a/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c
> > +++ b/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c
> > @@ -411,7 +411,7 @@ static const struct dc_plane_cap plane_cap = {
> >   .pixel_format_support = {
> >   .argb = true,
> >   .nv12 = false,
> > - .fp16 = false
> > + .fp16 = true
> >   },
> >
> >   .max_upscale_factor = {
> > diff --git a/drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c 
> > b/drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c
> > index 9a9764cbd78d..8f362e8c1787 100644
> > --- a/drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c
> > +++ b/drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c
> > @@ -516,7 +516,7 @@ static const struct dc_plane_cap plane_cap = {
> >   .pixel_format_support = {
> >   .argb = true,
> >   .nv12 = false,
> > - .fp16 = false
> > + .fp16 = true
> >   },
> >
> >   .max_upscale_factor = {
> >
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/amd/amdkfd: Fix large framesize for kfd_smi_ev_read()

[Alex Deucher]

On Wed, May 20, 2020 at 9:53 AM Aurabindo Pillai
 wrote:
>
> The buffer allocated is of 1024 bytes. Allocate this from
> heap instead of stack.
>
> Also remove check for stack size since we're allocating from heap
>
> Signed-off-by: Aurabindo Pillai 
> Tested-by: Amber Lin 

Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c | 26 +++--
>  1 file changed, 19 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c 
> b/drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c
> index f5fd18eacf0d..5aebe169f8c6 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c
> @@ -77,9 +77,11 @@ static ssize_t kfd_smi_ev_read(struct file *filep, char 
> __user *user,
> int ret;
> size_t to_copy;
> struct kfd_smi_client *client = filep->private_data;
> -   unsigned char buf[MAX_KFIFO_SIZE];
> +   unsigned char *buf;
>
> -   BUILD_BUG_ON(MAX_KFIFO_SIZE > 1024);
> +   buf = kzalloc(MAX_KFIFO_SIZE * sizeof(*buf), GFP_KERNEL);
> +   if (!buf)
> +   return -ENOMEM;
>
> /* kfifo_to_user can sleep so we can't use spinlock protection around
>  * it. Instead, we kfifo out as spinlocked then copy them to the user.
> @@ -88,19 +90,29 @@ static ssize_t kfd_smi_ev_read(struct file *filep, char 
> __user *user,
> to_copy = kfifo_len(>fifo);
> if (!to_copy) {
> spin_unlock(>lock);
> -   return -EAGAIN;
> +   ret = -EAGAIN;
> +   goto ret_err;
> }
> to_copy = min3(size, sizeof(buf), to_copy);
> ret = kfifo_out(>fifo, buf, to_copy);
> spin_unlock(>lock);
> -   if (ret <= 0)
> -   return -EAGAIN;
> +   if (ret <= 0) {
> +   ret = -EAGAIN;
> +   goto ret_err;
> +   }
>
> ret = copy_to_user(user, buf, to_copy);
> -   if (ret)
> -   return -EFAULT;
> +   if (ret) {
> +   ret = -EFAULT;
> +   goto ret_err;
> +   }
>
> +   kfree(buf);
> return to_copy;
> +
> +ret_err:
> +   kfree(buf);
> +   return ret;
>  }
>
>  static ssize_t kfd_smi_ev_write(struct file *filep, const char __user *user,
> --
> 2.25.1
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/amdgpu/smu10: Replace one-element array and use struct_size() helper

[Alex Deucher]

Applied.  thanks!

Alex

On Wed, May 20, 2020 at 3:42 AM Christian König
 wrote:
>
> Am 20.05.20 um 00:55 schrieb Gustavo A. R. Silva:
> > The current codebase makes use of one-element arrays in the following
> > form:
> >
> > struct something {
> >  int length;
> >  u8 data[1];
> > };
> >
> > struct something *instance;
> >
> > instance = kmalloc(sizeof(*instance) + size, GFP_KERNEL);
> > instance->length = size;
> > memcpy(instance->data, source, size);
> >
> > but the preferred mechanism to declare variable-length types such as
> > these ones is a flexible array member[1][2], introduced in C99:
> >
> > struct foo {
> >  int stuff;
> >  struct boo array[];
> > };
> >
> > By making use of the mechanism above, we will get a compiler warning
> > in case the flexible array does not occur last in the structure, which
> > will help us prevent some kind of undefined behavior bugs from being
> > inadvertently introduced[3] to the codebase from now on. So, replace
> > the one-element array with a flexible-array member.
> >
> > Also, make use of the new struct_size() helper to properly calculate the
> > size of struct smu10_voltage_dependency_table.
> >
> > This issue was found with the help of Coccinelle and, audited and fixed
> > _manually_.
> >
> > [1] 
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgcc.gnu.org%2Fonlinedocs%2Fgcc%2FZero-Length.htmldata=02%7C01%7Cchristian.koenig%40amd.com%7C8a400bdb88924a1d951508d7fc471966%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637255254622039268sdata=ILOPPn17c%2B3oyLLdh%2BgH2b%2B8RdhWuTFGxruRD7GUHOo%3Dreserved=0
> > [2] 
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FKSPP%2Flinux%2Fissues%2F21data=02%7C01%7Cchristian.koenig%40amd.com%7C8a400bdb88924a1d951508d7fc471966%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637255254622039268sdata=lCr5Otij55Snq27BDp4RmtW4hNhOS%2Bm4vSUOOAz07XA%3Dreserved=0
> > [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")
> >
> > Signed-off-by: Gustavo A. R. Silva 
>
> Acked-by: Christian König 
>
> May I suggest that we add a section how to correctly do this to
> Documentation/process/coding-style.rst or similar document?
>
> I've seen a bunch of different approaches and some even doesn't work
> with some gcc versions and result in a broken binary.
>
> Thanks,
> Christian.
>
> > ---
> >   drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c | 6 ++
> >   drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.h | 2 +-
> >   2 files changed, 3 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c 
> > b/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
> > index 246bb9ac557d8..c9cfe90a29471 100644
> > --- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
> > +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
> > @@ -410,12 +410,10 @@ static int 
> > smu10_get_clock_voltage_dependency_table(struct pp_hwmgr *hwmgr,
> >   struct smu10_voltage_dependency_table **pptable,
> >   uint32_t num_entry, const DpmClock_t 
> > *pclk_dependency_table)
> >   {
> > - uint32_t table_size, i;
> > + uint32_t i;
> >   struct smu10_voltage_dependency_table *ptable;
> >
> > - table_size = sizeof(uint32_t) + sizeof(struct 
> > smu10_voltage_dependency_table) * num_entry;
> > - ptable = kzalloc(table_size, GFP_KERNEL);
> > -
> > + ptable = kzalloc(struct_size(ptable, entries, num_entry), GFP_KERNEL);
> >   if (NULL == ptable)
> >   return -ENOMEM;
> >
> > diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.h 
> > b/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.h
> > index 1fb296a996f3a..0f969de10fabc 100644
> > --- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.h
> > +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.h
> > @@ -192,7 +192,7 @@ struct smu10_clock_voltage_dependency_record {
> >
> >   struct smu10_voltage_dependency_table {
> >   uint32_t count;
> > - struct smu10_clock_voltage_dependency_record entries[1];
> > + struct smu10_clock_voltage_dependency_record entries[];
> >   };
> >
> >   struct smu10_clock_voltage_information {
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 3/3] misc/habalabs: don't set default fence_ops->wait

[Oded Gabbay]

On Wed, May 20, 2020 at 9:05 PM Daniel Vetter  wrote:
>
> On Thu, May 14, 2020 at 02:38:38PM +0300, Oded Gabbay wrote:
> > On Tue, May 12, 2020 at 9:12 AM Daniel Vetter  
> > wrote:
> > >
> > > On Tue, May 12, 2020 at 4:14 AM Dave Airlie  wrote:
> > > >
> > > > On Mon, 11 May 2020 at 19:37, Oded Gabbay  wrote:
> > > > >
> > > > > On Mon, May 11, 2020 at 12:11 PM Daniel Vetter 
> > > > >  wrote:
> > > > > >
> > > > > > It's the default.
> > > > > Thanks for catching that.
> > > > >
> > > > > >
> > > > > > Also so much for "we're not going to tell the graphics people how to
> > > > > > review their code", dma_fence is a pretty core piece of gpu driver
> > > > > > infrastructure. And it's very much uapi relevant, including piles of
> > > > > > corresponding userspace protocols and libraries for how to pass 
> > > > > > these
> > > > > > around.
> > > > > >
> > > > > > Would be great if habanalabs would not use this (from a quick look
> > > > > > it's not needed at all), since open source the userspace and playing
> > > > > > by the usual rules isn't on the table. If that's not possible 
> > > > > > (because
> > > > > > it's actually using the uapi part of dma_fence to interact with gpu
> > > > > > drivers) then we have exactly what everyone promised we'd want to
> > > > > > avoid.
> > > > >
> > > > > We don't use the uapi parts, we currently only using the fencing and
> > > > > signaling ability of this module inside our kernel code. But maybe I
> > > > > didn't understand what you request. You want us *not* to use this
> > > > > well-written piece of kernel code because it is only used by graphics
> > > > > drivers ?
> > > > > I'm sorry but I don't get this argument, if this is indeed what you 
> > > > > meant.
> > > >
> > > > We would rather drivers using a feature that has requirements on
> > > > correct userspace implementations of the feature have a userspace that
> > > > is open source and auditable.
> > > >
> > > > Fencing is tricky, cross-device fencing is really tricky, and having
> > > > the ability for a closed userspace component to mess up other people's
> > > > drivers, think i915 shared with closed habana userspace and shared
> > > > fences, decreases ability to debug things.
> > > >
> > > > Ideally we wouldn't offer users known untested/broken scenarios, so
> > > > yes we'd prefer that drivers that intend to expose a userspace fencing
> > > > api around dma-fence would adhere to the rules of the gpu drivers.
> > > >
> > > > I'm not say you have to drop using dma-fence, but if you move towards
> > > > cross-device stuff I believe other drivers would be correct in
> > > > refusing to interact with fences from here.
> > >
> > > The flip side is if you only used dma-fence.c "because it's there",
> > > and not because it comes with an uapi attached and a cross-driver
> > > kernel internal contract for how to interact with gpu drivers, then
> > > there's really not much point in using it. It's a custom-rolled
> > > wait_queue/event thing, that's all. Without the gpu uapi and gpu
> > > cross-driver contract it would be much cleaner to just use wait_queue
> > > directly, and that's a construct all kernel developers understand, not
> > > just gpu folks. From a quick look at least habanalabs doesn't use any
> > > of these uapi/cross-driver/gpu bits.
> > > -Daniel
> >
> > Hi Daniel,
> > I want to say explicitly that we don't use the dma-buf uapi parts, nor
> > we intend to use them to communicate with any GPU device. We only use
> > it as simple completion mechanism as it was convenient to use.
> > I do understand I can exchange that mechanism with a simpler one, and
> > I will add an internal task to do it (albeit not in a very high
> > priority) and upstream it, its just that it is part of our data path
> > so we need to thoroughly validate it first.
>
> Sounds good.
>
> Wrt merging this patch here, can you include that in one of your next
> pulls? Or should I toss it entirely, waiting for you to remove dma_fence
> outright?

I'll include it in the next pull.
Thanks,
Oded
>
> Thanks, Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 3/3] misc/habalabs: don't set default fence_ops->wait

[Daniel Vetter]

On Thu, May 14, 2020 at 02:38:38PM +0300, Oded Gabbay wrote:
> On Tue, May 12, 2020 at 9:12 AM Daniel Vetter  wrote:
> >
> > On Tue, May 12, 2020 at 4:14 AM Dave Airlie  wrote:
> > >
> > > On Mon, 11 May 2020 at 19:37, Oded Gabbay  wrote:
> > > >
> > > > On Mon, May 11, 2020 at 12:11 PM Daniel Vetter  
> > > > wrote:
> > > > >
> > > > > It's the default.
> > > > Thanks for catching that.
> > > >
> > > > >
> > > > > Also so much for "we're not going to tell the graphics people how to
> > > > > review their code", dma_fence is a pretty core piece of gpu driver
> > > > > infrastructure. And it's very much uapi relevant, including piles of
> > > > > corresponding userspace protocols and libraries for how to pass these
> > > > > around.
> > > > >
> > > > > Would be great if habanalabs would not use this (from a quick look
> > > > > it's not needed at all), since open source the userspace and playing
> > > > > by the usual rules isn't on the table. If that's not possible (because
> > > > > it's actually using the uapi part of dma_fence to interact with gpu
> > > > > drivers) then we have exactly what everyone promised we'd want to
> > > > > avoid.
> > > >
> > > > We don't use the uapi parts, we currently only using the fencing and
> > > > signaling ability of this module inside our kernel code. But maybe I
> > > > didn't understand what you request. You want us *not* to use this
> > > > well-written piece of kernel code because it is only used by graphics
> > > > drivers ?
> > > > I'm sorry but I don't get this argument, if this is indeed what you 
> > > > meant.
> > >
> > > We would rather drivers using a feature that has requirements on
> > > correct userspace implementations of the feature have a userspace that
> > > is open source and auditable.
> > >
> > > Fencing is tricky, cross-device fencing is really tricky, and having
> > > the ability for a closed userspace component to mess up other people's
> > > drivers, think i915 shared with closed habana userspace and shared
> > > fences, decreases ability to debug things.
> > >
> > > Ideally we wouldn't offer users known untested/broken scenarios, so
> > > yes we'd prefer that drivers that intend to expose a userspace fencing
> > > api around dma-fence would adhere to the rules of the gpu drivers.
> > >
> > > I'm not say you have to drop using dma-fence, but if you move towards
> > > cross-device stuff I believe other drivers would be correct in
> > > refusing to interact with fences from here.
> >
> > The flip side is if you only used dma-fence.c "because it's there",
> > and not because it comes with an uapi attached and a cross-driver
> > kernel internal contract for how to interact with gpu drivers, then
> > there's really not much point in using it. It's a custom-rolled
> > wait_queue/event thing, that's all. Without the gpu uapi and gpu
> > cross-driver contract it would be much cleaner to just use wait_queue
> > directly, and that's a construct all kernel developers understand, not
> > just gpu folks. From a quick look at least habanalabs doesn't use any
> > of these uapi/cross-driver/gpu bits.
> > -Daniel
> 
> Hi Daniel,
> I want to say explicitly that we don't use the dma-buf uapi parts, nor
> we intend to use them to communicate with any GPU device. We only use
> it as simple completion mechanism as it was convenient to use.
> I do understand I can exchange that mechanism with a simpler one, and
> I will add an internal task to do it (albeit not in a very high
> priority) and upstream it, its just that it is part of our data path
> so we need to thoroughly validate it first.

Sounds good.

Wrt merging this patch here, can you include that in one of your next
pulls? Or should I toss it entirely, waiting for you to remove dma_fence
outright?

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drm/writeback: don't set fence->ops to default

[Daniel Vetter]

On Mon, May 11, 2020 at 06:12:32PM +, Ruhl, Michael J wrote:
> >-Original Message-
> >From: dri-devel  On Behalf Of
> >Daniel Vetter
> >Sent: Monday, May 11, 2020 5:12 AM
> >To: LKML 
> >Cc: David Airlie ; Daniel Vetter ;
> >Intel Graphics Development ; DRI
> >Development ; Thomas Zimmermann
> >; Vetter, Daniel 
> >Subject: [PATCH 1/3] drm/writeback: don't set fence->ops to default
> >
> >It's the default.
> 
> I can get behind that. 
> 
> Reviewed-by: Michael J. Ruhl 

Applied to drm-misc-next, thanks for reviewing.
-Daniel

> 
> >Signed-off-by: Daniel Vetter 
> >Cc: Maarten Lankhorst 
> >Cc: Maxime Ripard 
> >Cc: Thomas Zimmermann 
> >Cc: David Airlie 
> >Cc: Daniel Vetter 
> >---
> > drivers/gpu/drm/drm_writeback.c | 1 -
> > 1 file changed, 1 deletion(-)
> >
> >diff --git a/drivers/gpu/drm/drm_writeback.c
> >b/drivers/gpu/drm/drm_writeback.c
> >index 43d9e3bb3a94..dccf4504f1bb 100644
> >--- a/drivers/gpu/drm/drm_writeback.c
> >+++ b/drivers/gpu/drm/drm_writeback.c
> >@@ -108,7 +108,6 @@ static const struct dma_fence_ops
> >drm_writeback_fence_ops = {
> > .get_driver_name = drm_writeback_fence_get_driver_name,
> > .get_timeline_name = drm_writeback_fence_get_timeline_name,
> > .enable_signaling = drm_writeback_fence_enable_signaling,
> >-.wait = dma_fence_default_wait,
> > };
> >
> > static int create_writeback_properties(struct drm_device *dev)
> >--
> >2.26.2
> >
> >___
> >dri-devel mailing list
> >dri-devel@lists.freedesktop.org
> >https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/shmem-helpers: Simplify dma-buf importing

[Daniel Vetter]

- Ditch the ->pages array
- Make it a private gem bo, which means no shmem object, which means
  fireworks if anyone calls drm_gem_object_get_pages. But we've just
  made sure that's all covered.

v2: Rebase

Acked-by: Thomas Zimmermann 
Cc: Gerd Hoffmann 
Cc: Rob Herring 
Cc: Noralf Trønnes 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_gem_shmem_helper.c | 59 ++
 1 file changed, 23 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c 
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index 06cee8e97d27..f6854af206d2 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -35,22 +35,12 @@ static const struct drm_gem_object_funcs 
drm_gem_shmem_funcs = {
.mmap = drm_gem_shmem_mmap,
 };
 
-/**
- * drm_gem_shmem_create - Allocate an object with the given size
- * @dev: DRM device
- * @size: Size of the object to allocate
- *
- * This function creates a shmem GEM object.
- *
- * Returns:
- * A struct drm_gem_shmem_object * on success or an ERR_PTR()-encoded negative
- * error code on failure.
- */
-struct drm_gem_shmem_object *drm_gem_shmem_create(struct drm_device *dev, 
size_t size)
+static struct drm_gem_shmem_object *
+__drm_gem_shmem_create(struct drm_device *dev, size_t size, bool private)
 {
struct drm_gem_shmem_object *shmem;
struct drm_gem_object *obj;
-   int ret;
+   int ret = 0;
 
size = PAGE_ALIGN(size);
 
@@ -64,7 +54,10 @@ struct drm_gem_shmem_object *drm_gem_shmem_create(struct 
drm_device *dev, size_t
if (!obj->funcs)
obj->funcs = _gem_shmem_funcs;
 
-   ret = drm_gem_object_init(dev, obj, size);
+   if (private)
+   drm_gem_private_object_init(dev, obj, size);
+   else
+   ret = drm_gem_object_init(dev, obj, size);
if (ret)
goto err_free;
 
@@ -96,6 +89,21 @@ struct drm_gem_shmem_object *drm_gem_shmem_create(struct 
drm_device *dev, size_t
 
return ERR_PTR(ret);
 }
+/**
+ * drm_gem_shmem_create - Allocate an object with the given size
+ * @dev: DRM device
+ * @size: Size of the object to allocate
+ *
+ * This function creates a shmem GEM object.
+ *
+ * Returns:
+ * A struct drm_gem_shmem_object * on success or an ERR_PTR()-encoded negative
+ * error code on failure.
+ */
+struct drm_gem_shmem_object *drm_gem_shmem_create(struct drm_device *dev, 
size_t size)
+{
+   return __drm_gem_shmem_create(dev, size, false);
+}
 EXPORT_SYMBOL_GPL(drm_gem_shmem_create);
 
 /**
@@ -115,7 +123,6 @@ void drm_gem_shmem_free_object(struct drm_gem_object *obj)
if (obj->import_attach) {
shmem->pages_use_count--;
drm_prime_gem_destroy(obj, shmem->sgt);
-   kvfree(shmem->pages);
} else {
if (shmem->sgt) {
dma_unmap_sg(obj->dev->dev, shmem->sgt->sgl,
@@ -371,7 +378,7 @@ drm_gem_shmem_create_with_handle(struct drm_file *file_priv,
struct drm_gem_shmem_object *shmem;
int ret;
 
-   shmem = drm_gem_shmem_create(dev, size);
+   shmem = __drm_gem_shmem_create(dev, size, true);
if (IS_ERR(shmem))
return shmem;
 
@@ -695,36 +702,16 @@ drm_gem_shmem_prime_import_sg_table(struct drm_device 
*dev,
struct sg_table *sgt)
 {
size_t size = PAGE_ALIGN(attach->dmabuf->size);
-   size_t npages = size >> PAGE_SHIFT;
struct drm_gem_shmem_object *shmem;
-   int ret;
 
shmem = drm_gem_shmem_create(dev, size);
if (IS_ERR(shmem))
return ERR_CAST(shmem);
 
-   shmem->pages = kvmalloc_array(npages, sizeof(struct page *), 
GFP_KERNEL);
-   if (!shmem->pages) {
-   ret = -ENOMEM;
-   goto err_free_gem;
-   }
-
-   ret = drm_prime_sg_to_page_addr_arrays(sgt, shmem->pages, NULL, npages);
-   if (ret < 0)
-   goto err_free_array;
-
shmem->sgt = sgt;
-   shmem->pages_use_count = 1; /* Permanently pinned from our point of 
view */
 
DRM_DEBUG_PRIME("size = %zu\n", size);
 
return >base;
-
-err_free_array:
-   kvfree(shmem->pages);
-err_free_gem:
-   drm_gem_object_put(>base);
-
-   return ERR_PTR(ret);
 }
 EXPORT_SYMBOL_GPL(drm_gem_shmem_prime_import_sg_table);
-- 
2.26.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm/mm: improve rb_hole_addr rbtree search

[Nirmoy]

On 5/20/20 6:35 PM, Chris Wilson wrote:

Quoting Nirmoy (2020-05-20 17:28:04)

Hi Chris,

On 5/20/20 12:56 AM, Chris Wilson wrote:

Quoting Nirmoy Das (2020-05-19 09:44:36)

+#define DRM_MM_ALIGN_SHIFT 6
   #define HOLE_SIZE(NODE) ((NODE)->hole_size)
   #define HOLE_ADDR(NODE) (__drm_mm_hole_node_start(NODE))
+#define HOLE_SIZE_ALIGN(NODE) ((NODE->hole_size << DRM_MM_ALIGN_SHIFT) | \
+  ffs(HOLE_ADDR(NODE)))

Fwiw, max hole size of 58b, we would need to stop storing byte
extents...


Can you please explain 2nd part of this statement.

Currently we [i915] use drm_mm with byte-addressing, so 58b is a tad too
close to the amount we actually need to track. If we used page tracking
instead of bytes, we regain 12b to play around with. It makes no
difference to the code at the moment (e.g. we still could not fit within
u32) so there has been no pressure to rewrite the extents handling. But
given sufficient reason, we could.
-Chris



Thanks for the detailed explanation.


Nirmoy

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm/amd/display: Enable fp16 also on DCE-11.0 - DCE-12.

[Harry Wentland]

On 2020-05-15 1:19 a.m., Mario Kleiner wrote:
> Testing on a Polaris11 gpu with DCE-11.2 suggests that it
> seems to work fine there, so optimistically enable it for
> DCE-11 and later.
> 
> Signed-off-by: Mario Kleiner 
> ---
>  drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c | 2 +-
>  drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c | 2 +-
>  drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c 
> b/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
> index 9597fc79d7fa..a043ddae5149 100644
> --- a/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
> +++ b/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
> @@ -410,7 +410,7 @@ static const struct dc_plane_cap plane_cap = {
>   .pixel_format_support = {
>   .argb = true,
>   .nv12 = false,
> - .fp16 = false
> + .fp16 = true

Carrizo (DCE 11.0) has a HW bug where FP16 scaling doesn't work. I
recommend we leave it off here.

Harry

>   },
>  
>   .max_upscale_factor = {
> diff --git a/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c 
> b/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c
> index 4a7796de2ff5..51b3fe502670 100644
> --- a/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c
> +++ b/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c
> @@ -411,7 +411,7 @@ static const struct dc_plane_cap plane_cap = {
>   .pixel_format_support = {
>   .argb = true,
>   .nv12 = false,
> - .fp16 = false
> + .fp16 = true
>   },
>  
>   .max_upscale_factor = {
> diff --git a/drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c 
> b/drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c
> index 9a9764cbd78d..8f362e8c1787 100644
> --- a/drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c
> +++ b/drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c
> @@ -516,7 +516,7 @@ static const struct dc_plane_cap plane_cap = {
>   .pixel_format_support = {
>   .argb = true,
>   .nv12 = false,
> - .fp16 = false
> + .fp16 = true
>   },
>  
>   .max_upscale_factor = {
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: Restore the NULL check for drm_gem_object_put()

[Chris Wilson]

Quoting Emil Velikov (2020-05-20 15:25:05)
> Reviewed-by: Emil Velikov 
> 
> I'm half way through checking the callers and I've noticed a handful of bugs.
> Will send the series in due time, although your patch is a perfect
> intermediate solution.

Pushed the compromise patch. That should keep us all happy within our
own little bubbles for the moment. Have fun!
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm/mm: improve rb_hole_addr rbtree search

[Chris Wilson]

Quoting Nirmoy (2020-05-20 17:28:04)
> Hi Chris,
> 
> On 5/20/20 12:56 AM, Chris Wilson wrote:
> > Quoting Nirmoy Das (2020-05-19 09:44:36)
> >> +#define DRM_MM_ALIGN_SHIFT 6
> >>   #define HOLE_SIZE(NODE) ((NODE)->hole_size)
> >>   #define HOLE_ADDR(NODE) (__drm_mm_hole_node_start(NODE))
> >> +#define HOLE_SIZE_ALIGN(NODE) ((NODE->hole_size << DRM_MM_ALIGN_SHIFT) | \
> >> +  ffs(HOLE_ADDR(NODE)))
> > Fwiw, max hole size of 58b, we would need to stop storing byte
> > extents...
> 
> 
> Can you please explain 2nd part of this statement.

Currently we [i915] use drm_mm with byte-addressing, so 58b is a tad too
close to the amount we actually need to track. If we used page tracking
instead of bytes, we regain 12b to play around with. It makes no
difference to the code at the moment (e.g. we still could not fit within
u32) so there has been no pressure to rewrite the extents handling. But
given sufficient reason, we could.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm/mm: improve rb_hole_addr rbtree search

[Nirmoy]

Hi Chris,

On 5/20/20 12:56 AM, Chris Wilson wrote:

Quoting Nirmoy Das (2020-05-19 09:44:36)

+#define DRM_MM_ALIGN_SHIFT 6
  #define HOLE_SIZE(NODE) ((NODE)->hole_size)
  #define HOLE_ADDR(NODE) (__drm_mm_hole_node_start(NODE))
+#define HOLE_SIZE_ALIGN(NODE) ((NODE->hole_size << DRM_MM_ALIGN_SHIFT) | \
+  ffs(HOLE_ADDR(NODE)))

Fwiw, max hole size of 58b, we would need to stop storing byte
extents...



Can you please explain 2nd part of this statement.



  static struct drm_mm_node *
-next_hole_low_addr(struct drm_mm_node *entry, u64 size)
+next_hole_low_addr(struct drm_mm_node *entry, u64 size, u64 alignment)
  {
 struct rb_node *rb_node, *right_rb_node, *parent_rb_node;
 struct drm_mm_node *right_node;
+   u64 req_align = (size + alignment) << DRM_MM_ALIGN_SHIFT;
  
 if (!entry)

 return NULL;
@@ -513,6 +561,7 @@ next_hole_low_addr(struct drm_mm_node *entry, u64 size)
 right_node = rb_entry(right_rb_node,
   struct drm_mm_node, rb_hole_addr);
 if ((right_node->subtree_max_hole < size ||
+right_node->subtree_max_hole_align < req_align ||

What was the point in storing the packed alignment if we are just
searching for a hole big enough for (size + alignment)?


Yes, I realized this is not correct :/

Still thinking about a better solution to capture alignment into subtree 
elimination.



Regards,

Nirmoy


-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-develdata=02%7C01%7Cnirmoy.das%40amd.com%7C1b1ab9c2ca03412daa2108d7fc47d26e%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637255257724473951sdata=gDRvdhwLV1M%2BKLCgpENik52gAB3O0ik1n%2B%2FaZxLgr%2Fk%3Dreserved=0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC] Deprecate AGP GART support for Radeon/Nouveau/TTM

[Michel Dänzer]

On 2020-05-20 4:43 p.m., Christian König wrote:
> Am 13.05.20 um 13:03 schrieb Christian König:
>> Unfortunately AGP is still to widely used as we could just drop
>> support for using its GART.
>>
>> Not using the AGP GART also doesn't mean a loss in functionality since
>> drivers will just fallback to the driver specific PCI GART.
>>
>> For now just deprecate the code and don't enable the AGP GART in TTM
>> even when general AGP support is available.
> 
> So I've used an ancient system (32bit) to setup a test box for this.
> 
> 
> The first GPU I could test is an RV280 (Radeon 9200 PRO) which is easily
> 15 years old.
> 
> What happens in AGP mode is that glxgears shows artifacts during
> rendering on this system.
> 
> In PCI mode those rendering artifacts are gone and glxgears seems to
> draw everything correctly now.
> 
> Performance is obviously not comparable, cause in AGP we don't render
> all triangles correctly.
> 
> 
> The second GPU I could test is an RV630 PRO (Radeon HD 2600 PRO AGP)
> which is more than 10 years old.
> 
> As far as I can tell this one works in both AGP and PCIe mode perfectly
> fine.
> 
> Since this is only a 32bit system I couldn't really test any OpenGL game
> that well.
> 
> But for glxgears switching from AGP to PCIe mode seems to result in a
> roughly 5% performance drop.
> 
> The surprising reason for this is not the better TLB performance, but
> the lack of USWC support for the PCIe GART in radeon.

I suspect the main reason it's only 5% is that PCIe GART page tables are
stored in VRAM, so they don't need to be fetched across the PCIe link
(and presumably it has more than one TLB entry as well). The difference
is much bigger with native AGP ASICs with PCI GART.


-- 
Earthling Michel Dänzer   |   https://redhat.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC] Deprecate AGP GART support for Radeon/Nouveau/TTM

[Alex Deucher]

On Wed, May 20, 2020 at 10:43 AM Christian König
 wrote:
>
> Am 13.05.20 um 13:03 schrieb Christian König:
> > Unfortunately AGP is still to widely used as we could just drop support for 
> > using its GART.
> >
> > Not using the AGP GART also doesn't mean a loss in functionality since 
> > drivers will just fallback to the driver specific PCI GART.
> >
> > For now just deprecate the code and don't enable the AGP GART in TTM even 
> > when general AGP support is available.
>
> So I've used an ancient system (32bit) to setup a test box for this.
>
>
> The first GPU I could test is an RV280 (Radeon 9200 PRO) which is easily
> 15 years old.
>
> What happens in AGP mode is that glxgears shows artifacts during
> rendering on this system.
>
> In PCI mode those rendering artifacts are gone and glxgears seems to
> draw everything correctly now.
>
> Performance is obviously not comparable, cause in AGP we don't render
> all triangles correctly.
>
>
> The second GPU I could test is an RV630 PRO (Radeon HD 2600 PRO AGP)
> which is more than 10 years old.
>
> As far as I can tell this one works in both AGP and PCIe mode perfectly
> fine.
>
> Since this is only a 32bit system I couldn't really test any OpenGL game
> that well.
>
> But for glxgears switching from AGP to PCIe mode seems to result in a
> roughly 5% performance drop.
>
> The surprising reason for this is not the better TLB performance, but
> the lack of USWC support for the PCIe GART in radeon.
>
>
> So if anybody wants to get his hands dirty and squeeze a bit more
> performance out of the old hardware, porting USWC from amdgpu to radeon
> shouldn't be to much of a problem.

We do support USWC on radeon, although I think we had separate flags
for cached and WC.  That said we had a lot of problems with WC on 32
bit (see radeon_bo_create()).  The other problem is that, at least on
the really old radeons, the PCI gart didn't support snooped and
unsnooped.  It was always snooped.  It wasn't until pcie that the gart
hw got support for both.  For AGP, the expectation was that AGP
provided the uncached memory.

>
>
> Summing it up I'm still leaning towards disabling AGP completely by
> default for radeon and deprecate it in TTM as well.
>
> Thoughts? Especially Alex what do you think.

Works for me.

Alex
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH 0/8] Qualcomm Cloud AI 100 driver

[Greg Kroah-Hartman]

On Wed, May 20, 2020 at 08:48:13AM -0600, Jeffrey Hugo wrote:
> On 5/20/2020 2:34 AM, Daniel Vetter wrote:
> > On Wed, May 20, 2020 at 7:15 AM Greg Kroah-Hartman
> >  wrote:
> > > 
> > > On Tue, May 19, 2020 at 10:41:15PM +0200, Daniel Vetter wrote:
> > > > On Tue, May 19, 2020 at 07:41:20PM +0200, Greg Kroah-Hartman wrote:
> > > > > On Tue, May 19, 2020 at 08:57:38AM -0600, Jeffrey Hugo wrote:
> > > > > > On 5/18/2020 11:08 PM, Dave Airlie wrote:
> > > > > > > On Fri, 15 May 2020 at 00:12, Jeffrey Hugo  
> > > > > > > wrote:
> > > > > > > > 
> > > > > > > > Introduction:
> > > > > > > > Qualcomm Cloud AI 100 is a PCIe adapter card which contains a 
> > > > > > > > dedicated
> > > > > > > > SoC ASIC for the purpose of efficently running Deep Learning 
> > > > > > > > inference
> > > > > > > > workloads in a data center environment.
> > > > > > > > 
> > > > > > > > The offical press release can be found at -
> > > > > > > > https://www.qualcomm.com/news/releases/2019/04/09/qualcomm-brings-power-efficient-artificial-intelligence-inference
> > > > > > > > 
> > > > > > > > The offical product website is -
> > > > > > > > https://www.qualcomm.com/products/datacenter-artificial-intelligence
> > > > > > > > 
> > > > > > > > At the time of the offical press release, numerious technology 
> > > > > > > > news sites
> > > > > > > > also covered the product.  Doing a search of your favorite site 
> > > > > > > > is likely
> > > > > > > > to find their coverage of it.
> > > > > > > > 
> > > > > > > > It is our goal to have the kernel driver for the product fully 
> > > > > > > > upstream.
> > > > > > > > The purpose of this RFC is to start that process.  We are still 
> > > > > > > > doing
> > > > > > > > development (see below), and thus not quite looking to gain 
> > > > > > > > acceptance quite
> > > > > > > > yet, but now that we have a working driver we beleive we are at 
> > > > > > > > the stage
> > > > > > > > where meaningful conversation with the community can occur.
> > > > > > > 
> > > > > > > 
> > > > > > > Hi Jeffery,
> > > > > > > 
> > > > > > > Just wondering what the userspace/testing plans for this driver.
> > > > > > > 
> > > > > > > This introduces a new user facing API for a device without 
> > > > > > > pointers to
> > > > > > > users or tests for that API.
> > > > > > 
> > > > > > We have daily internal testing, although I don't expect you to take 
> > > > > > my word
> > > > > > for that.
> > > > > > 
> > > > > > I would like to get one of these devices into the hands of Linaro, 
> > > > > > so that
> > > > > > it can be put into KernelCI.  Similar to other Qualcomm products. 
> > > > > > I'm trying
> > > > > > to convince the powers that be to make this happen.
> > > > > > 
> > > > > > Regarding what the community could do on its own, everything but 
> > > > > > the Linux
> > > > > > driver is considered proprietary - that includes the on device 
> > > > > > firmware and
> > > > > > the entire userspace stack.  This is a decision above my pay grade.
> > > > > 
> > > > > Ok, that's a decision you are going to have to push upward on, as we
> > > > > really can't take this without a working, open, userspace.
> > > > 
> > > > Uh wut.
> > > > 
> > > > So the merge criteria for drivers/accel (atm still drivers/misc but I
> > > > thought that was interim until more drivers showed up) isn't actually
> > > > "totally-not-a-gpu accel driver without open source userspace".
> > > > 
> > > > Instead it's "totally-not-a-gpu accel driver without open source
> > > > userspace" _and_ you have to be best buddies with Greg. Or at least
> > > > not be on the naughty company list. Since for habanalabs all you
> > > > wanted is a few test cases to exercise the ioctls. Not the entire
> > > > userspace.
> > > 
> > > Also, to be fair, I have changed my mind after seeing the mess of
> > > complexity that these "ioctls for everyone!" type of pass-through
> > > these kinds of drivers are creating.  You were right, we need open
> > > userspace code in order to be able to properly evaluate and figure out
> > > what they are doing is right or not and be able to maintain things over
> > > time correctly.
> > > 
> > > So I was wrong, and you were right, my apologies for my previous
> > > stubbornness.
> > 
> > Awesome and don't worry, I'm pretty sure we've all been stubborn
> > occasionally :-)
> > 
> >  From a drivers/gpu pov I think still not quite there since we also
> > want to see the compiler for these programmable accelerator thingies.
> > But just having a fairly good consensus that "userspace library with
> > all the runtime stuff excluding compiler must be open" is a huge step
> > forward. Next step may be that we (kernel overall, drivers/gpu will
> > still ask for the full thing) have ISA docs for these programmable
> > things, so that we can also evaluate that aspect and gauge how many
> > security issues there might be. Plus have a fighting chance to fix up
> > the security leaks when (post smeltdown I don't 

Re: [RFC PATCH 0/8] Qualcomm Cloud AI 100 driver

[Daniel Vetter]

On Wed, May 20, 2020 at 08:48:13AM -0600, Jeffrey Hugo wrote:
> On 5/20/2020 2:34 AM, Daniel Vetter wrote:
> > On Wed, May 20, 2020 at 7:15 AM Greg Kroah-Hartman
> >  wrote:
> > > 
> > > On Tue, May 19, 2020 at 10:41:15PM +0200, Daniel Vetter wrote:
> > > > On Tue, May 19, 2020 at 07:41:20PM +0200, Greg Kroah-Hartman wrote:
> > > > > On Tue, May 19, 2020 at 08:57:38AM -0600, Jeffrey Hugo wrote:
> > > > > > On 5/18/2020 11:08 PM, Dave Airlie wrote:
> > > > > > > On Fri, 15 May 2020 at 00:12, Jeffrey Hugo  
> > > > > > > wrote:
> > > > > > > > 
> > > > > > > > Introduction:
> > > > > > > > Qualcomm Cloud AI 100 is a PCIe adapter card which contains a 
> > > > > > > > dedicated
> > > > > > > > SoC ASIC for the purpose of efficently running Deep Learning 
> > > > > > > > inference
> > > > > > > > workloads in a data center environment.
> > > > > > > > 
> > > > > > > > The offical press release can be found at -
> > > > > > > > https://www.qualcomm.com/news/releases/2019/04/09/qualcomm-brings-power-efficient-artificial-intelligence-inference
> > > > > > > > 
> > > > > > > > The offical product website is -
> > > > > > > > https://www.qualcomm.com/products/datacenter-artificial-intelligence
> > > > > > > > 
> > > > > > > > At the time of the offical press release, numerious technology 
> > > > > > > > news sites
> > > > > > > > also covered the product.  Doing a search of your favorite site 
> > > > > > > > is likely
> > > > > > > > to find their coverage of it.
> > > > > > > > 
> > > > > > > > It is our goal to have the kernel driver for the product fully 
> > > > > > > > upstream.
> > > > > > > > The purpose of this RFC is to start that process.  We are still 
> > > > > > > > doing
> > > > > > > > development (see below), and thus not quite looking to gain 
> > > > > > > > acceptance quite
> > > > > > > > yet, but now that we have a working driver we beleive we are at 
> > > > > > > > the stage
> > > > > > > > where meaningful conversation with the community can occur.
> > > > > > > 
> > > > > > > 
> > > > > > > Hi Jeffery,
> > > > > > > 
> > > > > > > Just wondering what the userspace/testing plans for this driver.
> > > > > > > 
> > > > > > > This introduces a new user facing API for a device without 
> > > > > > > pointers to
> > > > > > > users or tests for that API.
> > > > > > 
> > > > > > We have daily internal testing, although I don't expect you to take 
> > > > > > my word
> > > > > > for that.
> > > > > > 
> > > > > > I would like to get one of these devices into the hands of Linaro, 
> > > > > > so that
> > > > > > it can be put into KernelCI.  Similar to other Qualcomm products. 
> > > > > > I'm trying
> > > > > > to convince the powers that be to make this happen.
> > > > > > 
> > > > > > Regarding what the community could do on its own, everything but 
> > > > > > the Linux
> > > > > > driver is considered proprietary - that includes the on device 
> > > > > > firmware and
> > > > > > the entire userspace stack.  This is a decision above my pay grade.
> > > > > 
> > > > > Ok, that's a decision you are going to have to push upward on, as we
> > > > > really can't take this without a working, open, userspace.
> > > > 
> > > > Uh wut.
> > > > 
> > > > So the merge criteria for drivers/accel (atm still drivers/misc but I
> > > > thought that was interim until more drivers showed up) isn't actually
> > > > "totally-not-a-gpu accel driver without open source userspace".
> > > > 
> > > > Instead it's "totally-not-a-gpu accel driver without open source
> > > > userspace" _and_ you have to be best buddies with Greg. Or at least
> > > > not be on the naughty company list. Since for habanalabs all you
> > > > wanted is a few test cases to exercise the ioctls. Not the entire
> > > > userspace.
> > > 
> > > Also, to be fair, I have changed my mind after seeing the mess of
> > > complexity that these "ioctls for everyone!" type of pass-through
> > > these kinds of drivers are creating.  You were right, we need open
> > > userspace code in order to be able to properly evaluate and figure out
> > > what they are doing is right or not and be able to maintain things over
> > > time correctly.
> > > 
> > > So I was wrong, and you were right, my apologies for my previous
> > > stubbornness.
> > 
> > Awesome and don't worry, I'm pretty sure we've all been stubborn
> > occasionally :-)
> > 
> >  From a drivers/gpu pov I think still not quite there since we also
> > want to see the compiler for these programmable accelerator thingies.
> > But just having a fairly good consensus that "userspace library with
> > all the runtime stuff excluding compiler must be open" is a huge step
> > forward. Next step may be that we (kernel overall, drivers/gpu will
> > still ask for the full thing) have ISA docs for these programmable
> > things, so that we can also evaluate that aspect and gauge how many
> > security issues there might be. Plus have a fighting chance to fix up
> > the security leaks when (post smeltdown I don't 

Re: [PATCH v3] drm/amdgpu: off by one in amdgpu_device_attr_create_groups() error handling

[Christian König]

Am 20.05.20 um 17:31 schrieb Ruhl, Michael J:

-Original Message-
From: Dan Carpenter 
Sent: Wednesday, May 20, 2020 11:26 AM
To: Alex Deucher ; Kevin Wang
; Ruhl, Michael J 
Cc: Christian König ; David Airlie
; Daniel Vetter ; Evan Quan
; Rui Huang ; Kenneth Feng
; Yintian Tao ; Hawking Zhang
; amd-...@lists.freedesktop.org; dri-
de...@lists.freedesktop.org; linux-ker...@vger.kernel.org; kernel-
janit...@vger.kernel.org
Subject: [PATCH v3] drm/amdgpu: off by one in
amdgpu_device_attr_create_groups() error handling

This loop in the error handling code should start a "i - 1" and end at
"i == 0".  Currently it starts a "i" and ends at "i == 1".  The result
is that it removes one attribute that wasn't created yet, and leaks the
zeroeth attribute.

Fixes: 4e01847c38f7 ("drm/amdgpu: optimize amdgpu device attribute code")
Signed-off-by: Dan Carpenter 
---
v2: style change
v3: Fix embarrassing typo in the subject



Acked-by: Michael J. Ruhl 


Reviewed-by: Christian König 



m

drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c   | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
index b75362bf0742..e809534fabd4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
@@ -1942,9 +1942,8 @@ static int amdgpu_device_attr_create_groups(struct
amdgpu_device *adev,
return 0;

failed:
-   for (; i > 0; i--) {
+   while (i--)
amdgpu_device_attr_remove(adev, [i]);
-   }

return ret;
}


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH v3] drm/amdgpu: off by one in amdgpu_device_attr_create_groups() error handling

[Ruhl, Michael J]

>-Original Message-
>From: Dan Carpenter 
>Sent: Wednesday, May 20, 2020 11:26 AM
>To: Alex Deucher ; Kevin Wang
>; Ruhl, Michael J 
>Cc: Christian König ; David Airlie
>; Daniel Vetter ; Evan Quan
>; Rui Huang ; Kenneth Feng
>; Yintian Tao ; Hawking Zhang
>; amd-...@lists.freedesktop.org; dri-
>de...@lists.freedesktop.org; linux-ker...@vger.kernel.org; kernel-
>janit...@vger.kernel.org
>Subject: [PATCH v3] drm/amdgpu: off by one in
>amdgpu_device_attr_create_groups() error handling
>
>This loop in the error handling code should start a "i - 1" and end at
>"i == 0".  Currently it starts a "i" and ends at "i == 1".  The result
>is that it removes one attribute that wasn't created yet, and leaks the
>zeroeth attribute.
>
>Fixes: 4e01847c38f7 ("drm/amdgpu: optimize amdgpu device attribute code")
>Signed-off-by: Dan Carpenter 
>---
>v2: style change
>v3: Fix embarrassing typo in the subject



Acked-by: Michael J. Ruhl 

m
> drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c   | 3 +--
> 1 files changed, 1 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
>b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
>index b75362bf0742..e809534fabd4 100644
>--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
>+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
>@@ -1942,9 +1942,8 @@ static int amdgpu_device_attr_create_groups(struct
>amdgpu_device *adev,
>   return 0;
>
> failed:
>-  for (; i > 0; i--) {
>+  while (i--)
>   amdgpu_device_attr_remove(adev, [i]);
>-  }
>
>   return ret;
> }
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3] drm/amdgpu: off by one in amdgpu_device_attr_create_groups() error handling

[Dan Carpenter]

This loop in the error handling code should start a "i - 1" and end at
"i == 0".  Currently it starts a "i" and ends at "i == 1".  The result
is that it removes one attribute that wasn't created yet, and leaks the
zeroeth attribute.

Fixes: 4e01847c38f7 ("drm/amdgpu: optimize amdgpu device attribute code")
Signed-off-by: Dan Carpenter 
---
v2: style change
v3: Fix embarrassing typo in the subject

 drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c   | 3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
index b75362bf0742..e809534fabd4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
@@ -1942,9 +1942,8 @@ static int amdgpu_device_attr_create_groups(struct 
amdgpu_device *adev,
return 0;
 
 failed:
-   for (; i > 0; i--) {
+   while (i--)
amdgpu_device_attr_remove(adev, [i]);
-   }
 
return ret;
 }
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH v2] drm/amdgpu: off by on in amdgpu_device_attr_create_groups() error handling

[Ruhl, Michael J]

"off by on"

or 

"off by one"

?

M

>-Original Message-
>From: dri-devel  On Behalf Of Dan
>Carpenter
>Sent: Wednesday, May 20, 2020 9:08 AM
>To: Alex Deucher ; Kevin Wang
>
>Cc: David Airlie ; kernel-janit...@vger.kernel.org; linux-
>ker...@vger.kernel.org; amd-...@lists.freedesktop.org; Hawking Zhang
>; Rui Huang ; dri-
>de...@lists.freedesktop.org; Evan Quan ; Kenneth
>Feng ; Christian König
>; Yintian Tao 
>Subject: [PATCH v2] drm/amdgpu: off by on in
>amdgpu_device_attr_create_groups() error handling
>
>This loop in the error handling code should start a "i - 1" and end at
>"i == 0".  Currently it starts a "i" and ends at "i == 1".  The result
>is that it removes one attribute that wasn't created yet, and leaks the
>zeroeth attribute.
>
>Fixes: 4e01847c38f7 ("drm/amdgpu: optimize amdgpu device attribute code")
>Signed-off-by: Dan Carpenter 
>---
>v2: style change
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c   | 3 +--
> 1 files changed, 1 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
>b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
>index b75362bf0742..e809534fabd4 100644
>--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
>+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
>@@ -1942,9 +1942,8 @@ static int amdgpu_device_attr_create_groups(struct
>amdgpu_device *adev,
>   return 0;
>
> failed:
>-  for (; i > 0; i--) {
>+  while (i--)
>   amdgpu_device_attr_remove(adev, [i]);
>-  }
>
>   return ret;
> }
>___
>dri-devel mailing list
>dri-devel@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm/amd/display: Enable fp16 also on DCE-11.0 - DCE-12.

[Kazlauskas, Nicholas]

On 2020-05-15 1:19 a.m., Mario Kleiner wrote:

Testing on a Polaris11 gpu with DCE-11.2 suggests that it
seems to work fine there, so optimistically enable it for
DCE-11 and later.

Signed-off-by: Mario Kleiner 


Series is:

Reviewed-by: Nicholas Kazlauskas 

Thanks!


---
  drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c | 2 +-
  drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c | 2 +-
  drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c | 2 +-
  3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c 
b/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
index 9597fc79d7fa..a043ddae5149 100644
--- a/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
@@ -410,7 +410,7 @@ static const struct dc_plane_cap plane_cap = {
.pixel_format_support = {
.argb = true,
.nv12 = false,
-   .fp16 = false
+   .fp16 = true
},
  
  		.max_upscale_factor = {

diff --git a/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c 
b/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c
index 4a7796de2ff5..51b3fe502670 100644
--- a/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dce112/dce112_resource.c
@@ -411,7 +411,7 @@ static const struct dc_plane_cap plane_cap = {
.pixel_format_support = {
.argb = true,
.nv12 = false,
-   .fp16 = false
+   .fp16 = true
},
  
  	.max_upscale_factor = {

diff --git a/drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c 
b/drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c
index 9a9764cbd78d..8f362e8c1787 100644
--- a/drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dce120/dce120_resource.c
@@ -516,7 +516,7 @@ static const struct dc_plane_cap plane_cap = {
.pixel_format_support = {
.argb = true,
.nv12 = false,
-   .fp16 = false
+   .fp16 = true
},
  
  	.max_upscale_factor = {




___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 16/16] backlight: use backlight_is_blank() in all backlight drivers

[Daniel Thompson]

On Wed, May 20, 2020 at 11:56:43AM +0100, Emil Velikov wrote:
> Hi Sam,
> 
> On Sun, 17 May 2020 at 20:02, Sam Ravnborg  wrote:
> 
> > --- a/drivers/video/backlight/88pm860x_bl.c
> > +++ b/drivers/video/backlight/88pm860x_bl.c
> > @@ -123,13 +123,7 @@ static int pm860x_backlight_update_status(struct 
> > backlight_device *bl)
> >  {
> > int brightness = bl->props.brightness;
> >
> > -   if (bl->props.power != FB_BLANK_UNBLANK)
> > -   brightness = 0;
> > -
> > -   if (bl->props.fb_blank != FB_BLANK_UNBLANK)
> > -   brightness = 0;
> > -
> > -   if (bl->props.state & BL_CORE_SUSPENDED)
> > +   if (backlight_is_blank(bl))
> > brightness = 0;
> Off the top of my head, the above two lines should really be in backlight 
> core.
> There's nothing driver specific to them, plus it minimises the chances
> of next-driver getting it wrong.
> 
> 
> > --- a/drivers/video/backlight/as3711_bl.c
> > +++ b/drivers/video/backlight/as3711_bl.c
> > @@ -107,13 +107,11 @@ static int as3711_bl_update_status(struct 
> > backlight_device *bl)
> > int brightness = bl->props.brightness;
> > int ret = 0;
> >
> > -   dev_dbg(>dev, "%s(): brightness %u, pwr %x, blank %x, state 
> > %x\n",
> > +   dev_dbg(>dev, "%s(): brightness %u, pwr %x, state %x\n",
> > __func__, bl->props.brightness, bl->props.power,
> > -   bl->props.fb_blank, bl->props.state);
> > +   bl->props.state);
> >
> Let's also move this to backlight core.

Or just nuke it ;-)


Daniel.

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/3] drm/etnaviv: Don't ignore errors on getting clocks

[Russell King - ARM Linux admin]

On Wed, May 20, 2020 at 04:04:39PM +0200, Lucas Stach wrote:
> Am Mittwoch, den 20.05.2020, 15:38 +0200 schrieb Lubomir Rintel:
> > Yes. This means that in fact "core" is the only required clock for all
> > implementations of vivante,gc and the common binding needs to be updated
> > to reflect that. I'll follow with a patch that does that, unless there
> > are strong objections.
> > 
> > If there are implementations that require different clock inputs, then they
> > need to use additional compatible string for the particular flavor and the
> > binding should have conditionals for them. Something like this:
> > 
> >   if:
> > properties:
> >   compatible:
> > contains:
> >   const: fsl,imx6sx-gpu
> >   then:
> > properties:
> >   clocks:
> > minItems: 4
> 
> The DT binding of a device should describe the hardware of the device,
> not the specific integration into a SoC. Now it's a bit hard to make
> any definite statements about the Vivante GC GPU module itself, as most
> of the information we have is from reverse engineering. It's pretty
> clear though that the GPU module has at least 2 clock inputs: axi and
> core, as there is a feature bit that tells us if it's okay to gate the
> axi clock independently from core. 
> 
> I'm not 100% sure about the older cores as found in Dove, but all the
> more recent cores allow to clock the shader partition independently of
> the core partition, so that's another clock input.
> 
> Now when it comes to a SoC integration, it's totally fine to have all
> those GPU module clock inputs fed from the same clock source and behind
> a shared gate maybe. But that doesn't change the clock inputs from the
> device perspective, it's still 3 independent clock inputs, which then
> just point to the same clock source in the DT.
> 
> imx6sx.dtsi is even a precedent of such a setup: all module clock
> inputs are fed by a common clock and share a single gate.

It's very good to stand on a pedistal, and try to dictate what you
want, but what you want is not always possible, and that is the case
here.  You have made your idea of how you see the hardware quite
plain.

Getting back to reality, again, what we know is that there is one
clock for the GC600 on Dove, since are register settings to control
that clock.

What we also know is that there is an AHB clock, but how that relates
to the rest of the system, we have no documentation.  It is that is
used for the AHB bus, which incidentally includes the GC600 for access
to its register set. I don't remember whether AHB peripherals require
the clock or not, that is something that would need to be checked.
If they do, then it seems that clock is missing from the binding.

Then there's a description of the AXI interface to the GC600 which
mentions no clock (see 10.7.2 below).  It has a clock, but what that
clock is, and how it relates to the rest of the system is not clearly
specified.

So, again, what you're basically asking for is for someone to guess
and throw some ficticious model into DT.

No, if it's not known, then we should not be guessing and throwing
random garbage into a SoC DT description - once it's in the DT
description, it has to be supported going forward, and if it's later
found to be incorrect, then we have a problem.

So, I don't see how Dove can meet your requirements, and I think you
have to compromise on this, and just accept that Dove only has one
known clock.

If you want to continue being pedantic about this, then in order to
support that pedanty, we need to add an AHB clock to all Vivante GC
descriptions as well since the AHB interface requires it - there it
is called HCLK in the AHB specs.  Here is the extract from the Dove
documentation for the AHB interface:

10.7.1  AHB Interface
The main features of the AHB interface are:
n256k addressable register space
n32-bit accesses only (no bursts)
n32-bit data bus
nError response for illegal accesses
nAsynchronous interface to the Graphics Core
nInterrupt support
The interface uses a separate clock that is slower
than the AXI Bus clock, thus allowing a more
relaxed logic design. Because the Core clock is
different from the interface clock, design within
the GPU Core ensures that incoming and outgoing
data are handled properly when they cross clock
boundaries.
The GPU block occupies 256 KB (64k 32-bit words) of
the system address space. An AHB ERROR response is
returned if an illegal access is detected. Only
32-bit reads and writes are permitted.

10.7.2  AXI Interface
The main features of the AXI interface are:

Re: [PATCH] drm/doc: device hot-unplug for userspace

[Andrey Grodzovsky]

On 5/20/20 8:46 AM, Daniel Vetter wrote:

On Wed, May 20, 2020 at 02:19:08PM +0300, Pekka Paalanen wrote:

On Tue, 19 May 2020 10:37:12 -0400
Andrey Grodzovsky  wrote:


Thanks for the summary, does put things in order and makes it easier to
comprehend all the TODOs, some questions bellow

On 5/19/20 6:06 AM, Pekka Paalanen wrote:

From: Pekka Paalanen 

Set up the expectations on how hot-unplugging a DRM device should look like to
userspace.

Written by Daniel Vetter's request and largely based on his comments in IRC and
from 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Farchives%2Fdri-devel%2F2020-May%2F265484.htmldata=02%7C01%7CAndrey.Grodzovsky%40amd.com%7Ca4da241ff1e54610d95508d7fcbbcc11%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637255755828209496sdata=YDFoP2g3z3IiB77sRvAmPB%2Fix%2FV0Mh78YcCSAAlhXdg%3Dreserved=0
 .

Signed-off-by: Pekka Paalanen 
Cc: Daniel Vetter 
Cc: Andrey Grodzovsky 
Cc: Dave Airlie 
Cc: Sean Paul 

---

Disclaimer: I am a userspace developer writing for other userspace developers.
I took some liberties in defining what should happen without knowing what is
actually possible or what existing drivers already implement.
---
   Documentation/gpu/drm-uapi.rst | 75 ++
   1 file changed, 75 insertions(+)

diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
index 56fec6ed1ad8..80db4abd2cbd 100644
--- a/Documentation/gpu/drm-uapi.rst
+++ b/Documentation/gpu/drm-uapi.rst
@@ -1,3 +1,5 @@
+.. Copyright 2020 DisplayLink (UK) Ltd.
+
   ===
   Userland interfaces
   ===
@@ -162,6 +164,79 @@ other hand, a driver requires shared state between clients 
which is
   visible to user-space and accessible beyond open-file boundaries, they
   cannot support render nodes.
   
+Device Hot-Unplug

+=
+
+.. note::
+   The following is the plan. Implementation is not there yet
+   (2020 May 13).
+
+Graphics devices (display and/or render) may be connected via USB (e.g.
+display adapters or docking stations) or Thunderbolt (e.g. eGPU). An end
+user is able to hot-unplug this kind of devices while they are being
+used, and expects that the very least the machine does not crash. Any
+damage from hot-unplugging a DRM device needs to be limited as much as
+possible and userspace must be given the chance to handle it if it wants
+to. Ideally, unplugging a DRM device still lets a desktop to continue
+running, but that is going to need explicit support throughout the whole
+graphics stack: from kernel and userspace drivers, through display
+servers, via window system protocols, and in applications and libraries.
+
+Other scenarios that should lead to the same are: unrecoverable GPU
+crash, PCI device disappearing off the bus, or forced unbind of a driver
+from the physical device.
+
+In other words, from userspace perspective everything needs to keep on
+working more or less, until userspace stops using the disappeared DRM
+device and closes it completely. Userspace will learn of the device
+disappearance from the device removed uevent or in some cases specific
+ioctls returning EIO.
+
+This goal raises at least the following requirements for the kernel and
+drivers:
+
+- The kernel must not hang, crash or oops, no matter what userspace was
+  in the middle of doing when the device disappeared.
+
+- All GPU jobs that can no longer run must have their fences
+  force-signalled to avoid inflicting hangs to userspace.
+
+- KMS connectors must change their status to disconnected.
+
+- Legacy modesets and pageflips fake success.
+
+- Atomic commits, both real and TEST_ONLY, fake success.


Why wouldn't we return -EIO for the atommic commit IOTCL/legasy pflip
and modeset ioctls here same way as you suggested returning -EIO for
render ioctl ?

Hi,

that is more of a question for Daniel Vetter than me. I believe he is
worried that userspace will get the error handling horribly wrong
anyway, because it needs to be handled in every single display server
project. Render ioctl errors OTOH need to be handled only in the
corresponding Mesa or other userspace driver, and for render there are
API (OpenGL/EGL, Vulkan) specs that say how it must be handled to fill
the API contract. Because of the API contract, those are more likely to
have reasonable error handling in place already.

Yup pretty much. Atm compositors expect an -EINVAL (especially for
TEST_ONLY), some cope with the semi-spurious -EBUSY we still throw around,
but I expect most will just die if the get an -ENOMEM or -EIO or really
anything.

I think one area where we've historically thrown some spurious errors is
also vblank ioctls, since they don't take full locks and sometimes the
kernel needs to sneak in a modeset for some reason (gpu recovery, dp link
recovery, ...).

Either way I don't think there's anything the compositor can do than just
ignore the error and carry on.



So currently drm_ioctl will just check 

Re: [RFC] Deprecate AGP GART support for Radeon/Nouveau/TTM

[Christian König]

Am 13.05.20 um 13:03 schrieb Christian König:

Unfortunately AGP is still to widely used as we could just drop support for 
using its GART.

Not using the AGP GART also doesn't mean a loss in functionality since drivers 
will just fallback to the driver specific PCI GART.

For now just deprecate the code and don't enable the AGP GART in TTM even when 
general AGP support is available.


So I've used an ancient system (32bit) to setup a test box for this.


The first GPU I could test is an RV280 (Radeon 9200 PRO) which is easily 
15 years old.


What happens in AGP mode is that glxgears shows artifacts during 
rendering on this system.


In PCI mode those rendering artifacts are gone and glxgears seems to 
draw everything correctly now.


Performance is obviously not comparable, cause in AGP we don't render 
all triangles correctly.



The second GPU I could test is an RV630 PRO (Radeon HD 2600 PRO AGP) 
which is more than 10 years old.


As far as I can tell this one works in both AGP and PCIe mode perfectly 
fine.


Since this is only a 32bit system I couldn't really test any OpenGL game 
that well.


But for glxgears switching from AGP to PCIe mode seems to result in a 
roughly 5% performance drop.


The surprising reason for this is not the better TLB performance, but 
the lack of USWC support for the PCIe GART in radeon.



So if anybody wants to get his hands dirty and squeeze a bit more 
performance out of the old hardware, porting USWC from amdgpu to radeon 
shouldn't be to much of a problem.



Summing it up I'm still leaning towards disabling AGP completely by 
default for radeon and deprecate it in TTM as well.


Thoughts? Especially Alex what do you think.

Regards,
Christian.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: Restore the NULL check for drm_gem_object_put()

[Emil Velikov]

On Wed, 20 May 2020 at 15:24, Chris Wilson  wrote:
>
> Some users want to pass NULL to drm_gem_object_put(), but those using
> __drm_gem_object_put() did not. Compromise, have both and let the
> compiler sort it out.
>
> drm_gem_fb_destroy() calls drm_gem_object_put() with NULL obj causing:
> [   11.584209] BUG: kernel NULL pointer dereference, address: 
> [   11.584213] #PF: supervisor write access in kernel mode
> [   11.584215] #PF: error_code(0x0002) - not-present page
> [   11.584216] PGD 0 P4D 0
> [   11.584220] Oops: 0002 [#1] SMP NOPTI
> [   11.584223] CPU: 7 PID: 1571 Comm: gnome-shell Tainted: GE 
> 5.7.0-rc1-1-default+ #27
> [   11.584225] Hardware name: Micro-Star International Co., Ltd. MS-7A31/X370 
> XPOWER GAMING TITANIUM (MS-7A31), BIOS 1.MR 12/03/2019
> [   11.584237] RIP: 0010:drm_gem_fb_destroy+0x28/0x70 [drm_kms_helper]
> 
> [   11.584256] Call Trace:
> [   11.584279]  drm_mode_rmfb+0x189/0x1c0 [drm]
> [   11.584299]  ? drm_mode_rmfb+0x1c0/0x1c0 [drm]
> [   11.584314]  drm_ioctl_kernel+0xaa/0xf0 [drm]
> [   11.584329]  drm_ioctl+0x1ff/0x3b0 [drm]
> [   11.584347]  ? drm_mode_rmfb+0x1c0/0x1c0 [drm]
> [   11.584421]  amdgpu_drm_ioctl+0x49/0x80 [amdgpu]
> [   11.584427]  ksys_ioctl+0x87/0xc0
> [   11.584430]  __x64_sys_ioctl+0x16/0x20
> [   11.584434]  do_syscall_64+0x5f/0x240
> [   11.584438]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
> [   11.584440] RIP: 0033:0x7f0ef80f7227
>
> Reported-by: Nirmoy Das 
> Fixes: b5d250744ccc ("drm/gem: fold drm_gem_object_put_unlocked and 
> __drm_gem_object_put()")
> Signed-off-by: Chris Wilson 
> Cc: Nirmoy Das 
> Cc: Emil Velikov 
> Cc: Christian König .
> Acked-by: Nirmoy Das 

Reviewed-by: Emil Velikov 

I'm half way through checking the callers and I've noticed a handful of bugs.
Will send the series in due time, although your patch is a perfect
intermediate solution.

Thank you
Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: Restore the NULL check for drm_gem_object_put()

[Chris Wilson]

Some users want to pass NULL to drm_gem_object_put(), but those using
__drm_gem_object_put() did not. Compromise, have both and let the
compiler sort it out.

drm_gem_fb_destroy() calls drm_gem_object_put() with NULL obj causing:
[   11.584209] BUG: kernel NULL pointer dereference, address: 
[   11.584213] #PF: supervisor write access in kernel mode
[   11.584215] #PF: error_code(0x0002) - not-present page
[   11.584216] PGD 0 P4D 0
[   11.584220] Oops: 0002 [#1] SMP NOPTI
[   11.584223] CPU: 7 PID: 1571 Comm: gnome-shell Tainted: GE 
5.7.0-rc1-1-default+ #27
[   11.584225] Hardware name: Micro-Star International Co., Ltd. MS-7A31/X370 
XPOWER GAMING TITANIUM (MS-7A31), BIOS 1.MR 12/03/2019
[   11.584237] RIP: 0010:drm_gem_fb_destroy+0x28/0x70 [drm_kms_helper]

[   11.584256] Call Trace:
[   11.584279]  drm_mode_rmfb+0x189/0x1c0 [drm]
[   11.584299]  ? drm_mode_rmfb+0x1c0/0x1c0 [drm]
[   11.584314]  drm_ioctl_kernel+0xaa/0xf0 [drm]
[   11.584329]  drm_ioctl+0x1ff/0x3b0 [drm]
[   11.584347]  ? drm_mode_rmfb+0x1c0/0x1c0 [drm]
[   11.584421]  amdgpu_drm_ioctl+0x49/0x80 [amdgpu]
[   11.584427]  ksys_ioctl+0x87/0xc0
[   11.584430]  __x64_sys_ioctl+0x16/0x20
[   11.584434]  do_syscall_64+0x5f/0x240
[   11.584438]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[   11.584440] RIP: 0033:0x7f0ef80f7227

Reported-by: Nirmoy Das 
Fixes: b5d250744ccc ("drm/gem: fold drm_gem_object_put_unlocked and 
__drm_gem_object_put()")
Signed-off-by: Chris Wilson 
Cc: Nirmoy Das 
Cc: Emil Velikov 
Cc: Christian König .
Acked-by: Nirmoy Das 
---
 drivers/gpu/drm/i915/gem/i915_gem_object.h |  2 +-
 include/drm/drm_gem.h  | 10 +-
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index aba7517c2837..2faa481cc18f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -105,7 +105,7 @@ __attribute__((nonnull))
 static inline void
 i915_gem_object_put(struct drm_i915_gem_object *obj)
 {
-   drm_gem_object_put(>base);
+   __drm_gem_object_put(>base);
 }
 
 #define assert_object_held(obj) dma_resv_assert_held((obj)->base.resv)
diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
index 52173abdf500..2410ff0a8e86 100644
--- a/include/drm/drm_gem.h
+++ b/include/drm/drm_gem.h
@@ -363,6 +363,13 @@ static inline void drm_gem_object_get(struct 
drm_gem_object *obj)
kref_get(>refcount);
 }
 
+__attribute__((nonnull))
+static inline void
+__drm_gem_object_put(struct drm_gem_object *obj)
+{
+   kref_put(>refcount, drm_gem_object_free);
+}
+
 /**
  * drm_gem_object_put - drop a GEM buffer object reference
  * @obj: GEM buffer object
@@ -372,7 +379,8 @@ static inline void drm_gem_object_get(struct drm_gem_object 
*obj)
 static inline void
 drm_gem_object_put(struct drm_gem_object *obj)
 {
-   kref_put(>refcount, drm_gem_object_free);
+   if (obj)
+   __drm_gem_object_put(obj);
 }
 
 void drm_gem_object_put_locked(struct drm_gem_object *obj);
-- 
2.20.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/doc: device hot-unplug for userspace

[Daniel Vetter]

On Wed, May 20, 2020 at 3:20 PM Simon Ser  wrote:
>
> On Wednesday, May 20, 2020 2:55 PM, Daniel Vetter  wrote:
>
> > Maybe we should add an explicit note that there's no guarantee about the
> > new chardev minor this new device will get, it could both inherit the
> > existing one (you can't open the old one anymore anyway) or get a new one?
> >
> > Or does userspace want a guarantee, i.e. as long as there's still a handle
> > open kernel guarantees to not recycle the chardev minor (which is what we
> > currently do). In that case better to add that to your list of guarantees
> > above.
>
> The are race conditions to consider too, e.g.
>
> - Compositor sends /dev/dri/card0 to a client
> - card0 goes away
> - Another device takes card0
> - Client receives /dev/dri/card0 and then starts using it, but it's the
>   wrong device

Oh reminds me, what should we do about open() - that one will fail,
the chardev is going away after all, not failing kinda doesn't make
sense. And more tricky, about creating new leases?

I think reasonable semantics here would be that both of these "create
a new open drm fd" operations can fail as soon as the device is
unplugged. Userspace needs to be able to deal with that.
-Daniel

>
> At first glance these seem like edge-cases that almost never happen.
> However I've seen these happen in practice with connectors, especially
> with docks.
>
> One solution would be to number minor numbers like PIDs: don't recycle
> card0 before we've reached the upper minor number limit.



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/3] drm/etnaviv: Don't ignore errors on getting clocks

[Lucas Stach]

Am Mittwoch, den 20.05.2020, 15:38 +0200 schrieb Lubomir Rintel:
> On Thu, May 14, 2020 at 09:53:08AM +0100, Russell King - ARM Linux admin 
> wrote:
> > On Thu, May 14, 2020 at 10:40:58AM +0200, Lucas Stach wrote:
> > > Am Donnerstag, den 14.05.2020, 09:27 +0100 schrieb Russell King - ARM 
> > > Linux admin:
> > > > On Thu, May 14, 2020 at 10:18:02AM +0200, Lucas Stach wrote:
> > > > > Am Mittwoch, den 13.05.2020, 23:41 -0300 schrieb Fabio Estevam:
> > > > > > On Wed, May 13, 2020 at 2:09 PM Fabio Estevam  
> > > > > > wrote:
> > > > > > 
> > > > > > > The binding doc 
> > > > > > > Documentation/devicetree/bindings/gpu/vivante,gc.yaml
> > > > > > > says that only the 'reg' clock could be optional, the others are
> > > > > > > required.
> > > > > > 
> > > > > > arch/arm/boot/dts/dove.dtsi only uses the 'core' clock.
> > > > > > arch/arm/boot/dts/stm32mp157.dtsi uses 'bus' and 'core'
> > > > > > 
> > > > > > Maybe the binding needs to be updated and it seems that using
> > > > > > devm_clk_get_optional() like you propose is safe.
> > > > > 
> > > > > The binding is correct as-is. We want to require those clocks to be
> > > > > present, but the dove DT was added before the binding was finalized, 
> > > > > so
> > > > > the driver still treats the clocks as optional to not break
> > > > > compatibility with old DTs. Maybe this warrants a comment in the
> > > > > code...
> > > > 
> > > > The binding doc in mainline says:
> > > > 
> > > >   clocks:
> > > > items:
> > > >   - description: AXI/master interface clock
> > > >   - description: GPU core clock
> > > >   - description: Shader clock (only required if GPU has feature 
> > > > PIPE_3D)
> > > >   - description: AHB/slave interface clock (only required if GPU 
> > > > can gate slave interface independently)
> > > > minItems: 1
> > > > maxItems: 4
> > > > 
> > > >   clock-names:
> > > > items:
> > > >   enum: [ bus, core, shader, reg ]
> > > > minItems: 1
> > > > maxItems: 4
> > > > 
> > > > which looks correct to me - and means that Dove is compliant with that.
> > > 
> > > The YAML binding actually did loose something in translation here,
> > > which I didn't notice. Previously all those clocks were listed under
> > > "Required properties", with the exceptions listed in parenthesis. So
> > > the Dove GPU, which is a combined 2D/3D core should have axi, core and
> > > shader clocks specified.
> > 
> > That may be your desire, but that is impossible without knowing that
> > (a) it has the clocks
> > (b) what those clocks are connected to
> > 
> > I guess we could "make something up" but as DT is supposed to describe
> > hardware, I don't see how we can satisfy that and your requirement.
> > 
> > The only thing that is known from the documentation is that there is
> > one clock for the GPU on Dove.
> 
> Yes. This means that in fact "core" is the only required clock for all
> implementations of vivante,gc and the common binding needs to be updated
> to reflect that. I'll follow with a patch that does that, unless there
> are strong objections.
> 
> If there are implementations that require different clock inputs, then they
> need to use additional compatible string for the particular flavor and the
> binding should have conditionals for them. Something like this:
> 
>   if:
> properties:
>   compatible:
> contains:
>   const: fsl,imx6sx-gpu
>   then:
> properties:
>   clocks:
> minItems: 4

The DT binding of a device should describe the hardware of the device,
not the specific integration into a SoC. Now it's a bit hard to make
any definite statements about the Vivante GC GPU module itself, as most
of the information we have is from reverse engineering. It's pretty
clear though that the GPU module has at least 2 clock inputs: axi and
core, as there is a feature bit that tells us if it's okay to gate the
axi clock independently from core. 

I'm not 100% sure about the older cores as found in Dove, but all the
more recent cores allow to clock the shader partition independently of
the core partition, so that's another clock input.

Now when it comes to a SoC integration, it's totally fine to have all
those GPU module clock inputs fed from the same clock source and behind
a shared gate maybe. But that doesn't change the clock inputs from the
device perspective, it's still 3 independent clock inputs, which then
just point to the same clock source in the DT.

imx6sx.dtsi is even a precedent of such a setup: all module clock
inputs are fed by a common clock and share a single gate.

Regards,
Lucas

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/panfrost: fix runtime pm imbalance on error

[Steven Price]

On 20/05/2020 12:05, Dinghao Liu wrote:

pm_runtime_get_sync() increments the runtime PM usage counter even
the call returns an error code. Thus a pairing decrement is needed
on the error handling path to keep the counter balanced.

Signed-off-by: Dinghao Liu 


Actually I think we have the opposite problem. To be honest we don't 
handle this situation very well. By the time panfrost_job_hw_submit() is 
called the job has already been added to the pfdev->jobs array, so it's 
considered submitted even if it never actually lands on the hardware. So 
in the case of this function bailing out early we will then (eventually) 
hit a timeout and trigger a GPU reset.


panfrost_job_timedout() iterates through the pfdev->jobs array and calls 
pm_runtime_put_noidle() for each job it finds. So there's no inbalance 
here that I can see.


Have you actually observed the situation where pm_runtime_get_sync() 
returns a failure?


HOWEVER, it appears that by bailing out early the call to 
panfrost_devfreq_record_busy() is never made, which as far as I can see 
means that there may be an extra call to panfrost_devfreq_record_idle() 
when the jobs have timed out. Which could underflow the counter.


But equally looking at panfrost_job_timedout(), we only call 
panfrost_devfreq_record_idle() *once* even though multiple jobs might be 
processed.


There's a completely untested patch below which in theory should fix that...

Steve

8<---
diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c 
b/drivers/gpu/drm/panfrost/panfrost_job.c

index 7914b1570841..f9519afca29d 100644
--- a/drivers/gpu/drm/panfrost/panfrost_job.c
+++ b/drivers/gpu/drm/panfrost/panfrost_job.c
@@ -145,6 +145,8 @@ static void panfrost_job_hw_submit(struct 
panfrost_job *job, int js)

u64 jc_head = job->jc;
int ret;

+   panfrost_devfreq_record_busy(pfdev);
+
ret = pm_runtime_get_sync(pfdev->dev);
if (ret < 0)
return;
@@ -155,7 +157,6 @@ static void panfrost_job_hw_submit(struct 
panfrost_job *job, int js)

}

cfg = panfrost_mmu_as_get(pfdev, >file_priv->mmu);
-   panfrost_devfreq_record_busy(pfdev);

job_write(pfdev, JS_HEAD_NEXT_LO(js), jc_head & 0x);
job_write(pfdev, JS_HEAD_NEXT_HI(js), jc_head >> 32);
@@ -410,12 +411,12 @@ static void panfrost_job_timedout(struct 
drm_sched_job *sched_job)

for (i = 0; i < NUM_JOB_SLOTS; i++) {
if (pfdev->jobs[i]) {
pm_runtime_put_noidle(pfdev->dev);
+   panfrost_devfreq_record_idle(pfdev);
pfdev->jobs[i] = NULL;
}
}
spin_unlock_irqrestore(>js->job_lock, flags);

-   panfrost_devfreq_record_idle(pfdev);
panfrost_device_reset(pfdev);

for (i = 0; i < NUM_JOB_SLOTS; i++)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/amd/amdkfd: Fix large framesize for kfd_smi_ev_read()

[Aurabindo Pillai]

The buffer allocated is of 1024 bytes. Allocate this from
heap instead of stack.

Also remove check for stack size since we're allocating from heap

Signed-off-by: Aurabindo Pillai 
Tested-by: Amber Lin 
---
 drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c | 26 +++--
 1 file changed, 19 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c
index f5fd18eacf0d..5aebe169f8c6 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c
@@ -77,9 +77,11 @@ static ssize_t kfd_smi_ev_read(struct file *filep, char 
__user *user,
int ret;
size_t to_copy;
struct kfd_smi_client *client = filep->private_data;
-   unsigned char buf[MAX_KFIFO_SIZE];
+   unsigned char *buf;
 
-   BUILD_BUG_ON(MAX_KFIFO_SIZE > 1024);
+   buf = kzalloc(MAX_KFIFO_SIZE * sizeof(*buf), GFP_KERNEL);
+   if (!buf)
+   return -ENOMEM;
 
/* kfifo_to_user can sleep so we can't use spinlock protection around
 * it. Instead, we kfifo out as spinlocked then copy them to the user.
@@ -88,19 +90,29 @@ static ssize_t kfd_smi_ev_read(struct file *filep, char 
__user *user,
to_copy = kfifo_len(>fifo);
if (!to_copy) {
spin_unlock(>lock);
-   return -EAGAIN;
+   ret = -EAGAIN;
+   goto ret_err;
}
to_copy = min3(size, sizeof(buf), to_copy);
ret = kfifo_out(>fifo, buf, to_copy);
spin_unlock(>lock);
-   if (ret <= 0)
-   return -EAGAIN;
+   if (ret <= 0) {
+   ret = -EAGAIN;
+   goto ret_err;
+   }
 
ret = copy_to_user(user, buf, to_copy);
-   if (ret)
-   return -EFAULT;
+   if (ret) {
+   ret = -EFAULT;
+   goto ret_err;
+   }
 
+   kfree(buf);
return to_copy;
+
+ret_err:
+   kfree(buf);
+   return ret;
 }
 
 static ssize_t kfd_smi_ev_write(struct file *filep, const char __user *user,
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm/amdgpu: off by on in amdgpu_device_attr_create_groups() error handling

[Wang, Kevin(Yang)]

[AMD Official Use Only - Internal Distribution Only]

thanks.

Reviewed-by: Kevin Wang 

Best Regads,
Kevin

From: Dan Carpenter 
Sent: Wednesday, May 20, 2020 9:08 PM
To: Deucher, Alexander ; Wang, Kevin(Yang) 

Cc: Koenig, Christian ; David Airlie 
; Daniel Vetter ; Quan, Evan 
; Huang, Ray ; Feng, Kenneth 
; Tao, Yintian ; Zhang, Hawking 
; amd-...@lists.freedesktop.org 
; dri-devel@lists.freedesktop.org 
; linux-ker...@vger.kernel.org 
; kernel-janit...@vger.kernel.org 

Subject: [PATCH v2] drm/amdgpu: off by on in amdgpu_device_attr_create_groups() 
error handling

This loop in the error handling code should start a "i - 1" and end at
"i == 0".  Currently it starts a "i" and ends at "i == 1".  The result
is that it removes one attribute that wasn't created yet, and leaks the
zeroeth attribute.

Fixes: 4e01847c38f7 ("drm/amdgpu: optimize amdgpu device attribute code")
Signed-off-by: Dan Carpenter 
---
v2: style change

 drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c   | 3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
index b75362bf0742..e809534fabd4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
@@ -1942,9 +1942,8 @@ static int amdgpu_device_attr_create_groups(struct 
amdgpu_device *adev,
 return 0;

 failed:
-   for (; i > 0; i--) {
+   while (i--)
 amdgpu_device_attr_remove(adev, [i]);
-   }

 return ret;
 }
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/1] drm: check for NULL pointer in drm_gem_object_put

[Emil Velikov]

On Wed, 20 May 2020 at 14:30, Emil Velikov  wrote:
>
> On Wed, 20 May 2020 at 14:17, Chris Wilson  wrote:
> >
> > Quoting Christian König (2020-05-20 13:54:55)
> > > Am 20.05.20 um 14:49 schrieb Chris Wilson:
> > > > Quoting Christian König (2020-05-20 13:19:42)
> > > >> Am 20.05.20 um 14:14 schrieb Nirmoy Das:
> > > >>> drm_gem_fb_destroy() calls drm_gem_object_put() with NULL obj causing:
> > > >>> [   11.584209] BUG: kernel NULL pointer dereference, address: 
> > > >>> 
> > > >>> [   11.584213] #PF: supervisor write access in kernel mode
> > > >>> [   11.584215] #PF: error_code(0x0002) - not-present page
> > > >>> [   11.584216] PGD 0 P4D 0
> > > >>> [   11.584220] Oops: 0002 [#1] SMP NOPTI
> > > >>> [   11.584223] CPU: 7 PID: 1571 Comm: gnome-shell Tainted: G  
> > > >>>   E 5.7.0-rc1-1-default+ #27
> > > >>> [   11.584225] Hardware name: Micro-Star International Co., Ltd. 
> > > >>> MS-7A31/X370 XPOWER GAMING TITANIUM (MS-7A31), BIOS 1.MR 12/03/2019
> > > >>> [   11.584237] RIP: 0010:drm_gem_fb_destroy+0x28/0x70 [drm_kms_helper]
> > > >>> 
> > > >>> [   11.584256] Call Trace:
> > > >>> [   11.584279]  drm_mode_rmfb+0x189/0x1c0 [drm]
> > > >>> [   11.584299]  ? drm_mode_rmfb+0x1c0/0x1c0 [drm]
> > > >>> [   11.584314]  drm_ioctl_kernel+0xaa/0xf0 [drm]
> > > >>> [   11.584329]  drm_ioctl+0x1ff/0x3b0 [drm]
> > > >>> [   11.584347]  ? drm_mode_rmfb+0x1c0/0x1c0 [drm]
> > > >>> [   11.584421]  amdgpu_drm_ioctl+0x49/0x80 [amdgpu]
> > > >>> [   11.584427]  ksys_ioctl+0x87/0xc0
> > > >>> [   11.584430]  __x64_sys_ioctl+0x16/0x20
> > > >>> [   11.584434]  do_syscall_64+0x5f/0x240
> > > >>> [   11.584438]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
> > > >>> [   11.584440] RIP: 0033:0x7f0ef80f7227
> > > >>>
> > > >>> Signed-off-by: Nirmoy Das 
> > > >> Fixes:  missing here. Apart from that Reviewed-by: Christian König
> > > >> .
> > > >>
> > > >> Please resend with the tag added, then I'm going to push this to
> > > >> drm-misc-next asap.
> > > >>
> > > >> Christian.
> > > >>
> > > >>> ---
> > > >>>include/drm/drm_gem.h | 3 +++
> > > >>>1 file changed, 3 insertions(+)
> > > >>>
> > > >>> diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
> > > >>> index 52173abdf500..a13510346a9b 100644
> > > >>> --- a/include/drm/drm_gem.h
> > > >>> +++ b/include/drm/drm_gem.h
> > > >>> @@ -372,6 +372,9 @@ static inline void drm_gem_object_get(struct 
> > > >>> drm_gem_object *obj)
> > > >>>static inline void
> > > >>>drm_gem_object_put(struct drm_gem_object *obj)
> > > >>>{
> > > >>> + if (!obj)
> > > >>> + return;
> > > >>> +
> > > > This adds several thousand NULL checks where there were previously none.
> > > > I doubt the compiler eliminates them all.
> > > >
> > > > I'd suggest reverting
> > > > b5d250744ccc ("drm/gem: fold drm_gem_object_put_unlocked and 
> > > > __drm_gem_object_put()")
> > >
> > > I didn't looked into this patch in detail, but allowing to call *_put()
> > > functions with NULL and nothing bad happens is rather common practice.
> > >
> > > On the other hand I agree that this might cause a performance problem.
> > > How many sites do we have which could call drm_gem_object_put() with NULL?
> >
> > Just to put this in a tiny bit of perspective, for i915.ko
> >
> > add/remove: 0/0 grow/shrink: 141/20 up/down: 2211/-525 (1686)
> >
> > We've had flame wars for less. (Because it's easy to argue over little
> > changes.) Now this is just from this patch and not the revert...
> > The revert has no effect on code size.
>
> If we play the revert game thing will never end with having it fixed :-(
> I'd suggest sticking with the NULL check, maybe even a WARN to aid
> debug the 240 usecases.
>
> For the patch:
> Fixes: b5d250744ccc ("drm/gem: fold drm_gem_object_put_unlocked and
> __drm_gem_object_put()")
> Reviewed-by: Emil Velikov 
>
Alternatively, if you give me 30 minutes I should be able to finish
auditing the users ;-)

-Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/1] drm: check for NULL pointer in drm_gem_object_put

[Emil Velikov]

On Wed, 20 May 2020 at 14:17, Chris Wilson  wrote:
>
> Quoting Christian König (2020-05-20 13:54:55)
> > Am 20.05.20 um 14:49 schrieb Chris Wilson:
> > > Quoting Christian König (2020-05-20 13:19:42)
> > >> Am 20.05.20 um 14:14 schrieb Nirmoy Das:
> > >>> drm_gem_fb_destroy() calls drm_gem_object_put() with NULL obj causing:
> > >>> [   11.584209] BUG: kernel NULL pointer dereference, address: 
> > >>> 
> > >>> [   11.584213] #PF: supervisor write access in kernel mode
> > >>> [   11.584215] #PF: error_code(0x0002) - not-present page
> > >>> [   11.584216] PGD 0 P4D 0
> > >>> [   11.584220] Oops: 0002 [#1] SMP NOPTI
> > >>> [   11.584223] CPU: 7 PID: 1571 Comm: gnome-shell Tainted: G
> > >>> E 5.7.0-rc1-1-default+ #27
> > >>> [   11.584225] Hardware name: Micro-Star International Co., Ltd. 
> > >>> MS-7A31/X370 XPOWER GAMING TITANIUM (MS-7A31), BIOS 1.MR 12/03/2019
> > >>> [   11.584237] RIP: 0010:drm_gem_fb_destroy+0x28/0x70 [drm_kms_helper]
> > >>> 
> > >>> [   11.584256] Call Trace:
> > >>> [   11.584279]  drm_mode_rmfb+0x189/0x1c0 [drm]
> > >>> [   11.584299]  ? drm_mode_rmfb+0x1c0/0x1c0 [drm]
> > >>> [   11.584314]  drm_ioctl_kernel+0xaa/0xf0 [drm]
> > >>> [   11.584329]  drm_ioctl+0x1ff/0x3b0 [drm]
> > >>> [   11.584347]  ? drm_mode_rmfb+0x1c0/0x1c0 [drm]
> > >>> [   11.584421]  amdgpu_drm_ioctl+0x49/0x80 [amdgpu]
> > >>> [   11.584427]  ksys_ioctl+0x87/0xc0
> > >>> [   11.584430]  __x64_sys_ioctl+0x16/0x20
> > >>> [   11.584434]  do_syscall_64+0x5f/0x240
> > >>> [   11.584438]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
> > >>> [   11.584440] RIP: 0033:0x7f0ef80f7227
> > >>>
> > >>> Signed-off-by: Nirmoy Das 
> > >> Fixes:  missing here. Apart from that Reviewed-by: Christian König
> > >> .
> > >>
> > >> Please resend with the tag added, then I'm going to push this to
> > >> drm-misc-next asap.
> > >>
> > >> Christian.
> > >>
> > >>> ---
> > >>>include/drm/drm_gem.h | 3 +++
> > >>>1 file changed, 3 insertions(+)
> > >>>
> > >>> diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
> > >>> index 52173abdf500..a13510346a9b 100644
> > >>> --- a/include/drm/drm_gem.h
> > >>> +++ b/include/drm/drm_gem.h
> > >>> @@ -372,6 +372,9 @@ static inline void drm_gem_object_get(struct 
> > >>> drm_gem_object *obj)
> > >>>static inline void
> > >>>drm_gem_object_put(struct drm_gem_object *obj)
> > >>>{
> > >>> + if (!obj)
> > >>> + return;
> > >>> +
> > > This adds several thousand NULL checks where there were previously none.
> > > I doubt the compiler eliminates them all.
> > >
> > > I'd suggest reverting
> > > b5d250744ccc ("drm/gem: fold drm_gem_object_put_unlocked and 
> > > __drm_gem_object_put()")
> >
> > I didn't looked into this patch in detail, but allowing to call *_put()
> > functions with NULL and nothing bad happens is rather common practice.
> >
> > On the other hand I agree that this might cause a performance problem.
> > How many sites do we have which could call drm_gem_object_put() with NULL?
>
> Just to put this in a tiny bit of perspective, for i915.ko
>
> add/remove: 0/0 grow/shrink: 141/20 up/down: 2211/-525 (1686)
>
> We've had flame wars for less. (Because it's easy to argue over little
> changes.) Now this is just from this patch and not the revert...
> The revert has no effect on code size.

If we play the revert game thing will never end with having it fixed :-(
I'd suggest sticking with the NULL check, maybe even a WARN to aid
debug the 240 usecases.

For the patch:
Fixes: b5d250744ccc ("drm/gem: fold drm_gem_object_put_unlocked and
__drm_gem_object_put()")
Reviewed-by: Emil Velikov 

-Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/doc: device hot-unplug for userspace

[Simon Ser]

On Wednesday, May 20, 2020 2:55 PM, Daniel Vetter  wrote:

> Maybe we should add an explicit note that there's no guarantee about the
> new chardev minor this new device will get, it could both inherit the
> existing one (you can't open the old one anymore anyway) or get a new one?
>
> Or does userspace want a guarantee, i.e. as long as there's still a handle
> open kernel guarantees to not recycle the chardev minor (which is what we
> currently do). In that case better to add that to your list of guarantees
> above.

The are race conditions to consider too, e.g.

- Compositor sends /dev/dri/card0 to a client
- card0 goes away
- Another device takes card0
- Client receives /dev/dri/card0 and then starts using it, but it's the
  wrong device

At first glance these seem like edge-cases that almost never happen.
However I've seen these happen in practice with connectors, especially
with docks.

One solution would be to number minor numbers like PIDs: don't recycle
card0 before we've reached the upper minor number limit.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/1] drm: check for NULL pointer in drm_gem_object_put

[Chris Wilson]

Quoting Christian König (2020-05-20 13:54:55)
> Am 20.05.20 um 14:49 schrieb Chris Wilson:
> > Quoting Christian König (2020-05-20 13:19:42)
> >> Am 20.05.20 um 14:14 schrieb Nirmoy Das:
> >>> drm_gem_fb_destroy() calls drm_gem_object_put() with NULL obj causing:
> >>> [   11.584209] BUG: kernel NULL pointer dereference, address: 
> >>> 
> >>> [   11.584213] #PF: supervisor write access in kernel mode
> >>> [   11.584215] #PF: error_code(0x0002) - not-present page
> >>> [   11.584216] PGD 0 P4D 0
> >>> [   11.584220] Oops: 0002 [#1] SMP NOPTI
> >>> [   11.584223] CPU: 7 PID: 1571 Comm: gnome-shell Tainted: GE 
> >>> 5.7.0-rc1-1-default+ #27
> >>> [   11.584225] Hardware name: Micro-Star International Co., Ltd. 
> >>> MS-7A31/X370 XPOWER GAMING TITANIUM (MS-7A31), BIOS 1.MR 12/03/2019
> >>> [   11.584237] RIP: 0010:drm_gem_fb_destroy+0x28/0x70 [drm_kms_helper]
> >>> 
> >>> [   11.584256] Call Trace:
> >>> [   11.584279]  drm_mode_rmfb+0x189/0x1c0 [drm]
> >>> [   11.584299]  ? drm_mode_rmfb+0x1c0/0x1c0 [drm]
> >>> [   11.584314]  drm_ioctl_kernel+0xaa/0xf0 [drm]
> >>> [   11.584329]  drm_ioctl+0x1ff/0x3b0 [drm]
> >>> [   11.584347]  ? drm_mode_rmfb+0x1c0/0x1c0 [drm]
> >>> [   11.584421]  amdgpu_drm_ioctl+0x49/0x80 [amdgpu]
> >>> [   11.584427]  ksys_ioctl+0x87/0xc0
> >>> [   11.584430]  __x64_sys_ioctl+0x16/0x20
> >>> [   11.584434]  do_syscall_64+0x5f/0x240
> >>> [   11.584438]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
> >>> [   11.584440] RIP: 0033:0x7f0ef80f7227
> >>>
> >>> Signed-off-by: Nirmoy Das 
> >> Fixes:  missing here. Apart from that Reviewed-by: Christian König
> >> .
> >>
> >> Please resend with the tag added, then I'm going to push this to
> >> drm-misc-next asap.
> >>
> >> Christian.
> >>
> >>> ---
> >>>include/drm/drm_gem.h | 3 +++
> >>>1 file changed, 3 insertions(+)
> >>>
> >>> diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
> >>> index 52173abdf500..a13510346a9b 100644
> >>> --- a/include/drm/drm_gem.h
> >>> +++ b/include/drm/drm_gem.h
> >>> @@ -372,6 +372,9 @@ static inline void drm_gem_object_get(struct 
> >>> drm_gem_object *obj)
> >>>static inline void
> >>>drm_gem_object_put(struct drm_gem_object *obj)
> >>>{
> >>> + if (!obj)
> >>> + return;
> >>> +
> > This adds several thousand NULL checks where there were previously none.
> > I doubt the compiler eliminates them all.
> >
> > I'd suggest reverting
> > b5d250744ccc ("drm/gem: fold drm_gem_object_put_unlocked and 
> > __drm_gem_object_put()")
> 
> I didn't looked into this patch in detail, but allowing to call *_put() 
> functions with NULL and nothing bad happens is rather common practice.
> 
> On the other hand I agree that this might cause a performance problem. 
> How many sites do we have which could call drm_gem_object_put() with NULL?

Just to put this in a tiny bit of perspective, for i915.ko

add/remove: 0/0 grow/shrink: 141/20 up/down: 2211/-525 (1686)

We've had flame wars for less. (Because it's easy to argue over little
changes.) Now this is just from this patch and not the revert...
The revert has no effect on code size.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v6 00/16] drm/i915: Add support for HDCP 1.4 over MST connectors

[Sean Paul]

On Mon, May 18, 2020 at 12:41 PM Ramalingam C  wrote:
>
> On 2020-05-18 at 10:32:09 -0400, Sean Paul wrote:
> > On Fri, May 15, 2020 at 10:48 AM Ramalingam C  
> > wrote:
> > >
> > > On 2020-04-29 at 15:54:46 -0400, Sean Paul wrote:
> > > > From: Sean Paul 
> > > >
> > > > Changes in v6:
> > > > -Rebased on -tip
> > > > -Disabled HDCP over MST on GEN12
> > > > -Addressed Lyude's review comments in the 
> > > > QUERY_STREAM_ENCRYPTION_STATUS patch
> > >
> > > Sean,
> > >
> > > What is the test setup you have used?
> > >
> >
> > Hi Ram,
> > Thanks for the feedback. To be completely honest it's really
> > frustrating that I'm just now getting questions and review feedback
> > (which I've been begging for on IRC) on this review that could have
> > been addressed ~5 months ago. It's super disruptive to have to keep
> > switching back to this after a long hiatus and many i915 refactors
> > complicating my rebases.
> Hi Sean,
>
> As a developer I really feel bad for the delay happened in review.
> I couldn't spend required time for understanding MST part hence I
> couldn't review.
>
> Just for this series now I have started preparing myself on these topics,
> hence started reviewing the series.
>
> If you are still interested to work on this, I can commit for regular reviews.
>

Thanks Ram. I'm still incentivized to get this in. Once you have had a
chance to look over the whole series, I'll revise again.

Sean



> Thanks,
> Ram.
> >
> > If no one wants this patchset, that's fine, please just let me know so
> > I don't waste any more time. If Intel is interested, could we please
> > stop the review trickle and lay out exactly what needs to be done to
> > get this landed?
> >
> > Sean
> >
> >
> > > I am afraid our CI dont have the coverage for MST capability yet to 
> > > provide
> > > the functional status of the code.
> > >
> > > -Ram.
> > > >
> > > > Sean Paul (16):
> > > >   drm/i915: Fix sha_text population code
> > > >   drm/i915: Clear the repeater bit on HDCP disable
> > > >   drm/i915: WARN if HDCP signalling is enabled upon disable
> > > >   drm/i915: Intercept Aksv writes in the aux hooks
> > > >   drm/i915: Use the cpu_transcoder in intel_hdcp to toggle HDCP
> > > > signalling
> > > >   drm/i915: Factor out hdcp->value assignments
> > > >   drm/i915: Protect workers against disappearing connectors
> > > >   drm/i915: Don't fully disable HDCP on a port if multiple pipes are
> > > > using it
> > > >   drm/i915: Support DP MST in enc_to_dig_port() function
> > > >   drm/i915: Use ddi_update_pipe in intel_dp_mst
> > > >   drm/i915: Factor out HDCP shim functions from dp for use by dp_mst
> > > >   drm/i915: Plumb port through hdcp init
> > > >   drm/i915: Add connector to hdcp_shim->check_link()
> > > >   drm/mst: Add support for QUERY_STREAM_ENCRYPTION_STATUS MST sideband
> > > > message
> > > >   drm/i915: Print HDCP version info for all connectors
> > > >   drm/i915: Add HDCP 1.4 support for MST connectors
> > > >
> > > >  drivers/gpu/drm/drm_dp_mst_topology.c | 142 
> > > >  drivers/gpu/drm/i915/Makefile |   1 +
> > > >  drivers/gpu/drm/i915/display/intel_ddi.c  |  29 +-
> > > >  drivers/gpu/drm/i915/display/intel_ddi.h  |   2 +
> > > >  .../drm/i915/display/intel_display_debugfs.c  |  21 +-
> > > >  .../drm/i915/display/intel_display_types.h|  30 +-
> > > >  drivers/gpu/drm/i915/display/intel_dp.c   | 654 +--
> > > >  drivers/gpu/drm/i915/display/intel_dp.h   |   9 +
> > > >  drivers/gpu/drm/i915/display/intel_dp_hdcp.c  | 743 ++
> > > >  drivers/gpu/drm/i915/display/intel_dp_mst.c   |  19 +
> > > >  drivers/gpu/drm/i915/display/intel_hdcp.c | 217 +++--
> > > >  drivers/gpu/drm/i915/display/intel_hdcp.h |   2 +-
> > > >  drivers/gpu/drm/i915/display/intel_hdmi.c |  25 +-
> > > >  .../drm/selftests/test-drm_dp_mst_helper.c|  17 +
> > > >  include/drm/drm_dp_helper.h   |   3 +
> > > >  include/drm/drm_dp_mst_helper.h   |  44 ++
> > > >  include/drm/drm_hdcp.h|   3 +
> > > >  17 files changed, 1235 insertions(+), 726 deletions(-)
> > > >  create mode 100644 drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> > > >
> > > > --
> > > > Sean Paul, Software Engineer, Google / Chromium OS
> > > >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2] drm/amdgpu: off by on in amdgpu_device_attr_create_groups() error handling

[Dan Carpenter]

This loop in the error handling code should start a "i - 1" and end at
"i == 0".  Currently it starts a "i" and ends at "i == 1".  The result
is that it removes one attribute that wasn't created yet, and leaks the
zeroeth attribute.

Fixes: 4e01847c38f7 ("drm/amdgpu: optimize amdgpu device attribute code")
Signed-off-by: Dan Carpenter 
---
v2: style change

 drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c   | 3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
index b75362bf0742..e809534fabd4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
@@ -1942,9 +1942,8 @@ static int amdgpu_device_attr_create_groups(struct 
amdgpu_device *adev,
return 0;
 
 failed:
-   for (; i > 0; i--) {
+   while (i--)
amdgpu_device_attr_remove(adev, [i]);
-   }
 
return ret;
 }
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2] drm/i915/hdcp: Add additional R0' wait

[Sean Paul]

From: Sean Paul 

We're seeing some R0' mismatches in the field, particularly with
repeaters. I'm guessing the (already lenient) 300ms wait time isn't
enough for some setups. So add an additional wait when R0' is
mismatched.

Signed-off-by: Sean Paul 

Changes in v2:
- Actually add the delay in R0` wait (Ram)
---

Apologies, v1 was generated from a forward port from the CrOS kernel and
patch got confused and put the diff in V' wait instead of R0' wait.

Pay closer attention, Sean.

 drivers/gpu/drm/i915/display/intel_hdcp.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c 
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 2cbc4619b4ce..3c2d8c0a6da6 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -743,6 +743,9 @@ static int intel_hdcp_auth(struct intel_connector 
*connector)
if (!wait_for(intel_de_read(dev_priv, HDCP_STATUS(dev_priv, 
cpu_transcoder, port)) &
  (HDCP_STATUS_RI_MATCH | HDCP_STATUS_ENC), 1))
break;
+
+   /* Maybe the sink is lazy, give it some more time */
+   usleep_range(1, 5);
}
 
if (i == tries) {
-- 
Sean Paul, Software Engineer, Google / Chromium OS

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/1] drm: check for NULL pointer in drm_gem_object_put

[Christian König]

Am 20.05.20 um 15:00 schrieb Daniel Vetter:

On Wed, May 20, 2020 at 02:54:55PM +0200, Christian König wrote:

Am 20.05.20 um 14:49 schrieb Chris Wilson:

Quoting Christian König (2020-05-20 13:19:42)

Am 20.05.20 um 14:14 schrieb Nirmoy Das:

drm_gem_fb_destroy() calls drm_gem_object_put() with NULL obj causing:
[   11.584209] BUG: kernel NULL pointer dereference, address: 
[   11.584213] #PF: supervisor write access in kernel mode
[   11.584215] #PF: error_code(0x0002) - not-present page
[   11.584216] PGD 0 P4D 0
[   11.584220] Oops: 0002 [#1] SMP NOPTI
[   11.584223] CPU: 7 PID: 1571 Comm: gnome-shell Tainted: GE 
5.7.0-rc1-1-default+ #27
[   11.584225] Hardware name: Micro-Star International Co., Ltd. MS-7A31/X370 
XPOWER GAMING TITANIUM (MS-7A31), BIOS 1.MR 12/03/2019
[   11.584237] RIP: 0010:drm_gem_fb_destroy+0x28/0x70 [drm_kms_helper]

[   11.584256] Call Trace:
[   11.584279]  drm_mode_rmfb+0x189/0x1c0 [drm]
[   11.584299]  ? drm_mode_rmfb+0x1c0/0x1c0 [drm]
[   11.584314]  drm_ioctl_kernel+0xaa/0xf0 [drm]
[   11.584329]  drm_ioctl+0x1ff/0x3b0 [drm]
[   11.584347]  ? drm_mode_rmfb+0x1c0/0x1c0 [drm]
[   11.584421]  amdgpu_drm_ioctl+0x49/0x80 [amdgpu]
[   11.584427]  ksys_ioctl+0x87/0xc0
[   11.584430]  __x64_sys_ioctl+0x16/0x20
[   11.584434]  do_syscall_64+0x5f/0x240
[   11.584438]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[   11.584440] RIP: 0033:0x7f0ef80f7227

Signed-off-by: Nirmoy Das 

Fixes:  missing here. Apart from that Reviewed-by: Christian König
.

Please resend with the tag added, then I'm going to push this to
drm-misc-next asap.

Christian.


---
include/drm/drm_gem.h | 3 +++
1 file changed, 3 insertions(+)

diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
index 52173abdf500..a13510346a9b 100644
--- a/include/drm/drm_gem.h
+++ b/include/drm/drm_gem.h
@@ -372,6 +372,9 @@ static inline void drm_gem_object_get(struct drm_gem_object 
*obj)
static inline void
drm_gem_object_put(struct drm_gem_object *obj)
{
+ if (!obj)
+ return;
+

This adds several thousand NULL checks where there were previously none.
I doubt the compiler eliminates them all.

I'd suggest reverting
b5d250744ccc ("drm/gem: fold drm_gem_object_put_unlocked and 
__drm_gem_object_put()")

I didn't looked into this patch in detail, but allowing to call *_put()
functions with NULL and nothing bad happens is rather common practice.

On the other hand I agree that this might cause a performance problem. How
many sites do we have which could call drm_gem_object_put() with NULL?

Hm how did we even get to a place where one of the _put functions had a
NULL check and the other didn't?


No idea.


I do expect the compiler to clean up the entire mess, only place where I
can think of NULL checks is dumb cleanup code when driver load failed
halfway through. In all other places the compiler should have some
evidence that the pointer isn't NULL. But would be good to check that's
the case and we're not doing something stupid here ...


Well Nirmoy is blocked, so we need a solution fast. Auditing all call 
sites is not an option.


Revert or this one here I would say, either one is fine with me.

Christian.


-Daniel


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/1] drm: check for NULL pointer in drm_gem_object_put

[Daniel Vetter]

On Wed, May 20, 2020 at 02:54:55PM +0200, Christian König wrote:
> Am 20.05.20 um 14:49 schrieb Chris Wilson:
> > Quoting Christian König (2020-05-20 13:19:42)
> > > Am 20.05.20 um 14:14 schrieb Nirmoy Das:
> > > > drm_gem_fb_destroy() calls drm_gem_object_put() with NULL obj causing:
> > > > [   11.584209] BUG: kernel NULL pointer dereference, address: 
> > > > 
> > > > [   11.584213] #PF: supervisor write access in kernel mode
> > > > [   11.584215] #PF: error_code(0x0002) - not-present page
> > > > [   11.584216] PGD 0 P4D 0
> > > > [   11.584220] Oops: 0002 [#1] SMP NOPTI
> > > > [   11.584223] CPU: 7 PID: 1571 Comm: gnome-shell Tainted: G
> > > > E 5.7.0-rc1-1-default+ #27
> > > > [   11.584225] Hardware name: Micro-Star International Co., Ltd. 
> > > > MS-7A31/X370 XPOWER GAMING TITANIUM (MS-7A31), BIOS 1.MR 12/03/2019
> > > > [   11.584237] RIP: 0010:drm_gem_fb_destroy+0x28/0x70 [drm_kms_helper]
> > > > 
> > > > [   11.584256] Call Trace:
> > > > [   11.584279]  drm_mode_rmfb+0x189/0x1c0 [drm]
> > > > [   11.584299]  ? drm_mode_rmfb+0x1c0/0x1c0 [drm]
> > > > [   11.584314]  drm_ioctl_kernel+0xaa/0xf0 [drm]
> > > > [   11.584329]  drm_ioctl+0x1ff/0x3b0 [drm]
> > > > [   11.584347]  ? drm_mode_rmfb+0x1c0/0x1c0 [drm]
> > > > [   11.584421]  amdgpu_drm_ioctl+0x49/0x80 [amdgpu]
> > > > [   11.584427]  ksys_ioctl+0x87/0xc0
> > > > [   11.584430]  __x64_sys_ioctl+0x16/0x20
> > > > [   11.584434]  do_syscall_64+0x5f/0x240
> > > > [   11.584438]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
> > > > [   11.584440] RIP: 0033:0x7f0ef80f7227
> > > > 
> > > > Signed-off-by: Nirmoy Das 
> > > Fixes:  missing here. Apart from that Reviewed-by: Christian König
> > > .
> > > 
> > > Please resend with the tag added, then I'm going to push this to
> > > drm-misc-next asap.
> > > 
> > > Christian.
> > > 
> > > > ---
> > > >include/drm/drm_gem.h | 3 +++
> > > >1 file changed, 3 insertions(+)
> > > > 
> > > > diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
> > > > index 52173abdf500..a13510346a9b 100644
> > > > --- a/include/drm/drm_gem.h
> > > > +++ b/include/drm/drm_gem.h
> > > > @@ -372,6 +372,9 @@ static inline void drm_gem_object_get(struct 
> > > > drm_gem_object *obj)
> > > >static inline void
> > > >drm_gem_object_put(struct drm_gem_object *obj)
> > > >{
> > > > + if (!obj)
> > > > + return;
> > > > +
> > This adds several thousand NULL checks where there were previously none.
> > I doubt the compiler eliminates them all.
> > 
> > I'd suggest reverting
> > b5d250744ccc ("drm/gem: fold drm_gem_object_put_unlocked and 
> > __drm_gem_object_put()")
> 
> I didn't looked into this patch in detail, but allowing to call *_put()
> functions with NULL and nothing bad happens is rather common practice.
> 
> On the other hand I agree that this might cause a performance problem. How
> many sites do we have which could call drm_gem_object_put() with NULL?

Hm how did we even get to a place where one of the _put functions had a
NULL check and the other didn't?

I do expect the compiler to clean up the entire mess, only place where I
can think of NULL checks is dumb cleanup code when driver load failed
halfway through. In all other places the compiler should have some
evidence that the pointer isn't NULL. But would be good to check that's
the case and we're not doing something stupid here ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/doc: device hot-unplug for userspace

[Daniel Vetter]

On Tue, May 19, 2020 at 01:06:49PM +0300, Pekka Paalanen wrote:
> From: Pekka Paalanen 
> 
> Set up the expectations on how hot-unplugging a DRM device should look like to
> userspace.
> 
> Written by Daniel Vetter's request and largely based on his comments in IRC 
> and
> from https://lists.freedesktop.org/archives/dri-devel/2020-May/265484.html .
> 
> Signed-off-by: Pekka Paalanen 
> Cc: Daniel Vetter 
> Cc: Andrey Grodzovsky 
> Cc: Dave Airlie 
> Cc: Sean Paul 
> 
> ---
> 
> Disclaimer: I am a userspace developer writing for other userspace developers.
> I took some liberties in defining what should happen without knowing what is
> actually possible or what existing drivers already implement.
> ---
>  Documentation/gpu/drm-uapi.rst | 75 ++
>  1 file changed, 75 insertions(+)
> 
> diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
> index 56fec6ed1ad8..80db4abd2cbd 100644
> --- a/Documentation/gpu/drm-uapi.rst
> +++ b/Documentation/gpu/drm-uapi.rst
> @@ -1,3 +1,5 @@
> +.. Copyright 2020 DisplayLink (UK) Ltd.
> +
>  ===
>  Userland interfaces
>  ===
> @@ -162,6 +164,79 @@ other hand, a driver requires shared state between 
> clients which is
>  visible to user-space and accessible beyond open-file boundaries, they
>  cannot support render nodes.
>  
> +Device Hot-Unplug
> +=
> +
> +.. note::
> +   The following is the plan. Implementation is not there yet
> +   (2020 May 13).
> +
> +Graphics devices (display and/or render) may be connected via USB (e.g.
> +display adapters or docking stations) or Thunderbolt (e.g. eGPU). An end
> +user is able to hot-unplug this kind of devices while they are being
> +used, and expects that the very least the machine does not crash. Any
> +damage from hot-unplugging a DRM device needs to be limited as much as
> +possible and userspace must be given the chance to handle it if it wants
> +to. Ideally, unplugging a DRM device still lets a desktop to continue
> +running, but that is going to need explicit support throughout the whole
> +graphics stack: from kernel and userspace drivers, through display
> +servers, via window system protocols, and in applications and libraries.
> +
> +Other scenarios that should lead to the same are: unrecoverable GPU
> +crash, PCI device disappearing off the bus, or forced unbind of a driver
> +from the physical device.
> +
> +In other words, from userspace perspective everything needs to keep on
> +working more or less, until userspace stops using the disappeared DRM
> +device and closes it completely. Userspace will learn of the device
> +disappearance from the device removed uevent or in some cases specific
> +ioctls returning EIO.
> +
> +This goal raises at least the following requirements for the kernel and
> +drivers:
> +
> +- The kernel must not hang, crash or oops, no matter what userspace was
> +  in the middle of doing when the device disappeared.
> +
> +- All GPU jobs that can no longer run must have their fences
> +  force-signalled to avoid inflicting hangs to userspace.
> +
> +- KMS connectors must change their status to disconnected.
> +
> +- Legacy modesets and pageflips fake success.
> +
> +- Atomic commits, both real and TEST_ONLY, fake success.
> +
> +- Pending non-blocking KMS operations deliver the DRM events userspace
> +  is expecting.
> +
> +- If underlying memory disappears, the mmaps are replaced with harmless
> +  zero pages where access does not raise SIGBUS. Reads return zeros,
> +  writes are ignored.

Hm this is going to be expensive to implement, every write access would
cause a minor fault to catch it and throw it away. That's not going to be
fast is someone is caught trying to upload a giant texture at that moment
:-/

Could we go with just "Reads and writes will still completely without
errors, but have otherwise undefined behaviour". Then we could go with a
"single shared page for every drmfd" (to avoid leaks), set up with rw
permissions. That's dirt cheap, should be easy to implement and everything
stays fast.

> +
> +- dmabuf which point to memory that has disappeared are rewritten to
> +  point to harmless zero pages, similar to mmaps. Imports still succeed
> +  both ways: an existing device importing a dmabuf pointing to
> +  disappeared memory, and a disappeared device importing any dmabuf.

Same here about mmaps.

> +
> +- Render ioctls return EIO which is then handled in userspace drivers,
> +  e.g. Mesa, to have the device disappearance handled in the way
> +  specified for each API (OpenGL, GL ES: GL_KHR_robustness;
> +  Vulkan: VK_ERROR_DEVICE_LOST; etc.)

I'd go further and spec that driver-specific render ioctl have driver
specific behaviour, but overall must not result in crashes and failures
expect as specified in the client apis you already list.

Some drivers might just go with an uevent and have no errors from ioctls,
some might only want to have an error on a very specific ioctl, 

Re: [PATCH] drm/amdgpu: off by on in amdgpu_device_attr_create_groups() error handling

[Dan Carpenter]

On Wed, May 20, 2020 at 02:05:19PM +0200, Christian König wrote:
> Am 20.05.20 um 14:00 schrieb Dan Carpenter:
> > This loop in the error handling code should start a "i - 1" and end at
> > "i == 0".  Currently it starts a "i" and ends at "i == 1".  The result
> > is that it removes one attribute that wasn't created yet, and leaks the
> > zeroeth attribute.
> > 
> > Fixes: 4e01847c38f7 ("drm/amdgpu: optimize amdgpu device attribute code")
> > Signed-off-by: Dan Carpenter 
> > ---
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 5 ++---
> >   1 file changed, 2 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c 
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
> > index b75362bf0742..ee4a8e44fbeb 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
> > @@ -1931,7 +1931,7 @@ static int amdgpu_device_attr_create_groups(struct 
> > amdgpu_device *adev,
> > uint32_t mask)
> >   {
> > int ret = 0;
> > -   uint32_t i = 0;
> > +   int i;
> > for (i = 0; i < counts; i++) {
> > ret = amdgpu_device_attr_create(adev, [i], mask);
> > @@ -1942,9 +1942,8 @@ static int amdgpu_device_attr_create_groups(struct 
> > amdgpu_device *adev,
> > return 0;
> >   failed:
> > -   for (; i > 0; i--) {
> > +   while (--i >= 0)
> 
> As far as I know the common idiom for this is while (i--) which even works
> without changing the type of i to signed.

It's about 50/50, one way or the other.  To me --i >= 0 seems far more
readable.

I've been trying to figure out which tool tells people to make iterators
unsigned so I can help them avoid it.  :/  I understand how in theory
iterators could go above INT_MAX but if we're going above INT_MAX then
probably we should use a 64 bit type.  There are very few times where 2
billion iterations is not enough but in those situations probably 4
billion is not enough either.  So unsigned int iterators never or seldom
solve real life bugs but they regularly cause them.

regards,
dan carpenter

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/1] drm: check for NULL pointer in drm_gem_object_put

[Christian König]

Am 20.05.20 um 14:49 schrieb Chris Wilson:

Quoting Christian König (2020-05-20 13:19:42)

Am 20.05.20 um 14:14 schrieb Nirmoy Das:

drm_gem_fb_destroy() calls drm_gem_object_put() with NULL obj causing:
[   11.584209] BUG: kernel NULL pointer dereference, address: 
[   11.584213] #PF: supervisor write access in kernel mode
[   11.584215] #PF: error_code(0x0002) - not-present page
[   11.584216] PGD 0 P4D 0
[   11.584220] Oops: 0002 [#1] SMP NOPTI
[   11.584223] CPU: 7 PID: 1571 Comm: gnome-shell Tainted: GE 
5.7.0-rc1-1-default+ #27
[   11.584225] Hardware name: Micro-Star International Co., Ltd. MS-7A31/X370 
XPOWER GAMING TITANIUM (MS-7A31), BIOS 1.MR 12/03/2019
[   11.584237] RIP: 0010:drm_gem_fb_destroy+0x28/0x70 [drm_kms_helper]

[   11.584256] Call Trace:
[   11.584279]  drm_mode_rmfb+0x189/0x1c0 [drm]
[   11.584299]  ? drm_mode_rmfb+0x1c0/0x1c0 [drm]
[   11.584314]  drm_ioctl_kernel+0xaa/0xf0 [drm]
[   11.584329]  drm_ioctl+0x1ff/0x3b0 [drm]
[   11.584347]  ? drm_mode_rmfb+0x1c0/0x1c0 [drm]
[   11.584421]  amdgpu_drm_ioctl+0x49/0x80 [amdgpu]
[   11.584427]  ksys_ioctl+0x87/0xc0
[   11.584430]  __x64_sys_ioctl+0x16/0x20
[   11.584434]  do_syscall_64+0x5f/0x240
[   11.584438]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[   11.584440] RIP: 0033:0x7f0ef80f7227

Signed-off-by: Nirmoy Das 

Fixes:  missing here. Apart from that Reviewed-by: Christian König
.

Please resend with the tag added, then I'm going to push this to
drm-misc-next asap.

Christian.


---
   include/drm/drm_gem.h | 3 +++
   1 file changed, 3 insertions(+)

diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
index 52173abdf500..a13510346a9b 100644
--- a/include/drm/drm_gem.h
+++ b/include/drm/drm_gem.h
@@ -372,6 +372,9 @@ static inline void drm_gem_object_get(struct drm_gem_object 
*obj)
   static inline void
   drm_gem_object_put(struct drm_gem_object *obj)
   {
+ if (!obj)
+ return;
+

This adds several thousand NULL checks where there were previously none.
I doubt the compiler eliminates them all.

I'd suggest reverting
b5d250744ccc ("drm/gem: fold drm_gem_object_put_unlocked and 
__drm_gem_object_put()")


I didn't looked into this patch in detail, but allowing to call *_put() 
functions with NULL and nothing bad happens is rather common practice.


On the other hand I agree that this might cause a performance problem. 
How many sites do we have which could call drm_gem_object_put() with NULL?


Christian.


-Chris


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/1] drm: check for NULL pointer in drm_gem_object_put

[Chris Wilson]

Quoting Christian König (2020-05-20 13:19:42)
> Am 20.05.20 um 14:14 schrieb Nirmoy Das:
> > drm_gem_fb_destroy() calls drm_gem_object_put() with NULL obj causing:
> > [   11.584209] BUG: kernel NULL pointer dereference, address: 
> > 
> > [   11.584213] #PF: supervisor write access in kernel mode
> > [   11.584215] #PF: error_code(0x0002) - not-present page
> > [   11.584216] PGD 0 P4D 0
> > [   11.584220] Oops: 0002 [#1] SMP NOPTI
> > [   11.584223] CPU: 7 PID: 1571 Comm: gnome-shell Tainted: GE   
> >   5.7.0-rc1-1-default+ #27
> > [   11.584225] Hardware name: Micro-Star International Co., Ltd. 
> > MS-7A31/X370 XPOWER GAMING TITANIUM (MS-7A31), BIOS 1.MR 12/03/2019
> > [   11.584237] RIP: 0010:drm_gem_fb_destroy+0x28/0x70 [drm_kms_helper]
> > 
> > [   11.584256] Call Trace:
> > [   11.584279]  drm_mode_rmfb+0x189/0x1c0 [drm]
> > [   11.584299]  ? drm_mode_rmfb+0x1c0/0x1c0 [drm]
> > [   11.584314]  drm_ioctl_kernel+0xaa/0xf0 [drm]
> > [   11.584329]  drm_ioctl+0x1ff/0x3b0 [drm]
> > [   11.584347]  ? drm_mode_rmfb+0x1c0/0x1c0 [drm]
> > [   11.584421]  amdgpu_drm_ioctl+0x49/0x80 [amdgpu]
> > [   11.584427]  ksys_ioctl+0x87/0xc0
> > [   11.584430]  __x64_sys_ioctl+0x16/0x20
> > [   11.584434]  do_syscall_64+0x5f/0x240
> > [   11.584438]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
> > [   11.584440] RIP: 0033:0x7f0ef80f7227
> >
> > Signed-off-by: Nirmoy Das 
> 
> Fixes:  missing here. Apart from that Reviewed-by: Christian König 
> .
> 
> Please resend with the tag added, then I'm going to push this to 
> drm-misc-next asap.
> 
> Christian.
> 
> > ---
> >   include/drm/drm_gem.h | 3 +++
> >   1 file changed, 3 insertions(+)
> >
> > diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
> > index 52173abdf500..a13510346a9b 100644
> > --- a/include/drm/drm_gem.h
> > +++ b/include/drm/drm_gem.h
> > @@ -372,6 +372,9 @@ static inline void drm_gem_object_get(struct 
> > drm_gem_object *obj)
> >   static inline void
> >   drm_gem_object_put(struct drm_gem_object *obj)
> >   {
> > + if (!obj)
> > + return;
> > +

This adds several thousand NULL checks where there were previously none.
I doubt the compiler eliminates them all.

I'd suggest reverting
b5d250744ccc ("drm/gem: fold drm_gem_object_put_unlocked and 
__drm_gem_object_put()")
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/doc: device hot-unplug for userspace

[Daniel Vetter]

On Wed, May 20, 2020 at 02:19:08PM +0300, Pekka Paalanen wrote:
> On Tue, 19 May 2020 10:37:12 -0400
> Andrey Grodzovsky  wrote:
> 
> > Thanks for the summary, does put things in order and makes it easier to 
> > comprehend all the TODOs, some questions bellow
> > 
> > On 5/19/20 6:06 AM, Pekka Paalanen wrote:
> > > From: Pekka Paalanen 
> > >
> > > Set up the expectations on how hot-unplugging a DRM device should look 
> > > like to
> > > userspace.
> > >
> > > Written by Daniel Vetter's request and largely based on his comments in 
> > > IRC and
> > > from 
> > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Farchives%2Fdri-devel%2F2020-May%2F265484.htmldata=02%7C01%7Candrey.grodzovsky%40amd.com%7Ce8e13dc4c85648e5fcd408d7fbdc5f2b%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637254796242596783sdata=bA%2FAy3VGvzNqmV1kGigNROSZQEws2E98JibDxvEICNs%3Dreserved=0
> > >  .
> > >
> > > Signed-off-by: Pekka Paalanen 
> > > Cc: Daniel Vetter 
> > > Cc: Andrey Grodzovsky 
> > > Cc: Dave Airlie 
> > > Cc: Sean Paul 
> > >
> > > ---
> > >
> > > Disclaimer: I am a userspace developer writing for other userspace 
> > > developers.
> > > I took some liberties in defining what should happen without knowing what 
> > > is
> > > actually possible or what existing drivers already implement.
> > > ---
> > >   Documentation/gpu/drm-uapi.rst | 75 ++
> > >   1 file changed, 75 insertions(+)
> > >
> > > diff --git a/Documentation/gpu/drm-uapi.rst 
> > > b/Documentation/gpu/drm-uapi.rst
> > > index 56fec6ed1ad8..80db4abd2cbd 100644
> > > --- a/Documentation/gpu/drm-uapi.rst
> > > +++ b/Documentation/gpu/drm-uapi.rst
> > > @@ -1,3 +1,5 @@
> > > +.. Copyright 2020 DisplayLink (UK) Ltd.
> > > +
> > >   ===
> > >   Userland interfaces
> > >   ===
> > > @@ -162,6 +164,79 @@ other hand, a driver requires shared state between 
> > > clients which is
> > >   visible to user-space and accessible beyond open-file boundaries, they
> > >   cannot support render nodes.
> > >   
> > > +Device Hot-Unplug
> > > +=
> > > +
> > > +.. note::
> > > +   The following is the plan. Implementation is not there yet
> > > +   (2020 May 13).
> > > +
> > > +Graphics devices (display and/or render) may be connected via USB (e.g.
> > > +display adapters or docking stations) or Thunderbolt (e.g. eGPU). An end
> > > +user is able to hot-unplug this kind of devices while they are being
> > > +used, and expects that the very least the machine does not crash. Any
> > > +damage from hot-unplugging a DRM device needs to be limited as much as
> > > +possible and userspace must be given the chance to handle it if it wants
> > > +to. Ideally, unplugging a DRM device still lets a desktop to continue
> > > +running, but that is going to need explicit support throughout the whole
> > > +graphics stack: from kernel and userspace drivers, through display
> > > +servers, via window system protocols, and in applications and libraries.
> > > +
> > > +Other scenarios that should lead to the same are: unrecoverable GPU
> > > +crash, PCI device disappearing off the bus, or forced unbind of a driver
> > > +from the physical device.
> > > +
> > > +In other words, from userspace perspective everything needs to keep on
> > > +working more or less, until userspace stops using the disappeared DRM
> > > +device and closes it completely. Userspace will learn of the device
> > > +disappearance from the device removed uevent or in some cases specific
> > > +ioctls returning EIO.
> > > +
> > > +This goal raises at least the following requirements for the kernel and
> > > +drivers:
> > > +
> > > +- The kernel must not hang, crash or oops, no matter what userspace was
> > > +  in the middle of doing when the device disappeared.
> > > +
> > > +- All GPU jobs that can no longer run must have their fences
> > > +  force-signalled to avoid inflicting hangs to userspace.
> > > +
> > > +- KMS connectors must change their status to disconnected.
> > > +
> > > +- Legacy modesets and pageflips fake success.
> > > +
> > > +- Atomic commits, both real and TEST_ONLY, fake success.  
> > 
> > 
> > Why wouldn't we return -EIO for the atommic commit IOTCL/legasy pflip 
> > and modeset ioctls here same way as you suggested returning -EIO for 
> > render ioctl ?
> 
> Hi,
> 
> that is more of a question for Daniel Vetter than me. I believe he is
> worried that userspace will get the error handling horribly wrong
> anyway, because it needs to be handled in every single display server
> project. Render ioctl errors OTOH need to be handled only in the
> corresponding Mesa or other userspace driver, and for render there are
> API (OpenGL/EGL, Vulkan) specs that say how it must be handled to fill
> the API contract. Because of the API contract, those are more likely to
> have reasonable error handling in place already.

Yup pretty much. Atm compositors expect an -EINVAL (especially for

Re: [PATCH 2/2] drm: add docs for standard CRTC properties

[Daniel Vetter]

On Mon, May 18, 2020 at 02:22:47PM +, Simon Ser wrote:
> This patch adds docs for the ACTIVE and MODE_ID CRTC properties.
> 
> Signed-off-by: Simon Ser 
> Cc: Daniel Vetter 
> Cc: Ville Syrjala 
> Cc: Pekka Paalanen 
> Cc: Michel Dänzer 
> ---
> 
> Let me know if you think of other things to add.
> 
> Should we refer to ALLOW_MODESET in the MODE_ID docs?
> 
>  Documentation/gpu/drm-kms.rst |  5 +
>  drivers/gpu/drm/drm_crtc.c| 16 
>  2 files changed, 21 insertions(+)
> 
> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> index 397314d08f77..4289b7205696 100644
> --- a/Documentation/gpu/drm-kms.rst
> +++ b/Documentation/gpu/drm-kms.rst
> @@ -460,6 +460,11 @@ HDMI Specific Connector Properties
>  .. kernel-doc:: drivers/gpu/drm/drm_connector.c
> :doc: HDMI connector properties
>  
> +Standard CRTC Properties

Missing the 
--
line here so this reanders neatly as a title and works with the sidebar
toc. Please check the output to make sure that all looks good.


> +
> +.. kernel-doc:: drivers/gpu/drm/drm_crtc.c
> +   :doc: standard CRTC properties
> +
>  Plane Composition Properties
>  
>  
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 4936e1080e41..c28e662c1e93 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -204,6 +204,22 @@ struct dma_fence *drm_crtc_create_fence(struct drm_crtc 
> *crtc)
>   return fence;
>  }
>  
> +/**
> + * DOC: standard CRTC properties
> + *
> + * DRM CRTCs have a few standardized properties:
> + *
> + * ACTIVE:
> + *   Atomic property for setting the power state of the CRTC. When set to 1 
> the
> + *   CRTC will actively display content. When set to 0 the CRTC will be 
> powered
> + *   off. There is no expectation that user-space will reset CRTC resources 
> like
> + *   the mode and planes when setting ACTIVE to 0.

Maybe add "Note that the legacy DPMS property on connectors is internally
routed to control this property for atomic drivers."


Also I think we should add the dpms guarantee here.

"Userspace can rely on an change to ACTIVE always suceeding as long as no
other property has changed. If a change to ACTIVE only fails an atomic
test, this is a driver bug."

Kinda important part of the uapi here :-) Also the dpms emulation relies
on this.

> + * MODE_ID:
> + *   Atomic property for setting the CRTC display timings. The value is the 
> ID
> + *   of a blob containing the DRM mode info. To disable the CRTC, user-space
> + *   must set this property to 0.

Maybe we should add: "Note that only disabling by setting MODE_ID to 0
will release all internal resources (like reserved memory bandwidth or
clock generators). Only setting ACTIVE to 0 does not release reserved
resources, but only shuts down the hardware."

With these clarifications all added:

Reviewed-by: Daniel Vetter 

Thanks for doing this, I think really important we start properly
documenting these uapi details at least somewhere!

Cheers, Daniel

> + */
> +
>  /**
>   * drm_crtc_init_with_planes - Initialise a new CRTC object with
>   *specified primary and cursor planes.
> -- 
> 2.26.2
> 
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] ASoC: fsl: imx-pcm-dma: Don't request dma channel in probe

[Mark Brown]

On Wed, May 20, 2020 at 07:22:19PM +0800, Shengjiu Wang wrote:

> I see some driver also request dma channel in open() or hw_params().
> how can they avoid the defer probe issue?
> for example：
> sound/arm/pxa2xx-pcm-lib.c
> sound/soc/sprd/sprd-pcm-dma.c

Other drivers having problems means those drivers should be fixed, not
that we should copy the problems.  In the case of the PXA driver that's
very old code which predates deferred probe by I'd guess a decade.


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm: DPMS is no longer the only mutable connector prop

[Daniel Vetter]

On Mon, May 18, 2020 at 02:22:28PM +, Simon Ser wrote:
> There are a bunch of other writable connector properties now.
> 
> Signed-off-by: Simon Ser 
> Cc: Daniel Vetter 
> Cc: Ville Syrjala 
> Cc: Pekka Paalanen 
> Cc: Michel Dänzer 

Reviewed-by: Daniel Vetter 

I think in general the list of connector properties has become rather
sprawling and disorganized ...
-Daniel

> ---
>  drivers/gpu/drm/drm_connector.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index b1099e1251a2..f2b20fd66319 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -948,8 +948,7 @@ static const struct drm_prop_enum_list dp_colorspaces[] = 
> {
>   *   connector is linked to. Drivers should never set this property directly,
>   *   it is handled by the DRM core by calling the _connector_funcs.dpms
>   *   callback. For atomic drivers the remapping to the "ACTIVE" property is
> - *   implemented in the DRM core.  This is the only standard connector
> - *   property that userspace can change.
> + *   implemented in the DRM core.
>   *
>   *   Note that this property cannot be set through the MODE_ATOMIC ioctl,
>   *   userspace must use "ACTIVE" on the CRTC instead.
> -- 
> 2.26.2
> 
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PULL] drm-intel-next-fixes

[Joonas Lahtinen]

Hi Dave & Daniel,

On top of the drm-intel-next PR one fix for TypeC mode resets and
two compile time warning fixes.

CI results for your viewing:

https://intel-gfx-ci.01.org/tree/drm-intel-next-fixes/combined-alt.html

CI_DINF_189 = drm-intel-next pull
CI_DINF_190 = this pull (3 patches)

There is one regression in drm-intel-next baseline due to a bad
merge: igt@i915_selftest@live@gt_pm fails on TGL. The fix will
be in next weeks PR:

https://patchwork.freedesktop.org/patch/366280/?series=77448=1

Regards, Joonas

***

drm-intel-next-fixes-2020-05-20:

Fix for TypeC power domain toggling on resets (Cc: stable).
Two compile time warning fixes.

The following changes since commit 230982d8d8df7f9d9aa216840ea2db1df6ad5d37:

  drm/i915: Update DRIVER_DATE to 20200430 (2020-04-30 11:13:21 +0300)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel 
tags/drm-intel-next-fixes-2020-05-20

for you to fetch changes up to d96536f0fe699729a0974eb5b65eb0d87cc747e1:

  drm/i915: Fix AUX power domain toggling across TypeC mode resets (2020-05-19 
17:54:07 +0300)


Fix for TypeC power domain toggling on resets (Cc: stable).
Two compile time warning fixes.


Arnd Bergmann (1):
  drm/i915: avoid unused scale_user_to_hw() warning

Chris Wilson (40):
  drm/i915/gt: Move the batch buffer pool from the engine to the gt
  drm/i915/pmu: Keep a reference to module while active
  drm/i915/gt: Make timeslicing an explicit engine property
  drm/i915: Implement vm_ops->access for gdb access into mmaps
  drm/i915/gem: Use chained reloc batches
  drm/i915/gem: Use a single chained reloc batches for a single execbuf
  drm/i915/gem: Try an alternate engine for relocations
  drm/i915/gt: Sanitize RPS interrupts upon resume
  drm/i915/gem: Lazily acquire the device wakeref for freeing objects
  drm/i915: Allow some leniency in PCU reads
  drm/i915/gem: Specify address type for chained reloc batches
  drm/i915/gem: Implement legacy MI_STORE_DATA_IMM
  drm/i915/display: Warn if the FBC is still writing to stolen on removal
  drm/i915/selftests: Repeat the rps clock frequency measurement
  drm/i915/gt: Small tidy of gen8+ breadcrumb emission
  drm/i915/execlists: Record the active CCID from before reset
  drm/i915/gt: Stop holding onto the pinned_default_state
  drm/i915: Propagate error from completed fences
  drm/i915: Mark concurrent submissions with a weak-dependency
  drm/i915: Remove wait priority boosting
  drm/i915: Ignore submit-fences on the same timeline
  drm/i915: Pull waiting on an external dma-fence into its routine
  drm/i915/gt: Improve precision on defer_request assert
  drm/i915: Prevent using semaphores to chain up to external fences
  drm/i915: Replace the hardcoded I915_FENCE_TIMEOUT
  drm/i915/gt: Mark up the racy read of execlists->context_tag
  drm/i915: Tidy awaiting on dma-fences
  drm/i915: Emit await(batch) before MI_BB_START
  drm/i915/selftests: Always flush before unpining after writing
  drm/i915/gt: Restore Cherryview back to full-ppgtt
  drm/i915: Handle idling during i915_gem_evict_something busy loops
  drm/i915/gt: Reset execlists registers before HWSP
  drm/i915/gt: Suspend tasklets before resume sanitization
  drm/i915/gem: Remove redundant exec_fence
  drm/i915: Mark the addition of the initial-breadcrumb in the request
  drm/i915: Drop I915_RESET_TIMEOUT and friends
  drm/i915: Drop no-semaphore boosting
  drm/i915: Show per-engine default property values in sysfs
  drm/i915/selftests: Always call the provided engine->emit_init_breadcrumb
  drm/i915/gt: Transfer old virtual breadcrumbs to irq_worker

Gustavo A. R. Silva (1):
  drm/i915: Replace zero-length array with flexible-array

Gwan-gyeong Mun (14):
  video/hdmi: Add Unpack only function for DRM infoframe
  drm/i915/dp: Read out DP SDPs
  drm: Add logging function for DP VSC SDP
  drm/i915: Include HDMI DRM infoframe in the crtc state dump
  drm/i915: Include DP HDR Metadata Infoframe SDP in the crtc state dump
  drm/i915: Include DP VSC SDP in the crtc state dump
  drm/i915: Program DP SDPs with computed configs
  drm/i915: Add state readout for DP HDR Metadata Infoframe SDP
  drm/i915: Add state readout for DP VSC SDP
  drm/i915: Fix enabled infoframe states of lspcon
  drm/i915: Program DP SDPs on pipe updates
  drm/i915: Stop sending DP SDPs on ddi disable
  drm/i915/dp: Add compute routine for DP PSR VSC SDP
  drm/i915/psr: Use new DP VSC SDP compute routine on PSR

Imre Deak (2):
  drm/i915/tgl+: Fix interrupt handling for DP AUX transactions
  drm/i915: Fix AUX power domain toggling across TypeC mode resets

Joonas Lahtinen (3):
  Merge tag 

Re: [PATCH] Lenovo X13 Yoga OLED panel brightness fix

[Daniel Vetter]

On Mon, May 18, 2020 at 07:13:58PM -0400, Lyude Paul wrote:
> ok-actually, I'm not sure dim will actually allow me to push this because this
> never hit dri-devel as a properly formatted patch (because of the 
> --
> -- you put at the top of the branch confusing things)
> 
> Can you try again without adding any comments, and ideally see if lenovo can
> make it so you can just use git send-email? (unfortunately you're really not
> going to be able to work around this if you'll need to be submitting patches
> more regularly in the future I'm afraid)

Other option is hand-edit the patch and then manually add the msg-id
reference with dim add-links (or whatever it was) so the archive links are
too much off. That should work all somehow.

Still yeah gitlab mr would be neater.
-Daniel

> 
> On Mon, 2020-05-18 at 18:43 -0400, Lyude Paul wrote:
> > Yeah, git send-email is kinda :(, but unfortunately the entire kernel uses
> > this
> > workflow. Hopefully freedesktop's gitlab efforts will change this someday...
> > 
> > also - in the future, if you don't want comments to appear in the patch when
> > they're applied put them below the ---, e.g. the one before the Reviewed-by:
> > tag.
> > 
> > Anyway-I'll go ahead and push this, thanks for keeping this list up to date!
> > 
> > On Mon, 2020-05-18 at 00:06 +, Mark Pearson wrote:
> > > Hi,
> > > 
> > > Patch to fix an issue controlling the brightness of the OLED panel on the
> > > Lenovo X13 Yoga 
> > > Please let me know any feedback or questions.
> > > Note - apologies if this message has shown up before - I had some mail
> > > client
> > > issues.
> > > 
> > > Mark Pearson
> > > -
> > > 
> > > Add another panel that needs the edid quirk to the list so that 
> > > brightness 
> > > control works correctly. Fixes issue seen on Lenovo X13 Yoga with OLED 
> > > panel
> > > 
> > > Co-developed-by: jendr...@lenovo.com
> > > Signed-off-by: jendr...@lenovo.com
> > > Signed-off-by: Mark Pearson 
> > > Reviewed-by: Lyude Paul 
> > > ---
> > > drivers/gpu/drm/drm_dp_helper.c | 1 +
> > > 1 file changed, 1 insertion(+)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_dp_helper.c
> > > b/drivers/gpu/drm/drm_dp_helper.c
> > > index c6fbe6e6bc9d..41f0e797ce8c 100644
> > > --- a/drivers/gpu/drm/drm_dp_helper.c
> > > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > > @@ -1313,6 +1313,7 @@ static const struct edid_quirk edid_quirk_list[] = {
> > >{ MFG(0x06, 0xaf), PROD_ID(0xeb, 0x41),
> > > BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
> > >{ MFG(0x4d, 0x10), PROD_ID(0xc7, 0x14),
> > > BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
> > >{ MFG(0x4d, 0x10), PROD_ID(0xe6, 0x14),
> > > BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
> > > + { MFG(0x4c, 0x83), PROD_ID(0x47, 0x41),
> > > BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
> > > };
> > > 
> > >  #undef MFG
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/1] drm: check for NULL pointer in drm_gem_object_put

[Christian König]

Am 20.05.20 um 14:14 schrieb Nirmoy Das:

drm_gem_fb_destroy() calls drm_gem_object_put() with NULL obj causing:
[   11.584209] BUG: kernel NULL pointer dereference, address: 
[   11.584213] #PF: supervisor write access in kernel mode
[   11.584215] #PF: error_code(0x0002) - not-present page
[   11.584216] PGD 0 P4D 0
[   11.584220] Oops: 0002 [#1] SMP NOPTI
[   11.584223] CPU: 7 PID: 1571 Comm: gnome-shell Tainted: GE 
5.7.0-rc1-1-default+ #27
[   11.584225] Hardware name: Micro-Star International Co., Ltd. MS-7A31/X370 
XPOWER GAMING TITANIUM (MS-7A31), BIOS 1.MR 12/03/2019
[   11.584237] RIP: 0010:drm_gem_fb_destroy+0x28/0x70 [drm_kms_helper]

[   11.584256] Call Trace:
[   11.584279]  drm_mode_rmfb+0x189/0x1c0 [drm]
[   11.584299]  ? drm_mode_rmfb+0x1c0/0x1c0 [drm]
[   11.584314]  drm_ioctl_kernel+0xaa/0xf0 [drm]
[   11.584329]  drm_ioctl+0x1ff/0x3b0 [drm]
[   11.584347]  ? drm_mode_rmfb+0x1c0/0x1c0 [drm]
[   11.584421]  amdgpu_drm_ioctl+0x49/0x80 [amdgpu]
[   11.584427]  ksys_ioctl+0x87/0xc0
[   11.584430]  __x64_sys_ioctl+0x16/0x20
[   11.584434]  do_syscall_64+0x5f/0x240
[   11.584438]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[   11.584440] RIP: 0033:0x7f0ef80f7227

Signed-off-by: Nirmoy Das 


Fixes:  missing here. Apart from that Reviewed-by: Christian König 
.


Please resend with the tag added, then I'm going to push this to 
drm-misc-next asap.


Christian.


---
  include/drm/drm_gem.h | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
index 52173abdf500..a13510346a9b 100644
--- a/include/drm/drm_gem.h
+++ b/include/drm/drm_gem.h
@@ -372,6 +372,9 @@ static inline void drm_gem_object_get(struct drm_gem_object 
*obj)
  static inline void
  drm_gem_object_put(struct drm_gem_object *obj)
  {
+   if (!obj)
+   return;
+
kref_put(>refcount, drm_gem_object_free);
  }
  


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/amdgpu: off by on in amdgpu_device_attr_create_groups() error handling

[Christian König]

Am 20.05.20 um 14:00 schrieb Dan Carpenter:

This loop in the error handling code should start a "i - 1" and end at
"i == 0".  Currently it starts a "i" and ends at "i == 1".  The result
is that it removes one attribute that wasn't created yet, and leaks the
zeroeth attribute.

Fixes: 4e01847c38f7 ("drm/amdgpu: optimize amdgpu device attribute code")
Signed-off-by: Dan Carpenter 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 5 ++---
  1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
index b75362bf0742..ee4a8e44fbeb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
@@ -1931,7 +1931,7 @@ static int amdgpu_device_attr_create_groups(struct 
amdgpu_device *adev,
uint32_t mask)
  {
int ret = 0;
-   uint32_t i = 0;
+   int i;
  
  	for (i = 0; i < counts; i++) {

ret = amdgpu_device_attr_create(adev, [i], mask);
@@ -1942,9 +1942,8 @@ static int amdgpu_device_attr_create_groups(struct 
amdgpu_device *adev,
return 0;
  
  failed:

-   for (; i > 0; i--) {
+   while (--i >= 0)


As far as I know the common idiom for this is while (i--) which even 
works without changing the type of i to signed.


Christian.


amdgpu_device_attr_remove(adev, [i]);
-   }
  
  	return ret;

  }


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/amdgpu: off by on in amdgpu_device_attr_create_groups() error handling

[Dan Carpenter]

This loop in the error handling code should start a "i - 1" and end at
"i == 0".  Currently it starts a "i" and ends at "i == 1".  The result
is that it removes one attribute that wasn't created yet, and leaks the
zeroeth attribute.

Fixes: 4e01847c38f7 ("drm/amdgpu: optimize amdgpu device attribute code")
Signed-off-by: Dan Carpenter 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
index b75362bf0742..ee4a8e44fbeb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
@@ -1931,7 +1931,7 @@ static int amdgpu_device_attr_create_groups(struct 
amdgpu_device *adev,
uint32_t mask)
 {
int ret = 0;
-   uint32_t i = 0;
+   int i;
 
for (i = 0; i < counts; i++) {
ret = amdgpu_device_attr_create(adev, [i], mask);
@@ -1942,9 +1942,8 @@ static int amdgpu_device_attr_create_groups(struct 
amdgpu_device *adev,
return 0;
 
 failed:
-   for (; i > 0; i--) {
+   while (--i >= 0)
amdgpu_device_attr_remove(adev, [i]);
-   }
 
return ret;
 }
-- 
2.26.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: Replace deprecated function in drm_crtc_helper

[Sidong Yang]

Replace deprecated function drm_modeset_lock/unlock_all with
helper function DRM_MODESET_LOCK_ALL_BEGIN/END.

Signed-off-by: Sidong Yang 
---
 drivers/gpu/drm/drm_crtc_helper.c | 19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index a4d36aca45ea..c7379c719952 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -217,11 +217,14 @@ static void __drm_helper_disable_unused_functions(struct 
drm_device *dev)
  */
 void drm_helper_disable_unused_functions(struct drm_device *dev)
 {
+   struct drm_modeset_acquire_ctx ctx;
+   int ret;
+
WARN_ON(drm_drv_uses_atomic_modeset(dev));
 
-   drm_modeset_lock_all(dev);
+   DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, DRM_MODESET_ACQUIRE_INTERRUPTIBLE, 
ret);
__drm_helper_disable_unused_functions(dev);
-   drm_modeset_unlock_all(dev);
+   DRM_MODESET_LOCK_ALL_END(ctx, ret);
 }
 EXPORT_SYMBOL(drm_helper_disable_unused_functions);
 
@@ -938,13 +941,14 @@ void drm_helper_resume_force_mode(struct drm_device *dev)
 {
struct drm_crtc *crtc;
struct drm_encoder *encoder;
+   struct drm_modeset_acquire_ctx ctx;
const struct drm_crtc_helper_funcs *crtc_funcs;
int encoder_dpms;
-   bool ret;
+   int ret;
 
WARN_ON(drm_drv_uses_atomic_modeset(dev));
 
-   drm_modeset_lock_all(dev);
+   DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, DRM_MODESET_ACQUIRE_INTERRUPTIBLE, 
ret);
drm_for_each_crtc(crtc, dev) {
 
if (!crtc->enabled)
@@ -979,7 +983,7 @@ void drm_helper_resume_force_mode(struct drm_device *dev)
 
/* disable the unused connectors while restoring the modesetting */
__drm_helper_disable_unused_functions(dev);
-   drm_modeset_unlock_all(dev);
+   DRM_MODESET_LOCK_ALL_END(ctx, ret);
 }
 EXPORT_SYMBOL(drm_helper_resume_force_mode);
 
@@ -999,9 +1003,10 @@ EXPORT_SYMBOL(drm_helper_resume_force_mode);
 int drm_helper_force_disable_all(struct drm_device *dev)
 {
struct drm_crtc *crtc;
+   struct drm_modeset_acquire_ctx ctx;
int ret = 0;
 
-   drm_modeset_lock_all(dev);
+   DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, DRM_MODESET_ACQUIRE_INTERRUPTIBLE, 
ret);
drm_for_each_crtc(crtc, dev)
if (crtc->enabled) {
struct drm_mode_set set = {
@@ -1013,7 +1018,7 @@ int drm_helper_force_disable_all(struct drm_device *dev)
goto out;
}
 out:
-   drm_modeset_unlock_all(dev);
+   DRM_MODESET_LOCK_ALL_END(ctx, ret);
return ret;
 }
 EXPORT_SYMBOL(drm_helper_force_disable_all);
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [EXTERNAL] Re: [RFC PATCH 0/4] DirectX on Linux

[Steve Pronovost]

Hey guys,

Thanks for the discussion. I may not be able to immediately answer all of your 
questions, but I'll do my best .

drivers/hyperv sounds like it could be a better location. We weren't too sure 
where to put this, we though /drivers/gpu would be appropriate given this deal 
with GPUs, but I get your point... this is a vGPU driver that really only works 
when being run under Hyper-V, so drivers/hyperv is likely more appropriate.

In term of presentation, I need to clarify a few things. We announced today 
that we're also adding support for Linux GUI applications. The way this will 
work is roughly as follow. We're writing a Wayland compositor that will 
essentially bridge over RDP-RAIL (RAIL=Remote Application Integrated Locally). 
We're starting from a Weston base. Weston already has an RDP Backend, but 
that's for a full desktop remoting scheme. Weston draws a desktop and remote it 
over RDP... and then you can peek at that desktop using an rdp client on the 
Windows side. RAIL works differently. In that case our wayland compositor no 
longer paint a desktop... instead it simply forward individual visual / 
wl_surface over the RDP RAIL channel such that these visual can be displayed on 
the Windows desktop. The RDP client create proxy window for each of these top 
level visual and their content is filled with the data coming over the RDP 
channel. All pixels are owned by the RDP server/WSL... so these windows looks 
different than native window are they are painted and themed by WSL. The proxy 
window on the host gather input and inject back over RDP... This is essentially 
how application remoting works on windows and this is all publicly documented 
as part of the various RDP protocol specification. As a matter of fact, for the 
RDP server on the Weston side we are looking at continue to leverage FreeRDP 
(and provide fixes/enhancement as needed to the public project). Further, we're 
looking at further improvement down this path to avoid having to copy the 
content over the RAIL channel and instead just share/swap buffer between the 
guest and the host. We have extension to the RDP protocol, called VAIL 
(Virtualized Application Integrated Locally) which does that today. Today this 
is only use in Windows on Windows for very specific scenario. We're looking at 
extending the public RDP protocol with these VAIL extension to make this an 
official Microsoft supported protocol which would allow us to target this in 
WSL. We have finished designing this part in details. Our goal would be to 
leverage something along the line of wl_drm, dma-buf, dma-fence, etc... This 
compositor and all our contribution to FreeRDP will be fully open source, 
including our design doc. We're not quite sure yet whether this will be offered 
as a separate project entirely distinct from it's Weston root... or if we'll 
propose an extension to Weston to operate in this mode. We would like to build 
it such that in theory any Wayland compositor could add support for this mode 
of operation if they want to remote application to a Windows host (over the 
network, or on the same box).

We see /dev/dxg really as a projection of the GPU when running in WSL such that 
the GPU can be shared between WSL and the host... not something that would 
coexist "at the same time" with a real DRM GPU.

We have consider the possibility of bringing DX to Linux with no Windows cord 
attached. I'm not ready to discuss this at this time ... but in the 
hypothetical that we were do this, DX would be running on top of DRI/DRM on 
native Linux. We likely would be contributing some changes to DRM to address 
area of divergence and get better mapping for our user mode driver, but we 
wouldn't try to shoehorn /dev/dxg into the picture. In that hypothetical world, 
we would essentially have DX target DRM on native Linux and DX continue to 
target DXG in WSL to share the GPU with the host. I think this further 
reinforce the point you guys were making that the right place for our current 
dxgkrnl driver to live in would be /drivers/hyperv/dxgkrnl. In insight, I 
totally agree .

I think this cover all questions, let me know if I missed anything.

Thanks,
Steve

-Original Message-
From: Daniel Vetter  
Sent: Tuesday, May 19, 2020 4:01 PM
To: Dave Airlie 
Cc: Sasha Levin ; linux-hyp...@vger.kernel.org; Stephen 
Hemminger ; Ursulin, Tvrtko ; 
Greg Kroah-Hartman ; Haiyang Zhang 
; LKML ; dri-devel 
; Chris Wilson ; 
Steve Pronovost ; Linux Fbdev development list 
; Iouri Tarassov ; Deucher, 
Alexander ; KY Srinivasan ; Wei 
Liu ; Hawking Zhang 
Subject: [EXTERNAL] Re: [RFC PATCH 0/4] DirectX on Linux

On Wed, May 20, 2020 at 12:42 AM Dave Airlie  wrote:
>
> On Wed, 20 May 2020 at 02:33, Sasha Levin  wrote:
> >
> > There is a blog post that goes into more detail about the bigger 
> > picture, and walks through all the required pieces to make this 
> > work. It is available here:
> > 

Re: [PATCH] drm/doc: device hot-unplug for userspace

[Pekka Paalanen]

On Tue, 19 May 2020 10:37:12 -0400
Andrey Grodzovsky  wrote:

> Thanks for the summary, does put things in order and makes it easier to 
> comprehend all the TODOs, some questions bellow
> 
> On 5/19/20 6:06 AM, Pekka Paalanen wrote:
> > From: Pekka Paalanen 
> >
> > Set up the expectations on how hot-unplugging a DRM device should look like 
> > to
> > userspace.
> >
> > Written by Daniel Vetter's request and largely based on his comments in IRC 
> > and
> > from 
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Farchives%2Fdri-devel%2F2020-May%2F265484.htmldata=02%7C01%7Candrey.grodzovsky%40amd.com%7Ce8e13dc4c85648e5fcd408d7fbdc5f2b%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637254796242596783sdata=bA%2FAy3VGvzNqmV1kGigNROSZQEws2E98JibDxvEICNs%3Dreserved=0
> >  .
> >
> > Signed-off-by: Pekka Paalanen 
> > Cc: Daniel Vetter 
> > Cc: Andrey Grodzovsky 
> > Cc: Dave Airlie 
> > Cc: Sean Paul 
> >
> > ---
> >
> > Disclaimer: I am a userspace developer writing for other userspace 
> > developers.
> > I took some liberties in defining what should happen without knowing what is
> > actually possible or what existing drivers already implement.
> > ---
> >   Documentation/gpu/drm-uapi.rst | 75 ++
> >   1 file changed, 75 insertions(+)
> >
> > diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
> > index 56fec6ed1ad8..80db4abd2cbd 100644
> > --- a/Documentation/gpu/drm-uapi.rst
> > +++ b/Documentation/gpu/drm-uapi.rst
> > @@ -1,3 +1,5 @@
> > +.. Copyright 2020 DisplayLink (UK) Ltd.
> > +
> >   ===
> >   Userland interfaces
> >   ===
> > @@ -162,6 +164,79 @@ other hand, a driver requires shared state between 
> > clients which is
> >   visible to user-space and accessible beyond open-file boundaries, they
> >   cannot support render nodes.
> >   
> > +Device Hot-Unplug
> > +=
> > +
> > +.. note::
> > +   The following is the plan. Implementation is not there yet
> > +   (2020 May 13).
> > +
> > +Graphics devices (display and/or render) may be connected via USB (e.g.
> > +display adapters or docking stations) or Thunderbolt (e.g. eGPU). An end
> > +user is able to hot-unplug this kind of devices while they are being
> > +used, and expects that the very least the machine does not crash. Any
> > +damage from hot-unplugging a DRM device needs to be limited as much as
> > +possible and userspace must be given the chance to handle it if it wants
> > +to. Ideally, unplugging a DRM device still lets a desktop to continue
> > +running, but that is going to need explicit support throughout the whole
> > +graphics stack: from kernel and userspace drivers, through display
> > +servers, via window system protocols, and in applications and libraries.
> > +
> > +Other scenarios that should lead to the same are: unrecoverable GPU
> > +crash, PCI device disappearing off the bus, or forced unbind of a driver
> > +from the physical device.
> > +
> > +In other words, from userspace perspective everything needs to keep on
> > +working more or less, until userspace stops using the disappeared DRM
> > +device and closes it completely. Userspace will learn of the device
> > +disappearance from the device removed uevent or in some cases specific
> > +ioctls returning EIO.
> > +
> > +This goal raises at least the following requirements for the kernel and
> > +drivers:
> > +
> > +- The kernel must not hang, crash or oops, no matter what userspace was
> > +  in the middle of doing when the device disappeared.
> > +
> > +- All GPU jobs that can no longer run must have their fences
> > +  force-signalled to avoid inflicting hangs to userspace.
> > +
> > +- KMS connectors must change their status to disconnected.
> > +
> > +- Legacy modesets and pageflips fake success.
> > +
> > +- Atomic commits, both real and TEST_ONLY, fake success.  
> 
> 
> Why wouldn't we return -EIO for the atommic commit IOTCL/legasy pflip 
> and modeset ioctls here same way as you suggested returning -EIO for 
> render ioctl ?

Hi,

that is more of a question for Daniel Vetter than me. I believe he is
worried that userspace will get the error handling horribly wrong
anyway, because it needs to be handled in every single display server
project. Render ioctl errors OTOH need to be handled only in the
corresponding Mesa or other userspace driver, and for render there are
API (OpenGL/EGL, Vulkan) specs that say how it must be handled to fill
the API contract. Because of the API contract, those are more likely to
have reasonable error handling in place already.

I first thought it would be obvious for at least atomic commits to fail
appropriately, but then thinking again, it will only introduce new
failures that are currently very hard to test for (VKMS to the rescue),
and userspace would need to have code to correctly bail out for EIO
rather than attempt fallbacks. The uevent telling the device is gone is
going to come 

[PATCH] drm/exynos: Fix dma_parms allocation

[Marek Szyprowski]

Since commit 9495b7e92f71 ("driver core: platform: Initialize dma_parms
for platform devices") driver core handles allocation of the dma_parms
structure for platform device, so there is no need to manually allocate
nor free it.

Reported-by: Tomi Valkeinen 
Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/exynos/exynos_drm_dma.c | 27 +--
 1 file changed, 1 insertion(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dma.c 
b/drivers/gpu/drm/exynos/exynos_drm_dma.c
index 619f814..3d59800 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dma.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dma.c
@@ -31,23 +31,6 @@
 #define EXYNOS_DEV_ADDR_START  0x2000
 #define EXYNOS_DEV_ADDR_SIZE   0x4000
 
-static inline int configure_dma_max_seg_size(struct device *dev)
-{
-   if (!dev->dma_parms)
-   dev->dma_parms = kzalloc(sizeof(*dev->dma_parms), GFP_KERNEL);
-   if (!dev->dma_parms)
-   return -ENOMEM;
-
-   dma_set_max_seg_size(dev, DMA_BIT_MASK(32));
-   return 0;
-}
-
-static inline void clear_dma_max_seg_size(struct device *dev)
-{
-   kfree(dev->dma_parms);
-   dev->dma_parms = NULL;
-}
-
 /*
  * drm_iommu_attach_device- attach device to iommu mapping
  *
@@ -69,10 +52,7 @@ static int drm_iommu_attach_device(struct drm_device 
*drm_dev,
return -EINVAL;
}
 
-   ret = configure_dma_max_seg_size(subdrv_dev);
-   if (ret)
-   return ret;
-
+   dma_set_max_seg_size(subdrv_dev, DMA_BIT_MASK(32));
if (IS_ENABLED(CONFIG_ARM_DMA_USE_IOMMU)) {
/*
 * Keep the original DMA mapping of the sub-device and
@@ -89,9 +69,6 @@ static int drm_iommu_attach_device(struct drm_device *drm_dev,
ret = iommu_attach_device(priv->mapping, subdrv_dev);
}
 
-   if (ret)
-   clear_dma_max_seg_size(subdrv_dev);
-
return 0;
 }
 
@@ -114,8 +91,6 @@ static void drm_iommu_detach_device(struct drm_device 
*drm_dev,
arm_iommu_attach_device(subdrv_dev, *dma_priv);
} else if (IS_ENABLED(CONFIG_IOMMU_DMA))
iommu_detach_device(priv->mapping, subdrv_dev);
-
-   clear_dma_max_seg_size(subdrv_dev);
 }
 
 int exynos_drm_register_dma(struct drm_device *drm, struct device *dev,
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [EXTERNAL] Re: [RFC PATCH 0/4] DirectX on Linux

[Thomas Zimmermann]

Hi Steve,

thank you for the fast reply.

Am 20.05.20 um 09:42 schrieb Steve Pronovost:
>> Echoing what others said, you're not making a DRM driver. The driver should 
>> live outside of the DRM code.
> 
> Agreed, please see my earlier reply. We'll be moving the driver to 
> drivers/hyperv node or something similar. Apology for the confusion here.
> 
>> I have one question about the driver API: on Windows, DirectX versions are 
>> loosly tied to Windows releases. So I guess you can change the kernel 
>> interface among DirectX versions?
>> If so, how would this work on Linux in the long term? If there ever is a 
>> DirectX 13 or 14 with incompatible kernel interfaces, how would you plan to 
>> update the Linux driver?
> 
> You should think of the communication over the VM Bus for the vGPU projection 
> as a strongly versioned interface. We will be keeping compatibility with 
> older version of that interface as it evolves over time so we can continue to 
> run older guest (we already do). This protocol isn't actually tied to the DX 
> API. It is a generic abstraction for the GPU that can be used for any APIs 
> (for example the NVIDIA CUDA driver that we announced is going over the same 
> protocol to access the GPU). 
> 
> New version of user mode DX can either take advantage or sometime require new 
> services from this kernel abstraction. This mean that pulling a new version 
> of user mode DX can mean having to also pull a new version of this vGPU 
> kernel driver. For WSL, these essentially ships together. The kernel driver 
> ships as part of our WSL2 Linux Kernel integration. User mode DX bits ships 
> with Windows. 

Just a friendly advise: maintaining a proprietary component within a
Linux environment is tough. You will need a good plan for long-term
interface stability and compatibility with the other components.

Best regards
Thomas

> 
> -Original Message-
> From: Thomas Zimmermann  
> Sent: Wednesday, May 20, 2020 12:11 AM
> To: Sasha Levin ; alexander.deuc...@amd.com; 
> ch...@chris-wilson.co.uk; ville.syrj...@linux.intel.com; 
> hawking.zh...@amd.com; tvrtko.ursu...@intel.com
> Cc: linux-ker...@vger.kernel.org; linux-hyp...@vger.kernel.org; KY Srinivasan 
> ; Haiyang Zhang ; Stephen 
> Hemminger ; wei@kernel.org; Steve Pronovost 
> ; Iouri Tarassov ; 
> dri-devel@lists.freedesktop.org; linux-fb...@vger.kernel.org; 
> gre...@linuxfoundation.org
> Subject: [EXTERNAL] Re: [RFC PATCH 0/4] DirectX on Linux
> 
> Hi
> 
> Am 19.05.20 um 18:32 schrieb Sasha Levin:
>> There is a blog post that goes into more detail about the bigger 
>> picture, and walks through all the required pieces to make this work. 
>> It is available here:
>> https://devblogs.microsoft.com/directx/directx-heart-linux . The rest 
>> of this cover letter will focus on the Linux Kernel bits.
> 
> That's quite a surprise. Thanks for your efforts to contribute.
> 
>>
>> Overview
>> 
>>
>> This is the first draft of the Microsoft Virtual GPU (vGPU) driver. 
>> The driver exposes a paravirtualized GPU to user mode applications 
>> running in a virtual machine on a Windows host. This enables hardware 
>> acceleration in environment such as WSL (Windows Subsystem for Linux) 
>> where the Linux virtual machine is able to share the GPU with the 
>> Windows host.
>>
>> The projection is accomplished by exposing the WDDM (Windows Display 
>> Driver Model) interface as a set of IOCTL. This allows APIs and user 
>> mode driver written against the WDDM GPU abstraction on Windows to be 
>> ported to run within a Linux environment. This enables the port of the
>> D3D12 and DirectML APIs as well as their associated user mode driver 
>> to Linux. This also enables third party APIs, such as the popular 
>> NVIDIA Cuda compute API, to be hardware accelerated within a WSL environment.
>>
>> Only the rendering/compute aspect of the GPU are projected to the 
>> virtual machine, no display functionality is exposed. Further, at this 
>> time there are no presentation integration. So although the D3D12 API 
>> can be use to render graphics offscreen, there is no path (yet) for 
>> pixel to flow from the Linux environment back onto the Windows host 
>> desktop. This GPU stack is effectively side-by-side with the native 
>> Linux graphics stack.
>>
>> The driver creates the /dev/dxg device, which can be opened by user 
>> mode application and handles their ioctls. The IOCTL interface to the 
>> driver is defined in dxgkmthk.h (Dxgkrnl Graphics Port Driver ioctl 
>> definitions). The interface matches the D3DKMT interface on Windows.
>> Ioctls are implemented in ioctl.c.
> 
> Echoing what others said, you're not making a DRM driver. The driver should 
> live outside of the DRM code.
> 
> I have one question about the driver API: on Windows, DirectX versions are 
> loosly tied to Windows releases. So I guess you can change the kernel 
> interface among DirectX versions?
> 
> If so, how would this work on Linux in the long term? If there 

Re: [PATCH v2 0/16] backlight updates

[Emil Velikov]

Hi Sam,

It's a little weird to see this series, just after I mentioned that I
had one in the works.
Either way, patches 2 and 16 need some work. Although if you prefer
that can be done as follow-up.

For the rest:
Reviewed-by: Emil Velikov 

-Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] dma-fence: add might_sleep annotation to _wait()

[Daniel Vetter]

On Wed, May 20, 2020 at 08:54:36AM +0200, Christian König wrote:
> Am 19.05.20 um 15:27 schrieb Daniel Vetter:
> > Do it uncontionally, there's a separate peek function with
> > dma_fence_is_signalled() which can be called from atomic context.
> > 
> > v2: Consensus calls for an unconditional might_sleep (Chris,
> > Christian)
> > 
> > Full audit:
> > - dma-fence.h: Uses MAX_SCHEDULE_TIMOUT, good chance this sleeps
> > - dma-resv.c: Timeout always at least 1
> > - st-dma-fence.c: Save to sleep in testcases
> > - amdgpu_cs.c: Both callers are for variants of the wait ioctl
> > - amdgpu_device.c: Two callers in vram recover code, both right next
> >to mutex_lock.
> > - amdgpu_vm.c: Use in the vm_wait ioctl, next to _reserve/unreserve
> > - remaining functions in amdgpu: All for test_ib implementations for
> >various engines, caller for that looks all safe (debugfs, driver
> >load, reset)
> > - etnaviv: another wait ioctl
> > - habanalabs: another wait ioctl
> > - nouveau_fence.c: hardcoded 15*HZ ... glorious
> > - nouveau_gem.c: hardcoded 2*HZ ... so not even super consistent, but
> >this one does have a WARN_ON :-/ At least this one is only a
> >fallback path for when kmalloc fails. Maybe this should be put onto
> >some worker list instead, instead of a work per unamp ...
> > - i915/selftests: Hardecoded HZ / 4 or HZ / 8
> > - i915/gt/selftests: Going up the callchain looks safe looking at
> >nearby callers
> > - i915/gt/intel_gt_requests.c. Wrapped in a mutex_lock
> > - i915/gem_i915_gem_wait.c: The i915-version which is called instead
> >for i915 fences already has a might_sleep() annotation, so all good
> > 
> > Cc: Alex Deucher 
> > Cc: Lucas Stach 
> > Cc: Jani Nikula 
> > Cc: Joonas Lahtinen 
> > Cc: Rodrigo Vivi 
> > Cc: Ben Skeggs 
> > Cc: "VMware Graphics" 
> > Cc: Oded Gabbay 
> > Cc: linux-me...@vger.kernel.org
> > Cc: linaro-mm-...@lists.linaro.org
> > Cc: linux-r...@vger.kernel.org
> > Cc: amd-...@lists.freedesktop.org
> > Cc: intel-...@lists.freedesktop.org
> > Cc: Chris Wilson 
> > Cc: Maarten Lankhorst 
> > Cc: Christian König 
> > Signed-off-by: Daniel Vetter 
> 
> Reviewed-by: Christian König 

intel-gfx-ci approves too, thanks to both of you for reviews, patch merged
to drm-misc-next.
-Daniel

> 
> > ---
> >   drivers/dma-buf/dma-fence.c | 2 ++
> >   1 file changed, 2 insertions(+)
> > 
> > diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> > index 90edf2b281b0..656e9ac2d028 100644
> > --- a/drivers/dma-buf/dma-fence.c
> > +++ b/drivers/dma-buf/dma-fence.c
> > @@ -208,6 +208,8 @@ dma_fence_wait_timeout(struct dma_fence *fence, bool 
> > intr, signed long timeout)
> > if (WARN_ON(timeout < 0))
> > return -EINVAL;
> > +   might_sleep();
> > +
> > trace_dma_fence_wait_start(fence);
> > if (fence->ops->wait)
> > ret = fence->ops->wait(fence, intr, timeout);
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 16/16] backlight: use backlight_is_blank() in all backlight drivers

[Emil Velikov]

Hi Sam,

On Sun, 17 May 2020 at 20:02, Sam Ravnborg  wrote:

> --- a/drivers/video/backlight/88pm860x_bl.c
> +++ b/drivers/video/backlight/88pm860x_bl.c
> @@ -123,13 +123,7 @@ static int pm860x_backlight_update_status(struct 
> backlight_device *bl)
>  {
> int brightness = bl->props.brightness;
>
> -   if (bl->props.power != FB_BLANK_UNBLANK)
> -   brightness = 0;
> -
> -   if (bl->props.fb_blank != FB_BLANK_UNBLANK)
> -   brightness = 0;
> -
> -   if (bl->props.state & BL_CORE_SUSPENDED)
> +   if (backlight_is_blank(bl))
> brightness = 0;
Off the top of my head, the above two lines should really be in backlight core.
There's nothing driver specific to them, plus it minimises the chances
of next-driver getting it wrong.


> --- a/drivers/video/backlight/as3711_bl.c
> +++ b/drivers/video/backlight/as3711_bl.c
> @@ -107,13 +107,11 @@ static int as3711_bl_update_status(struct 
> backlight_device *bl)
> int brightness = bl->props.brightness;
> int ret = 0;
>
> -   dev_dbg(>dev, "%s(): brightness %u, pwr %x, blank %x, state %x\n",
> +   dev_dbg(>dev, "%s(): brightness %u, pwr %x, state %x\n",
> __func__, bl->props.brightness, bl->props.power,
> -   bl->props.fb_blank, bl->props.state);
> +   bl->props.state);
>
Let's also move this to backlight core.

-Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v1 13/25] dma-buf: Use sequence counter with associated wound/wait mutex

[Christian König]

Am 19.05.20 um 23:45 schrieb Ahmed S. Darwish:

A sequence counter write side critical section must be protected by some
form of locking to serialize writers. If the serialization primitive is
not disabling preemption implicitly, preemption has to be explicitly
disabled before entering the sequence counter write side critical
section.

The dma-buf reservation subsystem uses plain sequence counters to manage
updates to reservations. Writer serialization is accomplished through a
wound/wait mutex.

Acquiring a wound/wait mutex does not disable preemption, so this needs
to be done manually before and after the write side critical section.

Use the newly-added seqcount_ww_mutex_t instead:

   - It associates the ww_mutex with the sequence count, which enables
 lockdep to validate that the write side critical section is properly
 serialized.

   - It removes the need to explicitly add preempt_disable/enable()
 around the write side critical section because the write_begin/end()
 functions for this new data type automatically do this.

If lockdep is disabled this ww_mutex lock association is compiled out
and has neither storage size nor runtime overhead.


Mhm, is the dma_resv object the only user of this new seqcount_ww_mutex 
variant ?


If yes we are trying to get rid of this sequence counter for quite some 
time, so I would rather invest the additional time to finish this.


Regards,
Christian.



Signed-off-by: Ahmed S. Darwish 
---
  drivers/dma-buf/dma-resv.c   | 8 +---
  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 2 --
  include/linux/dma-resv.h | 2 +-
  3 files changed, 2 insertions(+), 10 deletions(-)

diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
index 590ce7ad60a0..3aba2b2bfc48 100644
--- a/drivers/dma-buf/dma-resv.c
+++ b/drivers/dma-buf/dma-resv.c
@@ -128,7 +128,7 @@ subsys_initcall(dma_resv_lockdep);
  void dma_resv_init(struct dma_resv *obj)
  {
ww_mutex_init(>lock, _ww_class);
-   seqcount_init(>seq);
+   seqcount_ww_mutex_init(>seq, >lock);
  
  	RCU_INIT_POINTER(obj->fence, NULL);

RCU_INIT_POINTER(obj->fence_excl, NULL);
@@ -259,7 +259,6 @@ void dma_resv_add_shared_fence(struct dma_resv *obj, struct 
dma_fence *fence)
fobj = dma_resv_get_list(obj);
count = fobj->shared_count;
  
-	preempt_disable();

write_seqcount_begin(>seq);
  
  	for (i = 0; i < count; ++i) {

@@ -281,7 +280,6 @@ void dma_resv_add_shared_fence(struct dma_resv *obj, struct 
dma_fence *fence)
smp_store_mb(fobj->shared_count, count);
  
  	write_seqcount_end(>seq);

-   preempt_enable();
dma_fence_put(old);
  }
  EXPORT_SYMBOL(dma_resv_add_shared_fence);
@@ -308,14 +306,12 @@ void dma_resv_add_excl_fence(struct dma_resv *obj, struct 
dma_fence *fence)
if (fence)
dma_fence_get(fence);
  
-	preempt_disable();

write_seqcount_begin(>seq);
/* write_seqcount_begin provides the necessary memory barrier */
RCU_INIT_POINTER(obj->fence_excl, fence);
if (old)
old->shared_count = 0;
write_seqcount_end(>seq);
-   preempt_enable();
  
  	/* inplace update, no shared fences */

while (i--)
@@ -393,13 +389,11 @@ int dma_resv_copy_fences(struct dma_resv *dst, struct 
dma_resv *src)
src_list = dma_resv_get_list(dst);
old = dma_resv_get_excl(dst);
  
-	preempt_disable();

write_seqcount_begin(>seq);
/* write_seqcount_begin provides the necessary memory barrier */
RCU_INIT_POINTER(dst->fence_excl, new);
RCU_INIT_POINTER(dst->fence, dst_list);
write_seqcount_end(>seq);
-   preempt_enable();
  
  	dma_resv_list_free(src_list);

dma_fence_put(old);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 9dff792c9290..87fd32aae8f9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -258,11 +258,9 @@ static int amdgpu_amdkfd_remove_eviction_fence(struct 
amdgpu_bo *bo,
new->shared_count = k;
  
  	/* Install the new fence list, seqcount provides the barriers */

-   preempt_disable();
write_seqcount_begin(>seq);
RCU_INIT_POINTER(resv->fence, new);
write_seqcount_end(>seq);
-   preempt_enable();
  
  	/* Drop the references to the removed fences or move them to ef_list */

for (i = j, k = 0; i < old->shared_count; ++i) {
diff --git a/include/linux/dma-resv.h b/include/linux/dma-resv.h
index a6538ae7d93f..d44a77e8a7e3 100644
--- a/include/linux/dma-resv.h
+++ b/include/linux/dma-resv.h
@@ -69,7 +69,7 @@ struct dma_resv_list {
   */
  struct dma_resv {
struct ww_mutex lock;
-   seqcount_t seq;
+   seqcount_ww_mutex_t seq;
  
  	struct dma_fence __rcu *fence_excl;

struct dma_resv_list __rcu *fence;

Re: [PATCH v2 03/16] backlight: add backlight_is_blank()

[Emil Velikov]

On Sun, 17 May 2020 at 20:02, Sam Ravnborg  wrote:
>
> The backlight support has two properties that express the state:
> - power
> - state
>
> It is un-documented and easy to get wrong.
> Add backlight_is_blank() helper to make it simpler for drivers
> to get the check of the state correct.
>
> A lot of drivers also includes checks for fb_blank.
> This check is redundant when the state is checked
> and thus not needed in this helper function.
> But added anyway to avoid introducing subtle bug
> due to the creative use in some drivers.
>
> Rolling out this helper to all relevant backlight drivers
> will eliminate almost all accesses to fb_blank.
>
Nit: please tweak your editor to wrap commit messages at 72 columns.

> v2:
>   - Added fb_blank condition (Daniel)
>
I was going to mention this, but Daniel beat me to it.

Please add an extra NOTE in the commit message. The fb_blank is a
behaviour change, albeit in the right direction.

-Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 02/16] backlight: refactor fb_notifier_callback()

[Emil Velikov]

Hi Sam,

On Sun, 17 May 2020 at 20:02, Sam Ravnborg  wrote:
>
> Increase readability of fb_notifier_callback() by removing
> a few indent levels.
> No functional change.
>
> Signed-off-by: Sam Ravnborg 
> Cc: Lee Jones 
> Cc: Daniel Thompson 
> Cc: Jingoo Han 
> ---
>  drivers/video/backlight/backlight.c | 43 +++--
>  1 file changed, 22 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/video/backlight/backlight.c 
> b/drivers/video/backlight/backlight.c
> index cac3e35d7630..17f04cff50ab 100644
> --- a/drivers/video/backlight/backlight.c
> +++ b/drivers/video/backlight/backlight.c
> @@ -58,28 +58,29 @@ static int fb_notifier_callback(struct notifier_block 
> *self,
>
> bd = container_of(self, struct backlight_device, fb_notif);
> mutex_lock(>ops_lock);
> -   if (bd->ops)
> -   if (!bd->ops->check_fb ||
> -   bd->ops->check_fb(bd, evdata->info)) {
> -   fb_blank = *(int *)evdata->data;
> -   if (fb_blank == FB_BLANK_UNBLANK &&
> -   !bd->fb_bl_on[node]) {
> -   bd->fb_bl_on[node] = true;
> -   if (!bd->use_count++) {
> -   bd->props.state &= ~BL_CORE_FBBLANK;
> -   bd->props.fb_blank = FB_BLANK_UNBLANK;
> -   backlight_update_status(bd);
> -   }
> -   } else if (fb_blank != FB_BLANK_UNBLANK &&
> -  bd->fb_bl_on[node]) {
> -   bd->fb_bl_on[node] = false;
> -   if (!(--bd->use_count)) {
> -   bd->props.state |= BL_CORE_FBBLANK;
> -   bd->props.fb_blank = fb_blank;
> -   backlight_update_status(bd);
> -   }
> -   }
> +
> +   if (!bd->ops)
> +   goto out;
> +   if (bd->ops->check_fb && !bd->ops->check_fb(bd, evdata->info))
Mildly related: Would be a nice to define which ops are mandatory and
which aren't.
That plus enforcement in backlight_device_register.

But that's for another patchset.

> +   goto out;
> +
> +   fb_blank = *(int *)evdata->data;
> +   if (fb_blank == FB_BLANK_UNBLANK && !bd->fb_bl_on[node]) {
> +   bd->fb_bl_on[node] = true;
> +   if (!bd->use_count++) {
> +   bd->props.state &= ~BL_CORE_FBBLANK;
> +   bd->props.fb_blank = FB_BLANK_UNBLANK;
> +   backlight_update_status(bd);
> +   }
> +   } else if (fb_blank != FB_BLANK_UNBLANK && bd->fb_bl_on[node]) {
> +   bd->fb_bl_on[node] = false;
> +   if (!(--bd->use_count)) {
> +   bd->props.state |= BL_CORE_FBBLANK;
> +   bd->props.fb_blank = fb_blank;
> +   backlight_update_status(bd);
> }
Something like the following reads better, plus one could simplify it
with follow-on patch.

if (fb_blank == FB_BLANK_UNBLANK)
if (!bd->fb_bl_on[node] && !bd->use_count++) {
bd->props.state &= ~BL_CORE_FBBLANK;
bd->props.fb_blank = FB_BLANK_UNBLANK;
backlight_update_status(bd);
// above is backlight_enable()
}
bd->fb_bl_on[node] = true;
} else {
if (bd->fb_bl_on[node] && !(--bd->use_count)) {
bd->props.state |= BL_CORE_FBBLANK;
bd->props.fb_blank = fb_blank;
backlight_update_status(bd);
// above is backlight_disable()
   }
bd->fb_bl_on[node] = false;
}

As-is, one cannot use the backlight helpers indicated, since it
touches .power. First one should ensure the drivers honour .power - by
using the helper introduced later.

-Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm] libdrm: enclose __FreeBSD__ behind a define

[Emmanuel Vadot]

On Tue, 19 May 2020 12:04:58 -0700
Carlos Santa  wrote:

> Not doing the above can cause compilation errors on
> platforms that don't define it.
> 
> [1/25] Compiling C object 'drm@sha/xf86drm.c.o.
> FAILED: drm@sha/xf86drm.c.o
> ../xf86drm.c: In function 'drmGetMinorNameForFD':
> ../xf86drm.c:2938:7: error: "__FreeBSD__" is not defined [-Werror=undef]
>  #elif __FreeBSD__
>^
> ../xf86drm.c: In function 'drmParsePciBusInfo':
> ../xf86drm.c:3258:7 error: "__FreeBSD__" is not defined [-Werror=undef]
>  #elif __FreeBSD__
>^
> ../x86drm.c: In function 'drmParsePciDeviceInfo':
> ../x86drm.c:3427:7 error: "__FreeBSD__" is not defined [-Werror=undef]
>  #elif __FreeBSD__
> 
> ../x86drm.c: In function 'drmGetDeviceNameFromFd2':
> ../xf86drm.c:4305:7 error: "__FreeBSD__" is not defined [-Werror=undef]
>  #elif __FreeBSD__
>^
> cc1: some warnigns being treated as errors
> ninja: build stopped: subcommand failed.
> 
> Signed-off-by: Carlos Santa 
> ---
>  xf86drm.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/xf86drm.c b/xf86drm.c
> index b49d42f70dbe..3965b4be366d 100644
> --- a/xf86drm.c
> +++ b/xf86drm.c
> @@ -2822,7 +2822,7 @@ static bool drmNodeIsDRM(int maj, int min)
>  snprintf(path, sizeof(path), "/sys/dev/char/%d:%d/device/drm",
>   maj, min);
>  return stat(path, ) == 0;
> -#elif __FreeBSD__
> +#elif defined(__FreeBSD__)
>  char name[SPECNAMELEN];
>  
>  if (!devname_r(makedev(maj, min), S_IFCHR, name, sizeof(name)))
> @@ -2935,7 +2935,7 @@ static char *drmGetMinorNameForFD(int fd, int type)
>  
>  closedir(sysdir);
>  return NULL;
> -#elif __FreeBSD__
> +#elif defined(__FreeBSD__)
>  struct stat sbuf;
>  char dname[SPECNAMELEN];
>  const char *mname;
> @@ -3255,7 +3255,7 @@ static int drmParsePciBusInfo(int maj, int min, 
> drmPciBusInfoPtr info)
>  info->func = pinfo.func;
>  
>  return 0;
> -#elif __FreeBSD__
> +#elif defined(__FreeBSD__)
>  return get_sysctl_pci_bus_info(maj, min, info);
>  #else
>  #warning "Missing implementation of drmParsePciBusInfo"
> @@ -3424,7 +3424,7 @@ static int drmParsePciDeviceInfo(int maj, int min,
>  device->subdevice_id = pinfo.subdevice_id;
>  
>  return 0;
> -#elif __FreeBSD__
> +#elif defined(__FreeBSD__)
>  drmPciBusInfo info;
>  struct pci_conf_io pc;
>  struct pci_match_conf patterns[1];
> @@ -4302,7 +4302,7 @@ drm_public char *drmGetDeviceNameFromFd2(int fd)
>  free(value);
>  
>  return strdup(path);
> -#elif __FreeBSD__
> +#elif defined(__FreeBSD__)
>  return drmGetDeviceNameFromFd(fd);
>  #else
>  struct stat  sbuf;
> -- 
> 2.20.1
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

 Ouch, sorry.

 Reviewed-by: Emmanuel Vadot 

-- 
Emmanuel Vadot  
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] ASoC: fsl: imx-pcm-dma: Don't request dma channel in probe

[Lucas Stach]

Am Mittwoch, den 20.05.2020, 16:20 +0800 schrieb Shengjiu Wang:
> Hi
> 
> On Tue, May 19, 2020 at 6:04 PM Lucas Stach  wrote:
> > Am Dienstag, den 19.05.2020, 17:41 +0800 schrieb Shengjiu Wang:
> > > There are two requirements that we need to move the request
> > > of dma channel from probe to open.
> > 
> > How do you handle -EPROBE_DEFER return code from the channel request if
> > you don't do it in probe?
> 
> I use the dma_request_slave_channel or dma_request_channel instead
> of dmaengine_pcm_request_chan_of. so there should be not -EPROBE_DEFER
> return code.

This is a pretty weak argument. The dmaengine device might probe after
you try to get the channel. Using a function to request the channel
that doesn't allow you to handle probe deferral is IMHO a bug and
should be fixed, instead of building even more assumptions on top of
it.

> > > - When dma device binds with power-domains, the power will
> > > be enabled when we request dma channel. If the request of dma
> > > channel happen on probe, then the power-domains will be always
> > > enabled after kernel boot up,  which is not good for power
> > > saving,  so we need to move the request of dma channel to .open();
> > 
> > This is certainly something which could be fixed in the dmaengine
> > driver.
> 
> Dma driver always call the pm_runtime_get_sync in
> device_alloc_chan_resources, the device_alloc_chan_resources is
> called when channel is requested. so power is enabled on channel
> request.

So why can't you fix the dmaengine driver to do that RPM call at a
later time when the channel is actually going to be used? This will
allow further power savings with other slave devices than the audio
PCM.

Regards,
Lucas

> > > - With FE-BE case, if the dma channel is requested in probe,
> > > then there will be below issue, which is caused by that the
> > > dma channel will be requested duplicately
> > 
> > Why is this requested a second time? Is this just some missing cleanup
> > on a deferred probe path?
> 
> Not relate with deferred probe.  With DMA1->ASRC->DMA2->ESAI case,
> the DMA1->ASRC->DMA2 is in FE,  ESAI is in BE.  When ESAI drvier
> probe,  DMA3 channel is created with ESAI's "dma:tx" (DMA3 channel
> is not used in this FE-BE case).When FE-BE startup, DMA2
> channel is created, it needs the ESAI's "dma:tx", so below warning
> comes out.
> 
> > Regards,
> > Lucas
> > 
> > > [  638.906268] sysfs: cannot create duplicate filename 
> > > '/devices/soc0/soc/200.bus/200.spba-bus/2024000.esai/dma:tx'
> > > [  638.919061] CPU: 1 PID: 673 Comm: aplay Not tainted 
> > > 5.7.0-rc1-12956-gfc64b2585593 #287
> > > [  638.927113] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
> > > [  638.933690] [] (unwind_backtrace) from [] 
> > > (show_stack+0x10/0x14)
> > > [  638.941464] [] (show_stack) from [] 
> > > (dump_stack+0xe4/0x118)
> > > [  638.948808] [] (dump_stack) from [] 
> > > (sysfs_warn_dup+0x50/0x64)
> > > [  638.956406] [] (sysfs_warn_dup) from [] 
> > > (sysfs_do_create_link_sd+0xc8/0xd4)
> > > [  638.965134] [] (sysfs_do_create_link_sd) from [] 
> > > (dma_request_chan+0xb0/0x210)
> > > [  638.974120] [] (dma_request_chan) from [] 
> > > (dma_request_slave_channel+0x8/0x14)
> > > [  638.983111] [] (dma_request_slave_channel) from [] 
> > > (fsl_asrc_dma_hw_params+0x1e0/0x438)
> > > [  638.992881] [] (fsl_asrc_dma_hw_params) from [] 
> > > (soc_pcm_hw_params+0x4a0/0x6a8)
> > > [  639.001952] [] (soc_pcm_hw_params) from [] 
> > > (dpcm_fe_dai_hw_params+0x70/0xe4)
> > > [  639.010765] [] (dpcm_fe_dai_hw_params) from [] 
> > > (snd_pcm_hw_params+0x158/0x418)
> > > [  639.019750] [] (snd_pcm_hw_params) from [] 
> > > (snd_pcm_ioctl+0x734/0x183c)
> > > [  639.028129] [] (snd_pcm_ioctl) from [] 
> > > (ksys_ioctl+0x2ac/0xb98)
> > > [  639.035812] [] (ksys_ioctl) from [] 
> > > (ret_fast_syscall+0x0/0x28)
> > > [  639.043490] Exception stack(0xec529fa8 to 0xec529ff0)
> > > [  639.048565] 9fa0:   bee84650 01321870 0004 
> > > c25c4111 bee84650 0002000f
> > > [  639.056766] 9fc0: bee84650 01321870 01321820 0036 1f40 
> > >  0002c2f8 0003
> > > [  639.064964] 9fe0: b6f483fc bee8451c b6ee2655 b6e1dcf8
> > > [  639.070339] fsl-esai-dai 2024000.esai: Cannot create DMA dma:tx symlink
> > > 
> > > Signed-off-by: Shengjiu Wang 
> > > ---
> > >  sound/soc/fsl/imx-pcm-dma.c | 173 +---
> > >  1 file changed, 159 insertions(+), 14 deletions(-)
> > > 
> > > diff --git a/sound/soc/fsl/imx-pcm-dma.c b/sound/soc/fsl/imx-pcm-dma.c
> > > index 04a9bc749016..dae53b384df4 100644
> > > --- a/sound/soc/fsl/imx-pcm-dma.c
> > > +++ b/sound/soc/fsl/imx-pcm-dma.c
> > > @@ -11,6 +11,7 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > > 
> > >  #include 
> > >  #include 
> > > @@ -29,24 +30,168 @@ static bool filter(struct dma_chan *chan, void 
> > > *param)
> > >   return true;
> > >  }
> > > 
> > > -static const struct snd_dmaengine_pcm_config 

[GIT PULL] etnaviv-fixes for 5.7

[Lucas Stach]

Hi Dave, hi Daniel,

two fixes:
- memory leak fix when userspace passes a invalid softpin address
- off-by-one crashing the kernel in the perfmon domain iteration when
the GPU core has both 2D and 3D capabilities

Regards,
Lucas

The following changes since commit 8f3d9f354286745c751374f5f1fcafee6b3f3136:

  Linux 5.7-rc1 (2020-04-12 12:35:55 -0700)

are available in the Git repository at:

  https://git.pengutronix.de/git/lst/linux etnaviv/fixes

for you to fetch changes up to ad99cb5e783bb03d512092db3387ead9504aad3d:

  drm/etnaviv: Fix a leak in submit_pin_objects() (2020-05-19 11:18:59 +0200)


Christian Gmeiner (1):
  drm/etnaviv: fix perfmon domain interation

Dan Carpenter (1):
  drm/etnaviv: Fix a leak in submit_pin_objects()

 drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 4 +++-
 drivers/gpu/drm/etnaviv/etnaviv_perfmon.c| 2 +-
 2 files changed, 4 insertions(+), 2 deletions(-)

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH 0/8] Qualcomm Cloud AI 100 driver

[Daniel Vetter]

On Wed, May 20, 2020 at 7:15 AM Greg Kroah-Hartman
 wrote:
>
> On Tue, May 19, 2020 at 10:41:15PM +0200, Daniel Vetter wrote:
> > On Tue, May 19, 2020 at 07:41:20PM +0200, Greg Kroah-Hartman wrote:
> > > On Tue, May 19, 2020 at 08:57:38AM -0600, Jeffrey Hugo wrote:
> > > > On 5/18/2020 11:08 PM, Dave Airlie wrote:
> > > > > On Fri, 15 May 2020 at 00:12, Jeffrey Hugo  
> > > > > wrote:
> > > > > >
> > > > > > Introduction:
> > > > > > Qualcomm Cloud AI 100 is a PCIe adapter card which contains a 
> > > > > > dedicated
> > > > > > SoC ASIC for the purpose of efficently running Deep Learning 
> > > > > > inference
> > > > > > workloads in a data center environment.
> > > > > >
> > > > > > The offical press release can be found at -
> > > > > > https://www.qualcomm.com/news/releases/2019/04/09/qualcomm-brings-power-efficient-artificial-intelligence-inference
> > > > > >
> > > > > > The offical product website is -
> > > > > > https://www.qualcomm.com/products/datacenter-artificial-intelligence
> > > > > >
> > > > > > At the time of the offical press release, numerious technology news 
> > > > > > sites
> > > > > > also covered the product.  Doing a search of your favorite site is 
> > > > > > likely
> > > > > > to find their coverage of it.
> > > > > >
> > > > > > It is our goal to have the kernel driver for the product fully 
> > > > > > upstream.
> > > > > > The purpose of this RFC is to start that process.  We are still 
> > > > > > doing
> > > > > > development (see below), and thus not quite looking to gain 
> > > > > > acceptance quite
> > > > > > yet, but now that we have a working driver we beleive we are at the 
> > > > > > stage
> > > > > > where meaningful conversation with the community can occur.
> > > > >
> > > > >
> > > > > Hi Jeffery,
> > > > >
> > > > > Just wondering what the userspace/testing plans for this driver.
> > > > >
> > > > > This introduces a new user facing API for a device without pointers to
> > > > > users or tests for that API.
> > > >
> > > > We have daily internal testing, although I don't expect you to take my 
> > > > word
> > > > for that.
> > > >
> > > > I would like to get one of these devices into the hands of Linaro, so 
> > > > that
> > > > it can be put into KernelCI.  Similar to other Qualcomm products. I'm 
> > > > trying
> > > > to convince the powers that be to make this happen.
> > > >
> > > > Regarding what the community could do on its own, everything but the 
> > > > Linux
> > > > driver is considered proprietary - that includes the on device firmware 
> > > > and
> > > > the entire userspace stack.  This is a decision above my pay grade.
> > >
> > > Ok, that's a decision you are going to have to push upward on, as we
> > > really can't take this without a working, open, userspace.
> >
> > Uh wut.
> >
> > So the merge criteria for drivers/accel (atm still drivers/misc but I
> > thought that was interim until more drivers showed up) isn't actually
> > "totally-not-a-gpu accel driver without open source userspace".
> >
> > Instead it's "totally-not-a-gpu accel driver without open source
> > userspace" _and_ you have to be best buddies with Greg. Or at least
> > not be on the naughty company list. Since for habanalabs all you
> > wanted is a few test cases to exercise the ioctls. Not the entire
> > userspace.
>
> Also, to be fair, I have changed my mind after seeing the mess of
> complexity that these "ioctls for everyone!" type of pass-through
> these kinds of drivers are creating.  You were right, we need open
> userspace code in order to be able to properly evaluate and figure out
> what they are doing is right or not and be able to maintain things over
> time correctly.
>
> So I was wrong, and you were right, my apologies for my previous
> stubbornness.

Awesome and don't worry, I'm pretty sure we've all been stubborn
occasionally :-)

>From a drivers/gpu pov I think still not quite there since we also
want to see the compiler for these programmable accelerator thingies.
But just having a fairly good consensus that "userspace library with
all the runtime stuff excluding compiler must be open" is a huge step
forward. Next step may be that we (kernel overall, drivers/gpu will
still ask for the full thing) have ISA docs for these programmable
things, so that we can also evaluate that aspect and gauge how many
security issues there might be. Plus have a fighting chance to fix up
the security leaks when (post smeltdown I don't really want to
consider this an if) someone finds a hole in the hw security wall. At
least in drivers/gpu we historically have a ton of drivers with
command checkers to validate what userspace wants to run on the
accelerator thingie. Both in cases where the hw was accidentally too
strict, and not strict enough.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org

Re: [PATCH] drm/amdgpu/smu10: Replace one-element array and use struct_size() helper

[Christian König]

Am 20.05.20 um 00:55 schrieb Gustavo A. R. Silva:

The current codebase makes use of one-element arrays in the following
form:

struct something {
 int length;
 u8 data[1];
};

struct something *instance;

instance = kmalloc(sizeof(*instance) + size, GFP_KERNEL);
instance->length = size;
memcpy(instance->data, source, size);

but the preferred mechanism to declare variable-length types such as
these ones is a flexible array member[1][2], introduced in C99:

struct foo {
 int stuff;
 struct boo array[];
};

By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on. So, replace
the one-element array with a flexible-array member.

Also, make use of the new struct_size() helper to properly calculate the
size of struct smu10_voltage_dependency_table.

This issue was found with the help of Coccinelle and, audited and fixed
_manually_.

[1] 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgcc.gnu.org%2Fonlinedocs%2Fgcc%2FZero-Length.htmldata=02%7C01%7Cchristian.koenig%40amd.com%7C8a400bdb88924a1d951508d7fc471966%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637255254622039268sdata=ILOPPn17c%2B3oyLLdh%2BgH2b%2B8RdhWuTFGxruRD7GUHOo%3Dreserved=0
[2] 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FKSPP%2Flinux%2Fissues%2F21data=02%7C01%7Cchristian.koenig%40amd.com%7C8a400bdb88924a1d951508d7fc471966%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637255254622039268sdata=lCr5Otij55Snq27BDp4RmtW4hNhOS%2Bm4vSUOOAz07XA%3Dreserved=0
[3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")

Signed-off-by: Gustavo A. R. Silva 


Acked-by: Christian König 

May I suggest that we add a section how to correctly do this to 
Documentation/process/coding-style.rst or similar document?


I've seen a bunch of different approaches and some even doesn't work 
with some gcc versions and result in a broken binary.


Thanks,
Christian.


---
  drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c | 6 ++
  drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.h | 2 +-
  2 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
index 246bb9ac557d8..c9cfe90a29471 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
@@ -410,12 +410,10 @@ static int 
smu10_get_clock_voltage_dependency_table(struct pp_hwmgr *hwmgr,
struct smu10_voltage_dependency_table **pptable,
uint32_t num_entry, const DpmClock_t 
*pclk_dependency_table)
  {
-   uint32_t table_size, i;
+   uint32_t i;
struct smu10_voltage_dependency_table *ptable;
  
-	table_size = sizeof(uint32_t) + sizeof(struct smu10_voltage_dependency_table) * num_entry;

-   ptable = kzalloc(table_size, GFP_KERNEL);
-
+   ptable = kzalloc(struct_size(ptable, entries, num_entry), GFP_KERNEL);
if (NULL == ptable)
return -ENOMEM;
  
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.h b/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.h

index 1fb296a996f3a..0f969de10fabc 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.h
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.h
@@ -192,7 +192,7 @@ struct smu10_clock_voltage_dependency_record {
  
  struct smu10_voltage_dependency_table {

uint32_t count;
-   struct smu10_clock_voltage_dependency_record entries[1];
+   struct smu10_clock_voltage_dependency_record entries[];
  };
  
  struct smu10_clock_voltage_information {


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [EXTERNAL] Re: [RFC PATCH 0/4] DirectX on Linux

[Daniel Vetter]

Hi Steve,

Sounds all good, some more comments and details below.

On Wed, May 20, 2020 at 5:47 AM Steve Pronovost 
wrote:

> Hey guys,
>
> Thanks for the discussion. I may not be able to immediately answer all of
> your questions, but I'll do my best .
>
> drivers/hyperv sounds like it could be a better location. We weren't too
> sure where to put this, we though /drivers/gpu would be appropriate given
> this deal with GPUs, but I get your point... this is a vGPU driver that
> really only works when being run under Hyper-V, so drivers/hyperv is likely
> more appropriate.
>

I think "it's a virtual gpu" is the wrong sales pitch, as is "only runs on
$platform". We have lots of drm drivers in drivers/gpu that fit that bill.
The better pitch I think is "it's a not a gpu, it's a dx12 protocol pipe"
and "we actually do not want to integrate with the linux gpu ecosystem and
primitives, we want to integrate with dx12 ecosystem and primitives to make
the seamless rdp/rail/vail stuff work nicely". Below some more thoughts on
the technical said.

>
> In term of presentation, I need to clarify a few things. We announced
> today that we're also adding support for Linux GUI applications. The way
> this will work is roughly as follow. We're writing a Wayland compositor
> that will essentially bridge over RDP-RAIL (RAIL=Remote Application
> Integrated Locally). We're starting from a Weston base. Weston already has
> an RDP Backend, but that's for a full desktop remoting scheme. Weston draws
> a desktop and remote it over RDP... and then you can peek at that desktop
> using an rdp client on the Windows side. RAIL works differently. In that
> case our wayland compositor no longer paint a desktop... instead it simply
> forward individual visual / wl_surface over the RDP RAIL channel such that
> these visual can be displayed on the Windows desktop. The RDP client create
> proxy window for each of these top level visual and their content is filled
> with the data coming over the RDP channel. All pixels are owned by the RDP
> server/WSL... so these windows looks different than native window are they
> are painted and themed by WSL. The proxy window on the host gather input
> and inject back over RDP... This is essentially how application remoting
> works on windows and this is all publicly documented as part of the various
> RDP protocol specification. As a matter of fact, for the RDP server on the
> Weston side we are looking at continue to leverage FreeRDP (and provide
> fixes/enhancement as needed to the public project). Further, we're looking
> at further improvement down this path to avoid having to copy the content
> over the RAIL channel and instead just share/swap buffer between the guest
> and the host. We have extension to the RDP protocol, called VAIL
> (Virtualized Application Integrated Locally) which does that today. Today
> this is only use in Windows on Windows for very specific scenario. We're
> looking at extending the public RDP protocol with these VAIL extension to
> make this an official Microsoft supported protocol which would allow us to
> target this in WSL. We have finished designing this part in details. Our
> goal would be to leverage something along the line of wl_drm, dma-buf,
> dma-fence, etc... This compositor and all our contribution to FreeRDP will
> be fully open source, including our design doc. We're not quite sure yet
> whether this will be offered as a separate project entirely distinct from
> it's Weston root... or if we'll propose an extension to Weston to operate
> in this mode. We would like to build it such that in theory any Wayland
> compositor could add support for this mode of operation if they want to
> remote application to a Windows host (over the network, or on the same box).
>

Sounds like a solid plan for presentation. I think this is all up to
wayland/weston folks to figure out with you, from the kernel side I have
only one concern (and I discussed that with a few folks already on irc, I
think they're at least on this thread involved within microsoft too in some
form): If we do integrate with linux concepts like wl_drm/dma-buf/fence and
so on then we end up with a normal gpu driver, with with lots of blobby
components all around that can't be opened (since large chunks written by
hw vendors, so nothing microsoft can do about them). That's the awkward
exception (why microsoft but not other gpu hw vendors/plaforms/whatever?)
that we need to avoid.

But wayland doesn't really need dma-buf and the wl_drm protocols afaiui, as
long as the egl extensions work you can have whatever private wayland
protocol in your winsys code you want to shovel the buffers and syncobj
from client to the wayland-rdp-rail compositor. If that uses dx12 native
handles for these things we side-step the awkward exception question for
linux gpu stack since it all stays 100% contained in drivers/hv. Just try
to avoid the nvidia fail of insisting that you need your own set of egl
extensions (egl_streams 

[PATCH] ASoC: fsl: imx-pcm-dma: Don't request dma channel in probe

[Shengjiu Wang]

There are two requirements that we need to move the request
of dma channel from probe to open.

- When dma device binds with power-domains, the power will
be enabled when we request dma channel. If the request of dma
channel happen on probe, then the power-domains will be always
enabled after kernel boot up,  which is not good for power
saving,  so we need to move the request of dma channel to .open();

- With FE-BE case, if the dma channel is requested in probe,
then there will be below issue, which is caused by that the
dma channel will be requested duplicately

[  638.906268] sysfs: cannot create duplicate filename 
'/devices/soc0/soc/200.bus/200.spba-bus/2024000.esai/dma:tx'
[  638.919061] CPU: 1 PID: 673 Comm: aplay Not tainted 
5.7.0-rc1-12956-gfc64b2585593 #287
[  638.927113] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[  638.933690] [] (unwind_backtrace) from [] 
(show_stack+0x10/0x14)
[  638.941464] [] (show_stack) from [] 
(dump_stack+0xe4/0x118)
[  638.948808] [] (dump_stack) from [] 
(sysfs_warn_dup+0x50/0x64)
[  638.956406] [] (sysfs_warn_dup) from [] 
(sysfs_do_create_link_sd+0xc8/0xd4)
[  638.965134] [] (sysfs_do_create_link_sd) from [] 
(dma_request_chan+0xb0/0x210)
[  638.974120] [] (dma_request_chan) from [] 
(dma_request_slave_channel+0x8/0x14)
[  638.983111] [] (dma_request_slave_channel) from [] 
(fsl_asrc_dma_hw_params+0x1e0/0x438)
[  638.992881] [] (fsl_asrc_dma_hw_params) from [] 
(soc_pcm_hw_params+0x4a0/0x6a8)
[  639.001952] [] (soc_pcm_hw_params) from [] 
(dpcm_fe_dai_hw_params+0x70/0xe4)
[  639.010765] [] (dpcm_fe_dai_hw_params) from [] 
(snd_pcm_hw_params+0x158/0x418)
[  639.019750] [] (snd_pcm_hw_params) from [] 
(snd_pcm_ioctl+0x734/0x183c)
[  639.028129] [] (snd_pcm_ioctl) from [] 
(ksys_ioctl+0x2ac/0xb98)
[  639.035812] [] (ksys_ioctl) from [] 
(ret_fast_syscall+0x0/0x28)
[  639.043490] Exception stack(0xec529fa8 to 0xec529ff0)
[  639.048565] 9fa0:   bee84650 01321870 0004 c25c4111 
bee84650 0002000f
[  639.056766] 9fc0: bee84650 01321870 01321820 0036 1f40  
0002c2f8 0003
[  639.064964] 9fe0: b6f483fc bee8451c b6ee2655 b6e1dcf8
[  639.070339] fsl-esai-dai 2024000.esai: Cannot create DMA dma:tx symlink

Signed-off-by: Shengjiu Wang 
---
 sound/soc/fsl/imx-pcm-dma.c | 173 +---
 1 file changed, 159 insertions(+), 14 deletions(-)

diff --git a/sound/soc/fsl/imx-pcm-dma.c b/sound/soc/fsl/imx-pcm-dma.c
index 04a9bc749016..dae53b384df4 100644
--- a/sound/soc/fsl/imx-pcm-dma.c
+++ b/sound/soc/fsl/imx-pcm-dma.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -29,24 +30,168 @@ static bool filter(struct dma_chan *chan, void *param)
return true;
 }
 
-static const struct snd_dmaengine_pcm_config imx_dmaengine_pcm_config = {
-   .prepare_slave_config = snd_dmaengine_pcm_prepare_slave_config,
-   .compat_filter_fn = filter,
-};
+static int imx_pcm_hw_params(struct snd_soc_component *component,
+struct snd_pcm_substream *substream,
+struct snd_pcm_hw_params *params)
+{
+   struct snd_pcm_runtime *runtime = substream->runtime;
+   struct snd_soc_pcm_runtime *rtd = substream->private_data;
+   struct snd_soc_dai *cpu_dai = asoc_rtd_to_cpu(rtd, 0);
+   struct snd_dmaengine_dai_dma_data *dma_data;
+   struct dma_slave_config config;
+   struct dma_chan *chan;
+   int ret = 0;
 
-int imx_pcm_dma_init(struct platform_device *pdev, size_t size)
+   snd_pcm_set_runtime_buffer(substream, >dma_buffer);
+   runtime->dma_bytes = params_buffer_bytes(params);
+
+   chan = snd_dmaengine_pcm_get_chan(substream);
+   if (!chan)
+   return -EINVAL;
+
+   ret = snd_hwparams_to_dma_slave_config(substream, params, );
+   if (ret)
+   return ret;
+
+   dma_data = snd_soc_dai_get_dma_data(cpu_dai, substream);
+   if (!dma_data)
+   return -EINVAL;
+
+   snd_dmaengine_pcm_set_config_from_dai_data(substream,
+  dma_data,
+  );
+   return dmaengine_slave_config(chan, );
+}
+
+static int imx_pcm_hw_free(struct snd_soc_component *component,
+  struct snd_pcm_substream *substream)
 {
-   struct snd_dmaengine_pcm_config *config;
+   snd_pcm_set_runtime_buffer(substream, NULL);
+   return 0;
+}
+
+static snd_pcm_uframes_t imx_pcm_pointer(struct snd_soc_component *component,
+struct snd_pcm_substream *substream)
+{
+   return snd_dmaengine_pcm_pointer(substream);
+}
+
+static int imx_pcm_trigger(struct snd_soc_component *component,
+  struct snd_pcm_substream *substream, int cmd)
+{
+   return snd_dmaengine_pcm_trigger(substream, cmd);
+}
+
+static int imx_pcm_open(struct snd_soc_component *component,
+  

[PATCH v2] drm/exynos: Remove dev_err() on platform_get_irq() failure

[Tamseel Shams]

platform_get_irq() will call dev_err() itself on failure,
so there is no need for the driver to also do this.
This is detected by coccinelle.

Also removing unnecessary curly braces around if () statement.

Signed-off-by: Tamseel Shams 
---
Fixed review comment by j...@perches.com

 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 4 +---
 drivers/gpu/drm/exynos/exynos_drm_g2d.c | 1 -
 drivers/gpu/drm/exynos/exynos_drm_rotator.c | 4 +---
 drivers/gpu/drm/exynos/exynos_drm_scaler.c  | 4 +---
 4 files changed, 3 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 902938d2568f..958e2c6a6702 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1809,10 +1809,8 @@ static int exynos_dsi_probe(struct platform_device *pdev)
}
 
dsi->irq = platform_get_irq(pdev, 0);
-   if (dsi->irq < 0) {
-   dev_err(dev, "failed to request dsi irq resource\n");
+   if (dsi->irq < 0)
return dsi->irq;
-   }
 
irq_set_status_flags(dsi->irq, IRQ_NOAUTOEN);
ret = devm_request_threaded_irq(dev, dsi->irq, NULL,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c 
b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index fcee33a43aca..03be31427181 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -1498,7 +1498,6 @@ static int g2d_probe(struct platform_device *pdev)
 
g2d->irq = platform_get_irq(pdev, 0);
if (g2d->irq < 0) {
-   dev_err(dev, "failed to get irq\n");
ret = g2d->irq;
goto err_put_clk;
}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_rotator.c 
b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
index dafa87b82052..2d94afba031e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
@@ -293,10 +293,8 @@ static int rotator_probe(struct platform_device *pdev)
return PTR_ERR(rot->regs);
 
irq = platform_get_irq(pdev, 0);
-   if (irq < 0) {
-   dev_err(dev, "failed to get irq\n");
+   if (irq < 0)
return irq;
-   }
 
ret = devm_request_irq(dev, irq, rotator_irq_handler, 0, dev_name(dev),
   rot);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_scaler.c 
b/drivers/gpu/drm/exynos/exynos_drm_scaler.c
index 93c43c8d914e..ce1857138f89 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_scaler.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_scaler.c
@@ -502,10 +502,8 @@ static int scaler_probe(struct platform_device *pdev)
return PTR_ERR(scaler->regs);
 
irq = platform_get_irq(pdev, 0);
-   if (irq < 0) {
-   dev_err(dev, "failed to get irq\n");
+   if (irq < 0)
return irq;
-   }
 
ret = devm_request_threaded_irq(dev, irq, NULL, scaler_irq_handler,
IRQF_ONESHOT, "drm_scaler", scaler);
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/tegra: hub: Do not enable orphaned window group

[Nicolin Chen]

Though the unconditional enable/disable code is not a final solution,
we don't want to run into a NULL pointer situation when window group
doesn't link to its DC parent if the DC is disabled in Device Tree.

So this patch simply adds a check to make sure that window group has
a valid parent before running into tegra_windowgroup_enable/disable.

Signed-off-by: Nicolin Chen 
---
 drivers/gpu/drm/tegra/hub.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/tegra/hub.c b/drivers/gpu/drm/tegra/hub.c
index 8183e617bf6b..a2ef8f218d4e 100644
--- a/drivers/gpu/drm/tegra/hub.c
+++ b/drivers/gpu/drm/tegra/hub.c
@@ -149,7 +149,9 @@ int tegra_display_hub_prepare(struct tegra_display_hub *hub)
for (i = 0; i < hub->soc->num_wgrps; i++) {
struct tegra_windowgroup *wgrp = >wgrps[i];
 
-   tegra_windowgroup_enable(wgrp);
+   /* Skip orphaned window group whose parent DC is disabled */
+   if (wgrp->parent)
+   tegra_windowgroup_enable(wgrp);
}
 
return 0;
@@ -166,7 +168,9 @@ void tegra_display_hub_cleanup(struct tegra_display_hub 
*hub)
for (i = 0; i < hub->soc->num_wgrps; i++) {
struct tegra_windowgroup *wgrp = >wgrps[i];
 
-   tegra_windowgroup_disable(wgrp);
+   /* Skip orphaned window group whose parent DC is disabled */
+   if (wgrp->parent)
+   tegra_windowgroup_disable(wgrp);
}
 }
 
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] arch/{mips,sparc,microblaze,powerpc}: Don't enable pagefault/preempt twice

[Guenter Roeck]

On Tue, May 19, 2020 at 11:40:32AM -0700, Ira Weiny wrote:
> On Tue, May 19, 2020 at 09:54:22AM -0700, Guenter Roeck wrote:
> > On Mon, May 18, 2020 at 11:48:43AM -0700, ira.we...@intel.com wrote:
> > > From: Ira Weiny 
> > > 
> > > The kunmap_atomic clean up failed to remove one set of pagefault/preempt
> > > enables when vaddr is not in the fixmap.
> > > 
> > > Fixes: bee2128a09e6 ("arch/kunmap_atomic: consolidate duplicate code")
> > > Signed-off-by: Ira Weiny 
> > 
> > microblazeel works with this patch,
> 
> Awesome...  Andrew in my rush yesterday I should have put a reported by on the
> patch for Guenter as well.
> 
> Sorry about that Guenter,

No worries.

> Ira
> 
> > as do the nosmp sparc32 boot tests,
> > but sparc32 boot tests with SMP enabled still fail with lots of messages
> > such as:
> > 
> > BUG: Bad page state in process swapper/0  pfn:006a1
> > page:f0933420 refcount:0 mapcount:1 mapping:(ptrval) index:0x1
> > flags: 0x0()
> > raw:  0100 0122  0001   
> > page dumped because: nonzero mapcount
> > Modules linked in:
> > CPU: 0 PID: 1 Comm: swapper/0 Tainted: GB 
> > 5.7.0-rc6-next-20200518-2-gb178d2d56f29 #1
> > [f00e7ab8 :
> > bad_page+0xa8/0x108 ]
> > [f00e8b54 :
> > free_pcppages_bulk+0x154/0x52c ]
> > [f00ea024 :
> > free_unref_page+0x54/0x6c ]
> > [f00ed864 :
> > free_reserved_area+0x58/0xec ]
> > [f0527104 :
> > kernel_init+0x14/0x110 ]
> > [f000b77c :
> > ret_from_kernel_thread+0xc/0x38 ]
> > [ :
> > 0x0 ]
> > 
> > Code path leading to that message is different but always the same
> > from free_unref_page().
> > 
> > Still testing ppc images.
> > 

ppc image tests are passing with this patch.

Guenter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] dt-bindings: gpu: arm,mali-utgard: add additional properties

[Johan Jonker]

In the old txt situation we add/describe only properties that are used
by the driver/hardware itself. With yaml it also filters things in a
node that are used by other drivers like 'assigned-clocks' and
'assigned-clock-rates' for some older Rockchip SoCs in 'gpu' nodes,
so add them to 'arm,mali-utgard.yaml'.

Signed-off-by: Johan Jonker 
---
 Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml 
b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml
index 4869258da..2fc97c544 100644
--- a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml
@@ -95,6 +95,12 @@ properties:
   - const: bus
   - const: core
 
+  assigned-clocks:
+maxItems: 1
+
+  assigned-clock-rates:
+maxItems: 1
+
   memory-region: true
 
   mali-supply: true
-- 
2.11.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH 0/8] Qualcomm Cloud AI 100 driver

[Bjorn Andersson]

On Tue 19 May 21:59 PDT 2020, Greg Kroah-Hartman wrote:

> On Tue, May 19, 2020 at 10:41:15PM +0200, Daniel Vetter wrote:
> > > Ok, that's a decision you are going to have to push upward on, as we
> > > really can't take this without a working, open, userspace.
> > 
> > Uh wut.
> > 
> > So the merge criteria for drivers/accel (atm still drivers/misc but I
> > thought that was interim until more drivers showed up) isn't actually
> > "totally-not-a-gpu accel driver without open source userspace".
> > 
> > Instead it's "totally-not-a-gpu accel driver without open source
> > userspace" _and_ you have to be best buddies with Greg. Or at least
> > not be on the naughty company list. Since for habanalabs all you
> > wanted is a few test cases to exercise the ioctls. Not the entire
> > userspace.
> 
> Habanalabs now has their full library opensourced that their tools use
> directly, so that's not an argument anymore.
> 
> My primary point here is the copyright owner of this code, because of
> that, I'm not going to objet to allowing this to be merged without open
> userspace code.
> 

So because it's copyright Linux Foundation you are going to accept it
without user space, after all?

Regards,
Bjorn
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] linux/bits.h: adjust GENMASK_INPUT_CHECK() check

[Rikard Falkeborn]

+ Andrew et al who recieved mail from the build robot this morning about
the same issue.

On Tue, May 19, 2020 at 10:14:52PM +0100, Emil Velikov wrote:
> Recently the GENMASK_INPUT_CHECK() was added, aiming to catch cases
> where there GENMASK arguments are flipped.
> 
> Although it seems to be triggering -Wtype-limits in the following cases:
> 
>unsigned foo = (10 + x);
>unsigned bar = GENMASK(foo, 0);
> 
>const unsigned foo = (10 + x);
>unsigned bar = GENMASK(foo, 0);
> 
> Here are the warnings, from my GCC 9.2 box.
> 
> warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]
>__builtin_constant_p((l) > (h)), (l) > (h), 0)))
> ^
> warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]
>__builtin_constant_p((l) > (h)), (l) > (h), 0)))
> ^
> 
> This results in people disabling the warning all together or promoting
> foo to signed. Either of which being a sub par option IMHO.
> 
> Add a trivial "+ 1" to each h and l in the constant expression.
> 
> v2: drop accidental !
> 
> Fixes: 295bcca84916 ("linux/bits.h: add compile time sanity check of
> GENMASK inputs")
> Cc: Rikard Falkeborn 
> Cc: Linus Torvalds 
> Cc: Chris Wilson 
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Emil Velikov 
> Reported-by: kbuild test robot 
> Reported-by: kbuild test robot 
> ---
>  include/linux/bits.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/linux/bits.h b/include/linux/bits.h
> index 4671fbf28842..02a42866d198 100644
> --- a/include/linux/bits.h
> +++ b/include/linux/bits.h
> @@ -23,7 +23,7 @@
>  #include 
>  #define GENMASK_INPUT_CHECK(h, l) \
>   (BUILD_BUG_ON_ZERO(__builtin_choose_expr( \
> - __builtin_constant_p((l) > (h)), (l) > (h), 0)))
> + __builtin_constant_p((l + 1) > (h + 1)), (l + 1) > (h + 1), 0)))

You need parentheses around l and h here.

I think I would have prefered a cast to int here instead but I'm fine
with either (I don't think pragmas for disabling the warning can be used
since the check is added to the mask). Either way, I think we need a
comment on why this is done.

>  #else
>  /*
>   * BUILD_BUG_ON_ZERO is not available in h files included from asm files,
> -- 
> 2.25.1
> 

I can't reproduce this with gcc 10 and kernelci.org does not show the
warning (but those builds seem to be gcc 8 only, so maybe this is a gcc
9 thing only). A bit strange this shows up now, it's been in Linus's
tree for six weeks and in next for even longer, but oh well.

Rikard
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/1] serial: stm32: add no_console_suspend support

[Erwan Le Ray]

In order to display console messages in low power mode, console pins
must be kept active after suspend call.

---
Initial patch "serial: stm32: add support for no_console_suspend" was part
of "STM32 usart power improvement" series, but as dependancy to
console_suspend pinctl state has been removed to fit with Rob comment [1],
this patch has no more dependancy with any other patch of this series.

[1] https://lkml.org/lkml/2019/7/9/451

Signed-off-by: Erwan Le Ray 

diff --git a/drivers/tty/serial/stm32-usart.c b/drivers/tty/serial/stm32-usart.c
index 9cfcf355567a..5afd29162f6c 100644
--- a/drivers/tty/serial/stm32-usart.c
+++ b/drivers/tty/serial/stm32-usart.c
@@ -1425,7 +1425,18 @@ static int __maybe_unused stm32_serial_suspend(struct 
device *dev)
else
stm32_serial_enable_wakeup(port, false);
 
-   pinctrl_pm_select_sleep_state(dev);
+   /*
+* When "no_console_suspend" is enabled, keep the pinctrl default state
+* and rely on bootloader stage to restore this state upon resume.
+* Otherwise, apply the idle or sleep states depending on wakeup
+* capabilities.
+*/
+   if (console_suspend_enabled || !uart_console(port)) {
+   if (device_may_wakeup(dev))
+   pinctrl_pm_select_idle_state(dev);
+   else
+   pinctrl_pm_select_sleep_state(dev);
+   }
 
return 0;
 }
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH 0/8] Qualcomm Cloud AI 100 driver

[Jason Gunthorpe]

On Tue, May 19, 2020 at 10:41:15PM +0200, Daniel Vetter wrote:

> Get some consistency into your decision making as maintainer. And don't
> tell me or anyone else that this is complicated, gpu and rdma driver folks
> very much told you and Olof last year that this is what you're getting
> yourself into.

It is complicated!

One of the big mistakes we learned from in RDMA is that we must have a
cannonical open userspace, that is at least the user side of the uABI
from the kernel. It doesn't have to do a lot but it does have to be
there and everyone must use it.

Some time ago it was all a fragmented mess where every HW had its own
library project with no community and that spilled into the kernel
where it became impossible to be sure everyone was playing nicely and
keeping their parts up to date. We are still digging out where I find
stuff in the kernel that just never seemed to make it into any
userspace..

I feel this is an essential ingredient, and I think I gave this advice
at LPC as well - it is important to start as a proper subsystem with a
proper standard user space. IMHO a random collection of opaque misc
drivers for incredibly complex HW is not going to magically gel into a
subsystem.

Given the state of the industry the userspace doesn't have to do
alot, and maybe that library exposes unique APIs for each HW, but it
is at least a rallying point to handle all these questions like: 'is
the proposed userspace enough?', give some consistency, and be ready
to add in those things that are common (like, say IOMMU PASID setup)

The uacce stuff is sort of interesting here as it does seem to take
some of that approach, it is really simplistic, but the basic idea of
creating a generic DMA work ring is in there, and probably applies
just as well to several of these 'totally-not-a-GPU' drivers.

The other key is that the uABI from the kernel does need to be very
flexible as really any new HW can appear with any new strange need all
the time, and there will not be detailed commonality between HWs. RDMA
has made this mistake a lot in the past too.

The newer RDMA netlink like API is actually turning out not bad for
this purpose.. (again something a subsystem could provide)

Also the approach in this driver to directly connect the device to
userspace for control commands has worked for RDMA in the past few
years.

Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] arch/{mips,sparc,microblaze,powerpc}: Don't enable pagefault/preempt twice

[Guenter Roeck]

On Mon, May 18, 2020 at 11:48:43AM -0700, ira.we...@intel.com wrote:
> From: Ira Weiny 
> 
> The kunmap_atomic clean up failed to remove one set of pagefault/preempt
> enables when vaddr is not in the fixmap.
> 
> Fixes: bee2128a09e6 ("arch/kunmap_atomic: consolidate duplicate code")
> Signed-off-by: Ira Weiny 

microblazeel works with this patch, as do the nosmp sparc32 boot tests,
but sparc32 boot tests with SMP enabled still fail with lots of messages
such as:

BUG: Bad page state in process swapper/0  pfn:006a1
page:f0933420 refcount:0 mapcount:1 mapping:(ptrval) index:0x1
flags: 0x0()
raw:  0100 0122  0001   
page dumped because: nonzero mapcount
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Tainted: GB 
5.7.0-rc6-next-20200518-2-gb178d2d56f29 #1
[f00e7ab8 :
bad_page+0xa8/0x108 ]
[f00e8b54 :
free_pcppages_bulk+0x154/0x52c ]
[f00ea024 :
free_unref_page+0x54/0x6c ]
[f00ed864 :
free_reserved_area+0x58/0xec ]
[f0527104 :
kernel_init+0x14/0x110 ]
[f000b77c :
ret_from_kernel_thread+0xc/0x38 ]
[ :
0x0 ]

Code path leading to that message is different but always the same
from free_unref_page().

Still testing ppc images.

Guenter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] drm/mm: improve rb_hole_addr rbtree search

[Nirmoy Das]

Userspace can still abuse alignment while allocating buffer object
to slow down rb_hole_addr rbtree search. This patch improves search
in fragmented rb_hole_addr rbtree by storing maximum subtree hole
alignment and use that to skip a complete subtree if that subtree
can not fit a (size + alignment) request.

With this patch applied, 50k bo allocs of size 4k and alignment 9k
took ~0.24 sec on amdgpu, compared to  27 sec without it.

Signed-off-by: Nirmoy Das 
---
 drivers/gpu/drm/drm_mm.c | 66 ++--
 include/drm/drm_mm.h |  1 +
 2 files changed, 58 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index 91e90c635e05..1af0a211b660 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -212,8 +212,11 @@ static void drm_mm_interval_tree_add_node(struct 
drm_mm_node *hole_node,
   _mm_interval_tree_augment);
 }
 
+#define DRM_MM_ALIGN_SHIFT 6
 #define HOLE_SIZE(NODE) ((NODE)->hole_size)
 #define HOLE_ADDR(NODE) (__drm_mm_hole_node_start(NODE))
+#define HOLE_SIZE_ALIGN(NODE) ((NODE->hole_size << DRM_MM_ALIGN_SHIFT) | \
+  ffs(HOLE_ADDR(NODE)))
 
 static u64 rb_to_hole_size(struct rb_node *rb)
 {
@@ -241,6 +244,33 @@ static void insert_hole_size(struct rb_root_cached *root,
rb_insert_color_cached(>rb_hole_size, root, first);
 }
 
+static inline bool
+augment_callbacks_compute_max_hole_align(struct drm_mm_node *node, bool exit)
+{
+   struct drm_mm_node *child;
+   u64 max = HOLE_SIZE_ALIGN(node);
+
+   if (node->rb_hole_addr.rb_left) {
+   child = rb_entry(node->rb_hole_addr.rb_left, struct drm_mm_node,
+rb_hole_addr);
+   if (child->subtree_max_hole_align > max)
+   max = child->subtree_max_hole_align;
+   }
+
+   if (node->rb_hole_addr.rb_right) {
+   child = rb_entry(node->rb_hole_addr.rb_right,
+struct drm_mm_node, rb_hole_addr);
+   if (child->subtree_max_hole_align > max)
+   max = child->subtree_max_hole_align;
+   }
+
+   if (exit && node->subtree_max_hole_align == max)
+   return true;
+
+   node->subtree_max_hole_align = max;
+   return false;
+}
+
 static inline bool
 augment_callbacks_compute_max_hole(struct drm_mm_node *node, bool exit)
 {
@@ -271,10 +301,14 @@ augment_callbacks_compute_max_hole(struct drm_mm_node 
*node, bool exit)
 static inline void
 augment_callbacks_propagate(struct rb_node *rb, struct rb_node *stop)
 {
+   bool compute_max_hole, compute_max_hole_align;
+
while (rb != stop) {
struct drm_mm_node *node = rb_entry(rb,  struct drm_mm_node,
rb_hole_addr);
-   if (augment_callbacks_compute_max_hole(node, true))
+   compute_max_hole = augment_callbacks_compute_max_hole(node, 
true);
+   compute_max_hole_align = 
augment_callbacks_compute_max_hole_align(node, true);
+   if (compute_max_hole && compute_max_hole_align)
break;
 
rb = rb_parent(>rb_hole_addr);
@@ -290,6 +324,7 @@ augment_callbacks_copy(struct rb_node *rb_old, struct 
rb_node *rb_new)
   rb_hole_addr);
 
new->subtree_max_hole = old->subtree_max_hole;
+   new->subtree_max_hole_align = old->subtree_max_hole_align;
 }
 
 static void
@@ -301,7 +336,9 @@ augment_callbacks_rotate(struct rb_node *rb_old, struct 
rb_node *rb_new)
   rb_hole_addr);
 
new->subtree_max_hole = old->subtree_max_hole;
+   new->subtree_max_hole_align = old->subtree_max_hole_align;
augment_callbacks_compute_max_hole(old, false);
+   augment_callbacks_compute_max_hole_align(old, false);
 }
 
 static const struct rb_augment_callbacks augment_callbacks = {
@@ -313,7 +350,9 @@ static const struct rb_augment_callbacks augment_callbacks 
= {
 static void insert_hole_addr(struct rb_root *root, struct drm_mm_node *node)
 {
struct rb_node **link = >rb_node, *rb_parent = NULL;
-   u64 start = HOLE_ADDR(node), subtree_max_hole = node->subtree_max_hole;
+   u64 start = HOLE_ADDR(node);
+   u64 subtree_max_hole = node->subtree_max_hole;
+   u64 subtree_max_hole_align = node->subtree_max_hole_align;
struct drm_mm_node *parent;
 
while (*link) {
@@ -322,6 +361,9 @@ static void insert_hole_addr(struct rb_root *root, struct 
drm_mm_node *node)
if (parent->subtree_max_hole < subtree_max_hole)
parent->subtree_max_hole = subtree_max_hole;
 
+   if (parent->subtree_max_hole_align < subtree_max_hole_align)
+   parent->subtree_max_hole_align = subtree_max_hole_align;
+
if (start < HOLE_ADDR(parent))
 

[PATCH 1/2] drm/mm: expand rb_hole_addr augmented callbacks

[Nirmoy Das]

Expand RB_DECLARE_CALLBACKS_MAX so that it is possible to store
extra value(max hole alignment) in the rb_hole_addr augmented rbtree.

Signed-off-by: Nirmoy Das 
---
 drivers/gpu/drm/drm_mm.c | 72 ++--
 1 file changed, 69 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index f4ca1ff80af9..91e90c635e05 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -241,9 +241,74 @@ static void insert_hole_size(struct rb_root_cached *root,
rb_insert_color_cached(>rb_hole_size, root, first);
 }

-RB_DECLARE_CALLBACKS_MAX(static, augment_callbacks,
-struct drm_mm_node, rb_hole_addr,
-u64, subtree_max_hole, HOLE_SIZE)
+static inline bool
+augment_callbacks_compute_max_hole(struct drm_mm_node *node, bool exit)
+{
+   struct drm_mm_node *child;
+   u64 max = HOLE_SIZE(node);
+
+   if (node->rb_hole_addr.rb_left) {
+   child = rb_entry(node->rb_hole_addr.rb_left, struct drm_mm_node,
+rb_hole_addr);
+   if (child->subtree_max_hole > max)
+   max = child->subtree_max_hole;
+   }
+
+   if (node->rb_hole_addr.rb_right) {
+   child = rb_entry(node->rb_hole_addr.rb_right,
+struct drm_mm_node, rb_hole_addr);
+   if (child->subtree_max_hole > max)
+   max = child->subtree_max_hole;
+   }
+
+   if (exit && node->subtree_max_hole == max)
+   return true;
+
+   node->subtree_max_hole = max;
+   return false;
+}
+
+static inline void
+augment_callbacks_propagate(struct rb_node *rb, struct rb_node *stop)
+{
+   while (rb != stop) {
+   struct drm_mm_node *node = rb_entry(rb,  struct drm_mm_node,
+   rb_hole_addr);
+   if (augment_callbacks_compute_max_hole(node, true))
+   break;
+
+   rb = rb_parent(>rb_hole_addr);
+   }
+}
+
+static inline void
+augment_callbacks_copy(struct rb_node *rb_old, struct rb_node *rb_new)
+{
+   struct drm_mm_node *old = rb_entry(rb_old, struct drm_mm_node,
+  rb_hole_addr);
+   struct drm_mm_node *new = rb_entry(rb_new, struct drm_mm_node,
+  rb_hole_addr);
+
+   new->subtree_max_hole = old->subtree_max_hole;
+}
+
+static void
+augment_callbacks_rotate(struct rb_node *rb_old, struct rb_node *rb_new)
+{
+   struct drm_mm_node *old = rb_entry(rb_old, struct drm_mm_node,
+  rb_hole_addr);
+   struct drm_mm_node *new = rb_entry(rb_new, struct drm_mm_node,
+  rb_hole_addr);
+
+   new->subtree_max_hole = old->subtree_max_hole;
+   augment_callbacks_compute_max_hole(old, false);
+}
+
+static const struct rb_augment_callbacks augment_callbacks = {
+   .propagate = augment_callbacks_propagate,
+   .copy = augment_callbacks_copy,
+   .rotate = augment_callbacks_rotate
+};

 static void insert_hole_addr(struct rb_root *root, struct drm_mm_node *node)
 {
@@ -256,6 +321,7 @@ static void insert_hole_addr(struct rb_root *root, struct 
drm_mm_node *node)
parent = rb_entry(rb_parent, struct drm_mm_node, rb_hole_addr);
if (parent->subtree_max_hole < subtree_max_hole)
parent->subtree_max_hole = subtree_max_hole;
+
if (start < HOLE_ADDR(parent))
link = >rb_hole_addr.rb_left;
else
--
2.26.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v1 00/25] seqlock: Extend seqcount API with associated locks

[Ahmed S. Darwish]

Hi,

A sequence counter write side critical section must be protected by some
form of locking to serialize writers. If the serialization primitive is
not disabling preemption implicitly, preemption has to be explicitly
disabled before entering the write side critical section.

There is no built-in debugging mechanism to verify that the lock used
for writer serialization is held and preemption is disabled. Some usage
sites like dma-buf have explicit lockdep checks for the writer-side
lock, but this covers only a small portion of the sequence counter usage
in the kernel.

Add new sequence counter types which allows to associate a lock to the
sequence counter at initialization time. The seqcount API functions are
extended to provide appropriate lockdep assertions depending on the
seqcount/lock type.

For sequence counters with associated locks that do not implicitly
disable preemption, preemption protection is enforced in the sequence
counter write side functions. This removes the need to explicitly add
preempt_disable/enable() around the write side critical sections: the
write_begin/end() functions for these new sequence counter types
automatically do this.

Extend the lockdep API with a macro asserting that preemption is
disabled.  Use it to verify that preemption is disabled for all sequence
counters write side critical sections.

If lockdep is disabled, these lock associations and non-preemptibility
checks are compiled out and have neither storage size nor runtime
overhead. If lockdep is enabled, a pointer to the lock is stored in the
seqcount and the write side API functions enable lockdep assertions.

The following seqcount types with associated locks are introduced:

 seqcount_spinlock_t
 seqcount_raw_spinlock_t
 seqcount_rwlock_t
 seqcount_mutex_t
 seqcount_ww_mutex_t

This lock association is not only useful for debugging purposes, it also
provides a mechanism for PREEMPT_RT to prevent writer starvation. On RT
kernels spinlocks and rwlocks are substituted with sleeping locks and
the code sections protected by these locks become preemptible, which has
the same problem as write side critical section with preemption enabled
on a non-RT kernel. RT utilizes this association by storing the provided
lock pointer and in case that a reader sees an active writer (seqcount
is odd), it does not spin, but blocks on the associated lock similar to
read_seqbegin_or_lock().

By using the lockdep debugging mechanisms added in this patch series, a
number of erroneous seqcount call-sites were discovered across the
kernel. The fixes are included at the beginning of the series.

Thanks,

8<--

Ahmed S. Darwish (25):
  net: core: device_rename: Use rwsem instead of a seqcount
  mm/swap: Don't abuse the seqcount latching API
  net: phy: fixed_phy: Remove unused seqcount
  block: nr_sects_write(): Disable preemption on seqcount write
  u64_stats: Document writer non-preemptibility requirement
  dma-buf: Remove custom seqcount lockdep class key
  lockdep: Add preemption disabled assertion API
  seqlock: lockdep assert non-preemptibility on seqcount_t write
  Documentation: locking: Describe seqlock design and usage
  seqlock: Add RST directives to kernel-doc code samples and notes
  seqlock: Add missing kernel-doc annotations
  seqlock: Extend seqcount API with associated locks
  dma-buf: Use sequence counter with associated wound/wait mutex
  sched: tasks: Use sequence counter with associated spinlock
  netfilter: conntrack: Use sequence counter with associated spinlock
  netfilter: nft_set_rbtree: Use sequence counter with associated rwlock
  xfrm: policy: Use sequence counters with associated lock
  timekeeping: Use sequence counter with associated raw spinlock
  vfs: Use sequence counter with associated spinlock
  raid5: Use sequence counter with associated spinlock
  iocost: Use sequence counter with associated spinlock
  NFSv4: Use sequence counter with associated spinlock
  userfaultfd: Use sequence counter with associated spinlock
  kvm/eventfd: Use sequence counter with associated spinlock
  hrtimer: Use sequence counter with associated raw spinlock

 Documentation/locking/index.rst   |   1 +
 Documentation/locking/seqlock.rst | 239 +
 MAINTAINERS   |   2 +-
 block/blk-iocost.c|   5 +-
 block/blk.h   |   2 +
 drivers/dma-buf/dma-resv.c|  15 +-
 .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c  |   2 -
 drivers/md/raid5.c|   2 +-
 drivers/md/raid5.h|   2 +-
 drivers/net/phy/fixed_phy.c   |  25 +-
 fs/dcache.c   |   2 +-
 fs/fs_struct.c|   4 +-
 fs/nfs/nfs4_fs.h  |   2 +-
 fs/nfs/nfs4state.c|   2 +-
 fs/userfaultfd.c  |   4 +-
 

[PATCH] drm/mediatek: mtk_mt8173_hdmi_phy: Remove unnused const variables

[Enric Balletbo i Serra]

There are some `static const u8` variables that are not used, this
triggers a warning building with `make W=1`, it is safe to remove them,
so do it and make the compiler more happy.

Signed-off-by: Enric Balletbo i Serra 
---

 .../gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c| 48 ---
 1 file changed, 48 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c 
b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
index 1c3575372230..827b93786fac 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
@@ -107,54 +107,6 @@
 #define RGS_HDMITX_5T1_EDG (0xf << 4)
 #define RGS_HDMITX_PLUG_TSTBIT(0)
 
-static const u8 PREDIV[3][4] = {
-   {0x0, 0x0, 0x0, 0x0},   /* 27Mhz */
-   {0x1, 0x1, 0x1, 0x1},   /* 74Mhz */
-   {0x1, 0x1, 0x1, 0x1}/* 148Mhz */
-};
-
-static const u8 TXDIV[3][4] = {
-   {0x3, 0x3, 0x3, 0x2},   /* 27Mhz */
-   {0x2, 0x1, 0x1, 0x1},   /* 74Mhz */
-   {0x1, 0x0, 0x0, 0x0}/* 148Mhz */
-};
-
-static const u8 FBKSEL[3][4] = {
-   {0x1, 0x1, 0x1, 0x1},   /* 27Mhz */
-   {0x1, 0x0, 0x1, 0x1},   /* 74Mhz */
-   {0x1, 0x0, 0x1, 0x1}/* 148Mhz */
-};
-
-static const u8 FBKDIV[3][4] = {
-   {19, 24, 29, 19},   /* 27Mhz */
-   {19, 24, 14, 19},   /* 74Mhz */
-   {19, 24, 14, 19}/* 148Mhz */
-};
-
-static const u8 DIVEN[3][4] = {
-   {0x2, 0x1, 0x1, 0x2},   /* 27Mhz */
-   {0x2, 0x2, 0x2, 0x2},   /* 74Mhz */
-   {0x2, 0x2, 0x2, 0x2}/* 148Mhz */
-};
-
-static const u8 HTPLLBP[3][4] = {
-   {0xc, 0xc, 0x8, 0xc},   /* 27Mhz */
-   {0xc, 0xf, 0xf, 0xc},   /* 74Mhz */
-   {0xc, 0xf, 0xf, 0xc}/* 148Mhz */
-};
-
-static const u8 HTPLLBC[3][4] = {
-   {0x2, 0x3, 0x3, 0x2},   /* 27Mhz */
-   {0x2, 0x3, 0x3, 0x2},   /* 74Mhz */
-   {0x2, 0x3, 0x3, 0x2}/* 148Mhz */
-};
-
-static const u8 HTPLLBR[3][4] = {
-   {0x1, 0x1, 0x0, 0x1},   /* 27Mhz */
-   {0x1, 0x2, 0x2, 0x1},   /* 74Mhz */
-   {0x1, 0x2, 0x2, 0x1}/* 148Mhz */
-};
-
 static int mtk_hdmi_pll_prepare(struct clk_hw *hw)
 {
struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
-- 
2.26.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v1 06/25] dma-buf: Remove custom seqcount lockdep class key

[Ahmed S. Darwish]

Commit 3c3b177a9369 ("reservation: add support for read-only access
using rcu") introduced a sequence counter to manage updates to
reservations. Back then, the reservation object initializer
reservation_object_init() was always inlined.

Having the sequence counter initialization inlined meant that each of
the call sites would have a different lockdep class key, which would've
broken lockdep's deadlock detection. The aforementioned commit thus
introduced, and exported, a custom seqcount lockdep class key and name.

The commit 8735f16803f00 ("dma-buf: cleanup reservation_object_init...")
transformed the reservation object initializer to a normal non-inlined C
function. seqcount_init(), which automatically defines the seqcount
lockdep class key and must be called non-inlined, can now be safely used.

Remove the seqcount custom lockdep class key, name, and export. Use
seqcount_init() inside the dma reservation object initializer.

Signed-off-by: Ahmed S. Darwish 
Reviewed-by: Sebastian Andrzej Siewior 
---
 drivers/dma-buf/dma-resv.c | 9 +
 include/linux/dma-resv.h   | 2 --
 2 files changed, 1 insertion(+), 10 deletions(-)

diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
index 4264e64788c4..590ce7ad60a0 100644
--- a/drivers/dma-buf/dma-resv.c
+++ b/drivers/dma-buf/dma-resv.c
@@ -50,12 +50,6 @@
 DEFINE_WD_CLASS(reservation_ww_class);
 EXPORT_SYMBOL(reservation_ww_class);
 
-struct lock_class_key reservation_seqcount_class;
-EXPORT_SYMBOL(reservation_seqcount_class);
-
-const char reservation_seqcount_string[] = "reservation_seqcount";
-EXPORT_SYMBOL(reservation_seqcount_string);
-
 /**
  * dma_resv_list_alloc - allocate fence list
  * @shared_max: number of fences we need space for
@@ -134,9 +128,8 @@ subsys_initcall(dma_resv_lockdep);
 void dma_resv_init(struct dma_resv *obj)
 {
ww_mutex_init(>lock, _ww_class);
+   seqcount_init(>seq);
 
-   __seqcount_init(>seq, reservation_seqcount_string,
-   _seqcount_class);
RCU_INIT_POINTER(obj->fence, NULL);
RCU_INIT_POINTER(obj->fence_excl, NULL);
 }
diff --git a/include/linux/dma-resv.h b/include/linux/dma-resv.h
index ee50d10f052b..a6538ae7d93f 100644
--- a/include/linux/dma-resv.h
+++ b/include/linux/dma-resv.h
@@ -46,8 +46,6 @@
 #include 
 
 extern struct ww_class reservation_ww_class;
-extern struct lock_class_key reservation_seqcount_class;
-extern const char reservation_seqcount_string[];
 
 /**
  * struct dma_resv_list - a list of shared fences
-- 
2.20.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/mediatek: mtk_hdmi: Remove debug messages for function calls

[Enric Balletbo i Serra]

Equivalent information can be nowadays obtained using function tracer

Signed-off-by: Enric Balletbo i Serra 
---

 drivers/gpu/drm/mediatek/mtk_hdmi.c| 12 +---
 drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c |  4 
 2 files changed, 1 insertion(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c 
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index b0555a7cb3b4..172d67294435 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -1634,8 +1634,6 @@ static int mtk_hdmi_audio_startup(struct device *dev, 
void *data)
 {
struct mtk_hdmi *hdmi = dev_get_drvdata(dev);
 
-   dev_dbg(dev, "%s\n", __func__);
-
mtk_hdmi_audio_enable(hdmi);
 
return 0;
@@ -1645,8 +1643,6 @@ static void mtk_hdmi_audio_shutdown(struct device *dev, 
void *data)
 {
struct mtk_hdmi *hdmi = dev_get_drvdata(dev);
 
-   dev_dbg(dev, "%s\n", __func__);
-
mtk_hdmi_audio_disable(hdmi);
 }
 
@@ -1655,8 +1651,6 @@ mtk_hdmi_audio_digital_mute(struct device *dev, void 
*data, bool enable)
 {
struct mtk_hdmi *hdmi = dev_get_drvdata(dev);
 
-   dev_dbg(dev, "%s(%d)\n", __func__, enable);
-
if (enable)
mtk_hdmi_hw_aud_mute(hdmi);
else
@@ -1669,8 +1663,6 @@ static int mtk_hdmi_audio_get_eld(struct device *dev, 
void *data, uint8_t *buf,
 {
struct mtk_hdmi *hdmi = dev_get_drvdata(dev);
 
-   dev_dbg(dev, "%s\n", __func__);
-
memcpy(buf, hdmi->conn.eld, min(sizeof(hdmi->conn.eld), len));
 
return 0;
@@ -1770,7 +1762,6 @@ static int mtk_drm_hdmi_probe(struct platform_device 
*pdev)
goto err_bridge_remove;
}
 
-   dev_dbg(dev, "mediatek hdmi probe success\n");
return 0;
 
 err_bridge_remove:
@@ -1793,7 +1784,7 @@ static int mtk_hdmi_suspend(struct device *dev)
struct mtk_hdmi *hdmi = dev_get_drvdata(dev);
 
mtk_hdmi_clk_disable_audio(hdmi);
-   dev_dbg(dev, "hdmi suspend success!\n");
+
return 0;
 }
 
@@ -1808,7 +1799,6 @@ static int mtk_hdmi_resume(struct device *dev)
return ret;
}
 
-   dev_dbg(dev, "hdmi resume success!\n");
return 0;
 }
 #endif
diff --git a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c 
b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
index b55f51675205..1c3575372230 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
@@ -159,8 +159,6 @@ static int mtk_hdmi_pll_prepare(struct clk_hw *hw)
 {
struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
 
-   dev_dbg(hdmi_phy->dev, "%s\n", __func__);
-
mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON1, RG_HDMITX_PLL_AUTOK_EN);
mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_PLL_POSDIV);
mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON3, RG_HDMITX_MHLCK_EN);
@@ -178,8 +176,6 @@ static void mtk_hdmi_pll_unprepare(struct clk_hw *hw)
 {
struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
 
-   dev_dbg(hdmi_phy->dev, "%s\n", __func__);
-
mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON1, RG_HDMITX_PLL_TXDIV_EN);
mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON1, RG_HDMITX_PLL_BIAS_LPF_EN);
usleep_range(100, 150);
-- 
2.26.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel