Re: [PATCH v4] staging: vboxvideo: Add vboxvideo to drivers/staging

[kbuild test robot]

Hi Hans,

[auto build test ERROR on staging/staging-testing]
[also build test ERROR on v4.12-rc7 next-20170626]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Hans-de-Goede/staging-vboxvideo-Add-vboxvideo-to-drivers-staging/20170627-035353
config: x86_64-randconfig-n0-06270721 (attached as .config)
compiler: gcc-4.8 (Debian 4.8.4-1) 4.8.4
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

>> ERROR: "framebuffer_release" [drivers/staging/vboxvideo/vboxvideo.ko] 
>> undefined!
>> ERROR: "fb_set_suspend" [drivers/staging/vboxvideo/vboxvideo.ko] undefined!
>> ERROR: "fb_dealloc_cmap" [drivers/staging/vboxvideo/vboxvideo.ko] undefined!
>> ERROR: "unregister_framebuffer" [drivers/staging/vboxvideo/vboxvideo.ko] 
>> undefined!

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


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

Re: [PATCH 3/9] drm/amdgpu: Don't force BOs into visible VRAM for page faults

[John Brooks]

On Mon, Jun 26, 2017 at 06:38:29PM +0900, Michel Dänzer wrote:
> On 24/06/17 02:39 AM, John Brooks wrote:
> > There is no need for page faults to force BOs into visible VRAM if it's
> > full, and the time it takes to do so is great enough to cause noticeable
> > stuttering. Add GTT as a possible placement so that if visible VRAM is
> > full, page faults move BOs to GTT instead of evicting other BOs from VRAM.
> > 
> > Signed-off-by: John Brooks 
> > ---
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 14 ++
> >  1 file changed, 6 insertions(+), 8 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c 
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> > index 244a7d3..751bc05 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> > @@ -981,10 +981,11 @@ int amdgpu_bo_fault_reserve_notify(struct 
> > ttm_buffer_object *bo)
> >  
> > /* hurrah the memory is not visible ! */
> > atomic64_inc(>num_vram_cpu_page_faults);
> > -   amdgpu_ttm_placement_from_domain(abo, AMDGPU_GEM_DOMAIN_VRAM);
> > +   amdgpu_ttm_placement_from_domain(abo, AMDGPU_GEM_DOMAIN_VRAM |
> > +AMDGPU_GEM_DOMAIN_GTT);
> > lpfn =  adev->mc.visible_vram_size >> PAGE_SHIFT;
> > for (i = 0; i < abo->placement.num_placement; i++) {
> > -   /* Force into visible VRAM */
> > +   /* Try to move the BO into visible VRAM */
> > if ((abo->placements[i].flags & TTM_PL_FLAG_VRAM) &&
> > (!abo->placements[i].lpfn ||
> >  abo->placements[i].lpfn > lpfn))
> > @@ -993,16 +994,13 @@ int amdgpu_bo_fault_reserve_notify(struct 
> > ttm_buffer_object *bo)
> > abo->placement.busy_placement = abo->placement.placement;
> > abo->placement.num_busy_placement = abo->placement.num_placement;
> > r = ttm_bo_validate(bo, >placement, false, false);
> > -   if (unlikely(r == -ENOMEM)) {
> > -   amdgpu_ttm_placement_from_domain(abo, AMDGPU_GEM_DOMAIN_GTT);
> > -   return ttm_bo_validate(bo, >placement, false, false);
> > -   } else if (unlikely(r != 0)) {
> > +   if (unlikely(r != 0))
> > return r;
> > -   }
> >  
> > offset = bo->mem.start << PAGE_SHIFT;
> > /* this should never happen */
> > -   if ((offset + size) > adev->mc.visible_vram_size)
> > +   if (bo->mem.mem_type == TTM_PL_VRAM &&
> > +   (offset + size) > adev->mc.visible_vram_size)
> > return -EINVAL;
> >  
> > return 0;
> > 
> 
> AFAICT this is essentially the same as
> https://patchwork.freedesktop.org/patch/156993/ . I retracted that patch
> due to it causing Rally Dirt performance degradation for Marek.
> Presumably other patches in this series compensate for that, but at the
> least this patch should be moved to the end of the series.

Yeah, it did end up pretty much the same as your patch :p

The reason this causes the performance degredation is that if a page fault
moves a BO to GTT, and it's *not* marked CPU_ACCESS_REQUIRED, then CS will move
it to invisible VRAM. And then another page fault happens. And this repeats
fast enough that the BO is constantly moving back and forth between GTT and
VRAM.

Patch 6 (Set/clear CPU_ACCESS_REQUIRED flag on page fault and CS) takes care of
it by not allowing BOs to go to invisible VRAM until after a timeout and only
if it didn't have a page fault too soon after the last time it was moved to
VRAM. This was implemented by setting the CPU_ACCESS_REQUIRED flag on page
faults and not clearing it unless those conditions are met. It doesn't
necessarily need to involve the flag, depending on where we decide to go with
that.

John

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

Re: [PATCH] amdgpu: sync amdgpu_drm with kernel.

[Michel Dänzer]

On 27/06/17 11:58 AM, Dave Airlie wrote:
> From: Dave Airlie 
> 
> This syncs the amdgpu_drm header with my drm-next branch as of
> 6d61e70ccc21606ffb8a0a03bd3aba24f659502b.
> 
> It brings over the VM and semaphore API changes.
> 
> Generated using make headers_install.
> Generated from git://people.freedesktop.org/~airlied/linux drm-next commit 
> 6d61e70ccc2.
> 
> Signed-off-by: Dave Airlie 

Reviewed-by: Michel Dänzer 


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

Re: [PATCH libdrm] libdrm/amdgpu: add interface for kernel semaphores

[Dave Airlie]

Ignore this, all kinds of patches from wrong tree stuff going on here.

Dave.

On 27 June 2017 at 07:19, Dave Airlie  wrote:
> From: Dave Airlie 
>
> This adds the corresponding code for libdrm to use the new
> kernel interfaces for semaphores.
>
> This will be used by radv to implement shared semaphores.
>
> TODO: Version checks.
>
> Signed-off-by: Dave Airlie 
> ---
>  amdgpu/amdgpu.h  |  28 +
>  amdgpu/amdgpu_cs.c   | 161 
> ---
>  include/drm/amdgpu_drm.h |  28 +
>  3 files changed, 208 insertions(+), 9 deletions(-)
>
> diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h
> index 7b26a04..747e248 100644
> --- a/amdgpu/amdgpu.h
> +++ b/amdgpu/amdgpu.h
> @@ -129,6 +129,8 @@ typedef struct amdgpu_va *amdgpu_va_handle;
>   */
>  typedef struct amdgpu_semaphore *amdgpu_semaphore_handle;
>
> +typedef uint32_t amdgpu_sem_handle;
> +
>  
> /*--*/
>  /* -- Structures -- 
> */
>  
> /*--*/
> @@ -365,6 +367,16 @@ struct amdgpu_cs_request {
> struct amdgpu_cs_fence_info fence_info;
>  };
>
> +struct amdgpu_cs_request_sem {
> +   /*
> +*
> +*/
> +   uint32_t number_of_wait_sem;
> +   uint32_t *wait_sems;
> +   uint32_t number_of_signal_sem;
> +   uint32_t *signal_sems;
> +};
> +
>  /**
>   * Structure which provide information about GPU VM MC Address space
>   * alignments requirements
> @@ -882,6 +894,12 @@ int amdgpu_cs_submit(amdgpu_context_handle context,
>  struct amdgpu_cs_request *ibs_request,
>  uint32_t number_of_requests);
>
> +int amdgpu_cs_submit_sem(amdgpu_context_handle context,
> +uint64_t flags,
> +struct amdgpu_cs_request *ibs_request,
> +struct amdgpu_cs_request_sem *ibs_sem,
> +uint32_t number_of_requests);
> +
>  /**
>   *  Query status of Command Buffer Submission
>   *
> @@ -1255,4 +1273,14 @@ int 
> amdgpu_cs_destroy_semaphore(amdgpu_semaphore_handle sem);
>  */
>  const char *amdgpu_get_marketing_name(amdgpu_device_handle dev);
>
> +int amdgpu_cs_create_sem(amdgpu_device_handle dev,
> +amdgpu_sem_handle *sem);
> +int amdgpu_cs_export_sem(amdgpu_device_handle dev,
> + amdgpu_sem_handle sem,
> +int *shared_handle);
> +int amdgpu_cs_import_sem(amdgpu_device_handle dev,
> + int shared_handle,
> +amdgpu_sem_handle *sem);
> +int amdgpu_cs_destroy_sem(amdgpu_device_handle dev,
> + amdgpu_sem_handle sem);
>  #endif /* #ifdef _AMDGPU_H_ */
> diff --git a/amdgpu/amdgpu_cs.c b/amdgpu/amdgpu_cs.c
> index fb5b3a8..7283327 100644
> --- a/amdgpu/amdgpu_cs.c
> +++ b/amdgpu/amdgpu_cs.c
> @@ -170,7 +170,8 @@ int amdgpu_cs_query_reset_state(amdgpu_context_handle 
> context,
>   * \sa amdgpu_cs_submit()
>  */
>  static int amdgpu_cs_submit_one(amdgpu_context_handle context,
> -   struct amdgpu_cs_request *ibs_request)
> +   struct amdgpu_cs_request *ibs_request,
> +   struct amdgpu_cs_request_sem *sem_request)
>  {
> union drm_amdgpu_cs cs;
> uint64_t *chunk_array;
> @@ -178,9 +179,11 @@ static int amdgpu_cs_submit_one(amdgpu_context_handle 
> context,
> struct drm_amdgpu_cs_chunk_data *chunk_data;
> struct drm_amdgpu_cs_chunk_dep *dependencies = NULL;
> struct drm_amdgpu_cs_chunk_dep *sem_dependencies = NULL;
> +   struct drm_amdgpu_cs_chunk_sem *wait_sem_dependencies = NULL;
> +   struct drm_amdgpu_cs_chunk_sem *signal_sem_dependencies = NULL;
> struct list_head *sem_list;
> amdgpu_semaphore_handle sem, tmp;
> -   uint32_t i, size, sem_count = 0;
> +   uint32_t i, j, size, sem_count = 0;
> bool user_fence;
> int r = 0;
>
> @@ -196,7 +199,7 @@ static int amdgpu_cs_submit_one(amdgpu_context_handle 
> context,
> }
> user_fence = (ibs_request->fence_info.handle != NULL);
>
> -   size = ibs_request->number_of_ibs + (user_fence ? 2 : 1) + 1;
> +   size = ibs_request->number_of_ibs + (user_fence ? 2 : 1) + 1 + 
> (sem_request ? 2 : 0);
>
> chunk_array = alloca(sizeof(uint64_t) * size);
> chunks = alloca(sizeof(struct drm_amdgpu_cs_chunk) * size);
> @@ -308,6 +311,45 @@ static int amdgpu_cs_submit_one(amdgpu_context_handle 
> context,
> chunks[i].chunk_data = (uint64_t)(uintptr_t)sem_dependencies;
> }
>
> +   if (sem_request) {
> +   if (sem_request->number_of_wait_sem) {
> +   wait_sem_dependencies = 

[PATCH] amdgpu: sync amdgpu_drm with kernel.

[Dave Airlie]

From: Dave Airlie 

This syncs the amdgpu_drm header with my drm-next branch as of
6d61e70ccc21606ffb8a0a03bd3aba24f659502b.

It brings over the VM and semaphore API changes.

Generated using make headers_install.
Generated from git://people.freedesktop.org/~airlied/linux drm-next commit 
6d61e70ccc2.

Signed-off-by: Dave Airlie 
---
 include/drm/amdgpu_drm.h | 54 +++-
 1 file changed, 53 insertions(+), 1 deletion(-)

diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
index 8cfe68c..d9aa4a3 100644
--- a/include/drm/amdgpu_drm.h
+++ b/include/drm/amdgpu_drm.h
@@ -51,6 +51,7 @@ extern "C" {
 #define DRM_AMDGPU_GEM_OP  0x10
 #define DRM_AMDGPU_GEM_USERPTR 0x11
 #define DRM_AMDGPU_WAIT_FENCES 0x12
+#define DRM_AMDGPU_VM  0x13
 
 #define DRM_IOCTL_AMDGPU_GEM_CREATEDRM_IOWR(DRM_COMMAND_BASE + 
DRM_AMDGPU_GEM_CREATE, union drm_amdgpu_gem_create)
 #define DRM_IOCTL_AMDGPU_GEM_MMAP  DRM_IOWR(DRM_COMMAND_BASE + 
DRM_AMDGPU_GEM_MMAP, union drm_amdgpu_gem_mmap)
@@ -65,6 +66,7 @@ extern "C" {
 #define DRM_IOCTL_AMDGPU_GEM_OPDRM_IOWR(DRM_COMMAND_BASE + 
DRM_AMDGPU_GEM_OP, struct drm_amdgpu_gem_op)
 #define DRM_IOCTL_AMDGPU_GEM_USERPTR   DRM_IOWR(DRM_COMMAND_BASE + 
DRM_AMDGPU_GEM_USERPTR, struct drm_amdgpu_gem_userptr)
 #define DRM_IOCTL_AMDGPU_WAIT_FENCES   DRM_IOWR(DRM_COMMAND_BASE + 
DRM_AMDGPU_WAIT_FENCES, union drm_amdgpu_wait_fences)
+#define DRM_IOCTL_AMDGPU_VMDRM_IOWR(DRM_COMMAND_BASE + 
DRM_AMDGPU_VM, union drm_amdgpu_vm)
 
 #define AMDGPU_GEM_DOMAIN_CPU  0x1
 #define AMDGPU_GEM_DOMAIN_GTT  0x2
@@ -190,6 +192,26 @@ union drm_amdgpu_ctx {
union drm_amdgpu_ctx_out out;
 };
 
+/* vm ioctl */
+#define AMDGPU_VM_OP_RESERVE_VMID  1
+#define AMDGPU_VM_OP_UNRESERVE_VMID2
+
+struct drm_amdgpu_vm_in {
+   /** AMDGPU_VM_OP_* */
+   __u32   op;
+   __u32   flags;
+};
+
+struct drm_amdgpu_vm_out {
+   /** For future use, no flags defined so far */
+   __u64   flags;
+};
+
+union drm_amdgpu_vm {
+   struct drm_amdgpu_vm_in in;
+   struct drm_amdgpu_vm_out out;
+};
+
 /*
  * This is not a reliable API and you should expect it to fail for any
  * number of reasons and have fallback path that do not use userptr to
@@ -295,7 +317,10 @@ union drm_amdgpu_gem_wait_idle {
 };
 
 struct drm_amdgpu_wait_cs_in {
-   /** Command submission handle */
+   /* Command submission handle
+ * handle equals 0 means none to wait for
+ * handle equals ~0ull means wait for the latest sequence number
+ */
__u64 handle;
/** Absolute timeout to wait */
__u64 timeout;
@@ -415,6 +440,8 @@ struct drm_amdgpu_gem_va {
 #define AMDGPU_CHUNK_ID_IB 0x01
 #define AMDGPU_CHUNK_ID_FENCE  0x02
 #define AMDGPU_CHUNK_ID_DEPENDENCIES   0x03
+#define AMDGPU_CHUNK_ID_SYNCOBJ_IN  0x04
+#define AMDGPU_CHUNK_ID_SYNCOBJ_OUT 0x05
 
 struct drm_amdgpu_cs_chunk {
__u32   chunk_id;
@@ -482,6 +509,10 @@ struct drm_amdgpu_cs_chunk_fence {
__u32 offset;
 };
 
+struct drm_amdgpu_cs_chunk_sem {
+   __u32 handle;
+};
+
 struct drm_amdgpu_cs_chunk_data {
union {
struct drm_amdgpu_cs_chunk_ib   ib_data;
@@ -578,6 +609,8 @@ struct drm_amdgpu_cs_chunk_data {
#define AMDGPU_INFO_SENSOR_VDDNB0x6
/* Subquery id: Query graphics voltage */
#define AMDGPU_INFO_SENSOR_VDDGFX   0x7
+/* Number of VRAM page faults on CPU access. */
+#define AMDGPU_INFO_NUM_VRAM_CPU_PAGE_FAULTS   0x1E
 
 #define AMDGPU_INFO_MMR_SE_INDEX_SHIFT 0
 #define AMDGPU_INFO_MMR_SE_INDEX_MASK  0xff
@@ -766,6 +799,25 @@ struct drm_amdgpu_info_device {
__u64 cntl_sb_buf_gpu_addr;
/* NGG Parameter Cache */
__u64 param_buf_gpu_addr;
+   __u32 prim_buf_size;
+   __u32 pos_buf_size;
+   __u32 cntl_sb_buf_size;
+   __u32 param_buf_size;
+   /* wavefront size*/
+   __u32 wave_front_size;
+   /* shader visible vgprs*/
+   __u32 num_shader_visible_vgprs;
+   /* CU per shader array*/
+   __u32 num_cu_per_sh;
+   /* number of tcc blocks*/
+   __u32 num_tcc_blocks;
+   /* gs vgt table depth*/
+   __u32 gs_vgt_table_depth;
+   /* gs primitive buffer depth*/
+   __u32 gs_prim_buffer_depth;
+   /* max gs wavefront per vgt*/
+   __u32 max_gs_waves_per_vgt;
+   __u32 _pad1;
 };
 
 struct drm_amdgpu_info_hw_ip {
-- 
2.9.4

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

[PATCH v3 1/3] dt-bindings: Add support for samsung s6e63j0x03 panel binding

[Hoegeun Kwon]

The Samsung s6e63j0x03 is a 1.63" 320x320 AMOLED panel connected using
MIPI-DSI interfaces.

Signed-off-by: Hoegeun Kwon 
Reviewed-by: Andrzej Hajda 
Acked-by: Rob Herring 
---
 .../bindings/display/panel/samsung,s6e63j0x03.txt  | 24 ++
 1 file changed, 24 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/samsung,s6e63j0x03.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/samsung,s6e63j0x03.txt 
b/Documentation/devicetree/bindings/display/panel/samsung,s6e63j0x03.txt
new file mode 100644
index 000..3f1a839
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e63j0x03.txt
@@ -0,0 +1,24 @@
+Samsung S6E63J0X03 1.63" 320x320 AMOLED panel (interface: MIPI-DSI command 
mode)
+
+Required properties:
+  - compatible: "samsung,s6e63j0x03"
+  - reg: the virtual channel number of a DSI peripheral
+  - vdd3-supply: I/O voltage supply
+  - vci-supply: voltage supply for analog circuits
+  - reset-gpios: a GPIO spec for the reset pin (active low)
+  - te-gpios: a GPIO spec for the tearing effect synchronization signal
+gpio pin (active high)
+
+Example:
+ {
+   ...
+
+   panel@0 {
+   compatible = "samsung,s6e63j0x03";
+   reg = <0>;
+   vdd3-supply = <_reg>;
+   vci-supply = <_reg>;
+   reset-gpios = < 1 GPIO_ACTIVE_LOW>;
+   te-gpios = < 6 GPIO_ACTIVE_HIGH>;
+   };
+};
-- 
1.9.1

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

[PATCH v3 3/3] ARM: dts: exynos: Remove the display-timing and delay from rinato dts

[Hoegeun Kwon]

The display-timing and delay are included in the panel driver. So it
should be removed in dts.

Signed-off-by: Hoegeun Kwon 
---
 arch/arm/boot/dts/exynos3250-rinato.dts | 22 --
 1 file changed, 22 deletions(-)

diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts 
b/arch/arm/boot/dts/exynos3250-rinato.dts
index de2702e..3df88383 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -227,28 +227,6 @@
vci-supply = <_reg>;
reset-gpios = < 1 GPIO_ACTIVE_LOW>;
te-gpios = < 6 GPIO_ACTIVE_HIGH>;
-   power-on-delay= <30>;
-   power-off-delay= <120>;
-   reset-delay = <5>;
-   init-delay = <100>;
-   flip-horizontal;
-   flip-vertical;
-   panel-width-mm = <29>;
-   panel-height-mm = <29>;
-
-   display-timings {
-   timing-0 {
-   clock-frequency = <460>;
-   hactive = <320>;
-   vactive = <320>;
-   hfront-porch = <1>;
-   hback-porch = <1>;
-   hsync-len = <1>;
-   vfront-porch = <150>;
-   vback-porch = <1>;
-   vsync-len = <2>;
-   };
-   };
};
 };
 
-- 
1.9.1

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

[PATCH v3 2/3] drm/panel: Add support for s6e63j0x03 panel driver

[Hoegeun Kwon]

This patch adds MIPI-DSI based S6E63J0X03 AMOLED LCD panel driver
which uses mipi_dsi bus to communicate with panel. The panel has
320×320 resolution in 1.63" physical panel. This panel is used in
Samsung Galaxy Gear 2.

Signed-off-by: Inki Dae 
Signed-off-by: Hyungwon Hwang 
Signed-off-by: Hoegeun Kwon 
---
 drivers/gpu/drm/panel/Kconfig|   7 +
 drivers/gpu/drm/panel/Makefile   |   1 +
 drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c | 540 +++
 3 files changed, 548 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 3e29a99..3f4afde 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -68,6 +68,13 @@ config DRM_PANEL_SAMSUNG_S6E3HA2
depends on DRM_MIPI_DSI
select VIDEOMODE_HELPERS
 
+config DRM_PANEL_SAMSUNG_S6E63J0X03
+   tristate "Samsung S6E63J0X03 DSI command mode panel"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   depends on BACKLIGHT_CLASS_DEVICE
+   select VIDEOMODE_HELPERS
+
 config DRM_PANEL_SAMSUNG_S6E8AA0
tristate "Samsung S6E8AA0 DSI video mode panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 292b3c7..f028269 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
 obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) += 
panel-panasonic-vvx10f034n00.o
 obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += panel-samsung-ld9040.o
 obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E3HA2) += panel-samsung-s6e3ha2.o
+obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E63J0X03) += panel-samsung-s6e63j0x03.o
 obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0) += panel-samsung-s6e8aa0.o
 obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
 obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c 
b/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c
new file mode 100644
index 000..c3d1b5d
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c
@@ -0,0 +1,540 @@
+/*
+ * MIPI-DSI based S6E63J0X03 AMOLED lcd 1.63 inch panel driver.
+ *
+ * Copyright (c) 2014-2017 Samsung Electronics Co., Ltd
+ *
+ * Inki Dae 
+ * Hoegeun Kwon 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MCS_LEVEL2_KEY 0xf0
+#define MCS_MTP_KEY0xf1
+#define MCS_MTP_SET3   0xd4
+
+#define MAX_BRIGHTNESS 100
+#define DEFAULT_BRIGHTNESS 80
+
+#define NUM_GAMMA_STEPS9
+#define GAMMA_CMD_CNT  28
+
+#define FIRST_COLUMN 20
+
+struct s6e63j0x03 {
+   struct device *dev;
+   struct drm_panel panel;
+   struct backlight_device *bl_dev;
+
+   struct regulator_bulk_data supplies[2];
+   struct gpio_desc *reset_gpio;
+};
+
+static const struct drm_display_mode default_mode = {
+   .clock = 4649,
+   .hdisplay = 320,
+   .hsync_start = 320 + 1,
+   .hsync_end = 320 + 1 + 1,
+   .htotal = 320 + 1 + 1 + 1,
+   .vdisplay = 320,
+   .vsync_start = 320 + 150,
+   .vsync_end = 320 + 150 + 1,
+   .vtotal = 320 + 150 + 1 + 2,
+   .vrefresh = 30,
+   .flags = 0,
+};
+
+static const unsigned char gamma_tbl[NUM_GAMMA_STEPS][GAMMA_CMD_CNT] = {
+   {   /* Gamma 10 */
+   MCS_MTP_SET3,
+   0x00, 0x00, 0x00, 0x7f, 0x7f, 0x7f, 0x52, 0x6b, 0x6f, 0x26,
+   0x28, 0x2d, 0x28, 0x26, 0x27, 0x33, 0x34, 0x32, 0x36, 0x36,
+   0x35, 0x00, 0xab, 0x00, 0xae, 0x00, 0xbf
+   },
+   {   /* gamma 30 */
+   MCS_MTP_SET3,
+   0x00, 0x00, 0x00, 0x70, 0x7f, 0x7f, 0x4e, 0x64, 0x69, 0x26,
+   0x27, 0x2a, 0x28, 0x29, 0x27, 0x31, 0x32, 0x31, 0x35, 0x34,
+   0x35, 0x00, 0xc4, 0x00, 0xca, 0x00, 0xdc
+   },
+   {   /* gamma 60 */
+   MCS_MTP_SET3,
+   0x00, 0x00, 0x00, 0x65, 0x7b, 0x7d, 0x5f, 0x67, 0x68, 0x2a,
+   0x28, 0x29, 0x28, 0x2a, 0x27, 0x31, 0x2f, 0x30, 0x34, 0x33,
+   0x34, 0x00, 0xd9, 0x00, 0xe4, 0x00, 0xf5
+   },
+   {   /* gamma 90 */
+   MCS_MTP_SET3,
+   0x00, 0x00, 0x00, 0x4d, 0x6f, 0x71, 0x67, 0x6a, 0x6c, 0x29,
+   0x28, 0x28, 0x28, 0x29, 0x27, 0x30, 0x2e, 0x30, 0x32, 0x31,
+   0x31, 0x00, 0xea, 0x00, 0xf6, 0x01, 0x09
+   },
+   {   /* gamma 120 */
+   MCS_MTP_SET3,
+   0x00, 0x00, 

[PATCH v3 0/3] Add support for the s6e63j0x03 panel on Rinato board

[Hoegeun Kwon]

Hi all,

The purpose of this patch is add support for s6e63j0x03 AMOLED panel
on the rinato board(Samsung Galaxy Gear 2).

Changes for V3:
- Applied patch 'ARM: dts: exynos: Fix the active of reset gpios from rinato 
dts' (v2 3/4)
- Remove the unnecessary define ('MIN_BRIGHTNESS')
- Removed explicit casting.
- Removed violation of kernel coding style.

Changes for V2:
- Added the interface info in binding document.
- Added Reviewed-by: Andrzej Hajda  (1/3 patch).
- Added Acked-by: Rob Herring  (1/3 patch).
- Fixed the tristate of config from video mode to command mode.
- Fixed the reset gpios from active high to low from rinato dts.
- Fixed a lot of things in panel driver, reflect Andrzej's review.

Best regards,
Hoegeun

Hoegeun Kwon (3):
  dt-bindings: Add support for samsung s6e63j0x03 panel binding
  drm/panel: Add support for s6e63j0x03 panel driver
  ARM: dts: exynos: Remove the display-timing and delay from rinato dts

 .../bindings/display/panel/samsung,s6e63j0x03.txt  |  24 +
 arch/arm/boot/dts/exynos3250-rinato.dts|  22 -
 drivers/gpu/drm/panel/Kconfig  |   7 +
 drivers/gpu/drm/panel/Makefile |   1 +
 drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c   | 540 +
 5 files changed, 572 insertions(+), 22 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/samsung,s6e63j0x03.txt
 create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c

-- 
1.9.1

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

Re: [PATCH 1/8] arm: omap4: enable CEC pin for Pandaboard A4 and ES

[Tony Lindgren]

Tomi,

* Tomi Valkeinen  [170428 04:15]:
> On 14/04/17 13:25, Hans Verkuil wrote:
> > From: Hans Verkuil 
> > 
> > The CEC pin was always pulled up, making it impossible to use it.
...

> Tony, can you queue this? It's safe to apply separately from the rest of
> the HDMI CEC work.

So the dts changes are merged now but what's the status of the CEC driver
changes? Were there some issues as I don't see them in next?

Regards,

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

Re: [PATCH 6/7] drm/tilcdc: clean up ifdef hacks around iowrite64

[Logan Gunthorpe]

Hi Jyri,

Thanks for the ack. However, I'm reworking this patch set to use the
include/linux/io-64-nonatomic* headers which will explicitly devolve
into two 32-bit transfers. It's not clear whether this is appropriate
for the tilcdc driver as it was never setup to use 32-bit transfers
(unlike the others I had patched).

If you think it's ok, I can still patch this driver to use the
non-atomic headers. Otherwise I can leave it out. Please let me know.

Thanks,

Logan


On 26/06/17 02:55 AM, Jyri Sarha wrote:
> Acked-by: Jyri Sarha 
> 
> And thanks!
> 
>> ---
>>  drivers/gpu/drm/tilcdc/tilcdc_regs.h | 6 --
>>  1 file changed, 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_regs.h 
>> b/drivers/gpu/drm/tilcdc/tilcdc_regs.h
>> index e9ce725698a9..0b901405f30a 100644
>> --- a/drivers/gpu/drm/tilcdc/tilcdc_regs.h
>> +++ b/drivers/gpu/drm/tilcdc/tilcdc_regs.h
>> @@ -133,13 +133,7 @@ static inline void tilcdc_write64(struct drm_device 
>> *dev, u32 reg, u64 data)
>>  struct tilcdc_drm_private *priv = dev->dev_private;
>>  void __iomem *addr = priv->mmio + reg;
>>  
>> -#ifdef iowrite64
>>  iowrite64(data, addr);
>> -#else
>> -__iowmb();
>> -/* This compiles to strd (=64-bit write) on ARM7 */
>> -*(u64 __force *)addr = __cpu_to_le64(data);
>> -#endif
>>  }
>>  
>>  static inline u32 tilcdc_read(struct drm_device *dev, u32 reg)
>>
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/7] iomap: implement ioread64 and iowrite64

[Logan Gunthorpe]

On 6/26/2017 2:43 PM, Arnd Bergmann wrote:

This hardcodes the behavior of include/linux/io-64-nonatomic-hi-lo.h, which
I find rather confusing, as only about one in five drivers wants this
behavior.

I'd suggest you don't add it in lib/iomap.c at all for 32-bit architectures,
but rather use the same logic that we have for readq/writeq in
io-64-nonatomic-hi-lo.h and io-64-nonatomic-lo-hi.h, adding
{lo_hi,hi_lo}_{ioread,iowrite}{,be} to the same files, and provide
the {ioread,iowrite}{,be} macros only if they have not been defined
at that point.


Thanks Arnd. Yes, I'm already reworking this patchset to do exactly that.

Logan

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

Re: [PATCH 1/3] drm/etnaviv: don't trigger OOM killer when page allocation fails

[Michal Hocko]

On Tue 20-06-17 11:25:24, Daniel Vetter wrote:
> On Tue, Jun 20, 2017 at 11:22:06AM +0200, Lucas Stach wrote:
> > Am Dienstag, den 20.06.2017, 11:06 +0200 schrieb Daniel Vetter:
> > > On Tue, Jun 06, 2017 at 09:17:06AM +0200, Lucas Stach wrote:
> > > > GPU buffers can be quite large, so userspace is expected to deal with
> > > > allocation failure. Don't trigger the OOM killer when page allocation 
> > > > for
> > > > the GEM objects fails, as this opens an easy possiblity for unprivileged
> > > > applications to DOS the system,a s the shmem pages are not fully 
> > > > accounted
> > > > to the allocating process.
> > > > 
> > > > Signed-off-by: Lucas Stach 
> > > > ---
> > > >  drivers/gpu/drm/etnaviv/etnaviv_gem.c | 3 ++-
> > > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem.c 
> > > > b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> > > > index f0efc5d..4c53508 100644
> > > > --- a/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> > > > +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem.c
> > > > @@ -662,7 +662,8 @@ static struct drm_gem_object 
> > > > *__etnaviv_gem_new(struct drm_device *dev,
> > > >  * going to pin these pages.
> > > >  */
> > > > mapping = obj->filp->f_mapping;
> > > > -   mapping_set_gfp_mask(mapping, GFP_HIGHUSER);
> > > > +   mapping_set_gfp_mask(mapping, GFP_HIGHUSER |
> > > > +__GFP_NORETRY | __GFP_NOWARN);
> > > 
> > > _NORETRY means the mm does try hard at all to free memory. We've just done
> > > this patch in 4.12 and totally regret it, because now gpu tasks run out of
> > > memory with plenty of (gpu) memory available that could be reaped.
> > > 
> > > There's some discussions going on with Michal Hocko and Chris Wilson
> > > about possible solutions for this without so much hacks.
> > 
> > Thanks for the heads up. In contrast to some of the other drivers
> > Etnaviv hasn't grown a proper shrinker yet, so I still think this patch
> > is a step in the right direction for the time being.
> > Currently with Etnaviv sitting on lots of GPU memory and the MM trying
> > hard to free more memory for GPU usage a simple piglit run might
> > pressure the OOM killer hard enough to bring the system down by killing
> > PID 1.
> 
> Ah ok, that changes the balance of course. Time to type that shrinker I'd
> say :-)

Yeah, shrinker sounds like an absolute must. Anyway, I've posted
__GFP_RETRY_MAYFAIL patchset [1] so you can use that flag.

[1] http://lkml.kernel.org/r/20170623085345.11304-1-mho...@kernel.org
-- 
Michal Hocko
SUSE Labs
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/i915: Synchronize connectors states when switching from poll to irq

[Paul Kocialkowski]

After detecting an IRQ storm, hotplug detection will switch from
irq-based detection to poll-based detection. After a short delay or
when resetting storm detection from debugfs, detection will switch
back to being irq-based.

However, it may occur that polling does not have enough time to detect
the current connector state when that second switch takes place. Thus,
this sets the appropriate hotplug event bits for the concerned
connectors and schedules the hotplug work, that will ensure the
connectors states are in sync when switching back to irq.

Without this, no irq will be triggered and the hpd change will be lost.

