Re: [RFC v2 2/2] dt-bindings: mipi-dsi: Add dual-channel DSI related info

[Archit Taneja]

On Monday 04 June 2018 05:47 PM, Heiko Stuebner wrote:

Am Donnerstag, 18. Januar 2018, 05:53:55 CEST schrieb Archit Taneja:

Add binding info for peripherals that support dual-channel DSI. Add
corresponding optional bindings for DSI host controllers that may
be configured in this mode. Add an example of an I2C controlled
device operating in dual-channel DSI mode.

Signed-off-by: Archit Taneja 


Looks like a great solution for that problem, so
Reviewed-by: Heiko Stuebner 

As I'm looking into that for my rk3399-scarlet device right now and
couldn't find this patchset in the kernel yet, is it planned to
merge or refresh these binding changes or were problems encountered.

At least an Ack/Review from Rob seems to be missing.



I forgot about these patches. Rob had reviewed the first one in
the set the second one still needed an Ack. I'll post a v3
that adds the Reviewed-bys and fixes a small typo.

Archit



Heiko


---
v2:
- Specify that clock-master is a boolean property.
- Drop/add unit-address and #*-cells where applicable.

  .../devicetree/bindings/display/mipi-dsi-bus.txt   | 80 ++
  1 file changed, 80 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt 
b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
index 94fb72cb916f..7a3abbedb3fa 100644
--- a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
+++ b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
@@ -29,6 +29,13 @@ Required properties:
  - #size-cells: Should be 0. There are cases where it makes sense to use a
different value here. See below.
  
+Optional properties:

+- clock-master: boolean. Should be enabled if the host is being used in
+  conjunction with another DSI host to drive the same peripheral. Hardware
+  supporting such a configuration generally requires the data on both the 
busses
+  to be driven by the same clock. Only the DSI host instance controlling this
+  clock should contain this property.
+
  DSI peripheral
  ==
  
@@ -62,6 +69,16 @@ primary control bus, but are also connected to a DSI bus (mostly for the data

  path). Connections between such peripherals and a DSI host can be represented
  using the graph bindings [1], [2].
  
+Peripherals that support dual channel DSI

+-
+
+Peripherals with higher bandwidth requirements can be connected to 2 DSI
+busses. Each DSI bus/channel drives some portion of the pixel data (generally
+left/right half of each line of the display, or even/odd lines of the display).
+The graph bindings should be used to represent the multiple DSI busses that are
+connected to this peripheral. Each DSI host's output endpoint can be linked to
+an input endpoint of the DSI peripheral.
+
  [1] Documentation/devicetree/bindings/graph.txt
  [2] Documentation/devicetree/bindings/media/video-interfaces.txt
  
@@ -71,6 +88,8 @@ Examples

with different virtual channel configurations.
  - (4) is an example of a peripheral on a I2C control bus connected with to
a DSI host using of-graph bindings.
+- (5) is an example of 2 DSI hosts driving a dual-channel DSI peripheral,
+  which uses I2C as its primary control bus.
  
  1)

