[RFC][PATCH 5/5] drm_hwcomposer: HACK: Fix tearing on hikey/hikey960

[John Stultz]

When using drm_hwcomposer with the hikey/hikey960 boards, the
resulting display shows lots of tearing.

I'm not much of an expert in how this code should work, but it
seems that we never call sync_wait(), and thus don't seem to be
handling the fences properly? I'm not sure.

Anyway, in a daze, I started cutting out code trying to make
sure we call the CreateNextTimelineFence() and
fb.set_release_fence_fd().

After doing so the tearing went away. I'm really not sure
what is wrong that requires these hacks. It may be the
hikey/hikey960 drm driver is incorrectly reporting or
handling something?

We do only have a single plane and no hardware compositing on
the boards, so we are having to force the gpu to do all the
compositing.

Any ideas for what a proper fix here would be? Or even just
hints on why this might make things work?

Change-Id: Ifba58f6f1cb00e5271892c0241e4891abe211f22
Cc: Marissa Wall 
Cc: Sean Paul 
Cc: Dmitry Shmidt 
Cc: Robert Foss 
Cc: Matt Szczesiak 
Cc: Liviu Dudau 
Cc: David Hanna 
Cc: Rob Herring 
Signed-off-by: John Stultz 
---
 drmdisplaycompositor.cpp | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drmdisplaycompositor.cpp b/drmdisplaycompositor.cpp
index acd13b8..6c391d6 100644
--- a/drmdisplaycompositor.cpp
+++ b/drmdisplaycompositor.cpp
@@ -299,10 +299,11 @@ int 
DrmDisplayCompositor::ApplySquash(DrmDisplayComposition *display_comp) {
display_comp->importer());
   pre_compositor_->Finish();
 
-  if (ret) {
+/*  if (ret) {
 ALOGE("Failed to squash layers");
 return ret;
   }
+*/
 
   ret = display_comp->CreateNextTimelineFence();
   if (ret <= 0) {
@@ -390,8 +391,8 @@ int 
DrmDisplayCompositor::PrepareFrame(DrmDisplayComposition *display_comp) {
   std::vector &layers = display_comp->layers();
   std::vector &comp_planes =
   display_comp->composition_planes();
-  std::vector &squash_regions =
-  display_comp->squash_regions();
+//  std::vector &squash_regions =
+//  display_comp->squash_regions();
   std::vector &pre_comp_regions =
   display_comp->pre_comp_regions();
 
@@ -405,7 +406,7 @@ int 
DrmDisplayCompositor::PrepareFrame(DrmDisplayComposition *display_comp) {
   }
 
   int squash_layer_index = -1;
-  if (squash_regions.size() > 0) {
+  if (1) { //squash_regions.size() > 0) {
 squash_framebuffer_index_ = (squash_framebuffer_index_ + 1) % 2;
 ret = ApplySquash(display_comp);
 if (ret)
-- 
2.7.4

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

[RFC][PATCH 4/5] drm_hwcomposer: HACK: force single plane

[John Stultz]

From: Rob Herring 

Change from Rob to force use of single plane.

Without this we don't see anything on the screen.

Suggestions for alternative solutions here would
be greatly appreciated!

Change-Id: Ic963c356ab1ef241d92fde6c890936b560f52051
Cc: Marissa Wall 
Cc: Sean Paul 
Cc: Dmitry Shmidt 
Cc: Robert Foss 
Cc: Matt Szczesiak 
Cc: Liviu Dudau 
Cc: David Hanna 
Cc: Rob Herring 
Signed-off-by: John Stultz 
---
 drmhwctwo.cpp | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drmhwctwo.cpp b/drmhwctwo.cpp
index dfca1a6..5ab4595 100644
--- a/drmhwctwo.cpp
+++ b/drmhwctwo.cpp
@@ -692,12 +692,10 @@ HWC2::Error 
DrmHwcTwo::HwcDisplay::ValidateDisplay(uint32_t *num_types,
   case HWC2::Composition::SolidColor:
   case HWC2::Composition::Cursor:
   case HWC2::Composition::Sideband:
+  default:
 layer.set_validated_type(HWC2::Composition::Client);
 ++*num_types;
 break;
-  default:
-layer.set_validated_type(layer.sf_type());
-break;
 }
   }
   return *num_types ? HWC2::Error::HasChanges : HWC2::Error::None;
-- 
2.7.4

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

[RFC][PATCH 3/5] drm_hwcomposer: Add platformhisi buffer importer for hikey and hikey960

[John Stultz]

This allows for importing buffers allocated from the
hikey and hikey960 gralloc implelementations.

Change-Id: I81abdd4d1dc7d9f2ef31078c91679b532d3262fd
Cc: Marissa Wall 
Cc: Sean Paul 
Cc: Dmitry Shmidt 
Cc: Robert Foss 
Cc: Matt Szczesiak 
Cc: Liviu Dudau 
Cc: David Hanna 
Cc: Rob Herring 
Signed-off-by: John Stultz 
---
 Android.mk   |  12 
 platformhisi.cpp | 200 +++
 platformhisi.h   |  50 ++
 3 files changed, 262 insertions(+)
 create mode 100644 platformhisi.cpp
 create mode 100644 platformhisi.h

diff --git a/Android.mk b/Android.mk
index ee5b8bf..caafce1 100644
--- a/Android.mk
+++ b/Android.mk
@@ -66,6 +66,7 @@ LOCAL_SRC_FILES := \
hwcutils.cpp \
platform.cpp \
platformdrmgeneric.cpp \
+   platformhisi.cpp \
separate_rects.cpp \
virtualcompositorworker.cpp \
vsyncworker.cpp
@@ -74,7 +75,18 @@ LOCAL_CPPFLAGS += \
-DHWC2_USE_CPP11 \
-DHWC2_INCLUDE_STRINGIFICATION
 
+
+ifeq ($(TARGET_PRODUCT),hikey960)
+LOCAL_CPPFLAGS += -DUSE_HISI_IMPORTER -DUSE_IMAGE_EXTERNAL_ESSL3 
-DUSE_TEXTURE_FN
+LOCAL_C_INCLUDES += device/linaro/hikey/gralloc960/
+else
+ifeq ($(TARGET_PRODUCT),hikey)
+LOCAL_CPPFLAGS += -DUSE_HISI_IMPORTER -DHIKEY
+LOCAL_C_INCLUDES += device/linaro/hikey/gralloc/
+else
 LOCAL_CPPFLAGS += -DUSE_DRM_GENERIC_IMPORTER
+endif
+endif
 
 LOCAL_MODULE := hwcomposer.drm
 LOCAL_MODULE_TAGS := optional
diff --git a/platformhisi.cpp b/platformhisi.cpp
new file mode 100644
index 000..123c8f2
--- /dev/null
+++ b/platformhisi.cpp
@@ -0,0 +1,200 @@
+/*
+ * Copyright (C) 2015 The Android Open Source Project
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+#define LOG_TAG "hwc-platform-hisi"
+
+#include "drmresources.h"
+#include "platform.h"
+#include "platformhisi.h"
+
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include "gralloc_priv.h"
+
+
+namespace android {
+
+#ifdef USE_HISI_IMPORTER
+// static
+Importer *Importer::CreateInstance(DrmResources *drm) {
+  HisiImporter *importer = new HisiImporter(drm);
+  if (!importer)
+return NULL;
+
+  int ret = importer->Init();
+  if (ret) {
+ALOGE("Failed to initialize the hisi importer %d", ret);
+delete importer;
+return NULL;
+  }
+  return importer;
+}
+#endif
+
+HisiImporter::HisiImporter(DrmResources *drm) : drm_(drm) {
+}
+
+HisiImporter::~HisiImporter() {
+}
+
+int HisiImporter::Init() {
+  int ret = hw_get_module(GRALLOC_HARDWARE_MODULE_ID,
+  (const hw_module_t **)&gralloc_);
+  if (ret) {
+ALOGE("Failed to open gralloc module %d", ret);
+return ret;
+  }
+
+  if (strcasecmp(gralloc_->common.author, "NVIDIA"))
+ALOGW("Using non-NVIDIA gralloc module: %s/%s\n", gralloc_->common.name,
+  gralloc_->common.author);
+
+  return 0;
+}
+
+#ifdef HIKEY
+uint32_t HisiImporter::ConvertHalFormatToDrm(uint32_t hal_format) {
+  switch (hal_format) {
+case HAL_PIXEL_FORMAT_RGB_888:
+  return DRM_FORMAT_BGR888;
+case HAL_PIXEL_FORMAT_BGRA_:
+  return DRM_FORMAT_ARGB;
+case HAL_PIXEL_FORMAT_RGBX_:
+  return DRM_FORMAT_XBGR;
+case HAL_PIXEL_FORMAT_RGBA_:
+  return DRM_FORMAT_ABGR;
+case HAL_PIXEL_FORMAT_RGB_565:
+  return DRM_FORMAT_BGR565;
+case HAL_PIXEL_FORMAT_YV12:
+  return DRM_FORMAT_YVU420;
+default:
+  ALOGE("Cannot convert hal format to drm format %u", hal_format);
+  return -EINVAL;
+  }
+}
+#else /* HIKEY960 case*/
+uint32_t HisiImporter::ConvertHalFormatToDrm(uint32_t hal_format) {
+  switch (hal_format) {
+case HAL_PIXEL_FORMAT_RGB_888:
+  return DRM_FORMAT_BGR888;
+case HAL_PIXEL_FORMAT_BGRA_:
+  return DRM_FORMAT_XBGR;
+case HAL_PIXEL_FORMAT_RGBX_:
+  return DRM_FORMAT_XBGR;
+case HAL_PIXEL_FORMAT_RGBA_:
+  return DRM_FORMAT_XBGR;
+case HAL_PIXEL_FORMAT_RGB_565:
+  return DRM_FORMAT_BGR565;
+case HAL_PIXEL_FORMAT_YV12:
+  return DRM_FORMAT_YVU420;
+default:
+  ALOGE("Cannot convert hal format to drm format %u", hal_format);
+  return -EINVAL;
+  }
+}
+#endif /* HIKEY */
+
+EGLImageKHR HisiImporter::ImportImage(EGLDisplay egl_display, buffer_handle_t 
handle) {
+  private_handle_t const *hnd = reinterpret_cast < private_handle_t const 
*>(handle);
+  if (!hnd)
+return NULL;
+  EGLint attr[] = {
+EGL_WIDTH, hnd->width,
+EGL_HE

[RFC][PATCH 1/5] drm_hwcomposer: provide a common gralloc handle definition

[John Stultz]

From: Rob Herring 

EGL, gralloc, and HWC must all have a common definition of fd's and int's
in native_handle_t to share the fd and width, height, format, etc. of a
dmabuf.

Move the definition into HWC so we aren't dependent on a specific gralloc
implementation and so we don't have to create an importer just for
different native_handle_t layouts. This will allow supporting multiple
gralloc implementations that conform to this layout.

For now, this is aligned with gbm_gralloc's struct. Once we change
gbm_gralloc and mesa to point to this copy, we can make modifications to
the struct.

Change-Id: I0e0e9994c7a13e6c47f00a70d13cd2ef9b1543d3
Cc: Marissa Wall 
Cc: Sean Paul 
Cc: Dmitry Shmidt 
Cc: Robert Foss 
Cc: Matt Szczesiak 
Cc: Liviu Dudau 
Cc: David Hanna 
Signed-off-by: Rob Herring 
[jstultz: This patch is important to be able to build AOSP
 without having to include the gbm_gralloc project.]
Signed-off-by: John Stultz 
---
 Android.mk   |  1 -
 gralloc_drm_handle.h | 87 
 2 files changed, 87 insertions(+), 1 deletion(-)
 create mode 100644 gralloc_drm_handle.h

diff --git a/Android.mk b/Android.mk
index 8b11e37..ee5b8bf 100644
--- a/Android.mk
+++ b/Android.mk
@@ -47,7 +47,6 @@ LOCAL_SHARED_LIBRARIES := \
 LOCAL_STATIC_LIBRARIES := libdrmhwc_utils
 
 LOCAL_C_INCLUDES := \
-   external/drm_gralloc \
system/core/libsync
 
 LOCAL_SRC_FILES := \
diff --git a/gralloc_drm_handle.h b/gralloc_drm_handle.h
new file mode 100644
index 000..e2f35dd
--- /dev/null
+++ b/gralloc_drm_handle.h
@@ -0,0 +1,87 @@
+/*
+ * Copyright (C) 2010-2011 Chia-I Wu 
+ * Copyright (C) 2010-2011 LunarG Inc.
+ * Copyright (C) 2016-2017 Linaro, Ltd., Rob Herring 
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included
+ * in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE 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.
+ */
+
+#ifndef _GRALLOC_DRM_HANDLE_H_
+#define _GRALLOC_DRM_HANDLE_H_
+
+#include 
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+struct gralloc_drm_handle_t {
+   native_handle_t base;
+
+   /* file descriptors */
+   int prime_fd;
+
+   /* integers */
+   int magic;
+
+   int width;
+   int height;
+   int format;
+   int usage;
+
+   int name;   /* the name of the bo */
+   int stride; /* the stride in bytes */
+   int data_owner; /* owner of data (for validation) */
+
+   uint64_t modifier __attribute__((aligned(8))); /* buffer modifiers */
+   union {
+   void *data; /* private pointer for gralloc */
+   uint64_t reserved;
+   } __attribute__((aligned(8)));
+};
+#define GRALLOC_HANDLE_MAGIC 0x5f47424d
+#define GRALLOC_HANDLE_NUM_FDS 1
+#define GRALLOC_HANDLE_NUM_INTS (  
\
+   ((sizeof(struct gralloc_drm_handle_t) - 
sizeof(native_handle_t))/sizeof(int))   \
+- GRALLOC_HANDLE_NUM_FDS)
+
+static inline struct gralloc_drm_handle_t *gralloc_drm_handle(buffer_handle_t 
_handle)
+{
+   struct gralloc_drm_handle_t *handle =
+   (struct gralloc_drm_handle_t *) _handle;
+
+   if (handle && (handle->base.version != sizeof(handle->base) ||
+  handle->base.numInts != GRALLOC_HANDLE_NUM_INTS ||
+  handle->base.numFds != GRALLOC_HANDLE_NUM_FDS ||
+  handle->magic != GRALLOC_HANDLE_MAGIC))
+   return NULL;
+
+   return handle;
+}
+
+static inline int gralloc_drm_get_prime_fd(buffer_handle_t _handle)
+{
+   struct gralloc_drm_handle_t *handle = gralloc_drm_handle(_handle);
+   return (handle) ? handle->prime_fd : -1;
+}
+
+#ifdef __cplusplus
+}
+#endif
+#endif /* _GRALLOC_DRM_HANDLE_H_ */
-- 
2.7.4

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

[RFC][PATCH 2/5] drm_hwcomposer: glworker: Add build time options for certain shader feature names

[John Stultz]

In order to get the hikey960, which uses the mali bifrost driver
working with drm_hwcomposer, its needed to tweak some extension
and funciton names used in the shaders.

Specifically:
* GL_OES_EGL_image_external_essl3 instead of
  GL_OES_EGL_image_external
* texture() instead of texture2D()

Which is configured using a build time definition.

Credit to Matt Szczesiak for suggesting these changes to get
hikey960 working!

I'm a bit new to all this, and I expect there may be a better
way to do this, so I'd love any feedback or comments!

Change-Id: I2c8f08341ad086479b66241b903c79b00f2a0feb
Cc: Marissa Wall 
Cc: Sean Paul 
Cc: Dmitry Shmidt 
Cc: Robert Foss 
Cc: Matt Szczesiak 
Cc: Liviu Dudau 
Cc: David Hanna 
Cc: Rob Herring 
Signed-off-by: John Stutlz 
---
 glworker.cpp | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/glworker.cpp b/glworker.cpp
index ca726bf..c35d1b6 100644
--- a/glworker.cpp
+++ b/glworker.cpp
@@ -41,6 +41,17 @@
 
 #define MAX_OVERLAPPING_LAYERS 64
 
+#ifdef USE_TEXTURE_FN
+ #define TEXTURE_STR "texture"
+#else
+ #define TEXTURE_STR "texture2D"
+#endif
+
+#ifdef USE_IMAGE_EXTERNAL_ESSL3
+ #define IMAGE_EXTERNAL_STR "GL_OES_EGL_image_external_essl3"
+#else
+ #define IMAGE_EXTERNAL_STR "GL_OES_EGL_image_external"
+#endif
 namespace android {
 
 // clang-format off
@@ -237,7 +248,7 @@ static std::string GenerateFragmentShader(int layer_count) {
   std::ostringstream fragment_shader_stream;
   fragment_shader_stream << "#version 300 es\n"
  << "#define LAYER_COUNT " << layer_count << "\n"
- << "#extension GL_OES_EGL_image_external : require\n"
+ << "#extension " << IMAGE_EXTERNAL_STR << " : 
require\n"
  << "precision mediump float;\n";
   for (int i = 0; i < layer_count; ++i) {
 fragment_shader_stream << "uniform samplerExternalOES uLayerTexture" << i
@@ -257,7 +268,7 @@ static std::string GenerateFragmentShader(int layer_count) {
   fragment_shader_stream << "  if (alphaCover > 0.5/255.0) {\n";
 // clang-format off
 fragment_shader_stream
-<< "  texSample = texture2D(uLayerTexture" << i << ",\n"
+<< "  texSample = " << TEXTURE_STR << "(uLayerTexture" << i << ",\n"
 << "fTexCoords[" << i << "]);\n"
 << "  multRgb = texSample.rgb *\n"
 << "max(texSample.a, uLayerPremult[" << i << "]);\n"
-- 
2.7.4

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

[RFC][PATCH 0/5] drm_hwcomposer: Changes to support HiKey/HiKey960

[John Stultz]

This patchset is an inital RFC I wanted to send out to get some
early review and feedback.

I've been working to enable the drm_hwcomposer for HiKey and
HiKey960 boards in AOSP, and this patchset contains the required
changes to the drm_hwcomposer code to get things working.

I'm really quite naive when it comes to graphics, and I'm sure I
don't fully understand the drm_hwcomposer code, so forgive me if
I've done anything terribly stupid here.

There are a few terrible hacks involved, which I'd really love
to get any guidance on how things should be properly done here.

The first is I'm using Rob's patch to force use of single plane,
without which I don't get anything on the screen.

The second is that after getting the drm_hwcomposer running, I
was seeing tons of tearing, which was exactly the behavior I'm
making this effort to avoid. So I have another hack patch that
removes some checks that fail which keep us from doing fence
handling properly. Again, any tips for what deeper issues need
to be addressed would be helpful!

Finally, the third hack isn't in this patchset, but in the
kernel, where with the drm_hwcomposer, on initialization, we
would hit the case where it was trying to enable vsync while the
crtc is off.  So I worked around that here:
https://git.linaro.org/people/john.stultz/android-dev.git/commit/?h=dev/hikey-hwcomposer-deps&id=30aa3e944e5c87fd4f61333a123d365e99825e3a

For that last issue, I'm not sure if this is due to some quirk
w/ the drm_hwcomposer initialization, or some other quirk of the
kirin drm driver,  but in development of this, I've also worked
with an older drm based hwc implementations which didn't trigger
this issue.

Anyway, outside of those hacks I'm sure there can be further
improvement as well, so I wanted to get it out for some initial
review.

If anyone wants to try the code out on either a HiKey or
HiKey960, you will need this patchset on top of the
freedesktop/master branch of drm_hwcomposer. You'll also need
the freedesktop/master branch of libdrm. You'll need the
following patches to the device/linaro/hikey project: 
https://github.com/johnstultz-work/android_device_linaro_hikey/commits/drm_hwc

And you'll need to replace the kernel Image-dtb with one built
from the following tree:
https://git.linaro.org/people/john.stultz/android-dev.git/log/?h=dev/hikey-hwcomposer-deps

Any thoughts or feedback will be very much appreciated!

Many thanks to Rob Herring and Matt Szczesiak for help to get
this working so far!

Thanks so much for your time!
-john

Cc: Marissa Wall 
Cc: Sean Paul 
Cc: Dmitry Shmidt 
Cc: Robert Foss 
Cc: Matt Szczesiak 
Cc: Liviu Dudau 
Cc: David Hanna 
Cc: Rob Herring 

John Stultz (3):
  drm_hwcomposer: glworker: Add build time options for certain shader
feature names
  drm_hwcomposer: Add platformhisi buffer importer for hikey and
hikey960
  drm_hwcomposer: HACK: Fix tearing on hikey/hikey960

Rob Herring (2):
  drm_hwcomposer: provide a common gralloc handle definition
  drm_hwcomposer: HACK: force single plane

 Android.mk   |  13 ++-
 drmdisplaycompositor.cpp |   9 ++-
 drmhwctwo.cpp|   4 +-
 glworker.cpp |  15 +++-
 gralloc_drm_handle.h |  87 +
 platformhisi.cpp | 200 +++
 platformhisi.h   |  50 
 7 files changed, 368 insertions(+), 10 deletions(-)
 create mode 100644 gralloc_drm_handle.h
 create mode 100644 platformhisi.cpp
 create mode 100644 platformhisi.h

-- 
2.7.4

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

[PATCH] libdrm: intel/Android.mk: Filter libdrm_intel library requirements on x86

[John Stultz]

When building AOSP after updating libdrm project to the
freedesktop/master branch, I've seen the following build errors:

external/libdrm/intel/Android.mk: error: libdrm_intel
(SHARED_LIBRARIES android-arm64) missing libpciaccess
(SHARED_LIBRARIES android-arm64) You can set
ALLOW_MISSING_DEPENDENCIES=true in your environment if this is
intentional, but that may defer real problems until later in the
build.

Using ALLOW_MISSING_DEPENDENCIES=true when building allows
things to function properly, but is not ideal.

So basically, while I'm not including the libdrm_intel package
into the build, just the fact that the Android.mk file references
libpciaccess which isn't a repo included in AOSP causes the build
failure.

So it seems we need some sort of conditional filter in the
Android.mk to skip over it if we're not building for intel.

This is my initial attempt at solving this.

Feedback would be greatly appreciated!

I note that in the AOSP version of libdrm, the reference to
libpciaccess has been removed. See:
 
https://android.googlesource.com/platform/external/libdrm/+/f6a1130dffae8de9ddd0c379066daf1df27fc8af%5E%21/
So I wonder if it make sense to instead remove this upstream as
well?

While this patch addresses upstream's Andorid.mk, I also notice
that the AOSP version of libdrm has converted to Android.bp files:
 
https://android.googlesource.com/platform/external/libdrm/+/fa32e29a1fe81e5472aabc65d3aa25a5af5aec55%5E%21/
and wonder if getting that conversion upstream would be a good
idea here?

Cc: Emil Velikov 
Cc: Chad Versace 
Cc: Marissa Wall 
Cc: Sean Paul 
Cc: Rob Herring 
Cc: Dan Willemsen 
Cc: Tomasz Figa 
Signed-off-by: John Stultz 
---
 intel/Android.mk | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/intel/Android.mk b/intel/Android.mk
index 5407ff3..d834692 100644
--- a/intel/Android.mk
+++ b/intel/Android.mk
@@ -21,6 +21,7 @@
 # IN THE SOFTWARE.
 #
 
+ifeq ($(TARGET_ARCH), x86)
 LOCAL_PATH := $(call my-dir)
 include $(CLEAR_VARS)
 
@@ -37,3 +38,4 @@ LOCAL_SHARED_LIBRARIES := \
 
 include $(LIBDRM_COMMON_MK)
 include $(BUILD_SHARED_LIBRARY)
+endif
-- 
2.7.4

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

Re: [PATCH v2 6/6] drm/tinydrm: Embed the mode in tinydrm_connector

[David Lechner]

On 01/09/2018 08:05 AM, Noralf Trønnes wrote:


Den 09.01.2018 11.08, skrev Daniel Vetter:

On Mon, Jan 08, 2018 at 07:46:27PM -0600, David Lechner wrote:

On 01/07/2018 11:44 AM, Noralf Trønnes wrote:

Embed the mode in tinydrm_connector instead of doing an devm_ allocation.
Remove unnecessary use of ret variable at the end of
tinydrm_display_pipe_init().

Signed-off-by: Noralf Trønnes 
---

Reviewed-by: David Lechner 

Since you two work together quit a bit, should we add David as drm-misc
committer?


I would love that. What do you say David?
This would mean that you will commit your own work after getting ack/rb.


Well... I suppose that would be alright.

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

Re: [PATCH v2 4/6] drm/tinydrm/mipi-dbi: Add poweron-reset functions

[David Lechner]

On 01/09/2018 09:01 AM, Noralf Trønnes wrote:


Den 09.01.2018 02.38, skrev David Lechner:

On 01/07/2018 11:44 AM, Noralf Trønnes wrote:

Split out common poweron-reset functionality.

Signed-off-by: Noralf Trønnes 
---
  drivers/gpu/drm/tinydrm/mi0283qt.c | 20 ++--
  drivers/gpu/drm/tinydrm/mipi-dbi.c | 63 ++
  drivers/gpu/drm/tinydrm/st7586.c   |  9 ++
  drivers/gpu/drm/tinydrm/st7735r.c  |  8 ++---
  include/drm/tinydrm/mipi-dbi.h |  2 ++
  5 files changed, 73 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/tinydrm/mi0283qt.c 
b/drivers/gpu/drm/tinydrm/mi0283qt.c
index c69a4d958f24..2a78bcd35045 100644
--- a/drivers/gpu/drm/tinydrm/mi0283qt.c
+++ b/drivers/gpu/drm/tinydrm/mi0283qt.c
@@ -49,31 +49,17 @@
    static int mi0283qt_init(struct mipi_dbi *mipi)
  {
-    struct tinydrm_device *tdev = &mipi->tinydrm;
-    struct device *dev = tdev->drm->dev;
  u8 addr_mode;
  int ret;
    DRM_DEBUG_KMS("\n");
  -    ret = regulator_enable(mipi->regulator);
-    if (ret) {
-    DRM_DEV_ERROR(dev, "Failed to enable regulator %d\n", ret);
+    ret = mipi_dbi_poweron_conditional_reset(mipi);
+    if (ret < 0)
  return ret;
-    }
-
-    /* Avoid flicker by skipping setup if the bootloader has done it */
-    if (mipi_dbi_display_is_on(mipi))
+    if (ret > 0)
  return 0;


If I am reading the patch right, it looks like there are two

if (ret > 0)
   return 0;

in a row with nothing in between when this is applied.


  -    mipi_dbi_hw_reset(mipi);
-    ret = mipi_dbi_command(mipi, MIPI_DCS_SOFT_RESET);
-    if (ret) {
-    DRM_DEV_ERROR(dev, "Error sending command %d\n", ret);
-    regulator_disable(mipi->regulator);
-    return ret;
-    }
-
  msleep(20);
    mipi_dbi_command(mipi, MIPI_DCS_SET_DISPLAY_OFF);
diff --git a/drivers/gpu/drm/tinydrm/mipi-dbi.c 
b/drivers/gpu/drm/tinydrm/mipi-dbi.c
index ecc5c81a93ac..eea6803ff223 100644
--- a/drivers/gpu/drm/tinydrm/mipi-dbi.c
+++ b/drivers/gpu/drm/tinydrm/mipi-dbi.c
@@ -463,6 +463,7 @@ bool mipi_dbi_display_is_on(struct mipi_dbi *mipi)
    val &= ~DCS_POWER_MODE_RESERVED_MASK;
  +    /* The poweron/reset value is 08h DCS_POWER_MODE_DISPLAY_NORMAL_MODE */
  if (val != (DCS_POWER_MODE_DISPLAY |
  DCS_POWER_MODE_DISPLAY_NORMAL_MODE | DCS_POWER_MODE_SLEEP_MODE))
  return false;
@@ -473,6 +474,68 @@ bool mipi_dbi_display_is_on(struct mipi_dbi *mipi)
  }
  EXPORT_SYMBOL(mipi_dbi_display_is_on);
  +static int mipi_dbi_por_conditional(struct mipi_dbi *mipi, bool cond)


I know it is long, but it would be nice to spell out poweron_reset here
instead of "por".


+{
+    struct device *dev = mipi->tinydrm.drm->dev;
+    int ret;
+
+    if (mipi->regulator) {
+    ret = regulator_enable(mipi->regulator);
+    if (ret) {
+    DRM_DEV_ERROR(dev, "Failed to enable regulator (%d)\n", ret);
+    return ret;
+    }
+    }
+
+    if (cond && mipi_dbi_display_is_on(mipi))
+    return 1;
+
+    mipi_dbi_hw_reset(mipi);
+    ret = mipi_dbi_command(mipi, MIPI_DCS_SOFT_RESET);


It seems unnecessary to do a soft reset after a hard reset, but I suppose some 
displays
don't have a hard reset and the extra soft reset shouldn't hurt anything.



Both ILI9341 and ST7735R (not ST7586S) lists soft reset as part of the
Power Flow Chart, but it's not explicit about it being required or not:

Power on sequence
HW reset
SW reset
State is now Sleep in

I looked in the MIPI DBI spec and there's nothing about requiring both
hw _and_ soft reset. But I have seen hard and soft reset in many panel
init's, so I think we keep this as the default. It has a 5ms penalty.
I could shave that off in mipi_dbi_hw_reset(). It keeps reset low for
20ms, but the spec says it just has to be longer than 9us with noise
spikes less than 20ns wide:

-    msleep(20);
+    usleep_range(20, 1000);



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

[PATCH libdrm] modetest: Fix to check return value of asprintf()

[Seung-Woo Kim]

There is warning about ignoring return value of 'asprintf'. Fix to
check return value of asprintf().

Signed-off-by: Seung-Woo Kim 
---
 tests/modetest/modetest.c |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 62d9332..0773bd0 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -656,10 +656,13 @@ static struct resources *get_resources(struct device *dev)
for (i = 0; i < res->res->count_connectors; i++) {
struct connector *connector = &res->connectors[i];
drmModeConnector *conn = connector->connector;
+   int num;
 
-   asprintf(&connector->name, "%s-%u",
+   num = asprintf(&connector->name, "%s-%u",
 util_lookup_connector_type_name(conn->connector_type),
 conn->connector_type_id);
+   if (num < 0)
+   goto error;
}
 
 #define get_properties(_res, __res, type, Type)
\
-- 
1.7.4.1

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

Re: [PATCH] drm/radeon: fill in rb backend map on evergreen/ni.

[Roland Scheidegger]

FWIW I was wrong that it was never filled in - when the backend map
query was introduced, the data indeed got filled in. However that got
lost very soon afterwards (over 6 years ago) by some fixes for backend
map calculation.
In any case,
Reviewed-by: Roland Scheidegger 

Am 09.01.2018 um 04:43 schrieb Dave Airlie:
> From: Dave Airlie 
> 
> This looks to have never gotten filled in, and it seems to
>  trigger a bug in mesa.
> 
> Reported-by: Roland Scheidegger 
> Signed-off-by: Dave Airlie 
> ---
>  drivers/gpu/drm/radeon/evergreen.c | 1 +
>  drivers/gpu/drm/radeon/ni.c| 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/radeon/evergreen.c 
> b/drivers/gpu/drm/radeon/evergreen.c
> index 24fe66c..5712d63 100644
> --- a/drivers/gpu/drm/radeon/evergreen.c
> +++ b/drivers/gpu/drm/radeon/evergreen.c
> @@ -3513,6 +3513,7 @@ static void evergreen_gpu_init(struct radeon_device 
> *rdev)
>   tmp = r6xx_remap_render_backend(rdev, tmp, 
> rdev->config.evergreen.max_backends,
>   EVERGREEN_MAX_BACKENDS, 
> disabled_rb_mask);
>   }
> + rdev->config.evergreen.backend_map = tmp;
>   WREG32(GB_BACKEND_MAP, tmp);
>  
>   WREG32(CGTS_SYS_TCC_DISABLE, 0);
> diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
> index 9eccd0c..381b0255 100644
> --- a/drivers/gpu/drm/radeon/ni.c
> +++ b/drivers/gpu/drm/radeon/ni.c
> @@ -1148,6 +1148,7 @@ static void cayman_gpu_init(struct radeon_device *rdev)
>   
> rdev->config.cayman.max_shader_engines,
>   CAYMAN_MAX_BACKENDS, 
> disabled_rb_mask);
>   }
> + rdev->config.cayman.backend_map = tmp;
>   WREG32(GB_BACKEND_MAP, tmp);
>  
>   cgts_tcc_disable = 0x;
> 

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

[PATCH v2 1/2] drm/bridge/synopsys: dsi: use common mipi_dsi_create_packet()

[Brian Norris]

This takes care of 2 TODOs in this driver, by using the common DSI
packet-marshalling code instead of our custom short/long write code.
This both saves us some duplicated code and gets us free support for
command types that weren't already part of our switch block (e.g.,
MIPI_DSI_GENERIC_LONG_WRITE).

The code logic stays mostly intact, except that it becomes unnecessary
to split the short/long write functions, and we have to copy data a bit
more.

Along the way, I noticed that loop bounds were a little odd:

while (DIV_ROUND_UP(len, pld_data_bytes))

This really was just supposed to be 'len != 0', so I made that more
clear.

Tested on RK3399 with some pending refactoring patches by Nickey Yang,
to make the Rockchip DSI driver wrap this common driver.

Signed-off-by: Brian Norris 
Reviewed-by: Philippe Cornu 
Tested-by: Philippe Cornu 
---
v2:
 * remove "dcs" naming, since these commands handle generic DSI too, not
   just DCS (thanks Philippe)
 * add Philippe's {Tested,Reviewed}-by
---
 drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 78 ++-
 1 file changed, 16 insertions(+), 62 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index d9cca4fd66ec..ed91e32ee43a 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -136,10 +136,6 @@
 GEN_SW_0P_TX_LP)
 
 #define DSI_GEN_HDR0x6c
-/* TODO These 2 defines will be reworked thanks to mipi_dsi_create_packet() */
-#define GEN_HDATA(data)(((data) & 0x) << 8)
-#define GEN_HTYPE(type)(((type) & 0xff) << 0)
-
 #define DSI_GEN_PLD_DATA   0x70
 
 #define DSI_CMD_PKT_STATUS 0x74
@@ -359,44 +355,15 @@ static int dw_mipi_dsi_gen_pkt_hdr_write(struct 
dw_mipi_dsi *dsi, u32 hdr_val)
return 0;
 }
 
-static int dw_mipi_dsi_dcs_short_write(struct dw_mipi_dsi *dsi,
-  const struct mipi_dsi_msg *msg)
-{
-   const u8 *tx_buf = msg->tx_buf;
-   u16 data = 0;
-   u32 val;
-
-   if (msg->tx_len > 0)
-   data |= tx_buf[0];
-   if (msg->tx_len > 1)
-   data |= tx_buf[1] << 8;
-
-   if (msg->tx_len > 2) {
-   dev_err(dsi->dev, "too long tx buf length %zu for short 
write\n",
-   msg->tx_len);
-   return -EINVAL;
-   }
-
-   val = GEN_HDATA(data) | GEN_HTYPE(msg->type);
-   return dw_mipi_dsi_gen_pkt_hdr_write(dsi, val);
-}
-
-static int dw_mipi_dsi_dcs_long_write(struct dw_mipi_dsi *dsi,
- const struct mipi_dsi_msg *msg)
+static int dw_mipi_dsi_write(struct dw_mipi_dsi *dsi,
+const struct mipi_dsi_packet *packet)
 {
-   const u8 *tx_buf = msg->tx_buf;
-   int len = msg->tx_len, pld_data_bytes = sizeof(u32), ret;
-   u32 hdr_val = GEN_HDATA(msg->tx_len) | GEN_HTYPE(msg->type);
+   const u8 *tx_buf = packet->payload;
+   int len = packet->payload_length, pld_data_bytes = sizeof(u32), ret;
u32 remainder;
u32 val;
 
-   if (msg->tx_len < 3) {
-   dev_err(dsi->dev, "wrong tx buf length %zu for long write\n",
-   msg->tx_len);
-   return -EINVAL;
-   }
-
-   while (DIV_ROUND_UP(len, pld_data_bytes)) {
+   while (len) {
if (len < pld_data_bytes) {
remainder = 0;
memcpy(&remainder, tx_buf, len);
@@ -419,40 +386,27 @@ static int dw_mipi_dsi_dcs_long_write(struct dw_mipi_dsi 
*dsi,
}
}
 
-   return dw_mipi_dsi_gen_pkt_hdr_write(dsi, hdr_val);
+   remainder = 0;
+   memcpy(&remainder, packet->header, sizeof(packet->header));
+   return dw_mipi_dsi_gen_pkt_hdr_write(dsi, remainder);
 }
 
 static ssize_t dw_mipi_dsi_host_transfer(struct mipi_dsi_host *host,
 const struct mipi_dsi_msg *msg)
 {
struct dw_mipi_dsi *dsi = host_to_dsi(host);
+   struct mipi_dsi_packet packet;
int ret;
 
-   /*
-* TODO dw drv improvements
-* use mipi_dsi_create_packet() instead of all following
-* functions and code (no switch cases, no
-* dw_mipi_dsi_dcs_short_write(), only the loop in long_write...)
-* and use packet.header...
-*/
-   dw_mipi_message_config(dsi, msg);
-
-   switch (msg->type) {
-   case MIPI_DSI_DCS_SHORT_WRITE:
-   case MIPI_DSI_DCS_SHORT_WRITE_PARAM:
-   case MIPI_DSI_SET_MAXIMUM_RETURN_PACKET_SIZE:
-   ret = dw_mipi_dsi_dcs_short_write(dsi, msg);
-   break;
-   case MIPI_DSI_DCS_LONG_WRITE:
-   ret = dw_mipi_dsi_dcs_long_write(dsi, msg);
-   break;
-   default:
-   dev_err(dsi->dev, "unsupported message type

[PATCH] drm/bridge/synopsys: dsi: make dw_mipi_dsi_bridge_mode_set() static

[Brian Norris]

sparse complains:

drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c:703:6: warning: symbol
'dw_mipi_dsi_bridge_mode_set' was not declared. Should it be static?

Signed-off-by: Brian Norris 
---
 drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index 90f13df6f106..d60a77e98b57 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -700,9 +700,9 @@ static void dw_mipi_dsi_bridge_post_disable(struct 
drm_bridge *bridge)
pm_runtime_put(dsi->dev);
 }
 
-void dw_mipi_dsi_bridge_mode_set(struct drm_bridge *bridge,
-struct drm_display_mode *mode,
-struct drm_display_mode *adjusted_mode)
+static void dw_mipi_dsi_bridge_mode_set(struct drm_bridge *bridge,
+   struct drm_display_mode *mode,
+   struct drm_display_mode *adjusted_mode)
 {
struct dw_mipi_dsi *dsi = bridge_to_dsi(bridge);
const struct dw_mipi_dsi_phy_ops *phy_ops = dsi->plat_data->phy_ops;
-- 
2.16.0.rc1.238.g530d649a79-goog

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

[PATCH v2 2/2] drm/bridge/synopsys: dsi: handle endianness correctly in dw_mipi_dsi_write()

[Brian Norris]

We're filling the "remainder" word with little-endian data, then writing
it out to IO registers with endian-correcting writel(). That probably
won't work on big-endian systems.

Let's mark the "remainder" variable as LE32 (since we fill it with
memcpy()) and do the swapping explicitly.

Some of this function could be done more easily without memcpy(), but
the unaligned "remainder" case is a little hard to do without
potentially overrunning 'tx_buf', so I just applied the same solution in
all cases (memcpy() + le32_to_cpu()).

Tested only on a little-endian system.

Signed-off-by: Brian Norris 
---
 drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index ed91e32ee43a..90f13df6f106 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -360,18 +360,18 @@ static int dw_mipi_dsi_write(struct dw_mipi_dsi *dsi,
 {
const u8 *tx_buf = packet->payload;
int len = packet->payload_length, pld_data_bytes = sizeof(u32), ret;
-   u32 remainder;
+   __le32 word;
u32 val;
 
while (len) {
if (len < pld_data_bytes) {
-   remainder = 0;
-   memcpy(&remainder, tx_buf, len);
-   dsi_write(dsi, DSI_GEN_PLD_DATA, remainder);
+   word = 0;
+   memcpy(&word, tx_buf, len);
+   dsi_write(dsi, DSI_GEN_PLD_DATA, le32_to_cpu(word));
len = 0;
} else {
-   memcpy(&remainder, tx_buf, pld_data_bytes);
-   dsi_write(dsi, DSI_GEN_PLD_DATA, remainder);
+   memcpy(&word, tx_buf, pld_data_bytes);
+   dsi_write(dsi, DSI_GEN_PLD_DATA, le32_to_cpu(word));
tx_buf += pld_data_bytes;
len -= pld_data_bytes;
}
@@ -386,9 +386,9 @@ static int dw_mipi_dsi_write(struct dw_mipi_dsi *dsi,
}
}
 
-   remainder = 0;
-   memcpy(&remainder, packet->header, sizeof(packet->header));
-   return dw_mipi_dsi_gen_pkt_hdr_write(dsi, remainder);
+   word = 0;
+   memcpy(&word, packet->header, sizeof(packet->header));
+   return dw_mipi_dsi_gen_pkt_hdr_write(dsi, le32_to_cpu(word));
 }
 
 static ssize_t dw_mipi_dsi_host_transfer(struct mipi_dsi_host *host,
-- 
2.16.0.rc1.238.g530d649a79-goog

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

Re: [PATCH] drm/bridge/synopsys: dsi: use common mipi_dsi_create_packet()

[Brian Norris]

Hi Philippe,

On Tue, Jan 09, 2018 at 10:48:43AM +, Philippe CORNU wrote:
> Hi Brian,
> 
> And many thanks for implementing these TODOs.

And thanks for adding them; it gave me a better option than just adding
yet another switch case (MIPI_DSI_GENERIC_LONG_WRITE) ;)

> On 01/06/2018 01:38 AM, Brian Norris wrote:
> > This takes care of 2 TODOs in this driver, by using the common DSI
> > packet-marshalling code instead of our custom short/long write code.
> > This both saves us some duplicated code and gets us free support for
> > command types that weren't already part of our switch block (e.g.,
> > MIPI_DSI_GENERIC_LONG_WRITE).
> > 
> > The code logic stays mostly intact, except that it becomes unnecessary
> > to split the short/long write functions, and we have to copy data a bit
> > more.
> > 
> > Along the way, I noticed that loop bounds were a little odd:
> > 
> > while (DIV_ROUND_UP(len, pld_data_bytes))
> > 
> > This really was just supposed to be 'len != 0', so I made that more
> > clear.
> > 
> > Tested on RK3399 with some pending refactoring patches by Nickey Yang,
> > to make the Rockchip DSI driver wrap this common driver.
> > 
> > Signed-off-by: Brian Norris 
> > ---
> > Could use an extra look from folks. This looks like the correct trivial
> > transformation, but I'm not that familiar with DSI.
> > 
> >   drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 78 
> > ++-
> >   1 file changed, 16 insertions(+), 62 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
> > b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> > index d9cca4fd66ec..2fed20e44dfe 100644
> > --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> > +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> > @@ -136,10 +136,6 @@
> >  GEN_SW_0P_TX_LP)
> >   
> >   #define DSI_GEN_HDR   0x6c
> > -/* TODO These 2 defines will be reworked thanks to 
> > mipi_dsi_create_packet() */
> > -#define GEN_HDATA(data)(((data) & 0x) << 8)
> > -#define GEN_HTYPE(type)(((type) & 0xff) << 0)
> > -
> >   #define DSI_GEN_PLD_DATA  0x70
> >   
> >   #define DSI_CMD_PKT_STATUS0x74
> > @@ -359,44 +355,15 @@ static int dw_mipi_dsi_gen_pkt_hdr_write(struct 
> > dw_mipi_dsi *dsi, u32 hdr_val)
> > return 0;
> >   }
> >   
> > -static int dw_mipi_dsi_dcs_short_write(struct dw_mipi_dsi *dsi,
> > -  const struct mipi_dsi_msg *msg)
> > -{
> > -   const u8 *tx_buf = msg->tx_buf;
> > -   u16 data = 0;
> > -   u32 val;
> > -
> > -   if (msg->tx_len > 0)
> > -   data |= tx_buf[0];
> > -   if (msg->tx_len > 1)
> > -   data |= tx_buf[1] << 8;
> > -
> > -   if (msg->tx_len > 2) {
> > -   dev_err(dsi->dev, "too long tx buf length %zu for short 
> > write\n",
> > -   msg->tx_len);
> > -   return -EINVAL;
> > -   }
> > -
> > -   val = GEN_HDATA(data) | GEN_HTYPE(msg->type);
> > -   return dw_mipi_dsi_gen_pkt_hdr_write(dsi, val);
> > -}
> > -
> > -static int dw_mipi_dsi_dcs_long_write(struct dw_mipi_dsi *dsi,
> > - const struct mipi_dsi_msg *msg)
> > +static int dw_mipi_dsi_dcs_write(struct dw_mipi_dsi *dsi,
> > +const struct mipi_dsi_packet *packet)
> 
> Both DCS and Generic dsi transfers are managed by drm_mipi_dsi.c 
> helpers. So maybe dw_mipi_dsi_dcs_write() should be renamed 
> dw_mipi_dsi_write()...

Ah, good point. I really meant to remove the _dcs naming too, but I
guess I missed it. Will follow up.

> >   {
> > -   const u8 *tx_buf = msg->tx_buf;
> > -   int len = msg->tx_len, pld_data_bytes = sizeof(u32), ret;
> > -   u32 hdr_val = GEN_HDATA(msg->tx_len) | GEN_HTYPE(msg->type);
> > +   const u8 *tx_buf = packet->payload;
> > +   int len = packet->payload_length, pld_data_bytes = sizeof(u32), ret;
> > u32 remainder;
> > u32 val;
> >   
> > -   if (msg->tx_len < 3) {
> > -   dev_err(dsi->dev, "wrong tx buf length %zu for long write\n",
> > -   msg->tx_len);
> > -   return -EINVAL;
> > -   }
> > -
> > -   while (DIV_ROUND_UP(len, pld_data_bytes)) {
> > +   while (len) {
> > if (len < pld_data_bytes) {
> > remainder = 0;
> > memcpy(&remainder, tx_buf, len);
> > @@ -419,40 +386,27 @@ static int dw_mipi_dsi_dcs_long_write(struct 
> > dw_mipi_dsi *dsi,
> > }
> > }
> >   
> > -   return dw_mipi_dsi_gen_pkt_hdr_write(dsi, hdr_val);
> > +   remainder = 0;
> > +   memcpy(&remainder, packet->header, sizeof(packet->header));

By the way: I don't think it's an issue that should block this patch,
since if I'm right, this function already is "broken", but isn't this
actually a bad way to handle byte-to-word marshalling? Particularly,
we're copying bytes into a word in LE ordering, but then we later write
them to IO registers with writel() (which does 

[PATCH] drm/i915: Don't allow HDCP on PORT E/F

[Sean Paul]

Port E doesn't have HDCP support, and Port F is disabled. Don't setup
the hdcp shim on those.

Reviewed-by: Daniel Vetter 
Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/i915/intel_hdmi.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 22251ad48b3b..09b52d218fd4 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -2296,7 +2296,8 @@ void intel_hdmi_init_connector(struct intel_digital_port 
*intel_dig_port,
 
intel_hdmi_add_properties(intel_hdmi, connector);
 
-   if (INTEL_GEN(dev_priv) >= 9) {
+   /* PORT E doesn't have HDCP, and PORT F is disabled */
+   if (INTEL_GEN(dev_priv) >= 9 && port < PORT_E) {
int ret = intel_hdcp_init(intel_connector,
  &intel_hdmi_hdcp_shim);
if (ret)
-- 
2.15.1.620.gb9897f4670-goog

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

[PATCH] drm/i915: Only disable HDCP when it's active

[Sean Paul]

Instead of always trying to disable HDCP. Only run hdcp_disable when the
state is not UNDESIRED. This will catch cases where it's enabled and
also cases where enable failed and the state is left in DESIRED mode.

Note that things won't blow up if disable is attempted while already
disabled, it's just bad form.

Reviewed-by: Daniel Vetter 
Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/i915/intel_hdcp.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index 3c164a27d50b..827cab22f191 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -616,15 +616,17 @@ int intel_hdcp_enable(struct intel_connector *connector)
 
 int intel_hdcp_disable(struct intel_connector *connector)
 {
-   int ret;
+   int ret = 0;
 
if (!connector->hdcp_shim)
return -ENOENT;
 
mutex_lock(&connector->hdcp_mutex);
 
-   connector->hdcp_value = DRM_MODE_CONTENT_PROTECTION_UNDESIRED;
-   ret = _intel_hdcp_disable(connector);
+   if (connector->hdcp_value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
+   connector->hdcp_value = DRM_MODE_CONTENT_PROTECTION_UNDESIRED;
+   ret = _intel_hdcp_disable(connector);
+   }
 
mutex_unlock(&connector->hdcp_mutex);
cancel_delayed_work_sync(&connector->hdcp_check_work);
-- 
2.15.1.620.gb9897f4670-goog

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

Re: [PATCH] drm/atomic: Fix memleak on ERESTARTSYS during non-blocking commits

[Alex Deucher]

On Mon, Jan 8, 2018 at 4:30 PM, Harry Wentland  wrote:
> On 2018-01-04 02:47 PM, sunpeng...@amd.com wrote:
>> From: "Leo (Sunpeng) Li" 
>>
>> During a non-blocking commit, it is possible to return before the
>> commit_tail work is queued (-ERESTARTSYS, for example).
>>
>> Since a reference on the crtc commit object is obtained for the pending
>> vblank event when preparing the commit, the above situation will leave
>> us with an extra reference.
>>
>> Therefore, if the commit_tail worker has not consumed the event at the
>> end of a commit, release it's reference.
>>
>> Signed-off-by: Leo (Sunpeng) Li 
>
> No expert on this but looks sane to me.
>
> Acked-by: Harry Wentland 


Pushed to drm-misc-next.

Thanks,

Alex

>
> Harry
>
>> ---
>>  drivers/gpu/drm/drm_atomic_helper.c | 9 +
>>  1 file changed, 9 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
>> b/drivers/gpu/drm/drm_atomic_helper.c
>> index ab40321..4253f57 100644
>> --- a/drivers/gpu/drm/drm_atomic_helper.c
>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
>> @@ -3421,6 +3421,15 @@ EXPORT_SYMBOL(drm_atomic_helper_crtc_duplicate_state);
>>  void __drm_atomic_helper_crtc_destroy_state(struct drm_crtc_state *state)
>>  {
>>   if (state->commit) {
>> + /*
>> +  * In the event that a non-blocking commit returns
>> +  * -ERESTARTSYS before the commit_tail work is queued, we will
>> +  * have an extra reference to the commit object. Release it, if
>> +  * the event has not been consumed by the worker.
>> +  */
>> + if (state->event)
>> + drm_crtc_commit_put(state->commit);
>> +
>>   kfree(state->commit->event);
>>   state->commit->event = NULL;
>>   drm_crtc_commit_put(state->commit);
>>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/3] drm: export gem dmabuf_ops for drivers to reuse

[Alex Deucher]

On Tue, Jan 9, 2018 at 10:56 AM, Deucher, Alexander
 wrote:
> I'll can push this and a few other misc patches today.
>

Pushed to drm-misc-next.

Thanks,

Alex


>
> Alex
> 
> From: amd-gfx  on behalf of Li,
> Samuel 
> Sent: Tuesday, January 9, 2018 10:20 AM
> To: Daniel Vetter; Koenig, Christian
> Cc: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Subject: RE: [PATCH 2/3] drm: export gem dmabuf_ops for drivers to reuse
>
> Yes, please hush this for me.
>
> Regards,
> Samuel Li
>
>
>> -Original Message-
>> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
>> Vetter
>> Sent: Tuesday, January 09, 2018 4:22 AM
>> To: Koenig, Christian 
>> Cc: Li, Samuel ; dri-devel@lists.freedesktop.org; amd-
>> g...@lists.freedesktop.org
>> Subject: Re: [PATCH 2/3] drm: export gem dmabuf_ops for drivers to reuse
>>
>> On Fri, Jan 05, 2018 at 10:16:04AM +0100, Christian König wrote:
>> > Am 04.01.2018 um 22:12 schrieb Samuel Li:
>> > > Change-Id: I03c22a890d2305f3243d88019d1a28bddd4ddda7
>> > > Signed-off-by: Samuel Li 
>> >
>> > Reviewed-by: Christian König 
>>
>> Want to push to drm-misc or some other plan with this?
>> -Daniel
>>
>> >
>> > > ---
>> > >   drivers/gpu/drm/drm_prime.c | 53 ++---
>> 
>> > >   include/drm/drm_prime.h | 22 +++
>> > >   2 files changed, 53 insertions(+), 22 deletions(-)
>> > >
>> > > diff --git a/drivers/gpu/drm/drm_prime.c
>> > > b/drivers/gpu/drm/drm_prime.c index 8de93a2..68a69e9 100644
>> > > --- a/drivers/gpu/drm/drm_prime.c
>> > > +++ b/drivers/gpu/drm/drm_prime.c
>> > > @@ -180,9 +180,8 @@ static int drm_prime_lookup_buf_handle(struct
>> drm_prime_file_private *prime_fpri
>> > >return -ENOENT;
>> > >   }
>> > > -static int drm_gem_map_attach(struct dma_buf *dma_buf,
>> > > -   struct device *target_dev,
>> > > -   struct dma_buf_attachment *attach)
>> > > +int drm_gem_map_attach(struct dma_buf *dma_buf, struct device
>> *target_dev,
>> > > +struct dma_buf_attachment *attach)
>> > >   {
>> > >struct drm_prime_attachment *prime_attach;
>> > >struct drm_gem_object *obj = dma_buf->priv; @@ -200,9 +199,10
>> @@
>> > > static int drm_gem_map_attach(struct dma_buf *dma_buf,
>> > >return dev->driver->gem_prime_pin(obj);
>> > >   }
>> > > +EXPORT_SYMBOL(drm_gem_map_attach);
>> > > -static void drm_gem_map_detach(struct dma_buf *dma_buf,
>> > > -struct dma_buf_attachment *attach)
>> > > +void drm_gem_map_detach(struct dma_buf *dma_buf,
>> > > + struct dma_buf_attachment *attach)
>> > >   {
>> > >struct drm_prime_attachment *prime_attach = attach->priv;
>> > >struct drm_gem_object *obj = dma_buf->priv; @@ -227,6 +227,7
>> @@
>> > > static void drm_gem_map_detach(struct dma_buf *dma_buf,
>> > >kfree(prime_attach);
>> > >attach->priv = NULL;
>> > >   }
>> > > +EXPORT_SYMBOL(drm_gem_map_detach);
>> > >   void drm_prime_remove_buf_handle_locked(struct
>> drm_prime_file_private *prime_fpriv,
>> > >struct dma_buf *dma_buf)
>> > > @@ -253,8 +254,8 @@ void
>> drm_prime_remove_buf_handle_locked(struct drm_prime_file_private
>> *prime_fpr
>> > >}
>> > >   }
>> > > -static struct sg_table *drm_gem_map_dma_buf(struct
>> dma_buf_attachment *attach,
>> > > - enum dma_data_direction dir)
>> > > +struct sg_table *drm_gem_map_dma_buf(struct dma_buf_attachment
>> *attach,
>> > > +  enum dma_data_direction dir)
>> > >   {
>> > >struct drm_prime_attachment *prime_attach = attach->priv;
>> > >struct drm_gem_object *obj = attach->dmabuf->priv; @@ -289,13
>> > > +290,15 @@ static struct sg_table *drm_gem_map_dma_buf(struct
>> dma_buf_attachment *attach,
>> > >return sgt;
>> > >   }
>> > > +EXPORT_SYMBOL(drm_gem_map_dma_buf);
>> > > -static void drm_gem_unmap_dma_buf(struct dma_buf_attachment
>> *attach,
>> > > -   struct sg_table *sgt,
>> > > -   enum dma_data_direction dir)
>> > > +void drm_gem_unmap_dma_buf(struct dma_buf_attachment *attach,
>> > > +struct sg_table *sgt,
>> > > +enum dma_data_direction dir)
>> > >   {
>> > >/* nothing to be done here */
>> > >   }
>> > > +EXPORT_SYMBOL(drm_gem_unmap_dma_buf);
>> > >   /**
>> > >* drm_gem_dmabuf_export - dma_buf export implementation for
>> GEM
>> > > @@ -346,47 +349,52 @@ void drm_gem_dmabuf_release(struct
>> dma_buf *dma_buf)
>> > >   }
>> > >   EXPORT_SYMBOL(drm_gem_dmabuf_release);
>> > > -static void *drm_gem_dmabuf_vmap(struct dma_buf *dma_buf)
>> > > +void *drm_gem_dmabuf_vmap(struct dma_buf *dma_buf)
>> > >   {
>> > >struct drm_gem_object *obj = dma_buf->priv;
>> > >struct drm_device *dev = obj->dev;
>> > >return dev->driver->gem_prime_vmap(obj);
>> > >   }
>> > > +EXPORT_SYMBOL(d

Re: [PATCH 05/19] drm/vc4: Use the alpha format helper

[Eric Anholt]

Maxime Ripard  writes:

> Now that the core has a drm format helper to tell if a format embeds an
> alpha component in it, let's use it.
>
> Cc: Eric Anholt 
> Signed-off-by: Maxime Ripard 

Reviewed-by: Eric Anholt 


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

Re: [PATCH 2/3] drm: export gem dmabuf_ops for drivers to reuse

[Deucher, Alexander]

I'll can push this and a few other misc patches today.

Alex

From: amd-gfx  on behalf of Li, Samuel 

Sent: Tuesday, January 9, 2018 10:20 AM
To: Daniel Vetter; Koenig, Christian
Cc: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
Subject: RE: [PATCH 2/3] drm: export gem dmabuf_ops for drivers to reuse

Yes, please hush this for me.

Regards,
Samuel Li


> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Tuesday, January 09, 2018 4:22 AM
> To: Koenig, Christian 
> Cc: Li, Samuel ; dri-devel@lists.freedesktop.org; amd-
> g...@lists.freedesktop.org
> Subject: Re: [PATCH 2/3] drm: export gem dmabuf_ops for drivers to reuse
>
> On Fri, Jan 05, 2018 at 10:16:04AM +0100, Christian König wrote:
> > Am 04.01.2018 um 22:12 schrieb Samuel Li:
> > > Change-Id: I03c22a890d2305f3243d88019d1a28bddd4ddda7
> > > Signed-off-by: Samuel Li 
> >
> > Reviewed-by: Christian König 
>
> Want to push to drm-misc or some other plan with this?
> -Daniel
>
> >
> > > ---
> > >   drivers/gpu/drm/drm_prime.c | 53 ++---
> 
> > >   include/drm/drm_prime.h | 22 +++
> > >   2 files changed, 53 insertions(+), 22 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_prime.c
> > > b/drivers/gpu/drm/drm_prime.c index 8de93a2..68a69e9 100644
> > > --- a/drivers/gpu/drm/drm_prime.c
> > > +++ b/drivers/gpu/drm/drm_prime.c
> > > @@ -180,9 +180,8 @@ static int drm_prime_lookup_buf_handle(struct
> drm_prime_file_private *prime_fpri
> > >return -ENOENT;
> > >   }
> > > -static int drm_gem_map_attach(struct dma_buf *dma_buf,
> > > -   struct device *target_dev,
> > > -   struct dma_buf_attachment *attach)
> > > +int drm_gem_map_attach(struct dma_buf *dma_buf, struct device
> *target_dev,
> > > +struct dma_buf_attachment *attach)
> > >   {
> > >struct drm_prime_attachment *prime_attach;
> > >struct drm_gem_object *obj = dma_buf->priv; @@ -200,9 +199,10
> @@
> > > static int drm_gem_map_attach(struct dma_buf *dma_buf,
> > >return dev->driver->gem_prime_pin(obj);
> > >   }
> > > +EXPORT_SYMBOL(drm_gem_map_attach);
> > > -static void drm_gem_map_detach(struct dma_buf *dma_buf,
> > > -struct dma_buf_attachment *attach)
> > > +void drm_gem_map_detach(struct dma_buf *dma_buf,
> > > + struct dma_buf_attachment *attach)
> > >   {
> > >struct drm_prime_attachment *prime_attach = attach->priv;
> > >struct drm_gem_object *obj = dma_buf->priv; @@ -227,6 +227,7
> @@
> > > static void drm_gem_map_detach(struct dma_buf *dma_buf,
> > >kfree(prime_attach);
> > >attach->priv = NULL;
> > >   }
> > > +EXPORT_SYMBOL(drm_gem_map_detach);
> > >   void drm_prime_remove_buf_handle_locked(struct
> drm_prime_file_private *prime_fpriv,
> > >struct dma_buf *dma_buf)
> > > @@ -253,8 +254,8 @@ void
> drm_prime_remove_buf_handle_locked(struct drm_prime_file_private
> *prime_fpr
> > >}
> > >   }
> > > -static struct sg_table *drm_gem_map_dma_buf(struct
> dma_buf_attachment *attach,
> > > - enum dma_data_direction dir)
> > > +struct sg_table *drm_gem_map_dma_buf(struct dma_buf_attachment
> *attach,
> > > +  enum dma_data_direction dir)
> > >   {
> > >struct drm_prime_attachment *prime_attach = attach->priv;
> > >struct drm_gem_object *obj = attach->dmabuf->priv; @@ -289,13
> > > +290,15 @@ static struct sg_table *drm_gem_map_dma_buf(struct
> dma_buf_attachment *attach,
> > >return sgt;
> > >   }
> > > +EXPORT_SYMBOL(drm_gem_map_dma_buf);
> > > -static void drm_gem_unmap_dma_buf(struct dma_buf_attachment
> *attach,
> > > -   struct sg_table *sgt,
> > > -   enum dma_data_direction dir)
> > > +void drm_gem_unmap_dma_buf(struct dma_buf_attachment *attach,
> > > +struct sg_table *sgt,
> > > +enum dma_data_direction dir)
> > >   {
> > >/* nothing to be done here */
> > >   }
> > > +EXPORT_SYMBOL(drm_gem_unmap_dma_buf);
> > >   /**
> > >* drm_gem_dmabuf_export - dma_buf export implementation for
> GEM
> > > @@ -346,47 +349,52 @@ void drm_gem_dmabuf_release(struct
> dma_buf *dma_buf)
> > >   }
> > >   EXPORT_SYMBOL(drm_gem_dmabuf_release);
> > > -static void *drm_gem_dmabuf_vmap(struct dma_buf *dma_buf)
> > > +void *drm_gem_dmabuf_vmap(struct dma_buf *dma_buf)
> > >   {
> > >struct drm_gem_object *obj = dma_buf->priv;
> > >struct drm_device *dev = obj->dev;
> > >return dev->driver->gem_prime_vmap(obj);
> > >   }
> > > +EXPORT_SYMBOL(drm_gem_dmabuf_vmap);
> > > -static void drm_gem_dmabuf_vunmap(struct dma_buf *dma_buf, void
> > > *vaddr)
> > > +void drm_gem_dmabuf_vunmap(struct dma_buf *dma_buf, void
> *vaddr)
> > >   {
> > >struct drm_gem_object *obj = dma_buf->priv;

[PATCH] drm/vmwgfx: Don't cache framebuffer maps

[Thomas Hellstrom]

Buffer objects need to be either pinned or reserved while a map is active,
that's not the case here, so avoid caching the framebuffer map.
This will cause increasing mapping activity mainly when we don't do
page flipping.

This fixes occasional garbage filled screens when the framebuffer has been
evicted after the map.

Since in-kernel mapping of whole buffer objects is error-prone on 32-bit
architectures and also quite inefficient, we will revisit this later.

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Sinclair Yeh 
Cc: 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c  |  6 --
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.h  |  2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 41 +++-
 3 files changed, 13 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 0545740b3724..641294aef165 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -697,7 +697,6 @@ vmw_du_plane_duplicate_state(struct drm_plane *plane)
vps->pinned = 0;
 
/* Mapping is managed by prepare_fb/cleanup_fb */
-   memset(&vps->guest_map, 0, sizeof(vps->guest_map));
memset(&vps->host_map, 0, sizeof(vps->host_map));
vps->cpp = 0;
 
@@ -760,11 +759,6 @@ vmw_du_plane_destroy_state(struct drm_plane *plane,
 
 
/* Should have been freed by cleanup_fb */
-   if (vps->guest_map.virtual) {
-   DRM_ERROR("Guest mapping not freed\n");
-   ttm_bo_kunmap(&vps->guest_map);
-   }
-
if (vps->host_map.virtual) {
DRM_ERROR("Host mapping not freed\n");
ttm_bo_kunmap(&vps->host_map);
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
index ff9c8389ff21..cd9da2dd79af 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
@@ -175,7 +175,7 @@ struct vmw_plane_state {
int pinned;
 
/* For CPU Blit */
-   struct ttm_bo_kmap_obj host_map, guest_map;
+   struct ttm_bo_kmap_obj host_map;
unsigned int cpp;
 };
 
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
index 90b5437fd787..b68d74888ab1 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
@@ -114,7 +114,7 @@ struct vmw_screen_target_display_unit {
bool defined;
 
/* For CPU Blit */
-   struct ttm_bo_kmap_obj host_map, guest_map;
+   struct ttm_bo_kmap_obj host_map;
unsigned int cpp;
 };
 
@@ -695,7 +695,8 @@ static void vmw_stdu_dmabuf_cpu_commit(struct vmw_kms_dirty 
*dirty)
s32 src_pitch, dst_pitch;
u8 *src, *dst;
bool not_used;
-
+   struct ttm_bo_kmap_obj guest_map;
+   int ret;
 
if (!dirty->num_hits)
return;
@@ -706,6 +707,13 @@ static void vmw_stdu_dmabuf_cpu_commit(struct 
vmw_kms_dirty *dirty)
if (width == 0 || height == 0)
return;
 
+   ret = ttm_bo_kmap(&ddirty->buf->base, 0, ddirty->buf->base.num_pages,
+ &guest_map);
+   if (ret) {
+   DRM_ERROR("Failed mapping framebuffer for blit: %d\n",
+ ret);
+   goto out_cleanup;
+   }
 
/* Assume we are blitting from Host (display_srf) to Guest (dmabuf) */
src_pitch = stdu->display_srf->base_size.width * stdu->cpp;
@@ -713,7 +721,7 @@ static void vmw_stdu_dmabuf_cpu_commit(struct vmw_kms_dirty 
*dirty)
src += ddirty->top * src_pitch + ddirty->left * stdu->cpp;
 
dst_pitch = ddirty->pitch;
-   dst = ttm_kmap_obj_virtual(&stdu->guest_map, ¬_used);
+   dst = ttm_kmap_obj_virtual(&guest_map, ¬_used);
dst += ddirty->fb_top * dst_pitch + ddirty->fb_left * stdu->cpp;
 
 
@@ -772,6 +780,7 @@ static void vmw_stdu_dmabuf_cpu_commit(struct vmw_kms_dirty 
*dirty)
vmw_fifo_commit(dev_priv, sizeof(*cmd));
}
 
+   ttm_bo_kunmap(&guest_map);
 out_cleanup:
ddirty->left = ddirty->top = ddirty->fb_left = ddirty->fb_top = S32_MAX;
ddirty->right = ddirty->bottom = S32_MIN;
@@ -1109,9 +1118,6 @@ vmw_stdu_primary_plane_cleanup_fb(struct drm_plane *plane,
 {
struct vmw_plane_state *vps = vmw_plane_state_to_vps(old_state);
 
-   if (vps->guest_map.virtual)
-   ttm_bo_kunmap(&vps->guest_map);
-
if (vps->host_map.virtual)
ttm_bo_kunmap(&vps->host_map);
 
@@ -1277,33 +1283,11 @@ vmw_stdu_primary_plane_prepare_fb(struct drm_plane 
*plane,
 */
if (vps->content_fb_type == SEPARATE_DMA &&
!(dev_priv->capabilities & SVGA_CAP_3D)) {
-
-   struct vmw_framebuffer_dmabuf *new_vfbd;
-
-   new_vfbd = vmw_framebuffer_to_vfbd(new_fb);
-
-   ret = ttm_bo_reserve(&new_vfbd->buffer->base, false, false,
-NULL);
-   if (ret)
-  

Re: How to map depth=30 fb to XBGR instead of XRGB?

[Daniel Vetter]

On Tue, Jan 09, 2018 at 03:28:23PM +, Chris Wilson wrote:
> Quoting Ville Syrjälä (2018-01-09 15:19:06)
> > On Sun, Dec 31, 2017 at 01:03:39AM -0500, Ilia Mirkin wrote:
> > > NVIDIA hardware, prior to Kepler, only supports XBGR2101010. However
> > > drmAddFB with depth = 30 will use the mapping in
> > > drm_mode_legacy_fb_format and pick the XRGB version of the format.
> > > 
> > > One solution is to tell userspace "stop using addfb, move to addfb2".
> > > However I'm hoping that there's some sort of semi-clean way of dealing
> > > with such driver eccentricities without resorting to changing
> > > userspace.
> > > 
> > > Can the ioctl be handled in the driver perhaps? Or would it be
> > > reasonable to add a callback in drm_driver?
> > 
> > I don't think there's any sane way to allow the driver to remap these.
> > How would generic userspace know which component order the driver
> > actually picked?
> 
> With getfb? Wait, I'll get my coat.

debugfs would dump the actual pixel format, at least in 4.16 :-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: How to map depth=30 fb to XBGR instead of XRGB?

[Daniel Vetter]

On Tue, Jan 09, 2018 at 05:19:06PM +0200, Ville Syrjälä wrote:
> On Sun, Dec 31, 2017 at 01:03:39AM -0500, Ilia Mirkin wrote:
> > NVIDIA hardware, prior to Kepler, only supports XBGR2101010. However
> > drmAddFB with depth = 30 will use the mapping in
> > drm_mode_legacy_fb_format and pick the XRGB version of the format.
> > 
> > One solution is to tell userspace "stop using addfb, move to addfb2".
> > However I'm hoping that there's some sort of semi-clean way of dealing
> > with such driver eccentricities without resorting to changing
> > userspace.
> > 
> > Can the ioctl be handled in the driver perhaps? Or would it be
> > reasonable to add a callback in drm_driver?
> 
> I don't think there's any sane way to allow the driver to remap these.
> How would generic userspace know which component order the driver
> actually picked?

By using addfb2. That seems the only option, and it'll likely result in a
bunch more "nouveau is crap" forum posts when people try to use 30bpp
with generic userspace on nouveau. Best we can do is drop a info_once
message into dmesg that userspace should consider using addfb2.

Ilia said he's ok with more "nouveau is crap", and that's about the only
option we have any.

Wrt implementation: A flag in drm_mode_config that overwrites the choice
in drm_addfb_ioctl (so that we can avoid going through all the drivers),
plus the same hack in the fbdev probe callback in nouveau is probably the
least invasive. Core one with a very huge comment ofc.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 04/11] drm/bridge/synopsys: dw-hdmi: Export some PHY related functions

[Laurent Pinchart]

Hello,

On Tuesday, 9 January 2018 17:58:46 EET Jernej Škrabec wrote:
> Dne torek, 09. januar 2018 ob 11:43:08 CET je Archit Taneja napisal(a):
> > On 12/31/2017 02:31 AM, Jernej Skrabec wrote:
> >> Parts of PHY code could be useful also for custom PHYs. For example,
> >> Allwinner A83T has custom PHY which is probably Synopsys gen2 PHY
> >> with few additional memory mapped registers, so most of the Synopsys PHY
> >> related code could be reused.
> >> 
> >> It turns out that even completely custom HDMI PHYs, such as the one
> >> found in Allwinner H3, can reuse some of those functions. This would
> >> suggest that (some?) functions exported in this commit are actually part
> >> of generic PHY interface and not really specific to Synopsys PHYs.
> >> 
> >> Export useful PHY functions.
> >> 
> >> Signed-off-by: Jernej Skrabec 
> >> ---
> >> 
> >> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 45 +---
> >> drivers/gpu/drm/bridge/synopsys/dw-hdmi.h |  2 ++
> >> include/drm/bridge/dw_hdmi.h  | 10 +++
> >> 3 files changed, 44 insertions(+), 13 deletions(-)
> >> 
> >> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> >> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index
> >> 7ca14d7325b5..67467d0b683a 100644
> >> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> >> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c

[snip]

> >> @@ -1065,6 +1067,23 @@ static void
> >> dw_hdmi_phy_sel_interface_control(struct dw_hdmi *hdmi, u8 enable)
> >> HDMI_PHY_CONF0_SELDIPIF_MASK);
> >>   }
> >> 
> >> +void dw_hdmi_phy_gen2_reset(struct dw_hdmi *hdmi, u8 enable)
> >> +{
> >> +  hdmi_mask_writeb(hdmi, enable, HDMI_MC_PHYRSTZ,
> >> +   HDMI_MC_PHYRSTZ_PHYRSTZ_OFFSET,
> >> +   HDMI_MC_PHYRSTZ_PHYRSTZ_MASK);
> >> +}
> >> +EXPORT_SYMBOL_GPL(dw_hdmi_phy_gen2_reset);

I don't remember the details, is the reset signal Gen2-specific ?

How about asserting and deasserting the reset signal in the same call instead 
of having to call this function twice ?

> >> +void dw_hdmi_phy_set_slave_addr(struct dw_hdmi *hdmi)
> >> +{
> >> +  hdmi_phy_test_clear(hdmi, 1);
> >> +  hdmi_writeb(hdmi, HDMI_PHY_I2CM_SLAVE_ADDR_PHY_GEN2,
> >> +  HDMI_PHY_I2CM_SLAVE_ADDR);
> >> +  hdmi_phy_test_clear(hdmi, 0);
> >> +}
> >> +EXPORT_SYMBOL_GPL(dw_hdmi_phy_set_slave_addr);
> > 
> > Should this be called dw_hdmi_phy_gen2_set_slave_addr?
> 
> Probably. I will rename it in v2 to be consistent with other phy functions.

The I2C write function is called dw_hdmi_phy_i2c_write(). If we want to be 
conosistent we should either rename this one to dw_hdmi_phy_i2c_set_addr() or 
rename them both to dw_hdmi_phy_gen2_i2c_write() and 
dw_hdmi_phy_gen2_i2c_set_addr(). I think I'd prefer the former, and we could 
even drop gen2 from dw_hdmi_phy_gen2_pddq() and dw_hdmi_phy_gen2_txpwron() if 
desired.

> > Looks good otherwise. Same for patches 3 and 4 in this series.
> > 
> >> +
> >>   static void dw_hdmi_phy_power_off(struct dw_hdmi *hdmi)
> >>   {
> >>const struct dw_hdmi_phy_data *phy = hdmi->phy.data;

[snip]

-- 
Regards,

Laurent Pinchart

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

RE: [PATCH 2/3] drm: export gem dmabuf_ops for drivers to reuse

[Li, Samuel]

Yes, please hush this for me.

Regards,
Samuel Li


> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Tuesday, January 09, 2018 4:22 AM
> To: Koenig, Christian 
> Cc: Li, Samuel ; dri-devel@lists.freedesktop.org; amd-
> g...@lists.freedesktop.org
> Subject: Re: [PATCH 2/3] drm: export gem dmabuf_ops for drivers to reuse
> 
> On Fri, Jan 05, 2018 at 10:16:04AM +0100, Christian König wrote:
> > Am 04.01.2018 um 22:12 schrieb Samuel Li:
> > > Change-Id: I03c22a890d2305f3243d88019d1a28bddd4ddda7
> > > Signed-off-by: Samuel Li 
> >
> > Reviewed-by: Christian König 
> 
> Want to push to drm-misc or some other plan with this?
> -Daniel
> 
> >
> > > ---
> > >   drivers/gpu/drm/drm_prime.c | 53 ++---
> 
> > >   include/drm/drm_prime.h | 22 +++
> > >   2 files changed, 53 insertions(+), 22 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_prime.c
> > > b/drivers/gpu/drm/drm_prime.c index 8de93a2..68a69e9 100644
> > > --- a/drivers/gpu/drm/drm_prime.c
> > > +++ b/drivers/gpu/drm/drm_prime.c
> > > @@ -180,9 +180,8 @@ static int drm_prime_lookup_buf_handle(struct
> drm_prime_file_private *prime_fpri
> > >   return -ENOENT;
> > >   }
> > > -static int drm_gem_map_attach(struct dma_buf *dma_buf,
> > > -   struct device *target_dev,
> > > -   struct dma_buf_attachment *attach)
> > > +int drm_gem_map_attach(struct dma_buf *dma_buf, struct device
> *target_dev,
> > > +struct dma_buf_attachment *attach)
> > >   {
> > >   struct drm_prime_attachment *prime_attach;
> > >   struct drm_gem_object *obj = dma_buf->priv; @@ -200,9 +199,10
> @@
> > > static int drm_gem_map_attach(struct dma_buf *dma_buf,
> > >   return dev->driver->gem_prime_pin(obj);
> > >   }
> > > +EXPORT_SYMBOL(drm_gem_map_attach);
> > > -static void drm_gem_map_detach(struct dma_buf *dma_buf,
> > > -struct dma_buf_attachment *attach)
> > > +void drm_gem_map_detach(struct dma_buf *dma_buf,
> > > + struct dma_buf_attachment *attach)
> > >   {
> > >   struct drm_prime_attachment *prime_attach = attach->priv;
> > >   struct drm_gem_object *obj = dma_buf->priv; @@ -227,6 +227,7
> @@
> > > static void drm_gem_map_detach(struct dma_buf *dma_buf,
> > >   kfree(prime_attach);
> > >   attach->priv = NULL;
> > >   }
> > > +EXPORT_SYMBOL(drm_gem_map_detach);
> > >   void drm_prime_remove_buf_handle_locked(struct
> drm_prime_file_private *prime_fpriv,
> > >   struct dma_buf *dma_buf)
> > > @@ -253,8 +254,8 @@ void
> drm_prime_remove_buf_handle_locked(struct drm_prime_file_private
> *prime_fpr
> > >   }
> > >   }
> > > -static struct sg_table *drm_gem_map_dma_buf(struct
> dma_buf_attachment *attach,
> > > - enum dma_data_direction dir)
> > > +struct sg_table *drm_gem_map_dma_buf(struct dma_buf_attachment
> *attach,
> > > +  enum dma_data_direction dir)
> > >   {
> > >   struct drm_prime_attachment *prime_attach = attach->priv;
> > >   struct drm_gem_object *obj = attach->dmabuf->priv; @@ -289,13
> > > +290,15 @@ static struct sg_table *drm_gem_map_dma_buf(struct
> dma_buf_attachment *attach,
> > >   return sgt;
> > >   }
> > > +EXPORT_SYMBOL(drm_gem_map_dma_buf);
> > > -static void drm_gem_unmap_dma_buf(struct dma_buf_attachment
> *attach,
> > > -   struct sg_table *sgt,
> > > -   enum dma_data_direction dir)
> > > +void drm_gem_unmap_dma_buf(struct dma_buf_attachment *attach,
> > > +struct sg_table *sgt,
> > > +enum dma_data_direction dir)
> > >   {
> > >   /* nothing to be done here */
> > >   }
> > > +EXPORT_SYMBOL(drm_gem_unmap_dma_buf);
> > >   /**
> > >* drm_gem_dmabuf_export - dma_buf export implementation for
> GEM
> > > @@ -346,47 +349,52 @@ void drm_gem_dmabuf_release(struct
> dma_buf *dma_buf)
> > >   }
> > >   EXPORT_SYMBOL(drm_gem_dmabuf_release);
> > > -static void *drm_gem_dmabuf_vmap(struct dma_buf *dma_buf)
> > > +void *drm_gem_dmabuf_vmap(struct dma_buf *dma_buf)
> > >   {
> > >   struct drm_gem_object *obj = dma_buf->priv;
> > >   struct drm_device *dev = obj->dev;
> > >   return dev->driver->gem_prime_vmap(obj);
> > >   }
> > > +EXPORT_SYMBOL(drm_gem_dmabuf_vmap);
> > > -static void drm_gem_dmabuf_vunmap(struct dma_buf *dma_buf, void
> > > *vaddr)
> > > +void drm_gem_dmabuf_vunmap(struct dma_buf *dma_buf, void
> *vaddr)
> > >   {
> > >   struct drm_gem_object *obj = dma_buf->priv;
> > >   struct drm_device *dev = obj->dev;
> > >   dev->driver->gem_prime_vunmap(obj, vaddr);
> > >   }
> > > +EXPORT_SYMBOL(drm_gem_dmabuf_vunmap);
> > > -static void *drm_gem_dmabuf_kmap_atomic(struct dma_

Re: [-next PATCH 3/4] treewide: Use DEVICE_ATTR_RO

[Greg Kroah-Hartman]

On Thu, Dec 21, 2017 at 11:34:10AM +0200, Sakari Ailus wrote:
> Hi Joe,
> 
> On Tue, Dec 19, 2017 at 10:15:08AM -0800, Joe Perches wrote:
> > diff --git a/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c 
> > b/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c
> > index a1c81c12718c..4338b8a1309f 100644
> > --- a/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c
> > +++ b/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c
> > @@ -158,10 +158,10 @@ static ssize_t dynamic_pool_show(struct device *dev,
> > return ret;
> >  };
> >  
> > -static DEVICE_ATTR(active_bo, 0444, active_bo_show, NULL);
> > -static DEVICE_ATTR(free_bo, 0444, free_bo_show, NULL);
> > -static DEVICE_ATTR(reserved_pool, 0444, reserved_pool_show, NULL);
> > -static DEVICE_ATTR(dynamic_pool, 0444, dynamic_pool_show, NULL);
> > +static DEVICE_ATTR_RO(active_bo);
> > +static DEVICE_ATTR_RO(free_bo);
> > +static DEVICE_ATTR_RO(reserved_pool);
> > +static DEVICE_ATTR_RO(dynamic_pool);
> >  
> >  static struct attribute *sysfs_attrs_ctrl[] = {
> > &dev_attr_active_bo.attr,
> 
> I have the exact same changes queued up in my tree. As there seem to be no
> dependencies to other patches in your set, how about dropping this chunk?

I've now dropped it, thanks.

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

[Bug 104216] Firefox quirks (black and/or white squares)

[bugzilla-daemon]

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

--- Comment #8 from Germano Massullo  ---
(In reply to Marek Olšák from comment #6)
> Have you tested the patch you linked?

I applied the patch into a personal Fedora Copr repo
https://copr.fedorainfracloud.org/coprs/germano/xorg_sRGB_patch_test/
and updated the affected system, but unfortunately the patch has no effect on
this bug I am experiencing

-- 
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 03/11] drm/bridge/synopsys: dw-hdmi: Enable workaround for v1.32a

[Neil Armstrong]

Hi,

I think this question is for Jose.

On 09/01/2018 13:56, Laurent Pinchart wrote:
> Hi Jernej,
> 
> Thank you for the patch.
> 
> On Saturday, 30 December 2017 23:01:55 EET Jernej Skrabec wrote:
>> Allwinner SoCs have dw hdmi controller v1.32a which exhibits same
>> magenta line issue as i.MX6Q and i.MX6DL. Enable workaround for it.

We observe the same issue on Amlogic SoCs with the dw hdmi controller v2.01a.

Rockchip seems to also use count=1 for 0x200a, 0x201a and 0x211a in
https://github.com/rockchip-linux/kernel/commit/cafa8ebd5f4df41425d6f2f61633d5bc64f20e65

Changelog is :
The issue can be worked around by issuing a TMDS software reset and
then write one of the FC registers several times. After tested, the
number of iterations of RK3399/RK3328(v2.11a), RK3368(v2.01a),
RK3288(v2.00a) is one.

Can you confirm it is necessary ?

Neil

>>
>> Tests show that one iteration is enough.
>>
>> Signed-off-by: Jernej Skrabec 
> 
> This does not break R-Car DU, so
> 
> Acked-by: Laurent Pinchart 
> 
>> ---
>>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 8 +---
>>  1 file changed, 5 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index
>> a38db40ce990..7ca14d7325b5 100644
>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> @@ -1634,9 +1634,10 @@ static void dw_hdmi_clear_overflow(struct dw_hdmi
>> *hdmi) * then write one of the FC registers several times.
>>   *
>>   * The number of iterations matters and depends on the HDMI TX revision
>> - * (and possibly on the platform). So far only i.MX6Q (v1.30a) and
>> - * i.MX6DL (v1.31a) have been identified as needing the workaround, with
>> - * 4 and 1 iterations respectively.
>> + * (and possibly on the platform). So far i.MX6Q (v1.30a), i.MX6DL
>> + * (v1.31a) and multiple Allwinner SoCs (v1.32a) have been identified
>> + * as needing the workaround, with 4 iterations for v1.30a and 1
>> + * iteration for others.
>>   */
>>
>>  switch (hdmi->version) {
>> @@ -1644,6 +1645,7 @@ static void dw_hdmi_clear_overflow(struct dw_hdmi
>> *hdmi) count = 4;
>>  break;
>>  case 0x131a:
>> +case 0x132a:
>>  count = 1;
>>  break;
>>  default:
> 

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

Re: How to map depth=30 fb to XBGR instead of XRGB?

[Chris Wilson]

Quoting Ville Syrjälä (2018-01-09 15:19:06)
> On Sun, Dec 31, 2017 at 01:03:39AM -0500, Ilia Mirkin wrote:
> > NVIDIA hardware, prior to Kepler, only supports XBGR2101010. However
> > drmAddFB with depth = 30 will use the mapping in
> > drm_mode_legacy_fb_format and pick the XRGB version of the format.
> > 
> > One solution is to tell userspace "stop using addfb, move to addfb2".
> > However I'm hoping that there's some sort of semi-clean way of dealing
> > with such driver eccentricities without resorting to changing
> > userspace.
> > 
> > Can the ioctl be handled in the driver perhaps? Or would it be
> > reasonable to add a callback in drm_driver?
> 
> I don't think there's any sane way to allow the driver to remap these.
> How would generic userspace know which component order the driver
> actually picked?

With getfb? Wait, I'll get my coat.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: How to map depth=30 fb to XBGR instead of XRGB?

[Ville Syrjälä]

On Sun, Dec 31, 2017 at 01:03:39AM -0500, Ilia Mirkin wrote:
> NVIDIA hardware, prior to Kepler, only supports XBGR2101010. However
> drmAddFB with depth = 30 will use the mapping in
> drm_mode_legacy_fb_format and pick the XRGB version of the format.
> 
> One solution is to tell userspace "stop using addfb, move to addfb2".
> However I'm hoping that there's some sort of semi-clean way of dealing
> with such driver eccentricities without resorting to changing
> userspace.
> 
> Can the ioctl be handled in the driver perhaps? Or would it be
> reasonable to add a callback in drm_driver?

I don't think there's any sane way to allow the driver to remap these.
How would generic userspace know which component order the driver
actually picked?

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

[Bug 104556] WARNING: CPU: 1 PID: 7288 at mm/slab_common.c:971 kmalloc_slab+0x5e/0x70

[bugzilla-daemon]

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

--- Comment #5 from Paul Menzel  ---
(In reply to Christian König from comment #3)
> Please add your dmesg as attachment and not as inline comment.

Sorry, I’ll do so next time.

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

Re: [PATCH v2 4/6] drm/tinydrm/mipi-dbi: Add poweron-reset functions

[Noralf Trønnes]

Den 09.01.2018 02.38, skrev David Lechner:

On 01/07/2018 11:44 AM, Noralf Trønnes wrote:

Split out common poweron-reset functionality.

Signed-off-by: Noralf Trønnes 
---
  drivers/gpu/drm/tinydrm/mi0283qt.c | 20 ++--
  drivers/gpu/drm/tinydrm/mipi-dbi.c | 63 
++

  drivers/gpu/drm/tinydrm/st7586.c   |  9 ++
  drivers/gpu/drm/tinydrm/st7735r.c  |  8 ++---
  include/drm/tinydrm/mipi-dbi.h |  2 ++
  5 files changed, 73 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/tinydrm/mi0283qt.c 
b/drivers/gpu/drm/tinydrm/mi0283qt.c

index c69a4d958f24..2a78bcd35045 100644
--- a/drivers/gpu/drm/tinydrm/mi0283qt.c
+++ b/drivers/gpu/drm/tinydrm/mi0283qt.c
@@ -49,31 +49,17 @@
    static int mi0283qt_init(struct mipi_dbi *mipi)
  {
-    struct tinydrm_device *tdev = &mipi->tinydrm;
-    struct device *dev = tdev->drm->dev;
  u8 addr_mode;
  int ret;
    DRM_DEBUG_KMS("\n");
  -    ret = regulator_enable(mipi->regulator);
-    if (ret) {
-    DRM_DEV_ERROR(dev, "Failed to enable regulator %d\n", ret);
+    ret = mipi_dbi_poweron_conditional_reset(mipi);
+    if (ret < 0)
  return ret;
-    }
-
-    /* Avoid flicker by skipping setup if the bootloader has done it */
-    if (mipi_dbi_display_is_on(mipi))
+    if (ret > 0)
  return 0;


If I am reading the patch right, it looks like there are two

if (ret > 0)
   return 0;

in a row with nothing in between when this is applied.


  -    mipi_dbi_hw_reset(mipi);
-    ret = mipi_dbi_command(mipi, MIPI_DCS_SOFT_RESET);
-    if (ret) {
-    DRM_DEV_ERROR(dev, "Error sending command %d\n", ret);
-    regulator_disable(mipi->regulator);
-    return ret;
-    }
-
  msleep(20);
    mipi_dbi_command(mipi, MIPI_DCS_SET_DISPLAY_OFF);
diff --git a/drivers/gpu/drm/tinydrm/mipi-dbi.c 
b/drivers/gpu/drm/tinydrm/mipi-dbi.c

index ecc5c81a93ac..eea6803ff223 100644
--- a/drivers/gpu/drm/tinydrm/mipi-dbi.c
+++ b/drivers/gpu/drm/tinydrm/mipi-dbi.c
@@ -463,6 +463,7 @@ bool mipi_dbi_display_is_on(struct mipi_dbi *mipi)
    val &= ~DCS_POWER_MODE_RESERVED_MASK;
  +    /* The poweron/reset value is 08h 
DCS_POWER_MODE_DISPLAY_NORMAL_MODE */

  if (val != (DCS_POWER_MODE_DISPLAY |
  DCS_POWER_MODE_DISPLAY_NORMAL_MODE | 
DCS_POWER_MODE_SLEEP_MODE))

  return false;
@@ -473,6 +474,68 @@ bool mipi_dbi_display_is_on(struct mipi_dbi *mipi)
  }
  EXPORT_SYMBOL(mipi_dbi_display_is_on);
  +static int mipi_dbi_por_conditional(struct mipi_dbi *mipi, bool cond)


I know it is long, but it would be nice to spell out poweron_reset here
instead of "por".


+{
+    struct device *dev = mipi->tinydrm.drm->dev;
+    int ret;
+
+    if (mipi->regulator) {
+    ret = regulator_enable(mipi->regulator);
+    if (ret) {
+    DRM_DEV_ERROR(dev, "Failed to enable regulator (%d)\n", 
ret);

+    return ret;
+    }
+    }
+
+    if (cond && mipi_dbi_display_is_on(mipi))
+    return 1;
+
+    mipi_dbi_hw_reset(mipi);
+    ret = mipi_dbi_command(mipi, MIPI_DCS_SOFT_RESET);


It seems unnecessary to do a soft reset after a hard reset, but I 
suppose some displays

don't have a hard reset and the extra soft reset shouldn't hurt anything.



Both ILI9341 and ST7735R (not ST7586S) lists soft reset as part of the
Power Flow Chart, but it's not explicit about it being required or not:

Power on sequence
HW reset
SW reset
State is now Sleep in

I looked in the MIPI DBI spec and there's nothing about requiring both
hw _and_ soft reset. But I have seen hard and soft reset in many panel
init's, so I think we keep this as the default. It has a 5ms penalty.
I could shave that off in mipi_dbi_hw_reset(). It keeps reset low for
20ms, but the spec says it just has to be longer than 9us with noise
spikes less than 20ns wide:

-    msleep(20);
+    usleep_range(20, 1000);

Noralf.


+    if (ret) {
+    DRM_DEV_ERROR(dev, "Failed to send reset command (%d)\n", ret);
+    if (mipi->regulator)
+    regulator_disable(mipi->regulator);
+    return ret;
+    }
+
+    return 0;
+}
+
+/**
+ * mipi_dbi_poweron_reset - MIPI DBI poweron and reset
+ * @mipi: MIPI DBI structure
+ *
+ * This function enables the regulator if used and does a hardware 
and software

+ * reset.
+ *
+ * Returns:
+ * Zero on success, or a negative error code.
+ */
+int mipi_dbi_poweron_reset(struct mipi_dbi *mipi)
+{
+    return mipi_dbi_por_conditional(mipi, false);
+}
+EXPORT_SYMBOL(mipi_dbi_poweron_reset);
+
+/**
+ * mipi_dbi_poweron_conditional_reset - MIPI DBI poweron and 
conditional reset

+ * @mipi: MIPI DBI structure
+ *
+ * This function enables the regulator if used and if the display is 
off, it
+ * does a hardware and software reset. If mipi_dbi_display_is_on() 
determines

+ * that the display is on, no reset is performed.
+ *
+ * Returns:
+ * Zero if the controller was reset, 1 if the display was already 
on, or a

+ * negative error code.
+ */
+int mipi_dbi_

Re: [RFC v2 2/8] drm/ioctl: Remove trailing whitespace

[Laurent Pinchart]

Hi Noralf,

Thank you for the patch.

On Thursday, 4 January 2018 00:21:04 EET Noralf Trønnes wrote:
> Remove a couple of trailing spaces.
> 
> Signed-off-by: Noralf Trønnes 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/drm_ioctl.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index 4aafe4802099..b1e96fb68ea8 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -509,7 +509,7 @@ int drm_ioctl_permit(u32 flags, struct drm_file
> *file_priv) return -EACCES;
> 
>   /* MASTER is only for master or control clients */
> - if (unlikely((flags & DRM_MASTER) &&
> + if (unlikely((flags & DRM_MASTER) &&
>!drm_is_current_master(file_priv) &&
>!drm_is_control_client(file_priv)))
>   return -EACCES;
> @@ -704,7 +704,7 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
>   *
>   * ##define DRM_IOCTL_MY_DRIVER_OPERATION \
>   * DRM_IOW(DRM_COMMAND_BASE, struct my_driver_operation)
> - *
> + *
>   * DRM driver private IOCTL must be in the range from DRM_COMMAND_BASE to
>   * DRM_COMMAND_END. Finally you need an array of &struct drm_ioctl_desc to
> wire * up the handlers and set the access rights::


-- 
Regards,

Laurent Pinchart

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

Re: [RFC v2 3/8] drm: Export some ioctl functions

[Laurent Pinchart]

Hi Noralf,

Thank you for the patch.

On Thursday, 4 January 2018 00:21:05 EET Noralf Trønnes wrote:
> Export the following functions so in-kernel users can allocate
> dumb buffers:
> - drm_file_alloc
> - drm_file_free
> - drm_prime_handle_to_fd_ioctl
> - drm_mode_addfb2
> - drm_mode_create_dumb_ioctl
> - drm_dropmaster_ioctl
> 
> Signed-off-by: Noralf Trønnes 

I agree with Daniel's comments. Additionally please see below for one small 
comment.

> ---
>  drivers/gpu/drm/drm_auth.c  |  1 +
>  drivers/gpu/drm/drm_crtc_internal.h |  4 
>  drivers/gpu/drm/drm_dumb_buffers.c  |  1 +
>  drivers/gpu/drm/drm_file.c  |  2 ++
>  drivers/gpu/drm/drm_framebuffer.c   |  1 +
>  drivers/gpu/drm/drm_internal.h  |  6 --
>  drivers/gpu/drm/drm_ioctl.c |  1 +
>  drivers/gpu/drm/drm_prime.c |  1 +
>  include/drm/drm_auth.h  |  3 +++
>  include/drm/drm_dumb_buffers.h  | 10 ++
>  include/drm/drm_file.h  |  2 ++
>  include/drm/drm_framebuffer.h   |  3 +++
>  include/drm/drm_prime.h |  2 ++
>  13 files changed, 27 insertions(+), 10 deletions(-)
>  create mode 100644 include/drm/drm_dumb_buffers.h

[snip]

> diff --git a/include/drm/drm_dumb_buffers.h b/include/drm/drm_dumb_buffers.h
> new file mode 100644
> index ..c1138c1c06ab
> --- /dev/null
> +++ b/include/drm/drm_dumb_buffers.h
> @@ -0,0 +1,10 @@

You should add an SPDX header to specify the file license.

> +#ifndef _DRM_DUMB_BUFFERS_H_
> +#define _DRM_DUMB_BUFFERS_H_
> +
> +struct drm_device;
> +struct drm_file;
> +
> +int drm_mode_create_dumb_ioctl(struct drm_device *dev,
> +void *data, struct drm_file *file_priv);
> +
> +#endif

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH v5] drm/omap: plane zpos/zorder management improvements

[Daniel Vetter]

On Tue, Jan 09, 2018 at 04:18:48PM +0200, Peter Ujfalusi wrote:
> Hi,
> 
> On 2018-01-09 14:44, Daniel Vetter wrote:
> >> Changes since v4:
> >> - further simplify the zpos checking by using a mask and a single loop
> >> - Commit message has been extended
> >>
> >> Changes since v3:
> >> - Use drm_plane_index() instead of storing the same index wothin omap_plane
> >>   struct
> >> - Optimize the zpos validation loop so we avoid extra checks.
> >>
> >> Changes since v2:
> >> - The check for duplicate zpos is moved to omap_crtc
> >>
> >> Changes since v1:
> >> - Dropped the zpos normalization related patches
> >> - New patch based on the discussion, see commit message.
> > 
> > Sorry for jumping in late to the party, but except when you have a really,
> > really, really good reason for why omapdrm has to not normalize zpos like
> > the other drivers do in this case, then I think we should be consistent.
> > 
> > An inconsistent kms uapi is a lot worse than an uapi with some design
> > issues: The latter just means we eventually need v2, the former guarantees
> > we need v2.
> 
> Even if the v2 contains the "drm/blend: Account also the primary plane
> of the crtc for normalized_zpos"?
> It is to ensure that the crtc->primary plane is going to have zpos = 0,
> even if it's plane_id is higher.

It's a bit a hack, but imo makes sense, given where we are with uapi.
Except it sounds like we have more bikesheds going on about what exactly
zpos is supposed to do.

> As it was discussed we have use case when we have two (or more) crtcs,
> each with one plane (they are the primary planes for the given crtc) and
> user moves one of the plane from one crtc to another, where it is no
> longer the primary plane, but still holds zpos = 0.
> 
> In this case we prefer to keep the actual primary plane of the crtc at
> the bottom and stack the new planes on top.

Yeah that all sounds reasonable. Or we state that userspace in that case
better readjust zpos to make it non-ambiguous. Or something else.

Just something that's consistent across drivers. I'm totally fine with
"organically grown uapi with lots of cruds and hacks".
-Daniel

> 
> > Thanks, Daniel
> > 
> >>
> >> Regards,
> >> Peter
> >>
> >>  drivers/gpu/drm/omapdrm/omap_crtc.c  | 23 ++-
> >>  drivers/gpu/drm/omapdrm/omap_plane.c | 15 ---
> >>  2 files changed, 26 insertions(+), 12 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
> >> b/drivers/gpu/drm/omapdrm/omap_crtc.c
> >> index 1b8154e58d18..941a6440fc8e 100644
> >> --- a/drivers/gpu/drm/omapdrm/omap_crtc.c
> >> +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
> >> @@ -486,6 +486,27 @@ static void omap_crtc_mode_set_nofb(struct drm_crtc 
> >> *crtc)
> >>}
> >>  }
> >>  
> >> +static int omap_crtc_validate_zpos(struct drm_crtc *crtc,
> >> + struct drm_crtc_state *state)
> >> +{
> >> +  struct drm_plane *plane;
> >> +  const struct drm_plane_state *pstate;
> >> +  unsigned int zpos_mask = 0;
> >> +
> >> +  /* Check the crts's planes against duplicated zpos value */
> >> +  drm_atomic_crtc_state_for_each_plane_state(plane, pstate, state) {
> >> +  if (zpos_mask & BIT(pstate->zpos)) {
> >> +  DBG("crtc%u: zpos must be unique (zpos: %u)",
> >> +  crtc->index, pstate->zpos);
> >> +  return -EINVAL;
> >> +  }
> >> +
> >> +  zpos_mask |= BIT(pstate->zpos);
> >> +  }
> >> +
> >> +  return 0;
> >> +}
> >> +
> >>  static int omap_crtc_atomic_check(struct drm_crtc *crtc,
> >>struct drm_crtc_state *state)
> >>  {
> >> @@ -509,7 +530,7 @@ static int omap_crtc_atomic_check(struct drm_crtc 
> >> *crtc,
> >>omap_crtc_state->rotation = pri_state->rotation;
> >>}
> >>  
> >> -  return 0;
> >> +  return omap_crtc_validate_zpos(crtc, state);
> >>  }
> >>  
> >>  static void omap_crtc_atomic_begin(struct drm_crtc *crtc,
> >> diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c 
> >> b/drivers/gpu/drm/omapdrm/omap_plane.c
> >> index 7d789d1551a1..39f25210bef1 100644
> >> --- a/drivers/gpu/drm/omapdrm/omap_plane.c
> >> +++ b/drivers/gpu/drm/omapdrm/omap_plane.c
> >> @@ -97,8 +97,7 @@ static void omap_plane_atomic_disable(struct drm_plane 
> >> *plane,
> >>struct omap_plane *omap_plane = to_omap_plane(plane);
> >>  
> >>plane->state->rotation = DRM_MODE_ROTATE_0;
> >> -  plane->state->zpos = plane->type == DRM_PLANE_TYPE_PRIMARY
> >> - ? 0 : omap_plane->id;
> >> +  plane->state->zpos = drm_plane_index(plane);
> >>  
> >>priv->dispc_ops->ovl_enable(omap_plane->id, false);
> >>  }
> >> @@ -184,18 +183,12 @@ void omap_plane_install_properties(struct drm_plane 
> >> *plane,
> >>  
> >>  static void omap_plane_reset(struct drm_plane *plane)
> >>  {
> >> -  struct omap_plane *omap_plane = to_omap_plane(plane);
> >> -
> >>drm_atomic_helper_plane_reset(plane);
> >>if (!plane->state)
> >>return;
> >>  

Re: [PATCH 1/2] drm/blend: Account also the primary plane of the crtc for normalized_zpos

[Daniel Vetter]

On Tue, Jan 09, 2018 at 03:40:36PM +0200, Laurent Pinchart wrote:
> Hi Daniel,
> 
> On Tuesday, 9 January 2018 14:42:55 EET Daniel Vetter wrote:
> > On Fri, Dec 22, 2017 at 05:15:05PM +0200, Peter Ujfalusi wrote:
> > > On 2017-12-22 12:12, Ville Syrjälä wrote:
> > > > On Fri, Dec 22, 2017 at 11:16:47AM +0200, Tomi Valkeinen wrote:
> > > >> On 21/12/17 17:12, Ville Syrjälä wrote:
> > >  If the userspace knows this, then it knows which primary plane is for
> > >  which crtc, right?
> > >  
> > >  And if it doesn't know this, then the userspace cannot associate any
> > >  plane to any crtc (except what it configures itself).
> > >  
> > >  So... If using legacy modesetting (and non-universal planes), there's
> > >  no
> > >  problem, primary planes are fixed and at low zpos. If using atomic
> > >  modesetting and universal planes, there's really no (default)
> > >  association between planes and crtcs, and "primary plane" doesn't
> > >  have
> > >  much meaning. Is that correct?
> > >  
> > >  If so... Then I guess the atomic modesetting client essentially
> > >  randomly
> > >  picks which plane it uses as a "root plane" (if it even needs such),
> > >  and
> > >  which planes as overlay planes? If that's the case, then this patch
> > >  doesn't quite fix the issue...
> > > >>> 
> > > >>> I'm not sure anyone has really thought how userspace would/should
> > > >>> assign
> > > >>> planes to crtcs. My only idea so far has been the crtc and their
> > > >>> preferred primary planes should be registered in the same order. But
> > > >>> someone should then also implement that same policy in userspace when
> > > >>> it's trying to figure out which plane to use. There are other
> > > >>> heuristics it should probably use, like preferring to pick a primary
> > > >>> plane for any fullscreen surface.
> > > >>> 
> > > >>> I guess from functional point of view it shouldn't matter which plane
> > > >>> you pick as long as the plane's user visible capabilities are
> > > >>> sufficient. But there might be user invisible power saving features
> > > >>> and
> > > >>> whatnot that only work with specific planes. So from that point of
> > > >>> view
> > > >>> maybe the order in which the planes get registered is important. Or we
> > > >>> could maybe come up with some kind of plane usage hints in the uapi
> > > >>> which could help userspace decide?
> > > >> 
> > > >> I was thinking about this, and... maybe there isn't even any problem
> > > >> (at
> > > >> least for OMAP). So lets say we set the default plane zpos to the plane
> > > >> index, and that the primary planes are reserved first (i.e. have lower
> > > >> zpos than overlay planes).
> > > >> 
> > > >> We have three different cases:
> > > >> 
> > > >> Legacy modesetting: No problems, primary plane is always at the bottom.
> > > >> If the userspace uses 2+ overlay planes, it can expect the zpos to be
> > > >> based on the plane id, or it can set the zpos.
> > > >> 
> > > >> Atomic+Universal, the application uses one primary plane, and zero or
> > > >> more overlay planes: No problems here, the situation is the same as for
> > > >> legacy.
> > > >> 
> > > >> Atomic+Universal, the application uses more than one primary plane, and
> > > >> zero or more overlay planes: in this case the app _has_ to manage zpos,
> > > >> because using two primary planes in a single screen, and expecting it
> > > >> to
> > > >> work by default, doesn't make sense.
> > > >> 
> > > >> If the above "rules" are valid, then there's no need for this patch.
> > > >> 
> > > >> But one question I don't have a good answer is that why would we want
> > > >> to
> > > >> normalize the zpos, instead of returning an error? If the above rules
> > > >> are valid, I think returning an error is better than normalizing and
> > > >> hiding the bad configuration.
> > > > 
> > > > IIRC I argued against the normalization, but some people really
> > > > wanted it for whatever reason.
> > > 
> > > OK, please ignore this series, I'll send a patch instead next year.
> > 
> > So now we end up with a bunch of kms drivers that normalize zpos, and a
> > bunch of others which rejects duplicated zpos.
> > 
> > That sounds even worse. Can we pls try to be consistent (even if it turns
> > out to be a not-so-great uapi decision, it's uapi, so let's not make
> > things worse by making it inconsistent).
> 
> For what it's worth, I'd tend to disallow duplicate zpos values. That forces 
> userspace to user atomic and to handle zpos explicitly, and that's exactly 
> why 
> it's my preference as not handling zpos explicitly in userspace will lead to 
> random behaviour at best.

I don't care what we're going with tbf, except it should be consistent
across drivers ... Everyone just implementing their flavour of bikeshed in
their driver is kinda uncool.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___

Re: [PATCH 06/19] drm/blend: Add a generic alpha property

[Daniel Vetter]

On Tue, Jan 09, 2018 at 02:53:22PM +0100, Maxime Ripard wrote:
> On Tue, Jan 09, 2018 at 01:32:41PM +0100, Daniel Vetter wrote:
> > On Tue, Jan 09, 2018 at 11:56:25AM +0100, Maxime Ripard wrote:
> > > Some drivers duplicate the logic to create a property to store a per-plane
> > > alpha.
> > > 
> > > Let's create a helper in order to move that to the core.
> > > 
> > > Cc: Boris Brezillon 
> > > Cc: Laurent Pinchart 
> > > Signed-off-by: Maxime Ripard 
> > 
> > Do we have userspace for this?
> 
> Wayland seems to be on its way to implement this, with ChromeOS using
> it:
> https://lists.freedesktop.org/archives/wayland-devel/2017-August/034741.html
> 
> and more specifically:
> https://chromium.googlesource.com/chromium/src/+/master/third_party/wayland-protocols/unstable/alpha-compositing/alpha-compositing-unstable-v1.xml#118

Yay, would be good to include these links in the patch description. Really
happy we're having a real standard now used by multiple people.

> > Is encoding a fixed 0-255 range really the best idea?
> 
> I don't really know, is there hardware or formats where there is more
> than 255? Or did you mean less than that?

30bit I'd assume wants more alpha. In the past we've done some fixed-point
stuff (e.g. for LUT), using the 0.0-1.0 float range. Using that for the
blend equation docs is also what I recommend (and that we map from 0-255
to 0.0-1.0 logically). Ofc the hw might not do any of that ... I think
0.16 fixed point, stored in a u16 is probably best. That's what we're
doing for gamma tables already, and that way drivers can simply throw away
the lower bits.

> > I know other drivers have skimped on the rules here a bit ... But at least
> > internally (i.e. within the drm_plane_state) we probably should restrict
> > ourselves to u8. And this needs real docs (i.e. the full blend equation
> > drivers are supposed to implement).
> 
> You mean straight vs premultiplied? Maybe we should implement this as
> an additional property in read only depending on how the hardware
> behaves?

No need for an additional property right now, but definitely document
whether you mean straight or pre-multiplied. Just writing down the blend
equation is probably best.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5] drm/omap: plane zpos/zorder management improvements

[Peter Ujfalusi]

Hi,

On 2018-01-09 14:44, Daniel Vetter wrote:
>> Changes since v4:
>> - further simplify the zpos checking by using a mask and a single loop
>> - Commit message has been extended
>>
>> Changes since v3:
>> - Use drm_plane_index() instead of storing the same index wothin omap_plane
>>   struct
>> - Optimize the zpos validation loop so we avoid extra checks.
>>
>> Changes since v2:
>> - The check for duplicate zpos is moved to omap_crtc
>>
>> Changes since v1:
>> - Dropped the zpos normalization related patches
>> - New patch based on the discussion, see commit message.
> 
> Sorry for jumping in late to the party, but except when you have a really,
> really, really good reason for why omapdrm has to not normalize zpos like
> the other drivers do in this case, then I think we should be consistent.
> 
> An inconsistent kms uapi is a lot worse than an uapi with some design
> issues: The latter just means we eventually need v2, the former guarantees
> we need v2.

Even if the v2 contains the "drm/blend: Account also the primary plane
of the crtc for normalized_zpos"?
It is to ensure that the crtc->primary plane is going to have zpos = 0,
even if it's plane_id is higher.

As it was discussed we have use case when we have two (or more) crtcs,
each with one plane (they are the primary planes for the given crtc) and
user moves one of the plane from one crtc to another, where it is no
longer the primary plane, but still holds zpos = 0.

In this case we prefer to keep the actual primary plane of the crtc at
the bottom and stack the new planes on top.

> Thanks, Daniel
> 
>>
>> Regards,
>> Peter
>>
>>  drivers/gpu/drm/omapdrm/omap_crtc.c  | 23 ++-
>>  drivers/gpu/drm/omapdrm/omap_plane.c | 15 ---
>>  2 files changed, 26 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
>> b/drivers/gpu/drm/omapdrm/omap_crtc.c
>> index 1b8154e58d18..941a6440fc8e 100644
>> --- a/drivers/gpu/drm/omapdrm/omap_crtc.c
>> +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
>> @@ -486,6 +486,27 @@ static void omap_crtc_mode_set_nofb(struct drm_crtc 
>> *crtc)
>>  }
>>  }
>>  
>> +static int omap_crtc_validate_zpos(struct drm_crtc *crtc,
>> +   struct drm_crtc_state *state)
>> +{
>> +struct drm_plane *plane;
>> +const struct drm_plane_state *pstate;
>> +unsigned int zpos_mask = 0;
>> +
>> +/* Check the crts's planes against duplicated zpos value */
>> +drm_atomic_crtc_state_for_each_plane_state(plane, pstate, state) {
>> +if (zpos_mask & BIT(pstate->zpos)) {
>> +DBG("crtc%u: zpos must be unique (zpos: %u)",
>> +crtc->index, pstate->zpos);
>> +return -EINVAL;
>> +}
>> +
>> +zpos_mask |= BIT(pstate->zpos);
>> +}
>> +
>> +return 0;
>> +}
>> +
>>  static int omap_crtc_atomic_check(struct drm_crtc *crtc,
>>  struct drm_crtc_state *state)
>>  {
>> @@ -509,7 +530,7 @@ static int omap_crtc_atomic_check(struct drm_crtc *crtc,
>>  omap_crtc_state->rotation = pri_state->rotation;
>>  }
>>  
>> -return 0;
>> +return omap_crtc_validate_zpos(crtc, state);
>>  }
>>  
>>  static void omap_crtc_atomic_begin(struct drm_crtc *crtc,
>> diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c 
>> b/drivers/gpu/drm/omapdrm/omap_plane.c
>> index 7d789d1551a1..39f25210bef1 100644
>> --- a/drivers/gpu/drm/omapdrm/omap_plane.c
>> +++ b/drivers/gpu/drm/omapdrm/omap_plane.c
>> @@ -97,8 +97,7 @@ static void omap_plane_atomic_disable(struct drm_plane 
>> *plane,
>>  struct omap_plane *omap_plane = to_omap_plane(plane);
>>  
>>  plane->state->rotation = DRM_MODE_ROTATE_0;
>> -plane->state->zpos = plane->type == DRM_PLANE_TYPE_PRIMARY
>> -   ? 0 : omap_plane->id;
>> +plane->state->zpos = drm_plane_index(plane);
>>  
>>  priv->dispc_ops->ovl_enable(omap_plane->id, false);
>>  }
>> @@ -184,18 +183,12 @@ void omap_plane_install_properties(struct drm_plane 
>> *plane,
>>  
>>  static void omap_plane_reset(struct drm_plane *plane)
>>  {
>> -struct omap_plane *omap_plane = to_omap_plane(plane);
>> -
>>  drm_atomic_helper_plane_reset(plane);
>>  if (!plane->state)
>>  return;
>>  
>> -/*
>> - * Set the zpos default depending on whether we are a primary or overlay
>> - * plane.
>> - */
>> -plane->state->zpos = plane->type == DRM_PLANE_TYPE_PRIMARY
>> -   ? 0 : omap_plane->id;
>> +/* Set the zpos to the plane index. */
>> +plane->state->zpos = drm_plane_index(plane);
>>  }
>>  
>>  static int omap_plane_atomic_set_property(struct drm_plane *plane,
>> @@ -295,7 +288,7 @@ struct drm_plane *omap_plane_init(struct drm_device *dev,
>>  drm_plane_helper_add(plane, &omap_plane_helper_funcs);
>>  
>>  omap_plane_install_properties(plane, &plane->base);
>> -drm_plane_create_zpos_property(plane, 0, 0, num_planes 

Re: [PATCH v2 6/6] drm/tinydrm: Embed the mode in tinydrm_connector

[Noralf Trønnes]

Den 09.01.2018 11.08, skrev Daniel Vetter:

On Mon, Jan 08, 2018 at 07:46:27PM -0600, David Lechner wrote:

On 01/07/2018 11:44 AM, Noralf Trønnes wrote:

Embed the mode in tinydrm_connector instead of doing an devm_ allocation.
Remove unnecessary use of ret variable at the end of
tinydrm_display_pipe_init().

Signed-off-by: Noralf Trønnes 
---

Reviewed-by: David Lechner 

Since you two work together quit a bit, should we add David as drm-misc
committer?


I would love that. What do you say David?
This would mean that you will commit your own work after getting ack/rb.

Noralf.


-Daniel


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

Re: [PATCH 06/19] drm/blend: Add a generic alpha property

[Maxime Ripard]

Hi Laurent,

On Tue, Jan 09, 2018 at 02:34:47PM +0200, Laurent Pinchart wrote:
> > Some drivers duplicate the logic to create a property to store a per-plane
> > alpha.
> > 
> > Let's create a helper in order to move that to the core.
> > 
> > Cc: Boris Brezillon 
> > Cc: Laurent Pinchart 
> > Signed-off-by: Maxime Ripard 
> > ---
> >  Documentation/gpu/kms-properties.csv |  2 +-
> >  drivers/gpu/drm/drm_atomic.c |  4 -
> >  drivers/gpu/drm/drm_atomic_helper.c  |  1 +-
> >  drivers/gpu/drm/drm_blend.c  | 32 +-
> >  include/drm/drm_blend.h  |  1 +-
> >  include/drm/drm_plane.h  |  6 +-
> >  6 files changed, 45 insertions(+), 1 deletion(-)
> > 
> > diff --git a/Documentation/gpu/kms-properties.csv
> > b/Documentation/gpu/kms-properties.csv index 927b65e14219..a3c3969c1992
> > 100644
> > --- a/Documentation/gpu/kms-properties.csv
> > +++ b/Documentation/gpu/kms-properties.csv
> > @@ -99,5 +99,5 @@ radeon,DVI-I,“coherent”,RANGE,"Min=0, Max=1",Connector,TBD
> > ,,"""underscan vborder""",RANGE,"Min=0, Max=128",Connector,TBD
> >  ,Audio,“audio”,ENUM,"{ ""off"", ""on"", ""auto"" }",Connector,TBD
> >  ,FMT Dithering,“dither”,ENUM,"{ ""off"", ""on"" }",Connector,TBD
> > -rcar-du,Generic,"""alpha""",RANGE,"Min=0, Max=255",Plane,TBD
> > +,,"""alpha""",RANGE,"Min=0, Max=255",Plane,Opacity of the plane from
> > transparent (0) to opaque (255) ,,"""colorkey""",RANGE,"Min=0,
> > Max=0x01ff",Plane,TBD
> 
> I think more documentation is needed. You should explain how the property 
> operates and which formats it is applicable to. For instance you need to 
> clarify what happens for format that contain an alpha component.

That's a very good point, and I'm not quite sure what should happen in
the first place :)

Should we forbid that configuration?

> >  /**
> > + * drm_plane_create_alpha_property - create a new alpha property
> > + * @plane: drm plane
> > + * @alpha: initial value of alpha, from 0 (transparent) to 255 (opaque)
> 
> Do you have a use case for initializing the alpha value to something else 
> than 
> fully opaque ?

I don't, but thought it might be useful. Maybe it isn't, in which case
I'm totally fine with it getting away.

> > + * This function initializes a generic, mutable, alpha property and
> > + * enables support for it in the DRM core.
> > + *
> > + * Drivers can then attach this property to their plane to enable
> > + * support for configurable plane alpha.
> 
> The function attaches the property to the plane, is the
> documentation outdated ?

Yes, I'll fix it.

> > + * Returns:
> > + * 0 on success, negative error code on failure.
> > + */
> > +int drm_plane_create_alpha_property(struct drm_plane *plane, u8 alpha)
> > +{
> > +   struct drm_property *prop;
> > +
> > +   prop = drm_property_create_range(plane->dev, 0, "alpha", 0, 255);
> 
> Do you think the 0-255 range will fit all use cases ?

This is kind of the same discussion we're having with Daniel, but are
there hardware or formats with an alpha component wider than 255?

Thanks!
Maxime

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


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

[Bug 104556] WARNING: CPU: 1 PID: 7288 at mm/slab_common.c:971 kmalloc_slab+0x5e/0x70

[bugzilla-daemon]

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

--- Comment #4 from Michel Dänzer  ---
The dmesg splat should be fixed with latest development kernels. The hang is
probably not directly related.

-- 
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 06/19] drm/blend: Add a generic alpha property

[Maxime Ripard]

On Tue, Jan 09, 2018 at 01:32:41PM +0100, Daniel Vetter wrote:
> On Tue, Jan 09, 2018 at 11:56:25AM +0100, Maxime Ripard wrote:
> > Some drivers duplicate the logic to create a property to store a per-plane
> > alpha.
> > 
> > Let's create a helper in order to move that to the core.
> > 
> > Cc: Boris Brezillon 
> > Cc: Laurent Pinchart 
> > Signed-off-by: Maxime Ripard 
> 
> Do we have userspace for this?

Wayland seems to be on its way to implement this, with ChromeOS using
it:
https://lists.freedesktop.org/archives/wayland-devel/2017-August/034741.html

and more specifically:
https://chromium.googlesource.com/chromium/src/+/master/third_party/wayland-protocols/unstable/alpha-compositing/alpha-compositing-unstable-v1.xml#118

> Is encoding a fixed 0-255 range really the best idea?

I don't really know, is there hardware or formats where there is more
than 255? Or did you mean less than that?

> I know other drivers have skimped on the rules here a bit ... But at least
> internally (i.e. within the drm_plane_state) we probably should restrict
> ourselves to u8. And this needs real docs (i.e. the full blend equation
> drivers are supposed to implement).

You mean straight vs premultiplied? Maybe we should implement this as
an additional property in read only depending on how the hardware
behaves?

Thanks!
Maxime

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


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

[Bug 104306] Mesa 17.3 breaks Firefox and other Xwayland apps on AMD HD7750

[bugzilla-daemon]

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

--- Comment #13 from Michel Dänzer  ---
(In reply to eric vz from comment #12)
> [...] gdb glxinfo and set a breakpoint on dri2_validate_usage, but that method
> appears not to be called before the process hangs.

It's not called in the client but in the Wayland compositor process, or maybe
in Xwayland.

-- 
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 v14 0/3] Move backlight helper functions from tinydrm-helpers to linux/backlight

[Rob Herring]

On Thu, Dec 21, 2017 at 8:08 AM, Daniel Vetter  wrote:
> On Thu, Dec 21, 2017 at 2:44 PM, Noralf Trønnes  wrote:
>>
>> Den 21.12.2017 14.05, skrev Daniel Vetter:
>>>
>>> On Thu, Dec 21, 2017 at 11:52:43AM +0100, Noralf Trønnes wrote:

 Den 11.12.2017 18.56, skrev Noralf Trønnes:
>
> Den 11.12.2017 18.45, skrev Noralf Trønnes:
>>
>> Den 11.12.2017 15.58, skrev Meghana Madhyastha:
>>>
>>> On Mon, Dec 11, 2017 at 03:12:06PM +0100, Noralf Trønnes wrote:

 Den 11.12.2017 14.17, skrev Meghana Madhyastha:
>
> On Sat, Dec 09, 2017 at 03:09:28PM +0100, Noralf Trønnes wrote:
>>
>> Den 21.10.2017 13.55, skrev Meghana Madhyastha:
>>>
>>> Changes in v14:
>>> - s/backlight_get/of_find_backlight/ in patch 2/3
>>> - Change commit message in patch 3/3 from requiring to acquiring
>>>
>>> Meghana Madhyastha (3):
>>> drm/tinydrm: Move helper functions from
>>> tinydrm-helpers to backlight.h
>>> drm/tinydrm: Move tinydrm_of_find_backlight to backlight.c
>>> drm/tinydrm: Add devres versions of of_find_backlight
>>
>> I tried the patchset and this is what I got:
>>
>> [8.057792] Unable to handle kernel paging
>> request at virtual address
>> fe6b
>
> 
>>
>> [9.144181] ---[ end trace 149c05934b6a6dcc ]---
>
> Is the reason possibly because we have omitted error checking on the
> return value of backlight_enable function ?
> tinydrm_enable_backlight and
> tinydrm_disable_baclight do this.
> Eg.
> ret = backlight_update_status(backlight);
> if (ret)
>  DRM_ERROR("Failed to enable backlight %d\n", ret);
>
> I'm not sure, just asking whether this could be a possible reason
> for the above trace.

 The crash happens during probe.
 I guess you'll figure this out when you get some hw to test on.
>>>
>>> I have set up the raspberry pi and have built and boot into the
>>> custom kernel
>>> but I am waiting for the panel to arrive. Meanwhile, any thoughts on
>>> error message ? Sorry for the trivial question, but I did not quite
>>> understand the crash message and how to replicate it.
>>
>> of_find_backlight() can return an error pointer (-EPROBE_DEFER):
>>
>> diff --git a/drivers/video/backlight/backlight.c
>> b/drivers/video/backlight/backlight.c
>> index 4bb7bf3ee443..57370c5d51f0 100644
>> --- a/drivers/video/backlight/backlight.c
>> +++ b/drivers/video/backlight/backlight.c
>> @@ -635,8 +635,8 @@ struct backlight_device
>> *devm_of_find_backlight(struct device *dev)
>>  int ret;
>>
>>  bd = of_find_backlight(dev);
>> -   if (!bd)
>> -   return NULL;
>> +   if (IS_ERR_OR_NULL(bd))
>> +   return bd;
>>
>>  ret = devm_add_action(dev, devm_backlight_put, bd);
>>  if (ret) {
>>
>> That solved the crash, but the backlight didn't turn on.
>> I had to do this as well:
>>
>> diff --git a/include/linux/backlight.h b/include/linux/backlight.h
>> index 5c441d4c049c..6f9925f10a7c 100644
>> --- a/include/linux/backlight.h
>> +++ b/include/linux/backlight.h
>> @@ -139,6 +139,8 @@ static inline int backlight_enable(struct
>> backlight_device *bd)
>>  if (!bd)
>>  return 0;
>>
>> +   if (!bd->props.brightness)
>> +   bd->props.brightness = bd->props.max_brightness;
>
> No, this is wrong, it should happen on probe, not every time it's
> enabled.
> So maybe it should be done in of_find_backlight() or something.
> I see that I'm currently doing it in tinydrm_of_find_backlight().
>
 I'm not happy with this brightness hack of mine really.

 Since I last looked at this I see that pwm_bl has gained the ability to
 start in a power off state (pwm_backlight_initial_power_state()).
 However the gpio_backlight driver doesn't do this. gpio_backlight has a
 'default-on' property, but the problem is that it sets brightness, not
 power state. So the absense of the property sets brightness to zero,
 which makes the driver turn off backlight on probe. This seems to be
 fine, but then systemd-backlight comes along and restores brightness
 to 1, since that's what it was on shutdown. This turns on backlight and
 now I have a glaring white uninitialized panel waiting for the display
 driver to set it up.

 This patch would solve my problem:

 diff --git a/drivers/video/backlight/gpio_backlight.c
 b/drivers/video/backlight/gpio_backlight.c
 index e470da95d806..54bb722e1ea3 100644
 --- a/drivers/video/backlight/gpio_backlight.c
 +++ b/

[Bug 104556] WARNING: CPU: 1 PID: 7288 at mm/slab_common.c:971 kmalloc_slab+0x5e/0x70

[bugzilla-daemon]

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

--- Comment #3 from Christian König  ---
Please add your dmesg as attachment and not as inline comment.

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

Re: [PATCH] drm/bridge/synopsis: stop clobbering drvdata

[Andrzej Hajda]

On 09.01.2018 14:37, Laurent Pinchart wrote:
> Hi Philippe,
>
> On Tuesday, 9 January 2018 15:01:02 EET Philippe CORNU wrote:
>> Hi Archit, Andrzej & Laurent,
>>
>> Regarding this patch from Brian, I think it could be nice to merge it 
>> (1xAcked-by, 2xReviewed-by).
>>
>> Could you please have a look?
>>
>> Only the small "typo" in the headline needs to be changed.
>>
>> Many thanks,
> I've just replied to Brian in this mail thread. Sorry for the delay, it 
> slipped through the cracks. Thank you for pinging me.

I have just pushed the patch to drm-misc-next. I am sorry, if you wanted
to polish it more, from the thread it looked it can be merged as is.

Regards
Andrzej


>> On 11/28/2017 10:34 AM, Philippe CORNU wrote:
>>
>>> Hi Brian,
>>>
>>> On 11/28/2017 02:05 AM, Brian Norris wrote:
>>>
 Bridge drivers/helpers shouldn't be clobbering the drvdata, since a
 parent driver might need to own this. Instead, let's return our
 'dw_mipi_dsi' object and have callers pass that back to us for removal.
>>>
>>> And many thanks for this cleanup.
>>> (please update the headline with "synopsys")
>>>
>>> Successfully tested on stm.
>>>
>>> Acked-by: Philippe Cornu 
>>>
>>> Many thanks,
>>> Philippe :-)
>>>

 Signed-off-by: Brian Norris 
 ---
   drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 36 
 ++-
   drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 14 +++
   include/drm/bridge/dw_mipi_dsi.h  | 17 -
   3 files changed, 33 insertions(+), 34 deletions(-)



 diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
 b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
 index d9cca4fd66ec..c39c7dce20ed 100644
 --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
 +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
 @@ -922,8 +922,6 @@ __dw_mipi_dsi_probe(struct platform_device *pdev,
   dsi->bridge.of_node = pdev->dev.of_node;
   #endif
 -dev_set_drvdata(dev, dsi);
 -
   return dsi;
   }
 @@ -935,23 +933,16 @@ static void __dw_mipi_dsi_remove(struct 
 dw_mipi_dsi *dsi)
   /*
* Probe/remove API, used from platforms based on the DRM bridge API.
*/
 -int dw_mipi_dsi_probe(struct platform_device *pdev,
 -  const struct dw_mipi_dsi_plat_data *plat_data)
 +struct dw_mipi_dsi *
 +dw_mipi_dsi_probe(struct platform_device *pdev,
 +  const struct dw_mipi_dsi_plat_data *plat_data)
   {
 -struct dw_mipi_dsi *dsi;
 -
 -dsi = __dw_mipi_dsi_probe(pdev, plat_data);
 -if (IS_ERR(dsi))
 -return PTR_ERR(dsi);
 -
 -return 0;
 +return __dw_mipi_dsi_probe(pdev, plat_data);
   }
   EXPORT_SYMBOL_GPL(dw_mipi_dsi_probe);
 -void dw_mipi_dsi_remove(struct platform_device *pdev)
 +void dw_mipi_dsi_remove(struct dw_mipi_dsi *dsi)
   {
 -struct dw_mipi_dsi *dsi = platform_get_drvdata(pdev);
 -
   mipi_dsi_host_unregister(&dsi->dsi_host);
   __dw_mipi_dsi_remove(dsi);
 @@ -961,31 +952,30 @@ EXPORT_SYMBOL_GPL(dw_mipi_dsi_remove);
   /*
* Bind/unbind API, used from platforms based on the component 
 framework.
*/
 -int dw_mipi_dsi_bind(struct platform_device *pdev, struct drm_encoder 
 *encoder,
 - const struct dw_mipi_dsi_plat_data *plat_data)
 +struct dw_mipi_dsi *
 +dw_mipi_dsi_bind(struct platform_device *pdev, struct drm_encoder 
 *encoder,
 + const struct dw_mipi_dsi_plat_data *plat_data)
   {
   struct dw_mipi_dsi *dsi;
   int ret;
   dsi = __dw_mipi_dsi_probe(pdev, plat_data);
   if (IS_ERR(dsi))
 -return PTR_ERR(dsi);
 +return dsi;
   ret = drm_bridge_attach(encoder, &dsi->bridge, NULL);
   if (ret) {
 -dw_mipi_dsi_remove(pdev);
 +dw_mipi_dsi_remove(dsi);
   DRM_ERROR("Failed to initialize bridge with drm\n");
 -return ret;
 +return ERR_PTR(ret);
   }
 -return 0;
 +return dsi;
   }
   EXPORT_SYMBOL_GPL(dw_mipi_dsi_bind);
 -void dw_mipi_dsi_unbind(struct device *dev)
 +void dw_mipi_dsi_unbind(struct dw_mipi_dsi *dsi)
   {
 -struct dw_mipi_dsi *dsi = dev_get_drvdata(dev);
 -
   __dw_mipi_dsi_remove(dsi);
   }
   EXPORT_SYMBOL_GPL(dw_mipi_dsi_unbind);
 diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c 
 b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
 index e5b6310240fe..7ed0ef7f6ec2 100644
 --- a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
 +++ b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
 @@ -66,6 +66,7 @@ enum dsi_color {
   struct dw_mipi_dsi_stm {
   void __iomem *base;
   struct clk *pllref_clk;
 +struct dw_mipi_dsi *dsi;
   };
   static inline void dsi_write(struct dw_mipi_dsi_st

Re: [PATCH 1/2] drm/blend: Account also the primary plane of the crtc for normalized_zpos

[Laurent Pinchart]

Hi Daniel,

On Tuesday, 9 January 2018 14:42:55 EET Daniel Vetter wrote:
> On Fri, Dec 22, 2017 at 05:15:05PM +0200, Peter Ujfalusi wrote:
> > On 2017-12-22 12:12, Ville Syrjälä wrote:
> > > On Fri, Dec 22, 2017 at 11:16:47AM +0200, Tomi Valkeinen wrote:
> > >> On 21/12/17 17:12, Ville Syrjälä wrote:
> >  If the userspace knows this, then it knows which primary plane is for
> >  which crtc, right?
> >  
> >  And if it doesn't know this, then the userspace cannot associate any
> >  plane to any crtc (except what it configures itself).
> >  
> >  So... If using legacy modesetting (and non-universal planes), there's
> >  no
> >  problem, primary planes are fixed and at low zpos. If using atomic
> >  modesetting and universal planes, there's really no (default)
> >  association between planes and crtcs, and "primary plane" doesn't
> >  have
> >  much meaning. Is that correct?
> >  
> >  If so... Then I guess the atomic modesetting client essentially
> >  randomly
> >  picks which plane it uses as a "root plane" (if it even needs such),
> >  and
> >  which planes as overlay planes? If that's the case, then this patch
> >  doesn't quite fix the issue...
> > >>> 
> > >>> I'm not sure anyone has really thought how userspace would/should
> > >>> assign
> > >>> planes to crtcs. My only idea so far has been the crtc and their
> > >>> preferred primary planes should be registered in the same order. But
> > >>> someone should then also implement that same policy in userspace when
> > >>> it's trying to figure out which plane to use. There are other
> > >>> heuristics it should probably use, like preferring to pick a primary
> > >>> plane for any fullscreen surface.
> > >>> 
> > >>> I guess from functional point of view it shouldn't matter which plane
> > >>> you pick as long as the plane's user visible capabilities are
> > >>> sufficient. But there might be user invisible power saving features
> > >>> and
> > >>> whatnot that only work with specific planes. So from that point of
> > >>> view
> > >>> maybe the order in which the planes get registered is important. Or we
> > >>> could maybe come up with some kind of plane usage hints in the uapi
> > >>> which could help userspace decide?
> > >> 
> > >> I was thinking about this, and... maybe there isn't even any problem
> > >> (at
> > >> least for OMAP). So lets say we set the default plane zpos to the plane
> > >> index, and that the primary planes are reserved first (i.e. have lower
> > >> zpos than overlay planes).
> > >> 
> > >> We have three different cases:
> > >> 
> > >> Legacy modesetting: No problems, primary plane is always at the bottom.
> > >> If the userspace uses 2+ overlay planes, it can expect the zpos to be
> > >> based on the plane id, or it can set the zpos.
> > >> 
> > >> Atomic+Universal, the application uses one primary plane, and zero or
> > >> more overlay planes: No problems here, the situation is the same as for
> > >> legacy.
> > >> 
> > >> Atomic+Universal, the application uses more than one primary plane, and
> > >> zero or more overlay planes: in this case the app _has_ to manage zpos,
> > >> because using two primary planes in a single screen, and expecting it
> > >> to
> > >> work by default, doesn't make sense.
> > >> 
> > >> If the above "rules" are valid, then there's no need for this patch.
> > >> 
> > >> But one question I don't have a good answer is that why would we want
> > >> to
> > >> normalize the zpos, instead of returning an error? If the above rules
> > >> are valid, I think returning an error is better than normalizing and
> > >> hiding the bad configuration.
> > > 
> > > IIRC I argued against the normalization, but some people really
> > > wanted it for whatever reason.
> > 
> > OK, please ignore this series, I'll send a patch instead next year.
> 
> So now we end up with a bunch of kms drivers that normalize zpos, and a
> bunch of others which rejects duplicated zpos.
> 
> That sounds even worse. Can we pls try to be consistent (even if it turns
> out to be a not-so-great uapi decision, it's uapi, so let's not make
> things worse by making it inconsistent).

For what it's worth, I'd tend to disallow duplicate zpos values. That forces 
userspace to user atomic and to handle zpos explicitly, and that's exactly why 
it's my preference as not handling zpos explicitly in userspace will lead to 
random behaviour at best.

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH] drm/bridge/synopsis: stop clobbering drvdata

[Laurent Pinchart]

Hi Philippe,

On Tuesday, 9 January 2018 15:01:02 EET Philippe CORNU wrote:
> Hi Archit, Andrzej & Laurent,
> 
> Regarding this patch from Brian, I think it could be nice to merge it 
> (1xAcked-by, 2xReviewed-by).
> 
> Could you please have a look?
> 
> Only the small "typo" in the headline needs to be changed.
> 
> Many thanks,

I've just replied to Brian in this mail thread. Sorry for the delay, it 
slipped through the cracks. Thank you for pinging me.

> On 11/28/2017 10:34 AM, Philippe CORNU wrote:
> 
> > Hi Brian,
> > 
> > On 11/28/2017 02:05 AM, Brian Norris wrote:
> > 
> >> Bridge drivers/helpers shouldn't be clobbering the drvdata, since a
> >> parent driver might need to own this. Instead, let's return our
> >> 'dw_mipi_dsi' object and have callers pass that back to us for removal.
> > 
> > 
> > And many thanks for this cleanup.
> > (please update the headline with "synopsys")
> > 
> > Successfully tested on stm.
> > 
> > Acked-by: Philippe Cornu 
> > 
> > Many thanks,
> > Philippe :-)
> > 
> >>
> >>
> >> Signed-off-by: Brian Norris 
> >> ---
> >>   drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 36 
> >> ++-
> >>   drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 14 +++
> >>   include/drm/bridge/dw_mipi_dsi.h  | 17 -
> >>   3 files changed, 33 insertions(+), 34 deletions(-)
> >>
> >>
> >>
> >> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
> >> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> >> index d9cca4fd66ec..c39c7dce20ed 100644
> >> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> >> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> >> @@ -922,8 +922,6 @@ __dw_mipi_dsi_probe(struct platform_device *pdev,
> >>   dsi->bridge.of_node = pdev->dev.of_node;
> >>   #endif
> >> -dev_set_drvdata(dev, dsi);
> >> -
> >>   return dsi;
> >>   }
> >> @@ -935,23 +933,16 @@ static void __dw_mipi_dsi_remove(struct 
> >> dw_mipi_dsi *dsi)
> >>   /*
> >>* Probe/remove API, used from platforms based on the DRM bridge API.
> >>*/
> >> -int dw_mipi_dsi_probe(struct platform_device *pdev,
> >> -  const struct dw_mipi_dsi_plat_data *plat_data)
> >> +struct dw_mipi_dsi *
> >> +dw_mipi_dsi_probe(struct platform_device *pdev,
> >> +  const struct dw_mipi_dsi_plat_data *plat_data)
> >>   {
> >> -struct dw_mipi_dsi *dsi;
> >> -
> >> -dsi = __dw_mipi_dsi_probe(pdev, plat_data);
> >> -if (IS_ERR(dsi))
> >> -return PTR_ERR(dsi);
> >> -
> >> -return 0;
> >> +return __dw_mipi_dsi_probe(pdev, plat_data);
> >>   }
> >>   EXPORT_SYMBOL_GPL(dw_mipi_dsi_probe);
> >> -void dw_mipi_dsi_remove(struct platform_device *pdev)
> >> +void dw_mipi_dsi_remove(struct dw_mipi_dsi *dsi)
> >>   {
> >> -struct dw_mipi_dsi *dsi = platform_get_drvdata(pdev);
> >> -
> >>   mipi_dsi_host_unregister(&dsi->dsi_host);
> >>   __dw_mipi_dsi_remove(dsi);
> >> @@ -961,31 +952,30 @@ EXPORT_SYMBOL_GPL(dw_mipi_dsi_remove);
> >>   /*
> >>* Bind/unbind API, used from platforms based on the component 
> >> framework.
> >>*/
> >> -int dw_mipi_dsi_bind(struct platform_device *pdev, struct drm_encoder 
> >> *encoder,
> >> - const struct dw_mipi_dsi_plat_data *plat_data)
> >> +struct dw_mipi_dsi *
> >> +dw_mipi_dsi_bind(struct platform_device *pdev, struct drm_encoder 
> >> *encoder,
> >> + const struct dw_mipi_dsi_plat_data *plat_data)
> >>   {
> >>   struct dw_mipi_dsi *dsi;
> >>   int ret;
> >>   dsi = __dw_mipi_dsi_probe(pdev, plat_data);
> >>   if (IS_ERR(dsi))
> >> -return PTR_ERR(dsi);
> >> +return dsi;
> >>   ret = drm_bridge_attach(encoder, &dsi->bridge, NULL);
> >>   if (ret) {
> >> -dw_mipi_dsi_remove(pdev);
> >> +dw_mipi_dsi_remove(dsi);
> >>   DRM_ERROR("Failed to initialize bridge with drm\n");
> >> -return ret;
> >> +return ERR_PTR(ret);
> >>   }
> >> -return 0;
> >> +return dsi;
> >>   }
> >>   EXPORT_SYMBOL_GPL(dw_mipi_dsi_bind);
> >> -void dw_mipi_dsi_unbind(struct device *dev)
> >> +void dw_mipi_dsi_unbind(struct dw_mipi_dsi *dsi)
> >>   {
> >> -struct dw_mipi_dsi *dsi = dev_get_drvdata(dev);
> >> -
> >>   __dw_mipi_dsi_remove(dsi);
> >>   }
> >>   EXPORT_SYMBOL_GPL(dw_mipi_dsi_unbind);
> >> diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c 
> >> b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> >> index e5b6310240fe..7ed0ef7f6ec2 100644
> >> --- a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> >> +++ b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> >> @@ -66,6 +66,7 @@ enum dsi_color {
> >>   struct dw_mipi_dsi_stm {
> >>   void __iomem *base;
> >>   struct clk *pllref_clk;
> >> +struct dw_mipi_dsi *dsi;
> >>   };
> >>   static inline void dsi_write(struct dw_mipi_dsi_stm *dsi, u32 reg, 
> >> u32 val)
> >> @@ -318,21 +319,24 @@ static int dw_mipi_dsi_stm_probe(struct 
> >> platform_device *pdev)
> >>   dw_mipi_dsi_stm_plat_data.base = dsi->base;
> >>   dw_mipi_ds

Re: [PATCH] drm/bridge/synopsis: stop clobbering drvdata

[Laurent Pinchart]

Hi Brian,

On Tuesday, 28 November 2017 20:21:23 EET Brian Norris wrote:
> On Tue, Nov 28, 2017 at 02:51:46PM +0200, Laurent Pinchart wrote:
> > Hi Brian,
> > 
> > Thank you for the patch.
> > 
> > I'd mention dw-mipi-dsi in the subject line as the directory contains the
> > dw-hdmi driver as well that this patch doesn't touch.
> 
> Yep. Does it need another tag in the subject? e.g., '.../dw-mipi-dsi:'?
> 
> > On Tuesday, 28 November 2017 03:05:38 EET Brian Norris wrote:
> >> Bridge drivers/helpers shouldn't be clobbering the drvdata, since a
> >> parent driver might need to own this.
> > 
> > By parent driver I assume you mean a glue driver that binds to the SoC-
> > specific compatible string for the DSI transmitter.
> 
> Indeed. Nickey picked this up for his Rockchip driver submission, but
> maybe we should reword the commit message a bit.

How about "drm: dw-mipi-dsi: Stop clobbering drvdata" ?

> >> Instead, let's return our
> >> 'dw_mipi_dsi' object and have callers pass that back to us for removal.
> >> 
> >> Signed-off-by: Brian Norris 
> > 
> > Wouldn't it be cleaner to embed the dw_mipi_dsi structure in the parent-
> > specific data structure (struct dw_mipi_dsi_stm and struct
> > dw_mipi_dsi_rockchip when the "[PATCH v3 0/5] Update ROCKCHIP DSI driver
> > that uses dw-mipi-dsi bridge" patch series will land) instead of
> > allocating it dynamically ? We would then have a single object to track.
> 
> I suppose we could do that too. But that would require exposing the
> whole layout of 'struct dw_mipi_dsi' to users. Do we want to sacrifice
> the enforced separation for a little bit of nicer object handling?

I certainly don't think we should go for spaghetti code with all objects 
accessing each other :) On the other hand, we're talking about C code, and we 
thus have no way to enforce access restrictions in the compiler, so it's a 
lost battle anyway. I don't see an issue with exposing the object in the sense 
of moving its definition to a header file if it results in cleaner code. I 
think we need to trust developers not to abuse internal APIs, and if they do, 
catch it during review.

> Also, this was modeled a bit after the similar rework needed to untangle
> the drvdata handling in the Rockchip analogix DP driver vs. the analogix
> bridge DP code:
> 
> [PATCH v6 03/10] drm/bridge: analogix: Do not use device's drvdata
> https://patchwork.kernel.org/patch/10015875/

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH 04/11] drm/bridge/synopsys: dw-hdmi: Export some PHY related functions

[Laurent Pinchart]

Hi Jernej,

Thank you for the patch.

On Saturday, 30 December 2017 23:01:56 EET Jernej Skrabec wrote:
> Parts of PHY code could be useful also for custom PHYs. For example,
> Allwinner A83T has custom PHY which is probably Synopsys gen2 PHY
> with few additional memory mapped registers, so most of the Synopsys PHY
> related code could be reused.
> 
> It turns out that even completely custom HDMI PHYs, such as the one
> found in Allwinner H3, can reuse some of those functions. This would
> suggest that (some?) functions exported in this commit are actually part
> of generic PHY interface and not really specific to Synopsys PHYs.

That's correct, those functions control the interface between the HDMI 
controller and the PHY. They're not specific to Synopsys PHYs, but they're 
specific to the PHY interface as designed by Synopsys.

> Export useful PHY functions.
> 
> Signed-off-by: Jernej Skrabec 
> ---
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 45 ---
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.h |  2 ++
>  include/drm/bridge/dw_hdmi.h  | 10 +++
>  3 files changed, 44 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index
> 7ca14d7325b5..67467d0b683a 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -1037,19 +1037,21 @@ static void dw_hdmi_phy_enable_svsret(struct dw_hdmi
> *hdmi, u8 enable) HDMI_PHY_CONF0_SVSRET_MASK);
>  }
> 
> -static void dw_hdmi_phy_gen2_pddq(struct dw_hdmi *hdmi, u8 enable)
> +void dw_hdmi_phy_gen2_pddq(struct dw_hdmi *hdmi, u8 enable)
>  {
>   hdmi_mask_writeb(hdmi, enable, HDMI_PHY_CONF0,
>HDMI_PHY_CONF0_GEN2_PDDQ_OFFSET,
>HDMI_PHY_CONF0_GEN2_PDDQ_MASK);
>  }
> +EXPORT_SYMBOL_GPL(dw_hdmi_phy_gen2_pddq);
> 
> -static void dw_hdmi_phy_gen2_txpwron(struct dw_hdmi *hdmi, u8 enable)
> +void dw_hdmi_phy_gen2_txpwron(struct dw_hdmi *hdmi, u8 enable)
>  {
>   hdmi_mask_writeb(hdmi, enable, HDMI_PHY_CONF0,
>HDMI_PHY_CONF0_GEN2_TXPWRON_OFFSET,
>HDMI_PHY_CONF0_GEN2_TXPWRON_MASK);
>  }
> +EXPORT_SYMBOL_GPL(dw_hdmi_phy_gen2_txpwron);
> 
>  static void dw_hdmi_phy_sel_data_en_pol(struct dw_hdmi *hdmi, u8 enable)
>  {
> @@ -1065,6 +1067,23 @@ static void dw_hdmi_phy_sel_interface_control(struct
> dw_hdmi *hdmi, u8 enable) HDMI_PHY_CONF0_SELDIPIF_MASK);
>  }
> 
> +void dw_hdmi_phy_gen2_reset(struct dw_hdmi *hdmi, u8 enable)
> +{
> + hdmi_mask_writeb(hdmi, enable, HDMI_MC_PHYRSTZ,
> +  HDMI_MC_PHYRSTZ_PHYRSTZ_OFFSET,
> +  HDMI_MC_PHYRSTZ_PHYRSTZ_MASK);
> +}
> +EXPORT_SYMBOL_GPL(dw_hdmi_phy_gen2_reset);
> +
> +void dw_hdmi_phy_set_slave_addr(struct dw_hdmi *hdmi)
> +{
> + hdmi_phy_test_clear(hdmi, 1);
> + hdmi_writeb(hdmi, HDMI_PHY_I2CM_SLAVE_ADDR_PHY_GEN2,
> + HDMI_PHY_I2CM_SLAVE_ADDR);
> + hdmi_phy_test_clear(hdmi, 0);
> +}
> +EXPORT_SYMBOL_GPL(dw_hdmi_phy_set_slave_addr);

Should the I2C address be passed as an argument ?

>  static void dw_hdmi_phy_power_off(struct dw_hdmi *hdmi)
>  {
>   const struct dw_hdmi_phy_data *phy = hdmi->phy.data;
> @@ -1204,15 +1223,12 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi)
>   dw_hdmi_phy_enable_svsret(hdmi, 1);
> 
>   /* PHY reset. The reset signal is active high on Gen2 PHYs. */
> - hdmi_writeb(hdmi, HDMI_MC_PHYRSTZ_PHYRSTZ, HDMI_MC_PHYRSTZ);
> - hdmi_writeb(hdmi, 0, HDMI_MC_PHYRSTZ);
> + dw_hdmi_phy_gen2_reset(hdmi, 1);
> + dw_hdmi_phy_gen2_reset(hdmi, 0);
> 
>   hdmi_writeb(hdmi, HDMI_MC_HEACPHY_RST_ASSERT, HDMI_MC_HEACPHY_RST);
> 
> - hdmi_phy_test_clear(hdmi, 1);
> - hdmi_writeb(hdmi, HDMI_PHY_I2CM_SLAVE_ADDR_PHY_GEN2,
> - HDMI_PHY_I2CM_SLAVE_ADDR);
> - hdmi_phy_test_clear(hdmi, 0);
> + dw_hdmi_phy_set_slave_addr(hdmi);
> 
>   /* Write to the PHY as configured by the platform */
>   if (pdata->configure_phy)
> @@ -1251,15 +1267,16 @@ static void dw_hdmi_phy_disable(struct dw_hdmi
> *hdmi, void *data) dw_hdmi_phy_power_off(hdmi);
>  }
> 
> -static enum drm_connector_status dw_hdmi_phy_read_hpd(struct dw_hdmi *hdmi,
> -   void *data)
> +enum drm_connector_status dw_hdmi_phy_read_hpd(struct dw_hdmi *hdmi,
> +void *data)
>  {
>   return hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_HPD ?
>   connector_status_connected : connector_status_disconnected;
>  }
> +EXPORT_SYMBOL_GPL(dw_hdmi_phy_read_hpd);
> 
> -static void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
> -bool force, bool disabled, bool rxsense)
> +void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
> + bool force, bool disabled, bool rxsense)
>  {
>   u8 old_mask = h

Re: [PATCH 01/19] drm/fourcc: Add a function to tell if the format embeds alpha

[Maxime Ripard]

Hi Laurent,

On Tue, Jan 09, 2018 at 02:29:58PM +0200, Laurent Pinchart wrote:
> On Tuesday, 9 January 2018 12:56:20 EET Maxime Ripard wrote:
> > There's a bunch of drivers that duplicate the same function to know if a
> > particular format embeds an alpha component or not.
> > 
> > Let's create a helper to avoid duplicating that logic.
> > 
> > Cc: Boris Brezillon 
> > Cc: Eric Anholt 
> > Cc: Inki Dae 
> > Cc: Joonyoung Shim 
> > Cc: Kyungmin Park 
> > Cc: Laurent Pinchart 
> > Cc: Mark Yao 
> > Cc: Seung-Woo Kim 
> > Signed-off-by: Maxime Ripard 
> > ---
> >  drivers/gpu/drm/drm_fourcc.c | 43 +-
> >  include/drm/drm_fourcc.h |  1 +-
> >  2 files changed, 44 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> > index 9c0152df45ad..6e6227d6a46b 100644
> > --- a/drivers/gpu/drm/drm_fourcc.c
> > +++ b/drivers/gpu/drm/drm_fourcc.c
> > @@ -348,3 +348,46 @@ int drm_format_plane_height(int height, uint32_t
> > format, int plane) return height / info->vsub;
> >  }
> >  EXPORT_SYMBOL(drm_format_plane_height);
> > +
> > +/**
> > + * drm_format_has_alpha - get whether the format embeds an alpha component
> > + * @format: pixel format (DRM_FORMAT_*)
> > + *
> > + * Returns:
> > + * true if the format embeds an alpha component, false otherwise.
> > + */
> > +bool drm_format_has_alpha(uint32_t format)
> > +{
> > +   switch (format) {
> > +   case DRM_FORMAT_ARGB:
> > +   case DRM_FORMAT_ABGR:
> > +   case DRM_FORMAT_RGBA:
> > +   case DRM_FORMAT_BGRA:
> > +   case DRM_FORMAT_ARGB1555:
> > +   case DRM_FORMAT_ABGR1555:
> > +   case DRM_FORMAT_RGBA5551:
> > +   case DRM_FORMAT_BGRA5551:
> > +   case DRM_FORMAT_ARGB:
> > +   case DRM_FORMAT_ABGR:
> > +   case DRM_FORMAT_RGBA:
> > +   case DRM_FORMAT_BGRA:
> > +   case DRM_FORMAT_ARGB2101010:
> > +   case DRM_FORMAT_ABGR2101010:
> > +   case DRM_FORMAT_RGBA1010102:
> > +   case DRM_FORMAT_BGRA1010102:
> > +   case DRM_FORMAT_AYUV:
> > +   case DRM_FORMAT_XRGB_A8:
> > +   case DRM_FORMAT_XBGR_A8:
> > +   case DRM_FORMAT_RGBX_A8:
> > +   case DRM_FORMAT_BGRX_A8:
> > +   case DRM_FORMAT_RGB888_A8:
> > +   case DRM_FORMAT_BGR888_A8:
> > +   case DRM_FORMAT_RGB565_A8:
> > +   case DRM_FORMAT_BGR565_A8:
> > +   return true;
> > +
> > +   default:
> > +   return false;
> > +   }
> > +}
> > +EXPORT_SYMBOL(drm_format_has_alpha);
> 
> How about adding the information to struct drm_format_info instead ? 
> drm_format_has_alpha() could then be implemented as
> 
> bool drm_format_has_alpha(uint32_t format)
> {
>   const struct drm_format_info *info;
> 
>   info = drm_format_info(format);
>   return info ? info->has_alpha : false;
> }

I considered it, and wasn't too sure about if adding more fields to
drm_format_info was ok. I can definitely do it that way.

> although drivers should really use the drm_framebuffer::format field directly 
> in most cases, so the helper might not be needed at all.

The drivers converted in my serie shouldn't be too hard to convert to
use drm_format_info directly, so that can be removed as well.

Maxime

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


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

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

[Benjamin Gaignard]

2018-01-09 12:56 GMT+01:00 Peter Rosin :
> On 2018-01-09 12:28, Philippe CORNU wrote:
>> Hi all,
>>
>> Do you think the patch is "acceptable" or should I change it somehow?
>> Any opinion is welcomed : )
>
> Maybe you should try Daniel Vetter? He was very helpful (thanks) when
> I worked on the clut changes...

Since it only impact stm driver, I have applied it on drm-misc-next.

Regards,
Benjamin

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

Re: [PATCH] drm/bridge/synopsis: stop clobbering drvdata

[Philippe CORNU]

Hi Archit, Andrzej & Laurent,

Regarding this patch from Brian, I think it could be nice to merge it 
(1xAcked-by, 2xReviewed-by).

Could you please have a look?

Only the small "typo" in the headline needs to be changed.

Many thanks,
Philippe :-)

On 11/28/2017 10:34 AM, Philippe CORNU wrote:
> Hi Brian,
> 
> On 11/28/2017 02:05 AM, Brian Norris wrote:
>> Bridge drivers/helpers shouldn't be clobbering the drvdata, since a
>> parent driver might need to own this. Instead, let's return our
>> 'dw_mipi_dsi' object and have callers pass that back to us for removal.
> 
> And many thanks for this cleanup.
> (please update the headline with "synopsys")
> 
> Successfully tested on stm.
> 
> Acked-by: Philippe Cornu 
> 
> Many thanks,
> Philippe :-)
>>
>> Signed-off-by: Brian Norris 
>> ---
>>   drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 36 
>> ++-
>>   drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 14 +++
>>   include/drm/bridge/dw_mipi_dsi.h  | 17 -
>>   3 files changed, 33 insertions(+), 34 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
>> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>> index d9cca4fd66ec..c39c7dce20ed 100644
>> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>> @@ -922,8 +922,6 @@ __dw_mipi_dsi_probe(struct platform_device *pdev,
>>   dsi->bridge.of_node = pdev->dev.of_node;
>>   #endif
>> -    dev_set_drvdata(dev, dsi);
>> -
>>   return dsi;
>>   }
>> @@ -935,23 +933,16 @@ static void __dw_mipi_dsi_remove(struct 
>> dw_mipi_dsi *dsi)
>>   /*
>>    * Probe/remove API, used from platforms based on the DRM bridge API.
>>    */
>> -int dw_mipi_dsi_probe(struct platform_device *pdev,
>> -  const struct dw_mipi_dsi_plat_data *plat_data)
>> +struct dw_mipi_dsi *
>> +dw_mipi_dsi_probe(struct platform_device *pdev,
>> +  const struct dw_mipi_dsi_plat_data *plat_data)
>>   {
>> -    struct dw_mipi_dsi *dsi;
>> -
>> -    dsi = __dw_mipi_dsi_probe(pdev, plat_data);
>> -    if (IS_ERR(dsi))
>> -    return PTR_ERR(dsi);
>> -
>> -    return 0;
>> +    return __dw_mipi_dsi_probe(pdev, plat_data);
>>   }
>>   EXPORT_SYMBOL_GPL(dw_mipi_dsi_probe);
>> -void dw_mipi_dsi_remove(struct platform_device *pdev)
>> +void dw_mipi_dsi_remove(struct dw_mipi_dsi *dsi)
>>   {
>> -    struct dw_mipi_dsi *dsi = platform_get_drvdata(pdev);
>> -
>>   mipi_dsi_host_unregister(&dsi->dsi_host);
>>   __dw_mipi_dsi_remove(dsi);
>> @@ -961,31 +952,30 @@ EXPORT_SYMBOL_GPL(dw_mipi_dsi_remove);
>>   /*
>>    * Bind/unbind API, used from platforms based on the component 
>> framework.
>>    */
>> -int dw_mipi_dsi_bind(struct platform_device *pdev, struct drm_encoder 
>> *encoder,
>> - const struct dw_mipi_dsi_plat_data *plat_data)
>> +struct dw_mipi_dsi *
>> +dw_mipi_dsi_bind(struct platform_device *pdev, struct drm_encoder 
>> *encoder,
>> + const struct dw_mipi_dsi_plat_data *plat_data)
>>   {
>>   struct dw_mipi_dsi *dsi;
>>   int ret;
>>   dsi = __dw_mipi_dsi_probe(pdev, plat_data);
>>   if (IS_ERR(dsi))
>> -    return PTR_ERR(dsi);
>> +    return dsi;
>>   ret = drm_bridge_attach(encoder, &dsi->bridge, NULL);
>>   if (ret) {
>> -    dw_mipi_dsi_remove(pdev);
>> +    dw_mipi_dsi_remove(dsi);
>>   DRM_ERROR("Failed to initialize bridge with drm\n");
>> -    return ret;
>> +    return ERR_PTR(ret);
>>   }
>> -    return 0;
>> +    return dsi;
>>   }
>>   EXPORT_SYMBOL_GPL(dw_mipi_dsi_bind);
>> -void dw_mipi_dsi_unbind(struct device *dev)
>> +void dw_mipi_dsi_unbind(struct dw_mipi_dsi *dsi)
>>   {
>> -    struct dw_mipi_dsi *dsi = dev_get_drvdata(dev);
>> -
>>   __dw_mipi_dsi_remove(dsi);
>>   }
>>   EXPORT_SYMBOL_GPL(dw_mipi_dsi_unbind);
>> diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c 
>> b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
>> index e5b6310240fe..7ed0ef7f6ec2 100644
>> --- a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
>> +++ b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
>> @@ -66,6 +66,7 @@ enum dsi_color {
>>   struct dw_mipi_dsi_stm {
>>   void __iomem *base;
>>   struct clk *pllref_clk;
>> +    struct dw_mipi_dsi *dsi;
>>   };
>>   static inline void dsi_write(struct dw_mipi_dsi_stm *dsi, u32 reg, 
>> u32 val)
>> @@ -318,21 +319,24 @@ static int dw_mipi_dsi_stm_probe(struct 
>> platform_device *pdev)
>>   dw_mipi_dsi_stm_plat_data.base = dsi->base;
>>   dw_mipi_dsi_stm_plat_data.priv_data = dsi;
>> -    ret = dw_mipi_dsi_probe(pdev, &dw_mipi_dsi_stm_plat_data);
>> -    if (ret) {
>> +    platform_set_drvdata(pdev, dsi);
>> +
>> +    dsi->dsi = dw_mipi_dsi_probe(pdev, &dw_mipi_dsi_stm_plat_data);
>> +    if (IS_ERR(dsi->dsi)) {
>>   DRM_ERROR("Failed to initialize mipi dsi host\n");
>>   clk_disable_unprepare(dsi->pllref_clk);
>> +    return PTR_ERR(dsi->dsi);
>>   }
>> -    return ret;
>> +    return 0;
>>   }
>>   sta

[Bug 104556] WARNING: CPU: 1 PID: 7288 at mm/slab_common.c:971 kmalloc_slab+0x5e/0x70

[bugzilla-daemon]

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

--- Comment #2 from Paul Menzel  ---
The system seems to hang afterward, even after killing the test. The X.Org X
server doesn’t start, and it doesn’t shut down.

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

Re: [PATCH] drm/virtio: Add window server support

[Tomeu Vizoso]

On 28 December 2017 at 12:53, Tomeu Vizoso  wrote:
> This is to allow clients running within VMs to be able to communicate
> with a compositor in the host. Clients will use the communication
> protocol that the compositor supports, and virtio-gpu will assist with
> making buffers available in both sides, and copying content as needed.

Here is the qemu side, a bit hackier atm:

https://gitlab.collabora.com/tomeu/qemu/commits/winsrv-wip

Regards,

Tomeu

> It is expected that a service in the guest will act as a proxy,
> interacting with virtio-gpu to support unmodified clients. For some
> features of the protocol, the hypervisor might have to intervene and
> also parse the protocol data to properly bridge resources. The following
> IOCTLs have been added to this effect:
>
> *_WINSRV_CONNECT: Opens a connection to the compositor in the host,
> returns a FD that represents this connection and on which the following
> IOCTLs can be used. Callers are expected to poll this FD for new
> messages from the compositor.
>
> *_WINSRV_TX: Asks the hypervisor to forward a message to the compositor
>
> *_WINSRV_RX: Returns all queued messages
>
> Alongside protocol data that is opaque to the kernel, the client can
> send file descriptors that reference GEM buffers allocated by
> virtio-gpu. The guest proxy is expected to figure out when a client is
> passing a FD that refers to shared memory in the guest and allocate a
> virtio-gpu buffer of the same size with DRM_VIRTGPU_RESOURCE_CREATE.
>
> When the client notifies the compositor that it can read from that buffer,
> the proxy should copy the contents from the SHM region to the virtio-gpu
> resource and call DRM_VIRTGPU_TRANSFER_TO_HOST.
>
> This has been tested with Wayland clients that make use of wl_shm to
> pass buffers to the compositor, but is expected to work similarly for X
> clients that make use of MIT-SHM with FD passing.
>
> v2: * Add padding to two virtio command structs
> * Properly cast two __user pointers (kbuild test robot)
>
> Signed-off-by: Tomeu Vizoso 
> Cc: Zach Reizner 
>
> ---
>
> Hi,
>
> this work is based on the virtio_wl driver in the ChromeOS kernel by
> Zach Reizner, currently at:
>
> https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.4/drivers/virtio/virtio_wl.c
>
> There's two features missing in this patch when compared with virtio_wl:
>
> * Allow the guest access directly host memory, without having to resort
> to TRANSFER_TO_HOST
>
> * Pass FDs from host to guest (Wayland specifies that the compositor
> shares keyboard data with the guest via a shared buffer)
>
> I plan to work on this next, but I would like to get some comments on
> the general approach so I can better choose which patch to follow.
>
> Thanks,
>
> Tomeu
> ---
>  drivers/gpu/drm/virtio/virtgpu_drv.h   |  39 -
>  drivers/gpu/drm/virtio/virtgpu_ioctl.c | 168 +++
>  drivers/gpu/drm/virtio/virtgpu_kms.c   |  58 +--
>  drivers/gpu/drm/virtio/virtgpu_vq.c| 285 
> -
>  include/uapi/drm/virtgpu_drm.h |  29 
>  include/uapi/linux/virtio_gpu.h|  41 +
>  6 files changed, 605 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h 
> b/drivers/gpu/drm/virtio/virtgpu_drv.h
> index da2fb585fea4..268b386e1232 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_drv.h
> +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
> @@ -178,6 +178,8 @@ struct virtio_gpu_device {
>
> struct virtio_gpu_queue ctrlq;
> struct virtio_gpu_queue cursorq;
> +   struct virtio_gpu_queue winsrv_rxq;
> +   struct virtio_gpu_queue winsrv_txq;
> struct kmem_cache *vbufs;
> bool vqs_ready;
>
> @@ -205,10 +207,32 @@ struct virtio_gpu_device {
>
>  struct virtio_gpu_fpriv {
> uint32_t ctx_id;
> +
> +   struct list_head winsrv_conns; /* list of virtio_gpu_winsrv_conn */
> +   spinlock_t winsrv_lock;
> +};
> +
> +struct virtio_gpu_winsrv_rx_qentry {
> +   struct virtio_gpu_winsrv_rx *cmd;
> +   struct list_head next;
> +};
> +
> +struct virtio_gpu_winsrv_conn {
> +   struct virtio_gpu_device *vgdev;
> +
> +   spinlock_t lock;
> +
> +   int fd;
> +   struct drm_file *drm_file;
> +
> +   struct list_head cmdq; /* queue of virtio_gpu_winsrv_rx_qentry */
> +   wait_queue_head_t cmdwq;
> +
> +   struct list_head next;
>  };
>
>  /* virtio_ioctl.c */
> -#define DRM_VIRTIO_NUM_IOCTLS 10
> +#define DRM_VIRTIO_NUM_IOCTLS 11
>  extern struct drm_ioctl_desc virtio_gpu_ioctls[DRM_VIRTIO_NUM_IOCTLS];
>
>  /* virtio_kms.c */
> @@ -318,9 +342,22 @@ virtio_gpu_cmd_resource_create_3d(struct 
> virtio_gpu_device *vgdev,
>  void virtio_gpu_ctrl_ack(struct virtqueue *vq);
>  void virtio_gpu_cursor_ack(struct virtqueue *vq);
>  void virtio_gpu_fence_ack(struct virtqueue *vq);
> +void virtio_gpu_winsrv_tx_ack(struct virtqueue *vq);
> +void virtio_gpu_winsrv_rx_read(struct virtqueue *vq);
>  void virtio_gpu_dequeue_ctrl_

Re: [PATCH 03/11] drm/bridge/synopsys: dw-hdmi: Enable workaround for v1.32a

[Laurent Pinchart]

Hi Jernej,

Thank you for the patch.

On Saturday, 30 December 2017 23:01:55 EET Jernej Skrabec wrote:
> Allwinner SoCs have dw hdmi controller v1.32a which exhibits same
> magenta line issue as i.MX6Q and i.MX6DL. Enable workaround for it.
> 
> Tests show that one iteration is enough.
> 
> Signed-off-by: Jernej Skrabec 

This does not break R-Car DU, so

Acked-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index
> a38db40ce990..7ca14d7325b5 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -1634,9 +1634,10 @@ static void dw_hdmi_clear_overflow(struct dw_hdmi
> *hdmi) * then write one of the FC registers several times.
>*
>* The number of iterations matters and depends on the HDMI TX revision
> -  * (and possibly on the platform). So far only i.MX6Q (v1.30a) and
> -  * i.MX6DL (v1.31a) have been identified as needing the workaround, with
> -  * 4 and 1 iterations respectively.
> +  * (and possibly on the platform). So far i.MX6Q (v1.30a), i.MX6DL
> +  * (v1.31a) and multiple Allwinner SoCs (v1.32a) have been identified
> +  * as needing the workaround, with 4 iterations for v1.30a and 1
> +  * iteration for others.
>*/
> 
>   switch (hdmi->version) {
> @@ -1644,6 +1645,7 @@ static void dw_hdmi_clear_overflow(struct dw_hdmi
> *hdmi) count = 4;
>   break;
>   case 0x131a:
> + case 0x132a:
>   count = 1;
>   break;
>   default:

-- 
Regards,

Laurent Pinchart

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

[Bug 104556] WARNING: CPU: 1 PID: 7288 at mm/slab_common.c:971 kmalloc_slab+0x5e/0x70

[bugzilla-daemon]

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

--- Comment #1 from Paul Menzel  ---
```
$ dmesg
[0.00] Linux version 4.14.12.mx64.200 (r...@orpheus.molgen.mpg.de) (gcc
version 5.3.0 (GCC)) #1 SMP Mon Jan 8 12:53:28 CET 2018
[0.00] Command line: BOOT_IMAGE=/boot/bzImage-4.14.12.mx64.200
crashkernel=256M root=LABEL=root ro console=ttyS1,115200n8 console=tty0
[0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point
registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR'
[0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[0.00] x86/fpu: xstate_offset[3]:  832, xstate_sizes[3]:   64
[0.00] x86/fpu: xstate_offset[4]:  896, xstate_sizes[4]:   64
[0.00] x86/fpu: Enabled xstate features 0x1f, context size is 960
bytes, using 'compacted' format.
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x000907ff] usable
[0.00] BIOS-e820: [mem 0x00090800-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x9082cfff] usable
[0.00] BIOS-e820: [mem 0x9082d000-0x9082dfff] ACPI NVS
[0.00] BIOS-e820: [mem 0x9082e000-0x90857fff] reserved
[0.00] BIOS-e820: [mem 0x90858000-0x908abfff] usable
[0.00] BIOS-e820: [mem 0x908ac000-0x910acfff] reserved
[0.00] BIOS-e820: [mem 0x910ad000-0x9db54fff] usable
[0.00] BIOS-e820: [mem 0x9db55000-0x9f2bbfff] reserved
[0.00] BIOS-e820: [mem 0x9f2bc000-0x9f309fff] ACPI data
[0.00] BIOS-e820: [mem 0x9f30a000-0x9fabefff] ACPI NVS
[0.00] BIOS-e820: [mem 0x9fabf000-0x9fffefff] reserved
[0.00] BIOS-e820: [mem 0x9000-0x9fff] usable
[0.00] BIOS-e820: [mem 0xa000-0xa00f] reserved
[0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved
[0.00] BIOS-e820: [mem 0xfe00-0xfe010fff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xff00-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00025c7f] usable
[0.00] NX (Execute Disable) protection: active
[0.00] random: fast init done
[0.00] SMBIOS 2.8 present.
[0.00] DMI: Dell Inc. OptiPlex 5040/0R790T, BIOS 1.2.7 01/15/2016
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] e820: last_pfn = 0x25c800 max_arch_pfn = 0x4
[0.00] MTRR default type: write-back
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 00C000 mask 7FC000 uncachable
[0.00]   1 base 00B000 mask 7FF000 uncachable
[0.00]   2 base 00A800 mask 7FF800 uncachable
[0.00]   3 base 00A400 mask 7FFC00 uncachable
[0.00]   4 base 00A200 mask 7FFE00 uncachable
[0.00]   5 base 00A180 mask 7FFF80 uncachable
[0.00]   6 disabled
[0.00]   7 disabled
[0.00]   8 disabled
[0.00]   9 disabled
[0.00] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT  
[0.00] e820: last_pfn = 0xa max_arch_pfn = 0x4
[0.00] found SMP MP-table at [mem 0x000fcdf0-0x000fcdff] mapped at
[ff200df0]
[0.00] Base memory trampoline at [8808a000] 8a000 size 24576
[0.00] Using GB pages for direct mapping
[0.00] BRK [0x02b6b000, 0x02b6bfff] PGTABLE
[0.00] BRK [0x02b6c000, 0x02b6cfff] PGTABLE
[0.00] BRK [0x02b6d000, 0x02b6dfff] PGTABLE
[0.00] BRK [0x02b6e000, 0x02b6efff] PGTABLE
[0.00] BRK [0x02b6f000, 0x02b6] PGTABLE
[0.00] BRK [0x02b7, 0x02b70fff] PGTABLE
[0.00] RAMDISK: [mem 0x375e7000-0x37aeafff]
[0.00] ACPI: Early table checksum verification disabled
[0.00] ACPI: RSDP 0x000F05B0 24 (v02 DELL  )
[0.00] ACPI: XSDT 0x9F2DC0A0 C4 (v01 DELL   CBX3
01072009 AMI  00010013)
[0.00] ACPI: FACP 0x9F2FE770 00010C (v05 DELL   CBX3
01072009 AMI  00010013)
[0.00] ACPI: DSD

[Bug 104556] WARNING: CPU: 1 PID: 7288 at mm/slab_common.c:971 kmalloc_slab+0x5e/0x70

[bugzilla-daemon]

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

Bug ID: 104556
   Summary: WARNING: CPU: 1 PID: 7288 at mm/slab_common.c:971
kmalloc_slab+0x5e/0x70
   Product: DRI
   Version: XOrg git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: pmenzel+bugs.freedesk...@molgen.mpg.de

With Linux 4.14.12 and libdrm 2.4.89, running `sudo tests/amdgpu/amdgpu_test
l`, it hangs at *gfx ring block test*, and the Linux messages below can be seen
running `dmesg`.

```
[  175.540929] [ cut here ]
[  175.540933] WARNING: CPU: 1 PID: 7288 at mm/slab_common.c:971
kmalloc_slab+0x5e/0x70
[  175.540934] Modules linked in: nfsv4 nfs 8021q garp mrp stp llc amdgpu ttm
drm_kms_helper cfbfillrect syscopyarea cfbimgblt sysfillrect sysimgblt hci_uart
fb_sys_fops cfbcopyarea fb font fbdev drm btqca btintel bluetooth wmi_bmof
video ecdh_generic wmi nfsd auth_rpcgss oid_registry nfs_acl lockd grace sunrpc
ipv6 autofs4 unix
[  175.540960] CPU: 1 PID: 7288 Comm: lt-amdgpu_test Not tainted
4.14.12.mx64.200 #1
[  175.540961] Hardware name: Dell Inc. OptiPlex 5040/0R790T, BIOS 1.2.7
01/15/2016
[  175.540961] task: 8802389b90c0 task.stack: c9000b724000
[  175.540963] RIP: 0010:kmalloc_slab+0x5e/0x70
[  175.540963] RSP: 0018:c9000b727928 EFLAGS: 00010246
[  175.540964] RAX:  RBX: 880250789008 RCX:
c9000b727a90
[  175.540965] RDX: 048c27c0 RSI:  RDI:
048c27c0
[  175.540965] RBP: c9000b727a90 R08: 880250789008 R09:
880250789038
[  175.540965] R10: 8802427426c8 R11:  R12:
014080c0
[  175.540966] R13: 048c27c0 R14: a0338314 R15:
8802427426c8
[  175.540966] FS:  7f56b969c700() GS:88025c48()
knlGS:
[  175.540967] CS:  0010 DS:  ES:  CR0: 80050033
[  175.540967] CR2: 7f56b96d1000 CR3: 00024a95e004 CR4:
003606e0
[  175.540968] DR0:  DR1:  DR2:

[  175.540968] DR3:  DR6: fffe0ff0 DR7:
0400
[  175.540968] Call Trace:
[  175.540971]  __kmalloc+0x23/0x240
[  175.541001]  amdgpu_vram_mgr_new+0xc4/0x2b0 [amdgpu]
[  175.541004]  ttm_bo_mem_space+0x111/0x4e0 [ttm]
[  175.541009]  ? add_hole+0xcc/0xf0 [drm]
[  175.541010]  ttm_bo_validate+0xab/0x120 [ttm]
[  175.541014]  ? drm_prime_handle_to_fd_ioctl+0x3e/0x50 [drm]
[  175.541016]  ttm_bo_init_reserved+0x343/0x400 [ttm]
[  175.541022]  amdgpu_bo_create_restricted+0x1db/0x460 [amdgpu]
[  175.541029]  ? amdgpu_fill_buffer+0x2e0/0x2e0 [amdgpu]
[  175.541036]  amdgpu_bo_create+0xbd/0x1b0 [amdgpu]
[  175.541043]  amdgpu_gem_object_create+0x76/0xe0 [amdgpu]
[  175.541050]  ? amdgpu_gem_object_close+0x1b0/0x1b0 [amdgpu]
[  175.541056]  amdgpu_gem_create_ioctl+0x84/0x100 [amdgpu]
[  175.541059]  drm_ioctl_kernel+0x65/0xb0 [drm]
[  175.541062]  drm_ioctl+0x28b/0x330 [drm]
[  175.541069]  ? amdgpu_gem_object_close+0x1b0/0x1b0 [amdgpu]
[  175.541070]  ? tty_write+0x1e6/0x2c0
[  175.541071]  ? n_tty_open+0xd0/0xd0
[  175.541076]  amdgpu_drm_ioctl+0x46/0x80 [amdgpu]
[  175.541078]  do_vfs_ioctl+0x8f/0x5b0
[  175.541079]  ? vfs_write+0x194/0x1b0
[  175.541080]  SyS_ioctl+0x3b/0x70
[  175.541081]  entry_SYSCALL_64_fastpath+0x13/0x6c
[  175.541082] RIP: 0033:0x7f56b86993e7
[  175.541083] RSP: 002b:7ffe44526408 EFLAGS: 0246
[  175.541083] Code: 82 f3 c3 48 85 ff b8 10 00 00 00 74 f4 48 83 ef 01 48 c1
ef 03 48 63 ff 0f be 87 c0 f6 46 82 eb d1 31 c0 81 e6 00 02 00 00 75 d6 <0f> ff
c3 48 8b 04 c5 c0 74 b3 82 c3 66 0f 1f 44 00 00 0f 1f 44 
[  175.541097] ---[ end trace bd4b3546ebd3d3ae ]---
[  175.541108] [drm:amdgpu_gem_object_create [amdgpu]] *ERROR* Failed to
allocate GEM object (1, 6, 4096, -12)
```

-- 
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 v5] drm/omap: plane zpos/zorder management improvements

[Laurent Pinchart]

Hi Peter,

Thank you for the patch.

On Tuesday, 9 January 2018 13:45:56 EET Peter Ujfalusi wrote:
> Use the plane index as default zpos for all planes. Even if the
> application is not setting zpos/zorder explicitly we will have unique zpos
> for each plane.
> 
> Planes with identical zpos value will result undefined behavior:
> disappearing planes, screen flickering and it is not supported by the
> hardware.
> 
> Enforce that all planes must have unique zpos on the given crtc by
> returning error when duplicate zpos value is requested.
> 
> Signed-off-by: Peter Ujfalusi 

Reviewed-by: Laurent Pinchart 

> ---
> Hi,
> 
> Changes since v4:
> - further simplify the zpos checking by using a mask and a single loop
> - Commit message has been extended
> 
> Changes since v3:
> - Use drm_plane_index() instead of storing the same index wothin omap_plane
>   struct
> - Optimize the zpos validation loop so we avoid extra checks.
> 
> Changes since v2:
> - The check for duplicate zpos is moved to omap_crtc
> 
> Changes since v1:
> - Dropped the zpos normalization related patches
> - New patch based on the discussion, see commit message.
> 
> Regards,
> Peter
> 
>  drivers/gpu/drm/omapdrm/omap_crtc.c  | 23 ++-
>  drivers/gpu/drm/omapdrm/omap_plane.c | 15 ---
>  2 files changed, 26 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c
> b/drivers/gpu/drm/omapdrm/omap_crtc.c index 1b8154e58d18..941a6440fc8e
> 100644
> --- a/drivers/gpu/drm/omapdrm/omap_crtc.c
> +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
> @@ -486,6 +486,27 @@ static void omap_crtc_mode_set_nofb(struct drm_crtc
> *crtc) }
>  }
> 
> +static int omap_crtc_validate_zpos(struct drm_crtc *crtc,
> +struct drm_crtc_state *state)
> +{
> + struct drm_plane *plane;
> + const struct drm_plane_state *pstate;
> + unsigned int zpos_mask = 0;
> +
> + /* Check the crts's planes against duplicated zpos value */
> + drm_atomic_crtc_state_for_each_plane_state(plane, pstate, state) {
> + if (zpos_mask & BIT(pstate->zpos)) {
> + DBG("crtc%u: zpos must be unique (zpos: %u)",
> + crtc->index, pstate->zpos);
> + return -EINVAL;
> + }
> +
> + zpos_mask |= BIT(pstate->zpos);
> + }
> +
> + return 0;
> +}
> +
>  static int omap_crtc_atomic_check(struct drm_crtc *crtc,
>   struct drm_crtc_state *state)
>  {
> @@ -509,7 +530,7 @@ static int omap_crtc_atomic_check(struct drm_crtc *crtc,
> omap_crtc_state->rotation = pri_state->rotation;
>   }
> 
> - return 0;
> + return omap_crtc_validate_zpos(crtc, state);
>  }
> 
>  static void omap_crtc_atomic_begin(struct drm_crtc *crtc,
> diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c
> b/drivers/gpu/drm/omapdrm/omap_plane.c index 7d789d1551a1..39f25210bef1
> 100644
> --- a/drivers/gpu/drm/omapdrm/omap_plane.c
> +++ b/drivers/gpu/drm/omapdrm/omap_plane.c
> @@ -97,8 +97,7 @@ static void omap_plane_atomic_disable(struct drm_plane
> *plane, struct omap_plane *omap_plane = to_omap_plane(plane);
> 
>   plane->state->rotation = DRM_MODE_ROTATE_0;
> - plane->state->zpos = plane->type == DRM_PLANE_TYPE_PRIMARY
> -? 0 : omap_plane->id;
> + plane->state->zpos = drm_plane_index(plane);
> 
>   priv->dispc_ops->ovl_enable(omap_plane->id, false);
>  }
> @@ -184,18 +183,12 @@ void omap_plane_install_properties(struct drm_plane
> *plane,
> 
>  static void omap_plane_reset(struct drm_plane *plane)
>  {
> - struct omap_plane *omap_plane = to_omap_plane(plane);
> -
>   drm_atomic_helper_plane_reset(plane);
>   if (!plane->state)
>   return;
> 
> - /*
> -  * Set the zpos default depending on whether we are a primary or overlay
> -  * plane.
> -  */
> - plane->state->zpos = plane->type == DRM_PLANE_TYPE_PRIMARY
> -? 0 : omap_plane->id;
> + /* Set the zpos to the plane index. */
> + plane->state->zpos = drm_plane_index(plane);
>  }
> 
>  static int omap_plane_atomic_set_property(struct drm_plane *plane,
> @@ -295,7 +288,7 @@ struct drm_plane *omap_plane_init(struct drm_device
> *dev, drm_plane_helper_add(plane, &omap_plane_helper_funcs);
> 
>   omap_plane_install_properties(plane, &plane->base);
> - drm_plane_create_zpos_property(plane, 0, 0, num_planes - 1);
> + drm_plane_create_zpos_property(plane, idx, 0, num_planes - 1);
> 
>   return plane;


-- 
Regards,

Laurent Pinchart

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

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

[Hans Verkuil]

First of all a Happy New Year for all of you!

And secondly: can this v5 patch series be reviewed/merged? It's been waiting
for that for a very long time now...

Regards,

Hans

On 12/11/17 09:57, Hans Verkuil wrote:
> Ping again. Added a CC to Ville whom I inexplicably forgot to add when
> I sent the v5 patch series.
> 
> Regards,
> 
>   Hans
> 
> On 01/12/17 08:23, Hans Verkuil wrote:
>> Ping!
>>
>> I really like to get this in for 4.16 so I can move forward with hooking
>> this up for nouveau/amd.
>>
>> Regards,
>>
>>  Hans
>>
>> On 11/20/2017 12:42 PM, Hans Verkuil wrote:
>>> This patch series adds support for the DisplayPort CEC-Tunneling-over-AUX
>>> feature. This patch series is based on the 4.14 mainline release but applies
>>> as well to drm-next.
>>>
>>> This patch series has been tested with my NUC7i5BNK, a Samsung USB-C to 
>>> HDMI adapter and a Club 3D DisplayPort MST Hub + modified UpTab DP-to-HDMI
>>> adapter (where the CEC pin is wired up).
>>>
>>> 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 or MegaChips MCDP2900), 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.
>>>
>>> Note that the current implementation does not support CEC over an MST hub.
>>> As far as I can see there is no mechanism defined in the DisplayPort
>>> standard to transport CEC interrupts over an MST device. It might be
>>> possible to do this through polling, but I have not been able to get that
>>> to work.
>>> --
>>>
>>> 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).
>>>
>>> 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.
>>>
>>> The main reason why this v5 is delayed by 2 months is due to the fact
>>> that I needed some dedicated time to investigate what happens when an
>>> MST hub is in use. It turns out that this is not working. There is no
>>> mechanism defined in the DisplayPort standard to transport the CEC
>>> interrupt back up the MST chain. I was actually able to send a CEC
>>> message but the interrupt that tells when the transmit finished is
>>> unavailable.
>>>
>>> I attempted to implement this via polling, but I got weird errors
>>> and was not able to read the DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1
>>> register. I decided to give up on this for now and just disable CEC
>>> for DP-to-HDMI adapters after an MST hub. I plan to revisit this
>>> later since it would be neat to make this work as well. Although it
>>> might not be possible at all.
>>>
>>> If anyone is interested, work-in-progress for this is here:
>>>
>>> https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=dp-cec-mst
>>>
>>> Note that I removed the Tested-by tag from Carlos Santa due to the
>>> almost complete rework of the third patch. Carlos, can you test this again?
>>>
>>> Regards,
>>>
>>> Hans
>>>
>>> Changes since v4:
>>>
>>> - Updated comment at the start of drm_dp_cec.c
>>> - Add edid pointer to drm_dp_cec_configure_adapter
>>> - Reworked the last patch (adding CEC to i915) based on Ville's comments
>>>   and my MST testing:
>>> - register/unregister CEC in intel_dp_connector_register/unregister
>>> - add comment and check if connector is registered in long_pulse
>>> - unregister CEC if an MST 'connector' is detected.
>>>
>>> ___
>>> dri-devel mailing list
>>> dri-devel@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>>>
>>
>> 

Re: [PATCH v5] drm/omap: plane zpos/zorder management improvements

[Daniel Vetter]

On Tue, Jan 09, 2018 at 01:45:56PM +0200, Peter Ujfalusi wrote:
> Use the plane index as default zpos for all planes. Even if the
> application is not setting zpos/zorder explicitly we will have unique zpos
> for each plane.
> 
> Planes with identical zpos value will result undefined behavior:
> disappearing planes, screen flickering and it is not supported by the
> hardware.
> 
> Enforce that all planes must have unique zpos on the given crtc by
> returning error when duplicate zpos value is requested.
> 
> Signed-off-by: Peter Ujfalusi 
> ---
> Hi,
> 
> Changes since v4:
> - further simplify the zpos checking by using a mask and a single loop
> - Commit message has been extended
> 
> Changes since v3:
> - Use drm_plane_index() instead of storing the same index wothin omap_plane
>   struct
> - Optimize the zpos validation loop so we avoid extra checks.
> 
> Changes since v2:
> - The check for duplicate zpos is moved to omap_crtc
> 
> Changes since v1:
> - Dropped the zpos normalization related patches
> - New patch based on the discussion, see commit message.

Sorry for jumping in late to the party, but except when you have a really,
really, really good reason for why omapdrm has to not normalize zpos like
the other drivers do in this case, then I think we should be consistent.

An inconsistent kms uapi is a lot worse than an uapi with some design
issues: The latter just means we eventually need v2, the former guarantees
we need v2.

Thanks, Daniel

> 
> Regards,
> Peter
> 
>  drivers/gpu/drm/omapdrm/omap_crtc.c  | 23 ++-
>  drivers/gpu/drm/omapdrm/omap_plane.c | 15 ---
>  2 files changed, 26 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
> b/drivers/gpu/drm/omapdrm/omap_crtc.c
> index 1b8154e58d18..941a6440fc8e 100644
> --- a/drivers/gpu/drm/omapdrm/omap_crtc.c
> +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
> @@ -486,6 +486,27 @@ static void omap_crtc_mode_set_nofb(struct drm_crtc 
> *crtc)
>   }
>  }
>  
> +static int omap_crtc_validate_zpos(struct drm_crtc *crtc,
> +struct drm_crtc_state *state)
> +{
> + struct drm_plane *plane;
> + const struct drm_plane_state *pstate;
> + unsigned int zpos_mask = 0;
> +
> + /* Check the crts's planes against duplicated zpos value */
> + drm_atomic_crtc_state_for_each_plane_state(plane, pstate, state) {
> + if (zpos_mask & BIT(pstate->zpos)) {
> + DBG("crtc%u: zpos must be unique (zpos: %u)",
> + crtc->index, pstate->zpos);
> + return -EINVAL;
> + }
> +
> + zpos_mask |= BIT(pstate->zpos);
> + }
> +
> + return 0;
> +}
> +
>  static int omap_crtc_atomic_check(struct drm_crtc *crtc,
>   struct drm_crtc_state *state)
>  {
> @@ -509,7 +530,7 @@ static int omap_crtc_atomic_check(struct drm_crtc *crtc,
>   omap_crtc_state->rotation = pri_state->rotation;
>   }
>  
> - return 0;
> + return omap_crtc_validate_zpos(crtc, state);
>  }
>  
>  static void omap_crtc_atomic_begin(struct drm_crtc *crtc,
> diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c 
> b/drivers/gpu/drm/omapdrm/omap_plane.c
> index 7d789d1551a1..39f25210bef1 100644
> --- a/drivers/gpu/drm/omapdrm/omap_plane.c
> +++ b/drivers/gpu/drm/omapdrm/omap_plane.c
> @@ -97,8 +97,7 @@ static void omap_plane_atomic_disable(struct drm_plane 
> *plane,
>   struct omap_plane *omap_plane = to_omap_plane(plane);
>  
>   plane->state->rotation = DRM_MODE_ROTATE_0;
> - plane->state->zpos = plane->type == DRM_PLANE_TYPE_PRIMARY
> -? 0 : omap_plane->id;
> + plane->state->zpos = drm_plane_index(plane);
>  
>   priv->dispc_ops->ovl_enable(omap_plane->id, false);
>  }
> @@ -184,18 +183,12 @@ void omap_plane_install_properties(struct drm_plane 
> *plane,
>  
>  static void omap_plane_reset(struct drm_plane *plane)
>  {
> - struct omap_plane *omap_plane = to_omap_plane(plane);
> -
>   drm_atomic_helper_plane_reset(plane);
>   if (!plane->state)
>   return;
>  
> - /*
> -  * Set the zpos default depending on whether we are a primary or overlay
> -  * plane.
> -  */
> - plane->state->zpos = plane->type == DRM_PLANE_TYPE_PRIMARY
> -? 0 : omap_plane->id;
> + /* Set the zpos to the plane index. */
> + plane->state->zpos = drm_plane_index(plane);
>  }
>  
>  static int omap_plane_atomic_set_property(struct drm_plane *plane,
> @@ -295,7 +288,7 @@ struct drm_plane *omap_plane_init(struct drm_device *dev,
>   drm_plane_helper_add(plane, &omap_plane_helper_funcs);
>  
>   omap_plane_install_properties(plane, &plane->base);
> - drm_plane_create_zpos_property(plane, 0, 0, num_planes - 1);
> + drm_plane_create_zpos_property(plane, idx, 0, num_planes - 1);
>  
>   return plane;
>  
> -- 
> Peter
> 
> Texas Instruments Finland Oy, Porkka

Re: [PATCH 1/2] drm/blend: Account also the primary plane of the crtc for normalized_zpos

[Daniel Vetter]

On Fri, Dec 22, 2017 at 05:15:05PM +0200, Peter Ujfalusi wrote:
> Hi,
> 
> On 2017-12-22 12:12, Ville Syrjälä wrote:
> > On Fri, Dec 22, 2017 at 11:16:47AM +0200, Tomi Valkeinen wrote:
> >> On 21/12/17 17:12, Ville Syrjälä wrote:
> >>
>  If the userspace knows this, then it knows which primary plane is for
>  which crtc, right?
> 
>  And if it doesn't know this, then the userspace cannot associate any
>  plane to any crtc (except what it configures itself).
> 
>  So... If using legacy modesetting (and non-universal planes), there's no
>  problem, primary planes are fixed and at low zpos. If using atomic
>  modesetting and universal planes, there's really no (default)
>  association between planes and crtcs, and "primary plane" doesn't have
>  much meaning. Is that correct?
> 
>  If so... Then I guess the atomic modesetting client essentially randomly
>  picks which plane it uses as a "root plane" (if it even needs such), and
>  which planes as overlay planes? If that's the case, then this patch
>  doesn't quite fix the issue...
> >>>
> >>> I'm not sure anyone has really thought how userspace would/should assign
> >>> planes to crtcs. My only idea so far has been the crtc and their
> >>> preferred primary planes should be registered in the same order. But
> >>> someone should then also implement that same policy in userspace when
> >>> it's trying to figure out which plane to use. There are other
> >>> heuristics it should probably use, like preferring to pick a primary
> >>> plane for any fullscreen surface.
> >>>
> >>> I guess from functional point of view it shouldn't matter which plane
> >>> you pick as long as the plane's user visible capabilities are
> >>> sufficient. But there might be user invisible power saving features and
> >>> whatnot that only work with specific planes. So from that point of view
> >>> maybe the order in which the planes get registered is important. Or we
> >>> could maybe come up with some kind of plane usage hints in the uapi
> >>> which could help userspace decide?
> >>
> >> I was thinking about this, and... maybe there isn't even any problem (at 
> >> least for OMAP). So lets say we set the default plane zpos to the plane 
> >> index, and that the primary planes are reserved first (i.e. have lower 
> >> zpos than overlay planes).
> >>
> >> We have three different cases:
> >>
> >> Legacy modesetting: No problems, primary plane is always at the bottom. 
> >> If the userspace uses 2+ overlay planes, it can expect the zpos to be 
> >> based on the plane id, or it can set the zpos.
> >>
> >> Atomic+Universal, the application uses one primary plane, and zero or 
> >> more overlay planes: No problems here, the situation is the same as for 
> >> legacy.
> >>
> >> Atomic+Universal, the application uses more than one primary plane, and 
> >> zero or more overlay planes: in this case the app _has_ to manage zpos, 
> >> because using two primary planes in a single screen, and expecting it to 
> >> work by default, doesn't make sense.
> >>
> >> If the above "rules" are valid, then there's no need for this patch.
> >>
> >> But one question I don't have a good answer is that why would we want to 
> >> normalize the zpos, instead of returning an error? If the above rules 
> >> are valid, I think returning an error is better than normalizing and 
> >> hiding the bad configuration.
> > 
> > IIRC I argued against the normalization, but some people really
> > wanted it for whatever reason.
> 
> OK, please ignore this series, I'll send a patch instead next year.

So now we end up with a bunch of kms drivers that normalize zpos, and a
bunch of others which rejects duplicated zpos.

That sounds even worse. Can we pls try to be consistent (even if it turns
out to be a not-so-great uapi decision, it's uapi, so let's not make
things worse by making it inconsistent).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 08/19] drm/rcar-du: Convert to the new generic alpha property

[Laurent Pinchart]

Hi Maxime,

Thank you for the patch.

On Tuesday, 9 January 2018 12:56:27 EET Maxime Ripard wrote:
> Now that we have support for per-plane alpha in the core, let's use it.
> 
> Cc: Laurent Pinchart 
> Signed-off-by: Maxime Ripard 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/rcar-du/rcar_du_drv.h   |  1 +-
>  drivers/gpu/drm/rcar-du/rcar_du_kms.c   |  5 +---
>  drivers/gpu/drm/rcar-du/rcar_du_plane.c | 15 +++--
>  drivers/gpu/drm/rcar-du/rcar_du_plane.h |  2 +-
>  drivers/gpu/drm/rcar-du/rcar_du_vsp.c   | 42 ++
>  drivers/gpu/drm/rcar-du/rcar_du_vsp.h   |  2 +-
>  6 files changed, 9 insertions(+), 58 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> b/drivers/gpu/drm/rcar-du/rcar_du_drv.h index f8cd79488ece..aff04adaae53
> 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> @@ -89,7 +89,6 @@ struct rcar_du_device {
>   struct rcar_du_vsp vsps[RCAR_DU_MAX_VSPS];
> 
>   struct {
> - struct drm_property *alpha;
>   struct drm_property *colorkey;
>   } props;
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> b/drivers/gpu/drm/rcar-du/rcar_du_kms.c index 566d1a948c8f..e1b5a7b460cc
> 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> @@ -417,11 +417,6 @@ static int rcar_du_encoders_init(struct rcar_du_device
> *rcdu)
> 
>  static int rcar_du_properties_init(struct rcar_du_device *rcdu)
>  {
> - rcdu->props.alpha =
> - drm_property_create_range(rcdu->ddev, 0, "alpha", 0, 255);
> - if (rcdu->props.alpha == NULL)
> - return -ENOMEM;
> -
>   /*
>* The color key is expressed as an RGB888 triplet stored in a 32-bit
>* integer in XRGB format. Bit 24 is used as a flag to disable (0)
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> b/drivers/gpu/drm/rcar-du/rcar_du_plane.c index 61833cc1c699..5b34e8092c8b
> 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> @@ -423,7 +423,7 @@ static void rcar_du_plane_setup_mode(struct
> rcar_du_group *rgrp, rcar_du_plane_write(rgrp, index, PnALPHAR,
> PnALPHAR_ABIT_0);
>   else
>   rcar_du_plane_write(rgrp, index, PnALPHAR,
> - PnALPHAR_ABIT_X | state->alpha);
> + PnALPHAR_ABIT_X | state->state.alpha);
> 
>   pnmr = PnMR_BM_MD | state->format->pnmr;
> 
> @@ -667,11 +667,11 @@ static void rcar_du_plane_reset(struct drm_plane
> *plane)
> 
>   state->hwindex = -1;
>   state->source = RCAR_DU_PLANE_MEMORY;
> - state->alpha = 255;
>   state->colorkey = RCAR_DU_COLORKEY_NONE;
>   state->state.zpos = plane->type == DRM_PLANE_TYPE_PRIMARY ? 0 : 1;
> 
>   plane->state = &state->state;
> + plane->state->alpha = 255;
>   plane->state->plane = plane;
>  }
> 
> @@ -683,9 +683,7 @@ static int rcar_du_plane_atomic_set_property(struct
> drm_plane *plane, struct rcar_du_plane_state *rstate =
> to_rcar_plane_state(state); struct rcar_du_device *rcdu =
> to_rcar_plane(plane)->group->dev;
> 
> - if (property == rcdu->props.alpha)
> - rstate->alpha = val;
> - else if (property == rcdu->props.colorkey)
> + if (property == rcdu->props.colorkey)
>   rstate->colorkey = val;
>   else
>   return -EINVAL;
> @@ -701,9 +699,7 @@ static int rcar_du_plane_atomic_get_property(struct
> drm_plane *plane, container_of(state, const struct rcar_du_plane_state,
> state);
>   struct rcar_du_device *rcdu = to_rcar_plane(plane)->group->dev;
> 
> - if (property == rcdu->props.alpha)
> - *val = rstate->alpha;
> - else if (property == rcdu->props.colorkey)
> + if (property == rcdu->props.colorkey)
>   *val = rstate->colorkey;
>   else
>   return -EINVAL;
> @@ -772,10 +768,9 @@ int rcar_du_planes_init(struct rcar_du_group *rgrp)
>   continue;
> 
>   drm_object_attach_property(&plane->plane.base,
> -rcdu->props.alpha, 255);
> - drm_object_attach_property(&plane->plane.base,
>  rcdu->props.colorkey,
>  RCAR_DU_COLORKEY_NONE);
> + drm_plane_create_alpha_property(&plane->plane, 255);
>   drm_plane_create_zpos_property(&plane->plane, 1, 1, 7);
>   }
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.h
> b/drivers/gpu/drm/rcar-du/rcar_du_plane.h index f62e09f195de..2dc793ebd1a2
> 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_plane.h
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.h
> @@ -50,7 +50,6 @@ static inline struct rcar_du_plane *to_rcar_plane(struct
> drm_plane *plane) * @state: base DRM plane state
>   * @format: information about the pixel format used by the plane
>   * @hwindex: 0-based hardware 

Re: [PATCH 05/19] drm/vc4: Use the alpha format helper

[Daniel Vetter]

On Tue, Jan 09, 2018 at 11:56:24AM +0100, Maxime Ripard wrote:
> Now that the core has a drm format helper to tell if a format embeds an
> alpha component in it, let's use it.
> 
> Cc: Eric Anholt 
> Signed-off-by: Maxime Ripard 

On patches 1-5:

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/vc4/vc4_plane.c | 19 +--
>  1 file changed, 9 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
> index 423a23ed8fc2..2c0e25128dcd 100644
> --- a/drivers/gpu/drm/vc4/vc4_plane.c
> +++ b/drivers/gpu/drm/vc4/vc4_plane.c
> @@ -85,40 +85,39 @@ static const struct hvs_format {
>   u32 drm; /* DRM_FORMAT_* */
>   u32 hvs; /* HVS_FORMAT_* */
>   u32 pixel_order;
> - bool has_alpha;
>   bool flip_cbcr;
>  } hvs_formats[] = {
>   {
>   .drm = DRM_FORMAT_XRGB, .hvs = HVS_PIXEL_FORMAT_RGBA,
> - .pixel_order = HVS_PIXEL_ORDER_ABGR, .has_alpha = false,
> + .pixel_order = HVS_PIXEL_ORDER_ABGR,
>   },
>   {
>   .drm = DRM_FORMAT_ARGB, .hvs = HVS_PIXEL_FORMAT_RGBA,
> - .pixel_order = HVS_PIXEL_ORDER_ABGR, .has_alpha = true,
> + .pixel_order = HVS_PIXEL_ORDER_ABGR,
>   },
>   {
>   .drm = DRM_FORMAT_ABGR, .hvs = HVS_PIXEL_FORMAT_RGBA,
> - .pixel_order = HVS_PIXEL_ORDER_ARGB, .has_alpha = true,
> + .pixel_order = HVS_PIXEL_ORDER_ARGB,
>   },
>   {
>   .drm = DRM_FORMAT_XBGR, .hvs = HVS_PIXEL_FORMAT_RGBA,
> - .pixel_order = HVS_PIXEL_ORDER_ARGB, .has_alpha = false,
> + .pixel_order = HVS_PIXEL_ORDER_ARGB,
>   },
>   {
>   .drm = DRM_FORMAT_RGB565, .hvs = HVS_PIXEL_FORMAT_RGB565,
> - .pixel_order = HVS_PIXEL_ORDER_XRGB, .has_alpha = false,
> + .pixel_order = HVS_PIXEL_ORDER_XRGB,
>   },
>   {
>   .drm = DRM_FORMAT_BGR565, .hvs = HVS_PIXEL_FORMAT_RGB565,
> - .pixel_order = HVS_PIXEL_ORDER_XBGR, .has_alpha = false,
> + .pixel_order = HVS_PIXEL_ORDER_XBGR,
>   },
>   {
>   .drm = DRM_FORMAT_ARGB1555, .hvs = HVS_PIXEL_FORMAT_RGBA5551,
> - .pixel_order = HVS_PIXEL_ORDER_ABGR, .has_alpha = true,
> + .pixel_order = HVS_PIXEL_ORDER_ABGR,
>   },
>   {
>   .drm = DRM_FORMAT_XRGB1555, .hvs = HVS_PIXEL_FORMAT_RGBA5551,
> - .pixel_order = HVS_PIXEL_ORDER_ABGR, .has_alpha = false,
> + .pixel_order = HVS_PIXEL_ORDER_ABGR,
>   },
>   {
>   .drm = DRM_FORMAT_YUV422,
> @@ -601,7 +600,7 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
>   /* Position Word 2: Source Image Size, Alpha Mode */
>   vc4_state->pos2_offset = vc4_state->dlist_count;
>   vc4_dlist_write(vc4_state,
> - VC4_SET_FIELD(format->has_alpha ?
> + VC4_SET_FIELD(drm_format_has_alpha(format->drm) ?
> SCALER_POS2_ALPHA_MODE_PIPELINE :
> SCALER_POS2_ALPHA_MODE_FIXED,
> SCALER_POS2_ALPHA_MODE) |
> -- 
> git-series 0.9.1
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [PATCH 06/19] drm/blend: Add a generic alpha property

[Laurent Pinchart]

Hi Maxime,

Thank you for the patch.

On Tuesday, 9 January 2018 12:56:25 EET Maxime Ripard wrote:
> Some drivers duplicate the logic to create a property to store a per-plane
> alpha.
> 
> Let's create a helper in order to move that to the core.
> 
> Cc: Boris Brezillon 
> Cc: Laurent Pinchart 
> Signed-off-by: Maxime Ripard 
> ---
>  Documentation/gpu/kms-properties.csv |  2 +-
>  drivers/gpu/drm/drm_atomic.c |  4 -
>  drivers/gpu/drm/drm_atomic_helper.c  |  1 +-
>  drivers/gpu/drm/drm_blend.c  | 32 +-
>  include/drm/drm_blend.h  |  1 +-
>  include/drm/drm_plane.h  |  6 +-
>  6 files changed, 45 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/gpu/kms-properties.csv
> b/Documentation/gpu/kms-properties.csv index 927b65e14219..a3c3969c1992
> 100644
> --- a/Documentation/gpu/kms-properties.csv
> +++ b/Documentation/gpu/kms-properties.csv
> @@ -99,5 +99,5 @@ radeon,DVI-I,“coherent”,RANGE,"Min=0, Max=1",Connector,TBD
> ,,"""underscan vborder""",RANGE,"Min=0, Max=128",Connector,TBD
>  ,Audio,“audio”,ENUM,"{ ""off"", ""on"", ""auto"" }",Connector,TBD
>  ,FMT Dithering,“dither”,ENUM,"{ ""off"", ""on"" }",Connector,TBD
> -rcar-du,Generic,"""alpha""",RANGE,"Min=0, Max=255",Plane,TBD
> +,,"""alpha""",RANGE,"Min=0, Max=255",Plane,Opacity of the plane from
> transparent (0) to opaque (255) ,,"""colorkey""",RANGE,"Min=0,
> Max=0x01ff",Plane,TBD

I think more documentation is needed. You should explain how the property 
operates and which formats it is applicable to. For instance you need to 
clarify what happens for format that contain an alpha component.

> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index c2da5585e201..ade18cf62c89 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -749,6 +749,8 @@ static int drm_atomic_plane_set_property(struct
> drm_plane *plane, state->src_w = val;
>   } else if (property == config->prop_src_h) {
>   state->src_h = val;
> + } else if (property == plane->alpha_property) {
> + state->alpha = val;
>   } else if (property == plane->rotation_property) {
>   if (!is_power_of_2(val & DRM_MODE_ROTATE_MASK))
>   return -EINVAL;
> @@ -810,6 +812,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
>   *val = state->src_w;
>   } else if (property == config->prop_src_h) {
>   *val = state->src_h;
> + } else if (property == plane->alpha_property) {
> + *val = state->alpha;
>   } else if (property == plane->rotation_property) {
>   *val = state->rotation;
>   } else if (property == plane->zpos_property) {
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c index 71d712f1b56a..018993df4c18
> 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -3372,6 +3372,7 @@ void drm_atomic_helper_plane_reset(struct drm_plane
> *plane)
> 
>   if (plane->state) {
>   plane->state->plane = plane;
> + plane->state->alpha = 255;

If you keep the ability to select an initial value other than fully opaque 
(see my comment below about that) you should reset to that value instead of 
hardcoding 255.

>   plane->state->rotation = DRM_MODE_ROTATE_0;
>   }
>  }
> diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> index 2e5e089dd912..8eea2a8af458 100644
> --- a/drivers/gpu/drm/drm_blend.c
> +++ b/drivers/gpu/drm/drm_blend.c
> @@ -104,6 +104,38 @@
>   */
> 
>  /**
> + * drm_plane_create_alpha_property - create a new alpha property
> + * @plane: drm plane
> + * @alpha: initial value of alpha, from 0 (transparent) to 255 (opaque)

Do you have a use case for initializing the alpha value to something else than 
fully opaque ?

> + * This function initializes a generic, mutable, alpha property and
> + * enables support for it in the DRM core.
> + *
> + * Drivers can then attach this property to their plane to enable
> + * support for configurable plane alpha.

The function attaches the property to the plane, is the documentation outdated 
?

> + * Returns:
> + * 0 on success, negative error code on failure.
> + */
> +int drm_plane_create_alpha_property(struct drm_plane *plane, u8 alpha)
> +{
> + struct drm_property *prop;
> +
> + prop = drm_property_create_range(plane->dev, 0, "alpha", 0, 255);

Do you think the 0-255 range will fit all use cases ?

> + if (!prop)
> + return -ENOMEM;
> +
> + drm_object_attach_property(&plane->base, prop, alpha);
> + plane->alpha_property = prop;
> +
> + if (plane->state)
> + plane->state->alpha = alpha;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_plane_create_alpha_property);
> +
> +/**
>   * drm_plane_create_rotation_property - create a new rotation property
>   * @plane: drm plane
>   * @rotation:

Re: [PATCH 06/19] drm/blend: Add a generic alpha property

[Daniel Vetter]

On Tue, Jan 09, 2018 at 11:56:25AM +0100, Maxime Ripard wrote:
> Some drivers duplicate the logic to create a property to store a per-plane
> alpha.
> 
> Let's create a helper in order to move that to the core.
> 
> Cc: Boris Brezillon 
> Cc: Laurent Pinchart 
> Signed-off-by: Maxime Ripard 

Do we have userspace for this? Is encoding a fixed 0-255 range really the
best idea?

I know other drivers have skimped on the rules here a bit ... But at least
internally (i.e. within the drm_plane_state) we probably should restrict
ourselves to u8. And this needs real docs (i.e. the full blend equation
drivers are supposed to implement).
-Daniel

> ---
>  Documentation/gpu/kms-properties.csv |  2 +-
>  drivers/gpu/drm/drm_atomic.c |  4 -
>  drivers/gpu/drm/drm_atomic_helper.c  |  1 +-
>  drivers/gpu/drm/drm_blend.c  | 32 +-
>  include/drm/drm_blend.h  |  1 +-
>  include/drm/drm_plane.h  |  6 +-
>  6 files changed, 45 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/gpu/kms-properties.csv 
> b/Documentation/gpu/kms-properties.csv
> index 927b65e14219..a3c3969c1992 100644
> --- a/Documentation/gpu/kms-properties.csv
> +++ b/Documentation/gpu/kms-properties.csv
> @@ -99,5 +99,5 @@ radeon,DVI-I,“coherent”,RANGE,"Min=0, Max=1",Connector,TBD
>  ,,"""underscan vborder""",RANGE,"Min=0, Max=128",Connector,TBD
>  ,Audio,“audio”,ENUM,"{ ""off"", ""on"", ""auto"" }",Connector,TBD
>  ,FMT Dithering,“dither”,ENUM,"{ ""off"", ""on"" }",Connector,TBD
> -rcar-du,Generic,"""alpha""",RANGE,"Min=0, Max=255",Plane,TBD
> +,,"""alpha""",RANGE,"Min=0, Max=255",Plane,Opacity of the plane from 
> transparent (0) to opaque (255)
>  ,,"""colorkey""",RANGE,"Min=0, Max=0x01ff",Plane,TBD
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index c2da5585e201..ade18cf62c89 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -749,6 +749,8 @@ static int drm_atomic_plane_set_property(struct drm_plane 
> *plane,
>   state->src_w = val;
>   } else if (property == config->prop_src_h) {
>   state->src_h = val;
> + } else if (property == plane->alpha_property) {
> + state->alpha = val;
>   } else if (property == plane->rotation_property) {
>   if (!is_power_of_2(val & DRM_MODE_ROTATE_MASK))
>   return -EINVAL;
> @@ -810,6 +812,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
>   *val = state->src_w;
>   } else if (property == config->prop_src_h) {
>   *val = state->src_h;
> + } else if (property == plane->alpha_property) {
> + *val = state->alpha;
>   } else if (property == plane->rotation_property) {
>   *val = state->rotation;
>   } else if (property == plane->zpos_property) {
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 71d712f1b56a..018993df4c18 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -3372,6 +3372,7 @@ void drm_atomic_helper_plane_reset(struct drm_plane 
> *plane)
>  
>   if (plane->state) {
>   plane->state->plane = plane;
> + plane->state->alpha = 255;
>   plane->state->rotation = DRM_MODE_ROTATE_0;
>   }
>  }
> diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> index 2e5e089dd912..8eea2a8af458 100644
> --- a/drivers/gpu/drm/drm_blend.c
> +++ b/drivers/gpu/drm/drm_blend.c
> @@ -104,6 +104,38 @@
>   */
>  
>  /**
> + * drm_plane_create_alpha_property - create a new alpha property
> + * @plane: drm plane
> + * @alpha: initial value of alpha, from 0 (transparent) to 255 (opaque)
> + *
> + * This function initializes a generic, mutable, alpha property and
> + * enables support for it in the DRM core.
> + *
> + * Drivers can then attach this property to their plane to enable
> + * support for configurable plane alpha.
> + *
> + * Returns:
> + * 0 on success, negative error code on failure.
> + */
> +int drm_plane_create_alpha_property(struct drm_plane *plane, u8 alpha)
> +{
> + struct drm_property *prop;
> +
> + prop = drm_property_create_range(plane->dev, 0, "alpha", 0, 255);
> + if (!prop)
> + return -ENOMEM;
> +
> + drm_object_attach_property(&plane->base, prop, alpha);
> + plane->alpha_property = prop;
> +
> + if (plane->state)
> + plane->state->alpha = alpha;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_plane_create_alpha_property);
> +
> +/**
>   * drm_plane_create_rotation_property - create a new rotation property
>   * @plane: drm plane
>   * @rotation: initial value of the rotation property
> diff --git a/include/drm/drm_blend.h b/include/drm/drm_blend.h
> index 17606026590b..5979a8fce453 100644
> --- a/include/drm/drm_blend.h
> +++ b/include/drm/drm_blend.h
> @@ -36,6 +36,7 @@ static inline bool drm_rotation_90_or_27

Re: [PATCH 07/19] drm/atmel-hclcdc: Convert to the new generic alpha property

[Boris Brezillon]

On Tue,  9 Jan 2018 11:56:26 +0100
Maxime Ripard  wrote:

> Now that we have support for per-plane alpha in the core, let's use it.
> 
> Cc: Boris Brezillon 

Acked-by: Boris Brezillon 

> Signed-off-by: Maxime Ripard 
> ---
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h| 13 +---
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 89 ++
>  2 files changed, 14 insertions(+), 88 deletions(-)
> 
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h 
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
> index 6833ee253cfa..704cac6399eb 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
> @@ -298,7 +298,6 @@ struct atmel_hlcdc_layer {
>  struct atmel_hlcdc_plane {
>   struct drm_plane base;
>   struct atmel_hlcdc_layer layer;
> - struct atmel_hlcdc_plane_properties *properties;
>  };
>  
>  static inline struct atmel_hlcdc_plane *
> @@ -345,18 +344,6 @@ struct atmel_hlcdc_dc_desc {
>  };
>  
>  /**
> - * Atmel HLCDC Plane properties.
> - *
> - * This structure stores plane property definitions.
> - *
> - * @alpha: alpha blending (or transparency) property
> - * @rotation: rotation property
> - */
> -struct atmel_hlcdc_plane_properties {
> - struct drm_property *alpha;
> -};
> -
> -/**
>   * Atmel HLCDC Display Controller.
>   *
>   * @desc: HLCDC Display Controller description
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c 
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> index 1a9318810a29..dbc508889e87 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> @@ -31,7 +31,6 @@
>   * @src_y: y buffer position
>   * @src_w: buffer width
>   * @src_h: buffer height
> - * @alpha: alpha blending of the plane
>   * @disc_x: x discard position
>   * @disc_y: y discard position
>   * @disc_w: discard width
> @@ -54,8 +53,6 @@ struct atmel_hlcdc_plane_state {
>   uint32_t src_w;
>   uint32_t src_h;
>  
> - u8 alpha;
> -
>   int disc_x;
>   int disc_y;
>   int disc_w;
> @@ -385,7 +382,7 @@ atmel_hlcdc_plane_update_general_settings(struct 
> atmel_hlcdc_plane *plane,
>   cfg |= ATMEL_HLCDC_LAYER_LAEN;
>   else
>   cfg |= ATMEL_HLCDC_LAYER_GAEN |
> -ATMEL_HLCDC_LAYER_GA(state->alpha);
> +ATMEL_HLCDC_LAYER_GA(state->base.alpha);
>   }
>  
>   if (state->disc_h && state->disc_w)
> @@ -553,7 +550,7 @@ atmel_hlcdc_plane_prepare_disc_area(struct drm_crtc_state 
> *c_state)
>  
>   if (!ovl_s->fb ||
>   drm_format_has_alpha(ovl_s->fb->format->format) ||
> - ovl_state->alpha != 255)
> + ovl_s->alpha != 255)
>   continue;
>  
>   /* TODO: implement a smarter hidden area detection */
> @@ -829,51 +826,18 @@ static void atmel_hlcdc_plane_destroy(struct drm_plane 
> *p)
>   drm_plane_cleanup(p);
>  }
>  
> -static int atmel_hlcdc_plane_atomic_set_property(struct drm_plane *p,
> -  struct drm_plane_state *s,
> -  struct drm_property *property,
> -  uint64_t val)
> -{
> - struct atmel_hlcdc_plane *plane = drm_plane_to_atmel_hlcdc_plane(p);
> - struct atmel_hlcdc_plane_properties *props = plane->properties;
> - struct atmel_hlcdc_plane_state *state =
> - drm_plane_state_to_atmel_hlcdc_plane_state(s);
> -
> - if (property == props->alpha)
> - state->alpha = val;
> - else
> - return -EINVAL;
> -
> - return 0;
> -}
> -
> -static int atmel_hlcdc_plane_atomic_get_property(struct drm_plane *p,
> - const struct drm_plane_state *s,
> - struct drm_property *property,
> - uint64_t *val)
> -{
> - struct atmel_hlcdc_plane *plane = drm_plane_to_atmel_hlcdc_plane(p);
> - struct atmel_hlcdc_plane_properties *props = plane->properties;
> - const struct atmel_hlcdc_plane_state *state =
> - container_of(s, const struct atmel_hlcdc_plane_state, base);
> -
> - if (property == props->alpha)
> - *val = state->alpha;
> - else
> - return -EINVAL;
> -
> - return 0;
> -}
> -
> -static int atmel_hlcdc_plane_init_properties(struct atmel_hlcdc_plane *plane,
> - struct atmel_hlcdc_plane_properties *props)
> +static int atmel_hlcdc_plane_init_properties(struct atmel_hlcdc_plane *plane)
>  {
>   const struct atmel_hlcdc_layer_desc *desc = plane->layer.desc;
>  
>   if (desc->type == ATMEL_HLCDC_OVERLAY_LAYER ||
> - desc->type == ATMEL_HLCDC_CURSOR_LAYER)
> - drm_object_attach_property(&plane->base.base,
> - 

Re: [PATCH 06/19] drm/blend: Add a generic alpha property

[Boris Brezillon]

On Tue,  9 Jan 2018 11:56:25 +0100
Maxime Ripard  wrote:

> Some drivers duplicate the logic to create a property to store a per-plane
> alpha.
> 
> Let's create a helper in order to move that to the core.
> 
> Cc: Boris Brezillon 

Reviewed-by: Boris Brezillon 

> Cc: Laurent Pinchart 
> Signed-off-by: Maxime Ripard 
> ---
>  Documentation/gpu/kms-properties.csv |  2 +-
>  drivers/gpu/drm/drm_atomic.c |  4 -
>  drivers/gpu/drm/drm_atomic_helper.c  |  1 +-
>  drivers/gpu/drm/drm_blend.c  | 32 +-
>  include/drm/drm_blend.h  |  1 +-
>  include/drm/drm_plane.h  |  6 +-
>  6 files changed, 45 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/gpu/kms-properties.csv 
> b/Documentation/gpu/kms-properties.csv
> index 927b65e14219..a3c3969c1992 100644
> --- a/Documentation/gpu/kms-properties.csv
> +++ b/Documentation/gpu/kms-properties.csv
> @@ -99,5 +99,5 @@ radeon,DVI-I,“coherent”,RANGE,"Min=0, Max=1",Connector,TBD
>  ,,"""underscan vborder""",RANGE,"Min=0, Max=128",Connector,TBD
>  ,Audio,“audio”,ENUM,"{ ""off"", ""on"", ""auto"" }",Connector,TBD
>  ,FMT Dithering,“dither”,ENUM,"{ ""off"", ""on"" }",Connector,TBD
> -rcar-du,Generic,"""alpha""",RANGE,"Min=0, Max=255",Plane,TBD
> +,,"""alpha""",RANGE,"Min=0, Max=255",Plane,Opacity of the plane from 
> transparent (0) to opaque (255)
>  ,,"""colorkey""",RANGE,"Min=0, Max=0x01ff",Plane,TBD
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index c2da5585e201..ade18cf62c89 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -749,6 +749,8 @@ static int drm_atomic_plane_set_property(struct drm_plane 
> *plane,
>   state->src_w = val;
>   } else if (property == config->prop_src_h) {
>   state->src_h = val;
> + } else if (property == plane->alpha_property) {
> + state->alpha = val;
>   } else if (property == plane->rotation_property) {
>   if (!is_power_of_2(val & DRM_MODE_ROTATE_MASK))
>   return -EINVAL;
> @@ -810,6 +812,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
>   *val = state->src_w;
>   } else if (property == config->prop_src_h) {
>   *val = state->src_h;
> + } else if (property == plane->alpha_property) {
> + *val = state->alpha;
>   } else if (property == plane->rotation_property) {
>   *val = state->rotation;
>   } else if (property == plane->zpos_property) {
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 71d712f1b56a..018993df4c18 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -3372,6 +3372,7 @@ void drm_atomic_helper_plane_reset(struct drm_plane 
> *plane)
>  
>   if (plane->state) {
>   plane->state->plane = plane;
> + plane->state->alpha = 255;
>   plane->state->rotation = DRM_MODE_ROTATE_0;
>   }
>  }
> diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
> index 2e5e089dd912..8eea2a8af458 100644
> --- a/drivers/gpu/drm/drm_blend.c
> +++ b/drivers/gpu/drm/drm_blend.c
> @@ -104,6 +104,38 @@
>   */
>  
>  /**
> + * drm_plane_create_alpha_property - create a new alpha property
> + * @plane: drm plane
> + * @alpha: initial value of alpha, from 0 (transparent) to 255 (opaque)
> + *
> + * This function initializes a generic, mutable, alpha property and
> + * enables support for it in the DRM core.
> + *
> + * Drivers can then attach this property to their plane to enable
> + * support for configurable plane alpha.
> + *
> + * Returns:
> + * 0 on success, negative error code on failure.
> + */
> +int drm_plane_create_alpha_property(struct drm_plane *plane, u8 alpha)
> +{
> + struct drm_property *prop;
> +
> + prop = drm_property_create_range(plane->dev, 0, "alpha", 0, 255);
> + if (!prop)
> + return -ENOMEM;
> +
> + drm_object_attach_property(&plane->base, prop, alpha);
> + plane->alpha_property = prop;
> +
> + if (plane->state)
> + plane->state->alpha = alpha;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_plane_create_alpha_property);
> +
> +/**
>   * drm_plane_create_rotation_property - create a new rotation property
>   * @plane: drm plane
>   * @rotation: initial value of the rotation property
> diff --git a/include/drm/drm_blend.h b/include/drm/drm_blend.h
> index 17606026590b..5979a8fce453 100644
> --- a/include/drm/drm_blend.h
> +++ b/include/drm/drm_blend.h
> @@ -36,6 +36,7 @@ static inline bool drm_rotation_90_or_270(unsigned int 
> rotation)
>   return rotation & (DRM_MODE_ROTATE_90 | DRM_MODE_ROTATE_270);
>  }
>  
> +int drm_plane_create_alpha_property(struct drm_plane *plane, u8 alpha);
>  int drm_plane_create_rotation_property(struct drm_plane *plane,
>  unsigned int rotation,
> 

Re: [PATCH 01/19] drm/fourcc: Add a function to tell if the format embeds alpha

[Laurent Pinchart]

Hi Maxime,

Thank you for the patch.

On Tuesday, 9 January 2018 12:56:20 EET Maxime Ripard wrote:
> There's a bunch of drivers that duplicate the same function to know if a
> particular format embeds an alpha component or not.
> 
> Let's create a helper to avoid duplicating that logic.
> 
> Cc: Boris Brezillon 
> Cc: Eric Anholt 
> Cc: Inki Dae 
> Cc: Joonyoung Shim 
> Cc: Kyungmin Park 
> Cc: Laurent Pinchart 
> Cc: Mark Yao 
> Cc: Seung-Woo Kim 
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/gpu/drm/drm_fourcc.c | 43 +-
>  include/drm/drm_fourcc.h |  1 +-
>  2 files changed, 44 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index 9c0152df45ad..6e6227d6a46b 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -348,3 +348,46 @@ int drm_format_plane_height(int height, uint32_t
> format, int plane) return height / info->vsub;
>  }
>  EXPORT_SYMBOL(drm_format_plane_height);
> +
> +/**
> + * drm_format_has_alpha - get whether the format embeds an alpha component
> + * @format: pixel format (DRM_FORMAT_*)
> + *
> + * Returns:
> + * true if the format embeds an alpha component, false otherwise.
> + */
> +bool drm_format_has_alpha(uint32_t format)
> +{
> + switch (format) {
> + case DRM_FORMAT_ARGB:
> + case DRM_FORMAT_ABGR:
> + case DRM_FORMAT_RGBA:
> + case DRM_FORMAT_BGRA:
> + case DRM_FORMAT_ARGB1555:
> + case DRM_FORMAT_ABGR1555:
> + case DRM_FORMAT_RGBA5551:
> + case DRM_FORMAT_BGRA5551:
> + case DRM_FORMAT_ARGB:
> + case DRM_FORMAT_ABGR:
> + case DRM_FORMAT_RGBA:
> + case DRM_FORMAT_BGRA:
> + case DRM_FORMAT_ARGB2101010:
> + case DRM_FORMAT_ABGR2101010:
> + case DRM_FORMAT_RGBA1010102:
> + case DRM_FORMAT_BGRA1010102:
> + case DRM_FORMAT_AYUV:
> + case DRM_FORMAT_XRGB_A8:
> + case DRM_FORMAT_XBGR_A8:
> + case DRM_FORMAT_RGBX_A8:
> + case DRM_FORMAT_BGRX_A8:
> + case DRM_FORMAT_RGB888_A8:
> + case DRM_FORMAT_BGR888_A8:
> + case DRM_FORMAT_RGB565_A8:
> + case DRM_FORMAT_BGR565_A8:
> + return true;
> +
> + default:
> + return false;
> + }
> +}
> +EXPORT_SYMBOL(drm_format_has_alpha);

How about adding the information to struct drm_format_info instead ? 
drm_format_has_alpha() could then be implemented as

bool drm_format_has_alpha(uint32_t format)
{
const struct drm_format_info *info;

info = drm_format_info(format);
return info ? info->has_alpha : false;
}

although drivers should really use the drm_framebuffer::format field directly 
in most cases, so the helper might not be needed at all.

> diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
> index 6942e84b6edd..e08fc22c5f78 100644
> --- a/include/drm/drm_fourcc.h
> +++ b/include/drm/drm_fourcc.h
> @@ -69,5 +69,6 @@ int drm_format_vert_chroma_subsampling(uint32_t format);
>  int drm_format_plane_width(int width, uint32_t format, int plane);
>  int drm_format_plane_height(int height, uint32_t format, int plane);
>  const char *drm_get_format_name(uint32_t format, struct drm_format_name_buf
> *buf);
> +bool drm_format_has_alpha(uint32_t format);
> 
>  #endif /* __DRM_FOURCC_H__ */

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH 02/19] drm/atmel-hlcdc: Use the alpha format helper

[Boris Brezillon]

On Tue,  9 Jan 2018 11:56:21 +0100
Maxime Ripard  wrote:

> Now that the core has a drm format helper to tell if a format embeds an
> alpha component in it, let's use it.
> 
> Cc: Boris Brezillon 

Acked-by: Boris Brezillon 

> Signed-off-by: Maxime Ripard 
> ---
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 20 ++
>  1 file changed, 3 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c 
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> index 703c2d13603f..1a9318810a29 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> @@ -194,20 +194,6 @@ static int atmel_hlcdc_format_to_plane_mode(u32 format, 
> u32 *mode)
>   return 0;
>  }
>  
> -static bool atmel_hlcdc_format_embeds_alpha(u32 format)
> -{
> - int i;
> -
> - for (i = 0; i < sizeof(format); i++) {
> - char tmp = (format >> (8 * i)) & 0xff;
> -
> - if (tmp == 'A')
> - return true;
> - }
> -
> - return false;
> -}
> -
>  static u32 heo_downscaling_xcoef[] = {
>   0x11343311,
>   0x00f7,
> @@ -395,7 +381,7 @@ atmel_hlcdc_plane_update_general_settings(struct 
> atmel_hlcdc_plane *plane,
>   cfg |= ATMEL_HLCDC_LAYER_OVR | ATMEL_HLCDC_LAYER_ITER2BL |
>  ATMEL_HLCDC_LAYER_ITER;
>  
> - if (atmel_hlcdc_format_embeds_alpha(format))
> + if (drm_format_has_alpha(format))
>   cfg |= ATMEL_HLCDC_LAYER_LAEN;
>   else
>   cfg |= ATMEL_HLCDC_LAYER_GAEN |
> @@ -566,7 +552,7 @@ atmel_hlcdc_plane_prepare_disc_area(struct drm_crtc_state 
> *c_state)
>   ovl_state = drm_plane_state_to_atmel_hlcdc_plane_state(ovl_s);
>  
>   if (!ovl_s->fb ||
> - atmel_hlcdc_format_embeds_alpha(ovl_s->fb->format->format) 
> ||
> + drm_format_has_alpha(ovl_s->fb->format->format) ||
>   ovl_state->alpha != 255)
>   continue;
>  
> @@ -769,7 +755,7 @@ static int atmel_hlcdc_plane_atomic_check(struct 
> drm_plane *p,
>  
>   if ((state->crtc_h != state->src_h || state->crtc_w != state->src_w) &&
>   (!desc->layout.memsize ||
> -  atmel_hlcdc_format_embeds_alpha(state->base.fb->format->format)))
> +  drm_format_has_alpha(state->base.fb->format->format)))
>   return -EINVAL;
>  
>   if (state->crtc_x < 0 || state->crtc_y < 0)

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

Re: [PATCH 01/19] drm/fourcc: Add a function to tell if the format embeds alpha

[Boris Brezillon]

On Tue,  9 Jan 2018 11:56:20 +0100
Maxime Ripard  wrote:

> There's a bunch of drivers that duplicate the same function to know if a
> particular format embeds an alpha component or not.
> 
> Let's create a helper to avoid duplicating that logic.
> 
> Cc: Boris Brezillon 

Reviewed-by: Boris Brezillon 

> Cc: Eric Anholt 
> Cc: Inki Dae 
> Cc: Joonyoung Shim 
> Cc: Kyungmin Park 
> Cc: Laurent Pinchart 
> Cc: Mark Yao 
> Cc: Seung-Woo Kim 
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/gpu/drm/drm_fourcc.c | 43 +-
>  include/drm/drm_fourcc.h |  1 +-
>  2 files changed, 44 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index 9c0152df45ad..6e6227d6a46b 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -348,3 +348,46 @@ int drm_format_plane_height(int height, uint32_t format, 
> int plane)
>   return height / info->vsub;
>  }
>  EXPORT_SYMBOL(drm_format_plane_height);
> +
> +/**
> + * drm_format_has_alpha - get whether the format embeds an alpha component
> + * @format: pixel format (DRM_FORMAT_*)
> + *
> + * Returns:
> + * true if the format embeds an alpha component, false otherwise.
> + */
> +bool drm_format_has_alpha(uint32_t format)
> +{
> + switch (format) {
> + case DRM_FORMAT_ARGB:
> + case DRM_FORMAT_ABGR:
> + case DRM_FORMAT_RGBA:
> + case DRM_FORMAT_BGRA:
> + case DRM_FORMAT_ARGB1555:
> + case DRM_FORMAT_ABGR1555:
> + case DRM_FORMAT_RGBA5551:
> + case DRM_FORMAT_BGRA5551:
> + case DRM_FORMAT_ARGB:
> + case DRM_FORMAT_ABGR:
> + case DRM_FORMAT_RGBA:
> + case DRM_FORMAT_BGRA:
> + case DRM_FORMAT_ARGB2101010:
> + case DRM_FORMAT_ABGR2101010:
> + case DRM_FORMAT_RGBA1010102:
> + case DRM_FORMAT_BGRA1010102:
> + case DRM_FORMAT_AYUV:
> + case DRM_FORMAT_XRGB_A8:
> + case DRM_FORMAT_XBGR_A8:
> + case DRM_FORMAT_RGBX_A8:
> + case DRM_FORMAT_BGRX_A8:
> + case DRM_FORMAT_RGB888_A8:
> + case DRM_FORMAT_BGR888_A8:
> + case DRM_FORMAT_RGB565_A8:
> + case DRM_FORMAT_BGR565_A8:
> + return true;
> +
> + default:
> + return false;
> + }
> +}
> +EXPORT_SYMBOL(drm_format_has_alpha);
> diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
> index 6942e84b6edd..e08fc22c5f78 100644
> --- a/include/drm/drm_fourcc.h
> +++ b/include/drm/drm_fourcc.h
> @@ -69,5 +69,6 @@ int drm_format_vert_chroma_subsampling(uint32_t format);
>  int drm_format_plane_width(int width, uint32_t format, int plane);
>  int drm_format_plane_height(int height, uint32_t format, int plane);
>  const char *drm_get_format_name(uint32_t format, struct drm_format_name_buf 
> *buf);
> +bool drm_format_has_alpha(uint32_t format);
>  
>  #endif /* __DRM_FOURCC_H__ */

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

[Bug 104555] RX 560 DPM auto - driver doesn't reliably set high clocks, causing stutter in mpv

[bugzilla-daemon]

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

Bug ID: 104555
   Summary: RX 560 DPM auto - driver doesn't reliably set high
clocks, causing stutter in mpv
   Product: DRI
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: tempel.jul...@gmail.com

When I use modest quality settings in mpv (0.28.0), the result is stuttery when
power_dpm_force_performance_level = auto.
The stuttering completely disappears when I set
power_dpm_force_performance_level = high.

Modest mpv settings would be these:
profile=gpu-hq
video-sync=display-resample
interpolation
tscale=linear

The stuttering isn't recognized by mpv's stats, so we unfortunately have to
judge with eyes (thus cheap interpolation is enabled, so result should be
smooth regardless of refreshrate).
It's very obvious with camera pans and it's most severe when I do any 2160p
60fps video downscaling to 1440p (in fullscreen on Xorg without compositor).

This happens with Linux 4.14.12 and 4.15 RC7, I didn't test older kernels.

Display is 2560x1440 75Hz, but it also happens at 60Hz (so probably regardless
of refreshrate or timings).

(my first report here, so plz don't tear it apart in case something's not to
your satisfaction)

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

[PATCH v5] drm/omap: plane zpos/zorder management improvements

[Peter Ujfalusi]

Use the plane index as default zpos for all planes. Even if the
application is not setting zpos/zorder explicitly we will have unique zpos
for each plane.

Planes with identical zpos value will result undefined behavior:
disappearing planes, screen flickering and it is not supported by the
hardware.

Enforce that all planes must have unique zpos on the given crtc by
returning error when duplicate zpos value is requested.

Signed-off-by: Peter Ujfalusi 
---
Hi,

Changes since v4:
- further simplify the zpos checking by using a mask and a single loop
- Commit message has been extended

Changes since v3:
- Use drm_plane_index() instead of storing the same index wothin omap_plane
  struct
- Optimize the zpos validation loop so we avoid extra checks.

Changes since v2:
- The check for duplicate zpos is moved to omap_crtc

Changes since v1:
- Dropped the zpos normalization related patches
- New patch based on the discussion, see commit message.

Regards,
Peter

 drivers/gpu/drm/omapdrm/omap_crtc.c  | 23 ++-
 drivers/gpu/drm/omapdrm/omap_plane.c | 15 ---
 2 files changed, 26 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index 1b8154e58d18..941a6440fc8e 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -486,6 +486,27 @@ static void omap_crtc_mode_set_nofb(struct drm_crtc *crtc)
}
 }
 
+static int omap_crtc_validate_zpos(struct drm_crtc *crtc,
+  struct drm_crtc_state *state)
+{
+   struct drm_plane *plane;
+   const struct drm_plane_state *pstate;
+   unsigned int zpos_mask = 0;
+
+   /* Check the crts's planes against duplicated zpos value */
+   drm_atomic_crtc_state_for_each_plane_state(plane, pstate, state) {
+   if (zpos_mask & BIT(pstate->zpos)) {
+   DBG("crtc%u: zpos must be unique (zpos: %u)",
+   crtc->index, pstate->zpos);
+   return -EINVAL;
+   }
+
+   zpos_mask |= BIT(pstate->zpos);
+   }
+
+   return 0;
+}
+
 static int omap_crtc_atomic_check(struct drm_crtc *crtc,
struct drm_crtc_state *state)
 {
@@ -509,7 +530,7 @@ static int omap_crtc_atomic_check(struct drm_crtc *crtc,
omap_crtc_state->rotation = pri_state->rotation;
}
 
-   return 0;
+   return omap_crtc_validate_zpos(crtc, state);
 }
 
 static void omap_crtc_atomic_begin(struct drm_crtc *crtc,
diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c 
b/drivers/gpu/drm/omapdrm/omap_plane.c
index 7d789d1551a1..39f25210bef1 100644
--- a/drivers/gpu/drm/omapdrm/omap_plane.c
+++ b/drivers/gpu/drm/omapdrm/omap_plane.c
@@ -97,8 +97,7 @@ static void omap_plane_atomic_disable(struct drm_plane *plane,
struct omap_plane *omap_plane = to_omap_plane(plane);
 
plane->state->rotation = DRM_MODE_ROTATE_0;
-   plane->state->zpos = plane->type == DRM_PLANE_TYPE_PRIMARY
-  ? 0 : omap_plane->id;
+   plane->state->zpos = drm_plane_index(plane);
 
priv->dispc_ops->ovl_enable(omap_plane->id, false);
 }
@@ -184,18 +183,12 @@ void omap_plane_install_properties(struct drm_plane 
*plane,
 
 static void omap_plane_reset(struct drm_plane *plane)
 {
-   struct omap_plane *omap_plane = to_omap_plane(plane);
-
drm_atomic_helper_plane_reset(plane);
if (!plane->state)
return;
 
-   /*
-* Set the zpos default depending on whether we are a primary or overlay
-* plane.
-*/
-   plane->state->zpos = plane->type == DRM_PLANE_TYPE_PRIMARY
-  ? 0 : omap_plane->id;
+   /* Set the zpos to the plane index. */
+   plane->state->zpos = drm_plane_index(plane);
 }
 
 static int omap_plane_atomic_set_property(struct drm_plane *plane,
@@ -295,7 +288,7 @@ struct drm_plane *omap_plane_init(struct drm_device *dev,
drm_plane_helper_add(plane, &omap_plane_helper_funcs);
 
omap_plane_install_properties(plane, &plane->base);
-   drm_plane_create_zpos_property(plane, 0, 0, num_planes - 1);
+   drm_plane_create_zpos_property(plane, idx, 0, num_planes - 1);
 
return plane;
 
-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

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

[Philippe CORNU]

Hi all,

Do you think the patch is "acceptable" or should I change it somehow?
Any opinion is welcomed : )

Many thanks,
Philippe :-)

On 11/24/2017 02:54 PM, Philippe CORNU wrote:
> Hi Peter,
> 
> On 11/13/2017 11:40 AM, Philippe CORNU wrote:
>> Hi Peter,
>>
>> On 11/12/2017 01:31 PM, Peter Rosin wrote:
>>> On 2017-11-10 17:12, Philippe CORNU wrote:
 Hi Peter,

 On 11/07/2017 05:34 PM, Peter Rosin wrote:
> On 2017-11-07 16:53, Philippe CORNU wrote:
>> + Peter
>>
>> Hi Peter,
>>
>> CLUT support on STM32 has been removed thanks to your clean up patch
>
> Support is a bit strong for what I thought was a dead function, or
> are you saying that it used to work before my series? Really sorry
> if that is the case!

 As I wrote in the previous related thread
 (https://lists.freedesktop.org/archives/dri-devel/2017-June/145070.html), 

 STM32 chipsets supports 8-bit CLUT mode but this driver version does 
 not
 support it "yet"...

 So, no worry regarding your clean up, I gave you an "acked-by" for 
 that : )
>>>
>>> Ok, good. Thanks for clearing that up!
>>>
>
> Anyway, the function I removed seemed to indicate that the hardware
> could handle a separate clut for each layer, but your new version
> does not. Why is that?

 Yes I confirm the clut support is available for each layer... but I
 thought the gamma_lut was only at the crtc level, not at layer level...
 Maybe I am wrong.
 Moreover, small test applications I used play only with clut at crtc
 level...

 Anyway, could you please help me to "find" a per-layer clut
 implementation because when I read "crtc->state->gamma_lut->data" it
 looks like gamma_lut is per crtc, not per plane...? or maybe I have to
 add extra properties for that...
>>>
>>> I wasn't clear enough. Yes, there is to my knowledge only one clut,
>>> not one per plane. What I noticed was that the function I removed
>>> seemed to touch clut registers for multiple layers, but your new
>>> function appears to only touch registers for one layer. So, I
>>> wondered if the "one and only" clut needed to be copied to the
>>> registers for the other layers, or if the old dead code was simply
>>> confused. Clearer?
>>>
>>
>> The old code was a generic helper function (ie. for all layers) but 
>> used only for the 1st layer. So, we could say that "old dead code was 
>> simply confused" :-)
>>
>> When I put back the clut support in this patch, I decided to update 
>> only the 1st layer (because there is no API for handling it on other 
>> layers). I also decided to not re-use the former generic helper 
>> function as the update loop is pretty small.
>>
>> This patch offers the clut mode feature for fbdev (only one plane in 
>> fbdev) and for drm (single plane for many use cases, 2nd plane being 
>> used mostly for video...)
>>
>> If tomorrow the API offers clut support per plane, the update loop 
>> will be moved to the plane update function, means the generic helper 
>> function will not be require anymore too.
> 
>  From the explanations above, do you think the patch is "acceptable" or 
> should I change it somehow?
> What is your opinion?
> Many thanks,
> Philippe :-)
> 
>>
>> Many thanks
>> Philippe :)
>>
>>> Cheers.
>>> Peter
>>>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 0/6] iommu/arm-smmu: Add runtime pm/sleep support

[Rafael J. Wysocki]

On Tuesday, January 9, 2018 11:01:43 AM CET Vivek Gautam wrote:
> This series provides the support for turning on the arm-smmu's
> clocks/power domains using runtime pm. This is done using the
> recently introduced device links patches, which lets the smmu's
> runtime to follow the master's runtime pm, so the smmu remains
> powered only when the masters use it.
> 
> It also adds support for Qcom's arm-smmu-v2 variant that
> has different clocks and power requirements.
> 
> Took some reference from the exynos runtime patches [2].
> 
> Previous version of the patchset [1].
> 
> After much discussion [4] over the use of pm_runtime_get/put() in
> .unmap op path for the arm-smmu, and after disussing over more than
> a couple of approaches to address this, we are putting forward the
> changes *without* using pm_runtime APIs in 'unmap'. Rather, letting
> the client device take the control of powering on/off the connected
> iommu through pm_runtime_get(put)_suppliers() APIs for the scnerios
> when the iommu power can't be directly controlled by clients through
> device links.
> Rafael has agreed to export the suppliers APIs [5].
> 
> [V5]
>* Dropped runtime pm calls from "arm_smmu_unmap" op as discussed over
>  the list [4] for the last patch series.
>* Added a patch to export pm_runtime_get/put_suppliers() APIs to the
>  series as agreed with Rafael [5].
>* Added the related patch for msm drm iommu layer to use
>  pm_runtime_get/put_suppliers() APIs in msm_mmu_funcs.
>* Dropped arm-mmu500 clock patch since that would break existing
>  platforms.
>* Changed compatible 'qcom,msm8996-smmu-v2' to 'qcom,smmu-v2' to reflect
>  the IP version rather than the platform on which it is used.
>  The same IP is used across multiple platforms including msm8996,
>  and sdm845 etc.
>* Using clock bulk APIs to handle the clocks available to the IP as
>  suggested by Stephen Boyd.
>* The first patch in v4 version of the patch-series:
>  ("iommu/arm-smmu: Fix the error path in arm_smmu_add_device") has
>  already made it to mainline.
> 
> [V4]
>* Reworked the clock handling part. We now take clock names as data
>  in the driver for supported compatible versions, and loop over them
>  to get, enable, and disable the clocks.
>* Using qcom,msm8996 based compatibles for bindings instead of a generic
>  qcom compatible.
>* Refactor MMU500 patch to just add the necessary clock names data and
>  corresponding bindings.
>* Added the pm_runtime_get/put() calls in .unmap iommu op (fix added by
>  Stanimir on top of previous patch version.
>* Added a patch to fix error path in arm_smmu_add_device()
>* Removed patch 3/5 of V3 patch series that added qcom,smmu-v2 bindings.
> 
> [V3]
>* Reworked the patches to keep the clocks init/enabling function
>  separately for each compatible.
> 
>* Added clocks bindings for MMU40x/500.
> 
>* Added a new compatible for qcom,smmu-v2 implementation and
>  the clock bindings for the same.
> 
>* Rebased on top of 4.11-rc1
> 
> [V2]
>* Split the patches little differently.
> 
>* Addressed comments.
> 
>* Removed the patch #4 [3] from previous post
>  for arm-smmu context save restore. Planning to
>  post this separately after reworking/addressing Robin's
>  feedback.
> 
>* Reversed the sequence to disable clocks than enabling.
>  This was required for those cases where the
>  clocks are populated in a dependent order from DT.
> 
> [1] https://www.spinics.net/lists/arm-kernel/msg567488.html
> [2] https://lkml.org/lkml/2016/10/20/70
> [3] https://patchwork.kernel.org/patch/9389717/
> [4] https://patchwork.kernel.org/patch/9827825/
> [5] https://patchwork.kernel.org/patch/10102445/
> 
> Sricharan R (3):
>   iommu/arm-smmu: Add pm_runtime/sleep ops
>   iommu/arm-smmu: Invoke pm_runtime during probe, add/remove device
>   iommu/arm-smmu: Add the device_link between masters and smmu
> 
> Vivek Gautam (3):
>   base: power: runtime: Export pm_runtime_get/put_suppliers
>   iommu/arm-smmu: Add support for qcom,smmu-v2 variant
>   drm/msm: iommu: Replace runtime calls with runtime suppliers
> 
>  .../devicetree/bindings/iommu/arm,smmu.txt |  35 ++
>  drivers/base/power/runtime.c   |   2 +
>  drivers/gpu/drm/msm/msm_iommu.c|  16 +--
>  drivers/iommu/arm-smmu.c   | 124 
> -
>  4 files changed, 163 insertions(+), 14 deletions(-)

I need some time to review the series.

Thanks,
Rafael

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

[PATCH 15/19] drm/sun4i: backend: Check for the number of alpha planes

[Maxime Ripard]

Due to the way the composition is done in hardware, we can only have a
single alpha-enabled plane active at a time, placed in the second (highest
priority) pipe.

Make sure of that in our atomic_check to not end up in an impossible
scenario.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/sun4i/sun4i_backend.c | 50 -
 drivers/gpu/drm/sun4i/sun4i_backend.h |  2 +-
 drivers/gpu/drm/sun4i/sun4i_layer.c   | 23 +-
 3 files changed, 53 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c 
b/drivers/gpu/drm/sun4i/sun4i_backend.c
index c4986054909b..dd995a6b8b12 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -329,6 +329,8 @@ static int sun4i_backend_atomic_check(struct sunxi_engine 
*engine,
struct drm_atomic_state *state = crtc_state->state;
struct drm_device *drm = state->dev;
struct drm_plane *plane;
+   unsigned int num_planes = 0;
+   unsigned int num_alpha_planes = 0;
unsigned int num_frontend_planes = 0;
 
DRM_DEBUG_DRIVER("Starting checking our planes\n");
@@ -341,6 +343,7 @@ static int sun4i_backend_atomic_check(struct sunxi_engine 
*engine,
drm_atomic_get_plane_state(state, plane);
struct sun4i_layer_state *layer_state =
state_to_sun4i_layer_state(plane_state);
+   struct drm_framebuffer *fb = plane_state->fb;
 
if (sun4i_backend_plane_uses_frontend(plane_state)) {
DRM_DEBUG_DRIVER("Using the frontend for plane %d\n",
@@ -351,6 +354,50 @@ static int sun4i_backend_atomic_check(struct sunxi_engine 
*engine,
} else {
layer_state->uses_frontend = false;
}
+
+   DRM_DEBUG_DRIVER("Plane FB format is %s\n",
+drm_get_format_name(fb->format->format,
+&format_name));
+   if (drm_format_has_alpha(fb->format->format))
+   num_alpha_planes++;
+
+   num_planes++;
+   }
+
+   /*
+* The hardware is a bit unusual here.
+*
+* Even though it supports 4 layers, it does the composition
+* in two separate steps.
+*
+* The first one is assigning a layer to one of its two
+* pipes. If more that 1 layer is assigned to the same pipe,
+* and if pixels overlaps, the pipe will take the pixel from
+* the layer with the highest priority.
+*
+* The second step is the actual alpha blending, that takes
+* the two pipes as input, and uses the eventual alpha
+* component to do the transparency between the two.
+*
+* This two steps scenario makes us unable to guarantee a
+* robust alpha blending between the 4 layers in all
+* situations, since this means that we need to have one layer
+* with alpha at the lowest position of our two pipes.
+*
+* However, we cannot even do that, since the hardware has a
+* bug where the lowest plane of the lowest pipe (pipe 0,
+* priority 0), if it has any alpha, will discard the pixel
+* entirely and just display the pixels in the background
+* color (black by default).
+*
+* Since means that we effectively have only three valid
+* configurations with alpha, all of them with the alpha being
+* on pipe1 with the lowest position, which can be 1, 2 or 3
+* depending on the number of planes and their zpos.
+*/
+   if (num_alpha_planes > SUN4I_BACKEND_NUM_ALPHA_LAYERS) {
+   DRM_DEBUG_DRIVER("Too many planes with alpha, rejecting...\n");
+   return -EINVAL;
}
 
if (num_frontend_planes > SUN4I_BACKEND_NUM_FRONTEND_LAYERS) {
@@ -358,6 +405,9 @@ static int sun4i_backend_atomic_check(struct sunxi_engine 
*engine,
return -EINVAL;
}
 
+   DRM_DEBUG_DRIVER("State valid with %u planes, %u alpha, %u video\n",
+num_planes, num_alpha_planes, num_frontend_planes);
+
return 0;
 }
 
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.h 
b/drivers/gpu/drm/sun4i/sun4i_backend.h
index 04a4f11b87a8..52e77591186a 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.h
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.h
@@ -146,6 +146,8 @@
 #define SUN4I_BACKEND_HWCCOLORTAB_OFF  0x4c00
 #define SUN4I_BACKEND_PIPE_OFF(p)  (0x5000 + (0x400 * (p)))
 
+#define SUN4I_BACKEND_NUM_LAYERS   4
+#define SUN4I_BACKEND_NUM_ALPHA_LAYERS 1
 #define SUN4I_BACKEND_NUM_FRONTEND_LAYERS  1
 
 struct sun4i_backend {
diff --git a/drivers/gpu/drm/sun4i/sun4i_layer.c 
b/drivers/gpu/drm/sun4i/sun4i_layer.c
index fbf25d59cf88..900e716443b8 100644
--- a/drivers/gpu/drm/sun4i/sun4i_layer.c
+++ b/drivers/gpu/drm

[PATCH 19/19] drm/sun4i: backend: Remove ARGB spoofing

[Maxime Ripard]

We've had some code for quite some time to prevent the alpha bug from
happening on the lowest primary plane. Since we now check for this in our
atomic_check, we can simply remove it.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/sun4i/sun4i_backend.c | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c 
b/drivers/gpu/drm/sun4i/sun4i_backend.c
index ec47098bfdb2..15a7bce27412 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -92,13 +92,8 @@ void sun4i_backend_layer_enable(struct sun4i_backend 
*backend,
   SUN4I_BACKEND_MODCTL_LAY_EN(layer), val);
 }
 
-static int sun4i_backend_drm_format_to_layer(struct drm_plane *plane,
-u32 format, u32 *mode)
+static int sun4i_backend_drm_format_to_layer(u32 format, u32 *mode)
 {
-   if (plane && (plane->type == DRM_PLANE_TYPE_PRIMARY) &&
-   (format == DRM_FORMAT_ARGB))
-   format = DRM_FORMAT_XRGB;
-
switch (format) {
case DRM_FORMAT_ARGB:
*mode = SUN4I_BACKEND_LAY_FBFMT_ARGB;
@@ -200,8 +195,7 @@ int sun4i_backend_update_layer_formats(struct sun4i_backend 
*backend,
   SUN4I_BACKEND_ATTCTL_REG0_LAY_GLBALPHA_EN,
   val);
 
-   ret = sun4i_backend_drm_format_to_layer(plane, fb->format->format,
-   &val);
+   ret = sun4i_backend_drm_format_to_layer(fb->format->format, &val);
if (ret) {
DRM_DEBUG_DRIVER("Invalid format\n");
return ret;
@@ -220,7 +214,7 @@ int sun4i_backend_update_layer_frontend(struct 
sun4i_backend *backend,
u32 val;
int ret;
 
-   ret = sun4i_backend_drm_format_to_layer(NULL, fmt, &val);
+   ret = sun4i_backend_drm_format_to_layer(fmt, &val);
if (ret) {
DRM_DEBUG_DRIVER("Invalid format\n");
return ret;
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 16/19] drm/sun4i: backend: Assign the pipes automatically

[Maxime Ripard]

Since we now have a way to enforce the zpos, check for the number of alpha
planes, the only missing part is to assign our pipe automatically instead
of hardcoding it.

The algorithm is quite simple, but requires two iterations over the list of
planes.

In the first one (which is the same one that we've had to check for alpha,
the frontend usage, and so on), we order the planes by their zpos.

We can then do a second iteration over that array by ascending zpos
starting with the pipe 0. When and if we encounter our alpha plane, we put
it and all the other subsequent planes in the second pipe.

And since we have runtime checks and pipe assignments now, we can just
remove the static declaration of the planes we used to have.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/sun4i/sun4i_backend.c | 41 +--
 drivers/gpu/drm/sun4i/sun4i_layer.c   | 50 
 drivers/gpu/drm/sun4i/sun4i_layer.h   |  1 +-
 3 files changed, 48 insertions(+), 44 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c 
b/drivers/gpu/drm/sun4i/sun4i_backend.c
index dd995a6b8b12..ad370ce66b4d 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -276,12 +276,16 @@ int sun4i_backend_update_layer_zpos(struct sun4i_backend 
*backend, int layer,
struct drm_plane *plane)
 {
struct drm_plane_state *state = plane->state;
+   struct sun4i_layer_state *p_state = state_to_sun4i_layer_state(state);
unsigned int priority = state->normalized_zpos;
+   unsigned int pipe = p_state->pipe;
 
-   DRM_DEBUG_DRIVER("Setting layer %d priority to %d\n", layer, priority);
-
+   DRM_DEBUG_DRIVER("Setting layer %d priority to %d and pipe %d\n",
+layer, priority, pipe);
regmap_update_bits(backend->engine.regs, 
SUN4I_BACKEND_ATTCTL_REG0(layer),
+  SUN4I_BACKEND_ATTCTL_REG0_LAY_PIPESEL_MASK |
   SUN4I_BACKEND_ATTCTL_REG0_LAY_PRISEL_MASK,
+  SUN4I_BACKEND_ATTCTL_REG0_LAY_PIPESEL(p_state->pipe) 
|
   SUN4I_BACKEND_ATTCTL_REG0_LAY_PRISEL(priority));
 
return 0;
@@ -326,12 +330,15 @@ static void sun4i_backend_atomic_begin(struct 
sunxi_engine *engine,
 static int sun4i_backend_atomic_check(struct sunxi_engine *engine,
  struct drm_crtc_state *crtc_state)
 {
+   struct drm_plane_state *plane_states[SUN4I_BACKEND_NUM_LAYERS] = { 0 };
struct drm_atomic_state *state = crtc_state->state;
struct drm_device *drm = state->dev;
struct drm_plane *plane;
unsigned int num_planes = 0;
unsigned int num_alpha_planes = 0;
unsigned int num_frontend_planes = 0;
+   unsigned int current_pipe = 0;
+   unsigned int i;
 
DRM_DEBUG_DRIVER("Starting checking our planes\n");
 
@@ -344,6 +351,7 @@ static int sun4i_backend_atomic_check(struct sunxi_engine 
*engine,
struct sun4i_layer_state *layer_state =
state_to_sun4i_layer_state(plane_state);
struct drm_framebuffer *fb = plane_state->fb;
+   struct drm_format_name_buf format_name;
 
if (sun4i_backend_plane_uses_frontend(plane_state)) {
DRM_DEBUG_DRIVER("Using the frontend for plane %d\n",
@@ -361,9 +369,19 @@ static int sun4i_backend_atomic_check(struct sunxi_engine 
*engine,
if (drm_format_has_alpha(fb->format->format))
num_alpha_planes++;
 
+   DRM_DEBUG_DRIVER("Plane zpos is %d\n",
+plane_state->normalized_zpos);
+
+   /* Sort our planes by Zpos */
+   plane_states[plane_state->normalized_zpos] = plane_state;
+
num_planes++;
}
 
+   /* All our planes were disabled, bail out */
+   if (!num_planes)
+   return 0;
+
/*
 * The hardware is a bit unusual here.
 *
@@ -400,6 +418,25 @@ static int sun4i_backend_atomic_check(struct sunxi_engine 
*engine,
return -EINVAL;
}
 
+   /* We can't have an alpha plane at the lowest position */
+   if (drm_format_has_alpha(plane_states[0]->fb->format->format))
+   return -EINVAL;
+
+   for (i = 1; i < num_planes; i++) {
+   struct drm_plane_state *p_state = plane_states[i];
+   struct drm_framebuffer *fb = p_state->fb;
+   struct sun4i_layer_state *s_state = 
state_to_sun4i_layer_state(p_state);
+
+   /*
+* The only alpha position is the lowest plane of the
+* second pipe.
+*/
+   if (drm_format_has_alpha(fb->format->format))
+   current_pipe++;
+
+   s_state->pipe = current_pipe;
+   }
+
if (num_frontend_planes > SUN4I_BACKEND_NUM_FRON

[PATCH 17/19] drm/sun4i: backend: Make zpos configurable

[Maxime Ripard]

Now that we have everything in place, we can make zpos configurable now.
Change the zpos property from an immutable one to a regular.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/sun4i/sun4i_layer.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_layer.c 
b/drivers/gpu/drm/sun4i/sun4i_layer.c
index ec7b906dbb84..9e538f761dcb 100644
--- a/drivers/gpu/drm/sun4i/sun4i_layer.c
+++ b/drivers/gpu/drm/sun4i/sun4i_layer.c
@@ -163,6 +163,9 @@ static struct sun4i_layer *sun4i_layer_init_one(struct 
drm_device *drm,
 &sun4i_backend_layer_helper_funcs);
layer->backend = backend;
 
+   drm_plane_create_zpos_property(&layer->plane, 0, 0,
+  SUN4I_BACKEND_NUM_LAYERS - 1);
+
return layer;
 }
 
@@ -189,8 +192,6 @@ struct drm_plane **sun4i_layers_init(struct drm_device *drm,
return ERR_CAST(layer);
};
 
-   drm_plane_create_zpos_immutable_property(&layer->plane, i);
-
layer->id = i;
planes[i] = &layer->plane;
};
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 18/19] drm/sun4i: Add support for plane alpha

[Maxime Ripard]

Our backend supports a per-plane alpha property. Support it through our new
helper.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/sun4i/sun4i_backend.c | 18 +++---
 drivers/gpu/drm/sun4i/sun4i_backend.h |  3 +++
 drivers/gpu/drm/sun4i/sun4i_layer.c   |  2 ++
 3 files changed, 20 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c 
b/drivers/gpu/drm/sun4i/sun4i_backend.c
index ad370ce66b4d..ec47098bfdb2 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -191,6 +191,15 @@ int sun4i_backend_update_layer_formats(struct 
sun4i_backend *backend,
DRM_DEBUG_DRIVER("Switching display backend interlaced mode %s\n",
 interlaced ? "on" : "off");
 
+   val = SUN4I_BACKEND_ATTCTL_REG0_LAY_GLBALPHA(state->alpha);
+   if (state->alpha != 255)
+   val |= SUN4I_BACKEND_ATTCTL_REG0_LAY_GLBALPHA_EN;
+   regmap_update_bits(backend->engine.regs,
+  SUN4I_BACKEND_ATTCTL_REG0(layer),
+  SUN4I_BACKEND_ATTCTL_REG0_LAY_GLBALPHA_MASK |
+  SUN4I_BACKEND_ATTCTL_REG0_LAY_GLBALPHA_EN,
+  val);
+
ret = sun4i_backend_drm_format_to_layer(plane, fb->format->format,
&val);
if (ret) {
@@ -366,7 +375,8 @@ static int sun4i_backend_atomic_check(struct sunxi_engine 
*engine,
DRM_DEBUG_DRIVER("Plane FB format is %s\n",
 drm_get_format_name(fb->format->format,
 &format_name));
-   if (drm_format_has_alpha(fb->format->format))
+   if (drm_format_has_alpha(fb->format->format) ||
+   (plane_state->alpha != 255))
num_alpha_planes++;
 
DRM_DEBUG_DRIVER("Plane zpos is %d\n",
@@ -419,7 +429,8 @@ static int sun4i_backend_atomic_check(struct sunxi_engine 
*engine,
}
 
/* We can't have an alpha plane at the lowest position */
-   if (drm_format_has_alpha(plane_states[0]->fb->format->format))
+   if (drm_format_has_alpha(plane_states[0]->fb->format->format) ||
+   (plane_states[0]->alpha != 255))
return -EINVAL;
 
for (i = 1; i < num_planes; i++) {
@@ -431,7 +442,8 @@ static int sun4i_backend_atomic_check(struct sunxi_engine 
*engine,
 * The only alpha position is the lowest plane of the
 * second pipe.
 */
-   if (drm_format_has_alpha(fb->format->format))
+   if (drm_format_has_alpha(fb->format->format) ||
+   (p_state->alpha != 255))
current_pipe++;
 
s_state->pipe = current_pipe;
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.h 
b/drivers/gpu/drm/sun4i/sun4i_backend.h
index 52e77591186a..03294d5dd1a2 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.h
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.h
@@ -68,11 +68,14 @@
 #define SUN4I_BACKEND_CKMIN_REG0x884
 #define SUN4I_BACKEND_CKCFG_REG0x888
 #define SUN4I_BACKEND_ATTCTL_REG0(l)   (0x890 + (0x4 * (l)))
+#define SUN4I_BACKEND_ATTCTL_REG0_LAY_GLBALPHA_MASKGENMASK(31, 24)
+#define SUN4I_BACKEND_ATTCTL_REG0_LAY_GLBALPHA(x)  ((x) << 24)
 #define SUN4I_BACKEND_ATTCTL_REG0_LAY_PIPESEL_MASK BIT(15)
 #define SUN4I_BACKEND_ATTCTL_REG0_LAY_PIPESEL(x)   ((x) << 15)
 #define SUN4I_BACKEND_ATTCTL_REG0_LAY_PRISEL_MASK  GENMASK(11, 10)
 #define SUN4I_BACKEND_ATTCTL_REG0_LAY_PRISEL(x)((x) << 
10)
 #define SUN4I_BACKEND_ATTCTL_REG0_LAY_VDOENBIT(1)
+#define SUN4I_BACKEND_ATTCTL_REG0_LAY_GLBALPHA_EN  BIT(0)
 
 #define SUN4I_BACKEND_ATTCTL_REG1(l)   (0x8a0 + (0x4 * (l)))
 #define SUN4I_BACKEND_ATTCTL_REG1_LAY_HSCAFCT  GENMASK(15, 14)
diff --git a/drivers/gpu/drm/sun4i/sun4i_layer.c 
b/drivers/gpu/drm/sun4i/sun4i_layer.c
index 9e538f761dcb..d5598de92f85 100644
--- a/drivers/gpu/drm/sun4i/sun4i_layer.c
+++ b/drivers/gpu/drm/sun4i/sun4i_layer.c
@@ -37,6 +37,7 @@ static void sun4i_backend_layer_reset(struct drm_plane *plane)
if (state) {
plane->state = &state->state;
plane->state->plane = plane;
+   plane->state->alpha = 255;
plane->state->zpos = layer->id;
}
 }
@@ -163,6 +164,7 @@ static struct sun4i_layer *sun4i_layer_init_one(struct 
drm_device *drm,
 &sun4i_backend_layer_helper_funcs);
layer->backend = backend;
 
+   drm_plane_create_alpha_property(&layer->plane, 255);
drm_plane_create_zpos_property(&layer->plane, 0, 0,
   SUN4I_BACKEND_NUM_LAYERS - 1);
 
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.free

[PATCH 13/19] drm/sun4i: backend: Set a default zpos in our reset hook

[Maxime Ripard]

The our plane state zpos value will be set only if there's an existing
state attached to the plane when creating the property.

However, this is not the case during the probe, and we therefore need to
put our default value in our reset hook.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/sun4i/sun4i_layer.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/sun4i/sun4i_layer.c 
b/drivers/gpu/drm/sun4i/sun4i_layer.c
index c448cb6b9fa9..03549646528a 100644
--- a/drivers/gpu/drm/sun4i/sun4i_layer.c
+++ b/drivers/gpu/drm/sun4i/sun4i_layer.c
@@ -28,6 +28,7 @@ struct sun4i_plane_desc {
 
 static void sun4i_backend_layer_reset(struct drm_plane *plane)
 {
+   struct sun4i_layer *layer = plane_to_sun4i_layer(plane);
struct sun4i_layer_state *state;
 
if (plane->state) {
@@ -43,6 +44,7 @@ static void sun4i_backend_layer_reset(struct drm_plane *plane)
if (state) {
plane->state = &state->state;
plane->state->plane = plane;
+   plane->state->zpos = layer->id;
}
 }
 
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 08/19] drm/rcar-du: Convert to the new generic alpha property

[Maxime Ripard]

Now that we have support for per-plane alpha in the core, let's use it.

Cc: Laurent Pinchart 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/rcar-du/rcar_du_drv.h   |  1 +-
 drivers/gpu/drm/rcar-du/rcar_du_kms.c   |  5 +---
 drivers/gpu/drm/rcar-du/rcar_du_plane.c | 15 +++--
 drivers/gpu/drm/rcar-du/rcar_du_plane.h |  2 +-
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c   | 42 ++
 drivers/gpu/drm/rcar-du/rcar_du_vsp.h   |  2 +-
 6 files changed, 9 insertions(+), 58 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h 
b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
index f8cd79488ece..aff04adaae53 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
@@ -89,7 +89,6 @@ struct rcar_du_device {
struct rcar_du_vsp vsps[RCAR_DU_MAX_VSPS];
 
struct {
-   struct drm_property *alpha;
struct drm_property *colorkey;
} props;
 
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index 566d1a948c8f..e1b5a7b460cc 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -417,11 +417,6 @@ static int rcar_du_encoders_init(struct rcar_du_device 
*rcdu)
 
 static int rcar_du_properties_init(struct rcar_du_device *rcdu)
 {
-   rcdu->props.alpha =
-   drm_property_create_range(rcdu->ddev, 0, "alpha", 0, 255);
-   if (rcdu->props.alpha == NULL)
-   return -ENOMEM;
-
/*
 * The color key is expressed as an RGB888 triplet stored in a 32-bit
 * integer in XRGB format. Bit 24 is used as a flag to disable (0)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c 
b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
index 61833cc1c699..5b34e8092c8b 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
@@ -423,7 +423,7 @@ static void rcar_du_plane_setup_mode(struct rcar_du_group 
*rgrp,
rcar_du_plane_write(rgrp, index, PnALPHAR, PnALPHAR_ABIT_0);
else
rcar_du_plane_write(rgrp, index, PnALPHAR,
-   PnALPHAR_ABIT_X | state->alpha);
+   PnALPHAR_ABIT_X | state->state.alpha);
 
pnmr = PnMR_BM_MD | state->format->pnmr;
 
@@ -667,11 +667,11 @@ static void rcar_du_plane_reset(struct drm_plane *plane)
 
state->hwindex = -1;
state->source = RCAR_DU_PLANE_MEMORY;
-   state->alpha = 255;
state->colorkey = RCAR_DU_COLORKEY_NONE;
state->state.zpos = plane->type == DRM_PLANE_TYPE_PRIMARY ? 0 : 1;
 
plane->state = &state->state;
+   plane->state->alpha = 255;
plane->state->plane = plane;
 }
 
@@ -683,9 +683,7 @@ static int rcar_du_plane_atomic_set_property(struct 
drm_plane *plane,
struct rcar_du_plane_state *rstate = to_rcar_plane_state(state);
struct rcar_du_device *rcdu = to_rcar_plane(plane)->group->dev;
 
-   if (property == rcdu->props.alpha)
-   rstate->alpha = val;
-   else if (property == rcdu->props.colorkey)
+   if (property == rcdu->props.colorkey)
rstate->colorkey = val;
else
return -EINVAL;
@@ -701,9 +699,7 @@ static int rcar_du_plane_atomic_get_property(struct 
drm_plane *plane,
container_of(state, const struct rcar_du_plane_state, state);
struct rcar_du_device *rcdu = to_rcar_plane(plane)->group->dev;
 
-   if (property == rcdu->props.alpha)
-   *val = rstate->alpha;
-   else if (property == rcdu->props.colorkey)
+   if (property == rcdu->props.colorkey)
*val = rstate->colorkey;
else
return -EINVAL;
@@ -772,10 +768,9 @@ int rcar_du_planes_init(struct rcar_du_group *rgrp)
continue;
 
drm_object_attach_property(&plane->plane.base,
-  rcdu->props.alpha, 255);
-   drm_object_attach_property(&plane->plane.base,
   rcdu->props.colorkey,
   RCAR_DU_COLORKEY_NONE);
+   drm_plane_create_alpha_property(&plane->plane, 255);
drm_plane_create_zpos_property(&plane->plane, 1, 1, 7);
}
 
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.h 
b/drivers/gpu/drm/rcar-du/rcar_du_plane.h
index f62e09f195de..2dc793ebd1a2 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_plane.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.h
@@ -50,7 +50,6 @@ static inline struct rcar_du_plane *to_rcar_plane(struct 
drm_plane *plane)
  * @state: base DRM plane state
  * @format: information about the pixel format used by the plane
  * @hwindex: 0-based hardware plane index, -1 means unused
- * @alpha: value of the plane alpha property
  * @colorkey: value of the plane colorkey property
  */
 struct rcar_du_plane_state {
@@ -60,7 +59,6 @@ struct rcar_du_plan

[PATCH 02/19] drm/atmel-hlcdc: Use the alpha format helper

[Maxime Ripard]

Now that the core has a drm format helper to tell if a format embeds an
alpha component in it, let's use it.

Cc: Boris Brezillon 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 20 ++
 1 file changed, 3 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
index 703c2d13603f..1a9318810a29 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
@@ -194,20 +194,6 @@ static int atmel_hlcdc_format_to_plane_mode(u32 format, 
u32 *mode)
return 0;
 }
 
-static bool atmel_hlcdc_format_embeds_alpha(u32 format)
-{
-   int i;
-
-   for (i = 0; i < sizeof(format); i++) {
-   char tmp = (format >> (8 * i)) & 0xff;
-
-   if (tmp == 'A')
-   return true;
-   }
-
-   return false;
-}
-
 static u32 heo_downscaling_xcoef[] = {
0x11343311,
0x00f7,
@@ -395,7 +381,7 @@ atmel_hlcdc_plane_update_general_settings(struct 
atmel_hlcdc_plane *plane,
cfg |= ATMEL_HLCDC_LAYER_OVR | ATMEL_HLCDC_LAYER_ITER2BL |
   ATMEL_HLCDC_LAYER_ITER;
 
-   if (atmel_hlcdc_format_embeds_alpha(format))
+   if (drm_format_has_alpha(format))
cfg |= ATMEL_HLCDC_LAYER_LAEN;
else
cfg |= ATMEL_HLCDC_LAYER_GAEN |
@@ -566,7 +552,7 @@ atmel_hlcdc_plane_prepare_disc_area(struct drm_crtc_state 
*c_state)
ovl_state = drm_plane_state_to_atmel_hlcdc_plane_state(ovl_s);
 
if (!ovl_s->fb ||
-   atmel_hlcdc_format_embeds_alpha(ovl_s->fb->format->format) 
||
+   drm_format_has_alpha(ovl_s->fb->format->format) ||
ovl_state->alpha != 255)
continue;
 
@@ -769,7 +755,7 @@ static int atmel_hlcdc_plane_atomic_check(struct drm_plane 
*p,
 
if ((state->crtc_h != state->src_h || state->crtc_w != state->src_w) &&
(!desc->layout.memsize ||
-atmel_hlcdc_format_embeds_alpha(state->base.fb->format->format)))
+drm_format_has_alpha(state->base.fb->format->format)))
return -EINVAL;
 
if (state->crtc_x < 0 || state->crtc_y < 0)
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 06/19] drm/blend: Add a generic alpha property

[Maxime Ripard]

Some drivers duplicate the logic to create a property to store a per-plane
alpha.

Let's create a helper in order to move that to the core.

Cc: Boris Brezillon 
Cc: Laurent Pinchart 
Signed-off-by: Maxime Ripard 
---
 Documentation/gpu/kms-properties.csv |  2 +-
 drivers/gpu/drm/drm_atomic.c |  4 -
 drivers/gpu/drm/drm_atomic_helper.c  |  1 +-
 drivers/gpu/drm/drm_blend.c  | 32 +-
 include/drm/drm_blend.h  |  1 +-
 include/drm/drm_plane.h  |  6 +-
 6 files changed, 45 insertions(+), 1 deletion(-)

diff --git a/Documentation/gpu/kms-properties.csv 
b/Documentation/gpu/kms-properties.csv
index 927b65e14219..a3c3969c1992 100644
--- a/Documentation/gpu/kms-properties.csv
+++ b/Documentation/gpu/kms-properties.csv
@@ -99,5 +99,5 @@ radeon,DVI-I,“coherent”,RANGE,"Min=0, Max=1",Connector,TBD
 ,,"""underscan vborder""",RANGE,"Min=0, Max=128",Connector,TBD
 ,Audio,“audio”,ENUM,"{ ""off"", ""on"", ""auto"" }",Connector,TBD
 ,FMT Dithering,“dither”,ENUM,"{ ""off"", ""on"" }",Connector,TBD
-rcar-du,Generic,"""alpha""",RANGE,"Min=0, Max=255",Plane,TBD
+,,"""alpha""",RANGE,"Min=0, Max=255",Plane,Opacity of the plane from 
transparent (0) to opaque (255)
 ,,"""colorkey""",RANGE,"Min=0, Max=0x01ff",Plane,TBD
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index c2da5585e201..ade18cf62c89 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -749,6 +749,8 @@ static int drm_atomic_plane_set_property(struct drm_plane 
*plane,
state->src_w = val;
} else if (property == config->prop_src_h) {
state->src_h = val;
+   } else if (property == plane->alpha_property) {
+   state->alpha = val;
} else if (property == plane->rotation_property) {
if (!is_power_of_2(val & DRM_MODE_ROTATE_MASK))
return -EINVAL;
@@ -810,6 +812,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
*val = state->src_w;
} else if (property == config->prop_src_h) {
*val = state->src_h;
+   } else if (property == plane->alpha_property) {
+   *val = state->alpha;
} else if (property == plane->rotation_property) {
*val = state->rotation;
} else if (property == plane->zpos_property) {
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 71d712f1b56a..018993df4c18 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3372,6 +3372,7 @@ void drm_atomic_helper_plane_reset(struct drm_plane 
*plane)
 
if (plane->state) {
plane->state->plane = plane;
+   plane->state->alpha = 255;
plane->state->rotation = DRM_MODE_ROTATE_0;
}
 }
diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
index 2e5e089dd912..8eea2a8af458 100644
--- a/drivers/gpu/drm/drm_blend.c
+++ b/drivers/gpu/drm/drm_blend.c
@@ -104,6 +104,38 @@
  */
 
 /**
+ * drm_plane_create_alpha_property - create a new alpha property
+ * @plane: drm plane
+ * @alpha: initial value of alpha, from 0 (transparent) to 255 (opaque)
+ *
+ * This function initializes a generic, mutable, alpha property and
+ * enables support for it in the DRM core.
+ *
+ * Drivers can then attach this property to their plane to enable
+ * support for configurable plane alpha.
+ *
+ * Returns:
+ * 0 on success, negative error code on failure.
+ */
+int drm_plane_create_alpha_property(struct drm_plane *plane, u8 alpha)
+{
+   struct drm_property *prop;
+
+   prop = drm_property_create_range(plane->dev, 0, "alpha", 0, 255);
+   if (!prop)
+   return -ENOMEM;
+
+   drm_object_attach_property(&plane->base, prop, alpha);
+   plane->alpha_property = prop;
+
+   if (plane->state)
+   plane->state->alpha = alpha;
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_plane_create_alpha_property);
+
+/**
  * drm_plane_create_rotation_property - create a new rotation property
  * @plane: drm plane
  * @rotation: initial value of the rotation property
diff --git a/include/drm/drm_blend.h b/include/drm/drm_blend.h
index 17606026590b..5979a8fce453 100644
--- a/include/drm/drm_blend.h
+++ b/include/drm/drm_blend.h
@@ -36,6 +36,7 @@ static inline bool drm_rotation_90_or_270(unsigned int 
rotation)
return rotation & (DRM_MODE_ROTATE_90 | DRM_MODE_ROTATE_270);
 }
 
+int drm_plane_create_alpha_property(struct drm_plane *plane, u8 alpha);
 int drm_plane_create_rotation_property(struct drm_plane *plane,
   unsigned int rotation,
   unsigned int supported_rotations);
diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
index 571615079230..a5e26064b132 100644
--- a/include/drm/drm_plane.h
+++ b/include/drm/drm_plane.h
@@ -42,6 +42,7 @@ struct drm_modeset_acquire_ct

[PATCH 09/19] drm/sun4i: backend: Fix structure indentation

[Maxime Ripard]

The sun4i_plane_desc structure was somehow indented to two tabulations
instead of one as we shoud do. Fix that.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/sun4i/sun4i_layer.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_layer.c 
b/drivers/gpu/drm/sun4i/sun4i_layer.c
index 4652b25be0d2..f03da16eb92a 100644
--- a/drivers/gpu/drm/sun4i/sun4i_layer.c
+++ b/drivers/gpu/drm/sun4i/sun4i_layer.c
@@ -20,10 +20,10 @@
 #include "sunxi_engine.h"
 
 struct sun4i_plane_desc {
-  enum drm_plane_type type;
-  u8  pipe;
-  const uint32_t  *formats;
-  uint32_tnformats;
+   enum drm_plane_type type;
+   u8  pipe;
+   const uint32_t  *formats;
+   uint32_tnformats;
 };
 
 static void sun4i_backend_layer_reset(struct drm_plane *plane)
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 07/19] drm/atmel-hclcdc: Convert to the new generic alpha property

[Maxime Ripard]

Now that we have support for per-plane alpha in the core, let's use it.

Cc: Boris Brezillon 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h| 13 +---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 89 ++
 2 files changed, 14 insertions(+), 88 deletions(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
index 6833ee253cfa..704cac6399eb 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
@@ -298,7 +298,6 @@ struct atmel_hlcdc_layer {
 struct atmel_hlcdc_plane {
struct drm_plane base;
struct atmel_hlcdc_layer layer;
-   struct atmel_hlcdc_plane_properties *properties;
 };
 
 static inline struct atmel_hlcdc_plane *
@@ -345,18 +344,6 @@ struct atmel_hlcdc_dc_desc {
 };
 
 /**
- * Atmel HLCDC Plane properties.
- *
- * This structure stores plane property definitions.
- *
- * @alpha: alpha blending (or transparency) property
- * @rotation: rotation property
- */
-struct atmel_hlcdc_plane_properties {
-   struct drm_property *alpha;
-};
-
-/**
  * Atmel HLCDC Display Controller.
  *
  * @desc: HLCDC Display Controller description
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
index 1a9318810a29..dbc508889e87 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
@@ -31,7 +31,6 @@
  * @src_y: y buffer position
  * @src_w: buffer width
  * @src_h: buffer height
- * @alpha: alpha blending of the plane
  * @disc_x: x discard position
  * @disc_y: y discard position
  * @disc_w: discard width
@@ -54,8 +53,6 @@ struct atmel_hlcdc_plane_state {
uint32_t src_w;
uint32_t src_h;
 
-   u8 alpha;
-
int disc_x;
int disc_y;
int disc_w;
@@ -385,7 +382,7 @@ atmel_hlcdc_plane_update_general_settings(struct 
atmel_hlcdc_plane *plane,
cfg |= ATMEL_HLCDC_LAYER_LAEN;
else
cfg |= ATMEL_HLCDC_LAYER_GAEN |
-  ATMEL_HLCDC_LAYER_GA(state->alpha);
+  ATMEL_HLCDC_LAYER_GA(state->base.alpha);
}
 
if (state->disc_h && state->disc_w)
@@ -553,7 +550,7 @@ atmel_hlcdc_plane_prepare_disc_area(struct drm_crtc_state 
*c_state)
 
if (!ovl_s->fb ||
drm_format_has_alpha(ovl_s->fb->format->format) ||
-   ovl_state->alpha != 255)
+   ovl_s->alpha != 255)
continue;
 
/* TODO: implement a smarter hidden area detection */
@@ -829,51 +826,18 @@ static void atmel_hlcdc_plane_destroy(struct drm_plane *p)
drm_plane_cleanup(p);
 }
 
-static int atmel_hlcdc_plane_atomic_set_property(struct drm_plane *p,
-struct drm_plane_state *s,
-struct drm_property *property,
-uint64_t val)
-{
-   struct atmel_hlcdc_plane *plane = drm_plane_to_atmel_hlcdc_plane(p);
-   struct atmel_hlcdc_plane_properties *props = plane->properties;
-   struct atmel_hlcdc_plane_state *state =
-   drm_plane_state_to_atmel_hlcdc_plane_state(s);
-
-   if (property == props->alpha)
-   state->alpha = val;
-   else
-   return -EINVAL;
-
-   return 0;
-}
-
-static int atmel_hlcdc_plane_atomic_get_property(struct drm_plane *p,
-   const struct drm_plane_state *s,
-   struct drm_property *property,
-   uint64_t *val)
-{
-   struct atmel_hlcdc_plane *plane = drm_plane_to_atmel_hlcdc_plane(p);
-   struct atmel_hlcdc_plane_properties *props = plane->properties;
-   const struct atmel_hlcdc_plane_state *state =
-   container_of(s, const struct atmel_hlcdc_plane_state, base);
-
-   if (property == props->alpha)
-   *val = state->alpha;
-   else
-   return -EINVAL;
-
-   return 0;
-}
-
-static int atmel_hlcdc_plane_init_properties(struct atmel_hlcdc_plane *plane,
-   struct atmel_hlcdc_plane_properties *props)
+static int atmel_hlcdc_plane_init_properties(struct atmel_hlcdc_plane *plane)
 {
const struct atmel_hlcdc_layer_desc *desc = plane->layer.desc;
 
if (desc->type == ATMEL_HLCDC_OVERLAY_LAYER ||
-   desc->type == ATMEL_HLCDC_CURSOR_LAYER)
-   drm_object_attach_property(&plane->base.base,
-  props->alpha, 255);
+   desc->type == ATMEL_HLCDC_CURSOR_LAYER) {
+   int ret;
+
+   ret = drm_plane_create_alpha_property(&plane->base, 255);
+   if (ret)
+   return ret;
+

[PATCH 14/19] drm/sun4i: backend: Add support for zpos

[Maxime Ripard]

Our various planes have a configurable zpos, that combined with the pipes
allow to configure the composition.

Since the interaction between the pipes, zpos and alphas framebuffers are
not trivials, let's just enable the zpos as an immutable property for now,
and use that zpos in our atomic_update part.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/sun4i/sun4i_backend.c | 15 +++
 drivers/gpu/drm/sun4i/sun4i_backend.h |  2 ++
 drivers/gpu/drm/sun4i/sun4i_framebuffer.c |  4 
 drivers/gpu/drm/sun4i/sun4i_layer.c   |  3 +++
 4 files changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c 
b/drivers/gpu/drm/sun4i/sun4i_backend.c
index a18c86a15748..c4986054909b 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -272,6 +272,21 @@ int sun4i_backend_update_layer_buffer(struct sun4i_backend 
*backend,
return 0;
 }
 
+int sun4i_backend_update_layer_zpos(struct sun4i_backend *backend, int layer,
+   struct drm_plane *plane)
+{
+   struct drm_plane_state *state = plane->state;
+   unsigned int priority = state->normalized_zpos;
+
+   DRM_DEBUG_DRIVER("Setting layer %d priority to %d\n", layer, priority);
+
+   regmap_update_bits(backend->engine.regs, 
SUN4I_BACKEND_ATTCTL_REG0(layer),
+  SUN4I_BACKEND_ATTCTL_REG0_LAY_PRISEL_MASK,
+  SUN4I_BACKEND_ATTCTL_REG0_LAY_PRISEL(priority));
+
+   return 0;
+}
+
 static bool sun4i_backend_plane_uses_scaler(struct drm_plane_state *state)
 {
u16 src_h = state->src_h >> 16;
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.h 
b/drivers/gpu/drm/sun4i/sun4i_backend.h
index 1ca8b7db6807..04a4f11b87a8 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.h
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.h
@@ -182,5 +182,7 @@ int sun4i_backend_update_layer_buffer(struct sun4i_backend 
*backend,
  int layer, struct drm_plane *plane);
 int sun4i_backend_update_layer_frontend(struct sun4i_backend *backend,
int layer, uint32_t in_fmt);
+int sun4i_backend_update_layer_zpos(struct sun4i_backend *backend,
+   int layer, struct drm_plane *plane);
 
 #endif /* _SUN4I_BACKEND_H_ */
diff --git a/drivers/gpu/drm/sun4i/sun4i_framebuffer.c 
b/drivers/gpu/drm/sun4i/sun4i_framebuffer.c
index e68004844abe..5b3986437a50 100644
--- a/drivers/gpu/drm/sun4i/sun4i_framebuffer.c
+++ b/drivers/gpu/drm/sun4i/sun4i_framebuffer.c
@@ -35,6 +35,10 @@ static int sun4i_de_atomic_check(struct drm_device *dev,
if (ret)
return ret;
 
+   ret = drm_atomic_normalize_zpos(dev, state);
+   if (ret)
+   return ret;
+
return drm_atomic_helper_check_planes(dev, state);
 }
 
diff --git a/drivers/gpu/drm/sun4i/sun4i_layer.c 
b/drivers/gpu/drm/sun4i/sun4i_layer.c
index 03549646528a..fbf25d59cf88 100644
--- a/drivers/gpu/drm/sun4i/sun4i_layer.c
+++ b/drivers/gpu/drm/sun4i/sun4i_layer.c
@@ -115,6 +115,7 @@ static void sun4i_backend_layer_atomic_update(struct 
drm_plane *plane,
}
 
sun4i_backend_update_layer_coord(backend, layer->id, plane);
+   sun4i_backend_update_layer_zpos(backend, layer->id, plane);
sun4i_backend_layer_enable(backend, layer->id, true);
 }
 
@@ -237,6 +238,8 @@ struct drm_plane **sun4i_layers_init(struct drm_device *drm,
return ERR_CAST(layer);
};
 
+   drm_plane_create_zpos_immutable_property(&layer->plane, i);
+
DRM_DEBUG_DRIVER("Assigning %s plane to pipe %d\n",
 i ? "overlay" : "primary", plane->pipe);
regmap_update_bits(engine->regs, SUN4I_BACKEND_ATTCTL_REG0(i),
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 05/19] drm/vc4: Use the alpha format helper

[Maxime Ripard]

Now that the core has a drm format helper to tell if a format embeds an
alpha component in it, let's use it.

Cc: Eric Anholt 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/vc4/vc4_plane.c | 19 +--
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index 423a23ed8fc2..2c0e25128dcd 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -85,40 +85,39 @@ static const struct hvs_format {
u32 drm; /* DRM_FORMAT_* */
u32 hvs; /* HVS_FORMAT_* */
u32 pixel_order;
-   bool has_alpha;
bool flip_cbcr;
 } hvs_formats[] = {
{
.drm = DRM_FORMAT_XRGB, .hvs = HVS_PIXEL_FORMAT_RGBA,
-   .pixel_order = HVS_PIXEL_ORDER_ABGR, .has_alpha = false,
+   .pixel_order = HVS_PIXEL_ORDER_ABGR,
},
{
.drm = DRM_FORMAT_ARGB, .hvs = HVS_PIXEL_FORMAT_RGBA,
-   .pixel_order = HVS_PIXEL_ORDER_ABGR, .has_alpha = true,
+   .pixel_order = HVS_PIXEL_ORDER_ABGR,
},
{
.drm = DRM_FORMAT_ABGR, .hvs = HVS_PIXEL_FORMAT_RGBA,
-   .pixel_order = HVS_PIXEL_ORDER_ARGB, .has_alpha = true,
+   .pixel_order = HVS_PIXEL_ORDER_ARGB,
},
{
.drm = DRM_FORMAT_XBGR, .hvs = HVS_PIXEL_FORMAT_RGBA,
-   .pixel_order = HVS_PIXEL_ORDER_ARGB, .has_alpha = false,
+   .pixel_order = HVS_PIXEL_ORDER_ARGB,
},
{
.drm = DRM_FORMAT_RGB565, .hvs = HVS_PIXEL_FORMAT_RGB565,
-   .pixel_order = HVS_PIXEL_ORDER_XRGB, .has_alpha = false,
+   .pixel_order = HVS_PIXEL_ORDER_XRGB,
},
{
.drm = DRM_FORMAT_BGR565, .hvs = HVS_PIXEL_FORMAT_RGB565,
-   .pixel_order = HVS_PIXEL_ORDER_XBGR, .has_alpha = false,
+   .pixel_order = HVS_PIXEL_ORDER_XBGR,
},
{
.drm = DRM_FORMAT_ARGB1555, .hvs = HVS_PIXEL_FORMAT_RGBA5551,
-   .pixel_order = HVS_PIXEL_ORDER_ABGR, .has_alpha = true,
+   .pixel_order = HVS_PIXEL_ORDER_ABGR,
},
{
.drm = DRM_FORMAT_XRGB1555, .hvs = HVS_PIXEL_FORMAT_RGBA5551,
-   .pixel_order = HVS_PIXEL_ORDER_ABGR, .has_alpha = false,
+   .pixel_order = HVS_PIXEL_ORDER_ABGR,
},
{
.drm = DRM_FORMAT_YUV422,
@@ -601,7 +600,7 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
/* Position Word 2: Source Image Size, Alpha Mode */
vc4_state->pos2_offset = vc4_state->dlist_count;
vc4_dlist_write(vc4_state,
-   VC4_SET_FIELD(format->has_alpha ?
+   VC4_SET_FIELD(drm_format_has_alpha(format->drm) ?
  SCALER_POS2_ALPHA_MODE_PIPELINE :
  SCALER_POS2_ALPHA_MODE_FIXED,
  SCALER_POS2_ALPHA_MODE) |
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 04/19] drm/rockchip: Use the alpha format helper

[Maxime Ripard]

Now that the core has a drm format helper to tell if a format embeds an
alpha component in it, let's use it.

Cc: Mark Yao 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 13 +
 1 file changed, 1 insertion(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 19128b4dea54..cfc4d4909185 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -253,17 +253,6 @@ static bool is_yuv_support(uint32_t format)
}
 }
 
-static bool is_alpha_support(uint32_t format)
-{
-   switch (format) {
-   case DRM_FORMAT_ARGB:
-   case DRM_FORMAT_ABGR:
-   return true;
-   default:
-   return false;
-   }
-}
-
 static uint16_t scl_vop_cal_scale(enum scale_mode mode, uint32_t src,
  uint32_t dst, bool is_horizontal,
  int vsu_mode, int *vskiplines)
@@ -790,7 +779,7 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
rb_swap = has_rb_swapped(fb->format->format);
VOP_WIN_SET(vop, win, rb_swap, rb_swap);
 
-   if (is_alpha_support(fb->format->format)) {
+   if (drm_format_has_alpha(fb->format->format)) {
VOP_WIN_SET(vop, win, dst_alpha_ctl,
DST_FACTOR_M0(ALPHA_SRC_INVERSE));
val = SRC_ALPHA_EN(1) | SRC_COLOR_M0(ALPHA_SRC_PRE_MUL) |
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 01/19] drm/fourcc: Add a function to tell if the format embeds alpha

[Maxime Ripard]

There's a bunch of drivers that duplicate the same function to know if a
particular format embeds an alpha component or not.

Let's create a helper to avoid duplicating that logic.

Cc: Boris Brezillon 
Cc: Eric Anholt 
Cc: Inki Dae 
Cc: Joonyoung Shim 
Cc: Kyungmin Park 
Cc: Laurent Pinchart 
Cc: Mark Yao 
Cc: Seung-Woo Kim 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/drm_fourcc.c | 43 +-
 include/drm/drm_fourcc.h |  1 +-
 2 files changed, 44 insertions(+)

diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 9c0152df45ad..6e6227d6a46b 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -348,3 +348,46 @@ int drm_format_plane_height(int height, uint32_t format, 
int plane)
return height / info->vsub;
 }
 EXPORT_SYMBOL(drm_format_plane_height);
+
+/**
+ * drm_format_has_alpha - get whether the format embeds an alpha component
+ * @format: pixel format (DRM_FORMAT_*)
+ *
+ * Returns:
+ * true if the format embeds an alpha component, false otherwise.
+ */
+bool drm_format_has_alpha(uint32_t format)
+{
+   switch (format) {
+   case DRM_FORMAT_ARGB:
+   case DRM_FORMAT_ABGR:
+   case DRM_FORMAT_RGBA:
+   case DRM_FORMAT_BGRA:
+   case DRM_FORMAT_ARGB1555:
+   case DRM_FORMAT_ABGR1555:
+   case DRM_FORMAT_RGBA5551:
+   case DRM_FORMAT_BGRA5551:
+   case DRM_FORMAT_ARGB:
+   case DRM_FORMAT_ABGR:
+   case DRM_FORMAT_RGBA:
+   case DRM_FORMAT_BGRA:
+   case DRM_FORMAT_ARGB2101010:
+   case DRM_FORMAT_ABGR2101010:
+   case DRM_FORMAT_RGBA1010102:
+   case DRM_FORMAT_BGRA1010102:
+   case DRM_FORMAT_AYUV:
+   case DRM_FORMAT_XRGB_A8:
+   case DRM_FORMAT_XBGR_A8:
+   case DRM_FORMAT_RGBX_A8:
+   case DRM_FORMAT_BGRX_A8:
+   case DRM_FORMAT_RGB888_A8:
+   case DRM_FORMAT_BGR888_A8:
+   case DRM_FORMAT_RGB565_A8:
+   case DRM_FORMAT_BGR565_A8:
+   return true;
+
+   default:
+   return false;
+   }
+}
+EXPORT_SYMBOL(drm_format_has_alpha);
diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index 6942e84b6edd..e08fc22c5f78 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -69,5 +69,6 @@ int drm_format_vert_chroma_subsampling(uint32_t format);
 int drm_format_plane_width(int width, uint32_t format, int plane);
 int drm_format_plane_height(int height, uint32_t format, int plane);
 const char *drm_get_format_name(uint32_t format, struct drm_format_name_buf 
*buf);
+bool drm_format_has_alpha(uint32_t format);
 
 #endif /* __DRM_FOURCC_H__ */
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 03/19] drm/exynos: Use the alpha format helper

[Maxime Ripard]

Now that the core has a drm format helper to tell if a format embeds an
alpha component in it, let's use it.

Cc: Inki Dae 
Cc: Joonyoung Shim 
Cc: Kyungmin Park 
Cc: Seung-Woo Kim 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/exynos/exynos_mixer.c | 14 +-
 1 file changed, 1 insertion(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index dc5d79465f9b..d7339a6d072c 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -179,18 +179,6 @@ static const u8 filter_cr_horiz_tap4[] = {
70, 59, 48, 37, 27, 19, 11, 5,
 };
 
-static inline bool is_alpha_format(unsigned int pixel_format)
-{
-   switch (pixel_format) {
-   case DRM_FORMAT_ARGB:
-   case DRM_FORMAT_ARGB1555:
-   case DRM_FORMAT_ARGB:
-   return true;
-   default:
-   return false;
-   }
-}
-
 static inline u32 vp_reg_read(struct mixer_context *ctx, u32 reg_id)
 {
return readl(ctx->vp_regs + reg_id);
@@ -625,7 +613,7 @@ static void mixer_graph_buffer(struct mixer_context *ctx,
mixer_reg_write(ctx, MXR_GRAPHIC_BASE(win), dma_addr);
 
mixer_cfg_layer(ctx, win, priority, true);
-   mixer_cfg_gfx_blend(ctx, win, is_alpha_format(fb->format->format));
+   mixer_cfg_gfx_blend(ctx, win, drm_format_has_alpha(fb->format->format));
 
/* layer update mandatory for mixer 16.0.33.0 */
if (ctx->mxr_ver == MXR_VER_16_0_33_0 ||
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 10/19] drm/sun4i: backend: Fix define typo

[Maxime Ripard]

There was a typo in the width spelling of the (unused)
SUN4I_BACKEND_IYUVLINEWITDTH_REG macro. Fix it.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/sun4i/sun4i_backend.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.h 
b/drivers/gpu/drm/sun4i/sun4i_backend.h
index b5edf2d50a24..1ca8b7db6807 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.h
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.h
@@ -112,7 +112,9 @@
 #define SUN4I_BACKEND_SPRALPHACTL_REG  0x90c
 #define SUN4I_BACKEND_IYUVCTL_REG  0x920
 #define SUN4I_BACKEND_IYUVADD_REG(c)   (0x930 + (0x4 * (c)))
-#define SUN4I_BACKEND_IYUVLINEWITDTH_REG(c)(0x940 + (0x4 * (c)))
+
+#define SUN4I_BACKEND_IYUVLINEWIDTH_REG(c) (0x940 + (0x4 * (c)))
+
 #define SUN4I_BACKEND_YGCOEF_REG(c)(0x950 + (0x4 * (c)))
 #define SUN4I_BACKEND_YGCONS_REG   0x95c
 #define SUN4I_BACKEND_URCOEF_REG(c)(0x960 + (0x4 * (c)))
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 12/19] drm/sun4i: backend: Move the coord function in the shared part

[Maxime Ripard]

The function supposed to update a plane's coordinates is called in both
branches of our function. Let's move it out the if statement.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/sun4i/sun4i_layer.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_layer.c 
b/drivers/gpu/drm/sun4i/sun4i_layer.c
index f03da16eb92a..c448cb6b9fa9 100644
--- a/drivers/gpu/drm/sun4i/sun4i_layer.c
+++ b/drivers/gpu/drm/sun4i/sun4i_layer.c
@@ -106,14 +106,13 @@ static void sun4i_backend_layer_atomic_update(struct 
drm_plane *plane,
  DRM_FORMAT_ARGB);
sun4i_backend_update_layer_frontend(backend, layer->id,
DRM_FORMAT_ARGB);
-   sun4i_backend_update_layer_coord(backend, layer->id, plane);
sun4i_frontend_enable(frontend);
} else {
-   sun4i_backend_update_layer_coord(backend, layer->id, plane);
sun4i_backend_update_layer_formats(backend, layer->id, plane);
sun4i_backend_update_layer_buffer(backend, layer->id, plane);
}
 
+   sun4i_backend_update_layer_coord(backend, layer->id, plane);
sun4i_backend_layer_enable(backend, layer->id, true);
 }
 
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 11/19] drm/sun4i: framebuffer: Add a custom atomic_check

[Maxime Ripard]

In order to support normalized zpos, we need to call
drm_atomic_normalize_zpos in our driver's drm_mode_config_funcs'
atomic_check.

Let's duplicate the definition of drm_atomic_helper_check for now.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/sun4i/sun4i_framebuffer.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_framebuffer.c 
b/drivers/gpu/drm/sun4i/sun4i_framebuffer.c
index a01a5b7d46e6..e68004844abe 100644
--- a/drivers/gpu/drm/sun4i/sun4i_framebuffer.c
+++ b/drivers/gpu/drm/sun4i/sun4i_framebuffer.c
@@ -26,9 +26,21 @@ static void sun4i_de_output_poll_changed(struct drm_device 
*drm)
drm_fbdev_cma_hotplug_event(drv->fbdev);
 }
 
+static int sun4i_de_atomic_check(struct drm_device *dev,
+struct drm_atomic_state *state)
+{
+   int ret;
+
+   ret = drm_atomic_helper_check_modeset(dev, state);
+   if (ret)
+   return ret;
+
+   return drm_atomic_helper_check_planes(dev, state);
+}
+
 static const struct drm_mode_config_funcs sun4i_de_mode_config_funcs = {
.output_poll_changed= sun4i_de_output_poll_changed,
-   .atomic_check   = drm_atomic_helper_check,
+   .atomic_check   = sun4i_de_atomic_check,
.atomic_commit  = drm_atomic_helper_commit,
.fb_create  = drm_gem_fb_create,
 };
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 00/19] drm/sun4i: Support more planes, zpos and plane-wide alpha

[Maxime Ripard]

Hi,

This serie aims at enhancing the support for our planes in the current drm
driver on the first generation of Allwinner's display engine.

This also introduces a few generic stuff, as well as some conversion for
some other drivers.

This series basically implements three things that look orthogonal, but due
to the way the hardware works are kind of related.

The main feature is that instead of implementing 2 planes per backend, we
are now able to use the planes that are available in hardware. This was
unsupported before because of the way the composition works in the
hardware.

Indeed, the planes are first grouped into 2 pipes that are doing a basic
composition, in case of overlapping planes, it just takes whatever plane
has the highest priority (=> zpos). Then, the alpha blending is done
between the two pipes. This was simplified so far by only using two planes,
one for each pipe, which was allowing us to have an illusion of proper
alpha blending. This is further complicated by the bug/feature that the
lowest plane must not have any alpha at all, otherwise the pixel will turn
black, no matter what the value of alpha is. This basically means that we
can have a plane with alpha only in the second pipe.

However, as we have more and more blocks being worked on, 2 planes are
getting really limited and we need to support all 4 of them.

This is mostly possible by extending our atomic_check and to make sure that
we enforce those constraints, and assign the pipes automatically. This is
done by looking at the number of planes using an alpha component, and we
then end up in various scenarios:
  - 0 plane with alpha
=> we don't care for the pipes at all. All the planes are assigned to
   the first pipe
  - 1 plane with alpha
=> we assign all the planes without alpha below the plane with alpha to
   the first pipe, and then all the remaining planes to the second
   pipe. The plane with alpha will be the lowest plane on that pipe,
   which means that whatever plane is above it will have precedence,
   but the alpha component will remain and will be used on pixels that
   are not overlapping
  - 2-4 planes with alpha
=> we can't operate that way, we just reject the configuration.

In addition to the formats that embed an alpha component, we also add
support for plane-wide alpha property, and in order to tweak the
configuration the way we want to, we also add support for configurable
zpos.

Let me know what you think,
Maxime

Maxime Ripard (19):
  drm/fourcc: Add a function to tell if the format embeds alpha
  drm/atmel-hlcdc: Use the alpha format helper
  drm/exynos: Use the alpha format helper
  drm/rockchip: Use the alpha format helper
  drm/vc4: Use the alpha format helper
  drm/blend: Add a generic alpha property
  drm/atmel-hclcdc: Convert to the new generic alpha property
  drm/rcar-du: Convert to the new generic alpha property
  drm/sun4i: backend: Fix structure indentation
  drm/sun4i: backend: Fix define typo
  drm/sun4i: framebuffer: Add a custom atomic_check
  drm/sun4i: backend: Move the coord function in the shared part
  drm/sun4i: backend: Set a default zpos in our reset hook
  drm/sun4i: backend: Add support for zpos
  drm/sun4i: backend: Check for the number of alpha planes
  drm/sun4i: backend: Assign the pipes automatically
  drm/sun4i: backend: Make zpos configurable
  drm/sun4i: Add support for plane alpha
  drm/sun4i: backend: Remove ARGB spoofing

 Documentation/gpu/kms-properties.csv|   2 +-
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h|  13 +--
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 109 ++-
 drivers/gpu/drm/drm_atomic.c|   4 +-
 drivers/gpu/drm/drm_atomic_helper.c |   1 +-
 drivers/gpu/drm/drm_blend.c |  32 -
 drivers/gpu/drm/drm_fourcc.c|  43 ++-
 drivers/gpu/drm/exynos/exynos_mixer.c   |  14 +--
 drivers/gpu/drm/rcar-du/rcar_du_drv.h   |   1 +-
 drivers/gpu/drm/rcar-du/rcar_du_kms.c   |   5 +-
 drivers/gpu/drm/rcar-du/rcar_du_plane.c |  15 +--
 drivers/gpu/drm/rcar-du/rcar_du_plane.h |   2 +-
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c   |  42 +--
 drivers/gpu/drm/rcar-du/rcar_du_vsp.h   |   2 +-
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  13 +--
 drivers/gpu/drm/sun4i/sun4i_backend.c   | 126 +++--
 drivers/gpu/drm/sun4i/sun4i_backend.h   |  11 +-
 drivers/gpu/drm/sun4i/sun4i_framebuffer.c   |  18 +-
 drivers/gpu/drm/sun4i/sun4i_layer.c |  84 ++-
 drivers/gpu/drm/sun4i/sun4i_layer.h |   1 +-
 drivers/gpu/drm/vc4/vc4_plane.c |  19 +--
 include/drm/drm_blend.h |   1 +-
 include/drm/drm_fourcc.h|   1 +-
 include/drm/drm_plane.h |   6 +-
 24 files changed, 289 insertions(+), 276 deletions(-)

base-commit: 53b519deaf2e507b121b64

Re: [PATCH] drm/bridge/synopsys: dsi: use common mipi_dsi_create_packet()

[Philippe CORNU]

Hi Brian,

And many thanks for implementing these TODOs.

On 01/06/2018 01:38 AM, Brian Norris wrote:
> This takes care of 2 TODOs in this driver, by using the common DSI
> packet-marshalling code instead of our custom short/long write code.
> This both saves us some duplicated code and gets us free support for
> command types that weren't already part of our switch block (e.g.,
> MIPI_DSI_GENERIC_LONG_WRITE).
> 
> The code logic stays mostly intact, except that it becomes unnecessary
> to split the short/long write functions, and we have to copy data a bit
> more.
> 
> Along the way, I noticed that loop bounds were a little odd:
> 
>   while (DIV_ROUND_UP(len, pld_data_bytes))
> 
> This really was just supposed to be 'len != 0', so I made that more
> clear.
> 
> Tested on RK3399 with some pending refactoring patches by Nickey Yang,
> to make the Rockchip DSI driver wrap this common driver.
> 
> Signed-off-by: Brian Norris 
> ---
> Could use an extra look from folks. This looks like the correct trivial
> transformation, but I'm not that familiar with DSI.
> 
>   drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 78 
> ++-
>   1 file changed, 16 insertions(+), 62 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> index d9cca4fd66ec..2fed20e44dfe 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> @@ -136,10 +136,6 @@
>GEN_SW_0P_TX_LP)
>   
>   #define DSI_GEN_HDR 0x6c
> -/* TODO These 2 defines will be reworked thanks to mipi_dsi_create_packet() 
> */
> -#define GEN_HDATA(data)  (((data) & 0x) << 8)
> -#define GEN_HTYPE(type)  (((type) & 0xff) << 0)
> -
>   #define DSI_GEN_PLD_DATA0x70
>   
>   #define DSI_CMD_PKT_STATUS  0x74
> @@ -359,44 +355,15 @@ static int dw_mipi_dsi_gen_pkt_hdr_write(struct 
> dw_mipi_dsi *dsi, u32 hdr_val)
>   return 0;
>   }
>   
> -static int dw_mipi_dsi_dcs_short_write(struct dw_mipi_dsi *dsi,
> -const struct mipi_dsi_msg *msg)
> -{
> - const u8 *tx_buf = msg->tx_buf;
> - u16 data = 0;
> - u32 val;
> -
> - if (msg->tx_len > 0)
> - data |= tx_buf[0];
> - if (msg->tx_len > 1)
> - data |= tx_buf[1] << 8;
> -
> - if (msg->tx_len > 2) {
> - dev_err(dsi->dev, "too long tx buf length %zu for short 
> write\n",
> - msg->tx_len);
> - return -EINVAL;
> - }
> -
> - val = GEN_HDATA(data) | GEN_HTYPE(msg->type);
> - return dw_mipi_dsi_gen_pkt_hdr_write(dsi, val);
> -}
> -
> -static int dw_mipi_dsi_dcs_long_write(struct dw_mipi_dsi *dsi,
> -   const struct mipi_dsi_msg *msg)
> +static int dw_mipi_dsi_dcs_write(struct dw_mipi_dsi *dsi,
> +  const struct mipi_dsi_packet *packet)

Both DCS and Generic dsi transfers are managed by drm_mipi_dsi.c 
helpers. So maybe dw_mipi_dsi_dcs_write() should be renamed 
dw_mipi_dsi_write()...


>   {
> - const u8 *tx_buf = msg->tx_buf;
> - int len = msg->tx_len, pld_data_bytes = sizeof(u32), ret;
> - u32 hdr_val = GEN_HDATA(msg->tx_len) | GEN_HTYPE(msg->type);
> + const u8 *tx_buf = packet->payload;
> + int len = packet->payload_length, pld_data_bytes = sizeof(u32), ret;
>   u32 remainder;
>   u32 val;
>   
> - if (msg->tx_len < 3) {
> - dev_err(dsi->dev, "wrong tx buf length %zu for long write\n",
> - msg->tx_len);
> - return -EINVAL;
> - }
> -
> - while (DIV_ROUND_UP(len, pld_data_bytes)) {
> + while (len) {
>   if (len < pld_data_bytes) {
>   remainder = 0;
>   memcpy(&remainder, tx_buf, len);
> @@ -419,40 +386,27 @@ static int dw_mipi_dsi_dcs_long_write(struct 
> dw_mipi_dsi *dsi,
>   }
>   }
>   
> - return dw_mipi_dsi_gen_pkt_hdr_write(dsi, hdr_val);
> + remainder = 0;
> + memcpy(&remainder, packet->header, sizeof(packet->header));
> + return dw_mipi_dsi_gen_pkt_hdr_write(dsi, remainder);
>   }
>   
>   static ssize_t dw_mipi_dsi_host_transfer(struct mipi_dsi_host *host,
>const struct mipi_dsi_msg *msg)
>   {
>   struct dw_mipi_dsi *dsi = host_to_dsi(host);
> + struct mipi_dsi_packet packet;
>   int ret;
>   
> - /*
> -  * TODO dw drv improvements
> -  * use mipi_dsi_create_packet() instead of all following
> -  * functions and code (no switch cases, no
> -  * dw_mipi_dsi_dcs_short_write(), only the loop in long_write...)
> -  * and use packet.header...
> -  */
> - dw_mipi_message_config(dsi, msg);
> -
> - switch (msg->type) {
> - case MIPI_DSI_DCS_SHORT_WRITE:
> - case MIPI_DSI_DCS_SHORT_WRITE_PARAM:
> -

Re: [RFC v2 7/8] drm/fb-helper: Add generic fbdev emulation

[Daniel Vetter]

On Wed, Jan 03, 2018 at 11:21:09PM +0100, Noralf Trønnes wrote:
> Add generic fbdev emulation which uses a drm_file to get a dumb_buffer
> and drm_framebuffer. The buffer is exported and vmap/mmap called on
> the dma-buf.
> 
> Signed-off-by: Noralf Trønnes 
> ---
>  drivers/gpu/drm/drm_fb_helper.c | 301 
> +++-
>  include/drm/drm_fb_helper.h |  33 +
>  2 files changed, 333 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index f9dcc7a5761f..270ff6dc8045 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -30,12 +30,15 @@
>  #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -1951,7 +1954,9 @@ static int drm_fb_helper_single_fb_probe(struct 
> drm_fb_helper *fb_helper,
>   if (fb_helper->fbdev->fbops->fb_open == drm_fb_helper_fb_open)
>   atomic_set(&fb_helper->open_count, 0);
>  
> - strcpy(fb_helper->fb->comm, "[fbcon]");
> + if (fb_helper->fb)
> + strcpy(fb_helper->fb->comm, "[fbcon]");
> +
>   return 0;
>  }
>  
> @@ -2975,6 +2980,300 @@ void drm_fb_helper_output_poll_changed(struct 
> drm_device *dev)
>  }
>  EXPORT_SYMBOL(drm_fb_helper_output_poll_changed);
>  
> +static struct fb_deferred_io drm_fb_helper_generic_defio = {
> + .delay  = HZ / 20,
> + .deferred_io= drm_fb_helper_deferred_io,
> +};
> +
> +static int drm_fb_helper_generic_alloc_buf(struct drm_fb_helper *fb_helper)
> +{
> + struct drm_fb_helper_surface_size *sizes = &fb_helper->sizes;
> + struct drm_mode_create_dumb dumb_args = { 0 };
> + struct drm_prime_handle prime_args = { 0 };
> + struct drm_mode_fb_cmd2 fb_args = { 0 };
> + struct drm_device *dev = fb_helper->dev;
> + struct fb_info *fbi = fb_helper->fbdev;
> + struct drm_framebuffer *fb;
> + struct dma_buf *dma_buf;
> + struct drm_file *file;
> + void *vaddr;
> + int ret;
> +
> + file = drm_file_alloc(dev->primary);
> + if (IS_ERR(file))
> + return PTR_ERR(file);
> +
> + drm_dropmaster_ioctl(dev, NULL, file);

Hm  why do we need this? Feels a bit like drm_file_alloc shouldn't do
the entire master dance for us ...

Otherwise this looks awesome, I really like it.

Reviewed-by: Daniel Vetter 
-Daniel

> +
> + dumb_args.width = sizes->surface_width;
> + dumb_args.height = sizes->surface_height;
> + dumb_args.bpp = sizes->surface_bpp;
> + ret = drm_mode_create_dumb_ioctl(dev, &dumb_args, file);
> + if (ret)
> + goto err_free_file;
> +
> + fb_args.width = dumb_args.width;
> + fb_args.height = dumb_args.height;
> + fb_args.pixel_format = drm_mode_legacy_fb_format(sizes->surface_bpp,
> +  sizes->surface_depth);
> + fb_args.handles[0] = dumb_args.handle;
> + fb_args.pitches[0] = dumb_args.pitch;
> + ret = drm_mode_addfb2(dev, &fb_args, file);
> + if (ret)
> + goto err_free_file;
> +
> + fb = drm_framebuffer_lookup(dev, file, fb_args.fb_id);
> + if (!fb) {
> + ret = -ENOENT;
> + goto err_free_file;
> + }
> +
> + /* drop the reference we picked up in framebuffer lookup */
> + drm_framebuffer_put(fb);
> +
> + strcpy(fb->comm, "[fbcon]");
> +
> + prime_args.handle = dumb_args.handle;
> + ret = drm_prime_handle_to_fd_ioctl(dev, &prime_args, file);
> + if (ret)
> + goto err_free_file;
> +
> + dma_buf = dma_buf_get(prime_args.fd);
> + if (WARN_ON(IS_ERR(dma_buf))) {
> + ret = PTR_ERR(dma_buf);
> + goto err_free_file;
> + }
> +
> + vaddr = dma_buf_vmap(dma_buf);
> + if (!vaddr) {
> + ret = -ENOMEM;
> + goto err_put_dmabuf;
> + }
> +
> + if (fb->funcs->dirty) {
> + fbi->fbdefio = &drm_fb_helper_generic_defio;
> + fb_deferred_io_init(fbi);
> + }
> +
> + fbi->screen_size = fb->height * fb->pitches[0];
> + fbi->fix.smem_len = fbi->screen_size;
> + fbi->screen_buffer = vaddr;
> +
> + fb_helper->dma_buf = dma_buf;
> + fb_helper->file = file;
> +
> + mutex_lock(&fb_helper->lock);
> + fb_helper->fb = fb;
> + drm_setup_crtcs_fb(fb_helper);
> + mutex_unlock(&fb_helper->lock);
> +
> + /* First time setup */
> + if (!fbi->var.bits_per_pixel) {
> + struct fb_videomode mode;
> +
> + drm_fb_helper_fill_fix(fbi, fb->pitches[0], fb->format->depth);
> + drm_fb_helper_fill_var(fbi, fb_helper, sizes->fb_width, 
> sizes->fb_height);
> +
> + /* Drop the mode added by register_framebuffer() */
> + fb_destroy_modelist(&fb_helper->fbdev->modelist);
> +
> + fb_var_to_vide

Re: [PATCH 04/11] drm/bridge/synopsys: dw-hdmi: Export some PHY related functions

[Archit Taneja]

On 12/31/2017 02:31 AM, Jernej Skrabec wrote:

Parts of PHY code could be useful also for custom PHYs. For example,
Allwinner A83T has custom PHY which is probably Synopsys gen2 PHY
with few additional memory mapped registers, so most of the Synopsys PHY
related code could be reused.

It turns out that even completely custom HDMI PHYs, such as the one
found in Allwinner H3, can reuse some of those functions. This would
suggest that (some?) functions exported in this commit are actually part
of generic PHY interface and not really specific to Synopsys PHYs.

Export useful PHY functions.

Signed-off-by: Jernej Skrabec 
---
  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 45 ++-
  drivers/gpu/drm/bridge/synopsys/dw-hdmi.h |  2 ++
  include/drm/bridge/dw_hdmi.h  | 10 +++
  3 files changed, 44 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 7ca14d7325b5..67467d0b683a 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1037,19 +1037,21 @@ static void dw_hdmi_phy_enable_svsret(struct dw_hdmi 
*hdmi, u8 enable)
 HDMI_PHY_CONF0_SVSRET_MASK);
  }
  
-static void dw_hdmi_phy_gen2_pddq(struct dw_hdmi *hdmi, u8 enable)

+void dw_hdmi_phy_gen2_pddq(struct dw_hdmi *hdmi, u8 enable)
  {
hdmi_mask_writeb(hdmi, enable, HDMI_PHY_CONF0,
 HDMI_PHY_CONF0_GEN2_PDDQ_OFFSET,
 HDMI_PHY_CONF0_GEN2_PDDQ_MASK);
  }
+EXPORT_SYMBOL_GPL(dw_hdmi_phy_gen2_pddq);
  
-static void dw_hdmi_phy_gen2_txpwron(struct dw_hdmi *hdmi, u8 enable)

+void dw_hdmi_phy_gen2_txpwron(struct dw_hdmi *hdmi, u8 enable)
  {
hdmi_mask_writeb(hdmi, enable, HDMI_PHY_CONF0,
 HDMI_PHY_CONF0_GEN2_TXPWRON_OFFSET,
 HDMI_PHY_CONF0_GEN2_TXPWRON_MASK);
  }
+EXPORT_SYMBOL_GPL(dw_hdmi_phy_gen2_txpwron);
  
  static void dw_hdmi_phy_sel_data_en_pol(struct dw_hdmi *hdmi, u8 enable)

  {
@@ -1065,6 +1067,23 @@ static void dw_hdmi_phy_sel_interface_control(struct 
dw_hdmi *hdmi, u8 enable)
 HDMI_PHY_CONF0_SELDIPIF_MASK);
  }
  
+void dw_hdmi_phy_gen2_reset(struct dw_hdmi *hdmi, u8 enable)

+{
+   hdmi_mask_writeb(hdmi, enable, HDMI_MC_PHYRSTZ,
+HDMI_MC_PHYRSTZ_PHYRSTZ_OFFSET,
+HDMI_MC_PHYRSTZ_PHYRSTZ_MASK);
+}
+EXPORT_SYMBOL_GPL(dw_hdmi_phy_gen2_reset);
+
+void dw_hdmi_phy_set_slave_addr(struct dw_hdmi *hdmi)
+{
+   hdmi_phy_test_clear(hdmi, 1);
+   hdmi_writeb(hdmi, HDMI_PHY_I2CM_SLAVE_ADDR_PHY_GEN2,
+   HDMI_PHY_I2CM_SLAVE_ADDR);
+   hdmi_phy_test_clear(hdmi, 0);
+}
+EXPORT_SYMBOL_GPL(dw_hdmi_phy_set_slave_addr);


Should this be called dw_hdmi_phy_gen2_set_slave_addr?

Looks good otherwise. Same for patches 3 and 4 in this series.

Thanks,
Archit


+
  static void dw_hdmi_phy_power_off(struct dw_hdmi *hdmi)
  {
const struct dw_hdmi_phy_data *phy = hdmi->phy.data;
@@ -1204,15 +1223,12 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi)
dw_hdmi_phy_enable_svsret(hdmi, 1);
  
  	/* PHY reset. The reset signal is active high on Gen2 PHYs. */

-   hdmi_writeb(hdmi, HDMI_MC_PHYRSTZ_PHYRSTZ, HDMI_MC_PHYRSTZ);
-   hdmi_writeb(hdmi, 0, HDMI_MC_PHYRSTZ);
+   dw_hdmi_phy_gen2_reset(hdmi, 1);
+   dw_hdmi_phy_gen2_reset(hdmi, 0);
  
  	hdmi_writeb(hdmi, HDMI_MC_HEACPHY_RST_ASSERT, HDMI_MC_HEACPHY_RST);
  
-	hdmi_phy_test_clear(hdmi, 1);

-   hdmi_writeb(hdmi, HDMI_PHY_I2CM_SLAVE_ADDR_PHY_GEN2,
-   HDMI_PHY_I2CM_SLAVE_ADDR);
-   hdmi_phy_test_clear(hdmi, 0);
+   dw_hdmi_phy_set_slave_addr(hdmi);
  
  	/* Write to the PHY as configured by the platform */

if (pdata->configure_phy)
@@ -1251,15 +1267,16 @@ static void dw_hdmi_phy_disable(struct dw_hdmi *hdmi, 
void *data)
dw_hdmi_phy_power_off(hdmi);
  }
  
-static enum drm_connector_status dw_hdmi_phy_read_hpd(struct dw_hdmi *hdmi,

- void *data)
+enum drm_connector_status dw_hdmi_phy_read_hpd(struct dw_hdmi *hdmi,
+  void *data)
  {
return hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_HPD ?
connector_status_connected : connector_status_disconnected;
  }
+EXPORT_SYMBOL_GPL(dw_hdmi_phy_read_hpd);
  
-static void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,

-  bool force, bool disabled, bool rxsense)
+void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
+   bool force, bool disabled, bool rxsense)
  {
u8 old_mask = hdmi->phy_mask;
  
@@ -1271,8 +1288,9 @@ static void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,

if (old_mask != hdmi->phy_mask)
hdmi_writeb(hdmi, hdmi->phy_mask, HDMI_PHY_MASK0);
  }
+EX

Re: [RFC v2 6/8] drm: Handle fbdev emulation in core

[Daniel Vetter]

On Wed, Jan 03, 2018 at 11:21:08PM +0100, Noralf Trønnes wrote:
> Prepare for generic fbdev emulation by letting DRM core work directly
> with the fbdev compatibility layer. This is done by adding new fbdev
> helper vtable callbacks for restore, hotplug_event, unregister and
> release.
> 
> Signed-off-by: Noralf Trønnes 

No clue whether my idea is any good, but inspired by the bootsplash
discussion, and the prospect that we might get other in-kernel drm/kms
clients I'm wondering whether we should make this a bit more generic and
tie it to drm_file?

The idea would be to have a list of internal drm clients by putting all
the internal drm_files onto a list (same way we do with the userspace
ones). Then we'd just walk that list and call ->hotplug, ->unregister and
->release at the right places.

->restore would be a bit different, I guess for that we'd only call the
->restore callback of the very first kernel-internal client.

With that we could then add/remove kernel-internal drm clients like normal
userspace clients, which should make integration of emergency consoles,
boot splashes and whatever else real easy. And I think it would be a lot
cleaner than leaking fb_helper knowledge into the drm core, which feels a
rather backwards.

Otoh that feels a bit overengineered (but at least it shouldn't be a lot
more code really). If the list is too much work we could start with 1
drm_file * pointer for internal stuff (but would still need locking, so
list_head is probably easier).

Thoughts?
-Daniel

> ---
>  drivers/gpu/drm/drm_file.c | 12 +++-
>  drivers/gpu/drm/drm_mode_config.c  | 10 ++
>  drivers/gpu/drm/drm_probe_helper.c |  4 
>  include/drm/drm_fb_helper.h| 33 +
>  4 files changed, 58 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> index 400d44437e93..7ec09fb83135 100644
> --- a/drivers/gpu/drm/drm_file.c
> +++ b/drivers/gpu/drm/drm_file.c
> @@ -35,6 +35,7 @@
>  #include 
>  #include 
>  
> +#include 
>  #include 
>  #include 
>  
> @@ -441,10 +442,19 @@ static void drm_legacy_dev_reinit(struct drm_device 
> *dev)
>  
>  void drm_lastclose(struct drm_device * dev)
>  {
> + struct drm_fb_helper *fb_helper = dev->fb_helper;
> + int ret;
> +
>   DRM_DEBUG("\n");
>  
> - if (dev->driver->lastclose)
> + if (dev->driver->lastclose) {
>   dev->driver->lastclose(dev);
> + } else if (fb_helper && fb_helper->funcs && fb_helper->funcs->restore) {
> + ret = fb_helper->funcs->restore(fb_helper);
> + if (ret)
> + DRM_ERROR("Failed to restore fbdev: %d\n", ret);
> + }
> +
>   DRM_DEBUG("driver lastclose completed\n");
>  
>   if (drm_core_check_feature(dev, DRIVER_LEGACY))
> diff --git a/drivers/gpu/drm/drm_mode_config.c 
> b/drivers/gpu/drm/drm_mode_config.c
> index bc5c46306b3d..260eb1730244 100644
> --- a/drivers/gpu/drm/drm_mode_config.c
> +++ b/drivers/gpu/drm/drm_mode_config.c
> @@ -21,6 +21,7 @@
>   */
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -61,6 +62,11 @@ int drm_modeset_register_all(struct drm_device *dev)
>  
>  void drm_modeset_unregister_all(struct drm_device *dev)
>  {
> + struct drm_fb_helper *fb_helper = dev->fb_helper;
> +
> + if (fb_helper && fb_helper->funcs && fb_helper->funcs->unregister)
> + fb_helper->funcs->unregister(fb_helper);
> +
>   drm_connector_unregister_all(dev);
>   drm_encoder_unregister_all(dev);
>   drm_crtc_unregister_all(dev);
> @@ -408,6 +414,7 @@ EXPORT_SYMBOL(drm_mode_config_init);
>   */
>  void drm_mode_config_cleanup(struct drm_device *dev)
>  {
> + struct drm_fb_helper *fb_helper = dev->fb_helper;
>   struct drm_connector *connector;
>   struct drm_connector_list_iter conn_iter;
>   struct drm_crtc *crtc, *ct;
> @@ -417,6 +424,9 @@ void drm_mode_config_cleanup(struct drm_device *dev)
>   struct drm_property_blob *blob, *bt;
>   struct drm_plane *plane, *plt;
>  
> + if (fb_helper && fb_helper->funcs && fb_helper->funcs->release)
> + fb_helper->funcs->release(fb_helper);
> +
>   list_for_each_entry_safe(encoder, enct, &dev->mode_config.encoder_list,
>head) {
>   encoder->funcs->destroy(encoder);
> diff --git a/drivers/gpu/drm/drm_probe_helper.c 
> b/drivers/gpu/drm/drm_probe_helper.c
> index 555fbe54d6e2..9d8b0ba54173 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -559,10 +559,14 @@ EXPORT_SYMBOL(drm_helper_probe_single_connector_modes);
>   */
>  void drm_kms_helper_hotplug_event(struct drm_device *dev)
>  {
> + struct drm_fb_helper *fb_helper = dev->fb_helper;
> +
>   /* 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);
> +