Re: [PATCHv4 3/5] dt-bindings: document the CEC GPIO bindings

[Hans Verkuil]

Ping!

Still waiting for an Ack from the devicetree devs so this can be merged for 
4.15.

Regards,

Hans

On 08/31/2017 01:01 PM, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> Document the bindings for the cec-gpio module for hardware where the
> CEC line and optionally the HPD line are connected to GPIO lines.
> 
> Signed-off-by: Hans Verkuil 
> ---
>  .../devicetree/bindings/media/cec-gpio.txt | 22 
> ++
>  1 file changed, 22 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/cec-gpio.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/cec-gpio.txt 
> b/Documentation/devicetree/bindings/media/cec-gpio.txt
> new file mode 100644
> index ..db20a7452dbd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/cec-gpio.txt
> @@ -0,0 +1,22 @@
> +* HDMI CEC GPIO driver
> +
> +The HDMI CEC GPIO module supports CEC implementations where the CEC line
> +is hooked up to a pull-up GPIO line and - optionally - the HPD line is
> +hooked up to another GPIO line.
> +
> +Required properties:
> +  - compatible: value must be "cec-gpio"
> +  - cec-gpio: gpio that the CEC line is connected to
> +
> +Optional property:
> +  - hpd-gpio: gpio that the HPD line is connected to
> +
> +Example for the Raspberry Pi 3 where the CEC line is connected to
> +pin 26 aka BCM7 aka CE1 on the GPIO pin header and the HPD line is
> +connected to pin 11 aka BCM17:
> +
> +cec-gpio@7 {
> +   compatible = "cec-gpio";
> +   cec-gpio = <&gpio 7 GPIO_OPEN_DRAIN>;
> +   hpd-gpio = <&gpio 17 GPIO_ACTIVE_HIGH>;
> +};
> 

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

Re: [PATCH v3 10/22] drm/imx: Use drm_gem_fb_create() and drm_gem_fb_prepare_fb()

[Philipp Zabel]

Hi Noralf,

