[Bug 104285] Euro Truck Simulator 2 and American Truck Simulator artifacts (Mesa 17.3, AMD R9 280X)

[bugzilla-daemon]

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

--- Comment #10 from megaphant...@bol.com.br ---
Seems good now:

Radeon HD 7850
kernel 4.16.3
mesa 18.0.1
LLVM 6.0.0

-- 
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 4/4] drm/vc4: Add parameter for syncobj support

[Stefan Schake]

This allows runtime detection of syncobj submission support.

Signed-off-by: Stefan Schake 
---
 drivers/gpu/drm/vc4/vc4_drv.c | 1 +
 include/uapi/drm/vc4_drm.h| 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index 806c8004b793..4e2ae2a9a164 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -102,6 +102,7 @@ static int vc4_get_param_ioctl(struct drm_device *dev, void 
*data,
case DRM_VC4_PARAM_SUPPORTS_FIXED_RCL_ORDER:
case DRM_VC4_PARAM_SUPPORTS_MADVISE:
case DRM_VC4_PARAM_SUPPORTS_PERFMON:
+   case DRM_VC4_PARAM_SUPPORTS_SYNCOBJ:
args->value = true;
break;
default:
diff --git a/include/uapi/drm/vc4_drm.h b/include/uapi/drm/vc4_drm.h
index 3a2ef9b5b60b..6f81cf05f7a3 100644
--- a/include/uapi/drm/vc4_drm.h
+++ b/include/uapi/drm/vc4_drm.h
@@ -338,6 +338,7 @@ struct drm_vc4_get_hang_state {
 #define DRM_VC4_PARAM_SUPPORTS_FIXED_RCL_ORDER 6
 #define DRM_VC4_PARAM_SUPPORTS_MADVISE 7
 #define DRM_VC4_PARAM_SUPPORTS_PERFMON 8
+#define DRM_VC4_PARAM_SUPPORTS_SYNCOBJ 9
 
 struct drm_vc4_get_param {
__u32 param;
-- 
2.14.1

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

[PATCH 1/4] drm/vc4: Enable syncobj support

[Stefan Schake]

This doesn't require any additional functionality from the driver but
is a prerequisite to userland calling the syncobj ioctls.

Signed-off-by: Stefan Schake 
---
 drivers/gpu/drm/vc4/vc4_drv.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index 94b99c90425a..806c8004b793 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -175,7 +175,8 @@ static struct drm_driver vc4_drm_driver = {
DRIVER_GEM |
DRIVER_HAVE_IRQ |
DRIVER_RENDER |
-   DRIVER_PRIME),
+   DRIVER_PRIME |
+   DRIVER_SYNCOBJ),
.lastclose = drm_fb_helper_lastclose,
.open = vc4_open,
.postclose = vc4_close,
-- 
2.14.1

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

[PATCH 3/4] drm/vc4: Export fence through syncobj

[Stefan Schake]

Allow specifying a syncobj on render job submission where we store the
fence for the job. This gives userland flexible access to the fence.

Signed-off-by: Stefan Schake 
---
 drivers/gpu/drm/vc4/vc4_gem.c | 38 +++---
 include/uapi/drm/vc4_drm.h| 13 +
 2 files changed, 48 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_gem.c b/drivers/gpu/drm/vc4/vc4_gem.c
index 232363488125..b39515a4ddcb 100644
--- a/drivers/gpu/drm/vc4/vc4_gem.c
+++ b/drivers/gpu/drm/vc4/vc4_gem.c
@@ -656,7 +656,8 @@ vc4_lock_bo_reservations(struct drm_device *dev,
  */
 static int
 vc4_queue_submit(struct drm_device *dev, struct vc4_exec_info *exec,
-struct ww_acquire_ctx *acquire_ctx)
+struct ww_acquire_ctx *acquire_ctx,
+struct drm_syncobj *out_sync)
 {
struct vc4_dev *vc4 = to_vc4_dev(dev);
struct vc4_exec_info *renderjob;
@@ -679,6 +680,9 @@ vc4_queue_submit(struct drm_device *dev, struct 
vc4_exec_info *exec,
fence->seqno = exec->seqno;
exec->fence = >base;
 
+   if (out_sync)
+   drm_syncobj_replace_fence(out_sync, exec->fence);
+
vc4_update_bo_seqnos(exec, seqno);
 
vc4_unlock_bo_reservations(dev, exec, acquire_ctx);
@@ -1114,6 +1118,7 @@ vc4_submit_cl_ioctl(struct drm_device *dev, void *data,
struct vc4_dev *vc4 = to_vc4_dev(dev);
struct vc4_file *vc4file = file_priv->driver_priv;
struct drm_vc4_submit_cl *args = data;
+   struct drm_syncobj *out_sync = NULL;
struct vc4_exec_info *exec;
struct ww_acquire_ctx acquire_ctx;
struct dma_fence *in_fence;
@@ -1123,11 +1128,17 @@ vc4_submit_cl_ioctl(struct drm_device *dev, void *data,
 VC4_SUBMIT_CL_FIXED_RCL_ORDER |
 VC4_SUBMIT_CL_RCL_ORDER_INCREASING_X |
 VC4_SUBMIT_CL_RCL_ORDER_INCREASING_Y |
-VC4_SUBMIT_CL_IMPORT_SYNCOBJ)) != 0) {
+VC4_SUBMIT_CL_IMPORT_SYNCOBJ |
+VC4_SUBMIT_CL_EXPORT_SYNCOBJ)) != 0) {
DRM_DEBUG("Unknown flags: 0x%02x\n", args->flags);
return -EINVAL;
}
 
+   if (args->pad2 != 0) {
+   DRM_DEBUG("->pad2 must be set to zero\n");
+   return -EINVAL;
+   }
+
exec = kcalloc(1, sizeof(*exec), GFP_KERNEL);
if (!exec) {
DRM_ERROR("malloc failure on exec struct\n");
@@ -1202,12 +1213,33 @@ vc4_submit_cl_ioctl(struct drm_device *dev, void *data,
if (ret)
goto fail;
 
+   if (args->flags & VC4_SUBMIT_CL_EXPORT_SYNCOBJ) {
+   out_sync = drm_syncobj_find(file_priv, args->out_sync);
+   if (!out_sync) {
+   ret = -EINVAL;
+   goto fail;
+   }
+
+   /* We replace the fence in out_sync in vc4_queue_submit since
+* the render job could execute immediately after that call.
+* If it finishes before our ioctl processing resumes the
+* render job fence could already have been freed.
+*/
+   }
+
/* Clear this out of the struct we'll be putting in the queue,
 * since it's part of our stack.
 */
exec->args = NULL;
 
-   ret = vc4_queue_submit(dev, exec, _ctx);
+   ret = vc4_queue_submit(dev, exec, _ctx, out_sync);
+
+   /* The syncobj isn't part of the exec data and we need to free our
+* reference even if job submission failed.
+*/
+   if (out_sync)
+   drm_syncobj_put(out_sync);
+
if (ret)
goto fail;
 
diff --git a/include/uapi/drm/vc4_drm.h b/include/uapi/drm/vc4_drm.h
index 389f21931c25..3a2ef9b5b60b 100644
--- a/include/uapi/drm/vc4_drm.h
+++ b/include/uapi/drm/vc4_drm.h
@@ -174,6 +174,7 @@ struct drm_vc4_submit_cl {
 #define VC4_SUBMIT_CL_RCL_ORDER_INCREASING_X   (1 << 2)
 #define VC4_SUBMIT_CL_RCL_ORDER_INCREASING_Y   (1 << 3)
 #define VC4_SUBMIT_CL_IMPORT_SYNCOBJ   (1 << 4)
+#define VC4_SUBMIT_CL_EXPORT_SYNCOBJ   (1 << 5)
__u32 flags;
 
/* Returned value of the seqno of this render job (for the
@@ -189,6 +190,18 @@ struct drm_vc4_submit_cl {
 * syncobj is signalled.
 */
__u32 in_sync;
+
+   /* Syncobj handle to export fence to. Set together with EXPORT_SYNCOBJ
+* flag. If set, the fence in the syncobj will be replaced with a fence
+* that signals upon completion of this render job.
+*/
+   __u32 out_sync;
+
+   /* Unused field to align this struct on 64 bits. Must be set to 0.
+* If one ever needs to add an u32 field to this struct, this field
+* can be used.
+*/
+   __u32 pad2;
 };
 
 /**
-- 
2.14.1

[PATCH 2/4] drm/vc4: Syncobj import support

[Stefan Schake]

Allow userland to specify a syncobj that is waited on before a render job
starts processing.

Signed-off-by: Stefan Schake 
---
 drivers/gpu/drm/vc4/vc4_drv.h |  2 ++
 drivers/gpu/drm/vc4/vc4_gem.c | 33 +++--
 include/uapi/drm/vc4_drm.h|  9 +
 3 files changed, 34 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index 4288615b66a2..3105df99cb12 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -10,6 +10,8 @@
 #include 
 #include 
 #include 
+#include 
+
 
 #include "uapi/drm/vc4_drm.h"
 
diff --git a/drivers/gpu/drm/vc4/vc4_gem.c b/drivers/gpu/drm/vc4/vc4_gem.c
index 2107b0daf8ef..232363488125 100644
--- a/drivers/gpu/drm/vc4/vc4_gem.c
+++ b/drivers/gpu/drm/vc4/vc4_gem.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "uapi/drm/vc4_drm.h"
 #include "vc4_drv.h"
@@ -1115,21 +1116,18 @@ vc4_submit_cl_ioctl(struct drm_device *dev, void *data,
struct drm_vc4_submit_cl *args = data;
struct vc4_exec_info *exec;
struct ww_acquire_ctx acquire_ctx;
+   struct dma_fence *in_fence;
int ret = 0;
 
if ((args->flags & ~(VC4_SUBMIT_CL_USE_CLEAR_COLOR |
 VC4_SUBMIT_CL_FIXED_RCL_ORDER |
 VC4_SUBMIT_CL_RCL_ORDER_INCREASING_X |
-VC4_SUBMIT_CL_RCL_ORDER_INCREASING_Y)) != 0) {
+VC4_SUBMIT_CL_RCL_ORDER_INCREASING_Y |
+VC4_SUBMIT_CL_IMPORT_SYNCOBJ)) != 0) {
DRM_DEBUG("Unknown flags: 0x%02x\n", args->flags);
return -EINVAL;
}
 
-   if (args->pad2 != 0) {
-   DRM_DEBUG("->pad2 must be set to zero\n");
-   return -EINVAL;
-   }
-
exec = kcalloc(1, sizeof(*exec), GFP_KERNEL);
if (!exec) {
DRM_ERROR("malloc failure on exec struct\n");
@@ -1164,6 +1162,29 @@ vc4_submit_cl_ioctl(struct drm_device *dev, void *data,
}
}
 
+   if (args->flags & VC4_SUBMIT_CL_IMPORT_SYNCOBJ) {
+   ret = drm_syncobj_find_fence(file_priv, args->in_sync,
+_fence);
+   if (ret)
+   goto fail;
+
+   /* When the fence (or fence array) is exclusively from our
+* context we can skip the wait since jobs are executed in
+* order of their submission through this ioctl and this can
+* only have fences from a prior job.
+*/
+   if (!dma_fence_match_context(in_fence,
+vc4->dma_fence_context)) {
+   ret = dma_fence_wait(in_fence, true);
+   if (ret) {
+   dma_fence_put(in_fence);
+   goto fail;
+   }
+   }
+
+   dma_fence_put(in_fence);
+   }
+
if (exec->args->bin_cl_size != 0) {
ret = vc4_get_bcl(dev, exec);
if (ret)
diff --git a/include/uapi/drm/vc4_drm.h b/include/uapi/drm/vc4_drm.h
index b95a0e11cb07..389f21931c25 100644
--- a/include/uapi/drm/vc4_drm.h
+++ b/include/uapi/drm/vc4_drm.h
@@ -173,6 +173,7 @@ struct drm_vc4_submit_cl {
 #define VC4_SUBMIT_CL_FIXED_RCL_ORDER  (1 << 1)
 #define VC4_SUBMIT_CL_RCL_ORDER_INCREASING_X   (1 << 2)
 #define VC4_SUBMIT_CL_RCL_ORDER_INCREASING_Y   (1 << 3)
+#define VC4_SUBMIT_CL_IMPORT_SYNCOBJ   (1 << 4)
__u32 flags;
 
/* Returned value of the seqno of this render job (for the
@@ -183,11 +184,11 @@ struct drm_vc4_submit_cl {
/* ID of the perfmon to attach to this job. 0 means no perfmon. */
__u32 perfmonid;
 
-   /* Unused field to align this struct on 64 bits. Must be set to 0.
-* If one ever needs to add an u32 field to this struct, this field
-* can be used.
+   /* Syncobj handle to wait on. Set together with IMPORT_SYNCOBJ flag.
+* If set, processing of this render job will not start until the
+* syncobj is signalled.
 */
-   __u32 pad2;
+   __u32 in_sync;
 };
 
 /**
-- 
2.14.1

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

[PATCH 0/4] drm/vc4: Syncobj import export

[Stefan Schake]

This series allows userspace to submit syncobj handles for importing
a fence to wait on or exporting the job fence as part of submission.

The primary use of this is to enable native fence fd support in Mesa.
Initial userspace implementation is under review and available here:

https://patchwork.freedesktop.org/series/42081/

Stefan Schake (4):
  drm/vc4: Enable syncobj support
  drm/vc4: Syncobj import support
  drm/vc4: Export fence through syncobj
  drm/vc4: Add parameter for syncobj support

 drivers/gpu/drm/vc4/vc4_drv.c |  4 ++-
 drivers/gpu/drm/vc4/vc4_drv.h |  2 ++
 drivers/gpu/drm/vc4/vc4_gem.c | 59 ---
 include/uapi/drm/vc4_drm.h| 15 +++
 4 files changed, 76 insertions(+), 4 deletions(-)

-- 
2.14.1

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

[PATCH v2 1/2] drm/exynos: fimd: Add support for S5PV210 FIMD variant

[Paweł Chmiel]

From: Tomasz Figa 

This patch adds support for FIMD variant found on S5PV210 SoC.
Except CLKSEL bit availability, it is identical to Exynos4210.

Tested-by: Paweł Chmiel 
Signed-off-by: Tomasz Figa 
Signed-off-by: Paweł Chmiel 
---

Changes from v1:
  - Added missing signed-off-by
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index d42ae2bc3e56..01b1570d0c3a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -121,6 +121,12 @@ static struct fimd_driver_data s3c64xx_fimd_driver_data = {
.has_limited_fmt = 1,
 };
 
+static struct fimd_driver_data s5pv210_fimd_driver_data = {
+   .timing_base = 0x0,
+   .has_shadowcon = 1,
+   .has_clksel = 1,
+};
+
 static struct fimd_driver_data exynos3_fimd_driver_data = {
.timing_base = 0x2,
.lcdblk_offset = 0x210,
@@ -193,6 +199,8 @@ struct fimd_context {
 static const struct of_device_id fimd_driver_dt_match[] = {
{ .compatible = "samsung,s3c6400-fimd",
  .data = _fimd_driver_data },
+   { .compatible = "samsung,s5pv210-fimd",
+ .data = _fimd_driver_data },
{ .compatible = "samsung,exynos3250-fimd",
  .data = _fimd_driver_data },
{ .compatible = "samsung,exynos4210-fimd",
-- 
2.7.4

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

[PATCH v2 2/2] drm/exynos: Allow DRM_EXYNOS on s5pv210.

[Paweł Chmiel]

This patch brings back possibility to use drivers depending on
DRM_EXYNOS, on Samsung S5PV210/S5PC110 series based systems.

Fixes: dbbc925bb83a ("drm/exynos: depend on ARCH_EXYNOS for DRM_EXYNOS")
Signed-off-by: Paweł Chmiel 
---
 drivers/gpu/drm/exynos/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 735ce47688f9..1548a784ef71 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -1,6 +1,6 @@
 config DRM_EXYNOS
tristate "DRM Support for Samsung SoC EXYNOS Series"
-   depends on OF && DRM && (ARCH_S3C64XX || ARCH_EXYNOS || 
ARCH_MULTIPLATFORM)
+   depends on OF && DRM && (ARCH_S3C64XX || ARCH_S5PV210 || ARCH_EXYNOS || 
ARCH_MULTIPLATFORM)
select DRM_KMS_HELPER
select VIDEOMODE_HELPERS
select SND_SOC_HDMI_CODEC if SND_SOC
-- 
2.7.4

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

Re: [PATCH 1/2] drm/exynos: fimd: Add support for S5PV210 FIMD variant

[Paweł Chmiel]

On Saturday, April 21, 2018 6:55:17 PM CEST Krzysztof Kozlowski wrote:
> On Fri, Apr 20, 2018 at 6:32 PM, Paweł Chmiel
>  wrote:
> > From: Tomasz Figa 
> >
> > This patch adds support for FIMD variant found on S5PV210 SoC.
> > Except CLKSEL bit availability, it is identical to Exynos4210.
> >
> > Tested-by: Paweł Chmiel 
> > Signed-off-by: Tomasz Figa 
> 
> You need to add your Signed-off-by here as well. It is necessary every
> time you touch a patch (and sending it is also a "touch" action).
Hi

Thanks for feedback, i've send a v2 version of this patchset with this issue 
fixed.

> 
> Best regards,
> Krzysztof
> 
> > ---
> >  drivers/gpu/drm/exynos/exynos_drm_fimd.c | 8 
> >  1 file changed, 8 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
> > b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> > index d42ae2bc3e56..01b1570d0c3a 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> > @@ -121,6 +121,12 @@ static struct fimd_driver_data 
> > s3c64xx_fimd_driver_data = {
> > .has_limited_fmt = 1,
> >  };
> >
> > +static struct fimd_driver_data s5pv210_fimd_driver_data = {
> > +   .timing_base = 0x0,
> > +   .has_shadowcon = 1,
> > +   .has_clksel = 1,
> > +};
> > +
> >  static struct fimd_driver_data exynos3_fimd_driver_data = {
> > .timing_base = 0x2,
> > .lcdblk_offset = 0x210,
> > @@ -193,6 +199,8 @@ struct fimd_context {
> >  static const struct of_device_id fimd_driver_dt_match[] = {
> > { .compatible = "samsung,s3c6400-fimd",
> >   .data = _fimd_driver_data },
> > +   { .compatible = "samsung,s5pv210-fimd",
> > + .data = _fimd_driver_data },
> > { .compatible = "samsung,exynos3250-fimd",
> >   .data = _fimd_driver_data },
> > { .compatible = "samsung,exynos4210-fimd",
> > --
> > 2.7.4
> >
> 


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

Re: [PATCH v3 0/7] Add tda998x (HDMI) support to atmel-hlcdc

[Peter Rosin]

On 2018-04-21 10:38, Laurent Pinchart wrote:
> Hi Peter,
> 
> On Friday, 20 April 2018 15:55:50 EEST Peter Rosin wrote:
>> On 2018-04-20 13:38, jacopo mondi wrote:
>>> On Fri, Apr 20, 2018 at 01:05:21PM +0200, Peter Rosin wrote:
 On 2018-04-20 12:18, Laurent Pinchart wrote:
> On Friday, 20 April 2018 11:52:35 EEST jacopo mondi wrote:
>> Hi Peter,
>>
>> I've been a bit a pain in the arse for you recently, but please
>> bear with me a bit more, and sorry for jumping late on the band wagon.
>>
>> On Thu, Apr 19, 2018 at 06:27:44PM +0200, Peter Rosin wrote:
>>> Hi!
>>>
>>> I naively thought that since there was support for both nxp,tda19988
>>> (in the tda998x driver) and the atmel-hlcdc, things would be a smooth
>>> ride. But it wasn't, so I started looking around and realized I had to
>>> fix things.
>>>
>>> In v1 and v2 I fixed things by making the atmel-hlcdc driver a master
>>> component, but now in v3 I fix things by making the tda998x driver
>>> a bridge instead. This was after a suggestion from Boris Brezillion

 That should be Brezillon, sorry for being sloppy with the spelling.

>>> (the atmel-hlcdc maintainer), so there was some risk of bias ... but
>>> after comparing what was needed, I too find the bridge approach
>>> better.
>>>
>>> In addition to the above, our PCB interface between the SAMA5D3 and
>>> the HDMI encoder is only using 16 bits, and this has to be described
>>> somewhere, or the atmel-hlcdc driver have no chance of selecting the
>>> correct output mode. Since I have similar problems with a ds90c185
>>> lvds encoder I added patches to override the atmel-hlcdc output format
>>> via DT properties compatible with the media video-interface binding
>>> and things start to play together.
>>>
>>> Since this series superseeds the bridge series [1], I have included
>>> the leftover bindings patch for the ti,ds90c185 here.
>>
>> I feel like this series would look better if it would make use of the
>> proposed bridge media bus format support I have recently sent out [1]
>> (and which was not there when you first sent v1).
>>
>> I understand your fundamental problem here is that the bus format
>> that should be reported by your bridge is different from the ones
>> actually supported by the TDA19988 chip, as the wirings ground some
>> of the input pins.
>>
>> Although this is defintely something that could be described in the
>> bridge's own OF node with the 'bus_width' property, and what I would
>> do, now that you have made a bridge out from the tda19988 driver, is:
>>
>> 1) Set the bridge accepted input bus_format parsing its pin
>> configuration, or default it if that's not implemented yet.
>> This will likely be rgb888. You can do that using the trivial
>> support for bridge input image formats implemented by my series.
>> 2) Specify in the bridge endpoint a 'bus_width' of <16>
>> 3) In your atmel-hlcd get both the image format of the bridge (rgb888)
>> and parse the remote endpoint property 'bus_width' and get the <16>
>> value back.
>
> Parsing properties of remote nodes should be avoided as much as
> possible, as they need to be interpreted in the context of the DT
> bindings related to the compatible string applicable to that node. I'd
> rather have the bus_width property in the local endpoint node.

 In addition to that, my view of this binding

endpoint {
bus-type = <0>;
>>>
>>> bus-type is used by v4l2_fwnode helpers to decide which type of bus
>>> they're dealing with iirc. Here it seems to me it has no added
>>> value, also because in your bindings description "it shall be 0" and
>>> it is not parsed anywhere in you code, but no big deal
>>
>> bus-type is indeed parsed and verified to be zero which means auto-detect
>> according to the video-interfaces binding. An auto-detect bus-type with
>> a given bus-width means a parallel interface IIUC.
> 
> I believe you could leave it out though. Your display controller only 
> supports 
> parallel buses, so there's no need to specify the bus type explicitly.

You need it if you want to verify that you conform to the video-interfaces
binding. And that verification is only needed *if* we want to build upon
the drm_of_media_bus_fmt function so that it eventually support other formats.

Where I'm coming from is this discussion with Rob:
https://lkml.org/lkml/2018/4/9/286

I interpreted that as is seen in patch 2/7 and 3/7 in v3 (and v2). True,
I might have read too much into his desire to have something generic,
and that the generic bit only applied to the binding, but 2/7 and 3/7
was how I interpreted that conversation.

>> From patch 3/7:
>>
>>  if (of_property_read_u32(node, "bus-type", _type))
>>  return 0;
>>  if (bus_type != 0)
>>  

[PATCH v2 0/2] drm/exynos: fimd: Add support for S5PV210

[Paweł Chmiel]

This patch series compose of 2 patches.

First patch, adding support for S5PV210 FIMD variant to Exynos driver.
Compatible for this soc was already existing in documentation.

Second patch, brings back possibility to use drivers depending on
DRM_EXYNOS, on Samsung S5PV210/S5PC110 series based systems.

Both patches has been tested on (not yet mainlined), an S5PV210 based
Samsung Galaxy S (i9000) phone.

Changes from v1:
  - Added missing signed-off-by to one of patches

Paweł Chmiel (1):
  drm/exynos: Allow DRM_EXYNOS on s5pv210.

Tomasz Figa (1):
  drm/exynos: fimd: Add support for S5PV210 FIMD variant

 drivers/gpu/drm/exynos/Kconfig   | 2 +-
 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 8 
 2 files changed, 9 insertions(+), 1 deletion(-)

-- 
2.7.4

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

Re: [PATCH 1/2] drm/exynos: fimd: Add support for S5PV210 FIMD variant

[Krzysztof Kozlowski]

On Fri, Apr 20, 2018 at 6:32 PM, Paweł Chmiel
 wrote:
> From: Tomasz Figa 
>
> This patch adds support for FIMD variant found on S5PV210 SoC.
> Except CLKSEL bit availability, it is identical to Exynos4210.
>
> Tested-by: Paweł Chmiel 
> Signed-off-by: Tomasz Figa 

You need to add your Signed-off-by here as well. It is necessary every
time you touch a patch (and sending it is also a "touch" action).

Best regards,
Krzysztof

> ---
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index d42ae2bc3e56..01b1570d0c3a 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -121,6 +121,12 @@ static struct fimd_driver_data s3c64xx_fimd_driver_data 
> = {
> .has_limited_fmt = 1,
>  };
>
> +static struct fimd_driver_data s5pv210_fimd_driver_data = {
> +   .timing_base = 0x0,
> +   .has_shadowcon = 1,
> +   .has_clksel = 1,
> +};
> +
>  static struct fimd_driver_data exynos3_fimd_driver_data = {
> .timing_base = 0x2,
> .lcdblk_offset = 0x210,
> @@ -193,6 +199,8 @@ struct fimd_context {
>  static const struct of_device_id fimd_driver_dt_match[] = {
> { .compatible = "samsung,s3c6400-fimd",
>   .data = _fimd_driver_data },
> +   { .compatible = "samsung,s5pv210-fimd",
> + .data = _fimd_driver_data },
> { .compatible = "samsung,exynos3250-fimd",
>   .data = _fimd_driver_data },
> { .compatible = "samsung,exynos4210-fimd",
> --
> 2.7.4
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104001] GPU driver hung when start steam client while playback video on Youtube (it occurs on latest staging kernel)

[bugzilla-daemon]

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

--- Comment #31 from mikhail.v.gavri...@gmail.com ---
(In reply to Marek Olšák from comment #30)
> This might fix it:
> https://cgit.freedesktop.org/mesa/mesa/commit/
> ?id=d15fb766aa3c98ffbe16d050b2af4804e4b12c57

For which mesa version this patch?

My si_pipe.c (mesa 18.0.1) looks differently
https://imgur.com/a/dc3RoHi

-- 
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 v3 4/7] drm/atmel-hlcdc: support bus-width (12/16/18/24) in endpoint nodes

[Boris Brezillon]

On Thu, 19 Apr 2018 18:27:48 +0200
Peter Rosin  wrote:

> This beats the heuristic that the connector is involved in what format
> should be output for cases where this fails.
> 
> E.g. if there is a bridge that changes format between the encoder and the
> connector, or if some of the RGB pins between the lcd controller and the
> encoder are not routed on the PCB.
> 
> This is critical for the devices that have the "conflicting output
> formats" issue (SAM9N12, SAM9X5, SAMA5D3), since the most significant
> RGB bits move around depending on the selected output mode. For
> devices that do not have the "conflicting output formats" issue
> (SAMA5D2, SAMA5D4), this is completely irrelevant.
> 
> Signed-off-by: Peter Rosin 
> ---
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c   | 71 
> +---
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h |  2 +
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 40 -
>  3 files changed, 92 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c 
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> index d73281095fac..b4e7f5b6f497 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> @@ -226,6 +226,56 @@ static void atmel_hlcdc_crtc_atomic_enable(struct 
> drm_crtc *c,
>  #define ATMEL_HLCDC_RGB888_OUTPUTBIT(3)
>  #define ATMEL_HLCDC_OUTPUT_MODE_MASK GENMASK(3, 0)
>  
> +static int atmel_hlcdc_connector_output_mode(struct drm_connector_state 
> *state)
> +{
> + struct drm_connector *connector = state->connector;
> + struct atmel_hlcdc_dc *dc = connector->dev->dev_private;
> + struct drm_encoder *encoder;
> + struct drm_display_info *info = >display_info;
> + unsigned int supported_fmts = 0;
> + int j;
> +
> + encoder = state->best_encoder;
> + if (!encoder)
> + encoder = connector->encoder;
> +
> + switch (dc->bus_fmt[encoder->index]) {
> + case 0:
> + break;
> + case MEDIA_BUS_FMT_RGB444_1X12:
> + return ATMEL_HLCDC_RGB444_OUTPUT;
> + case MEDIA_BUS_FMT_RGB565_1X16:
> + return ATMEL_HLCDC_RGB565_OUTPUT;
> + case MEDIA_BUS_FMT_RGB666_1X18:
> + return ATMEL_HLCDC_RGB666_OUTPUT;
> + case MEDIA_BUS_FMT_RGB888_1X24:
> + return ATMEL_HLCDC_RGB888_OUTPUT;
> + default:
> + return -EINVAL;
> + }
> +
> + for (j = 0; j < info->num_bus_formats; j++) {
> + switch (info->bus_formats[j]) {
> + case MEDIA_BUS_FMT_RGB444_1X12:
> + supported_fmts |= ATMEL_HLCDC_RGB444_OUTPUT;
> + break;
> + case MEDIA_BUS_FMT_RGB565_1X16:
> + supported_fmts |= ATMEL_HLCDC_RGB565_OUTPUT;
> + break;
> + case MEDIA_BUS_FMT_RGB666_1X18:
> + supported_fmts |= ATMEL_HLCDC_RGB666_OUTPUT;
> + break;
> + case MEDIA_BUS_FMT_RGB888_1X24:
> + supported_fmts |= ATMEL_HLCDC_RGB888_OUTPUT;
> + break;
> + default:
> + break;
> + }
> + }
> +
> + return supported_fmts;
> +}
> +
>  static int atmel_hlcdc_crtc_select_output_mode(struct drm_crtc_state *state)
>  {
>   unsigned int output_fmts = ATMEL_HLCDC_OUTPUT_MODE_MASK;
> @@ -238,31 +288,12 @@ static int atmel_hlcdc_crtc_select_output_mode(struct 
> drm_crtc_state *state)
>   crtc = drm_crtc_to_atmel_hlcdc_crtc(state->crtc);
>  
>   for_each_new_connector_in_state(state->state, connector, cstate, i) {
> - struct drm_display_info *info = >display_info;
>   unsigned int supported_fmts = 0;
> - int j;
>  
>   if (!cstate->crtc)
>   continue;
>  
> - for (j = 0; j < info->num_bus_formats; j++) {
> - switch (info->bus_formats[j]) {
> - case MEDIA_BUS_FMT_RGB444_1X12:
> - supported_fmts |= ATMEL_HLCDC_RGB444_OUTPUT;
> - break;
> - case MEDIA_BUS_FMT_RGB565_1X16:
> - supported_fmts |= ATMEL_HLCDC_RGB565_OUTPUT;
> - break;
> - case MEDIA_BUS_FMT_RGB666_1X18:
> - supported_fmts |= ATMEL_HLCDC_RGB666_OUTPUT;
> - break;
> - case MEDIA_BUS_FMT_RGB888_1X24:
> - supported_fmts |= ATMEL_HLCDC_RGB888_OUTPUT;
> - break;
> - default:
> - break;
> - }
> - }
> + supported_fmts = atmel_hlcdc_connector_output_mode(cstate);
>  
>   if (crtc->dc->desc->conflicting_output_formats)
>   

[Bug 104082] amdgpu 0000:07:00.0: swiotlb buffer is full (sz: 2097152 bytes)

[bugzilla-daemon]

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

--- Comment #41 from Jean Delvare  ---
Bah, I spoke too fast. Even with commit 9e7f06c8beee ("swiotlb: fix unexpected
swiotlb_alloc_coherent failures") backported, I end up seeing the backtraces
again, after several hours. So that commit helps but doesn't solve the problem.
It seems there are at least 3 different bugs leading to the same problem.

-- 
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 199101] AMDGPU Fury X random screen flicker on Linux kernel 4.16rc5

[bugzilla-daemon]

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

--- Comment #21 from Kevin McCormack (wittyma...@yahoo.com) ---
Thank you, Alex!

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

[Bug 105425] 3D & games produce periodic GPU crashes (Radeon R7 370)

[bugzilla-daemon]

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

--- Comment #40 from i...@yahoo.com ---
It seems like the sysrq actually worked, I see it in the logs.

The crash has happened around Apr20 15:54. Unfortunately the kernel error/panic
message is missing in both logs. My distro doesn't have systemd, so I cannot
tell you what the magic journalctl options are to get these messages out. On my
system, these usually go in /var/log/syslog . See if you can find something
more useful from about that time.

As for the apitrace, it should work out of the box.
First test it with:
   apitrace trace glxgears
It should create a glxgears.trace . If you run it again, it would create
glxgears.1.trace etc.

It's important to be sure that you are using 64 bit apitrace with 64bit
applications. 

   apitrace trace ./xonotic-linux64-glx

Should do the trick.
First, start a game match and exit right away. Then try to replay the result
with:

   apitrace replay xonotic-linux64.glx.trace

This is to make sure that tracing is working properly.

Then just make sure you have enough free space. Enable vsync, to limit the
frames per second. Using smaller textures should also help with the trace size
(textures are loaded at the level start, so playing longer match should help
too).

After you record a crash and reboot with sysrq, see if replaying the resulting
trace file would cause hang at its end.

You can compress the trace with `xz -9e xonotic*.trace` .

Good Luck.

-- 
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 100069] Dirt: Showdown bad performance and broken rendering with enabled advanced lightning

[bugzilla-daemon]

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

Gregor Münch  changed:

   What|Removed |Added

Summary|Dirt: Showdown bad  |Dirt: Showdown bad
   |performance with enabled|performance and broken
   |advanced lightning  |rendering with enabled
   ||advanced lightning

-- 
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 100069] Dirt: Showdown bad performance with enabled advanced lightning

[bugzilla-daemon]

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

--- Comment #11 from Gregor Münch  ---
Created attachment 138980
  --> https://bugs.freedesktop.org/attachment.cgi?id=138980=edit
ingame completely broken graphics

-- 
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 100069] Dirt: Showdown bad performance with enabled advanced lightning

[bugzilla-daemon]

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

Gregor Münch  changed:

   What|Removed |Added

 Attachment #137129|0   |1
is obsolete||

--- Comment #10 from Gregor Münch  ---
Created attachment 138979
  --> https://bugs.freedesktop.org/attachment.cgi?id=138979=edit
ingame benchmark mode

The cars with texture errors seem to be either a game bug or Phoronix Test
Suite bug.
If you select the Benchmark mode while you in the actual game, the cars are
rendered correctly.
However the graphics are still broken.
Seems to be a problem how the lights got applied to the objects.

-- 
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 105333] [gallium-nine] missing geometry after commit ac: replace ac_build_kill with ac_build_kill_if_false

[bugzilla-daemon]

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

--- Comment #5 from had...@gmx.de ---
I tried to make an apitrace, but it crashes for me when replaying. The apitrace
can be downloaded here:
https://www.dropbox.com/s/ynr9v7ls561qgdw/Mashinky.6.trace?dl=0
I opened a bug at the ixit github side here:
https://github.com/iXit/Mesa-3D/issues/314

-- 
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: [v2] drm/sun4i: add lvds mode_valid function

[Ondřej Jirman]

Hello,

On Thu, Apr 19, 2018 at 04:02:08PM +0200, Giulio Benetti wrote:
> Hi everybody,
> 
> Il 19/04/2018 15:36, Chen-Yu Tsai ha scritto:
> > On Thu, Apr 19, 2018 at 9:34 PM, Ondřej Jirman
> >  wrote:
> > > Hello Giulio,
> > > 
> > > this patch breaks LVDS output on A83T. Without it, modesetting works,
> > > with it there's no output.
> > > 
> > > Some more info below...
> > > 
> > > On Tue, Mar 13, 2018 at 12:20:19PM +0100, Giulio Benetti wrote:
> > > > mode_valid function is missing for lvds.
> > > > 
> > > > Add it making it pointed by encoder helper functions.
> > > > 
> > > > Signed-off-by: Giulio Benetti 
> > > > ---
> > > >   drivers/gpu/drm/sun4i/sun4i_lvds.c | 55 
> > > > ++
> > > >   1 file changed, 55 insertions(+)
> > > > 
> > > > diff --git a/drivers/gpu/drm/sun4i/sun4i_lvds.c 
> > > > b/drivers/gpu/drm/sun4i/sun4i_lvds.c
> > > > index be3f14d..b4c 100644
> > > > --- a/drivers/gpu/drm/sun4i/sun4i_lvds.c
> > > > +++ b/drivers/gpu/drm/sun4i/sun4i_lvds.c
> > > > @@ -94,9 +94,64 @@ static void sun4i_lvds_encoder_disable(struct 
> > > > drm_encoder *encoder)
> > > >}
> > > >   }
> > > > 
> > > > +static enum drm_mode_status sun4i_lvds_encoder_mode_valid(struct 
> > > > drm_encoder *crtc,
> > > > +   const struct 
> > > > drm_display_mode *mode)
> > > > +{
> > > > + struct sun4i_lvds *lvds = drm_encoder_to_sun4i_lvds(crtc);
> > > > + struct sun4i_tcon *tcon = lvds->tcon;
> > > > + u32 hsync = mode->hsync_end - mode->hsync_start;
> > > > + u32 vsync = mode->vsync_end - mode->vsync_start;
> > > > + unsigned long rate = mode->clock * 1000;
> > > > + long rounded_rate;
> > > > +
> > > > + DRM_DEBUG_DRIVER("Validating modes...\n");
> > > > +
> > > > + if (hsync < 1)
> > > > + return MODE_HSYNC_NARROW;
> > > > +
> > > > + if (hsync > 0x3ff)
> > > > + return MODE_HSYNC_WIDE;
> > > > +
> > > > + if ((mode->hdisplay < 1) || (mode->htotal < 1))
> > > > + return MODE_H_ILLEGAL;
> > > > +
> > > > + if ((mode->hdisplay > 0x7ff) || (mode->htotal > 0xfff))
> > > > + return MODE_BAD_HVALUE;
> > > > +
> > > > + DRM_DEBUG_DRIVER("Horizontal parameters OK\n");
> > > > +
> > > > + if (vsync < 1)
> > > > + return MODE_VSYNC_NARROW;
> > > > +
> > > > + if (vsync > 0x3ff)
> > > > + return MODE_VSYNC_WIDE;
> > > > +
> > > > + if ((mode->vdisplay < 1) || (mode->vtotal < 1))
> > > > + return MODE_V_ILLEGAL;
> > > > +
> > > > + if ((mode->vdisplay > 0x7ff) || (mode->vtotal > 0xfff))
> > > > + return MODE_BAD_VVALUE;
> > > > +
> > > > + DRM_DEBUG_DRIVER("Vertical parameters OK\n");
> > > > +
> > > > + tcon->dclk_min_div = 7;
> > > > + tcon->dclk_max_div = 7;
> > > 
> > > Why would validation function change any state anywhere?
> > > 
> > > > + rounded_rate = clk_round_rate(tcon->dclk, rate);
> > > 
> > > The issue is here, on A83T TBS A711 tablet, I get...
> > > 
> > > sun4i-tcon 1c0c000.lcd-controller: XXX: hsync=20 hdisplay=1024 htotal=1384
> > >vsync=5 vdisplay=600 vtotal=640 rate=5200 rounded_rate=51857142
> > > 
> > > > + if (rounded_rate < rate)
> > > > + return MODE_CLOCK_LOW;
> > > > +
> > > > + if (rounded_rate > rate)
> > > > + return MODE_CLOCK_HIGH;
> > > 
> > > ... while the previous conditions require an exact match for some reason.
> > > 
> > > But HW works fine without an exact rate match. Why is exact match 
> > > required here?
> > 
> > This thread might provide some more info, though we could never get an
> > agreement.
> > 
> > https://patchwork.kernel.org/patch/9446385/
> 
> Thanks for pointing that Thread ChenYu.
> So the only chance is to trim frequency according to encoder capabilities.
> I agree to block when encoder can't provide frequency specified,
> otherwise you could drive you panel at the near the lowest(highest)
> frequency and get out of limits for a few without knowing it.

When I set the range of pixel clock frequencies on simple-panel connected
to this encoder, the check still fails, so there's something not working
there as expected. This check is only called once with a typical frequency.

I guess drm doesn't implement clock-frequency range on panels. But I haven't
looked.

I can set the exact frequency that the SoC can provide on the simple-panel,
but that's a bit of a hack.

regards,
  o.

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

[PATCH] drm/hisilicon/hibmc: Using module_pci_driver.

[YueHaibing]

Remove boilerplate code by using macro module_pci_driver.

Signed-off-by: YueHaibing 
---
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 13 +
 1 file changed, 1 insertion(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index d4f6f1f..68d80c1 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -414,18 +414,7 @@ static struct pci_driver hibmc_pci_driver = {
.driver.pm =_pm_ops,
 };
 
-static int __init hibmc_init(void)
-{
-   return pci_register_driver(_pci_driver);
-}
-
-static void __exit hibmc_exit(void)
-{
-   return pci_unregister_driver(_pci_driver);
-}
-
-module_init(hibmc_init);
-module_exit(hibmc_exit);
+module_pci_driver(hibmc_pci_driver);
 
 MODULE_DEVICE_TABLE(pci, hibmc_pci_table);
 MODULE_AUTHOR("RongrongZou ");
-- 
2.7.0


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

Re: [PATCH v3 7/7] drm/i2c: tda998x: register as a drm bridge

[Russell King - ARM Linux]

On Thu, Apr 19, 2018 at 06:27:51PM +0200, Peter Rosin wrote:
> This makes this driver work with all(?) drivers that are not
> componentized and instead expect to connect to a panel/bridge. That
> said, the only one tested is atmel_hlcdc.
> 
> This hooks the relevant work function previously called by the encoder
> and the component also to the bridge, since the encoder goes away when
> connecting to the bridge interface of the driver and the equivalent of
> bind/unbind of the component is handled by bridge attach/detach.
> 
> The lifetime requirements of a bridge and a component are slightly
> different, which is the reason for struct tda998x_bridge.

As we are talking about bridge stuff, the patch below is what I've had
for a while converting Armada to be able to use a bridge-based tda998x.
As you can see, it's far from satisfactory at the moment.  Specifically:

1) it assumes all bridges are TMDS bridges, because as far as I can see,
   there's no way to know any different.
2) there's no way to really know whether a missing bridge is because we
   should be using the component helpers or that the bridge device
   doesn't exist yet.

diff --git a/drivers/gpu/drm/armada/armada_drv.c 
b/drivers/gpu/drm/armada/armada_drv.c
index 262409cae8bf..854d74466dec 100644
--- a/drivers/gpu/drm/armada/armada_drv.c
+++ b/drivers/gpu/drm/armada/armada_drv.c
@@ -20,6 +20,127 @@
 #include 
 #include "armada_ioctlP.h"
 
+static const struct drm_encoder_helper_funcs dummy_encoder_helper_funcs = {
+};
+
+static const struct drm_encoder_funcs dummy_encoder_funcs = {
+   .destroy = drm_encoder_cleanup,
+};
+
+static int dummy_encoder_add(struct device *dev, struct drm_device *drm,
+struct drm_bridge *bridge, int type, u32 crtcs)
+{
+   struct drm_encoder *enc;
+   int ret;
+
+   enc = devm_kzalloc(dev, sizeof(*enc), GFP_KERNEL);
+   if (!enc)
+   return -ENOMEM;
+
+   drm_encoder_helper_add(enc, _encoder_helper_funcs);
+   ret = drm_encoder_init(drm, enc, _encoder_funcs, type, NULL);
+   if (ret)
+   return ret;
+
+   enc->possible_crtcs = crtcs;
+   enc->bridge = bridge;
+   bridge->encoder = enc;
+
+   ret = drm_bridge_attach(enc, bridge, NULL);
+   if (ret)
+   dev_err(dev, "drm_bridge_attach() failed: %d\n", ret);
+
+   return ret;
+}
+
+static int hack_of_add_crtc_encoders(struct drm_device *drm,
+struct device_node *port)
+{
+   struct device *dev = drm->dev;
+   struct device_node *ep, *remote;
+   struct drm_bridge *bridge;
+   u32 crtcs;
+   int ret;
+
+   for_each_child_of_node(port, ep) {
+   remote = of_graph_get_remote_port_parent(ep);
+   if (!remote || !of_device_is_available(remote) ||
+   !of_device_is_available(remote->parent)) {
+   of_node_put(remote);
+   continue;
+   }
+
+   bridge = of_drm_find_bridge(remote);
+dev_info(dev, "found remote %s => bridge %p\n", of_node_full_name(remote), 
bridge);
+   if (!bridge) {
+   of_node_put(remote);
+   continue;
+   }
+
+   crtcs = drm_of_find_possible_crtcs(drm, remote);
+   /* If no CRTCs were found, fall back to our old behaviour */
+   if (crtcs == 0) {
+   dev_warn(dev, "Falling back to first CRTC\n");
+   crtcs = 1 << 0;
+   }
+
+   ret = dummy_encoder_add(dev, drm, bridge, DRM_MODE_ENCODER_TMDS,
+   crtcs);
+   if (ret) {
+   dev_err(dev, "drm_bridge_attach() failed: %d\n", ret);
+   of_node_put(ep);
+   return ret;
+   }
+   }
+
+   return 0;
+}
+
+static int hack_create_encoders(struct drm_device *drm)
+{
+   struct device *dev = drm->dev;
+   struct device_node *port = NULL;
+   int i, ret = 0;
+
+   if (dev->of_node) {
+   for (i = 0; ; i++) {
+   port = of_parse_phandle(dev->of_node, "ports", i);
+   if (!port)
+   break;
+
+   if (of_device_is_available(port->parent))
+   ret = hack_of_add_crtc_encoders(drm, port);
+
+   of_node_put(port);
+
+   if (ret)
+   break;
+   }
+   } else if (dev->platform_data) {
+   const char **devices = dev->platform_data;
+   struct device *d;
+
+   for (i = 0; devices[i]; i++) {
+   d = bus_find_device_by_name(_bus_type, NULL,
+   devices[i]);
+   if (d && d->of_node) {
+   

Re: [PATCHv3 3/8] drm/omap: add support for manually updated displays

[Tony Lindgren]

Hi,

* Daniel Stone  [180420 10:21]:
> Hi Tomi,
> 
> On 20 April 2018 at 08:09, Tomi Valkeinen  wrote:
> > It's actually not quite clear to me how manual update displays work with
> > DRM...
> >
> > As far as I see, we have essentially two cases: 1) single buffering,
> > where the userspace must set an area in the fb dirty, which then
> > triggers the update, 2) multi buffering, which doesn't need fb dirty,
> > but just a page flip which triggers the update.
> >
> > In the 2) case (which I think is the optimal case which all the modern
> > apps should use), there's no need for delayed work or any work, and the
> > code flow should be very similar to the auto-update model.
> 
> Correct. There's been talk (and I think patches?) of adding a
> per-plane dirty property, so userspace can as an optimisation inform
> the kernel of the area changed between frames. But short of that, a
> pageflip needs to trigger a full-plane update, with no dirtyfb
> required.

For per-plane dirty property patches, which ones do you refer to?

Then for xorg, there's my second attempt on fixing the command mode
rotation at [0]. Not sure if that's enough for a fix?

It seems not very efficient to me and I don't really know where
the the per crtc dirty flag should be stored..

I can easily test patches though with a command mode LCD and normal
HDMI setup on droid 4.

Regards,

Tony

[0] https://lists.x.org/archives/xorg-devel/2018-February/055890.html
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/7] Enable most media drivers to build on ARM

[Mauro Carvalho Chehab]

Right now, all media drivers build successfully with COMPILE_TEST on x86,
on both i386 and x86_64. Yet, several drivers there don't build on other
archs.

I don't need myself to build all drivers outside x86, but others could
find it useful. It also relps spreading COMPILE_TEST builds, with sounds
a good idea, as more developers may be seeing issues and submiting 
us patches.

So, this patch series makes most of them to be built elsewhere (tested
only with ARM with allyesconfig). The only two media drivers that don't build 
on such conditions are:

1) media/staging/atomisp: it uses several ACPI bits that no other media
driver requires (including Intel IPU3);

