[PATCH 3/3] RFC: dts: ifc6410: add splash screen carveout

[Emil Velikov]

On 3 March 2015 at 20:04, Rob Clark  wrote:
> Add a reserved-memory region for bootloader splashscreen, and assign it
> to the display device, so that drm/msm can take over the bootloader's
> splashscreen.
>
Hi Rob,

Rather silly question - does the bootloader always use/preserve the
same amount of memory regardless of the display's resolution & bpp ?
If not would this patch work in such cases ?

Cheers
Emil

[PATCH] i915: Add I915_PARAM_REVISION

[Emil Velikov]

On 4 March 2015 at 18:02, Daniel Vetter  wrote:
> On Wed, Mar 04, 2015 at 02:37:09PM +, Neil Roberts wrote:
>> This is a new parameter for DRM_I915_GETPARAM to query the GPU
>> revision.
>>
>> Signed-off-by: Neil Roberts 
>> ---
>>  include/drm/i915_drm.h | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
>> index 15dd01d..943a9d9 100644
>> --- a/include/drm/i915_drm.h
>> +++ b/include/drm/i915_drm.h
>> @@ -340,6 +340,7 @@ typedef struct drm_i915_irq_wait {
>>  #define I915_PARAM_HAS_EXEC_HANDLE_LUT   26
>>  #define I915_PARAM_HAS_WT 27
>>  #define I915_PARAM_CMD_PARSER_VERSION 28
>
> This gap isn't good and means you've manually added this line. Please use
> the make headers_install target from the kernel and update the entire
> i915_drm.h file from the generated one.
>
Up-to recently it was broken, so I'm guessing that no-one ran it since
the great uapi header move.
Would be nice if we can go back to using it - after all that's why
I've fixed it :-)

-Emil

[PATCH 3/5] drm: jz4780: Add DRM driver for Ingenic JZ4780

[Paul Bolle]

Zubair Lutfullah Kakakhel schreef op wo 04-03-2015 om 15:37 [+]:
> --- /dev/null
> +++ b/drivers/gpu/drm/jz4780/Makefile
> @@ -0,0 +1,10 @@
> +ccflags-y := -Iinclude/drm
> +ifeq (, $(findstring -W,$(EXTRA_CFLAGS)))
> +
> +endif

What does that do? 

> +jz4780-y := \
> + jz4780_crtc.o \
> + jz4780_drv.o

Please make this one line. 

> +obj-$(CONFIG_DRM_JZ4780) += jz4780.o

> --- /dev/null
> +++ b/drivers/gpu/drm/jz4780/jz4780_drv.c
> @@ -0,0 +1,388 @@
> +/*
> + * Copyright (C) 2015 Imagination Technologies
> + * Author: Zubair Lutfullah Kakakhel 
> + *
> + * DRM driver for Ingenic JZ4780
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published 
> by
> + * the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but 
> WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + */

This states the license is GPL v2. (I think the other files of this
driver carry similar comments.)

> +MODULE_LICENSE("GPL");

So you probably want
MODULE_LICENSE("GPL v2");

here.

Paul Bolle

[PATCH 5/5] drm: bridge/dw_hdmi: add jz4780 support

[Paul Bolle]

Zubair Lutfullah Kakakhel schreef op wo 04-03-2015 om 15:37 [+]:
> --- /dev/null
> +++ b/drivers/gpu/drm/jz4780/dw_hdmi-jz4780.c
> @@ -0,0 +1,234 @@
> +/* Copyright (C) 2011-2013 Freescale Semiconductor, Inc.
> + * Copyright (C) 2015 Imagination Technologies Ltd.
> + *
> + * derived from dw_hdmi-imx.c
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */

This states the license is GPL v2.

> +MODULE_LICENSE("GPL");

So you probably want
MODULE_LICENSE("GPL v2");

here.


Paul Bolle

[Bug 94081] [radeon 3.18 regression] GPU reset recovery fails

[bugzilla-dae...@bugzilla.kernel.org]

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

--- Comment #3 from Jan Vesely  ---
(In reply to Michel Dänzer from comment #2)
> Can you bisect?

It took a while (first bisect found unrelated i915 dispaly commit).
the failure was introduced in:

commit dd7cfd641228abb2669d8d047d5ec377b1835900
Author: Maarten Lankhorst 
Date:   Tue Jan 21 13:07:31 2014 +0100

drm/ttm: kill fence_lock

No users are left, kill it off! :D
Conversion to the reservation api is next on the list, after
that the functionality can be restored with rcu.

Signed-off-by: Maarten Lankhorst 

the commit moves a call to fence get below two "goto cleanup" in error paths,
however, fence_put is left in the cleanup: error target. Moving the fence_put
call to pflip_cleanup fixes the issue.

I've posted a patch.
> 
> (In reply to Jan Vesely from comment #1)
> > here's dmesg output for 3.17 kernel:
> 
> [...]
> 
> > [  249.362280] [drm:r600_ib_test] *ERROR* radeon: fence wait failed (-35).
> > [  249.362281] [drm:radeon_ib_ring_tests] *ERROR* radeon: failed testing IB
> > on GFX ring (-35).
> 
> Actually, this looks like the reset didn't fully work with 3.17 either
> though...

I don't remember seeing this during bisection. This log is from fedora 3.17.8
kernel. I'll check 3.17.8 vanilla and see whether it's fedora specific

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH 1/1] drm/radeon: Fix cleanup error path.

[Jan Vesely]

please ignore this patch, see bugzilla for details.

sorry for the noise.

On Wed, 2015-03-04 at 16:10 -0500, Jan Vesely wrote:
> cleanup: target is called before fence_get
> Fixes hangs on GPU reset on Turks GPU.
> 
> regression introduced by:
> commit dd7cfd641228abb2669d8d047d5ec377b1835900
> Author: Maarten Lankhorst 
> Date:   Tue Jan 21 13:07:31 2014 +0100
> 
> drm/ttm: kill fence_lock
> 
> No users are left, kill it off! :D
> Conversion to the reservation api is next on the list, after
> that the functionality can be restored with rcu.
> 
> Signed-off-by: Maarten Lankhorst 
> 
> CC: stable at vger.kernel.org
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=94081
> Signed-off-by: Jan Vesely 
> ---
>  drivers/gpu/drm/radeon/radeon_display.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/radeon/radeon_display.c 
> b/drivers/gpu/drm/radeon/radeon_display.c
> index 00ead8c..89a8c48 100644
> --- a/drivers/gpu/drm/radeon/radeon_display.c
> +++ b/drivers/gpu/drm/radeon/radeon_display.c
> @@ -573,6 +573,7 @@ vblank_cleanup:
>   drm_vblank_put(crtc->dev, radeon_crtc->crtc_id);
>  
>  pflip_cleanup:
> + fence_put(work->fence);
>   if (unlikely(radeon_bo_reserve(new_rbo, false) != 0)) {
>   DRM_ERROR("failed to reserve new rbo in error path\n");
>   goto cleanup;
> @@ -584,7 +585,6 @@ pflip_cleanup:
>  
>  cleanup:
>   drm_gem_object_unreference_unlocked(>old_rbo->gem_base);
> - fence_put(work->fence);
>   kfree(work);
>   return r;
>  }


-- 
Jan Vesely 
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150304/59303123/attachment.sig>

[PATCH 2/2] drm/exynos: decon: Add support for DECON-EXT

[Ajay kumar]

On Wed, Mar 4, 2015 at 7:44 PM, Andrzej Hajda  wrote:
> On 03/02/2015 11:57 AM, Ajay kumar wrote:
>> On Mon, Mar 2, 2015 at 1:38 PM, Andrzej Hajda  wrote:
>>> On 02/26/2015 04:24 PM, Ajay Kumar wrote:
 * Modify DECON-INT driver to support DECON-EXT.
 * Add a table of porch values needed to set timing registers of DECON-EXT.
 * DECON-EXT supports only H/w Triggered COMMAND mode.
 * DECON-EXT supports only one DMA window(window 1), so modify
   all window management routines to support 2 windows of DECON-INT
   and 1 window of DECON-EXT.

 Signed-off-by: Ajay Kumar 
 ---
  .../devicetree/bindings/video/exynos7-decon.txt|8 +-
  drivers/gpu/drm/exynos/exynos7_drm_decon.c |  229 
 ++--
  include/video/exynos7_decon.h  |   13 ++
  3 files changed, 230 insertions(+), 20 deletions(-)

 diff --git a/Documentation/devicetree/bindings/video/exynos7-decon.txt 
 b/Documentation/devicetree/bindings/video/exynos7-decon.txt
 index f5f9c8d..87350c0 100644
 --- a/Documentation/devicetree/bindings/video/exynos7-decon.txt
 +++ b/Documentation/devicetree/bindings/video/exynos7-decon.txt
 @@ -2,10 +2,14 @@ Device-Tree bindings for Samsung Exynos7 SoC display 
 controller (DECON)

  DECON (Display and Enhancement Controller) is the Display Controller for 
 the
  Exynos7 series of SoCs which transfers the image data from a video memory
 -buffer to an external LCD interface.
 +buffer to an external LCD/HDMI interface.
 +
 +Exynos7 supports DECON-INT for generating video signals for LCD.
 +Exynos7 supports DECON-EXT for generating video signals for HDMI.

  Required properties:
 -- compatible: value should be "samsung,exynos7-decon";
 +- compatible: value should be "samsung,exynos7-decon-int" for DECON-INT;
 +   value should be "samsung,exynos7-decon-ext" for DECON-EXT;

  - reg: physical base address and length of the DECON registers set.

 diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
 b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
 index 63f02e2..9e2d083 100644
 --- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
 +++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
 @@ -41,6 +41,28 @@

  #define WINDOWS_NR   2
>>> Maybe it would be better to rename it to MAX_WINDOWS_NR
>> Ok.
 +#define DECON_EXT_CH_MAPPING 0x432105
>>> I am not familiar with decon, could you explain what exactly
>>> this mapping means and why is it fixed in the driver to this value,
>>> not default one. By the way my specs says bits 0-3 are reserverd
>>> and here it seems you are using them.
>> I reused the value from the code which hardware team shared with me.
>> It tries to map a input hardware channel(IDMA or VPP channel) onto
>> a hardware window in DECON.
>> Channel_N is mapped onto window_N in case of DECON-INT.
>> In case of DECON-EXT, Channel 0 should be mapped to window 1 of DECON-EXT.
>> So, basically for the changes I have made, I should ideally set only
>> bits [4:6] to 0x1,
>> and leave other bits untouched, though modifying other bits wouldn't
>> affect in anyway.
 +
 +enum decon_type {
 + DECON_INT,
 + DECON_EXT,
 +} decon_type;
 +
 +struct decon_driver_data {
 + enum decon_type decon_type;
 + unsigned intnr_windows;
 +};
 +
 +static struct decon_driver_data exynos7_decon_int_driver_data = {
 + .decon_type = DECON_INT,
>>> I wonder if it wouldn't be better to use different fields to describe
>>> each capability/property instead of decon_type. For example
>>> .display_type = EXYNOS_DISPLAY_TYPE_LCD,
>>> .map_channels = 0,
>> Ok, let me list down the differences between INT and EXT.
>> 1) Only h/w triggered command mode for DECON-EXT.
>> 2) Need to feed modified porch values(decon_ext_timings)
>> 3) Input channel to H/w window mapping(WINCHMAP)
>> 4) default_window - 0 for DECON-INT and 1 for DECON-EXT
>>
>> Out of the above differences, the first 3 can somehow be converted
>> to capability/property and embedded into driver_data.
>> But the 4th difference is bothering me.
>> I tried using something like start_window, end_window and tried to make
>> The code common for DECON-INT and DECON-EXT, and it just doesn't work.
>> ex:
>> start_window = 0, end_window = 1 for DECON-INT
>> start_window = 1, end_window = 1 for DECON-EXT
>>
>> When win_commit gets called for window 0 from crtc_commit/plane_commit:
>> Configure start_window(0  for DECON-INT and 1 for DECON-EXT)
>>
>> When win_commit is called from decon_apply, it is called for window 1 also.
>> That time win_commit can skip updating actual window 1.
>> How do I take care of this ambiguity? This case happens with
>> win_disable routine also!
>
> I think clear distinction where are we using hw windows and where sw
> windows 

[PATCH] i915: Add I915_PARAM_REVISION

[Daniel Vetter]

On Wed, Mar 04, 2015 at 02:37:09PM +, Neil Roberts wrote:
> This is a new parameter for DRM_I915_GETPARAM to query the GPU
> revision.
> 
> Signed-off-by: Neil Roberts 
> ---
>  include/drm/i915_drm.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
> index 15dd01d..943a9d9 100644
> --- a/include/drm/i915_drm.h
> +++ b/include/drm/i915_drm.h
> @@ -340,6 +340,7 @@ typedef struct drm_i915_irq_wait {
>  #define I915_PARAM_HAS_EXEC_HANDLE_LUT   26
>  #define I915_PARAM_HAS_WT 27
>  #define I915_PARAM_CMD_PARSER_VERSION 28

This gap isn't good and means you've manually added this line. Please use
the make headers_install target from the kernel and update the entire
i915_drm.h file from the generated one.

Thanks, Daniel

> +#define I915_PARAM_REVISION  32
>  
>  typedef struct drm_i915_getparam {
>   int param;
> -- 
> 1.9.3
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH v4] mode: Retrieve only the current information for a Connector

[Daniel Vetter]

On Wed, Mar 04, 2015 at 01:16:20PM +, Chris Wilson wrote:
> Add a new API that allows the caller to skip any forced probing, which
> may require slow i2c to a remote display, and only report the currently
> active mode and encoder for a Connector. This is often the information
> of interest and is much, much faster than re-retrieving the link status
> and EDIDs, e.g. if the caller only wishes to count the number of active
> outputs.
> 
> v2: Fix error path to avoid double free after a failed GETCONNECTOR
> ioctl.
> 
> v3: Daniel strongly disapproved of my disjoint in behaviour between
> GetConnector and GetConnectorCurrent, and considering how best to make a
> drop in replacement for drmmode_output_init() convinced me keeping the
> API as consistent as possible was the right approach.
> 
> v4: Avoid probing on the second calls to GETCONNECTOR for unconnected
> outputs.
> 
> Signed-off-by: Chris Wilson 
> Cc: Daniel Vetter 
> Cc: Damien Lespiau 
> Cc: David Herrmann 

Reviewed-by: Daniel Vetter 

> ---
>  tests/modeprint/modeprint.c | 18 --
>  xf86drmMode.c   | 23 ---
>  xf86drmMode.h   | 17 +++--
>  3 files changed, 51 insertions(+), 7 deletions(-)
> 
> diff --git a/tests/modeprint/modeprint.c b/tests/modeprint/modeprint.c
> index 6f0d039..514d3ba 100644
> --- a/tests/modeprint/modeprint.c
> +++ b/tests/modeprint/modeprint.c
> @@ -43,6 +43,7 @@
>  
>  #define ARRAY_SIZE(a) (sizeof(a) / sizeof(a[0]))
>  
> +int current;
>  int connectors;
>  int full_props;
>  int edid;
> @@ -272,7 +273,7 @@ int printRes(int fd, drmModeResPtr res)
>  
>   if (connectors) {
>   for (i = 0; i < res->count_connectors; i++) {
> - connector = drmModeGetConnector(fd, res->connectors[i]);
> + connector = (current ? drmModeGetConnectorCurrent : 
> drmModeGetConnector) (fd, res->connectors[i]);
>  
>   if (!connector)
>   printf("Could not get connector %i\n", 
> res->connectors[i]);
> @@ -331,6 +332,7 @@ int printRes(int fd, drmModeResPtr res)
>  
>  void args(int argc, char **argv)
>  {
> + int defaults = 1;
>   int i;
>  
>   fbs = 0;
> @@ -341,32 +343,41 @@ void args(int argc, char **argv)
>   full_modes = 0;
>   full_props = 0;
>   connectors = 0;
> + current = 0;
>  
>   module_name = argv[1];
>  
>   for (i = 2; i < argc; i++) {
>   if (strcmp(argv[i], "-fb") == 0) {
>   fbs = 1;
> + defaults = 0;
>   } else if (strcmp(argv[i], "-crtcs") == 0) {
>   crtcs = 1;
> + defaults = 0;
>   } else if (strcmp(argv[i], "-cons") == 0) {
>   connectors = 1;
>   modes = 1;
> + defaults = 0;
>   } else if (strcmp(argv[i], "-modes") == 0) {
>   connectors = 1;
>   modes = 1;
> + defaults = 0;
>   } else if (strcmp(argv[i], "-full") == 0) {
>   connectors = 1;
>   modes = 1;
>   full_modes = 1;
> + defaults = 0;
>   } else if (strcmp(argv[i], "-props") == 0) {
>   connectors = 1;
>   full_props = 1;
> + defaults = 0;
>   } else if (strcmp(argv[i], "-edids") == 0) {
>   connectors = 1;
>   edid = 1;
> + defaults = 0;
>   } else if (strcmp(argv[i], "-encoders") == 0) {
>   encoders = 1;
> + defaults = 0;
>   } else if (strcmp(argv[i], "-v") == 0) {
>   fbs = 1;
>   edid = 1;
> @@ -376,10 +387,13 @@ void args(int argc, char **argv)
>   full_modes = 1;
>   full_props = 1;
>   connectors = 1;
> + defaults = 0;
> + } else if (strcmp(argv[i], "-current") == 0) {
> + current = 1;
>   }
>   }
>  
> - if (argc == 2) {
> + if (defaults) {
>   fbs = 1;
>   edid = 1;
>   crtcs = 1;
> diff --git a/xf86drmMode.c b/xf86drmMode.c
> index 9ea8fe7..57d1dc9 100644
> --- a/xf86drmMode.c
> +++ b/xf86drmMode.c
> @@ -476,19 +476,23 @@ drmModeEncoderPtr drmModeGetEncoder(int fd, uint32_t 
> encoder_id)
>  /*
>   * Connector manipulation
>   */
> -
> -drmModeConnectorPtr drmModeGetConnector(int fd, uint32_t connector_id)
> +static drmModeConnectorPtr
> +_drmModeGetConnector(int fd, uint32_t connector_id, int probe)
>  {
>   struct drm_mode_get_connector conn, counts;
>   drmModeConnectorPtr r = NULL;
>  
> -retry:
>   memclear(conn);
>   conn.connector_id = connector_id;
> + if (!probe) {
> 

[pull] drm/msm: fixes for 4.0

[Rob Clark]

opps, lets try that again on top of drm-fixes instead of drm-next..

---

Fixup some fallout of the fallout of atomic dpms, few mdp5 cursor
fixes, fix a leak in error path, and some fixes for kexec


The following changes since commit ed9ed50ccc2c16690b921171c809f6f15255ac65:

  Revert "drm/rockchip: Flip select/depends in Kconfig" (2015-03-03
21:11:34 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~robclark/linux msm-fixes-4.0

for you to fetch changes up to aa80a4a5190e697a6945849ab36fa7dabca815f3:

  drm/msm: kexec fixes (2015-03-04 18:23:41 -0500)


Laurent Pinchart (1):
  drm/msm/atomic: Don't leak atomic commit object when commit fails

Rob Clark (3):
  drm/msm/mdp5: fix cursor ROI
  drm/msm/mdp5: fix cursor blending
  drm/msm: kexec fixes

Stephane Viau (3):
  drm/msm/mdp5: fixup "drm/msm: fix fallout of atomic dpms changes"
  drm/msm: update generated headers (add 6th lm.base entry)
  drm/msm/mdp5: Avoid flushing registers when CRTC is disabled

 drivers/gpu/drm/msm/mdp/mdp4/mdp4_irq.c |  5 ++
 drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h | 15 ++---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c| 99 ++---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c |  6 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_irq.c |  5 ++
 drivers/gpu/drm/msm/msm_atomic.c|  4 +-
 6 files changed, 81 insertions(+), 53 deletions(-)

[PATCH 2/2] drm/udl: implement cursor.

[Haixia Shi]

Signed-off-by: Haixia Shi 
Reviewed-by: Stéphane Marchesin 
Tested-by: Haixia Shi 
---
 drivers/gpu/drm/udl/Makefile   |   2 +-
 drivers/gpu/drm/udl/udl_cursor.c   | 156 +
 drivers/gpu/drm/udl/udl_cursor.h   |  46 +++
 drivers/gpu/drm/udl/udl_drv.h  |   4 +
 drivers/gpu/drm/udl/udl_fb.c   |  31 
 drivers/gpu/drm/udl/udl_gem.c  |   3 +
 drivers/gpu/drm/udl/udl_main.c |  10 +++
 drivers/gpu/drm/udl/udl_modeset.c  |  45 +++
 drivers/gpu/drm/udl/udl_transfer.c |  36 -
 9 files changed, 317 insertions(+), 16 deletions(-)
 create mode 100644 drivers/gpu/drm/udl/udl_cursor.c
 create mode 100644 drivers/gpu/drm/udl/udl_cursor.h

diff --git a/drivers/gpu/drm/udl/Makefile b/drivers/gpu/drm/udl/Makefile
index 195bcac..67ccab4 100644
--- a/drivers/gpu/drm/udl/Makefile
+++ b/drivers/gpu/drm/udl/Makefile
@@ -1,6 +1,6 @@

 ccflags-y := -Iinclude/drm

-udl-y := udl_drv.o udl_modeset.o udl_connector.o udl_encoder.o udl_main.o 
udl_fb.o udl_transfer.o udl_gem.o udl_dmabuf.o
+udl-y := udl_drv.o udl_modeset.o udl_connector.o udl_encoder.o udl_main.o 
udl_fb.o udl_transfer.o udl_gem.o udl_dmabuf.o udl_cursor.o

 obj-$(CONFIG_DRM_UDL) := udl.o
diff --git a/drivers/gpu/drm/udl/udl_cursor.c b/drivers/gpu/drm/udl/udl_cursor.c
new file mode 100644
index 000..3b38ef5
--- /dev/null
+++ b/drivers/gpu/drm/udl/udl_cursor.c
@@ -0,0 +1,156 @@
+/*
+ * udl_cursor.c
+ *
+ * Copyright (c) 2015 The Chromium OS Authors
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see .
+ */
+
+#include 
+#include 
+
+#include "udl_cursor.h"
+#include "udl_drv.h"
+
+#define UDL_CURSOR_W 64
+#define UDL_CURSOR_H 64
+#define UDL_CURSOR_BUF (UDL_CURSOR_W * UDL_CURSOR_H)
+
+/*
+ * UDL drm cursor private structure.
+ */
+struct udl_cursor {
+   uint32_t buffer[UDL_CURSOR_BUF];
+   bool enabled;
+   int x;
+   int y;
+};
+
+int udl_cursor_alloc(struct udl_cursor **cursor)
+{
+   struct udl_cursor *new_cursor = kzalloc(sizeof(struct udl_cursor),
+   GFP_KERNEL);
+   if (!new_cursor)
+   return -ENOMEM;
+   *cursor = new_cursor;
+   return 0;
+}
+
+void udl_cursor_free(struct udl_cursor *cursor)
+{
+   BUG_ON(!cursor);
+   kfree(cursor);
+}
+
+void udl_cursor_copy(struct udl_cursor *dst, struct udl_cursor *src)
+{
+   memcpy(dst, src, sizeof(struct udl_cursor));
+}
+
+bool udl_cursor_enabled(struct udl_cursor *cursor)
+{
+   return cursor->enabled;
+}
+
+void udl_cursor_get_hline(struct udl_cursor *cursor, int x, int y,
+   struct udl_cursor_hline *hline)
+{
+   if (!cursor || !cursor->enabled ||
+   x >= cursor->x + UDL_CURSOR_W ||
+   y < cursor->y || y >= cursor->y + UDL_CURSOR_H) {
+   hline->buffer = NULL;
+   return;
+   }
+
+   hline->buffer = >buffer[UDL_CURSOR_W * (y - cursor->y)];
+   hline->width = UDL_CURSOR_W;
+   hline->offset = x - cursor->x;
+}
+
+/*
+ * Return pre-computed cursor blend value defined as:
+ * R: 5 bits (bit 0:4)
+ * G: 6 bits (bit 5:10)
+ * B: 5 bits (bit 11:15)
+ * A: 7 bits (bit 16:22)
+ */
+static uint32_t cursor_blend_val32(uint32_t pix)
+{
+   /* range of alpha_scaled is 0..64 */
+   uint32_t alpha_scaled = ((pix >> 24) * 65) >> 8;
+   return ((pix >> 3) & 0x1f) |
+   ((pix >> 5) & 0x7e0) |
+   ((pix >> 8) & 0xf800) |
+   (alpha_scaled << 16);
+}
+
+static int udl_cursor_download(struct udl_cursor *cursor,
+   struct drm_gem_object *obj)
+{
+   struct udl_gem_object *udl_gem_obj = to_udl_bo(obj);
+   uint32_t *src_ptr, *dst_ptr;
+   size_t i;
+
+   int ret = udl_gem_vmap(udl_gem_obj);
+   if (ret != 0) {
+   DRM_ERROR("failed to vmap cursor\n");
+   return ret;
+   }
+
+   src_ptr = udl_gem_obj->vmapping;
+   dst_ptr = cursor->buffer;
+   for (i = 0; i < UDL_CURSOR_BUF; ++i)
+   dst_ptr[i] = cursor_blend_val32(le32_to_cpu(src_ptr[i]));
+   return 0;
+}
+
+int udl_cursor_set(struct drm_crtc *crtc, struct drm_file *file,
+   uint32_t handle, uint32_t width, uint32_t height,
+   struct udl_cursor *cursor)
+{
+   if (handle) {
+   struct drm_gem_object *obj;
+   int err;
+   /* Currently we only 

[PATCH 1/2] drm/udl: make page flips asynchronous.

[Haixia Shi]

This also limits the maximum frequency of page flips by the vrefresh rate.

Signed-off-by: Haixia Shi 
Reviewed-by: Stéphane Marchesin 
Tested-by: Haixia Shi 
---
 drivers/gpu/drm/udl/udl_drv.h |   3 +
 drivers/gpu/drm/udl/udl_modeset.c | 129 ++
 2 files changed, 119 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/udl/udl_drv.h b/drivers/gpu/drm/udl/udl_drv.h
index 80adbac..b1e9fae 100644
--- a/drivers/gpu/drm/udl/udl_drv.h
+++ b/drivers/gpu/drm/udl/udl_drv.h
@@ -47,6 +47,7 @@ struct urb_list {
 };

 struct udl_fbdev;
+struct udl_flip_queue;

 struct udl_device {
struct device *dev;
@@ -65,6 +66,8 @@ struct udl_device {
atomic_t bytes_identical; /* saved effort with backbuffer comparison */
atomic_t bytes_sent; /* to usb, after compression including overhead */
atomic_t cpu_kcycles_used; /* transpired during pixel processing */
+
+   struct udl_flip_queue *flip_queue;
 };

 struct udl_gem_object {
diff --git a/drivers/gpu/drm/udl/udl_modeset.c 
b/drivers/gpu/drm/udl/udl_modeset.c
index 677190a6..f3804b4 100644
--- a/drivers/gpu/drm/udl/udl_modeset.c
+++ b/drivers/gpu/drm/udl/udl_modeset.c
@@ -303,6 +303,16 @@ udl_pipe_set_base(struct drm_crtc *crtc, int x, int y,
 }
 #endif

+struct udl_flip_queue {
+   struct mutex lock;
+   struct workqueue_struct *wq;
+   struct delayed_work work;
+   struct drm_crtc *crtc;
+   struct drm_pending_vblank_event *event;
+   u64 flip_time;  /* in jiffies */
+   u64 vblank_interval;  /* in jiffies */
+};
+
 static int udl_crtc_mode_set(struct drm_crtc *crtc,
   struct drm_display_mode *mode,
   struct drm_display_mode *adjusted_mode,
@@ -313,6 +323,7 @@ static int udl_crtc_mode_set(struct drm_crtc *crtc,
struct drm_device *dev = crtc->dev;
struct udl_framebuffer *ufb = to_udl_fb(crtc->primary->fb);
struct udl_device *udl = dev->dev_private;
+   struct udl_flip_queue *flip_queue = udl->flip_queue;
char *buf;
char *wrptr;
int color_depth = 0;
@@ -347,6 +358,13 @@ static int udl_crtc_mode_set(struct drm_crtc *crtc,
ufb->active_16 = true;
udl->mode_buf_len = wrptr - buf;

+   /* update flip queue vblank interval */
+   if (flip_queue) {
+   mutex_lock(_queue->lock);
+   flip_queue->vblank_interval = HZ / mode->vrefresh;
+   mutex_unlock(_queue->lock);
+   }
+
/* damage all of it */
udl_handle_damage(ufb, 0, 0, ufb->base.width, ufb->base.height);
return 0;
@@ -364,29 +382,82 @@ static void udl_crtc_destroy(struct drm_crtc *crtc)
kfree(crtc);
 }

+static void udl_sched_page_flip(struct work_struct *work)
+{
+   struct udl_flip_queue *flip_queue =
+   container_of(container_of(work, struct delayed_work, work),
+   struct udl_flip_queue, work);
+   struct drm_crtc *crtc;
+   struct drm_device *dev;
+   struct drm_pending_vblank_event *event;
+   struct drm_framebuffer *fb;
+
+   mutex_lock(_queue->lock);
+   crtc = flip_queue->crtc;
+   dev = crtc->dev;
+   event = flip_queue->event;
+   fb = crtc->primary->fb;
+   flip_queue->event = NULL;
+   mutex_unlock(_queue->lock);
+
+   if (fb)
+   udl_handle_damage(to_udl_fb(fb), 0, 0, fb->width, fb->height);
+   if (event) {
+   unsigned long flags;
+   spin_lock_irqsave(>event_lock, flags);
+   drm_send_vblank_event(dev, 0, event);
+   spin_unlock_irqrestore(>event_lock, flags);
+   }
+}
+
 static int udl_crtc_page_flip(struct drm_crtc *crtc,
  struct drm_framebuffer *fb,
  struct drm_pending_vblank_event *event,
  uint32_t page_flip_flags)
 {
-   struct udl_framebuffer *ufb = to_udl_fb(fb);
struct drm_device *dev = crtc->dev;
-   unsigned long flags;
+   struct udl_device *udl = dev->dev_private;
+   struct udl_flip_queue *flip_queue = udl->flip_queue;

-   struct drm_framebuffer *old_fb = crtc->primary->fb;
-   if (old_fb) {
-   struct udl_framebuffer *uold_fb = to_udl_fb(old_fb);
-   uold_fb->active_16 = false;
+   if (!flip_queue || !flip_queue->wq) {
+   DRM_ERROR("Uninitialized page flip queue\n");
+   return -ENOMEM;
}
-   ufb->active_16 = true;

-   udl_handle_damage(ufb, 0, 0, fb->width, fb->height);
+   mutex_lock(_queue->lock);
+
+   flip_queue->crtc = crtc;
+   if (fb) {
+   struct drm_framebuffer *old_fb;
+   struct udl_framebuffer *ufb;
+   ufb = to_udl_fb(fb);
+   old_fb = crtc->primary->fb;
+   if (old_fb) {
+   struct udl_framebuffer *uold_fb = to_udl_fb(old_fb);
+  

[PATCH 3/3] RFC: dts: ifc6410: add splash screen carveout

[Rob Clark]

On Wed, Mar 4, 2015 at 6:10 PM, Emil Velikov  
wrote:
> On 3 March 2015 at 20:04, Rob Clark  wrote:
>> Add a reserved-memory region for bootloader splashscreen, and assign it
>> to the display device, so that drm/msm can take over the bootloader's
>> splashscreen.
>>
> Hi Rob,
>
> Rather silly question - does the bootloader always use/preserve the
> same amount of memory regardless of the display's resolution & bpp ?
> If not would this patch work in such cases ?
>

In most cases, the bootloader puts up a splash screen on built-in lcd
panel, which sort of makes the problem easier (fixed resolution).  For
external display, I think you just have to size it for worst-case
(largest) resolution.

(ofc it is RFC since I was hoping to get comments if anyone has better
suggestions.. probably should have cc'd more people ;-))

BR,
-R

> Cheers
> Emil

[PATCH 1/2] drm/exynos: hdmi: Add support for Exynos7 HDMI

[Ajay kumar]

On Wed, Mar 4, 2015 at 4:02 PM, Andrzej Hajda  wrote:
> On 03/04/2015 10:54 AM, Ajay kumar wrote:
>> On Wed, Mar 4, 2015 at 2:30 PM, Andrzej Hajda  wrote:
>>> On 03/02/2015 09:40 AM, Ajay kumar wrote:
 Hi Andrej,

 On Fri, Feb 27, 2015 at 4:18 PM, Andrzej Hajda  
 wrote:
> Hi Ajay,
>
> Thanks for the patch.
 Thanks for reviewing the patch.

> On 02/26/2015 04:24 PM, Ajay Kumar wrote:
>> Modify the exynos HDMI driver to support Exynos7 HDMI 1.4.
>> * Add phy configs for Exynos7.
>> * Exynos7 has a different clock structure for HDMI,
>>   so introduce the new clocks.
>> * Add sysreg support to enable HDMI SYSREG on Exynos7.
>> * Exynos7 based boards need a DCDC_EN and LS_EN pins
>>   for powering up HDMI. Add support for that too.
>>
>> Signed-off-by: Ajay Kumar 
>> ---
>>  .../devicetree/bindings/video/exynos_hdmi.txt  |   21 +-
>>  drivers/gpu/drm/exynos/exynos_hdmi.c   |  252 
>> 
>>  drivers/gpu/drm/exynos/regs-hdmi.h |4 +
>>  3 files changed, 231 insertions(+), 46 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt 
>> b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>> index 1fd8cf9..bb22a60 100644
>> --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>> +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>> @@ -6,6 +6,7 @@ Required properties:
>>   2) "samsung,exynos4210-hdmi"
>>   3) "samsung,exynos4212-hdmi"
>>   4) "samsung,exynos5420-hdmi"
>> + 5) "samsung,exynos7-hdmi"
> Why not "samsung,exynos7420-hdmi" ?
> What compatible will you use for Exynos7430 or higher chip number?
 I will leave this decision to Inki Dae or Kukjin.

>>  - reg: physical base address of the hdmi and length of memory mapped
>>   region.
>>  - interrupts: interrupt number to the cpu.
>> @@ -15,21 +16,33 @@ Required properties:
>>   c) optional flags and pull up/down.
>>  - clocks: list of clock IDs from SoC clock driver.
>>   a) hdmi: Gate of HDMI IP bus clock.
>> - b) sclk_hdmi: Gate of HDMI special clock.
>> - c) sclk_pixel: Pixel special clock, one of the two possible inputs 
>> of
>> + HDMI clocks necessary for non exynos7:
>> +  b) sclk_hdmi: Gate of HDMI special clock.
>> +  c) sclk_pixel: Pixel special clock, one of the two possible 
>> inputs of
>>   HDMI clock mux.
>> - d) sclk_hdmiphy: HDMI PHY clock output, one of two possible inputs 
>> of
>> +  d) sclk_hdmiphy: HDMI PHY clock output, one of two possible 
>> inputs of
>>   HDMI clock mux.
>> - e) mout_hdmi: It is required by the driver to switch between the 2
>> +  e) mout_hdmi: It is required by the driver to switch between the 2
>>   parents i.e. sclk_pixel and sclk_hdmiphy. If hdmiphy is 
>> stable
>>   after configuration, parent is set to sclk_hdmiphy else
>>   sclk_pixel.
>> + HDMI clocks necessary for Exynos7:
>> +  b) pclk_hdmiphy: Gate to HDMIPHY clock.
> According to specs there is also pclk_hdmi, why do you specify only this
> one?
 Right, I have reused "hdmi" gating clock for pclk_hdmi. That is why I have
 left "hdmi" clock as common for exynos7 and non-exynos7.
>>> IMO it would be better to use separate entry for pclk_hdmi.
>> Ok.
>>
>> +  c) hdmi_pixel: Gate clock of MUX output for I_PIXEL_CLK.
>> +  d) hdmi_tmds: Gate clock of MUX output for I_TMDS_CLK.
> According to specs these clocks should be named i_pixel_clk and
> i_tmds_clk, shouldn't they?
 I actually took these changes from an "internal" code(non-DRM).
 The original author used these names, and I just carried the same names. :)

