Re: [Nouveau] [PATCH 1/8] drm/nouveau/kms/nv50-: Use atomic encoder callbacks everywhere

2020-11-13 Thread Ben Skeggs
I've merged all of these.  Sent the first to 5.10-fixes for the
regression there, the rest will go in with a later -next pull request.

Thanks,
Ben.

On Sat, 14 Nov 2020 at 10:14, Lyude Paul  wrote:
>
> It turns out that I forgot to go through and make sure that I converted all
> encoder callbacks to use atomic_enable/atomic_disable(), so let's go and
> actually do that.
>
> Signed-off-by: Lyude Paul 
> Cc: Kirill A. Shutemov 
> Fixes: 09838c4efe9a ("drm/nouveau/kms: Search for encoders' connectors 
> properly")
> ---
>  drivers/gpu/drm/nouveau/dispnv50/disp.c | 29 -
>  1 file changed, 14 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
> b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> index b111fe24a06b..36d6b6093d16 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> @@ -455,7 +455,7 @@ nv50_outp_get_old_connector(struct nouveau_encoder *outp,
>   * DAC
>   
> */
>  static void
> -nv50_dac_disable(struct drm_encoder *encoder)
> +nv50_dac_disable(struct drm_encoder *encoder, struct drm_atomic_state *state)
>  {
> struct nouveau_encoder *nv_encoder = nouveau_encoder(encoder);
> struct nv50_core *core = nv50_disp(encoder->dev)->core;
> @@ -467,7 +467,7 @@ nv50_dac_disable(struct drm_encoder *encoder)
>  }
>
>  static void
> -nv50_dac_enable(struct drm_encoder *encoder)
> +nv50_dac_enable(struct drm_encoder *encoder, struct drm_atomic_state *state)
>  {
> struct nouveau_encoder *nv_encoder = nouveau_encoder(encoder);
> struct nouveau_crtc *nv_crtc = nouveau_crtc(encoder->crtc);
> @@ -525,8 +525,8 @@ nv50_dac_detect(struct drm_encoder *encoder, struct 
> drm_connector *connector)
>  static const struct drm_encoder_helper_funcs
>  nv50_dac_help = {
> .atomic_check = nv50_outp_atomic_check,
> -   .enable = nv50_dac_enable,
> -   .disable = nv50_dac_disable,
> +   .atomic_enable = nv50_dac_enable,
> +   .atomic_disable = nv50_dac_disable,
> .detect = nv50_dac_detect
>  };
>
> @@ -1055,7 +1055,7 @@ nv50_dp_bpc_to_depth(unsigned int bpc)
>  }
>
>  static void
> -nv50_msto_enable(struct drm_encoder *encoder)
> +nv50_msto_enable(struct drm_encoder *encoder, struct drm_atomic_state *state)
>  {
> struct nv50_head *head = nv50_head(encoder->crtc);
> struct nv50_head_atom *armh = nv50_head_atom(head->base.base.state);
> @@ -1101,7 +1101,7 @@ nv50_msto_enable(struct drm_encoder *encoder)
>  }
>
>  static void
> -nv50_msto_disable(struct drm_encoder *encoder)
> +nv50_msto_disable(struct drm_encoder *encoder, struct drm_atomic_state 
> *state)
>  {
> struct nv50_msto *msto = nv50_msto(encoder);
> struct nv50_mstc *mstc = msto->mstc;
> @@ -1118,8 +1118,8 @@ nv50_msto_disable(struct drm_encoder *encoder)
>
>  static const struct drm_encoder_helper_funcs
>  nv50_msto_help = {
> -   .disable = nv50_msto_disable,
> -   .enable = nv50_msto_enable,
> +   .atomic_disable = nv50_msto_disable,
> +   .atomic_enable = nv50_msto_enable,
> .atomic_check = nv50_msto_atomic_check,
>  };
>
> @@ -1645,8 +1645,7 @@ nv50_sor_disable(struct drm_encoder *encoder,
>  }
>
>  static void
> -nv50_sor_enable(struct drm_encoder *encoder,
> -   struct drm_atomic_state *state)
> +nv50_sor_enable(struct drm_encoder *encoder, struct drm_atomic_state *state)
>  {
> struct nouveau_encoder *nv_encoder = nouveau_encoder(encoder);
> struct nouveau_crtc *nv_crtc = nouveau_crtc(encoder->crtc);
> @@ -1873,7 +1872,7 @@ nv50_pior_atomic_check(struct drm_encoder *encoder,
>  }
>
>  static void
> -nv50_pior_disable(struct drm_encoder *encoder)
> +nv50_pior_disable(struct drm_encoder *encoder, struct drm_atomic_state 
> *state)
>  {
> struct nouveau_encoder *nv_encoder = nouveau_encoder(encoder);
> struct nv50_core *core = nv50_disp(encoder->dev)->core;
> @@ -1885,7 +1884,7 @@ nv50_pior_disable(struct drm_encoder *encoder)
>  }
>
>  static void
> -nv50_pior_enable(struct drm_encoder *encoder)
> +nv50_pior_enable(struct drm_encoder *encoder, struct drm_atomic_state *state)
>  {
> struct nouveau_encoder *nv_encoder = nouveau_encoder(encoder);
> struct nouveau_crtc *nv_crtc = nouveau_crtc(encoder->crtc);
> @@ -1921,14 +1920,14 @@ nv50_pior_enable(struct drm_encoder *encoder)
> }
>
> core->func->pior->ctrl(core, nv_encoder->or, ctrl, asyh);
> -   nv_encoder->crtc = encoder->crtc;
> +   nv_encoder->crtc = _crtc->base;
>  }
>
>  static const struct drm_encoder_helper_funcs
>  nv50_pior_help = {
> .atomic_check = nv50_pior_atomic_check,
> -   .enable = nv50_pior_enable,
> -   .disable = nv50_pior_disable,
> +   .atomic_enable = nv50_pior_enable,
> +   .atomic_disable = nv50_pior_disable,
>  };
>
>  static void
> --
> 2.28.0
>
> 

[PULL] nouveau-next 5.11

2020-11-13 Thread Ben Skeggs
Just a single fix at the moment.  An alternate version of a regression
fix in 5.10, against additional changes from drm-next.

Ben.

The following changes since commit 512bce50a41c528fa15c4c014293e7bebf018658:

  Merge v5.10-rc3 into drm-next (2020-11-10 14:36:36 +0100)

are available in the Git repository at:

  git://github.com/skeggsb/linux linux-5.11

for you to fetch changes up to be323a4cef022aa9685b08d5a94ddc841ccf617a:

  drm/nouveau/ttm: avoid using nouveau_drm.ttm.type_vram prior to nv50
(2020-11-14 14:35:57 +1000)


Ben Skeggs (1):
  drm/nouveau/ttm: avoid using nouveau_drm.ttm.type_vram prior to nv50

 drivers/gpu/drm/nouveau/nouveau_bo.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PULL] nouveau-fixes 5.10

2020-11-13 Thread Ben Skeggs
The following changes since commit f8394f232b1eab649ce2df5c5f15b0e528c92091:

  Linux 5.10-rc3 (2020-11-08 16:10:16 -0800)

are available in the Git repository at:

  git://github.com/skeggsb/linux linux-5.10

for you to fetch changes up to 5c6fb4b28b165887c42c66731c90eaca818b04c6:

  drm/nouveau/kms/nv50-: Use atomic encoder callbacks everywhere
(2020-11-14 14:19:18 +1000)


Alexander Kapshuk (1):
  drm/nouveau/kms: Fix NULL pointer dereference in
nouveau_connector_detect_depth

Ben Skeggs (1):
  drm/nouveau/ttm: avoid using nouveau_drm.ttm.type_vram prior to nv50

Lyude Paul (1):
  drm/nouveau/kms/nv50-: Use atomic encoder callbacks everywhere

 drivers/gpu/drm/nouveau/dispnv50/disp.c | 29 ++---
 drivers/gpu/drm/nouveau/nouveau_bo.c|  3 +--
 drivers/gpu/drm/nouveau/nouveau_connector.c | 14 +-
 3 files changed, 24 insertions(+), 22 deletions(-)

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


[radeon-alex:amd-staging-drm-next 534/571] drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:904:6: warning: old-style function definition

2020-11-13 Thread kernel test robot
tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head:   a29bd65d3af75aa50f10e35af7bb77218943622f
commit: 16cf2b67735cdd2f97aade032f8d720c8b089523 [534/571] drm/amdgpu: add s0i3 
capacity check for s0i3 routine
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git remote add radeon-alex git://people.freedesktop.org/~agd5f/linux.git
git fetch --no-tags radeon-alex amd-staging-drm-next
git checkout 16cf2b67735cdd2f97aade032f8d720c8b089523
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=ia64 

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

All warnings (new ones prefixed by >>):

   drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c: In function 
'amdgpu_acpi_is_s0ix_supported':
>> drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:904:6: warning: old-style function 
>> definition [-Wold-style-definition]
 904 | bool amdgpu_acpi_is_s0ix_supported()
 |  ^

vim +904 drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c

   898  
   899  /**
   900   * amdgpu_acpi_is_s0ix_supported
   901   *
   902   * returns true if supported, false if not.
   903   */
 > 904  bool amdgpu_acpi_is_s0ix_supported()

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 8/8] drm/nouveau/kms/nv50-: Fix locking for audio callbacks

2020-11-13 Thread Lyude Paul
Noticed that I wasn't paying close enough attention the last time I looked
at our audio callbacks, as I completely missed the fact that we were
figuring out which audio-enabled connector goes to each encoder by checking
it's state, but without grabbing any of the appropriate modesetting locks
to do so.

That being said however: trying to grab modesetting locks in our audio
callbacks would be very painful due to the potential for locking inversion
between HDA and DRM. So, let's instead just copy what i915 does again - add
our own audio lock to protect audio related state, and store each audio
enabled connector in each nouveau_encoder struct so that we don't need to
check any atomic states.

Signed-off-by: Lyude Paul 
---
 drivers/gpu/drm/nouveau/dispnv50/disp.c   | 66 ---
 drivers/gpu/drm/nouveau/nouveau_drv.h |  1 +
 drivers/gpu/drm/nouveau/nouveau_encoder.h |  7 ++-
 3 files changed, 43 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index b19d0d7a6de9..65a991846e96 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -607,34 +607,27 @@ nv50_audio_component_get_eld(struct device *kdev, int 
port, int dev_id,
struct nouveau_drm *drm = nouveau_drm(drm_dev);
struct drm_encoder *encoder;
struct nouveau_encoder *nv_encoder;
-   struct drm_connector *connector;
struct nouveau_crtc *nv_crtc;
-   struct drm_connector_list_iter conn_iter;
int ret = 0;
 
*enabled = false;
 
+   mutex_lock(>audio.lock);
+
drm_for_each_encoder(encoder, drm->dev) {
struct nouveau_connector *nv_connector = NULL;
 
+   if (encoder->encoder_type == DRM_MODE_ENCODER_DPMST)
+   continue; /* TODO */
+
nv_encoder = nouveau_encoder(encoder);
+   nv_connector = nouveau_connector(nv_encoder->audio.connector);
+   nv_crtc = nouveau_crtc(nv_encoder->crtc);
 
-   drm_connector_list_iter_begin(drm_dev, _iter);
-   drm_for_each_connector_iter(connector, _iter) {
-   if (connector->state->best_encoder == encoder) {
-   nv_connector = nouveau_connector(connector);
-   break;
-   }
-   }
-   drm_connector_list_iter_end(_iter);
-   if (!nv_connector)
+   if (!nv_crtc || nv_encoder->or != port || nv_crtc->index != 
dev_id)
continue;
 
-   nv_crtc = nouveau_crtc(nv_encoder->crtc);
-   if (!nv_crtc || nv_encoder->or != port ||
-   nv_crtc->index != dev_id)
-   continue;
-   *enabled = nv_encoder->audio;
+   *enabled = nv_encoder->audio.enabled;
if (*enabled) {
ret = drm_eld_size(nv_connector->base.eld);
memcpy(buf, nv_connector->base.eld,
@@ -643,6 +636,8 @@ nv50_audio_component_get_eld(struct device *kdev, int port, 
int dev_id,
break;
}
 
+   mutex_unlock(>audio.lock);
+
return ret;
 }
 
@@ -692,17 +687,22 @@ static const struct component_ops 
nv50_audio_component_bind_ops = {
 static void
 nv50_audio_component_init(struct nouveau_drm *drm)
 {
-   if (!component_add(drm->dev->dev, _audio_component_bind_ops))
-   drm->audio.component_registered = true;
+   if (component_add(drm->dev->dev, _audio_component_bind_ops))
+   return;
+
+   drm->audio.component_registered = true;
+   mutex_init(>audio.lock);
 }
 
 static void
 nv50_audio_component_fini(struct nouveau_drm *drm)
 {
-   if (drm->audio.component_registered) {
-   component_del(drm->dev->dev, _audio_component_bind_ops);
-   drm->audio.component_registered = false;
-   }
+   if (!drm->audio.component_registered)
+   return;
+
+   component_del(drm->dev->dev, _audio_component_bind_ops);
+   drm->audio.component_registered = false;
+   mutex_destroy(>audio.lock);
 }
 
 /**
@@ -725,11 +725,13 @@ nv50_audio_disable(struct drm_encoder *encoder, struct 
nouveau_crtc *nv_crtc)
(0x0100 << nv_crtc->index),
};
 
-   if (!nv_encoder->audio)
-   return;
-
-   nv_encoder->audio = false;
-   nvif_mthd(>disp->object, 0, , sizeof(args));
+   mutex_lock(>audio.lock);
+   if (nv_encoder->audio.enabled) {
+   nv_encoder->audio.enabled = false;
+   nv_encoder->audio.connector = NULL;
+   nvif_mthd(>disp->object, 0, , sizeof(args));
+   }
+   mutex_unlock(>audio.lock);
 
nv50_audio_component_eld_notify(drm->audio.component, nv_encoder->or,

[PATCH 7/8] drm/nouveau/kms/nv50-: Use nouveau_encoder->crtc in get_eld callback

2020-11-13 Thread Lyude Paul
drm_encoder->crtc is deprecated for atomic drivers, but
nouveau_encoder->crtc is safe.

Signed-off-by: Lyude Paul 
---
 drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 63fff3988f19..b19d0d7a6de9 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -630,7 +630,7 @@ nv50_audio_component_get_eld(struct device *kdev, int port, 
int dev_id,
if (!nv_connector)
continue;
 
-   nv_crtc = nouveau_crtc(encoder->crtc);
+   nv_crtc = nouveau_crtc(nv_encoder->crtc);
if (!nv_crtc || nv_encoder->or != port ||
nv_crtc->index != dev_id)
continue;
-- 
2.28.0

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


[PATCH 0/8] drm/nouveau: Finish atomic cleanup + fix regression

2020-11-13 Thread Lyude Paul
This series just fixes a regression I accidentally introduced when
fixing how we find the currently set connectors for a given encoder:

09838c4efe9a ("drm/nouveau/kms: Search for encoders' connectors properly")

As well, this goes through and finishes cleaning up any references to
drm_encoder->crtc, any inappropriate references to drm_crtc->state, and
one inappropriate reference to drm_connector->state that I noticed along
the way.

Lyude Paul (8):
  drm/nouveau/kms/nv50-: Use atomic encoder callbacks everywhere
  drm/nouveau/kms/nv50-: Remove (nv_encoder->crtc) checks in ->disable
callbacks
  drm/nouveau/kms/nv50-: Rename encoder->atomic_(enable|disable)
callbacks
  drm/nouveau/kms/nv50-: s/armh/asyh/ in nv50_msto_atomic_enable()
  drm/nouveau/kms/nv50-: Reverse args for
nv50_outp_get_(old|new)_connector()
  drm/nouveau/kms/nv50-: Lookup current encoder/crtc from atomic state
  drm/nouveau/kms/nv50-: Use nouveau_encoder->crtc in get_eld callback
  drm/nouveau/kms/nv50-: Fix locking for audio callbacks

 drivers/gpu/drm/nouveau/dispnv50/disp.c   | 216 --
 drivers/gpu/drm/nouveau/nouveau_drv.h |   1 +
 drivers/gpu/drm/nouveau/nouveau_encoder.h |  13 +-
 3 files changed, 124 insertions(+), 106 deletions(-)

-- 
2.28.0

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


[PATCH 6/8] drm/nouveau/kms/nv50-: Lookup current encoder/crtc from atomic state

2020-11-13 Thread Lyude Paul
Despite being an atomic driver, nouveau has a lot of leftover code that
relies on retrieving information regarding the new atomic state from
members of drm_encoder and drm_crtc. The first field being used,
drm_encoder.crtc, is deprecated for atomic drivers. The second field being
used is drm_crtc.state, which is only really sensible to use outside of an
atomic modeset.

So, add some helpers to lookup the current crtc for a given outp from the
atomic state. Then, convert most of the code in dispnv50/disp.c to use said
new helper, along with the relevant DRM atomic helpers for retrieving the
new encoder/crtc combinations for a new atomic state.

Note that we don't get rid of the nouveau_encoder.crtc field entirely for
three reasons:

- Legacy modesetting for pre-nv50 still uses it
- It doesn't cause any locking issues
- We need it for the HDA callbacks, as grabbing atomic modesetting locks in
  those would be a mess.

Signed-off-by: Lyude Paul 
---
 drivers/gpu/drm/nouveau/dispnv50/disp.c | 59 -
 1 file changed, 38 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 2c0749fac9dc..63fff3988f19 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -449,6 +449,22 @@ nv50_outp_get_old_connector(struct drm_atomic_state 
*state, struct nouveau_encod
return NULL;
 }
 
+static struct nouveau_crtc *
+nv50_outp_get_new_crtc(const struct drm_atomic_state *state, const struct 
nouveau_encoder *outp)
+{
+   struct drm_crtc *crtc;
+   struct drm_crtc_state *crtc_state;
+   const u32 mask = drm_encoder_mask(>base.base);
+   int i;
+
+   for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
+   if (crtc_state->encoder_mask & mask)
+   return nouveau_crtc(crtc);
+   }
+
+   return NULL;
+}
+
 /**
  * DAC
  */
@@ -468,8 +484,9 @@ static void
 nv50_dac_atomic_enable(struct drm_encoder *encoder, struct drm_atomic_state 
*state)
 {
struct nouveau_encoder *nv_encoder = nouveau_encoder(encoder);
-   struct nouveau_crtc *nv_crtc = nouveau_crtc(encoder->crtc);
-   struct nv50_head_atom *asyh = nv50_head_atom(nv_crtc->base.state);
+   struct nouveau_crtc *nv_crtc = nv50_outp_get_new_crtc(state, 
nv_encoder);
+   struct nv50_head_atom *asyh =
+   nv50_head_atom(drm_atomic_get_new_crtc_state(state, 
_crtc->base));
struct nv50_core *core = nv50_disp(encoder->dev)->core;
u32 ctrl = 0;
 
@@ -490,7 +507,7 @@ nv50_dac_atomic_enable(struct drm_encoder *encoder, struct 
drm_atomic_state *sta
core->func->dac->ctrl(core, nv_encoder->or, ctrl, asyh);
asyh->or.depth = 0;
 
-   nv_encoder->crtc = encoder->crtc;
+   nv_encoder->crtc = _crtc->base;
 }
 
 static enum drm_connector_status
@@ -719,13 +736,12 @@ nv50_audio_disable(struct drm_encoder *encoder, struct 
nouveau_crtc *nv_crtc)
 }
 
 static void
-nv50_audio_enable(struct drm_encoder *encoder, struct drm_atomic_state *state,
+nv50_audio_enable(struct drm_encoder *encoder, struct nouveau_crtc *nv_crtc,
+ struct nouveau_connector *nv_connector, struct 
drm_atomic_state *state,
  struct drm_display_mode *mode)
 {
struct nouveau_drm *drm = nouveau_drm(encoder->dev);
struct nouveau_encoder *nv_encoder = nouveau_encoder(encoder);
-   struct nouveau_crtc *nv_crtc = nouveau_crtc(encoder->crtc);
-   struct nouveau_connector *nv_connector;
struct nv50_disp *disp = nv50_disp(encoder->dev);
struct __packed {
struct {
@@ -741,7 +757,6 @@ nv50_audio_enable(struct drm_encoder *encoder, struct 
drm_atomic_state *state,
 (0x0100 << nv_crtc->index),
};
 
-   nv_connector = nv50_outp_get_new_connector(state, nv_encoder);
if (!drm_detect_monitor_audio(nv_connector->edid))
return;
 
@@ -778,12 +793,12 @@ nv50_hdmi_disable(struct drm_encoder *encoder, struct 
nouveau_crtc *nv_crtc)
 }
 
 static void
-nv50_hdmi_enable(struct drm_encoder *encoder, struct drm_atomic_state *state,
+nv50_hdmi_enable(struct drm_encoder *encoder, struct nouveau_crtc *nv_crtc,
+struct nouveau_connector *nv_connector, struct 
drm_atomic_state *state,
 struct drm_display_mode *mode)
 {
struct nouveau_drm *drm = nouveau_drm(encoder->dev);
struct nouveau_encoder *nv_encoder = nouveau_encoder(encoder);
-   struct nouveau_crtc *nv_crtc = nouveau_crtc(encoder->crtc);
struct nv50_disp *disp = nv50_disp(encoder->dev);
struct {
struct nv50_disp_mthd_v1 base;
@@ -798,7 +813,6 @@ nv50_hdmi_enable(struct drm_encoder *encoder, struct 
drm_atomic_state *state,
 

[PATCH 5/8] drm/nouveau/kms/nv50-: Reverse args for nv50_outp_get_(old|new)_connector()

2020-11-13 Thread Lyude Paul
Just to be more consistent with the order of args that DRM helpers like
drm_atomic_get_new_crtc_state() use.

Signed-off-by: Lyude Paul 
---
 drivers/gpu/drm/nouveau/dispnv50/disp.c   | 15 ++-
 drivers/gpu/drm/nouveau/nouveau_encoder.h |  6 ++
 2 files changed, 8 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index cbcf3ef517dc..2c0749fac9dc 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -418,8 +418,7 @@ nv50_outp_atomic_check(struct drm_encoder *encoder,
 }
 
 struct nouveau_connector *
-nv50_outp_get_new_connector(struct nouveau_encoder *outp,
-   struct drm_atomic_state *state)
+nv50_outp_get_new_connector(struct drm_atomic_state *state, struct 
nouveau_encoder *outp)
 {
struct drm_connector *connector;
struct drm_connector_state *connector_state;
@@ -435,8 +434,7 @@ nv50_outp_get_new_connector(struct nouveau_encoder *outp,
 }
 
 struct nouveau_connector *
-nv50_outp_get_old_connector(struct nouveau_encoder *outp,
-   struct drm_atomic_state *state)
+nv50_outp_get_old_connector(struct drm_atomic_state *state, struct 
nouveau_encoder *outp)
 {
struct drm_connector *connector;
struct drm_connector_state *connector_state;
@@ -743,7 +741,7 @@ nv50_audio_enable(struct drm_encoder *encoder, struct 
drm_atomic_state *state,
 (0x0100 << nv_crtc->index),
};
 
-   nv_connector = nv50_outp_get_new_connector(nv_encoder, state);
+   nv_connector = nv50_outp_get_new_connector(state, nv_encoder);
if (!drm_detect_monitor_audio(nv_connector->edid))
return;
 
@@ -810,7 +808,7 @@ nv50_hdmi_enable(struct drm_encoder *encoder, struct 
drm_atomic_state *state,
int ret;
int size;
 
-   nv_connector = nv50_outp_get_new_connector(nv_encoder, state);
+   nv_connector = nv50_outp_get_new_connector(state, nv_encoder);
if (!drm_detect_hdmi_monitor(nv_connector->edid))
return;
 
@@ -1616,8 +1614,7 @@ nv50_sor_atomic_disable(struct drm_encoder *encoder, 
struct drm_atomic_state *st
 {
struct nouveau_encoder *nv_encoder = nouveau_encoder(encoder);
struct nouveau_crtc *nv_crtc = nouveau_crtc(nv_encoder->crtc);
-   struct nouveau_connector *nv_connector =
-   nv50_outp_get_old_connector(nv_encoder, state);
+   struct nouveau_connector *nv_connector = 
nv50_outp_get_old_connector(state, nv_encoder);
struct drm_dp_aux *aux = _connector->aux;
u8 pwr;
 
@@ -1664,7 +1661,7 @@ nv50_sor_atomic_enable(struct drm_encoder *encoder, 
struct drm_atomic_state *sta
u8 proto = NV507D_SOR_SET_CONTROL_PROTOCOL_CUSTOM;
u8 depth = NV837D_SOR_SET_CONTROL_PIXEL_DEPTH_DEFAULT;
 
-   nv_connector = nv50_outp_get_new_connector(nv_encoder, state);
+   nv_connector = nv50_outp_get_new_connector(state, nv_encoder);
nv_encoder->crtc = encoder->crtc;
 
if ((disp->disp->object.oclass == GT214_DISP ||
diff --git a/drivers/gpu/drm/nouveau/nouveau_encoder.h 
b/drivers/gpu/drm/nouveau/nouveau_encoder.h
index 21937f1c7dd9..0dea219a666e 100644
--- a/drivers/gpu/drm/nouveau/nouveau_encoder.h
+++ b/drivers/gpu/drm/nouveau/nouveau_encoder.h
@@ -141,11 +141,9 @@ enum drm_mode_status nv50_dp_mode_valid(struct 
drm_connector *,
unsigned *clock);
 
 struct nouveau_connector *
-nv50_outp_get_new_connector(struct nouveau_encoder *outp,
-   struct drm_atomic_state *state);
+nv50_outp_get_new_connector(struct drm_atomic_state *state, struct 
nouveau_encoder *outp);
 struct nouveau_connector *
-nv50_outp_get_old_connector(struct nouveau_encoder *outp,
-   struct drm_atomic_state *state);
+nv50_outp_get_old_connector(struct drm_atomic_state *state, struct 
nouveau_encoder *outp);
 
 int nv50_mstm_detect(struct nouveau_encoder *encoder);
 void nv50_mstm_remove(struct nv50_mstm *mstm);
-- 
2.28.0

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


[PATCH 2/8] drm/nouveau/kms/nv50-: Remove (nv_encoder->crtc) checks in ->disable callbacks

2020-11-13 Thread Lyude Paul
Noticed these in both the disable (which we'll be getting rid of in a
moment) and the atomic disable callbacks: both callback types check whether
or not there's actually a CRTC assigned to the given encoder. However, as
->atomic_disable and ->disable will never be called without a CRTC assigned
to the given encoder there's no point in this check. So just remove it.

Signed-off-by: Lyude Paul 
---
 drivers/gpu/drm/nouveau/dispnv50/disp.c | 37 -
 1 file changed, 17 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 36d6b6093d16..073ac66b2922 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -460,8 +460,8 @@ nv50_dac_disable(struct drm_encoder *encoder, struct 
drm_atomic_state *state)
struct nouveau_encoder *nv_encoder = nouveau_encoder(encoder);
struct nv50_core *core = nv50_disp(encoder->dev)->core;
const u32 ctrl = NVDEF(NV507D, DAC_SET_CONTROL, OWNER, NONE);
-   if (nv_encoder->crtc)
-   core->func->dac->ctrl(core, nv_encoder->or, ctrl, NULL);
+
+   core->func->dac->ctrl(core, nv_encoder->or, ctrl, NULL);
nv_encoder->crtc = NULL;
nv50_outp_release(nv_encoder);
 }
@@ -1620,28 +1620,25 @@ nv50_sor_disable(struct drm_encoder *encoder,
struct nouveau_crtc *nv_crtc = nouveau_crtc(nv_encoder->crtc);
struct nouveau_connector *nv_connector =
nv50_outp_get_old_connector(nv_encoder, state);
+   struct drm_dp_aux *aux = _connector->aux;
+   u8 pwr;
 
nv_encoder->crtc = NULL;
 
-   if (nv_crtc) {
-   struct drm_dp_aux *aux = _connector->aux;
-   u8 pwr;
+   if (nv_encoder->dcb->type == DCB_OUTPUT_DP) {
+   int ret = drm_dp_dpcd_readb(aux, DP_SET_POWER, );
 
-   if (nv_encoder->dcb->type == DCB_OUTPUT_DP) {
-   int ret = drm_dp_dpcd_readb(aux, DP_SET_POWER, );
-
-   if (ret == 0) {
-   pwr &= ~DP_SET_POWER_MASK;
-   pwr |=  DP_SET_POWER_D3;
-   drm_dp_dpcd_writeb(aux, DP_SET_POWER, pwr);
-   }
+   if (ret == 0) {
+   pwr &= ~DP_SET_POWER_MASK;
+   pwr |=  DP_SET_POWER_D3;
+   drm_dp_dpcd_writeb(aux, DP_SET_POWER, pwr);
}
-
-   nv_encoder->update(nv_encoder, nv_crtc->index, NULL, 0, 0);
-   nv50_audio_disable(encoder, nv_crtc);
-   nv50_hdmi_disable(_encoder->base.base, nv_crtc);
-   nv50_outp_release(nv_encoder);
}
+
+   nv_encoder->update(nv_encoder, nv_crtc->index, NULL, 0, 0);
+   nv50_audio_disable(encoder, nv_crtc);
+   nv50_hdmi_disable(_encoder->base.base, nv_crtc);
+   nv50_outp_release(nv_encoder);
 }
 
 static void
@@ -1877,8 +1874,8 @@ nv50_pior_disable(struct drm_encoder *encoder, struct 
drm_atomic_state *state)
struct nouveau_encoder *nv_encoder = nouveau_encoder(encoder);
struct nv50_core *core = nv50_disp(encoder->dev)->core;
const u32 ctrl = NVDEF(NV507D, PIOR_SET_CONTROL, OWNER, NONE);
-   if (nv_encoder->crtc)
-   core->func->pior->ctrl(core, nv_encoder->or, ctrl, NULL);
+
+   core->func->pior->ctrl(core, nv_encoder->or, ctrl, NULL);
nv_encoder->crtc = NULL;
nv50_outp_release(nv_encoder);
 }
-- 
2.28.0

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


[PATCH 3/8] drm/nouveau/kms/nv50-: Rename encoder->atomic_(enable|disable) callbacks

2020-11-13 Thread Lyude Paul
No functional changes, just change the function names to match the
callbacks they provide.

Signed-off-by: Lyude Paul 
---
 drivers/gpu/drm/nouveau/dispnv50/disp.c | 33 -
 1 file changed, 16 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 073ac66b2922..a47be145827e 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -455,7 +455,7 @@ nv50_outp_get_old_connector(struct nouveau_encoder *outp,
  * DAC
  */
 static void
-nv50_dac_disable(struct drm_encoder *encoder, struct drm_atomic_state *state)
+nv50_dac_atomic_disable(struct drm_encoder *encoder, struct drm_atomic_state 
*state)
 {
struct nouveau_encoder *nv_encoder = nouveau_encoder(encoder);
struct nv50_core *core = nv50_disp(encoder->dev)->core;
@@ -467,7 +467,7 @@ nv50_dac_disable(struct drm_encoder *encoder, struct 
drm_atomic_state *state)
 }
 
 static void
-nv50_dac_enable(struct drm_encoder *encoder, struct drm_atomic_state *state)
+nv50_dac_atomic_enable(struct drm_encoder *encoder, struct drm_atomic_state 
*state)
 {
struct nouveau_encoder *nv_encoder = nouveau_encoder(encoder);
struct nouveau_crtc *nv_crtc = nouveau_crtc(encoder->crtc);
@@ -525,8 +525,8 @@ nv50_dac_detect(struct drm_encoder *encoder, struct 
drm_connector *connector)
 static const struct drm_encoder_helper_funcs
 nv50_dac_help = {
.atomic_check = nv50_outp_atomic_check,
-   .atomic_enable = nv50_dac_enable,
-   .atomic_disable = nv50_dac_disable,
+   .atomic_enable = nv50_dac_atomic_enable,
+   .atomic_disable = nv50_dac_atomic_disable,
.detect = nv50_dac_detect
 };
 
@@ -1055,7 +1055,7 @@ nv50_dp_bpc_to_depth(unsigned int bpc)
 }
 
 static void
-nv50_msto_enable(struct drm_encoder *encoder, struct drm_atomic_state *state)
+nv50_msto_atomic_enable(struct drm_encoder *encoder, struct drm_atomic_state 
*state)
 {
struct nv50_head *head = nv50_head(encoder->crtc);
struct nv50_head_atom *armh = nv50_head_atom(head->base.base.state);
@@ -1101,7 +1101,7 @@ nv50_msto_enable(struct drm_encoder *encoder, struct 
drm_atomic_state *state)
 }
 
 static void
-nv50_msto_disable(struct drm_encoder *encoder, struct drm_atomic_state *state)
+nv50_msto_atomic_disable(struct drm_encoder *encoder, struct drm_atomic_state 
*state)
 {
struct nv50_msto *msto = nv50_msto(encoder);
struct nv50_mstc *mstc = msto->mstc;
@@ -1118,8 +1118,8 @@ nv50_msto_disable(struct drm_encoder *encoder, struct 
drm_atomic_state *state)
 
 static const struct drm_encoder_helper_funcs
 nv50_msto_help = {
-   .atomic_disable = nv50_msto_disable,
-   .atomic_enable = nv50_msto_enable,
+   .atomic_disable = nv50_msto_atomic_disable,
+   .atomic_enable = nv50_msto_atomic_enable,
.atomic_check = nv50_msto_atomic_check,
 };
 
@@ -1613,8 +1613,7 @@ nv50_sor_update(struct nouveau_encoder *nv_encoder, u8 
head,
 }
 
 static void
-nv50_sor_disable(struct drm_encoder *encoder,
-struct drm_atomic_state *state)
+nv50_sor_atomic_disable(struct drm_encoder *encoder, struct drm_atomic_state 
*state)
 {
struct nouveau_encoder *nv_encoder = nouveau_encoder(encoder);
struct nouveau_crtc *nv_crtc = nouveau_crtc(nv_encoder->crtc);
@@ -1642,7 +1641,7 @@ nv50_sor_disable(struct drm_encoder *encoder,
 }
 
 static void
-nv50_sor_enable(struct drm_encoder *encoder, struct drm_atomic_state *state)
+nv50_sor_atomic_enable(struct drm_encoder *encoder, struct drm_atomic_state 
*state)
 {
struct nouveau_encoder *nv_encoder = nouveau_encoder(encoder);
struct nouveau_crtc *nv_crtc = nouveau_crtc(encoder->crtc);
@@ -1747,8 +1746,8 @@ nv50_sor_enable(struct drm_encoder *encoder, struct 
drm_atomic_state *state)
 static const struct drm_encoder_helper_funcs
 nv50_sor_help = {
.atomic_check = nv50_outp_atomic_check,
-   .atomic_enable = nv50_sor_enable,
-   .atomic_disable = nv50_sor_disable,
+   .atomic_enable = nv50_sor_atomic_enable,
+   .atomic_disable = nv50_sor_atomic_disable,
 };
 
 static void
@@ -1869,7 +1868,7 @@ nv50_pior_atomic_check(struct drm_encoder *encoder,
 }
 
 static void
-nv50_pior_disable(struct drm_encoder *encoder, struct drm_atomic_state *state)
+nv50_pior_atomic_disable(struct drm_encoder *encoder, struct drm_atomic_state 
*state)
 {
struct nouveau_encoder *nv_encoder = nouveau_encoder(encoder);
struct nv50_core *core = nv50_disp(encoder->dev)->core;
@@ -1881,7 +1880,7 @@ nv50_pior_disable(struct drm_encoder *encoder, struct 
drm_atomic_state *state)
 }
 
 static void
-nv50_pior_enable(struct drm_encoder *encoder, struct drm_atomic_state *state)
+nv50_pior_atomic_enable(struct drm_encoder *encoder, struct drm_atomic_state 
*state)
 {
struct nouveau_encoder *nv_encoder = 

[PATCH 4/8] drm/nouveau/kms/nv50-: s/armh/asyh/ in nv50_msto_atomic_enable()

2020-11-13 Thread Lyude Paul
I have a strange dejavu feeling that I tried to submit a patch for this in
the past, but that it was rejected. I can't remember though, but I'm
further convinced this patch is the right thing to do anyway.

We label the to-be-committed head state in nv50_msto_atomic_enable() as
armh. Normally armh implies a state which is currently armed in hardware.
nv50_msto_atomic_enable() is called _after_ drm_atomic_swap_state()
however, but before the commit tail ends, which means that said state is
not actually armed on hardware.

As well - take note that this is the same convention followed in all of the
other atomic_enable() callbacks.

So, let's correct this to asyh.

Signed-off-by: Lyude Paul 
---
 drivers/gpu/drm/nouveau/dispnv50/disp.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index a47be145827e..cbcf3ef517dc 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -1058,7 +1058,7 @@ static void
 nv50_msto_atomic_enable(struct drm_encoder *encoder, struct drm_atomic_state 
*state)
 {
struct nv50_head *head = nv50_head(encoder->crtc);
-   struct nv50_head_atom *armh = nv50_head_atom(head->base.base.state);
+   struct nv50_head_atom *asyh = nv50_head_atom(head->base.base.state);
struct nv50_msto *msto = nv50_msto(encoder);
struct nv50_mstc *mstc = NULL;
struct nv50_mstm *mstm = NULL;
@@ -1080,8 +1080,7 @@ nv50_msto_atomic_enable(struct drm_encoder *encoder, 
struct drm_atomic_state *st
if (WARN_ON(!mstc))
return;
 
-   r = drm_dp_mst_allocate_vcpi(>mgr, mstc->port, armh->dp.pbn,
-armh->dp.tu);
+   r = drm_dp_mst_allocate_vcpi(>mgr, mstc->port, asyh->dp.pbn, 
asyh->dp.tu);
if (!r)
DRM_DEBUG_KMS("Failed to allocate VCPI\n");
 
@@ -1093,8 +1092,8 @@ nv50_msto_atomic_enable(struct drm_encoder *encoder, 
struct drm_atomic_state *st
else
proto = NV917D_SOR_SET_CONTROL_PROTOCOL_DP_B;
 
-   mstm->outp->update(mstm->outp, head->base.index, armh, proto,
-  nv50_dp_bpc_to_depth(armh->or.bpc));
+   mstm->outp->update(mstm->outp, head->base.index, asyh, proto,
+  nv50_dp_bpc_to_depth(asyh->or.bpc));
 
msto->mstc = mstc;
mstm->modified = true;
-- 
2.28.0

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


[PATCH 1/8] drm/nouveau/kms/nv50-: Use atomic encoder callbacks everywhere

2020-11-13 Thread Lyude Paul
It turns out that I forgot to go through and make sure that I converted all
encoder callbacks to use atomic_enable/atomic_disable(), so let's go and
actually do that.

Signed-off-by: Lyude Paul 
Cc: Kirill A. Shutemov 
Fixes: 09838c4efe9a ("drm/nouveau/kms: Search for encoders' connectors 
properly")
---
 drivers/gpu/drm/nouveau/dispnv50/disp.c | 29 -
 1 file changed, 14 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index b111fe24a06b..36d6b6093d16 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -455,7 +455,7 @@ nv50_outp_get_old_connector(struct nouveau_encoder *outp,
  * DAC
  */
 static void
-nv50_dac_disable(struct drm_encoder *encoder)
+nv50_dac_disable(struct drm_encoder *encoder, struct drm_atomic_state *state)
 {
struct nouveau_encoder *nv_encoder = nouveau_encoder(encoder);
struct nv50_core *core = nv50_disp(encoder->dev)->core;
@@ -467,7 +467,7 @@ nv50_dac_disable(struct drm_encoder *encoder)
 }
 
 static void
-nv50_dac_enable(struct drm_encoder *encoder)
+nv50_dac_enable(struct drm_encoder *encoder, struct drm_atomic_state *state)
 {
struct nouveau_encoder *nv_encoder = nouveau_encoder(encoder);
struct nouveau_crtc *nv_crtc = nouveau_crtc(encoder->crtc);
@@ -525,8 +525,8 @@ nv50_dac_detect(struct drm_encoder *encoder, struct 
drm_connector *connector)
 static const struct drm_encoder_helper_funcs
 nv50_dac_help = {
.atomic_check = nv50_outp_atomic_check,
-   .enable = nv50_dac_enable,
-   .disable = nv50_dac_disable,
+   .atomic_enable = nv50_dac_enable,
+   .atomic_disable = nv50_dac_disable,
.detect = nv50_dac_detect
 };
 
@@ -1055,7 +1055,7 @@ nv50_dp_bpc_to_depth(unsigned int bpc)
 }
 
 static void
-nv50_msto_enable(struct drm_encoder *encoder)
+nv50_msto_enable(struct drm_encoder *encoder, struct drm_atomic_state *state)
 {
struct nv50_head *head = nv50_head(encoder->crtc);
struct nv50_head_atom *armh = nv50_head_atom(head->base.base.state);
@@ -1101,7 +1101,7 @@ nv50_msto_enable(struct drm_encoder *encoder)
 }
 
 static void
-nv50_msto_disable(struct drm_encoder *encoder)
+nv50_msto_disable(struct drm_encoder *encoder, struct drm_atomic_state *state)
 {
struct nv50_msto *msto = nv50_msto(encoder);
struct nv50_mstc *mstc = msto->mstc;
@@ -1118,8 +1118,8 @@ nv50_msto_disable(struct drm_encoder *encoder)
 
 static const struct drm_encoder_helper_funcs
 nv50_msto_help = {
-   .disable = nv50_msto_disable,
-   .enable = nv50_msto_enable,
+   .atomic_disable = nv50_msto_disable,
+   .atomic_enable = nv50_msto_enable,
.atomic_check = nv50_msto_atomic_check,
 };
 
@@ -1645,8 +1645,7 @@ nv50_sor_disable(struct drm_encoder *encoder,
 }
 
 static void
-nv50_sor_enable(struct drm_encoder *encoder,
-   struct drm_atomic_state *state)
+nv50_sor_enable(struct drm_encoder *encoder, struct drm_atomic_state *state)
 {
struct nouveau_encoder *nv_encoder = nouveau_encoder(encoder);
struct nouveau_crtc *nv_crtc = nouveau_crtc(encoder->crtc);
@@ -1873,7 +1872,7 @@ nv50_pior_atomic_check(struct drm_encoder *encoder,
 }
 
 static void
-nv50_pior_disable(struct drm_encoder *encoder)
+nv50_pior_disable(struct drm_encoder *encoder, struct drm_atomic_state *state)
 {
struct nouveau_encoder *nv_encoder = nouveau_encoder(encoder);
struct nv50_core *core = nv50_disp(encoder->dev)->core;
@@ -1885,7 +1884,7 @@ nv50_pior_disable(struct drm_encoder *encoder)
 }
 
 static void
-nv50_pior_enable(struct drm_encoder *encoder)
+nv50_pior_enable(struct drm_encoder *encoder, struct drm_atomic_state *state)
 {
struct nouveau_encoder *nv_encoder = nouveau_encoder(encoder);
struct nouveau_crtc *nv_crtc = nouveau_crtc(encoder->crtc);
@@ -1921,14 +1920,14 @@ nv50_pior_enable(struct drm_encoder *encoder)
}
 
core->func->pior->ctrl(core, nv_encoder->or, ctrl, asyh);
-   nv_encoder->crtc = encoder->crtc;
+   nv_encoder->crtc = _crtc->base;
 }
 
 static const struct drm_encoder_helper_funcs
 nv50_pior_help = {
.atomic_check = nv50_pior_atomic_check,
-   .enable = nv50_pior_enable,
-   .disable = nv50_pior_disable,
+   .atomic_enable = nv50_pior_enable,
+   .atomic_disable = nv50_pior_disable,
 };
 
 static void
-- 
2.28.0

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


Re: [PATCH v3 0/5] console: Miscellaneous clean-ups, do not use FNTCHARCNT() in fbcon.c

2020-11-13 Thread Greg Kroah-Hartman
On Fri, Nov 13, 2020 at 10:16:33PM +0100, Daniel Vetter wrote:
> On Thu, Nov 12, 2020 at 07:02:21AM -0500, Peilin Ye wrote:
> > Hi all,
> > 
> > This is a collection of some miscellaneous clean-ups for fbcon and some
> > console drivers. Since v2, I rebased them on linux-next, added some
> > Reviewed-by: tags from Daniel and Greg, and rewrote the commit messages as
> > suggested by Jiri. See [1] for v2 links.
> > 
> > It does the following:
> > 
> >   - Garbage collect KD_FONT_OP_COPY callbacks since we disabled it
> > recently. Mark it as obsolete.
> >   - Delete dummy con_font_op() callbacks. (Reviewed by Greg)
> > 
> >   - Add a charcount field to our new font descriptor, `struct font_desc`.
> > (Reviewed by Daniel)
> >   - Do not use a hard-coded 256 for built-in font charcount in
> > console/sticore.c, use the new charcount field of `struct font_desc`
> > instead. (Reviewed by Daniel)
> >   - Similarly, in fbcon.c, avoid using the magic negative-indexing macro,
> > FNTCHARCNT(). Set `vc->vc_font.charcount` properly and always use that
> > instead.
> > 
> > Daniel, hopefully [5/5] removes FNTCHARCNT() for ever, but I have not
> > tested it sufficiently yet. I remember you mentioned elsewhere that
> > "fbtest.c" is insufficient for framebuffer testing, then how should we
> > test it? The first 4 patches should be fine.
> > 
> > Please reference commit messages for more information. Thank you!
> > 
> > [1] v2 links:
> > 
> > 2/5: 
> > https://lore.kernel.org/lkml/c5563eeea36aae7bd72ea2e985bc610d585ece40.1604306433.git.yepeilin...@gmail.com/
> > 3/5: 
> > https://lore.kernel.org/lkml/20201028060533.1206307-1-yepeilin...@gmail.com/
> > 4/5: 
> > https://lore.kernel.org/lkml/c38042bbf5c9777c84900d56c09f3c156b32af48.1603788512.git.yepeilin...@gmail.com/
> > 5/5: 
> > https://lore.kernel.org/lkml/20201028155139.1220549-1-yepeilin...@gmail.com/
> > 
> > Peilin Ye (5):
> >   console: Delete unused con_font_copy() callback implementations
> >   console: Delete dummy con_font_set() and con_font_default() callback 
> > implementations
> >   Fonts: Add charcount field to font_desc
> >   parisc/sticore: Avoid hard-coding built-in font charcount
> >   fbcon: Avoid using FNTCHARCNT() and hard-coded built-in font charcount
> 
> Patches all look good to me, if Greg is ok with me applying the entire
> pile to drm-misc-next I'll do that next week.

Yes, please do!

Reviewed-by: Greg Kroah-Hartman 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 02/30] include: drm: drm_atomic: Artificially use 'crtc' to avoid 'not used' warning

2020-11-13 Thread Lee Jones
On Fri, 13 Nov 2020, 21:31 Daniel Vetter,  wrote:

> On Fri, Nov 13, 2020 at 9:53 PM Lee Jones  wrote:
> >
> >
> >
> > On Fri, 13 Nov 2020, 20:50 Daniel Vetter,  wrote:
> >>
> >> On Thu, Nov 12, 2020 at 09:25:16PM +0100, Sam Ravnborg wrote:
> >> > Hi Lee,
> >> >
> >> > On Thu, Nov 12, 2020 at 07:00:11PM +, Lee Jones wrote:
> >> > > The precedent has already been set by other macros in the same file.
> >> > >
> >> > > Fixes the following W=1 kernel build warning(s):
> >> > >
> >> > >  drivers/gpu/drm/vkms/vkms_drv.c:55:19: warning: variable ‘crtc’
> set but not used [-Wunused-but-set-variable]
> >> > >  55 | struct drm_crtc *crtc;
> >> > >  | ^~~~
> >> > >
> >> > > Cc: Maarten Lankhorst 
> >> > > Cc: Maxime Ripard 
> >> > > Cc: Thomas Zimmermann 
> >> > > Cc: David Airlie 
> >> > > Cc: Daniel Vetter 
> >> > > Cc: Rob Clark 
> >> > > Cc: dri-devel@lists.freedesktop.org
> >> > > Signed-off-by: Lee Jones 
> >> >
> >> > Also applied to drm-misc-next.
> >> > This was the last patch from this batch I will process.
> >> > The others are left for the maintainers to pick up.
> >>
> >> btw for patches that maintainers don't pick up, the usual process is
> that
> >> we give them 2 weeks, then just mass apply. Now you're producing a lot
> of
> >> patches, too much for me to keep track, so please just ping me with a
> >> resend for those that expired and I'll go through and pick them all up.
> >
> >
> > That's great Daniel. Thanks for your support.
> >
> > I can do one better than that.
> >
> > Would a pull-request suit you?
>
> We have a few trees going on, and your patches are landing through all
> kinds of them. So this might be more coordination pain. If you can
> exclude patches for the separately and usually fairly well maintained
> drivers out of the pull it should work (drm/amd, drm/radeon, drm/i915,
> drm/nouveau, drm/msm and drm/omapdrm probably the usual ones).
>
> Or you just send the next pile and we'll see.
>
> Also I guess I can't really interest you in commit rights so this
> patch bombs get off my back again? :-)
>

What does that mean? Merge my own patches?

Not sure how that works with your group maintenance setup.

Is it just a `git push`?

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


Re: [PATCH 02/30] include: drm: drm_atomic: Artificially use 'crtc' to avoid 'not used' warning

2020-11-13 Thread Daniel Vetter
On Fri, Nov 13, 2020 at 9:53 PM Lee Jones  wrote:
>
>
>
> On Fri, 13 Nov 2020, 20:50 Daniel Vetter,  wrote:
>>
>> On Thu, Nov 12, 2020 at 09:25:16PM +0100, Sam Ravnborg wrote:
>> > Hi Lee,
>> >
>> > On Thu, Nov 12, 2020 at 07:00:11PM +, Lee Jones wrote:
>> > > The precedent has already been set by other macros in the same file.
>> > >
>> > > Fixes the following W=1 kernel build warning(s):
>> > >
>> > >  drivers/gpu/drm/vkms/vkms_drv.c:55:19: warning: variable ‘crtc’ set but 
>> > > not used [-Wunused-but-set-variable]
>> > >  55 | struct drm_crtc *crtc;
>> > >  | ^~~~
>> > >
>> > > Cc: Maarten Lankhorst 
>> > > Cc: Maxime Ripard 
>> > > Cc: Thomas Zimmermann 
>> > > Cc: David Airlie 
>> > > Cc: Daniel Vetter 
>> > > Cc: Rob Clark 
>> > > Cc: dri-devel@lists.freedesktop.org
>> > > Signed-off-by: Lee Jones 
>> >
>> > Also applied to drm-misc-next.
>> > This was the last patch from this batch I will process.
>> > The others are left for the maintainers to pick up.
>>
>> btw for patches that maintainers don't pick up, the usual process is that
>> we give them 2 weeks, then just mass apply. Now you're producing a lot of
>> patches, too much for me to keep track, so please just ping me with a
>> resend for those that expired and I'll go through and pick them all up.
>
>
> That's great Daniel. Thanks for your support.
>
> I can do one better than that.
>
> Would a pull-request suit you?

We have a few trees going on, and your patches are landing through all
kinds of them. So this might be more coordination pain. If you can
exclude patches for the separately and usually fairly well maintained
drivers out of the pull it should work (drm/amd, drm/radeon, drm/i915,
drm/nouveau, drm/msm and drm/omapdrm probably the usual ones).

Or you just send the next pile and we'll see.

Also I guess I can't really interest you in commit rights so this
patch bombs get off my back again? :-)

Cheers, 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 v3 0/5] console: Miscellaneous clean-ups, do not use FNTCHARCNT() in fbcon.c

2020-11-13 Thread Daniel Vetter
On Thu, Nov 12, 2020 at 07:02:21AM -0500, Peilin Ye wrote:
> Hi all,
> 
> This is a collection of some miscellaneous clean-ups for fbcon and some
> console drivers. Since v2, I rebased them on linux-next, added some
> Reviewed-by: tags from Daniel and Greg, and rewrote the commit messages as
> suggested by Jiri. See [1] for v2 links.
> 
> It does the following:
> 
>   - Garbage collect KD_FONT_OP_COPY callbacks since we disabled it
> recently. Mark it as obsolete.
>   - Delete dummy con_font_op() callbacks. (Reviewed by Greg)
> 
>   - Add a charcount field to our new font descriptor, `struct font_desc`.
> (Reviewed by Daniel)
>   - Do not use a hard-coded 256 for built-in font charcount in
> console/sticore.c, use the new charcount field of `struct font_desc`
> instead. (Reviewed by Daniel)
>   - Similarly, in fbcon.c, avoid using the magic negative-indexing macro,
> FNTCHARCNT(). Set `vc->vc_font.charcount` properly and always use that
> instead.
> 
> Daniel, hopefully [5/5] removes FNTCHARCNT() for ever, but I have not
> tested it sufficiently yet. I remember you mentioned elsewhere that
> "fbtest.c" is insufficient for framebuffer testing, then how should we
> test it? The first 4 patches should be fine.
> 
> Please reference commit messages for more information. Thank you!
> 
> [1] v2 links:
> 
> 2/5: 
> https://lore.kernel.org/lkml/c5563eeea36aae7bd72ea2e985bc610d585ece40.1604306433.git.yepeilin...@gmail.com/
> 3/5: 
> https://lore.kernel.org/lkml/20201028060533.1206307-1-yepeilin...@gmail.com/
> 4/5: 
> https://lore.kernel.org/lkml/c38042bbf5c9777c84900d56c09f3c156b32af48.1603788512.git.yepeilin...@gmail.com/
> 5/5: 
> https://lore.kernel.org/lkml/20201028155139.1220549-1-yepeilin...@gmail.com/
> 
> Peilin Ye (5):
>   console: Delete unused con_font_copy() callback implementations
>   console: Delete dummy con_font_set() and con_font_default() callback 
> implementations
>   Fonts: Add charcount field to font_desc
>   parisc/sticore: Avoid hard-coding built-in font charcount
>   fbcon: Avoid using FNTCHARCNT() and hard-coded built-in font charcount

Patches all look good to me, if Greg is ok with me applying the entire
pile to drm-misc-next I'll do that next week.

Thanks, Daniel

> 
>  drivers/usb/misc/sisusbvga/sisusb_con.c | 21 
>  drivers/video/console/dummycon.c| 20 
>  drivers/video/console/sticore.c |  8 +--
>  drivers/video/fbdev/core/fbcon.c| 68 -
>  drivers/video/fbdev/core/fbcon_rotate.c |  3 +-
>  drivers/video/fbdev/core/tileblit.c |  4 +-
>  include/linux/console.h |  1 -
>  include/linux/font.h|  1 +
>  include/uapi/linux/kd.h |  2 +-
>  lib/fonts/font_10x18.c  |  1 +
>  lib/fonts/font_6x10.c   |  1 +
>  lib/fonts/font_6x11.c   |  1 +
>  lib/fonts/font_6x8.c|  1 +
>  lib/fonts/font_7x14.c   |  1 +
>  lib/fonts/font_8x16.c   |  1 +
>  lib/fonts/font_8x8.c|  1 +
>  lib/fonts/font_acorn_8x8.c  |  1 +
>  lib/fonts/font_mini_4x6.c   |  1 +
>  lib/fonts/font_pearl_8x8.c  |  1 +
>  lib/fonts/font_sun12x22.c   |  1 +
>  lib/fonts/font_sun8x16.c|  1 +
>  lib/fonts/font_ter16x32.c   |  1 +
>  22 files changed, 42 insertions(+), 99 deletions(-)
> 
> -- 
> 2.25.1
> 

-- 
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/8] drm: Introduce an atomic_commit_setup function

2020-11-13 Thread Daniel Vetter
On Fri, Nov 13, 2020 at 04:29:49PM +0100, Maxime Ripard wrote:
> Private objects storing a state shared across all CRTCs need to be
> carefully handled to avoid a use-after-free issue.
> 
> The proper way to do this to track all the commits using that shared
> state and wait for the previous commits to be done before going on with
> the current one to avoid the reordering of commits that could occur.
> 
> However, this commit setup needs to be done after
> drm_atomic_helper_setup_commit(), because before the CRTC commit
> structure hasn't been allocated before, and before the workqueue is
> scheduled, because we would be potentially reordered already otherwise.
> 
> That means that drivers currently have to roll their own
> drm_atomic_helper_commit() function, even though it would be identical
> if not for the commit setup.
> 
> Let's introduce a hook to do so that would be called as part of
> drm_atomic_helper_commit, allowing us to reuse the atomic helpers.
> 
> Suggested-by: Daniel Vetter 
> Signed-off-by: Maxime Ripard 

Should probably wait with merging until we have the entire vc4 user ready
too. And I think the kerneldoc needs to be further improved, see
suggestions below.

> ---
>  drivers/gpu/drm/drm_atomic_helper.c  |  6 ++
>  include/drm/drm_modeset_helper_vtables.h | 18 ++
>  2 files changed, 24 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index ddd0e3239150..7d69c7844dfc 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -2083,8 +2083,11 @@ int drm_atomic_helper_setup_commit(struct 
> drm_atomic_state *state,
>   struct drm_plane *plane;
>   struct drm_plane_state *old_plane_state, *new_plane_state;
>   struct drm_crtc_commit *commit;
> + const struct drm_mode_config_helper_funcs *funcs;
>   int i, ret;
>  
> + funcs = state->dev->mode_config.helper_private;
> +
>   for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state, 
> new_crtc_state, i) {
>   commit = kzalloc(sizeof(*commit), GFP_KERNEL);
>   if (!commit)
> @@ -2169,6 +2172,9 @@ int drm_atomic_helper_setup_commit(struct 
> drm_atomic_state *state,
>   new_plane_state->commit = drm_crtc_commit_get(commit);
>   }
>  
> + if (funcs && funcs->atomic_commit_setup)
> + return funcs->atomic_commit_setup(state);
> +
>   return 0;
>  }
>  EXPORT_SYMBOL(drm_atomic_helper_setup_commit);
> diff --git a/include/drm/drm_modeset_helper_vtables.h 
> b/include/drm/drm_modeset_helper_vtables.h
> index f2de050085be..56470baf0513 100644
> --- a/include/drm/drm_modeset_helper_vtables.h
> +++ b/include/drm/drm_modeset_helper_vtables.h
> @@ -1396,6 +1396,24 @@ struct drm_mode_config_helper_funcs {
>* drm_atomic_helper_commit_tail().
>*/
>   void (*atomic_commit_tail)(struct drm_atomic_state *state);
> +
> + /**
> +  * @atomic_commit_setup:
> +  *
> +  * This hook is used by the default atomic_commit() hook implemented in
> +  * drm_atomic_helper_commit() together with the nonblocking helpers (see
> +  * drm_atomic_helper_setup_commit()) to extend the DRM commit setup. It

I think a link from drm_atomic_helper_setup_commit to this new hook here
would be useful too, maybe together with a note that waiting for these
additional synchronization points can be done at the start of
atomic_commit_tail.

> +  * is not used by the atomic helpers.
> +  *
> +  * This function is called at the end of
> +  * drm_atomic_helper_setup_commit(), so once the commit has been
> +  * properly setup across the generic DRM object states. It allows
> +  * drivers to do some additional commit tracking that isn't related to a
> +  * CRTC, plane or connector, typically a private object.
> +  *
> +  * This hook is optional.
> +  */
> + int (*atomic_commit_setup)(struct drm_atomic_state *state);

I think the kerneldoc for drm_private_obj should also explain when it is
necessary to use this, and when not:

- when the private state is a tied to an existing drm object (drm_crtc,
  drm_plane or drm_crtc) and never moves, then sufficient synchronization
  is already guaranteed by that superior object. This could even hold
  when the private object can be e.g. reassigned between planes, but
  always stays on the same crtc.

- if the private state object can be globally reassigned, then
  drm_crtc_commit synchronization points need to be set up in
  ->atomic_commit_setup and waited on as the first step in
  ->atomic_commit_tail


Also I just realized that a drm_private_state->obj backpointer to
drm_private_obj might be rather useful. Or at least more consistent with
all the other state objects.

Cheers, Daniel


>  };
>  
>  #endif
> -- 
> 2.28.0
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel 

Re: [PATCH 02/30] include: drm: drm_atomic: Artificially use 'crtc' to avoid 'not used' warning

2020-11-13 Thread Lee Jones
On Fri, 13 Nov 2020, 20:50 Daniel Vetter,  wrote:

> On Thu, Nov 12, 2020 at 09:25:16PM +0100, Sam Ravnborg wrote:
> > Hi Lee,
> >
> > On Thu, Nov 12, 2020 at 07:00:11PM +, Lee Jones wrote:
> > > The precedent has already been set by other macros in the same file.
> > >
> > > Fixes the following W=1 kernel build warning(s):
> > >
> > >  drivers/gpu/drm/vkms/vkms_drv.c:55:19: warning: variable ‘crtc’ set
> but not used [-Wunused-but-set-variable]
> > >  55 | struct drm_crtc *crtc;
> > >  | ^~~~
> > >
> > > Cc: Maarten Lankhorst 
> > > Cc: Maxime Ripard 
> > > Cc: Thomas Zimmermann 
> > > Cc: David Airlie 
> > > Cc: Daniel Vetter 
> > > Cc: Rob Clark 
> > > Cc: dri-devel@lists.freedesktop.org
> > > Signed-off-by: Lee Jones 
> >
> > Also applied to drm-misc-next.
> > This was the last patch from this batch I will process.
> > The others are left for the maintainers to pick up.
>
> btw for patches that maintainers don't pick up, the usual process is that
> we give them 2 weeks, then just mass apply. Now you're producing a lot of
> patches, too much for me to keep track, so please just ping me with a
> resend for those that expired and I'll go through and pick them all up.
>

That's great Daniel. Thanks for your support.

I can do one better than that.

Would a pull-request suit you?

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


Re: [PATCH v2 1/8] drm: Add dummy page per device or GEM object

2020-11-13 Thread Andrey Grodzovsky


On 6/22/20 1:50 PM, Daniel Vetter wrote:

On Mon, Jun 22, 2020 at 7:45 PM Christian König
 wrote:

Am 22.06.20 um 16:32 schrieb Andrey Grodzovsky:

On 6/22/20 9:18 AM, Christian König wrote:

Am 21.06.20 um 08:03 schrieb Andrey Grodzovsky:

Will be used to reroute CPU mapped BO's page faults once
device is removed.

Signed-off-by: Andrey Grodzovsky 
---
   drivers/gpu/drm/drm_file.c  |  8 
   drivers/gpu/drm/drm_prime.c | 10 ++
   include/drm/drm_file.h  |  2 ++
   include/drm/drm_gem.h   |  2 ++
   4 files changed, 22 insertions(+)

diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index c4c704e..67c0770 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -188,6 +188,12 @@ struct drm_file *drm_file_alloc(struct
drm_minor *minor)
   goto out_prime_destroy;
   }
   +file->dummy_page = alloc_page(GFP_KERNEL | __GFP_ZERO);
+if (!file->dummy_page) {
+ret = -ENOMEM;
+goto out_prime_destroy;
+}
+
   return file;
 out_prime_destroy:
@@ -284,6 +290,8 @@ void drm_file_free(struct drm_file *file)
   if (dev->driver->postclose)
   dev->driver->postclose(dev, file);
   +__free_page(file->dummy_page);
+
   drm_prime_destroy_file_private(>prime);
 WARN_ON(!list_empty(>event_list));
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 1de2cde..c482e9c 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -335,6 +335,13 @@ int drm_gem_prime_fd_to_handle(struct
drm_device *dev,
 ret = drm_prime_add_buf_handle(_priv->prime,
   dma_buf, *handle);
+
+if (!ret) {
+obj->dummy_page = alloc_page(GFP_KERNEL | __GFP_ZERO);
+if (!obj->dummy_page)
+ret = -ENOMEM;
+}
+

While the per file case still looks acceptable this is a clear NAK
since it will massively increase the memory needed for a prime
exported object.

I think that this is quite overkill in the first place and for the
hot unplug case we can just use the global dummy page as well.

Christian.


Global dummy page is good for read access, what do you do on write
access ? My first approach was indeed to map at first global dummy
page as read only and mark the vma->vm_flags as !VM_SHARED assuming
that this would trigger Copy On Write flow in core mm
(https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Felixir.bootlin.com%2Flinux%2Fv5.7-rc7%2Fsource%2Fmm%2Fmemory.c%23L3977data=02%7C01%7CAndrey.Grodzovsky%40amd.com%7C3753451d037544e7495408d816d4c4ee%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637284450384586120sdata=ZpRaQgqA5K4jRfidOiedey0AleeYQ97WNUkGA29ERA0%3Dreserved=0)
on the next page fault to same address triggered by a write access but
then i realized a new COW page will be allocated for each such mapping
and this is much more wasteful then having a dedicated page per GEM
object.

Yeah, but this is only for a very very small corner cases. What we need
to prevent is increasing the memory usage during normal operation to much.

Using memory during the unplug is completely unproblematic because we
just released quite a bunch of it by releasing all those system memory
buffers.

And I'm pretty sure that COWed pages are correctly accounted towards the
used memory of a process.

So I think if that approach works as intended and the COW pages are
released again on unmapping it would be the perfect solution to the problem.

Daniel what do you think?

If COW works, sure sounds reasonable. And if we can make sure we
managed to drop all the system allocations (otherwise suddenly 2x
memory usage, worst case). But I have no idea whether we can
retroshoehorn that into an established vma, you might have fun stuff
like a mkwrite handler there (which I thought is the COW handler
thing, but really no idea).

If we need to massively change stuff then I think rw dummy page,
allocated on first fault after hotunplug (maybe just make it one per
object, that's simplest) seems like the much safer option. Much less
code that can go wrong.
-Daniel



Regarding COW, i was looking into how to properly implement it from within the 
fault handler (i.e. ttm_bo_vm_fault)
and the main obstacle I hit is that of exclusive access to the vm_area_struct, i 
need to be able to modify
vma->vm_flags (and vm_page_prot)  to remove VM_SHARED bit so COW can be 
triggered on subsequent write access

fault (here https://elixir.bootlin.com/linux/latest/source/mm/memory.c#L4128)
but core mm takes only read side mm_sem (here for example 
https://elixir.bootlin.com/linux/latest/source/drivers/iommu/amd/iommu_v2.c#L488)
and so I am not supposed to modify vm_area_struct in this case. I am not sure if 
it's legit to write lock tthe mm_sem from this point.
I found some discussions about this here 
http://lkml.iu.edu/hypermail/linux/kernel/1909.1/02754.html but it wasn't really 
clear to me

what's the solution.

In any case, seems to me that easier and more memory 

Re: [PATCH 02/30] include: drm: drm_atomic: Artificially use 'crtc' to avoid 'not used' warning

2020-11-13 Thread Daniel Vetter
On Thu, Nov 12, 2020 at 09:25:16PM +0100, Sam Ravnborg wrote:
> Hi Lee,
> 
> On Thu, Nov 12, 2020 at 07:00:11PM +, Lee Jones wrote:
> > The precedent has already been set by other macros in the same file.
> > 
> > Fixes the following W=1 kernel build warning(s):
> > 
> >  drivers/gpu/drm/vkms/vkms_drv.c:55:19: warning: variable ‘crtc’ set but 
> > not used [-Wunused-but-set-variable]
> >  55 | struct drm_crtc *crtc;
> >  | ^~~~
> > 
> > Cc: Maarten Lankhorst 
> > Cc: Maxime Ripard 
> > Cc: Thomas Zimmermann 
> > Cc: David Airlie 
> > Cc: Daniel Vetter 
> > Cc: Rob Clark 
> > Cc: dri-devel@lists.freedesktop.org
> > Signed-off-by: Lee Jones 
> 
> Also applied to drm-misc-next.
> This was the last patch from this batch I will process.
> The others are left for the maintainers to pick up.

btw for patches that maintainers don't pick up, the usual process is that
we give them 2 weeks, then just mass apply. Now you're producing a lot of
patches, too much for me to keep track, so please just ping me with a
resend for those that expired and I'll go through and pick them all up.

Cheers, Daniel

> 
>   Sam
> ___
> 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 RESEND 2/2] drm/drm_vblank: set the dma-fence timestamp during send_vblank_event

2020-11-13 Thread Daniel Vetter
On Thu, Nov 12, 2020 at 10:27:23AM -0800, Veera Sundaram Sankaran wrote:
> The explicit out-fences in crtc are signaled as part of vblank event,
> indicating all framebuffers present on the Atomic Commit request are
> scanned out on the screen. Though the fence signal and the vblank event
> notification happens at the same time, triggered by the same hardware
> vsync event, the timestamp set in both are different. With drivers
> supporting precise vblank timestamp the difference between the two
> timestamps would be even higher. This might have an impact on use-mode
> frameworks using these fence timestamps for purposes other than simple
> buffer usage. For instance, the Android framework uses the retire-fences
> as an alternative to vblank when frame-updates are in progress Set the
> fence timestamp during send vblank event to avoid discrepancies.

I think a reference to the exact source code in android that does this
would be really useful. Something in drm_hwcomposer or whatever is doing
this.

Aside from documenting why we want to do this I think this all looks
reasonable.
-Daniel

> 
> Signed-off-by: Veera Sundaram Sankaran 
> ---
>  drivers/gpu/drm/drm_vblank.c | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> index b18e1ef..b38e50c 100644
> --- a/drivers/gpu/drm/drm_vblank.c
> +++ b/drivers/gpu/drm/drm_vblank.c
> @@ -24,6 +24,7 @@
>   * OTHER DEALINGS IN THE SOFTWARE.
>   */
>  
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -999,6 +1000,14 @@ static void send_vblank_event(struct drm_device *dev,
>   e->event.seq.time_ns = ktime_to_ns(now);
>   break;
>   }
> +
> + /*
> +  * update fence timestamp with the same vblank timestamp as both
> +  * are signaled by the same event
> +  */
> + if (e->base.fence)
> + e->base.fence->timestamp = now;
> +
>   trace_drm_vblank_event_delivered(e->base.file_priv, e->pipe, seq);
>   drm_send_event_locked(dev, >base);
>  }
> -- 
> 2.7.4
> 

-- 
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/tegra: output: Do not put OF node twice

2020-11-13 Thread Thierry Reding
From: Thierry Reding 

The original patch for commit 3d2e7aec7013 ("drm/tegra: output: Don't
leak OF node on error") contained this hunk, but it was accidentally
dropped during conflict resolution. This causes use-after-free errors
on devices that use an I2C controller for HDMI DDC/CI on Tegra210 and
later.

Fixes: 3d2e7aec7013 ("drm/tegra: output: Don't leak OF node on error")
Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/tegra/output.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/tegra/output.c b/drivers/gpu/drm/tegra/output.c
index 5a4fd0dbf4cf..47d26b5d9945 100644
--- a/drivers/gpu/drm/tegra/output.c
+++ b/drivers/gpu/drm/tegra/output.c
@@ -129,7 +129,6 @@ int tegra_output_probe(struct tegra_output *output)
 
if (!output->ddc) {
err = -EPROBE_DEFER;
-   of_node_put(ddc);
return err;
}
}
-- 
2.29.2

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


Re: [PATCH v10 6/6] dma-buf: Document that dma-buf size is fixed

2020-11-13 Thread Daniel Vetter
On Thu, Nov 12, 2020 at 09:25:14AM -0400, Jason Gunthorpe wrote:
> On Wed, Nov 11, 2020 at 05:33:23PM +0100, Daniel Vetter wrote:
> > On Tue, Nov 10, 2020 at 01:41:17PM -0800, Jianxin Xiong wrote:
> > > The fact that the size of dma-buf is invariant over the lifetime of the
> > > buffer is mentioned in the comment of 'dma_buf_ops.mmap', but is not
> > > documented at where the info is defined. Add the missing documentation.
> > > 
> > > Signed-off-by: Jianxin Xiong 
> > 
> > Applied to drm-misc-next, thanks for your patch. For the preceeding
> > dma-buf patch I'll wait for more review/acks before I apply it. Ack from
> > Jason might also be good, since looks like this dma_virt_ops is only used
> > in rdma.
> 
> We are likely to delete it entirely this cycle, Christoph already has
> a patch series to do it:
> 
> https://patchwork.kernel.org/project/linux-rdma/list/?series=379277
> 
> So, lets just forget about it

I can get behind that :-) Also I realized that even when we need it,
probably best if you merge it to avoid a partially broken feature in the
rdma tree. So not my problem anyway ...

Cheers, 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 v5 0/7] dma-buf: Performance improvements for system heap & a system-uncached implementation

2020-11-13 Thread Daniel Vetter
On Thu, Nov 12, 2020 at 08:11:02PM -0800, John Stultz wrote:
> On Thu, Nov 12, 2020 at 1:32 AM Daniel Vetter  wrote:
> > On Thu, Nov 12, 2020 at 11:09:04AM +0530, Sumit Semwal wrote:
> > > On Tue, 10 Nov 2020 at 09:19, John Stultz  wrote:
> > > >
> > > > Hey All,
> > > >   So just wanted to send my last revision of my patch series
> > > > of performance optimizations to the dma-buf system heap.
> > >
> > > Thanks very much for your patches - I think the first 5 patches look good 
> > > to me.
> > >
> > > I know there was a bit of discussion over adding a new system-uncached
> > > heap v/s using a flag to identify that; I think I prefer the separate
> > > heap idea, but lets ask one last time if any one else has any real
> > > objections to it.
> > >
> > > Daniel, Christian: any comments from your side on this?
> >
> > I do wonder a bit where the userspace stack for this all is, since tuning
> > allocators without a full stack is fairly pointless. dma-buf heaps is a
> > bit in a limbo situation here it feels like.
> 
> As mentioned in the system-uncached patch:
> Pending opensource users of this code include:
> * AOSP HiKey960 gralloc:
>   - https://android-review.googlesource.com/c/device/linaro/hikey/+/1399519
>   - Visibly improves performance over the system heap
> * AOSP Codec2 (possibly, needs more review):
>   - 
> https://android-review.googlesource.com/c/platform/frameworks/av/+/1360640/17/media/codec2/vndk/C2DmaBufAllocator.cpp#325
> 
> Additionally both the HiKey, HiKey960 grallocs  and Codec2 are already
> able to use the current dmabuf heaps instead of ION.
> 
> So I'm not sure what you mean by limbo, other than it being in a
> transition state where the interface is upstream and we're working on
> moving vendors to it from ION (which is staged to be dropped in 5.11).
> Part of that work is making sure we don't regress the performance
> expectations.

The mesa thing below, since if we test this with some downstream kernel
drivers or at least non-mesa userspace I'm somewhat worried we're just
creating a nice split world between the android gfx world and the
mesa/linux desktop gfx world.

But then that's kinda how android rolls, so *shrug*

> > Plus I'm vary of anything related to leaking this kind of stuff beyond the
> > dma-api because dma api maintainers don't like us doing that. But
> > personally no concern on that front really, gpus need this. It's just that
> > we do need solid justification I think if we land this. Hence back to
> > first point.
> >
> > Ideally first point comes in the form of benchmarking on android together
> > with a mesa driver (or mesa + some v4l driver or whatever it takes to
> > actually show the benefits, I have no idea).
> 
> Tying it with mesa is a little tough as the grallocs for mesa devices
> usually use gbm (gralloc.gbm or gralloc.minigbm). Swapping the
> allocation path for dmabuf heaps there gets a little complex as last I
> tried that (when trying to get HiKey working with Lima graphics, as
> gbm wouldn't allocate the contiguous buffers required by the display),
> I ran into issues with the drm_hwcomposer and mesa expecting the gbm
> private handle metadata in the buffer when it was passed in.
> 
> But I might take a look at it again. I got a bit lost digging through
> the mesa gbm allocation paths last time.
> 
> I'll also try to see if I can find a benchmark for the codec2 code
> (using dmabuf heaps with and without the uncached heap) on on db845c
> (w/ mesa), as that is already working and I suspect that might be
> close to what you're looking for.

tbh I think trying to push for this long term is the best we can hope for.

Media is also a lot more *meh* since it's deeply fragmented and a lot less
of it upstream than on the gles/display side.

I think confirming that this at least doesn't horrible blow up on a
gralloc/gbm+mesa stack would be useful I think.
-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 35/40] drm/msm/disp/mdp5/mdp5_kms: Make local functions 'mdp5_{en, dis}able()' static

2020-11-13 Thread abhinavk

On 2020-11-13 05:49, Lee Jones wrote:

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c:299:5: warning: no previous
prototype for ‘mdp5_disable’ [-Wmissing-prototypes]
 drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c:319:5: warning: no previous
prototype for ‘mdp5_enable’ [-Wmissing-prototypes]

Cc: Rob Clark 
Cc: Sean Paul 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Thomas Zimmermann 
Cc: linux-arm-...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: freedr...@lists.freedesktop.org
Signed-off-by: Lee Jones 

Reviewed-by: Abhinav Kumar 

---
 drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
index b3eecf8694771..15aed45022bc8 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
@@ -296,7 +296,7 @@ static const struct mdp_kms_funcs kms_funcs = {
.set_irqmask = mdp5_set_irqmask,
 };

-int mdp5_disable(struct mdp5_kms *mdp5_kms)
+static int mdp5_disable(struct mdp5_kms *mdp5_kms)
 {
DBG("");

@@ -316,7 +316,7 @@ int mdp5_disable(struct mdp5_kms *mdp5_kms)
return 0;
 }

-int mdp5_enable(struct mdp5_kms *mdp5_kms)
+static int mdp5_enable(struct mdp5_kms *mdp5_kms)
 {
DBG("");

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


Re: [Freedreno] [PATCH 34/40] drm/msm/disp/mdp5/mdp5_ctl: Demote non-conformant kernel-doc headers

2020-11-13 Thread abhinavk

On 2020-11-13 05:49, Lee Jones wrote:

Very little attempt has been made to document these functions.

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c:227: warning: Function
parameter or member 'ctl' not described in
'mdp5_ctl_set_encoder_state'
 drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c:227: warning: Function
parameter or member 'pipeline' not described in
'mdp5_ctl_set_encoder_state'
 drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c:227: warning: Function
parameter or member 'enabled' not described in
'mdp5_ctl_set_encoder_state'
 drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c:227: warning: Excess
function parameter 'enable' description in
'mdp5_ctl_set_encoder_state'
 drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c:529: warning: Function
parameter or member 'ctl' not described in 'mdp5_ctl_commit'
 drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c:529: warning: Function
parameter or member 'pipeline' not described in 'mdp5_ctl_commit'
 drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c:529: warning: Function
parameter or member 'flush_mask' not described in 'mdp5_ctl_commit'
 drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c:529: warning: Function
parameter or member 'start' not described in 'mdp5_ctl_commit'

Cc: Rob Clark 
Cc: Sean Paul 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: linux-arm-...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: freedr...@lists.freedesktop.org
Signed-off-by: Lee Jones 

Reviewed-by: Abhinav Kumar 

---
 drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c
index 030279d7b64b7..b5c40f9773629 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c
@@ -213,10 +213,10 @@ static void send_start_signal(struct mdp5_ctl 
*ctl)

spin_unlock_irqrestore(>hw_lock, flags);
 }

-/**
+/*
  * mdp5_ctl_set_encoder_state() - set the encoder state
  *
- * @enable: true, when encoder is ready for data streaming; false, 
otherwise.
+ * @enabled: true, when encoder is ready for data streaming; false, 
otherwise.

  *
  * Note:
  * This encoder state is needed to trigger START signal (data path 
kickoff).

@@ -507,7 +507,7 @@ static void fix_for_single_flush(struct mdp5_ctl
*ctl, u32 *flush_mask,
}
 }

-/**
+/*
  * mdp5_ctl_commit() - Register Flush
  *
  * The flush register is used to indicate several registers are all

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


Re: [PATCH 32/40] drm/msm/disp/mdp5/mdp5_crtc: Make local function 'mdp5_crtc_setup_pipeline()' static

2020-11-13 Thread abhinavk

On 2020-11-13 05:49, Lee Jones wrote:

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c:581:5: warning: no previous
prototype for ‘mdp5_crtc_setup_pipeline’ [-Wmissing-prototypes]

Cc: Rob Clark 
Cc: Sean Paul 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Thomas Zimmermann 
Cc: linux-arm-...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: freedr...@lists.freedesktop.org
Signed-off-by: Lee Jones 

Reviewed-by: Abhinav Kumar 

---
 drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
index 79dd56faf3de0..0c8f9f88301fa 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
@@ -578,9 +578,9 @@ static void mdp5_crtc_atomic_enable(struct drm_crtc 
*crtc,

mdp5_crtc->enabled = true;
 }

-int mdp5_crtc_setup_pipeline(struct drm_crtc *crtc,
-struct drm_crtc_state *new_crtc_state,
-bool need_right_mixer)
+static int mdp5_crtc_setup_pipeline(struct drm_crtc *crtc,
+   struct drm_crtc_state *new_crtc_state,
+   bool need_right_mixer)
 {
struct mdp5_crtc_state *mdp5_cstate =
to_mdp5_crtc_state(new_crtc_state);

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


Re: [Freedreno] [PATCH 39/40] drm/msm/disp/dpu1/dpu_encoder: Remove a bunch of unused variables

2020-11-13 Thread abhinavk

On 2020-11-13 05:49, Lee Jones wrote:

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c: In function
‘dpu_encoder_virt_mode_set’:
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c:981:31: warning: variable
‘num_dspp’ set but not used [-Wunused-but-set-variable]
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c:976:30: warning: variable
‘topology’ set but not used [-Wunused-but-set-variable]
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c: In function
‘_dpu_encoder_virt_enable_helper’:
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c:1099:26: warning:
variable ‘priv’ set but not used [-Wunused-but-set-variable]
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c: In function
‘dpu_encoder_virt_disable’:
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c:1210:18: warning:
variable ‘dpu_kms’ set but not used [-Wunused-but-set-variable]

Cc: Rob Clark 
Cc: Sean Paul 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: linux-arm-...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: freedr...@lists.freedesktop.org
Signed-off-by: Lee Jones 

Reviewed-by: Abhinav Kumar 

---
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 12 ++--
 1 file changed, 2 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index f7f5c258b5537..289bfb6f1861c 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -973,12 +973,11 @@ static void dpu_encoder_virt_mode_set(struct
drm_encoder *drm_enc,
struct drm_crtc *drm_crtc;
struct dpu_crtc_state *cstate;
struct dpu_global_state *global_state;
-   struct msm_display_topology topology;
struct dpu_hw_blk *hw_pp[MAX_CHANNELS_PER_ENC];
struct dpu_hw_blk *hw_ctl[MAX_CHANNELS_PER_ENC];
struct dpu_hw_blk *hw_lm[MAX_CHANNELS_PER_ENC];
struct dpu_hw_blk *hw_dspp[MAX_CHANNELS_PER_ENC] = { NULL };
-   int num_lm, num_ctl, num_pp, num_dspp;
+   int num_lm, num_ctl, num_pp;
int i, j;

if (!drm_enc) {
@@ -1020,8 +1019,6 @@ static void dpu_encoder_virt_mode_set(struct
drm_encoder *drm_enc,
if (drm_crtc->state->encoder_mask & drm_encoder_mask(drm_enc))
break;

-   topology = dpu_encoder_get_topology(dpu_enc, dpu_kms, adj_mode);
-
/* Query resource that have been reserved in atomic check step. */
num_pp = dpu_rm_get_assigned_resources(_kms->rm, global_state,
drm_enc->base.id, DPU_HW_BLK_PINGPONG, hw_pp,
@@ -1030,7 +1027,7 @@ static void dpu_encoder_virt_mode_set(struct
drm_encoder *drm_enc,
drm_enc->base.id, DPU_HW_BLK_CTL, hw_ctl, ARRAY_SIZE(hw_ctl));
num_lm = dpu_rm_get_assigned_resources(_kms->rm, global_state,
drm_enc->base.id, DPU_HW_BLK_LM, hw_lm, ARRAY_SIZE(hw_lm));
-   num_dspp = dpu_rm_get_assigned_resources(_kms->rm, global_state,
+   dpu_rm_get_assigned_resources(_kms->rm, global_state,
drm_enc->base.id, DPU_HW_BLK_DSPP, hw_dspp,
ARRAY_SIZE(hw_dspp));

@@ -1096,7 +1093,6 @@ static void dpu_encoder_virt_mode_set(struct
drm_encoder *drm_enc,
 static void _dpu_encoder_virt_enable_helper(struct drm_encoder 
*drm_enc)

 {
struct dpu_encoder_virt *dpu_enc = NULL;
-   struct msm_drm_private *priv;
int i;

if (!drm_enc || !drm_enc->dev) {
@@ -1104,8 +1100,6 @@ static void
_dpu_encoder_virt_enable_helper(struct drm_encoder *drm_enc)
return;
}

-   priv = drm_enc->dev->dev_private;
-
dpu_enc = to_dpu_encoder_virt(drm_enc);
if (!dpu_enc || !dpu_enc->cur_master) {
DPU_ERROR("invalid dpu encoder/master\n");
@@ -1207,7 +1201,6 @@ static void dpu_encoder_virt_disable(struct
drm_encoder *drm_enc)
 {
struct dpu_encoder_virt *dpu_enc = NULL;
struct msm_drm_private *priv;
-   struct dpu_kms *dpu_kms;
int i = 0;

if (!drm_enc) {
@@ -1225,7 +1218,6 @@ static void dpu_encoder_virt_disable(struct
drm_encoder *drm_enc)
dpu_enc->enabled = false;

priv = drm_enc->dev->dev_private;
-   dpu_kms = to_dpu_kms(priv->kms);

trace_dpu_enc_disable(DRMID(drm_enc));

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


Re: [Freedreno] [PATCH 38/40] drm/msm/disp/dpu1/dpu_core_perf: Remove set but unused variable 'dpu_cstate'

2020-11-13 Thread abhinavk

On 2020-11-13 05:49, Lee Jones wrote:

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c: In function
‘_dpu_core_perf_calc_crtc’:
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c:113:25: warning:
variable ‘dpu_cstate’ set but not used [-Wunused-but-set-variable]

Cc: Rob Clark 
Cc: Sean Paul 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Kalyan Thota 
Cc: linux-arm-...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: freedr...@lists.freedesktop.org
Signed-off-by: Lee Jones 

Reviewed-by: Abhinav Kumar 

---
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
index 37c8270681c23..36927fc04a388 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
@@ -110,14 +110,11 @@ static void _dpu_core_perf_calc_crtc(struct 
dpu_kms *kms,

struct drm_crtc_state *state,
struct dpu_core_perf_params *perf)
 {
-   struct dpu_crtc_state *dpu_cstate;
-
if (!kms || !kms->catalog || !crtc || !state || !perf) {
DPU_ERROR("invalid parameters\n");
return;
}

-   dpu_cstate = to_dpu_crtc_state(state);
memset(perf, 0, sizeof(struct dpu_core_perf_params));

if (kms->perf.perf_tune.mode == DPU_PERF_MODE_MINIMUM) {

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


Re: [PATCH][next] drm/kmb: fix potential integer overflow on multiplication

2020-11-13 Thread kernel test robot
Hi Colin,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on next-20201112]
[cannot apply to linus/master v5.10-rc3 v5.10-rc2 v5.10-rc1 v5.10-rc3]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Colin-King/drm-kmb-fix-potential-integer-overflow-on-multiplication/20201113-203903
base:a60b1e1fe9ca5f9d9a79e89a8d71228a8e04d35c
config: m68k-allmodconfig (attached as .config)
compiler: m68k-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://github.com/0day-ci/linux/commit/bb25aac8771c57130ea5a2a016790e3b7c62e283
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Colin-King/drm-kmb-fix-potential-integer-overflow-on-multiplication/20201113-203903
git checkout bb25aac8771c57130ea5a2a016790e3b7c62e283
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=m68k 

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

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

>> ERROR: modpost: "__udivdi3" [drivers/gpu/drm/kmb/kmb-drm.ko] undefined!
>> ERROR: modpost: "__divdi3" [drivers/gpu/drm/kmb/kmb-drm.ko] undefined!

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [git pull] drm fixes for 5.10-rc4

2020-11-13 Thread pr-tracker-bot
The pull request you sent on Fri, 13 Nov 2020 16:41:04 +1000:

> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-11-13

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/e627c25544dfec9af56842b07e40ad992731627a

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/fourcc: add table describing AMD modifiers bit layout

2020-11-13 Thread Alex Deucher
On Fri, Nov 13, 2020 at 12:21 PM Simon Ser  wrote:
>
> The table describes how each bit in the u64 value is used. Explicitly
> state which values a field can take if we have defines for them. Also
> add a note when a field isn't always populated.
>
> Forcing people to update the table when changing the bit layout should
> make it more obvious when there's a mistake, I hope.
>
> If we get to the point where the bit layout gets more complicated, it
> might be worth it to split the table into multiple tables (e.g. one for
> GFX8, one for GFX9+, and so on).
>
> Signed-off-by: Simon Ser 
> Cc: Bas Nieuwenhuizen 
> Cc: Alex Deucher 
> Cc: Daniel Vetter 

Applied.  Thanks!

Alex

> ---
>
> This already contains the fix in [1].
>
> [1]: https://lists.freedesktop.org/archives/amd-gfx/2020-November/056073.html
>
>  include/uapi/drm/drm_fourcc.h | 19 +++
>  1 file changed, 19 insertions(+)
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index ca48ed0e6bc1..253386b7bc6a 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -1114,6 +1114,25 @@ drm_fourcc_canonicalize_nvidia_format_mod(__u64 
> modifier)
>   *
>   * For multi-plane formats the above surfaces get merged into one plane for
>   * each format plane, based on the required alignment only.
> + *
> + * Bits  ParameterNotes
> + * -  
> -
> + *
> + *   7:0 TILE_VERSION Values are AMD_FMT_MOD_TILE_VER_*
> + *  12:8 TILE Values are AMD_FMT_MOD_TILE__*
> + *13 DCC
> + *14 DCC_RETILE
> + *15 DCC_PIPE_ALIGN
> + *16 DCC_INDEPENDENT_64B
> + *17 DCC_INDEPENDENT_128B
> + * 19:18 DCC_MAX_COMPRESSED_BLOCK Values are AMD_FMT_MOD_DCC_BLOCK_*
> + *20 DCC_CONSTANT_ENCODE
> + * 23:21 PIPE_XOR_BITSOnly for some chips
> + * 26:24 BANK_XOR_BITSOnly for some chips
> + * 29:27 PACKERS  Only for some chips
> + * 32:30 RB   Only for some chips
> + * 35:33 PIPE Only for some chips
> + * 55:36 -Reserved for future use, must be zero
>   */
>  #define AMD_FMT_MOD fourcc_mod_code(AMD, 0)
>
> --
> 2.29.2
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH][next] drm/kmb: fix array out-of-bounds writes to kmb->plane_status[]

2020-11-13 Thread Sam Ravnborg
Hi Colin.
On Fri, Nov 13, 2020 at 03:04:34PM +, Colin Ian King wrote:
> On 13/11/2020 14:55, Sam Ravnborg wrote:
> > Hi Colin.
> > 
> > On Fri, Nov 13, 2020 at 12:01:21PM +, Colin King wrote:
> >> From: Colin Ian King 
> >>
> >> Writes to elements in the kmb->plane_status array in function
> >> kmb_plane_atomic_disable are overrunning the array when plane_id is
> >> more than 1 because currently the array is KMB_MAX_PLANES elements
> >> in size and this is currently #defined as 1.  Fix this by defining
> >> KMB_MAX_PLANES to 4.
> > 
> > I fail to follow you here.
> > In kmb_plane_init() only one plane is allocated - with id set to 0.
> > So for now only one plane is allocated thus kmb_plane_atomic_disable()
> > is only called for this plane.
> > 
> > With your change we will start allocating four planes, something that is
> > not tested.
> > 
> > Do I miss something?
> > 
> > Sam
> > 
> 
> The static analysis from coverity on linux-next suggested that there was
> an array overflow as follows:
> 
> 108 static void kmb_plane_atomic_disable(struct drm_plane *plane,
> 109 struct drm_plane_state *state)
> 110 {
> 
>1. Condition 0 /* !!(!__builtin_types_compatible_p() &&
> !__builtin_types_compatible_p()) */, taking false branch.
> 
> 111struct kmb_plane *kmb_plane = to_kmb_plane(plane);
> 
>2. assignment: Assigning: plane_id = kmb_plane->id.
> 
> 112int plane_id = kmb_plane->id;
> 113struct kmb_drm_private *kmb;
> 114
> 115kmb = to_kmb(plane->dev);
> 116
> 
>3. Switch case value LAYER_3.
> 
> 117switch (plane_id) {
> 118case LAYER_0:
> 119kmb->plane_status[plane_id].ctrl = LCD_CTRL_VL1_ENABLE;
> 120break;

With the current code this is the only case that hits.
So coverity is right that if we hit other cases that would result in a
bug. But kmb_plane->id will for now not have other values than 0.

So it is a subtle false positive.
There is some "dead" code here - but this is in preparation for more
than one layer and we will keep the code for now, unless Anitha chimes
in and says otherwise.

Sam

> 121case LAYER_1:
> 
>(#2 of 4): Out-of-bounds write (OVERRUN)
> 
> 122kmb->plane_status[plane_id].ctrl = LCD_CTRL_VL2_ENABLE;
> 123break;
> 124case LAYER_2:
> 
>(#3 of 4): Out-of-bounds write (OVERRUN)
> 
> 125kmb->plane_status[plane_id].ctrl = LCD_CTRL_GL1_ENABLE;
> 126break;
> 
>4. equality_cond: Jumping to case LAYER_3.
> 
> 127case LAYER_3:
> 
>(#1 of 4): Out-of-bounds write (OVERRUN)
>5. overrun-local: Overrunning array kmb->plane_status of 1 8-byte
> elements at element index 3 (byte offset 31) using index plane_id (which
> evaluates to 3).
> 
> 128kmb->plane_status[plane_id].ctrl = LCD_CTRL_GL2_ENABLE;
> 129break;
> 130}
> 131
> 
>(#4 of 4): Out-of-bounds write (OVERRUN)
> 
> 132kmb->plane_status[plane_id].disable = true;
> 133 }
> 134
> 
> So it seems the assignments to  kmb->plane_status[plane_id] are
> overrunning the array since plane_status is allocated as 1 element and
> yet plane_id can be 0..3
> 
> I could be misunderstanding this, or it may be a false positive.
> 
> Colin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2] drm/fourcc: Fix modifier field mask for AMD modifiers.

2020-11-13 Thread Alex Deucher
On Fri, Nov 13, 2020 at 12:55 PM Bas Nieuwenhuizen
 wrote:
>
> The DCC_MAX_COMPRESSED_BLOCK has to contain one of
> AMD_FMT_MOD_DCC_BLOCK_* and with 3 values this doesn't
> fit in 1 bit.
>
> Fix this cleanly while it is only in drm-next.
>
> Fixes: 8ba16d599374 ("drm/fourcc: Add AMD DRM modifiers.")
> Reviewed-by: Alex Deucher 
> Signed-off-by: Bas Nieuwenhuizen 

Applied.  Thanks!

Alex

> ---
>  include/uapi/drm/drm_fourcc.h | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index df56e71a7380..a878664ba41c 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -1129,7 +1129,7 @@ drm_fourcc_canonicalize_nvidia_format_mod(__u64 
> modifier)
>  #define AMD_FMT_MOD_DCC_INDEPENDENT_128B_SHIFT 17
>  #define AMD_FMT_MOD_DCC_INDEPENDENT_128B_MASK 0x1
>  #define AMD_FMT_MOD_DCC_MAX_COMPRESSED_BLOCK_SHIFT 18
> -#define AMD_FMT_MOD_DCC_MAX_COMPRESSED_BLOCK_MASK 0x1
> +#define AMD_FMT_MOD_DCC_MAX_COMPRESSED_BLOCK_MASK 0x3
>
>  /*
>   * DCC supports embedding some clear colors directly in the DCC surface.
> @@ -1140,7 +1140,7 @@ drm_fourcc_canonicalize_nvidia_format_mod(__u64 
> modifier)
>   * If this bit is set that means the fastclear eliminate is not needed for 
> these
>   * embeddable colors.
>   */
> -#define AMD_FMT_MOD_DCC_CONSTANT_ENCODE_SHIFT 19
> +#define AMD_FMT_MOD_DCC_CONSTANT_ENCODE_SHIFT 20
>  #define AMD_FMT_MOD_DCC_CONSTANT_ENCODE_MASK 0x1
>
>  /*
> @@ -1153,15 +1153,15 @@ drm_fourcc_canonicalize_nvidia_format_mod(__u64 
> modifier)
>   * RB = only for TILE_VER_GFX9 & DCC
>   * PIPE = only for TILE_VER_GFX9 & DCC & (DCC_RETILE | DCC_PIPE_ALIGN)
>   */
> -#define AMD_FMT_MOD_PIPE_XOR_BITS_SHIFT 20
> +#define AMD_FMT_MOD_PIPE_XOR_BITS_SHIFT 21
>  #define AMD_FMT_MOD_PIPE_XOR_BITS_MASK 0x7
> -#define AMD_FMT_MOD_BANK_XOR_BITS_SHIFT 23
> +#define AMD_FMT_MOD_BANK_XOR_BITS_SHIFT 24
>  #define AMD_FMT_MOD_BANK_XOR_BITS_MASK 0x7
> -#define AMD_FMT_MOD_PACKERS_SHIFT 26 /* aliases with BANK_XOR_BITS */
> +#define AMD_FMT_MOD_PACKERS_SHIFT 27 /* aliases with BANK_XOR_BITS */
>  #define AMD_FMT_MOD_PACKERS_MASK 0x7
> -#define AMD_FMT_MOD_RB_SHIFT 29
> +#define AMD_FMT_MOD_RB_SHIFT 30
>  #define AMD_FMT_MOD_RB_MASK 0x7
> -#define AMD_FMT_MOD_PIPE_SHIFT 32
> +#define AMD_FMT_MOD_PIPE_SHIFT 33
>  #define AMD_FMT_MOD_PIPE_MASK 0x7
>
>  #define AMD_FMT_MOD_SET(field, value) \
> --
> 2.29.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH][next] drm/kmb: fix potential integer overflow on multiplication

2020-11-13 Thread kernel test robot
Hi Colin,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on next-20201112]
[cannot apply to linus/master v5.10-rc3 v5.10-rc2 v5.10-rc1 v5.10-rc3]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Colin-King/drm-kmb-fix-potential-integer-overflow-on-multiplication/20201113-203903
base:a60b1e1fe9ca5f9d9a79e89a8d71228a8e04d35c
config: i386-allyesconfig (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce (this is a W=1 build):
# 
https://github.com/0day-ci/linux/commit/bb25aac8771c57130ea5a2a016790e3b7c62e283
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Colin-King/drm-kmb-fix-potential-integer-overflow-on-multiplication/20201113-203903
git checkout bb25aac8771c57130ea5a2a016790e3b7c62e283
# save the attached .config to linux build tree
make W=1 ARCH=i386 

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

All errors (new ones prefixed by >>):

   ld: drivers/gpu/drm/kmb/kmb_dsi.o: in function `kmb_dsi_mode_set':
   kmb_dsi.c:(.text+0x13b7): undefined reference to `__udivdi3'
>> ld: kmb_dsi.c:(.text+0x13ca): undefined reference to `__udivdi3'

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2] drm/fourcc: Fix modifier field mask for AMD modifiers.

2020-11-13 Thread Bas Nieuwenhuizen
The DCC_MAX_COMPRESSED_BLOCK has to contain one of
AMD_FMT_MOD_DCC_BLOCK_* and with 3 values this doesn't
fit in 1 bit.

Fix this cleanly while it is only in drm-next.

Fixes: 8ba16d599374 ("drm/fourcc: Add AMD DRM modifiers.")
Reviewed-by: Alex Deucher 
Signed-off-by: Bas Nieuwenhuizen 
---
 include/uapi/drm/drm_fourcc.h | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index df56e71a7380..a878664ba41c 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -1129,7 +1129,7 @@ drm_fourcc_canonicalize_nvidia_format_mod(__u64 modifier)
 #define AMD_FMT_MOD_DCC_INDEPENDENT_128B_SHIFT 17
 #define AMD_FMT_MOD_DCC_INDEPENDENT_128B_MASK 0x1
 #define AMD_FMT_MOD_DCC_MAX_COMPRESSED_BLOCK_SHIFT 18
-#define AMD_FMT_MOD_DCC_MAX_COMPRESSED_BLOCK_MASK 0x1
+#define AMD_FMT_MOD_DCC_MAX_COMPRESSED_BLOCK_MASK 0x3
 
 /*
  * DCC supports embedding some clear colors directly in the DCC surface.
@@ -1140,7 +1140,7 @@ drm_fourcc_canonicalize_nvidia_format_mod(__u64 modifier)
  * If this bit is set that means the fastclear eliminate is not needed for 
these
  * embeddable colors.
  */
-#define AMD_FMT_MOD_DCC_CONSTANT_ENCODE_SHIFT 19
+#define AMD_FMT_MOD_DCC_CONSTANT_ENCODE_SHIFT 20
 #define AMD_FMT_MOD_DCC_CONSTANT_ENCODE_MASK 0x1
 
 /*
@@ -1153,15 +1153,15 @@ drm_fourcc_canonicalize_nvidia_format_mod(__u64 
modifier)
  * RB = only for TILE_VER_GFX9 & DCC
  * PIPE = only for TILE_VER_GFX9 & DCC & (DCC_RETILE | DCC_PIPE_ALIGN)
  */
-#define AMD_FMT_MOD_PIPE_XOR_BITS_SHIFT 20
+#define AMD_FMT_MOD_PIPE_XOR_BITS_SHIFT 21
 #define AMD_FMT_MOD_PIPE_XOR_BITS_MASK 0x7
-#define AMD_FMT_MOD_BANK_XOR_BITS_SHIFT 23
+#define AMD_FMT_MOD_BANK_XOR_BITS_SHIFT 24
 #define AMD_FMT_MOD_BANK_XOR_BITS_MASK 0x7
-#define AMD_FMT_MOD_PACKERS_SHIFT 26 /* aliases with BANK_XOR_BITS */
+#define AMD_FMT_MOD_PACKERS_SHIFT 27 /* aliases with BANK_XOR_BITS */
 #define AMD_FMT_MOD_PACKERS_MASK 0x7
-#define AMD_FMT_MOD_RB_SHIFT 29
+#define AMD_FMT_MOD_RB_SHIFT 30
 #define AMD_FMT_MOD_RB_MASK 0x7
-#define AMD_FMT_MOD_PIPE_SHIFT 32
+#define AMD_FMT_MOD_PIPE_SHIFT 33
 #define AMD_FMT_MOD_PIPE_MASK 0x7
 
 #define AMD_FMT_MOD_SET(field, value) \
-- 
2.29.2

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


Re: [PATCH] drm/fourcc: Fix modifier field mask for AMD modifiers.

2020-11-13 Thread Alex Deucher
On Fri, Nov 13, 2020 at 11:25 AM Bas Nieuwenhuizen
 wrote:
>
> The DCC_MAX_COMPRESSED_BLOCK has to contain one of
> AMD_FMT_MOD_DCC_BLOCK_* and with 3 values this doesn't
> fit in 1 bit.
>
> Fix this cleanly while it is only in drm-next.
>
> Fixes: 8ba16d5993749c3f31fd2b49e16f0dc1e1770b9c

Fixes: 8ba16d599374 ("drm/fourcc: Add AMD DRM modifiers.")

Also missing your signed-off-by.  With those things fixed:
Reviewed-by: Alex Deucher 

> ---
>
> Found while reviewing Simon's drm_info PR: 
> https://github.com/ascent12/drm_info/pull/63/commits/eaeae6ee78764a03d959cbc97c8b514f81a94c63
>
>  include/uapi/drm/drm_fourcc.h | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index df56e71a7380..a878664ba41c 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -1129,7 +1129,7 @@ drm_fourcc_canonicalize_nvidia_format_mod(__u64 
> modifier)
>  #define AMD_FMT_MOD_DCC_INDEPENDENT_128B_SHIFT 17
>  #define AMD_FMT_MOD_DCC_INDEPENDENT_128B_MASK 0x1
>  #define AMD_FMT_MOD_DCC_MAX_COMPRESSED_BLOCK_SHIFT 18
> -#define AMD_FMT_MOD_DCC_MAX_COMPRESSED_BLOCK_MASK 0x1
> +#define AMD_FMT_MOD_DCC_MAX_COMPRESSED_BLOCK_MASK 0x3
>
>  /*
>   * DCC supports embedding some clear colors directly in the DCC surface.
> @@ -1140,7 +1140,7 @@ drm_fourcc_canonicalize_nvidia_format_mod(__u64 
> modifier)
>   * If this bit is set that means the fastclear eliminate is not needed for 
> these
>   * embeddable colors.
>   */
> -#define AMD_FMT_MOD_DCC_CONSTANT_ENCODE_SHIFT 19
> +#define AMD_FMT_MOD_DCC_CONSTANT_ENCODE_SHIFT 20
>  #define AMD_FMT_MOD_DCC_CONSTANT_ENCODE_MASK 0x1
>
>  /*
> @@ -1153,15 +1153,15 @@ drm_fourcc_canonicalize_nvidia_format_mod(__u64 
> modifier)
>   * RB = only for TILE_VER_GFX9 & DCC
>   * PIPE = only for TILE_VER_GFX9 & DCC & (DCC_RETILE | DCC_PIPE_ALIGN)
>   */
> -#define AMD_FMT_MOD_PIPE_XOR_BITS_SHIFT 20
> +#define AMD_FMT_MOD_PIPE_XOR_BITS_SHIFT 21
>  #define AMD_FMT_MOD_PIPE_XOR_BITS_MASK 0x7
> -#define AMD_FMT_MOD_BANK_XOR_BITS_SHIFT 23
> +#define AMD_FMT_MOD_BANK_XOR_BITS_SHIFT 24
>  #define AMD_FMT_MOD_BANK_XOR_BITS_MASK 0x7
> -#define AMD_FMT_MOD_PACKERS_SHIFT 26 /* aliases with BANK_XOR_BITS */
> +#define AMD_FMT_MOD_PACKERS_SHIFT 27 /* aliases with BANK_XOR_BITS */
>  #define AMD_FMT_MOD_PACKERS_MASK 0x7
> -#define AMD_FMT_MOD_RB_SHIFT 29
> +#define AMD_FMT_MOD_RB_SHIFT 30
>  #define AMD_FMT_MOD_RB_MASK 0x7
> -#define AMD_FMT_MOD_PIPE_SHIFT 32
> +#define AMD_FMT_MOD_PIPE_SHIFT 33
>  #define AMD_FMT_MOD_PIPE_MASK 0x7
>
>  #define AMD_FMT_MOD_SET(field, value) \
> --
> 2.29.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 40/40] drm/amd/amdgpu/gfx_v7_0: Remove unused struct definition

2020-11-13 Thread Alex Deucher
On Fri, Nov 13, 2020 at 8:50 AM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c:5211:45: warning: ‘gfx_v7_0_ip_block’ 
> defined but not used [-Wunused-const-variable=]
>
> Cc: Alex Deucher 
> Cc: "Christian König" 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Sumit Semwal 
> Cc: amd-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-me...@vger.kernel.org
> Cc: linaro-mm-...@lists.linaro.org
> Signed-off-by: Lee Jones 

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c | 9 -
>  drivers/gpu/drm/amd/amdgpu/gfx_v7_0.h | 1 -
>  2 files changed, 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c 
> b/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
> index cb07bc21dcbe5..04e1e92f5f3cf 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
> @@ -5208,15 +5208,6 @@ static void gfx_v7_0_get_cu_info(struct amdgpu_device 
> *adev)
> cu_info->lds_size = 64;
>  }
>
> -static const struct amdgpu_ip_block_version gfx_v7_0_ip_block =
> -{
> -   .type = AMD_IP_BLOCK_TYPE_GFX,
> -   .major = 7,
> -   .minor = 0,
> -   .rev = 0,
> -   .funcs = _v7_0_ip_funcs,
> -};
> -
>  const struct amdgpu_ip_block_version gfx_v7_1_ip_block =
>  {
> .type = AMD_IP_BLOCK_TYPE_GFX,
> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.h 
> b/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.h
> index 6fb9c1524691f..eedce7d007f1d 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.h
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.h
> @@ -24,7 +24,6 @@
>  #ifndef __GFX_V7_0_H__
>  #define __GFX_V7_0_H__
>
> -extern const struct amdgpu_ip_block_version gfx_v7_0_ip_block;
>  extern const struct amdgpu_ip_block_version gfx_v7_1_ip_block;
>  extern const struct amdgpu_ip_block_version gfx_v7_2_ip_block;
>  extern const struct amdgpu_ip_block_version gfx_v7_3_ip_block;
> --
> 2.25.1
>
> ___
> 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 37/40] drm/amd/amdgpu/smu_v11_0_i2c: Provide descriptions for 'control' and 'data' params

2020-11-13 Thread Alex Deucher
On Fri, Nov 13, 2020 at 8:50 AM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/gpu/drm/amd/amdgpu/smu_v11_0_i2c.c:225: warning: Function parameter 
> or member 'control' not described in 'smu_v11_0_i2c_transmit'
>  drivers/gpu/drm/amd/amdgpu/smu_v11_0_i2c.c:325: warning: Function parameter 
> or member 'control' not described in 'smu_v11_0_i2c_receive'
>  drivers/gpu/drm/amd/amdgpu/smu_v11_0_i2c.c:325: warning: Function parameter 
> or member 'data' not described in 'smu_v11_0_i2c_receive'
>
> Cc: Alex Deucher 
> Cc: "Christian König" 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: amd-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Lee Jones 

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/amdgpu/smu_v11_0_i2c.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/smu_v11_0_i2c.c 
> b/drivers/gpu/drm/amd/amdgpu/smu_v11_0_i2c.c
> index 7fb240c4990ca..5c7d769aee3fb 100644
> --- a/drivers/gpu/drm/amd/amdgpu/smu_v11_0_i2c.c
> +++ b/drivers/gpu/drm/amd/amdgpu/smu_v11_0_i2c.c
> @@ -212,6 +212,7 @@ static uint32_t smu_v11_0_i2c_poll_rx_status(struct 
> i2c_adapter *control)
>  /**
>   * smu_v11_0_i2c_transmit - Send a block of data over the I2C bus to a slave 
> device.
>   *
> + * @control: I2C adapter reference
>   * @address: The I2C address of the slave device.
>   * @data: The data to transmit over the bus.
>   * @numbytes: The amount of data to transmit.
> @@ -313,7 +314,9 @@ static uint32_t smu_v11_0_i2c_transmit(struct i2c_adapter 
> *control,
>  /**
>   * smu_v11_0_i2c_receive - Receive a block of data over the I2C bus from a 
> slave device.
>   *
> + * @control: I2C adapter reference
>   * @address: The I2C address of the slave device.
> + * @data: Placeholder to store received data.
>   * @numbytes: The amount of data to transmit.
>   * @i2c_flag: Flags for transmission
>   *
> --
> 2.25.1
>
> ___
> 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 36/40] drm/amd/amdgpu/amdgpu_fw_attestation: Consume our own header containing prototypes

2020-11-13 Thread Alex Deucher
On Fri, Nov 13, 2020 at 8:51 AM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/gpu/drm/amd/amdgpu/amdgpu_fw_attestation.c:130:6: warning: no 
> previous prototype for ‘amdgpu_fw_attestation_debugfs_init’ 
> [-Wmissing-prototypes]
>
> Cc: Alex Deucher 
> Cc: "Christian König" 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Hawking Zhang 
> Cc: John Clements 
> Cc: amd-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Lee Jones 

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_fw_attestation.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fw_attestation.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_fw_attestation.c
> index c6947d6c7ff51..e47bca1c76359 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fw_attestation.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fw_attestation.c
> @@ -26,6 +26,7 @@
>  #include 
>
>  #include "amdgpu.h"
> +#include "amdgpu_fw_attestation.h"
>  #include "amdgpu_psp.h"
>  #include "amdgpu_ucode.h"
>  #include "soc15_common.h"
> @@ -139,4 +140,4 @@ void amdgpu_fw_attestation_debugfs_init(struct 
> amdgpu_device *adev)
> adev,
> _fw_attestation_debugfs_ops);
>  #endif
> -}
> \ No newline at end of file
> +}
> --
> 2.25.1
>
> ___
> 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 31/40] drm/amd/amdgpu/amdgpu_vm_sdma: Fix 'amdgpu_vm_sdma_prepare()'s doc-rot

2020-11-13 Thread Alex Deucher
On Fri, Nov 13, 2020 at 8:50 AM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c:63: warning: Function parameter 
> or member 'resv' not described in 'amdgpu_vm_sdma_prepare'
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c:63: warning: Function parameter 
> or member 'sync_mode' not described in 'amdgpu_vm_sdma_prepare'
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c:63: warning: Excess function 
> parameter 'owner' description in 'amdgpu_vm_sdma_prepare'
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c:63: warning: Excess function 
> parameter 'exclusive' description in 'amdgpu_vm_sdma_prepare'
>
> Cc: Alex Deucher 
> Cc: "Christian König" 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Sumit Semwal 
> Cc: amd-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-me...@vger.kernel.org
> Cc: linaro-mm-...@lists.linaro.org
> Signed-off-by: Lee Jones 

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c
> index db790574dc2e8..a83a646759c58 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c
> @@ -51,8 +51,8 @@ static int amdgpu_vm_sdma_map_table(struct amdgpu_bo *table)
>   * amdgpu_vm_sdma_prepare - prepare SDMA command submission
>   *
>   * @p: see amdgpu_vm_update_params definition
> - * @owner: owner we need to sync to
> - * @exclusive: exclusive move fence we need to sync to
> + * @resv: reservation object with embedded fence
> + * @sync_mode: synchronization mode
>   *
>   * Returns:
>   * Negativ errno, 0 for success.
> --
> 2.25.1
>
> ___
> 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 30/40] drm/amd/amdgpu/amdgpu_vm_cpu: Fix 'amdgpu_vm_cpu_prepare()'s doc-rot

2020-11-13 Thread Alex Deucher
On Fri, Nov 13, 2020 at 8:50 AM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vm_cpu.c:50: warning: Function parameter 
> or member 'resv' not described in 'amdgpu_vm_cpu_prepare'
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vm_cpu.c:50: warning: Function parameter 
> or member 'sync_mode' not described in 'amdgpu_vm_cpu_prepare'
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vm_cpu.c:50: warning: Excess function 
> parameter 'owner' description in 'amdgpu_vm_cpu_prepare'
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vm_cpu.c:50: warning: Excess function 
> parameter 'exclusive' description in 'amdgpu_vm_cpu_prepare'
>
> Cc: Alex Deucher 
> Cc: "Christian König" 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Sumit Semwal 
> Cc: Felix Kuehling 
> Cc: amd-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-me...@vger.kernel.org
> Cc: linaro-mm-...@lists.linaro.org
> Signed-off-by: Lee Jones 

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vm_cpu.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_cpu.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_cpu.c
> index 0786e754b..ac45d9c7a4e94 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_cpu.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_cpu.c
> @@ -38,8 +38,8 @@ static int amdgpu_vm_cpu_map_table(struct amdgpu_bo *table)
>   * amdgpu_vm_cpu_prepare - prepare page table update with the CPU
>   *
>   * @p: see amdgpu_vm_update_params definition
> - * @owner: owner we need to sync to
> - * @exclusive: exclusive move fence we need to sync to
> + * @resv: reservation object with embedded fence
> + * @sync_mode: synchronization mode
>   *
>   * Returns:
>   * Negativ errno, 0 for success.
> --
> 2.25.1
>
> ___
> 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 v1 11/30] drm/tegra: dc: Support OPP and SoC core voltage scaling

2020-11-13 Thread Thierry Reding
On Fri, Nov 13, 2020 at 08:13:49PM +0300, Dmitry Osipenko wrote:
> 13.11.2020 19:15, Mark Brown пишет:
> > On Fri, Nov 13, 2020 at 06:55:27PM +0300, Dmitry Osipenko wrote:
> >> 13.11.2020 17:29, Mark Brown пишет:
> > 
> >>> It's not clear if it matters - it's more a policy decision on the part
> >>> of the driver about what it thinks safe error handling is.  If it's not
> > 
> >> If regulator_get() returns a dummy regulator, then this means that
> >> regulator isn't specified in a device-tree. But then the only way for a
> >> consumer driver to check whether regulator is dummy, is to check
> >> presence of the supply property in a device-tree.
> > 
> > My point here is that the driver shouldn't be checking for a dummy
> > regulator, the driver should be checking the features that are provided
> > to it by the regulator and handling those.
> 
> I understand yours point, but then we need dummy regulator to provide
> all the features, and currently it does the opposite.

But that's exactly Mark's point. Any regular regulator could be lacking
all of the features just as well. If the regulator supports a fixed
voltage, then it's not going to allow you to set a different one, etc.
The point is that the regulator consumer should then be written in a
way to deal with varying levels of features.

Thierry


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


Re: [PATCH 27/40] drm/amd/amdgpu/amdgpu_ras: Remove unused function 'amdgpu_ras_error_cure'

2020-11-13 Thread Alex Deucher
On Fri, Nov 13, 2020 at 8:50 AM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:908:5: warning: no previous 
> prototype for ‘amdgpu_ras_error_cure’ [-Wmissing-prototypes]
>
> Cc: Alex Deucher 
> Cc: "Christian König" 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: amd-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Lee Jones 

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 7 ---
>  1 file changed, 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
> index b96267068a72d..f89a991999428 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
> @@ -905,13 +905,6 @@ int amdgpu_ras_error_inject(struct amdgpu_device *adev,
> return ret;
>  }
>
> -int amdgpu_ras_error_cure(struct amdgpu_device *adev,
> -   struct ras_cure_if *info)
> -{
> -   /* psp fw has no cure interface for now. */
> -   return 0;
> -}
> -
>  /* get the total error counts on all IPs */
>  unsigned long amdgpu_ras_query_error_count(struct amdgpu_device *adev,
> bool is_ce)
> --
> 2.25.1
>
> ___
> 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 v1 11/30] drm/tegra: dc: Support OPP and SoC core voltage scaling

2020-11-13 Thread Mark Brown
On Fri, Nov 13, 2020 at 08:13:49PM +0300, Dmitry Osipenko wrote:
> 13.11.2020 19:15, Mark Brown пишет:

> > My point here is that the driver shouldn't be checking for a dummy
> > regulator, the driver should be checking the features that are provided
> > to it by the regulator and handling those.

> I understand yours point, but then we need dummy regulator to provide
> all the features, and currently it does the opposite.

As could any other regulator?

> > It doesn't matter if this is
> > a dummy regulator or an actual regulator with limited features, the
> > effect is the same and the handling should be the same.  If the driver
> > is doing anything to handle dummy regulators explicitly as dummy
> > regulators it is doing it wrong.

> It matters because dummy regulator errors out all checks and changes
> other than enable/disable, instead of accepting them. If we could add an
> option for dummy regulator to succeed all the checks and accept all the
> values, then it could become more usable.

I'm a bit confused here TBH - I'm not sure I see a substantial
difference between a consumer detecting that it can't set any voltages
at all and the handling for an optional regulator.  Either way if it's
going to carry on and assume that whatever voltage is there works for
everything it boils down to setting a flag saying to skip the set
voltage operation.  I think you are too focused on the specific
implementation you currently have here.

We obviously can't just accept voltage change operations when we've no
idea what the current voltage of the device is.

> > To repeat you should *only* be using regulator_get_optional() in the
> > case where the supply may be physically absent which is not the case
> > here.
> 
> Alright, but then we either need to improve regulator core to make dummy
> regulator a bit more usable, or continue to work around it in drivers.
> What should we do?

As I keep saying the consumer driver should be enumerating the voltages
it can set, if it can't find any and wants to continue then it can just
skip setting voltages later on.  If only some are unavailable then it
probably wants to eliminate those specific OPPs instead.


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


RE: [PATCH v10 4/6] RDMA/mlx5: Support dma-buf based userspace memory region

2020-11-13 Thread Xiong, Jianxin
> -Original Message-
> From: Jason Gunthorpe 
> Sent: Friday, November 13, 2020 5:06 AM
> To: Xiong, Jianxin 
> Cc: linux-r...@vger.kernel.org; dri-devel@lists.freedesktop.org; Doug Ledford 
> ; Leon Romanovsky
> ; Sumit Semwal ; Christian Koenig 
> ; Vetter, Daniel
> 
> Subject: Re: [PATCH v10 4/6] RDMA/mlx5: Support dma-buf based userspace 
> memory region
> 
> On Fri, Nov 13, 2020 at 03:51:20AM +, Xiong, Jianxin wrote:
> 
> > > > +static void mlx5_ib_dmabuf_invalidate_cb(struct
> > > > +dma_buf_attachment
> > > > +*attach) {
> > > > +   struct ib_umem_dmabuf *umem_dmabuf = attach->importer_priv;
> > > > +   struct mlx5_ib_mr *mr = umem_dmabuf->private;
> > > > +
> > > > +   dma_resv_assert_held(umem_dmabuf->attach->dmabuf->resv);
> > > > +
> > > > +   if (mr)
> > >
> > > I don't think this 'if (mr)' test is needed anymore? I certainly
> > > prefer it gone as it is kind of messy. I expect unmapping the dma to 
> > > ensure this function is not running, and won't run again.
> >
> > It is still needed. When the dma-buf moves, the callback function of every 
> > attached importer is invoked, regardless if the importer has
> mapped the dma or not.
> >
> > >
> > > > +/**
> > > > + * mlx5_ib_fence_dmabuf_mr - Stop all access to the dmabuf MR
> > > > + * @mr: to fence
> > > > + *
> > > > + * On return no parallel threads will be touching this MR and no
> > > > +DMA will be
> > > > + * active.
> > > > + */
> > > > +void mlx5_ib_fence_dmabuf_mr(struct mlx5_ib_mr *mr) {
> > > > +   struct ib_umem_dmabuf *umem_dmabuf =
> > > > +to_ib_umem_dmabuf(mr->umem);
> > > > +
> > > > +   /* Prevent new page faults and prefetch requests from 
> > > > succeeding */
> > > > +   xa_erase(>dev->odp_mkeys, mlx5_base_mkey(mr->mmkey.key));
> > > > +
> > > > +   /* Wait for all running page-fault handlers to finish. */
> > > > +   synchronize_srcu(>dev->odp_srcu);
> > > > +
> > > > +   wait_event(mr->q_deferred_work,
> > > > +!atomic_read(>num_deferred_work));
> > > > +
> > > > +   dma_resv_lock(umem_dmabuf->attach->dmabuf->resv, NULL);
> > > > +   mlx5_mr_cache_invalidate(mr);
> > > > +   umem_dmabuf->private = NULL;
> > > > +   ib_umem_dmabuf_unmap_pages(umem_dmabuf);
> > > > +   dma_resv_unlock(umem_dmabuf->attach->dmabuf->resv);
> > > > +
> > > > +   if (!mr->cache_ent) {
> > > > +   mlx5_core_destroy_mkey(mr->dev->mdev, >mmkey);
> > > > +   WARN_ON(mr->descs);
> > > > +   }
> > >
> > > I didn't check carefully, but are you sure this destroy_mkey should be 
> > > here??
> >
> > To my understanding, yes. This is similar to what dma_fence_odp_mr()
> > does, just inlined here since it's not called from other places.
> 
> I think you should put the calls to dma_buf_dynamic_attach() and
> dma_buf_detach() into mlx5, it makes the whole thing a little cleaner, then 
> the umem->private isn't needed any more either.

Putting these calls into mlx5 can remove the 'ops' parameter from the umem_get 
call,
but I don't see how umem->private can be eliminated. In addition, I feel 
keeping these
two calls in the core provides a better separation between the core and the 
driver -- 
dma-buf API functions are only called from the core, except for 
locking/unlocking.

The 'if (mr)' part in the callback can be removed by adding a line
'if (!umem_dmabutf->sgt) return;' before that if that makes a difference. 

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


Re: [PATCH 26/40] drm/amd/amdgpu/amdgpu_gmc: Demote one and fix another function header

2020-11-13 Thread Alex Deucher
On Fri, Nov 13, 2020 at 8:50 AM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c:69: warning: Function parameter or 
> member 'bo' not described in 'amdgpu_gmc_pd_addr'
>  drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c:121: warning: Function parameter or 
> member 'bo' not described in 'amdgpu_gmc_agp_addr'
>  drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c:121: warning: Excess function 
> parameter 'tbo' description in 'amdgpu_gmc_agp_addr'
>
> Cc: Alex Deucher 
> Cc: "Christian König" 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: amd-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Lee Jones 

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
> index 056cb87d09ea3..fede84509dbca 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
> @@ -61,9 +61,8 @@ void amdgpu_gmc_get_pde_for_bo(struct amdgpu_bo *bo, int 
> level,
> amdgpu_gmc_get_vm_pde(adev, level, addr, flags);
>  }
>
> -/**
> +/*
>   * amdgpu_gmc_pd_addr - return the address of the root directory
> - *
>   */
>  uint64_t amdgpu_gmc_pd_addr(struct amdgpu_bo *bo)
>  {
> @@ -112,7 +111,7 @@ int amdgpu_gmc_set_pte_pde(struct amdgpu_device *adev, 
> void *cpu_pt_addr,
>  /**
>   * amdgpu_gmc_agp_addr - return the address in the AGP address space
>   *
> - * @tbo: TTM BO which needs the address, must be in GTT domain
> + * @bo: TTM BO which needs the address, must be in GTT domain
>   *
>   * Tries to figure out how to access the BO through the AGP aperture. Returns
>   * AMDGPU_BO_INVALID_OFFSET if that is not possible.
> --
> 2.25.1
>
> ___
> 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 25/40] drm/amd/amdgpu/amdgpu_debugfs: Demote obvious abuse of kernel-doc formatting

2020-11-13 Thread Alex Deucher
On Fri, Nov 13, 2020 at 8:50 AM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:308: warning: Function parameter 
> or member 'f' not described in 'amdgpu_debugfs_regs_read'
>  drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:308: warning: Function parameter 
> or member 'buf' not described in 'amdgpu_debugfs_regs_read'
>  drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:308: warning: Function parameter 
> or member 'size' not described in 'amdgpu_debugfs_regs_read'
>  drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:308: warning: Function parameter 
> or member 'pos' not described in 'amdgpu_debugfs_regs_read'
>  drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:317: warning: Function parameter 
> or member 'f' not described in 'amdgpu_debugfs_regs_write'
>  drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:317: warning: Function parameter 
> or member 'buf' not described in 'amdgpu_debugfs_regs_write'
>  drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:317: warning: Function parameter 
> or member 'size' not described in 'amdgpu_debugfs_regs_write'
>  drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:317: warning: Function parameter 
> or member 'pos' not described in 'amdgpu_debugfs_regs_write'
>
> Cc: Alex Deucher 
> Cc: "Christian König" 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Sumit Semwal 
> Cc: amd-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-me...@vger.kernel.org
> Cc: linaro-mm-...@lists.linaro.org
> Signed-off-by: Lee Jones 

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> index 5c1f3725c7410..a6667a2ca0db3 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> @@ -300,7 +300,7 @@ static int  amdgpu_debugfs_process_reg_op(bool read, 
> struct file *f,
> return result;
>  }
>
> -/**
> +/*
>   * amdgpu_debugfs_regs_read - Callback for reading MMIO registers
>   */
>  static ssize_t amdgpu_debugfs_regs_read(struct file *f, char __user *buf,
> @@ -309,7 +309,7 @@ static ssize_t amdgpu_debugfs_regs_read(struct file *f, 
> char __user *buf,
> return amdgpu_debugfs_process_reg_op(true, f, buf, size, pos);
>  }
>
> -/**
> +/*
>   * amdgpu_debugfs_regs_write - Callback for writing MMIO registers
>   */
>  static ssize_t amdgpu_debugfs_regs_write(struct file *f, const char __user 
> *buf,
> --
> 2.25.1
>
> ___
> 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 24/40] drm/amd/amdgpu/amdgpu_ids: Supply missing docs for 'id' and 'vmhub'

2020-11-13 Thread Alex Deucher
On Fri, Nov 13, 2020 at 8:50 AM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c:271: warning: Function parameter or 
> member 'id' not described in 'amdgpu_vmid_grab_reserved'
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c:523: warning: Function parameter or 
> member 'vmhub' not described in 'amdgpu_vmid_reset'
>
> Cc: Alex Deucher 
> Cc: "Christian König" 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Sumit Semwal 
> Cc: Felix Kuehling 
> Cc: amd-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-me...@vger.kernel.org
> Cc: linaro-mm-...@lists.linaro.org
> Signed-off-by: Lee Jones 

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c
> index 6e9a9e5dbea07..61a1331f482c5 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c
> @@ -259,6 +259,7 @@ static int amdgpu_vmid_grab_idle(struct amdgpu_vm *vm,
>   * @sync: sync object where we add dependencies
>   * @fence: fence protecting ID from reuse
>   * @job: job who wants to use the VMID
> + * @id: resulting VMID
>   *
>   * Try to assign a reserved VMID.
>   */
> @@ -514,6 +515,7 @@ void amdgpu_vmid_free_reserved(struct amdgpu_device *adev,
>   * amdgpu_vmid_reset - reset VMID to zero
>   *
>   * @adev: amdgpu device structure
> + * @vmhub: vmhub type
>   * @vmid: vmid number to use
>   *
>   * Reset saved GDW, GWS and OA to force switch on next flush.
> --
> 2.25.1
>
> ___
> 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 22/40] drm/amd/amdgpu/amdgpu_sched: Consume our own header containing prototypes

2020-11-13 Thread Alex Deucher
On Fri, Nov 13, 2020 at 8:50 AM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/gpu/drm/amd/amdgpu/amdgpu_sched.c:35:5: warning: no previous 
> prototype for ‘amdgpu_to_sched_priority’ [-Wmissing-prototypes]
>  drivers/gpu/drm/amd/amdgpu/amdgpu_sched.c:122:5: warning: no previous 
> prototype for ‘amdgpu_sched_ioctl’ [-Wmissing-prototypes]
>
> Cc: Alex Deucher 
> Cc: "Christian König" 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Luben Tuikov 
> Cc: Andres Rodriguez 
> Cc: amd-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Lee Jones 

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_sched.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_sched.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_sched.c
> index 0da0a0d986720..b7d861ed52849 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_sched.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_sched.c
> @@ -29,7 +29,7 @@
>  #include 
>
>  #include "amdgpu.h"
> -
> +#include "amdgpu_sched.h"
>  #include "amdgpu_vm.h"
>
>  int amdgpu_to_sched_priority(int amdgpu_priority,
> --
> 2.25.1
>
> ___
> 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 29/40] drm/amd/amdgpu/amdgpu_csa: Remove set but unused variable 'r'

2020-11-13 Thread Alex Deucher
On Fri, Nov 13, 2020 at 8:50 AM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c: In function 
> ‘amdgpu_allocate_static_csa’:
>  drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c:40:6: warning: variable ‘r’ set but 
> not used [-Wunused-but-set-variable]
>
> Cc: Alex Deucher 
> Cc: "Christian König" 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: monk@amd.com
> Cc: amd-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Lee Jones 

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
> index 08047bc4d5886..da21e60bb8272 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
> @@ -37,10 +37,9 @@ uint64_t amdgpu_csa_vaddr(struct amdgpu_device *adev)
>  int amdgpu_allocate_static_csa(struct amdgpu_device *adev, struct amdgpu_bo 
> **bo,
> u32 domain, uint32_t size)
>  {
> -   int r;
> void *ptr;
>
> -   r = amdgpu_bo_create_kernel(adev, size, PAGE_SIZE,
> +   amdgpu_bo_create_kernel(adev, size, PAGE_SIZE,
> domain, bo,
> NULL, );
> if (!*bo)
> --
> 2.25.1
>
> ___
> 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


[PATCH] drm/fourcc: add table describing AMD modifiers bit layout

2020-11-13 Thread Simon Ser
The table describes how each bit in the u64 value is used. Explicitly
state which values a field can take if we have defines for them. Also
add a note when a field isn't always populated.

Forcing people to update the table when changing the bit layout should
make it more obvious when there's a mistake, I hope.

If we get to the point where the bit layout gets more complicated, it
might be worth it to split the table into multiple tables (e.g. one for
GFX8, one for GFX9+, and so on).

Signed-off-by: Simon Ser 
Cc: Bas Nieuwenhuizen 
Cc: Alex Deucher 
Cc: Daniel Vetter 
---

This already contains the fix in [1].

[1]: https://lists.freedesktop.org/archives/amd-gfx/2020-November/056073.html

 include/uapi/drm/drm_fourcc.h | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index ca48ed0e6bc1..253386b7bc6a 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -1114,6 +1114,25 @@ drm_fourcc_canonicalize_nvidia_format_mod(__u64 modifier)
  *
  * For multi-plane formats the above surfaces get merged into one plane for
  * each format plane, based on the required alignment only.
+ *
+ * Bits  ParameterNotes
+ * -  -
+ *
+ *   7:0 TILE_VERSION Values are AMD_FMT_MOD_TILE_VER_*
+ *  12:8 TILE Values are AMD_FMT_MOD_TILE__*
+ *13 DCC
+ *14 DCC_RETILE
+ *15 DCC_PIPE_ALIGN
+ *16 DCC_INDEPENDENT_64B
+ *17 DCC_INDEPENDENT_128B
+ * 19:18 DCC_MAX_COMPRESSED_BLOCK Values are AMD_FMT_MOD_DCC_BLOCK_*
+ *20 DCC_CONSTANT_ENCODE
+ * 23:21 PIPE_XOR_BITSOnly for some chips
+ * 26:24 BANK_XOR_BITSOnly for some chips
+ * 29:27 PACKERS  Only for some chips
+ * 32:30 RB   Only for some chips
+ * 35:33 PIPE Only for some chips
+ * 55:36 -Reserved for future use, must be zero
  */
 #define AMD_FMT_MOD fourcc_mod_code(AMD, 0)
 
-- 
2.29.2


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


Re: [PATCH 21/40] drm/amd/amdgpu/amdgpu_virt: Make local function 'amdgpu_virt_update_vf2pf_work_item()' static

2020-11-13 Thread Alex Deucher
On Fri, Nov 13, 2020 at 8:50 AM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c:560:6: warning: no previous 
> prototype for ‘amdgpu_virt_update_vf2pf_work_item’ [-Wmissing-prototypes]
>
> Cc: Alex Deucher 
> Cc: "Christian König" 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: amd-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Lee Jones 

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> index 8aff6ef50f918..905b85391e64a 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> @@ -557,7 +557,7 @@ static int amdgpu_virt_write_vf2pf_data(struct 
> amdgpu_device *adev)
> return 0;
>  }
>
> -void amdgpu_virt_update_vf2pf_work_item(struct work_struct *work)
> +static void amdgpu_virt_update_vf2pf_work_item(struct work_struct *work)
>  {
> struct amdgpu_device *adev = container_of(work, struct amdgpu_device, 
> virt.vf2pf_work.work);
>
> --
> 2.25.1
>
> ___
> 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 19/40] drm/amd/amdgpu/amdgpu_vram_mgr: Add missing descriptions for 'dev' and 'dir'

2020-11-13 Thread Alex Deucher
On Fri, Nov 13, 2020 at 8:50 AM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:648: warning: Function 
> parameter or member 'dev' not described in 'amdgpu_vram_mgr_free_sgt'
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:648: warning: Function 
> parameter or member 'dir' not described in 'amdgpu_vram_mgr_free_sgt'
>
> Cc: Alex Deucher 
> Cc: "Christian König" 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: amd-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Lee Jones 

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> index c99c2180785fe..d2de2a720a3d8 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> @@ -637,6 +637,8 @@ int amdgpu_vram_mgr_alloc_sgt(struct amdgpu_device *adev,
>   * amdgpu_vram_mgr_free_sgt - allocate and fill a sg table
>   *
>   * @adev: amdgpu device pointer
> + * @dev: device pointer
> + * @dir: data direction of resource to unmap
>   * @sgt: sg table to free
>   *
>   * Free a previously allocate sg table.
> --
> 2.25.1
>
> ___
> 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 16/40] drm/amd/amdgpu/amdgpu_sync: Fix misnamed, missing and extra param descriptions

2020-11-13 Thread Alex Deucher
On Fri, Nov 13, 2020 at 8:50 AM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c:86: warning: Function parameter or 
> member 'f' not described in 'amdgpu_sync_get_owner'
>  drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c:86: warning: Excess function 
> parameter 'fence' description in 'amdgpu_sync_get_owner'
>  drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c:182: warning: Excess function 
> parameter 'adev' description in 'amdgpu_sync_vm_fence'
>  drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c:203: warning: Function parameter or 
> member 'adev' not described in 'amdgpu_sync_resv'
>
> Cc: Alex Deucher 
> Cc: "Christian König" 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Sumit Semwal 
> Cc: Felix Kuehling 
> Cc: amd-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-me...@vger.kernel.org
> Cc: linaro-mm-...@lists.linaro.org
> Signed-off-by: Lee Jones 

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c
> index 8ea6c49529e7d..4e558632a5d2b 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c
> @@ -78,7 +78,7 @@ static bool amdgpu_sync_same_dev(struct amdgpu_device *adev,
>  /**
>   * amdgpu_sync_get_owner - extract the owner of a fence
>   *
> - * @fence: fence get the owner from
> + * @f: fence get the owner from
>   *
>   * Extract who originally created the fence.
>   */
> @@ -172,7 +172,6 @@ int amdgpu_sync_fence(struct amdgpu_sync *sync, struct 
> dma_fence *f)
>  /**
>   * amdgpu_sync_vm_fence - remember to sync to this VM fence
>   *
> - * @adev: amdgpu device
>   * @sync: sync object to add fence to
>   * @fence: the VM fence to add
>   *
> @@ -190,6 +189,7 @@ int amdgpu_sync_vm_fence(struct amdgpu_sync *sync, struct 
> dma_fence *fence)
>  /**
>   * amdgpu_sync_resv - sync to a reservation object
>   *
> + * @adev: amdgpu device
>   * @sync: sync object to add fences from reservation object to
>   * @resv: reservation object with embedded fence
>   * @mode: how owner affects which fences we sync to
> --
> 2.25.1
>
> ___
> 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 11/40] drm/amd/amdgpu/amdgpu_pll: Fix kernel-doc formatting, missing and extra params

2020-11-13 Thread Alex Deucher
On Fri, Nov 13, 2020 at 8:50 AM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/gpu/drm/amd/amdgpu/amdgpu_pll.c:121: warning: Function parameter or 
> member 'freq' not described in 'amdgpu_pll_compute'
>  drivers/gpu/drm/amd/amdgpu/amdgpu_pll.c:121: warning: Function parameter or 
> member 'fb_div_p' not described in 'amdgpu_pll_compute'
>  drivers/gpu/drm/amd/amdgpu/amdgpu_pll.c:121: warning: Function parameter or 
> member 'frac_fb_div_p' not described in 'amdgpu_pll_compute'
>  drivers/gpu/drm/amd/amdgpu/amdgpu_pll.c:121: warning: Function parameter or 
> member 'ref_div_p' not described in 'amdgpu_pll_compute'
>  drivers/gpu/drm/amd/amdgpu/amdgpu_pll.c:121: warning: Function parameter or 
> member 'post_div_p' not described in 'amdgpu_pll_compute'
>  drivers/gpu/drm/amd/amdgpu/amdgpu_pll.c:317: warning: Excess function 
> parameter 'encoder' description in 'amdgpu_pll_get_shared_nondp_ppll'
>
> Cc: Alex Deucher 
> Cc: "Christian König" 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: amd-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Lee Jones 

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_pll.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pll.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_pll.c
> index 1f2305b7bd135..f2e20666c9c1b 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pll.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pll.c
> @@ -102,11 +102,12 @@ static void amdgpu_pll_get_fb_ref_div(unsigned nom, 
> unsigned den, unsigned post_
>   * amdgpu_pll_compute - compute PLL paramaters
>   *
>   * @pll: information about the PLL
> + * @freq: requested frequency
>   * @dot_clock_p: resulting pixel clock
> - * fb_div_p: resulting feedback divider
> - * frac_fb_div_p: fractional part of the feedback divider
> - * ref_div_p: resulting reference divider
> - * post_div_p: resulting reference divider
> + * @fb_div_p: resulting feedback divider
> + * @frac_fb_div_p: fractional part of the feedback divider
> + * @ref_div_p: resulting reference divider
> + * @post_div_p: resulting reference divider
>   *
>   * Try to calculate the PLL parameters to generate the given frequency:
>   * dot_clock = (ref_freq * feedback_div) / (ref_div * post_div)
> @@ -308,7 +309,6 @@ int amdgpu_pll_get_shared_dp_ppll(struct drm_crtc *crtc)
>   * amdgpu_pll_get_shared_nondp_ppll - return the PPLL used by another non-DP 
> crtc
>   *
>   * @crtc: drm crtc
> - * @encoder: drm encoder
>   *
>   * Returns the PPLL (Pixel PLL) used by another non-DP crtc/encoder which can
>   * be shared (i.e., same clock).
> --
> 2.25.1
>
> ___
> 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 08/40] drm/amd/amdgpu/amdgpu_ib: Fix some incorrect/incomplete function documentation

2020-11-13 Thread Alex Deucher
On Fri, Nov 13, 2020 at 8:50 AM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c:66: warning: Function parameter or 
> member 'adev' not described in 'amdgpu_ib_get'
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c:66: warning: Function parameter or 
> member 'vm' not described in 'amdgpu_ib_get'
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c:66: warning: Function parameter or 
> member 'pool_type' not described in 'amdgpu_ib_get'
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c:66: warning: Excess function 
> parameter 'ring' description in 'amdgpu_ib_get'
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c:125: warning: Function parameter or 
> member 'ring' not described in 'amdgpu_ib_schedule'
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c:125: warning: Function parameter or 
> member 'job' not described in 'amdgpu_ib_schedule'
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c:125: warning: Excess function 
> parameter 'adev' description in 'amdgpu_ib_schedule'
>
> Cc: Alex Deucher 
> Cc: "Christian König" 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Sumit Semwal 
> Cc: amd-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-me...@vger.kernel.org
> Cc: linaro-mm-...@lists.linaro.org
> Signed-off-by: Lee Jones 

Applied. Thanks!

Alex


> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
> index 2f53fa0ae9a62..c69af9b86cc60 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
> @@ -52,8 +52,10 @@
>  /**
>   * amdgpu_ib_get - request an IB (Indirect Buffer)
>   *
> - * @ring: ring index the IB is associated with
> + * @adev: amdgpu_device pointer
> + * @vm: amdgpu_vm pointer
>   * @size: requested IB size
> + * @pool_type: IB pool type (delayed, immediate, direct)
>   * @ib: IB object returned
>   *
>   * Request an IB (all asics).  IBs are allocated using the
> @@ -101,7 +103,7 @@ void amdgpu_ib_free(struct amdgpu_device *adev, struct 
> amdgpu_ib *ib,
>  /**
>   * amdgpu_ib_schedule - schedule an IB (Indirect Buffer) on the ring
>   *
> - * @adev: amdgpu_device pointer
> + * @ring: ring index the IB is associated with
>   * @num_ibs: number of IBs to schedule
>   * @ibs: IB objects to schedule
>   * @f: fence created during this submission
> --
> 2.25.1
>
> ___
> 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 05/40] drm/amd/amdgpu/amdgpu_ring: Fix misnaming of param 'max_dw'

2020-11-13 Thread Alex Deucher
On Fri, Nov 13, 2020 at 8:50 AM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:168: warning: Function parameter or 
> member 'max_dw' not described in 'amdgpu_ring_init'
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:168: warning: Excess function 
> parameter 'max_ndw' description in 'amdgpu_ring_init'
>
> Cc: Alex Deucher 
> Cc: "Christian König" 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Sumit Semwal 
> Cc: amd-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-me...@vger.kernel.org
> Cc: linaro-mm-...@lists.linaro.org
> Signed-off-by: Lee Jones 

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c
> index a23b2079696a1..1a612f51ecd9e 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c
> @@ -154,7 +154,7 @@ void amdgpu_ring_undo(struct amdgpu_ring *ring)
>   *
>   * @adev: amdgpu_device pointer
>   * @ring: amdgpu_ring structure holding ring information
> - * @max_ndw: maximum number of dw for ring alloc
> + * @max_dw: maximum number of dw for ring alloc
>   * @irq_src: interrupt source to use for this ring
>   * @irq_type: interrupt type to use for this ring
>   * @hw_prio: ring priority (NORMAL/HIGH)
> --
> 2.25.1
>
> ___
> 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 v4 1/1] lib/vsprintf: Add support for printing V4L2 and DRM fourccs

2020-11-13 Thread Joe Perches
On Fri, 2020-11-13 at 12:54 +0200, Sakari Ailus wrote:
> Hi Joe,
> 
> On Tue, Nov 03, 2020 at 08:49:36AM -0800, Joe Perches wrote:
> > On Tue, 2020-11-03 at 16:56 +0200, Sakari Ailus wrote:
> > > On Tue, Nov 03, 2020 at 04:47:47PM +0200, Andy Shevchenko wrote:
> > > > On Tue, Nov 03, 2020 at 03:34:00PM +0200, Sakari Ailus wrote:
> > > > > Add a printk modifier %p4cc (for pixel format) for printing V4L2 and 
> > > > > DRM
> > > > > pixel formats denoted by fourccs. The fourcc encoding is the same for 
> > > > > both
> > > > > so the same implementation can be used.
> > > > 
> > > > ...
> > > > 
> > > > > +static noinline_for_stack
> > > > > +char *fourcc_string(char *buf, char *end, const u32 *fourcc,
> > > > > + struct printf_spec spec, const char *fmt)
> > > > > +{
> > > > > + char output[sizeof("(xx)(xx)(xx)(xx) little-endian 
> > > > > (0x01234567)")];
> > > > 
> > > > I would add a comment that there is another possibility, i.e. 
> > > > big-endian, but
> > > > it occupies less space.
> > 
> > I think it's unnecessary as it's obvious and similarly done in other
> > _string type functions.
> > 
> > > > > + p = special_hex_number(p, output + sizeof(output) - 2, *fourcc,
> > > > > +sizeof(u32));
> > > > 
> > > > I would go with one line here.
> > > 
> > > It's wrapped since the result would be over 80 otherwise.
> > 
> > Perhaps simpler as
> > 
> > p = special_hex_number(p, p + 10, *fourcc, sizeof(u32));
> 
> Yes. But having bugs elsewhere would have a magnified effect.

How's that?  Where would "elsewhere" be?

> I wouldn't be afraid of a newline here.

I'd prefer obvious code instead of indirected p vs output
and having to lookup whatever output is again.

special_hex_number is already known to fit in the buffer.

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


Re: [PATCH v1 00/30] Introduce core voltage scaling for NVIDIA Tegra20/30 SoCs

2020-11-13 Thread Thierry Reding
On Fri, Nov 13, 2020 at 01:14:45AM +0300, Dmitry Osipenko wrote:
> 12.11.2020 23:43, Thierry Reding пишет:
> >> The difference in comparison to using voltage regulator directly is
> >> minimal, basically the core-supply phandle is replaced is replaced with
> >> a power-domain phandle in a device tree.
> > These new power-domain handles would have to be added to devices that
> > potentially already have a power-domain handle, right? Isn't that going
> > to cause issues? I vaguely recall that we already have multiple power
> > domains for the XUSB controller and we have to jump through extra hoops
> > to make that work.
> 
> I modeled the core PD as a parent of the PMC sub-domains, which
> presumably is a correct way to represent the domains topology.
> 
> https://gist.github.com/digetx/dfd92c7f7e0aa6cef20403c4298088d7
> 
> >> The only thing which makes me feel a bit uncomfortable is that there is
> >> no real hardware node for the power domain node in a device-tree.
> > Could we anchor the new power domain at the PMC for example? That would
> > allow us to avoid the "virtual" node.
> 
> I had a thought about using PMC for the core domain, but not sure
> whether it will be an entirely correct hardware description. Although,
> it will be nice to have it this way.
> 
> This is what Tegra TRM says about PMC:
> 
> "The Power Management Controller (PMC) block interacts with an external
> or Power Manager Unit (PMU). The PMC mostly controls the entry and exit
> of the system from different sleep modes. It provides power-gating
> controllers for SOC and CPU power-islands and also provides scratch
> storage to save some of the context during sleep modes (when CPU and/or
> SOC power rails are off). Additionally, PMC interacts with the external
> Power Manager Unit (PMU)."
> 
> The core voltage regulator is a part of the PMU.
> 
> Not all core SoC devices are behind PMC, IIUC.

There are usually some SoC devices that are always-on. Things like the
RTC for example, can never be power-gated, as far as I recall. On newer
chips there are usually many more blocks that can't be powergated at
all.

> > On the other hand, if we were to
> > use a regulator, we'd be adding a node for that, right? So isn't this
> > effectively going to be the same node if we use a power domain? Both
> > software constructs are using the same voltage regulator, so they should
> > be able to be described by the same device tree node, shouldn't they?
> 
> I'm not exactly sure what you're meaning by "use a regulator" and "we'd
> be adding a node for that", could you please clarify? This v1 approach
> uses a core-supply phandle (i.e. regulator is used), it doesn't require
> extra nodes.

What I meant to say was that the actual supply voltage is generated by
some device (typically one of the SD outputs of the PMIC). Whether we
model this as a power domain or a regulator doesn't really matter,
right? So I'm wondering if the device that generates the voltage should
be the power domain provider, just like it is the provider of the
regulator if this was modelled as a regulator.

Thierry


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


Re: [PATCH 4/7] drm/radeon: Pin buffers while they are vmap'ed

2020-11-13 Thread Thomas Zimmermann
Hi

Am 16.11.20 um 12:28 schrieb Christian König:
> Am 13.11.20 um 08:59 schrieb Thomas Zimmermann:
>> Hi Christian
>>
>> Am 12.11.20 um 18:16 schrieb Christian König:
>>> Am 12.11.20 um 14:21 schrieb Thomas Zimmermann:
 In order to avoid eviction of vmap'ed buffers, pin them in their GEM
 object's vmap implementation. Unpin them in the vunmap implementation.
 This is needed to make generic fbdev support work reliably. Without,
 the buffer object could be evicted while fbdev flushed its shadow
 buffer.

 In difference to the PRIME pin/unpin functions, the vmap code does not
 modify the BOs prime_shared_count, so a vmap-pinned BO does not
 count as
 shared.

 The actual pin location is not important as the vmap call returns
 information on how to access the buffer. Callers that require a
 specific location should explicitly pin the BO before vmapping it.
>>> Well is the buffer supposed to be scanned out?
>> No, not by the fbdev helper.
> 
> Ok in this case that should work.
> 
>>> If yes then the pin location is actually rather important since the
>>> hardware can only scan out from VRAM.
>> For relocatable BOs, fbdev uses a shadow buffer that makes all any
>> relocation transparent to userspace. It flushes the shadow fb into the
>> BO's memory if there are updates. The code is in
>> drm_fb_helper_dirty_work(). [1] During the flush operation, the vmap
>> call now pins the BO to wherever it is. The actual location does not
>> matter. It's vunmap'ed immediately afterwards.
> 
> The problem is what happens when it is prepared for scanout, but can't
> be moved to VRAM because it is vmapped?
> 
> When the shadow is never scanned out that isn't a problem, but we need
> to keep that in mind.

If this is a problem is practice, it has never shown up with the drivers
that use it already.

I think here's a modeset lock somewhere that could serialize these
operations. The fbdev console is not double buffered, so there's no
frequent pageflipping; hence interference should be small.

Best regards
Thomas

> 
> Regards,
> Christian.
> 
>>
>> For dma-buf sharing, the regular procedure of pin + vmap still apply.
>> This should always move the BO into GTT-managed memory.
>>
>> Best regards
>> Thomas
>>
>> [1]
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git%2Ftree%2Fdrivers%2Fgpu%2Fdrm%2Fdrm_fb_helper.c%23n432data=04%7C01%7Cchristian.koenig%40amd.com%7C31b890664ca7429fc45808d887aa0842%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637408511650629569%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=RLauuAuXkcl0rXwWWJ%2FrKP%2BsCr2wAzU1ejGV1bnQ80w%3Dreserved=0
>>
>>
>>> Regards,
>>> Christian.
>>>
 Signed-off-by: Thomas Zimmermann 
 ---
    drivers/gpu/drm/radeon/radeon_gem.c | 51
 +++--
    1 file changed, 49 insertions(+), 2 deletions(-)

 diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
 b/drivers/gpu/drm/radeon/radeon_gem.c
 index d2876ce3bc9e..eaf7fc9a7b07 100644
 --- a/drivers/gpu/drm/radeon/radeon_gem.c
 +++ b/drivers/gpu/drm/radeon/radeon_gem.c
 @@ -226,6 +226,53 @@ static int radeon_gem_handle_lockup(struct
 radeon_device *rdev, int r)
    return r;
    }
    +static int radeon_gem_object_vmap(struct drm_gem_object *obj,
 struct dma_buf_map *map)
 +{
 +    static const uint32_t any_domain = RADEON_GEM_DOMAIN_VRAM |
 +   RADEON_GEM_DOMAIN_GTT |
 +   RADEON_GEM_DOMAIN_CPU;
 +
 +    struct radeon_bo *bo = gem_to_radeon_bo(obj);
 +    int ret;
 +
 +    ret = radeon_bo_reserve(bo, false);
 +    if (ret)
 +    return ret;
 +
 +    /* pin buffer at its current location */
 +    ret = radeon_bo_pin(bo, any_domain, NULL);
 +    if (ret)
 +    goto err_radeon_bo_unreserve;
 +
 +    ret = drm_gem_ttm_vmap(obj, map);
 +    if (ret)
 +    goto err_radeon_bo_unpin;
 +
 +    radeon_bo_unreserve(bo);
 +
 +    return 0;
 +
 +err_radeon_bo_unpin:
 +    radeon_bo_unpin(bo);
 +err_radeon_bo_unreserve:
 +    radeon_bo_unreserve(bo);
 +    return ret;
 +}
 +
 +static void radeon_gem_object_vunmap(struct drm_gem_object *obj,
 struct dma_buf_map *map)
 +{
 +    struct radeon_bo *bo = gem_to_radeon_bo(obj);
 +    int ret;
 +
 +    ret = radeon_bo_reserve(bo, false);
 +    if (ret)
 +    return;
 +
 +    drm_gem_ttm_vunmap(obj, map);
 +    radeon_bo_unpin(bo);
 +    radeon_bo_unreserve(bo);
 +}
 +
    static const struct drm_gem_object_funcs radeon_gem_object_funcs = {
    .free = radeon_gem_object_free,
    .open = radeon_gem_object_open,
 @@ -234,8 +281,8 @@ static const struct 

[PATCH] drm/fourcc: Fix modifier field mask for AMD modifiers.

2020-11-13 Thread Bas Nieuwenhuizen
The DCC_MAX_COMPRESSED_BLOCK has to contain one of
AMD_FMT_MOD_DCC_BLOCK_* and with 3 values this doesn't
fit in 1 bit.

Fix this cleanly while it is only in drm-next.

Fixes: 8ba16d5993749c3f31fd2b49e16f0dc1e1770b9c
---

Found while reviewing Simon's drm_info PR: 
https://github.com/ascent12/drm_info/pull/63/commits/eaeae6ee78764a03d959cbc97c8b514f81a94c63

 include/uapi/drm/drm_fourcc.h | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index df56e71a7380..a878664ba41c 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -1129,7 +1129,7 @@ drm_fourcc_canonicalize_nvidia_format_mod(__u64 modifier)
 #define AMD_FMT_MOD_DCC_INDEPENDENT_128B_SHIFT 17
 #define AMD_FMT_MOD_DCC_INDEPENDENT_128B_MASK 0x1
 #define AMD_FMT_MOD_DCC_MAX_COMPRESSED_BLOCK_SHIFT 18
-#define AMD_FMT_MOD_DCC_MAX_COMPRESSED_BLOCK_MASK 0x1
+#define AMD_FMT_MOD_DCC_MAX_COMPRESSED_BLOCK_MASK 0x3
 
 /*
  * DCC supports embedding some clear colors directly in the DCC surface.
@@ -1140,7 +1140,7 @@ drm_fourcc_canonicalize_nvidia_format_mod(__u64 modifier)
  * If this bit is set that means the fastclear eliminate is not needed for 
these
  * embeddable colors.
  */
-#define AMD_FMT_MOD_DCC_CONSTANT_ENCODE_SHIFT 19
+#define AMD_FMT_MOD_DCC_CONSTANT_ENCODE_SHIFT 20
 #define AMD_FMT_MOD_DCC_CONSTANT_ENCODE_MASK 0x1
 
 /*
@@ -1153,15 +1153,15 @@ drm_fourcc_canonicalize_nvidia_format_mod(__u64 
modifier)
  * RB = only for TILE_VER_GFX9 & DCC
  * PIPE = only for TILE_VER_GFX9 & DCC & (DCC_RETILE | DCC_PIPE_ALIGN)
  */
-#define AMD_FMT_MOD_PIPE_XOR_BITS_SHIFT 20
+#define AMD_FMT_MOD_PIPE_XOR_BITS_SHIFT 21
 #define AMD_FMT_MOD_PIPE_XOR_BITS_MASK 0x7
-#define AMD_FMT_MOD_BANK_XOR_BITS_SHIFT 23
+#define AMD_FMT_MOD_BANK_XOR_BITS_SHIFT 24
 #define AMD_FMT_MOD_BANK_XOR_BITS_MASK 0x7
-#define AMD_FMT_MOD_PACKERS_SHIFT 26 /* aliases with BANK_XOR_BITS */
+#define AMD_FMT_MOD_PACKERS_SHIFT 27 /* aliases with BANK_XOR_BITS */
 #define AMD_FMT_MOD_PACKERS_MASK 0x7
-#define AMD_FMT_MOD_RB_SHIFT 29
+#define AMD_FMT_MOD_RB_SHIFT 30
 #define AMD_FMT_MOD_RB_MASK 0x7
-#define AMD_FMT_MOD_PIPE_SHIFT 32
+#define AMD_FMT_MOD_PIPE_SHIFT 33
 #define AMD_FMT_MOD_PIPE_MASK 0x7
 
 #define AMD_FMT_MOD_SET(field, value) \
-- 
2.29.2

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


Re: [PATCH v1 11/30] drm/tegra: dc: Support OPP and SoC core voltage scaling

2020-11-13 Thread Mark Brown
On Fri, Nov 13, 2020 at 06:55:27PM +0300, Dmitry Osipenko wrote:
> 13.11.2020 17:29, Mark Brown пишет:

> > It's not clear if it matters - it's more a policy decision on the part
> > of the driver about what it thinks safe error handling is.  If it's not

> If regulator_get() returns a dummy regulator, then this means that
> regulator isn't specified in a device-tree. But then the only way for a
> consumer driver to check whether regulator is dummy, is to check
> presence of the supply property in a device-tree.

My point here is that the driver shouldn't be checking for a dummy
regulator, the driver should be checking the features that are provided
to it by the regulator and handling those.  It doesn't matter if this is
a dummy regulator or an actual regulator with limited features, the
effect is the same and the handling should be the same.  If the driver
is doing anything to handle dummy regulators explicitly as dummy
regulators it is doing it wrong.

> We want to emit error messages when something goes wrong, for example
> when regulator voltage fails to change. It's fine that voltage changes
> are failing for a dummy regulator, but then consumer driver shouldn't
> recognize it as a error condition.

If you're fine with that you should also be fine with any other
regulator for which you failed to enumerate any voltages which you can
set.

> The regulator_get_optional() provides a more consistent and
> straightforward way for consumer drivers to check presence of a physical
> voltage regulator in comparison to dealing with a regulator_get(). The
> dummy regulator is nice to use when there is no need to change
> regulator's voltage, which doesn't work for a dummy regulator.

To repeat you should *only* be using regulator_get_optional() in the
case where the supply may be physically absent which is not the case
here.


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


Re: [PATCH 02/40] drm/amd/display/dc/core/dc_link_dp: Move DP_VGA_LVDS_CONVERTER_ID_{2, 3} to where they're used

2020-11-13 Thread Lee Jones
On Fri, 13 Nov 2020, Alex Deucher wrote:

> On Fri, Nov 13, 2020 at 8:49 AM Lee Jones  wrote:
> >
> > This patch fixes >200 warnings.
> >
> > Fixes the following W=1 kernel build warning(s):
> >
> >  drivers/gpu/drm/amd/amdgpu/../display/include/ddc_service_types.h:123:22: 
> > warning: ‘DP_VGA_LVDS_CONVERTER_ID_3’ defined but not used 
> > [-Wunused-const-variable=]
> >  123 | static const uint8_t DP_VGA_LVDS_CONVERTER_ID_3[] = "dnomlA";
> >  | ^~
> >  drivers/gpu/drm/amd/amdgpu/../display/include/ddc_service_types.h:121:22: 
> > warning: ‘DP_VGA_LVDS_CONVERTER_ID_2’ defined but not used 
> > [-Wunused-const-variable=]
> >  121 | static const uint8_t DP_VGA_LVDS_CONVERTER_ID_2[] = "sivarT";
> >
> > NB: Repeated ~100 times - snipped for brevity
> >
> > Cc: Harry Wentland 
> > Cc: Leo Li 
> > Cc: Alex Deucher 
> > Cc: "Christian König" 
> > Cc: David Airlie 
> > Cc: Daniel Vetter 
> > Cc: amd-...@lists.freedesktop.org
> > Cc: dri-devel@lists.freedesktop.org
> > Signed-off-by: Lee Jones 
> > ---
> >  drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c| 5 +
> >  drivers/gpu/drm/amd/display/include/ddc_service_types.h | 4 
> >  2 files changed, 5 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c 
> > b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> > index 6c60c1fdebdc1..f2023d2b53234 100644
> > --- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> > +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> > @@ -15,6 +15,11 @@
> >  #include "dc_dmub_srv.h"
> >  #include "dce/dmub_hw_lock_mgr.h"
> >
> > +/*Travis*/
> > +static const uint8_t DP_VGA_LVDS_CONVERTER_ID_2[] = "sivarT";
> > +/*Nutmeg*/
> > +static const uint8_t DP_VGA_LVDS_CONVERTER_ID_3[] = "dnomlA";
> > +
> >  #define DC_LOGGER \
> > link->ctx->logger
> >  #define DC_TRACE_LEVEL_MESSAGE(...) /* do nothing */
> > diff --git a/drivers/gpu/drm/amd/display/include/ddc_service_types.h 
> > b/drivers/gpu/drm/amd/display/include/ddc_service_types.h
> > index c9be899cd25cd..b453ce5a9bfdb 100644
> > --- a/drivers/gpu/drm/amd/display/include/ddc_service_types.h
> > +++ b/drivers/gpu/drm/amd/display/include/ddc_service_types.h
> > @@ -117,10 +117,6 @@ struct av_sync_data {
> > uint8_t aud_del_ins3;/* DPCD 0002Dh */
> >  };
> >
> > -/*Travis*/
> > -static const uint8_t DP_VGA_LVDS_CONVERTER_ID_2[] = "sivarT";
> > -/*Nutmeg*/
> > -static const uint8_t DP_VGA_LVDS_CONVERTER_ID_3[] = "dnomlA";
> >  /*DP to Dual link DVI converter*/
> >  static const uint8_t DP_DVI_CONVERTER_ID_4[] = "m2DVIa";
> >  static const uint8_t DP_DVI_CONVERTER_ID_5[] = "3393N2";
> 
> Can we keep all of these strings together?

I don't think so.  They are consumed by different files.

Oh, one way to do it would be to mark them as __maybe_unused, but
I only tend to do that a last resort.

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 04/40] drm/amd/amdgpu/amdgpu_drv: Move 'amdgpu_info_ioctl()'s prototype to shared header

2020-11-13 Thread Alex Deucher
On Fri, Nov 13, 2020 at 8:49 AM Lee Jones  wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c:486:5: warning: no previous 
> prototype for ‘amdgpu_info_ioctl’ [-Wmissing-prototypes]
>  486 | int amdgpu_info_ioctl(struct drm_device *dev, void *data, struct 
> drm_file *filp)
>  | ^
>
> Cc: Alex Deucher 
> Cc: "Christian König" 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: amd-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Lee Jones 

Luben already sent a patch to fix this one.  I'll be picking up that one.

Alex

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c |  4 +---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c |  1 +
>  drivers/gpu/drm/amd/amdgpu/amdgpu_kms.h | 31 +
>  3 files changed, 33 insertions(+), 3 deletions(-)
>  create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.h
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> index 1dfea15bbec36..afd357df0f886 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> @@ -43,7 +43,7 @@
>  #include "amdgpu_sched.h"
>
>  #include "amdgpu_amdkfd.h"
> -
> +#include "amdgpu_kms.h"
>  #include "amdgpu_ras.h"
>
>  /*
> @@ -1521,8 +1521,6 @@ int amdgpu_file_to_fpriv(struct file *filp, struct 
> amdgpu_fpriv **fpriv)
> return 0;
>  }
>
> -int amdgpu_info_ioctl(struct drm_device *dev, void *data, struct drm_file 
> *filp);
> -
>  const struct drm_ioctl_desc amdgpu_ioctls_kms[] = {
> DRM_IOCTL_DEF_DRV(AMDGPU_GEM_CREATE, amdgpu_gem_create_ioctl, 
> DRM_AUTH|DRM_RENDER_ALLOW),
> DRM_IOCTL_DEF_DRV(AMDGPU_CTX, amdgpu_ctx_ioctl, 
> DRM_AUTH|DRM_RENDER_ALLOW),
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> index 98721ae931841..54c4ee6d230d8 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> @@ -41,6 +41,7 @@
>  #include "amdgpu_amdkfd.h"
>  #include "amdgpu_gem.h"
>  #include "amdgpu_display.h"
> +#include "amdgpu_kms.h"
>  #include "amdgpu_ras.h"
>
>  void amdgpu_unregister_gpu_instance(struct amdgpu_device *adev)
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.h
> new file mode 100644
> index 0..f3111aef76cae
> --- /dev/null
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.h
> @@ -0,0 +1,31 @@
> +/* amdgpu_kms.h -- Private header for radeon driver -*- linux-c -*-
> + *
> + * Copyright 2008 Advanced Micro Devices, Inc.
> + * Copyright 2008 Red Hat Inc.
> + * Copyright 2009 Jerome Glisse.
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
> + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +#ifndef __AMDGPU_KMS_H__
> +#define __AMDGPU_KMS_H__
> +
> +int amdgpu_info_ioctl(struct drm_device *dev, void *data, struct drm_file 
> *filp);
> +
> +#endif /* __AMDGPU_KMS_H__ */
> --
> 2.25.1
>
> ___
> 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: [Freedreno] [PATCH 06/40] drm/msm/adreno/a6xx_gpu: Staticise local function 'a6xx_idle'

2020-11-13 Thread Jordan Crouse
On Fri, Nov 13, 2020 at 01:49:04PM +, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
> 
>  drivers/gpu/drm/msm/adreno/a6xx_gpu.c:33:6: warning: no previous prototype 
> for ‘a6xx_idle’ [-Wmissing-prototypes]
> 
> Cc: Rob Clark 
> Cc: Sean Paul 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: linux-arm-...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: freedr...@lists.freedesktop.org
> Signed-off-by: Lee Jones 

Reviewed-by: Jordan Crouse 
> ---
>  drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c 
> b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> index fcb0aabbc9852..03c2f7e0c9497 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> @@ -30,7 +30,7 @@ static inline bool _a6xx_check_idle(struct msm_gpu *gpu)
>   A6XX_RBBM_INT_0_MASK_RBBM_HANG_DETECT);
>  }
>  
> -bool a6xx_idle(struct msm_gpu *gpu, struct msm_ringbuffer *ring)
> +static bool a6xx_idle(struct msm_gpu *gpu, struct msm_ringbuffer *ring)
>  {
>   /* wait for CP to drain ringbuffer: */
>   if (!adreno_idle(gpu, ring))
> -- 
> 2.25.1
> 
> ___
> Freedreno mailing list
> freedr...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/freedreno

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 03/40] drm/amd/display/dc/core/dc_link_ddc: Move DP_DVI_CONVERTER_ID_{4, 5} to where they're used

2020-11-13 Thread Alex Deucher
On Fri, Nov 13, 2020 at 8:50 AM Lee Jones  wrote:
>
> This patch fixes >200 warnings.
>
> Fixes the following W=1 kernel build warning(s):
>
>  from drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:31:
>  drivers/gpu/drm/amd/amdgpu/../display/include/ddc_service_types.h:126:22: 
> warning: ‘DP_DVI_CONVERTER_ID_5’ defined but not used 
> [-Wunused-const-variable=]
>  126 | static const uint8_t DP_DVI_CONVERTER_ID_5[] = "3393N2";
>  | ^
>  drivers/gpu/drm/amd/amdgpu/../display/include/ddc_service_types.h:125:22: 
> warning: ‘DP_DVI_CONVERTER_ID_4’ defined but not used 
> [-Wunused-const-variable=]
>  125 | static const uint8_t DP_DVI_CONVERTER_ID_4[] = "m2DVIa";
>  | ^
>
> Cc: Harry Wentland 
> Cc: Leo Li 
> Cc: Alex Deucher 
> Cc: "Christian König" 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: amd-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Lee Jones 

Applied.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c   | 4 
>  drivers/gpu/drm/amd/display/include/ddc_service_types.h | 4 
>  2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c 
> b/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c
> index 54beda4d4e85d..c5936e0643606 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c
> @@ -37,6 +37,10 @@
>  #include "dc_link_ddc.h"
>  #include "dce/dce_aux.h"
>
> +/*DP to Dual link DVI converter*/
> +static const uint8_t DP_DVI_CONVERTER_ID_4[] = "m2DVIa";
> +static const uint8_t DP_DVI_CONVERTER_ID_5[] = "3393N2";
> +
>  #define AUX_POWER_UP_WA_DELAY 500
>  #define I2C_OVER_AUX_DEFER_WA_DELAY 70
>  #define I2C_OVER_AUX_DEFER_WA_DELAY_1MS 1
> diff --git a/drivers/gpu/drm/amd/display/include/ddc_service_types.h 
> b/drivers/gpu/drm/amd/display/include/ddc_service_types.h
> index b453ce5a9bfdb..4de59b66bb1a3 100644
> --- a/drivers/gpu/drm/amd/display/include/ddc_service_types.h
> +++ b/drivers/gpu/drm/amd/display/include/ddc_service_types.h
> @@ -117,8 +117,4 @@ struct av_sync_data {
> uint8_t aud_del_ins3;/* DPCD 0002Dh */
>  };
>
> -/*DP to Dual link DVI converter*/
> -static const uint8_t DP_DVI_CONVERTER_ID_4[] = "m2DVIa";
> -static const uint8_t DP_DVI_CONVERTER_ID_5[] = "3393N2";
> -
>  #endif /* __DAL_DDC_SERVICE_TYPES_H__ */
> --
> 2.25.1
>
> ___
> 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 4/7] drm/radeon: Pin buffers while they are vmap'ed

2020-11-13 Thread Christian König

Am 13.11.20 um 08:59 schrieb Thomas Zimmermann:

Hi Christian

Am 12.11.20 um 18:16 schrieb Christian König:

Am 12.11.20 um 14:21 schrieb Thomas Zimmermann:

In order to avoid eviction of vmap'ed buffers, pin them in their GEM
object's vmap implementation. Unpin them in the vunmap implementation.
This is needed to make generic fbdev support work reliably. Without,
the buffer object could be evicted while fbdev flushed its shadow buffer.

In difference to the PRIME pin/unpin functions, the vmap code does not
modify the BOs prime_shared_count, so a vmap-pinned BO does not count as
shared.

The actual pin location is not important as the vmap call returns
information on how to access the buffer. Callers that require a
specific location should explicitly pin the BO before vmapping it.

Well is the buffer supposed to be scanned out?

No, not by the fbdev helper.


Ok in this case that should work.


If yes then the pin location is actually rather important since the
hardware can only scan out from VRAM.

For relocatable BOs, fbdev uses a shadow buffer that makes all any
relocation transparent to userspace. It flushes the shadow fb into the
BO's memory if there are updates. The code is in
drm_fb_helper_dirty_work(). [1] During the flush operation, the vmap
call now pins the BO to wherever it is. The actual location does not
matter. It's vunmap'ed immediately afterwards.


The problem is what happens when it is prepared for scanout, but can't 
be moved to VRAM because it is vmapped?


When the shadow is never scanned out that isn't a problem, but we need 
to keep that in mind.


Regards,
Christian.



For dma-buf sharing, the regular procedure of pin + vmap still apply.
This should always move the BO into GTT-managed memory.

Best regards
Thomas

[1]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git%2Ftree%2Fdrivers%2Fgpu%2Fdrm%2Fdrm_fb_helper.c%23n432data=04%7C01%7Cchristian.koenig%40amd.com%7C31b890664ca7429fc45808d887aa0842%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637408511650629569%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=RLauuAuXkcl0rXwWWJ%2FrKP%2BsCr2wAzU1ejGV1bnQ80w%3Dreserved=0


Regards,
Christian.


Signed-off-by: Thomas Zimmermann 
---
   drivers/gpu/drm/radeon/radeon_gem.c | 51 +++--
   1 file changed, 49 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
b/drivers/gpu/drm/radeon/radeon_gem.c
index d2876ce3bc9e..eaf7fc9a7b07 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -226,6 +226,53 @@ static int radeon_gem_handle_lockup(struct
radeon_device *rdev, int r)
   return r;
   }
   +static int radeon_gem_object_vmap(struct drm_gem_object *obj,
struct dma_buf_map *map)
+{
+    static const uint32_t any_domain = RADEON_GEM_DOMAIN_VRAM |
+   RADEON_GEM_DOMAIN_GTT |
+   RADEON_GEM_DOMAIN_CPU;
+
+    struct radeon_bo *bo = gem_to_radeon_bo(obj);
+    int ret;
+
+    ret = radeon_bo_reserve(bo, false);
+    if (ret)
+    return ret;
+
+    /* pin buffer at its current location */
+    ret = radeon_bo_pin(bo, any_domain, NULL);
+    if (ret)
+    goto err_radeon_bo_unreserve;
+
+    ret = drm_gem_ttm_vmap(obj, map);
+    if (ret)
+    goto err_radeon_bo_unpin;
+
+    radeon_bo_unreserve(bo);
+
+    return 0;
+
+err_radeon_bo_unpin:
+    radeon_bo_unpin(bo);
+err_radeon_bo_unreserve:
+    radeon_bo_unreserve(bo);
+    return ret;
+}
+
+static void radeon_gem_object_vunmap(struct drm_gem_object *obj,
struct dma_buf_map *map)
+{
+    struct radeon_bo *bo = gem_to_radeon_bo(obj);
+    int ret;
+
+    ret = radeon_bo_reserve(bo, false);
+    if (ret)
+    return;
+
+    drm_gem_ttm_vunmap(obj, map);
+    radeon_bo_unpin(bo);
+    radeon_bo_unreserve(bo);
+}
+
   static const struct drm_gem_object_funcs radeon_gem_object_funcs = {
   .free = radeon_gem_object_free,
   .open = radeon_gem_object_open,
@@ -234,8 +281,8 @@ static const struct drm_gem_object_funcs
radeon_gem_object_funcs = {
   .pin = radeon_gem_prime_pin,
   .unpin = radeon_gem_prime_unpin,
   .get_sg_table = radeon_gem_prime_get_sg_table,
-    .vmap = drm_gem_ttm_vmap,
-    .vunmap = drm_gem_ttm_vunmap,
+    .vmap = radeon_gem_object_vmap,
+    .vunmap = radeon_gem_object_vunmap,
   };
     /*

___
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=04%7C01%7Cchristian.koenig%40amd.com%7C31b890664ca7429fc45808d887aa0842%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637408511650629569%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=h1U9Po83K7webxsiKpn3ZGFz9Fcg6SRkxtrXWZ1%2B%2FEc%3Dreserved=0



Re: [PATCH 02/40] drm/amd/display/dc/core/dc_link_dp: Move DP_VGA_LVDS_CONVERTER_ID_{2, 3} to where they're used

2020-11-13 Thread Alex Deucher
On Fri, Nov 13, 2020 at 8:49 AM Lee Jones  wrote:
>
> This patch fixes >200 warnings.
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/gpu/drm/amd/amdgpu/../display/include/ddc_service_types.h:123:22: 
> warning: ‘DP_VGA_LVDS_CONVERTER_ID_3’ defined but not used 
> [-Wunused-const-variable=]
>  123 | static const uint8_t DP_VGA_LVDS_CONVERTER_ID_3[] = "dnomlA";
>  | ^~
>  drivers/gpu/drm/amd/amdgpu/../display/include/ddc_service_types.h:121:22: 
> warning: ‘DP_VGA_LVDS_CONVERTER_ID_2’ defined but not used 
> [-Wunused-const-variable=]
>  121 | static const uint8_t DP_VGA_LVDS_CONVERTER_ID_2[] = "sivarT";
>
> NB: Repeated ~100 times - snipped for brevity
>
> Cc: Harry Wentland 
> Cc: Leo Li 
> Cc: Alex Deucher 
> Cc: "Christian König" 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: amd-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Lee Jones 

Applied.  thanks!

Alex

> ---
>  drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c| 5 +
>  drivers/gpu/drm/amd/display/include/ddc_service_types.h | 4 
>  2 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c 
> b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> index 6c60c1fdebdc1..f2023d2b53234 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> @@ -15,6 +15,11 @@
>  #include "dc_dmub_srv.h"
>  #include "dce/dmub_hw_lock_mgr.h"
>
> +/*Travis*/
> +static const uint8_t DP_VGA_LVDS_CONVERTER_ID_2[] = "sivarT";
> +/*Nutmeg*/
> +static const uint8_t DP_VGA_LVDS_CONVERTER_ID_3[] = "dnomlA";
> +
>  #define DC_LOGGER \
> link->ctx->logger
>  #define DC_TRACE_LEVEL_MESSAGE(...) /* do nothing */
> diff --git a/drivers/gpu/drm/amd/display/include/ddc_service_types.h 
> b/drivers/gpu/drm/amd/display/include/ddc_service_types.h
> index c9be899cd25cd..b453ce5a9bfdb 100644
> --- a/drivers/gpu/drm/amd/display/include/ddc_service_types.h
> +++ b/drivers/gpu/drm/amd/display/include/ddc_service_types.h
> @@ -117,10 +117,6 @@ struct av_sync_data {
> uint8_t aud_del_ins3;/* DPCD 0002Dh */
>  };
>
> -/*Travis*/
> -static const uint8_t DP_VGA_LVDS_CONVERTER_ID_2[] = "sivarT";
> -/*Nutmeg*/
> -static const uint8_t DP_VGA_LVDS_CONVERTER_ID_3[] = "dnomlA";
>  /*DP to Dual link DVI converter*/
>  static const uint8_t DP_DVI_CONVERTER_ID_4[] = "m2DVIa";
>  static const uint8_t DP_DVI_CONVERTER_ID_5[] = "3393N2";
> --
> 2.25.1
>
> ___
> 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 02/40] drm/amd/display/dc/core/dc_link_dp: Move DP_VGA_LVDS_CONVERTER_ID_{2, 3} to where they're used

2020-11-13 Thread Alex Deucher
On Fri, Nov 13, 2020 at 10:23 AM Alex Deucher  wrote:
>
> On Fri, Nov 13, 2020 at 8:49 AM Lee Jones  wrote:
> >
> > This patch fixes >200 warnings.
> >
> > Fixes the following W=1 kernel build warning(s):
> >
> >  drivers/gpu/drm/amd/amdgpu/../display/include/ddc_service_types.h:123:22: 
> > warning: ‘DP_VGA_LVDS_CONVERTER_ID_3’ defined but not used 
> > [-Wunused-const-variable=]
> >  123 | static const uint8_t DP_VGA_LVDS_CONVERTER_ID_3[] = "dnomlA";
> >  | ^~
> >  drivers/gpu/drm/amd/amdgpu/../display/include/ddc_service_types.h:121:22: 
> > warning: ‘DP_VGA_LVDS_CONVERTER_ID_2’ defined but not used 
> > [-Wunused-const-variable=]
> >  121 | static const uint8_t DP_VGA_LVDS_CONVERTER_ID_2[] = "sivarT";
> >
> > NB: Repeated ~100 times - snipped for brevity
> >
> > Cc: Harry Wentland 
> > Cc: Leo Li 
> > Cc: Alex Deucher 
> > Cc: "Christian König" 
> > Cc: David Airlie 
> > Cc: Daniel Vetter 
> > Cc: amd-...@lists.freedesktop.org
> > Cc: dri-devel@lists.freedesktop.org
> > Signed-off-by: Lee Jones 
> > ---
> >  drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c| 5 +
> >  drivers/gpu/drm/amd/display/include/ddc_service_types.h | 4 
> >  2 files changed, 5 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c 
> > b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> > index 6c60c1fdebdc1..f2023d2b53234 100644
> > --- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> > +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> > @@ -15,6 +15,11 @@
> >  #include "dc_dmub_srv.h"
> >  #include "dce/dmub_hw_lock_mgr.h"
> >
> > +/*Travis*/
> > +static const uint8_t DP_VGA_LVDS_CONVERTER_ID_2[] = "sivarT";
> > +/*Nutmeg*/
> > +static const uint8_t DP_VGA_LVDS_CONVERTER_ID_3[] = "dnomlA";
> > +
> >  #define DC_LOGGER \
> > link->ctx->logger
> >  #define DC_TRACE_LEVEL_MESSAGE(...) /* do nothing */
> > diff --git a/drivers/gpu/drm/amd/display/include/ddc_service_types.h 
> > b/drivers/gpu/drm/amd/display/include/ddc_service_types.h
> > index c9be899cd25cd..b453ce5a9bfdb 100644
> > --- a/drivers/gpu/drm/amd/display/include/ddc_service_types.h
> > +++ b/drivers/gpu/drm/amd/display/include/ddc_service_types.h
> > @@ -117,10 +117,6 @@ struct av_sync_data {
> > uint8_t aud_del_ins3;/* DPCD 0002Dh */
> >  };
> >
> > -/*Travis*/
> > -static const uint8_t DP_VGA_LVDS_CONVERTER_ID_2[] = "sivarT";
> > -/*Nutmeg*/
> > -static const uint8_t DP_VGA_LVDS_CONVERTER_ID_3[] = "dnomlA";
> >  /*DP to Dual link DVI converter*/
> >  static const uint8_t DP_DVI_CONVERTER_ID_4[] = "m2DVIa";
> >  static const uint8_t DP_DVI_CONVERTER_ID_5[] = "3393N2";
>
> Can we keep all of these strings together?

Nevermind, I hadn't seen the later patch that deals with the later ones.

Alex

>
> Alex
>
> > --
> > 2.25.1
> >
> > ___
> > 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 02/40] drm/amd/display/dc/core/dc_link_dp: Move DP_VGA_LVDS_CONVERTER_ID_{2, 3} to where they're used

2020-11-13 Thread Alex Deucher
On Fri, Nov 13, 2020 at 8:49 AM Lee Jones  wrote:
>
> This patch fixes >200 warnings.
>
> Fixes the following W=1 kernel build warning(s):
>
>  drivers/gpu/drm/amd/amdgpu/../display/include/ddc_service_types.h:123:22: 
> warning: ‘DP_VGA_LVDS_CONVERTER_ID_3’ defined but not used 
> [-Wunused-const-variable=]
>  123 | static const uint8_t DP_VGA_LVDS_CONVERTER_ID_3[] = "dnomlA";
>  | ^~
>  drivers/gpu/drm/amd/amdgpu/../display/include/ddc_service_types.h:121:22: 
> warning: ‘DP_VGA_LVDS_CONVERTER_ID_2’ defined but not used 
> [-Wunused-const-variable=]
>  121 | static const uint8_t DP_VGA_LVDS_CONVERTER_ID_2[] = "sivarT";
>
> NB: Repeated ~100 times - snipped for brevity
>
> Cc: Harry Wentland 
> Cc: Leo Li 
> Cc: Alex Deucher 
> Cc: "Christian König" 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: amd-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Lee Jones 
> ---
>  drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c| 5 +
>  drivers/gpu/drm/amd/display/include/ddc_service_types.h | 4 
>  2 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c 
> b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> index 6c60c1fdebdc1..f2023d2b53234 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> @@ -15,6 +15,11 @@
>  #include "dc_dmub_srv.h"
>  #include "dce/dmub_hw_lock_mgr.h"
>
> +/*Travis*/
> +static const uint8_t DP_VGA_LVDS_CONVERTER_ID_2[] = "sivarT";
> +/*Nutmeg*/
> +static const uint8_t DP_VGA_LVDS_CONVERTER_ID_3[] = "dnomlA";
> +
>  #define DC_LOGGER \
> link->ctx->logger
>  #define DC_TRACE_LEVEL_MESSAGE(...) /* do nothing */
> diff --git a/drivers/gpu/drm/amd/display/include/ddc_service_types.h 
> b/drivers/gpu/drm/amd/display/include/ddc_service_types.h
> index c9be899cd25cd..b453ce5a9bfdb 100644
> --- a/drivers/gpu/drm/amd/display/include/ddc_service_types.h
> +++ b/drivers/gpu/drm/amd/display/include/ddc_service_types.h
> @@ -117,10 +117,6 @@ struct av_sync_data {
> uint8_t aud_del_ins3;/* DPCD 0002Dh */
>  };
>
> -/*Travis*/
> -static const uint8_t DP_VGA_LVDS_CONVERTER_ID_2[] = "sivarT";
> -/*Nutmeg*/
> -static const uint8_t DP_VGA_LVDS_CONVERTER_ID_3[] = "dnomlA";
>  /*DP to Dual link DVI converter*/
>  static const uint8_t DP_DVI_CONVERTER_ID_4[] = "m2DVIa";
>  static const uint8_t DP_DVI_CONVERTER_ID_5[] = "3393N2";

Can we keep all of these strings together?

Alex

> --
> 2.25.1
>
> ___
> 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 01/40] drm/amd/include/vega10_ip_offset: Mark _BASE structs as __maybe_unused

2020-11-13 Thread Alex Deucher
On Fri, Nov 13, 2020 at 8:49 AM Lee Jones  wrote:
>
> This patch fixes nearly 400 warnings!
>
> These structures are too widely used in too many varying
> configurations to be split-up into different headers or moved into
> source files.
>
> Instead, we'll mark them as __maybe_unused which tells the compiler
> that we're aware they're being included into source files which do not
> make use of them - but we've looked into it, and it's okay.
>
> Let's tidy-up whilst were here.  Just alignment stuff.
>
> Fixes the following W=1 kernel build warning(s):
>
>  In file included from drivers/gpu/drm/amd/amdgpu/navi14_reg_init.c:27:
>  drivers/gpu/drm/amd/amdgpu/../include/navi14_ip_offset.h:179:29: warning: 
> ‘USB0_BASE’ defined but not used [-Wunused-const-variable=]
>  179 | static const struct IP_BASE USB0_BASE ={ { { { 0x0242A800, 0x05B0, 
> 0, 0, 0 } },
>  | ^
>  drivers/gpu/drm/amd/amdgpu/../include/navi14_ip_offset.h:172:29: warning: 
> ‘UMC_BASE’ defined but not used [-Wunused-const-variable=]
>  172 | static const struct IP_BASE UMC_BASE ={ { { { 0x00014000, 0x02425800, 
> 0, 0, 0 } },
>  | ^~~~
>  drivers/gpu/drm/amd/amdgpu/../include/navi14_ip_offset.h:151:29: warning: 
> ‘SDMA_BASE’ defined but not used [-Wunused-const-variable=]
>  151 | static const struct IP_BASE SDMA_BASE ={ { { { 0x1260, 0xA000, 
> 0x02402C00, 0, 0 } },
>  | ^
>  drivers/gpu/drm/amd/amdgpu/../include/navi14_ip_offset.h:144:29: warning: 
> ‘PCIE0_BASE’ defined but not used [-Wunused-const-variable=]
>  144 | static const struct IP_BASE PCIE0_BASE ={ { { { 0x, 
> 0x0014, 0x0D20, 0x00010400, 0x0241B000 } },
>  | ^~
>
> NB: Snipped for brevity
>
> Cc: Alex Deucher 
> Cc: "Christian König" 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: amd-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Lee Jones 

Applied.  Thanks!

Alex

> ---
>  .../gpu/drm/amd/include/vega10_ip_offset.h| 76 +--
>  1 file changed, 38 insertions(+), 38 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/include/vega10_ip_offset.h 
> b/drivers/gpu/drm/amd/include/vega10_ip_offset.h
> index 976dd2d565ba4..bb5463152f6b0 100644
> --- a/drivers/gpu/drm/amd/include/vega10_ip_offset.h
> +++ b/drivers/gpu/drm/amd/include/vega10_ip_offset.h
> @@ -35,177 +35,177 @@ struct IP_BASE
>  };
>
>
> -static const struct IP_BASE NBIF_BASE  = { { { { 0x, 
> 0x0014, 0x0D20, 0x00010400, 0 } },
> +static const struct IP_BASE __maybe_unused NBIF_BASE   = { { { { 0x, 
> 0x0014, 0x0D20, 0x00010400, 0 } },
>   
>   { { 0, 0, 0, 0, 0 } },
>   
>   { { 0, 0, 0, 0, 0 } },
>   
>   { { 0, 0, 0, 0, 0 } },
>   
>   { { 0, 0, 0, 0, 0 } } } };
> -static const struct IP_BASE NBIO_BASE  = { { { { 0x, 
> 0x0014, 0x0D20, 0x00010400, 0 } },
> +static const struct IP_BASE __maybe_unused NBIO_BASE   = { { { { 0x, 
> 0x0014, 0x0D20, 0x00010400, 0 } },
>   
>   { { 0, 0, 0, 0, 0 } },
>   
>   { { 0, 0, 0, 0, 0 } },
>   
>   { { 0, 0, 0, 0, 0 } },
>   
>   { { 0, 0, 0, 0, 0 } } } };
> -static const struct IP_BASE DCE_BASE   = { { { { 0x0012, 
> 0x00C0, 0x34C0, 0, 0 } },
> +static const struct IP_BASE __maybe_unused DCE_BASE= { { { { 0x0012, 
> 0x00C0, 0x34C0, 0, 0 } },
>   
>   { { 0, 0, 0, 0, 0 } },
>   
>   { { 0, 0, 0, 0, 0 } },
>   
>   { { 0, 0, 0, 0, 0 } },
>   
>   { { 0, 0, 0, 0, 0 } } } };
> -static const struct IP_BASE DCN_BASE   = { { { { 0x0012, 
> 0x00C0, 0x34C0, 0, 0 } },
> +static const struct IP_BASE __maybe_unused DCN_BASE= { { { { 0x0012, 
> 0x00C0, 0x34C0, 0, 0 } },
>   
>   { { 0, 0, 0, 0, 0 } },
>   
>   { { 0, 0, 0, 0, 0 } },
>   
>   { { 0, 0, 0, 0, 0 } },
> 

Re: [PATCH][next] drm/kmb: fix array out-of-bounds writes to kmb->plane_status[]

2020-11-13 Thread Colin Ian King
On 13/11/2020 14:55, Sam Ravnborg wrote:
> Hi Colin.
> 
> On Fri, Nov 13, 2020 at 12:01:21PM +, Colin King wrote:
>> From: Colin Ian King 
>>
>> Writes to elements in the kmb->plane_status array in function
>> kmb_plane_atomic_disable are overrunning the array when plane_id is
>> more than 1 because currently the array is KMB_MAX_PLANES elements
>> in size and this is currently #defined as 1.  Fix this by defining
>> KMB_MAX_PLANES to 4.
> 
> I fail to follow you here.
> In kmb_plane_init() only one plane is allocated - with id set to 0.
> So for now only one plane is allocated thus kmb_plane_atomic_disable()
> is only called for this plane.
> 
> With your change we will start allocating four planes, something that is
> not tested.
> 
> Do I miss something?
> 
>   Sam
> 

The static analysis from coverity on linux-next suggested that there was
an array overflow as follows:

108 static void kmb_plane_atomic_disable(struct drm_plane *plane,
109 struct drm_plane_state *state)
110 {

   1. Condition 0 /* !!(!__builtin_types_compatible_p() &&
!__builtin_types_compatible_p()) */, taking false branch.

111struct kmb_plane *kmb_plane = to_kmb_plane(plane);

   2. assignment: Assigning: plane_id = kmb_plane->id.

112int plane_id = kmb_plane->id;
113struct kmb_drm_private *kmb;
114
115kmb = to_kmb(plane->dev);
116

   3. Switch case value LAYER_3.

117switch (plane_id) {
118case LAYER_0:
119kmb->plane_status[plane_id].ctrl = LCD_CTRL_VL1_ENABLE;
120break;
121case LAYER_1:

   (#2 of 4): Out-of-bounds write (OVERRUN)

122kmb->plane_status[plane_id].ctrl = LCD_CTRL_VL2_ENABLE;
123break;
124case LAYER_2:

   (#3 of 4): Out-of-bounds write (OVERRUN)

125kmb->plane_status[plane_id].ctrl = LCD_CTRL_GL1_ENABLE;
126break;

   4. equality_cond: Jumping to case LAYER_3.

127case LAYER_3:

   (#1 of 4): Out-of-bounds write (OVERRUN)
   5. overrun-local: Overrunning array kmb->plane_status of 1 8-byte
elements at element index 3 (byte offset 31) using index plane_id (which
evaluates to 3).

128kmb->plane_status[plane_id].ctrl = LCD_CTRL_GL2_ENABLE;
129break;
130}
131

   (#4 of 4): Out-of-bounds write (OVERRUN)

132kmb->plane_status[plane_id].disable = true;
133 }
134

So it seems the assignments to  kmb->plane_status[plane_id] are
overrunning the array since plane_status is allocated as 1 element and
yet plane_id can be 0..3

I could be misunderstanding this, or it may be a false positive.

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


Re: [PATCH][next] drm/kmb: fix array out-of-bounds writes to kmb->plane_status[]

2020-11-13 Thread Sam Ravnborg
Hi Colin.

On Fri, Nov 13, 2020 at 12:01:21PM +, Colin King wrote:
> From: Colin Ian King 
> 
> Writes to elements in the kmb->plane_status array in function
> kmb_plane_atomic_disable are overrunning the array when plane_id is
> more than 1 because currently the array is KMB_MAX_PLANES elements
> in size and this is currently #defined as 1.  Fix this by defining
> KMB_MAX_PLANES to 4.

I fail to follow you here.
In kmb_plane_init() only one plane is allocated - with id set to 0.
So for now only one plane is allocated thus kmb_plane_atomic_disable()
is only called for this plane.

With your change we will start allocating four planes, something that is
not tested.

Do I miss something?

Sam

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


Re: [PATCH v1 11/30] drm/tegra: dc: Support OPP and SoC core voltage scaling

2020-11-13 Thread Mark Brown
On Fri, Nov 13, 2020 at 01:37:01AM +0300, Dmitry Osipenko wrote:
> 12.11.2020 23:01, Mark Brown пишет:
> >> But it's not allowed to change voltage of a dummy regulator, is it
> >> intentional?

> > Of course not, we can't know if the requested new voltage is valid - the
> > driver would have to have explict support for handling situations where
> > it's not possible to change the voltage (which it can detect through
> > enumerating the values it wants to set at startup).

> > [Requesting the same supply multiple times]

> But how driver is supposed to recognize that it's a dummy or buggy
> regulator if it rejects all voltages?

It's not clear if it matters - it's more a policy decision on the part
of the driver about what it thinks safe error handling is.  If it's not
possible to read voltages from the regulator the consumer driver has to
decide what it thinks it's safe for it to do, either way it has no idea
what the actual current voltage is.  It could assume that it's something
that supports all the use cases it wants to use and just carry on with
no configuration of voltages, it could decide that it might not support
everything and not make any changes to be safe, or do something like
try to figure out that if we're currently at a given OPP that's the top
OPP possible.  Historically when we've not had regulator control in
these drivers so they have effectively gone with the first option of
just assuming it's a generally safe value, this often aligns with what
the power on requirements for SoCs are so it's not unreasonable.


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


[PATCH 38/40] drm/msm/disp/dpu1/dpu_core_perf: Remove set but unused variable 'dpu_cstate'

2020-11-13 Thread Lee Jones
Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c: In function 
‘_dpu_core_perf_calc_crtc’:
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c:113:25: warning: variable 
‘dpu_cstate’ set but not used [-Wunused-but-set-variable]

Cc: Rob Clark 
Cc: Sean Paul 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Kalyan Thota 
Cc: linux-arm-...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: freedr...@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
index 37c8270681c23..36927fc04a388 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
@@ -110,14 +110,11 @@ static void _dpu_core_perf_calc_crtc(struct dpu_kms *kms,
struct drm_crtc_state *state,
struct dpu_core_perf_params *perf)
 {
-   struct dpu_crtc_state *dpu_cstate;
-
if (!kms || !kms->catalog || !crtc || !state || !perf) {
DPU_ERROR("invalid parameters\n");
return;
}
 
-   dpu_cstate = to_dpu_crtc_state(state);
memset(perf, 0, sizeof(struct dpu_core_perf_params));
 
if (kms->perf.perf_tune.mode == DPU_PERF_MODE_MINIMUM) {
-- 
2.25.1

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


[PATCH 36/40] drm/amd/amdgpu/amdgpu_fw_attestation: Consume our own header containing prototypes

2020-11-13 Thread Lee Jones
Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/amd/amdgpu/amdgpu_fw_attestation.c:130:6: warning: no previous 
prototype for ‘amdgpu_fw_attestation_debugfs_init’ [-Wmissing-prototypes]

Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Hawking Zhang 
Cc: John Clements 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_fw_attestation.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fw_attestation.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fw_attestation.c
index c6947d6c7ff51..e47bca1c76359 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fw_attestation.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fw_attestation.c
@@ -26,6 +26,7 @@
 #include 
 
 #include "amdgpu.h"
+#include "amdgpu_fw_attestation.h"
 #include "amdgpu_psp.h"
 #include "amdgpu_ucode.h"
 #include "soc15_common.h"
@@ -139,4 +140,4 @@ void amdgpu_fw_attestation_debugfs_init(struct 
amdgpu_device *adev)
adev,
_fw_attestation_debugfs_ops);
 #endif
-}
\ No newline at end of file
+}
-- 
2.25.1

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


[PATCH 18/40] drm/mediatek/mtk_dpi: Remove unused struct definition 'mtk_dpi_encoder_funcs'

2020-11-13 Thread Lee Jones
Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/mediatek/mtk_dpi.c:530:39: warning: ‘mtk_dpi_encoder_funcs’ 
defined but not used [-Wunused-const-variable=]

Cc: Chun-Kuang Hu 
Cc: Philipp Zabel 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Matthias Brugger 
Cc: Jie Qiu 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-media...@lists.infradead.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/mediatek/mtk_dpi.c | 9 -
 1 file changed, 9 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index cf11c4850b405..52f11a63a3304 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -522,15 +522,6 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
return 0;
 }
 
-static void mtk_dpi_encoder_destroy(struct drm_encoder *encoder)
-{
-   drm_encoder_cleanup(encoder);
-}
-
-static const struct drm_encoder_funcs mtk_dpi_encoder_funcs = {
-   .destroy = mtk_dpi_encoder_destroy,
-};
-
 static int mtk_dpi_bridge_attach(struct drm_bridge *bridge,
 enum drm_bridge_attach_flags flags)
 {
-- 
2.25.1

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


[PATCH 34/40] drm/msm/disp/mdp5/mdp5_ctl: Demote non-conformant kernel-doc headers

2020-11-13 Thread Lee Jones
Very little attempt has been made to document these functions.

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c:227: warning: Function parameter or 
member 'ctl' not described in 'mdp5_ctl_set_encoder_state'
 drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c:227: warning: Function parameter or 
member 'pipeline' not described in 'mdp5_ctl_set_encoder_state'
 drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c:227: warning: Function parameter or 
member 'enabled' not described in 'mdp5_ctl_set_encoder_state'
 drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c:227: warning: Excess function 
parameter 'enable' description in 'mdp5_ctl_set_encoder_state'
 drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c:529: warning: Function parameter or 
member 'ctl' not described in 'mdp5_ctl_commit'
 drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c:529: warning: Function parameter or 
member 'pipeline' not described in 'mdp5_ctl_commit'
 drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c:529: warning: Function parameter or 
member 'flush_mask' not described in 'mdp5_ctl_commit'
 drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c:529: warning: Function parameter or 
member 'start' not described in 'mdp5_ctl_commit'

Cc: Rob Clark 
Cc: Sean Paul 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: linux-arm-...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: freedr...@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c
index 030279d7b64b7..b5c40f9773629 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_ctl.c
@@ -213,10 +213,10 @@ static void send_start_signal(struct mdp5_ctl *ctl)
spin_unlock_irqrestore(>hw_lock, flags);
 }
 
-/**
+/*
  * mdp5_ctl_set_encoder_state() - set the encoder state
  *
- * @enable: true, when encoder is ready for data streaming; false, otherwise.
+ * @enabled: true, when encoder is ready for data streaming; false, otherwise.
  *
  * Note:
  * This encoder state is needed to trigger START signal (data path kickoff).
@@ -507,7 +507,7 @@ static void fix_for_single_flush(struct mdp5_ctl *ctl, u32 
*flush_mask,
}
 }
 
-/**
+/*
  * mdp5_ctl_commit() - Register Flush
  *
  * The flush register is used to indicate several registers are all
-- 
2.25.1

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


[PATCH 28/40] drm/amd/amdgpu/amdgpu_ras: Make local function 'amdgpu_ras_error_status_query' static

2020-11-13 Thread Lee Jones
Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:1482:6: warning: no previous prototype 
for ‘amdgpu_ras_error_status_query’ [-Wmissing-prototypes]

Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
index f89a991999428..9d11b847e6efe 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
@@ -1472,8 +1472,8 @@ static void amdgpu_ras_log_on_err_counter(struct 
amdgpu_device *adev)
 }
 
 /* Parse RdRspStatus and WrRspStatus */
-void amdgpu_ras_error_status_query(struct amdgpu_device *adev,
-   struct ras_query_if *info)
+static void amdgpu_ras_error_status_query(struct amdgpu_device *adev,
+ struct ras_query_if *info)
 {
/*
 * Only two block need to query read/write
-- 
2.25.1

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


[PATCH 32/40] drm/msm/disp/mdp5/mdp5_crtc: Make local function 'mdp5_crtc_setup_pipeline()' static

2020-11-13 Thread Lee Jones
Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c:581:5: warning: no previous 
prototype for ‘mdp5_crtc_setup_pipeline’ [-Wmissing-prototypes]

Cc: Rob Clark 
Cc: Sean Paul 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Thomas Zimmermann 
Cc: linux-arm-...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: freedr...@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
index 79dd56faf3de0..0c8f9f88301fa 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
@@ -578,9 +578,9 @@ static void mdp5_crtc_atomic_enable(struct drm_crtc *crtc,
mdp5_crtc->enabled = true;
 }
 
-int mdp5_crtc_setup_pipeline(struct drm_crtc *crtc,
-struct drm_crtc_state *new_crtc_state,
-bool need_right_mixer)
+static int mdp5_crtc_setup_pipeline(struct drm_crtc *crtc,
+   struct drm_crtc_state *new_crtc_state,
+   bool need_right_mixer)
 {
struct mdp5_crtc_state *mdp5_cstate =
to_mdp5_crtc_state(new_crtc_state);
-- 
2.25.1

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


[PATCH 24/40] drm/amd/amdgpu/amdgpu_ids: Supply missing docs for 'id' and 'vmhub'

2020-11-13 Thread Lee Jones
Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c:271: warning: Function parameter or 
member 'id' not described in 'amdgpu_vmid_grab_reserved'
 drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c:523: warning: Function parameter or 
member 'vmhub' not described in 'amdgpu_vmid_reset'

Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Sumit Semwal 
Cc: Felix Kuehling 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c
index 6e9a9e5dbea07..61a1331f482c5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c
@@ -259,6 +259,7 @@ static int amdgpu_vmid_grab_idle(struct amdgpu_vm *vm,
  * @sync: sync object where we add dependencies
  * @fence: fence protecting ID from reuse
  * @job: job who wants to use the VMID
+ * @id: resulting VMID
  *
  * Try to assign a reserved VMID.
  */
@@ -514,6 +515,7 @@ void amdgpu_vmid_free_reserved(struct amdgpu_device *adev,
  * amdgpu_vmid_reset - reset VMID to zero
  *
  * @adev: amdgpu device structure
+ * @vmhub: vmhub type
  * @vmid: vmid number to use
  *
  * Reset saved GDW, GWS and OA to force switch on next flush.
-- 
2.25.1

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


[PATCH 37/40] drm/amd/amdgpu/smu_v11_0_i2c: Provide descriptions for 'control' and 'data' params

2020-11-13 Thread Lee Jones
Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/amd/amdgpu/smu_v11_0_i2c.c:225: warning: Function parameter or 
member 'control' not described in 'smu_v11_0_i2c_transmit'
 drivers/gpu/drm/amd/amdgpu/smu_v11_0_i2c.c:325: warning: Function parameter or 
member 'control' not described in 'smu_v11_0_i2c_receive'
 drivers/gpu/drm/amd/amdgpu/smu_v11_0_i2c.c:325: warning: Function parameter or 
member 'data' not described in 'smu_v11_0_i2c_receive'

Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/amd/amdgpu/smu_v11_0_i2c.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/smu_v11_0_i2c.c 
b/drivers/gpu/drm/amd/amdgpu/smu_v11_0_i2c.c
index 7fb240c4990ca..5c7d769aee3fb 100644
--- a/drivers/gpu/drm/amd/amdgpu/smu_v11_0_i2c.c
+++ b/drivers/gpu/drm/amd/amdgpu/smu_v11_0_i2c.c
@@ -212,6 +212,7 @@ static uint32_t smu_v11_0_i2c_poll_rx_status(struct 
i2c_adapter *control)
 /**
  * smu_v11_0_i2c_transmit - Send a block of data over the I2C bus to a slave 
device.
  *
+ * @control: I2C adapter reference
  * @address: The I2C address of the slave device.
  * @data: The data to transmit over the bus.
  * @numbytes: The amount of data to transmit.
@@ -313,7 +314,9 @@ static uint32_t smu_v11_0_i2c_transmit(struct i2c_adapter 
*control,
 /**
  * smu_v11_0_i2c_receive - Receive a block of data over the I2C bus from a 
slave device.
  *
+ * @control: I2C adapter reference
  * @address: The I2C address of the slave device.
+ * @data: Placeholder to store received data.
  * @numbytes: The amount of data to transmit.
  * @i2c_flag: Flags for transmission
  *
-- 
2.25.1

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


[PATCH 23/40] drm/lima/lima_sched: Remove unused and unnecessary variable 'ret'

2020-11-13 Thread Lee Jones
Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/lima/lima_sched.c: In function ‘lima_sched_run_job’:
 drivers/gpu/drm/lima/lima_sched.c:227:20: warning: variable ‘ret’ set but not 
used [-Wunused-but-set-variable]

Cc: Qiang Yu 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Sumit Semwal 
Cc: "Christian König" 
Cc: dri-devel@lists.freedesktop.org
Cc: l...@lists.freedesktop.org
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/lima/lima_sched.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/lima/lima_sched.c 
b/drivers/gpu/drm/lima/lima_sched.c
index a070a85f8f368..63b4c5643f9cd 100644
--- a/drivers/gpu/drm/lima/lima_sched.c
+++ b/drivers/gpu/drm/lima/lima_sched.c
@@ -224,7 +224,6 @@ static struct dma_fence *lima_sched_run_job(struct 
drm_sched_job *job)
struct lima_sched_pipe *pipe = to_lima_pipe(job->sched);
struct lima_device *ldev = pipe->ldev;
struct lima_fence *fence;
-   struct dma_fence *ret;
int i, err;
 
/* after GPU reset */
@@ -246,7 +245,7 @@ static struct dma_fence *lima_sched_run_job(struct 
drm_sched_job *job)
/* for caller usage of the fence, otherwise irq handler
 * may consume the fence before caller use it
 */
-   ret = dma_fence_get(task->fence);
+   dma_fence_get(task->fence);
 
pipe->current_task = task;
 
-- 
2.25.1

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


[PATCH 15/40] drm/lima/lima_drv: Demote kernel-doc formatting abuse

2020-11-13 Thread Lee Jones
Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/lima/lima_drv.c:264: warning: cannot understand function 
prototype: 'const struct drm_driver lima_drm_driver = '

Cc: Qiang Yu 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel@lists.freedesktop.org
Cc: l...@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/lima/lima_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/lima/lima_drv.c b/drivers/gpu/drm/lima/lima_drv.c
index d497af91d8505..7b8d7178d09aa 100644
--- a/drivers/gpu/drm/lima/lima_drv.c
+++ b/drivers/gpu/drm/lima/lima_drv.c
@@ -255,7 +255,7 @@ static const struct drm_ioctl_desc lima_drm_driver_ioctls[] 
= {
 
 DEFINE_DRM_GEM_FOPS(lima_drm_driver_fops);
 
-/**
+/*
  * Changelog:
  *
  * - 1.1.0 - add heap buffer support
-- 
2.25.1

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


[PATCH 27/40] drm/amd/amdgpu/amdgpu_ras: Remove unused function 'amdgpu_ras_error_cure'

2020-11-13 Thread Lee Jones
Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:908:5: warning: no previous prototype 
for ‘amdgpu_ras_error_cure’ [-Wmissing-prototypes]

Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
index b96267068a72d..f89a991999428 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
@@ -905,13 +905,6 @@ int amdgpu_ras_error_inject(struct amdgpu_device *adev,
return ret;
 }
 
-int amdgpu_ras_error_cure(struct amdgpu_device *adev,
-   struct ras_cure_if *info)
-{
-   /* psp fw has no cure interface for now. */
-   return 0;
-}
-
 /* get the total error counts on all IPs */
 unsigned long amdgpu_ras_query_error_count(struct amdgpu_device *adev,
bool is_ce)
-- 
2.25.1

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


[PATCH 26/40] drm/amd/amdgpu/amdgpu_gmc: Demote one and fix another function header

2020-11-13 Thread Lee Jones
Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c:69: warning: Function parameter or 
member 'bo' not described in 'amdgpu_gmc_pd_addr'
 drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c:121: warning: Function parameter or 
member 'bo' not described in 'amdgpu_gmc_agp_addr'
 drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c:121: warning: Excess function 
parameter 'tbo' description in 'amdgpu_gmc_agp_addr'

Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
index 056cb87d09ea3..fede84509dbca 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c
@@ -61,9 +61,8 @@ void amdgpu_gmc_get_pde_for_bo(struct amdgpu_bo *bo, int 
level,
amdgpu_gmc_get_vm_pde(adev, level, addr, flags);
 }
 
-/**
+/*
  * amdgpu_gmc_pd_addr - return the address of the root directory
- *
  */
 uint64_t amdgpu_gmc_pd_addr(struct amdgpu_bo *bo)
 {
@@ -112,7 +111,7 @@ int amdgpu_gmc_set_pte_pde(struct amdgpu_device *adev, void 
*cpu_pt_addr,
 /**
  * amdgpu_gmc_agp_addr - return the address in the AGP address space
  *
- * @tbo: TTM BO which needs the address, must be in GTT domain
+ * @bo: TTM BO which needs the address, must be in GTT domain
  *
  * Tries to figure out how to access the BO through the AGP aperture. Returns
  * AMDGPU_BO_INVALID_OFFSET if that is not possible.
-- 
2.25.1

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


[PATCH 31/40] drm/amd/amdgpu/amdgpu_vm_sdma: Fix 'amdgpu_vm_sdma_prepare()'s doc-rot

2020-11-13 Thread Lee Jones
Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c:63: warning: Function parameter or 
member 'resv' not described in 'amdgpu_vm_sdma_prepare'
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c:63: warning: Function parameter or 
member 'sync_mode' not described in 'amdgpu_vm_sdma_prepare'
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c:63: warning: Excess function 
parameter 'owner' description in 'amdgpu_vm_sdma_prepare'
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c:63: warning: Excess function 
parameter 'exclusive' description in 'amdgpu_vm_sdma_prepare'

Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Sumit Semwal 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c
index db790574dc2e8..a83a646759c58 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c
@@ -51,8 +51,8 @@ static int amdgpu_vm_sdma_map_table(struct amdgpu_bo *table)
  * amdgpu_vm_sdma_prepare - prepare SDMA command submission
  *
  * @p: see amdgpu_vm_update_params definition
- * @owner: owner we need to sync to
- * @exclusive: exclusive move fence we need to sync to
+ * @resv: reservation object with embedded fence
+ * @sync_mode: synchronization mode
  *
  * Returns:
  * Negativ errno, 0 for success.
-- 
2.25.1

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


[PATCH 16/40] drm/amd/amdgpu/amdgpu_sync: Fix misnamed, missing and extra param descriptions

2020-11-13 Thread Lee Jones
Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c:86: warning: Function parameter or 
member 'f' not described in 'amdgpu_sync_get_owner'
 drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c:86: warning: Excess function 
parameter 'fence' description in 'amdgpu_sync_get_owner'
 drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c:182: warning: Excess function 
parameter 'adev' description in 'amdgpu_sync_vm_fence'
 drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c:203: warning: Function parameter or 
member 'adev' not described in 'amdgpu_sync_resv'

Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Sumit Semwal 
Cc: Felix Kuehling 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c
index 8ea6c49529e7d..4e558632a5d2b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c
@@ -78,7 +78,7 @@ static bool amdgpu_sync_same_dev(struct amdgpu_device *adev,
 /**
  * amdgpu_sync_get_owner - extract the owner of a fence
  *
- * @fence: fence get the owner from
+ * @f: fence get the owner from
  *
  * Extract who originally created the fence.
  */
@@ -172,7 +172,6 @@ int amdgpu_sync_fence(struct amdgpu_sync *sync, struct 
dma_fence *f)
 /**
  * amdgpu_sync_vm_fence - remember to sync to this VM fence
  *
- * @adev: amdgpu device
  * @sync: sync object to add fence to
  * @fence: the VM fence to add
  *
@@ -190,6 +189,7 @@ int amdgpu_sync_vm_fence(struct amdgpu_sync *sync, struct 
dma_fence *fence)
 /**
  * amdgpu_sync_resv - sync to a reservation object
  *
+ * @adev: amdgpu device
  * @sync: sync object to add fences from reservation object to
  * @resv: reservation object with embedded fence
  * @mode: how owner affects which fences we sync to
-- 
2.25.1

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


[PATCH 20/40] drm/pl111/pl111_debugfs: Make local function 'pl111_debugfs_regs()' static

2020-11-13 Thread Lee Jones
Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/pl111/pl111_debugfs.c:33:5: warning: no previous prototype for 
‘pl111_debugfs_regs’ [-Wmissing-prototypes]

Cc: Eric Anholt 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/pl111/pl111_debugfs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/pl111/pl111_debugfs.c 
b/drivers/gpu/drm/pl111/pl111_debugfs.c
index 317f68abf18b0..6744fa16f4644 100644
--- a/drivers/gpu/drm/pl111/pl111_debugfs.c
+++ b/drivers/gpu/drm/pl111/pl111_debugfs.c
@@ -30,7 +30,7 @@ static const struct {
REGDEF(CLCD_PL111_LCUR),
 };
 
-int pl111_debugfs_regs(struct seq_file *m, void *unused)
+static int pl111_debugfs_regs(struct seq_file *m, void *unused)
 {
struct drm_info_node *node = (struct drm_info_node *)m->private;
struct drm_device *dev = node->minor->dev;
-- 
2.25.1

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


[PATCH 29/40] drm/amd/amdgpu/amdgpu_csa: Remove set but unused variable 'r'

2020-11-13 Thread Lee Jones
Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c: In function 
‘amdgpu_allocate_static_csa’:
 drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c:40:6: warning: variable ‘r’ set but 
not used [-Wunused-but-set-variable]

Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: monk@amd.com
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
index 08047bc4d5886..da21e60bb8272 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c
@@ -37,10 +37,9 @@ uint64_t amdgpu_csa_vaddr(struct amdgpu_device *adev)
 int amdgpu_allocate_static_csa(struct amdgpu_device *adev, struct amdgpu_bo 
**bo,
u32 domain, uint32_t size)
 {
-   int r;
void *ptr;
 
-   r = amdgpu_bo_create_kernel(adev, size, PAGE_SIZE,
+   amdgpu_bo_create_kernel(adev, size, PAGE_SIZE,
domain, bo,
NULL, );
if (!*bo)
-- 
2.25.1

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


[PATCH 35/40] drm/msm/disp/mdp5/mdp5_kms: Make local functions 'mdp5_{en, dis}able()' static

2020-11-13 Thread Lee Jones
Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c:299:5: warning: no previous prototype 
for ‘mdp5_disable’ [-Wmissing-prototypes]
 drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c:319:5: warning: no previous prototype 
for ‘mdp5_enable’ [-Wmissing-prototypes]

Cc: Rob Clark 
Cc: Sean Paul 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Thomas Zimmermann 
Cc: linux-arm-...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: freedr...@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
index b3eecf8694771..15aed45022bc8 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
@@ -296,7 +296,7 @@ static const struct mdp_kms_funcs kms_funcs = {
.set_irqmask = mdp5_set_irqmask,
 };
 
-int mdp5_disable(struct mdp5_kms *mdp5_kms)
+static int mdp5_disable(struct mdp5_kms *mdp5_kms)
 {
DBG("");
 
@@ -316,7 +316,7 @@ int mdp5_disable(struct mdp5_kms *mdp5_kms)
return 0;
 }
 
-int mdp5_enable(struct mdp5_kms *mdp5_kms)
+static int mdp5_enable(struct mdp5_kms *mdp5_kms)
 {
DBG("");
 
-- 
2.25.1

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


[PATCH 25/40] drm/amd/amdgpu/amdgpu_debugfs: Demote obvious abuse of kernel-doc formatting

2020-11-13 Thread Lee Jones
Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:308: warning: Function parameter 
or member 'f' not described in 'amdgpu_debugfs_regs_read'
 drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:308: warning: Function parameter 
or member 'buf' not described in 'amdgpu_debugfs_regs_read'
 drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:308: warning: Function parameter 
or member 'size' not described in 'amdgpu_debugfs_regs_read'
 drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:308: warning: Function parameter 
or member 'pos' not described in 'amdgpu_debugfs_regs_read'
 drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:317: warning: Function parameter 
or member 'f' not described in 'amdgpu_debugfs_regs_write'
 drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:317: warning: Function parameter 
or member 'buf' not described in 'amdgpu_debugfs_regs_write'
 drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:317: warning: Function parameter 
or member 'size' not described in 'amdgpu_debugfs_regs_write'
 drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c:317: warning: Function parameter 
or member 'pos' not described in 'amdgpu_debugfs_regs_write'

Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Sumit Semwal 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
index 5c1f3725c7410..a6667a2ca0db3 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
@@ -300,7 +300,7 @@ static int  amdgpu_debugfs_process_reg_op(bool read, struct 
file *f,
return result;
 }
 
-/**
+/*
  * amdgpu_debugfs_regs_read - Callback for reading MMIO registers
  */
 static ssize_t amdgpu_debugfs_regs_read(struct file *f, char __user *buf,
@@ -309,7 +309,7 @@ static ssize_t amdgpu_debugfs_regs_read(struct file *f, 
char __user *buf,
return amdgpu_debugfs_process_reg_op(true, f, buf, size, pos);
 }
 
-/**
+/*
  * amdgpu_debugfs_regs_write - Callback for writing MMIO registers
  */
 static ssize_t amdgpu_debugfs_regs_write(struct file *f, const char __user 
*buf,
-- 
2.25.1

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


[PATCH 39/40] drm/msm/disp/dpu1/dpu_encoder: Remove a bunch of unused variables

2020-11-13 Thread Lee Jones
Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c: In function 
‘dpu_encoder_virt_mode_set’:
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c:981:31: warning: variable 
‘num_dspp’ set but not used [-Wunused-but-set-variable]
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c:976:30: warning: variable 
‘topology’ set but not used [-Wunused-but-set-variable]
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c: In function 
‘_dpu_encoder_virt_enable_helper’:
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c:1099:26: warning: variable ‘priv’ 
set but not used [-Wunused-but-set-variable]
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c: In function 
‘dpu_encoder_virt_disable’:
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c:1210:18: warning: variable 
‘dpu_kms’ set but not used [-Wunused-but-set-variable]

Cc: Rob Clark 
Cc: Sean Paul 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: linux-arm-...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: freedr...@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 12 ++--
 1 file changed, 2 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index f7f5c258b5537..289bfb6f1861c 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -973,12 +973,11 @@ static void dpu_encoder_virt_mode_set(struct drm_encoder 
*drm_enc,
struct drm_crtc *drm_crtc;
struct dpu_crtc_state *cstate;
struct dpu_global_state *global_state;
-   struct msm_display_topology topology;
struct dpu_hw_blk *hw_pp[MAX_CHANNELS_PER_ENC];
struct dpu_hw_blk *hw_ctl[MAX_CHANNELS_PER_ENC];
struct dpu_hw_blk *hw_lm[MAX_CHANNELS_PER_ENC];
struct dpu_hw_blk *hw_dspp[MAX_CHANNELS_PER_ENC] = { NULL };
-   int num_lm, num_ctl, num_pp, num_dspp;
+   int num_lm, num_ctl, num_pp;
int i, j;
 
if (!drm_enc) {
@@ -1020,8 +1019,6 @@ static void dpu_encoder_virt_mode_set(struct drm_encoder 
*drm_enc,
if (drm_crtc->state->encoder_mask & drm_encoder_mask(drm_enc))
break;
 
-   topology = dpu_encoder_get_topology(dpu_enc, dpu_kms, adj_mode);
-
/* Query resource that have been reserved in atomic check step. */
num_pp = dpu_rm_get_assigned_resources(_kms->rm, global_state,
drm_enc->base.id, DPU_HW_BLK_PINGPONG, hw_pp,
@@ -1030,7 +1027,7 @@ static void dpu_encoder_virt_mode_set(struct drm_encoder 
*drm_enc,
drm_enc->base.id, DPU_HW_BLK_CTL, hw_ctl, ARRAY_SIZE(hw_ctl));
num_lm = dpu_rm_get_assigned_resources(_kms->rm, global_state,
drm_enc->base.id, DPU_HW_BLK_LM, hw_lm, ARRAY_SIZE(hw_lm));
-   num_dspp = dpu_rm_get_assigned_resources(_kms->rm, global_state,
+   dpu_rm_get_assigned_resources(_kms->rm, global_state,
drm_enc->base.id, DPU_HW_BLK_DSPP, hw_dspp,
ARRAY_SIZE(hw_dspp));
 
@@ -1096,7 +1093,6 @@ static void dpu_encoder_virt_mode_set(struct drm_encoder 
*drm_enc,
 static void _dpu_encoder_virt_enable_helper(struct drm_encoder *drm_enc)
 {
struct dpu_encoder_virt *dpu_enc = NULL;
-   struct msm_drm_private *priv;
int i;
 
if (!drm_enc || !drm_enc->dev) {
@@ -1104,8 +1100,6 @@ static void _dpu_encoder_virt_enable_helper(struct 
drm_encoder *drm_enc)
return;
}
 
-   priv = drm_enc->dev->dev_private;
-
dpu_enc = to_dpu_encoder_virt(drm_enc);
if (!dpu_enc || !dpu_enc->cur_master) {
DPU_ERROR("invalid dpu encoder/master\n");
@@ -1207,7 +1201,6 @@ static void dpu_encoder_virt_disable(struct drm_encoder 
*drm_enc)
 {
struct dpu_encoder_virt *dpu_enc = NULL;
struct msm_drm_private *priv;
-   struct dpu_kms *dpu_kms;
int i = 0;
 
if (!drm_enc) {
@@ -1225,7 +1218,6 @@ static void dpu_encoder_virt_disable(struct drm_encoder 
*drm_enc)
dpu_enc->enabled = false;
 
priv = drm_enc->dev->dev_private;
-   dpu_kms = to_dpu_kms(priv->kms);
 
trace_dpu_enc_disable(DRMID(drm_enc));
 
-- 
2.25.1

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


[PATCH 14/40] drm/meson/meson_venc: Make local function 'meson_venc_hdmi_get_dmt_vmode' static

2020-11-13 Thread Lee Jones
Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/meson/meson_venc.c:893:6: warning: no previous prototype for 
‘meson_venc_hdmi_get_dmt_vmode’ [-Wmissing-prototypes]

Cc: Neil Armstrong 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Kevin Hilman 
Cc: Jerome Brunet 
Cc: Martin Blumenstingl 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-amlo...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/meson/meson_venc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/meson/meson_venc.c 
b/drivers/gpu/drm/meson/meson_venc.c
index f93c725b6f02d..5e2236ec189fa 100644
--- a/drivers/gpu/drm/meson/meson_venc.c
+++ b/drivers/gpu/drm/meson/meson_venc.c
@@ -890,8 +890,8 @@ bool meson_venc_hdmi_supported_vic(int vic)
 }
 EXPORT_SYMBOL_GPL(meson_venc_hdmi_supported_vic);
 
-void meson_venc_hdmi_get_dmt_vmode(const struct drm_display_mode *mode,
-  union meson_hdmi_venc_mode *dmt_mode)
+static void meson_venc_hdmi_get_dmt_vmode(const struct drm_display_mode *mode,
+ union meson_hdmi_venc_mode *dmt_mode)
 {
memset(dmt_mode, 0, sizeof(*dmt_mode));
 
-- 
2.25.1

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


[PATCH 12/40] drm/pl111/pl111_display: Make local function static

2020-11-13 Thread Lee Jones
Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/pl111/pl111_display.c:356:6: warning: no previous prototype 
for ‘pl111_display_disable’ [-Wmissing-prototypes]

Cc: Eric Anholt 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/pl111/pl111_display.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/pl111/pl111_display.c 
b/drivers/gpu/drm/pl111/pl111_display.c
index b3e8697cafcf1..69c02e7c82b7e 100644
--- a/drivers/gpu/drm/pl111/pl111_display.c
+++ b/drivers/gpu/drm/pl111/pl111_display.c
@@ -353,7 +353,7 @@ static void pl111_display_enable(struct 
drm_simple_display_pipe *pipe,
drm_crtc_vblank_on(crtc);
 }
 
-void pl111_display_disable(struct drm_simple_display_pipe *pipe)
+static void pl111_display_disable(struct drm_simple_display_pipe *pipe)
 {
struct drm_crtc *crtc = >crtc;
struct drm_device *drm = crtc->dev;
-- 
2.25.1

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


[PATCH 17/40] drm/meson/meson_vclk: Make two local functions static

2020-11-13 Thread Lee Jones
Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/meson/meson_vclk.c:134:6: warning: no previous prototype for 
‘meson_vid_pll_set’ [-Wmissing-prototypes]
 drivers/gpu/drm/meson/meson_vclk.c:490:6: warning: no previous prototype for 
‘meson_hdmi_pll_set_params’ [-Wmissing-prototypes]

Cc: Neil Armstrong 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Kevin Hilman 
Cc: Jerome Brunet 
Cc: Martin Blumenstingl 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-amlo...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/meson/meson_vclk.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/meson/meson_vclk.c 
b/drivers/gpu/drm/meson/meson_vclk.c
index 0eb86943a3588..2a82119eb58ed 100644
--- a/drivers/gpu/drm/meson/meson_vclk.c
+++ b/drivers/gpu/drm/meson/meson_vclk.c
@@ -131,7 +131,7 @@ enum {
VID_PLL_DIV_15,
 };
 
-void meson_vid_pll_set(struct meson_drm *priv, unsigned int div)
+static void meson_vid_pll_set(struct meson_drm *priv, unsigned int div)
 {
unsigned int shift_val = 0;
unsigned int shift_sel = 0;
@@ -487,9 +487,9 @@ static inline unsigned int pll_od_to_reg(unsigned int od)
return 0;
 }
 
-void meson_hdmi_pll_set_params(struct meson_drm *priv, unsigned int m,
-  unsigned int frac, unsigned int od1,
-  unsigned int od2, unsigned int od3)
+static void meson_hdmi_pll_set_params(struct meson_drm *priv, unsigned int m,
+ unsigned int frac, unsigned int od1,
+ unsigned int od2, unsigned int od3)
 {
unsigned int val;
 
-- 
2.25.1

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


[PATCH 19/40] drm/amd/amdgpu/amdgpu_vram_mgr: Add missing descriptions for 'dev' and 'dir'

2020-11-13 Thread Lee Jones
Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:648: warning: Function parameter 
or member 'dev' not described in 'amdgpu_vram_mgr_free_sgt'
 drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:648: warning: Function parameter 
or member 'dir' not described in 'amdgpu_vram_mgr_free_sgt'

Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
index c99c2180785fe..d2de2a720a3d8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
@@ -637,6 +637,8 @@ int amdgpu_vram_mgr_alloc_sgt(struct amdgpu_device *adev,
  * amdgpu_vram_mgr_free_sgt - allocate and fill a sg table
  *
  * @adev: amdgpu device pointer
+ * @dev: device pointer
+ * @dir: data direction of resource to unmap
  * @sgt: sg table to free
  *
  * Free a previously allocate sg table.
-- 
2.25.1

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


[PATCH 09/40] drm/mediatek/mtk_drm_crtc: Demote seriously out-of-date struct header

2020-11-13 Thread Lee Jones
This needs someone with in-depth knowledge of the driver to complete.

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/mediatek/mtk_drm_crtc.c:62: warning: Function parameter or 
member 'pending_needs_vblank' not described in 'mtk_drm_crtc'
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c:62: warning: Function parameter or 
member 'event' not described in 'mtk_drm_crtc'
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c:62: warning: Function parameter or 
member 'layer_nr' not described in 'mtk_drm_crtc'
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c:62: warning: Function parameter or 
member 'pending_async_planes' not described in 'mtk_drm_crtc'
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c:62: warning: Function parameter or 
member 'cmdq_client' not described in 'mtk_drm_crtc'
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c:62: warning: Function parameter or 
member 'cmdq_event' not described in 'mtk_drm_crtc'
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c:62: warning: Function parameter or 
member 'hw_lock' not described in 'mtk_drm_crtc'

Cc: Chun-Kuang Hu 
Cc: Philipp Zabel 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Matthias Brugger 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-media...@lists.infradead.org
Signed-off-by: Lee Jones 
---
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c 
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 193848fd75154..bfe9942305435 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -24,7 +24,7 @@
 #include "mtk_drm_gem.h"
 #include "mtk_drm_plane.h"
 
-/**
+/*
  * struct mtk_drm_crtc - MediaTek specific crtc structure.
  * @base: crtc object.
  * @enabled: records whether crtc_enable succeeded
@@ -34,6 +34,8 @@
  * @mutex: handle to one of the ten disp_mutex streams
  * @ddp_comp_nr: number of components in ddp_comp
  * @ddp_comp: array of pointers the mtk_ddp_comp structures used by this crtc
+ *
+ * TODO: Needs update: this header is missing a bunch of member descriptions.
  */
 struct mtk_drm_crtc {
struct drm_crtc base;
-- 
2.25.1

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


  1   2   >