date:20201108

Re: [PATCH] drm/msm: dsi: Constify dsi_host_ops

2020-11-08 Thread Sam Ravnborg

On Sun, Nov 08, 2020 at 11:37:38PM +0100, Rikard Falkeborn wrote:
> The only usage of dsi_host_ops is to assign its address to the ops field
> in the mipi_dsi_host struct, which is a const pointer. Make it const to
> allow the compiler to put it in read-only memory.
> 
> Signed-off-by: Rikard Falkeborn 
Reviewed-by: Sam Ravnborg 

With this patch all struct mipi_dsi_host_ops are const - good.
I expect the msm folks to pick it up.

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

Re: [PATCH] video: fbdev: riva: remove some unused varibles

2020-11-08 Thread Sam Ravnborg

Hi Alex,

On Sun, Nov 08, 2020 at 04:01:59PM +0800, Alex Shi wrote:
> Couple of variables are actually useless, remove them to save some gcc
> warning:
> drivers/video/fbdev/riva/riva_hw.c:250:21: warning: variable ‘mlwm’ set
> but not used [-Wunused-but-set-variable]
> drivers/video/fbdev/riva/riva_hw.c:665:15: warning: variable ‘vraw’ set
> but not used [-Wunused-but-set-variable]
> drivers/video/fbdev/riva/riva_hw.c:665:9: warning: variable ‘craw’ set
> but not used [-Wunused-but-set-variable]
> drivers/video/fbdev/riva/riva_hw.c:659:73: warning: variable ‘align’ set
> but not used [-Wunused-but-set-variable]
> drivers/video/fbdev/riva/riva_hw.c:659:50: warning: variable
> ‘color_key_enable’ set but not used [-Wunused-but-set-variable]
> 
> Signed-off-by: Alex Shi 
> Cc: Antonino Daplas  
> Cc: linux-fb...@vger.kernel.org 
> Cc: dri-devel@lists.freedesktop.org 
> Cc: linux-ker...@vger.kernel.org 

Thanks, applied to drm-misc-next. The fix will appear in -next in a week
or so.

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

Re: [PATCH v1] video: hyperv_fb: include vmalloc.h

2020-11-08 Thread Sam Ravnborg

Hi Olaf.

On Fri, Nov 06, 2020 at 07:39:41PM +0100, Olaf Hering wrote:
> hvfb_getmem uses vzalloc, therefore vmalloc.h should be included.
> 
> Fixes commit d21987d709e807ba7bbf47044deb56a3c02e8be4 ("video: hyperv:
> hyperv_fb: Support deferred IO for Hyper-V frame buffer driver")
> 
> Signed-off-by: Olaf Hering 

Thanks.
Applied to drm-misc-fixes - as it smells like a build fix in some
configurations.

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

Re: [PATCH] drm/panel: simple: Add flags to boe_nv133fhm_n61

2020-11-08 Thread Sam Ravnborg

Hi Stephen
On Fri, Nov 06, 2020 at 10:23:33AM -0800, Stephen Boyd wrote:
> Reading the EDID of this panel shows that these flags should be set. Set
> them so that we match what is in the EDID.
> 
> Cc: Douglas Anderson 
> Cc: Bjorn Andersson 
> Fixes: b0c664cc80e8 ("panel: simple: Add BOE NV133FHM-N61")
> Signed-off-by: Stephen Boyd 

Applied to drm-misc-next as I could not see this was needed in mainline.
Or at least not urgently.
Let me know if this should be expeditet to current -rc

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

[Bug 209987] Memory leak in amdgpu_dm_update_connector_after_detect

2020-11-08 Thread bugzilla-daemon

https://bugzilla.kernel.org/show_bug.cgi?id=209987

--- Comment #3 from Lee Starnes (lstarnes1...@gmail.com) ---
Created attachment 293577
  --> https://bugzilla.kernel.org/attachment.cgi?id=293577=edit
proposed patch

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 209987] Memory leak in amdgpu_dm_update_connector_after_detect

2020-11-08 Thread bugzilla-daemon

https://bugzilla.kernel.org/show_bug.cgi?id=209987

--- Comment #2 from Lee Starnes (lstarnes1...@gmail.com) ---
It looks like this can be fixed by setting aconnector->num_modes to the return
value from drm_add_edid_modes. At least one other place in amdgpu_dm.c sets
struct amdgpu_dm_connector.num_modes to the return value of drm_add_edid_modes
like this. I'm not familiar enough with AMDGPU or DRM internals to know if this
will mess anything up.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 00/16] drm/exynos: Convert driver to drm bridge

2020-11-08 Thread Inki Dae

Hi Michael,

Thanks for your contribution.

20. 9. 11. 오후 10:53에 Michael Tretter 이(가) 쓴 글:
> This is v2 of the series to convert the Exynos MIPI DSI driver into a drm
> bridge and make it usable with other drivers. Although the driver is
> converted, it still supports the component framework API to stay compliant
> with the Exynos DRM driver.
> 
> The Exynos MIPI DSI Phy is also found on the i.MX8M Mini. However, on the
> i.MX8M Mini, the bridge is driven by an LCDIF display controller instead of
> the Exynos Decon. The driver for the LCDIF does not use the component
> framework, but uses drm bridges.
> 
> I don't have any Exynos SoC to actually test the series. I build a dummy to
> test the bridge with a component driver, to make sure that at least the
> initialization is working. Furthermore, tested the driver as a bridge with a
> few additional unfinished patches on the i.MX8M Mini EVK. However, somebody
> should verify that the driver is still working on Exynos hardware.
> 
> I also changed the order of the patches to first make the driver more platform
> independent (patches 2 to 8), then convert to a drm bridge driver (patches 10

Just a fundamental question,
A MIPI-DSI(Display Serial Interface) bus device would be one of an encoder type 
of devices not bridge such as DSI to LVDS and LVDS to DSI bridge devices, and 
also image enhancer and image compressor in case of Exynos.
Why do you want to convert such MIPI-DSI driver to bridge type of driver? Seems 
not sensible. The reason would be just to share MIPI-DSI phy driver for Exynos 
with i.MX8M Mini?

Thanks,
Inki Dae


> to 13) and finally expose the API, split the code and move the platform
> independent driver to the bridges (patches 14 - 16). Hopefully this simplifies
> testing/bisecting and helps me to understand potential error reports.
> 
> Also I added host_ops for attach/detach and the tearing effect handler to make
> the calls into the platform code more visible.
> 
> Furthermore, the series should now apply to linux-next and correctly build the
> exynos_defconfig.
> 
> Thanks,
> 
> Michael
> 
> Changelog:
> 
> v2:
> - rebase on linux-next
> - verify with exynos_defconfig
> - fix crashes reported by Marek Szyprowski Exynos3250-based Rinato
> - reorder patches
> - add host_ops for platform specific code
> - roughly test component framework integration with dummy
> 
> Michael Tretter (16):
>   drm/encoder: remove obsolete documentation of bridge
>   drm/exynos: remove in_bridge_node from exynos_dsi
>   drm/exynos: use exynos_dsi as drvdata
>   drm/exynos: extract helper functions for probe
>   drm/exynos: move dsi host registration to probe
>   drm/exynos: shift register values to fields on write
>   drm/exynos: use identifier instead of register offsets
>   drm/exynos: add host_ops callback for platform drivers
>   drm/exynos: add callback for tearing effect handler
>   drm/exynos: implement a drm bridge
>   drm/exynos: convert encoder functions to bridge function
>   drm/exynos: configure mode on drm bridge
>   drm/exynos: get encoder from bridge whenever possible
>   drm/exynos: add API functions for platform drivers
>   drm/exynos: split out platform specific code
>   drm/exynos: move bridge driver to bridges
> 
>  drivers/gpu/drm/bridge/Kconfig  |9 +
>  drivers/gpu/drm/bridge/Makefile |1 +
>  drivers/gpu/drm/bridge/samsung-dsim.c   | 1790 +
>  drivers/gpu/drm/exynos/Kconfig  |5 +-
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c | 1927 ++-
>  include/drm/bridge/samsung-dsim.h   |   64 +
>  include/drm/drm_encoder.h   |1 -
>  7 files changed, 2027 insertions(+), 1770 deletions(-)
>  create mode 100644 drivers/gpu/drm/bridge/samsung-dsim.c
>  create mode 100644 include/drm/bridge/samsung-dsim.h
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 07/23] mtd: spi-nor: controllers: hisi-sfc: Demote non-conformant kernel-doc

2020-11-08 Thread Vignesh Raghavendra



On 11/2/20 5:23 PM, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
> 
>  drivers/mtd/spi-nor/controllers/hisi-sfc.c:328: warning: Function parameter 
> or member 'np' not described in 'hisi_spi_nor_register'
>  drivers/mtd/spi-nor/controllers/hisi-sfc.c:328: warning: Function parameter 
> or member 'host' not described in 'hisi_spi_nor_register'
> 
> Cc: Tudor Ambarus 
> Cc: Miquel Raynal 
> Cc: Richard Weinberger 
> Cc: Vignesh Raghavendra 
> Cc: Sumit Semwal 
> Cc: "Christian König" 
> Cc: linux-...@lists.infradead.org
> Cc: linux-me...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: linaro-mm-...@lists.linaro.org
> Signed-off-by: Lee Jones 
> ---
>  drivers/mtd/spi-nor/controllers/hisi-sfc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/mtd/spi-nor/controllers/hisi-sfc.c 
> b/drivers/mtd/spi-nor/controllers/hisi-sfc.c
> index 95c502173cbda..7c26f8f565cba 100644
> --- a/drivers/mtd/spi-nor/controllers/hisi-sfc.c
> +++ b/drivers/mtd/spi-nor/controllers/hisi-sfc.c
> @@ -320,7 +320,7 @@ static const struct spi_nor_controller_ops 
> hisi_controller_ops = {
>   .write = hisi_spi_nor_write,
>  };
>  
> -/**
> +/*
>   * Get spi flash device information and register it as a mtd device.
>   */
>  static int hisi_spi_nor_register(struct device_node *np,
> 

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

Re: [PATCH v2 04/16] drm/exynos: extract helper functions for probe

2020-11-08 Thread Inki Dae



20. 11. 8. 오전 7:27에 Sam Ravnborg 이(가) 쓴 글:
> On Fri, Sep 11, 2020 at 03:54:01PM +0200, Michael Tretter wrote:
>> As the driver shall be usable with drivers that use the component
>> framework and drivers that don't, split the common probing code into a
>> separate function that can be called from different locations.
>>
>> Signed-off-by: Michael Tretter 
> Reviewed-by: Sam Ravnborg 

This patch and other are related to what this patch series do. However, this 
patch makes Exynos board not working yet.
So excepting patches 2 to 3, I will wait for that this patch series will be 
fixed and reviewed more.

Thanks,
Inki Dae

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

Re: [PATCH v2 03/16] drm/exynos: use exynos_dsi as drvdata

2020-11-08 Thread Inki Dae



20. 11. 8. 오전 7:24에 Sam Ravnborg 이(가) 쓴 글:
> On Fri, Sep 11, 2020 at 03:54:00PM +0200, Michael Tretter wrote:
>> Use the exynos_dsi as drvdata instead of the encoder to further decouple
>> the driver from the encoder.
>>
>> Signed-off-by: Michael Tretter 
> Reviewed-by: Sam Ravnborg 
> 
> Likewise, the exynos people are expected to pick this up.

Cleanup patch so picked it up.

Thanks,
Inki Dae


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

Re: [PATCH v2 02/16] drm/exynos: remove in_bridge_node from exynos_dsi

2020-11-08 Thread Inki Dae



20. 11. 8. 오전 7:19에 Sam Ravnborg 이(가) 쓴 글:
> On Fri, Sep 11, 2020 at 03:53:59PM +0200, Michael Tretter wrote:
>> We do not need to keep a reference to the in_bridge_node, but we can
>> simply drop it, once we found and attached the previous bridge.
>>
>> Signed-off-by: Michael Tretter 
> Reviewed-by: Sam Ravnborg 
> 
> Note: I expect exynos people to pick it up.

Cleanup patch so picked it up.

Thanks,
Inki Dae

> 
>   Sam
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://protect2.fireeye.com/v1/url?k=0ba8a77f-54339e66-0ba92c30-000babff3793-ff3020eaa6c16149=1=eadf6490-86ef-461e-b39a-892e3aec0194=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

2020-11-08 Thread Stephen Rothwell

Hi all,

On Tue, 3 Nov 2020 14:21:08 +1100 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the drm-misc tree got a conflict in:
> 
>   drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> 
> between commit:
> 
>   e8a982355f96 ("drm/amd/display: Add tracepoint for amdgpu_dm")
> 
> from the amdgpu tree and commit:
> 
>   29b77ad7b9ca ("drm/atomic: Pass the full state to CRTC atomic_check")
> 
> from the drm-misc tree.
> 
> I fixed it up (see below) and can 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.
>  
> diff --cc drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 28dcaae06993,86fd4420f128..
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@@ -6003,19 -5514,19 +6003,21 @@@ static void dm_update_crtc_active_plane
>   }
>   
>   static int dm_crtc_helper_atomic_check(struct drm_crtc *crtc,
> -struct drm_crtc_state *state)
> +struct drm_atomic_state *state)
>   {
> + struct drm_crtc_state *crtc_state = drm_atomic_get_new_crtc_state(state,
> +   crtc);
>   struct amdgpu_device *adev = drm_to_adev(crtc->dev);
>   struct dc *dc = adev->dm.dc;
> - struct dm_crtc_state *dm_crtc_state = to_dm_crtc_state(state);
> + struct dm_crtc_state *dm_crtc_state = to_dm_crtc_state(crtc_state);
>   int ret = -EINVAL;
>   
> - trace_amdgpu_dm_crtc_atomic_check(state);
> ++trace_amdgpu_dm_crtc_atomic_check(crtc_state);
>  +
> - dm_update_crtc_active_planes(crtc, state);
> + dm_update_crtc_active_planes(crtc, crtc_state);
>   
>   if (unlikely(!dm_crtc_state->stream &&
> -  modeset_required(state, NULL, dm_crtc_state->stream))) {
> +  modeset_required(crtc_state, NULL, 
> dm_crtc_state->stream))) {
>   WARN_ON(1);
>   return ret;
>   }

This is now a conflict between the drm tree and the amdgpu tree.

-- 
Cheers,
Stephen Rothwell


pgpp7DmkQXnCU.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/4] drm/ttm: add multihop infrastrucutre (v2)

2020-11-08 Thread Dave Airlie

From: Dave Airlie 

Currently drivers get called to move a buffer, but if they have to
move it temporarily through another space (SYSTEM->VRAM via TT)
then they can end up with a lot of ttm->driver->ttm call stacks,
if the temprorary space moves requires eviction.

Instead of letting the driver do all the placement/space for the
temporary, allow it to report back (-EMULTIHOP) and a placement (hop)
to the move code, which will then do the temporary move, and the
correct placement move afterwards.

This removes a lot of code from drivers, at the expense of
adding some midlayering. I've some further ideas on how to turn
it inside out, but I think this is a good solution to the call
stack problems.

