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

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=99553
Bug 99553 depends on bug 106209, which changed state.

Bug 106209 Summary: [opencl] [llvm-svn] build failure   undefined reference to 
`clang::FrontendTimesIsEnabled'
https://bugs.freedesktop.org/show_bug.cgi?id=106209

   What|Removed |Added

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

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

[git pull] drm fix for mmap regression

[Dave Airlie]

Hi Linus,

This patch fixes the mmap regression reported to me on irc by an i686
kernel user today, he's tested the fix works, and I've audited all the
drm drivers for the bad mmap usage and since we use the mmap offset as
a lookup in a table we aren't inclined to have anything bad in there.

Thanks,
Dave.

The following changes since commit 67b8d5c7081221efa252e111cd52532ec6d4266f:

  Linux 4.17-rc5 (2018-05-13 16:15:17 -0700)

are available in the Git repository at:

  git://people.freedesktop.org/~airlied/linux
tags/drm-fixes-for-v4.17-rc6-urgent

for you to fetch changes up to 76ef6b28ea4f81c3d511866a9b31392caa833126:

  drm: set FMODE_UNSIGNED_OFFSET for drm files (2018-05-15 14:46:04 +1000)


urgent i686 mmap fix for drm drivers


Dave Airlie (1):
  drm: set FMODE_UNSIGNED_OFFSET for drm files

 drivers/gpu/drm/drm_file.c | 1 +
 1 file changed, 1 insertion(+)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/1] drm/mediatek: Add support for mediatek SOC MT2712

[CK Hu]

Hi, Stu:

I've some inline comments.

On Mon, 2018-05-14 at 17:59 +0800, Stu Hsieh wrote:
> This patch add support for the Mediatek MT2712 DISP subsystem.
> There are two OVL engine and three disp output in MT2712.
> 
> Signed-off-by: Stu Hsieh 
> ---
>  drivers/gpu/drm/mediatek/mtk_drm_ddp.c  | 77 
> ++---
>  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c |  4 ++
>  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h |  3 ++
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c  | 44 +
>  drivers/gpu/drm/mediatek/mtk_drm_drv.h  |  7 ++-
>  5 files changed, 127 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index 8130f3dab661..641f4361b006 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -29,6 +29,8 @@
>  #define DISP_REG_CONFIG_DISP_COLOR0_SEL_IN   0x084
>  #define DISP_REG_CONFIG_DISP_COLOR1_SEL_IN   0x088
>  #define DISP_REG_CONFIG_DPI_SEL_IN   0x0ac
> +#define DISP_REG_CONFIG_DISP_RDMA2_SOUT  0x0b8
> +#define DISP_REG_CONFIG_DISP_RDMA0_MOUT_EN   0x0c4
>  #define DISP_REG_CONFIG_DISP_RDMA1_MOUT_EN   0x0c8
>  #define DISP_REG_CONFIG_MMSYS_CG_CON00x100
>  
> @@ -41,6 +43,7 @@
>  #define DISP_REG_MUTEX_RST(n)(0x28 + 0x20 * (n))
>  #define DISP_REG_MUTEX_MOD(n)(0x2c + 0x20 * (n))
>  #define DISP_REG_MUTEX_SOF(n)(0x30 + 0x20 * (n))
> +#define DISP_REG_MUTEX_MOD2(n)   (0x34 + 0x20 * (n))
>  
>  #define INT_MUTEXBIT(1)
>  
> @@ -60,6 +63,25 @@
>  #define MT8173_MUTEX_MOD_DISP_PWM1   BIT(24)
>  #define MT8173_MUTEX_MOD_DISP_OD BIT(25)
>  
> +#define MT2712_MUTEX_MOD_DISP_OVL0   BIT(11)
> +#define MT2712_MUTEX_MOD_DISP_OVL1   BIT(12)
> +#define MT2712_MUTEX_MOD_DISP_RDMA0  BIT(13)
> +#define MT2712_MUTEX_MOD_DISP_RDMA1  BIT(14)
> +#define MT2712_MUTEX_MOD_DISP_RDMA2  BIT(15)
> +#define MT2712_MUTEX_MOD_DISP_WDMA0  BIT(16)
> +#define MT2712_MUTEX_MOD_DISP_WDMA1  BIT(17)
> +#define MT2712_MUTEX_MOD_DISP_COLOR0 BIT(18)
> +#define MT2712_MUTEX_MOD_DISP_COLOR1 BIT(19)
> +#define MT2712_MUTEX_MOD_DISP_AALBIT(20)
> +#define MT2712_MUTEX_MOD_DISP_UFOE   BIT(22)
> +#define MT2712_MUTEX_MOD_DISP_PWM0   BIT(23)
> +#define MT2712_MUTEX_MOD_DISP_PWM1   BIT(24)
> +#define MT2712_MUTEX_MOD_DISP_PWM2   BIT(10)
> +#define MT2712_MUTEX_MOD_DISP_OD BIT(25)
> +/* modules more than 32, add BIT(31) when using DISP_REG_MUTEX_MOD2 bit */
> +#define MT2712_MUTEX_MOD2_DISP_AAL1  (BIT(1) | BIT(31))
> +#define MT2712_MUTEX_MOD2_DISP_OD1   (BIT(2) | BIT(31))
> +

It looks like that MUTEX_MOD definition varies for each SoC. I think
such definition should be passed from dts to prevent modify driver for
each SoC. For example, the clock definition varies for each SoC, and its
definition is placed in [1]. The dts [2] include the header file and
pass the clock definition to driver.

[1]
https://elixir.bootlin.com/linux/v4.17-rc5/source/include/dt-bindings/clock/mt2712-clk.h
 
[2]
https://elixir.bootlin.com/linux/v4.17-rc5/source/arch/arm64/boot/dts/mediatek/mt2712e.dtsi

>  #define MT2701_MUTEX_MOD_DISP_OVLBIT(3)
>  #define MT2701_MUTEX_MOD_DISP_WDMA   BIT(6)
>  #define MT2701_MUTEX_MOD_DISP_COLOR  BIT(7)
> @@ -74,6 +96,7 @@
>  
>  #define OVL0_MOUT_EN_COLOR0  0x1
>  #define OD_MOUT_EN_RDMA0 0x1
> +#define OD1_MOUT_EN_RDMA1BIT(16)
>  #define UFOE_MOUT_EN_DSI00x1
>  #define COLOR0_SEL_IN_OVL0   0x1
>  #define OVL1_MOUT_EN_COLOR1  0x1
> @@ -108,6 +131,26 @@ static const unsigned int 
> mt2701_mutex_mod[DDP_COMPONENT_ID_MAX] = {
>   [DDP_COMPONENT_WDMA0] = MT2701_MUTEX_MOD_DISP_WDMA,
>  };
>  
> +static const unsigned int mt2712_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> + [DDP_COMPONENT_AAL] = MT2712_MUTEX_MOD_DISP_AAL,
> + [DDP_COMPONENT_AAL1] = MT2712_MUTEX_MOD2_DISP_AAL1,
> + [DDP_COMPONENT_COLOR0] = MT2712_MUTEX_MOD_DISP_COLOR0,
> + [DDP_COMPONENT_COLOR1] = MT2712_MUTEX_MOD_DISP_COLOR1,
> + [DDP_COMPONENT_OD] = MT2712_MUTEX_MOD_DISP_OD,
> + [DDP_COMPONENT_OD1] = MT2712_MUTEX_MOD2_DISP_OD1,
> + [DDP_COMPONENT_OVL0] = MT2712_MUTEX_MOD_DISP_OVL0,
> + [DDP_COMPONENT_OVL1] = MT2712_MUTEX_MOD_DISP_OVL1,
> + [DDP_COMPONENT_PWM0] = MT2712_MUTEX_MOD_DISP_PWM0,
> + [DDP_COMPONENT_PWM1] = MT2712_MUTEX_MOD_DISP_PWM1,
> + [DDP_COMPONENT_PWM2] = MT2712_MUTEX_MOD_DISP_PWM2,
> + [DDP_COMPONENT_RDMA0] = MT2712_MUTEX_MOD_DISP_RDMA0,
> + [DDP_COMPONENT_RDMA1] = MT2712_MUTEX_MOD_DISP_RDMA1,
> + [DDP_COMPONENT_RDMA2] = MT2712_MUTEX_MOD_DISP_RDMA2,
> + [DDP_COMPONENT_UFOE] = MT2712_MUTEX_MOD_DISP_UFOE,
> + [DDP_COMPONENT_WDMA0] = MT2712_MUTEX_MOD_DISP_WDMA0,
> + 

[PATCH v2 3/4] drm/dsc: Define VESA Display Stream Compression Capabilities

[Manasi Navare]

From: Gaurav K Singh 

This defines all the DSC parameters as per the VESA DSC spec
that will be required for DSC encoder/decoder

v2: Define this struct in DRM (From Manasi)
* Changed the data types to u8/u16 instead of unsigned longs (Manasi)
* Remove driver specific fields (Manasi)
* Move this struct definition to DRM (Manasi)
* Define DSC 1.2 parameters (Manasi)
* Use DSC_NUM_BUF_RANGES (Manasi)
* Call it drm_dsc_config (Manasi)

Cc: dri-devel@lists.freedesktop.org
Cc: Jani Nikula 
Cc: Ville Syrjala 
Cc: Anusha Srivatsa 
Signed-off-by: Manasi Navare 
Signed-off-by: Gaurav K Singh 
---
 include/drm/drm_dsc.h | 111 ++
 1 file changed, 111 insertions(+)

diff --git a/include/drm/drm_dsc.h b/include/drm/drm_dsc.h
index 5ee72e8..04501e2 100644
--- a/include/drm/drm_dsc.h
+++ b/include/drm/drm_dsc.h
@@ -30,6 +30,117 @@
 
 #define DSC_NUM_BUF_RANGES 15
 
+/* VESA Display Stream Compression DSC 1.2 constants */
+#define DSC_NUM_BUF_RANGES 15
+
+/* Configuration for a single Rate Control model range */
+struct dsc_rc_range_parameters {
+   /* Min Quantization Parameters allowed for this range */
+   u8 range_min_qp;
+   /* Max Quantization Parameters allowed for this range */
+   u8 range_max_qp;
+   /* Bits/group offset to apply to target for this group */
+   u8 range_bpg_offset;
+};
+
+struct drm_dsc_config {
+   /* Bits / component for previous reconstructed line buffer */
+   u8 line_buf_depth;
+   /* Bits per component to code (must be 8, 10, or 12) */
+   u8 bits_per_component;
+   /*
+* Flag indicating to do RGB - YCoCg conversion
+* and back (should be 1 for RGB input)
+*/
+   bool convert_rgb;
+   u8 slice_count;
+   /* Slice Width */
+   u16 slice_width;
+   /* Slice Height */
+   u16 slice_height;
+   /*
+* 4:2:2 enable mode (from PPS, 4:2:2 conversion happens
+* outside of DSC encode/decode algorithm)
+*/
+   bool enable422;
+   /* Picture Width */
+   u16 pic_width;
+   /* Picture Height */
+   u16 pic_height;
+   /* Offset to bits/group used by RC to determine QP adjustment */
+   u8 rc_tgt_offset_high;
+   /* Offset to bits/group used by RC to determine QP adjustment */
+   u8 rc_tgt_offset_low;
+   /* Bits/pixel target << 4 (ie., 4 fractional bits) */
+   u16 bits_per_pixel;
+   /*
+* Factor to determine if an edge is present based
+* on the bits produced
+*/
+   u8 rc_edge_factor;
+   /* Slow down incrementing once the range reaches this value */
+   u8 rc_quant_incr_limit1;
+   /* Slow down incrementing once the range reaches this value */
+   u8 rc_quant_incr_limit0;
+   /* Number of pixels to delay the initial transmission */
+   u16 initial_xmit_delay;
+   /* Number of pixels to delay the VLD on the decoder,not including SSM */
+   u16  initial_dec_delay;
+   /* Block prediction enable */
+   bool block_pred_enable;
+   /* Bits/group offset to use for first line of the slice */
+   u8 first_line_bpg_offset;
+   /* Value to use for RC model offset at slice start */
+   u16 initial_offset;
+   /* Thresholds defining each of the buffer ranges */
+   u16 rc_buf_thresh[DSC_NUM_BUF_RANGES - 1];
+   /* Parameters for each of the RC ranges */
+   struct dsc_rc_range_parameters rc_range_params[DSC_NUM_BUF_RANGES];
+   /* Total size of RC model */
+   u16 rc_model_size;
+   /* Minimum QP where flatness information is sent */
+   u8 flatness_min_qp;
+   /* Maximum QP where flatness information is sent */
+   u8 flatness_max_qp;
+   /* Initial value for scale factor */
+   u8 initial_scale_value;
+   /* Decrement scale factor every scale_decrement_interval groups */
+   u16 scale_decrement_interval;
+   /* Increment scale factor every scale_increment_interval groups */
+   u16 scale_increment_interval;
+   /* Non-first line BPG offset to use */
+   u16 nfl_bpg_offset;
+   /* BPG offset used to enforce slice bit */
+   u16 slice_bpg_offset;
+   /* Final RC linear transformation offset value */
+   u16 final_offset;
+   /* Enable on-off VBR (ie., disable stuffing bits) */
+   bool vbr_enable;
+   /* Mux word size (in bits) for SSM mode */
+   u8 mux_word_size;
+   /*
+* The (max) size in bytes of the "chunks" that are
+* used in slice multiplexing
+*/
+   u16 slice_chunk_size;
+   /* Rate Control buffer siz in bits */
+   u16 rc_bits;
+   /* DSC Minor Version */
+   u8 dsc_version_minor;
+   /* DSC Major version */
+   u8 dsc_version_major;
+   /* Native 4:2:2 support 

[PATCH v2 1/4] drm/dp: Define payload size for DP SDP PPS packet

[Manasi Navare]

DP 1.4 spec defines DP secondary data packet for DSC
picture parameter set. This patch defines its payload size
according to the DP 1.4 specification.

Signed-off-by: Manasi Navare 
Cc: Jani Nikula 
Cc: Ville Syrjala 
Cc: Anusha Srivatsa 
Cc: dri-devel@lists.freedesktop.org
---
 include/drm/drm_dp_helper.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index c015649..d13e512 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -992,6 +992,7 @@ struct dp_sdp_header {
 
 #define EDP_SDP_HEADER_REVISION_MASK   0x1F
 #define EDP_SDP_HEADER_VALID_PAYLOAD_BYTES 0x1F
+#define DP_SDP_PPS_HEADER_PAYLOAD_BYTES_MINUS_1 0x7F
 
 struct edp_vsc_psr {
struct dp_sdp_header sdp_header;
-- 
2.7.4

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

[PATCH v2 4/4] drm/dsc: Add helpers for DSC picture parameter set infoframes

[Manasi Navare]

According to Display Stream compression spec 1.2, the picture
parameter set metadata is sent from source to sink device
using the DP Secondary data packet. An infoframe is formed
for the PPS SDP header and PPS SDP payload bytes.
This patch adds helpers to fill the PPS SDP header
and PPS SDP payload according to the DSC 1.2 specification.

v3:
* Add reference to added kernel-docs in Documentation/gpu/drm-kms-helpers.rst
(Daniel Vetter)

v2:
* Add EXPORT_SYMBOL for the drm functions (Manasi)

Cc: dri-devel@lists.freedesktop.org
Cc: Jani Nikula 
Cc: Ville Syrjala 
Cc: Anusha Srivatsa 
Signed-off-by: Manasi Navare 
---
 Documentation/gpu/drm-kms-helpers.rst |  12 ++
 drivers/gpu/drm/Makefile  |   2 +-
 drivers/gpu/drm/drm_dsc.c | 227 ++
 include/drm/drm_dsc.h |  16 +++
 4 files changed, 256 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/drm_dsc.c

diff --git a/Documentation/gpu/drm-kms-helpers.rst 
b/Documentation/gpu/drm-kms-helpers.rst
index e37557b..13837f7 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -205,6 +205,18 @@ MIPI DSI Helper Functions Reference
 .. kernel-doc:: drivers/gpu/drm/drm_mipi_dsi.c
:export:
 
+Display Stream Compression Helper Functions Reference
+=
+
+.. kernel-doc:: drivers/gpu/drm/drm_dsc.c
+   :doc: dsc helpers
+
+.. kernel-doc:: include/drm/drm_dsc.h
+   :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_dsc.c
+   :export:
+
 Output Probing Helper Functions Reference
 =
 
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index ef9f3da..02f1b2c 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -31,7 +31,7 @@ drm-$(CONFIG_AGP) += drm_agpsupport.o
 drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
 drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
 
-drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
+drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_dsc.o 
drm_probe_helper.o \
drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \
drm_kms_helper_common.o drm_dp_dual_mode_helper.o \
drm_simple_kms_helper.o drm_modeset_helper.o \
diff --git a/drivers/gpu/drm/drm_dsc.c b/drivers/gpu/drm/drm_dsc.c
new file mode 100644
index 000..3bf8d42
--- /dev/null
+++ b/drivers/gpu/drm/drm_dsc.c
@@ -0,0 +1,227 @@
+/*
+ * Copyright © 2018 Intel Corp
+ *
+ * Permission to use, copy, modify, distribute, and sell this software and its
+ * documentation for any purpose is hereby granted without fee, provided that
+ * the above copyright notice appear in all copies and that both that copyright
+ * notice and this permission notice appear in supporting documentation, and
+ * that the name of the copyright holders not be used in advertising or
+ * publicity pertaining to distribution of the software without specific,
+ * written prior permission.  The copyright holders make no representations
+ * about the suitability of this software for any purpose.  It is provided "as
+ * is" without express or implied warranty.
+ *
+ * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
+ * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
+ * EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
+ * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE,
+ * DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
+ * TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE
+ * OF THIS SOFTWARE.
+ *
+ * Author:
+ * Manasi Navare 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/**
+ * DOC: dsc helpers
+ *
+ * These functions contain some common logic and helpers to deal with VESA
+ * Display Stream Compression standard required for DSC on Display Port/eDP or
+ * MIPI display interfaces.
+ */
+
+/**
+ * drm_dsc_dp_pps_header_init() - Initializes the PPS Header
+ * for DisplayPort as per the DP 1.4 spec.
+ * @pps_sdp: Secondary data packet for DSC Picture Parameter Set
+ */
+void drm_dsc_dp_pps_header_init(struct drm_dsc_pps_infoframe *pps_sdp)
+{
+   memset(_sdp->pps_header, 0, sizeof(pps_sdp->pps_header));
+
+   pps_sdp->pps_header.HB1 = DP_SDP_PPS;
+   pps_sdp->pps_header.HB2 = DP_SDP_PPS_HEADER_PAYLOAD_BYTES_MINUS_1;
+}
+EXPORT_SYMBOL(drm_dsc_dp_pps_header_init);
+
+/**
+ * drm_dsc_pps_infoframe_pack() - Populates the DSC PPS infoframe
+ * using the DSC configuration parameters in the order expected
+ * by the DSC Display Sink device. For the DSC, the sink device
+ * expects the PPS payload in the big endian format for the fields
+ * that span more 

[PATCH v2 2/4] drm/dsc: Define Display Stream Compression PPS infoframe

[Manasi Navare]

This patch defines a new header file for all the DSC 1.2 structures
and creates a structure for PPS infoframe which will be used to send
picture parameter set secondary data packet for display stream compression.
All the PPS infoframe syntax elements are taken from DSC 1.2 specification
from VESA.

v2:
* Fix the comments for kernel-doc

Cc: dri-devel@lists.freedesktop.org
Cc: Jani Nikula 
Cc: Ville Syrjala 
Cc: Anusha Srivatsa 
Signed-off-by: Manasi Navare 
---
 include/drm/drm_dsc.h | 437 ++
 1 file changed, 437 insertions(+)
 create mode 100644 include/drm/drm_dsc.h

diff --git a/include/drm/drm_dsc.h b/include/drm/drm_dsc.h
new file mode 100644
index 000..5ee72e8
--- /dev/null
+++ b/include/drm/drm_dsc.h
@@ -0,0 +1,437 @@
+/*
+ * Copyright (C) 2018 Intel Corp.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * Authors:
+ * Manasi Navare 
+ */
+
+#ifndef DRM_DSC_H_
+#define DRM_DSC_H_
+
+#include 
+
+#define DSC_NUM_BUF_RANGES 15
+
+/**
+ * struct picture_parameter_set - Represents 128 bytes of Picture Parameter Set
+ *
+ * The VESA DSC standard defines picture parameter set (PPS) which display 
stream
+ * compression encoders must communicate to decoders. The PPS is encapsulated
+ * in 128 bytes (PPS 0 through PPS 127). The fields in this structure are as 
per
+ * Table 4.1 in Vesa DSC specification v1.1/v1.2.
+ * The PPS fields that span over more than a byte should be stored in Big 
Endian
+ * format.
+ */
+struct picture_parameter_set {
+   /**
+* @dsc_version_minor:
+* PPS0[3:0] - Contains Minor version of DSC
+*/
+   u8 dsc_version_minor:4;
+   /**
+* @dsc_version_major:
+* PPS0[7:4] - Contains major version of DSC
+*/
+   u8 dsc_version_major:4;
+   /**
+* @pps_identifier:
+* PPS1[7:0] - Application specific identifier that can be
+* used to differentiate between different PPS tables.
+*/
+   u8 pps_identifier;
+   /**
+* @pps2_reserved:
+* PPS2[7:0]- RESERVED Byte
+*/
+   u8 pps2_reserved;
+   /**
+* @linebuf_depth:
+* PPS3[3:0] - Contains linebuffer bit depth used to generate
+* the bitstream. (0x0 - 16 bits for DSc 1.2, 0x8 - 8 bits,
+* 0xA - 10 bits, 0xB - 11 bits, 0xC - 12 bits, 0xD - 13 bits,
+* 0xE - 14 bits for DSC1.2, 0xF - 14 bits for DSC 1.2.
+*/
+   u8 linebuf_depth:4;
+   /**
+* @bits_per_component:
+* PPS3[7:4] - Bits per component fo rthe original pixels
+* of the encoded picture.
+*/
+   u8 bits_per_component:4;
+   /**
+* @bpp_high:
+* PPS4[1:0] - These are the most significant 2 bits of
+* compressed BPP bits_per_pixel[9:0] syntax element.
+*/
+   u8 bpp_high:2;
+   /**
+* @vbr_enable:
+* PPS4[2] - 0 = VBR disabled, 1 = VBR enabled
+*/
+   u8 vbr_enable:1;
+   /**
+* @simple_422:
+* PPS4[3] - Indicates if decoder drops samples to
+* reconstruct the 4:2:2 picture.
+*/
+   u8 simple_422:1;
+   /**
+* @convert_rgb:
+* PPS4[4] - Indicates if DSC color space conversion is active
+*/
+   u8 convert_rgb:1;
+   /**
+* @block_pred_enable:
+* PPS4[5] - Indicates if BP is used to code any groups in picture
+*/
+   u8 block_pred_enable:1;
+   /**
+* @pps4_reserved:
+* PPS4[7:6] - Reseved bits
+*/
+   u8 pps4_reserved:2;
+   /**
+* @bpp_low:
+* PPS5[7:0] - This indicates the lower significant 8 bits of
+* the compressed BPP bits_per_pixel[9:0] element.
+*/
+   u8 bpp_low;
+   /**
+

[PATCH v2 0/4] DRM helpers for Display Stream Compression PPS infoframes

[Manasi Navare]

VESA Display Stream Compression is a specification for visually losless
video compression over display links. The DSC standard also defines
a picture parameter set (PPS) which encoder must communicate to decoders.
This is done by encapsulating PPS header and payload bytes in an infoframe
that can be sent to the display sink using secondary data packets
as defined in DP 1.4 spec.

This patch series creates a new files drm_dsc.h and drm_dsc.c
which define all the DSC related structures and helpers that
can be called by drivers to form DSC PPS infoframes before
enabling Display Stream compression on eDP/DP/MIPI

v2:
*This is a v2 of the original patch series which adds kernel-doc
hooks for the new dsc files in drm-kms-helpers.rst. (Daniel Vetter)

Cc: dri-devel@lists.freedesktop.org
Cc: Jani Nikula 
Cc: Ville Syrjala 
Cc: Anusha Srivatsa 

Gaurav K Singh (1):
  drm/dsc: Define VESA Display Stream Compression Capabilities

Manasi Navare (3):
  drm/dp: Define payload size for DP SDP PPS packet
  drm/dsc: Define Display Stream Compression PPS infoframe
  drm/dsc: Add helpers for DSC picture parameter set infoframes

 Documentation/gpu/drm-kms-helpers.rst |  12 +
 drivers/gpu/drm/Makefile  |   2 +-
 drivers/gpu/drm/drm_dsc.c | 227 ++
 include/drm/drm_dp_helper.h   |   1 +
 include/drm/drm_dsc.h | 564 ++
 5 files changed, 805 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/drm_dsc.c
 create mode 100644 include/drm/drm_dsc.h

-- 
2.7.4

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

[PATCH 3/3] drm/tinydrm: new driver for ILI9341 display panels

[David Lechner]

);
+   mipi_dbi_command(mipi, ILI9341_DTCTRLB, 0x00, 0x00);
+
+   /* Power Control */
+   mipi_dbi_command(mipi, ILI9341_PWCTRL1, 0x23);
+   mipi_dbi_command(mipi, ILI9341_PWCTRL2, 0x10);
+   /* VCOM */
+   mipi_dbi_command(mipi, ILI9341_VMCTRL1, 0x3e, 0x28);
+   mipi_dbi_command(mipi, ILI9341_VMCTRL2, 0x86);
+
+   /* Memory Access Control */
+   mipi_dbi_command(mipi, MIPI_DCS_SET_PIXEL_FORMAT, 
MIPI_DCS_PIXEL_FMT_16BIT);
+
+   /* Frame Rate */
+   mipi_dbi_command(mipi, ILI9341_FRMCTR1, 0x00, 0x1b);
+
+   /* Gamma */
+   mipi_dbi_command(mipi, ILI9341_EN3GAM, 0x00);
+   mipi_dbi_command(mipi, MIPI_DCS_SET_GAMMA_CURVE, 0x01);
+   mipi_dbi_command(mipi, ILI9341_PGAMCTRL,
+0x0f, 0x31, 0x2b, 0x0c, 0x0e, 0x08, 0x4e, 0xf1,
+0x37, 0x07, 0x10, 0x03, 0x0e, 0x09, 0x00);
+   mipi_dbi_command(mipi, ILI9341_NGAMCTRL,
+0x00, 0x0e, 0x14, 0x03, 0x11, 0x07, 0x31, 0xc1,
+0x48, 0x08, 0x0f, 0x0c, 0x31, 0x36, 0x0f);
+
+   /* DDRAM */
+   mipi_dbi_command(mipi, ILI9341_ETMOD, 0x07);
+
+   /* Display */
+   mipi_dbi_command(mipi, ILI9341_DISCTRL, 0x08, 0x82, 0x27, 0x00);
+   mipi_dbi_command(mipi, MIPI_DCS_EXIT_SLEEP_MODE);
+   msleep(100);
+
+   mipi_dbi_command(mipi, MIPI_DCS_SET_DISPLAY_ON);
+   msleep(100);
+
+out_enable:
+   switch (mipi->rotation) {
+   default:
+   addr_mode = ILI9341_MADCTL_MX;
+   break;
+   case 90:
+   addr_mode = ILI9341_MADCTL_MV;
+   break;
+   case 180:
+   addr_mode = ILI9341_MADCTL_MY;
+   break;
+   case 270:
+   addr_mode = ILI9341_MADCTL_MV | ILI9341_MADCTL_MY |
+   ILI9341_MADCTL_MX;
+   break;
+   }
+   addr_mode |= ILI9341_MADCTL_BGR;
+   mipi_dbi_command(mipi, MIPI_DCS_SET_ADDRESS_MODE, addr_mode);
+   mipi_dbi_enable_flush(mipi, crtc_state, plane_state);
+}
+
+static const struct drm_simple_display_pipe_funcs ili9341_pipe_funcs = {
+   .enable = yx240qv29_enable,
+   .disable = mipi_dbi_pipe_disable,
+   .update = tinydrm_display_pipe_update,
+   .prepare_fb = drm_gem_fb_simple_display_pipe_prepare_fb,
+};
+
+static const struct drm_display_mode yx240qv29_mode = {
+   TINYDRM_MODE(240, 320, 37, 49),
+};
+
+DEFINE_DRM_GEM_CMA_FOPS(ili9341_fops);
+
+static struct drm_driver ili9341_driver = {
+   .driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME |
+ DRIVER_ATOMIC,
+   .fops   = _fops,
+   TINYDRM_GEM_DRIVER_OPS,
+   .lastclose  = drm_fb_helper_lastclose,
+   .debugfs_init   = mipi_dbi_debugfs_init,
+   .name   = "ili9341",
+   .desc   = "Ilitek ILI9341",
+   .date   = "20180514",
+   .major  = 1,
+   .minor  = 0,
+};
+
+static const struct of_device_id ili9341_of_match[] = {
+   { .compatible = "noname,yx240qv29" },
+   {},
+};
+MODULE_DEVICE_TABLE(of, ili9341_of_match);
+
+static const struct spi_device_id ili9341_id[] = {
+   { "yx240qv29", 0 },
+   { },
+};
+MODULE_DEVICE_TABLE(spi, ili9341_id);
+
+static int ili9341_probe(struct spi_device *spi)
+{
+   struct device *dev = >dev;
+   struct mipi_dbi *mipi;
+   struct gpio_desc *dc;
+   u32 rotation = 0;
+   int ret;
+
+   mipi = devm_kzalloc(dev, sizeof(*mipi), GFP_KERNEL);
+   if (!mipi)
+   return -ENOMEM;
+
+   mipi->reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
+   if (IS_ERR(mipi->reset)) {
+   DRM_DEV_ERROR(dev, "Failed to get gpio 'reset'\n");
+   return PTR_ERR(mipi->reset);
+   }
+
+   dc = devm_gpiod_get_optional(dev, "dc", GPIOD_OUT_LOW);
+   if (IS_ERR(dc)) {
+   DRM_DEV_ERROR(dev, "Failed to get gpio 'dc'\n");
+   return PTR_ERR(dc);
+   }
+
+   mipi->regulator = devm_regulator_get(dev, "power");
+   if (IS_ERR(mipi->regulator))
+   return PTR_ERR(mipi->regulator);
+
+   mipi->backlight = devm_of_find_backlight(dev);
+   if (IS_ERR(mipi->backlight))
+   return PTR_ERR(mipi->backlight);
+
+   device_property_read_u32(dev, "rotation", );
+
+   ret = mipi_dbi_spi_init(spi, mipi, dc);
+   if (ret)
+   return ret;
+
+   ret = mipi_dbi_init(>dev, mipi, _pipe_funcs,
+   _driver, _mode, rotation);
+   if (ret)
+   return ret;
+
+   spi_set_drvdata(spi, mipi);
+
+   return devm_tinydrm_register(>tinydrm);
+}
+
+static void ili9341_shutdown(struct spi_device *spi)
+{
+

[PATCH 0/3] drm/tinydrm: new dirver for ILI9341 displays

[David Lechner]

This series adds a new tinydrm driver for the Ilitek ILI9341 controller and
a 2.4" display panel that uses this controller.

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 "noname" as the vendor prefix. If someone has a
  better suggestion, please speak up.
* The driver is basically a copy of mi0283qt.c with a new init sequence,
  a different physical panel size, fixed (as in corrected) rotation handling,
  and dropped PM (since I don't have a way to test it). Do we want to try to
  share code with these two drivers (it's not much)?
* The MAINTAINERS patch for ili9225 is included so we don't end up with a merge
  conflict later on.

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

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

 .../bindings/display/ilitek,ili9341.txt   |  27 ++
 MAINTAINERS   |   8 +-
 drivers/gpu/drm/tinydrm/Kconfig   |  10 +
 drivers/gpu/drm/tinydrm/Makefile  |   1 +
 drivers/gpu/drm/tinydrm/ili9341.c | 239 ++
 5 files changed, 284 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/display/ilitek,ili9341.txt
 create mode 100644 drivers/gpu/drm/tinydrm/ili9341.c

-- 
2.17.0

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

[PATCH 2/3] dt-bindings: new binding for Ilitek ILI9341 display panels

[David Lechner]

This adds a new binding for Ilitek ILI9341 display panels. It includes
a compatible string for one display (more can be added in the future).

The vendor prefix "noname" is used because the vendor is not known.
The YX240QV29-T panel[1] is found, for example, in an Adafruit breakout
board[2] and in Mindsensors' PiStorms[3].

[1]: 
https://cdn-learn.adafruit.com/assets/assets/000/046/879/original/SPEC-YX240QV29-T_Rev.A__1_.pdf
[2]: https://www.adafruit.com/product/2478
[3]: 
http://www.mindsensors.com/stem-with-robotics/13-pistorms-v2-base-kit-raspberry-pi-brain-for-lego-robot

Signed-off-by: David Lechner 
---
 .../bindings/display/ilitek,ili9341.txt   | 27 +++
 1 file changed, 27 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/ilitek,ili9341.txt

diff --git a/Documentation/devicetree/bindings/display/ilitek,ili9341.txt 
b/Documentation/devicetree/bindings/display/ilitek,ili9341.txt
new file mode 100644
index ..0fc90b2dd732
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/ilitek,ili9341.txt
@@ -0,0 +1,27 @@
+Ilitek ILI9341 display panels
+
+This binding is for display panels using an Ilitek ILI9341 controller in SPI
+mode.
+
+Required properties:
+- compatible:  "noname,yx240qv29", "ilitek,ili9341"
+- dc-gpios:D/C pin
+- reset-gpios: Reset pin
+
+The node for this driver must be a child node of a SPI controller, hence
+all mandatory properties described in ../spi/spi-bus.txt must be specified.
+
+Optional properties:
+- rotation:panel rotation in degrees counter clockwise (0,90,180,270)
+- backlight:   phandle of the backlight device attached to the panel
+
+Example:
+   display@0{
+   compatible = "noname,yx240qv29", "ilitek,ili9341";
+   reg = <0>;
+   spi-max-frequency = <3200>;
+   dc-gpios = < 9 GPIO_ACTIVE_HIGH>;
+   reset-gpios = < 8 GPIO_ACTIVE_HIGH>;
+   rotation = <270>;
+   backlight = <>;
+   };
-- 
2.17.0

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

[PATCH 1/3] MAINTAINERS: fix path to ilitek, ili9225 device tree bindings

[David Lechner]

This fixes the path to the ilitek,ili9225 device tree binding file.

Signed-off-by: David Lechner 
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 334a00350922..bc219de9cbee 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4478,7 +4478,7 @@ DRM DRIVER FOR ILITEK ILI9225 PANELS
 M: David Lechner 
 S: Maintained
 F: drivers/gpu/drm/tinydrm/ili9225.c
-F: Documentation/devicetree/bindings/display/ili9225.txt
+F: Documentation/devicetree/bindings/display/ilitek,ili9225.txt
 
 DRM DRIVER FOR INTEL I810 VIDEO CARDS
 S: Orphan / Obsolete
-- 
2.17.0

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

[Bug 104790] When using OpenGL 4.x some applications crash

[bugzilla-daemon]

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

--- Comment #5 from i...@yahoo.com ---
How exactly do you enable compat or core profiles?

Afaik Gallium Nine should not be affected by any OpenGL related options...

Also, when wine program crashes and you refuse the dialog (press ESC?), the
debugger would dump all info (including backtrace) in the terminal.

Since the winedbg does not recognize modern debug symbols, you should compile
mesa3d with only dwarf2, as described in ixit nine website debug section.

Of course, this is if the backtrace is showing mesa3d related functions at all.

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

[RFC PATCH 4/5] mfd: cros-ec: Introduce CEC commands and events definitions.

[Neil Armstrong]

From: Stefan Adolfsson 

The EC can expose a CEC bus, this patch adds the CEC related definitions
needed by the cros-ec-cec driver.
Having a 16 byte mkbp event size makes it possible to send CEC
messages from the EC to the AP directly inside the mkbp event
instead of first doing a notification and then a read.

Signed-off-by: Stefan Adolfsson 
Signed-off-by: Neil Armstrong 
---
 drivers/platform/chrome/cros_ec_proto.c | 42 +
 include/linux/mfd/cros_ec.h |  2 +-
 include/linux/mfd/cros_ec_commands.h| 80 +
 3 files changed, 114 insertions(+), 10 deletions(-)

diff --git a/drivers/platform/chrome/cros_ec_proto.c 
b/drivers/platform/chrome/cros_ec_proto.c
index e7bbdf9..ba47f79 100644
--- a/drivers/platform/chrome/cros_ec_proto.c
+++ b/drivers/platform/chrome/cros_ec_proto.c
@@ -504,29 +504,53 @@ int cros_ec_cmd_xfer_status(struct cros_ec_device *ec_dev,
 }
 EXPORT_SYMBOL(cros_ec_cmd_xfer_status);
 
+static int get_next_event_xfer(struct cros_ec_device *ec_dev,
+  struct cros_ec_command *msg,
+  int version, uint32_t size)
+{
+   int ret;
+
+   msg->version = version;
+   msg->command = EC_CMD_GET_NEXT_EVENT;
+   msg->insize = size;
+   msg->outsize = 0;
+
+   ret = cros_ec_cmd_xfer(ec_dev, msg);
+   if (ret > 0) {
+   ec_dev->event_size = ret - 1;
+   memcpy(_dev->event_data, msg->data, size);
+   }
+
+   return ret;
+}
+
 static int get_next_event(struct cros_ec_device *ec_dev)
 {
u8 buffer[sizeof(struct cros_ec_command) + sizeof(ec_dev->event_data)];
struct cros_ec_command *msg = (struct cros_ec_command *)
+   static int cmd_version = 1;
int ret;
 
+   BUILD_BUG_ON(sizeof(union ec_response_get_next_data_v1) != 16);
+
if (ec_dev->suspended) {
dev_dbg(ec_dev->dev, "Device suspended.\n");
return -EHOSTDOWN;
}
 
-   msg->version = 0;
-   msg->command = EC_CMD_GET_NEXT_EVENT;
-   msg->insize = sizeof(ec_dev->event_data);
-   msg->outsize = 0;
+   if (cmd_version == 1) {
+   ret = get_next_event_xfer(ec_dev, msg, cmd_version,
+ sizeof(ec_dev->event_data));
+   if (ret != EC_RES_INVALID_VERSION)
+   return ret;
 
-   ret = cros_ec_cmd_xfer(ec_dev, msg);
-   if (ret > 0) {
-   ec_dev->event_size = ret - 1;
-   memcpy(_dev->event_data, msg->data,
-  sizeof(ec_dev->event_data));
+   /* Fallback to version 0 for future send attempts */
+   cmd_version = 0;
}
 
+   ret = get_next_event_xfer(ec_dev, msg, cmd_version,
+ sizeof(struct ec_response_get_next_event));
+
return ret;
 }
 
diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
index 2d4e23c..f3415eb 100644
--- a/include/linux/mfd/cros_ec.h
+++ b/include/linux/mfd/cros_ec.h
@@ -147,7 +147,7 @@ struct cros_ec_device {
bool mkbp_event_supported;
struct blocking_notifier_head event_notifier;
 
-   struct ec_response_get_next_event event_data;
+   struct ec_response_get_next_event_v1 event_data;
int event_size;
u32 host_event_wake_mask;
 };
diff --git a/include/linux/mfd/cros_ec_commands.h 
b/include/linux/mfd/cros_ec_commands.h
index f2edd99..18df466 100644
--- a/include/linux/mfd/cros_ec_commands.h
+++ b/include/linux/mfd/cros_ec_commands.h
@@ -804,6 +804,8 @@ enum ec_feature_code {
EC_FEATURE_MOTION_SENSE_FIFO = 24,
/* EC has RTC feature that can be controlled by host commands */
EC_FEATURE_RTC = 27,
+   /* EC supports CEC commands */
+   EC_FEATURE_CEC = 35,
 };
 
 #define EC_FEATURE_MASK_0(event_code) (1UL << (event_code % 32))
@@ -2078,6 +2080,12 @@ enum ec_mkbp_event {
/* EC sent a sysrq command */
EC_MKBP_EVENT_SYSRQ = 6,
 
+   /* Notify the AP that something happened on CEC */
+   EC_MKBP_CEC_EVENT = 8,
+
+   /* Send an incoming CEC message to the AP */
+   EC_MKBP_EVENT_CEC_MESSAGE = 9,
+
/* Number of MKBP events */
EC_MKBP_EVENT_COUNT,
 };
@@ -2093,12 +2101,31 @@ union ec_response_get_next_data {
uint32_t   sysrq;
 } __packed;
 
+union ec_response_get_next_data_v1 {
+   uint8_t   key_matrix[16];
+
+   /* Unaligned */
+   uint32_t  host_event;
+
+   uint32_t   buttons;
+   uint32_t   switches;
+   uint32_t   sysrq;
+   uint32_t   cec_events;
+   uint8_tcec_message[16];
+} __packed;
+
 struct ec_response_get_next_event {
uint8_t event_type;
/* Followed by event data if any */
union ec_response_get_next_data data;
 } __packed;
 
+struct ec_response_get_next_event_v1 {
+   uint8_t event_type;
+  

[RFC PATCH 1/5] mfd: cros_ec_dev: Add CEC sub-device registration

[Neil Armstrong]

The EC can expose a CEC bus, thus add the cros-ec-cec MFD sub-device
when the CEC feature bit is present.

Signed-off-by: Neil Armstrong 
---
 drivers/mfd/cros_ec_dev.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/mfd/cros_ec_dev.c b/drivers/mfd/cros_ec_dev.c
index eafd06f..57064ec 100644
--- a/drivers/mfd/cros_ec_dev.c
+++ b/drivers/mfd/cros_ec_dev.c
@@ -383,6 +383,18 @@ static void cros_ec_sensors_register(struct cros_ec_dev 
*ec)
kfree(msg);
 }
 
+static void cros_ec_cec_register(struct cros_ec_dev *ec)
+{
+   int ret;
+   struct mfd_cell cec_cell = {
+   .name = "cros-ec-cec",
+   };
+
+   ret = mfd_add_devices(ec->dev, 0, _cell, 1, NULL, 0, NULL);
+   if (ret)
+   dev_err(ec->dev, "failed to add EC CEC\n");
+}
+
 static int ec_device_probe(struct platform_device *pdev)
 {
int retval = -ENOMEM;
@@ -422,6 +434,10 @@ static int ec_device_probe(struct platform_device *pdev)
if (cros_ec_check_features(ec, EC_FEATURE_MOTION_SENSE))
cros_ec_sensors_register(ec);
 
+   /* check whether this EC handles CEC. */
+   if (cros_ec_check_features(ec, EC_FEATURE_CEC))
+   cros_ec_cec_register(ec);
+
/* Take control of the lightbar from the EC. */
lb_manual_suspend_ctrl(ec, 1);
 
-- 
2.7.4

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

[RFC PATCH 2/5] media: cec-notifier: Get notifier by device and connector name

[Neil Armstrong]

In non device-tree world, we can need to get the notifier by the driver
name directly and eventually defer probe if not yet created.

This patch adds a variant of the get function by using the device name
instead and will not create a notifier if not yet created.

But the i915 driver exposes at least 2 HDMI connectors, this patch also
adds the possibility to add a connector name tied to the notifier device
to form a tuple and associate different CEC controllers for each HDMI
connectors.

Signed-off-by: Neil Armstrong 
---
 drivers/media/cec/cec-notifier.c | 30 ---
 include/media/cec-notifier.h | 44 ++--
 2 files changed, 69 insertions(+), 5 deletions(-)

diff --git a/drivers/media/cec/cec-notifier.c b/drivers/media/cec/cec-notifier.c
index 16dffa0..716070a 100644
--- a/drivers/media/cec/cec-notifier.c
+++ b/drivers/media/cec/cec-notifier.c
@@ -21,6 +21,7 @@ struct cec_notifier {
struct list_head head;
struct kref kref;
struct device *dev;
+   const char *conn;
struct cec_adapter *cec_adap;
void (*callback)(struct cec_adapter *adap, u16 pa);
 
@@ -30,13 +31,34 @@ struct cec_notifier {
 static LIST_HEAD(cec_notifiers);
 static DEFINE_MUTEX(cec_notifiers_lock);
 
-struct cec_notifier *cec_notifier_get(struct device *dev)
+struct cec_notifier *cec_notifier_get_byname(const char *name,
+const char *conn)
 {
struct cec_notifier *n;
 
mutex_lock(_notifiers_lock);
list_for_each_entry(n, _notifiers, head) {
-   if (n->dev == dev) {
+   if (!strcmp(dev_name(n->dev), name) &&
+   (!conn || !strcmp(n->conn, conn))) {
+   kref_get(>kref);
+   mutex_unlock(_notifiers_lock);
+   return n;
+   }
+   }
+   mutex_unlock(_notifiers_lock);
+
+   return NULL;
+}
+EXPORT_SYMBOL_GPL(cec_notifier_get_byname);
+
+struct cec_notifier *cec_notifier_get_conn(struct device *dev, const char 
*conn)
+{
+   struct cec_notifier *n;
+
+   mutex_lock(_notifiers_lock);
+   list_for_each_entry(n, _notifiers, head) {
+   if (n->dev == dev &&
+   (!conn || !strcmp(n->conn, conn))) {
kref_get(>kref);
mutex_unlock(_notifiers_lock);
return n;
@@ -46,6 +68,8 @@ struct cec_notifier *cec_notifier_get(struct device *dev)
if (!n)
goto unlock;
n->dev = dev;
+   if (conn)
+   n->conn = devm_kstrdup(dev, conn, GFP_KERNEL);
n->phys_addr = CEC_PHYS_ADDR_INVALID;
mutex_init(>lock);
kref_init(>kref);
@@ -54,7 +78,7 @@ struct cec_notifier *cec_notifier_get(struct device *dev)
mutex_unlock(_notifiers_lock);
return n;
 }
-EXPORT_SYMBOL_GPL(cec_notifier_get);
+EXPORT_SYMBOL_GPL(cec_notifier_get_conn);
 
 static void cec_notifier_release(struct kref *kref)
 {
diff --git a/include/media/cec-notifier.h b/include/media/cec-notifier.h
index cf0add7..70f2974 100644
--- a/include/media/cec-notifier.h
+++ b/include/media/cec-notifier.h
@@ -20,6 +20,37 @@ struct cec_notifier;
 #if IS_REACHABLE(CONFIG_CEC_CORE) && IS_ENABLED(CONFIG_CEC_NOTIFIER)
 
 /**
+ * cec_notifier_get_byname - find a cec_notifier for the given device name
+ * and connector tuple.
+ * @name: device name that sends the events.
+ * @conn: the connector name from which the event occurs
+ *
+ * If a notifier for device @name exists, then increase the refcount and
+ * return that notifier.
+ *
+ * If it doesn't exist, return NULL
+ */
+struct cec_notifier *cec_notifier_get_byname(const char *name,
+const char *conn);
+
+/**
+ * cec_notifier_get_conn - find or create a new cec_notifier for the given
+ * device and connector tuple.
+ * @dev: device that sends the events.
+ * @conn: the connector name from which the event occurs
+ *
+ * If a notifier for device @dev already exists, then increase the refcount
+ * and return that notifier.
+ *
+ * If it doesn't exist, then allocate a new notifier struct and return a
+ * pointer to that new struct.
+ *
+ * Return NULL if the memory could not be allocated.
+ */
+struct cec_notifier *cec_notifier_get_conn(struct device *dev,
+  const char *conn);
+
+/**
  * cec_notifier_get - find or create a new cec_notifier for the given device.
  * @dev: device that sends the events.
  *
@@ -31,7 +62,10 @@ struct cec_notifier;
  *
  * Return NULL if the memory could not be allocated.
  */
-struct cec_notifier *cec_notifier_get(struct device *dev);
+static inline struct cec_notifier *cec_notifier_get(struct device *dev)
+{
+   return cec_notifier_get_conn(dev, NULL);
+}
 
 /**
  * cec_notifier_put - decrease refcount and delete when the refcount reaches 0.
@@ -85,12 +119,18 @@ 

[RFC PATCH 3/5] drm/i915: hdmi: add CEC notifier to intel_hdmi

[Neil Armstrong]

This patchs adds the cec_notifier feature to the intel_hdmi part
of the i915 DRM driver. It uses the HDMI DRM connector name to differentiate
between each HDMI ports.
The changes will allow the i915 HDMI code to notify EDID and HPD changes
to an eventual CEC adapter.

Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/i915/intel_drv.h  |  2 ++
 drivers/gpu/drm/i915/intel_hdmi.c | 10 ++
 2 files changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d436858..b50e51b 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -39,6 +39,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /**
  * __wait_for - magic wait macro
@@ -1001,6 +1002,7 @@ struct intel_hdmi {
bool has_audio;
bool rgb_quant_range_selectable;
struct intel_connector *attached_connector;
+   struct cec_notifier *notifier;
 };
 
 struct intel_dp_mst_encoder;
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 1baef4a..9b94d72 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1868,6 +1868,8 @@ intel_hdmi_set_edid(struct drm_connector *connector)
connected = true;
}
 
+   cec_notifier_set_phys_addr_from_edid(intel_hdmi->notifier, edid);
+
return connected;
 }
 
@@ -1876,6 +1878,7 @@ intel_hdmi_detect(struct drm_connector *connector, bool 
force)
 {
enum drm_connector_status status;
struct drm_i915_private *dev_priv = to_i915(connector->dev);
+   struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
 
DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
  connector->base.id, connector->name);
@@ -1891,6 +1894,9 @@ intel_hdmi_detect(struct drm_connector *connector, bool 
force)
 
intel_display_power_put(dev_priv, POWER_DOMAIN_GMBUS);
 
+   if (status != connector_status_connected)
+   cec_notifier_phys_addr_invalidate(intel_hdmi->notifier);
+
return status;
 }
 
@@ -2358,6 +2364,10 @@ void intel_hdmi_init_connector(struct intel_digital_port 
*intel_dig_port,
u32 temp = I915_READ(PEG_BAND_GAP_DATA);
I915_WRITE(PEG_BAND_GAP_DATA, (temp & ~0xf) | 0xd);
}
+
+   intel_hdmi->notifier = cec_notifier_get_conn(dev->dev, connector->name);
+   if (!intel_hdmi->notifier)
+   DRM_DEBUG_KMS("CEC notifier get failed\n");
 }
 
 void intel_hdmi_init(struct drm_i915_private *dev_priv,
-- 
2.7.4

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

[RFC PATCH 5/5] media: platform: Add Chrome OS EC CEC driver

[Neil Armstrong]

The Chrome OS Embedded Controller can expose a CEC bus, this patch add the
driver for such feature of the Embedded Controller.

This driver is part of the cros-ec MFD and will be add as a sub-device when
the feature bit is exposed by the EC.

The controller will only handle a single logical address and handles
all the messages retries and will only expose Success or Error.

When the logical address is invalid, the controller will act as a CEC sniffer
and transfer all messages on the bus.

Signed-off-by: Neil Armstrong 
---
 drivers/media/platform/Kconfig   |  11 +
 drivers/media/platform/Makefile  |   2 +
 drivers/media/platform/cros-ec/Makefile  |   1 +
 drivers/media/platform/cros-ec/cros-ec-cec.c | 331 +++
 4 files changed, 345 insertions(+)
 create mode 100644 drivers/media/platform/cros-ec/Makefile
 create mode 100644 drivers/media/platform/cros-ec/cros-ec-cec.c

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index c7a1cf8..e55a8ed2 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -546,6 +546,17 @@ menuconfig CEC_PLATFORM_DRIVERS
 
 if CEC_PLATFORM_DRIVERS
 
+config VIDEO_CROS_EC_CEC
+   tristate "Chrome OS EC CEC driver"
+   depends on MFD_CROS_EC || COMPILE_TEST
+   select CEC_CORE
+   select CEC_NOTIFIER
+   ---help---
+ If you say yes here you will get support for the
+ Chrome OS Embedded Controller's CEC.
+ The CEC bus is present in the HDMI connector and enables communication
+ between compatible devices.
+
 config VIDEO_MESON_AO_CEC
tristate "Amlogic Meson AO CEC driver"
depends on ARCH_MESON || COMPILE_TEST
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 932515d..0e0582e 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -92,3 +92,5 @@ obj-$(CONFIG_VIDEO_QCOM_CAMSS)+= 
qcom/camss-8x16/
 obj-$(CONFIG_VIDEO_QCOM_VENUS) += qcom/venus/
 
 obj-y  += meson/
+
+obj-y  += cros-ec/
diff --git a/drivers/media/platform/cros-ec/Makefile 
b/drivers/media/platform/cros-ec/Makefile
new file mode 100644
index 000..9ce97f9
--- /dev/null
+++ b/drivers/media/platform/cros-ec/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_VIDEO_CROS_EC_CEC) += cros-ec-cec.o
diff --git a/drivers/media/platform/cros-ec/cros-ec-cec.c 
b/drivers/media/platform/cros-ec/cros-ec-cec.c
new file mode 100644
index 000..fea90da
--- /dev/null
+++ b/drivers/media/platform/cros-ec/cros-ec-cec.c
@@ -0,0 +1,331 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * CEC driver for Chrome OS Embedded Controller
+ *
+ * Copyright (c) 2018 BayLibre, SAS
+ * Author: Neil Armstrong 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DRV_NAME   "cros-ec-cec"
+
+/**
+ * struct cros_ec_cec - Driver data for EC CEC
+ *
+ * @cros_ec: Pointer to EC device
+ * @notifier: Notifier info for responding to EC events
+ * @adap: CEC adapter
+ * @notify: CEC notifier pointer
+ * @rc_msg: storage for a received message
+ */
+struct cros_ec_cec {
+   struct cros_ec_device *cros_ec;
+   struct notifier_block notifier;
+   struct cec_adapter *adap;
+   struct cec_notifier *notify;
+   struct cec_msg rx_msg;
+};
+
+static void handle_cec_message(struct cros_ec_cec *cros_ec_cec)
+{
+   struct cros_ec_device *cros_ec = cros_ec_cec->cros_ec;
+   uint8_t *cec_message = cros_ec->event_data.data.cec_message;
+   unsigned int len = cros_ec->event_size;
+
+   cros_ec_cec->rx_msg.len = len;
+   memcpy(cros_ec_cec->rx_msg.msg, cec_message, len);
+
+   cec_received_msg(cros_ec_cec->adap, _ec_cec->rx_msg);
+}
+
+static void handle_cec_event(struct cros_ec_cec *cros_ec_cec)
+{
+   struct cros_ec_device *cros_ec = cros_ec_cec->cros_ec;
+   uint32_t events = cros_ec->event_data.data.cec_events;
+
+   if (events & EC_MKBP_CEC_SEND_OK)
+   cec_transmit_attempt_done(cros_ec_cec->adap,
+ CEC_TX_STATUS_OK);
+
+   if (events & EC_MKBP_CEC_SEND_FAILED)
+   cec_transmit_attempt_done(cros_ec_cec->adap,
+ CEC_TX_STATUS_ERROR);
+}
+
+static int cros_ec_cec_event(struct notifier_block *nb,
+   unsigned long queued_during_suspend, void *_notify)
+{
+   struct cros_ec_cec *cros_ec_cec;
+   struct cros_ec_device *cros_ec;
+
+   cros_ec_cec = container_of(nb, struct cros_ec_cec, notifier);
+   cros_ec = cros_ec_cec->cros_ec;
+
+   if (cros_ec->event_data.event_type == EC_MKBP_CEC_EVENT) {
+   handle_cec_event(cros_ec_cec);
+   return NOTIFY_OK;
+   }
+
+   if (cros_ec->event_data.event_type == 

[RFC PATCH 0/5] Add ChromeOS EC CEC Support

[Neil Armstrong]

Hi All,

The new Google "Fizz" Intel-based ChromeOS device is gaining CEC support
throught it's Embedded Controller, to enable the Linux CEC Core to communicate
with it and get the CEC Physical Address from the correct HDMI Connector, the
following must be added/changed:
- Add the CEC sub-device registration in the ChromeOS EC MFD Driver
- Add the CEC related commands and events definitions into the EC MFD driver
- Add a way to get a CEC notifier with it's (optional) connector name
- Add the CEC notifier to the i915 HDMI driver
- Add the proper ChromeOS EC CEC Driver

The CEC notifier with the connector name is the tricky point, since even on
Device-Tree platforms, there is no way to distinguish between multiple HDMI
connectors from the same DRM driver. The solution I implemented is pretty
simple and only adds an optional connector name to eventually distinguish
an HDMI connector notifier from another if they share the same device.

Feel free to comment this patchset !

Neil Armstrong (5):
  mfd: cros_ec_dev: Add CEC sub-device registration
  media: cec-notifier: Get notifier by device and connector name
  drm/i915: hdmi: add CEC notifier to intel_hdmi
  mfd: cros-ec: Introduce CEC commands and events definitions.
  media: platform: Add Chrome OS EC CEC driver

 drivers/gpu/drm/i915/intel_drv.h |   2 +
 drivers/gpu/drm/i915/intel_hdmi.c|  10 +
 drivers/media/cec/cec-notifier.c |  30 ++-
 drivers/media/platform/Kconfig   |  11 +
 drivers/media/platform/Makefile  |   2 +
 drivers/media/platform/cros-ec/Makefile  |   1 +
 drivers/media/platform/cros-ec/cros-ec-cec.c | 331 +++
 drivers/mfd/cros_ec_dev.c|  16 ++
 drivers/platform/chrome/cros_ec_proto.c  |  42 +++-
 include/linux/mfd/cros_ec.h  |   2 +-
 include/linux/mfd/cros_ec_commands.h |  80 +++
 include/media/cec-notifier.h |  44 +++-
 12 files changed, 556 insertions(+), 15 deletions(-)
 create mode 100644 drivers/media/platform/cros-ec/Makefile
 create mode 100644 drivers/media/platform/cros-ec/cros-ec-cec.c

-- 
2.7.4

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

[Bug 106500] GPU Recovery + DC deadlock

[bugzilla-daemon]

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

--- Comment #3 from Andrey Grodzovsky  ---
(In reply to Bas Nieuwenhuizen from comment #2)
> Created attachment 139568 [details]
> dmesg after trying 139562
> 
> I tried the patch and as expected we do not deadlock at the original places
> since we don't call those anymore. But I get garbage on my display (possibly
> expected due to loss of VRAM), can't switch VT and stopping X hangs X.
> 
> Furthermore I eventually still get stuck fence waits in dmesg (attached).
> 
> Furthermore, it seems the UVDF ringtest fails.

I think indeed the garbage is due to VRAM lost, maybe we don't create a shadow
BO for the display's BO. GPU reset fails due to  UVD failure to resume and SMU
failure so I believe that why any further fence submission hangs. The pipe
never recovers.

Harry, check the patch I attached, no reason to call 
drm_atomic_helper_resume/suspend explicitly from amdgpu_device_gpu_recover -
First of all it's already being called from the display code from
amd_ip_funcs.suspend/resume hooks.
Second of all, the place in amdgpu_device_gpu_recover it's being called is
wrong for GPU stalls since it is called BEFORE we cancel and force completion
of all in flight jobs which are stuck on the GPU. So as Bas explained it will
try to wait for fence  in amdgpu_pm_compute_clocks but the pipe is hanged so we
end up in deadlock. If we call the mode set AFTER forceful completion (as the
patch makes happen) no deadlock will happen.  

UVD/SMU failures require further debugging but I am on a different task at the
moment so maybe some one can pick this up...
Do you remember why that code is there ? I think it's remains of old code.
If you OK with this patch I will send it for review.

Further

-- 
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 106500] GPU Recovery + DC deadlock

[bugzilla-daemon]

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

--- Comment #2 from Bas Nieuwenhuizen  ---
Created attachment 139568
  --> https://bugs.freedesktop.org/attachment.cgi?id=139568=edit
dmesg after trying 139562

I tried the patch and as expected we do not deadlock at the original places
since we don't call those anymore. But I get garbage on my display (possibly
expected due to loss of VRAM), can't switch VT and stopping X hangs X.

Furthermore I eventually still get stuck fence waits in dmesg (attached).

Furthermore, it seems the UVDF ringtest fails.

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

linux-next: Signed-off-by missing for commits in the drm-intel tree

[Stephen Rothwell]

Hi all,

Commits

  cb8ba171ae6c ("drm/i915/gvt: let force_to_nonpriv cmd handler only valid for 
LRI cmd")
  0438a1059877 ("drm/i915/gvt: do not return error on handling force_to_nonpriv 
registers")
  3d8b9e258b9d ("drm/i915/gvt: let NOPID be the default value of 
force_to_nonpriv registers")
  b99f514f5dfa ("drm/i915/gvt: Remove disable_warn_untrack and print untracked 
mmio with debug level")

are missing a Signed-off-by from their committer.

-- 
Cheers,
Stephen Rothwell


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

[Bug 106519] Is it normal that the 4K video on the Vega 56 GPU played with loud turbine noise, 200% load of the desktop Core i7 CPU and at the same time playable with jerks and dropping frames?

[bugzilla-daemon]

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

--- Comment #1 from mikhail.v.gavri...@gmail.com ---
Created attachment 139567
  --> https://bugs.freedesktop.org/attachment.cgi?id=139567=edit
Video in Totem player

-- 
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 106519] Is it normal that the 4K video on the Vega 56 GPU played with loud turbine noise, 200% load of the desktop Core i7 CPU and at the same time playable with jerks and dropping frames?

[bugzilla-daemon]

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

--- Comment #2 from mikhail.v.gavri...@gmail.com ---
$ inxi -bM
System:Host: localhost.localdomain Kernel: 4.17.0-0.rc3.git4.1.fc29.x86_64
x86_64 bits: 64
   Desktop: Gnome 3.29.1 Distro: Fedora release 29 (Rawhide)
Machine:   Device: desktop System: Gigabyte product: Z87M-D3H serial: N/A
   Mobo: Gigabyte model: Z87M-D3H serial: N/A UEFI: American Megatrends
v: F11 date: 08/12/2014
Batteryhidpp__0: charge: N/A condition: NA/NA Wh
CPU:   Quad core Intel Core i7-4770 (-MT-MCP-) speed/max: 3790/3900 MHz
Graphics:  Card: Advanced Micro Devices [AMD/ATI] Vega 10 XT [Radeon RX Vega
64]
   Display Server: wayland (X.org 11.5 ) drivers:
modesetting,fbdev,vesa
   Resolution: 3840x2160@59.98hz
   OpenGL: renderer: Radeon RX Vega (VEGA10, DRM 3.25.0,
4.17.0-0.rc3.git4.1.fc29.x86_64, LLVM 6.0.0)
   version: 4.5 Mesa 18.1.0-rc3
Network:   Card: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet
Controller driver: r8169
Drives:HDD Total Size: 16241.0GB (19.6% used)
Info:  Processes: 429 Uptime: 1 day Memory: 16145.4/32037.0MB Client: Shell
(bash) inxi: 2.3.56

-- 
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 106519] Is it normal that the 4K video on the Vega 56 GPU played with loud turbine noise, 200% load of the desktop Core i7 CPU and at the same time playable with jerks and dropping frames?

[bugzilla-daemon]

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

Bug ID: 106519
   Summary: Is it normal that the 4K video on the Vega 56 GPU
played with loud turbine noise, 200% load of the
desktop Core i7 CPU and at the same time playable with
jerks and dropping frames?
   Product: DRI
   Version: XOrg git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: mikhail.v.gavri...@gmail.com

Created attachment 139566
  --> https://bugs.freedesktop.org/attachment.cgi?id=139566=edit
htop and xsensors

Is it normal that the 4K video on the Vega 56 GPU played with loud turbine
noise, 200% load of the desktop Core i7 CPU and at the same time playable with
jerks and dropping frames?

$ mpv --hwdec=vaapi Downloads/WE\ GOT\ INTEL\'S\ PROTOTYPE\ GRAPHICS\ CARD.webm 
Playing: Downloads/WE GOT INTEL'S PROTOTYPE GRAPHICS CARD.webm
 (+) Video --vid=1 (*) (vp9 3840x2160 29.970fps)
Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared object
file: No such file or directory
VO: [gpu] 3840x2160 yuv420p
V: 00:00:19 / 00:14:44 (2%) Dropped: 24


Exiting... (Quit)

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

Re: [PATCH v4 1/3] drm/panel: Add RGB666 variant of Innolux AT070TN90

[Paul Kocialkowski]

Hi,

Le vendredi 11 mai 2018 à 10:59 +0200, Maxime Ripard a écrit :
> On Wed, May 09, 2018 at 01:31:23PM +0200, Paul Kocialkowski wrote:
> > On Wed, 2018-05-09 at 09:12 +0200, Maxime Ripard wrote:
> > > On Tue, May 08, 2018 at 12:04:11AM +0200, Paul Kocialkowski wrote:
> > > > This adds timings for the RGB666 variant of the Innolux AT070TN90 panel,
> > > > as found on the Ainol AW1 tablet.
> > > > 
> > > > The panel also supports RGB888 output. When RGB666 mode is used instead,
> > > > the two extra lanes per component are grounded.
> > > > 
> > > > In the future, it might become necessary to introduce a dedicated
> > > > device-tree property to specify the bus format to use instead of the
> > > > default one for the panel. This will allow supporting different bus
> > > > formats for the same panel modes.
> > > > 
> > > > Signed-off-by: Paul Kocialkowski 
> > > > ---
> > > >  drivers/gpu/drm/panel/panel-simple.c | 26 ++
> > > >  1 file changed, 26 insertions(+)
> > > > 
> > > > diff --git a/drivers/gpu/drm/panel/panel-simple.c 
> > > > b/drivers/gpu/drm/panel/panel-simple.c
> > > > index cbf1ab404ee7..32e30d5a8f08 100644
> > > > --- a/drivers/gpu/drm/panel/panel-simple.c
> > > > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > > > @@ -1063,6 +1063,29 @@ static const struct panel_desc innolux_at043tn24 
> > > > = {
> > > > .bus_flags = DRM_BUS_FLAG_DE_HIGH | 
> > > > DRM_BUS_FLAG_PIXDATA_POSEDGE,
> > > >  };
> > > >  
> > > > +static const struct drm_display_mode innolux_at070tn90_mode = {
> > > > +   .clock = 4,
> > > > +   .hdisplay = 800,
> > > > +   .hsync_start = 800 + 112,
> > > > +   .hsync_end = 800 + 112 + 1,
> > > > +   .htotal = 800 + 112 + 1 + 87,
> > > > +   .vdisplay = 480,
> > > > +   .vsync_start = 480 + 141,
> > > > +   .vsync_end = 480 + 141 + 1,
> > > > +   .vtotal = 480 + 141 + 1 + 38,
> > > > +   .vrefresh = 60,
> > > > +};
> > > > +
> > > > +static const struct panel_desc innolux_at070tn90 = {
> > > > +   .modes = _at070tn90_mode,
> > > > +   .num_modes = 1,
> > > > +   .size = {
> > > > +   .width = 154,
> > > > +   .height = 86,
> > > > +   },
> > > > +   .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
> > > > +};
> > > > +
> > > 
> > > I'm not really convinced this is the right approach. You said it
> > > yourself, the panel is using a 24-bits interface, and you just happen
> > > to have a tablet that routed it using a 18-bits interface instead.
> > > 
> > > That doesn't belong in the driver, especially associated to the
> > > compatible, but where the routing is described: in the device
> > > tree. And given that the panel interface is a 24 bits panel, if we
> > > were to have a default, we should have this one, and not the one
> > > fitting your use case.
> > 
> > I fully agree, this is why I suggested introducing a dedicated dt
> > property for selecting the bus format (in the commit message). I still
> > proposed this patch as a temporary solution, but I'm definitely willing
> > to craft a proper solution as well.
> > 
> > Here is an initial proposition:
> > 1. Making bus_format an array in struct panel_desc and listing all the
> > relevant bus formats that the panel can support there;
> 
> I'm not sure this is needed, the input format is always the same in
> your case, the panel will always take a 24 bits RGB value. What you
> want to change is the encoder output format (and I guess you want that
> to be meaningful to enable or not the dithering).

Isn't the panel format supposed to match what the encoder's output
should be aiming for? In my case, that would be RGB666, so the idea
would be specifying both MEDIA_BUS_FMT_RGB666_1X18 and
MEDIA_BUS_FMT_RGB888_1X24 in a list of supported bus formats for the
panel. This way, both my setup and RGB888 setups can be supported.

> > 2. Introducing an optional "bus-format" dt property that indicates which
> > bus format to use, and using the first index of the bus formats array if
> > the property is not present;
> 
> I guess the width would be enough, and that way we can take the
> bus-width format that is already defined (but used in the v4l2
> framework, not in DRM yet).

Well, we already have bus-format defines on the DRM side and it feels
like mapping these directly in device-tree would be more useful as a
description of the hardware than just having the bus width.

Cheers,

Paul

-- 
Developer of free digital technology and hardware support.

Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/

signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 3/3] ARM: dts: sun7i: Add support for the Ainol AW1 tablet

[Paul Kocialkowski]

Hi and thanks for the review!

Le vendredi 11 mai 2018 à 16:36 +0200, Maxime Ripard a écrit :
> On Tue, May 08, 2018 at 12:04:13AM +0200, Paul Kocialkowski wrote:
> > +++ b/arch/arm/boot/dts/sun7i-a20-ainol-aw1.dts
> > @@ -0,0 +1,297 @@
> > +/*
> > + * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> 
> This really should be the first line, and with a C++ style comment, as
> in:
> 
> // SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> /*
>  * Copyright (C) ...
> 
> See Documentation/process/license-rules.rst

Okay, will do in v5.

> > +   backlight: backlight {
> > +   compatible = "pwm-backlight";
> > +   pwms = < 0 5 PWM_POLARITY_INVERTED>;
> > +   brightness-levels = <  0   1   1   1   1   2   2   2
> > +  2   3   3   3   3   4   4   4
> > +  5   5   5   6   6   6   7   7
> > +  8   8   8   9   9   9  10  10
> > + 10  11  11  12  12  12  13  13
> > + 14  14  14  15  15  16  16  17
> > + 17  17  18  18  19  19  20  20
> > + 21  21  21  22  22  23  23  24
> > + 24  25  25  26  26  27  27  28
> > + 28  29  30  30  31  31  32  32
> > + 33  33  34  35  35  36  36  37
> > + 38  38  39  39  40  41  41  42
> > + 43  43  44  44  45  46  47  47
> > + 48  49  49  50  51  51  52  53
> > + 54  54  55  56  57  57  58  59
> > + 60  61  61  62  63  64  65  65
> > + 66  67  68  69  70  71  71  72
> > + 73  74  75  76  77  78  79  80
> > + 81  82  83  84  85  86  87  88
> > + 89  90  91  92  93  94  95  96
> > + 97  98  99 101 102 103 104 105
> > +106 108 109 110 111 112 114 115
> > +116 117 119 120 121 123 124 125
> > +127 128 129 131 132 133 135 136
> > +138 139 141 142 144 145 147 148
> > +150 151 153 154 156 157 159 161
> > +162 164 166 167 169 171 173 174
> > +176 178 180 181 183 185 187 189
> > +191 192 194 196 198 200 202 204
> > +206 208 210 212 214 216 219 221
> > +223 225 227 229 232 234 236 238
> > +241 242 244 246 248 250 253 255>;
> 
> You kind of overdid it here :)
> 
> What I meant to say before was that if you have 10 elements (and you
> really should have something in that magnitude) each step should
> increase the perceived brightness by 10%.

Mhh I think 10 elements would fall too short to really depict the curve
with appropriate precision. Given the usual size for brightness cursors
in e.g. gnome-shell, it feels like a bigger number would be more
appropriate. Let's make it to 100 with values from 0 to 255!

> In this particular case, I really think having something close to <0 4
> 8 16 32 64 128 255> would be enough.
> 
> And in general, that kind of odd looking table without any more
> context is just screaming for a comment :)

Noted, I will explain the idea, but probably without the exact formula
that's really a nasty hack written down on a piece of paper sitting in
my garbage at this point.

-- 
Developer of free digital technology and hardware support.

Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/

signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Enric Balletbo Serra]

Hi Lin,

2018-05-14 11:53 GMT+02:00 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 

If you need to send another version, could you use the following name
and email address instead?

Reviewed-by: Enric Balletbo i Serra 

Thanks :)
 Enric

> ---
> Changes in v2:
> - update patch following Enric suggest
> - None
>  drivers/gpu/drm/rockchip/cdn-dp-core.c | 55 +++
>  drivers/gpu/drm/rockchip/cdn-dp-core.h |  1 +
>  drivers/gpu/drm/rockchip/cdn-dp-reg.c  | 69 
> ++
>  drivers/gpu/drm/rockchip/cdn-dp-reg.h  | 14 ++-
>  4 files changed, 122 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c 
> b/drivers/gpu/drm/rockchip/cdn-dp-core.c
> index c6fbdcd..cce64c1 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
> @@ -176,8 +176,8 @@ static int cdn_dp_get_sink_count(struct cdn_dp_device 
> *dp, u8 *sink_count)
> u8 value;
>
> *sink_count = 0;
> -   ret = cdn_dp_dpcd_read(dp, DP_SINK_COUNT, , 1);
> -   if (ret)
> +   ret = drm_dp_dpcd_read(>aux, DP_SINK_COUNT, , 1);
> +   if (ret < 0)
> return ret;
>
> *sink_count = DP_GET_SINK_COUNT(value);
> @@ -374,9 +374,9 @@ static int cdn_dp_get_sink_capability(struct 
> cdn_dp_device *dp)
> if (!cdn_dp_check_sink_connection(dp))
> return -ENODEV;
>
> -   ret = cdn_dp_dpcd_read(dp, DP_DPCD_REV, dp->dpcd,
> -  DP_RECEIVER_CAP_SIZE);
> -   if (ret) {
> +   ret = drm_dp_dpcd_read(>aux, DP_DPCD_REV, dp->dpcd,
> +  sizeof(dp->dpcd));
> +   if (ret < 0) {
> DRM_DEV_ERROR(dp->dev, "Failed to get caps %d\n", ret);
> return ret;
> }
> @@ -582,8 +582,8 @@ static bool cdn_dp_check_link_status(struct cdn_dp_device 
> *dp)
> if (!port || !dp->link.rate || !dp->link.num_lanes)
> return false;
>
> -   if (cdn_dp_dpcd_read(dp, DP_LANE0_1_STATUS, link_status,
> -DP_LINK_STATUS_SIZE)) {
> +   if (drm_dp_dpcd_read_link_status(>aux, link_status) !=
> +   DP_LINK_STATUS_SIZE) {
> DRM_ERROR("Failed to get link status\n");
> return false;
> }
> @@ -1012,6 +1012,40 @@ static int cdn_dp_pd_event(struct notifier_block *nb,
> return NOTIFY_DONE;
>  }
>
> +static ssize_t cdn_dp_aux_transfer(struct drm_dp_aux *aux,
> +  struct drm_dp_aux_msg *msg)
> +{
> +   struct cdn_dp_device *dp = container_of(aux, struct cdn_dp_device, 
> aux);
> +   int ret;
> +   u8 status;
> +
> +   switch (msg->request & ~DP_AUX_I2C_MOT) {
> +   case DP_AUX_NATIVE_WRITE:
> +   case DP_AUX_I2C_WRITE:
> +   case DP_AUX_I2C_WRITE_STATUS_UPDATE:
> +   ret = cdn_dp_dpcd_write(dp, msg->address, msg->buffer,
> +   msg->size);
> +   break;
> +   case DP_AUX_NATIVE_READ:
> +   case DP_AUX_I2C_READ:
> +   ret = cdn_dp_dpcd_read(dp, msg->address, msg->buffer,
> +  msg->size);
> +   break;
> +   default:
> +   return -EINVAL;
> +   }
> +
> +   status = cdn_dp_get_aux_status(dp);
> +   if (status == AUX_STATUS_ACK)
> +   msg->reply = DP_AUX_NATIVE_REPLY_ACK;
> +   else if (status == AUX_STATUS_NACK)
> +   msg->reply = DP_AUX_NATIVE_REPLY_NACK;
> +   else if (status == AUX_STATUS_DEFER)
> +   msg->reply = DP_AUX_NATIVE_REPLY_DEFER;
> +
> +   return ret;
> +}
> +
>  static int cdn_dp_bind(struct device *dev, struct device *master, void *data)
>  {
> struct cdn_dp_device *dp = dev_get_drvdata(dev);
> @@ -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;
>
> INIT_WORK(>event_work, cdn_dp_pd_event_work);
>
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.h 
> b/drivers/gpu/drm/rockchip/cdn-dp-core.h
> index f57e296..46159b2 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-core.h
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.h
> @@ -78,6 +78,7 @@ struct cdn_dp_device {
> struct 

[Bug 106517] IGT commit rights

[bugzilla-daemon]

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

--- Comment #1 from Dhinakaran Pandiyan  ---
Created attachment 139563
  --> https://bugs.freedesktop.org/attachment.cgi?id=139563=edit
SSH public key

-- 
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 2/2] drm/bridge: sii902x: add optional power supplies

[Philippe CORNU]

Hi Andrzej,

On 05/14/2018 12:33 PM, Andrzej Hajda wrote:
> On 14.05.2018 11:38, Philippe CORNU wrote:
>> Hi Laurent, Archit, Andrzej & Yannick,
>>
>> Do you have any comments on this v2 driver part?
>> (more details regarding v1/v2 differences in the cover letter
>> https://www.spinics.net/lists/dri-devel/msg174137.html)
>>
>> Thank you,
>> Philippe :-)
>>
>>
>> On 04/25/2018 09:53 AM, Philippe Cornu wrote:
>>> Add the optional power supplies using the description found in
>>> "SiI9022A/SiI9024A HDMI Transmitter Data Sheet (August 2016)".
>>>
>>> The sii902x input IOs are not "io safe" so it is important to
>>> enable/disable voltage regulators during probe/remove phases to
>>> avoid damages.
> 
> What exactly does it mean? Ie I understand that the chip has some
> limitations, but why enabling/disabling regulators in probe/remove
> should solve it?

thank you for your comment.

And sorry for the "bad" explanation in the 2nd paragraph about the fact 
that inputs are not "io safe". I added this 2nd paragraph in v2 
following a good comment from Laurent on adding the management of the 
regulators outside the probe/remove for a better power consumption 
management (enable/disable regulators only when the ic is used for 
displaying something for instance...). But after a deeper analysis, I 
realized that the only way to improve the power consumption is to 
implement & test the sii902x various sleep modes, that is out-of-scope 
of this small patch and also out-of-scope of my test board I use on 
which the sii902x bridge ic power consumption is very low compare to the 
rest of the system...

I will remove this "explanation" in v3 as it creates confusion.

Many thanks,
Philippe :-)

> 
> Regards
> Andrzej
> 
>>>
>>> Signed-off-by: Philippe Cornu 
>>> ---
>>>drivers/gpu/drm/bridge/sii902x.c | 38 
>>> ++
>>>1 file changed, 34 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/bridge/sii902x.c 
>>> b/drivers/gpu/drm/bridge/sii902x.c
>>> index 60373d7eb220..c367d7b91ade 100644
>>> --- a/drivers/gpu/drm/bridge/sii902x.c
>>> +++ b/drivers/gpu/drm/bridge/sii902x.c
>>> @@ -24,6 +24,7 @@
>>>#include 
>>>#include 
>>>#include 
>>> +#include 
>>>
>>>#include 
>>>#include 
>>> @@ -86,6 +87,7 @@ struct sii902x {
>>> struct drm_bridge bridge;
>>> struct drm_connector connector;
>>> struct gpio_desc *reset_gpio;
>>> +   struct regulator_bulk_data supplies[2];
>>>};
>>>
>>>static inline struct sii902x *bridge_to_sii902x(struct drm_bridge 
>>> *bridge)
>>> @@ -392,23 +394,42 @@ static int sii902x_probe(struct i2c_client *client,
>>> return PTR_ERR(sii902x->reset_gpio);
>>> }
>>>
>>> +   sii902x->supplies[0].supply = "iovcc";
>>> +   sii902x->supplies[1].supply = "vcc12";
>>> +   ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(sii902x->supplies),
>>> + sii902x->supplies);
>>> +   if (ret) {
>>> +   dev_err(dev, "Failed to get power supplies: %d\n", ret);
>>> +   return ret;
>>> +   }
>>> +
>>> +   ret = regulator_bulk_enable(ARRAY_SIZE(sii902x->supplies),
>>> +   sii902x->supplies);
>>> +   if (ret) {
>>> +   dev_err(dev, "Failed to enable power supplies: %d\n", ret);
>>> +   return ret;
>>> +   }
>>> +
>>> +   usleep_range(1, 2);
>>> +
>>> sii902x_reset(sii902x);
>>>
>>> ret = regmap_write(sii902x->regmap, SII902X_REG_TPI_RQB, 0x0);
>>> if (ret)
>>> -   return ret;
>>> +   goto err_disable_regulator;
>>>
>>> ret = regmap_bulk_read(sii902x->regmap, SII902X_REG_CHIPID(0),
>>>, 4);
>>> if (ret) {
>>> dev_err(dev, "regmap_read failed %d\n", ret);
>>> -   return ret;
>>> +   goto err_disable_regulator;
>>> }
>>>
>>> if (chipid[0] != 0xb0) {
>>> dev_err(dev, "Invalid chipid: %02x (expecting 0xb0)\n",
>>> chipid[0]);
>>> -   return -EINVAL;
>>> +   ret = -EINVAL;
>>> +   goto err_disable_regulator;
>>> }
>>>
>>> /* Clear all pending interrupts */
>>> @@ -424,7 +445,7 @@ static int sii902x_probe(struct i2c_client *client,
>>> IRQF_ONESHOT, dev_name(dev),
>>> sii902x);
>>> if (ret)
>>> -   return ret;
>>> +   goto err_disable_regulator;
>>> }
>>>
>>> sii902x->bridge.funcs = _bridge_funcs;
>>> @@ -434,6 +455,12 @@ static int sii902x_probe(struct i2c_client *client,
>>> i2c_set_clientdata(client, sii902x);
>>>
>>> return 0;
>>> +
>>> +err_disable_regulator:
>>> +   regulator_bulk_disable(ARRAY_SIZE(sii902x->supplies),
>>> +  sii902x->supplies);
>>> +
>>> +   return ret;
>>>}
>>>
>>>static int sii902x_remove(struct i2c_client 

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

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

--- Comment #202 from Ioannis Panagiotopoulos  ---
Can confirm that worked with kernel 4.16.7-300 on Fedora 28 Gnome with wayland
and the right boot arguments. However this worked when I had the R9 390
installed alone. When I used both the R9 390 and Rx 550 on the same system, the
display plugged on the R9 390 did not work correctly and produced broken UI
elements from time to time. Furthermore UI was very slow on response.
When tried Fedora 28 KDE, SDDM was constantly crashing when it tried to start
and stuck on a loop try-to-start->crash->try-to-start.
Kubuntu 18.04 KDE worked, but had the same issues as Fedora 28 Gnome.
So it seems the dpm bug is at last solved despite the other problems that might
be unrelated to dpm.

(In reply to heavyjoe from comment #201)
> (In reply to Sandeep from comment #200)
> > You can probably ignore the warnings, I get them too and nothing bad has
> > happened so far. As long as GPU hang doesn't occur, it's all good.
> 
> Thanks for the reply.
> In the problem reporting app it is written as
> "Unexpeted System Error" The system has encountered a problem and recovered.
> 
> The reason is as i wrote:
> WARNING: CPU: 1 PID: 369 at
> drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services.h:132
> generic_reg_update_ex+0x12c/0x160 [amdgpu]
> 
> so the system errors can occur as warnings? then i can live with it but i
> wasn't sure because it was labeled as system error...
> 
> thanks again. i will go on with that and hope no freezes appear.

if you installed the kernel manually, then try to install the
kernel-modules-extra package of this kernel version as well.

-- 
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 v10 1/2] drm: content-type property for HDMI connector

[Ville Syrjälä]

On Tue, May 08, 2018 at 10:44:56AM +0300, StanLis wrote:
> From: Stanislav Lisovskiy 
> 
> Added content_type property to drm_connector_state
> in order to properly handle external HDMI TV content-type setting.
> 
> v2:
>  * Moved helper function which attaches content type property
>to the drm core, as was suggested.
>Removed redundant connector state initialization.
> 
> v3:
>  * Removed caps in drm_content_type_enum_list.
>After some discussion it turned out that HDMI Spec 1.4
>was wrongly assuming that IT Content(itc) bit doesn't affect
>Content type states, however itc bit needs to be manupulated
>as well. In order to not expose additional property for itc,
>for sake of simplicity it was decided to bind those together
>in same "content type" property.
> 
> v4:
>  * Added it_content checking in intel_digital_connector_atomic_check.
>Fixed documentation for new content type enum.
> 
> v5:
>  * Moved patch revision's description to commit messages.
> 
> v6:
>  * Minor naming fix for the content type enumeration string.
> 
> v7:
>  * Fix parameter name for documentation and parameter alignment
>in order not to get warning. Added Content Type description to
>new HDMI connector properties section.
> 
> v8:
>  * Thrown away unneeded numbers from HDMI content-type property
>description. Switch to strings desription instead of plain
>definitions.
> 
> v9:
>  * Moved away hdmi specific content-type enum from
>drm_connector_state. Content type property should probably not
>be bound to any specific connector interface in
>drm_connector_state.
>Same probably should be done to hdmi_picture_aspect_ration enum
>which is also contained in drm_connector_state. Added special
>helper function to get derive hdmi specific relevant infoframe
>fields.
> 
> v10:
>  * Added usage description to HDMI properties kernel doc.
> 
> Acked-by: Hans Verkuil 
> Acked-by: Daniel Vetter 
> Signed-off-by: Stanislav Lisovskiy 
> ---
>  Documentation/gpu/drm-kms.rst|  6 +++
>  Documentation/gpu/kms-properties.csv |  1 +
>  drivers/gpu/drm/drm_atomic.c |  4 ++
>  drivers/gpu/drm/drm_connector.c  | 80 
>  drivers/gpu/drm/drm_edid.c   | 55 +++
>  include/drm/drm_connector.h  | 12 +
>  include/drm/drm_edid.h   |  6 +++
>  include/drm/drm_mode_config.h|  5 ++
>  include/uapi/drm/drm_mode.h  |  7 +++
>  9 files changed, 176 insertions(+)
> 
> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> index 1dffd1ac4cd4..e233c2626bd0 100644
> --- a/Documentation/gpu/drm-kms.rst
> +++ b/Documentation/gpu/drm-kms.rst
> @@ -517,6 +517,12 @@ Standard Connector Properties
>  .. kernel-doc:: drivers/gpu/drm/drm_connector.c
> :doc: standard connector properties
>  
> +HDMI Specific Connector Properties
> +-
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_connector.c
> +   :doc: HDMI connector properties
> +
>  Plane Composition Properties
>  
>  
> diff --git a/Documentation/gpu/kms-properties.csv 
> b/Documentation/gpu/kms-properties.csv
> index 07ed22ea3bd6..bfde04eddd14 100644
> --- a/Documentation/gpu/kms-properties.csv
> +++ b/Documentation/gpu/kms-properties.csv
> @@ -17,6 +17,7 @@ Owner Module/Drivers,Group,Property Name,Type,Property 
> Values,Object attached,De
>  ,Virtual GPU,“suggested X”,RANGE,"Min=0, Max=0x",Connector,property 
> to suggest an X offset for a connector
>  ,,“suggested Y”,RANGE,"Min=0, Max=0x",Connector,property to suggest 
> an Y offset for a connector
>  ,Optional,"""aspect ratio""",ENUM,"{ ""None"", ""4:3"", ""16:9"" 
> }",Connector,TDB
> +,Optional,"""content type""",ENUM,"{ ""No Data"", ""Graphics"", ""Photo"", 
> ""Cinema"", ""Game"" }",Connector,TBD
>  i915,Generic,"""Broadcast RGB""",ENUM,"{ ""Automatic"", ""Full"", ""Limited 
> 16:235"" }",Connector,"When this property is set to Limited 16:235 and CTM is 
> set, the hardware will be programmed with the result of the multiplication of 
> CTM by the limited range matrix to ensure the pixels normaly in the range 
> 0..1.0 are remapped to the range 16/255..235/255."
>  ,,“audio”,ENUM,"{ ""force-dvi"", ""off"", ""auto"", ""on"" }",Connector,TBD
>  ,SDVO-TV,“mode”,ENUM,"{ ""NTSC_M"", ""NTSC_J"", ""NTSC_443"", ""PAL_B"" } 
> etc.",Connector,TBD
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 3d9ae057a6cd..6c1e1e774517 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1270,6 +1270,8 @@ static int drm_atomic_connector_set_property(struct 
> drm_connector *connector,
>   state->link_status = val;
>   } else if (property == config->aspect_ratio_property) {
>   state->picture_aspect_ratio 

[Bug 106500] GPU Recovery + DC deadlock

[bugzilla-daemon]

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

--- Comment #1 from Andrey Grodzovsky  ---
Created attachment 139562
  --> https://bugs.freedesktop.org/attachment.cgi?id=139562=edit
Quick try to avoid deadlock

Can u give this a quick try and seed if it helps ?

-- 
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 106517] IGT commit rights

[bugzilla-daemon]

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

Bug ID: 106517
   Summary: IGT commit rights
   Product: DRI
   Version: XOrg git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: IGT
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: dhinakaran.pandi...@intel.com

Created attachment 139561
  --> https://bugs.freedesktop.org/attachment.cgi?id=139561=edit
GPG key

-- 
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 0/4] DRM helpers for Display Stream Compression PPS infoframes

[Manasi Navare]

On Mon, May 14, 2018 at 06:50:28PM +0200, Daniel Vetter wrote:
> On Wed, May 09, 2018 at 02:58:23PM -0700, Manasi Navare wrote:
> > VESA Display Stream Compression is a specification for visually losless
> > video compression over display links. The DSC standard also defines
> > a picture parameter set (PPS) which encoder must communicate to decoders.
> > This is done by encapsulating PPS header and payload bytes in an infoframe
> > that can be sent to the display sink using secondary data packets
> > as defined in DP 1.4 spec.
> > 
> > This patch series creates a new files drm_dsc.h and drm_dsc.c
> > which define all the DSC related structures and helpers that
> > can be called by drivers to form DSC PPS infoframes before
> > enabling Display Stream compression on eDP/DP/MIPI
> 
> Just an aside: At least here the threading for this patch series seems
> off. And patchwork also didn't pick up your cover letter:
> 
> https://patchwork.freedesktop.org/series/42969/
>

Yes the cover letter didnt get sent to the dri-devel, only to the
intel-gfx M-L: https://patchwork.freedesktop.org/series/42968/
 
> > 
> > These files can be used to add more DSC spec related helpers
> > common to all drivers.
> > 
> > Gaurav K Singh (1):
> >   drm/dsc: Define VESA Display Stream Compression Capabilities
> > 
> > Manasi Navare (3):
> >   drm/dp: Define payload size for DP SDP PPS packet
> >   drm/dsc: Define Display Stream Compression PPS infoframe
> >   drm/dsc: Add helpers for DSC picture parameter set infoframes
> > 
> >  drivers/gpu/drm/Makefile|   2 +-
> >  drivers/gpu/drm/drm_dsc.c   | 222 ++
> >  include/drm/drm_dp_helper.h |   1 +
> >  include/drm/drm_dsc.h   | 539 
> > 
> 
> Please include these new files into the overall kernel-doc structure (and
> make sure stuff is sufficiently documented).

I have added the necessary headers and documentation in the files itself
but will update the kernel-doc structure as wellf or these.

Manasi

> 
> Thanks, Daniel
> 
> >  4 files changed, 763 insertions(+), 1 deletion(-)
> >  create mode 100644 drivers/gpu/drm/drm_dsc.c
> >  create mode 100644 include/drm/drm_dsc.h
> > 
> > -- 
> > 2.7.4
> > 
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3] display: panel: Add AUO g070vvn01 display support (800x480)

[Rob Herring]

On Mon, May 14, 2018 at 10:36 AM, Lukasz Majewski  wrote:
> Dear All,

It is only Thierry that you need to ping. It goes thru his tree as I
mentioned on another panel you sent.

>> This commit adds support for AUO's 7.0" display.
>
> If I may gentle remind about this patch
>
>>
>> Signed-off-by: Lukasz Majewski 

You failed to add my Reviewed-by.

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

Re: [PATCH v2 1/2] dt-bindings/display/bridge: sii902x: add optional power supplies

[Laurent Pinchart]

Hi Philippe,

On Monday, 14 May 2018 12:22:16 EEST Philippe CORNU wrote:
> On 04/26/2018 12:05 AM, Laurent Pinchart wrote:
> > On Wednesday, 25 April 2018 20:11:23 EEST Rob Herring wrote:
> >> On Wed, Apr 25, 2018 at 04:17:25PM +0300, Laurent Pinchart wrote:
> >>> On Wednesday, 25 April 2018 15:20:04 EEST Philippe CORNU wrote:
>  On 04/25/2018 11:01 AM, Laurent Pinchart wrote:
> > On Wednesday, 25 April 2018 10:53:13 EEST Philippe Cornu wrote:
> >> Add optional power supplies using the description found in
> >> "SiI9022A/SiI9024A HDMI Transmitter Data Sheet (August 2016)".
> >>
> >> There is a single 1v2 supply voltage named vcc12 from which cvcc12
> >> (digital core) and avcc12 (TMDS analog) are derived because
> >> according to this data sheet:
> >> "cvcc12 and avcc12 can be derived from the same power source"
> >
> > Shouldn't the power supplies be mandatory, as explained by Mark in
> > https://lists.freedesktop.org/archives/dri-devel/2018-April/
> > 172400.html ?
> 
>  Laurent,
>  Many thanks Laurent for your comment, I understood the merge of the
>  two 1v2 power supplies but missed the "mandatory" part... maybe because
>  this patch (with optional power supplies) already got the reviewed-by
>  from Rob, I thought the discussion thread you pointed out was
>  applicable "only" to totally new driver documentation.
> 
>  So, on my side, as a "new user" of sii902x IC, no problem to put these
>  power supplies as mandatory instead of optional properties but I would
>  like to be sure this is applicable to both old and new bindings doc :
>  )
> >>>
> >>> We obviously need to retain backward compatibility, so on the driver
> >>> side you need to treat those power supplies as optional. From a DT
> >>> bindings point of view, however, I think they should be mandatory for
> >>> new DT.
> >>
> >> We don't really have a way to describe these 3 conditions (required for
> >> all, optional for all, and required for new). So generally we make
> >> additions optional. The exception sometimes is if we update all the dts
> >> files.
> > 
> > Can't we just make it mandatory in the bindings, as long as we treat it
> > as optional in drivers ?
> 
> How to progress on this patch? Do you have any suggestions?

By seeing what Rob thinks about my proposal above ? :-)

>  Rob,
>  could you please confirm these power supply properties should be
>  "mandatory"? if yes, should we then modify other optional properties
>  like the reset-gpios too in the future?
> >>>
> >>> The GPIOs properties are different in my opinion, as there's no
> >>> requirement to connect for instance the reset pin to a GPIO controllable
> >>> by the SoC. The pin could be hardwired to VCC, or connected to a system
> >>> reset that is automatically managed without SoC intervention. The power
> >>> supplies, however, are mandatory, in the sense that the chip will not
> >>> work if you leave the power supplies unconnected.
> >>
> >> DT only needs to describe what matters to s/w. If a regulator is
> >> fixed and you don't need to know its voltage (or other read-only
> >> parameters), then there's not much point in putting it in DT.
> >>
> >> I'd probably base this more at a platform level and you either use
> >> regulator binding or you don't. It's perfectly valid that you want to do
> >> things like regulator setup, pin ctrl and muxing setup, etc. all in
> >> firmware and the OS doesn't touch any of that.
> >>
> >> That's all a big can of worms which we shouldn't solve on this 2 line
> >> change. I think this change is fine as-is, so:
> >>
> >> Reviewed-by: Rob Herring 

-- 
Regards,

Laurent Pinchart



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

Re: [PATCH V1 2/5] backlight: qcom-wled: Add support for WLED4 peripheral

[Pavel Machek]

Hi!

> WLED4 peripheral is present on some PMICs like pmi8998
> and pm660l. It has a different register map and also
> configurations are different. Add support for it.
> 
> Signed-off-by: Kiran Gunda 
> ---
>  .../bindings/leds/backlight/qcom-wled.txt  | 172 -
>  drivers/video/backlight/qcom-wled.c| 749 
> +++--
>  2 files changed, 696 insertions(+), 225 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt 
> b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
> index fb39e32..0ceffa1 100644
> --- a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
> +++ b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
> @@ -1,30 +1,129 @@
>  Binding for Qualcomm Technologies, Inc. WLED driver
>  
> -Required properties:
> -- compatible: should be "qcom,pm8941-wled"
> -- reg: slave address
> -
> -Optional properties:
> -- default-brightness: brightness value on boot, value from: 0-4095
> - default: 2048
> +- compatible
> + Usage:required
> + Value type:   
> + Definition:   should be "qcom,pm8941-wled" or "qcom,pmi8998-wled".
> +   or "qcom,pm660l-wled".
> +
> +- reg
> + Usage:required
> + Value type:   
> + Definition:   Base address of the WLED modules.

I'm not sure if this change of format is good idea here...

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

Re: [PATCH 0/4] DRM helpers for Display Stream Compression PPS infoframes

[Daniel Vetter]

On Wed, May 09, 2018 at 02:58:23PM -0700, Manasi Navare wrote:
> VESA Display Stream Compression is a specification for visually losless
> video compression over display links. The DSC standard also defines
> a picture parameter set (PPS) which encoder must communicate to decoders.
> This is done by encapsulating PPS header and payload bytes in an infoframe
> that can be sent to the display sink using secondary data packets
> as defined in DP 1.4 spec.
> 
> This patch series creates a new files drm_dsc.h and drm_dsc.c
> which define all the DSC related structures and helpers that
> can be called by drivers to form DSC PPS infoframes before
> enabling Display Stream compression on eDP/DP/MIPI

Just an aside: At least here the threading for this patch series seems
off. And patchwork also didn't pick up your cover letter:

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

> 
> These files can be used to add more DSC spec related helpers
> common to all drivers.
> 
> Gaurav K Singh (1):
>   drm/dsc: Define VESA Display Stream Compression Capabilities
> 
> Manasi Navare (3):
>   drm/dp: Define payload size for DP SDP PPS packet
>   drm/dsc: Define Display Stream Compression PPS infoframe
>   drm/dsc: Add helpers for DSC picture parameter set infoframes
> 
>  drivers/gpu/drm/Makefile|   2 +-
>  drivers/gpu/drm/drm_dsc.c   | 222 ++
>  include/drm/drm_dp_helper.h |   1 +
>  include/drm/drm_dsc.h   | 539 
> 

Please include these new files into the overall kernel-doc structure (and
make sure stuff is sufficiently documented).

Thanks, Daniel

>  4 files changed, 763 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/drm_dsc.c
>  create mode 100644 include/drm/drm_dsc.h
> 
> -- 
> 2.7.4
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [PATCH] dma-fence: Make dma_fence_add_callback() fail if signaled with error

[Daniel Vetter]

On Fri, May 11, 2018 at 08:27:41AM +0100, Chris Wilson wrote:
> Quoting Ezequiel Garcia (2018-05-09 21:14:49)
> > Change how dma_fence_add_callback() behaves, when the fence
> > has error-signaled by the time it is being add. After this commit,
> > dma_fence_add_callback() returns the fence error, if it
> > has error-signaled before dma_fence_add_callback() is called.
> 
> Why? What problem are you trying to solve? fence->error does not imply
> that the fence has yet been signaled, and the caller wants a callback
> when it is signaled.

On top this is incosistent, e.g. we don't do the same for any of the other
dma_fence interfaces. Plus there's the issue that you might alias errno
values with fence errno values.

I think keeping the error codes from the functions you're calling distinct
from the error code of the fence itself makes a lot of sense. The first
tells you whether your request worked out (or why not), the second tells
you whether the asynchronous dma operation (gpu rendering, page flip,
whatever) that the dma_fence represents worked out (or why not). That's 2
distinct things imo.

Might be good to show us the driver code that needs this behaviour so we
can discuss how to best handle your use-case.

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

Re: [PATCH 03/21] clk: sunxi-ng: Enable DE2_CCU for Allwinner 64-bit SoCs

[Chen-Yu Tsai]

On Mon, May 14, 2018 at 1:20 AM, Jagan Teki  wrote:
> On Tue, May 1, 2018 at 9:53 PM, Chen-Yu Tsai  wrote:
>> On Mon, Apr 30, 2018 at 7:40 PM, Jagan Teki  
>> wrote:
>>> Allwinner 64-bit SoC like H5/A64 has DE2 CCU so enable them
>>> as default.
>>>
>>> Signed-off-by: Jagan Teki 
>>> ---
>>>  drivers/clk/sunxi-ng/Kconfig | 2 ++
>>>  1 file changed, 2 insertions(+)
>>>
>>> diff --git a/drivers/clk/sunxi-ng/Kconfig b/drivers/clk/sunxi-ng/Kconfig
>>> index 79dfd296c3d1..1fffd3bf6ff3 100644
>>> --- a/drivers/clk/sunxi-ng/Kconfig
>>> +++ b/drivers/clk/sunxi-ng/Kconfig
>>> @@ -58,6 +58,8 @@ config SUN8I_V3S_CCU
>>>
>>>  config SUN8I_DE2_CCU
>>> bool "Support for the Allwinner SoCs DE2 CCU"
>>> +   default ARM64 && ARCH_SUNXI
>>> +   depends on (DRM_SUN4I && (ARM64 && ARCH_SUNXI)) || COMPILE_TEST
>>
>> There is no reason to depend on DRM_SUN4I. There is no compile dependency.
>
> Since this CCU is for DE2 I've make DRM_SUN4I for that matter, any problem?

Users may very well be just using simplefb, but with all the clock drivers
enabled. That is a valid, if very limited, use case. So again, you should
not limit this driver based on DRM_SUN4I. There is no compile dependency.

>
>>
>> Also, this is needed on SUN8I as well, pretty much anything with DE 2.0.
>> So you shouldn't limit it to ARM64. That pretty much breaks things for
>> people with A83T's or H3's. In fact you should enable it by default for
>> these as well.
>
> True, I've skipped SUN8I since this series for A64.

And yet you are breaking existing users, which is a big no-no.

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

Re: [PATCH 3/3] drm/vc4: Attach underscan props to the HDMI connector

[Daniel Vetter]

On Wed, May 09, 2018 at 04:52:38PM +0200, Boris Brezillon wrote:
> On Mon, 7 May 2018 17:24:08 +0200
> Daniel Vetter  wrote:
> 
> > On Mon, May 07, 2018 at 04:44:34PM +0200, Boris Brezillon wrote:
> > > Now that the plane code takes the underscan setup into account, we can
> > > safely attach the underscan props to the HDMI connector.
> > > 
> > > We also take care of filling AVI infoframes correctly to expose the
> > > top/botton/left/right bar.
> > > 
> > > Note that these underscan props match pretty well the
> > > overscan_{left,right,top,bottom} properties defined in config.txt and
> > > parsed by the VC4 firmware.
> > > 
> > > Signed-off-by: Boris Brezillon 
> > > ---
> > >  drivers/gpu/drm/vc4/vc4_hdmi.c | 25 +
> > >  1 file changed, 25 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c 
> > > b/drivers/gpu/drm/vc4/vc4_hdmi.c
> > > index 1a6db291d48b..17464b5981f9 100644
> > > --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> > > +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> > > @@ -323,6 +323,16 @@ static struct drm_connector 
> > > *vc4_hdmi_connector_init(struct drm_device *dev,
> > >  DRM_MODE_CONNECTOR_HDMIA);
> > >   drm_connector_helper_add(connector, _hdmi_connector_helper_funcs);
> > >  
> > > + /* The hborder and vborder limit is arbitrarily set to 1024 which
> > > +  * should be more than enough for real use cases. Note that the actual
> > > +  * limitation comes from the display mode:
> > > +  *  hborder < hdisplay && vborder < vdisplay
> > > +  */
> > > + drm_connector_attach_underscan_properties(connector,  
> > 
> > We should probably sprinkle __must_check over all these :-)
> 
> I'm perfectly fine adding __must_check to
> drm_connector_attach_underscan_properties(), but I'm definitely not
> volunteering for a massive __must_check sanitization :P.

Yeah I just meant for this one here. The others might be a good candidate
for Documentation/gpu/todo.rst.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm SPDX updates

[Daniel Vetter]

On Mon, May 14, 2018 at 08:10:29AM -0700, Dirk Hohndel wrote:
> On Mon, May 14, 2018 at 05:01:43PM +0200, Thomas Hellstrom wrote:
> > > I haven't seen any comments in the week since I wrote this. I'm not
> > > familiar with the process for the drm changes - so what are the usual next
> > > steps? Do I need to submit all or part of this somewhere else? Or does
> > > Dave simply take the series (since it has no executable code changes at
> > > all)?
> > 
> > There are a number of teams sending pull requests to Dave. One option would
> > be to have it all go through the drm-misc tree. (CC'ing Daniel Vetter about
> > that). Another option would perhaps be to send a pull request directly to
> > Dave (Dave?) And finally, one option would be to rely on the maintainers of
> > each submodule to take the patches that touch that module. If you go for
> > this last option, I can surely take the patches that touch vmwgfx, and
> > Christian the TTM patches.
> 
> Again, since this involves no code changes, I think I'd prefer the path
> directly via Dave, simply as it makes it more likely that none of them get
> lost... assuming you are willing to do that, Dave, where would you like that 
> PR?

Cc: dri-devel and send it to Dave and you should be good. But I thought
Alex pulled this all in now? In the end probably doesn't matter really if
it gets merged twice :-)

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

Re: [PATCH v2 26/26] drm/bridge: establish a link between the bridge supplier and consumer

[Daniel Vetter]

On Fri, May 11, 2018 at 09:37:47AM +0200, Peter Rosin wrote:
> On 2018-05-10 10:10, Andrzej Hajda wrote:
> > On 04.05.2018 15:52, Peter Rosin wrote:
> >> If the bridge supplier is unbound, this will bring the bridge consumer
> >> down along with the bridge. Thus, there will no longer linger any
> >> dangling pointers from the bridge consumer (the drm_device) to some
> >> non-existent bridge supplier.
> >>
> >> Signed-off-by: Peter Rosin 
> >> ---
> >>  drivers/gpu/drm/drm_bridge.c | 18 ++
> >>  include/drm/drm_bridge.h |  2 ++
> >>  2 files changed, 20 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> >> index 78d186b6831b..0259f0a3ff27 100644
> >> --- a/drivers/gpu/drm/drm_bridge.c
> >> +++ b/drivers/gpu/drm/drm_bridge.c
> >> @@ -26,6 +26,7 @@
> >>  #include 
> >>  
> >>  #include 
> >> +#include 
> >>  #include 
> >>  
> >>  #include "drm_crtc_internal.h"
> >> @@ -127,12 +128,25 @@ int drm_bridge_attach(struct drm_encoder *encoder, 
> >> struct drm_bridge *bridge,
> >>if (bridge->dev)
> >>return -EBUSY;
> >>  
> >> +  if (encoder->dev->dev != bridge->odev) {
> > 
> > I wonder why device_link_add does not handle this case (self dependency)
> > silently as noop, as it seems to be a correct behavior.
> 
> It's kind-of a silly corner-case though, so perfectly understandable
> that it isn't handled.
> 
> >> +  bridge->link = device_link_add(encoder->dev->dev,
> >> + bridge->odev, 0);
> >> +  if (!bridge->link) {
> >> +  dev_err(bridge->odev, "failed to link bridge to %s\n",
> >> +  dev_name(encoder->dev->dev));
> >> +  return -EINVAL;
> >> +  }
> >> +  }
> >> +
> >>bridge->dev = encoder->dev;
> >>bridge->encoder = encoder;
> >>  
> >>if (bridge->funcs->attach) {
> >>ret = bridge->funcs->attach(bridge);
> >>if (ret < 0) {
> >> +  if (bridge->link)
> >> +  device_link_del(bridge->link);
> >> +  bridge->link = NULL;
> >>bridge->dev = NULL;
> >>bridge->encoder = NULL;
> >>return ret;
> >> @@ -159,6 +173,10 @@ void drm_bridge_detach(struct drm_bridge *bridge)
> >>if (bridge->funcs->detach)
> >>bridge->funcs->detach(bridge);
> >>  
> >> +  if (bridge->link)
> >> +  device_link_del(bridge->link);
> >> +  bridge->link = NULL;
> >> +
> >>bridge->dev = NULL;
> >>  }
> >>  
> >> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> >> index b656e505d11e..804189c63a4c 100644
> >> --- a/include/drm/drm_bridge.h
> >> +++ b/include/drm/drm_bridge.h
> >> @@ -261,6 +261,7 @@ struct drm_bridge_timings {
> >>   * @list: to keep track of all added bridges
> >>   * @timings: the timing specification for the bridge, if any (may
> >>   * be NULL)
> >> + * @link: drm consumer <-> bridge supplier
> > 
> > Nitpick: "<->" suggests symmetry, maybe "device link from drm consumer
> > to the bridge" would be better.
> 
> I meant "<->" to indicate that the link is bidirectional, not that the
> relationship is in any way symmetric. I wasn't aware of any implication
> of a symmetric relationship when using "<->", do you have a reference?
> But I guess the different arrow notations in math are somewhat overloaded
> and that someone at some point must have used "<->" to indicate a
> symmetric relationship...

Yeah I agree with Andrzej here, for me <-> implies a symmetric
relationship. Spelling it out like Andrzej suggested sounds like the
better idea.
-Daniel

> 
> > Anyway:
> > Reviewed-by: Andrzej Hajda 
> 
> Thanks!
> 
> Cheers,
> Peter
> 
> >  --
> > Regards
> > Andrzej
> > 
> >>   * @funcs: control functions
> >>   * @driver_private: pointer to the bridge driver's internal context
> >>   */
> >> @@ -271,6 +272,7 @@ struct drm_bridge {
> >>struct drm_bridge *next;
> >>struct list_head list;
> >>const struct drm_bridge_timings *timings;
> >> +  struct device_link *link;
> >>  
> >>const struct drm_bridge_funcs *funcs;
> >>void *driver_private;
> > 
> > 
> 

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

Re: [PATCH] gpu: drm: vgem: Change return type to vm_fault_t

[Daniel Vetter]

On Thu, May 10, 2018 at 02:51:38PM -0400, Sean Paul wrote:
> On Thu, May 10, 2018 at 07:58:11PM +0530, Souptick Joarder wrote:
> > Hi Sean,
> > 
> > On Mon, Apr 16, 2018 at 8:32 PM, Souptick Joarder  
> > wrote:
> > > Use new return type vm_fault_t for fault handler.
> > >
> > > Signed-off-by: Souptick Joarder 
> > > Reviewed-by: Matthew Wilcox 
> > > ---
> > >  drivers/gpu/drm/vgem/vgem_drv.c | 5 ++---
> > >  1 file changed, 2 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/vgem/vgem_drv.c 
> > > b/drivers/gpu/drm/vgem/vgem_drv.c
> > > index 2524ff1..c64a859 100644
> > > --- a/drivers/gpu/drm/vgem/vgem_drv.c
> > > +++ b/drivers/gpu/drm/vgem/vgem_drv.c
> > > @@ -61,13 +61,13 @@ static void vgem_gem_free_object(struct 
> > > drm_gem_object *obj)
> > > kfree(vgem_obj);
> > >  }
> > >
> > > -static int vgem_gem_fault(struct vm_fault *vmf)
> > > +static vm_fault_t vgem_gem_fault(struct vm_fault *vmf)
> > >  {
> > > struct vm_area_struct *vma = vmf->vma;
> > > struct drm_vgem_gem_object *obj = vma->vm_private_data;
> > > /* We don't use vmf->pgoff since that has the fake offset */
> > > unsigned long vaddr = vmf->address;
> > > -   int ret;
> > > +   vm_fault_t ret = VM_FAULT_SIGBUS;
> > > loff_t num_pages;
> > > pgoff_t page_offset;
> > > page_offset = (vaddr - vma->vm_start) >> PAGE_SHIFT;
> > > @@ -77,7 +77,6 @@ static int vgem_gem_fault(struct vm_fault *vmf)
> > > if (page_offset > num_pages)
> > > return VM_FAULT_SIGBUS;
> > >
> > > -   ret = -ENOENT;
> > > mutex_lock(>pages_lock);
> > > if (obj->pages) {
> > > get_page(obj->pages[page_offset]);
> > > --
> > > 1.9.1
> > >
> > 
> > Any further comment on this patch ?
> 
> Patch looks good to me. My build test fails, though, since vm_fault_t doesn't
> exist in drm-misc-next yet.

vm_fault_t is already in upstream, just needs Maarten to do a backmerge.
Which I think he's done by now ... Otherwise nag him more :-)
-Daniel

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

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

Re: [PATCH v3 02/40] drm: HDMI and DP specific HDCP2.2 defines

[Ramalingam C]

On Wednesday 09 May 2018 03:36 PM, Shankar, Uma wrote:



-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
Ramalingam C
Sent: Tuesday, April 3, 2018 7:27 PM
To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
jani.nik...@linux.intel.com; Winkler, Tomas ;
Usyskin, Alexander 
Cc: Vivi, Rodrigo 
Subject: [PATCH v3 02/40] drm: HDMI and DP specific HDCP2.2 defines

In preparation for implementing HDCP2.2 in I915, this patch adds HDCP register
definitions for HDMI and DP HDCP adaptations.

I believe we can just keep this message generic at drm layer, instead of 
calling out
i915 specifically. Currently it may be enabled for i915, but it will used for 
other
drivers as well in future.

ok



HDMI specific HDCP2.2 register definitions are added into drm_hdcp.h, where are

Make it "where as".

ok



HDCP2.2 register offsets in DPCD offsets are defined at drm_dp_helper.h.

v2:
  bit_field definitions are replaced by macros. [Tomas and Jany]

Typo in "Jani's" name.

Sorry Jani.



v3:
  No Changes.

Signed-off-by: Ramalingam C 
---
include/drm/drm_dp_helper.h | 54
+
include/drm/drm_hdcp.h  | 29 
2 files changed, 83 insertions(+)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index
4de97e94ef9d..2185b3a88911 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -887,6 +887,60 @@
#define DP_AUX_HDCP_KSV_FIFO0x6802C
#define DP_AUX_HDCP_AINFO   0x6803B

+/**
+ * DP HDCP2.2 parameter offsets in DPCD address space  */

Rectify the comment style

ok



+#define DP_HDCP_2_2_REG_RTX_OFFSET 0x69000
+#define DP_HDCP_2_2_REG_TXCAPS_OFFSET  0x69008
+#define DP_HDCP_2_2_REG_CERT_RX_OFFSET 0x6900B
+#define DP_HDCP_2_2_REG_RRX_OFFSET 0x69215
+#define DP_HDCP_2_2_REG_RX_CAPS_OFFSET 0x6921D
+#define DP_HDCP_2_2_REG_EKPUB_KM_OFFSET0x69220
+#define DP_HDCP_2_2_REG_EKH_KM_OFFSET  0x692A0
+#define DP_HDCP_2_2_REG_M_OFFSET   0x692B0
+#define DP_HDCP_2_2_REG_HPRIME_OFFSET  0x692C0
+#define DP_HDCP_2_2_REG_EKH_KM_RD_OFFSET   0x692E0
+#define DP_HDCP_2_2_REG_RN_OFFSET  0x692F0
+#define DP_HDCP_2_2_REG_LPRIME_OFFSET  0x692F8
+#define DP_HDCP_2_2_REG_EDKEY_KS_OFFSET0x69318
+#defineDP_HDCP_2_2_REG_RIV_OFFSET  0x69328
+#define DP_HDCP_2_2_REG_RXINFO_OFFSET  0x69330
+#define DP_HDCP_2_2_REG_SEQ_NUM_V_OFFSET   0x69332
+#define DP_HDCP_2_2_REG_VPRIME_OFFSET  0x69335
+#define DP_HDCP_2_2_REG_RECV_ID_LIST_OFFSET0x69345
+#define DP_HDCP_2_2_REG_V_OFFSET   0x693E0
+#define DP_HDCP_2_2_REG_SEQ_NUM_M_OFFSET   0x693F0
+#define DP_HDCP_2_2_REG_K_OFFSET   0x693F3
+#define DP_HDCP_2_2_REG_STREAM_ID_TYPE_OFFSET  0x693F5
+#define DP_HDCP_2_2_REG_MPRIME_OFFSET  0x69473
+#define DP_HDCP_2_2_REG_RXSTATUS_OFFSET0x69493
+#define DP_HDCP_2_2_REG_STREAM_TYPE_OFFSET 0x69494

This is not matching to the spec. Seems reserved in spec.

Not really. Register is defined in the DP HDCP2.2 Spec.



+#define DP_HDCP_2_2_REG_DBG_OFFSET 0x69518
+
+/**
+ * DP HDCP message start offsets in DPCD address space  */

Rectify comment style


+#define DP_HDCP_2_2_AKE_INIT_OFFSET
DP_HDCP_2_2_REG_RTX_OFFSET
+#define DP_HDCP_2_2_AKE_SEND_CERT_OFFSET
DP_HDCP_2_2_REG_CERT_RX_OFFSET
+#define DP_HDCP_2_2_AKE_NO_STORED_KM_OFFSET
DP_HDCP_2_2_REG_EKPUB_KM_OFFSET
+#define DP_HDCP_2_2_AKE_STORED_KM_OFFSET
DP_HDCP_2_2_REG_EKH_KM_OFFSET
+#define DP_HDCP_2_2_AKE_SEND_HPRIME_OFFSET
DP_HDCP_2_2_REG_HPRIME_OFFSET
+#define DP_HDCP_2_2_AKE_SEND_PARING_INFO_OFFSET

Typo in pairing

Fixed.



DP_HDCP_2_2_REG_EKH_KM_RD_OFFSET
+#define DP_HDCP_2_2_LC_INIT_OFFSET
DP_HDCP_2_2_REG_RN_OFFSET
+#define DP_HDCP_2_2_LC_SEND_LPRIME_OFFSET
DP_HDCP_2_2_REG_LPRIME_OFFSET
+#define DP_HDCP_2_2_SKE_SEND_EKS_OFFSET
DP_HDCP_2_2_REG_EDKEY_KS_OFFSET
+#define DP_HDCP_2_2_REP_SEND_RECVID_LIST_OFFSET
DP_HDCP_2_2_REG_RXINFO_OFFSET
+#define DP_HDCP_2_2_REP_SEND_ACK_OFFSET
DP_HDCP_2_2_REG_V_OFFSET
+#define DP_HDCP_2_2_REP_STREAM_MANAGE_OFFSET
DP_HDCP_2_2_REG_SEQ_NUM_M_OFFSET
+#define DP_HDCP_2_2_REP_STREAM_READY_OFFSET
DP_HDCP_2_2_REG_MPRIME_OFFSET
+
+#define HDCP_2_2_DP_RXSTATUS_LEN   1
+#define HDCP_2_2_DP_RXSTATUS_READY(x)  (x & BIT(0))
+#define HDCP_2_2_DP_RXSTATUS_H_PRIME(x)(x & BIT(1))
+#define HDCP_2_2_DP_RXSTATUS_PAIRING(x)(x & BIT(2))
+#define HDCP_2_2_DP_RXSTATUS_REAUTH_REQ(x) (x & BIT(3))
+#define HDCP_2_2_DP_RXSTATUS_LINK_FAILED(x)(x & 

Re: [PATCH] Add SPDX idenitifier and clarify license

[Christian König]

Am 14.05.2018 um 18:00 schrieb Alex Deucher:

On Wed, May 2, 2018 at 10:00 AM, Christian König
 wrote:

Am 02.05.2018 um 15:46 schrieb Thomas Hellstrom:

From: Dirk Hohndel 

This is dual licensed under GPL-2.0 or MIT.

Cc: "Christian König" 
Signed-off-by: Dirk Hohndel (VMware) 
Signed-off-by: Thomas Hellstrom 


Acked-by: Christian König 

If nobody objects I'm going to push it into our internal branch before the
weekend.

Did you ever push these?  I don't see them in the tree.


Ah, yes totally forgot about that. I think they (and another patch) 
ended up in the blacklist.


Need to ping John once more and probably work with those guys to change 
our server side rules for pushing license changes a bit.


Christian.



Alex



Thanks,
Christian.



---
   drivers/gpu/drm/ttm/ttm_agp_backend.c  | 1 +
   drivers/gpu/drm/ttm/ttm_bo.c   | 1 +
   drivers/gpu/drm/ttm/ttm_bo_manager.c   | 1 +
   drivers/gpu/drm/ttm/ttm_bo_util.c  | 1 +
   drivers/gpu/drm/ttm/ttm_bo_vm.c| 1 +
   drivers/gpu/drm/ttm/ttm_execbuf_util.c | 1 +
   drivers/gpu/drm/ttm/ttm_lock.c | 1 +
   drivers/gpu/drm/ttm/ttm_memory.c   | 1 +
   drivers/gpu/drm/ttm/ttm_module.c   | 1 +
   drivers/gpu/drm/ttm/ttm_object.c   | 1 +
   drivers/gpu/drm/ttm/ttm_tt.c   | 1 +
   11 files changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/ttm/ttm_agp_backend.c
b/drivers/gpu/drm/ttm/ttm_agp_backend.c
index 7c2485fe88d8..ea4d59eb8966 100644
--- a/drivers/gpu/drm/ttm/ttm_agp_backend.c
+++ b/drivers/gpu/drm/ttm/ttm_agp_backend.c
@@ -1,3 +1,4 @@
+/* SPDX-License-Identifier: GPL-2.0 OR MIT */

/**
*
* Copyright (c) 2006-2009 VMware, Inc., Palo Alto, CA., USA
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 98e06f8bf23b..68bcdd703cbd 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1,3 +1,4 @@
+/* SPDX-License-Identifier: GPL-2.0 OR MIT */

/**
*
* Copyright (c) 2006-2009 VMware, Inc., Palo Alto, CA., USA
diff --git a/drivers/gpu/drm/ttm/ttm_bo_manager.c
b/drivers/gpu/drm/ttm/ttm_bo_manager.c
index a7c232dc39cb..18d3debcc949 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_manager.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_manager.c
@@ -1,3 +1,4 @@
+/* SPDX-License-Identifier: GPL-2.0 OR MIT */

/**
*
* Copyright (c) 2007-2010 VMware, Inc., Palo Alto, CA., USA
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 2ebbae6067ab..1c17aa6a7c3c 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -1,3 +1,4 @@
+/* SPDX-License-Identifier: GPL-2.0 OR MIT */

/**
*
* Copyright (c) 2007-2009 VMware, Inc., Palo Alto, CA., USA
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c
b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 8eba95b3c737..c7ece7613a6a 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -1,3 +1,4 @@
+/* SPDX-License-Identifier: GPL-2.0 OR MIT */

/**
*
* Copyright (c) 2006-2009 VMware, Inc., Palo Alto, CA., USA
diff --git a/drivers/gpu/drm/ttm/ttm_execbuf_util.c
b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
index 3dca206e85f7..e73ae0d22897 100644
--- a/drivers/gpu/drm/ttm/ttm_execbuf_util.c
+++ b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
@@ -1,3 +1,4 @@
+/* SPDX-License-Identifier: GPL-2.0 OR MIT */

/**
*
* Copyright (c) 2006-2009 VMware, Inc., Palo Alto, CA., USA
diff --git a/drivers/gpu/drm/ttm/ttm_lock.c
b/drivers/gpu/drm/ttm/ttm_lock.c
index 913f4318cdc0..20694b8a01ca 100644
--- a/drivers/gpu/drm/ttm/ttm_lock.c
+++ b/drivers/gpu/drm/ttm/ttm_lock.c
@@ -1,3 +1,4 @@
+/* SPDX-License-Identifier: GPL-2.0 OR MIT */

/**
*
* Copyright (c) 2007-2009 VMware, Inc., Palo Alto, CA., USA
diff --git a/drivers/gpu/drm/ttm/ttm_memory.c
b/drivers/gpu/drm/ttm/ttm_memory.c
index 27856c55dc84..450387c92b63 100644
--- a/drivers/gpu/drm/ttm/ttm_memory.c
+++ b/drivers/gpu/drm/ttm/ttm_memory.c
@@ -1,3 +1,4 @@
+/* SPDX-License-Identifier: GPL-2.0 OR MIT */

/**
*
* Copyright (c) 2006-2009 VMware, Inc., Palo Alto, CA., USA
diff --git a/drivers/gpu/drm/ttm/ttm_module.c
b/drivers/gpu/drm/ttm/ttm_module.c
index 66fc6395eb54..6ff40c041d79 100644
--- a/drivers/gpu/drm/ttm/ttm_module.c
+++ b/drivers/gpu/drm/ttm/ttm_module.c
@@ -1,3 +1,4 @@
+/* 

Re: [PATCH] Add SPDX idenitifier and clarify license

[Alex Deucher]

On Wed, May 2, 2018 at 10:00 AM, Christian König
 wrote:
> Am 02.05.2018 um 15:46 schrieb Thomas Hellstrom:
>>
>> From: Dirk Hohndel 
>>
>> This is dual licensed under GPL-2.0 or MIT.
>>
>> Cc: "Christian König" 
>> Signed-off-by: Dirk Hohndel (VMware) 
>> Signed-off-by: Thomas Hellstrom 
>
>
> Acked-by: Christian König 
>
> If nobody objects I'm going to push it into our internal branch before the
> weekend.

Did you ever push these?  I don't see them in the tree.

Alex


>
> Thanks,
> Christian.
>
>
>> ---
>>   drivers/gpu/drm/ttm/ttm_agp_backend.c  | 1 +
>>   drivers/gpu/drm/ttm/ttm_bo.c   | 1 +
>>   drivers/gpu/drm/ttm/ttm_bo_manager.c   | 1 +
>>   drivers/gpu/drm/ttm/ttm_bo_util.c  | 1 +
>>   drivers/gpu/drm/ttm/ttm_bo_vm.c| 1 +
>>   drivers/gpu/drm/ttm/ttm_execbuf_util.c | 1 +
>>   drivers/gpu/drm/ttm/ttm_lock.c | 1 +
>>   drivers/gpu/drm/ttm/ttm_memory.c   | 1 +
>>   drivers/gpu/drm/ttm/ttm_module.c   | 1 +
>>   drivers/gpu/drm/ttm/ttm_object.c   | 1 +
>>   drivers/gpu/drm/ttm/ttm_tt.c   | 1 +
>>   11 files changed, 11 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/ttm/ttm_agp_backend.c
>> b/drivers/gpu/drm/ttm/ttm_agp_backend.c
>> index 7c2485fe88d8..ea4d59eb8966 100644
>> --- a/drivers/gpu/drm/ttm/ttm_agp_backend.c
>> +++ b/drivers/gpu/drm/ttm/ttm_agp_backend.c
>> @@ -1,3 +1,4 @@
>> +/* SPDX-License-Identifier: GPL-2.0 OR MIT */
>>
>> /**
>>*
>>* Copyright (c) 2006-2009 VMware, Inc., Palo Alto, CA., USA
>> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
>> index 98e06f8bf23b..68bcdd703cbd 100644
>> --- a/drivers/gpu/drm/ttm/ttm_bo.c
>> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
>> @@ -1,3 +1,4 @@
>> +/* SPDX-License-Identifier: GPL-2.0 OR MIT */
>>
>> /**
>>*
>>* Copyright (c) 2006-2009 VMware, Inc., Palo Alto, CA., USA
>> diff --git a/drivers/gpu/drm/ttm/ttm_bo_manager.c
>> b/drivers/gpu/drm/ttm/ttm_bo_manager.c
>> index a7c232dc39cb..18d3debcc949 100644
>> --- a/drivers/gpu/drm/ttm/ttm_bo_manager.c
>> +++ b/drivers/gpu/drm/ttm/ttm_bo_manager.c
>> @@ -1,3 +1,4 @@
>> +/* SPDX-License-Identifier: GPL-2.0 OR MIT */
>>
>> /**
>>*
>>* Copyright (c) 2007-2010 VMware, Inc., Palo Alto, CA., USA
>> diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
>> b/drivers/gpu/drm/ttm/ttm_bo_util.c
>> index 2ebbae6067ab..1c17aa6a7c3c 100644
>> --- a/drivers/gpu/drm/ttm/ttm_bo_util.c
>> +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
>> @@ -1,3 +1,4 @@
>> +/* SPDX-License-Identifier: GPL-2.0 OR MIT */
>>
>> /**
>>*
>>* Copyright (c) 2007-2009 VMware, Inc., Palo Alto, CA., USA
>> diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c
>> b/drivers/gpu/drm/ttm/ttm_bo_vm.c
>> index 8eba95b3c737..c7ece7613a6a 100644
>> --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
>> +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
>> @@ -1,3 +1,4 @@
>> +/* SPDX-License-Identifier: GPL-2.0 OR MIT */
>>
>> /**
>>*
>>* Copyright (c) 2006-2009 VMware, Inc., Palo Alto, CA., USA
>> diff --git a/drivers/gpu/drm/ttm/ttm_execbuf_util.c
>> b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
>> index 3dca206e85f7..e73ae0d22897 100644
>> --- a/drivers/gpu/drm/ttm/ttm_execbuf_util.c
>> +++ b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
>> @@ -1,3 +1,4 @@
>> +/* SPDX-License-Identifier: GPL-2.0 OR MIT */
>>
>> /**
>>*
>>* Copyright (c) 2006-2009 VMware, Inc., Palo Alto, CA., USA
>> diff --git a/drivers/gpu/drm/ttm/ttm_lock.c
>> b/drivers/gpu/drm/ttm/ttm_lock.c
>> index 913f4318cdc0..20694b8a01ca 100644
>> --- a/drivers/gpu/drm/ttm/ttm_lock.c
>> +++ b/drivers/gpu/drm/ttm/ttm_lock.c
>> @@ -1,3 +1,4 @@
>> +/* SPDX-License-Identifier: GPL-2.0 OR MIT */
>>
>> /**
>>*
>>* Copyright (c) 2007-2009 VMware, Inc., Palo Alto, CA., USA
>> diff --git a/drivers/gpu/drm/ttm/ttm_memory.c
>> b/drivers/gpu/drm/ttm/ttm_memory.c
>> index 27856c55dc84..450387c92b63 100644
>> --- a/drivers/gpu/drm/ttm/ttm_memory.c
>> +++ b/drivers/gpu/drm/ttm/ttm_memory.c
>> @@ -1,3 +1,4 @@
>> +/* SPDX-License-Identifier: GPL-2.0 OR MIT */
>>
>> /**
>>*
>>* Copyright (c) 2006-2009 VMware, Inc., Palo Alto, CA., USA
>> diff --git a/drivers/gpu/drm/ttm/ttm_module.c
>> b/drivers/gpu/drm/ttm/ttm_module.c
>> index 66fc6395eb54..6ff40c041d79 100644
>> --- a/drivers/gpu/drm/ttm/ttm_module.c
>> +++ 

Re: [Intel-gfx] [PATCH v3 01/40] drm: hdcp2.2 authentication msg definitions

[Ramalingam C]

Thank you for the review comments Uma Shankar!


On Wednesday 09 May 2018 03:31 PM, Shankar, Uma wrote:



-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Ramalingam C
Sent: Tuesday, April 3, 2018 7:27 PM
To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
jani.nik...@linux.intel.com; Winkler, Tomas ;
Usyskin, Alexander 
Cc: Vivi, Rodrigo 
Subject: [Intel-gfx] [PATCH v3 01/40] drm: hdcp2.2 authentication msg 
definitions

This patch defines the hdcp2.2 protocol messages for the

Drop redundant "the" and one of the hdcp2.2. Not required.

ok



HDCP2.2 authentication.

v2:
  bit_fields are removed. Instead bitmasking used. [Tomas and Jani]
  prefix HDCP_2_2_ is added to the macros. [Tomas]
v3:
  No Changes.

Signed-off-by: Ramalingam C 
---
include/drm/drm_hdcp.h | 183
+
1 file changed, 183 insertions(+)

diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h index
562fa7df2637..5e0a5ed1a08e 100644
--- a/include/drm/drm_hdcp.h
+++ b/include/drm/drm_hdcp.h
@@ -38,4 +38,187 @@
#define DRM_HDCP_DDC_BSTATUS0x41
#define DRM_HDCP_DDC_KSV_FIFO   0x43

+#define DRM_HDCP_1_4_SRM_ID0x8
+#define DRM_HDCP_1_4_VRL_LENGTH_SIZE   3
+#define DRM_HDCP_1_4_DCP_SIG_SIZE  40
+
+/**
+ * Protocol message definition for HDCP2.2 specification  */

Multi Line comment style not needed here.

Ok



+
+#define HDCP_STREAM_TYPE0  0x00
+#define HDCP_STREAM_TYPE1  0x01
+
+/* HDCP2.2 Msg IDs */
+#define HDCP_2_2_NULL_MSG  1
+#define HDCP_2_2_AKE_INIT  2
+#define HDCP_2_2_AKE_SEND_CERT 3
+#define HDCP_2_2_AKE_NO_STORED_KM  4
+#define HDCP_2_2_AKE_STORED_KM 5
+#define HDCP_2_2_AKE_SEND_HPRIME   7
+#define HDCP_2_2_AKE_SEND_PARING_INFO  8

Typo in Pairing

Fixed



+#define HDCP_2_2_LC_INIT   9
+#define HDCP_2_2_LC_SEND_LPRIME10
+#define HDCP_2_2_SKE_SEND_EKS  11
+#define HDCP_2_2_REP_SEND_RECVID_LIST  12
+#define HDCP_2_2_REP_SEND_ACK  15
+#define HDCP_2_2_REP_STREAM_MANAGE 16
+#define HDCP_2_2_REP_STREAM_READY  17
+#define HDCP_2_2_ERRATA_DP_STREAM_TYPE 50
+
+#define HDCP_2_2_RTX_LEN   8
+#define HDCP_2_2_RRX_LEN   8
+
+#define HDCP_2_2_K_PUB_RX_MOD_N_LEN128
+#define HDCP_2_2_K_PUB_RX_EXP_E_LEN3
+#define HDCP_2_2_K_PUB_RX_LEN
(HDCP_2_2_K_PUB_RX_MOD_N_LEN + \
+
HDCP_2_2_K_PUB_RX_EXP_E_LEN)
+
+#define HDCP_2_2_DCP_LLC_SIG_LEN   384
+
+#define HDCP_2_2_E_KPUB_KM_LEN 128
+#define HDCP_2_2_E_KH_KM_M_LEN (16 + 16)
+#define HDCP_2_2_H_PRIME_LEN   32
+#define HDCP_2_2_E_KH_KM_LEN   16
+#define HDCP_2_2_RN_LEN8
+#define HDCP_2_2_L_PRIME_LEN   32
+#define HDCP_2_2_E_DKEY_KS_LEN 16
+#define HDCP_2_2_RIV_LEN   8
+#define HDCP_2_2_SEQ_NUM_LEN   3
+#define HDCP_2_2_LPRIME_HALF_LEN   (HDCP_2_2_L_PRIME_LEN / 2)
+#define HDCP_2_2_RECEIVER_ID_LEN   DRM_HDCP_KSV_LEN
+#define HDCP_2_2_MAX_DEVICE_COUNT  31
+#define HDCP_2_2_RECEIVER_IDS_MAX_LEN
(HDCP_2_2_RECEIVER_ID_LEN * \
+
HDCP_2_2_MAX_DEVICE_COUNT)
+#define HDCP_2_2_MPRIME_LEN32
+
+/**

Remove an extra "*".


+ * TODO: This has to be changed for DP MST, as multiple stream on
+ * same port is possible.
+ * For HDCP2.2 on HDMI and DP SST this value is always 1.
+ */
+#define HDCP_2_2_MAX_CONTENT_STREAMS_CNT   1
+#define HDCP_2_2_TXCAP_MASK_LEN2
+#define HDCP_2_2_RXCAPS_LEN3
+#define HDCP_2_2_RX_REPEATER(x)(x & BIT(0))
+#define HDCP_2_2_DP_HDCP_CAPABLE(x)(x & BIT(1))
+#define HDCP_2_2_RXINFO_LEN2
+
+/* HDCP1.x compliant device in downstream */
+#define HDCP_2_2_HDCP1_DEVICE_CONNECTED(x) (x & BIT(0))
+
+/* HDCP2.0 Compliant repeater in downstream */
+#define HDCP_2_2_HDCP_2_0_REP_CONNECTED(x) (x & BIT(1))
+#define HDCP_2_2_MAX_CASCADE_EXCEEDED(x)   (x & BIT(2))
+#define HDCP_2_2_MAX_DEVS_EXCEEDED(x)  (x & BIT(3))
+#define HDCP_2_2_DEV_COUNT_LO(x)   ((x & (0xF << 4)) >> 4)
+#define HDCP_2_2_DEV_COUNT_HI(x)   (x & BIT(0))

As per 2.2 spec this is a 5 bit field and no mention of HI and LO is there for 
dev count.
A comment explaining why this masking style is chosen will be helpful since it 
doesn't
match exactly with spec.

dev 

[DPU PATCH v3 03/12] drm/msm/dpu: add MDSS top level driver for dpu

[Rajesh Yadav]

SoCs containing dpu have a MDSS top level wrapper
which includes sub-blocks as dpu, dsi, phy, dp etc.
MDSS top level wrapper manages common resources like
common clocks, power and irq for its sub-blocks.

Currently, in dpu driver, all the power resource
management is part of power_handle which manages
these resources via a custom implementation. And
the resource relationships are not modelled properly
in dt.  Moreover the irq domain handling code is part
of dpu device (which is a child device) due to lack
of a dedicated driver for MDSS top level wrapper
device.

This change adds dpu_mdss top level driver to handle
common clock like - core clock, ahb clock
(for register access), main power supply (i.e. gdsc)
and irq management.
The top level mdss device/driver acts as an interrupt
controller and manage hwirq mapping for its child
devices.

It implements runtime_pm support for resource management.
Child nodes can control these resources via runtime_pm
get/put calls on their corresponding devices due to parent
child relationship defined in dt.

Changes in v3:
- use "clock-frequency" dt-binding instead of "clock-rate",
  is it an optional binding (Sean Paul)
- remove handling of "clock-max-rate" proprietary
  dt-binding (Sean Paul)
- remove intermediate storing of msm_ioremap() retcode
  on failure instead return retcode directly (Sean Paul)
- msm_ioremap() prints error log in case of failure,
  so remove additional log from it's caller
- updated max core clock rate
- dropped (Reviewed-by: Jordan Crouse) due to above changes

Changes in v2:
- merge _dpu_mdss_hw_rev_init to dpu_mdss_init (Sean Paul)
- merge _dpu_mdss_get_intr_sources to dpu_mdss_irq (Sean Paul)
- fix indentation for irq_find_mapping call (Sean Paul)
- remove unnecessary goto statements from dpu_mdss_irq (Sean Paul)
- remove redundant param checks from
  dpu_mdss_irq_mask/unmask (Sean Paul/Jordan Crouse)
- remove redundant param checks from
  dpu_mdss_irqdomain_map (Sean Paul/Jordan Crouse)
- return error code from dpu_mdss_enable/disable (Sean Paul/Jordan 
Crouse)
- remove redundant param check from dpu_mdss_destroy (Sean Paul)
- remove explicit calls to devm_kfree (Sean Paul/Jordan Crouse)
- remove compatibility check from dpu_mdss_init as
  it is conditionally called from msm_drv (Sean Paul)
- reworked msm_dss_parse_clock() to add return checks for
  of_property_read_* calls, fix log message and
  fix alignment issues (Sean Paul/Jordan Crouse)
- remove extra line before dpu_mdss_init (Sean Paul)
- remove redundant param checks from __intr_offset and
  make it a void function to avoid unnecessary error
  handling from caller (Jordan Crouse)
- remove redundant param check from dpu_mdss_irq (Jordan Crouse)
- change mdss address space log message to debug and use %pK for
  kernel pointers (Jordan Crouse)
- remove unnecessary log message from msm_dss_parse_clock (Jordan 
Crouse)
- don't export msm_dss_parse_clock since it is used
  only by dpu driver (Jordan Crouse)

Signed-off-by: Rajesh Yadav 
---
 drivers/gpu/drm/msm/Makefile  |   1 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c  |  97 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.h  |  14 --
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h |   2 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c|   9 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h|   7 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c |  28 +--
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h |  11 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_irq.c   |  48 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c   |   6 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h   |   2 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c  | 251 ++
 drivers/gpu/drm/msm/dpu_io_util.c |  49 +
 drivers/gpu/drm/msm/msm_drv.c |  26 ++-
 drivers/gpu/drm/msm/msm_drv.h |   2 +-
 drivers/gpu/drm/msm/msm_kms.h |   1 +
 include/linux/dpu_io_util.h   |   2 +
 17 files changed, 329 insertions(+), 227 deletions(-)
 create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c

diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index d7558ed..d9826c1 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -81,6 +81,7 @@ msm-y := \
disp/dpu1/dpu_reg_dma.o \
disp/dpu1/dpu_rm.o \
disp/dpu1/dpu_vbif.o \
+   disp/dpu1/dpu_mdss.o \
dpu_dbg.o \
dpu_io_util.o \
dpu_dbg_evtlog.o \
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c
index 

[DPU PATCH v3 07/12] drm/msm/dpu: remove clock management code from dpu_power_handle

[Rajesh Yadav]

MDSS and dpu drivers manage their respective clocks via
runtime_pm. Remove custom clock management code from
dpu_power_handle.

Also dpu core clock management code is restricted to
dpu_core_perf module.

Changes in v3:
- none

Changes in v2:
- remove local variable to hold and return error code
  in _dpu_core_perf_set_core_clk_rate() instead return
  retcode directly from msm_dss_clk_set_rate() call (Sean Paul)
- dpu_core_perf_init() is called from dpu_kms_hw_init() and
  most of the params passed are already validated so remove
  redundant checks from dpu_core_perf_init() (Sean Paul)
- return >clk_config[i] directly to avoid local variable
  in _dpu_kms_get_clk() (Sean Paul)
- invert conditional check to eliminate local rate variable
  from dpu_kms_get_clk_rate() (Sean Paul)
- remove end label from dpu_power_resource_init() and return
  directly on dpu_power_parse_dt_supply() failure as no cleanup
  is needed (Sean Paul)
- remove checks for vtotal and vrefresh from
  dpu_encoder_phys_cmd_tearcheck_config() as they should be
  valid in mode_set call (Sean Paul)

Signed-off-by: Rajesh Yadav 
Reviewed-by: Sean Paul 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c  |  41 ++---
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h  |   8 +-
 .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c   |   9 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c|  28 ++-
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h|   9 +
 drivers/gpu/drm/msm/dpu_power_handle.c | 196 +
 drivers/gpu/drm/msm/dpu_power_handle.h |  40 -
 7 files changed, 63 insertions(+), 268 deletions(-)

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..5b79077 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
@@ -365,6 +365,17 @@ void dpu_core_perf_crtc_release_bw(struct drm_crtc *crtc)
}
 }
 
+static int _dpu_core_perf_set_core_clk_rate(struct dpu_kms *kms, u64 rate)
+{
+   struct dss_clk *core_clk = kms->perf.core_clk;
+
+   if (core_clk->max_rate && (rate > core_clk->max_rate))
+   rate = core_clk->max_rate;
+
+   core_clk->rate = rate;
+   return msm_dss_clk_set_rate(core_clk, 1);
+}
+
 static u64 _dpu_core_perf_get_core_clk_rate(struct dpu_kms *kms)
 {
u64 clk_rate = kms->perf.perf_tune.min_core_clk;
@@ -376,7 +387,8 @@ static u64 _dpu_core_perf_get_core_clk_rate(struct dpu_kms 
*kms)
dpu_cstate = to_dpu_crtc_state(crtc->state);
clk_rate = max(dpu_cstate->new_perf.core_clk_rate,
clk_rate);
-   clk_rate = clk_round_rate(kms->perf.core_clk, clk_rate);
+   clk_rate = clk_round_rate(kms->perf.core_clk->clk,
+   clk_rate);
}
}
 
@@ -484,15 +496,11 @@ void dpu_core_perf_crtc_update(struct drm_crtc *crtc,
 
DPU_EVT32(kms->dev, stop_req, clk_rate);
 
-   /* Temp change to avoid crash in clk_set_rate API. */
-#ifdef QCOM_DPU_SET_CLK
-   if (dpu_power_clk_set_rate(>phandle,
-  kms->perf.clk_name, clk_rate)) {
+   if (_dpu_core_perf_set_core_clk_rate(kms, clk_rate)) {
DPU_ERROR("failed to set %s clock rate %llu\n",
-   kms->perf.clk_name, clk_rate);
+   kms->perf.core_clk->clk_name, clk_rate);
return;
}
-#endif
 
kms->perf.core_clk_rate = clk_rate;
DPU_DEBUG("update clk rate = %lld HZ\n", clk_rate);
@@ -656,7 +664,6 @@ void dpu_core_perf_destroy(struct dpu_core_perf *perf)
dpu_core_perf_debugfs_destroy(perf);
perf->max_core_clk_rate = 0;
perf->core_clk = NULL;
-   perf->clk_name = NULL;
perf->phandle = NULL;
perf->catalog = NULL;
perf->dev = NULL;
@@ -667,9 +674,9 @@ int dpu_core_perf_init(struct dpu_core_perf *perf,
struct dpu_mdss_cfg *catalog,
struct dpu_power_handle *phandle,
struct dpu_power_client *pclient,
-   char *clk_name)
+   struct dss_clk *core_clk)
 {
-   if (!perf || !dev || !catalog || !phandle || !pclient || !clk_name) {
+   if (!pclient) {
DPU_ERROR("invalid parameters\n");
return -EINVAL;
}
@@ -678,23 +685,13 @@ int dpu_core_perf_init(struct dpu_core_perf *perf,
perf->catalog = catalog;
perf->phandle = phandle;
perf->pclient = pclient;
-   perf->clk_name = clk_name;
-
-   

[DPU PATCH v3 04/12] drm/msm/dpu: create new platform driver for dpu device

[Rajesh Yadav]

Current MSM display controller HW matches a tree like
hierarchy where MDSS top level wrapper is parent device
and mdp5/dpu, dsi, dp are child devices.

Each child device like mdp5, dsi etc. have a separate driver,
but currently dpu handling is tied to a single driver which
was managing both mdss and dpu resources.

Inorder to have the cleaner one to one device and driver
association, this change adds a new platform_driver for dpu
child device node which implements the kms functionality.

The dpu driver implements runtime_pm support for managing clocks
and bus bandwidth etc.

Changes in v3:
- none

Changes in v2:
- remove redundant param check from _dpu_kms_hw_destroy (Sean Paul)
- remove explicit calls to devm_kfree (Sean Paul)
- merge dpu_init into dpu_bind (Sean Paul)
- merge dpu_destroy into dpu_unbind (Sean Paul)
- use %pK for kernel pointer printing (Jordan Crouse)
- remove explicit devm allocation failure message (Jordan Crouse)

Signed-off-by: Rajesh Yadav 
Reviewed-by: Jordan Crouse 
Reviewed-by: Sean Paul 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 238 +---
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h |   4 +
 drivers/gpu/drm/msm/msm_drv.c   |   2 +
 drivers/gpu/drm/msm/msm_drv.h   |   3 +
 4 files changed, 196 insertions(+), 51 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index e4ab753..85f3dbc 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -1030,16 +1030,12 @@ static long dpu_kms_round_pixclk(struct msm_kms *kms, 
unsigned long rate,
return rate;
 }
 
-static void _dpu_kms_hw_destroy(struct dpu_kms *dpu_kms,
-   struct platform_device *pdev)
+static void _dpu_kms_hw_destroy(struct dpu_kms *dpu_kms)
 {
struct drm_device *dev;
struct msm_drm_private *priv;
int i;
 
-   if (!dpu_kms || !pdev)
-   return;
-
dev = dpu_kms->dev;
if (!dev)
return;
@@ -1091,15 +1087,15 @@ static void _dpu_kms_hw_destroy(struct dpu_kms *dpu_kms,
dpu_kms->core_client = NULL;
 
if (dpu_kms->vbif[VBIF_NRT])
-   msm_iounmap(pdev, dpu_kms->vbif[VBIF_NRT]);
+   msm_iounmap(dpu_kms->pdev, dpu_kms->vbif[VBIF_NRT]);
dpu_kms->vbif[VBIF_NRT] = NULL;
 
if (dpu_kms->vbif[VBIF_RT])
-   msm_iounmap(pdev, dpu_kms->vbif[VBIF_RT]);
+   msm_iounmap(dpu_kms->pdev, dpu_kms->vbif[VBIF_RT]);
dpu_kms->vbif[VBIF_RT] = NULL;
 
if (dpu_kms->mmio)
-   msm_iounmap(pdev, dpu_kms->mmio);
+   msm_iounmap(dpu_kms->pdev, dpu_kms->mmio);
dpu_kms->mmio = NULL;
 
dpu_reg_dma_deinit();
@@ -1172,8 +1168,6 @@ int dpu_kms_mmu_attach(struct dpu_kms *dpu_kms, bool 
secure_only)
 static void dpu_kms_destroy(struct msm_kms *kms)
 {
struct dpu_kms *dpu_kms;
-   struct drm_device *dev;
-   struct platform_device *platformdev;
 
if (!kms) {
DPU_ERROR("invalid kms\n");
@@ -1181,20 +1175,7 @@ static void dpu_kms_destroy(struct msm_kms *kms)
}
 
dpu_kms = to_dpu_kms(kms);
-   dev = dpu_kms->dev;
-   if (!dev) {
-   DPU_ERROR("invalid device\n");
-   return;
-   }
-
-   platformdev = to_platform_device(dev->dev);
-   if (!platformdev) {
-   DPU_ERROR("invalid platform device\n");
-   return;
-   }
-
-   _dpu_kms_hw_destroy(dpu_kms, platformdev);
-   kfree(dpu_kms);
+   _dpu_kms_hw_destroy(dpu_kms);
 }
 
 static void dpu_kms_preclose(struct msm_kms *kms, struct drm_file *file)
@@ -1550,7 +1531,6 @@ static int dpu_kms_hw_init(struct msm_kms *kms)
struct dpu_kms *dpu_kms;
struct drm_device *dev;
struct msm_drm_private *priv;
-   struct platform_device *platformdev;
int i, rc = -EINVAL;
 
if (!kms) {
@@ -1565,34 +1545,28 @@ static int dpu_kms_hw_init(struct msm_kms *kms)
goto end;
}
 
-   platformdev = to_platform_device(dev->dev);
-   if (!platformdev) {
-   DPU_ERROR("invalid platform device\n");
-   goto end;
-   }
-
priv = dev->dev_private;
if (!priv) {
DPU_ERROR("invalid private data\n");
goto end;
}
 
-   dpu_kms->mmio = msm_ioremap(platformdev, "mdp_phys", "mdp_phys");
+   dpu_kms->mmio = msm_ioremap(dpu_kms->pdev, "mdp_phys", "mdp_phys");
if (IS_ERR(dpu_kms->mmio)) {
rc = PTR_ERR(dpu_kms->mmio);
DPU_ERROR("mdp register memory map failed: %d\n", rc);
dpu_kms->mmio = NULL;
goto error;
}
-   DRM_INFO("mapped mdp address space @%p\n", dpu_kms->mmio);
-   

[DPU PATCH v3 12/12] drm/msm/dpu: add error handling in dpu_core_perf_crtc_update

[Rajesh Yadav]

dpu_core_perf_crtc_update() is responsible for aggregating
the data bus bandwidth and dpu core clock rate requirements
and request the same for all active crtcs.
Currently, there is no error handling support in this function
so there is no way caller can know if the perf request fails.
This change adds error handling code in dpu_core_perf_crtc_update().
The caller side error handling is not added in this patch.

Changes in v3:
- none

Signed-off-by: Rajesh Yadav 
Reviewed-by: Sean Paul 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 37 ++-
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h |  3 ++-
 2 files changed, 27 insertions(+), 13 deletions(-)

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 d3a1ed9..85c0229 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
@@ -248,7 +248,7 @@ int dpu_core_perf_crtc_check(struct drm_crtc *crtc,
return 0;
 }
 
-static void _dpu_core_perf_crtc_update_bus(struct dpu_kms *kms,
+static int _dpu_core_perf_crtc_update_bus(struct dpu_kms *kms,
struct drm_crtc *crtc, u32 bus_id)
 {
u64 bw_sum_of_intfs = 0, bus_ab_quota, bus_ib_quota;
@@ -257,6 +257,7 @@ static void _dpu_core_perf_crtc_update_bus(struct dpu_kms 
*kms,
= dpu_crtc_get_client_type(crtc);
struct drm_crtc *tmp_crtc;
struct dpu_crtc_state *dpu_cstate;
+   int ret = 0;
 
drm_for_each_crtc(tmp_crtc, crtc->dev) {
if (_dpu_core_perf_crtc_is_power_on(tmp_crtc) &&
@@ -286,25 +287,28 @@ static void _dpu_core_perf_crtc_update_bus(struct dpu_kms 
*kms,
 
switch (curr_client_type) {
case NRT_CLIENT:
-   dpu_power_data_bus_set_quota(>phandle, kms->core_client,
+   ret = dpu_power_data_bus_set_quota(
+   >phandle, kms->core_client,
DPU_POWER_HANDLE_DATA_BUS_CLIENT_NRT,
bus_id, bus_ab_quota, bus_ib_quota);
DPU_DEBUG("client:%s bus_id=%d ab=%llu ib=%llu\n", "nrt",
-   bus_id, bus_ab_quota, bus_ib_quota);
+ bus_id, bus_ab_quota, bus_ib_quota);
break;
 
case RT_CLIENT:
-   dpu_power_data_bus_set_quota(>phandle, kms->core_client,
+   ret = dpu_power_data_bus_set_quota(
+   >phandle, kms->core_client,
DPU_POWER_HANDLE_DATA_BUS_CLIENT_RT,
bus_id, bus_ab_quota, bus_ib_quota);
DPU_DEBUG("client:%s bus_id=%d ab=%llu ib=%llu\n", "rt",
-   bus_id, bus_ab_quota, bus_ib_quota);
+ bus_id, bus_ab_quota, bus_ib_quota);
break;
 
default:
DPU_ERROR("invalid client type:%d\n", curr_client_type);
break;
}
+   return ret;
 }
 
 /**
@@ -399,7 +403,7 @@ static u64 _dpu_core_perf_get_core_clk_rate(struct dpu_kms 
*kms)
return clk_rate;
 }
 
-void dpu_core_perf_crtc_update(struct drm_crtc *crtc,
+int dpu_core_perf_crtc_update(struct drm_crtc *crtc,
int params_changed, bool stop_req)
 {
struct dpu_core_perf_params *new, *old;
@@ -410,16 +414,17 @@ void dpu_core_perf_crtc_update(struct drm_crtc *crtc,
int i;
struct msm_drm_private *priv;
struct dpu_kms *kms;
+   int ret;
 
if (!crtc) {
DPU_ERROR("invalid crtc\n");
-   return;
+   return -EINVAL;
}
 
kms = _dpu_crtc_get_kms(crtc);
if (!kms || !kms->catalog) {
DPU_ERROR("invalid kms\n");
-   return;
+   return -EINVAL;
}
priv = kms->dev->dev_private;
 
@@ -482,8 +487,14 @@ void dpu_core_perf_crtc_update(struct drm_crtc *crtc,
update_bus, update_clk);
 
for (i = 0; i < DPU_POWER_HANDLE_DBUS_ID_MAX; i++) {
-   if (update_bus & BIT(i))
-   _dpu_core_perf_crtc_update_bus(kms, crtc, i);
+   if (update_bus & BIT(i)) {
+   ret = _dpu_core_perf_crtc_update_bus(kms, crtc, i);
+   if (ret) {
+   DPU_ERROR("crtc-%d: failed to update bw vote 
for bus-%d\n",
+ crtc->base.id, i);
+   return ret;
+   }
+   }
}
 
/*
@@ -495,15 +506,17 @@ void dpu_core_perf_crtc_update(struct drm_crtc *crtc,
 
DPU_EVT32(kms->dev, stop_req, clk_rate);
 
-   if (_dpu_core_perf_set_core_clk_rate(kms, clk_rate)) {
+   ret = _dpu_core_perf_set_core_clk_rate(kms, clk_rate);
+ 

[DPU PATCH v3 10/12] drm/msm/dpu: use runtime_pm calls in dpu_dbg

[Rajesh Yadav]

Currently, msm_drv was creating dpu_power_handle client
which was used by dpu_dbg module to enable power resources
before register debug dumping.

Now since, the mdss core power resource handling is
implemented via runtime_pm and same has been removed
from dpu_power_handle. Remove dpu_power_handle dependency
from msm_drv and use pm_runtime_get/put_sync calls from
dpu_dbg module on dpu_mdss top level device for core,
ahb clock and power resource management (for register access).

Changes in v3:
- none

Changes in v2:
- resolved conflict in dpu_core_perf_init
- dropped (Reviewed-by: Sean Paul) due to above change

Signed-off-by: Rajesh Yadav 
Reviewed-by: Sean Paul 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c |  7 ---
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h |  4 
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c   |  3 +--
 drivers/gpu/drm/msm/dpu_dbg.c | 18 +++---
 drivers/gpu/drm/msm/dpu_dbg.h | 13 ++---
 drivers/gpu/drm/msm/msm_drv.c | 27 +--
 drivers/gpu/drm/msm/msm_drv.h |  1 -
 7 files changed, 11 insertions(+), 62 deletions(-)

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 5b79077..2cf3fca 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
@@ -673,18 +673,11 @@ int dpu_core_perf_init(struct dpu_core_perf *perf,
struct drm_device *dev,
struct dpu_mdss_cfg *catalog,
struct dpu_power_handle *phandle,
-   struct dpu_power_client *pclient,
struct dss_clk *core_clk)
 {
-   if (!pclient) {
-   DPU_ERROR("invalid parameters\n");
-   return -EINVAL;
-   }
-
perf->dev = dev;
perf->catalog = catalog;
perf->phandle = phandle;
-   perf->pclient = pclient;
perf->core_clk = core_clk;
 
perf->max_core_clk_rate = core_clk->max_rate;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
index 015b5f0..5198e3c 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.h
@@ -53,7 +53,6 @@ struct dpu_core_perf_tune {
  * @debugfs_root: top level debug folder
  * @catalog: Pointer to catalog configuration
  * @phandle: Pointer to power handler
- * @pclient: Pointer to power client
  * @core_clk: Pointer to core clock structure
  * @core_clk_rate: current core clock rate
  * @max_core_clk_rate: maximum allowable core clock rate
@@ -68,7 +67,6 @@ struct dpu_core_perf {
struct dentry *debugfs_root;
struct dpu_mdss_cfg *catalog;
struct dpu_power_handle *phandle;
-   struct dpu_power_client *pclient;
struct dss_clk *core_clk;
u64 core_clk_rate;
u64 max_core_clk_rate;
@@ -115,14 +113,12 @@ void dpu_core_perf_crtc_update(struct drm_crtc *crtc,
  * @dev: Pointer to drm device
  * @catalog: Pointer to catalog
  * @phandle: Pointer to power handle
- * @pclient: Pointer to power client
  * @core_clk: pointer to core clock
  */
 int dpu_core_perf_init(struct dpu_core_perf *perf,
struct drm_device *dev,
struct dpu_mdss_cfg *catalog,
struct dpu_power_handle *phandle,
-   struct dpu_power_client *pclient,
struct dss_clk *core_clk);
 
 /**
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 349bda5..9c3b220 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -1721,8 +1721,7 @@ static int dpu_kms_hw_init(struct msm_kms *kms)
 #endif
 
rc = dpu_core_perf_init(_kms->perf, dev, dpu_kms->catalog,
-   >phandle, priv->pclient,
-   _dpu_kms_get_clk(dpu_kms, "core_clk"));
+   >phandle, _dpu_kms_get_clk(dpu_kms, "core_clk"));
if (rc) {
DPU_ERROR("failed to init perf %d\n", rc);
goto perf_err;
diff --git a/drivers/gpu/drm/msm/dpu_dbg.c b/drivers/gpu/drm/msm/dpu_dbg.c
index 4a39b82..27538bc 100644
--- a/drivers/gpu/drm/msm/dpu_dbg.c
+++ b/drivers/gpu/drm/msm/dpu_dbg.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "dpu_dbg.h"
 #include "disp/dpu1/dpu_hw_catalog.h"
@@ -167,7 +168,6 @@ struct dpu_dbg_vbif_debug_bus {
  * @evtlog: event log instance
  * @reg_base_list: list of register dumping regions
  * @dev: device pointer
- * @power_ctrl: callback structure for enabling power for reading hw registers
  * @req_dump_blks: list of blocks requested for dumping
  * @panic_on_err: whether to kernel panic after triggering dump via debugfs
  * @dump_work: work struct for deferring register dump work to separate thread
@@ -182,7 

[DPU PATCH v3 02/12] drm/msm/mdp5: subclass msm_mdss for mdp5

[Rajesh Yadav]

SoCs having mdp5 or dpu have identical tree like
device hierarchy where MDSS top level wrapper manages
common power resources for all child devices.

Subclass msm_mdss so that msm_mdss includes common defines
and mdp5/dpu mdss derivations to include any extensions.

Add mdss helper interface (msm_mdss_funcs) to msm_mdss
base for mdp5/dpu mdss specific implementation calls.

This change subclasses msm_mdss for mdp5, dpu specific
changes will be done separately.

Changes in v3:
- none

Changes in v2:
- fixed indentation for irq_domain_add_linear call (Sean Paul)

Signed-off-by: Rajesh Yadav 
Reviewed-by: Sean Paul 
---
 drivers/gpu/drm/msm/disp/mdp5/mdp5_mdss.c | 154 --
 drivers/gpu/drm/msm/msm_drv.c |  23 +++--
 drivers/gpu/drm/msm/msm_kms.h |  20 ++--
 3 files changed, 110 insertions(+), 87 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_mdss.c 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_mdss.c
index f2a0db7..1cc4e57 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_mdss.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_mdss.c
@@ -20,12 +20,10 @@
 #include "msm_drv.h"
 #include "mdp5_kms.h"
 
-/*
- * If needed, this can become more specific: something like struct mdp5_mdss,
- * which contains a 'struct msm_mdss base' member.
- */
-struct msm_mdss {
-   struct drm_device *dev;
+#define to_mdp5_mdss(x) container_of(x, struct mdp5_mdss, base)
+
+struct mdp5_mdss {
+   struct msm_mdss base;
 
void __iomem *mmio, *vbif;
 
@@ -41,22 +39,22 @@ struct msm_mdss {
} irqcontroller;
 };
 
-static inline void mdss_write(struct msm_mdss *mdss, u32 reg, u32 data)
+static inline void mdss_write(struct mdp5_mdss *mdp5_mdss, u32 reg, u32 data)
 {
-   msm_writel(data, mdss->mmio + reg);
+   msm_writel(data, mdp5_mdss->mmio + reg);
 }
 
-static inline u32 mdss_read(struct msm_mdss *mdss, u32 reg)
+static inline u32 mdss_read(struct mdp5_mdss *mdp5_mdss, u32 reg)
 {
-   return msm_readl(mdss->mmio + reg);
+   return msm_readl(mdp5_mdss->mmio + reg);
 }
 
 static irqreturn_t mdss_irq(int irq, void *arg)
 {
-   struct msm_mdss *mdss = arg;
+   struct mdp5_mdss *mdp5_mdss = arg;
u32 intr;
 
-   intr = mdss_read(mdss, REG_MDSS_HW_INTR_STATUS);
+   intr = mdss_read(mdp5_mdss, REG_MDSS_HW_INTR_STATUS);
 
VERB("intr=%08x", intr);
 
@@ -64,7 +62,7 @@ static irqreturn_t mdss_irq(int irq, void *arg)
irq_hw_number_t hwirq = fls(intr) - 1;
 
generic_handle_irq(irq_find_mapping(
-   mdss->irqcontroller.domain, hwirq));
+   mdp5_mdss->irqcontroller.domain, hwirq));
intr &= ~(1 << hwirq);
}
 
@@ -84,19 +82,19 @@ static irqreturn_t mdss_irq(int irq, void *arg)
 
 static void mdss_hw_mask_irq(struct irq_data *irqd)
 {
-   struct msm_mdss *mdss = irq_data_get_irq_chip_data(irqd);
+   struct mdp5_mdss *mdp5_mdss = irq_data_get_irq_chip_data(irqd);
 
smp_mb__before_atomic();
-   clear_bit(irqd->hwirq, >irqcontroller.enabled_mask);
+   clear_bit(irqd->hwirq, _mdss->irqcontroller.enabled_mask);
smp_mb__after_atomic();
 }
 
 static void mdss_hw_unmask_irq(struct irq_data *irqd)
 {
-   struct msm_mdss *mdss = irq_data_get_irq_chip_data(irqd);
+   struct mdp5_mdss *mdp5_mdss = irq_data_get_irq_chip_data(irqd);
 
smp_mb__before_atomic();
-   set_bit(irqd->hwirq, >irqcontroller.enabled_mask);
+   set_bit(irqd->hwirq, _mdss->irqcontroller.enabled_mask);
smp_mb__after_atomic();
 }
 
@@ -109,13 +107,13 @@ static void mdss_hw_unmask_irq(struct irq_data *irqd)
 static int mdss_hw_irqdomain_map(struct irq_domain *d, unsigned int irq,
 irq_hw_number_t hwirq)
 {
-   struct msm_mdss *mdss = d->host_data;
+   struct mdp5_mdss *mdp5_mdss = d->host_data;
 
if (!(VALID_IRQS & (1 << hwirq)))
return -EPERM;
 
irq_set_chip_and_handler(irq, _hw_irq_chip, handle_level_irq);
-   irq_set_chip_data(irq, mdss);
+   irq_set_chip_data(irq, mdp5_mdss);
 
return 0;
 }
@@ -126,90 +124,99 @@ static int mdss_hw_irqdomain_map(struct irq_domain *d, 
unsigned int irq,
 };
 
 
-static int mdss_irq_domain_init(struct msm_mdss *mdss)
+static int mdss_irq_domain_init(struct mdp5_mdss *mdp5_mdss)
 {
-   struct device *dev = mdss->dev->dev;
+   struct device *dev = mdp5_mdss->base.dev->dev;
struct irq_domain *d;
 
d = irq_domain_add_linear(dev->of_node, 32, _hw_irqdomain_ops,
- mdss);
+ mdp5_mdss);
if (!d) {
dev_err(dev, "mdss irq domain add failed\n");
return -ENXIO;
}
 
-   mdss->irqcontroller.enabled_mask = 0;
-   mdss->irqcontroller.domain = d;
+   mdp5_mdss->irqcontroller.enabled_mask = 0;
+   

[DPU PATCH v3 11/12] drm/msm/dpu: move dpu_power_handle to dpu folder

[Rajesh Yadav]

Now, since dpu_power_handle manages only bus scaling
and power enable/disable notifications which are restricted
to dpu driver, move dpu_power_handle to dpu folder.

Changes in v3:
- none

Changes in v2:
- resolved conflict in dpu_unbind
- dropped (Reviewed-by: Sean Paul) due to above change

Signed-off-by: Rajesh Yadav 
Reviewed-by: Sean Paul 
---
 drivers/gpu/drm/msm/Makefile |   2 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c |   1 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c|   5 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c |   7 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h |   2 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c  |   1 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c  |  39 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h  |   1 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c | 688 +++
 drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.h | 288 ++
 drivers/gpu/drm/msm/dpu_power_handle.c   | 688 ---
 drivers/gpu/drm/msm/dpu_power_handle.h   | 288 --
 drivers/gpu/drm/msm/msm_drv.c|   9 -
 drivers/gpu/drm/msm/msm_drv.h|   4 -
 14 files changed, 1008 insertions(+), 1015 deletions(-)
 create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c
 create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.h
 delete mode 100644 drivers/gpu/drm/msm/dpu_power_handle.c
 delete mode 100644 drivers/gpu/drm/msm/dpu_power_handle.h

diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index d9826c1..f578d5a 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -82,10 +82,10 @@ msm-y := \
disp/dpu1/dpu_rm.o \
disp/dpu1/dpu_vbif.o \
disp/dpu1/dpu_mdss.o \
+   disp/dpu1/dpu_power_handle.o \
dpu_dbg.o \
dpu_io_util.o \
dpu_dbg_evtlog.o \
-   dpu_power_handle.o \
msm_prop.o \
msm_atomic.o \
msm_debugfs.o \
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c
index 5c5cc56..33ab2ac 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c
@@ -18,7 +18,6 @@
 #include 
 
 #include "dpu_core_irq.h"
-#include "dpu_power_handle.h"
 
 /**
  * dpu_core_irq_callback_handler - dispatch core interrupts
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 2cf3fca..d3a1ed9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
@@ -257,7 +257,6 @@ static void _dpu_core_perf_crtc_update_bus(struct dpu_kms 
*kms,
= dpu_crtc_get_client_type(crtc);
struct drm_crtc *tmp_crtc;
struct dpu_crtc_state *dpu_cstate;
-   struct msm_drm_private *priv = kms->dev->dev_private;
 
drm_for_each_crtc(tmp_crtc, crtc->dev) {
if (_dpu_core_perf_crtc_is_power_on(tmp_crtc) &&
@@ -287,7 +286,7 @@ static void _dpu_core_perf_crtc_update_bus(struct dpu_kms 
*kms,
 
switch (curr_client_type) {
case NRT_CLIENT:
-   dpu_power_data_bus_set_quota(>phandle, kms->core_client,
+   dpu_power_data_bus_set_quota(>phandle, kms->core_client,
DPU_POWER_HANDLE_DATA_BUS_CLIENT_NRT,
bus_id, bus_ab_quota, bus_ib_quota);
DPU_DEBUG("client:%s bus_id=%d ab=%llu ib=%llu\n", "nrt",
@@ -295,7 +294,7 @@ static void _dpu_core_perf_crtc_update_bus(struct dpu_kms 
*kms,
break;
 
case RT_CLIENT:
-   dpu_power_data_bus_set_quota(>phandle, kms->core_client,
+   dpu_power_data_bus_set_quota(>phandle, kms->core_client,
DPU_POWER_HANDLE_DATA_BUS_CLIENT_RT,
bus_id, bus_ab_quota, bus_ib_quota);
DPU_DEBUG("client:%s bus_id=%d ab=%llu ib=%llu\n", "rt",
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index e2d2e32..99c5e75 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -598,6 +598,7 @@ static void dpu_crtc_destroy(struct drm_crtc *crtc)
_dpu_crtc_destroy_dest_scaler(dpu_crtc);
 
_dpu_crtc_deinit_events(dpu_crtc);
+   dpu_crtc->phandle = NULL;
 
drm_crtc_cleanup(crtc);
mutex_destroy(_crtc->crtc_lock);
@@ -2572,7 +2573,7 @@ static void dpu_crtc_disable(struct drm_crtc *crtc)
}
 
if (dpu_crtc->power_event)
-   dpu_power_handle_unregister_event(>phandle,
+   dpu_power_handle_unregister_event(dpu_crtc->phandle,
dpu_crtc->power_event);
 
 
@@ -2643,7 +2644,7 @@ 

[DPU PATCH v3 09/12] drm/msm/dp: remove dpu_power_handle calls from dp driver

[Rajesh Yadav]

DP driver was dependent on dpu_power_handle for MDSS
common clocks and gdsc (main power supply).
The common clocks and power is managed by MDSS top
wrapper device now which is parent of all sub-devices
like DP device.
For same reason, clock and power management code is
removed from dpu_power_handle. Hence, remove the
dpu_power_handle calls from dp driver.

Changes in v3:
- none

Changes in v2:
- none

Signed-off-by: Rajesh Yadav 
Reviewed-by: Sean Paul 
---
 drivers/gpu/drm/msm/dp/dp_power.c | 32 +---
 drivers/gpu/drm/msm/dp/dp_power.h |  4 +---
 2 files changed, 2 insertions(+), 34 deletions(-)

diff --git a/drivers/gpu/drm/msm/dp/dp_power.c 
b/drivers/gpu/drm/msm/dp/dp_power.c
index f6e341b..2a85b38 100644
--- a/drivers/gpu/drm/msm/dp/dp_power.c
+++ b/drivers/gpu/drm/msm/dp/dp_power.c
@@ -26,8 +26,6 @@ struct dp_power_private {
struct clk *pixel_parent;
 
struct dp_power dp_power;
-   struct dpu_power_client *dp_core_client;
-   struct dpu_power_handle *phandle;
 
bool core_clks_on;
bool link_clks_on;
@@ -410,8 +408,7 @@ static int dp_power_config_gpios(struct dp_power_private 
*power, bool flip,
return 0;
 }
 
-static int dp_power_client_init(struct dp_power *dp_power,
-   struct dpu_power_handle *phandle)
+static int dp_power_client_init(struct dp_power *dp_power)
 {
int rc = 0;
struct dp_power_private *power;
@@ -436,19 +433,8 @@ static int dp_power_client_init(struct dp_power *dp_power,
goto error_clk;
}
 
-   power->phandle = phandle;
-   snprintf(dp_client_name, DP_CLIENT_NAME_SIZE, "dp_core_client");
-   power->dp_core_client = dpu_power_client_create(phandle,
-   dp_client_name);
-   if (IS_ERR_OR_NULL(power->dp_core_client)) {
-   pr_err("[%s] client creation failed for DP", dp_client_name);
-   rc = -EINVAL;
-   goto error_client;
-   }
return 0;
 
-error_client:
-   dp_power_clk_init(power, false);
 error_clk:
dp_power_regulator_deinit(power);
 error_power:
@@ -466,7 +452,6 @@ static void dp_power_client_deinit(struct dp_power 
*dp_power)
 
power = container_of(dp_power, struct dp_power_private, dp_power);
 
-   dpu_power_client_destroy(power->phandle, power->dp_core_client);
dp_power_clk_init(power, false);
dp_power_regulator_deinit(power);
 }
@@ -521,13 +506,6 @@ static int dp_power_init(struct dp_power *dp_power, bool 
flip)
goto err_gpio;
}
 
-   rc = dpu_power_resource_enable(power->phandle,
-   power->dp_core_client, true);
-   if (rc) {
-   pr_err("Power resource enable failed\n");
-   goto err_dpu_power;
-   }
-
rc = dp_power_clk_enable(dp_power, DP_CORE_PM, true);
if (rc) {
pr_err("failed to enable DP core clocks\n");
@@ -537,8 +515,6 @@ static int dp_power_init(struct dp_power *dp_power, bool 
flip)
return 0;
 
 err_clk:
-   dpu_power_resource_enable(power->phandle, power->dp_core_client, false);
-err_dpu_power:
dp_power_config_gpios(power, flip, false);
 err_gpio:
dp_power_pinctrl_set(power, false);
@@ -562,12 +538,6 @@ static int dp_power_deinit(struct dp_power *dp_power)
power = container_of(dp_power, struct dp_power_private, dp_power);
 
dp_power_clk_enable(dp_power, DP_CORE_PM, false);
-   rc = dpu_power_resource_enable(power->phandle,
-   power->dp_core_client, false);
-   if (rc) {
-   pr_err("Power resource enable failed, rc=%d\n", rc);
-   goto exit;
-   }
dp_power_config_gpios(power, false, false);
dp_power_pinctrl_set(power, false);
dp_power_regulator_ctrl(power, false);
diff --git a/drivers/gpu/drm/msm/dp/dp_power.h 
b/drivers/gpu/drm/msm/dp/dp_power.h
index 84fe01d..d9dab72 100644
--- a/drivers/gpu/drm/msm/dp/dp_power.h
+++ b/drivers/gpu/drm/msm/dp/dp_power.h
@@ -16,7 +16,6 @@
 #define _DP_POWER_H_
 
 #include "dp_parser.h"
-#include "dpu_power_handle.h"
 
 /**
  * sruct dp_power - DisplayPort's power related data
@@ -32,8 +31,7 @@ struct dp_power {
int (*clk_enable)(struct dp_power *power, enum dp_pm_type pm_type,
bool enable);
int (*set_pixel_clk_parent)(struct dp_power *power);
-   int (*power_client_init)(struct dp_power *power,
-   struct dpu_power_handle *phandle);
+   int (*power_client_init)(struct dp_power *power);
void (*power_client_deinit)(struct dp_power *power);
 };
 
-- 
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

[DPU PATCH v3 08/12] drm/msm/dpu: remove power management code from dpu_power_handle

[Rajesh Yadav]

Mdss main power supply (mdss_gdsc) is implemented as a
generic power domain and mdss top level wrapper device
manage it via runtime_pm. Remove custom power management
code from dpu_power_handle.

Changes in v3:
- remove redundant param check from
  dpu_power_resource_init() (Sean Paul)

Changes in v2:
- resolved merge conflict in dpu_power_resource_init
- dropped (Reviewed-by: Sean Paul) due to above change

Signed-off-by: Rajesh Yadav 
Reviewed-by: Sean Paul 
---
 drivers/gpu/drm/msm/dpu_power_handle.c | 195 +
 drivers/gpu/drm/msm/dpu_power_handle.h |   2 -
 2 files changed, 1 insertion(+), 196 deletions(-)

diff --git a/drivers/gpu/drm/msm/dpu_power_handle.c 
b/drivers/gpu/drm/msm/dpu_power_handle.c
index 12602ae..bdf18de 100644
--- a/drivers/gpu/drm/msm/dpu_power_handle.c
+++ b/drivers/gpu/drm/msm/dpu_power_handle.c
@@ -101,150 +101,6 @@ void dpu_power_client_destroy(struct dpu_power_handle 
*phandle,
}
 }
 
-static int dpu_power_parse_dt_supply(struct platform_device *pdev,
-   struct dss_module_power *mp)
-{
-   int i = 0, rc = 0;
-   u32 tmp = 0;
-   struct device_node *of_node = NULL, *supply_root_node = NULL;
-   struct device_node *supply_node = NULL;
-
-   if (!pdev || !mp) {
-   pr_err("invalid input param pdev:%pK mp:%pK\n", pdev, mp);
-   return -EINVAL;
-   }
-
-   of_node = pdev->dev.of_node;
-
-   mp->num_vreg = 0;
-   supply_root_node = of_get_child_by_name(of_node,
-   "qcom,platform-supply-entries");
-   if (!supply_root_node) {
-   pr_debug("no supply entry present\n");
-   return rc;
-   }
-
-   for_each_child_of_node(supply_root_node, supply_node)
-   mp->num_vreg++;
-
-   if (mp->num_vreg == 0) {
-   pr_debug("no vreg\n");
-   return rc;
-   }
-
-   pr_debug("vreg found. count=%d\n", mp->num_vreg);
-   mp->vreg_config = devm_kzalloc(>dev, sizeof(struct dss_vreg) *
-   mp->num_vreg, GFP_KERNEL);
-   if (!mp->vreg_config) {
-   rc = -ENOMEM;
-   return rc;
-   }
-
-   for_each_child_of_node(supply_root_node, supply_node) {
-
-   const char *st = NULL;
-
-   rc = of_property_read_string(supply_node,
-   "qcom,supply-name", );
-   if (rc) {
-   pr_err("error reading name. rc=%d\n", rc);
-   goto error;
-   }
-
-   strlcpy(mp->vreg_config[i].vreg_name, st,
-   sizeof(mp->vreg_config[i].vreg_name));
-
-   rc = of_property_read_u32(supply_node,
-   "qcom,supply-min-voltage", );
-   if (rc) {
-   pr_err("error reading min volt. rc=%d\n", rc);
-   goto error;
-   }
-   mp->vreg_config[i].min_voltage = tmp;
-
-   rc = of_property_read_u32(supply_node,
-   "qcom,supply-max-voltage", );
-   if (rc) {
-   pr_err("error reading max volt. rc=%d\n", rc);
-   goto error;
-   }
-   mp->vreg_config[i].max_voltage = tmp;
-
-   rc = of_property_read_u32(supply_node,
-   "qcom,supply-enable-load", );
-   if (rc) {
-   pr_err("error reading enable load. rc=%d\n", rc);
-   goto error;
-   }
-   mp->vreg_config[i].enable_load = tmp;
-
-   rc = of_property_read_u32(supply_node,
-   "qcom,supply-disable-load", );
-   if (rc) {
-   pr_err("error reading disable load. rc=%d\n", rc);
-   goto error;
-   }
-   mp->vreg_config[i].disable_load = tmp;
-
-   rc = of_property_read_u32(supply_node,
-   "qcom,supply-pre-on-sleep", );
-   if (rc)
-   pr_debug("error reading supply pre sleep value. 
rc=%d\n",
-   rc);
-
-   mp->vreg_config[i].pre_on_sleep = (!rc ? tmp : 0);
-
-   rc = of_property_read_u32(supply_node,
-   "qcom,supply-pre-off-sleep", );
-   if (rc)
-   pr_debug("error reading supply pre sleep value. 
rc=%d\n",
-   rc);
-
-   mp->vreg_config[i].pre_off_sleep = (!rc ? tmp : 0);
-
-   rc = of_property_read_u32(supply_node,
-  

[DPU PATCH v3 06/12] drm/msm/dpu: use runtime_pm calls on dpu device

[Rajesh Yadav]

The dpu driver implements runtime_pm support for managing
dpu specific resources like - clocks, bus bandwidth etc.

Use pm_runtime_get/put_sync calls on dpu device.

The common clocks and power management for all child nodes
(mdp5/dpu, dsi, dp etc) is done by parent MDSS device/driver
via runtime_pm due to parent child relationship.

Changes in v3:
- none

Changes in v2:
- none

Signed-off-by: Rajesh Yadav 
Reviewed-by: Sean Paul 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c |  8 ++---
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 12 
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c  | 16 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c  | 45 +++-
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c|  6 ++--
 5 files changed, 31 insertions(+), 56 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c
index 977adc4..5c5cc56 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c
@@ -452,10 +452,10 @@ void dpu_core_irq_preinstall(struct dpu_kms *dpu_kms)
}
priv = dpu_kms->dev->dev_private;
 
-   dpu_power_resource_enable(>phandle, dpu_kms->core_client, true);
+   pm_runtime_get_sync(_kms->pdev->dev);
dpu_clear_all_irqs(dpu_kms);
dpu_disable_all_irqs(dpu_kms);
-   dpu_power_resource_enable(>phandle, dpu_kms->core_client, false);
+   pm_runtime_put_sync(_kms->pdev->dev);
 
spin_lock_init(_kms->irq_obj.cb_lock);
 
@@ -496,7 +496,7 @@ void dpu_core_irq_uninstall(struct dpu_kms *dpu_kms)
}
priv = dpu_kms->dev->dev_private;
 
-   dpu_power_resource_enable(>phandle, dpu_kms->core_client, true);
+   pm_runtime_get_sync(_kms->pdev->dev);
for (i = 0; i < dpu_kms->irq_obj.total_irqs; i++)
if (atomic_read(_kms->irq_obj.enable_counts[i]) ||
!list_empty(_kms->irq_obj.irq_cb_tbl[i]))
@@ -504,7 +504,7 @@ void dpu_core_irq_uninstall(struct dpu_kms *dpu_kms)
 
dpu_clear_all_irqs(dpu_kms);
dpu_disable_all_irqs(dpu_kms);
-   dpu_power_resource_enable(>phandle, dpu_kms->core_client, false);
+   pm_runtime_put_sync(_kms->pdev->dev);
 
kfree(dpu_kms->irq_obj.irq_cb_tbl);
kfree(dpu_kms->irq_obj.enable_counts);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 48920b05..e2d2e32 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -86,8 +86,12 @@ static inline int _dpu_crtc_power_enable(struct dpu_crtc 
*dpu_crtc, bool enable)
 
dpu_kms = to_dpu_kms(priv->kms);
 
-   return dpu_power_resource_enable(>phandle, dpu_kms->core_client,
-   enable);
+   if (enable)
+   pm_runtime_get_sync(_kms->pdev->dev);
+   else
+   pm_runtime_put_sync(_kms->pdev->dev);
+
+   return 0;
 }
 
 /**
@@ -2250,7 +2254,6 @@ static int _dpu_crtc_vblank_enable_no_lock(
 
/* drop lock since power crtc cb may try to re-acquire lock */
mutex_unlock(_crtc->crtc_lock);
-   pm_runtime_get_sync(dev->dev);
ret = _dpu_crtc_power_enable(dpu_crtc, true);
mutex_lock(_crtc->crtc_lock);
if (ret)
@@ -2580,7 +2583,6 @@ static void dpu_crtc_disable(struct drm_crtc *crtc)
/* disable clk & bw control until clk & bw properties are set */
cstate->bw_control = false;
cstate->bw_split_vote = false;
-   pm_runtime_put_sync(crtc->dev->dev);
 
mutex_unlock(_crtc->crtc_lock);
 }
@@ -2611,8 +2613,6 @@ static void dpu_crtc_enable(struct drm_crtc *crtc,
return;
}
 
-   pm_runtime_get_sync(crtc->dev->dev);
-
drm_for_each_encoder(encoder, crtc->dev) {
if (encoder->crtc != crtc)
continue;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 4386360..298a6ef 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -268,8 +268,12 @@ static inline int _dpu_encoder_power_enable(struct 
dpu_encoder_virt *dpu_enc,
 
dpu_kms = to_dpu_kms(priv->kms);
 
-   return dpu_power_resource_enable(>phandle, dpu_kms->core_client,
-   enable);
+   if (enable)
+   pm_runtime_get_sync(_kms->pdev->dev);
+   else
+   pm_runtime_put_sync(_kms->pdev->dev);
+
+   return 0;
 }
 
 void dpu_encoder_helper_report_irq_timeout(struct dpu_encoder_phys *phys_enc,
@@ -796,10 +800,8 @@ static void _dpu_encoder_resource_control_helper(struct 
drm_encoder *drm_enc,
}
 
if (enable) {
- 

[DPU PATCH v3 05/12] drm/msm/dpu: update dpu sub-block offsets wrt dpu base address

[Rajesh Yadav]

The dpu sub-block offsets were defined wrt mdss base address
instead of dpu base address.
Since, dpu is now defined as a separate device, update hw catalog
offsets for all dpu sub blocks wrt dpu base address.

Changes in v3:
- none

Changes in v2:
- none

Signed-off-by: Rajesh Yadav 
Reviewed-by: Sean Paul 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 68 +++
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 18 +++---
 2 files changed, 43 insertions(+), 43 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index c5b370f..2fd3254 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -80,7 +80,7 @@
 static struct dpu_mdp_cfg sdm845_mdp[] = {
{
.name = "top_0", .id = MDP_TOP,
-   .base = 0x1000, .len = 0x45C,
+   .base = 0x0, .len = 0x45C,
.features = 0,
.highest_bank_bit = 0x2,
.has_dest_scaler = true,
@@ -111,27 +111,27 @@
 static struct dpu_ctl_cfg sdm845_ctl[] = {
{
.name = "ctl_0", .id = CTL_0,
-   .base = 0x2000, .len = 0xE4,
+   .base = 0x1000, .len = 0xE4,
.features = BIT(DPU_CTL_SPLIT_DISPLAY)
},
{
.name = "ctl_1", .id = CTL_1,
-   .base = 0x2200, .len = 0xE4,
+   .base = 0x1200, .len = 0xE4,
.features = BIT(DPU_CTL_SPLIT_DISPLAY)
},
{
.name = "ctl_2", .id = CTL_2,
-   .base = 0x2400, .len = 0xE4,
+   .base = 0x1400, .len = 0xE4,
.features = 0
},
{
.name = "ctl_3", .id = CTL_3,
-   .base = 0x2600, .len = 0xE4,
+   .base = 0x1600, .len = 0xE4,
.features = 0
},
{
.name = "ctl_4", .id = CTL_4,
-   .base = 0x2800, .len = 0xE4,
+   .base = 0x1800, .len = 0xE4,
.features = 0
},
 };
@@ -211,21 +211,21 @@
}
 
 static struct dpu_sspp_cfg sdm845_sspp[] = {
-   SSPP_VIG_BLK("sspp_0", SSPP_VIG0, 0x5000,
+   SSPP_VIG_BLK("sspp_0", SSPP_VIG0, 0x4000,
sdm845_vig_sblk_0, 0, DPU_CLK_CTRL_VIG0),
-   SSPP_VIG_BLK("sspp_1", SSPP_VIG1, 0x7000,
+   SSPP_VIG_BLK("sspp_1", SSPP_VIG1, 0x6000,
sdm845_vig_sblk_1, 4, DPU_CLK_CTRL_VIG1),
-   SSPP_VIG_BLK("sspp_2", SSPP_VIG2, 0x9000,
+   SSPP_VIG_BLK("sspp_2", SSPP_VIG2, 0x8000,
sdm845_vig_sblk_2, 8, DPU_CLK_CTRL_VIG2),
-   SSPP_VIG_BLK("sspp_3", SSPP_VIG3, 0xb000,
+   SSPP_VIG_BLK("sspp_3", SSPP_VIG3, 0xa000,
sdm845_vig_sblk_3, 12, DPU_CLK_CTRL_VIG3),
-   SSPP_DMA_BLK("sspp_8", SSPP_DMA0, 0x25000,
+   SSPP_DMA_BLK("sspp_8", SSPP_DMA0, 0x24000,
sdm845_dma_sblk_0, 1, DPU_CLK_CTRL_DMA0),
-   SSPP_DMA_BLK("sspp_9", SSPP_DMA1, 0x27000,
+   SSPP_DMA_BLK("sspp_9", SSPP_DMA1, 0x26000,
sdm845_dma_sblk_1, 5, DPU_CLK_CTRL_DMA1),
-   SSPP_DMA_BLK("sspp_10", SSPP_DMA2, 0x29000,
+   SSPP_DMA_BLK("sspp_10", SSPP_DMA2, 0x28000,
sdm845_dma_sblk_2, 9, DPU_CLK_CTRL_CURSOR0),
-   SSPP_DMA_BLK("sspp_11", SSPP_DMA3, 0x2b000,
+   SSPP_DMA_BLK("sspp_11", SSPP_DMA3, 0x2a000,
sdm845_dma_sblk_3, 13, DPU_CLK_CTRL_CURSOR1),
 };
 
@@ -252,17 +252,17 @@
.lm_pair_mask = (1 << _lmpair) \
}
 static struct dpu_lm_cfg sdm845_lm[] = {
-   LM_BLK("lm_0", LM_0, 0x45000, DSPP_0,
+   LM_BLK("lm_0", LM_0, 0x44000, DSPP_0,
DS_0, PINGPONG_0, LM_1),
-   LM_BLK("lm_1", LM_1, 0x46000, DSPP_1,
+   LM_BLK("lm_1", LM_1, 0x45000, DSPP_1,
DS_1, PINGPONG_1, LM_0),
-   LM_BLK("lm_2", LM_2, 0x47000, DSPP_2,
+   LM_BLK("lm_2", LM_2, 0x46000, DSPP_2,
DS_MAX, PINGPONG_2, LM_5),
LM_BLK("lm_3", LM_3, 0x0, DSPP_MAX,
DS_MAX, PINGPONG_MAX, 0),
LM_BLK("lm_4", LM_4, 0x0, DSPP_MAX,
DS_MAX, PINGPONG_MAX, 0),
-   LM_BLK("lm_5", LM_5, 0x4a000, DSPP_3,
+   LM_BLK("lm_5", LM_5, 0x49000, DSPP_3,
DS_MAX, PINGPONG_3, LM_2),
 };
 
@@ -270,7 +270,7 @@
  * DSPP sub blocks config
  */
 static struct dpu_dspp_top_cfg sdm845_dspp_top = {
-   .name = "dspp_top", .base = 0x1300, .len = 0xc
+   .name = "dspp_top", .base = 0x300, .len = 0xc
 };
 
 static const struct dpu_dspp_sub_blks sdm845_dspp_sblk = {
@@ -304,10 +304,10 @@
}
 
 static struct dpu_dspp_cfg sdm845_dspp[] = {
-   DSPP_BLK("dspp_0", DSPP_0, 0x55000),
-   DSPP_BLK("dspp_1", DSPP_1, 0x57000),
-   DSPP_BLK("dspp_2", DSPP_2, 0x59000),
-   DSPP_BLK("dspp_3", DSPP_3, 0x5b000),
+   DSPP_BLK("dspp_0", DSPP_0, 0x54000),
+   DSPP_BLK("dspp_1", DSPP_1, 0x56000),
+   DSPP_BLK("dspp_2", DSPP_2, 0x58000),
+   DSPP_BLK("dspp_3", DSPP_3, 0x5a000),
 };
 
 

[DPU PATCH v3 01/12] drm/msm: remove redundant pm_runtime_enable call from msm_drv

[Rajesh Yadav]

MDSS top level device includes the common power resources
and it's corresponding driver (i.e. mdp5_mdss) handles call
to enable/disable runtime_pm for enabling these resources.
Remove redundant pm_runtime_enable call from msm_drv.

Changes in v3:
- none

Changes in v2:
- none

Signed-off-by: Rajesh Yadav 
Reviewed-by: Sean Paul 
---
 drivers/gpu/drm/msm/msm_drv.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index ebc40a9..9bb436f 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -581,7 +581,6 @@ static int msm_drm_init(struct device *dev, struct 
drm_driver *drv)
goto fail;
}
priv->kms = kms;
-   pm_runtime_enable(dev);
 
/**
 * Since kms->funcs->hw_init(kms) might call
-- 
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 v3 00/12] Refactor DPU device/driver hierarchy and add runtime_pm support

[Rajesh Yadav]

SoCs containing mdp5 or dpu have a MDSS top level wrapper which includes
sub-blocks as mdp5/dpu, dsi, dp, hdmi etc. The MDSS top level wrapper
manages common resources like common clocks, main power supply and
interrupts for its sub-blocks.

But current dpu driver implementation is based on a flat device hierarchy
where MDSS/DPU HW blocks were represented by single device and DSI/DP etc.
are represented as independent devices w/o any relationships b/t these
nodes which doesn't model the HW associations precisely.

A minimal MDSS and DPU controller device separation is done in following
patch series [1] but currently both these devices match to a single driver
which is getting probed two times and all the resources are still tied to
DPU device.

Moreover, all the power resource management in DPU driver is part of
power_handle module which manages these resources via a custom
implementation.

Irq domain handling is part of DPU device, due to lack of a dedicated
driver for MDSS top level wrapper device.

This patch series aims at adding separate drivers for MDSS top level
wrapper device and DPU child device. MDP5 device/driver is used as a
reference for this refactoring effort. Both the drivers implement
runtime_pm support for their power resource management. Child nodes can
control common resources managed by parent device due to parent child
relationship defined in dt. The top level MDSS device acts as an
interrupt controller and manages hwirq mappings for its child devices. 

Inorder to add MDP5 and DPU specific MDSS driver implementation, this patch
series also subclasses existing msm_mdss define. A helper interface
(msm_mdss_funcs) is added to invoke the platform specific implementations.

This change also corrects hw catalog offsets for all sub blocks present
within DPU device. The offset are now defined wrt DPU base address
(instead of using MDSS base address).

Clock and Power handling code have been removed from dpu_power_handle since
each device manages it's resources via runtime_pm. Now, since
dpu_power_handle manages only bus scaling and power enable/disable
notifications and it's usage is restricted to DPU driver only, moved
dpu_power_handle code to DPU folder.

The dt bindings update patch will be sent subsequently.

This patch series depends on [1].

1 - https://lists.freedesktop.org/archives/freedreno/2018-April/002354.html

Changes in v3:
- use "clock-frequency" dt-binding instead of "clock-rate",
  is it an optional binding (Sean Paul)
- remove handling of "clock-max-rate" proprietary
  dt-binding (Sean Paul)
- remove intermediate storing of msm_ioremap() retcode
  on failure instead return retcode directly (Sean Paul)
- remove redundant param check from
  dpu_power_resource_init() (Sean Paul)
- msm_ioremap() prints error log in case of failure,
  so remove additional log from it's caller
- updated max core clock rate

Changes in v2:
- fix indentation issues in dpu_mdss (Sean Paul)
- merge tiny static functions (like _dpu_mdss_hw_rev_init()
  and _dpu_mdss_get_intr_sources()) in caller functions (Sean Paul)
- remove unnecessary goto statements from dpu_mdss_irq (Sean Paul)
- remove redundant input param checks from dpu_mdss
  and dpu_kms (Sean Paul/Jordan Crouse)
- return error code from dpu_mdss_enable/disable (Sean Paul/Jordan 
Crouse)
- remove explicit calls to devm_kfree (Sean Paul/Jordan Crouse)
- remove compatibility check from dpu_mdss_init as
  it is conditionally called from msm_drv (Sean Paul)
- reworked msm_dss_parse_clock() to add return checks for
  of_property_read_* calls, fix log message and
  fix alignment issues (Sean Paul/Jordan Crouse)
- remove redundant param checks from __intr_offset and
  make it a void function to avoid unnecessary error
  handling from caller (Jordan Crouse)
- use %pK for kernel pointers (Jordan Crouse)
- don't export msm_dss_parse_clock since it is used
  only by dpu driver (Jordan Crouse)
- merge dpu_init into dpu_bind and dpu_destroy into dpu_unbind (Sean 
Paul)
- remove explicit devm allocation failure message (Jordan Crouse)
- remove local variable to hold and return error code
  in _dpu_core_perf_set_core_clk_rate() instead return
  retcode directly from msm_dss_clk_set_rate() call (Sean Paul)
- return >clk_config[i] directly to avoid local variable
  in _dpu_kms_get_clk() (Sean Paul)
- invert conditional check to eliminate local rate variable
  from dpu_kms_get_clk_rate() (Sean Paul)
- remove end label from dpu_power_resource_init() and return
  directly on dpu_power_parse_dt_supply() failure as no cleanup
  is needed (Sean Paul)
- remove checks for vtotal and vrefresh from
  

Re: [PATCH v3 4/4] drm/rockchip: support dp training outside dp firmware

[Sean Paul]

On Mon, May 14, 2018 at 05:53:55PM +0800, Lin Huang wrote:
> DP firmware uses fixed phy config values to do training, but some
> boards need to adjust these values to fit for their unique hardware
> design. So if the phy is using custom config values, do software
> link training instead of relying on firmware, if software training
> fail, keep firmware training as a fallback if sw training fails.
> 
> Signed-off-by: Chris Zhong 
> Signed-off-by: Lin Huang 
> ---
> Changes in v2:
> - update patch following Enric suggest
> Changes in v3:
> - use variable fw_training instead sw_training_success
> - base on DP SPCE, if training fail use lower link rate to retry training
> 
>  drivers/gpu/drm/rockchip/Makefile   |   3 +-
>  drivers/gpu/drm/rockchip/cdn-dp-core.c  |  24 +-
>  drivers/gpu/drm/rockchip/cdn-dp-core.h  |   2 +
>  drivers/gpu/drm/rockchip/cdn-dp-link-training.c | 416 
> 
>  drivers/gpu/drm/rockchip/cdn-dp-reg.c   |  31 +-
>  drivers/gpu/drm/rockchip/cdn-dp-reg.h   |  38 ++-
>  6 files changed, 501 insertions(+), 13 deletions(-)
>  create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-link-training.c
> 
> diff --git a/drivers/gpu/drm/rockchip/Makefile 
> b/drivers/gpu/drm/rockchip/Makefile
> index a314e21..b932f62 100644
> --- a/drivers/gpu/drm/rockchip/Makefile
> +++ b/drivers/gpu/drm/rockchip/Makefile
> @@ -9,7 +9,8 @@ rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o \
>  rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o
>  
>  rockchipdrm-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
> -rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o
> +rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o \
> + cdn-dp-link-training.o
>  rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
>  rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
>  rockchipdrm-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c 
> b/drivers/gpu/drm/rockchip/cdn-dp-core.c
> index cce64c1..d9d0d4d 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
> @@ -629,11 +629,13 @@ static void cdn_dp_encoder_enable(struct drm_encoder 
> *encoder)
>   goto out;
>   }
>   }
> -
> - ret = cdn_dp_set_video_status(dp, CONTROL_VIDEO_IDLE);
> - if (ret) {
> - DRM_DEV_ERROR(dp->dev, "Failed to idle video %d\n", ret);
> - goto out;
> + if (dp->use_fw_training == true) {
> + ret = cdn_dp_set_video_status(dp, CONTROL_VIDEO_IDLE);
> + if (ret) {
> + DRM_DEV_ERROR(dp->dev,
> +   "Failed to idle video %d\n", ret);
> + goto out;
> + }
>   }
>  
>   ret = cdn_dp_config_video(dp);
> @@ -642,11 +644,15 @@ static void cdn_dp_encoder_enable(struct drm_encoder 
> *encoder)
>   goto out;
>   }
>  
> - ret = cdn_dp_set_video_status(dp, CONTROL_VIDEO_VALID);
> - if (ret) {
> - DRM_DEV_ERROR(dp->dev, "Failed to valid video %d\n", ret);
> - goto out;
> + if (dp->use_fw_training == true) {
> + ret = cdn_dp_set_video_status(dp, CONTROL_VIDEO_VALID);
> + if (ret) {
> + DRM_DEV_ERROR(dp->dev,
> + "Failed to valid video %d\n", ret);
> + goto out;
> + }
>   }
> +
>  out:
>   mutex_unlock(>lock);
>  }
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.h 
> b/drivers/gpu/drm/rockchip/cdn-dp-core.h
> index 46159b2..77a9793 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-core.h
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.h
> @@ -84,6 +84,7 @@ struct cdn_dp_device {
>   bool connected;
>   bool active;
>   bool suspended;
> + bool use_fw_training;
>  
>   const struct firmware *fw;  /* cdn dp firmware */
>   unsigned int fw_version;/* cdn fw version */
> @@ -106,6 +107,7 @@ struct cdn_dp_device {
>   u8 ports;
>   u8 lanes;
>   int active_port;
> + u8 train_set[4];
>  
>   u8 dpcd[DP_RECEIVER_CAP_SIZE];
>   bool sink_has_audio;
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-link-training.c 
> b/drivers/gpu/drm/rockchip/cdn-dp-link-training.c
> new file mode 100644
> index 000..b8fd5bc
> --- /dev/null
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-link-training.c

/snip

> +static int cdn_dp_get_lower_link_rate(struct cdn_dp_device *dp)
> +{
> + if (dp->link.rate == DP_LINK_BW_1_62)
> + return -EINVAL;
> + else if (dp->link.rate == DP_LINK_BW_2_7)
> + dp->link.rate = DP_LINK_BW_1_62;

Extra indent

> + else
> + dp->link.rate = DP_LINK_BW_2_7;


This is better expressed as a switch statement:


switch 

Re: drm SPDX updates

[Thomas Hellstrom]

On 05/14/2018 04:54 PM, Dirk Hohndel wrote:

On Mon, May 14, 2018 at 07:59:56AM +0200, Thomas Gleixner wrote:

Dirk,

On Mon, 7 May 2018, Dirk Hohndel (VMware) wrote:


License clarifications and SPDX headers for a bunch of files which were
authored by VMware.

This should address the comments made on the previous series.
I added Thomas as Cc (sorry, forgot on the first version) and added a
couple of SOBs that I had received in the meantime.

Thanks for cleaning that up.

FWIW: Acked-by: Thomas Gleixner 

I haven't seen any comments in the week since I wrote this. I'm not
familiar with the process for the drm changes - so what are the usual next
steps? Do I need to submit all or part of this somewhere else? Or does
Dave simply take the series (since it has no executable code changes at
all)?

/D


There are a number of teams sending pull requests to Dave. One option 
would be to have it all go through the drm-misc tree. (CC'ing Daniel 
Vetter about that). Another option would perhaps be to send a pull 
request directly to Dave (Dave?) And finally, one option would be to 
rely on the maintainers of each submodule to take the patches that touch 
that module. If you go for this last option, I can surely take the 
patches that touch vmwgfx, and Christian the TTM patches.


/Thomas


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

Re: [PATCH v3 3/4] phy: rockchip-typec: support variable phy config value

[Sean Paul]

On Mon, May 14, 2018 at 05:53:54PM +0800, Lin Huang wrote:
> the phy config values used to fix in dp firmware, but some boards
> need change these values to do training and get the better eye diagram
> result. So support that in phy driver.
> 
> Signed-off-by: Chris Zhong 
> Signed-off-by: Lin Huang 
> ---
> Changes in v2:
> - update patch following Enric suggest
> Changes in v3:
> - delete need_software_training variable
> - add default phy config value, if dts do not define phy config value, use 
> these value
> 
>  drivers/phy/rockchip/phy-rockchip-typec.c | 305 
> --
>  include/soc/rockchip/rockchip_phy_typec.h |  63 ++
>  2 files changed, 270 insertions(+), 98 deletions(-)
>  create mode 100644 include/soc/rockchip/rockchip_phy_typec.h
> 
> diff --git a/drivers/phy/rockchip/phy-rockchip-typec.c 
> b/drivers/phy/rockchip/phy-rockchip-typec.c
> index 76a4b58..10253ad 100644
> --- a/drivers/phy/rockchip/phy-rockchip-typec.c
> +++ b/drivers/phy/rockchip/phy-rockchip-typec.c

/snip

>  
> +/* default phy config */
> +struct phy_config configs[3][4] = {

static const

Also, configs isn't a good name. How about tcphy_default_config?


> + {{ 0x2a, 0x00 },

Can you please expand the assignment for all of these, ie:

 { .swing = 0x2a, .pe = 0x00 },

> +  { 0x1f, 0x15 },
> +  { 0x14, 0x22 },
> +  { 0x02, 0x2b } },
> +
> + {{ 0x21, 0x00 },
> +  { 0x12, 0x15 },
> +  { 0x02, 0x22 },
> +  {0,0 } },
> +
> + {{ 0x15, 0x00 },
> +  { 0x00, 0x15 },
> +  {0,0 },
> +  {0,0 } },
> +};
> +

/snip

-- 
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 106513] AMDGPU not working on ubuntu 18.04

[bugzilla-daemon]

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

Alex Deucher  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #1 from Alex Deucher  ---


*** This bug has been marked as a duplicate of bug 105760 ***

-- 
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 105760] [4.17-rc1] RIP: smu7_populate_single_firmware_entry.isra.6+0x57/0xc0 [amdgpu] RSP: ffffa17901efb930

[bugzilla-daemon]

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

Alex Deucher  changed:

   What|Removed |Added

 CC||mathieu.dut...@gmail.com

--- Comment #9 from Alex Deucher  ---
*** Bug 106513 has been marked as a duplicate of this bug. ***

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

[Bug 106513] AMDGPU not working on ubuntu 18.04

[bugzilla-daemon]

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

Bug ID: 106513
   Summary: AMDGPU not working on ubuntu 18.04
   Product: DRI
   Version: XOrg git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: mathieu.dut...@gmail.com

Created attachment 139556
  --> https://bugs.freedesktop.org/attachment.cgi?id=139556=edit
the dmesg output

WHAT HAPPENS
- Amdgpu refuses to start without any information as of why.
- The problem happened between Ubuntu 17.10 and Ubuntu 18.04
- Three behaviors are occurring:
  a) The login happens normally (very rare, only 2 times)
  b) The login fails, the screen remain stuck and nothing happens
  c) The login fails and I am sent back to the login screen
- The mouse cursor does not respond to movements.
- I can access to the console via Ctrl+Alt F4
- The "dmesg" output is in attachment. The smoking gun in my opinion is
[  170.244044] [drm:atom_op_jump [amdgpu]] *ERROR* atombios stuck in loop for
more than 5secs aborting

TIPS
- I can access to login screen and to all the data on the computer. But only in
text mode. So I can update 

The crashes that allows ssh connection almost always happens when firefox is
openned and running a video (netflix, youtube) or whatsapp web.
- The crashes that simply hangs the entire computer may occur at any time.

OBSERVATIONS
- No modification were done to the driver, only standard driver from ubuntu
18.04.

SYSTEM SPECS
- Dell Inspiron 5767 is used. Kernel from Ubuntu

-- 
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: [DPU PATCH v2 03/12] drm/msm/dpu: add MDSS top level driver for dpu

[ryadav]

On 2018-05-11 20:58, Sean Paul wrote:

On Fri, May 11, 2018 at 08:19:29PM +0530, Rajesh Yadav wrote:

SoCs containing dpu have a MDSS top level wrapper
which includes sub-blocks as dpu, dsi, phy, dp etc.
MDSS top level wrapper manages common resources like
common clocks, power and irq for its sub-blocks.

Currently, in dpu driver, all the power resource
management is part of power_handle which manages
these resources via a custom implementation. And
the resource relationships are not modelled properly
in dt.  Moreover the irq domain handling code is part
of dpu device (which is a child device) due to lack
of a dedicated driver for MDSS top level wrapper
device.

This change adds dpu_mdss top level driver to handle
common clock like - core clock, ahb clock
(for register access), main power supply (i.e. gdsc)
and irq management.
The top level mdss device/driver acts as an interrupt
controller and manage hwirq mapping for its child
devices.

It implements runtime_pm support for resource management.
Child nodes can control these resources via runtime_pm
get/put calls on their corresponding devices due to parent
child relationship defined in dt.

Changes in v2:
- merge _dpu_mdss_hw_rev_init to dpu_mdss_init (Sean Paul)
- merge _dpu_mdss_get_intr_sources to dpu_mdss_irq (Sean Paul)
- fix indentation for irq_find_mapping call (Sean Paul)
- remove unnecessary goto statements from dpu_mdss_irq (Sean Paul)
- remove redundant param checks from
  dpu_mdss_irq_mask/unmask (Sean Paul/Jordan Crouse)
- remove redundant param checks from
  dpu_mdss_irqdomain_map (Sean Paul/Jordan Crouse)
	- return error code from dpu_mdss_enable/disable (Sean Paul/Jordan 
Crouse)

- remove redundant param check from dpu_mdss_destroy (Sean Paul)
- remove explicit calls to devm_kfree (Sean Paul/Jordan Crouse)
- remove compatibility check from dpu_mdss_init as
  it is conditionally called from msm_drv (Sean Paul)
- reworked msm_dss_parse_clock() to add return checks for
  of_property_read_* calls, fix log message and
  fix alignment issues (Sean Paul/Jordan Crouse)
- remove extra line before dpu_mdss_init (Sean Paul)
- remove redundant param checks from __intr_offset and
  make it a void function to avoid unnecessary error
  handling from caller (Jordan Crouse)
- remove redundant param check from dpu_mdss_irq (Jordan Crouse)
- change mdss address space log message to debug and use %pK for
  kernel pointers (Jordan Crouse)
	- remove unnecessary log message from msm_dss_parse_clock (Jordan 
Crouse)

- don't export msm_dss_parse_clock since it is used
  only by dpu driver (Jordan Crouse)

Signed-off-by: Rajesh Yadav 
---
 drivers/gpu/drm/msm/Makefile  |   1 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c  |  97 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.h  |  14 --
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c|   9 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h|   7 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c |  28 +--
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h |  11 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_irq.c   |  48 +---
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c   |   6 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h   |   2 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c  | 254 
++

 drivers/gpu/drm/msm/dpu_io_util.c |  57 +
 drivers/gpu/drm/msm/msm_drv.c |  26 ++-
 drivers/gpu/drm/msm/msm_drv.h |   2 +-
 drivers/gpu/drm/msm/msm_kms.h |   1 +
 include/linux/dpu_io_util.h   |   2 +
 16 files changed, 339 insertions(+), 226 deletions(-)
 create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c



/snip

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c

new file mode 100644
index 000..ce680ea
--- /dev/null
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c


/snip


+
+int dpu_mdss_init(struct drm_device *dev)
+{
+   struct platform_device *pdev = to_platform_device(dev->dev);
+   struct msm_drm_private *priv = dev->dev_private;
+   struct dpu_mdss *dpu_mdss;
+   struct dss_module_power *mp;
+   int ret = 0;
+
+   dpu_mdss = devm_kzalloc(dev->dev, sizeof(*dpu_mdss), GFP_KERNEL);
+   if (!dpu_mdss)
+   return -ENOMEM;
+
+   dpu_mdss->mmio = msm_ioremap(pdev, "mdss_phys", "mdss_phys");
+   if (IS_ERR(dpu_mdss->mmio)) {
+   ret = PTR_ERR(dpu_mdss->mmio);


remove this ...


+   DPU_ERROR("mdss register memory map failed: %d\n", ret);
+   dpu_mdss->mmio = NULL;
+   return ret;


... and replace with
return PTR_ERR(dpu_mdss->mmio);


Sure, I'll update in v3.


+   }

Re: [PATCH 0/3] fbdev/drm: sh_mobile: remove unused MERAM support

[Bartlomiej Zolnierkiewicz]

On Friday, April 27, 2018 02:09:31 PM Daniel Vetter wrote:
> On Fri, Apr 27, 2018 at 1:36 PM, Laurent Pinchart
>  wrote:
> > Hi Bartlomiej,
> >
> > On Friday, 27 April 2018 14:21:42 EEST Bartlomiej Zolnierkiewicz wrote:
> >> Hi,
> >>
> >> This patchset removes unused MERAM support (last user was removed
> >> 3 years ago) from shmobile fbdev & drm drivers and then removes
> >> MERAM driver itself.
> >>
> >> If it is okay to merge this patches I would like patch #1 to go
> >> through fbdev tree and patch #2 to go through drm tree. Once they
> >> are both upstream (v4.18) I will apply patch #3 to fbdev tree.
> >
> > Or you could merge everything through the fbdev tree in one go, the shmobile
> > driver hardly sees any activity these days.
> >
> > For the whole series,
> >
> > Acked-by: Laurent Pinchart 
> 
> Yeah merging all through fbdev is probably simplest, shmobile is not a
> driver that's actively changed a lot. Ack from me too.

Thanks, I've applied all patches to fbdev-for-next.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

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

Re: [PATCH] video: fbdev: remove unused auo_k190xfb drivers

[Bartlomiej Zolnierkiewicz]

On Friday, April 27, 2018 05:07:41 PM Heiko Stuebner wrote:
> Am Freitag, 27. April 2018, 13:04:24 CEST schrieb Bartlomiej Zolnierkiewicz:
> > auo_k1900fb and auo_k1901fb drivers have been introduced six
> > years ago by following commits:
> > 
> > commit 2c8304d3125b ("video: auo_k190x: add code shared by controller 
> > drivers")
> > commit 96b1d500e028 ("video: auo_k190x: add driver for AUO-K1900 variant")
> > commit 53027cdf2a67 ("video: auo_k190x: add driver for AUO-K1901 variant")
> > 
> > They never had any in-kernel user so just remove them (since
> > they are platform drivers they need corresponding platform
> > devices to be registered by kernel and it has never happened).
> > 
> > Cc: Heiko Stübner 
> > Signed-off-by: Bartlomiej Zolnierkiewicz 
> 
> While I still hold the ereaders using these controllers in high regard
> as my first kernel hacking project, reality is that I don't think I'll
> ever continue on trying to mainline these and if later someone wants
> to resurrect these (very old now) devices, they'll probably need a drm-
> driver anyway. So for the removal
> 
> Reviewed-by: Heiko Stuebner 

Thanks, I've queued the patch for v4.18.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

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

Re: [PATCH] drm/vc4: plane: Expand the lower bits using the LSB

[Stefan Schake]

On Tue, Apr 24, 2018 at 9:48 AM, Maxime Ripard
 wrote:
> The vc4 HVS uses an internal RGB888 representation of the frames, and will
> by default expand formats using a lower depth using zeros.
>
> This causes an issue when we try to use other compositing software such as
> pixman that seems to be filling the missing bits using the format least
> significant bit value. As such, this prevents us from checking the display
> output in a reliable way.
>
> To prevent this, force the same behaviour so that we can do such things.
>
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/gpu/drm/vc4/vc4_plane.c | 1 +
>  drivers/gpu/drm/vc4/vc4_regs.h  | 8 
>  2 files changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
> index ce39390be389..8dd33c6e9fd8 100644
> --- a/drivers/gpu/drm/vc4/vc4_plane.c
> +++ b/drivers/gpu/drm/vc4/vc4_plane.c
> @@ -542,6 +542,7 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
> /* Control word */
> vc4_dlist_write(vc4_state,
> SCALER_CTL0_VALID |
> +   VC4_SET_FIELD(SCALER_CTL0_EXPAND_LSB, 
> SCALER_CTL0_EXPAND) |
> (format->pixel_order << SCALER_CTL0_ORDER_SHIFT) |
> (format->hvs << SCALER_CTL0_PIXEL_FORMAT_SHIFT) |
> VC4_SET_FIELD(tiling, SCALER_CTL0_TILING) |
> diff --git a/drivers/gpu/drm/vc4/vc4_regs.h b/drivers/gpu/drm/vc4/vc4_regs.h
> index a141496104a6..7c28e6207ec2 100644
> --- a/drivers/gpu/drm/vc4/vc4_regs.h
> +++ b/drivers/gpu/drm/vc4/vc4_regs.h
> @@ -806,12 +806,20 @@ enum hvs_pixel_format {
>  #define SCALER_CTL0_ORDER_MASK VC4_MASK(14, 13)
>  #define SCALER_CTL0_ORDER_SHIFT13
>
> +#define SCALER_CTL0_EXPAND_MASKVC4_MASK(12, 11)
> +#define SCALER_CTL0_EXPAND_SHIFT   11
> +
>  #define SCALER_CTL0_SCL1_MASK  VC4_MASK(10, 8)
>  #define SCALER_CTL0_SCL1_SHIFT 8
>
>  #define SCALER_CTL0_SCL0_MASK  VC4_MASK(7, 5)
>  #define SCALER_CTL0_SCL0_SHIFT 5
>
> +#define SCALER_CTL0_EXPAND_ZERO0
> +#define SCALER_CTL0_EXPAND_LSB 1
> +#define SCALER_CTL0_EXPAND_MSB 2
> +#define SCALER_CTL0_EXPAND_REPEAT  3

Just a heads up, those defines have recently landed in drm-misc, with
slightly different naming: SCALER_CTL0_RGBA_EXPAND_*

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

Re: [PATCH v2 09/11] docs: Fix some broken references

[Masami Hiramatsu]

On Wed,  9 May 2018 10:18:52 -0300
Mauro Carvalho Chehab  wrote:

> As we move stuff around, some doc references are broken. Fix some of
> them via this script:
>   ./scripts/documentation-file-ref-check --fix-rst
> 
> Manually checked if the produced result is valid, removing a few
> false-positives.

The part of kprobes and trace_kprobe changes look good to me :)

Acked-by: Masami Hiramatsu 

Thank you,

> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  .../admin-guide/kernel-parameters.txt |  4 ++--
>  .../bindings/input/rotary-encoder.txt |  2 +-
>  Documentation/driver-api/gpio/consumer.rst|  2 +-
>  Documentation/kprobes.txt |  4 ++--
>  Documentation/trace/coresight.txt |  2 +-
>  Documentation/trace/events.rst|  2 +-
>  Documentation/trace/ftrace-uses.rst   |  2 +-
>  Documentation/trace/histogram.txt |  2 +-
>  Documentation/trace/intel_th.rst  |  2 +-
>  Documentation/trace/tracepoint-analysis.rst   |  6 +++---
>  Documentation/translations/ja_JP/howto.rst|  4 ++--
>  .../translations/zh_CN/magic-number.txt   |  4 ++--
>  .../zh_CN/video4linux/omap3isp.txt|  4 ++--
>  MAINTAINERS   | 20 +--
>  arch/Kconfig  |  2 +-
>  arch/arm/include/asm/cacheflush.h |  2 +-
>  arch/arm64/include/asm/cacheflush.h   |  2 +-
>  arch/microblaze/include/asm/cacheflush.h  |  2 +-
>  arch/um/Kconfig.um|  2 +-
>  arch/unicore32/include/asm/cacheflush.h   |  2 +-
>  arch/x86/entry/vsyscall/vsyscall_64.c |  2 +-
>  arch/xtensa/include/asm/cacheflush.h  |  4 ++--
>  block/Kconfig |  2 +-
>  certs/Kconfig |  2 +-
>  crypto/asymmetric_keys/asymmetric_type.c  |  2 +-
>  crypto/asymmetric_keys/signature.c|  2 +-
>  drivers/char/Kconfig  |  2 +-
>  drivers/clk/clk.c |  4 ++--
>  drivers/clk/ingenic/cgu.h |  2 +-
>  drivers/gpu/vga/Kconfig   |  2 +-
>  drivers/gpu/vga/vgaarb.c  |  2 +-
>  drivers/input/joystick/Kconfig| 10 +-
>  drivers/input/joystick/iforce/Kconfig |  2 +-
>  drivers/input/joystick/walkera0701.c  |  2 +-
>  drivers/input/misc/Kconfig|  4 ++--
>  drivers/input/misc/rotary_encoder.c   |  2 +-
>  drivers/input/mouse/Kconfig   |  6 +++---
>  drivers/input/mouse/alps.c|  2 +-
>  drivers/input/touchscreen/wm97xx-core.c   |  2 +-
>  drivers/lightnvm/pblk-rb.c|  2 +-
>  drivers/md/bcache/Kconfig |  2 +-
>  drivers/md/bcache/btree.c |  2 +-
>  drivers/md/bcache/extents.c   |  2 +-
>  drivers/media/dvb-core/dvb_ringbuffer.c   |  2 +-
>  drivers/media/pci/meye/Kconfig|  2 +-
>  drivers/media/platform/pxa_camera.c   |  4 ++--
>  .../soc_camera/sh_mobile_ceu_camera.c |  2 +-
>  drivers/media/radio/Kconfig   |  2 +-
>  drivers/media/radio/si470x/Kconfig|  2 +-
>  drivers/media/usb/dvb-usb-v2/lmedm04.c|  2 +-
>  drivers/media/usb/zr364xx/Kconfig |  2 +-
>  drivers/parport/Kconfig   |  6 +++---
>  drivers/staging/media/bcm2048/TODO|  2 +-
>  include/keys/asymmetric-subtype.h |  2 +-
>  include/keys/asymmetric-type.h|  2 +-
>  include/linux/assoc_array.h   |  2 +-
>  include/linux/assoc_array_priv.h  |  2 +-
>  include/linux/circ_buf.h  |  2 +-
>  include/linux/ftrace.h|  2 +-
>  include/linux/rculist_nulls.h |  2 +-
>  include/uapi/linux/prctl.h|  2 +-
>  include/xen/interface/io/kbdif.h  |  2 +-
>  kernel/cgroup/cpuset.c|  2 +-
>  kernel/trace/Kconfig  | 16 +++
>  lib/Kconfig   |  2 +-
>  security/selinux/hooks.c  |  2 +-
>  sound/core/Kconfig|  4 ++--
>  sound/drivers/Kconfig |  4 ++--
>  sound/pci/Kconfig | 10 +-
>  tools/include/uapi/linux/prctl.h  |  2 +-
>  tools/lib/api/fs/fs.c |  2 +-
>  tools/memory-model/README | 10 +-
>  tools/perf/util/bpf-prologue.c|  2 +-
>  .../config/custom-timeline-functions.cfg  |  4 ++--
>  74 files changed, 120 insertions(+), 120 deletions(-)
> 


-- 
Masami Hiramatsu 

Re: [PATCH] drm/vc4: plane: Expand the lower bits using the LSB

[Maxime Ripard]

Hi Eric,

On Tue, Apr 24, 2018 at 09:53:28AM -0700, Eric Anholt wrote:
> Maxime Ripard  writes:
> 
> > The vc4 HVS uses an internal RGB888 representation of the frames, and will
> > by default expand formats using a lower depth using zeros.
> >
> > This causes an issue when we try to use other compositing software such as
> > pixman that seems to be filling the missing bits using the format least
> > significant bit value. As such, this prevents us from checking the display
> > output in a reliable way.
> 
> I don't think this is the right expansion function, though?  My
> understanding of proper unorm expansion, and what pixman's
> unorm_to_unorm() does, is that you replicate the value in the missing
> bits until you've filled them all (so SCALER_CTL0_EXPAND_REPEAT)

This was based on experiment, so I might have missed that case and you
are probably right. I'll test with SCALER_CTL0_EXPAND_REPEAT and let
you know :)

Thanks!
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] gpu: drm: tegra: Adding new typedef vm_fault_t

[Thierry Reding]

On Tue, Apr 17, 2018 at 07:17:55PM +0530, Souptick Joarder wrote:
> Use new return type vm_fault_t for fault handler. For
> now, this is just documenting that the function returns
> a VM_FAULT value rather than an errno. Once all instances
> are converted, vm_fault_t will become a distinct type.
> 
> Reference id -> 1c8f422059ae ("mm: change return type to
> vm_fault_t")
> 
> Previously vm_insert_page() returns err which driver
> mapped into VM_FAULT_* type. The new function 
> vmf_insert_page() will replace this inefficiency by
> returning VM_FAULT_* type.
> 
> Signed-off-by: Souptick Joarder 
> ---
>  drivers/gpu/drm/tegra/gem.c | 18 ++
>  1 file changed, 2 insertions(+), 16 deletions(-)

Applied, thanks.

Thierry


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

[Bug 106499] [regression, bisected] Several games crash on start

[bugzilla-daemon]

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

--- Comment #2 from Gregor Münch  ---
There is another bug Report, bisecting to another commit (which might make more
sense): https://bugs.freedesktop.org/show_bug.cgi?id=106511

Was in a hurry while bisecting it, cant test until Friday. Feel free to mark
this as duplicate.

-- 
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] gpu: host1x: Acquire a reference to the IOVA cache

[Thierry Reding]

On Mon, May 14, 2018 at 01:34:27PM +0300, Dmitry Osipenko wrote:
> On 14.05.2018 13:13, Thierry Reding wrote:
> > From: Thierry Reding 
> > 
> > The IOVA API uses a memory cache to allocate IOVA nodes from. To make
> > sure that this cache is available, obtain a reference to it and release
> > the reference when the cache is no longer needed.
> > 
> > On 64-bit ARM this is hidden by the fact that the DMA mapping API gets
> > that reference and never releases it. On 32-bit ARM, this is papered
> > over by the Tegra DRM driver (the sole user of the host1x API requiring
> > the cache) acquiring a reference to the IOVA cache for its own purposes.
> > However, there may be additional users of this API in the future, so fix
> > this upfront to avoid surprises.
> > 
> > Fixes: 404bfb78daf3 ("gpu: host1x: Add IOMMU support")
> > Signed-off-by: Thierry Reding 
> > ---
> >  drivers/gpu/host1x/dev.c | 11 ++-
> >  1 file changed, 10 insertions(+), 1 deletion(-)

Applied, thanks.

Thierry


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 2/2] drm/bridge: sii902x: add optional power supplies

[Andrzej Hajda]

On 14.05.2018 11:38, Philippe CORNU wrote:
> Hi Laurent, Archit, Andrzej & Yannick,
>
> Do you have any comments on this v2 driver part?
> (more details regarding v1/v2 differences in the cover letter 
> https://www.spinics.net/lists/dri-devel/msg174137.html)
>
> Thank you,
> Philippe :-)
>
>
> On 04/25/2018 09:53 AM, Philippe Cornu wrote:
>> Add the optional power supplies using the description found in
>> "SiI9022A/SiI9024A HDMI Transmitter Data Sheet (August 2016)".
>>
>> The sii902x input IOs are not "io safe" so it is important to
>> enable/disable voltage regulators during probe/remove phases to
>> avoid damages.

What exactly does it mean? Ie I understand that the chip has some
limitations, but why enabling/disabling regulators in probe/remove
should solve it?

Regards
Andrzej

>>
>> Signed-off-by: Philippe Cornu 
>> ---
>>   drivers/gpu/drm/bridge/sii902x.c | 38 
>> ++
>>   1 file changed, 34 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/sii902x.c 
>> b/drivers/gpu/drm/bridge/sii902x.c
>> index 60373d7eb220..c367d7b91ade 100644
>> --- a/drivers/gpu/drm/bridge/sii902x.c
>> +++ b/drivers/gpu/drm/bridge/sii902x.c
>> @@ -24,6 +24,7 @@
>>   #include 
>>   #include 
>>   #include 
>> +#include 
>>   
>>   #include 
>>   #include 
>> @@ -86,6 +87,7 @@ struct sii902x {
>>  struct drm_bridge bridge;
>>  struct drm_connector connector;
>>  struct gpio_desc *reset_gpio;
>> +struct regulator_bulk_data supplies[2];
>>   };
>>   
>>   static inline struct sii902x *bridge_to_sii902x(struct drm_bridge *bridge)
>> @@ -392,23 +394,42 @@ static int sii902x_probe(struct i2c_client *client,
>>  return PTR_ERR(sii902x->reset_gpio);
>>  }
>>   
>> +sii902x->supplies[0].supply = "iovcc";
>> +sii902x->supplies[1].supply = "vcc12";
>> +ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(sii902x->supplies),
>> +  sii902x->supplies);
>> +if (ret) {
>> +dev_err(dev, "Failed to get power supplies: %d\n", ret);
>> +return ret;
>> +}
>> +
>> +ret = regulator_bulk_enable(ARRAY_SIZE(sii902x->supplies),
>> +sii902x->supplies);
>> +if (ret) {
>> +dev_err(dev, "Failed to enable power supplies: %d\n", ret);
>> +return ret;
>> +}
>> +
>> +usleep_range(1, 2);
>> +
>>  sii902x_reset(sii902x);
>>   
>>  ret = regmap_write(sii902x->regmap, SII902X_REG_TPI_RQB, 0x0);
>>  if (ret)
>> -return ret;
>> +goto err_disable_regulator;
>>   
>>  ret = regmap_bulk_read(sii902x->regmap, SII902X_REG_CHIPID(0),
>> , 4);
>>  if (ret) {
>>  dev_err(dev, "regmap_read failed %d\n", ret);
>> -return ret;
>> +goto err_disable_regulator;
>>  }
>>   
>>  if (chipid[0] != 0xb0) {
>>  dev_err(dev, "Invalid chipid: %02x (expecting 0xb0)\n",
>>  chipid[0]);
>> -return -EINVAL;
>> +ret = -EINVAL;
>> +goto err_disable_regulator;
>>  }
>>   
>>  /* Clear all pending interrupts */
>> @@ -424,7 +445,7 @@ static int sii902x_probe(struct i2c_client *client,
>>  IRQF_ONESHOT, dev_name(dev),
>>  sii902x);
>>  if (ret)
>> -return ret;
>> +goto err_disable_regulator;
>>  }
>>   
>>  sii902x->bridge.funcs = _bridge_funcs;
>> @@ -434,6 +455,12 @@ static int sii902x_probe(struct i2c_client *client,
>>  i2c_set_clientdata(client, sii902x);
>>   
>>  return 0;
>> +
>> +err_disable_regulator:
>> +regulator_bulk_disable(ARRAY_SIZE(sii902x->supplies),
>> +   sii902x->supplies);
>> +
>> +return ret;
>>   }
>>   
>>   static int sii902x_remove(struct i2c_client *client)
>> @@ -443,6 +470,9 @@ static int sii902x_remove(struct i2c_client *client)
>>   
>>  drm_bridge_remove(>bridge);
>>   
>> +regulator_bulk_disable(ARRAY_SIZE(sii902x->supplies),
>> +   sii902x->supplies);
>> +
>>  return 0;
>>   }
>>   


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

[Bug 106490] VA-API video deconding broken for Chromium on Mesa 18.0.3

[bugzilla-daemon]

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

--- Comment #1 from Leonid Maksymchuk  ---
It looks like it's Chromium or VA-API bug, but not Mesa.
Chromium VA-API decoding works with Mesa 18.0 if RGB10 visual configs is
disabled.

-- 
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 106496] Hung screen at modprobe amdgpu

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #2 from Michel Dänzer  ---
You'll have to disable SME for the time being.

*** This bug has been marked as a duplicate of bug 106245 ***

-- 
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 106245] Raven ridge (2400g) fails to start (swiotlb buffer is full) with IOMMU disabled

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

 CC||c...@atamisk.net

--- Comment #3 from Michel Dänzer  ---
*** Bug 106496 has been marked as a duplicate of this bug. ***

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

[Bug 106496] Hung screen at modprobe amdgpu

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

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

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

[PATCH] gpu: host1x: Acquire a reference to the IOVA cache

[Thierry Reding]

From: Thierry Reding 

The IOVA API uses a memory cache to allocate IOVA nodes from. To make
sure that this cache is available, obtain a reference to it and release
the reference when the cache is no longer needed.

On 64-bit ARM this is hidden by the fact that the DMA mapping API gets
that reference and never releases it. On 32-bit ARM, this is papered
over by the Tegra DRM driver (the sole user of the host1x API requiring
the cache) acquiring a reference to the IOVA cache for its own purposes.
However, there may be additional users of this API in the future, so fix
this upfront to avoid surprises.

Fixes: 404bfb78daf3 ("gpu: host1x: Add IOMMU support")
Signed-off-by: Thierry Reding 
---
 drivers/gpu/host1x/dev.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c
index 03db71173f5d..f1d5f76e9c33 100644
--- a/drivers/gpu/host1x/dev.c
+++ b/drivers/gpu/host1x/dev.c
@@ -223,10 +223,14 @@ static int host1x_probe(struct platform_device *pdev)
struct iommu_domain_geometry *geometry;
unsigned long order;
 
+   err = iova_cache_get();
+   if (err < 0)
+   goto put_group;
+
host->domain = iommu_domain_alloc(_bus_type);
if (!host->domain) {
err = -ENOMEM;
-   goto put_group;
+   goto put_cache;
}
 
err = iommu_attach_group(host->domain, host->group);
@@ -234,6 +238,7 @@ static int host1x_probe(struct platform_device *pdev)
if (err == -ENODEV) {
iommu_domain_free(host->domain);
host->domain = NULL;
+   iova_cache_put();
iommu_group_put(host->group);
host->group = NULL;
goto skip_iommu;
@@ -308,6 +313,9 @@ static int host1x_probe(struct platform_device *pdev)
 fail_free_domain:
if (host->domain)
iommu_domain_free(host->domain);
+put_cache:
+   if (host->group)
+   iova_cache_put();
 put_group:
iommu_group_put(host->group);
 
@@ -328,6 +336,7 @@ static int host1x_remove(struct platform_device *pdev)
put_iova_domain(>iova);
iommu_detach_group(host->domain, host->group);
iommu_domain_free(host->domain);
+   iova_cache_put();
iommu_group_put(host->group);
}
 
-- 
2.17.0

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

Re: [PATCH v3 5/5] drm/arm/malidp: Added the late system pm functions

[Ayan Halder]

On Wed, Apr 25, 2018 at 01:49:35PM +0200, Daniel Vetter wrote:
Hi Daniel,
> On Wed, Apr 25, 2018 at 1:26 PM, Liviu Dudau  wrote:
> > On Wed, Apr 25, 2018 at 09:17:22AM +0200, Daniel Vetter wrote:
> >> On Tue, Apr 24, 2018 at 07:12:47PM +0100, Ayan Kumar Halder wrote:
> >> > malidp_pm_suspend_late checks if the runtime status is not suspended
> >> > and if so, invokes malidp_runtime_pm_suspend which disables the
> >> > display engine/core interrupts and the clocks. It sets the runtime status
> >> > as suspended.
> >> >
> >> > The difference between suspend() and suspend_late() is as follows:-
> >> > 1. suspend() makes the device quiescent. In our case, we invoke the DRM
> >> > helper which disables the CRTC. This would have invoked runtime pm
> >> > suspend but the system suspend process disables runtime pm.
> >> > 2. suspend_late() It continues the suspend operations of the drm device
> >> > which was started by suspend(). In our case, it performs the same 
> >> > functionality
> >> > as runtime_suspend().
> >> >
> >> > The complimentary functions are resume() and resume_early(). In the case 
> >> > of
> >> > resume_early(), we invoke malidp_runtime_pm_resume() which enables the 
> >> > clocks
> >> > and the interrupts. It sets the runtime status as active. If the device 
> >> > was
> >> > in runtime suspend mode before system suspend was called, 
> >> > pm_runtime_work()
> >> > will put the device back in runtime suspended mode( after the complete 
> >> > system
> >> > has been resumed).
> >> >
> >> > Signed-off-by: Ayan Kumar Halder 
> >> >
> >>
> >> Afaiui we still haven't bottomed out on the discussion on v1. Did you get
> >> hold of Rafael?
> >
> > No, there was no reply from him. Lets try again:
> >
> > Rafael, we are debating on what the proper approach is for handling the
> > suspend/resume callbacks for a DRM driver that is likely to not be
> > runtime suspended when the power-down happens (because we are driving
> > the display output). We are using in this patch the LATE_SYSTEM_SLEEP_PM_OPS
> > in order to do the work that we also do during runtime suspend, which is
> > turning off the output and the clocks driving it. The reason for doing
> > that is because the PM core takes a runtime reference during system
> > suspend for all devices that are not already runtime suspended, so our
> > runtime_pm_suspend() hook is never called.
> >
> > Daniel's argument is that we should not be doing this from LATE hooks,
> > but from the normal suspend hooks, however kernel doc seems to suggest
> > otherwise.
> 
> For more context: I thought the reason behind the recommendation to
> stuff the rpm callbacks into the late/early hooks was to solve
> cross-device ordering issues. That way everyone shuts down the device
> functionality in the normal hooks, but only powers them off in the
> late hook (to allow other drivers to keep using the clock/i2c
> master/whatever). But we now have device_link to solve that since a
> while, so I'm not sure the recommendation to stuff the rpm hooks into
> late/early callbacks is still correct.
> -Daniel
> 
It has been more than two weeks and we have not got any response from
Rafael. Can you ping him personally or suggest any way by which ask
him to respond?
> >
> > Best regards,
> > Liviu
> >
> >
> >
> >> -Daniel
> >>
> >> > ---
> >> > Changes in v3:-
> >> > - Rebased on top of earlier v3 patches,
> >> >
> >> > Changes in v2:-
> >> > - Removed the change id and modified the commit message
> >> > ---
> >> >  drivers/gpu/drm/arm/malidp_drv.c | 17 +
> >> >  1 file changed, 17 insertions(+)
> >> >
> >> > diff --git a/drivers/gpu/drm/arm/malidp_drv.c 
> >> > b/drivers/gpu/drm/arm/malidp_drv.c
> >> > index 82221ea..c53b46a 100644
> >> > --- a/drivers/gpu/drm/arm/malidp_drv.c
> >> > +++ b/drivers/gpu/drm/arm/malidp_drv.c
> >> > @@ -768,8 +768,25 @@ static int __maybe_unused malidp_pm_resume(struct 
> >> > device *dev)
> >> > return 0;
> >> >  }
> >> >
> >> > +static int __maybe_unused malidp_pm_suspend_late(struct device *dev)
> >> > +{
> >> > +   if (!pm_runtime_status_suspended(dev)) {
> >> > +   malidp_runtime_pm_suspend(dev);
> >> > +   pm_runtime_set_suspended(dev);
> >> > +   }
> >> > +   return 0;
> >> > +}
> >> > +
> >> > +static int __maybe_unused malidp_pm_resume_early(struct device *dev)
> >> > +{
> >> > +   malidp_runtime_pm_resume(dev);
> >> > +   pm_runtime_set_active(dev);
> >> > +   return 0;
> >> > +}
> >> > +
> >> >  static const struct dev_pm_ops malidp_pm_ops = {
> >> > SET_SYSTEM_SLEEP_PM_OPS(malidp_pm_suspend, malidp_pm_resume) \
> >> > +   SET_LATE_SYSTEM_SLEEP_PM_OPS(malidp_pm_suspend_late, 
> >> > malidp_pm_resume_early) \
> >> > SET_RUNTIME_PM_OPS(malidp_runtime_pm_suspend, 
> >> > malidp_runtime_pm_resume, NULL)
> >> >  };
> >> >
> >> > --
> >> > 2.7.4
> >> >
> >> > ___
> >> > dri-devel mailing list
> >> > 

Re: [PATCH] drm: mali-dp: Add debugfs file for reporting internal errors

[Alexandru-Cosmin Gheorghe]

On Mon, May 14, 2018 at 10:19:27AM +0100, Brian Starkey wrote:
> Hi Alex,
> 
> On Fri, May 11, 2018 at 06:56:03PM +0100, Alexandru Gheorghe wrote:
> >Status register contains a lot of bits for reporting internal errors
> >inside Mali DP. Currently, we just silently ignore all of the erorrs,
> 
> Being picky: s/erorrs/errors/
> 
> >that doesn't help when we are investigating different bugs, especially
> >on the FPGA models which have a lot of constrains, so we could easily
> 
> s/constrains/constraints/
> 
> >end up in AXI or underrun errors.
> >
> >Add a new file called debug that contains an agregate of the
> 
> s/agregate/aggregate/
> 
> >errors reported by the Mali DP hardware.
> >
> >E.g:
> >[root@alarm ~]# cat /sys/kernel/debug/dri/1/debug
> >[DE] num_errors : 167
> >[DE] last_error_status  : 0x0001
> >[DE] last_error_vblank : 385
> >[SE] num_errors : 3
> >[SE] last_error_status  : 0x00e23001
> >[SE] last_error_vblank : 201
> >
> >This a morphosis of the patch presented here [1], where the errors
> >where reported continuously via trace_printk.
> >
> >[1] 
> >https://lists.freedesktop.org/archives/dri-devel/2018-February/167042.html
> >
> >Signed-off-by: Alexandru Gheorghe 
> >---
> >drivers/gpu/drm/arm/malidp_drv.c  | 61 
> >+++
> >drivers/gpu/drm/arm/malidp_drv.h  | 15 ++
> >drivers/gpu/drm/arm/malidp_hw.c   | 46 -
> >drivers/gpu/drm/arm/malidp_hw.h   |  1 +
> >drivers/gpu/drm/arm/malidp_regs.h |  6 
> >5 files changed, 122 insertions(+), 7 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/arm/malidp_drv.c 
> >b/drivers/gpu/drm/arm/malidp_drv.c
> >index 8d20faa..70ce19a 100644
> >--- a/drivers/gpu/drm/arm/malidp_drv.c
> >+++ b/drivers/gpu/drm/arm/malidp_drv.c
> >@@ -17,6 +17,7 @@
> >#include 
> >#include 
> >#include 
> >+#include 
> >
> >#include 
> >#include 
> >@@ -29,6 +30,7 @@
> >#include 
> >#include 
> >#include 
> >+#include 
> >
> >#include "malidp_drv.h"
> >#include "malidp_regs.h"
> >@@ -327,6 +329,62 @@ static int malidp_dumb_create(struct drm_file 
> >*file_priv,
> > return drm_gem_cma_dumb_create_internal(file_priv, drm, args);
> >}
> >
> >+#ifdef CONFIG_DEBUG_FS
> >+
> >+static void malidp_error_stats_init(struct malidp_error_stats *error_stats)
> >+{
> >+atomic_set(_stats->num_errors, 0);
> >+atomic_set(_stats->last_error_status, 0);
> >+atomic64_set(_stats->last_error_vblank, -1);
> >+}
> >+
> >+void malidp_error(struct malidp_error_stats *error_stats, u32 status,
> >+  u64 vblank)
> >+{
> >+atomic_set(_stats->last_error_status, status);
> >+atomic64_set(_stats->last_error_vblank, vblank);
> >+atomic_inc(_stats->num_errors);
> >+}
> >+
> 
> Do we already have a lock we could use to make sure the status printed
> is consistent? I know this is "only debug", but it could be annoying
> if we can't trust that the last_error_status does actually match the
> last_error_vblank.
>

No, we don't have any lock. Yes that would be annoying, I will add
one.
 
> >+void malidp_error_stats_dump(const char *prefix,
> >+ struct malidp_error_stats *error_stats,
> >+ struct seq_file *m)
> >+{
> >+seq_printf(m, "[%s] num_errors : %d\n", prefix,
> >+   atomic_read(_stats->num_errors));
> >+seq_printf(m, "[%s] last_error_status  : 0x%08x\n", prefix,
> >+   atomic_read(_stats->last_error_status));
> >+seq_printf(m, "[%s] last_error_vblank : %ld\n", prefix,
> >+   atomic64_read(_stats->last_error_vblank));
> >+}
> >+
> >+static int malidp_show_stats(struct seq_file *m, void *arg)
> >+{
> >+struct drm_info_node *node = (struct drm_info_node *)m->private;
> >+struct drm_device *drm = node->minor->dev;
> >+struct malidp_drm *malidp = drm->dev_private;
> >+
> >+malidp_error_stats_dump("DE", >de_errors, m);
> >+malidp_error_stats_dump("SE", >se_errors, m);
> >+return 0;
> >+}
> >+
> >+static struct drm_info_list malidp_debugfs_list[] = {
> >+{ "debug", malidp_show_stats, 0 },
> >+};
> 
> I think it would be pretty useful to have a way to reset the counters.
> Maybe by just writing anything to the file?
> 

drm_debugfs_fops doesn't allow writing. I see no reason using our own
debugs_fops, but do you think worth the trouble?

> Thanks,
> -Brian
> 
> >+
> >+static int malidp_debugfs_init(struct drm_minor *minor)
> >+{
> >+struct malidp_drm *malidp = minor->dev->dev_private;
> >+
> >+malidp_error_stats_init(>de_errors);
> >+malidp_error_stats_init(>se_errors);
> >+return drm_debugfs_create_files(malidp_debugfs_list,
> >+ARRAY_SIZE(malidp_debugfs_list), minor->debugfs_root, minor);
> >+}
> >+
> >+#endif //CONFIG_DEBUG_FS
> >+
> >static struct drm_driver malidp_driver = {
> > .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC |
> >DRIVER_PRIME,
> >@@ -343,6 +401,9 @@ static 

[Bug 97025] flip queue failed: Device or resource busy

[bugzilla-daemon]

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

--- Comment #28 from Michel Dänzer  ---
(In reply to Bernd Steinhauser from comment #27)
> 
> Although I'm not sure if it works as expected, since the display does still
> seem to disconnect when I turn the screen off.

AFAIK that's either a monitor or general DisplayPort issue. The drivers can't
prevent it but have to cope with it.

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

RE: [PATCH v3 27/40] drm/i915: Implement HDCP2.2 link integrity check

[Shankar, Uma]

>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Ramalingam C
>Sent: Tuesday, April 3, 2018 7:28 PM
>To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
>jani.nik...@linux.intel.com; Winkler, Tomas ;
>Usyskin, Alexander 
>Cc: Vivi, Rodrigo 
>Subject: [PATCH v3 27/40] drm/i915: Implement HDCP2.2 link integrity check
>
>Implements the link integrity check once in 500mSec.
>
>Once encryption is enabled, an ongoing Link Integrity Check is performed by the
>HDCP Receiver to check that cipher synchronization is maintained between the
>HDCP Transmitter and the HDCP Receiver.
>
>On the detection of synchronization lost, the HDCP Receiver must assert the
>corresponding bits of the RxStatus register. The Transmitter polls the RxStatus
>register and it may initiate re-authentication.
>
>v2:
>  Rebased.
>v3:
>  No Changes.
>
>Signed-off-by: Ramalingam C 
>---
> drivers/gpu/drm/i915/intel_hdcp.c | 81
>++-
> include/drm/drm_hdcp.h|  8 
> 2 files changed, 88 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
>b/drivers/gpu/drm/i915/intel_hdcp.c
>index 005627746ca5..e2aec73aefe3 100644
>--- a/drivers/gpu/drm/i915/intel_hdcp.c
>+++ b/drivers/gpu/drm/i915/intel_hdcp.c
>@@ -23,6 +23,8 @@
>
> static int _intel_hdcp2_enable(struct intel_connector *connector);  static int
>_intel_hdcp2_disable(struct intel_connector *connector);
>+static void intel_hdcp2_check_work(struct work_struct *work); static
>+int intel_hdcp2_check_link(struct intel_connector *connector);
>
> static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port *intel_dig_port,
>   const struct intel_hdcp_shim *shim) @@ -
>1456,6 +1458,83 @@ static int _intel_hdcp2_enable(struct intel_connector
>*connector)
>
>   hdcp->hdcp_value = DRM_MODE_CONTENT_PROTECTION_ENABLED;
>   schedule_work(>hdcp_prop_work);
>-
>+  schedule_delayed_work(>hdcp2_check_work,
>+DRM_HDCP2_CHECK_PERIOD_MS);
>   return 0;
> }
>+
>+static int intel_hdcp2_check_link(struct intel_connector *connector) {
>+  struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
>+  struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
>+  struct intel_hdcp *hdcp = >hdcp;
>+  enum port port = connector->encoder->port;
>+  int ret = 0;
>+
>+  if (!hdcp->hdcp_shim)
>+  return -ENOENT;
>+
>+  mutex_lock(>hdcp_mutex);
>+
>+  if (hdcp->hdcp_value ==
>DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
>+  goto out;
>+
>+  if (!(I915_READ(HDCP2_STATUS_DDI(port)) &
>LINK_ENCRYPTION_STATUS)) {
>+  DRM_ERROR("HDCP check failed: link is not encrypted, %x\n",
>+ I915_READ(HDCP2_STATUS_DDI(port)));
>+  ret = -ENXIO;
>+  hdcp->hdcp_value =
>DRM_MODE_CONTENT_PROTECTION_DESIRED;
>+  schedule_work(>hdcp_prop_work);
>+  goto out;
>+  }
>+
>+  ret = hdcp->hdcp_shim->check_2_2_link(intel_dig_port);

Check " hdcp->hdcp_shim->check_2_2_link " for NULL.

>+  if (!ret) {
>+  if (hdcp->hdcp_value !=
>DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
>+  hdcp->hdcp_value =
>DRM_MODE_CONTENT_PROTECTION_ENABLED;
>+  schedule_work(>hdcp_prop_work);
>+  }
>+  goto out;
>+  }
>+
>+  DRM_INFO("[%s:%d] HDCP2.2 link failed, retrying authentication\n",
>+   connector->base.name, connector->base.base.id);
>+
>+  ret = _intel_hdcp2_disable(connector);
>+  if (ret) {
>+  DRM_ERROR("[%s:%d] Failed to disable hdcp2.2 (%d)\n",
>+connector->base.name, connector->base.base.id, ret);
>+
>+  hdcp->hdcp_value =
>DRM_MODE_CONTENT_PROTECTION_DESIRED;
>+  schedule_work(>hdcp_prop_work);
>+  goto out;
>+  }
>+
>+  ret = _intel_hdcp2_enable(connector);
>+  if (ret) {
>+  DRM_ERROR("[%s:%d] Failed to enable hdcp2.2 (%d)\n",
>+connector->base.name, connector->base.base.id, ret);
>+
>+  hdcp->hdcp_value =
>DRM_MODE_CONTENT_PROTECTION_DESIRED;
>+  schedule_work(>hdcp_prop_work);
>+  goto out;
>+  }
>+
>+out:
>+  mutex_unlock(>hdcp_mutex);
>+  return ret;
>+}
>+
>+static void intel_hdcp2_check_work(struct work_struct *work) {
>+  struct intel_hdcp *hdcp = container_of(to_delayed_work(work),
>+  struct intel_hdcp,
>+  hdcp2_check_work);
>+  struct intel_connector *connector = container_of(hdcp,
>+  

Re: [PATCH v2 2/2] drm/bridge: sii902x: add optional power supplies

[Philippe CORNU]

Hi Laurent, Archit, Andrzej & Yannick,

Do you have any comments on this v2 driver part?
(more details regarding v1/v2 differences in the cover letter 
https://www.spinics.net/lists/dri-devel/msg174137.html)

Thank you,
Philippe :-)


On 04/25/2018 09:53 AM, Philippe Cornu wrote:
> Add the optional power supplies using the description found in
> "SiI9022A/SiI9024A HDMI Transmitter Data Sheet (August 2016)".
> 
> The sii902x input IOs are not "io safe" so it is important to
> enable/disable voltage regulators during probe/remove phases to
> avoid damages.
> 
> Signed-off-by: Philippe Cornu 
> ---
>   drivers/gpu/drm/bridge/sii902x.c | 38 ++
>   1 file changed, 34 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/sii902x.c 
> b/drivers/gpu/drm/bridge/sii902x.c
> index 60373d7eb220..c367d7b91ade 100644
> --- a/drivers/gpu/drm/bridge/sii902x.c
> +++ b/drivers/gpu/drm/bridge/sii902x.c
> @@ -24,6 +24,7 @@
>   #include 
>   #include 
>   #include 
> +#include 
>   
>   #include 
>   #include 
> @@ -86,6 +87,7 @@ struct sii902x {
>   struct drm_bridge bridge;
>   struct drm_connector connector;
>   struct gpio_desc *reset_gpio;
> + struct regulator_bulk_data supplies[2];
>   };
>   
>   static inline struct sii902x *bridge_to_sii902x(struct drm_bridge *bridge)
> @@ -392,23 +394,42 @@ static int sii902x_probe(struct i2c_client *client,
>   return PTR_ERR(sii902x->reset_gpio);
>   }
>   
> + sii902x->supplies[0].supply = "iovcc";
> + sii902x->supplies[1].supply = "vcc12";
> + ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(sii902x->supplies),
> +   sii902x->supplies);
> + if (ret) {
> + dev_err(dev, "Failed to get power supplies: %d\n", ret);
> + return ret;
> + }
> +
> + ret = regulator_bulk_enable(ARRAY_SIZE(sii902x->supplies),
> + sii902x->supplies);
> + if (ret) {
> + dev_err(dev, "Failed to enable power supplies: %d\n", ret);
> + return ret;
> + }
> +
> + usleep_range(1, 2);
> +
>   sii902x_reset(sii902x);
>   
>   ret = regmap_write(sii902x->regmap, SII902X_REG_TPI_RQB, 0x0);
>   if (ret)
> - return ret;
> + goto err_disable_regulator;
>   
>   ret = regmap_bulk_read(sii902x->regmap, SII902X_REG_CHIPID(0),
>  , 4);
>   if (ret) {
>   dev_err(dev, "regmap_read failed %d\n", ret);
> - return ret;
> + goto err_disable_regulator;
>   }
>   
>   if (chipid[0] != 0xb0) {
>   dev_err(dev, "Invalid chipid: %02x (expecting 0xb0)\n",
>   chipid[0]);
> - return -EINVAL;
> + ret = -EINVAL;
> + goto err_disable_regulator;
>   }
>   
>   /* Clear all pending interrupts */
> @@ -424,7 +445,7 @@ static int sii902x_probe(struct i2c_client *client,
>   IRQF_ONESHOT, dev_name(dev),
>   sii902x);
>   if (ret)
> - return ret;
> + goto err_disable_regulator;
>   }
>   
>   sii902x->bridge.funcs = _bridge_funcs;
> @@ -434,6 +455,12 @@ static int sii902x_probe(struct i2c_client *client,
>   i2c_set_clientdata(client, sii902x);
>   
>   return 0;
> +
> +err_disable_regulator:
> + regulator_bulk_disable(ARRAY_SIZE(sii902x->supplies),
> +sii902x->supplies);
> +
> + return ret;
>   }
>   
>   static int sii902x_remove(struct i2c_client *client)
> @@ -443,6 +470,9 @@ static int sii902x_remove(struct i2c_client *client)
>   
>   drm_bridge_remove(>bridge);
>   
> + regulator_bulk_disable(ARRAY_SIZE(sii902x->supplies),
> +sii902x->supplies);
> +
>   return 0;
>   }
>   
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH v3 26/40] drm/i915: Implement HDCP2.2 En/Dis-able

[Shankar, Uma]

>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Ramalingam C
>Sent: Tuesday, April 3, 2018 7:28 PM
>To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
>jani.nik...@linux.intel.com; Winkler, Tomas ;
>Usyskin, Alexander 
>Cc: Vivi, Rodrigo 
>Subject: [PATCH v3 26/40] drm/i915: Implement HDCP2.2 En/Dis-able

May be calling enable/disable sequence separately will be better :)

>
>Implements a sequence of enabling and disabling the HDCP2.2 (auth and
>encryption).
>
>v2:
>  Rebased.
>v3:
>  No Changes.
>
>Signed-off-by: Ramalingam C 
>---
> drivers/gpu/drm/i915/intel_hdcp.c | 75
>+++
> 1 file changed, 75 insertions(+)
>
>diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
>b/drivers/gpu/drm/i915/intel_hdcp.c
>index 91cac643f083..005627746ca5 100644
>--- a/drivers/gpu/drm/i915/intel_hdcp.c
>+++ b/drivers/gpu/drm/i915/intel_hdcp.c
>@@ -21,6 +21,9 @@
> #define HDCP2_LC_RETRY_CNT3
> #define TIME_FOR_ENCRYPT_STATUS_CHANGE32
>
>+static int _intel_hdcp2_enable(struct intel_connector *connector);
>+static int _intel_hdcp2_disable(struct intel_connector *connector);
>+
> static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port *intel_dig_port,
>   const struct intel_hdcp_shim *shim)  { @@ -
>1384,3 +1387,75 @@ static int hdcp2_disable_encryption(struct intel_connector
>*connector)
>
>   return ret;
> }
>+
>+static int hdcp2_authenticate_and_encrypt(struct intel_connector
>+*connector) {
>+  int ret, i, tries = 3;
>+
>+  for (i = 0; i < tries; i++) {
>+  ret = hdcp2_authenticate_sink(connector);
>+  if (!ret)
>+  break;
>+
>+  /* Clearing the mei hdcp session */
>+  hdcp2_deauthenticate_port(>hdcp);
>+  DRM_DEBUG_KMS("HDCP2.2 Auth %d of %d Failed.(%d)\n",
>+i + 1, tries, ret);
>+  }
>+
>+  if (i != tries) {
>+
>+  /*
>+   * Ensuring the required 200mSec min time interval between
>+   * Session Key Exchange and encryption.
>+   */
>+  msleep(HDCP_2_2_DELAY_BEFORE_ENCRYPTION_EN);
>+  ret = hdcp2_enable_encryption(connector);
>+  if (ret < 0) {
>+  DRM_DEBUG_KMS("Encryption Enable Failed.(%d)\n",
>ret);
>+  hdcp2_deauthenticate_port(>hdcp);
>+  }
>+  }
>+
>+  return ret;
>+}
>+
>+static int _intel_hdcp2_disable(struct intel_connector *connector) {
>+  int ret;
>+
>+  DRM_DEBUG_KMS("[%s:%d] HDCP2.2 is being Disabled\n",
>+connector->base.name, connector->base.base.id);
>+
>+  ret = hdcp2_disable_encryption(connector);

Check for return and print a message.

>+
>+  hdcp2_deauthenticate_port(>hdcp);
>+
>+  return ret;
>+}
>+
>+static int _intel_hdcp2_enable(struct intel_connector *connector) {
>+  struct intel_hdcp *hdcp = >hdcp;
>+  int ret;
>+
>+  DRM_DEBUG_KMS("[%s:%d] HDCP2.2 is being enabled. Type: %d\n",
>+connector->base.name, connector->base.base.id,
>+hdcp->content_type);
>+
>+  ret = hdcp2_authenticate_and_encrypt(connector);
>+  if (ret) {
>+  DRM_ERROR("HDCP2 Type%d  Enabling Failed. (%d)\n",
>+ hdcp->content_type, ret);
>+  return ret;
>+  }
>+
>+  DRM_DEBUG_KMS("[%s:%d] HDCP2.2 is enabled. Type %d\n",
>+connector->base.name, connector->base.base.id,
>+hdcp->content_type);
>+
>+  hdcp->hdcp_value = DRM_MODE_CONTENT_PROTECTION_ENABLED;
>+  schedule_work(>hdcp_prop_work);
>+
>+  return 0;
>+}
>--
>2.7.4
>
>___
>dri-devel mailing list
>dri-devel@lists.freedesktop.org
;>https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH v3 25/40] drm/i915: Enable and Disable HDCP2.2 port encryption

[Shankar, Uma]

>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Ramalingam C
>Sent: Tuesday, April 3, 2018 7:28 PM
>To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
>jani.nik...@linux.intel.com; Winkler, Tomas ;
>Usyskin, Alexander 
>Cc: Vivi, Rodrigo 
>Subject: [PATCH v3 25/40] drm/i915: Enable and Disable HDCP2.2 port encryption
>
>Implements the enable and disable functions for HDCP2.2 encryption of the
>PORT.
>
>v2:
>  intel_wait_for_register is used instead of wait_for. [Chris Wilson]
>v3:
>  No Changes.
>
>Signed-off-by: Ramalingam C 
>---
> drivers/gpu/drm/i915/intel_hdcp.c | 54
>+++
> 1 file changed, 54 insertions(+)
>
>diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
>b/drivers/gpu/drm/i915/intel_hdcp.c
>index d70320da85e4..91cac643f083 100644
>--- a/drivers/gpu/drm/i915/intel_hdcp.c
>+++ b/drivers/gpu/drm/i915/intel_hdcp.c
>@@ -19,6 +19,7 @@
>(enum hdcp_physical_port) (port))
> #define KEY_LOAD_TRIES5
> #define HDCP2_LC_RETRY_CNT3
>+#define TIME_FOR_ENCRYPT_STATUS_CHANGE32
>
> static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port *intel_dig_port,
>   const struct intel_hdcp_shim *shim) @@ -
>1330,3 +1331,56 @@ static int hdcp2_authenticate_sink(struct intel_connector
>*connector)
>
>   return ret;
> }
>+
>+static int hdcp2_enable_encryption(struct intel_connector *connector) {
>+  struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
>+  struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
>+  struct intel_hdcp *hdcp = >hdcp;
>+  enum port port = connector->encoder->port;
>+  int ret;
>+
>+  if (I915_READ(HDCP2_STATUS_DDI(port)) & LINK_ENCRYPTION_STATUS)

Print a message saying "Encryption Already enabled" .

>+  return 0;
>+
>+  if (hdcp->hdcp_shim->toggle_signalling)

Check for "hdcp->hdcp_shim" as well.

>+  hdcp->hdcp_shim->toggle_signalling(intel_dig_port, true);
>+
>+  if (I915_READ(HDCP2_STATUS_DDI(port)) & LINK_AUTH_STATUS) {
>+
>+  /* Link is Authenticated. Now set for Encryption */
>+  I915_WRITE(HDCP2_CTR_DDI(port),
>+ I915_READ(HDCP2_CTR_DDI(port)) |
>+ CTL_LINK_ENCRYPTION_REQ);
>+  }
>+
>+  ret = intel_wait_for_register(dev_priv, HDCP2_STATUS_DDI(port),
>+LINK_ENCRYPTION_STATUS,
>+LINK_ENCRYPTION_STATUS,
>+TIME_FOR_ENCRYPT_STATUS_CHANGE);

Print a message in case of timeout.

>+  return ret;
>+}
>+
>+static int hdcp2_disable_encryption(struct intel_connector *connector)
>+{
>+  struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
>+  struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
>+  struct intel_hdcp *hdcp = >hdcp;
>+  enum port port = connector->encoder->port;
>+  int ret;
>+
>+  if (!(I915_READ(HDCP2_STATUS_DDI(port)) &
>LINK_ENCRYPTION_STATUS))

Put a info message saying "Already Disabled" .

>+  return 0;
>+
>+  I915_WRITE(HDCP2_CTR_DDI(port),
>+ I915_READ(HDCP2_CTR_DDI(port)) &
>~CTL_LINK_ENCRYPTION_REQ);
>+
>+  ret = intel_wait_for_register(dev_priv, HDCP2_STATUS_DDI(port),
>+LINK_ENCRYPTION_STATUS, 0x0,
>+TIME_FOR_ENCRYPT_STATUS_CHANGE);

If this times out, do we still need to toggle the signalling ?

>+
>+  if (hdcp->hdcp_shim->toggle_signalling)

Check for validity of " hdcp->hdcp_shim".

>+  hdcp->hdcp_shim->toggle_signalling(intel_dig_port, false);
>+
>+  return ret;
>+}
>--
>2.7.4
>
>___
>dri-devel mailing list
>dri-devel@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/2] dt-bindings/display/bridge: sii902x: add optional power supplies

[Philippe CORNU]

Hi Rob & Laurent :)

On 04/26/2018 12:05 AM, Laurent Pinchart wrote:
> Hi Rob,
> 
> On Wednesday, 25 April 2018 20:11:23 EEST Rob Herring wrote:
>> On Wed, Apr 25, 2018 at 04:17:25PM +0300, Laurent Pinchart wrote:
>>> On Wednesday, 25 April 2018 15:20:04 EEST Philippe CORNU wrote:
 On 04/25/2018 11:01 AM, Laurent Pinchart wrote:
> On Wednesday, 25 April 2018 10:53:13 EEST Philippe Cornu wrote:
>> Add optional power supplies using the description found in
>> "SiI9022A/SiI9024A HDMI Transmitter Data Sheet (August 2016)".
>>
>> There is a single 1v2 supply voltage named vcc12 from which cvcc12
>> (digital core) and avcc12 (TMDS analog) are derived because according
>> to this data sheet:
>> "cvcc12 and avcc12 can be derived from the same power source"
>
> Shouldn't the power supplies be mandatory, as explained by Mark in
> https://lists.freedesktop.org/archives/dri-devel/2018-April/172400.html
> ?

 Laurent,
 Many thanks Laurent for your comment, I understood the merge of the two
 1v2 power supplies but missed the "mandatory" part... maybe because this
 patch (with optional power supplies) already got the reviewed-by from
 Rob, I thought the discussion thread you pointed out was applicable
 "only" to totally new driver documentation.

 So, on my side, as a "new user" of sii902x IC, no problem to put these
 power supplies as mandatory instead of optional properties but I would
 like to be sure this is applicable to both old and new bindings doc : )
>>>
>>> We obviously need to retain backward compatibility, so on the driver side
>>> you need to treat those power supplies as optional. From a DT bindings
>>> point of view, however, I think they should be mandatory for new DT.
>>
>> We don't really have a way to describe these 3 conditions (required for
>> all, optional for all, and required for new). So generally we make
>> additions optional. The exception sometimes is if we update all the dts
>> files.
> 
> Can't we just make it mandatory in the bindings, as long as we treat it as
> optional in drivers ?
> 

How to progress on this patch? Do you have any suggestions?

Many thanks for your help,
Philippe :-)

 Rob,
 could you please confirm these power supply properties should be
 "mandatory"? if yes, should we then modify other optional properties like
 the reset-gpios too in the future?
>>>
>>> The GPIOs properties are different in my opinion, as there's no
>>> requirement to connect for instance the reset pin to a GPIO controllable
>>> by the SoC. The pin could be hardwired to VCC, or connected to a system
>>> reset that is automatically managed without SoC intervention. The power
>>> supplies, however, are mandatory, in the sense that the chip will not work
>>> if you leave the power supplies unconnected.
>>
>> DT only needs to describe what matters to s/w. If a regulator is
>> fixed and you don't need to know its voltage (or other read-only
>> parameters), then there's not much point in putting it in DT.
>>
>> I'd probably base this more at a platform level and you either use
>> regulator binding or you don't. It's perfectly valid that you want to do
>> things like regulator setup, pin ctrl and muxing setup, etc. all in
>> firmware and the OS doesn't touch any of that.
>>
>> That's all a big can of worms which we shouldn't solve on this 2 line
>> change. I think this change is fine as-is, so:
>>
>> Reviewed-by: Rob Herring 
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: mali-dp: Add debugfs file for reporting internal errors

[Brian Starkey]

Hi Alex,

On Fri, May 11, 2018 at 06:56:03PM +0100, Alexandru Gheorghe wrote:

Status register contains a lot of bits for reporting internal errors
inside Mali DP. Currently, we just silently ignore all of the erorrs,


Being picky: s/erorrs/errors/


that doesn't help when we are investigating different bugs, especially
on the FPGA models which have a lot of constrains, so we could easily


s/constrains/constraints/


end up in AXI or underrun errors.

Add a new file called debug that contains an agregate of the


s/agregate/aggregate/


errors reported by the Mali DP hardware.

E.g:
[root@alarm ~]# cat /sys/kernel/debug/dri/1/debug
[DE] num_errors : 167
[DE] last_error_status  : 0x0001
[DE] last_error_vblank : 385
[SE] num_errors : 3
[SE] last_error_status  : 0x00e23001
[SE] last_error_vblank : 201

This a morphosis of the patch presented here [1], where the errors
where reported continuously via trace_printk.

[1] https://lists.freedesktop.org/archives/dri-devel/2018-February/167042.html

Signed-off-by: Alexandru Gheorghe 
---
drivers/gpu/drm/arm/malidp_drv.c  | 61 +++
drivers/gpu/drm/arm/malidp_drv.h  | 15 ++
drivers/gpu/drm/arm/malidp_hw.c   | 46 -
drivers/gpu/drm/arm/malidp_hw.h   |  1 +
drivers/gpu/drm/arm/malidp_regs.h |  6 
5 files changed, 122 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 8d20faa..70ce19a 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -17,6 +17,7 @@
#include 
#include 
#include 
+#include 

#include 
#include 
@@ -29,6 +30,7 @@
#include 
#include 
#include 
+#include 

#include "malidp_drv.h"
#include "malidp_regs.h"
@@ -327,6 +329,62 @@ static int malidp_dumb_create(struct drm_file *file_priv,
return drm_gem_cma_dumb_create_internal(file_priv, drm, args);
}

+#ifdef CONFIG_DEBUG_FS
+
+static void malidp_error_stats_init(struct malidp_error_stats *error_stats)
+{
+   atomic_set(_stats->num_errors, 0);
+   atomic_set(_stats->last_error_status, 0);
+   atomic64_set(_stats->last_error_vblank, -1);
+}
+
+void malidp_error(struct malidp_error_stats *error_stats, u32 status,
+ u64 vblank)
+{
+   atomic_set(_stats->last_error_status, status);
+   atomic64_set(_stats->last_error_vblank, vblank);
+   atomic_inc(_stats->num_errors);
+}
+


Do we already have a lock we could use to make sure the status printed
is consistent? I know this is "only debug", but it could be annoying
if we can't trust that the last_error_status does actually match the
last_error_vblank.


+void malidp_error_stats_dump(const char *prefix,
+struct malidp_error_stats *error_stats,
+struct seq_file *m)
+{
+   seq_printf(m, "[%s] num_errors : %d\n", prefix,
+  atomic_read(_stats->num_errors));
+   seq_printf(m, "[%s] last_error_status  : 0x%08x\n", prefix,
+  atomic_read(_stats->last_error_status));
+   seq_printf(m, "[%s] last_error_vblank : %ld\n", prefix,
+  atomic64_read(_stats->last_error_vblank));
+}
+
+static int malidp_show_stats(struct seq_file *m, void *arg)
+{
+   struct drm_info_node *node = (struct drm_info_node *)m->private;
+   struct drm_device *drm = node->minor->dev;
+   struct malidp_drm *malidp = drm->dev_private;
+
+   malidp_error_stats_dump("DE", >de_errors, m);
+   malidp_error_stats_dump("SE", >se_errors, m);
+   return 0;
+}
+
+static struct drm_info_list malidp_debugfs_list[] = {
+   { "debug", malidp_show_stats, 0 },
+};


I think it would be pretty useful to have a way to reset the counters.
Maybe by just writing anything to the file?

Thanks,
-Brian


+
+static int malidp_debugfs_init(struct drm_minor *minor)
+{
+   struct malidp_drm *malidp = minor->dev->dev_private;
+
+   malidp_error_stats_init(>de_errors);
+   malidp_error_stats_init(>se_errors);
+   return drm_debugfs_create_files(malidp_debugfs_list,
+   ARRAY_SIZE(malidp_debugfs_list), minor->debugfs_root, minor);
+}
+
+#endif //CONFIG_DEBUG_FS
+
static struct drm_driver malidp_driver = {
.driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC |
   DRIVER_PRIME,
@@ -343,6 +401,9 @@ static struct drm_driver malidp_driver = {
.gem_prime_vmap = drm_gem_cma_prime_vmap,
.gem_prime_vunmap = drm_gem_cma_prime_vunmap,
.gem_prime_mmap = drm_gem_cma_prime_mmap,
+#ifdef CONFIG_DEBUG_FS
+   .debugfs_init = malidp_debugfs_init,
+#endif
.fops = ,
.name = "mali-dp",
.desc = "ARM Mali Display Processor driver",
diff --git a/drivers/gpu/drm/arm/malidp_drv.h b/drivers/gpu/drm/arm/malidp_drv.h
index c70989b..c49056c 100644
--- a/drivers/gpu/drm/arm/malidp_drv.h
+++ b/drivers/gpu/drm/arm/malidp_drv.h
@@ -18,6 +18,12 @@

Re: [PATCH] drm: mali-dp: Add debugfs file for reporting internal errors

[Liviu Dudau]

On Fri, May 11, 2018 at 06:56:03PM +0100, Alexandru Gheorghe wrote:
> Status register contains a lot of bits for reporting internal errors
> inside Mali DP. Currently, we just silently ignore all of the erorrs,
> that doesn't help when we are investigating different bugs, especially
> on the FPGA models which have a lot of constrains, so we could easily
> end up in AXI or underrun errors.
> 
> Add a new file called debug that contains an agregate of the
> errors reported by the Mali DP hardware.
> 
> E.g:
> [root@alarm ~]# cat /sys/kernel/debug/dri/1/debug
> [DE] num_errors : 167
> [DE] last_error_status  : 0x0001
> [DE] last_error_vblank : 385
> [SE] num_errors : 3
> [SE] last_error_status  : 0x00e23001
> [SE] last_error_vblank : 201
> 
> This a morphosis of the patch presented here [1], where the errors
> where reported continuously via trace_printk.
> 
> [1] https://lists.freedesktop.org/archives/dri-devel/2018-February/167042.html
> 
> Signed-off-by: Alexandru Gheorghe 

Acked-by: Liviu Dudau 

> ---
>  drivers/gpu/drm/arm/malidp_drv.c  | 61 
> +++
>  drivers/gpu/drm/arm/malidp_drv.h  | 15 ++
>  drivers/gpu/drm/arm/malidp_hw.c   | 46 -
>  drivers/gpu/drm/arm/malidp_hw.h   |  1 +
>  drivers/gpu/drm/arm/malidp_regs.h |  6 
>  5 files changed, 122 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c 
> b/drivers/gpu/drm/arm/malidp_drv.c
> index 8d20faa..70ce19a 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -17,6 +17,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -29,6 +30,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "malidp_drv.h"
>  #include "malidp_regs.h"
> @@ -327,6 +329,62 @@ static int malidp_dumb_create(struct drm_file *file_priv,
>   return drm_gem_cma_dumb_create_internal(file_priv, drm, args);
>  }
>  
> +#ifdef CONFIG_DEBUG_FS
> +
> +static void malidp_error_stats_init(struct malidp_error_stats *error_stats)
> +{
> + atomic_set(_stats->num_errors, 0);
> + atomic_set(_stats->last_error_status, 0);
> + atomic64_set(_stats->last_error_vblank, -1);
> +}
> +
> +void malidp_error(struct malidp_error_stats *error_stats, u32 status,
> +   u64 vblank)
> +{
> + atomic_set(_stats->last_error_status, status);
> + atomic64_set(_stats->last_error_vblank, vblank);
> + atomic_inc(_stats->num_errors);
> +}
> +
> +void malidp_error_stats_dump(const char *prefix,
> +  struct malidp_error_stats *error_stats,
> +  struct seq_file *m)
> +{
> + seq_printf(m, "[%s] num_errors : %d\n", prefix,
> +atomic_read(_stats->num_errors));
> + seq_printf(m, "[%s] last_error_status  : 0x%08x\n", prefix,
> +atomic_read(_stats->last_error_status));
> + seq_printf(m, "[%s] last_error_vblank : %ld\n", prefix,
> +atomic64_read(_stats->last_error_vblank));
> +}
> +
> +static int malidp_show_stats(struct seq_file *m, void *arg)
> +{
> + struct drm_info_node *node = (struct drm_info_node *)m->private;
> + struct drm_device *drm = node->minor->dev;
> + struct malidp_drm *malidp = drm->dev_private;
> +
> + malidp_error_stats_dump("DE", >de_errors, m);
> + malidp_error_stats_dump("SE", >se_errors, m);
> + return 0;
> +}
> +
> +static struct drm_info_list malidp_debugfs_list[] = {
> + { "debug", malidp_show_stats, 0 },
> +};
> +
> +static int malidp_debugfs_init(struct drm_minor *minor)
> +{
> + struct malidp_drm *malidp = minor->dev->dev_private;
> +
> + malidp_error_stats_init(>de_errors);
> + malidp_error_stats_init(>se_errors);
> + return drm_debugfs_create_files(malidp_debugfs_list,
> + ARRAY_SIZE(malidp_debugfs_list), minor->debugfs_root, minor);
> +}
> +
> +#endif //CONFIG_DEBUG_FS
> +
>  static struct drm_driver malidp_driver = {
>   .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC |
>  DRIVER_PRIME,
> @@ -343,6 +401,9 @@ static struct drm_driver malidp_driver = {
>   .gem_prime_vmap = drm_gem_cma_prime_vmap,
>   .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
>   .gem_prime_mmap = drm_gem_cma_prime_mmap,
> +#ifdef CONFIG_DEBUG_FS
> + .debugfs_init = malidp_debugfs_init,
> +#endif
>   .fops = ,
>   .name = "mali-dp",
>   .desc = "ARM Mali Display Processor driver",
> diff --git a/drivers/gpu/drm/arm/malidp_drv.h 
> b/drivers/gpu/drm/arm/malidp_drv.h
> index c70989b..c49056c 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.h
> +++ b/drivers/gpu/drm/arm/malidp_drv.h
> @@ -18,6 +18,12 @@
>  #include 
>  #include "malidp_hw.h"
>  
> +struct malidp_error_stats {
> + atomic_t num_errors;
> + atomic_t last_error_status;
> + atomic64_t last_error_vblank;
> +};
> +
>  struct malidp_drm 

RE: [Intel-gfx] [PATCH v3 24/40] drm/i915: Implement HDCP2.2 repeater authentication

[Shankar, Uma]

>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Ramalingam C
>Sent: Tuesday, April 3, 2018 7:28 PM
>To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
>jani.nik...@linux.intel.com; Winkler, Tomas ;
>Usyskin, Alexander 
>Cc: Vivi, Rodrigo 
>Subject: [Intel-gfx] [PATCH v3 24/40] drm/i915: Implement HDCP2.2 repeater
>authentication
>
>Implements the HDCP2.2 repeaters authentication steps such as verifying the
>downstream topology and sending stream management information.
>
>v2:
>  Rebased.
>v3:
>  No Changes.
>
>Signed-off-by: Ramalingam C 
>---
> drivers/gpu/drm/i915/intel_hdcp.c | 135
>++
> 1 file changed, 135 insertions(+)
>
>diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
>b/drivers/gpu/drm/i915/intel_hdcp.c
>index ee9b7519fe73..d70320da85e4 100644
>--- a/drivers/gpu/drm/i915/intel_hdcp.c
>+++ b/drivers/gpu/drm/i915/intel_hdcp.c
>@@ -1145,6 +1145,135 @@ static int hdcp2_session_key_exchange(struct
>intel_connector *connector)
>   return 0;
> }
>
>+/*
>+ * Lib endianness functions are aligned for 16/32/64 bits. Since here
>+sequence
>+ * num is 24bits developed a small conversion function.
>+ */
>+static inline void reverse_endianness(u8 *dest, size_t dst_sz, u8 *src)

This function is already defined and used in mei layer. Define this in some
common header file and use instead of duplicating it here.  May be in below 
file:  


>+{
>+  u32 index;
>+
>+  if (dest != NULL && dst_sz != 0) {
>+  for (index = 0; index < dst_sz && index < sizeof(u32);
>+   index++) {
>+  dest[dst_sz - index - 1] = src[index];
>+  }
>+  }
>+}
>+
>+static
>+int hdcp2_propagate_stream_management_info(struct intel_connector
>+*connector) {
>+  struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
>+  struct intel_hdcp *hdcp = >hdcp;
>+  union {
>+  struct hdcp2_rep_stream_manage stream_manage;
>+  struct hdcp2_rep_stream_ready stream_ready;
>+  } msgs;
>+  const struct intel_hdcp_shim *shim = hdcp->hdcp_shim;
>+  int ret;
>+
>+  /* Prepare RepeaterAuth_Stream_Manage msg */
>+  msgs.stream_manage.msg_id = HDCP_2_2_REP_STREAM_MANAGE;
>+  reverse_endianness(msgs.stream_manage.seq_num_m,
>HDCP_2_2_SEQ_NUM_LEN,
>+ (u8 *)>seq_num_m);
>+
>+  /* K no of streams is fixed as 1. Stored as big-endian. */
>+  msgs.stream_manage.k = __swab16(1);
>+
>+  /* For HDMI this is forced to be 0x0. For DP SST also this is 0x0. */
>+  msgs.stream_manage.streams[0].stream_id = 0;
>+  msgs.stream_manage.streams[0].stream_type = hdcp->content_type;
>+
>+  /* Send it to Repeater */
>+  ret = shim->write_2_2_msg(intel_dig_port, _manage,
>+sizeof(msgs.stream_manage));
>+  if (ret < 0)
>+  return ret;
>+
>+  ret = shim->read_2_2_msg(intel_dig_port,
>HDCP_2_2_REP_STREAM_READY,
>+   _ready,
>sizeof(msgs.stream_ready));
>+  if (ret < 0)
>+  return ret;
>+
>+  hdcp->mei_data.seq_num_m = hdcp->seq_num_m;
>+  hdcp->mei_data.streams[0].stream_type = hdcp->content_type;
>+
>+  ret = hdcp2_verify_mprime(hdcp, _ready);
>+  if (ret < 0)
>+  return ret;
>+
>+  hdcp->seq_num_m++;
>+
>+  if (hdcp->seq_num_m > HDCP_2_2_SEQ_NUM_MAX) {
>+  DRM_DEBUG_KMS("seq_num_m roll over.\n");
>+  return -1;
>+  }

Leave a blank line.

>+  return 0;
>+}
>+
>+static
>+int hdcp2_authenticate_repeater_topology(struct intel_connector
>+*connector) {
>+  struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
>+  struct intel_hdcp *hdcp = >hdcp;
>+  union {
>+  struct hdcp2_rep_send_receiverid_list recvid_list;
>+  struct hdcp2_rep_send_ack rep_ack;
>+  } msgs;
>+  const struct intel_hdcp_shim *shim = hdcp->hdcp_shim;
>+  uint8_t *rx_info;
>+  uint32_t seq_num_v;
>+  int ret;
>+
>+  ret = shim->read_2_2_msg(intel_dig_port,
>HDCP_2_2_REP_SEND_RECVID_LIST,
>+   _list, sizeof(msgs.recvid_list));
>+  if (ret < 0)
>+  return ret;
>+
>+  rx_info = msgs.recvid_list.rx_info;
>+
>+  if (HDCP_2_2_MAX_CASCADE_EXCEEDED(rx_info[1]) ||
>+  HDCP_2_2_MAX_DEVS_EXCEEDED(rx_info[1])) {
>+  DRM_DEBUG_KMS("Topology Max Size Exceeded\n");
>+  return -1;
>+  }
>+
>+  /* Converting and Storing the seq_num_v to local variable as DWORD */
>+  reverse_endianness((u8 *)_num_v, HDCP_2_2_SEQ_NUM_LEN,
>+ msgs.recvid_list.seq_num_v);
>+
>+  if (seq_num_v < hdcp->seq_num_v) {
>+  

Re: [PATCH] gpu: drm: qxl: Adding new typedef vm_fault_t

[Gerd Hoffmann]

  Hi,

> > So my expectation that a backmerge happens anyway after -rc1/2 is in
> > line with reality, it is just to be delayed this time.  I'll stay
> > tuned ;)
> 
> Is this patch already merged in drm-misc-next tree ?

Pushed now.

cheers,
  Gerd

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

Re: [PATCH 2/2] drm/tegra: Acquire a reference to the IOVA cache

[Thierry Reding]

On Mon, Apr 23, 2018 at 11:43:16AM +0300, Dmitry Osipenko wrote:
> On 23.04.2018 11:41, Dmitry Osipenko wrote:
> > On 23.04.2018 11:34, Dmitry Osipenko wrote:
> >> On 23.04.2018 09:57, Thierry Reding wrote:
> >>> From: Thierry Reding 
> >>>
> >>> The IOVA API uses a memory cache to allocate IOVA nodes from. To make
> >>> sure that this cache is available, obtain a reference to it and release
> >>> the reference when the cache is no longer needed.
> >>>
> >>> On 64-bit ARM this is hidden by the fact that the DMA mapping API gets
> >>> that reference and never releases it. On 32-bit ARM, however, the DMA
> >>> mapping API doesn't do that, so allocation of IOVA nodes fails.
> >>>
> >>> Signed-off-by: Thierry Reding 
> >>> ---
> >>
> >> Reviewed-by: Dmitry Osipenko 
> >> Tested-by: Dmitry Osipenko 
> >>
> >> CONFIG_TEGRA_IOMMU_SMMU is enabled in the default kernel configs and hence 
> >> DRM
> >> should fail to probe on t124 since 4.11. What about to add stable tag for 
> >> v4.11+
> >> here to unbreak stable kernels as well?
> > 
> > IOMMU node for host1x was added to t124 DT in kernel v4.14, so s/4.11/4.14/.
> 
> On the other hand nothing stops to use newer DT with older kernel.

I've applied this and added:

Fixes: ad92601521ea ("drm/tegra: Add Tegra DRM allocation API")

Since that's the commit that introduced the iova API usage. It seems
like we also need a fix in drivers/gpu/host1x to grab a reference to
this IOVA cache because the host1x driver also makes use of that. It
looks as if this patch currently papers over that bug, and there's
very little chance that anyone will use the host1x driver without the
Tegra DRM driver. However, it's probably best to still fix it to avoid
future exposure.

I'll go type that patch up now.

Thierry


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

Re: [PATCH 1/2] drm/tegra: Fix order of teardown in IOMMU case

[Thierry Reding]

On Mon, Apr 23, 2018 at 11:35:14AM +0300, Dmitry Osipenko wrote:
> On 23.04.2018 09:57, Thierry Reding wrote:
> > From: Thierry Reding 
> > 
> > The original code works fine, this is merely a cosmetic change to make
> > the teardown order the reverse of the setup order.
> > 
> > Signed-off-by: Thierry Reding 
> Reviewed-by: Dmitry Osipenko 

Applied, thanks.

Thierry


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

Re: [PATCH v1] gpu: host1x: Fix dma_free_wc() argument in the error path

[Thierry Reding]

On Mon, Apr 23, 2018 at 12:54:56PM +0300, Dmitry Osipenko wrote:
> If IOVA allocation or IOMMU mapping fails, dma_free_wc() is invoked with
> size=0 because of a typo, that triggers "kernel BUG at mm/vmalloc.c:124!".
> 
> Signed-off-by: Dmitry Osipenko 
> ---
>  drivers/gpu/host1x/cdma.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied, thanks.

Thierry


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

Re: [PATCH] gpu: host1x: Fix compiler errors

[Thierry Reding]

On Mon, Mar 26, 2018 at 04:44:14PM +0200, Emil Goode wrote:
> The compiler is complaining with the following errors:
> 
> drivers/gpu/host1x/cdma.c:94:48: error:
>   passing argument 3 of ‘dma_alloc_wc’ from incompatible pointer type
>   [-Werror=incompatible-pointer-types]
> 
> drivers/gpu/host1x/cdma.c:113:48: error:
>   passing argument 3 of ‘dma_alloc_wc’ from incompatible pointer type
>   [-Werror=incompatible-pointer-types]
> 
> The expected pointer type of the third argument to dma_alloc_wc() is
> dma_addr_t but phys_addr_t is passed. Fix this by adding casts to the
> expected pointer type.
> 
> Signed-off-by: Emil Goode 
> ---
>  drivers/gpu/host1x/cdma.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/host1x/cdma.c b/drivers/gpu/host1x/cdma.c
> index 28541b280739..5e8b321a751e 100644
> --- a/drivers/gpu/host1x/cdma.c
> +++ b/drivers/gpu/host1x/cdma.c
> @@ -91,8 +91,8 @@ static int host1x_pushbuffer_init(struct push_buffer *pb)
>  
>   size = iova_align(>iova, size);
>  
> - pb->mapped = dma_alloc_wc(host1x->dev, size, >phys,
> -   GFP_KERNEL);
> + pb->mapped = dma_alloc_wc(host1x->dev, size,
> +   (dma_addr_t *)>phys, GFP_KERNEL);
>   if (!pb->mapped)
>   return -ENOMEM;
>  
> @@ -110,8 +110,8 @@ static int host1x_pushbuffer_init(struct push_buffer *pb)
>   if (err)
>   goto iommu_free_iova;
>   } else {
> - pb->mapped = dma_alloc_wc(host1x->dev, size, >phys,
> -   GFP_KERNEL);
> + pb->mapped = dma_alloc_wc(host1x->dev, size,
> +   (dma_addr_t *)>phys, GFP_KERNEL);
>   if (!pb->mapped)
>   return -ENOMEM;
>  

This doesn't seem right. There's no guarantee that phys_addr_t and
dma_addr_t will be compatible, so the above isn't always correct. Also,
I don't see a need for pb->phys to ever be phys_addr_t. It's allocated
through dma_alloc_wc() exclusively, so it should just be dma_addr_t.

Note that the !pb->phys check in host1x_pushbuffer_destroy() becomes
technically wrong if pb->phys is dma_addr_t (0 is a perfectly valid
value for dma_addr_t), so make sure to flip that to !pb->mapped instead.
pb->mapped and pb->phys are always set in tandem, and checking mapped
for non-NULL is the right check to test whether the pair is valid or
not.

Thierry


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

Re: [PATCH 09/21] arm64: dts: allwinner: a64: Add HDMI support

[Maxime Ripard]

On Mon, May 14, 2018 at 02:03:36PM +0530, Jagan Teki wrote:
> On Wed, May 2, 2018 at 5:04 PM, Maxime Ripard  
> wrote:
> > Hi,
> >
> > On Mon, Apr 30, 2018 at 05:10:46PM +0530, Jagan Teki wrote:
> >> + hdmi_phy: hdmi-phy@1ef {
> >> + compatible = "allwinner,sun50i-a64-hdmi-phy",
> >> +  "allwinner,sun8i-h3-hdmi-phy";
> >> + reg = <0x01ef 0x1>;
> >> + clocks = < CLK_BUS_HDMI>, < CLK_HDMI_DDC>,
> >> +  < CLK_PLL_VIDEO1>;
> >
> > You were discussing that the PLL0 could also be used to clock the PHY,
> > has that been figured out?
> 
> This is what I understand from Fig: 3-3. Module Clock Diagram, both
> tcon0 and tcon1 are using HDMI. I'm thinking based on the tcon
> configuration we need use proper PLL or some logic to get common PLL
> don't know yet. Since this series adding tcon1 I've attached PLL1.

You're not describing the TCON node here though, but the HDMI one, and
the HDMI block is listed in both the PLL video 0 and 1.

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