Signed-off-by: Paul Kocialkowski 
---
 drivers/gpu/drm/i915/intel_hotplug.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_hotplug.c 
b/drivers/gpu/drm/i915/intel_hotplug.c
index f1200272a699..29f55480b0bb 100644
--- a/drivers/gpu/drm/i915/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/intel_hotplug.c
@@ -218,9 +218,13 @@ static void intel_hpd_irq_storm_reenable_work(struct 
work_struct *work)
struct intel_connector *intel_connector = 
to_intel_connector(connector);
 
if (intel_connector->encoder->hpd_pin == i) {
-   if (connector->polled != 
intel_connector->polled)
+   if (connector->polled != 
intel_connector->polled) {
DRM_DEBUG_DRIVER("Reenabling HPD on 
connector %s\n",
 connector->name);
+
+   dev_priv->hotplug.event_bits |= (1 << 
i);
+   }
+
connector->polled = intel_connector->polled;
if (!connector->polled)
connector->polled = 
DRM_CONNECTOR_POLL_HPD;
@@ -232,6 +236,8 @@ static void intel_hpd_irq_storm_reenable_work(struct 
work_struct *work)
dev_priv->display.hpd_irq_setup(dev_priv);
spin_unlock_irq(_priv->irq_lock);
 
+   schedule_work(_priv->hotplug.hotplug_work);
+
intel_runtime_pm_put(dev_priv);
 }
 
-- 
2.13.1

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

Re: [PATCH v2 00/14] improve the fb_setcmap helper

[Peter Rosin]

On 2017-06-26 11:35, Daniel Vetter wrote:
> On Thu, Jun 22, 2017 at 08:06:23AM +0200, Peter Rosin wrote:
>> Hi!
>>
>> While trying to get CLUT support for the atmel_hlcdc driver, and
>> specifically for the emulated fbdev interface, I received some
>> push-back that my feeble in-driver attempts should be solved
>> by the core. This is my attempt to do it right.
>>
>> I have obviously not tested all of this with more than a compile,
>> but patches 1 and 3 are enough to make the atmel-hlcdc driver
>> do what I need (when patched to support CLUT modes). The rest is
>> just lots of removals and cleanup made possible by the improved
>> core.
>>
>> Please test, I would not be surprised if I have fouled up some
>> bit-manipulation somewhere in this mostly mechanical change...
>>
>> Changes since v1:
>>
>> - Rebased to next-20170621
>> - Split 1/11 into a preparatory patch, a cleanup patch and then
>>   the meat in 3/14.
>> - Handle pseudo-palette for FB_VISUAL_TRUECOLOR.
>> - Removed the empty .gamma_get/.gamma_set fb helpers from the
>>   armada driver that I had somehow managed to ignore but which
>>   0day found real quick.
>> - Be less judgemental on drivers only providing .gamma_get and
>>   .gamma_set, but no .load_lut. That's actually a valid thing
>>   to do if you only need pseudo-palette for FB_VISUAL_TRUECOLOR.
>> - Add a comment about colliding bitfields in the nouveau driver.
>> - Remove gamma_set/gamma_get declarations from the radeon driver
>>   (the definitions were removed in v1).
> 
> Ok some nits/questions on the first three, but in principle looks all ok I
> think. The driver patches also look good (but I didn't yet carefully
> review all the conversion). What we might want to do is entirely remove
> driver's reliance on ->gamma_store (mostly amounts to in-lining the
> load_lut functions) and only update ->gamma_store after gamma_set returned
> successfully. But that's a bit more work.
> 
> Save/restoring it instead might be simpler to fix that bug, but since it's
> pre-existing also ok as follow-up.

I'm traveling and cannot make progress this week. The merge window is
also real close so this series will therefore probably miss it unless
something unexpected happens...

I'll get back to this for the next cycle, just a heads up.

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

Re: clean up and modularize arch dma_mapping interface V2

[tndave]

On 06/26/2017 02:47 AM, Christoph Hellwig wrote:

On Sat, Jun 24, 2017 at 10:36:56AM -0500, Benjamin Herrenschmidt wrote:

I think we still need to do it. For example we have a bunch new "funky"
cases.


I have no plan to do away with the selection - I just want a better
interface than the current one.

I agree we need better interface than the current one.
Like Benjamin mentioned cases for powerpc , sparc also need some special
treatment for ATU IOMMU depending on device's DMA mask.

For sparc, I am in process of enabling one or more dedicated IOTSB (I/O
Translation Storage Buffer) per PCI BDF (contrary to current design
where all PCI device under root complex share a 32bit and/or 64bit IOTSB
depending on 32bit and/or 64bit DMA). I am planning to use DMA set mask
APIs as hook where based on device's dma mask values (dma_mask and
coherent_dma_mask) one or more IOTSB resource will be allocated (and
released [1]).

Without set_dma_mask ops, I can still rely on HAVE_ARCH_DMA_SET_MASK and
dma_supported() that allows me to distinguish if device is setting
its streaming dma_mask and coherent_dma_mask respectively.

-Tushar

[1] By default, every PCI BDF will have one dedicated 32bit IOTSB. This
is to support default case where some device drivers even don't bother
to set DMA mask but instead are fine with default 32bit mask.
A 64bit IOTSB will be allocated when device request 64bit dma_mask.
However if device wants 64bit dma mask for both coherent and
non-coherent, a default 32bit IOTSB will be released as well. Wasting an
IOTSB is not a good idea because there is a hard limit on max number of
IOTSB per guest domain per root complex.



--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

[Bug 93715] [r600g] rendering issues with R600_DEBUG=nosb for all three 'raytrace' variants

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=93715

--- Comment #5 from Dieter Nützel  ---
Yes,

it works correctly with current mesa-git and a RX580 (Polaris 20), now.

Hello Gert,
will try with my old 6670 HD (Turks XT) when I find more time to switch it back
in.

But good progress so far.

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

Re: [PATCH 6/9] drm/amdgpu: Set/clear CPU_ACCESS_REQUIRED flag on page fault and CS

[Marek Olšák]

On Mon, Jun 26, 2017 at 11:27 AM, Michel Dänzer  wrote:
> On 25/06/17 03:00 AM, Christian König wrote:
>> Am 23.06.2017 um 19:39 schrieb John Brooks:
>>> When the AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED flag is given by
>>> userspace,
>>> it should only be treated as a hint to initially place a BO somewhere CPU
>>> accessible, rather than having a permanent effect on BO placement.
>>
>> And that is a clear NAK from my side.
>>
>> CPU_ACCESS_REQUIRED is a permanent limitation to where the buffer should
>> be placed.
>
> It really can't be more than a hint. The userspace driver cannot
> reliably know ahead of time whether a BO will be accessed by the CPU at
> all, let alone how often. A BO which incorrectly has this flag set
> creates artificial pressure on CPU visible VRAM.

I also think the flag is only a hint and shouldn't be taken too seriously.

Only AMDGPU_GEM_CREATE_NO_CPU_ACCESS has a strict behavior.

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

[Bug 101596] Blender renders black UI elements

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101596

--- Comment #3 from Sebastian Parborg  ---
I've narrowed it down to this commit:
https://cgit.freedesktop.org/mesa/mesa/commit/?id=56a28ace35c513ba22d754192127c359c28ed7e5

It seems like that is the one that breaks it.

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

Re: [PATCH 7/9] drm/amdgpu: Throttle visible VRAM moves separately

[John Brooks]

On Mon, Jun 26, 2017 at 06:44:30PM +0900, Michel Dänzer wrote:
> On 24/06/17 02:39 AM, John Brooks wrote:
> > The BO move throttling code is designed to allow VRAM to fill quickly if it
> > is relatively empty. However, this does not take into account situations
> > where the visible VRAM is smaller than total VRAM, and total VRAM may not
> > be close to full but the visible VRAM segment is under pressure. In such
> > situations, visible VRAM would experience unrestricted swapping and
> > performance would drop.
> > 
> > Add a separate counter specifically for moves involving visible VRAM, and
> > check it before moving BOs there.
> > 
> > Fixes: 95844d20ae02 (drm/amdgpu: throttle buffer migrations at CS using a 
> > fixed MBps limit (v2))
> > Signed-off-by: John Brooks 
> 
> Something like this patch is definitely needed, good catch.
> 
> However, as is one issue is that it incurs CPU overhead even when all of
> VRAM is CPU visible. Can that be avoided somehow?
> 

I guess that depends which part of it you consider to be expensive.

bytes_moved_vis_threshold isn't used unless visible VRAM is smaller than total
VRAM, so any work/instructions that go into computing it could be skipped in
that case (at the cost of checking that visible_vram_size < real_vram_size)
Would that help?

John

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

[Bug 92715] [IGT] [BYT-M/KBL/BSW/BXT/BDW] gem_reset_stats sub tests fail

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=92715

Ricardo  changed:

   What|Removed |Added

   Assignee|humberto.i.perez.rodriguez@ |dri-devel@lists.freedesktop
   |intel.com   |.org

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

[PATCH libdrm] libdrm/amdgpu: add interface for kernel semaphores

[Dave Airlie]

From: Dave Airlie 

This adds the corresponding code for libdrm to use the new
kernel interfaces for semaphores.

This will be used by radv to implement shared semaphores.

TODO: Version checks.

Signed-off-by: Dave Airlie 
---
 amdgpu/amdgpu.h  |  28 +
 amdgpu/amdgpu_cs.c   | 161 ---
 include/drm/amdgpu_drm.h |  28 +
 3 files changed, 208 insertions(+), 9 deletions(-)

diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h
index 7b26a04..747e248 100644
--- a/amdgpu/amdgpu.h
+++ b/amdgpu/amdgpu.h
@@ -129,6 +129,8 @@ typedef struct amdgpu_va *amdgpu_va_handle;
  */
 typedef struct amdgpu_semaphore *amdgpu_semaphore_handle;
 
+typedef uint32_t amdgpu_sem_handle;
+
 /*--*/
 /* -- Structures -- */
 /*--*/
@@ -365,6 +367,16 @@ struct amdgpu_cs_request {
struct amdgpu_cs_fence_info fence_info;
 };
 
+struct amdgpu_cs_request_sem {
+   /*
+*
+*/
+   uint32_t number_of_wait_sem;
+   uint32_t *wait_sems;
+   uint32_t number_of_signal_sem;
+   uint32_t *signal_sems;
+};
+
 /**
  * Structure which provide information about GPU VM MC Address space
  * alignments requirements
@@ -882,6 +894,12 @@ int amdgpu_cs_submit(amdgpu_context_handle context,
 struct amdgpu_cs_request *ibs_request,
 uint32_t number_of_requests);
 
+int amdgpu_cs_submit_sem(amdgpu_context_handle context,
+uint64_t flags,
+struct amdgpu_cs_request *ibs_request,
+struct amdgpu_cs_request_sem *ibs_sem,
+uint32_t number_of_requests);
+
 /**
  *  Query status of Command Buffer Submission
  *
@@ -1255,4 +1273,14 @@ int amdgpu_cs_destroy_semaphore(amdgpu_semaphore_handle 
sem);
 */
 const char *amdgpu_get_marketing_name(amdgpu_device_handle dev);
 
+int amdgpu_cs_create_sem(amdgpu_device_handle dev,
+amdgpu_sem_handle *sem);
+int amdgpu_cs_export_sem(amdgpu_device_handle dev,
+ amdgpu_sem_handle sem,
+int *shared_handle);
+int amdgpu_cs_import_sem(amdgpu_device_handle dev,
+ int shared_handle,
+amdgpu_sem_handle *sem);
+int amdgpu_cs_destroy_sem(amdgpu_device_handle dev,
+ amdgpu_sem_handle sem);
 #endif /* #ifdef _AMDGPU_H_ */
diff --git a/amdgpu/amdgpu_cs.c b/amdgpu/amdgpu_cs.c
index fb5b3a8..7283327 100644
--- a/amdgpu/amdgpu_cs.c
+++ b/amdgpu/amdgpu_cs.c
@@ -170,7 +170,8 @@ int amdgpu_cs_query_reset_state(amdgpu_context_handle 
context,
  * \sa amdgpu_cs_submit()
 */
 static int amdgpu_cs_submit_one(amdgpu_context_handle context,
-   struct amdgpu_cs_request *ibs_request)
+   struct amdgpu_cs_request *ibs_request,
+   struct amdgpu_cs_request_sem *sem_request)
 {
union drm_amdgpu_cs cs;
uint64_t *chunk_array;
@@ -178,9 +179,11 @@ static int amdgpu_cs_submit_one(amdgpu_context_handle 
context,
struct drm_amdgpu_cs_chunk_data *chunk_data;
struct drm_amdgpu_cs_chunk_dep *dependencies = NULL;
struct drm_amdgpu_cs_chunk_dep *sem_dependencies = NULL;
+   struct drm_amdgpu_cs_chunk_sem *wait_sem_dependencies = NULL;
+   struct drm_amdgpu_cs_chunk_sem *signal_sem_dependencies = NULL;
struct list_head *sem_list;
amdgpu_semaphore_handle sem, tmp;
-   uint32_t i, size, sem_count = 0;
+   uint32_t i, j, size, sem_count = 0;
bool user_fence;
int r = 0;
 
@@ -196,7 +199,7 @@ static int amdgpu_cs_submit_one(amdgpu_context_handle 
context,
}
user_fence = (ibs_request->fence_info.handle != NULL);
 
-   size = ibs_request->number_of_ibs + (user_fence ? 2 : 1) + 1;
+   size = ibs_request->number_of_ibs + (user_fence ? 2 : 1) + 1 + 
(sem_request ? 2 : 0);
 
chunk_array = alloca(sizeof(uint64_t) * size);
chunks = alloca(sizeof(struct drm_amdgpu_cs_chunk) * size);
@@ -308,6 +311,45 @@ static int amdgpu_cs_submit_one(amdgpu_context_handle 
context,
chunks[i].chunk_data = (uint64_t)(uintptr_t)sem_dependencies;
}
 
+   if (sem_request) {
+   if (sem_request->number_of_wait_sem) {
+   wait_sem_dependencies = malloc(sizeof(struct 
drm_amdgpu_cs_chunk_sem) * sem_request->number_of_wait_sem);
+   if (!wait_sem_dependencies) {
+   r = -ENOMEM;
+   goto error_unlock;
+   }
+   for (j = 0; j < sem_request->number_of_wait_sem; j++) {
+   struct 

Re: [PATCH] libdrm: add drm syncobj create/destroy/import/export

[Dave Airlie]

ping?

Dave.

On 17 June 2017 at 11:06, Dave Airlie  wrote:
> From: Dave Airlie 
>
> These ioctls are now in drm next so add the first set of libdrm APIs.
>
> Signed-off-by: Dave Airlie 
> ---
>  include/drm/drm.h | 26 ++
>  xf86drm.c | 81 
> +++
>  xf86drm.h |  8 ++
>  3 files changed, 115 insertions(+)
>
> diff --git a/include/drm/drm.h b/include/drm/drm.h
> index 1e7a4bc..bf3674a 100644
> --- a/include/drm/drm.h
> +++ b/include/drm/drm.h
> @@ -642,6 +642,7 @@ struct drm_gem_open {
>  #define DRM_CAP_ADDFB2_MODIFIERS   0x10
>  #define DRM_CAP_PAGE_FLIP_TARGET   0x11
>  #define DRM_CAP_CRTC_IN_VBLANK_EVENT   0x12
> +#define DRM_CAP_SYNCOBJ0x13
>
>  /** DRM_IOCTL_GET_CAP ioctl argument type */
>  struct drm_get_cap {
> @@ -691,6 +692,26 @@ struct drm_prime_handle {
> __s32 fd;
>  };
>
> +struct drm_syncobj_create {
> +   __u32 handle;
> +   __u32 flags;
> +};
> +
> +struct drm_syncobj_destroy {
> +   __u32 handle;
> +   __u32 pad;
> +};
> +
> +#define DRM_SYNCOBJ_FD_TO_HANDLE_FLAGS_IMPORT_SYNC_FILE (1 << 0)
> +#define DRM_SYNCOBJ_HANDLE_TO_FD_FLAGS_EXPORT_SYNC_FILE (1 << 0)
> +struct drm_syncobj_handle {
> +   __u32 handle;
> +   __u32 flags;
> +
> +   __s32 fd;
> +   __u32 pad;
> +};
> +
>  #if defined(__cplusplus)
>  }
>  #endif
> @@ -809,6 +830,11 @@ extern "C" {
>  #define DRM_IOCTL_MODE_CREATEPROPBLOB  DRM_IOWR(0xBD, struct 
> drm_mode_create_blob)
>  #define DRM_IOCTL_MODE_DESTROYPROPBLOB DRM_IOWR(0xBE, struct 
> drm_mode_destroy_blob)
>
> +#define DRM_IOCTL_SYNCOBJ_CREATE   DRM_IOWR(0xBF, struct 
> drm_syncobj_create)
> +#define DRM_IOCTL_SYNCOBJ_DESTROY  DRM_IOWR(0xC0, struct 
> drm_syncobj_destroy)
> +#define DRM_IOCTL_SYNCOBJ_HANDLE_TO_FD DRM_IOWR(0xC1, struct 
> drm_syncobj_handle)
> +#define DRM_IOCTL_SYNCOBJ_FD_TO_HANDLE DRM_IOWR(0xC2, struct 
> drm_syncobj_handle)
> +
>  /**
>   * Device specific ioctls should only be in their respective headers
>   * The device specific ioctl range is from 0x40 to 0x9f.
> diff --git a/xf86drm.c b/xf86drm.c
> index 728ac78..2ac3f26 100644
> --- a/xf86drm.c
> +++ b/xf86drm.c
> @@ -4146,3 +4146,84 @@ char *drmGetDeviceNameFromFd2(int fd)
>  return strdup(node);
>  #endif
>  }
> +
> +int drmSyncobjCreate(int fd, uint32_t flags, uint32_t *handle)
> +{
> +struct drm_syncobj_create args;
> +int ret;
> +
> +memclear(args);
> +args.flags = flags;
> +args.handle = 0;
> +ret = drmIoctl(fd, DRM_IOCTL_SYNCOBJ_CREATE, );
> +if (ret)
> +   return ret;
> +*handle = args.handle;
> +return 0;
> +}
> +
> +int drmSyncobjDestroy(int fd, uint32_t handle)
> +{
> +struct drm_syncobj_destroy args;
> +
> +memclear(args);
> +args.handle = handle;
> +return drmIoctl(fd, DRM_IOCTL_SYNCOBJ_DESTROY, );
> +}
> +
> +int drmSyncobjHandleToFD(int fd, uint32_t handle, int *obj_fd)
> +{
> +struct drm_syncobj_handle args;
> +int ret;
> +
> +memclear(args);
> +args.fd = -1;
> +args.handle = handle;
> +ret = drmIoctl(fd, DRM_IOCTL_SYNCOBJ_HANDLE_TO_FD, );
> +if (ret)
> +   return ret;
> +*obj_fd = args.fd;
> +return 0;
> +}
> +
> +int drmSyncobjFDToHandle(int fd, int obj_fd, uint32_t *handle)
> +{
> +struct drm_syncobj_handle args;
> +int ret;
> +
> +memclear(args);
> +args.fd = obj_fd;
> +args.handle = 0;
> +ret = drmIoctl(fd, DRM_IOCTL_SYNCOBJ_FD_TO_HANDLE, );
> +if (ret)
> +   return ret;
> +*handle = args.handle;
> +return 0;
> +}
> +
> +int drmSyncobjImportSyncFile(int fd, uint32_t handle, int sync_file_fd)
> +{
> +struct drm_syncobj_handle args;
> +
> +memclear(args);
> +args.fd = sync_file_fd;
> +args.handle = handle;
> +args.flags = DRM_SYNCOBJ_FD_TO_HANDLE_FLAGS_IMPORT_SYNC_FILE;
> +return drmIoctl(fd, DRM_IOCTL_SYNCOBJ_FD_TO_HANDLE, );
> +}
> +
> +int drmSyncobjExportSyncFile(int fd, uint32_t handle, int *sync_file_fd)
> +{
> +struct drm_syncobj_handle args;
> +int ret;
> +
> +memclear(args);
> +args.fd = -1;
> +args.handle = handle;
> +args.flags = DRM_SYNCOBJ_HANDLE_TO_FD_FLAGS_EXPORT_SYNC_FILE;
> +ret = drmIoctl(fd, DRM_IOCTL_SYNCOBJ_HANDLE_TO_FD, );
> +if (ret)
> +   return ret;
> +*sync_file_fd = args.fd;
> +return 0;
> +}
> diff --git a/xf86drm.h b/xf86drm.h
> index 74f54f1..2855a3e 100644
> --- a/xf86drm.h
> +++ b/xf86drm.h
> @@ -853,6 +853,14 @@ extern int drmGetDevices2(uint32_t flags, drmDevicePtr 
> devices[], int max_device
>
>  extern int drmDevicesEqual(drmDevicePtr a, drmDevicePtr b);
>
> +extern int drmSyncobjCreate(int fd, uint32_t flags, uint32_t *handle);
> +extern int drmSyncobjDestroy(int fd, uint32_t handle);
> +extern int drmSyncobjHandleToFD(int fd, uint32_t handle, int *obj_fd);
> +extern int drmSyncobjFDToHandle(int fd, int obj_fd, uint32_t 

Re: [PATCH 2/7] iomap: implement ioread64 and iowrite64

[Arnd Bergmann]

> +u64 ioread64(void __iomem *addr)
> +{
> +   u64 low, high;
> +
> +   low = ioread32(addr);
> +   high = ioread32(addr + sizeof(u32));
> +   return low | (high << 32);
> +}
> +u64 ioread64be(void __iomem *addr)
> +{
> +   u64 low, high;
> +
> +   low = ioread32be(addr + sizeof(u32));
> +   high = ioread32be(addr);
> +   return low | (high << 32);
> +}
> +#endif

This hardcodes the behavior of include/linux/io-64-nonatomic-hi-lo.h, which
I find rather confusing, as only about one in five drivers wants this
behavior.

I'd suggest you don't add it in lib/iomap.c at all for 32-bit architectures,
but rather use the same logic that we have for readq/writeq in
io-64-nonatomic-hi-lo.h and io-64-nonatomic-lo-hi.h, adding
{lo_hi,hi_lo}_{ioread,iowrite}{,be} to the same files, and provide
the {ioread,iowrite}{,be} macros only if they have not been defined
at that point.

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

[Bug 100289] 'flip queue failed in radeon_scanout_flip: Invalid argument' error and small frame buffer allocated on turning off and on new monitor

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100289

--- Comment #10 from Julien Isorce  ---
It could be that drm.debug=0x01 will tell you if the error comes from one of
the two "case:" here
https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/drm_plane.c?h=amd-staging-4.9#n796
.
If it is the case it should appear in dmesg.

Also worth a try with
https://launchpad.net/~paulo-miguel-dias/+archive/ubuntu/mesa with contains an
up to date version of xf86-video-ati.

The error message is different but I wonder if the patch attached to
https://bugs.freedesktop.org/show_bug.cgi?id=99769 would help here too.

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

[PATCH] drm/vmwgfx: Free hash table allocated by cmdbuf managed res mgr

[Thomas Hellstrom]

From: Deepak Rawat 

The hash table created during vmw_cmdbuf_res_man_create was
never freed. This causes memory leak in context creation.
Added the corresponding drm_ht_remove in vmw_cmdbuf_res_man_destroy.

Tested for memory leak by running piglit overnight and kernel
memory is not inflated which earlier was.

Cc: 
Signed-off-by: Deepak Rawat 
Reviewed-by: Sinclair Yeh 
Signed-off-by: Thomas Hellstrom 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c
index 13db8a2..1f013d4 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c
@@ -321,6 +321,7 @@ void vmw_cmdbuf_res_man_destroy(struct 
vmw_cmdbuf_res_manager *man)
list_for_each_entry_safe(entry, next, >list, head)
vmw_cmdbuf_res_free(man, entry);
 
+   drm_ht_remove(>resources);
kfree(man);
 }
 
-- 
2.7.4

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

Re: [PATCH v2 00/14] improve the fb_setcmap helper

[Dave Airlie]

>
> I'm traveling and cannot make progress this week. The merge window is
> also real close so this series will therefore probably miss it unless
> something unexpected happens...

Don't worry you missed the merge window for drm already, we don't merge
things after -rc6. Please remember the Linus merge window is for maintainers
to merge stuff to Linus, things need to be ready long before it, and for drm
you shouldn't really tie yourself to the merge cycle.

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

Re: [PATCH v2] drm/core: Fail atomic IOCTL with no CRTC state but with signaling.

[Harry Wentland]

On 2017-06-20 01:57 PM, Andrey Grodzovsky wrote:
> Problem : While running IGT kms_atomic_transition test suite i encountered
> a hang in drmHandleEvent immediately following  an atomic_commit.
> After dumping the atomic state I relized that in this case there was
> not even one CRTC attached to the state and only disabled
> planes. This probably due to a commit which hadn't changed any property
> which would require attaching crtc state. This means drmHandleEvent
> will never wake up from read since without CRTC in atomic state
> the event fd will not be signaled.
> 
> Fix: Protect against this issue by failing atomic_commit early in
> drm_mode_atomic_commit where such probelm can be identified.
> 
> v2:
> Fix typos and extra newlines.
> 
> Change-Id: I3ee28ffae35fd1e8bfe553146c44da53da02e6f8
> Signed-off-by: Andrey Grodzovsky 

Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/drm_atomic.c | 11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index a567310..48145bf 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1933,7 +1933,7 @@ static int prepare_crtc_signaling(struct drm_device 
> *dev,
>  {
>   struct drm_crtc *crtc;
>   struct drm_crtc_state *crtc_state;
> - int i, ret;
> + int i, c = 0, ret;
>  
>   if (arg->flags & DRM_MODE_ATOMIC_TEST_ONLY)
>   return 0;
> @@ -1994,8 +1994,17 @@ static int prepare_crtc_signaling(struct drm_device 
> *dev,
>  
>   crtc_state->event->base.fence = fence;
>   }
> +
> + c++;
>   }
>  
> + /*
> +  * Having this flag means user mode pends on event which will never
> +  * reach due to lack of at least one CRTC for signaling
> +  */
> + if (c == 0 && (arg->flags & DRM_MODE_PAGE_FLIP_EVENT))
> + return -EINVAL;
> +
>   return 0;
>  }
>  
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 100289] 'flip queue failed in radeon_scanout_flip: Invalid argument' error and small frame buffer allocated on turning off and on new monitor

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100289

--- Comment #9 from omegap...@startmail.com ---
As nothings happened on this ticket for a few months, I've reached the task
again. I can confirm DisplayPort-0 remains connected according to xrandr when
its off, prior to the problem happening.

I'm now running Xorg with '-logverbose 255', but nothing more is logged when
the problem occurs.

A new failure mode has emerged - sometimes the middle Samsung monitor goes off,
and requires disabling and reenabling via the XFCE4 Display program to get it
back on again (haven't tried with xrandr etc).

I'm a bit disappointed nothing more is logged by X, I'm going to see what I can
find out in XFCE4's tooling.

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

Re: [PATCH 1/2] drm: rcar-du: Restrict DPLL duty cycle workaround to H3 ES1.x

[Geert Uytterhoeven]

Hi Laurent,

On Wed, Jun 21, 2017 at 11:04 AM, Laurent Pinchart
 wrote:
> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> @@ -158,6 +157,11 @@ static void rcar_du_dpll_divider(struct rcar_du_crtc 
> *rcrtc,
>  best_diff);
>  }
>
> +static const struct soc_device_attribute rcar_du_r8a7795_es1[] = {
> +   { .soc_id = "r8a7795", .revision = "ES1.*" },
> +   { /* sentinel */ }
> +};
> +
>  static void rcar_du_crtc_set_display_timing(struct rcar_du_crtc *rcrtc)
>  {
> const struct drm_display_mode *mode = 
> >crtc.state->adjusted_mode;
> @@ -185,7 +189,20 @@ static void rcar_du_crtc_set_display_timing(struct 
> rcar_du_crtc *rcrtc)
>
> extclk = clk_get_rate(rcrtc->extclock);
> if (rcdu->info->dpll_ch & (1 << rcrtc->index)) {
> -   rcar_du_dpll_divider(rcrtc, , extclk, 
> mode_clock);
> +   unsigned long target = mode_clock;
> +
> +   /*
> +* The H3 ES1.x exhibits dot clock duty cycle 
> stability
> +* issues. We can work around them by configuring the
> +* DPLL to twice the desired frequency, coupled with a
> +* /2 post-divider. This isn't needed on other SoCs 
> and
> +* breaks HDMI output on M3-W for a currently unknown
> +* reason, so restrict the workaround to H3 ES1.x.
> +*/
> +   if (soc_device_match(rcar_du_r8a7795_es1))

Matching is done over and over again, on every display enable/resume.
Can it be done at probe time?
Or in rcar_du_crtc_create(), which has access to rcrtc?

> +   target *= 2;

You can also store the multiplier in rcar_du_r8a7795_es1.data
(store 1 in .data of the sentinel), removing the need for an if clause.

> +
> +   rcar_du_dpll_divider(rcrtc, , extclk, target);
> extclk = dpll.output;

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4] drm/sun4i: hdmi: Implement I2C adapter for A10s DDC bus

[Maxime Ripard]

On Sat, Jun 24, 2017 at 04:10:54PM +1000, Jonathan Liu wrote:
> The documentation for drm_do_get_edid in drivers/gpu/drm/drm_edid.c states:
> "As in the general case the DDC bus is accessible by the kernel at the I2C
> level, drivers must make all reasonable efforts to expose it as an I2C
> adapter and use drm_get_edid() instead of abusing this function."
> 
> Exposing the DDC bus as an I2C adapter is more beneficial as it can be used
> for purposes other than reading the EDID such as modifying the EDID or
> using the HDMI DDC pins as an I2C bus through the I2C dev interface from
> userspace (e.g. i2c-tools).
> 
> Implement this for A10s.
> 
> Signed-off-by: Jonathan Liu 
> ---
> Changes for v4:
>  - Carry over copyright from initial I2C code into sun4i_hdmi_i2c.c
>  - Clean up indentation in sun4i_hdmi.h
>  - Rename SUN4I_HDMI_DDC_MAX_TRANSFER_SIZE to SUN4I_HDMI_DDC_BYTE_COUNT_MAX
>and group it under the SUN4I_HDMI_DDC_BYTE_COUNT_REG define, changing the
>value to use the GENMASK macro to make it clear that it is derived from
>the width of the field in the register
>  - Fix SUN4I_HDMI_DDC_INT_STATUS_DDC_TX_FIFO_UNDERFLOW typo which should be
>SUN4I_HDMI_DDC_INT_STATUS_DDC_TX_FIFO_OVERFLOW
>  - Remove redundant rewriting of SUN4I_HDMI_DDC_INT_STATUS_REG register
>  - Change struct i2c_adapter to be const by using devm_kmemdup on creation
>  - Return -ETIMEDOUT instead of -EIO if there is timeout while transferring an
>I2C message
>  - Instead of waiting for 1-2 bytes to transfer, wait for the time it would
>take for remaining bytes to transfer (limited by FIFO size)
>  - Add additional comments
> 
> Changes for v3:
>  - Explain why drm_do_get_edid should be used and why it's better to expose it
>as an I2C adapter in commit message
>  - Reorder bit defines in descending order for consistency
>  - Keep old unused macros instead of removing them
>  - The v2 algorithm split large transfers into 16 byte transfers but this may
>cause a large single write to be treated as multiple writes causing data
>corruption. The algorithm has been reworked to not split larger transfers
>and make more use of the FIFO to avoid this.
>  - Moved the creation of the DDC clock from sun4i_hdmi_enc.c to
>sun4i_hdmi_i2c.c
>  - Reformatted code
>  - Instead of masking bits that we don't want to check for errors, explicitly
>check the error bits
>  - Clear error bits at start of transfer in case of error from previous 
> transfer
>  - Poll for completion of FIFO clear after setting FIFO clear bit
> 
> Changes for v2:
>  - Rebased against Maxime's sunxi-drm/for-next branch
>  - Fix up error paths in sun4i_hdmi_bind so that the I2C adapter is deleted if
>any of the calls after the I2C adapter is created fails
>  - Remove unnecessary includes in sun4i_hdmi_i2c.c
> 
>  drivers/gpu/drm/sun4i/Makefile |   1 +
>  drivers/gpu/drm/sun4i/sun4i_hdmi.h |  23 
>  drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 101 ++
>  drivers/gpu/drm/sun4i/sun4i_hdmi_i2c.c | 242 
> +
>  4 files changed, 277 insertions(+), 90 deletions(-)
>  create mode 100644 drivers/gpu/drm/sun4i/sun4i_hdmi_i2c.c
> 
> diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
> index e29fd3a2ba9c..43c753cafc88 100644
> --- a/drivers/gpu/drm/sun4i/Makefile
> +++ b/drivers/gpu/drm/sun4i/Makefile
> @@ -2,6 +2,7 @@ sun4i-drm-y += sun4i_drv.o
>  sun4i-drm-y += sun4i_framebuffer.o
>  
>  sun4i-drm-hdmi-y += sun4i_hdmi_enc.o
> +sun4i-drm-hdmi-y += sun4i_hdmi_i2c.o
>  sun4i-drm-hdmi-y += sun4i_hdmi_ddc_clk.o
>  sun4i-drm-hdmi-y += sun4i_hdmi_tmds_clk.o
>  
> diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi.h 
> b/drivers/gpu/drm/sun4i/sun4i_hdmi.h
> index 2f2f2ff1ea63..eaff92fe236c 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_hdmi.h
> +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi.h
> @@ -96,6 +96,7 @@
>  #define SUN4I_HDMI_DDC_CTRL_ENABLE   BIT(31)
>  #define SUN4I_HDMI_DDC_CTRL_START_CMDBIT(30)
>  #define SUN4I_HDMI_DDC_CTRL_FIFO_DIR_MASKBIT(8)
> +#define SUN4I_HDMI_DDC_CTRL_FIFO_DIR_WRITE   (1 << 8)
>  #define SUN4I_HDMI_DDC_CTRL_FIFO_DIR_READ(0 << 8)
>  #define SUN4I_HDMI_DDC_CTRL_RESETBIT(0)
>  
> @@ -105,14 +106,33 @@
>  #define SUN4I_HDMI_DDC_ADDR_OFFSET(off)  (((off) & 0xff) << 8)
>  #define SUN4I_HDMI_DDC_ADDR_SLAVE(addr)  ((addr) & 0xff)
>  
> +#define SUN4I_HDMI_DDC_INT_STATUS_REG0x50c
> +#define SUN4I_HDMI_DDC_INT_STATUS_ILLEGAL_FIFO_OPERATION BIT(7)
> +#define SUN4I_HDMI_DDC_INT_STATUS_DDC_RX_FIFO_UNDERFLOW  BIT(6)
> +#define SUN4I_HDMI_DDC_INT_STATUS_DDC_TX_FIFO_OVERFLOW   BIT(5)
> +#define SUN4I_HDMI_DDC_INT_STATUS_FIFO_REQUEST   BIT(4)
> +#define SUN4I_HDMI_DDC_INT_STATUS_ARBITRATION_ERROR  BIT(3)
> +#define SUN4I_HDMI_DDC_INT_STATUS_ACK_ERROR  BIT(2)
> +#define 

[PATCH v2 12/14] drm: rcar-du: Support multiple sources from the same VSP

[Laurent Pinchart]

On R-Car H3 ES2.0, DU channels 0 and 3 are served by two separate
pipelines from the same VSP. Support this in the DU driver.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c |  2 +-
 drivers/gpu/drm/rcar-du/rcar_du_crtc.h |  3 ++
 drivers/gpu/drm/rcar-du/rcar_du_kms.c  | 91 ++
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c  | 37 +++---
 drivers/gpu/drm/rcar-du/rcar_du_vsp.h  | 10 +++-
 5 files changed, 110 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 345eff72f581..8f942ebdd0c6 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -721,7 +721,7 @@ int rcar_du_crtc_create(struct rcar_du_group *rgrp, 
unsigned int index)
rcrtc->index = index;
 
if (rcar_du_has(rcdu, RCAR_DU_FEATURE_VSP1_SOURCE))
-   primary = >vsp->planes[0].plane;
+   primary = >vsp->planes[rcrtc->vsp_pipe].plane;
else
primary = >planes[index % 2].plane;
 
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
index b199ed5adf36..0b6d26ecfc38 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
@@ -35,6 +35,8 @@ struct rcar_du_vsp;
  * @flip_wait: wait queue used to signal page flip completion
  * @outputs: bitmask of the outputs (enum rcar_du_output) driven by this CRTC
  * @group: CRTC group this CRTC belongs to
+ * @vsp: VSP feeding video to this CRTC
+ * @vsp_pipe: index of the VSP pipeline feeding video to this CRTC
  */
 struct rcar_du_crtc {
struct drm_crtc crtc;
@@ -52,6 +54,7 @@ struct rcar_du_crtc {
 
struct rcar_du_group *group;
struct rcar_du_vsp *vsp;
+   unsigned int vsp_pipe;
 };
 
 #define to_rcar_crtc(c)container_of(c, struct rcar_du_crtc, crtc)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index f4125c8ca902..82b978a5dae6 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -432,6 +432,83 @@ static int rcar_du_properties_init(struct rcar_du_device 
*rcdu)
return 0;
 }
 
