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

[Maarten Lankhorst]

Op 07-11-17 om 15:31 schreef Daniel Vetter:
> On Wed, Nov 01, 2017 at 04:04:33PM +0100, Maarten Lankhorst wrote:
>> 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.
>>
>> Vmwgfx' and simple kms helper atomic implementation rejects CRTC
>> enabled without plane, so we can do this safely.
>>
>> If the atomic commit is rejected by the driver then we will still
>> fall back to the old behavior and turn off the crtc.
>>
>> Changes since v1:
>> - Restart completely when rmfb with crtc on fails (Sean Paul).
>>
>> Signed-off-by: Maarten Lankhorst 
>> Cc: Sean Paul 
>> Cc: Daniel Vetter 
> Reviewed-by: Daniel Vetter 
Thanks, pushed. :)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH] drm/ttm: set bo->resv point to tbo->ttm_resv after individualize_resv

[He, Roger]

I guess this because you move the resv changing out of lock of bo->resv.
Because at the beginning ttm_mem_evict_first may __ttm_bo_reserve(bo->resv) 
success, and then bo->resv has been changed by another thread. That is not 
matched and at this point bo->ttm_resv also may been freed already.

 And I think it is not easy to put it out of two lock of bo->resv and 
bo->ttm_resv.

Thanks
Roger(Hongbo.He)
-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of 
Michel D?nzer
Sent: Wednesday, November 08, 2017 12:16 AM
To: Christian König 
Cc: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org
Subject: Re: [PATCH] drm/ttm: set bo->resv point to tbo->ttm_resv after 
individualize_resv

On 07/11/17 02:44 PM, Christian König wrote:
> Set bo->resv to ttm_resv during BO cleanup. This way freed BOs can be 
> better reaped during eviction.
> 
> Signed-off-by: Roger He 
> Signed-off-by: Christian König 

KASAN caught some badness while running piglit with this applied, see the 
attached dmesg excerpts.


At least some of this might be pre-existing bugs being exposed by this change. 
E.g. I've been chasing another use-after-free, with ttm_bo_delayed_delete 
trying to reserve a BO which has already been destroyed. Looks like maybe the 
ddestroy list handling isn't quite watertight yet.


-- 
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: [PATCH v5 06/12] drm/cma-helper: Turn to_drm_gem_cma_obj() into a macro

[Laurent Pinchart]

Hi Noralf,

Thank you for the patch.