dsi-host {
@@ -153,3 +172,64 @@ Examples
};
};
};
+
+5)
+   i2c-host {
+   dsi-bridge@35 {
+   compatible = "...";
+   reg = <0x35>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   dsi0_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+   dsi1_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
+   };
+   };
+
+   dsi0-host {
+   ...
+
+   /*
+* this DSI instance drives the clock for both the host
+* controllers
+*/
+   clock-master;
+
+   ports {
+   ...
+
+   port {
+   dsi0_out: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+   };
+
+   dsi1-host {
+   ...
+
+   ports {
+   ...
+
+   port {
+   dsi1_out: endpoint {
+ 

[Bug 106827] Segmentation fault in i915_validate_state on SolveSpace startup

[bugzilla-daemon]

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

--- Comment #2 from Paul Fertser  ---
As an additional datapoint, DRI (non-Gallium) driver from the same tree works
without problems.

-- 
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 106533] r300_dri.so SIGSEGV in llvm_pipeline_generic under Cinnamon

[bugzilla-daemon]

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

--- Comment #12 from Marek Olšák  ---
17.x branches are no longer supported (and 18.0 is uncertain). Users and
distros are encouraged to switch to Mesa 18.1 if they want to obtain future
fixes.

-- 
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 106289] mupen64plus segfaults deep inside r300_dri.so

[bugzilla-daemon]

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

--- Comment #3 from Anthony Ciani  ---
Check out bug 106533.  It was also a SEGV in llvm_pipeline_generic.  There is a
patch.

-- 
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 106533] r300_dri.so SIGSEGV in llvm_pipeline_generic under Cinnamon

[bugzilla-daemon]

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

--- Comment #11 from Anthony Ciani  ---
Thanks.  That patch resolved the issue with clear_with_quad and Cinnamon as
well.  

While I was looking at the source, I did notice that many of the functions
assumed that their inputs were valid.  I was speculating that clear_with_quad
may have calculated a zero or even negative number of elements and passed that
along to draw_pt_arrays, which would have passed a NULL array or negative index
to llvm.

You might want to apply that patch to the 17.1, 17.2 and 17.3 branches as well.
 While researching this bug I saw several posts from people having llvm
problems on Radeon hardware with Fedora and Ubuntu versions based on the 17.x
branches.

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

[DPU PATCH v2 6/7] drm/msm: remove msm_prop files

[Jeykumar Sankaran]

Remove hand rolled msm property caching to handle DPU
custom properties. This change also cleans up all its
dependencies to cache and restore respective drm
states.

changs in v2:
- none

Signed-off-by: Jeykumar Sankaran 
Reviewed-by: Sean Paul 
---
 drivers/gpu/drm/msm/Makefile  |   1 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c |   2 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c  | 239 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h  |  16 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h   |   2 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 123 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h |  12 -
 drivers/gpu/drm/msm/msm_drv.h |  16 +-
 drivers/gpu/drm/msm/msm_prop.c| 688 --
 drivers/gpu/drm/msm/msm_prop.h| 438 
 10 files changed, 8 insertions(+), 1529 deletions(-)
 delete mode 100644 drivers/gpu/drm/msm/msm_prop.c
 delete mode 100644 drivers/gpu/drm/msm/msm_prop.h

diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index d289503..5331188 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -76,7 +76,6 @@ msm-y := \
dpu_io_util.o \
dpu_dbg_evtlog.o \
dpu_power_handle.o \
-   msm_prop.o \
msm_atomic.o \
msm_debugfs.o \
msm_drv.o \
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
index c4820de..e4b82d5 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
@@ -19,8 +19,6 @@
 #include 
 #include 
 
-#include "msm_prop.h"
-
 #include "dpu_kms.h"
 #include "dpu_trace.h"
 #include "dpu_crtc.h"
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 0c25c45..dd8c91e 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -579,10 +579,6 @@ static void dpu_crtc_destroy(struct drm_crtc *crtc)
if (!crtc)
return;
 
-   if (dpu_crtc->blob_info)
-   drm_property_blob_put(dpu_crtc->blob_info);
-   msm_property_destroy(_crtc->property_info);
-
_dpu_crtc_deinit_events(dpu_crtc);
 
drm_crtc_cleanup(crtc);
@@ -1341,9 +1337,7 @@ static void dpu_crtc_destroy_state(struct drm_crtc *crtc,
 
__drm_atomic_helper_crtc_destroy_state(state);
 
-   /* destroy value helper */
-   msm_property_destroy_state(_crtc->property_info, cstate,
-   >property_state);
+   kfree(cstate);
 }
 
 static int _dpu_crtc_wait_for_frame_done(struct drm_crtc *crtc)
@@ -1592,17 +1586,12 @@ static struct drm_crtc_state 
*dpu_crtc_duplicate_state(struct drm_crtc *crtc)
 
dpu_crtc = to_dpu_crtc(crtc);
old_cstate = to_dpu_crtc_state(crtc->state);
-   cstate = msm_property_alloc_state(_crtc->property_info);
+   cstate = kmemdup(old_cstate, sizeof(*old_cstate), GFP_KERNEL);
if (!cstate) {
DPU_ERROR("failed to allocate state\n");
return NULL;
}
 
-   /* duplicate value helper */
-   msm_property_duplicate_state(_crtc->property_info,
-   old_cstate, cstate,
-   >property_state, cstate->property_values);
-
/* duplicate base helper */
__drm_atomic_helper_crtc_duplicate_state(crtc, >base);
 
@@ -1638,17 +1627,12 @@ static void dpu_crtc_reset(struct drm_crtc *crtc)
}
 
dpu_crtc = to_dpu_crtc(crtc);
-   cstate = msm_property_alloc_state(_crtc->property_info);
+   cstate = kzalloc(sizeof(*cstate), GFP_KERNEL);
if (!cstate) {
DPU_ERROR("failed to allocate state\n");
return;
}
 
-   /* reset value helper */
-   msm_property_reset_state(_crtc->property_info, cstate,
-   >property_state,
-   cstate->property_values);
-
_dpu_crtc_rp_reset(>rp, _crtc->rp_lock,
_crtc->rp_head);
 
@@ -2145,212 +2129,6 @@ void dpu_crtc_cancel_pending_flip(struct drm_crtc 
*crtc, struct drm_file *file)
_dpu_crtc_complete_flip(crtc, file);
 }
 
-/**
- * dpu_crtc_install_properties - install all drm properties for crtc
- * @crtc: Pointer to drm crtc structure
- */
-static void dpu_crtc_install_properties(struct drm_crtc *crtc,
-   struct dpu_mdss_cfg *catalog)
-{
-   struct dpu_crtc *dpu_crtc;
-   struct drm_device *dev;
-   struct dpu_kms_info *info;
-   struct dpu_kms *dpu_kms;
-
-   DPU_DEBUG("\n");
-
-   if (!crtc || !catalog) {
-   DPU_ERROR("invalid crtc or catalog\n");
-   return;
-   }
-
-   dpu_crtc = to_dpu_crtc(crtc);
-   dev = crtc->dev;
-   dpu_kms = _dpu_crtc_get_kms(crtc);
-
-   if (!dpu_kms) {
-   DPU_ERROR("invalid argument\n");
-   

[DPU PATCH v2 7/7] drm/msm: remove dpu specific uapi header

[Jeykumar Sankaran]

remove unwanted dpu uapi headers exposing custom
payload layouts for custom properties

changs in v2:
- none

Signed-off-by: Jeykumar Sankaran 
Reviewed-by: Sean Paul 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h  |   1 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c |   1 -
 include/uapi/drm/dpu_drm.h| 220 ---
 include/uapi/drm/msm_drm_pp.h | 345 --
 4 files changed, 567 deletions(-)
 delete mode 100644 include/uapi/drm/dpu_drm.h
 delete mode 100644 include/uapi/drm/msm_drm_pp.h

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
index f752101..9c89102 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
@@ -20,7 +20,6 @@
 #define _DPU_CRTC_H_
 
 #include 
-#include 
 #include 
 #include "dpu_kms.h"
 #include "dpu_core_perf.h"
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
index 830b69e..5b4d529 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
@@ -10,7 +10,6 @@
  * GNU General Public License for more details.
  */
 
-#include 
 #include "dpu_kms.h"
 #include "dpu_hw_catalog.h"
 #include "dpu_hwio.h"
diff --git a/include/uapi/drm/dpu_drm.h b/include/uapi/drm/dpu_drm.h
deleted file mode 100644
index 93af1fb..000
--- a/include/uapi/drm/dpu_drm.h
+++ /dev/null
@@ -1,220 +0,0 @@
-#ifndef _DPU_DRM_H_
-#define _DPU_DRM_H_
-
-#include "drm.h"
-
-/* Total number of supported color planes */
-#define DPU_MAX_PLANES  4
-
-/* Total number of parameterized detail enhancer mapping curves */
-#define DPU_MAX_DE_CURVES 3
-
- /* Y/RGB and UV filter configuration */
-#define FILTER_EDGE_DIRECTED_2D0x0
-#define FILTER_CIRCULAR_2D 0x1
-#define FILTER_SEPARABLE_1D0x2
-#define FILTER_BILINEAR0x3
-
-/* Alpha filters */
-#define FILTER_ALPHA_DROP_REPEAT   0x0
-#define FILTER_ALPHA_BILINEAR  0x1
-#define FILTER_ALPHA_2D0x3
-
-/* Blend filters */
-#define FILTER_BLEND_CIRCULAR_2D   0x0
-#define FILTER_BLEND_SEPARABLE_1D  0x1
-
-/* LUT configuration flags */
-#define SCALER_LUT_SWAP0x1
-#define SCALER_LUT_DIR_WR  0x2
-#define SCALER_LUT_Y_CIR_WR0x4
-#define SCALER_LUT_UV_CIR_WR   0x8
-#define SCALER_LUT_Y_SEP_WR0x10
-#define SCALER_LUT_UV_SEP_WR   0x20
-
-/**
- * Blend operations for "blend_op" property
- *
- * @DPU_DRM_BLEND_OP_NOT_DEFINED:   No blend operation defined for the layer.
- * @DPU_DRM_BLEND_OP_OPAQUE:Apply a constant blend operation. The layer
- *  would appear opaque in case fg plane alpha
- *  is 0xff.
- * @DPU_DRM_BLEND_OP_PREMULTIPLIED: Apply source over blend rule. Layer already
- *  has alpha pre-multiplication done. If the 
fg
- *  plane alpha is less than 0xff, apply
- *  modulation as well. This operation is
- *  intended on layers having alpha channel.
- * @DPU_DRM_BLEND_OP_COVERAGE:  Apply source over blend rule. Layer is not
- *  alpha pre-multiplied. Apply
- *  pre-multiplication. If fg plane alpha is
- *  less than 0xff, apply modulation as well.
- * @DPU_DRM_BLEND_OP_MAX:   Used to track maximum blend operation
- *  possible by mdp.
- */
-#define DPU_DRM_BLEND_OP_NOT_DEFINED0
-#define DPU_DRM_BLEND_OP_OPAQUE 1
-#define DPU_DRM_BLEND_OP_PREMULTIPLIED  2
-#define DPU_DRM_BLEND_OP_COVERAGE   3
-#define DPU_DRM_BLEND_OP_MAX4
-
-/**
- * Bit masks for "src_config" property
- * construct bitmask via (1UL << DPU_DRM_)
- */
-#define DPU_DRM_DEINTERLACE 0   /* Specifies interlaced input */
-
-/* DRM bitmasks are restricted to 0..63 */
-#define DPU_DRM_BITMASK_COUNT   64
-
-/* Number of dest scalers supported */
-#define DPU_MAX_DS_COUNT 2
-
-/*
- * Destination scaler flag config
- */
-#define DPU_DRM_DESTSCALER_ENABLE   0x1
-#define DPU_DRM_DESTSCALER_SCALE_UPDATE 0x2
-#define DPU_DRM_DESTSCALER_ENHANCER_UPDATE  0x4
-#define DPU_DRM_DESTSCALER_PU_ENABLE0x8
-
-/**
- * struct dpu_drm_dest_scaler_cfg - destination scaler config structure
- * @flags:  Flag to switch between mode for destination scaler
- *  refer to destination scaler flag config
- * @index:  Destination scaler selection index
- * @lm_width:   Layer mixer width configuration
- * @lm_height:  Layer mixer height configuration
- * @scaler_cfg: The scaling parameters for all the mode except disable
- *  Userspace pointer to struct dpu_drm_scaler_v2
- */
-struct 

[DPU PATCH v2 3/7] drm/msm: enable zpos normalization

[Jeykumar Sankaran]

Enable drm core zpos normalization for planes.

changes in v2:
- none

Signed-off-by: Jeykumar Sankaran 
Reviewed-by: Sean Paul 
---
 drivers/gpu/drm/msm/msm_drv.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index ebc40a9..549359e 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -592,6 +592,9 @@ static int msm_drm_init(struct device *dev, struct 
drm_driver *drv)
ddev->mode_config.funcs = _config_funcs;
ddev->mode_config.helper_private = _config_helper_funcs;
 
+   /* Enable normalization of plane zpos */
+   ddev->mode_config.normalize_zpos = true;
+
if (kms) {
ret = kms->funcs->hw_init(kms);
if (ret) {
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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

[DPU PATCH v2 4/7] drm/msm/dpu: switch to drm zpos property

[Jeykumar Sankaran]

Replace custom plane zpos property with drm core zpos
property. CRTC relies on the normalized zpos values
to configure blend stages of each plane.

changes in v2:
- Move out unrelated changes in plane init (Sean Paul)

Signed-off-by: Jeykumar Sankaran 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c  | 36 +--
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 16 +++---
 2 files changed, 14 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 24bf9c4..48361fb 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -2582,24 +2582,6 @@ struct plane_state {
u32 pipe_id;
 };
 
-static int pstate_cmp(const void *a, const void *b)
-{
-   struct plane_state *pa = (struct plane_state *)a;
-   struct plane_state *pb = (struct plane_state *)b;
-   int rc = 0;
-   int pa_zpos, pb_zpos;
-
-   pa_zpos = dpu_plane_get_property(pa->dpu_pstate, PLANE_PROP_ZPOS);
-   pb_zpos = dpu_plane_get_property(pb->dpu_pstate, PLANE_PROP_ZPOS);
-
-   if (pa_zpos != pb_zpos)
-   rc = pa_zpos - pb_zpos;
-   else
-   rc = pa->drm_pstate->crtc_x - pb->drm_pstate->crtc_x;
-
-   return rc;
-}
-
 static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
struct drm_crtc_state *state)
 {
@@ -2665,8 +2647,7 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
 
pstates[cnt].dpu_pstate = to_dpu_plane_state(pstate);
pstates[cnt].drm_pstate = pstate;
-   pstates[cnt].stage = dpu_plane_get_property(
-   pstates[cnt].dpu_pstate, PLANE_PROP_ZPOS);
+   pstates[cnt].stage = pstate->normalized_zpos;
pstates[cnt].pipe_id = dpu_plane_pipe(plane);
 
/* check dim layer stage with every plane */
@@ -2722,21 +2703,6 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
}
}
 
-   /* assign mixer stages based on sorted zpos property */
-   sort(pstates, cnt, sizeof(pstates[0]), pstate_cmp, NULL);
-
-   if (!dpu_is_custom_client()) {
-   int stage_old = pstates[0].stage;
-
-   z_pos = 0;
-   for (i = 0; i < cnt; i++) {
-   if (stage_old != pstates[i].stage)
-   ++z_pos;
-   stage_old = pstates[i].stage;
-   pstates[i].stage = z_pos;
-   }
-   }
-
z_pos = -1;
for (i = 0; i < cnt; i++) {
/* reset counts at every new blend stage */
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index 36e3c15..28735c8 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -59,6 +59,7 @@
 #define DPU_NAME_SIZE  12
 
 #define DPU_PLANE_COLOR_FILL_FLAG  BIT(31)
+#define DPU_ZPOS_MAX 255
 
 /* multirect rect index */
 enum {
@@ -1518,9 +1519,6 @@ static void _dpu_plane_install_properties(struct 
drm_plane *plane,
/* reserve zpos == 0 for primary planes */
zpos_def = drm_plane_index(plane) + 1;
}
-
-   msm_property_install_range(>property_info, "zpos",
-   0x0, 0, zpos_max, zpos_def, PLANE_PROP_ZPOS);
 }
 
 static int dpu_plane_atomic_set_property(struct drm_plane *plane,
@@ -1958,6 +1956,7 @@ struct drm_plane *dpu_plane_init(struct drm_device *dev,
struct msm_drm_private *priv;
struct dpu_kms *kms;
enum drm_plane_type type;
+   int zpos_max = DPU_ZPOS_MAX;
int ret = -EINVAL;
 
if (!dev) {
@@ -2051,6 +2050,17 @@ struct drm_plane *dpu_plane_init(struct drm_device *dev,
 
pdpu->catalog = kms->catalog;
 
+   if (kms->catalog->mixer_count &&
+   kms->catalog->mixer[0].sblk->maxblendstages) {
+   zpos_max = kms->catalog->mixer[0].sblk->maxblendstages - 1;
+   if (zpos_max > DPU_STAGE_MAX - DPU_STAGE_0 - 1)
+   zpos_max = DPU_STAGE_MAX - DPU_STAGE_0 - 1;
+   }
+
+   ret = drm_plane_create_zpos_property(plane, 0, 0, zpos_max);
+   if (ret)
+   DPU_ERROR("failed to install zpos property, rc = %d\n", ret);
+
/* success! finalize initialization */
drm_plane_helper_add(plane, _plane_helper_funcs);
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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

[DPU PATCH v2 5/7] drm/msm/dpu: clean up dpu crtc custom properties

[Jeykumar Sankaran]

Remove dpu crtc custom properties and its handlers.

changes in v2:
- none

Signed-off-by: Jeykumar Sankaran 
Reviewed-by: Sean Paul 
---
 drivers/gpu/drm/msm/Makefile  |   1 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c |  28 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c  | 856 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h  |  27 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c   |  12 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ds.c | 149 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ds.h | 111 
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c |  67 --
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.h |  14 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h   |  16 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c|  71 +--
 drivers/gpu/drm/msm/msm_drv.h |  15 -
 12 files changed, 11 insertions(+), 1356 deletions(-)
 delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ds.c
 delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ds.h

diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 7bc3921..d289503 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -57,7 +57,6 @@ msm-y := \
disp/dpu1/dpu_hw_catalog.o \
disp/dpu1/dpu_hw_cdm.o \
disp/dpu1/dpu_hw_ctl.o \
-   disp/dpu1/dpu_hw_ds.o \
disp/dpu1/dpu_hw_interrupts.o \
disp/dpu1/dpu_hw_intf.o \
disp/dpu1/dpu_hw_lm.o \
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
index 981f77f..c4820de 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
@@ -102,34 +102,6 @@ static void _dpu_core_perf_calc_crtc(struct dpu_kms *kms,
dpu_cstate = to_dpu_crtc_state(state);
memset(perf, 0, sizeof(struct dpu_core_perf_params));
 
-   perf->bw_ctl[DPU_POWER_HANDLE_DBUS_ID_MNOC] =
-   dpu_crtc_get_property(dpu_cstate, CRTC_PROP_CORE_AB);
-   perf->max_per_pipe_ib[DPU_POWER_HANDLE_DBUS_ID_MNOC] =
-   dpu_crtc_get_property(dpu_cstate, CRTC_PROP_CORE_IB);
-
-   if (dpu_cstate->bw_split_vote) {
-   perf->bw_ctl[DPU_POWER_HANDLE_DBUS_ID_LLCC] =
-   dpu_crtc_get_property(dpu_cstate, CRTC_PROP_LLCC_AB);
-   perf->max_per_pipe_ib[DPU_POWER_HANDLE_DBUS_ID_LLCC] =
-   dpu_crtc_get_property(dpu_cstate, CRTC_PROP_LLCC_IB);
-   perf->bw_ctl[DPU_POWER_HANDLE_DBUS_ID_EBI] =
-   dpu_crtc_get_property(dpu_cstate, CRTC_PROP_DRAM_AB);
-   perf->max_per_pipe_ib[DPU_POWER_HANDLE_DBUS_ID_EBI] =
-   dpu_crtc_get_property(dpu_cstate, CRTC_PROP_DRAM_IB);
-   } else {
-   perf->bw_ctl[DPU_POWER_HANDLE_DBUS_ID_LLCC] =
-   dpu_crtc_get_property(dpu_cstate, CRTC_PROP_CORE_AB);
-   perf->max_per_pipe_ib[DPU_POWER_HANDLE_DBUS_ID_LLCC] =
-   dpu_crtc_get_property(dpu_cstate, CRTC_PROP_CORE_IB);
-   perf->bw_ctl[DPU_POWER_HANDLE_DBUS_ID_EBI] =
-   dpu_crtc_get_property(dpu_cstate, CRTC_PROP_CORE_AB);
-   perf->max_per_pipe_ib[DPU_POWER_HANDLE_DBUS_ID_EBI] =
-   dpu_crtc_get_property(dpu_cstate, CRTC_PROP_CORE_IB);
-   }
-
-   perf->core_clk_rate =
-   dpu_crtc_get_property(dpu_cstate, CRTC_PROP_CORE_CLK);
-
if (!dpu_cstate->bw_control) {
for (i = 0; i < DPU_POWER_HANDLE_DBUS_ID_MAX; i++) {
perf->bw_ctl[i] = kms->catalog->perf.max_bw_high *
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 48361fb..0c25c45 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -570,18 +570,6 @@ static void _dpu_crtc_deinit_events(struct dpu_crtc 
*dpu_crtc)
return;
 }
 
-/**
- * dpu_crtc_destroy_dest_scaler - free memory allocated for scaler lut
- * @dpu_crtc: Pointer to dpu crtc
- */
-static void _dpu_crtc_destroy_dest_scaler(struct dpu_crtc *dpu_crtc)
-{
-   if (!dpu_crtc)
-   return;
-
-   kfree(dpu_crtc->scl3_lut_cfg);
-}
-
 static void dpu_crtc_destroy(struct drm_crtc *crtc)
 {
struct dpu_crtc *dpu_crtc = to_dpu_crtc(crtc);
@@ -594,7 +582,6 @@ static void dpu_crtc_destroy(struct drm_crtc *crtc)
if (dpu_crtc->blob_info)
drm_property_blob_put(dpu_crtc->blob_info);
msm_property_destroy(_crtc->property_info);
-   _dpu_crtc_destroy_dest_scaler(dpu_crtc);
 
_dpu_crtc_deinit_events(dpu_crtc);
 
@@ -630,71 +617,6 @@ static void _dpu_crtc_setup_blend_cfg(struct 
dpu_crtc_mixer *mixer,
DPU_BLEND_BG_ALPHA_BG_CONST);
 }
 
-static void _dpu_crtc_setup_dim_layer_cfg(struct drm_crtc *crtc,
-   struct dpu_crtc *dpu_crtc, struct 

[DPU PATCH v2 1/7] drm/msm: remove connector custom properties

[Jeykumar Sankaran]

Cleanup residual connector property enumerations.

changs in v2:
- none

Signed-off-by: Jeykumar Sankaran 
Reviewed-by: Sean Paul 
---
 drivers/gpu/drm/msm/msm_drv.h | 27 ---
 1 file changed, 27 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index 90a2521..954ac12 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -140,32 +140,6 @@ enum msm_mdp_crtc_property {
CRTC_PROP_COUNT
 };
 
-enum msm_mdp_conn_property {
-   /* blob properties, always put these first */
-   CONNECTOR_PROP_DPU_INFO,
-   CONNECTOR_PROP_HDR_INFO,
-   CONNECTOR_PROP_PP_DITHER,
-
-   /* # of blob properties */
-   CONNECTOR_PROP_BLOBCOUNT,
-
-   /* range properties */
-   CONNECTOR_PROP_OUT_FB = CONNECTOR_PROP_BLOBCOUNT,
-   CONNECTOR_PROP_DST_X,
-   CONNECTOR_PROP_DST_Y,
-   CONNECTOR_PROP_DST_W,
-   CONNECTOR_PROP_DST_H,
-   CONNECTOR_PROP_BL_SCALE,
-   CONNECTOR_PROP_AD_BL_SCALE,
-
-   /* enum/bitmask properties */
-   CONNECTOR_PROP_AUTOREFRESH,
-   CONNECTOR_PROP_LP,
-
-   /* total # of properties */
-   CONNECTOR_PROP_COUNT
-};
-
 struct msm_vblank_ctrl {
struct kthread_work work;
struct list_head event_list;
@@ -434,7 +408,6 @@ struct msm_drm_private {
/* Properties */
struct drm_property *plane_property[PLANE_PROP_COUNT];
struct drm_property *crtc_property[CRTC_PROP_COUNT];
-   struct drm_property *conn_property[CONNECTOR_PROP_COUNT];
 
/* Color processing properties for the crtc */
struct drm_property **cp_property;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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

[DPU PATCH v2 0/7] clean up DPU custom properties

[Jeykumar Sankaran]

Submitting a series of patches to further clean up DPU driver by stripping
down a list of custom properties supporting proprietary features. It 
removes the property installers/handlers and cleans up relevant files of
of some of the advanced features. This series is based on the patch[1] 
available on the drm-next tip.

[1]https://patchwork.kernel.org/patch/10202847/

Thanks.

changes in v2:
- remove stale code in blend config
- move unrelated code while updating zpos property
- Makefile changes

Jeykumar Sankaran (7):
  drm/msm: remove connector custom properties
  drm/msm/dpu: clean up dpu plane custom properties
  drm/msm: enable zpos normalization
  drm/msm/dpu: switch to drm zpos property
  drm/msm/dpu: clean up dpu crtc custom properties
  drm/msm: remove msm_prop files
  drm/msm: remove dpu specific uapi header

 drivers/gpu/drm/msm/Makefile   |   10 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_ad4.h|   99 --
 .../gpu/drm/msm/disp/dpu1/dpu_color_processing.c   | 1521 
 .../gpu/drm/msm/disp/dpu1/dpu_color_processing.h   |  120 --
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c  |   30 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c   | 1328 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h   |   45 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c|   14 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h|2 -
 .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c|1 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ad4.c | 1443 ---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c |   72 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h |   89 --
 .../msm/disp/dpu1/dpu_hw_color_proc_common_v4.h|   69 -
 .../gpu/drm/msm/disp/dpu1/dpu_hw_color_proc_v4.c   |  242 
 .../gpu/drm/msm/disp/dpu1/dpu_hw_color_proc_v4.h   |   40 -
 .../drm/msm/disp/dpu1/dpu_hw_color_processing.h|   20 -
 .../msm/disp/dpu1/dpu_hw_color_processing_v1_7.c   |  565 
 .../msm/disp/dpu1/dpu_hw_color_processing_v1_7.h   |   92 --
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c |   44 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h |   15 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ds.c  |  149 --
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ds.h  |  111 --
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c|  209 ---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.h|  220 ---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c  |   67 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.h  |   14 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h|   58 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c|   68 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h|6 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_reg_dma_v1.c  |  757 --
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_reg_dma_v1.h  |   27 -
 .../msm/disp/dpu1/dpu_hw_reg_dma_v1_color_proc.c   |  943 
 .../msm/disp/dpu1/dpu_hw_reg_dma_v1_color_proc.h   |   75 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c|  219 ---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h|   73 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.c|1 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h|  156 ++
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c|3 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c  | 1404 ++
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h  |   43 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_reg_dma.c|  139 --
 drivers/gpu/drm/msm/disp/dpu1/dpu_reg_dma.h|  310 
 drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c |  149 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h |2 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_wb.c |2 -
 drivers/gpu/drm/msm/msm_drv.c  |3 +
 drivers/gpu/drm/msm/msm_drv.h  |   86 +-
 drivers/gpu/drm/msm/msm_prop.c |  688 -
 drivers/gpu/drm/msm/msm_prop.h |  438 --
 include/uapi/drm/dpu_drm.h |  407 --
 include/uapi/drm/msm_drm.h |1 -
 include/uapi/drm/msm_drm_pp.h  |  345 -
 53 files changed, 297 insertions(+), 12737 deletions(-)
 delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_ad4.h
 delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_color_processing.c
 delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_color_processing.h
 delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ad4.c
 delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_color_proc_common_v4.h
 delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_color_proc_v4.c
 delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_color_proc_v4.h
 delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_color_processing.h
 delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_color_processing_v1_7.c
 delete mode 100644 

Re: [PULL] drm-misc-next

[Dave Airlie]

On 26 April 2018 at 20:53, Maarten Lankhorst  wrote:
> Hi Dave,
>
> This is my first pull request for v4.18. Only UAPI change is adding a generic 
> plane
> alpha property, which replaces the driver specific ones in sun4i, rcar-du and 
> atmel-hclcdc.
>
> drm-misc-next-2018-04-26:
> drm-misc-next for v4.18:
>
> UAPI Changes:
> - Add support for a generic plane alpha property to sun4i, rcar-du and 
> atmel-hclcdc. (Maxime)
>
> Core Changes:
> - Stop looking at legacy plane->fb and crtc members in atomic drivers. (Ville)
> - mode_valid return type fixes. (Luc)
> - Handle zpos normalization in the core. (Peter)
>
> Driver Changes:
> - Implement CTM, plane alpha and generic async cursor support in vc4. (Stefan)
> - Various fixes for HPD and aux chan in drm_bridge/analogix_dp. (Lin, Zain, 
> Douglas)
> - Add support for MIPI DSI to sun4i. (Maxime)

>
> Oleksandr Andrushchenko (3):
> drm/xen-front: Add support for Xen PV display frontend

This isn't mentioned in the above changelog, please try and fill me in better :)

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

[Bug 106788] DP audio plays slower than HDMI

[bugzilla-daemon]

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

--- Comment #2 from Ming-Wei Shih  ---
Created attachment 140041
  --> https://bugs.freedesktop.org/attachment.cgi?id=140041=edit
dmesg ouput

-- 
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 106533] r300_dri.so SIGSEGV in llvm_pipeline_generic under Cinnamon

[bugzilla-daemon]

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

Marek Olšák  changed:

   What|Removed |Added

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

--- Comment #10 from Marek Olšák  ---
Thanks for testing. I pushed the patch as
17a42062ccdb3bf5624435db9598e4353756771f. Closing.

-- 
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 106666] amdgpu 0000:09:00.0: [gfxhub] VMC page fault (src_id:0 ring:56 vmid:3 pas_id:0), [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, last signaled seq=327845, last emitted seq=32

[bugzilla-daemon]

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

--- Comment #13 from udo  ---
Thanks.
For my Ryzen 5 2400g that means all vega* files from
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/amdgpu
?

LLVM is at 6.0.0, it it the fedora 28 llvm.
I should switch to git llvm? (again)

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

[PATCH] drm/fourcc: add msm compressed format modifiers

[Jeykumar Sankaran]

Qualcomm Snapdragon chipsets uses compressed format
to optimize BW across multiple IP's. This change adds
needed modifier support in drm for a simple 4x4 tile
based compressed variants of base formats.

Signed-off-by: Jeykumar Sankaran 
---
 include/uapi/drm/drm_fourcc.h | 13 +
 1 file changed, 13 insertions(+)

diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index e04613d..81444e0 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -405,6 +405,19 @@
  */
 #define DRM_FORMAT_MOD_BROADCOM_VC4_T_TILED fourcc_mod_code(BROADCOM, 1)
 
+/*
+ * MSM compressed format
+ *
+ * Refers to the compressed variant of a base format.
+ * Implementation may be platform and base-format specific.
+ *
+ * Each macrotile consists of m x n (mostly 4 x 4) tiles.
+ * Pixel data pitch/stride is aligned with macrotile width.
+ * Pixel data height is aligned with macrotile height.
+ * Entire pixel data buffer is aligned with 4k(bytes).
+ */
+#define DRM_FORMAT_MOD_QCOM_COMPRESSED fourcc_mod_code(QCOM, 1)
+
 #if defined(__cplusplus)
 }
 #endif
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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

Re: [Linaro-mm-sig] [PATCH resend] drivers: dma-buf: Change %p to %pK in debug messages

[Chris Wilson]

Quoting Daniel Rosenberg (2018-06-06 00:40:41)
> The format specifier %p can leak kernel addresses
> while not valuing the kptr_restrict system settings.
> Use %pK instead of %p, which also evaluates whether
> kptr_restrict is set.

This is backwards though. You never care about the actual value here and
the hashed pointer (%p) is always enough to provide an identifying token.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 106287] 18.0.1 introduced glitches in Dying Light

[bugzilla-daemon]

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

--- Comment #7 from Henrik Holst  ---
BTW if there are any mesa devs out there with a Radeon RX and that is willing
to try and find how to fix this I'm willing to gift a copy of Dying Light.

-- 
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 106287] 18.0.1 introduced glitches in Dying Light

[bugzilla-daemon]

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

--- Comment #6 from Henrik Holst  ---
Sounds almost like a locking issue / racing condition then. Almost looks like
we have to try and compile mesa ourselves to figure out which patch to 18.0.1
that broke it and why 18.0.3 fixed it while 18.1.0 broke it again even though
18.1.0 contains all the patches from 18.0.3...

Currently I'm using the Padoka PPA but the stable one seams to be stuck at
18.0.1 for 16.04LTS and the unstable one seams to have dropped support for
16.04 altogether.

-- 
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 v8 1/4] drm/bridge: add support for sn65dsi86 bridge driver

[Sean Paul]

On Tue, Jun 05, 2018 at 11:10:15AM +0530, Sandeep Panda wrote:
> Add support for TI's sn65dsi86 dsi2edp bridge chip.
> The chip converts DSI transmitted signal to eDP signal,
> which is fed to the connected eDP panel.
> 
> This chip can be controlled via either i2c interface or
> dsi interface. Currently in driver all the control registers
> are being accessed through i2c interface only.
> Also as of now HPD support has not been added to bridge
> chip driver.
> 
> Changes in v1:
>  - Split the dt-bindings and the driver support into separate patches
>(Andrzej Hajda).
>  - Use of gpiod APIs to parse and configure gpios instead of obsolete ones
>(Andrzej Hajda).
>  - Use macros to define the register offsets (Andrzej Hajda).
> 
> Changes in v2:
>  - Separate out edp panel specific HW resource handling from bridge
>driver and create a separate edp panel drivers to handle panel
>specific mode information and HW resources (Sean Paul).
>  - Replace pr_* APIs to DRM_* APIs to log error or debug information
>(Sean Paul).
>  - Remove some of the unnecessary structure/variable from driver (Sean
>Paul).
>  - Rename the function and structure prefix "sn65dsi86" to "ti_sn_bridge"
>(Sean Paul / Rob Herring).
>  - Remove most of the hard-coding and modified the bridge init sequence
>based on current mode (Sean Paul).
>  - Remove the existing function to retrieve the EDID data and
>implemented this as an i2c_adapter and use drm_get_edid() (Sean Paul).
>  - Remove the dummy irq handler implementation, will add back the
>proper irq handling later (Sean Paul).
>  - Capture the required enable gpios in a single array based on dt entry
>instead of having individual descriptor for each gpio (Sean Paul).
> 
> Changes in v3:
>  - Remove usage of irq_gpio and replace it as "interrupts" property (Rob
>Herring).
>  - Remove the unnecessary header file inclusions (Sean Paul).
>  - Rearrange the header files in alphabetical order (Sean Paul).
>  - Use regmap interface to perform i2c transactions.
>  - Update Copyright/License field and address other review comments
>(Jordan Crouse).
> 
> Changes in v4:
>  - Update License/Copyright (Sean Paul).
>  - Add Kconfig and Makefile changes (Sean Paul).
>  - Drop i2c gpio handling from this bridge driver, since i2c sda/scl gpios
>will be handled by i2c master.
>  - Update required supplies names.
>  - Remove unnecessary goto statements (Sean Paul).
>  - Add mutex lock to power_ctrl API to avoid race conditions (Sean
>Paul).
>  - Add support to parse reference clk frequency from dt(optional).
>  - Update the bridge chip enable/disable sequence.
> 
> Changes in v5:
>  - Fixed Kbuild test service reported warnings.
> 
> Changes in v6:
>  - Use PM runtime based ref-counting instead of local ref_count mechanism
>(Stephen Boyd).
>  - Clean up some debug logs and indentations (Sean Paul).
>  - Simplify dp rate calculation (Sean Paul).
>  - Add support to configure refclk based on input REFCLK pin or DACP/N
>pin (Stephen Boyd).
> 
> Changes in v7:
>  - Use static supply entries instead of dynamic allocation (Andrzej
>Hajda).
>  - Defer bridge driver probe if panel is not probed (Andrzej Hajda).
>  - Update of_graph APIs for correct node reference management. (Andrzej
>Hajda).
>  - Remove local display_mode object (Andrzej Hajda).
>  - Remove version id check function from driver.
> 
> Changes in v8:
>  - Move dsi register/attach function to bridge driver probe (Andrzej
>Hajda).
>  - Introduce a new helper function to write 16bit words into consecutive
>registers (Andrzej Hajda).
>  - Remove unnecessary macros (Andrzej Hajda).
> 
> Signed-off-by: Sandeep Panda 
> ---
>  drivers/gpu/drm/bridge/Kconfig|   9 +
>  drivers/gpu/drm/bridge/Makefile   |   1 +
>  drivers/gpu/drm/bridge/ti-sn65dsi86.c | 666 
> ++
>  3 files changed, 676 insertions(+)
>  create mode 100644 drivers/gpu/drm/bridge/ti-sn65dsi86.c
> 
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 3b99d5a..8153150 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -108,6 +108,15 @@ config DRM_TI_TFP410
>   ---help---
> Texas Instruments TFP410 DVI/HDMI Transmitter driver
>  
> +config DRM_TI_SN65DSI86
> + tristate "TI SN65DSI86 DSI to eDP bridge"
> + depends on OF
> + select DRM_KMS_HELPER
> + select REGMAP_I2C
> + select DRM_PANEL
> + ---help---
> +   Texas Instruments SN65DSI86 DSI to eDP Bridge driver
> +
>  source "drivers/gpu/drm/bridge/analogix/Kconfig"
>  
>  source "drivers/gpu/drm/bridge/adv7511/Kconfig"
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index 373eb28..3711be8 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -12,4 +12,5 @@ obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
>  obj-$(CONFIG_DRM_ANALOGIX_DP) += 

Re: [PATCH v8 1/4] drm/bridge: add support for sn65dsi86 bridge driver

[Sean Paul]

On Tue, Jun 05, 2018 at 04:47:15PM +0530, Vinod wrote:
> On 05-06-18, 11:10, Sandeep Panda wrote:
> > Add support for TI's sn65dsi86 dsi2edp bridge chip.
> > The chip converts DSI transmitted signal to eDP signal,
> > which is fed to the connected eDP panel.
> > 
> > This chip can be controlled via either i2c interface or
> > dsi interface. Currently in driver all the control registers
> > are being accessed through i2c interface only.
> > Also as of now HPD support has not been added to bridge
> > chip driver.
> > 
> > Changes in v1:
> >  - Split the dt-bindings and the driver support into separate patches
> >(Andrzej Hajda).
> >  - Use of gpiod APIs to parse and configure gpios instead of obsolete ones
> >(Andrzej Hajda).
> >  - Use macros to define the register offsets (Andrzej Hajda).
> 
> This is pretty useless for changelog. This is useful for review but not
> down the line when this is applied
> 
> Since you have cover letter, you may add it there. Or after sob and ---
> tag in the patch, that way it is skipped while applying..

FWIW, in drm we prefer the changelog is included in the commit message. It gives
credit to the reviewers, sometimes explains why decisions were made, and commit
message space is cheap :-).

Sean

> 
> > +#define SN_ENABLE_VID_STREAM_BIT   BIT(3)
> > +#define SN_DSIA_NUM_LANES_BITS (BIT(4) | BIT(3))
> > +#define SN_DP_NUM_LANES_BITS   (BIT(5) | BIT(4))
> > +#define SN_DP_DATA_RATE_BITS   (BIT(7) | BIT(6) | BIT(5))
> 
> GENMASK(7, 5)
> 
> > +static int __maybe_unused ti_sn_bridge_resume(struct device *dev)
> > +{
> > +   struct ti_sn_bridge *pdata = dev_get_drvdata(dev);
> > +   int ret = 0;
> 
> superfluous initialization
> 
> > +static int __maybe_unused ti_sn_bridge_suspend(struct device *dev)
> > +{
> > +   struct ti_sn_bridge *pdata = dev_get_drvdata(dev);
> > +   int ret = 0;
> 
> here as well
> 
> > +static int ti_sn_bridge_connector_get_modes(struct drm_connector 
> > *connector)
> > +{
> > +   struct ti_sn_bridge *pdata = connector_to_ti_sn_bridge(connector);
> > +   struct edid *edid;
> > +   u32 num_modes;
> > +
> > +   if (pdata->panel) {
> > +   DRM_DEBUG_KMS("get mode from connected drm_panel\n");
> > +   return drm_panel_get_modes(pdata->panel);
> > +   }
> > +
> > +   if (!pdata->ddc)
> > +   return 0;
> > +
> > +   pm_runtime_get_sync(pdata->dev);
> 
> you should check return of this
> 
> > +static void ti_sn_bridge_set_refclk(struct ti_sn_bridge *pdata)
> > +{
> > +   int i = 0;
> 
> superfluous initialization
> 
> > +static void ti_sn_bridge_enable(struct drm_bridge *bridge)
> > +{
> > +   struct ti_sn_bridge *pdata = bridge_to_ti_sn_bridge(bridge);
> > +   unsigned int val = 0;
> 
> here as well
> 
> > +static void ti_sn_bridge_pre_enable(struct drm_bridge *bridge)
> > +{
> > +   struct ti_sn_bridge *pdata = bridge_to_ti_sn_bridge(bridge);
> > +
> > +   pm_runtime_get_sync(pdata->dev);
> 
> error check required
> -- 
> ~Vinod

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v8 3/4] drm/panel: add Innolux TV123WAM panel driver support

[Sean Paul]

On Tue, Jun 05, 2018 at 11:10:17AM +0530, Sandeep Panda wrote:
> Add support for Innolux TV123WAM, which is a 12.3" eDP
> display panel with 2160x1440 resolution.
> 
> Changes in v1:
>  - Add the compatibility string, display_mode and panel_desc
>structures in alphabetical order (Sean Paul).
> 
> Signed-off-by: Sandeep Panda 

Reviewed-by: Sean Paul 

> ---
>  drivers/gpu/drm/panel/panel-simple.c | 27 +++
>  1 file changed, 27 insertions(+)
> 
> diff --git a/drivers/gpu/drm/panel/panel-simple.c 
> b/drivers/gpu/drm/panel/panel-simple.c
> index 234af81..8c72270 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -1190,6 +1190,30 @@ static void panel_simple_shutdown(struct device *dev)
>   },
>  };
>  
> +static const struct drm_display_mode innolux_tv123wam_mode = {
> + .clock = 206016,
> + .hdisplay = 2160,
> + .hsync_start = 2160 + 48,
> + .hsync_end = 2160 + 48 + 32,
> + .htotal = 2160 + 48 + 32 + 80,
> + .vdisplay = 1440,
> + .vsync_start = 1440 + 3,
> + .vsync_end = 1440 + 3 + 10,
> + .vtotal = 1440 + 3 + 10 + 27,
> + .vrefresh = 60,
> + .flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC,
> +};
> +
> +static const struct panel_desc innolux_tv123wam = {
> + .modes = _tv123wam_mode,
> + .num_modes = 1,
> + .bpc = 8,
> + .size = {
> + .width = 259,
> + .height = 173,
> + },
> +};
> +
>  static const struct drm_display_mode innolux_zj070na_01p_mode = {
>   .clock = 51501,
>   .hdisplay = 1024,
> @@ -2037,6 +2061,9 @@ static void panel_simple_shutdown(struct device *dev)
>   .compatible = "innolux,n156bge-l21",
>   .data = _n156bge_l21,
>   }, {
> + .compatible = "innolux,tv123wam",
> + .data = _tv123wam,
> + }, {
>   .compatible = "innolux,zj070na-01p",
>   .data = _zj070na_01p,
>   }, {
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 106827] Segmentation fault in i915_validate_state on SolveSpace startup

[bugzilla-daemon]

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

--- Comment #1 from Paul Fertser  ---
Ok, recompiling this file with -O makes the issue a bit clearer:

0x09de52ae in validate_program (i915=0xd402bb0, batch_space=0xbe9c8308)
at ../../../../../src/gallium/drivers/i915/i915_state_emit.c:431
431*batch_space = i915->fs->decl_len + i915->fs->program_len +
additional_size;
(gdb) p i915->fs
$3 = (struct i915_fragment_shader *) 0x0

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

[PATCH 2/2] drm: rcar-du: lvds: add R8A77980 support

[Sergei Shtylyov]

Add support for the R-Car V3H (R8A77980) SoC to the LVDS encoder driver.

Signed-off-by: Sergei Shtylyov 

---
 drivers/gpu/drm/rcar-du/rcar_lvds.c |1 +
 1 file changed, 1 insertion(+)

Index: drm/drivers/gpu/drm/rcar-du/rcar_lvds.c
===
--- drm.orig/drivers/gpu/drm/rcar-du/rcar_lvds.c
+++ drm/drivers/gpu/drm/rcar-du/rcar_lvds.c
@@ -519,6 +519,7 @@ static const struct of_device_id rcar_lv
{ .compatible = "renesas,r8a7795-lvds", .data = _lvds_gen3_info },
{ .compatible = "renesas,r8a7796-lvds", .data = _lvds_gen3_info },
{ .compatible = "renesas,r8a77970-lvds", .data = 
_lvds_r8a77970_info },
+   { .compatible = "renesas,r8a77980-lvds", .data = _lvds_gen3_info },
{ }
 };
 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] dt-bindings: display: renesas: lvds: document R8A77980 bindings

[Sergei Shtylyov]

Document the R-Car V3H (R8A77980) SoC in the R-Car LVDS bindings.

Signed-off-by: Sergei Shtylyov 

---
 Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt |1 +
 1 file changed, 1 insertion(+)

Index: drm/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
===
--- drm.orig/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
+++ drm/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
@@ -14,6 +14,7 @@ Required properties:
   - "renesas,r8a7795-lvds" for R8A7795 (R-Car H3) compatible LVDS encoders
   - "renesas,r8a7796-lvds" for R8A7796 (R-Car M3-W) compatible LVDS encoders
   - "renesas,r8a77970-lvds" for R8A77970 (R-Car V3M) compatible LVDS encoders
+  - "renesas,r8a77980-lvds" for R8A77980 (R-Car V3H) compatible LVDS encoders
   - "renesas,r8a77995-lvds" for R8A77995 (R-Car D3) compatible LVDS encoders
 
 - reg: Base address and length for the memory-mapped registers
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/2] Add R-Car V3H (R8A77980) support to the R-Car LVDS driver

[Sergei Shtylyov]

Hello!

Here's the set of 2 patches against the 'drm-next' branch of the 'drm.git' repo.
The purpose of these patches is to add the R-Car V3H (R8A77980) support to the
R-Car LVDS driver.

[1/2] dt-bindings: display: renesas: lvds: document R8A77980 bindings
[2/2] drm: rcar-du: lvds: add R8A77980 support

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

Re: [PATCH] dt-bindings: display: renesas: du: document R8A77980 bindings

[Laurent Pinchart]

Hi Sergei,

On Tuesday, 5 June 2018 22:49:57 EEST Sergei Shtylyov wrote:
> On 06/05/2018 10:16 PM, Laurent Pinchart wrote:
>  Document the R-Car V3H (R8A77980) SoC in the R-Car DU bindings; the DU
>  hardware seems the same as in the R-Car V3M (R8A77970).
> >>> 
> >>> How about "the DU hardware has the same topology as in the R-Car V3M
> >>> (R8A77970)" ? "seems" sounds like we're very unsure :-)
> >> 
> >> That's probably better, indeed.
> >> 
>  Signed-off-by: Sergei Shtylyov 
>  
>  ---
>  The patch is against the 'drm-next' branch of David Airlie's
>  'linux.git' repo.
> >>> 
> >>> Then you might want to switch to git://anongit.freedesktop.org/drm/drm
> >>> :-)
> >> 
> >> No, the corresponding MAINTAINERS records don't include
> >> drivers/gpu/drm/rcar-du/ or worse yet, the DU bindings. :-)
> 
> Well, there is still no corresponding record, actually...
> 
> > My point is that Dave's tree has moved.
> 
> How am I supposed to learn about it, from gossips? :-)

I learnt it the hard way when a pull request I had prepared against the old 
tree conflicted (at compile time) with patches merged in the new tree. This 
broke the build, and I learnt about the new tree from a kbuild bot report.

> >> Seriously, I thought you've done a patch to remove your dead 'fbdev' repo
> >> months ago and IO'm still seeing it listed... :-/
> > 
> > I'll address that now.
> 
> TIA.
> 
> >>> Apart from that,
> >>> 
> >>> Reviewed-by: Laurent Pinchart 
> >>> 
> >>> If you agree with the small change to the commit message I'll fix the
> >>> conflict locally, there's no need to resubmit.
> >> 
> >> I do agree, except I don't know what conflict you mean.
> >> 
> >> [...]
> > 
> > I mean the conflict with
> > 
> > commit dc8142901befabea974393d49b803f131243feb4
> > Author: Kieran Bingham 
> > Date:   Thu Apr 26 17:53:31 2018 +0100
> > 
> > dt-bindings: display: renesas: du: Document the r8a77965 bindings
> > 
> > that is present in Dave's new tree.
> 
> Ah... TIA again. :-)

-- 
Regards,

Laurent Pinchart



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

Re: [PATCH] dt-bindings: display: renesas: du: document R8A77980 bindings

[Sergei Shtylyov]

On 06/05/2018 10:16 PM, Laurent Pinchart wrote:

 Document the R-Car V3H (R8A77980) SoC in the R-Car DU bindings; the DU
 hardware seems the same as in the R-Car V3M (R8A77970).
>>>
>>> How about "the DU hardware has the same topology as in the R-Car V3M
>>> (R8A77970)" ? "seems" sounds like we're very unsure :-)
>>
>>That's probably better, indeed.
>>
 Signed-off-by: Sergei Shtylyov 

 ---
 The patch is against the 'drm-next' branch of David Airlie's 'linux.git'
 repo.
>>>
>>> Then you might want to switch to git://anongit.freedesktop.org/drm/drm :-)
>>
>> No, the corresponding MAINTAINERS records don't include
>> drivers/gpu/drm/rcar-du/ or worse yet, the DU bindings. :-)

   Well, there is still no corresponding record, actually... 

> My point is that Dave's tree has moved.

   How am I supposed to learn about it, from gossips? :-)

>> Seriously, I thought you've done a patch to remove your dead 'fbdev' repo
>> months ago and IO'm still seeing it listed... :-/
> 
> I'll address that now.

   TIA.
 
>>> Apart from that,
>>>
>>> Reviewed-by: Laurent Pinchart 
>>>
>>> If you agree with the small change to the commit message I'll fix the
>>> conflict locally, there's no need to resubmit.
>>
>> I do agree, except I don't know what conflict you mean.
>>
>> [...]
> 
> I mean the conflict with
> 
> commit dc8142901befabea974393d49b803f131243feb4
> Author: Kieran Bingham 
> Date:   Thu Apr 26 17:53:31 2018 +0100
> 
> dt-bindings: display: renesas: du: Document the r8a77965 bindings
> 
> that is present in Dave's new tree.

   Ah... TIA again. :-)

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

Re: [DPU PATCH 2/7] drm/msm/dpu: clean up dpu plane custom properties

[Jeykumar Sankaran]