2) radio-miropcm20: This device depnds on ISA_DMA_API, with is available only
for a few non-Intel architectures.

In other words, the following symbols aren't enabled with allyesconfig:

INTEL_ATOMISP VIDEO_ATOMISP
VIDEO_ATOMISP_MSRLIST_HELPER VIDEO_ATOMISP_MT9M114
VIDEO_ATOMISP_GC0310  VIDEO_ATOMISP_GC2235 
VIDEO_ATOMISP_OV2722 VIDEO_ATOMISP_OV5693
VIDEO_ATOMISP_OV2680 VIDEO_ATOMISP_LM3554
RADIO_MIROPCM20

All patches in this series are available at:

https://git.linuxtv.org/mchehab/experimental.git/log/?h=compile_test_v7

Mauro Carvalho Chehab (7):
  asm-generic, media: allow COMPILE_TEST with virt_to_bus
  media: meye: allow building it with COMPILE_TEST on non-x86
  media: rc: allow build pnp-dependent drivers with COMPILE_TEST
  media: ipu3: allow building it with COMPILE_TEST on non-x86 archs
  omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP
  media: omap2: allow building it with COMPILE_TEST && DRM_OMAP
  media: via-camera: allow build on non-x86 archs with COMPILE_TEST

 drivers/media/pci/intel/ipu3/Kconfig |  3 +-
 drivers/media/pci/meye/Kconfig   |  3 +-
 drivers/media/pci/sta2x11/Kconfig|  4 +--
 drivers/media/pci/zoran/Kconfig  |  3 +-
 drivers/media/platform/Kconfig   |  2 +-
 drivers/media/platform/omap/Kconfig  |  3 +-
 drivers/media/platform/via-camera.c  | 10 ++-
 drivers/media/rc/Kconfig | 10 +++
 include/asm-generic/io.h |  2 +-
 include/linux/sony-laptop.h  |  4 +++
 include/linux/via-core.h | 17 
 include/linux/via-gpio.h |  4 +++
 include/linux/via_i2c.h  |  5 
 include/video/omapfb_dss.h   | 54 ++--
 14 files changed, 107 insertions(+), 17 deletions(-)