v2: separate out the driver patches, add WARN for getting
MULTHOP in paths we shouldn't (Daniel)

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c|  3 +-
 drivers/gpu/drm/drm_gem_vram_helper.c  |  3 +-
 drivers/gpu/drm/nouveau/nouveau_bo.c   |  3 +-
 drivers/gpu/drm/qxl/qxl_ttm.c  |  3 +-
 drivers/gpu/drm/radeon/radeon_ttm.c|  3 +-
 drivers/gpu/drm/ttm/ttm_bo.c   | 68 +++---
 drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c |  3 +-
 include/drm/ttm/ttm_bo_driver.h|  7 ++-
 8 files changed, 77 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index c01c060e4ac5..ce0d82802333 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -656,7 +656,8 @@ static bool amdgpu_mem_visible(struct amdgpu_device *adev,
  */
 static int amdgpu_bo_move(struct ttm_buffer_object *bo, bool evict,
  struct ttm_operation_ctx *ctx,
- struct ttm_resource *new_mem)
+ struct ttm_resource *new_mem,
+ struct ttm_place *hop)
 {
struct amdgpu_device *adev;
struct amdgpu_bo *abo;
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c 
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 16d68c04ea5d..2cec7b1482b8 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -964,7 +964,8 @@ static void bo_driver_delete_mem_notify(struct 
ttm_buffer_object *bo)
 static int bo_driver_move(struct ttm_buffer_object *bo,
  bool evict,
  struct ttm_operation_ctx *ctx,
- struct ttm_resource *new_mem)
+ struct ttm_resource *new_mem,
+ struct ttm_place *hop)
 {
struct drm_gem_vram_object *gbo;
 
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 8133377d865d..fee07b9d19ed 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1023,7 +1023,8 @@ nouveau_bo_vm_cleanup(struct ttm_buffer_object *bo,
 static int
 nouveau_bo_move(struct ttm_buffer_object *bo, bool evict,
struct ttm_operation_ctx *ctx,
-   struct ttm_resource *new_reg)
+   struct ttm_resource *new_reg,
+   struct ttm_place *hop)
 {
struct nouveau_drm *drm = nouveau_bdev(bo->bdev);
struct nouveau_bo *nvbo = nouveau_bo(bo);
diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
index a80d59634143..128c38c8a837 100644
--- a/drivers/gpu/drm/qxl/qxl_ttm.c
+++ b/drivers/gpu/drm/qxl/qxl_ttm.c
@@ -140,7 +140,8 @@ static void qxl_bo_move_notify(struct ttm_buffer_object *bo,
 
 static int qxl_bo_move(struct ttm_buffer_object *bo, bool evict,
   struct ttm_operation_ctx *ctx,
-  struct ttm_resource *new_mem)
+  struct ttm_resource *new_mem,
+  struct ttm_place *hop)
 {
struct ttm_resource *old_mem = >mem;
int ret;
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 95038ac3382e..29062dbea299 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -303,7 +303,8 @@ static int radeon_move_ram_vram(struct ttm_buffer_object 
*bo,
 
 static int radeon_bo_move(struct ttm_buffer_object *bo, bool evict,
  struct ttm_operation_ctx *ctx,
- struct ttm_resource *new_mem)
+ struct ttm_resource *new_mem,
+ struct ttm_place *hop)
 {
struct radeon_device *rdev;
struct radeon_bo *rbo;
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index e2a124b3affb..9f840f2a7836 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -231,7 +231,8 @@ EXPORT_SYMBOL(ttm_bo_bulk_move_lru_tail);
 
 static int ttm_bo_handle_move_mem(struct ttm_buffer_object *bo,
  struct ttm_resource *mem, bool evict,
-

[PATCH 3/4] drm/nouveau/ttm: use multihop

2020-11-08 Thread Dave Airlie

From: Dave Airlie 

This removes the code to move resources directly between
SYSTEM and VRAM in favour of using the core ttm mulithop code.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/nouveau/nouveau_bo.c | 112 ---
 1 file changed, 13 insertions(+), 99 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index fee07b9d19ed..2b7720f412c1 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -861,96 +861,6 @@ nouveau_bo_move_init(struct nouveau_drm *drm)
NV_INFO(drm, "MM: using %s for buffer copies\n", name);
 }
 
-static int
-nouveau_bo_move_flipd(struct ttm_buffer_object *bo, bool evict,
- struct ttm_operation_ctx *ctx,
- struct ttm_resource *new_reg)
-{
-   struct ttm_place placement_memtype = {
-   .fpfn = 0,
-   .lpfn = 0,
-   .mem_type = TTM_PL_TT,
-   .flags = 0
-   };
-   struct ttm_placement placement;
-   struct ttm_resource tmp_reg;
-   int ret;
-
-   placement.num_placement = placement.num_busy_placement = 1;
-   placement.placement = placement.busy_placement = _memtype;
-
-   tmp_reg = *new_reg;
-   tmp_reg.mm_node = NULL;
-   ret = ttm_bo_mem_space(bo, , _reg, ctx);
-   if (ret)
-   return ret;
-
-   ret = ttm_tt_populate(bo->bdev, bo->ttm, ctx);
-   if (ret)
-   goto out;
-
-   ret = nouveau_ttm_tt_bind(bo->bdev, bo->ttm, _reg);
-   if (ret)
-   goto out;
-
-   ret = nouveau_bo_move_m2mf(bo, true, ctx, _reg);
-   if (ret)
-   goto out;
-
-   ret = ttm_bo_wait_ctx(bo, ctx);
-   if (ret)
-   goto out;
-
-   nouveau_ttm_tt_unbind(bo->bdev, bo->ttm);
-   ttm_resource_free(bo, >mem);
-   ttm_bo_assign_mem(bo, _reg);
-out:
-   ttm_resource_free(bo, _reg);
-   return ret;
-}
-
-static int
-nouveau_bo_move_flips(struct ttm_buffer_object *bo, bool evict,
- struct ttm_operation_ctx *ctx,
- struct ttm_resource *new_reg)
-{
-   struct ttm_place placement_memtype = {
-   .fpfn = 0,
-   .lpfn = 0,
-   .mem_type = TTM_PL_TT,
-   .flags = 0
-   };
-   struct ttm_placement placement;
-   struct ttm_resource tmp_reg;
-   int ret;
-
-   placement.num_placement = placement.num_busy_placement = 1;
-   placement.placement = placement.busy_placement = _memtype;
-
-   tmp_reg = *new_reg;
-   tmp_reg.mm_node = NULL;
-   ret = ttm_bo_mem_space(bo, , _reg, ctx);
-   if (ret)
-   return ret;
-
-   ret = ttm_tt_populate(bo->bdev, bo->ttm, ctx);
-   if (unlikely(ret != 0))
-   return ret;
-
-   ret = nouveau_ttm_tt_bind(bo->bdev, bo->ttm, _reg);
-   if (unlikely(ret != 0))
-   return ret;
-
-   ttm_bo_assign_mem(bo, _reg);
-   ret = nouveau_bo_move_m2mf(bo, true, ctx, new_reg);
-   if (ret)
-   goto out;
-
-out:
-   ttm_resource_free(bo, _reg);
-   return ret;
-}
-
 static void
 nouveau_bo_move_ntfy(struct ttm_buffer_object *bo, bool evict,
 struct ttm_resource *new_reg)
@@ -1032,6 +942,17 @@ nouveau_bo_move(struct ttm_buffer_object *bo, bool evict,
struct nouveau_drm_tile *new_tile = NULL;
int ret = 0;
 
+   if ((old_reg->mem_type == TTM_PL_SYSTEM &&
+new_reg->mem_type == TTM_PL_VRAM) ||
+   (old_reg->mem_type == TTM_PL_VRAM &&
+new_reg->mem_type == TTM_PL_SYSTEM)) {
+   hop->fpfn = 0;
+   hop->lpfn = 0;
+   hop->mem_type = TTM_PL_TT;
+   hop->flags = 0;
+   return -EMULTIHOP;
+   }
+
if (new_reg->mem_type == TTM_PL_TT) {
ret = nouveau_ttm_tt_bind(bo->bdev, bo->ttm, new_reg);
if (ret)
@@ -1074,15 +995,8 @@ nouveau_bo_move(struct ttm_buffer_object *bo, bool evict,
 
/* Hardware assisted copy. */
if (drm->ttm.move) {
-   if (new_reg->mem_type == TTM_PL_SYSTEM)
-   ret = nouveau_bo_move_flipd(bo, evict, ctx,
-   new_reg);
-   else if (old_reg->mem_type == TTM_PL_SYSTEM)
-   ret = nouveau_bo_move_flips(bo, evict, ctx,
-   new_reg);
-   else
-   ret = nouveau_bo_move_m2mf(bo, evict, ctx,
-  new_reg);
+   ret = nouveau_bo_move_m2mf(bo, evict, ctx,
+  new_reg);
if (!ret)
goto out;
}
-- 
2.27.0

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

[PATCH 4/4] drm/radeon/ttm: use multihop

2020-11-08 Thread Dave Airlie

From: Dave Airlie 

This removes the code to move resources directly between
SYSTEM and VRAM in favour of using the core ttm mulithop code.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/radeon/radeon_ttm.c | 119 +++-
 1 file changed, 13 insertions(+), 106 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 29062dbea299..788655ebafdb 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -206,101 +206,6 @@ static int radeon_move_blit(struct ttm_buffer_object *bo,
return r;
 }
 
-static int radeon_move_vram_ram(struct ttm_buffer_object *bo,
-   bool evict,
-   struct ttm_operation_ctx *ctx,
-   struct ttm_resource *new_mem)
-{
-   struct ttm_resource *old_mem = >mem;
-   struct ttm_resource tmp_mem;
-   struct ttm_place placements;
-   struct ttm_placement placement;
-   int r;
-
-   tmp_mem = *new_mem;
-   tmp_mem.mm_node = NULL;
-   placement.num_placement = 1;
-   placement.placement = 
-   placement.num_busy_placement = 1;
-   placement.busy_placement = 
-   placements.fpfn = 0;
-   placements.lpfn = 0;
-   placements.mem_type = TTM_PL_TT;
-   placements.flags = 0;
-   r = ttm_bo_mem_space(bo, , _mem, ctx);
-   if (unlikely(r)) {
-   return r;
-   }
-
-   r = ttm_tt_populate(bo->bdev, bo->ttm, ctx);
-   if (unlikely(r)) {
-   goto out_cleanup;
-   }
-
-   r = radeon_ttm_tt_bind(bo->bdev, bo->ttm, _mem);
-   if (unlikely(r)) {
-   goto out_cleanup;
-   }
-   r = radeon_move_blit(bo, true, _mem, old_mem);
-   if (unlikely(r)) {
-   goto out_cleanup;
-   }
-   r = ttm_bo_wait_ctx(bo, ctx);
-   if (unlikely(r))
-   goto out_cleanup;
-
-   radeon_ttm_tt_unbind(bo->bdev, bo->ttm);
-   ttm_resource_free(bo, >mem);
-   ttm_bo_assign_mem(bo, new_mem);
-out_cleanup:
-   ttm_resource_free(bo, _mem);
-   return r;
-}
-
-static int radeon_move_ram_vram(struct ttm_buffer_object *bo,
-   bool evict,
-   struct ttm_operation_ctx *ctx,
-   struct ttm_resource *new_mem)
-{
-   struct ttm_resource *old_mem = >mem;
-   struct ttm_resource tmp_mem;
-   struct ttm_placement placement;
-   struct ttm_place placements;
-   int r;
-
-   tmp_mem = *new_mem;
-   tmp_mem.mm_node = NULL;
-   placement.num_placement = 1;
-   placement.placement = 
-   placement.num_busy_placement = 1;
-   placement.busy_placement = 
-   placements.fpfn = 0;
-   placements.lpfn = 0;
-   placements.mem_type = TTM_PL_TT;
-   placements.flags = 0;
-   r = ttm_bo_mem_space(bo, , _mem, ctx);
-   if (unlikely(r)) {
-   return r;
-   }
-
-   r = ttm_tt_populate(bo->bdev, bo->ttm, ctx);
-   if (unlikely(r))
-   goto out_cleanup;
-
-   r = radeon_ttm_tt_bind(bo->bdev, bo->ttm, _mem);
-   if (unlikely(r))
-   goto out_cleanup;
-
-   ttm_bo_assign_mem(bo, _mem);
-   r = radeon_move_blit(bo, true, new_mem, old_mem);
-   if (unlikely(r)) {
-   goto out_cleanup;
-   }
-out_cleanup:
-   ttm_resource_free(bo, _mem);
-   return r;
-}
-
 static int radeon_bo_move(struct ttm_buffer_object *bo, bool evict,
  struct ttm_operation_ctx *ctx,
  struct ttm_resource *new_mem,
@@ -311,6 +216,17 @@ static int radeon_bo_move(struct ttm_buffer_object *bo, 
bool evict,
struct ttm_resource *old_mem = >mem;
int r;
 
+   if ((old_mem->mem_type == TTM_PL_SYSTEM &&
+new_mem->mem_type == TTM_PL_VRAM) ||
+   (old_mem->mem_type == TTM_PL_VRAM &&
+new_mem->mem_type == TTM_PL_SYSTEM)) {
+   hop->fpfn = 0;
+   hop->lpfn = 0;
+   hop->mem_type = TTM_PL_TT;
+   hop->flags = 0;
+   return -EMULTIHOP;
+   }
+
if (new_mem->mem_type == TTM_PL_TT) {
r = radeon_ttm_tt_bind(bo->bdev, bo->ttm, new_mem);
if (r)
@@ -351,17 +267,8 @@ static int radeon_bo_move(struct ttm_buffer_object *bo, 
bool evict,
goto memcpy;
}
 
-   if (old_mem->mem_type == TTM_PL_VRAM &&
-   new_mem->mem_type == TTM_PL_SYSTEM) {
-   r = radeon_move_vram_ram(bo, evict, ctx, new_mem);
-   } else if (old_mem->mem_type == TTM_PL_SYSTEM &&
-  new_mem->mem_type == TTM_PL_VRAM) {
-   r = radeon_move_ram_vram(bo, evict, ctx, new_mem);
-   } else {
-   r = radeon_move_blit(bo, evict,
-new_mem, old_mem);
-   }
-
+   r = radeon_move_blit(bo, evict,
+

[PATCH 2/4] drm/amdgpu/ttm: use multihop

2020-11-08 Thread Dave Airlie

From: Dave Airlie 

This removes the code to move resources directly between
SYSTEM and VRAM in favour of using the core ttm mulithop code.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 136 +++-
 1 file changed, 13 insertions(+), 123 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index ce0d82802333..e1458d575aa9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -512,119 +512,6 @@ static int amdgpu_move_blit(struct ttm_buffer_object *bo,
return r;
 }
 
-/**
- * amdgpu_move_vram_ram - Copy VRAM buffer to RAM buffer
- *
- * Called by amdgpu_bo_move().
- */
-static int amdgpu_move_vram_ram(struct ttm_buffer_object *bo, bool evict,
-   struct ttm_operation_ctx *ctx,
-   struct ttm_resource *new_mem)
-{
-   struct ttm_resource *old_mem = >mem;
-   struct ttm_resource tmp_mem;
-   struct ttm_place placements;
-   struct ttm_placement placement;
-   int r;
-
-   /* create space/pages for new_mem in GTT space */
-   tmp_mem = *new_mem;
-   tmp_mem.mm_node = NULL;
-   placement.num_placement = 1;
-   placement.placement = 
-   placement.num_busy_placement = 1;
-   placement.busy_placement = 
-   placements.fpfn = 0;
-   placements.lpfn = 0;
-   placements.mem_type = TTM_PL_TT;
-   placements.flags = 0;
-   r = ttm_bo_mem_space(bo, , _mem, ctx);
-   if (unlikely(r)) {
-   pr_err("Failed to find GTT space for blit from VRAM\n");
-   return r;
-   }
-
-   r = ttm_tt_populate(bo->bdev, bo->ttm, ctx);
-   if (unlikely(r))
-   goto out_cleanup;
-
-   /* Bind the memory to the GTT space */
-   r = amdgpu_ttm_backend_bind(bo->bdev, bo->ttm, _mem);
-   if (unlikely(r)) {
-   goto out_cleanup;
-   }
-
-   /* blit VRAM to GTT */
-   r = amdgpu_move_blit(bo, evict, _mem, old_mem);
-   if (unlikely(r)) {
-   goto out_cleanup;
-   }
-
-   r = ttm_bo_wait_ctx(bo, ctx);
-   if (unlikely(r))
-   goto out_cleanup;
-
-   amdgpu_ttm_backend_unbind(bo->bdev, bo->ttm);
-   ttm_resource_free(bo, >mem);
-   ttm_bo_assign_mem(bo, new_mem);
-out_cleanup:
-   ttm_resource_free(bo, _mem);
-   return r;
-}
-
-/**
- * amdgpu_move_ram_vram - Copy buffer from RAM to VRAM
- *
- * Called by amdgpu_bo_move().
- */
-static int amdgpu_move_ram_vram(struct ttm_buffer_object *bo, bool evict,
-   struct ttm_operation_ctx *ctx,
-   struct ttm_resource *new_mem)
-{
-   struct ttm_resource *old_mem = >mem;
-   struct ttm_resource tmp_mem;
-   struct ttm_placement placement;
-   struct ttm_place placements;
-   int r;
-
-   /* make space in GTT for old_mem buffer */
-   tmp_mem = *new_mem;
-   tmp_mem.mm_node = NULL;
-   placement.num_placement = 1;
-   placement.placement = 
-   placement.num_busy_placement = 1;
-   placement.busy_placement = 
-   placements.fpfn = 0;
-   placements.lpfn = 0;
-   placements.mem_type = TTM_PL_TT;
-   placements.flags = 0;
-   r = ttm_bo_mem_space(bo, , _mem, ctx);
-   if (unlikely(r)) {
-   pr_err("Failed to find GTT space for blit to VRAM\n");
-   return r;
-   }
-
-   /* move/bind old memory to GTT space */
-   r = ttm_tt_populate(bo->bdev, bo->ttm, ctx);
-   if (unlikely(r))
-   return r;
-
-   r = amdgpu_ttm_backend_bind(bo->bdev, bo->ttm, _mem);
-   if (unlikely(r)) {
-   goto out_cleanup;
-   }
-
-   ttm_bo_assign_mem(bo, _mem);
-   /* copy to VRAM */
-   r = amdgpu_move_blit(bo, evict, new_mem, old_mem);
-   if (unlikely(r)) {
-   goto out_cleanup;
-   }
-out_cleanup:
-   ttm_resource_free(bo, _mem);
-   return r;
-}
-
 /**
  * amdgpu_mem_visible - Check that memory can be accessed by ttm_bo_move_memcpy
  *
@@ -664,6 +551,17 @@ static int amdgpu_bo_move(struct ttm_buffer_object *bo, 
bool evict,
struct ttm_resource *old_mem = >mem;
int r;
 
+   if ((old_mem->mem_type == TTM_PL_SYSTEM &&
+new_mem->mem_type == TTM_PL_VRAM) ||
+   (old_mem->mem_type == TTM_PL_VRAM &&
+new_mem->mem_type == TTM_PL_SYSTEM)) {
+   hop->fpfn = 0;
+   hop->lpfn = 0;
+   hop->mem_type = TTM_PL_TT;
+   hop->flags = 0;
+   return -EMULTIHOP;
+   }
+
if (new_mem->mem_type == TTM_PL_TT) {
r = amdgpu_ttm_backend_bind(bo->bdev, bo->ttm, new_mem);
if (r)
@@ -717,16 +615,8 @@ static int amdgpu_bo_move(struct ttm_buffer_object *bo, 
bool evict,
goto memcpy;
}
 
-   if (old_mem->mem_type ==

ttm multihop split out v2

2020-11-08 Thread Dave Airlie

This is the multhop patch split out per driver, and with the
changes Daniel requested.

Sorry it took a while, got distracted with other things.

Dave.


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

[PATCH 2/7] soc: sunxi: Deal with the MBUS DMA offsets in a central place

2020-11-08 Thread Maxime Ripard

So far most of the drivers with the MBUS quirks had to duplicate the
code to deal with DT compatibility and enforcing the DMA offsets.

Let's move for a more maintainable solution by putting everything in a
notifier that would take care of setting up the DMA offsets for all the
MBUS devices.

Suggested-by: Robin Murphy 
Signed-off-by: Maxime Ripard 
---
 drivers/soc/sunxi/Kconfig  |   8 ++
 drivers/soc/sunxi/Makefile |   1 +
 drivers/soc/sunxi/sunxi_mbus.c | 132 +
 3 files changed, 141 insertions(+)
 create mode 100644 drivers/soc/sunxi/sunxi_mbus.c

diff --git a/drivers/soc/sunxi/Kconfig b/drivers/soc/sunxi/Kconfig
index f10fd6cae13e..1fef0e711056 100644
--- a/drivers/soc/sunxi/Kconfig
+++ b/drivers/soc/sunxi/Kconfig
@@ -2,6 +2,14 @@
 #
 # Allwinner sunXi SoC drivers
 #
+
+config SUNXI_MBUS
+   bool
+   default ARCH_SUNXI
+   help
+ Say y to enable the fixups needed to support the Allwinner
+ MBUS DMA quirks.
+
 config SUNXI_SRAM
bool
default ARCH_SUNXI
diff --git a/drivers/soc/sunxi/Makefile b/drivers/soc/sunxi/Makefile
index 7816fbbec387..549159571d4f 100644
--- a/drivers/soc/sunxi/Makefile
+++ b/drivers/soc/sunxi/Makefile
@@ -1,2 +1,3 @@
 # SPDX-License-Identifier: GPL-2.0-only
+obj-$(CONFIG_SUNXI_MBUS) +=sunxi_mbus.o
 obj-$(CONFIG_SUNXI_SRAM) +=sunxi_sram.o
diff --git a/drivers/soc/sunxi/sunxi_mbus.c b/drivers/soc/sunxi/sunxi_mbus.c
new file mode 100644
index ..a9d077f73c3a
--- /dev/null
+++ b/drivers/soc/sunxi/sunxi_mbus.c
@@ -0,0 +1,132 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (C) 2020 Maxime Ripard  */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static const char * const sunxi_mbus_devices[] = {
+   /*
+* The display engine virtual devices are not strictly speaking
+* connected to the MBUS, but since DRM will perform all the
+* memory allocations and DMA operations through that device, we
+* need to have the quirk on those devices too.
+*/
+   "allwinner,sun4i-a10-display-engine",
+   "allwinner,sun5i-a10s-display-engine",
+   "allwinner,sun5i-a13-display-engine",
+   "allwinner,sun6i-a31-display-engine",
+   "allwinner,sun6i-a31s-display-engine",
+   "allwinner,sun7i-a20-display-engine",
+   "allwinner,sun8i-a23-display-engine",
+   "allwinner,sun8i-a33-display-engine",
+   "allwinner,sun8i-a83t-display-engine",
+   "allwinner,sun8i-h3-display-engine",
+   "allwinner,sun8i-r40-display-engine",
+   "allwinner,sun8i-v3s-display-engine",
+   "allwinner,sun9i-a80-display-engine",
+   "allwinner,sun50i-a64-display-engine",
+
+   /*
+* And now we have the regular devices connected to the MBUS
+* (that we know of).
+*/
+   "allwinner,sun4i-a10-csi1",
+   "allwinner,sun4i-a10-display-backend",
+   "allwinner,sun4i-a10-display-frontend",
+   "allwinner,sun4i-a10-video-engine",
+   "allwinner,sun5i-a13-display-backend",
+   "allwinner,sun5i-a13-video-engine",
+   "allwinner,sun6i-a31-csi",
+   "allwinner,sun6i-a31-display-backend",
+   "allwinner,sun7i-a20-csi0",
+   "allwinner,sun7i-a20-display-backend",
+   "allwinner,sun7i-a20-display-frontend",
+   "allwinner,sun7i-a20-video-engine",
+   "allwinner,sun8i-a23-display-backend",
+   "allwinner,sun8i-a23-display-frontend",
+   "allwinner,sun8i-a33-display-backend",
+   "allwinner,sun8i-a33-display-frontend",
+   "allwinner,sun8i-a33-video-engine",
+   "allwinner,sun8i-a83t-csi",
+   "allwinner,sun8i-h3-csi",
+   "allwinner,sun8i-h3-video-engine",
+   "allwinner,sun8i-v3s-csi",
+   "allwinner,sun9i-a80-display-backend",
+   "allwinner,sun50i-a64-csi",
+   "allwinner,sun50i-a64-video-engine",
+   "allwinner,sun50i-h5-video-engine",
+   NULL,
+};
+
+static int sunxi_mbus_notifier(struct notifier_block *nb,
+  unsigned long event, void *__dev)
+{
+   struct device *dev = __dev;
+   int ret;
+
+   if (event != BUS_NOTIFY_ADD_DEVICE)
+   return NOTIFY_DONE;
+
+   /*
+* Only the devices that need a large memory bandwidth do DMA
+* directly over the memory bus (called MBUS), instead of going
+* through the regular system bus.
+*/
+   if (!of_device_compatible_match(dev->of_node, sunxi_mbus_devices))
+   return NOTIFY_DONE;
+
+   /*
+* Devices with an interconnects property have the MBUS
+* relationship described in their DT and dealt with by
+* of_dma_configure, so we can just skip them.
+*
+* Older DTs or SoCs who are not clearly understood need to set
+* that DMA offset though.
+*/
+   if (of_find_property(dev->of_node, "interconnects", NULL))
+   return NOTIFY_DONE;
+
+   ret = dma_direct_set_offset(dev,

[V2] drm: msm: adreno: use IS_ERR() instead of null pointer check

2020-11-08 Thread Wang Qing

a6xx_gmu_get_mmio() never return null in case of error, but ERR_PTR(), so 
we should use IS_ERR() instead of null pointer check and IS_ERR_OR_NULL().

Signed-off-by: Wang Qing 
---
 drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 491fee4..82420f7
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -492,7 +492,7 @@ static void a6xx_gmu_rpmh_init(struct a6xx_gmu *gmu)
void __iomem *seqptr = a6xx_gmu_get_mmio(pdev, "gmu_pdc_seq");
uint32_t pdc_address_offset;
 
-   if (!pdcptr || !seqptr)
+   if (IS_ERR(pdcptr) || IS_ERR(seqptr))
goto err;
 
if (adreno_is_a618(adreno_gpu) || adreno_is_a640(adreno_gpu))
@@ -580,9 +580,9 @@ static void a6xx_gmu_rpmh_init(struct a6xx_gmu *gmu)
wmb();
 
 err:
-   if (!IS_ERR_OR_NULL(pdcptr))
+   if (!IS_ERR(pdcptr))
iounmap(pdcptr);
-   if (!IS_ERR_OR_NULL(seqptr))
+   if (!IS_ERR(seqptr))
iounmap(seqptr);
 }
 
-- 
2.7.4

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

Re: [PATCH v2] drm/vc4: replace idr_init() by idr_init_base()

2020-11-08 Thread Deepak R Varma

On Fri, Nov 06, 2020 at 11:52:49AM +0100, Maxime Ripard wrote:
> On Thu, Nov 05, 2020 at 01:24:14PM -0800, Eric Anholt wrote:
> > On Thu, Nov 5, 2020 at 12:21 PM Deepak R Varma  wrote:
> > >
> > > idr_init() uses base 0 which is an invalid identifier for this driver.
> > > The idr_alloc for this driver uses VC4_PERFMONID_MIN as start value for
> > > ID range and it is #defined to 1. The new function idr_init_base allows
> > > IDR to set the ID lookup from base 1. This avoids all lookups that
> > > otherwise starts from 0 since 0 is always unused / available.
> > >
> > > References: commit 6ce711f27500 ("idr: Make 1-based IDRs more efficient")
> > >
> > > Signed-off-by: Deepak R Varma 
> > > ---
> > > Changes since v1:
> > >- Change suggested by Eric Anholt
> > >  1. Use VC4_PERFMONID_MIN instead of magic number 1
> > >
> > >  drivers/gpu/drm/vc4/vc4_perfmon.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/vc4/vc4_perfmon.c 
> > > b/drivers/gpu/drm/vc4/vc4_perfmon.c
> > > index f4aa75efd16b..18abc06335c1 100644
> > > --- a/drivers/gpu/drm/vc4/vc4_perfmon.c
> > > +++ b/drivers/gpu/drm/vc4/vc4_perfmon.c
> > > @@ -77,7 +77,7 @@ struct vc4_perfmon *vc4_perfmon_find(struct vc4_file 
> > > *vc4file, int id)
> > >  void vc4_perfmon_open_file(struct vc4_file *vc4file)
> > >  {
> > > mutex_init(>perfmon.lock);
> > > -   idr_init(>perfmon.idr);
> > > +   idr_init_base(>perfmon.idr, VC4_PERFMONID_MIN);
> > >  }
> > >
> > >  static int vc4_perfmon_idr_del(int id, void *elem, void *data)
> > > --
> > > 2.25.1
> > 
> > Reviewed-by: Eric Anholt 
> > 
> > hopefully Maxime can apply it.
> 
> Applied, thanks!

Thank you all. Appreciate your time.

./drv

> Maxime


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

[PATCH] drm/msm: dsi: Constify dsi_host_ops

2020-11-08 Thread Rikard Falkeborn

The only usage of dsi_host_ops is to assign its address to the ops field
in the mipi_dsi_host struct, which is a const pointer. Make it const to
allow the compiler to put it in read-only memory.

Signed-off-by: Rikard Falkeborn 
---
 drivers/gpu/drm/msm/dsi/dsi_host.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 198db8d4cf3d..ab281cba0f08 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -1657,7 +1657,7 @@ static ssize_t dsi_host_transfer(struct mipi_dsi_host 
*host,
return ret;
 }
 
-static struct mipi_dsi_host_ops dsi_host_ops = {
+static const struct mipi_dsi_host_ops dsi_host_ops = {
.attach = dsi_host_attach,
.detach = dsi_host_detach,
.transfer = dsi_host_transfer,
-- 
2.29.2

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

Re: [PATCH v3 0/3] Reduce context clear batch size to avoid gpu hang

2020-11-08 Thread rwright

On Mon, Nov 02, 2020 at 12:57:10PM -0700, rwri...@hpe.com wrote:
> On Mon, Nov 02, 2020 at 10:48:54AM +0100, Hans de Goede wrote:
> > Hi,
> > 
> ...
> That said, if the i915 maintainers respond in favor of the simpler
> unconditional reduction of the batch size, I will be glad to
> propose a much simpler version of my patch.
> ...

I received a suggestion from Mika Kuoppala to test 
https://patchwork.freedesktop.org/patch/399174/?series=83531=1 as a
solution for the GPU hang I observed, and the test was successful.
I recommend this patch as a better approch than my own, as it 
addresses more general cases without introducing a new quirk.

--
Randy WrightUsmail: Hewlett Packard Enterprise
Email: rwri...@hpe.com  Servers Linux Enablement
Phone: (970) 898-0998   3404 E. Harmony Rd, Mailstop 36
Fort Collins, CO 80528-9599 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/7] drm/sun4i: backend: Fix probe failure with multiple backends

2020-11-08 Thread Maxime Ripard

Commit e0d072782c73 ("dma-mapping: introduce DMA range map, supplanting
dma_pfn_offset") introduced a regression in our code since the second
backed to probe will now get -EINVAL back from dma_direct_set_offset and
will prevent the entire DRM device from probing.

Ignore -EINVAL as a temporary measure to get it back working, before
removing that call entirely.

Fixes: e0d072782c73 ("dma-mapping: introduce DMA range map, supplanting 
dma_pfn_offset")
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/sun4i/sun4i_backend.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c 
b/drivers/gpu/drm/sun4i/sun4i_backend.c
index 77497b45f9a2..55960cbb1019 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -814,9 +814,15 @@ static int sun4i_backend_bind(struct device *dev, struct 
device *master,
 *
 * XXX(hch): this has no business in a driver and needs to move
 * to the device tree.
+*
+* If we have two subsequent calls to dma_direct_set_offset
+* returns -EINVAL. Unfortunately, this happens when we have two
+* backends in the system, and will result in the driver
+* reporting an error while it has been setup properly before.
+* Ignore EINVAL, but it should really be removed eventually.
 */
ret = dma_direct_set_offset(drm->dev, PHYS_OFFSET, 0, SZ_4G);
-   if (ret)
+   if (ret && ret != -EINVAL)
return ret;
}
 
-- 
2.28.0

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

Re: [PATCH v8 1/5] RDMA/umem: Support importing dma-buf as user memory region

2020-11-08 Thread Jason Gunthorpe

On Fri, Nov 06, 2020 at 04:34:07PM +, Xiong, Jianxin wrote:

> > The user could specify a length that is beyond the dma buf, can
> > the dma buf length be checked during get?
> 
> In order to check the length, the buffer needs to be mapped. That can be done.

Do DMA bufs even have definitate immutable lengths? Going to be a
probelm if they can shrink

> > Also page_size can be 0 because iova is not OK. iova should be
> > checked for alignment during get as well:
> > 
> >   iova & (PAGE_SIZE-1) == umem->addr & (PAGE_SIZE-1)
> 
> If ib_umem_dmabuf_map_pages is called during get this error is automatically 
> caught.

The ib_umem_find_best_pgsz() checks this equation, yes.

So you'd map the sgl before allocating the mkey? This then checks the
length and iova?

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

Re: [PATCH v3 00/56] Convert DSI code to use drm_mipi_dsi and drm_panel

2020-11-08 Thread H. Nikolaus Schaller

Hi Tomi,

> Am 06.11.2020 um 16:04 schrieb Tomi Valkeinen :
> 
>> 
>> I took the driver and make my omap4-sdp dts to use it. It probes for me, but 
>> stop after that:
>> 
>> [  119.346374] omapdss_dss 5800.dss: supply vdda_video not found, using 
>> dummy regulator
>> [  119.358398] DSS: OMAP DSS rev 4.0
>> [  119.680053] panel-dsi-cm 58004000.encoder.0: failed to get video timing, 
>> using defaults
>> [  119.695709] panel-dsi-cm 58004000.encoder.0: supply vpnl not found, using 
>> dummy regulator
>> [  119.711242] panel-dsi-cm 58004000.encoder.0: supply vddi not found, using 
>> dummy regulator
>> [  119.769470] panel-btl507212-w677l 58005000.encoder.0: w677l_probe
>> [  119.779388] panel-btl507212-w677l 58005000.encoder.0: w677l_probe ok
>> [  119.846679] omapdss_dss 5800.dss: bound 58001000.dispc (ops 
>> dispc_component_ops [omapdrm])
>> [  119.858673] omapdss_dss 5800.dss: bound 58004000.encoder (ops 
>> dsi_component_ops [omapdrm])
>> [  119.882629] omapdss_dss 5800.dss: bound 58005000.encoder (ops 
>> dsi_component_ops [omapdrm])
>> [  119.902069] omapdss_dss 5800.dss: bound 58006000.encoder (ops 
>> hdmi4_component_ops [omapdrm])
>> [  119.962066] dmm 4e00.dmm: initialized all PAT entries
>> [  120.014770] panel-btl507212-w677l 58005000.encoder.0: w677l_get_modes
>> 
>> I didn't debug yet where it's hanging. So you're not even getting the probe?
> 
> Oh, it's stuck in a loop trying to calculate suitable timings. It doesn't 
> find it, as I'm running on
> omap4, with just 2 datalanes instead of 4 which the panel needs. Looks like 
> the code could use some
> improvement there.
> 
> Anyway, possibly on omap5 it goes fine.

I have set up based on our complete letux-5.10-rc2 tree and maybe using our 
private config makes
the difference. Anyways, the driver is now probed and I can see the call to 
w677l_get_modes().

I have still no image and no calls to prepare/unprepare etc. but now I can 
start to debug on omap5.
And hopefully we are close to push the panel driver for review. And in a second 
step some device
tree for the Pyra.

The new tree is here: 
https://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/work-pyra-panel

BR and thanks,
Nikolaus

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

[PATCH v2 5/5] drm/msm: bump up the uapi version

2020-11-08 Thread Jonathan Marek

Increase the minor version to indicate the presence of new features.

Signed-off-by: Jonathan Marek 
---
 drivers/gpu/drm/msm/msm_drv.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 3f17acdf6594..7230d3c0eee5 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -39,9 +39,10 @@
  *   GEM object's debug name
  * - 1.5.0 - Add SUBMITQUERY_QUERY ioctl
  * - 1.6.0 - Syncobj support
+ * - 1.7.0 - MSM_BO_CACHED_COHERENT and DRM_IOCTL_MSM_GEM_SYNC_CACHE
  */
 #define MSM_VERSION_MAJOR  1
-#define MSM_VERSION_MINOR  6
+#define MSM_VERSION_MINOR  7
 #define MSM_VERSION_PATCHLEVEL 0
 
 static const struct drm_mode_config_funcs mode_config_funcs = {
-- 
2.26.1

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

Re: [PATCH v5 05/15] mm/frame-vector: Use FOLL_LONGTERM

2020-11-08 Thread Jason Gunthorpe

On Fri, Nov 06, 2020 at 11:01:57AM +0100, Daniel Vetter wrote:

> gpu drivers also tend to use vmf_insert_pfn* directly, so we can do
> on-demand paging and move buffers around. From what I glanced for
> lowest level we to the pte_mkspecial correctly (I think I convinced
> myself that vm_insert_pfn does that), but for pud/pmd levels it seems
> just yolo.
> 
> remap_pfn_range seems to indeed split down to pte level always.

Thats what it looked like to me too.
 
> >  From my reading, yes. See ioremap_try_huge_pmd().
> 
> The ioremap here shouldn't matter, since this is for kernel-internal
> mappings. So that's all fine I think.

Right, sorry to be unclear, we are talking about io_remap_pfn_range()
which is for userspace mappings in VMAs

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

[PATCH 7/7] media: sun8i-di: Remove the call to of_dma_configure

2020-11-08 Thread Maxime Ripard

of_dma_configure is called by the core before probe gets called so this
is redundant.

Signed-off-by: Maxime Ripard 
---
 drivers/media/platform/sunxi/sun8i-di/sun8i-di.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/media/platform/sunxi/sun8i-di/sun8i-di.c 
b/drivers/media/platform/sunxi/sun8i-di/sun8i-di.c
index ba5d07886607..ed863bf5ea80 100644
--- a/drivers/media/platform/sunxi/sun8i-di/sun8i-di.c
+++ b/drivers/media/platform/sunxi/sun8i-di/sun8i-di.c
@@ -825,10 +825,6 @@ static int deinterlace_probe(struct platform_device *pdev)
return ret;
}
 
-   ret = of_dma_configure(dev->dev, dev->dev->of_node, true);
-   if (ret)
-   return ret;
-
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
dev->base = devm_ioremap_resource(>dev, res);
if (IS_ERR(dev->base))
-- 
2.28.0

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

[PATCH v2 4/5] drm/msm: add DRM_MSM_GEM_SYNC_CACHE for non-coherent cache maintenance

2020-11-08 Thread Jonathan Marek

This makes it possible to use the non-coherent cached MSM_BO_CACHED mode,
which otherwise doesn't provide any method for cleaning/invalidating the
cache to sync with the device.

Signed-off-by: Jonathan Marek 
---
 drivers/gpu/drm/msm/msm_drv.c | 21 +
 drivers/gpu/drm/msm/msm_drv.h |  2 ++
 drivers/gpu/drm/msm/msm_gem.c | 23 +++
 include/uapi/drm/msm_drm.h| 20 
 4 files changed, 66 insertions(+)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index bae48afca82e..3f17acdf6594 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -959,6 +959,26 @@ static int msm_ioctl_submitqueue_close(struct drm_device 
*dev, void *data,
return msm_submitqueue_remove(file->driver_priv, id);
 }
 
+static int msm_ioctl_gem_sync_cache(struct drm_device *dev, void *data,
+   struct drm_file *file)
+{
+   struct drm_msm_gem_sync_cache *args = data;
+   struct drm_gem_object *obj;
+
+   if (args->flags & ~MSM_GEM_SYNC_CACHE_FLAGS)
+   return -EINVAL;
+
+   obj = drm_gem_object_lookup(file, args->handle);
+   if (!obj)
+   return -ENOENT;
+
+   msm_gem_sync_cache(obj, args->flags, args->offset, args->end);
+
+   drm_gem_object_put(obj);
+
+   return 0;
+}
+
 static const struct drm_ioctl_desc msm_ioctls[] = {
DRM_IOCTL_DEF_DRV(MSM_GET_PARAM,msm_ioctl_get_param,
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(MSM_GEM_NEW,  msm_ioctl_gem_new,  
DRM_RENDER_ALLOW),
@@ -971,6 +991,7 @@ static const struct drm_ioctl_desc msm_ioctls[] = {
DRM_IOCTL_DEF_DRV(MSM_SUBMITQUEUE_NEW,   msm_ioctl_submitqueue_new,   
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(MSM_SUBMITQUEUE_CLOSE, msm_ioctl_submitqueue_close, 
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(MSM_SUBMITQUEUE_QUERY, msm_ioctl_submitqueue_query, 
DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(MSM_GEM_SYNC_CACHE,msm_ioctl_gem_sync_cache,
DRM_RENDER_ALLOW),
 };
 
 static const struct vm_operations_struct vm_ops = {
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index 22ebecb28349..f170f843010e 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -318,6 +318,8 @@ void msm_gem_active_get(struct drm_gem_object *obj, struct 
msm_gpu *gpu);
 void msm_gem_active_put(struct drm_gem_object *obj);
 int msm_gem_cpu_prep(struct drm_gem_object *obj, uint32_t op, ktime_t 
*timeout);
 int msm_gem_cpu_fini(struct drm_gem_object *obj);
+void msm_gem_sync_cache(struct drm_gem_object *obj, uint32_t flags,
+   size_t range_start, size_t range_end);
 void msm_gem_free_object(struct drm_gem_object *obj);
 int msm_gem_new_handle(struct drm_device *dev, struct drm_file *file,
uint32_t size, uint32_t flags, uint32_t *handle, char *name);
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 3d8254b5de16..039738696f9a 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -797,6 +797,29 @@ int msm_gem_cpu_fini(struct drm_gem_object *obj)
return 0;
 }
 
+void msm_gem_sync_cache(struct drm_gem_object *obj, uint32_t flags,
+   size_t range_start, size_t range_end)
+{
+   struct msm_gem_object *msm_obj = to_msm_bo(obj);
+   struct device *dev = msm_obj->base.dev->dev;
+
+   /* exit early if get_pages() hasn't been called yet */
+   if (!msm_obj->pages)
+   return;
+
+   /* TODO: sync only the specified range */
+
+   if (flags & MSM_GEM_SYNC_FOR_DEVICE) {
+   dma_sync_sg_for_device(dev, msm_obj->sgt->sgl,
+   msm_obj->sgt->nents, DMA_TO_DEVICE);
+   }
+
+   if (flags & MSM_GEM_SYNC_FOR_CPU) {
+   dma_sync_sg_for_cpu(dev, msm_obj->sgt->sgl,
+   msm_obj->sgt->nents, DMA_FROM_DEVICE);
+   }
+}
+
 #ifdef CONFIG_DEBUG_FS
 static void describe_fence(struct dma_fence *fence, const char *type,
struct seq_file *m)
diff --git a/include/uapi/drm/msm_drm.h b/include/uapi/drm/msm_drm.h
index 474497e8743a..c8288f328528 100644
--- a/include/uapi/drm/msm_drm.h
+++ b/include/uapi/drm/msm_drm.h
@@ -319,6 +319,24 @@ struct drm_msm_submitqueue_query {
__u32 pad;
 };
 
+/*
+ * Host cache maintenance (relevant for MSM_BO_CACHED)
+ * driver may both clean/invalidate (flush) for clean
+ */
+
+#define MSM_GEM_SYNC_FOR_DEVICE0x1
+#define MSM_GEM_SYNC_FOR_CPU   0x2
+
+#define MSM_GEM_SYNC_CACHE_FLAGS   (MSM_GEM_SYNC_FOR_DEVICE | \
+MSM_GEM_SYNC_FOR_CPU)
+
+struct drm_msm_gem_sync_cache {
+   __u32 handle;
+   __u32 flags;
+   __u64 offset;
+   __u64 end;  /* offset + size */
+};
+
 #define DRM_MSM_GET_PARAM  0x00
 /* placeholder:
 #define DRM_MSM_SET_PARAM  0x01
@@ -336,6 +354,7 @@ struct

[PATCH 3/7] drm/sun4i: backend: Remove the MBUS quirks

2020-11-08 Thread Maxime Ripard

Now that the MBUS quirks are applied by our global notifier, we can
remove them from our DRM driver.

Suggested-by: Christoph Hellwig 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/sun4i/sun4i_backend.c | 19 ---
 1 file changed, 19 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c 
b/drivers/gpu/drm/sun4i/sun4i_backend.c
index 55960cbb1019..522e51a404cc 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -805,25 +805,6 @@ static int sun4i_backend_bind(struct device *dev, struct 
device *master,
ret = of_dma_configure(drm->dev, dev->of_node, true);
if (ret)
return ret;
-   } else {
-   /*
-* If we don't have the interconnect property, most likely
-* because of an old DT, we need to set the DMA offset by hand
-* on our device since the RAM mapping is at 0 for the DMA bus,
-* unlike the CPU.
-*
-* XXX(hch): this has no business in a driver and needs to move
-* to the device tree.
-*
-* If we have two subsequent calls to dma_direct_set_offset
-* returns -EINVAL. Unfortunately, this happens when we have two
-* backends in the system, and will result in the driver
-* reporting an error while it has been setup properly before.
-* Ignore EINVAL, but it should really be removed eventually.
-*/
-   ret = dma_direct_set_offset(drm->dev, PHYS_OFFSET, 0, SZ_4G);
-   if (ret && ret != -EINVAL)
-   return ret;
}
 
backend->engine.node = dev->of_node;
-- 
2.28.0

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

[PATCH 2/2] drm: omapdrm: dss: fix reference leak in dss_runtime_get

2020-11-08 Thread Zhang Qilong

pm_runtime_get_sync() will increment pm usage at first and it
will resume the device later. If runtime of the device has
error or device is in inaccessible state(or other error state),
resume operation will fail. If we do not call put operation to
decrease the reference, it will result in reference leak in
dss_runtime_get. Moreover, this device cannot enter the idle state
and always stay busy or other non-idle state later. So we should
fix it through adding pm_runtime_put_noidle.

Fixes: 7b295257a13d8 ("drm: omapdrm: dss: Pass DSS private structure to runtime 
PM functions")

Signed-off-by: Zhang Qilong 
---
 drivers/gpu/drm/omapdrm/dss/dss.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/dss.c 
b/drivers/gpu/drm/omapdrm/dss/dss.c
index 6ccbc29c4ce4..9571f3db6f71 100644
--- a/drivers/gpu/drm/omapdrm/dss/dss.c
+++ b/drivers/gpu/drm/omapdrm/dss/dss.c
@@ -858,8 +858,12 @@ int dss_runtime_get(struct dss_device *dss)
DSSDBG("dss_runtime_get\n");
 
r = pm_runtime_get_sync(>pdev->dev);
-   WARN_ON(r < 0);
-   return r < 0 ? r : 0;
+   if (WARN_ON(r < 0)) {
+   pm_runtime_put_noidle(>pdev->dev);
+   return r;
+   }
+
+   return 0;
 }
 
 void dss_runtime_put(struct dss_device *dss)
-- 
2.25.4

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

[PATCH] drm/panel: simple: Add flags to boe_nv133fhm_n61

2020-11-08 Thread Stephen Boyd

Reading the EDID of this panel shows that these flags should be set. Set
them so that we match what is in the EDID.

Cc: Douglas Anderson 
Cc: Bjorn Andersson 
Fixes: b0c664cc80e8 ("panel: simple: Add BOE NV133FHM-N61")
Signed-off-by: Stephen Boyd 
---
 drivers/gpu/drm/panel/panel-simple.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 2be358fb46f7..204674fccd64 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1327,6 +1327,7 @@ static const struct drm_display_mode 
boe_nv133fhm_n61_modes = {
.vsync_start = 1080 + 3,
.vsync_end = 1080 + 3 + 6,
.vtotal = 1080 + 3 + 6 + 31,
+   .flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC,
 };
 
 /* Also used for boe_nv133fhm_n62 */

base-commit: 3650b228f83adda7e5ee532e2b90429c03f7b9ec
-- 
Sent by a computer, using git, on the internet

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

Re: [PATCH 03/19] gpu: drm: imx: ipuv3-plane: Mark 'crtc_state' as __always_unused

2020-11-08 Thread Ahmad Fatoum

On 11/6/20 8:41 AM, Lee Jones wrote:
> On Thu, 05 Nov 2020, Ahmad Fatoum wrote:
> 
>> Hello Lee,
>>
>> On 11/5/20 3:45 PM, Lee Jones wrote:
>>> In the macro for_each_oldnew_crtc_in_state() 'crtc_state' is provided
>>> as a container for state->crtcs[i].new_state, but is not utilised in
>>> this use-case.  We cannot simply delete the variable, so here we tell
>>> the compiler that we're intentionally discarding the read value.
>>
>> for_each_oldnew_crtc_in_state already (void) casts the drm_crtc and the old
>> drm_crtc_state to silence unused-but-set-variable warning. Should we maybe
>> (void) cast the new crtc_state as well?
> 
> From what I saw, it only void casts the ones which aren't assigned.

How do you mean? I wonder if

 #define for_each_oldnew_crtc_in_state(__state, crtc, old_crtc_state, 
new_crtc_state, __i) \
for ((__i) = 0; \
 (__i) < (__state)->dev->mode_config.num_crtc;  \
 (__i)++)   \
for_each_if ((__state)->crtcs[__i].ptr &&   \
 ((crtc) = (__state)->crtcs[__i].ptr,   \
  (void)(crtc) /* Only to avoid 
unused-but-set-variable warning */, \
 (old_crtc_state) = 
(__state)->crtcs[__i].old_state, \
 (void)(old_crtc_state) /* Only to avoid 
unused-but-set-variable warning */, \
-(new_crtc_state) = 
(__state)->crtcs[__i].new_state, 1))
+(new_crtc_state) = 
(__state)->crtcs[__i].new_state, \
+(void)(new_crtc_state), 1))

wouldn't be better.

> 
>>> Fixes the following W=1 kernel build warning(s):
>>>
>>>  drivers/gpu/drm/imx/ipuv3-plane.c: In function ‘ipu_planes_assign_pre’:
>>>  drivers/gpu/drm/imx/ipuv3-plane.c:746:42: warning: variable ‘crtc_state’ 
>>> set but not used [-Wunused-but-set-variable]
>>>
>>> Cc: Philipp Zabel 
>>> Cc: David Airlie 
>>> Cc: Daniel Vetter 
>>> Cc: Shawn Guo 
>>> Cc: Sascha Hauer 
>>> Cc: Pengutronix Kernel Team 
>>> Cc: Fabio Estevam 
>>> Cc: NXP Linux Team 
>>> Cc: dri-devel@lists.freedesktop.org
>>> Signed-off-by: Lee Jones 
>>> ---
>>>  drivers/gpu/drm/imx/ipuv3-plane.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
>>> b/drivers/gpu/drm/imx/ipuv3-plane.c
>>> index 8a4235d9d9f1e..acc0a3ce4992f 100644
>>> --- a/drivers/gpu/drm/imx/ipuv3-plane.c
>>> +++ b/drivers/gpu/drm/imx/ipuv3-plane.c
>>> @@ -743,7 +743,7 @@ bool ipu_plane_atomic_update_pending(struct drm_plane 
>>> *plane)
>>>  int ipu_planes_assign_pre(struct drm_device *dev,
>>>   struct drm_atomic_state *state)
>>>  {
>>> -   struct drm_crtc_state *old_crtc_state, *crtc_state;
>>> +   struct drm_crtc_state *old_crtc_state, __always_unused *crtc_state;
>>> struct drm_plane_state *plane_state;
>>> struct ipu_plane_state *ipu_state;
>>> struct ipu_plane *ipu_plane;
>>>
>>
> 

-- 
Pengutronix e.K.   | |
Steuerwalder Str. 21   | http://www.pengutronix.de/  |
31137 Hildesheim, Germany  | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 5/7] media: sun6i: Remove the MBUS quirks

2020-11-08 Thread Maxime Ripard

Now that the MBUS quirks are applied by our global notifier, we can
remove them from our CSI driver for the A31.

Suggested-by: Christoph Hellwig 
Signed-off-by: Maxime Ripard 
---
 .../media/platform/sunxi/sun6i-csi/sun6i_csi.c  | 17 -
 1 file changed, 17 deletions(-)

diff --git a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c 
b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
index e69e14379fc6..27935f1e9555 100644
--- a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
+++ b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
@@ -881,14 +881,6 @@ static int sun6i_csi_resource_request(struct sun6i_csi_dev 
*sdev,
return 0;
 }
 
-/*
- * PHYS_OFFSET isn't available on all architectures. In order to
- * accommodate for COMPILE_TEST, let's define it to something dumb.
- */
-#if defined(CONFIG_COMPILE_TEST) && !defined(PHYS_OFFSET)
-#define PHYS_OFFSET 0
-#endif
-
 static int sun6i_csi_probe(struct platform_device *pdev)
 {
struct sun6i_csi_dev *sdev;
@@ -899,15 +891,6 @@ static int sun6i_csi_probe(struct platform_device *pdev)
return -ENOMEM;
 
sdev->dev = >dev;
-   /*
-* The DMA bus has the memory mapped at 0.
-*
-* XXX(hch): this has no business in a driver and needs to move
-* to the device tree.
-*/
-   ret = dma_direct_set_offset(sdev->dev, PHYS_OFFSET, 0, SZ_4G);
-   if (ret)
-   return ret;
 
ret = sun6i_csi_resource_request(sdev, pdev);
if (ret)
-- 
2.28.0

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

[PATCH 4/7] media: sun4i: Remove the MBUS quirks

2020-11-08 Thread Maxime Ripard

Now that the MBUS quirks are applied by our global notifier, we can
remove them from our CSI driver for the A10.

Suggested-by: Christoph Hellwig 
Signed-off-by: Maxime Ripard 
---
 .../platform/sunxi/sun4i-csi/sun4i_csi.c  | 27 ---
 1 file changed, 27 deletions(-)

diff --git a/drivers/media/platform/sunxi/sun4i-csi/sun4i_csi.c 
b/drivers/media/platform/sunxi/sun4i-csi/sun4i_csi.c
index eb15c8c725ca..ec46cff80fdb 100644
--- a/drivers/media/platform/sunxi/sun4i-csi/sun4i_csi.c
+++ b/drivers/media/platform/sunxi/sun4i-csi/sun4i_csi.c
@@ -167,33 +167,6 @@ static int sun4i_csi_probe(struct platform_device *pdev)
if (!csi->traits)
return -EINVAL;
 
-   /*
-* On Allwinner SoCs, some high memory bandwidth devices do DMA
-* directly over the memory bus (called MBUS), instead of the
-* system bus. The memory bus has a different addressing scheme
-* without the DRAM starting offset.
-*
-* In some cases this can be described by an interconnect in
-* the device tree. In other cases where the hardware is not
-* fully understood and the interconnect is left out of the
-* device tree, fall back to a default offset.
-*/
-   if (of_find_property(csi->dev->of_node, "interconnects", NULL)) {
-   ret = of_dma_configure(csi->dev, csi->dev->of_node, true);
-   if (ret)
-   return ret;
-   } else {
-   /*
-* XXX(hch): this has no business in a driver and needs to move
-* to the device tree.
-*/
-#ifdef PHYS_PFN_OFFSET
-   ret = dma_direct_set_offset(csi->dev, PHYS_OFFSET, 0, SZ_4G);
-   if (ret)
-   return ret;
-#endif
-   }
-
csi->mdev.dev = csi->dev;
strscpy(csi->mdev.model, "Allwinner Video Capture Device",
sizeof(csi->mdev.model));
-- 
2.28.0

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

Re: [PATCH v2] drm/vc4: replace idr_init() by idr_init_base()

2020-11-08 Thread Maxime Ripard

On Thu, Nov 05, 2020 at 01:24:14PM -0800, Eric Anholt wrote:
> On Thu, Nov 5, 2020 at 12:21 PM Deepak R Varma  wrote:
> >
> > idr_init() uses base 0 which is an invalid identifier for this driver.
> > The idr_alloc for this driver uses VC4_PERFMONID_MIN as start value for
> > ID range and it is #defined to 1. The new function idr_init_base allows
> > IDR to set the ID lookup from base 1. This avoids all lookups that
> > otherwise starts from 0 since 0 is always unused / available.
> >
> > References: commit 6ce711f27500 ("idr: Make 1-based IDRs more efficient")
> >
> > Signed-off-by: Deepak R Varma 
> > ---
> > Changes since v1:
> >- Change suggested by Eric Anholt
> >  1. Use VC4_PERFMONID_MIN instead of magic number 1
> >
> >  drivers/gpu/drm/vc4/vc4_perfmon.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/vc4/vc4_perfmon.c 
> > b/drivers/gpu/drm/vc4/vc4_perfmon.c
> > index f4aa75efd16b..18abc06335c1 100644
> > --- a/drivers/gpu/drm/vc4/vc4_perfmon.c
> > +++ b/drivers/gpu/drm/vc4/vc4_perfmon.c
> > @@ -77,7 +77,7 @@ struct vc4_perfmon *vc4_perfmon_find(struct vc4_file 
> > *vc4file, int id)
> >  void vc4_perfmon_open_file(struct vc4_file *vc4file)
> >  {
> > mutex_init(>perfmon.lock);
> > -   idr_init(>perfmon.idr);
> > +   idr_init_base(>perfmon.idr, VC4_PERFMONID_MIN);
> >  }
> >
> >  static int vc4_perfmon_idr_del(int id, void *elem, void *data)
> > --
> > 2.25.1
> 
> Reviewed-by: Eric Anholt 
> 
> hopefully Maxime can apply it.

Applied, thanks!
Maxime


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

Re: [PATCH] drm/stm: Enable RPM during fbdev registration

2020-11-08 Thread Marek Vasut


On 11/6/20 5:13 PM, Yannick FERTRE wrote:

Hi Marek,


Hi,


On 11/5/20 10:45 AM, Marek Vasut wrote:

On 11/5/20 10:39 AM, Daniel Vetter wrote:

On Wed, Nov 04, 2020 at 01:52:00PM +0100, Marek Vasut wrote:

Enable runtime PM before registering the fbdev emulation and disable it
afterward, otherwise register access to the LTDC IP during the fbdev
emulation registration might hang the system.

The problem happens because RPM is activated at the end of ltdc_load(),
but the fbdev emulation registration happens only after that, and ends
up calling ltdc_crtc_mode_set_nofb(), which checks whether RPM is active
and only if it is not active, calls pm_runtime_get_sync() to enable the
clock and so on. If the clock are not enabled, any register access in
ltdc_crtc_mode_set_nofb() could hang the platform completely.

This patch makes sure that ltdc_crtc_mode_set_nofb() is called within
pm_runtime_get_sync(), so with clock enabled.


[...]


This looks like you're papering over a bug in your modeset code. If
userspace later on does a setpar on the fbdev chardev, the exact same
thing could happen. You need to fix your modeset code to avoid this, not
sprinkle temporary rpm_get/put all over some top level entry points,
because you can't even patch those all.


I have a feeling all those pm_runtime_active() checks in the driver
might be the root cause of this ? I wonder why the code doesn't use
pm_runtime_{get,put}_sync() only when accessing registers. Thoughts?


First line of function ltdc_crtc_mode_set_nofb check the pm_runtime to
avoid to access registers without clock enabled.



static void ltdc_crtc_mode_set_nofb(struct drm_crtc *crtc)
{
...
if (!pm_runtime_active(ddev->dev)) {
ret = pm_runtime_get_sync(ddev->dev);

I test the fb with framebuffer console, & it works fine on my side.
Do you test fb on a old kernel?
How can I reproduce your issue?


I observed sporadic hangs and tracked it down to the fbdev registration, 
which calls this code. Note that pm_runtime_active() here will return 0, 
because it was already activated in ltdc_load().


My question in reply to Daniel was more geared toward why do we even 
have all these checks in the driver, wouldn't it be better to just 
always call pm_runtime_get_sync()/pm_runtime_put_sync() in the code 
which requires the hardware to be active ?

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

[PATCH 6/7] media: cedrus: Remove the MBUS quirks

2020-11-08 Thread Maxime Ripard

Now that the MBUS quirks are applied by our global notifier, we can
remove them from Cedrus. Since the only quirk was whether or not we had
to apply that DMA quirk, we can also remove the quirks infrastructure.

Suggested-by: Christoph Hellwig 
Signed-off-by: Maxime Ripard 
---
 drivers/staging/media/sunxi/cedrus/cedrus.c|  1 -
 drivers/staging/media/sunxi/cedrus/cedrus.h|  3 ---
 drivers/staging/media/sunxi/cedrus/cedrus_hw.c | 18 --
 3 files changed, 22 deletions(-)

diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c 
b/drivers/staging/media/sunxi/cedrus/cedrus.c
index e0e35502e34a..d5fca10ea5b4 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
@@ -523,7 +523,6 @@ static const struct cedrus_variant sun50i_h5_cedrus_variant 
= {
 static const struct cedrus_variant sun50i_h6_cedrus_variant = {
.capabilities   = CEDRUS_CAPABILITY_UNTILED |
  CEDRUS_CAPABILITY_H265_DEC,
-   .quirks = CEDRUS_QUIRK_NO_DMA_OFFSET,
.mod_rate   = 6,
 };
 
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.h 
b/drivers/staging/media/sunxi/cedrus/cedrus.h
index 93c843ae14bb..626090a5811c 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus.h
+++ b/drivers/staging/media/sunxi/cedrus/cedrus.h
@@ -29,8 +29,6 @@
 #define CEDRUS_CAPABILITY_UNTILED  BIT(0)
 #define CEDRUS_CAPABILITY_H265_DEC BIT(1)
 
-#define CEDRUS_QUIRK_NO_DMA_OFFSET BIT(0)
-
 enum cedrus_codec {
CEDRUS_CODEC_MPEG2,
CEDRUS_CODEC_H264,
@@ -150,7 +148,6 @@ struct cedrus_dec_ops {
 
 struct cedrus_variant {
unsigned intcapabilities;
-   unsigned intquirks;
unsigned intmod_rate;
 };
 
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_hw.c 
b/drivers/staging/media/sunxi/cedrus/cedrus_hw.c
index bcf050a04ffc..286c7fe844c3 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus_hw.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus_hw.c
@@ -222,24 +222,6 @@ int cedrus_hw_probe(struct cedrus_dev *dev)
return ret;
}
 
-   /*
-* The VPU is only able to handle bus addresses so we have to subtract
-* the RAM offset to the physcal addresses.
-*
-* This information will eventually be obtained from device-tree.
-*
-* XXX(hch): this has no business in a driver and needs to move
-* to the device tree.
-*/
-
-#ifdef PHYS_PFN_OFFSET
-   if (!(variant->quirks & CEDRUS_QUIRK_NO_DMA_OFFSET)) {
-   ret = dma_direct_set_offset(dev->dev, PHYS_OFFSET, 0, SZ_4G);
-   if (ret)
-   return ret;
-   }
-#endif
-
ret = of_reserved_mem_device_init(dev->dev);
if (ret && ret != -ENODEV) {
dev_err(dev->dev, "Failed to reserve memory\n");
-- 
2.28.0

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

Re: [PATCH v8 3/5] RDMA/uverbs: Add uverbs command for dma-buf based MR registration

2020-11-08 Thread Jason Gunthorpe

On Fri, Nov 06, 2020 at 04:20:34PM +, Xiong, Jianxin wrote:
> > From: Jason Gunthorpe 
> > Sent: Thursday, November 05, 2020 4:13 PM
> > To: Xiong, Jianxin 
> > Cc: linux-r...@vger.kernel.org; dri-devel@lists.freedesktop.org; Doug 
> > Ledford ; Leon Romanovsky
> > ; Sumit Semwal ; Christian Koenig 
> > ; Vetter, Daniel
> > 
> > Subject: Re: [PATCH v8 3/5] RDMA/uverbs: Add uverbs command for dma-buf 
> > based MR registration
> > 
> > On Thu, Nov 05, 2020 at 02:48:07PM -0800, Jianxin Xiong wrote:
> > 
> > > + ret = ib_check_mr_access(access_flags);
> > > + if (ret)
> > > + return ret;
> > 
> > This should also reject unsupportable flags like ACCESS_ON_DEMAND and 
> > HUGETLB
> 
> Will do.

Just change IB_ACCESS_SUPPORTED to the list of allowed flags in this
context


> > > + mr->device  = pd->device;
> > > + mr->pd  = pd;
> > > + mr->type= IB_MR_TYPE_USER;
> > > + mr->uobject = uobj;
> > > + atomic_inc(>usecnt);
> > 
> > Fix intending when copying code please
> 
> It could be due to a mix of tab and space. They look aligned in the source 
> file. Will fix.

The interior spaces before the = should not be there, we don't align ='s

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

[PATCH 0/2] drm: omapdrm: fix reference leak in runtime get ops

2020-11-08 Thread Zhang Qilong

pm_runtime_get_sync() will increment pm usage at first and it
will resume the device later. If runtime of the device has
error or device is in inaccessible state(or other error state),
resume operation will fail. If we do not call put operation to
decrease the reference, it will result in reference leak in
Moreover, this device cannot enter the idle state and always
stay busy or other non-idle state later. So we should fix it
through adding pm_runtime_put_noidle.

Zhang Qilong (2):
  drm: omapdrm: dsi: fix-reference-leak-in dsi_runtime_get.
  drm: omapdrm: dss: fix reference leak in dss_runtime_get

 drivers/gpu/drm/omapdrm/dss/dsi.c | 8 ++--
 drivers/gpu/drm/omapdrm/dss/dss.c | 8 ++--
 2 files changed, 12 insertions(+), 4 deletions(-)

-- 
2.25.4

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

[PATCH 0/7] sunxi: Remove the calls to dma_direct_set_offset

2020-11-08 Thread Maxime Ripard

Hi,

Here's an attempt to removing the dma_direct_set_offset calls we have in
numerous drivers and move all those quirks into a global notifier as suggested
by Robin.

Let me know what you think,
Maxime

Maxime Ripard (7):
  drm/sun4i: backend: Fix probe failure with multiple backends
  soc: sunxi: Deal with the MBUS DMA offsets in a central place
  drm/sun4i: backend: Remove the MBUS quirks
  media: sun4i: Remove the MBUS quirks
  media: sun6i: Remove the MBUS quirks
  media: cedrus: Remove the MBUS quirks
  media: sun8i-di: Remove the call to of_dma_configure

 drivers/gpu/drm/sun4i/sun4i_backend.c |  13 --
 .../platform/sunxi/sun4i-csi/sun4i_csi.c  |  27 
 .../platform/sunxi/sun6i-csi/sun6i_csi.c  |  17 ---
 .../media/platform/sunxi/sun8i-di/sun8i-di.c  |   4 -
 drivers/soc/sunxi/Kconfig |   8 ++
 drivers/soc/sunxi/Makefile|   1 +
 drivers/soc/sunxi/sunxi_mbus.c| 132 ++
 drivers/staging/media/sunxi/cedrus/cedrus.c   |   1 -
 drivers/staging/media/sunxi/cedrus/cedrus.h   |   3 -
 .../staging/media/sunxi/cedrus/cedrus_hw.c|  18 ---
 10 files changed, 141 insertions(+), 83 deletions(-)
 create mode 100644 drivers/soc/sunxi/sunxi_mbus.c

-- 
2.28.0

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

[PATCH v2 1/5] drm/msm: add MSM_BO_CACHED_COHERENT

2020-11-08 Thread Jonathan Marek

Add a new cache mode for creating coherent host-cached BOs.

Signed-off-by: Jonathan Marek 
Reviewed-by: Jordan Crouse 
---
 drivers/gpu/drm/msm/adreno/adreno_device.c | 1 +
 drivers/gpu/drm/msm/msm_drv.h  | 1 +
 drivers/gpu/drm/msm/msm_gem.c  | 8 
 include/uapi/drm/msm_drm.h | 5 ++---
 4 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c 
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index 58e03b20e1c7..21c9bc954f38 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -410,6 +410,7 @@ static int adreno_bind(struct device *dev, struct device 
*master, void *data)
config.rev.minor, config.rev.patchid);
 
priv->is_a2xx = config.rev.core == 2;
+   priv->has_cached_coherent = config.rev.core >= 6;
 
gpu = info->init(drm);
if (IS_ERR(gpu)) {
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index f33281ac7913..22ebecb28349 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -168,6 +168,7 @@ struct msm_drm_private {
struct msm_file_private *lastctx;
/* gpu is only set on open(), but we need this info earlier */
bool is_a2xx;
+   bool has_cached_coherent;
 
struct drm_fb_helper *fbdev;
 
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 04be4cf1..3d8254b5de16 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -420,6 +420,9 @@ static int msm_gem_pin_iova(struct drm_gem_object *obj,
if (msm_obj->flags & MSM_BO_MAP_PRIV)
prot |= IOMMU_PRIV;
 
+   if (msm_obj->flags & MSM_BO_CACHED_COHERENT)
+   prot |= IOMMU_CACHE;
+
WARN_ON(!mutex_is_locked(_obj->lock));
 
if (WARN_ON(msm_obj->madv != MSM_MADV_WILLNEED))
@@ -1004,6 +1007,7 @@ static int msm_gem_new_impl(struct drm_device *dev,
uint32_t size, uint32_t flags,
struct drm_gem_object **obj)
 {
+   struct msm_drm_private *priv = dev->dev_private;
struct msm_gem_object *msm_obj;
 
switch (flags & MSM_BO_CACHE_MASK) {
@@ -1011,6 +1015,10 @@ static int msm_gem_new_impl(struct drm_device *dev,
case MSM_BO_CACHED:
case MSM_BO_WC:
break;
+   case MSM_BO_CACHED_COHERENT:
+   if (priv->has_cached_coherent)
+   break;
+   /* fallthrough */
default:
DRM_DEV_ERROR(dev->dev, "invalid cache flag: %x\n",
(flags & MSM_BO_CACHE_MASK));
diff --git a/include/uapi/drm/msm_drm.h b/include/uapi/drm/msm_drm.h
index a6c1f3eb2623..474497e8743a 100644
--- a/include/uapi/drm/msm_drm.h
+++ b/include/uapi/drm/msm_drm.h
@@ -94,12 +94,11 @@ struct drm_msm_param {
 #define MSM_BO_CACHED0x0001
 #define MSM_BO_WC0x0002
 #define MSM_BO_UNCACHED  0x0004
+#define MSM_BO_CACHED_COHERENT 0x08
 
 #define MSM_BO_FLAGS (MSM_BO_SCANOUT | \
   MSM_BO_GPU_READONLY | \
-  MSM_BO_CACHED | \
-  MSM_BO_WC | \
-  MSM_BO_UNCACHED)
+  MSM_BO_CACHE_MASK)
 
 struct drm_msm_gem_new {
__u64 size;   /* in */
-- 
2.26.1

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

[PATCH v1] video: hyperv_fb: include vmalloc.h

2020-11-08 Thread Olaf Hering

hvfb_getmem uses vzalloc, therefore vmalloc.h should be included.

Fixes commit d21987d709e807ba7bbf47044deb56a3c02e8be4 ("video: hyperv:
hyperv_fb: Support deferred IO for Hyper-V frame buffer driver")

Signed-off-by: Olaf Hering 
---
 drivers/video/fbdev/hyperv_fb.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_fb.c
index e36fb1a0ecdb..5bc86f481a78 100644
--- a/drivers/video/fbdev/hyperv_fb.c
+++ b/drivers/video/fbdev/hyperv_fb.c
@@ -47,6 +47,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] video: fbdev: riva: remove some unused varibles

2020-11-08 Thread Alex Shi

Couple of variables are actually useless, remove them to save some gcc
warning:
drivers/video/fbdev/riva/riva_hw.c:250:21: warning: variable ‘mlwm’ set
but not used [-Wunused-but-set-variable]
drivers/video/fbdev/riva/riva_hw.c:665:15: warning: variable ‘vraw’ set
but not used [-Wunused-but-set-variable]
drivers/video/fbdev/riva/riva_hw.c:665:9: warning: variable ‘craw’ set
but not used [-Wunused-but-set-variable]
drivers/video/fbdev/riva/riva_hw.c:659:73: warning: variable ‘align’ set
but not used [-Wunused-but-set-variable]
drivers/video/fbdev/riva/riva_hw.c:659:50: warning: variable
‘color_key_enable’ set but not used [-Wunused-but-set-variable]

Signed-off-by: Alex Shi 
Cc: Antonino Daplas  
Cc: linux-fb...@vger.kernel.org 
Cc: dri-devel@lists.freedesktop.org 
Cc: linux-ker...@vger.kernel.org 
---
 drivers/video/fbdev/riva/riva_hw.c | 14 +++---
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/drivers/video/fbdev/riva/riva_hw.c 
b/drivers/video/fbdev/riva/riva_hw.c
index 4168ac464565..bcf9c4b4de31 100644
--- a/drivers/video/fbdev/riva/riva_hw.c
+++ b/drivers/video/fbdev/riva/riva_hw.c
@@ -247,14 +247,13 @@ static int nv3_iterate(nv3_fifo_info *res_info, 
nv3_sim_state * state, nv3_arb_i
 int mburst_size = 32;
 int mmisses, gmisses, vmisses;
 int misses;
-int vlwm, glwm, mlwm;
+int vlwm, glwm;
 int last, next, cur;
 int max_gfsize ;
 long ns;
 
 vlwm = 0;
 glwm = 0;
-mlwm = 0;
 vfsize = 0;
 gfsize = 0;
 cur = ainfo->cur;
@@ -656,13 +655,12 @@ static char nv3_get_param(nv3_fifo_info *res_info, 
nv3_sim_state * state, nv3_ar
 nv4_sim_state *arb
 )
 {
-int data, pagemiss, cas,width, video_enable, color_key_enable, bpp, align;
+int data, pagemiss, cas,width, video_enable, bpp;
 int nvclks, mclks, pclks, vpagemiss, crtpagemiss, vbs;
 int found, mclk_extra, mclk_loop, cbs, m1, p1;
 int mclk_freq, pclk_freq, nvclk_freq, mp_enable;
 int us_m, us_n, us_p, video_drain_rate, crtc_drain_rate;
 int vpm_us, us_video, vlwm, video_fill_us, cpm_us, us_crt,clwm;
-int craw, vraw;
 
 fifo->valid = 1;
 pclk_freq = arb->pclk_khz;
@@ -672,9 +670,7 @@ static char nv3_get_param(nv3_fifo_info *res_info, 
nv3_sim_state * state, nv3_ar
 cas = arb->mem_latency;
 width = arb->memory_width >> 6;
 video_enable = arb->enable_video;
-color_key_enable = arb->gr_during_vid;
 bpp = arb->pix_bpp;
-align = arb->mem_aligned;
 mp_enable = arb->enable_mp;
 clwm = 0;
 vlwm = 0;
@@ -782,8 +778,6 @@ static char nv3_get_param(nv3_fifo_info *res_info, 
nv3_sim_state * state, nv3_ar
 mclk_extra--;
 }
 }
-craw = clwm;
-vraw = vlwm;
 if (clwm < 384) clwm = 384;
 if (vlwm < 128) vlwm = 128;
 data = (int)(clwm);
@@ -842,7 +836,7 @@ static char nv3_get_param(nv3_fifo_info *res_info, 
nv3_sim_state * state, nv3_ar
 nv10_sim_state *arb
 )
 {
-int data, pagemiss, cas,width, video_enable, color_key_enable, bpp, align;
+int data, pagemiss, cas,width, video_enable, bpp;
 int nvclks, mclks, pclks, vpagemiss, crtpagemiss, vbs;
 int nvclk_fill, us_extra;
 int found, mclk_extra, mclk_loop, cbs, m1;
@@ -863,9 +857,7 @@ static char nv3_get_param(nv3_fifo_info *res_info, 
nv3_sim_state * state, nv3_ar
 cas = arb->mem_latency;
 width = arb->memory_width/64;
 video_enable = arb->enable_video;
-color_key_enable = arb->gr_during_vid;
 bpp = arb->pix_bpp;
-align = arb->mem_aligned;
 mp_enable = arb->enable_mp;
 clwm = 0;
 vlwm = 1024;
-- 
1.8.3.1

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

Re: [PATCH v8 4/5] RDMA/mlx5: Support dma-buf based userspace memory region

2020-11-08 Thread Jason Gunthorpe

On Fri, Nov 06, 2020 at 01:11:38AM +, Xiong, Jianxin wrote:
> > On Thu, Nov 05, 2020 at 02:48:08PM -0800, Jianxin Xiong wrote:
> > > @@ -966,7 +969,10 @@ static struct mlx5_ib_mr *alloc_mr_from_cache(struct 
> > > ib_pd *pd,
> > >   struct mlx5_ib_mr *mr;
> > >   unsigned int page_size;
> > >
> > > - page_size = mlx5_umem_find_best_pgsz(umem, mkc, log_page_size, 0, iova);
> > > + if (umem->is_dmabuf)
> > > + page_size = ib_umem_find_best_pgsz(umem, PAGE_SIZE, iova);
> > 
> > You said the sgl is not set here, why doesn't this crash? It is certainly 
> > wrong to call this function without a SGL.
> 
> The sgl is NULL, and nmap is 0. The 'for_each_sg' loop is just skipped and 
> won't crash.

Just wire this to 4k it is clearer than calling some no-op pgsz


> > > + if (!mr->cache_ent) {
> > > + mlx5_core_destroy_mkey(mr->dev->mdev, >mmkey);
> > > + WARN_ON(mr->descs);
> > > + }
> > > +}
> > 
> > I would expect this to call ib_umem_dmabuf_unmap_pages() ?
> > 
> > Who calls it on the dereg path?
> > 
> > This looks quite strange to me, it calls ib_umem_dmabuf_unmap_pages() only 
> > from the invalidate callback?
> 
> It is also called from ib_umem_dmabuf_release(). 

Hmm, that is no how the other APIs work, the unmap should be paired
with the map in the caller, and the sequence for destroy should be

 invalidate
 unmap
 destroy_mkey
 release_umem

I have another series coming that makes the other three destroy flows
much closer to that ideal.

> > I feel uneasy how this seems to assume everything works sanely, we can have 
> > parallel page faults so pagefault_dmabuf_mr() can be called
> > multiple times after an invalidation, and it doesn't protect itself against 
> > calling ib_umem_dmabuf_map_pages() twice.
> > 
> > Perhaps the umem code should keep track of the current map state and exit 
> > if there is already a sgl. NULL or not NULL sgl would do and
> > seems quite reasonable.
> 
> Ib_umem_dmabuf_map() already checks the sgl and will do nothing if it is 
> already set.

How? What I see in patch 1 is an unconditonal call to
dma_buf_map_attachment() ?

> > > + if (is_dmabuf_mr(mr))
> > > + return pagefault_dmabuf_mr(mr, umem_dmabuf, user_va,
> > > +bcnt, bytes_mapped, flags);
> > 
> > But this doesn't care about user_va or bcnt it just triggers the whole 
> > thing to be remapped, so why calculate it?
> 
> The range check is still needed, in order to catch application
> errors of using incorrect address or count in verbs command. Passing
> the values further in is to allow pagefault_dmabuf_mr to generate
> return value and set bytes_mapped in a way consistent with the page
> fault handler chain.

The HW validates the range. The range check in the ODP case is to
protect against a HW bug that would cause the kernel to
malfunction. For dmabuf you don't need to do it

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

[PATCH v2 0/5] drm/msm: support for host-cached BOs

2020-11-08 Thread Jonathan Marek

This is to support cached and cached-coherent memory types in vulkan.

v2:
 - added patches 2/3 to enable using dma_ops_bypass
 - changed DRM_MSM_GEM_SYNC_CACHE patch to use dma_sync_sg_for_device()
   and dma_sync_sg_for_cpu(), and renamed sync flags.

Not sure I did the right thing with for the dma_ops_bypass part,
this is what I came up with reading the emails.

Jonathan Marek (5):
  drm/msm: add MSM_BO_CACHED_COHERENT
  dma-direct: add dma_direct_bypass() to force direct ops
  drm/msm: call dma_direct_bypass()
  drm/msm: add DRM_MSM_GEM_SYNC_CACHE for non-coherent cache maintenance
  drm/msm: bump up the uapi version

 drivers/gpu/drm/msm/Kconfig|  1 +
 drivers/gpu/drm/msm/adreno/adreno_device.c |  1 +
 drivers/gpu/drm/msm/msm_drv.c  | 32 +++---
 drivers/gpu/drm/msm/msm_drv.h  |  3 ++
 drivers/gpu/drm/msm/msm_gem.c  | 31 +
 include/linux/dma-direct.h |  9 ++
 include/uapi/drm/msm_drm.h | 25 +++--
 kernel/dma/direct.c| 23 
 8 files changed, 118 insertions(+), 7 deletions(-)

-- 
2.26.1

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

[PATCH v2 3/5] drm/msm: call dma_direct_bypass()

2020-11-08 Thread Jonathan Marek

Always use direct dma ops and no swiotlb.

Note: arm-smmu-qcom already avoids creating iommu dma ops, but not
everything uses arm-smmu-qcom and this also sets the dma mask.

Signed-off-by: Jonathan Marek 
---
 drivers/gpu/drm/msm/Kconfig   | 1 +
 drivers/gpu/drm/msm/msm_drv.c | 8 +---
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
index e5816b498494..07c50405970a 100644
--- a/drivers/gpu/drm/msm/Kconfig
+++ b/drivers/gpu/drm/msm/Kconfig
@@ -20,6 +20,7 @@ config DRM_MSM
select SND_SOC_HDMI_CODEC if SND_SOC
select SYNC_FILE
select PM_OPP
+   select DMA_OPS_BYPASS
help
  DRM/KMS driver for MSM/snapdragon.
 
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 49685571dc0e..bae48afca82e 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -6,6 +6,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1288,10 +1289,11 @@ static int msm_pdev_probe(struct platform_device *pdev)
if (ret)
goto fail;
 
-   /* on all devices that I am aware of, iommu's which can map
-* any address the cpu can see are used:
+   /* always use direct dma ops and no swiotlb
+* note: arm-smmu-qcom already avoids creating iommu dma ops, but
+* not everything uses arm-smmu-qcom and this also sets the dma mask
 */
-   ret = dma_set_mask_and_coherent(>dev, ~0);
+   ret = dma_direct_bypass(>dev);
if (ret)
goto fail;
 
-- 
2.26.1

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

[PATCH 1/2] drm: omapdrm: dsi: fix-reference-leak-in dsi_runtime_get.

2020-11-08 Thread Zhang Qilong

pm_runtime_get_sync() will increment pm usage at first and it
will resume the device later. If runtime of the device has
error or device is in inaccessible state(or other error state),
resume operation will fail. If we do not call put operation to
decrease the reference, it will result in reference leak in
dsi_runtime_get. Moreover, this device cannot enter the idle
state and always stay busy or other non-idle state later. So we
should fix it through adding pm_runtime_put_noidle.

Fixes: 4600ea9c49cc4 ("drm: omapdrm: dsi: Store the struct device pointer in 
struct dsi_data")

Signed-off-by: Zhang Qilong 
---
 drivers/gpu/drm/omapdrm/dss/dsi.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c 
b/drivers/gpu/drm/omapdrm/dss/dsi.c
index eeccf40bae41..f407d9c60ada 100644
--- a/drivers/gpu/drm/omapdrm/dss/dsi.c
+++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
@@ -1112,8 +1112,12 @@ static int dsi_runtime_get(struct dsi_data *dsi)
DSSDBG("dsi_runtime_get\n");
 
r = pm_runtime_get_sync(dsi->dev);
-   WARN_ON(r < 0);
-   return r < 0 ? r : 0;
+   if (WARN_ON(r < 0)) {
+   pm_runtime_put_noidle(dsi->dev);
+   return r;
+   }
+
+   return 0;
 }
 
 static void dsi_runtime_put(struct dsi_data *dsi)
-- 
2.25.4

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

Re: [PATCH 3/3] drm/msm/dpu: add support for clk and bw scaling for display

2020-11-08 Thread Amit Pundir

On Tue, 4 Aug 2020 at 21:09, Rob Clark  wrote:
>
> On Thu, Jul 16, 2020 at 4:36 AM Kalyan Thota  wrote:
> >
> > This change adds support to scale src clk and bandwidth as
> > per composition requirements.
> >
> > Interconnect registration for bw has been moved to mdp
> > device node from mdss to facilitate the scaling.
> >
> > Changes in v1:
> >  - Address armv7 compilation issues with the patch (Rob)
> >
> > Signed-off-by: Kalyan Thota 
>
> Reviewed-by: Rob Clark 
>

Hi Kalyan, Rob,

This patch broke the display on the PocoF1 phone
(sdm845-xiaomi-beryllium.dts) running AOSP.
I can boot to UI but the display is frozen soon after that and
dmesg is full of following errors:

[drm:dpu_core_perf_crtc_update:397] [dpu error]crtc-65: failed to
update bus bw vote
[drm:dpu_core_perf_crtc_check:203] [dpu error]exceeds bandwidth:
7649746kb > 680kb
[drm:dpu_crtc_atomic_check:969] [dpu error]crtc65 failed performance check -7
[drm:dpu_core_perf_crtc_check:203] [dpu error]exceeds bandwidth:
7649746kb > 680kb
[drm:dpu_crtc_atomic_check:969] [dpu error]crtc65 failed performance check -7
[drm:dpu_core_perf_crtc_check:203] [dpu error]exceeds bandwidth:
7649746kb > 680kb
[drm:dpu_crtc_atomic_check:969] [dpu error]crtc65 failed performance check -7

Here is the full dmesg https://pastebin.ubuntu.com/p/PcSdNgMnYw/.
Georgi pointed out following patch but it didn't help,
https://lore.kernel.org/dri-devel/20201027102304.945424-1-dmitry.barysh...@linaro.org/
Am I missing any other followup fix?

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

Re: [PATCH v5 05/15] mm/frame-vector: Use FOLL_LONGTERM

2020-11-08 Thread Jason Gunthorpe

On Fri, Nov 06, 2020 at 11:27:59AM +0100, Daniel Vetter wrote:
> On Fri, Nov 6, 2020 at 11:01 AM Daniel Vetter  wrote:
> >
> > On Fri, Nov 6, 2020 at 5:08 AM John Hubbard  wrote:
> > >
> > > On 11/5/20 4:49 AM, Jason Gunthorpe wrote:
> > > > On Thu, Nov 05, 2020 at 10:25:24AM +0100, Daniel Vetter wrote:
> > > >>> /*
> > > >>>   * If we can't determine whether or not a pte is special, then fail 
> > > >>> immediately
> > > >>>   * for ptes. Note, we can still pin HugeTLB and THP as these are 
> > > >>> guaranteed not
> > > >>>   * to be special.
> > > >>>   *
> > > >>>   * For a futex to be placed on a THP tail page, get_futex_key 
> > > >>> requires a
> > > >>>   * get_user_pages_fast_only implementation that can pin pages. Thus 
> > > >>> it's still
> > > >>>   * useful to have gup_huge_pmd even if we can't operate on ptes.
> > > >>>   */
> > > >>
> > > >> We support hugepage faults in gpu drivers since recently, and I'm not
> > > >> seeing a pud_mkhugespecial anywhere. So not sure this works, but 
> > > >> probably
> > > >> just me missing something again.
> > > >
> > > > It means ioremap can't create an IO page PUD, it has to be broken up.
> > > >
> > > > Does ioremap even create anything larger than PTEs?
> >
> > gpu drivers also tend to use vmf_insert_pfn* directly, so we can do
> > on-demand paging and move buffers around. From what I glanced for
> > lowest level we to the pte_mkspecial correctly (I think I convinced
> > myself that vm_insert_pfn does that), but for pud/pmd levels it seems
> > just yolo.
> 
> So I dug around a bit more and ttm sets PFN_DEV | PFN_MAP to get past
> the various pft_t_devmap checks (see e.g. vmf_insert_pfn_pmd_prot()).
> x86-64 has ARCH_HAS_PTE_DEVMAP, and gup.c seems to handle these
> specially, but frankly I got totally lost in what this does.

The fact vmf_insert_pfn_pmd_prot() has all those BUG_ON's to prevent
putting VM_PFNMAP pages into the page tables seems like a big red
flag.

The comment seems to confirm what we are talking about here:

/*
 * If we had pmd_special, we could avoid all these restrictions,
 * but we need to be consistent with PTEs and architectures that
 * can't support a 'special' bit.
 */

ie without the ability to mark special we can't block fast gup and
anyone who does O_DIRECT on these ranges will crash the kernel when it
tries to convert a IO page into a struct page.

Should be easy enough to directly test?

Putting non-struct page PTEs into a VMA without setting VM_PFNMAP just
seems horribly wrong to me.

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

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

2020-11-08 Thread Dmitry Osipenko

05.11.2020 18:22, Dmitry Osipenko пишет:
> 05.11.2020 12:45, Ulf Hansson пишет:
> ...
>> I need some more time to review this, but just a quick check found a
>> few potential issues...
> 
> Thank you for starting the review! I'm pretty sure it will take a couple
> revisions until all the questions will be resolved :)
> 
>> The "core-supply", that you specify as a regulator for each
>> controller's device node, is not the way we describe power domains.
>> Instead, it seems like you should register a power-domain provider
>> (with the help of genpd) and implement the ->set_performance_state()
>> callback for it. Each device node should then be hooked up to this
>> power-domain, rather than to a "core-supply". For DT bindings, please
>> have a look at Documentation/devicetree/bindings/power/power-domain.yaml
>> and Documentation/devicetree/bindings/power/power_domain.txt.
>>
>> In regards to the "sync state" problem (preventing to change
>> performance states until all consumers have been attached), this can
>> then be managed by the genpd provider driver instead.
> 
> I'll need to take a closer look at GENPD, thank you for the suggestion.
> 
> Sounds like a software GENPD driver which manages clocks and voltages
> could be a good idea, but it also could be an unnecessary
> over-engineering. Let's see..
> 

Hello Ulf and all,

I took a detailed look at the GENPD and tried to implement it. Here is
what was found:

1. GENPD framework doesn't aggregate performance requests from the
attached devices. This means that if deviceA requests performance state
10 and then deviceB requests state 3, then framework will set domain's
state to 3 instead of 10.

https://elixir.bootlin.com/linux/v5.10-rc2/source/drivers/base/power/domain.c#L376

2. GENPD framework has a sync() callback in the genpd.domain structure,
but this callback isn't allowed to be used by the GENPD implementation.
The GENPD framework always overrides that callback for its own needs.
Hence GENPD doesn't allow to solve the bootstrapping
state-synchronization problem in a nice way.

https://elixir.bootlin.com/linux/v5.10-rc2/source/drivers/base/power/domain.c#L2606

3. Tegra doesn't have a dedicated hardware power-controller for the core
domain, instead there is only an external voltage regulator. Hence we
will need to create a phony device-tree node for the virtual power
domain, which is probably a wrong thing to do.

===

Perhaps it should be possible to create some hacks to work around
bullets 2 and 3 in order to achieve what we need for DVFS on Tegra, but
bullet 1 isn't solvable without changing how the GENPD core works.

Altogether, the GENPD in its current form is a wrong abstraction for a
system-wide DVFS in a case where multiple devices share power domain and
this domain is a voltage regulator. The regulator framework is the
correct abstraction in this case for today.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 RESEND] drm: mxsfb: Implement .format_mod_supported

2020-11-08 Thread Daniel Abrecht


This will make sure applications which use the IN_FORMATS blob
to figure out which modifiers they can use will pick up the
linear modifier which is needed by mxsfb. Such applications
will not work otherwise if an incompatible implicit modifier
ends up being selected.

Before commit ae1ed0093281 ("drm: mxsfb: Stop using DRM simple
display pipeline helper"), the DRM simple display pipeline
helper took care of this.

Signed-off-by: Daniel Abrecht 
Fixes: ae1ed0093281 ("drm: mxsfb: Stop using DRM simple display pipeline 
helper")

---
 drivers/gpu/drm/mxsfb/mxsfb_kms.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c 
b/drivers/gpu/drm/mxsfb/mxsfb_kms.c

index 956f631997f2..fc4b1626261b 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
@@ -484,6 +484,13 @@ static void 
mxsfb_plane_overlay_atomic_update(struct drm_plane *plane,

writel(ctrl, mxsfb->base + LCDC_AS_CTRL);
 }

+static bool mxsfb_format_mod_supported(struct drm_plane *plane,
+  uint32_t format,
+  uint64_t modifier)
+{
+   return modifier == DRM_FORMAT_MOD_LINEAR;
+}
+
 static const struct drm_plane_helper_funcs 
mxsfb_plane_primary_helper_funcs = {

.atomic_check = mxsfb_plane_atomic_check,
.atomic_update = mxsfb_plane_primary_atomic_update,
@@ -495,6 +502,7 @@ static const struct drm_plane_helper_funcs 
mxsfb_plane_overlay_helper_funcs = {

 };

 static const struct drm_plane_funcs mxsfb_plane_funcs = {
+   .format_mod_supported   = mxsfb_format_mod_supported,
.update_plane   = drm_atomic_helper_update_plane,
.disable_plane  = drm_atomic_helper_disable_plane,
.destroy= drm_plane_cleanup,
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 00/56] Convert DSI code to use drm_mipi_dsi and drm_panel

2020-11-08 Thread Nikhil Devshatwar

On 14:02-20201105, Tomi Valkeinen wrote:
> Hi,
> 
> This is third version of the series sent by Sebastian in February:
> 
> https://www.spinics.net/lists/linux-omap/msg153465.html
> 
> I took the patches from his git tree, and rebased on 5.10-rc2. There
> were some conflicts and compilation errors, and one bug that made dsi to
> not work (videomode variable was not initialized to 0).
> 
> I then fixed the few checkpatch and sparse issues. Overall, Sebastian's
> patches are pretty much as they were previously. I did drop Laurent's
> reviewed-bys, as it's been a long time since the previous series, and
> the patches are not identical anyway.
> 
> The topmost 5 patches are new ones, cleanups enabled by the DSI
> conversion. They could be handled separately, but it's such a nice
> cleanup, and I've been waiting for years to get this done, so here they
> are. That said, there are still a _lot_ of cleanups to do.
> 
> Almost all of the patches are omapdrm changes. The two non-omapdrm
> changes are:
> - After converting panel-dsi-cm to common DRM panel model, it is moved
>   to drm's panel directory.
> - Add MIPI_DSI_MODE_ULPS_IDLE flag
> 
> I have tested these with OMAP4 SDP, AM5 EVM and OMAP4 Panda. SDP has
> command mode panel, and I don't have any videomode panels.
> 
> Sebastian, I hope you're ok with all this? I did send you an email, but
> didn't get a reply yet, so I thought to just proceed. If you want to
> handle this in some other way, or don't want your
> authorship/signed-off-by in some of the commits, just tell.
> 
>  Tomi
> 
> Sebastian Reichel (51):
>   drm/dsi: add MIPI_DSI_MODE_ULPS_IDLE
>   Revert "drm/omap: dss: Remove unused omap_dss_device operations"
>   drm/omap: drop unused dsi.configure_pins
>   drm/omap: dsi: use MIPI_DSI_FMT_* instead of OMAP_DSS_DSI_FMT_*
>   drm/omap: constify write buffers
>   drm/omap: dsi: add generic transfer function
>   drm/omap: panel-dsi-cm: convert to transfer API
>   drm/omap: dsi: unexport specific data transfer functions
>   drm/omap: dsi: drop virtual channel logic
>   drm/omap: dsi: simplify write function
>   drm/omap: dsi: simplify read functions
>   drm/omap: dsi: switch dsi_vc_send_long/short to mipi_dsi_msg
>   drm/omap: dsi: introduce mipi_dsi_host
>   drm/omap: panel-dsi-cm: use DSI helpers
>   drm/omap: dsi: request VC via mipi_dsi_attach
>   drm/omap: panel-dsi-cm: drop hardcoded VC
>   drm/omap: panel-dsi-cm: use common MIPI DCS 1.3 defines
>   drm/omap: dsi: drop unused memory_read()
>   drm/omap: dsi: drop unused get_te()
>   drm/omap: dsi: drop unused enable_te()
>   drm/omap: dsi: drop useless sync()
>   drm/omap: dsi: use pixel-format and mode from attach
>   drm/omap: panel-dsi-cm: use bulk regulator API
>   drm/omap: dsi: lp/hs switching support for transfer()
>   drm/omap: dsi: move TE GPIO handling into core
>   drm/omap: dsi: drop custom enable_te() API
>   drm/omap: dsi: do bus locking in host driver
>   drm/omap: dsi: untangle ulps ops from enable/disable
>   drm/omap: dsi: do ULPS in host driver
>   drm/omap: dsi: move panel refresh function to host
>   drm/omap: dsi: Reverse direction of the DSS device enable/disable
> operations
>   drm/omap: dsi: drop custom panel capability support
>   drm/omap: dsi: convert to drm_panel
>   drm/omap: drop omapdss-boot-init
>   drm/omap: dsi: implement check timings
>   drm/omap: panel-dsi-cm: use DEVICE_ATTR_RO
>   drm/omap: panel-dsi-cm: support unbinding
>   drm/omap: panel-dsi-cm: fix remove()
>   drm/omap: remove global dss_device variable
>   drm/panel: Move OMAP's DSI command mode panel driver
>   drm/omap: dsi: Register a drm_bridge
>   drm/omap: remove legacy DSS device operations
>   drm/omap: remove unused omap_connector
>   drm/omap: simplify omap_display_id
>   drm/omap: drop unused DSS next pointer
>   drm/omap: drop empty omap_encoder helper functions
>   drm/omap: drop DSS ops_flags
>   drm/omap: drop dssdev display field
>   drm/omap: simplify DSI manual update code
>   drm/omap: dsi: simplify pin config
>   ARM: omap2plus_defconfig: Update for moved DSI command mode panel
> 
> Tomi Valkeinen (5):
>   drm/omap: squash omapdrm sub-modules into one
>   drm/omap: remove unused display.c
>   drm/omap: drop unused owner field
>   drm/omap: remove dispc_ops
>   drm/omap: remove dss_mgr_ops
> 

Reviewed-by: Nikhil Devshatwar 

Thanks
Nikhil D

>  arch/arm/configs/omap2plus_defconfig  |2 +-
>  drivers/gpu/drm/omapdrm/Kconfig   |  120 +-
>  drivers/gpu/drm/omapdrm/Makefile  |   19 +-
>  drivers/gpu/drm/omapdrm/displays/Kconfig  |   10 -
>  drivers/gpu/drm/omapdrm/displays/Makefile |2 -
>  .../gpu/drm/omapdrm/displays/panel-dsi-cm.c   | 1385 -
>  drivers/gpu/drm/omapdrm/dss/Kconfig   |  135 --
>  drivers/gpu/drm/omapdrm/dss/Makefile  |   20 -
>  drivers/gpu/drm/omapdrm/dss/base.c|   87 +-
>  drivers/gpu/drm/omapdrm/dss/dispc.c   |  101 +-
>  drivers/gpu/drm/omapdrm/dss/display.c

Re: [PATCH] drm: remove unneeded break

2020-11-08 Thread Sam Ravnborg

Hi Tom
On Mon, Oct 19, 2020 at 07:06:41PM +0200, Sam Ravnborg wrote:
> Hi Tom
> On Mon, Oct 19, 2020 at 09:31:15AM -0700, t...@redhat.com wrote:
> > From: Tom Rix 
> > 
> > A break is not needed if it is preceded by a return or break
> > 
> > Signed-off-by: Tom Rix 
> 
> Looks good and builds with no warnings.
> 
> One of the diffs made me - "oh this looks wrong". But after I looked again
> it was right and the resulting code is more readable - so good.
> 
> Acked-by: Sam Ravnborg 
> 
> Was tempted to just apply to drm-misc-next but will give others the
> opportunity to chime in.

Thanks.
Now applied to drm-misc-next - will show up in -next in a week or so.

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

[PATCH] vt: Disable KD_FONT_OP_COPY

2020-11-08 Thread Daniel Vetter

It's buggy:

On Fri, Nov 06, 2020 at 10:30:08PM +0800, Minh Yuan wrote:
> We recently discovered a slab-out-of-bounds read in fbcon in the latest
> kernel ( v5.10-rc2 for now ).  The root cause of this vulnerability is that
> "fbcon_do_set_font" did not handle "vc->vc_font.data" and
> "vc->vc_font.height" correctly, and the patch
>  for VT_RESIZEX can't handle this
> issue.
>
> Specifically, we use KD_FONT_OP_SET to set a small font.data for tty6, and
> use  KD_FONT_OP_SET again to set a large font.height for tty1. After that,
> we use KD_FONT_OP_COPY to assign tty6's vc_font.data to tty1's vc_font.data
> in "fbcon_do_set_font", while tty1 retains the original larger
> height. Obviously, this will cause an out-of-bounds read, because we can
> access a smaller vc_font.data with a larger vc_font.height.

Further there was only one user ever.
- Android's loadfont, busybox and console-tools only ever use OP_GET
  and OP_SET
- fbset documentation only mentions the kernel cmdline font: option,
  not anything else.
- systemd used OP_COPY before release 232 published in Nov 2016

Now unfortunately the crucial report seems to have gone down with
gmane, and the commit message doesn't say much. But the pull request
hints at OP_COPY being broken

https://github.com/systemd/systemd/pull/3651

So in other words, this never worked, and the only project which
foolishly every tried to use it, realized that rather quickly too.

Instead of trying to fix security issues here on dead code by adding
missing checks, fix the entire thing by removing the functionality.

Note that systemd code using the OP_COPY function ignored the return
value, so it doesn't matter what we're doing here really - just in
case a lone server somewhere happens to be extremely unlucky and
running an affected old version of systemd. The relevant code from
font_copy_to_all_vcs() in systemd was:

/* copy font from active VT, where the font was uploaded to */
cfo.op = KD_FONT_OP_COPY;
cfo.height = vcs.v_active-1; /* tty1 == index 0 */
(void) ioctl(vcfd, KDFONTOP, );

Note this just disables the ioctl, garbage collecting the now unused
callbacks is left for -next.

v2: Tetsuo found the old mail, which allowed me to find it on another
archive. Add the link too.

Acked-by: Peilin Ye 
Reported-by: Minh Yuan 
References: 
https://lists.freedesktop.org/archives/systemd-devel/2016-June/036935.html
References: https://github.com/systemd/systemd/pull/3651
Cc: Minh Yuan 
Cc: Greg KH 
Cc: Peilin Ye 
Cc: Tetsuo Handa 
Signed-off-by: Daniel Vetter 
---
 drivers/tty/vt/vt.c | 24 ++--
 1 file changed, 2 insertions(+), 22 deletions(-)

diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 9506a76f3ab6..d04a162939a4 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -4704,27 +4704,6 @@ static int con_font_default(struct vc_data *vc, struct 
console_font_op *op)
return rc;
 }
 
-static int con_font_copy(struct vc_data *vc, struct console_font_op *op)
-{
-   int con = op->height;
-   int rc;
-
-
-   console_lock();
-   if (vc->vc_mode != KD_TEXT)
-   rc = -EINVAL;
-   else if (!vc->vc_sw->con_font_copy)
-   rc = -ENOSYS;
-   else if (con < 0 || !vc_cons_allocated(con))
-   rc = -ENOTTY;
-   else if (con == vc->vc_num) /* nothing to do */
-   rc = 0;
-   else
-   rc = vc->vc_sw->con_font_copy(vc, con);
-   console_unlock();
-   return rc;
-}
-
 int con_font_op(struct vc_data *vc, struct console_font_op *op)
 {
switch (op->op) {
@@ -4735,7 +4714,8 @@ int con_font_op(struct vc_data *vc, struct 
console_font_op *op)
case KD_FONT_OP_SET_DEFAULT:
return con_font_default(vc, op);
case KD_FONT_OP_COPY:
-   return con_font_copy(vc, op);
+   /* was buggy and never really used */
+   return -EINVAL;
}
return -ENOSYS;
 }
-- 
2.28.0

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

Re: [PATCH] drm/bridge: lvds-codec: Use dev_err_probe for error handling

2020-11-08 Thread Sam Ravnborg

Hi Biju
On Tue, Oct 20, 2020 at 10:36:55AM +0100, Biju Das wrote:
> dev_err_probe function simplifies error handling. So use the same in probe
> function wherever possible.
> 
> Signed-off-by: Biju Das 
Thanks, applied to drm-misc-next

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

Re: [PATCH] drm/panel: panel-simple: Add connector_type for EDT ETM0700G0DH6 panel

2020-11-08 Thread Sam Ravnborg

Hi Biju

On Tue, Oct 20, 2020 at 10:49:10AM +0100, Biju Das wrote:
> Fix the warning message "missing connector type" by adding connector_type
> for EDT ETM0700G0DH6 panel.
> 
> Signed-off-by: Biju Das 

Thanks, applied to drm-misc-next.

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

Re: [PATCH] drm/mcde: Fix unbalanced regulator

2020-11-08 Thread Sam Ravnborg

On Sun, Nov 08, 2020 at 12:35:35PM +0100, Linus Walleij wrote:
> Since we now turn off the EPOD regulator to reset the
> hardware, we need to balance the regulators after that
> point. If registering the master fails we only need
> to disable one regulator. Fix this by open-coding
> this leg of the error path.
> 
> Cc: Stephan Gerhold 
> Fixes: c4842d4d0f74 ("drm/mcde: Fix display pipeline restart")
> Signed-off-by: Linus Walleij 
Looked for a devm variant of regulator_enable() but they do not seem to
exist. So the way the patch does it seems the best way.

Reviewed-by: Sam Ravnborg 

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

[PATCH] drm/mcde: Fix unbalanced regulator

2020-11-08 Thread Linus Walleij

Since we now turn off the EPOD regulator to reset the
hardware, we need to balance the regulators after that
point. If registering the master fails we only need
to disable one regulator. Fix this by open-coding
this leg of the error path.

Cc: Stephan Gerhold 
Fixes: c4842d4d0f74 ("drm/mcde: Fix display pipeline restart")
Signed-off-by: Linus Walleij 
---
 drivers/gpu/drm/mcde/mcde_drv.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mcde/mcde_drv.c b/drivers/gpu/drm/mcde/mcde_drv.c
index c592957ed07f..92f8bd907193 100644
--- a/drivers/gpu/drm/mcde/mcde_drv.c
+++ b/drivers/gpu/drm/mcde/mcde_drv.c
@@ -413,7 +413,13 @@ static int mcde_probe(struct platform_device *pdev)
  match);
if (ret) {
dev_err(dev, "failed to add component master\n");
-   goto clk_disable;
+   /*
+* The EPOD regulator is already disabled at this point so some
+* special errorpath code is needed
+*/
+   clk_disable_unprepare(mcde->mcde_clk);
+   regulator_disable(mcde->vana);
+   return ret;
}
 
return 0;
-- 
2.26.2

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

Re: [PATCH v3 2/3] drm/bridge: sii902x: Enable I/O and core VCC supplies if present

2020-11-08 Thread Sam Ravnborg

Hi Alexandru

On Tue, Oct 20, 2020 at 05:14:58PM -0500, Alexandru Gagniuc wrote:
> On the SII9022, the IOVCC and CVCC12 supplies must reach the correct
> voltage before the reset sequence is initiated. On most boards, this
> assumption is true at boot-up, so initialization succeeds.
> 
> However, when we try to initialize the chip with incorrect supply
> voltages, it will not respond to I2C requests. sii902x_probe() fails
> with -ENXIO.
> 
> To resolve this, look for the "iovcc" and "cvcc12" regulators, and
> make sure they are enabled before starting the reset sequence. If
> these supplies are not available in devicetree, then they will default
> to dummy-regulator. In that case everything will work like before.
> 
> This was observed on a STM32MP157C-DK2 booting in u-boot falcon mode.
> On this board, the supplies would be set by the second stage
> bootloader, which does not run in falcon mode.
> 
> Signed-off-by: Alexandru Gagniuc 

Thanks, applied series to drm-misc-next. I fixed two
checkpatch --strict warnings while applying.

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

Re: [PATCH] drm: bridge: dw-hdmi: Avoid resetting force in the detect function

2020-11-08 Thread Sam Ravnborg

Hi Russell,

On Sun, Nov 08, 2020 at 09:57:25AM +, Russell King - ARM Linux admin wrote:
> On Sun, Nov 08, 2020 at 10:53:22AM +0100, Sam Ravnborg wrote:
> > Russell,
> > 
> > On Sat, Oct 31, 2020 at 07:17:47PM +1100, Jonathan Liu wrote:
> > > It has been observed that resetting force in the detect function can
> > > result in the PHY being powered down in response to hot-plug detect
> > > being asserted, even when the HDMI connector is forced on.
> > > 
> > > Enabling debug messages and adding a call to dump_stack() in
> > > dw_hdmi_phy_power_off() shows the following in dmesg:
> > > [  160.637413] dwhdmi-rockchip ff94.hdmi: EVENT=plugin
> > > [  160.637433] dwhdmi-rockchip ff94.hdmi: PHY powered down in 0 
> > > iterations
> > > 
> > > Call trace:
> > > dw_hdmi_phy_power_off
> > > dw_hdmi_phy_disable
> > > dw_hdmi_update_power
> > > dw_hdmi_detect
> > > dw_hdmi_connector_detect
> > > drm_helper_probe_detect_ctx
> > > drm_helper_hpd_irq_event
> > > dw_hdmi_irq
> > > irq_thread_fn
> > > irq_thread
> > > kthread
> > > ret_from_fork
> > > 
> > > Fixes: 381f05a7a842 ("drm: bridge/dw_hdmi: add connector mode forcing")
> > > Signed-off-by: Jonathan Liu 
> > 
> > you are the original author of this code - any comments on this patch?
> 
> No further comments beyond what has already been discussed, and the
> long and short of it is it's been so long that I don't remember why
> that code was there. Given that, I'm not even in a position to ack
> the change. Sorry.
Thanks for the quick reply.

Given that this fixes a problem for Jonathan I will apply this to -fixes
if there is no other feedback the next couple of days.
If it introduces regression we can take it from there.

Jonathan - please ping me if I forget.

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

Re: [PATCH RESEND v2] drm/bridge/tc358775: Fixes bus formats read

2020-11-08 Thread Sam Ravnborg

Hi Laurent,

On Thu, Oct 22, 2020 at 12:15:47PM +0530, Vinay Simha BN wrote:
> - atomic_check removed
> - video data input and output formats added
> - bus formats read from drm_bridge_state.output_bus_cfg.format
>   and .atomic_get_input_bus_fmts() instead of connector
> 
> Signed-off-by: Vinay Simha BN 

could you try to find time to review this patch?

You already provided valuable feedback and it looks fine to me.
But it would be perfect if you could find time to take a look.

Thanks in advance,

Sam

> 
> ---
> v1:
>  * Laurent Pinchart review comments incorporated
>drm_bridge_state.output_bus_cfg.format
>instead of connector
> v2:
>  * Laurent Pinchart review comments incorporated
>atomic_check removed
>video data input and output formats added
> ---
>  drivers/gpu/drm/bridge/tc358775.c | 75 
> ++-
>  1 file changed, 58 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/tc358775.c 
> b/drivers/gpu/drm/bridge/tc358775.c
> index 2272adc..cc27570 100644
> --- a/drivers/gpu/drm/bridge/tc358775.c
> +++ b/drivers/gpu/drm/bridge/tc358775.c
> @@ -271,6 +271,20 @@ struct tc_data {
>   struct gpio_desc*stby_gpio;
>   u8  lvds_link; /* single-link or dual-link */
>   u8  bpc;
> + u32 output_bus_fmt;
> +};
> +
> +static const u32 tc_lvds_in_bus_fmts[] = {
> + MEDIA_BUS_FMT_RGB565_1X16,
> + MEDIA_BUS_FMT_RGB666_1X18,
> + MEDIA_BUS_FMT_RGB666_1X24_CPADHI,
> + MEDIA_BUS_FMT_RBG888_1X24,
> +};
> +
> +static const u32 tc_lvds_out_bus_fmts[] = {
> + MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA,
> + MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
> + MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
>  };
>  
>  static inline struct tc_data *bridge_to_tc(struct drm_bridge *b)
> @@ -359,19 +373,6 @@ static void d2l_write(struct i2c_client *i2c, u16 addr, 
> u32 val)
>   ret, addr);
>  }
>  
> -/* helper function to access bus_formats */
> -static struct drm_connector *get_connector(struct drm_encoder *encoder)
> -{
> - struct drm_device *dev = encoder->dev;
> - struct drm_connector *connector;
> -
> - list_for_each_entry(connector, >mode_config.connector_list, head)
> - if (connector->encoder == encoder)
> - return connector;
> -
> - return NULL;
> -}
> -
>  static void tc_bridge_enable(struct drm_bridge *bridge)
>  {
>   struct tc_data *tc = bridge_to_tc(bridge);
> @@ -380,7 +381,10 @@ static void tc_bridge_enable(struct drm_bridge *bridge)
>   u32 val = 0;
>   u16 dsiclk, clkdiv, byteclk, t1, t2, t3, vsdelay;
>   struct drm_display_mode *mode;
> - struct drm_connector *connector = get_connector(bridge->encoder);
> + struct drm_bridge_state *state =
> + drm_priv_to_bridge_state(bridge->base.state);
> +
> + tc->output_bus_fmt = state->output_bus_cfg.format;
>  
>   mode = >encoder->crtc->state->adjusted_mode;
>  
> @@ -451,14 +455,13 @@ static void tc_bridge_enable(struct drm_bridge *bridge)
>   d2l_write(tc->i2c, LVPHY0, LV_PHY0_PRBS_ON(4) | LV_PHY0_ND(6));
>  
>   dev_dbg(tc->dev, "bus_formats %04x bpc %d\n",
> - connector->display_info.bus_formats[0],
> + tc->output_bus_fmt,
>   tc->bpc);
>   /*
>* Default hardware register settings of tc358775 configured
>* with MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA jeida-24 format
>*/
> - if (connector->display_info.bus_formats[0] ==
> - MEDIA_BUS_FMT_RGB888_1X7X4_SPWG) {
> + if (tc->output_bus_fmt == MEDIA_BUS_FMT_RGB888_1X7X4_SPWG) {
>   /* VESA-24 */
>   d2l_write(tc->i2c, LV_MX0003, LV_MX(LVI_R0, LVI_R1, LVI_R2, 
> LVI_R3));
>   d2l_write(tc->i2c, LV_MX0407, LV_MX(LVI_R4, LVI_R7, LVI_R5, 
> LVI_G0));
> @@ -590,6 +593,40 @@ static int tc358775_parse_dt(struct device_node *np, 
> struct tc_data *tc)
>   return 0;
>  }
>  
> +static u32 *
> +tc_bridge_get_input_bus_fmts(struct drm_bridge *bridge,
> +  struct drm_bridge_state *bridge_state,
> +  struct drm_crtc_state *crtc_state,
> +  struct drm_connector_state *conn_state,
> +  u32 output_fmt,
> +  unsigned int *num_input_fmts)
> +{
> + u32 *input_fmts = NULL;
> + u8 i;
> +
> + *num_input_fmts = 0;
> +
> + for (i = 0 ; i < ARRAY_SIZE(tc_lvds_out_bus_fmts) ; ++i) {
> + if (output_fmt == tc_lvds_out_bus_fmts[i])
> + break;
> + }
> +
> + if (i == ARRAY_SIZE(tc_lvds_out_bus_fmts))
> + return NULL;
> +
> + *num_input_fmts = ARRAY_SIZE(tc_lvds_in_bus_fmts);
> +
> + input_fmts = kcalloc(*num_input_fmts, ARRAY_SIZE(tc_lvds_in_bus_fmts),
> +  GFP_KERNEL);
> + if (!input_fmts)
> + return NULL;
> +
> + for (i = 0; i

Re: [PATCH] drm: xlnx: Use dma_request_chan for DMA channel request

2020-11-08 Thread Sam Ravnborg

Hi Peter.

On Fri, Oct 23, 2020 at 12:46:02PM +0300, Peter Ujfalusi wrote:
> There is no need to use the of_dma_request_slave_channel() directly as
> dma_request_chan() is going to try to get the channel via OF as well.
> 
> Signed-off-by: Peter Ujfalusi 

I took a look at this and agree on your analysis.
Reviewed-by: Sam Ravnborg 

I expect the maintainers to pick up this patch.

Sam

> ---
>  drivers/gpu/drm/xlnx/zynqmp_disp.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c 
> b/drivers/gpu/drm/xlnx/zynqmp_disp.c
> index 98bd48f13fd1..a4405d081aca 100644
> --- a/drivers/gpu/drm/xlnx/zynqmp_disp.c
> +++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c
> @@ -28,7 +28,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -1316,8 +1315,7 @@ static int zynqmp_disp_layer_request_dma(struct 
> zynqmp_disp *disp,
>  
>   snprintf(dma_channel_name, sizeof(dma_channel_name),
>"%s%u", dma_names[layer->id], i);
> - dma->chan = of_dma_request_slave_channel(disp->dev->of_node,
> -  dma_channel_name);
> + dma->chan = dma_request_chan(disp->dev, dma_channel_name);
>   if (IS_ERR(dma->chan)) {
>   dev_err(disp->dev, "failed to request dma channel\n");
>   ret = PTR_ERR(dma->chan);
> -- 
> Peter
> 
> 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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: bridge: cdns: Kconfig: Switch over dependency to ARCH_K3

2020-11-08 Thread Sam Ravnborg

Hi Nishanth

On Mon, Oct 26, 2020 at 11:54:41AM -0500, Nishanth Menon wrote:
> With the integration of chip-id detection scheme in kernel[1], there
> is no specific need to maintain multitudes of SoC specific config
> options, discussed as per [2], we have deprecated the usage in other
> places for v5.10-rc1. Fix the missing user so that we can clean up the
> configs in v5.11.
> 
> [1] drivers/soc/ti/k3-socinfo.c commit 907a2b7e2fc7 ("soc: ti: add k3 
> platforms chipid module driver")
> [2] 
> https://lore.kernel.org/linux-arm-kernel/20200908112534.t5bgrjf7y3a6l2ss@akan/
> 
> Fixes: afba7e6c5fc1 ("rm: bridge: cdns-mhdp8546: Add TI J721E wrapper")
> Cc: Swapnil Jakhade 
> Cc: Tomi Valkeinen 
> Cc: Laurent Pinchart 
> Cc: Yuti Amonkar 
> Cc: Jyri Sarha 
> Signed-off-by: Nishanth Menon 

Applied to drm-misc-fixes with Tomi's r-b
Fixed the "Fixes" line while applying - someone ate a 'd'

Sam

> ---
>  drivers/gpu/drm/bridge/cadence/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/bridge/cadence/Kconfig 
> b/drivers/gpu/drm/bridge/cadence/Kconfig
> index 511d67b16d14..ef8c230e0f62 100644
> --- a/drivers/gpu/drm/bridge/cadence/Kconfig
> +++ b/drivers/gpu/drm/bridge/cadence/Kconfig
> @@ -13,7 +13,7 @@ config DRM_CDNS_MHDP8546
>  if DRM_CDNS_MHDP8546
>  
>  config DRM_CDNS_MHDP8546_J721E
> - depends on ARCH_K3_J721E_SOC || COMPILE_TEST
> + depends on ARCH_K3 || COMPILE_TEST
>   bool "J721E Cadence DPI/DP wrapper support"
>   default y
>   help
> -- 
> 2.28.0
> 
> ___
> 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: dw-hdmi: Avoid resetting force in the detect function

2020-11-08 Thread Russell King - ARM Linux admin

On Sun, Nov 08, 2020 at 10:53:22AM +0100, Sam Ravnborg wrote:
> Russell,
> 
> On Sat, Oct 31, 2020 at 07:17:47PM +1100, Jonathan Liu wrote:
> > It has been observed that resetting force in the detect function can
> > result in the PHY being powered down in response to hot-plug detect
> > being asserted, even when the HDMI connector is forced on.
> > 
> > Enabling debug messages and adding a call to dump_stack() in
> > dw_hdmi_phy_power_off() shows the following in dmesg:
> > [  160.637413] dwhdmi-rockchip ff94.hdmi: EVENT=plugin
> > [  160.637433] dwhdmi-rockchip ff94.hdmi: PHY powered down in 0 
> > iterations
> > 
> > Call trace:
> > dw_hdmi_phy_power_off
> > dw_hdmi_phy_disable
> > dw_hdmi_update_power
> > dw_hdmi_detect
> > dw_hdmi_connector_detect
> > drm_helper_probe_detect_ctx
> > drm_helper_hpd_irq_event
> > dw_hdmi_irq
> > irq_thread_fn
> > irq_thread
> > kthread
> > ret_from_fork
> > 
> > Fixes: 381f05a7a842 ("drm: bridge/dw_hdmi: add connector mode forcing")
> > Signed-off-by: Jonathan Liu 
> 
> you are the original author of this code - any comments on this patch?

No further comments beyond what has already been discussed, and the
long and short of it is it's been so long that I don't remember why
that code was there. Given that, I'm not even in a position to ack
the change. Sorry.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: panel: simple: add missing platform_driver_unregister() in panel_simple_init

2020-11-08 Thread Sam Ravnborg

Hi Qinglang

On Sat, Oct 31, 2020 at 09:18:56AM +0800, Qinglang Miao wrote:
> Add the missing platform_driver_unregister() before return
> from panel_simple_init in the error handling case when failed
> to register panel_simple_dsi_driver with CONFIG_DRM_MIPI_DSI
> enabled.
> 
> Signed-off-by: Qinglang Miao 

Looks relevant, applied to drm-misc-next.

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

Re: [PATCH] drm: bridge: dw-hdmi: Avoid resetting force in the detect function

2020-11-08 Thread Sam Ravnborg

Russell,

On Sat, Oct 31, 2020 at 07:17:47PM +1100, Jonathan Liu wrote:
> It has been observed that resetting force in the detect function can
> result in the PHY being powered down in response to hot-plug detect
> being asserted, even when the HDMI connector is forced on.
> 
> Enabling debug messages and adding a call to dump_stack() in
> dw_hdmi_phy_power_off() shows the following in dmesg:
> [  160.637413] dwhdmi-rockchip ff94.hdmi: EVENT=plugin
> [  160.637433] dwhdmi-rockchip ff94.hdmi: PHY powered down in 0 iterations
> 
> Call trace:
> dw_hdmi_phy_power_off
> dw_hdmi_phy_disable
> dw_hdmi_update_power
> dw_hdmi_detect
> dw_hdmi_connector_detect
> drm_helper_probe_detect_ctx
> drm_helper_hpd_irq_event
> dw_hdmi_irq
> irq_thread_fn
> irq_thread
> kthread
> ret_from_fork
> 
> Fixes: 381f05a7a842 ("drm: bridge/dw_hdmi: add connector mode forcing")
> Signed-off-by: Jonathan Liu 

you are the original author of this code - any comments on this patch?

Sam

> ---
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 6 --
>  1 file changed, 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index 748df1cacd2b..0c79a9ba48bb 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -2327,12 +2327,6 @@ static enum drm_connector_status dw_hdmi_detect(struct 
> dw_hdmi *hdmi)
>  {
>   enum drm_connector_status result;
>  
> - mutex_lock(>mutex);
> - hdmi->force = DRM_FORCE_UNSPECIFIED;
> - dw_hdmi_update_power(hdmi);
> - dw_hdmi_update_phy_mask(hdmi);
> - mutex_unlock(>mutex);
> -
>   result = hdmi->phy.ops->read_hpd(hdmi, hdmi->phy.data);
>  
>   mutex_lock(>mutex);
> -- 
> 2.29.1
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/7] opp: Allow dev_pm_opp_put_*() APIs to accept NULL opp_table

2020-11-08 Thread Ilia Lin

Reviewed-by: Ilia Lin 


On Fri, Nov 6, 2020 at 9:05 AM Viresh Kumar  wrote:
>
> Hello,
>
> This patchset updates the dev_pm_opp_put_*() helpers to accept a NULL
> pointer for the OPP table, in order to allow the callers to drop the
> unnecessary checks they had to carry.
>
> All these must get merged upstream through the OPP tree as there is a
> hard dependency on the first patch here. Thanks.
>
> Viresh Kumar (7):
>   opp: Allow dev_pm_opp_put_*() APIs to accept NULL opp_table
>   cpufreq: dt: dev_pm_opp_put_regulators() accepts NULL argument
>   cpufreq: qcom-cpufreq-nvmem: dev_pm_opp_put_*() accepts NULL argument
>   devfreq: exynos: dev_pm_opp_put_*() accepts NULL argument
>   drm/lima: dev_pm_opp_put_*() accepts NULL argument
>   drm/panfrost: dev_pm_opp_put_*() accepts NULL argument
>   media: venus: dev_pm_opp_put_*() accepts NULL argument
>
>  drivers/cpufreq/cpufreq-dt.c   |  6 ++
>  drivers/cpufreq/qcom-cpufreq-nvmem.c   | 15 ++-
>  drivers/devfreq/exynos-bus.c   | 12 
>  drivers/gpu/drm/lima/lima_devfreq.c| 13 -
>  drivers/gpu/drm/panfrost/panfrost_devfreq.c|  6 ++
>  drivers/media/platform/qcom/venus/pm_helpers.c |  3 +--
>  drivers/opp/core.c | 18 ++
>  7 files changed, 37 insertions(+), 36 deletions(-)
>
> --
> 2.25.0.rc1.19.g042ed3e048af
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 1/3] drm: panel: simple: Allow timing constraints, not fixed delays

2020-11-08 Thread Sam Ravnborg

Hi Douglas.

On Thu, Nov 05, 2020 at 01:57:39PM -0800, Douglas Anderson wrote:
> The simple panel code currently allows panels to define fixed delays
> at certain stages of initialization.  These work OK, but they don't
> really map all that clearly to the requirements presented in many
> panel datasheets.  Instead of defining a fixed delay, those datasheets
> provide a timing diagram and specify a minimum amount of time that
> needs to pass from event A to event B.
> 
> Because of the way things are currently defined, most panels end up
> over-delaying.  One prime example here is that a number of panels I've
> looked at define the amount of time that must pass between turning a
> panel off and turning it back on again.  Since there is no way to
> specify this, many developers have listed this as the "unprepare"
> delay.  However, if nobody ever tried to turn the panel on again in
> the next 500 ms (or whatever the delay was) then this delay was
> pointless.  It's better to do the delay only in the case that someone
> tried to turn the panel on too quickly.
> 
> Let's support specifying delays as constraints.  We'll start with the
> one above and also a second one: the minimum time between prepare
> being done and doing the enable.  On the panel I'm looking at, there's
> an 80 ms minimum time between HPD being asserted by the panel and
> setting the backlight enable GPIO.  By specifying as a constraint we
> can enforce this without over-delaying.  Specifically the link
> training is allowed to happen in parallel with this delay so adding a
> fixed 80 ms delay isn't ideal.
Nice and detaild explanation - thanks.

Reading through this a few times it seems that a simpler approach would
be to change the semantics of the dealys we already have a little and
only add one new field:

   struct {
unsigned int prepare;
unsigned int hpd_absent_delay;
unsigned int prepare_to_enable;
unsigned int enable;
unsigned int disable;
unsigned int unprepare;
} delay;

The lines marked "//*" are new or changed:

prepare()
//*enforce unprepare time
// enable regulator
// set enable gpio
// do fixed prepare delay (this is time until we can trust hpd)
// wait for HPD GPIO if applicable, otherwise do fixed hpd_absent_delay
//*start counting for prepare_to_enable

enable()
//*enforce prepare_to_enable min time
// enable backlight if applicable

panel shows nice pictures of kitties

disable()
// disable backlight is applicable
// fixed disable delay

unprepare()
// unset enable gpio
// disable regulator
//*start counting for unprepare delay


This should not break any exisitng panels - and we avoid that we have
two delays that are almost the same.

Would that work for you?

Note that no new struct was introduced - this is all dealys so keep it in
the same struct.

A dew details in the following.

Sam

> 
> Signed-off-by: Douglas Anderson 
> ---
> 
> Changes in v3:
> - Fixed totally backwards "if" tests.  :(
> 
> Changes in v2:
> - Inline the kernel doc for the two new members.
A nice follow-up patch would be to move the remaining fields as inline
doc. But let us settle on this first.

>  struct panel_simple {
>   struct drm_panel base;
> - bool prepared;
>   bool enabled;
>   bool no_hpd;
>  
> + ktime_t prepared_time;
> + ktime_t unprepared_time;
> +
>   const struct panel_desc *desc;
>  
>   struct regulator *supply;
> @@ -230,6 +294,20 @@ static int panel_simple_get_non_edid_modes(struct 
> panel_simple *panel,
>   return num;
>  }
>  
> +static void panel_simple_wait_min_time(ktime_t start_ktime, unsigned int 
> min_ms)
> +{
> + ktime_t now_ktime, min_ktime;
> +
> + if (!min_ms)
> + return;
> +
> + min_ktime = ktime_add(start_ktime, ms_to_ktime(min_ms));
> + now_ktime = ktime_get();
> +
> + if (ktime_before(now_ktime, min_ktime))
> + msleep(ktime_to_ms(ktime_sub(min_ktime, now_ktime)) + 1);
> +}
panel_simple_wait()?


> +
>  static int panel_simple_disable(struct drm_panel *panel)
>  {
>   struct panel_simple *p = to_panel_simple(panel);
> @@ -249,18 +327,19 @@ static int panel_simple_unprepare(struct drm_panel 
> *panel)
>  {
>   struct panel_simple *p = to_panel_simple(panel);
>  
> - if (!p->prepared)
> + if (p->prepared_time == 0)
>   return 0;
>  
>   gpiod_set_value_cansleep(p->enable_gpio, 0);
>  
>   regulator_disable(p->supply);
>  
> + p->prepared_time = 0;
> + p->unprepared_time = ktime_get();
> +
>   if (p->desc->delay.unprepare)
>   msleep(p->desc->delay.unprepare);
>  
> - p->prepared = false;
> -
>   return 0;
>  }
>  
> @@ -296,9 +375,12 @@ static int panel_simple_prepare(struct drm_panel *panel)
>   int err;
>   int hpd_asserted;
>  
> - if (p->prepared)
> + if (p->prepared_time != 0)
>   return 0;
>  
> +

69 matches

Mail list logo