>>  - clock-names: aliases as per driver requirements for above clock IDs:
>>   "hdmi", "sclk_hdmi", "sclk_pixel", "sclk_hdmiphy" and "mout_hdmi".
>>  - ddc: phandle to the hdmi ddc node
>>  - phy: phandle to the hdmi phy node
>>  - samsung,syscon-phandle: phandle for system controller node for PMU.
>>
>> +Only for Exynos7(when compatible = "samsung,exynos7-hdmi"):
>> +- samsung,sysreg-phandle: phandle for system controller node for SYSREG 
>> block.
>> +
>> +Optional properties:
>> +- dcdc-gpios: OF device-tree gpio specification for HDMI_DCDC_EN pin.
>> +- lsen-gpios: OF device-tree gpio specification for HDMI_LS_EN pin.
> What is purpose of these gpios?
 These 2 GPIOs need to be enabled to powerup HDMI on exynos7-espresso board.
 Other boards need not provide the GPIO.
>>> HDMI is internal IP of SoC, so it is rather not configurable via pins.
>>> Pin names suggests they are for DC-DC converter and level shifter, I guess
>>> 

[pull] drm/msm: fixes for 4.0

[Rob Clark]

Fixup some fallout of the fallout of atomic dpms, few mdp5 cursor
fixes, fix a leak in error path, and some fixes for kexec

BR,
-R

The following changes since commit 329414c4e7b7506fe3eab545b3fc9e44b7f28a10:

  Merge tag 'topic/drm-misc-2015-02-25' of
git://anongit.freedesktop.org/drm-intel into drm-next (2015-02-26
10:32:55 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~robclark/linux msm-fixes-4.0

for you to fetch changes up to afe37e5764bfe2c249c58990029a568d4209eaf7:

  drm/msm: kexec fixes (2015-03-04 16:45:14 -0500)


Laurent Pinchart (1):
  drm/msm/atomic: Don't leak atomic commit object when commit fails

Rob Clark (3):
  drm/msm/mdp5: fix cursor ROI
  drm/msm/mdp5: fix cursor blending
  drm/msm: kexec fixes

Stephane Viau (3):
  drm/msm/mdp5: fixup "drm/msm: fix fallout of atomic dpms changes"
  drm/msm: update generated headers (add 6th lm.base entry)
  drm/msm/mdp5: Avoid flushing registers when CRTC is disabled

 drivers/gpu/drm/msm/mdp/mdp4/mdp4_irq.c |  5 ++
 drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h | 15 ++---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c| 99 ++---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c |  6 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_irq.c |  5 ++
 drivers/gpu/drm/msm/msm_atomic.c|  4 +-
 6 files changed, 81 insertions(+), 53 deletions(-)

[PATCH] vgaarb: Stub vga_set_legacy_decoding()

[Alex Williamson]

On Thu, 2015-03-05 at 09:43 +1000, Dave Airlie wrote:
> On 25 February 2015 at 02:16, Alex Williamson
>  wrote:
> > vga_set_legacy_decoding() is defined in drivers/gpu/vga/vgaarb.c,
> > which is only compiled with CONFIG_VGA_ARB.  A caller would
> > therefore get an undefined symbol if the VGA arbiter is not
> > enabled.
> 
> Acked-by: Dave Airlie 

Thanks Dave!  I'll route this through my tree with the commit that uses
it.

> > Signed-off-by: Alex Williamson 
> > ---
> >
> > I'd like to use this function from vfio-pci to opt-out VGA devices
> > from arbitration if vfio-pci VGA support is disabled.  This helps to
> > keep DRI2 enabled on the host if additional GPUs are installed for
> > VMs and used without VGA support.  I can pull this change in through
> > my tree if someone wants to provide just an ack.  Thanks!
> >
> >  include/linux/vgaarb.h |5 +
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/include/linux/vgaarb.h b/include/linux/vgaarb.h
> > index c37bd4d..8c3b412 100644
> > --- a/include/linux/vgaarb.h
> > +++ b/include/linux/vgaarb.h
> > @@ -65,8 +65,13 @@ struct pci_dev;
> >   * out of the arbitration process (and can be safe to take
> >   * interrupts at any time.
> >   */
> > +#if defined(CONFIG_VGA_ARB)
> >  extern void vga_set_legacy_decoding(struct pci_dev *pdev,
> > unsigned int decodes);
> > +#else
> > +static inline void vga_set_legacy_decoding(struct pci_dev *pdev,
> > +  unsigned int decodes) { };
> > +#endif
> >
> >  /**
> >   * vga_get - acquire & locks VGA resources
> >
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4] drm/vgem: implement virtual GEM

[Zach Reizner]

This patch implements the virtual GEM driver with PRIME sharing which
allows vgem to import a gem object from other drivers for the purpose
of mmap-ing them to userspace. The mmap is done using the mmap
operation exported by other drivers.

v2: remove platform_device and do not attach to dma bufs
v3: use drm helpers for get/put pages
v4: correct dumb create pitch

Reviewed-by: Rob Clark  (v3)
Reviewed-by: Stéphane Marchesin  (v3)
Signed-off-by: Adam Jackson 
Signed-off-by: Ben Widawsky 
Signed-off-by: Zach Reizner 
---
 drivers/gpu/drm/Kconfig |   9 +
 drivers/gpu/drm/Makefile|   1 +
 drivers/gpu/drm/vgem/Makefile   |   4 +
 drivers/gpu/drm/vgem/vgem_dma_buf.c |  94 ++
 drivers/gpu/drm/vgem/vgem_drv.c | 364 
 drivers/gpu/drm/vgem/vgem_drv.h |  57 ++
 6 files changed, 529 insertions(+)
 create mode 100644 drivers/gpu/drm/vgem/Makefile
 create mode 100644 drivers/gpu/drm/vgem/vgem_dma_buf.c
 create mode 100644 drivers/gpu/drm/vgem/vgem_drv.c
 create mode 100644 drivers/gpu/drm/vgem/vgem_drv.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 151a050..47f2ce8 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -165,6 +165,15 @@ config DRM_SAVAGE
  Choose this option if you have a Savage3D/4/SuperSavage/Pro/Twister
  chipset. If M is selected the module will be called savage.

+config DRM_VGEM
+   tristate "Virtual GEM provider"
+   depends on DRM
+   help
+ Choose this option to get a virtual graphics memory manager,
+ as used by Mesa's software renderer for enhanced performance.
+ If M is selected the module will be called vgem.
+
+
 source "drivers/gpu/drm/exynos/Kconfig"

 source "drivers/gpu/drm/rockchip/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 2c239b9..7d4944e 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -48,6 +48,7 @@ obj-$(CONFIG_DRM_SIS)   += sis/
 obj-$(CONFIG_DRM_SAVAGE)+= savage/
 obj-$(CONFIG_DRM_VMWGFX)+= vmwgfx/
 obj-$(CONFIG_DRM_VIA)  +=via/
+obj-$(CONFIG_DRM_VGEM) += vgem/
 obj-$(CONFIG_DRM_NOUVEAU) +=nouveau/
 obj-$(CONFIG_DRM_EXYNOS) +=exynos/
 obj-$(CONFIG_DRM_ROCKCHIP) +=rockchip/
diff --git a/drivers/gpu/drm/vgem/Makefile b/drivers/gpu/drm/vgem/Makefile
new file mode 100644
index 000..1055cb7
--- /dev/null
+++ b/drivers/gpu/drm/vgem/Makefile
@@ -0,0 +1,4 @@
+ccflags-y := -Iinclude/drm
+vgem-y := vgem_drv.o vgem_dma_buf.o
+
+obj-$(CONFIG_DRM_VGEM) += vgem.o
diff --git a/drivers/gpu/drm/vgem/vgem_dma_buf.c 
b/drivers/gpu/drm/vgem/vgem_dma_buf.c
new file mode 100644
index 000..0254438
--- /dev/null
+++ b/drivers/gpu/drm/vgem/vgem_dma_buf.c
@@ -0,0 +1,94 @@
+/*
+ * Copyright © 2012 Intel Corporation
+ * Copyright © 2014 The Chromium OS Authors
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ *Ben Widawsky 
+ *
+ */
+
+#include 
+#include "vgem_drv.h"
+
+struct sg_table *vgem_gem_prime_get_sg_table(struct drm_gem_object *gobj)
+{
+   struct drm_vgem_gem_object *obj = to_vgem_bo(gobj);
+   BUG_ON(obj->pages == NULL);
+
+   return drm_prime_pages_to_sg(obj->pages, obj->base.size / PAGE_SIZE);
+}
+
+int vgem_gem_prime_pin(struct drm_gem_object *gobj)
+{
+   struct drm_vgem_gem_object *obj = to_vgem_bo(gobj);
+   return vgem_gem_get_pages(obj);
+}
+
+void vgem_gem_prime_unpin(struct drm_gem_object *gobj)
+{
+   struct drm_vgem_gem_object *obj = to_vgem_bo(gobj);
+   vgem_gem_put_pages(obj);
+}
+
+void *vgem_gem_prime_vmap(struct drm_gem_object *gobj)
+{
+   struct drm_vgem_gem_object *obj = to_vgem_bo(gobj);
+   BUG_ON(obj->pages == NULL);
+
+   return vmap(obj->pages, obj->base.size / PAGE_SIZE, 0, PAGE_KERNEL);
+}
+
+void vgem_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr)
+{
+   vunmap(vaddr);
+}
+
+struct 

[PATCH 1/1] drm/radeon: Fix cleanup error path.

[Jan Vesely]

cleanup: target is called before fence_get
Fixes hangs on GPU reset on Turks GPU.

regression introduced by:
commit dd7cfd641228abb2669d8d047d5ec377b1835900
Author: Maarten Lankhorst 
Date:   Tue Jan 21 13:07:31 2014 +0100

drm/ttm: kill fence_lock

No users are left, kill it off! :D
Conversion to the reservation api is next on the list, after
that the functionality can be restored with rcu.

Signed-off-by: Maarten Lankhorst 

CC: stable at vger.kernel.org
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=94081
Signed-off-by: Jan Vesely 
---
 drivers/gpu/drm/radeon/radeon_display.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_display.c 
b/drivers/gpu/drm/radeon/radeon_display.c
index 00ead8c..89a8c48 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -573,6 +573,7 @@ vblank_cleanup:
drm_vblank_put(crtc->dev, radeon_crtc->crtc_id);

 pflip_cleanup:
+   fence_put(work->fence);
if (unlikely(radeon_bo_reserve(new_rbo, false) != 0)) {
DRM_ERROR("failed to reserve new rbo in error path\n");
goto cleanup;
@@ -584,7 +585,6 @@ pflip_cleanup:

 cleanup:
drm_gem_object_unreference_unlocked(>old_rbo->gem_base);
-   fence_put(work->fence);
kfree(work);
return r;
 }
-- 
2.1.0

[PATCH 1/3] drm/layerscape: Add fsl dcu DRM driver

[Stefan Agner]

On 2015-02-13 12:03, Jianwei Wang wrote:
> This patch add support for Two Dimensional Animation and Compositing
> Engine (2D-ACE) on the Freescale LS102x SoCs.
> 
> 2D-ACE is a Freescale display controller. It supports at most four
> plane and provide an hardware cursor.
> 
> This is a simplified version, only a primary plane, a fb created for
> fbdev, a crtc, a connector for TFT LCD panel, an encoder, and the
> encoder is not in use. Now this drver support fbdev only.

Hi,

Do you know if that driver also works on Vybrid devices? Vybrid has also
DCU4 module with 2D-ACE functionality, also the registers look pretty
similar. I was thinking about creating a driver for Vybrid anyway...

Some remarks below...