On Tuesday, 7 November 2017 21:13:42 EET Noralf Trønnes wrote:
> This allows the argument to be a const.
> 
> The other option was to keep it an inline function and make the argument
> a const:
> 
> static inline struct drm_gem_cma_object *
> to_drm_gem_cma_obj(const struct drm_gem_object *gem_obj)
> {
>   return container_of(gem_obj, struct drm_gem_cma_object, base);
> }
> 
> This will happily return a non-const pointer to the drm_gem_cma_object
> based on a const pointer to the contained drm_gem_object, thus creating
> const-safety problems.
> 
> There was an attempt to fix the problem in the container_of() macro
> itself (see https://lkml.org/lkml/2017/5/19/381) but the patch seems to
> have fallen through the cracks. It would require turning this inline
> function into a macro.
> 
> By making this a macro now, we will benefit from a possible future
> enhancement of container_of(). We don't loose type checking by doing
> this, container_of() takes care of that.
> 
> Suggested-by: Laurent Pinchart 
> Signed-off-by: Noralf Trønnes 

Reviewed-by: Laurent Pinchart 

> ---
>  include/drm/drm_gem_cma_helper.h | 7 ++-
>  1 file changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/include/drm/drm_gem_cma_helper.h
> b/include/drm/drm_gem_cma_helper.h index 58a739bf15f1..7a3dcf0cf289 100644
> --- a/include/drm/drm_gem_cma_helper.h
> +++ b/include/drm/drm_gem_cma_helper.h
> @@ -20,11 +20,8 @@ struct drm_gem_cma_object {
>   void *vaddr;
>  };
> 
> -static inline struct drm_gem_cma_object *
> -to_drm_gem_cma_obj(struct drm_gem_object *gem_obj)
> -{
> - return container_of(gem_obj, struct drm_gem_cma_object, base);
> -}
> +#define to_drm_gem_cma_obj(gem_obj) \
> + container_of(gem_obj, struct drm_gem_cma_object, base)
> 
>  #ifndef CONFIG_MMU
>  #define DRM_GEM_CMA_UNMAPPED_AREA_FOPS \


-- 
Regards,

Laurent Pinchart

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

[PATCH v1 0/2] DRM driver for ILI9225 display panels

[David Lechner]

This is a new driver for ILI9225 based display panels.

There are a couple of things that stand out:

1.  Despite my best efforts, I could not find a name for this display[1], so I
have made up a generic name for it. If someone recognizes this and has a
name for it, please speak up. The best documentation I could find was
here[2].

2.  There is quite a bit of one-off code copied from mipi-dbi.c. Based on the
feedback from a previous patch series, I'm guessing that we don't want to
modify mipi-dbi.c to accommodate the ILI9225 controller because the ILI9225
controller does not use standard MIPI commands. ILI9225 has it's own
non-standard command set, but other than that, it pretty much matches the
generic mipi-dbi driver in all regards.

Code that could be easily shared:

a.  ili9225_buf_copy() is exactly the same as mipi_dbi_buf_copy()
- ili9225_buf_copy() is used in ili9225_fb_dirty()
- mipi_dbi_buf_copy() is static in mipi-dbi.c

b.  ili9225_spi_cmd_max_speed() is exactly the same as
mipi_dbi_spi_cmd_max_speed()
- ili9225_spi_cmd_max_speed() is used in ili9225_command() below, so
  would not need to be copied if mipi_dbi_typec3_command() could be
  shared
- mipi_dbi_spi_cmd_max_speed() is static in mipi-dbi.c

c.  ili9225_command() is nearly the same as mipi_dbi_typec3_command()
- a few unused lines were removed so I didn't have to copy even more
  code, but these would not be an issue if code was shared
- cmd == ILI9225_WRITE_DATA_TO_GRAM instead of
  cmd == MIPI_DCS_WRITE_MEMORY_START

d.  ili9225_spi_init() is nearly the same as mipi_dbi_spi_init()
- a few unused lines were removed so I didn't have to copy even more
  code, but these would not be an issue if code was shared
- mipi->command = ili9225_command instead of
  mipi->command = mipi_dbi_typec3_command
- this function would not need to be copied if mipi_dbi_typec3_command()
  was modified to work with the ILI9225 command set too

e.  ili9225_init() is nearly the same as mipi_dbi_init()
- only difference is ili9225_fb_funcs instead of mipi_dbi_fb_funcs

3.  I haven't tried it, but I believe that it is possible to implement
DRM_FORMAT_RGB888 directly instead of simulating DRM_FORMAT_XRGB.
I don't know if there would be any real benefit to doing this. I am not
familiar enough with userspace programs/libraries to know if this mode is
universally used. And, it will only physically be 18-bit color instead of
24-bit but will increase the amount of data transferred by 50% (3 bytes per
pixel instead of 2). Implementing this would have a side effect of making
the one-off shared code (described above) more than one-off though.

[1]: https://github.com/Nkawu/TFT_22_ILI9225
[2]: http://www.hotmcu.com/22-176x220-tft-lcd-with-spi-interface-p-316.html

David Lechner (2):
  dt-bindings: Add binding for Ilitek ILI9225 display panels
  drm/tinydrm: add driver for ILI9225 panels

 .../devicetree/bindings/display/ilitek,ili9225.txt |  25 +
 MAINTAINERS|   6 +
 drivers/gpu/drm/tinydrm/Kconfig|  10 +
 drivers/gpu/drm/tinydrm/Makefile   |   1 +
 drivers/gpu/drm/tinydrm/ili9225.c  | 547 +
 5 files changed, 589 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/ilitek,ili9225.txt
 create mode 100644 drivers/gpu/drm/tinydrm/ili9225.c

--
2.7.4

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

[PATCH v1 2/2] drm/tinydrm: add driver for ILI9225 panels

[David Lechner]

This adds a new driver for display panels based on the Ilitek ILI9225
controller.

This was developed for a no-name panel with a red PCB that is commonly
marketed for Arduino. See .

I really did try very hard to find a make and model for this panel, but
there doesn't seem to be one, so the best I can do is offer the picture
in the link above for identification.

Signed-off-by: David Lechner 
---
 MAINTAINERS   |   6 +
 drivers/gpu/drm/tinydrm/Kconfig   |  10 +
 drivers/gpu/drm/tinydrm/Makefile  |   1 +
 drivers/gpu/drm/tinydrm/ili9225.c | 547 ++
 4 files changed, 564 insertions(+)
 create mode 100644 drivers/gpu/drm/tinydrm/ili9225.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 0d77f22..72404f3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4372,6 +4372,12 @@ T:   git git://anongit.freedesktop.org/drm/drm-misc
 S: Maintained
 F: drivers/gpu/drm/tve200/
 
+DRM DRIVER FOR ILITEK ILI9225 PANELS
+M: David Lechner 
+S: Maintained
+F: drivers/gpu/drm/tinydrm/ili9225.c
+F: Documentation/devicetree/bindings/display/ili9225.txt
+
 DRM DRIVER FOR INTEL I810 VIDEO CARDS
 S: Orphan / Obsolete
 F: drivers/gpu/drm/i810/
diff --git a/drivers/gpu/drm/tinydrm/Kconfig b/drivers/gpu/drm/tinydrm/Kconfig
index 2e790e7..90c5bd5 100644
--- a/drivers/gpu/drm/tinydrm/Kconfig
+++ b/drivers/gpu/drm/tinydrm/Kconfig
@@ -12,6 +12,16 @@ menuconfig DRM_TINYDRM
 config TINYDRM_MIPI_DBI
tristate
 
+config TINYDRM_ILI9225
+   tristate "DRM support for ILI9225 display panels"
+   depends on DRM_TINYDRM && SPI
+   select TINYDRM_MIPI_DBI
+   help
+ DRM driver for the following Ilitek ILI9225 panels:
+ * No-name 2.2" color screen module
+
+ If M is selected the module will be called ili9225.
+
 config TINYDRM_MI0283QT
tristate "DRM support for MI0283QT"
depends on DRM_TINYDRM && SPI
diff --git a/drivers/gpu/drm/tinydrm/Makefile b/drivers/gpu/drm/tinydrm/Makefile
index 0c184bd..8aeee53 100644
--- a/drivers/gpu/drm/tinydrm/Makefile
+++ b/drivers/gpu/drm/tinydrm/Makefile
@@ -4,6 +4,7 @@ obj-$(CONFIG_DRM_TINYDRM)   += core/
 obj-$(CONFIG_TINYDRM_MIPI_DBI) += mipi-dbi.o
 
 # Displays
+obj-$(CONFIG_TINYDRM_ILI9225)  += ili9225.o
 obj-$(CONFIG_TINYDRM_MI0283QT) += mi0283qt.o
 obj-$(CONFIG_TINYDRM_REPAPER)  += repaper.o
 obj-$(CONFIG_TINYDRM_ST7586)   += st7586.o
diff --git a/drivers/gpu/drm/tinydrm/ili9225.c 
b/drivers/gpu/drm/tinydrm/ili9225.c
new file mode 100644
index 000..07e1b8b
--- /dev/null
+++ b/drivers/gpu/drm/tinydrm/ili9225.c
@@ -0,0 +1,547 @@
+/*
+ * DRM driver for Ilitek ILI9225 panels
+ *
+ * Copyright 2017 David Lechner 
+ *
+ * Lots of code copied from mipi-dbi.c
+ * Copyright 2016 Noralf Trønnes
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#define ILI9225_DRIVER_READ_CODE   0x00
+#define ILI9225_DRIVER_OUTPUT_CONTROL  0x01
+#define ILI9225_LCD_AC_DRIVING_CONTROL 0x02
+#define ILI9225_ENTRY_MODE 0x03
+#define ILI9225_DISPLAY_CONTROL_1  0x07
+#define ILI9225_BLANK_PERIOD_CONTROL_1 0x08
+#define ILI9225_FRAME_CYCLE_CONTROL0x0b
+#define ILI9225_INTERFACE_CONTROL  0x0c
+#define ILI9225_OSCILLATION_CONTROL0x0f
+#define ILI9225_POWER_CONTROL_10x10
+#define ILI9225_POWER_CONTROL_20x11
+#define ILI9225_POWER_CONTROL_30x12
+#define ILI9225_POWER_CONTROL_40x13
+#define ILI9225_POWER_CONTROL_50x14
+#define ILI9225_VCI_RECYCLING  0x15
+#define ILI9225_RAM_ADDRESS_SET_1  0x20
+#define ILI9225_RAM_ADDRESS_SET_2  0x21
+#define ILI9225_WRITE_DATA_TO_GRAM 0x22
+#define ILI9225_SOFTWARE_RESET 0x28
+#define ILI9225_GATE_SCAN_CONTROL  0x30
+#define ILI9225_VERTICAL_SCROLL_1  0x31
+#define ILI9225_VERTICAL_SCROLL_2  0x32
+#define ILI9225_VERTICAL_SCROLL_3  0x33
+#define ILI9225_PARTIAL_DRIVING_POS_1  0x34
+#define ILI9225_PARTIAL_DRIVING_POS_2  0x35
+#define ILI9225_HORIZ_WINDOW_ADDR_10x36
+#define ILI9225_HORIZ_WINDOW_ADDR_20x37
+#define ILI9225_VERT_WINDOW_ADDR_1 0x38
+#define ILI9225_VERT_WINDOW_ADDR_2 0x39
+#define ILI9225_GAMMA_CONTROL_10x50
+#define ILI9225_GAMMA_CONTROL_20x51
+#define ILI9225_GAMMA_CONTROL_30x52
+#define ILI9225_GAMMA_CONTROL_40x53
+#define ILI9225_GAMMA_CONTROL_50x54
+#define ILI9225_GAMMA_CONTROL_60x55
+#define 

[PATCH v1 1/2] dt-bindings: Add binding for Ilitek ILI9225 display panels

[David Lechner]

This adds a new binding for display panels that use an Ilitek ILI9225
controller.

The "generic,2.2in-176x220-ili9225-tft" device listed has no identification
markings whatsoever and an hour of googling turned up nothing, hence the use
of "generic".

An example of this nameless device can be found at:
https://github.com/Nkawu/TFT_22_ILI9225

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

diff --git a/Documentation/devicetree/bindings/display/ilitek,ili9225.txt 
b/Documentation/devicetree/bindings/display/ilitek,ili9225.txt
new file mode 100644
index 000..5839f56
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/ilitek,ili9225.txt
@@ -0,0 +1,25 @@
+Ilitek ILI9225 display panels
+
+This binding is for display panels using an Ilitek ILI9225 controller in SPI
+mode.
+
+Required properties:
+- compatible:  "generic,2.2in-176x220-ili9225-tft"
+- rs-gpios:Register select signal
+- reset-gpios: Reset pin
+
+The node for this driver must be a child node of a SPI controller, hence
+all mandatory properties described in ../spi/spi-bus.txt must be specified.
+
+Optional properties:
+- rotation:panel rotation in degrees counter clockwise (0,90,180,270)
+
+Example:
+   display@0{
+   compatible = "generic,2.2in-176x220-ili9225-tft";
+   reg = <0>;
+   spi-max-frequency = <1200>;
+   rs-gpios = < 9 GPIO_ACTIVE_HIGH>;
+   reset-gpios = < 8 GPIO_ACTIVE_HIGH>;
+   rotation = <270>;
+   };
-- 
2.7.4

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

[PATCH v2] drm/dp: Add DP DSC DPCD receiver capability size define and missing SHIFT

[Manasi Navare]

This patch defines the DP DSC receiver capability size that gives
total number of DP DSC DPCD registers.
This also adds a missing SHIFT define missed in the
commit id (ab6a46ea6842ce "Add DPCD definitions for DP 1.4 DSC feature")

v2:
* Missed th SHIFT define that I mentioned in the message

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

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 9049ef1..036d0ec 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -223,6 +223,7 @@
 #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_MAX_BITS_PER_PIXEL_HI_SHIFT 8
 
 #define DP_DSC_DEC_COLOR_FORMAT_CAP 0x069
 # define DP_DSC_RGB (1 << 0)
@@ -874,6 +875,7 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const u8 
link_status[DP_LINK_STATUS_SI
 
 #define DP_BRANCH_OUI_HEADER_SIZE  0xc
 #define DP_RECEIVER_CAP_SIZE   0xf
+#define DP_DSC_RECEIVER_CAP_SIZE0xf
 #define EDP_PSR_RECEIVER_CAP_SIZE  2
 #define EDP_DISPLAY_CTL_CAP_SIZE   3
 
-- 
2.1.4

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

[PATCH] drm/dp: Add DP DSC DPCD receiver capability size define and missing SHIFT

[Manasi Navare]

This patch defines the DP DSC receiver capability size that gives
total number of DP DSC DPCD registers.
This also adds a missing SHIFT define missed in the
commit id (ab6a46ea6842ce "Add DPCD definitions for DP 1.4 DSC feature")

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

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 9049ef1..ff02c23 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -874,6 +874,7 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const u8 
link_status[DP_LINK_STATUS_SI
 
 #define DP_BRANCH_OUI_HEADER_SIZE  0xc
 #define DP_RECEIVER_CAP_SIZE   0xf
+#define DP_DSC_RECEIVER_CAP_SIZE0xf
 #define EDP_PSR_RECEIVER_CAP_SIZE  2
 #define EDP_DISPLAY_CTL_CAP_SIZE   3
 
-- 
2.1.4

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

[Bug 103544] Graphical glitches r600 in game this war of mine linux native

[bugzilla-daemon]

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

--- Comment #15 from Roland Scheidegger  ---
(In reply to Roland Scheidegger from comment #14)
> - the driver doesn't use the ieee variants consistently (e.g. muls from
> lerps).
> There's also some inconsistencies - for r600, the comments say for non-gl
> usage the ieee variant should be used for rcp, however eg/cayman will use
> that anyway, and I don't think handling it differently between these drivers
> is done on purpose.

Actually that seems to be the problem - on r600, rcp/rsq_clamped are used (btw
does someone know why rsq has its own code expansion on r600, but not
eg/cayman)?
But eg/cayman use rcp/rsq_ieee. It looks like if I use rcp_clamped instead that
is enough to fix everything (regardless what rsq/min/max are using).

-- 
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 66963] Rv6xx dpm problems

[bugzilla-daemon]

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

--- Comment #296 from Mihai Coman  ---
Hello,

On a whim I've decided to try radeon.dpm=1 again. I've been running it for the
past couple of days and I haven't had gotten any lockups, and I used to get
them in the first 30 min. The temp. decrease is considerable, from 10 to 20
degrees C.

Can anyone else still running this old hardware try it again, to confirm?

I'm running;
Linux icxbox 4.13.11-1-ARCH
Mobility Radeon HD 3650 on HP EliteBook 8530w.

-- 
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 103544] Graphical glitches r600 in game this war of mine linux native

[bugzilla-daemon]

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

--- Comment #14 from Roland Scheidegger  ---
(In reply to Ilia Mirkin from comment #13)
> (In reply to Roland Scheidegger from comment #12)
> > Here's a apitrace for this (1GB, of course the corruption is only seen
> > towards the end...), should be available a week (?):
> > https://we.tl/EanuxRG7Yf
> 
> Well, this all replays fine with nouveau, even if I remove the blending
> config which makes 0*nan=0. At least I couldn't see any artifacts.
> 
> So this all points to ... sadness. Can you check if you still see artifacts
> with nosb?

Tried that, doesn't help.

I noticed some things looking questionable in the driver:
- the driver doesn't use the ieee variants consistently (e.g. muls from lerps).
There's also some inconsistencies - for r600, the comments say for non-gl usage
the ieee variant should be used for rcp, however eg/cayman will use that
anyway, and I don't think handling it differently between these drivers is done
on purpose.
- the driver uses min/max instead of min_dx10/max_dx10 (though at least the EG
ISA docs are wrong/inaccurate what they exactly do). These would kill off NaNs
(albeit I am not entirely sure if the non-dx10 version doesn't kill off NaNs
neither, given the docs aren't accurate in the first place...). I think this
probably should be changed (as far as I can tell, radeonsi also uses
effectively the dx10 versions, since llvm.min/maxnum is specified as selecting
non-nan operands, though I don't know if the backend honors it really). This
actually does help things, it removes the black holes in the fires, and the
"vertical blue stripes" (albeit the latter wasn't really in that trace). But
otherwise there's still lots of black boxes around.

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

[radeon-alex:amd-staging-drm-next 2135/2152] sound/soc/amd/acp-pcm-dma.c:857: undefined reference to `__umoddi3'

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head:   9ef4af0611bafed9fd40c4af92c1daeefba45e95
commit: fb837978e0395a5f936e56bb3ed4c824d50da8e8 [2135/2152] ASoC: amd: Report 
accurate hw_ptr during dma
config: i386-randconfig-x0-11080703 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout fb837978e0395a5f936e56bb3ed4c824d50da8e8
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   sound/soc/amd/acp-pcm-dma.o: In function `acp_dma_pointer':
>> sound/soc/amd/acp-pcm-dma.c:857: undefined reference to `__umoddi3'
   sound/soc/amd/acp-pcm-dma.c:861: undefined reference to `__umoddi3'

vim +857 sound/soc/amd/acp-pcm-dma.c

   841  
   842  static snd_pcm_uframes_t acp_dma_pointer(struct snd_pcm_substream 
*substream)
   843  {
   844  u32 buffersize;
   845  u32 pos = 0;
   846  u64 bytescount = 0;
   847  
   848  struct snd_pcm_runtime *runtime = substream->runtime;
   849  struct audio_substream_data *rtd = runtime->private_data;
   850  
   851  buffersize = frames_to_bytes(runtime, runtime->buffer_size);
   852  bytescount = acp_get_byte_count(rtd->acp_mmio, 
substream->stream);
   853  
   854  if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
   855  if (bytescount > rtd->renderbytescount)
   856  bytescount = bytescount - rtd->renderbytescount;
 > 857  pos =  bytescount % buffersize;
   858  } else {
   859  if (bytescount > rtd->capturebytescount)
   860  bytescount = bytescount - 
rtd->capturebytescount;
   861  pos = bytescount % buffersize;
   862  }
   863  return bytes_to_frames(runtime, pos);
   864  }
   865  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 103613] Reverse Prime with intel/amdgpu causes segfault in glamor_block_handler when enabling monitor

[bugzilla-daemon]

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

--- Comment #3 from EoD  ---
Created attachment 135291
  --> https://bugs.freedesktop.org/attachment.cgi?id=135291=edit
GDBs Backtrace with -O0

-- 
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 99923] HITMAN (2016) having lighting and artefacting, and overly light room.

[bugzilla-daemon]

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

--- Comment #18 from Christoph Schwerdtfeger  ---
Unfortunately still the same...

# glxinfo | grep Mesa
client glx vendor string: Mesa Project and SGI
OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.2.4
OpenGL version string: 3.0 Mesa 17.2.4
OpenGL ES profile version string: OpenGL ES 3.1 Mesa 17.2.4

# glxinfo | grep -i llvm
Device: AMD TAHITI (DRM 2.50.0 / 4.13.0-1-amd64, LLVM 5.0.0) (0x679a)
OpenGL renderer string: AMD TAHITI (DRM 2.50.0 / 4.13.0-1-amd64, LLVM 5.0.0)

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

Re: AMD, please run Smatch on your driver

[Harry Wentland]

Thanks, Dan, for bringing this to our attention. We (the display guys here) 
weren't aware of smatch and will give it a spin and try to address some of the 
remaining items (after your, Dave's, and Ernst's patches).

Harry

On 2017-11-06 06:34 AM, Dan Carpenter wrote:
> Linux-next was offline for the last month and the AMD drm driver went
> through major changes.  Anyway, I'm a bit overwhelmed by the number of
> warnings and I'm not going to be able to go through them all so I'm just
> sending them to you unfiltered.
> 
> Part of the problem is that I'm not running the released version of
> Smatch myself.  That has two effects.  1) The released version is
> crappier than I had imagined.  2) I get *way* more warnings than you see
> which is overwhelming...  So this is mostly my fault and I will try to
> do better.
> 
> Here are the current warnings from Friday's linux-next, lightly edited.
> I know that everyone hates a big dump of static checker warnings...
> Speaking of being ignored, I sent a fix for this one back in August but
> never heard back:
> 
>   drivers/gpu/drm/amd/amdgpu/ci_dpm.c:4553 ci_set_mc_special_registers()
>   error: buffer overflow 'table->mc_reg_address' 16 <= 16
> 
> https://lists.freedesktop.org/archives/amd-gfx/2017-August/012333.html
> 
> So this is partly your fault as well because if you cleaned up static
> checker warnings little by little, then they wouldn't pile up like this.
> Eventually, everyone is going to have to start running Smatch for
> themselves because it scales better than relying on me to do it.
> 
> regards,
> dan carpenter
> 
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:2224 amdgpu_device_init() warn: 
> 'adev->rio_mem' was not released on error
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:2395 amdgpu_device_init() warn: 
> 'adev->rio_mem' was not released on error
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:3373 amdgpu_debugfs_regs_write() 
> warn: 'mutex:>pm.mutex' is sometimes locked here and sometimes unlocked.
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:3377 amdgpu_debugfs_regs_write() 
> warn: 'mutex:>pm.mutex' is sometimes locked here and sometimes unlocked.
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:3771 amdgpu_debugfs_gpr_read() 
> error: buffer overflow 'data' 1024 <= 4095
> drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c:155 amdgpu_driver_load_kms() warn: we 
> tested 'r' before and it was 'false'
> drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c:689 amdgpu_gem_op_ioctl() warn: 
> should 'robj->tbo.mem.page_alignment << 12' be a 64 bit type?
> drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:196 amdgpu_cs_parser_init() warn: 
> 'mutex:>ctx->lock' is sometimes locked here and sometimes unlocked.
> drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:674 amdgpu_cs_parser_bos() warn: we 
> tested 'r' before and it was 'false'
> drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:755 amdgpu_cs_parser_fini() warn: 
> 'mutex:>ctx->lock' is sometimes locked here and sometimes unlocked.
> drivers/gpu/drm/amd/amdgpu/atombios_i2c.c:72 
> amdgpu_atombios_i2c_process_i2c_ch() warn: impossible condition '(num > 255) 
> => (0-255 > 255)'
> drivers/gpu/drm/amd/amdgpu/amdgpu_queue_mgr.c:217 amdgpu_queue_mgr_map() 
> warn: variable dereferenced before check 'mgr' (see line 215)
> drivers/gpu/drm/amd/amdgpu/kv_dpm.c:1618 kv_get_acp_boot_level() warn: always 
> true condition '(table->entries[i]->clk >= 0) => (0-u32max >= 0)'
> drivers/gpu/drm/amd/amdgpu/ci_dpm.c:4560 ci_set_mc_special_registers() error: 
> buffer overflow 'table->mc_reg_address' 16 <= 16
> drivers/gpu/drm/amd/amdgpu/ci_dpm.c:5065 
> ci_request_link_speed_change_before_state_change() warn: missing break? 
> reassigning 'pi->force_pcie_gen'
> drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c:5256 gfx_v7_0_get_cu_info() error: 
> buffer overflow 'cu_info->bitmap' 4 <= 4
> drivers/gpu/drm/amd/amdgpu/si.c:1288 si_common_early_init() warn: 
> inconsistent indenting
> drivers/gpu/drm/amd/amdgpu/dce_v6_0.c:3026 dce_v6_0_pageflip_irq() warn: 
> inconsistent indenting
> drivers/gpu/drm/amd/amdgpu/si_dpm.c:6242 
> si_request_link_speed_change_before_state_change() warn: missing break? 
> reassigning 'si_pi->force_pcie_gen'
> drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c:5222 gfx_v8_0_pre_soft_reset() warn: 
> inconsistent indenting
> drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c:7105 gfx_v8_0_get_cu_info() error: 
> buffer overflow 'cu_info->bitmap' 4 <= 4
> drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c:3077 gfx_v9_0_soft_reset() warn: we 
> tested 'grbm_soft_reset' before and it was 'true'
> drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c:3644 gfx_v9_0_ring_emit_ib_gfx() warn: 
> inconsistent indenting
> drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c:4457 gfx_v9_0_get_cu_info() error: 
> buffer overflow 'cu_info->bitmap' 4 <= 4
> drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c:605 amdgpu_cgs_lock_grbm_idx() warn: 
> 'mutex:>grbm_idx_mutex' is sometimes locked here and sometimes unlocked.
> drivers/gpu/drm/amd/amdgpu/../scheduler/gpu_scheduler.c:696 amd_sched_init() 
> warn: call of 'kthread_create_on_node' with 

[Bug 103613] Reverse Prime with intel/amdgpu causes segfault in glamor_block_handler when enabling monitor

[bugzilla-daemon]

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

--- Comment #2 from EoD  ---
On request from IRC, I also tried using UXA instead of SNA with the intel
driver.

It does not crash anymore, but when I try to enable the 2nd monitor, I get a
"xrandr: Configure crtc 6 failed" and the following output in the Xorg.log:

[  1537.831] randr: falling back to unsynchronized pixmap sharing
[  1537.831] randr: failed to set shadow slave pixmap
[  1537.831] (EE) intel(G0): failed to set mode: No space left on device

-- 
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 103613] Reverse Prime with intel/amdgpu causes segfault in glamor_block_handler when enabling monitor

[bugzilla-daemon]

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

--- Comment #1 from EoD  ---
I also tried using modesetting instead of the other drivers and

Enabling the monitor...

- works, when I set driver=modesetting on the both cards via an xorg.conf
- works, when I set driver=modesetting on the intel card only.
- works, when I set driver=modesetting on the amd card only, but according to
listproviders, both cards use modesetting.

-- 
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 103544] Graphical glitches r600 in game this war of mine linux native

[bugzilla-daemon]

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

--- Comment #13 from Ilia Mirkin  ---
(In reply to Roland Scheidegger from comment #12)
> Here's a apitrace for this (1GB, of course the corruption is only seen
> towards the end...), should be available a week (?):
> https://we.tl/EanuxRG7Yf

Well, this all replays fine with nouveau, even if I remove the blending config
which makes 0*nan=0. At least I couldn't see any artifacts.

So this all points to ... sadness. Can you check if you still see artifacts
with nosb?

-- 
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 v5 11/12] drm/tinydrm: Use drm_gem_cma_print_info()

[Noralf Trønnes]

There is a new core debugfs file that prints fb/gem info:
/dri//framebuffer

Use drm_gem_cma_print_info() to provide info to that output instead
of using drm_fb_cma_debugfs_show().

Reviewed-by: Daniel Vetter 
Signed-off-by: Noralf Trønnes 
Reviewed-by: Laurent Pinchart 
---
 drivers/gpu/drm/tinydrm/mipi-dbi.c | 8 +---
 include/drm/tinydrm/tinydrm.h  | 1 +
 2 files changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/tinydrm/mipi-dbi.c 
b/drivers/gpu/drm/tinydrm/mipi-dbi.c
index d43e992ab432..347f9b226f26 100644
--- a/drivers/gpu/drm/tinydrm/mipi-dbi.c
+++ b/drivers/gpu/drm/tinydrm/mipi-dbi.c
@@ -961,10 +961,6 @@ static const struct file_operations 
mipi_dbi_debugfs_command_fops = {
.write = mipi_dbi_debugfs_command_write,
 };
 
-static const struct drm_info_list mipi_dbi_debugfs_list[] = {
-   { "fb",   drm_fb_cma_debugfs_show, 0 },
-};
-
 /**
  * mipi_dbi_debugfs_init - Create debugfs entries
  * @minor: DRM minor
@@ -987,9 +983,7 @@ int mipi_dbi_debugfs_init(struct drm_minor *minor)
debugfs_create_file("command", mode, minor->debugfs_root, mipi,
_dbi_debugfs_command_fops);
 
-   return drm_debugfs_create_files(mipi_dbi_debugfs_list,
-   ARRAY_SIZE(mipi_dbi_debugfs_list),
-   minor->debugfs_root, minor);
+   return 0;
 }
 EXPORT_SYMBOL(mipi_dbi_debugfs_init);
 
diff --git a/include/drm/tinydrm/tinydrm.h b/include/drm/tinydrm/tinydrm.h
index 4774fe3d4273..423828922e5a 100644
--- a/include/drm/tinydrm/tinydrm.h
+++ b/include/drm/tinydrm/tinydrm.h
@@ -46,6 +46,7 @@ pipe_to_tinydrm(struct drm_simple_display_pipe *pipe)
  */
 #define TINYDRM_GEM_DRIVER_OPS \
.gem_free_object= tinydrm_gem_cma_free_object, \
+   .gem_print_info = drm_gem_cma_print_info, \
.gem_vm_ops = _gem_cma_vm_ops, \
.prime_handle_to_fd = drm_gem_prime_handle_to_fd, \
.prime_fd_to_handle = drm_gem_prime_fd_to_handle, \
-- 
2.14.2

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

[PATCH v5 10/12] drm/tilcdc: Use drm_gem_cma_print_info()

[Noralf Trønnes]

There is a new core debugfs file that prints fb/gem info:
/dri//framebuffer

Use drm_gem_cma_print_info() to provide info to that output instead
of using drm_fb_cma_debugfs_show().

Cc: Jyri Sarha 
Cc: Tomi Valkeinen 
Signed-off-by: Noralf Trønnes 
Acked-by: Jyri Sarha 
Reviewed-by: Laurent Pinchart 
---
 drivers/gpu/drm/tilcdc/tilcdc_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 72ce063aa0d8..bc4feb3a84b9 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -507,7 +507,6 @@ static int tilcdc_mm_show(struct seq_file *m, void *arg)
 static struct drm_info_list tilcdc_debugfs_list[] = {
{ "regs", tilcdc_regs_show, 0 },
{ "mm",   tilcdc_mm_show,   0 },
-   { "fb",   drm_fb_cma_debugfs_show, 0 },
 };
 
 static int tilcdc_debugfs_init(struct drm_minor *minor)
@@ -541,6 +540,7 @@ static struct drm_driver tilcdc_driver = {
.lastclose  = tilcdc_lastclose,
.irq_handler= tilcdc_irq,
.gem_free_object_unlocked = drm_gem_cma_free_object,
+   .gem_print_info = drm_gem_cma_print_info,
.gem_vm_ops = _gem_cma_vm_ops,
.dumb_create= drm_gem_cma_dumb_create,
 
-- 
2.14.2

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

[PATCH v5 12/12] drm/cma-helper: Remove drm_fb_cma_debugfs_show()

[Noralf Trønnes]

drm_fb_cma_debugfs_show() and drm_gem_cma_describe() are superseded
by drm_framebuffer_debugfs_init() and drm_gem_cma_print_info().

Cc: Laurent Pinchart 
Signed-off-by: Noralf Trønnes 
Reviewed-by: Daniel Vetter 
Reviewed-by: Laurent Pinchart 
---
 drivers/gpu/drm/drm_fb_cma_helper.c  | 37 
 drivers/gpu/drm/drm_gem_cma_helper.c | 26 -
 include/drm/drm_fb_cma_helper.h  |  6 --
 include/drm/drm_gem_cma_helper.h |  4 
 4 files changed, 73 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
b/drivers/gpu/drm/drm_fb_cma_helper.c
index 0e3c14174d08..35b56dfba929 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -130,43 +130,6 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct drm_framebuffer 
*fb,
 }
 EXPORT_SYMBOL_GPL(drm_fb_cma_get_gem_addr);
 
-#ifdef CONFIG_DEBUG_FS
-static void drm_fb_cma_describe(struct drm_framebuffer *fb, struct seq_file *m)
-{
-   int i;
-
-   seq_printf(m, "fb: %dx%d@%4.4s\n", fb->width, fb->height,
-   (char *)>format->format);
-
-   for (i = 0; i < fb->format->num_planes; i++) {
-   seq_printf(m, "   %d: offset=%d pitch=%d, obj: ",
-   i, fb->offsets[i], fb->pitches[i]);
-   drm_gem_cma_describe(drm_fb_cma_get_gem_obj(fb, i), m);
-   }
-}
-
-/**
- * drm_fb_cma_debugfs_show() - Helper to list CMA framebuffer objects
- *in debugfs.
- * @m: output file
- * @arg: private data for the callback
- */
-int drm_fb_cma_debugfs_show(struct seq_file *m, void *arg)
-{
-   struct drm_info_node *node = (struct drm_info_node *) m->private;
-   struct drm_device *dev = node->minor->dev;
-   struct drm_framebuffer *fb;
-
-   mutex_lock(>mode_config.fb_lock);
-   drm_for_each_fb(fb, dev)
-   drm_fb_cma_describe(fb, m);
-   mutex_unlock(>mode_config.fb_lock);
-
-   return 0;
-}
-EXPORT_SYMBOL_GPL(drm_fb_cma_debugfs_show);
-#endif
-
 static int drm_fb_cma_mmap(struct fb_info *info, struct vm_area_struct *vma)
 {
return dma_mmap_writecombine(info->device, vma, info->screen_base,
diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c 
b/drivers/gpu/drm/drm_gem_cma_helper.c
index 29f7b0fd3ad4..88ad88719605 100644
--- a/drivers/gpu/drm/drm_gem_cma_helper.c
+++ b/drivers/gpu/drm/drm_gem_cma_helper.c
@@ -397,32 +397,6 @@ unsigned long drm_gem_cma_get_unmapped_area(struct file 
*filp,
 EXPORT_SYMBOL_GPL(drm_gem_cma_get_unmapped_area);
 #endif
 
-#ifdef CONFIG_DEBUG_FS
-/**
- * drm_gem_cma_describe - describe a CMA GEM object for debugfs
- * @cma_obj: CMA GEM object
- * @m: debugfs file handle
- *
- * This function can be used to dump a human-readable representation of the
- * CMA GEM object into a synthetic file.
- */
-void drm_gem_cma_describe(struct drm_gem_cma_object *cma_obj,
- struct seq_file *m)
-{
-   struct drm_gem_object *obj = _obj->base;
-   uint64_t off;
-
-   off = drm_vma_node_start(>vma_node);
-
-   seq_printf(m, "%2d (%2d) %08llx %pad %p %zu",
-   obj->name, kref_read(>refcount),
-   off, _obj->paddr, cma_obj->vaddr, obj->size);
-
-   seq_printf(m, "\n");
-}
-EXPORT_SYMBOL_GPL(drm_gem_cma_describe);
-#endif
-
 /**
  * drm_gem_cma_print_info() - Print _gem_cma_object info for debugfs
  * @p: DRM printer
diff --git a/include/drm/drm_fb_cma_helper.h b/include/drm/drm_fb_cma_helper.h
index 023f052a5873..a613ff022e6c 100644
--- a/include/drm/drm_fb_cma_helper.h
+++ b/include/drm/drm_fb_cma_helper.h
@@ -35,11 +35,5 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct drm_framebuffer 
*fb,
   struct drm_plane_state *state,
   unsigned int plane);
 
-#ifdef CONFIG_DEBUG_FS
-struct seq_file;
-
-int drm_fb_cma_debugfs_show(struct seq_file *m, void *arg);
-#endif
-
 #endif
 
diff --git a/include/drm/drm_gem_cma_helper.h b/include/drm/drm_gem_cma_helper.h
index 40435f3480e5..76ded75f02cc 100644
--- a/include/drm/drm_gem_cma_helper.h
+++ b/include/drm/drm_gem_cma_helper.h
@@ -87,10 +87,6 @@ unsigned long drm_gem_cma_get_unmapped_area(struct file 
*filp,
unsigned long flags);
 #endif
 
-#ifdef CONFIG_DEBUG_FS
-void drm_gem_cma_describe(struct drm_gem_cma_object *obj, struct seq_file *m);
-#endif
-
 void drm_gem_cma_print_info(struct drm_printer *p, unsigned int indent,
const struct drm_gem_object *obj);
 
-- 
2.14.2

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

[PATCH v5 09/12] drm/arm/hdlcd: Use drm_gem_cma_print_info()

[Noralf Trønnes]

There is a new core debugfs file that prints fb/gem info:
/dri//framebuffer

Use drm_gem_cma_print_info() to provide info to that output instead
of using drm_fb_cma_debugfs_show().

Cc: Liviu Dudau 
Cc: Brian Starkey 
Signed-off-by: Noralf Trønnes 
Acked-by: Liviu Dudau 
Reviewed-by: Laurent Pinchart 
---
 drivers/gpu/drm/arm/hdlcd_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
index 764d0c83710c..59b21bdc0c30 100644
--- a/drivers/gpu/drm/arm/hdlcd_drv.c
+++ b/drivers/gpu/drm/arm/hdlcd_drv.c
@@ -230,7 +230,6 @@ static int hdlcd_show_pxlclock(struct seq_file *m, void 
*arg)
 static struct drm_info_list hdlcd_debugfs_list[] = {
{ "interrupt_count", hdlcd_show_underrun_count, 0 },
{ "clocks", hdlcd_show_pxlclock, 0 },
-   { "fb", drm_fb_cma_debugfs_show, 0 },
 };
 
 static int hdlcd_debugfs_init(struct drm_minor *minor)
@@ -252,6 +251,7 @@ static struct drm_driver hdlcd_driver = {
.irq_postinstall = hdlcd_irq_postinstall,
.irq_uninstall = hdlcd_irq_uninstall,
.gem_free_object_unlocked = drm_gem_cma_free_object,
+   .gem_print_info = drm_gem_cma_print_info,
.gem_vm_ops = _gem_cma_vm_ops,
.dumb_create = drm_gem_cma_dumb_create,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
-- 
2.14.2

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

[PATCH v5 05/12] drm/atomic: Use drm_framebuffer_print_info()

[Noralf Trønnes]

Use drm_framebuffer_print_info() to print framebuffer info in
drm_atomic_plane_print_state(). This will give optional GEM info as well.

Reviewed-by: Daniel Vetter 
Signed-off-by: Noralf Trønnes 
Reviewed-by: Laurent Pinchart 
---
 drivers/gpu/drm/drm_atomic.c | 18 +++---
 1 file changed, 3 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index fd96c3dad2fb..bf8ca515c958 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -33,6 +33,7 @@
 #include 
 
 #include "drm_crtc_internal.h"
+#include "drm_internal.h"
 
 void __drm_crtc_commit_free(struct kref *kref)
 {
@@ -935,21 +936,8 @@ static void drm_atomic_plane_print_state(struct 
drm_printer *p,
drm_printf(p, "plane[%u]: %s\n", plane->base.id, plane->name);
drm_printf(p, "\tcrtc=%s\n", state->crtc ? state->crtc->name : 
"(null)");
drm_printf(p, "\tfb=%u\n", state->fb ? state->fb->base.id : 0);
-   if (state->fb) {
-   struct drm_framebuffer *fb = state->fb;
-   int i, n = fb->format->num_planes;
-   struct drm_format_name_buf format_name;
-
-   drm_printf(p, "\t\tformat=%s\n",
- drm_get_format_name(fb->format->format, 
_name));
-   drm_printf(p, "\t\t\tmodifier=0x%llx\n", fb->modifier);
-   drm_printf(p, "\t\tsize=%dx%d\n", fb->width, fb->height);
-   drm_printf(p, "\t\tlayers:\n");
-   for (i = 0; i < n; i++) {
-   drm_printf(p, "\t\t\tpitch[%d]=%u\n", i, 
fb->pitches[i]);
-   drm_printf(p, "\t\t\toffset[%d]=%u\n", i, 
fb->offsets[i]);
-   }
-   }
+   if (state->fb)
+   drm_framebuffer_print_info(p, 2, state->fb);
drm_printf(p, "\tcrtc-pos=" DRM_RECT_FMT "\n", DRM_RECT_ARG());
drm_printf(p, "\tsrc-pos=" DRM_RECT_FP_FMT "\n", DRM_RECT_FP_ARG());
drm_printf(p, "\trotation=%x\n", state->rotation);
-- 
2.14.2

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

Re: [Intel-gfx] [RFC PATCH] drm/vblanks: Deal with HW vblank counter resets.

[Pandiyan, Dhinakaran]

On Tue, 2017-11-07 at 13:39 +0100, Daniel Vetter wrote:
> On Tue, Nov 07, 2017 at 10:47:00AM +0100, Michel Dänzer wrote:
> > On 07/11/17 07:26 AM, Dhinakaran Pandiyan wrote:
> > > Some HW vblank counters reset due to power management events, which messes
> > > up the vblank counting logic. This leads to screen freezes with user space
> > > waiting on vblank events that may not occur if the counter keeps 
> > > resetting.
> > > 
> > > For e.g., After the HW vblank counter resets
> > > [9.007359] [drm:drm_update_vblank_count [drm]] updating vblank count
> > > on crtc 0: current=297, diff=4294965389, hw=5 hw_last=1912
> > > 
> > > So, fall back to the SW counter, computed using  vblank timestamps
> > > and frame duration, when the HW counter value deviates by 50% of the SW
> > > computed value.
> > > 
> > > I have tested this patch on my SKL laptop with i915.enable_psr=1 and it
> > > *seems* to solve the screen freeze issue seen with PSR when DMC is loaded.
> > > 
> > > Known issues:
> > > 1) The 50% deviation margin is arbitrary.
> > > 2) "Redundant vblirq ignored" messages are more frequent.
> > > 
> > > I am sending this as an RFC to get feedback on whether the fall back
> > > approach is sane and if it should be implemented in the core.
> > 
> > Is there no way for the driver to know under which circumstances the
> > reset to 0 might happen? 

Not precisely, but the driver does need to allow the firmware to go into
lower power states.

> If there is, maybe it could be solved by
> > calling drm_crtc_vblank_off() before it might happen and
> > drm_crtc_vblank_on() after it might have happened.
> > 
> > Otherwise, might it be better not to use the HW counter at all when it's
> > known not to be reliable?
> 
> We know when it happens, so agreed this isn't a good/workable solution
> really. I thought the plan to fix that was to fix up our runtime pm to
> make sure the vblank counter doesn't get reset while we need it (pending
> flip or vblank). And in-between (when the vblank counter is totally off)
> we'd fix any mismatch by adjusting the sw vblank counter with an explicit
> call (where we can use the elapsed time to estimate the elapsed vblank
> counts well enough). Adding a magic hack like this doesn't sound like a
> good plan to me indeed.
> -Daniel

Thanks for the feedback, I wasn't aware of an agreed plan. I just went
through patchwork history now and realized that the full-time SW counter
approach was tried earlier, but not much information on why it was
abandoned.

Allowing runtime PM (PSR + DMC) to do it's job while letting the SW
estimate vblanks if the hardware counter is unreliable didn't seem like
a terrible plan. It could save more power fwiw. But, I understand your
concerns, will see what I can do.

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

[PATCH v5 02/12] drm/framebuffer: drm_framebuffer_read_refcount() constify argument

[Noralf Trønnes]

Constify argument so functions calling into this take a const argument.

Reviewed-by: Ville Syrjälä 
Signed-off-by: Noralf Trønnes 
Reviewed-by: Laurent Pinchart 
---
 include/drm/drm_framebuffer.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/drm/drm_framebuffer.h b/include/drm/drm_framebuffer.h
index b6996ddb19d6..6cce22e1a0f2 100644
--- a/include/drm/drm_framebuffer.h
+++ b/include/drm/drm_framebuffer.h
@@ -263,7 +263,7 @@ static inline void drm_framebuffer_unreference(struct 
drm_framebuffer *fb)
  *
  * This functions returns the framebuffer's reference count.
  */
-static inline uint32_t drm_framebuffer_read_refcount(struct drm_framebuffer 
*fb)
+static inline uint32_t drm_framebuffer_read_refcount(const struct 
drm_framebuffer *fb)
 {
return kref_read(>base.refcount);
 }
-- 
2.14.2

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

[PATCH v5 06/12] drm/cma-helper: Turn to_drm_gem_cma_obj() into a macro

[Noralf Trønnes]

This allows the argument to be a const.

The other option was to keep it an inline function and make the argument
a const:

static inline struct drm_gem_cma_object *
to_drm_gem_cma_obj(const struct drm_gem_object *gem_obj)
{
return container_of(gem_obj, struct drm_gem_cma_object, base);
}

This will happily return a non-const pointer to the drm_gem_cma_object
based on a const pointer to the contained drm_gem_object, thus creating
const-safety problems.

There was an attempt to fix the problem in the container_of() macro
itself (see https://lkml.org/lkml/2017/5/19/381) but the patch seems to
have fallen through the cracks. It would require turning this inline
function into a macro.

By making this a macro now, we will benefit from a possible future
enhancement of container_of(). We don't loose type checking by doing
this, container_of() takes care of that.

Suggested-by: Laurent Pinchart 
Signed-off-by: Noralf Trønnes 
---
 include/drm/drm_gem_cma_helper.h | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/include/drm/drm_gem_cma_helper.h b/include/drm/drm_gem_cma_helper.h
index 58a739bf15f1..7a3dcf0cf289 100644
--- a/include/drm/drm_gem_cma_helper.h
+++ b/include/drm/drm_gem_cma_helper.h
@@ -20,11 +20,8 @@ struct drm_gem_cma_object {
void *vaddr;
 };
 
-static inline struct drm_gem_cma_object *
-to_drm_gem_cma_obj(struct drm_gem_object *gem_obj)
-{
-   return container_of(gem_obj, struct drm_gem_cma_object, base);
-}
+#define to_drm_gem_cma_obj(gem_obj) \
+   container_of(gem_obj, struct drm_gem_cma_object, base)
 
 #ifndef CONFIG_MMU
 #define DRM_GEM_CMA_UNMAPPED_AREA_FOPS \
-- 
2.14.2

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

[PATCH v5 07/12] drm/cma-helper: Add drm_gem_cma_print_info()

[Noralf Trønnes]

Add drm_gem_cma_print_info() for debugfs printing
struct drm_gem_cma_object specific info.

Reviewed-by: Daniel Vetter 
Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/drm_gem_cma_helper.c | 19 +++
 include/drm/drm_gem_cma_helper.h |  3 +++
 2 files changed, 22 insertions(+)

diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c 
b/drivers/gpu/drm/drm_gem_cma_helper.c
index 020e7668dfab..29f7b0fd3ad4 100644
--- a/drivers/gpu/drm/drm_gem_cma_helper.c
+++ b/drivers/gpu/drm/drm_gem_cma_helper.c
@@ -423,6 +423,25 @@ void drm_gem_cma_describe(struct drm_gem_cma_object 
*cma_obj,
 EXPORT_SYMBOL_GPL(drm_gem_cma_describe);
 #endif
 
+/**
+ * drm_gem_cma_print_info() - Print _gem_cma_object info for debugfs
+ * @p: DRM printer
+ * @indent: Tab indentation level
+ * @gem: GEM object
+ *
+ * This function can be used as the _driver->gem_print_info callback.
+ * It prints paddr and vaddr for use in e.g. debugfs output.
+ */
+void drm_gem_cma_print_info(struct drm_printer *p, unsigned int indent,
+   const struct drm_gem_object *obj)
+{
+   const struct drm_gem_cma_object *cma_obj = to_drm_gem_cma_obj(obj);
+
+   drm_printf_indent(p, indent, "paddr=%pad\n", _obj->paddr);
+   drm_printf_indent(p, indent, "vaddr=%p\n", cma_obj->vaddr);
+}
+EXPORT_SYMBOL(drm_gem_cma_print_info);
+
 /**
  * drm_gem_cma_prime_get_sg_table - provide a scatter/gather table of pinned
  * pages for a CMA GEM object
diff --git a/include/drm/drm_gem_cma_helper.h b/include/drm/drm_gem_cma_helper.h
index 7a3dcf0cf289..40435f3480e5 100644
--- a/include/drm/drm_gem_cma_helper.h
+++ b/include/drm/drm_gem_cma_helper.h
@@ -91,6 +91,9 @@ unsigned long drm_gem_cma_get_unmapped_area(struct file *filp,
 void drm_gem_cma_describe(struct drm_gem_cma_object *obj, struct seq_file *m);
 #endif
 
+void drm_gem_cma_print_info(struct drm_printer *p, unsigned int indent,
+   const struct drm_gem_object *obj);
+
 struct sg_table *drm_gem_cma_prime_get_sg_table(struct drm_gem_object *obj);
 struct drm_gem_object *
 drm_gem_cma_prime_import_sg_table(struct drm_device *dev,
-- 
2.14.2

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

[PATCH v5 08/12] drm/arc: Use drm_gem_cma_print_info()

[Noralf Trønnes]

There is a new core debugfs file that prints fb/gem info:
/dri//framebuffer

Use drm_gem_cma_print_info() to provide info to that output instead
of using drm_fb_cma_debugfs_show().

Cc: Alexey Brodkin 
Signed-off-by: Noralf Trønnes 
Reviewed-by: Laurent Pinchart 
---
 drivers/gpu/drm/arc/arcpgu_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c b/drivers/gpu/drm/arc/arcpgu_drv.c
index 074fd4ea7ece..f067de4e1e82 100644
--- a/drivers/gpu/drm/arc/arcpgu_drv.c
+++ b/drivers/gpu/drm/arc/arcpgu_drv.c
@@ -155,7 +155,6 @@ static int arcpgu_show_pxlclock(struct seq_file *m, void 
*arg)
 
 static struct drm_info_list arcpgu_debugfs_list[] = {
{ "clocks", arcpgu_show_pxlclock, 0 },
-   { "fb", drm_fb_cma_debugfs_show, 0 },
 };
 
 static int arcpgu_debugfs_init(struct drm_minor *minor)
@@ -180,6 +179,7 @@ static struct drm_driver arcpgu_drm_driver = {
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_free_object_unlocked = drm_gem_cma_free_object,
+   .gem_print_info = drm_gem_cma_print_info,
.gem_vm_ops = _gem_cma_vm_ops,
.gem_prime_export = drm_gem_prime_export,
.gem_prime_import = drm_gem_prime_import,
-- 
2.14.2

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

[PATCH v5 04/12] drm/framebuffer: Add framebuffer debugfs file

[Noralf Trønnes]

Add debugfs file that dumps info about the framebuffers and its planes.
Also dump info about any connected gem object(s).

Reviewed-by: Daniel Vetter 
Signed-off-by: Noralf Trønnes 
Reviewed-by: Laurent Pinchart 
---
 drivers/gpu/drm/drm_debugfs.c |  6 
 drivers/gpu/drm/drm_framebuffer.c | 59 +++
 drivers/gpu/drm/drm_gem.c | 17 +++
 drivers/gpu/drm/drm_internal.h|  7 +
 include/drm/drm_drv.h | 15 ++
 5 files changed, 104 insertions(+)

diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index c1807d5754b2..550f29de6c1f 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -158,6 +158,12 @@ int drm_debugfs_init(struct drm_minor *minor, int minor_id,
}
}
 
+   ret = drm_framebuffer_debugfs_init(minor);
+   if (ret) {
+   DRM_ERROR("Failed to create framebuffer debugfs file\n");
+   return ret;
+   }
+
if (dev->driver->debugfs_init) {
ret = dev->driver->debugfs_init(minor);
if (ret) {
diff --git a/drivers/gpu/drm/drm_framebuffer.c 
b/drivers/gpu/drm/drm_framebuffer.c
index 40e6565105ac..c421dc01b334 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -25,7 +25,9 @@
 #include 
 #include 
 #include 
+#include 
 
+#include "drm_internal.h"
 #include "drm_crtc_internal.h"
 
 /**
@@ -956,3 +958,60 @@ int drm_framebuffer_plane_height(int height,
return fb_plane_height(height, fb->format, plane);
 }
 EXPORT_SYMBOL(drm_framebuffer_plane_height);
+
+void drm_framebuffer_print_info(struct drm_printer *p, unsigned int indent,
+   const struct drm_framebuffer *fb)
+{
+   struct drm_format_name_buf format_name;
+   unsigned int i;
+
+   drm_printf_indent(p, indent, "refcount=%u\n",
+ drm_framebuffer_read_refcount(fb));
+   drm_printf_indent(p, indent, "format=%s\n",
+ drm_get_format_name(fb->format->format, 
_name));
+   drm_printf_indent(p, indent, "modifier=0x%llx\n", fb->modifier);
+   drm_printf_indent(p, indent, "size=%ux%u\n", fb->width, fb->height);
+   drm_printf_indent(p, indent, "layers:\n");
+
+   for (i = 0; i < fb->format->num_planes; i++) {
+   drm_printf_indent(p, indent + 1, "size[%u]=%dx%d\n", i,
+ drm_framebuffer_plane_width(fb->width, fb, i),
+ drm_framebuffer_plane_height(fb->height, fb, 
i));
+   drm_printf_indent(p, indent + 1, "pitch[%u]=%u\n", i, 
fb->pitches[i]);
+   drm_printf_indent(p, indent + 1, "offset[%u]=%u\n", i, 
fb->offsets[i]);
+   drm_printf_indent(p, indent + 1, "obj[%u]:%s\n", i,
+ fb->obj[i] ? "" : "(null)");
+   if (fb->obj[i])
+   drm_gem_print_info(p, indent + 2, fb->obj[i]);
+   }
+}
+
+#ifdef CONFIG_DEBUG_FS
+static int drm_framebuffer_info(struct seq_file *m, void *data)
+{
+   struct drm_info_node *node = m->private;
+   struct drm_device *dev = node->minor->dev;
+   struct drm_printer p = drm_seq_file_printer(m);
+   struct drm_framebuffer *fb;
+
+   mutex_lock(>mode_config.fb_lock);
+   drm_for_each_fb(fb, dev) {
+   drm_printf(, "framebuffer[%u]:\n", fb->base.id);
+   drm_framebuffer_print_info(, 1, fb);
+   }
+   mutex_unlock(>mode_config.fb_lock);
+
+   return 0;
+}
+
+static const struct drm_info_list drm_framebuffer_debugfs_list[] = {
+   { "framebuffer", drm_framebuffer_info, 0 },
+};
+
+int drm_framebuffer_debugfs_init(struct drm_minor *minor)
+{
+   return drm_debugfs_create_files(drm_framebuffer_debugfs_list,
+   ARRAY_SIZE(drm_framebuffer_debugfs_list),
+   minor->debugfs_root, minor);
+}
+#endif
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 4c84b23d37cc..01f8d9481211 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -40,6 +40,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "drm_internal.h"
 
 /** @file drm_gem.c
@@ -1040,3 +1041,19 @@ int drm_gem_mmap(struct file *filp, struct 
vm_area_struct *vma)
return ret;
 }
 EXPORT_SYMBOL(drm_gem_mmap);
+
+void drm_gem_print_info(struct drm_printer *p, unsigned int indent,
+   const struct drm_gem_object *obj)
+{
+   drm_printf_indent(p, indent, "name=%d\n", obj->name);
+   drm_printf_indent(p, indent, "refcount=%u\n",
+ kref_read(>refcount));
+   drm_printf_indent(p, indent, "start=%08lx\n",
+ drm_vma_node_start(>vma_node));
+   drm_printf_indent(p, indent, "size=%zu\n", obj->size);
+   

[PATCH v5 03/12] drm/print: Add drm_printf_indent()

[Noralf Trønnes]

Add drm_printf_indent() that adds tab indentation according to argument.
Indentation overflow is marked with an X.

Reviewed-by: Daniel Vetter 
Signed-off-by: Noralf Trønnes 
Reviewed-by: Laurent Pinchart 
---
 include/drm/drm_print.h | 8 
 1 file changed, 8 insertions(+)

diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index 7b9c86a6ca3e..7dbfdebec973 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -80,6 +80,14 @@ void __drm_printfn_debug(struct drm_printer *p, struct 
va_format *vaf);
 __printf(2, 3)
 void drm_printf(struct drm_printer *p, const char *f, ...);
 
+/**
+ * drm_printf_indent - Print to a _printer stream with indentation
+ * @printer: DRM printer
+ * @indent: Tab indentation level (max 5)
+ * @fmt: Format string
+ */
+#define drm_printf_indent(printer, indent, fmt, ...) \
+   drm_printf((printer), "%.*s" fmt, (indent), "\t\t\t\t\tX", 
##__VA_ARGS__)
 
 /**
  * drm_seq_file_printer - construct a _printer that outputs to _file
-- 
2.14.2

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

[PATCH v5 01/12] drm/vma-manager: drm_vma_node_start() constify argument

[Noralf Trønnes]

Constify argument so functions calling into this take a const argument.

Reviewed-by: Ville Syrjälä 
Signed-off-by: Noralf Trønnes 
Reviewed-by: Laurent Pinchart 
---
 include/drm/drm_vma_manager.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/drm/drm_vma_manager.h b/include/drm/drm_vma_manager.h
index d84d52f6d2b1..8758df94e9a0 100644
--- a/include/drm/drm_vma_manager.h
+++ b/include/drm/drm_vma_manager.h
@@ -152,7 +152,7 @@ static inline void drm_vma_node_reset(struct 
drm_vma_offset_node *node)
  * Start address of @node for page-based addressing. 0 if the node does not
  * have an offset allocated.
  */
-static inline unsigned long drm_vma_node_start(struct drm_vma_offset_node 
*node)
+static inline unsigned long drm_vma_node_start(const struct 
drm_vma_offset_node *node)
 {
return node->vm_node.start;
 }
-- 
2.14.2

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

[PATCH v5 00/12] drm/framebuffer: Add framebuffer debugfs file

[Noralf Trønnes]

This patchset adds a debugfs file that prints info about the
framebuffers.

Changes since version 4:
- Add framebuffer debugfs file: Fix printk formats and add info about
  indent argument in gem_print_info callback docs (Laurent)
- Turn to_drm_gem_cma_obj() into a macro (Laurent)
- drm_gem_cma_print_info(): Make the cma_obj variable a const since it
  is derived from the obj variable which is a const.

Changes since version 3:
- Applied patch: drm/gem: Remove trailing whitespace
- Turn drm_printf_indent() into a macro (Ville)
- drm_printf_indent() add overflow marker (Jani)
- Converted arc, hdlcd, tilcdc and removed drm_fb_cma_debugfs_show()

Noralf Trønnes (12):
  drm/vma-manager: drm_vma_node_start() constify argument
  drm/framebuffer: drm_framebuffer_read_refcount() constify argument
  drm/print: Add drm_printf_indent()
  drm/framebuffer: Add framebuffer debugfs file
  drm/atomic: Use drm_framebuffer_print_info()
  drm/cma-helper: Turn to_drm_gem_cma_obj() into a macro
  drm/cma-helper: Add drm_gem_cma_print_info()
  drm/arc: Use drm_gem_cma_print_info()
  drm/arm/hdlcd: Use drm_gem_cma_print_info()
  drm/tilcdc: Use drm_gem_cma_print_info()
  drm/tinydrm: Use drm_gem_cma_print_info()
  drm/cma-helper: Remove drm_fb_cma_debugfs_show()

 drivers/gpu/drm/arc/arcpgu_drv.c |  2 +-
 drivers/gpu/drm/arm/hdlcd_drv.c  |  2 +-
 drivers/gpu/drm/drm_atomic.c | 18 ++-
 drivers/gpu/drm/drm_debugfs.c|  6 
 drivers/gpu/drm/drm_fb_cma_helper.c  | 37 --
 drivers/gpu/drm/drm_framebuffer.c| 59 
 drivers/gpu/drm/drm_gem.c| 17 +++
 drivers/gpu/drm/drm_gem_cma_helper.c | 31 ---
 drivers/gpu/drm/drm_internal.h   |  7 +
 drivers/gpu/drm/tilcdc/tilcdc_drv.c  |  2 +-
 drivers/gpu/drm/tinydrm/mipi-dbi.c   |  8 +
 include/drm/drm_drv.h| 15 +
 include/drm/drm_fb_cma_helper.h  |  6 
 include/drm/drm_framebuffer.h|  2 +-
 include/drm/drm_gem_cma_helper.h | 12 +++-
 include/drm/drm_print.h  |  8 +
 include/drm/drm_vma_manager.h|  2 +-
 include/drm/tinydrm/tinydrm.h|  1 +
 18 files changed, 138 insertions(+), 97 deletions(-)

--
2.14.2

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

[Bug 103613] Reverse Prime with intel/amdgpu causes segfault in glamor_block_handler when enabling monitor

[bugzilla-daemon]

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

Bug ID: 103613
   Summary: Reverse Prime with intel/amdgpu causes segfault in
glamor_block_handler when enabling monitor
   Product: DRI
   Version: DRI git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: e...@xmw.de

I have a discrete AMD card (Tonga) using amdgpu and an iGPU (Skylake/HD530)
using the intel driver.

I enabled DRI3 on both devices, but xrandr only shows the outputs/monitors of
the AMD card.

When I use "xrandr --setprovideroutputsource 1 0" everything is still fine,
xrandr shows now all outputs/monitors.

When I try to enable the monitor connected to the iGPU via "xrandr --output
HDMI3 --auto" the x-server segfaults with the following backtrace:

#0  0x7fdffdd2334d in glamor_block_handler () from
/usr/lib64/xorg/modules/libglamoregl.so
#1  0x7fe00d639f8b in amdgpu_glamor_flush () from
/usr/lib64/xorg/modules/drivers/amdgpu_drv.so
#2  0x7fe00d62df23 in redisplay_dirty () from
/usr/lib64/xorg/modules/drivers/amdgpu_drv.so
#3  0x7fe00d62f728 in AMDGPUBlockHandler_KMS () from
/usr/lib64/xorg/modules/drivers/amdgpu_drv.so
#4  0x0043a27f in BlockHandler ()
#5  0x00587ac3 in WaitForSomething ()

Here are further details, including the Xorg.log and the used configs:
https://gist.github.com/EoD/c1c4f2b4afde2d0523e9ea8bb1567452

-- 
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: [Intel-gfx] [RFC 1/7] drm: Add Plane Degamma properties

[Brian Starkey]

On Tue, Nov 07, 2017 at 05:49:56PM +, Brian Starkey wrote:


In one of the previous discussions[1] related to per-plane color
management, Lionel suggested that the 16-bit color lut entries weren't
enough when considering HDR.

It might be worth creating a new gamma lut format with 32-bit entries
for these new properties, as HDR is very much a real rather than
hypothetical concern these days.

Thanks,
-Brian


Sorry, failed to paste the link:

[1] https://patchwork.kernel.org/patch/9546905/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [RFC 1/7] drm: Add Plane Degamma properties

[Brian Starkey]

Hi,

On Tue, Nov 07, 2017 at 05:36:25PM +0530, Uma Shankar wrote:

Add Plane Degamma as a blob property and plane
degamma size as a range property.

v2: Rebase

Signed-off-by: Uma Shankar 
---
drivers/gpu/drm/drm_atomic.c|   12 
drivers/gpu/drm/drm_atomic_helper.c |6 ++
drivers/gpu/drm/drm_mode_config.c   |   14 ++
include/drm/drm_mode_config.h   |   11 +++
include/drm/drm_plane.h |   10 ++
5 files changed, 53 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 7e0e7be..30853c7 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -713,6 +713,8 @@ static int drm_atomic_plane_set_property(struct drm_plane 
*plane,
{
struct drm_device *dev = plane->dev;
struct drm_mode_config *config = >mode_config;
+   bool replaced = false;
+   int ret;

if (property == config->prop_fb_id) {
struct drm_framebuffer *fb = drm_framebuffer_lookup(dev, NULL, 
val);
@@ -758,6 +760,12 @@ static int drm_atomic_plane_set_property(struct drm_plane 
*plane,
} else if (plane->funcs->atomic_set_property) {
return plane->funcs->atomic_set_property(plane, state,
property, val);
+   } else if (property == config->plane_degamma_lut_property) {
+   ret = drm_atomic_replace_property_blob_from_id(dev,
+   >degamma_lut,
+   val, -1, );
+   state->color_mgmt_changed |= replaced;
+   return ret;
} else {
return -EINVAL;
}
@@ -816,6 +824,9 @@ static int drm_atomic_plane_set_property(struct drm_plane 
*plane,
*val = state->zpos;
} else if (plane->funcs->atomic_get_property) {
return plane->funcs->atomic_get_property(plane, state, 
property, val);
+   } else if (property == config->plane_degamma_lut_property) {
+   *val = (state->degamma_lut) ?
+   state->degamma_lut->base.id : 0;
} else {
return -EINVAL;
}
@@ -953,6 +964,7 @@ static void drm_atomic_plane_print_state(struct drm_printer 
*p,
drm_printf(p, "\tcrtc-pos=" DRM_RECT_FMT "\n", DRM_RECT_ARG());
drm_printf(p, "\tsrc-pos=" DRM_RECT_FP_FMT "\n", DRM_RECT_FP_ARG());
drm_printf(p, "\trotation=%x\n", state->rotation);
+   drm_printf(p, "\tcolor_mgmt_changed=%d\n", state->color_mgmt_changed);

if (plane->funcs->atomic_print_state)
plane->funcs->atomic_print_state(p, state);
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 71d712f..ba924cf 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3395,6 +3395,10 @@ void __drm_atomic_helper_plane_duplicate_state(struct 
drm_plane *plane,

state->fence = NULL;
state->commit = NULL;
+
+   if (state->degamma_lut)
+   drm_property_blob_get(state->degamma_lut);
+   state->color_mgmt_changed = false;
}
EXPORT_SYMBOL(__drm_atomic_helper_plane_duplicate_state);

@@ -3439,6 +3443,8 @@ void __drm_atomic_helper_plane_destroy_state(struct 
drm_plane_state *state)

if (state->commit)
drm_crtc_commit_put(state->commit);
+
+   drm_property_blob_put(state->degamma_lut);
}
EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);

diff --git a/drivers/gpu/drm/drm_mode_config.c 
b/drivers/gpu/drm/drm_mode_config.c
index cda8bfa..118f6ac 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -348,6 +348,20 @@ static int drm_mode_create_standard_properties(struct 
drm_device *dev)
return -ENOMEM;
dev->mode_config.modifiers_property = prop;

+   prop = drm_property_create(dev,
+   DRM_MODE_PROP_BLOB,
+   "PLANE_DEGAMMA_LUT", 0);
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.plane_degamma_lut_property = prop;
+
+   prop = drm_property_create_range(dev,
+   DRM_MODE_PROP_IMMUTABLE,
+   "PLANE_DEGAMMA_LUT_SIZE", 0, UINT_MAX);
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.plane_degamma_lut_size_property = prop;
+
return 0;
}

diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 0b4ac2e..6ee2df6 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -718,6 +718,17 @@ struct drm_mode_config {
struct drm_property *gamma_lut_size_property;

/**
+* @plane_degamma_lut_property: Optional Plane property to set the LUT
+* used to convert the framebuffer's colors to linear gamma.
+*/
+   struct drm_property *plane_degamma_lut_property;
+   /**
+* 

Re: [RFC 2/7] drm: Add Plane CTM property

[Brian Starkey]

Hi Uma,

On Tue, Nov 07, 2017 at 05:36:26PM +0530, Uma Shankar wrote:

Add a blob property for plane CSC usage.

v2: Rebase

Signed-off-by: Uma Shankar 
---
drivers/gpu/drm/drm_atomic.c|   10 ++
drivers/gpu/drm/drm_atomic_helper.c |3 +++
drivers/gpu/drm/drm_mode_config.c   |7 +++
include/drm/drm_mode_config.h   |6 ++
include/drm/drm_plane.h |8 
5 files changed, 34 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 30853c7..45aede5 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -766,6 +766,14 @@ static int drm_atomic_plane_set_property(struct drm_plane 
*plane,
val, -1, );
state->color_mgmt_changed |= replaced;
return ret;
+   } else if (property == config->plane_ctm_property) {
+   ret = drm_atomic_replace_property_blob_from_id(dev,
+   >ctm,
+   val,
+   sizeof(struct drm_color_ctm),
+   );
+   state->color_mgmt_changed |= replaced;
+   return ret;
} else {
return -EINVAL;
}
@@ -827,6 +835,8 @@ static int drm_atomic_plane_set_property(struct drm_plane 
*plane,
} else if (property == config->plane_degamma_lut_property) {
*val = (state->degamma_lut) ?
state->degamma_lut->base.id : 0;
+   } else if (property == config->plane_ctm_property) {
+   *val = (state->ctm) ? state->ctm->base.id : 0;
} else {
return -EINVAL;
}
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index ba924cf..d3154e0 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3398,6 +3398,8 @@ void __drm_atomic_helper_plane_duplicate_state(struct 
drm_plane *plane,

if (state->degamma_lut)
drm_property_blob_get(state->degamma_lut);
+   if (state->ctm)
+   drm_property_blob_get(state->ctm);
state->color_mgmt_changed = false;
}
EXPORT_SYMBOL(__drm_atomic_helper_plane_duplicate_state);
@@ -3445,6 +3447,7 @@ void __drm_atomic_helper_plane_destroy_state(struct 
drm_plane_state *state)
drm_crtc_commit_put(state->commit);

drm_property_blob_put(state->degamma_lut);
+   drm_property_blob_put(state->ctm);
}
EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);

diff --git a/drivers/gpu/drm/drm_mode_config.c 
b/drivers/gpu/drm/drm_mode_config.c
index 118f6ac..bccc70e 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -362,6 +362,13 @@ static int drm_mode_create_standard_properties(struct 
drm_device *dev)
return -ENOMEM;
dev->mode_config.plane_degamma_lut_size_property = prop;

+   prop = drm_property_create(dev,
+   DRM_MODE_PROP_BLOB,
+   "PLANE_CTM", 0);


I do wonder if "PLANE_" is really needed here, as the property will
only ever be found on a plane (same would apply to all three property
names).


+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.plane_ctm_property = prop;
+
return 0;
}

diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 6ee2df6..3bf7fc6 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -727,6 +727,12 @@ struct drm_mode_config {
 * size of the degamma LUT as supported by the driver (read-only).
 */
struct drm_property *plane_degamma_lut_size_property;
+   /**
+* @plane_ctm_property: Optional CRTC property to set the
+* matrix used to convert colors after the lookup in the
+* degamma LUT.
+*/


Copy-paste error - should be "Optional plane property"

Thanks,
-Brian


+   struct drm_property *plane_ctm_property;

/**
 * @suggested_x_property: Optional connector property with a hint for
diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
index d112c50..7fcc51e 100644
--- a/include/drm/drm_plane.h
+++ b/include/drm/drm_plane.h
@@ -132,6 +132,14 @@ struct drm_plane_state {
struct drm_property_blob *degamma_lut;

/**
+* @ctm:
+*
+* Color transformation matrix. See drm_plane_enable_color_mgmt(). The
+* blob (if not NULL) is a  drm_color_ctm.
+*/
+   struct drm_property_blob *ctm;
+
+   /**
 * @commit: Tracks the pending commit to prevent use-after-free 
conditions,
 * and for async plane updates.
 *
--
1.7.9.5

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

[PATCH v3 7/7] drm/bridge: tc358767: add copyright lines

[Andrey Gusakov]

Add copyright lines for Zodiac who paid for driver development.

Signed-off-by: Andrey Gusakov 
---
 drivers/gpu/drm/bridge/tc358767.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/bridge/tc358767.c 
b/drivers/gpu/drm/bridge/tc358767.c
index 37e33f2..69d2af3 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -6,6 +6,8 @@
  *
  * Copyright (C) 2016 Pengutronix, Philipp Zabel 
  *
+ * Copyright (C) 2016 Zodiac Inflight Innovations
+ *
  * Initially based on: drivers/gpu/drm/i2c/tda998x_drv.c
  *
  * Copyright (C) 2012 Texas Instruments
-- 
1.7.10.4

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

[PATCH v3 6/7] drm/bridge: tc358767: fix 1-lane behavior

[Andrey Gusakov]

Use drm_dp_channel_eq_ok helper

Acked-by: Philipp Zabel 
Signed-off-by: Andrey Gusakov 
---
 drivers/gpu/drm/bridge/tc358767.c |   13 +++--
 1 file changed, 3 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/bridge/tc358767.c 
b/drivers/gpu/drm/bridge/tc358767.c
index bb5d277..37e33f2 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -819,8 +819,6 @@ static int tc_main_link_setup(struct tc_data *tc)
unsigned int rate;
u32 dp_phy_ctrl;
int timeout;
-   bool aligned;
-   bool ready;
u32 value;
int ret;
u8 tmp[8];
@@ -965,16 +963,15 @@ static int tc_main_link_setup(struct tc_data *tc)
ret = drm_dp_dpcd_read_link_status(aux, tmp + 2);
if (ret < 0)
goto err_dpcd_read;
-   ready = (tmp[2] == ((DP_CHANNEL_EQ_BITS << 4) | /* Lane1 */
-DP_CHANNEL_EQ_BITS));  /* Lane0 */
-   aligned = tmp[4] & DP_INTERLANE_ALIGN_DONE;
-   } while ((--timeout) && !(ready && aligned));
+   } while ((--timeout) &&
+!(drm_dp_channel_eq_ok(tmp + 2,  tc->link.base.num_lanes)));
 
if (timeout == 0) {
/* Read DPCD 0x200-0x201 */
ret = drm_dp_dpcd_read(aux, DP_SINK_COUNT, tmp, 2);
if (ret < 0)
goto err_dpcd_read;
+   dev_err(dev, "channel(s) EQ not ok\n");
dev_info(dev, "0x0200 SINK_COUNT: 0x%02x\n", tmp[0]);
dev_info(dev, "0x0201 DEVICE_SERVICE_IRQ_VECTOR: 0x%02x\n",
 tmp[1]);
@@ -985,10 +982,6 @@ static int tc_main_link_setup(struct tc_data *tc)
dev_info(dev, "0x0206 ADJUST_REQUEST_LANE0_1: 0x%02x\n",
 tmp[6]);
 
-   if (!ready)
-   dev_err(dev, "Lane0/1 not ready\n");
-   if (!aligned)
-   dev_err(dev, "Lane0/1 not aligned\n");
return -EAGAIN;
}
 
-- 
1.7.10.4

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

[PATCH v3 2/7] drm/bridge: tc358767: filter out too high modes

[Andrey Gusakov]

Pixel clock limitation for DPI is 154 MHz. Do not accept modes
with higher pixel clock rate.

Reviewed-by: Andrzej Hajda 
Signed-off-by: Andrey Gusakov 
---
 drivers/gpu/drm/bridge/tc358767.c |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/tc358767.c 
b/drivers/gpu/drm/bridge/tc358767.c
index d52cd41..948a486 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -1103,7 +1103,10 @@ static bool tc_bridge_mode_fixup(struct drm_bridge 
*bridge,
 static int tc_connector_mode_valid(struct drm_connector *connector,
   struct drm_display_mode *mode)
 {
-   /* Accept any mode */
+   /* DPI interface clock limitation: upto 154 MHz */
+   if (mode->clock > 154000)
+   return MODE_CLOCK_HIGH;
+
return MODE_OK;
 }
 
-- 
1.7.10.4

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

[PATCH v3 3/7] drm/bridge: tc358767: fix DP0_MISC register set

[Andrey Gusakov]

Remove shift from TU_SIZE_RECOMMENDED define as it used to
calculate max_tu_symbols.

Acked-by: Philipp Zabel 
Signed-off-by: Andrey Gusakov 
---
 drivers/gpu/drm/bridge/tc358767.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/tc358767.c 
b/drivers/gpu/drm/bridge/tc358767.c
index 948a486..47e23a2 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -97,7 +97,7 @@
 #define DP0_ACTIVEVAL  0x0650
 #define DP0_SYNCVAL0x0654
 #define DP0_MISC   0x0658
-#define TU_SIZE_RECOMMENDED(0x3f << 16) /* LSCLK cycles per TU */
+#define TU_SIZE_RECOMMENDED(63) /* LSCLK cycles per TU */
 #define BPC_6  (0 << 5)
 #define BPC_8  (1 << 5)
 
@@ -716,7 +716,8 @@ static int tc_set_video_mode(struct tc_data *tc, struct 
drm_display_mode *mode)
 * Must be less than tu_size.
 */
max_tu_symbol = TU_SIZE_RECOMMENDED - 1;
-   tc_write(DP0_MISC, (max_tu_symbol << 23) | TU_SIZE_RECOMMENDED | BPC_8);
+   tc_write(DP0_MISC, (max_tu_symbol << 23) | (TU_SIZE_RECOMMENDED << 16) |
+  BPC_8);
 
return 0;
 err:
-- 
1.7.10.4

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

[PATCH v3 4/7] drm/bridge: tc358767: fix timing calculations

[Andrey Gusakov]

Fields in HTIM01 and HTIM02 regs should be even.
Recomended thresh_dly value is max_tu_symbol.
Remove set of VPCTRL0.VSDELAY as it is related to DSI input
interface. Currently driver supports only DPI.

Acked-by: Philipp Zabel 
Signed-off-by: Andrey Gusakov 
---
 drivers/gpu/drm/bridge/tc358767.c |   34 --
 1 file changed, 20 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/bridge/tc358767.c 
b/drivers/gpu/drm/bridge/tc358767.c
index 47e23a2..29c99dc 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -659,6 +659,14 @@ static int tc_set_video_mode(struct tc_data *tc, struct 
drm_display_mode *mode)
int lower_margin = mode->vsync_start - mode->vdisplay;
int vsync_len = mode->vsync_end - mode->vsync_start;
 
+   /*
+* Recommended maximum number of symbols transferred in a transfer unit:
+* DIV_ROUND_UP((input active video bandwidth in bytes) * tu_size,
+*  (output active video bandwidth in bytes))
+* Must be less than tu_size.
+*/
+   max_tu_symbol = TU_SIZE_RECOMMENDED - 1;
+
dev_dbg(tc->dev, "set mode %dx%d\n",
mode->hdisplay, mode->vdisplay);
dev_dbg(tc->dev, "H margin %d,%d sync %d\n",
@@ -668,13 +676,18 @@ static int tc_set_video_mode(struct tc_data *tc, struct 
drm_display_mode *mode)
dev_dbg(tc->dev, "total: %dx%d\n", mode->htotal, mode->vtotal);
 
 
-   /* LCD Ctl Frame Size */
-   tc_write(VPCTRL0, (0x40 << 20) /* VSDELAY */ |
+   /*
+* LCD Ctl Frame Size
+* datasheet is not clear of vsdelay in case of DPI
+* assume we do not need any delay when DPI is a source of
+* sync signals
+*/
+   tc_write(VPCTRL0, (0 << 20) /* VSDELAY */ |
 OPXLFMT_RGB888 | FRMSYNC_DISABLED | MSF_DISABLED);
-   tc_write(HTIM01, (left_margin << 16) |  /* H back porch */
-(hsync_len << 0)); /* Hsync */
-   tc_write(HTIM02, (right_margin << 16) | /* H front porch */
-(mode->hdisplay << 0));/* width */
+   tc_write(HTIM01, (ALIGN(left_margin, 2) << 16) | /* H back porch */
+(ALIGN(hsync_len, 2) << 0));/* Hsync */
+   tc_write(HTIM02, (ALIGN(right_margin, 2) << 16) |  /* H front porch */
+(ALIGN(mode->hdisplay, 2) << 0)); /* width */
tc_write(VTIM01, (upper_margin << 16) | /* V back porch */
 (vsync_len << 0)); /* Vsync */
tc_write(VTIM02, (lower_margin << 16) | /* V front porch */
@@ -693,7 +706,7 @@ static int tc_set_video_mode(struct tc_data *tc, struct 
drm_display_mode *mode)
/* DP Main Stream Attributes */
vid_sync_dly = hsync_len + left_margin + mode->hdisplay;
tc_write(DP0_VIDSYNCDELAY,
-(0x003e << 16) |   /* thresh_dly */
+(max_tu_symbol << 16) |/* thresh_dly */
 (vid_sync_dly << 0));
 
tc_write(DP0_TOTALVAL, (mode->vtotal << 16) | (mode->htotal));
@@ -709,13 +722,6 @@ static int tc_set_video_mode(struct tc_data *tc, struct 
drm_display_mode *mode)
tc_write(DPIPXLFMT, VS_POL_ACTIVE_LOW | HS_POL_ACTIVE_LOW |
 DE_POL_ACTIVE_HIGH | SUB_CFG_TYPE_CONFIG1 | DPI_BPP_RGB888);
 
-   /*
-* Recommended maximum number of symbols transferred in a transfer unit:
-* DIV_ROUND_UP((input active video bandwidth in bytes) * tu_size,
-*  (output active video bandwidth in bytes))
-* Must be less than tu_size.
-*/
-   max_tu_symbol = TU_SIZE_RECOMMENDED - 1;
tc_write(DP0_MISC, (max_tu_symbol << 23) | (TU_SIZE_RECOMMENDED << 16) |
   BPC_8);
 
-- 
1.7.10.4

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

[PATCH v3 5/7] drm/bridge: tc358767: fix AUXDATAn registers access

[Andrey Gusakov]

First four bytes should go to DP0_AUXWDATA0. Due to bug if
len > 4 first four bytes was writen to DP0_AUXWDATA1 and all
data get shifted by 4 bytes. Fix it.

Acked-by: Philipp Zabel 
Signed-off-by: Andrey Gusakov 
---
 drivers/gpu/drm/bridge/tc358767.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/tc358767.c 
b/drivers/gpu/drm/bridge/tc358767.c
index 29c99dc..bb5d277 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -318,7 +318,7 @@ static ssize_t tc_aux_transfer(struct drm_dp_aux *aux,
tmp = (tmp << 8) | buf[i];
i++;
if (((i % 4) == 0) || (i == size)) {
-   tc_write(DP0_AUXWDATA(i >> 2), tmp);
+   tc_write(DP0_AUXWDATA((i - 1) >> 2), tmp);
tmp = 0;
}
}
-- 
1.7.10.4

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

[PATCH v3 1/7] drm/bridge: tc358767: do no fail on hi-res displays

[Andrey Gusakov]

Do not fail data rates higher than 2.7 and more than 2 lanes.
Try to fall back to 2.7Gbps and 2 lanes.

Acked-by: Philipp Zabel 
Reviewed-by: Andrzej Hajda 
Signed-off-by: Andrey Gusakov 
---
 drivers/gpu/drm/bridge/tc358767.c |   14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/bridge/tc358767.c 
b/drivers/gpu/drm/bridge/tc358767.c
index 8571cfd..d52cd41 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -603,8 +603,15 @@ static int tc_get_display_props(struct tc_data *tc)
ret = drm_dp_link_probe(>aux, >link.base);
if (ret < 0)
goto err_dpcd_read;
-   if ((tc->link.base.rate != 162000) && (tc->link.base.rate != 27))
-   goto err_dpcd_inval;
+   if ((tc->link.base.rate != 162000) && (tc->link.base.rate != 27)) {
+   dev_dbg(tc->dev, "Falling to 2.7 Gbps rate\n");
+   tc->link.base.rate = 27;
+   }
+
+   if (tc->link.base.num_lanes > 2) {
+   dev_dbg(tc->dev, "Falling to 2 lanes\n");
+   tc->link.base.num_lanes = 2;
+   }
 
ret = drm_dp_dpcd_readb(>aux, DP_MAX_DOWNSPREAD, tmp);
if (ret < 0)
@@ -637,9 +644,6 @@ static int tc_get_display_props(struct tc_data *tc)
 err_dpcd_read:
dev_err(tc->dev, "failed to read DPCD: %d\n", ret);
return ret;
-err_dpcd_inval:
-   dev_err(tc->dev, "invalid DPCD\n");
-   return -EINVAL;
 }
 
 static int tc_set_video_mode(struct tc_data *tc, struct drm_display_mode *mode)
-- 
1.7.10.4

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

[PATCH v3 0/7] drm/bridge: tc358767: fixes and improvements

[Andrey Gusakov]

This set of patches fixes several issues that was found during testing
tc358767 with desktop DisplayPort displays.

Changes since v3
- added comment about removed VPCTRL0 write
- corrected comment in "filter out too high modes"
- added sing-off

Changes since v2:
- fixed maximum pixelclock frequency
- copyright patch added

Andrey Gusakov (7):
  drm/bridge: tc358767: do no fail on hi-res displays
  drm/bridge: tc358767: filter out too high modes
  drm/bridge: tc358767: fix DP0_MISC register set
  drm/bridge: tc358767: fix timing calculations
  drm/bridge: tc358767: fix AUXDATAn registers access
  drm/bridge: tc358767: fix 1-lane behavior
  drm/bridge: tc358767: add copyright lines

 drivers/gpu/drm/bridge/tc358767.c |   75 +
 1 file changed, 42 insertions(+), 33 deletions(-)

-- 
1.7.10.4

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

Re: [PATCH 1/3] ASoC: amd: Report accurate hw_ptr during dma

[Agrawal, Akshu]

On 11/7/2017 5:07 PM, Mark Brown wrote:

On Tue, Nov 07, 2017 at 07:26:03PM +0530, Mukunda,Vijendar wrote:

Removing URL links and commit-ready description in v2.


This doesn't really answer my question:


These two URLs are different, what was being reviewed here?  What is
Commit-Ready supposed to mean?


Same patch is reviewed, once on 4.4 kernel (659699) and then on 4.12 
kernel (672267).

Commit-ready is to get it merged on tree after receiving a +2.



Please don't top post, reply in line with needed context.  This allows
readers to readily follow the flow of conversation and understand what
you are talking about and also helps ensure that everything in the
discussion is being addressed.


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

Re: [PATCH] drm/ttm: set bo->resv point to tbo->ttm_resv after individualize_resv

[Michel Dänzer]

On 07/11/17 02:44 PM, Christian König wrote:
> Set bo->resv to ttm_resv during BO cleanup. This way freed BOs can be
> better reaped during eviction.
> 
> Signed-off-by: Roger He 
> Signed-off-by: Christian König 

KASAN caught some badness while running piglit with this applied, see
the attached dmesg excerpts.


At least some of this might be pre-existing bugs being exposed by this
change. E.g. I've been chasing another use-after-free, with
ttm_bo_delayed_delete trying to reserve a BO which has already been
destroyed. Looks like maybe the ddestroy list handling isn't quite
watertight yet.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
Nov  7 16:36:02 kaveri kernel: [  164.320428] ==
Nov  7 16:36:02 kaveri kernel: [  164.320482] BUG: KASAN: use-after-free in amdgpu_ttm_copy_mem_to_mem+0x1171/0x15f0 [amdgpu]
Nov  7 16:36:02 kaveri kernel: [  164.320485] Read of size 8 at addr 880398d9f010 by task max-texture-siz/7130
Nov  7 16:36:02 kaveri kernel: [  164.320486] 
Nov  7 16:36:02 kaveri kernel: [  164.320490] CPU: 1 PID: 7130 Comm: max-texture-siz Tainted: G   O4.14.0-rc3+ #32
Nov  7 16:36:02 kaveri kernel: [  164.320492] Hardware name: Micro-Star International Co., Ltd. MS-7A34/B350 TOMAHAWK (MS-7A34), BIOS 1.80 09/13/2017
Nov  7 16:36:02 kaveri kernel: [  164.320492] Call Trace:
Nov  7 16:36:02 kaveri kernel: [  164.320498]  dump_stack+0xad/0x139
Nov  7 16:36:02 kaveri kernel: [  164.320501]  ? dma_virt_map_sg+0x1f7/0x1f7
Nov  7 16:36:02 kaveri kernel: [  164.320505]  print_address_description+0x6a/0x270
Nov  7 16:36:02 kaveri kernel: [  164.320507]  kasan_report+0x277/0x360
Nov  7 16:36:02 kaveri kernel: [  164.320547]  ? amdgpu_ttm_copy_mem_to_mem+0x1171/0x15f0 [amdgpu]
Nov  7 16:36:02 kaveri kernel: [  164.320587]  amdgpu_ttm_copy_mem_to_mem+0x1171/0x15f0 [amdgpu]
Nov  7 16:36:02 kaveri kernel: [  164.320590]  ? security_capable+0x6d/0xa0
Nov  7 16:36:02 kaveri kernel: [  164.320595]  ? ttm_check_swapping+0x26/0x240 [ttm]
Nov  7 16:36:02 kaveri kernel: [  164.320599]  ? ttm_mem_global_alloc_zone.constprop.4+0x1bc/0x290 [ttm]
Nov  7 16:36:02 kaveri kernel: [  164.320657]  ? amdgpu_copy_buffer+0x7c0/0x7c0 [amdgpu]
Nov  7 16:36:02 kaveri kernel: [  164.320666]  ? ttm_pool_populate+0x618/0xb40 [ttm]
Nov  7 16:36:02 kaveri kernel: [  164.320674]  ? ttm_pool_unpopulate+0x290/0x290 [ttm]
Nov  7 16:36:02 kaveri kernel: [  164.320677]  ? kasan_unpoison_shadow+0x30/0x40
Nov  7 16:36:02 kaveri kernel: [  164.320732]  amdgpu_move_blit.constprop.17+0x227/0x4a0 [amdgpu]
Nov  7 16:36:02 kaveri kernel: [  164.320735]  ? __kmalloc_node+0x170/0x280
Nov  7 16:36:02 kaveri kernel: [  164.320739]  ? ttm_dma_tt_init+0x27a/0x520 [ttm]
Nov  7 16:36:02 kaveri kernel: [  164.320781]  ? amdgpu_ttm_copy_mem_to_mem+0x15f0/0x15f0 [amdgpu]
Nov  7 16:36:02 kaveri kernel: [  164.320788]  ? ttm_dma_tt_init+0x27a/0x520 [ttm]
Nov  7 16:36:02 kaveri kernel: [  164.320833]  ? amdgpu_bo_move_notify+0xf9/0x310 [amdgpu]
Nov  7 16:36:02 kaveri kernel: [  164.320873]  amdgpu_bo_move+0x227/0x700 [amdgpu]
Nov  7 16:36:02 kaveri kernel: [  164.320879]  ttm_bo_handle_move_mem+0x86a/0x2300 [ttm]
Nov  7 16:36:02 kaveri kernel: [  164.320883]  ? ttm_bo_mem_space+0x54e/0xe90 [ttm]
Nov  7 16:36:02 kaveri kernel: [  164.320936]  ? amdgpu_evict_flags+0x285/0x620 [amdgpu]
Nov  7 16:36:02 kaveri kernel: [  164.320944]  ttm_bo_evict+0x3ee/0xc70 [ttm]
Nov  7 16:36:02 kaveri kernel: [  164.320968]  ? drm_mm_init+0x4d0/0x4d0 [drm]
Nov  7 16:36:02 kaveri kernel: [  164.320975]  ? ttm_bo_handle_move_mem+0x2300/0x2300 [ttm]
Nov  7 16:36:02 kaveri kernel: [  164.320983]  ? ttm_bo_add_to_lru+0x42f/0x640 [ttm]
Nov  7 16:36:02 kaveri kernel: [  164.320987]  ? bpf_prog_alloc+0x2d0/0x2d0
Nov  7 16:36:02 kaveri kernel: [  164.320990]  ? deref_stack_reg+0x1f0/0x1f0
Nov  7 16:36:02 kaveri kernel: [  164.320994]  ? kmalloc_order+0x4b/0x60
Nov  7 16:36:02 kaveri kernel: [  164.321002]  ttm_mem_evict_first+0x2e0/0x460 [ttm]
Nov  7 16:36:02 kaveri kernel: [  164.321010]  ? ttm_bo_evict+0xc70/0xc70 [ttm]
Nov  7 16:36:02 kaveri kernel: [  164.321018]  ttm_bo_mem_space+0x894/0xe90 [ttm]
Nov  7 16:36:02 kaveri kernel: [  164.321026]  ? ttm_bo_mem_compat+0x6b/0x130 [ttm]
Nov  7 16:36:02 kaveri kernel: [  164.321032]  ttm_bo_validate+0x301/0x530 [ttm]
Nov  7 16:36:02 kaveri kernel: [  164.321037]  ? ttm_bo_evict_mm+0xa0/0xa0 [ttm]
Nov  7 16:36:02 kaveri kernel: [  164.321039]  ? SyS_membarrier+0x2b0/0x2b0
Nov  7 16:36:02 kaveri kernel: [  164.321057]  ? drm_vma_offset_add+0xb4/0x180 [drm]
Nov  7 16:36:02 kaveri kernel: [  164.321065]  ttm_bo_init_reserved+0xaf3/0x1200 [ttm]
Nov  7 16:36:02 kaveri kernel: [  164.321071]  ? ttm_bo_validate+0x530/0x530 [ttm]
Nov  7 16:36:02 kaveri kernel: [  164.321075]  ? get_empty_filp+0x27b/0x530
Nov  7 16:36:02 kaveri 

Re: [Intel-gfx] [PATCH 0/7] Add Plane Color Properties

[Daniel Stone]

Hi Uma,

On 7 November 2017 at 12:06, Uma Shankar  wrote:
> This patch series adds properties for plane color features. It adds
> properties for degamma used to linearize data, CSC used for gamut
> conversion, and gamma used to again non-linearize data as per panel
> supported color space. These can be utilize by user space to convert
> planes from one format to another, one color space to another etc.
>
> Usersapce can take smart blending decisions and utilize these hardware
> supported plane color features to get accurate color profile. The same
> can help in consistent color quality from source to panel taking
> advantage of advanced color features in hardware.
>
> These patches just add the property interfaces and enable helper functions.

This is missing documentation on how plane colour management interacts
with CRTC colour management. Is it a step before CRTC colour
management is applied, or does it bypass CRTC colour management, or
... ?

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

Re: [PATCH] drm/stm: ltdc: add clut mode support

[Philippe CORNU]

+ Peter

Hi Peter,

CLUT support on STM32 has been removed thanks to your clean up patch 
named "drm: stm: remove dead code and pointless local lut storage" 
(https://patchwork.freedesktop.org/patch/166898/)

This below patch puts back the clut mode support using the new drm gamma 
api.

May I ask you please a short review on this patch?

Many thanks,
Philippe :-)


On 10/26/2017 01:17 PM, Philippe Cornu wrote:
> Add the 8-bit clut mode support at crtc level.
> Useful for low memory footprint user interfaces but also for
> 8-bit old games (including color shifting visual effects).
> Tested with fbdev FBIOPUTCMAP & drm DRM_IOCTL_MODE_SETGAMMA
> ioctls.
> 
> Signed-off-by: Philippe Cornu 
> ---
>   drivers/gpu/drm/stm/ltdc.c | 30 ++
>   1 file changed, 30 insertions(+)
> 
> diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
> index 7be6710..d5c8a42 100644
> --- a/drivers/gpu/drm/stm/ltdc.c
> +++ b/drivers/gpu/drm/stm/ltdc.c
> @@ -174,6 +174,8 @@
>   
>   #define LXCFBLNR_CFBLN  GENMASK(10, 0)  /* Color Frame Buffer Line 
> Number */
>   
> +#define CLUT_SIZE256
> +
>   #define CONSTA_MAX  0xFF/* CONSTant Alpha MAX= 1.0 */
>   #define BF1_PAXCA   0x600   /* Pixel Alpha x Constant Alpha */
>   #define BF1_CA  0x400   /* Constant Alpha */
> @@ -362,6 +364,28 @@ static irqreturn_t ltdc_irq(int irq, void *arg)
>* DRM_CRTC
>*/
>   
> +static void ltdc_crtc_update_clut(struct drm_crtc *crtc)
> +{
> + struct ltdc_device *ldev = crtc_to_ltdc(crtc);
> + struct drm_color_lut *lut;
> + u32 val;
> + int i;
> +
> + if (!crtc || !crtc->state)
> + return;
> +
> + if (!crtc->state->color_mgmt_changed || !crtc->state->gamma_lut)
> + return;
> +
> + lut = (struct drm_color_lut *)crtc->state->gamma_lut->data;
> +
> + for (i = 0; i < CLUT_SIZE; i++, lut++) {
> + val = ((lut->red << 8) & 0xff) | (lut->green & 0xff00) |
> + (lut->blue >> 8) | (i << 24);
> + reg_write(ldev->regs, LTDC_L1CLUTWR, val);
> + }
> +}
> +
>   static void ltdc_crtc_atomic_enable(struct drm_crtc *crtc,
>   struct drm_crtc_state *old_state)
>   {
> @@ -485,6 +509,8 @@ static void ltdc_crtc_atomic_flush(struct drm_crtc *crtc,
>   
>   DRM_DEBUG_ATOMIC("\n");
>   
> + ltdc_crtc_update_clut(crtc);
> +
>   /* Commit shadow registers = update planes at next vblank */
>   reg_set(ldev->regs, LTDC_SRCR, SRCR_VBR);
>   
> @@ -532,6 +558,7 @@ void ltdc_crtc_disable_vblank(struct drm_device *ddev, 
> unsigned int pipe)
>   .reset = drm_atomic_helper_crtc_reset,
>   .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
>   .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
> + .gamma_set = drm_atomic_helper_legacy_gamma_set,
>   };
>   
>   /*
> @@ -764,6 +791,9 @@ static int ltdc_crtc_init(struct drm_device *ddev, struct 
> drm_crtc *crtc)
>   
>   drm_crtc_helper_add(crtc, _crtc_helper_funcs);
>   
> + drm_mode_crtc_set_gamma_size(crtc, CLUT_SIZE);
> + drm_crtc_enable_color_mgmt(crtc, 0, false, CLUT_SIZE);
> +
>   DRM_DEBUG_DRIVER("CRTC:%d created\n", crtc->base.id);
>   
>   /* Add planes. Note : the first layer is used by primary plane */
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [RFC 1/7] drm: Add Plane Degamma properties

[Emil Velikov]

On 7 November 2017 at 12:06, Uma Shankar  wrote:
> Add Plane Degamma as a blob property and plane
> degamma size as a range property.
>
> v2: Rebase
>
Hi Uma, seems like something has gone wrong during the rebase.

> Signed-off-by: Uma Shankar 
> ---
>  drivers/gpu/drm/drm_atomic.c|   12 
>  drivers/gpu/drm/drm_atomic_helper.c |6 ++
>  drivers/gpu/drm/drm_mode_config.c   |   14 ++
>  include/drm/drm_mode_config.h   |   11 +++
>  include/drm/drm_plane.h |   10 ++
>  5 files changed, 53 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 7e0e7be..30853c7 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -713,6 +713,8 @@ static int drm_atomic_plane_set_property(struct drm_plane 
> *plane,
>  {
> struct drm_device *dev = plane->dev;
> struct drm_mode_config *config = >mode_config;
> +   bool replaced = false;
> +   int ret;
>
> if (property == config->prop_fb_id) {
> struct drm_framebuffer *fb = drm_framebuffer_lookup(dev, 
> NULL, val);
> @@ -758,6 +760,12 @@ static int drm_atomic_plane_set_property(struct 
> drm_plane *plane,
> } else if (plane->funcs->atomic_set_property) {
> return plane->funcs->atomic_set_property(plane, state,
> property, val);
> +   } else if (property == config->plane_degamma_lut_property) {
> +   ret = drm_atomic_replace_property_blob_from_id(dev,
> +   >degamma_lut,
> +   val, -1, );
> +   state->color_mgmt_changed |= replaced;
> +   return ret;
Namely: the driver specific atomic_set_property will be called and the
newly added code will not be reached.
I think we should keep the atomic_set_property call last in the
if/else chain. Converting the lot to a switch statement might make
things a bit more obvious.


> } else {
> return -EINVAL;
> }
> @@ -816,6 +824,9 @@ static int drm_atomic_plane_set_property(struct drm_plane 
> *plane,
> *val = state->zpos;
> } else if (plane->funcs->atomic_get_property) {
> return plane->funcs->atomic_get_property(plane, state, 
> property, val);
> +   } else if (property == config->plane_degamma_lut_property) {
> +   *val = (state->degamma_lut) ?
> +   state->degamma_lut->base.id : 0;
Analogous thing happens here.

Did you test the updated series through IGT - it should have caught
the above (considering we have tests, and I'm not loosing my marbles).
Same comments apply for CTM and gamma, patches 2 and 3 respectively.

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

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

[Daniel Vetter]

On Wed, Nov 01, 2017 at 04:04:33PM +0100, Maarten Lankhorst wrote:
> 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.
> 
> Vmwgfx' and simple kms helper atomic implementation rejects CRTC
> enabled without plane, so we can do this safely.
> 
> If the atomic commit is rejected by the driver then we will still
> fall back to the old behavior and turn off the crtc.
> 
> Changes since v1:
> - Restart completely when rmfb with crtc on fails (Sean Paul).
> 
> Signed-off-by: Maarten Lankhorst 
> Cc: Sean Paul 
> Cc: Daniel Vetter 

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/drm_framebuffer.c | 23 +--
>  1 file changed, 17 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_framebuffer.c 
> b/drivers/gpu/drm/drm_framebuffer.c
> index 2affe53f3fda..f0679468f421 100644
> --- a/drivers/gpu/drm/drm_framebuffer.c
> +++ b/drivers/gpu/drm/drm_framebuffer.c
> @@ -765,14 +765,18 @@ static int atomic_remove_fb(struct drm_framebuffer *fb)
>   struct drm_plane *plane;
>   struct drm_connector *conn;
>   struct drm_connector_state *conn_state;
> - int i, ret = 0;
> + int i, ret;
>   unsigned plane_mask;
> + bool disable_crtcs = false;
>  
> - state = drm_atomic_state_alloc(dev);
> - if (!state)
> - return -ENOMEM;
> -
> +retry_disable:
>   drm_modeset_acquire_init(, 0);
> +
> + state = drm_atomic_state_alloc(dev);
> + if (!state) {
> + ret = -ENOMEM;
> + goto out;
> + }
>   state->acquire_ctx = 
>  
>  retry:
> @@ -793,7 +797,7 @@ static int atomic_remove_fb(struct drm_framebuffer *fb)
>   goto unlock;
>   }
>  
> - if (plane_state->crtc->primary == plane) {
> + 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);
> @@ -818,6 +822,7 @@ static int atomic_remove_fb(struct drm_framebuffer *fb)
>   plane->old_fb = plane->fb;
>   }
>  
> + /* This list is only filled when disable_crtcs is set. */
>   for_each_new_connector_in_state(state, conn, conn_state, i) {
>   ret = drm_atomic_set_crtc_for_connector(conn_state, NULL);
>  
> @@ -840,9 +845,15 @@ static int atomic_remove_fb(struct drm_framebuffer *fb)
>  
>   drm_atomic_state_put(state);
>  
> +out:
>   drm_modeset_drop_locks();
>   drm_modeset_acquire_fini();
>  
> + if (ret == -EINVAL && !disable_crtcs) {
> + disable_crtcs = true;
> + goto retry_disable;
> + }
> +
>   return ret;
>  }
>  
> -- 
> 2.14.1
> 

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

Re: [Intel-gfx] [PATCH] drm/selftests/mm: Insert cond_resched() between insert modes

[Joonas Lahtinen]

On Tue, 2017-11-07 at 14:51 +0200, Joonas Lahtinen wrote:
> On Tue, 2017-11-07 at 10:41 +, Chris Wilson wrote:
> > kbuilder has begun running the selftests and reported a soft-lockup
> > inside __igt_insert(), so break up the test loop over different
> > modes
> > with another call to cond_resched().
> > 
> > Reported-by: Fengguang Wu 
> > Signed-off-by: Chris Wilson 
> > Cc: Joonas Lahtinen 
> 
> Reviewed-by: Joonas Lahtinen 

Pushed to drm-misc-next, thanks for the patch.

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

[PATCH 1/2] fbdev: pxa3xx: use ktime_get_ts64 for time stamps

[Arnd Bergmann]

do_gettimeofday() is deprecated because it is not y2038 safe, so I'm
changing the calculation for the diagnostic output over to using
'timespec64'.

We really only print time deltas here, so changing it to monotonic
time makes this more robust, the correct accessor for this is
ktime_get_ts64().

Signed-off-by: Arnd Bergmann 
---
 drivers/video/fbdev/pxa3xx-gcu.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/video/fbdev/pxa3xx-gcu.c b/drivers/video/fbdev/pxa3xx-gcu.c
index 3366076f9e0f..ddca4425adc8 100644
--- a/drivers/video/fbdev/pxa3xx-gcu.c
+++ b/drivers/video/fbdev/pxa3xx-gcu.c
@@ -104,7 +104,7 @@ struct pxa3xx_gcu_priv {
wait_queue_head_t wait_idle;
wait_queue_head_t wait_free;
spinlock_tspinlock;
-   struct timevalbase_time;
+   struct timespec64 base_time;
 
struct pxa3xx_gcu_batch *free;
struct pxa3xx_gcu_batch *ready;
@@ -126,18 +126,20 @@ gc_writel(struct pxa3xx_gcu_priv *priv, unsigned int off, 
unsigned long val)
 
 #define QPRINT(priv, level, msg)   \
do {\
-   struct timeval tv;  \
+   struct timespec64 ts;   \
struct pxa3xx_gcu_shared *shared = priv->shared;\
u32 base = gc_readl(priv, REG_GCRBBR);  \
\
-   do_gettimeofday();   \
+   ktime_get_ts64();\
+   ts = timespec64_sub(ts, priv->base_time);   \
\
-   printk(level "%ld.%03ld.%03ld - %-17s: %-21s (%s, " \
+   printk(level "%lld.%03ld.%03ld - %-17s: %-21s (%s, "\
"STATUS "   \
"0x%02lx, B 0x%08lx [%ld], E %5ld, H %5ld, "\
"T %5ld)\n",\
-   tv.tv_sec - priv->base_time.tv_sec, \
-   tv.tv_usec / 1000, tv.tv_usec % 1000,   \
+   (s64)(tv.tv_sec),   \
+   tv.tv_usec / NSEC_PER_MSEC, \
+   (tv.tv_usec % NSEC_PER_MSEC) / USEC_PER_MSEC,   \
__func__, msg,  \
shared->hw_running ? "running" : "   idle", \
gc_readl(priv, REG_GCISCR), \
@@ -164,7 +166,7 @@ pxa3xx_gcu_reset(struct pxa3xx_gcu_priv *priv)
priv->shared->buffer_phys = priv->shared_phys;
priv->shared->magic = PXA3XX_GCU_SHARED_MAGIC;
 
-   do_gettimeofday(>base_time);
+   ktime_get_ts64(>base_time);
 
/* set up the ring buffer pointers */
gc_writel(priv, REG_GCRBLR, 0);
-- 
2.9.0

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

[PATCH 2/2] fbdev: radeon: stop use ktime_get() for HZ calibration

[Arnd Bergmann]

do_gettimeofday() is deprecated and a bit clumsy. This changes
radeon_probe_pll_params() over to using ktime_get() with monotonic
times. There is no need to check for negative values any more
since the monotonic clocksource cannot go backwards, but I'm
adding a check for zero-division in case of a bad clocksource.

Signed-off-by: Arnd Bergmann 
---
 drivers/video/fbdev/aty/radeon_base.c | 18 +++---
 1 file changed, 7 insertions(+), 11 deletions(-)

diff --git a/drivers/video/fbdev/aty/radeon_base.c 
b/drivers/video/fbdev/aty/radeon_base.c
index 8ad1643e7d1c..8b7048fbf6dc 100644
--- a/drivers/video/fbdev/aty/radeon_base.c
+++ b/drivers/video/fbdev/aty/radeon_base.c
@@ -583,8 +583,8 @@ static int radeon_probe_pll_params(struct radeonfb_info 
*rinfo)
int hTotal, vTotal, num, denom, m, n;
unsigned long long hz, vclk;
long xtal;
-   struct timeval start_tv, stop_tv;
-   long total_secs, total_usecs;
+   ktime_t start_time, stop_time;
+   u64 total_usecs;
int i;
 
/* Ugh, we cut interrupts, bad bad bad, but we want some precision
@@ -600,7 +600,7 @@ static int radeon_probe_pll_params(struct radeonfb_info 
*rinfo)
if (((INREG(CRTC_VLINE_CRNT_VLINE) >> 16) & 0x3ff) == 0)
break;
 
-   do_gettimeofday(_tv);
+   start_time = ktime_get();
 
for(i=0; i<100; i++)
if (((INREG(CRTC_VLINE_CRNT_VLINE) >> 16) & 0x3ff) != 0)
@@ -610,18 +610,14 @@ static int radeon_probe_pll_params(struct radeonfb_info 
*rinfo)
if (((INREG(CRTC_VLINE_CRNT_VLINE) >> 16) & 0x3ff) == 0)
break;

-   do_gettimeofday(_tv);
+   stop_time = ktime_get();

local_irq_enable();
 
-   total_secs = stop_tv.tv_sec - start_tv.tv_sec;
-   if (total_secs > 10)
+   total_usecs = ktime_us_delta(stop_time, start_time);
+   if (total_usecs >= 10 * USEC_PER_SEC || total_usecs == 0)
return -1;
-   total_usecs = stop_tv.tv_usec - start_tv.tv_usec;
-   total_usecs += total_secs * 100;
-   if (total_usecs < 0)
-   total_usecs = -total_usecs;
-   hz = 100/total_usecs;
+   hz = USEC_PER_SEC/(u32)total_usecs;
  
hTotal = ((INREG(CRTC_H_TOTAL_DISP) & 0x1ff) + 1) * 8;
vTotal = ((INREG(CRTC_V_TOTAL_DISP) & 0x3ff) + 1);
-- 
2.9.0

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

drivers/gpu/drm/bridge/lvds-encoder.c broken in mainline

[Lothar Waßmann]

Hi,

drivers/gpu/drm/bridge/lvds-encoder.c driver is currently
dysfunctional due to:
|commit 13dfc0540a575b47b2d640b093ac16e9e09474f6
|Author: Eric Anholt 
|Date:   Fri Jun 2 13:25:14 2017 -0700
|
|drm/bridge: Refactor out the panel wrapper from the lvds-encoder bridge.

Also, there is no in-kernel user of this driver, so that it obviously
doesn't get tested in any way. There is only one dts file (r8a7779-marzen.dts)
that instantiates this driver, but it has an incomplete OF graph. The missing
link for the OF graph is provided by either r8a77xx-aa104xd12-panel.dtsi or
r8a77xx-aa121td01-panel.dtsi, but those files are referenced nowhere in
the kernel source.

Should the driver be removed or moved to staging, until it is properly
fixed?


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

Re: [PATCH v1 2/2] drm/stm: ltdc: add a 2nd endpoint

[Benjamin Gaignard]

2017-10-26 13:48 GMT+02:00 Philippe Cornu :
> ltdc can have up to 2 endpoints:
>  - dpi external gpios: for rgb panels or external bridge ICs.
>  - dpi internal ios: connected internally to dsi.
>
> Note: Refer to the reference manual to know if the dsi is
> present on your device.

Applied on drm-misc-next
Thanks

Benjamin

> Signed-off-by: Philippe Cornu 
> ---
>  drivers/gpu/drm/stm/ltdc.c | 64 
> --
>  1 file changed, 45 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
> index d5c8a42..38a6739 100644
> --- a/drivers/gpu/drm/stm/ltdc.c
> +++ b/drivers/gpu/drm/stm/ltdc.c
> @@ -33,6 +33,8 @@
>
>  #define MAX_IRQ 4
>
> +#define MAX_ENDPOINTS 2
> +
>  #define HWVER_10200 0x010200
>  #define HWVER_10300 0x010300
>  #define HWVER_20101 0x020101
> @@ -886,18 +888,33 @@ int ltdc_load(struct drm_device *ddev)
> struct ltdc_device *ldev = ddev->dev_private;
> struct device *dev = ddev->dev;
> struct device_node *np = dev->of_node;
> -   struct drm_bridge *bridge;
> -   struct drm_panel *panel;
> +   struct drm_bridge *bridge[MAX_ENDPOINTS] = {NULL};
> +   struct drm_panel *panel[MAX_ENDPOINTS] = {NULL};
> struct drm_crtc *crtc;
> struct reset_control *rstc;
> struct resource *res;
> -   int irq, ret, i;
> +   int irq, ret, i, endpoint_not_ready = -ENODEV;
>
> DRM_DEBUG_DRIVER("\n");
>
> -   ret = drm_of_find_panel_or_bridge(np, 0, 0, , );
> -   if (ret)
> -   return ret;
> +   /* Get endpoints if any */
> +   for (i = 0; i < MAX_ENDPOINTS; i++) {
> +   ret = drm_of_find_panel_or_bridge(np, 0, i, [i],
> + [i]);
> +
> +   /*
> +* If at least one endpoint is ready, continue probing,
> +* else if at least one endpoint is -EPROBE_DEFER and
> +* there is no previous ready endpoints, defer probing.
> +*/
> +   if (!ret)
> +   endpoint_not_ready = 0;
> +   else if (ret == -EPROBE_DEFER && endpoint_not_ready)
> +   endpoint_not_ready = -EPROBE_DEFER;
> +   }
> +
> +   if (endpoint_not_ready)
> +   return endpoint_not_ready;
>
> rstc = devm_reset_control_get_exclusive(dev, NULL);
>
> @@ -958,19 +975,25 @@ int ltdc_load(struct drm_device *ddev)
>
> DRM_INFO("ltdc hw version 0x%08x - ready\n", ldev->caps.hw_version);
>
> -   if (panel) {
> -   bridge = drm_panel_bridge_add(panel, DRM_MODE_CONNECTOR_DPI);
> -   if (IS_ERR(bridge)) {
> -   DRM_ERROR("Failed to create panel-bridge\n");
> -   ret = PTR_ERR(bridge);
> -   goto err;
> +   /* Add endpoints panels or bridges if any */
> +   for (i = 0; i < MAX_ENDPOINTS; i++) {
> +   if (panel[i]) {
> +   bridge[i] = drm_panel_bridge_add(panel[i],
> +   
> DRM_MODE_CONNECTOR_DPI);
> +   if (IS_ERR(bridge[i])) {
> +   DRM_ERROR("panel-bridge endpoint %d\n", i);
> +   ret = PTR_ERR(bridge[i]);
> +   goto err;
> +   }
> }
> -   }
>
> -   ret = ltdc_encoder_init(ddev, bridge);
> -   if (ret) {
> -   DRM_ERROR("Failed to init encoder\n");
> -   goto err;
> +   if (bridge[i]) {
> +   ret = ltdc_encoder_init(ddev, bridge[i]);
> +   if (ret) {
> +   DRM_ERROR("init encoder endpoint %d\n", i);
> +   goto err;
> +   }
> +   }
> }
>
> crtc = devm_kzalloc(dev, sizeof(*crtc), GFP_KERNEL);
> @@ -998,7 +1021,8 @@ int ltdc_load(struct drm_device *ddev)
> return 0;
>
>  err:
> -   drm_panel_bridge_remove(bridge);
> +   for (i = 0; i < MAX_ENDPOINTS; i++)
> +   drm_panel_bridge_remove(bridge[i]);
>
> clk_disable_unprepare(ldev->pixel_clk);
>
> @@ -1008,10 +1032,12 @@ int ltdc_load(struct drm_device *ddev)
>  void ltdc_unload(struct drm_device *ddev)
>  {
> struct ltdc_device *ldev = ddev->dev_private;
> +   int i;
>
> DRM_DEBUG_DRIVER("\n");
>
> -   drm_of_panel_bridge_remove(ddev->dev->of_node, 0, 0);
> +   for (i = 0; i < MAX_ENDPOINTS; i++)
> +   drm_of_panel_bridge_remove(ddev->dev->of_node, 0, i);
>
> clk_disable_unprepare(ldev->pixel_clk);
>  }
> --
> 1.9.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v1 1/2] dt-bindings: display: stm32: add a 2nd endpoint

[Benjamin Gaignard]

2017-10-27 16:38 GMT+02:00 Rob Herring :
> On Thu, Oct 26, 2017 at 01:48:08PM +0200, Philippe Cornu wrote:
>> ltdc can have up to 2 endpoints:
>>  - dpi external gpios: for rgb panels or external bridge ICs.
>>  - dpi internal ios: connected internally to dsi.
>>
>> Note: Refer to the reference manual to know if the dsi is
>> present on your device.
>>
>> Signed-off-by: Philippe Cornu 
>> ---
>>  Documentation/devicetree/bindings/display/st,stm32-ltdc.txt | 6 +-
>>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> Acked-by: Rob Herring 
>

Applied on drm-misc-next
Thanks

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

Re: [PATCH] drm/stm: checkpatch strict minor updates

[Benjamin Gaignard]

2017-11-01 12:33 GMT+01:00 Gustavo Padovan :
> 2017-10-26 Philippe Cornu :
>
>> Minor fixes detected with "scripts/checkpatch.pl --strict"
>>
>> Signed-off-by: Philippe Cornu 
>> ---
>>  drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 4 ++--
>>  drivers/gpu/drm/stm/ltdc.c| 2 +-
>>  2 files changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c 
>> b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
>> index 10b2b77..3e8b9ed 100644
>> --- a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
>> +++ b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
>> @@ -129,7 +129,7 @@ static int dsi_pll_get_params(int clkin_khz, int 
>> clkout_khz,
>>   int fvco_min, fvco_max, delta, best_delta; /* all in khz */
>>
>>   /* Early checks preventing division by 0 & odd results */
>> - if ((clkin_khz <= 0) || (clkout_khz <= 0))
>> + if (clkin_khz <= 0 || clkout_khz <= 0)
>>   return -EINVAL;
>>
>>   fvco_min = LANE_MIN_KBPS * 2 * ODF_MAX;
>> @@ -155,7 +155,7 @@ static int dsi_pll_get_params(int clkin_khz, int 
>> clkout_khz,
>>   for (o = ODF_MIN; o <= ODF_MAX; o *= 2) {
>>   n = DIV_ROUND_CLOSEST(i * o * clkout_khz, clkin_khz);
>>   /* Check ndiv according to vco range */
>> - if ((n < n_min) || (n > n_max))
>> + if (n < n_min || n > n_max)
>>   continue;
>>   /* Check if new delta is better & saves parameters */
>>   delta = dsi_pll_get_clkout_khz(clkin_khz, i, n, o) -
>> diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
>> index 735c908..7be6710 100644
>> --- a/drivers/gpu/drm/stm/ltdc.c
>> +++ b/drivers/gpu/drm/stm/ltdc.c
>> @@ -556,7 +556,7 @@ static int ltdc_plane_atomic_check(struct drm_plane 
>> *plane,
>>   src_h = state->src_h >> 16;
>>
>>   /* Reject scaling */
>> - if ((src_w != state->crtc_w) || (src_h != state->crtc_h)) {
>> + if (src_w != state->crtc_w || src_h != state->crtc_h) {
>>   DRM_ERROR("Scaling is not supported");
>>   return -EINVAL;
>
> Reviewed-by: Gustavo Padovan 
>

Applied on drm-misc-next.
Thanks

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

Re: [PATCH] drm/stm: dsi: Rename driver name

[Benjamin Gaignard]

2017-11-01 12:31 GMT+01:00 Gustavo Padovan :
> Hi Philippe,
>
> 2017-10-26 Philippe Cornu :
>
>> Rename the driver name from "dw_mipi_dsi-stm" to
>> "stm32-display-dsi" for a better readability
>> in /sys/bus/platform/drivers entries.
>>
>> Signed-off-by: Philippe Cornu 
>> ---
>>  drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c 
>> b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
>> index e5b6310..10b2b77 100644
>> --- a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
>> +++ b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
>> @@ -342,7 +342,7 @@ static int dw_mipi_dsi_stm_remove(struct platform_device 
>> *pdev)
>>   .remove = dw_mipi_dsi_stm_remove,
>>   .driver = {
>>   .of_match_table = dw_mipi_dsi_stm_dt_ids,
>> - .name   = "dw_mipi_dsi-stm",
>> + .name   = "stm32-display-dsi",
>
> Reviewed-by: Gustavo Padovan 
>
> Gustavo

Applied on drm-misc-next.
Thanks

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

[PULL] drm-misc-next-fixes

[Daniel Vetter]

Hi Dave,

drm-misc-next-fixes-2017-11-07:
Fixes for 4.15 merge window:

Just the cherry-picked vc4 fix plus a GFP_NOFAIL annotation (there's
apparently some new options in-flight to change/audit
too-small-to-fail kmalloc semantics or something like that).

Cheers, Daniel

The following changes since commit 62884cd386b876638720ef88374b31a84ca7ee5f:

  drm: Add four ioctls for managing drm mode object leases [v7] (2017-10-25 
16:31:30 +1000)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-fixes-2017-11-07

for you to fetch changes up to e073db5c5d7ad311efa8f4192a2047b006bbc5f3:

  drm/vc4: Fix wrong printk format in vc4_bo_stats_debugfs() (2017-11-03 
10:15:42 -0700)


Fixes for 4.15 merge window:

Just the cherry-picked vc4 fix plus a GFP_NOFAIL annotation (there's
apparently some new options in-flight to change/audit
too-small-to-fail kmalloc semantics or something like that).


Boris Brezillon (1):
  drm/vc4: Fix wrong printk format in vc4_bo_stats_debugfs()

Chris Wilson (1):
  drm: Require __GFP_NOFAIL for the legacy drm_modeset_lock_all

 drivers/gpu/drm/drm_modeset_lock.c | 2 +-
 drivers/gpu/drm/vc4/vc4_bo.c   | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

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

[PATCH] drm/ttm: set bo->resv point to tbo->ttm_resv after individualize_resv

[Christian König]

Set bo->resv to ttm_resv during BO cleanup. This way freed BOs can be
better reaped during eviction.

Signed-off-by: Roger He 
Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_bo.c | 23 ---
 1 file changed, 8 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index c088703777e2..cc33eb2174f6 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -444,18 +444,19 @@ static void ttm_bo_cleanup_refs_or_queue(struct 
ttm_buffer_object *bo)
reservation_object_wait_timeout_rcu(bo->resv, true, false,
30 * HZ);
spin_lock(>lru_lock);
+   bo->resv = >ttm_resv;
goto error;
}
 
spin_lock(>lru_lock);
-   ret = __ttm_bo_reserve(bo, false, true, NULL);
+   if (bo->resv != >ttm_resv)
+   bo->resv = >ttm_resv;
+   else
+   ret = __ttm_bo_reserve(bo, false, true, NULL);
if (!ret) {
-   if (reservation_object_test_signaled_rcu(>ttm_resv, true)) {
+   if (reservation_object_test_signaled_rcu(bo->resv, true)) {
ttm_bo_del_from_lru(bo);
spin_unlock(>lru_lock);
-   if (bo->resv != >ttm_resv)
-   reservation_object_unlock(>ttm_resv);
-
ttm_bo_cleanup_memtype_use(bo);
return;
}
@@ -474,8 +475,6 @@ static void ttm_bo_cleanup_refs_or_queue(struct 
ttm_buffer_object *bo)
 
__ttm_bo_unreserve(bo);
}
-   if (bo->resv != >ttm_resv)
-   reservation_object_unlock(>ttm_resv);
 
 error:
kref_get(>list_kref);
@@ -503,15 +502,9 @@ static int ttm_bo_cleanup_refs_and_unlock(struct 
ttm_buffer_object *bo,
  bool no_wait_gpu)
 {
struct ttm_bo_global *glob = bo->glob;
-   struct reservation_object *resv;
int ret;
 
-   if (unlikely(list_empty(>ddestroy)))
-   resv = bo->resv;
-   else
-   resv = >ttm_resv;
-
-   if (reservation_object_test_signaled_rcu(resv, true))
+   if (reservation_object_test_signaled_rcu(bo->resv, true))
ret = 0;
else
ret = -EBUSY;
@@ -521,7 +514,7 @@ static int ttm_bo_cleanup_refs_and_unlock(struct 
ttm_buffer_object *bo,
ww_mutex_unlock(>resv->lock);
spin_unlock(>lru_lock);
 
-   lret = reservation_object_wait_timeout_rcu(resv, true,
+   lret = reservation_object_wait_timeout_rcu(bo->resv, true,
   interruptible,
   30 * HZ);
 
-- 
2.11.0

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

Re: [PATCH] drm/selftests/mm: Insert cond_resched() between insert modes

[Joonas Lahtinen]

On Tue, 2017-11-07 at 10:41 +, Chris Wilson wrote:
> kbuilder has begun running the selftests and reported a soft-lockup
> inside __igt_insert(), so break up the test loop over different modes
> with another call to cond_resched().
> 
> Reported-by: Fengguang Wu 
> Signed-off-by: Chris Wilson 
> Cc: Joonas Lahtinen 

Reviewed-by: Joonas Lahtinen 

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

Re: [RFC PATCH] drm/vblanks: Deal with HW vblank counter resets.

[Daniel Vetter]

On Tue, Nov 07, 2017 at 10:47:00AM +0100, Michel Dänzer wrote:
> On 07/11/17 07:26 AM, Dhinakaran Pandiyan wrote:
> > Some HW vblank counters reset due to power management events, which messes
> > up the vblank counting logic. This leads to screen freezes with user space
> > waiting on vblank events that may not occur if the counter keeps resetting.
> > 
> > For e.g., After the HW vblank counter resets
> > [9.007359] [drm:drm_update_vblank_count [drm]] updating vblank count
> > on crtc 0: current=297, diff=4294965389, hw=5 hw_last=1912
> > 
> > So, fall back to the SW counter, computed using  vblank timestamps
> > and frame duration, when the HW counter value deviates by 50% of the SW
> > computed value.
> > 
> > I have tested this patch on my SKL laptop with i915.enable_psr=1 and it
> > *seems* to solve the screen freeze issue seen with PSR when DMC is loaded.
> > 
> > Known issues:
> > 1) The 50% deviation margin is arbitrary.
> > 2) "Redundant vblirq ignored" messages are more frequent.
> > 
> > I am sending this as an RFC to get feedback on whether the fall back
> > approach is sane and if it should be implemented in the core.
> 
> Is there no way for the driver to know under which circumstances the
> reset to 0 might happen? If there is, maybe it could be solved by
> calling drm_crtc_vblank_off() before it might happen and
> drm_crtc_vblank_on() after it might have happened.
> 
> Otherwise, might it be better not to use the HW counter at all when it's
> known not to be reliable?

We know when it happens, so agreed this isn't a good/workable solution
really. I thought the plan to fix that was to fix up our runtime pm to
make sure the vblank counter doesn't get reset while we need it (pending
flip or vblank). And in-between (when the vblank counter is totally off)
we'd fix any mismatch by adjusting the sw vblank counter with an explicit
call (where we can use the elapsed time to estimate the elapsed vblank
counts well enough). Adding a magic hack like this doesn't sound like a
good plan to me indeed.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 3/5] drm/vmwgfx: Try to fix plane clipping

[Daniel Vetter]

On Mon, Nov 06, 2017 at 08:04:38PM +0200, Ville Syrjälä wrote:
> On Thu, Nov 02, 2017 at 03:19:30PM +0200, Ville Syrjälä wrote:
> > On Thu, Nov 02, 2017 at 11:12:09AM +0100, Daniel Vetter wrote:
> > > On Wed, Nov 01, 2017 at 08:29:18PM +0200, Ville Syrjala wrote:
> > > > From: Ville Syrjälä 
> > > > 
> > > > Try to fix the code to actually clip the plane to the crtc bounds
> > > > instead of the user provided crtc coordinates (which would be a no-op
> > > > since those are exactly the coordinates before clipping).
> > > > 
> > > > Cc: VMware Graphics 
> > > > Cc: Sinclair Yeh 
> > > > Cc: Thomas Hellstrom 
> > > > Signed-off-by: Ville Syrjälä 
> > > 
> > > I kinda wonder whether we shouldn't push this down into the helper ...
> > 
> > Would require quite going through all drivers making sure they are
> > happy with using the adjusted_mode.crtc_ timings. I think most drivers
> > use the other adjusted_mode timings currently, and some even use the
> > user mode timings (which could be an actual bug).
> 
> Let me take that back. What we want is to clip to the user mode
> timings. Stereo 3D needs the special treatment from
> drm_mode_get_hv_timing(). I'm getting confused by all these
> different timings we have all over the place.
> 
> I think for i915 all we would need is to change the double wide/dual
> link adjustent for pipe_src_w to simply reject odd widths instead.
> That would guarantee that the user mode timings match the pipe_src_w/h
> 100%.
> 
> For the other driver we'd need to figure out why they're using
> adjusted_mode timings for clipping. I guess that's just a mistake,
> which I repeated here with vmwgfx after getting confused by looking
> at the other drivers.
> 
> I guess I just volunteered myself to do this. Just needs plenty of
> acks from driver maintainers I suppose.

Yeah consistently using drm_mode_get_hv_timing from
crtc_state->requested_mode seems like the right thing to do. Otherwise
there's a driver bug lurking somewhere ...
-Daniel

> 
> > 
> > > 
> > > Either way, Reviewed-by: Daniel Vetter 
> > > 
> > > > ---
> > > >  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 23 +--
> > > >  1 file changed, 13 insertions(+), 10 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
> > > > b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> > > > index 515b67783a41..efa41c086198 100644
> > > > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> > > > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> > > > @@ -441,20 +441,23 @@ vmw_du_cursor_plane_atomic_update(struct 
> > > > drm_plane *plane,
> > > >  int vmw_du_primary_plane_atomic_check(struct drm_plane *plane,
> > > >   struct drm_plane_state *state)
> > > >  {
> > > > +   struct drm_crtc_state *crtc_state = NULL;
> > > > struct drm_framebuffer *new_fb = state->fb;
> > > > -   struct drm_rect clip = {
> > > > -   .x1 = state->crtc_x,
> > > > -   .y1 = state->crtc_y,
> > > > -   .x2 = state->crtc_x + state->crtc_w,
> > > > -   .y2 = state->crtc_y + state->crtc_h,
> > > > -   };
> > > > +   struct drm_rect clip = {};
> > > > int ret;
> > > >  
> > > > -   ret = drm_plane_helper_check_state(state, ,
> > > > -   DRM_PLANE_HELPER_NO_SCALING,
> > > > -   DRM_PLANE_HELPER_NO_SCALING,
> > > > -   false, true);
> > > > +   if (state->crtc)
> > > > +   crtc_state = 
> > > > drm_atomic_get_new_crtc_state(state->state, state->crtc);
> > > >  
> > > > +   if (crtc_state && crtc_state->enable) {
> > > > +   clip.x2 = crtc_state->adjusted_mode.hdisplay;
> > > > +   clip.y2 = crtc_state->adjusted_mode.vdisplay;
> > > > +   }
> > > > +
> > > > +   ret = drm_plane_helper_check_state(state, ,
> > > > +  DRM_PLANE_HELPER_NO_SCALING,
> > > > +  DRM_PLANE_HELPER_NO_SCALING,
> > > > +  false, true);
> > > >  
> > > > if (!ret && new_fb) {
> > > > struct drm_crtc *crtc = state->crtc;
> > > > -- 
> > > > 2.13.6
> > > > 
> > > > ___
> > > > dri-devel mailing list
> > > > dri-devel@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > > 
> > > -- 
> > > Daniel Vetter
> > > Software Engineer, Intel Corporation
> > > http://blog.ffwll.ch
> > 
> > -- 
> > Ville Syrjälä
> > Intel OTC
> > ___
> > Intel-gfx mailing list
> > intel-...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> Ville Syrjälä
> Intel 

Re: [PATCH 1/3] ASoC: amd: Report accurate hw_ptr during dma

[Mark Brown]

On Tue, Nov 07, 2017 at 07:26:03PM +0530, Mukunda,Vijendar wrote:
> Removing URL links and commit-ready description in v2.

This doesn't really answer my question:

> > These two URLs are different, what was being reviewed here?  What is
> > Commit-Ready supposed to mean?

Please don't top post, reply in line with needed context.  This allows
readers to readily follow the flow of conversation and understand what
you are talking about and also helps ensure that everything in the
discussion is being addressed.


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

[RFC 7/7] drm/i915: Load plane color luts from atomic flip

[Uma Shankar]

Load plane color luts as part of atomic plane updates.
This will be done only if the plane color luts are changed.

Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/i915/intel_atomic_plane.c |4 
 drivers/gpu/drm/i915/intel_color.c|8 
 drivers/gpu/drm/i915/intel_drv.h  |1 +
 3 files changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c 
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index 8e6dc15..52d71db 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -239,6 +239,10 @@ static void intel_plane_atomic_update(struct drm_plane 
*plane,
intel_atomic_get_new_plane_state(state, intel_plane);
struct drm_crtc *crtc = new_plane_state->base.crtc ?: old_state->crtc;
 
+   if (new_plane_state->base.color_mgmt_changed) {
+   intel_color_load_plane_luts(_plane_state->base);
+   }
+
if (new_plane_state->base.visible) {
const struct intel_crtc_state *new_crtc_state =
intel_atomic_get_new_crtc_state(state, 
to_intel_crtc(crtc));
diff --git a/drivers/gpu/drm/i915/intel_color.c 
b/drivers/gpu/drm/i915/intel_color.c
index 3452769..34e70ba 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -663,6 +663,14 @@ void intel_color_load_luts(struct drm_crtc_state 
*crtc_state)
dev_priv->display.load_luts(crtc_state);
 }
 
+void intel_color_load_plane_luts(const struct drm_plane_state *plane_state)
+{
+   struct drm_device *dev = plane_state->plane->dev;
+   struct drm_i915_private *dev_priv = to_i915(dev);
+
+   dev_priv->display.load_plane_luts(plane_state);
+}
+
 int intel_color_check(struct drm_crtc *crtc,
  struct drm_crtc_state *crtc_state)
 {
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index eb90d11..67487d4 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -2027,6 +2027,7 @@ int intel_plane_atomic_check_with_state(const struct 
intel_crtc_state *old_crtc_
 void intel_color_set_csc(struct drm_crtc_state *crtc_state);
 void intel_color_load_luts(struct drm_crtc_state *crtc_state);
 void intel_plane_color_init(struct drm_plane *plane);
+void intel_color_load_plane_luts(const struct drm_plane_state *plane_state);
 
 /* intel_lspcon.c */
 bool lspcon_init(struct intel_digital_port *intel_dig_port);
-- 
1.7.9.5

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

[RFC 6/7] drm/i915: Implement Plane Gamma for Bdw and Gen9 platforms

[Uma Shankar]

Implement Plane Gamma feature for BDW and Gen9 platforms.

Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/i915/i915_pci.c  |5 ++-
 drivers/gpu/drm/i915/i915_reg.h  |   24 ++
 drivers/gpu/drm/i915/intel_color.c   |   58 ++
 drivers/gpu/drm/i915/intel_display.c |4 +++
 drivers/gpu/drm/i915/intel_sprite.c  |4 +++
 5 files changed, 94 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 6458c30..6655eaf 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -51,7 +51,10 @@
.cursor_offsets = { CURSOR_A_OFFSET, IVB_CURSOR_B_OFFSET, 
IVB_CURSOR_C_OFFSET }
 
 #define BDW_COLORS \
-   .color = { .degamma_lut_size = 512, .gamma_lut_size = 512 }
+   .color = { .degamma_lut_size = 512, .gamma_lut_size = 512 }, \
+   .plane_color = { .plane_degamma_lut_size = 0, \
+.plane_gamma_lut_size = 16 }
+
 #define CHV_COLORS \
.color = { .degamma_lut_size = 65, .gamma_lut_size = 257 }
 #define GLK_COLORS \
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index f0f8f60..b71082b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -159,6 +159,9 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
 #define _PHY3(phy, ...) _PICK(phy, __VA_ARGS__)
 #define _MMIO_PHY3(phy, a, b, c) _MMIO(_PHY3(phy, a, b, c))
 
+#define _MMIO_PLANE_GAMC(plane, i, a, b)  _MMIO(_PIPE(plane, a, b) + (i) * 4)
+#define _MMIO_PLANE_GAMC16(plane, i, a, b)  _MMIO(_PIPE(plane, a, b) + (i) * 4)
+
 #define _MASKED_FIELD(mask, value) ({ \
if (__builtin_constant_p(mask))\
BUILD_BUG_ON_MSG(((mask) & 0x), "Incorrect mask"); \
@@ -8800,6 +8803,27 @@ enum skl_power_gate {
 #define PRE_CSC_GAMC_INDEX(pipe)   _MMIO_PIPE(pipe, _PRE_CSC_GAMC_INDEX_A, 
_PRE_CSC_GAMC_INDEX_B)
 #define PRE_CSC_GAMC_DATA(pipe)_MMIO_PIPE(pipe, 
_PRE_CSC_GAMC_DATA_A, _PRE_CSC_GAMC_DATA_B)
 
+/* Plane Gamma in Gen9+ */
+#define _PLANE_GAMC_1_A0x701d0
+#define _PLANE_GAMC_1_B0x711d0
+#define _PLANE_GAMC_2_A0x702d0
+#define _PLANE_GAMC_2_B0x712d0
+#define _PLANE_GAMC_1(pipe)_PIPE(pipe, _PLANE_GAMC_1_A, _PLANE_GAMC_1_B)
+#define _PLANE_GAMC_2(pipe)_PIPE(pipe, _PLANE_GAMC_2_A, _PLANE_GAMC_2_B)
+#define PLANE_GAMC(pipe, plane, i) \
+   _MMIO_PLANE_GAMC(plane, i, _PLANE_GAMC_1(pipe), _PLANE_GAMC_2(pipe))
+
+#define _PLANE_GAMC16_1_A  0x70210
+#define _PLANE_GAMC16_1_B  0x71210
+#define _PLANE_GAMC16_2_A  0x70310
+#define _PLANE_GAMC16_2_B  0x71310
+#define _PLANE_GAMC16_1(pipe)  _PIPE(pipe, _PLANE_GAMC16_1_A, \
+_PLANE_GAMC16_1_B)
+#define _PLANE_GAMC16_2(pipe)  _PIPE(pipe, _PLANE_GAMC16_2_A, \
+_PLANE_GAMC16_2_B)
+#define PLANE_GAMC16(pipe, plane, i) _MMIO_PLANE_GAMC16(plane, i, \
+   _PLANE_GAMC16_1(pipe), _PLANE_GAMC16_2(pipe))
+
 /* pipe CSC & degamma/gamma LUTs on CHV */
 #define _CGM_PIPE_A_CSC_COEFF01(VLV_DISPLAY_BASE + 0x67900)
 #define _CGM_PIPE_A_CSC_COEFF23(VLV_DISPLAY_BASE + 0x67904)
diff --git a/drivers/gpu/drm/i915/intel_color.c 
b/drivers/gpu/drm/i915/intel_color.c
index f2481f1..3452769 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -489,6 +489,59 @@ static void broadwell_load_luts(struct drm_crtc_state 
*state)
I915_WRITE(PREC_PAL_INDEX(pipe), 0);
 }
 
+static void bdw_load_plane_gamma_lut(const struct drm_plane_state *state,
+u32 offset)
+{
+   struct drm_i915_private *dev_priv = to_i915(state->plane->dev);
+   enum pipe pipe = to_intel_plane(state->plane)->pipe;
+   enum plane_id plane = to_intel_plane(state->plane)->id;
+   uint32_t i, lut_size =
+   INTEL_INFO(dev_priv)->plane_color.plane_gamma_lut_size;
+
+   if (state->gamma_lut) {
+   struct drm_color_lut *lut =
+   (struct drm_color_lut *) state->gamma_lut->data;
+
+   for (i = 0; i < lut_size; i++) {
+   uint32_t word =
+   (drm_color_lut_extract(lut[i].red, 10) << 20) |
+   (drm_color_lut_extract(lut[i].green, 10) << 10) |
+   drm_color_lut_extract(lut[i].blue, 10);
+
+   I915_WRITE(PLANE_GAMC(pipe, plane, i), word);
+   }
+
+   /* Program the max register to clamp values > 1.0. */
+   i = lut_size - 1;
+   I915_WRITE(PLANE_GAMC16(pipe, plane, 0),
+  drm_color_lut_extract(lut[i].red, 16));
+   I915_WRITE(PLANE_GAMC16(pipe, plane, 1),
+  

[RFC 5/7] drm/i915: Enable plane color features

[Uma Shankar]

Enable and initialize plane color features.

v2: Rebase and some cleanup

Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/i915/i915_drv.h|   10 ++
 drivers/gpu/drm/i915/intel_color.c |   12 
 drivers/gpu/drm/i915/intel_drv.h   |9 +
 3 files changed, 31 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index fe93115..6c91b5f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -744,6 +744,11 @@ struct drm_i915_display_funcs {
 
void (*load_csc_matrix)(struct drm_crtc_state *crtc_state);
void (*load_luts)(struct drm_crtc_state *crtc_state);
+   /* Add Plane Color callbacks */
+   void (*load_plane_csc_matrix)(const struct drm_plane_state
+ *plane_state);
+   void (*load_plane_luts)(const struct drm_plane_state
+   *plane_state);
 };
 
 #define CSR_VERSION(major, minor)  ((major) << 16 | (minor))
@@ -890,6 +895,11 @@ struct intel_device_info {
u16 degamma_lut_size;
u16 gamma_lut_size;
} color;
+
+   struct plane_color_luts {
+   u16 plane_degamma_lut_size;
+   u16 plane_gamma_lut_size;
+   } plane_color;
 };
 
 struct intel_display_error_state;
diff --git a/drivers/gpu/drm/i915/intel_color.c 
b/drivers/gpu/drm/i915/intel_color.c
index b8315bc..f2481f1 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -641,6 +641,18 @@ int intel_color_check(struct drm_crtc *crtc,
return -EINVAL;
 }
 
+void intel_plane_color_init(struct drm_plane *plane)
+{
+   struct drm_i915_private *dev_priv = to_i915(plane->dev);
+
+   /* Enable color management support when we have degamma & gamma LUTs. */
+   if (INTEL_INFO(dev_priv)->plane_color.plane_degamma_lut_size != 0 &&
+   INTEL_INFO(dev_priv)->plane_color.plane_gamma_lut_size != 0)
+   drm_plane_enable_color_mgmt(plane,
+   INTEL_INFO(dev_priv)->plane_color.plane_degamma_lut_size,
+   true, INTEL_INFO(dev_priv)->plane_color.plane_gamma_lut_size);
+}
+
 void intel_color_init(struct drm_crtc *crtc)
 {
struct drm_i915_private *dev_priv = to_i915(crtc->dev);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 00b4886..eb90d11 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -445,6 +445,14 @@ struct intel_plane_state {
 */
int scaler_id;
 
+   /*
+* Use reduced/limited/broadcast rbg range, compressing from the full
+* range fed into the crtcs.
+*/
+   bool limited_color_range;
+   /* Gamma mode programmed on the plane */
+   uint32_t gamma_mode;
+
struct drm_intel_sprite_colorkey ckey;
 };
 
@@ -2018,6 +2026,7 @@ int intel_plane_atomic_check_with_state(const struct 
intel_crtc_state *old_crtc_
 int intel_color_check(struct drm_crtc *crtc, struct drm_crtc_state *state);
 void intel_color_set_csc(struct drm_crtc_state *crtc_state);
 void intel_color_load_luts(struct drm_crtc_state *crtc_state);
+void intel_plane_color_init(struct drm_plane *plane);
 
 /* intel_lspcon.c */
 bool lspcon_init(struct intel_digital_port *intel_dig_port);
-- 
1.7.9.5

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

[RFC 3/7] drm: Add Plane Gamma properties

[Uma Shankar]

Add plane gamma as blob property and size as a
range property.

v2: Rebase

Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/drm_atomic.c|8 
 drivers/gpu/drm/drm_atomic_helper.c |3 +++
 drivers/gpu/drm/drm_mode_config.c   |   14 ++
 include/drm/drm_mode_config.h   |   11 +++
 include/drm/drm_plane.h |9 +
 5 files changed, 45 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 45aede5..41946d2 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -774,6 +774,12 @@ static int drm_atomic_plane_set_property(struct drm_plane 
*plane,
);
state->color_mgmt_changed |= replaced;
return ret;
+   } else if (property == config->plane_gamma_lut_property) {
+   ret = drm_atomic_replace_property_blob_from_id(dev,
+   >gamma_lut,
+   val, -1, );
+   state->color_mgmt_changed |= replaced;
+   return ret;
} else {
return -EINVAL;
}
@@ -837,6 +843,8 @@ static int drm_atomic_plane_set_property(struct drm_plane 
*plane,
state->degamma_lut->base.id : 0;
} else if (property == config->plane_ctm_property) {
*val = (state->ctm) ? state->ctm->base.id : 0;
+   } else if (property == config->plane_gamma_lut_property) {
+   *val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
} else {
return -EINVAL;
}
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index d3154e0..1d2566d 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3400,6 +3400,8 @@ void __drm_atomic_helper_plane_duplicate_state(struct 
drm_plane *plane,
drm_property_blob_get(state->degamma_lut);
if (state->ctm)
drm_property_blob_get(state->ctm);
+   if (state->gamma_lut)
+   drm_property_blob_get(state->gamma_lut);
state->color_mgmt_changed = false;
 }
 EXPORT_SYMBOL(__drm_atomic_helper_plane_duplicate_state);
@@ -3448,6 +3450,7 @@ void __drm_atomic_helper_plane_destroy_state(struct 
drm_plane_state *state)
 
drm_property_blob_put(state->degamma_lut);
drm_property_blob_put(state->ctm);
+   drm_property_blob_put(state->gamma_lut);
 }
 EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);
 
diff --git a/drivers/gpu/drm/drm_mode_config.c 
b/drivers/gpu/drm/drm_mode_config.c
index bccc70e..94c4420 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -369,6 +369,20 @@ static int drm_mode_create_standard_properties(struct 
drm_device *dev)
return -ENOMEM;
dev->mode_config.plane_ctm_property = prop;
 
+   prop = drm_property_create(dev,
+   DRM_MODE_PROP_BLOB,
+   "PLANE_GAMMA_LUT", 0);
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.plane_gamma_lut_property = prop;
+
+   prop = drm_property_create_range(dev,
+   DRM_MODE_PROP_IMMUTABLE,
+   "PLANE_GAMMA_LUT_SIZE", 0, UINT_MAX);
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.plane_gamma_lut_size_property = prop;
+
return 0;
 }
 
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 3bf7fc6..e55aaed 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -733,6 +733,17 @@ struct drm_mode_config {
 * degamma LUT.
 */
struct drm_property *plane_ctm_property;
+   /**
+* @plane_gamma_lut_property: Optional Plane property to set the LUT
+* used to convert the colors, after the CTM matrix, to the common
+* gamma space chosen for blending.
+*/
+   struct drm_property *plane_gamma_lut_property;
+   /**
+* @plane_gamma_lut_size_property: Optional Plane property for the size
+* of the gamma LUT as supported by the driver (read-only).
+*/
+   struct drm_property *plane_gamma_lut_size_property;
 
/**
 * @suggested_x_property: Optional connector property with a hint for
diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
index 7fcc51e..01d9ea7 100644
--- a/include/drm/drm_plane.h
+++ b/include/drm/drm_plane.h
@@ -140,6 +140,15 @@ struct drm_plane_state {
struct drm_property_blob *ctm;
 
/**
+* @gamma_lut:
+*
+* Lookup table for converting pixel data after the color conversion
+* matrix @ctm.  See drm_plane_enable_color_mgmt(). The blob (if not
+* NULL) is an array of  drm_color_lut.
+*/
+   struct drm_property_blob *gamma_lut;
+
+   /**
 * 

[RFC 4/7] drm: Define helper function for plane color enabling

[Uma Shankar]

Define helper function to enable Plane color features
to attach plane color properties to plane structure.

v2: Rebase

Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/drm_plane.c  |   45 ++
 include/drm/drm_color_mgmt.h |5 +
 2 files changed, 50 insertions(+)

diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 19404e3..e9f2dab 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -144,6 +144,51 @@ static int create_in_format_blob(struct drm_device *dev, 
struct drm_plane *plane
 }
 
 /**
+ * drm_plane_enable_color_mgmt - enable color management properties
+ * @plane: DRM Plane
+ * @plane_degamma_lut_size: the size of the degamma lut (before CSC)
+ * @plane_has_ctm: whether to attach ctm_property for CSC matrix
+ * @plane_gamma_lut_size: the size of the gamma lut (after CSC)
+ *
+ * This function lets the driver enable the color correction
+ * properties on a plane. This includes 3 degamma, csc and gamma
+ * properties that userspace can set and 2 size properties to inform
+ * the userspace of the lut sizes. Each of the properties are
+ * optional. The gamma and degamma properties are only attached if
+ * their size is not 0 and ctm_property is only attached if has_ctm is
+ * true.
+ */
+void drm_plane_enable_color_mgmt(struct drm_plane *plane,
+   uint plane_degamma_lut_size,
+   bool plane_has_ctm,
+   uint plane_gamma_lut_size)
+{
+   struct drm_device *dev = plane->dev;
+   struct drm_mode_config *config = >mode_config;
+
+   if (plane_degamma_lut_size) {
+   drm_object_attach_property(>base,
+   config->plane_degamma_lut_property, 0);
+   drm_object_attach_property(>base,
+   config->plane_degamma_lut_size_property,
+   plane_degamma_lut_size);
+   }
+
+   if (plane_has_ctm)
+   drm_object_attach_property(>base,
+   config->plane_ctm_property, 0);
+
+   if (plane_gamma_lut_size) {
+   drm_object_attach_property(>base,
+   config->plane_gamma_lut_property, 0);
+   drm_object_attach_property(>base,
+   config->plane_gamma_lut_size_property,
+   plane_gamma_lut_size);
+   }
+}
+EXPORT_SYMBOL(drm_plane_enable_color_mgmt);
+
+/**
  * drm_universal_plane_init - Initialize a new universal plane object
  * @dev: DRM device
  * @plane: plane object to init
diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
index 03a59cb..155a9ba 100644
--- a/include/drm/drm_color_mgmt.h
+++ b/include/drm/drm_color_mgmt.h
@@ -37,4 +37,9 @@ void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc,
 int drm_mode_crtc_set_gamma_size(struct drm_crtc *crtc,
 int gamma_size);
 
+void drm_plane_enable_color_mgmt(struct drm_plane *plane,
+uint plane_degamma_lut_size,
+bool plane_has_ctm,
+uint plane_gamma_lut_size);
+
 #endif
-- 
1.7.9.5

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

[RFC 2/7] drm: Add Plane CTM property

[Uma Shankar]

Add a blob property for plane CSC usage.

v2: Rebase

Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/drm_atomic.c|   10 ++
 drivers/gpu/drm/drm_atomic_helper.c |3 +++
 drivers/gpu/drm/drm_mode_config.c   |7 +++
 include/drm/drm_mode_config.h   |6 ++
 include/drm/drm_plane.h |8 
 5 files changed, 34 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 30853c7..45aede5 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -766,6 +766,14 @@ static int drm_atomic_plane_set_property(struct drm_plane 
*plane,
val, -1, );
state->color_mgmt_changed |= replaced;
return ret;
+   } else if (property == config->plane_ctm_property) {
+   ret = drm_atomic_replace_property_blob_from_id(dev,
+   >ctm,
+   val,
+   sizeof(struct drm_color_ctm),
+   );
+   state->color_mgmt_changed |= replaced;
+   return ret;
} else {
return -EINVAL;
}
@@ -827,6 +835,8 @@ static int drm_atomic_plane_set_property(struct drm_plane 
*plane,
} else if (property == config->plane_degamma_lut_property) {
*val = (state->degamma_lut) ?
state->degamma_lut->base.id : 0;
+   } else if (property == config->plane_ctm_property) {
+   *val = (state->ctm) ? state->ctm->base.id : 0;
} else {
return -EINVAL;
}
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index ba924cf..d3154e0 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3398,6 +3398,8 @@ void __drm_atomic_helper_plane_duplicate_state(struct 
drm_plane *plane,
 
if (state->degamma_lut)
drm_property_blob_get(state->degamma_lut);
+   if (state->ctm)
+   drm_property_blob_get(state->ctm);
state->color_mgmt_changed = false;
 }
 EXPORT_SYMBOL(__drm_atomic_helper_plane_duplicate_state);
@@ -3445,6 +3447,7 @@ void __drm_atomic_helper_plane_destroy_state(struct 
drm_plane_state *state)
drm_crtc_commit_put(state->commit);
 
drm_property_blob_put(state->degamma_lut);
+   drm_property_blob_put(state->ctm);
 }
 EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);
 
diff --git a/drivers/gpu/drm/drm_mode_config.c 
b/drivers/gpu/drm/drm_mode_config.c
index 118f6ac..bccc70e 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -362,6 +362,13 @@ static int drm_mode_create_standard_properties(struct 
drm_device *dev)
return -ENOMEM;
dev->mode_config.plane_degamma_lut_size_property = prop;
 
+   prop = drm_property_create(dev,
+   DRM_MODE_PROP_BLOB,
+   "PLANE_CTM", 0);
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.plane_ctm_property = prop;
+
return 0;
 }
 
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 6ee2df6..3bf7fc6 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -727,6 +727,12 @@ struct drm_mode_config {
 * size of the degamma LUT as supported by the driver (read-only).
 */
struct drm_property *plane_degamma_lut_size_property;
+   /**
+* @plane_ctm_property: Optional CRTC property to set the
+* matrix used to convert colors after the lookup in the
+* degamma LUT.
+*/
+   struct drm_property *plane_ctm_property;
 
/**
 * @suggested_x_property: Optional connector property with a hint for
diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
index d112c50..7fcc51e 100644
--- a/include/drm/drm_plane.h
+++ b/include/drm/drm_plane.h
@@ -132,6 +132,14 @@ struct drm_plane_state {
struct drm_property_blob *degamma_lut;
 
/**
+* @ctm:
+*
+* Color transformation matrix. See drm_plane_enable_color_mgmt(). The
+* blob (if not NULL) is a  drm_color_ctm.
+*/
+   struct drm_property_blob *ctm;
+
+   /**
 * @commit: Tracks the pending commit to prevent use-after-free 
conditions,
 * and for async plane updates.
 *
-- 
1.7.9.5

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

[RFC 1/7] drm: Add Plane Degamma properties

[Uma Shankar]

Add Plane Degamma as a blob property and plane
degamma size as a range property.

v2: Rebase

Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/drm_atomic.c|   12 
 drivers/gpu/drm/drm_atomic_helper.c |6 ++
 drivers/gpu/drm/drm_mode_config.c   |   14 ++
 include/drm/drm_mode_config.h   |   11 +++
 include/drm/drm_plane.h |   10 ++
 5 files changed, 53 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 7e0e7be..30853c7 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -713,6 +713,8 @@ static int drm_atomic_plane_set_property(struct drm_plane 
*plane,
 {
struct drm_device *dev = plane->dev;
struct drm_mode_config *config = >mode_config;
+   bool replaced = false;
+   int ret;
 
if (property == config->prop_fb_id) {
struct drm_framebuffer *fb = drm_framebuffer_lookup(dev, NULL, 
val);
@@ -758,6 +760,12 @@ static int drm_atomic_plane_set_property(struct drm_plane 
*plane,
} else if (plane->funcs->atomic_set_property) {
return plane->funcs->atomic_set_property(plane, state,
property, val);
+   } else if (property == config->plane_degamma_lut_property) {
+   ret = drm_atomic_replace_property_blob_from_id(dev,
+   >degamma_lut,
+   val, -1, );
+   state->color_mgmt_changed |= replaced;
+   return ret;
} else {
return -EINVAL;
}
@@ -816,6 +824,9 @@ static int drm_atomic_plane_set_property(struct drm_plane 
*plane,
*val = state->zpos;
} else if (plane->funcs->atomic_get_property) {
return plane->funcs->atomic_get_property(plane, state, 
property, val);
+   } else if (property == config->plane_degamma_lut_property) {
+   *val = (state->degamma_lut) ?
+   state->degamma_lut->base.id : 0;
} else {
return -EINVAL;
}
@@ -953,6 +964,7 @@ static void drm_atomic_plane_print_state(struct drm_printer 
*p,
drm_printf(p, "\tcrtc-pos=" DRM_RECT_FMT "\n", DRM_RECT_ARG());
drm_printf(p, "\tsrc-pos=" DRM_RECT_FP_FMT "\n", DRM_RECT_FP_ARG());
drm_printf(p, "\trotation=%x\n", state->rotation);
+   drm_printf(p, "\tcolor_mgmt_changed=%d\n", state->color_mgmt_changed);
 
if (plane->funcs->atomic_print_state)
plane->funcs->atomic_print_state(p, state);
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 71d712f..ba924cf 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3395,6 +3395,10 @@ void __drm_atomic_helper_plane_duplicate_state(struct 
drm_plane *plane,
 
state->fence = NULL;
state->commit = NULL;
+
+   if (state->degamma_lut)
+   drm_property_blob_get(state->degamma_lut);
+   state->color_mgmt_changed = false;
 }
 EXPORT_SYMBOL(__drm_atomic_helper_plane_duplicate_state);
 
@@ -3439,6 +3443,8 @@ void __drm_atomic_helper_plane_destroy_state(struct 
drm_plane_state *state)
 
if (state->commit)
drm_crtc_commit_put(state->commit);
+
+   drm_property_blob_put(state->degamma_lut);
 }
 EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);
 
diff --git a/drivers/gpu/drm/drm_mode_config.c 
b/drivers/gpu/drm/drm_mode_config.c
index cda8bfa..118f6ac 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -348,6 +348,20 @@ static int drm_mode_create_standard_properties(struct 
drm_device *dev)
return -ENOMEM;
dev->mode_config.modifiers_property = prop;
 
+   prop = drm_property_create(dev,
+   DRM_MODE_PROP_BLOB,
+   "PLANE_DEGAMMA_LUT", 0);
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.plane_degamma_lut_property = prop;
+
+   prop = drm_property_create_range(dev,
+   DRM_MODE_PROP_IMMUTABLE,
+   "PLANE_DEGAMMA_LUT_SIZE", 0, UINT_MAX);
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.plane_degamma_lut_size_property = prop;
+
return 0;
 }
 
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 0b4ac2e..6ee2df6 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -718,6 +718,17 @@ struct drm_mode_config {
struct drm_property *gamma_lut_size_property;
 
/**
+* @plane_degamma_lut_property: Optional Plane property to set the LUT
+* used to convert the framebuffer's colors to linear gamma.
+*/
+   struct drm_property *plane_degamma_lut_property;
+   /**
+* @plane_degamma_lut_size_property: Optional Plane property 

[PATCH 0/7] Add Plane Color Properties

[Uma Shankar]

This patch series adds properties for plane color features. It adds
properties for degamma used to linearize data, CSC used for gamut
conversion, and gamma used to again non-linearize data as per panel
supported color space. These can be utilize by user space to convert
planes from one format to another, one color space to another etc.

Usersapce can take smart blending decisions and utilize these hardware
supported plane color features to get accurate color profile. The same
can help in consistent color quality from source to panel taking
advantage of advanced color features in hardware.

These patches just add the property interfaces and enable helper functions.

This series adds Intel Gen9 specific plane gamma feature. We can build up
and add other platform/hardware specific implementation on top of this series

Note: This is just to get a design feedback whether these interfaces look ok. 
Based on community feedback on interfaces, we will implement IGT tests to 
validate
plane color features. This is un-tested currently. 

v2: Dropped legacy gamma table for plane as suggested by Maarten. Added 
Gen9/BDW plane
gamma feature and rebase on tot.

Uma Shankar (7):
  drm: Add Plane Degamma properties
  drm: Add Plane CTM property
  drm: Add Plane Gamma properties
  drm: Define helper function for plane color enabling
  drm/i915: Enable plane color features
  drm/i915: Implement Plane Gamma for Bdw and Gen9 platforms
  drm/i915: Load plane color luts from atomic flip

 drivers/gpu/drm/drm_atomic.c  |   30 +++
 drivers/gpu/drm/drm_atomic_helper.c   |   12 +
 drivers/gpu/drm/drm_mode_config.c |   35 +
 drivers/gpu/drm/drm_plane.c   |   45 +
 drivers/gpu/drm/i915/i915_drv.h   |   10 
 drivers/gpu/drm/i915/i915_pci.c   |5 +-
 drivers/gpu/drm/i915/i915_reg.h   |   24 +
 drivers/gpu/drm/i915/intel_atomic_plane.c |4 ++
 drivers/gpu/drm/i915/intel_color.c|   78 +
 drivers/gpu/drm/i915/intel_display.c  |4 ++
 drivers/gpu/drm/i915/intel_drv.h  |   10 
 drivers/gpu/drm/i915/intel_sprite.c   |4 ++
 include/drm/drm_color_mgmt.h  |5 ++
 include/drm/drm_mode_config.h |   28 +++
 include/drm/drm_plane.h   |   27 ++
 15 files changed, 320 insertions(+), 1 deletion(-)

-- 
1.7.9.5

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

Re: [RFC PATCH] drm/vblanks: Deal with HW vblank counter resets.

[Ville Syrjälä]

On Tue, Nov 07, 2017 at 11:55:44AM +0100, Michel Dänzer wrote:
> On 07/11/17 11:50 AM, Ville Syrjälä wrote:
> > On Tue, Nov 07, 2017 at 10:47:00AM +0100, Michel Dänzer wrote:
> >> On 07/11/17 07:26 AM, Dhinakaran Pandiyan wrote:
> >>> Some HW vblank counters reset due to power management events, which messes
> >>> up the vblank counting logic. This leads to screen freezes with user space
> >>> waiting on vblank events that may not occur if the counter keeps 
> >>> resetting.
> >>>
> >>> For e.g., After the HW vblank counter resets
> >>> [9.007359] [drm:drm_update_vblank_count [drm]] updating vblank count
> >>> on crtc 0: current=297, diff=4294965389, hw=5 hw_last=1912
> >>>
> >>> So, fall back to the SW counter, computed using  vblank timestamps
> >>> and frame duration, when the HW counter value deviates by 50% of the SW
> >>> computed value.
> >>>
> >>> I have tested this patch on my SKL laptop with i915.enable_psr=1 and it
> >>> *seems* to solve the screen freeze issue seen with PSR when DMC is loaded.
> >>>
> >>> Known issues:
> >>> 1) The 50% deviation margin is arbitrary.
> >>> 2) "Redundant vblirq ignored" messages are more frequent.
> >>>
> >>> I am sending this as an RFC to get feedback on whether the fall back
> >>> approach is sane and if it should be implemented in the core.
> >>
> >> Is there no way for the driver to know under which circumstances the
> >> reset to 0 might happen? If there is, maybe it could be solved by
> >> calling drm_crtc_vblank_off() before it might happen and
> >> drm_crtc_vblank_on() after it might have happened.
> >>
> >> Otherwise, might it be better not to use the HW counter at all when it's
> >> known not to be reliable?
> > 
> > Yeah, I think we could just avoid using the HW counter whenever there's
> > a possibility of PSR being used on the crtc.
> > 
> > Assuming we still want to use the HW counter on crtcs that can't do PSR,
> > we're going to need some kind of per-crtc mechanism to tell drm_vblank.c
> > which method to use. hwmode.private_flags is one option. We already use
> > it for choosing between the scanline counter and hardware timestamps when
> > calculating the scanout position. But in this case the flag wouldn't be
> > exactly private since drm_vblank.c would have to know about it as well.
> > If that is deemed to be a problem, then we might just need to add a bool
> > to struct drm_vblank_crtc to indicate that the hw counter is good, or
> > maybe even move the dev->max_vblank_count to live inside
> > struct drm_vblank_crtc.
> 
> Or just allow setting struct drm_vblank_crtc's get_vblank_counter member
> to NULL?

Looks like that's actually under drm_crtc_funcs. I'm thinking we want
to keep that as const. Not sure we want to add a third way for drivers
to provide a .get_vblank_counter() hook (the second one being the
old drm_driver.get_vblank_counter() hook, which i915 is still using
actually).

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

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

[Tomi Valkeinen]

On 20/10/17 10:49, Boris Brezillon wrote:
> Add a driver for Cadence DPI -> DSI bridge.
> 
> This driver only support a subset of Cadence DSI bridge capabilities.
> 
> Here is a non-exhaustive list of missing features:
>  * burst mode
>  * dynamic configuration of the DPHY based on the
>  * support for additional input interfaces (SDI input)

And runtime PM.

Adding those features will change the driver quite a bit, I imagine. I
wonder if there's much benefit in reviewing the driver before the
features have been added... At least DPHY and runtime PM are critical
features.

Any reviewed-by for this version won't be really valid when those
features have been added.

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH] drm/vblanks: Deal with HW vblank counter resets.

[Michel Dänzer]

On 07/11/17 11:50 AM, Ville Syrjälä wrote:
> On Tue, Nov 07, 2017 at 10:47:00AM +0100, Michel Dänzer wrote:
>> On 07/11/17 07:26 AM, Dhinakaran Pandiyan wrote:
>>> Some HW vblank counters reset due to power management events, which messes
>>> up the vblank counting logic. This leads to screen freezes with user space
>>> waiting on vblank events that may not occur if the counter keeps resetting.
>>>
>>> For e.g., After the HW vblank counter resets
>>> [9.007359] [drm:drm_update_vblank_count [drm]] updating vblank count
>>> on crtc 0: current=297, diff=4294965389, hw=5 hw_last=1912
>>>
>>> So, fall back to the SW counter, computed using  vblank timestamps
>>> and frame duration, when the HW counter value deviates by 50% of the SW
>>> computed value.
>>>
>>> I have tested this patch on my SKL laptop with i915.enable_psr=1 and it
>>> *seems* to solve the screen freeze issue seen with PSR when DMC is loaded.
>>>
>>> Known issues:
>>> 1) The 50% deviation margin is arbitrary.
>>> 2) "Redundant vblirq ignored" messages are more frequent.
>>>
>>> I am sending this as an RFC to get feedback on whether the fall back
>>> approach is sane and if it should be implemented in the core.
>>
>> Is there no way for the driver to know under which circumstances the
>> reset to 0 might happen? If there is, maybe it could be solved by
>> calling drm_crtc_vblank_off() before it might happen and
>> drm_crtc_vblank_on() after it might have happened.
>>
>> Otherwise, might it be better not to use the HW counter at all when it's
>> known not to be reliable?
> 
> Yeah, I think we could just avoid using the HW counter whenever there's
> a possibility of PSR being used on the crtc.
> 
> Assuming we still want to use the HW counter on crtcs that can't do PSR,
> we're going to need some kind of per-crtc mechanism to tell drm_vblank.c
> which method to use. hwmode.private_flags is one option. We already use
> it for choosing between the scanline counter and hardware timestamps when
> calculating the scanout position. But in this case the flag wouldn't be
> exactly private since drm_vblank.c would have to know about it as well.
> If that is deemed to be a problem, then we might just need to add a bool
> to struct drm_vblank_crtc to indicate that the hw counter is good, or
> maybe even move the dev->max_vblank_count to live inside
> struct drm_vblank_crtc.

Or just allow setting struct drm_vblank_crtc's get_vblank_counter member
to NULL?


-- 
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: [RFC PATCH] drm/vblanks: Deal with HW vblank counter resets.

[Ville Syrjälä]

On Tue, Nov 07, 2017 at 10:47:00AM +0100, Michel Dänzer wrote:
> On 07/11/17 07:26 AM, Dhinakaran Pandiyan wrote:
> > Some HW vblank counters reset due to power management events, which messes
> > up the vblank counting logic. This leads to screen freezes with user space
> > waiting on vblank events that may not occur if the counter keeps resetting.
> > 
> > For e.g., After the HW vblank counter resets
> > [9.007359] [drm:drm_update_vblank_count [drm]] updating vblank count
> > on crtc 0: current=297, diff=4294965389, hw=5 hw_last=1912
> > 
> > So, fall back to the SW counter, computed using  vblank timestamps
> > and frame duration, when the HW counter value deviates by 50% of the SW
> > computed value.
> > 
> > I have tested this patch on my SKL laptop with i915.enable_psr=1 and it
> > *seems* to solve the screen freeze issue seen with PSR when DMC is loaded.
> > 
> > Known issues:
> > 1) The 50% deviation margin is arbitrary.
> > 2) "Redundant vblirq ignored" messages are more frequent.
> > 
> > I am sending this as an RFC to get feedback on whether the fall back
> > approach is sane and if it should be implemented in the core.
> 
> Is there no way for the driver to know under which circumstances the
> reset to 0 might happen? If there is, maybe it could be solved by
> calling drm_crtc_vblank_off() before it might happen and
> drm_crtc_vblank_on() after it might have happened.
> 
> Otherwise, might it be better not to use the HW counter at all when it's
> known not to be reliable?

Yeah, I think we could just avoid using the HW counter whenever there's
a possibility of PSR being used on the crtc.

Assuming we still want to use the HW counter on crtcs that can't do PSR,
we're going to need some kind of per-crtc mechanism to tell drm_vblank.c
which method to use. hwmode.private_flags is one option. We already use
it for choosing between the scanline counter and hardware timestamps when
calculating the scanout position. But in this case the flag wouldn't be
exactly private since drm_vblank.c would have to know about it as well.
If that is deemed to be a problem, then we might just need to add a bool
to struct drm_vblank_crtc to indicate that the hw counter is good, or
maybe even move the dev->max_vblank_count to live inside
struct drm_vblank_crtc.

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

[PATCH] drm/selftests/mm: Insert cond_resched() between insert modes

[Chris Wilson]

kbuilder has begun running the selftests and reported a soft-lockup
inside __igt_insert(), so break up the test loop over different modes
with another call to cond_resched().

Reported-by: Fengguang Wu 
Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/selftests/test-drm_mm.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/selftests/test-drm_mm.c 
b/drivers/gpu/drm/selftests/test-drm_mm.c
index 86eb4c185a28..7cc935d7b7aa 100644
--- a/drivers/gpu/drm/selftests/test-drm_mm.c
+++ b/drivers/gpu/drm/selftests/test-drm_mm.c
@@ -682,6 +682,8 @@ static int __igt_insert(unsigned int count, u64 size, bool 
replace)
drm_mm_for_each_node_safe(node, next, )
drm_mm_remove_node(node);
DRM_MM_BUG_ON(!drm_mm_clean());
+
+   cond_resched();
}
 
ret = 0;
@@ -944,6 +946,8 @@ static int __igt_insert_range(unsigned int count, u64 size, 
u64 start, u64 end)
drm_mm_for_each_node_safe(node, next, )
drm_mm_remove_node(node);
DRM_MM_BUG_ON(!drm_mm_clean());
+
+   cond_resched();
}
 
ret = 0;
@@ -1068,6 +1072,7 @@ static int igt_align(void *ignored)
drm_mm_for_each_node_safe(node, next, )
drm_mm_remove_node(node);
DRM_MM_BUG_ON(!drm_mm_clean());
+
cond_resched();
}
 
-- 
2.15.0

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

[PATCH] drm/tilcdc: Remove drm_framebuffer_get() and *_put() calls

[Jyri Sarha]

The drm_framebuffer_get() and drm_framebuffer_put() calls in the
tilcdc driver are obsolete. The drm atomic modesetting core should
take care of holding the references while the atomic state object is
in use. The old state is deleted when a commit of a new one is
completed after drm_atomic_helper_wait_for_vblanks().

This also fixes an occasional framebuffer leak the old
drm_framebuffer_get() and drm_framebuffer_put() code had.

Signed-off-by: Jyri Sarha 
---
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 49 
 1 file changed, 49 deletions(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index 6ef4d1a..b81a593 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -51,12 +51,8 @@ struct tilcdc_crtc {
ktime_t last_vblank;
unsigned int hvtotal_us;
 
-   struct drm_framebuffer *curr_fb;
struct drm_framebuffer *next_fb;
 
-   /* for deferred fb unref's: */
-   struct drm_flip_work unref_work;
-
/* Only set if an external encoder is connected */
bool simulate_vesa_sync;
 
@@ -70,20 +66,8 @@ struct tilcdc_crtc {
 };
 #define to_tilcdc_crtc(x) container_of(x, struct tilcdc_crtc, base)
 
-static void unref_worker(struct drm_flip_work *work, void *val)
-{
-   struct tilcdc_crtc *tilcdc_crtc =
-   container_of(work, struct tilcdc_crtc, unref_work);
-   struct drm_device *dev = tilcdc_crtc->base.dev;
-
-   mutex_lock(>mode_config.mutex);
-   drm_framebuffer_put(val);
-   mutex_unlock(>mode_config.mutex);
-}
-
 static void set_scanout(struct drm_crtc *crtc, struct drm_framebuffer *fb)
 {
-   struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
struct drm_device *dev = crtc->dev;
struct tilcdc_drm_private *priv = dev->dev_private;
struct drm_gem_cma_object *gem;
@@ -108,12 +92,6 @@ static void set_scanout(struct drm_crtc *crtc, struct 
drm_framebuffer *fb)
 
dma_base_and_ceiling = (u64)end << 32 | start;
tilcdc_write64(dev, LCDC_DMA_FB_BASE_ADDR_0_REG, dma_base_and_ceiling);
-
-   if (tilcdc_crtc->curr_fb)
-   drm_flip_work_queue(_crtc->unref_work,
-   tilcdc_crtc->curr_fb);
-
-   tilcdc_crtc->curr_fb = fb;
 }
 
 /*
@@ -464,8 +442,6 @@ static void tilcdc_crtc_set_mode(struct drm_crtc *crtc)
 
set_scanout(crtc, fb);
 
-   drm_framebuffer_get(fb);
-
crtc->hwmode = crtc->state->adjusted_mode;
 
tilcdc_crtc->hvtotal_us =
@@ -524,7 +500,6 @@ static void tilcdc_crtc_off(struct drm_crtc *crtc, bool 
shutdown)
 {
struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
struct drm_device *dev = crtc->dev;
-   struct tilcdc_drm_private *priv = dev->dev_private;
int ret;
 
mutex_lock(_crtc->enable_lock);
@@ -554,20 +529,6 @@ static void tilcdc_crtc_off(struct drm_crtc *crtc, bool 
shutdown)
 
pm_runtime_put_sync(dev->dev);
 
-   if (tilcdc_crtc->next_fb) {
-   drm_flip_work_queue(_crtc->unref_work,
-   tilcdc_crtc->next_fb);
-   tilcdc_crtc->next_fb = NULL;
-   }
-
-   if (tilcdc_crtc->curr_fb) {
-   drm_flip_work_queue(_crtc->unref_work,
-   tilcdc_crtc->curr_fb);
-   tilcdc_crtc->curr_fb = NULL;
-   }
-
-   drm_flip_work_commit(_crtc->unref_work, priv->wq);
-
tilcdc_crtc->enabled = false;
mutex_unlock(_crtc->enable_lock);
 }
@@ -614,7 +575,6 @@ static void tilcdc_crtc_recover_work(struct work_struct 
*work)
 
 static void tilcdc_crtc_destroy(struct drm_crtc *crtc)
 {
-   struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
struct tilcdc_drm_private *priv = crtc->dev->dev_private;
 
tilcdc_crtc_shutdown(crtc);
@@ -623,7 +583,6 @@ static void tilcdc_crtc_destroy(struct drm_crtc *crtc)
 
of_node_put(crtc->port);
drm_crtc_cleanup(crtc);
-   drm_flip_work_cleanup(_crtc->unref_work);
 }
 
 int tilcdc_crtc_update_fb(struct drm_crtc *crtc,
@@ -638,9 +597,6 @@ int tilcdc_crtc_update_fb(struct drm_crtc *crtc,
return -EBUSY;
}
 
-   drm_framebuffer_get(fb);
-
-   crtc->primary->fb = fb;
tilcdc_crtc->event = event;
 
mutex_lock(_crtc->enable_lock);
@@ -936,8 +892,6 @@ irqreturn_t tilcdc_crtc_irq(struct drm_crtc *crtc)
 
now = ktime_get();
 
-   drm_flip_work_commit(_crtc->unref_work, priv->wq);
-
spin_lock_irqsave(_crtc->irq_lock, flags);
 
tilcdc_crtc->last_vblank = now;
@@ -1064,9 +1018,6 @@ int tilcdc_crtc_create(struct drm_device *dev)
 
init_waitqueue_head(_crtc->frame_done_wq);
 
-   drm_flip_work_init(_crtc->unref_work,
-   "unref", unref_worker);
-
spin_lock_init(_crtc->irq_lock);
INIT_WORK(_crtc->recover_work, 

Re: [RFC PATCH] drm/vblanks: Deal with HW vblank counter resets.

[Michel Dänzer]

On 07/11/17 07:26 AM, Dhinakaran Pandiyan wrote:
> Some HW vblank counters reset due to power management events, which messes
> up the vblank counting logic. This leads to screen freezes with user space
> waiting on vblank events that may not occur if the counter keeps resetting.
> 
> For e.g., After the HW vblank counter resets
> [9.007359] [drm:drm_update_vblank_count [drm]] updating vblank count
> on crtc 0: current=297, diff=4294965389, hw=5 hw_last=1912
> 
> So, fall back to the SW counter, computed using  vblank timestamps
> and frame duration, when the HW counter value deviates by 50% of the SW
> computed value.
> 
> I have tested this patch on my SKL laptop with i915.enable_psr=1 and it
> *seems* to solve the screen freeze issue seen with PSR when DMC is loaded.
> 
> Known issues:
> 1) The 50% deviation margin is arbitrary.
> 2) "Redundant vblirq ignored" messages are more frequent.
> 
> I am sending this as an RFC to get feedback on whether the fall back
> approach is sane and if it should be implemented in the core.

Is there no way for the driver to know under which circumstances the
reset to 0 might happen? If there is, maybe it could be solved by
calling drm_crtc_vblank_off() before it might happen and
drm_crtc_vblank_on() after it might have happened.

Otherwise, might it be better not to use the HW counter at all when it's
known not to be reliable?


-- 
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: [PATCH 3/3] ASoC: rt5645: Wait for 400msec before concluding on value of RT5645_VENDOR_ID2

[Agrawal, Akshu]

On 11/6/2017 9:54 PM, Mark Brown wrote:

On Fri, Nov 03, 2017 at 04:35:45PM -0400, Alex Deucher wrote:


Minimum time required between power On of codec and read
of RT5645_VENDOR_ID2 is 400msec. We should wait and attempt
before erroring out.


So the description says we have to wait 400ms before attempting a
read...


Yes, that's true.




BUG=b:66978383


What does this mean?


A bug ID. Removing it in V2.




@@ -3786,6 +3789,15 @@ static int rt5645_i2c_probe(struct i2c_client *i2c,
}
regmap_read(regmap, RT5645_VENDOR_ID2, );
  
+	/*

+* Read for 400msec, as it is the interval required between
+* read and power On.
+*/
+   while (val != RT5645_DEVICE_ID && val != RT5650_DEVICE_ID && --timeout) 
{
+   msleep(1);
+   regmap_read(regmap, RT5645_VENDOR_ID2, );
+   }
+


...but what we actually do is try to read up to 400 times starting well
before that 400ms is up.  This directly contradicts what the commit
message said we needed, may take a lot longer if the chip misbehaves on
the I2C bus while it's not ready (which wouldn't be that much of a
surprise), might lead to us reporting before the chip is really stable
(if the read happens to work while the chip isn't yet stable) and could
cause lots of noise on the console if the I2C controller gets upset.
What are we actually waiting for here?



In my understanding if we get RT5645 or RT5650 DEVICE ID from register 
RT5645_VENDOR_ID2 then that means the chip is stable.



If we really need 400ms of dead reckoning time (which is a lot for a
modern chip, that feels more like a VMID ramp) then it's going to be
safer to just do that.



Agreed, will just sleep for 400ms before reading the register value.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 5/9] drm/exynos: Add generic support for devices shared with V4L2 subsystem

[Marek Szyprowski]

Hi Inki,

On 2017-11-06 02:20, Inki Dae wrote:

2017년 11월 03일 21:28에 Marek Szyprowski 이(가) 쓴 글:

On 2017-11-01 07:26, Inki Dae wrote:

2017년 10월 23일 16:54에 Marek Szyprowski 이(가) 쓴 글:

Some hardware modules, like FIMC in Exynos4 series are shared between
V4L2 (camera support) and DRM (memory-to-memory processing) subsystems.
This patch provides a simple check to let such drivers to be used in the
driver components framework.

Signed-off-by: Marek Szyprowski 
---
   drivers/gpu/drm/exynos/exynos_drm_drv.c | 17 -
   drivers/gpu/drm/exynos/exynos_drm_drv.h |  2 ++
   2 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index cac0d84385d3..60ae6ae06eb2 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -216,6 +216,7 @@ struct exynos_drm_driver_info {
   #define DRM_COMPONENT_DRIVERBIT(0)/* supports component framework */
   #define DRM_VIRTUAL_DEVICEBIT(1)/* create virtual platform device */
   #define DRM_DMA_DEVICEBIT(2)/* can be used for dma allocations */
+#define DRM_SHARED_DEVICEBIT(3)/* devices shared with V4L2 subsystem */
 #define DRV_PTR(drv, cond) (IS_ENABLED(cond) ?  : NULL)
   @@ -267,6 +268,17 @@ static struct exynos_drm_driver_info 
exynos_drm_drivers[] = {
   }
   };
   +int exynos_drm_check_shared_device(struct device *dev)
+{
+/*
+ * Exynos DRM drivers handle only devices that support
+ * the LCD Writeback data path, rest is handled by V4L2 driver
+ */
+if (!of_property_read_bool(dev->of_node, "samsung,lcd-wb"))
+return -ENODEV;
+return 0;
+}
+
   static int compare_dev(struct device *dev, void *data)
   {
   return dev == (struct device *)data;
@@ -288,7 +300,10 @@ static struct component_match *exynos_drm_match_add(struct 
device *dev)
   >driver->driver,
   (void *)platform_bus_type.match))) {
   put_device(p);
-component_match_add(dev, , compare_dev, d);
+
+if (!(info->flags & DRM_SHARED_DEVICE) ||
+exynos_drm_check_shared_device(d) == 0)
+component_match_add(dev, , compare_dev, d);

Seems above line make fimc device driver to be bound only when fimc device node has 
"samsung,lcd-wb" property. However, Exynos DRM FIMC driver is able to various 
transfomations such as color space conversion, scaling up/down and rotation.
And this driver is used as mem to mem device driver. However, 'writeback' 
feature means 'dma to memory', which delivers one blended image in display 
controller into system memory.

This patch is only to bind fimc.2 and fimc.3 devices to DRM and fimc.0
and fimc.1 to V4L2. Exactly the same checks are in V4l2 and old DRM FIMC
drivers.

Indeed. No change for behaivor.

When Sylwester posted old version[1] of DRM fimc device tree support, seems he 
and even me missed the behaiver of DRM FIMC driver.
According to below patch description, it says,
"The DRM driver uses this interface for setting up the FIFO data link between FIMD 
and FIMC IP blocks"

We thought we could use 'samsung,lcd-wb' property to distinguish FIMC devices 
for V4L2 and ones for DRM - only fimc 2 and fimc 3 - have 'samsung'lcd-wb' 
property'.

but it's not true. DRM FIMC driver is used as a general post processing 
hardware such as color space conversion, scaling up/down and rotation 
operations.
In FIMC device's perspective, 'samsung,lcd-wb' means 'dma to memory' - as I 
mentioned before, which delivers one blended image in display controller into 
system memory and it's just one of several features FIMC has - so it doesn't 
make sense.

For example,
User - some device tree - can remove 'samsung,lcd-wb' property from fimc device 
node because this property is optional. In this case, binding of DRM FIMC 
driver will fail even though FIMC driver can provide other functions.
We shouldn't make FIMC device to be limited with just LCD write back feature 
and we need to find a good way to distinguish FIMC devices for V4L2 and DRM.

Anyway, we are trying to merge new version of IPP driver which is really a big 
change so how about making sure the behaiver of this driver, not depending on 
'old version'?
I think we need to take care of this carefully because ABI interface could be 
changed according to our decision.

To Sylwester,
Could you give us your option?

According to Exynos4412 datasheet,
'isp-wb' can go to input of FIMC 0, 1 and 2, and 'lcd-wb' can go to input of 
FIMC 2 and 3 if Figure 43-1 in the datasheet is right.

So it says,
1. FIMC 0 and 1 could be used for isp-wb.
2. FIMC 2 could be used for isp-wb and lcd-wb.
3. FIMC 3 could be used for lcd-wb.

But you updated binding document as like below,
"Optional properties:
...
- samsung,isp-wb: this property must be present if the IP block has the ISP
   writeback input.
- 

Re: [PATCH 1/3] ASoC: amd: Report accurate hw_ptr during dma

[Mukunda,Vijendar]

Removing URL links and commit-ready description in v2.


On Monday 06 November 2017 09:18 PM, Mark Brown wrote:

On Fri, Nov 03, 2017 at 04:35:43PM -0400, Alex Deucher wrote:


Signed-off-by: Vijendar Mukunda 
Signed-off-by: Akshu Agrawal 
Reviewed-on: https://chromium-review.googlesource.com/659699
Commit-Ready: Akshu Agrawal 
Tested-by: Akshu Agrawal 
Reviewed-by: Jason Clinton 
Reviewed-on: https://chromium-review.googlesource.com/676627

These two URLs are different, what was being reviewed here?  What is
Commit-Ready supposed to mean?


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

Re: [PATCH 15/22] drm/tilcdc: Use drm_fb_cma_fbdev_init/fini()

[Jyri Sarha]

On 11/04/17 15:04, Noralf Trønnes wrote:
> Use drm_fb_cma_fbdev_init() and drm_fb_cma_fbdev_fini() which relies on
> the fact that drm_device holds a pointer to the drm_fb_helper structure.
> This means that the driver doesn't have to keep track of that.
> Also use the drm_fb_helper functions directly.
> 
> Cc: Jyri Sarha 
> Cc: Tomi Valkeinen 
> Signed-off-by: Noralf Trønnes 

Acked-by: Jyri Sarha 

Let me know if you want me to pick this to my next tilcdc pull request!

Thanks,
Jyri

> ---
>  drivers/gpu/drm/tilcdc/tilcdc_drv.c | 26 +-
>  drivers/gpu/drm/tilcdc/tilcdc_drv.h |  2 --
>  2 files changed, 5 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
> b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> index 72ce063aa0d8..091b1025898e 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> @@ -69,12 +69,6 @@ static struct drm_framebuffer *tilcdc_fb_create(struct 
> drm_device *dev,
>   return drm_gem_fb_create(dev, file_priv, mode_cmd);
>  }
>  
> -static void tilcdc_fb_output_poll_changed(struct drm_device *dev)
> -{
> - struct tilcdc_drm_private *priv = dev->dev_private;
> - drm_fbdev_cma_hotplug_event(priv->fbdev);
> -}
> -
>  static int tilcdc_atomic_check(struct drm_device *dev,
>  struct drm_atomic_state *state)
>  {
> @@ -146,7 +140,7 @@ static int tilcdc_commit(struct drm_device *dev,
>  
>  static const struct drm_mode_config_funcs mode_config_funcs = {
>   .fb_create = tilcdc_fb_create,
> - .output_poll_changed = tilcdc_fb_output_poll_changed,
> + .output_poll_changed = drm_fb_helper_output_poll_changed,
>   .atomic_check = tilcdc_atomic_check,
>   .atomic_commit = tilcdc_commit,
>  };
> @@ -198,8 +192,7 @@ static void tilcdc_fini(struct drm_device *dev)
>  
>   drm_kms_helper_poll_fini(dev);
>  
> - if (priv->fbdev)
> - drm_fbdev_cma_fini(priv->fbdev);
> + drm_fb_cma_fbdev_fini(dev);
>  
>   drm_irq_uninstall(dev);
>   drm_mode_config_cleanup(dev);
> @@ -405,12 +398,9 @@ static int tilcdc_init(struct drm_driver *ddrv, struct 
> device *dev)
>  
>   drm_mode_config_reset(ddev);
>  
> - priv->fbdev = drm_fbdev_cma_init(ddev, bpp,
> -  ddev->mode_config.num_connector);
> - if (IS_ERR(priv->fbdev)) {
> - ret = PTR_ERR(priv->fbdev);
> + ret = drm_fb_cma_fbdev_init(ddev, bpp, 0);
> + if (ret)
>   goto init_failed;
> - }
>  
>   drm_kms_helper_poll_init(ddev);
>  
> @@ -427,12 +417,6 @@ static int tilcdc_init(struct drm_driver *ddrv, struct 
> device *dev)
>   return ret;
>  }
>  
> -static void tilcdc_lastclose(struct drm_device *dev)
> -{
> - struct tilcdc_drm_private *priv = dev->dev_private;
> - drm_fbdev_cma_restore_mode(priv->fbdev);
> -}
> -
>  static irqreturn_t tilcdc_irq(int irq, void *arg)
>  {
>   struct drm_device *dev = arg;
> @@ -538,7 +522,7 @@ DEFINE_DRM_GEM_CMA_FOPS(fops);
>  static struct drm_driver tilcdc_driver = {
>   .driver_features= (DRIVER_HAVE_IRQ | DRIVER_GEM | DRIVER_MODESET |
>  DRIVER_PRIME | DRIVER_ATOMIC),
> - .lastclose  = tilcdc_lastclose,
> + .lastclose  = drm_fb_helper_lastclose,
>   .irq_handler= tilcdc_irq,
>   .gem_free_object_unlocked = drm_gem_cma_free_object,
>   .gem_vm_ops = _gem_cma_vm_ops,
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.h 
> b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
> index 8caa11bc7aec..ead512216669 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_drv.h
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
> @@ -79,8 +79,6 @@ struct tilcdc_drm_private {
>  
>   struct workqueue_struct *wq;
>  
> - struct drm_fbdev_cma *fbdev;
> -
>   struct drm_crtc *crtc;
>  
>   unsigned int num_encoders;
> 


-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: video: atmel_lcdfb: Use common error handling code in atmel_lcdfb_of_init()

[Nicolas Ferre]

On 06/11/2017 at 10:32, SF Markus Elfring wrote:
>> Sorry but NACK: the message was malformed and resulted in the
>> duplication of the error log that you spotted.
>>
>> The proper way to fix this is to modify the second occurrence of this 
>> message.
> 
> * Would you like to achieve that a corresponding message will mention
>   anything around a property “atmel,dmacon” (instead of “bits-per-pixel”)?

Yes: that would actually fix the wrong log message.

> * Can it make sense to adjust the used message format then?

In another patch, why not... Beware about the added complexity though.

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

Re: [PATCH 4.9.y 1/3] drm/bridge: adv7511: Rework adv7511_power_on/off() so they can be reused internally

[Nhan Ngoc. Nguyen]

On 11/6/2017 2:57 PM, Greg KH wrote:

On Fri, Nov 03, 2017 at 10:10:26AM +0700, Nhan Nguyen wrote:

From: John Stultz 

commit 651e4769ba2a9f20c4b8a823ae2727bf7fa9c9f0 upstream.

In chasing down issues with EDID probing, I found some
duplicated but incomplete logic used to power the chip on and
off.

This patch refactors the adv7511_power_on/off functions, so
they can be used for internal needs.

Cc: David Airlie 
Cc: Archit Taneja 
Cc: Wolfram Sang 
Cc: Lars-Peter Clausen 
Cc: Laurent Pinchart 
Cc: dri-devel@lists.freedesktop.org
Cc: sta...@vger.kernel.org
Signed-off-by: John Stultz 
Signed-off-by: Archit Taneja 
Signed-off-by: Thong Ho 
Signed-off-by: Nhan Nguyen 
Link: 
http://patchwork.freedesktop.org/patch/msgid/1484614372-15342-5-git-send-email-john.stu...@linaro.org
---
  drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 15 +++
  1 file changed, 11 insertions(+), 4 deletions(-)

Why are you asking for these 3 patches to be backported to the 4.9
stable tree?  What bugs are they fixing?  How do they meet the stable
kernel rules?

totally confused,

greg k-h


This patch is re-writes the i2c address to ADV7511_REG_EDID_I2C_ADDR register 
to ensure its properly set before reading the EDID data.
In the past, the backporting is for Kernel v4.4 and you asked to port for 4.9 
also.




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

radeon_dp_aux_transfer_native: 74 callbacks suppressed

[Jean Delvare]

Hi all,

commit 92c177b7947d9c889ea7b024871445015ea74221
Author: Lyude
Date:   Wed Feb 22 16:34:53 2017 -0500

drm/radeon/dp_auxch: Ratelimit aux transfer debug messages

does more harm than good in my opinion. Since this commit, I see
several occurrences of the following message in my kernel log daily:

radeon_dp_aux_transfer_native: 74 callbacks suppressed

I never got to see the "callback" in question though, not even once, as
this is a debug message which is off by default. Before the change, I
would not get any such message in the kernel log (as I would expect
when everything works as intended.)

Does this debug message really have any practical value? If not, the
easiest solution would be to simply drop it:

--- a/drivers/gpu/drm/radeon/radeon_dp_auxch.c
+++ b/drivers/gpu/drm/radeon/radeon_dp_auxch.c
@@ -168,8 +168,10 @@ radeon_dp_aux_transfer_native(struct drm
goto done;
}
if (tmp & AUX_RX_ERROR_FLAGS) {
-   DRM_DEBUG_KMS_RATELIMITED("dp_aux_ch flags not zero: %08x\n",
- tmp);
+   /*
+* aux transfers always fail with non-zero status flags when
+* there's nothing connected on the port
+*/
ret = -EIO;
goto done;
}

I can resend this as a formal patch if you agree with this solution.

The actual cause of the problem is that ___ratelimit() prints its
message at KERN_WARNING level regardless of the level of the message
being suppressed. This makes ratelimiting debug, info or notice
messages awkward. Looks like a design overlook to me, maybe it should
be fixed, but that's a much bigger and intrusive change than the
proposal above.

-- 
Jean Delvare
SUSE L3 Support
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] video: fbdev: sm501fb: mark expected switch fall-through in sm501fb_blank_crt

[Gustavo A. R. Silva]

In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.

Signed-off-by: Gustavo A. R. Silva 
---
 drivers/video/fbdev/sm501fb.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/video/fbdev/sm501fb.c b/drivers/video/fbdev/sm501fb.c
index 076dd27..7085cc0 100644
--- a/drivers/video/fbdev/sm501fb.c
+++ b/drivers/video/fbdev/sm501fb.c
@@ -1008,6 +1008,7 @@ static int sm501fb_blank_crt(int blank_mode, struct 
fb_info *info)
case FB_BLANK_POWERDOWN:
ctrl &= ~SM501_DC_CRT_CONTROL_ENABLE;
sm501_misc_control(fbi->dev->parent, SM501_MISC_DAC_POWER, 0);
+   /* fall through */
 
case FB_BLANK_NORMAL:
ctrl |= SM501_DC_CRT_CONTROL_BLANK;
-- 
2.7.4

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

[PATCH] video: fbdev: aty: radeon_pm: mark expected switch fall-throughs

[Gustavo A. R. Silva]

In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.

Signed-off-by: Gustavo A. R. Silva 
---
 drivers/video/fbdev/aty/radeon_pm.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/video/fbdev/aty/radeon_pm.c 
b/drivers/video/fbdev/aty/radeon_pm.c
index f7c253d..7137c12 100644
--- a/drivers/video/fbdev/aty/radeon_pm.c
+++ b/drivers/video/fbdev/aty/radeon_pm.c
@@ -1208,9 +1208,11 @@ static void radeon_pm_enable_dll_m10(struct 
radeonfb_info *rinfo)
case 1:
if (mc & 0x4)
break;
+   /* fall through */
case 2:
dll_sleep_mask |= MDLL_R300_RDCK__MRDCKB_SLEEP;
dll_reset_mask |= MDLL_R300_RDCK__MRDCKB_RESET;
+   /* fall through */
case 0:
dll_sleep_mask |= MDLL_R300_RDCK__MRDCKA_SLEEP;
dll_reset_mask |= MDLL_R300_RDCK__MRDCKA_RESET;
@@ -1219,6 +1221,7 @@ static void radeon_pm_enable_dll_m10(struct radeonfb_info 
*rinfo)
case 1:
if (!(mc & 0x4))
break;
+   /* fall through */
case 2:
dll_sleep_mask |= MDLL_R300_RDCK__MRDCKD_SLEEP;
dll_reset_mask |= MDLL_R300_RDCK__MRDCKD_RESET;
-- 
2.7.4

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

drm/i915: GPU Hang with kernel v4.14-rc8

[Julian Wollrath]

Hi,

I do not have a bugzilla account and do not intend to register in the
bugzilla, therefore, I am sending this e-mail instead. I have got a GPU
hang with kernel v4.14-rc8 "GPU HANG: ecode 7:1:0xecdfbff0, in Xorg
[761], reason: No progress on bcs0, action: reset". The crash dump is
attached.

With best regards,
Julian Wollrath

-- 
 ()  ascii ribbon campaign - against html e-mail 
 /\- against proprietary attachments


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

[PATCH] video: fbdev: cirrusfb: mark expected switch fall-throughs

[Gustavo A. R. Silva]

In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.

Notice that in this particular case I placed the "fall through" comment
on its own line, which is what GCC is expecting to find.

Signed-off-by: Gustavo A. R. Silva 
---
 drivers/video/fbdev/cirrusfb.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/video/fbdev/cirrusfb.c b/drivers/video/fbdev/cirrusfb.c
index d992aa5..b3be06d 100644
--- a/drivers/video/fbdev/cirrusfb.c
+++ b/drivers/video/fbdev/cirrusfb.c
@@ -1477,10 +1477,12 @@ static void init_vgachip(struct fb_info *info)
mdelay(100);
/* mode */
vga_wgfx(cinfo->regbase, CL_GR31, 0x00);
-   case BT_GD5480:  /* fall through */
+   /* fall through */
+   case BT_GD5480:
/* from Klaus' NetBSD driver: */
vga_wgfx(cinfo->regbase, CL_GR2F, 0x00);
-   case BT_ALPINE:  /* fall through */
+   /* fall through */
+   case BT_ALPINE:
/* put blitter into 542x compat */
vga_wgfx(cinfo->regbase, CL_GR33, 0x00);
break;
-- 
2.7.4

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

Re: linux-next: Tree for Nov 6 (amdgpu_virt.c)

[Randy Dunlap]

On 11/05/2017 11:30 PM, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20171103:
> 

on i386, when CONFIG_MODULES is not set:

  CC  drivers/gpu/drm/amd/amdgpu/amdgpu_virt.o
In file included from ../arch/x86/include/asm/atomic.h:5:0,
 from ../include/linux/atomic.h:5,
 from ../drivers/gpu/drm/amd/amdgpu/amdgpu.h:31,
 from ../drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c:24:
../drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c: In function 
'amdgpu_virt_init_data_exchange':
../drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c:331:20: error: dereferencing 
pointer to incomplete type
 if (THIS_MODULE->version != NULL)
^
../include/linux/compiler.h:58:30: note: in definition of macro '__trace_if'
  if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
  ^
../drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c:331:5: note: in expansion of macro 
'if'
 if (THIS_MODULE->version != NULL)
 ^
../drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c:331:20: error: dereferencing 
pointer to incomplete type
 if (THIS_MODULE->version != NULL)
^
../include/linux/compiler.h:58:42: note: in definition of macro '__trace_if'
  if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
  ^
../drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c:331:5: note: in expansion of macro 
'if'
 if (THIS_MODULE->version != NULL)
 ^
../drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c:331:20: error: dereferencing 
pointer to incomplete type
 if (THIS_MODULE->version != NULL)
^
../include/linux/compiler.h:69:16: note: in definition of macro '__trace_if'
   __r = !!(cond); \
^
../drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c:331:5: note: in expansion of macro 
'if'
 if (THIS_MODULE->version != NULL)
 ^
../drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c:332:29: error: dereferencing 
pointer to incomplete type
  strcpy(str, THIS_MODULE->version);
 ^
../scripts/Makefile.build:314: recipe for target 
'drivers/gpu/drm/amd/amdgpu/amdgpu_virt.o' failed
make[5]: *** [drivers/gpu/drm/amd/amdgpu/amdgpu_virt.o] Error 1



Reported-by: Randy Dunlap 

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

Re: [PATCH] video: atmel_lcdfb: Use common error handling code in atmel_lcdfb_of_init()

[Nicolas Ferre]

On 05/11/2017 at 14:10, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Sun, 5 Nov 2017 14:00:52 +0100
> 
> Add a jump target so that a specific error message is stored only once
> at the end of this function implementation.
> Replace two calls of the function "dev_err" by goto statements.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 

Sorry but NACK: the message was malformed and resulted in the
duplication of the error log that you spotted.

The proper way to fix this is to modify the second occurrence of this
message.
If you want to lower the size of strings in this driver, you can do it,
but not like this.

Regards,
  Nicolas


> ---
>  drivers/video/fbdev/atmel_lcdfb.c | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/video/fbdev/atmel_lcdfb.c 
> b/drivers/video/fbdev/atmel_lcdfb.c
> index e06358da4b99..3672c2e52ebd 100644
> --- a/drivers/video/fbdev/atmel_lcdfb.c
> +++ b/drivers/video/fbdev/atmel_lcdfb.c
> @@ -1047,10 +1047,8 @@ static int atmel_lcdfb_of_init(struct atmel_lcdfb_info 
> *sinfo)
>   }
>  
>   ret = of_property_read_u32(display_np, "bits-per-pixel", 
> >bits_per_pixel);
> - if (ret < 0) {
> - dev_err(dev, "failed to get property bits-per-pixel\n");
> - goto put_display_node;
> - }
> + if (ret < 0)
> + goto report_bits_failure;
>  
>   ret = of_property_read_u32(display_np, "atmel,guard-time", 
> >guard_time);
>   if (ret < 0) {
> @@ -1065,10 +1063,8 @@ static int atmel_lcdfb_of_init(struct atmel_lcdfb_info 
> *sinfo)
>   }
>  
>   ret = of_property_read_u32(display_np, "atmel,dmacon", 
> >default_dmacon);
> - if (ret < 0) {
> - dev_err(dev, "failed to get property bits-per-pixel\n");
> - goto put_display_node;
> - }
> + if (ret < 0)
> + goto report_bits_failure;
>  
>   INIT_LIST_HEAD(>pwr_gpios);
>   ret = -ENOMEM;
> @@ -1147,6 +1143,10 @@ static int atmel_lcdfb_of_init(struct atmel_lcdfb_info 
> *sinfo)
>  put_display_node:
>   of_node_put(display_np);
>   return ret;
> +
> +report_bits_failure:
> + dev_err(dev, "failed to get property bits-per-pixel\n");
> + goto put_display_node;
>  }
>  #else
>  static int atmel_lcdfb_of_init(struct atmel_lcdfb_info *sinfo)
> 


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

Re: [PATCH 0/4] dma-buf: Silence dma_fence __rcu sparse warnings

[Sumit Semwal]

Hi Ville,

On 3 November 2017 at 13:18, Christian König  wrote:
> Patch #4 is Reviewed-by: Christian König .
>
> The rest is Acked-by: Christian König .
>
> Regards,
> Christian.
>
>
> Am 02.11.2017 um 21:03 schrieb Ville Syrjala:
>>
>> From: Ville Syrjälä 
>>
>> When building drm+i915 I get around 150 lines of sparse noise from
>> dma_fence __rcu warnings. This series eliminates all of that.
>>
>> The first two patches were already posted by Chris, but there wasn't
>> any real reaction, so I figured I'd repost with a wider Cc list.
>>
>> As for the other two patches, I'm no expert on dma_fence and I didn't
>> spend a lot of time looking at it so I can't be sure I annotated all
>> the accesses correctly. But I figured someone will scream at me if
>> I got it wrong ;)
>>
>> Cc: Dave Airlie 
>> Cc: Jason Ekstrand 
>> Cc: linaro-mm-...@lists.linaro.org
>> Cc: linux-me...@vger.kernel.org
>> Cc: Alex Deucher 
>> Cc: Christian König 
>> Cc: Sumit Semwal 
>> Cc: Chris Wilson 
>>
>> Chris Wilson (2):
>>drm/syncobj: Mark up the fence as an RCU protected pointer
>>dma-buf/fence: Sparse wants __rcu on the object itself
>>
>> Ville Syrjälä (2):
>>drm/syncobj: Use proper methods for accessing rcu protected pointers
>>dma-buf: Use rcu_assign_pointer() to set rcu protected pointers

For patches 2 (with Daniel's minor comment) and 4, please feel free to add my
Acked-by: Sumit Semwal >
>>   drivers/dma-buf/reservation.c |  2 +-
>>   drivers/gpu/drm/drm_syncobj.c | 11 +++
>>   include/drm/drm_syncobj.h |  2 +-
>>   include/linux/dma-fence.h |  2 +-
>>   4 files changed, 10 insertions(+), 7 deletions(-)
>>
>

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