[Bug 102796] steam not rendering correctly on VEGA 56

2017-09-16 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=102796

--- Comment #2 from Tom Englund  ---
using LIBGL_ALWAYS_SOFTWARE=true steam , makes it render just like it should,
so i would assume the issue is somewhere in mesa with vega.

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

[Bug 93826] 2560x1440 @144Hz graphic glitches and bad refresh rate

2017-09-16 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=93826

Emma Stott  changed:

   What|Removed |Added

 Resolution|FIXED   |---
 Status|RESOLVED|REOPENED

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

[Bug 93826] 2560x1440 @144Hz graphic glitches and bad refresh rate

2017-09-16 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=93826

--- Comment #77 from Emma Stott  ---
I've just given this another try and unfortunately it's still happening for me,
even with the latest kernel:

uname -a: Linux winters-pc 4.12.13-1-ARCH #1 SMP PREEMPT Fri Sep 15 06:36:43
UTC 2017 x86_64 GNU/Linux

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

Re: [PATCH v3 10/22] drm/imx: Use drm_gem_fb_create() and drm_gem_fb_prepare_fb()

2017-09-16 Thread Noralf Trønnes 


Den 11.09.2017 09.57, skrev Philipp Zabel:

Hi Noralf,

On Sun, 2017-08-13 at 15:31 +0200, Noralf Trønnes wrote:

drm_fb_cma_create() and drm_fb_cma_prepare_fb() are just wrappers now,
use drm_gem_fb_create() and drm_gem_fb_prepare_fb() directly.


Cc: Philipp Zabel 
Signed-off-by: Noralf Trønnes 

---
  drivers/gpu/drm/imx/imx-drm-core.c | 3 ++-
  drivers/gpu/drm/imx/ipuv3-plane.c  | 3 ++-
  2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