> 
> Signed-off-by: Alison Wang 
> Signed-off-by: Xiubo Li 
> Signed-off-by: Jianwei Wang 
> ---
>  .../devicetree/bindings/video/fsl,dcfb.txt |  50 +++
>  drivers/gpu/drm/Kconfig|   2 +
>  drivers/gpu/drm/Makefile   |   1 +
>  drivers/gpu/drm/fsl/Kconfig|  17 +
>  drivers/gpu/drm/fsl/Makefile   |   7 +
>  drivers/gpu/drm/fsl/fsl_dcu_drm_crtc.c | 412 
> +
>  drivers/gpu/drm/fsl/fsl_dcu_drm_crtc.h |  40 ++
>  drivers/gpu/drm/fsl/fsl_dcu_drm_drv.c  | 323 
>  drivers/gpu/drm/fsl/fsl_dcu_drm_drv.h  | 167 +
>  drivers/gpu/drm/fsl/fsl_dcu_drm_fbdev.c|  43 +++
>  drivers/gpu/drm/fsl/fsl_dcu_drm_kms.c  |  45 +++
>  drivers/gpu/drm/fsl/fsl_dcu_drm_kms.h  |  22 ++
>  drivers/gpu/drm/fsl/fsl_dcu_drm_plane.c| 124 +++
>  drivers/gpu/drm/fsl/fsl_dcu_drm_plane.h|  28 ++
>  14 files changed, 1281 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/video/fsl,dcfb.txt
>  create mode 100644 drivers/gpu/drm/fsl/Kconfig
>  create mode 100644 drivers/gpu/drm/fsl/Makefile
>  create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_crtc.c
>  create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_crtc.h
>  create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_drv.c
>  create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_drv.h
>  create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_fbdev.c
>  create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_kms.c
>  create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_kms.h
>  create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_plane.c
>  create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_plane.h
> 
> diff --git a/Documentation/devicetree/bindings/video/fsl,dcfb.txt
> b/Documentation/devicetree/bindings/video/fsl,dcfb.txt
> new file mode 100644
> index 000..de7da97
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/fsl,dcfb.txt
> @@ -0,0 +1,50 @@
> +* Freescale Simple Display Controller FB Driver

"FB Driver" probably refers more to a fbdev driver in the Linux kernel
sense, but since this is a DRM driver this is somewhat confusing. The
binding should describe the hardware, in the Vybrid RM mentions the IP
as "Display Control Unit (DCU4)", so maybe

Freescale Display Controller Unit (DCU4) module

Also, instead of using dcfb, I would use somewhat more hardware
describing, e.g. dcu4?

> +
> +Required properties:
> +- compatible:Should be one of "fsl,ls1021a-dcfb".

If the driver also works for Vybrid, be favorable to have a generic
compatible string, e.g. fsl,dcu4?

> +- reg:   Address and length of the register set for dcfb.
> +- clocks:From common clock binding: handle to dcfb clock.
> +- clock-names:   From common clock binding: Shall be "dcfb".
> +- display:   The phandle to display node.
> +
> +Optional properties:
> +- scfg-controller:   The phandle of scfg node.
> +
> +Required properties:
> +- bits-per-pixel:<16> for RGB565,
> + <24> for RGB888,
> + <32> for RGB.
> +
> +Required timing node for dispplay sub-node:
> +- display-timings:   Refer to binding doc display-timing.txt for details.
> +
> +Examples:
> +dcfb: dcfb at 2ce {
> + compatible = "fsl,ls1021a-dcfb";
> + reg = <0x0 0x2ce 0x0 0x1>;
> + clocks = <_clk 0>;
> + clock-names = "dcfb";
> + scfg-controller = <>;
> + display = <>;
> +
> + display: display at 0 {
> + bits-per-pixel = <24>;
> +
> + display-timings {
> + native-mode = <>;
> + timing0: nl4827hc19 {
> + clock-frequency = <1087>;
> + hactive = <480>;
> + vactive = <272>;
> + hback-porch = <2>;
> + hfront-porch = <2>;
> + vback-porch = <1>;
> + vfront-porch = <1>;
> + hsync-len = <41>;
> + vsync-len = <2>;
> +   

[PATCH 5/5] drm: bridge/dw_hdmi: add jz4780 support

[Zubair Lutfullah Kakakhel]

Ingenic JZ4780 hdmi is compatible with dw_hdmi.

Signed-off-by: Zubair Lutfullah Kakakhel 
---
 drivers/gpu/drm/jz4780/Kconfig  |  10 ++
 drivers/gpu/drm/jz4780/Makefile |   1 +
 drivers/gpu/drm/jz4780/dw_hdmi-jz4780.c | 234 
 include/drm/bridge/dw_hdmi.h|   1 +
 4 files changed, 246 insertions(+)
 create mode 100644 drivers/gpu/drm/jz4780/dw_hdmi-jz4780.c

diff --git a/drivers/gpu/drm/jz4780/Kconfig b/drivers/gpu/drm/jz4780/Kconfig
index ae417d1..1dc1ea6 100644
--- a/drivers/gpu/drm/jz4780/Kconfig
+++ b/drivers/gpu/drm/jz4780/Kconfig
@@ -10,3 +10,13 @@ config DRM_JZ4780
  Choose this option if you have an Ingenic JZ4780 SoC with LCDC display
  controller, for example the MIPS Creator CI20 board

+config JZ4780_DW_HDMI
+tristate "JZ4780 specific extensions for Synopsys DW HDMI"
+depends on DRM_JZ4780
+select DRM_DW_HDMI
+help
+ This selects support for JZ4780 SoC specific extensions
+ for the Synopsys DesignWare HDMI driver. If you want to
+ enable HDMI on JZ4780 based SoC, you should select this
+ option.n if you have an Ingenic SoC with LCDC display
+ controller, for example the CI20 board
diff --git a/drivers/gpu/drm/jz4780/Makefile b/drivers/gpu/drm/jz4780/Makefile
index f1c9ee5..57d15b5 100644
--- a/drivers/gpu/drm/jz4780/Makefile
+++ b/drivers/gpu/drm/jz4780/Makefile
@@ -7,4 +7,5 @@ jz4780-y := \
jz4780_crtc.o \
jz4780_drv.o

+obj-$(CONFIG_JZ4780_DW_HDMI) += dw_hdmi-jz4780.o
 obj-$(CONFIG_DRM_JZ4780)   += jz4780.o
diff --git a/drivers/gpu/drm/jz4780/dw_hdmi-jz4780.c 
b/drivers/gpu/drm/jz4780/dw_hdmi-jz4780.c
new file mode 100644
index 000..dd66458
--- /dev/null
+++ b/drivers/gpu/drm/jz4780/dw_hdmi-jz4780.c
@@ -0,0 +1,234 @@
+/* Copyright (C) 2011-2013 Freescale Semiconductor, Inc.
+ * Copyright (C) 2015 Imagination Technologies Ltd.
+ *
+ * derived from dw_hdmi-imx.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct jz4780_hdmi {
+   struct device *dev;
+   struct drm_encoder encoder;
+   struct regmap *regmap;
+};
+
+static const struct dw_hdmi_mpll_config jz4780_mpll_cfg[] = {
+   {
+   4525, {
+   { 0x01e0, 0x },
+   { 0x21e1, 0x },
+   { 0x41e2, 0x }
+   },
+   }, {
+   9250, {
+   { 0x0140, 0x0005 },
+   { 0x2141, 0x0005 },
+   { 0x4142, 0x0005 },
+   },
+   }, {
+   14850, {
+   { 0x00a0, 0x000a },
+   { 0x20a1, 0x000a },
+   { 0x40a2, 0x000a },
+   },
+   }, {
+   ~0UL, {
+   { 0x00a0, 0x000a },
+   { 0x2001, 0x000f },
+   { 0x4002, 0x000f },
+   },
+   }
+};
+
+static const struct dw_hdmi_curr_ctrl jz4780_cur_ctr[] = {
+   /*  pixelclk bpp8bpp10   bpp12 */
+   {
+   5400, { 0x091c, 0x091c, 0x06dc },
+   }, {
+   5840, { 0x091c, 0x06dc, 0x06dc },
+   }, {
+   7200, { 0x06dc, 0x06dc, 0x091c },
+   }, {
+   7425, { 0x06dc, 0x0b5c, 0x091c },
+   }, {
+   11880, { 0x091c, 0x091c, 0x06dc },
+   }, {
+   21600, { 0x06dc, 0x0b5c, 0x091c },
+   }
+};
+
+static const struct dw_hdmi_sym_term jz4780_sym_term[] = {
+   /*pixelclk   symbol   term*/
+   { 14850, 0x800d, 0x0005 },
+   { ~0UL,  0x, 0x }
+};
+
+static void dw_hdmi_jz4780_encoder_disable(struct drm_encoder *encoder)
+{
+}
+
+static bool dw_hdmi_jz4780_encoder_mode_fixup(struct drm_encoder *encoder,
+  const struct drm_display_mode *mode,
+  struct drm_display_mode *adj_mode)
+{
+   return true;
+}
+
+static void dw_hdmi_jz4780_encoder_mode_set(struct drm_encoder *encoder,
+struct drm_display_mode *mode,
+struct drm_display_mode *adj_mode)
+{
+}
+
+static void dw_hdmi_jz4780_encoder_commit(struct drm_encoder *encoder)
+{
+}
+
+static void dw_hdmi_jz4780_encoder_prepare(struct drm_encoder *encoder)
+{
+}
+
+static struct drm_encoder_helper_funcs dw_hdmi_jz4780_encoder_helper_funcs = {
+   .mode_fixup = dw_hdmi_jz4780_encoder_mode_fixup,
+   .mode_set   = dw_hdmi_jz4780_encoder_mode_set,
+   .prepare= dw_hdmi_jz4780_encoder_prepare,
+   .commit = 

[PATCH 4/5] dt-bindings: video: Add jz4780-hdmi binding

[Zubair Lutfullah Kakakhel]

Add DT bindings for the hdmi driver for the Ingenic JZ4780 SoC.

Signed-off-by: Zubair Lutfullah Kakakhel 
---
 .../bindings/video/ingenic-jz4780-hdmi.txt | 41 ++
 1 file changed, 41 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/video/ingenic-jz4780-hdmi.txt

diff --git a/Documentation/devicetree/bindings/video/ingenic-jz4780-hdmi.txt 
b/Documentation/devicetree/bindings/video/ingenic-jz4780-hdmi.txt
new file mode 100644
index 000..f02e59f
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/ingenic-jz4780-hdmi.txt
@@ -0,0 +1,41 @@
+Device-Tree bindings for Ingenic JZ4780 HDMI Transmitter
+
+The HDMI Transmitter in the Ingenic JZ4780 is a Synopsys DesignWare HDMI 1.4
+TX controller IP with accompanying PHY IP.
+
+Required properties:
+ - #address-cells : should be <1>
+ - #size-cells : should be <0>
+ - compatible : should be "ingenic,jz4780-hdmi"
+ - reg-io-width: must be <4>
+ - clocks: phandle to isrf and iahb clocks
+ - clock-names : must be "isrf" and "iahb"
+ - ports: Port nodes with endpoint definitions as defined in
+   Documentation/devicetree/bindings/media/video-interfaces.txt,
+
+Optional properties:
+ - ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
+
+example:
+
+hdmi: hdmi at 1018 {
+   compatible = "ingenic,jz4780-hdmi";
+   reg = <0x1018 0x8000>;
+   reg-io-width = <4>;
+   ddc-i2c-bus = <>;
+   interrupt-parent = <>;
+   interrupts = <3>;
+   clocks = < JZ4780_CLK_HDMI>, < JZ4780_CLK_AHB0>;
+   clock-names = "isfr", "iahb";
+
+   ports {
+   hdmi_in: port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   hdmi_in_lcd: endpoint at 0 {
+   reg = <0>;
+   remote-endpoint = <_out_hdmi>;
+   };
+   };
+   };
+};
-- 
1.9.1

[PATCH 3/5] drm: jz4780: Add DRM driver for Ingenic JZ4780

[Zubair Lutfullah Kakakhel]

Add drm driver for the Ingenic JZ4780 SoC.

Signed-off-by: Zubair Lutfullah Kakakhel 
---
 drivers/gpu/drm/Kconfig  |   2 +
 drivers/gpu/drm/Makefile |   1 +
 drivers/gpu/drm/jz4780/Kconfig   |  12 +
 drivers/gpu/drm/jz4780/Makefile  |  10 +
 drivers/gpu/drm/jz4780/jz4780_crtc.c | 721 +++
 drivers/gpu/drm/jz4780/jz4780_drv.c  | 388 +++
 drivers/gpu/drm/jz4780/jz4780_drv.h  |  84 
 drivers/gpu/drm/jz4780/jz4780_regs.h | 696 +
 8 files changed, 1914 insertions(+)
 create mode 100644 drivers/gpu/drm/jz4780/Kconfig
 create mode 100644 drivers/gpu/drm/jz4780/Makefile
 create mode 100644 drivers/gpu/drm/jz4780/jz4780_crtc.c
 create mode 100644 drivers/gpu/drm/jz4780/jz4780_drv.c
 create mode 100644 drivers/gpu/drm/jz4780/jz4780_drv.h
 create mode 100644 drivers/gpu/drm/jz4780/jz4780_regs.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 151a050..77edd60 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -208,3 +208,5 @@ source "drivers/gpu/drm/sti/Kconfig"
 source "drivers/gpu/drm/amd/amdkfd/Kconfig"

 source "drivers/gpu/drm/imx/Kconfig"
+
+source "drivers/gpu/drm/jz4780/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 2c239b9..f8403e1 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -66,6 +66,7 @@ obj-$(CONFIG_DRM_MSM) += msm/
 obj-$(CONFIG_DRM_TEGRA) += tegra/
 obj-$(CONFIG_DRM_STI) += sti/
 obj-$(CONFIG_DRM_IMX) += imx/
+obj-$(CONFIG_DRM_JZ4780) += jz4780/
 obj-y  += i2c/
 obj-y  += panel/
 obj-y  += bridge/
diff --git a/drivers/gpu/drm/jz4780/Kconfig b/drivers/gpu/drm/jz4780/Kconfig
new file mode 100644
index 000..ae417d1
--- /dev/null
+++ b/drivers/gpu/drm/jz4780/Kconfig
@@ -0,0 +1,12 @@
+config DRM_JZ4780
+   tristate "DRM Support for Ingenic JZ4780 LCDC Display Controller"
+   depends on DRM && OF
+   select DRM_KMS_HELPER
+   select DRM_KMS_FB_HELPER
+   select DRM_KMS_CMA_HELPER
+   select DRM_GEM_CMA_HELPER
+   select VIDEOMODE_HELPERS
+   help
+ Choose this option if you have an Ingenic JZ4780 SoC with LCDC display
+ controller, for example the MIPS Creator CI20 board
+
diff --git a/drivers/gpu/drm/jz4780/Makefile b/drivers/gpu/drm/jz4780/Makefile
new file mode 100644
index 000..f1c9ee5
--- /dev/null
+++ b/drivers/gpu/drm/jz4780/Makefile
@@ -0,0 +1,10 @@
+ccflags-y := -Iinclude/drm
+ifeq (, $(findstring -W,$(EXTRA_CFLAGS)))
+
+endif
+
+jz4780-y := \
+   jz4780_crtc.o \
+   jz4780_drv.o
+
+obj-$(CONFIG_DRM_JZ4780)   += jz4780.o
diff --git a/drivers/gpu/drm/jz4780/jz4780_crtc.c 
b/drivers/gpu/drm/jz4780/jz4780_crtc.c
new file mode 100644
index 000..6f48cfa
--- /dev/null
+++ b/drivers/gpu/drm/jz4780/jz4780_crtc.c
@@ -0,0 +1,721 @@
+/*
+ * Copyright (C) 2014 Imagination Technologies
+ * Author: Zubair Lutfullah Kakakhel 
+ *
+ * LCDC CRTC driver for Ingenic JZ4780, based on the tilcdc driver
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include 
+
+#include "drm_flip_work.h"
+#include 
+
+#include "jz4780_drv.h"
+#include "jz4780_regs.h"
+
+/**
+ * @next: physical address of next frame descriptor
+ * @databuf: physical address of buffer
+ * @id: frame ID
+ * @cmd: DMA command and buffer length(in word)
+ * @offsize: DMA off size, in word
+ * @page_width: DMA page width, in word
+ * @cpos: smart LCD mode is commands' number, other is bpp,
+ * premulti and position of foreground 0, 1
+ * @desc_size: alpha and size of foreground 0, 1
+ */
+struct jz4780_framedesc {
+   uint32_t next;
+   uint32_t databuf;
+   uint32_t id;
+   uint32_t cmd;
+   uint32_t offsize;
+   uint32_t page_width;
+   uint32_t cpos;
+   uint32_t desc_size;
+} __packed;
+
+struct jz4780_crtc {
+   struct drm_crtc base;
+   struct device *dev;
+   struct drm_device *drm_dev;
+
+   const struct jz4780_panel_info *info;
+   uint32_t dirty;
+
+   struct drm_pending_vblank_event *event;
+   int dpms;
+   wait_queue_head_t frame_done_wq;
+   bool frame_done;
+
+   /* fb currently set to scanout 0/1: */
+   struct drm_framebuffer *scanout[2];
+
+   /* for deferred fb unref's: */
+   struct drm_flip_work unref_work;
+
+   /* DMA descriptors */
+   struct jz4780_framedesc 

[PATCH 2/5] dt-bindings: video: Add jz4780-lcd binding

[Zubair Lutfullah Kakakhel]

Add DT bindings for the LCD controller on the jz4780 SoC

Signed-off-by: Zubair Lutfullah Kakakhel 
---
 .../bindings/video/ingenic-jz4780-lcd.txt  | 39 ++
 1 file changed, 39 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/video/ingenic-jz4780-lcd.txt

diff --git a/Documentation/devicetree/bindings/video/ingenic-jz4780-lcd.txt 
b/Documentation/devicetree/bindings/video/ingenic-jz4780-lcd.txt
new file mode 100644
index 000..8512ce3
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/ingenic-jz4780-lcd.txt
@@ -0,0 +1,39 @@
+Bindings for Ingenic JZ4780 LCD Controller
+
+LCD Controller is the Display Controller for the Ingenic JZ4780 SoC
+
+Required properties:
+- compatible: should be "ingenic,jz4780-lcd"
+- reg: Should contain the address & size of the LCD controller registers.
+- interrupts: Should specify the interrupt provided by parent.
+- clocks: Should contain two clock specifiers for the JZ4780_CLK_TVE 
JZ4780_CLK_LCD0PIXCLK.
+- clock-names : Must be "lcd_clk", "lcd_pixclk";
+- port: A port node with endpoint definitions as defined in
+  Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Optional properties:
+- interrupt-parent: phandle to parent interrupt controller
+
+Example:
+
+lcd: jz4780-lcdk at 0x1305 {
+   compatible = "ingenic,jz4780-lcd";
+   reg = <0x1305 0x1800>;
+
+   clocks = < JZ4780_CLK_TVE>, < JZ4780_CLK_LCD0PIXCLK>;
+   clock-names = "lcd_clk", "lcd_pixclk";
+
+   interrupt-parent = <>;
+   interrupts = <31>;
+
+   jz4780_lcd_out: port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   jz4780_out_hdmi: endpoint at 0 {
+   reg = <0>;
+   remote-endpoint = <_in_lcd>;
+   };
+   };
+
+};
-- 
1.9.1

[PATCH 1/5] dt-bindings: video: Add Ingenic jz4780-drm binding

[Zubair Lutfullah Kakakhel]

This patch adds a display susbsytem for the Ingenic JZ4780 SoC

Signed-off-by: Zubair Lutfullah Kakakhel 
---
 .../devicetree/bindings/video/ingenic-jz4780-drm.txt| 17 +
 1 file changed, 17 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/video/ingenic-jz4780-drm.txt

diff --git a/Documentation/devicetree/bindings/video/ingenic-jz4780-drm.txt 
b/Documentation/devicetree/bindings/video/ingenic-jz4780-drm.txt
new file mode 100644
index 000..14a65a7
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/ingenic-jz4780-drm.txt
@@ -0,0 +1,17 @@
+Ingenic JZ4780 DRM master device
+
+
+The Ingenic JZ4780 DRM master device is a virtual device needed to list all
+devices or other display interface nodes that comprise the graphics subsystem.
+
+Required properties:
+- compatible: Should be "ingenic,jz4780-display-subsystem"
+- ports: Should contain a list of phandles pointing to display interface port
+  as defined in Documentation/devicetree/bindings/video/rockchip-vop.txt
+
+example:
+
+display-subsystem {
+   compatible = "ingenic,jz4780-display-subsystem";
+   ports = <_lcd_out>;
+};
-- 
1.9.1

[PATCH 0/5] drm: dt: jz4780: Add Ingenic JZ4780 driver

[Zubair Lutfullah Kakakhel]

Hi,

Here we have 5 patches that add a DRM driver for the LCD
controller in the Ingenic JZ4780 SoC.

The HDMI Controller in the JZ4780 is by Synopsys
and the dw_hdmi driver is used.

These patches are based on 4.0-rc2

Feedback welcome

Thank-you
ZubairLK

Zubair Lutfullah Kakakhel (5):
  dt-bindings: video: Add Ingenic jz4780-drm binding
  dt-bindings: video: Add jz4780-lcd binding
  drm: jz4780: Add DRM driver for Ingenic JZ4780
  dt-bindings: video: Add jz4780-hdmi binding
  drm: bridge/dw_hdmi: add jz4780 support

 .../bindings/video/ingenic-jz4780-drm.txt  |  17 +
 .../bindings/video/ingenic-jz4780-hdmi.txt |  41 ++
 .../bindings/video/ingenic-jz4780-lcd.txt  |  39 ++
 drivers/gpu/drm/Kconfig|   2 +
 drivers/gpu/drm/Makefile   |   1 +
 drivers/gpu/drm/jz4780/Kconfig |  22 +
 drivers/gpu/drm/jz4780/Makefile|  11 +
 drivers/gpu/drm/jz4780/dw_hdmi-jz4780.c| 234 +++
 drivers/gpu/drm/jz4780/jz4780_crtc.c   | 721 +
 drivers/gpu/drm/jz4780/jz4780_drv.c| 388 +++
 drivers/gpu/drm/jz4780/jz4780_drv.h|  84 +++
 drivers/gpu/drm/jz4780/jz4780_regs.h   | 696 
 include/drm/bridge/dw_hdmi.h   |   1 +
 13 files changed, 2257 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/video/ingenic-jz4780-drm.txt
 create mode 100644 
Documentation/devicetree/bindings/video/ingenic-jz4780-hdmi.txt
 create mode 100644 
Documentation/devicetree/bindings/video/ingenic-jz4780-lcd.txt
 create mode 100644 drivers/gpu/drm/jz4780/Kconfig
 create mode 100644 drivers/gpu/drm/jz4780/Makefile
 create mode 100644 drivers/gpu/drm/jz4780/dw_hdmi-jz4780.c
 create mode 100644 drivers/gpu/drm/jz4780/jz4780_crtc.c
 create mode 100644 drivers/gpu/drm/jz4780/jz4780_drv.c
 create mode 100644 drivers/gpu/drm/jz4780/jz4780_drv.h
 create mode 100644 drivers/gpu/drm/jz4780/jz4780_regs.h

-- 
1.9.1

[PATCH] drm: Lighten sysfs connector 'status'

[Chris Wilson]

Since the beginning, sysfs/connector/status has done a heavyweight
detection of the current connector status. But no user, such as upowerd
or logind, has ever desired to initiate a probe. Move the probing into a
new attribute so that existing users get the behaviour they desire.

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Cc: David Herrmann 
Cc: Dave Airlie 
---
 drivers/gpu/drm/drm_sysfs.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
index 5c99d3773212..e4ee91a2bd28 100644
--- a/drivers/gpu/drm/drm_sysfs.c
+++ b/drivers/gpu/drm/drm_sysfs.c
@@ -166,7 +166,7 @@ void drm_sysfs_destroy(void)
 /*
  * Connector properties
  */
-static ssize_t status_show(struct device *device,
+static ssize_t detect_show(struct device *device,
   struct device_attribute *attr,
   char *buf)
 {
@@ -185,6 +185,16 @@ static ssize_t status_show(struct device *device,
drm_get_connector_status_name(status));
 }

+static ssize_t status_show(struct device *device,
+  struct device_attribute *attr,
+  char *buf)
+{
+   struct drm_connector *connector = to_drm_connector(device);
+
+   return snprintf(buf, PAGE_SIZE, "%s\n",
+   drm_get_connector_status_name(connector->status));
+}
+
 static ssize_t dpms_show(struct device *device,
   struct device_attribute *attr,
   char *buf)
@@ -339,12 +349,14 @@ static ssize_t select_subconnector_show(struct device 
*device,
drm_get_dvi_i_select_name((int)subconnector));
 }

+static DEVICE_ATTR_RO(detect);
 static DEVICE_ATTR_RO(status);
 static DEVICE_ATTR_RO(enabled);
 static DEVICE_ATTR_RO(dpms);
 static DEVICE_ATTR_RO(modes);

 static struct attribute *connector_dev_attrs[] = {
+   _attr_detect.attr,
_attr_status.attr,
_attr_enabled.attr,
_attr_dpms.attr,
-- 
2.1.4

[PATCH 1/2] drm/exynos: hdmi: Add support for Exynos7 HDMI

[Ajay kumar]

On Wed, Mar 4, 2015 at 2:30 PM, Andrzej Hajda  wrote:
> On 03/02/2015 09:40 AM, Ajay kumar wrote:
>> Hi Andrej,
>>
>> On Fri, Feb 27, 2015 at 4:18 PM, Andrzej Hajda  
>> wrote:
>>> Hi Ajay,
>>>
>>> Thanks for the patch.
>> Thanks for reviewing the patch.
>>
>>> On 02/26/2015 04:24 PM, Ajay Kumar wrote:
 Modify the exynos HDMI driver to support Exynos7 HDMI 1.4.
 * Add phy configs for Exynos7.
 * Exynos7 has a different clock structure for HDMI,
   so introduce the new clocks.
 * Add sysreg support to enable HDMI SYSREG on Exynos7.
 * Exynos7 based boards need a DCDC_EN and LS_EN pins
   for powering up HDMI. Add support for that too.

 Signed-off-by: Ajay Kumar 
 ---
  .../devicetree/bindings/video/exynos_hdmi.txt  |   21 +-
  drivers/gpu/drm/exynos/exynos_hdmi.c   |  252 
 
  drivers/gpu/drm/exynos/regs-hdmi.h |4 +
  3 files changed, 231 insertions(+), 46 deletions(-)

 diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt 
 b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
 index 1fd8cf9..bb22a60 100644
 --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
 +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
 @@ -6,6 +6,7 @@ Required properties:
   2) "samsung,exynos4210-hdmi"
   3) "samsung,exynos4212-hdmi"
   4) "samsung,exynos5420-hdmi"
 + 5) "samsung,exynos7-hdmi"
