[git pull] vmwgfx-fixes-5.7

2020-05-15 Thread Roland Scheidegger (VMware)
Dave, Daniel

Some minor fixes and a maintainer change.

The following changes since commit 24085f70a6e1b0cb647ec92623284641d8270637:

  Merge tag 'trace-v5.7-rc4' of 
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace (2020-05-12 
11:06:26 -0700)

are available in the Git repository at:

  git+ssh://srol...@people.freedesktop.org/~sroland/linux vmwgfx-fixes-5.7

for you to fetch changes up to 80542002ccd41f3703a9ae9e8e95cfbaad370db6:

  drm/vmwgfx: Return true in function vmw_fence_obj_signaled() (2020-05-16 
06:50:37 +0200)


Colin Ian King (1):
  drm/vmwgfx: remove redundant assignment to variable ret

Guixiong Wei (1):
  drm/vmwgfx: Fix parameter name in vmw_bo_init

Jason Yan (1):
  drm/vmwgfx: Return true in function vmw_fence_obj_signaled()

Roland Scheidegger (1):
  drm/vmwgfx: update MAINTAINERS entry

 MAINTAINERS | 4 ++--
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_fence.c   | 2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] drm/vmwgfx: update MAINTAINERS entry

2020-05-15 Thread Roland Scheidegger
From: Roland Scheidegger 

Maintainer switch from Thomas Hellstrom to Roland Scheidegger

Reviewed-by: Charmaine Lee 
Reviewed-by: Neha Bhende 
Acked-by: Thomas Hellstrom 
Signed-off-by: Roland Scheidegger 
---
 MAINTAINERS | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 24d0226abc8e..1e08e5bc5c8a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5511,10 +5511,10 @@ F:  drivers/gpu/drm/vboxvideo/
 
 DRM DRIVER FOR VMWARE VIRTUAL GPU
 M: "VMware Graphics" 
-M: Thomas Hellstrom 
+M: Roland Scheidegger 
 L: dri-devel@lists.freedesktop.org
 S: Supported
-T: git git://people.freedesktop.org/~thomash/linux
+T: git git://people.freedesktop.org/~sroland/linux
 F: drivers/gpu/drm/vmwgfx/
 F: include/uapi/drm/vmwgfx_drm.h
 
-- 
2.17.1

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


Re: [PATCH] drm/bridge: ti-sn65dsi86: Fix off-by-one error in clock choice

2020-05-15 Thread Rob Clark
On Mon, May 4, 2020 at 9:32 PM Douglas Anderson  wrote:
>
> If the rate in our table is _equal_ to the rate we want then it's OK
> to pick it.  It doesn't need to be greater than the one we want.
>
> Fixes: a095f15c00e2 ("drm/bridge: add support for sn65dsi86 bridge driver")
> Signed-off-by: Douglas Anderson 

Reviewed-by: Rob Clark 

> ---
>
>  drivers/gpu/drm/bridge/ti-sn65dsi86.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c 
> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> index 6ad688b320ae..be000b0ca56b 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -475,7 +475,7 @@ static int ti_sn_bridge_calc_min_dp_rate_idx(struct 
> ti_sn_bridge *pdata)
>1000 * pdata->dp_lanes * DP_CLK_FUDGE_DEN);
>
> for (i = 1; i < ARRAY_SIZE(ti_sn_bridge_dp_rate_lut) - 1; i++)
> -   if (ti_sn_bridge_dp_rate_lut[i] > dp_rate_mhz)
> +   if (ti_sn_bridge_dp_rate_lut[i] >= dp_rate_mhz)
> break;
>
> return i;
> --
> 2.26.2.526.g744177e7f7-goog
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/bridge: ti-sn65dsi86: Clear old error bits before AUX transfers

2020-05-15 Thread Rob Clark
On Fri, May 8, 2020 at 4:33 PM Douglas Anderson  wrote:
>
> The AUX channel transfer error bits in the status register are latched
> and need to be cleared.  Clear them before doing our transfer so we
> don't see old bits and get confused.
>
> Without this patch having a single failure would mean that all future
> transfers would look like they failed.
>
> Fixes: b814ec6d4535 ("drm/bridge: ti-sn65dsi86: Implement AUX channel")
> Signed-off-by: Douglas Anderson 

Reviewed-by: Rob Clark 

> ---
>
>  drivers/gpu/drm/bridge/ti-sn65dsi86.c | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c 
> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> index 6ad688b320ae..d865cc2565bc 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -827,6 +827,12 @@ static ssize_t ti_sn_aux_transfer(struct drm_dp_aux *aux,
>  buf[i]);
> }
>
> +   /* Clear old status bits before start so we don't get confused */
> +   regmap_write(pdata->regmap, SN_AUX_CMD_STATUS_REG,
> +AUX_IRQ_STATUS_NAT_I2C_FAIL |
> +AUX_IRQ_STATUS_AUX_RPLY_TOUT |
> +AUX_IRQ_STATUS_AUX_SHORT);
> +
> regmap_write(pdata->regmap, SN_AUX_CMD_REG, request_val | 
> AUX_CMD_SEND);
>
> ret = regmap_read_poll_timeout(pdata->regmap, SN_AUX_CMD_REG, val,
> --
> 2.26.2.645.ge9eca65c58-goog
>
> ___
> 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 v2 1/2] drm/bridge: ti-sn65dsi86: Implement lane reordering + polarity

2020-05-15 Thread Rob Clark
On Wed, May 6, 2020 at 2:03 PM Douglas Anderson  wrote:
>
> The ti-sn65dsi86 MIPI DSI to eDP bridge chip supports arbitrary
> remapping of eDP lanes and also polarity inversion.  Both of these
> features have been described in the device tree bindings for the
> device since the beginning but were never implemented in the driver.
> Implement both of them.
>
> Part of this change also allows you to (via the same device tree
> bindings) specify to use fewer than the max number of DP lanes that
> the panel reports.  This could be useful if your display supports more
> lanes but only a few are hooked up on your board.
>
> Signed-off-by: Douglas Anderson 
> Reviewed-by: Stephen Boyd 

Reviewed-by: Rob Clark 

> ---
> This patch is based upon my my outstanding series[1] not because there
> is any real requirement but simply to avoid merge conflicts.  I
> believe that my previous series is ready to land.  If, however, you'd
> prefer that I rebase this patch somewhere atop something else then
> please shout.
>
> [1] https://lore.kernel.org/r/20200430194617.197510-1-diand...@chromium.org
>
> Changes in v2:
> - Use SN_MAX_DP_LANES instead of 4 in one place.
> - Comment that we aren't doing full validation of dts params.
> - Check dp_lanes <= SN_MAX_DP_LANES to avoid buffer overrun.
> - Add missing of_node_put()
>
>  drivers/gpu/drm/bridge/ti-sn65dsi86.c | 82 ++-
>  1 file changed, 68 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c 
> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> index 1a125423eb07..534b712dccf8 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -50,8 +50,12 @@
>  #define SN_CHA_VERTICAL_BACK_PORCH_REG 0x36
>  #define SN_CHA_HORIZONTAL_FRONT_PORCH_REG  0x38
>  #define SN_CHA_VERTICAL_FRONT_PORCH_REG0x3A
> +#define SN_LN_ASSIGN_REG   0x59
> +#define  LN_ASSIGN_WIDTH   2
>  #define SN_ENH_FRAME_REG   0x5A
>  #define  VSTREAM_ENABLEBIT(3)
> +#define  LN_POLRS_OFFSET   4
> +#define  LN_POLRS_MASK 0xf0
>  #define SN_DATA_FORMAT_REG 0x5B
>  #define  BPP_18_RGBBIT(0)
>  #define SN_HPD_DISABLE_REG 0x5C
> @@ -98,6 +102,7 @@
>
>  #define SN_REGULATOR_SUPPLY_NUM4
>
> +#define SN_MAX_DP_LANES4
>  #define SN_NUM_GPIOS   4
>
>  /**
> @@ -115,6 +120,8 @@
>   * @enable_gpio:  The GPIO we toggle to enable the bridge.
>   * @supplies: Data for bulk enabling/disabling our regulators.
>   * @dp_lanes: Count of dp_lanes we're using.
> + * @ln_assign:Value to program to the LN_ASSIGN register.
> + * @ln_polr:  Value for the 4-bit LN_POLRS field of SN_ENH_FRAME_REG.
>   *
>   * @gchip:If we expose our GPIOs, this is used.
>   * @gchip_output: A cache of whether we've set GPIOs to output.  This
> @@ -140,6 +147,8 @@ struct ti_sn_bridge {
> struct gpio_desc*enable_gpio;
> struct regulator_bulk_data  supplies[SN_REGULATOR_SUPPLY_NUM];
> int dp_lanes;
> +   u8  ln_assign;
> +   u8  ln_polrs;
>
> struct gpio_chipgchip;
> DECLARE_BITMAP(gchip_output, SN_NUM_GPIOS);
> @@ -707,26 +716,20 @@ static void ti_sn_bridge_enable(struct drm_bridge 
> *bridge)
> int dp_rate_idx;
> unsigned int val;
> int ret = -EINVAL;
> +   int max_dp_lanes;
>
> -   /*
> -* Run with the maximum number of lanes that the DP sink supports.
> -*
> -* Depending use cases, we might want to revisit this later because:
> -* - It's plausible that someone may have run fewer lines to the
> -*   sink than the sink actually supports, assuming that the lines
> -*   will just be driven at a higher rate.
> -* - The DP spec seems to indicate that it's more important to 
> minimize
> -*   the number of lanes than the link rate.
> -*
> -* If we do revisit, it would be important to measure the power 
> impact.
> -*/
> -   pdata->dp_lanes = ti_sn_get_max_lanes(pdata);
> +   max_dp_lanes = ti_sn_get_max_lanes(pdata);
> +   pdata->dp_lanes = min(pdata->dp_lanes, max_dp_lanes);
>
> /* DSI_A lane config */
> -   val = CHA_DSI_LANES(4 - pdata->dsi->lanes);
> +   val = CHA_DSI_LANES(SN_MAX_DP_LANES - pdata->dsi->lanes);
> regmap_update_bits(pdata->regmap, SN_DSI_LANES_REG,
>CHA_DSI_LANES_MASK, val);
>
> +   regmap_write(pdata->regmap, SN_LN_ASSIGN_REG, pdata->ln_assign);
> +   regmap_update_bits(pdata->regmap, SN_ENH_FRAME_REG, LN_POLRS_MASK,
> +  pdata->ln_polrs << LN_POLRS_OFFSET);
> +
>  

Re: [PATCH v1 0/18] backlight updates

2020-05-15 Thread Sam Ravnborg
Hi all.
i
...

> Sam Ravnborg (18):
>   drm/omap: display: use devm_of_find_backlight
>   drm/tilcdc: use devm_of_find_backlight
Tomi - thanks for the prompt review of the above two patches.

>   video: amba-clcd: use devm_of_find_backlight
Any takes for review/ack of this patch?

>   backlight: make of_find_backlight static
>   backlight: drop backlight_put()
>   backlight: make of_find_backlight_by_node() static
The above three patches are moved to the end of the patchset in v2.
They cannot be applied before the users are gone.
As we will remove users of of_find_backlight_by_node() in
drm-misc-next, we can only merge the "make static" patches in the
backlight tree after the merge window.
So move them to the end so we may apply other patches before.

I plan to send v2 end of the weekend, and hope for some feedback on the
doc pathches until then.

Sam

>   backlight: refactor fb_notifier_callback()
>   backlight: add backlight_is_blank()
>   backlight: improve backlight_ops documentation
>   backlight: improve backlight_properties documentation
>   backlight: improve backlight_device documentation
>   backlight: document inline functions in backlight.h
>   backlight: document enums in backlight.h
>   backlight: remove the unused backlight_bl driver
>   backlight: drop extern from prototypes
>   backlight: add overview and update doc
>   backlight: wire up kernel-doc documentation
>   backlight: use backlight_is_blank() in all backlight drivers
> 
>  Documentation/gpu/backlight.rst |  12 +
>  Documentation/gpu/index.rst |   1 +
>  drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c |  18 +-
>  drivers/gpu/drm/tilcdc/tilcdc_panel.c   |  17 +-
>  drivers/video/backlight/88pm860x_bl.c   |   8 +-
>  drivers/video/backlight/Kconfig |   8 -
>  drivers/video/backlight/Makefile|   1 -
>  drivers/video/backlight/adp5520_bl.c|   5 +-
>  drivers/video/backlight/adp8860_bl.c|   5 +-
>  drivers/video/backlight/adp8870_bl.c|   5 +-
>  drivers/video/backlight/as3711_bl.c |   8 +-
>  drivers/video/backlight/backlight.c | 237 --
>  drivers/video/backlight/bd6107.c|   4 +-
>  drivers/video/backlight/corgi_lcd.c |   5 +-
>  drivers/video/backlight/cr_bllcd.c  |  22 +-
>  drivers/video/backlight/da903x_bl.c |   8 +-
>  drivers/video/backlight/ep93xx_bl.c |   3 +-
>  drivers/video/backlight/generic_bl.c| 110 ---
>  drivers/video/backlight/gpio_backlight.c|   4 +-
>  drivers/video/backlight/hp680_bl.c  |   4 +-
>  drivers/video/backlight/jornada720_bl.c |   2 +-
>  drivers/video/backlight/kb3886_bl.c |   4 +-
>  drivers/video/backlight/led_bl.c|   4 +-
>  drivers/video/backlight/lm3533_bl.c |   4 +-
>  drivers/video/backlight/locomolcd.c |   4 +-
>  drivers/video/backlight/lv5207lp.c  |   4 +-
>  drivers/video/backlight/max8925_bl.c|   8 +-
>  drivers/video/backlight/pwm_bl.c|   4 +-
>  drivers/video/backlight/qcom-wled.c |   4 +-
>  drivers/video/backlight/tps65217_bl.c   |   4 +-
>  drivers/video/backlight/wm831x_bl.c |   8 +-
>  drivers/video/fbdev/amba-clcd.c |  19 +-
>  include/linux/backlight.h   | 415 
> +++-
>  33 files changed, 536 insertions(+), 433 deletions(-)
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v1 06/18] backlight: make of_find_backlight_by_node() static

2020-05-15 Thread Sam Ravnborg
Hi myself and others.

On Thu, May 14, 2020 at 09:09:49PM +0200, Sam Ravnborg wrote:
> There are no external users of of_find_backlight_by_node().
> Make it static so we keep it that way.
> 
> Signed-off-by: Sam Ravnborg 
> Cc: Lee Jones 
> Cc: Daniel Thompson 
> Cc: Jingoo Han 
> ---
>  drivers/video/backlight/backlight.c | 22 +-
>  include/linux/backlight.h   | 10 --
>  2 files changed, 9 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/video/backlight/backlight.c 
> b/drivers/video/backlight/backlight.c
> index 547aa3e1a03a..91dfcf4a2087 100644
> --- a/drivers/video/backlight/backlight.c
> +++ b/drivers/video/backlight/backlight.c
> @@ -577,19 +577,9 @@ static int of_parent_match(struct device *dev, const 
> void *data)
>   return dev->parent && dev->parent->of_node == data;
>  }
>  
> -/**
> - * of_find_backlight_by_node() - find backlight device by device-tree node
> - * @node: device-tree node of the backlight device
> - *
> - * Returns a pointer to the backlight device corresponding to the given DT
> - * node or NULL if no such backlight device exists or if the device hasn't
> - * been probed yet.
> - *
> - * This function obtains a reference on the backlight device and it is the
> - * caller's responsibility to drop the reference by calling put_device() on
> - * the backlight device's .dev field.
> - */
> -struct backlight_device *of_find_backlight_by_node(struct device_node *node)
> +/* Find backlight device by device-tree node */
> +static struct backlight_device *
> +of_find_backlight_by_node(struct device_node *node)
>  {
>   struct device *dev;
>  
> @@ -598,6 +588,12 @@ struct backlight_device 
> *of_find_backlight_by_node(struct device_node *node)
>   return dev ? to_backlight_device(dev) : NULL;
>  }
>  EXPORT_SYMBOL(of_find_backlight_by_node);
Dropped this EXPORT in v2.

Sam

> +#else
> +static struct backlight_device *
> +of_find_backlight_by_node(struct device_node *node)
> +{
> + return NULL;
> +}
>  #endif
>  
>  static struct backlight_device *of_find_backlight(struct device *dev)
> diff --git a/include/linux/backlight.h b/include/linux/backlight.h
> index 3d757a850b88..b7839ea9d00a 100644
> --- a/include/linux/backlight.h
> +++ b/include/linux/backlight.h
> @@ -198,16 +198,6 @@ struct generic_bl_info {
>   void (*kick_battery)(void);
>  };
>  
> -#ifdef CONFIG_OF
> -struct backlight_device *of_find_backlight_by_node(struct device_node *node);
> -#else
> -static inline struct backlight_device *
> -of_find_backlight_by_node(struct device_node *node)
> -{
> - return NULL;
> -}
> -#endif
> -
>  #if IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)
>  struct backlight_device *devm_of_find_backlight(struct device *dev);
>  #else
> -- 
> 2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/i915: avoid unused scale_user_to_hw() warning

2020-05-15 Thread Chris Wilson
Quoting Arnd Bergmann (2020-04-28 22:30:50)
> After the function is no longer marked 'inline', there
> is now a new warning pointing out that the only caller
> is inside of an #ifdef:
> 
> drivers/gpu/drm/i915/display/intel_panel.c:493:12: warning: 
> 'scale_user_to_hw' defined but not used [-Wunused-function]
>   493 | static u32 scale_user_to_hw(struct intel_connector *connector,
>   |^~~~
> 
> Move the function itself into that #ifdef as well.
> 
> Fixes: 81b55ef1f47b ("drm/i915: drop a bunch of superfluous inlines")
> Signed-off-by: Arnd Bergmann 
Reviewed-b: Chris Wilson 
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 2/2] dt-bindings: arm-smmu: Add sc7180 compatible string

2020-05-15 Thread Doug Anderson
Hi,

On Fri, May 1, 2020 at 3:30 AM Sharat Masetty  wrote:
>
> This patch simply adds a new compatible string for SC7180 platform.
>
> Signed-off-by: Sharat Masetty 
> ---
>  Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml 
> b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
> index 6515dbe..986098b 100644
> --- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
> @@ -28,6 +28,7 @@ properties:
>- enum:
>- qcom,msm8996-smmu-v2
>- qcom,msm8998-smmu-v2
> +  - qcom,sc7180-smmu-v2
>- qcom,sdm845-smmu-v2
>- const: qcom,smmu-v2

Is anything blocking this patch from landing now?

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


Re: [PATCH 11/14] docs: move other kAPI documents to core-api

2020-05-15 Thread Jonathan Corbet
On Fri,  1 May 2020 17:37:55 +0200
Mauro Carvalho Chehab  wrote:

> There are a number of random documents that seem to be
> describing some aspects of the core-api. Move them to such
> directory, adding them at the core-api/index.rst file.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  Documentation/admin-guide/sysctl/vm.rst | 2 +-
>  Documentation/core-api/index.rst| 6 ++
>  Documentation/{mailbox.txt => core-api/mailbox.rst} | 0
>  Documentation/{nommu-mmap.txt => core-api/nommu-mmap.rst}   | 0
>  .../{this_cpu_ops.txt => core-api/this_cpu_ops.rst} | 0
>  .../unaligned-memory-access.rst}| 0
>  Documentation/gpu/drm-mm.rst| 2 +-
>  arch/Kconfig| 2 +-
>  init/Kconfig| 2 +-
>  mm/Kconfig  | 2 +-
>  mm/nommu.c  | 2 +-
>  11 files changed, 12 insertions(+), 6 deletions(-)
>  rename Documentation/{mailbox.txt => core-api/mailbox.rst} (100%)
>  rename Documentation/{nommu-mmap.txt => core-api/nommu-mmap.rst} (100%)
>  rename Documentation/{this_cpu_ops.txt => core-api/this_cpu_ops.rst} (100%)
>  rename Documentation/{unaligned-memory-access.txt => 
> core-api/unaligned-memory-access.rst} (100%)

This one doesn't apply for me.  Beyond that, I'm not entirely convinced
about a couple of the moves...

 - mailbox.txt seems like driver-api stuff to me?
 - nommu-mmap.txt is mostly (though not completely) about the semantic of
   mmap() options as seen by user space, so perhaps belongs in that
   manual...?

Thanks,

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


Re: [git pull] drm fixes for 5.7-rc6

2020-05-15 Thread pr-tracker-bot
The pull request you sent on Fri, 15 May 2020 16:12:52 +1000:

> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-05-15

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

Thank you!

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


Re: [PATCH v12 00/14] In order to readout DP SDPs, refactors the handling of DP SDPs

2020-05-15 Thread Mun, Gwan-gyeong
Hi Ville,
Thank you for notifying me that. I definitely missed the crash.
Sorry for that.
Danial and Jani, I' under debugging the crash case.
If you are availabe please do not merge current version.

Br,

G.G.

> 
On Fri, 2020-05-15 at 16:14 +0200, Daniel Vetter wrote:
> On Fri, May 15, 2020 at 04:13:18PM +0300, Jani Nikula wrote:
> > On Fri, 15 May 2020, Ville Syrjälä 
> > wrote:
> > > On Thu, May 14, 2020 at 02:19:23PM +0300, Jani Nikula wrote:
> > > > On Thu, 14 May 2020, Gwan-gyeong Mun  > > > > wrote:
> > > > > In order to readout DP SDPs (Secondary Data Packet: DP HDR
> > > > > Metadata
> > > > > Infoframe SDP, DP VSC SDP), it refactors handling DP SDPs
> > > > > codes.
> > > > > It adds new compute routines for DP HDR Metadata Infoframe
> > > > > SDP
> > > > > and DP VSC SDP. 
> > > > > And new writing routines of DP SDPs (Secondary Data Packet)
> > > > > that uses
> > > > > computed configs.
> > > > > New reading routines of DP SDPs are added for readout.
> > > > > It adds a logging function for DP VSC SDP.
> > > > > When receiving video it is very useful to be able to log DP
> > > > > VSC SDP.
> > > > > This greatly simplifies debugging.
> > > > > In order to use a common VSC SDP Colorimetry calculating code
> > > > > on PSR,
> > > > > it uses a new psr vsc sdp compute routine.
> > > > 
> > > > Pushed the series to drm-intel-next-queued with Daniel's irc
> > > > ack for
> > > > merging the two non-i915 patches that route too.
> > > 
> > > fi-hsw-4770 now oopses at boot:
> > 
> > /o\
> > 
> > What did I miss? What part about the CI report did I overlook?
> 
> Participating hosts (48 -> 45)
> --
> 
>   Additional (1): fi-kbl-7560u 
>   Missing(4): fi-byt-clapper fi-byt-squawks fi-bsw-cyan fi-hsw-
> 4200u
> 
> 
> You kill machines at boot, CI won't tell you.
> 
> This is (or at least was) because the network is shitty enough that
> we
> have more spurious failures because the ethernet went into the ether
> than
> because of people having killed the machine with their patches for
> real.
> Also it's hard to grab logs if the thing doesn't work at all, so cant
> give
> you any more data than the above.
> 
> Yes this sucks :-/
> 
> Cheers, Daniel
> 
> > BR,
> > Jani.
> > 
> > 
> > > <1>[3.736903] BUG: kernel NULL pointer dereference, address:
> > > 
> > > <1>[3.736916] #PF: supervisor read access in kernel mode
> > > <1>[3.736916] #PF: error_code(0x) - not-present page
> > > <6>[3.736917] PGD 0 P4D 0 
> > > <4>[3.736919] Oops:  [#1] PREEMPT SMP PTI
> > > <4>[3.736921] CPU: 0 PID: 363 Comm: systemd-udevd Not tainted
> > > 5.7.0-rc5-CI-CI_DRM_8485+ #1
> > > <4>[3.736922] Hardware name: LENOVO 10AGS00601/SHARKBAY, BIOS
> > > FBKT34AUS 04/24/2013
> > > <4>[3.736986] RIP: 0010:intel_psr_enabled+0x8/0x70 [i915]
> > > <4>[3.736988] Code: 18 48 c7 c6 40 09 79 a0 e8 e3 e2 04 e1 0f
> > > b6 44 24 03 e9 f4 fd ff ff 90 66 2e 0f 1f 84 00 00 00 00 00 41 54
> > > 55 53 48 83 ec 08 <48> 8b 9f d8 fe ff ff f6 83 5e 0d 00 00 20 74
> > > 09 80 bb 6c b6 00 00
> > > <4>[3.737036] RSP: 0018:c947f8a0 EFLAGS: 00010286
> > > <4>[3.737042] RAX: 0002 RBX: 8883ffd04000
> > > RCX: 0001
> > > <4>[3.737048] RDX: 0007 RSI: 8883ffd04000
> > > RDI: 0128
> > > <4>[3.737055] RBP: 888406afe200 R08: 000f
> > > R09: 0001
> > > <4>[3.737061] R10:  R11: 
> > > R12: 
> > > <4>[3.737068] R13: 8883f75d R14: 888406afe200
> > > R15: 8883f75d0870
> > > <4>[3.737075] FS:  7f71618f9680()
> > > GS:88840ec0() knlGS:
> > > <4>[3.737082] CS:  0010 DS:  ES:  CR0:
> > > 80050033
> > > <4>[3.737088] CR2:  CR3: 000402510002
> > > CR4: 001606f0
> > > <4>[3.737094] DR0:  DR1: 
> > > DR2: 
> > > <4>[3.737101] DR3:  DR6: fffe0ff0
> > > DR7: 0400
> > > <4>[3.737107] Call Trace:
> > > <4>[3.737175]  intel_read_dp_sdp+0x1a4/0x380 [i915]
> > > <4>[3.737246]  hsw_crt_get_config+0x12/0x40 [i915]
> > > <4>[3.737317]  intel_modeset_setup_hw_state+0x3b3/0x16a0
> > > [i915]
> > > ...
> > 
> > -- 
> > Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [Freedreno] [PATCH] drm/msm/dpu: ensure device suspend happens during PM sleep

2020-05-15 Thread Doug Anderson
Hi,

On Fri, May 15, 2020 at 5:06 AM  wrote:
>
> On 2020-05-14 21:47, Doug Anderson wrote:
> > Hi,
> >
> > On Fri, May 1, 2020 at 6:31 AM Kalyan Thota 
> > wrote:
> >>
> >> "The PM core always increments the runtime usage counter
> >> before calling the ->suspend() callback and decrements it
> >> after calling the ->resume() callback"
> >>
> >> DPU and DSI are managed as runtime devices. When
> >> suspend is triggered, PM core adds a refcount on all the
> >> devices and calls device suspend, since usage count is
> >> already incremented, runtime suspend was not getting called
> >> and it kept the clocks on which resulted in target not
> >> entering into XO shutdown.
> >>
> >> Add changes to force suspend on runtime devices during pm sleep.
> >>
> >> Changes in v1:
> >>  - Remove unnecessary checks in the function
> >> _dpu_kms_disable_dpu (Rob Clark).
> >>
> >> Changes in v2:
> >>  - Avoid using suspend_late to reset the usagecount
> >>as suspend_late might not be called during suspend
> >>call failures (Doug).
> >>
> >> Changes in v3:
> >>  - Use force suspend instead of managing device usage_count
> >>via runtime put and get API's to trigger callbacks (Doug).
> >>
> >> Changes in v4:
> >>  - Check the return values of pm_runtime_force_suspend and
> >>pm_runtime_force_resume API's and pass appropriately (Doug).
> >>
> >> Changes in v5:
> >
> > Can you please put the version number properly in your subject?  It's
> > really hard to tell one version of your patch from another.
> >
> >
> >>  - With v4 patch, test cycle has uncovered issues in device resume.
> >>
> >>On bubs: cmd tx failures were seen as SW is sending panel off
> >>commands when the dsi resources are turned off.
> >>
> >>Upon suspend, DRM driver will issue a NULL composition to the
> >>dpu, followed by turning off all the HW blocks.
> >>
> >>v5 changes will serialize the NULL commit and resource unwinding
> >>by handling them under PM prepare and PM complete phases there by
> >>ensuring that clks are on when panel off commands are being
> >>processed.
> >
> > I'm still most definitely not an expert in how all the DRM pieces all
> > hook up together, but the solution you have in this patch seems wrong
> > to me.  As far as I can tell the "prepare" state isn't supposed to be
> > actually doing the suspend work and here that's exactly what you're
> > doing.  I think you should find a different solution to ensure
> > ordering is correct.
> >
> > -Doug
> >
>
> Hi,

Quite honestly I'm probably not the right person to be reviewing this
code.  I mostly just noticed one of your early patches and it looked
strange to me.  Hopefully someone with actual experience in how all
the DRM components work together can actually review and see if this
makes sense.  Maybe Sean would know better?

That being said, let me at least look at what you're saying...


> Prepare and Complete are callbacks defined as part of Sleep and Resume
> sequence
>
> Entering PM SUSPEND the phases are : prepare --> suspend -->
> suspend_late --> suspend_noirq.
> While leaving PM SUSPEND the phases are: resume_noirq --> resume_early
> --> resume --> complete.

Sure, it's part of the sequence.  It's also documented in pm.h as:

 * The principal role of this callback is to prevent new children of
 * the device from being registered after it has returned (the driver's
 * subsystem and generally the rest of the kernel is supposed to prevent
 * new calls to the probe method from being made too once @prepare() has
 * succeeded).

It does not feel like that matches your usage of this call.


> The reason to push drm suspend handling to PM prepare phase is that
> parent here will trigger a modeset to turn off the timing and
> subsequently the panel.
> the child devices should not turn of their clocks before parent unwinds
> the composition. Hence they are serialized as per the sequence mentioned
> above.

So the general model in Linux is that children suspend before their
parents, right?  So you're saying that, in this case, the parent needs
to act on the child before the child suspends.  Is that correct?

Rather than hijacking the prepare/complete, I'd be at least slightly
inclined to move the other driver to turn off its clocks in
suspend_late and to turn them back on in resume_early?  That seems to
be what was done in "analogix_dp-rockchip.c" to solve a similar
problem.


> A similar approach is taken by other driver that use drm framework. In
> this driver, the device registers for prepare and complete callbacks to
> handle drm_suspend and drm_resume.
> https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/drivers/gpu/drm/exynos/exynos_drm_drv.c#L163

OK, if there is another driver in DRM then I guess I won't object too
strongly.  Note that when searching for other drivers I noticed this
bit in todo.rst:

* Most drivers (except i915 and nouveau) that use
* drm_atomic_helper_suspend/resume() can probably be converted to use
* 

[PULL] drm-intel-next

2020-05-15 Thread Joonas Lahtinen
)
- Remove redundant exec_fence (Chris)
- Mark the addition of the initial-breadcrumb in the request (Chris)
- Transfer old virtual breadcrumbs to irq_worker (Chris)
- Read the DP SDPs from the video DIP (Gwan-gyeong)
- Program DP SDPs with computed configs (Gwan-gyeong)
- Add state readout for DP VSC and DP HDR Metadata Infoframe SDP
  (Gwan-gyeong)
- Add compute routine for DP PSR VSC SDP (Gwan-gyeong)
- Use new DP VSC SDP compute routine on PSR (Gwan-gyeong)
- Restrict qgv points which don't have enough bandwidth. (Stanislav)
- Nuke pointless div by 64bit (Ville)

- Static checker code fixes (Nathan, Mika, Chris)
- Add logging function for DP VSC SDP (Gwan-gyeong)
- Include HDMI DRM infoframe, DP HDR metadata and DP VSC SDP in the
  crtc state dump (Gwan-gyeong)
- Make timeslicing explicit engine property (Chris, Tvrtko)
- Selftest and debugging improvements (Chris)
- Align variable names with BSpec (Ville)
- Tidy up gen8+ breadcrumb emission code (Chris)
- Turn intel_digital_port_connected() in a vfunc (Ville)
- Use stashed away hpd isr bits in intel_digital_port_connected() (Ville)
- Extract i915_cs_timestamp_{ns_to_ticks,tick_to_ns}() (Ville)

The following changes since commit 230982d8d8df7f9d9aa216840ea2db1df6ad5d37:

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

are available in the Git repository at:

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

for you to fetch changes up to 3a36aa237e4ed04553c0998cf5f47eda3e206e4f:

  drm/i915: Update DRIVER_DATE to 20200515 (2020-05-15 14:49:24 +0300)



UAPI Changes:

- drm/i915: Show per-engine default property values in sysfs

By providing the default values configured into the kernel via sysfs, it
is much more convenient for userspace to restore those sane defaults, or
at least know what are considered good baseline. This is useful, for
example, to cleanup after any failed userspace prior to commencing new
jobs.

Cross-subsystem Changes:

- video/hdmi: Add Unpack only function for DRM infoframe
- Includes pull request gvt-next-2020-05-12

Driver Changes:

- Restore Cherryview back to full-ppgtt (Chris, Mika)
- Document locking guidelines for i915 (Chris, Daniel, Joonas)
- Fix GitLab #1746: Handle idling during i915_gem_evict_something busy loops 
(Chris)
- Display WA #1105: Require linear fb stride to be multiple of 512 bytes on
  gen9/glk (Ville)
- Add Wa_14010685332 for ICP/ICL (Matt R)
- Restrict w/a 1607087056 for EHL/JSL (Swathi)
- Fix interrupt handling for DP AUX transactions on Tigerlake (Imre)
- Revert "drm/i915/tgl: Include ro parts of l3 to invalidate" (Mika)
- Fix HDC pipeline flush hardware bit on Gen12 (Mika)
- Flush L3 when flushing render on Gen12 (Mika)
- Invalidate aux table entries forcibly between BB on Gen12 (Mika)
- Add aux table invalidate for all engines on Gen12 (Mika)
- Force pte cacheline to main memory Gen8+ (Mika)
- Add and enable TGL+ SAGV support (Stanislav)
- Implement vm_ops->access on i915 mmaps for GDB (Chris, Kristian)
- Replace zero-length array with flexible-array (Gustavo)
- Improve batch buffer pool effectiveness to mitigate soft-rc6 hit (Chris)
- Remove wait priority boosting (Chris)
- Keep driver module referenced when PMU is active (Chris)
- Sanitize RPS interrupts upon resume (Chris)
- Extend pcode read timeout to 20 ms (Chris)
- Wait for ACT sent before enabling MST pipe (Ville)
- Extend support to async relocations to SNB (Chris)
- Remove CNL pre-prod workarounds (Ville)
- Don't enable WaIncreaseLatencyIPCEnabled when IPC is disabled (Sultan)
- Record the active CCID from before reset (Chris)
- Mark concurrent submissions with a weak-dependency (Chris)
- Peel dma-fence-chains for await to allow engine-to-engine sync (Lionel)
- Prevent using semaphores to chain up to external fences (Chris)
- Fix GLK watermark calculations (Ville)
- Emit await(batch) before MI_BB_START (Chris)
- Reset execlists registers before HWSP (Chris)
- Drop no-semaphore boosting in favor of fast timeslicing (Chris)
- Fix enabled infoframe states of lspcon (Gwan-gyeong)
- Program DP SDPs on pipe updates (Gwan-gyeong)
- Stop sending DP SDPs on ddi disable (Gwan-gyeong)
- Store CS timestamp frequency in Hz (Ville)

- Remove unused HAS_FWTABLE macro (Pascal)
- Use batchbuffer chaining for relocations to save ring space (Chris)
- Try different engines for relocs if MI ops not supported (Chris, Tvrtko)
- Lazily acquire the device wakeref for freeing objects (Chris)
- Streamline display code arithmetics around rounding etc. (Ville)
- Use bw state for per crtc SAGV evaluation (Stanislav)
- Track active_pipes in bw_state (Stanislav)
- Nuke mode.vrefresh usage (Ville)
- Warn if the FBC is still writing to stolen on removal (Chris)
- Added new PCode commands prepping for QGV rescricting (Stansilav)
- Stop holding onto the pinned_default_state (Chris)
- Propagate error from completed fences (Chris)
-

Re: linux-next: manual merge of the drm-misc tree with the drm-misc-fixes tree

2020-05-15 Thread Tomi Valkeinen
Hi Stephen,

On 23/04/2020 06:17, Stephen Rothwell wrote:
> Hi all,
> 
> On Tue, 21 Apr 2020 09:10:25 +0300 Tomi Valkeinen  
> wrote:
>>
>> On 21/04/2020 04:52, Stephen Rothwell wrote:
>>>
>>> Today's linux-next merge of the drm-misc tree got a conflict in:he drm-misc 
>>> tree with the drm-misc-fixes tree
>>>
>>> drivers/gpu/drm/tidss/tidss_encoder.c
>>>
>>> between commit:
>>>
>>> 9da67433f64e ("drm/tidss: fix crash related to accessing freed memory")
>>>
>>> from the drm-misc-fixes tree and commit:
>>>
>>> b28ad7deb2f2 ("drm/tidss: Use simple encoder")
>>>
>>> from the drm-misc tree.
>>>
>>> I fixed it up (I just used the latter version of this file) and can
>>
>> We need to use "drm/tidss: fix crash related to accessing freed memory" 
>> version.
>>
>>> carry the fix as necessary. This is now fixed as far as linux-next is
>>> concerned, but any non trivial conflicts should be mentioned to your
>>> upstream maintainer when your tree is submitted for merging.  You may
>>> also want to consider cooperating with the maintainer of the conflicting
>>> tree to minimise any particularly complex conflicts.
>>
>> I have fixed this with drm-misc's dim tool, so I presume the conflict goes 
>> away when drm-misc-fixes
>> is merged to drm-fixes, and drm-fixes is then at some point merged to 
>> drm-misc-next.
>>
>> It was a bit bad timing with the "drm/tidss: Use simple encoder", which 
>> removes the plumbing I
>> needed to implement the fix. So I effectively revert the "drm/tidss: Use 
>> simple encoder".
>>
>>Tomi
>>
> 
> This is now a conflict between the drm and drm-misc-fixes trees.

The fix ("drm/tidss: fix crash related to accessing freed memory") is in 
v5.7-rc3, and the conflicting change ("drm/tidss: Use simple encoder") in 
drm-next.

The conflict resolution in linux-next drops the fix and take the change from 
drm-next, which causes crash on module removal.

Here's the diff I made on top of linux-next to fix it. Essentially dropping the 
simple-encoder change, and reapplying the fix. This should be fixed in drm-next 
when Dave next time pulls in Linus' branch.

diff --git a/drivers/gpu/drm/tidss/tidss_encoder.c 
b/drivers/gpu/drm/tidss/tidss_encoder.c
index 4c0558286f5e..e624cdcbb567 100644
--- a/drivers/gpu/drm/tidss/tidss_encoder.c
+++ b/drivers/gpu/drm/tidss/tidss_encoder.c
@@ -56,25 +56,38 @@ static int tidss_encoder_atomic_check(struct drm_encoder 
*encoder,
return 0;
 }
 
+static void tidss_encoder_destroy(struct drm_encoder *encoder)
+{
+   drm_encoder_cleanup(encoder);
+   kfree(encoder);
+}
+
 static const struct drm_encoder_helper_funcs encoder_helper_funcs = {
.atomic_check = tidss_encoder_atomic_check,
 };
 
+static const struct drm_encoder_funcs encoder_funcs = {
+   .destroy = tidss_encoder_destroy,
+};
+
 struct drm_encoder *tidss_encoder_create(struct tidss_device *tidss,
 u32 encoder_type, u32 possible_crtcs)
 {
struct drm_encoder *enc;
int ret;
 
-   enc = devm_kzalloc(tidss->dev, sizeof(*enc), GFP_KERNEL);
+   enc = kzalloc(sizeof(*enc), GFP_KERNEL);
if (!enc)
return ERR_PTR(-ENOMEM);
 
enc->possible_crtcs = possible_crtcs;
 
-   ret = drm_simple_encoder_init(>ddev, enc, encoder_type);
-   if (ret < 0)
+   ret = drm_encoder_init(>ddev, enc, _funcs,
+  encoder_type, NULL);
+   if (ret < 0) {
+   kfree(enc);
return ERR_PTR(ret);
+   }
 
drm_encoder_helper_add(enc, _helper_funcs);
 


 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 12/38] drm/gem: add drm_object_put helper

2020-05-15 Thread Steven Price

On 15/05/2020 10:50, Emil Velikov wrote:

From: Emil Velikov 

Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.

Add helper, which will allow us to transition the drivers one by one,
dropping the suffix.

v2: add missing space after function name (Jani)

Signed-off-by: Emil Velikov 
Acked-by: Sam Ravnborg  (v1)


NIT: The subject is wrong: s/drm_object_put/drm_gem_object_put/

With that fixed:

Reviewed-by: Steven Price 

Steve


---
  include/drm/drm_gem.h | 6 --
  1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
index a231a2b3f5ac..2f7b86c0649c 100644
--- a/include/drm/drm_gem.h
+++ b/include/drm/drm_gem.h
@@ -364,17 +364,19 @@ static inline void drm_gem_object_get(struct 
drm_gem_object *obj)
  }
  
  /**

- * drm_gem_object_put_unlocked - drop a GEM buffer object reference
+ * drm_gem_object_put - drop a GEM buffer object reference
   * @obj: GEM buffer object
   *
   * This releases a reference to @obj.
   */
  static inline void
-drm_gem_object_put_unlocked(struct drm_gem_object *obj)
+drm_gem_object_put(struct drm_gem_object *obj)
  {
kref_put(>refcount, drm_gem_object_free);
  }
  
+#define drm_gem_object_put_unlocked drm_gem_object_put

+
  void drm_gem_object_put_locked(struct drm_gem_object *obj);
  
  int drm_gem_handle_create(struct drm_file *file_priv,




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


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

2020-05-15 Thread Ramalingam C
On 2020-04-29 at 15:54:46 -0400, Sean Paul wrote:
> From: Sean Paul 
> 
> Changes in v6:
> -Rebased on -tip
> -Disabled HDCP over MST on GEN12
> -Addressed Lyude's review comments in the QUERY_STREAM_ENCRYPTION_STATUS patch

Sean,

What is the test setup you have used?

I am afraid our CI dont have the coverage for MST capability yet to provide
the functional status of the code.

-Ram.
> 
> Sean Paul (16):
>   drm/i915: Fix sha_text population code
>   drm/i915: Clear the repeater bit on HDCP disable
>   drm/i915: WARN if HDCP signalling is enabled upon disable
>   drm/i915: Intercept Aksv writes in the aux hooks
>   drm/i915: Use the cpu_transcoder in intel_hdcp to toggle HDCP
> signalling
>   drm/i915: Factor out hdcp->value assignments
>   drm/i915: Protect workers against disappearing connectors
>   drm/i915: Don't fully disable HDCP on a port if multiple pipes are
> using it
>   drm/i915: Support DP MST in enc_to_dig_port() function
>   drm/i915: Use ddi_update_pipe in intel_dp_mst
>   drm/i915: Factor out HDCP shim functions from dp for use by dp_mst
>   drm/i915: Plumb port through hdcp init
>   drm/i915: Add connector to hdcp_shim->check_link()
>   drm/mst: Add support for QUERY_STREAM_ENCRYPTION_STATUS MST sideband
> message
>   drm/i915: Print HDCP version info for all connectors
>   drm/i915: Add HDCP 1.4 support for MST connectors
> 
>  drivers/gpu/drm/drm_dp_mst_topology.c | 142 
>  drivers/gpu/drm/i915/Makefile |   1 +
>  drivers/gpu/drm/i915/display/intel_ddi.c  |  29 +-
>  drivers/gpu/drm/i915/display/intel_ddi.h  |   2 +
>  .../drm/i915/display/intel_display_debugfs.c  |  21 +-
>  .../drm/i915/display/intel_display_types.h|  30 +-
>  drivers/gpu/drm/i915/display/intel_dp.c   | 654 +--
>  drivers/gpu/drm/i915/display/intel_dp.h   |   9 +
>  drivers/gpu/drm/i915/display/intel_dp_hdcp.c  | 743 ++
>  drivers/gpu/drm/i915/display/intel_dp_mst.c   |  19 +
>  drivers/gpu/drm/i915/display/intel_hdcp.c | 217 +++--
>  drivers/gpu/drm/i915/display/intel_hdcp.h |   2 +-
>  drivers/gpu/drm/i915/display/intel_hdmi.c |  25 +-
>  .../drm/selftests/test-drm_dp_mst_helper.c|  17 +
>  include/drm/drm_dp_helper.h   |   3 +
>  include/drm/drm_dp_mst_helper.h   |  44 ++
>  include/drm/drm_hdcp.h|   3 +
>  17 files changed, 1235 insertions(+), 726 deletions(-)
>  create mode 100644 drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> 
> -- 
> Sean Paul, Software Engineer, Google / Chromium OS
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


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

2020-05-15 Thread Ramalingam C
On 2020-04-29 at 15:55:02 -0400, Sean Paul wrote:
> From: Sean Paul 
> 
> Now that all the groundwork has been laid, we can turn on HDCP 1.4 over
> MST. Everything except for toggling the HDCP signalling and HDCP 2.2
> support is the same as the DP case, so we'll re-use those callbacks
> 
> Cc: Juston Li 
> Signed-off-by: Sean Paul 
> Link: 
> https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-12-s...@poorly.run
>  #v1
> Link: 
> https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-13-s...@poorly.run
>  #v2
> Link: 
> https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-13-s...@poorly.run
>  #v3
> Link: 
> https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-15-s...@poorly.run
>  #v4
> Link: 
> https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-17-s...@poorly.run
>  #v5
> 
> Changes in v2:
> -Toggle HDCP from encoder disable/enable
> -Don't disable HDCP on MST connector destroy, leave that for encoder
>  disable, just ensure the check_work routine isn't running any longer
> Changes in v3:
> -Place the shim in the new intel_dp_hdcp.c file (Ville)
> Changes in v4:
> -Actually use the mst shim for mst connections (Juston)
> -Use QUERY_STREAM_ENC_STATUS MST message to verify channel is encrypted
> Changes in v5:
> -Add sleep on disable signalling to match hdmi delay
> Changes in v6:
> -Disable HDCP over MST on GEN12+ since I'm unsure how it should work and I
>  don't have hardware to test it
> ---
>  drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 107 ++-
>  drivers/gpu/drm/i915/display/intel_dp_mst.c  |  18 
>  2 files changed, 124 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c 
> b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> index 4e3dafbea1f9..331fdb312e05 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> @@ -7,10 +7,12 @@
>   */
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  
>  #include "intel_display_types.h"
> +#include "intel_ddi.h"
>  #include "intel_dp.h"
>  #include "intel_hdcp.h"
>  
> @@ -618,6 +620,106 @@ static const struct intel_hdcp_shim intel_dp_hdcp_shim 
> = {
>   .protocol = HDCP_PROTOCOL_DP,
>  };
>  
> +static int
> +intel_dp_mst_hdcp_toggle_signalling(struct intel_digital_port 
> *intel_dig_port,
> + enum transcoder cpu_transcoder,
> + bool enable)
> +{
> + struct drm_i915_private *i915 = to_i915(intel_dig_port->base.base.dev);
> + int ret;
> +
> + if (!enable)
> + usleep_range(6, 60); /* Bspec says >= 6us */
> +
> + ret = intel_ddi_toggle_hdcp_signalling(_dig_port->base,
> +cpu_transcoder, enable);
Sean,

The bit configured here is meant for HDMI and DVI only. Ignore for DP.
Thanks anshuman for pointing that out.
> + if (ret)
> + drm_dbg_kms(>drm, "%s HDCP signalling failed (%d)\n",
> +   enable ? "Enable" : "Disable", ret);
> + return ret;
> +}
> +
> +static
> +int intel_dp_mst_hdcp2_write_msg(struct intel_digital_port *intel_dig_port,
> +  void *buf, size_t size)
> +{
> + return -EOPNOTSUPP;
> +}
> +
> +static
> +int intel_dp_mst_hdcp2_read_msg(struct intel_digital_port *intel_dig_port,
> + u8 msg_id, void *buf, size_t size)
> +{
> + return -EOPNOTSUPP;
> +}
> +
> +static int
> +intel_dp_mst_hdcp2_config_stream_type(struct intel_digital_port 
> *intel_dig_port,
> +   bool is_repeater, u8 content_type)
> +{
> + return -EOPNOTSUPP;
> +}
> +
> +static
> +int intel_dp_mst_hdcp2_check_link(struct intel_digital_port *intel_dig_port)
> +{
> + return -EOPNOTSUPP;
> +}
> +
> +static
> +int intel_dp_mst_hdcp2_capable(struct intel_digital_port *intel_dig_port,
> +bool *capable)
> +{
> + *capable = false;
> + return 0;
> +}
> +
> +static
> +bool intel_dp_mst_hdcp_check_link(struct intel_digital_port *intel_dig_port,
> +   struct intel_connector *connector)
> +{
> + struct drm_i915_private *i915 = to_i915(intel_dig_port->base.base.dev);
> + struct intel_dp *intel_dp = _dig_port->dp;
> + struct drm_dp_query_stream_enc_status_ack_reply reply;
> + int ret;
> +
> + if (!intel_dp_hdcp_check_link(intel_dig_port, connector))
> + return false;
> +
> + ret = drm_dp_send_query_stream_enc_status(_dp->mst_mgr,
> +   connector->port, );
> + if (ret) {
> + drm_dbg_kms(>drm,
> + "[CONNECTOR:%d:%s] failed QSES ret=%d\n",
> + connector->base.base.id, connector->base.name, ret);
> + return false;
> + }
> +
> + return reply.auth_completed && reply.encryption_enabled;
> +}
> +
> +static 

Re: Re:Re: [PATCH v2] drm/arm: fixes pixel clock enabled with wrong format

2020-05-15 Thread Liviu Dudau
Hi Bernard,

On Fri, May 08, 2020 at 04:47:17PM +0800, Bernard wrote:
> From: "赵军奎" 
> Date: 2020-04-24 19:37:36
> To:  Liviu Dudau 
> Cc:  Brian Starkey ,David Airlie 
> ,Daniel Vetter 
> ,dri-devel@lists.freedesktop.org,linux-ker...@vger.kernel.org,opensource.ker...@vivo.com
> Subject: Re:Re: [PATCH v2] drm/arm: fixes pixel clock enabled with wrong 
> format
> 
> 
> 
> 
> From: Liviu Dudau 
> Date: 2020-04-24 19:09:50
> To:  Bernard Zhao 
> Cc:  Brian Starkey ,David Airlie 
> ,Daniel Vetter 
> ,dri-devel@lists.freedesktop.org,linux-ker...@vger.kernel.org,opensource.ker...@vivo.com
> Subject: Re: [PATCH v2] drm/arm: fixes pixel clock enabled with wrong 
> format>Hi Bernand,
> >
> >On Thu, Apr 23, 2020 at 11:35:51PM -0700, Bernard Zhao wrote:
> >> The pixel clock is still enabled when the format is wrong.
> >> no error branch handle, and also some register is not set
> >> in this case, e.g: HDLCD_REG__SELECT. Maybe we
> >> should disable this clock and throw an warn message when
> >> this happened.
> >> With this change, the code maybe a bit more readable.
> >> 
> >> Signed-off-by: Bernard Zhao 
> >> 
> >> Changes since V1:
> >> *add format error handle, if format is not correct, throw
> >> an warning message and disable this clock.
> >> 
> >> Link for V1:
> >> *https://lore.kernel.org/patchwork/patch/1228501/
> >> ---
> >>  drivers/gpu/drm/arm/hdlcd_crtc.c | 13 +
> >>  1 file changed, 9 insertions(+), 4 deletions(-)
> >> 
> >> diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c 
> >> b/drivers/gpu/drm/arm/hdlcd_crtc.c
> >> index af67fefed38d..f3945dee2b7d 100644
> >> --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
> >> +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
> >> @@ -96,7 +96,7 @@ static int hdlcd_set_pxl_fmt(struct drm_crtc *crtc)
> >>}
> >>  
> >>if (WARN_ON(!format))
> >> -  return 0;
> >> +  return -EINVAL;
> >
> >That is the right fix!
> >
> >>  
> >>/* HDLCD uses 'bytes per pixel', zero means 1 byte */
> >>btpp = (format->bits_per_pixel + 7) / 8;
> >> @@ -125,7 +125,7 @@ static int hdlcd_set_pxl_fmt(struct drm_crtc *crtc)
> >>return 0;
> >>  }
> >>  
> >> -static void hdlcd_crtc_mode_set_nofb(struct drm_crtc *crtc)
> >> +static int hdlcd_crtc_mode_set_nofb(struct drm_crtc *crtc)
> >
> >But this is not. We don't need to propagate the error further, just 
> >
> >>  {
> >>struct hdlcd_drm_private *hdlcd = crtc_to_hdlcd_priv(crtc);
> >>struct drm_display_mode *m = >state->adjusted_mode;
> >> @@ -162,9 +162,10 @@ static void hdlcd_crtc_mode_set_nofb(struct drm_crtc 
> >> *crtc)
> >>  
> >>err = hdlcd_set_pxl_fmt(crtc);
> >>if (err)
> >> -  return;
> >
> 
> My previous understanding was that when such an exception occurred, it was 
> caught
> in the atomic_enable interface, and then disable pixel clock. I am not sure 
> is this ok or
> i have to do more register clean operaction.
> 
> >... return here so that we don't call clk_set_rate();
> And for this part, i am a little confused :
> 1 clk_set_rate must be set even if format is wrong?
> 2 The original code logic shows that If format is not correct, we will not 
> set registers 
> HDLCD_REG_PIXEL_FORMAT & HDLCD_REG__SELECT, will this bring in
> any problems?
> 3 if 1 the rate must set & 2 registers above doesn`t matter, then maybe there 
> is no
> need to disable pixel clock.
> Am i misunderstanding

You are right, the pixel format check should not happen inside 
hdlcd_crtc_atomic_enable()
hook, it should be moved into a separate function hdlcd_crtc_atomic_check() and 
that needs
to be hooked into .atomic_check() for hdlcd_crtc_helper_funcs().

If you want to have another go I'll be happy to review and Ack your patch.

Best regards,
Liviu 

> 
> Regards,
> Bernard
> 
> >> +  return err;
> >>  
> >>clk_set_rate(hdlcd->clk, m->crtc_clock * 1000);
> >> +  return 0;
> >>  }
> >>  
> >>  static void hdlcd_crtc_atomic_enable(struct drm_crtc *crtc,
> >> @@ -173,7 +174,11 @@ static void hdlcd_crtc_atomic_enable(struct drm_crtc 
> >> *crtc,
> >>struct hdlcd_drm_private *hdlcd = crtc_to_hdlcd_priv(crtc);
> >>  
> >>clk_prepare_enable(hdlcd->clk);
> >> -  hdlcd_crtc_mode_set_nofb(crtc);
> >> +  if (hdlcd_crtc_mode_set_nofb(crtc)) {
> >> +  DRM_DEBUG_KMS("Invalid format, pixel clock enable failed!\n");
> >> +  clk_disable_unprepare(hdlcd->clk);
> >> +  return;
> >> +  }
> >>hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 1);
> >>drm_crtc_vblank_on(crtc);
> >>  }
> >> -- 
> >> 2.26.2
> >> 
> >
> >-- 
> >
> >| I would like to |
> >| fix the world,  |
> >| but they're not |
> >| giving me the   |
> > \ source code!  /
> >  ---
> >¯\_(ツ)_/¯
> 
> 
> 

-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯
___
dri-devel mailing list
dri-devel@lists.freedesktop.org

Re: [PATCH v2 34/38] drm/vgem: remove _unlocked suffix in drm_object_put_unlocked

2020-05-15 Thread Daniel Vetter
On Fri, May 15, 2020 at 10:51:14AM +0100, Emil Velikov wrote:
> From: Emil Velikov 
> 
> Spelling out _unlocked for each and every driver is a annoying.
> Especially if we consider how many drivers, do not know (or need to)
> about the horror stories involving struct_mutex.
> 
> Just drop the suffix. It makes the API cleaner.
> 
> Done via the following script:
> 
> __from=drm_gem_object_put_unlocked
> __to=drm_gem_object_put
> for __file in $(git grep --name-only $__from); do
>   sed -i  "s/$__from/$__to/g" $__file;
> done
> 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Emil Velikov 
> Signed-off-by: Emil Velikov 
> Acked-by: Sam Ravnborg 

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/vgem/vgem_drv.c   | 6 +++---
>  drivers/gpu/drm/vgem/vgem_fence.c | 2 +-
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
> index ec1a8ebb6f1b..e4dc7b267a0b 100644
> --- a/drivers/gpu/drm/vgem/vgem_drv.c
> +++ b/drivers/gpu/drm/vgem/vgem_drv.c
> @@ -198,7 +198,7 @@ static struct drm_gem_object *vgem_gem_create(struct 
> drm_device *dev,
>  
>   ret = drm_gem_handle_create(file, >base, handle);
>   if (ret) {
> - drm_gem_object_put_unlocked(>base);
> + drm_gem_object_put(>base);
>   return ERR_PTR(ret);
>   }
>  
> @@ -223,7 +223,7 @@ static int vgem_gem_dumb_create(struct drm_file *file, 
> struct drm_device *dev,
>   args->size = gem_object->size;
>   args->pitch = pitch;
>  
> - drm_gem_object_put_unlocked(gem_object);
> + drm_gem_object_put(gem_object);
>  
>   DRM_DEBUG("Created object of size %llu\n", args->size);
>  
> @@ -251,7 +251,7 @@ static int vgem_gem_dumb_map(struct drm_file *file, 
> struct drm_device *dev,
>  
>   *offset = drm_vma_node_offset_addr(>vma_node);
>  unref:
> - drm_gem_object_put_unlocked(obj);
> + drm_gem_object_put(obj);
>  
>   return ret;
>  }
> diff --git a/drivers/gpu/drm/vgem/vgem_fence.c 
> b/drivers/gpu/drm/vgem/vgem_fence.c
> index 9268f6fc3f66..17f32f550dd9 100644
> --- a/drivers/gpu/drm/vgem/vgem_fence.c
> +++ b/drivers/gpu/drm/vgem/vgem_fence.c
> @@ -182,7 +182,7 @@ int vgem_fence_attach_ioctl(struct drm_device *dev,
>   dma_fence_put(fence);
>   }
>  err:
> - drm_gem_object_put_unlocked(obj);
> + drm_gem_object_put(obj);
>   return ret;
>  }
>  
> -- 
> 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 v2 36/38] drm/vkms: remove _unlocked suffix in drm_object_put_unlocked

2020-05-15 Thread Daniel Vetter
On Fri, May 15, 2020 at 10:51:16AM +0100, Emil Velikov wrote:
> From: Emil Velikov 
> 
> Spelling out _unlocked for each and every driver is a annoying.
> Especially if we consider how many drivers, do not know (or need to)
> about the horror stories involving struct_mutex.
> 
> Just drop the suffix. It makes the API cleaner.
> 
> Done via the following script:
> 
> __from=drm_gem_object_put_unlocked
> __to=drm_gem_object_put
> for __file in $(git grep --name-only $__from); do
>   sed -i  "s/$__from/$__to/g" $__file;
> done
> 
> v2:
>  - Rebase
> 
> Cc: Rodrigo Siqueira 
> Cc: Haneen Mohammed 
> Cc: Daniel Vetter 
> Signed-off-by: Emil Velikov 
> Acked-by: Sam Ravnborg  (v1)

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/vkms/vkms_gem.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/vkms/vkms_gem.c b/drivers/gpu/drm/vkms/vkms_gem.c
> index c541fec57566..a017fc59905e 100644
> --- a/drivers/gpu/drm/vkms/vkms_gem.c
> +++ b/drivers/gpu/drm/vkms/vkms_gem.c
> @@ -141,7 +141,7 @@ int vkms_dumb_create(struct drm_file *file, struct 
> drm_device *dev,
>   args->size = gem_obj->size;
>   args->pitch = pitch;
>  
> - drm_gem_object_put_unlocked(gem_obj);
> + drm_gem_object_put(gem_obj);
>  
>   DRM_DEBUG_DRIVER("Created object of size %lld\n", size);
>  
> -- 
> 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: [Intel-gfx] [PATCH v12 00/14] In order to readout DP SDPs, refactors the handling of DP SDPs

2020-05-15 Thread Saarinen, Jani
Hi,

> -Original Message-
> From: Intel-gfx  On Behalf Of Jani 
> Nikula
> Sent: perjantai 15. toukokuuta 2020 16.13
> To: Ville Syrjälä 
> Cc: linux-fb...@vger.kernel.org; daniel.vet...@ffwll.ch; intel-
> g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> laurent.pinch...@ideasonboard.com
> Subject: Re: [Intel-gfx] [PATCH v12 00/14] In order to readout DP SDPs, 
> refactors the
> handling of DP SDPs
> 
> On Fri, 15 May 2020, Ville Syrjälä  wrote:
> > On Thu, May 14, 2020 at 02:19:23PM +0300, Jani Nikula wrote:
> >> On Thu, 14 May 2020, Gwan-gyeong Mun 
> wrote:
> >> > In order to readout DP SDPs (Secondary Data Packet: DP HDR Metadata
> >> > Infoframe SDP, DP VSC SDP), it refactors handling DP SDPs codes.
> >> > It adds new compute routines for DP HDR Metadata Infoframe SDP and
> >> > DP VSC SDP.
> >> > And new writing routines of DP SDPs (Secondary Data Packet) that
> >> > uses computed configs.
> >> > New reading routines of DP SDPs are added for readout.
> >> > It adds a logging function for DP VSC SDP.
> >> > When receiving video it is very useful to be able to log DP VSC SDP.
> >> > This greatly simplifies debugging.
> >> > In order to use a common VSC SDP Colorimetry calculating code on
> >> > PSR, it uses a new psr vsc sdp compute routine.
> >>
> >> Pushed the series to drm-intel-next-queued with Daniel's irc ack for
> >> merging the two non-i915 patches that route too.
> >
> > fi-hsw-4770 now oopses at boot:
> 
> /o\
> 
> What did I miss? What part about the CI report did I overlook?
Damn, indeed:
https://patchwork.freedesktop.org/series/72853/
Ci results is success but it has:
Known issues


  Here are the changes found in Patchwork_17654 that come from known issues:

### CI changes ###

 Issues hit 

  * boot:
- fi-hsw-4770:[PASS][1] -> [FAIL][2] ([CI#80])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8481/fi-hsw-4770/boot.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17654/fi-hsw-4770/boot.html

> 
> BR,
> Jani.
> 
> 
> >
> > <1>[3.736903] BUG: kernel NULL pointer dereference, address:
> 
> > <1>[3.736916] #PF: supervisor read access in kernel mode
> > <1>[3.736916] #PF: error_code(0x) - not-present page
> > <6>[3.736917] PGD 0 P4D 0
> > <4>[3.736919] Oops:  [#1] PREEMPT SMP PTI
> > <4>[3.736921] CPU: 0 PID: 363 Comm: systemd-udevd Not tainted 
> > 5.7.0-rc5-CI-
> CI_DRM_8485+ #1
> > <4>[3.736922] Hardware name: LENOVO 10AGS00601/SHARKBAY, BIOS
> FBKT34AUS 04/24/2013
> > <4>[3.736986] RIP: 0010:intel_psr_enabled+0x8/0x70 [i915]
> > <4>[3.736988] Code: 18 48 c7 c6 40 09 79 a0 e8 e3 e2 04 e1 0f b6 44 24 
> > 03 e9 f4
> fd ff ff 90 66 2e 0f 1f 84 00 00 00 00 00 41 54 55 53 48 83 ec 08 <48> 8b 9f 
> d8 fe ff ff
> f6 83 5e 0d 00 00 20 74 09 80 bb 6c b6 00 00
> > <4>[3.737036] RSP: 0018:c947f8a0 EFLAGS: 00010286
> > <4>[3.737042] RAX: 0002 RBX: 8883ffd04000 RCX:
> 0001
> > <4>[3.737048] RDX: 0007 RSI: 8883ffd04000 RDI:
> 0128
> > <4>[3.737055] RBP: 888406afe200 R08: 000f R09:
> 0001
> > <4>[3.737061] R10:  R11:  R12:
> 
> > <4>[3.737068] R13: 8883f75d R14: 888406afe200 R15:
> 8883f75d0870
> > <4>[3.737075] FS:  7f71618f9680() GS:88840ec0()
> knlGS:
> > <4>[3.737082] CS:  0010 DS:  ES:  CR0: 80050033
> > <4>[3.737088] CR2:  CR3: 000402510002 CR4:
> 001606f0
> > <4>[3.737094] DR0:  DR1:  DR2:
> 
> > <4>[3.737101] DR3:  DR6: fffe0ff0 DR7:
> 0400
> > <4>[3.737107] Call Trace:
> > <4>[3.737175]  intel_read_dp_sdp+0x1a4/0x380 [i915]
> > <4>[3.737246]  hsw_crt_get_config+0x12/0x40 [i915]
> > <4>[3.737317]  intel_modeset_setup_hw_state+0x3b3/0x16a0 [i915]
> > ...
> 
> --
> Jani Nikula, Intel Open Source Graphics Center
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 10/38] drm/gem: fold drm_gem_object_put_unlocked and __drm_gem_object_put()

2020-05-15 Thread Daniel Vetter
On Fri, May 15, 2020 at 10:50:50AM +0100, Emil Velikov wrote:
> From: Emil Velikov 
> 
> With earlier patch we removed the overhead so now we can lift the helper
> into the header effectively folding it with __drm_object_put.
> 
> v2: drop struct_mutex references (Daniel)
> 
> Signed-off-by: Emil Velikov 
> Acked-by: Sam Ravnborg  (v1)
> Reviewed-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_gem.c  | 19 ---
>  drivers/gpu/drm/i915/gem/i915_gem_object.h |  2 +-
>  include/drm/drm_drv.h  |  2 --
>  include/drm/drm_gem.h  | 16 +++-
>  4 files changed, 4 insertions(+), 35 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index dab8763b2e73..599d5ff53b73 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -982,25 +982,6 @@ drm_gem_object_free(struct kref *kref)
>  }
>  EXPORT_SYMBOL(drm_gem_object_free);
>  
> -/**
> - * drm_gem_object_put_unlocked - drop a GEM buffer object reference
> - * @obj: GEM buffer object
> - *
> - * This releases a reference to @obj. Callers must not hold the
> - * _device.struct_mutex lock when calling this function.
> - *
> - * See also __drm_gem_object_put().
> - */
> -void
> -drm_gem_object_put_unlocked(struct drm_gem_object *obj)
> -{
> - if (!obj)
> - return;
> -
> - kref_put(>refcount, drm_gem_object_free);
> -}
> -EXPORT_SYMBOL(drm_gem_object_put_unlocked);
> -
>  /**
>   * drm_gem_object_put - release a GEM buffer object reference
>   * @obj: GEM buffer object
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h 
> b/drivers/gpu/drm/i915/gem/i915_gem_object.h
> index 2faa481cc18f..41351cbf31b5 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
> @@ -105,7 +105,7 @@ __attribute__((nonnull))
>  static inline void
>  i915_gem_object_put(struct drm_i915_gem_object *obj)
>  {
> - __drm_gem_object_put(>base);
> + drm_gem_object_put_unlocked(>base);
>  }
>  
>  #define assert_object_held(obj) dma_resv_assert_held((obj)->base.resv)
> diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> index e6eff508f687..bb924cddc09c 100644
> --- a/include/drm/drm_drv.h
> +++ b/include/drm/drm_drv.h
> @@ -332,8 +332,6 @@ struct drm_driver {
>*
>* This is deprecated and should not be used by new drivers. Use
>* _gem_object_funcs.free instead.
> -  * Compared to @gem_free_object this is not encumbered with
> -  * _device.struct_mutex legacy locking schemes.

Ah here's the two lines removed that I missed in the earlier patch. If you
feel like moving that hunk or not, r-b: me on both is ok.
-Daniel

>*/
>   void (*gem_free_object_unlocked) (struct drm_gem_object *obj);
>  
> diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
> index ec2d24a60a76..c3bdade093ae 100644
> --- a/include/drm/drm_gem.h
> +++ b/include/drm/drm_gem.h
> @@ -364,27 +364,17 @@ static inline void drm_gem_object_get(struct 
> drm_gem_object *obj)
>  }
>  
>  /**
> - * __drm_gem_object_put - raw function to release a GEM buffer object 
> reference
> + * drm_gem_object_put_unlocked - drop a GEM buffer object reference
>   * @obj: GEM buffer object
>   *
> - * This function is meant to be used by drivers which are not encumbered with
> - * _device.struct_mutex legacy locking and which are using the
> - * gem_free_object_unlocked callback. It avoids all the locking checks and
> - * locking overhead of drm_gem_object_put() and 
> drm_gem_object_put_unlocked().
> - *
> - * Drivers should never call this directly in their code. Instead they should
> - * wrap it up into a ``driver_gem_object_put(struct driver_gem_object *obj)``
> - * wrapper function, and use that. Shared code should never call this, to
> - * avoid breaking drivers by accident which still depend upon
> - * _device.struct_mutex locking.
> + * This releases a reference to @obj.
>   */
>  static inline void
> -__drm_gem_object_put(struct drm_gem_object *obj)
> +drm_gem_object_put_unlocked(struct drm_gem_object *obj)
>  {
>   kref_put(>refcount, drm_gem_object_free);
>  }
>  
> -void drm_gem_object_put_unlocked(struct drm_gem_object *obj);
>  void drm_gem_object_put(struct drm_gem_object *obj);
>  
>  int drm_gem_handle_create(struct drm_file *file_priv,
> -- 
> 2.25.1
> 
> ___
> 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 v2 09/38] drm: remove drm_driver::gem_free_object

2020-05-15 Thread Daniel Vetter
On Fri, May 15, 2020 at 10:50:49AM +0100, Emil Velikov wrote:
> From: Emil Velikov 
> 
> No drivers set the callback, so remove it all together.
> 
> Signed-off-by: Emil Velikov 
> Acked-by: Sam Ravnborg 
> Reviewed-by: Thomas Zimmermann 

If I've read your series correctly I think you've missed one kerneldoc
line for @gem_free_object_unlocked:

 * Compared to @gem_free_object this is not encumbered with
 * _device.struct_mutex legacy locking schemes.


With that also removed:

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/drm_gem.c | 22 +++---
>  include/drm/drm_drv.h |  8 
>  include/drm/drm_gem.h |  5 +++--
>  3 files changed, 6 insertions(+), 29 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 12fa121d0966..dab8763b2e73 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -975,15 +975,10 @@ drm_gem_object_free(struct kref *kref)
>   container_of(kref, struct drm_gem_object, refcount);
>   struct drm_device *dev = obj->dev;
>  
> - if (obj->funcs) {
> + if (obj->funcs)
>   obj->funcs->free(obj);
> - } else if (dev->driver->gem_free_object_unlocked) {
> + else if (dev->driver->gem_free_object_unlocked)
>   dev->driver->gem_free_object_unlocked(obj);
> - } else if (dev->driver->gem_free_object) {
> - WARN_ON(!mutex_is_locked(>struct_mutex));
> -
> - dev->driver->gem_free_object(obj);
> - }
>  }
>  EXPORT_SYMBOL(drm_gem_object_free);
>  
> @@ -999,21 +994,10 @@ EXPORT_SYMBOL(drm_gem_object_free);
>  void
>  drm_gem_object_put_unlocked(struct drm_gem_object *obj)
>  {
> - struct drm_device *dev;
> -
>   if (!obj)
>   return;
>  
> - dev = obj->dev;
> -
> - if (dev->driver->gem_free_object) {
> - might_lock(>struct_mutex);
> - if (kref_put_mutex(>refcount, drm_gem_object_free,
> - >struct_mutex))
> - mutex_unlock(>struct_mutex);
> - } else {
> - kref_put(>refcount, drm_gem_object_free);
> - }
> + kref_put(>refcount, drm_gem_object_free);
>  }
>  EXPORT_SYMBOL(drm_gem_object_put_unlocked);
>  
> diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> index 6d457652f199..e6eff508f687 100644
> --- a/include/drm/drm_drv.h
> +++ b/include/drm/drm_drv.h
> @@ -327,14 +327,6 @@ struct drm_driver {
>*/
>   void (*debugfs_init)(struct drm_minor *minor);
>  
> - /**
> -  * @gem_free_object: deconstructor for drm_gem_objects
> -  *
> -  * This is deprecated and should not be used by new drivers. Use
> -  * _gem_object_funcs.free instead.
> -  */
> - void (*gem_free_object) (struct drm_gem_object *obj);
> -
>   /**
>* @gem_free_object_unlocked: deconstructor for drm_gem_objects
>*
> diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
> index 0b375069cd48..ec2d24a60a76 100644
> --- a/include/drm/drm_gem.h
> +++ b/include/drm/drm_gem.h
> @@ -272,8 +272,9 @@ struct drm_gem_object {
>* attachment point for the device. This is invariant over the lifetime
>* of a gem object.
>*
> -  * The _driver.gem_free_object callback is responsible for cleaning
> -  * up the dma_buf attachment and references acquired at import time.
> +  * The _driver.gem_free_object_unlocked callback is responsible for
> +  * cleaning up the dma_buf attachment and references acquired at import
> +  * time.
>*
>* Note that the drm gem/prime core does not depend upon drivers setting
>* this field any more. So for drivers where this doesn't make sense
> -- 
> 2.25.1
> 
> ___
> 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


XDC 2020: Registration & Call for Proposals now open!

2020-05-15 Thread Szwichtenberg, Radoslaw
Hello!

Registration & Call for Proposals are now open for XDC 2020, which will
take place at the Gdańsk University of Technology in Gdańsk, Poland on 
September 16-18, 2020.

Thanks to LWN.net for hosting the website again this year!

https://xdc2020.x.org

As usual, the conference is free of charge and open to the general public. If 
you plan on attending, please make sure to register as early as possible! 
However, don't book any travel or hotel until the organization decides if we 
keep the conference as it is or there is any change. Please read this message 
on the website for more information:

https://xdc2020.x.org/event/9/page/78-covid-19

In order to register as attendee, you will therefore need to register via the 
XDC
website. However, as XDC is sharing the same Indico infrastructure as
LPC, if you previously registered on the LPC website
(linuxplumbersconference.org) or on the XDC 2019 website (xdc2019.x.org), then 
you already have an active account
and can use the same username & password to login!

https://xdc2020.x.org/event/9/registrations/7/

In addition to registration, the CfP is now open for talks, workshops
and demos at XDC 2020. While any serious proposal will be gratefully
considered, topics of interest to X.Org and freedesktop.org developers
are encouraged. The program focus is on new development, ongoing
challenges and anything else that will spark discussions among
attendees in the hallway track.

We are open to talks across all layers of the graphics stack, from the
kernel to desktop environments / graphical applications and about how
to make things better for the developers who build them. Head to the
CfP page to learn more: 

https://xdc2020.x.org/event/9/abstracts/

The deadline for submissions is Sunday, 5 July 2020.

Notice that the event may end up being postponed, converted to a fully online 
conference, or even a hybrid one (physical event + some remote talks). It 
depends on how COVID-19 situation evolves in the different countries and the 
restrictions we will have at that time.
Also, some people may decide to skip the physical conference to avoid any risk 
of infection. Because of that, please indicate in your talk submission if you 
prefer to give a remote talk in the case that XDC keeps being a physical event 
this year. Similarly, if you think that your talk makes no sense if XDC ends up 
being a fully-virtual conference, please indicate that in the notes of the talk 
submission.

If COVID-19 situation allows it, we are looking forward to seeing you in 
Gdańsk! If you have any questions, please send me an email to 
radoslaw.szwichtenb...@intel.com,  adding on CC the X.org board (board at 
foundation.x.org).

And don't forget, you can follow us on Twitter for all the latest
updates and to stay connected:

https://twitter.com/xdc2020

Best,

Radek


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


Re: [PATCH v12 00/14] In order to readout DP SDPs, refactors the handling of DP SDPs

2020-05-15 Thread Daniel Vetter
On Fri, May 15, 2020 at 04:13:18PM +0300, Jani Nikula wrote:
> On Fri, 15 May 2020, Ville Syrjälä  wrote:
> > On Thu, May 14, 2020 at 02:19:23PM +0300, Jani Nikula wrote:
> >> On Thu, 14 May 2020, Gwan-gyeong Mun  wrote:
> >> > In order to readout DP SDPs (Secondary Data Packet: DP HDR Metadata
> >> > Infoframe SDP, DP VSC SDP), it refactors handling DP SDPs codes.
> >> > It adds new compute routines for DP HDR Metadata Infoframe SDP
> >> > and DP VSC SDP. 
> >> > And new writing routines of DP SDPs (Secondary Data Packet) that uses
> >> > computed configs.
> >> > New reading routines of DP SDPs are added for readout.
> >> > It adds a logging function for DP VSC SDP.
> >> > When receiving video it is very useful to be able to log DP VSC SDP.
> >> > This greatly simplifies debugging.
> >> > In order to use a common VSC SDP Colorimetry calculating code on PSR,
> >> > it uses a new psr vsc sdp compute routine.
> >> 
> >> Pushed the series to drm-intel-next-queued with Daniel's irc ack for
> >> merging the two non-i915 patches that route too.
> >
> > fi-hsw-4770 now oopses at boot:
> 
> /o\
> 
> What did I miss? What part about the CI report did I overlook?

Participating hosts (48 -> 45)
--

  Additional (1): fi-kbl-7560u 
  Missing(4): fi-byt-clapper fi-byt-squawks fi-bsw-cyan fi-hsw-4200u


You kill machines at boot, CI won't tell you.

This is (or at least was) because the network is shitty enough that we
have more spurious failures because the ethernet went into the ether than
because of people having killed the machine with their patches for real.
Also it's hard to grab logs if the thing doesn't work at all, so cant give
you any more data than the above.

Yes this sucks :-/

Cheers, Daniel

> 
> BR,
> Jani.
> 
> 
> >
> > <1>[3.736903] BUG: kernel NULL pointer dereference, address: 
> > 
> > <1>[3.736916] #PF: supervisor read access in kernel mode
> > <1>[3.736916] #PF: error_code(0x) - not-present page
> > <6>[3.736917] PGD 0 P4D 0 
> > <4>[3.736919] Oops:  [#1] PREEMPT SMP PTI
> > <4>[3.736921] CPU: 0 PID: 363 Comm: systemd-udevd Not tainted 
> > 5.7.0-rc5-CI-CI_DRM_8485+ #1
> > <4>[3.736922] Hardware name: LENOVO 10AGS00601/SHARKBAY, BIOS FBKT34AUS 
> > 04/24/2013
> > <4>[3.736986] RIP: 0010:intel_psr_enabled+0x8/0x70 [i915]
> > <4>[3.736988] Code: 18 48 c7 c6 40 09 79 a0 e8 e3 e2 04 e1 0f b6 44 24 
> > 03 e9 f4 fd ff ff 90 66 2e 0f 1f 84 00 00 00 00 00 41 54 55 53 48 83 ec 08 
> > <48> 8b 9f d8 fe ff ff f6 83 5e 0d 00 00 20 74 09 80 bb 6c b6 00 00
> > <4>[3.737036] RSP: 0018:c947f8a0 EFLAGS: 00010286
> > <4>[3.737042] RAX: 0002 RBX: 8883ffd04000 RCX: 
> > 0001
> > <4>[3.737048] RDX: 0007 RSI: 8883ffd04000 RDI: 
> > 0128
> > <4>[3.737055] RBP: 888406afe200 R08: 000f R09: 
> > 0001
> > <4>[3.737061] R10:  R11:  R12: 
> > 
> > <4>[3.737068] R13: 8883f75d R14: 888406afe200 R15: 
> > 8883f75d0870
> > <4>[3.737075] FS:  7f71618f9680() GS:88840ec0() 
> > knlGS:
> > <4>[3.737082] CS:  0010 DS:  ES:  CR0: 80050033
> > <4>[3.737088] CR2:  CR3: 000402510002 CR4: 
> > 001606f0
> > <4>[3.737094] DR0:  DR1:  DR2: 
> > 
> > <4>[3.737101] DR3:  DR6: fffe0ff0 DR7: 
> > 0400
> > <4>[3.737107] Call Trace:
> > <4>[3.737175]  intel_read_dp_sdp+0x1a4/0x380 [i915]
> > <4>[3.737246]  hsw_crt_get_config+0x12/0x40 [i915]
> > <4>[3.737317]  intel_modeset_setup_hw_state+0x3b3/0x16a0 [i915]
> > ...
> 
> -- 
> Jani Nikula, Intel Open Source Graphics Center

-- 
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/2] drm/shmem: Use cached mappings by default

2020-05-15 Thread Daniel Vetter
On Fri, May 15, 2020 at 08:58:02AM +0200, Thomas Zimmermann wrote:
> Hi
> 
> Am 14.05.20 um 22:36 schrieb Rob Herring:
> > On Thu, May 14, 2020 at 7:40 AM Daniel Vetter  wrote:
> >>
> >> On Wed, May 13, 2020 at 05:03:11PM +0200, Thomas Zimmermann wrote:
> >>> SHMEM-buffer backing storage is allocated from system memory; which is
> >>> typically cachable. Currently, only virtio uses cachable mappings; udl
> >>> uses its own vmap/mmap implementation for cachable mappings. Other
> >>> drivers default to writecombine mappings.
> >>
> >> I'm pretty sure this breaks all these drivers. quick grep on a few
> >> functions says this is used by lima, panfrost, v3d. And they definitely
> >> need uncached/wc stuff afaiui. Or I'm completely missing something?
> > 
> 
> OK. I think I'll just make a patch that adds a .gem_create_object helper
> that sets the map_cached flag. So drivers can opt-in.
> 
> > Yes, that would be my guess. DMA is usually non-coherent on Arm.
> 
> Can one of you give me some pointer to what you're looking at? For
> example, I grepped for use of vmap within lima and only found [1].
> That's a for memcpy with no DMA involved. There's got to be something
> I'm missing.
> 
> Best regards
> Thomas
> 
> [1]
> https://cgit.freedesktop.org/drm/drm-tip/tree/drivers/gpu/drm/lima/lima_sched.c#n391

$ git grep drm_gem_shmem_mmap

We also need correct access from userspace, otherwise the gpu is going to
be sad.
-Daniel
> 
> > 
> > Rob
> > 
> 
> -- 
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Felix Imendörffer
> 




-- 
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: drm state readout helpers

2020-05-15 Thread Ville Syrjälä
On Fri, May 15, 2020 at 04:51:53PM +0300, Ville Syrjälä wrote:
> On Fri, May 15, 2020 at 03:36:13PM +0200, Daniel Vetter wrote:
> > Hi all,
> > 
> > Maxime seems to have a need for a bit more than what the current
> > drm_mode_config_reste can do, so here's a bunch of ideas inspired by
> > i915.
> > 
> > I think minimally what you need is a drm_atomic_state_helper_readout()
> > functions, which instead of resetting, allocates all the obj->state
> > pointers and fills them out. For that I think the simplest is to add
> > atomic_readout_state functions to crtc, connector and plane (if you
> > want to take over the firmware fb allocation too), which take as
> > parameter the object, and return the read-out state. Important, they
> > must _not_ touch anything persistent, otherwise the following stuff
> > here doesn't work.
> > 
> > Next up is the challenge of bridges and encoders. If the goal is to
> > properly shut down encoders/bridges, they also need their state. And
> > on most hw, they need a mix of the crtc and connector state, so best
> > to pass both of those (plus bridge state for bridges) to them. You can
> > do that if we assume that connector_helper_funcs->atomic_readout_state
> > sets the drm_connector_state->crtc pointer correctly. So the
> > drm_atomic_state_helper_readout function would first loop through
> > connectors and crtcs, and then loop through encoders and bridges to
> > fill in the gaps. Last you probably want to go through planes.
> > 
> > Now even more fun hw will have trouble and might need to look up
> > random other objects to set stuff, so we need a drm_atomic_state
> > structure to tie all these things together. For reasons that will
> > become obvious later on these read-out states should be stored in the
> > old_ state pointers.
> > 
> > Finally we need the actual helper which takes that read-out state and
> > smashes it into the real obj->state pointers, essentially a swap_state
> > but in reverse (since we need to write the old_ state pointers into
> > obj->state).
> > 
> > One thing i915 does, but I don't think is really needed: We read out
> > the connector->crtc routing as a first step, and once we have that, we
> > read out the connector/encoder/crtc steps. I think if you first read
> > out (and hence allocate) crtrc states, and then connector, and then
> > encoder/bridges that should work, and simplifies the flow a bit. So we
> > need another drm_atomic_state_helper_reset_to_readout or whatever,
> > which uses _readout and then does the reverse swap. Drivers call this
> > instead of drm_mode_config_reset.
> > 
> > Now the real issue: How do you make sure this actually works? Testing
> > with different fw configurations is usually impossible, you cant
> > easily tell the firmware to boot with different modes. Or at least
> > it's cumbersome since manual testing and lots of reboots. Waiting for
> > bug reports and then fixing them, while probably breaking something
> > else is a game of whack-a-mole.
> > 
> > So what i915 does is read out the hw state on every nonblocking
> > modeset (the additional time spent doesn't matter), but _only_ for the
> > objects touched in that modeset state. This is why you need to read
> > out into old_ state pointers, since after a blocking modeset those are
> > unused and available.
> 
> I have a feeling this old vs. new thing is still going to bite
> someone. But atm don't really have any sane alternative ideas.
> 
> Hmm, maybe we could at least tag the atomic_state as "readout only"
> for the duration of the actual readout and WARN/fail if anyone does
> drm_atomic_get_new_foo_state() and for_each_new/oldnew...() on it?

Oh, and I also had some fun with the readout overwriting
old_crtc_state->commit when I playing around with vblank workers.
I'm not even sure why that doesn't blow up currently as well. 

I think we should try to remove that confusing new_crtc_state->commit
vs. old_crtc_state->commit switcheroo. But I have a feeling that is
going to require quite a few changes since I guess it's the
old_crtc_state that currently gets plumbed into various places.

Another related annoyance is the old_foo_state->state vs.
new_foo_state->state which routinely trips up people with null ptr
derefs.

I guess trying to type up some cocci to plumb drm_atomic_state
everywhere might be a start...

-- 
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 01/44] drivers/base: Always release devres on device_del

2020-05-15 Thread Daniel Vetter
On Fri, May 15, 2020 at 02:55:38PM +0200, Greg Kroah-Hartman wrote:
> On Tue, Apr 28, 2020 at 03:15:12PM +0200, Daniel Vetter wrote:
> > On Mon, Apr 06, 2020 at 03:55:28PM +0200, Daniel Vetter wrote:
> > > On Mon, Apr 6, 2020 at 3:38 PM Greg Kroah-Hartman
> > >  wrote:
> > > >
> > > > On Mon, Apr 06, 2020 at 02:32:51PM +0200, Daniel Vetter wrote:
> > > > > On Fri, Apr 3, 2020 at 3:58 PM Daniel Vetter  
> > > > > wrote:
> > > > > >
> > > > > > In drm we've added nice drm_device (the main gpu driver thing, which
> > > > > > also represents the userspace interfaces and has everything else
> > > > > > dangling off it) init functions using devres, devm_drm_dev_init and
> > > > > > soon devm_drm_dev_alloc (this patch series adds that).
> > > > > >
> > > > > > A slight trouble is that drm_device itself holds a reference on the
> > > > > > struct device it's sitting on top (for sysfs links and dmesg debug 
> > > > > > and
> > > > > > lots of other things), so there's a reference loop. For real drivers
> > > > > > this is broken at remove/unplug time, where all devres resources are
> > > > > > released device_release_driver(), before the final device reference 
> > > > > > is
> > > > > > dropped. So far so good.
> > > > > >
> > > > > > There's 2 exceptions:
> > > > > > - drm/vkms|vgem: Virtual drivers for which we create a fake/virtual
> > > > > >   platform device to make them look more like normal devices to
> > > > > >   userspace. These aren't drivers in the driver model sense, we 
> > > > > > simple
> > > > > >   create a platform_device and register it.
> > > > > >
> > > > > > - drm/i915/selftests, where we create minimal mock devices, and 
> > > > > > again
> > > > > >   the selftests aren't proper drivers in the driver model sense.
> > > > > >
> > > > > > For these two cases the reference loop isn't broken, because devres 
> > > > > > is
> > > > > > only cleaned up when the last device reference is dropped. But 
> > > > > > that's
> > > > > > not happening, because the drm_device holds that last struct device
> > > > > > reference.
> > > > > >
> > > > > > Thus far this wasn't a problem since the above cases simply
> > > > > > hand-rolled their cleanup code. But I want to convert all drivers 
> > > > > > over
> > > > > > to the devm_ versions, hence it would be really nice if these
> > > > > > virtual/fake/mock uses-cases could also be managed with devres
> > > > > > cleanup.
> > > > > >
> > > > > > I see three possible approaches:
> > > > >
> > > > > Restarting this at the top level, because the discussion thus far just
> > > > > ended in a long "you're doing it wrong", despite that I think we're
> > > > > doing what v4l is doing (plus/minus that we can't do an exact matching
> > > > > handling in drm because our uapi has a lot more warts, which we can't
> > > > > change because no breaking userspace).
> > > > >
> > > > > So which one of the three below is the right approach?
> > > > >
> > > > > Aside, looking at the v4l solution I think there's also a confusion
> > > > > about struct device representing a char device (which v4l directly
> > > > > uses as its userspace interface refcounted thing, and which drm does
> > > > > _not_ directly). And a struct device embedded into something like
> > > > > platform_device or a virtual device, where a driver can bind to. My
> > > > > question here is about the former, I don't care how cdev struct device
> > > > > are cleaned up one bit. Now if other subsystems relies on the devres
> > > > > cleanup behaviour we currently have because of such cdev usage, then
> > > > > yeah first approach doesn't work (and I have a big surprised that use
> > > > > case, but hey would actually learn something).
> > > > >
> > > > > End of aside, since again I want to figure out which of the tree
> > > > > approaches it the right one. Not about how wrong one of them is,
> > > > > ignoring the other three I laid out. And maybe there's even more
> > > > > options for this.
> > > >
> > > > Sorry, been swamped with other things, give me a few days to get back to
> > > > this, I need to dig into how you all are dealing with the virtual
> > > > drivers.
> > > 
> > > Sure, no problem.
> > > 
> > > > Doing this in the middle of the merge window is a bit rough :)
> > > 
> > > Ah I always forget ... we freeze drm at -rc6, so merge window is
> > > actually my most relaxed time since everyone is busy and no one has
> > > time to report drm bugs :-)
> > 
> > Hi Greg,
> > 
> > Since -rc3 is out, had any to ponder this? Otherwise we'll be right back
> > in the next merge window ...
> 
> I owe you a response to this.  I'm going to try to carve out some time
> on Monday to do this, sorry for the delay :(

No worries, I got myself plenty occupied with other fun stuff in graphics
for now. And the part of the series which doesn't need this here is all
landed, so new drivers already look a notch cleaner in their code.

I'd have poked you earlier, but ofc very much appreciated if you can look
into this a 

Re: [PATCH v3 1/4] dma-buf: add support for virtio exported objects

2020-05-15 Thread Daniel Vetter
On Fri, May 15, 2020 at 02:07:06PM +0900, David Stevens wrote:
> On Thu, May 14, 2020 at 9:30 PM Daniel Vetter  wrote:
> > On Thu, May 14, 2020 at 05:19:40PM +0900, David Stevens wrote:
> > > Sorry for the duplicate reply, didn't notice this until now.
> > >
> > > > Just storing
> > > > the uuid should be doable (assuming this doesn't change during the
> > > > lifetime of the buffer), so no need for a callback.
> > >
> > > Directly storing the uuid doesn't work that well because of
> > > synchronization issues. The uuid needs to be shared between multiple
> > > virtio devices with independent command streams, so to prevent races
> > > between importing and exporting, the exporting driver can't share the
> > > uuid with other drivers until it knows that the device has finished
> > > registering the uuid. That requires a round trip to and then back from
> > > the device. Using a callback allows the latency from that round trip
> > > registration to be hidden.
> >
> > Uh, that means you actually do something and there's locking involved.
> > Makes stuff more complicated, invariant attributes are a lot easier
> > generally. Registering that uuid just always doesn't work, and blocking
> > when you're exporting?
> 
> Registering the id at creation and blocking in gem export is feasible,
> but it doesn't work well for systems with a centralized buffer
> allocator that doesn't support batch allocations (e.g. gralloc). In
> such a system, the round trip latency would almost certainly be
> included in the buffer allocation time. At least on the system I'm
> working on, I suspect that would add 10s of milliseconds of startup
> latency to video pipelines (although I haven't benchmarked the
> difference). Doing the blocking as late as possible means most or all
> of the latency can be hidden behind other pipeline setup work.
> 
> In terms of complexity, I think the synchronization would be basically
> the same in either approach, just in different locations. All it would
> do is alleviate the need for a callback to fetch the UUID.

Hm ok. I guess if we go with the older patch, where this all is a lot more
just code in virtio, doing an extra function to allocate the uuid sounds
fine. Then synchronization is entirely up to the virtio subsystem and not
a dma-buf problem (and hence not mine). You can use dma_resv_lock or so,
but no need to. But with callbacks potentially going both ways things
always get a bit interesting wrt locking - this is what makes peer2peer
dma-buf so painful right now. Hence I'd like to avoid that if needed, at
least at the dma-buf level. virtio code I don't mind what you do there :-)

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: drm state readout helpers

2020-05-15 Thread Ville Syrjälä
On Fri, May 15, 2020 at 03:36:13PM +0200, Daniel Vetter wrote:
> Hi all,
> 
> Maxime seems to have a need for a bit more than what the current
> drm_mode_config_reste can do, so here's a bunch of ideas inspired by
> i915.
> 
> I think minimally what you need is a drm_atomic_state_helper_readout()
> functions, which instead of resetting, allocates all the obj->state
> pointers and fills them out. For that I think the simplest is to add
> atomic_readout_state functions to crtc, connector and plane (if you
> want to take over the firmware fb allocation too), which take as
> parameter the object, and return the read-out state. Important, they
> must _not_ touch anything persistent, otherwise the following stuff
> here doesn't work.
> 
> Next up is the challenge of bridges and encoders. If the goal is to
> properly shut down encoders/bridges, they also need their state. And
> on most hw, they need a mix of the crtc and connector state, so best
> to pass both of those (plus bridge state for bridges) to them. You can
> do that if we assume that connector_helper_funcs->atomic_readout_state
> sets the drm_connector_state->crtc pointer correctly. So the
> drm_atomic_state_helper_readout function would first loop through
> connectors and crtcs, and then loop through encoders and bridges to
> fill in the gaps. Last you probably want to go through planes.
> 
> Now even more fun hw will have trouble and might need to look up
> random other objects to set stuff, so we need a drm_atomic_state
> structure to tie all these things together. For reasons that will
> become obvious later on these read-out states should be stored in the
> old_ state pointers.
> 
> Finally we need the actual helper which takes that read-out state and
> smashes it into the real obj->state pointers, essentially a swap_state
> but in reverse (since we need to write the old_ state pointers into
> obj->state).
> 
> One thing i915 does, but I don't think is really needed: We read out
> the connector->crtc routing as a first step, and once we have that, we
> read out the connector/encoder/crtc steps. I think if you first read
> out (and hence allocate) crtrc states, and then connector, and then
> encoder/bridges that should work, and simplifies the flow a bit. So we
> need another drm_atomic_state_helper_reset_to_readout or whatever,
> which uses _readout and then does the reverse swap. Drivers call this
> instead of drm_mode_config_reset.
> 
> Now the real issue: How do you make sure this actually works? Testing
> with different fw configurations is usually impossible, you cant
> easily tell the firmware to boot with different modes. Or at least
> it's cumbersome since manual testing and lots of reboots. Waiting for
> bug reports and then fixing them, while probably breaking something
> else is a game of whack-a-mole.
> 
> So what i915 does is read out the hw state on every nonblocking
> modeset (the additional time spent doesn't matter), but _only_ for the
> objects touched in that modeset state. This is why you need to read
> out into old_ state pointers, since after a blocking modeset those are
> unused and available.

I have a feeling this old vs. new thing is still going to bite
someone. But atm don't really have any sane alternative ideas.

Hmm, maybe we could at least tag the atomic_state as "readout only"
for the duration of the actual readout and WARN/fail if anyone does
drm_atomic_get_new_foo_state() and for_each_new/oldnew...() on it?

> Next item is to add a  atomic_compare_state
> function to crtc/connector and maybe bridges (i.e. all objects
> with state), which compares 2 state objects for equality. This needs
> to be a driver callback since each driver will only read out the state
> relevant from take-over from fw, not every possible feature, so
> there's lots you need to ignore. If any of these functions note a
> mismatch you splat with a warning and dump both the old and new states
> with the atomic_print driver hooks. I915 uses some #define so that
> these comparisons are one-liners (see PIPE_CONFIG_CHECK_X/I and so on,
> maybe we should have a few default ones with proper atomic naming, the
> names date back to the first somewhat-atomic modeset flow in i915).
> 
> So for validation we need a drm_atomic_state_helper_check which uses
> _readout, and then the compare functions plus debug printouts if it
> goes wrong. I'd wire that directly into the default
> drm_atomic_helper_commit function.
> 
> With these pieces you should have a state readout code that actually
> tends to work, and you can even test it (simply by doing a bunch of
> modesets). In i915 we have the _check code running unconditionally,
> blocking modesets are slow enough that it really doesn't matter.
> 
> One more thing on the implementation: Since this is all helpers all
> the hooks should probably be in the respective helper function tables.
> 
> Cheers, Daniel
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - 

Re: [PATCH] drm: drm_fourcc: add NV15, Q410, Q401 YUV formats

2020-05-15 Thread Brian Starkey
Hi Ben,

On Wed, May 06, 2020 at 03:41:26PM +0100, Ben Davis wrote:
> Hi all, any feedback on this patch?
> Thanks, Ben
> On Wed, Apr 22, 2020 at 12:13:49PM +0100, Ben Davis wrote:
> > DRM_FORMAT_NV15 is a 2 plane format suitable for linear and 16x16
> > block-linear memory layouts. The format is similar to P010 with 4:2:0
> > sub-sampling but has no padding between components. Instead, luminance
> > and chrominance samples are grouped into 4s so that each group is packed
> > into an integer number of bytes:
> > 
> >  = UVUV = 4 * 10 bits = 40 bits = 5 bytes
> > 
> > The '15' suffix refers to the optimum effective bits per pixel which is
> > achieved when the total number of luminance samples is a multiple of 8.
> > 
> > Q410 and Q401 are both 3 plane non-subsampled formats with 16 bits per
> > component, but only 10 bits are used and 6 are padded. 'Q' is chosen
> > as the first letter to denote 3 plane YUV444, (and is the next letter
> > along from P which is usually 2 plane).
> > 
> > Signed-off-by: Ben Davis 

The descriptions match my understanding of the formats and the
format_info struct, so feel free to add my r-b:

Reviewed-by: Brian Starkey 

Can anyone else pass comment on the approach and/or naming? I feel
like we should have some non-Arm eyes on this before we merge it.

Thanks,
-Brian

> > ---
> >  drivers/gpu/drm/drm_fourcc.c  | 12 
> >  include/uapi/drm/drm_fourcc.h | 24 
> >  2 files changed, 36 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> > index b234bfaeda06..0c0a65481afd 100644
> > --- a/drivers/gpu/drm/drm_fourcc.c
> > +++ b/drivers/gpu/drm/drm_fourcc.c
> > @@ -274,6 +274,18 @@ const struct drm_format_info *__drm_format_info(u32 
> > format)
> > { .format = DRM_FORMAT_YUV420_10BIT,.depth = 0,
> >   .num_planes = 1, .cpp = { 0, 0, 0 }, .hsub = 2, .vsub = 2,
> >   .is_yuv = true },
> > +   { .format = DRM_FORMAT_NV15,.depth = 0,
> > + .num_planes = 2, .char_per_block = { 5, 5, 0 },
> > + .block_w = { 4, 4, 0 }, .block_h = { 1, 1, 0 }, .hsub = 2,
> > + .vsub = 2, .is_yuv = true },
> > +   { .format = DRM_FORMAT_Q410,.depth = 0,
> > + .num_planes = 3, .char_per_block = { 2, 2, 2 },
> > + .block_w = { 1, 1, 1 }, .block_h = { 1, 1, 1 }, .hsub = 0,
> > + .vsub = 0, .is_yuv = true },
> > +   { .format = DRM_FORMAT_Q401,.depth = 0,
> > + .num_planes = 3, .char_per_block = { 2, 2, 2 },
> > + .block_w = { 1, 1, 1 }, .block_h = { 1, 1, 1 }, .hsub = 0,
> > + .vsub = 0, .is_yuv = true },
> > };
> >  
> > unsigned int i;
> > diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> > index 8bc0b31597d8..232b9ad3534d 100644
> > --- a/include/uapi/drm/drm_fourcc.h
> > +++ b/include/uapi/drm/drm_fourcc.h
> > @@ -236,6 +236,12 @@ extern "C" {
> >  #define DRM_FORMAT_NV61fourcc_code('N', 'V', '6', '1') /* 2x1 
> > subsampled Cb:Cr plane */
> >  #define DRM_FORMAT_NV24fourcc_code('N', 'V', '2', '4') /* 
> > non-subsampled Cr:Cb plane */
> >  #define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /* 
> > non-subsampled Cb:Cr plane */
> > +/*
> > + * 2 plane YCbCr
> > + * index 0 = Y plane, [39:0] Y3:Y2:Y1:Y0 little endian
> > + * index 1 = Cr:Cb plane, [39:0] Cr1:Cb1:Cr0:Cb0 little endian
> > + */
> > +#define DRM_FORMAT_NV15fourcc_code('N', 'V', '1', '5') /* 2x2 
> > subsampled Cr:Cb plane */
> >  
> >  /*
> >   * 2 plane YCbCr MSB aligned
> > @@ -265,6 +271,24 @@ extern "C" {
> >   */
> >  #define DRM_FORMAT_P016fourcc_code('P', '0', '1', '6') /* 2x2 
> > subsampled Cr:Cb plane 16 bits per channel */
> >  
> > +
> > +/* 3 plane non-subsampled (444) YCbCr
> > + * 16 bits per component, but only 10 bits are used and 6 bits are padded
> > + * index 0: Y plane, [15:0] Y:x [10:6] little endian
> > + * index 1: Cb plane, [15:0] Cb:x [10:6] little endian
> > + * index 2: Cr plane, [15:0] Cr:x [10:6] little endian
> > + */
> > +#define DRM_FORMAT_Q410fourcc_code('Q', '4', '1', '0')
> > +
> > +/* 3 plane non-subsampled (444) YCrCb
> > + * 16 bits per component, but only 10 bits are used and 6 bits are padded
> > + * index 0: Y plane, [15:0] Y:x [10:6] little endian
> > + * index 1: Cr plane, [15:0] Cr:x [10:6] little endian
> > + * index 2: Cb plane, [15:0] Cb:x [10:6] little endian
> > + */
> > +#define DRM_FORMAT_Q401fourcc_code('Q', '4', '0', '1')
> > +
> > +
> >  /*
> >   * 3 plane YCbCr
> >   * index 0: Y plane, [7:0] Y
> > -- 
> > 2.24.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


drm state readout helpers

2020-05-15 Thread Daniel Vetter
Hi all,

Maxime seems to have a need for a bit more than what the current
drm_mode_config_reste can do, so here's a bunch of ideas inspired by
i915.

I think minimally what you need is a drm_atomic_state_helper_readout()
functions, which instead of resetting, allocates all the obj->state
pointers and fills them out. For that I think the simplest is to add
atomic_readout_state functions to crtc, connector and plane (if you
want to take over the firmware fb allocation too), which take as
parameter the object, and return the read-out state. Important, they
must _not_ touch anything persistent, otherwise the following stuff
here doesn't work.

Next up is the challenge of bridges and encoders. If the goal is to
properly shut down encoders/bridges, they also need their state. And
on most hw, they need a mix of the crtc and connector state, so best
to pass both of those (plus bridge state for bridges) to them. You can
do that if we assume that connector_helper_funcs->atomic_readout_state
sets the drm_connector_state->crtc pointer correctly. So the
drm_atomic_state_helper_readout function would first loop through
connectors and crtcs, and then loop through encoders and bridges to
fill in the gaps. Last you probably want to go through planes.

Now even more fun hw will have trouble and might need to look up
random other objects to set stuff, so we need a drm_atomic_state
structure to tie all these things together. For reasons that will
become obvious later on these read-out states should be stored in the
old_ state pointers.

Finally we need the actual helper which takes that read-out state and
smashes it into the real obj->state pointers, essentially a swap_state
but in reverse (since we need to write the old_ state pointers into
obj->state).

One thing i915 does, but I don't think is really needed: We read out
the connector->crtc routing as a first step, and once we have that, we
read out the connector/encoder/crtc steps. I think if you first read
out (and hence allocate) crtrc states, and then connector, and then
encoder/bridges that should work, and simplifies the flow a bit. So we
need another drm_atomic_state_helper_reset_to_readout or whatever,
which uses _readout and then does the reverse swap. Drivers call this
instead of drm_mode_config_reset.

Now the real issue: How do you make sure this actually works? Testing
with different fw configurations is usually impossible, you cant
easily tell the firmware to boot with different modes. Or at least
it's cumbersome since manual testing and lots of reboots. Waiting for
bug reports and then fixing them, while probably breaking something
else is a game of whack-a-mole.

So what i915 does is read out the hw state on every nonblocking
modeset (the additional time spent doesn't matter), but _only_ for the
objects touched in that modeset state. This is why you need to read
out into old_ state pointers, since after a blocking modeset those are
unused and available. Next item is to add a  atomic_compare_state
function to crtc/connector and maybe bridges (i.e. all objects
with state), which compares 2 state objects for equality. This needs
to be a driver callback since each driver will only read out the state
relevant from take-over from fw, not every possible feature, so
there's lots you need to ignore. If any of these functions note a
mismatch you splat with a warning and dump both the old and new states
with the atomic_print driver hooks. I915 uses some #define so that
these comparisons are one-liners (see PIPE_CONFIG_CHECK_X/I and so on,
maybe we should have a few default ones with proper atomic naming, the
names date back to the first somewhat-atomic modeset flow in i915).

So for validation we need a drm_atomic_state_helper_check which uses
_readout, and then the compare functions plus debug printouts if it
goes wrong. I'd wire that directly into the default
drm_atomic_helper_commit function.

With these pieces you should have a state readout code that actually
tends to work, and you can even test it (simply by doing a bunch of
modesets). In i915 we have the _check code running unconditionally,
blocking modesets are slow enough that it really doesn't matter.

One more thing on the implementation: Since this is all helpers all
the hooks should probably be in the respective helper function tables.

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


Re: [PATCH v12 00/14] In order to readout DP SDPs, refactors the handling of DP SDPs

2020-05-15 Thread Jani Nikula
On Fri, 15 May 2020, Ville Syrjälä  wrote:
> On Thu, May 14, 2020 at 02:19:23PM +0300, Jani Nikula wrote:
>> On Thu, 14 May 2020, Gwan-gyeong Mun  wrote:
>> > In order to readout DP SDPs (Secondary Data Packet: DP HDR Metadata
>> > Infoframe SDP, DP VSC SDP), it refactors handling DP SDPs codes.
>> > It adds new compute routines for DP HDR Metadata Infoframe SDP
>> > and DP VSC SDP. 
>> > And new writing routines of DP SDPs (Secondary Data Packet) that uses
>> > computed configs.
>> > New reading routines of DP SDPs are added for readout.
>> > It adds a logging function for DP VSC SDP.
>> > When receiving video it is very useful to be able to log DP VSC SDP.
>> > This greatly simplifies debugging.
>> > In order to use a common VSC SDP Colorimetry calculating code on PSR,
>> > it uses a new psr vsc sdp compute routine.
>> 
>> Pushed the series to drm-intel-next-queued with Daniel's irc ack for
>> merging the two non-i915 patches that route too.
>
> fi-hsw-4770 now oopses at boot:

/o\

What did I miss? What part about the CI report did I overlook?

BR,
Jani.


>
> <1>[3.736903] BUG: kernel NULL pointer dereference, address: 
> 
> <1>[3.736916] #PF: supervisor read access in kernel mode
> <1>[3.736916] #PF: error_code(0x) - not-present page
> <6>[3.736917] PGD 0 P4D 0 
> <4>[3.736919] Oops:  [#1] PREEMPT SMP PTI
> <4>[3.736921] CPU: 0 PID: 363 Comm: systemd-udevd Not tainted 
> 5.7.0-rc5-CI-CI_DRM_8485+ #1
> <4>[3.736922] Hardware name: LENOVO 10AGS00601/SHARKBAY, BIOS FBKT34AUS 
> 04/24/2013
> <4>[3.736986] RIP: 0010:intel_psr_enabled+0x8/0x70 [i915]
> <4>[3.736988] Code: 18 48 c7 c6 40 09 79 a0 e8 e3 e2 04 e1 0f b6 44 24 03 
> e9 f4 fd ff ff 90 66 2e 0f 1f 84 00 00 00 00 00 41 54 55 53 48 83 ec 08 <48> 
> 8b 9f d8 fe ff ff f6 83 5e 0d 00 00 20 74 09 80 bb 6c b6 00 00
> <4>[3.737036] RSP: 0018:c947f8a0 EFLAGS: 00010286
> <4>[3.737042] RAX: 0002 RBX: 8883ffd04000 RCX: 
> 0001
> <4>[3.737048] RDX: 0007 RSI: 8883ffd04000 RDI: 
> 0128
> <4>[3.737055] RBP: 888406afe200 R08: 000f R09: 
> 0001
> <4>[3.737061] R10:  R11:  R12: 
> 
> <4>[3.737068] R13: 8883f75d R14: 888406afe200 R15: 
> 8883f75d0870
> <4>[3.737075] FS:  7f71618f9680() GS:88840ec0() 
> knlGS:
> <4>[3.737082] CS:  0010 DS:  ES:  CR0: 80050033
> <4>[3.737088] CR2:  CR3: 000402510002 CR4: 
> 001606f0
> <4>[3.737094] DR0:  DR1:  DR2: 
> 
> <4>[3.737101] DR3:  DR6: fffe0ff0 DR7: 
> 0400
> <4>[3.737107] Call Trace:
> <4>[3.737175]  intel_read_dp_sdp+0x1a4/0x380 [i915]
> <4>[3.737246]  hsw_crt_get_config+0x12/0x40 [i915]
> <4>[3.737317]  intel_modeset_setup_hw_state+0x3b3/0x16a0 [i915]
> ...

-- 
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[RFC PATCH 4/6] drm/bridge/nwl-dsi: Drop mux handling

2020-05-15 Thread Guido Günther
This will be handled via the mux-input-bridge.

Signed-off-by: Guido Günther 
---
 drivers/gpu/drm/bridge/Kconfig   |  1 -
 drivers/gpu/drm/bridge/nwl-dsi.c | 61 
 2 files changed, 62 deletions(-)

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 3886c0f41bdd..11444f841e35 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -78,7 +78,6 @@ config DRM_NWL_MIPI_DSI
select DRM_PANEL_BRIDGE
select GENERIC_PHY_MIPI_DPHY
select MFD_SYSCON
-   select MULTIPLEXER
select REGMAP_MMIO
help
  This enables the Northwest Logic MIPI DSI Host controller as
diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c b/drivers/gpu/drm/bridge/nwl-dsi.c
index b14d725bf609..8839f333f39c 100644
--- a/drivers/gpu/drm/bridge/nwl-dsi.c
+++ b/drivers/gpu/drm/bridge/nwl-dsi.c
@@ -12,7 +12,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -44,9 +43,6 @@ enum transfer_direction {
DSI_PACKET_RECEIVE,
 };
 
-#define NWL_DSI_ENDPOINT_LCDIF 0
-#define NWL_DSI_ENDPOINT_DCSS 1
-
 struct nwl_dsi_plat_clk_config {
const char *id;
struct clk *clk;
@@ -94,7 +90,6 @@ struct nwl_dsi {
struct reset_control *rst_esc;
struct reset_control *rst_dpi;
struct reset_control *rst_pclk;
-   struct mux_control *mux;
 
/* DSI clocks */
struct clk *phy_ref_clk;
@@ -1018,14 +1013,6 @@ static int nwl_dsi_parse_dt(struct nwl_dsi *dsi)
}
dsi->tx_esc_clk = clk;
 
-   dsi->mux = devm_mux_control_get(dsi->dev, NULL);
-   if (IS_ERR(dsi->mux)) {
-   ret = PTR_ERR(dsi->mux);
-   if (ret != -EPROBE_DEFER)
-   DRM_DEV_ERROR(dsi->dev, "Failed to get mux: %d\n", ret);
-   return ret;
-   }
-
base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(base))
return PTR_ERR(base);
@@ -1073,47 +1060,6 @@ static int nwl_dsi_parse_dt(struct nwl_dsi *dsi)
return 0;
 }
 
-static int nwl_dsi_select_input(struct nwl_dsi *dsi)
-{
-   struct device_node *remote;
-   u32 use_dcss = 1;
-   int ret;
-
-   remote = of_graph_get_remote_node(dsi->dev->of_node, 0,
- NWL_DSI_ENDPOINT_LCDIF);
-   if (remote) {
-   use_dcss = 0;
-   } else {
-   remote = of_graph_get_remote_node(dsi->dev->of_node, 0,
- NWL_DSI_ENDPOINT_DCSS);
-   if (!remote) {
-   DRM_DEV_ERROR(dsi->dev,
- "No valid input endpoint found\n");
-   return -EINVAL;
-   }
-   }
-
-   DRM_DEV_INFO(dsi->dev, "Using %s as input source\n",
-(use_dcss) ? "DCSS" : "LCDIF");
-   ret = mux_control_try_select(dsi->mux, use_dcss);
-   if (ret < 0)
-   DRM_DEV_ERROR(dsi->dev, "Failed to select input: %d\n", ret);
-
-   of_node_put(remote);
-   return ret;
-}
-
-static int nwl_dsi_deselect_input(struct nwl_dsi *dsi)
-{
-   int ret;
-
-   ret = mux_control_deselect(dsi->mux);
-   if (ret < 0)
-   DRM_DEV_ERROR(dsi->dev, "Failed to deselect input: %d\n", ret);
-
-   return ret;
-}
-
 static const struct drm_bridge_timings nwl_dsi_timings = {
.input_bus_flags = DRM_BUS_FLAG_DE_LOW,
 };
@@ -1175,12 +1121,6 @@ static int nwl_dsi_probe(struct platform_device *pdev)
dev_set_drvdata(dev, dsi);
pm_runtime_enable(dev);
 
-   ret = nwl_dsi_select_input(dsi);
-   if (ret < 0) {
-   mipi_dsi_host_unregister(>dsi_host);
-   return ret;
-   }
-
drm_bridge_add(>bridge);
return 0;
 }
@@ -1189,7 +1129,6 @@ static int nwl_dsi_remove(struct platform_device *pdev)
 {
struct nwl_dsi *dsi = platform_get_drvdata(pdev);
 
-   nwl_dsi_deselect_input(dsi);
mipi_dsi_host_unregister(>dsi_host);
drm_bridge_remove(>bridge);
pm_runtime_disable(>dev);
-- 
2.26.1

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


[RFC PATCH 2/6] drm/bridge: Add mux-input bridge

2020-05-15 Thread Guido Günther
This bridge allows to select the input source
via a mux controller. The input source is
determined via DT but it could become rutime
selectable in the future.

Signed-off-by: Guido Günther 
---
 drivers/gpu/drm/bridge/Kconfig |   9 ++
 drivers/gpu/drm/bridge/Makefile|   1 +
 drivers/gpu/drm/bridge/mux-input.c | 238 +
 3 files changed, 248 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/mux-input.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 04f876e985de..3886c0f41bdd 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -206,6 +206,15 @@ config DRM_TI_TPD12S015
  Texas Instruments TPD12S015 HDMI level shifter and ESD protection
  driver.
 
+config DRM_MUX_INPUT
+   tristate "Bridge to select a video input source"
+   depends on OF
+   depends on DRM_BRIDGE
+   select MULTIPLEXER
+   help
+ Select this option if you want to select the input source to
+ a DRM bridge or panel via a separate mux chip.
+
 source "drivers/gpu/drm/bridge/analogix/Kconfig"
 
 source "drivers/gpu/drm/bridge/adv7511/Kconfig"
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index d63d4b7e4347..9f3370ce7e07 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -4,6 +4,7 @@ obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o
 obj-$(CONFIG_DRM_DISPLAY_CONNECTOR) += display-connector.o
 obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o
 obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) += 
megachips-stdp-ge-b850v3-fw.o
+obj-$(CONFIG_DRM_MUX_INPUT) += mux-input.o
 obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
 obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
 obj-$(CONFIG_DRM_PARADE_PS8640) += parade-ps8640.o
diff --git a/drivers/gpu/drm/bridge/mux-input.c 
b/drivers/gpu/drm/bridge/mux-input.c
new file mode 100644
index ..24961d41ac30
--- /dev/null
+++ b/drivers/gpu/drm/bridge/mux-input.c
@@ -0,0 +1,238 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2020 Purism SPC
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#define DRV_NAME "mux-input-bridge"
+
+struct mux_input {
+   struct drm_bridge bridge;
+   struct drm_bridge *out;
+   struct device *dev;
+   struct mux_control *mux;
+   unsigned int n_inputs;
+   unsigned int input;
+   struct drm_bridge_timings timings;
+};
+
+static inline struct mux_input *bridge_to_mux_input(struct drm_bridge *bridge)
+{
+   return container_of(bridge, struct mux_input, bridge);
+}
+
+static void mux_input_bridge_disable(struct drm_bridge *bridge)
+{
+   struct mux_input *mux_input = bridge_to_mux_input(bridge);
+
+   pm_runtime_put(mux_input->dev);
+}
+
+static void mux_input_bridge_pre_enable(struct drm_bridge *bridge)
+{
+   struct mux_input *mux_input = bridge_to_mux_input(bridge);
+
+   pm_runtime_get(mux_input->dev);
+}
+
+static int mux_input_bridge_attach(struct drm_bridge *bridge,
+  enum drm_bridge_attach_flags flags)
+{
+   struct mux_input *mux_input = bridge_to_mux_input(bridge);
+   struct drm_bridge *panel_bridge;
+   struct drm_panel *panel;
+   struct device *dev;
+   struct device_node *remote;
+   int ret;
+
+   /* Only attach to the selected input */
+   remote = of_graph_get_remote_node(mux_input->dev->of_node,
+ mux_input->input,
+ 0);
+   if (!remote)
+   return -EINVAL;
+
+   if (bridge->dev) {
+   dev = bridge->dev->dev;
+   if (dev->of_node != remote) {
+   DRM_DEV_DEBUG(mux_input->dev,
+ "Not attaching to endpoint %s",
+ dev->of_node->name);
+   return -EINVAL;
+   }
+   }
+   of_node_put(remote);
+
+   ret = drm_of_find_panel_or_bridge(mux_input->dev->of_node,
+ mux_input->n_inputs - 1, 0, ,
+ _bridge);
+   if (ret)
+   return ret;
+
+   if (panel) {
+   panel_bridge = drm_panel_bridge_add(panel);
+   if (IS_ERR(panel_bridge))
+   return PTR_ERR(panel_bridge);
+   }
+   mux_input->out = panel_bridge;
+
+   if (!mux_input->out)
+   return -EPROBE_DEFER;
+
+   /* Bubble downstream bridge timings upwards */
+   memcpy(_input->timings, mux_input->out->timings,
+  sizeof(mux_input->timings));
+   mux_input->bridge.timings = _input->timings;
+   return drm_bridge_attach(bridge->encoder, mux_input->out, bridge,
+flags);
+}
+
+static void mux_input_bridge_detach(struct 

[RFC PATCH 1/6] dt-bindings: display/bridge: Add binding for input mux bridge

2020-05-15 Thread Guido Günther
The bridge allows to select the input source via a mux controller.

Signed-off-by: Guido Günther 
---
 .../display/bridge/mux-input-bridge.yaml  | 123 ++
 1 file changed, 123 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/mux-input-bridge.yaml

diff --git 
a/Documentation/devicetree/bindings/display/bridge/mux-input-bridge.yaml 
b/Documentation/devicetree/bindings/display/bridge/mux-input-bridge.yaml
new file mode 100644
index ..4029cf63ee5c
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/mux-input-bridge.yaml
@@ -0,0 +1,123 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/mux-input-bridge.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: DRM input source selection via multiplexer
+
+maintainers:
+  - Guido Gúnther 
+
+description: |
+  The input multiplexer bridge allows to select an input source
+  via an associated mux controller.
+
+properties:
+  compatible:
+const: mux-input-bridge
+
+  '#address-cells':
+const: 1
+
+  '#size-cells':
+const: 0
+
+  default-input:
+description: The default input to use
+
+  mux-controls:
+description:
+  mux controller node to use for operating the input mux
+
+  ports:
+type: object
+properties:
+  '#address-cells':
+const: 1
+  '#size-cells':
+const: 0
+
+patternProperties:
+  "^port@[0-9]+":
+type: object
+description:
+  At least three nodes containing endpoints connecting to the
+  pixel data inputs and outputs. The last port is always the
+  output port.
+
+properties:
+  reg:
+maxItems: 1
+
+  endpoint:
+description: sub-node describing the input
+type: object
+
+required:
+  - reg
+
+additionalProperties: false
+
+required:
+  - port@0
+  - port@1
+  - port@2
+
+additionalProperties: false
+
+required:
+  - '#address-cells'
+  - '#size-cells'
+  - mux-controls
+  - ports
+
+additionalProperties: false
+
+examples:
+ - |
+   #include 
+
+   mux: mux-controller {
+   compatible = "gpio-mux";
+   #mux-control-cells = <0>;
+
+   mux-gpios = < 15 GPIO_ACTIVE_HIGH>;
+   };
+
+   mipi-mux {
+   compatible = "mux-input-bridge";
+   default-input = <0>;
+   mux-controls = < 0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+
+   dpi_mux_from_lcdif: endpoint {
+   remote-endpoint = <_dpi_out>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+
+   dpi_mux_from_dccss: endpoint {
+   remote-endpoint = <_dpi_out>;
+   };
+   };
+
+   port@2 {
+   reg = <2>;
+
+   dpi_mux_out: endpoint {
+   remote-endpoint = <_dpi_in>;
+   };
+   };
+   };
+   };
-- 
2.26.1

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


[RFC PATCH 5/6] arm64: dts: imx8mq: Add NWL dsi controller

2020-05-15 Thread Guido Günther
Add a node for the Northwestlogic MIPI DSI IP core, "disabled" by
default.

Signed-off-by: Guido Günther 
---
 arch/arm64/boot/dts/freescale/imx8mq.dtsi | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi 
b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
index 0142f06ead12..6bbbf44e6be0 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
@@ -889,6 +889,37 @@ sec_jr2: jr@3000 {
};
};
 
+   mipi_dsi: mipi-dsi@30a0 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "fsl,imx8mq-nwl-dsi";
+   reg = <0x30a0 0x300>;
+   clocks = < IMX8MQ_CLK_DSI_CORE>,
+< IMX8MQ_CLK_DSI_AHB>,
+< IMX8MQ_CLK_DSI_IPG_DIV>,
+< IMX8MQ_CLK_DSI_PHY_REF>,
+< IMX8MQ_CLK_LCDIF_PIXEL>;
+   clock-names = "core", "rx_esc", "tx_esc", 
"phy_ref", "lcdif";
+   assigned-clocks = < IMX8MQ_CLK_DSI_AHB>,
+ < IMX8MQ_CLK_DSI_CORE>,
+ < IMX8MQ_CLK_DSI_IPG_DIV>;
+   assigned-clock-parents = < 
IMX8MQ_SYS1_PLL_80M>,
+< 
IMX8MQ_SYS1_PLL_266M>;
+   assigned-clock-rates = <8000>,
+  <26600>,
+  <2000>;
+   interrupts = ;
+   resets = < 
IMX8MQ_RESET_MIPI_DSI_RESET_BYTE_N>,
+< 
IMX8MQ_RESET_MIPI_DSI_DPI_RESET_N>,
+< 
IMX8MQ_RESET_MIPI_DSI_ESC_RESET_N>,
+< 
IMX8MQ_RESET_MIPI_DSI_PCLK_RESET_N>;
+   reset-names = "byte", "dpi", "esc", "pclk";
+   phys = <>;
+   phy-names = "dphy";
+   power-domains = <_mipi>;
+   status = "disabled";
+};
+
dphy: dphy@30a00300 {
compatible = "fsl,imx8mq-mipi-dphy";
reg = <0x30a00300 0x100>;
-- 
2.26.1

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


[RFC PATCH 3/6] dt-bindings: display/bridge/nwl-dsi: Drop mux handling

2020-05-15 Thread Guido Günther
No need to encode the SoC specifics in the bridge driver. For the
imx8mq we can use the mux-input-bridge.

Signed-off-by: Guido Günther 
---
 .../devicetree/bindings/display/bridge/nwl-dsi.yaml | 6 --
 1 file changed, 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml 
b/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
index 8aff2d68fc33..d2c2d4e19a25 100644
--- a/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
@@ -46,10 +46,6 @@ properties:
   - const: phy_ref
   - const: lcdif
 
-  mux-controls:
-description:
-  mux controller node to use for operating the input mux
-
   phys:
 maxItems: 1
 description:
@@ -151,7 +147,6 @@ required:
   - clocks
   - compatible
   - interrupts
-  - mux-controls
   - phy-names
   - phys
   - ports
@@ -180,7 +175,6 @@ examples:
< IMX8MQ_CLK_LCDIF_PIXEL>;
   clock-names = "core", "rx_esc", "tx_esc", "phy_ref", "lcdif";
   interrupts = ;
-  mux-controls = < 0>;
   power-domains = <_mipi>;
   resets = < IMX8MQ_RESET_MIPI_DSI_RESET_BYTE_N>,
< IMX8MQ_RESET_MIPI_DSI_DPI_RESET_N>,
-- 
2.26.1

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


[RFC PATCH 0/6] drm/bridge: Add mux input selection bridge

2020-05-15 Thread Guido Günther
This bridge driver allows to select the input to a downstream bridge (or panel)
via device tree.

It can be useful to separate the pixel source selection from the actual bridge
processing the pixel data. E.g. NXP's imx8mq has two display controllers. Both
can feed the pixel data to the NWL DSI IP core. The input selection is done via
a separate mux register elsewhere on the chip, so separating this out avoids SoC
specific code in such drivers.

The current implementation allows to select the input source via device tree.
The long term goal is to allow to switch the input source at run time. This
can be useful to e.g. use the less power hungry display controller for normal
operation but switch to a the other display controller when running full screen
games (since it can detile textures more efficiently).

This was initially suggested by Laurent Pinchart¹. It is similar in spirit to
the video-mux in the media subsystem but for DRM bridges.

Besides the actual driver this series includes the necessary bits to demo the
usage for the Librem5 devkit.

The series is based on linux-next as of next-20200512.

¹ 
https://lore.kernel.org/dri-devel/20200415021908.gh19...@pendragon.ideasonboard.com/

Guido Günther (6):
  dt-bindings: display/bridge: Add binding for input mux bridge
  drm/bridge: Add mux-input bridge
  dt-bindings: display/bridge/nwl-dsi: Drop mux handling
  drm/bridge/nwl-dsi: Drop mux handling
  arm64: dts: imx8mq: Add NWL dsi controller
  arm64: dts: imx8mq-librem5-devkit: Enable MIPI DSI panel

 .../display/bridge/mux-input-bridge.yaml  | 123 +
 .../bindings/display/bridge/nwl-dsi.yaml  |   6 -
 .../dts/freescale/imx8mq-librem5-devkit.dts   |  81 ++
 arch/arm64/boot/dts/freescale/imx8mq.dtsi |  31 +++
 drivers/gpu/drm/bridge/Kconfig|  10 +-
 drivers/gpu/drm/bridge/Makefile   |   1 +
 drivers/gpu/drm/bridge/mux-input.c| 238 ++
 drivers/gpu/drm/bridge/nwl-dsi.c  |  61 -
 8 files changed, 483 insertions(+), 68 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/mux-input-bridge.yaml
 create mode 100644 drivers/gpu/drm/bridge/mux-input.c

-- 
2.26.1

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


[RFC PATCH 6/6] arm64: dts: imx8mq-librem5-devkit: Enable MIPI DSI panel

2020-05-15 Thread Guido Günther
Enable MIPI LCD panel output by adding nodes for the NWL DSI host
controller, the mux-input-bridge, the Rocktech panel and the eLCDIF
display controller.

Signed-off-by: Guido Günther 
---
 .../dts/freescale/imx8mq-librem5-devkit.dts   | 81 +++
 1 file changed, 81 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8mq-librem5-devkit.dts 
b/arch/arm64/boot/dts/freescale/imx8mq-librem5-devkit.dts
index 7fc31c71a626..d98f9b8dede8 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq-librem5-devkit.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mq-librem5-devkit.dts
@@ -841,6 +841,87 @@ MX8MQ_IOMUXC_NAND_DATA03_GPIO3_IO9 0x19 /* WWAN_RESET */
};
 };
 
+ {
+   status = "okay";
+
+   port@0 {
+   lcdif_dpi_out: endpoint {
+   remote-endpoint = <_mux_from_lcdif>;
+   };
+   };
+};
+
+_gpr {
+   mipi_mux: mipi-mux {
+   compatible = "mux-input-bridge";
+   mux-controls = < 0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "okay";
+   default-input = <0>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+
+   dpi_mux_from_lcdif: endpoint {
+   remote-endpoint = <_dpi_out>;
+   };
+   };
+
+   port@1 { /* dcss */
+   reg = <1>;
+   };
+
+   port@2 {
+   reg = <2>;
+   dpi_mux_out: endpoint {
+   remote-endpoint = <_dpi_in>;
+   };
+
+   };
+   };
+   };
+};
+
+_dsi {
+   status = "okay";
+   panel@0 {
+   compatible = "rocktech,jh057n00900";
+   reg = <0>;
+   backlight = <_dsi>;
+   reset-gpios = < 13 GPIO_ACTIVE_LOW>;
+   vcc-supply = <_2v8_p>;
+   iovcc-supply = <_1v8_p>;
+   port@0 {
+   panel_in: endpoint {
+   remote-endpoint = <_dsi_out>;
+   };
+   };
+   };
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   nwl_dpi_in: endpoint {
+   remote-endpoint = <_mux_out>;
+   };
+   };
+   port@1 {
+   reg = <1>;
+   nwl_dsi_out: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+};
+
 _gpu {
power-supply = <_reg>;
 };
-- 
2.26.1

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


Re: [PATCH v12 00/14] In order to readout DP SDPs, refactors the handling of DP SDPs

2020-05-15 Thread Ville Syrjälä
On Thu, May 14, 2020 at 02:19:23PM +0300, Jani Nikula wrote:
> On Thu, 14 May 2020, Gwan-gyeong Mun  wrote:
> > In order to readout DP SDPs (Secondary Data Packet: DP HDR Metadata
> > Infoframe SDP, DP VSC SDP), it refactors handling DP SDPs codes.
> > It adds new compute routines for DP HDR Metadata Infoframe SDP
> > and DP VSC SDP. 
> > And new writing routines of DP SDPs (Secondary Data Packet) that uses
> > computed configs.
> > New reading routines of DP SDPs are added for readout.
> > It adds a logging function for DP VSC SDP.
> > When receiving video it is very useful to be able to log DP VSC SDP.
> > This greatly simplifies debugging.
> > In order to use a common VSC SDP Colorimetry calculating code on PSR,
> > it uses a new psr vsc sdp compute routine.
> 
> Pushed the series to drm-intel-next-queued with Daniel's irc ack for
> merging the two non-i915 patches that route too.

fi-hsw-4770 now oopses at boot:

<1>[3.736903] BUG: kernel NULL pointer dereference, address: 

<1>[3.736916] #PF: supervisor read access in kernel mode
<1>[3.736916] #PF: error_code(0x) - not-present page
<6>[3.736917] PGD 0 P4D 0 
<4>[3.736919] Oops:  [#1] PREEMPT SMP PTI
<4>[3.736921] CPU: 0 PID: 363 Comm: systemd-udevd Not tainted 
5.7.0-rc5-CI-CI_DRM_8485+ #1
<4>[3.736922] Hardware name: LENOVO 10AGS00601/SHARKBAY, BIOS FBKT34AUS 
04/24/2013
<4>[3.736986] RIP: 0010:intel_psr_enabled+0x8/0x70 [i915]
<4>[3.736988] Code: 18 48 c7 c6 40 09 79 a0 e8 e3 e2 04 e1 0f b6 44 24 03 
e9 f4 fd ff ff 90 66 2e 0f 1f 84 00 00 00 00 00 41 54 55 53 48 83 ec 08 <48> 8b 
9f d8 fe ff ff f6 83 5e 0d 00 00 20 74 09 80 bb 6c b6 00 00
<4>[3.737036] RSP: 0018:c947f8a0 EFLAGS: 00010286
<4>[3.737042] RAX: 0002 RBX: 8883ffd04000 RCX: 
0001
<4>[3.737048] RDX: 0007 RSI: 8883ffd04000 RDI: 
0128
<4>[3.737055] RBP: 888406afe200 R08: 000f R09: 
0001
<4>[3.737061] R10:  R11:  R12: 

<4>[3.737068] R13: 8883f75d R14: 888406afe200 R15: 
8883f75d0870
<4>[3.737075] FS:  7f71618f9680() GS:88840ec0() 
knlGS:
<4>[3.737082] CS:  0010 DS:  ES:  CR0: 80050033
<4>[3.737088] CR2:  CR3: 000402510002 CR4: 
001606f0
<4>[3.737094] DR0:  DR1:  DR2: 

<4>[3.737101] DR3:  DR6: fffe0ff0 DR7: 
0400
<4>[3.737107] Call Trace:
<4>[3.737175]  intel_read_dp_sdp+0x1a4/0x380 [i915]
<4>[3.737246]  hsw_crt_get_config+0x12/0x40 [i915]
<4>[3.737317]  intel_modeset_setup_hw_state+0x3b3/0x16a0 [i915]
...

-- 
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: ✓ Fi.CI.IGT: success for drm/dp_mst: Fix timeout handling of MST down messages

2020-05-15 Thread Imre Deak
On Wed, May 13, 2020 at 02:40:29PM +, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/dp_mst: Fix timeout handling of MST down messages
> URL   : https://patchwork.freedesktop.org/series/77216/
> State : success

Patch pushed to drm-misc-next, thanks for the review.

> 
> == Summary ==
> 
> CI Bug Log - changes from CI_DRM_8472_full -> Patchwork_17643_full
> 
> 
> Summary
> ---
> 
>   **SUCCESS**
> 
>   No regressions found.
> 
>   
> 
> New tests
> -
> 
>   New tests have been introduced between CI_DRM_8472_full and 
> Patchwork_17643_full:
> 
> ### New IGT tests (123) ###
> 
>   * igt@kms_cursor_crc@pipe-a-cursor-128x128-offscreen:
> - Statuses : 7 pass(s)
> - Exec time: [2.97, 4.97] s
> 
>   * igt@kms_cursor_crc@pipe-a-cursor-128x128-onscreen:
> - Statuses : 8 pass(s)
> - Exec time: [1.73, 2.92] s
> 
>   * igt@kms_cursor_crc@pipe-a-cursor-128x128-random:
> - Statuses : 8 pass(s)
> - Exec time: [2.74, 4.76] s
> 
>   * igt@kms_cursor_crc@pipe-a-cursor-128x128-rapid-movement:
> - Statuses : 8 pass(s)
> - Exec time: [0.19, 1.11] s
> 
>   * igt@kms_cursor_crc@pipe-a-cursor-128x128-sliding:
> - Statuses : 8 pass(s)
> - Exec time: [2.59, 4.28] s
> 
>   * igt@kms_cursor_crc@pipe-a-cursor-128x42-offscreen:
> - Statuses : 7 pass(s) 1 skip(s)
> - Exec time: [0.0, 4.96] s
> 
>   * igt@kms_cursor_crc@pipe-a-cursor-128x42-onscreen:
> - Statuses : 7 pass(s) 1 skip(s)
> - Exec time: [0.0, 2.89] s
> 
>   * igt@kms_cursor_crc@pipe-a-cursor-128x42-random:
> - Statuses : 7 pass(s) 1 skip(s)
> - Exec time: [0.0, 4.46] s
> 
>   * igt@kms_cursor_crc@pipe-a-cursor-128x42-sliding:
> - Statuses : 7 pass(s) 1 skip(s)
> - Exec time: [0.0, 4.28] s
> 
>   * igt@kms_cursor_crc@pipe-a-cursor-256x256-offscreen:
> - Statuses : 8 pass(s)
> - Exec time: [2.97, 4.94] s
> 
>   * igt@kms_cursor_crc@pipe-a-cursor-256x256-onscreen:
> - Statuses : 8 pass(s)
> - Exec time: [1.73, 2.90] s
> 
>   * igt@kms_cursor_crc@pipe-a-cursor-256x256-random:
> - Statuses : 1 fail(s) 7 pass(s)
> - Exec time: [0.44, 4.41] s
> 
>   * igt@kms_cursor_crc@pipe-a-cursor-256x256-rapid-movement:
> - Statuses : 7 pass(s)
> - Exec time: [0.29, 1.14] s
> 
>   * igt@kms_cursor_crc@pipe-a-cursor-256x256-sliding:
> - Statuses : 8 pass(s)
> - Exec time: [2.61, 4.30] s
> 
>   * igt@kms_cursor_crc@pipe-a-cursor-256x85-offscreen:
> - Statuses : 1 fail(s) 6 pass(s) 1 skip(s)
> - Exec time: [0.0, 4.97] s
> 
>   * igt@kms_cursor_crc@pipe-a-cursor-256x85-onscreen:
> - Statuses : 7 pass(s) 1 skip(s)
> - Exec time: [0.0, 2.87] s
> 
>   * igt@kms_cursor_crc@pipe-a-cursor-256x85-random:
> - Statuses : 7 pass(s) 1 skip(s)
> - Exec time: [0.0, 4.43] s
> 
>   * igt@kms_cursor_crc@pipe-a-cursor-256x85-sliding:
> - Statuses : 7 pass(s) 1 skip(s)
> - Exec time: [0.0, 4.26] s
> 
>   * igt@kms_cursor_crc@pipe-a-cursor-512x170-offscreen:
> - Statuses : 8 skip(s)
> - Exec time: [0.0] s
> 
>   * igt@kms_cursor_crc@pipe-a-cursor-512x170-onscreen:
> - Statuses : 8 skip(s)
> - Exec time: [0.0] s
> 
>   * igt@kms_cursor_crc@pipe-a-cursor-512x170-random:
> - Statuses : 8 skip(s)
> - Exec time: [0.0] s
> 
>   * igt@kms_cursor_crc@pipe-a-cursor-512x170-sliding:
> - Statuses : 8 skip(s)
> - Exec time: [0.0] s
> 
>   * igt@kms_cursor_crc@pipe-a-cursor-512x512-offscreen:
> - Statuses : 8 skip(s)
> - Exec time: [0.0] s
> 
>   * igt@kms_cursor_crc@pipe-a-cursor-512x512-onscreen:
> - Statuses : 8 skip(s)
> - Exec time: [0.0] s
> 
>   * igt@kms_cursor_crc@pipe-a-cursor-512x512-random:
> - Statuses : 8 skip(s)
> - Exec time: [0.0] s
> 
>   * igt@kms_cursor_crc@pipe-a-cursor-512x512-rapid-movement:
> - Statuses : 8 skip(s)
> - Exec time: [0.0] s
> 
>   * igt@kms_cursor_crc@pipe-a-cursor-512x512-sliding:
> - Statuses : 8 skip(s)
> - Exec time: [0.0] s
> 
>   * igt@kms_cursor_crc@pipe-a-cursor-64x21-offscreen:
> - Statuses : 7 pass(s) 1 skip(s)
> - Exec time: [0.0, 4.96] s
> 
>   * igt@kms_cursor_crc@pipe-a-cursor-64x21-onscreen:
> - Statuses : 7 pass(s) 1 skip(s)
> - Exec time: [0.0, 2.89] s
> 
>   * igt@kms_cursor_crc@pipe-a-cursor-64x21-random:
> - Statuses : 1 fail(s) 6 pass(s) 1 skip(s)
> - Exec time: [0.0, 4.45] s
> 
>   * igt@kms_cursor_crc@pipe-a-cursor-64x21-sliding:
> - Statuses : 7 pass(s) 1 skip(s)
> - Exec time: [0.0, 4.74] s
> 
>   * igt@kms_cursor_crc@pipe-a-cursor-64x64-offscreen:
> - Statuses : 8 pass(s)
> - Exec time: [2.95, 4.96] s
> 
>   * igt@kms_cursor_crc@pipe-a-cursor-64x64-onscreen:
> - Statuses : 8 pass(s)
> - Exec time: [1.76, 3.29] s
> 
>   * igt@kms_cursor_crc@pipe-a-cursor-64x64-random:
> - Statuses : 8 pass(s)
> - Exec time: [2.69, 4.51] s
> 
>   * igt@kms_cursor_crc@pipe-a-cursor-64x64-rapid-movement:
> - Statuses : 8 pass(s)
> - 

Re: [PATCH 01/44] drivers/base: Always release devres on device_del

2020-05-15 Thread Greg Kroah-Hartman
On Tue, Apr 28, 2020 at 03:15:12PM +0200, Daniel Vetter wrote:
> On Mon, Apr 06, 2020 at 03:55:28PM +0200, Daniel Vetter wrote:
> > On Mon, Apr 6, 2020 at 3:38 PM Greg Kroah-Hartman
> >  wrote:
> > >
> > > On Mon, Apr 06, 2020 at 02:32:51PM +0200, Daniel Vetter wrote:
> > > > On Fri, Apr 3, 2020 at 3:58 PM Daniel Vetter  
> > > > wrote:
> > > > >
> > > > > In drm we've added nice drm_device (the main gpu driver thing, which
> > > > > also represents the userspace interfaces and has everything else
> > > > > dangling off it) init functions using devres, devm_drm_dev_init and
> > > > > soon devm_drm_dev_alloc (this patch series adds that).
> > > > >
> > > > > A slight trouble is that drm_device itself holds a reference on the
> > > > > struct device it's sitting on top (for sysfs links and dmesg debug and
> > > > > lots of other things), so there's a reference loop. For real drivers
> > > > > this is broken at remove/unplug time, where all devres resources are
> > > > > released device_release_driver(), before the final device reference is
> > > > > dropped. So far so good.
> > > > >
> > > > > There's 2 exceptions:
> > > > > - drm/vkms|vgem: Virtual drivers for which we create a fake/virtual
> > > > >   platform device to make them look more like normal devices to
> > > > >   userspace. These aren't drivers in the driver model sense, we simple
> > > > >   create a platform_device and register it.
> > > > >
> > > > > - drm/i915/selftests, where we create minimal mock devices, and again
> > > > >   the selftests aren't proper drivers in the driver model sense.
> > > > >
> > > > > For these two cases the reference loop isn't broken, because devres is
> > > > > only cleaned up when the last device reference is dropped. But that's
> > > > > not happening, because the drm_device holds that last struct device
> > > > > reference.
> > > > >
> > > > > Thus far this wasn't a problem since the above cases simply
> > > > > hand-rolled their cleanup code. But I want to convert all drivers over
> > > > > to the devm_ versions, hence it would be really nice if these
> > > > > virtual/fake/mock uses-cases could also be managed with devres
> > > > > cleanup.
> > > > >
> > > > > I see three possible approaches:
> > > >
> > > > Restarting this at the top level, because the discussion thus far just
> > > > ended in a long "you're doing it wrong", despite that I think we're
> > > > doing what v4l is doing (plus/minus that we can't do an exact matching
> > > > handling in drm because our uapi has a lot more warts, which we can't
> > > > change because no breaking userspace).
> > > >
> > > > So which one of the three below is the right approach?
> > > >
> > > > Aside, looking at the v4l solution I think there's also a confusion
> > > > about struct device representing a char device (which v4l directly
> > > > uses as its userspace interface refcounted thing, and which drm does
> > > > _not_ directly). And a struct device embedded into something like
> > > > platform_device or a virtual device, where a driver can bind to. My
> > > > question here is about the former, I don't care how cdev struct device
> > > > are cleaned up one bit. Now if other subsystems relies on the devres
> > > > cleanup behaviour we currently have because of such cdev usage, then
> > > > yeah first approach doesn't work (and I have a big surprised that use
> > > > case, but hey would actually learn something).
> > > >
> > > > End of aside, since again I want to figure out which of the tree
> > > > approaches it the right one. Not about how wrong one of them is,
> > > > ignoring the other three I laid out. And maybe there's even more
> > > > options for this.
> > >
> > > Sorry, been swamped with other things, give me a few days to get back to
> > > this, I need to dig into how you all are dealing with the virtual
> > > drivers.
> > 
> > Sure, no problem.
> > 
> > > Doing this in the middle of the merge window is a bit rough :)
> > 
> > Ah I always forget ... we freeze drm at -rc6, so merge window is
> > actually my most relaxed time since everyone is busy and no one has
> > time to report drm bugs :-)
> 
> Hi Greg,
> 
> Since -rc3 is out, had any to ponder this? Otherwise we'll be right back
> in the next merge window ...

I owe you a response to this.  I'm going to try to carve out some time
on Monday to do this, sorry for the delay :(

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


Re: [PATCH 01/11] tty/sysrq: alpha: export and use __sysrq_get_key_op()

2020-05-15 Thread Greg Kroah-Hartman
On Wed, May 13, 2020 at 10:43:41PM +0100, Emil Velikov wrote:
> Export a pointer to the sysrq_get_key_op(). This way we can cleanly
> unregister it, instead of the current solutions of modifuing it inplace.
> 
> Since __sysrq_get_key_op() is no longer used externally, let's make it
> a static function.
> 
> This patch will allow us to limit access to each and every sysrq op and
> constify the sysrq handling.
> 
> Cc: Greg Kroah-Hartman 
> Cc: Jiri Slaby 
> Cc: linux-ker...@vger.kernel.org
> Cc: Richard Henderson 
> Cc: Ivan Kokshaysky 
> Cc: Matt Turner 
> Cc: linux-al...@vger.kernel.org
> Signed-off-by: Emil Velikov 
> ---
> Please keep me in the CC list, as I'm not subscribed to the list.
> 
> IMHO it would be better if this gets merged this via the tty tree.

All now taken, thanks!

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


Re: [PATCH v2 27/38] drm/panfrost: remove _unlocked suffix in drm_object_put_unlocked

2020-05-15 Thread Steven Price

On 15/05/2020 10:51, Emil Velikov wrote:

From: Emil Velikov 

Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.

Just drop the suffix. It makes the API cleaner.

Done via the following script:

__from=drm_gem_object_put_unlocked
__to=drm_gem_object_put
for __file in $(git grep --name-only $__from); do
   sed -i  "s/$__from/$__to/g" $__file;
done

Cc: Rob Herring 
Cc: Tomeu Vizoso 
Cc: Steven Price 
Signed-off-by: Emil Velikov 
Acked-by: Sam Ravnborg 


NIT: The subject is wrong: s/drm_object_put/drm_gem_object_put/

With that fixed:

Reviewed-by: Steven Price 

Steve


---
  drivers/gpu/drm/panfrost/panfrost_drv.c | 10 +-
  drivers/gpu/drm/panfrost/panfrost_gem.c |  4 ++--
  drivers/gpu/drm/panfrost/panfrost_job.c |  2 +-
  drivers/gpu/drm/panfrost/panfrost_mmu.c |  2 +-
  drivers/gpu/drm/panfrost/panfrost_perfcnt.c |  4 ++--
  5 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c 
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index 882fecc33fdb..ada51df9a7a3 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -99,7 +99,7 @@ static int panfrost_ioctl_create_bo(struct drm_device *dev, 
void *data,
  
  	mapping = panfrost_gem_mapping_get(bo, priv);

if (!mapping) {
-   drm_gem_object_put_unlocked(>base.base);
+   drm_gem_object_put(>base.base);
return -EINVAL;
}
  
@@ -317,7 +317,7 @@ panfrost_ioctl_wait_bo(struct drm_device *dev, void *data,

if (!ret)
ret = timeout ? -ETIMEDOUT : -EBUSY;
  
-	drm_gem_object_put_unlocked(gem_obj);

+   drm_gem_object_put(gem_obj);
  
  	return ret;

  }
@@ -351,7 +351,7 @@ static int panfrost_ioctl_mmap_bo(struct drm_device *dev, 
void *data,
args->offset = drm_vma_node_offset_addr(_obj->vma_node);
  
  out:

-   drm_gem_object_put_unlocked(gem_obj);
+   drm_gem_object_put(gem_obj);
return ret;
  }
  
@@ -372,7 +372,7 @@ static int panfrost_ioctl_get_bo_offset(struct drm_device *dev, void *data,

bo = to_panfrost_bo(gem_obj);
  
  	mapping = panfrost_gem_mapping_get(bo, priv);

-   drm_gem_object_put_unlocked(gem_obj);
+   drm_gem_object_put(gem_obj);
  
  	if (!mapping)

return -EINVAL;
@@ -438,7 +438,7 @@ static int panfrost_ioctl_madvise(struct drm_device *dev, 
void *data,
mutex_unlock(>mappings.lock);
mutex_unlock(>shrinker_lock);
  
-	drm_gem_object_put_unlocked(gem_obj);

+   drm_gem_object_put(gem_obj);
return ret;
  }
  
diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.c b/drivers/gpu/drm/panfrost/panfrost_gem.c

index 17b654e1eb94..ac5d0aa80276 100644
--- a/drivers/gpu/drm/panfrost/panfrost_gem.c
+++ b/drivers/gpu/drm/panfrost/panfrost_gem.c
@@ -93,7 +93,7 @@ static void panfrost_gem_mapping_release(struct kref *kref)
mapping = container_of(kref, struct panfrost_gem_mapping, refcount);
  
  	panfrost_gem_teardown_mapping(mapping);

-   drm_gem_object_put_unlocked(>obj->base.base);
+   drm_gem_object_put(>obj->base.base);
kfree(mapping);
  }
  
@@ -261,7 +261,7 @@ panfrost_gem_create_with_handle(struct drm_file *file_priv,

 */
ret = drm_gem_handle_create(file_priv, >base, handle);
/* drop reference from allocate - handle holds it now. */
-   drm_gem_object_put_unlocked(>base);
+   drm_gem_object_put(>base);
if (ret)
return ERR_PTR(ret);
  
diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c b/drivers/gpu/drm/panfrost/panfrost_job.c

index 7914b1570841..b2f09c038d35 100644
--- a/drivers/gpu/drm/panfrost/panfrost_job.c
+++ b/drivers/gpu/drm/panfrost/panfrost_job.c
@@ -281,7 +281,7 @@ static void panfrost_job_cleanup(struct kref *ref)
  
  	if (job->bos) {

for (i = 0; i < job->bo_count; i++)
-   drm_gem_object_put_unlocked(job->bos[i]);
+   drm_gem_object_put(job->bos[i]);
  
  		kvfree(job->bos);

}
diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c 
b/drivers/gpu/drm/panfrost/panfrost_mmu.c
index ed28aeba6d59..0a339c6fbfaa 100644
--- a/drivers/gpu/drm/panfrost/panfrost_mmu.c
+++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c
@@ -538,7 +538,7 @@ static int panfrost_mmu_map_fault_addr(struct 
panfrost_device *pfdev, int as,
  err_pages:
drm_gem_shmem_put_pages(>base);
  err_bo:
-   drm_gem_object_put_unlocked(>base.base);
+   drm_gem_object_put(>base.base);
return ret;
  }
  
diff --git a/drivers/gpu/drm/panfrost/panfrost_perfcnt.c b/drivers/gpu/drm/panfrost/panfrost_perfcnt.c

index 6913578d5aa7..ec4695cf3caf 100644
--- a/drivers/gpu/drm/panfrost/panfrost_perfcnt.c
+++ b/drivers/gpu/drm/panfrost/panfrost_perfcnt.c
@@ -156,7 +156,7 @@ static int 

Re: [PATCH v2 13/38] drm: remove _unlocked suffix in drm_object_put_unlocked

2020-05-15 Thread Steven Price

On 15/05/2020 10:50, Emil Velikov wrote:

From: Emil Velikov 

Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.

Just drop the suffix. It makes the API cleaner.

Done via the following script:

__from=drm_gem_object_put_unlocked
__to=drm_gem_object_put
for __file in $(git grep --name-only $__from); do
   sed -i  "s/$__from/$__to/g" $__file;
done

Pay special attention to the compat #define

v2: keep sed and #define removal separate

Cc: David Airlie 
Cc: Daniel Vetter 
Signed-off-by: Emil Velikov 
Acked-by: Sam Ravnborg  (v1)


NIT: The subject is wrong: s/drm_object_put/drm_gem_object_put/

With that fixed:

Reviewed-by: Steven Price 

Steve


---
  Documentation/gpu/drm-mm.rst |  2 +-
  drivers/gpu/drm/drm_client.c |  2 +-
  drivers/gpu/drm/drm_gem.c| 26 ++--
  drivers/gpu/drm/drm_gem_cma_helper.c |  8 +++---
  drivers/gpu/drm/drm_gem_framebuffer_helper.c |  6 ++---
  drivers/gpu/drm/drm_gem_shmem_helper.c   |  4 +--
  drivers/gpu/drm/drm_gem_ttm_helper.c |  2 +-
  drivers/gpu/drm/drm_gem_vram_helper.c| 10 
  drivers/gpu/drm/drm_prime.c  |  6 ++---
  include/drm/drm_gem.h|  2 +-
  10 files changed, 34 insertions(+), 34 deletions(-)

diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
index 5ba2ead8f317..8c8540ee859c 100644
--- a/Documentation/gpu/drm-mm.rst
+++ b/Documentation/gpu/drm-mm.rst
@@ -178,7 +178,7 @@ GEM Objects Lifetime
  
  
  All GEM objects are reference-counted by the GEM core. References can be

-acquired and release by calling drm_gem_object_get() and 
drm_gem_object_put_unlocked()
+acquired and release by calling drm_gem_object_get() and drm_gem_object_put()
  respectively.
  
  When the last reference to a GEM object is released the GEM core calls

diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
index 8cb93f5209a4..536a22747b51 100644
--- a/drivers/gpu/drm/drm_client.c
+++ b/drivers/gpu/drm/drm_client.c
@@ -237,7 +237,7 @@ static void drm_client_buffer_delete(struct 
drm_client_buffer *buffer)
drm_gem_vunmap(buffer->gem, buffer->vaddr);
  
  	if (buffer->gem)

-   drm_gem_object_put_unlocked(buffer->gem);
+   drm_gem_object_put(buffer->gem);
  
  	if (buffer->handle)

drm_mode_destroy_dumb(dev, buffer->handle, 
buffer->client->file);
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index f21327ebc562..ae02b3842c90 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -235,7 +235,7 @@ drm_gem_object_handle_put_unlocked(struct drm_gem_object 
*obj)
mutex_unlock(>object_name_lock);
  
  	if (final)

-   drm_gem_object_put_unlocked(obj);
+   drm_gem_object_put(obj);
  }
  
  /*

@@ -331,7 +331,7 @@ int drm_gem_dumb_map_offset(struct drm_file *file, struct 
drm_device *dev,
  
  	*offset = drm_vma_node_offset_addr(>vma_node);

  out:
-   drm_gem_object_put_unlocked(obj);
+   drm_gem_object_put(obj);
  
  	return ret;

  }
@@ -690,7 +690,7 @@ static int objects_lookup(struct drm_file *filp, u32 
*handle, int count,
   * Returns:
   *
   * @objs filled in with GEM object pointers. Returned GEM objects need to be
- * released with drm_gem_object_put_unlocked(). -ENOENT is returned on a lookup
+ * released with drm_gem_object_put(). -ENOENT is returned on a lookup
   * failure. 0 is returned on success.
   *
   */
@@ -785,7 +785,7 @@ long drm_gem_dma_resv_wait(struct drm_file *filep, u32 
handle,
else if (ret > 0)
ret = 0;
  
-	drm_gem_object_put_unlocked(obj);

+   drm_gem_object_put(obj);
  
  	return ret;

  }
@@ -860,7 +860,7 @@ drm_gem_flink_ioctl(struct drm_device *dev, void *data,
  
  err:

mutex_unlock(>object_name_lock);
-   drm_gem_object_put_unlocked(obj);
+   drm_gem_object_put(obj);
return ret;
  }
  
@@ -898,7 +898,7 @@ drm_gem_open_ioctl(struct drm_device *dev, void *data,
  
  	/* drm_gem_handle_create_tail unlocks dev->object_name_lock. */

ret = drm_gem_handle_create_tail(file_priv, obj, );
-   drm_gem_object_put_unlocked(obj);
+   drm_gem_object_put(obj);
if (ret)
return ret;
  
@@ -991,7 +991,7 @@ EXPORT_SYMBOL(drm_gem_object_free);

   * driver doesn't use _device.struct_mutex for anything.
   *
   * For drivers not encumbered with legacy locking use
- * drm_gem_object_put_unlocked() instead.
+ * drm_gem_object_put() instead.
   */
  void
  drm_gem_object_put_locked(struct drm_gem_object *obj)
@@ -1030,7 +1030,7 @@ void drm_gem_vm_close(struct vm_area_struct *vma)
  {
struct drm_gem_object *obj = vma->vm_private_data;
  
-	drm_gem_object_put_unlocked(obj);

+   drm_gem_object_put(obj);
  }
  

Re: [PATCH v2 11/38] drm/gem: add _locked suffix to drm_object_put

2020-05-15 Thread Steven Price

On 15/05/2020 10:50, Emil Velikov wrote:

From: Emil Velikov 

Vast majority of DRM (core and drivers) are struct_mutex free.

As such we have only a handful of cases where the locked helper should
be used. Make that stand out a little bit better.

Done via the following script:

__from=drm_gem_object_put
__to=drm_gem_object_put_locked

for __file in $(git grep --name-only --word-regexp $__from); do
   sed -i  "s/\<$__from\>/$__to/g" $__file;
done

Cc: Rob Clark 
Cc: Sean Paul 
Cc: linux-arm-...@vger.kernel.org
Signed-off-by: Emil Velikov 
Acked-by: Sam Ravnborg 


NIT: The subject is wrong: s/drm_object_put/drm_gem_object_put/

Otherwise with that fixes LTGM:

Reviewed-By: Steven Price 

Steve


---
  drivers/gpu/drm/drm_gem.c | 6 +++---
  drivers/gpu/drm/msm/adreno/a5xx_debugfs.c | 4 ++--
  drivers/gpu/drm/msm/msm_drv.c | 2 +-
  drivers/gpu/drm/msm/msm_gem.c | 6 +++---
  drivers/gpu/drm/msm/msm_gem_submit.c  | 2 +-
  drivers/gpu/drm/msm/msm_gpu.c | 2 +-
  include/drm/drm_gem.h | 4 ++--
  7 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 599d5ff53b73..f21327ebc562 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -983,7 +983,7 @@ drm_gem_object_free(struct kref *kref)
  EXPORT_SYMBOL(drm_gem_object_free);
  
  /**

- * drm_gem_object_put - release a GEM buffer object reference
+ * drm_gem_object_put_locked - release a GEM buffer object reference
   * @obj: GEM buffer object
   *
   * This releases a reference to @obj. Callers must hold the
@@ -994,7 +994,7 @@ EXPORT_SYMBOL(drm_gem_object_free);
   * drm_gem_object_put_unlocked() instead.
   */
  void
-drm_gem_object_put(struct drm_gem_object *obj)
+drm_gem_object_put_locked(struct drm_gem_object *obj)
  {
if (obj) {
WARN_ON(!mutex_is_locked(>dev->struct_mutex));
@@ -1002,7 +1002,7 @@ drm_gem_object_put(struct drm_gem_object *obj)
kref_put(>refcount, drm_gem_object_free);
}
  }
-EXPORT_SYMBOL(drm_gem_object_put);
+EXPORT_SYMBOL(drm_gem_object_put_locked);
  
  /**

   * drm_gem_vm_open - vma->ops->open implementation for GEM
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_debugfs.c 
b/drivers/gpu/drm/msm/adreno/a5xx_debugfs.c
index 8cae2ca4af6b..68eddac7771c 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_debugfs.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_debugfs.c
@@ -124,13 +124,13 @@ reset_set(void *data, u64 val)
  
  	if (a5xx_gpu->pm4_bo) {

msm_gem_unpin_iova(a5xx_gpu->pm4_bo, gpu->aspace);
-   drm_gem_object_put(a5xx_gpu->pm4_bo);
+   drm_gem_object_put_locked(a5xx_gpu->pm4_bo);
a5xx_gpu->pm4_bo = NULL;
}
  
  	if (a5xx_gpu->pfp_bo) {

msm_gem_unpin_iova(a5xx_gpu->pfp_bo, gpu->aspace);
-   drm_gem_object_put(a5xx_gpu->pfp_bo);
+   drm_gem_object_put_locked(a5xx_gpu->pfp_bo);
a5xx_gpu->pfp_bo = NULL;
}
  
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c

index 29295dee2a2e..6baed5b43ea3 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -932,7 +932,7 @@ static int msm_ioctl_gem_madvise(struct drm_device *dev, 
void *data,
ret = 0;
}
  
-	drm_gem_object_put(obj);

+   drm_gem_object_put_locked(obj);
  
  unlock:

mutex_unlock(>struct_mutex);
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 5a6a79fbc9d6..8696c405f709 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -879,7 +879,7 @@ void msm_gem_describe_objects(struct list_head *list, 
struct seq_file *m)
  }
  #endif
  
-/* don't call directly!  Use drm_gem_object_put() and friends */

+/* don't call directly!  Use drm_gem_object_put_locked() and friends */
  void msm_gem_free_object(struct drm_gem_object *obj)
  {
struct msm_gem_object *msm_obj = to_msm_bo(obj);
@@ -1183,7 +1183,7 @@ static void *_msm_gem_kernel_new(struct drm_device *dev, 
uint32_t size,
return vaddr;
  err:
if (locked)
-   drm_gem_object_put(obj);
+   drm_gem_object_put_locked(obj);
else
drm_gem_object_put_unlocked(obj);
  
@@ -1215,7 +1215,7 @@ void msm_gem_kernel_put(struct drm_gem_object *bo,

msm_gem_unpin_iova(bo, aspace);
  
  	if (locked)

-   drm_gem_object_put(bo);
+   drm_gem_object_put_locked(bo);
else
drm_gem_object_put_unlocked(bo);
  }
diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c 
b/drivers/gpu/drm/msm/msm_gem_submit.c
index 385d4965a8d0..8f450a245cfb 100644
--- a/drivers/gpu/drm/msm/msm_gem_submit.c
+++ b/drivers/gpu/drm/msm/msm_gem_submit.c
@@ -387,7 +387,7 @@ static void submit_cleanup(struct msm_gem_submit *submit)
struct msm_gem_object *msm_obj = submit->bos[i].obj;

Re: [PATCH v6 08/16] drm/i915: Don't fully disable HDCP on a port if multiple pipes are using it

2020-05-15 Thread Ramalingam C
On 2020-04-29 at 15:54:54 -0400, Sean Paul wrote:
> From: Sean Paul 
> 
> This patch is required for HDCP over MST. If a port is being used for
> multiple HDCP streams, we don't want to fully disable HDCP on a port if
> one of them is disabled. Instead, we just disable the HDCP signalling on
> that particular pipe and exit early. The last pipe to disable HDCP will
> also bring down HDCP on the port.
> 
> In order to achieve this, we need to keep a refcount in intel_digital_port
> and protect it using a new hdcp_mutex.
> 
> Cc: Ramalingam C 
> Signed-off-by: Sean Paul 
> Link: 
> https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-8-s...@poorly.run
>  #v1
> Link: 
> https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-9-s...@poorly.run
>  #v2
> Link: 
> https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-9-s...@poorly.run
>  #v3
> Link: 
> https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-9-s...@poorly.run
>  #v4
> Link: 
> https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-9-s...@poorly.run
>  #v5
> 
> Changes in v2:
> -Move the toggle_signalling call into _intel_hdcp_disable so it's called from 
> check_work
> Changes in v3:
> -None
> Changes in v4:
> -None
> Changes in v5:
> -Change WARN_ON to drm_WARN_ON
> Changes in v6:
> -None
> ---
>  drivers/gpu/drm/i915/display/intel_ddi.c  |  3 ++
>  .../drm/i915/display/intel_display_types.h|  5 ++
>  drivers/gpu/drm/i915/display/intel_dp.c   |  2 +
>  drivers/gpu/drm/i915/display/intel_hdcp.c | 53 +++
>  drivers/gpu/drm/i915/display/intel_hdmi.c |  2 +
>  5 files changed, 56 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index dc5d39ae4743..11155a8a73c0 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -4801,6 +4801,9 @@ void intel_ddi_init(struct drm_i915_private *dev_priv, 
> enum port port)
>   drm_encoder_init(_priv->drm, >base, _ddi_funcs,
>DRM_MODE_ENCODER_TMDS, "DDI %c", port_name(port));
>  
> + mutex_init(_dig_port->hdcp_mutex);
> + intel_dig_port->num_hdcp_streams = 0;
> +
>   encoder->hotplug = intel_ddi_hotplug;
>   encoder->compute_output_type = intel_ddi_compute_output_type;
>   encoder->compute_config = intel_ddi_compute_config;
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 383046050c37..69edfab4e266 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1411,6 +1411,11 @@ struct intel_digital_port {
>   enum phy_fia tc_phy_fia;
>   u8 tc_phy_fia_idx;
>  
> + /* protects num_hdcp_streams reference count */
> + struct mutex hdcp_mutex;
> + /* the number of pipes using HDCP signalling out of this port */
> + unsigned int num_hdcp_streams;
> +
>   void (*write_infoframe)(struct intel_encoder *encoder,
>   const struct intel_crtc_state *crtc_state,
>   unsigned int type,
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 39c1304fe071..a33ee8f30d14 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -8450,6 +8450,8 @@ bool intel_dp_init(struct drm_i915_private *dev_priv,
>   intel_encoder = _dig_port->base;
>   encoder = _encoder->base;
>  
> + mutex_init(_dig_port->hdcp_mutex);
> +
>   if (drm_encoder_init(_priv->drm, _encoder->base,
>_dp_enc_funcs, DRM_MODE_ENCODER_TMDS,
>"DP %c", port_name(port)))
> diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c 
> b/drivers/gpu/drm/i915/display/intel_hdcp.c
> index a4446d47ef27..0c00bbc3f66e 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> @@ -801,6 +801,19 @@ static int _intel_hdcp_disable(struct intel_connector 
> *connector)
>   drm_dbg_kms(_priv->drm, "[%s:%d] HDCP is being disabled...\n",
>   connector->base.name, connector->base.base.id);
>  
> + /*
> +  * If there are other connectors on this port using HDCP, don't disable
> +  * it. Instead, toggle the HDCP signalling off on that particular
> +  * connector/pipe and exit.
> +  */
> + if (intel_dig_port->num_hdcp_streams > 0) {
> + ret = hdcp->shim->toggle_signalling(intel_dig_port,
> + cpu_transcoder, false);
> + if (ret)
> + DRM_ERROR("Failed to disable HDCP signalling\n");
> + return ret;
> + }
> +
>   hdcp->hdcp_encrypted = false;
>   intel_de_write(dev_priv, HDCP_CONF(dev_priv, cpu_transcoder, 

Re: [PATCH v2 00/38] Fareless gem_free_object

2020-05-15 Thread Thomas Zimmermann
Hi,

I have reviewed some of these patches. For the rest of the series you
can add

Acked-by: Thomas Zimmermann 

Best regards
Thomas

Am 15.05.20 um 11:50 schrieb Emil Velikov:
> Hi all,
> 
> Here is v2 of the series, with the requested minor tweaks.
> 
>  - Add new WARNING in the struct_mutex doc (Daniel)
>  - Drop a few more struct_mutex references (Daniel)
>  - Missing space in the drm_object_put doc (Jani)
>  - Keep drm_object_put_unlocked removal as separate patch (Sam, Thomas)
> 
> Considering other have pending work, which may clash with this series
> and the overall positive feedback (thanks everyone), I'm inclined to
> merge the series to drm-misc-next on Monday evening.
> 
> -Emil
> 
> Emil Velikov (38):
>   drm: remove unused drm_gem.h include
>   drm/gem: use _unlocked reference in drm_gem_objects_lookup docs
>   drm/todo: mention i915 in the struct_mutex section
>   drm/doc: drop struct_mutex references
>   drm/doc: add WARNING for drm_device::struct_mutex
>   drm/doc: drop struct_mutex reference for drm_gem_object_free
>   drm/amdgpu: use the unlocked drm_gem_object_put
>   drm/gma500: Use lockless gem BO free callback
>   drm: remove drm_driver::gem_free_object
>   drm/gem: fold drm_gem_object_put_unlocked and __drm_gem_object_put()
>   drm/gem: add _locked suffix to drm_object_put
>   drm/gem: add drm_object_put helper
>   drm: remove _unlocked suffix in drm_object_put_unlocked
>   drm/amd: remove _unlocked suffix in drm_object_put_unlocked
>   drm/arm: remove _unlocked suffix in drm_object_put_unlocked
>   drm/armada: remove _unlocked suffix in drm_object_put_unlocked
>   drm/etnaviv: remove _unlocked suffix in drm_object_put_unlocked
>   drm/exynos: remove _unlocked suffix in drm_object_put_unlocked
>   drm/gma500: remove _unlocked suffix in drm_object_put_unlocked
>   drm/i915: remove _unlocked suffix in drm_object_put_unlocked
>   drm/lima: remove _unlocked suffix in drm_object_put_unlocked
>   drm/mediatek: remove _unlocked suffix in drm_object_put_unlocked
>   drm/mgag200: remove _unlocked suffix in drm_object_put_unlocked
>   drm/msm: remove _unlocked suffix in drm_object_put_unlocked
>   drm/nouveau: remove _unlocked suffix in drm_object_put_unlocked
>   drm/omapdrm: remove _unlocked suffix in drm_object_put_unlocked
>   drm/panfrost: remove _unlocked suffix in drm_object_put_unlocked
>   drm/qxl: remove _unlocked suffix in drm_object_put_unlocked
>   drm/radeon: remove _unlocked suffix in drm_object_put_unlocked
>   drm/rockchip: remove _unlocked suffix in drm_object_put_unlocked
>   drm/tegra: remove _unlocked suffix in drm_object_put_unlocked
>   drm/v3d: remove _unlocked suffix in drm_object_put_unlocked
>   drm/vc4: remove _unlocked suffix in drm_object_put_unlocked
>   drm/vgem: remove _unlocked suffix in drm_object_put_unlocked
>   drm/virtio: remove _unlocked suffix in drm_object_put_unlocked
>   drm/vkms: remove _unlocked suffix in drm_object_put_unlocked
>   drm/xen: remove _unlocked suffix in drm_object_put_unlocked
>   drm: remove transient drm_object_put_unlocked()
> 
>  Documentation/gpu/drm-mm.rst  |  5 +-
>  Documentation/gpu/todo.rst|  4 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c   |  2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c|  2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_display.c   |  4 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c|  4 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c   | 20 +++---
>  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c|  6 +-
>  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c|  6 +-
>  drivers/gpu/drm/amd/amdgpu/dce_v6_0.c |  6 +-
>  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c |  6 +-
>  .../arm/display/komeda/komeda_framebuffer.c   |  6 +-
>  drivers/gpu/drm/arm/malidp_drv.c  |  4 +-
>  drivers/gpu/drm/armada/armada_crtc.c  |  8 +--
>  drivers/gpu/drm/armada/armada_fb.c|  4 +-
>  drivers/gpu/drm/armada/armada_fbdev.c |  6 +-
>  drivers/gpu/drm/armada/armada_gem.c   | 10 +--
>  drivers/gpu/drm/drm_client.c  |  2 +-
>  drivers/gpu/drm/drm_gem.c | 70 +--
>  drivers/gpu/drm/drm_gem_cma_helper.c  |  8 +--
>  drivers/gpu/drm/drm_gem_framebuffer_helper.c  |  6 +-
>  drivers/gpu/drm/drm_gem_shmem_helper.c|  4 +-
>  drivers/gpu/drm/drm_gem_ttm_helper.c  |  2 +-
>  drivers/gpu/drm/drm_gem_vram_helper.c | 10 +--
>  drivers/gpu/drm/drm_prime.c   |  6 +-
>  drivers/gpu/drm/drm_vm.c  |  1 -
>  drivers/gpu/drm/etnaviv/etnaviv_drv.c |  8 +--
>  drivers/gpu/drm/etnaviv/etnaviv_gem.c |  6 +-
>  drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c   |  2 +-
>  drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c  |  2 +-
>  drivers/gpu/drm/exynos/exynos_drm_gem.c   |  4 +-
>  drivers/gpu/drm/exynos/exynos_drm_gem.h   |  2 +-
>  drivers/gpu/drm/gma500/framebuffer.c  |  2 +-
>  drivers/gpu/drm/gma500/gem.c 

Re: [PATCH v1 02/18] drm/tilcdc: use devm_of_find_backlight

2020-05-15 Thread Tomi Valkeinen

On 14/05/2020 22:09, Sam Ravnborg wrote:

Look up backlight device using devm_of_find_backlight().
This simplifies the code and prevents us from hardcoding
the node name in the driver.

Signed-off-by: Sam Ravnborg 
Cc: Jyri Sarha 
Cc: Tomi Valkeinen 
---
  drivers/gpu/drm/tilcdc/tilcdc_panel.c | 17 ++---
  1 file changed, 6 insertions(+), 11 deletions(-)


Reviewed-by: Tomi Valkeinen 

 Tomi

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v1 01/18] drm/omap: display: use devm_of_find_backlight

2020-05-15 Thread Tomi Valkeinen

On 14/05/2020 22:09, Sam Ravnborg wrote:

Look up backlight device using devm_of_find_backlight().
This simplifies the code and prevents us from hardcoding
the node name in the driver.

Signed-off-by: Sam Ravnborg 
Cc: Tomi Valkeinen 
Cc: Zheng Bin 
Cc: Kate Stewart 
Cc: Enrico Weigelt 
Cc: Allison Randal 
Cc: Laurent Pinchart 
Cc: Thomas Gleixner 
Cc: Kefeng Wang 
Cc: Sam Ravnborg 
---
  .../gpu/drm/omapdrm/displays/panel-dsi-cm.c| 18 --
  1 file changed, 8 insertions(+), 10 deletions(-)


Reviewed-by: Tomi Valkeinen 

 Tomi

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 11/38] drm/gem: add _locked suffix to drm_object_put

2020-05-15 Thread Thomas Zimmermann
Hi Emil

Am 15.05.20 um 11:50 schrieb Emil Velikov:
> From: Emil Velikov 
> 
> Vast majority of DRM (core and drivers) are struct_mutex free.
> 
> As such we have only a handful of cases where the locked helper should
> be used. Make that stand out a little bit better.
> 
> Done via the following script:
> 
> __from=drm_gem_object_put
> __to=drm_gem_object_put_locked
> 
> for __file in $(git grep --name-only --word-regexp $__from); do
>   sed -i  "s/\<$__from\>/$__to/g" $__file;
> done
> 
> Cc: Rob Clark 
> Cc: Sean Paul 
> Cc: linux-arm-...@vger.kernel.org
> Signed-off-by: Emil Velikov 
> Acked-by: Sam Ravnborg 
> ---
>  drivers/gpu/drm/drm_gem.c | 6 +++---
>  drivers/gpu/drm/msm/adreno/a5xx_debugfs.c | 4 ++--
>  drivers/gpu/drm/msm/msm_drv.c | 2 +-
>  drivers/gpu/drm/msm/msm_gem.c | 6 +++---
>  drivers/gpu/drm/msm/msm_gem_submit.c  | 2 +-
>  drivers/gpu/drm/msm/msm_gpu.c | 2 +-
>  include/drm/drm_gem.h | 4 ++--
>  7 files changed, 13 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 599d5ff53b73..f21327ebc562 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -983,7 +983,7 @@ drm_gem_object_free(struct kref *kref)
>  EXPORT_SYMBOL(drm_gem_object_free);
>  
>  /**
> - * drm_gem_object_put - release a GEM buffer object reference
> + * drm_gem_object_put_locked - release a GEM buffer object reference
>   * @obj: GEM buffer object
>   *
>   * This releases a reference to @obj. Callers must hold the
> @@ -994,7 +994,7 @@ EXPORT_SYMBOL(drm_gem_object_free);
>   * drm_gem_object_put_unlocked() instead.
>   */
>  void
> -drm_gem_object_put(struct drm_gem_object *obj)
> +drm_gem_object_put_locked(struct drm_gem_object *obj)
>  {
>   if (obj) {
>   WARN_ON(!mutex_is_locked(>dev->struct_mutex));
> @@ -1002,7 +1002,7 @@ drm_gem_object_put(struct drm_gem_object *obj)
>   kref_put(>refcount, drm_gem_object_free);
>   }
>  }
> -EXPORT_SYMBOL(drm_gem_object_put);
> +EXPORT_SYMBOL(drm_gem_object_put_locked);
>  
>  /**
>   * drm_gem_vm_open - vma->ops->open implementation for GEM
> diff --git a/drivers/gpu/drm/msm/adreno/a5xx_debugfs.c 
> b/drivers/gpu/drm/msm/adreno/a5xx_debugfs.c
> index 8cae2ca4af6b..68eddac7771c 100644
> --- a/drivers/gpu/drm/msm/adreno/a5xx_debugfs.c
> +++ b/drivers/gpu/drm/msm/adreno/a5xx_debugfs.c
> @@ -124,13 +124,13 @@ reset_set(void *data, u64 val)
>  
>   if (a5xx_gpu->pm4_bo) {
>   msm_gem_unpin_iova(a5xx_gpu->pm4_bo, gpu->aspace);
> - drm_gem_object_put(a5xx_gpu->pm4_bo);
> + drm_gem_object_put_locked(a5xx_gpu->pm4_bo);
>   a5xx_gpu->pm4_bo = NULL;
>   }
>  
>   if (a5xx_gpu->pfp_bo) {
>   msm_gem_unpin_iova(a5xx_gpu->pfp_bo, gpu->aspace);
> - drm_gem_object_put(a5xx_gpu->pfp_bo);
> + drm_gem_object_put_locked(a5xx_gpu->pfp_bo);
>   a5xx_gpu->pfp_bo = NULL;
>   }
>  
> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> index 29295dee2a2e..6baed5b43ea3 100644
> --- a/drivers/gpu/drm/msm/msm_drv.c
> +++ b/drivers/gpu/drm/msm/msm_drv.c
> @@ -932,7 +932,7 @@ static int msm_ioctl_gem_madvise(struct drm_device *dev, 
> void *data,
>   ret = 0;
>   }
>  
> - drm_gem_object_put(obj);
> + drm_gem_object_put_locked(obj);
>  
>  unlock:
>   mutex_unlock(>struct_mutex);
> diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
> index 5a6a79fbc9d6..8696c405f709 100644
> --- a/drivers/gpu/drm/msm/msm_gem.c
> +++ b/drivers/gpu/drm/msm/msm_gem.c
> @@ -879,7 +879,7 @@ void msm_gem_describe_objects(struct list_head *list, 
> struct seq_file *m)
>  }
>  #endif
>  
> -/* don't call directly!  Use drm_gem_object_put() and friends */
> +/* don't call directly!  Use drm_gem_object_put_locked() and friends */
>  void msm_gem_free_object(struct drm_gem_object *obj)
>  {
>   struct msm_gem_object *msm_obj = to_msm_bo(obj);
> @@ -1183,7 +1183,7 @@ static void *_msm_gem_kernel_new(struct drm_device 
> *dev, uint32_t size,
>   return vaddr;
>  err:
>   if (locked)
> - drm_gem_object_put(obj);
> + drm_gem_object_put_locked(obj);
>   else
>   drm_gem_object_put_unlocked(obj);
>  
> @@ -1215,7 +1215,7 @@ void msm_gem_kernel_put(struct drm_gem_object *bo,
>   msm_gem_unpin_iova(bo, aspace);
>  
>   if (locked)
> - drm_gem_object_put(bo);
> + drm_gem_object_put_locked(bo);
>   else
>   drm_gem_object_put_unlocked(bo);
>  }
> diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c 
> b/drivers/gpu/drm/msm/msm_gem_submit.c
> index 385d4965a8d0..8f450a245cfb 100644
> --- a/drivers/gpu/drm/msm/msm_gem_submit.c
> +++ b/drivers/gpu/drm/msm/msm_gem_submit.c
> @@ -387,7 +387,7 @@ static void submit_cleanup(struct msm_gem_submit *submit)
>   struct 

Re: [PATCH v2 31/38] drm/tegra: remove _unlocked suffix in drm_object_put_unlocked

2020-05-15 Thread Thierry Reding
On Fri, May 15, 2020 at 10:51:11AM +0100, Emil Velikov wrote:
> From: Emil Velikov 
> 
> Spelling out _unlocked for each and every driver is a annoying.
> Especially if we consider how many drivers, do not know (or need to)
> about the horror stories involving struct_mutex.
> 
> Just drop the suffix. It makes the API cleaner.
> 
> Done via the following script:
> 
> __from=drm_gem_object_put_unlocked
> __to=drm_gem_object_put
> for __file in $(git grep --name-only $__from); do
>   sed -i  "s/$__from/$__to/g" $__file;
> done
> 
> Cc: Thierry Reding 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Signed-off-by: Emil Velikov 
> Acked-by: Sam Ravnborg 
> ---
>  drivers/gpu/drm/tegra/drm.c | 12 ++--
>  drivers/gpu/drm/tegra/fb.c  |  6 +++---
>  drivers/gpu/drm/tegra/gem.c |  4 ++--
>  3 files changed, 11 insertions(+), 11 deletions(-)

Acked-by: Thierry Reding 


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


Re: [PATCH v4 2/4] drm/imx: Add initial support for DCSS on iMX8MQ

2020-05-15 Thread Guido Günther
Hi Laurentiu,
On Fri, May 15, 2020 at 02:10:13PM +0300, Laurentiu Palcu wrote:
> Hi Guido,
> 
> On Fri, May 15, 2020 at 11:27:19AM +0200, Guido Günther wrote:
> > Hi Laurentiu,
> > On Fri, Mar 06, 2020 at 02:49:26PM +0200, Laurentiu Palcu wrote:
> > > From: Laurentiu Palcu 
> > > 
> > > This adds initial support for iMX8MQ's Display Controller Subsystem 
> > > (DCSS).
> > > Some of its capabilities include:
> > >  * 4K@60fps;
> > >  * HDR10;
> > >  * one graphics and 2 video pipelines;
> > >  * on-the-fly decompression of compressed video and graphics;
> > > 
> > > The reference manual can be found here:
> > > https://www.nxp.com/webapp/Download?colCode=IMX8MDQLQRM
> > > 
> > > The current patch adds only basic functionality: one primary plane for
> > > graphics, linear, tiled and super-tiled buffers support (no graphics
> > > decompression yet), no HDR10 and no video planes.
> > > 
> > > Video planes support and HDR10 will be added in subsequent patches once
> > > per-plane de-gamma/CSC/gamma support is in.
> > > 
> > > Signed-off-by: Laurentiu Palcu 
> > > ---
> > >  drivers/gpu/drm/imx/Kconfig|   2 +
> > >  drivers/gpu/drm/imx/Makefile   |   1 +
> > >  drivers/gpu/drm/imx/dcss/Kconfig   |   9 +
> > >  drivers/gpu/drm/imx/dcss/Makefile  |   6 +
> > >  drivers/gpu/drm/imx/dcss/dcss-blkctl.c |  73 +++
> > >  drivers/gpu/drm/imx/dcss/dcss-crtc.c   | 206 ++
> > >  drivers/gpu/drm/imx/dcss/dcss-ctxld.c  | 431 +
> > >  drivers/gpu/drm/imx/dcss/dcss-dev.c| 277 +
> > >  drivers/gpu/drm/imx/dcss/dcss-dev.h| 172 +
> > >  drivers/gpu/drm/imx/dcss/dcss-dpr.c| 562 +
> > >  drivers/gpu/drm/imx/dcss/dcss-drv.c| 183 ++
> > >  drivers/gpu/drm/imx/dcss/dcss-dtg.c| 413 +
> > >  drivers/gpu/drm/imx/dcss/dcss-kms.c| 188 ++
> > >  drivers/gpu/drm/imx/dcss/dcss-kms.h|  43 ++
> > >  drivers/gpu/drm/imx/dcss/dcss-plane.c  | 405 
> > >  drivers/gpu/drm/imx/dcss/dcss-scaler.c | 826 +
> > >  drivers/gpu/drm/imx/dcss/dcss-ss.c | 180 ++
> > >  17 files changed, 3977 insertions(+)
> > >  create mode 100644 drivers/gpu/drm/imx/dcss/Kconfig
> > >  create mode 100644 drivers/gpu/drm/imx/dcss/Makefile
> > >  create mode 100644 drivers/gpu/drm/imx/dcss/dcss-blkctl.c
> > >  create mode 100644 drivers/gpu/drm/imx/dcss/dcss-crtc.c
> > >  create mode 100644 drivers/gpu/drm/imx/dcss/dcss-ctxld.c
> > >  create mode 100644 drivers/gpu/drm/imx/dcss/dcss-dev.c
> > >  create mode 100644 drivers/gpu/drm/imx/dcss/dcss-dev.h
> > >  create mode 100644 drivers/gpu/drm/imx/dcss/dcss-dpr.c
> > >  create mode 100644 drivers/gpu/drm/imx/dcss/dcss-drv.c
> > >  create mode 100644 drivers/gpu/drm/imx/dcss/dcss-dtg.c
> > >  create mode 100644 drivers/gpu/drm/imx/dcss/dcss-kms.c
> > >  create mode 100644 drivers/gpu/drm/imx/dcss/dcss-kms.h
> > >  create mode 100644 drivers/gpu/drm/imx/dcss/dcss-plane.c
> > >  create mode 100644 drivers/gpu/drm/imx/dcss/dcss-scaler.c
> > >  create mode 100644 drivers/gpu/drm/imx/dcss/dcss-ss.c
> > > 
> > > diff --git a/drivers/gpu/drm/imx/Kconfig b/drivers/gpu/drm/imx/Kconfig
> > > index 207bf7409dfb..6231048aa5aa 100644
> > > --- a/drivers/gpu/drm/imx/Kconfig
> > > +++ b/drivers/gpu/drm/imx/Kconfig
> > > @@ -39,3 +39,5 @@ config DRM_IMX_HDMI
> > >   depends on DRM_IMX
> > >   help
> > > Choose this if you want to use HDMI on i.MX6.
> > > +
> > > +source "drivers/gpu/drm/imx/dcss/Kconfig"
> > > diff --git a/drivers/gpu/drm/imx/Makefile b/drivers/gpu/drm/imx/Makefile
> > > index 21cdcc2faabc..b644deffe948 100644
> > > --- a/drivers/gpu/drm/imx/Makefile
> > > +++ b/drivers/gpu/drm/imx/Makefile
> > > @@ -9,3 +9,4 @@ obj-$(CONFIG_DRM_IMX_TVE) += imx-tve.o
> > >  obj-$(CONFIG_DRM_IMX_LDB) += imx-ldb.o
> > >  
> > >  obj-$(CONFIG_DRM_IMX_HDMI) += dw_hdmi-imx.o
> > > +obj-$(CONFIG_DRM_IMX_DCSS) += dcss/
> > > diff --git a/drivers/gpu/drm/imx/dcss/Kconfig 
> > > b/drivers/gpu/drm/imx/dcss/Kconfig
> > > new file mode 100644
> > > index ..988979bc22cc
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/imx/dcss/Kconfig
> > > @@ -0,0 +1,9 @@
> > > +config DRM_IMX_DCSS
> > > + tristate "i.MX8MQ DCSS"
> > > + select RESET_CONTROLLER
> > > + select IMX_IRQSTEER
> > > + select DRM_KMS_CMA_HELPER
> > > + depends on DRM && ARCH_MXC
> > > + help
> > > +   Choose this if you have a NXP i.MX8MQ based system and want to use the
> > > +   Display Controller Subsystem. This option enables DCSS support.
> > > diff --git a/drivers/gpu/drm/imx/dcss/Makefile 
> > > b/drivers/gpu/drm/imx/dcss/Makefile
> > > new file mode 100644
> > > index ..8c7c8da42792
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/imx/dcss/Makefile
> > > @@ -0,0 +1,6 @@
> > > +imx-dcss-objs := dcss-drv.o dcss-dev.o dcss-blkctl.o dcss-ctxld.o 
> > > dcss-dtg.o \
> > > +  dcss-ss.o dcss-dpr.o dcss-scaler.o dcss-kms.o 
> > > dcss-crtc.o \
> > > +  

Re: [PATCH v4 2/4] drm/imx: Add initial support for DCSS on iMX8MQ

2020-05-15 Thread Laurentiu Palcu
Hi Guido,

On Fri, May 15, 2020 at 11:27:19AM +0200, Guido Günther wrote:
> Hi Laurentiu,
> On Fri, Mar 06, 2020 at 02:49:26PM +0200, Laurentiu Palcu wrote:
> > From: Laurentiu Palcu 
> > 
> > This adds initial support for iMX8MQ's Display Controller Subsystem (DCSS).
> > Some of its capabilities include:
> >  * 4K@60fps;
> >  * HDR10;
> >  * one graphics and 2 video pipelines;
> >  * on-the-fly decompression of compressed video and graphics;
> > 
> > The reference manual can be found here:
> > https://www.nxp.com/webapp/Download?colCode=IMX8MDQLQRM
> > 
> > The current patch adds only basic functionality: one primary plane for
> > graphics, linear, tiled and super-tiled buffers support (no graphics
> > decompression yet), no HDR10 and no video planes.
> > 
> > Video planes support and HDR10 will be added in subsequent patches once
> > per-plane de-gamma/CSC/gamma support is in.
> > 
> > Signed-off-by: Laurentiu Palcu 
> > ---
> >  drivers/gpu/drm/imx/Kconfig|   2 +
> >  drivers/gpu/drm/imx/Makefile   |   1 +
> >  drivers/gpu/drm/imx/dcss/Kconfig   |   9 +
> >  drivers/gpu/drm/imx/dcss/Makefile  |   6 +
> >  drivers/gpu/drm/imx/dcss/dcss-blkctl.c |  73 +++
> >  drivers/gpu/drm/imx/dcss/dcss-crtc.c   | 206 ++
> >  drivers/gpu/drm/imx/dcss/dcss-ctxld.c  | 431 +
> >  drivers/gpu/drm/imx/dcss/dcss-dev.c| 277 +
> >  drivers/gpu/drm/imx/dcss/dcss-dev.h| 172 +
> >  drivers/gpu/drm/imx/dcss/dcss-dpr.c| 562 +
> >  drivers/gpu/drm/imx/dcss/dcss-drv.c| 183 ++
> >  drivers/gpu/drm/imx/dcss/dcss-dtg.c| 413 +
> >  drivers/gpu/drm/imx/dcss/dcss-kms.c| 188 ++
> >  drivers/gpu/drm/imx/dcss/dcss-kms.h|  43 ++
> >  drivers/gpu/drm/imx/dcss/dcss-plane.c  | 405 
> >  drivers/gpu/drm/imx/dcss/dcss-scaler.c | 826 +
> >  drivers/gpu/drm/imx/dcss/dcss-ss.c | 180 ++
> >  17 files changed, 3977 insertions(+)
> >  create mode 100644 drivers/gpu/drm/imx/dcss/Kconfig
> >  create mode 100644 drivers/gpu/drm/imx/dcss/Makefile
> >  create mode 100644 drivers/gpu/drm/imx/dcss/dcss-blkctl.c
> >  create mode 100644 drivers/gpu/drm/imx/dcss/dcss-crtc.c
> >  create mode 100644 drivers/gpu/drm/imx/dcss/dcss-ctxld.c
> >  create mode 100644 drivers/gpu/drm/imx/dcss/dcss-dev.c
> >  create mode 100644 drivers/gpu/drm/imx/dcss/dcss-dev.h
> >  create mode 100644 drivers/gpu/drm/imx/dcss/dcss-dpr.c
> >  create mode 100644 drivers/gpu/drm/imx/dcss/dcss-drv.c
> >  create mode 100644 drivers/gpu/drm/imx/dcss/dcss-dtg.c
> >  create mode 100644 drivers/gpu/drm/imx/dcss/dcss-kms.c
> >  create mode 100644 drivers/gpu/drm/imx/dcss/dcss-kms.h
> >  create mode 100644 drivers/gpu/drm/imx/dcss/dcss-plane.c
> >  create mode 100644 drivers/gpu/drm/imx/dcss/dcss-scaler.c
> >  create mode 100644 drivers/gpu/drm/imx/dcss/dcss-ss.c
> > 
> > diff --git a/drivers/gpu/drm/imx/Kconfig b/drivers/gpu/drm/imx/Kconfig
> > index 207bf7409dfb..6231048aa5aa 100644
> > --- a/drivers/gpu/drm/imx/Kconfig
> > +++ b/drivers/gpu/drm/imx/Kconfig
> > @@ -39,3 +39,5 @@ config DRM_IMX_HDMI
> > depends on DRM_IMX
> > help
> >   Choose this if you want to use HDMI on i.MX6.
> > +
> > +source "drivers/gpu/drm/imx/dcss/Kconfig"
> > diff --git a/drivers/gpu/drm/imx/Makefile b/drivers/gpu/drm/imx/Makefile
> > index 21cdcc2faabc..b644deffe948 100644
> > --- a/drivers/gpu/drm/imx/Makefile
> > +++ b/drivers/gpu/drm/imx/Makefile
> > @@ -9,3 +9,4 @@ obj-$(CONFIG_DRM_IMX_TVE) += imx-tve.o
> >  obj-$(CONFIG_DRM_IMX_LDB) += imx-ldb.o
> >  
> >  obj-$(CONFIG_DRM_IMX_HDMI) += dw_hdmi-imx.o
> > +obj-$(CONFIG_DRM_IMX_DCSS) += dcss/
> > diff --git a/drivers/gpu/drm/imx/dcss/Kconfig 
> > b/drivers/gpu/drm/imx/dcss/Kconfig
> > new file mode 100644
> > index ..988979bc22cc
> > --- /dev/null
> > +++ b/drivers/gpu/drm/imx/dcss/Kconfig
> > @@ -0,0 +1,9 @@
> > +config DRM_IMX_DCSS
> > +   tristate "i.MX8MQ DCSS"
> > +   select RESET_CONTROLLER
> > +   select IMX_IRQSTEER
> > +   select DRM_KMS_CMA_HELPER
> > +   depends on DRM && ARCH_MXC
> > +   help
> > + Choose this if you have a NXP i.MX8MQ based system and want to use the
> > + Display Controller Subsystem. This option enables DCSS support.
> > diff --git a/drivers/gpu/drm/imx/dcss/Makefile 
> > b/drivers/gpu/drm/imx/dcss/Makefile
> > new file mode 100644
> > index ..8c7c8da42792
> > --- /dev/null
> > +++ b/drivers/gpu/drm/imx/dcss/Makefile
> > @@ -0,0 +1,6 @@
> > +imx-dcss-objs := dcss-drv.o dcss-dev.o dcss-blkctl.o dcss-ctxld.o 
> > dcss-dtg.o \
> > +dcss-ss.o dcss-dpr.o dcss-scaler.o dcss-kms.o 
> > dcss-crtc.o \
> > +dcss-plane.o
> > +
> > +obj-$(CONFIG_DRM_IMX_DCSS) += imx-dcss.o
> > +
> > diff --git a/drivers/gpu/drm/imx/dcss/dcss-blkctl.c 
> > b/drivers/gpu/drm/imx/dcss/dcss-blkctl.c
> > new file mode 100644
> > index ..0276917f409f
> > --- /dev/null
> > +++ 

Re: [PATCH] drm/etnaviv: fix perfmon domain interation

2020-05-15 Thread Christian Gmeiner
Am Fr., 15. Mai 2020 um 12:33 Uhr schrieb Lucas Stach :
>
> Am Freitag, den 15.05.2020, 12:27 +0200 schrieb Christian Gmeiner:
> > Am Fr., 15. Mai 2020 um 12:24 Uhr schrieb Lucas Stach 
> > :
> > > Am Freitag, den 15.05.2020, 12:12 +0200 schrieb Paul Cercueil:
> > > > Hi Christian,
> > > >
> > > > Le ven. 15 mai 2020 à 12:09, Christian Gmeiner
> > > >  a écrit :
> > > > > Am Mo., 11. Mai 2020 um 14:38 Uhr schrieb Christian Gmeiner
> > > > > :
> > > > > >  The GC860 has one GPU device which has a 2d and 3d core. In this
> > > > > > case
> > > > > >  we want to expose perfmon information for both cores.
> > > > > >
> > > > > >  The driver has one array which contains all possible perfmon 
> > > > > > domains
> > > > > >  with some meta data - doms_meta. Here we can see that for the GC860
> > > > > >  two elements of that array are relevant:
> > > > > >
> > > > > >doms_3d: is at index 0 in the doms_meta array with 8 perfmon
> > > > > > domains
> > > > > >doms_2d: is at index 1 in the doms_meta array with 1 perfmon
> > > > > > domain
> > > > > >
> > > > > >  The userspace driver wants to get a list of all perfmon domains and
> > > > > >  their perfmon signals. This is done by iterating over all domains
> > > > > > and
> > > > > >  their signals. If the userspace driver wants to access the domain
> > > > > > with
> > > > > >  id 8 the kernel driver fails and returns invalid data from doms_3d
> > > > > > with
> > > > > >  and invalid offset.
> > > > > >
> > > > > >  This results in:
> > > > > >Unable to handle kernel paging request at virtual address 
> > > > > > 
> > > > > >
> > > > > >  On such a device it is not possible to use the userspace driver at
> > > > > > all.
> > > > > >
> > > > > >  The fix for this off-by-one error is quite simple.
> > > > > >
> > > > > >  Reported-by: Paul Cercueil 
> > > > > >  Tested-by: Paul Cercueil 
> > > > > >  Fixes: ed1dd899baa3 ("drm/etnaviv: rework perfmon query
> > > > > > infrastructure")
> > > > > >  Cc: sta...@vger.kernel.org
> > > > > >  Signed-off-by: Christian Gmeiner 
> > > > > >  ---
> > > > > >   drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 2 +-
> > > > > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > >
> > > > > >  diff --git a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
> > > > > > b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
> > > > > >  index e6795bafcbb9..35f7171e779a 100644
> > > > > >  --- a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
> > > > > >  +++ b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
> > > > > >  @@ -453,7 +453,7 @@ static const struct etnaviv_pm_domain
> > > > > > *pm_domain(const struct etnaviv_gpu *gpu,
> > > > > >  if (!(gpu->identity.features & meta->feature))
> > > > > >  continue;
> > > > > >
> > > > > >  -   if (meta->nr_domains < (index - offset)) {
> > > > > >  +   if ((meta->nr_domains - 1) < (index - offset)) {
> > > > > >  offset += meta->nr_domains;
> > > > > >  continue;
> > > > > >  }
> > > > > >  --
> > > > > >  2.26.2
> > > > > >
> > > > >
> > > > > ping
> > > >
> > > > I'll merge it tomorrow if there's no further feedback.
> > >
> > > Huh? Etnaviv patches are going through the etnaviv tree.
> > >
> > > We now have two different solutions to the same issue. I first want to
> > > dig into the code to see why two developers can get confused enough by
> > > the code to come up with totally different fixes.
> > >
> >
> > You will see that the solutions are not totally different. I really hoped to
> > get this fixed in the 5.7 release.. but I think its now too late.
>
> I didn't have time to look at the full picture, yet. We still have at
> least a week until the final 5.7 release, why would it be too late to
> get a fix upstream?
>

Great - so I count on you that we will have a fix in 5.7 release.

-- 
greets
--
Christian Gmeiner, MSc

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


Re: [PATCH 10/11] kernel/power: constify sysrq_key_op

2020-05-15 Thread Greg Kroah-Hartman
On Fri, May 15, 2020 at 11:11:57AM +0100, Emil Velikov wrote:
> On Thu, 14 May 2020 at 12:21, Rafael J. Wysocki  wrote:
> >
> > On Wed, May 13, 2020 at 11:46 PM Emil Velikov  
> > wrote:
> > >
> > > With earlier commits, the API no longer discards the const-ness of the
> > > sysrq_key_op. As such we can add the notation.
> > >
> > > Cc: Greg Kroah-Hartman 
> > > Cc: Jiri Slaby 
> > > Cc: linux-ker...@vger.kernel.org
> > > Cc: "Rafael J. Wysocki" 
> > > Cc: Len Brown 
> > > Cc: linux...@vger.kernel.org
> > > Signed-off-by: Emil Velikov 
> >
> > Acked-by: Rafael J. Wysocki 
> >
> Thanks
> 
> > and I'm assuming that this is going to be applied along with the rest
> > of the series.
> >
> I believe so, although I have not heard anything from the TTY maintainers yet.

I will take them all, thanks.

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


Re: [PATCH] drm/etnaviv: fix perfmon domain interation

2020-05-15 Thread Lucas Stach
Am Freitag, den 15.05.2020, 12:27 +0200 schrieb Christian Gmeiner:
> Am Fr., 15. Mai 2020 um 12:24 Uhr schrieb Lucas Stach 
> :
> > Am Freitag, den 15.05.2020, 12:12 +0200 schrieb Paul Cercueil:
> > > Hi Christian,
> > > 
> > > Le ven. 15 mai 2020 à 12:09, Christian Gmeiner
> > >  a écrit :
> > > > Am Mo., 11. Mai 2020 um 14:38 Uhr schrieb Christian Gmeiner
> > > > :
> > > > >  The GC860 has one GPU device which has a 2d and 3d core. In this
> > > > > case
> > > > >  we want to expose perfmon information for both cores.
> > > > > 
> > > > >  The driver has one array which contains all possible perfmon domains
> > > > >  with some meta data - doms_meta. Here we can see that for the GC860
> > > > >  two elements of that array are relevant:
> > > > > 
> > > > >doms_3d: is at index 0 in the doms_meta array with 8 perfmon
> > > > > domains
> > > > >doms_2d: is at index 1 in the doms_meta array with 1 perfmon
> > > > > domain
> > > > > 
> > > > >  The userspace driver wants to get a list of all perfmon domains and
> > > > >  their perfmon signals. This is done by iterating over all domains
> > > > > and
> > > > >  their signals. If the userspace driver wants to access the domain
> > > > > with
> > > > >  id 8 the kernel driver fails and returns invalid data from doms_3d
> > > > > with
> > > > >  and invalid offset.
> > > > > 
> > > > >  This results in:
> > > > >Unable to handle kernel paging request at virtual address 
> > > > > 
> > > > >  On such a device it is not possible to use the userspace driver at
> > > > > all.
> > > > > 
> > > > >  The fix for this off-by-one error is quite simple.
> > > > > 
> > > > >  Reported-by: Paul Cercueil 
> > > > >  Tested-by: Paul Cercueil 
> > > > >  Fixes: ed1dd899baa3 ("drm/etnaviv: rework perfmon query
> > > > > infrastructure")
> > > > >  Cc: sta...@vger.kernel.org
> > > > >  Signed-off-by: Christian Gmeiner 
> > > > >  ---
> > > > >   drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 2 +-
> > > > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > 
> > > > >  diff --git a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
> > > > > b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
> > > > >  index e6795bafcbb9..35f7171e779a 100644
> > > > >  --- a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
> > > > >  +++ b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
> > > > >  @@ -453,7 +453,7 @@ static const struct etnaviv_pm_domain
> > > > > *pm_domain(const struct etnaviv_gpu *gpu,
> > > > >  if (!(gpu->identity.features & meta->feature))
> > > > >  continue;
> > > > > 
> > > > >  -   if (meta->nr_domains < (index - offset)) {
> > > > >  +   if ((meta->nr_domains - 1) < (index - offset)) {
> > > > >  offset += meta->nr_domains;
> > > > >  continue;
> > > > >  }
> > > > >  --
> > > > >  2.26.2
> > > > > 
> > > > 
> > > > ping
> > > 
> > > I'll merge it tomorrow if there's no further feedback.
> > 
> > Huh? Etnaviv patches are going through the etnaviv tree.
> > 
> > We now have two different solutions to the same issue. I first want to
> > dig into the code to see why two developers can get confused enough by
> > the code to come up with totally different fixes.
> > 
> 
> You will see that the solutions are not totally different. I really hoped to
> get this fixed in the 5.7 release.. but I think its now too late.

I didn't have time to look at the full picture, yet. We still have at
least a week until the final 5.7 release, why would it be too late to
get a fix upstream?

Regards,
Lucas

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


Re: [PATCH] drm/etnaviv: fix perfmon domain interation

2020-05-15 Thread Christian Gmeiner
Am Fr., 15. Mai 2020 um 12:24 Uhr schrieb Lucas Stach :
>
> Am Freitag, den 15.05.2020, 12:12 +0200 schrieb Paul Cercueil:
> > Hi Christian,
> >
> > Le ven. 15 mai 2020 à 12:09, Christian Gmeiner
> >  a écrit :
> > > Am Mo., 11. Mai 2020 um 14:38 Uhr schrieb Christian Gmeiner
> > > :
> > > >  The GC860 has one GPU device which has a 2d and 3d core. In this
> > > > case
> > > >  we want to expose perfmon information for both cores.
> > > >
> > > >  The driver has one array which contains all possible perfmon domains
> > > >  with some meta data - doms_meta. Here we can see that for the GC860
> > > >  two elements of that array are relevant:
> > > >
> > > >doms_3d: is at index 0 in the doms_meta array with 8 perfmon
> > > > domains
> > > >doms_2d: is at index 1 in the doms_meta array with 1 perfmon
> > > > domain
> > > >
> > > >  The userspace driver wants to get a list of all perfmon domains and
> > > >  their perfmon signals. This is done by iterating over all domains
> > > > and
> > > >  their signals. If the userspace driver wants to access the domain
> > > > with
> > > >  id 8 the kernel driver fails and returns invalid data from doms_3d
> > > > with
> > > >  and invalid offset.
> > > >
> > > >  This results in:
> > > >Unable to handle kernel paging request at virtual address 
> > > >
> > > >  On such a device it is not possible to use the userspace driver at
> > > > all.
> > > >
> > > >  The fix for this off-by-one error is quite simple.
> > > >
> > > >  Reported-by: Paul Cercueil 
> > > >  Tested-by: Paul Cercueil 
> > > >  Fixes: ed1dd899baa3 ("drm/etnaviv: rework perfmon query
> > > > infrastructure")
> > > >  Cc: sta...@vger.kernel.org
> > > >  Signed-off-by: Christian Gmeiner 
> > > >  ---
> > > >   drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 2 +-
> > > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > >  diff --git a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
> > > > b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
> > > >  index e6795bafcbb9..35f7171e779a 100644
> > > >  --- a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
> > > >  +++ b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
> > > >  @@ -453,7 +453,7 @@ static const struct etnaviv_pm_domain
> > > > *pm_domain(const struct etnaviv_gpu *gpu,
> > > >  if (!(gpu->identity.features & meta->feature))
> > > >  continue;
> > > >
> > > >  -   if (meta->nr_domains < (index - offset)) {
> > > >  +   if ((meta->nr_domains - 1) < (index - offset)) {
> > > >  offset += meta->nr_domains;
> > > >  continue;
> > > >  }
> > > >  --
> > > >  2.26.2
> > > >
> > >
> > > ping
> >
> > I'll merge it tomorrow if there's no further feedback.
>
> Huh? Etnaviv patches are going through the etnaviv tree.
>
> We now have two different solutions to the same issue. I first want to
> dig into the code to see why two developers can get confused enough by
> the code to come up with totally different fixes.
>

You will see that the solutions are not totally different. I really hoped to
get this fixed in the 5.7 release.. but I think its now too late.

-- 
greets
--
Christian Gmeiner, MSc

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


Re: [PATCH] drm/etnaviv: fix perfmon domain interation

2020-05-15 Thread Christian Gmeiner
Hi Paul

Am Fr., 15. Mai 2020 um 12:12 Uhr schrieb Paul Cercueil :
>
> Hi Christian,
>
> Le ven. 15 mai 2020 à 12:09, Christian Gmeiner
>  a écrit :
> > Am Mo., 11. Mai 2020 um 14:38 Uhr schrieb Christian Gmeiner
> > :
> >>
> >>  The GC860 has one GPU device which has a 2d and 3d core. In this
> >> case
> >>  we want to expose perfmon information for both cores.
> >>
> >>  The driver has one array which contains all possible perfmon domains
> >>  with some meta data - doms_meta. Here we can see that for the GC860
> >>  two elements of that array are relevant:
> >>
> >>doms_3d: is at index 0 in the doms_meta array with 8 perfmon
> >> domains
> >>doms_2d: is at index 1 in the doms_meta array with 1 perfmon
> >> domain
> >>
> >>  The userspace driver wants to get a list of all perfmon domains and
> >>  their perfmon signals. This is done by iterating over all domains
> >> and
> >>  their signals. If the userspace driver wants to access the domain
> >> with
> >>  id 8 the kernel driver fails and returns invalid data from doms_3d
> >> with
> >>  and invalid offset.
> >>
> >>  This results in:
> >>Unable to handle kernel paging request at virtual address 
> >>
> >>  On such a device it is not possible to use the userspace driver at
> >> all.
> >>
> >>  The fix for this off-by-one error is quite simple.
> >>
> >>  Reported-by: Paul Cercueil 
> >>  Tested-by: Paul Cercueil 
> >>  Fixes: ed1dd899baa3 ("drm/etnaviv: rework perfmon query
> >> infrastructure")
> >>  Cc: sta...@vger.kernel.org
> >>  Signed-off-by: Christian Gmeiner 
> >>  ---
> >>   drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 2 +-
> >>   1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >>  diff --git a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
> >> b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
> >>  index e6795bafcbb9..35f7171e779a 100644
> >>  --- a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
> >>  +++ b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
> >>  @@ -453,7 +453,7 @@ static const struct etnaviv_pm_domain
> >> *pm_domain(const struct etnaviv_gpu *gpu,
> >>  if (!(gpu->identity.features & meta->feature))
> >>  continue;
> >>
> >>  -   if (meta->nr_domains < (index - offset)) {
> >>  +   if ((meta->nr_domains - 1) < (index - offset)) {
> >>  offset += meta->nr_domains;
> >>  continue;
> >>  }
> >>  --
> >>  2.26.2
> >>
> >
> > ping
>
> I'll merge it tomorrow if there's no further feedback.
>

Works for me too.. as far as Lucas (the maintainer) is happy with it.

-- 
greets
--
Christian Gmeiner, MSc

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


Re: [PATCH] drm/etnaviv: fix perfmon domain interation

2020-05-15 Thread Lucas Stach
Am Freitag, den 15.05.2020, 12:12 +0200 schrieb Paul Cercueil:
> Hi Christian,
> 
> Le ven. 15 mai 2020 à 12:09, Christian Gmeiner 
>  a écrit :
> > Am Mo., 11. Mai 2020 um 14:38 Uhr schrieb Christian Gmeiner
> > :
> > >  The GC860 has one GPU device which has a 2d and 3d core. In this 
> > > case
> > >  we want to expose perfmon information for both cores.
> > > 
> > >  The driver has one array which contains all possible perfmon domains
> > >  with some meta data - doms_meta. Here we can see that for the GC860
> > >  two elements of that array are relevant:
> > > 
> > >doms_3d: is at index 0 in the doms_meta array with 8 perfmon 
> > > domains
> > >doms_2d: is at index 1 in the doms_meta array with 1 perfmon 
> > > domain
> > > 
> > >  The userspace driver wants to get a list of all perfmon domains and
> > >  their perfmon signals. This is done by iterating over all domains 
> > > and
> > >  their signals. If the userspace driver wants to access the domain 
> > > with
> > >  id 8 the kernel driver fails and returns invalid data from doms_3d 
> > > with
> > >  and invalid offset.
> > > 
> > >  This results in:
> > >Unable to handle kernel paging request at virtual address 
> > > 
> > >  On such a device it is not possible to use the userspace driver at 
> > > all.
> > > 
> > >  The fix for this off-by-one error is quite simple.
> > > 
> > >  Reported-by: Paul Cercueil 
> > >  Tested-by: Paul Cercueil 
> > >  Fixes: ed1dd899baa3 ("drm/etnaviv: rework perfmon query 
> > > infrastructure")
> > >  Cc: sta...@vger.kernel.org
> > >  Signed-off-by: Christian Gmeiner 
> > >  ---
> > >   drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 2 +-
> > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > >  diff --git a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c 
> > > b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
> > >  index e6795bafcbb9..35f7171e779a 100644
> > >  --- a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
> > >  +++ b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
> > >  @@ -453,7 +453,7 @@ static const struct etnaviv_pm_domain 
> > > *pm_domain(const struct etnaviv_gpu *gpu,
> > >  if (!(gpu->identity.features & meta->feature))
> > >  continue;
> > > 
> > >  -   if (meta->nr_domains < (index - offset)) {
> > >  +   if ((meta->nr_domains - 1) < (index - offset)) {
> > >  offset += meta->nr_domains;
> > >  continue;
> > >  }
> > >  --
> > >  2.26.2
> > > 
> > 
> > ping
> 
> I'll merge it tomorrow if there's no further feedback.

Huh? Etnaviv patches are going through the etnaviv tree.

We now have two different solutions to the same issue. I first want to
dig into the code to see why two developers can get confused enough by
the code to come up with totally different fixes.

Regards,
Lucas

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


Re: [PATCH v2 30/38] drm/rockchip: remove _unlocked suffix in drm_object_put_unlocked

2020-05-15 Thread Heiko Stübner
Am Freitag, 15. Mai 2020, 11:51:10 CEST schrieb Emil Velikov:
> From: Emil Velikov 
> 
> Spelling out _unlocked for each and every driver is a annoying.
> Especially if we consider how many drivers, do not know (or need to)
> about the horror stories involving struct_mutex.
> 
> Just drop the suffix. It makes the API cleaner.
> 
> Done via the following script:
> 
> __from=drm_gem_object_put_unlocked
> __to=drm_gem_object_put
> for __file in $(git grep --name-only $__from); do
>   sed -i  "s/$__from/$__to/g" $__file;
> done
> 
> Cc: Sandy Huang 
> Cc: "Heiko Stübner" 
> Cc: David Airlie 
> Signed-off-by: Emil Velikov 
> Acked-by: Sam Ravnborg 

Acked-by: Heiko Stuebner 



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


Re: [PATCH v2 28/38] drm/qxl: remove _unlocked suffix in drm_object_put_unlocked

2020-05-15 Thread Gerd Hoffmann
On Fri, May 15, 2020 at 10:51:08AM +0100, Emil Velikov wrote:
> From: Emil Velikov 
> 
> Spelling out _unlocked for each and every driver is a annoying.
> Especially if we consider how many drivers, do not know (or need to)
> about the horror stories involving struct_mutex.
> 
> Just drop the suffix. It makes the API cleaner.

Acked-by: Gerd Hoffmann 

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


Re: [PATCH v2 35/38] drm/virtio: remove _unlocked suffix in drm_object_put_unlocked

2020-05-15 Thread Gerd Hoffmann
On Fri, May 15, 2020 at 10:51:15AM +0100, Emil Velikov wrote:
> From: Emil Velikov 
> 
> Spelling out _unlocked for each and every driver is a annoying.
> Especially if we consider how many drivers, do not know (or need to)
> about the horror stories involving struct_mutex.
> 
> Just drop the suffix. It makes the API cleaner.

Acked-by: Gerd Hoffmann 

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


Re: [PATCH 10/11] kernel/power: constify sysrq_key_op

2020-05-15 Thread Emil Velikov
On Thu, 14 May 2020 at 12:21, Rafael J. Wysocki  wrote:
>
> On Wed, May 13, 2020 at 11:46 PM Emil Velikov  
> wrote:
> >
> > With earlier commits, the API no longer discards the const-ness of the
> > sysrq_key_op. As such we can add the notation.
> >
> > Cc: Greg Kroah-Hartman 
> > Cc: Jiri Slaby 
> > Cc: linux-ker...@vger.kernel.org
> > Cc: "Rafael J. Wysocki" 
> > Cc: Len Brown 
> > Cc: linux...@vger.kernel.org
> > Signed-off-by: Emil Velikov 
>
> Acked-by: Rafael J. Wysocki 
>
Thanks

> and I'm assuming that this is going to be applied along with the rest
> of the series.
>
I believe so, although I have not heard anything from the TTY maintainers yet.

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


Re: [PATCH v5 30/38] dmabuf: fix common struct sg_table related issues

2020-05-15 Thread Gerd Hoffmann
> diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
> index acb26c6..89e293b 100644
> --- a/drivers/dma-buf/udmabuf.c
> +++ b/drivers/dma-buf/udmabuf.c
> @@ -63,10 +63,9 @@ static struct sg_table *get_sg_table(struct device *dev, 
> struct dma_buf *buf,
>   GFP_KERNEL);
>   if (ret < 0)
>   goto err;
> - if (!dma_map_sg(dev, sg->sgl, sg->nents, direction)) {
> - ret = -EINVAL;
> + ret = dma_map_sgtable(dev, sg, direction, 0);
> + if (ret < 0)
>   goto err;
> - }
>   return sg;
>  
>  err:
> @@ -78,7 +77,7 @@ static struct sg_table *get_sg_table(struct device *dev, 
> struct dma_buf *buf,
>  static void put_sg_table(struct device *dev, struct sg_table *sg,
>enum dma_data_direction direction)
>  {
> - dma_unmap_sg(dev, sg->sgl, sg->nents, direction);
> + dma_unmap_sgtable(dev, sg, direction, 0);
>   sg_free_table(sg);
>   kfree(sg);
>  }

Easy straightforward conversation.

Acked-by: Gerd Hoffmann 

take care,
  Gerd

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


Re: [PATCH v5 25/38] drm: virtio: fix common struct sg_table related issues

2020-05-15 Thread Gerd Hoffmann
On Wed, May 13, 2020 at 03:32:32PM +0200, Marek Szyprowski wrote:
> The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
> returns the number of the created entries in the DMA address space.
> However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
> dma_unmap_sg must be called with the original number of the entries
> passed to the dma_map_sg().
> 
> struct sg_table is a common structure used for describing a non-contiguous
> memory buffer, used commonly in the DRM and graphics subsystems. It
> consists of a scatterlist with memory pages and DMA addresses (sgl entry),
> as well as the number of scatterlist entries: CPU pages (orig_nents entry)
> and DMA mapped pages (nents entry).
> 
> It turned out that it was a common mistake to misuse nents and orig_nents
> entries, calling DMA-mapping functions with a wrong number of entries or
> ignoring the number of mapped entries returned by the dma_map_sg()
> function.
> 
> To avoid such issues, lets use a common dma-mapping wrappers operating
> directly on the struct sg_table objects and use scatterlist page
> iterators where possible. This, almost always, hides references to the
> nents and orig_nents entries, making the code robust, easier to follow
> and copy/paste safe.

Looks all sane.

Acked-by: Gerd Hoffmann 

take care,
  Gerd

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


Re: [PATCH] drm/etnaviv: fix perfmon domain interation

2020-05-15 Thread Christian Gmeiner
Am Mo., 11. Mai 2020 um 14:38 Uhr schrieb Christian Gmeiner
:
>
> The GC860 has one GPU device which has a 2d and 3d core. In this case
> we want to expose perfmon information for both cores.
>
> The driver has one array which contains all possible perfmon domains
> with some meta data - doms_meta. Here we can see that for the GC860
> two elements of that array are relevant:
>
>   doms_3d: is at index 0 in the doms_meta array with 8 perfmon domains
>   doms_2d: is at index 1 in the doms_meta array with 1 perfmon domain
>
> The userspace driver wants to get a list of all perfmon domains and
> their perfmon signals. This is done by iterating over all domains and
> their signals. If the userspace driver wants to access the domain with
> id 8 the kernel driver fails and returns invalid data from doms_3d with
> and invalid offset.
>
> This results in:
>   Unable to handle kernel paging request at virtual address 
>
> On such a device it is not possible to use the userspace driver at all.
>
> The fix for this off-by-one error is quite simple.
>
> Reported-by: Paul Cercueil 
> Tested-by: Paul Cercueil 
> Fixes: ed1dd899baa3 ("drm/etnaviv: rework perfmon query infrastructure")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Christian Gmeiner 
> ---
>  drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c 
> b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
> index e6795bafcbb9..35f7171e779a 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
> @@ -453,7 +453,7 @@ static const struct etnaviv_pm_domain *pm_domain(const 
> struct etnaviv_gpu *gpu,
> if (!(gpu->identity.features & meta->feature))
> continue;
>
> -   if (meta->nr_domains < (index - offset)) {
> +   if ((meta->nr_domains - 1) < (index - offset)) {
> offset += meta->nr_domains;
> continue;
> }
> --
> 2.26.2
>

ping

-- 
greets
--
Christian Gmeiner, MSc

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


[PATCH v2 14/38] drm/amd: remove _unlocked suffix in drm_object_put_unlocked

2020-05-15 Thread Emil Velikov
From: Emil Velikov 

Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.

Just drop the suffix. It makes the API cleaner.

Done via the following script:

__from=drm_gem_object_put_unlocked
__to=drm_gem_object_put
for __file in $(git grep --name-only $__from); do
  sed -i  "s/$__from/$__to/g" $__file;
done

Cc: Alex Deucher 
Cc: "Christian König" 
Cc: "David (ChunMing) Zhou" 
Signed-off-by: Emil Velikov 
Acked-by: Sam Ravnborg 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c |  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c  |  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c |  4 ++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c |  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c  |  4 ++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 20 ++--
 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c  |  6 +++---
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c  |  6 +++---
 drivers/gpu/drm/amd/amdgpu/dce_v6_0.c   |  6 +++---
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c   |  6 +++---
 10 files changed, 29 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c
index 85b0515c0fdc..4053597b3af2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c
@@ -102,7 +102,7 @@ int amdgpu_bo_list_create(struct amdgpu_device *adev, 
struct drm_file *filp,
}
 
bo = amdgpu_bo_ref(gem_to_amdgpu_bo(gobj));
-   drm_gem_object_put_unlocked(gobj);
+   drm_gem_object_put(gobj);
 
usermm = amdgpu_ttm_tt_get_usermm(bo->tbo.ttm);
if (usermm) {
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index af91627b19b0..76ea245f2106 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -57,7 +57,7 @@ static int amdgpu_cs_user_fence_chunk(struct amdgpu_cs_parser 
*p,
/* One for TTM and one for the CS job */
p->uf_entry.tv.num_shared = 2;
 
-   drm_gem_object_put_unlocked(gobj);
+   drm_gem_object_put(gobj);
 
size = amdgpu_bo_size(bo);
if (size != PAGE_SIZE || (data->offset + 8) > size) {
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index 84cee27cd7ef..de9b62e2800a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -575,14 +575,14 @@ amdgpu_display_user_framebuffer_create(struct drm_device 
*dev,
 
amdgpu_fb = kzalloc(sizeof(*amdgpu_fb), GFP_KERNEL);
if (amdgpu_fb == NULL) {
-   drm_gem_object_put_unlocked(obj);
+   drm_gem_object_put(obj);
return ERR_PTR(-ENOMEM);
}
 
ret = amdgpu_display_framebuffer_init(dev, amdgpu_fb, mode_cmd, obj);
if (ret) {
kfree(amdgpu_fb);
-   drm_gem_object_put_unlocked(obj);
+   drm_gem_object_put(obj);
return ERR_PTR(ret);
}
 
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
index 652c57a3b847..43d8ed7dbd00 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
@@ -587,7 +587,7 @@ struct drm_gem_object *amdgpu_gem_prime_import(struct 
drm_device *dev,
attach = dma_buf_dynamic_attach(dma_buf, dev->dev,
_dma_buf_attach_ops, obj);
if (IS_ERR(attach)) {
-   drm_gem_object_put_unlocked(obj);
+   drm_gem_object_put(obj);
return ERR_CAST(attach);
}
 
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
index 9ae7b61f696a..ca5dde4ec47d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
@@ -114,7 +114,7 @@ static void amdgpufb_destroy_pinned_object(struct 
drm_gem_object *gobj)
amdgpu_bo_unpin(abo);
amdgpu_bo_unreserve(abo);
}
-   drm_gem_object_put_unlocked(gobj);
+   drm_gem_object_put(gobj);
 }
 
 static int amdgpufb_create_pinned_object(struct amdgpu_fbdev *rfbdev,
@@ -279,7 +279,7 @@ static int amdgpufb_create(struct drm_fb_helper *helper,
 
}
if (fb && ret) {
-   drm_gem_object_put_unlocked(gobj);
+   drm_gem_object_put(gobj);
drm_framebuffer_unregister_private(fb);
drm_framebuffer_cleanup(fb);
kfree(fb);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index e42608115c99..8c0597f306ec 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -106,7 +106,7 @@ void 

[PATCH v2 21/38] drm/lima: remove _unlocked suffix in drm_object_put_unlocked

2020-05-15 Thread Emil Velikov
From: Emil Velikov 

Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.

Just drop the suffix. It makes the API cleaner.

Done via the following script:

__from=drm_gem_object_put_unlocked
__to=drm_gem_object_put
for __file in $(git grep --name-only $__from); do
  sed -i  "s/$__from/$__to/g" $__file;
done

Cc: Qiang Yu 
Cc: David Airlie 
Cc: Daniel Vetter 
Signed-off-by: Emil Velikov 
Acked-by: Sam Ravnborg 
---
 drivers/gpu/drm/lima/lima_gem.c   | 10 +-
 drivers/gpu/drm/lima/lima_sched.c |  2 +-
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/lima/lima_gem.c b/drivers/gpu/drm/lima/lima_gem.c
index 5404e0d668db..155f2b4b4030 100644
--- a/drivers/gpu/drm/lima/lima_gem.c
+++ b/drivers/gpu/drm/lima/lima_gem.c
@@ -134,7 +134,7 @@ int lima_gem_create_handle(struct drm_device *dev, struct 
drm_file *file,
 
 out:
/* drop reference from allocate - handle holds it now */
-   drm_gem_object_put_unlocked(obj);
+   drm_gem_object_put(obj);
 
return err;
 }
@@ -243,7 +243,7 @@ int lima_gem_get_info(struct drm_file *file, u32 handle, 
u32 *va, u64 *offset)
 
*offset = drm_vma_node_offset_addr(>vma_node);
 
-   drm_gem_object_put_unlocked(obj);
+   drm_gem_object_put(obj);
return 0;
 }
 
@@ -323,7 +323,7 @@ int lima_gem_submit(struct drm_file *file, struct 
lima_submit *submit)
 */
err = lima_vm_bo_add(vm, bo, false);
if (err) {
-   drm_gem_object_put_unlocked(obj);
+   drm_gem_object_put(obj);
goto err_out0;
}
 
@@ -368,7 +368,7 @@ int lima_gem_submit(struct drm_file *file, struct 
lima_submit *submit)
submit->nr_bos, );
 
for (i = 0; i < submit->nr_bos; i++)
-   drm_gem_object_put_unlocked([i]->base.base);
+   drm_gem_object_put([i]->base.base);
 
if (out_sync) {
drm_syncobj_replace_fence(out_sync, fence);
@@ -389,7 +389,7 @@ int lima_gem_submit(struct drm_file *file, struct 
lima_submit *submit)
if (!bos[i])
break;
lima_vm_bo_del(vm, bos[i]);
-   drm_gem_object_put_unlocked([i]->base.base);
+   drm_gem_object_put([i]->base.base);
}
if (out_sync)
drm_syncobj_put(out_sync);
diff --git a/drivers/gpu/drm/lima/lima_sched.c 
b/drivers/gpu/drm/lima/lima_sched.c
index e6cefda00279..64ced6d0e6cf 100644
--- a/drivers/gpu/drm/lima/lima_sched.c
+++ b/drivers/gpu/drm/lima/lima_sched.c
@@ -151,7 +151,7 @@ void lima_sched_task_fini(struct lima_sched_task *task)
 
if (task->bos) {
for (i = 0; i < task->num_bos; i++)
-   drm_gem_object_put_unlocked(>bos[i]->base.base);
+   drm_gem_object_put(>bos[i]->base.base);
kfree(task->bos);
}
 
-- 
2.25.1

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


[PATCH v2 26/38] drm/omapdrm: remove _unlocked suffix in drm_object_put_unlocked

2020-05-15 Thread Emil Velikov
From: Emil Velikov 

Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.

Just drop the suffix. It makes the API cleaner.

Done via the following script:

__from=drm_gem_object_put_unlocked
__to=drm_gem_object_put
for __file in $(git grep --name-only $__from); do
  sed -i  "s/$__from/$__to/g" $__file;
done

Cc: Tomi Valkeinen 
Cc: David Airlie 
Cc: Daniel Vetter 
Signed-off-by: Emil Velikov 
Acked-by: Sam Ravnborg 
---
 drivers/gpu/drm/omapdrm/omap_drv.c   | 2 +-
 drivers/gpu/drm/omapdrm/omap_fb.c| 2 +-
 drivers/gpu/drm/omapdrm/omap_fbdev.c | 2 +-
 drivers/gpu/drm/omapdrm/omap_gem.c   | 4 ++--
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c 
b/drivers/gpu/drm/omapdrm/omap_drv.c
index cdafd7ef1c32..242d28281784 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -503,7 +503,7 @@ static int ioctl_gem_info(struct drm_device *dev, void 
*data,
args->size = omap_gem_mmap_size(obj);
args->offset = omap_gem_mmap_offset(obj);
 
-   drm_gem_object_put_unlocked(obj);
+   drm_gem_object_put(obj);
 
return ret;
 }
diff --git a/drivers/gpu/drm/omapdrm/omap_fb.c 
b/drivers/gpu/drm/omapdrm/omap_fb.c
index 9aeab81dfb90..05f30e2618c9 100644
--- a/drivers/gpu/drm/omapdrm/omap_fb.c
+++ b/drivers/gpu/drm/omapdrm/omap_fb.c
@@ -326,7 +326,7 @@ struct drm_framebuffer *omap_framebuffer_create(struct 
drm_device *dev,
 
 error:
while (--i >= 0)
-   drm_gem_object_put_unlocked(bos[i]);
+   drm_gem_object_put(bos[i]);
 
return fb;
 }
diff --git a/drivers/gpu/drm/omapdrm/omap_fbdev.c 
b/drivers/gpu/drm/omapdrm/omap_fbdev.c
index 09a84919ef73..3f6cfc24fb64 100644
--- a/drivers/gpu/drm/omapdrm/omap_fbdev.c
+++ b/drivers/gpu/drm/omapdrm/omap_fbdev.c
@@ -140,7 +140,7 @@ static int omap_fbdev_create(struct drm_fb_helper *helper,
/* note: if fb creation failed, we can't rely on fb destroy
 * to unref the bo:
 */
-   drm_gem_object_put_unlocked(fbdev->bo);
+   drm_gem_object_put(fbdev->bo);
ret = PTR_ERR(fb);
goto fail;
}
diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c 
b/drivers/gpu/drm/omapdrm/omap_gem.c
index d08ae95ecc0a..d0d12d5dd76c 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem.c
@@ -629,7 +629,7 @@ int omap_gem_dumb_map_offset(struct drm_file *file, struct 
drm_device *dev,
 
*offset = omap_gem_mmap_offset(obj);
 
-   drm_gem_object_put_unlocked(obj);
+   drm_gem_object_put(obj);
 
 fail:
return ret;
@@ -1348,7 +1348,7 @@ int omap_gem_new_handle(struct drm_device *dev, struct 
drm_file *file,
}
 
/* drop reference from allocate - handle holds it now */
-   drm_gem_object_put_unlocked(obj);
+   drm_gem_object_put(obj);
 
return 0;
 }
-- 
2.25.1

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


[PATCH v2 13/38] drm: remove _unlocked suffix in drm_object_put_unlocked

2020-05-15 Thread Emil Velikov
From: Emil Velikov 

Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.

Just drop the suffix. It makes the API cleaner.

Done via the following script:

__from=drm_gem_object_put_unlocked
__to=drm_gem_object_put
for __file in $(git grep --name-only $__from); do
  sed -i  "s/$__from/$__to/g" $__file;
done

Pay special attention to the compat #define

v2: keep sed and #define removal separate

Cc: David Airlie 
Cc: Daniel Vetter 
Signed-off-by: Emil Velikov 
Acked-by: Sam Ravnborg  (v1)
---
 Documentation/gpu/drm-mm.rst |  2 +-
 drivers/gpu/drm/drm_client.c |  2 +-
 drivers/gpu/drm/drm_gem.c| 26 ++--
 drivers/gpu/drm/drm_gem_cma_helper.c |  8 +++---
 drivers/gpu/drm/drm_gem_framebuffer_helper.c |  6 ++---
 drivers/gpu/drm/drm_gem_shmem_helper.c   |  4 +--
 drivers/gpu/drm/drm_gem_ttm_helper.c |  2 +-
 drivers/gpu/drm/drm_gem_vram_helper.c| 10 
 drivers/gpu/drm/drm_prime.c  |  6 ++---
 include/drm/drm_gem.h|  2 +-
 10 files changed, 34 insertions(+), 34 deletions(-)

diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
index 5ba2ead8f317..8c8540ee859c 100644
--- a/Documentation/gpu/drm-mm.rst
+++ b/Documentation/gpu/drm-mm.rst
@@ -178,7 +178,7 @@ GEM Objects Lifetime
 
 
 All GEM objects are reference-counted by the GEM core. References can be
-acquired and release by calling drm_gem_object_get() and 
drm_gem_object_put_unlocked()
+acquired and release by calling drm_gem_object_get() and drm_gem_object_put()
 respectively.
 
 When the last reference to a GEM object is released the GEM core calls
diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
index 8cb93f5209a4..536a22747b51 100644
--- a/drivers/gpu/drm/drm_client.c
+++ b/drivers/gpu/drm/drm_client.c
@@ -237,7 +237,7 @@ static void drm_client_buffer_delete(struct 
drm_client_buffer *buffer)
drm_gem_vunmap(buffer->gem, buffer->vaddr);
 
if (buffer->gem)
-   drm_gem_object_put_unlocked(buffer->gem);
+   drm_gem_object_put(buffer->gem);
 
if (buffer->handle)
drm_mode_destroy_dumb(dev, buffer->handle, 
buffer->client->file);
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index f21327ebc562..ae02b3842c90 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -235,7 +235,7 @@ drm_gem_object_handle_put_unlocked(struct drm_gem_object 
*obj)
mutex_unlock(>object_name_lock);
 
if (final)
-   drm_gem_object_put_unlocked(obj);
+   drm_gem_object_put(obj);
 }
 
 /*
@@ -331,7 +331,7 @@ int drm_gem_dumb_map_offset(struct drm_file *file, struct 
drm_device *dev,
 
*offset = drm_vma_node_offset_addr(>vma_node);
 out:
-   drm_gem_object_put_unlocked(obj);
+   drm_gem_object_put(obj);
 
return ret;
 }
@@ -690,7 +690,7 @@ static int objects_lookup(struct drm_file *filp, u32 
*handle, int count,
  * Returns:
  *
  * @objs filled in with GEM object pointers. Returned GEM objects need to be
- * released with drm_gem_object_put_unlocked(). -ENOENT is returned on a lookup
+ * released with drm_gem_object_put(). -ENOENT is returned on a lookup
  * failure. 0 is returned on success.
  *
  */
@@ -785,7 +785,7 @@ long drm_gem_dma_resv_wait(struct drm_file *filep, u32 
handle,
else if (ret > 0)
ret = 0;
 
-   drm_gem_object_put_unlocked(obj);
+   drm_gem_object_put(obj);
 
return ret;
 }
@@ -860,7 +860,7 @@ drm_gem_flink_ioctl(struct drm_device *dev, void *data,
 
 err:
mutex_unlock(>object_name_lock);
-   drm_gem_object_put_unlocked(obj);
+   drm_gem_object_put(obj);
return ret;
 }
 
@@ -898,7 +898,7 @@ drm_gem_open_ioctl(struct drm_device *dev, void *data,
 
/* drm_gem_handle_create_tail unlocks dev->object_name_lock. */
ret = drm_gem_handle_create_tail(file_priv, obj, );
-   drm_gem_object_put_unlocked(obj);
+   drm_gem_object_put(obj);
if (ret)
return ret;
 
@@ -991,7 +991,7 @@ EXPORT_SYMBOL(drm_gem_object_free);
  * driver doesn't use _device.struct_mutex for anything.
  *
  * For drivers not encumbered with legacy locking use
- * drm_gem_object_put_unlocked() instead.
+ * drm_gem_object_put() instead.
  */
 void
 drm_gem_object_put_locked(struct drm_gem_object *obj)
@@ -1030,7 +1030,7 @@ void drm_gem_vm_close(struct vm_area_struct *vma)
 {
struct drm_gem_object *obj = vma->vm_private_data;
 
-   drm_gem_object_put_unlocked(obj);
+   drm_gem_object_put(obj);
 }
 EXPORT_SYMBOL(drm_gem_vm_close);
 
@@ -1079,7 +1079,7 @@ int drm_gem_mmap_obj(struct drm_gem_object *obj, unsigned 
long obj_size,
if (obj->funcs && obj->funcs->mmap) {
ret = 

[PATCH v2 16/38] drm/armada: remove _unlocked suffix in drm_object_put_unlocked

2020-05-15 Thread Emil Velikov
From: Emil Velikov 

Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.

Just drop the suffix. It makes the API cleaner.

Done via the following script:

__from=drm_gem_object_put_unlocked
__to=drm_gem_object_put
for __file in $(git grep --name-only $__from); do
  sed -i  "s/$__from/$__to/g" $__file;
done

Cc: Russell King 
Cc: David Airlie 
Cc: Daniel Vetter 
Signed-off-by: Emil Velikov 
Acked-by: Sam Ravnborg 
---
 drivers/gpu/drm/armada/armada_crtc.c  |  8 
 drivers/gpu/drm/armada/armada_fb.c|  4 ++--
 drivers/gpu/drm/armada/armada_fbdev.c |  6 +++---
 drivers/gpu/drm/armada/armada_gem.c   | 10 +-
 4 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_crtc.c 
b/drivers/gpu/drm/armada/armada_crtc.c
index c2b92acd1e9a..38dfaa46d306 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -710,13 +710,13 @@ static int armada_drm_crtc_cursor_set(struct drm_crtc 
*crtc,
 
/* Must be a kernel-mapped object */
if (!obj->addr) {
-   drm_gem_object_put_unlocked(>obj);
+   drm_gem_object_put(>obj);
return -EINVAL;
}
 
if (obj->obj.size < w * h * 4) {
DRM_ERROR("buffer is too small\n");
-   drm_gem_object_put_unlocked(>obj);
+   drm_gem_object_put(>obj);
return -ENOMEM;
}
}
@@ -724,7 +724,7 @@ static int armada_drm_crtc_cursor_set(struct drm_crtc *crtc,
if (dcrtc->cursor_obj) {
dcrtc->cursor_obj->update = NULL;
dcrtc->cursor_obj->update_data = NULL;
-   drm_gem_object_put_unlocked(>cursor_obj->obj);
+   drm_gem_object_put(>cursor_obj->obj);
}
dcrtc->cursor_obj = obj;
dcrtc->cursor_w = w;
@@ -760,7 +760,7 @@ static void armada_drm_crtc_destroy(struct drm_crtc *crtc)
struct armada_private *priv = crtc->dev->dev_private;
 
if (dcrtc->cursor_obj)
-   drm_gem_object_put_unlocked(>cursor_obj->obj);
+   drm_gem_object_put(>cursor_obj->obj);
 
priv->dcrtc[dcrtc->num] = NULL;
drm_crtc_cleanup(>crtc);
diff --git a/drivers/gpu/drm/armada/armada_fb.c 
b/drivers/gpu/drm/armada/armada_fb.c
index 426ca383d696..b87c71703c85 100644
--- a/drivers/gpu/drm/armada/armada_fb.c
+++ b/drivers/gpu/drm/armada/armada_fb.c
@@ -129,12 +129,12 @@ struct drm_framebuffer *armada_fb_create(struct 
drm_device *dev,
goto err;
}
 
-   drm_gem_object_put_unlocked(>obj);
+   drm_gem_object_put(>obj);
 
return >fb;
 
  err_unref:
-   drm_gem_object_put_unlocked(>obj);
+   drm_gem_object_put(>obj);
  err:
DRM_ERROR("failed to initialize framebuffer: %d\n", ret);
return ERR_PTR(ret);
diff --git a/drivers/gpu/drm/armada/armada_fbdev.c 
b/drivers/gpu/drm/armada/armada_fbdev.c
index f2dc371bd8e5..0c4601275507 100644
--- a/drivers/gpu/drm/armada/armada_fbdev.c
+++ b/drivers/gpu/drm/armada/armada_fbdev.c
@@ -51,13 +51,13 @@ static int armada_fbdev_create(struct drm_fb_helper *fbh,
 
ret = armada_gem_linear_back(dev, obj);
if (ret) {
-   drm_gem_object_put_unlocked(>obj);
+   drm_gem_object_put(>obj);
return ret;
}
 
ptr = armada_gem_map_object(dev, obj);
if (!ptr) {
-   drm_gem_object_put_unlocked(>obj);
+   drm_gem_object_put(>obj);
return -ENOMEM;
}
 
@@ -67,7 +67,7 @@ static int armada_fbdev_create(struct drm_fb_helper *fbh,
 * A reference is now held by the framebuffer object if
 * successful, otherwise this drops the ref for the error path.
 */
-   drm_gem_object_put_unlocked(>obj);
+   drm_gem_object_put(>obj);
 
if (IS_ERR(dfb))
return PTR_ERR(dfb);
diff --git a/drivers/gpu/drm/armada/armada_gem.c 
b/drivers/gpu/drm/armada/armada_gem.c
index 976685f2939e..8005614d2e6b 100644
--- a/drivers/gpu/drm/armada/armada_gem.c
+++ b/drivers/gpu/drm/armada/armada_gem.c
@@ -256,7 +256,7 @@ int armada_gem_dumb_create(struct drm_file *file, struct 
drm_device *dev,
/* drop reference from allocate - handle holds it now */
DRM_DEBUG_DRIVER("obj %p size %zu handle %#x\n", dobj, size, handle);
  err:
-   drm_gem_object_put_unlocked(>obj);
+   drm_gem_object_put(>obj);
return ret;
 }
 
@@ -288,7 +288,7 @@ int armada_gem_create_ioctl(struct drm_device *dev, void 
*data,
/* drop reference from allocate - handle holds it now */
DRM_DEBUG_DRIVER("obj %p size %zu handle %#x\n", dobj, size, handle);
  err:
-   drm_gem_object_put_unlocked(>obj);
+   drm_gem_object_put(>obj);
  

[PATCH v2 20/38] drm/i915: remove _unlocked suffix in drm_object_put_unlocked

2020-05-15 Thread Emil Velikov
From: Emil Velikov 

Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.

Just drop the suffix. It makes the API cleaner.

Done via the following script:

__from=drm_gem_object_put_unlocked
__to=drm_gem_object_put
for __file in $(git grep --name-only $__from); do
  sed -i  "s/$__from/$__to/g" $__file;
done

Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
Signed-off-by: Emil Velikov 
Acked-by: Sam Ravnborg 
---
 drivers/gpu/drm/i915/gem/i915_gem_object.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 41351cbf31b5..aba7517c2837 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -105,7 +105,7 @@ __attribute__((nonnull))
 static inline void
 i915_gem_object_put(struct drm_i915_gem_object *obj)
 {
-   drm_gem_object_put_unlocked(>base);
+   drm_gem_object_put(>base);
 }
 
 #define assert_object_held(obj) dma_resv_assert_held((obj)->base.resv)
-- 
2.25.1

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


[PATCH v2 10/38] drm/gem: fold drm_gem_object_put_unlocked and __drm_gem_object_put()

2020-05-15 Thread Emil Velikov
From: Emil Velikov 

With earlier patch we removed the overhead so now we can lift the helper
into the header effectively folding it with __drm_object_put.

v2: drop struct_mutex references (Daniel)

Signed-off-by: Emil Velikov 
Acked-by: Sam Ravnborg  (v1)
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_gem.c  | 19 ---
 drivers/gpu/drm/i915/gem/i915_gem_object.h |  2 +-
 include/drm/drm_drv.h  |  2 --
 include/drm/drm_gem.h  | 16 +++-
 4 files changed, 4 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index dab8763b2e73..599d5ff53b73 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -982,25 +982,6 @@ drm_gem_object_free(struct kref *kref)
 }
 EXPORT_SYMBOL(drm_gem_object_free);
 
-/**
- * drm_gem_object_put_unlocked - drop a GEM buffer object reference
- * @obj: GEM buffer object
- *
- * This releases a reference to @obj. Callers must not hold the
- * _device.struct_mutex lock when calling this function.
- *
- * See also __drm_gem_object_put().
- */
-void
-drm_gem_object_put_unlocked(struct drm_gem_object *obj)
-{
-   if (!obj)
-   return;
-
-   kref_put(>refcount, drm_gem_object_free);
-}
-EXPORT_SYMBOL(drm_gem_object_put_unlocked);
-
 /**
  * drm_gem_object_put - release a GEM buffer object reference
  * @obj: GEM buffer object
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 2faa481cc18f..41351cbf31b5 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -105,7 +105,7 @@ __attribute__((nonnull))
 static inline void
 i915_gem_object_put(struct drm_i915_gem_object *obj)
 {
-   __drm_gem_object_put(>base);
+   drm_gem_object_put_unlocked(>base);
 }
 
 #define assert_object_held(obj) dma_resv_assert_held((obj)->base.resv)
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index e6eff508f687..bb924cddc09c 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -332,8 +332,6 @@ struct drm_driver {
 *
 * This is deprecated and should not be used by new drivers. Use
 * _gem_object_funcs.free instead.
-* Compared to @gem_free_object this is not encumbered with
-* _device.struct_mutex legacy locking schemes.
 */
void (*gem_free_object_unlocked) (struct drm_gem_object *obj);
 
diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
index ec2d24a60a76..c3bdade093ae 100644
--- a/include/drm/drm_gem.h
+++ b/include/drm/drm_gem.h
@@ -364,27 +364,17 @@ static inline void drm_gem_object_get(struct 
drm_gem_object *obj)
 }
 
 /**
- * __drm_gem_object_put - raw function to release a GEM buffer object reference
+ * drm_gem_object_put_unlocked - drop a GEM buffer object reference
  * @obj: GEM buffer object
  *
- * This function is meant to be used by drivers which are not encumbered with
- * _device.struct_mutex legacy locking and which are using the
- * gem_free_object_unlocked callback. It avoids all the locking checks and
- * locking overhead of drm_gem_object_put() and drm_gem_object_put_unlocked().
- *
- * Drivers should never call this directly in their code. Instead they should
- * wrap it up into a ``driver_gem_object_put(struct driver_gem_object *obj)``
- * wrapper function, and use that. Shared code should never call this, to
- * avoid breaking drivers by accident which still depend upon
- * _device.struct_mutex locking.
+ * This releases a reference to @obj.
  */
 static inline void
-__drm_gem_object_put(struct drm_gem_object *obj)
+drm_gem_object_put_unlocked(struct drm_gem_object *obj)
 {
kref_put(>refcount, drm_gem_object_free);
 }
 
-void drm_gem_object_put_unlocked(struct drm_gem_object *obj);
 void drm_gem_object_put(struct drm_gem_object *obj);
 
 int drm_gem_handle_create(struct drm_file *file_priv,
-- 
2.25.1

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


[PATCH v2 37/38] drm/xen: remove _unlocked suffix in drm_object_put_unlocked

2020-05-15 Thread Emil Velikov
From: Emil Velikov 

Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.

Just drop the suffix. It makes the API cleaner.

Done via the following script:

__from=drm_gem_object_put_unlocked
__to=drm_gem_object_put
for __file in $(git grep --name-only $__from); do
  sed -i  "s/$__from/$__to/g" $__file;
done

Cc: Oleksandr Andrushchenko 
Cc: David Airlie 
Cc: Daniel Vetter 
Signed-off-by: Emil Velikov 
Acked-by: Sam Ravnborg 
---
 drivers/gpu/drm/xen/xen_drm_front.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/xen/xen_drm_front.c 
b/drivers/gpu/drm/xen/xen_drm_front.c
index 1fd458e877ca..3e660fb111b3 100644
--- a/drivers/gpu/drm/xen/xen_drm_front.c
+++ b/drivers/gpu/drm/xen/xen_drm_front.c
@@ -419,7 +419,7 @@ static int xen_drm_drv_dumb_create(struct drm_file *filp,
goto fail_handle;
 
/* Drop reference from allocate - handle holds it now */
-   drm_gem_object_put_unlocked(obj);
+   drm_gem_object_put(obj);
return 0;
 
 fail_handle:
@@ -427,7 +427,7 @@ static int xen_drm_drv_dumb_create(struct drm_file *filp,
   xen_drm_front_dbuf_to_cookie(obj));
 fail_backend:
/* drop reference from allocate */
-   drm_gem_object_put_unlocked(obj);
+   drm_gem_object_put(obj);
 fail:
DRM_ERROR("Failed to create dumb buffer: %d\n", ret);
return ret;
-- 
2.25.1

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


[PATCH v2 17/38] drm/etnaviv: remove _unlocked suffix in drm_object_put_unlocked

2020-05-15 Thread Emil Velikov
From: Emil Velikov 

Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.

Just drop the suffix. It makes the API cleaner.

Done via the following script:

__from=drm_gem_object_put_unlocked
__to=drm_gem_object_put
for __file in $(git grep --name-only $__from); do
  sed -i  "s/$__from/$__to/g" $__file;
done

Cc: Lucas Stach 
Cc: Russell King 
Cc: Christian Gmeiner 
Signed-off-by: Emil Velikov 
Acked-by: Sam Ravnborg 
---
 drivers/gpu/drm/etnaviv/etnaviv_drv.c| 8 
 drivers/gpu/drm/etnaviv/etnaviv_gem.c| 6 +++---
 drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c  | 2 +-
 drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 2 +-
 4 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c 
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index 27c948f5dfeb..a2b649a8248e 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
@@ -289,7 +289,7 @@ static int etnaviv_ioctl_gem_cpu_prep(struct drm_device 
*dev, void *data,
 
ret = etnaviv_gem_cpu_prep(obj, args->op, >timeout);
 
-   drm_gem_object_put_unlocked(obj);
+   drm_gem_object_put(obj);
 
return ret;
 }
@@ -310,7 +310,7 @@ static int etnaviv_ioctl_gem_cpu_fini(struct drm_device 
*dev, void *data,
 
ret = etnaviv_gem_cpu_fini(obj);
 
-   drm_gem_object_put_unlocked(obj);
+   drm_gem_object_put(obj);
 
return ret;
 }
@@ -330,7 +330,7 @@ static int etnaviv_ioctl_gem_info(struct drm_device *dev, 
void *data,
return -ENOENT;
 
ret = etnaviv_gem_mmap_offset(obj, >offset);
-   drm_gem_object_put_unlocked(obj);
+   drm_gem_object_put(obj);
 
return ret;
 }
@@ -413,7 +413,7 @@ static int etnaviv_ioctl_gem_wait(struct drm_device *dev, 
void *data,
 
ret = etnaviv_gem_wait_bo(gpu, obj, timeout);
 
-   drm_gem_object_put_unlocked(obj);
+   drm_gem_object_put(obj);
 
return ret;
 }
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
index dc9ef302f517..b9bfb50ce7ee 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
@@ -244,7 +244,7 @@ void etnaviv_gem_mapping_unreference(struct 
etnaviv_vram_mapping *mapping)
mapping->use -= 1;
mutex_unlock(_obj->lock);
 
-   drm_gem_object_put_unlocked(_obj->base);
+   drm_gem_object_put(_obj->base);
 }
 
 struct etnaviv_vram_mapping *etnaviv_gem_mapping_get(
@@ -633,7 +633,7 @@ int etnaviv_gem_new_handle(struct drm_device *dev, struct 
drm_file *file,
 
/* drop reference from allocate - handle holds it now */
 fail:
-   drm_gem_object_put_unlocked(obj);
+   drm_gem_object_put(obj);
 
return ret;
 }
@@ -742,6 +742,6 @@ int etnaviv_gem_new_userptr(struct drm_device *dev, struct 
drm_file *file,
ret = drm_gem_handle_create(file, _obj->base, handle);
 
/* drop reference from allocate - handle holds it now */
-   drm_gem_object_put_unlocked(_obj->base);
+   drm_gem_object_put(_obj->base);
return ret;
 }
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
index f24dd21c2363..6d9e5c3c4dd5 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
@@ -136,7 +136,7 @@ struct drm_gem_object 
*etnaviv_gem_prime_import_sg_table(struct drm_device *dev,
return _obj->base;
 
 fail:
-   drm_gem_object_put_unlocked(_obj->base);
+   drm_gem_object_put(_obj->base);
 
return ERR_PTR(ret);
 }
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
index 3b0afa156d92..1b12b57d2406 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
@@ -396,7 +396,7 @@ static void submit_cleanup(struct kref *kref)
 
/* if the GPU submit failed, objects might still be locked */
submit_unlock_object(submit, i);
-   drm_gem_object_put_unlocked(_obj->base);
+   drm_gem_object_put(_obj->base);
}
 
wake_up_all(>gpu->fence_event);
-- 
2.25.1

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


[PATCH v2 18/38] drm/exynos: remove _unlocked suffix in drm_object_put_unlocked

2020-05-15 Thread Emil Velikov
From: Emil Velikov 

Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.

Just drop the suffix. It makes the API cleaner.

Done via the following script:

__from=drm_gem_object_put_unlocked
__to=drm_gem_object_put
for __file in $(git grep --name-only $__from); do
  sed -i  "s/$__from/$__to/g" $__file;
done

Cc: Inki Dae 
Cc: Joonyoung Shim 
Cc: Seung-Woo Kim 
Signed-off-by: Emil Velikov 
Acked-by: Sam Ravnborg 
---
 drivers/gpu/drm/exynos/exynos_drm_gem.c | 4 ++--
 drivers/gpu/drm/exynos/exynos_drm_gem.h | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index d734d9d51762..642a276e869b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -139,7 +139,7 @@ static int exynos_drm_gem_handle_create(struct 
drm_gem_object *obj,
DRM_DEV_DEBUG_KMS(to_dma_dev(obj->dev), "gem handle = 0x%x\n", *handle);
 
/* drop reference from allocate - handle holds it now. */
-   drm_gem_object_put_unlocked(obj);
+   drm_gem_object_put(obj);
 
return 0;
 }
@@ -333,7 +333,7 @@ int exynos_drm_gem_get_ioctl(struct drm_device *dev, void 
*data,
args->flags = exynos_gem->flags;
args->size = exynos_gem->size;
 
-   drm_gem_object_put_unlocked(obj);
+   drm_gem_object_put(obj);
 
return 0;
 }
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.h 
b/drivers/gpu/drm/exynos/exynos_drm_gem.h
index 42ec67bc262d..0e8d2306c08a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.h
@@ -86,7 +86,7 @@ struct exynos_drm_gem *exynos_drm_gem_get(struct drm_file 
*filp,
  */
 static inline void exynos_drm_gem_put(struct exynos_drm_gem *exynos_gem)
 {
-   drm_gem_object_put_unlocked(_gem->base);
+   drm_gem_object_put(_gem->base);
 }
 
 /* get buffer information to memory region allocated by gem. */
-- 
2.25.1

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


[PATCH v2 06/38] drm/doc: drop struct_mutex reference for drm_gem_object_free

2020-05-15 Thread Emil Velikov
From: Emil Velikov 

The comment that struct_mutex must be held is misleading. It is only
required when .gem_free_object() is used.

Since that one is going with the next patches, drop the reference.

Signed-off-by: Emil Velikov 
Acked-by: Sam Ravnborg 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_gem.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 918d1ba25f63..12fa121d0966 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -965,7 +965,6 @@ EXPORT_SYMBOL(drm_gem_object_release);
  * @kref: kref of the object to free
  *
  * Called after the last reference to the object has been lost.
- * Must be called holding _device.struct_mutex.
  *
  * Frees the object
  */
-- 
2.25.1

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


[PATCH v2 23/38] drm/mgag200: remove _unlocked suffix in drm_object_put_unlocked

2020-05-15 Thread Emil Velikov
From: Emil Velikov 

Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.

Just drop the suffix. It makes the API cleaner.

Done via the following script:

__from=drm_gem_object_put_unlocked
__to=drm_gem_object_put
for __file in $(git grep --name-only $__from); do
  sed -i  "s/$__from/$__to/g" $__file;
done

Cc: Dave Airlie 
Cc: David Airlie 
Cc: Daniel Vetter 
Signed-off-by: Emil Velikov 
Reviewed-by: Thomas Zimmermann 
---
 drivers/gpu/drm/mgag200/mgag200_cursor.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/mgag200/mgag200_cursor.c 
b/drivers/gpu/drm/mgag200/mgag200_cursor.c
index aebc9ce43d55..c6932dc8acf2 100644
--- a/drivers/gpu/drm/mgag200/mgag200_cursor.c
+++ b/drivers/gpu/drm/mgag200/mgag200_cursor.c
@@ -286,7 +286,7 @@ int mgag200_crtc_cursor_set(struct drm_crtc *crtc, struct 
drm_file *file_priv,
ret = PTR_ERR(src);
dev_err(>pdev->dev,
"failed to map user buffer updates\n");
-   goto err_drm_gem_object_put_unlocked;
+   goto err_drm_gem_object_put;
}
 
ret = mgag200_show_cursor(mdev, src, width, height);
@@ -295,13 +295,13 @@ int mgag200_crtc_cursor_set(struct drm_crtc *crtc, struct 
drm_file *file_priv,
 
/* Now update internal buffer pointers */
drm_gem_vram_vunmap(gbo, src);
-   drm_gem_object_put_unlocked(obj);
+   drm_gem_object_put(obj);
 
return 0;
 err_drm_gem_vram_vunmap:
drm_gem_vram_vunmap(gbo, src);
-err_drm_gem_object_put_unlocked:
-   drm_gem_object_put_unlocked(obj);
+err_drm_gem_object_put:
+   drm_gem_object_put(obj);
return ret;
 }
 
-- 
2.25.1

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


[PATCH v2 07/38] drm/amdgpu: use the unlocked drm_gem_object_put

2020-05-15 Thread Emil Velikov
From: Emil Velikov 

The driver does not hold struct_mutex, thus using the locked version of
the helper is incorrect.

Cc: Alex Deucher 
Cc: Christian König 
Cc: amd-...@lists.freedesktop.org
Fixes: a39414716ca0 ("drm/amdgpu: add independent DMA-buf import v9"):
Signed-off-by: Emil Velikov 
Acked-by: Sam Ravnborg 
Reviewed-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
index 43d8ed7dbd00..652c57a3b847 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
@@ -587,7 +587,7 @@ struct drm_gem_object *amdgpu_gem_prime_import(struct 
drm_device *dev,
attach = dma_buf_dynamic_attach(dma_buf, dev->dev,
_dma_buf_attach_ops, obj);
if (IS_ERR(attach)) {
-   drm_gem_object_put(obj);
+   drm_gem_object_put_unlocked(obj);
return ERR_CAST(attach);
}
 
-- 
2.25.1

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


[PATCH v2 38/38] drm: remove transient drm_object_put_unlocked()

2020-05-15 Thread Emil Velikov
From: Emil Velikov 

As of last commit, all the drivers have been updated away from the
_unlocked helper. As such we can now remove the transient #define.

v2: keep sed and #define removal separate

Cc: David Airlie 
Cc: Daniel Vetter 
Signed-off-by: Emil Velikov 
Acked-by: Sam Ravnborg  (v1)
---
 include/drm/drm_gem.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
index 10c5d561eb18..52173abdf500 100644
--- a/include/drm/drm_gem.h
+++ b/include/drm/drm_gem.h
@@ -375,8 +375,6 @@ drm_gem_object_put(struct drm_gem_object *obj)
kref_put(>refcount, drm_gem_object_free);
 }
 
-#define drm_gem_object_put_unlocked drm_gem_object_put
-
 void drm_gem_object_put_locked(struct drm_gem_object *obj);
 
 int drm_gem_handle_create(struct drm_file *file_priv,
-- 
2.25.1

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


[PATCH v2 19/38] drm/gma500: remove _unlocked suffix in drm_object_put_unlocked

2020-05-15 Thread Emil Velikov
From: Emil Velikov 

Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.

Just drop the suffix. It makes the API cleaner.

Done via the following script:

__from=drm_gem_object_put_unlocked
__to=drm_gem_object_put
for __file in $(git grep --name-only $__from); do
  sed -i  "s/$__from/$__to/g" $__file;
done

Cc: Patrik Jakobsson 
Cc: David Airlie 
Cc: Daniel Vetter 
Signed-off-by: Emil Velikov 
Acked-by: Sam Ravnborg 
---
 drivers/gpu/drm/gma500/framebuffer.c | 2 +-
 drivers/gpu/drm/gma500/gem.c | 2 +-
 drivers/gpu/drm/gma500/gma_display.c | 6 +++---
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/gma500/framebuffer.c 
b/drivers/gpu/drm/gma500/framebuffer.c
index 23a78d755382..da02d7e8a8f5 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -491,7 +491,7 @@ static int psb_fbdev_destroy(struct drm_device *dev,
drm_framebuffer_cleanup(fb);
 
if (fb->obj[0])
-   drm_gem_object_put_unlocked(fb->obj[0]);
+   drm_gem_object_put(fb->obj[0]);
kfree(fb);
 
return 0;
diff --git a/drivers/gpu/drm/gma500/gem.c b/drivers/gpu/drm/gma500/gem.c
index 83ee86f70b89..f9c4b1d76f56 100644
--- a/drivers/gpu/drm/gma500/gem.c
+++ b/drivers/gpu/drm/gma500/gem.c
@@ -82,7 +82,7 @@ int psb_gem_create(struct drm_file *file, struct drm_device 
*dev, u64 size,
return ret;
}
/* We have the initial and handle reference but need only one now */
-   drm_gem_object_put_unlocked(>gem);
+   drm_gem_object_put(>gem);
*handlep = handle;
return 0;
 }
diff --git a/drivers/gpu/drm/gma500/gma_display.c 
b/drivers/gpu/drm/gma500/gma_display.c
index 17f136985d21..3df6d6e850f5 100644
--- a/drivers/gpu/drm/gma500/gma_display.c
+++ b/drivers/gpu/drm/gma500/gma_display.c
@@ -351,7 +351,7 @@ int gma_crtc_cursor_set(struct drm_crtc *crtc,
gt = container_of(gma_crtc->cursor_obj,
  struct gtt_range, gem);
psb_gtt_unpin(gt);
-   drm_gem_object_put_unlocked(gma_crtc->cursor_obj);
+   drm_gem_object_put(gma_crtc->cursor_obj);
gma_crtc->cursor_obj = NULL;
}
return 0;
@@ -427,7 +427,7 @@ int gma_crtc_cursor_set(struct drm_crtc *crtc,
if (gma_crtc->cursor_obj) {
gt = container_of(gma_crtc->cursor_obj, struct gtt_range, gem);
psb_gtt_unpin(gt);
-   drm_gem_object_put_unlocked(gma_crtc->cursor_obj);
+   drm_gem_object_put(gma_crtc->cursor_obj);
}
 
gma_crtc->cursor_obj = obj;
@@ -435,7 +435,7 @@ int gma_crtc_cursor_set(struct drm_crtc *crtc,
return ret;
 
 unref_cursor:
-   drm_gem_object_put_unlocked(obj);
+   drm_gem_object_put(obj);
return ret;
 }
 
-- 
2.25.1

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


[PATCH v2 25/38] drm/nouveau: remove _unlocked suffix in drm_object_put_unlocked

2020-05-15 Thread Emil Velikov
From: Emil Velikov 

Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.

Just drop the suffix. It makes the API cleaner.

Done via the following script:

__from=drm_gem_object_put_unlocked
__to=drm_gem_object_put
for __file in $(git grep --name-only $__from); do
  sed -i  "s/$__from/$__to/g" $__file;
done

Cc: Ben Skeggs 
Cc: David Airlie 
Cc: Daniel Vetter 
Signed-off-by: Emil Velikov 
Acked-by: Sam Ravnborg 
---
 drivers/gpu/drm/nouveau/dispnv04/crtc.c   |  2 +-
 drivers/gpu/drm/nouveau/nouveau_abi16.c   |  2 +-
 drivers/gpu/drm/nouveau/nouveau_display.c |  8 
 drivers/gpu/drm/nouveau/nouveau_gem.c | 14 +++---
 4 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c 
b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
index 1f08de4241e0..27f511b9987b 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
@@ -1017,7 +1017,7 @@ nv04_crtc_cursor_set(struct drm_crtc *crtc, struct 
drm_file *file_priv,
nv_crtc->cursor.set_offset(nv_crtc, nv_crtc->cursor.offset);
nv_crtc->cursor.show(nv_crtc, true);
 out:
-   drm_gem_object_put_unlocked(gem);
+   drm_gem_object_put(gem);
return ret;
 }
 
diff --git a/drivers/gpu/drm/nouveau/nouveau_abi16.c 
b/drivers/gpu/drm/nouveau/nouveau_abi16.c
index e2bae1424502..72c91991b96a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_abi16.c
+++ b/drivers/gpu/drm/nouveau/nouveau_abi16.c
@@ -139,7 +139,7 @@ nouveau_abi16_chan_fini(struct nouveau_abi16 *abi16,
if (chan->ntfy) {
nouveau_vma_del(>ntfy_vma);
nouveau_bo_unpin(chan->ntfy);
-   drm_gem_object_put_unlocked(>ntfy->bo.base);
+   drm_gem_object_put(>ntfy->bo.base);
}
 
if (chan->heap.block_size)
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c 
b/drivers/gpu/drm/nouveau/nouveau_display.c
index 700817dc4fa0..60bef0ad028d 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -185,7 +185,7 @@ nouveau_user_framebuffer_destroy(struct drm_framebuffer 
*drm_fb)
struct nouveau_framebuffer *fb = nouveau_framebuffer(drm_fb);
 
if (fb->nvbo)
-   drm_gem_object_put_unlocked(>nvbo->bo.base);
+   drm_gem_object_put(>nvbo->bo.base);
 
drm_framebuffer_cleanup(drm_fb);
kfree(fb);
@@ -267,7 +267,7 @@ nouveau_user_framebuffer_create(struct drm_device *dev,
if (ret == 0)
return >base;
 
-   drm_gem_object_put_unlocked(gem);
+   drm_gem_object_put(gem);
return ERR_PTR(ret);
 }
 
@@ -648,7 +648,7 @@ nouveau_display_dumb_create(struct drm_file *file_priv, 
struct drm_device *dev,
return ret;
 
ret = drm_gem_handle_create(file_priv, >bo.base, >handle);
-   drm_gem_object_put_unlocked(>bo.base);
+   drm_gem_object_put(>bo.base);
return ret;
 }
 
@@ -663,7 +663,7 @@ nouveau_display_dumb_map_offset(struct drm_file *file_priv,
if (gem) {
struct nouveau_bo *bo = nouveau_gem_object(gem);
*poffset = drm_vma_node_offset_addr(>bo.base.vma_node);
-   drm_gem_object_put_unlocked(gem);
+   drm_gem_object_put(gem);
return 0;
}
 
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c 
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index f5ece1f94973..5631c484d10f 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -279,7 +279,7 @@ nouveau_gem_ioctl_new(struct drm_device *dev, void *data,
}
 
/* drop reference from allocate - handle holds it now */
-   drm_gem_object_put_unlocked(>bo.base);
+   drm_gem_object_put(>bo.base);
return ret;
 }
 
@@ -358,7 +358,7 @@ validate_fini_no_ticket(struct validate_op *op, struct 
nouveau_channel *chan,
list_del(>entry);
nvbo->reserved_by = NULL;
ttm_bo_unreserve(>bo);
-   drm_gem_object_put_unlocked(>bo.base);
+   drm_gem_object_put(>bo.base);
}
 }
 
@@ -405,14 +405,14 @@ validate_init(struct nouveau_channel *chan, struct 
drm_file *file_priv,
nvbo = nouveau_gem_object(gem);
if (nvbo == res_bo) {
res_bo = NULL;
-   drm_gem_object_put_unlocked(gem);
+   drm_gem_object_put(gem);
continue;
}
 
if (nvbo->reserved_by && nvbo->reserved_by == file_priv) {
NV_PRINTK(err, cli, "multiple instances of buffer %d on 
"
  "validation list\n", b->handle);
-   drm_gem_object_put_unlocked(gem);
+   drm_gem_object_put(gem);

[PATCH v2 15/38] drm/arm: remove _unlocked suffix in drm_object_put_unlocked

2020-05-15 Thread Emil Velikov
From: Emil Velikov 

Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.

Just drop the suffix. It makes the API cleaner.

Done via the following script:

__from=drm_gem_object_put_unlocked
__to=drm_gem_object_put
for __file in $(git grep --name-only $__from); do
  sed -i  "s/$__from/$__to/g" $__file;
done

Cc: Liviu Dudau 
Cc: Brian Starkey 
Cc: David Airlie 
Signed-off-by: Emil Velikov 
Acked-by: Sam Ravnborg 
Acked-by: Liviu Dudau 
---
 drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c | 6 +++---
 drivers/gpu/drm/arm/malidp_drv.c| 4 ++--
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c 
b/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
index 1b01a625f40e..170f9dc8ec19 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
@@ -19,7 +19,7 @@ static void komeda_fb_destroy(struct drm_framebuffer *fb)
u32 i;
 
for (i = 0; i < fb->format->num_planes; i++)
-   drm_gem_object_put_unlocked(fb->obj[i]);
+   drm_gem_object_put(fb->obj[i]);
 
drm_framebuffer_cleanup(fb);
kfree(kfb);
@@ -103,7 +103,7 @@ komeda_fb_afbc_size_check(struct komeda_fb *kfb, struct 
drm_file *file,
return 0;
 
 check_failed:
-   drm_gem_object_put_unlocked(obj);
+   drm_gem_object_put(obj);
return -EINVAL;
 }
 
@@ -199,7 +199,7 @@ komeda_fb_create(struct drm_device *dev, struct drm_file 
*file,
 
 err_cleanup:
for (i = 0; i < kfb->base.format->num_planes; i++)
-   drm_gem_object_put_unlocked(kfb->base.obj[i]);
+   drm_gem_object_put(kfb->base.obj[i]);
 
kfree(kfb);
return ERR_PTR(ret);
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index def8c9ffafca..c2507b7d8512 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -349,11 +349,11 @@ malidp_verify_afbc_framebuffer_size(struct drm_device 
*dev,
if (objs->size < afbc_size) {
DRM_DEBUG_KMS("buffer size (%zu) too small for AFBC buffer size 
= %u\n",
  objs->size, afbc_size);
-   drm_gem_object_put_unlocked(objs);
+   drm_gem_object_put(objs);
return false;
}
 
-   drm_gem_object_put_unlocked(objs);
+   drm_gem_object_put(objs);
 
return true;
 }
-- 
2.25.1

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


[PATCH v2 12/38] drm/gem: add drm_object_put helper

2020-05-15 Thread Emil Velikov
From: Emil Velikov 

Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.

Add helper, which will allow us to transition the drivers one by one,
dropping the suffix.

v2: add missing space after function name (Jani)

Signed-off-by: Emil Velikov 
Acked-by: Sam Ravnborg  (v1)
---
 include/drm/drm_gem.h | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
index a231a2b3f5ac..2f7b86c0649c 100644
--- a/include/drm/drm_gem.h
+++ b/include/drm/drm_gem.h
@@ -364,17 +364,19 @@ static inline void drm_gem_object_get(struct 
drm_gem_object *obj)
 }
 
 /**
- * drm_gem_object_put_unlocked - drop a GEM buffer object reference
+ * drm_gem_object_put - drop a GEM buffer object reference
  * @obj: GEM buffer object
  *
  * This releases a reference to @obj.
  */
 static inline void
-drm_gem_object_put_unlocked(struct drm_gem_object *obj)
+drm_gem_object_put(struct drm_gem_object *obj)
 {
kref_put(>refcount, drm_gem_object_free);
 }
 
+#define drm_gem_object_put_unlocked drm_gem_object_put
+
 void drm_gem_object_put_locked(struct drm_gem_object *obj);
 
 int drm_gem_handle_create(struct drm_file *file_priv,
-- 
2.25.1

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


[PATCH v2 11/38] drm/gem: add _locked suffix to drm_object_put

2020-05-15 Thread Emil Velikov
From: Emil Velikov 

Vast majority of DRM (core and drivers) are struct_mutex free.

As such we have only a handful of cases where the locked helper should
be used. Make that stand out a little bit better.

Done via the following script:

__from=drm_gem_object_put
__to=drm_gem_object_put_locked

for __file in $(git grep --name-only --word-regexp $__from); do
  sed -i  "s/\<$__from\>/$__to/g" $__file;
done

Cc: Rob Clark 
Cc: Sean Paul 
Cc: linux-arm-...@vger.kernel.org
Signed-off-by: Emil Velikov 
Acked-by: Sam Ravnborg 
---
 drivers/gpu/drm/drm_gem.c | 6 +++---
 drivers/gpu/drm/msm/adreno/a5xx_debugfs.c | 4 ++--
 drivers/gpu/drm/msm/msm_drv.c | 2 +-
 drivers/gpu/drm/msm/msm_gem.c | 6 +++---
 drivers/gpu/drm/msm/msm_gem_submit.c  | 2 +-
 drivers/gpu/drm/msm/msm_gpu.c | 2 +-
 include/drm/drm_gem.h | 4 ++--
 7 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 599d5ff53b73..f21327ebc562 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -983,7 +983,7 @@ drm_gem_object_free(struct kref *kref)
 EXPORT_SYMBOL(drm_gem_object_free);
 
 /**
- * drm_gem_object_put - release a GEM buffer object reference
+ * drm_gem_object_put_locked - release a GEM buffer object reference
  * @obj: GEM buffer object
  *
  * This releases a reference to @obj. Callers must hold the
@@ -994,7 +994,7 @@ EXPORT_SYMBOL(drm_gem_object_free);
  * drm_gem_object_put_unlocked() instead.
  */
 void
-drm_gem_object_put(struct drm_gem_object *obj)
+drm_gem_object_put_locked(struct drm_gem_object *obj)
 {
if (obj) {
WARN_ON(!mutex_is_locked(>dev->struct_mutex));
@@ -1002,7 +1002,7 @@ drm_gem_object_put(struct drm_gem_object *obj)
kref_put(>refcount, drm_gem_object_free);
}
 }
-EXPORT_SYMBOL(drm_gem_object_put);
+EXPORT_SYMBOL(drm_gem_object_put_locked);
 
 /**
  * drm_gem_vm_open - vma->ops->open implementation for GEM
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_debugfs.c 
b/drivers/gpu/drm/msm/adreno/a5xx_debugfs.c
index 8cae2ca4af6b..68eddac7771c 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_debugfs.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_debugfs.c
@@ -124,13 +124,13 @@ reset_set(void *data, u64 val)
 
if (a5xx_gpu->pm4_bo) {
msm_gem_unpin_iova(a5xx_gpu->pm4_bo, gpu->aspace);
-   drm_gem_object_put(a5xx_gpu->pm4_bo);
+   drm_gem_object_put_locked(a5xx_gpu->pm4_bo);
a5xx_gpu->pm4_bo = NULL;
}
 
if (a5xx_gpu->pfp_bo) {
msm_gem_unpin_iova(a5xx_gpu->pfp_bo, gpu->aspace);
-   drm_gem_object_put(a5xx_gpu->pfp_bo);
+   drm_gem_object_put_locked(a5xx_gpu->pfp_bo);
a5xx_gpu->pfp_bo = NULL;
}
 
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 29295dee2a2e..6baed5b43ea3 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -932,7 +932,7 @@ static int msm_ioctl_gem_madvise(struct drm_device *dev, 
void *data,
ret = 0;
}
 
-   drm_gem_object_put(obj);
+   drm_gem_object_put_locked(obj);
 
 unlock:
mutex_unlock(>struct_mutex);
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 5a6a79fbc9d6..8696c405f709 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -879,7 +879,7 @@ void msm_gem_describe_objects(struct list_head *list, 
struct seq_file *m)
 }
 #endif
 
-/* don't call directly!  Use drm_gem_object_put() and friends */
+/* don't call directly!  Use drm_gem_object_put_locked() and friends */
 void msm_gem_free_object(struct drm_gem_object *obj)
 {
struct msm_gem_object *msm_obj = to_msm_bo(obj);
@@ -1183,7 +1183,7 @@ static void *_msm_gem_kernel_new(struct drm_device *dev, 
uint32_t size,
return vaddr;
 err:
if (locked)
-   drm_gem_object_put(obj);
+   drm_gem_object_put_locked(obj);
else
drm_gem_object_put_unlocked(obj);
 
@@ -1215,7 +1215,7 @@ void msm_gem_kernel_put(struct drm_gem_object *bo,
msm_gem_unpin_iova(bo, aspace);
 
if (locked)
-   drm_gem_object_put(bo);
+   drm_gem_object_put_locked(bo);
else
drm_gem_object_put_unlocked(bo);
 }
diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c 
b/drivers/gpu/drm/msm/msm_gem_submit.c
index 385d4965a8d0..8f450a245cfb 100644
--- a/drivers/gpu/drm/msm/msm_gem_submit.c
+++ b/drivers/gpu/drm/msm/msm_gem_submit.c
@@ -387,7 +387,7 @@ static void submit_cleanup(struct msm_gem_submit *submit)
struct msm_gem_object *msm_obj = submit->bos[i].obj;
submit_unlock_unpin_bo(submit, i, false);
list_del_init(_obj->submit_entry);
-   drm_gem_object_put(_obj->base);
+   drm_gem_object_put_locked(_obj->base);
  

[PATCH v2 28/38] drm/qxl: remove _unlocked suffix in drm_object_put_unlocked

2020-05-15 Thread Emil Velikov
From: Emil Velikov 

Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.

Just drop the suffix. It makes the API cleaner.

Done via the following script:

__from=drm_gem_object_put_unlocked
__to=drm_gem_object_put
for __file in $(git grep --name-only $__from); do
  sed -i  "s/$__from/$__to/g" $__file;
done

Cc: Dave Airlie 
Cc: Gerd Hoffmann 
Cc: David Airlie 
Signed-off-by: Emil Velikov 
Acked-by: Sam Ravnborg 
---
 drivers/gpu/drm/qxl/qxl_cmd.c | 2 +-
 drivers/gpu/drm/qxl/qxl_display.c | 6 +++---
 drivers/gpu/drm/qxl/qxl_dumb.c| 2 +-
 drivers/gpu/drm/qxl/qxl_gem.c | 2 +-
 drivers/gpu/drm/qxl/qxl_ioctl.c   | 4 ++--
 drivers/gpu/drm/qxl/qxl_object.c  | 4 ++--
 6 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_cmd.c b/drivers/gpu/drm/qxl/qxl_cmd.c
index d1086b2a6892..3104af3d86b8 100644
--- a/drivers/gpu/drm/qxl/qxl_cmd.c
+++ b/drivers/gpu/drm/qxl/qxl_cmd.c
@@ -377,7 +377,7 @@ void qxl_io_destroy_primary(struct qxl_device *qdev)
 {
wait_for_io_cmd(qdev, 0, QXL_IO_DESTROY_PRIMARY_ASYNC);
qdev->primary_bo->is_primary = false;
-   drm_gem_object_put_unlocked(>primary_bo->tbo.base);
+   drm_gem_object_put(>primary_bo->tbo.base);
qdev->primary_bo = NULL;
 }
 
diff --git a/drivers/gpu/drm/qxl/qxl_display.c 
b/drivers/gpu/drm/qxl/qxl_display.c
index 1082cd5d2fd4..e403b37118d1 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -783,7 +783,7 @@ static int qxl_plane_prepare_fb(struct drm_plane *plane,
qdev->dumb_shadow_bo->surf.width  != surf.width ||
qdev->dumb_shadow_bo->surf.height != surf.height) {
if (qdev->dumb_shadow_bo) {
-   drm_gem_object_put_unlocked
+   drm_gem_object_put
(>dumb_shadow_bo->tbo.base);
qdev->dumb_shadow_bo = NULL;
}
@@ -793,7 +793,7 @@ static int qxl_plane_prepare_fb(struct drm_plane *plane,
}
if (user_bo->shadow != qdev->dumb_shadow_bo) {
if (user_bo->shadow) {
-   drm_gem_object_put_unlocked
+   drm_gem_object_put
(_bo->shadow->tbo.base);
user_bo->shadow = NULL;
}
@@ -828,7 +828,7 @@ static void qxl_plane_cleanup_fb(struct drm_plane *plane,
qxl_bo_unpin(user_bo);
 
if (old_state->fb != plane->state->fb && user_bo->shadow) {
-   drm_gem_object_put_unlocked(_bo->shadow->tbo.base);
+   drm_gem_object_put(_bo->shadow->tbo.base);
user_bo->shadow = NULL;
}
 }
diff --git a/drivers/gpu/drm/qxl/qxl_dumb.c b/drivers/gpu/drm/qxl/qxl_dumb.c
index 24e903383aa1..c04cd5a2553c 100644
--- a/drivers/gpu/drm/qxl/qxl_dumb.c
+++ b/drivers/gpu/drm/qxl/qxl_dumb.c
@@ -83,6 +83,6 @@ int qxl_mode_dumb_mmap(struct drm_file *file_priv,
return -ENOENT;
qobj = gem_to_qxl_bo(gobj);
*offset_p = qxl_bo_mmap_offset(qobj);
-   drm_gem_object_put_unlocked(gobj);
+   drm_gem_object_put(gobj);
return 0;
 }
diff --git a/drivers/gpu/drm/qxl/qxl_gem.c b/drivers/gpu/drm/qxl/qxl_gem.c
index 5ff6fa9b799c..48e096285b4c 100644
--- a/drivers/gpu/drm/qxl/qxl_gem.c
+++ b/drivers/gpu/drm/qxl/qxl_gem.c
@@ -97,7 +97,7 @@ int qxl_gem_object_create_with_handle(struct qxl_device *qdev,
return r;
/* drop reference from allocate - handle holds it now */
*qobj = gem_to_qxl_bo(gobj);
-   drm_gem_object_put_unlocked(gobj);
+   drm_gem_object_put(gobj);
return 0;
 }
 
diff --git a/drivers/gpu/drm/qxl/qxl_ioctl.c b/drivers/gpu/drm/qxl/qxl_ioctl.c
index d9a583966949..5dc78990990a 100644
--- a/drivers/gpu/drm/qxl/qxl_ioctl.c
+++ b/drivers/gpu/drm/qxl/qxl_ioctl.c
@@ -125,7 +125,7 @@ static int qxlhw_handle_to_bo(struct drm_file *file_priv, 
uint64_t handle,
qobj = gem_to_qxl_bo(gobj);
 
ret = qxl_release_list_add(release, qobj);
-   drm_gem_object_put_unlocked(gobj);
+   drm_gem_object_put(gobj);
if (ret)
return ret;
 
@@ -347,7 +347,7 @@ static int qxl_update_area_ioctl(struct drm_device *dev, 
void *data,
qxl_bo_unreserve(qobj);
 
 out:
-   drm_gem_object_put_unlocked(gobj);
+   drm_gem_object_put(gobj);
return ret;
 }
 
diff --git a/drivers/gpu/drm/qxl/qxl_object.c b/drivers/gpu/drm/qxl/qxl_object.c
index edc8a9916872..80e7a17aaddd 100644
--- a/drivers/gpu/drm/qxl/qxl_object.c
+++ b/drivers/gpu/drm/qxl/qxl_object.c
@@ -224,7 +224,7 @@ void qxl_bo_unref(struct qxl_bo **bo)
if ((*bo) == NULL)
return;
 
-   

[PATCH v2 32/38] drm/v3d: remove _unlocked suffix in drm_object_put_unlocked

2020-05-15 Thread Emil Velikov
From: Emil Velikov 

Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.

Just drop the suffix. It makes the API cleaner.

Done via the following script:

__from=drm_gem_object_put_unlocked
__to=drm_gem_object_put
for __file in $(git grep --name-only $__from); do
  sed -i  "s/$__from/$__to/g" $__file;
done

Cc: Eric Anholt 
Cc: David Airlie 
Cc: Daniel Vetter 
Signed-off-by: Emil Velikov 
Acked-by: Sam Ravnborg 
---
 drivers/gpu/drm/v3d/v3d_bo.c  | 6 +++---
 drivers/gpu/drm/v3d/v3d_gem.c | 4 ++--
 drivers/gpu/drm/v3d/v3d_irq.c | 2 +-
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/v3d/v3d_bo.c b/drivers/gpu/drm/v3d/v3d_bo.c
index edd299ab53d8..8b52cb25877c 100644
--- a/drivers/gpu/drm/v3d/v3d_bo.c
+++ b/drivers/gpu/drm/v3d/v3d_bo.c
@@ -185,7 +185,7 @@ int v3d_create_bo_ioctl(struct drm_device *dev, void *data,
args->offset = bo->node.start << PAGE_SHIFT;
 
ret = drm_gem_handle_create(file_priv, >base.base, >handle);
-   drm_gem_object_put_unlocked(>base.base);
+   drm_gem_object_put(>base.base);
 
return ret;
 }
@@ -208,7 +208,7 @@ int v3d_mmap_bo_ioctl(struct drm_device *dev, void *data,
}
 
args->offset = drm_vma_node_offset_addr(_obj->vma_node);
-   drm_gem_object_put_unlocked(gem_obj);
+   drm_gem_object_put(gem_obj);
 
return 0;
 }
@@ -229,6 +229,6 @@ int v3d_get_bo_offset_ioctl(struct drm_device *dev, void 
*data,
 
args->offset = bo->node.start << PAGE_SHIFT;
 
-   drm_gem_object_put_unlocked(gem_obj);
+   drm_gem_object_put(gem_obj);
return 0;
 }
diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c
index 09a7639cf161..915f8bfdb58c 100644
--- a/drivers/gpu/drm/v3d/v3d_gem.c
+++ b/drivers/gpu/drm/v3d/v3d_gem.c
@@ -358,7 +358,7 @@ v3d_job_free(struct kref *ref)
 
for (i = 0; i < job->bo_count; i++) {
if (job->bo[i])
-   drm_gem_object_put_unlocked(job->bo[i]);
+   drm_gem_object_put(job->bo[i]);
}
kvfree(job->bo);
 
@@ -384,7 +384,7 @@ v3d_render_job_free(struct kref *ref)
struct v3d_bo *bo, *save;
 
list_for_each_entry_safe(bo, save, >unref_list, unref_head) {
-   drm_gem_object_put_unlocked(>base.base);
+   drm_gem_object_put(>base.base);
}
 
v3d_job_free(ref);
diff --git a/drivers/gpu/drm/v3d/v3d_irq.c b/drivers/gpu/drm/v3d/v3d_irq.c
index 51b65263c657..c88686489b88 100644
--- a/drivers/gpu/drm/v3d/v3d_irq.c
+++ b/drivers/gpu/drm/v3d/v3d_irq.c
@@ -72,7 +72,7 @@ v3d_overflow_mem_work(struct work_struct *work)
V3D_CORE_WRITE(0, V3D_PTB_BPOS, obj->size);
 
 out:
-   drm_gem_object_put_unlocked(obj);
+   drm_gem_object_put(obj);
 }
 
 static irqreturn_t
-- 
2.25.1

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


[PATCH v2 36/38] drm/vkms: remove _unlocked suffix in drm_object_put_unlocked

2020-05-15 Thread Emil Velikov
From: Emil Velikov 

Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.

Just drop the suffix. It makes the API cleaner.

Done via the following script:

__from=drm_gem_object_put_unlocked
__to=drm_gem_object_put
for __file in $(git grep --name-only $__from); do
  sed -i  "s/$__from/$__to/g" $__file;
done

v2:
 - Rebase

Cc: Rodrigo Siqueira 
Cc: Haneen Mohammed 
Cc: Daniel Vetter 
Signed-off-by: Emil Velikov 
Acked-by: Sam Ravnborg  (v1)
---
 drivers/gpu/drm/vkms/vkms_gem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vkms/vkms_gem.c b/drivers/gpu/drm/vkms/vkms_gem.c
index c541fec57566..a017fc59905e 100644
--- a/drivers/gpu/drm/vkms/vkms_gem.c
+++ b/drivers/gpu/drm/vkms/vkms_gem.c
@@ -141,7 +141,7 @@ int vkms_dumb_create(struct drm_file *file, struct 
drm_device *dev,
args->size = gem_obj->size;
args->pitch = pitch;
 
-   drm_gem_object_put_unlocked(gem_obj);
+   drm_gem_object_put(gem_obj);
 
DRM_DEBUG_DRIVER("Created object of size %lld\n", size);
 
-- 
2.25.1

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


[PATCH v2 31/38] drm/tegra: remove _unlocked suffix in drm_object_put_unlocked

2020-05-15 Thread Emil Velikov
From: Emil Velikov 

Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.

Just drop the suffix. It makes the API cleaner.

Done via the following script:

__from=drm_gem_object_put_unlocked
__to=drm_gem_object_put
for __file in $(git grep --name-only $__from); do
  sed -i  "s/$__from/$__to/g" $__file;
done

Cc: Thierry Reding 
Cc: David Airlie 
Cc: Daniel Vetter 
Signed-off-by: Emil Velikov 
Acked-by: Sam Ravnborg 
---
 drivers/gpu/drm/tegra/drm.c | 12 ++--
 drivers/gpu/drm/tegra/fb.c  |  6 +++---
 drivers/gpu/drm/tegra/gem.c |  4 ++--
 3 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index d4f51b5c7ee5..09d71c94985c 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -328,7 +328,7 @@ int tegra_drm_submit(struct tegra_drm_context *context,
 
 fail:
while (num_refs--)
-   drm_gem_object_put_unlocked(refs[num_refs]);
+   drm_gem_object_put(refs[num_refs]);
 
kfree(refs);
 
@@ -368,7 +368,7 @@ static int tegra_gem_mmap(struct drm_device *drm, void 
*data,
 
args->offset = drm_vma_node_offset_addr(>gem.vma_node);
 
-   drm_gem_object_put_unlocked(gem);
+   drm_gem_object_put(gem);
 
return 0;
 }
@@ -636,7 +636,7 @@ static int tegra_gem_set_tiling(struct drm_device *drm, 
void *data,
bo->tiling.mode = mode;
bo->tiling.value = value;
 
-   drm_gem_object_put_unlocked(gem);
+   drm_gem_object_put(gem);
 
return 0;
 }
@@ -676,7 +676,7 @@ static int tegra_gem_get_tiling(struct drm_device *drm, 
void *data,
break;
}
 
-   drm_gem_object_put_unlocked(gem);
+   drm_gem_object_put(gem);
 
return err;
 }
@@ -701,7 +701,7 @@ static int tegra_gem_set_flags(struct drm_device *drm, void 
*data,
if (args->flags & DRM_TEGRA_GEM_BOTTOM_UP)
bo->flags |= TEGRA_BO_BOTTOM_UP;
 
-   drm_gem_object_put_unlocked(gem);
+   drm_gem_object_put(gem);
 
return 0;
 }
@@ -723,7 +723,7 @@ static int tegra_gem_get_flags(struct drm_device *drm, void 
*data,
if (bo->flags & TEGRA_BO_BOTTOM_UP)
args->flags |= DRM_TEGRA_GEM_BOTTOM_UP;
 
-   drm_gem_object_put_unlocked(gem);
+   drm_gem_object_put(gem);
 
return 0;
 }
diff --git a/drivers/gpu/drm/tegra/fb.c b/drivers/gpu/drm/tegra/fb.c
index 2b0666ac681b..01939c57fc74 100644
--- a/drivers/gpu/drm/tegra/fb.c
+++ b/drivers/gpu/drm/tegra/fb.c
@@ -171,7 +171,7 @@ struct drm_framebuffer *tegra_fb_create(struct drm_device 
*drm,
 
 unreference:
while (i--)
-   drm_gem_object_put_unlocked([i]->gem);
+   drm_gem_object_put([i]->gem);
 
return ERR_PTR(err);
 }
@@ -235,7 +235,7 @@ static int tegra_fbdev_probe(struct drm_fb_helper *helper,
info = drm_fb_helper_alloc_fbi(helper);
if (IS_ERR(info)) {
dev_err(drm->dev, "failed to allocate framebuffer info\n");
-   drm_gem_object_put_unlocked(>gem);
+   drm_gem_object_put(>gem);
return PTR_ERR(info);
}
 
@@ -244,7 +244,7 @@ static int tegra_fbdev_probe(struct drm_fb_helper *helper,
err = PTR_ERR(fbdev->fb);
dev_err(drm->dev, "failed to allocate DRM framebuffer: %d\n",
err);
-   drm_gem_object_put_unlocked(>gem);
+   drm_gem_object_put(>gem);
return PTR_ERR(fbdev->fb);
}
 
diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
index 623768100c6a..723df142a981 100644
--- a/drivers/gpu/drm/tegra/gem.c
+++ b/drivers/gpu/drm/tegra/gem.c
@@ -24,7 +24,7 @@ static void tegra_bo_put(struct host1x_bo *bo)
 {
struct tegra_bo *obj = host1x_to_tegra_bo(bo);
 
-   drm_gem_object_put_unlocked(>gem);
+   drm_gem_object_put(>gem);
 }
 
 /* XXX move this into lib/scatterlist.c? */
@@ -385,7 +385,7 @@ struct tegra_bo *tegra_bo_create_with_handle(struct 
drm_file *file,
return ERR_PTR(err);
}
 
-   drm_gem_object_put_unlocked(>gem);
+   drm_gem_object_put(>gem);
 
return bo;
 }
-- 
2.25.1

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


[PATCH v2 33/38] drm/vc4: remove _unlocked suffix in drm_object_put_unlocked

2020-05-15 Thread Emil Velikov
From: Emil Velikov 

Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.

Just drop the suffix. It makes the API cleaner.

Done via the following script:

__from=drm_gem_object_put_unlocked
__to=drm_gem_object_put
for __file in $(git grep --name-only $__from); do
  sed -i  "s/$__from/$__to/g" $__file;
done

Cc: Eric Anholt 
Cc: David Airlie 
Cc: Daniel Vetter 
Signed-off-by: Emil Velikov 
Acked-by: Sam Ravnborg 
---
 drivers/gpu/drm/vc4/vc4_bo.c  | 14 +++---
 drivers/gpu/drm/vc4/vc4_gem.c | 14 +++---
 drivers/gpu/drm/vc4/vc4_kms.c |  2 +-
 drivers/gpu/drm/vc4/vc4_v3d.c |  4 ++--
 4 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
index 72d30d90b856..74ceebd62fbc 100644
--- a/drivers/gpu/drm/vc4/vc4_bo.c
+++ b/drivers/gpu/drm/vc4/vc4_bo.c
@@ -490,7 +490,7 @@ int vc4_dumb_create(struct drm_file *file_priv,
bo->madv = VC4_MADV_WILLNEED;
 
ret = drm_gem_handle_create(file_priv, >base.base, >handle);
-   drm_gem_object_put_unlocked(>base.base);
+   drm_gem_object_put(>base.base);
 
return ret;
 }
@@ -834,7 +834,7 @@ int vc4_create_bo_ioctl(struct drm_device *dev, void *data,
bo->madv = VC4_MADV_WILLNEED;
 
ret = drm_gem_handle_create(file_priv, >base.base, >handle);
-   drm_gem_object_put_unlocked(>base.base);
+   drm_gem_object_put(>base.base);
 
return ret;
 }
@@ -854,7 +854,7 @@ int vc4_mmap_bo_ioctl(struct drm_device *dev, void *data,
/* The mmap offset was set up at BO allocation time. */
args->offset = drm_vma_node_offset_addr(_obj->vma_node);
 
-   drm_gem_object_put_unlocked(gem_obj);
+   drm_gem_object_put(gem_obj);
return 0;
 }
 
@@ -918,7 +918,7 @@ vc4_create_shader_bo_ioctl(struct drm_device *dev, void 
*data,
ret = drm_gem_handle_create(file_priv, >base.base, >handle);
 
 fail:
-   drm_gem_object_put_unlocked(>base.base);
+   drm_gem_object_put(>base.base);
 
return ret;
 }
@@ -965,7 +965,7 @@ int vc4_set_tiling_ioctl(struct drm_device *dev, void *data,
bo = to_vc4_bo(gem_obj);
bo->t_format = t_format;
 
-   drm_gem_object_put_unlocked(gem_obj);
+   drm_gem_object_put(gem_obj);
 
return 0;
 }
@@ -1000,7 +1000,7 @@ int vc4_get_tiling_ioctl(struct drm_device *dev, void 
*data,
else
args->modifier = DRM_FORMAT_MOD_NONE;
 
-   drm_gem_object_put_unlocked(gem_obj);
+   drm_gem_object_put(gem_obj);
 
return 0;
 }
@@ -1091,7 +1091,7 @@ int vc4_label_bo_ioctl(struct drm_device *dev, void *data,
ret = -ENOMEM;
mutex_unlock(>bo_lock);
 
-   drm_gem_object_put_unlocked(gem_obj);
+   drm_gem_object_put(gem_obj);
 
return ret;
 }
diff --git a/drivers/gpu/drm/vc4/vc4_gem.c b/drivers/gpu/drm/vc4/vc4_gem.c
index e1cfc3ccd05a..9f01ddd5b932 100644
--- a/drivers/gpu/drm/vc4/vc4_gem.c
+++ b/drivers/gpu/drm/vc4/vc4_gem.c
@@ -58,7 +58,7 @@ vc4_free_hang_state(struct drm_device *dev, struct 
vc4_hang_state *state)
unsigned int i;
 
for (i = 0; i < state->user_state.bo_count; i++)
-   drm_gem_object_put_unlocked(state->bo[i]);
+   drm_gem_object_put(state->bo[i]);
 
kfree(state);
 }
@@ -808,7 +808,7 @@ vc4_cl_lookup_bos(struct drm_device *dev,
 fail_put_bo:
/* Release any reference to acquired objects. */
for (i = 0; i < exec->bo_count && exec->bo[i]; i++)
-   drm_gem_object_put_unlocked(>bo[i]->base);
+   drm_gem_object_put(>bo[i]->base);
 
 fail:
kvfree(handles);
@@ -957,7 +957,7 @@ vc4_complete_exec(struct drm_device *dev, struct 
vc4_exec_info *exec)
struct vc4_bo *bo = to_vc4_bo(>bo[i]->base);
 
vc4_bo_dec_usecnt(bo);
-   drm_gem_object_put_unlocked(>bo[i]->base);
+   drm_gem_object_put(>bo[i]->base);
}
kvfree(exec->bo);
}
@@ -966,7 +966,7 @@ vc4_complete_exec(struct drm_device *dev, struct 
vc4_exec_info *exec)
struct vc4_bo *bo = list_first_entry(>unref_list,
 struct vc4_bo, unref_head);
list_del(>unref_head);
-   drm_gem_object_put_unlocked(>base.base);
+   drm_gem_object_put(>base.base);
}
 
/* Free up the allocation of any bin slots we used. */
@@ -1107,7 +1107,7 @@ vc4_wait_bo_ioctl(struct drm_device *dev, void *data,
ret = vc4_wait_for_seqno_ioctl_helper(dev, bo->seqno,
  >timeout_ns);
 
-   drm_gem_object_put_unlocked(gem_obj);
+   drm_gem_object_put(gem_obj);
return ret;
 }
 
@@ -1301,7 +1301,7 @@ vc4_gem_destroy(struct drm_device *dev)
 * the 

[PATCH v2 35/38] drm/virtio: remove _unlocked suffix in drm_object_put_unlocked

2020-05-15 Thread Emil Velikov
From: Emil Velikov 

Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.

Just drop the suffix. It makes the API cleaner.

Done via the following script:

__from=drm_gem_object_put_unlocked
__to=drm_gem_object_put
for __file in $(git grep --name-only $__from); do
  sed -i  "s/$__from/$__to/g" $__file;
done

Cc: David Airlie 
Cc: Gerd Hoffmann 
Cc: Daniel Vetter 
Signed-off-by: Emil Velikov 
Acked-by: Sam Ravnborg 
---
 drivers/gpu/drm/virtio/virtgpu_display.c | 2 +-
 drivers/gpu/drm/virtio/virtgpu_gem.c | 6 +++---
 drivers/gpu/drm/virtio/virtgpu_ioctl.c   | 6 +++---
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c 
b/drivers/gpu/drm/virtio/virtgpu_display.c
index cc7fd957a307..f3ce49c5a34c 100644
--- a/drivers/gpu/drm/virtio/virtgpu_display.c
+++ b/drivers/gpu/drm/virtio/virtgpu_display.c
@@ -307,7 +307,7 @@ virtio_gpu_user_framebuffer_create(struct drm_device *dev,
ret = virtio_gpu_framebuffer_init(dev, virtio_gpu_fb, mode_cmd, obj);
if (ret) {
kfree(virtio_gpu_fb);
-   drm_gem_object_put_unlocked(obj);
+   drm_gem_object_put(obj);
return NULL;
}
 
diff --git a/drivers/gpu/drm/virtio/virtgpu_gem.c 
b/drivers/gpu/drm/virtio/virtgpu_gem.c
index 1025658be4df..3dcd61aa6649 100644
--- a/drivers/gpu/drm/virtio/virtgpu_gem.c
+++ b/drivers/gpu/drm/virtio/virtgpu_gem.c
@@ -52,7 +52,7 @@ static int virtio_gpu_gem_create(struct drm_file *file,
*obj_p = >base.base;
 
/* drop reference from allocate - handle holds it now */
-   drm_gem_object_put_unlocked(>base.base);
+   drm_gem_object_put(>base.base);
 
*handle_p = handle;
return 0;
@@ -102,7 +102,7 @@ int virtio_gpu_mode_dumb_mmap(struct drm_file *file_priv,
if (gobj == NULL)
return -ENOENT;
*offset_p = drm_vma_node_offset_addr(>vma_node);
-   drm_gem_object_put_unlocked(gobj);
+   drm_gem_object_put(gobj);
return 0;
 }
 
@@ -237,7 +237,7 @@ void virtio_gpu_array_put_free(struct 
virtio_gpu_object_array *objs)
u32 i;
 
for (i = 0; i < objs->nents; i++)
-   drm_gem_object_put_unlocked(objs->objs[i]);
+   drm_gem_object_put(objs->objs[i]);
virtio_gpu_array_free(objs);
 }
 
diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c 
b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
index 867c5e239d55..584766be8d64 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
@@ -278,7 +278,7 @@ static int virtio_gpu_resource_create_ioctl(struct 
drm_device *dev, void *data,
drm_gem_object_release(obj);
return ret;
}
-   drm_gem_object_put_unlocked(obj);
+   drm_gem_object_put(obj);
 
rc->res_handle = qobj->hw_res_handle; /* similiar to a VM address */
rc->bo_handle = handle;
@@ -300,7 +300,7 @@ static int virtio_gpu_resource_info_ioctl(struct drm_device 
*dev, void *data,
 
ri->size = qobj->base.base.size;
ri->res_handle = qobj->hw_res_handle;
-   drm_gem_object_put_unlocked(gobj);
+   drm_gem_object_put(gobj);
return 0;
 }
 
@@ -417,7 +417,7 @@ static int virtio_gpu_wait_ioctl(struct drm_device *dev, 
void *data,
else if (ret > 0)
ret = 0;
 
-   drm_gem_object_put_unlocked(obj);
+   drm_gem_object_put(obj);
return ret;
 }
 
-- 
2.25.1

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


[PATCH v2 27/38] drm/panfrost: remove _unlocked suffix in drm_object_put_unlocked

2020-05-15 Thread Emil Velikov
From: Emil Velikov 

Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.

Just drop the suffix. It makes the API cleaner.

Done via the following script:

__from=drm_gem_object_put_unlocked
__to=drm_gem_object_put
for __file in $(git grep --name-only $__from); do
  sed -i  "s/$__from/$__to/g" $__file;
done

Cc: Rob Herring 
Cc: Tomeu Vizoso 
Cc: Steven Price 
Signed-off-by: Emil Velikov 
Acked-by: Sam Ravnborg 
---
 drivers/gpu/drm/panfrost/panfrost_drv.c | 10 +-
 drivers/gpu/drm/panfrost/panfrost_gem.c |  4 ++--
 drivers/gpu/drm/panfrost/panfrost_job.c |  2 +-
 drivers/gpu/drm/panfrost/panfrost_mmu.c |  2 +-
 drivers/gpu/drm/panfrost/panfrost_perfcnt.c |  4 ++--
 5 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c 
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index 882fecc33fdb..ada51df9a7a3 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -99,7 +99,7 @@ static int panfrost_ioctl_create_bo(struct drm_device *dev, 
void *data,
 
mapping = panfrost_gem_mapping_get(bo, priv);
if (!mapping) {
-   drm_gem_object_put_unlocked(>base.base);
+   drm_gem_object_put(>base.base);
return -EINVAL;
}
 
@@ -317,7 +317,7 @@ panfrost_ioctl_wait_bo(struct drm_device *dev, void *data,
if (!ret)
ret = timeout ? -ETIMEDOUT : -EBUSY;
 
-   drm_gem_object_put_unlocked(gem_obj);
+   drm_gem_object_put(gem_obj);
 
return ret;
 }
@@ -351,7 +351,7 @@ static int panfrost_ioctl_mmap_bo(struct drm_device *dev, 
void *data,
args->offset = drm_vma_node_offset_addr(_obj->vma_node);
 
 out:
-   drm_gem_object_put_unlocked(gem_obj);
+   drm_gem_object_put(gem_obj);
return ret;
 }
 
@@ -372,7 +372,7 @@ static int panfrost_ioctl_get_bo_offset(struct drm_device 
*dev, void *data,
bo = to_panfrost_bo(gem_obj);
 
mapping = panfrost_gem_mapping_get(bo, priv);
-   drm_gem_object_put_unlocked(gem_obj);
+   drm_gem_object_put(gem_obj);
 
if (!mapping)
return -EINVAL;
@@ -438,7 +438,7 @@ static int panfrost_ioctl_madvise(struct drm_device *dev, 
void *data,
mutex_unlock(>mappings.lock);
mutex_unlock(>shrinker_lock);
 
-   drm_gem_object_put_unlocked(gem_obj);
+   drm_gem_object_put(gem_obj);
return ret;
 }
 
diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.c 
b/drivers/gpu/drm/panfrost/panfrost_gem.c
index 17b654e1eb94..ac5d0aa80276 100644
--- a/drivers/gpu/drm/panfrost/panfrost_gem.c
+++ b/drivers/gpu/drm/panfrost/panfrost_gem.c
@@ -93,7 +93,7 @@ static void panfrost_gem_mapping_release(struct kref *kref)
mapping = container_of(kref, struct panfrost_gem_mapping, refcount);
 
panfrost_gem_teardown_mapping(mapping);
-   drm_gem_object_put_unlocked(>obj->base.base);
+   drm_gem_object_put(>obj->base.base);
kfree(mapping);
 }
 
@@ -261,7 +261,7 @@ panfrost_gem_create_with_handle(struct drm_file *file_priv,
 */
ret = drm_gem_handle_create(file_priv, >base, handle);
/* drop reference from allocate - handle holds it now. */
-   drm_gem_object_put_unlocked(>base);
+   drm_gem_object_put(>base);
if (ret)
return ERR_PTR(ret);
 
diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c 
b/drivers/gpu/drm/panfrost/panfrost_job.c
index 7914b1570841..b2f09c038d35 100644
--- a/drivers/gpu/drm/panfrost/panfrost_job.c
+++ b/drivers/gpu/drm/panfrost/panfrost_job.c
@@ -281,7 +281,7 @@ static void panfrost_job_cleanup(struct kref *ref)
 
if (job->bos) {
for (i = 0; i < job->bo_count; i++)
-   drm_gem_object_put_unlocked(job->bos[i]);
+   drm_gem_object_put(job->bos[i]);
 
kvfree(job->bos);
}
diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c 
b/drivers/gpu/drm/panfrost/panfrost_mmu.c
index ed28aeba6d59..0a339c6fbfaa 100644
--- a/drivers/gpu/drm/panfrost/panfrost_mmu.c
+++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c
@@ -538,7 +538,7 @@ static int panfrost_mmu_map_fault_addr(struct 
panfrost_device *pfdev, int as,
 err_pages:
drm_gem_shmem_put_pages(>base);
 err_bo:
-   drm_gem_object_put_unlocked(>base.base);
+   drm_gem_object_put(>base.base);
return ret;
 }
 
diff --git a/drivers/gpu/drm/panfrost/panfrost_perfcnt.c 
b/drivers/gpu/drm/panfrost/panfrost_perfcnt.c
index 6913578d5aa7..ec4695cf3caf 100644
--- a/drivers/gpu/drm/panfrost/panfrost_perfcnt.c
+++ b/drivers/gpu/drm/panfrost/panfrost_perfcnt.c
@@ -156,7 +156,7 @@ static int panfrost_perfcnt_enable_locked(struct 
panfrost_device *pfdev,
gpu_write(pfdev, GPU_PRFCNT_TILER_EN, 0x);
 
/* The BO ref is retained by the mapping. */

[PATCH v2 29/38] drm/radeon: remove _unlocked suffix in drm_object_put_unlocked

2020-05-15 Thread Emil Velikov
From: Emil Velikov 

Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.

Just drop the suffix. It makes the API cleaner.

Done via the following script:

__from=drm_gem_object_put_unlocked
__to=drm_gem_object_put
for __file in $(git grep --name-only $__from); do
  sed -i  "s/$__from/$__to/g" $__file;
done

Cc: Alex Deucher 
Cc: "Christian König" 
Cc: "David (ChunMing) Zhou" 
Signed-off-by: Emil Velikov 
Acked-by: Sam Ravnborg 
---
 drivers/gpu/drm/radeon/radeon_cs.c  |  2 +-
 drivers/gpu/drm/radeon/radeon_cursor.c  |  6 ++---
 drivers/gpu/drm/radeon/radeon_display.c |  8 +++
 drivers/gpu/drm/radeon/radeon_fb.c  |  4 ++--
 drivers/gpu/drm/radeon/radeon_gem.c | 30 -
 drivers/gpu/drm/radeon/radeon_object.c  |  2 +-
 6 files changed, 26 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
b/drivers/gpu/drm/radeon/radeon_cs.c
index 0d0ab8e0ff3b..af0bf78314e2 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -443,7 +443,7 @@ static void radeon_cs_parser_fini(struct radeon_cs_parser 
*parser, int error, bo
if (bo == NULL)
continue;
 
-   drm_gem_object_put_unlocked(>tbo.base);
+   drm_gem_object_put(>tbo.base);
}
}
kfree(parser->track);
diff --git a/drivers/gpu/drm/radeon/radeon_cursor.c 
b/drivers/gpu/drm/radeon/radeon_cursor.c
index 9180bb51b913..3507805b34bc 100644
--- a/drivers/gpu/drm/radeon/radeon_cursor.c
+++ b/drivers/gpu/drm/radeon/radeon_cursor.c
@@ -309,7 +309,7 @@ int radeon_crtc_cursor_set2(struct drm_crtc *crtc,
robj = gem_to_radeon_bo(obj);
ret = radeon_bo_reserve(robj, false);
if (ret != 0) {
-   drm_gem_object_put_unlocked(obj);
+   drm_gem_object_put(obj);
return ret;
}
/* Only 27 bit offset for legacy cursor */
@@ -319,7 +319,7 @@ int radeon_crtc_cursor_set2(struct drm_crtc *crtc,
radeon_bo_unreserve(robj);
if (ret) {
DRM_ERROR("Failed to pin new cursor BO (%d)\n", ret);
-   drm_gem_object_put_unlocked(obj);
+   drm_gem_object_put(obj);
return ret;
}
 
@@ -354,7 +354,7 @@ int radeon_crtc_cursor_set2(struct drm_crtc *crtc,
radeon_bo_unpin(robj);
radeon_bo_unreserve(robj);
}
-   drm_gem_object_put_unlocked(radeon_crtc->cursor_bo);
+   drm_gem_object_put(radeon_crtc->cursor_bo);
}
 
radeon_crtc->cursor_bo = obj;
diff --git a/drivers/gpu/drm/radeon/radeon_display.c 
b/drivers/gpu/drm/radeon/radeon_display.c
index 35db79a168bf..6222bdb74825 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -281,7 +281,7 @@ static void radeon_unpin_work_func(struct work_struct 
*__work)
} else
DRM_ERROR("failed to reserve buffer after flip\n");
 
-   drm_gem_object_put_unlocked(>old_rbo->tbo.base);
+   drm_gem_object_put(>old_rbo->tbo.base);
kfree(work);
 }
 
@@ -613,7 +613,7 @@ static int radeon_crtc_page_flip_target(struct drm_crtc 
*crtc,
radeon_bo_unreserve(new_rbo);
 
 cleanup:
-   drm_gem_object_put_unlocked(>old_rbo->tbo.base);
+   drm_gem_object_put(>old_rbo->tbo.base);
dma_fence_put(work->fence);
kfree(work);
return r;
@@ -1337,14 +1337,14 @@ radeon_user_framebuffer_create(struct drm_device *dev,
 
fb = kzalloc(sizeof(*fb), GFP_KERNEL);
if (fb == NULL) {
-   drm_gem_object_put_unlocked(obj);
+   drm_gem_object_put(obj);
return ERR_PTR(-ENOMEM);
}
 
ret = radeon_framebuffer_init(dev, fb, mode_cmd, obj);
if (ret) {
kfree(fb);
-   drm_gem_object_put_unlocked(obj);
+   drm_gem_object_put(obj);
return ERR_PTR(ret);
}
 
diff --git a/drivers/gpu/drm/radeon/radeon_fb.c 
b/drivers/gpu/drm/radeon/radeon_fb.c
index cf3156a65fc1..fc4212633bdf 100644
--- a/drivers/gpu/drm/radeon/radeon_fb.c
+++ b/drivers/gpu/drm/radeon/radeon_fb.c
@@ -119,7 +119,7 @@ static void radeonfb_destroy_pinned_object(struct 
drm_gem_object *gobj)
radeon_bo_unpin(rbo);
radeon_bo_unreserve(rbo);
}
-   drm_gem_object_put_unlocked(gobj);
+   drm_gem_object_put(gobj);
 }
 
 static int radeonfb_create_pinned_object(struct radeon_fbdev *rfbdev,
@@ -298,7 +298,7 @@ static int radeonfb_create(struct drm_fb_helper *helper,
 
}
if (fb && ret) {
-   drm_gem_object_put_unlocked(gobj);
+   drm_gem_object_put(gobj);
drm_framebuffer_unregister_private(fb);
   

[PATCH v2 24/38] drm/msm: remove _unlocked suffix in drm_object_put_unlocked

2020-05-15 Thread Emil Velikov
From: Emil Velikov 

Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.

Just drop the suffix. It makes the API cleaner.

Done via the following script:

__from=drm_gem_object_put_unlocked
__to=drm_gem_object_put
for __file in $(git grep --name-only $__from); do
  sed -i  "s/$__from/$__to/g" $__file;
done

Cc: Rob Clark 
Cc: Sean Paul 
Cc: David Airlie 
Signed-off-by: Emil Velikov 
Acked-by: Sam Ravnborg 
---
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c |  6 +++---
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c |  2 +-
 drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c |  4 ++--
 drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c  |  2 +-
 drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c |  2 +-
 drivers/gpu/drm/msm/dsi/dsi_host.c|  2 +-
 drivers/gpu/drm/msm/msm_drv.c |  6 +++---
 drivers/gpu/drm/msm/msm_fb.c  |  4 ++--
 drivers/gpu/drm/msm/msm_gem.c | 12 ++--
 9 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index 724024a2243a..ad41ff023a1a 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -804,17 +804,17 @@ static void a5xx_destroy(struct msm_gpu *gpu)
 
if (a5xx_gpu->pm4_bo) {
msm_gem_unpin_iova(a5xx_gpu->pm4_bo, gpu->aspace);
-   drm_gem_object_put_unlocked(a5xx_gpu->pm4_bo);
+   drm_gem_object_put(a5xx_gpu->pm4_bo);
}
 
if (a5xx_gpu->pfp_bo) {
msm_gem_unpin_iova(a5xx_gpu->pfp_bo, gpu->aspace);
-   drm_gem_object_put_unlocked(a5xx_gpu->pfp_bo);
+   drm_gem_object_put(a5xx_gpu->pfp_bo);
}
 
if (a5xx_gpu->gpmu_bo) {
msm_gem_unpin_iova(a5xx_gpu->gpmu_bo, gpu->aspace);
-   drm_gem_object_put_unlocked(a5xx_gpu->gpmu_bo);
+   drm_gem_object_put(a5xx_gpu->gpmu_bo);
}
 
adreno_gpu_cleanup(adreno_gpu);
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 68af24150de5..34b85aaec747 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -795,7 +795,7 @@ static void a6xx_destroy(struct msm_gpu *gpu)
 
if (a6xx_gpu->sqe_bo) {
msm_gem_unpin_iova(a6xx_gpu->sqe_bo, gpu->aspace);
-   drm_gem_object_put_unlocked(a6xx_gpu->sqe_bo);
+   drm_gem_object_put(a6xx_gpu->sqe_bo);
}
 
a6xx_gmu_remove(a6xx_gpu);
diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c 
b/drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c
index c9239b07fe4f..a0253297bc76 100644
--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c
+++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c
@@ -119,7 +119,7 @@ static void unref_cursor_worker(struct drm_flip_work *work, 
void *val)
struct msm_kms *kms = _kms->base.base;
 
msm_gem_unpin_iova(val, kms->aspace);
-   drm_gem_object_put_unlocked(val);
+   drm_gem_object_put(val);
 }
 
 static void mdp4_crtc_destroy(struct drm_crtc *crtc)
@@ -452,7 +452,7 @@ static int mdp4_crtc_cursor_set(struct drm_crtc *crtc,
return 0;
 
 fail:
-   drm_gem_object_put_unlocked(cursor_bo);
+   drm_gem_object_put(cursor_bo);
return ret;
 }
 
diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c 
b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
index dda05436f716..243584d4b1d7 100644
--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
@@ -165,7 +165,7 @@ static void mdp4_destroy(struct msm_kms *kms)
 
if (mdp4_kms->blank_cursor_iova)
msm_gem_unpin_iova(mdp4_kms->blank_cursor_bo, kms->aspace);
-   drm_gem_object_put_unlocked(mdp4_kms->blank_cursor_bo);
+   drm_gem_object_put(mdp4_kms->blank_cursor_bo);
 
if (aspace) {
aspace->mmu->funcs->detach(aspace->mmu);
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
index 998bef1190a3..ca3368c828d0 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
@@ -166,7 +166,7 @@ static void unref_cursor_worker(struct drm_flip_work *work, 
void *val)
struct msm_kms *kms = _kms->base.base;
 
msm_gem_unpin_iova(val, kms->aspace);
-   drm_gem_object_put_unlocked(val);
+   drm_gem_object_put(val);
 }
 
 static void mdp5_crtc_destroy(struct drm_crtc *crtc)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 11ae5b8444c3..66ca0c009cfa 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -1132,7 +1132,7 @@ static void dsi_tx_buf_free(struct msm_dsi_host *msm_host)
priv = dev->dev_private;
if (msm_host->tx_gem_obj) {

[PATCH v2 30/38] drm/rockchip: remove _unlocked suffix in drm_object_put_unlocked

2020-05-15 Thread Emil Velikov
From: Emil Velikov 

Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.

Just drop the suffix. It makes the API cleaner.

Done via the following script:

__from=drm_gem_object_put_unlocked
__to=drm_gem_object_put
for __file in $(git grep --name-only $__from); do
  sed -i  "s/$__from/$__to/g" $__file;
done

Cc: Sandy Huang 
Cc: "Heiko Stübner" 
Cc: David Airlie 
Signed-off-by: Emil Velikov 
Acked-by: Sam Ravnborg 
---
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c  | 2 +-
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
index 9b13c784b347..3aa37e177667 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
@@ -88,7 +88,7 @@ rockchip_fb_create(struct drm_device *dev, struct drm_file 
*file,
struct drm_gem_object **obj = afbc_fb->base.obj;
 
for (i = 0; i < info->num_planes; ++i)
-   drm_gem_object_put_unlocked(obj[i]);
+   drm_gem_object_put(obj[i]);
 
kfree(afbc_fb);
return ERR_PTR(ret);
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index 0d1884684dcb..b9275ba7c5a5 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
@@ -392,7 +392,7 @@ rockchip_gem_create_with_handle(struct drm_file *file_priv,
goto err_handle_create;
 
/* drop reference from allocate - handle holds it now. */
-   drm_gem_object_put_unlocked(obj);
+   drm_gem_object_put(obj);
 
return rk_obj;
 
-- 
2.25.1

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


[PATCH v2 34/38] drm/vgem: remove _unlocked suffix in drm_object_put_unlocked

2020-05-15 Thread Emil Velikov
From: Emil Velikov 

Spelling out _unlocked for each and every driver is a annoying.
Especially if we consider how many drivers, do not know (or need to)
about the horror stories involving struct_mutex.

Just drop the suffix. It makes the API cleaner.

Done via the following script:

__from=drm_gem_object_put_unlocked
__to=drm_gem_object_put
for __file in $(git grep --name-only $__from); do
  sed -i  "s/$__from/$__to/g" $__file;
done

Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Emil Velikov 
Signed-off-by: Emil Velikov 
Acked-by: Sam Ravnborg 
---
 drivers/gpu/drm/vgem/vgem_drv.c   | 6 +++---
 drivers/gpu/drm/vgem/vgem_fence.c | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index ec1a8ebb6f1b..e4dc7b267a0b 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -198,7 +198,7 @@ static struct drm_gem_object *vgem_gem_create(struct 
drm_device *dev,
 
ret = drm_gem_handle_create(file, >base, handle);
if (ret) {
-   drm_gem_object_put_unlocked(>base);
+   drm_gem_object_put(>base);
return ERR_PTR(ret);
}
 
@@ -223,7 +223,7 @@ static int vgem_gem_dumb_create(struct drm_file *file, 
struct drm_device *dev,
args->size = gem_object->size;
args->pitch = pitch;
 
-   drm_gem_object_put_unlocked(gem_object);
+   drm_gem_object_put(gem_object);
 
DRM_DEBUG("Created object of size %llu\n", args->size);
 
@@ -251,7 +251,7 @@ static int vgem_gem_dumb_map(struct drm_file *file, struct 
drm_device *dev,
 
*offset = drm_vma_node_offset_addr(>vma_node);
 unref:
-   drm_gem_object_put_unlocked(obj);
+   drm_gem_object_put(obj);
 
return ret;
 }
diff --git a/drivers/gpu/drm/vgem/vgem_fence.c 
b/drivers/gpu/drm/vgem/vgem_fence.c
index 9268f6fc3f66..17f32f550dd9 100644
--- a/drivers/gpu/drm/vgem/vgem_fence.c
+++ b/drivers/gpu/drm/vgem/vgem_fence.c
@@ -182,7 +182,7 @@ int vgem_fence_attach_ioctl(struct drm_device *dev,
dma_fence_put(fence);
}
 err:
-   drm_gem_object_put_unlocked(obj);
+   drm_gem_object_put(obj);
return ret;
 }
 
-- 
2.25.1

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


[PATCH v2 09/38] drm: remove drm_driver::gem_free_object

2020-05-15 Thread Emil Velikov
From: Emil Velikov 

No drivers set the callback, so remove it all together.

Signed-off-by: Emil Velikov 
Acked-by: Sam Ravnborg 
Reviewed-by: Thomas Zimmermann 
---
 drivers/gpu/drm/drm_gem.c | 22 +++---
 include/drm/drm_drv.h |  8 
 include/drm/drm_gem.h |  5 +++--
 3 files changed, 6 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 12fa121d0966..dab8763b2e73 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -975,15 +975,10 @@ drm_gem_object_free(struct kref *kref)
container_of(kref, struct drm_gem_object, refcount);
struct drm_device *dev = obj->dev;
 
-   if (obj->funcs) {
+   if (obj->funcs)
obj->funcs->free(obj);
-   } else if (dev->driver->gem_free_object_unlocked) {
+   else if (dev->driver->gem_free_object_unlocked)
dev->driver->gem_free_object_unlocked(obj);
-   } else if (dev->driver->gem_free_object) {
-   WARN_ON(!mutex_is_locked(>struct_mutex));
-
-   dev->driver->gem_free_object(obj);
-   }
 }
 EXPORT_SYMBOL(drm_gem_object_free);
 
@@ -999,21 +994,10 @@ EXPORT_SYMBOL(drm_gem_object_free);
 void
 drm_gem_object_put_unlocked(struct drm_gem_object *obj)
 {
-   struct drm_device *dev;
-
if (!obj)
return;
 
-   dev = obj->dev;
-
-   if (dev->driver->gem_free_object) {
-   might_lock(>struct_mutex);
-   if (kref_put_mutex(>refcount, drm_gem_object_free,
-   >struct_mutex))
-   mutex_unlock(>struct_mutex);
-   } else {
-   kref_put(>refcount, drm_gem_object_free);
-   }
+   kref_put(>refcount, drm_gem_object_free);
 }
 EXPORT_SYMBOL(drm_gem_object_put_unlocked);
 
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index 6d457652f199..e6eff508f687 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -327,14 +327,6 @@ struct drm_driver {
 */
void (*debugfs_init)(struct drm_minor *minor);
 
-   /**
-* @gem_free_object: deconstructor for drm_gem_objects
-*
-* This is deprecated and should not be used by new drivers. Use
-* _gem_object_funcs.free instead.
-*/
-   void (*gem_free_object) (struct drm_gem_object *obj);
-
/**
 * @gem_free_object_unlocked: deconstructor for drm_gem_objects
 *
diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
index 0b375069cd48..ec2d24a60a76 100644
--- a/include/drm/drm_gem.h
+++ b/include/drm/drm_gem.h
@@ -272,8 +272,9 @@ struct drm_gem_object {
 * attachment point for the device. This is invariant over the lifetime
 * of a gem object.
 *
-* The _driver.gem_free_object callback is responsible for cleaning
-* up the dma_buf attachment and references acquired at import time.
+* The _driver.gem_free_object_unlocked callback is responsible for
+* cleaning up the dma_buf attachment and references acquired at import
+* time.
 *
 * Note that the drm gem/prime core does not depend upon drivers setting
 * this field any more. So for drivers where this doesn't make sense
-- 
2.25.1

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


  1   2   >