b/drivers/gpu/drm/imx/imx-drm-core.c
index f91cb72..93c7e3f 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -24,6 +24,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -105,7 +106,7 @@ static int imx_drm_atomic_check(struct drm_device *dev,
  }
  
  static const struct drm_mode_config_funcs imx_drm_mode_config_funcs = {

-   .fb_create = drm_fb_cma_create,
+   .fb_create = drm_gem_fb_create,
    .output_poll_changed = imx_drm_output_poll_changed,
    .atomic_check = imx_drm_atomic_check,
    .atomic_commit = drm_atomic_helper_commit,

diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
b/drivers/gpu/drm/imx/ipuv3-plane.c
index debde2d..82e1c50 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -18,6 +18,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  
  #include "video/imx-ipu-v3.h"

@@ -661,7 +662,7 @@ static void ipu_plane_atomic_update(struct drm_plane *plane,
  }
  
  static const struct drm_plane_helper_funcs ipu_plane_helper_funcs = {

-   .prepare_fb = drm_fb_cma_prepare_fb,
+   .prepare_fb = drm_gem_fb_prepare_fb,
    .atomic_check = ipu_plane_atomic_check,
    .atomic_disable = ipu_plane_atomic_disable,
    .atomic_update = ipu_plane_atomic_update,

Acked-by: Philipp Zabel 


Thanks, applied to drm-misc.

Noralf.

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

Re: [PATCH v2 2/2] drm/gem-fb-helper: Use debug message on gem lookup failure

2017-09-16 Thread Noralf Trønnes 


Den 13.09.2017 04.44, skrev Laurent Pinchart:

Hi Noralf,

Thank you for the patch.

On Monday, 11 September 2017 19:37:45 EEST Noralf Trønnes wrote:

GEM lookup failure can easily be triggered by userspace so make
it a debug message, not an error message.

Also remove unnecessary inner parentheses and fix alphabetical
struct declaration order.

Cc: Laurent Pinchart 
Signed-off-by: Noralf Trønnes 
Reviewed-by: Daniel Vetter 

Reviewed-by: Laurent Pinchart 


Thanks, applied to drm-misc.

Noralf.


---
  drivers/gpu/drm/drm_gem_framebuffer_helper.c | 4 ++--
  include/drm/drm_gem_framebuffer_helper.h | 2 +-
  2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
b/drivers/gpu/drm/drm_gem_framebuffer_helper.c index e2ca002..9cf6566
100644
--- a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
+++ b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
@@ -157,7 +157,7 @@ drm_gem_fb_create_with_funcs(struct drm_device *dev,
struct drm_file *file,

objs[i] = drm_gem_object_lookup(file, mode_cmd->handles[i]);
if (!objs[i]) {
-   DRM_DEV_ERROR(dev->dev, "Failed to lookup GEM\n");
+   DRM_DEBUG_KMS("Failed to lookup GEM object\n");
ret = -ENOENT;
goto err_gem_object_put;
}
@@ -235,7 +235,7 @@ int drm_gem_fb_prepare_fb(struct drm_plane *plane,
struct dma_buf *dma_buf;
struct dma_fence *fence;

-   if ((plane->state->fb == state->fb) || !state->fb)
+   if (plane->state->fb == state->fb || !state->fb)
return 0;

dma_buf = drm_gem_fb_get_obj(state->fb, 0)->dma_buf;
diff --git a/include/drm/drm_gem_framebuffer_helper.h
b/include/drm/drm_gem_framebuffer_helper.h index db9cfa0..5ca7cdc 100644
--- a/include/drm/drm_gem_framebuffer_helper.h
+++ b/include/drm/drm_gem_framebuffer_helper.h
@@ -2,8 +2,8 @@
  #define __DRM_GEM_FB_HELPER_H__

  struct drm_device;
-struct drm_file;
  struct drm_fb_helper_surface_size;
+struct drm_file;
  struct drm_framebuffer;
  struct drm_framebuffer_funcs;
  struct drm_gem_object;




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

Re: [PATCH v2 07/11] drm/tinydrm: Drop driver registered message

2017-09-16 Thread Noralf Trønnes 


Den 09.09.2017 23.33, skrev David Lechner:

On 09/08/2017 10:07 AM, Noralf Trønnes wrote:

No need to put out a driver registered message since drm_dev_register()
does that now. SPI speed is an important metric when dealing with
display problems, so retain that info.

Cc: David Lechner 
Signed-off-by: Noralf Trønnes 
---


Acked-by: David Lechner 



Thanks David, applied to drm-misc.

Noralf.

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

Re: [PATCH] drm/radeon: properly initialize r600_audio_status() data

2017-09-16 Thread Christian König 

Am 15.09.2017 um 22:06 schrieb Arnd Bergmann:

The structure returned from r600_audio_status() is only partially
initialized, and older gcc versions (4.3 and 4.4) warn about this:

drivers/gpu/drm/radeon/r600_hdmi.c: In function 'r600_audio_status':
drivers/gpu/drm/radeon/r600_hdmi.c:108: error: 'status.id' is used 
uninitialized in this function
drivers/gpu/drm/radeon/r600_hdmi.c:108: error: 'status.connected' is used 
uninitialized in this function
drivers/gpu/drm/radeon/r600_hdmi.c:108: error: 'status.offset' is used 
uninitialized in this function

This is harmless and surprisingly correct in C99, as the caller
only accesses the fields that got initialized, so newer compilers
don't warn about it, but initializing the entire structure feels
like the right thing to do here and avoids the warning.

Signed-off-by: Arnd Bergmann 


Reviewed-by: Christian König 


---
  drivers/gpu/drm/radeon/r600_hdmi.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/r600_hdmi.c 
b/drivers/gpu/drm/radeon/r600_hdmi.c
index e82a99cb2459..ab32830c4e23 100644
--- a/drivers/gpu/drm/radeon/r600_hdmi.c
+++ b/drivers/gpu/drm/radeon/r600_hdmi.c
@@ -58,7 +58,7 @@ enum r600_hdmi_iec_status_bits {
  
  static struct r600_audio_pin r600_audio_status(struct radeon_device *rdev)

  {
-   struct r600_audio_pin status;
+   struct r600_audio_pin status = {};
uint32_t value;
  
  	value = RREG32(R600_AUDIO_RATE_BPS_CHANNEL);



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

Re: [PATCH 0/8] drm/fb-helper: Use drm_file to get a dumb framebuffer

2017-09-16 Thread Noralf Trønnes 


Den 15.09.2017 18.37, skrev Noralf Trønnes:


Den 15.09.2017 00.29, skrev Laurent Pinchart:

Hi Noralf,

On Wednesday, 13 September 2017 18:19:22 EEST Noralf Trønnes wrote:

Den 13.09.2017 07.09, skrev Laurent Pinchart:

On Monday, 11 September 2017 17:31:54 EEST Noralf Trønnes wrote:

Hi,

I want to start out by saying that this patchset is low priority 
for me
and if no one has interest or time to review this, that is just 
fine. I

was in the flow and just typed it out.

This patchset adds a way for fbdev emulation code to create a
framebuffer that is backed by a dumb buffer. drm_fb_helper gets a
drm_file to hang the objects on, drm_framebuffer_create_dumb() 
creates

the framebuffer and drm_fb_helper_fini() destroys it.
I have verified that all cma drivers supports dumb buffers, so
converting the library should be fine for all.
Stupid question, what does this give us ? The series makes the call 
stack
more complex (up to a point where I'm getting trouble just 
following it),

what's the advantage that offsets that ?

The short answer is that it avoids the need for special fbdev
_with_funcs() functions in libraries like cma for framebuffers with the
dirty callback set.

I'm suprised that you think this more complex, I find it more coherent
when fbdev userspace is doing things more like DRM userspace, like
hanging the objects on a drm_file and cleaning up the objects when 
done.
Maybe moving to a new code base gave me the wrong feeling that the 
result is

more complex. The current implementation is certainly not simple.


The longer and more diffuse answer is that it's annoying me that many
drivers carry the burden of fbdev emulation just to get a console!
I totally agree with that. Ideally I'd like to remove 100% of 
fbdev-related

code from drivers. This includes

- initialization and cleanup of fbdev helpers
- fbdev restore in last_close()
- forwarding of hotplug events to fbdev compatibility layer

In practice we'll likely need to keep one initialization function (or a
drm_driver flag) to let drivers opt-in to fbdev compatibility, but 
the rest

should go away. Or maybe we could even enable fbdev compatibility in all
drivers unconditionally.


Interesting idea, maybe something like this:



I just remembered that Daniel said something about the helpers shouldn't
bleed into the core, which my suggestion does :-/



 struct drm_device {
+     struct drm_fb_helper *fbdev;
 };

 void drm_lastclose(struct drm_device * dev)
 {
 DRM_DEBUG("\n");

 if (dev->driver->lastclose)
     dev->driver->lastclose(dev);
+    else if (dev->fbdev)
+        drm_fb_helper_restore_fbdev_mode_unlocked(dev->fbdev);
 DRM_DEBUG("driver lastclose completed\n");

 if (drm_core_check_feature(dev, DRIVER_LEGACY))
     drm_legacy_dev_reinit(dev);
 }

 void drm_kms_helper_hotplug_event(struct drm_device *dev)
 {
 /* send a uevent + call fbdev */
 drm_sysfs_hotplug_event(dev);
 if (dev->mode_config.funcs->output_poll_changed)
     dev->mode_config.funcs->output_poll_changed(dev);
+    else if (dev->fbdev)
+        drm_fb_helper_hotplug_event(dev->fbdev);
 }

 void drm_dev_unregister(struct drm_device *dev)
 {
    struct drm_map_list *r_list, *list_temp;

+    if (dev->fbdev)
+        drm_fb_helper_unregister_fbi(dev->fbdev);
+
 drm_lastclose(dev);
 ...
 }

 static void drm_dev_release(struct kref *ref)
 {
 struct drm_device *dev = container_of(ref, struct drm_device, ref);

+    drm_fb_helper_simple_fini(dev);
+
 if (dev->driver->release) {
     dev->driver->release(dev);
 } else {
     drm_dev_fini(dev);
     kfree(dev);
 }
 }

int driver_probe()
{
    ret = drm_fb_helper_simple_init(dev, ...);
    if (ret)
        DRM_WARN("Oh well fbdev init failed, but don't let that stop 
us\n");

}

I've slightly adjusted some code I have in the pipeline:

/**
 * drm_fb_helper_simple_init - Simple fbdev emulation init
 * @dev: DRM device
 * @bpp_sel: bpp value to use for the framebuffer configuration
 * @max_conn: max connector count
 * @funcs: pointer to structure of functions associated with this helper
 *
 * Simple fbdev emulation initialization. This function allocates a
 * &drm_fb_helper structure and calls:
 * drm_fb_helper_prepare(), drm_fb_helper_init(),
 * drm_fb_helper_single_add_all_connectors() and
 * drm_fb_helper_initial_config().
 *
 * fbdev deferred I/O users should use drm_fb_helper_defio_init().
 *
 * Returns:
 * Zero on success, negative error code on failure.
 */
int drm_fb_helper_simple_init(struct drm_device *dev, int bpp_sel, int 
max_conn,

              const struct drm_fb_helper_funcs *funcs)
{
    struct drm_fb_helper *fb_helper;
    int ret;

    fb_helper = kzalloc(sizeof(*fb_helper), GFP_KERNEL);
    if (!fb_helper)
        return -ENOMEM;

    drm_fb_helper_prepare(dev, fb_helper, funcs);

    ret = drm_fb_helper_init(dev, fb_helper, max_conn);
    if (ret < 0) {
        DRM_DEV_ERROR(dev->dev, "Failed to initialize fb helper.\n");
     

[PATCHv4 2/3] drm-kms-helpers.rst: document the DP CEC helpers

2017-09-16 Thread Hans Verkuil 
From: Hans Verkuil 

Document the Display Port CEC helper functions.

Signed-off-by: Hans Verkuil 
---
 Documentation/gpu/drm-kms-helpers.rst | 9 +
 1 file changed, 9 insertions(+)

diff --git a/Documentation/gpu/drm-kms-helpers.rst 
b/Documentation/gpu/drm-kms-helpers.rst
index 7c5e2549a58a..0d2fa879edd1 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -175,6 +175,15 @@ Display Port Helper Functions Reference
 .. kernel-doc:: drivers/gpu/drm/drm_dp_helper.c
:export:
 
+Display Port CEC Helper Functions Reference
+===
+
+.. kernel-doc:: drivers/gpu/drm/drm_dp_cec.c
+   :doc: dp cec helpers
+
+.. kernel-doc:: drivers/gpu/drm/drm_dp_cec.c
+   :export:
+
 Display Port Dual Mode Adaptor Helper Functions Reference
 =
 
-- 
2.14.1

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

[PATCHv4 0/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support

2017-09-16 Thread Hans Verkuil 
From: Hans Verkuil 

This patch series adds support for the DisplayPort CEC-Tunneling-over-AUX
feature. This patch series is based on the current pre-4.14-rc1 mainline
which has all the needed cec 4.14 patches merged.

This patch series has been tested with my NUC7i5BNK and a Samsung USB-C to 
HDMI adapter.

Please note this comment at the start of drm_dp_cec.c:

--
Unfortunately it turns out that we have a chicken-and-egg situation
here. Quite a few active (mini-)DP-to-HDMI or USB-C-to-HDMI adapters
have a converter chip that supports CEC-Tunneling-over-AUX (usually the
Parade PS176), but they do not wire up the CEC pin, thus making CEC
useless.

Sadly there is no way for this driver to know this. What happens is 
that a /dev/cecX device is created that is isolated and unable to see
any of the other CEC devices. Quite literally the CEC wire is cut
(or in this case, never connected in the first place).

I suspect that the reason so few adapters support this is that this
tunneling protocol was never supported by any OS. So there was no 
easy way of testing it, and no incentive to correctly wire up the
CEC pin.

Hopefully by creating this driver it will be easier for vendors to 
finally fix their adapters and test the CEC functionality.

I keep a list of known working adapters here:

https://hverkuil.home.xs4all.nl/cec-status.txt

Please mail me (hverk...@xs4all.nl) if you find an adapter that works
and is not yet listed there.
--

I really hope that this work will provide an incentive for vendors to
finally connect the CEC pin. It's a shame that there are so few adapters
that work (I found only two USB-C to HDMI adapters that work, and no
(mini-)DP to HDMI adapters at all).

Note that a colleague who actually knows his way around a soldering iron
modified an UpTab DisplayPort-to-HDMI adapter for me, hooking up the CEC
pin. And after that change it worked. I also received confirmation that
this really is a chicken-and-egg situation: it is because there is no CEC
support for this feature in any OS that they do not hook up the CEC pin.

So hopefully if this gets merged there will be an incentive for vendors
to make adapters where this actually works. It is a very nice feature
for HTPC boxes.

Changes since v3:

Incorporated Ville's comments. The two main changes (besides some small
readability changes) are:

- use drm_dp_read_desc() in drm_dp_cec_adap_status().
- drop the 'for (attempts = 0...)' loop in drm_dp_cec_irq().

Changes since v2:

- Use the new CEC_CAP_DEFAULTS define
- Replace 'if (!IS_ERR_OR_NULL(aux->cec_adap)) {' in 
drm_dp_cec_configure_adapter()
  by just 'if (aux->cec_adap) {'.

Changes since v1:

- Incorporated Sean's review comments in patch 1/3.

Regards,

Hans



Hans Verkuil (3):
  drm: add support for DisplayPort CEC-Tunneling-over-AUX
  drm-kms-helpers.rst: document the DP CEC helpers
  drm/i915: add DisplayPort CEC-Tunneling-over-AUX support

 Documentation/gpu/drm-kms-helpers.rst |   9 ++
 drivers/gpu/drm/Kconfig   |  10 ++
 drivers/gpu/drm/Makefile  |   1 +
 drivers/gpu/drm/drm_dp_cec.c  | 292 ++
 drivers/gpu/drm/i915/intel_dp.c   |  18 ++-
 include/drm/drm_dp_helper.h   |  24 +++
 6 files changed, 350 insertions(+), 4 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_dp_cec.c

-- 
2.14.1

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

[PATCHv4 1/3] drm: add support for DisplayPort CEC-Tunneling-over-AUX

2017-09-16 Thread Hans Verkuil 
From: Hans Verkuil 

This adds support for the DisplayPort CEC-Tunneling-over-AUX
feature that is part of the DisplayPort 1.3 standard.

Unfortunately, not all DisplayPort/USB-C to HDMI adapters with a
chip that has this capability actually hook up the CEC pin, so
even though a CEC device is created, it may not actually work.

Signed-off-by: Hans Verkuil 
Tested-by: Carlos Santa 
---
 drivers/gpu/drm/Kconfig  |  10 ++
 drivers/gpu/drm/Makefile |   1 +
 drivers/gpu/drm/drm_dp_cec.c | 292 +++
 include/drm/drm_dp_helper.h  |  24 
 4 files changed, 327 insertions(+)
 create mode 100644 drivers/gpu/drm/drm_dp_cec.c

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 83cb2a88c204..1f2708df5c4e 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -120,6 +120,16 @@ config DRM_LOAD_EDID_FIRMWARE
  default case is N. Details and instructions how to build your own
  EDID data are given in Documentation/EDID/HOWTO.txt.
 
+config DRM_DP_CEC
+   bool "Enable DisplayPort CEC-Tunneling-over-AUX HDMI support"
+   select CEC_CORE
+   help
+ Choose this option if you want to enable HDMI CEC support for
+ DisplayPort/USB-C to HDMI adapters.
+
+ Note: not all adapters support this feature, and even for those
+ that do support this they often do not hook up the CEC pin.
+
 config DRM_TTM
tristate
depends on DRM && MMU
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 24a066e1841c..c6552c62049e 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -40,6 +40,7 @@ drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += 
drm_edid_load.o
 drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
 drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o
 drm_kms_helper-$(CONFIG_DRM_DP_AUX_CHARDEV) += drm_dp_aux_dev.o
+drm_kms_helper-$(CONFIG_DRM_DP_CEC) += drm_dp_cec.o
 
 obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o
 obj-$(CONFIG_DRM_DEBUG_MM_SELFTEST) += selftests/
diff --git a/drivers/gpu/drm/drm_dp_cec.c b/drivers/gpu/drm/drm_dp_cec.c
new file mode 100644
index ..d110cac007de
--- /dev/null
+++ b/drivers/gpu/drm/drm_dp_cec.c
@@ -0,0 +1,292 @@
+/*
+ * DisplayPort CEC-Tunneling-over-AUX support
+ *
+ * Copyright 2017 Cisco Systems, Inc. and/or its affiliates. All rights 
reserved.
+ *
+ * This program is free software; you may redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * Unfortunately it turns out that we have a chicken-and-egg situation
+ * here. Quite a few active (mini-)DP-to-HDMI or USB-C-to-HDMI adapters
+ * have a converter chip that supports CEC-Tunneling-over-AUX (usually the
+ * Parade PS176), but they do not wire up the CEC pin, thus making CEC
+ * useless.
+ *
+ * Sadly there is no way for this driver to know this. What happens is
+ * that a /dev/cecX device is created that is isolated and unable to see
+ * any of the other CEC devices. Quite literally the CEC wire is cut
+ * (or in this case, never connected in the first place).
+ *
+ * I suspect that the reason so few adapters support this is that this
+ * tunneling protocol was never supported by any OS. So there was no
+ * easy way of testing it, and no incentive to correctly wire up the
+ * CEC pin.
+ *
+ * Hopefully by creating this driver it will be easier for vendors to
+ * finally fix their adapters and test the CEC functionality.
+ *
+ * I keep a list of known working adapters here:
+ *
+ * https://hverkuil.home.xs4all.nl/cec-status.txt
+ *
+ * Please mail me (hverk...@xs4all.nl) if you find an adapter that works
+ * and is not yet listed there.
+ */
+
+/**
+ * DOC: dp cec helpers
+ *
+ * These functions take care of supporting the CEC-Tunneling-over-AUX
+ * feature of DisplayPort-to-HDMI adapters.
+ */
+
+static int drm_dp_cec_adap_enable(struct cec_adapter *adap, bool enable)
+{
+   struct drm_dp_aux *aux = cec_get_drvdata(adap);
+   u32 val = enable ? DP_CEC_TUNNELING_ENABLE : 0;
+   ssize_t err = 0;
+
+   err = drm_dp_dpcd_writeb(aux, DP_CEC_TUNNELING_CONTROL, val);
+   return (enable && err < 0) ? err : 0;
+}
+
+static int drm_dp_cec_adap_log_addr(struct cec_adapter *adap, u8 addr)
+{
+   struct drm_dp_aux *aux = cec_get_drvdata(adap);

[PATCHv4 3/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support

2017-09-16 Thread Hans Verkuil 
From: Hans Verkuil 

Implement support for this DisplayPort feature.

The cec device is created whenever it detects an adapter that
has this feature. It is only removed when a new adapter is connected
that does not support this. If a new adapter is connected that has
different properties than the previous one, then the old cec device is
unregistered and a new one is registered to replace the old one.

Signed-off-by: Hans Verkuil 
Tested-by: Carlos Santa 
---
 drivers/gpu/drm/i915/intel_dp.c | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 64fa774c855b..fdb853d2c458 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1449,6 +1450,7 @@ static void intel_aux_reg_init(struct intel_dp *intel_dp)
 static void
 intel_dp_aux_fini(struct intel_dp *intel_dp)
 {
+   cec_unregister_adapter(intel_dp->aux.cec_adap);
kfree(intel_dp->aux.name);
 }
 
@@ -4587,6 +4589,7 @@ intel_dp_set_edid(struct intel_dp *intel_dp)
intel_connector->detect_edid = edid;
 
intel_dp->has_audio = drm_detect_monitor_audio(edid);
+   cec_s_phys_addr_from_edid(intel_dp->aux.cec_adap, edid);
 }
 
 static void
@@ -4596,6 +4599,7 @@ intel_dp_unset_edid(struct intel_dp *intel_dp)
 
kfree(intel_connector->detect_edid);
intel_connector->detect_edid = NULL;
+   cec_phys_addr_invalidate(intel_dp->aux.cec_adap);
 
intel_dp->has_audio = false;
 }
@@ -4616,13 +4620,17 @@ intel_dp_long_pulse(struct intel_connector 
*intel_connector)
intel_display_power_get(to_i915(dev), intel_dp->aux_power_domain);
 
/* Can't disconnect eDP, but you can close the lid... */
-   if (is_edp(intel_dp))
+   if (is_edp(intel_dp)) {
status = edp_detect(intel_dp);
-   else if (intel_digital_port_connected(to_i915(dev),
- dp_to_dig_port(intel_dp)))
+   } else if (intel_digital_port_connected(to_i915(dev),
+   dp_to_dig_port(intel_dp))) {
status = intel_dp_detect_dpcd(intel_dp);
-   else
+   if (status == connector_status_connected)
+   drm_dp_cec_configure_adapter(&intel_dp->aux,
+intel_dp->aux.name, dev->dev);
+   } else {
status = connector_status_disconnected;
+   }
 
if (status == connector_status_disconnected) {
memset(&intel_dp->compliance, 0, sizeof(intel_dp->compliance));
@@ -5011,6 +5019,8 @@ intel_dp_hpd_pulse(struct intel_digital_port 
*intel_dig_port, bool long_hpd)
 
intel_display_power_get(dev_priv, intel_dp->aux_power_domain);
 
+   drm_dp_cec_irq(&intel_dp->aux);
+
if (intel_dp->is_mst) {
if (intel_dp_check_mst_status(intel_dp) == -EINVAL) {
/*
-- 
2.14.1

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

[PATCHv5 1/5] cec: add CEC_EVENT_PIN_HPD_LOW/HIGH events

2017-09-16 Thread Hans Verkuil 
From: Hans Verkuil 

Add support for two new low-level events: PIN_HPD_LOW and PIN_HPD_HIGH.

This is specifically meant for use with the upcoming cec-gpio driver
and makes it possible to trace when the HPD pin changes. Some HDMI
sinks do strange things with the HPD and this makes it easy to debug
this.

Note that this also moves the initialization of a devnode mutex and
list to the allocate_adapter function: if the HPD is high, then as
soon as the HPD interrupt is created an interrupt occurs and
cec_queue_pin_hpd_event() is called which requires that the devnode
mutex and list are initialized.

Signed-off-by: Hans Verkuil 
---
 drivers/media/cec/cec-adap.c | 18 +-
 drivers/media/cec/cec-api.c  | 18 ++
 drivers/media/cec/cec-core.c |  8 
 include/media/cec-pin.h  |  4 
 include/media/cec.h  | 12 +++-
 include/uapi/linux/cec.h |  2 ++
 6 files changed, 52 insertions(+), 10 deletions(-)

diff --git a/drivers/media/cec/cec-adap.c b/drivers/media/cec/cec-adap.c
index dd769e40416f..eb904a71609a 100644
--- a/drivers/media/cec/cec-adap.c
+++ b/drivers/media/cec/cec-adap.c
@@ -86,7 +86,7 @@ void cec_queue_event_fh(struct cec_fh *fh,
const struct cec_event *new_ev, u64 ts)
 {
static const u8 max_events[CEC_NUM_EVENTS] = {
-   1, 1, 64, 64,
+   1, 1, 64, 64, 8, 8,
};
struct cec_event_entry *entry;
unsigned int ev_idx = new_ev->event - 1;
@@ -170,6 +170,22 @@ void cec_queue_pin_cec_event(struct cec_adapter *adap, 
bool is_high, ktime_t ts)
 }
 EXPORT_SYMBOL_GPL(cec_queue_pin_cec_event);
 
+/* Notify userspace that the HPD pin changed state at the given time. */
+void cec_queue_pin_hpd_event(struct cec_adapter *adap, bool is_high, ktime_t 
ts)
+{
+   struct cec_event ev = {
+   .event = is_high ? CEC_EVENT_PIN_HPD_HIGH :
+  CEC_EVENT_PIN_HPD_LOW,
+   };
+   struct cec_fh *fh;
+
+   mutex_lock(&adap->devnode.lock);
+   list_for_each_entry(fh, &adap->devnode.fhs, list)
+   cec_queue_event_fh(fh, &ev, ktime_to_ns(ts));
+   mutex_unlock(&adap->devnode.lock);
+}
+EXPORT_SYMBOL_GPL(cec_queue_pin_hpd_event);
+
 /*
  * Queue a new message for this filehandle.
  *
diff --git a/drivers/media/cec/cec-api.c b/drivers/media/cec/cec-api.c
index a079f7fe018c..465bb3ec21f6 100644
--- a/drivers/media/cec/cec-api.c
+++ b/drivers/media/cec/cec-api.c
@@ -529,7 +529,7 @@ static int cec_open(struct inode *inode, struct file *filp)
 * Initial events that are automatically sent when the cec device is
 * opened.
 */
-   struct cec_event ev_state = {
+   struct cec_event ev = {
.event = CEC_EVENT_STATE_CHANGE,
.flags = CEC_EVENT_FL_INITIAL_STATE,
};
@@ -569,9 +569,19 @@ static int cec_open(struct inode *inode, struct file *filp)
filp->private_data = fh;
 
/* Queue up initial state events */
-   ev_state.state_change.phys_addr = adap->phys_addr;
-   ev_state.state_change.log_addr_mask = adap->log_addrs.log_addr_mask;
-   cec_queue_event_fh(fh, &ev_state, 0);
+   ev.state_change.phys_addr = adap->phys_addr;
+   ev.state_change.log_addr_mask = adap->log_addrs.log_addr_mask;
+   cec_queue_event_fh(fh, &ev, 0);
+#ifdef CONFIG_CEC_PIN
+   if (adap->pin && adap->pin->ops->read_hpd) {
+   err = adap->pin->ops->read_hpd(adap);
+   if (err >= 0) {
+   ev.event = err ? CEC_EVENT_PIN_HPD_HIGH :
+CEC_EVENT_PIN_HPD_LOW;
+   cec_queue_event_fh(fh, &ev, 0);
+   }
+   }
+#endif
 
list_add(&fh->list, &devnode->fhs);
mutex_unlock(&devnode->lock);
diff --git a/drivers/media/cec/cec-core.c b/drivers/media/cec/cec-core.c
index 648136e552d5..e3a1fb6d6690 100644
--- a/drivers/media/cec/cec-core.c
+++ b/drivers/media/cec/cec-core.c
@@ -112,10 +112,6 @@ static int __must_check cec_devnode_register(struct 
cec_devnode *devnode,
int minor;
int ret;
 
-   /* Initialization */
-   INIT_LIST_HEAD(&devnode->fhs);
-   mutex_init(&devnode->lock);
-
/* Part 1: Find a free minor number */
mutex_lock(&cec_devnode_lock);
minor = find_next_zero_bit(cec_devnode_nums, CEC_NUM_DEVICES, 0);
@@ -242,6 +238,10 @@ struct cec_adapter *cec_allocate_adapter(const struct 
cec_adap_ops *ops,
INIT_LIST_HEAD(&adap->wait_queue);
init_waitqueue_head(&adap->kthread_waitq);
 
+   /* adap->devnode initialization */
+   INIT_LIST_HEAD(&adap->devnode.fhs);
+   mutex_init(&adap->devnode.lock);
+
adap->kthread = kthread_run(cec_thread_func, adap, "cec-%s", name);
if (IS_ERR(adap->kthread)) {
pr_err("cec-%s: kernel_thread() failed\n", name);
diff --git a/include/media/cec-pin.h b/include/media/cec-pin.h
index f09cc9579d53..e

[PATCHv5 4/5] cec-gpio: add HDMI CEC GPIO driver

2017-09-16 Thread Hans Verkuil 
From: Hans Verkuil 

Add a simple HDMI CEC GPIO driver that sits on top of the cec-pin framework.

While I have heard of SoCs that use the GPIO pin for CEC (apparently an
early RockChip SoC used that), the main use-case of this driver is to
function as a debugging tool.

By connecting the CEC line to a GPIO pin on a Raspberry Pi 3 for example
it turns it into a CEC debugger and protocol analyzer.

With 'cec-ctl --monitor-pin' the CEC traffic can be analyzed.

But of course it can also be used with any hardware project where the
HDMI CEC line is hooked up to a pull-up gpio line.

In addition this has (optional) support for tracing HPD changes if the
HPD is connected to a GPIO.

Signed-off-by: Hans Verkuil 
---
 drivers/media/platform/Kconfig |  10 ++
 drivers/media/platform/Makefile|   2 +
 drivers/media/platform/cec-gpio/Makefile   |   1 +
 drivers/media/platform/cec-gpio/cec-gpio.c | 236 +
 4 files changed, 249 insertions(+)
 create mode 100644 drivers/media/platform/cec-gpio/Makefile
 create mode 100644 drivers/media/platform/cec-gpio/cec-gpio.c

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 7e7cc49b8674..e4c89a16a3e7 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -553,6 +553,16 @@ config VIDEO_MESON_AO_CEC
  This is a driver for Amlogic Meson SoCs AO CEC interface. It uses the
  generic CEC framework interface.
  CEC bus is present in the HDMI connector and enables communication
+
+config CEC_GPIO
+   tristate "Generic GPIO-based CEC driver"
+   depends on PREEMPT
+   select CEC_CORE
+   select CEC_PIN
+   select GPIOLIB
+   ---help---
+ This is a generic GPIO-based CEC driver.
+ The CEC bus is present in the HDMI connector and enables communication
  between compatible devices.
 
 config VIDEO_SAMSUNG_S5P_CEC
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index c1ef946bf032..9bf48f118537 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -26,6 +26,8 @@ obj-$(CONFIG_VIDEO_CODA)  += coda/
 
 obj-$(CONFIG_VIDEO_SH_VEU) += sh_veu.o
 
+obj-$(CONFIG_CEC_GPIO) += cec-gpio/
+
 obj-$(CONFIG_VIDEO_MEM2MEM_DEINTERLACE)+= m2m-deinterlace.o
 
 obj-$(CONFIG_VIDEO_MUX)+= video-mux.o
diff --git a/drivers/media/platform/cec-gpio/Makefile 
b/drivers/media/platform/cec-gpio/Makefile
new file mode 100644
index ..e82b258afa55
--- /dev/null
+++ b/drivers/media/platform/cec-gpio/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_CEC_GPIO) += cec-gpio.o
diff --git a/drivers/media/platform/cec-gpio/cec-gpio.c 
b/drivers/media/platform/cec-gpio/cec-gpio.c
new file mode 100644
index ..eb982bce99fc
--- /dev/null
+++ b/drivers/media/platform/cec-gpio/cec-gpio.c
@@ -0,0 +1,236 @@
+/*
+ * Copyright 2017 Cisco Systems, Inc. and/or its affiliates. All rights 
reserved.
+ *
+ * This program is free software; you may redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct cec_gpio {
+   struct cec_adapter  *adap;
+   struct device   *dev;
+
+   struct gpio_desc*cec_gpio;
+   int cec_irq;
+   boolcec_is_low;
+   boolcec_have_irq;
+
+   struct gpio_desc*hpd_gpio;
+   int hpd_irq;
+   boolhpd_is_high;
+   ktime_t hpd_ts;
+};
+
+static bool cec_gpio_read(struct cec_adapter *adap)
+{
+   struct cec_gpio *cec = cec_get_drvdata(adap);
+
+   if (cec->cec_is_low)
+   return false;
+   return gpiod_get_value(cec->cec_gpio);
+}
+
+static void cec_gpio_high(struct cec_adapter *adap)
+{
+   struct cec_gpio *cec = cec_get_drvdata(adap);
+
+   if (!cec->cec_is_low)
+   return;
+   cec->cec_is_low = false;
+   gpiod_set_value(cec->cec_gpio, 1);
+}
+
+static void cec_gpio_low(struct cec_adapter *adap)
+{
+   struct cec_gpio *cec = cec_get_drvdata(adap);
+
+   if (cec->cec_is_low)
+   return;
+   if (WARN_ON_ONCE(cec->cec_have_irq))
+   free_irq(cec->cec_irq, cec);
+

[PATCHv5 0/5] cec-gpio: add HDMI CEC GPIO-based driver

2017-09-16 Thread Hans Verkuil 
From: Hans Verkuil 

This driver adds support for CEC implementations that use a pull-up
GPIO line. While SoCs exist that do this, the primary use-case is to
turn a single-board computer into a cheap CEC debugger.

Together with 'cec-ctl --monitor-pin' you can do low-level CEC bus
monitoring and do protocol analysis. And error injection is also
planned for the future.

Here is an example using the Raspberry Pi 3:

https://hverkuil.home.xs4all.nl/rpi3-cec.jpg

While this example is for the Rpi, this driver will work for any
SoC with a pull-up GPIO line.

In addition the cec-gpio driver can optionally monitor the HPD line.
The state of the HPD line influences the CEC behavior so it is very
useful to be able to monitor both.

And some HDMI sinks are known to quickly toggle the HPD when e.g.
switching between inputs. So it is useful to be able to see an event
when the HPD changes value.

The first two patches add support for the new HPD events. The last
three patches are for the cec-gpio driver itself.

Regards,

Hans

Changes since v4:

- cec-gpio.txt: *-gpio -> *-gpios
- cec-gpio.txt: document hdmi-phandle. To be used when cec-gpio is
  associated with an HDMI receiver/transmitter.
- cec-gpio.txt: remove incorrect @7 from dts example.

Changes since v3:

- cec-gpio.txt: refer to lines instead of pins and use OPEN_DRAIN
  in the example.
- Kconfig: add select GPIOLIB
- cec-gpio.c: switch to gpiod.
- cec-core.c: initialize the devnode mutex/list in allocate_adapter.
  Doing this in register_adapter is too late if the HPD is high.

Changes since v2:

- Add support for HPD events.
- Switch from pin BCM4 to pin BCM7 in the bindings example

Changes since v1:

- Updated the bindings doc to not refer to the driver, instead
  refer to the hardware.

Hans Verkuil (5):
  cec: add CEC_EVENT_PIN_HPD_LOW/HIGH events
  cec-ioc-dqevent.rst: document new CEC_EVENT_PIN_HPD_LOW/HIGH events
  dt-bindings: document the CEC GPIO bindings
  cec-gpio: add HDMI CEC GPIO driver
  MAINTAINERS: add cec-gpio entry

 .../devicetree/bindings/media/cec-gpio.txt |  29 +++
 Documentation/media/uapi/cec/cec-ioc-dqevent.rst   |  18 ++
 MAINTAINERS|   9 +
 drivers/media/cec/cec-adap.c   |  18 +-
 drivers/media/cec/cec-api.c|  18 +-
 drivers/media/cec/cec-core.c   |   8 +-
 drivers/media/platform/Kconfig |  10 +
 drivers/media/platform/Makefile|   2 +
 drivers/media/platform/cec-gpio/Makefile   |   1 +
 drivers/media/platform/cec-gpio/cec-gpio.c | 236 +
 include/media/cec-pin.h|   4 +
 include/media/cec.h|  12 +-
 include/uapi/linux/cec.h   |   2 +
 13 files changed, 357 insertions(+), 10 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/media/cec-gpio.txt
 create mode 100644 drivers/media/platform/cec-gpio/Makefile
 create mode 100644 drivers/media/platform/cec-gpio/cec-gpio.c

-- 
2.14.1

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

[PATCHv5 5/5] MAINTAINERS: add cec-gpio entry

2017-09-16 Thread Hans Verkuil 
From: Hans Verkuil 

Add an entry for the CEC GPIO driver.

Signed-off-by: Hans Verkuil 
---
 MAINTAINERS | 9 +
 1 file changed, 9 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index eb930ebecfcb..5ef0d34ef502 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3205,6 +3205,15 @@ F:   include/uapi/linux/cec.h
 F: include/uapi/linux/cec-funcs.h
 F: Documentation/devicetree/bindings/media/cec.txt
 
+CEC GPIO DRIVER
+M: Hans Verkuil 
+L: linux-me...@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+W: http://linuxtv.org
+S: Supported
+F: drivers/media/platform/cec-gpio/
+F: Documentation/devicetree/bindings/media/cec-gpio.txt
+
 CELL BROADBAND ENGINE ARCHITECTURE
 M: Arnd Bergmann 
 L: linuxppc-...@lists.ozlabs.org
-- 
2.14.1

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

[PATCHv5 3/5] dt-bindings: document the CEC GPIO bindings

2017-09-16 Thread Hans Verkuil 
From: Hans Verkuil 

Document the bindings for the cec-gpio module for hardware where the
CEC line and optionally the HPD line are connected to GPIO lines.

Signed-off-by: Hans Verkuil 
---
 .../devicetree/bindings/media/cec-gpio.txt | 29 ++
 1 file changed, 29 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/cec-gpio.txt

diff --git a/Documentation/devicetree/bindings/media/cec-gpio.txt 
b/Documentation/devicetree/bindings/media/cec-gpio.txt
new file mode 100644
index ..1b7e13f36b08
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/cec-gpio.txt
@@ -0,0 +1,29 @@
+* HDMI CEC GPIO driver
+
+The HDMI CEC GPIO module supports CEC implementations where the CEC line
+is hooked up to a pull-up GPIO line and - optionally - the HPD line is
+hooked up to another GPIO line.
+
+Required properties:
+  - compatible: value must be "cec-gpio".
+  - cec-gpios: gpio that the CEC line is connected to.
+
+If the CEC line is associated with an HDMI receiver/transmitter, then the
+following property is also required:
+
+  - hdmi-phandle - phandle to the HDMI controller, see also cec.txt.
+
+If the CEC line is not associated with an HDMI receiver/transmitter, then
+the following property is optional:
+
+  - hpd-gpios: gpio that the HPD line is connected to.
+
+Example for the Raspberry Pi 3 where the CEC line is connected to
+pin 26 aka BCM7 aka CE1 on the GPIO pin header and the HPD line is
+connected to pin 11 aka BCM17:
+
+cec-gpio {
+   compatible = "cec-gpio";
+   cec-gpio = <&gpio 7 GPIO_OPEN_DRAIN>;
+   hpd-gpio = <&gpio 17 GPIO_ACTIVE_HIGH>;
+};
-- 
2.14.1

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

[PATCHv5 2/5] cec-ioc-dqevent.rst: document new CEC_EVENT_PIN_HPD_LOW/HIGH events

2017-09-16 Thread Hans Verkuil 
From: Hans Verkuil 

Document these new CEC events.

Signed-off-by: Hans Verkuil 
---
 Documentation/media/uapi/cec/cec-ioc-dqevent.rst | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/Documentation/media/uapi/cec/cec-ioc-dqevent.rst 
b/Documentation/media/uapi/cec/cec-ioc-dqevent.rst
index db615e3405c0..32b47763f5a6 100644
--- a/Documentation/media/uapi/cec/cec-ioc-dqevent.rst
+++ b/Documentation/media/uapi/cec/cec-ioc-dqevent.rst
@@ -160,6 +160,24 @@ it is guaranteed that the state did change in between the 
two events.
   - Generated if the CEC pin goes from a low voltage to a high voltage.
 Only applies to adapters that have the ``CEC_CAP_MONITOR_PIN``
capability set.
+* .. _`CEC-EVENT-PIN-HPD-LOW`:
+
+  - ``CEC_EVENT_PIN_HPD_LOW``
+  - 5
+  - Generated if the HPD pin goes from a high voltage to a low voltage.
+Only applies to adapters that have the ``CEC_CAP_MONITOR_PIN``
+   capability set. When open() is called, the HPD pin can be read and
+   the HPD is low, then an initial event will be generated for that
+   filehandle.
+* .. _`CEC-EVENT-PIN-HPD-HIGH`:
+
+  - ``CEC_EVENT_PIN_HPD_HIGH``
+  - 6
+  - Generated if the HPD pin goes from a low voltage to a high voltage.
+Only applies to adapters that have the ``CEC_CAP_MONITOR_PIN``
+   capability set. When open() is called, the HPD pin can be read and
+   the HPD is high, then an initial event will be generated for that
+   filehandle.
 
 
 .. tabularcolumns:: |p{6.0cm}|p{0.6cm}|p{10.9cm}|
-- 
2.14.1

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

Re: [PATCH 0/8] drm/fb-helper: Use drm_file to get a dumb framebuffer

2017-09-16 Thread Noralf Trønnes 


Den 16.09.2017 14.37, skrev Noralf Trønnes:


Den 15.09.2017 18.37, skrev Noralf Trønnes:


Den 15.09.2017 00.29, skrev Laurent Pinchart:

Hi Noralf,

On Wednesday, 13 September 2017 18:19:22 EEST Noralf Trønnes wrote:

Den 13.09.2017 07.09, skrev Laurent Pinchart:

On Monday, 11 September 2017 17:31:54 EEST Noralf Trønnes wrote:

Hi,

I want to start out by saying that this patchset is low priority 
for me
and if no one has interest or time to review this, that is just 
fine. I

was in the flow and just typed it out.

This patchset adds a way for fbdev emulation code to create a
framebuffer that is backed by a dumb buffer. drm_fb_helper gets a
drm_file to hang the objects on, drm_framebuffer_create_dumb() 
creates

the framebuffer and drm_fb_helper_fini() destroys it.
I have verified that all cma drivers supports dumb buffers, so
converting the library should be fine for all.
Stupid question, what does this give us ? The series makes the 
call stack
more complex (up to a point where I'm getting trouble just 
following it),

what's the advantage that offsets that ?

The short answer is that it avoids the need for special fbdev
_with_funcs() functions in libraries like cma for framebuffers with 
the

dirty callback set.

I'm suprised that you think this more complex, I find it more coherent
when fbdev userspace is doing things more like DRM userspace, like
hanging the objects on a drm_file and cleaning up the objects when 
done.
Maybe moving to a new code base gave me the wrong feeling that the 
result is

more complex. The current implementation is certainly not simple.


The longer and more diffuse answer is that it's annoying me that many
drivers carry the burden of fbdev emulation just to get a console!
I totally agree with that. Ideally I'd like to remove 100% of 
fbdev-related

code from drivers. This includes

- initialization and cleanup of fbdev helpers
- fbdev restore in last_close()
- forwarding of hotplug events to fbdev compatibility layer

In practice we'll likely need to keep one initialization function (or a
drm_driver flag) to let drivers opt-in to fbdev compatibility, but 
the rest
should go away. Or maybe we could even enable fbdev compatibility in 
all

drivers unconditionally.


Interesting idea, maybe something like this:



I just remembered that Daniel said something about the helpers shouldn't
bleed into the core, which my suggestion does :-/



 struct drm_device {
+     struct drm_fb_helper *fbdev;
 };



However, other helpers are allowed pointers in core structures, so if we
can do that we can at least add helpers that can be used directly as
callbacks:

/**
 * drm_fb_helper_lastclose - DRM driver lastclose helper for fbdev
 * @dev: DRM device
 *
 * This function can be used as the &drm_driver->lastclose callback for 
drivers

 * that only need to call drm_fb_helper_restore_fbdev_mode_unlocked().
 *
 * Note: &drm_device->fbdev needs to be set.
 */
void drm_fb_helper_lastclose(struct drm_device *dev)
{
    drm_fb_helper_restore_fbdev_mode_unlocked(dev->fbdev);
}
EXPORT_SYMBOL(drm_fb_helper_lastclose);

/**
 * drm_fb_helper_output_poll_changed - DRM mode config 
\.output_poll_changed

 * helper
 * @dev: DRM device
 *
 * This function can be used as the
 * &drm_mode_config_funcs.output_poll_changed callback for drivers that 
only

 * need to call drm_fb_helper_hotplug_event().
 *
 * Note: &drm_device->fbdev needs to be set.
 */
void drm_fb_helper_output_poll_changed(struct drm_device *dev)
{
    drm_fb_helper_hotplug_event(dev->fbdev);
}
EXPORT_SYMBOL(drm_fb_helper_output_poll_changed);


 void drm_lastclose(struct drm_device * dev)
 {
 DRM_DEBUG("\n");

 if (dev->driver->lastclose)
     dev->driver->lastclose(dev);
+    else if (dev->fbdev)
+ drm_fb_helper_restore_fbdev_mode_unlocked(dev->fbdev);
 DRM_DEBUG("driver lastclose completed\n");

 if (drm_core_check_feature(dev, DRIVER_LEGACY))
     drm_legacy_dev_reinit(dev);
 }

 void drm_kms_helper_hotplug_event(struct drm_device *dev)
 {
 /* send a uevent + call fbdev */
 drm_sysfs_hotplug_event(dev);
 if (dev->mode_config.funcs->output_poll_changed)
     dev->mode_config.funcs->output_poll_changed(dev);
+    else if (dev->fbdev)
+        drm_fb_helper_hotplug_event(dev->fbdev);
 }

 void drm_dev_unregister(struct drm_device *dev)
 {
    struct drm_map_list *r_list, *list_temp;

+    if (dev->fbdev)
+        drm_fb_helper_unregister_fbi(dev->fbdev);
+
 drm_lastclose(dev);
 ...
 }

 static void drm_dev_release(struct kref *ref)
 {
 struct drm_device *dev = container_of(ref, struct drm_device, ref);

+    drm_fb_helper_simple_fini(dev);
+
 if (dev->driver->release) {
     dev->driver->release(dev);
 } else {
     drm_dev_fini(dev);
     kfree(dev);
 }
 }

int driver_probe()
{
    ret = drm_fb_helper_simple_init(dev, ...);
    if (ret)
        DRM_WARN("Oh well fbdev init failed, but don't let that stop 
us\n");

}

I've slight

Re: [git pull] amdkfd next 4.14

2017-09-16 Thread Oded Gabbay 
On Mon, Sep 4, 2017 at 10:50 AM, Daniel Vetter  wrote:
> Hi Alex,
>
> Since Dave is out, can you just pull that into the amd pile?
> -Daniel
>

Hi Alex,
Did you take the patches to your pile ?
If not, I'll ping Dave again as it seems he is back to work (at least
partially).

Oded

> On Sat, Sep 02, 2017 at 04:29:38PM +0300, Oded Gabbay wrote:
>> Hi Dave,
>>
>> Three more amdkfd commits for the 4.14 merge window, nothing too major:
>>
>> - Removing redundant memset before memcpy
>> - Passing valid mqd pointer to destroy_mqd function (fix apply to VI cards)
>> - Replace uint32_t and uint64_t with __u32 and __u64 respectively in 
>> kfd_ioctl.h
>>
>> Thanks,
>> Oded
>>
>> The following changes since commit 7846b12fe0b5feab5446d892f41b5140c1419109:
>>
>>   Merge branch 'drm-vmwgfx-next' of 
>> git://people.freedesktop.org/~syeh/repos_linux into drm-next (2017-08-29 
>> 10:38:14 +1000)
>>
>> are available in the git repository at:
>>
>>   git://people.freedesktop.org/~gabbayo/linux tags/drm-amdkfd-next-2017-09-02
>>
>> for you to fetch changes up to 1fabbf781167052f4480bdcc627378a27e78a559:
>>
>>   drm/amdkfd: pass queue's mqd when destroying mqd (2017-09-02 15:00:25 
>> +0300)
>>
>> 
>> Himanshu Jha (1):
>>   drm/amdkfd: remove memset before memcpy
>>
>> Mikko Rapeli (1):
>>   uapi linux/kfd_ioctl.h: only use __u32 and __u64
>>
>> Oded Gabbay (1):
>>   drm/amdkfd: pass queue's mqd when destroying mqd
>>
>>  drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c  |   2 +-
>>  .../gpu/drm/amd/amdkfd/kfd_process_queue_manager.c |   1 -
>>  include/uapi/linux/kfd_ioctl.h | 172 
>> ++---
>>  3 files changed, 87 insertions(+), 88 deletions(-)
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 102389] Random black screen on RX 470, HDMI 4k-60Hz

2017-09-16 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=102389

--- Comment #4 from jeremi.jasin...@gmail.com ---
I've changed system to Kde Neon, with stock kernel: 4.10.0-33 and amdgpu-pro
driver, but the problem is persistent.

I'm attaching new dmesg and Xorg log files. I don't know if errors in dmesg are
causing black screens, because they come up at different time then the black
screens. So maybe it's problem with monitor? 

I've also noticed that black screen happened at least once in virtual console.

This problem is really annoying, if you need some other logs, or information
please write, and I'll try to provide it.

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

[Bug 102389] Random black screen on RX 470, HDMI 4k-60Hz

2017-09-16 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=102389

--- Comment #5 from jeremi.jasin...@gmail.com ---
Created attachment 134274
  --> https://bugs.freedesktop.org/attachment.cgi?id=134274&action=edit
xorg log from kde neon

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

[Bug 102389] Random black screen on RX 470, HDMI 4k-60Hz

2017-09-16 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=102389

--- Comment #6 from jeremi.jasin...@gmail.com ---
Created attachment 134275
  --> https://bugs.freedesktop.org/attachment.cgi?id=134275&action=edit
dmesg log from kde neon

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

[PATCH v2] drm/rockchip: Replace dev_* with DRM_DEV_*

2017-09-16 Thread Haneen Mohammed 
This patch replace instances of dev_info/err/debug with
DRM_DEV_INFO/ERROR/WARN respectively inorder to use a drm-formatted
specific log messages. Issue corrected with the help of the following
Coccinelle script:

@r@
@@

(
-dev_info
+DRM_DEV_INFO
|
-dev_err
+DRM_DEV_ERROR
|
-dev_dbg
+DRM_DEV_DEBUG
)

Signed-off-by: Haneen Mohammed 
---
Changes in v2:
 - Change patch title
 - Remove redundant print messages from DRM_DEV_*

 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 26 
 drivers/gpu/drm/rockchip/cdn-dp-reg.c   |  2 +-
 drivers/gpu/drm/rockchip/dw-mipi-dsi.c  | 86 ++---
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 19 +++---
 drivers/gpu/drm/rockchip/inno_hdmi.c| 14 ++--
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 12 ++--
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c  |  8 ++-
 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c   | 18 --
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 32 -
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c |  2 +-
 10 files changed, 121 insertions(+), 98 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 9606121..4d3f6ad 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -88,7 +88,7 @@ static void analogix_dp_psr_set(struct drm_encoder *encoder, 
bool enabled)
if (!analogix_dp_psr_supported(dp->dev))
return;
 
-   dev_dbg(dp->dev, "%s PSR...\n", enabled ? "Entry" : "Exit");
+   DRM_DEV_DEBUG(dp->dev, "%s PSR...\n", enabled ? "Entry" : "Exit");
 
spin_lock_irqsave(&dp->psr_lock, flags);
if (enabled)
@@ -110,7 +110,7 @@ static void analogix_dp_psr_work(struct work_struct *work)
ret = rockchip_drm_wait_vact_end(dp->encoder.crtc,
 PSR_WAIT_LINE_FLAG_TIMEOUT_MS);
if (ret) {
-   dev_err(dp->dev, "line flag interrupt did not arrive\n");
+   DRM_DEV_ERROR(dp->dev, "line flag interrupt did not arrive\n");
return;
}
 
@@ -140,13 +140,13 @@ static int rockchip_dp_poweron(struct 
analogix_dp_plat_data *plat_data)
 
ret = clk_prepare_enable(dp->pclk);
if (ret < 0) {
-   dev_err(dp->dev, "failed to enable pclk %d\n", ret);
+   DRM_DEV_ERROR(dp->dev, "failed to enable pclk %d\n", ret);
return ret;
}
 
ret = rockchip_dp_pre_init(dp);
if (ret < 0) {
-   dev_err(dp->dev, "failed to dp pre init %d\n", ret);
+   DRM_DEV_ERROR(dp->dev, "failed to dp pre init %d\n", ret);
clk_disable_unprepare(dp->pclk);
return ret;
}
@@ -211,17 +211,17 @@ static void rockchip_dp_drm_encoder_enable(struct 
drm_encoder *encoder)
else
val = dp->data->lcdsel_big;
 
-   dev_dbg(dp->dev, "vop %s output to dp\n", (ret) ? "LIT" : "BIG");
+   DRM_DEV_DEBUG(dp->dev, "vop %s output to dp\n", (ret) ? "LIT" : "BIG");
 
ret = clk_prepare_enable(dp->grfclk);
if (ret < 0) {
-   dev_err(dp->dev, "failed to enable grfclk %d\n", ret);
+   DRM_DEV_ERROR(dp->dev, "failed to enable grfclk %d\n", ret);
return;
}
 
ret = regmap_write(dp->grf, dp->data->lcdsel_grf_reg, val);
if (ret != 0)
-   dev_err(dp->dev, "Could not write to GRF: %d\n", ret);
+   DRM_DEV_ERROR(dp->dev, "Could not write to GRF: %d\n", ret);
 
clk_disable_unprepare(dp->grfclk);
 }
@@ -277,7 +277,7 @@ static int rockchip_dp_init(struct rockchip_dp_device *dp)
 
dp->grf = syscon_regmap_lookup_by_phandle(np, "rockchip,grf");
if (IS_ERR(dp->grf)) {
-   dev_err(dev, "failed to get rockchip,grf property\n");
+   DRM_DEV_ERROR(dev, "failed to get rockchip,grf property\n");
return PTR_ERR(dp->grf);
}
 
@@ -287,31 +287,31 @@ static int rockchip_dp_init(struct rockchip_dp_device *dp)
} else if (PTR_ERR(dp->grfclk) == -EPROBE_DEFER) {
return -EPROBE_DEFER;
} else if (IS_ERR(dp->grfclk)) {
-   dev_err(dev, "failed to get grf clock\n");
+   DRM_DEV_ERROR(dev, "failed to get grf clock\n");
return PTR_ERR(dp->grfclk);
}
 
dp->pclk = devm_clk_get(dev, "pclk");
if (IS_ERR(dp->pclk)) {
-   dev_err(dev, "failed to get pclk property\n");
+   DRM_DEV_ERROR(dev, "failed to get pclk property\n");
return PTR_ERR(dp->pclk);
}
 
dp->rst = devm_reset_control_get(dev, "dp");
if (IS_ERR(dp->rst)) {
-   dev_err(dev, "failed to get dp reset control\n");
+   DRM_DEV_ERROR(dev, "failed to get dp reset control\n");
return PTR_ERR(dp->rst);
}
 
ret = clk_prepare_enab

[PATCH v1 1/3] media: vsp1: Prevent resuming DRM pipelines

2017-09-16 Thread Kieran Bingham 
DRM pipelines utilising the VSP must stop all frame processing as part
of the suspend operation to ensure the hardware is idle. Upon resume,
the pipeline must not be started until the DU performs an atomic flush
to restore the hardware configuration and state.

Therefore the vsp1_pipeline_resume() call is not needed for DRM
pipelines, and we can disable it in this instance.

CC: linux-me...@vger.kernel.org

Signed-off-by: Kieran Bingham 
---
 drivers/media/platform/vsp1/vsp1_drv.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/vsp1/vsp1_drv.c 
b/drivers/media/platform/vsp1/vsp1_drv.c
index 962e4c304076..7604c7994c74 100644
--- a/drivers/media/platform/vsp1/vsp1_drv.c
+++ b/drivers/media/platform/vsp1/vsp1_drv.c
@@ -582,7 +582,13 @@ static int __maybe_unused vsp1_pm_resume(struct device 
*dev)
struct vsp1_device *vsp1 = dev_get_drvdata(dev);
 
pm_runtime_force_resume(vsp1->dev);
-   vsp1_pipelines_resume(vsp1);
+
+   /*
+* DRM pipelines are stopped before suspend, and will be resumed after
+* the DRM subsystem has reconfigured its pipeline with an atomic flush
+*/
+   if (!vsp1->drm)
+   vsp1_pipelines_resume(vsp1);
 
return 0;
 }
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v1 3/3] drm: rcar-du: Remove unused CRTC suspend/resume functions

2017-09-16 Thread Kieran Bingham 
An early implementation of suspend-resume helpers are available in the
CRTC module, however they are unused and no longer needed.

With suspend and resume handled by the core DRM atomic helpers, we can
remove the unused functions.

CC: dri-devel@lists.freedesktop.org

Signed-off-by: Kieran Bingham 
---
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 35 +---
 1 file changed, 35 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 301ea1a8018e..b492063a6e1f 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -557,41 +557,6 @@ static void rcar_du_crtc_stop(struct rcar_du_crtc *rcrtc)
rcar_du_group_start_stop(rcrtc->group, false);
 }
 
-void rcar_du_crtc_suspend(struct rcar_du_crtc *rcrtc)
-{
-   if (rcar_du_has(rcrtc->group->dev, RCAR_DU_FEATURE_VSP1_SOURCE))
-   rcar_du_vsp_disable(rcrtc);
-
-   rcar_du_crtc_stop(rcrtc);
-   rcar_du_crtc_put(rcrtc);
-}
-
-void rcar_du_crtc_resume(struct rcar_du_crtc *rcrtc)
-{
-   unsigned int i;
-
-   if (!rcrtc->crtc.state->active)
-   return;
-
-   rcar_du_crtc_get(rcrtc);
-   rcar_du_crtc_setup(rcrtc);
-
-   /* Commit the planes state. */
-   if (!rcar_du_has(rcrtc->group->dev, RCAR_DU_FEATURE_VSP1_SOURCE)) {
-   for (i = 0; i < rcrtc->group->num_planes; ++i) {
-   struct rcar_du_plane *plane = &rcrtc->group->planes[i];
-
-   if (plane->plane.state->crtc != &rcrtc->crtc)
-   continue;
-
-   rcar_du_plane_setup(plane);
-   }
-   }
-
-   rcar_du_crtc_update_planes(rcrtc);
-   rcar_du_crtc_start(rcrtc);
-}
-
 /* 
-
  * CRTC Functions
  */
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v1 2/3] drm: rcar-du: Add suspend resume helpers

2017-09-16 Thread Kieran Bingham 
The pipeline needs to ensure that the hardware is idle for suspend and
resume operations.

Implement suspend and resume functions using the DRM atomic helper
functions.

CC: dri-devel@lists.freedesktop.org

Signed-off-by: Kieran Bingham 
---
 drivers/gpu/drm/rcar-du/rcar_du_drv.c | 18 +++---
 drivers/gpu/drm/rcar-du/rcar_du_drv.h |  1 +
 2 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c 
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index 09fbceade6b1..01b91d0c169c 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -22,6 +22,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -267,9 +268,19 @@ static struct drm_driver rcar_du_driver = {
 static int rcar_du_pm_suspend(struct device *dev)
 {
struct rcar_du_device *rcdu = dev_get_drvdata(dev);
+   struct drm_atomic_state *state;
 
drm_kms_helper_poll_disable(rcdu->ddev);
-   /* TODO Suspend the CRTC */
+   drm_fbdev_cma_set_suspend_unlocked(rcdu->fbdev, true);
+
+   state = drm_atomic_helper_suspend(rcdu->ddev);
+   if (IS_ERR(state)) {
+   drm_fbdev_cma_set_suspend_unlocked(rcdu->fbdev, false);
+   drm_kms_helper_poll_enable(rcdu->ddev);
+   return PTR_ERR(state);
+   }
+
+   rcdu->suspend_state = state;
 
return 0;
 }
@@ -278,9 +289,10 @@ static int rcar_du_pm_resume(struct device *dev)
 {
struct rcar_du_device *rcdu = dev_get_drvdata(dev);
 
-   /* TODO Resume the CRTC */
-
+   drm_atomic_helper_resume(rcdu->ddev, rcdu->suspend_state);
+   drm_fbdev_cma_set_suspend_unlocked(rcdu->fbdev, false);
drm_kms_helper_poll_enable(rcdu->ddev);
+
return 0;
 }
 #endif
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h 
b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
index f8cd79488ece..f400fde65a0c 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
@@ -81,6 +81,7 @@ struct rcar_du_device {
 
struct drm_device *ddev;
struct drm_fbdev_cma *fbdev;
+   struct drm_atomic_state *suspend_state;
 
struct rcar_du_crtc crtcs[RCAR_DU_MAX_CRTCS];
unsigned int num_crtcs;
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v1 0/3] drm/media: Implement DU Suspend and Resume on VSP pipelines

2017-09-16 Thread Kieran Bingham 
This short series covers two subsystems and implements support for suspend and
resume operations on the DU pipelines on Gen3 Rcar platforms.

Patch 1: Prevent resuming DRM pipelines,
  - Ensures that the VSP does not incorrectly start DU pipelines.

Patch 2: Add suspend resume helpers
  - Makes use of the atomic helper functions to control the CRTCs
and fbdev emulation.

Patch 3: Remove unused CRTC suspend/resume functions
  - Cleans up some old, related but unused functions that are not
necessary to keep in the code base.

Whilst this is posted as a single series, there are no hard dependencies
between any of the three patches. They can be picked up independently as
and when they are successfully reviewed.

This series can be fetched from the following:

 git://git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git 
tags/vsp-du/du-suspend-resume/v1
  
It is based upon a merge of both the current linux-media master branch and the 
DRM drm-next tree.

Kieran Bingham (3):
  media: vsp1: Prevent resuming DRM pipelines
  drm: rcar-du: Add suspend resume helpers
  drm: rcar-du: Remove unused CRTC suspend/resume functions

 drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 35 +---
 drivers/gpu/drm/rcar-du/rcar_du_drv.c  | 18 +++---
 drivers/gpu/drm/rcar-du/rcar_du_drv.h  |  1 +-
 drivers/media/platform/vsp1/vsp1_drv.c |  8 +-
 4 files changed, 23 insertions(+), 39 deletions(-)

base-commit: 8d2ec9ae96657bbd539d88dbc9d01088f2c9ee63
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v1 2/3] drm: rcar-du: Add suspend resume helpers

2017-09-16 Thread Kieran Bingham 
Hi Laurent,

Thanks for your speedy review!

On 15/09/17 18:02, Laurent Pinchart wrote:
> Hi Kieran,
> 
> Thank you for the patch.
> 
> On Friday, 15 September 2017 19:42:06 EEST Kieran Bingham wrote:
>> The pipeline needs to ensure that the hardware is idle for suspend and
>> resume operations.
> 
> I'm not sure to really understand this sentence.

It makes sense to me ... :) - But I'm not the (only) target audience.

How about re-wording it in a similar way to your suggestion in [1/3]

"""
To support system suspend operations we must ensure the hardware is stopped, and
resumed explicitly from the suspend and resume handlers.

Implement suspend and resume functions using the DRM atomic helper
functions.
"""


> 
>> Implement suspend and resume functions using the DRM atomic helper
>> functions.
>>
>> CC: dri-devel@lists.freedesktop.org
>>
>> Signed-off-by: Kieran Bingham 
> 
> The rest of the patch looks good to me. With the commit message clarified,
> 
> Reviewed-by: Laurent Pinchart 
> 
>> ---
>>  drivers/gpu/drm/rcar-du/rcar_du_drv.c | 18 +++---
>>  drivers/gpu/drm/rcar-du/rcar_du_drv.h |  1 +
>>  2 files changed, 16 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
>> b/drivers/gpu/drm/rcar-du/rcar_du_drv.c index 09fbceade6b1..01b91d0c169c
>> 100644
>> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
>> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
>> @@ -22,6 +22,7 @@
>>  #include 
>>
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -267,9 +268,19 @@ static struct drm_driver rcar_du_driver = {
>>  static int rcar_du_pm_suspend(struct device *dev)
>>  {
>>  struct rcar_du_device *rcdu = dev_get_drvdata(dev);
>> +struct drm_atomic_state *state;
>>
>>  drm_kms_helper_poll_disable(rcdu->ddev);
>> -/* TODO Suspend the CRTC */
>> +drm_fbdev_cma_set_suspend_unlocked(rcdu->fbdev, true);
>> +
>> +state = drm_atomic_helper_suspend(rcdu->ddev);
>> +if (IS_ERR(state)) {
>> +drm_fbdev_cma_set_suspend_unlocked(rcdu->fbdev, false);
>> +drm_kms_helper_poll_enable(rcdu->ddev);
>> +return PTR_ERR(state);
>> +}
>> +
>> +rcdu->suspend_state = state;
>>
>>  return 0;
>>  }
>> @@ -278,9 +289,10 @@ static int rcar_du_pm_resume(struct device *dev)
>>  {
>>  struct rcar_du_device *rcdu = dev_get_drvdata(dev);
>>
>> -/* TODO Resume the CRTC */
>> -
>> +drm_atomic_helper_resume(rcdu->ddev, rcdu->suspend_state);
>> +drm_fbdev_cma_set_suspend_unlocked(rcdu->fbdev, false);
>>  drm_kms_helper_poll_enable(rcdu->ddev);
>> +
>>  return 0;
>>  }
>>  #endif
>> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
>> b/drivers/gpu/drm/rcar-du/rcar_du_drv.h index f8cd79488ece..f400fde65a0c
>> 100644
>> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
>> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
>> @@ -81,6 +81,7 @@ struct rcar_du_device {
>>
>>  struct drm_device *ddev;
>>  struct drm_fbdev_cma *fbdev;
>> +struct drm_atomic_state *suspend_state;
>>
>>  struct rcar_du_crtc crtcs[RCAR_DU_MAX_CRTCS];
>>  unsigned int num_crtcs;
> 
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/amdgpu: revert tile table update for oland

2017-09-16 Thread Jean Delvare 
On Thu, 14 Sep 2017 12:31:29 -0400, Alex Deucher wrote:
> On Thu, Sep 14, 2017 at 12:21 PM, Marek Olšák  wrote:
> > Reviewed-by: Marek Olšák   
> 
> Applied.  thanks.
> 
> Alex

Thanks. I forgot the tag but this is obviously a candidate for stable
trees. I have prepared  different version for older kernels already,
I'll post it to stable@ after the fix is merged into Linus' tree.

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

GC2000 series support GLES3

2017-09-16 Thread Torsten Sievers 
Hi guys,

when i reading through the (somewhen) upcoming iMX8 and its GC7000 series i
stumbled over this one:

http://www.vivantecorp.com/index.php/en/technology/3d.html

at the very end it is stating the the GC2000 series support GLES3.

However when i am looking at my device on the hummingboard it appears to
support only GLES2...

Am I doing something wrong or Is this a etnaviv restriction? If so is there
anything that we can help to support it?

BTW: does anybody know if etnaviv is / will support the GC7000 already?

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

Re: drm: Why shmem?

2017-09-16 Thread Eric Anholt 
Noralf Trønnes  writes:

> Den 15.09.2017 02.45, skrev Eric Anholt:
>> Noralf Trønnes  writes:
>>
>>> Den 30.08.2017 09.40, skrev Daniel Vetter:
 On Tue, Aug 29, 2017 at 10:40:04AM -0700, Eric Anholt wrote:
> Daniel Vetter  writes:
>
>> On Mon, Aug 28, 2017 at 8:44 PM, Noralf Trønnes  
>> wrote:
>>> Hi,
>>>
>>> Currently I'm using the cma library with tinydrm because it was so
>>> simple to use even though I have to work around the fact that reads are
>>> uncached. A bigger problem that I have become aware of, is that it
>>> restricts the dma buffers it can import since they have to be continous.
>>>
>>> So I looked to udl and it uses shmem. Fine, let's make a shmem gem
>>> library similar to the cma library.
>>>
>>> Now I have done so and have started to think about the DOC: section,
>>> explaining what the library does. And I'm stuck, what's the benefit of
>>> using shmem compared to just using alloc_page()?
>> Gives you swapping (and eventually maybe even migration) since there's
>> a real filesystem behind it. Atm this only works if you register a
>> shrinker callback, which for display drivers is a bit overkill. See
>> i915 or msm for examples (or ttm, if you want an entire fancy
>> framework), and git grep shrinker -- drivers/gpu.
> The shrinker is only needed if you need some impetus to unbind objects
> from your page tables, right?  If you're just binding the pages for the
> moment that you're doing SPI transfers to the display, then in the
> remaining time it could be swapped out, right?
 Yup, and for SPI the setup overhead shouldn't matter. But everyone else
 probably wants to cache mappings and page lists, and that means some kind
 of shrinker to drop them when needed.
>>> Let me see if I've understood this correctly:
>>>
>>> The first time I call drm_gem_get_pages() the buffer pages are
>>> allocated and pinned.
>>> When I then call drm_gem_put_pages() the pages are unpinned, but not freed.
>>> The kernel is now free to swap out the pages if necessary.
>>> Calling drm_gem_get_pages() a second time will swapin the pages if
>>> necessary and pin them.
>>>
>>> If this is correct, where are pages freed?
>> drm_gem_object_release() during freeing of the object.
>>
>
> I see that you get the pages in vc5_bo_create() and put them in
> vc5_free_object(). This means that you don't benefit from the shmem
> "advantage" of swapping.
> Why do you use shmem? Simplicity since it's built into DRM?

I *just* started writing this driver.  I'm not unpinning objects under
memory pressure ye.t


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

[Bug 102646] Screen flickering under amdgpu-experimental (buffer corruptions?)

2017-09-16 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=102646

--- Comment #11 from Justin Mitzel  ---
The problem also happens in Kernel 4.13.2. Although it does not seem as bad.

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

[Bug 102646] Screen flickering under amdgpu-experimental (buffer corruptions?)

2017-09-16 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=102646

--- Comment #12 from Justin Mitzel  ---
Created attachment 134285
  --> https://bugs.freedesktop.org/attachment.cgi?id=134285&action=edit
New Xorg Log

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

[PATCH] gpu: ipu-v3: ipu-dc: Remove unused 'di' variable

2017-09-16 Thread Fabio Estevam 
From: Fabio Estevam 

The 'di' variable is never used inside lipu_dc_enable_channel(),
so just remove it.

This fixes the following build warning with W=1:

drivers/gpu/ipu-v3/ipu-dc.c: In function 'ipu_dc_enable_channel':
drivers/gpu/ipu-v3/ipu-dc.c:252:6: warning: variable 'di' set but not used 
[-Wunused-but-set-variable] 

Signed-off-by: Fabio Estevam 
---
 drivers/gpu/ipu-v3/ipu-dc.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/gpu/ipu-v3/ipu-dc.c b/drivers/gpu/ipu-v3/ipu-dc.c
index 7a4b836..49bfe6e 100644
--- a/drivers/gpu/ipu-v3/ipu-dc.c
+++ b/drivers/gpu/ipu-v3/ipu-dc.c
@@ -249,11 +249,8 @@ EXPORT_SYMBOL_GPL(ipu_dc_enable);
 
 void ipu_dc_enable_channel(struct ipu_dc *dc)
 {
-   int di;
u32 reg;
 
-   di = dc->di;
-
reg = readl(dc->base + DC_WR_CH_CONF);
reg |= DC_WR_CH_CONF_PROG_TYPE_NORMAL;
writel(reg, dc->base + DC_WR_CH_CONF);
-- 
2.7.4

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

[PATCH v2] gpu: ipu-v3: ipu-dc: Remove unused 'di' variable

2017-09-16 Thread Fabio Estevam 
From: Fabio Estevam 

The 'di' variable is never used inside ipu_dc_enable_channel(),
so just remove it.

This fixes the following build warning with W=1:

drivers/gpu/ipu-v3/ipu-dc.c: In function 'ipu_dc_enable_channel':
drivers/gpu/ipu-v3/ipu-dc.c:252:6: warning: variable 'di' set but not used 
[-Wunused-but-set-variable] 

Signed-off-by: Fabio Estevam 
---
Changes since v1:
- Fix a typo in the function name in the commit log.

 drivers/gpu/ipu-v3/ipu-dc.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/gpu/ipu-v3/ipu-dc.c b/drivers/gpu/ipu-v3/ipu-dc.c
index 7a4b836..49bfe6e 100644
--- a/drivers/gpu/ipu-v3/ipu-dc.c
+++ b/drivers/gpu/ipu-v3/ipu-dc.c
@@ -249,11 +249,8 @@ EXPORT_SYMBOL_GPL(ipu_dc_enable);
 
 void ipu_dc_enable_channel(struct ipu_dc *dc)
 {
-   int di;
u32 reg;
 
-   di = dc->di;
-
reg = readl(dc->base + DC_WR_CH_CONF);
reg |= DC_WR_CH_CONF_PROG_TYPE_NORMAL;
writel(reg, dc->base + DC_WR_CH_CONF);
-- 
2.7.4

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

[lkp-robot] [drm/fb] a583bc678d: WARNING:at_kernel/workqueue.c:#flush_workqueue

2017-09-16 Thread kernel test robot 

FYI, we noticed the following commit:

commit: a583bc678d0a5e54844d3380e242dd9bb5fb0b00 ("drm/fb-helper: Allocate a 
drm_file")
url: 
https://github.com/0day-ci/linux/commits/Noralf-Tr-nnes/drm-fb-helper-Use-drm_file-to-get-a-dumb-framebuffer/20170914-132818
base: git://people.freedesktop.org/~airlied/linux.git drm-next

in testcase: boot

on test machine: qemu-system-x86_64 -enable-kvm -smp 2 -m 512M

caused below changes (please refer to attached dmesg/kmsg for entire 
log/backtrace):


++++
|| 6b0c88fff7 | a583bc678d |
++++
| boot_successes | 66 | 0  |
| boot_failures  | 0  | 77 |
| WARNING:at_kernel/workqueue.c:#flush_workqueue | 0  | 32 |
| kernel_BUG_at_lib/list_debug.c | 0  | 66 |
| invalid_opcode:#[##]   | 0  | 66 |
| Kernel_panic-not_syncing:Fatal_exception   | 0  | 77 |
| BUG:unable_to_handle_kernel| 0  | 11 |
| Oops:#[##] | 0  | 11 |
++++



[   14.785867] WARNING: CPU: 0 PID: 5 at kernel/workqueue.c:2606 
flush_workqueue+0x881/0x8b0
[   14.798652] list_del corruption. prev->next should be 88001c459300, but 
was   (null)
[   14.798673] [ cut here ]
[   14.798674] kernel BUG at lib/list_debug.c:56!
[   14.798677] invalid opcode:  [#1] PREEMPT
[   14.798679] CPU: 0 PID: 24 Comm: kworker/u2:1 Not tainted 
4.13.0-rc5-01112-ga583bc6 #1
[   14.798680] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.9.3-20161025_171302-gandalf 04/01/2014
[   14.798686] task: 88001d31f0c0 task.stack: c90c
[   14.798690] RIP: 0010:__list_del_entry_valid+0x155/0x160
[   14.798691] RSP: :c90c3e60 EFLAGS: 00010086
[   14.798693] RAX: 0054 RBX: 0003 RCX: 
[   14.798693] RDX: 0002 RSI:  RDI: 0046
[   14.798694] RBP: c90c3e88 R08:  R09: 
[   14.798695] R10: 88001d31f110 R11: 6c756e28 R12: 88001c459300
[   14.798696] R13: 88001c491cc0 R14: 88001d1bc030 R15: 
[   14.798698] FS:  () GS:8422f000() 
knlGS:
[   14.798699] CS:  0010 DS:  ES:  CR0: 80050033
[   14.798700] CR2: 00a8 CR3: 0420e000 CR4: 06f0
[   14.798702] Call Trace:
[   14.798707]  worker_thread+0x1c5/0x810
[   14.798709]  kthread+0x187/0x190
[   14.798711]  ? process_one_work+0x7f0/0x7f0
[   14.798712]  ? __kthread_create_on_node+0x260/0x260
[   14.798715]  ret_from_fork+0x25/0x30
[   14.798716] Code: 06 7e ff 0f 0b 4c 89 f2 4c 89 e6 48 c7 c7 c0 d9 db 83 e8 
9f 06 7e ff 0f 0b 49 8b 16 4c 89 e6 48 c7 c7 f8 d9 db 83 e8 8b 06 7e ff <0f> 0b 
90 90 90 90 90 90 90 90 90 55 48 89 f8 45 31 db 41 ba 01 
[   14.798741] RIP: __list_del_entry_valid+0x155/0x160 RSP: c90c3e60
[   14.798746] ---[ end trace 22b1dffd04582160 ]---


To reproduce:

git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k  job-script  # job-script is attached in this 
email



Thanks,
Xiaolong
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.13.0-rc5 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=28
CONFIG_ARCH_MMAP_RND_BITS_MAX=32
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y

#
# General setup
#