Re: [PATCH v3 2/2] drm/fb-helper: implement ioctl FBIO_WAITFORVSYNC

[Michel Dänzer]

On 21/02/17 07:00 PM, Stefan Lengfeld wrote:
> 
> 2/ Wait for a single vsync event on all active crtcs as Ville Syrjälä 
>described here [2] in the optimal implementation.

FWIW, this seems like a bad idea, since with multiple active CRTCs it
would make it essentially random at which intervals the ioctl returns,
and which CRTCs are in vertical blank when it does. So it would be
useless for both timing and tearing prevention purposes, i.e. more or
less completely useless.


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

Re: [Intel-gfx] [PATCH v3 4/8] drm: Add driver-private objects to atomic state

[Archit Taneja]

On 02/22/2017 05:31 AM, Pandiyan, Dhinakaran wrote:

On Fri, 2017-02-17 at 15:37 +0530, Archit Taneja wrote:


On 02/16/2017 05:43 AM, Pandiyan, Dhinakaran wrote:

On Wed, 2017-02-15 at 16:53 +0530, Archit Taneja wrote:

Hi,

On 02/09/2017 12:08 PM, Dhinakaran Pandiyan wrote:

It is necessary to track states for objects other than connector, crtc
and plane for atomic modesets. But adding objects like DP MST link
bandwidth to drm_atomic_state would mean that a non-core object will be
modified by the core helper functions for swapping and clearing
it's state. So, lets add void * objects and helper functions that operate
on void * types to keep these objects and states private to the core.
Drivers can then implement specific functions to swap and clear states.
The other advantage having just void * for these objects in
drm_atomic_state is that objects of different types can be managed in the
same state array.

v2: Added docs and new iterator to filter private objects (Daniel)

Suggested-by: Daniel Vetter 
Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/drm_atomic.c| 68 +++
 drivers/gpu/drm/drm_atomic_helper.c |  5 ++
 include/drm/drm_atomic.h| 91 +
 3 files changed, 164 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index a567310..1a9ffe8 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -57,6 +57,7 @@ void drm_atomic_state_default_release(struct drm_atomic_state 
*state)
kfree(state->connectors);
kfree(state->crtcs);
kfree(state->planes);
+   kfree(state->private_objs);
 }
 EXPORT_SYMBOL(drm_atomic_state_default_release);

@@ -184,6 +185,20 @@ void drm_atomic_state_default_clear(struct 
drm_atomic_state *state)
state->planes[i].ptr = NULL;
state->planes[i].state = NULL;
}
+
+   for (i = 0; i < state->num_private_objs; i++) {
+   void *private_obj = state->private_objs[i].obj;
+   void *obj_state = state->private_objs[i].obj_state;
+
+   if (!private_obj)
+   continue;
+
+   state->private_objs[i].funcs->destroy_state(obj_state);
+   state->private_objs[i].obj = NULL;
+   state->private_objs[i].obj_state = NULL;
+   state->private_objs[i].funcs = NULL;
+   }
+
 }
 EXPORT_SYMBOL(drm_atomic_state_default_clear);

@@ -974,6 +989,59 @@ static void drm_atomic_plane_print_state(struct 
drm_printer *p,
 }

 /**
+ * drm_atomic_get_private_obj_state - get private object state
+ * @state: global atomic state
+ * @obj: private object to get the state for
+ * @funcs: pointer to the struct of function pointers that identify the object
+ * type
+ *
+ * This function returns the private object state for the given private object,
+ * allocating the state if needed. It does not grab any locks as the caller is
+ * expected to care of any required locking.
+ *
+ * RETURNS:
+ *
+ * Either the allocated state or the error code encoded into a pointer.
+ */
+void *
+drm_atomic_get_private_obj_state(struct drm_atomic_state *state, void *obj,
+ const struct drm_private_state_funcs *funcs)
+{
+   int index, num_objs, i;
+   size_t size;
+   struct __drm_private_objs_state *arr;
+
+   for (i = 0; i < state->num_private_objs; i++)
+   if (obj == state->private_objs[i].obj &&
+   state->private_objs[i].obj_state)
+   return state->private_objs[i].obj_state;


Comparing this func to drm_atomic_get_plane_state/drm_atomic_get_crtc_state, it
doesn't seem to call drm_modeset_lock if the obj_state doesn't already exist. I
don't understand the locking stuff toowell, I just noticed this difference when
comparing this approach with what is done in the msm kms driver (where we
have subclassed drm_atomic_state to msm_kms_state).

Thanks,
Archit




The caller is expected to take care of any required locking. The
driver-private objects are opaque from core's pov, so the core is not
aware of necessary locks for that object type.


I had a look at the rest of the series, and I couldn't easily understand
whether the caller code protects the MST related driver private state. Is
it expected to be protect via the drm_mode_config.connection_mutex lock?

Thanks,
Archit



That's right, the connection_mutex takes care of the locking for the MST
private state. I can add that as a comment to the caller's (MST helper)
kernel doc with a

WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex));


That would be nice to have.

In the comment: "It does not grab any locks as the caller is expected to
care of any required locking.", you could maybe be a bit more specific
and rephrase it as "the caller needs to grab the _modeset_lock
responsible for protecting the private object 

[Bug 194645] amdgpu: amdgpu_resume failed

[bugzilla-daemon]

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

--- Comment #10 from Michel Dänzer (mic...@daenzer.net) ---
(In reply to Mateusz Lenik from comment #6)
> Can incremental builds (that means without clean/distclean, just building
> whatever files have changed) have some effect on bisect outcome?

It's more likely that the problem doesn't always occur even with an affected
commit, and that you therefore accidentally incorrectly declared some commits
as good. Try suspending / resuming multiple times, maybe even rebooting a
couple of times in between, before declaring a commit as good.

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

Re: [RESEND PATCH v7 0/7] Rockchip dw-mipi-dsi driver

[Chris Zhong]

Hi Sean

On 02/21/2017 11:39 PM, Sean Paul wrote:

On Mon, Feb 20, 2017 at 04:02:16PM +0800, Chris Zhong wrote:

Hi all

[Resend this v7 version series, since there are 5 mails have gone missing, last
week]

This version does not change the existing v6 patches, just to add the
"bandwidth fix" patch back, since we really need it.

This patch serial is for RK3399 MIPI DSI. The MIPI DSI controller of
RK3399 is almost the same as RK3288, except a little bit of difference
in phy clock controlling and port id selection register. These patches
add RK3399 support and the power domain support.

And these patches base on John Keeping's v3 patches[0], it fixes many bugs,
they have been tested on rk3288 evb board.

Do we have an ETA on when John is planning on respinning his patchset based on
review feedback?

I guess John will send the v4 patch soon, since there are not many point 
need to change.
And as I know, Mark Yao is going to merge John's v4 series to his 
branch, and this v7 series

will be merged after that.



[0]:
[01/24] https://patchwork.kernel.org/patch/9544089
[02/24] https://patchwork.kernel.org/patch/9544061
[03/24] https://patchwork.kernel.org/patch/9544065
[04/24] https://patchwork.kernel.org/patch/9544077
[05/24] https://patchwork.kernel.org/patch/9544033
[06/24] https://patchwork.kernel.org/patch/9544037
[07/24] https://patchwork.kernel.org/patch/9544029
[08/24] https://patchwork.kernel.org/patch/9544031
[09/24] https://patchwork.kernel.org/patch/9544083
[10/24] https://patchwork.kernel.org/patch/9544063
[11/24] https://patchwork.kernel.org/patch/9544085
[12/24] https://patchwork.kernel.org/patch/9544093
[13/24] https://patchwork.kernel.org/patch/9544081
[14/24] https://patchwork.kernel.org/patch/9544057
[15/24] https://patchwork.kernel.org/patch/9544079
[16/24] https://patchwork.kernel.org/patch/9544035
[17/24] https://patchwork.kernel.org/patch/9544105
[18/24] https://patchwork.kernel.org/patch/9544059
[21/24] https://patchwork.kernel.org/patch/9544009
[22/24] https://patchwork.kernel.org/patch/9544049
[23/24] https://patchwork.kernel.org/patch/9544055
[24/24] https://patchwork.kernel.org/patch/9544109


Changes in v6:
- no need check phy_cfg_clk before enable/disable

Changes in v5:
- check the error of phy_cfg_clk in dw_mipi_dsi_bind

Changes in v4:
- remove the unrelated change

Changes in v3:
- base on John Keeping's patch series

Chris Zhong (7):
   dt-bindings: add rk3399 support for dw-mipi-rockchip
   drm/rockchip/dsi: dw-mipi: support RK3399 mipi dsi
   drm/rockchip/dsi: dw-mipi: correct the coding style
   drm/rockchip/dsi: remove mode_valid function
   dt-bindings: add power domain node for dw-mipi-rockchip
   drm/rockchip/dsi: fix insufficient bandwidth of some panel
   drm/rockchip/dsi: add dw-mipi power domain support

  .../display/rockchip/dw_mipi_dsi_rockchip.txt  |   7 +-
  drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 160 -
  2 files changed, 100 insertions(+), 67 deletions(-)

--
2.6.3

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


--
Chris Zhong


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

Re: [PATCH v10 0/3] Add support for the S6E3HA2 panel on TM2 board

[Hoegeun Kwon]

Hi all,


This patchset is resent patchset.

Because I have a missing TO, CC, I sent it again.

Sorry, I will send it in the correct format next time.


Best Regards,

Hoegeun


On 02/22/2017 10:09 AM, Hoegeun Kwon wrote:

Dear Thierry,

I understand that your opinion is:
It is better to handle the error every time it is input to the
register, rather than error handling at once in the struct using
error. This not only makes the code easier to maintain, but also
reduces unnecessary computation.

So I modified the panel driver to code-by-code error handling.
If this is not your opinion, could you tell me what your opinion?

Best Regards,
Hoegeun


Changes for V10:
- Fixed code-by-code error handling.

Changes for V9:
- Fixed the te-gpio to optional in bindings

Changes for V8:
- Applied below two patches: (drm/exynos)
  : drm/exynos: mic: Add mode_set callback function
  : drm/exynos: mic: Fix parse_dt function
- The dt-binding patch and driver patch were divided.
- Rebase these patches on samsung SoC tree[1] and tm2 touckey patch[2].

Change for V7:
- Fixed the mode_set callback function of mic device driver.
  because the mic register is initialized when entering suspend
  mode, so should set the reg value whenever pre_enable is
  called.

Changes for V6:
- Fixed the parse_dt function of dsi device driver.
- Removed OF graph of panel in DT and DT binding document.
- Fixed the s6e3ha2 panel device driver.
  - Fixed from number size to ARRAY_SIZE().
  - Fixed error handling in mipi_dsi_dcs_* functions.
  - Fixed the clock of display_mode.
  - Removed unnecessary casting and error log.

Change for V5:
- The V5 has only one fix in V4 below.
- Removed the enable check of the mic driver in mode_set
  callback, because mode_set should be performed every time.

Changes for V4:
- Removed display-timings in devicetree, the display-timings has
  been fixed to be provided by the device driver.
- Added the mode_set callback function into exynos_drm_mic,
  because the exynos_drm_mic driver can not parse a videomode
  struct by removing the display-timings from the devicetree.

Changes for V3:
- In the DT binding document, made it clearly that the panel is a
  child node of dsi.
- Fix reset-gpio active from high to low.
- Is the OF graph saying related to patch2?
  Althogh the panel is a child of dsi, I think OF graph necessary.
  because if a remote-endpoint is not specified, the dsi also
  panel is not probed.
- The display-timings has been fixed to be provided by the device
  driver. however, I think display-timings is necessary in dts.
  because if dts does not have display-timings, dsi will not load.

Changes for V2:
- Fixed the samsung,s6e3ha2.txt DT document.
  - Added active high or low after the description of the GPIOs.
  - Removed the reg and added a description of the virtual
channel number of a DSI peripheral.

Depends on:
[1] https://git.kernel.org/cgit/linux/kernel/git/krzk/linux.git/ 
(for-next branch)

[2] https://patchwork.kernel.org/patch/9504131/
- ("arm64: dts: exynos: Add tm2 touchkey node")

Hoegeun Kwon (2):
  dt-bindings: Add support for samsung s6e3ha2 panel binding
  drm/panel: Add support for S6E3HA2 panel driver on TM2 board

Hyungwon Hwang (1):
  arm64: dts: exynos: Add support for S6E3HA2 panel device on TM2 board

 .../bindings/display/panel/samsung,s6e3ha2.txt |  28 +
 arch/arm64/boot/dts/exynos/exynos5433-tm2.dts  |  12 +
 drivers/gpu/drm/panel/Kconfig  |   6 +
 drivers/gpu/drm/panel/Makefile |   1 +
 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c  | 739 
+

 5 files changed, 786 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt

 create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c



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

[Bug 95306] Random Blank(black) screens on "Carrizo"

[bugzilla-daemon]

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

--- Comment #61 from Jaime Rodrigo  ---
(In reply to Jaime Rodrigo from comment #60)
> Tried every RC8 and it blackouts too. Official 4.10 release boots into low
> graphics mode by default, and theres no kernel driver in use (nor radeon or
> amdgpu). Installed AMDGPUPRO and I get stuck in the logging screen (after
> logging successfully it goes back to the logging screen and so on), and
> still using low graphics mode

Tried RC8*

-- 
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] drm: Add DPCD definitions for DP 1.4 DSC feature

[Navare, Manasi D]

On Fri, 17 Feb 2017, Manasi Navare  wrote:
> Display stream compression is supported on DP 1.4 DP devices. This 
> patch adds the corersponding DPCD register definitions for DSC.
>
> v2:
> * Rebased on drm-tip
>
> Signed-off-by: Manasi Navare 
> Cc: Jani Nikula 
> Cc: Paulo Zanoni 
> Cc: dri-devel@lists.freedesktop.org

Tedious work to cross check this stuff against the spec... found one real 
issue; while at it please fix a few nitpicks that I would otherwise have 
ignored.

BR,
Jani.


> ---
>  include/drm/drm_dp_helper.h | 102 
> 
>  1 file changed, 102 insertions(+)
>
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h 
> index ba89295..4c1fc26 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -179,6 +179,108 @@
>  
>  #define DP_GUID  0x030   /* 1.2 */
>  
> +#define DP_DSC_SUPPORT  0x060   /* DP 1.4 */
> +# define DP_DSC_DECOMPRESSION_IS_SUPPORTED  (1 << 0)
> +
> +#define DP_DSC_REV  0x061
> +# define DP_DSC_MAJOR_MASK  (15 << 0)
> +# define DP_DSC_MINOR_MASK  (15 << 4)
> +# define DP_DSC_MINOR_SHIFT 4

Nitpick: Hex is preferred for masks. Same for all masks below. MAJOR_SHIFT for 
completeness.

So should I add the MAJOR_SHIFT as well even though it will just 0?


> +
> +#define DP_DSC_RC_BUF_BLK_SIZE  0x062
> +# define DP_DSC_RC_BUF_BLK_SIZE_1   0x0
> +# define DP_DSC_RC_BUF_BLK_SIZE_4   0x1
> +# define DP_DSC_RC_BUF_BLK_SIZE_16  0x2
> +# define DP_DSC_RC_BUF_BLK_SIZE_64  0x3
> +
> +#define DP_DSC_RC_BUF_SIZE  0x063
> +
> +#define DP_DSC_SLICE_CAP_1  0x064
> +# define DP_DSC_1_PER_DP_DSC_SINK   (1 << 0)
> +# define DP_DSC_2_PER_DP_DSC_SINK   (1 << 1)
> +# define DP_DSC_4_PER_DP_DSC_SINK   (1 << 3)
> +# define DP_DSC_6_PER_DP_DSC_SINK   (1 << 4)
> +# define DP_DSC_8_PER_DP_DSC_SINK   (1 << 5)
> +# define DP_DSC_10_PER_DP_DSC_SINK  (1 << 6)
> +# define DP_DSC_12_PER_DP_DSC_SINK  (1 << 7)
> +
> +#define DP_DSC_LINE_BUF_BIT_DEPTH   0x065
> +# define DP_DSC_LINE_BUF_BIT_DEPTH_MASK (15 << 0)
> +# define DP_DSC_LINE_BUF_BIT_DEPTH_90x0
> +# define DP_DSC_LINE_BUF_BIT_DEPTH_10   0x1
> +# define DP_DSC_LINE_BUF_BIT_DEPTH_11   0x2
> +# define DP_DSC_LINE_BUF_BIT_DEPTH_12   0x3
> +# define DP_DSC_LINE_BUF_BIT_DEPTH_13   0x4
> +# define DP_DSC_LINE_BUF_BIT_DEPTH_14   0x5
> +# define DP_DSC_LINE_BUF_BIT_DEPTH_15   0x6
> +# define DP_DSC_LINE_BUF_BIT_DEPTH_16   0x7
> +# define DP_DSC_LINE_BUF_BIT_DEPTH_80x8
> +
> +#define DP_DSC_BLK_PREDICTION_SUPPORT   0x066
> +# define DP_DSC_BLK_PREDICTION_IS_SUPPORTED (1 << 0)
> +
> +#define DP_DSC_MAX_BITS_PER_PIXEL_LOW   0x067   /* eDP 1.4 */
> +
> +#define DP_DSC_MAX_BITS_PER_PIXEL_HI0x068   /* eDP 1.4 */
> +
> +#define DP_DSC_DEC_COLOR_FORMAT_CAP 0x069
> +# define DP_DSC_RGB (1 << 0)
> +# define DP_DSC_YCbCr444(1 << 1)
> +# define DP_DSC_YCbCr422_Simple (1 << 2)
> +# define DP_DSC_YCbCr422_Native (1 << 3)
> +# define DP_DSC_YCbCr420_Native (1 << 4)
> +
> +#define DP_DSC_DEC_COLOR_DEPTH_CAP  0x06A
> +# define DP_DSC_8_BPC   (1 << 1)
> +# define DP_DSC_10_BPC  (1 << 2)
> +# define DP_DSC_12_BPC  (1 >> 3)

Oops, shifting to wrong direction!

Oops, yes that is my mistake, I will fix the shift direction.

> +
> +#define DP_DSC_PEAK_THROUGHPUT  0x06B
> +# define DP_DSC_THROUGHPUT_MODE_0_340   0x1
> +# define DP_DSC_THROUGHPUT_MODE_0_400   0x2
> +# define DP_DSC_THROUGHPUT_MODE_0_450   0x3
> +# define DP_DSC_THROUGHPUT_MODE_0_500   0x4
> +# define DP_DSC_THROUGHPUT_MODE_0_550   0x5
> +# define DP_DSC_THROUGHPUT_MODE_0_600   0x6
> +# define DP_DSC_THROUGHPUT_MODE_0_650   0x7
> +# define DP_DSC_THROUGHPUT_MODE_0_700   0x8
> +# define DP_DSC_THROUGHPUT_MODE_0_750   0x9
> +# define DP_DSC_THROUGHPUT_MODE_0_800   0xA
> +# define DP_DSC_THROUGHPUT_MODE_0_850   0xB
> +# define DP_DSC_THROUGHPUT_MODE_0_900   0xC
> +# define DP_DSC_THROUGHPUT_MODE_0_950   0xD
> +# define DP_DSC_THROUGHPUT_MODE_0_1000  0xE

Nitpick: MODE_0_MASK and MODE_0_SHIFT for completeness. Seems inconsistent to 
use hex for MODE_0 values and dec for MODE_1 values.

For Mode 0, it would be all these values shifted by 0, should I add the shifts 
by 0 for consistency with 
MODE_1?
And yes I will add MODE_0 MASK and SHIFT.

Regards
Manasi

> +# define DP_DSC_THROUGHPUT_MODE_1_MASK  (15 << 4)
> +# define DP_DSC_THROUGHPUT_MODE_1_SHIFT 4
> +# define 

[PATCH v10 3/3] arm64: dts: exynos: Add support for S6E3HA2 panel device on TM2 board

[Hoegeun Kwon]

From: Hyungwon Hwang 

This patch add the panel device tree node for S6E3HA2 display
controller to TM2 dts.

Signed-off-by: Hyungwon Hwang 
Signed-off-by: Andrzej Hajda 
Signed-off-by: Chanwoo Choi 
Signed-off-by: Hoegeun Kwon 
Tested-by: Chanwoo Choi 
---
 arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts 
b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts

index dea0a6f..db3fed2 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
@@ -52,6 +52,18 @@
assigned-clock-rates = <25000>, <4>;
 };
 + {
+   panel@0 {
+   compatible = "samsung,s6e3ha2";
+   reg = <0>;
+   vdd3-supply = <_reg>;
+   vci-supply = <_reg>;
+   reset-gpios = < 0 GPIO_ACTIVE_LOW>;
+   enable-gpios = < 5 GPIO_ACTIVE_HIGH>;
+   te-gpios = < 3 GPIO_ACTIVE_HIGH>;
+   };
+};
+
 _9 {
status = "okay";
 -- 1.9.1



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

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

[Hoegeun Kwon]

The Samsung s6e3ha2 is a 5.7" 1440x2560 AMOLED panel connected
using MIPI-DSI interfaces.

Signed-off-by: Donghwa Lee 
Signed-off-by: Hyungwon Hwang 
Signed-off-by: Hoegeun Kwon 
Reviewed-by: Andrzej Hajda 
Acked-by: Rob Herring 
---
 .../bindings/display/panel/samsung,s6e3ha2.txt | 28 
++

 1 file changed, 28 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt


diff --git 
a/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt 
b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt

new file mode 100644
index 000..18854f4
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
@@ -0,0 +1,28 @@
+Samsung S6E3HA2 5.7" 1440x2560 AMOLED panel
+
+Required properties:
+  - compatible: "samsung,s6e3ha2"
+  - reg: the virtual channel number of a DSI peripheral
+  - vdd3-supply: I/O voltage supply
+  - vci-supply: voltage supply for analog circuits
+  - reset-gpios: a GPIO spec for the reset pin (active low)
+  - enable-gpios: a GPIO spec for the panel enable pin (active high)
+
+Optional properties:
+  - te-gpios: a GPIO spec for the tearing effect synchronization signal
+gpio pin (active high)
+
+Example:
+ {
+   ...
+
+   panel@0 {
+   compatible = "samsung,s6e3ha2";
+   reg = <0>;
+   vdd3-supply = <_reg>;
+   vci-supply = <_reg>;
+   reset-gpios = < 0 GPIO_ACTIVE_LOW>;
+   enable-gpios = < 5 GPIO_ACTIVE_HIGH>;
+   te-gpios = < 3 GPIO_ACTIVE_HIGH>;
+   };
+};
--
1.9.1



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

[PATCH v10 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

[Hoegeun Kwon]

This patch add support for MIPI-DSI based S6E3HA2 AMOLED panel
driver. This panel has 1440x2560 resolution in 5.7-inch physical
panel in the TM2 device.

Signed-off-by: Donghwa Lee 
Signed-off-by: Hyungwon Hwang 
Signed-off-by: Hoegeun Kwon 
Tested-by: Chanwoo Choi 
Reviewed-by: Andrzej Hajda 
---
 drivers/gpu/drm/panel/Kconfig |   6 +
 drivers/gpu/drm/panel/Makefile|   1 +
 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c | 739 
++

 3 files changed, 746 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 62aba97..d913c83 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -52,6 +52,12 @@ config DRM_PANEL_PANASONIC_VVX10F034N00
  WUXGA (1920x1200) Novatek NT1397-based DSI panel as found in some
  Xperia Z2 tablets
 +config DRM_PANEL_SAMSUNG_S6E3HA2
+   tristate "Samsung S6E3HA2 DSI video mode panel"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   select VIDEOMODE_HELPERS
+
 config DRM_PANEL_SAMSUNG_S6E8AA0
tristate "Samsung S6E8AA0 DSI video mode panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index a5c7ec0..1d483b0 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += 
panel-jdi-lt070me05000.o

 obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
 obj-$(CONFIG_DRM_PANEL_PANASONIC_VVX10F034N00) += 
panel-panasonic-vvx10f034n00.o

 obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += panel-samsung-ld9040.o
+obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E3HA2) += panel-samsung-s6e3ha2.o
 obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0) += panel-samsung-s6e8aa0.o
 obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
 obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c 