>>> Why not "samsung,exynos7420-hdmi" ?
>>> What compatible will you use for Exynos7430 or higher chip number?
>> I will leave this decision to Inki Dae or Kukjin.
>>
  - reg: physical base address of the hdmi and length of memory mapped
   region.
  - interrupts: interrupt number to the cpu.
 @@ -15,21 +16,33 @@ Required properties:
   c) optional flags and pull up/down.
  - clocks: list of clock IDs from SoC clock driver.
   a) hdmi: Gate of HDMI IP bus clock.
 - b) sclk_hdmi: Gate of HDMI special clock.
 - c) sclk_pixel: Pixel special clock, one of the two possible inputs of
 + HDMI clocks necessary for non exynos7:
 +  b) sclk_hdmi: Gate of HDMI special clock.
 +  c) sclk_pixel: Pixel special clock, one of the two possible inputs 
 of
   HDMI clock mux.
 - d) sclk_hdmiphy: HDMI PHY clock output, one of two possible inputs of
 +  d) sclk_hdmiphy: HDMI PHY clock output, one of two possible inputs 
 of
   HDMI clock mux.
 - e) mout_hdmi: It is required by the driver to switch between the 2
 +  e) mout_hdmi: It is required by the driver to switch between the 2
   parents i.e. sclk_pixel and sclk_hdmiphy. If hdmiphy is 
 stable
   after configuration, parent is set to sclk_hdmiphy else
   sclk_pixel.
 + HDMI clocks necessary for Exynos7:
 +  b) pclk_hdmiphy: Gate to HDMIPHY clock.
>>> According to specs there is also pclk_hdmi, why do you specify only this
>>> one?
>> Right, I have reused "hdmi" gating clock for pclk_hdmi. That is why I have
>> left "hdmi" clock as common for exynos7 and non-exynos7.
>
> IMO it would be better to use separate entry for pclk_hdmi.
Ok.

 +  c) hdmi_pixel: Gate clock of MUX output for I_PIXEL_CLK.
 +  d) hdmi_tmds: Gate clock of MUX output for I_TMDS_CLK.
>>> According to specs these clocks should be named i_pixel_clk and
>>> i_tmds_clk, shouldn't they?
>> I actually took these changes from an "internal" code(non-DRM).
>> The original author used these names, and I just carried the same names. :)
>>
  - clock-names: aliases as per driver requirements for above clock IDs:
   "hdmi", "sclk_hdmi", "sclk_pixel", "sclk_hdmiphy" and "mout_hdmi".
  - ddc: phandle to the hdmi ddc node
  - phy: phandle to the hdmi phy node
  - samsung,syscon-phandle: phandle for system controller node for PMU.

 +Only for Exynos7(when compatible = "samsung,exynos7-hdmi"):
 +- samsung,sysreg-phandle: phandle for system controller node for SYSREG 
 block.
 +
 +Optional properties:
 +- dcdc-gpios: OF device-tree gpio specification for HDMI_DCDC_EN pin.
 +- lsen-gpios: OF device-tree gpio specification for HDMI_LS_EN pin.
>>> What is purpose of these gpios?
>> These 2 GPIOs need to be enabled to powerup HDMI on exynos7-espresso board.
>> Other boards need not provide the GPIO.
>
> HDMI is internal IP of SoC, so it is rather not configurable via pins.
> Pin names suggests they are for DC-DC converter and level shifter, I guess
> these are for HDMI connector, not the HDMI IP, am I right?
Right, this is for HDMI connector.

> Maybe better option is to use pinctrl for these gpios, or use gpio
> regulator, hard
> to guess without documentation.
Why should I not use devm_gpiod_get_optional for these GPIOs?

Ajay

[PATCH 2/2] drm/exynos: decon: Add support for DECON-EXT

[Andrzej Hajda]

On 03/02/2015 11:57 AM, Ajay kumar wrote:
> On Mon, Mar 2, 2015 at 1:38 PM, Andrzej Hajda  wrote:
>> On 02/26/2015 04:24 PM, Ajay Kumar wrote:
>>> * Modify DECON-INT driver to support DECON-EXT.
>>> * Add a table of porch values needed to set timing registers of DECON-EXT.
>>> * DECON-EXT supports only H/w Triggered COMMAND mode.
>>> * DECON-EXT supports only one DMA window(window 1), so modify
>>>   all window management routines to support 2 windows of DECON-INT
>>>   and 1 window of DECON-EXT.
>>>
>>> Signed-off-by: Ajay Kumar 
>>> ---
>>>  .../devicetree/bindings/video/exynos7-decon.txt|8 +-
>>>  drivers/gpu/drm/exynos/exynos7_drm_decon.c |  229 
>>> ++--
>>>  include/video/exynos7_decon.h  |   13 ++
>>>  3 files changed, 230 insertions(+), 20 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/video/exynos7-decon.txt 
>>> b/Documentation/devicetree/bindings/video/exynos7-decon.txt
>>> index f5f9c8d..87350c0 100644
>>> --- a/Documentation/devicetree/bindings/video/exynos7-decon.txt
>>> +++ b/Documentation/devicetree/bindings/video/exynos7-decon.txt
>>> @@ -2,10 +2,14 @@ Device-Tree bindings for Samsung Exynos7 SoC display 
>>> controller (DECON)
>>>
>>>  DECON (Display and Enhancement Controller) is the Display Controller for 
>>> the
>>>  Exynos7 series of SoCs which transfers the image data from a video memory
>>> -buffer to an external LCD interface.
>>> +buffer to an external LCD/HDMI interface.
>>> +
>>> +Exynos7 supports DECON-INT for generating video signals for LCD.
>>> +Exynos7 supports DECON-EXT for generating video signals for HDMI.
>>>
>>>  Required properties:
>>> -- compatible: value should be "samsung,exynos7-decon";
>>> +- compatible: value should be "samsung,exynos7-decon-int" for DECON-INT;
>>> +   value should be "samsung,exynos7-decon-ext" for DECON-EXT;
>>>
>>>  - reg: physical base address and length of the DECON registers set.
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
>>> b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
>>> index 63f02e2..9e2d083 100644
>>> --- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
>>> +++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
>>> @@ -41,6 +41,28 @@
>>>
>>>  #define WINDOWS_NR   2
>> Maybe it would be better to rename it to MAX_WINDOWS_NR
> Ok.
>>> +#define DECON_EXT_CH_MAPPING 0x432105
>> I am not familiar with decon, could you explain what exactly
>> this mapping means and why is it fixed in the driver to this value,
>> not default one. By the way my specs says bits 0-3 are reserverd
>> and here it seems you are using them.
> I reused the value from the code which hardware team shared with me.
> It tries to map a input hardware channel(IDMA or VPP channel) onto
> a hardware window in DECON.
> Channel_N is mapped onto window_N in case of DECON-INT.
> In case of DECON-EXT, Channel 0 should be mapped to window 1 of DECON-EXT.
> So, basically for the changes I have made, I should ideally set only
> bits [4:6] to 0x1,
> and leave other bits untouched, though modifying other bits wouldn't
> affect in anyway.
>>> +
>>> +enum decon_type {
>>> + DECON_INT,
>>> + DECON_EXT,
>>> +} decon_type;
>>> +
>>> +struct decon_driver_data {
>>> + enum decon_type decon_type;
>>> + unsigned intnr_windows;
>>> +};
>>> +
>>> +static struct decon_driver_data exynos7_decon_int_driver_data = {
>>> + .decon_type = DECON_INT,
>> I wonder if it wouldn't be better to use different fields to describe
>> each capability/property instead of decon_type. For example
>> .display_type = EXYNOS_DISPLAY_TYPE_LCD,
>> .map_channels = 0,
> Ok, let me list down the differences between INT and EXT.
> 1) Only h/w triggered command mode for DECON-EXT.
> 2) Need to feed modified porch values(decon_ext_timings)
> 3) Input channel to H/w window mapping(WINCHMAP)
> 4) default_window - 0 for DECON-INT and 1 for DECON-EXT
>
> Out of the above differences, the first 3 can somehow be converted
> to capability/property and embedded into driver_data.
> But the 4th difference is bothering me.
> I tried using something like start_window, end_window and tried to make
> The code common for DECON-INT and DECON-EXT, and it just doesn't work.
> ex:
> start_window = 0, end_window = 1 for DECON-INT
> start_window = 1, end_window = 1 for DECON-EXT
>
> When win_commit gets called for window 0 from crtc_commit/plane_commit:
> Configure start_window(0  for DECON-INT and 1 for DECON-EXT)
>
> When win_commit is called from decon_apply, it is called for window 1 also.
> That time win_commit can skip updating actual window 1.
> How do I take care of this ambiguity? This case happens with
> win_disable routine also!

I think clear distinction where are we using hw windows and where sw
windows should be enough.
For example the loop iterating over all windows can look like:

for (win = 0; win < drv_data->nr_windows; win++) {
int hw_win 

[Bug 89420] DELL U2415 monitor detection issue

[bugzilla-dae...@freedesktop.org]

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

--- Comment #2 from Michiel Janssens  ---
Tested with 3.19.0-031900-generic.
Same behaviour.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150304/88347743/attachment.html>

[PATCH] drm/exynos/ipp: Validate buffer enqueue requests

[Marek Szyprowski]

From: Beata Michalska 

As for now there is no validation of incoming buffer
enqueue request as far as the gem buffers are being
concerned. This might lead to some undesired cases
when the driver tries to operate on invalid buffers
(wiht no valid gem object handle i.e.).
Add some basic checks to rule out those potential issues.

Signed-off-by: Beata Michalska 
[mszyprow: rebased onto v4.0-rc1 and adapted to recent ipp changes]
Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/exynos/exynos_drm_ipp.c | 44 +
 1 file changed, 44 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index 12ae9c4..ac35625 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -476,6 +476,45 @@ err_clear:
return ret;
 }

+static int ipp_validate_mem_node(struct drm_device *drm_dev,
+struct drm_exynos_ipp_mem_node *m_node,
+struct drm_exynos_ipp_cmd_node *c_node)
+{
+   struct drm_exynos_ipp_config *ipp_cfg;
+   unsigned int num_plane;
+   unsigned long min_size, size;
+   unsigned int bpp;
+   int i;
+
+   /* The property id should already be varified */
+   ipp_cfg = _node->property.config[m_node->prop_id];
+   num_plane = drm_format_num_planes(ipp_cfg->fmt);
+
+   /**
+* This is a rather simplified validation of a memory node.
+* It basically verifies provided gem object handles
+* and the buffer sizes with respect to current configuration.
+* This is not the best that can be done
+* but it seems more than enough
+*/
+   for (i = 0; i < num_plane; ++i) {
+   if (!m_node->buf_info.handles[i]) {
+   DRM_ERROR("invalid handle for plane %d\n", i);
+   return -EINVAL;
+   }
+   bpp = drm_format_plane_cpp(ipp_cfg->fmt, i);
+   min_size = (ipp_cfg->sz.hsize * ipp_cfg->sz.vsize * bpp) >> 3;
+   size = exynos_drm_gem_get_size(drm_dev,
+  m_node->buf_info.handles[i],
+  c_node->filp);
+   if (min_size > size) {
+   DRM_ERROR("invalid size for plane %d\n", i);
+   return -EINVAL;
+   }
+   }
+   return 0;
+}
+
 static int ipp_put_mem_node(struct drm_device *drm_dev,
struct drm_exynos_ipp_cmd_node *c_node,
struct drm_exynos_ipp_mem_node *m_node)
@@ -552,6 +591,11 @@ static struct drm_exynos_ipp_mem_node
}

mutex_lock(_node->mem_lock);
+   if (ipp_validate_mem_node(drm_dev, m_node, c_node)) {
+   ipp_put_mem_node(drm_dev, c_node, m_node);
+   mutex_unlock(_node->mem_lock);
+   return ERR_PTR(-EFAULT);
+   }
list_add_tail(_node->list, _node->mem_list[qbuf->ops_id]);
mutex_unlock(_node->mem_lock);

-- 
1.9.2

[Bug 89420] DELL U2415 monitor detection issue

[bugzilla-dae...@freedesktop.org]

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

--- Comment #1 from Alex Deucher  ---
Is this still an issue with a newer kernel?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150304/95f126bd/attachment.html>

[Bug 89420] DELL U2415 monitor detection issue

[bugzilla-dae...@freedesktop.org]

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

Alex Deucher  changed:

   What|Removed |Added

  Component|Driver/Radeon   |DRM/Radeon
   Assignee|xorg-driver-ati at lists.x.org |dri-devel at 
lists.freedesktop
   ||.org
Product|xorg|DRI
 QA Contact|xorg-team at lists.x.org   |

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150304/6037ff85/attachment.html>

[PATCH] i915: Add I915_PARAM_REVISION

[Neil Roberts]

This is a new parameter for DRM_I915_GETPARAM to query the GPU
revision.

Signed-off-by: Neil Roberts 
---
 include/drm/i915_drm.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index 15dd01d..943a9d9 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -340,6 +340,7 @@ typedef struct drm_i915_irq_wait {
 #define I915_PARAM_HAS_EXEC_HANDLE_LUT   26
 #define I915_PARAM_HAS_WT   27
 #define I915_PARAM_CMD_PARSER_VERSION   28
+#define I915_PARAM_REVISION  32

 typedef struct drm_i915_getparam {
int param;
-- 
1.9.3

[PATCH v2] mode: Retrieve only the current information for a Connector

[Daniel Vetter]

On Wed, Mar 4, 2015 at 1:34 PM, Chris Wilson  
wrote:
> On Wed, Mar 04, 2015 at 01:31:46PM +0100, Daniel Vetter wrote:
>> On Wed, Mar 4, 2015 at 12:29 PM, Chris Wilson  
>> wrote:
>> > On Wed, Mar 04, 2015 at 12:08:42PM +0100, Daniel Vetter wrote:
>> >> On Wed, Mar 04, 2015 at 10:38:08AM +, Chris Wilson wrote:
>> >> > +   if (conn.encoder_id) {
>> >> > +   r->count_encoders = 1;
>> >>
>> >> This only works for i915 where we only ever have 1 encoder. Other drivers
>> >> reassign encoders depending upon output type (e.g. dvi-i vs dvi-d). Imo
>> >> it'd be cleaner to do something like the below:
>> >
>> > Not quite. This value is the currently active encoder_id for the
>> > connector; there can only be one. As opposed to the array of associated
>> > encoders that we normally supply on ouptut. Even i915 has multiple
>> > encoders on connectors nowadays!
>>
>> DRM_MAX_ENCODER in the kernel is 3. And i915 has multipled connectors
>> for the same encoder, but not the other way round. Having multiple
>> encoders is the reason for the best_encoders callback in the crtc
>> helpers, which we've ditched for i915 (we always pick the single
>> intel_connector->encoder statically assigned at load time).
>
> We have multiple encoders on the same connector, since 3.17.

Ok short summary of our irc discussion: I've totally missed the fake
encoders from dp mst, i915 indeed has multiple possible encoders per
output now too.

Wrt the api discussion itself I didn't realize that Chris' code digs
out the entire current configuration (including mode and all that) and
intentionally filters out all the other information supplied by the
kernel (like the mode list or list of possible encoders). Imo that's
too high-level and artificially limits what drivers could do with
this.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH v2] mode: Retrieve only the current information for a Connector

[Daniel Vetter]

On Wed, Mar 4, 2015 at 12:29 PM, Chris Wilson  
wrote:
> On Wed, Mar 04, 2015 at 12:08:42PM +0100, Daniel Vetter wrote:
>> On Wed, Mar 04, 2015 at 10:38:08AM +, Chris Wilson wrote:
>> > +   if (conn.encoder_id) {
>> > +   r->count_encoders = 1;
>>
>> This only works for i915 where we only ever have 1 encoder. Other drivers
>> reassign encoders depending upon output type (e.g. dvi-i vs dvi-d). Imo
>> it'd be cleaner to do something like the below:
>
> Not quite. This value is the currently active encoder_id for the
> connector; there can only be one. As opposed to the array of associated
> encoders that we normally supply on ouptut. Even i915 has multiple
> encoders on connectors nowadays!

DRM_MAX_ENCODER in the kernel is 3. And i915 has multipled connectors
for the same encoder, but not the other way round. Having multiple
encoders is the reason for the best_encoders callback in the crtc
helpers, which we've ditched for i915 (we always pick the single
intel_connector->encoder statically assigned at load time).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH v4] mode: Retrieve only the current information for a Connector

[Chris Wilson]

Add a new API that allows the caller to skip any forced probing, which
may require slow i2c to a remote display, and only report the currently
active mode and encoder for a Connector. This is often the information
of interest and is much, much faster than re-retrieving the link status
and EDIDs, e.g. if the caller only wishes to count the number of active
outputs.

v2: Fix error path to avoid double free after a failed GETCONNECTOR
ioctl.

v3: Daniel strongly disapproved of my disjoint in behaviour between
GetConnector and GetConnectorCurrent, and considering how best to make a
drop in replacement for drmmode_output_init() convinced me keeping the
API as consistent as possible was the right approach.

v4: Avoid probing on the second calls to GETCONNECTOR for unconnected
outputs.

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Cc: Damien Lespiau 
Cc: David Herrmann 
---
 tests/modeprint/modeprint.c | 18 --
 xf86drmMode.c   | 23 ---
 xf86drmMode.h   | 17 +++--
 3 files changed, 51 insertions(+), 7 deletions(-)

diff --git a/tests/modeprint/modeprint.c b/tests/modeprint/modeprint.c
index 6f0d039..514d3ba 100644
--- a/tests/modeprint/modeprint.c
+++ b/tests/modeprint/modeprint.c
@@ -43,6 +43,7 @@

 #define ARRAY_SIZE(a) (sizeof(a) / sizeof(a[0]))

+int current;
 int connectors;
 int full_props;
 int edid;
@@ -272,7 +273,7 @@ int printRes(int fd, drmModeResPtr res)