On Sun, 2017-08-13 at 15:31 +0200, Noralf Trønnes wrote:
> drm_fb_cma_create() and drm_fb_cma_prepare_fb() are just wrappers now,
> use drm_gem_fb_create() and drm_gem_fb_prepare_fb() directly.
> 
> > Cc: Philipp Zabel 
> > Signed-off-by: Noralf Trønnes 
> ---
>  drivers/gpu/drm/imx/imx-drm-core.c | 3 ++-
>  drivers/gpu/drm/imx/ipuv3-plane.c  | 3 ++-
>  2 files changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
> b/drivers/gpu/drm/imx/imx-drm-core.c
> index f91cb72..93c7e3f 100644
> --- a/drivers/gpu/drm/imx/imx-drm-core.c
> +++ b/drivers/gpu/drm/imx/imx-drm-core.c
> @@ -24,6 +24,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -105,7 +106,7 @@ static int imx_drm_atomic_check(struct drm_device *dev,
>  }
>  
>  static const struct drm_mode_config_funcs imx_drm_mode_config_funcs = {
> > -   .fb_create = drm_fb_cma_create,
> > +   .fb_create = drm_gem_fb_create,
> >     .output_poll_changed = imx_drm_output_poll_changed,
> >     .atomic_check = imx_drm_atomic_check,
> >     .atomic_commit = drm_atomic_helper_commit,
> diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
> b/drivers/gpu/drm/imx/ipuv3-plane.c
> index debde2d..82e1c50 100644
> --- a/drivers/gpu/drm/imx/ipuv3-plane.c
> +++ b/drivers/gpu/drm/imx/ipuv3-plane.c
> @@ -18,6 +18,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include "video/imx-ipu-v3.h"
> @@ -661,7 +662,7 @@ static void ipu_plane_atomic_update(struct drm_plane 
> *plane,
>  }
>  
>  static const struct drm_plane_helper_funcs ipu_plane_helper_funcs = {
> > -   .prepare_fb = drm_fb_cma_prepare_fb,
> > +   .prepare_fb = drm_gem_fb_prepare_fb,
> >     .atomic_check = ipu_plane_atomic_check,
> >     .atomic_disable = ipu_plane_atomic_disable,
> >     .atomic_update = ipu_plane_atomic_update,

Acked-by: Philipp Zabel 

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

Re: [PATCH 04/12] drm/cirrus: initialize start and size fields

[Gerd Hoffmann]

On Fri, 2017-09-08 at 19:05 +0530, Varad Gautam wrote:
> From: Dominik Behr 
> 
> initialize start and size fields in fb info
> so user space drivers like fbdev can map the memory

Hmm? That works just fine in vanilla 4.12 ...

cheers,
  Gerd

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

Re: [PATCH 05/12] drm/cirrus: hardcode vram size

[Gerd Hoffmann]

On Fri, 2017-09-08 at 19:05 +0530, Varad Gautam wrote:
> From: Zach Reizner 
> 
> There is no reliable way of detecting actual VRAM size, which is
> important in the case of cirrus because cursor data is always stored
> in
> the last 16K of VRAM. Because qemu effectivaly hardcodes 4MB but
> reports
> 32MB, we hardcode 4MB in the cirrus driver to ensure the cursor works
> properly.

This comment is misleading.  pci bar size != vram size.  There is more
stuff in the pci bar than just the vram, thats why it is larger than
vram.  It's not qemu mis-reporting something.

The actual vram size is 4MB.  This is what the original hardware had,
so the qemu emulation uses that too.  So the fix is correct, but please
adjust commit message and comment.

cheers,
  Gerd


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

Re: [PATCH 11/12] drm/cirrus: implement atomic hardware cursor support

[Gerd Hoffmann]

On Fri, 2017-09-08 at 19:05 +0530, Varad Gautam wrote:
> From: Varad Gautam 
> 
> This enables cursor plane on cirrus. It only supports ARGB 8-bit
> cursors
> from userspace, and downconverts them to 1-bit black and white with
> masking, which is all cirrus hardware can support. Only cursors with
> size 32x32 or 64x64 will work.

Isn't it better to just not implement hardware cursor then, so
userspace can fallback to software cursor instead?  Advertising ARGB
cursor support to userspace, but then crippling those cursors to
black'n'white doesn't look sensible to me ...

cheers,
  Gerd

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

[Bug 196777] Virtual guest using video device QXL does not reach GDM

[bugzilla-daemon]

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

Gerd Hoffmann (kra...@redhat.com) changed:

   What|Removed |Added

 CC||kra...@redhat.com

--- Comment #2 from Gerd Hoffmann (kra...@redhat.com) ---
can you check whenever this patch fixes it?

https://www.kraxel.org/cgit/linux/commit/?h=drm-qxl-atomic&id=b16a0bb7a9d54d9dd256059b35adf6f96fddc22e

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

Re: [PATCH] dma-fence: fix dma_fence_get_rcu_safe

[Christian König]

Sorry for the delayed response, but your mail somehow ended up in the 
Spam folder.


Am 04.09.2017 um 15:40 schrieb Chris Wilson:

Quoting Christian König (2017-09-04 14:27:33)

From: Christian König 

The logic is buggy and unnecessary complex. When dma_fence_get_rcu() fails to
acquire a reference it doesn't necessary mean that there is no fence at all.

It usually mean that the fence was replaced by a new one and in this situation
we certainly want to have the new one as result and *NOT* NULL.

Which is not guaranteed by the code you wrote either.

The point of the comment is that the mb is only inside the successful
kref_atomic_inc_unless_zero, and that only after that mb do you know
whether or not you have the current fence.

You can argue that you want to replace the
if (!dma_fence_get_rcu())
return NULL
with
if (!dma_fence_get_rcu()
continue;
but it would be incorrect to say that by simply ignoring the
post-condition check that you do have the right fence.


You are completely missing the point here.

It is irrelevant if you have the current fence or not when you return. 
You can only guarantee that it is the current fence when you take a look 
and that is exactly what we want to avoid.


So the existing code is complete nonsense. Instead what we need to 
guarantee is that we return *ANY* fence which we can grab a reference for.


See the usual life of a fence* variable looks like this:
1. assigning pointer to fence A;
2. assigning pointer to fence B;
3. assigning pointer to fence C;


When dma_fence_get_rcu_safe() is called between step #1 and step #2 for 
example it is perfectly valid to just return either fence A or fence B.


But it is invalid to return NULL because that suggests that we don't 
need to sync at all.


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

Re: [PATCH] dma-fence: fix dma_fence_get_rcu_safe

[Chris Wilson]

Quoting Christian König (2017-09-11 09:50:40)
> Sorry for the delayed response, but your mail somehow ended up in the 
> Spam folder.
> 
> Am 04.09.2017 um 15:40 schrieb Chris Wilson:
> > Quoting Christian König (2017-09-04 14:27:33)
> >> From: Christian König 
> >>
> >> The logic is buggy and unnecessary complex. When dma_fence_get_rcu() fails 
> >> to
> >> acquire a reference it doesn't necessary mean that there is no fence at 
> >> all.
> >>
> >> It usually mean that the fence was replaced by a new one and in this 
> >> situation
> >> we certainly want to have the new one as result and *NOT* NULL.
> > Which is not guaranteed by the code you wrote either.
> >
> > The point of the comment is that the mb is only inside the successful
> > kref_atomic_inc_unless_zero, and that only after that mb do you know
> > whether or not you have the current fence.
> >
> > You can argue that you want to replace the
> >   if (!dma_fence_get_rcu())
> >   return NULL
> > with
> >   if (!dma_fence_get_rcu()
> >   continue;
> > but it would be incorrect to say that by simply ignoring the
> > post-condition check that you do have the right fence.
> 
> You are completely missing the point here.
> 
> It is irrelevant if you have the current fence or not when you return. 
> You can only guarantee that it is the current fence when you take a look 
> and that is exactly what we want to avoid.
> 
> So the existing code is complete nonsense. Instead what we need to 
> guarantee is that we return *ANY* fence which we can grab a reference for.

Not quite. We can grab a reference on a fence that was already freed and
reused between the rcu_dereference() and dma_fence_get_rcu().
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 102650] [CI][ALL] igt@sw_sync@timeline_closed - Failure waiting on unsignaled fence on closed timeline

[bugzilla-daemon]

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

Chris Wilson  changed:

   What|Removed |Added

   Assignee|intel-gfx-bugs@lists.freede |dri-devel@lists.freedesktop
   |sktop.org   |.org
  Component|DRM/Intel   |IGT
 QA Contact|intel-gfx-bugs@lists.freede |
   |sktop.org   |

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

[Bug 102650] [CI][ALL] igt@sw_sync@timeline_closed - Failure waiting on unsignaled fence on closed timeline

[bugzilla-daemon]

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

--- Comment #1 from Chris Wilson  ---
Test needs to be updated to reflect the kernel.

-- 
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] dma-fence: fix dma_fence_get_rcu_safe

[Christian König]

Am 11.09.2017 um 10:59 schrieb Chris Wilson:

Quoting Christian König (2017-09-11 09:50:40)

Sorry for the delayed response, but your mail somehow ended up in the
Spam folder.

Am 04.09.2017 um 15:40 schrieb Chris Wilson:

Quoting Christian König (2017-09-04 14:27:33)

From: Christian König 

The logic is buggy and unnecessary complex. When dma_fence_get_rcu() fails to
acquire a reference it doesn't necessary mean that there is no fence at all.

It usually mean that the fence was replaced by a new one and in this situation
we certainly want to have the new one as result and *NOT* NULL.

Which is not guaranteed by the code you wrote either.

The point of the comment is that the mb is only inside the successful
kref_atomic_inc_unless_zero, and that only after that mb do you know
whether or not you have the current fence.

You can argue that you want to replace the
   if (!dma_fence_get_rcu())
   return NULL
with
   if (!dma_fence_get_rcu()
   continue;
but it would be incorrect to say that by simply ignoring the
post-condition check that you do have the right fence.

You are completely missing the point here.

It is irrelevant if you have the current fence or not when you return.
You can only guarantee that it is the current fence when you take a look
and that is exactly what we want to avoid.

So the existing code is complete nonsense. Instead what we need to
guarantee is that we return *ANY* fence which we can grab a reference for.

Not quite. We can grab a reference on a fence that was already freed and
reused between the rcu_dereference() and dma_fence_get_rcu().


Reusing a memory structure before the RCU grace period is completed is 
illegal, otherwise the whole RCU approach won't work.


So that case can't happen.

Regards,
Christian.


-Chris



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

Re: [PATCH] dma-fence: fix dma_fence_get_rcu_safe

[Chris Wilson]

Quoting Christian König (2017-09-11 10:06:50)
> Am 11.09.2017 um 10:59 schrieb Chris Wilson:
> > Quoting Christian König (2017-09-11 09:50:40)
> >> Sorry for the delayed response, but your mail somehow ended up in the
> >> Spam folder.
> >>
> >> Am 04.09.2017 um 15:40 schrieb Chris Wilson:
> >>> Quoting Christian König (2017-09-04 14:27:33)
>  From: Christian König 
> 
>  The logic is buggy and unnecessary complex. When dma_fence_get_rcu() 
>  fails to
>  acquire a reference it doesn't necessary mean that there is no fence at 
>  all.
> 
>  It usually mean that the fence was replaced by a new one and in this 
>  situation
>  we certainly want to have the new one as result and *NOT* NULL.
> >>> Which is not guaranteed by the code you wrote either.
> >>>
> >>> The point of the comment is that the mb is only inside the successful
> >>> kref_atomic_inc_unless_zero, and that only after that mb do you know
> >>> whether or not you have the current fence.
> >>>
> >>> You can argue that you want to replace the
> >>>if (!dma_fence_get_rcu())
> >>>return NULL
> >>> with
> >>>if (!dma_fence_get_rcu()
> >>>continue;
> >>> but it would be incorrect to say that by simply ignoring the
> >>> post-condition check that you do have the right fence.
> >> You are completely missing the point here.
> >>
> >> It is irrelevant if you have the current fence or not when you return.
> >> You can only guarantee that it is the current fence when you take a look
> >> and that is exactly what we want to avoid.
> >>
> >> So the existing code is complete nonsense. Instead what we need to
> >> guarantee is that we return *ANY* fence which we can grab a reference for.
> > Not quite. We can grab a reference on a fence that was already freed and
> > reused between the rcu_dereference() and dma_fence_get_rcu().
> 
> Reusing a memory structure before the RCU grace period is completed is 
> illegal, otherwise the whole RCU approach won't work.

RCU only protects that the pointer remains valid. If you use
SLAB_TYPESAFE_BY_RCU, it is possible to reuse the pointer within a grace
period. It does happen and that is the point the comment is trying to
make.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 4/6] [media] exynos-gsc: Add hardware rotation limits

[Sylwester Nawrocki]

On 09/08/2017 08:02 AM, Hoegeun Kwon wrote:

The hardware rotation limits of gsc depends on SOC (Exynos
5250/5420/5433). Distinguish them and add them to the driver data.

Signed-off-by: Hoegeun Kwon 
---
  drivers/media/platform/exynos-gsc/gsc-core.c | 96 
  1 file changed, 83 insertions(+), 13 deletions(-)

diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c 
b/drivers/media/platform/exynos-gsc/gsc-core.c
index 4380150..8f8636e 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -943,7 +943,37 @@ static irqreturn_t gsc_irq_handler(int irq, void *priv)
return IRQ_HANDLED;
  }
  
-static struct gsc_pix_max gsc_v_100_max = {

+static struct gsc_pix_max gsc_v_5250_max = {
+   .org_scaler_bypass_w= 8192,
+   .org_scaler_bypass_h= 8192,
+   .org_scaler_input_w = 4800,
+   .org_scaler_input_h = 3344,
+   .real_rot_dis_w = 4800,
+   .real_rot_dis_h = 3344,
+   .real_rot_en_w  = 2016,
+   .real_rot_en_h  = 2016,
+   .target_rot_dis_w   = 4800,
+   .target_rot_dis_h   = 3344,
+   .target_rot_en_w= 2016,
+   .target_rot_en_h= 2016,
+};
+
+static struct gsc_pix_max gsc_v_5420_max = {
+   .org_scaler_bypass_w= 8192,
+   .org_scaler_bypass_h= 8192,
+   .org_scaler_input_w = 4800,
+   .org_scaler_input_h = 3344,
+   .real_rot_dis_w = 4800,
+   .real_rot_dis_h = 3344,
+   .real_rot_en_w  = 2048,
+   .real_rot_en_h  = 2048,
+   .target_rot_dis_w   = 4800,
+   .target_rot_dis_h   = 3344,
+   .target_rot_en_w= 2016,
+   .target_rot_en_h= 2016,
+};
+
+static struct gsc_pix_max gsc_v_5433_max = {
.org_scaler_bypass_w= 8192,
.org_scaler_bypass_h= 8192,
.org_scaler_input_w = 4800,
@@ -979,8 +1009,8 @@ static irqreturn_t gsc_irq_handler(int irq, void *priv)
.target_h   = 2,  /* yuv420 : 2, others : 1 */
  };
  
-static struct gsc_variant gsc_v_100_variant = {

-   .pix_max= &gsc_v_100_max,
+static struct gsc_variant gsc_v_5250_variant = {
+   .pix_max= &gsc_v_5250_max,
.pix_min= &gsc_v_100_min,
.pix_align  = &gsc_v_100_align,
.in_buf_cnt = 32,
@@ -992,12 +1022,48 @@ static irqreturn_t gsc_irq_handler(int irq, void *priv)
.local_sc_down  = 2,
  };
  
-static struct gsc_driverdata gsc_v_100_drvdata = {

+static struct gsc_variant gsc_v_5420_variant = {
+   .pix_max= &gsc_v_5420_max,
+   .pix_min= &gsc_v_100_min,
+   .pix_align  = &gsc_v_100_align,
+   .in_buf_cnt = 32,
+   .out_buf_cnt= 32,
+   .sc_up_max  = 8,
+   .sc_down_max= 16,
+   .poly_sc_down_max   = 4,
+   .pre_sc_down_max= 4,
+   .local_sc_down  = 2,
+};
+
+static struct gsc_variant gsc_v_5433_variant = {
+   .pix_max= &gsc_v_5433_max,
+   .pix_min= &gsc_v_100_min,
+   .pix_align  = &gsc_v_100_align,
+   .in_buf_cnt = 32,
+   .out_buf_cnt= 32,
+   .sc_up_max  = 8,
+   .sc_down_max= 16,
+   .poly_sc_down_max   = 4,
+   .pre_sc_down_max= 4,
+   .local_sc_down  = 2,
+};
+
+static struct gsc_driverdata gsc_v_5250_drvdata = {
.variant = {
-   [0] = &gsc_v_100_variant,
-   [1] = &gsc_v_100_variant,
-   [2] = &gsc_v_100_variant,
-   [3] = &gsc_v_100_variant,
+   [0] = &gsc_v_5250_variant,
+   [1] = &gsc_v_5250_variant,
+   [2] = &gsc_v_5250_variant,
+   [3] = &gsc_v_5250_variant,
+   },
+   .num_entities = 4,
+   .clk_names = { "gscl" },
+   .num_clocks = 1,
+};
+
+static struct gsc_driverdata gsc_v_5420_drvdata = {
+   .variant = {
+   [0] = &gsc_v_5420_variant,
+   [1] = &gsc_v_5420_variant,
},
.num_entities = 4,
.clk_names = { "gscl" },
@@ -1006,9 +1072,9 @@ static irqreturn_t gsc_irq_handler(int irq, void *priv)
  
  static struct gsc_driverdata gsc_5433_drvdata = {

.variant = {
-   [0] = &gsc_v_100_variant,
-   [1] = &gsc_v_100_variant,
-   [2] = &gsc_v_100_variant,
+   [0] = &gsc_v_5433_variant,
+   [1] = &gsc_v_5433_variant,
+   [2] = &gsc_v_5433_variant,
},
.num_entities = 3,
.clk_names = { "pclk", "aclk", "aclk_xiu", "aclk_gsclbend" },
@@ -1017,8 +1083,12 @@ static irqreturn_t gsc_irq_handler(int irq, void *priv)
  
  static const struct of_device_id exynos_gsc_match[] = {

{
-

[PATCH] qxl: fix primary surface handling

[Gerd Hoffmann]

The atomic conversion of the qxl driver didn't got the primary surface
handling completely right.  It works in the common simple cases, but
fails for example when changing the display resolution using xrandr or
in multihead setups.

The rules are simple:  There is one primary surface.  Before defining a
new one you have to destroy the old one.

This patch makes qxl_primary_atomic_update() destroy the primary surface
before defining a new one.  It fixes is_primary flag updates.  It adds
is_primary checks so we don't try to update the primary surface in case
it already has the state we want it being in.

Signed-off-by: Gerd Hoffmann 
---
 drivers/gpu/drm/qxl/qxl_display.c | 36 
 1 file changed, 20 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_display.c 
b/drivers/gpu/drm/qxl/qxl_display.c
index 14c5613b43..e1dd05423e 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -509,23 +509,25 @@ static void qxl_primary_atomic_update(struct drm_plane 
*plane,
.y2 = qfb->base.height
};
 
-   if (!old_state->fb) {
-   qxl_io_log(qdev,
-  "create primary fb: %dx%d,%d,%d\n",
-  bo->surf.width, bo->surf.height,
-  bo->surf.stride, bo->surf.format);
-
-   qxl_io_create_primary(qdev, 0, bo);
-   bo->is_primary = true;
-   return;
-
-   } else {
+   if (old_state->fb) {
qfb_old = to_qxl_framebuffer(old_state->fb);
bo_old = gem_to_qxl_bo(qfb_old->obj);
+   } else {
+   bo_old = NULL;
+   }
+
+   if (bo == bo_old)
+   return;
+
+   if (bo_old && bo_old->is_primary) {
+   qxl_io_destroy_primary(qdev);
bo_old->is_primary = false;
}
 
-   bo->is_primary = true;
+   if (!bo->is_primary) {
+   qxl_io_create_primary(qdev, 0, bo);
+   bo->is_primary = true;
+   }
qxl_draw_dirty_fb(qdev, qfb, bo, 0, 0, &norect, 1, 1);
 }
 
@@ -534,13 +536,15 @@ static void qxl_primary_atomic_disable(struct drm_plane 
*plane,
 {
struct qxl_device *qdev = plane->dev->dev_private;
 
-   if (old_state->fb)
-   {   struct qxl_framebuffer *qfb =
+   if (old_state->fb) {
+   struct qxl_framebuffer *qfb =
to_qxl_framebuffer(old_state->fb);
struct qxl_bo *bo = gem_to_qxl_bo(qfb->obj);
 
-   qxl_io_destroy_primary(qdev);
-   bo->is_primary = false;
+   if (bo->is_primary) {
+   qxl_io_destroy_primary(qdev);
+   bo->is_primary = false;
+   }
}
 }
 
-- 
2.9.3

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

[Bug 102616] [CI][SNB,HSW,APL,KBL] igt@gem_eio@in-flight - Failed assertion: __vgem_fence_signal(fd, fence) == 0

[bugzilla-daemon]

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

--- Comment #5 from Chris Wilson  ---
*** Bug 102652 has been marked as a duplicate of this bug. ***

-- 
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] dma-fence: fix dma_fence_get_rcu_safe

[Chris Wilson]

Quoting Christian König (2017-09-11 10:57:57)
> Am 11.09.2017 um 11:23 schrieb Chris Wilson:
> > Quoting Christian König (2017-09-11 10:06:50)
> >> Am 11.09.2017 um 10:59 schrieb Chris Wilson:
> >>> Quoting Christian König (2017-09-11 09:50:40)
>  Sorry for the delayed response, but your mail somehow ended up in the
>  Spam folder.
> 
>  Am 04.09.2017 um 15:40 schrieb Chris Wilson:
> > Quoting Christian König (2017-09-04 14:27:33)
> >> From: Christian König 
> >>
> >> The logic is buggy and unnecessary complex. When dma_fence_get_rcu() 
> >> fails to
> >> acquire a reference it doesn't necessary mean that there is no fence 
> >> at all.
> >>
> >> It usually mean that the fence was replaced by a new one and in this 
> >> situation
> >> we certainly want to have the new one as result and *NOT* NULL.
> > Which is not guaranteed by the code you wrote either.
> >
> > The point of the comment is that the mb is only inside the successful
> > kref_atomic_inc_unless_zero, and that only after that mb do you know
> > whether or not you have the current fence.
> >
> > You can argue that you want to replace the
> > if (!dma_fence_get_rcu())
> > return NULL
> > with
> > if (!dma_fence_get_rcu()
> > continue;
> > but it would be incorrect to say that by simply ignoring the
> > post-condition check that you do have the right fence.
>  You are completely missing the point here.
> 
>  It is irrelevant if you have the current fence or not when you return.
>  You can only guarantee that it is the current fence when you take a look
>  and that is exactly what we want to avoid.
> 
>  So the existing code is complete nonsense. Instead what we need to
>  guarantee is that we return *ANY* fence which we can grab a reference 
>  for.
> >>> Not quite. We can grab a reference on a fence that was already freed and
> >>> reused between the rcu_dereference() and dma_fence_get_rcu().
> >> Reusing a memory structure before the RCU grace period is completed is
> >> illegal, otherwise the whole RCU approach won't work.
> > RCU only protects that the pointer remains valid. If you use
> > SLAB_TYPESAFE_BY_RCU, it is possible to reuse the pointer within a grace
> > period. It does happen and that is the point the comment is trying to
> > make.
> 
> Yeah, but that is illegal with a fence objects.
> 
> When anybody allocates fences this way it breaks at least 
> reservation_object_get_fences_rcu(), 
> reservation_object_wait_timeout_rcu() and 
> reservation_object_test_signaled_single().

Many, many months ago I sent patches to fix them all.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] dma-fence: fix dma_fence_get_rcu_safe

[Christian König]

Am 11.09.2017 um 11:23 schrieb Chris Wilson:

Quoting Christian König (2017-09-11 10:06:50)

Am 11.09.2017 um 10:59 schrieb Chris Wilson:

Quoting Christian König (2017-09-11 09:50:40)

Sorry for the delayed response, but your mail somehow ended up in the
Spam folder.

Am 04.09.2017 um 15:40 schrieb Chris Wilson:

Quoting Christian König (2017-09-04 14:27:33)

From: Christian König 

The logic is buggy and unnecessary complex. When dma_fence_get_rcu() fails to
acquire a reference it doesn't necessary mean that there is no fence at all.

It usually mean that the fence was replaced by a new one and in this situation
we certainly want to have the new one as result and *NOT* NULL.

Which is not guaranteed by the code you wrote either.

The point of the comment is that the mb is only inside the successful
kref_atomic_inc_unless_zero, and that only after that mb do you know
whether or not you have the current fence.

You can argue that you want to replace the
if (!dma_fence_get_rcu())
return NULL
with
if (!dma_fence_get_rcu()
continue;
but it would be incorrect to say that by simply ignoring the
post-condition check that you do have the right fence.

You are completely missing the point here.

It is irrelevant if you have the current fence or not when you return.
You can only guarantee that it is the current fence when you take a look
and that is exactly what we want to avoid.

So the existing code is complete nonsense. Instead what we need to
guarantee is that we return *ANY* fence which we can grab a reference for.

Not quite. We can grab a reference on a fence that was already freed and
reused between the rcu_dereference() and dma_fence_get_rcu().

Reusing a memory structure before the RCU grace period is completed is
illegal, otherwise the whole RCU approach won't work.

RCU only protects that the pointer remains valid. If you use
SLAB_TYPESAFE_BY_RCU, it is possible to reuse the pointer within a grace
period. It does happen and that is the point the comment is trying to
make.


Yeah, but that is illegal with a fence objects.

When anybody allocates fences this way it breaks at least 
reservation_object_get_fences_rcu(), 
reservation_object_wait_timeout_rcu() and 
reservation_object_test_signaled_single().


Cause all of them rely on dma_fence_get() to return NULL when the fence 
isn't valid any more to restart the operation.


When dma_fence_get_rcu() returns a reallocated fence the operation 
wouldn't correctly restart and the end result most likely not be correct 
at all.


Using SLAB_TYPESAFE_BY_RCU is only valid if you can ensure that you have 
the right object using a second criteria and that is not the case with 
fences.


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

[Bug 102655] [CI][HSW] igt@gem_flink_race@flink_close - Failed assertion: obj_count == 0

[bugzilla-daemon]

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

Chris Wilson  changed:

   What|Removed |Added

 QA Contact|intel-gfx-bugs@lists.freede |
   |sktop.org   |
  Component|DRM/Intel   |IGT
   Assignee|intel-gfx-bugs@lists.freede |dri-devel@lists.freedesktop
   |sktop.org   |.org

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

[Bug 102655] [CI][HSW] igt@gem_flink_race@flink_close - Failed assertion: obj_count == 0

[bugzilla-daemon]

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

--- Comment #2 from Chris Wilson  ---
Given all the floating references held on objects, I'm not sure if we can do a
"stable_obj_count" without the loop and sleeping. I'm not sure of all the
places that we do have such objects in a timer, so getting the interval right
or adding a flush control is hard. E.g. one thing we are not flushing before
counting are the kms workqueues which hold a reference on the old object until
finished.

-- 
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 102369] [CI][SNB] Failed assertion: !kmsg_check("*ERROR*") in igt@tools_test@check_dmesg

[bugzilla-daemon]

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

Chris Wilson  changed:

   What|Removed |Added

 QA Contact|intel-gfx-bugs@lists.freede |
   |sktop.org   |
   Assignee|intel-gfx-bugs@lists.freede |dri-devel@lists.freedesktop
   |sktop.org   |.org
  Component|DRM/Intel   |IGT

-- 
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 102369] [CI][SNB] Failed assertion: !kmsg_check("*ERROR*") in igt@tools_test@check_dmesg

[bugzilla-daemon]

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

Martin Peres  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #3 from Martin Peres  ---
Thanks Chris!We wanted to run the others bug not inflight, once the new test
stops
killing the kernel, we should be ok to run all of gem_eio (or right now
if killing the kernel with an oops and

-- 
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 102616] [CI][SNB,HSW,APL,KBL] igt@gem_eio@in-flight - Failed assertion: __vgem_fence_signal(fd, fence) == 0

[bugzilla-daemon]

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

--- Comment #6 from Chris Wilson  ---
Related igt commit 4f082c35d2df545f81d202ae1a08463f6c123552 (upstream/master)
Author: Chris Wilson 
Date:   Fri Sep 8 13:48:05 2017 +0100

igt/gem_eio: Install an exithandler to unwedge the device after failure

Under normal conditions, we try to repair the damage we inflict to the
GPU, but if we fail we don't. Make sure that if the test does die, we do
try to restore normal operation by using an atexit handler.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102616
Signed-off-by: Chris Wilson 
Reviewed-by: Arkadiusz Hiler 

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

[PATCHv3 2/3] drm-kms-helpers.rst: document the DP CEC helpers

[Hans Verkuil]

From: Hans Verkuil 

Document the Display Port CEC helper functions.

Signed-off-by: Hans Verkuil 
---
 Documentation/gpu/drm-kms-helpers.rst | 9 +
 1 file changed, 9 insertions(+)

diff --git a/Documentation/gpu/drm-kms-helpers.rst 
b/Documentation/gpu/drm-kms-helpers.rst
index 7c5e2549a58a..0d2fa879edd1 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -175,6 +175,15 @@ Display Port Helper Functions Reference
 .. kernel-doc:: drivers/gpu/drm/drm_dp_helper.c
:export:
 
+Display Port CEC Helper Functions Reference
+===
+
+.. kernel-doc:: drivers/gpu/drm/drm_dp_cec.c
+   :doc: dp cec helpers
+
+.. kernel-doc:: drivers/gpu/drm/drm_dp_cec.c
+   :export:
+
 Display Port Dual Mode Adaptor Helper Functions Reference
 =
 
-- 
2.14.1

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

[PATCHv3 0/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support

[Hans Verkuil]

From: Hans Verkuil 

This patch series adds support for the DisplayPort CEC-Tunneling-over-AUX
feature. This patch series is based on the current pre-4.14-rc1 mainline
which has all the needed cec 4.14 patches merged.

This patch series has been tested with my NUC7i5BNK and a Samsung USB-C to 
HDMI adapter.

Please note this comment at the start of drm_dp_cec.c:

--
Unfortunately it turns out that we have a chicken-and-egg situation
here. Quite a few active (mini-)DP-to-HDMI or USB-C-to-HDMI adapters
have a converter chip that supports CEC-Tunneling-over-AUX (usually the
Parade PS176), but they do not wire up the CEC pin, thus making CEC
useless.

Sadly there is no way for this driver to know this. What happens is 
that a /dev/cecX device is created that is isolated and unable to see
any of the other CEC devices. Quite literally the CEC wire is cut
(or in this case, never connected in the first place).

I suspect that the reason so few adapters support this is that this
tunneling protocol was never supported by any OS. So there was no 
easy way of testing it, and no incentive to correctly wire up the
CEC pin.

Hopefully by creating this driver it will be easier for vendors to 
finally fix their adapters and test the CEC functionality.

I keep a list of known working adapters here:

https://hverkuil.home.xs4all.nl/cec-status.txt

Please mail me (hverk...@xs4all.nl) if you find an adapter that works
and is not yet listed there.
--

I really hope that this work will provide an incentive for vendors to
finally connect the CEC pin. It's a shame that there are so few adapters
that work (I found only two USB-C to HDMI adapters that work, and no
(mini-)DP to HDMI adapters at all).

Note that a colleague who actually knows his way around a soldering iron
modified an UpTab DisplayPort-to-HDMI adapter for me, hooking up the CEC
pin. And after that change it worked. I also received confirmation that
this really is a chicken-and-egg situation: it is because there is no CEC
support for this feature in any OS that they do not hook up the CEC pin.

So hopefully if this gets merged there will be an incentive for vendors
to make adapters where this actually works. It is a very nice feature
for HTPC boxes.

I've added Imre and Ville. It would be great if this can go in for 4.15.

Changes since v2:

- Use the new CEC_CAP_DEFAULTS define
- Replace 'if (!IS_ERR_OR_NULL(aux->cec_adap)) {' in 
drm_dp_cec_configure_adapter()
  by just 'if (aux->cec_adap) {'.

Changes since v1:

- Incorporated Sean's review comments in patch 1/3.

Regards,

Hans

Hans Verkuil (3):
  drm: add support for DisplayPort CEC-Tunneling-over-AUX
  drm-kms-helpers.rst: document the DP CEC helpers
  drm/i915: add DisplayPort CEC-Tunneling-over-AUX support

 Documentation/gpu/drm-kms-helpers.rst |   9 +
 drivers/gpu/drm/Kconfig   |  10 ++
 drivers/gpu/drm/Makefile  |   1 +
 drivers/gpu/drm/drm_dp_cec.c  | 301 ++
 drivers/gpu/drm/i915/intel_dp.c   |  18 +-
 include/drm/drm_dp_helper.h   |  24 +++
 6 files changed, 359 insertions(+), 4 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_dp_cec.c

-- 
2.14.1

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

[PATCHv3 1/3] drm: add support for DisplayPort CEC-Tunneling-over-AUX

[Hans Verkuil]

From: Hans Verkuil 

This adds support for the DisplayPort CEC-Tunneling-over-AUX
feature that is part of the DisplayPort 1.3 standard.

Unfortunately, not all DisplayPort/USB-C to HDMI adapters with a
chip that has this capability actually hook up the CEC pin, so
even though a CEC device is created, it may not actually work.

Signed-off-by: Hans Verkuil 
Tested-by: Carlos Santa 
---
 drivers/gpu/drm/Kconfig  |  10 ++
 drivers/gpu/drm/Makefile |   1 +
 drivers/gpu/drm/drm_dp_cec.c | 301 +++
 include/drm/drm_dp_helper.h  |  24 
 4 files changed, 336 insertions(+)
 create mode 100644 drivers/gpu/drm/drm_dp_cec.c

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 83cb2a88c204..1f2708df5c4e 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -120,6 +120,16 @@ config DRM_LOAD_EDID_FIRMWARE
  default case is N. Details and instructions how to build your own
  EDID data are given in Documentation/EDID/HOWTO.txt.
 
+config DRM_DP_CEC
+   bool "Enable DisplayPort CEC-Tunneling-over-AUX HDMI support"
+   select CEC_CORE
+   help
+ Choose this option if you want to enable HDMI CEC support for
+ DisplayPort/USB-C to HDMI adapters.
+
+ Note: not all adapters support this feature, and even for those
+ that do support this they often do not hook up the CEC pin.
+
 config DRM_TTM
tristate
depends on DRM && MMU
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 24a066e1841c..c6552c62049e 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -40,6 +40,7 @@ drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += 
drm_edid_load.o
 drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
 drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o
 drm_kms_helper-$(CONFIG_DRM_DP_AUX_CHARDEV) += drm_dp_aux_dev.o
+drm_kms_helper-$(CONFIG_DRM_DP_CEC) += drm_dp_cec.o
 
 obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o
 obj-$(CONFIG_DRM_DEBUG_MM_SELFTEST) += selftests/
diff --git a/drivers/gpu/drm/drm_dp_cec.c b/drivers/gpu/drm/drm_dp_cec.c
new file mode 100644
index ..b831bb72c932
--- /dev/null
+++ b/drivers/gpu/drm/drm_dp_cec.c
@@ -0,0 +1,301 @@
+/*
+ * DisplayPort CEC-Tunneling-over-AUX support
+ *
+ * Copyright 2017 Cisco Systems, Inc. and/or its affiliates. All rights 
reserved.
+ *
+ * This program is free software; you may redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * Unfortunately it turns out that we have a chicken-and-egg situation
+ * here. Quite a few active (mini-)DP-to-HDMI or USB-C-to-HDMI adapters
+ * have a converter chip that supports CEC-Tunneling-over-AUX (usually the
+ * Parade PS176), but they do not wire up the CEC pin, thus making CEC
+ * useless.
+ *
+ * Sadly there is no way for this driver to know this. What happens is
+ * that a /dev/cecX device is created that is isolated and unable to see
+ * any of the other CEC devices. Quite literally the CEC wire is cut
+ * (or in this case, never connected in the first place).
+ *
+ * I suspect that the reason so few adapters support this is that this
+ * tunneling protocol was never supported by any OS. So there was no
+ * easy way of testing it, and no incentive to correctly wire up the
+ * CEC pin.
+ *
+ * Hopefully by creating this driver it will be easier for vendors to
+ * finally fix their adapters and test the CEC functionality.
+ *
+ * I keep a list of known working adapters here:
+ *
+ * https://hverkuil.home.xs4all.nl/cec-status.txt
+ *
+ * Please mail me (hverk...@xs4all.nl) if you find an adapter that works
+ * and is not yet listed there.
+ */
+
+/**
+ * DOC: dp cec helpers
+ *
+ * These functions take care of supporting the CEC-Tunneling-over-AUX
+ * feature of DisplayPort-to-HDMI adapters.
+ */
+
+static int drm_dp_cec_adap_enable(struct cec_adapter *adap, bool enable)
+{
+   struct drm_dp_aux *aux = cec_get_drvdata(adap);
+   u32 val = enable ? DP_CEC_TUNNELING_ENABLE : 0;
+   ssize_t err = 0;
+
+   err = drm_dp_dpcd_writeb(aux, DP_CEC_TUNNELING_CONTROL, val);
+   return (enable && err < 0) ? err : 0;
+}
+
+static int drm_dp_cec_adap_log_addr(struct cec_adapter *adap, u8 addr)
+{
+   struct drm_dp_aux *aux = cec_get_drvdata(adap);

[PATCHv3 3/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support

[Hans Verkuil]

From: Hans Verkuil 

Implement support for this DisplayPort feature.

The cec device is created whenever it detects an adapter that
has this feature. It is only removed when a new adapter is connected
that does not support this. If a new adapter is connected that has
different properties than the previous one, then the old cec device is
unregistered and a new one is registered to replace the old one.

Signed-off-by: Hans Verkuil 
Tested-by: Carlos Santa 
---
 drivers/gpu/drm/i915/intel_dp.c | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 64fa774c855b..fdb853d2c458 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1449,6 +1450,7 @@ static void intel_aux_reg_init(struct intel_dp *intel_dp)
 static void
 intel_dp_aux_fini(struct intel_dp *intel_dp)
 {
+   cec_unregister_adapter(intel_dp->aux.cec_adap);
kfree(intel_dp->aux.name);
 }
 
@@ -4587,6 +4589,7 @@ intel_dp_set_edid(struct intel_dp *intel_dp)
intel_connector->detect_edid = edid;
 
intel_dp->has_audio = drm_detect_monitor_audio(edid);
+   cec_s_phys_addr_from_edid(intel_dp->aux.cec_adap, edid);
 }
 
 static void
@@ -4596,6 +4599,7 @@ intel_dp_unset_edid(struct intel_dp *intel_dp)
 
kfree(intel_connector->detect_edid);
intel_connector->detect_edid = NULL;
+   cec_phys_addr_invalidate(intel_dp->aux.cec_adap);
 
intel_dp->has_audio = false;
 }
@@ -4616,13 +4620,17 @@ intel_dp_long_pulse(struct intel_connector 
*intel_connector)
intel_display_power_get(to_i915(dev), intel_dp->aux_power_domain);
 
/* Can't disconnect eDP, but you can close the lid... */
-   if (is_edp(intel_dp))
+   if (is_edp(intel_dp)) {
status = edp_detect(intel_dp);
-   else if (intel_digital_port_connected(to_i915(dev),
- dp_to_dig_port(intel_dp)))
+   } else if (intel_digital_port_connected(to_i915(dev),
+   dp_to_dig_port(intel_dp))) {
status = intel_dp_detect_dpcd(intel_dp);
-   else
+   if (status == connector_status_connected)
+   drm_dp_cec_configure_adapter(&intel_dp->aux,
+intel_dp->aux.name, dev->dev);
+   } else {
status = connector_status_disconnected;
+   }
 
if (status == connector_status_disconnected) {
memset(&intel_dp->compliance, 0, sizeof(intel_dp->compliance));
@@ -5011,6 +5019,8 @@ intel_dp_hpd_pulse(struct intel_digital_port 
*intel_dig_port, bool long_hpd)
 
intel_display_power_get(dev_priv, intel_dp->aux_power_domain);
 
+   drm_dp_cec_irq(&intel_dp->aux);
+
if (intel_dp->is_mst) {
if (intel_dp_check_mst_status(intel_dp) == -EINVAL) {
/*
-- 
2.14.1

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

Re: [PATCH v3 1/2] drm/bridge: add Silicon Image SiI9234 driver

[Maciej Purski]

Hi Krzysztof,
thank you for your comments.

On 08.09.2017 at 19:05, Krzysztof Kozlowski wrote:


On Tue, Sep 05, 2017 at 04:01:38PM +0200, Maciej Purski wrote:

SiI9234 transmitter converts eTMDS/HDMI signal to MHL 1.0.
It is controlled via I2C bus. Its interaction with other
devices in video pipeline is performed mainly on HW level.
The only interaction it does on device driver level is
filtering-out unsupported video modes, it exposes drm_bridge
interface to perform this operation.

This patch is based on the code refactored by Tomasz Stanislawski
, which was initially developed by:
Adam Hampson 
Erik Gilling 
Shankar Bandal 
Dharam Kumar 

Signed-off-by: Maciej Purski 
---
  .../devicetree/bindings/display/bridge/sii9234.txt |  34 +
  drivers/gpu/drm/bridge/Kconfig |   8 +
  drivers/gpu/drm/bridge/Makefile|   1 +
  drivers/gpu/drm/bridge/sii9234.c   | 993 +
  4 files changed, 1036 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/display/bridge/sii9234.txt
  create mode 100644 drivers/gpu/drm/bridge/sii9234.c

diff --git a/Documentation/devicetree/bindings/display/bridge/sii9234.txt 
b/Documentation/devicetree/bindings/display/bridge/sii9234.txt
new file mode 100644
index 000..3ce7413
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/sii9234.txt
@@ -0,0 +1,34 @@
+Silicon Image SiI9234 HDMI/MHL bridge bindings
+
+Required properties:
+   - compatible : "sil,sii9234".
+   - reg : I2C address for TPI interface, use 0x39
+   - avcc33-supply : MHL/USB Switch Supply Voltage (3.3V)
+   - iovcc18-supply : I/O Supply Voltage (1.8V)
+   - avcc12-supply : TMDS Analog Supply Voltage (1.2V)
+   - cvcc12-supply : Digital Core Supply Voltage (1.2V)
+   - interrupts, interrupt-parent: interrupt specifier of INT pin
+   - reset-gpios: gpio specifier of RESET pin (active low)
+   - video interfaces: Device node can contain video interface port
+   node for HDMI encoder according to [1].
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+   sii9234@39 {
+   compatible = "sil,sii9234";
+   reg = <0x39>;
+   avcc33-supply = <&vcc33mhl>;
+   iovcc18-supply = <&vcc18mhl>;
+   avcc12-supply = <&vsil12>;
+   cvcc12-supply = <&vsil12>;
+   reset-gpios = <&gpf3 4 GPIO_ACTIVE_LOW>;
+   interrupt-parent = <&gpf3>;
+   interrupts = <5 IRQ_TYPE_LEVEL_HIGH>;
+
+   port {
+   mhl_to_hdmi: endpoint {
+   remote-endpoint = <&hdmi_to_mhl>;
+   };
+   };
+   };
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index adf9ae0..9dba16fd 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -84,6 +84,14 @@ config DRM_SII902X
---help---
  Silicon Image sii902x bridge chip driver.
  
+config DRM_SII9234

+   tristate "Silicon Image SII9234 HDMI/MHL bridge"
+   depends on OF
+   ---help---
+ Say Y here if you want support for the MHL interface.
+ It is an I2C driver, that detects connection of MHL bridge
+ and starts encapsulation of HDMI signal.
+
  config DRM_TOSHIBA_TC358767
tristate "Toshiba TC358767 eDP bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index defcf1e..e3d5eb0 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
  obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
  obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
  obj-$(CONFIG_DRM_SII902X) += sii902x.o
+obj-$(CONFIG_DRM_SII9234) += sii9234.o
  obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
  obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
  obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
diff --git a/drivers/gpu/drm/bridge/sii9234.c b/drivers/gpu/drm/bridge/sii9234.c
new file mode 100644
index 000..b70d69a
--- /dev/null
+++ b/drivers/gpu/drm/bridge/sii9234.c
@@ -0,0 +1,993 @@
+/*
+ * Copyright (C) 2017 Samsung Electronics
+ *
+ * Authors:
+ *Tomasz Stanislawski 
+ *Maciej Purski 
+ *
+ * Based on sii9234 driver created by:
+ *Adam Hampson 
+ *Erik Gilling 
+ *Shankar Bandal 
+ *Dharam Kumar 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for m

Re: [PATCH] drm/i915: Fix an error handling in 'intel_framebuffer_init()'

[Jani Nikula]

On Sun, 10 Sep 2017, Christophe JAILLET  wrote:
> We should go through the error handling path to decrease the
> 'framebuffer_references' as done everywhere else in this function.
>
> Fixes: 2e2adb05736c ("drm/i915: Add render decompression support")
> Signed-off-by: Christophe JAILLET 

Pushed to drm-intel-next-queued, thanks for the patch.

For future reference, the intel-gfx list will suffice.


BR,
Jani.


> ---
>  drivers/gpu/drm/i915/intel_display.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 7cd392f2cd94..478fa449003f 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -14077,7 +14077,7 @@ static int intel_framebuffer_init(struct 
> intel_framebuffer *intel_fb,
>  
>   if (mode_cmd->handles[i] != mode_cmd->handles[0]) {
>   DRM_DEBUG_KMS("bad plane %d handle\n", i);
> - return -EINVAL;
> + goto err;
>   }
>  
>   stride_alignment = intel_fb_stride_alignment(fb, i);

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

[PATCHv4 0/4] tegra-cec: add Tegra HDMI CEC support

[Hans Verkuil]

From: Hans Verkuil 

This patch series adds support for the Tegra CEC functionality.

This v4 has been rebased to the latest 4.14 pre-rc1 mainline.

Please review! Other than for the bindings that are now Acked I have not
received any feedback.

The first patch documents the CEC bindings, the second adds support
for this to tegra124.dtsi and enables it for the Jetson TK1.

The third patch adds the CEC driver itself and the final patch adds
the cec notifier support to the drm/tegra driver in order to notify
the CEC driver whenever the physical address changes.

I expect that the dts changes apply as well to the Tegra X1/X2 and possibly
other Tegra SoCs, but I can only test this with my Jetson TK1 board.

The dt-bindings and the tegra-cec driver would go in through the media
subsystem, the drm/tegra part through the drm subsystem and the dts
changes through (I guess) the linux-tegra developers. Luckily they are
all independent of one another.

To test this you need the CEC utilities from git://linuxtv.org/v4l-utils.git.

To build this:

git clone git://linuxtv.org/v4l-utils.git
cd v4l-utils
./bootstrap.sh; ./configure
make
sudo make install # optional, you really only need utils/cec*

To test:

cec-ctl --playback # configure as playback device
cec-ctl -S # detect all connected CEC devices

See here for the public CEC API:

https://hverkuil.home.xs4all.nl/spec/uapi/cec/cec-api.html

Regards,

Hans

Changes since v3:

- Use the new CEC_CAP_DEFAULTS define
- Use IS_ERR(cec->adap) instead of IS_ERR_OR_NULL(cec->adap)
  (cec_allocate_adapter never returns a NULL pointer)
- Drop the device_init_wakeup: wakeup is not (yet) supported by
  the CEC framework and I have never tested it.

Hans Verkuil (4):
  dt-bindings: document the tegra CEC bindings
  ARM: tegra: add CEC support to tegra124.dtsi
  tegra-cec: add Tegra HDMI CEC driver
  drm/tegra: add cec-notifier support

 .../devicetree/bindings/media/tegra-cec.txt|  27 ++
 MAINTAINERS|   8 +
 arch/arm/boot/dts/tegra124-jetson-tk1.dts  |   4 +
 arch/arm/boot/dts/tegra124.dtsi|  12 +-
 drivers/gpu/drm/tegra/Kconfig  |   1 +
 drivers/gpu/drm/tegra/drm.h|   3 +
 drivers/gpu/drm/tegra/hdmi.c   |   9 +
 drivers/gpu/drm/tegra/output.c |   6 +
 drivers/media/platform/Kconfig |  11 +
 drivers/media/platform/Makefile|   2 +
 drivers/media/platform/tegra-cec/Makefile  |   1 +
 drivers/media/platform/tegra-cec/tegra_cec.c   | 501 +
 drivers/media/platform/tegra-cec/tegra_cec.h   | 127 ++
 13 files changed, 711 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/media/tegra-cec.txt
 create mode 100644 drivers/media/platform/tegra-cec/Makefile
 create mode 100644 drivers/media/platform/tegra-cec/tegra_cec.c
 create mode 100644 drivers/media/platform/tegra-cec/tegra_cec.h

-- 
2.14.1

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

[PATCHv4 4/4] drm/tegra: add cec-notifier support

[Hans Verkuil]

From: Hans Verkuil 

In order to support CEC the HDMI driver has to inform the CEC driver
whenever the physical address changes. So when the EDID is read the
CEC driver has to be informed and whenever the hotplug detect goes
away.

This is done through the cec-notifier framework.

The link between the HDMI driver and the CEC driver is done through
the hdmi_phandle in the tegra-cec node in the device tree.

Signed-off-by: Hans Verkuil 
---
 drivers/gpu/drm/tegra/Kconfig  | 1 +
 drivers/gpu/drm/tegra/drm.h| 3 +++
 drivers/gpu/drm/tegra/hdmi.c   | 9 +
 drivers/gpu/drm/tegra/output.c | 6 ++
 4 files changed, 19 insertions(+)

diff --git a/drivers/gpu/drm/tegra/Kconfig b/drivers/gpu/drm/tegra/Kconfig
index 2db29d67193d..c882918c2024 100644
--- a/drivers/gpu/drm/tegra/Kconfig
+++ b/drivers/gpu/drm/tegra/Kconfig
@@ -8,6 +8,7 @@ config DRM_TEGRA
select DRM_PANEL
select TEGRA_HOST1X
select IOMMU_IOVA if IOMMU_SUPPORT
+   select CEC_CORE if CEC_NOTIFIER
help
  Choose this option if you have an NVIDIA Tegra SoC.
 
diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
index 6d6da01282f3..c0a18b60caf1 100644
--- a/drivers/gpu/drm/tegra/drm.h
+++ b/drivers/gpu/drm/tegra/drm.h
@@ -212,6 +212,8 @@ int tegra_dc_state_setup_clock(struct tegra_dc *dc,
   struct clk *clk, unsigned long pclk,
   unsigned int div);
 
+struct cec_notifier;
+
 struct tegra_output {
struct device_node *of_node;
struct device *dev;
@@ -219,6 +221,7 @@ struct tegra_output {
struct drm_panel *panel;
struct i2c_adapter *ddc;
const struct edid *edid;
+   struct cec_notifier *notifier;
unsigned int hpd_irq;
int hpd_gpio;
enum of_gpio_flags hpd_gpio_flags;
diff --git a/drivers/gpu/drm/tegra/hdmi.c b/drivers/gpu/drm/tegra/hdmi.c
index cda0491ed6bf..fbf14e1efd0e 100644
--- a/drivers/gpu/drm/tegra/hdmi.c
+++ b/drivers/gpu/drm/tegra/hdmi.c
@@ -21,6 +21,8 @@
 
 #include 
 
+#include 
+
 #include "hdmi.h"
 #include "drm.h"
 #include "dc.h"
@@ -1720,6 +1722,10 @@ static int tegra_hdmi_probe(struct platform_device *pdev)
return PTR_ERR(hdmi->vdd);
}
 
+   hdmi->output.notifier = cec_notifier_get(&pdev->dev);
+   if (hdmi->output.notifier == NULL)
+   return -ENOMEM;
+
hdmi->output.dev = &pdev->dev;
 
err = tegra_output_probe(&hdmi->output);
@@ -1778,6 +1784,9 @@ static int tegra_hdmi_remove(struct platform_device *pdev)
 
tegra_output_remove(&hdmi->output);
 
+   if (hdmi->output.notifier)
+   cec_notifier_put(hdmi->output.notifier);
+
return 0;
 }
 
diff --git a/drivers/gpu/drm/tegra/output.c b/drivers/gpu/drm/tegra/output.c
index 595d1ec3e02e..57c052521a44 100644
--- a/drivers/gpu/drm/tegra/output.c
+++ b/drivers/gpu/drm/tegra/output.c
@@ -11,6 +11,8 @@
 #include 
 #include "drm.h"
 
+#include 
+
 int tegra_output_connector_get_modes(struct drm_connector *connector)
 {
struct tegra_output *output = connector_to_output(connector);
@@ -33,6 +35,7 @@ int tegra_output_connector_get_modes(struct drm_connector 
*connector)
edid = drm_get_edid(connector, output->ddc);
 
drm_mode_connector_update_edid_property(connector, edid);
+   cec_notifier_set_phys_addr_from_edid(output->notifier, edid);
 
if (edid) {
err = drm_add_edid_modes(connector, edid);
@@ -68,6 +71,9 @@ tegra_output_connector_detect(struct drm_connector 
*connector, bool force)
status = connector_status_connected;
}
 
+   if (status != connector_status_connected)
+   cec_notifier_phys_addr_invalidate(output->notifier);
+
return status;
 }
 
-- 
2.14.1

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

[PATCHv4 1/4] dt-bindings: document the tegra CEC bindings

[Hans Verkuil]

From: Hans Verkuil 

This documents the binding for the Tegra CEC module.

Signed-off-by: Hans Verkuil 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/media/tegra-cec.txt| 27 ++
 1 file changed, 27 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/tegra-cec.txt

diff --git a/Documentation/devicetree/bindings/media/tegra-cec.txt 
b/Documentation/devicetree/bindings/media/tegra-cec.txt
new file mode 100644
index ..c503f06f3b84
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/tegra-cec.txt
@@ -0,0 +1,27 @@
+* Tegra HDMI CEC hardware
+
+The HDMI CEC module is present in Tegra SoCs and its purpose is to
+handle communication between HDMI connected devices over the CEC bus.
+
+Required properties:
+  - compatible : value should be one of the following:
+   "nvidia,tegra114-cec"
+   "nvidia,tegra124-cec"
+   "nvidia,tegra210-cec"
+  - reg : Physical base address of the IP registers and length of memory
+ mapped region.
+  - interrupts : HDMI CEC interrupt number to the CPU.
+  - clocks : from common clock binding: handle to HDMI CEC clock.
+  - clock-names : from common clock binding: must contain "cec",
+ corresponding to the entry in the clocks property.
+  - hdmi-phandle : phandle to the HDMI controller, see also cec.txt.
+
+Example:
+
+cec@70015000 {
+   compatible = "nvidia,tegra124-cec";
+   reg = <0x0 0x70015000 0x0 0x1000>;
+   interrupts = ;
+   clocks = <&tegra_car TEGRA124_CLK_CEC>;
+   clock-names = "cec";
+};
-- 
2.14.1

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

[PATCHv4 2/4] ARM: tegra: add CEC support to tegra124.dtsi

[Hans Verkuil]

From: Hans Verkuil 

Add support for the Tegra CEC IP to tegra124.dtsi and enable it on the
Jetson TK1.

Signed-off-by: Hans Verkuil 
---
 arch/arm/boot/dts/tegra124-jetson-tk1.dts |  4 
 arch/arm/boot/dts/tegra124.dtsi   | 12 +++-
 2 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/tegra124-jetson-tk1.dts 
b/arch/arm/boot/dts/tegra124-jetson-tk1.dts
index 7bacb2954f58..7f56de6890c3 100644
--- a/arch/arm/boot/dts/tegra124-jetson-tk1.dts
+++ b/arch/arm/boot/dts/tegra124-jetson-tk1.dts
@@ -67,6 +67,10 @@
};
};
 
+   cec@70015000 {
+   status = "okay";
+   };
+
gpu@0,5700 {
/*
 * Node left disabled on purpose - the bootloader will enable
diff --git a/arch/arm/boot/dts/tegra124.dtsi b/arch/arm/boot/dts/tegra124.dtsi
index 1b10b14a6abd..1a21e527fb6e 100644
--- a/arch/arm/boot/dts/tegra124.dtsi
+++ b/arch/arm/boot/dts/tegra124.dtsi
@@ -123,7 +123,7 @@
nvidia,head = <1>;
};
 
-   hdmi@5428 {
+   hdmi: hdmi@5428 {
compatible = "nvidia,tegra124-hdmi";
reg = <0x0 0x5428 0x0 0x0004>;
interrupts = ;
@@ -851,6 +851,16 @@
status = "disabled";
};
 
+   cec@70015000 {
+   compatible = "nvidia,tegra124-cec";
+   reg = <0x0 0x70015000 0x0 0x1000>;
+   interrupts = ;
+   clocks = <&tegra_car TEGRA124_CLK_CEC>;
+   clock-names = "cec";
+   hdmi-phandle = <&hdmi>;
+   status = "disabled";
+   };
+
soctherm: thermal-sensor@700e2000 {
compatible = "nvidia,tegra124-soctherm";
reg = <0x0 0x700e2000 0x0 0x600 /* SOC_THERM reg_base */
-- 
2.14.1

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

[PATCHv4 3/4] tegra-cec: add Tegra HDMI CEC driver

[Hans Verkuil]

From: Hans Verkuil 

This driver adds support for the Tegra CEC IP. It is based on the
NVIDIA drivers/misc/tegra-cec driver in their 3.10 kernel.

This has been converted to the CEC framework and cleaned up.

Tested with my Jetson TK1 board. It has also been tested with the
Tegra X1 in an embedded product.

Note of warning for the Tegra X2: this SoC supports two HDMI outputs,
but only one CEC adapter and the CEC bus is shared between the
two outputs. This is a design mistake and the CEC adapter can
control only one HDMI output. Never hook up both HDMI outputs
to the CEC bus in a hardware design: this is illegal as per the
CEC specification.

The CEC bus can be shared between multiple inputs and zero or one
outputs, but not between multiple outputs.

Signed-off-by: Hans Verkuil 
---
 MAINTAINERS  |   8 +
 drivers/media/platform/Kconfig   |  11 +
 drivers/media/platform/Makefile  |   2 +
 drivers/media/platform/tegra-cec/Makefile|   1 +
 drivers/media/platform/tegra-cec/tegra_cec.c | 501 +++
 drivers/media/platform/tegra-cec/tegra_cec.h | 127 +++
 6 files changed, 650 insertions(+)
 create mode 100644 drivers/media/platform/tegra-cec/Makefile
 create mode 100644 drivers/media/platform/tegra-cec/tegra_cec.c
 create mode 100644 drivers/media/platform/tegra-cec/tegra_cec.h

diff --git a/MAINTAINERS b/MAINTAINERS
index eb930ebecfcb..dd40c1f335a8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1923,6 +1923,14 @@ M:   Lennert Buytenhek 
 L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
 S: Maintained
 
+ARM/TEGRA HDMI CEC SUBSYSTEM SUPPORT
+M: Hans Verkuil 
+L: linux-te...@vger.kernel.org
+L: linux-me...@vger.kernel.org
+S: Maintained
+F: drivers/media/platform/tegra-cec/
+F: Documentation/devicetree/bindings/media/tegra-cec.txt
+
 ARM/TETON BGA MACHINE SUPPORT
 M: "Mark F. Brown" 
 L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 7e7cc49b8674..ec218fcf3886 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -589,6 +589,17 @@ config VIDEO_STM32_HDMI_CEC
  CEC bus is present in the HDMI connector and enables communication
  between compatible devices.
 
+config VIDEO_TEGRA_HDMI_CEC
+   tristate "Tegra HDMI CEC driver"
+   depends on ARCH_TEGRA || COMPILE_TEST
+   select CEC_CORE
+   select CEC_NOTIFIER
+   ---help---
+ This is a driver for the Tegra HDMI CEC interface. It uses the
+ generic CEC framework interface.
+ The CEC bus is present in the HDMI connector and enables communication
+ between compatible devices.
+
 endif #CEC_PLATFORM_DRIVERS
 
 menuconfig SDR_PLATFORM_DRIVERS
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index c1ef946bf032..e31faaa852f3 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -46,6 +46,8 @@ obj-$(CONFIG_VIDEO_STI_HDMI_CEC)  += sti/cec/
 
 obj-$(CONFIG_VIDEO_STI_DELTA)  += sti/delta/
 
+obj-$(CONFIG_VIDEO_TEGRA_HDMI_CEC) += tegra-cec/
+
 obj-y  += stm32/
 
 obj-y   += blackfin/
diff --git a/drivers/media/platform/tegra-cec/Makefile 
b/drivers/media/platform/tegra-cec/Makefile
new file mode 100644
index ..f3d81127589f
--- /dev/null
+++ b/drivers/media/platform/tegra-cec/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_VIDEO_TEGRA_HDMI_CEC) += tegra_cec.o
diff --git a/drivers/media/platform/tegra-cec/tegra_cec.c 
b/drivers/media/platform/tegra-cec/tegra_cec.c
new file mode 100644
index ..b53743f555e8
--- /dev/null
+++ b/drivers/media/platform/tegra-cec/tegra_cec.c
@@ -0,0 +1,501 @@
+/*
+ * Tegra CEC implementation
+ *
+ * The original 3.10 CEC driver using a custom API:
+ *
+ * Copyright (c) 2012-2015, NVIDIA CORPORATION.  All rights reserved.
+ *
+ * Conversion to the CEC framework and to the mainline kernel:
+ *
+ * Copyright 2016-2017 Cisco Systems, Inc. and/or its affiliates. All rights 
reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+

Re: [PATCH] dma-fence: fix dma_fence_get_rcu_safe

[Christian König]

Am 11.09.2017 um 12:01 schrieb Chris Wilson:

[SNIP]

Yeah, but that is illegal with a fence objects.

When anybody allocates fences this way it breaks at least
reservation_object_get_fences_rcu(),
reservation_object_wait_timeout_rcu() and
reservation_object_test_signaled_single().

Many, many months ago I sent patches to fix them all.


Found those after a bit a searching. Yeah, those patches where proposed 
more than a year ago, but never pushed upstream.


Not sure if we really should go this way. dma_fence objects are shared 
between drivers and since we can't judge if it's the correct fence based 
on a criteria in the object (only the read counter which is outside) all 
drivers need to be correct for this.


I would rather go the way and change dma_fence_release() to wrap 
fence->ops->release into call_rcu() to keep the whole RCU handling 
outside of the individual drivers.


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

Re: [PATCH 1/2] dma-buf: make reservation_object_copy_fences rcu save

[Christian König]

Am 10.09.2017 um 09:30 schrieb Maarten Lankhorst:

Op 04-09-17 om 21:02 schreef Christian König:

From: Christian König 

Stop requiring that the src reservation object is locked for this operation.

Signed-off-by: Christian König 
---
  drivers/dma-buf/reservation.c | 56 ---
  1 file changed, 42 insertions(+), 14 deletions(-)

diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index dec3a81..b44d9d7 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -266,8 +266,7 @@ EXPORT_SYMBOL(reservation_object_add_excl_fence);
  * @dst: the destination reservation object
  * @src: the source reservation object
  *
-* Copy all fences from src to dst. Both src->lock as well as dst-lock must be
-* held.
+* Copy all fences from src to dst. dst-lock must be held.
  */
  int reservation_object_copy_fences(struct reservation_object *dst,
   struct reservation_object *src)

Could this be implemented using reservation_object_get_fences_rcu? You're 
essentially duplicating its functionality.


I've considered this as well, but reservation_object_get_fences_rcu() 
returns an array and here we need an reservation_object_list.


Regards,
Christian.



Cheers,
Maarten
___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx



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

Re: [PATCH V3 00/23] drm/etnaviv: support performance counters

[Lucas Stach]

Hi Christian,

Am Donnerstag, den 31.08.2017, 18:08 +0200 schrieb Christian Gmeiner:
> 2017-08-25 11:06 GMT+02:00 Christian Gmeiner :

[...]

> It looks like I have screwed up patches 03 and 04 - used v1 ones
> instead of v2 :/
> I will send out a tested v4 series on Tuesday next week as I am
> currently in Sweden
> and my device @home did not survived a reboot.
> 
> Sorry if I wasted somebody's time.

Any news about this? Do you have a fully working stack available
somewhere, so I can test/validate the kernel changes?

Regards,
Lucas

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

[Bug 196771] [AMDGPU] Scrambled video output during boot on WQHD monitor

[bugzilla-daemon]

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

--- Comment #5 from Rokas Kupstys (rokups+kernel-b...@zoho.com) ---
I swapped cable to displayport and now it is working properly. Must be issue
with HDMI then.

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

Re: [PATCH v2] drm/dp/mst: Sideband message transaction to power up/down nodes

[Ville Syrjälä]

On Wed, Sep 06, 2017 at 05:14:58PM -0700, Dhinakaran Pandiyan wrote:
> The POWER_DOWN_PHY and POWER_UP_PHY sideband message transactions allow
> the source to reqest any node in a mst path or a whole path to be
> powered down or up. This allows drivers to target a specific sink in the
> MST topology, an improvement over just power managing the imediate
> downstream device. Secondly, since the request-reply protocol waits for an
> ACK, we can be sure that a downstream sink has enough time to respond to a
> power up/down request.

I was a bit worried how this handles multiple streams going through
the same MST device, but looks like the spec has accounted for this
by having the device skip the D3 if any active streams are present.

I guess that also means we have to do this after we've turned off the
stream, assuming we want things actually reach D3. Looks like that does
match our current order of things.

Pushed this one to drm-misc-next. Thanks for the patch and review.

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

Re: [PATCH v3 1/2] drm/bridge: add Silicon Image SiI9234 driver

[Marek Szyprowski]

Hi Krzysztof,

On 2017-09-11 15:18, Krzysztof Kozlowski wrote:

On Mon, Sep 11, 2017 at 1:42 PM, Maciej Purski  wrote:

+   ctx->client[I2C_MHL] = client;
+
+   ctx->client[I2C_TPI] = i2c_new_dummy(adapter, I2C_TPI_ADDR);
+   if (!ctx->client[I2C_TPI]) {
+   dev_err(ctx->dev, "failed to create TPI client\n");
+   return -ENODEV;
+   }
+
+   ctx->client[I2C_HDMI] = i2c_new_dummy(adapter, I2C_HDMI_ADDR);
+   if (!ctx->client[I2C_HDMI]) {
+   dev_err(ctx->dev, "failed to create HDMI RX client\n");
+   goto fail_tpi;
+   }
+
+   ctx->client[I2C_CBUS] = i2c_new_dummy(adapter, I2C_CBUS_ADDR);
+   if (!ctx->client[I2C_CBUS]) {
+   dev_err(ctx->dev, "failed to create CBUS client\n");
+   goto fail_hdmi;
+   }

You are using i2c_smbus_* calls. Why not converting to regmap_i2c? It is
preferred interface.


According to my search, there are only 5 drivers, which use regmap_i2c and
none of them in drm. If you think that it is really needed, could you please
explain
why?

There are slightly more than five drivers:

$ git grep regmap_init_i2c | wc -l
352

... and even more using regmap interface in generic (not i2c).

I think this is really wanted because for free you get:
1. locking,
2. proper locking - with lockdep and nested mutexes :),
3. caching of accesses,
4. handling of endianness,
5. optionally a trivial way of handling interrupts (regmap_irq_chip),

Also this brings unified interface for most of the drivers regardless
of protocol used beneath (I2C, SPI and even MMIO but for simple cases
MMIO might not have much sense). This last argument actually brings
the most benefit for me because it abstracts driver from trivial I2C
implementation and it could allow even easy code-reuse for e.g. SPI
version.


Regmap make sense for multi-function chips, which require more than one
client driver (so proper locking is important). It also makes sense if
the chip is produced in more than one flavor (like i2c, spi, MMIO, etc).

None of the above takes place in this case... So in case of this driver
using regmap is IMHO an over-engineering.

> ...

Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland

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

Re: [PATCH 00/10] drm/exynos: TV path improvements

[Tobias Jakobi]

Hello Andrzej,

just did a quick test and looks good so far. One thing I noticed is that
compared to Daniel's approach you just manipulate HDMI_TG_HACT_{ST,SZ}_L,
instead of HDMI_TG_VACT_SZ_L + HDMI_TG_HACT_{ST,SZ}_L. I just wanted to make
sure that on the HDMI level, this does the same thing?

I'll try to do a proper review tomorrow.

I also noticed that I have another patch by Daniel in my tree, which, together
with the quirk, enables 1366x768@60Hz. Going to send it shortly, since it could
probably go along with this series.

With best wishes,
Tobias



Andrzej Hajda wrote:
> Hi all,
> 
> This patchset does two main things:
> - removes mode limitation for Exynos542x chips, multiple modes were filtered
>   out due to lack of HW version checking code,
> - enables two modes on older chips, thanks to quirk found by Daniel Drake,
>   and published by Tobias Jakobi [1][2].
> Beside this it consolidates the code and performs multiple cleanups.
> 
> [1]: http://www.spinics.net/lists/linux-samsung-soc/msg24617.html
> [2]: https://www.spinics.net/lists/dri-devel/msg150906.html
> 
> Regards
> Andrzej
> 
> 
> Andrzej Hajda (10):
>   drm/exynos/mixer: abstract out output mode setup code
>   drm/exynos/mixer: move mode commit to enable callback
>   drm/exynos/mixer: move resolution configuration to single function
>   drm/exynos/mixer: fix mode validation code
>   drm/exynos/mixer: remove mixer_resources sub-structure
>   drm/exynos/hdmi: remove redundant mode field
>   drm/exynos: add mode_fixup callback to exynos_drm_crtc_ops
>   drm/exynos/mixer: pass actual mode on MIXER to encoder
>   drm/exynos/hdmi: quirk for support mode timings conversion
>   drm/exynos/mixer: enable support for 1024x768 and 1280x1024 modes
> 
>  drivers/gpu/drm/exynos/exynos_drm_crtc.c |  15 +
>  drivers/gpu/drm/exynos/exynos_drm_drv.h  |   3 +
>  drivers/gpu/drm/exynos/exynos_hdmi.c |  49 ++--
>  drivers/gpu/drm/exynos/exynos_mixer.c| 452 
> +++
>  4 files changed, 265 insertions(+), 254 deletions(-)
> 

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

Re: [PATCH 1/2] dma-buf: make reservation_object_copy_fences rcu save

[Maarten Lankhorst]

Op 11-09-17 om 14:53 schreef Christian König:
> Am 10.09.2017 um 09:30 schrieb Maarten Lankhorst:
>> Op 04-09-17 om 21:02 schreef Christian König:
>>> From: Christian König 
>>>
>>> Stop requiring that the src reservation object is locked for this operation.
>>>
>>> Signed-off-by: Christian König 
>>> ---
>>>   drivers/dma-buf/reservation.c | 56 
>>> ---
>>>   1 file changed, 42 insertions(+), 14 deletions(-)
>>>
>>> diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
>>> index dec3a81..b44d9d7 100644
>>> --- a/drivers/dma-buf/reservation.c
>>> +++ b/drivers/dma-buf/reservation.c
>>> @@ -266,8 +266,7 @@ EXPORT_SYMBOL(reservation_object_add_excl_fence);
>>>   * @dst: the destination reservation object
>>>   * @src: the source reservation object
>>>   *
>>> -* Copy all fences from src to dst. Both src->lock as well as dst-lock must 
>>> be
>>> -* held.
>>> +* Copy all fences from src to dst. dst-lock must be held.
>>>   */
>>>   int reservation_object_copy_fences(struct reservation_object *dst,
>>>  struct reservation_object *src)
>> Could this be implemented using reservation_object_get_fences_rcu? You're 
>> essentially duplicating its functionality.
>
> I've considered this as well, but reservation_object_get_fences_rcu() returns 
> an array and here we need an reservation_object_list. 

Doesn't seem too hard, below is the result from fiddling with the allocation 
function..
reservation_object_list is just a list of fences with some junk in front.

Here you go, but only tested with the compiler. O:)
-8<-
 drivers/dma-buf/reservation.c | 192 
+
 1 file changed, 109 insertions(+), 83 deletions(-)

diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index dec3a815455d..72ee91f34132 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -261,87 +261,43 @@ void reservation_object_add_excl_fence(struct 
reservation_object *obj,
 }
 EXPORT_SYMBOL(reservation_object_add_excl_fence);
 
-/**
-* reservation_object_copy_fences - Copy all fences from src to dst.
-* @dst: the destination reservation object
-* @src: the source reservation object
-*
-* Copy all fences from src to dst. Both src->lock as well as dst-lock must be
-* held.
-*/
-int reservation_object_copy_fences(struct reservation_object *dst,
-  struct reservation_object *src)
+static bool realloc_shared(void **ptr, struct dma_fence ***pshared, unsigned 
shared_max, bool alloc_list, bool unlocked)
 {
-   struct reservation_object_list *src_list, *dst_list;
-   struct dma_fence *old, *new;
-   size_t size;
-   unsigned i;
-
-   src_list = reservation_object_get_list(src);
-
-   if (src_list) {
-   size = offsetof(typeof(*src_list),
-   shared[src_list->shared_count]);
-   dst_list = kmalloc(size, GFP_KERNEL);
-   if (!dst_list)
-   return -ENOMEM;
-
-   dst_list->shared_count = src_list->shared_count;
-   dst_list->shared_max = src_list->shared_count;
-   for (i = 0; i < src_list->shared_count; ++i)
-   dst_list->shared[i] =
-   dma_fence_get(src_list->shared[i]);
-   } else {
-   dst_list = NULL;
-   }
-
-   kfree(dst->staged);
-   dst->staged = NULL;
+   size_t sz;
+   void *newptr;
 
-   src_list = reservation_object_get_list(dst);
+   if (alloc_list)
+   sz = offsetof(struct reservation_object_list, 
shared[shared_max]);
+   else
+   sz = shared_max * sizeof(struct dma_fence *);
 
-   old = reservation_object_get_excl(dst);
-   new = reservation_object_get_excl(src);
+   newptr = krealloc(*ptr, sz, unlocked ? GFP_KERNEL : GFP_NOWAIT | 
__GFP_NOWARN);
+   if (!newptr)
+   return false;
 
-   dma_fence_get(new);
+   *ptr = newptr;
+   if (alloc_list) {
+   struct reservation_object_list *fobj = newptr;
 
-   preempt_disable();
-   write_seqcount_begin(&dst->seq);
-   /* write_seqcount_begin provides the necessary memory barrier */
-   RCU_INIT_POINTER(dst->fence_excl, new);
-   RCU_INIT_POINTER(dst->fence, dst_list);
-   write_seqcount_end(&dst->seq);
-   preempt_enable();
-
-   if (src_list)
-   kfree_rcu(src_list, rcu);
-   dma_fence_put(old);
+   fobj->shared_max = shared_max;
+   *pshared = fobj->shared;
+   } else
+   *pshared = newptr;
 
-   return 0;
+   return true;
 }
-EXPORT_SYMBOL(reservation_object_copy_fences);
 
-/**
- * reservation_object_get_fences_rcu - Get an object's shared and exclusive
- * fences without update side 

[PATCH] drm/exynos/hdmi: add 85.5MHz pixel clock for v14 HDMI PHY

[Tobias Jakobi]

From: Daniel Drake 

Configuration details from Samsung. This enables 1366x768@60Hz,
which also needs the 257px timing hack to work around a mixer
limitation.

Signed-off-by: Daniel Drake 
Signed-off-by: Tobias Jakobi 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c  | 9 +
 drivers/gpu/drm/exynos/exynos_mixer.c | 1 +
 2 files changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 2b14cc7def6f..adc69331dafe 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -298,6 +298,15 @@ static const struct hdmiphy_config hdmiphy_v14_configs[] = 
{
},
},
{
+   .pixel_clock = 8550,
+   .conf = {
+   0x01, 0xd1, 0x24, 0x11, 0x40, 0x40, 0xd0, 0x08,
+   0x84, 0xa0, 0xd6, 0xd8, 0x45, 0xa0, 0xac, 0x80,
+   0x08, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86,
+   0x54, 0x90, 0x24, 0x01, 0x00, 0x00, 0x01, 0x80,
+   },
+   },
+   {
.pixel_clock = 10650,
.conf = {
0x01, 0xd1, 0x2c, 0x12, 0x40, 0x0c, 0x09, 0x08,
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 96c3f61f080e..1dd65e261385 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -1127,6 +1127,7 @@ static int mixer_atomic_check(struct exynos_drm_crtc 
*crtc,
 
/* Check against some specific resolutions. */
if ((w == 1024 && h == 768) ||
+   (w == 1366 && h == 768) ||
(w == 1280 && h == 1024))
return 0;
 
-- 
2.13.5

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

Re: [PATCH] qxl: fix primary surface handling

[Emil Velikov]

[CC-ing Gabriel]

Hi Gerd,

On 11 September 2017 at 10:39, Gerd Hoffmann  wrote:
> The atomic conversion of the qxl driver didn't got the primary surface
> handling completely right.  It works in the common simple cases, but
> fails for example when changing the display resolution using xrandr or
> in multihead setups.
>
> The rules are simple:  There is one primary surface.  Before defining a
> new one you have to destroy the old one.
>
> This patch makes qxl_primary_atomic_update() destroy the primary surface
> before defining a new one.  It fixes is_primary flag updates.  It adds
> is_primary checks so we don't try to update the primary surface in case
> it already has the state we want it being in.
>
Please include a fixes tag alongside the bug reports (if it addresses
both that is). Adding cross-references is very beneficial.

Fixes: 3538e80a869b ("drm: qxl: Atomic phase 1: Implement mode_set_nofb")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102338
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=196777


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

[PATCH 1/8] drm: provide management functions for drm_file

[Noralf Trønnes]

From: David Herrmann 

Rather than doing drm_file allocation/destruction right in the fops, lets
provide separate helpers. This decouples drm_file management from the
still-mandatory drm-fops. It prepares for use of drm_file without the
fops, both by possible separate fops implementations and APIs (not that I
am aware of any such plans), and more importantly from in-kernel use where
no real file is available.

Signed-off-by: David Herrmann 
Rebased, kept drm_events_release() and exported functions.
Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/drm_file.c | 323 ++---
 include/drm/drm_file.h |   2 +
 2 files changed, 186 insertions(+), 139 deletions(-)

diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index b3c6e99..eeea374 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -101,6 +101,176 @@ DEFINE_MUTEX(drm_global_mutex);
 
 static int drm_open_helper(struct file *filp, struct drm_minor *minor);
 
+/**
+ * drm_file_alloc - allocate file context
+ * @minor: minor to allocate on
+ *
+ * This allocates a new DRM file context. It is not linked into any context and
+ * can be used by the caller freely. Note that the context keeps a pointer to
+ * @minor, so it must be freed before @minor is.
+ *
+ * The legacy paths might require the drm_global_mutex to be held.
+ *
+ * RETURNS:
+ * Pointer to newly allocated context, ERR_PTR on failure.
+ */
+struct drm_file *drm_file_alloc(struct drm_minor *minor)
+{
+   struct drm_device *dev = minor->dev;
+   struct drm_file *file;
+   int ret;
+
+   file = kzalloc(sizeof(*file), GFP_KERNEL);
+   if (!file)
+   return ERR_PTR(-ENOMEM);
+
+   file->pid = get_pid(task_pid(current));
+   file->minor = minor;
+
+   /* for compatibility root is always authenticated */
+   file->authenticated = capable(CAP_SYS_ADMIN);
+   file->lock_count = 0;
+
+   INIT_LIST_HEAD(&file->lhead);
+   INIT_LIST_HEAD(&file->fbs);
+   mutex_init(&file->fbs_lock);
+   INIT_LIST_HEAD(&file->blobs);
+   INIT_LIST_HEAD(&file->pending_event_list);
+   INIT_LIST_HEAD(&file->event_list);
+   init_waitqueue_head(&file->event_wait);
+   file->event_space = 4096; /* set aside 4k for event buffer */
+
+   mutex_init(&file->event_read_lock);
+
+   if (drm_core_check_feature(dev, DRIVER_GEM))
+   drm_gem_open(dev, file);
+
+   if (drm_core_check_feature(dev, DRIVER_SYNCOBJ))
+   drm_syncobj_open(file);
+
+   if (drm_core_check_feature(dev, DRIVER_PRIME))
+   drm_prime_init_file_private(&file->prime);
+
+   if (dev->driver->open) {
+   ret = dev->driver->open(dev, file);
+   if (ret < 0)
+   goto out_prime_destroy;
+   }
+
+   if (drm_is_primary_client(file)) {
+   ret = drm_master_open(file);
+   if (ret)
+   goto out_close;
+   }
+
+   return file;
+
+out_close:
+   if (dev->driver->postclose)
+   dev->driver->postclose(dev, file);
+out_prime_destroy:
+   if (drm_core_check_feature(dev, DRIVER_PRIME))
+   drm_prime_destroy_file_private(&file->prime);
+   if (drm_core_check_feature(dev, DRIVER_SYNCOBJ))
+   drm_syncobj_release(file);
+   if (drm_core_check_feature(dev, DRIVER_GEM))
+   drm_gem_release(dev, file);
+   put_pid(file->pid);
+   kfree(file);
+
+   return ERR_PTR(ret);
+}
+EXPORT_SYMBOL(drm_file_alloc);
+
+static void drm_events_release(struct drm_file *file)
+{
+   struct drm_device *dev = file->minor->dev;
+   struct drm_pending_event *e, *et;
+   unsigned long flags;
+
+   spin_lock_irqsave(&dev->event_lock, flags);
+
+   /* Unlink pending events */
+   list_for_each_entry_safe(e, et, &file->pending_event_list,
+pending_link) {
+   list_del(&e->pending_link);
+   e->file_priv = NULL;
+   }
+
+   /* Remove unconsumed events */
+   list_for_each_entry_safe(e, et, &file->event_list, link) {
+   list_del(&e->link);
+   kfree(e);
+   }
+
+   spin_unlock_irqrestore(&dev->event_lock, flags);
+}
+
+/**
+ * drm_file_free - free file context
+ * @file: context to free, or NULL
+ *
+ * This destroys and deallocates a DRM file context previously allocated via
+ * drm_file_alloc(). The caller must make sure to unlink it from any contexts
+ * before calling this.
+ *
+ * The legacy paths might require the drm_global_mutex to be held.
+ *
+ * If NULL is passed, this is a no-op.
+ *
+ * RETURNS:
+ * 0 on success, or error code on failure.
+ */
+void drm_file_free(struct drm_file *file)
+{
+   struct drm_device *dev;
+
+   if (!file)
+   return;
+
+   dev = file->minor->dev;
+
+   if (drm_core_check_feature(dev, DRIVER_LEGACY) &&
+   dev->driver->precl

[PATCH 0/8] drm/fb-helper: Use drm_file to get a dumb framebuffer

[Noralf Trønnes]

Hi,

I want to start out by saying that this patchset is low priority for me
and if no one has interest or time to review this, that is just fine. I
was in the flow and just typed it out.

This patchset adds a way for fbdev emulation code to create a
framebuffer that is backed by a dumb buffer. drm_fb_helper gets a
drm_file to hang the objects on, drm_framebuffer_create_dumb() creates
the framebuffer and drm_fb_helper_fini() destroys it.
I have verified that all cma drivers supports dumb buffers, so
converting the library should be fine for all.

A patch by David Herrmann from a year ago made this easy. It was the
last piece in his work to make it possible to create a drm_file for
in-kernel use, but it never got merged.

I've cc'ed intel-gfx since that will give CI runs of the core patches if
I understood Daniel right.

Noralf.

David Herrmann (1):
  drm: provide management functions for drm_file

Noralf Trønnes (7):
  drm/framebuffer: Add drm_framebuffer_create_dumb()
  drm/auth: Export drm_dropmaster_ioctl()
  drm/fb-helper: Allocate a drm_file
  drm/fb-cma-helper: Use drm_framebuffer_create_dumb()
  drm/fb-cma-helper: Drop unnecessary fbdev buffer offset
  drm/tinydrm: Use drm_fbdev_cma_init()
  drm/fb-cma-helper: Remove drm_fbdev_cma_init_with_funcs()

 drivers/gpu/drm/drm_auth.c  |   1 +
 drivers/gpu/drm/drm_fb_cma_helper.c | 111 ++
 drivers/gpu/drm/drm_fb_helper.c |  22 +-
 drivers/gpu/drm/drm_file.c  | 323 
 drivers/gpu/drm/drm_framebuffer.c   |  61 ++
 drivers/gpu/drm/drm_internal.h  |   2 -
 drivers/gpu/drm/tinydrm/core/tinydrm-core.c |   5 +-
 include/drm/drm_auth.h  |   2 +
 include/drm/drm_fb_helper.h |   9 +
 include/drm/drm_file.h  |   2 +
 include/drm/drm_framebuffer.h   |   4 +
 11 files changed, 305 insertions(+), 237 deletions(-)

-- 
2.7.4

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

[PATCH 2/8] drm/framebuffer: Add drm_framebuffer_create_dumb()

[Noralf Trønnes]

drm_framebuffer_create_dumb() uses the dumb buffer API to create a
buffer that is attached to a framebuffer.
Useful for fbdev emulation.

Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/drm_framebuffer.c | 61 +++
 include/drm/drm_framebuffer.h |  4 +++
 2 files changed, 65 insertions(+)

diff --git a/drivers/gpu/drm/drm_framebuffer.c 
b/drivers/gpu/drm/drm_framebuffer.c
index af27984..07e5199 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -955,3 +955,64 @@ int drm_framebuffer_plane_height(int height,
return fb_plane_height(height, fb->format, plane);
 }
 EXPORT_SYMBOL(drm_framebuffer_plane_height);
+
+/**
+ * drm_framebuffer_create_dumb - Create dumb framebuffer
+ * @file_priv: DRM file
+ * @width: Framebuffer width
+ * @height: Framebuffer height
+ * @format: Framebuffer FOURCC format
+ *
+ * This function creates a framebuffer backed by a dumb buffer for in-kernel
+ * use. fbdev emulation code can use this to create a framebuffer.
+ *
+ * Returns:
+ * Pointer to a drm_framebuffer on success or an error pointer on failure.
+ */
+struct drm_framebuffer *
+drm_framebuffer_create_dumb(struct drm_file *file_priv, unsigned int width,
+   unsigned int height, u32 format)
+{
+   struct drm_device *dev = file_priv->minor->dev;
+   struct drm_mode_create_dumb dumb_args = { 0 };
+   struct drm_mode_fb_cmd2 fb_args = { 0 };
+   struct drm_framebuffer *fb;
+   int ret;
+
+   dumb_args.width = width;
+   dumb_args.height = height;
+   dumb_args.bpp = drm_format_plane_cpp(format, 0) * 8;
+
+   ret = drm_mode_create_dumb_ioctl(dev, &dumb_args, file_priv);
+   if (ret)
+   return ERR_PTR(ret);
+
+   fb_args.width = width;
+   fb_args.height = height;
+   fb_args.pixel_format = format;
+   fb_args.handles[0] = dumb_args.handle;
+   fb_args.pitches[0] = dumb_args.pitch;
+
+   ret = drm_mode_addfb2(dev, &fb_args, file_priv);
+   if (ret)
+   goto err_destroy_dumb;
+
+   fb = drm_framebuffer_lookup(dev, fb_args.fb_id);
+   if (!fb) {
+   ret = -ENOENT;
+   goto err_rmfb;
+   }
+
+   /* drop the reference we picked up in framebuffer lookup */
+   drm_framebuffer_put(fb);
+
+   return fb;
+
+err_rmfb:
+   drm_mode_rmfb(dev, &fb_args, file_priv);
+err_destroy_dumb:
+   drm_mode_destroy_dumb_ioctl(dev, &dumb_args, file_priv);
+
+   return ERR_PTR(ret);
+}
+EXPORT_SYMBOL(drm_framebuffer_create_dumb);
diff --git a/include/drm/drm_framebuffer.h b/include/drm/drm_framebuffer.h
index b6996dd..212c66a 100644
--- a/include/drm/drm_framebuffer.h
+++ b/include/drm/drm_framebuffer.h
@@ -306,4 +306,8 @@ int drm_framebuffer_plane_width(int width,
 int drm_framebuffer_plane_height(int height,
 const struct drm_framebuffer *fb, int plane);
 
+struct drm_framebuffer *
+drm_framebuffer_create_dumb(struct drm_file *file_priv, unsigned int width,
+   unsigned int height, u32 format);
+
 #endif
-- 
2.7.4

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

[PATCH 7/8] drm/tinydrm: Use drm_fbdev_cma_init()

[Noralf Trønnes]

Since the cma library now uses drm_framebuffer_create_dumb(),
drm_fbdev_cma_init() will provide a framebuffer with the dirty callback
set.

Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/tinydrm/core/tinydrm-core.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-core.c 
b/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
index 551709e..6ebe970 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
@@ -221,9 +221,8 @@ static int tinydrm_register(struct tinydrm_device *tdev)
if (ret)
return ret;
 
-   fbdev = drm_fbdev_cma_init_with_funcs(drm, bpp ? bpp : 32,
- drm->mode_config.num_connector,
- tdev->fb_funcs);
+   fbdev = drm_fbdev_cma_init(drm, bpp ? bpp : 32,
+  drm->mode_config.num_connector);
if (IS_ERR(fbdev))
DRM_ERROR("Failed to initialize fbdev: %ld\n", PTR_ERR(fbdev));
else
-- 
2.7.4

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

[PATCH 6/8] drm/fb-cma-helper: Drop unnecessary fbdev buffer offset

[Noralf Trønnes]

Drop the unnecessary fbdev buffer offset, it can only be zero since
drm_fb_helper_fill_var() sets xoffset and yoffset to zero;

Cc: Laurent Pinchart 
Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/drm_fb_cma_helper.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
b/drivers/gpu/drm/drm_fb_cma_helper.c
index f0a2863..49623a4 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -316,7 +316,6 @@ drm_fbdev_cma_create(struct drm_fb_helper *helper,
struct drm_gem_cma_object *obj;
struct drm_framebuffer *fb;
unsigned int bytes_per_pixel;
-   unsigned long offset;
struct fb_info *fbi;
size_t size;
u32 format;
@@ -352,12 +351,9 @@ drm_fbdev_cma_create(struct drm_fb_helper *helper,
drm_fb_helper_fill_fix(fbi, fb->pitches[0], fb->format->depth);
drm_fb_helper_fill_var(fbi, helper, sizes->fb_width, sizes->fb_height);
 
-   offset = fbi->var.xoffset * bytes_per_pixel;
-   offset += fbi->var.yoffset * fb->pitches[0];
-
dev->mode_config.fb_base = (resource_size_t)obj->paddr;
-   fbi->screen_base = obj->vaddr + offset;
-   fbi->fix.smem_start = (unsigned long)(obj->paddr + offset);
+   fbi->screen_base = obj->vaddr;
+   fbi->fix.smem_start = (unsigned long)obj->paddr;
fbi->screen_size = size;
fbi->fix.smem_len = size;
 
-- 
2.7.4

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

[PATCH 8/8] drm/fb-cma-helper: Remove drm_fbdev_cma_init_with_funcs()

[Noralf Trønnes]

No users left so remove drm_fbdev_cma_init_with_funcs().
Also remove example fbdev code in docs, there's nothing special now.

Cc: Laurent Pinchart 
Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/drm_fb_cma_helper.c | 59 ++---
 1 file changed, 3 insertions(+), 56 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
b/drivers/gpu/drm/drm_fb_cma_helper.c
index 49623a4..d8904a8 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -29,7 +29,6 @@
 
 struct drm_fbdev_cma {
struct drm_fb_helperfb_helper;
-   const struct drm_framebuffer_funcs *fb_funcs;
 };
 
 /**
@@ -46,33 +45,6 @@ struct drm_fbdev_cma {
  * If the &drm_framebuffer_funcs.dirty callback is set, fb_deferred_io will be
  * set up automatically. &drm_framebuffer_funcs.dirty is called by
  * drm_fb_helper_deferred_io() in process context (&struct delayed_work).
- *
- * Example fbdev deferred io code::
- *
- * static int driver_fb_dirty(struct drm_framebuffer *fb,
- *struct drm_file *file_priv,
- *unsigned flags, unsigned color,
- *struct drm_clip_rect *clips,
- *unsigned num_clips)
- * {
- * struct drm_gem_cma_object *cma = drm_fb_cma_get_gem_obj(fb, 0);
- * ... push changes ...
- * return 0;
- * }
- *
- * static struct drm_framebuffer_funcs driver_fb_funcs = {
- * .destroy   = drm_fb_cma_destroy,
- * .create_handle = drm_fb_cma_create_handle,
- * .dirty = driver_fb_dirty,
- * };
- *
- * Initialize::
- *
- * fbdev = drm_fbdev_cma_init_with_funcs(dev, 16,
- *   dev->mode_config.num_crtc,
- *   dev->mode_config.num_connector,
- *   &driver_fb_funcs);
- *
  */
 
 static inline struct drm_fbdev_cma *to_fbdev_cma(struct drm_fb_helper *helper)
@@ -371,17 +343,15 @@ static const struct drm_fb_helper_funcs 
drm_fb_cma_helper_funcs = {
 };
 
 /**
- * drm_fbdev_cma_init_with_funcs() - Allocate and initializes a drm_fbdev_cma 
struct
+ * drm_fbdev_cma_init() - Allocate and initializes a drm_fbdev_cma struct
  * @dev: DRM device
  * @preferred_bpp: Preferred bits per pixel for the device
  * @max_conn_count: Maximum number of connectors
- * @funcs: fb helper functions, in particular a custom dirty() callback
  *
  * Returns a newly allocated drm_fbdev_cma struct or a ERR_PTR.
  */
-struct drm_fbdev_cma *drm_fbdev_cma_init_with_funcs(struct drm_device *dev,
-   unsigned int preferred_bpp, unsigned int max_conn_count,
-   const struct drm_framebuffer_funcs *funcs)
+struct drm_fbdev_cma *drm_fbdev_cma_init(struct drm_device *dev,
+   unsigned int preferred_bpp, unsigned int max_conn_count)
 {
struct drm_fbdev_cma *fbdev_cma;
struct drm_fb_helper *helper;
@@ -392,7 +362,6 @@ struct drm_fbdev_cma *drm_fbdev_cma_init_with_funcs(struct 
drm_device *dev,
dev_err(dev->dev, "Failed to allocate drm fbdev.\n");
return ERR_PTR(-ENOMEM);
}
-   fbdev_cma->fb_funcs = funcs;
 
helper = &fbdev_cma->fb_helper;
 
@@ -426,28 +395,6 @@ struct drm_fbdev_cma *drm_fbdev_cma_init_with_funcs(struct 
drm_device *dev,
 
return ERR_PTR(ret);
 }
-EXPORT_SYMBOL_GPL(drm_fbdev_cma_init_with_funcs);
-
-static const struct drm_framebuffer_funcs drm_fb_cma_funcs = {
-   .destroy= drm_gem_fb_destroy,
-   .create_handle  = drm_gem_fb_create_handle,
-};
-
-/**
- * drm_fbdev_cma_init() - Allocate and initializes a drm_fbdev_cma struct
- * @dev: DRM device
- * @preferred_bpp: Preferred bits per pixel for the device
- * @max_conn_count: Maximum number of connectors
- *
- * Returns a newly allocated drm_fbdev_cma struct or a ERR_PTR.
- */
-struct drm_fbdev_cma *drm_fbdev_cma_init(struct drm_device *dev,
-   unsigned int preferred_bpp, unsigned int max_conn_count)
-{
-   return drm_fbdev_cma_init_with_funcs(dev, preferred_bpp,
-max_conn_count,
-&drm_fb_cma_funcs);
-}
 EXPORT_SYMBOL_GPL(drm_fbdev_cma_init);
 
 /**
-- 
2.7.4

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

[PATCH 3/8] drm/auth: Export drm_dropmaster_ioctl()

[Noralf Trønnes]

Export drm_dropmaster_ioctl() so in-kernel drm_file_alloc() users can
drop master.

Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/drm_auth.c | 1 +
 drivers/gpu/drm/drm_internal.h | 2 --
 include/drm/drm_auth.h | 2 ++
 3 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
index 7ff6973..8417130 100644
--- a/drivers/gpu/drm/drm_auth.c
+++ b/drivers/gpu/drm/drm_auth.c
@@ -221,6 +221,7 @@ int drm_dropmaster_ioctl(struct drm_device *dev, void *data,
mutex_unlock(&dev->master_mutex);
return ret;
 }
+EXPORT_SYMBOL(drm_dropmaster_ioctl);
 
 int drm_master_open(struct drm_file *file_priv)
 {
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index 4e906b8..f690ccd 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -78,8 +78,6 @@ int drm_authmagic(struct drm_device *dev, void *data,
  struct drm_file *file_priv);
 int drm_setmaster_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);
-int drm_dropmaster_ioctl(struct drm_device *dev, void *data,
-struct drm_file *file_priv);
 int drm_master_open(struct drm_file *file_priv);
 void drm_master_release(struct drm_file *file_priv);
 
diff --git a/include/drm/drm_auth.h b/include/drm/drm_auth.h
index 81a40c2..b72c137 100644
--- a/include/drm/drm_auth.h
+++ b/include/drm/drm_auth.h
@@ -81,5 +81,7 @@ struct drm_master {
 struct drm_master *drm_master_get(struct drm_master *master);
 void drm_master_put(struct drm_master **master);
 bool drm_is_current_master(struct drm_file *fpriv);
+int drm_dropmaster_ioctl(struct drm_device *dev, void *data,
+struct drm_file *file_priv);
 
 #endif
-- 
2.7.4

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

[PATCH 5/8] drm/fb-cma-helper: Use drm_framebuffer_create_dumb()

[Noralf Trønnes]

Use drm_framebuffer_create_dumb() to create a framebuffer for fbdev.
No need for error cleanup in drm_fbdev_cma_create(), since the one in
drm_fbdev_cma_init_with_funcs() will do fine.

Cc: Laurent Pinchart 
Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/drm_fb_cma_helper.c | 44 +
 1 file changed, 15 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
b/drivers/gpu/drm/drm_fb_cma_helper.c
index f2ee883..f0a2863 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -312,7 +312,6 @@ static int
 drm_fbdev_cma_create(struct drm_fb_helper *helper,
struct drm_fb_helper_surface_size *sizes)
 {
-   struct drm_fbdev_cma *fbdev_cma = to_fbdev_cma(helper);
struct drm_device *dev = helper->dev;
struct drm_gem_cma_object *obj;
struct drm_framebuffer *fb;
@@ -320,6 +319,7 @@ drm_fbdev_cma_create(struct drm_fb_helper *helper,
unsigned long offset;
struct fb_info *fbi;
size_t size;
+   u32 format;
int ret;
 
DRM_DEBUG_KMS("surface width(%d), height(%d) and bpp(%d)\n",
@@ -327,26 +327,23 @@ drm_fbdev_cma_create(struct drm_fb_helper *helper,
sizes->surface_bpp);
 
bytes_per_pixel = DIV_ROUND_UP(sizes->surface_bpp, 8);
-   size = sizes->surface_width * sizes->surface_height * bytes_per_pixel;
-   obj = drm_gem_cma_create(dev, size);
-   if (IS_ERR(obj))
-   return -ENOMEM;
 
-   fbi = drm_fb_helper_alloc_fbi(helper);
-   if (IS_ERR(fbi)) {
-   ret = PTR_ERR(fbi);
-   goto err_gem_free_object;
-   }
-
-   fb = drm_gem_fbdev_fb_create(dev, sizes, 0, &obj->base,
-fbdev_cma->fb_funcs);
+   format = drm_mode_legacy_fb_format(sizes->surface_bpp,
+  sizes->surface_depth);
+   fb = drm_framebuffer_create_dumb(helper->file, sizes->surface_width,
+sizes->surface_height, format);
if (IS_ERR(fb)) {
-   dev_err(dev->dev, "Failed to allocate DRM framebuffer.\n");
-   ret = PTR_ERR(fb);
-   goto err_fb_info_destroy;
+   DRM_DEV_ERROR(dev->dev, "Failed to create DRM framebuffer.\n");
+   return PTR_ERR(fb);
}
 
helper->fb = fb;
+   obj = to_drm_gem_cma_obj(fb->obj[0]);
+   size = fb->obj[0]->size;
+
+   fbi = drm_fb_helper_alloc_fbi(helper);
+   if (IS_ERR(fbi))
+   return PTR_ERR(fbi);
 
fbi->par = helper;
fbi->flags = FBINFO_FLAG_DEFAULT;
@@ -364,21 +361,13 @@ drm_fbdev_cma_create(struct drm_fb_helper *helper,
fbi->screen_size = size;
fbi->fix.smem_len = size;
 
-   if (fbdev_cma->fb_funcs->dirty) {
+   if (fb->funcs->dirty) {
ret = drm_fbdev_cma_defio_init(fbi, obj);
if (ret)
-   goto err_cma_destroy;
+   return ret;
}
 
return 0;
-
-err_cma_destroy:
-   drm_framebuffer_remove(fb);
-err_fb_info_destroy:
-   drm_fb_helper_fini(helper);
-err_gem_free_object:
-   drm_gem_object_put_unlocked(&obj->base);
-   return ret;
 }
 
 static const struct drm_fb_helper_funcs drm_fb_cma_helper_funcs = {
@@ -475,9 +464,6 @@ void drm_fbdev_cma_fini(struct drm_fbdev_cma *fbdev_cma)
if (fbdev_cma->fb_helper.fbdev)
drm_fbdev_cma_defio_fini(fbdev_cma->fb_helper.fbdev);
 
-   if (fbdev_cma->fb_helper.fb)
-   drm_framebuffer_remove(fbdev_cma->fb_helper.fb);
-
drm_fb_helper_fini(&fbdev_cma->fb_helper);
kfree(fbdev_cma);
 }
-- 
2.7.4

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

[PATCH 4/8] drm/fb-helper: Allocate a drm_file

[Noralf Trønnes]

Allocate a drm_file so drivers can use drm_framebuffer_create_dumb()
to create a buffer. The framebuffer is reaped automtically in
drm_fb_helper_fini().

Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/drm_fb_helper.c | 22 --
 include/drm/drm_fb_helper.h |  9 +
 2 files changed, 29 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 6a31d13..a04bdf9 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -902,6 +903,7 @@ EXPORT_SYMBOL(drm_fb_helper_unregister_fbi);
  *
  * This cleans up all remaining resources associated with @fb_helper. Must be
  * called after drm_fb_helper_unlink_fbi() was called.
+ * drm_framebuffer_create_dumb() created framebuffers will be destroyed.
  */
 void drm_fb_helper_fini(struct drm_fb_helper *fb_helper)
 {
@@ -932,6 +934,7 @@ void drm_fb_helper_fini(struct drm_fb_helper *fb_helper)
mutex_destroy(&fb_helper->lock);
drm_fb_helper_crtc_free(fb_helper);
 
+   drm_file_free(fb_helper->file);
 }
 EXPORT_SYMBOL(drm_fb_helper_fini);
 
@@ -2465,6 +2468,16 @@ __drm_fb_helper_initial_config_and_unlock(struct 
drm_fb_helper *fb_helper,
unsigned int width, height;
int ret;
 
+   fb_helper->file = drm_file_alloc(dev->primary);
+   if (IS_ERR(fb_helper->file)) {
+   ret = PTR_ERR(fb_helper->file);
+   fb_helper->file = NULL;
+   mutex_unlock(&fb_helper->lock);
+   return ret;
+   }
+
+   drm_dropmaster_ioctl(dev, NULL, fb_helper->file);
+
width = dev->mode_config.max_width;
height = dev->mode_config.max_height;
 
@@ -2478,7 +2491,7 @@ __drm_fb_helper_initial_config_and_unlock(struct 
drm_fb_helper *fb_helper,
}
mutex_unlock(&fb_helper->lock);
 
-   return ret;
+   goto err_free_file;
}
drm_setup_crtcs_fb(fb_helper);
 
@@ -2494,7 +2507,7 @@ __drm_fb_helper_initial_config_and_unlock(struct 
drm_fb_helper *fb_helper,
 
ret = register_framebuffer(info);
if (ret < 0)
-   return ret;
+   goto err_free_file;
 
dev_info(dev->dev, "fb%d: %s frame buffer device\n",
 info->node, info->fix.id);
@@ -2507,6 +2520,11 @@ __drm_fb_helper_initial_config_and_unlock(struct 
drm_fb_helper *fb_helper,
mutex_unlock(&kernel_fb_helper_lock);
 
return 0;
+
+err_free_file:
+   drm_file_free(fb_helper->file);
+
+   return ret;
 }
 
 /**
diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index 33fe959..89757ff 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -154,6 +154,15 @@ struct drm_fb_helper_connector {
 struct drm_fb_helper {
struct drm_framebuffer *fb;
struct drm_device *dev;
+
+   /**
+* @file:
+*
+* DRM file that can be used with drm_framebuffer_create_dumb() to
+* create a framebuffer to back fbdev.
+*/
+   struct drm_file *file;
+
int crtc_count;
struct drm_fb_helper_crtc *crtc_info;
int connector_count;
-- 
2.7.4

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

Re: [PATCH 1/2] dma-buf: make reservation_object_copy_fences rcu save

[Christian König]

Am 11.09.2017 um 15:56 schrieb Maarten Lankhorst:

Op 11-09-17 om 14:53 schreef Christian König:

Am 10.09.2017 um 09:30 schrieb Maarten Lankhorst:

Op 04-09-17 om 21:02 schreef Christian König:

From: Christian König 

Stop requiring that the src reservation object is locked for this operation.

Signed-off-by: Christian König 
---
   drivers/dma-buf/reservation.c | 56 
---
   1 file changed, 42 insertions(+), 14 deletions(-)

diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index dec3a81..b44d9d7 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -266,8 +266,7 @@ EXPORT_SYMBOL(reservation_object_add_excl_fence);
   * @dst: the destination reservation object
   * @src: the source reservation object
   *
-* Copy all fences from src to dst. Both src->lock as well as dst-lock must be
-* held.
+* Copy all fences from src to dst. dst-lock must be held.
   */
   int reservation_object_copy_fences(struct reservation_object *dst,
  struct reservation_object *src)

Could this be implemented using reservation_object_get_fences_rcu? You're 
essentially duplicating its functionality.

I've considered this as well, but reservation_object_get_fences_rcu() returns 
an array and here we need an reservation_object_list.

Doesn't seem too hard, below is the result from fiddling with the allocation 
function..
reservation_object_list is just a list of fences with some junk in front.

Here you go, but only tested with the compiler. O:)
-8<-
  drivers/dma-buf/reservation.c | 192 
+
  1 file changed, 109 insertions(+), 83 deletions(-)


To be honest that looks rather ugly to me for not much gain.

Additional to that we loose the optimization I've stolen from the wait 
function.


Regards,
Christian.



diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index dec3a815455d..72ee91f34132 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -261,87 +261,43 @@ void reservation_object_add_excl_fence(struct 
reservation_object *obj,
  }
  EXPORT_SYMBOL(reservation_object_add_excl_fence);
  
-/**

-* reservation_object_copy_fences - Copy all fences from src to dst.
-* @dst: the destination reservation object
-* @src: the source reservation object
-*
-* Copy all fences from src to dst. Both src->lock as well as dst-lock must be
-* held.
-*/
-int reservation_object_copy_fences(struct reservation_object *dst,
-  struct reservation_object *src)
+static bool realloc_shared(void **ptr, struct dma_fence ***pshared, unsigned 
shared_max, bool alloc_list, bool unlocked)
  {
-   struct reservation_object_list *src_list, *dst_list;
-   struct dma_fence *old, *new;
-   size_t size;
-   unsigned i;
-
-   src_list = reservation_object_get_list(src);
-
-   if (src_list) {
-   size = offsetof(typeof(*src_list),
-   shared[src_list->shared_count]);
-   dst_list = kmalloc(size, GFP_KERNEL);
-   if (!dst_list)
-   return -ENOMEM;
-
-   dst_list->shared_count = src_list->shared_count;
-   dst_list->shared_max = src_list->shared_count;
-   for (i = 0; i < src_list->shared_count; ++i)
-   dst_list->shared[i] =
-   dma_fence_get(src_list->shared[i]);
-   } else {
-   dst_list = NULL;
-   }
-
-   kfree(dst->staged);
-   dst->staged = NULL;
+   size_t sz;
+   void *newptr;
  
-	src_list = reservation_object_get_list(dst);

+   if (alloc_list)
+   sz = offsetof(struct reservation_object_list, 
shared[shared_max]);
+   else
+   sz = shared_max * sizeof(struct dma_fence *);
  
-	old = reservation_object_get_excl(dst);

-   new = reservation_object_get_excl(src);
+   newptr = krealloc(*ptr, sz, unlocked ? GFP_KERNEL : GFP_NOWAIT | 
__GFP_NOWARN);
+   if (!newptr)
+   return false;
  
-	dma_fence_get(new);

+   *ptr = newptr;
+   if (alloc_list) {
+   struct reservation_object_list *fobj = newptr;
  
-	preempt_disable();

-   write_seqcount_begin(&dst->seq);
-   /* write_seqcount_begin provides the necessary memory barrier */
-   RCU_INIT_POINTER(dst->fence_excl, new);
-   RCU_INIT_POINTER(dst->fence, dst_list);
-   write_seqcount_end(&dst->seq);
-   preempt_enable();
-
-   if (src_list)
-   kfree_rcu(src_list, rcu);
-   dma_fence_put(old);
+   fobj->shared_max = shared_max;
+   *pshared = fobj->shared;
+   } else
+   *pshared = newptr;
  
-	return 0;

+   return true;
  }
-EXPORT_SYMBOL(reservation_object_copy_fences);
  
-/**

[Bug 102659] Radeon 7970M Lockup

[bugzilla-daemon]

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

Bug ID: 102659
   Summary: Radeon 7970M Lockup
   Product: DRI
   Version: XOrg git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: vilsol2...@gmail.com

Created attachment 134160
  --> https://bugs.freedesktop.org/attachment.cgi?id=134160&action=edit
DMESG Log

I am experiencing full GPU lockup when running anything on the GPU (using the
DRI_PRIME=1 flag).

No matter how demanding is whatever I am testing, after ~3min it will lock up
the GPU and freeze.

I am running on 4.10.0-34-lowlatency kernel with everything else up to date.
(same error on generic kernel).

-- 
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 102659] Radeon 7970M Lockup

[bugzilla-daemon]

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

--- Comment #1 from vilsol2...@gmail.com ---
Created attachment 134161
  --> https://bugs.freedesktop.org/attachment.cgi?id=134161&action=edit
LSPCI Output

-- 
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 102659] Radeon 7970M Lockup

[bugzilla-daemon]

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

--- Comment #2 from vilsol2...@gmail.com ---
Created attachment 134162
  --> https://bugs.freedesktop.org/attachment.cgi?id=134162&action=edit
GLXINFO Output

-- 
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 102659] Radeon 7970M Lockup

[bugzilla-daemon]

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

vilsol2...@gmail.com changed:

   What|Removed |Added

 Attachment #134160|application/x-trash |text/x-log
  mime type||

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

Re: [PATCH 1/2] dma-buf: make reservation_object_copy_fences rcu save

[Maarten Lankhorst]

Op 11-09-17 om 16:45 schreef Christian König:
> Am 11.09.2017 um 15:56 schrieb Maarten Lankhorst:
>> Op 11-09-17 om 14:53 schreef Christian König:
>>> Am 10.09.2017 um 09:30 schrieb Maarten Lankhorst:
 Op 04-09-17 om 21:02 schreef Christian König:
> From: Christian König 
>
> Stop requiring that the src reservation object is locked for this 
> operation.
>
> Signed-off-by: Christian König 
> ---
>drivers/dma-buf/reservation.c | 56 
> ---
>1 file changed, 42 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
> index dec3a81..b44d9d7 100644
> --- a/drivers/dma-buf/reservation.c
> +++ b/drivers/dma-buf/reservation.c
> @@ -266,8 +266,7 @@ EXPORT_SYMBOL(reservation_object_add_excl_fence);
>* @dst: the destination reservation object
>* @src: the source reservation object
>*
> -* Copy all fences from src to dst. Both src->lock as well as dst-lock 
> must be
> -* held.
> +* Copy all fences from src to dst. dst-lock must be held.
>*/
>int reservation_object_copy_fences(struct reservation_object *dst,
>   struct reservation_object *src)
 Could this be implemented using reservation_object_get_fences_rcu? You're 
 essentially duplicating its functionality.
>>> I've considered this as well, but reservation_object_get_fences_rcu() 
>>> returns an array and here we need an reservation_object_list.
>> Doesn't seem too hard, below is the result from fiddling with the allocation 
>> function..
>> reservation_object_list is just a list of fences with some junk in front.
>>
>> Here you go, but only tested with the compiler. O:)
>> -8<-
>>   drivers/dma-buf/reservation.c | 192 
>> +
>>   1 file changed, 109 insertions(+), 83 deletions(-)
>
> To be honest that looks rather ugly to me for not much gain.
>
> Additional to that we loose the optimization I've stolen from the wait 
> function.

Right now your version does exactly the same as 
reservation_object_get_fences_rcu,
but with a reservation_object_list instead of a fence array.

Can't you change reservation_object_get_fences_rcu to return a
reservation_object_list? All callsites look like they could be easily converted.

So the new patch series would be:
1. Make reservation_object_get_fences_rcu return a reservation_object_list
2. Add optimization
3. Convert reservation_object_copy_fences to use rcu.

Cheers,
Maarten

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

Re: [PATCH 1/2] dma-buf: make reservation_object_copy_fences rcu save

[Christian König]

Am 11.09.2017 um 17:13 schrieb Maarten Lankhorst:

Op 11-09-17 om 16:45 schreef Christian König:

Am 11.09.2017 um 15:56 schrieb Maarten Lankhorst:

Op 11-09-17 om 14:53 schreef Christian König:

Am 10.09.2017 um 09:30 schrieb Maarten Lankhorst:
[SNIP]

To be honest that looks rather ugly to me for not much gain.

Additional to that we loose the optimization I've stolen from the wait function.

Right now your version does exactly the same as 
reservation_object_get_fences_rcu,
but with a reservation_object_list instead of a fence array.


Well then please take a closer look again:

for (i = 0; i < src_list->shared_count; ++i) {
struct dma_fence *fence;

fence = rcu_dereference(src_list->shared[i]);
if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT,
 &fence->flags))
continue;

if (!dma_fence_get_rcu(fence)) {
kfree(dst_list);
src_list = rcu_dereference(src->fence);
goto retry;
}

if (dma_fence_is_signaled(fence)) {
dma_fence_put(fence);
continue;
}

dst_list->shared[dst_list->shared_count++] = fence;
}


We only take fences into the new reservation list when they aren't 
already signaled.


This can't be added to reservation_object_get_fences_rcu() because that 
would break VM handling on radeon and amdgpu.


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

Re: [PATCH 1/2] dma-buf: make reservation_object_copy_fences rcu save

[Christian König]

Am 11.09.2017 um 17:22 schrieb Christian König:

Am 11.09.2017 um 17:13 schrieb Maarten Lankhorst:

Op 11-09-17 om 16:45 schreef Christian König:

Am 11.09.2017 um 15:56 schrieb Maarten Lankhorst:

Op 11-09-17 om 14:53 schreef Christian König:

Am 10.09.2017 um 09:30 schrieb Maarten Lankhorst:
[SNIP]

To be honest that looks rather ugly to me for not much gain.

Additional to that we loose the optimization I've stolen from the 
wait function.
Right now your version does exactly the same as 
reservation_object_get_fences_rcu,

but with a reservation_object_list instead of a fence array.


Well then please take a closer look again:

for (i = 0; i < src_list->shared_count; ++i) {
struct dma_fence *fence;

fence = rcu_dereference(src_list->shared[i]);
if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT,
 &fence->flags))
continue;

if (!dma_fence_get_rcu(fence)) {
kfree(dst_list);
src_list = rcu_dereference(src->fence);
goto retry;
}

if (dma_fence_is_signaled(fence)) {
dma_fence_put(fence);
continue;
}

dst_list->shared[dst_list->shared_count++] = fence;
}


We only take fences into the new reservation list when they aren't 
already signaled.


This can't be added to reservation_object_get_fences_rcu() because 
that would break VM handling on radeon and amdgpu.


What we could do is adding a function to return all fences (including 
the exclusive one) as reservation_object_list() and use that in both the 
wait as well as the copy function.


Regards,
Christian.



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



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

Re: [PATCH 1/2] dma-buf: make reservation_object_copy_fences rcu save

[Maarten Lankhorst]

Op 11-09-17 om 17:24 schreef Christian König:
> Am 11.09.2017 um 17:22 schrieb Christian König:
>> Am 11.09.2017 um 17:13 schrieb Maarten Lankhorst:
>>> Op 11-09-17 om 16:45 schreef Christian König:
 Am 11.09.2017 um 15:56 schrieb Maarten Lankhorst:
> Op 11-09-17 om 14:53 schreef Christian König:
>> Am 10.09.2017 um 09:30 schrieb Maarten Lankhorst:
>> [SNIP]
 To be honest that looks rather ugly to me for not much gain.

 Additional to that we loose the optimization I've stolen from the wait 
 function.
>>> Right now your version does exactly the same as 
>>> reservation_object_get_fences_rcu,
>>> but with a reservation_object_list instead of a fence array.
>>
>> Well then please take a closer look again:
>>> for (i = 0; i < src_list->shared_count; ++i) {
>>> struct dma_fence *fence;
>>>
>>> fence = rcu_dereference(src_list->shared[i]);
>>> if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT,
>>>  &fence->flags))
>>> continue;
>>>
>>> if (!dma_fence_get_rcu(fence)) {
>>> kfree(dst_list);
>>> src_list = rcu_dereference(src->fence);
>>> goto retry;
>>> }
>>>
>>> if (dma_fence_is_signaled(fence)) {
>>> dma_fence_put(fence);
>>> continue;
>>> }
>>>
>>> dst_list->shared[dst_list->shared_count++] = fence;
>>> }
>>
>> We only take fences into the new reservation list when they aren't already 
>> signaled.
>>
>> This can't be added to reservation_object_get_fences_rcu() because that 
>> would break VM handling on radeon and amdgpu.
>
> What we could do is adding a function to return all fences (including the 
> exclusive one) as reservation_object_list() and use that in both the wait as 
> well as the copy function. 
Yeah, but I don't see the problem with VM, guessing amdgpu_vm_prt_fini.. why 
would it break if I pruned the signaled fences from the copied list?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[bugzilla-daemon]

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

--- Comment #85 from Jean Delvare (jdelv...@suse.de) ---
Created attachment 258301
  --> https://bugzilla.kernel.org/attachment.cgi?id=258301&action=edit
[PATCH] drm/amdgpu: revert tile table update for oland (for kernels v4.13 and
up)

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

Re: [PATCH 1/2] dma-buf: make reservation_object_copy_fences rcu save

[Christian König]

Am 11.09.2017 um 17:29 schrieb Maarten Lankhorst:

Op 11-09-17 om 17:24 schreef Christian König:

Am 11.09.2017 um 17:22 schrieb Christian König:

Am 11.09.2017 um 17:13 schrieb Maarten Lankhorst:

Op 11-09-17 om 16:45 schreef Christian König:

Am 11.09.2017 um 15:56 schrieb Maarten Lankhorst:

Op 11-09-17 om 14:53 schreef Christian König:

Am 10.09.2017 um 09:30 schrieb Maarten Lankhorst:
[SNIP]

To be honest that looks rather ugly to me for not much gain.

Additional to that we loose the optimization I've stolen from the wait function.

Right now your version does exactly the same as 
reservation_object_get_fences_rcu,
but with a reservation_object_list instead of a fence array.

Well then please take a closer look again:

 for (i = 0; i < src_list->shared_count; ++i) {
 struct dma_fence *fence;

 fence = rcu_dereference(src_list->shared[i]);
 if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT,
  &fence->flags))
 continue;

 if (!dma_fence_get_rcu(fence)) {
 kfree(dst_list);
 src_list = rcu_dereference(src->fence);
 goto retry;
 }

 if (dma_fence_is_signaled(fence)) {
 dma_fence_put(fence);
 continue;
 }

dst_list->shared[dst_list->shared_count++] = fence;
 }

We only take fences into the new reservation list when they aren't already 
signaled.

This can't be added to reservation_object_get_fences_rcu() because that would 
break VM handling on radeon and amdgpu.

What we could do is adding a function to return all fences (including the 
exclusive one) as reservation_object_list() and use that in both the wait as 
well as the copy function.

Yeah, but I don't see the problem with VM, guessing amdgpu_vm_prt_fini.. why 
would it break if I pruned the signaled fences from the copied list?


Not the PRT stuff would break, but the VM flush handling. Rather long 
story, but basically we need to have the already signaled fences as well 
to correctly update the hardware state.


We could of course handle all that in a single function which gets its 
behavior as parameters, but to be honest I think just having two copies 
of the code which looks almost the same is cleaner.


Regards,
Christian.


___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx



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

Re: [PATCH] qxl: fix primary surface handling

[Gabriel Krisman Bertazi]

Gerd Hoffmann  writes:

> The atomic conversion of the qxl driver didn't got the primary surface
> handling completely right.  It works in the common simple cases, but
> fails for example when changing the display resolution using xrandr or
> in multihead setups.
>
> The rules are simple:  There is one primary surface.  Before defining a
> new one you have to destroy the old one.
>
> This patch makes qxl_primary_atomic_update() destroy the primary surface
> before defining a new one.  It fixes is_primary flag updates.  It adds
> is_primary checks so we don't try to update the primary surface in case
> it already has the state we want it being in.
>

Reviewed-by: Gabriel Krisman Bertazi 

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

[PATCH v2 1/2] drm/gem-fb-helper: Cleanup docs

[Noralf Trønnes]

Make the docs read a little better.

Cc: Laurent Pinchart 
Signed-off-by: Noralf Trønnes 
Reviewed-by: Daniel Vetter 
---

Changes:
Addressed Daniel's comments.

 drivers/gpu/drm/drm_gem_framebuffer_helper.c | 25 ++---
 1 file changed, 14 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c 
b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
index d54a083..e2ca002 100644
--- a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
+++ b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
@@ -27,18 +27,21 @@
  * DOC: overview
  *
  * This library provides helpers for drivers that don't subclass
- * &drm_framebuffer and and use &drm_gem_object for their backing storage.
+ * &drm_framebuffer and use &drm_gem_object for their backing storage.
  *
  * Drivers without additional needs to validate framebuffers can simply use
- * drm_gem_fb_create() and everything is wired up automatically. But all
- * parts can be used individually.
+ * drm_gem_fb_create() and everything is wired up automatically. Other drivers
+ * can use all parts independently.
  */

 /**
  * drm_gem_fb_get_obj() - Get GEM object for framebuffer
- * @fb: The framebuffer
+ * @fb: framebuffer
  * @plane: Which plane
  *
+ * No additional reference is taken beyond the one that the &drm_frambuffer
+ * already holds.
+ *
  * Returns the GEM object for given framebuffer.
  */
 struct drm_gem_object *drm_gem_fb_get_obj(struct drm_framebuffer *fb,
@@ -82,7 +85,7 @@ drm_gem_fb_alloc(struct drm_device *dev,

 /**
  * drm_gem_fb_destroy - Free GEM backed framebuffer
- * @fb: DRM framebuffer
+ * @fb: framebuffer
  *
  * Frees a GEM backed framebuffer with its backing buffer(s) and the structure
  * itself. Drivers can use this as their &drm_framebuffer_funcs->destroy
@@ -102,8 +105,8 @@ EXPORT_SYMBOL(drm_gem_fb_destroy);

 /**
  * drm_gem_fb_create_handle - Create handle for GEM backed framebuffer
- * @fb: DRM framebuffer
- * @file: drm file
+ * @fb: framebuffer
+ * @file: DRM file
  * @handle: handle created
  *
  * Drivers can use this as their &drm_framebuffer_funcs->create_handle
@@ -124,7 +127,7 @@ EXPORT_SYMBOL(drm_gem_fb_create_handle);
  *  &drm_mode_config_funcs.fb_create
  *  callback
  * @dev: DRM device
- * @file: drm file for the ioctl call
+ * @file: DRM file for the ioctl call
  * @mode_cmd: metadata from the userspace fb creation request
  * @funcs: vtable to be used for the new framebuffer object
  *
@@ -194,7 +197,7 @@ static const struct drm_framebuffer_funcs drm_gem_fb_funcs 
= {
 /**
  * drm_gem_fb_create() - &drm_mode_config_funcs.fb_create callback function
  * @dev: DRM device
- * @file: drm file for the ioctl call
+ * @file: DRM file for the ioctl call
  * @mode_cmd: metadata from the userspace fb creation request
  *
  * If your hardware has special alignment or pitch requirements these should be
@@ -214,11 +217,11 @@ EXPORT_SYMBOL_GPL(drm_gem_fb_create);
 /**
  * drm_gem_fb_prepare_fb() - Prepare gem framebuffer
  * @plane: Which plane
- * @state: Plane state attach fence to
+ * @state: Plane state the fence will be attached to
  *
  * This can be used as the &drm_plane_helper_funcs.prepare_fb hook.
  *
- * This function checks if the plane FB has an dma-buf attached, extracts
+ * This function checks if the plane FB has a dma-buf attached, extracts
  * the exclusive fence and attaches it to plane state for the atomic helper
  * to wait on.
  *
--
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/gem-fb-helper: Use debug message on gem lookup failure

[Noralf Trønnes]

GEM lookup failure can easily be triggered by userspace so make
it a debug message, not an error message.

Also remove unnecessary inner parentheses and fix alphabetical
struct declaration order.

Cc: Laurent Pinchart 
Signed-off-by: Noralf Trønnes 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_gem_framebuffer_helper.c | 4 ++--
 include/drm/drm_gem_framebuffer_helper.h | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c 
b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
index e2ca002..9cf6566 100644
--- a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
+++ b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
@@ -157,7 +157,7 @@ drm_gem_fb_create_with_funcs(struct drm_device *dev, struct 
drm_file *file,
 
objs[i] = drm_gem_object_lookup(file, mode_cmd->handles[i]);
if (!objs[i]) {
-   DRM_DEV_ERROR(dev->dev, "Failed to lookup GEM\n");
+   DRM_DEBUG_KMS("Failed to lookup GEM object\n");
ret = -ENOENT;
goto err_gem_object_put;
}
@@ -235,7 +235,7 @@ int drm_gem_fb_prepare_fb(struct drm_plane *plane,
struct dma_buf *dma_buf;
struct dma_fence *fence;
 
-   if ((plane->state->fb == state->fb) || !state->fb)
+   if (plane->state->fb == state->fb || !state->fb)
return 0;
 
dma_buf = drm_gem_fb_get_obj(state->fb, 0)->dma_buf;
diff --git a/include/drm/drm_gem_framebuffer_helper.h 
b/include/drm/drm_gem_framebuffer_helper.h
index db9cfa0..5ca7cdc 100644
--- a/include/drm/drm_gem_framebuffer_helper.h
+++ b/include/drm/drm_gem_framebuffer_helper.h
@@ -2,8 +2,8 @@
 #define __DRM_GEM_FB_HELPER_H__
 
 struct drm_device;
-struct drm_file;
 struct drm_fb_helper_surface_size;
+struct drm_file;
 struct drm_framebuffer;
 struct drm_framebuffer_funcs;
 struct drm_gem_object;
-- 
2.7.4

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

Re: [Intel-gfx] [PATCH v2] drm/dp/mst: Sideband message transaction to power up/down nodes

[Pandiyan, Dhinakaran]

On Mon, 2017-09-11 at 16:33 +0300, Ville Syrjälä wrote:
> On Wed, Sep 06, 2017 at 05:14:58PM -0700, Dhinakaran Pandiyan wrote:
> > The POWER_DOWN_PHY and POWER_UP_PHY sideband message transactions allow
> > the source to reqest any node in a mst path or a whole path to be
> > powered down or up. This allows drivers to target a specific sink in the
> > MST topology, an improvement over just power managing the imediate
> > downstream device. Secondly, since the request-reply protocol waits for an
> > ACK, we can be sure that a downstream sink has enough time to respond to a
> > power up/down request.
> 
> I was a bit worried how this handles multiple streams going through
> the same MST device, but looks like the spec has accounted for this
> by having the device skip the D3 if any active streams are present.
> 
> I guess that also means we have to do this after we've turned off the
> stream, assuming we want things actually reach D3. Looks like that does
> match our current order of things.
> 
> Pushed this one to drm-misc-next. Thanks for the patch and review.
> 
Thanks, do you see any potential problems patch with Patch 2/2?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v8 1/3] dt-bindings: display: Add Document for Rockchip Soc LVDS

[Rob Herring]

On Sat, Sep 02, 2017 at 07:28:47PM +0800, Sandy Huang wrote:
> This patch add Document for Rockchip Soc RK3288 LVDS,
> This based on the patches from Mark yao and Heiko Stuebner.
> 
> Signed-off-by: Mark yao 
> Signed-off-by: Heiko Stuebner 
> Signed-off-by: Sandy Huang 
> ---
> Change the Signed-off order
> 
>  .../bindings/display/rockchip/rockchip-lvds.txt| 99 
> ++
>  1 file changed, 99 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt

I see this is already applied, but in the future please add acks when 
posting new versions.

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

Re: [PATCHv4 3/5] dt-bindings: document the CEC GPIO bindings

[Linus Walleij]

On Thu, Aug 31, 2017 at 1:01 PM, Hans Verkuil  wrote:

> +   cec-gpio = <&gpio 7 GPIO_OPEN_DRAIN>;

Actually if you want to be 100% specific:

cec-gpio = <&gpio 7 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>;

(Parens are needed.)

But I'm not very picky about that, active high is implicit.

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

[Bug 102276] System randomly freezes, only fixed by power off and boot.

[bugzilla-daemon]

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

--- Comment #6 from Mathieu Belanger  ---
I might have the same bug

I does not append with Mesa git from mid august but a version from beginning of
September do it.

System boot, splash screen turn on, I login in KDE, sometime it fail and return
to login (X crash).

With it work, doing stuff that require 3D card will sometime work or do
graphics corruption and crash the system. When games work, it usually crash
after not so long.. Even opening the KDE menu can trigger the crash, when that
append, the mouse usually work but nothing else (can't toggle numlock for
example). Using magic keys usually work to reboot the system.

Kernel 4.12
DDX GIT
Mesa GIT
libdrm from 22 Jul (might be old but mesa don't complain when I build it.

Video card is a Polaris 10 card (RX480)


/var/log/message get flooded by these when I open an opengl context:
Sep 11 15:26:44 tanith kernel: amdgpu :0c:00.0: GPU fault detected: 146
0x0b02b714
Sep 11 15:26:44 tanith kernel: amdgpu :0c:00.0:  
VM_CONTEXT1_PROTECTION_FAULT_ADDR   0x00106360
Sep 11 15:26:44 tanith kernel: amdgpu :0c:00.0:  
VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0D0B7014
Sep 11 15:26:44 tanith kernel: amdgpu :0c:00.0: VM fault (0x14, vmid 6) at
page 1074016, write from 'SDM0' (0x53444d30) (183)
Sep 11 15:26:44 tanith kernel: amdgpu :0c:00.0: GPU fault detected: 146
0x0b02b714
Sep 11 15:26:44 tanith kernel: amdgpu :0c:00.0:  
VM_CONTEXT1_PROTECTION_FAULT_ADDR   0x00106362
Sep 11 15:26:44 tanith kernel: amdgpu :0c:00.0:  
VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0D0B7014
Sep 11 15:26:44 tanith kernel: amdgpu :0c:00.0: VM fault (0x14, vmid 6) at
page 1074018, write from 'SDM0' (0x53444d30) (183)
Sep 11 15:26:44 tanith kernel: amdgpu :0c:00.0: GPU fault detected: 146
0x0b02b714
Sep 11 15:26:44 tanith kernel: amdgpu :0c:00.0:  
VM_CONTEXT1_PROTECTION_FAULT_ADDR   0x00106365
Sep 11 15:26:44 tanith kernel: amdgpu :0c:00.0:  
VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0D0B7014
Sep 11 15:26:44 tanith kernel: amdgpu :0c:00.0: VM fault (0x14, vmid 6) at
page 1074021, write from 'SDM0' (0x53444d30) (183)
Sep 11 15:26:44 tanith kernel: amdgpu :0c:00.0: GPU fault detected: 146
0x0b02b714
Sep 11 15:26:44 tanith kernel: amdgpu :0c:00.0:  
VM_CONTEXT1_PROTECTION_FAULT_ADDR   0x00106367
Sep 11 15:26:44 tanith kernel: amdgpu :0c:00.0:  
VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0D0B7014
Sep 11 15:26:44 tanith kernel: amdgpu :0c:00.0: VM fault (0x14, vmid 6) at
page 1074023, write from 'SDM0' (0x53444d30) (183)
Sep 11 15:26:44 tanith kernel: amdgpu :0c:00.0: GPU fault detected: 146
0x0b0ab714
Sep 11 15:26:44 tanith kernel: amdgpu :0c:00.0:  
VM_CONTEXT1_PROTECTION_FAULT_ADDR   0x00106369
Sep 11 15:26:44 tanith kernel: amdgpu :0c:00.0:  
VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0D0B7014
Sep 11 15:26:44 tanith kernel: amdgpu :0c:00.0: VM fault (0x14, vmid 6) at
page 1074025, write from 'SDM0' (0x53444d30) (183)
Sep 11 15:26:44 tanith kernel: amdgpu :0c:00.0: GPU fault detected: 146
0x0b0ab714
Sep 11 15:26:44 tanith kernel: amdgpu :0c:00.0:  
VM_CONTEXT1_PROTECTION_FAULT_ADDR   0x0010636B
Sep 11 15:26:44 tanith kernel: amdgpu :0c:00.0:  
VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0D0B7014
Sep 11 15:26:44 tanith kernel: amdgpu :0c:00.0: VM fault (0x14, vmid 6) at
page 1074027, write from 'SDM0' (0x53444d30) (183)
Sep 11 15:26:44 tanith kernel: amdgpu :0c:00.0: GPU fault detected: 146
0x0b0ab714
Sep 11 15:26:44 tanith kernel: amdgpu :0c:00.0:  
VM_CONTEXT1_PROTECTION_FAULT_ADDR   0x0010636D
Sep 11 15:26:44 tanith kernel: amdgpu :0c:00.0:  
VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0D0B7014
Sep 11 15:26:44 tanith kernel: amdgpu :0c:00.0: VM fault (0x14, vmid 6) at
page 1074029, write from 'SDM0' (0x53444d30) (183)
Sep 11 15:26:44 tanith kernel: amdgpu :0c:00.0: GPU fault detected: 146
0x0b0ab714
Sep 11 15:26:44 tanith kernel: amdgpu :0c:00.0:  
VM_CONTEXT1_PROTECTION_FAULT_ADDR   0x0010636F
Sep 11 15:26:44 tanith kernel: amdgpu :0c:00.0:  
VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0D0B7014
Sep 11 15:26:44 tanith kernel: amdgpu :0c:00.0: VM fault (0x14, vmid 6) at
page 1074031, write from 'SDM0' (0x53444d30) (183)
Sep 11 15:26:44 tanith kernel: amdgpu :0c:00.0: GPU fault detected: 146
0x0b12b714
Sep 11 15:26:44 tanith kernel: amdgpu :0c:00.0:  
VM_CONTEXT1_PROTECTION_FAULT_ADDR   0x00106372
Sep 11 15:26:44 tanith kernel: amdgpu :0c:00.0:  
VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0D0B7014
Sep 11 15:26:44 tanith kernel: amdgpu :0c:00.0: VM fault (0x14, vmid 6) at
page 1074034, write from 'SDM0' (0x53444d30) (183)
Sep 11 15:26:44 tanith kernel: amdgpu :0c:00.0: GPU fault detected: 146
0x0b12b714
Sep 11 15:26:44 tanith kernel: amdgpu :0c:00.0:  
VM_CONTEXT1_PROTECTION_FAULT_ADDR   0x00106374
Sep 11 15:26:44 tanith kernel: amdgpu :0c:00.0:  
VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0D0B7014
Sep 11 15:26:44 tanith kernel: amdgpu 0

Re: [PATCH] drm/amd/powerplay: remove unnecessary call to memset

[Alex Deucher]

On Mon, Sep 11, 2017 at 8:37 AM, Himanshu Jha
 wrote:
> call to memset to assign 0 value immediately after allocating
> memory with kzalloc is unnecesaary as kzalloc allocates the memory
> filled with 0 value.
>
> Semantic patch used to resolve this issue:
>
> @@
> expression e,e2; constant c;
> statement S;
> @@
>
>   e = kzalloc(e2, c);
>   if(e == NULL) S
> - memset(e, 0, e2);
>
> Signed-off-by: Himanshu Jha 

Applied.

Thanks!

Alex

> ---
>  .../drm/amd/powerplay/hwmgr/process_pptables_v1_0.c  | 20 
> 
>  1 file changed, 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/process_pptables_v1_0.c 
> b/drivers/gpu/drm/amd/powerplay/hwmgr/process_pptables_v1_0.c
> index 84f01fd3..d1af148 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/process_pptables_v1_0.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/process_pptables_v1_0.c
> @@ -173,8 +173,6 @@ static int get_vddc_lookup_table(
> if (NULL == table)
> return -ENOMEM;
>
> -   memset(table, 0x00, table_size);
> -
> table->count = vddc_lookup_pp_tables->ucNumEntries;
>
> for (i = 0; i < vddc_lookup_pp_tables->ucNumEntries; i++) {
> @@ -335,8 +333,6 @@ static int get_valid_clk(
> if (NULL == table)
> return -ENOMEM;
>
> -   memset(table, 0x00, table_size);
> -
> table->count = (uint32_t)clk_volt_pp_table->count;
>
> for (i = 0; i < table->count; i++) {
> @@ -390,8 +386,6 @@ static int get_mclk_voltage_dependency_table(
> if (NULL == mclk_table)
> return -ENOMEM;
>
> -   memset(mclk_table, 0x00, table_size);
> -
> mclk_table->count = (uint32_t)mclk_dep_table->ucNumEntries;
>
> for (i = 0; i < mclk_dep_table->ucNumEntries; i++) {
> @@ -439,8 +433,6 @@ static int get_sclk_voltage_dependency_table(
> if (NULL == sclk_table)
> return -ENOMEM;
>
> -   memset(sclk_table, 0x00, table_size);
> -
> sclk_table->count = (uint32_t)tonga_table->ucNumEntries;
>
> for (i = 0; i < tonga_table->ucNumEntries; i++) {
> @@ -473,8 +465,6 @@ static int get_sclk_voltage_dependency_table(
> if (NULL == sclk_table)
> return -ENOMEM;
>
> -   memset(sclk_table, 0x00, table_size);
> -
> sclk_table->count = (uint32_t)polaris_table->ucNumEntries;
>
> for (i = 0; i < polaris_table->ucNumEntries; i++) {
> @@ -525,8 +515,6 @@ static int get_pcie_table(
> if (pcie_table == NULL)
> return -ENOMEM;
>
> -   memset(pcie_table, 0x00, table_size);
> -
> /*
> * Make sure the number of pcie entries are less than or equal 
> to sclk dpm levels.
> * Since first PCIE entry is for ULV, #pcie has to be <= 
> SclkLevel + 1.
> @@ -567,8 +555,6 @@ static int get_pcie_table(
> if (pcie_table == NULL)
> return -ENOMEM;
>
> -   memset(pcie_table, 0x00, table_size);
> -
> /*
> * Make sure the number of pcie entries are less than or equal 
> to sclk dpm levels.
> * Since first PCIE entry is for ULV, #pcie has to be <= 
> SclkLevel + 1.
> @@ -615,8 +601,6 @@ static int get_cac_tdp_table(
> if (NULL == tdp_table)
> return -ENOMEM;
>
> -   memset(tdp_table, 0x00, table_size);
> -
> hwmgr->dyn_state.cac_dtp_table = kzalloc(table_size, GFP_KERNEL);
>
> if (NULL == hwmgr->dyn_state.cac_dtp_table) {
> @@ -624,8 +608,6 @@ static int get_cac_tdp_table(
> return -ENOMEM;
> }
>
> -   memset(hwmgr->dyn_state.cac_dtp_table, 0x00, table_size);
> -
> if (table->ucRevId < 3) {
> const ATOM_Tonga_PowerTune_Table *tonga_table =
> (ATOM_Tonga_PowerTune_Table *)table;
> @@ -725,8 +707,6 @@ static int get_mm_clock_voltage_table(
> if (NULL == mm_table)
> return -ENOMEM;
>
> -   memset(mm_table, 0x00, table_size);
> -
> mm_table->count = mm_dependency_table->ucNumEntries;
>
> for (i = 0; i < mm_dependency_table->ucNumEntries; i++) {
> --
> 2.7.4
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 102666] amdgpu_vm_bo_invalidate NULL reference in amd-staging-drm-next

[bugzilla-daemon]

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

Bug ID: 102666
   Summary: amdgpu_vm_bo_invalidate NULL reference in
amd-staging-drm-next
   Product: DRI
   Version: DRI git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: b...@basnieuwenhuizen.nl

Created attachment 134171
  --> https://bugs.freedesktop.org/attachment.cgi?id=134171&action=edit
dmesg

I'm getting a 

[  404.518419] BUG: unable to handle kernel NULL pointer dereference at
0220
[  404.518445] IP: amdgpu_vm_bo_invalidate+0x71/0x150 [amdgpu]


when running vulkan cts with 32 processes (with tests that cause OOM removed).

Current linux tip:

commit 2dd9dc59c1419c090b084461165bd8b0adf1fecb (HEAD -> amd-staging-drm-next,
origin/amd-staging-drm-next)
Author: Harry Wentland 
Date:   Thu Aug 31 21:17:05 2017 -0400

drm/amdgpu: Remove unused flip_flags from amdgpu_crtc


It doesn't seem like there is a correlating hang: the card is clocked down and
/sys/kernel/debug/dri/0/amdgpu_fence_info shows no pending fences. However,
eventually some of the CTS processes get stuck, and I can't kill them gdb into
them etc. Probably a pagefault that gets stuck, since fence waiting doesn't
seem to get stuck easily? Either way, not sure if that is related yet.

AFAICT the issue is that vm->root.base.bo is NULL in

if (evicted && bo->tbo.resv == vm->root.base.bo->tbo.resv) {

-- 
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 102666] amdgpu_vm_bo_invalidate NULL reference in amd-staging-drm-next

[bugzilla-daemon]

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

Bas Nieuwenhuizen  changed:

   What|Removed |Added

 Attachment #134171|text/x-log  |text/plain
  mime type||

-- 
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 196845] Freezing of pc in every start or restart of pc, and cpio gpu errors - HP 8570w

[bugzilla-daemon]

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

Zhang Rui (rui.zh...@intel.com) changed:

   What|Removed |Added

 CC||rui.zh...@intel.com
  Component|Other   |Video(DRI - non Intel)
   Assignee|kristen.c.acca...@intel.com |drivers_video-dri@kernel-bu
   ||gs.osdl.org
Product|Power Management|Drivers

-- 
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 99710] [amdgpu R9 390] GPU hang when playing Hearthstone in Wine

[bugzilla-daemon]

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

--- Comment #11 from garththei...@hotmail.com ---
(In reply to Sandeep from comment #10)
> I tried the 4.11.0 kernel since I suspected that the buggy change might also
> be present in the point releases, but that also caused a hang whenplaying
> Left 4 Dead 2. Will try older kernels and see if they work correctly (which
> they should since this hang definitely wasn't present 2 months ago).

Yep, Sandeep, I think this behaviour is tied to DPM issues highlighted in Bug
91880 : 'Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly
performing'. I suggest following, reading, and commenting on that issue.

-- 
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 00/10] drm/exynos: TV path improvements

[Andrzej Hajda]

On 11.09.2017 15:54, Tobias Jakobi wrote:
> Hello Andrzej,
>
> just did a quick test and looks good so far. One thing I noticed is that
> compared to Daniel's approach you just manipulate HDMI_TG_HACT_{ST,SZ}_L,
> instead of HDMI_TG_VACT_SZ_L + HDMI_TG_HACT_{ST,SZ}_L. I just wanted to make
> sure that on the HDMI level, this does the same thing?

With Daniel's patch 1st line and the last column are missing.
With this patch 1st line is distorted, last column is OK, IMO better result.
Another alternative I see is to hide 1st line and make all columns OK,
but I am not really convinced to it, but it is just my feelings :)

Btw, I have also played with 800x600, but I was not able to find good
timings - HBLANK is too small.
There are also other resolutions which one can try to fix. Especially
after adding more clocks to HDMI-PHY.

Regards
Andrzej



>
> I'll try to do a proper review tomorrow.
>
> I also noticed that I have another patch by Daniel in my tree, which, together
> with the quirk, enables 1366x768@60Hz. Going to send it shortly, since it 
> could
> probably go along with this series.
>
> With best wishes,
> Tobias
>
>
>
> Andrzej Hajda wrote:
>> Hi all,
>>
>> This patchset does two main things:
>> - removes mode limitation for Exynos542x chips, multiple modes were filtered
>>   out due to lack of HW version checking code,
>> - enables two modes on older chips, thanks to quirk found by Daniel Drake,
>>   and published by Tobias Jakobi [1][2].
>> Beside this it consolidates the code and performs multiple cleanups.
>>
>> [1]: http://www.spinics.net/lists/linux-samsung-soc/msg24617.html
>> [2]: https://www.spinics.net/lists/dri-devel/msg150906.html
>>
>> Regards
>> Andrzej
>>
>>
>> Andrzej Hajda (10):
>>   drm/exynos/mixer: abstract out output mode setup code
>>   drm/exynos/mixer: move mode commit to enable callback
>>   drm/exynos/mixer: move resolution configuration to single function
>>   drm/exynos/mixer: fix mode validation code
>>   drm/exynos/mixer: remove mixer_resources sub-structure
>>   drm/exynos/hdmi: remove redundant mode field
>>   drm/exynos: add mode_fixup callback to exynos_drm_crtc_ops
>>   drm/exynos/mixer: pass actual mode on MIXER to encoder
>>   drm/exynos/hdmi: quirk for support mode timings conversion
>>   drm/exynos/mixer: enable support for 1024x768 and 1280x1024 modes
>>
>>  drivers/gpu/drm/exynos/exynos_drm_crtc.c |  15 +
>>  drivers/gpu/drm/exynos/exynos_drm_drv.h  |   3 +
>>  drivers/gpu/drm/exynos/exynos_hdmi.c |  49 ++--
>>  drivers/gpu/drm/exynos/exynos_mixer.c| 452 
>> +++
>>  4 files changed, 265 insertions(+), 254 deletions(-)
>>
>
>
>

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

Re: [PATCH v3 2/3] drm: add fallback default device detection

[Andrew Donnellan]

On 01/09/17 17:27, Daniel Axtens wrote:

The VGA arbiter selects a default VGA device that is enabled and
reachable via the legacy VGA resources (mem 0xa-0xb, io
0x3b0-0x3bb, io 0x3c0-0x3df, etc).

(As a special case for x86 and IA64, this can be overridden by
EFI.)

If there is no such device, e.g., because there's no enabled VGA
device, the host bridge doesn't support access to those legacy
resources, or a PCI-PCI bridge doesn't have VGA Enable set, a
platform may select an arbitrary device by calling
pci_set_default_display(). powerpc does this, for example.

If there is also no platform hook, there will be no default
device nominated. This is not necessarily what we want.

Add handling for devices that aren't handled by the vga arbiter or
platform by adding a late initcall and a class enable hook. If there
is no default from vgaarb or the platform then the first VGA card
that is enabled, has a driver bound, and can decode memory or I/O
will be marked as default.

This means single-card setups on systems without access to legacy
areas and without arch hooks will work. Multi-card setups on these
systems will nominate an arbitrary device, rather than no devices.

Signed-off-by: Daniel Axtens 

---

v3:

Split out from re-organisation for simplicity.
Add better description and better documentaion.

Thanks to (in no particular order), Daniel Vetter, Lorenzo Pieralisi,
Ard Biesheuvel and Dave Airlie. Special thanks to Ben Herrenschmidt
and Bjorn Helgass, whose prose I have borrowed.

v1:

Tested on:
  - x86_64 laptop
  - arm64 D05 board with hibmc card
  - qemu powerpc with tcg and bochs std-vga

I know this adds another config option and that's a bit sad, but
we can't include it unconditionally as it depends on PCI.
Suggestions welcome.


Tested on our iMac G5, the fallback handler doesn't fire (which should 
be correct).


Tested-by: Andrew Donnellan 


+static void vga_default_enable_hook(struct pci_dev *pdev)
+{
+   if (!vga_default_active)
+  return;
+
+   if (pci_default_display())
+   return;
+
+   vga_default_try_device(pdev);
+}
+DECLARE_PCI_FIXUP_CLASS_ENABLE(PCI_ANY_ID, PCI_ANY_ID,
+  PCI_CLASS_DISPLAY_VGA, 8,
+  vga_default_enable_hook)



Looks like you have some spaces/tabs inconsistencies here.

--
Andrew Donnellan  OzLabs, ADL Canberra
andrew.donnel...@au1.ibm.com  IBM Australia Limited

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

Re: [PATCH v3 1/2] drm/bridge: add Silicon Image SiI9234 driver

[Krzysztof Kozlowski]

On Mon, Sep 11, 2017 at 3:39 PM, Marek Szyprowski
 wrote:
> Hi Krzysztof,
>
>
> On 2017-09-11 15:18, Krzysztof Kozlowski wrote:
>>
>> On Mon, Sep 11, 2017 at 1:42 PM, Maciej Purski 
>> wrote:
>
> +   ctx->client[I2C_MHL] = client;
> +
> +   ctx->client[I2C_TPI] = i2c_new_dummy(adapter, I2C_TPI_ADDR);
> +   if (!ctx->client[I2C_TPI]) {
> +   dev_err(ctx->dev, "failed to create TPI client\n");
> +   return -ENODEV;
> +   }
> +
> +   ctx->client[I2C_HDMI] = i2c_new_dummy(adapter, I2C_HDMI_ADDR);
> +   if (!ctx->client[I2C_HDMI]) {
> +   dev_err(ctx->dev, "failed to create HDMI RX client\n");
> +   goto fail_tpi;
> +   }
> +
> +   ctx->client[I2C_CBUS] = i2c_new_dummy(adapter, I2C_CBUS_ADDR);
> +   if (!ctx->client[I2C_CBUS]) {
> +   dev_err(ctx->dev, "failed to create CBUS client\n");
> +   goto fail_hdmi;
> +   }

 You are using i2c_smbus_* calls. Why not converting to regmap_i2c? It is
 preferred interface.
>>>
>>>
>>> According to my search, there are only 5 drivers, which use regmap_i2c
>>> and
>>> none of them in drm. If you think that it is really needed, could you
>>> please
>>> explain
>>> why?
>>
>> There are slightly more than five drivers:
>>
>> $ git grep regmap_init_i2c | wc -l
>> 352
>>
>> ... and even more using regmap interface in generic (not i2c).
>>
>> I think this is really wanted because for free you get:
>> 1. locking,
>> 2. proper locking - with lockdep and nested mutexes :),
>> 3. caching of accesses,
>> 4. handling of endianness,
>> 5. optionally a trivial way of handling interrupts (regmap_irq_chip),
>>
>> Also this brings unified interface for most of the drivers regardless
>> of protocol used beneath (I2C, SPI and even MMIO but for simple cases
>> MMIO might not have much sense). This last argument actually brings
>> the most benefit for me because it abstracts driver from trivial I2C
>> implementation and it could allow even easy code-reuse for e.g. SPI
>> version.
>
>
> Regmap make sense for multi-function chips, which require more than one
> client driver (so proper locking is important). It also makes sense if
> the chip is produced in more than one flavor (like i2c, spi, MMIO, etc).
>
> None of the above takes place in this case... So in case of this driver
> using regmap is IMHO an over-engineering.

Good points and true that setting up regmap requires some more code
around probe. However it will remove half or even more of your
interrupt handler. Less driver specific code, more generic code used.
Also current code around I2C (sii9234_writeb() etc) is not thread
safe... which for now is not a problem as the only entrance point is
the interrupt. Maybe it's fine then to use existing implementation
especially if you do not see any future enhancements to the driver.

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

[PATCH] drm/amd/powerplay: remove unnecessary call to memset

[Himanshu Jha]

call to memset to assign 0 value immediately after allocating
memory with kzalloc is unnecesaary as kzalloc allocates the memory
filled with 0 value.

Semantic patch used to resolve this issue:

@@
expression e,e2; constant c;
statement S;
@@

  e = kzalloc(e2, c);
  if(e == NULL) S
- memset(e, 0, e2);

Signed-off-by: Himanshu Jha 
---
 .../drm/amd/powerplay/hwmgr/process_pptables_v1_0.c  | 20 
 1 file changed, 20 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/process_pptables_v1_0.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/process_pptables_v1_0.c
index 84f01fd3..d1af148 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/process_pptables_v1_0.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/process_pptables_v1_0.c
@@ -173,8 +173,6 @@ static int get_vddc_lookup_table(
if (NULL == table)
return -ENOMEM;
 
-   memset(table, 0x00, table_size);
-
table->count = vddc_lookup_pp_tables->ucNumEntries;
 
for (i = 0; i < vddc_lookup_pp_tables->ucNumEntries; i++) {
@@ -335,8 +333,6 @@ static int get_valid_clk(
if (NULL == table)
return -ENOMEM;
 
-   memset(table, 0x00, table_size);
-
table->count = (uint32_t)clk_volt_pp_table->count;
 
for (i = 0; i < table->count; i++) {
@@ -390,8 +386,6 @@ static int get_mclk_voltage_dependency_table(
if (NULL == mclk_table)
return -ENOMEM;
 
-   memset(mclk_table, 0x00, table_size);
-
mclk_table->count = (uint32_t)mclk_dep_table->ucNumEntries;
 
for (i = 0; i < mclk_dep_table->ucNumEntries; i++) {
@@ -439,8 +433,6 @@ static int get_sclk_voltage_dependency_table(
if (NULL == sclk_table)
return -ENOMEM;
 
-   memset(sclk_table, 0x00, table_size);
-
sclk_table->count = (uint32_t)tonga_table->ucNumEntries;
 
for (i = 0; i < tonga_table->ucNumEntries; i++) {
@@ -473,8 +465,6 @@ static int get_sclk_voltage_dependency_table(
if (NULL == sclk_table)
return -ENOMEM;
 
-   memset(sclk_table, 0x00, table_size);
-
sclk_table->count = (uint32_t)polaris_table->ucNumEntries;
 
for (i = 0; i < polaris_table->ucNumEntries; i++) {
@@ -525,8 +515,6 @@ static int get_pcie_table(
if (pcie_table == NULL)
return -ENOMEM;
 
-   memset(pcie_table, 0x00, table_size);
-
/*
* Make sure the number of pcie entries are less than or equal 
to sclk dpm levels.
* Since first PCIE entry is for ULV, #pcie has to be <= 
SclkLevel + 1.
@@ -567,8 +555,6 @@ static int get_pcie_table(
if (pcie_table == NULL)
return -ENOMEM;
 
-   memset(pcie_table, 0x00, table_size);
-
/*
* Make sure the number of pcie entries are less than or equal 
to sclk dpm levels.
* Since first PCIE entry is for ULV, #pcie has to be <= 
SclkLevel + 1.
@@ -615,8 +601,6 @@ static int get_cac_tdp_table(
if (NULL == tdp_table)
return -ENOMEM;
 
-   memset(tdp_table, 0x00, table_size);
-
hwmgr->dyn_state.cac_dtp_table = kzalloc(table_size, GFP_KERNEL);
 
if (NULL == hwmgr->dyn_state.cac_dtp_table) {
@@ -624,8 +608,6 @@ static int get_cac_tdp_table(
return -ENOMEM;
}
 
-   memset(hwmgr->dyn_state.cac_dtp_table, 0x00, table_size);
-
if (table->ucRevId < 3) {
const ATOM_Tonga_PowerTune_Table *tonga_table =
(ATOM_Tonga_PowerTune_Table *)table;
@@ -725,8 +707,6 @@ static int get_mm_clock_voltage_table(
if (NULL == mm_table)
return -ENOMEM;
 
-   memset(mm_table, 0x00, table_size);
-
mm_table->count = mm_dependency_table->ucNumEntries;
 
for (i = 0; i < mm_dependency_table->ucNumEntries; i++) {
-- 
2.7.4

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

[PATCH] drm/amdgpu: revert tile table update for oland

[Jean Delvare]

Several users have complained that the tile table update broke Oland
support. Despite several attempts to fix it, the root cause is still
unknown at this point and no solution is available. As it is not
acceptable to leave a known regression breaking a major functionality
in the kernel for several releases, let's just reverse this
optimization for now. It can be implemented again later if and only
if the breakage is understood and fixed.

As there were no complaints for Hainan so far, only the Oland part of
the offending commit is reverted. Optimization is preserved on
Hainan, so this commit isn't an actual revert of the original.

This fixes bug #194761:
https://bugzilla.kernel.org/show_bug.cgi?id=194761

Signed-off-by: Jean Delvare 
Fixes: f8d9422ef80c ("drm/amdgpu: update tile table for oland/hainan")
Cc: Flora Cui 
Cc: Junwei Zhang 
Cc: Alex Deucher 
Cc: Marek Olšák 
---
This version of the fix is suitable for kernels v4.13 and up.
I'm running it for some time now it works perfectly on my
Radeon R5 240 (Dell OEM):
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. 
[AMD/ATI] Oland [Radeon HD 8570 / R7 240/340 OEM] [1002:6611]

 drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c |  189 +-
 1 file changed, 188 insertions(+), 1 deletion(-)

--- linux-4.13.orig/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c   2017-09-11 
17:33:30.103176910 +0200
+++ linux-4.13/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c2017-09-11 
17:40:12.711316976 +0200
@@ -636,7 +636,194 @@ static void gfx_v6_0_tiling_mode_table_i
NUM_BANKS(ADDR_SURF_2_BANK);
for (reg_offset = 0; reg_offset < num_tile_mode_states; 
reg_offset++)
WREG32(mmGB_TILE_MODE0 + reg_offset, 
tilemode[reg_offset]);
-   } else if (adev->asic_type == CHIP_OLAND || adev->asic_type == 
CHIP_HAINAN) {
+   } else if (adev->asic_type == CHIP_OLAND) {
+   tilemode[0] =   MICRO_TILE_MODE(ADDR_SURF_DEPTH_MICRO_TILING) |
+   ARRAY_MODE(ARRAY_2D_TILED_THIN1) |
+   PIPE_CONFIG(ADDR_SURF_P4_8x16) |
+   TILE_SPLIT(ADDR_SURF_TILE_SPLIT_64B) |
+   NUM_BANKS(ADDR_SURF_16_BANK) |
+   BANK_WIDTH(ADDR_SURF_BANK_WIDTH_1) |
+   BANK_HEIGHT(ADDR_SURF_BANK_HEIGHT_4) |
+   MACRO_TILE_ASPECT(ADDR_SURF_MACRO_ASPECT_4);
+   tilemode[1] =   MICRO_TILE_MODE(ADDR_SURF_DEPTH_MICRO_TILING) |
+   ARRAY_MODE(ARRAY_2D_TILED_THIN1) |
+   PIPE_CONFIG(ADDR_SURF_P4_8x16) |
+   TILE_SPLIT(ADDR_SURF_TILE_SPLIT_128B) |
+   NUM_BANKS(ADDR_SURF_16_BANK) |
+   BANK_WIDTH(ADDR_SURF_BANK_WIDTH_1) |
+   BANK_HEIGHT(ADDR_SURF_BANK_HEIGHT_4) |
+   MACRO_TILE_ASPECT(ADDR_SURF_MACRO_ASPECT_4);
+   tilemode[2] =   MICRO_TILE_MODE(ADDR_SURF_DEPTH_MICRO_TILING) |
+   ARRAY_MODE(ARRAY_2D_TILED_THIN1) |
+   PIPE_CONFIG(ADDR_SURF_P4_8x16) |
+   TILE_SPLIT(ADDR_SURF_TILE_SPLIT_256B) |
+   NUM_BANKS(ADDR_SURF_16_BANK) |
+   BANK_WIDTH(ADDR_SURF_BANK_WIDTH_1) |
+   BANK_HEIGHT(ADDR_SURF_BANK_HEIGHT_4) |
+   MACRO_TILE_ASPECT(ADDR_SURF_MACRO_ASPECT_4);
+   tilemode[3] =   MICRO_TILE_MODE(ADDR_SURF_DEPTH_MICRO_TILING) |
+   ARRAY_MODE(ARRAY_2D_TILED_THIN1) |
+   PIPE_CONFIG(ADDR_SURF_P4_8x16) |
+   TILE_SPLIT(ADDR_SURF_TILE_SPLIT_128B) |
+   NUM_BANKS(ADDR_SURF_16_BANK) |
+   BANK_WIDTH(ADDR_SURF_BANK_WIDTH_1) |
+   BANK_HEIGHT(ADDR_SURF_BANK_HEIGHT_4) |
+   MACRO_TILE_ASPECT(ADDR_SURF_MACRO_ASPECT_4);
+   tilemode[4] =   MICRO_TILE_MODE(ADDR_SURF_DEPTH_MICRO_TILING) |
+   ARRAY_MODE(ARRAY_1D_TILED_THIN1) |
+   PIPE_CONFIG(ADDR_SURF_P4_8x16) |
+   TILE_SPLIT(ADDR_SURF_TILE_SPLIT_64B) |
+   NUM_BANKS(ADDR_SURF_16_BANK) |
+   BANK_WIDTH(ADDR_SURF_BANK_WIDTH_1) |
+   BANK_HEIGHT(ADDR_SURF_BANK_HEIGHT_2) |
+   MACRO_TILE_ASPECT(ADDR_SURF_MACRO_ASPECT_2);
+   tilemode[5] =   MICRO_TILE_MODE(ADDR_SURF_DEPTH_MICRO_TILING) |
+   ARRAY_MODE(ARRAY_2D_TILED_THIN1) |
+   PIPE_CONFIG(ADDR_SURF_P4_8x16) |
+   TILE_SP

Re: [PATCH v3 1/2] drm/bridge: add Silicon Image SiI9234 driver

[Krzysztof Kozlowski]

On Mon, Sep 11, 2017 at 1:42 PM, Maciej Purski  wrote:
>>> +   ctx->client[I2C_MHL] = client;
>>> +
>>> +   ctx->client[I2C_TPI] = i2c_new_dummy(adapter, I2C_TPI_ADDR);
>>> +   if (!ctx->client[I2C_TPI]) {
>>> +   dev_err(ctx->dev, "failed to create TPI client\n");
>>> +   return -ENODEV;
>>> +   }
>>> +
>>> +   ctx->client[I2C_HDMI] = i2c_new_dummy(adapter, I2C_HDMI_ADDR);
>>> +   if (!ctx->client[I2C_HDMI]) {
>>> +   dev_err(ctx->dev, "failed to create HDMI RX client\n");
>>> +   goto fail_tpi;
>>> +   }
>>> +
>>> +   ctx->client[I2C_CBUS] = i2c_new_dummy(adapter, I2C_CBUS_ADDR);
>>> +   if (!ctx->client[I2C_CBUS]) {
>>> +   dev_err(ctx->dev, "failed to create CBUS client\n");
>>> +   goto fail_hdmi;
>>> +   }
>>
>> You are using i2c_smbus_* calls. Why not converting to regmap_i2c? It is
>> preferred interface.
>
>
> According to my search, there are only 5 drivers, which use regmap_i2c and
> none of them in drm. If you think that it is really needed, could you please
> explain
> why?

There are slightly more than five drivers:

$ git grep regmap_init_i2c | wc -l
352

... and even more using regmap interface in generic (not i2c).

I think this is really wanted because for free you get:
1. locking,
2. proper locking - with lockdep and nested mutexes :),
3. caching of accesses,
4. handling of endianness,
5. optionally a trivial way of handling interrupts (regmap_irq_chip),

Also this brings unified interface for most of the drivers regardless
of protocol used beneath (I2C, SPI and even MMIO but for simple cases
MMIO might not have much sense). This last argument actually brings
the most benefit for me because it abstracts driver from trivial I2C
implementation and it could allow even easy code-reuse for e.g. SPI
version.


>>
>>> +
>>> +   return 0;
>>> +
>>> +fail_hdmi:
>>> +   i2c_unregister_device(ctx->client[I2C_HDMI]);
>>> +fail_tpi:
>>> +   i2c_unregister_device(ctx->client[I2C_TPI]);
>>> +
>>> +   return -ENODEV;
>>> +}
>>> +
>>> +static void sii9234_deinit_resources(struct sii9234 *ctx)
>>> +{
>>> +   i2c_unregister_device(ctx->client[I2C_CBUS]);
>>> +   i2c_unregister_device(ctx->client[I2C_HDMI]);
>>> +   i2c_unregister_device(ctx->client[I2C_TPI]);
>>> +}
>>> +
>>> +static inline struct sii9234 *bridge_to_sii9234(struct drm_bridge
>>> *bridge)
>>> +{
>>> +   return container_of(bridge, struct sii9234, bridge);
>>> +}
>>> +
>>> +static enum drm_mode_status sii9234_mode_valid(struct drm_bridge
>>> *bridge,
>>> +   const struct drm_display_mode
>>> *mode)
>>> +{
>>> +   if (mode->clock > MHL1_MAX_CLK)
>>> +   return MODE_CLOCK_HIGH;
>>> +
>>> +   return MODE_OK;
>>> +}
>>> +
>>> +static const struct drm_bridge_funcs sii9234_bridge_funcs = {
>>> +   .mode_valid = sii9234_mode_valid,
>>> +};
>>> +
>>> +static int sii9234_probe(struct i2c_client *client,
>>> + const struct i2c_device_id
>>> *id)
>>> +{
>>> +   struct i2c_adapter *adapter = to_i2c_adapter(client->dev.parent);
>>> +   struct sii9234 *ctx;
>>> +   struct device *dev = &client->dev;
>>> +   int ret;
>>> +
>>> +   ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
>>> +   if (!ctx)
>>> +   return -ENOMEM;
>>> +
>>> +   ctx->dev = dev;
>>> +   mutex_init(&ctx->lock);
>>> +
>>> +   if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_BYTE_DATA))
>>> {
>>> +   dev_err(dev, "I2C adapter lacks SMBUS feature\n");
>>> +   return -EIO;
>>> +   }
>>> +
>>> +   if (!client->irq) {
>>> +   dev_err(dev, "no irq provided\n");
>>> +   return -EINVAL;
>>> +   }
>>> +
>>> +   irq_set_status_flags(client->irq, IRQ_NOAUTOEN);
>>> +   ret = devm_request_threaded_irq(dev, client->irq, NULL,
>>> +   sii9234_irq_thread,
>>> +   IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
>>> +   "sii9234", ctx);
>>> +   if (ret < 0) {
>>> +   dev_err(dev, "failed to install IRQ handler\n");
>>> +   return ret;
>>> +   }
>>
>> You are setting up interrupts before initialization of I2C. Can the
>> interrupt happen in this short window?
>
>
> It can't happen, because in the previous line there is a status flag set to
> IRQ_NOAUTOEN. IRQs are enabled in sii9234_cable_in() function which is
> called after initialization of I2C.

Ah, okay, I missed that. Thanks!

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