b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c

new file mode 100644
index 000..4cc08d7
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
@@ -0,0 +1,739 @@
+/*
+ * MIPI-DSI based s6e3ha2 AMOLED 5.7 inch panel driver.
+ *
+ * Copyright (c) 2016 Samsung Electronics Co., Ltd.
+ * Donghwa Lee 
+ * Hyungwon Hwang 
+ * Hoegeun Kwon 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define S6E3HA2_MIN_BRIGHTNESS 0
+#define S6E3HA2_MAX_BRIGHTNESS 100
+#define S6E3HA2_DEFAULT_BRIGHTNESS 80
+
+#define S6E3HA2_NUM_GAMMA_STEPS46
+#define S6E3HA2_GAMMA_CMD_CNT  35
+#define S6E3HA2_VINT_STATUS_MAX10
+
+static const u8 
gamma_tbl[S6E3HA2_NUM_GAMMA_STEPS][S6E3HA2_GAMMA_CMD_CNT] = {

+   { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x82, 0x83,
+ 0x85, 0x88, 0x8b, 0x8b, 0x84, 0x88, 0x82, 0x82, 0x89, 0x86, 0x8c,
+ 0x94, 0x84, 0xb1, 0xaf, 0x8e, 0xcf, 0xad, 0xc9, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+   { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x84, 0x84,
+ 0x85, 0x87, 0x8b, 0x8a, 0x84, 0x88, 0x82, 0x82, 0x89, 0x86, 0x8a,
+ 0x93, 0x84, 0xb0, 0xae, 0x8e, 0xc9, 0xa8, 0xc5, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+   { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x83, 0x83,
+ 0x85, 0x86, 0x8a, 0x8a, 0x84, 0x88, 0x81, 0x84, 0x8a, 0x88, 0x8a,
+ 0x91, 0x84, 0xb1, 0xae, 0x8b, 0xd5, 0xb2, 0xcc, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+   { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x83, 0x83,
+ 0x85, 0x86, 0x8a, 0x8a, 0x84, 0x87, 0x81, 0x84, 0x8a, 0x87, 0x8a,
+ 0x91, 0x85, 0xae, 0xac, 0x8a, 0xc3, 0xa3, 0xc0, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+   { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x88, 0x86, 0x87, 0x85, 0x85,
+ 0x86, 0x85, 0x88, 0x89, 0x84, 0x89, 0x82, 0x84, 0x87, 0x85, 0x8b,
+ 0x91, 0x88, 0xad, 0xab, 0x8a, 0xb7, 0x9b, 0xb6, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+   { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x83, 0x83,
+ 0x85, 0x86, 0x89, 0x8a, 0x84, 0x89, 0x83, 0x83, 0x86, 0x84, 0x8b,
+ 0x90, 0x84, 0xb0, 0xae, 0x8b, 0xce, 0xad, 0xc8, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+   { 0x00, 0xb8, 0x00, 0xc3, 0x00, 0xb1, 0x89, 0x87, 0x87, 0x83, 0x83,
+ 0x85, 0x87, 0x89, 0x8a, 0x83, 0x87, 0x82, 0x85, 0x88, 0x87, 0x89,
+ 0x8f, 0x84, 0xac, 0xaa, 0x89, 0xb1, 0x98, 0xaf, 0x00, 0x00, 0x00,
+ 0x00, 0x00 },
+   { 0x00, 0xb8, 

[PATCH v10 0/3] Add support for the S6E3HA2 panel on TM2 board

[Hoegeun Kwon]

Dear Thierry,

I understand that your opinion is:
It is better to handle the error every time it is input to the
register, rather than error handling at once in the struct using
error. This not only makes the code easier to maintain, but also
reduces unnecessary computation.

So I modified the panel driver to code-by-code error handling.
If this is not your opinion, could you tell me what your opinion?

Best Regards,
Hoegeun


Changes for V10:
- Fixed code-by-code error handling.

Changes for V9:
- Fixed the te-gpio to optional in bindings

Changes for V8:
- Applied below two patches: (drm/exynos)
  : drm/exynos: mic: Add mode_set callback function
  : drm/exynos: mic: Fix parse_dt function
- The dt-binding patch and driver patch were divided.
- Rebase these patches on samsung SoC tree[1] and tm2 touckey patch[2].

Change for V7:
- Fixed the mode_set callback function of mic device driver.
  because the mic register is initialized when entering suspend
  mode, so should set the reg value whenever pre_enable is
  called.

Changes for V6:
- Fixed the parse_dt function of dsi device driver.
- Removed OF graph of panel in DT and DT binding document.
- Fixed the s6e3ha2 panel device driver.
  - Fixed from number size to ARRAY_SIZE().
  - Fixed error handling in mipi_dsi_dcs_* functions.
  - Fixed the clock of display_mode.
  - Removed unnecessary casting and error log.

Change for V5:
- The V5 has only one fix in V4 below.
- Removed the enable check of the mic driver in mode_set
  callback, because mode_set should be performed every time.

Changes for V4:
- Removed display-timings in devicetree, the display-timings has
  been fixed to be provided by the device driver.
- Added the mode_set callback function into exynos_drm_mic,
  because the exynos_drm_mic driver can not parse a videomode
  struct by removing the display-timings from the devicetree.

Changes for V3:
- In the DT binding document, made it clearly that the panel is a
  child node of dsi.
- Fix reset-gpio active from high to low.
- Is the OF graph saying related to patch2?
  Althogh the panel is a child of dsi, I think OF graph necessary.
  because if a remote-endpoint is not specified, the dsi also
  panel is not probed.
- The display-timings has been fixed to be provided by the device
  driver. however, I think display-timings is necessary in dts.
  because if dts does not have display-timings, dsi will not load.

Changes for V2:
- Fixed the samsung,s6e3ha2.txt DT document.
  - Added active high or low after the description of the GPIOs.
  - Removed the reg and added a description of the virtual
channel number of a DSI peripheral.

Depends on:
[1] https://git.kernel.org/cgit/linux/kernel/git/krzk/linux.git/ 
(for-next branch)

[2] https://patchwork.kernel.org/patch/9504131/
- ("arm64: dts: exynos: Add tm2 touchkey node")

Hoegeun Kwon (2):
  dt-bindings: Add support for samsung s6e3ha2 panel binding
  drm/panel: Add support for S6E3HA2 panel driver on TM2 board

Hyungwon Hwang (1):
  arm64: dts: exynos: Add support for S6E3HA2 panel device on TM2 board

 .../bindings/display/panel/samsung,s6e3ha2.txt |  28 +
 arch/arm64/boot/dts/exynos/exynos5433-tm2.dts  |  12 +
 drivers/gpu/drm/panel/Kconfig  |   6 +
 drivers/gpu/drm/panel/Makefile |   1 +
 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c  | 739 
+

 5 files changed, 786 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt

 create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c

--
1.9.1



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

[Bug 95306] Random Blank(black) screens on "Carrizo"

[bugzilla-daemon]

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

--- Comment #60 from Jaime Rodrigo  ---
Tried every RC8 and it blackouts too. Official 4.10 release boots into low
graphics mode by default, and theres no kernel driver in use (nor radeon or
amdgpu). Installed AMDGPUPRO and I get stuck in the logging screen (after
logging successfully it goes back to the logging screen and so on), and still
using low graphics mode

-- 
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/rockchip: some fixes

[Mark yao]

Hi Dave

Some fixes, looks good to me.

Best regards.

The following changes since commit 9ca70356a9260403c1bda40d942935e55d00c11c:

  Revert "drm: Resurrect atomic rmfb code, v3" (2017-02-17 12:39:04 +1000)

are available in the git repository at:

  https://github.com/markyzq/kernel-drm-rockchip.git 
drm-rockchip-next-2017-02-22


for you to fetch changes up to 3690629b844b961fc9dda98b0ffc16a6010a7f21:

  drm/rockchip: vop: verify pixelclock for hdmi and displayport 
(2017-02-22 08:44:22 +0800)



Arnd Bergmann (1):
  drm/rockchip: add extcon dependency for DP

Christophe Jaillet (1):
  drm/rockchip: cdn-dp: Fix error handling

Mark Yao (3):
  drm/rockchip: vop: no need wait vblank on crtc enable
  drm/rockchip: vop: verify display mode with vop max_output
  drm/rockchip: vop: verify pixelclock for hdmi and displayport

 drivers/gpu/drm/rockchip/Kconfig|  1 +
 drivers/gpu/drm/rockchip/cdn-dp-core.c  |  4 +++-
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 56 
++--

 drivers/gpu/drm/rockchip/rockchip_drm_vop.h |  7 +++
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 13 +
 5 files changed, 42 insertions(+), 39 deletions(-)

--
Ｍark Yao


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

Re: [PATCH v2 0/5] Fix the parse_dt of exynos dsi and remove the OF graph

[Krzysztof Kozlowski]

On Tue, Feb 21, 2017 at 1:24 AM, Inki Dae  wrote:
>>> Ideally you are right. DT changes should be no any dependency of driver 
>>> changes but now Exynos DT is broken.
>>
>> I didn't receive any bug reports that Exynos DT is broken so I am
>> quite surprised hearing that. What do you mean by that?
>
> Wrong usage of Display relevant DT ABI is being fixed without the backward 
> compatibility of the DT ABI. This means device driver doesn't consider old DT 
> binding.
> So the use of old DTB binary will make kernel booting not to work correctly.

First you wrote that Exynos DT ABI is broken. Now you mention that
wrong usage is being fixed and old DTB will not be supported. I really
don't get what was your idea. Either something is broken or not. This
is not a Shrodinger's cat.

>
>>
>>> So if we have to keep the bisectability between driver and device tree 
>>> patches - this means that all drivers should always keep the backward 
>>> compatibility - then the drivers will be messed up.
>>
>> No, you are mixing two things. Bisectability is different than
>> backward compatibility. For the backward DT ABI compatibility, we
>> agreed that in this case it can be dropped. However bisectability is
>> something totally different. The DTS changes always go through
>> separate branch, so the driver has to be *always* ready for such case
>> and should still be fully bisectable. This is a general rule existing
>
> I meant that if this patch series considers old DT binding to keep the 
> bisectability, then this driver would be messed up because the driver should 
> try to bind same properties at different places and one of these two cases 
> should be bound.
> So this driver doesn't consider the old DT binding, which means that the old 
> DTB binary isn't compatible with this driver - exynos_drm_dsi.c.

Which is wrong. The driver breaks bisectability on first commit.

Let me put it simple:
1. First commit breaks all existing in-kernel DTS. When someone tries
such commit during bisect, he will see some kind of failure. This
means that bisectability is broken on first commit, regardless whether
the rest of patches is on the same branch or not.

2. If the DTS are applied directly after first commit, the
bisectability breakage gap is one-commit wide.

3. DTS commits go to different tree and different branch. This is a
general rule. This means that bisectability breakage gap will be much
wider, span over different trees and branches. This is bad. Bad by
design.

4. Overall: these patches will break bisectability *always*. How big
the breakage will be, depends on way of applying.

5. My merge window was closed some weeks ago. I sent an private email
to Samsung folks, *including you*, on 24th of Jan reminding about
arm-soc merge cycle and that it will close soon. You did not respond.
Yesterday, v4.10 was released which opens Linus' merge window and now
you want to apply these commits. The worst possible timing.
Irresponsible.

So let me put it straight. Please fix the first commit so it will not
break bisectability.

> This means if only one side is merged then this driver wouldn't work 
> correctly.
>
>> for long time and every deviation from the rule is pointed out by
>> arm-soc guys. Whenever I accepted breaking of this rule, I had hard
>> times with arm-soc so no - I am no longer giving up basic rule just
>> because developer might not care.
>
> Understood and reasonable. Seems I just hurried up. For the bisectability, 
> this driver will have a little messed up code temporarily, and this messed up 
> code will be removed after dt change is merged.

Not necessarily. Maybe this can be made in a smart way. I believed
that no one cared to keep it reasonable and that is a problem.

> This thing was really what I want to avoid - if even the messed up code 
> should be keeped forever for the backward compatibility then it would be 
> really terribble. :(

Again you are mixing DT ABI backward compatibility with bisectability.
There is no point of explaining this again...

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

Re: [PATCH v1] drm/i915/bxt: use NULL for GPIO connection ID

[Andy Shevchenko]

On Tue, 2017-02-21 at 18:26 +0200, Jani Nikula wrote:
> On Tue, 21 Feb 2017, Andy Shevchenko  m> wrote:
> > The commit 213e08ad60ba ("drm/i915/bxt: add bxt dsi gpio element
> > support") enables GPIO support for Broxton based platforms.
> > 
> > While using that API we might get into troubles in the future,
> > because
> > we can't rely on label "panel" in the driver since vendor firmware
> > might
> > provide any GPIO pin there, e.g. "reset", and even mark it in _DSD
> > (in
> > which case the request will fail).
> > 
> > To avoid inconsistency and potential issues we have two options:
> > a) generate GPIO ACPI mapping table and supply it via
> > acpi_dev_add_driver_gpios(), or
> > b) just pass NULL as connection ID.
> > 
> > The b) approach is much simplier and would work since the driver
> > relies
> > on GPIO indeces only. Moreover, the _CRS fallback mechanism, when
> > requesting GPIO, is going to be stricter, and supplying non-NULL
> > connection ID when neither _DSD, nor GPIO ACPI mapping is present,
> > will
> > make request fail.
> 
> The patch version log in the commit suggests otherwise; we'd tried and
> failed with NULL,

Can I see DSDT excerpts of the platform that fails?

>  until Mika realized passing "panel" works:
> 
> v2 by Mika: switch *NULL* to *"panel"* when requesting gpio for
> MIPI/DSI
> panel.

> 
> See also [1]. What has changed since then that should make this work
> now? We shouldn't apply until we get Tested-by's.

Not changed yet, but *going to be*. See my repository here [2].
To fix the mess with GPIO ACPI stuff we are going to make request
stricter as I pointed in commit message above, i.e. asking for a GPIO by
connection ID without _DSD present will guarantee -ENOENT since it will
be no fallback to _CRS. You may follow discussion in our internal
mailing list for drivers.

> [1] http://mid.mail-archive.com/1480597671.26172.82.camel@intel.com

[2] http://bitbucket.org/andy-shev/linux/branch/topic%2Fuart%2frpm

-- 
Andy Shevchenko 
Intel Finland Oy
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v1] drm/i915/bxt: use NULL for GPIO connection ID

[Andy Shevchenko]

The commit 213e08ad60ba ("drm/i915/bxt: add bxt dsi gpio element
support") enables GPIO support for Broxton based platforms.

While using that API we might get into troubles in the future, because
we can't rely on label "panel" in the driver since vendor firmware might
provide any GPIO pin there, e.g. "reset", and even mark it in _DSD (in
which case the request will fail).

To avoid inconsistency and potential issues we have two options:
a) generate GPIO ACPI mapping table and supply it via
acpi_dev_add_driver_gpios(), or
b) just pass NULL as connection ID.

The b) approach is much simplier and would work since the driver relies
on GPIO indeces only. Moreover, the _CRS fallback mechanism, when
requesting GPIO, is going to be stricter, and supplying non-NULL
connection ID when neither _DSD, nor GPIO ACPI mapping is present, will
make request fail.

Cc: Mika Kahola 
Cc: Jani Nikula 
Signed-off-by: Andy Shevchenko 
---
 drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index 8f683b8b1816..493d5ec2b53a 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -315,7 +315,7 @@ static void bxt_exec_gpio(struct drm_i915_private *dev_priv,
 
if (!gpio_desc) {
gpio_desc = devm_gpiod_get_index(dev_priv->drm.dev,
-"panel", gpio_index,
+NULL, gpio_index,
 value ? GPIOD_OUT_LOW :
 GPIOD_OUT_HIGH);
 
-- 
2.11.0

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

Re: [Intel-gfx] [PATCH v3 4/8] drm: Add driver-private objects to atomic state

[Pandiyan, Dhinakaran]

On Fri, 2017-02-17 at 15:37 +0530, Archit Taneja wrote:
> 
> On 02/16/2017 05:43 AM, Pandiyan, Dhinakaran wrote:
> > On Wed, 2017-02-15 at 16:53 +0530, Archit Taneja wrote:
> >> Hi,
> >>
> >> On 02/09/2017 12:08 PM, Dhinakaran Pandiyan wrote:
> >>> It is necessary to track states for objects other than connector, crtc
> >>> and plane for atomic modesets. But adding objects like DP MST link
> >>> bandwidth to drm_atomic_state would mean that a non-core object will be
> >>> modified by the core helper functions for swapping and clearing
> >>> it's state. So, lets add void * objects and helper functions that operate
> >>> on void * types to keep these objects and states private to the core.
> >>> Drivers can then implement specific functions to swap and clear states.
> >>> The other advantage having just void * for these objects in
> >>> drm_atomic_state is that objects of different types can be managed in the
> >>> same state array.
> >>>
> >>> v2: Added docs and new iterator to filter private objects (Daniel)
> >>>
> >>> Suggested-by: Daniel Vetter 
> >>> Signed-off-by: Dhinakaran Pandiyan 
> >>> ---
> >>>  drivers/gpu/drm/drm_atomic.c| 68 +++
> >>>  drivers/gpu/drm/drm_atomic_helper.c |  5 ++
> >>>  include/drm/drm_atomic.h| 91 
> >>> +
> >>>  3 files changed, 164 insertions(+)
> >>>
> >>> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> >>> index a567310..1a9ffe8 100644
> >>> --- a/drivers/gpu/drm/drm_atomic.c
> >>> +++ b/drivers/gpu/drm/drm_atomic.c
> >>> @@ -57,6 +57,7 @@ void drm_atomic_state_default_release(struct 
> >>> drm_atomic_state *state)
> >>>   kfree(state->connectors);
> >>>   kfree(state->crtcs);
> >>>   kfree(state->planes);
> >>> + kfree(state->private_objs);
> >>>  }
> >>>  EXPORT_SYMBOL(drm_atomic_state_default_release);
> >>>
> >>> @@ -184,6 +185,20 @@ void drm_atomic_state_default_clear(struct 
> >>> drm_atomic_state *state)
> >>>   state->planes[i].ptr = NULL;
> >>>   state->planes[i].state = NULL;
> >>>   }
> >>> +
> >>> + for (i = 0; i < state->num_private_objs; i++) {
> >>> + void *private_obj = state->private_objs[i].obj;
> >>> + void *obj_state = state->private_objs[i].obj_state;
> >>> +
> >>> + if (!private_obj)
> >>> + continue;
> >>> +
> >>> + state->private_objs[i].funcs->destroy_state(obj_state);
> >>> + state->private_objs[i].obj = NULL;
> >>> + state->private_objs[i].obj_state = NULL;
> >>> + state->private_objs[i].funcs = NULL;
> >>> + }
> >>> +
> >>>  }
> >>>  EXPORT_SYMBOL(drm_atomic_state_default_clear);
> >>>
> >>> @@ -974,6 +989,59 @@ static void drm_atomic_plane_print_state(struct 
> >>> drm_printer *p,
> >>>  }
> >>>
> >>>  /**
> >>> + * drm_atomic_get_private_obj_state - get private object state
> >>> + * @state: global atomic state
> >>> + * @obj: private object to get the state for
> >>> + * @funcs: pointer to the struct of function pointers that identify the 
> >>> object
> >>> + * type
> >>> + *
> >>> + * This function returns the private object state for the given private 
> >>> object,
> >>> + * allocating the state if needed. It does not grab any locks as the 
> >>> caller is
> >>> + * expected to care of any required locking.
> >>> + *
> >>> + * RETURNS:
> >>> + *
> >>> + * Either the allocated state or the error code encoded into a pointer.
> >>> + */
> >>> +void *
> >>> +drm_atomic_get_private_obj_state(struct drm_atomic_state *state, void 
> >>> *obj,
> >>> +   const struct drm_private_state_funcs *funcs)
> >>> +{
> >>> + int index, num_objs, i;
> >>> + size_t size;
> >>> + struct __drm_private_objs_state *arr;
> >>> +
> >>> + for (i = 0; i < state->num_private_objs; i++)
> >>> + if (obj == state->private_objs[i].obj &&
> >>> + state->private_objs[i].obj_state)
> >>> + return state->private_objs[i].obj_state;
> >>
> >> Comparing this func to 
> >> drm_atomic_get_plane_state/drm_atomic_get_crtc_state, it
> >> doesn't seem to call drm_modeset_lock if the obj_state doesn't already 
> >> exist. I
> >> don't understand the locking stuff toowell, I just noticed this difference 
> >> when
> >> comparing this approach with what is done in the msm kms driver (where we
> >> have subclassed drm_atomic_state to msm_kms_state).
> >>
> >> Thanks,
> >> Archit
> >>
> >
> >
> > The caller is expected to take care of any required locking. The
> > driver-private objects are opaque from core's pov, so the core is not
> > aware of necessary locks for that object type.
> 
> I had a look at the rest of the series, and I couldn't easily understand
> whether the caller code protects the MST related driver private state. Is
> it expected to be protect via the drm_mode_config.connection_mutex lock?
> 
> Thanks,
> Archit
> 

That's right, the connection_mutex takes care of the 

Re: [PATCH] drm/vmwgfx: Work around drm removal of control nodes

[Sinclair Yeh]

Reviewed-by: Sinclair Yeh <s...@vmware.com>


On Tue, Feb 21, 2017 at 05:42:27PM +0700, Thomas Hellstrom wrote:
> vmware tools has a daemon that gets layout information from the GUI and
> forwards it to DRM so that the modesetting code can set preferred connector
> locations and modes. This daemon was using control nodes but since control
> nodes were just removed, make it possible for the daemon to use render- or
> primary nodes instead. This is a bit ugly but will allow drm to proceed with
> removal of the mostly unused control-node code and allow vmware to proceed
> with fixing up automatic layout settings for gnome-shell/wayland.
> 
> We bump minor to inform user-space about the api change.
> 
> Cc: <sta...@vger.kernel.org>
> Signed-off-by: Thomas Hellstrom <thellst...@vmware.com>
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 11 ++-
>  drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |  4 ++--
>  2 files changed, 12 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> index 541a588..d08f269 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> @@ -199,9 +199,14 @@ static const struct drm_ioctl_desc vmw_ioctls[] = {
>   VMW_IOCTL_DEF(VMW_PRESENT_READBACK,
> vmw_present_readback_ioctl,
> DRM_MASTER | DRM_AUTH),
> + /*
> +  * The permissions of the below ioctl are overridden in
> +  * vmw_generic_ioctl(). We require either
> +  * DRM_MASTER or capable(CAP_SYS_ADMIN).
> +  */
>   VMW_IOCTL_DEF(VMW_UPDATE_LAYOUT,
> vmw_kms_update_layout_ioctl,
> -   DRM_MASTER | DRM_CONTROL_ALLOW),
> +   DRM_RENDER_ALLOW),
>   VMW_IOCTL_DEF(VMW_CREATE_SHADER,
> vmw_shader_define_ioctl,
> DRM_AUTH | DRM_RENDER_ALLOW),
> @@ -1123,6 +1128,10 @@ static long vmw_generic_ioctl(struct file *filp, 
> unsigned int cmd,
>  
>   return (long) vmw_execbuf_ioctl(dev, arg, file_priv,
>   _IOC_SIZE(cmd));
> + } else if (nr == DRM_COMMAND_BASE + DRM_VMW_UPDATE_LAYOUT) {
> + if (!drm_is_current_master(file_priv) &&
> + !capable(CAP_SYS_ADMIN))
> + return -EACCES;
>   }
>  
>   if (unlikely(ioctl->cmd != cmd))
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> index 1e59a48..59ff419 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> @@ -41,9 +41,9 @@
>  #include 
>  #include "vmwgfx_fence.h"
>  
> -#define VMWGFX_DRIVER_DATE "20160210"
> +#define VMWGFX_DRIVER_DATE "20170221"
>  #define VMWGFX_DRIVER_MAJOR 2
> -#define VMWGFX_DRIVER_MINOR 11
> +#define VMWGFX_DRIVER_MINOR 12
>  #define VMWGFX_DRIVER_PATCHLEVEL 0
>  #define VMWGFX_FILE_PAGE_OFFSET 0x0010
>  #define VMWGFX_FIFO_STATIC_SIZE (1024*1024)
> -- 
> 2.9.3
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99488] [r600g]OpenCL driver causes ImageMagick to hang on JPEG input in Gaussian Blur kernel