-- 
2.14.3


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

Re: [PATCH v3 7/7] drm/i2c: tda998x: register as a drm bridge

[Peter Rosin]

On 2018-04-20 12:53, Russell King - ARM Linux wrote:
> On Fri, Apr 20, 2018 at 12:49:42PM +0200, Peter Rosin wrote:
>> On 2018-04-20 12:41, kbuild test robot wrote:
>>> Hi Peter,
>>>
>>> I love your patch! Yet something to improve:
>>
>> Yup, right you are!
>>
>>> [auto build test ERROR on drm/drm-next]
>>> [also build test ERROR on v4.17-rc1 next-20180420]
>>> [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/Peter-Rosin/Add-tda998x-HDMI-support-to-atmel-hlcdc/20180420-160131
>>> base:   git://people.freedesktop.org/~airlied/linux.git drm-next
>>> config: i386-randconfig-a0-201815 (attached as .config)
>>> compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
>>> reproduce:
>>> # save the attached .config to linux build tree
>>> make ARCH=i386 
>>>
>>> All errors (new ones prefixed by >>):
>>>
>>>drivers/gpu/drm/i2c/tda998x_drv.c: In function 'tda998x_probe':
> drivers/gpu/drm/i2c/tda998x_drv.c:1859:16: error: 'struct drm_bridge' has 
> no member named 'of_node'
>>>  bridge->bridge.of_node = dev->of_node;
>>>^
>>
>> Anybody got a better fix than this?
>>
>> #ifdef CONFIG_OF
>>  bridge->bridge.of_node = dev->of_node;
>> #endif
> 
> How about the bridge code provides a helper to do this, something like:
> 
> static inline void bridge_set_device(struct drm_bridge *bridge,
>struct device *dev)
> {
> #ifdef CONFIG_OF
>   bridge->of_node = dev->of_node;
> #endif
> }
> 
> which (a) nicely hides the firmware flavour, and (b) hides the ifdef in
> the bridge header where it belongs.  If the bridge code needs to be
> converted to fwnode in the future, at least this would be abstracted
> from the drivers.
> 

Hmm, I looked around and found numerous other #ifdefs for this, so my plan
is to just add one more. Fixing up all these ifdefs is orthogonal and can
be done later.

Cheers,
Peter

PS. I also noted that I had forgotten to remove a couple of dev_info calls
in this patch. Will remove for v4.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: udl: Destroy framebuffer only if it was initialized

[Emil Lundmark]

This fixes a NULL pointer dereference that can happen if the UDL
driver is unloaded before the framebuffer is initialized. This can
happen e.g. if the USB device is unplugged right after it was plugged
in.

Signed-off-by: Emil Lundmark 
---
 drivers/gpu/drm/udl/udl_fb.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/udl/udl_fb.c b/drivers/gpu/drm/udl/udl_fb.c
index 2ebdc6d5a76e..5754e37f741b 100644
--- a/drivers/gpu/drm/udl/udl_fb.c
+++ b/drivers/gpu/drm/udl/udl_fb.c
@@ -426,9 +426,11 @@ static void udl_fbdev_destroy(struct drm_device *dev,
 {
drm_fb_helper_unregister_fbi(>helper);
drm_fb_helper_fini(>helper);
-   drm_framebuffer_unregister_private(>ufb.base);
-   drm_framebuffer_cleanup(>ufb.base);
-   drm_gem_object_put_unlocked(>ufb.obj->base);
+   if (ufbdev->ufb.obj) {
+   drm_framebuffer_unregister_private(>ufb.base);
+   drm_framebuffer_cleanup(>ufb.base);
+   drm_gem_object_put_unlocked(>ufb.obj->base);
+   }
 }
 
 int udl_fbdev_init(struct drm_device *dev)
-- 
2.17.0.484.g0c8726318c-goog

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

[PATCH 0/2] drm/exynos: fimd: Add support for S5PV210

[Paweł Chmiel]

This patch series compose of 2 patches.

First patch, adding support for S5PV210 FIMD variant to Exynos driver.
Compatible for this soc was already existing in documentation.

Second patch, brings back possibility to use drivers depending on
DRM_EXYNOS, on Samsung S5PV210/S5PC110 series based systems.

Both patches has been tested on (not yet mainlined), an S5PV210 based
Samsung Galaxy S (i9000) phone.

Paweł Chmiel (1):
  drm/exynos: Allow DRM_EXYNOS on s5pv210.

Tomasz Figa (1):
  drm/exynos: fimd: Add support for S5PV210 FIMD variant

 drivers/gpu/drm/exynos/Kconfig   | 2 +-
 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 8 
 2 files changed, 9 insertions(+), 1 deletion(-)

-- 
2.7.4

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

Re: [PATCH v3 7/7] drm/i2c: tda998x: register as a drm bridge

[Peter Rosin]

On 2018-04-20 12:24, Russell King - ARM Linux wrote:
> On Fri, Apr 20, 2018 at 01:06:49PM +0300, Laurent Pinchart wrote:
>> Hi Peter,
>>
>> Thank you for the patch.
>>
>> On Thursday, 19 April 2018 19:27:51 EEST Peter Rosin wrote:
>>> This makes this driver work with all(?) drivers that are not
>>> componentized and instead expect to connect to a panel/bridge. That
>>> said, the only one tested is atmel_hlcdc.
>>>
>>> This hooks the relevant work function previously called by the encoder
>>> and the component also to the bridge, since the encoder goes away when
>>> connecting to the bridge interface of the driver and the equivalent of
>>> bind/unbind of the component is handled by bridge attach/detach.
>>>
>>> The lifetime requirements of a bridge and a component are slightly
>>> different, which is the reason for struct tda998x_bridge.
>>
>> Couldn't you move the allocation and initialization (tda998x_create) of the 
>> tda998x_priv structure to probe time ? I think you wouldn't need a separate 
>> structure in that case. Unless I'm mistaken there would be an added benefit 
>> of 
>> separating component and bridge initialization, resulting in the encoder not 
>> being initialized at all if the component isn't used. You wouldn't need to 
>> add 
>> a local_encoder parameter to the tda998x_init() function.
> 
> No, I don't like that idea one bit, as I've stated in the past about the
> component API.  The same (probably) goes for the bridge stuff too.
> 
> Consider the following:
> 
> Your DRM system is initialised.  You then remove a module, which results
> in the DRM system being torn down.  You re-insert the module (eg, having
> made a change to it).  The DRM system is then re-initialised.
> 
> At this point, what is the state of variables such as priv->is_on if
> you allocate the structure at probe time?
> 
> What about all the other variables in the driver private structure - are
> you sure that the driver can cope with random values from the previous
> "usage" remaining there?
> 
> At the moment, this isn't a concern for the driver because we
> dev_kzalloc() the structure in the bind callback.  Move that to the
> probe function, and the structure is no longer re-initialised each
> time, and so it retains the previous state.  The driver is not setup
> to cope with that.
> 
> So, to work around that, you would need to reinitialise _everything_
> in the structure that the driver requires, which IMHO is a very
> open to bugs (eg, if a member is missed, or added without the
> necessary re-initialisation), _especially_ when this is not a path
> that will get regular testing.
> 
> If you want to do this for a subset of data, it would be much better
> to separate them into independent structures (maybe one embedded into
> the other) so that this problem can not occur.  That way, a subset
> of the data can be memset() when bound to the rest of the DRM system
> ensuring a consistent driver state and still achieve what you're
> suggesting.

This was the exact reason I added struct tda998x_bridge. It seemed
very risky to move the tda998x_create call (or some of its meat) to
the probe function. Even if that could be done I think it should
definitely be a separate patch.

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

Re: [PATCH v3 7/7] drm/i2c: tda998x: register as a drm bridge

[Russell King - ARM Linux]

On Fri, Apr 20, 2018 at 01:06:49PM +0300, Laurent Pinchart wrote:
> Hi Peter,
> 
> Thank you for the patch.
> 
> On Thursday, 19 April 2018 19:27:51 EEST Peter Rosin wrote:
> > This makes this driver work with all(?) drivers that are not
> > componentized and instead expect to connect to a panel/bridge. That
> > said, the only one tested is atmel_hlcdc.
> > 
> > This hooks the relevant work function previously called by the encoder
> > and the component also to the bridge, since the encoder goes away when
> > connecting to the bridge interface of the driver and the equivalent of
> > bind/unbind of the component is handled by bridge attach/detach.
> > 
> > The lifetime requirements of a bridge and a component are slightly
> > different, which is the reason for struct tda998x_bridge.
> 
> Couldn't you move the allocation and initialization (tda998x_create) of the 
> tda998x_priv structure to probe time ? I think you wouldn't need a separate 
> structure in that case. Unless I'm mistaken there would be an added benefit 
> of 
> separating component and bridge initialization, resulting in the encoder not 
> being initialized at all if the component isn't used. You wouldn't need to 
> add 
> a local_encoder parameter to the tda998x_init() function.

No, I don't like that idea one bit, as I've stated in the past about the
component API.  The same (probably) goes for the bridge stuff too.

Consider the following:

Your DRM system is initialised.  You then remove a module, which results
in the DRM system being torn down.  You re-insert the module (eg, having
made a change to it).  The DRM system is then re-initialised.

At this point, what is the state of variables such as priv->is_on if
you allocate the structure at probe time?

What about all the other variables in the driver private structure - are
you sure that the driver can cope with random values from the previous
"usage" remaining there?

At the moment, this isn't a concern for the driver because we
dev_kzalloc() the structure in the bind callback.  Move that to the
probe function, and the structure is no longer re-initialised each
time, and so it retains the previous state.  The driver is not setup
to cope with that.

So, to work around that, you would need to reinitialise _everything_
in the structure that the driver requires, which IMHO is a very
open to bugs (eg, if a member is missed, or added without the
necessary re-initialisation), _especially_ when this is not a path
that will get regular testing.

If you want to do this for a subset of data, it would be much better
to separate them into independent structures (maybe one embedded into
the other) so that this problem can not occur.  That way, a subset
of the data can be memset() when bound to the rest of the DRM system
ensuring a consistent driver state and still achieve what you're
suggesting.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 5/7] drm/i2c: tda9950: add CEC driver

[Russell King - ARM Linux]

Hi Hans,

Any comments?

Thanks.

On Mon, Apr 09, 2018 at 01:16:32PM +0100, Russell King wrote:
> Add a CEC driver for the TDA9950, which is a stand-alone I2C CEC device,
> but is also integrated into HDMI transceivers such as the TDA9989 and
> TDA19989.
> 
> The TDA9950 contains a command processor which handles retransmissions
> and the low level bus protocol.  The driver just has to read and write
> the messages, and handle error conditions.
> 
> Signed-off-by: Russell King 
> ---
>  drivers/gpu/drm/i2c/Kconfig   |   5 +
>  drivers/gpu/drm/i2c/Makefile  |   1 +
>  drivers/gpu/drm/i2c/tda9950.c | 509 
> ++
>  include/linux/platform_data/tda9950.h |  16 ++
>  4 files changed, 531 insertions(+)
>  create mode 100644 drivers/gpu/drm/i2c/tda9950.c
>  create mode 100644 include/linux/platform_data/tda9950.h
> 
> diff --git a/drivers/gpu/drm/i2c/Kconfig b/drivers/gpu/drm/i2c/Kconfig
> index a6c92beb410a..3a232f5ff0a1 100644
> --- a/drivers/gpu/drm/i2c/Kconfig
> +++ b/drivers/gpu/drm/i2c/Kconfig
> @@ -26,4 +26,9 @@ config DRM_I2C_NXP_TDA998X
>   help
> Support for NXP Semiconductors TDA998X HDMI encoders.
>  
> +config DRM_I2C_NXP_TDA9950
> + tristate "NXP Semiconductors TDA9950/TDA998X HDMI CEC"
> + select CEC_NOTIFIER
> + select CEC_CORE
> +
>  endmenu
> diff --git a/drivers/gpu/drm/i2c/Makefile b/drivers/gpu/drm/i2c/Makefile
> index b20100c18ffb..a962f6f08568 100644
> --- a/drivers/gpu/drm/i2c/Makefile
> +++ b/drivers/gpu/drm/i2c/Makefile
> @@ -7,3 +7,4 @@ obj-$(CONFIG_DRM_I2C_SIL164) += sil164.o
>  
>  tda998x-y := tda998x_drv.o
>  obj-$(CONFIG_DRM_I2C_NXP_TDA998X) += tda998x.o
> +obj-$(CONFIG_DRM_I2C_NXP_TDA9950) += tda9950.o
> diff --git a/drivers/gpu/drm/i2c/tda9950.c b/drivers/gpu/drm/i2c/tda9950.c
> new file mode 100644
> index ..3f7396caad48
> --- /dev/null
> +++ b/drivers/gpu/drm/i2c/tda9950.c
> @@ -0,0 +1,509 @@
> +/*
> + *  TDA9950 Consumer Electronics Control driver
> + *
> + * 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.
> + *
> + * The NXP TDA9950 implements the HDMI Consumer Electronics Control
> + * interface.  The host interface is similar to a mailbox: the data
> + * registers starting at REG_CDR0 are written to send a command to the
> + * internal CPU, and replies are read from these registers.
> + *
> + * As the data registers represent a mailbox, they must be accessed
> + * as a single I2C transaction.  See the TDA9950 data sheet for details.
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +enum {
> + REG_CSR = 0x00,
> + CSR_BUSY = BIT(7),
> + CSR_INT  = BIT(6),
> + CSR_ERR  = BIT(5),
> +
> + REG_CER = 0x01,
> +
> + REG_CVR = 0x02,
> +
> + REG_CCR = 0x03,
> + CCR_RESET = BIT(7),
> + CCR_ON= BIT(6),
> +
> + REG_ACKH = 0x04,
> + REG_ACKL = 0x05,
> +
> + REG_CCONR = 0x06,
> + CCONR_ENABLE_ERROR = BIT(4),
> + CCONR_RETRY_MASK = 7,
> +
> + REG_CDR0 = 0x07,
> +
> + CDR1_REQ = 0x00,
> + CDR1_CNF = 0x01,
> + CDR1_IND = 0x81,
> + CDR1_ERR = 0x82,
> + CDR1_IER = 0x83,
> +
> + CDR2_CNF_SUCCESS= 0x00,
> + CDR2_CNF_OFF_STATE  = 0x80,
> + CDR2_CNF_BAD_REQ= 0x81,
> + CDR2_CNF_CEC_ACCESS = 0x82,
> + CDR2_CNF_ARB_ERROR  = 0x83,
> + CDR2_CNF_BAD_TIMING = 0x84,
> + CDR2_CNF_NACK_ADDR  = 0x85,
> + CDR2_CNF_NACK_DATA  = 0x86,
> +};
> +
> +struct tda9950_priv {
> + struct i2c_client *client;
> + struct device *hdmi;
> + struct cec_adapter *adap;
> + struct tda9950_glue *glue;
> + u16 addresses;
> + struct cec_msg rx_msg;
> + struct cec_notifier *notify;
> + bool open;
> +};
> +
> +static int tda9950_write_range(struct i2c_client *client, u8 addr, u8 *p, 
> int cnt)
> +{
> + struct i2c_msg msg;
> + u8 buf[cnt + 1];
> + int ret;
> +
> + buf[0] = addr;
> + memcpy(buf + 1, p, cnt);
> +
> + msg.addr = client->addr;
> + msg.flags = 0;
> + msg.len = cnt + 1;
> + msg.buf = buf;
> +
> + dev_dbg(>dev, "wr 0x%02x: %*ph\n", addr, cnt, p);
> +
> + ret = i2c_transfer(client->adapter, , 1);
> + if (ret < 0)
> + dev_err(>dev, "Error %d writing to cec:0x%x\n", ret, 
> addr);
> + return ret < 0 ? ret : 0;
> +}
> +
> +static void tda9950_write(struct i2c_client *client, u8 addr, u8 val)
> +{
> + tda9950_write_range(client, addr, , 1);
> +}
> +
> +static int tda9950_read_range(struct i2c_client *client, u8 addr, u8 *p, int 
> cnt)
> +{
> + struct i2c_msg msg[2];
> + int ret;
> +
> + msg[0].addr = client->addr;
> + msg[0].flags = 0;
> + msg[0].len = 1;
> + msg[0].buf = 
> + msg[1].addr = client->addr;
> + msg[1].flags = I2C_M_RD;
> + 

[PATCH v3 1/6] drm/panel: Add support for the EDT ETM0700G0BDH6

[jan.tuerk]

From: Jan Tuerk 

The Emerging Display Technology ETM0700G0BDH6 is exactly
the same display as the ETM0700G0DH6, exept the pixelclock
polarity. Therefore re-use the ETM0700G0DH6 modes. It is
used by default on emtrion Avari based development kits.

Signed-off-by: Jan Tuerk 
---
 drivers/gpu/drm/panel/panel-simple.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index cbf1ab404ee7..8b7feb2888f2 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -909,6 +909,18 @@ static const struct panel_desc edt_etm0700g0dh6 = {
.bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_NEGEDGE,
 };
 
+static const struct panel_desc edt_etm0700g0bdh6 = {
+   .modes = _etm0700g0dh6_mode,
+   .num_modes = 1,
+   .bpc = 6,
+   .size = {
+   .width = 152,
+   .height = 91,
+   },
+   .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
+   .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_POSEDGE,
+};
+
 static const struct drm_display_mode foxlink_fl500wvr00_a0t_mode = {
.clock = 32260,
.hdisplay = 800,
@@ -2134,6 +2146,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "edt,etm0700g0dh6",
.data = _etm0700g0dh6,
}, {
+   .compatible = "edt,etm0700g0bdh6",
+   .data = _etm0700g0bdh6,
+   }, {
.compatible = "foxlink,fl500wvr00-a0t",
.data = _fl500wvr00_a0t,
}, {
-- 
2.11.0

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

[PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

[Mauro Carvalho Chehab]

Add stubs for omapfb_dss.h, in the case it is included by
some driver when CONFIG_FB_OMAP2 is not defined, with can
happen on ARM when DRM_OMAP is not 'n'.

That allows building such driver(s) with COMPILE_TEST.

Signed-off-by: Mauro Carvalho Chehab 
---
 include/video/omapfb_dss.h | 54 --
 1 file changed, 52 insertions(+), 2 deletions(-)

diff --git a/include/video/omapfb_dss.h b/include/video/omapfb_dss.h
index 1d38901d599d..e9775144ff3b 100644
--- a/include/video/omapfb_dss.h
+++ b/include/video/omapfb_dss.h
@@ -774,6 +774,12 @@ struct omap_dss_driver {
const struct hdmi_avi_infoframe *avi);
 };
 
+#define for_each_dss_dev(d) while ((d = omap_dss_get_next_device(d)) != NULL)
+
+typedef void (*omap_dispc_isr_t) (void *arg, u32 mask);
+
+#ifdef CONFIG_FB_OMAP2
+
 enum omapdss_version omapdss_get_version(void);
 bool omapdss_is_initialized(void);
 
@@ -785,7 +791,6 @@ void omapdss_unregister_display(struct omap_dss_device 
*dssdev);
 
 struct omap_dss_device *omap_dss_get_device(struct omap_dss_device *dssdev);
 void omap_dss_put_device(struct omap_dss_device *dssdev);
-#define for_each_dss_dev(d) while ((d = omap_dss_get_next_device(d)) != NULL)
 struct omap_dss_device *omap_dss_get_next_device(struct omap_dss_device *from);
 struct omap_dss_device *omap_dss_find_device(void *data,
int (*match)(struct omap_dss_device *dssdev, void *data));
@@ -826,7 +831,6 @@ int omapdss_default_get_recommended_bpp(struct 
omap_dss_device *dssdev);
 void omapdss_default_get_timings(struct omap_dss_device *dssdev,
struct omap_video_timings *timings);
 
-typedef void (*omap_dispc_isr_t) (void *arg, u32 mask);
 int omap_dispc_register_isr(omap_dispc_isr_t isr, void *arg, u32 mask);
 int omap_dispc_unregister_isr(omap_dispc_isr_t isr, void *arg, u32 mask);
 
@@ -856,5 +860,51 @@ omapdss_of_get_first_endpoint(const struct device_node 
*parent);
 
 struct omap_dss_device *
 omapdss_of_find_source_for_first_ep(struct device_node *node);
+#else
+
+static inline enum omapdss_version omapdss_get_version(void)
+{ return OMAPDSS_VER_UNKNOWN; };
+
+static inline bool omapdss_is_initialized(void)
+{ return false; };
+
+static inline int omap_dispc_register_isr(omap_dispc_isr_t isr,
+ void *arg, u32 mask)
+{ return 0; };
+
+static inline int omap_dispc_unregister_isr(omap_dispc_isr_t isr,
+   void *arg, u32 mask)
+{ return 0; };
+
+static inline struct omap_dss_device
+*omap_dss_get_device(struct omap_dss_device *dssdev)
+{ return NULL; };
+
+static inline struct omap_dss_device
+*omap_dss_get_next_device(struct omap_dss_device *from)
+{return NULL; };
+
+static inline void omap_dss_put_device(struct omap_dss_device *dssdev) {};
+
+static inline int omapdss_compat_init(void)
+{ return 0; };
+
+static inline void omapdss_compat_uninit(void) {};
+
+static inline int omap_dss_get_num_overlay_managers(void)
+{ return 0; };
+
+static inline struct omap_overlay_manager *omap_dss_get_overlay_manager(int 
num)
+{ return NULL; };
+
+static inline int omap_dss_get_num_overlays(void)
+{ return 0; };
+
+static inline struct omap_overlay *omap_dss_get_overlay(int num)
+{ return NULL; };
+
+
+#endif /* FB_OMAP2 */
+
 
 #endif /* __OMAPFB_DSS_H */
-- 
2.14.3

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

Re: [PATCH 1/8] drm/mediatek: Use regmap for register access

[Matthias Brugger]

Hi Philipp,

On 11/23/2017 09:54 AM, Philipp Zabel wrote:
> Hi Matthias,
> 
> On Tue, 2017-11-14 at 22:41 +0100, Matthias Brugger wrote:
>> The mmsys memory space is shared between the drm and the
>> clk driver. Use regmap to access it.
>>
>> Signed-off-by: Matthias Brugger 
>> ---
>>  drivers/gpu/drm/mediatek/mtk_drm_crtc.c |  4 ++--
>>  drivers/gpu/drm/mediatek/mtk_drm_ddp.c  | 30 +-
>>  drivers/gpu/drm/mediatek/mtk_drm_ddp.h  |  4 ++--
>>  drivers/gpu/drm/mediatek/mtk_drm_drv.c  | 13 -
>>  drivers/gpu/drm/mediatek/mtk_drm_drv.h  |  2 +-
>>  5 files changed, 26 insertions(+), 27 deletions(-)
> [...]
[...]
>>  }
>>  
>>  value = mtk_ddp_sel_in(cur, next, );
>>  if (value) {
>> -reg = readl_relaxed(config_regs + addr) & ~value;
>> -writel_relaxed(reg, config_regs + addr);
>> +regmap_read(config_regs, addr, );
>> +reg &= ~value;
>> +regmap_write(config_regs, addr, reg);
> 
>   regmap_update_bits(config_regs, addr, value, 0);
> 
> Reviewed-by: Philipp Zabel 
> 

Thanks for having a look on that.

I'll update the next version with regmap_update_bits and leave your Reviewed-by,
hope that's ok.

Regards,
Matthias

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

Re: [PATCH v3 0/7] Add tda998x (HDMI) support to atmel-hlcdc

[Peter Rosin]

On 2018-04-20 13:38, jacopo mondi wrote:
> Hi Peter,
> 
> On Fri, Apr 20, 2018 at 01:05:21PM +0200, Peter Rosin wrote:
>> On 2018-04-20 12:18, Laurent Pinchart wrote:
>>> Hello,
>>>
>>> On Friday, 20 April 2018 11:52:35 EEST jacopo mondi wrote:
 Hi Peter,
 I've been a bit a pain in the arse for you recently, but please
 bear with me a bit more, and sorry for jumping late on the band wagon.

 On Thu, Apr 19, 2018 at 06:27:44PM +0200, Peter Rosin wrote:
> Hi!
>
> I naively thought that since there was support for both nxp,tda19988 (in
> the tda998x driver) and the atmel-hlcdc, things would be a smooth ride.
> But it wasn't, so I started looking around and realized I had to fix
> things.
>
> In v1 and v2 I fixed things by making the atmel-hlcdc driver a master
> component, but now in v3 I fix things by making the tda998x driver
> a bridge instead. This was after a suggestion from Boris Brezillion
>>
>> That should be Brezillon, sorry for being sloppy with the spelling.
>>
> (the atmel-hlcdc maintainer), so there was some risk of bias ... but
> after comparing what was needed, I too find the bridge approach better.
>
> In addition to the above, our PCB interface between the SAMA5D3 and the
> HDMI encoder is only using 16 bits, and this has to be described
> somewhere, or the atmel-hlcdc driver have no chance of selecting the
> correct output mode. Since I have similar problems with a ds90c185 lvds
> encoder I added patches to override the atmel-hlcdc output format via
> DT properties compatible with the media video-interface binding and
> things start to play together.
>
> Since this series superseeds the bridge series [1], I have included the
> leftover bindings patch for the ti,ds90c185 here.

 I feel like this series would look better if it would make use of the
 proposed bridge media bus format support I have recently sent out [1]
 (and which was not there when you first sent v1).

 I understand your fundamental problem here is that the bus format
 that should be reported by your bridge is different from the ones
 actually supported by the TDA19988 chip, as the wirings ground some
 of the input pins.

 Although this is defintely something that could be described in the
 bridge's own OF node with the 'bus_width' property, and what I would do,
 now that you have made a bridge out from the tda19988 driver, is:

 1) Set the bridge accepted input bus_format parsing its pin
 configuration, or default it if that's not implemented yet.
 This will likely be rgb888. You can do that using the trivial
 support for bridge input image formats implemented by my series.
 2) Specify in the bridge endpoint a 'bus_width' of <16>
 3) In your atmel-hlcd get both the image format of the bridge (rgb888)
 and parse the remote endpoint property 'bus_width' and get the <16>
 value back.