if (connectors) {
for (i = 0; i < res->count_connectors; i++) {
-   connector = drmModeGetConnector(fd, res->connectors[i]);
+   connector = (current ? drmModeGetConnectorCurrent : 
drmModeGetConnector) (fd, res->connectors[i]);

if (!connector)
printf("Could not get connector %i\n", 
res->connectors[i]);
@@ -331,6 +332,7 @@ int printRes(int fd, drmModeResPtr res)

 void args(int argc, char **argv)
 {
+   int defaults = 1;
int i;

fbs = 0;
@@ -341,32 +343,41 @@ void args(int argc, char **argv)
full_modes = 0;
full_props = 0;
connectors = 0;
+   current = 0;

module_name = argv[1];

for (i = 2; i < argc; i++) {
if (strcmp(argv[i], "-fb") == 0) {
fbs = 1;
+   defaults = 0;
} else if (strcmp(argv[i], "-crtcs") == 0) {
crtcs = 1;
+   defaults = 0;
} else if (strcmp(argv[i], "-cons") == 0) {
connectors = 1;
modes = 1;
+   defaults = 0;
} else if (strcmp(argv[i], "-modes") == 0) {
connectors = 1;
modes = 1;
+   defaults = 0;
} else if (strcmp(argv[i], "-full") == 0) {
connectors = 1;
modes = 1;
full_modes = 1;
+   defaults = 0;
} else if (strcmp(argv[i], "-props") == 0) {
connectors = 1;
full_props = 1;
+   defaults = 0;
} else if (strcmp(argv[i], "-edids") == 0) {
connectors = 1;
edid = 1;
+   defaults = 0;
} else if (strcmp(argv[i], "-encoders") == 0) {
encoders = 1;
+   defaults = 0;
} else if (strcmp(argv[i], "-v") == 0) {
fbs = 1;
edid = 1;
@@ -376,10 +387,13 @@ void args(int argc, char **argv)
full_modes = 1;
full_props = 1;
connectors = 1;
+   defaults = 0;
+   } else if (strcmp(argv[i], "-current") == 0) {
+   current = 1;
}
}

-   if (argc == 2) {
+   if (defaults) {
fbs = 1;
edid = 1;
crtcs = 1;
diff --git a/xf86drmMode.c b/xf86drmMode.c
index 9ea8fe7..57d1dc9 100644
--- a/xf86drmMode.c
+++ b/xf86drmMode.c
@@ -476,19 +476,23 @@ drmModeEncoderPtr drmModeGetEncoder(int fd, uint32_t 
encoder_id)
 /*
  * Connector manipulation
  */
-
-drmModeConnectorPtr drmModeGetConnector(int fd, uint32_t connector_id)
+static drmModeConnectorPtr
+_drmModeGetConnector(int fd, uint32_t connector_id, int probe)
 {
struct drm_mode_get_connector conn, counts;
drmModeConnectorPtr r = NULL;

-retry:
memclear(conn);
conn.connector_id = connector_id;
+   if (!probe) {
+   conn.count_modes = 1;
+   conn.modes_ptr = VOID2U64(drmMalloc(sizeof(struct 
drm_mode_modeinfo)));
+   }

if (drmIoctl(fd, DRM_IOCTL_MODE_GETCONNECTOR, ))
return 0;

+retry:
counts 

[pull] radeon drm-fixes-4.0

[Alex Deucher]

Hi Dave,

Radeon fixes for 4.0:
- Fix some fallout from the audio rework
- Fix a possible oops in the CS ioctl
- Fix interlaced modes on DCE8
- Do a posting read in irq_set callbacks to make sure
  interrupts are properly flushed through the pci bridge

The following changes since commit ed9ed50ccc2c16690b921171c809f6f15255ac65:

  Revert "drm/rockchip: Flip select/depends in Kconfig" (2015-03-03 21:11:34 
+1000)

are available in the git repository at:

  git://people.freedesktop.org/~agd5f/linux drm-fixes-4.0

for you to fetch changes up to 77ae5f4b48a0445426c9c1ef7c0f28b717e35d55:

  drm/radeon: fix interlaced modes on DCE8 (2015-03-03 17:28:31 -0500)


Alex Deucher (14):
  drm/radeon: fix the audio dpms callbacks
  drm/radeon: assign pin in detect
  drm/radeon/audio: set mute around state setup
  drm/radeon: don't toggle audio state in modeset
  drm/radeon/audio: update EDID derived fields in modeset
  drm/radeon: properly set dto for dp on DCE4/5
  drm/radeon: adjust audio callback order
  drm/radeon: do a posting read in r100_set_irq
  drm/radeon: do a posting read in rs600_set_irq
  drm/radeon: do a posting read in r600_set_irq
  drm/radeon: do a posting read in evergreen_set_irq
  drm/radeon: do a posting read in si_set_irq
  drm/radeon: do a posting read in cik_set_irq
  drm/radeon: fix interlaced modes on DCE8

Slava Grigorev (2):
  radeon/audio: fix whitespace
  radeon/audio: fix DP audio on DCE6

Tommi Rantala (1):
  drm/radeon: fix DRM_IOCTL_RADEON_CS oops

 drivers/gpu/drm/radeon/atombios_crtc.c |  3 ++
 drivers/gpu/drm/radeon/atombios_encoders.c | 30 +++--
 drivers/gpu/drm/radeon/cik.c   |  3 ++
 drivers/gpu/drm/radeon/dce6_afmt.c | 68 +++---
 drivers/gpu/drm/radeon/evergreen.c |  3 ++
 drivers/gpu/drm/radeon/evergreen_hdmi.c| 59 +-
 drivers/gpu/drm/radeon/r100.c  |  4 ++
 drivers/gpu/drm/radeon/r600.c  |  3 ++
 drivers/gpu/drm/radeon/r600_hdmi.c | 11 -
 drivers/gpu/drm/radeon/radeon_audio.c  | 50 +++---
 drivers/gpu/drm/radeon/radeon_cs.c |  4 +-
 drivers/gpu/drm/radeon/rs600.c |  4 ++
 drivers/gpu/drm/radeon/si.c|  3 ++
 drivers/gpu/drm/radeon/sid.h   |  4 +-
 14 files changed, 122 insertions(+), 127 deletions(-)

[Bug 93701] radeon: two "empty" pixel lines on left side of screen, rest of screen gets slightly squished

[bugzilla-dae...@bugzilla.kernel.org]

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

--- Comment #14 from Frederik vom Hofe  ---
Ok I got the git magic working.
But the audio-fixes branch still does not fix the issue for me.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH v3] mode: Retrieve only the current information for a Connector

[Chris Wilson]

Add a new API that allows the caller to skip any forced probing, which
may require slow i2c to a remote display, and only report the currently
active mode and encoder for a Connector. This is often the information
of interest and is much, much faster than re-retrieving the link status
and EDIDs, e.g. if the caller only wishes to count the number of active
outputs.

v2: Fix error path to avoid double free after a failed GETCONNECTOR
ioctl.

v3: Daniel strongly disapproved of my disjoint in behaviour between
GetConnector and GetConnectorCurrent, and considering how best to make a
drop in replacement for drmmode_output_init() convinced me keeping the
API as consistent as possible was the right approach.

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Cc: Damien Lespiau 
Cc: David Herrmann 
---
 tests/modeprint/modeprint.c | 18 --
 xf86drmMode.c   | 20 +---
 xf86drmMode.h   | 17 +++--
 3 files changed, 48 insertions(+), 7 deletions(-)

diff --git a/tests/modeprint/modeprint.c b/tests/modeprint/modeprint.c
index 6f0d039..514d3ba 100644
--- a/tests/modeprint/modeprint.c
+++ b/tests/modeprint/modeprint.c
@@ -43,6 +43,7 @@

 #define ARRAY_SIZE(a) (sizeof(a) / sizeof(a[0]))

+int current;
 int connectors;
 int full_props;
 int edid;
@@ -272,7 +273,7 @@ int printRes(int fd, drmModeResPtr res)

if (connectors) {
for (i = 0; i < res->count_connectors; i++) {
-   connector = drmModeGetConnector(fd, res->connectors[i]);
+   connector = (current ? drmModeGetConnectorCurrent : 
drmModeGetConnector) (fd, res->connectors[i]);

if (!connector)
printf("Could not get connector %i\n", 
res->connectors[i]);
@@ -331,6 +332,7 @@ int printRes(int fd, drmModeResPtr res)

 void args(int argc, char **argv)
 {
+   int defaults = 1;
int i;

fbs = 0;
@@ -341,32 +343,41 @@ void args(int argc, char **argv)
full_modes = 0;
full_props = 0;
connectors = 0;
+   current = 0;

module_name = argv[1];

for (i = 2; i < argc; i++) {
if (strcmp(argv[i], "-fb") == 0) {
fbs = 1;
+   defaults = 0;
} else if (strcmp(argv[i], "-crtcs") == 0) {
crtcs = 1;
+   defaults = 0;
} else if (strcmp(argv[i], "-cons") == 0) {
connectors = 1;
modes = 1;
+   defaults = 0;
} else if (strcmp(argv[i], "-modes") == 0) {
connectors = 1;
modes = 1;
+   defaults = 0;
} else if (strcmp(argv[i], "-full") == 0) {
connectors = 1;
modes = 1;
full_modes = 1;
+   defaults = 0;
} else if (strcmp(argv[i], "-props") == 0) {
connectors = 1;
full_props = 1;
+   defaults = 0;
} else if (strcmp(argv[i], "-edids") == 0) {
connectors = 1;
edid = 1;
+   defaults = 0;
} else if (strcmp(argv[i], "-encoders") == 0) {
encoders = 1;
+   defaults = 0;
} else if (strcmp(argv[i], "-v") == 0) {
fbs = 1;
edid = 1;
@@ -376,10 +387,13 @@ void args(int argc, char **argv)
full_modes = 1;
full_props = 1;
connectors = 1;
+   defaults = 0;
+   } else if (strcmp(argv[i], "-current") == 0) {
+   current = 1;
}
}

-   if (argc == 2) {
+   if (defaults) {
fbs = 1;
edid = 1;
crtcs = 1;
diff --git a/xf86drmMode.c b/xf86drmMode.c
index 9ea8fe7..138f1bf 100644
--- a/xf86drmMode.c
+++ b/xf86drmMode.c
@@ -476,19 +476,23 @@ drmModeEncoderPtr drmModeGetEncoder(int fd, uint32_t 
encoder_id)
 /*
  * Connector manipulation
  */
-
-drmModeConnectorPtr drmModeGetConnector(int fd, uint32_t connector_id)
+static drmModeConnectorPtr
+_drmModeGetConnector(int fd, uint32_t connector_id, int probe)
 {
struct drm_mode_get_connector conn, counts;
drmModeConnectorPtr r = NULL;

-retry:
memclear(conn);
conn.connector_id = connector_id;
+   if (!probe) {
+   conn.count_modes = 1;
+   conn.modes_ptr = VOID2U64(drmMalloc(sizeof(struct 
drm_mode_modeinfo)));
+   }

if (drmIoctl(fd, DRM_IOCTL_MODE_GETCONNECTOR, ))
return 0;

+retry:
counts = conn;

if (conn.count_props) {
@@ -572,6 +576,16 @@ err_allocs:

[GIT PULL]: dma-buf fixes for 4.0

[Sumit Semwal]

Hi Linus,

May I please request you to pull a couple of fixes in dma-buf for 4.0-rc3?


The following changes since commit b942c653ae265abbd31032f3b4f5f857e5c7c723:

  Merge tag 'trace-sh-3.19' of
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
(2015-01-22 06:26:07 +1200)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/sumits/dma-buf.git
tags/dma-buf-for-4.0-rc3

for you to fetch changes up to 4eb2440ed60fb5793f7aa6da89b3d517cc59de43:

  reservation: Remove shadowing local variable 'ret' (2015-01-22 16:29:31 +0530)


dma-buf pull request for 4.0-rc3
- minor timeout & other fixes on reservation/fence


Jammy Zhou (2):
  reservation: wait only with non-zero timeout specified (v3)
  dma-buf/fence: don't wait when specified timeout is zero

Michel Dänzer (1):
  reservation: Remove shadowing local variable 'ret'

 drivers/dma-buf/fence.c   | 3 +++
 drivers/dma-buf/reservation.c | 5 +++--
 2 files changed, 6 insertions(+), 2 deletions(-)

Thanks, and Best regards,
Sumit.

PS: I am not submitting the cleanup that I submitted in my earlier
pull request that you had to reject due to my stupid copy-paste error;
that one patch and it's fix is in for-next, but it's not, strictly
speaking, a "fix" to qualify for -rc3, hence I'll wait for the next
merge-window to submit it.

[PATCH v2] mode: Retrieve only the current information for a Connector

[Chris Wilson]

On Wed, Mar 04, 2015 at 01:31:46PM +0100, Daniel Vetter wrote:
> On Wed, Mar 4, 2015 at 12:29 PM, Chris Wilson  
> wrote:
> > On Wed, Mar 04, 2015 at 12:08:42PM +0100, Daniel Vetter wrote:
> >> On Wed, Mar 04, 2015 at 10:38:08AM +, Chris Wilson wrote:
> >> > +   if (conn.encoder_id) {
> >> > +   r->count_encoders = 1;
> >>
> >> This only works for i915 where we only ever have 1 encoder. Other drivers
> >> reassign encoders depending upon output type (e.g. dvi-i vs dvi-d). Imo
> >> it'd be cleaner to do something like the below:
> >
> > Not quite. This value is the currently active encoder_id for the
> > connector; there can only be one. As opposed to the array of associated
> > encoders that we normally supply on ouptut. Even i915 has multiple
> > encoders on connectors nowadays!
> 
> DRM_MAX_ENCODER in the kernel is 3. And i915 has multipled connectors
> for the same encoder, but not the other way round. Having multiple
> encoders is the reason for the best_encoders callback in the crtc
> helpers, which we've ditched for i915 (we always pick the single
> intel_connector->encoder statically assigned at load time).

We have multiple encoders on the same connector, since 3.17.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH v2] mode: Retrieve only the current information for a Connector

[Daniel Vetter]

On Wed, Mar 04, 2015 at 10:38:08AM +, Chris Wilson wrote:
> Add a new API that allows the caller to skip any forced probing, which
> may require slow i2c to a remote display, and only report the currently
> active mode and encoder for a Connector. This is often the information
> of interest and is much, much faster than re-retrieving the link status
> and EDIDs, e.g. if the caller only wishes to count the number of active
> outputs.
> 
> v2: Fix error path to avoid double free after a failed GETCONNECTOR
> ioctl.
> 
> Signed-off-by: Chris Wilson 
> Cc: Daniel Vetter 
> Cc: Damien Lespiau 
> Cc: David Herrmann 

Context for David: Apparently logind sees fit to probe drm connectors,
right when X starts and not using the cached state. Which needless adds up
to a few hundred ms delay since X then blocks when it does its own cached
getconnector. I've asked Chris to extract the code from the intel ddx to
make this a bit more official and known.

> ---
>  tests/modeprint/modeprint.c | 18 -
>  xf86drmMode.c   | 97 
> +
>  xf86drmMode.h   | 17 +++-
>  3 files changed, 128 insertions(+), 4 deletions(-)
> 
> diff --git a/tests/modeprint/modeprint.c b/tests/modeprint/modeprint.c
> index 6f0d039..514d3ba 100644
> --- a/tests/modeprint/modeprint.c
> +++ b/tests/modeprint/modeprint.c
> @@ -43,6 +43,7 @@
>  
>  #define ARRAY_SIZE(a) (sizeof(a) / sizeof(a[0]))
>  
> +int current;
>  int connectors;
>  int full_props;
>  int edid;
> @@ -272,7 +273,7 @@ int printRes(int fd, drmModeResPtr res)
>  
>   if (connectors) {
>   for (i = 0; i < res->count_connectors; i++) {
> - connector = drmModeGetConnector(fd, res->connectors[i]);
> + connector = (current ? drmModeGetConnectorCurrent : 
> drmModeGetConnector) (fd, res->connectors[i]);
>  
>   if (!connector)
>   printf("Could not get connector %i\n", 
> res->connectors[i]);
> @@ -331,6 +332,7 @@ int printRes(int fd, drmModeResPtr res)
>  
>  void args(int argc, char **argv)
>  {
> + int defaults = 1;
>   int i;
>  
>   fbs = 0;
> @@ -341,32 +343,41 @@ void args(int argc, char **argv)
>   full_modes = 0;
>   full_props = 0;
>   connectors = 0;
> + current = 0;
>  
>   module_name = argv[1];
>  
>   for (i = 2; i < argc; i++) {
>   if (strcmp(argv[i], "-fb") == 0) {
>   fbs = 1;
> + defaults = 0;
>   } else if (strcmp(argv[i], "-crtcs") == 0) {
>   crtcs = 1;
> + defaults = 0;
>   } else if (strcmp(argv[i], "-cons") == 0) {
>   connectors = 1;
>   modes = 1;
> + defaults = 0;
>   } else if (strcmp(argv[i], "-modes") == 0) {
>   connectors = 1;
>   modes = 1;
> + defaults = 0;
>   } else if (strcmp(argv[i], "-full") == 0) {
>   connectors = 1;
>   modes = 1;
>   full_modes = 1;
> + defaults = 0;
>   } else if (strcmp(argv[i], "-props") == 0) {
>   connectors = 1;
>   full_props = 1;
> + defaults = 0;
>   } else if (strcmp(argv[i], "-edids") == 0) {
>   connectors = 1;
>   edid = 1;
> + defaults = 0;
>   } else if (strcmp(argv[i], "-encoders") == 0) {
>   encoders = 1;
> + defaults = 0;
>   } else if (strcmp(argv[i], "-v") == 0) {
>   fbs = 1;
>   edid = 1;
> @@ -376,10 +387,13 @@ void args(int argc, char **argv)
>   full_modes = 1;
>   full_props = 1;
>   connectors = 1;
> + defaults = 0;
> + } else if (strcmp(argv[i], "-current") == 0) {
> + current = 1;
>   }
>   }
>  
> - if (argc == 2) {
> + if (defaults) {
>   fbs = 1;
>   edid = 1;
>   crtcs = 1;
> diff --git a/xf86drmMode.c b/xf86drmMode.c
> index 9ea8fe7..4433dc7 100644
> --- a/xf86drmMode.c
> +++ b/xf86drmMode.c
> @@ -572,6 +572,103 @@ err_allocs:
>   return r;
>  }
>  
> +drmModeConnectorPtr drmModeGetConnectorCurrent(int fd, uint32_t connector_id)
> +{
> + struct drm_mode_modeinfo mode;
> + struct drm_mode_get_encoder enc;
> + struct drm_mode_get_connector conn;
> + unsigned int num_props = 0;
> + drmModeConnectorPtr r;
> +
> + memclear(conn);
> + conn.connector_id = connector_id;
> + do {
> + if (conn.count_props) {
> + drmFree(U642VOID(conn.props_ptr));
> + 

[Intel-gfx] [PATCH 1/8] drm: Pass in new and old plane state to prepare_fb and cleanup_fb

[Rob Clark]

On Tue, Mar 3, 2015 at 9:22 AM, Tvrtko Ursulin
 wrote:
> From: Tvrtko Ursulin 
>
> Use cases like rotation require these hooks to have some context so they
> know how to prepare and cleanup the frame buffer correctly.
>
> For i915 specifically, object backing pages need to be mapped differently
> for different rotation modes and the driver needs to know which mapping to
> instantiate and which to tear down when transitioning between them.
>
> v2: Made passed in states const. (Daniel Vetter)
>
> Signed-off-by: Tvrtko Ursulin 
> Cc: Daniel Vetter 
> Cc: dri-devel at lists.freedesktop.org
> ---
>  drivers/gpu/drm/drm_atomic_helper.c   | 13 -
>  drivers/gpu/drm/drm_plane_helper.c|  5 +++--
>  drivers/gpu/drm/i915/intel_display.c  |  6 --
>  drivers/gpu/drm/i915/intel_drv.h  |  6 --
>  drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c |  6 --

jfyi, mdp5 would need similar fixup..

and with my bikeshedding hat on, maybe swap the order of plane_state
and fb.. somehow that feels like a more natural order (but that is
just bikeshedding, feel free to ignore that part)

with mdp5 (and with or without bikeshed),

Reviewed-by: Rob Clark 


BR,
-R

>  drivers/gpu/drm/tegra/dc.c|  6 --
>  include/drm/drm_plane_helper.h|  6 --
>  7 files changed, 31 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 3ce57f4..a745881 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1116,6 +1116,7 @@ int drm_atomic_helper_prepare_planes(struct drm_device 
> *dev,
> for (i = 0; i < nplanes; i++) {
> struct drm_plane_helper_funcs *funcs;
> struct drm_plane *plane = state->planes[i];
> +   struct drm_plane_state *plane_state = state->plane_states[i];
> struct drm_framebuffer *fb;
>
> if (!plane)
> @@ -1123,10 +1124,10 @@ int drm_atomic_helper_prepare_planes(struct 
> drm_device *dev,
>
> funcs = plane->helper_private;
>
> -   fb = state->plane_states[i]->fb;
> +   fb = plane_state->fb;
>
> if (fb && funcs->prepare_fb) {
> -   ret = funcs->prepare_fb(plane, fb);
> +   ret = funcs->prepare_fb(plane, fb, plane_state);
> if (ret)
> goto fail;
> }
> @@ -1138,6 +1139,7 @@ fail:
> for (i--; i >= 0; i--) {
> struct drm_plane_helper_funcs *funcs;
> struct drm_plane *plane = state->planes[i];
> +   struct drm_plane_state *plane_state = state->plane_states[i];
> struct drm_framebuffer *fb;
>
> if (!plane)
> @@ -1148,7 +1150,7 @@ fail:
> fb = state->plane_states[i]->fb;
>
> if (fb && funcs->cleanup_fb)
> -   funcs->cleanup_fb(plane, fb);
> +   funcs->cleanup_fb(plane, fb, plane_state);
>
> }
>
> @@ -1254,6 +1256,7 @@ void drm_atomic_helper_cleanup_planes(struct drm_device 
> *dev,
> for (i = 0; i < nplanes; i++) {
> struct drm_plane_helper_funcs *funcs;
> struct drm_plane *plane = old_state->planes[i];
> +   struct drm_plane_state *plane_state = 
> old_state->plane_states[i];
> struct drm_framebuffer *old_fb;
>
> if (!plane)
> @@ -1261,10 +1264,10 @@ void drm_atomic_helper_cleanup_planes(struct 
> drm_device *dev,
>
> funcs = plane->helper_private;
>
> -   old_fb = old_state->plane_states[i]->fb;
> +   old_fb = plane_state->fb;
>
> if (old_fb && funcs->cleanup_fb)
> -   funcs->cleanup_fb(plane, old_fb);
> +   funcs->cleanup_fb(plane, old_fb, plane_state);
> }
>  }
>  EXPORT_SYMBOL(drm_atomic_helper_cleanup_planes);
> diff --git a/drivers/gpu/drm/drm_plane_helper.c 
> b/drivers/gpu/drm/drm_plane_helper.c
> index 5ba5792..813a066 100644
> --- a/drivers/gpu/drm/drm_plane_helper.c
> +++ b/drivers/gpu/drm/drm_plane_helper.c
> @@ -437,7 +437,8 @@ int drm_plane_helper_commit(struct drm_plane *plane,
>
> if (plane_funcs->prepare_fb && plane_state->fb &&
> plane_state->fb != old_fb) {
> -   ret = plane_funcs->prepare_fb(plane, plane_state->fb);
> +   ret = plane_funcs->prepare_fb(plane, plane_state->fb,
> + plane_state);
> if (ret)
> goto out;
> }
> @@ -487,7 +488,7 @@ int drm_plane_helper_commit(struct drm_plane *plane,
> }
>
> if (plane_funcs->cleanup_fb && old_fb)
> -   plane_funcs->cleanup_fb(plane, old_fb);
> +   plane_funcs->cleanup_fb(plane, old_fb, plane_state);
>  out:
> if 

[PATCH 2/4] drm/msm/mdp5: Enhance operation mode for pipeline configuration

[Archit Taneja]

Hi,

On 03/04/2015 12:06 AM, Stephane Viau wrote:
> DSI and WB interfaces need a more complex pipeline configuration
> than the current mdp5_ctl_set_intf().
>
> For example, memory output connections need to be selected for
> WB. Interface mode (Video vs. Command modes) also need to be
> configured for DSI.
>
> This change takes care of configuring the whole pipeline as far
> as operation mode goes. DSI and WB interfaces will be added
> later.
>
> Signed-off-by: Stephane Viau 
> ---
>   drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h |  2 +
>   drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c| 39 ++---
>   drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c | 91 
> +
>   drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.h |  3 +-
>   drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c | 29 +
>   drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 16 -
>   drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h | 48 ---
>   7 files changed, 157 insertions(+), 71 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h 
> b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h
> index dba4d52..be587b8 100644
> --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h
> +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h
> @@ -31,6 +31,8 @@ extern const struct mdp5_cfg_hw *mdp5_cfg;
>
>   typedef DECLARE_BITMAP(mdp5_smp_state_t, MAX_SMP_BLOCKS);
>
> +#define MDP5_INTF_IS_VIRTUAL_DISPLAY(intf_type)   ((intf_type) >= 
> INTF_VIRTUAL)
> +

Minor comment and probably matter of taste. Having the above as 
mdp5_intf_is_virtual() would seem better in the code.



Thanks,
Archit

[PATCH 4/4] drm/msm/mdp5: Make the intf connection in config module

[Archit Taneja]

Hi,

On 03/04/2015 12:06 AM, Stephane Viau wrote:
> Up until now, we assume that eDP is tight to intf_0 and HDMI to
> intf_3. This information shall actually come from the mdp5_cfg
> module since it can change from one chip to another.
>
> Signed-off-by: Stephane Viau 
> ---
>   drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c |   8 +++
>   drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h |   4 ++
>   drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 111 
> ++--
>   3 files changed, 74 insertions(+), 49 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c 
> b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
> index 72c075a..8bee023 100644
> --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
> +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
> @@ -62,6 +62,10 @@ const struct mdp5_cfg_hw msm8x74_config = {
>   .count = 4,
>   .base = { 0x12500, 0x12700, 0x12900, 0x12b00 },
>   },
> + .intfs = {
> + [0] = INTF_eDP,
> + [3] = INTF_HDMI,
> + },
>   .max_clk = 2,
>   };
>
> @@ -111,6 +115,10 @@ const struct mdp5_cfg_hw apq8084_config = {
>   .count = 5,
>   .base = { 0x12500, 0x12700, 0x12900, 0x12b00, 0x12d00 },
>   },
> + .intfs = {
> + [0] = INTF_eDP,
> + [3] = INTF_HDMI,
> + },
>   .max_clk = 32000,
>   };
>
> diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h 
> b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h
> index be149b3..4e91f14 100644
> --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h
> +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h
> @@ -58,6 +58,8 @@ struct mdp5_smp_block {
>   int reserved[MAX_CLIENTS];  /* # of MMBs allocated per client */
>   };
>
> +#define MDP5_INTF_NUM_MAX5
> +
>   struct mdp5_cfg_hw {
>   char  *name;
>
> @@ -71,6 +73,8 @@ struct mdp5_cfg_hw {
>   struct mdp5_sub_block ad;
>   struct mdp5_sub_block intf;
>
> + u32 intfs[MDP5_INTF_NUM_MAX]; /* array of enum mdp5_intf_type */
> +

The array type could be "enum mdp5_intf_type" rather than u32.

>   uint32_t max_clk;
>   };
>
> diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c 
> b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
> index 390d9d2..8cec00e 100644
> --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
> +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
> @@ -161,6 +161,44 @@ int mdp5_enable(struct mdp5_kms *mdp5_kms)
>   return 0;
>   }
>
> +static int construct_encoder(struct mdp5_kms *mdp5_kms,
> + enum mdp5_intf_type intf_type, int intf_num)
> +{
> + struct drm_device *dev = mdp5_kms->dev;
> + struct msm_drm_private *priv = dev->dev_private;
> + struct drm_encoder *encoder;
> + struct mdp5_interface intf = {
> + .num= intf_num,
> + .type   = intf_type,
> + .mode   = MDP5_INTF_MODE_NONE,
> + };
> + int ret = 0;
> +
> + encoder = mdp5_encoder_init(dev, );
> + if (IS_ERR(encoder)) {
> + ret = PTR_ERR(encoder);
> + dev_err(dev->dev, "failed to construct encoder: %d\n", ret);
> + return ret;
> + }
> +
> + encoder->possible_crtcs = (1 << priv->num_crtcs) - 1;
> + priv->encoders[priv->num_encoders++] = encoder;
> +
> + if (intf_type == INTF_HDMI) {
> + ret = hdmi_modeset_init(priv->hdmi, dev, encoder);
> + if (ret)
> + dev_err(dev->dev, "failed to init HDMI: %d\n", ret);
> +
> + } else if (intf_type == INTF_eDP) {
> + /* Construct bridge/connector for eDP: */
> + ret = msm_edp_modeset_init(priv->edp, dev, encoder);
> + if (ret)
> + dev_err(dev->dev, "failed to init eDP: %d\n", ret);
> + }
> +
> + return ret;
> +}
> +
>   static int modeset_init(struct mdp5_kms *mdp5_kms)
>   {
>   static const enum mdp5_pipe crtcs[] = {
> @@ -171,7 +209,6 @@ static int modeset_init(struct mdp5_kms *mdp5_kms)
>   };
>   struct drm_device *dev = mdp5_kms->dev;
>   struct msm_drm_private *priv = dev->dev_private;
> - struct drm_encoder *encoder;
>   const struct mdp5_cfg_hw *hw_cfg;
>   int i, ret;
>
> @@ -222,56 +259,29 @@ static int modeset_init(struct mdp5_kms *mdp5_kms)
>   }
>   }
>
> - if (priv->hdmi) {
> - struct mdp5_interface intf = {
> - .num= 3,
> - .type   = INTF_HDMI,
> - .mode   = MDP5_INTF_MODE_NONE,
> - };
> -
> - /* Construct encoder for HDMI: */
> - encoder = mdp5_encoder_init(dev, );
> - if (IS_ERR(encoder)) {
> - dev_err(dev->dev, "failed to construct encoder\n");
> - ret = PTR_ERR(encoder);
> - goto fail;
> - }
> -
> - encoder->possible_crtcs = (1 << priv->num_crtcs) - 1;;
> - priv->encoders[priv->num_encoders++] 

[PATCH 1/2] drm/exynos: hdmi: Add support for Exynos7 HDMI

[Andrzej Hajda]

On 03/04/2015 10:54 AM, Ajay kumar wrote:
> On Wed, Mar 4, 2015 at 2:30 PM, Andrzej Hajda  wrote:
>> On 03/02/2015 09:40 AM, Ajay kumar wrote:
>>> Hi Andrej,
>>>
>>> On Fri, Feb 27, 2015 at 4:18 PM, Andrzej Hajda  
>>> wrote:
 Hi Ajay,

 Thanks for the patch.
>>> Thanks for reviewing the patch.
>>>
 On 02/26/2015 04:24 PM, Ajay Kumar wrote:
> Modify the exynos HDMI driver to support Exynos7 HDMI 1.4.
> * Add phy configs for Exynos7.
> * Exynos7 has a different clock structure for HDMI,
>   so introduce the new clocks.
> * Add sysreg support to enable HDMI SYSREG on Exynos7.
> * Exynos7 based boards need a DCDC_EN and LS_EN pins
>   for powering up HDMI. Add support for that too.
>
> Signed-off-by: Ajay Kumar 
> ---
>  .../devicetree/bindings/video/exynos_hdmi.txt  |   21 +-
>  drivers/gpu/drm/exynos/exynos_hdmi.c   |  252 
> 
>  drivers/gpu/drm/exynos/regs-hdmi.h |4 +
>  3 files changed, 231 insertions(+), 46 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt 
> b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> index 1fd8cf9..bb22a60 100644
> --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> @@ -6,6 +6,7 @@ Required properties:
>   2) "samsung,exynos4210-hdmi"
>   3) "samsung,exynos4212-hdmi"
>   4) "samsung,exynos5420-hdmi"
> + 5) "samsung,exynos7-hdmi"
 Why not "samsung,exynos7420-hdmi" ?
 What compatible will you use for Exynos7430 or higher chip number?
>>> I will leave this decision to Inki Dae or Kukjin.
>>>
>  - reg: physical base address of the hdmi and length of memory mapped
>   region.
>  - interrupts: interrupt number to the cpu.
> @@ -15,21 +16,33 @@ Required properties:
>   c) optional flags and pull up/down.
>  - clocks: list of clock IDs from SoC clock driver.
>   a) hdmi: Gate of HDMI IP bus clock.
> - b) sclk_hdmi: Gate of HDMI special clock.
> - c) sclk_pixel: Pixel special clock, one of the two possible inputs 
> of
> + HDMI clocks necessary for non exynos7:
> +  b) sclk_hdmi: Gate of HDMI special clock.
> +  c) sclk_pixel: Pixel special clock, one of the two possible inputs 
> of
>   HDMI clock mux.
> - d) sclk_hdmiphy: HDMI PHY clock output, one of two possible inputs 
> of
> +  d) sclk_hdmiphy: HDMI PHY clock output, one of two possible inputs 
> of
>   HDMI clock mux.
> - e) mout_hdmi: It is required by the driver to switch between the 2
> +  e) mout_hdmi: It is required by the driver to switch between the 2
>   parents i.e. sclk_pixel and sclk_hdmiphy. If hdmiphy is 
> stable
>   after configuration, parent is set to sclk_hdmiphy else
>   sclk_pixel.
> + HDMI clocks necessary for Exynos7:
> +  b) pclk_hdmiphy: Gate to HDMIPHY clock.
 According to specs there is also pclk_hdmi, why do you specify only this
 one?
>>> Right, I have reused "hdmi" gating clock for pclk_hdmi. That is why I have
>>> left "hdmi" clock as common for exynos7 and non-exynos7.
>> IMO it would be better to use separate entry for pclk_hdmi.
> Ok.
>
> +  c) hdmi_pixel: Gate clock of MUX output for I_PIXEL_CLK.
> +  d) hdmi_tmds: Gate clock of MUX output for I_TMDS_CLK.
 According to specs these clocks should be named i_pixel_clk and
 i_tmds_clk, shouldn't they?
>>> I actually took these changes from an "internal" code(non-DRM).
>>> The original author used these names, and I just carried the same names. :)
>>>
>  - clock-names: aliases as per driver requirements for above clock IDs:
>   "hdmi", "sclk_hdmi", "sclk_pixel", "sclk_hdmiphy" and "mout_hdmi".
>  - ddc: phandle to the hdmi ddc node
>  - phy: phandle to the hdmi phy node
>  - samsung,syscon-phandle: phandle for system controller node for PMU.
>
> +Only for Exynos7(when compatible = "samsung,exynos7-hdmi"):
> +- samsung,sysreg-phandle: phandle for system controller node for SYSREG 
> block.
> +
> +Optional properties:
> +- dcdc-gpios: OF device-tree gpio specification for HDMI_DCDC_EN pin.
> +- lsen-gpios: OF device-tree gpio specification for HDMI_LS_EN pin.
 What is purpose of these gpios?
>>> These 2 GPIOs need to be enabled to powerup HDMI on exynos7-espresso board.
>>> Other boards need not provide the GPIO.
>> HDMI is internal IP of SoC, so it is rather not configurable via pins.
>> Pin names suggests they are for DC-DC converter and level shifter, I guess
>> these are for HDMI connector, not the HDMI IP, am I right?
> Right, this is for HDMI connector.
>
>> Maybe better option is to use pinctrl for these gpios, or use 

[PATCH v2] mode: Retrieve only the current information for a Connector

[Chris Wilson]

On Wed, Mar 04, 2015 at 12:08:42PM +0100, Daniel Vetter wrote:
> On Wed, Mar 04, 2015 at 10:38:08AM +, Chris Wilson wrote:
> > +   if (conn.encoder_id) {
> > +   r->count_encoders = 1;
> 
> This only works for i915 where we only ever have 1 encoder. Other drivers
> reassign encoders depending upon output type (e.g. dvi-i vs dvi-d). Imo
> it'd be cleaner to do something like the below:

Not quite. This value is the currently active encoder_id for the
connector; there can only be one. As opposed to the array of associated
encoders that we normally supply on ouptut. Even i915 has multiple
encoders on connectors nowadays!
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH] drm/mm: Support 4 GiB and larger ranges

[Alex Deucher]

On Fri, Jan 23, 2015 at 3:05 AM, Thierry Reding
 wrote:
> From: Thierry Reding 
>
> The current implementation is limited by the number of addresses that
> fit into an unsigned long. This causes problems on 32-bit Tegra where
> unsigned long is 32-bit but drm_mm is used to manage an IOVA space of
> 4 GiB. Given the 32-bit limitation, the range is limited to 4 GiB - 1
> (or 4 GiB - 4 KiB for page granularity).
>
> This commit changes the start and size of the range to be an unsigned
> 64-bit integer, thus allowing much larger ranges to be supported.
>
> Signed-off-by: Thierry Reding 

Did this land yet?  I think we need this for for the full fix for the
case when device address space does not match CPU address space.
E.g., radeons have 40 or 48 bit internal address spaces.  On radeon's
with 4GB or more vram, the gart aperture ends up above that in the
GPU's address space which ends up getting truncated on 32 bit.  See
the discussion here:
http://lists.freedesktop.org/archives/dri-devel/2015-March/078614.html

Alex

> ---
>  drivers/gpu/drm/drm_mm.c | 152 
> ---
>  include/drm/drm_mm.h |  52 
>  2 files changed, 105 insertions(+), 99 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
> index 04a209e2b66d..7fc6f8bd4821 100644
> --- a/drivers/gpu/drm/drm_mm.c
> +++ b/drivers/gpu/drm/drm_mm.c
> @@ -91,29 +91,29 @@
>   */
>
>  static struct drm_mm_node *drm_mm_search_free_generic(const struct drm_mm 
> *mm,
> -   unsigned long size,
> +   u64 size,
> unsigned alignment,
> unsigned long color,
> enum drm_mm_search_flags 
> flags);
>  static struct drm_mm_node *drm_mm_search_free_in_range_generic(const struct 
> drm_mm *mm,
> -   unsigned long size,
> +   u64 size,
> unsigned alignment,
> unsigned long color,
> -   unsigned long start,
> -   unsigned long end,
> +   u64 start,
> +   u64 end,
> enum drm_mm_search_flags 
> flags);
>
>  static void drm_mm_insert_helper(struct drm_mm_node *hole_node,
>  struct drm_mm_node *node,
> -unsigned long size, unsigned alignment,
> +u64 size, unsigned alignment,
>  unsigned long color,
>  enum drm_mm_allocator_flags flags)
>  {
> struct drm_mm *mm = hole_node->mm;
> -   unsigned long hole_start = drm_mm_hole_node_start(hole_node);
> -   unsigned long hole_end = drm_mm_hole_node_end(hole_node);
> -   unsigned long adj_start = hole_start;
> -   unsigned long adj_end = hole_end;
> +   u64 hole_start = drm_mm_hole_node_start(hole_node);
> +   u64 hole_end = drm_mm_hole_node_end(hole_node);
> +   u64 adj_start = hole_start;
> +   u64 adj_end = hole_end;
>
> BUG_ON(node->allocated);
>
> @@ -124,12 +124,15 @@ static void drm_mm_insert_helper(struct drm_mm_node 
> *hole_node,
> adj_start = adj_end - size;
>
> if (alignment) {
> -   unsigned tmp = adj_start % alignment;
> -   if (tmp) {
> +   u64 tmp = adj_start;
> +   unsigned rem;
> +
> +   rem = do_div(tmp, alignment);
> +   if (rem) {
> if (flags & DRM_MM_CREATE_TOP)
> -   adj_start -= tmp;
> +   adj_start -= rem;
> else
> -   adj_start += alignment - tmp;
> +   adj_start += alignment - rem;
> }
> }
>
> @@ -176,9 +179,9 @@ static void drm_mm_insert_helper(struct drm_mm_node 
> *hole_node,
>  int drm_mm_reserve_node(struct drm_mm *mm, struct drm_mm_node *node)
>  {
> struct drm_mm_node *hole;
> -   unsigned long end = node->start + node->size;
> -   unsigned long hole_start;
> -   unsigned long hole_end;
> +   u64 end = node->start + node->size;
> +   u64 hole_start;
> +   u64 hole_end;
>
> BUG_ON(node == NULL);
>
> @@ -227,7 +230,7 @@ EXPORT_SYMBOL(drm_mm_reserve_node);
>   * 0 on success, -ENOSPC if there's no suitable hole.
>   */
>  int drm_mm_insert_node_generic(struct drm_mm *mm, struct drm_mm_node *node,
> -  unsigned long size, unsigned alignment,
> +

[PATCH v2] mode: Retrieve only the current information for a Connector

[Daniel Stone]

Hi,

On 4 March 2015 at 11:08, Daniel Vetter  wrote:
> +drmModeConnectorPtr drmModeGetConnector(int fd, uint32_t connector_id)
> +drmModeConnectorPtr drmModeGetConnector(int fd, uint32_t connector_id)

Testing would probably reveal that you wanted to call one of these
drmModeGetConnectorCurrent. :)

Cheers,
Daniel

[PATCH 4/4] drm/msm/mdp5: Make the intf connection in config module

["Stéphane Viau"]

> Hi,

Hi Archit,

>
> On 03/04/2015 12:06 AM, Stephane Viau wrote:
>> Up until now, we assume that eDP is tight to intf_0 and HDMI to
>> intf_3. This information shall actually come from the mdp5_cfg
>> module since it can change from one chip to another.
>>
>> Signed-off-by: Stephane Viau 
>> ---
>>   drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c |   8 +++
>>   drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h |   4 ++
>>   drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 111
>> ++--
>>   3 files changed, 74 insertions(+), 49 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
>> b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
>> index 72c075a..8bee023 100644
>> --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
>> +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
>> @@ -62,6 +62,10 @@ const struct mdp5_cfg_hw msm8x74_config = {
>>  .count = 4,
>>  .base = { 0x12500, 0x12700, 0x12900, 0x12b00 },
>>  },
>> +.intfs = {
>> +[0] = INTF_eDP,
>> +[3] = INTF_HDMI,
>> +},
>>  .max_clk = 2,
>>   };
>>
>> @@ -111,6 +115,10 @@ const struct mdp5_cfg_hw apq8084_config = {
>>  .count = 5,
>>  .base = { 0x12500, 0x12700, 0x12900, 0x12b00, 0x12d00 },
>>  },
>> +.intfs = {
>> +[0] = INTF_eDP,
>> +[3] = INTF_HDMI,
>> +},
>>  .max_clk = 32000,
>>   };
>>
>> diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h
>> b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h
>> index be149b3..4e91f14 100644
>> --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h
>> +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h
>> @@ -58,6 +58,8 @@ struct mdp5_smp_block {
>>  int reserved[MAX_CLIENTS];  /* # of MMBs allocated per client */
>>   };
>>
>> +#define MDP5_INTF_NUM_MAX   5
>> +
>>   struct mdp5_cfg_hw {
>>  char  *name;
>>
>> @@ -71,6 +73,8 @@ struct mdp5_cfg_hw {
>>  struct mdp5_sub_block ad;
>>  struct mdp5_sub_block intf;
>>
>> +u32 intfs[MDP5_INTF_NUM_MAX]; /* array of enum mdp5_intf_type */
>> +
>
> The array type could be "enum mdp5_intf_type" rather than u32.
>

The problem here is that mdp5_cfg.h must be included before mdp5.xml.h
(see mdp5_kms.h #24) so that mdp5_cfg pointer can be resolved in the
latter.
mdp5_cfg.h hence cannot use any types defined in mdp5.xml.h, including
'enum mdp5_intf_type'.

>>  uint32_t max_clk;
>>   };
>>
>> diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
>> b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
>> index 390d9d2..8cec00e 100644
>> --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
>> +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
>> @@ -161,6 +161,44 @@ int mdp5_enable(struct mdp5_kms *mdp5_kms)
>>  return 0;
>>   }
>>
>> +static int construct_encoder(struct mdp5_kms *mdp5_kms,
>> +enum mdp5_intf_type intf_type, int intf_num)
>> +{
>> +struct drm_device *dev = mdp5_kms->dev;
>> +struct msm_drm_private *priv = dev->dev_private;
>> +struct drm_encoder *encoder;
>> +struct mdp5_interface intf = {
>> +.num= intf_num,
>> +.type   = intf_type,
>> +.mode   = MDP5_INTF_MODE_NONE,
>> +};
>> +int ret = 0;
>> +
>> +encoder = mdp5_encoder_init(dev, );
>> +if (IS_ERR(encoder)) {
>> +ret = PTR_ERR(encoder);
>> +dev_err(dev->dev, "failed to construct encoder: %d\n", ret);
>> +return ret;
>> +}
>> +
>> +encoder->possible_crtcs = (1 << priv->num_crtcs) - 1;
>> +priv->encoders[priv->num_encoders++] = encoder;
>> +
>> +if (intf_type == INTF_HDMI) {
>> +ret = hdmi_modeset_init(priv->hdmi, dev, encoder);
>> +if (ret)
>> +dev_err(dev->dev, "failed to init HDMI: %d\n", ret);
>> +
>> +} else if (intf_type == INTF_eDP) {
>> +/* Construct bridge/connector for eDP: */
>> +ret = msm_edp_modeset_init(priv->edp, dev, encoder);
>> +if (ret)
>> +dev_err(dev->dev, "failed to init eDP: %d\n", ret);
>> +}
>> +
>> +return ret;
>> +}
>> +
>>   static int modeset_init(struct mdp5_kms *mdp5_kms)
>>   {
>>  static const enum mdp5_pipe crtcs[] = {
>> @@ -171,7 +209,6 @@ static int modeset_init(struct mdp5_kms *mdp5_kms)
>>  };
>>  struct drm_device *dev = mdp5_kms->dev;
>>  struct msm_drm_private *priv = dev->dev_private;
>> -struct drm_encoder *encoder;
>>  const struct mdp5_cfg_hw *hw_cfg;
>>  int i, ret;
>>
>> @@ -222,56 +259,29 @@ static int modeset_init(struct mdp5_kms *mdp5_kms)
>>  }
>>  }
>>
>> -if (priv->hdmi) {
>> -struct mdp5_interface intf = {
>> -.num= 3,
>> -.type   = INTF_HDMI,
>> -.mode   = MDP5_INTF_MODE_NONE,
>> -};
>> -
>> -/* Construct encoder for HDMI: */
>> -encoder = mdp5_encoder_init(dev, );
>> -if 

[PATCH] drm: Lighten sysfs connector 'status'

[Alex Deucher]

On Wed, Mar 4, 2015 at 10:25 AM, Chris Wilson  
wrote:
> Since the beginning, sysfs/connector/status has done a heavyweight
> detection of the current connector status. But no user, such as upowerd
> or logind, has ever desired to initiate a probe. Move the probing into a
> new attribute so that existing users get the behaviour they desire.

Reviewed-by: Alex Deucher 

>
> Signed-off-by: Chris Wilson 
> Cc: Daniel Vetter 
> Cc: David Herrmann 
> Cc: Dave Airlie 
> ---
>  drivers/gpu/drm/drm_sysfs.c | 14 +-
>  1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
> index 5c99d3773212..e4ee91a2bd28 100644
> --- a/drivers/gpu/drm/drm_sysfs.c
> +++ b/drivers/gpu/drm/drm_sysfs.c
> @@ -166,7 +166,7 @@ void drm_sysfs_destroy(void)
>  /*
>   * Connector properties
>   */
> -static ssize_t status_show(struct device *device,
> +static ssize_t detect_show(struct device *device,
>struct device_attribute *attr,
>char *buf)
>  {
> @@ -185,6 +185,16 @@ static ssize_t status_show(struct device *device,
> drm_get_connector_status_name(status));
>  }
>
> +static ssize_t status_show(struct device *device,
> +  struct device_attribute *attr,
> +  char *buf)
> +{
> +   struct drm_connector *connector = to_drm_connector(device);
> +
> +   return snprintf(buf, PAGE_SIZE, "%s\n",
> +   drm_get_connector_status_name(connector->status));
> +}
> +
>  static ssize_t dpms_show(struct device *device,
>struct device_attribute *attr,
>char *buf)
> @@ -339,12 +349,14 @@ static ssize_t select_subconnector_show(struct device 
> *device,
> drm_get_dvi_i_select_name((int)subconnector));
>  }
>
> +static DEVICE_ATTR_RO(detect);
>  static DEVICE_ATTR_RO(status);
>  static DEVICE_ATTR_RO(enabled);
>  static DEVICE_ATTR_RO(dpms);
>  static DEVICE_ATTR_RO(modes);
>
>  static struct attribute *connector_dev_attrs[] = {
> +   _attr_detect.attr,
> _attr_status.attr,
> _attr_enabled.attr,
> _attr_dpms.attr,
> --
> 2.1.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2] mode: Retrieve only the current information for a Connector

[Chris Wilson]

Add a new API that allows the caller to skip any forced probing, which
may require slow i2c to a remote display, and only report the currently
active mode and encoder for a Connector. This is often the information
of interest and is much, much faster than re-retrieving the link status
and EDIDs, e.g. if the caller only wishes to count the number of active
outputs.

v2: Fix error path to avoid double free after a failed GETCONNECTOR
ioctl.

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Cc: Damien Lespiau 
Cc: David Herrmann 
---
 tests/modeprint/modeprint.c | 18 -
 xf86drmMode.c   | 97 +
 xf86drmMode.h   | 17 +++-
 3 files changed, 128 insertions(+), 4 deletions(-)

diff --git a/tests/modeprint/modeprint.c b/tests/modeprint/modeprint.c
index 6f0d039..514d3ba 100644
--- a/tests/modeprint/modeprint.c
+++ b/tests/modeprint/modeprint.c
@@ -43,6 +43,7 @@

 #define ARRAY_SIZE(a) (sizeof(a) / sizeof(a[0]))

+int current;
 int connectors;
 int full_props;
 int edid;
@@ -272,7 +273,7 @@ int printRes(int fd, drmModeResPtr res)

if (connectors) {
for (i = 0; i < res->count_connectors; i++) {
-   connector = drmModeGetConnector(fd, res->connectors[i]);
+   connector = (current ? drmModeGetConnectorCurrent : 
drmModeGetConnector) (fd, res->connectors[i]);

if (!connector)
printf("Could not get connector %i\n", 
res->connectors[i]);
@@ -331,6 +332,7 @@ int printRes(int fd, drmModeResPtr res)

 void args(int argc, char **argv)
 {
+   int defaults = 1;
int i;

fbs = 0;
@@ -341,32 +343,41 @@ void args(int argc, char **argv)
full_modes = 0;
full_props = 0;
connectors = 0;
+   current = 0;

module_name = argv[1];

for (i = 2; i < argc; i++) {
if (strcmp(argv[i], "-fb") == 0) {
fbs = 1;
+   defaults = 0;
} else if (strcmp(argv[i], "-crtcs") == 0) {
crtcs = 1;
+   defaults = 0;
} else if (strcmp(argv[i], "-cons") == 0) {
connectors = 1;
modes = 1;
+   defaults = 0;
} else if (strcmp(argv[i], "-modes") == 0) {
connectors = 1;
modes = 1;
+   defaults = 0;
} else if (strcmp(argv[i], "-full") == 0) {
connectors = 1;
modes = 1;
full_modes = 1;
+   defaults = 0;
} else if (strcmp(argv[i], "-props") == 0) {
connectors = 1;
full_props = 1;
+   defaults = 0;
} else if (strcmp(argv[i], "-edids") == 0) {
connectors = 1;
edid = 1;
+   defaults = 0;
} else if (strcmp(argv[i], "-encoders") == 0) {
encoders = 1;
+   defaults = 0;
} else if (strcmp(argv[i], "-v") == 0) {
fbs = 1;
edid = 1;
@@ -376,10 +387,13 @@ void args(int argc, char **argv)
full_modes = 1;
full_props = 1;
connectors = 1;
+   defaults = 0;
+   } else if (strcmp(argv[i], "-current") == 0) {
+   current = 1;
}
}

-   if (argc == 2) {
+   if (defaults) {
fbs = 1;
edid = 1;
crtcs = 1;
diff --git a/xf86drmMode.c b/xf86drmMode.c
index 9ea8fe7..4433dc7 100644
--- a/xf86drmMode.c
+++ b/xf86drmMode.c
@@ -572,6 +572,103 @@ err_allocs:
return r;
 }

+drmModeConnectorPtr drmModeGetConnectorCurrent(int fd, uint32_t connector_id)
+{
+   struct drm_mode_modeinfo mode;
+   struct drm_mode_get_encoder enc;
+   struct drm_mode_get_connector conn;
+   unsigned int num_props = 0;
+   drmModeConnectorPtr r;
+
+   memclear(conn);
+   conn.connector_id = connector_id;
+   do {
+   if (conn.count_props) {
+   drmFree(U642VOID(conn.props_ptr));
+   conn.props_ptr = 
VOID2U64(drmMalloc(conn.count_props*sizeof(uint32_t)));
+   if (!conn.props_ptr)
+   goto err;
+
+   drmFree(U642VOID(conn.prop_values_ptr));
+   conn.prop_values_ptr = 
VOID2U64(drmMalloc(conn.count_props*sizeof(uint64_t)));
+   if (!conn.prop_values_ptr)
+   goto err;
+
+   num_props = conn.count_props;
+   }
+
+   conn.count_modes 

[PATCH] drm/ttm: device address space != CPU address space

[Thomas Hellstrom]

OK. Understood.

Also, conditioned on drm_mm compatibility (which is really a driver issue),

Acked-by: Thomas Hellstrom 


On 03/04/2015 10:33 AM, Christian König wrote:
> Even shifting doesn't help here. We have up to 48bits of physical
> address space on modern systems with still 4K page size.
>
> This means 48-12=36bit address space, that won't fit into a 32bit
> integer no matter what.
>
> Assuming we have already double checked drm_mm the patch is
> Reviewed-by: Christian König 
>
> Regards,
> Christian.
>
> On 04.03.2015 09:01, Thomas Hellstrom wrote:
>> Hi!
>>
>> IIRC, the interpretation of gpu_offset is fully controlled by the
>> driver. That means to keep a native integer size
>> you should be able to set
>>
>> radeon_gpu_offset := (ttm_gpu_offset << suitable_shift);
>>
>> However, if you feel that this is too intrusive in the driver, I'm not
>> against the current patch as it stands. It's important, however that the
>> interactions with drm_mm is sorted out. I'm not sure the patch that
>> converted drm_mm to 64-bit instead
>> of unsigned long went in. (There were similar arguments against that
>> patch).
>>
>> Thanks,
>> Thomas
>>
>>
>> On 03/04/2015 06:18 AM, Alex Deucher wrote:
>>> We need to store device offsets in 64 bit as the device
>>> address space may be larger than the CPU's.
>>>
>>> Fixes GPU init failures on radeons with 4GB or more of
>>> vram on 32 bit kernels.  We put vram at the start of the
>>> GPU's address space so the gart aperture starts at 4 GB
>>> causing all GPU addresses in the gart aperture to get
>>> truncated.
>>>
>>> bug:
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.freedesktop.org_show-5Fbug.cgi-3Fid-3D89072=AwIBAg=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=vpukPkBtpoNQp2IUKuFviOmPNYWVKmen3Jeeu55zmEA=M1rvbqZd6hlmRIsZmBXhSypX4cSQqZSddym13SRVKtg=sriG7bnxL46LbaYmq_FnswHY9WOrPvTbdK7um05zoxE=
>>>
>>>
>>> Signed-off-by: Alex Deucher 
>>> Cc: thellstrom at vmware.com
>>> ---
>>> Untested.  Someone more familiar with the ttm internals can
>>> probably point out any additional bits I missed.  Heading to
>>> bed now.
>>>
>>>   drivers/gpu/drm/ttm/ttm_bo.c| 2 +-
>>>   include/drm/ttm/ttm_bo_api.h| 2 +-
>>>   include/drm/ttm/ttm_bo_driver.h | 2 +-
>>>   3 files changed, 3 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c
>>> b/drivers/gpu/drm/ttm/ttm_bo.c
>>> index d395b0b..8d9b7de 100644
>>> --- a/drivers/gpu/drm/ttm/ttm_bo.c
>>> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
>>> @@ -74,7 +74,7 @@ static void ttm_mem_type_debug(struct
>>> ttm_bo_device *bdev, int mem_type)
>>>   pr_err("has_type: %d\n", man->has_type);
>>>   pr_err("use_type: %d\n", man->use_type);
>>>   pr_err("flags: 0x%08X\n", man->flags);
>>> -pr_err("gpu_offset: 0x%08lX\n", man->gpu_offset);
>>> +pr_err("gpu_offset: 0x%08llX\n", man->gpu_offset);
>>>   pr_err("size: %llu\n", man->size);
>>>   pr_err("available_caching: 0x%08X\n",
>>> man->available_caching);
>>>   pr_err("default_caching: 0x%08X\n", man->default_caching);
>>> diff --git a/include/drm/ttm/ttm_bo_api.h
>>> b/include/drm/ttm/ttm_bo_api.h
>>> index 0ccf7f2..c768ddf 100644
>>> --- a/include/drm/ttm/ttm_bo_api.h
>>> +++ b/include/drm/ttm/ttm_bo_api.h
>>> @@ -249,7 +249,7 @@ struct ttm_buffer_object {
>>>* either of these locks held.
>>>*/
>>>   -unsigned long offset;
>>> +uint64_t offset; /* GPU address space is independent of CPU
>>> word size */
>>>   uint32_t cur_placement;
>>> struct sg_table *sg;
>>> diff --git a/include/drm/ttm/ttm_bo_driver.h
>>> b/include/drm/ttm/ttm_bo_driver.h
>>> index 142d752..813042c 100644
>>> --- a/include/drm/ttm/ttm_bo_driver.h
>>> +++ b/include/drm/ttm/ttm_bo_driver.h
>>> @@ -277,7 +277,7 @@ struct ttm_mem_type_manager {
>>>   bool has_type;
>>>   bool use_type;
>>>   uint32_t flags;
>>> -unsigned long gpu_offset;
>>> +uint64_t gpu_offset; /* GPU address space is independent of CPU
>>> word size */
>>>   uint64_t size;
>>>   uint32_t available_caching;
>>>   uint32_t default_caching;
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.freedesktop.org_mailman_listinfo_dri-2Ddevel=AwIDaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=vpukPkBtpoNQp2IUKuFviOmPNYWVKmen3Jeeu55zmEA=OZUnRVpjH7RJ-rhjZ9RYGh_B9euuww9Hi2CoMW17QZY=mxUmoWCnh6WYNIPj7pCHCoCNuaAE-_rZAGKJpVd1r3Q=
>
>

[PATCH] drm/ttm: device address space != CPU address space

[Christian König]

Even shifting doesn't help here. We have up to 48bits of physical 
address space on modern systems with still 4K page size.

This means 48-12=36bit address space, that won't fit into a 32bit 
integer no matter what.

Assuming we have already double checked drm_mm the patch is Reviewed-by: 
Christian König 

Regards,
Christian.

On 04.03.2015 09:01, Thomas Hellstrom wrote:
> Hi!
>
> IIRC, the interpretation of gpu_offset is fully controlled by the
> driver. That means to keep a native integer size
> you should be able to set
>
> radeon_gpu_offset := (ttm_gpu_offset << suitable_shift);
>
> However, if you feel that this is too intrusive in the driver, I'm not
> against the current patch as it stands. It's important, however that the
> interactions with drm_mm is sorted out. I'm not sure the patch that
> converted drm_mm to 64-bit instead
> of unsigned long went in. (There were similar arguments against that patch).
>
> Thanks,
> Thomas
>
>
> On 03/04/2015 06:18 AM, Alex Deucher wrote:
>> We need to store device offsets in 64 bit as the device
>> address space may be larger than the CPU's.
>>
>> Fixes GPU init failures on radeons with 4GB or more of
>> vram on 32 bit kernels.  We put vram at the start of the
>> GPU's address space so the gart aperture starts at 4 GB
>> causing all GPU addresses in the gart aperture to get
>> truncated.
>>
>> bug:
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.freedesktop.org_show-5Fbug.cgi-3Fid-3D89072=AwIBAg=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=vpukPkBtpoNQp2IUKuFviOmPNYWVKmen3Jeeu55zmEA=M1rvbqZd6hlmRIsZmBXhSypX4cSQqZSddym13SRVKtg=sriG7bnxL46LbaYmq_FnswHY9WOrPvTbdK7um05zoxE=
>>
>> Signed-off-by: Alex Deucher 
>> Cc: thellstrom at vmware.com
>> ---
>> Untested.  Someone more familiar with the ttm internals can
>> probably point out any additional bits I missed.  Heading to
>> bed now.
>>
>>   drivers/gpu/drm/ttm/ttm_bo.c| 2 +-
>>   include/drm/ttm/ttm_bo_api.h| 2 +-
>>   include/drm/ttm/ttm_bo_driver.h | 2 +-
>>   3 files changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
>> index d395b0b..8d9b7de 100644
>> --- a/drivers/gpu/drm/ttm/ttm_bo.c
>> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
>> @@ -74,7 +74,7 @@ static void ttm_mem_type_debug(struct ttm_bo_device *bdev, 
>> int mem_type)
>>  pr_err("has_type: %d\n", man->has_type);
>>  pr_err("use_type: %d\n", man->use_type);
>>  pr_err("flags: 0x%08X\n", man->flags);
>> -pr_err("gpu_offset: 0x%08lX\n", man->gpu_offset);
>> +pr_err("gpu_offset: 0x%08llX\n", man->gpu_offset);
>>  pr_err("size: %llu\n", man->size);
>>  pr_err("available_caching: 0x%08X\n", man->available_caching);
>>  pr_err("default_caching: 0x%08X\n", man->default_caching);
>> diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
>> index 0ccf7f2..c768ddf 100644
>> --- a/include/drm/ttm/ttm_bo_api.h
>> +++ b/include/drm/ttm/ttm_bo_api.h
>> @@ -249,7 +249,7 @@ struct ttm_buffer_object {
>>   * either of these locks held.
>>   */
>>   
>> -unsigned long offset;
>> +uint64_t offset; /* GPU address space is independent of CPU word size */
>>  uint32_t cur_placement;
>>   
>>  struct sg_table *sg;
>> diff --git a/include/drm/ttm/ttm_bo_driver.h 
>> b/include/drm/ttm/ttm_bo_driver.h
>> index 142d752..813042c 100644
>> --- a/include/drm/ttm/ttm_bo_driver.h
>> +++ b/include/drm/ttm/ttm_bo_driver.h
>> @@ -277,7 +277,7 @@ struct ttm_mem_type_manager {
>>  bool has_type;
>>  bool use_type;
>>  uint32_t flags;
>> -unsigned long gpu_offset;
>> +uint64_t gpu_offset; /* GPU address space is independent of CPU word 
>> size */
>>  uint64_t size;
>>  uint32_t available_caching;
>>  uint32_t default_caching;
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] mode: Retrieve only the current information for a Connector

[Chris Wilson]

Add a new API that allows the caller to skip any forced probing, which
may require slow i2c to a remote display, and only report the currently
active mode and encoder for a Connector. This is often the information
of interest and is much, much faster than re-retrieving the link status
and EDIDs, e.g. if the caller only wishes to count the number of active
outputs.

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Cc: Damien Lespiau 
C: David Herrmann 
---
 tests/modeprint/modeprint.c | 18 -
 xf86drmMode.c   | 98 +
 xf86drmMode.h   | 17 +++-
 3 files changed, 129 insertions(+), 4 deletions(-)

diff --git a/tests/modeprint/modeprint.c b/tests/modeprint/modeprint.c
index 6f0d039..514d3ba 100644
--- a/tests/modeprint/modeprint.c
+++ b/tests/modeprint/modeprint.c
@@ -43,6 +43,7 @@

 #define ARRAY_SIZE(a) (sizeof(a) / sizeof(a[0]))

+int current;
 int connectors;
 int full_props;
 int edid;
@@ -272,7 +273,7 @@ int printRes(int fd, drmModeResPtr res)

if (connectors) {
for (i = 0; i < res->count_connectors; i++) {
-   connector = drmModeGetConnector(fd, res->connectors[i]);
+   connector = (current ? drmModeGetConnectorCurrent : 
drmModeGetConnector) (fd, res->connectors[i]);

if (!connector)
printf("Could not get connector %i\n", 
res->connectors[i]);
@@ -331,6 +332,7 @@ int printRes(int fd, drmModeResPtr res)

 void args(int argc, char **argv)
 {
+   int defaults = 1;
int i;

fbs = 0;
@@ -341,32 +343,41 @@ void args(int argc, char **argv)
full_modes = 0;
full_props = 0;
connectors = 0;
+   current = 0;

module_name = argv[1];

for (i = 2; i < argc; i++) {
if (strcmp(argv[i], "-fb") == 0) {
fbs = 1;
+   defaults = 0;
} else if (strcmp(argv[i], "-crtcs") == 0) {
crtcs = 1;
+   defaults = 0;
} else if (strcmp(argv[i], "-cons") == 0) {
connectors = 1;
modes = 1;
+   defaults = 0;
} else if (strcmp(argv[i], "-modes") == 0) {
connectors = 1;
modes = 1;
+   defaults = 0;
} else if (strcmp(argv[i], "-full") == 0) {
connectors = 1;
modes = 1;
full_modes = 1;
+   defaults = 0;
} else if (strcmp(argv[i], "-props") == 0) {
connectors = 1;
full_props = 1;
+   defaults = 0;
} else if (strcmp(argv[i], "-edids") == 0) {
connectors = 1;
edid = 1;
+   defaults = 0;
} else if (strcmp(argv[i], "-encoders") == 0) {
encoders = 1;
+   defaults = 0;
} else if (strcmp(argv[i], "-v") == 0) {
fbs = 1;
edid = 1;
@@ -376,10 +387,13 @@ void args(int argc, char **argv)
full_modes = 1;
full_props = 1;
connectors = 1;
+   defaults = 0;
+   } else if (strcmp(argv[i], "-current") == 0) {
+   current = 1;
}
}

-   if (argc == 2) {
+   if (defaults) {
fbs = 1;
edid = 1;
crtcs = 1;
diff --git a/xf86drmMode.c b/xf86drmMode.c
index 9ea8fe7..5544e5b 100644
--- a/xf86drmMode.c
+++ b/xf86drmMode.c
@@ -572,6 +572,104 @@ err_allocs:
return r;
 }

+drmModeConnectorPtr drmModeGetConnectorCurrent(int fd, uint32_t connector_id)
+{
+   struct drm_mode_modeinfo mode;
+   struct drm_mode_get_encoder enc;
+   struct drm_mode_get_connector conn;
+   unsigned int num_props = 0;
+   drmModeConnectorPtr r;
+
+   memclear(conn);
+   conn.connector_id = connector_id;
+   do {
+   if (conn.count_props) {
+   drmFree(U642VOID(conn.props_ptr));
+   drmFree(U642VOID(conn.prop_values_ptr));
+
+   conn.props_ptr = 
VOID2U64(drmMalloc(conn.count_props*sizeof(uint32_t)));
+   if (!conn.props_ptr)
+   goto err;
+
+   conn.prop_values_ptr = 
VOID2U64(drmMalloc(conn.count_props*sizeof(uint64_t)));
+   if (!conn.prop_values_ptr)
+   goto err;
+
+   num_props = conn.count_props;
+   }
+
+   conn.count_modes = 1; /* skip detect */
+   conn.modes_ptr = (uintptr_t)
+   

[PATCH v2] drm/i915: gen4: work around hang during hibernation

[Jani Nikula]

On Mon, 02 Mar 2015, Bjørn Mork  wrote:
> Jani Nikula  writes:
>
>> On Mon, 02 Mar 2015, Imre Deak  wrote:
>>> Bjørn reported that his machine hang during hibernation and eventually
>>> bisected the problem to the following commit:
>>>
>>> commit da2bc1b9db3351addd293e5b82757efe1f77ed1d
>>> Author: Imre Deak 
>>> Date:   Thu Oct 23 19:23:26 2014 +0300
>>>
>>> drm/i915: add poweroff_late handler
>>>
>>> The problem seems to be that after the kernel puts the device into D3
>>> the BIOS still tries to access it, or otherwise assumes that it's in D0.
>>> This is clearly bogus, since ACPI mandates that devices are put into D3
>>> by the OSPM if they are not wake-up sources. In the future we want to
>>> unify more of the driver's runtime and system suspend paths, for example
>>> by skipping all the system suspend/hibernation hooks if the device is
>>> runtime suspended already. Accordingly for all other platforms the goal
>>> is still to properly power down the device during hibernation.
>>>
>>> v2:
>>> - Another GEN4 Lenovo laptop had the same issue, while platforms from
>>>   other vendors (including mobile and desktop, GEN4 and non-GEN4) seem
>>>   to work fine. Based on this apply the workaround on all GEN4 Lenovo
>>>   platforms.
>>> - add code comment about failing platforms (Ville)
>>>
>>> Reference: 
>>> http://lists.freedesktop.org/archives/intel-gfx/2015-February/060633.html
>>> Reported-and-bisected-by: Bjørn Mork 
>>> Signed-off-by: Imre Deak 
>>
>> Bjørn, I would really appreciate your Tested-by on this patch before I
>> queue it for v4.0 and cc: stable for v3.19.
>
> No problem. This version still works fine for me.  Feel free to add
>
> Tested-by: Bjørn Mork 

Pushed to drm-intel-fixes with Daniel's IRC ack. Thanks for the patch
and testing.

BR,
Jani.


>
>
>
> Bjørn

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH 1/2] drm/exynos: hdmi: Add support for Exynos7 HDMI

[Andrzej Hajda]

On 03/02/2015 09:40 AM, Ajay kumar wrote:
> Hi Andrej,
>
> On Fri, Feb 27, 2015 at 4:18 PM, Andrzej Hajda  wrote:
>> Hi Ajay,
>>
>> Thanks for the patch.
> Thanks for reviewing the patch.
>
>> On 02/26/2015 04:24 PM, Ajay Kumar wrote:
>>> Modify the exynos HDMI driver to support Exynos7 HDMI 1.4.
>>> * Add phy configs for Exynos7.
>>> * Exynos7 has a different clock structure for HDMI,
>>>   so introduce the new clocks.
>>> * Add sysreg support to enable HDMI SYSREG on Exynos7.
>>> * Exynos7 based boards need a DCDC_EN and LS_EN pins
>>>   for powering up HDMI. Add support for that too.
>>>
>>> Signed-off-by: Ajay Kumar 
>>> ---
>>>  .../devicetree/bindings/video/exynos_hdmi.txt  |   21 +-
>>>  drivers/gpu/drm/exynos/exynos_hdmi.c   |  252 
>>> 
>>>  drivers/gpu/drm/exynos/regs-hdmi.h |4 +
>>>  3 files changed, 231 insertions(+), 46 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt 
>>> b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>>> index 1fd8cf9..bb22a60 100644
>>> --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>>> +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>>> @@ -6,6 +6,7 @@ Required properties:
>>>   2) "samsung,exynos4210-hdmi"
>>>   3) "samsung,exynos4212-hdmi"
>>>   4) "samsung,exynos5420-hdmi"
>>> + 5) "samsung,exynos7-hdmi"
>> Why not "samsung,exynos7420-hdmi" ?
>> What compatible will you use for Exynos7430 or higher chip number?
> I will leave this decision to Inki Dae or Kukjin.
>
>>>  - reg: physical base address of the hdmi and length of memory mapped
>>>   region.
>>>  - interrupts: interrupt number to the cpu.
>>> @@ -15,21 +16,33 @@ Required properties:
>>>   c) optional flags and pull up/down.
>>>  - clocks: list of clock IDs from SoC clock driver.
>>>   a) hdmi: Gate of HDMI IP bus clock.
>>> - b) sclk_hdmi: Gate of HDMI special clock.
>>> - c) sclk_pixel: Pixel special clock, one of the two possible inputs of
>>> + HDMI clocks necessary for non exynos7:
>>> +  b) sclk_hdmi: Gate of HDMI special clock.
>>> +  c) sclk_pixel: Pixel special clock, one of the two possible inputs of
>>>   HDMI clock mux.
>>> - d) sclk_hdmiphy: HDMI PHY clock output, one of two possible inputs of
>>> +  d) sclk_hdmiphy: HDMI PHY clock output, one of two possible inputs of
>>>   HDMI clock mux.
>>> - e) mout_hdmi: It is required by the driver to switch between the 2
>>> +  e) mout_hdmi: It is required by the driver to switch between the 2
>>>   parents i.e. sclk_pixel and sclk_hdmiphy. If hdmiphy is stable
>>>   after configuration, parent is set to sclk_hdmiphy else
>>>   sclk_pixel.
>>> + HDMI clocks necessary for Exynos7:
>>> +  b) pclk_hdmiphy: Gate to HDMIPHY clock.
>> According to specs there is also pclk_hdmi, why do you specify only this
>> one?
> Right, I have reused "hdmi" gating clock for pclk_hdmi. That is why I have
> left "hdmi" clock as common for exynos7 and non-exynos7.

IMO it would be better to use separate entry for pclk_hdmi.

>>> +  c) hdmi_pixel: Gate clock of MUX output for I_PIXEL_CLK.
>>> +  d) hdmi_tmds: Gate clock of MUX output for I_TMDS_CLK.
>> According to specs these clocks should be named i_pixel_clk and
>> i_tmds_clk, shouldn't they?
> I actually took these changes from an "internal" code(non-DRM).
> The original author used these names, and I just carried the same names. :)
>
>>>  - clock-names: aliases as per driver requirements for above clock IDs:
>>>   "hdmi", "sclk_hdmi", "sclk_pixel", "sclk_hdmiphy" and "mout_hdmi".
>>>  - ddc: phandle to the hdmi ddc node
>>>  - phy: phandle to the hdmi phy node
>>>  - samsung,syscon-phandle: phandle for system controller node for PMU.
>>>
>>> +Only for Exynos7(when compatible = "samsung,exynos7-hdmi"):
>>> +- samsung,sysreg-phandle: phandle for system controller node for SYSREG 
>>> block.
>>> +
>>> +Optional properties:
>>> +- dcdc-gpios: OF device-tree gpio specification for HDMI_DCDC_EN pin.
>>> +- lsen-gpios: OF device-tree gpio specification for HDMI_LS_EN pin.
>> What is purpose of these gpios?
> These 2 GPIOs need to be enabled to powerup HDMI on exynos7-espresso board.
> Other boards need not provide the GPIO.

HDMI is internal IP of SoC, so it is rather not configurable via pins.
Pin names suggests they are for DC-DC converter and level shifter, I guess
these are for HDMI connector, not the HDMI IP, am I right?

Maybe better option is to use pinctrl for these gpios, or use gpio
regulator, hard
to guess without documentation.

Regards
Andrzej

[PATCH 1/8] clk: add helper function clk_is_match()

[Geert Uytterhoeven]

On Wed, Feb 25, 2015 at 6:27 PM, Mike Turquette  
wrote:
> From: Michael Turquette 
> Date: Wed, 25 Feb 2015 09:11:01 -0800
> Subject: [PATCH] clk: introduce clk_is_match
>
> Some drivers compare struct clk pointers as a means of knowing
> if the two pointers reference the same clock hardware. This behavior is
> dubious (drivers must not dereference struct clk), but did not cause any
> regressions until the per-user struct clk patch was merged. Now the test
> for matching clk's will always fail with per-user struct clk's.
>
> clk_is_match is introduced to fix the regression and prevent drivers
> from comparing the pointers manually.
>
> Fixes: 035a61c314eb ("clk: Make clk API return per-user struct clk instances")
> Cc: Russell King 
> Cc: Stephen Boyd 
> Cc: Shawn Guo 
> Cc: Tomeu Vizoso 
> Signed-off-by: Michael Turquette 
> ---
>  drivers/clk/clk.c   | 26 ++
>  include/linux/clk.h | 18 ++
>  2 files changed, 44 insertions(+)
>
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index eb01529..09670de 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -2171,6 +2171,32 @@ int clk_get_phase(struct clk *clk)
>  }
>
>  /**
> + * clk_is_match - check if two clk's point to the same hardware clock
> + * @p: clk compared against q
> + * @q: clk compared against p
> + *
> + * Returns true if the two struct clk pointers both point to the same 
> hardware
> + * clock node. Put differently, returns true if struct clk *p and struct clk 
> *q
> + * share the same struct clk_core object.
> + *
> + * Returns false otherwise. Note that two NULL clks are treated as matching.
> + */
> +bool clk_is_match(struct clk *p, struct clk *q)

const struct clk *p, const struct clk *q

> --- a/include/linux/clk.h
> +++ b/include/linux/clk.h
> @@ -376,6 +376,19 @@ struct clk *clk_get_parent(struct clk *clk);
>   */
>  struct clk *clk_get_sys(const char *dev_id, const char *con_id);
>
> +/**
> + * clk_is_match - check if two clk's point to the same hardware clock
> + * @p: clk compared against q
> + * @q: clk compared against p
> + *
> + * Returns true if the two struct clk pointers both point to the same 
> hardware
> + * clock node. Put differently, returns true if struct clk *p and struct clk 
> *q
> + * share the same struct clk_core object.
> + *
> + * Returns false otherwise. Note that two NULL clks are treated as matching.
> + */
> +bool clk_is_match(struct clk *p, struct clk *q);

const struct clk *p, const struct clk *q

> +
>  #else /* !CONFIG_HAVE_CLK */
>
>  static inline struct clk *clk_get(struct device *dev, const char *id)
> @@ -429,6 +442,11 @@ static inline struct clk *clk_get_parent(struct clk *clk)
> return NULL;
>  }
>
> +static inline bool clk_is_match(struct clk *p, struct clk *q)