[bugzilla-daemon]

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

--- Comment #8 from Jan Vesely  ---
Created attachment 129815
  --> https://bugs.freedesktop.org/attachment.cgi?id=129815=edit
Fix-ALU-clause-markers-use-detection

This patch fixes gromacs build for me. I tested blur and it now results in
"Register number out of range!" failure.

-- 
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 99851] [drm:.r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD)

[bugzilla-daemon]

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

--- Comment #18 from intermedi...@hotmail.com  ---
umm thans for the info. 
i have an idea... but need to check oldest kernel version.
i see last release of kernel made radeon load only as a  module. dont made
radeon as a y . 
on embenbed ppc machine for dont have cafedead i sow on nxp faq they suggest
load radeon as y and include the radeon firmwares inside the kernel. this is
not possible on server. will check and report

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

Re: [PATCH 7/7] drm/sun4i: Make sun4i_crtc_init return ERR_PTR style error codes

[Maxime Ripard]

On Fri, Feb 17, 2017 at 11:13:30AM +0800, Chen-Yu Tsai wrote:
> sun4i_crtc_init can fail for a number of reasons. Instead of returning
> a NULL pointer when it fails, pass back the encountered error using
> ERR_PTR.
> 
> Signed-off-by: Chen-Yu Tsai 

Applied, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.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 6/7] drm/sun4i: Save newly created layer in layers array in sun4i_layers_init

[Maxime Ripard]

On Fri, Feb 17, 2017 at 11:13:29AM +0800, Chen-Yu Tsai wrote:
> sun4i_layers_init allocates an array to store pointers to newly created
> layers returned by sun4i_layer_init_one(), but fails to actually store
> them. But it actually returns the empty array to unsuspecting users.
> 
> Save the pointers in the array, so that they may be used later.
> 
> Signed-off-by: Chen-Yu Tsai 

Applied, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.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 5/7] drm/sun4i: Drop useless assignment in sun4i_layers_init

[Maxime Ripard]

On Fri, Feb 17, 2017 at 11:13:28AM +0800, Chen-Yu Tsai wrote:
> The assignment found in the main loop in sun4i_layers_init:
> 
>   struct sun4i_layer *layer = layers[i];
> 
> is useless as it gets overwritten by the next line:
> 
>   layer = sun4i_layer_init_one(drm, plane);
> 
> Drop the assignment.
> 
> Signed-off-by: Chen-Yu Tsai 

Applied, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.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 4/7] drm/sun4i: Fix kcalloc element size in sun4i_layers_init

[Maxime Ripard]

On Fri, Feb 17, 2017 at 11:13:27AM +0800, Chen-Yu Tsai wrote:
> In sun4i_layers_init we are allocating an array of pointers to struct
> sun4i_layer:
> 
>   layers = devm_kcalloc(drm->dev, ARRAY_SIZE(sun4i_backend_planes),
> sizeof(**layers), GFP_KERNEL);
> 
> The element size should be the size of an individual element of the
> array. Change it to sizeof(*layers) to avoid wasting a lot of memory.
> 
> Signed-off-by: Chen-Yu Tsai 

Applied, thanks!
Maxime
-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.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 3/7] drm/sun4i: Check return value of drm_vblank_init

[Maxime Ripard]

On Fri, Feb 17, 2017 at 11:13:26AM +0800, Chen-Yu Tsai wrote:
> drm_vblank_init can fail due to insufficient memory. Ignoring the error
> and proceeding may cause the kernel to dereference an invalid pointer
> when vblank is enabled.
> 
> Signed-off-by: Chen-Yu Tsai 

Applied, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

[PATCH 2/2] drm/sti: remove unused sti_drm_dbg_cleanup

[Arnd Bergmann]

A cleanup patch just introduced this function, but no user, leading
to a compile-time warning:

drivers/gpu/drm/sti/sti_drv.c:120:13: error: 'sti_drm_dbg_cleanup' defined but 
not used [-Werror=unused-function]

It would be logical that we should actually call this function, but
I couldn't see from where, so this patch just shuts up the warning,
which may be the wrong approach.

Fixes: 5e60f595d6ca ("drm/sti: use atomic_helper for commit")
Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/sti/sti_drv.c | 9 -
 1 file changed, 9 deletions(-)

diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/sti_drv.c
index e6c1646b9c53..20fc0fbfa849 100644
--- a/drivers/gpu/drm/sti/sti_drv.c
+++ b/drivers/gpu/drm/sti/sti_drv.c
@@ -117,15 +117,6 @@ static int sti_drm_dbg_init(struct drm_minor *minor)
return ret;
 }
 
-static void sti_drm_dbg_cleanup(struct drm_minor *minor)
-{
-   drm_debugfs_remove_files(sti_drm_dbg_list,
-ARRAY_SIZE(sti_drm_dbg_list), minor);
-
-   drm_debugfs_remove_files((struct drm_info_list *)_drm_fps_fops,
-1, minor);
-}
-
 static int sti_atomic_check(struct drm_device *dev,
struct drm_atomic_state *state)
 {
-- 
2.9.0

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

[PATCH 1/2] drm/sti: remove unused variable

[Arnd Bergmann]

One variable was left behind after its user got removed and we should now
delete the declaration as well:

drivers/gpu/drm/sti/sti_vtg.c: In function 'vtg_probe':
drivers/gpu/drm/sti/sti_vtg.c:392:22: error: unused variable 'np' 
[-Werror=unused-variable]

Fixes: 0c7ff84f7f9d ("drm/sti: remove deprecated legacy vtg slave")
Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/sti/sti_vtg.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/sti/sti_vtg.c b/drivers/gpu/drm/sti/sti_vtg.c
index 943bce56692e..2dcba1d3a122 100644
--- a/drivers/gpu/drm/sti/sti_vtg.c
+++ b/drivers/gpu/drm/sti/sti_vtg.c
@@ -389,7 +389,6 @@ static irqreturn_t vtg_irq(int irq, void *arg)
 static int vtg_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
-   struct device_node *np;
struct sti_vtg *vtg;
struct resource *res;
int ret;
-- 
2.9.0

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

[Bug 99851] [drm:.r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD)

[bugzilla-daemon]

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

--- Comment #17 from Alex Deucher  ---
(In reply to intermedi...@hotmail.com from comment #16)
> why im sure it is an xorg issue or one of xorg  component issue
> (cafedead),because on Lubuntu 14.04.5 i had kernel 4.9 and no issue but xorg
> was 1.6

X has nothing to do with the kernel ring tests.  Those happen long before X
gets involved.  If the ring tests fail, all acceleration is disabled so you
need to sort out the kernel issue before addressing X.

-- 
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 99387] Kernel 4.9: Kaveri + Hainan choked on boot using amdgpu

[bugzilla-daemon]

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

--- Comment #18 from Marco  ---
Works fine here too (but only on 4.10) with the two ptches applied.

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

Re: [PATCH] drm: zte: fix static checker warning on variable 'fmt'

[Sean Paul]

On Mon, Feb 20, 2017 at 8:49 AM, Shawn Guo  wrote:
> From: Shawn Guo 
>
> Commit 4e986d3705df ("drm: zte: add overlay plane support") introduces
> the following static checker warning:
>
>  drivers/gpu/drm/zte/zx_plane.c:170 zx_vl_rsz_setup()
>  warn: always true condition '(fmt >= 0) => (0-u32max >= 0)'
>
> Fix it by change 'fmt' type to integer.
>
> Reported-by: Dan Carpenter 
> Fixes: 4e986d3705df ("drm: zte: add overlay plane support")
> Signed-off-by: Shawn Guo 

Reviewed-by: Sean Paul 

> ---
>  drivers/gpu/drm/zte/zx_plane.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/zte/zx_plane.c b/drivers/gpu/drm/zte/zx_plane.c
> index 1d08ba381098..d646ac931663 100644
> --- a/drivers/gpu/drm/zte/zx_plane.c
> +++ b/drivers/gpu/drm/zte/zx_plane.c
> @@ -159,7 +159,7 @@ static void zx_vl_rsz_setup(struct zx_plane *zplane, 
> uint32_t format,
> void __iomem *rsz = zplane->rsz;
> u32 src_chroma_w = src_w;
> u32 src_chroma_h = src_h;
> -   u32 fmt;
> +   int fmt;
>
> /* Set up source and destination resolution */
> zx_writel(rsz + RSZ_SRC_CFG, RSZ_VER(src_h - 1) | RSZ_HOR(src_w - 1));
> @@ -203,7 +203,7 @@ static void zx_vl_plane_atomic_update(struct drm_plane 
> *plane,
> u32 src_x, src_y, src_w, src_h;
> u32 dst_x, dst_y, dst_w, dst_h;
> uint32_t format;
> -   u32 fmt;
> +   int fmt;
> int num_planes;
> int i;
>
> --
> 1.9.1
>



-- 
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 99881] Lockup/Freezes on Laptop with switchable graphics

[bugzilla-daemon]

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

--- Comment #21 from Matthew Fox  ---
Created attachment 129814
  --> https://bugs.freedesktop.org/attachment.cgi?id=129814=edit
dmesg after xrandr

-- 
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 99881] Lockup/Freezes on Laptop with switchable graphics

[bugzilla-daemon]

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

--- Comment #20 from Matthew Fox  ---
Created attachment 129813
  --> https://bugs.freedesktop.org/attachment.cgi?id=129813=edit
dmesg before xrandr

-- 
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 99881] Lockup/Freezes on Laptop with switchable graphics

[bugzilla-daemon]

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

--- Comment #19 from Matthew Fox  ---
Created attachment 129812
  --> https://bugs.freedesktop.org/attachment.cgi?id=129812=edit
vgaswitcheroo switch after xrandr

-- 
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 99881] Lockup/Freezes on Laptop with switchable graphics

[bugzilla-daemon]

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

--- Comment #18 from Matthew Fox  ---
Created attachment 129811
  --> https://bugs.freedesktop.org/attachment.cgi?id=129811=edit
vgaswitcheroo switch before xrandr

-- 
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 99881] Lockup/Freezes on Laptop with switchable graphics

[bugzilla-daemon]

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

--- Comment #17 from Matthew Fox  ---
Created attachment 129810
  --> https://bugs.freedesktop.org/attachment.cgi?id=129810=edit
Xorg log after xrandr

-- 
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 98869] Electronic Super Joy graphic artefacts (regression,bisected)

[bugzilla-daemon]

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

Marek Olšák  changed:

   What|Removed |Added

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

--- Comment #26 from Marek Olšák  ---
I pushed Grazvydas's patch.

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

[Bug 99881] Lockup/Freezes on Laptop with switchable graphics

[bugzilla-daemon]

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

--- Comment #16 from Matthew Fox  ---
Created attachment 129809
  --> https://bugs.freedesktop.org/attachment.cgi?id=129809=edit
Xorg log before xrandr

-- 
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 99881] Lockup/Freezes on Laptop with switchable graphics

[bugzilla-daemon]

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

--- Comment #15 from Matthew Fox  ---
Created attachment 129808
  --> https://bugs.freedesktop.org/attachment.cgi?id=129808=edit
xrandr.log

-- 
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 99881] Lockup/Freezes on Laptop with switchable graphics

[bugzilla-daemon]

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

--- Comment #14 from Matthew Fox  ---
Hi,

It's rare that the PC doesn't lock up with runpm enabled so I've only been able
to test this a couple of times.

In the first try, the PC had stabilized (stopped freezing) after a while. I
then ran xrandr. Immediately after I cat /sys/kernel/debug/vgaswitcheroo/switch
and the discrete gpu had powered up. dmesg showed 1 block of gpu initialization
lines. A few seconds later vgaswitcheroo/switch showed the discrete gpu as
being off. dmesg also showed 2 or 3 blocks of the gpu initialization. It looked
like the gpu was being enabled and disabled repeatedly. The computer then
locked up a few seconds later. I don't have any logs for this session.

In the second try, the PC had stabilized. I ran xrandr and vgaswitcheroo/switch
had changed from 'DynOff' to 'DynPwr' for the discrete gpu. dmesg showed 1
block of the gpu initialization. The computer locked up a few seconds later.
The logs I have were captured straight after xrandr had run so the 'dmesg
after' log only shows one of the gpu initialization blocks but I suspect the
gpu was being enabled and disabled repeatedly before the PC locked up. I wasn't
able to run dmesg again before the lockup to confirm.

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

Re: [PATCH 2/7] drm/sun4i: Fix up error path cleanup for master bind function

[Maxime Ripard]

On Fri, Feb 17, 2017 at 11:13:25AM +0800, Chen-Yu Tsai wrote:
> The master bind function calls numerous drm functions which initialize
> underlying structures. It also tries to bind the various components
> of the display pipeline, some of which may add additional drm objects.
> 
> This patch adds proper cleanup functions in the error path of the
> master bind function.
> 
> This requires the patch "drm/sun4i: Move drm_mode_config_cleanup call
> to main driver", which splits out drm_mode_config_cleanup from
> sun4i_framebuffer_free so we can call it separately.
> 
> Signed-off-by: Chen-Yu Tsai 

Applied, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.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 1/7] drm/sun4i: Move drm_mode_config_cleanup call to main driver

[Maxime Ripard]

On Fri, Feb 17, 2017 at 11:13:24AM +0800, Chen-Yu Tsai wrote:
> drm_mode_config_cleanup is the complement of drm_mode_config_init, which
> is called in the bind function of sun4i_drv. drm_mode_config_cleanup
> should be put in the unbind function to match.
> 
> Signed-off-by: Chen-Yu Tsai 

Applied, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

[Bug 99136] Blood Effects Total War: Warhammer

[bugzilla-daemon]

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

--- Comment #31 from siyia  ---
ok not 10 but around 3GB

-- 
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 99136] Blood Effects Total War: Warhammer

[bugzilla-daemon]

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

--- Comment #30 from siyia  ---
lol thatgs 10 GB!!!

-- 
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 194645] amdgpu: amdgpu_resume failed

[bugzilla-daemon]

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

--- Comment #9 from Mateusz Lenik (m...@mlen.pl) ---
I retried it with x11 drivers build for 4.9.11, it still crashes