>>>
>>> Parsing properties of remote nodes should be avoided as much as possible, as
>>> they need to be interpreted in the context of the DT bindings related to the
>>> compatible string applicable to that node. I'd rather have the bus_width
>>> property in the local endpoint node.
>>
>> In addition to that, my view of this binding
>>
>>  endpoint {
>>  bus-type = <0>;
> 
> bus-type is used by v4l2_fwnode helpers to decide which type of bus
> they're dealing with iirc. Here it seems to me it has no added
> value, also because in your bindings description "it shall be 0" and
> it is not parsed anywhere in you code, but no big deal

bus-type is indeed parsed and verified to be zero which means auto-detect
according to the video-interfaces binding. An auto-detect bus-type with
a given bus-width means a parallel interface IIUC.

From patch 3/7:

if (of_property_read_u32(node, "bus-type", _type))
return 0;
if (bus_type != 0)
return -EINVAL;


>>  bus-widht = <16>;
>>  };
>>
>> is that it always means rgb565. See further below.
>>
 4) Set the correct format in the atmel hlcd driver to accommodate a
 bridge that wants rgb888 on a 16 bit wide bus (that would be rgb565,
 or are there other possible combinations I am missing?)

 I would consider this better mostly because in this series you are
 creating a semantic for the whole DRM subsystem on the 'bus_width'
 property, where numerical values as '12', '16' etc are arbitrary tied
 to the selection of a media bus format. At least you should use a
 common set of defines [1] between the device tree and the driver,
 but this looks anyway fragile imho.
>>>
>>> This I agree with though. Combining the remote bus format with the local bus
>>> width should fix the problem without having to parse remote properties.
>>
>> My thinking was that the binding with bus-type = <0> and bus-width = 
>> 

Re: [PATCH v6 24/30] drm/rockchip: Disable PSR on input events

[Enric Balletbo i Serra]

Hi Andrzej,

On 20/04/18 15:47, Andrzej Hajda wrote:
> Hi Enric,
> 
> 
> On 05.04.2018 11:49, Enric Balletbo i Serra wrote:
>> From: "Kristian H. Kristensen" 
>>
>> To improve PSR exit latency, we speculatively start exiting when we
>> receive input events. Occasionally, this may lead to false positives,
>> but most of the time we get a head start on coming out of PSR. Depending
>> on how userspace takes to produce a new frame in response to the event,
>> this can completely hide the exit latency. In case of Chrome OS, we
>> typically get the input notifier 50ms or more before the dirty_fb
>> triggered exit.
> 
> This patch is quite controversial and require more attention/discussion
> and probably changes.

Agree.

> The rest of the patches is OK, and all have r-b/t-b tags.
> If you prefer I can merge all other patches, if you rebase patches 25-30
> on top of patch 23, or I can only merge patches 01-23.
> What do you prefer?
> 

If the patches 25-30 are also fine let me rebase those, and lets start a
discussion regarding patches 23-25 on another patchset. I'll send another
version without 23-25.

Regards,
 Enric