On 2018-06-04 12:53, Sean Paul wrote:

On Wed, May 23, 2018 at 12:30:57PM -0700, Jeykumar Sankaran wrote:

This change removes all the dpu plane custom properties
and its handlers.

Signed-off-by: Jeykumar Sankaran 
---
 Makefile   |2 +-
 drivers/gpu/drm/msm/Makefile   |8 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_ad4.h|   99 --
 .../gpu/drm/msm/disp/dpu1/dpu_color_processing.c   | 1521



 .../gpu/drm/msm/disp/dpu1/dpu_color_processing.h   |  120 --
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c   |  148 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h   |3 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c|2 -
 .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c|1 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ad4.c | 1443

---

 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c |   72 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h |   89 --
 .../msm/disp/dpu1/dpu_hw_color_proc_common_v4.h|   69 -
 .../gpu/drm/msm/disp/dpu1/dpu_hw_color_proc_v4.c   |  242 
 .../gpu/drm/msm/disp/dpu1/dpu_hw_color_proc_v4.h   |   40 -
 .../drm/msm/disp/dpu1/dpu_hw_color_processing.h|   20 -
 .../msm/disp/dpu1/dpu_hw_color_processing_v1_7.c   |  565 
 .../msm/disp/dpu1/dpu_hw_color_processing_v1_7.h   |   92 --
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c |   44 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h |   15 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c|  209 ---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.h|  220 ---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c  |1 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h|   44 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c|   68 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h|6 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_reg_dma_v1.c  |  757 --
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_reg_dma_v1.h  |   27 -
 .../msm/disp/dpu1/dpu_hw_reg_dma_v1_color_proc.c   |  943 


 .../msm/disp/dpu1/dpu_hw_reg_dma_v1_color_proc.h   |   75 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c|  219 ---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h|   73 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.c|1 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h|  156 ++
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c|3 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c  | 1267

+---

 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h  |   31 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_reg_dma.c|  139 --
 drivers/gpu/drm/msm/disp/dpu1/dpu_reg_dma.h|  310 
 drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c |  102 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h |2 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_wb.c |2 -
 drivers/gpu/drm/msm/msm_drv.h  |   28 -
 include/uapi/drm/dpu_drm.h |  187 ---
 include/uapi/drm/msm_drm.h |1 -
 45 files changed, 277 insertions(+), 9189 deletions(-)


Doing all of this at once is really hard to review. I would have 
preferred

to
review each feature removal in a separate patch. However, since this is
just
going to be squashed into the DPU megapatch anyways, I guess it's fine.


Sure. I thought I was helping by squashing them beforehand.
Will take care by spliting them for review on future patches.

I only paid close attention to the additions, there are some unrelated
whitespace changes, but also meh on account of the squash (and non seem
objectionable).


 delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_ad4.h
 delete mode 100644 
drivers/gpu/drm/msm/disp/dpu1/dpu_color_processing.c
 delete mode 100644 
drivers/gpu/drm/msm/disp/dpu1/dpu_color_processing.h

 delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ad4.c
 delete mode 100644

drivers/gpu/drm/msm/disp/dpu1/dpu_hw_color_proc_common_v4.h
 delete mode 100644 
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_color_proc_v4.c
 delete mode 100644 
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_color_proc_v4.h

 delete mode 100644

drivers/gpu/drm/msm/disp/dpu1/dpu_hw_color_processing.h

 delete mode 100644

drivers/gpu/drm/msm/disp/dpu1/dpu_hw_color_processing_v1_7.c

 delete mode 100644

drivers/gpu/drm/msm/disp/dpu1/dpu_hw_color_processing_v1_7.h

 delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c
 delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.h
 delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_reg_dma_v1.c
 delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_reg_dma_v1.h
 delete mode 100644

drivers/gpu/drm/msm/disp/dpu1/dpu_hw_reg_dma_v1_color_proc.c

 delete mode 100644

drivers/gpu/drm/msm/disp/dpu1/dpu_hw_reg_dma_v1_color_proc.h

 delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_reg_dma.c
 delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_reg_dma.h

diff --git a/Makefile b/Makefile

Re: [PATCH] dt-bindings: display: renesas: du: document R8A77980 bindings

[Laurent Pinchart]

Hi Sergei,

On Tuesday, 5 June 2018 21:57:47 EEST Sergei Shtylyov wrote:
> On 06/05/2018 01:09 PM, Laurent Pinchart wrote:
> >> Document the R-Car V3H (R8A77980) SoC in the R-Car DU bindings; the DU
> >> hardware seems the same as in the R-Car V3M (R8A77970).
> > 
> > How about "the DU hardware has the same topology as in the R-Car V3M
> > (R8A77970)" ? "seems" sounds like we're very unsure :-)
> 
>That's probably better, indeed.
> 
> >> Signed-off-by: Sergei Shtylyov 
> >> 
> >> ---
> >> The patch is against the 'drm-next' branch of David Airlie's 'linux.git'
> >> repo.
> > 
> > Then you might want to switch to git://anongit.freedesktop.org/drm/drm :-)
> 
> No, the corresponding MAINTAINERS records don't include
> drivers/gpu/drm/rcar-du/ or worse yet, the DU bindings. :-)

My point is that Dave's tree has moved.

> Seriously, I thought you've done a patch to remove your dead 'fbdev' repo
> months ago and IO'm still seeing it listed... :-/

I'll address that now.

> > Apart from that,
> > 
> > Reviewed-by: Laurent Pinchart 
> > 
> > If you agree with the small change to the commit message I'll fix the
> > conflict locally, there's no need to resubmit.
> 
> I do agree, except I don't know what conflict you mean.
> 
> [...]

I mean the conflict with

commit dc8142901befabea974393d49b803f131243feb4
Author: Kieran Bingham 
Date:   Thu Apr 26 17:53:31 2018 +0100

dt-bindings: display: renesas: du: Document the r8a77965 bindings

that is present in Dave's new tree.

-- 
Regards,

Laurent Pinchart



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

Re: [PATCH] drm/amdgpu: Grab/put runtime PM references in atomic_commit_tail()

[Harry Wentland]

On 2018-06-04 03:35 PM, Lyude Paul wrote:
> So, unfortunately I recently made the discovery that in the upstream
> kernel, the only reason that amdgpu is not currently suffering from
> issues with runtime PM putting the GPU into suspend while it's driving
> displays is due to the fact that on most prime systems, we have sound
> devices associated with the GPU that hold their own runtime PM ref for
> the GPU.
> 
> What this means however, is that in the event that there isn't any kind
> of sound device active (which can easily be reproduced by building a
> kernel with sound drivers disabled), the GPU will fall asleep even when
> there's displays active. This appears to be in part due to the fact that
> amdgpu has not actually ever relied on it's rpm_idle() function to be
> the only thing keeping it running, and normally grabs it's own power
> references whenever there are displays active (as can be seen with the
> original pre-DC codepath in amdgpu_display_crtc_set_config() in
> amdgpu_display.c). This means it's very likely that this bug was
> introduced during the switch over the DC.
> 
> So to fix this, we start grabbing runtime PM references every time we
> enable a previously disabled CRTC in atomic_commit_tail(). This appears
> to be the correct solution, as it matches up with what i915 does in
> i915/intel_runtime_pm.c.
> 
> The one sideaffect of this is that we ignore the variable that the
> pre-DC code used to use for tracking when it needed runtime PM refs,
> adev->have_disp_power_ref. This is mainly because there's no way for a
> driver to tell whether or not all of it's CRTCs are enabled or disabled
> when we've begun committing an atomic state, as there may be CRTC
> commits happening in parallel that aren't contained within the atomic
> state being committed. So, it's safer to just get/put a reference for
> each CRTC being enabled or disabled in the new atomic state.
> 
> Signed-off-by: Lyude Paul 


I'm not familiar with the runtime_pm stuff, as is painfully obvious from the 
fact that we missed that with the DC driver. That said, from a cursory look at 
runtime_pm.txt, this looks right. 

Reviewed-by: Harry Wentland 

I'll pull this in through the amd-stg tree.

> ---
> As a note, I'm not entirely happy with this fix and I wouldn't be
> surprised if I missed something while looking through amdgpu. So, please
> don't hesistate to suggest a better fix :).

I still don't really like amdgpu_dm_atomic_commit_tail and related functions. 
We have plans to rework these and make them more straight-forward.

Harry

> 
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 1dd1142246c2..361b81ef6997 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -46,6 +46,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -4211,6 +4212,8 @@ static void amdgpu_dm_atomic_commit_tail(struct 
> drm_atomic_state *state)
>   if (dm_old_crtc_state->stream)
>   remove_stream(adev, acrtc, 
> dm_old_crtc_state->stream);
>  
> + pm_runtime_get_noresume(dev->dev);
> +
>   acrtc->enabled = true;
>   acrtc->hw_mode = new_crtc_state->mode;
>   crtc->hwmode = new_crtc_state->mode;
> @@ -4396,6 +4399,16 @@ static void amdgpu_dm_atomic_commit_tail(struct 
> drm_atomic_state *state)
>   drm_atomic_helper_wait_for_flip_done(dev, state);
>  
>   drm_atomic_helper_cleanup_planes(dev, state);
> +
> + /* Finally, drop a runtime PM reference for each newly disabled CRTC,
> +  * so we can put the GPU into runtime suspend if we're not driving any
> +  * displays anymore
> +  */
> + pm_runtime_mark_last_busy(dev->dev);
> + for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state, 
> new_crtc_state, i) {
> + if (old_crtc_state->active && !new_crtc_state->active)
> + pm_runtime_put_autosuspend(dev->dev);
> + }
>  }
>  
>  
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/3] drm/v3d: Remove the bad signaled() implementation.

[Eric Anholt]

Since our seqno value comes from a counter associated with the GPU
ring, not the entity (aka client), they'll be completed out of order.
There's actually no need for this code at all, since we don't have
enable_signaling() and thus DMA_FENCE_SIGNALED_BIT will be set before
we could be called.

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/v3d/v3d_drv.h   |  1 -
 drivers/gpu/drm/v3d/v3d_fence.c | 13 -
 drivers/gpu/drm/v3d/v3d_gem.c   |  7 ++-
 drivers/gpu/drm/v3d/v3d_irq.c   |  3 ---
 4 files changed, 6 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/v3d/v3d_drv.h b/drivers/gpu/drm/v3d/v3d_drv.h
index 26005abd9c5d..f32ac8c98f37 100644
--- a/drivers/gpu/drm/v3d/v3d_drv.h
+++ b/drivers/gpu/drm/v3d/v3d_drv.h
@@ -25,7 +25,6 @@ struct v3d_queue_state {
 
u64 fence_context;
u64 emit_seqno;
-   u64 finished_seqno;
 };
 
 struct v3d_dev {
diff --git a/drivers/gpu/drm/v3d/v3d_fence.c b/drivers/gpu/drm/v3d/v3d_fence.c
index 087d49c8cb12..bfe31a89668b 100644
--- a/drivers/gpu/drm/v3d/v3d_fence.c
+++ b/drivers/gpu/drm/v3d/v3d_fence.c
@@ -40,19 +40,14 @@ static bool v3d_fence_enable_signaling(struct dma_fence 
*fence)
return true;
 }
 
-static bool v3d_fence_signaled(struct dma_fence *fence)
-{
-   struct v3d_fence *f = to_v3d_fence(fence);
-   struct v3d_dev *v3d = to_v3d_dev(f->dev);
-
-   return v3d->queue[f->queue].finished_seqno >= f->seqno;
-}
-
 const struct dma_fence_ops v3d_fence_ops = {
.get_driver_name = v3d_fence_get_driver_name,
.get_timeline_name = v3d_fence_get_timeline_name,
.enable_signaling = v3d_fence_enable_signaling,
-   .signaled = v3d_fence_signaled,
+   /* Each of our fences gets signaled as complete by the IRQ
+* handler, so we rely on the core's tracking of signaling.
+*/
+   .signaled = NULL,
.wait = dma_fence_default_wait,
.release = dma_fence_free,
 };
diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c
index 9ea83bdb9a30..d06d6697e089 100644
--- a/drivers/gpu/drm/v3d/v3d_gem.c
+++ b/drivers/gpu/drm/v3d/v3d_gem.c
@@ -657,17 +657,14 @@ void
 v3d_gem_destroy(struct drm_device *dev)
 {
struct v3d_dev *v3d = to_v3d_dev(dev);
-   enum v3d_queue q;
 
v3d_sched_fini(v3d);
 
/* Waiting for exec to finish would need to be done before
 * unregistering V3D.
 */
-   for (q = 0; q < V3D_MAX_QUEUES; q++) {
-   WARN_ON(v3d->queue[q].emit_seqno !=
-   v3d->queue[q].finished_seqno);
-   }
+   WARN_ON(v3d->bin_job);
+   WARN_ON(v3d->render_job);
 
drm_mm_takedown(>mm);
 
diff --git a/drivers/gpu/drm/v3d/v3d_irq.c b/drivers/gpu/drm/v3d/v3d_irq.c
index 77e1fa046c10..e07514eb11b5 100644
--- a/drivers/gpu/drm/v3d/v3d_irq.c
+++ b/drivers/gpu/drm/v3d/v3d_irq.c
@@ -87,15 +87,12 @@ v3d_irq(int irq, void *arg)
}
 
if (intsts & V3D_INT_FLDONE) {
-   v3d->queue[V3D_BIN].finished_seqno++;
dma_fence_signal(v3d->bin_job->bin.done_fence);
status = IRQ_HANDLED;
}
 
if (intsts & V3D_INT_FRDONE) {
-   v3d->queue[V3D_RENDER].finished_seqno++;
dma_fence_signal(v3d->render_job->render.done_fence);
-
status = IRQ_HANDLED;
}
 
-- 
2.17.0

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

[PATCH 3/3] drm/v3d: Add a note about locking of v3d_fence_create().

[Eric Anholt]

This isn't the first time I've had to argue to myself why the '++' was
safe.

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/v3d/v3d_fence.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/v3d/v3d_fence.c b/drivers/gpu/drm/v3d/v3d_fence.c
index bfe31a89668b..6265e9ab4a13 100644
--- a/drivers/gpu/drm/v3d/v3d_fence.c
+++ b/drivers/gpu/drm/v3d/v3d_fence.c
@@ -3,6 +3,9 @@
 
 #include "v3d_drv.h"
 
+/* Note that V3D fences are created during v3d_job_run(), so we're
+ * already implictly locked.
+ */
 struct dma_fence *v3d_fence_create(struct v3d_dev *v3d, enum v3d_queue queue)
 {
struct v3d_fence *fence;
-- 
2.17.0

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

[PATCH 1/3] drm/v3d: Take a lock across GPU scheduler job creation and queuing.

[Eric Anholt]

Between creation and queueing of a job, you need to prevent any other
job from being created and queued.  Otherwise the scheduler's fences
may be signaled out of seqno order.

Signed-off-by: Eric Anholt 
Fixes: 57692c94dcbe ("drm/v3d: Introduce a new DRM driver for Broadcom V3D 
V3.x+")
---

ccing amd-gfx due to interaction of this series with the scheduler.

 drivers/gpu/drm/v3d/v3d_drv.h |  5 +
 drivers/gpu/drm/v3d/v3d_gem.c | 11 +--
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/v3d/v3d_drv.h b/drivers/gpu/drm/v3d/v3d_drv.h
index a043ac3aae98..26005abd9c5d 100644
--- a/drivers/gpu/drm/v3d/v3d_drv.h
+++ b/drivers/gpu/drm/v3d/v3d_drv.h
@@ -85,6 +85,11 @@ struct v3d_dev {
 */
struct mutex reset_lock;
 
+   /* Lock taken when creating and pushing the GPU scheduler
+* jobs, to keep the sched-fence seqnos in order.
+*/
+   struct mutex sched_lock;
+
struct {
u32 num_allocated;
u32 pages_allocated;
diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c
index b513f9189caf..9ea83bdb9a30 100644
--- a/drivers/gpu/drm/v3d/v3d_gem.c
+++ b/drivers/gpu/drm/v3d/v3d_gem.c
@@ -550,13 +550,16 @@ v3d_submit_cl_ioctl(struct drm_device *dev, void *data,
if (ret)
goto fail;
 
+   mutex_lock(>sched_lock);
if (exec->bin.start != exec->bin.end) {
ret = drm_sched_job_init(>bin.base,
 >queue[V3D_BIN].sched,
 _priv->sched_entity[V3D_BIN],
 v3d_priv);
-   if (ret)
+   if (ret) {
+   mutex_unlock(>sched_lock);
goto fail_unreserve;
+   }
 
exec->bin_done_fence =
dma_fence_get(>bin.base.s_fence->finished);
@@ -570,12 +573,15 @@ v3d_submit_cl_ioctl(struct drm_device *dev, void *data,
 >queue[V3D_RENDER].sched,
 _priv->sched_entity[V3D_RENDER],
 v3d_priv);
-   if (ret)
+   if (ret) {
+   mutex_unlock(>sched_lock);
goto fail_unreserve;
+   }
 
kref_get(>refcount); /* put by scheduler job completion */
drm_sched_entity_push_job(>render.base,
  _priv->sched_entity[V3D_RENDER]);
+   mutex_unlock(>sched_lock);
 
v3d_attach_object_fences(exec);
 
@@ -615,6 +621,7 @@ v3d_gem_init(struct drm_device *dev)
spin_lock_init(>job_lock);
mutex_init(>bo_lock);
mutex_init(>reset_lock);
+   mutex_init(>sched_lock);
 
/* Note: We don't allocate address 0.  Various bits of HW
 * treat 0 as special, such as the occlusion query counters
-- 
2.17.0

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

Re: [PATCH] dt-bindings: display: renesas: du: document R8A77980 bindings

[Sergei Shtylyov]

On 06/05/2018 01:09 PM, Laurent Pinchart wrote:

>> Document the R-Car V3H (R8A77980) SoC in the R-Car DU bindings; the DU
>> hardware seems the same as in the R-Car V3M (R8A77970).
> 
> How about "the DU hardware has the same topology as in the R-Car V3M 
> (R8A77970)" ? "seems" sounds like we're very unsure :-)

   That's probably better, indeed.

>> Signed-off-by: Sergei Shtylyov 
>>
>> ---
>> The patch is against the 'drm-next' branch of David Airlie's 'linux.git'
>> repo.
> 
> Then you might want to switch to git://anongit.freedesktop.org/drm/drm :-)

   No, the corresponding MAINTAINERS records don't include 
drivers/gpu/drm/rcar-du/
or worse yet, the DU bindings. :-)
  Seriously, I thought you've done a patch to remove your dead 'fbdev' repo 
months
ago and IO'm still seeing it listed... :-/ 

> Apart from that,
> 
> Reviewed-by: Laurent Pinchart 
> 
> If you agree with the small change to the commit message I'll fix the 
> conflict 
> locally, there's no need to resubmit.

   I do agree, except I don't know what conflict you mean.

[...]

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

Re: [PATCH] drm/vc4: Enable the DSI module and link before other enables.

[Eric Anholt]

Andrzej Hajda  writes:

> On 04.06.2018 21:44, Eric Anholt wrote:
>> We want the DSI PHY to be enabled and the DSI module clocked before a
>> panel or bridge's prepare() function, since most DSI panel drivers
>> with a prepare() hook are doing DCS transactions inside of them.
>>
>> Signed-off-by: Eric Anholt 
>> Cc: Kevin Quigley 
>> Cc: James Hughes 
>> Cc: Boris Brezillon 
>> ---
>>
>> I'm not sure it makes sense to enable CRTCs before encoders on vc4 at
>> all.  Why start scanning pixels before the encoder is ready to hear
>> about VSTART?  However, this patch will hopefully unblock people
>> trying to attach other panels to rpi
>
> But this patch is about enabling encoder before panel/bridge prepare. Or
> am I missing something.
> Anyway I would be more precise here, MIPI-DSI bus is used for two things:
> - control bus - accessing DSI device (configuration/detection,...),
> - video data bus - sending video stream.
>
> I suspect in prepare/pre_enable phase of DSI panel/bridge only control
> bus should be functional, video stream transfer does not make sense.
> So the best solution (I guess) would be to split DSI-encoder enable
> sequence into control bus enable and video transfer enable parts and
> call the former before 1st transfer request from device and the latter
> in encoder enable callback. Of course there will be a problem then with
> disabling sequence, ie stopping video stream should be performed in
> encoder's disable, but when we should disable control bus? If we do it
> in encoder's disable callback we could not perform transfers in
> post_disable cb of the bridge - in most cases (maybe all currently
> present in kernel) it will work, but it does not look ideal.
> All this recalls me discussion that hardwiring bridge callbacks into drm
> core is problematic and maybe it would be better to call downstream
> callbacks explicitly from upstream element - the callback order should
> depend on the local bus protocol, and should not be fixed in drm core.

It does seem like for DSI encoders they generally would need to be able
to control when the call down to the bridge happens.  However, from my
experience with panels, drivers are bad about calling both prepare and
enable, if their particular panel only cares about one of them.  So, how
about:

- encoders can call drm_bridge_disable_midlayer_calls() (any naming
  suggestions?) to flag this bridge as not wanting the calls from the
  atomic helpers.

- atomic helpers WARN if bridge midlayer_calls flag was set and
  drm_bridge_pre_enable/enable/disable/post_disable failed to be called
  by the encoder

- drm_bridge_detach() clears disable_midlayer_calls flag for the next
  encoder


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

[PATCH] Changing comment for the list_empty() routine which returns boolean

[Nitin Yewale]

Author: Nitin U. Yewale 
Date:   Mon Jun 4 23:28:41 2018 +0530

Changing comment for the list_empty routine.
---
Signed-off-by: Nitin U. Yewale 

diff --git a/drivers/gpu/drm/nouveau/include/nvif/list.h
b/drivers/gpu/drm/nouveau/include/nvif/list.h
index 8af5d144ecb0..12bf7ee4 100644
--- a/drivers/gpu/drm/nouveau/include/nvif/list.h
+++ b/drivers/gpu/drm/nouveau/include/nvif/list.h
@@ -226,10 +226,7 @@ static inline void list_move_tail(struct list_head *list,
 /**
  * Check if the list is empty.
  *
- * Example:
- * list_empty(>list_of_foos);
- *
- * @return True if the list contains one or more elements or False otherwise.
+ * @return True if the list is empty (head->next == head) or False otherwise.
  */
 static inline bool
 list_empty(struct list_head *head)

-- 
Thank you,
Nitin Yewale
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 106827] Segmentation fault in i915_validate_state on SolveSpace startup

[bugzilla-daemon]

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

Bug ID: 106827
   Summary: Segmentation fault in i915_validate_state on
SolveSpace startup
   Product: Mesa
   Version: git
  Hardware: x86 (IA32)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/DRI/i915
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: fercer...@gmail.com
QA Contact: dri-devel@lists.freedesktop.org

Hello,

I am getting a SIGSEGV on startup of SolveSpace v2.1.rc1-418-g2b9ffd1 on a
GNU/Linux system.

Running on a i915 (chipset: 945GM) from Mesa Project
OpenGL version 2.1 Mesa 18.2.0-devel (git-66c61797ad) is supported

$ LD_LIBRARY_PATH=/usr/local/lib gdb ~/tmp/solvespace/build/bin/solvespace
GNU gdb (Gentoo 7.12.1 vanilla) 7.12.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /home/pavel/tmp/solvespace/build/bin/solvespace...(no
debugging symbols found)...done.
(gdb) r
Starting program: /home/pavel/tmp/solvespace/build/bin/solvespace 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".
SolveSpace!

Generate::ALL (for bounding box) took 238 ms
Generate::ALL took 256 ms

Program received signal SIGSEGV, Segmentation fault.
i915_validate_state (batch_space=, i915=0xb8a488)
at ../../../../../src/gallium/drivers/i915/i915_state_emit.c:525
525VALIDATE_ATOM(program, I915_HW_PROGRAM);
(gdb) bt full
#0  i915_validate_state (batch_space=, i915=0xb8a488)
at ../../../../../src/gallium/drivers/i915/i915_state_emit.c:525
tmp = 
#1  i915_emit_hardware_state (i915=0xb8a488)
at ../../../../../src/gallium/drivers/i915/i915_state_emit.c:551
batch_space = 48
save_ptr = 
#2  0xb3c353bb in i915_clear_emit (pipe=0xb8a488, buffers=1, color=0xbb9cd8,
depth=1, stencil=0, 
destx=0, desty=0, width=868, height=759) at
../../../../../src/gallium/drivers/i915/i915_clear.c:173
clear_params = 3
clear_color = 0
clear_depth = 
clear_stencil = 
clear_color = 0
u_color = {ub = 9 '\t', us = 9, ui = {9, 196608, 11, 196608}, h = {9,
0, 0, 3}, f = {
1.26116862e-44, 2.75506488e-40, 1.54142831e-44, 2.75506488e-40}, d
= {
4.1720134847010471e-309, 4.1720134847010569e-309,
4.6186441515375747e-62, 0}}
cbuf_tex = 
depth_tex = 
depth_clear_bbp = 
color_clear_bbp = 0
#3  0xb3c36035 in i915_clear_render (pipe=0xb8a488, buffers=1, color=0xbb9cd8,
depth=1, stencil=0)
at ../../../../../src/gallium/drivers/i915/i915_clear.c:256
No locals.
#4  0xb3929aff in st_Clear (ctx=, mask=)
at ../../../src/mesa/state_tracker/st_cb_clear.c:451
depthRb = 
quad_buffers = 
clear_buffers = 
i = 
#5  0xb376c572 in clear (no_error=false, mask=, ctx=0xbb87a0)
at ../../../src/mesa/main/clear.c:221
bufferMask = 16
#6  _mesa_Clear (mask=) at ../../../src/mesa/main/clear.c:242
ctx = 0xbb87a0
#7  0x0047b891 in SolveSpace::OpenGl2Renderer::UpdateProjection() ()
No symbol table info available.
#8  0x0047ba33 in SolveSpace::OpenGl2Renderer::NewFrame() ()
No symbol table info available.
#9  0x0048bbe7 in SolveSpace::GraphicsWindow::Paint() ()
No symbol table info available.
#10 0x0046ea4e in
SolveSpace::GraphicsWidget::on_render(Glib::RefPtr const&) ()
No symbol table info available.
#11 0xb7d2ac61 in Gtk::GLArea_Class::render_callback(_GtkGLArea*,
_GdkGLContext*) ()
   from /usr/lib/libgtkmm-3.0.so.1
No symbol table info available.
#12 0xb60c908e in ffi_call_SYSV () from /usr/lib/libffi.so.6
---Type  to continue, or q  to quit---
No symbol table info available.
#13 0xb60c8ca6 in ffi_call () from /usr/lib/libffi.so.6
No symbol table info available.
#14 0xb6651301 in g_cclosure_marshal_generic_va () from
/usr/lib/libgobject-2.0.so.0
No symbol table info available.
#15 0xb665088b in ?? () from /usr/lib/libgobject-2.0.so.0
No symbol table info available.
#16 0xb666cca7 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
No symbol table info available.
#17 0xb666d7e3 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
No symbol table info available.
#18 0xb7509f01 in ?? () from /usr/lib/libgtk-3.so.0
No symbol table info 

[Bug 106287] 18.0.1 introduced glitches in Dying Light

[bugzilla-daemon]

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

--- Comment #5 from stu...@gmail.com ---
Adding more, barely useful information.

Sometimes, I can start the game and the issues aren't there.   Sometimes I
start the game and they are there.  It's apparent at the start (the menu screen
actually).  Seems like there's some luck as to initialization/threading
involved to me.

-- 
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 106258] AMD Xorg start failes with non-4K page sizes