[   64.460823] suspend debug: Waiting for 5 second(s).
[   69.490160] sd 2:0:0:0: [sda] Starting disk
[   69.490214] sd 4:0:0:0: [sdb] Starting disk
[   69.490280] sd 5:0:0:0: [sdc] Starting disk
[   69.491999] power_meter ACPI000D:00: Found ACPI power meter.
[   69.492179] rtc_cmos 00:00: System wakeup disabled by ACPI
[   69.493742] serial 00:03: activated
[   69.495145] serial 00:04: activated
[   69.502637] pcieport :00:1c.3: System wakeup disabled by ACPI
[   69.502808] pcieport :00:1c.2: System wakeup disabled by ACPI
[   69.527164] [drm] PCIE GART of 8192M enabled (table at 0x0004).
[   69.530900] DPM is already running
[   69.540893] [drm] ring test on 0 succeeded in 14 usecs
[   69.561779] igb :05:00.0 enp5s0: igb: enp5s0 NIC Link is Up 1000 Mbps
Full Duplex, Flow Control: RX
[   69.806059] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[   69.806089] ata1: SATA link down (SStatus 0 SControl 300)
[   69.806109] ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[   69.806129] ata2: SATA link down (SStatus 0 SControl 300)
[   69.807977] ata3.00: supports DRM functions and may not be fully accessible
[   69.810946] ata4.00: configured for UDMA/100
[   69.812759] ata3.00: disabling queued TRIM support
[   69.813020] ata3.00: supports DRM functions and may not be fully accessible
[   69.814376] ata8: SATA link down (SStatus 0 SControl 300)
[   69.814392] ata7: SATA link down (SStatus 0 SControl 300)
[   69.814410] ata10: SATA link down (SStatus 0 SControl 300)
[   69.814427] ata9: SATA link down (SStatus 0 SControl 300)
[   69.814445] ata6: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[   69.814478] ata5: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[   69.817823] ata3.00: disabling queued TRIM support
[   69.817890] ata3.00: configured for UDMA/133
[   70.862372] [drm:gfx_v8_0_ring_test_ring] *ERROR* amdgpu: ring 1 test failed
(scratch(0xC040)=0xCAFEDEAD)
[   71.007943] [drm:gfx_v8_0_ring_test_ring] *ERROR* amdgpu: ring 2 test failed
(scratch(0xC040)=0xCAFEDEAD)
[   71.153518] [drm:gfx_v8_0_ring_test_ring] *ERROR* amdgpu: ring 3 test failed
(scratch(0xC040)=0xCAFEDEAD)
[   71.299093] [drm:gfx_v8_0_ring_test_ring] *ERROR* amdgpu: ring 4 test failed
(scratch(0xC040)=0xCAFEDEAD)
[   71.444670] [drm:gfx_v8_0_ring_test_ring] *ERROR* amdgpu: ring 5 test failed
(scratch(0xC040)=0xCAFEDEAD)
[   71.590256] [drm:gfx_v8_0_ring_test_ring] *ERROR* amdgpu: ring 6 test failed
(scratch(0xC040)=0xCAFEDEAD)
[   71.735830] [drm:gfx_v8_0_ring_test_ring] *ERROR* amdgpu: ring 7 test failed
(scratch(0xC040)=0xCAFEDEAD)
[   71.881433] [drm:gfx_v8_0_ring_test_ring] *ERROR* amdgpu: ring 8 test failed
(scratch(0xC040)=0xCAFEDEAD)
[   71.988538] [drm:sdma_v3_0_ring_test_ring] *ERROR* amdgpu: ring 9 test
failed (0xCAFEDEAD)
[   71.988543] [drm:amdgpu_resume] *ERROR* resume of IP block 
failed -22
[   71.988546] [drm:amdgpu_device_resume] *ERROR* amdgpu_resume failed (-22).
[   73.031518] [drm:gfx_v8_0_ring_test_ib] *ERROR* amdgpu: IB test timed out.
[   73.031523] [drm:amdgpu_ib_ring_tests] *ERROR* amdgpu: failed testing IB on
GFX ring (-110).
[   73.031525] [drm:amdgpu_device_resume] *ERROR* ib ring test failed (-110).
[   73.061223] [drm] PCIE GART of 8192M enabled (table at 0x0004).
[   73.064209] DPM is already running
[   73.074176] [drm] ring test on 0 succeeded in 14 usecs
[   74.428386] [drm:gfx_v8_0_ring_test_ring] *ERROR* amdgpu: ring 1 test failed
(scratch(0xC040)=0xCAFEDEAD)
[   74.578515] [drm:gfx_v8_0_ring_test_ring] *ERROR* amdgpu: ring 2 test failed
(scratch(0xC040)=0xCAFEDEAD)
[   74.728630] [drm:gfx_v8_0_ring_test_ring] *ERROR* amdgpu: ring 3 test failed
(scratch(0xC040)=0xCAFEDEAD)
[   74.878757] [drm:gfx_v8_0_ring_test_ring] *ERROR* amdgpu: ring 4 test failed
(scratch(0xC040)=0xCAFEDEAD)
[   74.951465] ata6.00: qc timeout (cmd 0x27)
[   74.951473] ata6.00: failed to read native max address (err_mask=0x4)
[   74.951474] ata6.00: HPA support seems broken, skipping HPA handling
[   74.951475] ata6.00: revalidation failed (errno=-5)
[   74.951485] ata5.00: qc timeout (cmd 0x27)
[   74.951491] ata5.00: failed to read native max address (err_mask=0x4)
[   74.951492] ata5.00: HPA support seems broken, skipping HPA handling
[   74.951493] ata5.00: revalidation failed (errno=-5)
[   75.028962] [drm:gfx_v8_0_ring_test_ring] *ERROR* amdgpu: ring 5 test failed
(scratch(0xC040)=0xCAFEDEAD)
[   75.179242] [drm:gfx_v8_0_ring_test_ring] *ERROR* amdgpu: ring 6 test failed
(scratch(0xC040)=0xCAFEDEAD)
[   75.261502] ata6: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[   75.261522] ata5: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[   75.330302] [drm:gfx_v8_0_ring_test_ring] *ERROR* amdgpu: ring 7 test failed
(scratch(0xC040)=0xCAFEDEAD)
[   75.480460] [drm:gfx_v8_0_ring_test_ring] *ERROR* 

[Bug 194649] Graphical garbage r9 380

[bugzilla-daemon]

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

--- Comment #3 from Roberth Sjonøy (roberth.sjo...@gmail.com) ---
The example shown in the image is easily reproducible for me by just right
clicking over and over and it will appear.

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

[Bug 194649] Graphical garbage r9 380

[bugzilla-daemon]

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

Roberth Sjonøy (roberth.sjo...@gmail.com) changed:

   What|Removed |Added

 Attachment #254861|xorg log.   |xorg log
description||

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

[Bug 194649] Graphical garbage r9 380

[bugzilla-daemon]

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

--- Comment #2 from Roberth Sjonøy (roberth.sjo...@gmail.com) ---
Created attachment 254861
  --> https://bugzilla.kernel.org/attachment.cgi?id=254861=edit
xorg log.

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

[Bug 194649] Graphical garbage r9 380

[bugzilla-daemon]

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

--- Comment #1 from Roberth Sjonøy (roberth.sjo...@gmail.com) ---
Created attachment 254859
  --> https://bugzilla.kernel.org/attachment.cgi?id=254859=edit
dmesg output

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

[Bug 194649] New: Graphical garbage r9 380

[bugzilla-daemon]

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

Bug ID: 194649
   Summary: Graphical garbage r9 380
   Product: Drivers
   Version: 2.5
Kernel Version: 4.9
  Hardware: All
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-...@kernel-bugs.osdl.org
  Reporter: roberth.sjo...@gmail.com
Regression: No

Created attachment 254857
  --> https://bugzilla.kernel.org/attachment.cgi?id=254857=edit
Picture of the corruption when rightclicking in websites in chromium

There is a graphical garbage in the dropdown menu when right clicking any
plasma application, tooltips in any plasma application, it flashes very briefly
and is very partial regardless if I move the mouse cursor.

Same with chromium, but it happens more often and is more severe when
rightclicking inside a website. It doesn't disappear in this case until you
move the mouse cursor anywhere over the dropdown menu, if I right click the ui
itself in chromium(bookmarks bar) it flashes very briefly and is very partial
regardless if I move the mouse cursor over the dropdown menu.

It sometimes happen very briefly across the whole window when opening a new
window for Gwenview.

This started to happen after upgrading from kernel 4.8.13 to 4.9.6, it still
happens in 4.10.0. Different mesa version makes no difference.

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

[Bug 194645] amdgpu: amdgpu_resume failed

[bugzilla-daemon]

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

--- Comment #8 from Mateusz Lenik (m...@mlen.pl) ---
(In reply to Christian König from comment #7)
> Please don't rebuild the x11 drivers! If it's a kernel bug you only need to
> build and check the kernel. X11 shouldn't be involved here.
> 
> Or does it work with an old X11 and a new kernel? Could be that it is a new
> feature which causes the issue and you need both new kernel and new X
> drivers to trigger the problem.

I didn't think about it this way, because I used exactly the same version of
the drivers, just rebuild them via emerge @x11-module-rebuild @module-rebuild.

On the other hand, initially I didn't rebuild them and used the version built
against 4.10. It failed to resume on v4.9, so I assumed I should rebuild them
too. I'll check this, maybe x drivers are the real issue here.

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

[Bug 194645] amdgpu: amdgpu_resume failed

[bugzilla-daemon]

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

--- Comment #7 from Christian König (deathsim...@vodafone.de) ---
(In reply to Mateusz Lenik from comment #6)
> I did check that it was using the freshly built kernel manually before every
> suspend test and I rebuilt x11 drivers every time the revision was changed.

Please don't rebuild the x11 drivers! If it's a kernel bug you only need to
build and check the kernel. X11 shouldn't be involved here.

Or does it work with an old X11 and a new kernel? Could be that it is a new
feature which causes the issue and you need both new kernel and new X drivers
to trigger the problem.

> Can incremental builds (that means without clean/distclean, just building
> whatever files have changed) have some effect on bisect outcome?

Well in theory that should work fine.

But in practice it is possible (but unlikely) that the build system didn't
track some dependencies correctly. It's just that in this case you usually get
a kernel which don't want to boot at all. So you notice the problem
immediately.

> The other weird thing is that after few bisections `make kernelrelease`
> returned `4.8.0+` even when I wanted to find out what is wrong in commits
> between v4.9 and v4.10-r1. Any idea what did I do incorrectly?

You did nothing wrong, bisect just drifted into a branch which was merged in
4.10, but originally based on 4.8.

That just happens when that branch was under development for a long time before
merging (e.g. started of as something 4.8 based).

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

[Bug 194645] amdgpu: amdgpu_resume failed

[bugzilla-daemon]

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

--- Comment #6 from Mateusz Lenik (m...@mlen.pl) ---
I did check that it was using the freshly built kernel manually before every
suspend test and I rebuilt x11 drivers every time the revision was changed.

Can incremental builds (that means without clean/distclean, just building
whatever files have changed) have some effect on bisect outcome?

The other weird thing is that after few bisections `make kernelrelease`
returned `4.8.0+` even when I wanted to find out what is wrong in commits
between v4.9 and v4.10-r1. Any idea what did I do incorrectly?

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

Re: [PATCH v1] drm/i915/bxt: use NULL for GPIO connection ID

[Jani Nikula]

On Tue, 21 Feb 2017, Andy Shevchenko  wrote:
> The commit 213e08ad60ba ("drm/i915/bxt: add bxt dsi gpio element
> support") enables GPIO support for Broxton based platforms.
>
> While using that API we might get into troubles in the future, because
> we can't rely on label "panel" in the driver since vendor firmware might
> provide any GPIO pin there, e.g. "reset", and even mark it in _DSD (in
> which case the request will fail).
>
> To avoid inconsistency and potential issues we have two options:
> a) generate GPIO ACPI mapping table and supply it via
> acpi_dev_add_driver_gpios(), or
> b) just pass NULL as connection ID.
>
> The b) approach is much simplier and would work since the driver relies
> on GPIO indeces only. Moreover, the _CRS fallback mechanism, when
> requesting GPIO, is going to be stricter, and supplying non-NULL
> connection ID when neither _DSD, nor GPIO ACPI mapping is present, will
> make request fail.

The patch version log in the commit suggests otherwise; we'd tried and
failed with NULL, until Mika realized passing "panel" works:

v2 by Mika: switch *NULL* to *"panel"* when requesting gpio for MIPI/DSI
panel.

See also [1]. What has changed since then that should make this work
now? We shouldn't apply until we get Tested-by's.


BR,
Jani.


[1] http://mid.mail-archive.com/1480597671.26172.82.camel@intel.com