> Regards
> Andrzej
> 
>>
>> Signed-off-by: Kristian H. Kristensen 
>> Signed-off-by: Thierry Escande 
>> Signed-off-by: Enric Balletbo i Serra 
>> Tested-by: Marek Szyprowski 
>> ---
>>
>>  drivers/gpu/drm/rockchip/rockchip_drm_psr.c | 134 
>> 
>>  1 file changed, 134 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c 
>> b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
>> index 9376f4396b6b..a107845ba97c 100644
>> --- a/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
>> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_psr.c
>> @@ -12,6 +12,8 @@
>>   * GNU General Public License for more details.
>>   */
>>  
>> +#include 
>> +
>>  #include 
>>  #include 
>>  
>> @@ -35,6 +37,9 @@ struct psr_drv {
>>  enum psr_state  state;
>>  
>>  struct delayed_work flush_work;
>> +struct work_struct  disable_work;
>> +
>> +struct input_handlerinput_handler;
>>  
>>  int (*set)(struct drm_encoder *encoder, bool enable);
>>  };
>> @@ -133,6 +138,18 @@ static void psr_flush_handler(struct work_struct *work)
>>  mutex_unlock(>lock);
>>  }
>>  
>> +static void psr_disable_handler(struct work_struct *work)
>> +{
>> +struct psr_drv *psr = container_of(work, struct psr_drv, disable_work);
>> +
>> +/* If the state has changed since we initiated the flush, do nothing */
>> +mutex_lock(>lock);
>> +if (psr->state == PSR_ENABLE)
>> +psr_set_state_locked(psr, PSR_FLUSH);
>> +mutex_unlock(>lock);
>> +mod_delayed_work(system_wq, >flush_work, PSR_FLUSH_TIMEOUT_MS);
>> +}
>> +
>>  /**
>>   * rockchip_drm_psr_activate - activate PSR on the given pipe
>>   * @encoder: encoder to obtain the PSR encoder
>> @@ -173,6 +190,7 @@ int rockchip_drm_psr_deactivate(struct drm_encoder 
>> *encoder)
>>  psr->active = false;
>>  mutex_unlock(>lock);
>>  cancel_delayed_work_sync(>flush_work);
>> +cancel_work_sync(>disable_work);
>>  
>>  return 0;
>>  }
>> @@ -226,6 +244,95 @@ void rockchip_drm_psr_flush_all(struct drm_device *dev)
>>  }
>>  EXPORT_SYMBOL(rockchip_drm_psr_flush_all);
>>  
>> +static void psr_input_event(struct input_handle *handle,
>> +unsigned int type, unsigned int code,
>> +int value)
>> +{
>> +struct psr_drv *psr = handle->handler->private;
>> +
>> +schedule_work(>disable_work);
>> +}
>> +
>> +static int psr_input_connect(struct input_handler *handler,
>> + struct input_dev *dev,
>> + const struct input_device_id *id)
>> +{
>> +struct input_handle *handle;
>> +int error;
>> +
>> +handle = kzalloc(sizeof(struct input_handle), GFP_KERNEL);
>> +if (!handle)
>> +return -ENOMEM;
>> +
>> +handle->dev = dev;
>> +handle->handler = handler;
>> +handle->name = "rockchip-psr";
>> +
>> +error = input_register_handle(handle);
>> +if (error)
>> +goto err2;
>> +
>> +error = input_open_device(handle);
>> +if (error)
>> +goto err1;
>> +
>> +return 0;
>> +
>> +err1:
>> +input_unregister_handle(handle);
>> +err2:
>> +kfree(handle);
>> +return error;
>> +}
>> +
>> +static void psr_input_disconnect(struct input_handle *handle)
>> +{
>> +input_close_device(handle);
>> +input_unregister_handle(handle);
>> +kfree(handle);
>> +}
>> +
>> +/* Same device ids as cpu-boost */
>> +static const struct input_device_id psr_ids[] = {
>> +{
>> +.flags = INPUT_DEVICE_ID_MATCH_EVBIT |
>> + INPUT_DEVICE_ID_MATCH_ABSBIT,
>> +.evbit = { BIT_MASK(EV_ABS) },
>> +.absbit = { [BIT_WORD(ABS_MT_POSITION_X)] =
>> +  

Re: [PATCH v3 7/7] drm/i2c: tda998x: register as a drm bridge

[Russell King - ARM Linux]

On Fri, Apr 20, 2018 at 12:49:42PM +0200, Peter Rosin wrote:
> On 2018-04-20 12:41, kbuild test robot wrote:
> > Hi Peter,
> > 
> > I love your patch! Yet something to improve:
> 
> Yup, right you are!
> 
> > [auto build test ERROR on drm/drm-next]
> > [also build test ERROR on v4.17-rc1 next-20180420]
> > [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/Peter-Rosin/Add-tda998x-HDMI-support-to-atmel-hlcdc/20180420-160131
> > base:   git://people.freedesktop.org/~airlied/linux.git drm-next
> > config: i386-randconfig-a0-201815 (attached as .config)
> > compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
> > reproduce:
> > # save the attached .config to linux build tree
> > make ARCH=i386 
> > 
> > All errors (new ones prefixed by >>):
> > 
> >drivers/gpu/drm/i2c/tda998x_drv.c: In function 'tda998x_probe':
> >>> drivers/gpu/drm/i2c/tda998x_drv.c:1859:16: error: 'struct drm_bridge' has 
> >>> no member named 'of_node'
> >  bridge->bridge.of_node = dev->of_node;
> >^
> 
> Anybody got a better fix than this?
> 
> #ifdef CONFIG_OF
>   bridge->bridge.of_node = dev->of_node;
> #endif

How about the bridge code provides a helper to do this, something like:

static inline void bridge_set_device(struct drm_bridge *bridge,
 struct device *dev)
{
#ifdef CONFIG_OF
bridge->of_node = dev->of_node;
#endif
}

which (a) nicely hides the firmware flavour, and (b) hides the ifdef in
the bridge header where it belongs.  If the bridge code needs to be
converted to fwnode in the future, at least this would be abstracted
from the drivers.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] drm/exynos: Allow DRM_EXYNOS on s5pv210

[Paweł Chmiel]

This patch brings back possibility to use drivers depending on
DRM_EXYNOS, on Samsung S5PV210/S5PC110 series based systems.

Fixes: dbbc925bb83a ("drm/exynos: depend on ARCH_EXYNOS for DRM_EXYNOS")
Signed-off-by: Paweł Chmiel 
---
 drivers/gpu/drm/exynos/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 735ce47688f9..1548a784ef71 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -1,6 +1,6 @@
 config DRM_EXYNOS
tristate "DRM Support for Samsung SoC EXYNOS Series"
-   depends on OF && DRM && (ARCH_S3C64XX || ARCH_EXYNOS || 
ARCH_MULTIPLATFORM)
+   depends on OF && DRM && (ARCH_S3C64XX || ARCH_S5PV210 || ARCH_EXYNOS || 
ARCH_MULTIPLATFORM)
select DRM_KMS_HELPER
select VIDEOMODE_HELPERS
select SND_SOC_HDMI_CODEC if SND_SOC
-- 
2.7.4

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

Re: [PATCH 4/8] clk: mediatek: mt2701-mm: switch to mfd device

[Matthias Brugger]

On 04/20/2018 03:00 PM, Matthias Brugger wrote:
> Hi Stephen,
> 
> On 11/15/2017 01:17 AM, Stephen Boyd wrote:
>> On 11/14, Matthias Brugger wrote:
>>> As the new mfd device is in place, switch probing
>>> for the MMSYS to support invocation from the mfd device.
>>>
>>> Signed-off-by: Matthias Brugger 
>>> ---
>>
>> Acked-by: Stephen Boyd 
>>
> 
> I did a minor change to this patch and patch 7/8 to get rid of mmsys_private
> variable. Nevertheless I kept your Acked-by, as it only changes how we get the
> device tree node.
> 
> Hope that's OK with you.
> 

Sorry, I didn't explain me. I'm talking about v2 of the series, which I'm
working on right now.

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

[PATCH v3 4/6] ARM: dts: imx: Add an cpu0 label for imx6dl devices.

[jan.tuerk]

From: Jan Tuerk 

Adding the label cpu0 allows the adjustment of cpu-parameters
by reference in overlaying dtsi files in the same way as it
is possible for imx6q devices.

Signed-off-by: Jan Tuerk 
---
 arch/arm/boot/dts/imx6dl.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
index 558bce81209d..fc658bf3a693 100644
--- a/arch/arm/boot/dts/imx6dl.dtsi
+++ b/arch/arm/boot/dts/imx6dl.dtsi
@@ -21,7 +21,7 @@
#address-cells = <1>;
#size-cells = <0>;
 
-   cpu@0 {
+   cpu0: cpu@0 {
compatible = "arm,cortex-a9";
device_type = "cpu";
reg = <0>;
-- 
2.11.0

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

Re: [PATCH v3 0/7] Add tda998x (HDMI) support to atmel-hlcdc

[Peter Rosin]

On 2018-04-20 12:18, Laurent Pinchart wrote:
> Hello,
> 
> On Friday, 20 April 2018 11:52:35 EEST jacopo mondi wrote:
>> Hi Peter,
>> I've been a bit a pain in the arse for you recently, but please
>> bear with me a bit more, and sorry for jumping late on the band wagon.
>>
>> On Thu, Apr 19, 2018 at 06:27:44PM +0200, Peter Rosin wrote:
>>> Hi!
>>>
>>> I naively thought that since there was support for both nxp,tda19988 (in
>>> the tda998x driver) and the atmel-hlcdc, things would be a smooth ride.
>>> But it wasn't, so I started looking around and realized I had to fix
>>> things.
>>>
>>> In v1 and v2 I fixed things by making the atmel-hlcdc driver a master
>>> component, but now in v3 I fix things by making the tda998x driver
>>> a bridge instead. This was after a suggestion from Boris Brezillion

That should be Brezillon, sorry for being sloppy with the spelling.

>>> (the atmel-hlcdc maintainer), so there was some risk of bias ... but
>>> after comparing what was needed, I too find the bridge approach better.
>>>
>>> In addition to the above, our PCB interface between the SAMA5D3 and the
>>> HDMI encoder is only using 16 bits, and this has to be described
>>> somewhere, or the atmel-hlcdc driver have no chance of selecting the
>>> correct output mode. Since I have similar problems with a ds90c185 lvds
>>> encoder I added patches to override the atmel-hlcdc output format via
>>> DT properties compatible with the media video-interface binding and
>>> things start to play together.
>>>
>>> Since this series superseeds the bridge series [1], I have included the
>>> leftover bindings patch for the ti,ds90c185 here.
>>
>> I feel like this series would look better if it would make use of the
>> proposed bridge media bus format support I have recently sent out [1]
>> (and which was not there when you first sent v1).
>>
>> I understand your fundamental problem here is that the bus format
>> that should be reported by your bridge is different from the ones
>> actually supported by the TDA19988 chip, as the wirings ground some
>> of the input pins.
>>
>> Although this is defintely something that could be described in the
>> bridge's own OF node with the 'bus_width' property, and what I would do,
>> now that you have made a bridge out from the tda19988 driver, is:
>>
>> 1) Set the bridge accepted input bus_format parsing its pin
>> configuration, or default it if that's not implemented yet.
>> This will likely be rgb888. You can do that using the trivial
>> support for bridge input image formats implemented by my series.
>> 2) Specify in the bridge endpoint a 'bus_width' of <16>
>> 3) In your atmel-hlcd get both the image format of the bridge (rgb888)
>> and parse the remote endpoint property 'bus_width' and get the <16>
>> value back.
> 
> Parsing properties of remote nodes should be avoided as much as possible, as 
> they need to be interpreted in the context of the DT bindings related to the 
> compatible string applicable to that node. I'd rather have the bus_width 
> property in the local endpoint node.

In addition to that, my view of this binding

endpoint {
bus-type = <0>;
bus-widht = <16>;
};

is that it always means rgb565. See further below.

>> 4) Set the correct format in the atmel hlcd driver to accommodate a
>> bridge that wants rgb888 on a 16 bit wide bus (that would be rgb565,
>> or are there other possible combinations I am missing?)
>>
>> I would consider this better mostly because in this series you are
>> creating a semantic for the whole DRM subsystem on the 'bus_width'
>> property, where numerical values as '12', '16' etc are arbitrary tied
>> to the selection of a media bus format. At least you should use a
>> common set of defines [1] between the device tree and the driver,
>> but this looks anyway fragile imho.
> 
> This I agree with though. Combining the remote bus format with the local bus 
> width should fix the problem without having to parse remote properties.

My thinking was that the binding with bus-type = <0> and bus-width = 
would mean a parallel bus (type 0 means auto-detect and with a bus-width that
auto-detect means a parallel bus) and the most natural/common interpretation
of that bus-width. For bus widths of 12, 16, 18, 24, 30 etc I think that
would be rgb444, rgb565, rgb666, rgb888, rgb101010 (or, I'm first so I get
to define the default). If you have some other interpretation of a bus with
that width, you'd need to extend the video-interface binding with some way
of saying what you need, perhaps using some kind of data mapping or something
to say e.g. bgr666. And you'd need some kind of indicator if you have YUV
signals instead of RGB, and LVDS isn't a completely parallel bus, so you'd
need something for that. Etc.

Because the word from Rob was that there should be one common binding that
describes video interfaces. I started an implementation that interprets that
binding in a drm context in
[PATCH 3/7] drm: of: 

Re: [PATCH 4/8] clk: mediatek: mt2701-mm: switch to mfd device

[Matthias Brugger]

Hi Stephen,

On 11/15/2017 01:17 AM, Stephen Boyd wrote:
> On 11/14, Matthias Brugger wrote:
>> As the new mfd device is in place, switch probing
>> for the MMSYS to support invocation from the mfd device.
>>
>> Signed-off-by: Matthias Brugger 
>> ---
> 
> Acked-by: Stephen Boyd 
> 

I did a minor change to this patch and patch 7/8 to get rid of mmsys_private
variable. Nevertheless I kept your Acked-by, as it only changes how we get the
device tree node.

Hope that's OK with you.

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

[PATCH 1/2] drm/exynos: fimd: Add support for S5PV210 FIMD variant

[Paweł Chmiel]

From: Tomasz Figa 

This patch adds support for FIMD variant found on S5PV210 SoC.
Except CLKSEL bit availability, it is identical to Exynos4210.

Tested-by: Paweł Chmiel 
Signed-off-by: Tomasz Figa 
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index d42ae2bc3e56..01b1570d0c3a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -121,6 +121,12 @@ static struct fimd_driver_data s3c64xx_fimd_driver_data = {
.has_limited_fmt = 1,
 };
 
+static struct fimd_driver_data s5pv210_fimd_driver_data = {
+   .timing_base = 0x0,
+   .has_shadowcon = 1,
+   .has_clksel = 1,
+};
+
 static struct fimd_driver_data exynos3_fimd_driver_data = {
.timing_base = 0x2,
.lcdblk_offset = 0x210,
@@ -193,6 +199,8 @@ struct fimd_context {
 static const struct of_device_id fimd_driver_dt_match[] = {
{ .compatible = "samsung,s3c6400-fimd",
  .data = _fimd_driver_data },
+   { .compatible = "samsung,s5pv210-fimd",
+ .data = _fimd_driver_data },
{ .compatible = "samsung,exynos3250-fimd",
  .data = _fimd_driver_data },
{ .compatible = "samsung,exynos4210-fimd",
-- 
2.7.4

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

Re: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for Geminilake

[Ian W MORRISON]

On 20 April 2018 at 17:50, Jani Nikula  wrote:
> On Fri, 20 Apr 2018, Ian W MORRISON  wrote:
>> I've performed backport testing and some additional analysis as follows:
>
> What testing did you do beyond booting? Did you run igt?
>
> BR,
> Jani.

I did some basic testing including running a 4K video on Chrome whilst
running intel_gpu_top. The intel_gpu_top program doesn't display
anything on 4.12 either with or without the patch as neither I nor
Canonical enabled CONFIG_DRM_I915_ALPHA_SUPPORT. Do you think that the
stable tag should exclude 4.12 because of the 'alpha quality support'
and if so do you want a V2 of the patch?

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

[PATCH] drivers: omap2: Kconfig: make FB_OMAP2_DSS_INIT depend on OF

[Anders Roxell]

Commit 7378f1149884 ("media: omap2: omapfb: allow building it with
COMPILE_TEST") broke compilation without CONFIG_OF selected.
  CC  drivers/video/fbdev/core/fbmem.o
drivers/video/fbdev/omap2/omapfb/dss/omapdss-boot-init.c: In function 
‘omapdss_update_prop’:
drivers/video/fbdev/omap2/omapfb/dss/omapdss-boot-init.c:68:2: error: implicit 
declaration of function ‘of_update_property’; did you mean ‘of_get_property’? 
[-Werror=implicit-function-declaration]
  of_update_property(node, prop);
  ^~
  of_get_property
cc1: some warnings being treated as errors
scripts/Makefile.build:312: recipe for target 
'drivers/video/fbdev/omap2/omapfb/dss/omapdss-boot-init.o' failed
make[7]: *** [drivers/video/fbdev/omap2/omapfb/dss/omapdss-boot-init.o] Error 1
scripts/Makefile.build:559: recipe for target 
'drivers/video/fbdev/omap2/omapfb/dss' failed
make[6]: *** [drivers/video/fbdev/omap2/omapfb/dss] Error 2
make[6]: *** Waiting for unfinished jobs

Add OF dependency in order to make all configurations work again.

of_update_property() has no inline stub, and that that could be added as
an alternative.

Signed-off-by: Anders Roxell 
---
 drivers/video/fbdev/omap2/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/omap2/Kconfig 
b/drivers/video/fbdev/omap2/Kconfig
index 82008699d253..4de381f2452e 100644
--- a/drivers/video/fbdev/omap2/Kconfig
+++ b/drivers/video/fbdev/omap2/Kconfig
@@ -1,4 +1,4 @@
-if ARCH_OMAP2PLUS || COMPILE_TEST
+if OF && (ARCH_OMAP2PLUS || COMPILE_TEST)
 
 source "drivers/video/fbdev/omap2/omapfb/Kconfig"
 
-- 
2.17.0

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

Re: [PATCH v3 7/7] drm/i2c: tda998x: register as a drm bridge

[Peter Rosin]

On 2018-04-20 12:41, kbuild test robot wrote:
> Hi Peter,
> 
> I love your patch! Yet something to improve:

Yup, right you are!

> [auto build test ERROR on drm/drm-next]
> [also build test ERROR on v4.17-rc1 next-20180420]
> [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/Peter-Rosin/Add-tda998x-HDMI-support-to-atmel-hlcdc/20180420-160131
> base:   git://people.freedesktop.org/~airlied/linux.git drm-next
> config: i386-randconfig-a0-201815 (attached as .config)
> compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=i386 
> 
> All errors (new ones prefixed by >>):
> 
>drivers/gpu/drm/i2c/tda998x_drv.c: In function 'tda998x_probe':
>>> drivers/gpu/drm/i2c/tda998x_drv.c:1859:16: error: 'struct drm_bridge' has 
>>> no member named 'of_node'
>  bridge->bridge.of_node = dev->of_node;
>^

Anybody got a better fix than this?

#ifdef CONFIG_OF
bridge->bridge.of_node = dev->of_node;
#endif

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

[PATCH v3 5/6] ARM: dts: Add support for emtrion emCON-MX6 series

[jan.tuerk]

From: Jan Tuerk 

This patch adds support for the emtrion GmbH emCON-MX6 modules.
They are available with imx.6 Solo, Dual-Lite, Dual and Quad
equipped with Memory from 512MB to 2GB (configured by U-Boot).

Our default developer-Kit ships with the Avari baseboard and the
EDT ETM0700G0BDH6 Display (imx6[q|dl]-emcon-avari).

The devicetree is split into the common part providing all module
components and the basic support for all SoC versions
(imx6qdl-emcon.dtsi) and parts which are i.mx6 S|DL and D|Q relevant.
Finally the support for the avari baseboard in the developer-kit
configuration is provided by the emcon-avari dts files.

Signed-off-by: Jan Tuerk 
---
 Documentation/devicetree/bindings/arm/emtrion.txt |  13 +
 arch/arm/boot/dts/Makefile|   2 +
 arch/arm/boot/dts/imx6dl-emcon-avari.dts  | 224 ++
 arch/arm/boot/dts/imx6dl-emcon.dtsi   |  27 +
 arch/arm/boot/dts/imx6q-emcon-avari.dts   | 224 ++
 arch/arm/boot/dts/imx6q-emcon.dtsi|  27 +
 arch/arm/boot/dts/imx6qdl-emcon.dtsi  | 838 ++
 7 files changed, 1355 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/emtrion.txt
 create mode 100644 arch/arm/boot/dts/imx6dl-emcon-avari.dts
 create mode 100644 arch/arm/boot/dts/imx6dl-emcon.dtsi
 create mode 100644 arch/arm/boot/dts/imx6q-emcon-avari.dts
 create mode 100644 arch/arm/boot/dts/imx6q-emcon.dtsi
 create mode 100644 arch/arm/boot/dts/imx6qdl-emcon.dtsi

diff --git a/Documentation/devicetree/bindings/arm/emtrion.txt 
b/Documentation/devicetree/bindings/arm/emtrion.txt
new file mode 100644
index ..3ff6c6c2034d
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/emtrion.txt
@@ -0,0 +1,13 @@
+Emtrion Devicetree Bindings
+===
+
+emCON Series:
+-
+
+Required root node properties
+   - compatible:
+   - "emtrion,emcon-mx6", "fsl,imx6q", "fsl,imx6dl"; : emCON-MX6 Generic 
SoM
+   - "emtrion,emcon-mx6", "fsl,imx6q"; : emCON-MX6D or 
emCON-MX6Q SoM
+   - "emtrion,emcon-mx6-avari", "fsl,imx6q";   : emCON-MX6D or 
emCON-MX6Q SoM on Avari Base
+   - "emtrion,emcon-mx6", "fsl,imx6dl";: emCON-MX6S or 
emCON-MX6DL SoM
+   - "emtrion,emcon-mx6-avari", "fsl,imx6dl";  : emCON-MX6S or 
emCON-MX6DL SoM on Avari Base
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 7e2424957809..05b930da3fda 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -381,6 +381,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6dl-cubox-i-emmc-som-v15.dtb \
imx6dl-cubox-i-som-v15.dtb \
imx6dl-dfi-fs700-m60.dtb \
+   imx6dl-emcon-avari.dtb \
imx6dl-gw51xx.dtb \
imx6dl-gw52xx.dtb \
imx6dl-gw53xx.dtb \
@@ -442,6 +443,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6q-display5-tianma-tm070-1280x768.dtb \
imx6q-dmo-edmqmx6.dtb \
imx6q-dms-ba16.dtb \
+   imx6q-emcon-avari.dtb \
imx6q-evi.dtb \
imx6q-gk802.dtb \
imx6q-gw51xx.dtb \
diff --git a/arch/arm/boot/dts/imx6dl-emcon-avari.dts 
b/arch/arm/boot/dts/imx6dl-emcon-avari.dts
new file mode 100644
index ..2344fb9498e3
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-emcon-avari.dts
@@ -0,0 +1,224 @@
+// SPDX-License-Identifier: (GPL-2.0 or MIT)
+/* Copyright (C) 2018 emtrion GmbH
+ * Author: Jan Tuerk  
+ */
+
+/dts-v1/;
+#include "imx6dl.dtsi"
+#include "imx6qdl-emcon.dtsi"
+#include "imx6dl-emcon.dtsi" /*Include camera2 pinmux*/
+
+/ {
+   model = "emtrion SoM emCON-MX6 Solo/Dual-Lite Avari";
+   compatible = "emtrion,emcon-mx6-avari", "fsl,imx6dl";
+
+   aliases {
+   mmc0 = 
+   mmc2 = 
+   mmc1 = 
+   mmc3 = 
+   };
+
+   chosen {
+   stdout-path = <>;
+   };
+
+   memory {
+   reg = <0x1000 0x4000>;
+   };
+
+   supplies {
+   compatible = "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   wallplug5p0: supply@0 {
+   compatible = "regulator-fixed";
+   reg = <0>;
+   regulator-name = "WALL-PLUG";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
+   base3p3: supply@1 {
+   compatible = "regulator-fixed";
+   reg = <1>;
+   vin-supply = <>;
+   regulator-name = "3V3-avari";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-always-on;
+   

[PATCH v3 2/6] drm/panel: Add support for the EDT ETM0700G0EDH6

[jan.tuerk]

From: Jan Tuerk 

The Emerging Display Technology ETM0700G0EDH6 is the
uses the same panel as the ETM0700G0BDH6. It differs
in the hardware design for the backlight and the
touchscreen i2c interface. As the new display type has
different requirements for drive-strengths on the i2c-bus,
add an additional compatible to allow the handling of it or warn
about incompatible cpu and display combinations.

Signed-off-by: Jan Tuerk 
---
 drivers/gpu/drm/panel/panel-simple.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 8b7feb2888f2..2eed60134fa3 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2149,6 +2149,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "edt,etm0700g0bdh6",
.data = _etm0700g0bdh6,
}, {
+   .compatible = "edt,etm0700g0edh6",
+   .data = _etm0700g0bdh6,
+   }, {
.compatible = "foxlink,fl500wvr00-a0t",
.data = _fl500wvr00_a0t,
}, {
-- 
2.11.0

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

Re: [PATCH v3 5/7] drm/i2c: tda9950: add CEC driver

[Russell King - ARM Linux]

On Fri, Apr 20, 2018 at 05:48:12PM +0200, Hans Verkuil wrote:
> On 04/20/2018 05:31 PM, Russell King - ARM Linux wrote:
> > Hi Hans,
> > 
> > Any comments?
> 
> I have been traveling and haven't had time to look at this. Next week will
> be busy as well, but I expect to be able to look at it the week after that.

Well, that doesn't work because I won't be reading mail that week,
and I'll probably simply ignore the excessive backlog when I do
start reading mail again.

> I remember from the previous series that I couldn't test it with my BeagleBone
> Black board (the calibration gpio had to switch from in to out but it wasn't 
> allowed
> since it had an associated irq). That's still a problem?
> 
> I didn't see any changes in that area when I did a quick scan.

Correct, and unless you wish me to do the work for you (in which case
you can pay me) nothing is going to change on that front!  Seriously,
please do not expect me to add support for platforms I don't have
access to.  I'm just a volunteer for this, probably the same as you.

I don't think we ended up with an answer for that problem.  I don't
see that dropping the requested interrupt, using the GPIO, and then
re-requesting the interrupt is an option - how do we handle a failure
to re-request the interrupt?  Do we just ignore the error, or let DRM
stop working properly?

In any case, I don't have a working HDMI CEC-compliant setup anymore,
(no TV, just a HDMI monitor now) so I would rather _not_ change the
driver from its known-to-be-working state.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCHv3 3/8] drm/omap: add support for manually updated displays

[Tony Lindgren]

* Daniel Stone  [180420 14:41]:
> Hi Tony!
> 
> On 20 April 2018 at 15:25, Tony Lindgren  wrote:
> > * Daniel Stone  [180420 10:21]:
> >> On 20 April 2018 at 08:09, Tomi Valkeinen  wrote:
> >> > It's actually not quite clear to me how manual update displays work with
> >> > DRM...
> >> >
> >> > As far as I see, we have essentially two cases: 1) single buffering,
> >> > where the userspace must set an area in the fb dirty, which then
> >> > triggers the update, 2) multi buffering, which doesn't need fb dirty,
> >> > but just a page flip which triggers the update.
> >> >
> >> > In the 2) case (which I think is the optimal case which all the modern
> >> > apps should use), there's no need for delayed work or any work, and the
> >> > code flow should be very similar to the auto-update model.
> >>
> >> Correct. There's been talk (and I think patches?) of adding a
> >> per-plane dirty property, so userspace can as an optimisation inform
> >> the kernel of the area changed between frames. But short of that, a
> >> pageflip needs to trigger a full-plane update, with no dirtyfb
> >> required.
> >
> > For per-plane dirty property patches, which ones do you refer to?
> 
> Here's the latest iteration of that series:
> https://lists.freedesktop.org/archives/dri-devel/2018-April/171900.html
> <1522885748-67122-1-git-send-email-dra...@vmware.com>

OK thanks for the link.

> > Then for xorg, there's my second attempt on fixing the command mode
> > rotation at [0]. Not sure if that's enough for a fix?
> >
> > It seems not very efficient to me and I don't really know where
> > the the per crtc dirty flag should be stored..
> 
> I try to deny all knowledge of X11 these days, I'm afraid.

:)

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

[PATCH] Revert "drm/sun4i: add lvds mode_valid function"

[megous]

From: Ondrej Jirman 

The reverted commit broke LVDS output on TBS A711 Tablet. That tablet
has simple-panel node that has fixed pixel clock-frequency that A83T
SoC used in the tablet can't generate exactly.

Requested rate is 5200 and rounded_rate is calculated as 51857142.
It's close enough for it to work in practice, but with strict check
in the reverted commit, the mode is rejected needlessly in this case.

DT allows to specify a range of values for simple-panel/clock-frequency,
but driver doesn't respect that ATM. Given that TBS A711 is the single
user of sun4i-lvds driver, let's revert that commit for now, until
a better solution for the problem is found.

Also see: https://patchwork.kernel.org/patch/9446385/ for relevant
discussion (or search for "[RFC] drm/sun4i: rgb: Add 5% tolerance
to dot clock frequency check").

Fixes: e4e4b7ad50cf ("drm/sun4i: add lvds mode_valid function")
Reported-by: Ondrej Jirman 
Signed-off-by: Ondrej Jirman 
---
 drivers/gpu/drm/sun4i/sun4i_lvds.c | 55 --
 1 file changed, 55 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_lvds.c 
b/drivers/gpu/drm/sun4i/sun4i_lvds.c
index b4c9fbf5..be3f14d7746d 100644
--- a/drivers/gpu/drm/sun4i/sun4i_lvds.c
+++ b/drivers/gpu/drm/sun4i/sun4i_lvds.c
@@ -94,64 +94,9 @@ static void sun4i_lvds_encoder_disable(struct drm_encoder 
*encoder)
}
 }
 
-static enum drm_mode_status sun4i_lvds_encoder_mode_valid(struct drm_encoder 
*crtc,
- const struct 
drm_display_mode *mode)
-{
-   struct sun4i_lvds *lvds = drm_encoder_to_sun4i_lvds(crtc);
-   struct sun4i_tcon *tcon = lvds->tcon;
-   u32 hsync = mode->hsync_end - mode->hsync_start;
-   u32 vsync = mode->vsync_end - mode->vsync_start;
-   unsigned long rate = mode->clock * 1000;
-   long rounded_rate;
-
-   DRM_DEBUG_DRIVER("Validating modes...\n");
-
-   if (hsync < 1)
-   return MODE_HSYNC_NARROW;
-
-   if (hsync > 0x3ff)
-   return MODE_HSYNC_WIDE;
-
-   if ((mode->hdisplay < 1) || (mode->htotal < 1))
-   return MODE_H_ILLEGAL;
-
-   if ((mode->hdisplay > 0x7ff) || (mode->htotal > 0xfff))
-   return MODE_BAD_HVALUE;
-
-   DRM_DEBUG_DRIVER("Horizontal parameters OK\n");
-
-   if (vsync < 1)
-   return MODE_VSYNC_NARROW;
-
-   if (vsync > 0x3ff)
-   return MODE_VSYNC_WIDE;
-
-   if ((mode->vdisplay < 1) || (mode->vtotal < 1))
-   return MODE_V_ILLEGAL;
-
-   if ((mode->vdisplay > 0x7ff) || (mode->vtotal > 0xfff))
-   return MODE_BAD_VVALUE;
-
-   DRM_DEBUG_DRIVER("Vertical parameters OK\n");
-
-   tcon->dclk_min_div = 7;
-   tcon->dclk_max_div = 7;
-   rounded_rate = clk_round_rate(tcon->dclk, rate);
-   if (rounded_rate < rate)
-   return MODE_CLOCK_LOW;
-
-   if (rounded_rate > rate)
-   return MODE_CLOCK_HIGH;
-
-   DRM_DEBUG_DRIVER("Clock rate OK\n");
-
-   return MODE_OK;
-}
-
 static const struct drm_encoder_helper_funcs sun4i_lvds_enc_helper_funcs = {
.disable= sun4i_lvds_encoder_disable,
.enable = sun4i_lvds_encoder_enable,
-   .mode_valid = sun4i_lvds_encoder_mode_valid,
 };
 
 static const struct drm_encoder_funcs sun4i_lvds_enc_funcs = {
-- 
2.17.0

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

[PATCH v3 6/6] ARM: imx_v6_v7_defconfig: Enable DA0963 PMIC support.

[jan.tuerk]

From: Jan Tuerk 

All recent emtrion modules based on i.mx6 make use of the DA0963.
Therefore enable it with the following defaults:
- CONFIG_MFD_DA9063=y
- CONFIG_REGULATOR_DA9063=y
- CONFIG_DA9063_WATCHDOG=m
MFD and REGULATOR are built-in to have it at Kernel boot-time.
The WATCHDOG is optional and could be loaded from userspace.

Signed-off-by: Jan Tuerk 
---
 arch/arm/configs/imx_v6_v7_defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/configs/imx_v6_v7_defconfig 
b/arch/arm/configs/imx_v6_v7_defconfig
index 3a308437b088..691d431250d4 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -214,9 +214,11 @@ CONFIG_CPU_THERMAL=y
 CONFIG_IMX_THERMAL=y
 CONFIG_WATCHDOG=y
 CONFIG_DA9062_WATCHDOG=y
+CONFIG_DA9063_WATCHDOG=m
 CONFIG_IMX2_WDT=y
 CONFIG_MFD_DA9052_I2C=y
 CONFIG_MFD_DA9062=y
+CONFIG_MFD_DA9063=y
 CONFIG_MFD_MC13XXX_SPI=y
 CONFIG_MFD_MC13XXX_I2C=y
 CONFIG_MFD_STMPE=y
@@ -225,6 +227,7 @@ CONFIG_REGULATOR_FIXED_VOLTAGE=y
 CONFIG_REGULATOR_ANATOP=y
 CONFIG_REGULATOR_DA9052=y
 CONFIG_REGULATOR_DA9062=y
+CONFIG_REGULATOR_DA9063=y
 CONFIG_REGULATOR_GPIO=y
 CONFIG_REGULATOR_MC13783=y
 CONFIG_REGULATOR_MC13892=y
-- 
2.11.0

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

[PATCH] drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers v2

[Hans de Goede]

Before this commit the WaSkipStolenMemoryFirstPage workaround code was
skipping the first 4k by passing 4096 as start of the address range passed
to drm_mm_init(). This means that calling drm_mm_reserve_node() to try and
reserve the firmware framebuffer so that we can inherit it would always
fail, as the firmware framebuffer starts at address 0.

Commit d43537610470 ("drm/i915: skip the first 4k of stolen memory on
everything >= gen8") says in its commit message: "This is confirmed to fix
Skylake screen flickering issues (probably caused by the fact that we
initialized a ring in the first page of stolen, but I didn't 100% confirm
this theory)."

Which suggests that it is safe to use the first page for a linear
framebuffer as the firmware is doing (see note below).

This commit always passes 0 as start to drm_mm_init() and works around
WaSkipStolenMemoryFirstPage in i915_gem_stolen_insert_node_in_range()
by insuring the start address passed by to drm_mm_insert_node_in_range()
is always 4k or more. All entry points to i915_gem_stolen.c go through
i915_gem_stolen_insert_node_in_range(), so that any newly allocated
objects such as ring-buffers will not be allocated in the first 4k.

The one exception is i915_gem_object_create_stolen_for_preallocated()
which directly calls drm_mm_reserve_node() which now will be able to
use the first 4k.

This fixes the i915 driver no longer being able to inherit the firmware
framebuffer on gen8+, which fixes the video output changing from the
vendor logo to a black screen as soon as the i915 driver is loaded
(on systems without fbcon).

Some notes about the mapping of the BIOS framebuffer:

v1 led to some discussion if the assumption of the intel_display.c code
that the firmware framebuffer is a linear mapping of the stolen memory
starting at offset 0 is still correct, because that would mean that the
GOP does not implement the WaSkipStolenMemoryFirstPage workaround.

To verify this the following code was added at the end of
i915_gem_object_create_stolen_for_preallocated() :

pr_err("first ggtt entry before bind: 0x%016llx\n",
   readq(dev_priv->ggtt.gsm));
ret = i915_vma_bind(vma,
HAS_LLC(dev_priv) ? I915_CACHE_LLC : I915_CACHE_NONE,
PIN_UPDATE);
pr_err("i915_vma_bind ret %d\n", ret);
pr_err("first ggtt entry after bind: 0x%016llx\n",
   readq(dev_priv->ggtt.gsm));

Which prints the mapping of the first page, then does a vma_bind() to
force update the mapping with our linear view of the framebuffer and
then prints the mapping of the first page again.

On an Asrock B150M Pro4S/D3 mainboard with i5-6500 CPU this prints:

[1.651141] first ggtt entry before bind: 0x78c1
[1.651151] i915_vma_bind ret 0
[1.651152] first ggtt entry after bind: 0x78c00083

And "sudo cat /proc/iomem | grep Stolen" gives:
  78c0-88bf : Graphics Stolen Memory

There are no visual changes with this patch (BIOS vendor logo still
stays in place when we inherit the BIOS framebuffer), so the vma_bind()
does not impact which memory is being scanned out.

The address of the first ggtt entry matches with the start of stolen
and the i915_vma_bind call only changes the first gtt entry's flags,
or-ing in _PAGE_RW (BIT(1)) and PPAT_CACHED (BIT(7)), which perfectly
matches what we would expect based on gen8_pte_encode()'s behavior.

So it seems that the GOP indeed does NOT implement the wa and the i915's
code assuming a linear mapping at the start of stolen for the BIOS fb
still holds true for gen8+.

I've also tested this on a Cherry Trail based device (a GPD Win)
with identical results (the flags are 0x1b after the vma_bind
on CHT, which matches with I915_CACHE_NONE).

Changed in v2: No code changes, extended the commit message with the
verification that the intel_display.c BIOS framebuffer mapping is still
correct.

Reviewed-by: Daniel Vetter 
Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/i915/i915_gem_stolen.c | 15 ++-
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index af915d041281..ad949cc30928 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -51,6 +51,10 @@ int i915_gem_stolen_insert_node_in_range(struct 
drm_i915_private *dev_priv,
if (!drm_mm_initialized(_priv->mm.stolen))
return -ENODEV;
 
+   /* WaSkipStolenMemoryFirstPage:bdw+ */
+   if (INTEL_GEN(dev_priv) >= 8 && start < 4096)
+   start = 4096;
+
mutex_lock(_priv->mm.stolen_lock);
ret = drm_mm_insert_node_in_range(_priv->mm.stolen, node,
  size, alignment, 0,
@@ -343,7 +347,6 @@ int i915_gem_init_stolen(struct drm_i915_private *dev_priv)
 {
resource_size_t reserved_base, stolen_top;
resource_size_t reserved_total, reserved_size;
-   resource_size_t 

[PATCH v3 0/6] Add basic support for emtrion emCON-MX6 modules

[jan.tuerk]

From: Jan Tuerk 

Changes for v3:
  [PATCH v3 1/6] drm/panel: Add support for the EDT ETM0700G0BDH6
- moved Documentation into seperate commit ([PATCH v3/6])

  [PATCH v3 2/6] drm/panel: Add support for the EDT ETM0700G0EDH6
- new Patch, adding additionally compatible for the new hardware type

  [PATCH v3 3/6] dt-bindings: display: Document the EDT et* displays in one 
file.
- new Patch, as requested by Rob Herring document the EDT Displays in a 
single file

  [PATCH v3 4/6] ARM: dts: imx: Add an cpu0 label for imx6dl devices.
- Unchanged
  [PATCH v3 5/6] ARM: dts: Add support for emtrion emCON-MX6 series
- change License Header to SPDX + dual-license without licence text.
- coding-style fixes
  [PATCH v3 6/6] ARM: imx_v6_v7_defconfig: Enable DA0963 PMIC support.
- Rebased and merged

 Documentation/devicetree/bindings/arm/emtrion.txt  |  13 +
 .../bindings/display/panel/edt,et-series.txt   |  39 +
 .../bindings/display/panel/edt,et057090dhu.txt |   7 -
 .../bindings/display/panel/edt,et070080dh6.txt |  10 -
 .../bindings/display/panel/edt,etm0700g0dh6.txt|  10 -
 arch/arm/boot/dts/Makefile |   2 +
 arch/arm/boot/dts/imx6dl-emcon-avari.dts   | 224 ++
 arch/arm/boot/dts/imx6dl-emcon.dtsi|  27 +
 arch/arm/boot/dts/imx6dl.dtsi  |   2 +-
 arch/arm/boot/dts/imx6q-emcon-avari.dts| 224 ++
 arch/arm/boot/dts/imx6q-emcon.dtsi |  27 +
 arch/arm/boot/dts/imx6qdl-emcon.dtsi   | 838 +
 arch/arm/configs/imx_v6_v7_defconfig   |   3 +
 drivers/gpu/drm/panel/panel-simple.c   |  18 +
 14 files changed, 1416 insertions(+), 28 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/emtrion.txt
 create mode 100644 
Documentation/devicetree/bindings/display/panel/edt,et-series.txt
 delete mode 100644 
Documentation/devicetree/bindings/display/panel/edt,et057090dhu.txt
 delete mode 100644 
Documentation/devicetree/bindings/display/panel/edt,et070080dh6.txt
 delete mode 100644 
Documentation/devicetree/bindings/display/panel/edt,etm0700g0dh6.txt
 create mode 100644 arch/arm/boot/dts/imx6dl-emcon-avari.dts
 create mode 100644 arch/arm/boot/dts/imx6dl-emcon.dtsi
 create mode 100644 arch/arm/boot/dts/imx6q-emcon-avari.dts
 create mode 100644 arch/arm/boot/dts/imx6q-emcon.dtsi
 create mode 100644 arch/arm/boot/dts/imx6qdl-emcon.dtsi

-- 
2.11.0

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

[PATCH v3 3/6] dt-bindings: display: Document the EDT et* displays in one file.

[jan.tuerk]

From: Jan Tuerk 

Document the Emerging Display Technology Corp. (EDT) using the
simple-panel binding in one single file.

Signed-off-by: Jan Tuerk 
---
 .../bindings/display/panel/edt,et-series.txt   | 39 ++
 .../bindings/display/panel/edt,et057090dhu.txt |  7 
 .../bindings/display/panel/edt,et070080dh6.txt | 10 --
 .../bindings/display/panel/edt,etm0700g0dh6.txt| 10 --
 4 files changed, 39 insertions(+), 27 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/edt,et-series.txt
 delete mode 100644 
Documentation/devicetree/bindings/display/panel/edt,et057090dhu.txt
 delete mode 100644 
Documentation/devicetree/bindings/display/panel/edt,et070080dh6.txt
 delete mode 100644 
Documentation/devicetree/bindings/display/panel/edt,etm0700g0dh6.txt

diff --git a/Documentation/devicetree/bindings/display/panel/edt,et-series.txt 
b/Documentation/devicetree/bindings/display/panel/edt,et-series.txt
new file mode 100644
index ..f56b99ebd9be
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/edt,et-series.txt
@@ -0,0 +1,39 @@
+Emerging Display Technology Corp. Displays
+==
+
+
+Display bindings for EDT Display Technology Corp. Displays which are
+compatible with the simple-panel binding, which is specified in
+simple-panel.txt
+
+
+5,7" WVGA TFT Panels
+
+
++-+-+-+
+| Identifier  | compatbile  | description |
++=+=+=+
+| ET057090DHU | edt,et057090dhu | 5.7" VGA TFT LCD panel  |
++-+-+-+
+
+
+7,0" WVGA TFT Panels
+
+
++-+-+-+
+| Identifier  | compatbile  | description |
++=+=+=+
+| ETM0700G0DH6| edt,etm070080dh6| WVGA TFT Display with capacitive|
+| | | Touchscreen |
++-+-+-+
+| ETM0700G0BDH6   | edt,etm070080bdh6   | Same as ETM0700G0DH6 but with   |
+| | | inverted pixel clock.   |
++-+-+-+
+| ETM0700G0EDH6   | edt,etm070080edh6   | Same display as the ETM0700G0BDH6,  |
+| | | but with changed Hardware for the   |
+| | | backlight and the touch interface   |
++-+-+-+
+| ET070080DH6 | edt,etm070080dh6| Same timings as the ETM0700G0DH6,   |
+| | | but with resistive touch.   |
++-+-+-+
+
diff --git 
a/Documentation/devicetree/bindings/display/panel/edt,et057090dhu.txt 
b/Documentation/devicetree/bindings/display/panel/edt,et057090dhu.txt
deleted file mode 100644
index 4903d7b1d947..
--- a/Documentation/devicetree/bindings/display/panel/edt,et057090dhu.txt
+++ /dev/null
@@ -1,7 +0,0 @@
-Emerging Display Technology Corp. 5.7" VGA TFT LCD panel
-
-Required properties:
-- compatible: should be "edt,et057090dhu"
-
-This binding is compatible with the simple-panel binding, which is specified
-in simple-panel.txt in this directory.
diff --git 
a/Documentation/devicetree/bindings/display/panel/edt,et070080dh6.txt 
b/Documentation/devicetree/bindings/display/panel/edt,et070080dh6.txt
deleted file mode 100644
index 20cb38e836e4..
--- a/Documentation/devicetree/bindings/display/panel/edt,et070080dh6.txt
+++ /dev/null
@@ -1,10 +0,0 @@
-Emerging Display Technology Corp. ET070080DH6 7.0" WVGA TFT LCD panel
-
-Required properties:
-- compatible: should be "edt,et070080dh6"
-
-This panel is the same as ETM0700G0DH6 except for the touchscreen.
-ET070080DH6 is the model with resistive touch.
-
-This binding is compatible with the simple-panel binding, which is specified
-in simple-panel.txt in this directory.
diff --git 
a/Documentation/devicetree/bindings/display/panel/edt,etm0700g0dh6.txt 
b/Documentation/devicetree/bindings/display/panel/edt,etm0700g0dh6.txt
deleted file mode 100644
index ee4b18053e40..
--- a/Documentation/devicetree/bindings/display/panel/edt,etm0700g0dh6.txt
+++ /dev/null
@@ -1,10 +0,0 @@
-Emerging Display Technology Corp. ETM0700G0DH6 7.0" WVGA TFT LCD panel
-
-Required properties:
-- compatible: should be "edt,etm0700g0dh6"
-
-This panel is the same as ET070080DH6 except for the 

Re: RFC for a render API to support adaptive sync and VRR

[Daniel Stone]

Hi,

On 20 April 2018 at 21:32, Manasi Navare  wrote:
> On Wed, Apr 18, 2018 at 09:39:02AM +0200, Daniel Vetter wrote:
>> On Wed, Apr 18, 2018 at 5:58 AM, Keith Packard  wrote:
>> > I'd also encourage using a single unit for all of these values,
>> > preferably nanoseconds. Absolute times should all be referenced to
>> > CLOCK_MONOTONIC.
>>
>> +1 on everything Keith said. I got somehow dragged in khr vk
>> discussions around preventing micro-stuttering, and consensus seems to
>> be that timestamps for scheduling frames is the way to go, most likely
>> absolute ones (not everything is running Linux unfortunately, so can't
>> go outright and claim it's guaranteed to be CLOCK_MONOTONIC).
>
> And yes I also got consensus from Mesa and media folks about using the
> absolute timestamp for scheduling the frames and then the driver will
> modify the vblank logic to "present no earlier than the timestamp"

Whilst we're all piling in, here's another AOL. We didn't yet
implement this for Wayland because of the fun involved in adding a
FIFO mode to a very mailbox window system, but at some point we'll
have to suck it up and push it.

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

[Bug 106165] [vega10] vega56 VM_L2_PROTECTION_FAULT_STATUS in wine games

[bugzilla-daemon]

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

Bug ID: 106165
   Summary: [vega10] vega56 VM_L2_PROTECTION_FAULT_STATUS in wine
games
   Product: DRI
   Version: unspecified
  Hardware: x86 (IA32)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: tomenglun...@gmail.com

Device: Radeon RX Vega (VEGA10 / DRM 3.23.0 / 4.16.3-1-ARCH, LLVM 6.0.0)
(0x687f)
mesa Version: 18.0.1

when starting legion td 2 in wine my system freezes and these errors happends
in my journal.

apr 21 11:55:24 tom-pc kernel: amdgpu :03:00.0: [gfxhub] VMC page fault
(src_id:0 ring:190 vmid:5 pas_id:0)
apr 21 11:55:24 tom-pc kernel: amdgpu :03:00.0:   at page
0x680c0c192000 from 27
apr 21 11:55:24 tom-pc kernel: amdgpu :03:00.0:
VM_L2_PROTECTION_FAULT_STATUS:0x005C017D
apr 21 11:55:24 tom-pc kernel: amdgpu :03:00.0: [gfxhub] VMC page fault
(src_id:0 ring:190 vmid:5 pas_id:0)
apr 21 11:55:24 tom-pc kernel: amdgpu :03:00.0:   at page
0x680c0c212000 from 27
apr 21 11:55:24 tom-pc kernel: amdgpu :03:00.0:
VM_L2_PROTECTION_FAULT_STATUS:0x005C017D
apr 21 11:55:24 tom-pc kernel: amdgpu :03:00.0: [gfxhub] VMC page fault
(src_id:0 ring:190 vmid:5 pas_id:0)
apr 21 11:55:24 tom-pc kernel: amdgpu :03:00.0:   at page
0x680c0c292000 from 27
apr 21 11:55:24 tom-pc kernel: amdgpu :03:00.0:
VM_L2_PROTECTION_FAULT_STATUS:0x005C017D
apr 21 11:55:24 tom-pc kernel: amdgpu :03:00.0: [gfxhub] VMC page fault
(src_id:0 ring:190 vmid:5 pas_id:0)
apr 21 11:55:24 tom-pc kernel: amdgpu :03:00.0:   at page
0x680c0c312000 from 27
apr 21 11:55:24 tom-pc kernel: amdgpu :03:00.0:
VM_L2_PROTECTION_FAULT_STATUS:0x005C017D
apr 21 11:55:24 tom-pc kernel: amdgpu :03:00.0: [gfxhub] VMC page fault
(src_id:0 ring:190 vmid:5 pas_id:0)
apr 21 11:55:24 tom-pc kernel: amdgpu :03:00.0:   at page
0x680c0c60a000 from 27
apr 21 11:55:24 tom-pc kernel: amdgpu :03:00.0:
VM_L2_PROTECTION_FAULT_STATUS:0x005C017D
apr 21 11:55:24 tom-pc kernel: amdgpu :03:00.0: [gfxhub] VMC page fault
(src_id:0 ring:190 vmid:5 pas_id:0)
apr 21 11:55:24 tom-pc kernel: amdgpu :03:00.0:   at page
0x680c0c952000 from 27
apr 21 11:55:24 tom-pc kernel: amdgpu :03:00.0:
VM_L2_PROTECTION_FAULT_STATUS:0x005C017D
apr 21 11:55:24 tom-pc kernel: amdgpu :03:00.0: [gfxhub] VMC page fault
(src_id:0 ring:190 vmid:5 pas_id:0)
apr 21 11:55:24 tom-pc kernel: amdgpu :03:00.0:   at page
0x680c0c70a000 from 27
apr 21 11:55:24 tom-pc kernel: amdgpu :03:00.0:
VM_L2_PROTECTION_FAULT_STATUS:0x005C017D
apr 21 11:55:24 tom-pc kernel: amdgpu :03:00.0: [gfxhub] VMC page fault
(src_id:0 ring:190 vmid:5 pas_id:0)
apr 21 11:55:24 tom-pc kernel: amdgpu :03:00.0:   at page
0x680c0c68a000 from 27
apr 21 11:55:24 tom-pc kernel: amdgpu :03:00.0:
VM_L2_PROTECTION_FAULT_STATUS:0x005C017D
apr 21 11:55:24 tom-pc kernel: amdgpu :03:00.0: [gfxhub] VMC page fault
(src_id:0 ring:190 vmid:5 pas_id:0)
apr 21 11:55:24 tom-pc kernel: amdgpu :03:00.0:   at page
0x680c0c58a000 from 27
apr 21 11:55:24 tom-pc kernel: amdgpu :03:00.0:
VM_L2_PROTECTION_FAULT_STATUS:0x005C017D
apr 21 11:55:24 tom-pc kernel: amdgpu :03:00.0: [gfxhub] VMC page fault
(src_id:0 ring:190 vmid:5 pas_id:0)
apr 21 11:55:24 tom-pc kernel: amdgpu :03:00.0:   at page
0x680c0c78b000 from 27
apr 21 11:55:24 tom-pc kernel: amdgpu :03:00.0:
VM_L2_PROTECTION_FAULT_STATUS:0x005C017D
apr 21 11:55:24 tom-pc kernel: amdgpu :03:00.0: IH ring buffer overflow
(0x000A2D40, 0x2E00, 0x00022D60)

-- 
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] drm/bridge: vga-dac: Fix edid memory leak

[Laurent Pinchart]

Hi Sean,

Thank you for the patch.

On Friday, 20 April 2018 21:59:59 EEST Sean Paul wrote:
> edid should be freed once it's finished being used.
> 
> Fixes: 56fe8b6f4991 ("drm/bridge: Add RGB to VGA bridge support")
> Cc: Rob Herring 
> Cc: Sean Paul 
> Cc: Maxime Ripard 
> Cc: Archit Taneja 
> Cc: Andrzej Hajda 
> Cc: Laurent Pinchart 
> Cc:  # v4.9+
> Signed-off-by: Sean Paul 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/bridge/dumb-vga-dac.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c
> b/drivers/gpu/drm/bridge/dumb-vga-dac.c index 498d5948d1a8..9837c8d69e69
> 100644
> --- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
> +++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
> @@ -56,7 +56,9 @@ static int dumb_vga_get_modes(struct drm_connector
> *connector) }
> 
>   drm_mode_connector_update_edid_property(connector, edid);
> - return drm_add_edid_modes(connector, edid);
> + ret = drm_add_edid_modes(connector, edid);
> + kfree(edid);
> + return ret;
> 
>  fallback:
>   /*

-- 
Regards,

Laurent Pinchart



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

Re: [PATCH v3 0/7] Add tda998x (HDMI) support to atmel-hlcdc

[Laurent Pinchart]

Hi Peter,

On Friday, 20 April 2018 15:55:50 EEST Peter Rosin wrote:
> On 2018-04-20 13:38, jacopo mondi wrote:
> > On Fri, Apr 20, 2018 at 01:05:21PM +0200, Peter Rosin wrote:
> >> On 2018-04-20 12:18, Laurent Pinchart wrote:
> >>> On Friday, 20 April 2018 11:52:35 EEST jacopo mondi wrote:
>  Hi Peter,
>  
>  I've been a bit a pain in the arse for you recently, but please
>  bear with me a bit more, and sorry for jumping late on the band wagon.
>  
>  On Thu, Apr 19, 2018 at 06:27:44PM +0200, Peter Rosin wrote:
> > Hi!
> > 
> > I naively thought that since there was support for both nxp,tda19988
> > (in the tda998x driver) and the atmel-hlcdc, things would be a smooth
> > ride. But it wasn't, so I started looking around and realized I had to
> > fix things.
> > 
> > In v1 and v2 I fixed things by making the atmel-hlcdc driver a master
> > component, but now in v3 I fix things by making the tda998x driver
> > a bridge instead. This was after a suggestion from Boris Brezillion
> >> 
> >> That should be Brezillon, sorry for being sloppy with the spelling.
> >> 
> > (the atmel-hlcdc maintainer), so there was some risk of bias ... but
> > after comparing what was needed, I too find the bridge approach
> > better.
> > 
> > In addition to the above, our PCB interface between the SAMA5D3 and
> > the HDMI encoder is only using 16 bits, and this has to be described
> > somewhere, or the atmel-hlcdc driver have no chance of selecting the
> > correct output mode. Since I have similar problems with a ds90c185
> > lvds encoder I added patches to override the atmel-hlcdc output format
> > via DT properties compatible with the media video-interface binding
> > and things start to play together.
> > 
> > Since this series superseeds the bridge series [1], I have included
> > the leftover bindings patch for the ti,ds90c185 here.
>  
>  I feel like this series would look better if it would make use of the
>  proposed bridge media bus format support I have recently sent out [1]
>  (and which was not there when you first sent v1).
>  
>  I understand your fundamental problem here is that the bus format
>  that should be reported by your bridge is different from the ones
>  actually supported by the TDA19988 chip, as the wirings ground some
>  of the input pins.
>  
>  Although this is defintely something that could be described in the
>  bridge's own OF node with the 'bus_width' property, and what I would
>  do, now that you have made a bridge out from the tda19988 driver, is:
>  
>  1) Set the bridge accepted input bus_format parsing its pin
>  configuration, or default it if that's not implemented yet.
>  This will likely be rgb888. You can do that using the trivial
>  support for bridge input image formats implemented by my series.
>  2) Specify in the bridge endpoint a 'bus_width' of <16>
>  3) In your atmel-hlcd get both the image format of the bridge (rgb888)
>  and parse the remote endpoint property 'bus_width' and get the <16>
>  value back.
> >>> 
> >>> Parsing properties of remote nodes should be avoided as much as
> >>> possible, as they need to be interpreted in the context of the DT
> >>> bindings related to the compatible string applicable to that node. I'd
> >>> rather have the bus_width property in the local endpoint node.
> >> 
> >> In addition to that, my view of this binding
> >> 
> >>endpoint {
> >>bus-type = <0>;
> > 
> > bus-type is used by v4l2_fwnode helpers to decide which type of bus
> > they're dealing with iirc. Here it seems to me it has no added
> > value, also because in your bindings description "it shall be 0" and
> > it is not parsed anywhere in you code, but no big deal
> 
> bus-type is indeed parsed and verified to be zero which means auto-detect
> according to the video-interfaces binding. An auto-detect bus-type with
> a given bus-width means a parallel interface IIUC.

I believe you could leave it out though. Your display controller only supports 
parallel buses, so there's no need to specify the bus type explicitly.

> From patch 3/7:
> 
>   if (of_property_read_u32(node, "bus-type", _type))
>   return 0;
>   if (bus_type != 0)
>   return -EINVAL;
> 
> >>bus-widht = <16>;
> >>};
> >> 
> >> is that it always means rgb565. See further below.
> >> 
>  4) Set the correct format in the atmel hlcd driver to accommodate a
>  bridge that wants rgb888 on a 16 bit wide bus (that would be rgb565,
>  or are there other possible combinations I am missing?)
>  
>  I would consider this better mostly because in this series you are
>  creating a semantic for the whole DRM subsystem on the 'bus_width'
>  property, where numerical values as '12', '16' etc are arbitrary tied
>  to the selection of a 

Re: [PATCH v3 0/7] Add tda998x (HDMI) support to atmel-hlcdc

[Laurent Pinchart]

Hi Jacopo,

On Friday, 20 April 2018 14:22:04 EEST jacopo mondi wrote:
> On Fri, Apr 20, 2018 at 01:18:13PM +0300, Laurent Pinchart wrote:
> > On Friday, 20 April 2018 11:52:35 EEST jacopo mondi wrote:
> > > Hi Peter,
> > > 
> > > I've been a bit a pain in the arse for you recently, but please
> > > bear with me a bit more, and sorry for jumping late on the band wagon.
> > > 
> > > On Thu, Apr 19, 2018 at 06:27:44PM +0200, Peter Rosin wrote:
> > > > Hi!
> > > > 
> > > > I naively thought that since there was support for both nxp,tda19988
> > > > (in the tda998x driver) and the atmel-hlcdc, things would be a smooth
> > > > ride. But it wasn't, so I started looking around and realized I had to
> > > > fix things.
> > > > 
> > > > In v1 and v2 I fixed things by making the atmel-hlcdc driver a master
> > > > component, but now in v3 I fix things by making the tda998x driver
> > > > a bridge instead. This was after a suggestion from Boris Brezillion
> > > > (the atmel-hlcdc maintainer), so there was some risk of bias ... but
> > > > after comparing what was needed, I too find the bridge approach
> > > > better.
> > > > 
> > > > In addition to the above, our PCB interface between the SAMA5D3 and
> > > > the HDMI encoder is only using 16 bits, and this has to be described
> > > > somewhere, or the atmel-hlcdc driver have no chance of selecting the
> > > > correct output mode. Since I have similar problems with a ds90c185
> > > > lvds encoder I added patches to override the atmel-hlcdc output format
> > > > via DT properties compatible with the media video-interface binding
> > > > and things start to play together.
> > > > 
> > > > Since this series superseeds the bridge series [1], I have included
> > > > the leftover bindings patch for the ti,ds90c185 here.
> > > 
> > > I feel like this series would look better if it would make use of the
> > > proposed bridge media bus format support I have recently sent out [1]
> > > (and which was not there when you first sent v1).
> > > 
> > > I understand your fundamental problem here is that the bus format
> > > that should be reported by your bridge is different from the ones
> > > actually supported by the TDA19988 chip, as the wirings ground some
> > > of the input pins.
> > > 
> > > Although this is defintely something that could be described in the
> > > bridge's own OF node with the 'bus_width' property, and what I would do,
> > > now that you have made a bridge out from the tda19988 driver, is:
> > > 
> > > 1) Set the bridge accepted input bus_format parsing its pin
> > > configuration, or default it if that's not implemented yet.
> > > This will likely be rgb888. You can do that using the trivial
> > > support for bridge input image formats implemented by my series.
> > > 2) Specify in the bridge endpoint a 'bus_width' of <16>
> > > 3) In your atmel-hlcd get both the image format of the bridge (rgb888)
> > > and parse the remote endpoint property 'bus_width' and get the <16>
> > > value back.
> > 
> > Parsing properties of remote nodes should be avoided as much as possible,
> > as they need to be interpreted in the context of the DT bindings related
> > to the compatible string applicable to that node. I'd rather have the
> > bus_width property in the local endpoint node.
> 
> Right, I see...
> Well, in Peter's case, the bus width, being a consequence of
> wirings, can be described safely in both endpoints, right?

If we look at it from the endpoints' point of view, the display controller has 
to output a 16-bit format, and the HDMI encoder receives a 24-bit format. The 
conversion is due to PCB wiring so there's no DT node to describe that. I thus 
believe the right description to be bus-width = <16> on the display controller 
side, and bus-width = <24> on the HDMI encoder side.

This being said, even if the bus-width property was set to 16 on both sides, 
what I frown upon is parsing a property of the HDMI encoder DT node in the 
display controller driver.

> > > 4) Set the correct format in the atmel hlcd driver to accommodate a
> > > bridge that wants rgb888 on a 16 bit wide bus (that would be rgb565,
> > > or are there other possible combinations I am missing?)
> > > 
> > > I would consider this better mostly because in this series you are
> > > creating a semantic for the whole DRM subsystem on the 'bus_width'
> > > property, where numerical values as '12', '16' etc are arbitrary tied
> > > to the selection of a media bus format. At least you should use a
> > > common set of defines [1] between the device tree and the driver,
> > > but this looks anyway fragile imho.
> > 
> > This I agree with though. Combining the remote bus format with the local
> > bus width should fix the problem without having to parse remote
> > properties.
> > 
> > > Have I maybe missed some parts of the problem you are trying to solve
> > > here?
> > > 
> > > [1] drm: bridge: Add support for static image formats
> > > 
> > > https://lwn.net/Articles/752296/
> > > 
> > > [2] 

Re: [PATCH] video: fbdev: sh_mobile_meram: Drop SUPERH platform dependency

[Laurent Pinchart]

Hi Geert,

Thank you for the patch.

On Friday, 20 April 2018 17:20:51 EEST Geert Uytterhoeven wrote:
> Since commit a521422ea4ae6128 ("ARM: shmobile: mackerel: Remove Legacy C
> board code"), the only remaining platforms using this driver are SuperH
> SH-Mobile SoCs (sh7723).  As both SUPERH and ARCH_SHMOBILE are set for
> these platforms, the SUPERH dependency can be dropped.
> 
> Signed-off-by: Geert Uytterhoeven 

Acked-by: Laurent Pinchart 

> ---
>  drivers/video/fbdev/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> index d94254263ea5caa7..434e95b9320ead05 100644
> --- a/drivers/video/fbdev/Kconfig
> +++ b/drivers/video/fbdev/Kconfig
> @@ -2348,7 +2348,7 @@ source "drivers/video/fbdev/mmp/Kconfig"
> 
>  config FB_SH_MOBILE_MERAM
>   tristate "SuperH Mobile MERAM read ahead support"
> - depends on (SUPERH || ARCH_SHMOBILE)
> + depends on ARCH_SHMOBILE
>   select GENERIC_ALLOCATOR
>   ---help---
> Enable MERAM support for the SuperH controller.


-- 
Regards,

Laurent Pinchart



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

Re: [PATCH] drm/etnaviv: remove register logging

[Christian Gmeiner]

2018-04-20 19:14 GMT+02:00 Lucas Stach :
> I'm not aware of any case where tracing GPU register manipulation at the
> kernel level would have been useful. It only adds more indirections and
> adds to the code size.

It was a nice to have during initial driver development and I am okay
to remove it.

> Signed-off-by: Lucas Stach 

Reviewed-by: Christian Gmeiner 

> ---
>  drivers/gpu/drm/etnaviv/Kconfig   |  8 --
>  drivers/gpu/drm/etnaviv/etnaviv_drv.c | 51 
> ---
>  drivers/gpu/drm/etnaviv/etnaviv_drv.h |  5 
>  drivers/gpu/drm/etnaviv/etnaviv_gpu.c |  4 ++-
>  drivers/gpu/drm/etnaviv/etnaviv_gpu.h |  4 +--
>  5 files changed, 5 insertions(+), 67 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/Kconfig b/drivers/gpu/drm/etnaviv/Kconfig
> index e5bfeca361bd..041a77e400d4 100644
> --- a/drivers/gpu/drm/etnaviv/Kconfig
> +++ b/drivers/gpu/drm/etnaviv/Kconfig
> @@ -22,11 +22,3 @@ config DRM_ETNAVIV_THERMAL
> help
>   Compile in support for thermal throttling.
>   Say Y unless you want to risk burning your SoC.
> -
> -config DRM_ETNAVIV_REGISTER_LOGGING
> -   bool "enable ETNAVIV register logging"
> -   depends on DRM_ETNAVIV
> -   help
> - Compile in support for logging register reads/writes in a format
> - that can be parsed by envytools demsm tool.  If enabled, register
> - logging can be switched on via etnaviv.reglog=y module param.
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c 
> b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> index ab50090d066c..0aa543d75953 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> @@ -25,57 +25,6 @@
>  #include "etnaviv_mmu.h"
>  #include "etnaviv_perfmon.h"
>
> -#ifdef CONFIG_DRM_ETNAVIV_REGISTER_LOGGING
> -static bool reglog;
> -MODULE_PARM_DESC(reglog, "Enable register read/write logging");
> -module_param(reglog, bool, 0600);
> -#else
> -#define reglog 0
> -#endif
> -
> -void __iomem *etnaviv_ioremap(struct platform_device *pdev, const char *name,
> -   const char *dbgname)
> -{
> -   struct resource *res;
> -   void __iomem *ptr;
> -
> -   if (name)
> -   res = platform_get_resource_byname(pdev, IORESOURCE_MEM, 
> name);
> -   else
> -   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> -
> -   ptr = devm_ioremap_resource(>dev, res);
> -   if (IS_ERR(ptr)) {
> -   dev_err(>dev, "failed to ioremap %s: %ld\n", name,
> -   PTR_ERR(ptr));
> -   return ptr;
> -   }
> -
> -   if (reglog)
> -   dev_printk(KERN_DEBUG, >dev, "IO:region %s 0x%p 
> %08zx\n",
> -  dbgname, ptr, (size_t)resource_size(res));
> -
> -   return ptr;
> -}
> -
> -void etnaviv_writel(u32 data, void __iomem *addr)
> -{
> -   if (reglog)
> -   printk(KERN_DEBUG "IO:W %p %08x\n", addr, data);
> -
> -   writel(data, addr);
> -}
> -
> -u32 etnaviv_readl(const void __iomem *addr)
> -{
> -   u32 val = readl(addr);
> -
> -   if (reglog)
> -   printk(KERN_DEBUG "IO:R %p %08x\n", addr, val);
> -
> -   return val;
> -}
> -
>  /*
>   * DRM operations:
>   */
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.h 
> b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
> index ddb17ee565e9..56be51c13c49 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_drv.h
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.h
> @@ -101,11 +101,6 @@ void etnaviv_gem_describe_objects(struct 
> etnaviv_drm_private *priv,
> struct seq_file *m);
>  #endif
>
> -void __iomem *etnaviv_ioremap(struct platform_device *pdev, const char *name,
> -   const char *dbgname);
> -void etnaviv_writel(u32 data, void __iomem *addr);
> -u32 etnaviv_readl(const void __iomem *addr);
> -
>  #define DBG(fmt, ...) DRM_DEBUG(fmt"\n", ##__VA_ARGS__)
>  #define VERB(fmt, ...) if (0) DRM_DEBUG(fmt"\n", ##__VA_ARGS__)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> index 8a88799bf79b..08c587547f19 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> @@ -1735,6 +1735,7 @@ static int etnaviv_gpu_platform_probe(struct 
> platform_device *pdev)
>  {
> struct device *dev = >dev;
> struct etnaviv_gpu *gpu;
> +   struct resource *res;
> int err;
>
> gpu = devm_kzalloc(dev, sizeof(*gpu), GFP_KERNEL);
> @@ -1746,7 +1747,8 @@ static int etnaviv_gpu_platform_probe(struct 
> platform_device *pdev)
> mutex_init(>fence_idr_lock);
>
> /* Map registers: */
> -   gpu->mmio = etnaviv_ioremap(pdev, NULL, dev_name(gpu->dev));
> +   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +   gpu->mmio = devm_ioremap_resource(>dev, res);
> if (IS_ERR(gpu->mmio))
> return 

[PATCH v8 1/2] drm/bridge: Add Cadence DSI driver

[Boris Brezillon]

Add a driver for Cadence DPI -> DSI bridge.

This driver only support a subset of Cadence DSI bridge capabilities.

This driver has been tested/debugged in a simulated environment which
explains why some of the features are missing.  Here is a
non-exhaustive list of missing features:
 * burst mode
 * DPHY init/configuration steps
 * support for additional input interfaces (SDI input)

DSI commands and non-burst video mode have been tested.

Signed-off-by: Boris Brezillon 
Reviewed-by: Andrzej Hajda 
Acked-by: Eric Anholt 
Reviewed-by: Archit Taneja 
---
Changes in v8:
- Update my email address

Changes in v7:
- Use DIV_ROUND_UP_ULL() to fix a build error on arm 32-bit
- Add Archit's R-b

Changes in v6:
- Use SPDX header
- Do not enable the sys_clk in the probe function
- Remove unneeded udelay()
- Add a function to make sure the PLL and pixel clock are close enough
  to be recoverable if they don't match exactly
- Add the DPHY init sequence used in simulation (likely to be different
  based on each SoC integration)

Changes in v5:
- Add runtime PM support

Changes in v4:
- Fix typos
- Rename clks as suggested by Tomi
- Fix DSI setup done in cdns_dsi_bridge_enable()
- Add a precision about where this bridge is supposed to used to the
  Kconfig entry
- Let DRM_CDNS_DSI select DRM_PANEL_BRIDGE
- Remove the IP version from the DT compatible name
- Adapt register the layout to match the one used in the last revision
  of the IP (hopefully the final version)

Changes in v3:
- replace magic values by real timing calculation. The DPHY PLL clock
  is still hardcoded since we don't have a working DPHY block yet, and
  this is the piece of HW we need to dynamically configure the PLL
  rate based on the display refresh rate and the resolution.
- parse DSI devices represented with the OF-graph. This is needed to
  support DSI devices controlled through an external bus like I2C or
  SPI.
- use the DRM panel-bridge infrastructure to simplify the DRM panel
  logic

Changes in v2:
- rebase on v4.12-rc1 and adapt to driver to the drm_bridge API changes
- return the correct error when devm_clk_get(sysclk) fails
- add missing depends on OF and select DRM_PANEL in the Kconfig entry

DSI runtime PM
---
 drivers/gpu/drm/bridge/Kconfig|   10 +
 drivers/gpu/drm/bridge/Makefile   |1 +
 drivers/gpu/drm/bridge/cdns-dsi.c | 1623 +
 3 files changed, 1634 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/cdns-dsi.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 42c9c2d13752..1d75d3a1f951 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -25,6 +25,16 @@ config DRM_ANALOGIX_ANX78XX
  the HDMI output of an application processor to MyDP
  or DisplayPort.
 
+config DRM_CDNS_DSI
+   tristate "Cadence DPI/DSI bridge"
+   select DRM_KMS_HELPER
+   select DRM_MIPI_DSI
+   select DRM_PANEL_BRIDGE
+   depends on OF
+   help
+ Support Cadence DPI to DSI bridge. This is an internal
+ bridge and is meant to be directly embedded in a SoC.
+
 config DRM_DUMB_VGA_DAC
tristate "Dumb VGA DAC Bridge support"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index fd90b16a65c0..35f88d48ec20 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -1,5 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0
 obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
+obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
 obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
 obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o
 obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) += 
megachips-stdp-ge-b850v3-fw.o
diff --git a/drivers/gpu/drm/bridge/cdns-dsi.c 
b/drivers/gpu/drm/bridge/cdns-dsi.c
new file mode 100644
index ..c255fc3e1be5
--- /dev/null
+++ b/drivers/gpu/drm/bridge/cdns-dsi.c
@@ -0,0 +1,1623 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright: 2017 Cadence Design Systems, Inc.
+ *
+ * Author: Boris Brezillon 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define IP_CONF0x0
+#define SP_HS_FIFO_DEPTH(x)(((x) & GENMASK(30, 26)) >> 26)
+#define SP_LP_FIFO_DEPTH(x)(((x) & GENMASK(25, 21)) >> 21)
+#define VRS_FIFO_DEPTH(x)  (((x) & GENMASK(20, 16)) >> 16)
+#define DIRCMD_FIFO_DEPTH(x)   (((x) & GENMASK(15, 13)) >> 13)
+#define SDI_IFACE_32   BIT(12)
+#define INTERNAL_DATAPATH_32   (0 << 10)
+#define INTERNAL_DATAPATH_16   (1 << 10)
+#define INTERNAL_DATAPATH_8(3 << 10)
+#define INTERNAL_DATAPATH_SIZE ((x) & GENMASK(11, 10))
+#define 

[PATCH v8 2/2] dt-bindings: drm/bridge: Document Cadence DSI bridge bindings

[Boris Brezillon]

Document the bindings used for the Cadence DSI bridge.

Signed-off-by: Boris Brezillon 
Reviewed-by: Rob Herring 
---
Changes in v8:
- Update my email address

Changes in v7:
- Add Rob's R-b

Changes in v6:
- Document the DPHY bindings
- Drop Rob's ack because of the addition DPHY bindings doc

Changes in v5:
- Add optional reset line for the peripheral/APB logic

Changes in v4:
- Rename DSI clks (suggested by Tomi)
- Drop the IP version in the compatible since it can be extracted from
  a register (suggested by Andrzej)

Changes in v3:
- Fix clock names in the example
- Document how to represent DSI devices that are controller through
  an external bus like I2C or SPI

Changes in v2:
- None
---
 .../bindings/display/bridge/cdns,dsi.txt   | 133 +
 1 file changed, 133 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt

diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt 
b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt
new file mode 100644
index ..f5725bb6c61c
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt
@@ -0,0 +1,133 @@
+Cadence DSI bridge
+==
+
+The Cadence DSI bridge is a DPI to DSI bridge supporting up to 4 DSI lanes.
+
+Required properties:
+- compatible: should be set to "cdns,dsi".
+- reg: physical base address and length of the controller's registers.
+- interrupts: interrupt line connected to the DSI bridge.
+- clocks: DSI bridge clocks.
+- clock-names: must contain "dsi_p_clk" and "dsi_sys_clk".
+- phys: phandle link to the MIPI D-PHY controller.
+- phy-names: must contain "dphy".
+- #address-cells: must be set to 1.
+- #size-cells: must be set to 0.
+
+Optional properties:
+- resets: DSI reset lines.
+- reset-names: can contain "dsi_p_rst".
+
+Required subnodes:
+- ports: Ports as described in Documentation/devicetree/bindings/graph.txt.
+  2 ports are available:
+  * port 0: this port is only needed if some of your DSI devices are
+   controlled through  an external bus like I2C or SPI. Can have at
+   most 4 endpoints. The endpoint number is directly encoding the
+   DSI virtual channel used by this device.
+  * port 1: represents the DPI input.
+  Other ports will be added later to support the new kind of inputs.
+
+- one subnode per DSI device connected on the DSI bus. Each DSI device should
+  contain a reg property encoding its virtual channel.
+
+Cadence DPHY
+
+
+Cadence DPHY block.
+
+Required properties:
+- compatible: should be set to "cdns,dphy".
+- reg: physical base address and length of the DPHY registers.
+- clocks: DPHY reference clocks.
+- clock-names: must contain "psm" and "pll_ref".
+- #phy-cells: must be set to 0.
+
+
+Example:
+   dphy0: dphy@fd0e{
+   compatible = "cdns,dphy";
+   reg = <0x0 0xfd0e 0x0 0x1000>;
+   clocks = <_clk>, <_ref_clk>;
+   clock-names = "psm", "pll_ref";
+   #phy-cells = <0>;
+   };
+
+   dsi0: dsi@fd0c {
+   compatible = "cdns,dsi";
+   reg = <0x0 0xfd0c 0x0 0x1000>;
+   clocks = <>, <>;
+   clock-names = "dsi_p_clk", "dsi_sys_clk";
+   interrupts = <1>;
+   phys = <>;
+   phy-names = "dphy";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@1 {
+   reg = <1>;
+   dsi0_dpi_input: endpoint {
+   remote-endpoint = <_dpi_output>;
+   };
+   };
+   };
+
+   panel: dsi-dev@0 {
+   compatible = "";
+   reg = <0>;
+   };
+   };
+
+or
+
+   dsi0: dsi@fd0c {
+   compatible = "cdns,dsi";
+   reg = <0x0 0xfd0c 0x0 0x1000>;
+   clocks = <>, <>;
+   clock-names = "dsi_p_clk", "dsi_sys_clk";
+   interrupts = <1>;
+   phys = <>;
+   phy-names = "dphy";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   dsi0_output: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <_panel_input>;
+   };
+

[PATCH v7 2/2] dt-bindings: drm/bridge: Document Cadence DSI bridge bindings

[Boris Brezillon]

From: Boris Brezillon 

Document the bindings used for the Cadence DSI bridge.

Signed-off-by: Boris Brezillon 
Reviewed-by: Rob Herring 
---
Changes in v7:
- Add Rob's R-b

Changes in v6:
- Document the DPHY bindings
- Drop Rob's ack because of the addition DPHY bindings doc

Changes in v5:
- Add optional reset line for the peripheral/APB logic

Changes in v4:
- Rename DSI clks (suggested by Tomi)
- Drop the IP version in the compatible since it can be extracted from
  a register (suggested by Andrzej)

Changes in v3:
- Fix clock names in the example
- Document how to represent DSI devices that are controller through
  an external bus like I2C or SPI

Changes in v2:
- None
---
 .../bindings/display/bridge/cdns,dsi.txt   | 133 +
 1 file changed, 133 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt

diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt 
b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt
new file mode 100644
index ..f5725bb6c61c
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt
@@ -0,0 +1,133 @@
+Cadence DSI bridge
+==
+
+The Cadence DSI bridge is a DPI to DSI bridge supporting up to 4 DSI lanes.
+
+Required properties:
+- compatible: should be set to "cdns,dsi".
+- reg: physical base address and length of the controller's registers.
+- interrupts: interrupt line connected to the DSI bridge.
+- clocks: DSI bridge clocks.
+- clock-names: must contain "dsi_p_clk" and "dsi_sys_clk".
+- phys: phandle link to the MIPI D-PHY controller.
+- phy-names: must contain "dphy".
+- #address-cells: must be set to 1.
+- #size-cells: must be set to 0.
+
+Optional properties:
+- resets: DSI reset lines.
+- reset-names: can contain "dsi_p_rst".
+
+Required subnodes:
+- ports: Ports as described in Documentation/devicetree/bindings/graph.txt.
+  2 ports are available:
+  * port 0: this port is only needed if some of your DSI devices are
+   controlled through  an external bus like I2C or SPI. Can have at
+   most 4 endpoints. The endpoint number is directly encoding the
+   DSI virtual channel used by this device.
+  * port 1: represents the DPI input.
+  Other ports will be added later to support the new kind of inputs.
+
+- one subnode per DSI device connected on the DSI bus. Each DSI device should
+  contain a reg property encoding its virtual channel.
+
+Cadence DPHY
+
+
+Cadence DPHY block.
+
+Required properties:
+- compatible: should be set to "cdns,dphy".
+- reg: physical base address and length of the DPHY registers.
+- clocks: DPHY reference clocks.
+- clock-names: must contain "psm" and "pll_ref".
+- #phy-cells: must be set to 0.
+
+
+Example:
+   dphy0: dphy@fd0e{
+   compatible = "cdns,dphy";
+   reg = <0x0 0xfd0e 0x0 0x1000>;
+   clocks = <_clk>, <_ref_clk>;
+   clock-names = "psm", "pll_ref";
+   #phy-cells = <0>;
+   };
+
+   dsi0: dsi@fd0c {
+   compatible = "cdns,dsi";
+   reg = <0x0 0xfd0c 0x0 0x1000>;
+   clocks = <>, <>;
+   clock-names = "dsi_p_clk", "dsi_sys_clk";
+   interrupts = <1>;
+   phys = <>;
+   phy-names = "dphy";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@1 {
+   reg = <1>;
+   dsi0_dpi_input: endpoint {
+   remote-endpoint = <_dpi_output>;
+   };
+   };
+   };
+
+   panel: dsi-dev@0 {
+   compatible = "";
+   reg = <0>;
+   };
+   };
+
+or
+
+   dsi0: dsi@fd0c {
+   compatible = "cdns,dsi";
+   reg = <0x0 0xfd0c 0x0 0x1000>;
+   clocks = <>, <>;
+   clock-names = "dsi_p_clk", "dsi_sys_clk";
+   interrupts = <1>;
+   phys = <>;
+   phy-names = "dphy";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   dsi0_output: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <_panel_input>;
+  

[PATCH v7 1/2] drm/bridge: Add Cadence DSI driver

[Boris Brezillon]

From: Boris Brezillon 

Add a driver for Cadence DPI -> DSI bridge.

This driver only support a subset of Cadence DSI bridge capabilities.

This driver has been tested/debugged in a simulated environment which
explains why some of the features are missing.  Here is a
non-exhaustive list of missing features:
 * burst mode
 * DPHY init/configuration steps
 * support for additional input interfaces (SDI input)

DSI commands and non-burst video mode have been tested.

Signed-off-by: Boris Brezillon 
Reviewed-by: Andrzej Hajda 
Acked-by: Eric Anholt 
Reviewed-by: Archit Taneja 
---
Changes in v7:
- Use DIV_ROUND_UP_ULL() to fix a build error on arm 32-bit
- Add Archit's R-b

Changes in v6:
- Use SPDX header
- Do not enable the sys_clk in the probe function
- Remove unneeded udelay()
- Add a function to make sure the PLL and pixel clock are close enough
  to be recoverable if they don't match exactly
- Add the DPHY init sequence used in simulation (likely to be different
  based on each SoC integration)

Changes in v5:
- Add runtime PM support

Changes in v4:
- Fix typos
- Rename clks as suggested by Tomi
- Fix DSI setup done in cdns_dsi_bridge_enable()
- Add a precision about where this bridge is supposed to used to the
  Kconfig entry
- Let DRM_CDNS_DSI select DRM_PANEL_BRIDGE
- Remove the IP version from the DT compatible name
- Adapt register the layout to match the one used in the last revision
  of the IP (hopefully the final version)

Changes in v3:
- replace magic values by real timing calculation. The DPHY PLL clock
  is still hardcoded since we don't have a working DPHY block yet, and
  this is the piece of HW we need to dynamically configure the PLL
  rate based on the display refresh rate and the resolution.
- parse DSI devices represented with the OF-graph. This is needed to
  support DSI devices controlled through an external bus like I2C or
  SPI.
- use the DRM panel-bridge infrastructure to simplify the DRM panel
  logic

Changes in v2:
- rebase on v4.12-rc1 and adapt to driver to the drm_bridge API changes
- return the correct error when devm_clk_get(sysclk) fails
- add missing depends on OF and select DRM_PANEL in the Kconfig entry

DSI runtime PM
---
 drivers/gpu/drm/bridge/Kconfig|   10 +
 drivers/gpu/drm/bridge/Makefile   |1 +
 drivers/gpu/drm/bridge/cdns-dsi.c | 1623 +
 3 files changed, 1634 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/cdns-dsi.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 42c9c2d13752..1d75d3a1f951 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -25,6 +25,16 @@ config DRM_ANALOGIX_ANX78XX
  the HDMI output of an application processor to MyDP
  or DisplayPort.
 
+config DRM_CDNS_DSI
+   tristate "Cadence DPI/DSI bridge"
+   select DRM_KMS_HELPER
+   select DRM_MIPI_DSI
+   select DRM_PANEL_BRIDGE
+   depends on OF
+   help
+ Support Cadence DPI to DSI bridge. This is an internal
+ bridge and is meant to be directly embedded in a SoC.
+
 config DRM_DUMB_VGA_DAC
tristate "Dumb VGA DAC Bridge support"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index fd90b16a65c0..35f88d48ec20 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -1,5 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0
 obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
+obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
 obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
 obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o
 obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) += 
megachips-stdp-ge-b850v3-fw.o
diff --git a/drivers/gpu/drm/bridge/cdns-dsi.c 
b/drivers/gpu/drm/bridge/cdns-dsi.c
new file mode 100644
index ..9d75e6707e05
--- /dev/null
+++ b/drivers/gpu/drm/bridge/cdns-dsi.c
@@ -0,0 +1,1623 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright: 2017 Cadence Design Systems, Inc.
+ *
+ * Author: Boris Brezillon 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define IP_CONF0x0
+#define SP_HS_FIFO_DEPTH(x)(((x) & GENMASK(30, 26)) >> 26)
+#define SP_LP_FIFO_DEPTH(x)(((x) & GENMASK(25, 21)) >> 21)
+#define VRS_FIFO_DEPTH(x)  (((x) & GENMASK(20, 16)) >> 16)
+#define DIRCMD_FIFO_DEPTH(x)   (((x) & GENMASK(15, 13)) >> 13)
+#define SDI_IFACE_32   BIT(12)
+#define INTERNAL_DATAPATH_32   (0 << 10)
+#define INTERNAL_DATAPATH_16   (1 << 10)
+#define INTERNAL_DATAPATH_8(3 << 10)
+#define INTERNAL_DATAPATH_SIZE ((x) & 

Re: [PATCH v6 1/2] drm/bridge: Add Cadence DSI driver

[Boris Brezillon]

Hi Archit,

On Sun, 15 Apr 2018 13:39:44 +0530
Archit Taneja  wrote:

> > +static int cdns_dsi_get_dphy_pll_cfg(struct cdns_dphy *dphy,
> > +struct cdns_dphy_cfg *cfg,
> > +unsigned int dpi_htotal,
> > +unsigned int dpi_bpp,
> > +unsigned int dpi_hz,
> > +unsigned int dsi_htotal,
> > +unsigned int dsi_nlanes,
> > +unsigned int *dsi_hfp_ext)
> > +{
> > +   u64 dlane_bps, dlane_bps_max, fbdiv, fbdiv_max, adj_dsi_htotal;
> > +   unsigned long pll_ref_hz = clk_get_rate(dphy->pll_ref_clk);
> > +
> > +   memset(cfg, 0, sizeof(*cfg));
> > +
> > +   cfg->nlanes = dsi_nlanes;
> > +
> > +   if (pll_ref_hz < 960 || pll_ref_hz >= 15000)
> > +   return -EINVAL;
> > +   else if (pll_ref_hz < 1920)
> > +   cfg->pll_ipdiv = 1;
> > +   else if (pll_ref_hz < 3840)
> > +   cfg->pll_ipdiv = 2;
> > +   else if (pll_ref_hz < 7680)
> > +   cfg->pll_ipdiv = 4;
> > +   else
> > +   cfg->pll_ipdiv = 8;
> > +
> > +   /*
> > +* Make sure DSI htotal is aligned on a lane boundary when calculating
> > +* the expected data rate. This is done by extending HFP in case of
> > +* misalignment.
> > +*/
> > +   adj_dsi_htotal = dsi_htotal;
> > +   if (dsi_htotal % dsi_nlanes)
> > +   adj_dsi_htotal += dsi_nlanes - (dsi_htotal % dsi_nlanes);
> > +
> > +   dlane_bps = (u64)dpi_hz * adj_dsi_htotal;
> > +
> > +   /* data rate in bytes/sec is not an integer, refuse the mode. */
> > +   if (do_div(dlane_bps, dsi_nlanes * dpi_htotal))
> > +   return -EINVAL;
> > +
> > +   /* data rate was in bytes/sec, convert to bits/sec. */
> > +   dlane_bps *= 8;
> > +
> > +   if (dlane_bps > 25UL || dlane_bps < 16000UL)
> > +   return -EINVAL;
> > +   else if (dlane_bps >= 125000)
> > +   cfg->pll_opdiv = 1;
> > +   else if (dlane_bps >= 63000)
> > +   cfg->pll_opdiv = 2;
> > +   else if (dlane_bps >= 32000)
> > +   cfg->pll_opdiv = 4;
> > +   else if (dlane_bps >= 16000)
> > +   cfg->pll_opdiv = 8;
> > +
> > +   /*
> > +* Allow a deviation of 0.2% on the per-lane data rate to try to
> > +* recover a potential mismatch between DPI and PPI clks.
> > +*/
> > +   dlane_bps_max = dlane_bps + (dlane_bps / 500);  
> 
> kbuild reported an error for 32 bit archs. I'm guessing it's because of
> this divide above?

Yep, DIV_ROUND_UP_ULL() should fix the problem.

> 
> 
> > +
> > +   fbdiv_max = DIV_ROUND_DOWN_ULL((dlane_bps + (dlane_bps / 500)) * 2 *  
> 
> You could use dlane_bps_max here instead.

Sure.

> 
> Otherwise,
> 
> Reviewed-by: Archit Taneja 

Thanks for the review.

Does that mean I'm allowed to apply the patch to drm-misc-next myself
after fixing the div64 issue?

Regards,

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

[Bug 91808] trine1 misrender r600g

[bugzilla-daemon]

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

--- Comment #10 from Hamish Wilson  ---
Created attachment 138966
  --> https://bugs.freedesktop.org/attachment.cgi?id=138966=edit
April 2018 Graphical Artifact Screenshots

I am seeing graphical artifacts across several levels of Trine Enchanted
Edition. These are most apparent with the gears in the Academy Hallways level,
but I also encountered a curious lighting artifact in the Dragon Graveyard
level as well as a problem with the rain later on in the same level. I am using
a Sapphire Radeon HD 6870 graphics card on Arch Linux using the 4.16.3-1-ARCH
Kernel package, the 1:18.0.1-1 xf86-video-ati pacakge, and the 18.0.1-1 Mesa
package.

-- 
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