+static int rcar_du_vsps_init(struct rcar_du_device *rcdu)
+{
+   const struct device_node *np = rcdu->dev->of_node;
+   struct of_phandle_args args;
+   struct {
+   struct device_node *np;
+   unsigned int crtcs_mask;
+   } vsps[RCAR_DU_MAX_VSPS] = { { 0, }, };
+   unsigned int vsps_count = 0;
+   unsigned int cells;
+   unsigned int i;
+   int ret;
+
+   /*
+* First parse the DT vsps property to populate the list of VSPs. Each
+* entry contains a pointer to the VSP DT node and a bitmask of the
+* connected DU CRTCs.
+*/
+   cells = of_property_count_u32_elems(np, "vsps") / rcdu->num_crtcs - 1;
+   if (cells > 1)
+   return -EINVAL;
+
+   for (i = 0; i < rcdu->num_crtcs; ++i) {
+   unsigned int j;
+
+   ret = of_parse_phandle_with_fixed_args(np, "vsps", cells, i,
+  );
+   if (ret < 0)
+   goto error;
+
+   /*
+* Add the VSP to the list or update the corresponding existing
+* entry if the VSP has already been added.
+*/
+   for (j = 0; j < vsps_count; ++j) {
+   if (vsps[j].np == args.np)
+   break;
+   }
+
+   if (j < vsps_count)
+   of_node_put(args.np);
+   else
+   vsps[vsps_count++].np = args.np;
+
+   vsps[j].crtcs_mask |= 1 << i;
+
+   /* Store the VSP pointer and pipe index in the CRTC. */
+   rcdu->crtcs[i].vsp = >vsps[j];
+   rcdu->crtcs[i].vsp_pipe = cells >= 1 ? args.args[0] : 0;
+   }
+
+   /*
+* Then initialize all the VSPs from the node pointers and CRTCs bitmask
+* computed previously.
+*/
+   for (i = 0; i < vsps_count; ++i) {
+   struct rcar_du_vsp *vsp = >vsps[i];
+
+   vsp->index = i;
+   vsp->dev = rcdu;
+
+   ret = rcar_du_vsp_init(vsp, vsps[i].np, vsps[i].crtcs_mask);
+   if (ret < 0)
+   goto error;
+   }
+
+   return 0;
+
+error:
+   for (i = 0; i < ARRAY_SIZE(vsps); ++i) {
+   if (vsps[i].np)
+   of_node_put(vsps[i].np);
+   }
+
+   return ret;
+}
+
 int rcar_du_modeset_init(struct rcar_du_device *rcdu)
 {
static const unsigned int mmio_offsets[] = {
@@ -499,17 +576,9 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu)
 
/* Initialize the compositors. */
if 

[PATCH v2 03/14] v4l: vsp1: Don't set WPF sink pointer

[Laurent Pinchart]

The sink pointer is used to configure routing inside the VSP, and as
such must point to the next VSP entity in the pipeline. The WPF being a
pipeline terminal sink, its output route can't be configured. The
routing configuration code already handles this correctly without
referring to the sink pointer, which thus doesn't need to be set.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_drv.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/media/platform/vsp1/vsp1_drv.c 
b/drivers/media/platform/vsp1/vsp1_drv.c
index 6b35e043b554..35087d5573ce 100644
--- a/drivers/media/platform/vsp1/vsp1_drv.c
+++ b/drivers/media/platform/vsp1/vsp1_drv.c
@@ -412,7 +412,6 @@ static int vsp1_create_entities(struct vsp1_device *vsp1)
}
 
list_add_tail(>list, >videos);
-   wpf->entity.sink = >video.entity;
}
}
 
-- 
Regards,

Laurent Pinchart

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

[PATCH v2 05/14] v4l: vsp1: Don't create links for DRM pipeline

[Laurent Pinchart]

When the VSP1 is used in a DRM pipeline the driver doesn't register the
media device. Links between entities are not exposed to userspace, but
are still used internally for the sole purpose of setting up internal
source to sink pointers through the link setup handler.

Instead of going through this complex procedure, remove link creation
and set the sink pointers directly.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_drm.c | 53 --
 drivers/media/platform/vsp1/vsp1_drm.h |  1 -
 drivers/media/platform/vsp1/vsp1_drv.c | 16 --
 3 files changed, 12 insertions(+), 58 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index 2d5a74e95e09..c72d021ff820 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -487,6 +487,7 @@ void vsp1_du_atomic_flush(struct device *dev)
 
vsp1->bru->inputs[i].rpf = rpf;
rpf->bru_input = i;
+   rpf->entity.sink = >bru->entity;
rpf->entity.sink_pad = i;
 
dev_dbg(vsp1->dev, "%s: connecting RPF.%u to BRU:%u\n",
@@ -564,53 +565,6 @@ EXPORT_SYMBOL_GPL(vsp1_du_unmap_sg);
  * Initialization
  */
 
-int vsp1_drm_create_links(struct vsp1_device *vsp1)
-{
-   const u32 flags = MEDIA_LNK_FL_ENABLED | MEDIA_LNK_FL_IMMUTABLE;
-   unsigned int i;
-   int ret;
-
-   /*
-* VSPD instances require a BRU to perform composition and a LIF to
-* output to the DU.
-*/
-   if (!vsp1->bru || !vsp1->lif)
-   return -ENXIO;
-
-   for (i = 0; i < vsp1->info->rpf_count; ++i) {
-   struct vsp1_rwpf *rpf = vsp1->rpf[i];
-
-   ret = media_create_pad_link(>entity.subdev.entity,
-   RWPF_PAD_SOURCE,
-   >bru->entity.subdev.entity,
-   i, flags);
-   if (ret < 0)
-   return ret;
-
-   rpf->entity.sink = >bru->entity;
-   rpf->entity.sink_pad = i;
-   }
-
-   ret = media_create_pad_link(>bru->entity.subdev.entity,
-   vsp1->bru->entity.source_pad,
-   >wpf[0]->entity.subdev.entity,
-   RWPF_PAD_SINK, flags);
-   if (ret < 0)
-   return ret;
-
-   vsp1->bru->entity.sink = >wpf[0]->entity;
-   vsp1->bru->entity.sink_pad = RWPF_PAD_SINK;
-
-   ret = media_create_pad_link(>wpf[0]->entity.subdev.entity,
-   RWPF_PAD_SOURCE,
-   >lif->entity.subdev.entity,
-   LIF_PAD_SINK, flags);
-   if (ret < 0)
-   return ret;
-
-   return 0;
-}
-
 int vsp1_drm_init(struct vsp1_device *vsp1)
 {
struct vsp1_pipeline *pipe;
@@ -631,6 +585,11 @@ int vsp1_drm_init(struct vsp1_device *vsp1)
list_add_tail(>entity.list_pipe, >entities);
}
 
+   vsp1->bru->entity.sink = >wpf[0]->entity;
+   vsp1->bru->entity.sink_pad = 0;
+   vsp1->wpf[0]->entity.sink = >lif->entity;
+   vsp1->wpf[0]->entity.sink_pad = 0;
+
list_add_tail(>bru->entity.list_pipe, >entities);
list_add_tail(>wpf[0]->entity.list_pipe, >entities);
list_add_tail(>lif->entity.list_pipe, >entities);
diff --git a/drivers/media/platform/vsp1/vsp1_drm.h 
b/drivers/media/platform/vsp1/vsp1_drm.h
index cbdbb8a39883..67d6549edfad 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.h
+++ b/drivers/media/platform/vsp1/vsp1_drm.h
@@ -48,6 +48,5 @@ static inline struct vsp1_drm *to_vsp1_drm(struct 
vsp1_pipeline *pipe)
 
 int vsp1_drm_init(struct vsp1_device *vsp1);
 void vsp1_drm_cleanup(struct vsp1_device *vsp1);
-int vsp1_drm_create_links(struct vsp1_device *vsp1);
 
 #endif /* __VSP1_DRM_H__ */
diff --git a/drivers/media/platform/vsp1/vsp1_drv.c 
b/drivers/media/platform/vsp1/vsp1_drv.c
index 9b3a0790f92a..5a467b118a1c 100644
--- a/drivers/media/platform/vsp1/vsp1_drv.c
+++ b/drivers/media/platform/vsp1/vsp1_drv.c
@@ -423,19 +423,15 @@ static int vsp1_create_entities(struct vsp1_device *vsp1)
goto done;
}
 
-   /* Create links. */
-   if (vsp1->info->uapi)
-   ret = vsp1_uapi_create_links(vsp1);
-   else
-   ret = vsp1_drm_create_links(vsp1);
-   if (ret < 0)
-   goto done;
-
/*
-* Register subdev nodes if the userspace API is enabled or initialize
-* the DRM pipeline otherwise.
+* Create links and register subdev nodes if the userspace API is
+* enabled or initialize the DRM pipeline otherwise.
 */
if (vsp1->info->uapi) {
+   ret = vsp1_uapi_create_links(vsp1);
+   if (ret < 0)
+  

[PATCH v2 10/14] v4l: vsp1: Add support for multiple DRM pipelines

[Laurent Pinchart]

The R-Car H3 ES2.0 VSP-DL instance has two LIF entities and can drive
two display pipelines at the same time. Refactor the VSP DRM code to
support that by introducing a vsp_drm_pipeline object that models one
display pipeline.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_drm.c | 200 -
 drivers/media/platform/vsp1/vsp1_drm.h |  35 +++---
 2 files changed, 141 insertions(+), 94 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index 4e1b893e8f51..7791d7b5a743 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -34,10 +34,10 @@
 
 static void vsp1_du_pipeline_frame_end(struct vsp1_pipeline *pipe)
 {
-   struct vsp1_drm *drm = to_vsp1_drm(pipe);
+   struct vsp1_drm_pipeline *drm_pipe = to_vsp1_drm_pipeline(pipe);
 
-   if (drm->du_complete)
-   drm->du_complete(drm->du_private);
+   if (drm_pipe->du_complete)
+   drm_pipe->du_complete(drm_pipe->du_private);
 }
 
 /* 
-
@@ -80,15 +80,22 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int 
pipe_index,
  const struct vsp1_du_lif_config *cfg)
 {
struct vsp1_device *vsp1 = dev_get_drvdata(dev);
-   struct vsp1_pipeline *pipe = >drm->pipe;
-   struct vsp1_bru *bru = vsp1->bru;
+   struct vsp1_drm_pipeline *drm_pipe;
+   struct vsp1_pipeline *pipe;
+   struct vsp1_bru *bru;
struct v4l2_subdev_format format;
+   const char *bru_name;
unsigned int i;
int ret;
 
-   if (pipe_index > 0)
+   if (pipe_index >= vsp1->info->lif_count)
return -EINVAL;
 
+   drm_pipe = >drm->pipe[pipe_index];
+   pipe = _pipe->pipe;
+   bru = to_bru(>bru->subdev);
+   bru_name = pipe->bru->type == VSP1_ENTITY_BRU ? "BRU" : "BRS";
+
if (!cfg) {
/*
 * NULL configuration means the CRTC is being disabled, stop
@@ -100,14 +107,25 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int 
pipe_index,
 
media_pipeline_stop(>output->entity.subdev.entity);
 
-   for (i = 0; i < bru->entity.source_pad; ++i) {
-   vsp1->drm->inputs[i].enabled = false;
-   bru->inputs[i].rpf = NULL;
+   for (i = 0; i < ARRAY_SIZE(pipe->inputs); ++i) {
+   struct vsp1_rwpf *rpf = pipe->inputs[i];
+
+   if (!rpf)
+   continue;
+
+   /*
+* Remove the RPF from the pipe and the list of BRU
+* inputs.
+*/
+   WARN_ON(list_empty(>entity.list_pipe));
+   list_del_init(>entity.list_pipe);
pipe->inputs[i] = NULL;
+
+   bru->inputs[rpf->bru_input].rpf = NULL;
}
 
+   drm_pipe->du_complete = NULL;
pipe->num_inputs = 0;
-   vsp1->drm->du_complete = NULL;
 
vsp1_dlm_reset(pipe->output->dlm);
vsp1_device_put(vsp1);
@@ -117,8 +135,8 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int 
pipe_index,
return 0;
}
 
-   dev_dbg(vsp1->dev, "%s: configuring LIF with format %ux%u\n",
-   __func__, cfg->width, cfg->height);
+   dev_dbg(vsp1->dev, "%s: configuring LIF%u with format %ux%u\n",
+   __func__, pipe_index, cfg->width, cfg->height);
 
/*
 * Configure the format at the BRU sinks and propagate it through the
@@ -127,7 +145,7 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int 
pipe_index,
memset(, 0, sizeof(format));
format.which = V4L2_SUBDEV_FORMAT_ACTIVE;
 
-   for (i = 0; i < bru->entity.source_pad; ++i) {
+   for (i = 0; i < pipe->bru->source_pad; ++i) {
format.pad = i;
 
format.format.width = cfg->width;
@@ -135,60 +153,60 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int 
pipe_index,
format.format.code = MEDIA_BUS_FMT_ARGB_1X32;
format.format.field = V4L2_FIELD_NONE;
 
-   ret = v4l2_subdev_call(>entity.subdev, pad,
+   ret = v4l2_subdev_call(>bru->subdev, pad,
   set_fmt, NULL, );
if (ret < 0)
return ret;
 
-   dev_dbg(vsp1->dev, "%s: set format %ux%u (%x) on BRU pad %u\n",
+   dev_dbg(vsp1->dev, "%s: set format %ux%u (%x) on %s pad %u\n",
__func__, format.format.width, format.format.height,
-   format.format.code, i);
+   format.format.code, bru_name, i);
}
 
-   format.pad 

[PATCH v2 14/14] drm: rcar-du: Configure DPAD0 routing through last group on Gen3

[Laurent Pinchart]

On Gen3 SoCs DPAD0 routing is configured through the last CRTC group,
unlike on Gen2 where it is configured through the first CRTC group. Fix
the driver accordingly.

Fixes: 2427b3037710 ("drm: rcar-du: Add R8A7795 device support")
Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_group.c | 21 ++---
 1 file changed, 14 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_group.c 
b/drivers/gpu/drm/rcar-du/rcar_du_group.c
index 64738fca96d0..2abb2fdd143e 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_group.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_group.c
@@ -208,23 +208,30 @@ void rcar_du_group_restart(struct rcar_du_group *rgrp)
 
 int rcar_du_set_dpad0_vsp1_routing(struct rcar_du_device *rcdu)
 {
+   struct rcar_du_group *rgrp;
+   struct rcar_du_crtc *crtc;
int ret;
 
if (!rcar_du_has(rcdu, RCAR_DU_FEATURE_EXT_CTRL_REGS))
return 0;
 
-   /* RGB output routing to DPAD0 and VSP1D routing to DU0/1/2 are
-* configured in the DEFR8 register of the first group. As this function
-* can be called with the DU0 and DU1 CRTCs disabled, we need to enable
-* the first group clock before accessing the register.
+   /*
+* RGB output routing to DPAD0 and VSP1D routing to DU0/1/2 are
+* configured in the DEFR8 register of the first group on Gen2 and the
+* last group on Gen3. As this function can be called with the DU
+* channels of the corresponding CRTCs disabled, we need to enable the
+* group clock before accessing the register.
 */
-   ret = clk_prepare_enable(rcdu->crtcs[0].clock);
+   rgrp = >groups[DIV_ROUND_UP(rcdu->num_crtcs, 2) - 1];
+   crtc = >crtcs[rgrp->index * 2];
+
+   ret = clk_prepare_enable(crtc->clock);
if (ret < 0)
return ret;
 
-   rcar_du_group_setup_defr8(>groups[0]);
+   rcar_du_group_setup_defr8(rgrp);
 
-   clk_disable_unprepare(rcdu->crtcs[0].clock);
+   clk_disable_unprepare(crtc->clock);
 
return 0;
 }
-- 
Regards,

Laurent Pinchart

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

[PATCH v2 06/14] v4l: vsp1: Add pipe index argument to the VSP-DU API

[Laurent Pinchart]

In the H3 ES2.0 SoC the VSP2-DL instance has two connections to DU
channels that need to be configured independently. Extend the VSP-DU API
with a pipeline index to identify which pipeline the caller wants to
operate on.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c  | 12 ++--
 drivers/media/platform/vsp1/vsp1_drm.c | 32 ++--
 include/media/vsp1.h   | 10 ++
 3 files changed, 34 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c 
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
index f870445ebc8d..d46dce054442 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
@@ -81,22 +81,22 @@ void rcar_du_vsp_enable(struct rcar_du_crtc *crtc)
 */
crtc->group->need_restart = true;
 
-   vsp1_du_setup_lif(crtc->vsp->vsp, );
+   vsp1_du_setup_lif(crtc->vsp->vsp, 0, );
 }
 
 void rcar_du_vsp_disable(struct rcar_du_crtc *crtc)
 {
-   vsp1_du_setup_lif(crtc->vsp->vsp, NULL);
+   vsp1_du_setup_lif(crtc->vsp->vsp, 0, NULL);
 }
 
 void rcar_du_vsp_atomic_begin(struct rcar_du_crtc *crtc)
 {
-   vsp1_du_atomic_begin(crtc->vsp->vsp);
+   vsp1_du_atomic_begin(crtc->vsp->vsp, 0);
 }
 
 void rcar_du_vsp_atomic_flush(struct rcar_du_crtc *crtc)
 {
-   vsp1_du_atomic_flush(crtc->vsp->vsp);
+   vsp1_du_atomic_flush(crtc->vsp->vsp, 0);
 }
 
 /* Keep the two tables in sync. */
@@ -192,7 +192,7 @@ static void rcar_du_vsp_plane_setup(struct 
rcar_du_vsp_plane *plane)
}
}
 