>
> Cc: Mika Kahola 
> Cc: Jani Nikula 
> Signed-off-by: Andy Shevchenko 
> ---
>  drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
> b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> index 8f683b8b1816..493d5ec2b53a 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> @@ -315,7 +315,7 @@ static void bxt_exec_gpio(struct drm_i915_private 
> *dev_priv,
>  
>   if (!gpio_desc) {
>   gpio_desc = devm_gpiod_get_index(dev_priv->drm.dev,
> -  "panel", gpio_index,
> +  NULL, gpio_index,
>value ? GPIOD_OUT_LOW :
>GPIOD_OUT_HIGH);

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

[Bug 194645] amdgpu: amdgpu_resume failed

[bugzilla-daemon]

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

Christian König (deathsim...@vodafone.de) changed:

   What|Removed |Added

 CC||deathsim...@vodafone.de

--- Comment #5 from Christian König (deathsim...@vodafone.de) ---
(In reply to Mateusz Lenik from comment #4)
> I did try to bisect, but wasn't very successful. It reported totally
> unrelated commit as the first “bad” commit.
> 
> I'm sure that resume for amdgpu works correctly on v4.9 and is broken on
> 4.10-rc1

Make sure that reboot to the correct kernel after each retry.

On Ubuntu I usually change /etc/grub.d/10_linux to automatically boot into the
latest installed kernel and not the one with the highest version number as
well.

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

Re: [PATCH v3 13/23] drm: mediatek: use vblank hooks in struct drm_crtc_funcs

[Sean Paul]

On Tue, Feb 07, 2017 at 05:16:25PM +0800, Shawn Guo wrote:
> From: Shawn Guo 
> 
> The vblank hooks in struct drm_driver are deprecated and only meant for
> legacy drivers.  For modern drivers with DRIVER_MODESET flag, the hooks
> in struct drm_crtc_funcs should be used instead.
> 
> Signed-off-by: Shawn Guo 

Applied to -misc

Thanks,

Sean

> Cc: CK Hu 
> ---
>  drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 8 
>  drivers/gpu/drm/mediatek/mtk_drm_crtc.h | 2 --
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c  | 3 ---
>  3 files changed, 4 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index a73de1e669c2..69982f5a6198 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -168,9 +168,8 @@ static void mtk_drm_crtc_mode_set_nofb(struct drm_crtc 
> *crtc)
>   state->pending_config = true;
>  }
>  
> -int mtk_drm_crtc_enable_vblank(struct drm_device *drm, unsigned int pipe)
> +static int mtk_drm_crtc_enable_vblank(struct drm_crtc *crtc)
>  {
> - struct drm_crtc *crtc = drm_crtc_from_index(drm, pipe);
>   struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
>   struct mtk_ddp_comp *ovl = mtk_crtc->ddp_comp[0];
>  
> @@ -179,9 +178,8 @@ int mtk_drm_crtc_enable_vblank(struct drm_device *drm, 
> unsigned int pipe)
>   return 0;
>  }
>  
> -void mtk_drm_crtc_disable_vblank(struct drm_device *drm, unsigned int pipe)
> +static void mtk_drm_crtc_disable_vblank(struct drm_crtc *crtc)
>  {
> - struct drm_crtc *crtc = drm_crtc_from_index(drm, pipe);
>   struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
>   struct mtk_ddp_comp *ovl = mtk_crtc->ddp_comp[0];
>  
> @@ -436,6 +434,8 @@ static void mtk_drm_crtc_atomic_flush(struct drm_crtc 
> *crtc,
>   .atomic_duplicate_state = mtk_drm_crtc_duplicate_state,
>   .atomic_destroy_state   = mtk_drm_crtc_destroy_state,
>   .gamma_set  = drm_atomic_helper_legacy_gamma_set,
> + .enable_vblank  = mtk_drm_crtc_enable_vblank,
> + .disable_vblank = mtk_drm_crtc_disable_vblank,
>  };
>  
>  static const struct drm_crtc_helper_funcs mtk_crtc_helper_funcs = {
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.h 
> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
> index a1550fa3c9d2..9d9410c67ae9 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.h
> @@ -23,8 +23,6 @@
>  #define MTK_MAX_BPC  10
>  #define MTK_MIN_BPC  3
>  
> -int mtk_drm_crtc_enable_vblank(struct drm_device *drm, unsigned int pipe);
> -void mtk_drm_crtc_disable_vblank(struct drm_device *drm, unsigned int pipe);
>  void mtk_drm_crtc_commit(struct drm_crtc *crtc);
>  void mtk_crtc_ddp_irq(struct drm_crtc *crtc, struct mtk_ddp_comp *ovl);
>  int mtk_drm_crtc_create(struct drm_device *drm_dev,
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index ef8675336465..f5a1fd9b3ecc 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -256,9 +256,6 @@ static void mtk_drm_kms_deinit(struct drm_device *drm)
>   .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME |
>  DRIVER_ATOMIC,
>  
> - .enable_vblank = mtk_drm_crtc_enable_vblank,
> - .disable_vblank = mtk_drm_crtc_disable_vblank,
> -
>   .gem_free_object_unlocked = mtk_drm_gem_free_object,
>   .gem_vm_ops = _gem_cma_vm_ops,
>   .dumb_create = mtk_drm_gem_dumb_create,
> -- 
> 1.9.1
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [PATCH v3 15/23] drm: qxl: use vblank hooks in struct drm_crtc_funcs

[Sean Paul]

On Tue, Feb 07, 2017 at 05:16:27PM +0800, Shawn Guo wrote:
> From: Shawn Guo 
> 
> The vblank hooks in struct drm_driver are deprecated and only meant for
> legacy drivers.  For modern drivers with DRIVER_MODESET flag, the hooks
> in struct drm_crtc_funcs should be used instead.
> 
> Signed-off-by: Shawn Guo 

Applied to -misc

Thanks,

Sean

> Cc: Dave Airlie 
> ---
>  drivers/gpu/drm/qxl/qxl_display.c | 16 
>  drivers/gpu/drm/qxl/qxl_drv.c | 18 --
>  2 files changed, 16 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/gpu/drm/qxl/qxl_display.c 
> b/drivers/gpu/drm/qxl/qxl_display.c
> index 1094cd33eb06..2ce805a7ce5e 100644
> --- a/drivers/gpu/drm/qxl/qxl_display.c
> +++ b/drivers/gpu/drm/qxl/qxl_display.c
> @@ -548,6 +548,19 @@ static int qxl_crtc_cursor_move(struct drm_crtc *crtc,
>   return 0;
>  }
>  
> +static u32 qxl_noop_get_vblank_counter(struct drm_crtc *crtc)
> +{
> + return 0;
> +}
> +
> +static int qxl_noop_enable_vblank(struct drm_crtc *crtc)
> +{
> + return 0;
> +}
> +
> +static void qxl_noop_disable_vblank(struct drm_crtc *crtc)
> +{
> +}
>  
>  static const struct drm_crtc_funcs qxl_crtc_funcs = {
>   .cursor_set2 = qxl_crtc_cursor_set2,
> @@ -555,6 +568,9 @@ static int qxl_crtc_cursor_move(struct drm_crtc *crtc,
>   .set_config = drm_crtc_helper_set_config,
>   .destroy = qxl_crtc_destroy,
>   .page_flip = qxl_crtc_page_flip,
> + .get_vblank_counter = qxl_noop_get_vblank_counter,
> + .enable_vblank = qxl_noop_enable_vblank,
> + .disable_vblank = qxl_noop_disable_vblank,
>  };
>  
>  void qxl_user_framebuffer_destroy(struct drm_framebuffer *fb)
> diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
> index 8e17c241e63c..48d51a2f3bd8 100644
> --- a/drivers/gpu/drm/qxl/qxl_drv.c
> +++ b/drivers/gpu/drm/qxl/qxl_drv.c
> @@ -247,21 +247,6 @@ static int qxl_pm_restore(struct device *dev)
>   return qxl_drm_resume(drm_dev, false);
>  }
>  
> -static u32 qxl_noop_get_vblank_counter(struct drm_device *dev,
> -unsigned int pipe)
> -{
> - return 0;
> -}
> -
> -static int qxl_noop_enable_vblank(struct drm_device *dev, unsigned int pipe)
> -{
> - return 0;
> -}
> -
> -static void qxl_noop_disable_vblank(struct drm_device *dev, unsigned int 
> pipe)
> -{
> -}
> -
>  static const struct dev_pm_ops qxl_pm_ops = {
>   .suspend = qxl_pm_suspend,
>   .resume = qxl_pm_resume,
> @@ -281,9 +266,6 @@ static void qxl_noop_disable_vblank(struct drm_device 
> *dev, unsigned int pipe)
>  static struct drm_driver qxl_driver = {
>   .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME |
>  DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED,
> - .get_vblank_counter = qxl_noop_get_vblank_counter,
> - .enable_vblank = qxl_noop_enable_vblank,
> - .disable_vblank = qxl_noop_disable_vblank,
>  
>   .set_busid = drm_pci_set_busid,
>  
> -- 
> 1.9.1
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [PATCH v3 11/23] drm: kirin: use vblank hooks in struct drm_crtc_funcs

[Sean Paul]

On Thu, Feb 16, 2017 at 11:23:39AM +0800, Xinliang Liu wrote:
> On 7 February 2017 at 17:16, Shawn Guo  wrote:
> > From: Shawn Guo 
> >
> > The vblank hooks in struct drm_driver are deprecated and only meant for
> > legacy drivers.  For modern drivers with DRIVER_MODESET flag, the hooks
> > in struct drm_crtc_funcs should be used instead.
> >
> > Signed-off-by: Shawn Guo 
> > Cc: Xinliang Liu 
> 
> Thanks Shawn for the rework patches,
> For the kirin,
> Reviewed-by: Xinliang Liu 

Applied to -misc

Thanks,

Sean

> 
> Thanks,
> -xinliang
> 
> > ---
> >  drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 10 --
> >  1 file changed, 4 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c 
> > b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
> > index 0624fab8046f..c96c228a9898 100644
> > --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
> > +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
> > @@ -302,9 +302,8 @@ static void ade_set_medianoc_qos(struct ade_crtc *acrtc)
> >SOCKET_QOS_EN, SOCKET_QOS_EN);
> >  }
> >
> > -static int ade_enable_vblank(struct drm_device *dev, unsigned int pipe)
> > +static int ade_crtc_enable_vblank(struct drm_crtc *crtc)
> >  {
> > -   struct drm_crtc *crtc = drm_crtc_from_index(dev, pipe);
> > struct ade_crtc *acrtc = to_ade_crtc(crtc);
> > struct ade_hw_ctx *ctx = acrtc->ctx;
> > void __iomem *base = ctx->base;
> > @@ -318,9 +317,8 @@ static int ade_enable_vblank(struct drm_device *dev, 
> > unsigned int pipe)
> > return 0;
> >  }
> >
> > -static void ade_disable_vblank(struct drm_device *dev, unsigned int pipe)
> > +static void ade_crtc_disable_vblank(struct drm_crtc *crtc)
> >  {
> > -   struct drm_crtc *crtc = drm_crtc_from_index(dev, pipe);
> > struct ade_crtc *acrtc = to_ade_crtc(crtc);
> > struct ade_hw_ctx *ctx = acrtc->ctx;
> > void __iomem *base = ctx->base;
> > @@ -570,6 +568,8 @@ static void ade_crtc_atomic_flush(struct drm_crtc *crtc,
> > .set_property = drm_atomic_helper_crtc_set_property,
> > .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
> > .atomic_destroy_state   = drm_atomic_helper_crtc_destroy_state,
> > +   .enable_vblank  = ade_crtc_enable_vblank,
> > +   .disable_vblank = ade_crtc_disable_vblank,
> >  };
> >
> >  static int ade_crtc_init(struct drm_device *dev, struct drm_crtc *crtc,
> > @@ -1025,8 +1025,6 @@ static int ade_drm_init(struct platform_device *pdev)
> >IRQF_SHARED, dev->driver->name, acrtc);
> > if (ret)
> > return ret;
> > -   dev->driver->enable_vblank = ade_enable_vblank;
> > -   dev->driver->disable_vblank = ade_disable_vblank;
> >
> > return 0;
> >  }
> > --
> > 1.9.1
> >
> > ___
> > 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

-- 
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 194645] amdgpu: amdgpu_resume failed

[bugzilla-daemon]

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

--- Comment #4 from Mateusz Lenik (m...@mlen.pl) ---
I did try to bisect, but wasn't very successful. It reported totally unrelated
commit as the first “bad” commit.

I'm sure that resume for amdgpu works correctly on v4.9 and is broken on
4.10-rc1

$ git bisect log
git bisect start
# good: [69973b830859bc6529a7a0468ba0d80ee5117826] Linux 4.9
git bisect good 69973b830859bc6529a7a0468ba0d80ee5117826
# bad: [7ce7d89f48834cefece7804d38fc5d85382edf77] Linux 4.10-rc1
git bisect bad 7ce7d89f48834cefece7804d38fc5d85382edf77
# bad: [72cca7baf4fba777b8ab770b902cf2e08941773f] Merge tag 'staging-4.10-rc1'
of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
git bisect bad 72cca7baf4fba777b8ab770b902cf2e08941773f
# bad: [b8d2798f32785398fcd1c48ea80c0c6c5ab88537] Merge tag 'clk-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux
git bisect bad b8d2798f32785398fcd1c48ea80c0c6c5ab88537
# bad: [ea3349a03519dcd4f32d949cd80ab995623dc5ac] mlx4: xdp: Reserve headroom
for receiving packet when XDP prog is active
git bisect bad ea3349a03519dcd4f32d949cd80ab995623dc5ac
# bad: [54dbf3a57731da6e21c6e65bd1a7f9ee009708ca] Merge branch 'nway-reset'
git bisect bad 54dbf3a57731da6e21c6e65bd1a7f9ee009708ca
# bad: [0c288c86928e50d6d8d2efa4ca23dca58d28543e] tipc: create TIPC_LISTEN as a
new sk_state
git bisect bad 0c288c86928e50d6d8d2efa4ca23dca58d28543e
# bad: [e1da71ca88170d1a6232951294b44dc0c824e464] i40e: Drop code for
unsupported flow types
git bisect bad e1da71ca88170d1a6232951294b44dc0c824e464
# bad: [0f524a80ff35af8a7664d7661d948107da142e04] net: Add warning if any lower
device is still in adjacency list
git bisect bad 0f524a80ff35af8a7664d7661d948107da142e04
# bad: [f9dbd5a343eeb3e8bf8853256d05188dd27c1ecf] Merge branch
'ila-cached-route'
git bisect bad f9dbd5a343eeb3e8bf8853256d05188dd27c1ecf
# bad: [687d911466774808ed4926edadb20cc4f0153bed] Merge branch 's390-net'
git bisect bad 687d911466774808ed4926edadb20cc4f0153bed
# bad: [b07bf5fa32e0991b263652de56066fe311f2] Merge branch 'xgene-gpio'
git bisect bad b07bf5fa32e0991b263652de56066fe311f2
# bad: [86e3a04002378610d77d3941f45ebbf531cf605e] net: ti: netcp_ethss: use new
api ethtool_{get|set}_link_ksettings
git bisect bad 86e3a04002378610d77d3941f45ebbf531cf605e
# bad: [d6d50c7ea42d3659782695bfebf4ae6548d00db5] net: stmmac: use phydev from
struct net_device
git bisect bad d6d50c7ea42d3659782695bfebf4ae6548d00db5
# bad: [a54e1612bc3dd4a3974b69a6043dd4ddbab14e6d] net: mv643xx_eth: use new api
ethtool_{get|set}_link_ksettings
git bisect bad a54e1612bc3dd4a3974b69a6043dd4ddbab14e6d
# bad: [1e8a655db2f4dd8777eda08c2af7d1381b9eecca] net: mv643xx_eth: use phydev
from struct net_device
git bisect bad 1e8a655db2f4dd8777eda08c2af7d1381b9eecca
# first bad commit: [1e8a655db2f4dd8777eda08c2af7d1381b9eecca] net:
mv643xx_eth: use phydev from struct net_device

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

[Bug 99889] nouveau preventing shutdown after suspend-resume

[bugzilla-daemon]

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

Ilia Mirkin  changed:

   What|Removed |Added

Product|DRI |xorg
 QA Contact||xorg-t...@lists.x.org
   Assignee|dri-devel@lists.freedesktop |nouveau@lists.freedesktop.o
   |.org|rg
  Component|DRM/other   |Driver/nouveau
Version|DRI git |unspecified

-- 
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 99889] nouveau preventing shutdown after suspend-resume

[bugzilla-daemon]

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

Bug ID: 99889
   Summary: nouveau preventing shutdown after suspend-resume
   Product: DRI
   Version: DRI git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/other
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: jprv...@gmail.com

On a Asus X756UQK laptop with nvidia + intel graphics, after a suspend-resume
cycle the machine hangs on shutdown, requiring a forced power off.

This problem is present on nouveau/linux-4.11 branch tip (de9b3ec13dfc
drm/nouveau/tmr: provide backtrace when a timeout is hit), Linus' v4.10-rc8
tag, and was first seen on a 4.8 kernel. On this 4.8 kernel, after resuming I
saw the following messages on the kernel log once:

[  186.117539] nouveau :01:00.0: DRM: evicting buffers...
[  186.118105] nouveau :01:00.0: DRM: waiting for kernel channels to go
idle...
[  201.139049] nouveau :01:00.0: DRM: failed to idle channel 0 [DRM]
[  201.139688] [ cut here ]
[  201.140297] WARNING: CPU: 0 PID: 1230 at
/usr/src/packages/BUILD/linux-4.8.0/drivers/pci/pci.c:1616
pci_disable_device+0x99/0xb0
[  201.140970] nouveau :01:00.0: disabling already-disabled device
[  201.140984] Modules linked in:
[  201.141608]  ccm arc4 rfcomm joydev cmac bnep intel_rapl
x86_pkg_temp_thermal coretemp i2c_designware_platform i2c_designware_core
kvm_intel asus_nb_wmi asus_wmi sparse_keymap snd_hda_codec_hdmi
snd_hda_codec_conexant snd_soc_skl snd_hda_codec_generic snd_soc_skl_ipc
snd_soc_sst_ipc kvm ath10k_pci snd_soc_sst_dsp snd_hda_ext_core
snd_soc_sst_match ath10k_core snd_soc_core irqbypass crct10dif_pclmul
snd_compress crc32_pclmul ac97_bus ghash_clmulni_intel snd_pcm_dmaengine ath
mac80211 snd_hda_intel aesni_intel snd_hda_codec aes_x86_64 snd_hda_core lrw
glue_helper uvcvideo snd_hwdep ablk_helper videobuf2_vmalloc cryptd
videobuf2_memops snd_pcm videobuf2_v4l2 cfg80211 videobuf2_core videodev
snd_timer media input_leds snd r8169 soundcore mii btusb btrtl shpchp
processor_thermal_device mei_me idma64 mei
[  201.143087]  intel_pch_thermal
[  201.143087]  virt_dma
[  201.143087]  intel_lpss_pci
[  201.143088]  intel_soc_dts_iosf
[  201.143088]  hci_uart
[  201.143089]  elan_i2c
[  201.143089]  btbcm
[  201.143089]  btqca
[  201.143090]  btintel
[  201.143090]  bluetooth
[  201.143090]  int3403_thermal
[  201.143091]  int340x_thermal_zone
[  201.143091]  acpi_als
[  201.143091]  kfifo_buf
[  201.143092]  int3400_thermal
[  201.143092]  acpi_thermal_rel
[  201.143093]  industrialio
[  201.143093]  intel_lpss_acpi
[  201.143093]  acpi_pad
[  201.143094]  tpm_crb
[  201.143094]  intel_lpss
[  201.143094]  fjes
[  201.143095]  mac_hid
[  201.143095]  asus_wireless
[  201.143095]  nouveau
[  201.143096]  i915
[  201.143096]  mxm_wmi
[  201.143096]  i2c_algo_bit
[  201.143097]  drm_kms_helper
[  201.143097]  syscopyarea
[  201.143098]  ttm
[  201.143098]  sysfillrect
[  201.143098]  serio_raw
[  201.143099]  sysimgblt
[  201.143099]  fb_sys_fops
[  201.143100]  drm
[  201.143100]  ahci
[  201.143100]  libahci
[  201.143101]  i2c_hid
[  201.143101]  hid
[  201.143101]  video
[  201.143102]  wmi

[  201.143104] CPU: 0 PID: 1230 Comm: kworker/0:6 Not tainted
4.8.0-32-generic #34+dev155.82734c4beos3.1.2-Endless
[  201.143104] Hardware name: ASUSTeK COMPUTER INC. X756UQK/X756UQK, BIOS
X756UQK.201 07/01/2016
[  201.143107] Workqueue: pm pm_runtime_work
[  201.143110]  0286 6307316f 953a9d933c08
9e031233
[  201.143111]  953a9d933c58  953a9d933c48
9dc832f1
[  201.143112]  0650 953a9ff44000 953a9feeeca0
953a997b1800
[  201.143113] Call Trace:
[  201.143116]  [] dump_stack+0x63/0x90
[  201.143118]  [] __warn+0xd1/0xf0
[  201.143120]  [] warn_slowpath_fmt+0x5f/0x80
[  201.143122]  [] ? pci_save_vc_state+0x34/0xe0
[  201.143124]  [] pci_disable_device+0x99/0xb0
[  201.143152]  []
nouveau_pmops_runtime_suspend+0x69/0xe0 [nouveau]
[  201.143153]  [] pci_pm_runtime_suspend+0x5b/0x180
[  201.143154]  [] __rpm_callback+0x33/0x70
[  201.143155]  [] rpm_callback+0x24/0x80
[  201.143156]  [] ? pci_pm_runtime_resume+0xa0/0xa0
[  201.143157]  [] rpm_suspend+0x12d/0x650
[  201.143158]  [] pm_runtime_work+0x78/0xa0
[  201.143160]  [] process_one_work+0x156/0x420
[  201.143161]  [] worker_thread+0x4e/0x4a0
[  201.143162]  [] ? rescuer_thread+0x380/0x380
[  201.143163]  [] ? rescuer_thread+0x380/0x380
[  201.143165]  [] kthread+0xd8/0xf0
[  201.143167]  [] ret_from_fork+0x1f/0x40
[  

Re: [RESEND PATCH v7 6/7] drm/rockchip/dsi: fix insufficient bandwidth of some panel

[Sean Paul]

On Mon, Feb 20, 2017 at 04:02:22PM +0800, Chris Zhong wrote:
> Set the lanes bps to 1 / 0.9 times of pclk, the margin is not enough
> for some panel, it will cause the screen display is not normal, so
> increases the badnwidth to 1 / 0.8.
> 
> Signed-off-by: Chris Zhong 

Reviewed-by: Sean Paul 

> ---
> 
> Changes in v6: None
> Changes in v5: None
> Changes in v4: None
> Changes in v3: None
> 
>  drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
> b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> index c2d7674..a653384 100644
> --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> @@ -532,8 +532,8 @@ static int dw_mipi_dsi_get_lane_bps(struct dw_mipi_dsi 
> *dsi,
>  
>   mpclk = DIV_ROUND_UP(mode->clock, MSEC_PER_SEC);
>   if (mpclk) {
> - /* take 1 / 0.9, since mbps must big than bandwidth of RGB */
> - tmp = mpclk * (bpp / dsi->lanes) * 10 / 9;
> + /* take 1 / 0.8, since mbps must big than bandwidth of RGB */
> + tmp = mpclk * (bpp / dsi->lanes) * 10 / 8;
>   if (tmp < max_mbps)
>   target_mbps = tmp;
>   else
> -- 
> 2.6.3
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [RESEND PATCH v7 0/7] Rockchip dw-mipi-dsi driver

[Sean Paul]

On Mon, Feb 20, 2017 at 04:02:16PM +0800, Chris Zhong wrote:
> Hi all
> 
> [Resend this v7 version series, since there are 5 mails have gone missing, 
> last
> week]
> 
> This version does not change the existing v6 patches, just to add the
> "bandwidth fix" patch back, since we really need it.
> 
> This patch serial is for RK3399 MIPI DSI. The MIPI DSI controller of
> RK3399 is almost the same as RK3288, except a little bit of difference
> in phy clock controlling and port id selection register. These patches
> add RK3399 support and the power domain support.
> 
> And these patches base on John Keeping's v3 patches[0], it fixes many bugs,
> they have been tested on rk3288 evb board.

Do we have an ETA on when John is planning on respinning his patchset based on
review feedback?

> 
> [0]:
> [01/24] https://patchwork.kernel.org/patch/9544089
> [02/24] https://patchwork.kernel.org/patch/9544061
> [03/24] https://patchwork.kernel.org/patch/9544065
> [04/24] https://patchwork.kernel.org/patch/9544077
> [05/24] https://patchwork.kernel.org/patch/9544033
> [06/24] https://patchwork.kernel.org/patch/9544037
> [07/24] https://patchwork.kernel.org/patch/9544029
> [08/24] https://patchwork.kernel.org/patch/9544031
> [09/24] https://patchwork.kernel.org/patch/9544083
> [10/24] https://patchwork.kernel.org/patch/9544063
> [11/24] https://patchwork.kernel.org/patch/9544085
> [12/24] https://patchwork.kernel.org/patch/9544093
> [13/24] https://patchwork.kernel.org/patch/9544081
> [14/24] https://patchwork.kernel.org/patch/9544057
> [15/24] https://patchwork.kernel.org/patch/9544079
> [16/24] https://patchwork.kernel.org/patch/9544035
> [17/24] https://patchwork.kernel.org/patch/9544105
> [18/24] https://patchwork.kernel.org/patch/9544059
> [21/24] https://patchwork.kernel.org/patch/9544009
> [22/24] https://patchwork.kernel.org/patch/9544049
> [23/24] https://patchwork.kernel.org/patch/9544055
> [24/24] https://patchwork.kernel.org/patch/9544109
> 
> 
> Changes in v6:
> - no need check phy_cfg_clk before enable/disable
> 
> Changes in v5:
> - check the error of phy_cfg_clk in dw_mipi_dsi_bind
> 
> Changes in v4:
> - remove the unrelated change
> 
> Changes in v3:
> - base on John Keeping's patch series
> 
> Chris Zhong (7):
>   dt-bindings: add rk3399 support for dw-mipi-rockchip
>   drm/rockchip/dsi: dw-mipi: support RK3399 mipi dsi
>   drm/rockchip/dsi: dw-mipi: correct the coding style
>   drm/rockchip/dsi: remove mode_valid function
>   dt-bindings: add power domain node for dw-mipi-rockchip
>   drm/rockchip/dsi: fix insufficient bandwidth of some panel
>   drm/rockchip/dsi: add dw-mipi power domain support
> 
>  .../display/rockchip/dw_mipi_dsi_rockchip.txt  |   7 +-
>  drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 160 
> -
>  2 files changed, 100 insertions(+), 67 deletions(-)
> 
> -- 
> 2.6.3
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [PATCH] dma-buf: add support for compat ioctl

[Christian König]

Am 21.02.2017 um 15:55 schrieb Marek Szyprowski:

Dear All,

On 2017-02-21 15:37, Marek Szyprowski wrote:

Hi Christian,

On 2017-02-21 14:59, Christian König wrote:

Am 21.02.2017 um 14:21 schrieb Marek Szyprowski:
Add compat ioctl support to dma-buf. This lets one to use 
DMA_BUF_IOCTL_SYNC
ioctl from 32bit application on 64bit kernel. Data structures for 
both 32
and 64bit modes are same, so there is no need for additional 
translation

layer.


Well I might be wrong, but IIRC compat_ioctl was just optional and 
if not specified unlocked_ioctl was called instead.


If that is true your patch wouldn't have any effect at all.


Well, then why I got -ENOTTY in the 32bit test app for this ioctl on 
64bit ARM64 kernel without this patch?




I've checked in fs/compat_ioctl.c, I see no fallback in 
COMPAT_SYSCALL_DEFINE3,
so one has to provide compat_ioctl callback to have ioctl working with 
32bit

apps.


Then my memory cheated on me.

In this case the patch is Reviewed-by: Christian König 
.


Regards,
Christian.



Best regards



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

Re: [PATCH] dma-buf: add support for compat ioctl

[Marek Szyprowski]

Dear All,

On 2017-02-21 15:37, Marek Szyprowski wrote:

Hi Christian,

On 2017-02-21 14:59, Christian König wrote:

Am 21.02.2017 um 14:21 schrieb Marek Szyprowski:
Add compat ioctl support to dma-buf. This lets one to use 
DMA_BUF_IOCTL_SYNC
ioctl from 32bit application on 64bit kernel. Data structures for 
both 32
and 64bit modes are same, so there is no need for additional 
translation

layer.


Well I might be wrong, but IIRC compat_ioctl was just optional and if 
not specified unlocked_ioctl was called instead.


If that is true your patch wouldn't have any effect at all.


Well, then why I got -ENOTTY in the 32bit test app for this ioctl on 
64bit ARM64 kernel without this patch?




I've checked in fs/compat_ioctl.c, I see no fallback in 
COMPAT_SYSCALL_DEFINE3,

so one has to provide compat_ioctl callback to have ioctl working with 32bit
apps.

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

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

Re: [PATCH] dma-buf: add support for compat ioctl

[Marek Szyprowski]

Hi Christian,

On 2017-02-21 14:59, Christian König wrote:

Am 21.02.2017 um 14:21 schrieb Marek Szyprowski:
Add compat ioctl support to dma-buf. This lets one to use 
DMA_BUF_IOCTL_SYNC
ioctl from 32bit application on 64bit kernel. Data structures for 
both 32

and 64bit modes are same, so there is no need for additional translation
layer.


Well I might be wrong, but IIRC compat_ioctl was just optional and if 
not specified unlocked_ioctl was called instead.


If that is true your patch wouldn't have any effect at all.


Well, then why I got -ENOTTY in the 32bit test app for this ioctl on 
64bit ARM64 kernel without this patch?


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

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

Re: [PATCH v2 0/4] drm: handle override/firmware edid at the lowest level

[Jani Nikula]

On Fri, 17 Feb 2017, Ville Syrjälä  wrote:
> On Fri, Feb 17, 2017 at 05:20:50PM +0200, Jani Nikula wrote:
>> v2 of cover.1487241304.git.jani.nikula@intel.com">http://mid.mail-archive.com/cover.1487241304.git.jani.nikula@intel.com
>
> lgtm. For the series
> Reviewed-by: Ville Syrjälä 

Thanks for the review. I pushed patches 1-3 as they're not all that
controversial, and it'll give us more coverage on the change in patch 3.

I would like to have more eyeballs and acks on patch 4 before pushing.

BR,
Jani.

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

Re: [PATCH v2 4/9] dt-bindings: Add Ampire AM-480272H3TMQW-T01H panel

[Rob Herring]

On Mon, Feb 20, 2017 at 5:01 AM, Yannick FERTRE  wrote:
>
>
> On 02/16/2017 03:34 AM, Rob Herring wrote:
>> On Fri, Feb 10, 2017 at 03:54:44PM +0100, Yannick Fertre wrote:
>>> Signed-off-by: Yannick Fertre 
>>> ---
>>>  .../bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt | 7 
>>> +++
>>>  1 file changed, 7 insertions(+)
>>>  create mode 100644 
>>> Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt
>>>
>>> diff --git 
>>> a/Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt
>>>  
>>> b/Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt
>>> new file mode 100644
>>> index 000..f59e3c4
>>> --- /dev/null
>>> +++ 
>>> b/Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt
>>> @@ -0,0 +1,7 @@
>>> +Ampire AM-480272H3TMQW-T01H 4.3" WQVGA TFT LCD panel
>>> +
>>> +Required properties:
>>> +- compatible: should be "ampire,am-480272h3tmqw-t01h"
>>
>> No GPIO controls or power supply for this panel?
>>
>> Rob
>>
>
> Hi Rob,
> thank for your reply.
> There is no gpio or power supply control for this panel with the eval
> board stm429x9i.

You need to describe what the panel has, not what you have control of
or not on a particular board.

> This binding is similar to all panel bindings which are link to panel
> simple. Details on gpio & power supply are describe with simple-panel
> binding.

simple-panel.txt provides what possible standard properties there are,
not whether a panel uses them. The power supply needs to be explicit
because I don't know if you forgot and there's really 2 supplies or
you are using "power-supply" for a single supply.

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

Re: [PATCH v3 1/7] dt-bindings: display: add STM32 LTDC driver

[Rob Herring]

On Mon, Feb 20, 2017 at 10:08 AM, Yannick Fertre  wrote:
> Signed-off-by: Yannick Fertre 
> ---
>  .../devicetree/bindings/display/st,stm32-ltdc.txt  | 36 
> ++
>  1 file changed, 36 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/st,stm32-ltdc.txt

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

Re: [PATCH] dma-buf: add support for compat ioctl

[Christian König]

Am 21.02.2017 um 14:21 schrieb Marek Szyprowski:

Add compat ioctl support to dma-buf. This lets one to use DMA_BUF_IOCTL_SYNC
ioctl from 32bit application on 64bit kernel. Data structures for both 32
and 64bit modes are same, so there is no need for additional translation
layer.


Well I might be wrong, but IIRC compat_ioctl was just optional and if 
not specified unlocked_ioctl was called instead.


If that is true your patch wouldn't have any effect at all.

Regards,
Christian.



Signed-off-by: Marek Szyprowski 
---
  drivers/dma-buf/dma-buf.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 718f832a5c71..0007b792827b 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -325,6 +325,9 @@ static long dma_buf_ioctl(struct file *file,
.llseek = dma_buf_llseek,
.poll   = dma_buf_poll,
.unlocked_ioctl = dma_buf_ioctl,
+#ifdef CONFIG_COMPAT
+   .compat_ioctl   = dma_buf_ioctl,
+#endif
  };
  
  /*



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

[PATCH 1/3] drm/atomic: Make disable_all helper fully disable the crtc.

[Maarten Lankhorst]

It seems that nouveau requires this, so best to do this in the helper.
This allows nouveau to use the atomic suspend helper.

Cc: nouv...@lists.freedesktop.org
Acked-by: Ben Skeggs  #irc
Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/drm_atomic_helper.c   |  51 ++
 drivers/gpu/drm/nouveau/nouveau_display.c | 113 +-
 2 files changed, 38 insertions(+), 126 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 9203f3e933f7..ff361066381e 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2427,9 +2427,13 @@ int drm_atomic_helper_disable_all(struct drm_device *dev,
  struct drm_modeset_acquire_ctx *ctx)
 {
struct drm_atomic_state *state;
+   struct drm_connector_state *conn_state;
struct drm_connector *conn;
-   struct drm_connector_list_iter conn_iter;
-   int err;
+   struct drm_plane_state *plane_state;
+   struct drm_plane *plane;
+   struct drm_crtc_state *crtc_state;
+   struct drm_crtc *crtc;
+   int ret, i;
 
state = drm_atomic_state_alloc(dev);
if (!state)
@@ -2437,29 +2441,48 @@ int drm_atomic_helper_disable_all(struct drm_device 
*dev,
 
state->acquire_ctx = ctx;
 
-   drm_connector_list_iter_get(dev, _iter);
-   drm_for_each_connector_iter(conn, _iter) {
-   struct drm_crtc *crtc = conn->state->crtc;
-   struct drm_crtc_state *crtc_state;
-
-   if (!crtc || conn->dpms != DRM_MODE_DPMS_ON)
-   continue;
-
+   drm_for_each_crtc(crtc, dev) {
crtc_state = drm_atomic_get_crtc_state(state, crtc);
if (IS_ERR(crtc_state)) {
-   err = PTR_ERR(crtc_state);
+   ret = PTR_ERR(crtc_state);
goto free;
}
 
crtc_state->active = false;
+
+   ret = drm_atomic_set_mode_prop_for_crtc(crtc_state, NULL);
+   if (ret < 0)
+   goto free;
+
+   ret = drm_atomic_add_affected_planes(state, crtc);
+   if (ret < 0)
+   goto free;
+
+   ret = drm_atomic_add_affected_connectors(state, crtc);
+   if (ret < 0)
+   goto free;
}
 
-   err = drm_atomic_commit(state);
+   for_each_connector_in_state(state, conn, conn_state, i) {
+   ret = drm_atomic_set_crtc_for_connector(conn_state, NULL);
+   if (ret < 0)
+   goto free;
+   }
+
+   for_each_plane_in_state(state, plane, plane_state, i) {
+   ret = drm_atomic_set_crtc_for_plane(plane_state, NULL);
+   if (ret < 0)
+   goto free;
+
+   drm_atomic_set_fb_for_plane(plane_state, NULL);
+   }
+
+   ret = drm_atomic_commit(state);
 free:
-   drm_connector_list_iter_put(_iter);
drm_atomic_state_put(state);
-   return err;
+   return ret;
 }
+
 EXPORT_SYMBOL(drm_atomic_helper_disable_all);
 
 /**
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c 
b/drivers/gpu/drm/nouveau/nouveau_display.c
index d479aad97cd4..820f44bef0bd 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -625,117 +625,6 @@ nouveau_display_destroy(struct drm_device *dev)
kfree(disp);
 }
 
-static int
-nouveau_atomic_disable_connector(struct drm_atomic_state *state,
-struct drm_connector *connector)
-{
-   struct drm_connector_state *connector_state;
-   struct drm_crtc *crtc;
-   struct drm_crtc_state *crtc_state;
-   struct drm_plane_state *plane_state;
-   struct drm_plane *plane;
-   int ret;
-
-   if (!(crtc = connector->state->crtc))
-   return 0;
-
-   connector_state = drm_atomic_get_connector_state(state, connector);
-   if (IS_ERR(connector_state))
-   return PTR_ERR(connector_state);
-
-   ret = drm_atomic_set_crtc_for_connector(connector_state, NULL);
-   if (ret)
-   return ret;
-
-   crtc_state = drm_atomic_get_crtc_state(state, crtc);
-   if (IS_ERR(crtc_state))
-   return PTR_ERR(crtc_state);
-
-   ret = drm_atomic_set_mode_for_crtc(crtc_state, NULL);
-   if (ret)
-   return ret;
-
-   crtc_state->active = false;
-
-   drm_for_each_plane_mask(plane, connector->dev, crtc_state->plane_mask) {
-   plane_state = drm_atomic_get_plane_state(state, plane);
-   if (IS_ERR(plane_state))
-   return PTR_ERR(plane_state);
-
-   ret = drm_atomic_set_crtc_for_plane(plane_state, NULL);
-   if (ret)
-   return ret;
-
-   

[PATCH 2/3] drm: Convert drm_framebuffer_remove to atomic, v4.

[Maarten Lankhorst]

Instead of trying to do everything in 1 go, just do a basic safe
conversion first. We've been bitten by too many regressions in the
past.

This patch only converts drm_framebuffer_remove to atomic. The
regression sensitive part is split out to a separate patch.

v2:
- Remove plane->fb assignment, done by drm_atomic_clean_old_fb.
- Add WARN_ON when atomic_remove_fb fails.
- Always call drm_atomic_state_put.
v3:
- Use drm_drv_uses_atomic_modeset
- Handle the case where the first plane-disable-only commit fails
  with -EINVAL. Some drivers do not support this, fall back to
  disabling all crtc's in this case.
v4:
- Solve vmwgfx compatibility issue in their driver, was fixed in this
  patch by v3.
- Move only disabling primary to a separate patch.

Signed-off-by: Daniel Vetter 
Signed-off-by: Daniel Vetter 
Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/drm_atomic.c| 88 +
 drivers/gpu/drm/drm_crtc_internal.h |  1 +
 drivers/gpu/drm/drm_framebuffer.c   |  7 +++
 3 files changed, 96 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index afec53832145..285e1c23e8c9 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -2061,6 +2061,94 @@ static void complete_crtc_signaling(struct drm_device 
*dev,
kfree(fence_state);
 }
 
+int drm_atomic_remove_fb(struct drm_framebuffer *fb)
+{
+   struct drm_modeset_acquire_ctx ctx;
+   struct drm_device *dev = fb->dev;
+   struct drm_atomic_state *state;
+   struct drm_plane *plane;
+   struct drm_connector *conn;
+   struct drm_connector_state *conn_state;
+   int i, ret = 0;
+   unsigned plane_mask;
+
+   state = drm_atomic_state_alloc(dev);
+   if (!state)
+   return -ENOMEM;
+
+   drm_modeset_acquire_init(, 0);
+   state->acquire_ctx = 
+
+retry:
+   plane_mask = 0;
+   ret = drm_modeset_lock_all_ctx(dev, );
+   if (ret)
+   goto unlock;
+
+   drm_for_each_plane(plane, dev) {
+   struct drm_plane_state *plane_state;
+
+   if (plane->state->fb != fb)
+   continue;
+
+   plane_state = drm_atomic_get_plane_state(state, plane);
+   if (IS_ERR(plane_state)) {
+   ret = PTR_ERR(plane_state);
+   goto unlock;
+   }
+
+   if (plane_state->crtc->primary == plane) {
+   struct drm_crtc_state *crtc_state;
+
+   crtc_state = drm_atomic_get_existing_crtc_state(state, 
plane_state->crtc);
+
+   ret = drm_atomic_add_affected_connectors(state, 
plane_state->crtc);
+   if (ret)
+   goto unlock;
+
+   crtc_state->active = false;
+   ret = drm_atomic_set_mode_for_crtc(crtc_state, NULL);
+   if (ret)
+   goto unlock;
+   }
+
+   drm_atomic_set_fb_for_plane(plane_state, NULL);
+   ret = drm_atomic_set_crtc_for_plane(plane_state, NULL);
+   if (ret)
+   goto unlock;
+
+   plane_mask |= BIT(drm_plane_index(plane));
+
+   plane->old_fb = plane->fb;
+   }
+
+   for_each_connector_in_state(state, conn, conn_state, i) {
+   ret = drm_atomic_set_crtc_for_connector(conn_state, NULL);
+
+   if (ret)
+   goto unlock;
+   }
+
+   if (plane_mask)
+   ret = drm_atomic_commit(state);
+
+unlock:
+   if (plane_mask)
+   drm_atomic_clean_old_fb(dev, plane_mask, ret);
+
+   if (ret == -EDEADLK) {
+   drm_modeset_backoff();
+   goto retry;
+   }
+
+   drm_atomic_state_put(state);
+
+   drm_modeset_drop_locks();
+   drm_modeset_acquire_fini();
+
+   return ret;
+}
+
 int drm_mode_atomic_ioctl(struct drm_device *dev,
  void *data, struct drm_file *file_priv)
 {
diff --git a/drivers/gpu/drm/drm_crtc_internal.h 
b/drivers/gpu/drm/drm_crtc_internal.h
index 955c5690bf64..e0678f8a51cf 100644
--- a/drivers/gpu/drm/drm_crtc_internal.h
+++ b/drivers/gpu/drm/drm_crtc_internal.h
@@ -183,6 +183,7 @@ int drm_atomic_get_property(struct drm_mode_object *obj,
struct drm_property *property, uint64_t *val);
 int drm_mode_atomic_ioctl(struct drm_device *dev,
  void *data, struct drm_file *file_priv);
+int drm_atomic_remove_fb(struct drm_framebuffer *fb);
 
 
 /* drm_plane.c */
diff --git a/drivers/gpu/drm/drm_framebuffer.c 
b/drivers/gpu/drm/drm_framebuffer.c
index 28a0108a1ab8..c0e593a7f9b4 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -773,6 +773,12 @@ void 

[PATCH 0/3] drm/atomic: Make drm_framebuffer_remove atomic, again.

[Maarten Lankhorst]

This fixes a connector leak first when disabling the device,
and then converts rmfb to atomic. The behavior change is done as
a separate patch, so it can be reverted if it breaks, again..

Maarten Lankhorst (3):
  drm/atomic: Make disable_all helper fully disable the crtc.
  drm: Convert drm_framebuffer_remove to atomic, v4.
  drm/atomic: Try to preserve the crtc enabled state in drm_atomic_remove_fb.

 drivers/gpu/drm/drm_atomic.c  | 106 
 drivers/gpu/drm/drm_atomic_helper.c   |  51 ++
 drivers/gpu/drm/drm_crtc_internal.h   |   1 +
 drivers/gpu/drm/drm_framebuffer.c |   7 ++
 drivers/gpu/drm/nouveau/nouveau_display.c | 113 +-
 5 files changed, 152 insertions(+), 126 deletions(-)

-- 
2.7.4

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

[PATCH 3/3] drm/atomic: Try to preserve the crtc enabled state in drm_atomic_remove_fb.

[Maarten Lankhorst]

This introduces a slight behavioral change to rmfb. Instead of
disabling a crtc when the primary plane is disabled, we try to
preserve it.

Apart from old versions of the vmwgfx xorg driver, there is
nothing depending on rmfb disabling a crtc. Since vmwgfx is
a legacy driver we can safely only disable the plane with atomic.
In the conversion to atomic the driver will reject the config
without primary plane.

If this commit is rejected by the driver then we will still fall
back to the old behavior and turn off the crtc.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/drm_atomic.c | 22 --
 1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 285e1c23e8c9..0d5b0065208e 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -2070,7 +2070,7 @@ int drm_atomic_remove_fb(struct drm_framebuffer *fb)
struct drm_connector *conn;
struct drm_connector_state *conn_state;
int i, ret = 0;
-   unsigned plane_mask;
+   unsigned plane_mask, disable_crtcs = false;
 
state = drm_atomic_state_alloc(dev);
if (!state)
@@ -2097,7 +2097,13 @@ int drm_atomic_remove_fb(struct drm_framebuffer *fb)
goto unlock;
}
 
-   if (plane_state->crtc->primary == plane) {
+   /*
+* Some drivers do not support keeping crtc active with the
+* primary plane disabled. If we fail to commit with -EINVAL
+* then we will try to perform the same commit but with all
+* crtc's disabled for primary planes as well.
+*/
+   if (disable_crtcs && plane_state->crtc->primary == plane) {
struct drm_crtc_state *crtc_state;
 
crtc_state = drm_atomic_get_existing_crtc_state(state, 
plane_state->crtc);
@@ -2122,6 +2128,7 @@ int drm_atomic_remove_fb(struct drm_framebuffer *fb)
plane->old_fb = plane->fb;
}
 
+   /* This list is only not empty when disable_crtcs is set. */
for_each_connector_in_state(state, conn, conn_state, i) {
ret = drm_atomic_set_crtc_for_connector(conn_state, NULL);
 
@@ -2143,6 +2150,17 @@ int drm_atomic_remove_fb(struct drm_framebuffer *fb)
 
drm_atomic_state_put(state);
 
+   if (ret == -EINVAL && !disable_crtcs) {
+   disable_crtcs = true;
+
+   state = drm_atomic_state_alloc(dev);
+   if (state) {
+   state->acquire_ctx = 
+   goto retry;
+   }
+   ret = -ENOMEM;
+   }
+
drm_modeset_drop_locks();
drm_modeset_acquire_fini();
 
-- 
2.7.4

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

[PATCH] dma-buf: add support for compat ioctl

[Marek Szyprowski]

Add compat ioctl support to dma-buf. This lets one to use DMA_BUF_IOCTL_SYNC
ioctl from 32bit application on 64bit kernel. Data structures for both 32
and 64bit modes are same, so there is no need for additional translation
layer.

Signed-off-by: Marek Szyprowski 
---
 drivers/dma-buf/dma-buf.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 718f832a5c71..0007b792827b 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -325,6 +325,9 @@ static long dma_buf_ioctl(struct file *file,
.llseek = dma_buf_llseek,
.poll   = dma_buf_poll,
.unlocked_ioctl = dma_buf_ioctl,
+#ifdef CONFIG_COMPAT
+   .compat_ioctl   = dma_buf_ioctl,
+#endif
 };
 
 /*
-- 
1.9.1

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

[Bug 194579] AMDGPU: Possible size overflow detected by PaX in ttm_bo_handle_move_mem (drivers/gpu/drm/ttm/ttm_bo.c:388)

[bugzilla-daemon]

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

--- Comment #12 from PaX Team (pagee...@freemail.hu) ---
(In reply to Christian König from comment #11)
> The issue is that the offset handling should actually be transparent to TTM.
> So mem.start can have any value here which might as well overflow during the
> assignment.
> 
> So even with Nicolais suggestion of using LONG_MAX I would NAK the patch.
> 
> The only clean solution I can see is to remove bo->offset altogether and
> move that into a helper the drivers can call on demand.

obviously i'm not qualified to do that kind of surgery ;), i'd just like
to keep our existing overflow checking instrumentation for
tm_buffer_object.offset
instead of getting rid of it because of just one intentional overflow. if
setting ->offset regardless of any overflows is important then couldn't we
go the other way and change the value of AMDGPU_BO_INVALID_OFFSET to something
that would not trigger the overflow here? say LONG_MAX >> PAGE_SHIFT. would
that work/not clash with otherwise valid values for this offset? (makes me
also wonder why ULONG_MAX isn't used since that would produce an even bigger
safety zone)

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

Re: [PATCH] dma-buf/reservation: Wrap ww_mutex_trylock

[Joonas Lahtinen]

On ti, 2017-02-21 at 09:30 +, Chris Wilson wrote:
> In a similar fashion to reservation_object_lock() and
> reservation_object_unlock(), ww_mutex_trylock is also useful and so is
> worth wrapping for consistency.
> 
> Signed-off-by: Chris Wilson 
> Cc: Sumit Semwal 
> Cc: Joonas Lahtinen 
> Cc: Daniel Vetter 



> @@ -151,6 +151,26 @@ reservation_object_lock(struct reservation_object *obj,
>  }
>  
>  /**
> + * reservation_object_trylock - trylock the reservation object
> + * @obj: the reservation object
> + *
> + * Tries to lock the reservation object for exclusive access and 
> modification.
> + * Note, that the lock is only against other writers, readers will run
> + * concurrently with a writer under RCU. The seqlock is used to notify 
> readers
> + * if they overlap with a writer.
> + *
> + * Also note that since no context is provided, no deadlock protection is
> + * possible.
> + *
> + * Returns true if the lock was acquired, false otherwise.
> + */
> +static inline bool

I'd carry over the __must_check flag, with that;

Reviewed-by: Joonas Lahtinen 

Regards, Joonas

> +reservation_object_trylock(struct reservation_object *obj)
> +{
> + return ww_mutex_trylock(>lock);
> +}
> +
> +/**
>   * reservation_object_unlock - unlock the reservation object
>   * @obj: the reservation object
>   *
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 91202] Output to DVI-I (or DVI-D) is blank on Tonga (R9 285 and 380X) with multiple monitors

[bugzilla-daemon]

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

--- Comment #27 from Thomas R.  ---
With amd-staging-4.9, commit a364784ea02674736abd9d345fd74bf6787f95a1
("drm/amdgpu: expose GPU sensor related information"), it works now, but only
if DC is enabled (I guess it's DAL reborn?)

Either I didn't configure DAL correctly before (even though it showed up in
dmesg), or there was an actual change that made it work for my card between
xmas and now.

Today I lit a candle and deleted fglrx.

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

[PATCH] drm/vmwgfx: Work around drm removal of control nodes

[Thomas Hellstrom]

vmware tools has a daemon that gets layout information from the GUI and
forwards it to DRM so that the modesetting code can set preferred connector
locations and modes. This daemon was using control nodes but since control
nodes were just removed, make it possible for the daemon to use render- or
primary nodes instead. This is a bit ugly but will allow drm to proceed with
removal of the mostly unused control-node code and allow vmware to proceed
with fixing up automatic layout settings for gnome-shell/wayland.

We bump minor to inform user-space about the api change.

Cc: <sta...@vger.kernel.org>
Signed-off-by: Thomas Hellstrom <thellst...@vmware.com>
---
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 11 ++-
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |  4 ++--
 2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 541a588..d08f269 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -199,9 +199,14 @@ static const struct drm_ioctl_desc vmw_ioctls[] = {
VMW_IOCTL_DEF(VMW_PRESENT_READBACK,
  vmw_present_readback_ioctl,
  DRM_MASTER | DRM_AUTH),
+   /*
+* The permissions of the below ioctl are overridden in
+* vmw_generic_ioctl(). We require either
+* DRM_MASTER or capable(CAP_SYS_ADMIN).
+*/
VMW_IOCTL_DEF(VMW_UPDATE_LAYOUT,
  vmw_kms_update_layout_ioctl,
- DRM_MASTER | DRM_CONTROL_ALLOW),
+ DRM_RENDER_ALLOW),
VMW_IOCTL_DEF(VMW_CREATE_SHADER,
  vmw_shader_define_ioctl,
  DRM_AUTH | DRM_RENDER_ALLOW),
@@ -1123,6 +1128,10 @@ static long vmw_generic_ioctl(struct file *filp, 
unsigned int cmd,
 
return (long) vmw_execbuf_ioctl(dev, arg, file_priv,
_IOC_SIZE(cmd));
+   } else if (nr == DRM_COMMAND_BASE + DRM_VMW_UPDATE_LAYOUT) {
+   if (!drm_is_current_master(file_priv) &&
+   !capable(CAP_SYS_ADMIN))
+   return -EACCES;
}
 
if (unlikely(ioctl->cmd != cmd))
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index 1e59a48..59ff419 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -41,9 +41,9 @@
 #include 
 #include "vmwgfx_fence.h"
 
-#define VMWGFX_DRIVER_DATE "20160210"
+#define VMWGFX_DRIVER_DATE "20170221"
 #define VMWGFX_DRIVER_MAJOR 2
-#define VMWGFX_DRIVER_MINOR 11
+#define VMWGFX_DRIVER_MINOR 12
 #define VMWGFX_DRIVER_PATCHLEVEL 0
 #define VMWGFX_FILE_PAGE_OFFSET 0x0010
 #define VMWGFX_FIFO_STATIC_SIZE (1024*1024)
-- 
2.9.3

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

Re: [PATCH] [RFC] drm: Nerf DRM_CONTROL nodes

[Thomas Hellstrom]

On 02/20/2017 11:22 PM, Daniel Vetter wrote:
> On Sun, Feb 19, 2017 at 4:21 PM, Thomas Hellstrom  wrote:
>> So I think we need a quick revert of this commit or a quick stable
>> follow-up to unbreak things on our side.
> I'd much prefer we just register control nodes for vmwgfx only, with a
> commit message explaining in detail what exactly your control tool is
> using (i.e. which ioctl), plus links to the source code for future
> references. Also not sold on the immediate revert, this stuff has been
> merged since months.
> -Daniel
>

https://cgit.freedesktop.org/~thomash/open-vm-tools/commit/?h=feature/thellstrom/resolutionKMS=9bf65a22d5a06d3a706bc14578619a56e06f8a24

/Thomas

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

Re: [PATCH v3 2/2] drm/fb-helper: implement ioctl FBIO_WAITFORVSYNC

[Ville Syrjälä]

On Tue, Feb 21, 2017 at 11:00:59AM +0100, Stefan Lengfeld wrote:
> Hi Maxime,
> 
> On Wed, Feb 15, 2017 at 05:19:09PM +0100, Maxime Ripard wrote:
> > From: Stefan Christ 
> > 
> 
> Maybe change the author here. Only the boilerplate code looks my original
> patch. The real code is your work ;-)
> 
> > Implement legacy framebuffer ioctl FBIO_WAITFORVSYNC in the generic
> > framebuffer emulation driver. Legacy framebuffer users like non kms/drm
> > based OpenGL(ES)/EGL implementations may require the ioctl to
> > synchronize drawing or buffer flip for double buffering. It is tested on
> > the i.MX6.
> > 
> > Code is based on
> > 
> > https://github.com/Xilinx/linux-xlnx/blob/master/drivers/gpu/drm/xilinx/xilinx_drm_fb.c#L196
> > 
> > Signed-off-by: Stefan Christ 
> > Signed-off-by: Maxime Ripard 
> > ---
> >  drivers/gpu/drm/drm_fb_helper.c | 63 ++-
> >  include/drm/drm_fb_helper.h | 12 +-
> >  2 files changed, 74 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_fb_helper.c 
> > b/drivers/gpu/drm/drm_fb_helper.c
> > index c6de87abaca8..15ee9641c725 100644
> > --- a/drivers/gpu/drm/drm_fb_helper.c
> > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > @@ -1240,6 +1240,69 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap, 
> > struct fb_info *info)
> >  EXPORT_SYMBOL(drm_fb_helper_setcmap);
> >  
> >  /**
> > + * drm_fb_helper_ioctl - legacy ioctl implementation
> > + * @info: fbdev registered by the helper
> > + * @cmd: ioctl command
> > + * @arg: ioctl argument
> > + *
> > + * A helper to implement the standard fbdev ioctl. Only
> > + * FBIO_WAITFORVSYNC is implemented for now.
> > + */
> > +int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd,
> > +   unsigned long arg)
> > +{
> > +   struct drm_fb_helper *fb_helper = info->par;
> > +   struct drm_device *dev = fb_helper->dev;
> > +   struct drm_mode_set *mode_set;
> > +   struct drm_crtc *crtc;
> > +   u32 karg;
> > +   int ret = 0;
> > +
> > +   mutex_lock(>mode_config.mutex);
> > +   if (!drm_fb_helper_is_bound(fb_helper)) {
> > +   ret = -EBUSY;
> > +   goto unlock;
> > +   }
> > +
> > +   switch (cmd) {
> > +   case FBIO_WAITFORVSYNC:
> > +   if (get_user(karg, (__u32 __user *)arg)) {
> > +   ret = -EFAULT;
> > +   goto unlock;
> > +   }
> > +
> > +   if (karg >= fb_helper->crtc_count) {
> > +   ret = -EINVAL;
> > +   goto unlock;
> > +   }
> 
> Ville Syrjälä said [1]:
> 
> FBIO_WAITFORVSYNC takes the crtc as a parmeter, so I'm not sure we want
> to do this for all the crtcs. Though what that crtc means for fb is
> rather poorly defined.
> 
> Don't think it takes the crtc as a parameter in 'arg'. When you look at the
> existing fb_ioctl implementations in the directory drivers/video/fbdev/, the
> argument 'arg' is either ignored or must be '0'.

Have a look at matroxfb.

> 
> Furthmore most exiting userspace code just passes the value "0" as the
> argument. For example DirectFB:
> 
>  static const int zero = 0;
>  [...]
>  if (ioctl( dfb_fbdev->fd, FBIO_WAITFORVSYNC,  ))

Again the matrox driver is different. And looks like unichrome might have
done something even more exotic with the argument.

But I do agree that using this with the kms fbdev implementation could
be quite problematic as you can't actually know which crtcs the
fb_helper has picked.

> 
> I see two options here: 
> 
> 1/ Just wait for the first vsync event on the first enabled crtc. This is
>a good approximation for the old framebuffer API. It has no concept of
>multiple crtcs with concurrenctly running scan out processes. (Maybe apart
>from extra vendor implementations). So if there are really more than one 
> active
>crtcs in the system, bad luck with framebuffer API. There will be tearing.
>Userspace has to use the new DRM/KMS API.
> 
> 2/ Wait for a single vsync event on all active crtcs as Ville Syrjälä 
>described here [2] in the optimal implementation.
> 
> Kind regards / Mit freundlichen Grüßen
>   Stefan Lengfeld
> 
> [1] https://lists.freedesktop.org/archives/dri-devel/2017-February/132617.html
> [2] https://lists.freedesktop.org/archives/dri-devel/2017-February/132820.html
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: DRM_CONTROL node breakage (Re: [PATCH] [RFC] drm: Nerf DRM_CONTROL nodes)

[Thomas Hellstrom]

On 02/21/2017 06:34 AM, David Airlie wrote:
>> No.
>>
>> IMO Not fixing this immediately through stable is out of the question.
>> The deal is that we don't break userspace.
>> Having said that, I'm not against a long term vmwgfx-only solution. But
>> let's fix this now.
>>
>> Admittedly we missed testing this but you got to understand that not all
>> developer teams have a multitude of
>> developers (we have on average one for the whole linux graphics driver
>> stack except GL), and the bug
>> doesn't show up for QE on regression testing unless they run
>> gnome-sheel/Wayland which they currently don't, and I guess they've been
>> focused on the fb2 regression.
>>
>> It's no secret that we've been using the control nodes for some time.
>> The CONTROL_ALLOW is present in the
>> driver private ioctls and the commit has been there since 2016.
>>
>> The user-space code has been present in vmware-tools also since that
>> commit and due to the long release cycles of
>> open-vm-tools the open-vm-tools version was just about to be released.
>> It's necessary for non-xorg
> can you send a revert against drm-next? I'm not sure how clean it will be.
>
> there might be an intermediate step.
>
> Then can we port vmtools of this behaviour, not even sure what it is doing.
>
> Dave.

So after a quick investigation of the impact it looks like the daemon
patch was pulled out of the Fedora open-vm-tools update in time. This
limits the impact to within VMware where we can update the daemon code
and rerun the test cycle. I've posted a patch that makes it possible for
us to use render-nodes instead of control nodes.

/Thomas



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

Re: [PATCH v3 2/2] drm/fb-helper: implement ioctl FBIO_WAITFORVSYNC

[Stefan Lengfeld]

Hi Maxime,

On Wed, Feb 15, 2017 at 05:19:09PM +0100, Maxime Ripard wrote:
> From: Stefan Christ 
> 

Maybe change the author here. Only the boilerplate code looks my original
patch. The real code is your work ;-)

> Implement legacy framebuffer ioctl FBIO_WAITFORVSYNC in the generic
> framebuffer emulation driver. Legacy framebuffer users like non kms/drm
> based OpenGL(ES)/EGL implementations may require the ioctl to
> synchronize drawing or buffer flip for double buffering. It is tested on
> the i.MX6.
> 
> Code is based on
> 
> https://github.com/Xilinx/linux-xlnx/blob/master/drivers/gpu/drm/xilinx/xilinx_drm_fb.c#L196
> 
> Signed-off-by: Stefan Christ 
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/gpu/drm/drm_fb_helper.c | 63 ++-
>  include/drm/drm_fb_helper.h | 12 +-
>  2 files changed, 74 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index c6de87abaca8..15ee9641c725 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -1240,6 +1240,69 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct 
> fb_info *info)
>  EXPORT_SYMBOL(drm_fb_helper_setcmap);
>  
>  /**
> + * drm_fb_helper_ioctl - legacy ioctl implementation
> + * @info: fbdev registered by the helper
> + * @cmd: ioctl command
> + * @arg: ioctl argument
> + *
> + * A helper to implement the standard fbdev ioctl. Only
> + * FBIO_WAITFORVSYNC is implemented for now.
> + */
> +int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd,
> + unsigned long arg)
> +{
> + struct drm_fb_helper *fb_helper = info->par;
> + struct drm_device *dev = fb_helper->dev;
> + struct drm_mode_set *mode_set;
> + struct drm_crtc *crtc;
> + u32 karg;
> + int ret = 0;
> +
> + mutex_lock(>mode_config.mutex);
> + if (!drm_fb_helper_is_bound(fb_helper)) {
> + ret = -EBUSY;
> + goto unlock;
> + }
> +
> + switch (cmd) {
> + case FBIO_WAITFORVSYNC:
> + if (get_user(karg, (__u32 __user *)arg)) {
> + ret = -EFAULT;
> + goto unlock;
> + }
> +
> + if (karg >= fb_helper->crtc_count) {
> + ret = -EINVAL;
> + goto unlock;
> + }

Ville Syrjälä said [1]:

FBIO_WAITFORVSYNC takes the crtc as a parmeter, so I'm not sure we want
to do this for all the crtcs. Though what that crtc means for fb is
rather poorly defined.

Don't think it takes the crtc as a parameter in 'arg'. When you look at the
existing fb_ioctl implementations in the directory drivers/video/fbdev/, the
argument 'arg' is either ignored or must be '0'.

Furthmore most exiting userspace code just passes the value "0" as the
argument. For example DirectFB:

 static const int zero = 0;
 [...]
 if (ioctl( dfb_fbdev->fd, FBIO_WAITFORVSYNC,  ))

I see two options here: 

1/ Just wait for the first vsync event on the first enabled crtc. This is
   a good approximation for the old framebuffer API. It has no concept of
   multiple crtcs with concurrenctly running scan out processes. (Maybe apart
   from extra vendor implementations). So if there are really more than one 
active
   crtcs in the system, bad luck with framebuffer API. There will be tearing.
   Userspace has to use the new DRM/KMS API.

2/ Wait for a single vsync event on all active crtcs as Ville Syrjälä 
   described here [2] in the optimal implementation.

Kind regards / Mit freundlichen Grüßen
Stefan Lengfeld

[1] https://lists.freedesktop.org/archives/dri-devel/2017-February/132617.html
[2] https://lists.freedesktop.org/archives/dri-devel/2017-February/132820.html
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 194579] AMDGPU: Possible size overflow detected by PaX in ttm_bo_handle_move_mem (drivers/gpu/drm/ttm/ttm_bo.c:388)

[bugzilla-daemon]

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

--- Comment #11 from Christian König (deathsim...@vodafone.de) ---
(In reply to PaX Team from comment #9)
> would the following workaround do the job of not triggering the overflow and
> not causing any other logic bugs for our purposes:

Not really.

The issue is that the offset handling should actually be transparent to TTM. So
mem.start can have any value here which might as well overflow during the
assignment.

So even with Nicolais suggestion of using LONG_MAX I would NAK the patch.

The only clean solution I can see is to remove bo->offset altogether and move
that into a helper the drivers can call on demand.

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

Re: [PATCH v2] drm: Add DPCD definitions for DP 1.4 DSC feature

[Jani Nikula]

On Fri, 17 Feb 2017, Manasi Navare  wrote:
> Display stream compression is supported on DP 1.4 DP
> devices. This patch adds the corersponding DPCD
> register definitions for DSC.
>
> v2:
> * Rebased on drm-tip
>
> Signed-off-by: Manasi Navare 
> Cc: Jani Nikula 
> Cc: Paulo Zanoni 
> Cc: dri-devel@lists.freedesktop.org

Tedious work to cross check this stuff against the spec... found one
real issue; while at it please fix a few nitpicks that I would otherwise
have ignored.

BR,
Jani.


> ---
>  include/drm/drm_dp_helper.h | 102 
> 
>  1 file changed, 102 insertions(+)
>
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index ba89295..4c1fc26 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -179,6 +179,108 @@
>  
>  #define DP_GUID  0x030   /* 1.2 */
>  
> +#define DP_DSC_SUPPORT  0x060   /* DP 1.4 */
> +# define DP_DSC_DECOMPRESSION_IS_SUPPORTED  (1 << 0)
> +
> +#define DP_DSC_REV  0x061
> +# define DP_DSC_MAJOR_MASK  (15 << 0)
> +# define DP_DSC_MINOR_MASK  (15 << 4)
> +# define DP_DSC_MINOR_SHIFT 4

Nitpick: Hex is preferred for masks. Same for all masks
below. MAJOR_SHIFT for completeness.

> +
> +#define DP_DSC_RC_BUF_BLK_SIZE  0x062
> +# define DP_DSC_RC_BUF_BLK_SIZE_1   0x0
> +# define DP_DSC_RC_BUF_BLK_SIZE_4   0x1
> +# define DP_DSC_RC_BUF_BLK_SIZE_16  0x2
> +# define DP_DSC_RC_BUF_BLK_SIZE_64  0x3
> +
> +#define DP_DSC_RC_BUF_SIZE  0x063
> +
> +#define DP_DSC_SLICE_CAP_1  0x064
> +# define DP_DSC_1_PER_DP_DSC_SINK   (1 << 0)
> +# define DP_DSC_2_PER_DP_DSC_SINK   (1 << 1)
> +# define DP_DSC_4_PER_DP_DSC_SINK   (1 << 3)
> +# define DP_DSC_6_PER_DP_DSC_SINK   (1 << 4)
> +# define DP_DSC_8_PER_DP_DSC_SINK   (1 << 5)
> +# define DP_DSC_10_PER_DP_DSC_SINK  (1 << 6)
> +# define DP_DSC_12_PER_DP_DSC_SINK  (1 << 7)
> +
> +#define DP_DSC_LINE_BUF_BIT_DEPTH   0x065
> +# define DP_DSC_LINE_BUF_BIT_DEPTH_MASK (15 << 0)
> +# define DP_DSC_LINE_BUF_BIT_DEPTH_90x0
> +# define DP_DSC_LINE_BUF_BIT_DEPTH_10   0x1
> +# define DP_DSC_LINE_BUF_BIT_DEPTH_11   0x2
> +# define DP_DSC_LINE_BUF_BIT_DEPTH_12   0x3
> +# define DP_DSC_LINE_BUF_BIT_DEPTH_13   0x4
> +# define DP_DSC_LINE_BUF_BIT_DEPTH_14   0x5
> +# define DP_DSC_LINE_BUF_BIT_DEPTH_15   0x6
> +# define DP_DSC_LINE_BUF_BIT_DEPTH_16   0x7
> +# define DP_DSC_LINE_BUF_BIT_DEPTH_80x8
> +
> +#define DP_DSC_BLK_PREDICTION_SUPPORT   0x066
> +# define DP_DSC_BLK_PREDICTION_IS_SUPPORTED (1 << 0)
> +
> +#define DP_DSC_MAX_BITS_PER_PIXEL_LOW   0x067   /* eDP 1.4 */
> +
> +#define DP_DSC_MAX_BITS_PER_PIXEL_HI0x068   /* eDP 1.4 */
> +
> +#define DP_DSC_DEC_COLOR_FORMAT_CAP 0x069
> +# define DP_DSC_RGB (1 << 0)
> +# define DP_DSC_YCbCr444(1 << 1)
> +# define DP_DSC_YCbCr422_Simple (1 << 2)
> +# define DP_DSC_YCbCr422_Native (1 << 3)
> +# define DP_DSC_YCbCr420_Native (1 << 4)
> +
> +#define DP_DSC_DEC_COLOR_DEPTH_CAP  0x06A
> +# define DP_DSC_8_BPC   (1 << 1)
> +# define DP_DSC_10_BPC  (1 << 2)
> +# define DP_DSC_12_BPC  (1 >> 3)

Oops, shifting to wrong direction!

> +
> +#define DP_DSC_PEAK_THROUGHPUT  0x06B
> +# define DP_DSC_THROUGHPUT_MODE_0_340   0x1
> +# define DP_DSC_THROUGHPUT_MODE_0_400   0x2
> +# define DP_DSC_THROUGHPUT_MODE_0_450   0x3
> +# define DP_DSC_THROUGHPUT_MODE_0_500   0x4
> +# define DP_DSC_THROUGHPUT_MODE_0_550   0x5
> +# define DP_DSC_THROUGHPUT_MODE_0_600   0x6
> +# define DP_DSC_THROUGHPUT_MODE_0_650   0x7
> +# define DP_DSC_THROUGHPUT_MODE_0_700   0x8
> +# define DP_DSC_THROUGHPUT_MODE_0_750   0x9
> +# define DP_DSC_THROUGHPUT_MODE_0_800   0xA
> +# define DP_DSC_THROUGHPUT_MODE_0_850   0xB
> +# define DP_DSC_THROUGHPUT_MODE_0_900   0xC
> +# define DP_DSC_THROUGHPUT_MODE_0_950   0xD
> +# define DP_DSC_THROUGHPUT_MODE_0_1000  0xE

Nitpick: MODE_0_MASK and MODE_0_SHIFT for completeness. Seems
inconsistent to use hex for MODE_0 values and dec for MODE_1 values.

> +# define DP_DSC_THROUGHPUT_MODE_1_MASK  (15 << 4)
> +# define DP_DSC_THROUGHPUT_MODE_1_SHIFT 4
> +# define DP_DSC_THROUGHPUT_MODE_1_340   (1 << 4)
> +# define DP_DSC_THROUGHPUT_MODE_1_400   (2 << 4)
> +# define DP_DSC_THROUGHPUT_MODE_1_450   (3 << 4)
> +# define DP_DSC_THROUGHPUT_MODE_1_500   (4 << 4)
> +# define DP_DSC_THROUGHPUT_MODE_1_550   (5 << 4)
> +# define DP_DSC_THROUGHPUT_MODE_1_600   (6 << 4)
> +# 

[PATCH] dma-buf/reservation: Wrap ww_mutex_trylock

[Chris Wilson]

In a similar fashion to reservation_object_lock() and
reservation_object_unlock(), ww_mutex_trylock is also useful and so is
worth wrapping for consistency.

Signed-off-by: Chris Wilson 
Cc: Sumit Semwal 
Cc: Joonas Lahtinen 
Cc: Daniel Vetter 
---
 include/linux/reservation.h | 20 
 1 file changed, 20 insertions(+)

diff --git a/include/linux/reservation.h b/include/linux/reservation.h
index 24da961b085d..28d544364e52 100644
--- a/include/linux/reservation.h
+++ b/include/linux/reservation.h
@@ -151,6 +151,26 @@ reservation_object_lock(struct reservation_object *obj,
 }
 
 /**
+ * reservation_object_trylock - trylock the reservation object
+ * @obj: the reservation object
+ *
+ * Tries to lock the reservation object for exclusive access and modification.
+ * Note, that the lock is only against other writers, readers will run
+ * concurrently with a writer under RCU. The seqlock is used to notify readers
+ * if they overlap with a writer.
+ *
+ * Also note that since no context is provided, no deadlock protection is
+ * possible.
+ *
+ * Returns true if the lock was acquired, false otherwise.
+ */
+static inline bool
+reservation_object_trylock(struct reservation_object *obj)
+{
+   return ww_mutex_trylock(>lock);
+}
+
+/**
  * reservation_object_unlock - unlock the reservation object
  * @obj: the reservation object
  *
-- 
2.11.0

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

[Bug 194579] AMDGPU: Possible size overflow detected by PaX in ttm_bo_handle_move_mem (drivers/gpu/drm/ttm/ttm_bo.c:388)

[bugzilla-daemon]

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

--- Comment #10 from Nicolai Hähnle (nhaeh...@gmail.com) ---
1. That shouldn't compile (use LONG_MAX).
2. The cur_placement still needs to be updated even in that case.

Guarding only the assignment to bo->offset in this way is a reasonable
workaround, I think.

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

Re: [PATCH] drm: drm_printer: add __printf validation

[Joe Perches]

On Tue, 2017-02-21 at 11:02 +0200, Jani Nikula wrote:
> On Tue, 21 Feb 2017, Joe Perches  wrote:
> > On Tue, 2017-02-21 at 10:26 +0200, Jani Nikula wrote:
> > > You know how this stuff works, please split it up to get the stuff
> > > merged.
> > 
> > Quite well actually.
> > 
> > Fix it as you think appropriate.
> > But in any case, fix it.
> 
> Yes, I'm sure someone will eventually send patches I can apply.

As you know it's a defect, you or one
of the other maintainers of that file
should fix it and not wait for what you
consider the ideal patch.

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

[Bug 194645] amdgpu: amdgpu_resume failed

[bugzilla-daemon]

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

--- Comment #3 from Mateusz Lenik (m...@mlen.pl) ---
I'll try to do it later today.

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

Re: [PATCH] drm: drm_printer: add __printf validation

[Jani Nikula]

On Tue, 21 Feb 2017, Joe Perches  wrote:
> On Tue, 2017-02-21 at 10:26 +0200, Jani Nikula wrote:
>> You know how this stuff works, please split it up to get the stuff
>> merged.
>
> Quite well actually.
>
> Fix it as you think appropriate.
> But in any case, fix it.

Yes, I'm sure someone will eventually send patches I can apply.

BR,
Jani.

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

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Avoid decomposing a signal-on-any fence-array

[Joonas Lahtinen]

On ma, 2017-02-20 at 13:12 +0100, Maarten Lankhorst wrote:
> Op 20-02-17 om 13:03 schreef Chris Wilson:
> > 
> > On Mon, Feb 20, 2017 at 01:32:42PM +0200, Joonas Lahtinen wrote:
> > > 
> > > Smells like a helper function? While that helper is finding the way
> > > upstream;
> > Blurgh.
> > 
> > enum dma_fence_array_signal_mode {
> > DMA_FENCE_ARRAY_SIGNAL_ON_ALL = 0,
> > DMA_FENCE_ARRAY_SIGNAL_ON_ANY,
> > };
> > 
> > enum dma_fence_array_signal_mode
> > dma_fence_array_get_signaling_mode(struct dma_fence_array *array)
> > {   
> > return test_bit(DMA_FENCE_ARRAY_SIGNAL_ANY, >base.flags) ?
> > DMA_FENCE_ARRAY_SIGNAL_ON_ANY : 
> > DMA_FENCE_ARRAY_SIGNAL_ON_ALL;
> > }
> > 
> > if (!dma_fence_is_array(fence) ||
> > dma_fence_array_get_signaling_mode(to_dma_fence_array(fence)) == 
> > DMA_FENCE_ARRAY_SIGNAL_ON_ANY)
> > 
> > Hmm. Not happy with that yet.
> > -Chris
> > 
> bool dma_fence_array_signal_on_any with a WARN_ON(!dma_fence_is_array(fence))?

I was also thinking along these lines.

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 194645] amdgpu: amdgpu_resume failed

[bugzilla-daemon]

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

--- Comment #2 from Michel Dänzer (mic...@daenzer.net) ---
Can you bisect?

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

Re: [PULL] mxsfb fixes

[Jani Nikula]

On Mon, 20 Feb 2017, Marek Vasut  wrote:
> On 02/20/2017 10:05 AM, Dave Airlie wrote:
>> On 20 Feb. 2017 18:29, "Marek Vasut"  wrote:
>> 
>> On 02/20/2017 03:56 AM, Dave Airlie wrote:
>>> On 19 February 2017 at 08:25, Marek Vasut  wrote:
 On 02/17/2017 09:34 PM, Dave Airlie wrote:
> On 17 February 2017 at 18:00, Marek Vasut  wrote:
>> On 02/17/2017 03:41 AM, Dave Airlie wrote:
>>> On 16 February 2017 at 08:16, Marek Vasut  wrote:
 Hi,

 I collected the MXSFB fixes, based on top of airlied/drm-fixes:
>>>
>>> At this stage I'd rather not give these to Linus, can you rebase them
>> onto
>>> drm-next, and resend, feel free to add stable cc's.
>>>
>>> Fixes like this should really be getting to me sooner than rc8.
>>
>> I know, sorry about that. I was totally overloaded in the past weeks.
>> What about getting them to rc1, any chance for that ?
>
> Yes if you can rebase them onto drm-next.

 Ha, got it. Try the following:

 The following changes since commit 9ca70356a9260403c1bda40d942935
>> e55d00c11c:

   Revert "drm: Resurrect atomic rmfb code, v3" (2017-02-17 12:39:04
>> +1000)

 are available in the git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/marex/linux-2.6.git
 c72a2ec8208b40683fbd2970684ffbf3a8c7d17e
>>>
>>> Nearly, put please use a tag :-)
>> 
>> I'm sure you can pull this batch without a tag ;-)
>> 
>> 
>> No, I really need tags preferably signed.
>> 
>> Otherwise the merge is all ugly.
>> 
>> 
>> What do you have in mind for the next PR
>> 
>> 
>> Not sure I follow.
>
> What do you need to get these five fixes applied, ideally without much
> further annoyance to either of us. Ideally point me to some docs.

Tag the head of the branch you want pulled. Push the tag to the repo you
want Dave to pull from. Generate the pull request using the tag instead
of branch.

Something along the lines of:

$ git tag $tag $remote/$branch
$ git push $remote $tag
$ git request-pull $upstream $url $tag

Replace $vars with what you have. Use git tag -s option to do a signed
tag.

HTH,
Jani.

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

Re: [PATCH] drm: drm_printer: add __printf validation

[Joe Perches]

On Tue, 2017-02-21 at 10:26 +0200, Jani Nikula wrote:
> You know how this stuff works, please split it up to get the stuff
> merged.

Quite well actually.

Fix it as you think appropriate.
But in any case, fix it.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 194645] amdgpu: amdgpu_resume failed

[bugzilla-daemon]

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

--- Comment #1 from Mateusz Lenik (m...@mlen.pl) ---
Created attachment 254851
  --> https://bugzilla.kernel.org/attachment.cgi?id=254851=edit
full dmesg

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

[Bug 194645] New: amdgpu: amdgpu_resume failed

[bugzilla-daemon]

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

Bug ID: 194645
   Summary: amdgpu: amdgpu_resume failed
   Product: Drivers
   Version: 2.5
Kernel Version: 4.10
  Hardware: x86-64
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-...@kernel-bugs.osdl.org
  Reporter: m...@mlen.pl
Regression: No

amdgpu fails to resume from suspend on 4.10 kernel, 4.9.11 worked fine.
Steps to reproduce:

# echo devices > /sys/power/pm_test
# pm-suspend

Network cards successfully resume, so I was able to save dmesg.

[  397.627426] PM: Suspending system (mem)
[  397.627446] Suspending console(s) (use no_console_suspend to debug)
[  397.631850] sd 5:0:0:0: [sdc] Synchronizing SCSI cache
[  397.632039] sd 4:0:0:0: [sdb] Synchronizing SCSI cache
[  397.632105] sd 5:0:0:0: [sdc] Stopping disk
[  397.632290] sd 2:0:0:0: [sda] Synchronizing SCSI cache
[  397.632330] sd 4:0:0:0: [sdb] Stopping disk
[  397.632408] sd 2:0:0:0: [sda] Stopping disk
[  397.634055] serial 00:04: disabled
[  397.634414] serial 00:03: disabled
[  397.640880] pcieport :00:1c.3: System wakeup enabled by ACPI
[  397.660463] pcieport :00:1c.2: System wakeup enabled by ACPI
[  398.763780] PM: suspend of devices complete after 1133.531 msecs
[  398.763783] suspend debug: Waiting for 5 second(s).
[  403.788120] sd 2:0:0:0: [sda] Starting disk
[  403.788222] sd 4:0:0:0: [sdb] Starting disk
[  403.788371] sd 5:0:0:0: [sdc] Starting disk
[  403.790105] power_meter ACPI000D:00: Found ACPI power meter.
[  403.790337] rtc_cmos 00:00: System wakeup disabled by ACPI
[  403.791949] serial 00:03: activated
[  403.793332] serial 00:04: activated
[  403.800245] pcieport :00:1c.2: System wakeup disabled by ACPI
[  403.800261] pcieport :00:1c.3: System wakeup disabled by ACPI
[  403.828004] [drm] PCIE GART of 8192M enabled (table at 0x0004).
[  403.831686] DPM is already running
[  403.841652] [drm] ring test on 0 succeeded in 14 usecs
[  403.860221] igb :05:00.0 enp5s0: igb: enp5s0 NIC Link is Up 1000 Mbps
Full Duplex, Flow Control: RX
[  404.100306] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[  404.100332] ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[  404.102286] ata3.00: supports DRM functions and may not be fully accessible
[  404.105189] ata4.00: configured for UDMA/100
[  404.107085] ata3.00: disabling queued TRIM support
[  404.107348] ata3.00: supports DRM functions and may not be fully accessible
[  404.108258] ata1: SATA link down (SStatus 0 SControl 300)
[  404.108263] ata8: SATA link down (SStatus 0 SControl 300)
[  404.108481] ata7: SATA link down (SStatus 0 SControl 300)
[  404.109098] ata2: SATA link down (SStatus 0 SControl 300)
[  404.109101] ata10: SATA link down (SStatus 0 SControl 300)
[  404.109118] ata9: SATA link down (SStatus 0 SControl 300)
[  404.109137] ata5: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[  404.109165] ata6: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[  404.112123] ata3.00: disabling queued TRIM support
[  404.112190] ata3.00: configured for UDMA/133
[  405.194437] [drm:gfx_v8_0_ring_test_ring] *ERROR* amdgpu: ring 1 test failed
(scratch(0xC040)=0xCAFEDEAD)
[  405.344148] [drm:gfx_v8_0_ring_test_ring] *ERROR* amdgpu: ring 2 test failed
(scratch(0xC040)=0xCAFEDEAD)
[  405.493818] [drm:gfx_v8_0_ring_test_ring] *ERROR* amdgpu: ring 3 test failed
(scratch(0xC040)=0xCAFEDEAD)
[  405.643453] [drm:gfx_v8_0_ring_test_ring] *ERROR* amdgpu: ring 4 test failed
(scratch(0xC040)=0xCAFEDEAD)
[  405.793096] [drm:gfx_v8_0_ring_test_ring] *ERROR* amdgpu: ring 5 test failed
(scratch(0xC040)=0xCAFEDEAD)
[  405.942823] [drm:gfx_v8_0_ring_test_ring] *ERROR* amdgpu: ring 6 test failed
(scratch(0xC040)=0xCAFEDEAD)
[  406.092469] [drm:gfx_v8_0_ring_test_ring] *ERROR* amdgpu: ring 7 test failed
(scratch(0xC040)=0xCAFEDEAD)
[  406.242085] [drm:gfx_v8_0_ring_test_ring] *ERROR* amdgpu: ring 8 test failed
(scratch(0xC040)=0xCAFEDEAD)
[  406.352370] [drm:sdma_v3_0_ring_test_ring] *ERROR* amdgpu: ring 9 test
failed (0xCAFEDEAD)
[  406.352375] [drm:amdgpu_resume] *ERROR* resume of IP block 
failed -22
[  406.352378] [drm:amdgpu_device_resume] *ERROR* amdgpu_resume failed (-22).
[  407.382569] [drm:gfx_v8_0_ring_test_ib] *ERROR* amdgpu: IB test timed out.
[  407.382578] [drm:amdgpu_ib_ring_tests] *ERROR* amdgpu: failed testing IB on
GFX ring (-110).
[  407.382583] [drm:amdgpu_device_resume] *ERROR* ib ring test failed (-110).
[  407.383927] amdgpu :02:00.0: 9e2a95b8c800 pin failed
[  407.485003] [drm] PCIE GART of 8192M enabled (table at 0x0004).
[  407.488228] DPM is already running
[  407.498215] [drm] ring test on 0 succeeded in 14 usecs
[  408.812575] [drm:gfx_v8_0_ring_test_ring] *ERROR* amdgpu: ring 1 test failed
(scratch(0xC040)=0xCAFEDEAD)
[  408.958365] 

Re: [PATCH] drm: drm_printer: add __printf validation

[Jani Nikula]

On Mon, 20 Feb 2017, Joe Perches  wrote:
> On Mon, 2017-02-20 at 12:17 +, Eric Engestrom wrote:
>> On Wednesday, 2017-02-15 15:33:18 -0800, Joe Perches wrote:
>> > drm_printf does not currently use the compiler to verify
>> > format and arguments.  Make it do so.
>> > 
>> > Miscellanea:
>> > 
>> > o Add appropriate #include files for __printf and struct va_format
>> > o Convert dev_printk to dev_info
>> 
>> I think these unrelated changes should be in 4 patches:
>> 1 - add annotation to check the format string against the arguments
>> (linux/compiler.h should be added here)
>> 2 - add missing linux/printk.h header for struct va_format
>> Note that I think a forward declaration is more appropriate here, as
>> we only use pointers to this struct in this file, we never try to
>> look inside. On the other hand:
>> 3 - drm_print.c needs the header in drm_printf(), but as a separate
>> patch
>> 4 - convert dev_printk to dev_info (you need to include linux/device.h
>> there)
>
> I am not a big fan of making trivial patches into a series.

It's standard procedure in kernel development to split out unrelated
changes into individual patches, regardless of whether you think they
are trivial or not. Four is probably excessive, but you get the idea.

>> You can add my r-b on all four patches when you send them to the list :)
>
> If you want to break it up, go ahead.

You know how this stuff works, please split it up to get the stuff
merged.


BR,
Jani.


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

Re: [Intel-gfx] [PATCH v3 5/6] drm/i915: enable scrambling

[Sharma, Shashank]

Thanks for the review Maarten.

My comments inline.


Regards

Shashank


On 2/20/2017 5:48 PM, Maarten Lankhorst wrote:

Op 10-02-17 om 17:29 schreef Shashank Sharma:

Geminilake platform sports a native HDMI 2.0 controller, and is
capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec
mendates scrambling for these higher clocks, for reduced RF footprint.

This patch checks if the monitor supports scrambling, and if required,
enables it during the modeset.

V2: Addressed review comments from Ville:
- Do not track scrambling status in DRM layer, track somewhere in
   driver like in intel_crtc_state.
- Don't talk to monitor at such a low layer, set monitor scrambling
   in intel_enable_ddi() before enabling the port.

V3: Addressed review comments from Jani
- In comments, function names, use "sink" instead of "monitor",
   so that the implementation could be close to the language of
   HDMI spec.

Signed-off-by: Shashank Sharma 
---
  drivers/gpu/drm/i915/i915_reg.h   |   4 ++
  drivers/gpu/drm/i915/intel_ddi.c  |  28 ++
  drivers/gpu/drm/i915/intel_drv.h  |  14 +
  drivers/gpu/drm/i915/intel_hdmi.c | 106 ++
  4 files changed, 152 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 141a5c1..81cf10b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7819,7 +7819,11 @@ enum {
  #define  TRANS_DDI_EDP_INPUT_B_ONOFF  (5<<12)
  #define  TRANS_DDI_EDP_INPUT_C_ONOFF  (6<<12)
  #define  TRANS_DDI_DP_VC_PAYLOAD_ALLOC(1<<8)
+#define  TRANS_DDI_HDMI_SCRAMBLER_CTS_ENABLE (1<<7)
+#define  TRANS_DDI_HDMI_SCRAMBLER_RESET_FREQ (1<<6)
  #define  TRANS_DDI_BFI_ENABLE (1<<4)
+#define  TRANS_DDI_HIGH_TMDS_CHAR_RATE (1<<4)
+#define  TRANS_DDI_HDMI_SCRAMBLING (1<<0)
  
  /* DisplayPort Transport Control */

  #define _DP_TP_CTL_A  0x64040
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index cd6fedd..bd8293d 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1278,6 +1278,11 @@ void intel_ddi_enable_transcoder_func(struct drm_crtc 
*crtc)
temp |= TRANS_DDI_MODE_SELECT_HDMI;
else
temp |= TRANS_DDI_MODE_SELECT_DVI;
+
+   if (IS_GEMINILAKE(dev_priv))
+   temp = intel_hdmi_handle_source_scrambling(
+   intel_encoder,
+   _crtc->config->base.adjusted_mode, temp);
} else if (type == INTEL_OUTPUT_ANALOG) {
temp |= TRANS_DDI_MODE_SELECT_FDI;
temp |= (intel_crtc->config->fdi_lanes - 1) << 1;
@@ -1843,6 +1848,21 @@ static void intel_enable_ddi(struct intel_encoder 
*intel_encoder,
struct intel_digital_port *intel_dig_port =
enc_to_dig_port(encoder);
  
+		if (IS_GEMINILAKE(dev_priv)) {

+   struct intel_crtc *crtc = to_intel_crtc(encoder->crtc);
+   /*
+* GLK sports a native HDMI 2.0 controller. If required
+* clock rate is > 340 Mhz && scrambling is supported
+* by sink, enable scrambling before enabling the
+* HDMI 2.0 port. The sink can choose to disable the
+* scrambling if it doesn't detect a scrambled within
+* 100 ms.
+*/
+   intel_hdmi_handle_sink_scrambling(intel_encoder,
+   conn_state->connector,
+   crtc->config, true);
+   }
+
/* In HDMI/DVI mode, the port width, and swing/emphasis values
 * are ignored so nothing special needs to be done besides
 * enabling the port.
@@ -1875,6 +1895,14 @@ static void intel_disable_ddi(struct intel_encoder 
*intel_encoder,
if (old_crtc_state->has_audio)
intel_audio_codec_disable(intel_encoder);
  
+	if (type == INTEL_OUTPUT_HDMI) {

+   struct intel_crtc *intel_crtc = to_intel_crtc(encoder->crtc);
+
+   intel_hdmi_handle_sink_scrambling(intel_encoder,
+   old_conn_state->connector,
+   intel_crtc->config, false);
+   }
+
if (type == INTEL_OUTPUT_EDP) {
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
  
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h

index 6e37fba..df0170b88 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -691,6 +691,12 @@ struct intel_crtc_state {
  
  	/* Gamma mode programmed on the pipe */

uint32_t gamma_mode;
+
+   /* HDMI scrambling status (sink) */
+   bool