const struct clk *p, const struct clk *q

> +{
> +   return p == q ? true : false;

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 
linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

[PATCH 1/8] clk: add helper function clk_is_match()

[Russell King - ARM Linux]

On Wed, Feb 25, 2015 at 09:27:57AM -0800, Mike Turquette wrote:
> +static inline bool clk_is_match(struct clk *p, struct clk *q)
> +{
> + return p == q ? true : false;

When they created the C standard, they already taught the compiler that
p == q returns a true / false boolean value; there's no need for ?: here.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

[PATCH] drm: Fix trivial typos in comments

[Yannick Guerrini]

Change 'pixes' to 'pixels'
Change 'enabel' to 'enable'
Change 'enabeling' to 'enabling'

Signed-off-by: Yannick Guerrini 
---
 drivers/gpu/drm/drm_modes.c   | 4 ++--
 drivers/gpu/drm/i2c/adv7511.c | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 487d0e3..2cca85f 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -278,7 +278,7 @@ struct drm_display_mode *drm_cvt_mode(struct drm_device 
*dev, int hdisplay,
hblank = drm_mode->hdisplay * hblank_percentage /
 (100 * HV_FACTOR - hblank_percentage);
hblank -= hblank % (2 * CVT_H_GRANULARITY);
-   /* 14. find the total pixes per line */
+   /* 14. find the total pixels per line */
drm_mode->htotal = drm_mode->hdisplay + hblank;
drm_mode->hsync_end = drm_mode->hdisplay + hblank / 2;
drm_mode->hsync_start = drm_mode->hsync_end -
@@ -1209,7 +1209,7 @@ EXPORT_SYMBOL(drm_mode_connector_list_update);
  * x[M][R][-][@][i][m][eDd]
  *
  * The intermediate drm_cmdline_mode structure is required to store additional
- * options from the command line modline like the force-enabel/disable flag.
+ * options from the command line modline like the force-enable/disable flag.
  *
  * Returns:
  * True if a valid modeline has been parsed, false otherwise.
diff --git a/drivers/gpu/drm/i2c/adv7511.c b/drivers/gpu/drm/i2c/adv7511.c
index fa140e0..61aa824 100644
--- a/drivers/gpu/drm/i2c/adv7511.c
+++ b/drivers/gpu/drm/i2c/adv7511.c
@@ -573,7 +573,7 @@ static void adv7511_encoder_dpms(struct drm_encoder 
*encoder, int mode)
 * goes low the adv7511 is reset and the outputs are disabled
 * which might cause the monitor to go to standby again. To
 * avoid this we ignore the HDP pin for the first few seconds
-* after enabeling the output.
+* after enabling the output.
 */
regmap_update_bits(adv7511->regmap, ADV7511_REG_POWER2,
   ADV7511_REG_POWER2_HDP_SRC_MASK,
-- 
1.9.5.msysgit.0

[Bug 90741] Radeon: System pauses on TAHITI

[bugzilla-dae...@bugzilla.kernel.org]

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

--- Comment #79 from Maarten Lankhorst  ---
Yeah all patches are obsolete except attachment 166571 and the posting read
patches..

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH] drm/ttm: device address space != CPU address space

[Thomas Hellstrom]

Hi!

IIRC, the interpretation of gpu_offset is fully controlled by the
driver. That means to keep a native integer size
you should be able to set

radeon_gpu_offset := (ttm_gpu_offset << suitable_shift);

However, if you feel that this is too intrusive in the driver, I'm not
against the current patch as it stands. It's important, however that the
interactions with drm_mm is sorted out. I'm not sure the patch that
converted drm_mm to 64-bit instead
of unsigned long went in. (There were similar arguments against that patch).

Thanks,
Thomas


On 03/04/2015 06:18 AM, Alex Deucher wrote:
> We need to store device offsets in 64 bit as the device
> address space may be larger than the CPU's.
>
> Fixes GPU init failures on radeons with 4GB or more of
> vram on 32 bit kernels.  We put vram at the start of the
> GPU's address space so the gart aperture starts at 4 GB
> causing all GPU addresses in the gart aperture to get
> truncated.
>
> bug:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.freedesktop.org_show-5Fbug.cgi-3Fid-3D89072=AwIBAg=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=vpukPkBtpoNQp2IUKuFviOmPNYWVKmen3Jeeu55zmEA=M1rvbqZd6hlmRIsZmBXhSypX4cSQqZSddym13SRVKtg=sriG7bnxL46LbaYmq_FnswHY9WOrPvTbdK7um05zoxE=
>  
>
> Signed-off-by: Alex Deucher 
> Cc: thellstrom at vmware.com
> ---
> Untested.  Someone more familiar with the ttm internals can
> probably point out any additional bits I missed.  Heading to
> bed now.
>
>  drivers/gpu/drm/ttm/ttm_bo.c| 2 +-
>  include/drm/ttm/ttm_bo_api.h| 2 +-
>  include/drm/ttm/ttm_bo_driver.h | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index d395b0b..8d9b7de 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -74,7 +74,7 @@ static void ttm_mem_type_debug(struct ttm_bo_device *bdev, 
> int mem_type)
>   pr_err("has_type: %d\n", man->has_type);
>   pr_err("use_type: %d\n", man->use_type);
>   pr_err("flags: 0x%08X\n", man->flags);
> - pr_err("gpu_offset: 0x%08lX\n", man->gpu_offset);
> + pr_err("gpu_offset: 0x%08llX\n", man->gpu_offset);
>   pr_err("size: %llu\n", man->size);
>   pr_err("available_caching: 0x%08X\n", man->available_caching);
>   pr_err("default_caching: 0x%08X\n", man->default_caching);
> diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
> index 0ccf7f2..c768ddf 100644
> --- a/include/drm/ttm/ttm_bo_api.h
> +++ b/include/drm/ttm/ttm_bo_api.h
> @@ -249,7 +249,7 @@ struct ttm_buffer_object {
>* either of these locks held.
>*/
>  
> - unsigned long offset;
> + uint64_t offset; /* GPU address space is independent of CPU word size */
>   uint32_t cur_placement;
>  
>   struct sg_table *sg;
> diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
> index 142d752..813042c 100644
> --- a/include/drm/ttm/ttm_bo_driver.h
> +++ b/include/drm/ttm/ttm_bo_driver.h
> @@ -277,7 +277,7 @@ struct ttm_mem_type_manager {
>   bool has_type;
>   bool use_type;
>   uint32_t flags;
> - unsigned long gpu_offset;
> + uint64_t gpu_offset; /* GPU address space is independent of CPU word 
> size */
>   uint64_t size;
>   uint32_t available_caching;
>   uint32_t default_caching;

[Bug 85647] Random radeonsi crashes with mesa 10.3.x

[bugzilla-dae...@freedesktop.org]

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

--- Comment #44 from Hannu  ---
Created attachment 113981
  --> https://bugs.freedesktop.org/attachment.cgi?id=113981=edit
Xorg.0.log after crash, linux 4.0.0-rc2 with patches

Here is Xorg.0.log, backtrace at the end.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150304/3e106798/attachment.html>

[Bug 85647] Random radeonsi crashes with mesa 10.3.x

[bugzilla-dae...@freedesktop.org]

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

--- Comment #43 from Hannu  ---
Created attachment 113979
  --> https://bugs.freedesktop.org/attachment.cgi?id=113979=edit
journalctl -b after crash, linux 4.0.0-rc2 with patches

Tested mesa 10.3.2-1 with the dma problem again with linux kernel 4.0.0-rc2
with attachment 166571 from bug 90741 and "drm/radeon: do a posting read in
si_set_irq" from posting-read branch applied (I'm testing just for fun, 10.4.5
works fine).

This time X restarted after the lockup (asks username and password). Journalctl
-b attached, there is something in Xorg.0.log this time, I'll attach it next.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150304/a70ecf1e/attachment.html>

[PATCH] drm/ttm: device address space != CPU address space

[Zhou, Jammy]

Patch is Reviewed-by: Jammy Zhou 

Regards,
Jammy

-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of 
Alex Deucher
Sent: Wednesday, March 04, 2015 1:19 PM
To: dri-devel at lists.freedesktop.org
Cc: Deucher, Alexander; thellstrom at vmware.com
Subject: [PATCH] drm/ttm: device address space != CPU address space

We need to store device offsets in 64 bit as the device address space may be 
larger than the CPU's.

Fixes GPU init failures on radeons with 4GB or more of vram on 32 bit kernels.  
We put vram at the start of the GPU's address space so the gart aperture starts 
at 4 GB causing all GPU addresses in the gart aperture to get truncated.

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

Signed-off-by: Alex Deucher 
Cc: thellstrom at vmware.com
---
Untested.  Someone more familiar with the ttm internals can probably point out 
any additional bits I missed.  Heading to bed now.

 drivers/gpu/drm/ttm/ttm_bo.c| 2 +-
 include/drm/ttm/ttm_bo_api.h| 2 +-
 include/drm/ttm/ttm_bo_driver.h | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c index 
d395b0b..8d9b7de 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -74,7 +74,7 @@ static void ttm_mem_type_debug(struct ttm_bo_device *bdev, 
int mem_type)
pr_err("has_type: %d\n", man->has_type);
pr_err("use_type: %d\n", man->use_type);
pr_err("flags: 0x%08X\n", man->flags);
-   pr_err("gpu_offset: 0x%08lX\n", man->gpu_offset);
+   pr_err("gpu_offset: 0x%08llX\n", man->gpu_offset);
pr_err("size: %llu\n", man->size);
pr_err("available_caching: 0x%08X\n", man->available_caching);
pr_err("default_caching: 0x%08X\n", man->default_caching);
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h index 
0ccf7f2..c768ddf 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -249,7 +249,7 @@ struct ttm_buffer_object {
 * either of these locks held.
 */

-   unsigned long offset;
+   uint64_t offset; /* GPU address space is independent of CPU word size 
+*/
uint32_t cur_placement;

struct sg_table *sg;
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h 
index 142d752..813042c 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -277,7 +277,7 @@ struct ttm_mem_type_manager {
bool has_type;
bool use_type;
uint32_t flags;
-   unsigned long gpu_offset;
+   uint64_t gpu_offset; /* GPU address space is independent of CPU word 
+size */
uint64_t size;
uint32_t available_caching;
uint32_t default_caching;
--
1.8.3.1

___
dri-devel mailing list
dri-devel at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 89072] Radeon Hawaii no acceleration on 32-bit kernel

[bugzilla-dae...@freedesktop.org]

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

--- Comment #3 from Alex Deucher  ---
Created attachment 113971
  --> https://bugs.freedesktop.org/attachment.cgi?id=113971=edit
possible fix

Does this patch help?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150304/cc3af58d/attachment-0001.html>

[Bug 89072] Radeon Hawaii no acceleration on 32-bit kernel

[bugzilla-dae...@freedesktop.org]

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

--- Comment #2 from Alex Deucher  ---
I think the problem is ttm uses an unsigned long to store the offsets which is
only 32 bits on 32 bit kernels, but the GPU's address space is 64 bit so it
gets cut off.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150304/6fa1f4ec/attachment.html>

[Bug 89374] Firefox smooth scrolling isn't smooth

[bugzilla-dae...@freedesktop.org]

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

--- Comment #5 from Michel Dänzer  ---
(In reply to sunweb from comment #4)
> No difference.

Did you verify in /var/log/Xorg.0.log that glamor was enabled?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150304/315e9135/attachment.html>

[PATCH 1/3] drm/layerscape: Add fsl dcu DRM driver

[jianwei.w...@freescale.com]

> -Original Message-
> From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Tuesday, March 03, 2015 6:54 PM
> To: Wang Jianwei-B52261
> Cc: Daniel Vetter; dri-devel at lists.freedesktop.org;
> jbarnes at virtuousgeek.org; Wood Scott-B07421; Xiubo Li; Wang Huan-B18965;
> linux-kernel at vger.kernel.org; linux-arm-kernel at lists.infradead.org
> Subject: Re: [PATCH 1/3] drm/layerscape: Add fsl dcu DRM driver
> 
> On Tue, Mar 03, 2015 at 10:06:57AM +, Jianwei.Wang at freescale.com
> wrote:
> > > -Original Message-
> > > From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of
> Daniel
> > > Vetter
> > > Sent: Sunday, February 22, 2015 7:35 PM
> > > To: Wang Jianwei-B52261
> > > Cc: dri-devel at lists.freedesktop.org; jbarnes at virtuousgeek.org; Wood
> > > Scott-B07421; Xiubo Li; Wang Huan-B18965; linux-
> kernel at vger.kernel.org;
> > > linux-arm-kernel at lists.infradead.org
> > > Subject: Re: [PATCH 1/3] drm/layerscape: Add fsl dcu DRM driver
> > >
> > > On Fri, Feb 13, 2015 at 07:03:54PM +0800, Jianwei Wang wrote:
> > > > This patch add support for Two Dimensional Animation and
> Compositing
> > > > Engine (2D-ACE) on the Freescale LS102x SoCs.
> > > >
> > > > 2D-ACE is a Freescale display controller. It supports at most four
> > > > plane and provide an hardware cursor.
> > > >
> > > > This is a simplified version, only a primary plane, a fb created
> for
> > > > fbdev, a crtc, a connector for TFT LCD panel, an encoder, and the
> > > > encoder is not in use. Now this drver support fbdev only.
> > > >
> > > > Signed-off-by: Alison Wang 
> > > > Signed-off-by: Xiubo Li 
> > > > Signed-off-by: Jianwei Wang 
> > >
> > > Imo adding a new driver without primary plane support (use
> > > drm_crtc_init_with_planes) and without atomic support doesn't make
> sense
> > > any more.
> > >
> > > Also, what do you mean with "support fbdev only"?
> > > -Daniel
> > >
> >
> > Daniel,
> >
> > This driver has supported primary plane (use drm_crtc_init_with_planes)
> > Already.
> > If atomic support is a must? 2D-ACE is a simple display Controller and
> > this is a simplified version. If atomic support is not a must, I want
> to add
> > it with patches, is it ok?
> 
> atomic is the new way the drm display subsystem works, not supporting it
> in new drivers makes this transition even longer. Since I guess if you
> don't want to do the conversion now no one else will do it anytime later,
> and then we're stuck with this driver as-is. On top of that atomic should
> simplify testing for your driver a lot (since a few things are take care
> of for you in the generic atomic code).
> -Daniel
> 

Okey! I'll add atomic support in this driver.

Regards,
Wang Jianwei

> >
> > " Now this drver support fbdev only." if this sentence confuses you,
> > I'd like remove it. In fact I mean that this driver only create a
> framebuffer
> > dev (use drm_fbdev_cma_init).
> >
> > Thanks
> > Regards,
> > Wang Jianwei
> >
> > > > ---
> > > >  .../devicetree/bindings/video/fsl,dcfb.txt |  50 +++
> > > >  drivers/gpu/drm/Kconfig|   2 +
> > > >  drivers/gpu/drm/Makefile   |   1 +
> > > >  drivers/gpu/drm/fsl/Kconfig|  17 +
> > > >  drivers/gpu/drm/fsl/Makefile   |   7 +
> > > >  drivers/gpu/drm/fsl/fsl_dcu_drm_crtc.c | 412
> > > +
> > > >  drivers/gpu/drm/fsl/fsl_dcu_drm_crtc.h |  40 ++
> > > >  drivers/gpu/drm/fsl/fsl_dcu_drm_drv.c  | 323
> > > 
> > > >  drivers/gpu/drm/fsl/fsl_dcu_drm_drv.h  | 167 +
> > > >  drivers/gpu/drm/fsl/fsl_dcu_drm_fbdev.c|  43 +++
> > > >  drivers/gpu/drm/fsl/fsl_dcu_drm_kms.c  |  45 +++
> > > >  drivers/gpu/drm/fsl/fsl_dcu_drm_kms.h  |  22 ++
> > > >  drivers/gpu/drm/fsl/fsl_dcu_drm_plane.c| 124 +++
> > > >  drivers/gpu/drm/fsl/fsl_dcu_drm_plane.h|  28 ++
> > > >  14 files changed, 1281 insertions(+)
> > > >  create mode 100644
> > > > Documentation/devicetree/bindings/video/fsl,dcfb.txt
> > > >  create mode 100644 drivers/gpu/drm/fsl/Kconfig  create mode 100644
> > > > drivers/gpu/drm/fsl/Makefile  create mode 100644
> > > > drivers/gpu/drm/fsl/fsl_dcu_drm_crtc.c
> > > >  create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_crtc.h
> > > >  create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_drv.c
> > > >  create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_drv.h
> > > >  create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_fbdev.c
> > > >  create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_kms.c
> > > >  create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_kms.h
> > > >  create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_plane.c
> > > >  create mode 100644 drivers/gpu/drm/fsl/fsl_dcu_drm_plane.h
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/video/fsl,dcfb.txt
> > > > 

[PATCH 2/2] drm/exynos: decon: Add support for DECON-EXT

[Inki Dae]

Hi,

2015-03-02 19:57 GMT+09:00 Ajay kumar :
> On Mon, Mar 2, 2015 at 1:38 PM, Andrzej Hajda  wrote:
>> On 02/26/2015 04:24 PM, Ajay Kumar wrote:
>>> * Modify DECON-INT driver to support DECON-EXT.
>>> * Add a table of porch values needed to set timing registers of DECON-EXT.
>>> * DECON-EXT supports only H/w Triggered COMMAND mode.
>>> * DECON-EXT supports only one DMA window(window 1), so modify
>>>   all window management routines to support 2 windows of DECON-INT
>>>   and 1 window of DECON-EXT.
>>>
>>> Signed-off-by: Ajay Kumar 
>>> ---
>>>  .../devicetree/bindings/video/exynos7-decon.txt|8 +-
>>>  drivers/gpu/drm/exynos/exynos7_drm_decon.c |  229 
>>> ++--
>>>  include/video/exynos7_decon.h  |   13 ++
>>>  3 files changed, 230 insertions(+), 20 deletions(-)
>>>

-- snip --

>>>  static void decon_commit(struct exynos_drm_crtc *crtc)
>>>  {
>>>   struct decon_context *ctx = crtc->ctx;
>>> + struct decon_driver_data *drv_data = ctx->driver_data;
>>>   struct drm_display_mode *mode = >base.mode;
>>> + struct decon_ext_videomode *my_mode;
>>>   u32 val, clkdiv;
>>>
>>>   if (ctx->suspended)
>>> @@ -200,6 +306,38 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
>>>   if (mode->htotal == 0 || mode->vtotal == 0)
>>>   return;
>>>
>>> + if (drv_data->decon_type == DECON_EXT) {
>>> + if ((mode->hdisplay == 720) && (mode->vdisplay == 480) &&
>>> + (mode->vrefresh == 60))
>>> + my_mode = _ext_porchs[MODE_720_480_60];
>>> + if ((mode->hdisplay == 720) && (mode->vdisplay == 576) &&
>>> + (mode->vrefresh == 50))
>>> + my_mode = _ext_porchs[MODE_720_576_50];
>>> + if ((mode->hdisplay == 1280) && (mode->vdisplay == 720) &&
>>> + (mode->vrefresh == 60))
>>> + my_mode = _ext_porchs[MODE_1280_720_60];
>>> + if ((mode->hdisplay == 1280) && (mode->vdisplay == 720) &&
>>> + (mode->vrefresh == 50))
>>> + my_mode = _ext_porchs[MODE_1280_720_50];
>>> + if ((mode->hdisplay == 1920) && (mode->vdisplay == 1080) &&
>>> + (mode->vrefresh == 60))
>>> + my_mode = _ext_porchs[MODE_1920_1080_60];
>>> + if ((mode->hdisplay == 1920) && (mode->vdisplay == 1080) &&
>>> + (mode->vrefresh == 50))
>>> + my_mode = _ext_porchs[MODE_1920_1080_50];
>>> + if ((mode->hdisplay == 1920) && (mode->vdisplay == 1080) &&
>>> + (mode->vrefresh == 30))
>>> + my_mode = _ext_porchs[MODE_1920_1080_30];
>>> + if ((mode->hdisplay == 1920) && (mode->vdisplay == 1080) &&
>>> + (mode->vrefresh == 25))
>>> + my_mode = _ext_porchs[MODE_1920_1080_25];
>>> + if ((mode->hdisplay == 1920) && (mode->vdisplay == 1080) &&
>>> + (mode->vrefresh == 24))
>>> + my_mode = _ext_porchs[MODE_1920_1080_24];
>>> +
>>> + decon_ext_set_timing(mode, my_mode);
>>> + }
>>> +
>>
>> I guess these ugly ifs could be replaced by simple loop:
>> for (i = 0; i < ARRAY_SIZE(decon_ext_porchs); ++i) {
>> if (mode->hdisplay != decon_ext_porchs[i].hdisplay || ...)
>> continue;
>> decon_ext_set_timing(mode, _ext_porchs[i]);
>> break;
>> }
> Ok, Though the number of checks is the same, your code at least looks better. 
> :)
>
>> Anyway I have doubts if commit should modify crtc.base.mode I guess
>> better place for it can be in *_fixup callback.
> Inki? What is your suggestion?

Agree with Andrzej. The fixup callback would be a right place to find
a valid mode. By the way, what if mode->hdisplay/vdisplay/vrefresh are
not supported for all DECON_EXT modes?

Thanks,
Inki Dae

[PATCH] drm/ttm: device address space != CPU address space

[Alex Deucher]

We need to store device offsets in 64 bit as the device
address space may be larger than the CPU's.

Fixes GPU init failures on radeons with 4GB or more of
vram on 32 bit kernels.  We put vram at the start of the
GPU's address space so the gart aperture starts at 4 GB
causing all GPU addresses in the gart aperture to get
truncated.

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

Signed-off-by: Alex Deucher 
Cc: thellstrom at vmware.com
---
Untested.  Someone more familiar with the ttm internals can
probably point out any additional bits I missed.  Heading to
bed now.

 drivers/gpu/drm/ttm/ttm_bo.c| 2 +-
 include/drm/ttm/ttm_bo_api.h| 2 +-
 include/drm/ttm/ttm_bo_driver.h | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index d395b0b..8d9b7de 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -74,7 +74,7 @@ static void ttm_mem_type_debug(struct ttm_bo_device *bdev, 
int mem_type)
pr_err("has_type: %d\n", man->has_type);
pr_err("use_type: %d\n", man->use_type);
pr_err("flags: 0x%08X\n", man->flags);
-   pr_err("gpu_offset: 0x%08lX\n", man->gpu_offset);
+   pr_err("gpu_offset: 0x%08llX\n", man->gpu_offset);
pr_err("size: %llu\n", man->size);
pr_err("available_caching: 0x%08X\n", man->available_caching);
pr_err("default_caching: 0x%08X\n", man->default_caching);
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index 0ccf7f2..c768ddf 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -249,7 +249,7 @@ struct ttm_buffer_object {
 * either of these locks held.
 */

-   unsigned long offset;
+   uint64_t offset; /* GPU address space is independent of CPU word size */
uint32_t cur_placement;

struct sg_table *sg;
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index 142d752..813042c 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -277,7 +277,7 @@ struct ttm_mem_type_manager {
bool has_type;
bool use_type;
uint32_t flags;
-   unsigned long gpu_offset;
+   uint64_t gpu_offset; /* GPU address space is independent of CPU word 
size */
uint64_t size;
uint32_t available_caching;
uint32_t default_caching;
-- 
1.8.3.1