[bugzilla-daemon]

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

--- Comment #23 from fox...@ruin.net ---
(In reply to Michel Dänzer from comment #22)
> (In reply to foxbat from comment #21)
> > [   75.701323] NIP [c0081748cd08] amdgpu_sa_bo_new+0x640/0x6c0 [amdgpu]
> 
> What does
> 
>  scripts/faddr2line drivers/gpu/drm/amd/amdgpu/amdgpu.ko
> amdgpu_sa_bo_new+0x640/0x6c0
> 
> say in the kernel build tree?

foxbat@colossus:~/build/linux-4.17$ scripts/faddr2line
drivers/gpu/drm/amd/amdgpu/amdgpu.ko amdgpu_sa_bo_new+0x640/0x6c0 

skipping amdgpu_sa_bo_new address at 0x3cd08 due to size mismatch (0x6c0 !=
0x18e) no match for amdgpu_sa_bo_new+0x640/0x6c0

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

[PATCH 4.9 55/61] drm/psr: Fix missed entry in PSR setup time table.

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Dhinakaran Pandiyan 

commit bdcc02cf1bb508fc700df7662f55058f651f2621 upstream.

Entry corresponding to 220 us setup time was missing. I am not aware of
any specific bug this fixes, but this could potentially result in enabling
PSR on a panel with a higher setup time requirement than supported by the
hardware.

I verified the value is present in eDP spec versions 1.3, 1.4 and 1.4a.

Fixes: 6608804b3d7f ("drm/dp: Add drm_dp_psr_setup_time()")
Cc: sta...@vger.kernel.org
Cc: Ville Syrjälä 
Cc: Jose Roberto de Souza 
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: José Roberto de Souza 
Reviewed-by: Tarun Vyas 
Signed-off-by: Dhinakaran Pandiyan 
Signed-off-by: Jani Nikula 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20180511195145.3829-3-dhinakaran.pandi...@intel.com
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/gpu/drm/drm_dp_helper.c |1 +
 1 file changed, 1 insertion(+)

--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1065,6 +1065,7 @@ int drm_dp_psr_setup_time(const u8 psr_c
static const u16 psr_setup_time_us[] = {
PSR_SETUP_TIME(330),
PSR_SETUP_TIME(275),
+   PSR_SETUP_TIME(220),
PSR_SETUP_TIME(165),
PSR_SETUP_TIME(110),
PSR_SETUP_TIME(55),


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

[PATCH 2/2] drm/amdgpu: Rename entity cleanup finctions.

[Andrey Grodzovsky]

Everything in the flush code path (i.e. waiting for SW queue
to become empty) names with *_flush()
and everything in the release code path names *_fini()

Signed-off-by: Andrey Grodzovsky 
Suggested-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 6 +++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +-
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index e8c6cc1..93279ee 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -683,8 +683,8 @@ int amdgpu_ctx_ioctl(struct drm_device *dev, void *data,
 int amdgpu_ctx_wait_prev_fence(struct amdgpu_ctx *ctx, unsigned ring_id);
 
 void amdgpu_ctx_mgr_init(struct amdgpu_ctx_mgr *mgr);
-void amdgpu_ctx_mgr_entity_cleanup(struct amdgpu_ctx_mgr *mgr);
 void amdgpu_ctx_mgr_entity_fini(struct amdgpu_ctx_mgr *mgr);
+void amdgpu_ctx_mgr_entity_flush(struct amdgpu_ctx_mgr *mgr);
 void amdgpu_ctx_mgr_fini(struct amdgpu_ctx_mgr *mgr);
 
 
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
index c0f06c0..0120b24 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
@@ -444,7 +444,7 @@ void amdgpu_ctx_mgr_init(struct amdgpu_ctx_mgr *mgr)
idr_init(>ctx_handles);
 }
 
-void amdgpu_ctx_mgr_entity_fini(struct amdgpu_ctx_mgr *mgr)
+void amdgpu_ctx_mgr_entity_flush(struct amdgpu_ctx_mgr *mgr)
 {
struct amdgpu_ctx *ctx;
struct idr *idp;
@@ -473,7 +473,7 @@ void amdgpu_ctx_mgr_entity_fini(struct amdgpu_ctx_mgr *mgr)
mutex_unlock(>lock);
 }
 
-void amdgpu_ctx_mgr_entity_cleanup(struct amdgpu_ctx_mgr *mgr)
+void amdgpu_ctx_mgr_entity_fini(struct amdgpu_ctx_mgr *mgr)
 {
struct amdgpu_ctx *ctx;
struct idr *idp;
@@ -506,7 +506,7 @@ void amdgpu_ctx_mgr_fini(struct amdgpu_ctx_mgr *mgr)
struct idr *idp;
uint32_t id;
 
-   amdgpu_ctx_mgr_entity_cleanup(mgr);
+   amdgpu_ctx_mgr_entity_fini(mgr);
 
idp = >ctx_handles;
 
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index a549483..6841497 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -860,7 +860,7 @@ static int amdgpu_flush(struct file *f, fl_owner_t id)
struct drm_file *file_priv = f->private_data;
struct amdgpu_fpriv *fpriv = file_priv->driver_priv;
 
-   amdgpu_ctx_mgr_entity_fini(>ctx_mgr);
+   amdgpu_ctx_mgr_entity_flush(>ctx_mgr);
 
return 0;
 }
-- 
2.7.4

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

[PATCH 1/2] drm/scheduler: Rename cleanup functions.

[Andrey Grodzovsky]

Everything in the flush code path (i.e. waiting for SW queue
to become empty) names with *_flush()
and everything in the release code path names *_fini()

This patch also effect the amdgpu and etnaviv drivers which
use those functions.

Signed-off-by: Andrey Grodzovsky 
Suggested-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c   |  8 
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c   |  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c   |  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c   |  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c|  4 ++--
 drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c |  2 +-
 drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c |  2 +-
 drivers/gpu/drm/etnaviv/etnaviv_drv.c |  2 +-
 drivers/gpu/drm/scheduler/gpu_scheduler.c | 18 +-
 include/drm/gpu_scheduler.h   |  6 +++---
 10 files changed, 24 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
index 64b3a1e..c0f06c0 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
@@ -104,7 +104,7 @@ static int amdgpu_ctx_init(struct amdgpu_device *adev,
 
 failed:
for (j = 0; j < i; j++)
-   drm_sched_entity_fini(>rings[j]->sched,
+   drm_sched_entity_destroy(>rings[j]->sched,
  >rings[j].entity);
kfree(ctx->fences);
ctx->fences = NULL;
@@ -178,7 +178,7 @@ static void amdgpu_ctx_do_release(struct kref *ref)
if (ctx->adev->rings[i] == >adev->gfx.kiq.ring)
continue;
 
-   drm_sched_entity_fini(>adev->rings[i]->sched,
+   drm_sched_entity_destroy(>adev->rings[i]->sched,
>rings[i].entity);
}
 
@@ -466,7 +466,7 @@ void amdgpu_ctx_mgr_entity_fini(struct amdgpu_ctx_mgr *mgr)
if (ctx->adev->rings[i] == >adev->gfx.kiq.ring)
continue;
 
-   max_wait = 
drm_sched_entity_do_release(>adev->rings[i]->sched,
+   max_wait = 
drm_sched_entity_flush(>adev->rings[i]->sched,
  >rings[i].entity, max_wait);
}
}
@@ -492,7 +492,7 @@ void amdgpu_ctx_mgr_entity_cleanup(struct amdgpu_ctx_mgr 
*mgr)
continue;
 
if (kref_read(>refcount) == 1)
-   
drm_sched_entity_cleanup(>adev->rings[i]->sched,
+   
drm_sched_entity_fini(>adev->rings[i]->sched,
>rings[i].entity);
else
DRM_ERROR("ctx %p is still alive\n", ctx);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 57d4da6..a6e3191 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -162,7 +162,7 @@ static int amdgpu_ttm_global_init(struct amdgpu_device 
*adev)
 static void amdgpu_ttm_global_fini(struct amdgpu_device *adev)
 {
if (adev->mman.mem_global_referenced) {
-   drm_sched_entity_fini(adev->mman.entity.sched,
+   drm_sched_entity_destroy(adev->mman.entity.sched,
  >mman.entity);
mutex_destroy(>mman.gtt_window_lock);
drm_global_item_unref(>mman.bo_global_ref.ref);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
index bcf68f8..d7ff39e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
@@ -292,7 +292,7 @@ int amdgpu_uvd_sw_fini(struct amdgpu_device *adev)
for (j = 0; j < adev->uvd.num_uvd_inst; ++j) {
kfree(adev->uvd.inst[j].saved_bo);
 
-   drm_sched_entity_fini(>uvd.inst[j].ring.sched, 
>uvd.inst[j].entity);
+   drm_sched_entity_destroy(>uvd.inst[j].ring.sched, 
>uvd.inst[j].entity);
 
amdgpu_bo_free_kernel(>uvd.inst[j].vcpu_bo,
  >uvd.inst[j].gpu_addr,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
index 23d960e..b0dcdfd 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
@@ -222,7 +222,7 @@ int amdgpu_vce_sw_fini(struct amdgpu_device *adev)
if (adev->vce.vcpu_bo == NULL)
return 0;
 
-   drm_sched_entity_fini(>vce.ring[0].sched, >vce.entity);
+   drm_sched_entity_destroy(>vce.ring[0].sched, >vce.entity);
 
amdgpu_bo_free_kernel(>vce.vcpu_bo, >vce.gpu_addr,
(void **)>vce.cpu_addr);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index b0eb2f5..0ab1440 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ 

[Bug 106666] amdgpu 0000:09:00.0: [gfxhub] VMC page fault (src_id:0 ring:56 vmid:3 pas_id:0), [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, last signaled seq=327845, last emitted seq=32

[bugzilla-daemon]

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

--- Comment #12 from Michel Dänzer  ---
Per https://bugs.freedesktop.org/show_bug.cgi?id=105251#c9 , make sure you have
current microcode and LLVM

-- 
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 105300] amd-staging-drm-next-git 4.16 & RX 560 DL-DVI: corruption with refreshrates >73Hz when DPM changing VRAM clock

[bugzilla-daemon]

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

--- Comment #14 from tempel.jul...@gmail.com ---
73Hz + dynamic clocking work again with recent drm-next-4.19-wip build.

As a sidenote: On Windows (which is installed on the same system as a 2nd OS),
there has never been an issue with 75Hz during the last six months.

-- 
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 106258] AMD Xorg start failes with non-4K page sizes

[bugzilla-daemon]

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

--- Comment #22 from Michel Dänzer  ---
(In reply to foxbat from comment #21)
> [   75.701323] NIP [c0081748cd08] amdgpu_sa_bo_new+0x640/0x6c0 [amdgpu]

What does

 scripts/faddr2line drivers/gpu/drm/amd/amdgpu/amdgpu.ko
amdgpu_sa_bo_new+0x640/0x6c0

say in the kernel build tree?

-- 
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 106258] AMD Xorg start failes with non-4K page sizes

[bugzilla-daemon]

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

--- Comment #21 from fox...@ruin.net ---
I am still getting amdgpu crashes on POWER9 (ppc64le) using the latest AMD
firmware and on kernel 4.17 (release). My card is a WX5100 - Polaris 10. I can
reliably reproduce this by having spectacle attempt to capture an area of the
screen. However I also experience crashes randomly while moving a window.
Here is the dmesg output:

[   75.701274] CPU: 37 PID: 3391 Comm: spectacle Not tainted 4.17.0-foxbat-64k
#1
[   75.701275] NIP:  c0081748cd08 LR: c00817495944 CTR:

[   75.701278] REGS: c01f8ea53230 TRAP: 0700   Not tainted 
(4.17.0-foxbat-64k)
[   75.701278] MSR:  90029033   CR: 24828848 
XER: 2004
[   75.701284] CFAR: c0081748c724 SOFTE: 0
   GPR00: c00817495944 c01f8ea534b0 c008176e6400
c000201cb2303418
   GPR04: c000201ca9cfce60 09fff138 0100
05a3
   GPR08: 3817b594461fff5f 0010 
c00817649dd0
   GPR12: 8000 c01d5600 c000201cb230
c01fe89d9d20
   GPR16: 027ffc4e c000201ca9cfce60 fffe2000
ffef
   GPR20: 09fff138 0100 c000201cb23066a8

   GPR24: 027ffc4e 000e5fff c000201cb2303418
0001fe00
   GPR28: c000201cb230  c000201ca9cfce60
09fff138
[   75.701323] NIP [c0081748cd08] amdgpu_sa_bo_new+0x640/0x6c0 [amdgpu]
[   75.701347] LR [c00817495944] amdgpu_ib_get+0x8c/0x120 [amdgpu]
[   75.701348] Call Trace:
[   75.701370] [c01f8ea534b0] [c0081748c7f8]
amdgpu_sa_bo_new+0x130/0x6c0 [amdgpu] (unreliable)
[   75.701395] [c01f8ea53710] [c00817495944] amdgpu_ib_get+0x8c/0x120
[amdgpu]
[   75.701421] [c01f8ea53790] [c00817572558]
amdgpu_job_alloc_with_ib+0x90/0x110 [amdgpu]
[   75.701442] [c01f8ea537d0] [c00817492124]
amdgpu_vm_bo_update_mapping+0x35c/0x480 [amdgpu]
[   75.701469] [c01f8ea538c0] [c008174925c8]
amdgpu_vm_bo_update+0x380/0x740 [amdgpu]
[   75.701489] [c01f8ea539d0] [c00817476d10]
amdgpu_gem_va_ioctl+0x5f8/0x620 [amdgpu]
[   75.701496] [c01f8ea53b20] [c00815348ce8]
drm_ioctl_kernel+0xa0/0x140 [drm]
[   75.701502] [c01f8ea53b70] [c008153491b4] drm_ioctl+0x1ac/0x4d0
[drm]
[   75.701518] [c01f8ea53cb0] [c00817450078] amdgpu_drm_ioctl+0x70/0xd0
[amdgpu]
[   75.701521] [c01f8ea53d00] [c03e216c] do_vfs_ioctl+0xdc/0x8a0
[   75.701523] [c01f8ea53da0] [c03e2a34] ksys_ioctl+0x104/0x120
[   75.701525] [c01f8ea53df0] [c03e2a90] sys_ioctl+0x40/0xa0
[   75.701528] [c01f8ea53e30] [c000b9e0] system_call+0x58/0x6c
[   75.701529] Instruction dump:
[   75.701531] 7fc3f378 38210260 e8010010 81810008 ea21ff88 ea81ffa0 eaa1ffa8
eb41ffd0
[   75.701535] ebc1fff0 7c0803a6 7d908120 4e800020 <0fe0> 3bc0ffea 7fc3f378
38210260
[   75.701540] ---[ end trace 838930e3a806a76d ]---
[   75.701557] amdgpu :01:00.0: failed to get a new IB (-22)
[   75.701637] [drm:amdgpu_gem_va_ioctl [amdgpu]] *ERROR* Couldn't update BO_VA
(-22)
[   75.702847] amdgpu :01:00.0: failed to get a new IB (-22)
[   75.736208] amdgpu :01:00.0: failed to get a new IB (-22)
[   75.741527] amdgpu :01:00.0: failed to get a new IB (-22)
[   75.741602] [drm:amdgpu_gem_va_ioctl [amdgpu]] *ERROR* Couldn't update BO_VA
(-22)
[   75.743120] amdgpu :01:00.0: failed to get a new IB (-22)
[   75.743182] [drm:amdgpu_gem_va_ioctl [amdgpu]] *ERROR* Couldn't update BO_VA
(-22)

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

Re: [PATCH v2 0/4] drm/tinydrm: new dirver for ILI9341 displays

[Noralf Trønnes]

(cc: drm-misc maintainers)


Den 04.06.2018 03.21, skrev David Lechner:



On 6/3/18 5:00 PM, Noralf Trønnes wrote:


Den 25.05.2018 21.36, skrev David Lechner:
This series adds a new tinydrm driver for the Ilitek ILI9341 
controller and

a 2.4" display panel that uses this controller.


David, do you have commit rights now?


No. Opened a bug a while back to request access, but I guess the
right person didn't see it.

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



Could someone please look at this?

Noralf.



Noralf.


A few things to note here:
* The datasheet for this display[1] doesn't have a vendor mentioned 
on it
   anywhere, so I have used "adafruit" as the vendor prefix. If 
someone has a

   better suggestion, please speak up.
* The MAINTAINERS patch for ili9225 is included so we don't end up 
with a merge

   conflict later on.

v2 changes:
* change vendor prefix from "noname" to "adafruit"
* new patch for "adafruit" vendor prefix
* minor style changes
* drop regulator from driver (instead of adding to DT bindings)

[1]: 
https://cdn-learn.adafruit.com/assets/assets/000/046/879/original/SPEC-YX240QV29-T_Rev.A__1_.pdf 




David Lechner (4):
   MAINTAINERS: fix path to ilitek,ili9225 device tree bindings
   dt-bindings: Add vendor prefix for Adafruit
   dt-bindings: new binding for Ilitek ILI9341 display panels
   drm/tinydrm: new driver for ILI9341 display panels

  .../bindings/display/ilitek,ili9341.txt   |  27 ++
  .../devicetree/bindings/vendor-prefixes.txt   |   1 +
  MAINTAINERS   |   8 +-
  drivers/gpu/drm/tinydrm/Kconfig   |  10 +
  drivers/gpu/drm/tinydrm/Makefile  |   1 +
  drivers/gpu/drm/tinydrm/ili9341.c | 233 
++

  6 files changed, 279 insertions(+), 1 deletion(-)
  create mode 100644 
Documentation/devicetree/bindings/display/ilitek,ili9341.txt

  create mode 100644 drivers/gpu/drm/tinydrm/ili9341.c





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

[Bug 106228] amdgpu reads back brightness 0 (which is not true) if checked before a brightness has been explicitly set

[bugzilla-daemon]

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

--- Comment #3 from Daniel Drake  ---
Do you have any specific debugging suggestions?
Can we ship an affected laptop to you for diagnosis?

-- 
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/21] USB DisplayLink patches

[Mikulas Patocka]

On Tue, 5 Jun 2018, Alexey Brodkin wrote:

> Hi Mikulas,
> 
> On Sun, 2018-06-03 at 16:40 +0200, Mikulas Patocka wrote:
> > Hi
> > 
> > Here I'm sending bug fixes and performance improvements for the USB
> > DisplayLink framebuffer and modesetting drivers for this merge window.
> 
> For such a long series it would be very nice to post a link to your git
> tree so people may play with your changes easily.
> 
> Could you please prepare one?
> 
> -Alexey

I don't use git to manage my patches, I use quilt.

I uploaded the patches from quilt here: 
http://people.redhat.com/~mpatocka/patches/kernel/udl/series.html

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

Re: [PATCH 08/21] udl-kms: avoid prefetch

[Mikulas Patocka]

On Tue, 5 Jun 2018, Alexey Brodkin wrote:

> Hi Mikulas,
> 
> On Sun, 2018-06-03 at 16:41 +0200, Mikulas Patocka wrote:
> > Modern processors can detect linear memory accesses and prefetch data
> > automatically, so there's no need to use prefetch.
> 
> Not each and every CPU that's capable of running Linux has prefetch
> functionality :)
> 
> Still read-on...
> 
> > Signed-off-by: Mikulas Patocka 
> > 
> > ---
> >  drivers/gpu/drm/udl/udl_transfer.c |7 ---
> >  1 file changed, 7 deletions(-)
> > 
> > Index: linux-4.16.12/drivers/gpu/drm/udl/udl_transfer.c
> > ===
> > --- linux-4.16.12.orig/drivers/gpu/drm/udl/udl_transfer.c   2018-05-31 
> > 14:48:12.0 +0200
> > +++ linux-4.16.12/drivers/gpu/drm/udl/udl_transfer.c2018-05-31 
> > 14:48:12.0 +0200
> > @@ -13,7 +13,6 @@
> >  #include 
> >  #include 
> >  #include 
> > -#include 
> >  #include 
> >  
> >  #include 
> > @@ -51,9 +50,6 @@ static int udl_trim_hline(const u8 *bbac
> > int start = width;
> > int end = width;
> >  
> > -   prefetch((void *) front);
> > -   prefetch((void *) back);
> 
> AFAIK prefetcher fetches new data according to a known history... i.e. based 
> on previously
> used pattern we'll trying to get the next batch of data.
> 
> But the code above is in the very beginning of the data processing routine 
> where
> prefetcher doesn't yet have any history to know what and where to prefetch.
> 
> So I'd say this particular usage is good.
> At least those prefetches shouldn't hurt because typically it
> would be just 1 instruction if those exist or nothing if CPU/compiler doesn't
> support it.

See this post https://lwn.net/Articles/444336/ where they measured that 
prefetch hurts performance. Prefetch shouldn't be used unless you have a 
proof that it improves performance.

The problem is that the prefetch instruction causes stalls in the pipeline 
when it encounters TLB miss and the automatic prefetcher doesn't.

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

Re: [PATCH v8 2/4] dt-bindings: drm/bridge: Document sn65dsi86 bridge bindings

[Rob Herring]

On Tue, Jun 05, 2018 at 11:10:16AM +0530, Sandeep Panda wrote:
> Document the bindings used for the sn65dsi86 DSI to eDP bridge.
> 
> Changes in v1:
>  - Rephrase the dt-binding descriptions to be more inline with existing
>bindings (Andrzej Hajda).
>  - Add missing dt-binding that are parsed by corresponding driver
>(Andrzej Hajda).
> 
> Changes in v2:
>  - Remove edp panel specific dt-binding entries. Only keep bridge
>specific entries (Sean Paul).
>  - Remove custom-modes dt entry since its usage is removed from driver also 
> (Sean Paul).
>  - Remove is-pluggable dt entry since this will not be needed anymore (Sean 
> Paul).
> 
> Changes in v3:
>  - Remove irq-gpio dt entry and instead populate is an interrupt
>property (Rob Herring).
> 
> Changes in v4:
>  - Add link to bridge chip datasheet (Stephen Boyd)
>  - Add vpll and vcc regulator supply bindings (Stephen Boyd)
>  - Add ref clk optional dt binding (Stephen Boyd)
>  - Add gpio-controller optional dt binding (Stephen Boyd)
> 
> Changes in v5:
>  - Use clock property to specify the input refclk (Stephen Boyd).
>  - Update gpio cell and pwm cell numbers (Stephen Boyd).
> 
> Changes in v6:
>  - Add property to mention the lane mapping scheme and polarity inversion
>(Stephen Boyd).
> 
> Changes in v7:
>  - Detail description of lane mapping scheme dt property (Andrzej
>Hajda/ Rob Herring).
>  - Removed HDP gpio binding, since the bridge uses IRQ signal to
>determine HPD, and IRQ property is already documented in binding.
> 
> Signed-off-by: Sandeep Panda 
> ---
>  .../bindings/display/bridge/ti,sn65dsi86.txt   | 109 
> +
>  1 file changed, 109 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt 
> b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
> new file mode 100644
> index 000..33329f9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
> @@ -0,0 +1,109 @@
> +SN65DSI86 DSI to eDP bridge chip
> +
> +
> +This is the binding for Texas Instruments SN65DSI86 bridge.
> +http://www.ti.com/general/docs/lit/getliterature.tsp?genericPartNumber=sn65dsi86=pdf
> +
> +Required properties:
> +- compatible: Must be "ti,sn65dsi86"
> +- reg: i2c address of the chip, 0x2d as per datasheet
> +- enable-gpios: OF device-tree gpio specification for bridge_en pin (active 
> high)
> +
> +- vccio-supply: A 1.8V supply that powers up the digital IOs.
> +- vpll-supply: A 1.8V supply that powers up the displayport PLL.
> +- vcca-supply: A 1.2V supply that powers up the analog circuits.
> +- vcc-supply: A 1.2V supply that powers up the digital core.
> +
> +Optional properties:
> +- interrupts: Specifier for the SN65DSI86 interrupt line.
> +
> +- ddc-i2c-bus: phandle of the I2C controller used for DDC EDID probing
> +
> +- gpio-controller: Marks the device has a GPIO controller.
> +- #gpio-cells: Should be two. The first cell is the pin number and
> +   the second cell is used to specify flags.
> +   See ../../gpio/gpio.txt for more information.
> +- #pwm-cells : Should be one. See ../../pwm/pwm.txt for description of
> +   the cell formats.
> +
> +- clock-names: should be "refclk"
> +- clocks: Specification for input reference clock. The reference
> +   clock rate must be 12 MHz, 19.2 MHz, 26 MHz, 27 MHz or 38.4 MHz.
> +
> +- lane-mapping: Specification to describe the logical to physical lane

As I mentioned in v7, we already have a property for this. It's called
'data-lanes' and defined in media/video-interfaces.txt. Use that. If you 
need polarity too, then add a property for that. And add it to 
video-interfaces.txt.

> + mapping scheme and polarity inversion of eDP lanes on PCB.
> + Each pair present at index n (where n lies between 0 and 3)
> + describes the lane mapping of logical lane to physical lane n
> + and the polarity(it should be either 1 or 0) of the physical 
> lane n.
> +
> + For example:
> + lane-mapping = <2 1>,
> + <1 0>,
> + <3 1>,
> + <0 0>;
> +
> + The above mapping describes that logical lane 2 is mapped to
> + physical lane 0 and polarity of physical lane 0 is inverted,
> + logical lane 1 is mapped to physical lane 1 and polarity of
> + physical lane 1 is normal, logical lane 3 is mapped to physical
> + lane 2 and polarity of physical lane 2 is inverted, logical 
> lane 0
> + is mapped to physical lane 4 and polarity of physical lane 3 is 
> normal.
> +
> + If this property is not mentioned then it is assumed that 
> physical
> + lanes 0 through 3 are mapped to logical 

[PATCH v1 7/7] drm: sti: remove the last call to debugfs

[Benjamin Gaignard]

Thanks to all the hooks in drm structure, custom debugfs could be
removed of sti driver.

Signed-off-by: Benjamin Gaignard 
---
 drivers/gpu/drm/sti/sti_drv.c | 50 ---
 1 file changed, 50 deletions(-)

diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/sti_drv.c
index 90c46b49c931..95b0ac4d819c 100644
--- a/drivers/gpu/drm/sti/sti_drv.c
+++ b/drivers/gpu/drm/sti/sti_drv.c
@@ -7,7 +7,6 @@
 #include 
 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -72,53 +71,6 @@ static int sti_drm_fps_set(void *data, u64 val)
 DEFINE_SIMPLE_ATTRIBUTE(sti_drm_fps_fops,
sti_drm_fps_get, sti_drm_fps_set, "%llu\n");
 
-static int sti_drm_fps_dbg_show(struct seq_file *s, void *data)
-{
-   struct drm_info_node *node = s->private;
-   struct drm_device *dev = node->minor->dev;
-   struct drm_plane *p;
-
-   list_for_each_entry(p, >mode_config.plane_list, head) {
-   struct sti_plane *plane = to_sti_plane(p);
-
-   seq_printf(s, "%s%s\n",
-  plane->fps_info.fps_str,
-  plane->fps_info.fips_str);
-   }
-
-   return 0;
-}
-
-static struct drm_info_list sti_drm_dbg_list[] = {
-   {"fps_get", sti_drm_fps_dbg_show, 0},
-};
-
-static int sti_drm_dbg_init(struct drm_minor *minor)
-{
-   struct dentry *dentry;
-   int ret;
-
-   ret = drm_debugfs_create_files(sti_drm_dbg_list,
-  ARRAY_SIZE(sti_drm_dbg_list),
-  minor->debugfs_root, minor);
-   if (ret)
-   goto err;
-
-   dentry = debugfs_create_file("fps_show", S_IRUGO | S_IWUSR,
-minor->debugfs_root, minor->dev,
-_drm_fps_fops);
-   if (!dentry) {
-   ret = -ENOMEM;
-   goto err;
-   }
-
-   DRM_INFO("%s: debugfs installed\n", DRIVER_NAME);
-   return 0;
-err:
-   DRM_ERROR("%s: cannot install debugfs\n", DRIVER_NAME);
-   return ret;
-}
-
 static const struct drm_mode_config_funcs sti_mode_config_funcs = {
.fb_create = drm_gem_fb_create,
.output_poll_changed = drm_fb_helper_output_poll_changed,
@@ -167,8 +119,6 @@ static struct drm_driver sti_driver = {
.gem_prime_vunmap = drm_gem_cma_prime_vunmap,
.gem_prime_mmap = drm_gem_cma_prime_mmap,
 
-   .debugfs_init = sti_drm_dbg_init,
-
.name = DRIVER_NAME,
.desc = DRIVER_DESC,
.date = DRIVER_DATE,
-- 
2.15.0

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

[PATCH v1 6/7] drm: sti: make encoders use atomic_print_state instead of debugfs

[Benjamin Gaignard]

Convert all sti encoders to atomic_print usage rather than use a
debugfs entry.

Signed-off-by: Benjamin Gaignard 
---
 drivers/gpu/drm/sti/sti_tvout.c | 162 
 1 file changed, 63 insertions(+), 99 deletions(-)

diff --git a/drivers/gpu/drm/sti/sti_tvout.c b/drivers/gpu/drm/sti/sti_tvout.c
index ea4a3b87fa55..8aa23710b695 100644
--- a/drivers/gpu/drm/sti/sti_tvout.c
+++ b/drivers/gpu/drm/sti/sti_tvout.c
@@ -442,10 +442,10 @@ static void tvout_hda_start(struct sti_tvout *tvout, bool 
main_path)
tvout_write(tvout, 0, TVO_HD_DAC_CFG_OFF);
 }
 
-#define DBGFS_DUMP(reg) seq_printf(s, "\n  %-25s 0x%08X", #reg, \
+#define DBGFS_DUMP(reg) drm_printf(p, "\n\t\t%-25s 0x%08X", #reg, \
   readl(tvout->regs + reg))
 
-static void tvout_dbg_vip(struct seq_file *s, int val)
+static void tvout_dbg_vip(struct drm_printer *p, int val)
 {
int r, g, b, tmp, mask;
char *const reorder[] = {"Y_G", "Cb_B", "Cr_R"};
@@ -459,86 +459,94 @@ static void tvout_dbg_vip(struct seq_file *s, int val)
   "Aux (color matrix by-passed)",
   "", "", "", "", "", "Force value"};
 
-   seq_putc(s, '\t');
+   drm_printf(p, "\n\t\t\t");
mask = TVO_VIP_REORDER_MASK << TVO_VIP_REORDER_R_SHIFT;
r = (val & mask) >> TVO_VIP_REORDER_R_SHIFT;
mask = TVO_VIP_REORDER_MASK << TVO_VIP_REORDER_G_SHIFT;
g = (val & mask) >> TVO_VIP_REORDER_G_SHIFT;
mask = TVO_VIP_REORDER_MASK << TVO_VIP_REORDER_B_SHIFT;
b = (val & mask) >> TVO_VIP_REORDER_B_SHIFT;
-   seq_printf(s, "%-24s %s->%s %s->%s %s->%s\n", "Reorder:",
+   drm_printf(p, "%-24s %s->%s %s->%s %s->%s", "Reorder:",
   reorder[r], reorder[TVO_VIP_REORDER_CR_R_SEL],
   reorder[g], reorder[TVO_VIP_REORDER_Y_G_SEL],
   reorder[b], reorder[TVO_VIP_REORDER_CB_B_SEL]);
-   seq_puts(s, "\t\t\t\t\t");
+   drm_printf(p, "\n\t\t\t");
mask = TVO_VIP_CLIP_MASK << TVO_VIP_CLIP_SHIFT;
tmp = (val & mask) >> TVO_VIP_CLIP_SHIFT;
-   seq_printf(s, "%-24s %s\n", "Clipping:", clipping[tmp]);
-   seq_puts(s, "\t\t\t\t\t");
+   drm_printf(p, "%-24s %s", "Clipping:", clipping[tmp]);
+   drm_printf(p, "\n\t\t\t");
mask = TVO_VIP_RND_MASK << TVO_VIP_RND_SHIFT;
tmp = (val & mask) >> TVO_VIP_RND_SHIFT;
-   seq_printf(s, "%-24s input data rounded to %s per component\n",
+   drm_printf(p, "%-24s input data rounded to %s per component",
   "Round:", round[tmp]);
-   seq_puts(s, "\t\t\t\t\t");
+   drm_printf(p, "\n\t\t\t");
tmp = (val & TVO_VIP_SEL_INPUT_MASK);
-   seq_printf(s, "%-24s %s", "Input selection:", input_sel[tmp]);
+   drm_printf(p, "%-24s %s", "Input selection:", input_sel[tmp]);
 }
 
-static void tvout_dbg_hd_dac_cfg(struct seq_file *s, int val)
+static void tvout_dbg_hd_dac_cfg(struct drm_printer *p, int val)
 {
-   seq_printf(s, "\t%-24s %s", "HD DAC:",
+   drm_printf(p, "\t%-24s %s", "HD DAC:",
   val & 1 ? "disabled" : "enabled");
 }
 
-static int tvout_dbg_show(struct seq_file *s, void *data)
+static void sti_tvout_print(struct drm_printer *p, struct drm_encoder *encoder)
 {
-   struct drm_info_node *node = s->private;
-   struct sti_tvout *tvout = (struct sti_tvout *)node->info_ent->data;
+   struct sti_tvout *tvout = to_sti_tvout(encoder);
struct drm_crtc *crtc;
 
-   seq_printf(s, "TVOUT: (vaddr = 0x%p)", tvout->regs);
-
-   seq_puts(s, "\n\n  HDMI encoder: ");
-   crtc = tvout->hdmi->crtc;
-   if (crtc) {
-   seq_printf(s, "connected to %s path",
-  sti_crtc_is_main(crtc) ? "main" : "aux");
-   DBGFS_DUMP(TVO_HDMI_SYNC_SEL);
-   DBGFS_DUMP(TVO_VIP_HDMI);
-   tvout_dbg_vip(s, readl(tvout->regs + TVO_VIP_HDMI));
-   } else {
-   seq_puts(s, "disabled");
+   drm_printf(p, "\tTVOUT: (vaddr = 0x%pK)\n", tvout->regs);
+
+   if (encoder->encoder_type == DRM_MODE_ENCODER_TMDS) {
+   drm_printf(p, "\tHDMI encoder: ");
+   crtc = tvout->hdmi->crtc;
+   if (crtc) {
+   drm_printf(p, "connected to %s path",
+  sti_crtc_is_main(crtc) ? "main" : "aux");
+   DBGFS_DUMP(TVO_HDMI_SYNC_SEL);
+   DBGFS_DUMP(TVO_VIP_HDMI);
+   tvout_dbg_vip(p, readl(tvout->regs + TVO_VIP_HDMI));
+   } else {
+   drm_printf(p, "disabled\n");
+   return;
+   }
}
 
-   seq_puts(s, "\n\n  DVO encoder: ");
-   crtc = tvout->dvo->crtc;
-   if (crtc) {
-   seq_printf(s, "connected to %s path",
-  sti_crtc_is_main(crtc) ? "main" : "aux");
-   

[PATCH v1 5/7] drm: sti: make crtc use atomic_print_state instead of debugfs

[Benjamin Gaignard]

Convert sti crtc to atomic_print_state usage rather than use a
debugfs entry.

Signed-off-by: Benjamin Gaignard 
---
 drivers/gpu/drm/sti/sti_compositor.c | 16 ---
 drivers/gpu/drm/sti/sti_compositor.h |  3 --
 drivers/gpu/drm/sti/sti_crtc.c   | 17 ---
 drivers/gpu/drm/sti/sti_mixer.c  | 89 ++--
 drivers/gpu/drm/sti/sti_mixer.h  |  3 +-
 drivers/gpu/drm/sti/sti_vid.c| 60 
 drivers/gpu/drm/sti/sti_vid.h|  2 +-
 7 files changed, 59 insertions(+), 131 deletions(-)

diff --git a/drivers/gpu/drm/sti/sti_compositor.c 
b/drivers/gpu/drm/sti/sti_compositor.c
index 021b8fcaa0b9..c08d5c560557 100644
--- a/drivers/gpu/drm/sti/sti_compositor.c
+++ b/drivers/gpu/drm/sti/sti_compositor.c
@@ -39,22 +39,6 @@ static const struct sti_compositor_data 
stih407_compositor_data = {
},
 };
 
-int sti_compositor_debugfs_init(struct sti_compositor *compo,
-   struct drm_minor *minor)
-{
-   unsigned int i;
-
-   for (i = 0; i < STI_MAX_VID; i++)
-   if (compo->vid[i])
-   vid_debugfs_init(compo->vid[i], minor);
-
-   for (i = 0; i < STI_MAX_MIXER; i++)
-   if (compo->mixer[i])
-   sti_mixer_debugfs_init(compo->mixer[i], minor);
-
-   return 0;
-}
-
 static int sti_compositor_bind(struct device *dev,
   struct device *master,
   void *data)
diff --git a/drivers/gpu/drm/sti/sti_compositor.h 
b/drivers/gpu/drm/sti/sti_compositor.h
index ac4bb3834810..eb8b233e68a2 100644
--- a/drivers/gpu/drm/sti/sti_compositor.h
+++ b/drivers/gpu/drm/sti/sti_compositor.h
@@ -79,7 +79,4 @@ struct sti_compositor {
struct notifier_block vtg_vblank_nb[STI_MAX_MIXER];
 };
 
-int sti_compositor_debugfs_init(struct sti_compositor *compo,
-   struct drm_minor *minor);
-
 #endif
diff --git a/drivers/gpu/drm/sti/sti_crtc.c b/drivers/gpu/drm/sti/sti_crtc.c
index 5824e6aca8f4..4e137932ffe4 100644
--- a/drivers/gpu/drm/sti/sti_crtc.c
+++ b/drivers/gpu/drm/sti/sti_crtc.c
@@ -316,15 +316,20 @@ void sti_crtc_disable_vblank(struct drm_device *drm_dev, 
unsigned int pipe)
DRM_DEBUG_DRIVER("Warning: cannot unregister VTG notifier\n");
 }
 
-static int sti_crtc_late_register(struct drm_crtc *crtc)
+static void sti_crtc_print_state(struct drm_printer *p,
+const struct drm_crtc_state *state)
 {
-   struct sti_mixer *mixer = to_sti_mixer(crtc);
+   struct sti_mixer *mixer = to_sti_mixer(state->crtc);
struct sti_compositor *compo = dev_get_drvdata(mixer->dev);
+   unsigned int i;
 
-   if (drm_crtc_index(crtc) == 0)
-   return sti_compositor_debugfs_init(compo, crtc->dev->primary);
+   for (i = 0; i < STI_MAX_VID; i++)
+   if (compo->vid[i])
+   sti_vid_print_state(p, compo->vid[i]);
 
-   return 0;
+   for (i = 0; i < STI_MAX_MIXER; i++)
+   if (compo->mixer[i])
+   sti_mixer_print_state(p, compo->mixer[i]);
 }
 
 static const struct drm_crtc_funcs sti_crtc_funcs = {
@@ -335,7 +340,7 @@ static const struct drm_crtc_funcs sti_crtc_funcs = {
.reset = drm_atomic_helper_crtc_reset,
.atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
-   .late_register = sti_crtc_late_register,
+   .atomic_print_state = sti_crtc_print_state,
 };
 
 bool sti_crtc_is_main(struct drm_crtc *crtc)
diff --git a/drivers/gpu/drm/sti/sti_mixer.c b/drivers/gpu/drm/sti/sti_mixer.c
index a4f45c74d678..22525139d315 100644
--- a/drivers/gpu/drm/sti/sti_mixer.c
+++ b/drivers/gpu/drm/sti/sti_mixer.c
@@ -70,20 +70,20 @@ static inline void sti_mixer_reg_write(struct sti_mixer 
*mixer,
writel(val, mixer->regs + reg_id);
 }
 
-#define DBGFS_DUMP(reg) seq_printf(s, "\n  %-25s 0x%08X", #reg, \
+#define DBGFS_DUMP(reg) drm_printf(p, "\n\t\t%-25s 0x%08X", #reg, \
   sti_mixer_reg_read(mixer, reg))
 
-static void mixer_dbg_ctl(struct seq_file *s, int val)
+static void mixer_dbg_ctl(struct drm_printer *p, int val)
 {
unsigned int i;
int count = 0;
char *const disp_layer[] = {"BKG", "VID0", "VID1", "GDP0",
"GDP1", "GDP2", "GDP3"};
 
-   seq_puts(s, "\tEnabled: ");
+   drm_printf(p, "\tEnabled: ");
for (i = 0; i < 7; i++) {
if (val & 1) {
-   seq_printf(s, "%s ", disp_layer[i]);
+   drm_printf(p, "%s ", disp_layer[i]);
count++;
}
val = val >> 1;
@@ -91,114 +91,75 @@ static void mixer_dbg_ctl(struct seq_file *s, int val)
 
val = val >> 2;
if (val & 1) {
-   seq_puts(s, "CURS ");
+   drm_printf(p, "CURS 

[PATCH v1 4/7] drm: sti: make connectors use atomic_print_state instead of debugfs

[Benjamin Gaignard]

Convert all sti connectors to atomic_print_state usage rather than
use a debugfs entry.

Signed-off-by: Benjamin Gaignard 
---
 drivers/gpu/drm/sti/sti_dvo.c  |  60 +--
 drivers/gpu/drm/sti/sti_hda.c  |  75 +++
 drivers/gpu/drm/sti/sti_hdmi.c | 132 -
 3 files changed, 90 insertions(+), 177 deletions(-)

diff --git a/drivers/gpu/drm/sti/sti_dvo.c b/drivers/gpu/drm/sti/sti_dvo.c
index a5979cd25cc7..5662613ae6e0 100644
--- a/drivers/gpu/drm/sti/sti_dvo.c
+++ b/drivers/gpu/drm/sti/sti_dvo.c
@@ -6,7 +6,6 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -158,52 +157,37 @@ static void dvo_awg_configure(struct sti_dvo *dvo, u32 
*awg_ram_code, int nb)
writel(DVO_AWG_CTRL_EN, dvo->regs + DVO_AWG_DIGSYNC_CTRL);
 }
 
-#define DBGFS_DUMP(reg) seq_printf(s, "\n  %-25s 0x%08X", #reg, \
+#define DBGFS_DUMP(reg) drm_printf(p, "\n\t\t%-25s 0x%08X", #reg, \
   readl(dvo->regs + reg))
 
-static void dvo_dbg_awg_microcode(struct seq_file *s, void __iomem *reg)
+static void dvo_dbg_awg_microcode(struct drm_printer *p, void __iomem *reg)
 {
unsigned int i;
 
-   seq_puts(s, "\n\n");
-   seq_puts(s, "  DVO AWG microcode:");
+   drm_printf(p, "\n\n");
+   drm_printf(p, "  DVO AWG microcode:");
for (i = 0; i < AWG_MAX_INST; i++) {
if (i % 8 == 0)
-   seq_printf(s, "\n  %04X:", i);
-   seq_printf(s, " %04X", readl(reg + i * 4));
+   drm_printf(p, "\n  %04X:", i);
+   drm_printf(p, " %04X", readl(reg + i * 4));
}
 }
 
-static int dvo_dbg_show(struct seq_file *s, void *data)
+static void sti_dvo_print_state(struct drm_printer *p,
+   const struct drm_connector_state *state)
 {
-   struct drm_info_node *node = s->private;
-   struct sti_dvo *dvo = (struct sti_dvo *)node->info_ent->data;
+   struct sti_dvo_connector *dvo_connector
+   = to_sti_dvo_connector(state->connector);
+   struct sti_dvo *dvo = dvo_connector->dvo;
 
-   seq_printf(s, "DVO: (vaddr = 0x%p)", dvo->regs);
+   drm_printf(p, "DVO: (vaddr = 0x%p)", dvo->regs);
DBGFS_DUMP(DVO_AWG_DIGSYNC_CTRL);
DBGFS_DUMP(DVO_DOF_CFG);
DBGFS_DUMP(DVO_LUT_PROG_LOW);
DBGFS_DUMP(DVO_LUT_PROG_MID);
DBGFS_DUMP(DVO_LUT_PROG_HIGH);
-   dvo_dbg_awg_microcode(s, dvo->regs + DVO_DIGSYNC_INSTR_I);
-   seq_putc(s, '\n');
-   return 0;
-}
-
-static struct drm_info_list dvo_debugfs_files[] = {
-   { "dvo", dvo_dbg_show, 0, NULL },
-};
-
-static int dvo_debugfs_init(struct sti_dvo *dvo, struct drm_minor *minor)
-{
-   unsigned int i;
-
-   for (i = 0; i < ARRAY_SIZE(dvo_debugfs_files); i++)
-   dvo_debugfs_files[i].data = dvo;
-
-   return drm_debugfs_create_files(dvo_debugfs_files,
-   ARRAY_SIZE(dvo_debugfs_files),
-   minor->debugfs_root, minor);
+   dvo_dbg_awg_microcode(p, dvo->regs + DVO_DIGSYNC_INSTR_I);
+   drm_printf(p, "\n");
 }
 
 static void sti_dvo_disable(struct drm_bridge *bridge)
@@ -397,20 +381,6 @@ sti_dvo_connector_detect(struct drm_connector *connector, 
bool force)
return connector_status_disconnected;
 }
 
-static int sti_dvo_late_register(struct drm_connector *connector)
-{
-   struct sti_dvo_connector *dvo_connector
-   = to_sti_dvo_connector(connector);
-   struct sti_dvo *dvo = dvo_connector->dvo;
-
-   if (dvo_debugfs_init(dvo, dvo->drm_dev->primary)) {
-   DRM_ERROR("DVO debugfs setup failed\n");
-   return -EINVAL;
-   }
-
-   return 0;
-}
-
 static const struct drm_connector_funcs sti_dvo_connector_funcs = {
.fill_modes = drm_helper_probe_single_connector_modes,
.detect = sti_dvo_connector_detect,
@@ -418,7 +388,7 @@ static const struct drm_connector_funcs 
sti_dvo_connector_funcs = {
.reset = drm_atomic_helper_connector_reset,
.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
-   .late_register = sti_dvo_late_register,
+   .atomic_print_state = sti_dvo_print_state,
 };
 
 static struct drm_encoder *sti_dvo_find_encoder(struct drm_device *dev)
diff --git a/drivers/gpu/drm/sti/sti_hda.c b/drivers/gpu/drm/sti/sti_hda.c
index 67bbdb49fffc..0734f2751505 100644
--- a/drivers/gpu/drm/sti/sti_hda.c
+++ b/drivers/gpu/drm/sti/sti_hda.c
@@ -307,71 +307,56 @@ static void hda_enable_hd_dacs(struct sti_hda *hda, bool 
enable)
}
 }
 
-#define DBGFS_DUMP(reg) seq_printf(s, "\n  %-25s 0x%08X", #reg, \
+#define DBGFS_DUMP(reg) drm_printf(p, "\n\t\t%-25s 0x%08X", #reg, \
   readl(hda->regs + reg))
 
-static void hda_dbg_cfg(struct seq_file *s, int val)
+static void 

[PATCH v1 0/7] Remove debugfs from sti display driver

[Benjamin Gaignard]

Thanks to the various atomic_print_state hooks in drm structure all
custom debugfs code could be remove from sti driver (~ -330 lines).

This patchset does two addtion in drm core:
- printing normalized zpos of each plane
- add "atomic_print" hook in encoder structure to be able to dump encoders
  at the same time than the others elements

All other patches are implemeting the various hooks in sti driver.

Benjamin Gaignard (7):
  drm: print plane state normalized zpos value
  drm: add hook to print encoder status
  drm: sti: make planes use atomic_print_state instead of debugfs
  drm: sti: make connectors use atomic_print_state instead of debugfs
  drm: sti: make crtc use atomic_print_state instead of debugfs
  drm: sti: make encoders use atomic_print_state instead of debugfs
  drm: sti: remove the last call to debugfs

 drivers/gpu/drm/drm_atomic.c |  16 +++
 drivers/gpu/drm/sti/sti_compositor.c |  16 ---
 drivers/gpu/drm/sti/sti_compositor.h |   3 -
 drivers/gpu/drm/sti/sti_crtc.c   |  17 +--
 drivers/gpu/drm/sti/sti_cursor.c |  65 
 drivers/gpu/drm/sti/sti_drv.c|  50 -
 drivers/gpu/drm/sti/sti_dvo.c|  60 +++
 drivers/gpu/drm/sti/sti_gdp.c| 196 +++
 drivers/gpu/drm/sti/sti_hda.c|  75 --
 drivers/gpu/drm/sti/sti_hdmi.c   | 132 ++-
 drivers/gpu/drm/sti/sti_hqvdp.c  | 149 +++---
 drivers/gpu/drm/sti/sti_mixer.c  |  89 +---
 drivers/gpu/drm/sti/sti_mixer.h  |   3 +-
 drivers/gpu/drm/sti/sti_tvout.c  | 162 +++--
 drivers/gpu/drm/sti/sti_vid.c|  60 ---
 drivers/gpu/drm/sti/sti_vid.h|   2 +-
 include/drm/drm_encoder.h|  12 +++
 17 files changed, 386 insertions(+), 721 deletions(-)

-- 
2.15.0

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

[PATCH v1 2/7] drm: add hook to print encoder status

[Benjamin Gaignard]

Even if encoders don't have state it could be useful to get information
from them when dumping of the other elements state.
Add an optional hook in drm_encoder_funcs structure and call it after crtc
print state.

Signed-off-by: Benjamin Gaignard 
---
 drivers/gpu/drm/drm_atomic.c | 15 +++
 include/drm/drm_encoder.h| 12 
 2 files changed, 27 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index cd1d677617c8..6a9f5be01172 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -28,6 +28,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1799,6 +1800,15 @@ int drm_atomic_nonblocking_commit(struct 
drm_atomic_state *state)
 }
 EXPORT_SYMBOL(drm_atomic_nonblocking_commit);
 
+static void drm_atomic_encoder_print(struct drm_printer *p,
+struct drm_encoder *encoder)
+{
+   drm_printf(p, "encoder[%u]: %s\n", encoder->base.id, encoder->name);
+
+   if (encoder->funcs->atomic_print)
+   encoder->funcs->atomic_print(p, encoder);
+}
+
 static void drm_atomic_print_state(const struct drm_atomic_state *state)
 {
struct drm_printer p = drm_info_printer(state->dev->dev);
@@ -1828,6 +1838,7 @@ static void __drm_state_dump(struct drm_device *dev, 
struct drm_printer *p,
struct drm_mode_config *config = >mode_config;
struct drm_plane *plane;
struct drm_crtc *crtc;
+   struct drm_encoder *encoder;
struct drm_connector *connector;
struct drm_connector_list_iter conn_iter;
 
@@ -1850,6 +1861,10 @@ static void __drm_state_dump(struct drm_device *dev, 
struct drm_printer *p,
drm_modeset_unlock(>mutex);
}
 
+   drm_for_each_encoder(encoder, dev) {
+   drm_atomic_encoder_print(p, encoder);
+   }
+
drm_connector_list_iter_begin(dev, _iter);
if (take_locks)
drm_modeset_lock(>mode_config.connection_mutex, NULL);
diff --git a/include/drm/drm_encoder.h b/include/drm/drm_encoder.h
index fb299696c7c4..b847dad817b0 100644
--- a/include/drm/drm_encoder.h
+++ b/include/drm/drm_encoder.h
@@ -80,6 +80,18 @@ struct drm_encoder_funcs {
 * before data structures are torndown.
 */
void (*early_unregister)(struct drm_encoder *encoder);
+
+   /**
+* @atomic_print
+*
+* If driver could implement this optional hook for printing
+* additional driver specific information.
+*
+* Do not call this directly, use drm_atomic_encoder_print()
+* instead.
+*/
+   void (*atomic_print)(struct drm_printer *p,
+struct drm_encoder *encoder);
 };
 
 /**
-- 
2.15.0

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

[PATCH v1 1/7] drm: print plane state normalized zpos value

[Benjamin Gaignard]

When dumping plane state print normalized zpos value as done for
the other plane state fields.

Signed-off-by: Benjamin Gaignard 
---
 drivers/gpu/drm/drm_atomic.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 07fef42869aa..cd1d677617c8 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -988,6 +988,7 @@ static void drm_atomic_plane_print_state(struct drm_printer 
*p,
drm_printf(p, "\tcrtc-pos=" DRM_RECT_FMT "\n", DRM_RECT_ARG());
drm_printf(p, "\tsrc-pos=" DRM_RECT_FP_FMT "\n", DRM_RECT_FP_ARG());
drm_printf(p, "\trotation=%x\n", state->rotation);
+   drm_printf(p, "\tnormalized-zpos=%x\n", state->normalized_zpos);
drm_printf(p, "\tcolor-encoding=%s\n",
   drm_get_color_encoding_name(state->color_encoding));
drm_printf(p, "\tcolor-range=%s\n",
-- 
2.15.0

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

[PATCH v1 3/7] drm: sti: make planes use atomic_print_state instead of debugfs

[Benjamin Gaignard]

Convert all sti planes to atomic_print_state usage rather than use a debugfs
entry.

Signed-off-by: Benjamin Gaignard 
---
 drivers/gpu/drm/sti/sti_cursor.c |  65 +
 drivers/gpu/drm/sti/sti_gdp.c| 196 +--
 drivers/gpu/drm/sti/sti_hqvdp.c  | 149 +
 3 files changed, 146 insertions(+), 264 deletions(-)

diff --git a/drivers/gpu/drm/sti/sti_cursor.c b/drivers/gpu/drm/sti/sti_cursor.c
index df0a282b9615..69f6b1091422 100644
--- a/drivers/gpu/drm/sti/sti_cursor.c
+++ b/drivers/gpu/drm/sti/sti_cursor.c
@@ -74,72 +74,57 @@ static const uint32_t cursor_supported_formats[] = {
 
 #define to_sti_cursor(x) container_of(x, struct sti_cursor, plane)
 
-#define DBGFS_DUMP(reg) seq_printf(s, "\n  %-25s 0x%08X", #reg, \
+#define DBGFS_DUMP(reg) drm_printf(p, "\n\t\t%-25s 0x%08X", #reg, \
   readl(cursor->regs + reg))
 
-static void cursor_dbg_vpo(struct seq_file *s, u32 val)
+static void cursor_dbg_vpo(struct drm_printer *p, u32 val)
 {
-   seq_printf(s, "\txdo:%4d\tydo:%4d", val & 0x0FFF, (val >> 16) & 0x0FFF);
+   drm_printf(p, "\txdo:%4d\tydo:%4d", val & 0x0FFF, (val >> 16) & 0x0FFF);
 }
 
-static void cursor_dbg_size(struct seq_file *s, u32 val)
+static void cursor_dbg_size(struct drm_printer *p, u32 val)
 {
-   seq_printf(s, "\t%d x %d", val & 0x07FF, (val >> 16) & 0x07FF);
+   drm_printf(p, "\t%d x %d", val & 0x07FF, (val >> 16) & 0x07FF);
 }
 
-static void cursor_dbg_pml(struct seq_file *s,
+static void cursor_dbg_pml(struct drm_printer *p,
   struct sti_cursor *cursor, u32 val)
 {
if (cursor->pixmap.paddr == val)
-   seq_printf(s, "\tVirt @: %p", cursor->pixmap.base);
+   drm_printf(p, "\tVirt @: %pK", cursor->pixmap.base);
 }
 
-static void cursor_dbg_cml(struct seq_file *s,
+static void cursor_dbg_cml(struct drm_printer *p,
   struct sti_cursor *cursor, u32 val)
 {
if (cursor->clut_paddr == val)
-   seq_printf(s, "\tVirt @: %p", cursor->clut);
+   drm_printf(p, "\tVirt @: %pK", cursor->clut);
 }
 
-static int cursor_dbg_show(struct seq_file *s, void *data)
+static void sti_cursor_plane_print_state(struct drm_printer *p,
+const struct drm_plane_state *state)
 {
-   struct drm_info_node *node = s->private;
-   struct sti_cursor *cursor = (struct sti_cursor *)node->info_ent->data;
+   struct sti_plane *plane = to_sti_plane(state->plane);
+   struct sti_cursor *cursor = to_sti_cursor(plane);
 
-   seq_printf(s, "%s: (vaddr = 0x%p)",
+   drm_printf(p, "\t%s: (vaddr = 0x%pK)",
   sti_plane_to_str(>plane), cursor->regs);
 
DBGFS_DUMP(CUR_CTL);
DBGFS_DUMP(CUR_VPO);
-   cursor_dbg_vpo(s, readl(cursor->regs + CUR_VPO));
+   cursor_dbg_vpo(p, readl(cursor->regs + CUR_VPO));
DBGFS_DUMP(CUR_PML);
-   cursor_dbg_pml(s, cursor, readl(cursor->regs + CUR_PML));
+   cursor_dbg_pml(p, cursor, readl(cursor->regs + CUR_PML));
DBGFS_DUMP(CUR_PMP);
DBGFS_DUMP(CUR_SIZE);
-   cursor_dbg_size(s, readl(cursor->regs + CUR_SIZE));
+   cursor_dbg_size(p, readl(cursor->regs + CUR_SIZE));
DBGFS_DUMP(CUR_CML);
-   cursor_dbg_cml(s, cursor, readl(cursor->regs + CUR_CML));
+   cursor_dbg_cml(p, cursor, readl(cursor->regs + CUR_CML));
DBGFS_DUMP(CUR_AWS);
DBGFS_DUMP(CUR_AWE);
-   seq_putc(s, '\n');
-   return 0;
-}
-
-static struct drm_info_list cursor_debugfs_files[] = {
-   { "cursor", cursor_dbg_show, 0, NULL },
-};
-
-static int cursor_debugfs_init(struct sti_cursor *cursor,
-  struct drm_minor *minor)
-{
-   unsigned int i;
 
-   for (i = 0; i < ARRAY_SIZE(cursor_debugfs_files); i++)
-   cursor_debugfs_files[i].data = cursor;
-
-   return drm_debugfs_create_files(cursor_debugfs_files,
-   ARRAY_SIZE(cursor_debugfs_files),
-   minor->debugfs_root, minor);
+   drm_printf(p, "\t%s%s\n",
+  plane->fps_info.fps_str, plane->fps_info.fips_str);
 }
 
 static void sti_cursor_argb_to_clut8(struct sti_cursor *cursor, u32 *src)
@@ -336,14 +321,6 @@ static void sti_cursor_destroy(struct drm_plane *drm_plane)
drm_plane_cleanup(drm_plane);
 }
 
-static int sti_cursor_late_register(struct drm_plane *drm_plane)
-{
-   struct sti_plane *plane = to_sti_plane(drm_plane);
-   struct sti_cursor *cursor = to_sti_cursor(plane);
-
-   return cursor_debugfs_init(cursor, drm_plane->dev->primary);
-}
-
 static const struct drm_plane_funcs sti_cursor_plane_helpers_funcs = {
.update_plane = drm_atomic_helper_update_plane,
.disable_plane = drm_atomic_helper_disable_plane,
@@ -351,7 +328,7 @@ static const struct drm_plane_funcs 
sti_cursor_plane_helpers_funcs = {

Re: [PATCH v7 1/5] drm/rockchip: add transfer function for cdn-dp

[Heiko Stübner]

Hi,

Am Mittwoch, 23. Mai 2018, 09:42:29 CEST schrieb Lin Huang:
> From: Chris Zhong 
> 
> We may support training outside firmware, so we need support
> dpcd read/write to get the message or do some setting with
> display.
> 
> Signed-off-by: Chris Zhong 
> Signed-off-by: Lin Huang 
> Reviewed-by: Sean Paul 
> Reviewed-by: Enric Balletbo 

> @@ -1030,6 +1064,13 @@ static int cdn_dp_bind(struct device *dev, struct
> device *master, void *data) dp->active = false;
>   dp->active_port = -1;
>   dp->fw_loaded = false;
> + dp->aux.name = "DP-AUX";
> + dp->aux.transfer = cdn_dp_aux_transfer;
> + dp->aux.dev = dev;
> +
> + ret = drm_dp_aux_register(>aux);
> + if (ret)
> + return ret;

this is missing matching drm_dp_aux_unregister calls both in the error path as 
well as in the unbind callback.

With the code as is, the kernel gives warnings about it trying to initialize 
an already initialized object ... in cases like probe-deferrals.


Heiko


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

Re: [PATCH] drm/atomic: Constify mode argument to mode_valid_path()

[Ville Syrjälä]

On Tue, Jun 05, 2018 at 03:51:28PM +0300, Laurent Pinchart wrote:
> The mode_valid_path() function validates the mode it receives without
> ever modifying it. Constify the mode pointer argument to make that
> explicit.
> 
> Signed-off-by: Laurent Pinchart 

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 130da5195f3b..7c3958f73dd4 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -456,7 +456,7 @@ mode_fixup(struct drm_atomic_state *state)
>  static enum drm_mode_status mode_valid_path(struct drm_connector *connector,
>   struct drm_encoder *encoder,
>   struct drm_crtc *crtc,
> - struct drm_display_mode *mode)
> + const struct drm_display_mode *mode)
>  {
>   enum drm_mode_status ret;
>  
> @@ -495,7 +495,7 @@ mode_valid(struct drm_atomic_state *state)
>   struct drm_crtc *crtc = conn_state->crtc;
>   struct drm_crtc_state *crtc_state;
>   enum drm_mode_status mode_status;
> - struct drm_display_mode *mode;
> + const struct drm_display_mode *mode;
>  
>   if (!crtc || !encoder)
>   continue;
> -- 
> Regards,
> 
> Laurent Pinchart
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [linux-sunxi] Re: [PATCH v2 00/26] arm64: allwinner: Add A64 DE2 HDMI support

[Maxime Ripard]

On Tue, Jun 05, 2018 at 06:23:57PM +0530, Jagan Teki wrote:
> On Fri, May 18, 2018 at 3:29 PM, Maxime Ripard
>  wrote:
> > On Fri, May 18, 2018 at 03:15:10PM +0530, Jagan Teki wrote:
> >> Allwinner A64 has display engine pipeline like other Allwinner SOC's 
> >> A83T/H3/H5.
> >>
> >> A64 behaviour similar to Allwinner A83T where
> >> Mixer0 => TCON0 => LVDS/RGB/MIPI-DSI
> >> Mixer1 => TCON1 => HDMI
> >> as per Display System Block DiagramAllwinner_A64_User_Manual_V1.1.pdf
> >>
> >> This is second patch-set followed with previous RFC[1] and first series[2]
> >> and merely concentrated on HDMI pipeline through TCON1 and rest will add 
> >> eventually.
> >>
> >> This series fixed previous version comments
> >> - about documenting fallback compatibles
> >> - adding new compatible for mixer1
> >> - support for multiple DW HDMI PHY clock parents (thanks, to Jernej)
> >>
> >> Note:
> >> Pine64 boards are unable to get edid by default like other A64 boards,
> >> but forcing 'video=HDMI-A-1:1920x1080@60D' kernel command line can
> >> create edid with display on penel.
> >
> > There's no point in trying to push this without the SRAM issue being
> > solved. It is required, and won't be merged unless this is addressed.
> 
> is SRAM issue resolved? if so may be I will try to test it on top.

I'd expect the one working on this to push a solution to solve this.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


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

Re: [PATCH v2 12/21] drm: i2c: ch7006: use match_string() helper

[Andy Shevchenko]

On Thu, May 31, 2018 at 2:11 PM, Yisheng Xie  wrote:
> match_string() returns the index of an array for a matching string,
> which can be used instead of open coded variant.
>

Reviewed-by: Andy Shevchenko 

> Cc: David Airlie 
> Cc: Yisheng Xie 
> Cc: Daniel Vetter 
> Cc: Arvind Yadav 
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Yisheng Xie 
> ---
> v2:
>  - handle err case before normal case.
>
>  drivers/gpu/drm/i2c/ch7006_drv.c | 13 +
>  1 file changed, 5 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i2c/ch7006_drv.c 
> b/drivers/gpu/drm/i2c/ch7006_drv.c
> index 544a8a2..9eefdfe 100644
> --- a/drivers/gpu/drm/i2c/ch7006_drv.c
> +++ b/drivers/gpu/drm/i2c/ch7006_drv.c
> @@ -464,16 +464,13 @@ static int ch7006_encoder_init(struct i2c_client 
> *client,
> priv->chip_version = ch7006_read(client, CH7006_VERSION_ID);
>
> if (ch7006_tv_norm) {
> -   for (i = 0; i < NUM_TV_NORMS; i++) {
> -   if (!strcmp(ch7006_tv_norm_names[i], ch7006_tv_norm)) 
> {
> -   priv->norm = i;
> -   break;
> -   }
> -   }
> -
> -   if (i == NUM_TV_NORMS)
> +   i = match_string(ch7006_tv_norm_names,
> +NUM_TV_NORMS, ch7006_tv_norm);
> +   if (i < 0)
> ch7006_err(client, "Invalid TV norm setting 
> \"%s\".\n",
>ch7006_tv_norm);
> +   else
> +   priv->norm = i;
> }
>
> if (ch7006_scale >= 0 && ch7006_scale <= 2)
> --
> 1.7.12.4
>



-- 
With Best Regards,
Andy Shevchenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 11/21] drm/nouveau: use match_string() helper

[Andy Shevchenko]

On Thu, May 31, 2018 at 2:11 PM, Yisheng Xie  wrote:
> match_string() returns the index of an array for a matching string,
> which can be used instead of open coded variant.
>

Reviewed-by: Andy Shevchenko 

> Cc: Ben Skeggs 
> Cc: David Airlie 
> Cc: dri-devel@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Signed-off-by: Yisheng Xie 
> ---
> v2:
>  - handle err case before normal case - per Andy
>
>  drivers/gpu/drm/nouveau/dispnv04/tvnv17.c | 13 +
>  1 file changed, 5 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c 
> b/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c
> index 6d99f11..67ba2ac 100644
> --- a/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c
> +++ b/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c
> @@ -644,16 +644,13 @@ static int nv17_tv_create_resources(struct drm_encoder 
> *encoder,
> int i;
>
> if (nouveau_tv_norm) {
> -   for (i = 0; i < num_tv_norms; i++) {
> -   if (!strcmp(nv17_tv_norm_names[i], nouveau_tv_norm)) {
> -   tv_enc->tv_norm = i;
> -   break;
> -   }
> -   }
> -
> -   if (i == num_tv_norms)
> +   i = match_string(nv17_tv_norm_names,
> +num_tv_norms, nouveau_tv_norm);
> +   if (i < 0)
> NV_WARN(drm, "Invalid TV norm setting \"%s\"\n",
> nouveau_tv_norm);
> +   else
> +   tv_enc->tv_norm = i;
> }
>
> drm_mode_create_tv_properties(dev, num_tv_norms, nv17_tv_norm_names);
> --
> 1.7.12.4
>



-- 
With Best Regards,
Andy Shevchenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/atomic: Constify mode argument to mode_valid_path()

[Laurent Pinchart]

The mode_valid_path() function validates the mode it receives without
ever modifying it. Constify the mode pointer argument to make that
explicit.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/drm_atomic_helper.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 130da5195f3b..7c3958f73dd4 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -456,7 +456,7 @@ mode_fixup(struct drm_atomic_state *state)
 static enum drm_mode_status mode_valid_path(struct drm_connector *connector,
struct drm_encoder *encoder,
struct drm_crtc *crtc,
-   struct drm_display_mode *mode)
+   const struct drm_display_mode *mode)
 {
enum drm_mode_status ret;
 
@@ -495,7 +495,7 @@ mode_valid(struct drm_atomic_state *state)
struct drm_crtc *crtc = conn_state->crtc;
struct drm_crtc_state *crtc_state;
enum drm_mode_status mode_status;
-   struct drm_display_mode *mode;
+   const struct drm_display_mode *mode;
 
if (!crtc || !encoder)
continue;
-- 
Regards,

Laurent Pinchart

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

[Bug 105046] Screen resolution reset to 1368x768 when turning monitor off

[bugzilla-daemon]

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

--- Comment #13 from Lothar Paltins  ---
Created attachment 140032
  --> https://bugs.freedesktop.org/attachment.cgi?id=140032=edit
dmesg output after amdgpu crash

-- 
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 105046] Screen resolution reset to 1368x768 when turning monitor off

[bugzilla-daemon]

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

--- Comment #12 from Lothar Paltins  ---
I've got the same issue with an AMD Ryzen 5 2400G after a power cycle of the
monitor (Dell U3011 with a resolution of 2560x1600 connected via DisplayPort).
It happened not always, but very often. I thought, it was fixed by the
workaround with the "drm.edid_firmware=..." kernel parameter, but now it
happened again. And there also seems to be a crash in the amdgpu driver. I've
attached the dmesg output after this happened.

-- 
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 v8 1/4] drm/bridge: add support for sn65dsi86 bridge driver

[Vinod]

On 05-06-18, 11:10, Sandeep Panda wrote:
> Add support for TI's sn65dsi86 dsi2edp bridge chip.
> The chip converts DSI transmitted signal to eDP signal,
> which is fed to the connected eDP panel.
> 
> This chip can be controlled via either i2c interface or
> dsi interface. Currently in driver all the control registers
> are being accessed through i2c interface only.
> Also as of now HPD support has not been added to bridge
> chip driver.
> 
> Changes in v1:
>  - Split the dt-bindings and the driver support into separate patches
>(Andrzej Hajda).
>  - Use of gpiod APIs to parse and configure gpios instead of obsolete ones
>(Andrzej Hajda).
>  - Use macros to define the register offsets (Andrzej Hajda).

This is pretty useless for changelog. This is useful for review but not
down the line when this is applied

Since you have cover letter, you may add it there. Or after sob and ---
tag in the patch, that way it is skipped while applying..

> +#define SN_ENABLE_VID_STREAM_BIT BIT(3)
> +#define SN_DSIA_NUM_LANES_BITS   (BIT(4) | BIT(3))
> +#define SN_DP_NUM_LANES_BITS (BIT(5) | BIT(4))
> +#define SN_DP_DATA_RATE_BITS (BIT(7) | BIT(6) | BIT(5))

GENMASK(7, 5)

> +static int __maybe_unused ti_sn_bridge_resume(struct device *dev)
> +{
> + struct ti_sn_bridge *pdata = dev_get_drvdata(dev);
> + int ret = 0;

superfluous initialization

> +static int __maybe_unused ti_sn_bridge_suspend(struct device *dev)
> +{
> + struct ti_sn_bridge *pdata = dev_get_drvdata(dev);
> + int ret = 0;

here as well

> +static int ti_sn_bridge_connector_get_modes(struct drm_connector *connector)
> +{
> + struct ti_sn_bridge *pdata = connector_to_ti_sn_bridge(connector);
> + struct edid *edid;
> + u32 num_modes;
> +
> + if (pdata->panel) {
> + DRM_DEBUG_KMS("get mode from connected drm_panel\n");
> + return drm_panel_get_modes(pdata->panel);
> + }
> +
> + if (!pdata->ddc)
> + return 0;
> +
> + pm_runtime_get_sync(pdata->dev);

you should check return of this

> +static void ti_sn_bridge_set_refclk(struct ti_sn_bridge *pdata)
> +{
> + int i = 0;

superfluous initialization

> +static void ti_sn_bridge_enable(struct drm_bridge *bridge)
> +{
> + struct ti_sn_bridge *pdata = bridge_to_ti_sn_bridge(bridge);
> + unsigned int val = 0;

here as well

> +static void ti_sn_bridge_pre_enable(struct drm_bridge *bridge)
> +{
> + struct ti_sn_bridge *pdata = bridge_to_ti_sn_bridge(bridge);
> +
> + pm_runtime_get_sync(pdata->dev);

error check required
-- 
~Vinod
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/bridge: analogix-anx78xx: Switch to SPDX identifier.

[Laurent Pinchart]

Hi Enric,

On Tuesday, 5 June 2018 13:27:06 EEST Enric Balletbo i Serra wrote:
> On 05/06/18 12:11, Laurent Pinchart wrote:
> > On Tuesday, 5 June 2018 13:00:50 EEST Enric Balletbo i Serra wrote:
> >> Adopt the SPDX license identifier headers to ease license compliance
> >> management.
> >> 
> >> Signed-off-by: Enric Balletbo i Serra 
> >> ---
> >> 
> >>  drivers/gpu/drm/bridge/analogix-anx78xx.c | 24 ---
> >>  1 file changed, 8 insertions(+), 16 deletions(-)
> >> 
> >> diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.c
> >> b/drivers/gpu/drm/bridge/analogix-anx78xx.c index
> >> b49043866be6..54d7e7981bed 100644
> >> --- a/drivers/gpu/drm/bridge/analogix-anx78xx.c
> >> +++ b/drivers/gpu/drm/bridge/analogix-anx78xx.c
> >> @@ -1,19 +1,11 @@
> >> -/*
> >> - * Copyright(c) 2016, Analogix Semiconductor.
> >> - *
> >> - * This program is free software; you can redistribute it and/or modify
> >> - * it under the terms of the GNU General Public License version 2 and
> >> - * only version 2 as published by the Free Software Foundation.
> >> - *
> >> - * 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 more details.
> >> - *
> >> - * Based on anx7808 driver obtained from chromeos with copyright:
> >> - * Copyright(c) 2013, Google Inc.
> >> - *
> >> - */
> >> +// SPDX-License-Identifier: GPL-2.0
> > 
> > This looks good to m.
> > 
> >> +// Driver for ANX78xx SlimPort transmitter.
> >> +//
> >> +// Copyright (C) 2016 Analogix Semiconductor.
> >> +// Copyright (C) 2016 Google, Inc.
> > 
> > Should the last line be 2013, not 2016 ?
> 
> Yes, my bad.
> 
> >> +//
> >> +// Author: Enric Balletbo i Serra 
> > 
> > I don't think there's a need to convert the whole comment block to
> > C++-style.
> 
> Seems that putting everything as // is Linus Torvalds' preferred style:
> https://lkml.org/lkml/2017/11/25/133
> 
> But if you want I change, I don't mind to use the c style instead, just let
> me know.

As usual with coding styles, it's a matter of preferences, feelings, and 
getting used to changes. I personally dislike C++-style comments in kernel 
sources. The fact that we have few of them makes them seem out of place, and 
thus disturb code reading. My preferences might change if the style becomes 
more prominent and I get used to it. Or maybe not :-)

This being said, I'd personally keep changes minimal here, and give the last 
word to the driver maintainer(s) as for any coding style matter.

> >>  #include 
> >>  #include 
> >>  #include 

-- 
Regards,

Laurent Pinchart



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

Re: [PATCH] drm/bridge: analogix-anx78xx: Switch to SPDX identifier.

[Laurent Pinchart]

Hi Enric,

Thank you for the patch.

On Tuesday, 5 June 2018 13:00:50 EEST Enric Balletbo i Serra wrote:
> Adopt the SPDX license identifier headers to ease license compliance
> management.
> 
> Signed-off-by: Enric Balletbo i Serra 
> ---
> 
>  drivers/gpu/drm/bridge/analogix-anx78xx.c | 24 ---
>  1 file changed, 8 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.c
> b/drivers/gpu/drm/bridge/analogix-anx78xx.c index
> b49043866be6..54d7e7981bed 100644
> --- a/drivers/gpu/drm/bridge/analogix-anx78xx.c
> +++ b/drivers/gpu/drm/bridge/analogix-anx78xx.c
> @@ -1,19 +1,11 @@
> -/*
> - * Copyright(c) 2016, Analogix Semiconductor.
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License version 2 and
> - * only version 2 as published by the Free Software Foundation.
> - *
> - * 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 more details.
> - *
> - * Based on anx7808 driver obtained from chromeos with copyright:
> - * Copyright(c) 2013, Google Inc.
> - *
> - */
> +// SPDX-License-Identifier: GPL-2.0

This looks good to m.

> +// Driver for ANX78xx SlimPort transmitter.
> +//
> +// Copyright (C) 2016 Analogix Semiconductor.
> +// Copyright (C) 2016 Google, Inc.

Should the last line be 2013, not 2016 ?

> +//
> +// Author: Enric Balletbo i Serra 

I don't think there's a need to convert the whole comment block to C++-style.

>  #include 
>  #include 
>  #include 

-- 
Regards,

Laurent Pinchart



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

Re: [PATCH] dt-bindings: display: renesas: du: document R8A77980 bindings

[Laurent Pinchart]

Hi Sergei,

Thank you for the patch.

On Monday, 4 June 2018 22:04:59 EEST Sergei Shtylyov wrote:
> Document the R-Car V3H (R8A77980) SoC in the R-Car DU bindings; the DU
> hardware seems the same as in the R-Car V3M (R8A77970).

How about "the DU hardware has the same topology as in the R-Car V3M 
(R8A77970)" ? "seems" sounds like we're very unsure :-)

> Signed-off-by: Sergei Shtylyov 
> 
> ---
> The patch is against the 'drm-next' branch of David Airlie's 'linux.git'
> repo.

Then you might want to switch to git://anongit.freedesktop.org/drm/drm :-)

Apart from that,

Reviewed-by: Laurent Pinchart 

If you agree with the small change to the commit message I'll fix the conflict 
locally, there's no need to resubmit.

>  Documentation/devicetree/bindings/display/renesas,du.txt |2 ++
>  1 file changed, 2 insertions(+)
> 
> Index: linux/Documentation/devicetree/bindings/display/renesas,du.txt
> ===
> --- linux.orig/Documentation/devicetree/bindings/display/renesas,du.txt
> +++ linux/Documentation/devicetree/bindings/display/renesas,du.txt
> @@ -14,6 +14,7 @@ Required Properties:
>  - "renesas,du-r8a7795" for R8A7795 (R-Car H3) compatible DU
>  - "renesas,du-r8a7796" for R8A7796 (R-Car M3-W) compatible DU
>  - "renesas,du-r8a77970" for R8A77970 (R-Car V3M) compatible DU
> +- "renesas,du-r8a77980" for R8A77980 (R-Car V3H) compatible DU
>  - "renesas,du-r8a77995" for R8A77995 (R-Car D3) compatible DU
> 
>- reg: the memory-mapped I/O registers base address and length
> @@ -60,6 +61,7 @@ corresponding to each DU output.
>   R8A7795 (R-Car H3)   DPAD 0 HDMI 0 HDMI 1 LVDS 0
>   R8A7796 (R-Car M3-W) DPAD 0 HDMI 0 LVDS 0 -
>   R8A77970 (R-Car V3M) DPAD 0 LVDS 0 -  -
> + R8A77980 (R-Car V3H) DPAD 0 LVDS 0 -  -
>   R8A77995 (R-Car D3)  DPAD 0 LVDS 0 LVDS 1 -

-- 
Regards,

Laurent Pinchart



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

[Bug 106589] HP w2207 monitor not waking from sleep

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

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

Re: [PATCH v3 1/2] drm: Add per-plane pixel blend mode property

[Lowry Li]

On Mon, Jun 04, 2018 at 02:49:26PM +0100, Emil Velikov wrote:
> On 1 June 2018 at 13:41, Lowry Li  wrote:
> > Pixel blend modes represent the alpha blending equation
> > selection, describing how the pixels from the current
> > plane are composited with the background.
> >
> > Add a pixel_blend_mode to drm_plane_state and a
> > blend_mode_property to drm_plane, and related support
> > functions.
> >
> > Defines three blend modes in drm_blend.h.
> >
> > Signed-off-by: Lowry Li 
> > ---
> >  drivers/gpu/drm/drm_atomic.c|   4 ++
> >  drivers/gpu/drm/drm_atomic_helper.c |   1 +
> >  drivers/gpu/drm/drm_blend.c | 126 
> > 
> >  include/drm/drm_blend.h |   6 ++
> >  include/drm/drm_plane.h |   5 ++
> >  5 files changed, 142 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 07fef42..1d18389 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -785,6 +785,8 @@ static int drm_atomic_plane_set_property(struct 
> > drm_plane *plane,
> > state->src_h = val;
> > } else if (property == plane->alpha_property) {
> > state->alpha = val;
> > +   } else if (property == plane->blend_mode_property) {
> > +   state->pixel_blend_mode = val;
> > } else if (property == plane->rotation_property) {
> > if (!is_power_of_2(val & DRM_MODE_ROTATE_MASK))
> > return -EINVAL;
> > @@ -852,6 +854,8 @@ static int drm_atomic_plane_set_property(struct 
> > drm_plane *plane,
> > *val = state->src_h;
> > } else if (property == plane->alpha_property) {
> > *val = state->alpha;
> > +   } else if (property == plane->blend_mode_property) {
> > +   *val = state->pixel_blend_mode;
> > } else if (property == plane->rotation_property) {
> > *val = state->rotation;
> > } else if (property == plane->zpos_property) {
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index 130da51..7f5d463 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -3515,6 +3515,7 @@ void drm_atomic_helper_plane_reset(struct drm_plane 
> > *plane)
> > /* Reset the alpha value to fully opaque if it matters */
> > if (plane->alpha_property)
> > plane->state->alpha = 
> > plane->alpha_property->values[1];
> > +   plane->state->pixel_blend_mode = DRM_MODE_BLEND_PREMULTI;
> > }
> >  }
> >  EXPORT_SYMBOL(drm_atomic_helper_plane_reset);
> > diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> > index a16a74d..ac6f19c 100644
> > --- a/drivers/gpu/drm/drm_blend.c
> > +++ b/drivers/gpu/drm/drm_blend.c
> > @@ -107,6 +107,52 @@
> >   * planes. Without this property the primary plane is always below the 
> > cursor
> >   * plane, and ordering between all other planes is undefined.
> >   *
> > + * pixel blend mode:
> > + * Pixel blend mode is set up with 
> > drm_plane_create_blend_mode_property().
> > + * It adds a blend mode for alpha blending equation selection, 
> > describing
> > + * how the pixels from the current plane are composited with the
> > + * background.
> > + *
> > + *  Three alpha blending equations are defined:
> > + *
> > + *  "None":
> > + *  Blend formula that ignores the pixel alpha::
> > + *
> > + *  out.rgb = plane_alpha * fg.rgb +
> > + *  (1 - plane_alpha) * bg.rgb
> > + *
> > + *  "Pre-multiplied":
> > + *  Blend formula that assumes the pixel color values
> > + *  have been already pre-multiplied with the alpha
> > + *  channel values::
> > + *
> > + *  out.rgb = plane_alpha * fg.rgb +
> > + *  (1 - (plane_alpha * fg.alpha)) * bg.rgb
> > + *
> > + *  "Coverage":
> > + *  Blend formula that assumes the pixel color values have not
> > + *  been pre-multiplied and will do so when blending them to 
> > the
> > + *  background color values::
> > + *
> > + *  out.rgb = plane_alpha * fg.alpha * fg.rgb +
> > + *  (1 - (plane_alpha * fg.alpha)) * bg.rgb
> > + *
> > + *  Using the following symbols:
> > + *
> > + *  ``fg.rgb``:
> > + *  Each of the RGB component values from the plane's pixel
> > + *  ``fg.alpha``:
> > + *  Alpha component value from the plane's pixel. If the 
> > plane's
> > + *  pixel format has no alpha component, then this is assumed 
> > to be
> > + *  1.0. In these cases, this property has no effect, as all 
> > three
> > + *  equations become equivalent.
> > + *  

[Bug 105251] [Vega10] GPU lockup on boot: VMC page fault

[bugzilla-daemon]

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

--- Comment #10 from Christian König  ---
Hi everybody,

first of all please add logs as attachments and not inline into the bug report.

Then make sure that the firmware files are up to date. It looks like we
accidentally released corrupted firmware files once, but those should already
be replaced with working versions.

-- 
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 199925] system-freeze with amdgpu.dc=1 & HDMI-Output

[bugzilla-daemon]

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

Martin (martin...@gmx.com) changed:

   What|Removed |Added

 CC||martin...@gmx.com

--- Comment #1 from Martin (martin...@gmx.com) ---
I think I may be experiencing a similar problem.

I had 2 random system freezes, the kind when nothing can be done (the second
time I had the characteristic audio freeze).

Both freezes happened when I was stopping audio playback and/or the screen was
in the stand by mode. ( I was switching screen's input to Display Port which is
the PC that froze). The screen is Dell U2515H (it doesn't have speakers, I use
audio out mini-jack on the motherboard for audio output).

I haven't experiences such issues on the previous kernel version.

I don't have amdgpu.dc=1 on kernel cmdline but as I understand it it's the new
default for 4.17.0

I started getting this kind of traces in my logs:


Jun  5 08:15:16 callisto kernel: [drm:generic_reg_wait [amdgpu]] *ERROR*
REG_WAIT timeout 10us * 3000 tries - dce110_stream_encoder_dp_blank line:956
Jun  5 08:15:16 callisto kernel: WARNING: CPU: 0 PID: 1799 at
drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:195
generic_reg_wait+0xe1/0x160 [amdgpu]
Jun  5 08:15:16 callisto kernel: Modules linked in: lz4 lz4_compress zram it87
hwmon_vid vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) cpufreq_ondemand
ext4 crc16 mbcache jbd2 i2c_dev wmi_bmof amdgpu snd_hda_codec_realtek
snd_hda_codec_generic chash gpu_sched drm_kms_helper syscopyarea sysfillrect
sysimgblt fb_sys_fops snd_hda_intel ttm snd_hda_codec sundance snd_hwdep
k10temp drm mii snd_hda_core drm_panel_orientation_quirks snd_pcm snd_timer snd
wmi soundcore evdev acpi_cpufreq loop
Jun  5 08:15:16 callisto kernel: CPU: 0 PID: 1799 Comm: Xorg Tainted: G   
W  O  4.17.0 #1
Jun  5 08:15:16 callisto kernel: Hardware name: Gigabyte Technology Co., Ltd.
GA-MA770T-UD3/GA-MA770T-UD3, BIOS F8 10/18/2010
Jun  5 08:15:16 callisto kernel: RIP: 0010:generic_reg_wait+0xe1/0x160 [amdgpu]
Jun  5 08:15:16 callisto kernel: RSP: 0018:c92bb8a0 EFLAGS: 00010297
Jun  5 08:15:16 callisto kernel: RAX: 0074 RBX: 000a
RCX: 
Jun  5 08:15:16 callisto kernel: RDX: 88023fc1bea0 RSI: 88023fc15158
RDI: 88023fc15158
Jun  5 08:15:16 callisto kernel: RBP: 0010 R08: 0387
R09: 00010200
Jun  5 08:15:16 callisto kernel: R10:  R11: 0001
R12: 880234790380
Jun  5 08:15:16 callisto kernel: R13: 0bb9 R14: 0001
R15: 
Jun  5 08:15:16 callisto kernel: FS:  7f242ef01d40()
GS:88023fc0() knlGS:
Jun  5 08:15:16 callisto kernel: CS:  0010 DS:  ES:  CR0:
80050033
Jun  5 08:15:16 callisto kernel: CR2: 00e7b000 CR3: 000221bd
CR4: 06f0
Jun  5 08:15:16 callisto kernel: Call Trace:
Jun  5 08:15:16 callisto kernel:  dce110_stream_encoder_dp_blank+0x12a/0x190
[amdgpu]
Jun  5 08:15:16 callisto kernel:  core_link_disable_stream+0x53/0x270 [amdgpu]
Jun  5 08:15:16 callisto kernel:  dce110_reset_hw_ctx_wrap+0xb1/0x1c0 [amdgpu]
Jun  5 08:15:16 callisto kernel:  dce110_apply_ctx_to_hw+0x3b/0x8f0 [amdgpu]
Jun  5 08:15:16 callisto kernel:  ? amdgpu_pm_compute_clocks+0x87/0x4c0
[amdgpu]
Jun  5 08:15:16 callisto kernel:  dc_commit_state+0x2db/0x570 [amdgpu]
Jun  5 08:15:16 callisto kernel:  ? dc_stream_get_scanoutpos+0x4e/0x60 [amdgpu]
Jun  5 08:15:16 callisto kernel:  ? dm_crtc_get_scanoutpos+0x51/0x90 [amdgpu]
Jun  5 08:15:16 callisto kernel:  ? drm_calc_timestamping_constants+0xf3/0x180
[drm]
Jun  5 08:15:16 callisto kernel:  amdgpu_dm_atomic_commit_tail+0x33d/0xcd0
[amdgpu]
Jun  5 08:15:16 callisto kernel:  ? amdgpu_bo_pin_restricted+0x1cc/0x2b0
[amdgpu]
Jun  5 08:15:16 callisto kernel:  ? wait_for_common+0x111/0x190
Jun  5 08:15:16 callisto kernel:  ? wait_for_common+0x111/0x190
Jun  5 08:15:16 callisto kernel:  commit_tail+0x38/0x70 [drm_kms_helper]
Jun  5 08:15:16 callisto kernel:  drm_atomic_helper_commit+0x11d/0x130
[drm_kms_helper]
Jun  5 08:15:16 callisto kernel:  drm_atomic_connector_commit_dpms+0xe9/0x120
[drm]
Jun  5 08:15:16 callisto kernel:  drm_mode_obj_set_property_ioctl+0x152/0x250
[drm]
Jun  5 08:15:16 callisto kernel:  ? drm_mode_connector_set_obj_prop+0xa0/0xa0
[drm]
Jun  5 08:15:16 callisto kernel: 
drm_mode_connector_property_set_ioctl+0x24/0x30 [drm]
Jun  5 08:15:16 callisto kernel:  drm_ioctl_kernel+0x6b/0xd0 [drm]
Jun  5 08:15:16 callisto kernel:  ? __switch_to_asm+0x30/0x60
Jun  5 08:15:16 callisto kernel:  drm_ioctl+0x1a3/0x380 [drm]
Jun  5 08:15:16 callisto kernel:  ? drm_mode_connector_set_obj_prop+0xa0/0xa0
[drm]
Jun  5 08:15:16 callisto kernel:  ? schedule_hrtimeout_range_clock+0x99/0x100
Jun  5 08:15:16 callisto kernel:  ? __handle_mm_fault+0x47f/0xa30
Jun  5 08:15:16 callisto 

Re: [PATCH] drm/vc4: Enable the DSI module and link before other enables.

[Andrzej Hajda]

On 04.06.2018 21:44, Eric Anholt wrote:
> We want the DSI PHY to be enabled and the DSI module clocked before a
> panel or bridge's prepare() function, since most DSI panel drivers
> with a prepare() hook are doing DCS transactions inside of them.
>
> Signed-off-by: Eric Anholt 
> Cc: Kevin Quigley 
> Cc: James Hughes 
> Cc: Boris Brezillon 
> ---
>
> I'm not sure it makes sense to enable CRTCs before encoders on vc4 at
> all.  Why start scanning pixels before the encoder is ready to hear
> about VSTART?  However, this patch will hopefully unblock people
> trying to attach other panels to rpi

But this patch is about enabling encoder before panel/bridge prepare. Or
am I missing something.
Anyway I would be more precise here, MIPI-DSI bus is used for two things:
- control bus - accessing DSI device (configuration/detection,...),
- video data bus - sending video stream.

I suspect in prepare/pre_enable phase of DSI panel/bridge only control
bus should be functional, video stream transfer does not make sense.
So the best solution (I guess) would be to split DSI-encoder enable
sequence into control bus enable and video transfer enable parts and
call the former before 1st transfer request from device and the latter
in encoder enable callback. Of course there will be a problem then with
disabling sequence, ie stopping video stream should be performed in
encoder's disable, but when we should disable control bus? If we do it
in encoder's disable callback we could not perform transfers in
post_disable cb of the bridge - in most cases (maybe all currently
present in kernel) it will work, but it does not look ideal.
All this recalls me discussion that hardwiring bridge callbacks into drm
core is problematic and maybe it would be better to call downstream
callbacks explicitly from upstream element - the callback order should
depend on the local bus protocol, and should not be fixed in drm core.

Regards
Andrzej

>
>  drivers/gpu/drm/vc4/vc4_drv.h |  1 +
>  drivers/gpu/drm/vc4/vc4_dsi.c |  3 +--
>  drivers/gpu/drm/vc4/vc4_kms.c | 25 +
>  3 files changed, 27 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
> index 554a4e810d5b..e7d7bfc75acd 100644
> --- a/drivers/gpu/drm/vc4/vc4_drv.h
> +++ b/drivers/gpu/drm/vc4/vc4_drv.h
> @@ -711,6 +711,7 @@ int vc4_dpi_debugfs_regs(struct seq_file *m, void 
> *unused);
>  /* vc4_dsi.c */
>  extern struct platform_driver vc4_dsi_driver;
>  int vc4_dsi_debugfs_regs(struct seq_file *m, void *unused);
> +void vc4_dsi_prepare(struct drm_encoder *encoder);
>  
>  /* vc4_fence.c */
>  extern const struct dma_fence_ops vc4_fence_ops;
> diff --git a/drivers/gpu/drm/vc4/vc4_dsi.c b/drivers/gpu/drm/vc4/vc4_dsi.c
> index 8aa897835118..88471731e066 100644
> --- a/drivers/gpu/drm/vc4/vc4_dsi.c
> +++ b/drivers/gpu/drm/vc4/vc4_dsi.c
> @@ -875,7 +875,7 @@ static bool vc4_dsi_encoder_mode_fixup(struct drm_encoder 
> *encoder,
>   return true;
>  }
>  
> -static void vc4_dsi_encoder_enable(struct drm_encoder *encoder)
> +void vc4_dsi_prepare(struct drm_encoder *encoder)
>  {
>   struct drm_display_mode *mode = >crtc->state->adjusted_mode;
>   struct vc4_dsi_encoder *vc4_encoder = to_vc4_dsi_encoder(encoder);
> @@ -1345,7 +1345,6 @@ static const struct mipi_dsi_host_ops vc4_dsi_host_ops 
> = {
>  
>  static const struct drm_encoder_helper_funcs vc4_dsi_encoder_helper_funcs = {
>   .disable = vc4_dsi_encoder_disable,
> - .enable = vc4_dsi_encoder_enable,
>   .mode_fixup = vc4_dsi_encoder_mode_fixup,
>  };
>  
> diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
> index 8a411e5f8776..7e9b52ba3448 100644
> --- a/drivers/gpu/drm/vc4/vc4_kms.c
> +++ b/drivers/gpu/drm/vc4/vc4_kms.c
> @@ -140,6 +140,9 @@ vc4_atomic_complete_commit(struct drm_atomic_state *state)
>  {
>   struct drm_device *dev = state->dev;
>   struct vc4_dev *vc4 = to_vc4_dev(dev);
> + struct drm_connector *connector;
> + struct drm_connector_state *new_conn_state;
> + int i;
>  
>   drm_atomic_helper_wait_for_fences(dev, state, false);
>  
> @@ -151,6 +154,28 @@ vc4_atomic_complete_commit(struct drm_atomic_state 
> *state)
>  
>   drm_atomic_helper_commit_planes(dev, state, 0);
>  
> + /* Enable DSI link. */
> + for_each_new_connector_in_state(state, connector, new_conn_state, i) {
> + struct drm_encoder *encoder;
> + struct vc4_encoder *vc4_encoder;
> +
> + if (!new_conn_state->best_encoder)
> + continue;
> +
> + if (!new_conn_state->crtc->state->active ||
> + !drm_atomic_crtc_needs_modeset(new_conn_state->crtc->state))
> + continue;
> +
> + (void)connector;
> + encoder = new_conn_state->best_encoder;
> + vc4_encoder = to_vc4_encoder(encoder);
> +
> + if (vc4_encoder->type == VC4_ENCODER_TYPE_DSI0 ||
> + 

[PATCH v8 0/4] Add suppport for sn65dsi86 bridge chip and Innolux 2k edp panel

[Sandeep Panda]

Changes in current patchset:
 - Moved dsi register/attach function to bridge probe.
 - Renames and added more description to lane-mapping dt property.
 - Removed some unnecessary headers/macros from driver.

Sandeep Panda (4):
  drm/bridge: add support for sn65dsi86 bridge driver
  dt-bindings: drm/bridge: Document sn65dsi86 bridge bindings
  drm/panel: add Innolux TV123WAM panel driver support
  dt-bindings: drm/panel: Document Innolux TV123WAM panel bindings

 .../bindings/display/bridge/ti,sn65dsi86.txt   | 109 
 .../bindings/display/panel/innolux,tv123wam.txt|  20 +
 drivers/gpu/drm/bridge/Kconfig |   9 +
 drivers/gpu/drm/bridge/Makefile|   1 +
 drivers/gpu/drm/bridge/ti-sn65dsi86.c  | 666 +
 drivers/gpu/drm/panel/panel-simple.c   |  27 +
 6 files changed, 832 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
 create mode 100644 
Documentation/devicetree/bindings/display/panel/innolux,tv123wam.txt
 create mode 100644 drivers/gpu/drm/bridge/ti-sn65dsi86.c

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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

[PATCH v8 0/4] Add suppport for sn65dsi86 bridge chip and Innolux 2k edp panel

[Sandeep Panda]

Changes in current patchset:
 - Moved dsi register/attach function to bridge probe.
 - Renames and added more description to lane-mapping dt property.
 - Removed some unnecessary headers/macros from driver.

Sandeep Panda (4):
  drm/bridge: add support for sn65dsi86 bridge driver
  dt-bindings: drm/bridge: Document sn65dsi86 bridge bindings
  drm/panel: add Innolux TV123WAM panel driver support
  dt-bindings: drm/panel: Document Innolux TV123WAM panel bindings

 .../bindings/display/bridge/ti,sn65dsi86.txt   | 109 
 .../bindings/display/panel/innolux,tv123wam.txt|  20 +
 drivers/gpu/drm/bridge/Kconfig |   9 +
 drivers/gpu/drm/bridge/Makefile|   1 +
 drivers/gpu/drm/bridge/ti-sn65dsi86.c  | 666 +
 drivers/gpu/drm/panel/panel-simple.c   |  27 +
 6 files changed, 832 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
 create mode 100644 
Documentation/devicetree/bindings/display/panel/innolux,tv123wam.txt
 create mode 100644 drivers/gpu/drm/bridge/ti-sn65dsi86.c

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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

Re: [PATCH v2 5/9] xen/gntdev: Allow mappings for DMA buffers

[Boris Ostrovsky]

On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko 
>
> Allow mappings for DMA backed  buffers if grant table module
> supports such: this extends grant device to not only map buffers
> made of balloon pages, but also from buffers allocated with
> dma_alloc_xxx.
>
> Signed-off-by: Oleksandr Andrushchenko 
> ---
>  drivers/xen/gntdev.c  | 99 ++-
>  include/uapi/xen/gntdev.h | 15 ++
>  2 files changed, 112 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
> index bd56653b9bbc..9813fc440c70 100644
> --- a/drivers/xen/gntdev.c
> +++ b/drivers/xen/gntdev.c
> @@ -37,6 +37,9 @@
>  #include 
>  #include 
>  #include 
> +#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
> +#include 
> +#endif
>  
>  #include 
>  #include 
> @@ -72,6 +75,11 @@ struct gntdev_priv {
>   struct mutex lock;
>   struct mm_struct *mm;
>   struct mmu_notifier mn;
> +
> +#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
> + /* Device for which DMA memory is allocated. */
> + struct device *dma_dev;
> +#endif
>  };
>  
>  struct unmap_notify {
> @@ -96,10 +104,27 @@ struct grant_map {
>   struct gnttab_unmap_grant_ref *kunmap_ops;
>   struct page **pages;
>   unsigned long pages_vm_start;
> +
> +#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
> + /*
> +  * If dmabuf_vaddr is not NULL then this mapping is backed by DMA
> +  * capable memory.
> +  */
> +
> + struct device *dma_dev;
> + /* Flags used to create this DMA buffer: GNTDEV_DMA_FLAG_XXX. */
> + int dma_flags;
> + void *dma_vaddr;
> + dma_addr_t dma_bus_addr;
> + /* This is required for gnttab_dma_{alloc|free}_pages. */

How about

/* Needed to avoid allocation in gnttab_dma_free_pages(). */

> + xen_pfn_t *frames;
> +#endif
>  };
>  
>  static int unmap_grant_pages(struct grant_map *map, int offset, int pages);
>  
> +static struct miscdevice gntdev_miscdev;
> +
>  /* -- */
>  
>  static void gntdev_print_maps(struct gntdev_priv *priv,
> @@ -121,8 +146,27 @@ static void gntdev_free_map(struct grant_map *map)
>   if (map == NULL)
>   return;
>  
> +#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
> + if (map->dma_vaddr) {
> + struct gnttab_dma_alloc_args args;
> +
> + args.dev = map->dma_dev;
> + args.coherent = map->dma_flags & GNTDEV_DMA_FLAG_COHERENT;
> + args.nr_pages = map->count;
> + args.pages = map->pages;
> + args.frames = map->frames;
> + args.vaddr = map->dma_vaddr;
> + args.dev_bus_addr = map->dma_bus_addr;
> +
> + gnttab_dma_free_pages();
> + } else
> +#endif
>   if (map->pages)
>   gnttab_free_pages(map->count, map->pages);
> +
> +#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
> + kfree(map->frames);
> +#endif


Can this be done under if (map->dma_vaddr) ? In other words, is it
possible for dma_vaddr to be NULL and still have unallocated frames pointer?


>   kfree(map->pages);
>   kfree(map->grants);
>   kfree(map->map_ops);
> @@ -132,7 +176,8 @@ static void gntdev_free_map(struct grant_map *map)
>   kfree(map);
>  }
>  
> -static struct grant_map *gntdev_alloc_map(struct gntdev_priv *priv, int 
> count)
> +static struct grant_map *gntdev_alloc_map(struct gntdev_priv *priv, int 
> count,
> +   int dma_flags)
>  {
>   struct grant_map *add;
>   int i;
> @@ -155,6 +200,37 @@ static struct grant_map *gntdev_alloc_map(struct 
> gntdev_priv *priv, int count)
>   NULL == add->pages)
>   goto err;
>  
> +#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
> + add->dma_flags = dma_flags;
> +
> + /*
> +  * Check if this mapping is requested to be backed
> +  * by a DMA buffer.
> +  */
> + if (dma_flags & (GNTDEV_DMA_FLAG_WC | GNTDEV_DMA_FLAG_COHERENT)) {
> + struct gnttab_dma_alloc_args args;
> +
> + add->frames = kcalloc(count, sizeof(add->frames[0]),
> +   GFP_KERNEL);
> + if (!add->frames)
> + goto err;
> +
> + /* Remember the device, so we can free DMA memory. */
> + add->dma_dev = priv->dma_dev;
> +
> + args.dev = priv->dma_dev;
> + args.coherent = dma_flags & GNTDEV_DMA_FLAG_COHERENT;
> + args.nr_pages = count;
> + args.pages = add->pages;
> + args.frames = add->frames;
> +
> + if (gnttab_dma_alloc_pages())
> + goto err;
> +
> + add->dma_vaddr = args.vaddr;
> + add->dma_bus_addr = args.dev_bus_addr;
> + } else
> +#endif
>   if (gnttab_alloc_pages(count, add->pages))
>   goto err;
>  
> @@ -325,6 +401,14 @@ static int map_grant_pages(struct grant_map *map)
>   map->unmap_ops[i].handle = 

Re: [PATCH v2 8/9] xen/gntdev: Implement dma-buf import functionality

[Boris Ostrovsky]

On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote:
>  /* -- */
>  
> +static int
> +dmabuf_imp_grant_foreign_access(struct page **pages, u32 *refs,
> + int count, int domid)
> +{
> + grant_ref_t priv_gref_head;
> + int i, ret;
> +
> + ret = gnttab_alloc_grant_references(count, _gref_head);
> + if (ret < 0) {
> + pr_err("Cannot allocate grant references, ret %d\n", ret);
> + return ret;
> + }
> +
> + for (i = 0; i < count; i++) {
> + int cur_ref;
> +
> + cur_ref = gnttab_claim_grant_reference(_gref_head);
> + if (cur_ref < 0) {
> + ret = cur_ref;
> + pr_err("Cannot claim grant reference, ret %d\n", ret);
> + goto out;
> + }
> +
> + gnttab_grant_foreign_access_ref(cur_ref, domid,
> + xen_page_to_gfn(pages[i]), 0);
> + refs[i] = cur_ref;
> + }
> +
> + ret = 0;

return 0?

> +
> +out:
> + gnttab_free_grant_references(priv_gref_head);
> + return ret;
> +}
> +

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

[PATCH v8 3/4] drm/panel: add Innolux TV123WAM panel driver support

[Sandeep Panda]

Add support for Innolux TV123WAM, which is a 12.3" eDP
display panel with 2160x1440 resolution.

Changes in v1:
 - Add the compatibility string, display_mode and panel_desc
   structures in alphabetical order (Sean Paul).

Signed-off-by: Sandeep Panda 
---
 drivers/gpu/drm/panel/panel-simple.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 234af81..8c72270 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1190,6 +1190,30 @@ static void panel_simple_shutdown(struct device *dev)
},
 };
 
+static const struct drm_display_mode innolux_tv123wam_mode = {
+   .clock = 206016,
+   .hdisplay = 2160,
+   .hsync_start = 2160 + 48,
+   .hsync_end = 2160 + 48 + 32,
+   .htotal = 2160 + 48 + 32 + 80,
+   .vdisplay = 1440,
+   .vsync_start = 1440 + 3,
+   .vsync_end = 1440 + 3 + 10,
+   .vtotal = 1440 + 3 + 10 + 27,
+   .vrefresh = 60,
+   .flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC,
+};
+
+static const struct panel_desc innolux_tv123wam = {
+   .modes = _tv123wam_mode,
+   .num_modes = 1,
+   .bpc = 8,
+   .size = {
+   .width = 259,
+   .height = 173,
+   },
+};
+
 static const struct drm_display_mode innolux_zj070na_01p_mode = {
.clock = 51501,
.hdisplay = 1024,
@@ -2037,6 +2061,9 @@ static void panel_simple_shutdown(struct device *dev)
.compatible = "innolux,n156bge-l21",
.data = _n156bge_l21,
}, {
+   .compatible = "innolux,tv123wam",
+   .data = _tv123wam,
+   }, {
.compatible = "innolux,zj070na-01p",
.data = _zj070na_01p,
}, {
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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

[PATCH v8 1/4] drm/bridge: add support for sn65dsi86 bridge driver

[Sandeep Panda]

Add support for TI's sn65dsi86 dsi2edp bridge chip.
The chip converts DSI transmitted signal to eDP signal,
which is fed to the connected eDP panel.

This chip can be controlled via either i2c interface or
dsi interface. Currently in driver all the control registers
are being accessed through i2c interface only.
Also as of now HPD support has not been added to bridge
chip driver.

Changes in v1:
 - Split the dt-bindings and the driver support into separate patches
   (Andrzej Hajda).
 - Use of gpiod APIs to parse and configure gpios instead of obsolete ones
   (Andrzej Hajda).
 - Use macros to define the register offsets (Andrzej Hajda).

Changes in v2:
 - Separate out edp panel specific HW resource handling from bridge
   driver and create a separate edp panel drivers to handle panel
   specific mode information and HW resources (Sean Paul).
 - Replace pr_* APIs to DRM_* APIs to log error or debug information
   (Sean Paul).
 - Remove some of the unnecessary structure/variable from driver (Sean
   Paul).
 - Rename the function and structure prefix "sn65dsi86" to "ti_sn_bridge"
   (Sean Paul / Rob Herring).
 - Remove most of the hard-coding and modified the bridge init sequence
   based on current mode (Sean Paul).
 - Remove the existing function to retrieve the EDID data and
   implemented this as an i2c_adapter and use drm_get_edid() (Sean Paul).
 - Remove the dummy irq handler implementation, will add back the
   proper irq handling later (Sean Paul).
 - Capture the required enable gpios in a single array based on dt entry
   instead of having individual descriptor for each gpio (Sean Paul).

Changes in v3:
 - Remove usage of irq_gpio and replace it as "interrupts" property (Rob
   Herring).
 - Remove the unnecessary header file inclusions (Sean Paul).
 - Rearrange the header files in alphabetical order (Sean Paul).
 - Use regmap interface to perform i2c transactions.
 - Update Copyright/License field and address other review comments
   (Jordan Crouse).

Changes in v4:
 - Update License/Copyright (Sean Paul).
 - Add Kconfig and Makefile changes (Sean Paul).
 - Drop i2c gpio handling from this bridge driver, since i2c sda/scl gpios
   will be handled by i2c master.
 - Update required supplies names.
 - Remove unnecessary goto statements (Sean Paul).
 - Add mutex lock to power_ctrl API to avoid race conditions (Sean
   Paul).
 - Add support to parse reference clk frequency from dt(optional).
 - Update the bridge chip enable/disable sequence.

Changes in v5:
 - Fixed Kbuild test service reported warnings.

Changes in v6:
 - Use PM runtime based ref-counting instead of local ref_count mechanism
   (Stephen Boyd).
 - Clean up some debug logs and indentations (Sean Paul).
 - Simplify dp rate calculation (Sean Paul).
 - Add support to configure refclk based on input REFCLK pin or DACP/N
   pin (Stephen Boyd).

Changes in v7:
 - Use static supply entries instead of dynamic allocation (Andrzej
   Hajda).
 - Defer bridge driver probe if panel is not probed (Andrzej Hajda).
 - Update of_graph APIs for correct node reference management. (Andrzej
   Hajda).
 - Remove local display_mode object (Andrzej Hajda).
 - Remove version id check function from driver.

Changes in v8:
 - Move dsi register/attach function to bridge driver probe (Andrzej
   Hajda).
 - Introduce a new helper function to write 16bit words into consecutive
   registers (Andrzej Hajda).
 - Remove unnecessary macros (Andrzej Hajda).

Signed-off-by: Sandeep Panda 
---
 drivers/gpu/drm/bridge/Kconfig|   9 +
 drivers/gpu/drm/bridge/Makefile   |   1 +
 drivers/gpu/drm/bridge/ti-sn65dsi86.c | 666 ++
 3 files changed, 676 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/ti-sn65dsi86.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 3b99d5a..8153150 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -108,6 +108,15 @@ config DRM_TI_TFP410
---help---
  Texas Instruments TFP410 DVI/HDMI Transmitter driver
 
+config DRM_TI_SN65DSI86
+   tristate "TI SN65DSI86 DSI to eDP bridge"
+   depends on OF
+   select DRM_KMS_HELPER
+   select REGMAP_I2C
+   select DRM_PANEL
+   ---help---
+ Texas Instruments SN65DSI86 DSI to eDP Bridge driver
+
 source "drivers/gpu/drm/bridge/analogix/Kconfig"
 
 source "drivers/gpu/drm/bridge/adv7511/Kconfig"
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 373eb28..3711be8 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -12,4 +12,5 @@ obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
 obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
 obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
 obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
+obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o
 obj-y += synopsys/
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c 
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
new file mode 100644
index 

Re: [PATCH v2 9/9] xen/gntdev: Expose gntdev's dma-buf API for in-kernel use

[Boris Ostrovsky]

On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko 
>
> Allow creating grant device context for use by kernel modules which
> require functionality, provided by gntdev. Export symbols for dma-buf
> API provided by the module.

Can you give an example of who'd be using these interfaces?


-boris

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

Re: [PATCH v2 7/9] xen/gntdev: Implement dma-buf export functionality

[Boris Ostrovsky]

On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko 
>
> 1. Create a dma-buf from grant references provided by the foreign
>domain. By default dma-buf is backed by system memory pages, but
>by providing GNTDEV_DMA_FLAG_XXX flags it can also be created
>as a DMA write-combine/coherent buffer, e.g. allocated with
>corresponding dma_alloc_xxx API.
>Export the resulting buffer as a new dma-buf.
>
> 2. Implement waiting for the dma-buf to be released: block until the
>dma-buf with the file descriptor provided is released.
>If within the time-out provided the buffer is not released then
>-ETIMEDOUT error is returned. If the buffer with the file descriptor
>does not exist or has already been released, then -ENOENT is
>returned. For valid file descriptors this must not be treated as
>error.
>
> Signed-off-by: Oleksandr Andrushchenko 
> ---
>  drivers/xen/gntdev-dmabuf.c | 393 +++-
>  drivers/xen/gntdev-dmabuf.h |   9 +-
>  drivers/xen/gntdev.c|  90 -
>  3 files changed, 486 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/xen/gntdev-dmabuf.c b/drivers/xen/gntdev-dmabuf.c
> index 6bedd1387bd9..f612468879b4 100644
> --- a/drivers/xen/gntdev-dmabuf.c
> +++ b/drivers/xen/gntdev-dmabuf.c
> @@ -3,15 +3,58 @@
>  /*
>   * Xen dma-buf functionality for gntdev.
>   *
> + * DMA buffer implementation is based on drivers/gpu/drm/drm_prime.c.
> + *
>   * Copyright (c) 2018 Oleksandr Andrushchenko, EPAM Systems Inc.
>   */
>  
> +#include 
>  #include 
>  
>  #include "gntdev-dmabuf.h"
>  
> +struct gntdev_dmabuf {
> + struct gntdev_dmabuf_priv *priv;
> + struct dma_buf *dmabuf;
> + struct list_head next;
> + int fd;
> +
> + union {
> + struct {
> + /* Exported buffers are reference counted. */
> + struct kref refcount;
> +
> + struct gntdev_priv *priv;
> + struct grant_map *map;
> + void (*release)(struct gntdev_priv *priv,
> + struct grant_map *map);
> + } exp;
> + } u;
> +
> + /* Number of pages this buffer has. */
> + int nr_pages;
> + /* Pages of this buffer. */
> + struct page **pages;
> +};
> +
> +struct gntdev_dmabuf_wait_obj {
> + struct list_head next;
> + struct gntdev_dmabuf *gntdev_dmabuf;
> + struct completion completion;
> +};
> +
> +struct gntdev_dmabuf_attachment {
> + struct sg_table *sgt;
> + enum dma_data_direction dir;
> +};
> +
>  struct gntdev_dmabuf_priv {
> - int dummy;
> + /* List of exported DMA buffers. */
> + struct list_head exp_list;
> + /* List of wait objects. */
> + struct list_head exp_wait_list;
> + /* This is the lock which protects dma_buf_xxx lists. */
> + struct mutex lock;
>  };
>  
>  /* -- */
> @@ -22,19 +65,359 @@ struct gntdev_dmabuf_priv {
>  /* Implementation of wait for exported DMA buffer to be released. */
>  /* -- */
>  
> +static void dmabuf_exp_release(struct kref *kref);
> +
> +static struct gntdev_dmabuf_wait_obj *
> +dmabuf_exp_wait_obj_new(struct gntdev_dmabuf_priv *priv,
> + struct gntdev_dmabuf *gntdev_dmabuf)
> +{
> + struct gntdev_dmabuf_wait_obj *obj;
> +
> + obj = kzalloc(sizeof(*obj), GFP_KERNEL);
> + if (!obj)
> + return ERR_PTR(-ENOMEM);
> +
> + init_completion(>completion);
> + obj->gntdev_dmabuf = gntdev_dmabuf;
> +
> + mutex_lock(>lock);
> + list_add(>next, >exp_wait_list);
> + /* Put our reference and wait for gntdev_dmabuf's release to fire. */
> + kref_put(_dmabuf->u.exp.refcount, dmabuf_exp_release);
> + mutex_unlock(>lock);
> + return obj;
> +}
> +
> +static void dmabuf_exp_wait_obj_free(struct gntdev_dmabuf_priv *priv,
> +  struct gntdev_dmabuf_wait_obj *obj)
> +{
> + struct gntdev_dmabuf_wait_obj *cur_obj, *q;
> +
> + mutex_lock(>lock);
> + list_for_each_entry_safe(cur_obj, q, >exp_wait_list, next)
> + if (cur_obj == obj) {
> + list_del(>next);
> + kfree(obj);
> + break;
> + }
> + mutex_unlock(>lock);
> +}
> +
> +static int dmabuf_exp_wait_obj_wait(struct gntdev_dmabuf_wait_obj *obj,
> + u32 wait_to_ms)
> +{
> + if (wait_for_completion_timeout(>completion,
> + msecs_to_jiffies(wait_to_ms)) <= 0)
> + return -ETIMEDOUT;
> +
> + return 0;
> +}
> +
> +static void dmabuf_exp_wait_obj_signal(struct gntdev_dmabuf_priv *priv,
> +struct gntdev_dmabuf *gntdev_dmabuf)
> +{
> + struct gntdev_dmabuf_wait_obj *obj, *q;
> +
> + 

[PATCH v8 2/4] dt-bindings: drm/bridge: Document sn65dsi86 bridge bindings

[Sandeep Panda]

Document the bindings used for the sn65dsi86 DSI to eDP bridge.

Changes in v1:
 - Rephrase the dt-binding descriptions to be more inline with existing
   bindings (Andrzej Hajda).
 - Add missing dt-binding that are parsed by corresponding driver
   (Andrzej Hajda).

Changes in v2:
 - Remove edp panel specific dt-binding entries. Only keep bridge
   specific entries (Sean Paul).
 - Remove custom-modes dt entry since its usage is removed from driver also 
(Sean Paul).
 - Remove is-pluggable dt entry since this will not be needed anymore (Sean 
Paul).

Changes in v3:
 - Remove irq-gpio dt entry and instead populate is an interrupt
   property (Rob Herring).

Changes in v4:
 - Add link to bridge chip datasheet (Stephen Boyd)
 - Add vpll and vcc regulator supply bindings (Stephen Boyd)
 - Add ref clk optional dt binding (Stephen Boyd)
 - Add gpio-controller optional dt binding (Stephen Boyd)

Changes in v5:
 - Use clock property to specify the input refclk (Stephen Boyd).
 - Update gpio cell and pwm cell numbers (Stephen Boyd).

Changes in v6:
 - Add property to mention the lane mapping scheme and polarity inversion
   (Stephen Boyd).

Changes in v7:
 - Detail description of lane mapping scheme dt property (Andrzej
   Hajda/ Rob Herring).
 - Removed HDP gpio binding, since the bridge uses IRQ signal to
   determine HPD, and IRQ property is already documented in binding.

Signed-off-by: Sandeep Panda 
---
 .../bindings/display/bridge/ti,sn65dsi86.txt   | 109 +
 1 file changed, 109 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt

diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt 
b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
new file mode 100644
index 000..33329f9
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
@@ -0,0 +1,109 @@
+SN65DSI86 DSI to eDP bridge chip
+
+
+This is the binding for Texas Instruments SN65DSI86 bridge.
+http://www.ti.com/general/docs/lit/getliterature.tsp?genericPartNumber=sn65dsi86=pdf
+
+Required properties:
+- compatible: Must be "ti,sn65dsi86"
+- reg: i2c address of the chip, 0x2d as per datasheet
+- enable-gpios: OF device-tree gpio specification for bridge_en pin (active 
high)
+
+- vccio-supply: A 1.8V supply that powers up the digital IOs.
+- vpll-supply: A 1.8V supply that powers up the displayport PLL.
+- vcca-supply: A 1.2V supply that powers up the analog circuits.
+- vcc-supply: A 1.2V supply that powers up the digital core.
+
+Optional properties:
+- interrupts: Specifier for the SN65DSI86 interrupt line.
+
+- ddc-i2c-bus: phandle of the I2C controller used for DDC EDID probing
+
+- gpio-controller: Marks the device has a GPIO controller.
+- #gpio-cells: Should be two. The first cell is the pin number and
+   the second cell is used to specify flags.
+   See ../../gpio/gpio.txt for more information.
+- #pwm-cells : Should be one. See ../../pwm/pwm.txt for description of
+   the cell formats.
+
+- clock-names: should be "refclk"
+- clocks: Specification for input reference clock. The reference
+ clock rate must be 12 MHz, 19.2 MHz, 26 MHz, 27 MHz or 38.4 MHz.
+
+- lane-mapping: Specification to describe the logical to physical lane
+   mapping scheme and polarity inversion of eDP lanes on PCB.
+   Each pair present at index n (where n lies between 0 and 3)
+   describes the lane mapping of logical lane to physical lane n
+   and the polarity(it should be either 1 or 0) of the physical 
lane n.
+
+   For example:
+   lane-mapping = <2 1>,
+   <1 0>,
+   <3 1>,
+   <0 0>;
+
+   The above mapping describes that logical lane 2 is mapped to
+   physical lane 0 and polarity of physical lane 0 is inverted,
+   logical lane 1 is mapped to physical lane 1 and polarity of
+   physical lane 1 is normal, logical lane 3 is mapped to physical
+   lane 2 and polarity of physical lane 2 is inverted, logical 
lane 0
+   is mapped to physical lane 4 and polarity of physical lane 3 is 
normal.
+
+   If this property is not mentioned then it is assumed that 
physical
+   lanes 0 through 3 are mapped to logical lanes 0 through 3 and 
polarity
+   of all physical lanes is normal.
+
+Required nodes:
+This device has two video ports. Their connections are modelled using the
+OF graph bindings specified in Documentation/devicetree/bindings/graph.txt.
+
+- Video port 0 for DSI input
+- Video port 1 for eDP output
+
+Example
+---
+
+edp-bridge@2d {
+   compatible = "ti,sn65dsi86";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x2d>;
+
+   enable-gpios 

Re: [PATCH v2 4/9] xen/grant-table: Allow allocating buffers suitable for DMA

[Boris Ostrovsky]

On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko 
>
> Extend grant table module API to allow allocating buffers that can
> be used for DMA operations and mapping foreign grant references
> on top of those.
> The resulting buffer is similar to the one allocated by the balloon
> driver in terms that proper memory reservation is made
> ({increase|decrease}_reservation and VA mappings updated if needed).
> This is useful for sharing foreign buffers with HW drivers which
> cannot work with scattered buffers provided by the balloon driver,
> but require DMAable memory instead.
>
> Signed-off-by: Oleksandr Andrushchenko 
> ---
>  drivers/xen/Kconfig   |  13 +
>  drivers/xen/grant-table.c | 109 ++
>  include/xen/grant_table.h |  18 +++
>  3 files changed, 140 insertions(+)
>
> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index e5d0c28372ea..39536ddfbce4 100644
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -161,6 +161,19 @@ config XEN_GRANT_DEV_ALLOC
> to other domains. This can be used to implement frontend drivers
> or as part of an inter-domain shared memory channel.
>  
> +config XEN_GRANT_DMA_ALLOC
> + bool "Allow allocating DMA capable buffers with grant reference module"
> + depends on XEN && HAS_DMA
> + help
> +   Extends grant table module API to allow allocating DMA capable
> +   buffers and mapping foreign grant references on top of it.
> +   The resulting buffer is similar to one allocated by the balloon
> +   driver in terms that proper memory reservation is made
> +   ({increase|decrease}_reservation and VA mappings updated if needed).
> +   This is useful for sharing foreign buffers with HW drivers which
> +   cannot work with scattered buffers provided by the balloon driver,
> +   but require DMAable memory instead.
> +
>  config SWIOTLB_XEN
>   def_bool y
>   select SWIOTLB
> diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> index dbb48a89e987..5658e58d9cc6 100644
> --- a/drivers/xen/grant-table.c
> +++ b/drivers/xen/grant-table.c
> @@ -45,6 +45,9 @@
>  #include 
>  #include 
>  #include 
> +#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
> +#include 
> +#endif
>  
>  #include 
>  #include 
> @@ -57,6 +60,7 @@
>  #ifdef CONFIG_X86
>  #include 
>  #endif
> +#include 
>  #include 
>  #include 
>  
> @@ -811,6 +815,73 @@ int gnttab_alloc_pages(int nr_pages, struct page **pages)
>  }
>  EXPORT_SYMBOL_GPL(gnttab_alloc_pages);
>  
> +#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
> +/**
> + * gnttab_dma_alloc_pages - alloc DMAable pages suitable for grant mapping 
> into
> + * @args: arguments to the function
> + */
> +int gnttab_dma_alloc_pages(struct gnttab_dma_alloc_args *args)
> +{
> + unsigned long pfn, start_pfn;
> + size_t size;
> + int i, ret;
> +
> + size = args->nr_pages << PAGE_SHIFT;
> + if (args->coherent)
> + args->vaddr = dma_alloc_coherent(args->dev, size,
> +  >dev_bus_addr,
> +  GFP_KERNEL | __GFP_NOWARN);
> + else
> + args->vaddr = dma_alloc_wc(args->dev, size,
> +>dev_bus_addr,
> +GFP_KERNEL | __GFP_NOWARN);
> + if (!args->vaddr) {
> + pr_err("Failed to allocate DMA buffer of size %zu\n", size);
> + return -ENOMEM;
> + }
> +
> + start_pfn = __phys_to_pfn(args->dev_bus_addr);
> + for (pfn = start_pfn, i = 0; pfn < start_pfn + args->nr_pages;
> + pfn++, i++) {
> + struct page *page = pfn_to_page(pfn);
> +
> + args->pages[i] = page;
> + args->frames[i] = xen_page_to_gfn(page);
> + xenmem_reservation_scrub_page(page);
> + }
> +
> + xenmem_reservation_va_mapping_reset(args->nr_pages, args->pages);
> +
> + ret = xenmem_reservation_decrease(args->nr_pages, args->frames);
> + if (ret != args->nr_pages) {
> + pr_err("Failed to decrease reservation for DMA buffer\n");
> + ret = -EFAULT;
> + goto fail_free_dma;
> + }
> +
> + ret = gnttab_pages_set_private(args->nr_pages, args->pages);
> + if (ret < 0)
> + goto fail_clear_private;
> +
> + return 0;
> +
> +fail_clear_private:
> + gnttab_pages_clear_private(args->nr_pages, args->pages);
> +fail_free_dma:
> + xenmem_reservation_increase(args->nr_pages, args->frames);
> + xenmem_reservation_va_mapping_update(args->nr_pages, args->pages,
> +  args->frames);
> + if (args->coherent)
> + dma_free_coherent(args->dev, size,
> +   args->vaddr, args->dev_bus_addr);
> + else
> + dma_free_wc(args->dev, size,
> + args->vaddr, args->dev_bus_addr);
> + return 

Re: [PATCH v2 6/9] xen/gntdev: Add initial support for dma-buf UAPI

[Boris Ostrovsky]

On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko 
>
> Add UAPI and IOCTLs for dma-buf grant device driver extension:
> the extension allows userspace processes and kernel modules to
> use Xen backed dma-buf implementation. With this extension grant
> references to the pages of an imported dma-buf can be exported
> for other domain use and grant references coming from a foreign
> domain can be converted into a local dma-buf for local export.
> Implement basic initialization and stubs for Xen DMA buffers'
> support.


It would be very helpful if people advocating for this interface
reviewed it as well.


>
> Signed-off-by: Oleksandr Andrushchenko 
> ---
>  drivers/xen/Kconfig |  10 +++
>  drivers/xen/Makefile|   1 +
>  drivers/xen/gntdev-dmabuf.c |  75 +++
>  drivers/xen/gntdev-dmabuf.h |  41 +++
>  drivers/xen/gntdev.c| 142 
>  include/uapi/xen/gntdev.h   |  91 +++
>  6 files changed, 360 insertions(+)
>  create mode 100644 drivers/xen/gntdev-dmabuf.c
>  create mode 100644 drivers/xen/gntdev-dmabuf.h
>
> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index 39536ddfbce4..52d64e4b6b81 100644
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -152,6 +152,16 @@ config XEN_GNTDEV
>   help
> Allows userspace processes to use grants.
>  
> +config XEN_GNTDEV_DMABUF
> + bool "Add support for dma-buf grant access device driver extension"
> + depends on XEN_GNTDEV && XEN_GRANT_DMA_ALLOC && DMA_SHARED_BUFFER


Is there a reason to have XEN_GRANT_DMA_ALLOC without XEN_GNTDEV_DMABUF?


> + help
> +   Allows userspace processes and kernel modules to use Xen backed
> +   dma-buf implementation. With this extension grant references to
> +   the pages of an imported dma-buf can be exported for other domain
> +   use and grant references coming from a foreign domain can be
> +   converted into a local dma-buf for local export.
> +
>  config XEN_GRANT_DEV_ALLOC
>   tristate "User-space grant reference allocator driver"
>   depends on XEN
> diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
> index 3c87b0c3aca6..33afb7b2b227 100644
> --- a/drivers/xen/Makefile
> +++ b/drivers/xen/Makefile
> @@ -41,5 +41,6 @@ obj-$(CONFIG_XEN_PVCALLS_BACKEND)   += pvcalls-back.o
>  obj-$(CONFIG_XEN_PVCALLS_FRONTEND)   += pvcalls-front.o
>  xen-evtchn-y := evtchn.o
>  xen-gntdev-y := gntdev.o
> +xen-gntdev-$(CONFIG_XEN_GNTDEV_DMABUF)   += gntdev-dmabuf.o
>  xen-gntalloc-y   := gntalloc.o
>  xen-privcmd-y:= privcmd.o
> diff --git a/drivers/xen/gntdev-dmabuf.c b/drivers/xen/gntdev-dmabuf.c
> new file mode 100644
> index ..6bedd1387bd9
> --- /dev/null
> +++ b/drivers/xen/gntdev-dmabuf.c
> @@ -0,0 +1,75 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +/*
> + * Xen dma-buf functionality for gntdev.
> + *
> + * Copyright (c) 2018 Oleksandr Andrushchenko, EPAM Systems Inc.
> + */
> +
> +#include 
> +
> +#include "gntdev-dmabuf.h"
> +
> +struct gntdev_dmabuf_priv {
> + int dummy;
> +};
> +
> +/* -- */
> +/* DMA buffer export support. */
> +/* -- */
> +
> +/* -- */
> +/* Implementation of wait for exported DMA buffer to be released. */
> +/* -- */

Why this comment style?

> +
> +int gntdev_dmabuf_exp_wait_released(struct gntdev_dmabuf_priv *priv, int fd,
> + int wait_to_ms)
> +{
> + return -EINVAL;
> +}
> +
> +/* -- */
> +/* DMA buffer export support. */
> +/* -- */
> +
> +int gntdev_dmabuf_exp_from_pages(struct gntdev_dmabuf_export_args *args)
> +{
> + return -EINVAL;
> +}
> +
> +/* -- */
> +/* DMA buffer import support. */
> +/* -- */
> +
> +struct gntdev_dmabuf *
> +gntdev_dmabuf_imp_to_refs(struct gntdev_dmabuf_priv *priv, struct device 
> *dev,
> +   int fd, int count, int domid)
> +{
> + return ERR_PTR(-ENOMEM);
> +}
> +
> +u32 *gntdev_dmabuf_imp_get_refs(struct gntdev_dmabuf *gntdev_dmabuf)
> +{
> + return NULL;
> +}
> +
> +int gntdev_dmabuf_imp_release(struct gntdev_dmabuf_priv *priv, u32 fd)
> +{
> + return -EINVAL;
> +}
> +
> +struct gntdev_dmabuf_priv *gntdev_dmabuf_init(void)
> +{
> + struct 

[PATCH v8 4/4] dt-bindings: drm/panel: Document Innolux TV123WAM panel bindings

[Sandeep Panda]

Innolux TV123WAM is a 12.3" eDP display panel with
2160x1440 resolution, which can be supported by simple
panel driver.

Changes in v1:
 - Make use of simple panel driver instead of creating
   a new driver for this panel (Sean Paul).
 - Combine dt-binding and driver changes into one patch
   as done by other existing panel support changes.

Changes in v2:
 - Separate driver change from dt-binding documentation (Rob Herring).
 - Add the properties from simple-panel binding that are applicable to
   this panel (Rob Herring).

Signed-off-by: Sandeep Panda 
Reviewed-by: Rob Herring 
---
 .../bindings/display/panel/innolux,tv123wam.txt  | 20 
 1 file changed, 20 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/innolux,tv123wam.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/innolux,tv123wam.txt 
b/Documentation/devicetree/bindings/display/panel/innolux,tv123wam.txt
new file mode 100644
index 000..a9b3526
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/innolux,tv123wam.txt
@@ -0,0 +1,20 @@
+Innolux TV123WAM 12.3 inch eDP 2K display panel
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
+
+Required properties:
+- compatible: should be "innolux,tv123wam"
+- power-supply: regulator to provide the supply voltage
+
+Optional properties:
+- enable-gpios: GPIO pin to enable or disable the panel
+- backlight: phandle of the backlight device attached to the panel
+
+Example:
+   panel_edp: panel-edp {
+   compatible = "innolux,tv123wam";
+   enable-gpios = < 31 GPIO_ACTIVE_LOW>;
+   power-supply = <_l2>;
+   backlight = <>;
+   };
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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

Re: [PATCH] drm/amdgpu: Grab/put runtime PM references in atomic_commit_tail()

[Christian König]

Am 04.06.2018 um 21:35 schrieb Lyude Paul:

So, unfortunately I recently made the discovery that in the upstream
kernel, the only reason that amdgpu is not currently suffering from
issues with runtime PM putting the GPU into suspend while it's driving
displays is due to the fact that on most prime systems, we have sound
devices associated with the GPU that hold their own runtime PM ref for
the GPU.

What this means however, is that in the event that there isn't any kind
of sound device active (which can easily be reproduced by building a
kernel with sound drivers disabled), the GPU will fall asleep even when
there's displays active. This appears to be in part due to the fact that
amdgpu has not actually ever relied on it's rpm_idle() function to be
the only thing keeping it running, and normally grabs it's own power
references whenever there are displays active (as can be seen with the
original pre-DC codepath in amdgpu_display_crtc_set_config() in
amdgpu_display.c). This means it's very likely that this bug was
introduced during the switch over the DC.

So to fix this, we start grabbing runtime PM references every time we
enable a previously disabled CRTC in atomic_commit_tail(). This appears
to be the correct solution, as it matches up with what i915 does in
i915/intel_runtime_pm.c.

The one sideaffect of this is that we ignore the variable that the
pre-DC code used to use for tracking when it needed runtime PM refs,
adev->have_disp_power_ref. This is mainly because there's no way for a
driver to tell whether or not all of it's CRTCs are enabled or disabled
when we've begun committing an atomic state, as there may be CRTC
commits happening in parallel that aren't contained within the atomic
state being committed. So, it's safer to just get/put a reference for
each CRTC being enabled or disabled in the new atomic state.

Signed-off-by: Lyude Paul 


The final decision is with Harray, but at least the explanation makes 
perfect sense to me.


Acked-by: Christian König .

Harry do you want to pick that up and push it into our internal branch 
while Alex is on vacation or should I do that?


Regards,
Christian.


---
As a note, I'm not entirely happy with this fix and I wouldn't be
surprised if I missed something while looking through amdgpu. So, please
don't hesistate to suggest a better fix :).

  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 13 +
  1 file changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 1dd1142246c2..361b81ef6997 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -46,6 +46,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #include 

  #include 
@@ -4211,6 +4212,8 @@ static void amdgpu_dm_atomic_commit_tail(struct 
drm_atomic_state *state)
if (dm_old_crtc_state->stream)
remove_stream(adev, acrtc, 
dm_old_crtc_state->stream);
  
+			pm_runtime_get_noresume(dev->dev);

+
acrtc->enabled = true;
acrtc->hw_mode = new_crtc_state->mode;
crtc->hwmode = new_crtc_state->mode;
@@ -4396,6 +4399,16 @@ static void amdgpu_dm_atomic_commit_tail(struct 
drm_atomic_state *state)
drm_atomic_helper_wait_for_flip_done(dev, state);
  
  	drm_atomic_helper_cleanup_planes(dev, state);

+
+   /* Finally, drop a runtime PM reference for each newly disabled CRTC,
+* so we can put the GPU into runtime suspend if we're not driving any
+* displays anymore
+*/
+   pm_runtime_mark_last_busy(dev->dev);
+   for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state, 
new_crtc_state, i) {
+   if (old_crtc_state->active && !new_crtc_state->active)
+   pm_runtime_put_autosuspend(dev->dev);
+   }
  }
  
  


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