-   vsp1_du_atomic_update(plane->vsp->vsp, plane->index, );
+   vsp1_du_atomic_update(plane->vsp->vsp, 0, plane->index, );
 }
 
 static int rcar_du_vsp_plane_prepare_fb(struct drm_plane *plane,
@@ -292,7 +292,7 @@ static void rcar_du_vsp_plane_atomic_update(struct 
drm_plane *plane,
if (plane->state->crtc)
rcar_du_vsp_plane_setup(rplane);
else
-   vsp1_du_atomic_update(rplane->vsp->vsp, rplane->index, NULL);
+   vsp1_du_atomic_update(rplane->vsp->vsp, 0, rplane->index, NULL);
 }
 
 static const struct drm_plane_helper_funcs rcar_du_vsp_plane_helper_funcs = {
diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index c72d021ff820..daaafe7885fa 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -58,21 +58,26 @@ EXPORT_SYMBOL_GPL(vsp1_du_init);
 /**
  * vsp1_du_setup_lif - Setup the output part of the VSP pipeline
  * @dev: the VSP device
+ * @pipe_index: the DRM pipeline index
  * @cfg: the LIF configuration
  *
  * Configure the output part of VSP DRM pipeline for the given frame @cfg.width
- * and @cfg.height. This sets up formats on the BRU source pad, the WPF0 sink
- * and source pads, and the LIF sink pad.
+ * and @cfg.height. This sets up formats on the blend unit (BRU or BRS) source
+ * pad, the WPF sink and source pads, and the LIF sink pad.
  *
- * As the media bus code on the BRU source pad is conditioned by the
- * configuration of the BRU sink 0 pad, we also set up the formats on all BRU
+ * The @pipe_index argument selects which DRM pipeline to setup. The number of
+ * available pipelines depend on the VSP instance.
+ *
+ * As the media bus code on the blend unit source pad is conditioned by the
+ * configuration of its sink 0 pad, we also set up the formats on all blend 
unit
  * sinks, even if the configuration will be overwritten later by
- * vsp1_du_setup_rpf(). This ensures that the BRU configuration is set to a 
well
- * defined state.
+ * vsp1_du_setup_rpf(). This ensures that the blend unit configuration is set 
to
+ * a well defined state.
  *
  * Return 0 on success or a negative error code on failure.
  */
-int vsp1_du_setup_lif(struct device *dev, const struct vsp1_du_lif_config *cfg)
+int vsp1_du_setup_lif(struct device *dev, unsigned int pipe_index,
+ const struct vsp1_du_lif_config *cfg)
 {
struct vsp1_device *vsp1 = dev_get_drvdata(dev);
struct vsp1_pipeline *pipe = >drm->pipe;
@@ -81,6 +86,9 @@ int vsp1_du_setup_lif(struct device *dev, const struct 
vsp1_du_lif_config *cfg)
unsigned int i;
int ret;
 
+   if (pipe_index > 0)
+   return -EINVAL;
+
if (!cfg) {
/*
 * NULL configuration means the CRTC is being disabled, stop
@@ -232,8 +240,9 @@ EXPORT_SYMBOL_GPL(vsp1_du_setup_lif);
 /**
  * vsp1_du_atomic_begin - Prepare for an atomic update
  * @dev: the VSP device
+ * @pipe_index: the DRM pipeline index
  */
-void vsp1_du_atomic_begin(struct device *dev)
+void vsp1_du_atomic_begin(struct device *dev, unsigned int pipe_index)
 {
struct vsp1_device *vsp1 = dev_get_drvdata(dev);
struct vsp1_pipeline *pipe = >drm->pipe;
@@ -245,6 +254,7 @@ EXPORT_SYMBOL_GPL(vsp1_du_atomic_begin);
 /**
  * vsp1_du_atomic_update - 

[PATCH v2 13/14] drm: rcar-du: Restrict DPLL duty cycle workaround to H3 ES1.x

[Laurent Pinchart]

The H3 ES1.x exhibits dot clock duty cycle stability issues. We can work
around them by configuring the DPLL to twice the desired frequency,
coupled with a /2 post-divider. This isn't needed on other SoCs and
breaks HDMI output on M3-W for a currently unknown reason, so restrict
the workaround to H3 ES1.x.

From an implementation point of view, move work around handling outside
of the rcar_du_dpll_divider() function by requesting a x2 DPLL output
frequency explicitly. The existing post-divider calculation mechanism
will then take care of dividing the clock by two automatically.

While at it, print a more useful debugging message to ease debugging
clock rate issues.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 37 +-
 1 file changed, 27 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 8f942ebdd0c6..6c29981377c0 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -13,6 +13,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -129,10 +130,8 @@ static void rcar_du_dpll_divider(struct rcar_du_crtc 
*rcrtc,
for (fdpll = 1; fdpll < 32; fdpll++) {
unsigned long output;
 
-   /* 1/2 (FRQSEL=1) for duty rate 50% */
output = input * (n + 1) / (m + 1)
-  / (fdpll + 1) / 2;
-
+  / (fdpll + 1);
if (output >= 4)
continue;
 
@@ -158,6 +157,11 @@ static void rcar_du_dpll_divider(struct rcar_du_crtc 
*rcrtc,
 best_diff);
 }
 
+static const struct soc_device_attribute rcar_du_r8a7795_es1[] = {
+   { .soc_id = "r8a7795", .revision = "ES1.*" },
+   { /* sentinel */ }
+};
+
 static void rcar_du_crtc_set_display_timing(struct rcar_du_crtc *rcrtc)
 {
const struct drm_display_mode *mode = >crtc.state->adjusted_mode;
@@ -185,7 +189,20 @@ static void rcar_du_crtc_set_display_timing(struct 
rcar_du_crtc *rcrtc)
 
extclk = clk_get_rate(rcrtc->extclock);
if (rcdu->info->dpll_ch & (1 << rcrtc->index)) {
-   rcar_du_dpll_divider(rcrtc, , extclk, mode_clock);
+   unsigned long target = mode_clock;
+
+   /*
+* The H3 ES1.x exhibits dot clock duty cycle stability
+* issues. We can work around them by configuring the
+* DPLL to twice the desired frequency, coupled with a
+* /2 post-divider. This isn't needed on other SoCs and
+* breaks HDMI output on M3-W for a currently unknown
+* reason, so restrict the workaround to H3 ES1.x.
+*/
+   if (soc_device_match(rcar_du_r8a7795_es1))
+   target *= 2;
+
+   rcar_du_dpll_divider(rcrtc, , extclk, target);
extclk = dpll.output;
}
 
@@ -197,8 +214,6 @@ static void rcar_du_crtc_set_display_timing(struct 
rcar_du_crtc *rcrtc)
 
if (abs((long)extrate - (long)mode_clock) <
abs((long)rate - (long)mode_clock)) {
-   dev_dbg(rcrtc->group->dev->dev,
-   "crtc%u: using external clock\n", rcrtc->index);
 
if (rcdu->info->dpll_ch & (1 << rcrtc->index)) {
u32 dpllcr = DPLLCR_CODE | DPLLCR_CLKE
@@ -215,12 +230,14 @@ static void rcar_du_crtc_set_display_timing(struct 
rcar_du_crtc *rcrtc)
 
rcar_du_group_write(rcrtc->group, DPLLCR,
dpllcr);
-
-   escr = ESCR_DCLKSEL_DCLKIN | 1;
-   } else {
-   escr = ESCR_DCLKSEL_DCLKIN | extdiv;
}
+
+   escr = ESCR_DCLKSEL_DCLKIN | extdiv;
}
+
+   dev_dbg(rcrtc->group->dev->dev,
+   "mode clock %lu extrate %lu rate %lu ESCR 0x%08x\n",
+   mode_clock, extrate, rate, escr);
}
 
rcar_du_group_write(rcrtc->group, rcrtc->index % 2 ? ESCR2 : ESCR,
-- 
Regards,

Laurent Pinchart

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

[PATCH v2 11/14] v4l: vsp1: Add support for header display lists in continuous mode

[Laurent Pinchart]

The VSP supports both header and headerless display lists. The latter is
easier to use when the VSP feeds data directly to the DU in continuous
mode, and the driver thus uses headerless display lists for DU operation
and header display lists otherwise.

Headerless display lists are only available on WPF.0. This has never
been an issue so far, as only WPF.0 is connected to the DU. However, on
H3 ES2.0, the VSP-DL instance has both WPF.0 and WPF.1 connected to the
DU. We thus can't use headerless display lists unconditionally for DU
operation.

Implement support for continuous mode with header display lists, and use
it for DU operation on WPF outputs that don't support headerless mode.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_dl.c   | 195 +---
 drivers/media/platform/vsp1/vsp1_regs.h |   1 +
 2 files changed, 127 insertions(+), 69 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_dl.c 
b/drivers/media/platform/vsp1/vsp1_dl.c
index bb92be4fe0f0..8b5cbb6b7a70 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -95,6 +95,7 @@ enum vsp1_dl_mode {
  * struct vsp1_dl_manager - Display List manager
  * @index: index of the related WPF
  * @mode: display list operation mode (header or headerless)
+ * @singleshot: execute the display list in single-shot mode
  * @vsp1: the VSP1 device
  * @lock: protects the free, active, queued, pending and gc_fragments lists
  * @free: array of all free display lists
@@ -107,6 +108,7 @@ enum vsp1_dl_mode {
 struct vsp1_dl_manager {
unsigned int index;
enum vsp1_dl_mode mode;
+   bool singleshot;
struct vsp1_device *vsp1;
 
spinlock_t lock;
@@ -437,6 +439,7 @@ int vsp1_dl_list_add_chain(struct vsp1_dl_list *head,
 
 static void vsp1_dl_list_fill_header(struct vsp1_dl_list *dl, bool is_last)
 {
+   struct vsp1_dl_manager *dlm = dl->dlm;
struct vsp1_dl_header_list *hdr = dl->header->lists;
struct vsp1_dl_body *dlb;
unsigned int num_lists = 0;
@@ -461,85 +464,145 @@ static void vsp1_dl_list_fill_header(struct vsp1_dl_list 
*dl, bool is_last)
 
dl->header->num_lists = num_lists;
 
-   /*
-* If this display list's chain is not empty, we are on a list, where
-* the next item in the list is the display list entity which should be
-* automatically queued by the hardware.
-*/
if (!list_empty(>chain) && !is_last) {
+   /*
+* If this display list's chain is not empty, we are on a list,
+* and the next item is the display list that we must queue for
+* automatic processing by the hardware.
+*/
struct vsp1_dl_list *next = list_next_entry(dl, chain);
 
dl->header->next_header = next->dma;
dl->header->flags = VSP1_DLH_AUTO_START;
+   } else if (!dlm->singleshot) {
+   /*
+* if the display list manager works in continuous mode, the VSP
+* should loop over the display list continuously until
+* instructed to do otherwise.
+*/
+   dl->header->next_header = dl->dma;
+   dl->header->flags = VSP1_DLH_INT_ENABLE | VSP1_DLH_AUTO_START;
} else {
+   /*
+* Otherwise, in mem-to-mem mode, we work in single-shot mode
+* and the next display list must not be started automatically.
+*/
dl->header->flags = VSP1_DLH_INT_ENABLE;
}
 }
 
-void vsp1_dl_list_commit(struct vsp1_dl_list *dl)
+static bool vsp1_dl_list_hw_update_pending(struct vsp1_dl_manager *dlm)
 {
-   struct vsp1_dl_manager *dlm = dl->dlm;
struct vsp1_device *vsp1 = dlm->vsp1;
-   unsigned long flags;
-   bool update;
-
-   if (dl->dlm->mode == VSP1_DL_MODE_HEADER) {
-   struct vsp1_dl_list *dl_child;
-
-   /*
-* In header mode the caller guarantees that the hardware is
-* idle at this point.
-*/
 
-   /* Fill the header for the head and chained display lists. */
-   vsp1_dl_list_fill_header(dl, list_empty(>chain));
-
-   list_for_each_entry(dl_child, >chain, chain) {
-   bool last = list_is_last(_child->chain, >chain);
+   if (!dlm->queued)
+   return false;
 
-   vsp1_dl_list_fill_header(dl_child, last);
-   }
-   }
+   /*
+* Check whether the VSP1 has taken the update. In headerless mode the
+* hardware indicates this by clearing the UPD bit in the DL_BODY_SIZE
+* register, and in header mode by clearing the UPDHDR bit in the CMD
+* register.
+*/
+   if (dlm->mode == VSP1_DL_MODE_HEADERLESS)
+   return 

[PATCH v2 08/14] v4l: vsp1: Add support for new VSP2-BS, VSP2-DL and VSP2-D instances

[Laurent Pinchart]

New Gen3 SoCs come with two new VSP2 variants names VSP2-BS and VSP2-DL,
as well as a new VSP2-D variant on V3M and V3H SoCs. Add new entries for
them in the VSP device info table.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_drv.c  | 24 
 drivers/media/platform/vsp1/vsp1_regs.h | 15 +--
 2 files changed, 37 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_drv.c 
b/drivers/media/platform/vsp1/vsp1_drv.c
index 6a9aeb71aedf..c4f2ac61f7d2 100644
--- a/drivers/media/platform/vsp1/vsp1_drv.c
+++ b/drivers/media/platform/vsp1/vsp1_drv.c
@@ -710,6 +710,14 @@ static const struct vsp1_device_info vsp1_device_infos[] = 
{
.num_bru_inputs = 5,
.uapi = true,
}, {
+   .version = VI6_IP_VERSION_MODEL_VSPBS_GEN3,
+   .model = "VSP2-BS",
+   .gen = 3,
+   .features = VSP1_HAS_BRS,
+   .rpf_count = 2,
+   .wpf_count = 1,
+   .uapi = true,
+   }, {
.version = VI6_IP_VERSION_MODEL_VSPD_GEN3,
.model = "VSP2-D",
.gen = 3,
@@ -717,6 +725,22 @@ static const struct vsp1_device_info vsp1_device_infos[] = 
{
.rpf_count = 5,
.wpf_count = 2,
.num_bru_inputs = 5,
+   }, {
+   .version = VI6_IP_VERSION_MODEL_VSPD_V3,
+   .model = "VSP2-D",
+   .gen = 3,
+   .features = VSP1_HAS_BRS | VSP1_HAS_BRU | VSP1_HAS_LIF,
+   .rpf_count = 5,
+   .wpf_count = 1,
+   .num_bru_inputs = 5,
+   }, {
+   .version = VI6_IP_VERSION_MODEL_VSPDL_GEN3,
+   .model = "VSP2-DL",
+   .gen = 3,
+   .features = VSP1_HAS_BRS | VSP1_HAS_BRU | VSP1_HAS_LIF,
+   .rpf_count = 5,
+   .wpf_count = 2,
+   .num_bru_inputs = 5,
},
 };
 
diff --git a/drivers/media/platform/vsp1/vsp1_regs.h 
b/drivers/media/platform/vsp1/vsp1_regs.h
index 744217e020b9..ab439a60a100 100644
--- a/drivers/media/platform/vsp1/vsp1_regs.h
+++ b/drivers/media/platform/vsp1/vsp1_regs.h
@@ -699,9 +699,20 @@
 #define VI6_IP_VERSION_MODEL_VSPBD_GEN3(0x15 << 8)
 #define VI6_IP_VERSION_MODEL_VSPBC_GEN3(0x16 << 8)
 #define VI6_IP_VERSION_MODEL_VSPD_GEN3 (0x17 << 8)
+#define VI6_IP_VERSION_MODEL_VSPD_V3   (0x18 << 8)
+#define VI6_IP_VERSION_MODEL_VSPDL_GEN3(0x19 << 8)
+#define VI6_IP_VERSION_MODEL_VSPBS_GEN3(0x1a << 8)
 #define VI6_IP_VERSION_SOC_MASK(0xff << 0)
-#define VI6_IP_VERSION_SOC_H   (0x01 << 0)
-#define VI6_IP_VERSION_SOC_M   (0x02 << 0)
+#define VI6_IP_VERSION_SOC_H2  (0x01 << 0)
+#define VI6_IP_VERSION_SOC_V2H (0x01 << 0)
+#define VI6_IP_VERSION_SOC_V3M (0x01 << 0)
+#define VI6_IP_VERSION_SOC_M2  (0x02 << 0)
+#define VI6_IP_VERSION_SOC_M3W (0x02 << 0)
+#define VI6_IP_VERSION_SOC_V3H (0x02 << 0)
+#define VI6_IP_VERSION_SOC_H3  (0x03 << 0)
+#define VI6_IP_VERSION_SOC_D3  (0x04 << 0)
+#define VI6_IP_VERSION_SOC_M3N (0x04 << 0)
+#define VI6_IP_VERSION_SOC_E3  (0x04 << 0)
 
 /* 
-
  * RPF CLUT Registers
-- 
Regards,

Laurent Pinchart

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

[PATCH v2 09/14] v4l: vsp1: Add support for multiple LIF instances

[Laurent Pinchart]

The VSP2-DL instance (present in the H3 ES2.0 and M3-N SoCs) has two LIF
instances. Adapt the driver infrastructure to support multiple LIFs.
Support for multiple display pipelines will be added separately.

The change to the entity routing table removes the ability to connect
the LIF output to the HGO or HGT histogram generators. This feature is
only available on Gen2 hardware, isn't supported by the rest of the
driver, and has no known use case, so this isn't an issue.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1.h|  5 ++--
 drivers/media/platform/vsp1/vsp1_drm.c|  8 ++---
 drivers/media/platform/vsp1/vsp1_drv.c| 49 +++
 drivers/media/platform/vsp1/vsp1_entity.c |  3 +-
 drivers/media/platform/vsp1/vsp1_lif.c|  5 ++--
 drivers/media/platform/vsp1/vsp1_lif.h|  2 +-
 drivers/media/platform/vsp1/vsp1_regs.h   |  4 ++-
 7 files changed, 46 insertions(+), 30 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1.h 
b/drivers/media/platform/vsp1/vsp1.h
index 73858a0ed35c..78ef838416b3 100644
--- a/drivers/media/platform/vsp1/vsp1.h
+++ b/drivers/media/platform/vsp1/vsp1.h
@@ -41,11 +41,11 @@ struct vsp1_rwpf;
 struct vsp1_sru;
 struct vsp1_uds;
 
+#define VSP1_MAX_LIF   2
 #define VSP1_MAX_RPF   5
 #define VSP1_MAX_UDS   3
 #define VSP1_MAX_WPF   4
 
-#define VSP1_HAS_LIF   (1 << 0)
 #define VSP1_HAS_LUT   (1 << 1)
 #define VSP1_HAS_SRU   (1 << 2)
 #define VSP1_HAS_BRU   (1 << 3)
@@ -61,6 +61,7 @@ struct vsp1_device_info {
const char *model;
unsigned int gen;
unsigned int features;
+   unsigned int lif_count;
unsigned int rpf_count;
unsigned int uds_count;
unsigned int wpf_count;
@@ -84,7 +85,7 @@ struct vsp1_device {
struct vsp1_hgt *hgt;
struct vsp1_hsit *hsi;
struct vsp1_hsit *hst;
-   struct vsp1_lif *lif;
+   struct vsp1_lif *lif[VSP1_MAX_LIF];
struct vsp1_lut *lut;
struct vsp1_rwpf *rpf[VSP1_MAX_RPF];
struct vsp1_sru *sru;
diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index daaafe7885fa..4e1b893e8f51 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -181,7 +181,7 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int 
pipe_index,
format.format.code);
 
format.pad = LIF_PAD_SINK;
-   ret = v4l2_subdev_call(>lif->entity.subdev, pad, set_fmt, NULL,
+   ret = v4l2_subdev_call(>lif[0]->entity.subdev, pad, set_fmt, NULL,
   );
if (ret < 0)
return ret;
@@ -599,15 +599,15 @@ int vsp1_drm_init(struct vsp1_device *vsp1)
 
vsp1->bru->entity.sink = >wpf[0]->entity;
vsp1->bru->entity.sink_pad = 0;
-   vsp1->wpf[0]->entity.sink = >lif->entity;
+   vsp1->wpf[0]->entity.sink = >lif[0]->entity;
vsp1->wpf[0]->entity.sink_pad = 0;
 
list_add_tail(>bru->entity.list_pipe, >entities);
list_add_tail(>wpf[0]->entity.list_pipe, >entities);
-   list_add_tail(>lif->entity.list_pipe, >entities);
+   list_add_tail(>lif[0]->entity.list_pipe, >entities);
 
pipe->bru = >bru->entity;
-   pipe->lif = >lif->entity;
+   pipe->lif = >lif[0]->entity;
pipe->output = vsp1->wpf[0];
pipe->output->pipe = pipe;
pipe->frame_end = vsp1_du_pipeline_frame_end;
diff --git a/drivers/media/platform/vsp1/vsp1_drv.c 
b/drivers/media/platform/vsp1/vsp1_drv.c
index c4f2ac61f7d2..e875982f02ae 100644
--- a/drivers/media/platform/vsp1/vsp1_drv.c
+++ b/drivers/media/platform/vsp1/vsp1_drv.c
@@ -168,10 +168,13 @@ static int vsp1_uapi_create_links(struct vsp1_device 
*vsp1)
return ret;
}
 
-   if (vsp1->lif) {
-   ret = media_create_pad_link(>wpf[0]->entity.subdev.entity,
+   for (i = 0; i < vsp1->info->lif_count; ++i) {
+   if (!vsp1->lif[i])
+   continue;
+
+   ret = media_create_pad_link(>wpf[i]->entity.subdev.entity,
RWPF_PAD_SOURCE,
-   >lif->entity.subdev.entity,
+   >lif[i]->entity.subdev.entity,
LIF_PAD_SINK, 0);
if (ret < 0)
return ret;
@@ -334,18 +337,23 @@ static int vsp1_create_entities(struct vsp1_device *vsp1)
}
 
/*
-* The LIF is only supported when used in conjunction with the DU, in
+* The LIFs are only supported when used in conjunction with the DU, in
 * which case the userspace API is disabled. If the userspace API is
-* enabled skip the LIF, even when present.
+* enabled skip the LIFs, even when present.
 */
-

[PATCH v2 07/14] v4l: vsp1: Add support for the BRS entity

[Laurent Pinchart]

The Blend/ROP Sub Unit (BRS) is a stripped-down version of the BRU found
in several VSP2 instances. Compared to a regular BRU, it supports two
inputs only, and thus has no ROP unit.

Add support for the BRS by modeling it as a new entity type, but reuse
the vsp1_bru object underneath. Chaining the BRU and BRS entities seems
to be supported by the hardware but isn't implemented yet as it isn't
the primary use case for the BRS.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1.h|  2 +
 drivers/media/platform/vsp1/vsp1_bru.c| 45 ++
 drivers/media/platform/vsp1/vsp1_bru.h|  4 +-
 drivers/media/platform/vsp1/vsp1_drv.c| 19 +-
 drivers/media/platform/vsp1/vsp1_entity.c | 13 ++-
 drivers/media/platform/vsp1/vsp1_entity.h |  1 +
 drivers/media/platform/vsp1/vsp1_pipe.c   |  7 ++--
 drivers/media/platform/vsp1/vsp1_regs.h   | 26 +
 drivers/media/platform/vsp1/vsp1_video.c  | 63 ---
 drivers/media/platform/vsp1/vsp1_wpf.c|  4 +-
 10 files changed, 130 insertions(+), 54 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1.h 
b/drivers/media/platform/vsp1/vsp1.h
index 847963b6e9eb..73858a0ed35c 100644
--- a/drivers/media/platform/vsp1/vsp1.h
+++ b/drivers/media/platform/vsp1/vsp1.h
@@ -54,6 +54,7 @@ struct vsp1_uds;
 #define VSP1_HAS_WPF_HFLIP (1 << 6)
 #define VSP1_HAS_HGO   (1 << 7)
 #define VSP1_HAS_HGT   (1 << 8)
+#define VSP1_HAS_BRS   (1 << 9)
 
 struct vsp1_device_info {
u32 version;
@@ -76,6 +77,7 @@ struct vsp1_device {
struct rcar_fcp_device *fcp;
struct device *bus_master;
 
+   struct vsp1_bru *brs;
struct vsp1_bru *bru;
struct vsp1_clu *clu;
struct vsp1_hgo *hgo;
diff --git a/drivers/media/platform/vsp1/vsp1_bru.c 
b/drivers/media/platform/vsp1/vsp1_bru.c
index 85362c5ef57a..e8fd2ae3b3eb 100644
--- a/drivers/media/platform/vsp1/vsp1_bru.c
+++ b/drivers/media/platform/vsp1/vsp1_bru.c
@@ -33,7 +33,7 @@
 static inline void vsp1_bru_write(struct vsp1_bru *bru, struct vsp1_dl_list 
*dl,
  u32 reg, u32 data)
 {
-   vsp1_dl_list_write(dl, reg, data);
+   vsp1_dl_list_write(dl, bru->base + reg, data);
 }
 
 /* 
-
@@ -332,11 +332,14 @@ static void bru_configure(struct vsp1_entity *entity,
/*
 * Route BRU input 1 as SRC input to the ROP unit and configure the ROP
 * unit with a NOP operation to make BRU input 1 available as the
-* Blend/ROP unit B SRC input.
+* Blend/ROP unit B SRC input. Only needed for BRU, the BRS has no ROP
+* unit.
 */
-   vsp1_bru_write(bru, dl, VI6_BRU_ROP, VI6_BRU_ROP_DSTSEL_BRUIN(1) |
-  VI6_BRU_ROP_CROP(VI6_ROP_NOP) |
-  VI6_BRU_ROP_AROP(VI6_ROP_NOP));
+   if (entity->type == VSP1_ENTITY_BRU)
+   vsp1_bru_write(bru, dl, VI6_BRU_ROP,
+  VI6_BRU_ROP_DSTSEL_BRUIN(1) |
+  VI6_BRU_ROP_CROP(VI6_ROP_NOP) |
+  VI6_BRU_ROP_AROP(VI6_ROP_NOP));
 
for (i = 0; i < bru->entity.source_pad; ++i) {
bool premultiplied = false;
@@ -366,12 +369,13 @@ static void bru_configure(struct vsp1_entity *entity,
ctrl |= VI6_BRU_CTRL_DSTSEL_VRPF;
 
/*
-* Route BRU inputs 0 to 3 as SRC inputs to Blend/ROP units A to
-* D in that order. The Blend/ROP unit B SRC is hardwired to the
-* ROP unit output, the corresponding register bits must be set
-* to 0.
+* Route inputs 0 to 3 as SRC inputs to Blend/ROP units A to D
+* in that order. In the BRU the Blend/ROP unit B SRC is
+* hardwired to the ROP unit output, the corresponding register
+* bits must be set to 0. The BRS has no ROP unit and doesn't
+* need any special processing.
 */
-   if (i != 1)
+   if (!(entity->type == VSP1_ENTITY_BRU && i == 1))
ctrl |= VI6_BRU_CTRL_SRCSEL_BRUIN(i);
 
vsp1_bru_write(bru, dl, VI6_BRU_CTRL(i), ctrl);
@@ -407,20 +411,31 @@ static const struct vsp1_entity_operations bru_entity_ops 
= {
  * Initialization and Cleanup
  */
 
-struct vsp1_bru *vsp1_bru_create(struct vsp1_device *vsp1)
+struct vsp1_bru *vsp1_bru_create(struct vsp1_device *vsp1,
+enum vsp1_entity_type type)
 {
struct vsp1_bru *bru;
+   unsigned int num_pads;
+   const char *name;
int ret;
 
bru = devm_kzalloc(vsp1->dev, sizeof(*bru), GFP_KERNEL);
if (bru == NULL)
return ERR_PTR(-ENOMEM);
 
+   bru->base = type == VSP1_ENTITY_BRU ? VI6_BRU_BASE : 

[PATCH v2 04/14] v4l: vsp1: Store source and sink pointers as vsp1_entity

[Laurent Pinchart]

The internal VSP entity source and sink pointers are stored as
media_entity pointers, which are then cast to a vsp1_entity. As all
sources and sinks are vsp1_entity instances, we can store the
vsp1_entity pointers directly.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_drm.c|  4 ++--
 drivers/media/platform/vsp1/vsp1_drv.c|  2 +-
 drivers/media/platform/vsp1/vsp1_entity.c | 26 +-
 drivers/media/platform/vsp1/vsp1_entity.h |  4 ++--
 4 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index bc3fd9bc7126..2d5a74e95e09 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -587,7 +587,7 @@ int vsp1_drm_create_links(struct vsp1_device *vsp1)
if (ret < 0)
return ret;
 
-   rpf->entity.sink = >bru->entity.subdev.entity;
+   rpf->entity.sink = >bru->entity;
rpf->entity.sink_pad = i;
}
 
@@ -598,7 +598,7 @@ int vsp1_drm_create_links(struct vsp1_device *vsp1)
if (ret < 0)
return ret;
 
-   vsp1->bru->entity.sink = >wpf[0]->entity.subdev.entity;
+   vsp1->bru->entity.sink = >wpf[0]->entity;
vsp1->bru->entity.sink_pad = RWPF_PAD_SINK;
 
ret = media_create_pad_link(>wpf[0]->entity.subdev.entity,
diff --git a/drivers/media/platform/vsp1/vsp1_drv.c 
b/drivers/media/platform/vsp1/vsp1_drv.c
index 35087d5573ce..9b3a0790f92a 100644
--- a/drivers/media/platform/vsp1/vsp1_drv.c
+++ b/drivers/media/platform/vsp1/vsp1_drv.c
@@ -121,7 +121,7 @@ static int vsp1_create_sink_links(struct vsp1_device *vsp1,
return ret;
 
if (flags & MEDIA_LNK_FL_ENABLED)
-   source->sink = entity;
+   source->sink = sink;
}
}
 
diff --git a/drivers/media/platform/vsp1/vsp1_entity.c 
b/drivers/media/platform/vsp1/vsp1_entity.c
index 4bdb3b141611..71dd903263ad 100644
--- a/drivers/media/platform/vsp1/vsp1_entity.c
+++ b/drivers/media/platform/vsp1/vsp1_entity.c
@@ -24,18 +24,11 @@
 #include "vsp1_pipe.h"
 #include "vsp1_rwpf.h"
 
-static inline struct vsp1_entity *
-media_entity_to_vsp1_entity(struct media_entity *entity)
-{
-   return container_of(entity, struct vsp1_entity, subdev.entity);
-}
-
 void vsp1_entity_route_setup(struct vsp1_entity *entity,
 struct vsp1_pipeline *pipe,
 struct vsp1_dl_list *dl)
 {
struct vsp1_entity *source;
-   struct vsp1_entity *sink;
 
if (entity->type == VSP1_ENTITY_HGO) {
u32 smppt;
@@ -44,7 +37,7 @@ void vsp1_entity_route_setup(struct vsp1_entity *entity,
 * The HGO is a special case, its routing is configured on the
 * sink pad.
 */
-   source = media_entity_to_vsp1_entity(entity->sources[0]);
+   source = entity->sources[0];
smppt = (pipe->output->entity.index << VI6_DPR_SMPPT_TGW_SHIFT)
  | (source->route->output << VI6_DPR_SMPPT_PT_SHIFT);
 
@@ -57,7 +50,7 @@ void vsp1_entity_route_setup(struct vsp1_entity *entity,
 * The HGT is a special case, its routing is configured on the
 * sink pad.
 */
-   source = media_entity_to_vsp1_entity(entity->sources[0]);
+   source = entity->sources[0];
smppt = (pipe->output->entity.index << VI6_DPR_SMPPT_TGW_SHIFT)
  | (source->route->output << VI6_DPR_SMPPT_PT_SHIFT);
 
@@ -69,9 +62,8 @@ void vsp1_entity_route_setup(struct vsp1_entity *entity,
if (source->route->reg == 0)
return;
 
-   sink = media_entity_to_vsp1_entity(source->sink);
vsp1_dl_list_write(dl, source->route->reg,
-  sink->route->inputs[source->sink_pad]);
+  source->sink->route->inputs[source->sink_pad]);
 }
 
 /* 
-
@@ -316,6 +308,12 @@ int vsp1_subdev_enum_frame_size(struct v4l2_subdev *subdev,
  * Media Operations
  */
 
+static inline struct vsp1_entity *
+media_entity_to_vsp1_entity(struct media_entity *entity)
+{
+   return container_of(entity, struct vsp1_entity, subdev.entity);
+}
+
 static int vsp1_entity_link_setup_source(const struct media_pad *source_pad,
 const struct media_pad *sink_pad,
 u32 flags)
@@ -339,7 +337,7 @@ static int vsp1_entity_link_setup_source(const struct 
media_pad *source_pad,
sink->type != VSP1_ENTITY_HGT) {
if (source->sink)
return -EBUSY;
-  

[PATCH v2 02/14] v4l: vsp1: Don't recycle active list at display start

[Laurent Pinchart]

When the display start interrupt occurs, we know that the hardware has
finished loading the active display list. The driver then proceeds to
recycle the list, assuming it won't be needed anymore.

This assumption holds true for headerless display lists, as the VSP
doesn't reload the list for the next frame if it hasn't changed.
However, this isn't true anymore for header display lists, as they are
loaded at every frame start regardless of whether they have been
updated.

To prepare for header display lists usage in display pipelines, we need
to postpone recycling the list until it gets replaced by a new one
through a page flip. The driver already does so in the frame end
interrupt handler, so all we need is to skip list recycling in the
display start interrupt handler.

While the active list can be recycled at display start for headerless
display lists, there's no real harm in postponing that to the frame end
interrupt handler in all cases. This simplifies interrupt handling as we
don't need to process the display start interrupt anymore.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_dl.c  | 16 
 drivers/media/platform/vsp1/vsp1_dl.h  |  1 -
 drivers/media/platform/vsp1/vsp1_drm.c | 12 
 drivers/media/platform/vsp1/vsp1_drm.h |  2 --
 drivers/media/platform/vsp1/vsp1_drv.c |  8 
 5 files changed, 4 insertions(+), 35 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_dl.c 
b/drivers/media/platform/vsp1/vsp1_dl.c
index dc47e236c780..bb92be4fe0f0 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -547,22 +547,6 @@ void vsp1_dl_list_commit(struct vsp1_dl_list *dl)
  * Display List Manager
  */
 
-/* Interrupt Handling */
-void vsp1_dlm_irq_display_start(struct vsp1_dl_manager *dlm)
-{
-   spin_lock(>lock);
-
-   /*
-* The display start interrupt signals the end of the display list
-* processing by the device. The active display list, if any, won't be
-* accessed anymore and can be reused.
-*/
-   __vsp1_dl_list_put(dlm->active);
-   dlm->active = NULL;
-
-   spin_unlock(>lock);
-}
-
 /**
  * vsp1_dlm_irq_frame_end - Display list handler for the frame end interrupt
  * @dlm: the display list manager
diff --git a/drivers/media/platform/vsp1/vsp1_dl.h 
b/drivers/media/platform/vsp1/vsp1_dl.h
index 6ec1380a10af..ee3508172f0a 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.h
+++ b/drivers/media/platform/vsp1/vsp1_dl.h
@@ -27,7 +27,6 @@ struct vsp1_dl_manager *vsp1_dlm_create(struct vsp1_device 
*vsp1,
unsigned int prealloc);
 void vsp1_dlm_destroy(struct vsp1_dl_manager *dlm);
 void vsp1_dlm_reset(struct vsp1_dl_manager *dlm);
-void vsp1_dlm_irq_display_start(struct vsp1_dl_manager *dlm);
 bool vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm);
 
 struct vsp1_dl_list *vsp1_dl_list_get(struct vsp1_dl_manager *dlm);
diff --git a/drivers/media/platform/vsp1/vsp1_drm.c 
b/drivers/media/platform/vsp1/vsp1_drm.c
index 9377aafa8996..bc3fd9bc7126 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -32,11 +32,6 @@
  * Interrupt Handling
  */
 
-void vsp1_drm_display_start(struct vsp1_device *vsp1)
-{
-   vsp1_dlm_irq_display_start(vsp1->drm->pipe.output->dlm);
-}
-
 static void vsp1_du_pipeline_frame_end(struct vsp1_pipeline *pipe)
 {
struct vsp1_drm *drm = to_vsp1_drm(pipe);
@@ -224,6 +219,10 @@ int vsp1_du_setup_lif(struct device *dev, const struct 
vsp1_du_lif_config *cfg)
return ret;
}
 
+   /* Disable the display interrupts. */
+   vsp1_write(vsp1, VI6_DISP_IRQ_STA, 0);
+   vsp1_write(vsp1, VI6_DISP_IRQ_ENB, 0);
+
dev_dbg(vsp1->dev, "%s: pipeline enabled\n", __func__);
 
return 0;
@@ -529,13 +528,10 @@ void vsp1_du_atomic_flush(struct device *dev)
 
/* Start or stop the pipeline if needed. */
if (!vsp1->drm->num_inputs && pipe->num_inputs) {
-   vsp1_write(vsp1, VI6_DISP_IRQ_STA, 0);
-   vsp1_write(vsp1, VI6_DISP_IRQ_ENB, VI6_DISP_IRQ_ENB_DSTE);
spin_lock_irqsave(>irqlock, flags);
vsp1_pipeline_run(pipe);
spin_unlock_irqrestore(>irqlock, flags);
} else if (vsp1->drm->num_inputs && !pipe->num_inputs) {
-   vsp1_write(vsp1, VI6_DISP_IRQ_ENB, 0);
vsp1_pipeline_stop(pipe);
}
 }
diff --git a/drivers/media/platform/vsp1/vsp1_drm.h 
b/drivers/media/platform/vsp1/vsp1_drm.h
index e9f80727ff92..cbdbb8a39883 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.h
+++ b/drivers/media/platform/vsp1/vsp1_drm.h
@@ -50,6 +50,4 @@ int vsp1_drm_init(struct vsp1_device *vsp1);
 void vsp1_drm_cleanup(struct vsp1_device *vsp1);
 int vsp1_drm_create_links(struct vsp1_device *vsp1);
 
-void vsp1_drm_display_start(struct vsp1_device *vsp1);
-
 #endif /* 

[PATCH v2 00/14] Renesas R-Car VSP: Add H3 ES2.0 support

[Laurent Pinchart]

Hello,

This patch series implements support for the R-Car H3 ES2.0 SoC in the VSP
and DU drivers.
 
Compared to the H3 ES1.1, the H3 ES2.0 has a new VSP2-DL instance that
includes two blending units, a BRU and a BRS. The BRS is similar to the BRU
but has two inputs only, and is used to service a second DU channel from the
same VSP through a second LIF instances connected to WPF.1.

The patch series starts with a small fixes and cleanups in patches 01/14 to
05/14. Patch 06/14 prepares the VSP driver for multiple DU channels support by
extending the DU-VSP API with an additional argument. Patches 07/14 to 10/14
gradually build H3 ES2.0 support on top of that by implementing all needed
features in the VSP driver.

So far the VSP driver always used headerless display lists when operating in
connection with the DU. This mode of operation is only available on WPF.0, so
support for regular display lists with headers when operating with the DU is
added in patch 11/14.

The remaining patches finally implement H3 ES2.0 support in the DU driver,
with support for VSP sharing implemented in patch 12/14, for H3 ES2.0 PLL in
patch 13/14 (by restricting the ES1.x workaround to ES1.x SoCs) and for RGB
output routing in patch 14/14.

Compared to v1, the series has gone under considerable changes. Testing
locally on H3 ES2.0 uncovered multiple issues in the previous partially tested
version, which have been fixed in additional patches. The following changes
can be noted in particular.

- New small cleanups in patches 02/14 to 05/14
- Pass the pipe index to vsp1_du_atomic_update() explicitly
- Rebase on top of the VSP-DU flicker fixes, resulting in a major rework of
  "v4l: vsp1: Add support for header display lists in continuous mode"
- New patches 09/14, 10/14 and 12/14 to support the previously untested VGA
  output

The series is based on top of Dave's latest drm-next branch as it depends on
patches merged by Dave for v4.13. It depends, for testing, on

- the sh-pfc-for-v4.13 branch from Geert's renesas-drivers tree
- the "[PATCH v2 0/2] R-Car H3 ES2.0 Salvator-X: Enable DU support in DT"
  patch series

For convenience, a branch merging this series with all dependencies is
available from

git://linuxtv.org/pinchartl/media.git drm/next/h3-es2/merged

with the DT and driver series split in two branches respectively tagged
drm-h3-es2-dt-20170626 and drm-h3-es2-vsp-du-20170626.

The patches have been tested on the Lager, Salvator-X H3 ES1.x, Salvator-X
M3-W and Salvator-XS boards. All outputs have been tested using modetest
without any noticeable regression.

Laurent Pinchart (14):
  v4l: vsp1: Fill display list headers without holding dlm spinlock
  v4l: vsp1: Don't recycle active list at display start
  v4l: vsp1: Don't set WPF sink pointer
  v4l: vsp1: Store source and sink pointers as vsp1_entity
  v4l: vsp1: Don't create links for DRM pipeline
  v4l: vsp1: Add pipe index argument to the VSP-DU API
  v4l: vsp1: Add support for the BRS entity
  v4l: vsp1: Add support for new VSP2-BS, VSP2-DL and VSP2-D instances
  v4l: vsp1: Add support for multiple LIF instances
  v4l: vsp1: Add support for multiple DRM pipelines
  v4l: vsp1: Add support for header display lists in continuous mode
  drm: rcar-du: Support multiple sources from the same VSP
  drm: rcar-du: Restrict DPLL duty cycle workaround to H3 ES1.x
  drm: rcar-du: Configure DPAD0 routing through last group on Gen3

 drivers/gpu/drm/rcar-du/rcar_du_crtc.c|  39 ++--
 drivers/gpu/drm/rcar-du/rcar_du_crtc.h|   3 +
 drivers/gpu/drm/rcar-du/rcar_du_group.c   |  21 ++-
 drivers/gpu/drm/rcar-du/rcar_du_kms.c |  91 --
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c |  37 ++--
 drivers/gpu/drm/rcar-du/rcar_du_vsp.h |  10 +-
 drivers/media/platform/vsp1/vsp1.h|   7 +-
 drivers/media/platform/vsp1/vsp1_bru.c|  45 +++--
 drivers/media/platform/vsp1/vsp1_bru.h|   4 +-
 drivers/media/platform/vsp1/vsp1_dl.c | 205 +-
 drivers/media/platform/vsp1/vsp1_dl.h |   1 -
 drivers/media/platform/vsp1/vsp1_drm.c| 283 +++---
 drivers/media/platform/vsp1/vsp1_drm.h|  38 ++--
 drivers/media/platform/vsp1/vsp1_drv.c| 115 
 drivers/media/platform/vsp1/vsp1_entity.c |  40 +++--
 drivers/media/platform/vsp1/vsp1_entity.h |   5 +-
 drivers/media/platform/vsp1/vsp1_lif.c|   5 +-
 drivers/media/platform/vsp1/vsp1_lif.h|   2 +-
 drivers/media/platform/vsp1/vsp1_pipe.c   |   7 +-
 drivers/media/platform/vsp1/vsp1_regs.h   |  46 +++--
 drivers/media/platform/vsp1/vsp1_video.c  |  63 ---
 drivers/media/platform/vsp1/vsp1_wpf.c|   4 +-
 include/media/vsp1.h  |  10 +-
 23 files changed, 676 insertions(+), 405 deletions(-)

-- 
Regards,

Laurent Pinchart

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

[PATCH v2 01/14] v4l: vsp1: Fill display list headers without holding dlm spinlock

[Laurent Pinchart]

The display list headers are filled using information from the display
list only. Lower the display list manager spinlock contention by filling
the headers without holding the lock.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_dl.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_dl.c 
b/drivers/media/platform/vsp1/vsp1_dl.c
index aaf17b13fd78..dc47e236c780 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -483,8 +483,6 @@ void vsp1_dl_list_commit(struct vsp1_dl_list *dl)
unsigned long flags;
bool update;
 
-   spin_lock_irqsave(>lock, flags);
-
if (dl->dlm->mode == VSP1_DL_MODE_HEADER) {
struct vsp1_dl_list *dl_child;
 
@@ -501,7 +499,11 @@ void vsp1_dl_list_commit(struct vsp1_dl_list *dl)
 
vsp1_dl_list_fill_header(dl_child, last);
}
+   }
 
+   spin_lock_irqsave(>lock, flags);
+
+   if (dl->dlm->mode == VSP1_DL_MODE_HEADER) {
/*
 * Commit the head display list to hardware. Chained headers
 * will auto-start.
-- 
Regards,

Laurent Pinchart

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

[Bug 100393] Cemu wiiu emulator crashes after selecting game on radeonsi

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100393

--- Comment #10 from Giovanni ongaro  ---
Mika your last patch works even for cemu 1.8.0 i have only one question when is
the VENDOR override worth and what are you forcing as vendor and render?

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

Re: [PATCH v4 2/6] dt-bindings: display: Add Synopsys DW MIPI DSI DRM bridge driver

[Philippe CORNU]

On 06/23/2017 11:25 PM, Rob Herring wrote:
> On Mon, Jun 19, 2017 at 06:28:01PM +0200, Philippe CORNU wrote:
>> This patch adds documentation of device tree bindings for the
>> Synopsys DesignWare MIPI DSI host DRM bridge driver.
> 
> You missed Archit's comment on v3. Bindings are for h/w, not drivers.
> 
> Rob
> 
Dear Rob :-)
sorry to have miss that ones.
I have updated all bindings accordingly (including the optional dpi/rgb 
pixel clock). Everything is now ready for the coming v5 patchset (I am 
waiting for more comments before sending it).
Big thanks :-)
Philippe
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: adv7511_audio: Add .get_dai_id callback to map port number to dai id

[John Stultz]

On Tue, Jun 13, 2017 at 5:05 PM, Mark Brown  wrote:
> On Tue, Jun 13, 2017 at 02:59:49PM -0700, John Stultz wrote:
>> ALSA SoC needs to know connected DAI ID for probing. Using
>> the new audio-card-graph approach, ports/endpoints are used
>> to describe how the links are connected. Unfortunately, since
>
> Unless someone objects in the next week or so I intend to apply this.


Hey Mark,
  Just wanted to check on this to make sure it didn't slip by. I've
not seen it show up in -next yet.

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

Re: [PATCH v3] staging: vboxvideo: Add vboxvideo to drivers/staging

[Hans de Goede]

Hi,

On 26-06-17 18:24, Daniel Vetter wrote:

On Mon, Jun 26, 2017 at 06:06:19PM +0200, Hans de Goede wrote:

Hi,

On 23-06-17 11:31, Daniel Vetter wrote:

On Thu, Jun 22, 2017 at 11:11:37AM +0200, Hans de Goede wrote:

This commit adds the vboxvideo drm/kms driver for the virtual graphics
card used in Virtual Box virtual machines to drivers/staging.

Why drivers/staging? This driver is already being patched into the kernel
by several distros, thus it is good to get this driver upstream soon, so
that work on the driver can be easily shared.

At the same time we want to take our time to get this driver properly
cleaned up (mainly converted to the new atomic modesetting APIs) before
submitting it as a normal driver under drivers/gpu/drm, putting this
driver in staging for now allows both.

Note this driver has already been significantly cleaned up, when I started
working on this the files under /usr/src/vboxguest/vboxvideo as installed
by Virtual Box 5.1.18 Guest Additions had a total linecount of 52681
lines. The version in this commit has 4874 lines.

Cc: vbox-...@virtualbox.org
Cc: Michael Thayer 
Signed-off-by: Hans de Goede 
Signed-off-by: Michael Thayer 
---
Changes in v2:
-Add Michael's S-o-b
-Improve Kconfig help text
-Remove .config changes which accidentally got added to the commit

Changes in v3:
-Convert the files shared with the video-driver for other operating-systems
   to kernel coding style too
-Remove unused code from these files


In the end it's up to you, but our experience in drm with -staging has
been that's both a pain (separate tree, which makes coordination harder
for drm drivers) and a ghetto (no one from drm will look at your patches).

Especially for small drivers (and this is one, and I expect if you use all
the latest and greates helpers atomic will provide it'll shrink
considerably) it's just not worth the pain to polish stuff twice.

0toh I see the benefit of putting stuff into staging so in the end it's up
to you, just beware pls.


Thanks for the heads up Daniel, for now I would like to move forward with
getting this in staging, but I do agree that it would be good to get it
into drivers/gpu soon. Michael do you think you will have some time soon
to look at moving this to the atomic helpers ?


To make it clear what I think is the minimal path towards drivers/gpu:
- switch to atomic helpers (well probably simple_display_pipe if it fits)
- delete half the driver code by dropping optional hooks and using helpers
- make sure you don't use any callback/functions where the kerneldoc says
   it's deprecated (e.g. load/unload)
- merge


Thank you for this list, that is very helpful.


We can do the checkpatch/style bikeshedding once merged into drivers/gpu/
imo, that's real good fodder for newbies anyway :-)


Actually for v3 I've already converted everything to kernel coding style,
so that is already done :)

Regards,

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

[PATCH 2/2] drm/vblank: Unexport drm_vblank_cleanup

[Daniel Vetter]

There's no reason for drivers to call this, and all the ones I've
removed looked very fishy:
- Proper quiescenting of the vblank machinery should be done by
  calling drm_crtc_vblank_off(), which is best done by shutting down
  the entire display engine with drm_atomic_helper_shutdown.

- Releasing of allocated memory is done by the core already, it calls
  drm_vblank_cleanup as a fallback.

- drm_vblank_cleanup also has checks for drivers which forget to clean
  up vblank interrupts.

This essentially reverts

commit e77cef9c2d87db835ad9d70cde4a9b00b0ca2262
Author: Jerome Glisse 
Date:   Thu Jan 7 15:39:13 2010 +0100

drm: Avoid calling vblank function is vblank wasn't initialized

which was done to fix a bug in radeon code with msi interrupts:

commit 003e69f9862bcda89a75c27750efdbc17ac02945
Author: Jerome Glisse 
Date:   Thu Jan 7 15:39:14 2010 +0100

drm/radeon/kms: Don't try to enable IRQ if we have no handler installed

Afaict from digging around in old code, this was needed to avoid
blowing up in the ums fallback, and has stopped serving it's purpose
long ago - if irq init fails, the driver fails to load, and there's
really no way to blow up anymore.

Long story short, this was most likely a small ums compat/fallback
hack that became a thing of it's own and got cargo-cult duplicated all
over the drm codebase for essentially no gain at all.

v2: Mention that for drivers with a ->release callback cleanup is
handled by drm_dev_fini() (Thierry).

Cc: Thierry Reding 
Acked-by: Thierry Reding 
Cc: Jerome Glisse 
Reviewed-by: Sean Paul 
Acked-by: Alex Deucher 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_internal.h |  1 +
 drivers/gpu/drm/drm_vblank.c   | 19 ++-
 include/drm/drm_vblank.h   |  1 -
 3 files changed, 3 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index f89371e920e6..068b685608cf 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -57,6 +57,7 @@ int drm_gem_name_info(struct seq_file *m, void *data);
 /* drm_vblank.c */
 extern unsigned int drm_timestamp_monotonic;
 void drm_vblank_disable_and_save(struct drm_device *dev, unsigned int pipe);
+void drm_vblank_cleanup(struct drm_device *dev);
 
 /* IOCTLS */
 int drm_wait_vblank_ioctl(struct drm_device *dev, void *data,
diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 7e3f59182571..05d043e9219f 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -394,19 +394,6 @@ static void vblank_disable_fn(unsigned long arg)
spin_unlock_irqrestore(>vbl_lock, irqflags);
 }
 
-/**
- * drm_vblank_cleanup - cleanup vblank support
- * @dev: DRM device
- *
- * This function cleans up any resources allocated in drm_vblank_init(). It is
- * called by the DRM core when @dev is finalized.
- *
- * Drivers can call drm_vblank_cleanup() if they need to quiescent the vblank
- * interrupt in their unload code. But in general this should be handled by
- * disabling all active _crtc through e.g. drm_atomic_helper_shutdown, 
which
- * should end up calling drm_crtc_vblank_off().
- *
- */
 void drm_vblank_cleanup(struct drm_device *dev)
 {
unsigned int pipe;
@@ -428,7 +415,6 @@ void drm_vblank_cleanup(struct drm_device *dev)
 
dev->num_crtcs = 0;
 }
-EXPORT_SYMBOL(drm_vblank_cleanup);
 
 /**
  * drm_vblank_init - initialize vblank support
@@ -436,9 +422,8 @@ EXPORT_SYMBOL(drm_vblank_cleanup);
  * @num_crtcs: number of CRTCs supported by @dev
  *
  * This function initializes vblank support for @num_crtcs display pipelines.
- * Drivers do not need to call drm_vblank_cleanup(), cleanup is already handled
- * by the DRM core, or through calling drm_dev_fini() for drivers with a
- * _driver.release callback.
+ * Cleanup is handled by the DRM core, or through calling drm_dev_fini() for
+ * drivers with a _driver.release callback.
  *
  * Returns:
  * Zero on success or a negative error code on failure.
diff --git a/include/drm/drm_vblank.h b/include/drm/drm_vblank.h
index 4ceef128582f..7fba9efe4951 100644
--- a/include/drm/drm_vblank.h
+++ b/include/drm/drm_vblank.h
@@ -168,7 +168,6 @@ void drm_crtc_wait_one_vblank(struct drm_crtc *crtc);
 void drm_crtc_vblank_off(struct drm_crtc *crtc);
 void drm_crtc_vblank_reset(struct drm_crtc *crtc);
 void drm_crtc_vblank_on(struct drm_crtc *crtc);
-void drm_vblank_cleanup(struct drm_device *dev);
 u32 drm_crtc_accurate_vblank_count(struct drm_crtc *crtc);
 
 bool drm_calc_vbltimestamp_from_scanoutpos(struct drm_device *dev,
-- 
2.11.0

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

[PATCH 1/2] drm/vmwgfx: Drop drm_vblank_cleanup

[Daniel Vetter]

Again stopping the vblank before uninstalling the irq handler is kinda
the wrong way round, but the fb_off stuff should take care of
disabling the dsiplay at least in most cases. So drop the
drm_vblank_cleanup code since it's not really doing anything, it looks
all cargo-culted.

v2: Appease gcc better.

v3: Simplify code (Sean Paul)

Cc: Sinclair Yeh 
Cc: Thomas Hellstrom 
Reviewed-by: Sean Paul 
Reviewed-by: Thomas Hellstrom 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c  |  8 ++--
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.h  |  2 --
 drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c  |  4 
 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c |  9 -
 drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 27 +--
 5 files changed, 3 insertions(+), 47 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 3d94ea67a825..1cd67b10a0d9 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -1658,7 +1658,7 @@ int vmw_kms_init(struct vmw_private *dev_priv)
 
 int vmw_kms_close(struct vmw_private *dev_priv)
 {
-   int ret;
+   int ret = 0;
 
/*
 * Docs says we should take the lock before calling this function
@@ -1666,11 +1666,7 @@ int vmw_kms_close(struct vmw_private *dev_priv)
 * drm_encoder_cleanup which takes the lock we deadlock.
 */
drm_mode_config_cleanup(dev_priv->dev);
-   if (dev_priv->active_display_unit == vmw_du_screen_object)
-   ret = vmw_kms_sou_close_display(dev_priv);
-   else if (dev_priv->active_display_unit == vmw_du_screen_target)
-   ret = vmw_kms_stdu_close_display(dev_priv);
-   else
+   if (dev_priv->active_display_unit == vmw_du_legacy)
ret = vmw_kms_ldu_close_display(dev_priv);
 
return ret;
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
index 5f8d678ae675..ff9c8389ff21 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
@@ -390,7 +390,6 @@ int vmw_kms_update_proxy(struct vmw_resource *res,
  * Screen Objects display functions - vmwgfx_scrn.c
  */
 int vmw_kms_sou_init_display(struct vmw_private *dev_priv);
-int vmw_kms_sou_close_display(struct vmw_private *dev_priv);
 int vmw_kms_sou_do_surface_dirty(struct vmw_private *dev_priv,
 struct vmw_framebuffer *framebuffer,
 struct drm_clip_rect *clips,
@@ -418,7 +417,6 @@ int vmw_kms_sou_readback(struct vmw_private *dev_priv,
  * Screen Target Display Unit functions - vmwgfx_stdu.c
  */
 int vmw_kms_stdu_init_display(struct vmw_private *dev_priv);
-int vmw_kms_stdu_close_display(struct vmw_private *dev_priv);
 int vmw_kms_stdu_surface_dirty(struct vmw_private *dev_priv,
   struct vmw_framebuffer *framebuffer,
   struct drm_clip_rect *clips,
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
index d3987bcf53f8..449ed4fba0f2 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
@@ -582,13 +582,9 @@ int vmw_kms_ldu_init_display(struct vmw_private *dev_priv)
 
 int vmw_kms_ldu_close_display(struct vmw_private *dev_priv)
 {
-   struct drm_device *dev = dev_priv->dev;
-
if (!dev_priv->ldu_priv)
return -ENOSYS;
 
-   drm_vblank_cleanup(dev);
-
BUG_ON(!list_empty(_priv->ldu_priv->active));
 
kfree(dev_priv->ldu_priv);
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
index 8d7dc9def7c2..3b917c9b0c21 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
@@ -746,15 +746,6 @@ int vmw_kms_sou_init_display(struct vmw_private *dev_priv)
return 0;
 }
 
-int vmw_kms_sou_close_display(struct vmw_private *dev_priv)
-{
-   struct drm_device *dev = dev_priv->dev;
-
-   drm_vblank_cleanup(dev);
-
-   return 0;
-}
-
 static int do_dmabuf_define_gmrfb(struct vmw_private *dev_priv,
  struct vmw_framebuffer *framebuffer)
 {
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
index 50be1f034f9e..6aecba6cd5e2 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
@@ -1651,36 +1651,11 @@ int vmw_kms_stdu_init_display(struct vmw_private 
*dev_priv)
 
if (unlikely(ret != 0)) {
DRM_ERROR("Failed to initialize STDU %d", i);
-   goto err_vblank_cleanup;
+   return ret;
}
}
 
DRM_INFO("Screen Target Display device initialized\n");
 
return 0;
-
-err_vblank_cleanup:
-   drm_vblank_cleanup(dev);
-   return 

Re: [PATCH v2 1/7] dt-bindings: display: renesas: Add R-Car M3-W HDMI TX DT bindings

[Rob Herring]

On Wed, Jun 21, 2017 at 12:31:27PM +0300, Laurent Pinchart wrote:
> The M3-W HDMI TX controller seems to be compatible for the H3. No
> extension to the DT bindings are needed, add an SoC-specific compatible
> string in case differences between the IP versions are found later and
> require model-specific handling.
> 
> Signed-off-by: Laurent Pinchart 
> ---
>  Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt | 1 +
>  1 file changed, 1 insertion(+)

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

Re: [PATCH v3] staging: vboxvideo: Add vboxvideo to drivers/staging

[Hans de Goede]

Hi,

On 22-06-17 14:03, Dan Carpenter wrote:
> This is obviously much better and easier to review.  I ended up
> reviewing it like I would normal code instead of staging code.  My main
> thing is could you please re-write the module init error handling so
> that each function does its own error handling instead of just calling
> vbox_driver_unload().  Doing it that way is always going to buggy and
> impossible to review.

Thanks for the review I'm preparing a v4 addressing all your comments,
one small remark and one question about your remarks:



>> +int vbox_irq_init(struct vbox_private *vbox)
>> +{
>> +  int ret;
>> +
>> +  vbox_update_mode_hints(vbox);
>> +  ret = drm_irq_install(vbox->dev, vbox->dev->pdev->irq);
>> +  if (unlikely(ret != 0)) {
>
>
> This is a slow path so don't use likely/unlikely.  Just say:
>
>if (ret)
>
>> +  vbox_irq_fini(vbox);
>
> No need.  Btw, the error handling in this driver is very frustrating for
> me.  There is a massive do-everything cleanup function we call if init
> fails or we need to unload the module.  But here we are doing our own
> cleanup so vbox_irq_fini() is called twice.  And, of course, if the
> resource isn't needed for the entire lifetime of the module then we have
> to do normal kernel style error handling.  And then there is
> vbox_mode_fini() which is not implemented.  The not implemented function
> is not a coincidence, I see that a lot when people start down the path
> of writing do-everything-style error handling.
>
> My suggestion is to use normal kernel style error handling everywhere
> because it's simpler in the end.  Every function cleans up after itself
> so you never return half the allocations you wanted.  Choose the label
> name to reflect what you are doing at the label.  You only need to
> remember the most recent allocation instead of remembering every single
> thing you allocated.
>
>one = alloc();
>if (!one)
>return -ENOMEM;
>
>two = alloc();
>if (!two) {
>rc = -ENOMEM;
>goto free_one;
>}
>
>three = alloc();
>if (!three) {
>rc = -ENOMEM;
>goto free_two;
>}
>
> It's really simple if you plod along one thing at time.

Ack, I had already converted some functions to this style,
also to avoid nested success checks leading to an indentation
ever further to the right. I will move more code over to
this style for v4.

>> +  DRM_ERROR("Failed installing irq: %d\n", ret);
>> +  return 1;
>
> Preserve the error code.  "return ret;"
>
>
>> +  }
>> +  INIT_WORK(>hotplug_work, vbox_hotplug_worker);
>> +  vbox->isr_installed = true;
>
> The isr_installed variable is not needed.
>
>> +  return 0;
>> +}
>> +
>> +void vbox_irq_fini(struct vbox_private *vbox)
>> +{
>> +  if (vbox->isr_installed) {
>> +  drm_irq_uninstall(vbox->dev);
>> +  flush_work(>hotplug_work);
>
> These should be freed in the reverse order from how they were allocated
> so I don't have to audit for use after frees or whatever.

You're right in principle, but your example is wrong:

> void vbox_irq_fini(struct vbox_private *vbox)
> {
>flush_work(>hotplug_work);
>drm_irq_uninstall(vbox->dev);
> }

The irq can schedule the work, so we need to uninstall it
and then wait for any pending work to finish, so the original
fini order is right, the init order is wrong however. So I've
fixed the init order to be the reverse of the fini code.



>> +int vbox_dumb_create(struct drm_file *file,
>> +   struct drm_device *dev, struct drm_mode_create_dumb 
*args)
>> +{
>> +  int ret;
>> +  struct drm_gem_object *gobj;
>> +  u32 handle;
>> +
>> +  args->pitch = args->width * ((args->bpp + 7) / 8);
>> +  args->size = args->pitch * args->height;
>> +
>> +  ret = vbox_gem_create(dev, args->size, false, );
>> +  if (ret)
>> +  return ret;
>> +
>> +  ret = drm_gem_handle_create(file, gobj, );
>> +  drm_gem_object_unreference_unlocked(gobj);
>> +  if (ret)
>> +  return ret;
>
> This is a resource leak.

What makes you say that? Note the unreference done before the
ret check. I could be missing something here, but I think this is fine ?

<2nd mega-snip>

Regards,

Hans

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

Re: [Intel-gfx] [PATCH v12 3/3] drm/i915: Add option to support dynamic backlight via DPCD

[David Weinehall]

On Thu, Jun 22, 2017 at 12:03:39PM -0700, Puthikorn Voravootivat wrote:
> This patch adds option to enable dynamic backlight for eDP
> panel that supports this feature via DPCD register and
> set minimum / maximum brightness to 0% and 100% of the
> normal brightness.

This patch causes a regression on my ThinkPad X1 Carbon Gen 4;
with enable_dbc = true the backlight stays off; setting i915.enable_dbc=0
on boot makes things work properly again.

> Signed-off-by: Puthikorn Voravootivat 
> Reviewed-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/i915/i915_params.c|  5 +
>  drivers/gpu/drm/i915/i915_params.h|  3 ++-
>  drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 26 ++
>  3 files changed, 33 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_params.c 
> b/drivers/gpu/drm/i915/i915_params.c
> index 5b5ab15d191f..88b9d3e6713a 100644
> --- a/drivers/gpu/drm/i915/i915_params.c
> +++ b/drivers/gpu/drm/i915/i915_params.c
> @@ -65,6 +65,7 @@ struct i915_params i915 __read_mostly = {
>   .inject_load_failure = 0,
>   .enable_dpcd_backlight = -1,
>   .enable_gvt = false,
> + .enable_dbc = true,
>  };
>  
>  module_param_named(modeset, i915.modeset, int, 0400);
> @@ -254,3 +255,7 @@ MODULE_PARM_DESC(enable_dpcd_backlight,
>  module_param_named(enable_gvt, i915.enable_gvt, bool, 0400);
>  MODULE_PARM_DESC(enable_gvt,
>   "Enable support for Intel GVT-g graphics virtualization host 
> support(default:false)");
> +
> +module_param_named_unsafe(enable_dbc, i915.enable_dbc, bool, 0600);
> +MODULE_PARM_DESC(enable_dbc,
> + "Enable support for dynamic backlight control (default:true)");
> diff --git a/drivers/gpu/drm/i915/i915_params.h 
> b/drivers/gpu/drm/i915/i915_params.h
> index 0d6cf9138dc4..057e203e6bda 100644
> --- a/drivers/gpu/drm/i915/i915_params.h
> +++ b/drivers/gpu/drm/i915/i915_params.h
> @@ -67,7 +67,8 @@
>   func(bool, verbose_state_checks); \
>   func(bool, nuclear_pageflip); \
>   func(bool, enable_dp_mst); \
> - func(bool, enable_gvt)
> + func(bool, enable_gvt); \
> + func(bool, enable_dbc)
>  
>  #define MEMBER(T, member) T member
>  struct i915_params {
> diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
> b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> index fea161727c6e..b25cd88fc1c5 100644
> --- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> @@ -173,6 +173,24 @@ static bool intel_dp_aux_set_pwm_freq(struct 
> intel_connector *connector)
>   return true;
>  }
>  
> +/*
> +* Set minimum / maximum dynamic brightness percentage. This value is 
> expressed
> +* as the percentage of normal brightness in 5% increments.
> +*/
> +static bool
> +intel_dp_aux_set_dynamic_backlight_percent(struct intel_dp *intel_dp,
> +u32 min, u32 max)
> +{
> + u8 dbc[] = { DIV_ROUND_CLOSEST(min, 5), DIV_ROUND_CLOSEST(max, 5) };
> +
> + if (drm_dp_dpcd_write(_dp->aux, DP_EDP_DBC_MINIMUM_BRIGHTNESS_SET,
> +   dbc, sizeof(dbc)) < 0) {
> + DRM_DEBUG_KMS("Failed to write aux DBC brightness level\n");
> + return false;
> + }
> + return true;
> +}
> +
>  static void intel_dp_aux_enable_backlight(const struct intel_crtc_state 
> *crtc_state,
> const struct drm_connector_state 
> *conn_state)
>  {
> @@ -208,6 +226,14 @@ static void intel_dp_aux_enable_backlight(const struct 
> intel_crtc_state *crtc_st
>   if (intel_dp_aux_set_pwm_freq(connector))
>   new_dpcd_buf |= DP_EDP_BACKLIGHT_FREQ_AUX_SET_ENABLE;
>  
> + if (i915.enable_dbc &&
> + (intel_dp->edp_dpcd[2] & DP_EDP_DYNAMIC_BACKLIGHT_CAP)) {
> + if(intel_dp_aux_set_dynamic_backlight_percent(intel_dp, 0, 
> 100)) {
> + new_dpcd_buf |= DP_EDP_DYNAMIC_BACKLIGHT_ENABLE;
> + DRM_DEBUG_KMS("Enable dynamic brightness.\n");
> + }
> + }
> +
>   if (new_dpcd_buf != dpcd_buf) {
>   if (drm_dp_dpcd_writeb(_dp->aux,
>   DP_EDP_BACKLIGHT_MODE_SET_REGISTER, new_dpcd_buf) < 0) {
> -- 
> 2.13.1.611.g7e3b11ae1-goog
> 
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 21/21] drm/etnaviv: submit supports performance monitor requests

[Lucas Stach]

Am Freitag, den 09.06.2017, 12:26 +0200 schrieb Christian Gmeiner:
> We increment the minor driver version so userspace can detect perfmon
> support.
> 
> Signed-off-by: Christian Gmeiner 

Reviewed-by: Lucas Stach 

> ---
>  drivers/gpu/drm/etnaviv/etnaviv_drv.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> index 536760a..eec6c00 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> @@ -550,7 +550,7 @@ static struct drm_driver etnaviv_drm_driver = {
>   .desc   = "etnaviv DRM",
>   .date   = "20151214",
>   .major  = 1,
> - .minor  = 1,
> + .minor  = 2,
>  };
>  
>  /*
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 20/21] drm/etnaviv: enable debug registers on demand

[Lucas Stach]

Please add a short description, stating that the perfmon registers are
debug regs.

Am Freitag, den 09.06.2017, 12:26 +0200 schrieb Christian Gmeiner:
> Signed-off-by: Christian Gmeiner 

Reviewed-by: Lucas Stach 

> ---
>  drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> index 1e23472..faf2925 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> @@ -1336,6 +1336,11 @@ static void
> sync_point_perfmon_sample_pre(struct etnaviv_gpu *gpu,
>   val &= ~VIVS_PM_POWER_CONTROLS_ENABLE_MODULE_CLOCK_GATING;
>   gpu_write(gpu, VIVS_PM_POWER_CONTROLS, val);
>  
> + /* enable debug register */
> + val = gpu_read(gpu, VIVS_HI_CLOCK_CONTROL);
> + val &= ~VIVS_HI_CLOCK_CONTROL_DISABLE_DEBUG_REGISTERS;
> + gpu_write(gpu, VIVS_HI_CLOCK_CONTROL, val);
> +
>   sync_point_perfmon_sample(gpu, event, ETNA_PM_PROCESS_PRE);
>  }
>  
> @@ -1353,6 +1358,11 @@ static void
> sync_point_perfmon_sample_post(struct etnaviv_gpu *gpu,
>   *pmr->bo_vma = pmr->sequence;
>   }
>  
> + /* disable debug register */
> + val = gpu_read(gpu, VIVS_HI_CLOCK_CONTROL);
> + val |= VIVS_HI_CLOCK_CONTROL_DISABLE_DEBUG_REGISTERS;
> + gpu_write(gpu, VIVS_HI_CLOCK_CONTROL, val);
> +
>   /* enable clock gating */
>   val = gpu_read(gpu, VIVS_PM_POWER_CONTROLS);
>   val |= VIVS_PM_POWER_CONTROLS_ENABLE_MODULE_CLOCK_GATING;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 19/21] drm/etnaviv: need to disable clock gating when doing profiling

[Lucas Stach]

Am Freitag, den 09.06.2017, 12:26 +0200 schrieb Christian Gmeiner:
> As done by Vivante kernel driver.
> 
> Signed-off-by: Christian Gmeiner 

Reviewed-by: Lucas Stach 

> ---
>  drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> index 2e9f031..1e23472 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> @@ -1329,6 +1329,13 @@ static void sync_point_perfmon_sample(struct
> etnaviv_gpu *gpu,
>  static void sync_point_perfmon_sample_pre(struct etnaviv_gpu *gpu,
>   struct etnaviv_event *event)
>  {
> + u32 val;
> +
> + /* disable clock gating */
> + val = gpu_read(gpu, VIVS_PM_POWER_CONTROLS);
> + val &= ~VIVS_PM_POWER_CONTROLS_ENABLE_MODULE_CLOCK_GATING;
> + gpu_write(gpu, VIVS_PM_POWER_CONTROLS, val);
> +
>   sync_point_perfmon_sample(gpu, event, ETNA_PM_PROCESS_PRE);
>  }
>  
> @@ -1336,6 +1343,7 @@ static void
> sync_point_perfmon_sample_post(struct etnaviv_gpu *gpu,
>   struct etnaviv_event *event)
>  {
>   unsigned int i;
> + u32 val;
>  
>   sync_point_perfmon_sample(gpu, event, ETNA_PM_PROCESS_POST);
>  
> @@ -1344,6 +1352,11 @@ static void
> sync_point_perfmon_sample_post(struct etnaviv_gpu *gpu,
>  
>   *pmr->bo_vma = pmr->sequence;
>   }
> +
> + /* enable clock gating */
> + val = gpu_read(gpu, VIVS_PM_POWER_CONTROLS);
> + val |= VIVS_PM_POWER_CONTROLS_ENABLE_MODULE_CLOCK_GATING;
> + gpu_write(gpu, VIVS_PM_POWER_CONTROLS, val);
>  }
>  
>  
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99349] Failed to build shader (translation from TGSI)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99349

--- Comment #15 from Elia Argentieri  ---
Now it works! I also had to set MESA_GLSL_CACHE_DISABLE to make it work, maybe
it was picking the old shader. Thank you very much.

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

Re: [PATCH 10/21] drm/etnaviv: use 'sync points' for performance monitor requests

[Lucas Stach]

Am Freitag, den 09.06.2017, 12:26 +0200 schrieb Christian Gmeiner:
> With 'sync points' we can sample the reqeustes perform signals
> before and/or after the submited command buffer.
> 
> Signed-off-by: Christian Gmeiner 
> ---
>  drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 112
> +-
>  drivers/gpu/drm/etnaviv/etnaviv_gpu.h |   4 ++
>  2 files changed, 102 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> index 0766861..2e9f031 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> @@ -1313,12 +1313,47 @@ void etnaviv_gpu_pm_put(struct etnaviv_gpu
> *gpu)
>   pm_runtime_put_autosuspend(gpu->dev);
>  }
>  
> +static void sync_point_perfmon_sample(struct etnaviv_gpu *gpu,
> + struct etnaviv_event *event, unsigned int flags)
> +{
> + unsigned int i;
> +
> + for (i = 0; i < event->nr_pmrs; i++) {
> + const struct etnaviv_perfmon_request *pmr = event-
> >pmrs + i;
> +
> + if (pmr->flags == flags)
> + etnaviv_perfmon_process(gpu, pmr);
> + }
> +}
> +
> +static void sync_point_perfmon_sample_pre(struct etnaviv_gpu *gpu,
> + struct etnaviv_event *event)
> +{
> + sync_point_perfmon_sample(gpu, event, ETNA_PM_PROCESS_PRE);
> +}
> +
> +static void sync_point_perfmon_sample_post(struct etnaviv_gpu *gpu,
> + struct etnaviv_event *event)
> +{
> + unsigned int i;
> +
> + sync_point_perfmon_sample(gpu, event, ETNA_PM_PROCESS_POST);
> +
> + for (i = 0; i < event->nr_pmrs; i++) {
> + const struct etnaviv_perfmon_request *pmr = event-
> >pmrs + i;
> +
> + *pmr->bo_vma = pmr->sequence;
> + }
> +}
> +
> +
>  /* add bo's to gpu's ring, and kick gpu: */
>  int etnaviv_gpu_submit(struct etnaviv_gpu *gpu,
>   struct etnaviv_gem_submit *submit, struct etnaviv_cmdbuf
> *cmdbuf)
>  {
>   struct dma_fence *fence;
>   unsigned int event, i;
> + unsigned int sync[2] = { ~0U, ~0U };
>   int ret;
>  
>   ret = etnaviv_gpu_pm_get_sync(gpu);
> @@ -1341,6 +1376,39 @@ int etnaviv_gpu_submit(struct etnaviv_gpu
> *gpu,
>   goto out_pm_put;
>   }
>  
> + /*
> +  * if there are performance monitor requests we need to have
> a sync point to
> +  * re-configure gpu and process ETNA_PM_PROCESS_PRE
> requests.
> +  */
> + if (cmdbuf->nr_pmrs) {
> + sync[0] = event_alloc(gpu);
> +
> + if (unlikely(sync[0] == ~0U)) {
> + DRM_ERROR("no free events for sync point
> 0\n");
> + event_free(gpu, event);
> + ret = -EBUSY;
> + goto out_pm_put;
> + }
> + }
> +
> + /*
> +  * if there are performance monitor requests we need to have
> sync point to
> +  * re-configure gpu, process ETNA_PM_PROCESS_POST requests
> and update the
> +  * sequence number for userspace.
> +  */
> + if (cmdbuf->nr_pmrs) {
> + sync[1] = event_alloc(gpu);
> +
> + if (unlikely(sync[1] == ~0U)) {
> + DRM_ERROR("no free events for sync point
> 1\n");
> + event_free(gpu, event);
> + if (unlikely(sync[0] == ~0U))
> + event_free(gpu, sync[0]);
> + ret = -EBUSY;
> + goto out_pm_put;
> + }
> + }
> +

This is dangerous. We aren't holding the GPU lock at this point (and we
can't because of livelocks with the GPU hangchecker), so given enough
parallel submits with PMRs all the submits might abort as they can't
allocate enough events, as each one might hold one out of the available
events.

I think what we need here is to extend the event_alloc API to take the
number of events we need and grab them all at once under the event
spinlock.

>   mutex_lock(>lock);
>  
>   fence = etnaviv_gpu_fence_alloc(gpu);
> @@ -1360,8 +1428,22 @@ int etnaviv_gpu_submit(struct etnaviv_gpu
> *gpu,
>   gpu->lastctx = cmdbuf->ctx;
>   }
>  
> + if (sync[0] != ~0U) {
> + gpu->event[sync[0]].sync_point =
> _point_perfmon_sample_pre;
> + gpu->event[sync[0]].nr_pmrs = cmdbuf->nr_pmrs;
> + gpu->event[sync[0]].pmrs = cmdbuf->pmrs;
> + etnaviv_sync_point_queue(gpu, sync[0]);
> + }
> +
>   etnaviv_buffer_queue(gpu, event, cmdbuf);
>  
> + if (sync[1] != ~0U) {
> + gpu->event[sync[1]].sync_point =
> _point_perfmon_sample_post;
> + gpu->event[sync[1]].nr_pmrs = cmdbuf->nr_pmrs;
> + gpu->event[sync[1]].pmrs = cmdbuf->pmrs;
> + etnaviv_sync_point_queue(gpu, sync[1]);
> + }
> +
>   cmdbuf->fence = fence;
>   list_add_tail(>node, >active_cmd_list);
>  
> @@ -1455,20 +1537,22 @@ static irqreturn_t irq_handler(int irq, void
> *data)

Re: [PATCH 09/21] drm/etnaviv: clear alloced event

[Lucas Stach]

Am Freitag, den 09.06.2017, 12:21 +0200 schrieb Christian Gmeiner:
> Results in less code as there is no need to set every struct
> member to 0/NULL.
> 
> Signed-off-by: Christian Gmeiner 

Reviewed-by: Lucas Stach 

> ---
>  drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> index 803fcf4..0766861 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> @@ -1156,6 +1156,7 @@ static unsigned int event_alloc(struct
> etnaviv_gpu *gpu)
>   /* find first free event */
>   for (i = 0; i < ARRAY_SIZE(gpu->event); i++) {
>   if (gpu->event[i].used == false) {
> + memset(>event[i], 0, sizeof(struct
> etnaviv_event));
>   gpu->event[i].used = true;
>   event = i;
>   break;
> @@ -1350,7 +1351,6 @@ int etnaviv_gpu_submit(struct etnaviv_gpu *gpu,
>   }
>  
>   gpu->event[event].fence = fence;
> - gpu->event[event].sync_point = NULL;
>   submit->fence = dma_fence_get(fence);
>   gpu->active_fence = submit->fence->seqno;
>  
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 08/21] drm/etnaviv: add 'sync point' support

[Lucas Stach]

Am Freitag, den 09.06.2017, 12:21 +0200 schrieb Christian Gmeiner:
> In order to support performance counters in a sane way we need to
> provide
> a method to sync the GPU with the CPU. The GPU can process multpile
> command
> buffers/events per irq. With the help of a 'sync point' we can
> trigger an event
> and stop the GPU/FE immediately. When the CPU is done with is
> processing it
> simply needs to restart the FE and the GPU will continue.
> 
> Signed-off-by: Christian Gmeiner 
> ---
>  drivers/gpu/drm/etnaviv/etnaviv_buffer.c | 36
> 
>  drivers/gpu/drm/etnaviv/etnaviv_drv.h|  1 +
>  drivers/gpu/drm/etnaviv/etnaviv_gpu.c| 14 +
>  drivers/gpu/drm/etnaviv/etnaviv_gpu.h|  2 ++
>  4 files changed, 53 insertions(+)
> 
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
> b/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
> index ed9588f..9e7098e 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
> @@ -250,6 +250,42 @@ void etnaviv_buffer_end(struct etnaviv_gpu *gpu)
>   }
>  }
>  
> +/* Append a 'sync point' to the ring buffer. */
> +void etnaviv_sync_point_queue(struct etnaviv_gpu *gpu, unsigned int
> event)
> +{
> + struct etnaviv_cmdbuf *buffer = gpu->buffer;
> + unsigned int waitlink_offset = buffer->user_size - 16;
> + u32 dwords, target;
> +
> + /*
> +  * We need at most 3 dwords in the return target:
> +  * 1 event + 1 end + 1 wait + 1 link.
> +  */
> + dwords = 4;
> + target = etnaviv_buffer_reserve(gpu, buffer, dwords);
> +
> + /* Signal sync point event */
> + CMD_LOAD_STATE(buffer, VIVS_GL_EVENT,
> VIVS_GL_EVENT_EVENT_ID(event) |
> +    VIVS_GL_EVENT_FROM_PE);
> +
> + /* Stop the FE to 'pause' the GPU */
> + CMD_END(buffer);
> +
> + /* Append waitlink */
> + CMD_WAIT(buffer);
> + CMD_LINK(buffer, 2, etnaviv_cmdbuf_get_va(buffer) +
> + buffer->user_size - 4);
> +
> + /*
> +  * Kick off the 'sync point' command by replacing the
> previous
> +  * WAIT with a link to the address in the ring buffer.
> +  */
> + etnaviv_buffer_replace_wait(buffer, waitlink_offset,
> + VIV_FE_LINK_HEADER_OP_LINK |
> + VIV_FE_LINK_HEADER_PREFETCH(dwor
> ds),
> + target);
> +}
> +
>  /* Append a command buffer to the ring buffer. */
>  void etnaviv_buffer_queue(struct etnaviv_gpu *gpu, unsigned int
> event,
>   struct etnaviv_cmdbuf *cmdbuf)
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.h
> b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
> index 058389f..f6cdd69 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_drv.h
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
> @@ -101,6 +101,7 @@ int etnaviv_gem_new_userptr(struct drm_device
> *dev, struct drm_file *file,
>  u16 etnaviv_buffer_init(struct etnaviv_gpu *gpu);
>  u16 etnaviv_buffer_config_mmuv2(struct etnaviv_gpu *gpu, u32
> mtlb_addr, u32 safe_addr);
>  void etnaviv_buffer_end(struct etnaviv_gpu *gpu);
> +void etnaviv_sync_point_queue(struct etnaviv_gpu *gpu, unsigned int
> event);
>  void etnaviv_buffer_queue(struct etnaviv_gpu *gpu, unsigned int
> event,
>   struct etnaviv_cmdbuf *cmdbuf);
>  void etnaviv_validate_init(void);
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> index 037087e..803fcf4 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> @@ -25,6 +25,7 @@
>  #include "etnaviv_gpu.h"
>  #include "etnaviv_gem.h"
>  #include "etnaviv_mmu.h"
> +#include "etnaviv_perfmon.h"
>  #include "common.xml.h"
>  #include "state.xml.h"
>  #include "state_hi.xml.h"
> @@ -1349,6 +1350,7 @@ int etnaviv_gpu_submit(struct etnaviv_gpu *gpu,
>   }
>  
>   gpu->event[event].fence = fence;
> + gpu->event[event].sync_point = NULL;
>   submit->fence = dma_fence_get(fence);
>   gpu->active_fence = submit->fence->seqno;
>  
> @@ -1394,6 +1396,15 @@ int etnaviv_gpu_submit(struct etnaviv_gpu
> *gpu,
>   return ret;
>  }
>  
> +static void etnaviv_process_sync_point(struct etnaviv_gpu *gpu,
> + struct etnaviv_event *event)
> +{
> + u32 addr = gpu_read(gpu, VIVS_FE_DMA_ADDRESS);
> +
> + event->sync_point(gpu, event);
> + etnaviv_gpu_start_fe(gpu, addr + 2, 2);
> +}
> +
>  /*
>   * Init/Cleanup:
>   */
> @@ -1440,6 +1451,9 @@ static irqreturn_t irq_handler(int irq, void
> *data)
>  
>   dev_dbg(gpu->dev, "event %u\n", event);
>  
> + if (gpu->event[event].sync_point)
> + etnaviv_process_sync_point(gpu,
> >event[event]);
> +

Sorry, but this part is a no-go. This means you are doing all the PM
register reads/writes (which might be many) from the IRQ handler. This
is a crucial fast path in the driver, which affects the realtime

Re: [PATCH 1/8] drm/amd/amdgpu: Added asic_type as ACP DMA driver platform data

[Christian König]

Am 23.06.2017 um 19:05 schrieb Alex Deucher:

On Fri, Jun 23, 2017 at 12:43 PM, Christian König
 wrote:

Am 23.06.2017 um 18:34 schrieb Alex Deucher:

From: Vijendar Mukunda 

asic_type information is passed to ACP DMA Driver as platform data.
We need this to determine whether the asic is Carrizo (CZ) or
Stoney (ST) in the acp sound driver.

Reviewed-by: Alex Deucher 
Signed-off-by: Vijendar Mukunda 
Signed-off-by: Alex Deucher 
---
   drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c | 4 
   sound/soc/amd/acp-pcm-dma.c | 8 ++--
   sound/soc/amd/acp.h | 7 +++
   3 files changed, 13 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
index 06879d1..7a2a765 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c
@@ -262,6 +262,7 @@ static int acp_hw_init(void *handle)
 uint64_t acp_base;
 struct device *dev;
 struct i2s_platform_data *i2s_pdata;
+   u32 asic_type;
 struct amdgpu_device *adev = (struct amdgpu_device *)handle;
   @@ -271,6 +272,7 @@ static int acp_hw_init(void *handle)
 if (!ip_block)
 return -EINVAL;
   + asic_type = adev->asic_type;
 r = amd_acp_hw_init(adev->acp.cgs_device,
 ip_block->version->major,
ip_block->version->minor);
 /* -ENODEV means board uses AZ rather than ACP */
@@ -355,6 +357,8 @@ static int acp_hw_init(void *handle)
 adev->acp.acp_cell[0].name = "acp_audio_dma";
 adev->acp.acp_cell[0].num_resources = 4;
 adev->acp.acp_cell[0].resources = >acp.acp_res[0];
+   adev->acp.acp_cell[0].platform_data = _type;
+   adev->acp.acp_cell[0].pdata_size = sizeof(asic_type);


Have the painkillers jellyfied my brain or are you setting a pointer in the
amdgpu device structure to some variable on the stack?

If it's just for initialization then that's probably ok, but I would reset
the pointer at the end of the function.

Otherwise somebody might have the idea to dereference it later on and that
can only lead to trouble.

I think it's ok because the hotplug of the audio device is triggered
from this function, so the audio device should be probed by the time
this variable goes out of scope.  That said, it would probably be
better to use the asic_type from the GPU driver instance directly
rather than a stack variable.


Yeah, agree. But keeping a stale reference in to a stack variable in the 
driver struct is still ugly like hell.


At bare minimum set this to NULL at the end of the function, or even 
better use a intptr_t to encode the asic type into the pointer.


Christian.



Alex



Christian.



 adev->acp.acp_cell[1].name = "designware-i2s";
 adev->acp.acp_cell[1].num_resources = 1;
diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
index 08b1399..dcbf997 100644
--- a/sound/soc/amd/acp-pcm-dma.c
+++ b/sound/soc/amd/acp-pcm-dma.c
@@ -73,12 +73,6 @@ static const struct snd_pcm_hardware
acp_pcm_hardware_capture = {
 .periods_max = CAPTURE_MAX_NUM_PERIODS,
   };
   -struct audio_drv_data {
-   struct snd_pcm_substream *play_stream;
-   struct snd_pcm_substream *capture_stream;
-   void __iomem *acp_mmio;
-};
-
   static u32 acp_reg_read(void __iomem *acp_mmio, u32 reg)
   {
 return readl(acp_mmio + (reg * 4));
@@ -916,6 +910,7 @@ static int acp_audio_probe(struct platform_device
*pdev)
 int status;
 struct audio_drv_data *audio_drv_data;
 struct resource *res;
+   const u32 *pdata = pdev->dev.platform_data;
 audio_drv_data = devm_kzalloc(>dev, sizeof(struct
audio_drv_data),
 GFP_KERNEL);
@@ -932,6 +927,7 @@ static int acp_audio_probe(struct platform_device
*pdev)
 audio_drv_data->play_stream = NULL;
 audio_drv_data->capture_stream = NULL;
+   audio_drv_data->asic_type =  *pdata;
 res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
 if (!res) {
diff --git a/sound/soc/amd/acp.h b/sound/soc/amd/acp.h
index 330832e..28cf914 100644
--- a/sound/soc/amd/acp.h
+++ b/sound/soc/amd/acp.h
@@ -84,6 +84,13 @@ struct audio_substream_data {
 void __iomem *acp_mmio;
   };
   +struct audio_drv_data {
+   struct snd_pcm_substream *play_stream;
+   struct snd_pcm_substream *capture_stream;
+   void __iomem *acp_mmio;
+   u32 asic_type;
+};
+
   enum {
 ACP_TILE_P1 = 0,
 ACP_TILE_P2,





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

Re: [PATCH 06/21] drm/etnaviv: copy pmrs from userspace

[Lucas Stach]

Am Freitag, den 09.06.2017, 12:21 +0200 schrieb Christian Gmeiner:
> All performance monitor requests will be validated during this phase.
> 
> Signed-off-by: Christian Gmeiner 
> ---
>  drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 68
> +++-
>  1 file changed, 66 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> index fdfe31d..ed05b64 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> @@ -21,6 +21,7 @@
>  #include "etnaviv_drv.h"
>  #include "etnaviv_gpu.h"
>  #include "etnaviv_gem.h"
> +#include "etnaviv_perfmon.h"
>  
>  /*
>   * Cmdstream submission:
> @@ -283,6 +284,53 @@ static int submit_reloc(struct
> etnaviv_gem_submit *submit, void *stream,
>   return 0;
>  }
>  
> +static int submit_perfmon_request(struct etnaviv_gem_submit *submit,

Please name this after what is does: submit_perfmon_validate()

> + struct etnaviv_cmdbuf *cmdbuf,
> + const struct drm_etnaviv_gem_submit_pmr *pmrs,
> + u32 nr_pms)
> +{
> + u32 i;
> +
> + for (i = 0; i < nr_pms; i++) {
> + const struct drm_etnaviv_gem_submit_pmr *r = pmrs +
> i;
> + struct etnaviv_gem_submit_bo *bo;
> + int ret;
> +
> + ret = submit_bo(submit, r->read_idx, );
> + if (ret)
> + return ret;
> +
> + if (r->read_offset == 0) {
> + DRM_ERROR("perfmon request: offset is 0");
> + return -EINVAL;
> + }

Why is a 0 offset invalid? Can't the readback be placed at the
beginning of the BO?

> +
> + if (r->read_offset >= bo->obj->base.size -
> sizeof(u32)) {
> + DRM_ERROR("perfmon request: offset %u
> outside object", i);
> + return -EINVAL;
> + }
> +
> + if (!r->flags) {
> + DRM_ERROR("perfmon request: flags are 0");
> + return -EINVAL;
> + }
This needs to validate that the flags are valid, not just that there
are flags -> reject any non-allocated flag bits.

> +
> + if (etnaviv_pm_req_validate(r)) {
> + DRM_ERROR("perfmon request: domain or signal
> not valid");
> + return -EINVAL;
> + }
> +
> + cmdbuf->pmrs[i].flags = r->flags;
> + cmdbuf->pmrs[i].domain = r->domain;
> + cmdbuf->pmrs[i].signal = r->signal;
> + cmdbuf->pmrs[i].sequence = r->sequence;
> + cmdbuf->pmrs[i].offset = r->read_offset;
> + cmdbuf->pmrs[i].bo_vma = etnaviv_gem_vmap(>obj-
> >base);
> + }
> +
> + return 0;
> +}
> +
>  static void submit_cleanup(struct etnaviv_gem_submit *submit)
>  {
>   unsigned i;
> @@ -306,6 +354,7 @@ int etnaviv_ioctl_gem_submit(struct drm_device
> *dev, void *data,
>   struct etnaviv_drm_private *priv = dev->dev_private;
>   struct drm_etnaviv_gem_submit *args = data;
>   struct drm_etnaviv_gem_submit_reloc *relocs;
> + struct drm_etnaviv_gem_submit_pmr *pmrs;
>   struct drm_etnaviv_gem_submit_bo *bos;
>   struct etnaviv_gem_submit *submit;
>   struct etnaviv_cmdbuf *cmdbuf;
> @@ -347,11 +396,12 @@ int etnaviv_ioctl_gem_submit(struct drm_device
> *dev, void *data,
>    */
>   bos = drm_malloc_ab(args->nr_bos, sizeof(*bos));
>   relocs = drm_malloc_ab(args->nr_relocs, sizeof(*relocs));
> + pmrs = drm_malloc_ab(args->nr_pmrs, sizeof(*pmrs));
>   stream = drm_malloc_ab(1, args->stream_size);
>   cmdbuf = etnaviv_cmdbuf_new(gpu->cmdbuf_suballoc,
>   ALIGN(args->stream_size, 8) + 8,
> - args->nr_bos, 0);
> - if (!bos || !relocs || !stream || !cmdbuf) {
> + args->nr_bos, args->nr_pmrs);
> + if (!bos || !relocs || !pmrs || !stream || !cmdbuf) {
>   ret = -ENOMEM;
>   goto err_submit_cmds;
>   }
> @@ -373,6 +423,13 @@ int etnaviv_ioctl_gem_submit(struct drm_device
> *dev, void *data,
>   goto err_submit_cmds;
>   }
>  
> + ret = copy_from_user(pmrs, u64_to_user_ptr(args->pmrs),
> +  args->nr_pmrs * sizeof(*pmrs));
> + if (ret) {
> + ret = -EFAULT;
> + goto err_submit_cmds;
> + }
> +
>   ret = copy_from_user(stream, u64_to_user_ptr(args->stream),
>    args->stream_size);
>   if (ret) {
> @@ -441,8 +498,13 @@ int etnaviv_ioctl_gem_submit(struct drm_device
> *dev, void *data,
>   if (ret)
>   goto out;
>  
> + ret = submit_perfmon_request(submit, cmdbuf, pmrs, args-
> >nr_pmrs);
> + if (ret)
> + goto out;
> +
>   memcpy(cmdbuf->vaddr, stream, args->stream_size);
>   

Re: [PATCH 05/21] drm/etnaviv: add performance monitor request validation

[Lucas Stach]

Am Freitag, den 09.06.2017, 12:21 +0200 schrieb Christian Gmeiner:
> Check if the selected domain and signal combination exists.
> 
> Signed-off-by: Christian Gmeiner 

Reviewed-by: Lucas Stach 

> ---
>  drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 15 +++
>  drivers/gpu/drm/etnaviv/etnaviv_perfmon.h |  2 ++
>  2 files changed, 17 insertions(+)
> 
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
> b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
> index 9c6f284..b8dc5fa 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
> @@ -79,3 +79,18 @@ int etnaviv_pm_query_sig(struct etnaviv_gpu *gpu,
>  
>   return 0;
>  }
> +
> +int etnaviv_pm_req_validate(const struct drm_etnaviv_gem_submit_pmr
> *r)
> +{
> + const struct etnaviv_pm_domain *dom;
> +
> + if (r->domain >= ARRAY_SIZE(doms))
> + return -EINVAL;
> +
> + dom = [r->domain];
> +
> + if (r->signal > dom->nr_signals)
> + return -EINVAL;
> +
> + return 0;
> +}
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.h
> b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.h
> index 4b2b518..f20b69c 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.h
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.h
> @@ -40,4 +40,6 @@ int etnaviv_pm_query_dom(struct etnaviv_gpu *gpu,
>  int etnaviv_pm_query_sig(struct etnaviv_gpu *gpu,
>   struct drm_etnaviv_pm_signal *signal);
>  
> +int etnaviv_pm_req_validate(const struct drm_etnaviv_gem_submit_pmr
> *r);
> +
>  #endif /* __ETNAVIV_PERFMON_H__ */
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 04/21] drm/etnaviv: extend etnaviv_gpu_cmdbuf_new(..) with nr_pmrs

[Lucas Stach]

Am Freitag, den 09.06.2017, 12:21 +0200 schrieb Christian Gmeiner:
> This commits extends etnaviv_gpu_cmdbuf_new(..) to define the number
> of struct etnaviv_perfmon elements gets stored.
> 
> Signed-off-by: Christian Gmeiner 
> ---
>  drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c | 13 -
>  drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.h |  2 +-
>  drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c |  2 +-
>  drivers/gpu/drm/etnaviv/etnaviv_gpu.c|  2 +-
>  4 files changed, 15 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c
> b/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c
> index 633e0f0..bb3f82e 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c
> @@ -19,6 +19,7 @@
>  #include "etnaviv_cmdbuf.h"
>  #include "etnaviv_gpu.h"
>  #include "etnaviv_mmu.h"
> +#include "etnaviv_perfmon.h"
>  
>  #define SUBALLOC_SIZESZ_256K
>  #define SUBALLOC_GRANULE SZ_4K
> @@ -87,9 +88,10 @@ void etnaviv_cmdbuf_suballoc_destroy(struct
> etnaviv_cmdbuf_suballoc *suballoc)
>  
>  struct etnaviv_cmdbuf *
>  etnaviv_cmdbuf_new(struct etnaviv_cmdbuf_suballoc *suballoc, u32
> size,
> -    size_t nr_bos)
> +    size_t nr_bos, size_t nr_pmrs)
>  {
>   struct etnaviv_cmdbuf *cmdbuf;
> + struct etnaviv_perfmon_request *pmrs;
>   size_t sz = size_vstruct(nr_bos, sizeof(cmdbuf->bo_map[0]),
>    sizeof(*cmdbuf));
>   int granule_offs, order, ret;
> @@ -98,6 +100,14 @@ etnaviv_cmdbuf_new(struct etnaviv_cmdbuf_suballoc
> *suballoc, u32 size,
>   if (!cmdbuf)
>   return NULL;
>  
> + sz = sizeof(*pmrs) * nr_pmrs;
> + pmrs = kzalloc(sz, GFP_KERNEL);
> + if (!pmrs) {
> + kfree(cmdbuf);
> + return NULL;
> + }

While this is okay as-is, I have some more additions to this code
planned, so I would appreciate if you could change this into a "goto
out_free_cmdbuf" and move this down to the end of the function.

Regards,
Lucas

> + cmdbuf->pmrs = pmrs;
>   cmdbuf->suballoc = suballoc;
>   cmdbuf->size = size;
>  
> @@ -139,6 +149,7 @@ void etnaviv_cmdbuf_free(struct etnaviv_cmdbuf
> *cmdbuf)
>   suballoc->free_space = 1;
>   mutex_unlock(>lock);
>   wake_up_all(>free_event);
> + kfree(cmdbuf->pmrs);
>   kfree(cmdbuf);
>  }
>  
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.h
> b/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.h
> index 1b549f0..b6348b9 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.h
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.h
> @@ -53,7 +53,7 @@ void etnaviv_cmdbuf_suballoc_destroy(struct
> etnaviv_cmdbuf_suballoc *suballoc);
>  
>  struct etnaviv_cmdbuf *
>  etnaviv_cmdbuf_new(struct etnaviv_cmdbuf_suballoc *suballoc, u32
> size,
> -    size_t nr_bos);
> +    size_t nr_bos, size_t nr_pmrs);
>  void etnaviv_cmdbuf_free(struct etnaviv_cmdbuf *cmdbuf);
>  
>  u32 etnaviv_cmdbuf_get_va(struct etnaviv_cmdbuf *buf);
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> index de80ee1..fdfe31d 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> @@ -350,7 +350,7 @@ int etnaviv_ioctl_gem_submit(struct drm_device
> *dev, void *data,
>   stream = drm_malloc_ab(1, args->stream_size);
>   cmdbuf = etnaviv_cmdbuf_new(gpu->cmdbuf_suballoc,
>   ALIGN(args->stream_size, 8) + 8,
> - args->nr_bos);
> + args->nr_bos, 0);
>   if (!bos || !relocs || !stream || !cmdbuf) {
>   ret = -ENOMEM;
>   goto err_submit_cmds;
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> index ada45fd..037087e 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> @@ -721,7 +721,7 @@ int etnaviv_gpu_init(struct etnaviv_gpu *gpu)
>   }
>  
>   /* Create buffer: */
> - gpu->buffer = etnaviv_cmdbuf_new(gpu->cmdbuf_suballoc,
> PAGE_SIZE, 0);
> + gpu->buffer = etnaviv_cmdbuf_new(gpu->cmdbuf_suballoc,
> PAGE_SIZE, 0, 0);
>   if (!gpu->buffer) {
>   ret = -ENOMEM;
>   dev_err(gpu->dev, "could not create command
> buffer\n");
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 02/21] drm/etnaviv: add uapi for perfmon feature

[Lucas Stach]

Am Freitag, den 09.06.2017, 12:21 +0200 schrieb Christian Gmeiner:
> Sadly we can not read any registers via command stream so we need
> to extend the drm_etnaviv_gem_submit struct with performance monitor
> requests. Those requests gets process before and/or after the actual
> submitted command stream.
> 
> The Vivante kernel driver has a special ioctl to read all perfmon
> registers at once and return it. There is no connection between
> a specifc command stream and the read perf values.
> 
> Signed-off-by: Christian Gmeiner 
> ---
>  include/uapi/drm/etnaviv_drm.h | 16 
>  1 file changed, 16 insertions(+)
> 
> diff --git a/include/uapi/drm/etnaviv_drm.h
> b/include/uapi/drm/etnaviv_drm.h
> index 9e488a0..b67a7dd 100644
> --- a/include/uapi/drm/etnaviv_drm.h
> +++ b/include/uapi/drm/etnaviv_drm.h
> @@ -150,6 +150,19 @@ struct drm_etnaviv_gem_submit_bo {
>   __u64 presumed;   /* in/out, presumed buffer address */
>  };
>  
> +/* performance monitor request (pmr) */
> +#define ETNA_PM_PROCESS_PRE 0x0001
> +#define ETNA_PM_PROCESS_POST0x0002
> +struct drm_etnaviv_gem_submit_pmr {
> + __u32 flags;  /* in, when to process request
> (ETNA_PM_PROCESS_x) */
> + __u8  domain; /* in, pm domain */
> + __u8  signal; /* in, pm signal */

Are we sure that no domain will ever have more than 256 signals?

> + __u16 pad[3];

Unnecessary large pad. A single u16 is enough to naturally align the
next member.

> + __u32 sequence;   /* in, sequence number */
> + __u32 read_offset;/* in, offset from read_bo */
> + __u32 read_idx;   /* in, index of read_bo buffer */
> +};
> +
>  /* Each cmdstream submit consists of a table of buffers involved,
> and
>   * one or more cmdstream buffers.  This allows for conditional
> execution
>   * (context-restore), and IB buffers needed for per tile/bin draw
> cmds.
> @@ -175,6 +188,9 @@ struct drm_etnaviv_gem_submit {
>   __u64 stream; /* in, ptr to cmdstream */
>   __u32 flags;  /* in, mask of ETNA_SUBMIT_x */
>   __s32 fence_fd;   /* in/out, fence fd (see
> ETNA_SUBMIT_FENCE_FD_x) */
> + __u64 pmrs;   /* in, ptr to array of submit_pmr's */
> + __u32 nr_pmrs;/* in, number of submit_pmr's */
> + __u32 pad;

This pad isn't needed.

>  };
>  
>  /* The normal way to synchronize with the GPU is just to CPU_PREP on
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99353] Kaveri 7400K shows random colored noise instead of GUI in X or Wayland

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99353

--- Comment #2 from Vedran Miletić  ---
Michel, I missed this reply, sorry! I will test ASAP.

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

Re: [PATCH 11/13] drm/vmwgfx: Drop drm_vblank_cleanup

[Thomas Hellstrom]

With the below fixed,

Reviewed-by: Thomas Hellstrom 


On 06/23/2017 04:10 PM, Sean Paul wrote:

On Wed, Jun 21, 2017 at 10:28:48AM +0200, Daniel Vetter wrote:

Again stopping the vblank before uninstalling the irq handler is kinda
the wrong way round, but the fb_off stuff should take care of
disabling the dsiplay at least in most cases. So drop the
drm_vblank_cleanup code since it's not really doing anything, it looks
all cargo-culted.

v2: Appease gcc better.

Cc: Sinclair Yeh 
Cc: Thomas Hellstrom 
Signed-off-by: Daniel Vetter 
---
  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c  |  9 +++--
  drivers/gpu/drm/vmwgfx/vmwgfx_kms.h  |  2 --
  drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c  |  4 
  drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c |  9 -
  drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 27 +--
  5 files changed, 4 insertions(+), 47 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 3d94ea67a825..a93c0bb73452 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -1658,7 +1658,7 @@ int vmw_kms_init(struct vmw_private *dev_priv)
  
  int vmw_kms_close(struct vmw_private *dev_priv)

  {
-   int ret;
+   int ret = 0;
  
  	/*

 * Docs says we should take the lock before calling this function
@@ -1666,11 +1666,8 @@ int vmw_kms_close(struct vmw_private *dev_priv)
 * drm_encoder_cleanup which takes the lock we deadlock.
 */
drm_mode_config_cleanup(dev_priv->dev);
-   if (dev_priv->active_display_unit == vmw_du_screen_object)
-   ret = vmw_kms_sou_close_display(dev_priv);
-   else if (dev_priv->active_display_unit == vmw_du_screen_target)
-   ret = vmw_kms_stdu_close_display(dev_priv);
-   else
+   if (dev_priv->active_display_unit != vmw_du_screen_object &&
+   dev_priv->active_display_unit != vmw_du_screen_target)

I think this is equivalent to:

if (dev_priv->active_display_unit == vmw_du_legacy)


ret = vmw_kms_ldu_close_display(dev_priv);
  
  	return ret;

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
index 5f8d678ae675..ff9c8389ff21 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
@@ -390,7 +390,6 @@ int vmw_kms_update_proxy(struct vmw_resource *res,
   * Screen Objects display functions - vmwgfx_scrn.c
   */
  int vmw_kms_sou_init_display(struct vmw_private *dev_priv);
-int vmw_kms_sou_close_display(struct vmw_private *dev_priv);
  int vmw_kms_sou_do_surface_dirty(struct vmw_private *dev_priv,
 struct vmw_framebuffer *framebuffer,
 struct drm_clip_rect *clips,
@@ -418,7 +417,6 @@ int vmw_kms_sou_readback(struct vmw_private *dev_priv,
   * Screen Target Display Unit functions - vmwgfx_stdu.c
   */
  int vmw_kms_stdu_init_display(struct vmw_private *dev_priv);
-int vmw_kms_stdu_close_display(struct vmw_private *dev_priv);
  int vmw_kms_stdu_surface_dirty(struct vmw_private *dev_priv,
   struct vmw_framebuffer *framebuffer,
   struct drm_clip_rect *clips,
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
index d3987bcf53f8..449ed4fba0f2 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
@@ -582,13 +582,9 @@ int vmw_kms_ldu_init_display(struct vmw_private *dev_priv)
  
  int vmw_kms_ldu_close_display(struct vmw_private *dev_priv)

  {
-   struct drm_device *dev = dev_priv->dev;
-
if (!dev_priv->ldu_priv)
return -ENOSYS;
  
-	drm_vblank_cleanup(dev);

-
BUG_ON(!list_empty(_priv->ldu_priv->active));
  
  	kfree(dev_priv->ldu_priv);

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
index 8d7dc9def7c2..3b917c9b0c21 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
@@ -746,15 +746,6 @@ int vmw_kms_sou_init_display(struct vmw_private *dev_priv)
return 0;
  }
  
-int vmw_kms_sou_close_display(struct vmw_private *dev_priv)

-{
-   struct drm_device *dev = dev_priv->dev;
-
-   drm_vblank_cleanup(dev);
-
-   return 0;
-}
-
  static int do_dmabuf_define_gmrfb(struct vmw_private *dev_priv,
  struct vmw_framebuffer *framebuffer)
  {
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
index 50be1f034f9e..6aecba6cd5e2 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
@@ -1651,36 +1651,11 @@ int vmw_kms_stdu_init_display(struct vmw_private 
*dev_priv)
  
  		if (unlikely(ret != 0)) {

DRM_ERROR("Failed to initialize STDU %d", i);
-   goto err_vblank_cleanup;
+  

[Bug 98238] Witcher 2: objects are black when changing lod on Radeon Pitcairn

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=98238

Gregor Münch  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #22 from Gregor Münch  ---
(In reply to Shmerl from comment #21)
> It's now in master. It should eventually land in /etc/drirc in distros, but
> until then, build Mesa from source and set this variable when running the
> game:
> 
> glsl_correct_derivatives_after_discard=true

Not needed, Edmondos patch sets this automatically.
https://cgit.freedesktop.org/mesa/mesa/commit/?id=2ea16f08f3f57ce32a2912ddd0ed74027a89a547

If someone wants old behavior back set in game's launch option:
glsl_correct_derivatives_after_discard=false %command%

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

[Bug 194761] amdgpu driver breaks on Oland (SI)

[bugzilla-daemon]

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

--- Comment #68 from siyia (eutychio...@gmail.com) ---
Probably some mistake in the documentation, otherwise i doesnt make sense,
unless the use some magic lol, by the way with kernel 4.11.6 the problem got
worse, now also the desktop enviroment is rendered incorrectly.

-- 
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] drm/vmwgfx: Fix fbdev emulation using legacy functions

[Thomas Hellstrom]

Hi, Daniel,

On 06/21/2017 03:30 PM, Daniel Vetter wrote:

On Thu, Apr 6, 2017 at 10:02 PM, Daniel Vetter  wrote:

Fixing this properly would mean we get to wire the acquire_ctx all the
way through vmwgfx fbdev code, and doing the same was tricky for the
shared fbdev layer. Probably much better to look into refactoring the
entire code to use the helpers, but since that's not a viable
long-term solution fix the issue by open-coding a vmwgfx version of
set_config, that does the legacy backoff dance internally.

I'm digging around in the fbev locking again, and stumbled over this.
Any plans for vmwgfx to switch over to the core fbdev emulation
helpers? If not I'll have to put another layer of hacks around this,
and it's kinda getting unsightly :(


It's on our todo-list but I don't think any work on this will take place 
during summer, because of vacations etc.


Thanks,
Thomas





My goal is to remove any usage of the implicit
mode_config.acquire_context since that just breaks the wait/wound
mutex locking scheme and doesn't really work together with atomic
drivers. Once fbdev helpers and the property setting are fixed this
here is the last place (minus something in i915 that I'll take care of
of course). I'm getting close to that point.

Thanks, Daniel



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

[Bug 101596] Blender renders black UI elements

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101596

Sebastian Parborg  changed:

   What|Removed |Added

   Hardware|Other   |x86-64 (AMD64)
 OS|All |Linux (All)

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

[Bug 101596] Blender renders black UI elements

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101596

--- Comment #2 from Sebastian Parborg  ---
Created attachment 132253
  --> https://bugs.freedesktop.org/attachment.cgi?id=132253=edit
blender after matcap

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

[Bug 101596] Blender renders black UI elements

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101596

Bug ID: 101596
   Summary: Blender renders black UI elements
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: darkdefe...@gmail.com
QA Contact: dri-devel@lists.freedesktop.org

Created attachment 132251
  --> https://bugs.freedesktop.org/attachment.cgi?id=132251=edit
glxinfo output

It seems like a recent change to llvm or mesa broke blender on radeonsi. It
works fine with llvm 4 and mesa 17.1.3.

Steps to reproduce:

1. Open the blender default cube scene.

2. Open the "N" panel by pressing N while your mouse cursor is in the 3d view.

3. Scroll down to the "Shading" tab and check "Matcap"

4. Now UI elements becomes black (and more and more will become black as you
use the program)

See the attached screenshots

I should also point out that it is not only matcaps that triggers this.
However, it is the fastest way to trigger this.

I have attached the output of glxinfo.

BTW, there is also a other long standing problem where you have to use tripple
buffering in blender with radeonsi or the UI is messed up. I didn't find any
bug for this either, but it has been a problem for a long time so I don't know
if this is known?

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

[Bug 101596] Blender renders black UI elements

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101596

--- Comment #1 from Sebastian Parborg  ---
Created attachment 132252
  --> https://bugs.freedesktop.org/attachment.cgi?id=132252=edit
Blender before matcap

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

Re: [PATCH 3/4] drm/i915: Add format modifiers for Intel

[Emil Velikov]

On 23 June 2017 at 17:45, Ben Widawsky  wrote:
> This was based on a patch originally by Kristian. It has been modified
> pretty heavily to use the new callbacks from the previous patch.
>
> v2:
>   - Add LINEAR and Yf modifiers to list (Ville)
>   - Combine i8xx and i965 into one list of formats (Ville)
>   - Allow 1010102 formats for Y/Yf tiled (Ville)
>
> v3:
>   - Handle cursor formats (Ville)
>   - Put handling for LINEAR in the mod_support functions (Ville)
>
> v4:
>   - List each modifier explicitly in supported modifiers (Ville)
>   - Handle the CURSOR plane (Ville)
>
> v5:
>   - Split out cursor and sprite handling (Ville)
>
> v6:
>   - Actually use the sprite funcs (Emil)
>   - Use unreachable (Emil)
>
> v7:
>   - Only allow Intel modifiers and LINEAR (Ben)
>
> v8
>   - Fix spite assert introduced in v6 (Daniel)
>
> Cc: Ville Syrjälä 
> Cc: Kristian H. Kristensen 
> Cc: Emil Velikov 
> Signed-off-by: Ben Widawsky 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 136 
> +--
>  drivers/gpu/drm/i915/intel_sprite.c  |  82 -
>  2 files changed, 211 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 7d55c5e3df28..877a51514c61 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -72,6 +72,12 @@ static const uint32_t i965_primary_formats[] = {
> DRM_FORMAT_XBGR2101010,
>  };
>
> +static const uint64_t i9xx_format_modifiers[] = {
> +   I915_FORMAT_MOD_X_TILED,
> +   DRM_FORMAT_MOD_LINEAR,
> +   DRM_FORMAT_MOD_INVALID
> +};
> +
>  static const uint32_t skl_primary_formats[] = {
> DRM_FORMAT_C8,
> DRM_FORMAT_RGB565,
> @@ -87,11 +93,24 @@ static const uint32_t skl_primary_formats[] = {
> DRM_FORMAT_VYUY,
>  };
>
> +static const uint64_t skl_format_modifiers[] = {
> +   I915_FORMAT_MOD_Yf_TILED,
> +   I915_FORMAT_MOD_Y_TILED,
> +   I915_FORMAT_MOD_X_TILED,
> +   DRM_FORMAT_MOD_LINEAR,
> +   DRM_FORMAT_MOD_INVALID
> +};
> +
>  /* Cursor formats */
>  static const uint32_t intel_cursor_formats[] = {
> DRM_FORMAT_ARGB,
>  };
>
> +static const uint64_t cursor_format_modifiers[] = {
> +   DRM_FORMAT_MOD_LINEAR,
> +   DRM_FORMAT_MOD_INVALID
> +};
> +
>  static void i9xx_crtc_clock_get(struct intel_crtc *crtc,
> struct intel_crtc_state *pipe_config);
>  static void ironlake_pch_clock_get(struct intel_crtc *crtc,
> @@ -13810,6 +13829,108 @@ void intel_plane_destroy(struct drm_plane *plane)
> kfree(to_intel_plane(plane));
>  }
>
> +static bool i8xx_mod_supported(uint32_t format, uint64_t modifier)
> +{
> +   switch (format) {
> +   case DRM_FORMAT_C8:
> +   case DRM_FORMAT_RGB565:
> +   case DRM_FORMAT_XRGB1555:
> +   case DRM_FORMAT_XRGB:
> +   return modifier == DRM_FORMAT_MOD_LINEAR ||
> +   modifier == I915_FORMAT_MOD_X_TILED;
> +   default:
> +   return false;
> +   }
> +}
> +
> +static bool i965_mod_supported(uint32_t format, uint64_t modifier)
> +{
> +   switch (format) {
> +   case DRM_FORMAT_C8:
> +   case DRM_FORMAT_RGB565:
> +   case DRM_FORMAT_XRGB:
> +   case DRM_FORMAT_XBGR:
> +   case DRM_FORMAT_XRGB2101010:
> +   case DRM_FORMAT_XBGR2101010:
> +   return modifier == DRM_FORMAT_MOD_LINEAR ||
> +   modifier == I915_FORMAT_MOD_X_TILED;
> +   default:
> +   return false;
> +   }
> +}
> +
> +static bool skl_mod_supported(uint32_t format, uint64_t modifier)
> +{
> +   switch (format) {
> +   case DRM_FORMAT_C8:
> +   switch (modifier) {
> +   case DRM_FORMAT_MOD_LINEAR:
> +   case I915_FORMAT_MOD_X_TILED:
> +   case I915_FORMAT_MOD_Y_TILED:
> +   return true;
> +   default:
> +   return false;
> +   }
> +   case DRM_FORMAT_RGB565:
> +   case DRM_FORMAT_XRGB:
> +   case DRM_FORMAT_XBGR:
> +   case DRM_FORMAT_ARGB:
> +   case DRM_FORMAT_ABGR:
> +   case DRM_FORMAT_XRGB2101010:
> +   case DRM_FORMAT_XBGR2101010:
> +   case DRM_FORMAT_YUYV:
> +   case DRM_FORMAT_YVYU:
> +   case DRM_FORMAT_UYVY:
> +   case DRM_FORMAT_VYUY:
> +   /* All i915 modifiers are fine */
> +   switch (modifier) {
> +   case DRM_FORMAT_MOD_LINEAR:
> +   case I915_FORMAT_MOD_X_TILED:
> +   case I915_FORMAT_MOD_Y_TILED:
> +   case I915_FORMAT_MOD_Yf_TILED:
> +   return true;
> +   default:
> +   return false;
> +   }
> +   default:
> +   

Re: [Intel-gfx] [PATCH v4 10/15] drm/i915: add compute-config for YCBCR outputs

[Ander Conselvan De Oliveira]

On Wed, 2017-06-21 at 21:19 +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 6/20/2017 7:50 PM, Ander Conselvan De Oliveira wrote:
> > On Mon, 2017-06-19 at 21:38 +0530, Shashank Sharma wrote:
> > > This patch checks encoder level support for HDMI YCBCR outputs.
> > > HDMI output mode is a connector property, this patch checks if
> > > source and sink can support the HDMI output type selected by user.
> > > And if they both can, it commits the hdmi output type into crtc state,
> > > for further staging in driver.
> > > 
> > > V2: Split the patch into two, kept helper functions in DRM layer.
> > > V3: Changed the compute_config function based on new DRM API.
> > > V4: Rebase
> > > 
> > > Cc: Ville Syrjala 
> > > Cc: Daniel Vetter 
> > > Cc: Ander Conselvan De Oliveira 
> > > Signed-off-by: Shashank Sharma 
> > > ---
> > >   drivers/gpu/drm/i915/intel_display.c |  1 +
> > >   drivers/gpu/drm/i915/intel_drv.h |  3 ++
> > >   drivers/gpu/drm/i915/intel_hdmi.c| 93 
> > > ++--
> > >   3 files changed, 94 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index f9bf0d5..da29536 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -11930,6 +11930,7 @@ intel_pipe_config_compare(struct drm_i915_private 
> > > *dev_priv,
> > >   PIPE_CONF_CHECK_I(hdmi_scrambling);
> > >   PIPE_CONF_CHECK_I(hdmi_high_tmds_clock_ratio);
> > >   PIPE_CONF_CHECK_I(has_infoframe);
> > > + PIPE_CONF_CHECK_I(hdmi_output);
> > >   
> > >   PIPE_CONF_CHECK_I(has_audio);
> > >   
> > > diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> > > b/drivers/gpu/drm/i915/intel_drv.h
> > > index 1727350..38fe56c 100644
> > > --- a/drivers/gpu/drm/i915/intel_drv.h
> > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > @@ -780,6 +780,9 @@ struct intel_crtc_state {
> > >   
> > >   /* HDMI High TMDS char rate ratio */
> > >   bool hdmi_high_tmds_clock_ratio;
> > > +
> > > + /* HDMI output type */
> > > + enum drm_hdmi_output_type hdmi_output;
> > >   };
> > >   
> > >   struct intel_crtc {
> > > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> > > b/drivers/gpu/drm/i915/intel_hdmi.c
> > > index 170abc4..22da5cd 100644
> > > --- a/drivers/gpu/drm/i915/intel_hdmi.c
> > > +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> > > @@ -1317,7 +1317,8 @@ intel_hdmi_mode_valid(struct drm_connector 
> > > *connector,
> > >   return status;
> > >   }
> > >   
> > > -static bool hdmi_12bpc_possible(struct intel_crtc_state *crtc_state)
> > > +static bool hdmi_12bpc_possible(struct intel_crtc_state *crtc_state,
> > > + enum drm_hdmi_output_type hdmi_out)
> > >   {
> > >   struct drm_i915_private *dev_priv =
> > >   to_i915(crtc_state->base.crtc->dev);
> > > @@ -1329,6 +1330,16 @@ static bool hdmi_12bpc_possible(struct 
> > > intel_crtc_state *crtc_state)
> > >   if (HAS_GMCH_DISPLAY(dev_priv))
> > >   return false;
> > >   
> > > + if (hdmi_out == DRM_HDMI_OUTPUT_YCBCR422) {
> > > + /*
> > > +  * HDMI spec says YCBCR422 is 12bpc, but its not a deep
> > > +  * color format. So respect the spec, and not allow this
> > > +  * to be deep color
> > > +  */
> > > + DRM_DEBUG_KMS("Not allowing deep color for YCBCR422 output\n");
> > > + return false;
> > > + }
> > > +
> > 
> > I suppose this is about the remark in section 6.2.4 of the HDMI 1.4 spec. 
> > If I'm
> > interpreting that correctly, the relevant information for us is that the 
> > TMDS
> > clock doesn't need to be multiplied by 1.5, unlike other 12 bpc scenarios.
> > 
> > To me it seems misleading to say 12 bpc is not possible in that case. I'm
> > wondering if it makes more sense to split this in two parts:
> > 
> >   (i)  What is the TMDS clock scaling for a given output format?
> >   (ii) Is the format and scaled TMDS clock supported by the source and the 
> > sink?
> 
> My interpretation of the spec was YCBCR422 is a 12 bit encoding scheme, 
> but its not a deep color mode (I guess that's what Ville also thought)

What is the definition of deep color? Section 6.2.4 of HDMI 1.4 says "YCBCR
4:2:2 is also 36-bit mode but does not require the further use of the Deep Color
modes described in section 6.5.2 and 6.5.3." Looking at those sections, I
believe the only relevant bit for the driver is whether to change the TMDS
clock. Is there something I'm missing?

> In I915, 12_bpc is always considered as deep color mode case, whereas I 
> have seen EDIDs which indicate support for YCBCR422 but they do not 
> indicate deep color support.

I see two issues here. One is that we have a function that is call
hdmi_12bpc_possible() and 

[Bug 99553] Tracker bug for runnning OpenCL applications on Clover

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99553

--- Comment #14 from Luke A. Guest  ---
Added https://bugs.freedesktop.org/show_bug.cgi?id=101594

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

[Bug 101594] Blender doesn't detect OpenCL with Clover

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101594

Bug ID: 101594
   Summary: Blender doesn't detect OpenCL with Clover
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: lagu...@archeia.com
QA Contact: dri-devel@lists.freedesktop.org

Cannot use Blender Cycles with Clover on AMD GPU's, tested with R9 390 - Hawaii
Pro

Steps:

1) Load Blender
2) File -> User preferences -> System -> Cycles computer device = None

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

Re: [PATCH 2/9] drm/amdgpu: Add vis_vramlimit module parameter

[Christian König]

Am 23.06.2017 um 19:39 schrieb John Brooks:

Allow specifying a limit on visible VRAM via a module parameter. This is
helpful for testing performance under visible VRAM pressure.

Signed-off-by: John Brooks 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 +
  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 4 
  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 8 
  3 files changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index c407d2d..fe73633 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -74,6 +74,7 @@
   */
  extern int amdgpu_modeset;
  extern int amdgpu_vram_limit;
+extern int amdgpu_vis_vram_limit;
  extern int amdgpu_gart_size;
  extern int amdgpu_moverate;
  extern int amdgpu_benchmarking;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 4c7c262..a14f458 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -73,6 +73,7 @@
  #define KMS_DRIVER_PATCHLEVEL 0
  
  int amdgpu_vram_limit = 0;

+int amdgpu_vis_vram_limit = 0;
  int amdgpu_gart_size = -1; /* auto */
  int amdgpu_moverate = -1; /* auto */
  int amdgpu_benchmarking = 0;
@@ -119,6 +120,9 @@ int amdgpu_lbpw = -1;
  MODULE_PARM_DESC(vramlimit, "Restrict VRAM for testing, in megabytes");
  module_param_named(vramlimit, amdgpu_vram_limit, int, 0600);
  
+MODULE_PARM_DESC(vis_vramlimit, "Restrict visible VRAM for testing, in megabytes");

+module_param_named(vis_vramlimit, amdgpu_vis_vram_limit, int, 0444);
+
  MODULE_PARM_DESC(gartsize, "Size of PCIE/IGP gart to setup in megabytes (32, 64, 
etc., -1 = auto)");
  module_param_named(gartsize, amdgpu_gart_size, int, 0600);
  
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c

index c9b131b..0676a78 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1095,6 +1095,7 @@ static struct ttm_bo_driver amdgpu_bo_driver = {
  int amdgpu_ttm_init(struct amdgpu_device *adev)
  {
int r;
+   u64 vis_vram_limit;
  
  	r = amdgpu_ttm_global_init(adev);

if (r) {
@@ -1118,6 +1119,13 @@ int amdgpu_ttm_init(struct amdgpu_device *adev)
DRM_ERROR("Failed initializing VRAM heap.\n");
return r;
}
+
+   /* Reduce size of CPU-visible VRAM if requested */
+   vis_vram_limit = amdgpu_vis_vram_limit * 1024 * 1024;


You need a 64bit cast here, otherwise you can get an overrun.

Apart from that the patch is Reviewed-by: Christian König 
.


Regards,
Christian.


+   if (amdgpu_vis_vram_limit > 0 &&
+   vis_vram_limit <= adev->mc.visible_vram_size)
+   adev->mc.visible_vram_size = vis_vram_limit;
+
/* Change the size here instead of the init above so only lpfn is 
affected */
amdgpu_ttm_set_active_vram_size(adev, adev->mc.visible_vram_size);
  



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

[Bug 99553] Tracker bug for runnning OpenCL applications on Clover

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99553

--- Comment #13 from Luke A. Guest  ---
Doesn't seem to be.

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

Re: [PATCH v2 4/4] drm/tinydrm: Add RePaper e-ink driver

[Daniel Vetter]

On Thu, Jun 08, 2017 at 05:14:35PM +0200, Noralf Trønnes wrote:
> This adds support for the Pervasive Displays RePaper branded displays.
> The controller code is taken from the userspace driver available
> through repaper.org. Only the V231 film is supported since the others
> are EOL.
> 
> Signed-off-by: Noralf Trønnes 

I took a look, and besides the tinydrm issues we've capture already this
all looks reasonable.

Acked-by: Daniel Vetter 

Yes I'm trying once more to sign you up for drm-misc commit rights, hence
not pushing ...
-Daniel
> ---
>  MAINTAINERS   |6 +
>  drivers/gpu/drm/tinydrm/Kconfig   |   12 +
>  drivers/gpu/drm/tinydrm/Makefile  |1 +
>  drivers/gpu/drm/tinydrm/repaper.c | 1095 
> +
>  4 files changed, 1114 insertions(+)
>  create mode 100644 drivers/gpu/drm/tinydrm/repaper.c
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 757d487..800afa2 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4446,6 +4446,12 @@ M: Dave Airlie 
>  S:   Odd Fixes
>  F:   drivers/gpu/drm/mgag200/
>  
> +DRM DRIVER FOR PERVASIVE DISPLAYS REPAPER PANELS
> +M:   Noralf Trønnes 
> +S:   Maintained
> +F:   drivers/gpu/drm/tinydrm/repaper.c
> +F:   Documentation/devicetree/bindings/display/repaper.txt
> +
>  DRM DRIVER FOR RAGE 128 VIDEO CARDS
>  S:   Orphan / Obsolete
>  F:   drivers/gpu/drm/r128/
> diff --git a/drivers/gpu/drm/tinydrm/Kconfig b/drivers/gpu/drm/tinydrm/Kconfig
> index 3504c53..9596e44 100644
> --- a/drivers/gpu/drm/tinydrm/Kconfig
> +++ b/drivers/gpu/drm/tinydrm/Kconfig
> @@ -19,3 +19,15 @@ config TINYDRM_MI0283QT
>   help
> DRM driver for the Multi-Inno MI0283QT display panel
> If M is selected the module will be called mi0283qt.
> +
> +config TINYDRM_REPAPER
> + tristate "DRM support for Pervasive Displays RePaper panels (V231)"
> + depends on DRM_TINYDRM && SPI
> + help
> +   DRM driver for the following Pervasive Displays panels:
> +   1.44" TFT EPD Panel (E1144CS021)
> +   1.90" TFT EPD Panel (E1190CS021)
> +   2.00" TFT EPD Panel (E2200CS021)
> +   2.71" TFT EPD Panel (E2271CS021)
> +
> +   If M is selected the module will be called repaper.
> diff --git a/drivers/gpu/drm/tinydrm/Makefile 
> b/drivers/gpu/drm/tinydrm/Makefile
> index 7a3604c..95bb4d4 100644
> --- a/drivers/gpu/drm/tinydrm/Makefile
> +++ b/drivers/gpu/drm/tinydrm/Makefile
> @@ -5,3 +5,4 @@ obj-$(CONFIG_TINYDRM_MIPI_DBI)+= mipi-dbi.o
>  
>  # Displays
>  obj-$(CONFIG_TINYDRM_MI0283QT)   += mi0283qt.o
> +obj-$(CONFIG_TINYDRM_REPAPER)+= repaper.o
> diff --git a/drivers/gpu/drm/tinydrm/repaper.c 
> b/drivers/gpu/drm/tinydrm/repaper.c
> new file mode 100644
> index 000..3343d3f
> --- /dev/null
> +++ b/drivers/gpu/drm/tinydrm/repaper.c
> @@ -0,0 +1,1095 @@
> +/*
> + * DRM driver for Pervasive Displays RePaper branded e-ink panels
> + *
> + * Copyright 2013-2017 Pervasive Displays, Inc.
> + * Copyright 2017 Noralf Trønnes
> + *
> + * The driver supports:
> + * Material Film: Aurora Mb (V231)
> + * Driver IC: G2 (eTC)
> + *
> + * The controller code was taken from the userspace driver:
> + * https://github.com/repaper/gratis
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +#define REPAPER_RID_G2_COG_ID0x12
> +
> +enum repaper_model {
> + E1144CS021 = 1,
> + E1190CS021,
> + E2200CS021,
> + E2271CS021,
> +};
> +
> +enum repaper_stage { /* Image pixel -> Display pixel */
> + REPAPER_COMPENSATE,  /* B -> W, W -> B (Current Image) */
> + REPAPER_WHITE,   /* B -> N, W -> W (Current Image) */
> + REPAPER_INVERSE, /* B -> N, W -> B (New Image) */
> + REPAPER_NORMAL   /* B -> B, W -> W (New Image) */
> +};
> +
> +enum repaper_epd_border_byte {
> + REPAPER_BORDER_BYTE_NONE,
> + REPAPER_BORDER_BYTE_ZERO,
> + REPAPER_BORDER_BYTE_SET,
> +};
> +
> +struct repaper_epd {
> + struct tinydrm_device tinydrm;
> + struct spi_device *spi;
> +
> + struct gpio_desc *panel_on;
> + struct gpio_desc *border;
> + struct gpio_desc *discharge;
> + struct gpio_desc *reset;
> + struct gpio_desc *busy;
> +
> + struct thermal_zone_device *thermal;
> +
> + unsigned int height;
> + unsigned int width;
> + unsigned int bytes_per_scan;
> + const u8 *channel_select;
> + unsigned int stage_time;
> + unsigned int factored_stage_time;
> + bool middle_scan;
> + bool pre_border_byte;
> + enum repaper_epd_border_byte border_byte;
> 

Re: [PATCH 2/9] drm/amdgpu: Add vis_vramlimit module parameter

[Michel Dänzer]

On 24/06/17 02:39 AM, John Brooks wrote:
> Allow specifying a limit on visible VRAM via a module parameter. This is
> helpful for testing performance under visible VRAM pressure.
> 
> Signed-off-by: John Brooks 

Reviewed-by: Michel Dänzer 


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

Re: clean up and modularize arch dma_mapping interface V2

[Christoph Hellwig]

On Sat, Jun 24, 2017 at 10:36:56AM -0500, Benjamin Herrenschmidt wrote:
> I think we still need to do it. For example we have a bunch new "funky"
> cases.

I have no plan to do away with the selection - I just want a better
interface than the current one.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH libdrm] amdgpu: update the exported always on CU bitmap

[Flora Cui]

keep cu_ao_mask unchanged for backward compatibility.

Change-Id: I9f497aadd309977468e246fea333b392c0150276
Signed-off-by: Flora Cui 
---
This patch should be landed after the kmd patch upsteam. right?
 amdgpu/amdgpu.h  | 2 ++
 amdgpu/amdgpu_gpu_info.c | 1 +
 include/drm/amdgpu_drm.h | 3 +++
 3 files changed, 6 insertions(+)

diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h
index b6779f9..cc80493 100644
--- a/amdgpu/amdgpu.h
+++ b/amdgpu/amdgpu.h
@@ -486,7 +486,9 @@ struct amdgpu_gpu_info {
uint32_t pa_sc_raster_cfg1[4];
/* CU info */
uint32_t cu_active_number;
+   /* NOTE: cu_ao_mask is INVALID, DON'T use it */
uint32_t cu_ao_mask;
+   uint32_t cu_ao_bitmap[4][4];
uint32_t cu_bitmap[4][4];
/* video memory type info*/
uint32_t vram_type;
diff --git a/amdgpu/amdgpu_gpu_info.c b/amdgpu/amdgpu_gpu_info.c
index 34f77be..7a5feb9 100644
--- a/amdgpu/amdgpu_gpu_info.c
+++ b/amdgpu/amdgpu_gpu_info.c
@@ -230,6 +230,7 @@ drm_private int 
amdgpu_query_gpu_info_init(amdgpu_device_handle dev)
 
dev->info.cu_active_number = dev->dev_info.cu_active_number;
dev->info.cu_ao_mask = dev->dev_info.cu_ao_mask;
+   memcpy(>info.cu_ao_bitmap[0][0], 
>dev_info.cu_ao_bitmap[0][0], sizeof(dev->info.cu_ao_bitmap));
memcpy(>info.cu_bitmap[0][0], >dev_info.cu_bitmap[0][0], 
sizeof(dev->info.cu_bitmap));
 
/* TODO: info->max_quad_shader_pipes is not set */
diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
index df250de..05c4e72 100644
--- a/include/drm/amdgpu_drm.h
+++ b/include/drm/amdgpu_drm.h
@@ -832,6 +832,7 @@ struct drm_amdgpu_info_device {
__u64 max_memory_clock;
/* cu information */
__u32 cu_active_number;
+   /* NOTE: cu_ao_mask is INVALID, DON'T use it */
__u32 cu_ao_mask;
__u32 cu_bitmap[4][4];
/** Render backend pipe mask. One render backend is CB+DB. */
@@ -886,6 +887,8 @@ struct drm_amdgpu_info_device {
/* max gs wavefront per vgt*/
__u32 max_gs_waves_per_vgt;
__u32 _pad1;
+   /* always on cu bitmap */
+   __u32 cu_ao_bitmap[4][4];
 };
 
 struct drm_amdgpu_info_hw_ip {
-- 
2.7.4

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

Re: [PATCH 7/9] drm/amdgpu: Throttle visible VRAM moves separately

[Michel Dänzer]

On 24/06/17 02:39 AM, John Brooks wrote:
> The BO move throttling code is designed to allow VRAM to fill quickly if it
> is relatively empty. However, this does not take into account situations
> where the visible VRAM is smaller than total VRAM, and total VRAM may not
> be close to full but the visible VRAM segment is under pressure. In such
> situations, visible VRAM would experience unrestricted swapping and
> performance would drop.
> 
> Add a separate counter specifically for moves involving visible VRAM, and
> check it before moving BOs there.
> 
> Fixes: 95844d20ae02 (drm/amdgpu: throttle buffer migrations at CS using a 
> fixed MBps limit (v2))
> Signed-off-by: John Brooks 

Something like this patch is definitely needed, good catch.

However, as is one issue is that it incurs CPU overhead even when all of
VRAM is CPU visible. Can that be avoided somehow?


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

Re: [PATCH v2 3/4] drm/tinydrm: Add tinydrm_xrgb8888_to_gray8() helper

[Daniel Vetter]

On Thu, Jun 08, 2017 at 05:14:34PM +0200, Noralf Trønnes wrote:
> Drm has no monochrome or greyscale support so add a conversion
> from the common format XR24.
> 
> Also reorder includes into the common order.
> 
> Signed-off-by: Noralf Trønnes 
> ---
>  drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c | 74 
> +-
>  include/drm/tinydrm/tinydrm-helpers.h  |  1 +
>  2 files changed, 73 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c 
> b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
> index d4cda33..75808bb 100644
> --- a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
> +++ b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
> @@ -7,13 +7,15 @@
>   * (at your option) any later version.
>   */
>  
> -#include 
> -#include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
>  
> +#include 
> +#include 
> +
>  static unsigned int spi_max;
>  module_param(spi_max, uint, 0400);
>  MODULE_PARM_DESC(spi_max, "Set a lower SPI max transfer size");
> @@ -181,6 +183,74 @@ void tinydrm_xrgb_to_rgb565(u16 *dst, void *vaddr,
>  EXPORT_SYMBOL(tinydrm_xrgb_to_rgb565);
>  
>  /**
> + * tinydrm_xrgb_to_gray8 - Convert XRGB to grayscale
> + * @dst: 8-bit grayscale destination buffer
> + * @fb: DRM framebuffer
> + *
> + * Drm doesn't have native monochrome or grayscale support.
> + * Such drivers can announce the commonly supported XR24 format to userspace
> + * and use this function to convert to the native format.
> + *
> + * Monochrome drivers will use the most significant bit,
> + * where 1 means foreground color and 0 background color.
> + *
> + * ITU BT.601 is used for the RGB -> luma (brightness) conversion.
> + *
> + * Returns:
> + * Zero on success, negative error code on failure.
> + */
> +int tinydrm_xrgb_to_gray8(u8 *dst, struct drm_framebuffer *fb)

I think it's ok to use this for backwards compat reasons with userspace
that simply expects xrgb, but adding monochrome fourcc codes to drm
isn't hard, and I think would be better to do that here.

There's also my comment from earlier that too much of tinydrm is in
tinydrm, and maybe we should move some of it out (we already have
tinydrm_xrgb_to_rgb565). But looks ok otherwise.

Acked-by: Daniel Vetter 

Daniel


> +{
> + struct drm_gem_cma_object *cma_obj = drm_fb_cma_get_gem_obj(fb, 0);
> + struct dma_buf_attachment *import_attach = cma_obj->base.import_attach;
> + unsigned int x, y, pitch = fb->pitches[0];
> + int ret = 0;
> + void *buf;
> + u32 *src;
> +
> + if (WARN_ON(fb->format->format != DRM_FORMAT_XRGB))
> + return -EINVAL;
> + /*
> +  * The cma memory is write-combined so reads are uncached.
> +  * Speed up by fetching one line at a time.
> +  */
> + buf = kmalloc(pitch, GFP_KERNEL);
> + if (!buf)
> + return -ENOMEM;
> +
> + if (import_attach) {
> + ret = dma_buf_begin_cpu_access(import_attach->dmabuf,
> +DMA_FROM_DEVICE);
> + if (ret)
> + goto err_free;
> + }
> +
> + for (y = 0; y < fb->height; y++) {
> + src = cma_obj->vaddr + (y * pitch);
> + memcpy(buf, src, pitch);
> + src = buf;
> + for (x = 0; x < fb->width; x++) {
> + u8 r = (*src & 0x00ff) >> 16;
> + u8 g = (*src & 0xff00) >> 8;
> + u8 b =  *src & 0x00ff;
> +
> + /* ITU BT.601: Y = 0.299 R + 0.587 G + 0.114 B */
> + *dst++ = (3 * r + 6 * g + b) / 10;
> + src++;
> + }
> + }
> +
> + if (import_attach)
> + ret = dma_buf_end_cpu_access(import_attach->dmabuf,
> +  DMA_FROM_DEVICE);
> +err_free:
> + kfree(buf);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL(tinydrm_xrgb_to_gray8);
> +
> +/**
>   * tinydrm_of_find_backlight - Find backlight device in device-tree
>   * @dev: Device
>   *
> diff --git a/include/drm/tinydrm/tinydrm-helpers.h 
> b/include/drm/tinydrm/tinydrm-helpers.h
> index 9b9b6cf..a6c387f 100644
> --- a/include/drm/tinydrm/tinydrm-helpers.h
> +++ b/include/drm/tinydrm/tinydrm-helpers.h
> @@ -43,6 +43,7 @@ void tinydrm_swab16(u16 *dst, void *vaddr, struct 
> drm_framebuffer *fb,
>  void tinydrm_xrgb_to_rgb565(u16 *dst, void *vaddr,
>   struct drm_framebuffer *fb,
>   struct drm_clip_rect *clip, bool swap);
> +int tinydrm_xrgb_to_gray8(u8 *dst, struct drm_framebuffer *fb);
>  
>  struct backlight_device *tinydrm_of_find_backlight(struct device *dev);
>  int tinydrm_enable_backlight(struct backlight_device *backlight);
> -- 
> 2.7.4
> 
> ___
> dri-devel mailing list
> 

Re: [PATCH 3/9] drm/amdgpu: Don't force BOs into visible VRAM for page faults

[Michel Dänzer]

On 24/06/17 02:39 AM, John Brooks wrote:
> There is no need for page faults to force BOs into visible VRAM if it's
> full, and the time it takes to do so is great enough to cause noticeable
> stuttering. Add GTT as a possible placement so that if visible VRAM is
> full, page faults move BOs to GTT instead of evicting other BOs from VRAM.
> 
> Signed-off-by: John Brooks 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 14 ++
>  1 file changed, 6 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> index 244a7d3..751bc05 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> @@ -981,10 +981,11 @@ int amdgpu_bo_fault_reserve_notify(struct 
> ttm_buffer_object *bo)
>  
>   /* hurrah the memory is not visible ! */
>   atomic64_inc(>num_vram_cpu_page_faults);
> - amdgpu_ttm_placement_from_domain(abo, AMDGPU_GEM_DOMAIN_VRAM);
> + amdgpu_ttm_placement_from_domain(abo, AMDGPU_GEM_DOMAIN_VRAM |
> +  AMDGPU_GEM_DOMAIN_GTT);
>   lpfn =  adev->mc.visible_vram_size >> PAGE_SHIFT;
>   for (i = 0; i < abo->placement.num_placement; i++) {
> - /* Force into visible VRAM */
> + /* Try to move the BO into visible VRAM */
>   if ((abo->placements[i].flags & TTM_PL_FLAG_VRAM) &&
>   (!abo->placements[i].lpfn ||
>abo->placements[i].lpfn > lpfn))
> @@ -993,16 +994,13 @@ int amdgpu_bo_fault_reserve_notify(struct 
> ttm_buffer_object *bo)
>   abo->placement.busy_placement = abo->placement.placement;
>   abo->placement.num_busy_placement = abo->placement.num_placement;
>   r = ttm_bo_validate(bo, >placement, false, false);
> - if (unlikely(r == -ENOMEM)) {
> - amdgpu_ttm_placement_from_domain(abo, AMDGPU_GEM_DOMAIN_GTT);
> - return ttm_bo_validate(bo, >placement, false, false);
> - } else if (unlikely(r != 0)) {
> + if (unlikely(r != 0))
>   return r;
> - }
>  
>   offset = bo->mem.start << PAGE_SHIFT;
>   /* this should never happen */
> - if ((offset + size) > adev->mc.visible_vram_size)
> + if (bo->mem.mem_type == TTM_PL_VRAM &&
> + (offset + size) > adev->mc.visible_vram_size)
>   return -EINVAL;
>  
>   return 0;
> 

AFAICT this is essentially the same as
https://patchwork.freedesktop.org/patch/156993/ . I retracted that patch
due to it causing Rally Dirt performance degradation for Marek.
Presumably other patches in this series compensate for that, but at the
least this patch should be moved to the end of the series.


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

Re: [PATCH v2 00/14] improve the fb_setcmap helper

[Daniel Vetter]

On Thu, Jun 22, 2017 at 08:06:23AM +0200, Peter Rosin wrote:
> Hi!
> 
> While trying to get CLUT support for the atmel_hlcdc driver, and
> specifically for the emulated fbdev interface, I received some
> push-back that my feeble in-driver attempts should be solved
> by the core. This is my attempt to do it right.
> 
> I have obviously not tested all of this with more than a compile,
> but patches 1 and 3 are enough to make the atmel-hlcdc driver
> do what I need (when patched to support CLUT modes). The rest is
> just lots of removals and cleanup made possible by the improved
> core.
> 
> Please test, I would not be surprised if I have fouled up some
> bit-manipulation somewhere in this mostly mechanical change...
> 
> Changes since v1:
> 
> - Rebased to next-20170621
> - Split 1/11 into a preparatory patch, a cleanup patch and then
>   the meat in 3/14.
> - Handle pseudo-palette for FB_VISUAL_TRUECOLOR.
> - Removed the empty .gamma_get/.gamma_set fb helpers from the
>   armada driver that I had somehow managed to ignore but which
>   0day found real quick.
> - Be less judgemental on drivers only providing .gamma_get and
>   .gamma_set, but no .load_lut. That's actually a valid thing
>   to do if you only need pseudo-palette for FB_VISUAL_TRUECOLOR.
> - Add a comment about colliding bitfields in the nouveau driver.
> - Remove gamma_set/gamma_get declarations from the radeon driver
>   (the definitions were removed in v1).

Ok some nits/questions on the first three, but in principle looks all ok I
think. The driver patches also look good (but I didn't yet carefully
review all the conversion). What we might want to do is entirely remove
driver's reliance on ->gamma_store (mostly amounts to in-lining the
load_lut functions) and only update ->gamma_store after gamma_set returned
successfully. But that's a bit more work.

Save/restoring it instead might be simpler to fix that bug, but since it's
pre-existing also ok as follow-up.

Cheers, Daniel

> 
> Cheers,
> peda
> 
> Peter Rosin (14):
>   drm/fb-helper: keep the .gamma_store updated in drm_fb_helper_setcmap
>   drm/fb-helper: remove drm_fb_helper_save_lut_atomic
>   drm/fb-helper: do a generic fb_setcmap helper in terms of crtc
> .gamma_set
>   drm: amd: remove dead code and pointless local lut storage
>   drm: armada: remove dead empty functions
>   drm: ast: remove dead code and pointless local lut storage
>   drm: cirrus: remove dead code and pointless local lut storage
>   drm: gma500: remove dead code and pointless local lut storage
>   drm: i915: remove dead code and pointless local lut storage
>   drm: mgag200: remove dead code and pointless local lut storage
>   drm: nouveau: remove dead code and pointless local lut storage
>   drm: radeon: remove dead code and pointless local lut storage
>   drm: stm: remove dead code and pointless local lut storage
>   drm: remove unused and redundant callbacks
> 
>  drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c  |  24 
>  drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h|   1 -
>  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c  |  27 ++---
>  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c  |  27 ++---
>  drivers/gpu/drm/amd/amdgpu/dce_v6_0.c   |  27 ++---
>  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c   |  27 ++---
>  drivers/gpu/drm/amd/amdgpu/dce_virtual.c|  23 
>  drivers/gpu/drm/armada/armada_crtc.c|  10 --
>  drivers/gpu/drm/armada/armada_crtc.h|   2 -
>  drivers/gpu/drm/armada/armada_fbdev.c   |   2 -
>  drivers/gpu/drm/ast/ast_drv.h   |   1 -
>  drivers/gpu/drm/ast/ast_fb.c|  20 
>  drivers/gpu/drm/ast/ast_mode.c  |  26 +
>  drivers/gpu/drm/cirrus/cirrus_drv.h |   8 --
>  drivers/gpu/drm/cirrus/cirrus_fbdev.c   |   2 -
>  drivers/gpu/drm/cirrus/cirrus_mode.c|  71 +++-
>  drivers/gpu/drm/drm_fb_helper.c | 164 
> +---
>  drivers/gpu/drm/gma500/framebuffer.c|  22 
>  drivers/gpu/drm/gma500/gma_display.c|  32 ++
>  drivers/gpu/drm/gma500/psb_intel_display.c  |   7 +-
>  drivers/gpu/drm/gma500/psb_intel_drv.h  |   1 -
>  drivers/gpu/drm/i915/intel_drv.h|   1 -
>  drivers/gpu/drm/i915/intel_fbdev.c  |  31 --
>  drivers/gpu/drm/mgag200/mgag200_drv.h   |   5 -
>  drivers/gpu/drm/mgag200/mgag200_fb.c|   2 -
>  drivers/gpu/drm/mgag200/mgag200_mode.c  |  62 +++
>  drivers/gpu/drm/nouveau/dispnv04/crtc.c |  26 ++---
>  drivers/gpu/drm/nouveau/nouveau_crtc.h  |   3 -
>  drivers/gpu/drm/nouveau/nouveau_fbcon.c |  22 
>  drivers/gpu/drm/nouveau/nv50_display.c  |  40 +++
>  drivers/gpu/drm/radeon/atombios_crtc.c  |   1 -
>  drivers/gpu/drm/radeon/radeon_connectors.c  |   7 +-
>  drivers/gpu/drm/radeon/radeon_display.c |  71 +---
>  drivers/gpu/drm/radeon/radeon_fb.c  |   2 -
>  drivers/gpu/drm/radeon/radeon_legacy_crtc.c |   1 -
>  drivers/gpu/drm/radeon/radeon_mode.h 

Re: [PATCH v2 03/14] drm/fb-helper: do a generic fb_setcmap helper in terms of crtc .gamma_set

[Daniel Vetter]

On Thu, Jun 22, 2017 at 12:22:10PM +0200, Peter Rosin wrote:
> This makes the redundant fb helpers .load_lut, .gamma_set and .gamma_get
> totally obsolete.
> 
> Signed-off-by: Peter Rosin 
> ---
>  drivers/gpu/drm/drm_fb_helper.c | 151 
> +---
>  1 file changed, 63 insertions(+), 88 deletions(-)
> 
> This is an alternative version rebased on top of Daniel's "fbdev helper
> locking rework and deferred setup" series.
> 
> And as noted by Daniel, .gamma_set does an atomic commit. Thus, the locks
> needs to be dropped and reacquired for each crtc. So, that is fixed here
> too. Doing it like this with a couple of individual alternative patches
> instead of sending a whole new series since the dependency on Daniel's
> series makes life somewhat difficult...
> 
> Cheers,
> peda
> 
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 4aceb59..aa025f1 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -1257,50 +1257,6 @@ void drm_fb_helper_set_suspend_unlocked(struct 
> drm_fb_helper *fb_helper,
>  }
>  EXPORT_SYMBOL(drm_fb_helper_set_suspend_unlocked);
>  
> -static int setcolreg(struct drm_crtc *crtc, u16 red, u16 green,
> -  u16 blue, u16 regno, struct fb_info *info)
> -{
> - struct drm_fb_helper *fb_helper = info->par;
> - struct drm_framebuffer *fb = fb_helper->fb;
> -
> - if (info->fix.visual == FB_VISUAL_TRUECOLOR) {
> - u32 *palette;
> - u32 value;
> - /* place color in psuedopalette */
> - if (regno > 16)
> - return -EINVAL;
> - palette = (u32 *)info->pseudo_palette;
> - red >>= (16 - info->var.red.length);
> - green >>= (16 - info->var.green.length);
> - blue >>= (16 - info->var.blue.length);
> - value = (red << info->var.red.offset) |
> - (green << info->var.green.offset) |
> - (blue << info->var.blue.offset);
> - if (info->var.transp.length > 0) {
> - u32 mask = (1 << info->var.transp.length) - 1;
> -
> - mask <<= info->var.transp.offset;
> - value |= mask;
> - }
> - palette[regno] = value;
> - return 0;
> - }
> -
> - /*
> -  * The driver really shouldn't advertise pseudo/directcolor
> -  * visuals if it can't deal with the palette.
> -  */
> - if (WARN_ON(!fb_helper->funcs->gamma_set ||
> - !fb_helper->funcs->gamma_get))
> - return -EINVAL;
> -
> - WARN_ON(fb->format->cpp[0] != 1);
> -
> - fb_helper->funcs->gamma_set(crtc, red, green, blue, regno);
> -
> - return 0;
> -}
> -
>  /**
>   * drm_fb_helper_setcmap - implementation for _ops.fb_setcmap
>   * @cmap: cmap to set
> @@ -1310,12 +1266,10 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap, 
> struct fb_info *info)
>  {
>   struct drm_fb_helper *fb_helper = info->par;
>   struct drm_device *dev = fb_helper->dev;
> - const struct drm_crtc_helper_funcs *crtc_funcs;
> - u16 *red, *green, *blue, *transp;
> + struct drm_modeset_acquire_ctx ctx;
>   struct drm_crtc *crtc;
>   u16 *r, *g, *b;
> - int i, j, rc = 0;
> - int start;
> + int i, ret = 0;
>  
>   if (oops_in_progress)
>   return -EBUSY;
> @@ -1329,61 +1283,82 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap, 
> struct fb_info *info)
>   return -EBUSY;
>   }
>  
> - drm_modeset_lock_all(dev);
> - for (i = 0; i < fb_helper->crtc_count; i++) {
> - crtc = fb_helper->crtc_info[i].mode_set.crtc;
> - crtc_funcs = crtc->helper_private;
> + drm_modeset_acquire_init(, 0);
>  
> - red = cmap->red;
> - green = cmap->green;
> - blue = cmap->blue;
> - transp = cmap->transp;
> - start = cmap->start;
> + for (i = 0; i < fb_helper->crtc_count; i++) {
> + if (info->fix.visual == FB_VISUAL_TRUECOLOR) {
> + u32 *palette;
> + int j;
>  
> - if (info->fix.visual != FB_VISUAL_TRUECOLOR) {
> - if (!crtc->gamma_size) {
> - rc = -EINVAL;
> - goto out;
> + if (cmap->start + cmap->len > 16) {
> + ret = -EINVAL;
> + break;
>   }
>  
> - if (cmap->start + cmap->len > crtc->gamma_size) {
> - rc = -EINVAL;
> - goto out;
> + palette = (u32 *)info->pseudo_palette;
> + for (j = 0; j < cmap->len; ++j) {
> + u16 red = cmap->red[j];
> + u16 green = cmap->green[j];
> + 

Re: [PATCH v2 01/14] drm/fb-helper: keep the .gamma_store updated in drm_fb_helper_setcmap

[Daniel Vetter]

On Thu, Jun 22, 2017 at 08:06:24AM +0200, Peter Rosin wrote:
> I think the gamma_store can end up invalid on error. But the way I read
> it, that can happen in drm_mode_gamma_set_ioctl as well, so why should
> this pesky legacy fbdev stuff be any better?
> 
> Signed-off-by: Peter Rosin 
> ---
>  drivers/gpu/drm/drm_fb_helper.c | 27 +++
>  1 file changed, 27 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 574af01..25315fb 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -1223,12 +1223,16 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap, 
> struct fb_info *info)
>   const struct drm_crtc_helper_funcs *crtc_funcs;
>   u16 *red, *green, *blue, *transp;
>   struct drm_crtc *crtc;
> + u16 *r, *g, *b;
>   int i, j, rc = 0;
>   int start;
>  
>   if (oops_in_progress)
>   return -EBUSY;
>  
> + if (cmap->start + cmap->len < cmap->start)
> + return -EINVAL;

Doesn't the fbdev core check this for us?

> +
>   drm_modeset_lock_all(dev);
>   if (!drm_fb_helper_is_bound(fb_helper)) {
>   drm_modeset_unlock_all(dev);
> @@ -1245,6 +1249,29 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct 
> fb_info *info)
>   transp = cmap->transp;
>   start = cmap->start;
>  
> + if (info->fix.visual != FB_VISUAL_TRUECOLOR) {

I think switching to a positive check of visual == PSEUDOCOLOR is a bit
clearer. Also this makes more sense once we move over to the main
gamma_set function, since as-is it's unclear that setcolreg only does
something for PSEUDOCOLOR. But interim I guess that's ok.
-Daniel

> + if (!crtc->gamma_size) {
> + rc = -EINVAL;
> + goto out;
> + }
> +
> + if (cmap->start + cmap->len > crtc->gamma_size) {
> + rc = -EINVAL;
> + goto out;
> + }
> +
> + r = crtc->gamma_store;
> + g = r + crtc->gamma_size;
> + b = g + crtc->gamma_size;
> +
> + memcpy(r + cmap->start, cmap->red,
> +cmap->len * sizeof(u16));
> + memcpy(g + cmap->start, cmap->green,
> +cmap->len * sizeof(u16));
> + memcpy(b + cmap->start, cmap->blue,
> +cmap->len * sizeof(u16));
> + }
> +
>   for (j = 0; j < cmap->len; j++) {
>   u16 hred, hgreen, hblue, htransp = 0x;
>  
> -- 
> 2.1.4
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [PATCH 6/9] drm/amdgpu: Set/clear CPU_ACCESS_REQUIRED flag on page fault and CS

[Michel Dänzer]

On 25/06/17 03:00 AM, Christian König wrote:
> Am 23.06.2017 um 19:39 schrieb John Brooks:
>> When the AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED flag is given by
>> userspace,
>> it should only be treated as a hint to initially place a BO somewhere CPU
>> accessible, rather than having a permanent effect on BO placement.
> 
> And that is a clear NAK from my side.
> 
> CPU_ACCESS_REQUIRED is a permanent limitation to where the buffer should
> be placed.

It really can't be more than a hint. The userspace driver cannot
reliably know ahead of time whether a BO will be accessed by the CPU at
all, let alone how often. A BO which incorrectly has this flag set
creates artificial pressure on CPU visible VRAM.


> Ignoring that and changing the IOCTL interface like this is clearly not
> acceptable.

I'd say it's more adapting the semantics of the flag to reality. :)


>> Instead of the flag being set in stone at BO creation, set the flag
>> when a page fault occurs so that it goes somewhere CPU-visible, and clear it
>> when the BO is requested by the GPU.

My idea was to only clear the flag when the BO is moved from GTT to
VRAM. That way, any BO which was ever accessed by the CPU since it was
last moved to VRAM will be preferably put in the CPU visible part of VRAM.

Not sure which way is better though.


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

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: Wait for pending modesets to complete before trying link training, v2.

[Maarten Lankhorst]

Op 14-06-17 om 15:44 schreef Ville Syrjälä:
> On Wed, Jun 14, 2017 at 11:08:42AM +0200, Maarten Lankhorst wrote:
>> The nonblocking modeset tests were failing on systems with a DP output,
>> because lijnk training could occur during the modeset.
>>
>> With normal modesets we're protected by the connection_mutex lock,
>> but nonblocking modesets drop locks before completing. To get around
>> that, check if the most recent crtc_state has a modeset, and if this
>> is the case, wait for all outstanding atomic updates on that crtc
>> to complete.
>>
>> This fixes the following spew when running nonblocking tests:
>> [ 1061.653778] [ cut here ]
>> [ 1061.653781] WARNING: CPU: 1 PID: 8165 at
>> drivers/gpu/drm/drm_irq.c:1217 drm_wait_one_vblank+0x165/0x1a0
>> [ 1061.653782] vblank not available on crtc 0, ret=-22
>> [ 1061.653783] Modules linked in: vgem snd_hda_intel i915
>> snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic
>> x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul
>> crc32_pclmul ghash_clmulni_intel snd_hda_codec snd_hwdep snd_hda_core
>> snd_pcm mei_me mei e1000e ptp pps_core i2c_hid [last unloaded: vgem]
>> [ 1061.653796] CPU: 1 PID: 8165 Comm: kworker/1:3 Tainted: G U  W
>> 4.10.0-rc1-CI-Custom_114+ #1
>> [ 1061.653797] Hardware name: GIGABYTE GB-BKi5A-7200/MFLP5AP-00, BIOS F1
>> 07/27/2016
>> [ 1061.653812] Workqueue: events i915_hpd_poll_init_work [i915]
>> [ 1061.653813] Call Trace:
>> [ 1061.653816]  dump_stack+0x67/0x92
>> [ 1061.653818]  __warn+0xc6/0xe0
>> [ 1061.653819]  warn_slowpath_fmt+0x4a/0x50
>> [ 1061.653820]  ? drm_vblank_get+0x74/0xc0
>> [ 1061.653821]  drm_wait_one_vblank+0x165/0x1a0
>> [ 1061.653823]  ? drm_dp_dpcd_write+0x16/0x20
>> [ 1061.653837]  ? intel_dp_set_link_train+0x44/0xe0 [i915]
>> [ 1061.653851]  intel_dp_check_link_status+0x113/0x1a0 [i915]
>> [ 1061.653864]  intel_dp_detect+0x5a1/0xa40 [i915]
>> [ 1061.653866]  drm_helper_hpd_irq_event+0x8d/0x110
>> [ 1061.653880]  i915_hpd_poll_init_work+0xab/0xd0 [i915]
>> [ 1061.653882]  process_one_work+0x1f4/0x6d0
>> [ 1061.653883]  ? process_one_work+0x16e/0x6d0
>> [ 1061.653885]  worker_thread+0x49/0x4a0
>> [ 1061.653886]  kthread+0x107/0x140
>> [ 1061.653888]  ? process_one_work+0x6d0/0x6d0
>> [ 1061.653889]  ? kthread_create_on_node+0x40/0x40
>> [ 1061.653891]  ret_from_fork+0x27/0x40
>> [ 1061.653892] ---[ end trace f6037618668d4cbc ]---
>> [ 1061.656353] [drm:intel_dp_set_idle_link_train [i915]] *ERROR* Timed out 
>> waiting for DP idle patterns
>>
>> Changes since v1:
>> - intel_dp_detect() now holds connection_mutex and has an acquire_ctx,
>>   rewrite patch to take advantage of it.
>>
>> Signed-off-by: Maarten Lankhorst 
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99272
>> Testcase: kms_atomic_transitions.1x-modeset-transitions-nonblocking
>> ---
>>  drivers/gpu/drm/i915/intel_dp.c | 72 
>> ++---
>>  1 file changed, 60 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_dp.c 
>> b/drivers/gpu/drm/i915/intel_dp.c
>> index 64fa774c855b..c7a66883e453 100644
>> --- a/drivers/gpu/drm/i915/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/intel_dp.c
>> @@ -4243,21 +4243,32 @@ static void
>>  intel_dp_check_link_status(struct intel_dp *intel_dp)
>>  {
>>  struct intel_encoder *intel_encoder = _to_dig_port(intel_dp)->base;
>> -struct drm_device *dev = intel_dp_to_dev(intel_dp);
>>  u8 link_status[DP_LINK_STATUS_SIZE];
>> +struct intel_connector *intel_connector = intel_dp->attached_connector;
>> +struct drm_crtc *crtc;
>>  
>> -WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex));
>> -
>> -if (!intel_dp_get_link_status(intel_dp, link_status)) {
>> -DRM_ERROR("Failed to get link status\n");
>> +crtc = intel_connector->base.state->crtc;
>> +if (!crtc)
>>  return;
>> -}
>>  
>> -if (!intel_encoder->base.crtc)
>> +WARN_ON(!drm_modeset_is_locked(>mutex));
>> +
>> +if (!crtc->state->active)
>>  return;
>>  
>> -if (!to_intel_crtc(intel_encoder->base.crtc)->active)
>> +if (drm_atomic_crtc_needs_modeset(crtc->state)) {
>> +int ret;
>> +
>> +/* wait for atomic modeset to complete */
>> +ret = drm_atomic_helper_wait_for_hw_done(crtc);
>> +if (ret < 0)
>> +DRM_ERROR("Waiting for hw_done timed out\n");
>> +}
>> +
>> +if (!intel_dp_get_link_status(intel_dp, link_status)) {
>> +DRM_ERROR("Failed to get link status\n");
>>  return;
>> +}
>>  
>>  /*
>>   * Validate the cached values of intel_dp->link_rate and
>> @@ -4291,7 +4302,6 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
>>  static bool
>>  intel_dp_short_pulse(struct intel_dp *intel_dp)
>>  {
>> -struct drm_device *dev = intel_dp_to_dev(intel_dp);
>>  struct intel_encoder *intel_encoder = 

Re: [PATCH v2 03/14] drm/fb-helper: do a generic fb_setcmap helper in terms of crtc .gamma_set

[Daniel Vetter]

On Thu, Jun 22, 2017 at 08:06:26AM +0200, Peter Rosin wrote:
> This makes the redundant fb helpers .load_lut, .gamma_set and .gamma_get
> totally obsolete.
> 
> Signed-off-by: Peter Rosin 
> ---
>  drivers/gpu/drm/drm_fb_helper.c | 154 
> 
>  1 file changed, 63 insertions(+), 91 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 7ade384..58eb045 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -1150,50 +1150,6 @@ void drm_fb_helper_set_suspend_unlocked(struct 
> drm_fb_helper *fb_helper,
>  }
>  EXPORT_SYMBOL(drm_fb_helper_set_suspend_unlocked);
>  
> -static int setcolreg(struct drm_crtc *crtc, u16 red, u16 green,
> -  u16 blue, u16 regno, struct fb_info *info)
> -{
> - struct drm_fb_helper *fb_helper = info->par;
> - struct drm_framebuffer *fb = fb_helper->fb;
> -
> - if (info->fix.visual == FB_VISUAL_TRUECOLOR) {
> - u32 *palette;
> - u32 value;
> - /* place color in psuedopalette */
> - if (regno > 16)
> - return -EINVAL;
> - palette = (u32 *)info->pseudo_palette;
> - red >>= (16 - info->var.red.length);
> - green >>= (16 - info->var.green.length);
> - blue >>= (16 - info->var.blue.length);
> - value = (red << info->var.red.offset) |
> - (green << info->var.green.offset) |
> - (blue << info->var.blue.offset);
> - if (info->var.transp.length > 0) {
> - u32 mask = (1 << info->var.transp.length) - 1;
> -
> - mask <<= info->var.transp.offset;
> - value |= mask;
> - }
> - palette[regno] = value;
> - return 0;
> - }
> -
> - /*
> -  * The driver really shouldn't advertise pseudo/directcolor
> -  * visuals if it can't deal with the palette.
> -  */
> - if (WARN_ON(!fb_helper->funcs->gamma_set ||
> - !fb_helper->funcs->gamma_get))
> - return -EINVAL;
> -
> - WARN_ON(fb->format->cpp[0] != 1);
> -
> - fb_helper->funcs->gamma_set(crtc, red, green, blue, regno);
> -
> - return 0;
> -}
> -
>  /**
>   * drm_fb_helper_setcmap - implementation for _ops.fb_setcmap
>   * @cmap: cmap to set
> @@ -1203,12 +1159,10 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap, 
> struct fb_info *info)
>  {
>   struct drm_fb_helper *fb_helper = info->par;
>   struct drm_device *dev = fb_helper->dev;
> - const struct drm_crtc_helper_funcs *crtc_funcs;
> - u16 *red, *green, *blue, *transp;
> + struct drm_modeset_acquire_ctx ctx;
>   struct drm_crtc *crtc;
>   u16 *r, *g, *b;
> - int i, j, rc = 0;
> - int start;
> + int i, ret;
>  
>   if (oops_in_progress)
>   return -EBUSY;
> @@ -1216,65 +1170,83 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap, 
> struct fb_info *info)
>   if (cmap->start + cmap->len < cmap->start)
>   return -EINVAL;
>  
> - drm_modeset_lock_all(dev);
> + drm_modeset_acquire_init(, 0);
> +retry:
> + ret = drm_modeset_lock_all_ctx(dev, );
> + if (ret)
> + goto out;
>   if (!drm_fb_helper_is_bound(fb_helper)) {
> - drm_modeset_unlock_all(dev);
> - return -EBUSY;
> + ret = -EBUSY;
> + goto out;
>   }
>  
>   for (i = 0; i < fb_helper->crtc_count; i++) {
> - crtc = fb_helper->crtc_info[i].mode_set.crtc;
> - crtc_funcs = crtc->helper_private;
> -
> - red = cmap->red;
> - green = cmap->green;
> - blue = cmap->blue;
> - transp = cmap->transp;
> - start = cmap->start;
> + if (info->fix.visual == FB_VISUAL_TRUECOLOR) {
> + u32 *palette;
> + int j;
>  
> - if (info->fix.visual != FB_VISUAL_TRUECOLOR) {
> - if (!crtc->gamma_size) {
> - rc = -EINVAL;
> + if (cmap->start + cmap->len > 16) {
> + ret = -EINVAL;
>   goto out;
>   }
>  
> - if (cmap->start + cmap->len > crtc->gamma_size) {
> - rc = -EINVAL;
> - goto out;
> + palette = (u32 *)info->pseudo_palette;
> + for (j = 0; j < cmap->len; ++j) {
> + u16 red = cmap->red[j];
> + u16 green = cmap->green[j];
> + u16 blue = cmap->blue[j];
> + u32 value;
> +
> + red >>= 16 - info->var.red.length;
> + green >>= 16 - info->var.green.length;
> +  

Re: [PATCH v2 02/14] drm/fb-helper: remove drm_fb_helper_save_lut_atomic

[Daniel Vetter]

On Thu, Jun 22, 2017 at 08:06:25AM +0200, Peter Rosin wrote:
> drm_fb_helper_save_lut_atomic is redundant since the .gamma_store is
> now always kept up to date by drm_fb_helper_setcmap.
> 
> Signed-off-by: Peter Rosin 

Also note that this is for kgdb support only and so likely very buggy
(since no one cried when we started to break kgdb support when switching
drivers to atomic).
-Daniel

> ---
>  drivers/gpu/drm/drm_fb_helper.c | 17 -
>  1 file changed, 17 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 25315fb..7ade384 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -229,22 +229,6 @@ int drm_fb_helper_remove_one_connector(struct 
> drm_fb_helper *fb_helper,
>  }
>  EXPORT_SYMBOL(drm_fb_helper_remove_one_connector);
>  
> -static void drm_fb_helper_save_lut_atomic(struct drm_crtc *crtc, struct 
> drm_fb_helper *helper)
> -{
> - uint16_t *r_base, *g_base, *b_base;
> - int i;
> -
> - if (helper->funcs->gamma_get == NULL)
> - return;
> -
> - r_base = crtc->gamma_store;
> - g_base = r_base + crtc->gamma_size;
> - b_base = g_base + crtc->gamma_size;
> -
> - for (i = 0; i < crtc->gamma_size; i++)
> - helper->funcs->gamma_get(crtc, _base[i], _base[i], 
> _base[i], i);
> -}
> -
>  static void drm_fb_helper_restore_lut_atomic(struct drm_crtc *crtc)
>  {
>   uint16_t *r_base, *g_base, *b_base;
> @@ -285,7 +269,6 @@ int drm_fb_helper_debug_enter(struct fb_info *info)
>   if (drm_drv_uses_atomic_modeset(mode_set->crtc->dev))
>   continue;
>  
> - drm_fb_helper_save_lut_atomic(mode_set->crtc, helper);
>   funcs->mode_set_base_atomic(mode_set->crtc,
>   mode_set->fb,
>   mode_set->x,
> -- 
> 2.1.4
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [PATCH] DRM: Fix an incorrectly formatted table

[Daniel Vetter]

On Fri, Jun 23, 2017 at 02:00:13PM -0600, Jonathan Corbet wrote:
> The "supported input formats" table in dw_hdmi.h was incorrectly formatted,
> using "+" signs where "|" needs to be.  That, in turn, causes the PDF build
> to fail.
> 
> Fixes: def23aa7e9821a3dfe3fb7b139dd0229a89fdeb0

I fixed the citation above to follow guidelines (yes we have a dim cite
cmd in our maintainer tooling for this) and applied to drm-misc for 4.13.

Thanks, Daniel

> Signed-off-by: Jonathan Corbet 
> ---
>  include/drm/bridge/dw_hdmi.h | 70 
> ++--
>  1 file changed, 35 insertions(+), 35 deletions(-)
> 
> diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
> index ed599bea3f6c..c00671fef53c 100644
> --- a/include/drm/bridge/dw_hdmi.h
> +++ b/include/drm/bridge/dw_hdmi.h
> @@ -22,56 +22,56 @@ struct dw_hdmi;
>   * 48bit bus.
>   *
>   * 
> +--+--+--+
> - * + Format Name  + Format Code  + Encodings 
>+
> + * | Format Name  | Format Code  | Encodings 
>|
>   * 
> +--+--+--+
> - * + RGB 4:4:4 8bit   + ``MEDIA_BUS_FMT_RGB888_1X24``+ 
> ``V4L2_YCBCR_ENC_DEFAULT``   +
> + * | RGB 4:4:4 8bit   | ``MEDIA_BUS_FMT_RGB888_1X24``| 
> ``V4L2_YCBCR_ENC_DEFAULT``   |
>   * 
> +--+--+--+
> - * + RGB 4:4:4 10bits + ``MEDIA_BUS_FMT_RGB101010_1X30`` + 
> ``V4L2_YCBCR_ENC_DEFAULT``   +
> + * | RGB 4:4:4 10bits | ``MEDIA_BUS_FMT_RGB101010_1X30`` | 
> ``V4L2_YCBCR_ENC_DEFAULT``   |
>   * 
> +--+--+--+
> - * + RGB 4:4:4 12bits + ``MEDIA_BUS_FMT_RGB121212_1X36`` + 
> ``V4L2_YCBCR_ENC_DEFAULT``   +
> + * | RGB 4:4:4 12bits | ``MEDIA_BUS_FMT_RGB121212_1X36`` | 
> ``V4L2_YCBCR_ENC_DEFAULT``   |
>   * 
> +--+--+--+
> - * + RGB 4:4:4 16bits + ``MEDIA_BUS_FMT_RGB161616_1X48`` + 
> ``V4L2_YCBCR_ENC_DEFAULT``   +
> + * | RGB 4:4:4 16bits | ``MEDIA_BUS_FMT_RGB161616_1X48`` | 
> ``V4L2_YCBCR_ENC_DEFAULT``   |
>   * 
> +--+--+--+
> - * + YCbCr 4:4:4 8bit + ``MEDIA_BUS_FMT_YUV8_1X24``  + 
> ``V4L2_YCBCR_ENC_601``   +
> - * +  +  + or 
> ``V4L2_YCBCR_ENC_709``+
> - * +  +  + or 
> ``V4L2_YCBCR_ENC_XV601``  +
> - * +  +  + or 
> ``V4L2_YCBCR_ENC_XV709``  +
> + * | YCbCr 4:4:4 8bit | ``MEDIA_BUS_FMT_YUV8_1X24``  | 
> ``V4L2_YCBCR_ENC_601``   |
> + * |  |  | or 
> ``V4L2_YCBCR_ENC_709``|
> + * |  |  | or 
> ``V4L2_YCBCR_ENC_XV601``  |
> + * |  |  | or 
> ``V4L2_YCBCR_ENC_XV709``  |
>   * 
> +--+--+--+
> - * + YCbCr 4:4:4 10bits   + ``MEDIA_BUS_FMT_YUV10_1X30`` + 
> ``V4L2_YCBCR_ENC_601``   +
> - * +  +  + or 
> ``V4L2_YCBCR_ENC_709``+
> - * +  +  + or 
> ``V4L2_YCBCR_ENC_XV601``  +
> - * +  +  + or 
> ``V4L2_YCBCR_ENC_XV709``  +
> + * | YCbCr 4:4:4 10bits   | ``MEDIA_BUS_FMT_YUV10_1X30`` | 
> ``V4L2_YCBCR_ENC_601``   |
> + * |  |  | or 
> ``V4L2_YCBCR_ENC_709``|
> + * |  |  | or 
> ``V4L2_YCBCR_ENC_XV601``  |
> + * |  |  | or 
> ``V4L2_YCBCR_ENC_XV709``  |
>   * 
> +--+--+--+
> - * + YCbCr 4:4:4 12bits   + ``MEDIA_BUS_FMT_YUV12_1X36`` + 
> ``V4L2_YCBCR_ENC_601``   +
> - * +  +  + or 
> ``V4L2_YCBCR_ENC_709``+
> - * +  +  + or 
> ``V4L2_YCBCR_ENC_XV601``  +
> - * +  +  + or 
> ``V4L2_YCBCR_ENC_XV709``  +
> + * | YCbCr 4:4:4 12bits   | ``MEDIA_BUS_FMT_YUV12_1X36`` | 
> ``V4L2_YCBCR_ENC_601``   |
> + * |  |  | or 
> ``V4L2_YCBCR_ENC_709``|
> + * |  |  | or 
> ``V4L2_YCBCR_ENC_XV601``  |

[Bug 101484] [regression, bisected] Steam fails to render content, if mesa is compiled with -O2 -march=haswell

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101484

--- Comment #11 from Michel Dänzer  ---
It could be either a compiler bug, or a Mesa bug which only manifests itself
with certain compiler options.

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

[Bug 101484] [regression, bisected] Steam fails to render content, if mesa is compiled with -O2 -march=haswell

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=101484

--- Comment #10 from Eric Engestrom  ---
Looks to me like you're hitting a compiler optimisation bug; what compiler
() are you using?
Can you try another one? For instance, if you were using gcc, `CC=clang
CXX=clang++ ./configure` should do it.

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

Re: [PATCH 6/7] drm/tilcdc: clean up ifdef hacks around iowrite64

[Jyri Sarha]

On 06/22/17 19:48, Logan Gunthorpe wrote:
> Now that we can expect iowrite64 to always exist the hack is no longer
> necessary so we just call iowrite64 directly.
> 
> Signed-off-by: Logan Gunthorpe 
> Cc: Jyri Sarha 
> Cc: Tomi Valkeinen 
> Cc: David Airlie 

Acked-by: Jyri Sarha 

And thanks!

> ---
>  drivers/gpu/drm/tilcdc/tilcdc_regs.h | 6 --
>  1 file changed, 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_regs.h 
> b/drivers/gpu/drm/tilcdc/tilcdc_regs.h
> index e9ce725698a9..0b901405f30a 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_regs.h
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_regs.h
> @@ -133,13 +133,7 @@ static inline void tilcdc_write64(struct drm_device 
> *dev, u32 reg, u64 data)
>   struct tilcdc_drm_private *priv = dev->dev_private;
>   void __iomem *addr = priv->mmio + reg;
>  
> -#ifdef iowrite64
>   iowrite64(data, addr);
> -#else
> - __iowmb();
> - /* This compiles to strd (=64-bit write) on ARM7 */
> - *(u64 __force *)addr = __cpu_to_le64(data);
> -#endif
>  }
>  
>  static inline u32 tilcdc_read(struct drm_device *dev, u32 reg)
> 

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