Re: [RFC][PATCH] libdrm: gralloc_handle.h: Fix build issue with Android

[Robert Foss]

Hey John,

On 03/16/2018 10:48 PM, John Stultz wrote:

In trying to integrate the new gralloc_handle.h with the
drm_hwcomposer, I started seeing the following compilation
errors:

In file included from external/drm_hwcomposer/platformdrmgeneric.cpp:28:
external/libdrm/android/gralloc_handle.h:108:9: error: cannot initialize return 
object of type 'native_handle_t *' (aka 'native_handle *') with an lvalue of 
type 'struct gralloc_handle_t *'
 return handle;
^~
1 error generated.

This seems to be due to the gralloc_handle_create() definition
claiming to return a native_handle_t * type, rather then a
gralloc_handle_t *, which is what the code actually returns.

This function isn't actually used in the current drm_hwcomposer,
so I'm not totally sure that this fix is correct (rather then
returning the gralloc_handle_t's embadedded native_handle_t ptr).

But it seems something like this is needed.

Cc: Robert Foss 
Cc: Rob Herring 
Cc: Sean Paul 
Signed-off-by: John Stultz 
---
  android/gralloc_handle.h | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/android/gralloc_handle.h b/android/gralloc_handle.h
index 9cb5a5d..6e925c9 100644
--- a/android/gralloc_handle.h
+++ b/android/gralloc_handle.h
@@ -84,7 +84,7 @@ static inline struct gralloc_handle_t 
*gralloc_handle(buffer_handle_t handle)
  /**
   * Create a buffer handle.
   */
-static inline native_handle_t *gralloc_handle_create(int32_t width,
+static inline gralloc_handle_t *gralloc_handle_create(int32_t width,
   int32_t height,
   int32_t hal_format,
   int32_t usage)
@@ -107,5 +107,4 @@ static inline native_handle_t 
*gralloc_handle_create(int32_t width,
  
  	return handle;

  }
-
  #endif



The gralloc_handle_t regturn type seems to be the correct one to me.

This patch is:
Reviewed-by: Robert Foss 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 198123] Console is the wrong color at boot with radeon 6670

[bugzilla-daemon]

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

--- Comment #47 from sh...@tuta.io ---
I analysed individual bits in register dumps. Some bits are set in all 8 dumps
with black background and unset in most of dumps with grey background.

The value at 0x69F0 is 0x00401004 in all black dumps, vary in grey dumps.

The value at 0x69FC is 0x0002 in all black dumps, 0x in all grey
dumps.

Other registers, least significant bit first:

6BB0  0 + ? ? ? ? ? ?  ? ? ? 0 0 0 0 0  0 0 0 0 0 0 0 0  0 0 0 0 0 0 0 0
6E98  ? ? + ? ? ? ? ?  ? 1 0 0 0 0 0 0  0 0 0 0 0 0 0 0  0 0 0 0 0 0 0 0
6E9C  ? ? + ? ? ? ? ?  ? 1 0 0 0 0 0 0  ? ? ? ? ? ? ? ?  ? ? ? 0 0 0 0 0

Legend:
0 always 0 in black dumps
1 always 1 in black dumps
? vary in black dumps
+ always 1 in black dumps, usually 0 in grey dumps

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

[RESEND PATCH libdrm] tests: fix memory leak issue

[Inki Dae]

Fixed memory leak issue to drmModeRes and drmModePlaneRes objects.

These objects were allocated by drmModeGetResources and
drmModeGetPlaneResources functions but not freed properly.

So this patch frees them by calling drmModeFreeResources
drmModeFreePlaneResources functions at failure case.

Signed-off-by: Inki Dae 
---
 tests/kms/libkms-test-device.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/tests/kms/libkms-test-device.c b/tests/kms/libkms-test-device.c
index 53c7349..042ae05 100644
--- a/tests/kms/libkms-test-device.c
+++ b/tests/kms/libkms-test-device.c
@@ -67,7 +67,7 @@ static void kms_device_probe_screens(struct kms_device 
*device)
 
device->screens = calloc(res->count_connectors, sizeof(screen));
if (!device->screens)
-   return;
+   goto err_free_resources;
 
for (i = 0; i < res->count_connectors; i++) {
unsigned int *count;
@@ -97,6 +97,7 @@ static void kms_device_probe_screens(struct kms_device 
*device)
device->num_screens++;
}
 
+err_free_resources:
drmModeFreeResources(res);
 }
 
@@ -112,7 +113,7 @@ static void kms_device_probe_crtcs(struct kms_device 
*device)
 
device->crtcs = calloc(res->count_crtcs, sizeof(crtc));
if (!device->crtcs)
-   return;
+   goto err_free_resources;
 
for (i = 0; i < res->count_crtcs; i++) {
crtc = kms_crtc_create(device, res->crtcs[i]);
@@ -123,6 +124,7 @@ static void kms_device_probe_crtcs(struct kms_device 
*device)
device->num_crtcs++;
}
 
+err_free_resources:
drmModeFreeResources(res);
 }
 
@@ -138,7 +140,7 @@ static void kms_device_probe_planes(struct kms_device 
*device)
 
device->planes = calloc(res->count_planes, sizeof(plane));
if (!device->planes)
-   return;
+   goto err_free_resources;
 
for (i = 0; i < res->count_planes; i++) {
plane = kms_plane_create(device, res->planes[i]);
@@ -149,6 +151,7 @@ static void kms_device_probe_planes(struct kms_device 
*device)
device->num_planes++;
}
 
+err_free_resources:
drmModeFreePlaneResources(res);
 }
 
-- 
1.9.1

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

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

[Stefan Schake]

On Tue, Mar 20, 2018 at 2:49 AM, John Stultz  wrote:
> On Tue, Mar 20, 2018 at 6:55 AM, Stefan Schake  wrote:
>> Hey John,
>>
>> On Wed, Mar 14, 2018 at 5:47 PM, John Stultz  wrote:
>>> 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.
>>
>> I'm afraid this change has snowballed straight into the mesa build where
>> it's now missing dependencies for i915_dri:
>>
>> external/mesa3d/src/mesa/drivers/dri/i915/Android.mk: error:
>> i915_dri (SHARED_LIBRARIES android-arm) missing libdrm_intel
>>
>> Maybe that one needs the BOARD_GPU_DRIVERS treatment instead..
>
> So tinkering here, it seems to me just changing the conditionalizing
> to skipping over just the libpciaccess addition to
> LOCAL_SHARED_LIBRARIES might be a simpler solution.
>
> Or would you see that as too ugly?

I guess my real problem is with libpciaccess itself. Okay, we can't ding
it for not being in AOSP, plenty of upstream Android isn't. But then the
freedesktop/upstream repo of libpciaccess doesn't support Android build,
the copies I found on Android-x86 and intel-ia are outdated and the latter
doesn't seem to have it in its manifest. Beyond that, the only reference is
in intel_bufmgr that if I understood the other discussion correctly is no
longer used in Mesa?

But that's mostly ranting, I don't even have any Intel hardware I use for
Android. So I guess in the spirit of achieving the original goal of making
that annoying error go away, ignoring only libpciaccess is just as well.

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

[PATCH libdrm] tests: fix memory leak issue

[Inki Dae]

Fixed memory leak issue to drmModeRes object.

This object was allocated by drmModeGetResources function
but not freed when device->screens failed.

So this patch frees the drmModeRes object when device->screens failed
by calling drmModeFreeResources function.

Signed-off-by: Inki Dae 
---
 tests/kms/libkms-test-device.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tests/kms/libkms-test-device.c b/tests/kms/libkms-test-device.c
index 53c7349..8127aa7 100644
--- a/tests/kms/libkms-test-device.c
+++ b/tests/kms/libkms-test-device.c
@@ -112,7 +112,7 @@ static void kms_device_probe_crtcs(struct kms_device 
*device)
 
device->crtcs = calloc(res->count_crtcs, sizeof(crtc));
if (!device->crtcs)
-   return;
+   goto err_free_resources;
 
for (i = 0; i < res->count_crtcs; i++) {
crtc = kms_crtc_create(device, res->crtcs[i]);
@@ -123,6 +123,7 @@ static void kms_device_probe_crtcs(struct kms_device 
*device)
device->num_crtcs++;
}
 
+err_free_resources:
drmModeFreeResources(res);
 }
 
-- 
1.9.1

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

[RFC][PATCH] libdrm: intel/Android.mk: Limit x86/x86_64 filtering to just libpciaccess

[John Stultz]

In ed07718ae7ba ("libdrm: intel/Android.mk: Filter libdrm_intel
library requirements on x86/x86_64"), I avoided including the
logic from intel/Android.mk on non-x86 based builds.

This was done to avoid the inclusion of the libpciaccess library
as a build requirement. As a side effect, it removed the
libdrm_intel target. This then caused trouble on non-x86 builds
that use mesa3d, as its Android.mk files include the libdrm_intel
as a build target.

So instead of removing everything, this patch fixes the previous
change to just remove the libpciaccess library as a build
dependency on non-x86 builds.

Validated on both hikey960 (no mesa3d) and db410c (with mesa3d)
builds.

Cc: Rob Herring 
Cc: Sean Paul 
Cc: Robert Foss 
Cc: Emil Velikov 
Cc: Tomasz Figa 
Cc: Marissa Wall 
Cc: Dan Willemsen 
Fixes: ed07718ae7ba ("libdrm: intel/Android.mk: Filter
   libdrm_intel library requirements on x86/x86_64")
Reported-by: Stefan Schake 
Signed-off-by: John Stultz 
---
 intel/Android.mk | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/intel/Android.mk b/intel/Android.mk
index 3f9db78..5e144f8 100644
--- a/intel/Android.mk
+++ b/intel/Android.mk
@@ -21,7 +21,6 @@
 # IN THE SOFTWARE.
 #
 
-ifeq ($(TARGET_ARCH),$(filter $(TARGET_ARCH),x86 x86_64))
 LOCAL_PATH := $(call my-dir)
 include $(CLEAR_VARS)
 
@@ -33,9 +32,12 @@ LOCAL_MODULE := libdrm_intel
 LOCAL_SRC_FILES := $(LIBDRM_INTEL_FILES)
 
 LOCAL_SHARED_LIBRARIES := \
-   libdrm \
+   libdrm
+
+ifeq ($(TARGET_ARCH),$(filter $(TARGET_ARCH),x86 x86_64))
+  LOCAL_SHARED_LIBRARIES += \
libpciaccess
+endif
 
 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] libdrm: intel/Android.mk: Filter libdrm_intel library requirements on x86/x86_64

[John Stultz]

On Tue, Mar 20, 2018 at 6:55 AM, Stefan Schake  wrote:
> Hey John,
>
> On Wed, Mar 14, 2018 at 5:47 PM, John Stultz  wrote:
>> 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.
>
> I'm afraid this change has snowballed straight into the mesa build where
> it's now missing dependencies for i915_dri:
>
> external/mesa3d/src/mesa/drivers/dri/i915/Android.mk: error:
> i915_dri (SHARED_LIBRARIES android-arm) missing libdrm_intel
>
> Maybe that one needs the BOARD_GPU_DRIVERS treatment instead..

So tinkering here, it seems to me just changing the conditionalizing
to skipping over just the libpciaccess addition to
LOCAL_SHARED_LIBRARIES might be a simpler solution.

Or would you see that as too ugly?

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

linux-next: manual merge of the drm-misc tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm-misc tree got a conflict in:

  drivers/gpu/drm/sun4i/sun4i_tcon.h

between commit:

  e742a17cd360 ("drm/sun4i: tcon: Reduce the scope of the LVDS error a bit")

from Linus' tree and commit:

  6664e9dc5383 ("drm/sun4i: Add support for A80 TCONs")

from the drm-misc tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/sun4i/sun4i_tcon.h
index abdc6ad6b384,d3a945b7bb60..
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
@@@ -176,7 -176,7 +176,8 @@@ struct sun4i_tcon_quirks 
boolhas_channel_1;  /* a33 does not have channel 1 */
boolhas_lvds_alt;   /* Does the LVDS clock have a parent other than 
the TCON clock? */
boolneeds_de_be_mux; /* sun6i needs mux to select backend */
 +  boolsupports_lvds;   /* Does the TCON support an LVDS output? */
+   boolneeds_edp_reset; /* a80 edp reset needed for tcon0 access */
  
/* callback to handle tcon muxing options */
int (*set_mux)(struct sun4i_tcon *, const struct drm_encoder *);


pgpmLvkxZbUnv.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[John Stultz]

On Tue, Mar 20, 2018 at 6:55 AM, Stefan Schake  wrote:
> Hey John,
>
> On Wed, Mar 14, 2018 at 5:47 PM, John Stultz  wrote:
>> 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.
>
> I'm afraid this change has snowballed straight into the mesa build where
> it's now missing dependencies for i915_dri:
>
> external/mesa3d/src/mesa/drivers/dri/i915/Android.mk: error:
> i915_dri (SHARED_LIBRARIES android-arm) missing libdrm_intel
>
> Maybe that one needs the BOARD_GPU_DRIVERS treatment instead..

Oof. Apologies for missing this, my environment uses the AOSP mesa3d.

I'll pull that down and take a look at what a better solution should be.

Rob: Do you want to revert in the meantime?

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

[Bug 105018] Kernel panic when waking up after screen goes blank.

[bugzilla-daemon]

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

--- Comment #23 from L.S.S.  ---
EDIT: It seems I'm experiencing some intermittent screen flicker with current
4.16 kernel (on the same system, with only Patch 3 applied as it's the only
patch needed for 4.16), although it doesn't really affect normal system usage.

I'm not sure if this flicker is related to this problem, but I'm putting it up
here as it's still a continuation of my watching this issue's condition.

-- 
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 v1 0/2] PCI: Sparc 64-bit resource fixups

[David Miller]

From: Bjorn Helgaas 
Date: Mon, 19 Mar 2018 14:38:54 -0500

> I'd be happy to remove both.  But I wonder how X init works on
> sparc.

It's been many years since I worked on this, but I think it
mapped and used the PCI ROM resource for this.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Stefan Schake]

Hey John,

On Wed, Mar 14, 2018 at 5:47 PM, John Stultz  wrote:
> 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.

I'm afraid this change has snowballed straight into the mesa build where
it's now missing dependencies for i915_dri:

external/mesa3d/src/mesa/drivers/dri/i915/Android.mk: error:
i915_dri (SHARED_LIBRARIES android-arm) missing libdrm_intel

Maybe that one needs the BOARD_GPU_DRIVERS treatment instead..

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

[PATCH] drm/msm/dsi: use correct enum in dsi_get_cmd_fmt

[Stefan Agner]

The function dsi_get_cmd_fmt returns enum dsi_cmd_dst_format,
use the correct enum value also for MIPI_DSI_FMT_RGB666/_PACKED.

This has been discovered using clang:
  drivers/gpu/drm/msm/dsi/dsi_host.c:743:35: warning: implicit conversion
from enumeration type 'enum dsi_vid_dst_format' to different
enumeration type 'enum dsi_cmd_dst_format' [-Wenum-conversion]
  case MIPI_DSI_FMT_RGB666:   return VID_DST_FORMAT_RGB666;
  ~~ ^

Signed-off-by: Stefan Agner 
---
 drivers/gpu/drm/msm/dsi/dsi_host.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 0f7324a686ca..d729b2b4b66d 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -740,7 +740,7 @@ static inline enum dsi_cmd_dst_format dsi_get_cmd_fmt(
switch (mipi_fmt) {
case MIPI_DSI_FMT_RGB888:   return CMD_DST_FORMAT_RGB888;
case MIPI_DSI_FMT_RGB666_PACKED:
-   case MIPI_DSI_FMT_RGB666:   return VID_DST_FORMAT_RGB666;
+   case MIPI_DSI_FMT_RGB666:   return CMD_DST_FORMAT_RGB666;
case MIPI_DSI_FMT_RGB565:   return CMD_DST_FORMAT_RGB565;
default:return CMD_DST_FORMAT_RGB888;
}
-- 
2.16.2

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

[PATCH] drm/tegra: dc: use correct format array for Tegra124.

[Stefan Agner]

Use tegra124_(primary|overlay)_formats for Tegra124.

Fixes: 511c7023cf23 ("drm/tegra: dc: Support more formats")
Signed-off-by: Stefan Agner 
---
 drivers/gpu/drm/tegra/dc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index b8403ed48285..fdc3195557c4 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -1999,9 +1999,9 @@ static const struct tegra_dc_soc_info 
tegra124_dc_soc_info = {
.coupled_pm = false,
.has_nvdisplay = false,
.num_primary_formats = ARRAY_SIZE(tegra124_primary_formats),
-   .primary_formats = tegra114_primary_formats,
+   .primary_formats = tegra124_primary_formats,
.num_overlay_formats = ARRAY_SIZE(tegra124_overlay_formats),
-   .overlay_formats = tegra114_overlay_formats,
+   .overlay_formats = tegra124_overlay_formats,
 };
 
 static const struct tegra_dc_soc_info tegra210_dc_soc_info = {
-- 
2.16.2

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

Re: [PATCH] drm/i915/gvt/scheduler: fix potential NULL pointer dereference

[Chris Wilson]

Quoting Gustavo A. R. Silva (2018-03-19 20:50:12)
> Hi Chris,
> 
> On 03/19/2018 03:38 PM, Chris Wilson wrote:
> > Quoting Gustavo A. R. Silva (2018-03-19 19:30:53)
> >> _workload_ is being dereferenced before it is null checked, hence
> >> there is a potential null pointer dereference.
> >>
> >> Fix this by moving the pointer dereference after _workload_ has
> >> been null checked.
> > 
> > The checks are misleading and not required.
> 
> All of them?
> 
> if (!workload || !reg_state || workload->ring_id != RCS)
> return;

workload can not be NULL (dereference in caller), reg_state can not be
NULL (by construct from kmap()).

It may be not an RCS ring through.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/8] ARM: sun9i: a80: Add display support

[Maxime Ripard]

On Thu, Mar 15, 2018 at 07:41:28PM +0800, Chen-Yu Tsai wrote:
> Hi everyone,
> 
> This series adds basic support for the display pipelines found on the
> Allwinner A80 SoC. Currently only parallel RGB output via TCON0 is
> supported. TCON1 drives the HDMI encoder, which I've not been able to
> get working yet.
> 
> Patch 1 adds device tree bindings for the TCONs on the A80. In
> particular, TCON0 requires the eDP reset control in addition to its own.
> 
> Patch 2 adds a device tree binding for the Detail Enhancement Unit found
> only on the A80.
> 
> Patch 3 adds driver support for the TCONs.
> 
> Patch 4 adds compatible strings to the device tree bindings for all the 
> remaining peripherals covered by this series.
> 
> Patch 5 adds support for the compatible strings from the previous patch
> to the sun4i-drm driver.
> 
> Patch 6 adds the display pipeline device nodes to the A80 .dtsi file.
> 
> Patch 7 adds a pinmux setting for RGB888 output for TCON0.
> 
> Patch 8 enables VGA output on the Cubieboard4 via an external DAC and
> an I2C bus from the SoC for DDC.
> 
> 
> I've had these patches for quite some time now, rebasing them as more
> features were added to sun4i-drm. Please have a look.

Applied all, thanks!
Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.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 0/2] drm/sun4i: backend: Support interleaved YUV planes

[Maxime Ripard]

On Thu, Mar 01, 2018 at 08:18:44PM +0100, Maxime Ripard wrote:
> Hi,
> 
> This is an attempt at supporting the interleaved YUV planes in the sun4i
> DRM driver for SoCs that use the DE1.
> 
> There's nothing out of the extraordinary there, we just have one more
> constraint in our DRM driver, since we can only have a single YUV plane.
> 
> Let me know what you think,
> Maxime

Applied both with Chen-Yu comments fixed.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


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

Re: [Outreachy kernel] [PATCH DRM] drm: Introduce drm_global_item_{get/put}()

[Daniel Vetter]

On Tue, Mar 13, 2018 at 1:02 PM, Haneen Mohammed
 wrote:
> For consistency with other reference counting APIs in the kernel,
> introduce drm_global_item_{get/put} functions instead of
> drm_global_item_{ref/unref}.
>
> Compatibility aliases are added to keep existing code working.
>
> The semantic patch scripts/coccinelle/api/drm-get-put.cocci has been
> extended to account for the new helpers.
>
> Signed-off-by: Haneen Mohammed 

Somehow this fell through the cracks. drm_global.c is only used by ttm
and vmwgfx, adding relevant maintainers.
-Daniel

> ---
>  drivers/gpu/drm/drm_global.c | 43 
> +++-
>  include/drm/drm_global.h |  2 ++
>  scripts/coccinelle/api/drm-get-put.cocci | 10 
>  3 files changed, 49 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_global.c b/drivers/gpu/drm/drm_global.c
> index b2dc21e..76cf948 100644
> --- a/drivers/gpu/drm/drm_global.c
> +++ b/drivers/gpu/drm/drm_global.c
> @@ -64,7 +64,7 @@ void drm_global_release(void)
>  }
>
>  /**
> - * drm_global_item_ref - Initialize and acquire reference to memory
> + * drm_global_item_get - Initialize and acquire reference to memory
>   * object
>   * @ref: Object for initialization
>   *
> @@ -75,7 +75,7 @@ void drm_global_release(void)
>   * Returns:
>   * Zero on success, non-zero otherwise.
>   */
> -int drm_global_item_ref(struct drm_global_reference *ref)
> +int drm_global_item_get(struct drm_global_reference *ref)
>  {
> int ret = 0;
> struct drm_global_item *item = [ref->global_type];
> @@ -107,10 +107,10 @@ int drm_global_item_ref(struct drm_global_reference 
> *ref)
> mutex_unlock(>mutex);
> return ret;
>  }
> -EXPORT_SYMBOL(drm_global_item_ref);
> +EXPORT_SYMBOL(drm_global_item_get);
>
>  /**
> - * drm_global_item_unref - Drop reference to memory
> + * drm_global_item_put - Drop reference to memory
>   * object
>   * @ref: Object being removed
>   *
> @@ -120,7 +120,7 @@ EXPORT_SYMBOL(drm_global_item_ref);
>   *
>   */
>
> -void drm_global_item_unref(struct drm_global_reference *ref)
> +void drm_global_item_put(struct drm_global_reference *ref)
>  {
> struct drm_global_item *item = [ref->global_type];
>
> @@ -133,5 +133,36 @@ void drm_global_item_unref(struct drm_global_reference 
> *ref)
> }
> mutex_unlock(>mutex);
>  }
> -EXPORT_SYMBOL(drm_global_item_unref);
> +EXPORT_SYMBOL(drm_global_item_put);
>
> +/**
> + * drm_global_item_ref - Initialize and acquire reference to memory
> + * object
> + * @ref: Object for initialization
> + *
> + * This is a compatibility alias for drm_global_item_get() and should
> + * not be used by new code.
> + *
> + * Returns:
> + * Zero on success, non-zero otherwise.
> + */
> +int drm_global_item_ref(struct drm_global_reference *ref)
> +{
> +   return drm_global_item_get(ref);
> +}
> +EXPORT_SYMBOL(drm_global_item_ref);
> +
> +/**
> + * drm_global_item_unref - Drop reference to memory
> + * object
> + * @ref: Object being removed
> + *
> + * This is a compatibility alias for drm_global_item_get() and should not
> + * be used by new code.
> + */
> +
> +void drm_global_item_unref(struct drm_global_reference *ref)
> +{
> +   drm_global_item_put(ref);
> +}
> +EXPORT_SYMBOL(drm_global_item_unref);
> diff --git a/include/drm/drm_global.h b/include/drm/drm_global.h
> index 3a83060..5eb6f0c 100644
> --- a/include/drm/drm_global.h
> +++ b/include/drm/drm_global.h
> @@ -47,6 +47,8 @@ struct drm_global_reference {
>
>  void drm_global_init(void);
>  void drm_global_release(void);
> +int drm_global_item_get(struct drm_global_reference *ref);
> +void drm_global_item_put(struct drm_global_reference *ref);
>  int drm_global_item_ref(struct drm_global_reference *ref);
>  void drm_global_item_unref(struct drm_global_reference *ref);
>
> diff --git a/scripts/coccinelle/api/drm-get-put.cocci 
> b/scripts/coccinelle/api/drm-get-put.cocci
> index 91fceb8..db1c465 100644
> --- a/scripts/coccinelle/api/drm-get-put.cocci
> +++ b/scripts/coccinelle/api/drm-get-put.cocci
> @@ -54,6 +54,12 @@ expression object;
>  |
>  - drm_dev_unref(object)
>  + drm_dev_put(object)
> +|
> +- drm_global_item_ref(object)
> ++ drm_global_item_get(object)
> +|
> +- drm_global_item_unref(object)
> ++ drm_global_item_put(object)
>  )
>
>  @r depends on report@
> @@ -87,6 +93,10 @@ drm_property_unreference_blob@p(object)
>  drm_property_reference_blob@p(object)
>  |
>  drm_dev_unref@p(object)
> +|
> +drm_global_item_ref@p(object)
> +|
> +drm_global_item_unref@p(object)
>  )
>
>  @script:python depends on report@
> --
> 2.7.4
>
> --
> You received this message because you are subscribed to the Google Groups 
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view 

Re: [PATCH] drm/i915/gvt/scheduler: fix potential NULL pointer dereference

[Chris Wilson]

Quoting Gustavo A. R. Silva (2018-03-19 19:30:53)
> _workload_ is being dereferenced before it is null checked, hence
> there is a potential null pointer dereference.
> 
> Fix this by moving the pointer dereference after _workload_ has
> been null checked.

The checks are misleading and not required.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 2/3] drm/msm/dsi: add implementation for helper functions

[Jordan Crouse]

On Tue, Mar 20, 2018 at 01:11:02AM +0530, Sibi S wrote:
> Add dsi host helper function implementation for DSI v2
> DSI 6G 1.x and DSI 6G v2.0+ controllers
> 
> Signed-off-by: Sibi S 
> ---
>  drivers/gpu/drm/msm/dsi/dsi.h  |  15 +++
>  drivers/gpu/drm/msm/dsi/dsi_cfg.c  |  56 +++--
>  drivers/gpu/drm/msm/dsi/dsi_host.c | 236 
> -
>  3 files changed, 296 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
> index 80be83e8fdec..dfa049d876bd 100644
> --- a/drivers/gpu/drm/msm/dsi/dsi.h
> +++ b/drivers/gpu/drm/msm/dsi/dsi.h
> @@ -183,6 +183,21 @@ int msm_dsi_host_modeset_init(struct mipi_dsi_host *host,
>  int msm_dsi_host_init(struct msm_dsi *msm_dsi);
>  int msm_dsi_runtime_suspend(struct device *dev);
>  int msm_dsi_runtime_resume(struct device *dev);
> +int dsi_link_clk_enable_6g(struct msm_dsi_host *msm_host);
> +int dsi_link_clk_enable_v2(struct msm_dsi_host *msm_host);
> +void dsi_link_clk_disable_6g(struct msm_dsi_host *msm_host);
> +void dsi_link_clk_disable_v2(struct msm_dsi_host *msm_host);
> +int dsi_tx_buf_alloc_6g(struct msm_dsi_host *msm_host, int size);
> +int dsi_tx_buf_alloc_v2(struct msm_dsi_host *msm_host, int size);
> +void *dsi_tx_buf_get_6g(struct msm_dsi_host *msm_host);
> +void *dsi_tx_buf_get_v2(struct msm_dsi_host *msm_host);
> +void dsi_tx_buf_put_6g(struct msm_dsi_host *msm_host);
> +int dsi_dma_base_get_6g(struct msm_dsi_host *msm_host, uint64_t *iova);
> +int dsi_dma_base_get_v2(struct msm_dsi_host *msm_host, uint64_t *iova);
> +int dsi_clk_init_v2(struct msm_dsi_host *msm_host);
> +int dsi_clk_init_6g_v2(struct msm_dsi_host *msm_host);
> +int dsi_calc_clk_rate_v2(struct msm_dsi_host *msm_host);
> +int dsi_calc_clk_rate_6g(struct msm_dsi_host *msm_host);
>  
>  /* dsi phy */
>  struct msm_dsi_phy;
> diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.c 
> b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
> index 0327bb54b01b..dcdfb1bb54f9 100644
> --- a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
> +++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
> @@ -136,20 +136,58 @@ static const struct msm_dsi_config sdm845_dsi_cfg = {
>   .num_dsi = 2,
>  };
>  
> +const static struct msm_dsi_host_cfg_ops msm_dsi_v2_host_ops = {
> + .link_clk_enable = dsi_link_clk_enable_v2,
> + .link_clk_disable = dsi_link_clk_disable_v2,
> + .clk_init_ver = dsi_clk_init_v2,
> + .tx_buf_alloc = dsi_tx_buf_alloc_v2,
> + .tx_buf_get = dsi_tx_buf_get_v2,
> + .tx_buf_put = NULL,
> + .dma_base_get = dsi_dma_base_get_v2,
> + .calc_clk_rate = dsi_calc_clk_rate_v2,
> +};
> +
> +const static struct msm_dsi_host_cfg_ops msm_dsi_6g_host_ops = {
> + .link_clk_enable = dsi_link_clk_enable_6g,
> + .link_clk_disable = dsi_link_clk_disable_6g,
> + .clk_init_ver = NULL,
> + .tx_buf_alloc = dsi_tx_buf_alloc_6g,
> + .tx_buf_get = dsi_tx_buf_get_6g,
> + .tx_buf_put = dsi_tx_buf_put_6g,
> + .dma_base_get = dsi_dma_base_get_6g,
> + .calc_clk_rate = dsi_calc_clk_rate_6g,
> +};
> +
> +const static struct msm_dsi_host_cfg_ops msm_dsi_6g_v2_host_ops = {
> + .link_clk_enable = dsi_link_clk_enable_6g,
> + .link_clk_disable = dsi_link_clk_disable_6g,
> + .clk_init_ver = dsi_clk_init_6g_v2,
> + .tx_buf_alloc = dsi_tx_buf_alloc_6g,
> + .tx_buf_get = dsi_tx_buf_get_6g,
> + .tx_buf_put = dsi_tx_buf_put_6g,
> + .dma_base_get = dsi_dma_base_get_6g,
> + .calc_clk_rate = dsi_calc_clk_rate_6g,
> +};
> +
>  static const struct msm_dsi_cfg_handler dsi_cfg_handlers[] = {
> - {MSM_DSI_VER_MAJOR_V2, MSM_DSI_V2_VER_MINOR_8064, _dsi_cfg},
> + {MSM_DSI_VER_MAJOR_V2, MSM_DSI_V2_VER_MINOR_8064,
> + _dsi_cfg, _dsi_v2_host_ops},
>   {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_0,
> - _apq8084_dsi_cfg},
> + _apq8084_dsi_cfg, _dsi_6g_host_ops},
>   {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_1,
> - _apq8084_dsi_cfg},
> + _apq8084_dsi_cfg, _dsi_6g_host_ops},
>   {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_1_1,
> - _apq8084_dsi_cfg},
> + _apq8084_dsi_cfg, _dsi_6g_host_ops},
>   {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_2,
> - _apq8084_dsi_cfg},
> - {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_3, _dsi_cfg},
> - {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_3_1, _dsi_cfg},
> - {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_4_1, _dsi_cfg},
> - {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V2_2_1, _dsi_cfg},
> + _apq8084_dsi_cfg, _dsi_6g_host_ops},
> + {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_3,
> + _dsi_cfg, _dsi_6g_host_ops},
> + {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_3_1,
> + _dsi_cfg, _dsi_6g_host_ops},
> + {MSM_DSI_VER_MAJOR_6G, 

[DPU PATCH v3] drm/msm: Use atomic private_obj instead of subclassing

[Sean Paul]

Instead of subclassing atomic state, store driver private data in
private_obj/state. This allows us to remove the swap_state driver hook
for mdp5 and get closer to using the atomic helpers entirely.

Changes in v2:
 - Use state->state in disp duplicate_state callback (Jeykumar)
Changes in v3:
 - Update comment describing msm_kms_state (Jeykumar)

Cc: Jeykumar Sankaran 
Reviewed-by: Jeykumar Sankaran 
Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 37 ++
 drivers/gpu/drm/msm/msm_atomic.c | 30 ---
 drivers/gpu/drm/msm/msm_drv.c| 65 ++--
 drivers/gpu/drm/msm/msm_drv.h|  4 +-
 drivers/gpu/drm/msm/msm_kms.h| 27 +-
 5 files changed, 94 insertions(+), 69 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
index 6d8e3a9a6fc0..f1a248419655 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
@@ -74,36 +74,32 @@ struct mdp5_state *mdp5_get_state(struct drm_atomic_state 
*s)
 {
struct msm_drm_private *priv = s->dev->dev_private;
struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(priv->kms));
-   struct msm_kms_state *state = to_kms_state(s);
-   struct mdp5_state *new_state;
+   struct msm_kms_state *kms_state;
int ret;
 
-   if (state->state)
-   return state->state;
-
ret = drm_modeset_lock(_kms->state_lock, s->acquire_ctx);
if (ret)
return ERR_PTR(ret);
 
-   new_state = kmalloc(sizeof(*mdp5_kms->state), GFP_KERNEL);
-   if (!new_state)
-   return ERR_PTR(-ENOMEM);
+   kms_state = msm_kms_get_state(s);
+   if (IS_ERR_OR_NULL(kms_state))
+   return (struct mdp5_state *)kms_state; /* casting ERR_PTR */
 
-   /* Copy state: */
-   new_state->hwpipe = mdp5_kms->state->hwpipe;
-   new_state->hwmixer = mdp5_kms->state->hwmixer;
-   if (mdp5_kms->smp)
-   new_state->smp = mdp5_kms->state->smp;
+   return kms_state->state;
+}
 
-   state->state = new_state;
+static void *mdp5_duplicate_state(void *state)
+{
+   if (!state)
+   return kzalloc(sizeof(struct mdp5_state), GFP_KERNEL);
 
-   return new_state;
+   return kmemdup(state, sizeof(struct mdp5_state), GFP_KERNEL);
 }
 
-static void mdp5_swap_state(struct msm_kms *kms, struct drm_atomic_state 
*state)
+static void mdp5_destroy_state(void *state)
 {
-   struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(kms));
-   swap(to_kms_state(state)->state, mdp5_kms->state);
+   struct mdp5_state *mdp_state = state;
+   kfree(mdp_state);
 }
 
 static void mdp5_prepare_commit(struct msm_kms *kms, struct drm_atomic_state 
*state)
@@ -229,7 +225,8 @@ static const struct mdp_kms_funcs kms_funcs = {
.irq = mdp5_irq,
.enable_vblank   = mdp5_enable_vblank,
.disable_vblank  = mdp5_disable_vblank,
-   .swap_state  = mdp5_swap_state,
+   .duplicate_state = mdp5_duplicate_state,
+   .destroy_state   = mdp5_destroy_state,
.prepare_commit  = mdp5_prepare_commit,
.complete_commit = mdp5_complete_commit,
.wait_for_crtc_commit_done = mdp5_wait_for_crtc_commit_done,
@@ -726,8 +723,6 @@ static void mdp5_destroy(struct platform_device *pdev)
 
if (mdp5_kms->rpm_enabled)
pm_runtime_disable(>dev);
-
-   kfree(mdp5_kms->state);
 }
 
 static int construct_pipes(struct mdp5_kms *mdp5_kms, int cnt,
diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c
index 7e54eb65d096..1f53262ea46b 100644
--- a/drivers/gpu/drm/msm/msm_atomic.c
+++ b/drivers/gpu/drm/msm/msm_atomic.c
@@ -169,9 +169,6 @@ int msm_atomic_commit(struct drm_device *dev,
 */
BUG_ON(drm_atomic_helper_swap_state(state, false) < 0);
 
-   if (to_kms_state(state)->state)
-   priv->kms->funcs->swap_state(priv->kms, state);
-
/*
 * Provide the driver a chance to prepare for output fences. This is
 * done after the point of no return, but before asynchronous commits
@@ -210,30 +207,3 @@ int msm_atomic_commit(struct drm_device *dev,
drm_atomic_helper_cleanup_planes(dev, state);
return ret;
 }
-
-struct drm_atomic_state *msm_atomic_state_alloc(struct drm_device *dev)
-{
-   struct msm_kms_state *state = kzalloc(sizeof(*state), GFP_KERNEL);
-
-   if (!state || drm_atomic_state_init(dev, >base) < 0) {
-   kfree(state);
-   return NULL;
-   }
-
-   return >base;
-}
-
-void msm_atomic_state_clear(struct drm_atomic_state *s)
-{
-   struct msm_kms_state *state = to_kms_state(s);
-   drm_atomic_state_default_clear(>base);
-   kfree(state->state);
- 

Re: [DPU PATCH 06/11] drm/msm: Remove msm_commit/kthread, use atomic helper commit

[Jeykumar Sankaran]

On 2018-03-19 08:01, Sean Paul wrote:

On Mon, Mar 12, 2018 at 04:23:10PM -0400, Sean Paul wrote:

On Thu, Mar 08, 2018 at 05:08:03PM -0800, Jeykumar Sankaran wrote:
> On 2018-03-02 06:56, Sean Paul wrote:
> > On Thu, Mar 01, 2018 at 07:37:10PM -0500, Rob Clark wrote:
> > > On Thu, Mar 1, 2018 at 3:37 PM,   wrote:
> > > > On 2018-03-01 07:27, Sean Paul wrote:
> > > >>
> > > >> On Wed, Feb 28, 2018 at 08:07:00PM -0800, jsa...@codeaurora.org
> > wrote:
> > > >>>
> > > >>> On 2018-02-28 11:19, Sean Paul wrote:
> > > >>> > Moving further towards switching fully to the the atomic

helpers,

> > this
> > > >>> > patch removes the hand-rolled kthread nonblock commit code

and

> > uses
> > > >>
> > > >> the
> > > >>>
> > > >>> > atomic helpers commit_work model.
> > > >>> >
> > > >>> > There's still a lot of copypasta here, but it's still needed

to

> > > >>> > facilitate the swap_state and prepare_fence private

functions.

> > These
> > > >>> > will be sorted out in a follow-on patch.
> > > >>> >
> > > >>> > Change-Id: I9fcba27824ba63d3fab96cb2bc194bfa6f3475b7
> > > >>> > Signed-off-by: Sean Paul 
> > > >>> > ---





> > > >>
> > > >>> > - /* only return zero if

work

> > is
> > > >>> > -  * queued

successfully.

> > > >>> > -  */
> > > >>> > - ret = 0;
> > > >>> > - } else {
> > > >>> > - DRM_ERROR(" Error for
> > crtc_id:
> > > >>> > %d\n",
> > > >>> > -
> > > >>> > priv->disp_thread[j].crtc_id);
> > > >>> > - }
> > > >>> > - break;
> > > >>> > - }
> > > >>> > - }
>
> Care to remove priv->disp_thread and all its references as a part of

this

> change?

Definitely! Will revise.



Now that I look at it, disp_thread doesn't seem relevant to this 
change.

It
seems like it's used for deferred cleanup. So perhaps we could get rid 
of

it,
but IMO that would be a different patch.


Sean

hmm.. disp_threads are created per CRTC (per display) to allow 
concurrency of
hardware programming. So its not entirely irrelevant to this chnage. But 
since
it involves more than just priv->disp_thread cleanup, I am fine with 
cleaning

that in a separate patch.

Reviewed-by: Jeykumar Sankaran 


>
> - Jeykumar S





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

[PATCH v2 3/3] drm/msm/dsi: replace version checks with helper functions

[Sibi S]

Replace version checks with the helper functions bound to
cfg_handler for DSI v2, DSI 6G 1.x and DSI 6G v2.0+ controllers

Signed-off-by: Sibi S 
---
 drivers/gpu/drm/msm/dsi/dsi_host.c | 242 +
 1 file changed, 29 insertions(+), 213 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 78ea4540f0ee..bf8581a5e67c 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -426,19 +426,6 @@ static int dsi_clk_init(struct msm_dsi_host *msm_host)
goto exit;
}
 
-   if (cfg_hnd->major == MSM_DSI_VER_MAJOR_6G &&
-   cfg_hnd->minor >= MSM_DSI_6G_VER_MINOR_V2_2_1) {
-   msm_host->byte_intf_clk = msm_clk_get(pdev, "byte_intf");
-   if (IS_ERR(msm_host->byte_intf_clk)) {
-   ret = PTR_ERR(msm_host->byte_intf_clk);
-   pr_err("%s: can't find byte_intf clock. ret=%d\n",
-   __func__, ret);
-   goto exit;
-   }
-   } else {
-   msm_host->byte_intf_clk = NULL;
-   }
-
msm_host->byte_clk_src = clk_get_parent(msm_host->byte_clk);
if (!msm_host->byte_clk_src) {
ret = -ENODEV;
@@ -453,31 +440,8 @@ static int dsi_clk_init(struct msm_dsi_host *msm_host)
goto exit;
}
 
-   if (cfg_hnd->major == MSM_DSI_VER_MAJOR_V2) {
-   msm_host->src_clk = msm_clk_get(pdev, "src");
-   if (IS_ERR(msm_host->src_clk)) {
-   ret = PTR_ERR(msm_host->src_clk);
-   pr_err("%s: can't find src clock. ret=%d\n",
-   __func__, ret);
-   msm_host->src_clk = NULL;
-   goto exit;
-   }
-
-   msm_host->esc_clk_src = clk_get_parent(msm_host->esc_clk);
-   if (!msm_host->esc_clk_src) {
-   ret = -ENODEV;
-   pr_err("%s: can't get esc clock parent. ret=%d\n",
-   __func__, ret);
-   goto exit;
-   }
-
-   msm_host->dsi_clk_src = clk_get_parent(msm_host->src_clk);
-   if (!msm_host->dsi_clk_src) {
-   ret = -ENODEV;
-   pr_err("%s: can't get src clock parent. ret=%d\n",
-   __func__, ret);
-   }
-   }
+   if (cfg_hnd->ops->clk_init_ver)
+   ret = cfg_hnd->ops->clk_init_ver(msm_host);
 exit:
return ret;
 }
@@ -681,16 +645,6 @@ int dsi_link_clk_enable_v2(struct msm_dsi_host *msm_host)
return ret;
 }
 
-static int dsi_link_clk_enable(struct msm_dsi_host *msm_host)
-{
-   const struct msm_dsi_cfg_handler *cfg_hnd = msm_host->cfg_hnd;
-
-   if (cfg_hnd->major == MSM_DSI_VER_MAJOR_6G)
-   return dsi_link_clk_enable_6g(msm_host);
-   else
-   return dsi_link_clk_enable_v2(msm_host);
-}
-
 void dsi_link_clk_disable_6g(struct msm_dsi_host *msm_host)
 {
clk_disable_unprepare(msm_host->esc_clk);
@@ -708,24 +662,6 @@ void dsi_link_clk_disable_v2(struct msm_dsi_host *msm_host)
clk_disable_unprepare(msm_host->byte_clk);
 }
 
-static void dsi_link_clk_disable(struct msm_dsi_host *msm_host)
-{
-   const struct msm_dsi_cfg_handler *cfg_hnd = msm_host->cfg_hnd;
-
-   if (cfg_hnd->major == MSM_DSI_VER_MAJOR_6G) {
-   clk_disable_unprepare(msm_host->esc_clk);
-   clk_disable_unprepare(msm_host->pixel_clk);
-   if (msm_host->byte_intf_clk)
-   clk_disable_unprepare(msm_host->byte_intf_clk);
-   clk_disable_unprepare(msm_host->byte_clk);
-   } else {
-   clk_disable_unprepare(msm_host->pixel_clk);
-   clk_disable_unprepare(msm_host->src_clk);
-   clk_disable_unprepare(msm_host->esc_clk);
-   clk_disable_unprepare(msm_host->byte_clk);
-   }
-}
-
 int dsi_calc_clk_rate_6g(struct msm_dsi_host *msm_host)
 {
struct drm_display_mode *mode = msm_host->mode;
@@ -814,73 +750,6 @@ int dsi_calc_clk_rate_v2(struct msm_dsi_host *msm_host)
return 0;
 }
 
-static int dsi_calc_clk_rate(struct msm_dsi_host *msm_host)
-{
-   struct drm_display_mode *mode = msm_host->mode;
-   const struct msm_dsi_cfg_handler *cfg_hnd = msm_host->cfg_hnd;
-   u8 lanes = msm_host->lanes;
-   u32 bpp = dsi_get_bpp(msm_host->format);
-   u32 pclk_rate;
-
-   if (!mode) {
-   pr_err("%s: mode not set\n", __func__);
-   return -EINVAL;
-   }
-
-   pclk_rate = mode->clock * 1000;
-   if (lanes > 0) {
-   msm_host->byte_clk_rate = (pclk_rate * bpp) / (8 * lanes);
-   } else {
-   pr_err("%s: forcing mdss_dsi lanes to 1\n", __func__);
-   

[PATCH v2 2/3] drm/msm/dsi: add implementation for helper functions

[Sibi S]

Add dsi host helper function implementation for DSI v2
DSI 6G 1.x and DSI 6G v2.0+ controllers

Signed-off-by: Sibi S 
---
 drivers/gpu/drm/msm/dsi/dsi.h  |  15 +++
 drivers/gpu/drm/msm/dsi/dsi_cfg.c  |  56 +++--
 drivers/gpu/drm/msm/dsi/dsi_host.c | 236 -
 3 files changed, 296 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
index 80be83e8fdec..dfa049d876bd 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -183,6 +183,21 @@ int msm_dsi_host_modeset_init(struct mipi_dsi_host *host,
 int msm_dsi_host_init(struct msm_dsi *msm_dsi);
 int msm_dsi_runtime_suspend(struct device *dev);
 int msm_dsi_runtime_resume(struct device *dev);
+int dsi_link_clk_enable_6g(struct msm_dsi_host *msm_host);
+int dsi_link_clk_enable_v2(struct msm_dsi_host *msm_host);
+void dsi_link_clk_disable_6g(struct msm_dsi_host *msm_host);
+void dsi_link_clk_disable_v2(struct msm_dsi_host *msm_host);
+int dsi_tx_buf_alloc_6g(struct msm_dsi_host *msm_host, int size);
+int dsi_tx_buf_alloc_v2(struct msm_dsi_host *msm_host, int size);
+void *dsi_tx_buf_get_6g(struct msm_dsi_host *msm_host);
+void *dsi_tx_buf_get_v2(struct msm_dsi_host *msm_host);
+void dsi_tx_buf_put_6g(struct msm_dsi_host *msm_host);
+int dsi_dma_base_get_6g(struct msm_dsi_host *msm_host, uint64_t *iova);
+int dsi_dma_base_get_v2(struct msm_dsi_host *msm_host, uint64_t *iova);
+int dsi_clk_init_v2(struct msm_dsi_host *msm_host);
+int dsi_clk_init_6g_v2(struct msm_dsi_host *msm_host);
+int dsi_calc_clk_rate_v2(struct msm_dsi_host *msm_host);
+int dsi_calc_clk_rate_6g(struct msm_dsi_host *msm_host);
 
 /* dsi phy */
 struct msm_dsi_phy;
diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.c 
b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
index 0327bb54b01b..dcdfb1bb54f9 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
@@ -136,20 +136,58 @@ static const struct msm_dsi_config sdm845_dsi_cfg = {
.num_dsi = 2,
 };
 
+const static struct msm_dsi_host_cfg_ops msm_dsi_v2_host_ops = {
+   .link_clk_enable = dsi_link_clk_enable_v2,
+   .link_clk_disable = dsi_link_clk_disable_v2,
+   .clk_init_ver = dsi_clk_init_v2,
+   .tx_buf_alloc = dsi_tx_buf_alloc_v2,
+   .tx_buf_get = dsi_tx_buf_get_v2,
+   .tx_buf_put = NULL,
+   .dma_base_get = dsi_dma_base_get_v2,
+   .calc_clk_rate = dsi_calc_clk_rate_v2,
+};
+
+const static struct msm_dsi_host_cfg_ops msm_dsi_6g_host_ops = {
+   .link_clk_enable = dsi_link_clk_enable_6g,
+   .link_clk_disable = dsi_link_clk_disable_6g,
+   .clk_init_ver = NULL,
+   .tx_buf_alloc = dsi_tx_buf_alloc_6g,
+   .tx_buf_get = dsi_tx_buf_get_6g,
+   .tx_buf_put = dsi_tx_buf_put_6g,
+   .dma_base_get = dsi_dma_base_get_6g,
+   .calc_clk_rate = dsi_calc_clk_rate_6g,
+};
+
+const static struct msm_dsi_host_cfg_ops msm_dsi_6g_v2_host_ops = {
+   .link_clk_enable = dsi_link_clk_enable_6g,
+   .link_clk_disable = dsi_link_clk_disable_6g,
+   .clk_init_ver = dsi_clk_init_6g_v2,
+   .tx_buf_alloc = dsi_tx_buf_alloc_6g,
+   .tx_buf_get = dsi_tx_buf_get_6g,
+   .tx_buf_put = dsi_tx_buf_put_6g,
+   .dma_base_get = dsi_dma_base_get_6g,
+   .calc_clk_rate = dsi_calc_clk_rate_6g,
+};
+
 static const struct msm_dsi_cfg_handler dsi_cfg_handlers[] = {
-   {MSM_DSI_VER_MAJOR_V2, MSM_DSI_V2_VER_MINOR_8064, _dsi_cfg},
+   {MSM_DSI_VER_MAJOR_V2, MSM_DSI_V2_VER_MINOR_8064,
+   _dsi_cfg, _dsi_v2_host_ops},
{MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_0,
-   _apq8084_dsi_cfg},
+   _apq8084_dsi_cfg, _dsi_6g_host_ops},
{MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_1,
-   _apq8084_dsi_cfg},
+   _apq8084_dsi_cfg, _dsi_6g_host_ops},
{MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_1_1,
-   _apq8084_dsi_cfg},
+   _apq8084_dsi_cfg, _dsi_6g_host_ops},
{MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_2,
-   _apq8084_dsi_cfg},
-   {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_3, _dsi_cfg},
-   {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_3_1, _dsi_cfg},
-   {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_4_1, _dsi_cfg},
-   {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V2_2_1, _dsi_cfg},
+   _apq8084_dsi_cfg, _dsi_6g_host_ops},
+   {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_3,
+   _dsi_cfg, _dsi_6g_host_ops},
+   {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_3_1,
+   _dsi_cfg, _dsi_6g_host_ops},
+   {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_4_1,
+   _dsi_cfg, _dsi_6g_host_ops},
+   {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V2_2_1,
+   _dsi_cfg, _dsi_6g_v2_host_ops},

[PATCH v2 0/3] Cleanup excessive DSI host controller version checks

[Sibi S]

This patch series aims to create and bind dsi host controller helper
functions to functionalities that vary across DSI v2, DSI 6G 1.x and
DSI 6G v2.0+ controllers. These functionalities are currently under
excessive version checks which is now replaced with the corresponding
helper function.

V2:
  Removes command broadcast support for DSI 6G v2.0+ controllers from
  the patch series and incorporates all the suggested corrections
  

Sibi S (3):
  drm/msm/dsi: add dsi host helper functions support
  drm/msm/dsi: add implementation for helper functions
  drm/msm/dsi: replace version checks with helper functions

 drivers/gpu/drm/msm/dsi/dsi.h  |  16 ++
 drivers/gpu/drm/msm/dsi/dsi_cfg.c  |  56 +-
 drivers/gpu/drm/msm/dsi/dsi_cfg.h  |  12 ++
 drivers/gpu/drm/msm/dsi/dsi_host.c | 362 +
 4 files changed, 280 insertions(+), 166 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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

[PATCH v2 1/3] drm/msm/dsi: add dsi host helper functions support

[Sibi S]

Add dsi host helper functions support for DSI v2 and DSI 6G 1.x
controllers that are under version checks

Signed-off-by: Sibi S 
---
 drivers/gpu/drm/msm/dsi/dsi.h |  1 +
 drivers/gpu/drm/msm/dsi/dsi_cfg.h | 12 
 2 files changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
index 70d9a9a47acd..80be83e8fdec 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -149,6 +149,7 @@ static inline int msm_dsi_pll_set_usecase(struct 
msm_dsi_pll *pll,
 #endif
 
 /* dsi host */
+struct msm_dsi_host;
 int msm_dsi_host_xfer_prepare(struct mipi_dsi_host *host,
const struct mipi_dsi_msg *msg);
 void msm_dsi_host_xfer_restore(struct mipi_dsi_host *host,
diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.h 
b/drivers/gpu/drm/msm/dsi/dsi_cfg.h
index 9cfdcf1c95d5..a795a062b779 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_cfg.h
+++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.h
@@ -40,10 +40,22 @@ struct msm_dsi_config {
const int num_dsi;
 };
 
+struct msm_dsi_host_cfg_ops {
+   int (*link_clk_enable)(struct msm_dsi_host *msm_host);
+   void (*link_clk_disable)(struct msm_dsi_host *msm_host);
+   int (*clk_init_ver)(struct msm_dsi_host *msm_host);
+   int (*tx_buf_alloc)(struct msm_dsi_host *msm_host, int size);
+   void* (*tx_buf_get)(struct msm_dsi_host *msm_host);
+   void (*tx_buf_put)(struct msm_dsi_host *msm_host);
+   int (*dma_base_get)(struct msm_dsi_host *msm_host, uint64_t *iova);
+   int (*calc_clk_rate)(struct msm_dsi_host *msm_host);
+};
+
 struct msm_dsi_cfg_handler {
u32 major;
u32 minor;
const struct msm_dsi_config *cfg;
+   const struct msm_dsi_host_cfg_ops *ops;
 };
 
 const struct msm_dsi_cfg_handler *msm_dsi_cfg_get(u32 major, u32 minor);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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

Re: [PATCH v1 0/2] PCI: Sparc 64-bit resource fixups

[Bjorn Helgaas]

[+cc Dave, Alex, dri-devel]

On Mon, Mar 19, 2018 at 02:28:31PM -0400, David Miller wrote:
> From: Bjorn Helgaas 
> Date: Mon, 19 Mar 2018 12:11:40 -0500
> 
> > I could have worded the changelog better.  This is about reserving PCI
> > bus addresses 0xc-0xc7fff, not the VGA framebuffer at
> > 0xa-0xb.
> > 
> > If I understand correctly, a VGA device will respond to the
> > framebuffer at 0xa-0xb, but the device itself will not respond
> > to the 0xc-0xc7fff range.  I think the typical x86 PC arrangement
> > is that the BIOS reads the VGA option ROM using the normal relocatable
> > expansion ROM BAR and copies it into system memory at 0xc, so it
> > is in real physical memory.
> > 
> > I don't know what sparc firmware does, but I'm assuming the VGA PCI
> > device behaves the same in that it wouldn't respond to 0xc itself.
> 
> The Sparc firmware doesn't copy the VGA option ROM.
> 
> That physical address location 0xc in system memory is just
> normal memory and most likely the kernel image itself is residing
> there.
> 
> >> I could understand removing the System ROM resource altogether, that
> >> makes a lot of sense to me.
> > 
> > Do you want me to remove the System ROM resource?  If so, I'll
> > make a separate patch to remove it, followed by one that does
> > whatever we figure out is the right thing for the video ROM.
> 
> Porbably it makes the most sense to remove both, given the above.

I'd be happy to remove both.  But I wonder how X init works on sparc.

I thought X had code to run the option ROM under emulation and I
wondered if that might rely on the ROM image being at 0xc.  Maybe
it reads it from the sysfs "rom" file?  That would be available
regardless of what firmware does, but I have a dim recollection of 
something being more complicated than just reading the image directly
from the ROM.

Maybe Dave or Alex know the details?

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

Re: [DPU PATCH v2] drm/msm: Use atomic private_obj instead of subclassing

[Jeykumar Sankaran]

On 2018-03-19 10:31, Sean Paul wrote:

Instead of subclassing atomic state, store driver private data in
private_obj/state. This allows us to remove the swap_state driver hook
for mdp5 and get closer to using the atomic helpers entirely.

Changes in v2:
 - Use state->state in disp duplicate_state callback (Jeykumar)

Cc: Jeykumar Sankaran 
Signed-off-by: Sean Paul 

With the below comment updated

Reviewed-by: Jeykumar Sankaran 


---
 drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 37 ++
 drivers/gpu/drm/msm/msm_atomic.c | 30 ---
 drivers/gpu/drm/msm/msm_drv.c| 65 ++--
 drivers/gpu/drm/msm/msm_drv.h|  4 +-
 drivers/gpu/drm/msm/msm_kms.h| 28 +-
 5 files changed, 95 insertions(+), 69 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
index 6d8e3a9a6fc0..f1a248419655 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
@@ -74,36 +74,32 @@ struct mdp5_state *mdp5_get_state(struct
drm_atomic_state *s)
 {
struct msm_drm_private *priv = s->dev->dev_private;
struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(priv->kms));
-   struct msm_kms_state *state = to_kms_state(s);
-   struct mdp5_state *new_state;
+   struct msm_kms_state *kms_state;
int ret;

-   if (state->state)
-   return state->state;
-
ret = drm_modeset_lock(_kms->state_lock, s->acquire_ctx);
if (ret)
return ERR_PTR(ret);

-   new_state = kmalloc(sizeof(*mdp5_kms->state), GFP_KERNEL);
-   if (!new_state)
-   return ERR_PTR(-ENOMEM);
+   kms_state = msm_kms_get_state(s);
+   if (IS_ERR_OR_NULL(kms_state))
+   return (struct mdp5_state *)kms_state; /* casting ERR_PTR
*/

-   /* Copy state: */
-   new_state->hwpipe = mdp5_kms->state->hwpipe;
-   new_state->hwmixer = mdp5_kms->state->hwmixer;
-   if (mdp5_kms->smp)
-   new_state->smp = mdp5_kms->state->smp;
+   return kms_state->state;
+}

-   state->state = new_state;
+static void *mdp5_duplicate_state(void *state)
+{
+   if (!state)
+   return kzalloc(sizeof(struct mdp5_state), GFP_KERNEL);

-   return new_state;
+   return kmemdup(state, sizeof(struct mdp5_state), GFP_KERNEL);
 }

-static void mdp5_swap_state(struct msm_kms *kms, struct 
drm_atomic_state

*state)
+static void mdp5_destroy_state(void *state)
 {
-   struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(kms));
-   swap(to_kms_state(state)->state, mdp5_kms->state);
+   struct mdp5_state *mdp_state = state;
+   kfree(mdp_state);
 }

 static void mdp5_prepare_commit(struct msm_kms *kms, struct
drm_atomic_state *state)
@@ -229,7 +225,8 @@ static const struct mdp_kms_funcs kms_funcs = {
.irq = mdp5_irq,
.enable_vblank   = mdp5_enable_vblank,
.disable_vblank  = mdp5_disable_vblank,
-   .swap_state  = mdp5_swap_state,
+   .duplicate_state = mdp5_duplicate_state,
+   .destroy_state   = mdp5_destroy_state,
.prepare_commit  = mdp5_prepare_commit,
.complete_commit = mdp5_complete_commit,
.wait_for_crtc_commit_done =
mdp5_wait_for_crtc_commit_done,
@@ -726,8 +723,6 @@ static void mdp5_destroy(struct platform_device 
*pdev)


if (mdp5_kms->rpm_enabled)
pm_runtime_disable(>dev);
-
-   kfree(mdp5_kms->state);
 }

 static int construct_pipes(struct mdp5_kms *mdp5_kms, int cnt,
diff --git a/drivers/gpu/drm/msm/msm_atomic.c
b/drivers/gpu/drm/msm/msm_atomic.c
index 7e54eb65d096..1f53262ea46b 100644
--- a/drivers/gpu/drm/msm/msm_atomic.c
+++ b/drivers/gpu/drm/msm/msm_atomic.c
@@ -169,9 +169,6 @@ int msm_atomic_commit(struct drm_device *dev,
 */
BUG_ON(drm_atomic_helper_swap_state(state, false) < 0);

-   if (to_kms_state(state)->state)
-   priv->kms->funcs->swap_state(priv->kms, state);
-
/*
 * Provide the driver a chance to prepare for output fences. This
is
 * done after the point of no return, but before asynchronous
commits
@@ -210,30 +207,3 @@ int msm_atomic_commit(struct drm_device *dev,
drm_atomic_helper_cleanup_planes(dev, state);
return ret;
 }
-
-struct drm_atomic_state *msm_atomic_state_alloc(struct drm_device 
*dev)

-{
-   struct msm_kms_state *state = kzalloc(sizeof(*state), GFP_KERNEL);
-
-   if (!state || drm_atomic_state_init(dev, >base) < 0) {
-   kfree(state);
-   return NULL;
-   }
-
-   return >base;
-}
-
-void msm_atomic_state_clear(struct drm_atomic_state *s)
-{
-   struct msm_kms_state *state = to_kms_state(s);
-   drm_atomic_state_default_clear(>base);
-   kfree(state->state);
-   

[PATCH v2] drm/i915: Disable some extra clang warnings

[Matthias Kaehlcke]

Commit 39bf4de89ff7 ("drm/i915: Add -Wall -Wextra to our build, set
warnings to full") enabled extra warnings for i915 to spot possible
bugs in new code, and then disabled a subset of these warnings to keep
the current code building without warnings (with gcc). Enabling the
extra warnings also enabled some additional clang-only warnings, as a
result building i915 with clang currently is extremely noisy. For now
also disable the clang warnings sign-compare, sometimes-uninitialized,
unneeded-internal-declaration and initializer-overrides. If desired
they can be re-enabled after the code has been fixed.

Fixes: 39bf4de89ff7 ("drm/i915: Add -Wall -Wextra to our build, set
warnings to full")
Signed-off-by: Matthias Kaehlcke 
---
Changes in v2:
- rebased on drm-tip
- added comment indicating that disabled warnings are clang warnings

 drivers/gpu/drm/i915/Makefile | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 4eee91a3a236..9717c037b582 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -18,6 +18,11 @@ subdir-ccflags-y += $(call cc-disable-warning, type-limits)
 subdir-ccflags-y += $(call cc-disable-warning, missing-field-initializers)
 subdir-ccflags-y += $(call cc-disable-warning, implicit-fallthrough)
 subdir-ccflags-y += $(call cc-disable-warning, unused-but-set-variable)
+# clang warnings
+subdir-ccflags-y += $(call cc-disable-warning, sign-compare)
+subdir-ccflags-y += $(call cc-disable-warning, sometimes-uninitialized)
+subdir-ccflags-y += $(call cc-disable-warning, unneeded-internal-declaration)
+subdir-ccflags-y += $(call cc-disable-warning, initializer-overrides)
 subdir-ccflags-$(CONFIG_DRM_I915_WERROR) += -Werror
 
 # Fine grained warnings disable
-- 
2.16.2.804.g6dcf76e118-goog

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

Re: [PATCH hwc v1] [RFC] drm_hwcomposer: Flatten composition using writeback connector

[Sean Paul]

On Tue, Mar 13, 2018 at 04:21:20PM +, Alexandru Gheorghe wrote:
> This patchset tries to add support for using writeback connector to
> flatten a scene when it doesn't change for a while. This idea had
> been floated around on IRC here [1] and here [2].
> 
> Developed on top of the latest writeback series, sent by Liviu here
> [3].
> 
> Probably the patch should/could be broken in more patches, but since I
> want to put this out there to get feedback, I kept them as a single
> patch for now.

Thank you for your patch, it's looking good. Feel free to submit the v2 in
multiple patches. Also note that we've migrated to gitlab, the new tree is
located here:

https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer


> 
> This change could be summarize as follow:
> - Attach a writeback connector to the CRTC that's controlling a
> display.
> - Detect the scene did not change for a while(60 vblanks).
> - Re-commit scene and get the composited scene through the writeback
> connector.
> - Commit the whole scene as a single plane.
> 
> Some areas that I consider important and I could use some
> feedback/ideas:
> 
> 1. Building the pipeline.
> Currently, drm_hwcomposer allows to connect just a single connector
> to a crtc. For now, I decided to treat the writeback connector as a
> separate field inside DrmCrtc. I'm not sure if it's a good idea to try
> to handle this in a unified way, since the writeback connector is such
> a special connector. Regarding the allocation of writeback connectors,
> my idea was to allocate writeback connector to the primary display
> first and then continue allocating while respecting the display number. 0
> gets a writeback before 1 and so on.
> 
> 2. Heuristic for triggering the flattening.
> I just created a VSyncWorker which will trigger the flattening of the
> scene if it doesn't change for 60 consecutive vsyncs. The countdown
> gets reset every time ValidateDisplay is called. This is a relatively
> basic heuristic, so I'm open to suggestions.
> 
> 3. Locking scheme corner cases.
> The Vsynworker is a separate thread which will contend with
> SurfaceFlinger for showing things on the screen. I tried to limit the
> race window by resetting the countdown on ValidateDisplay and
> explicitely checking that we still need to use the flatten scene before
> commiting to get the writeback result or before applying the flattened
> scene.
> 
> 4. Building the DrmDisplayComposition for the flattened scene.
> I kind of lost myself  in all types of layers/planes and compositions,
> so I'm not sure if I'm correctly building the DrmDisplayComposition
> object for the FlattenScene, it works and shows what I expect on the
> screen. So, any feedback here is appreciated.
> 
> 5. I see there is a drmcompositorworker.cpp which implemented the same
> idea using the GPU, however that seems to not be used anymore, does
> anyone know the rationale behind it?
> 
> Some unfinished/untested things:
> - Make sure the DrmFrameBuffer allocates one of the formats reported
>   in WRITEBACK_PIXEL_FORMATS.
> - I'm using a hacked setup where, when needed it, the GL compositing is
>   done by Surfaceflinger, so I'm not sure how well this changes are
>   getting along with the GLCompositorWorker.
> 
> [1] 
> https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel_names==2018-02-23
> [2] 
> https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel_names==2018-02-09
> [3] https://lists.freedesktop.org/archives/dri-devel/2018-February/167703.html
> 
> Signed-off-by: Alexandru Gheorghe 
> ---
>  drmconnector.cpp |  36 ++-
>  drmconnector.h   |   8 +++
>  drmcrtc.cpp  |  11 +++-
>  drmcrtc.h|   8 ++-
>  drmdisplaycompositor.cpp | 164 
> +--
>  drmdisplaycompositor.h   |  16 +++--
>  drmencoder.cpp   |  15 +
>  drmencoder.h |   7 +-
>  drmhwctwo.cpp|   1 +
>  drmresources.cpp |  56 +++-
>  drmresources.h   |   1 +
>  11 files changed, 306 insertions(+), 17 deletions(-)
> 
> diff --git a/drmconnector.cpp b/drmconnector.cpp
> index 145518f..2ed4f23 100644
> --- a/drmconnector.cpp
> +++ b/drmconnector.cpp
> @@ -52,6 +52,23 @@ int DrmConnector::Init() {
>  ALOGE("Could not get CRTC_ID property\n");
>  return ret;
>}
> +  if (writeback()) {
> +ret = drm_->GetConnectorProperty(*this, "WRITEBACK_PIXEL_FORMATS", 
> _pixel_formats_);
> +if (ret) {
> +  ALOGE("Could not get WRITEBACK_PIXEL_FORMATS connector_id = %d\n", 
> id_);
> +  return ret;
> +}
> +ret = drm_->GetConnectorProperty(*this, "WRITEBACK_FB_ID", 
> _fb_id_);
> +if (ret) {
> +  ALOGE("Could not get WRITEBACK_FB_ID connector_id = %d\n", id_);
> +  return ret;
> +}
> +ret = drm_->GetConnectorProperty(*this, "WRITEBACK_OUT_FENCE_PTR", 
> _out_fence_);
> +if (ret) {
> +  ALOGE("Could not get 

[DPU PATCH v2] drm/msm: Use atomic private_obj instead of subclassing

[Sean Paul]

Instead of subclassing atomic state, store driver private data in
private_obj/state. This allows us to remove the swap_state driver hook
for mdp5 and get closer to using the atomic helpers entirely.

Changes in v2:
 - Use state->state in disp duplicate_state callback (Jeykumar)

Cc: Jeykumar Sankaran 
Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 37 ++
 drivers/gpu/drm/msm/msm_atomic.c | 30 ---
 drivers/gpu/drm/msm/msm_drv.c| 65 ++--
 drivers/gpu/drm/msm/msm_drv.h|  4 +-
 drivers/gpu/drm/msm/msm_kms.h| 28 +-
 5 files changed, 95 insertions(+), 69 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
index 6d8e3a9a6fc0..f1a248419655 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
@@ -74,36 +74,32 @@ struct mdp5_state *mdp5_get_state(struct drm_atomic_state 
*s)
 {
struct msm_drm_private *priv = s->dev->dev_private;
struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(priv->kms));
-   struct msm_kms_state *state = to_kms_state(s);
-   struct mdp5_state *new_state;
+   struct msm_kms_state *kms_state;
int ret;
 
-   if (state->state)
-   return state->state;
-
ret = drm_modeset_lock(_kms->state_lock, s->acquire_ctx);
if (ret)
return ERR_PTR(ret);
 
-   new_state = kmalloc(sizeof(*mdp5_kms->state), GFP_KERNEL);
-   if (!new_state)
-   return ERR_PTR(-ENOMEM);
+   kms_state = msm_kms_get_state(s);
+   if (IS_ERR_OR_NULL(kms_state))
+   return (struct mdp5_state *)kms_state; /* casting ERR_PTR */
 
-   /* Copy state: */
-   new_state->hwpipe = mdp5_kms->state->hwpipe;
-   new_state->hwmixer = mdp5_kms->state->hwmixer;
-   if (mdp5_kms->smp)
-   new_state->smp = mdp5_kms->state->smp;
+   return kms_state->state;
+}
 
-   state->state = new_state;
+static void *mdp5_duplicate_state(void *state)
+{
+   if (!state)
+   return kzalloc(sizeof(struct mdp5_state), GFP_KERNEL);
 
-   return new_state;
+   return kmemdup(state, sizeof(struct mdp5_state), GFP_KERNEL);
 }
 
-static void mdp5_swap_state(struct msm_kms *kms, struct drm_atomic_state 
*state)
+static void mdp5_destroy_state(void *state)
 {
-   struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(kms));
-   swap(to_kms_state(state)->state, mdp5_kms->state);
+   struct mdp5_state *mdp_state = state;
+   kfree(mdp_state);
 }
 
 static void mdp5_prepare_commit(struct msm_kms *kms, struct drm_atomic_state 
*state)
@@ -229,7 +225,8 @@ static const struct mdp_kms_funcs kms_funcs = {
.irq = mdp5_irq,
.enable_vblank   = mdp5_enable_vblank,
.disable_vblank  = mdp5_disable_vblank,
-   .swap_state  = mdp5_swap_state,
+   .duplicate_state = mdp5_duplicate_state,
+   .destroy_state   = mdp5_destroy_state,
.prepare_commit  = mdp5_prepare_commit,
.complete_commit = mdp5_complete_commit,
.wait_for_crtc_commit_done = mdp5_wait_for_crtc_commit_done,
@@ -726,8 +723,6 @@ static void mdp5_destroy(struct platform_device *pdev)
 
if (mdp5_kms->rpm_enabled)
pm_runtime_disable(>dev);
-
-   kfree(mdp5_kms->state);
 }
 
 static int construct_pipes(struct mdp5_kms *mdp5_kms, int cnt,
diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c
index 7e54eb65d096..1f53262ea46b 100644
--- a/drivers/gpu/drm/msm/msm_atomic.c
+++ b/drivers/gpu/drm/msm/msm_atomic.c
@@ -169,9 +169,6 @@ int msm_atomic_commit(struct drm_device *dev,
 */
BUG_ON(drm_atomic_helper_swap_state(state, false) < 0);
 
-   if (to_kms_state(state)->state)
-   priv->kms->funcs->swap_state(priv->kms, state);
-
/*
 * Provide the driver a chance to prepare for output fences. This is
 * done after the point of no return, but before asynchronous commits
@@ -210,30 +207,3 @@ int msm_atomic_commit(struct drm_device *dev,
drm_atomic_helper_cleanup_planes(dev, state);
return ret;
 }
-
-struct drm_atomic_state *msm_atomic_state_alloc(struct drm_device *dev)
-{
-   struct msm_kms_state *state = kzalloc(sizeof(*state), GFP_KERNEL);
-
-   if (!state || drm_atomic_state_init(dev, >base) < 0) {
-   kfree(state);
-   return NULL;
-   }
-
-   return >base;
-}
-
-void msm_atomic_state_clear(struct drm_atomic_state *s)
-{
-   struct msm_kms_state *state = to_kms_state(s);
-   drm_atomic_state_default_clear(>base);
-   kfree(state->state);
-   state->state = NULL;
-}
-
-void msm_atomic_state_free(struct drm_atomic_state *state)
-{
-   

[PATCH libdrm 1/1] intel: allocate the requested size when reuse is disabled

[James Xiong]

From: "Xiong, James" 

1) fixed a bug: a bucket size instead of the requested
was allocated even when reuse is disabled. 2) set bo_reuse
explicitly

Signed-off-by: Xiong, James 
---
 intel/intel_bufmgr_gem.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 386da30..6fdb1ca 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -402,6 +402,9 @@ drm_intel_gem_bo_bucket_for_size(drm_intel_bufmgr_gem 
*bufmgr_gem,
 {
int i;
 
+   if (!bufmgr_gem->bo_reuse)
+   return NULL;
+
for (i = 0; i < bufmgr_gem->num_buckets; i++) {
struct drm_intel_gem_bo_bucket *bucket =
_gem->cache_bucket[i];
@@ -1382,7 +1385,7 @@ drm_intel_gem_bo_unreference_final(drm_intel_bo *bo, 
time_t time)
 
bucket = drm_intel_gem_bo_bucket_for_size(bufmgr_gem, bo->size);
/* Put the buffer into our internal cache for reuse if we can. */
-   if (bufmgr_gem->bo_reuse && bo_gem->reusable && bucket != NULL &&
+   if (bo_gem->reusable && bucket != NULL &&
drm_intel_gem_bo_madvise_internal(bufmgr_gem, bo_gem,
  I915_MADV_DONTNEED)) {
bo_gem->free_time = time;
@@ -3806,6 +3809,7 @@ drm_intel_bufmgr_gem_init(int fd, int batch_size)
drm_intel_gem_get_pipe_from_crtc_id;
bufmgr_gem->bufmgr.bo_references = drm_intel_gem_bo_references;
 
+   bufmgr_gem->bo_reuse = false;
init_cache_buckets(bufmgr_gem);
 
DRMINITLISTHEAD(_gem->vma_cache);
-- 
2.7.4

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

[Bug 105611] Alt-Tabbing in kwin results in SIGSEV in radeonsi

[bugzilla-daemon]

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

Clemens Eisserer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Clemens Eisserer  ---


*** This bug has been marked as a duplicate of bug 103234 ***

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

[Bug 103234] KWin crashed when Alt+Tab-ing through open windows

[bugzilla-daemon]

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

Clemens Eisserer  changed:

   What|Removed |Added

 CC||linuxhi...@gmail.com

--- Comment #17 from Clemens Eisserer  ---
*** Bug 105611 has been marked as a duplicate of this bug. ***

-- 
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: [GIT PULL] drm/tegra: Changes for v4.17-rc1

[Thierry Reding]

On Mon, Mar 19, 2018 at 02:32:08PM +, Marcel Ziswiler wrote:
> Hi Thierry
> 
> On Mon, 2018-03-19 at 10:59 +0100, Thierry Reding wrote:
> > Hi Dave,
> > 
> > The following changes since commit
> > 7928b2cbe55b2a410a0f5c1f154610059c57b1b2:
> > 
> >   Linux 4.16-rc1 (2018-02-11 15:04:29 -0800)
> > 
> > are available in the Git repository at:
> > 
> >   git://anongit.freedesktop.org/tegra/linux tags/drm/tegra/for-4.17-
> > rc1
> > 
> > for you to fetch changes up to
> > 27e92f1f1600c214bf649daddb9b88b68330a8d1:
> > 
> >   drm/tegra: prime: Implement ->{begin,end}_cpu_access() (2018-03-17
> > 00:04:20 +0100)
> > 
> > Apologies for the delay. I originally wanted to send this out on
> > Friday
> > but then ran into a pair of bugs that I thought might be caused by
> > this
> > branch. Turns out that they were both already broken in v4.16-rc1 and
> > I
> > just hadn't tested for the corner case, so I caught them only very
> > late
> > in the release cycle.
> > 
> > Anyway, the fixes for that are on the drm/tegra/fixes branch for
> > which
> > I sent an updated pull request earlier. The stuff here's fairly
> > trivial
> > and incremental improvements.
> 
> Both linux-next as of Friday and today as well as your
> tags/drm/tegra/for-4.17-rc1 fail for me on TK1 as follows:
> 
> [3.609146] +V1.05_AVDD_HDMI_PLL: supplied by +V1.05
> [3.614294] +V3.3_AVDD_HDMI: supplied by +V1.05
> [3.622078] [ cut here ]
> [3.626719] WARNING: CPU: 2 PID: 87 at
> /run/media/zim/Build/Sources/linux-
> tegra.git/drivers/gpu/drm/drm_fourcc.c:204 drm_format_info+0x48/0x50
> [3.639588] Modules linked in:
> [3.642673] CPU: 2 PID: 87 Comm: kworker/2:1 Not tainted 4.16.0-rc1
> #2
> [3.649213] Hardware name: NVIDIA Tegra SoC (Flattened Device Tree)
> [3.655495] Workqueue: events deferred_probe_work_func
> [3.660672] [] (unwind_backtrace) from []
> (show_stack+0x10/0x14)
> [3.668430] [] (show_stack) from []
> (dump_stack+0x8c/0xa0)
> [3.675684] [] (dump_stack) from []
> (__warn+0xe0/0xf8)
> [3.682587] [] (__warn) from []
> (warn_slowpath_null+0x40/0x48)
> [3.690189] [] (warn_slowpath_null) from []
> (drm_format_info+0x48/0x50)
> [3.698551] [] (drm_format_info) from []
> (tegra_plane_format_mod_supported+0x14/0x30)
> [3.708150] [] (tegra_plane_format_mod_supported) from
> [] (drm_universal_plane_init+0x2ec/0x59c)
> [3.718703] [] (drm_universal_plane_init) from
> [] (tegra_dc_init+0x1b8/0x510)
> [3.727611] [] (tegra_dc_init) from []
> (host1x_device_init+0x44/0xd0)
> [3.735821] [] (host1x_device_init) from []
> (tegra_drm_load+0x228/0x308)
> [3.744291] [] (tegra_drm_load) from []
> (drm_dev_register+0x138/0x1d0)
> [3.752588] [] (drm_dev_register) from []
> (host1x_drm_probe+0x34/0x58)
> [3.760883] [] (host1x_drm_probe) from []
> (driver_probe_device+0x254/0x32c)
> [3.769612] [] (driver_probe_device) from []
> (bus_for_each_drv+0x58/0xb8)
> [3.778145] [] (bus_for_each_drv) from []
> (__device_attach+0xd0/0x138)
> [3.786436] [] (__device_attach) from []
> (bus_probe_device+0x84/0x8c)
> [3.794645] [] (bus_probe_device) from []
> (device_add+0x3b4/0x5b8)
> [3.802599] [] (device_add) from []
> (host1x_subdev_register+0xac/0xd4)
> [3.810897] [] (host1x_subdev_register) from []
> (host1x_client_register+0x108/0x128)
> [3.820412] [] (host1x_client_register) from []
> (tegra_hdmi_probe+0x1e4/0x2d0)
> [3.829406] [] (tegra_hdmi_probe) from []
> (platform_drv_probe+0x50/0xac)
> [3.837855] [] (platform_drv_probe) from []
> (driver_probe_device+0x254/0x32c)
> [3.846756] [] (driver_probe_device) from []
> (bus_for_each_drv+0x58/0xb8)
> [3.855309] [] (bus_for_each_drv) from []
> (__device_attach+0xd0/0x138)
> [3.863603] [] (__device_attach) from []
> (bus_probe_device+0x84/0x8c)
> [3.871809] [] (bus_probe_device) from []
> (deferred_probe_work_func+0x4c/0x148)
> [3.880885] [] (deferred_probe_work_func) from
> [] (process_one_work+0x1ec/0x55c)
> [3.890047] [] (process_one_work) from []
> (worker_thread+0x29c/0x598)
> [3.898237] [] (worker_thread) from []
> (kthread+0x14c/0x154)
> [3.905662] [] (kthread) from []
> (ret_from_fork+0x14/0x2c)
> [3.912901] Exception stack(0xee2b1fb0 to 0xee2b1ff8)
> [3.917958] 1fa0: 
>   
> [3.926153] 1fc0:     
>   
> [3.934348] 1fe0:     0013
> 
> [3.941050] ---[ end trace f2913c9fb893aca6 ]---
> ...
> [4.594476] Unable to handle kernel NULL pointer dereference at
> virtual address 0005
> [4.602584] pgd = b237c3d6
> [4.605293] [0005] *pgd=
> [4.608895] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
> [4.614209] Modules linked in:
> [4.617274] CPU: 2 PID: 87 Comm: kworker/2:1 Tainted:
> GW4.16.0-rc1 #2
> [

[PATCH] drm/i915: Promote .format_mod_supported() to the lead role

[Ville Syrjala]

From: Ville Syrjälä 

Up to now we've used the plane's modifier list as the primary
source of information for which modifiers are supported by a
given plane. In order to allow auxiliary metadata to be embedded
within the bits of the modifier we need to stop doing that.

Thus we have to make .format_mod_supported() aware of the plane's
capabilities and gracefully deal with any modifier being passed
in directly from userspace.

Cc: Eric Anholt 
References: 
https://lists.freedesktop.org/archives/dri-devel/2018-March/169782.html
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 147 +++---
 drivers/gpu/drm/i915/intel_drv.h |   1 +
 drivers/gpu/drm/i915/intel_sprite.c  | 194 ++-
 3 files changed, 210 insertions(+), 132 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 3e7ab75e1b41..d717004be0b8 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -88,15 +88,7 @@ static const uint32_t skl_primary_formats[] = {
DRM_FORMAT_VYUY,
 };
 
-static const uint64_t skl_format_modifiers_noccs[] = {
-   I915_FORMAT_MOD_Yf_TILED,
-   I915_FORMAT_MOD_Y_TILED,
-   I915_FORMAT_MOD_X_TILED,
-   DRM_FORMAT_MOD_LINEAR,
-   DRM_FORMAT_MOD_INVALID
-};
-
-static const uint64_t skl_format_modifiers_ccs[] = {
+static const uint64_t skl_format_modifiers[] = {
I915_FORMAT_MOD_Yf_TILED_CCS,
I915_FORMAT_MOD_Y_TILED_CCS,
I915_FORMAT_MOD_Yf_TILED,
@@ -12997,8 +12989,17 @@ void intel_plane_destroy(struct drm_plane *plane)
kfree(to_intel_plane(plane));
 }
 
-static bool i8xx_mod_supported(uint32_t format, uint64_t modifier)
+static bool i8xx_plane_format_mod_supported(struct drm_plane *_plane,
+   u32 format, u64 modifier)
 {
+   switch (modifier) {
+   case DRM_FORMAT_MOD_LINEAR:
+   case I915_FORMAT_MOD_X_TILED:
+   break;
+   default:
+   return false;
+   }
+
switch (format) {
case DRM_FORMAT_C8:
case DRM_FORMAT_RGB565:
@@ -13011,8 +13012,17 @@ static bool i8xx_mod_supported(uint32_t format, 
uint64_t modifier)
}
 }
 
-static bool i965_mod_supported(uint32_t format, uint64_t modifier)
+static bool i965_plane_format_mod_supported(struct drm_plane *_plane,
+   u32 format, u64 modifier)
 {
+   switch (modifier) {
+   case DRM_FORMAT_MOD_LINEAR:
+   case I915_FORMAT_MOD_X_TILED:
+   break;
+   default:
+   return false;
+   }
+
switch (format) {
case DRM_FORMAT_C8:
case DRM_FORMAT_RGB565:
@@ -13027,17 +13037,37 @@ static bool i965_mod_supported(uint32_t format, 
uint64_t modifier)
}
 }
 
-static bool skl_mod_supported(uint32_t format, uint64_t modifier)
+static bool skl_plane_format_mod_supported(struct drm_plane *_plane,
+  u32 format, u64 modifier)
 {
+   struct intel_plane *plane = to_intel_plane(_plane);
+
+   switch (modifier) {
+   case DRM_FORMAT_MOD_LINEAR:
+   case I915_FORMAT_MOD_X_TILED:
+   case I915_FORMAT_MOD_Y_TILED:
+   case I915_FORMAT_MOD_Yf_TILED:
+   break;
+   case I915_FORMAT_MOD_Y_TILED_CCS:
+   case I915_FORMAT_MOD_Yf_TILED_CCS:
+   if (!plane->has_ccs)
+   return false;
+   break;
+   default:
+   return false;
+   }
+
switch (format) {
case DRM_FORMAT_XRGB:
case DRM_FORMAT_XBGR:
case DRM_FORMAT_ARGB:
case DRM_FORMAT_ABGR:
-   if (modifier == I915_FORMAT_MOD_Yf_TILED_CCS ||
-   modifier == I915_FORMAT_MOD_Y_TILED_CCS)
-   return true;
-   /* fall through */
+   return modifier == DRM_FORMAT_MOD_LINEAR ||
+   modifier == I915_FORMAT_MOD_X_TILED ||
+   modifier == I915_FORMAT_MOD_Y_TILED ||
+   modifier == I915_FORMAT_MOD_Yf_TILED ||
+   modifier == I915_FORMAT_MOD_Y_TILED_CCS ||
+   modifier == I915_FORMAT_MOD_Yf_TILED_CCS;
case DRM_FORMAT_RGB565:
case DRM_FORMAT_XRGB2101010:
case DRM_FORMAT_XBGR2101010:
@@ -13045,52 +13075,49 @@ static bool skl_mod_supported(uint32_t format, 
uint64_t modifier)
case DRM_FORMAT_YVYU:
case DRM_FORMAT_UYVY:
case DRM_FORMAT_VYUY:
-   if (modifier == I915_FORMAT_MOD_Yf_TILED)
-   return true;
-   /* fall through */
+   return modifier == DRM_FORMAT_MOD_LINEAR ||
+   modifier == I915_FORMAT_MOD_X_TILED ||
+   modifier == 

[Bug 105611] Alt-Tabbing in kwin results in SIGSEV in radeonsi

[bugzilla-daemon]

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

Bug ID: 105611
   Summary: Alt-Tabbing in kwin results in SIGSEV in radeonsi
   Product: Mesa
   Version: 17.3
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: linuxhi...@gmail.com
QA Contact: dri-devel@lists.freedesktop.org

Alt+Tab on my kaveri 7650k system with 4k+full-hd screens (amdgpu,
linux-4.15.9, mesa-17.3.6) running kde/kwin with compositor enabled results in:

Thread 26 "gallium_drv:0" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fff63fff700 (LWP 9101)]
si_draw_vbo (ctx=0x56963dc0, info=0x569d7be8) at si_state_draw.c:1372
1372} else if (sctx->b.chip_class <= CIK &&
#0  0x7fffc37fa890 in si_draw_vbo (ctx=0x56963dc0, info=0x569d7be8)
at si_state_draw.c:1372
sctx = 0x56963dc0
rs = 
indexbuf = 0x0
dirty_tex_counter = 
rast_prim = 
index_size = 2
index_offset = 0
#1  0x7fffc351d593 in tc_call_draw_vbo (pipe=,
payload=0x569d7be8) at util/u_threaded_context.c:1816
info = 0x569d7be8
#2  0x7fffc351a990 in tc_batch_execute (job=job@entry=0x569d7340,
thread_index=thread_index@entry=0) at util/u_threaded_context.c:94
iter = 0x569d7be0
batch = 0x569d7340
pipe = 0x56963dc0
last = 0x569d7fa0
#3  0x7fffc33e2fda in util_queue_thread_func
(input=input@entry=0x5688f1c0) at u_queue.c:187
job = {job = 0x569d7340, fence = 0x569d7350, execute =
0x7fffc351a950 , cleanup = 0x0}
queue = 0x569d5978
thread_index = 0
#4  0x7fffc33e2e67 in impl_thrd_routine (p=) at
../../include/c11/threads_posix.h:87
pack = {func = 0x7fffc33e2ea0 , arg =
0x5688f1c0}
#5  0x702e050b in start_thread () at /lib64/libpthread.so.0
#6  0x7fffecaa716f in clone () at /lib64/libc.so.6

-- 
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 1/3] drm: Trust format_mod_supported() when it OKs a plane modifier.

[Ville Syrjälä]

On Fri, Mar 16, 2018 at 03:04:33PM -0700, Eric Anholt wrote:
> For parameterized modifiers (Broadcom's SAND and UIF), we need to
> allow the parameter fields to be filled in, while exposing only the
> variant of the modifier with the parameter unfilled in the internal
> arrays and the format blob.
> 
> Signed-off-by: Eric Anholt 
> Cc: Ville Syrjälä 
> ---
>  drivers/gpu/drm/drm_plane.c | 23 ---
>  include/drm/drm_plane.h |  5 -
>  2 files changed, 16 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index 46fbd019a337..5bb501f1aae8 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -561,19 +561,20 @@ int drm_plane_check_pixel_format(struct drm_plane 
> *plane,
>   if (i == plane->format_count)
>   return -EINVAL;
>  
> - if (!plane->modifier_count)
> - return 0;
> + if (plane->funcs->format_mod_supported) {
> + if (!plane->funcs->format_mod_supported(plane, format, 
> modifier))
> + return -EINVAL;
> + } else {
> + if (!plane->modifier_count)
> + return 0;
>  
> - for (i = 0; i < plane->modifier_count; i++) {
> - if (modifier == plane->modifiers[i])
> - break;
> + for (i = 0; i < plane->modifier_count; i++) {
> + if (modifier == plane->modifiers[i])
> + break;
> + }
> + if (i == plane->modifier_count)
> + return -EINVAL;
>   }
> - if (i == plane->modifier_count)
> - return -EINVAL;
> -
> - if (plane->funcs->format_mod_supported &&
> - !plane->funcs->format_mod_supported(plane, format, modifier))
> - return -EINVAL;
>  
>   return 0;
>  }
> diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
> index f7bf4a48b1c3..6b1b51645f75 100644
> --- a/include/drm/drm_plane.h
> +++ b/include/drm/drm_plane.h
> @@ -420,7 +420,10 @@ struct drm_plane_funcs {
>* This optional hook is used for the DRM to determine if the given
>* format/modifier combination is valid for the plane. This allows the
>* DRM to generate the correct format bitmask (which formats apply to
> -  * which modifier).
> +  * which modifier), and to valdiate modifiers at atomic_check time.
> +  *
> +  * If not present, then any modifier in the plane's modifier
> +  * list is allowed with any of the plane's formats.

This certainly avoids the vfunc profileration that using the
modifiers list causes. So yeah I do like it from that angle.

It does promote .format_mod_supported() to a more prominent role. My
original idea for .format_mod_supported() was that it could be very
lightweight; just reject the exceptional cases and assume everything
else is fine. With the change of role I think the docs should make it
very clear that _any_ modifier can be passed to this function directly
from userspace. The driver must handle that gracefully and without
spewing any non-debug stuff to dmesg.

Also I definitely need to change i915. Currently we're using the
modifier list as the primary means by which we filter out unsupported
modifiers for planes, and .format_mod_support() just serves an
supporting role further removing any format+mod combination that isn't
valid. So I need to make .format_mod_supported() the lead actor here
and the modifier list just serves as a starting point which we filter
down to something we can report via the IN_FORMATS blobifier.

Hmm. And now the question becomes should we make .format_mod_supported()
take over the role of validating the pixel format as well from the
plane's format list? It would certainly be more in line with the
approach we're now going to take with modifiers.

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

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

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

--- Comment #187 from Lauri Gustafsson  ---
About "I can force a system hard-lock by doing anything which disables a
monitor", on my system it used to crash more frequently the less desktop area I
had. Small resolution monitor crashes often, multi monitor setup less often.
But I don't have the hardware any more so I can't test if it still works that
way.

-- 
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 1/5] dma-buf: add optional invalidate_mappings callback v2

[Christian König]

Am 19.03.2018 um 16:53 schrieb Chris Wilson:

Quoting Christian König (2018-03-16 14:22:32)
[snip, probably lost too must context]

This allows for full grown pipelining, e.g. the exporter can say I need
to move the buffer for some operation. Then let the move operation wait
for all existing fences in the reservation object and install the fence
of the move operation as exclusive fence.

Ok, the situation I have in mind is the non-pipelined case: revoking
dma-buf for mmu_invalidate_range or shrink_slab. I would need a
completion event that can be waited on the cpu for all the invalidate
callbacks. (Essentially an atomic_t counter plus struct completion; a
lighter version of dma_fence, I wonder where I've seen that before ;)


Actually that is harmless.

When you need to unmap a DMA-buf because of mmu_invalidate_range or 
shrink_slab you need to wait for it's reservation object anyway.


This needs to be done to make sure that the backing memory is now idle, 
it doesn't matter if the jobs where submitted by DMA-buf importers or 
your own driver.


The sg tables pointing to the now released memory might live a bit 
longer, but that is unproblematic and actually intended.


When we would try to destroy the sg tables in an mmu_invalidate_range or 
shrink_slab callback we would run into a lockdep horror.


Regards,
Christian.



Even so, it basically means passing a fence object down to the async
callbacks for them to signal when they are complete. Just to handle the
non-pipelined version. :|
-Chris
___
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

[Bug 105534] amdgpu cannot set 2560x1440@60 mode even though monitor,gpu and motherboard support it

[bugzilla-daemon]

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

--- Comment #14 from Alex Deucher  ---
(In reply to philipmorant from comment #13)
> No, that's not it either. Apparently it's not going through
> amdgpu_connector_dvi_mode_valid().  My trace output (using DRM_ERROR()) does
> not appear in syslog.

That's the legacy pre-DC code.

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

[Bug 105534] amdgpu cannot set 2560x1440@60 mode even though monitor,gpu and motherboard support it

[bugzilla-daemon]

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

--- Comment #13 from philipmor...@gmail.com ---
No, that's not it either. Apparently it's not going through
amdgpu_connector_dvi_mode_valid().  My trace output (using DRM_ERROR()) does
not appear in syslog.

-- 
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 1/5] dma-buf: add optional invalidate_mappings callback v2

[Chris Wilson]

Quoting Christian König (2018-03-16 14:22:32)
[snip, probably lost too must context]
> This allows for full grown pipelining, e.g. the exporter can say I need 
> to move the buffer for some operation. Then let the move operation wait 
> for all existing fences in the reservation object and install the fence 
> of the move operation as exclusive fence.

Ok, the situation I have in mind is the non-pipelined case: revoking
dma-buf for mmu_invalidate_range or shrink_slab. I would need a
completion event that can be waited on the cpu for all the invalidate
callbacks. (Essentially an atomic_t counter plus struct completion; a
lighter version of dma_fence, I wonder where I've seen that before ;)

Even so, it basically means passing a fence object down to the async
callbacks for them to signal when they are complete. Just to handle the
non-pipelined version. :|
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105610] [CI] igt@gem_ctx_isolation@vecs0-s3 - fail - igt_core-WARNING: [cmd] rtcwake: /dev/rtc0: unable to find device: Device or resource busy

[bugzilla-daemon]

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

Marta Löfstedt  changed:

   What|Removed |Added

 Whiteboard||ReadyForDev

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

[Bug 105610] [CI] igt@gem_ctx_isolation@vecs0-s3 - fail - igt_core-WARNING: [cmd] rtcwake: /dev/rtc0: unable to find device: Device or resource busy

[bugzilla-daemon]

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

Marta Löfstedt  changed:

   What|Removed |Added

  Component|DRM/Intel   |IGT
   Assignee|intel-gfx-bugs@lists.freede |dri-devel@lists.freedesktop
   |sktop.org   |.org
 QA Contact|intel-gfx-bugs@lists.freede |
   |sktop.org   |

-- 
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 RESEND v2 1/2] drm/xen-front: Add support for Xen PV display frontend

[Daniel Vetter]

On Mon, Mar 19, 2018 at 3:19 PM, Oleksandr Andrushchenko
 wrote:
> On 03/19/2018 03:51 PM, Daniel Vetter wrote:
>>
>> On Fri, Mar 16, 2018 at 12:52:09PM +0200, Oleksandr Andrushchenko wrote:
>>>
>>> Hi, Daniel!
>>> Sorry, if I strip the patch too much below.
>>>
>>> On 03/16/2018 10:23 AM, Daniel Vetter wrote:

 S-o-b line went missing here :-)
>>>
>>> will restore it back ;)

 I've read through it, 2 actual review comments (around hot-unplug and
 around the error recovery for failed flips), a few bikesheds, but looks
 all reasonable to me. And much easier to read as one big patch (it's
 just
 3k).

 One more thing I'd do as a follow-up (don't rewrite everything, this is
 close to merge, better to get it in first): You have a lot of
 indirections
 and function calls across sources files. That's kinda ok if you have a
 huge driver with 100+k lines of code where you have to split things up.
 But for a small driver like yours here it's a bit overkill.
>>>
>>> will review and try to rework after the driver is in
>
> I'll probably merge xen_drm_front_drv.c and xen_drm_front.c now as
> anyway I have to re-work driver unloading, e.g. "fishy" code below.

 Personally I'd merge at least the xen backend stuff into the
 corresponding
 kms code, but that's up to you.
>>>
>>> I prefer to have it in smaller chunks and all related code at
>>> one place, so it is easier to maintain. That is why I didn't
>>> plumb frontend <-> backend code right into the KMS code.

 And as mentioned, if you decide to do
 that, a follow-up patch (once this has merged) is perfectly fine.
>>>
>>> Ok, after the merge
>>
>> If you prefer your current layout, then pls keep it. Bikeshed = personal
>> style nit, feel free to ignore if you like stuff differently. In the end
>> it's your driver, not mine, and I can easily navigate the current code
>> (with a few extra jumps).
>
> Some of the indirections will be removed by merging
> xen_drm_front_drv.c and xen_drm_front.c. Are these what you
> mean or is there anything else?
>
>> -Daniel
>>
 -Daniel

> +int xen_drm_front_dbuf_create_from_sgt(struct xen_drm_front_info
> *front_info,
> +   uint64_t dbuf_cookie, uint32_t width, uint32_t height,
> +   uint32_t bpp, uint64_t size, struct sg_table *sgt)
> +{
> +   return be_dbuf_create_int(front_info, dbuf_cookie, width,
> height,
> +   bpp, size, NULL, sgt);
> +}
> +
> +int xen_drm_front_dbuf_create_from_pages(struct xen_drm_front_info
> *front_info,
> +   uint64_t dbuf_cookie, uint32_t width, uint32_t height,
> +   uint32_t bpp, uint64_t size, struct page **pages)
> +{
> +   return be_dbuf_create_int(front_info, dbuf_cookie, width,
> height,
> +   bpp, size, pages, NULL);
> +}

 The above two wrappers seem a bit much, just to set sgt = NULL or pages
 =
 NULL in one of them. I'd drop them, but that's a bikeshed so feel free
 to
 ignore.
>>>
>>> I had that the way you say in some of the previous implementations,
>>> but finally decided to have these dummy wrappers: seems
>>> to be cleaner this way
>
> +static void displback_disconnect(struct xen_drm_front_info
> *front_info)
> +{
> +   bool removed = true;
> +
> +   if (front_info->drm_pdev) {
> +   if (xen_drm_front_drv_is_used(front_info->drm_pdev)) {
> +   DRM_WARN("DRM driver still in use, deferring
> removal\n");
> +   removed = false;
> +   } else
> +   xen_drv_remove_internal(front_info);

 Ok this logic here is fishy, since you're open-coding the drm unplug
 infrastructure, but slightly differently and slightyl racy. If you have
 a
 driver where your underlying "hw" (well it's virtual here, but same
 idea)
 can disappear any time while userspace is still using the drm driver,
 you
 need to use the drm_dev_unplug() function and related code.
 drm_dev_unplug() works like drm_dev_unregister, except for the hotplug
 case.

 Then you also have to guard all the driver entry points where you do
 access the backchannel using drm_dev_is_unplugged() (I've seen a few of
 those already). Then you can rip out all the logic here and the
 xen_drm_front_drv_is_used() helper.
>>>
>>> Will rework it with drm_dev_unplug, thank you

 I thought there's some patches from Noralf in-flight that improved the
 docs on this, I need to check
>
> Yes, I will definitely use those as soon as they are available.
> But at the moment let me clarify a bit on the use-cases for driver
> unplugging and backend disconnection.
>
> The backend, by disconnecting, expects full DRM driver teardown, because,
> for 

[Bug 105534] amdgpu cannot set 2560x1440@60 mode even though monitor,gpu and motherboard support it

[bugzilla-daemon]

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

--- Comment #12 from philipmor...@gmail.com ---
static int amdgpu_connector_dvi_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode)
has a hard-coded 165000 and looks likely.
I'll try hacking that to bits.

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

[Bug 105534] amdgpu cannot set 2560x1440@60 mode even though monitor,gpu and motherboard support it

[bugzilla-daemon]

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

--- Comment #11 from philipmor...@gmail.com ---
#TDMS_MAX_PIXEL_CLOCK 33 makes no difference.
See syslog files attached above.

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

[Bug 105534] amdgpu cannot set 2560x1440@60 mode even though monitor,gpu and motherboard support it

[bugzilla-daemon]

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

--- Comment #10 from philipmor...@gmail.com ---
Created attachment 138200
  --> https://bugs.freedesktop.org/attachment.cgi?id=138200=edit
syslog for xrandr --output with drm.debug-0xe and TDMS_MAX_PIXEL_CLOCK 33

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

[Bug 105534] amdgpu cannot set 2560x1440@60 mode even though monitor,gpu and motherboard support it

[bugzilla-daemon]

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

--- Comment #9 from philipmor...@gmail.com ---
Created attachment 138199
  --> https://bugs.freedesktop.org/attachment.cgi?id=138199=edit
syslog for xrandr --addmode with drm.debug-0xe and TDMS_MAX_PIXEL_CLOCK 33

-- 
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: [DPU PATCH 06/11] drm/msm: Remove msm_commit/kthread, use atomic helper commit

[Sean Paul]

On Mon, Mar 12, 2018 at 04:23:10PM -0400, Sean Paul wrote:
> On Thu, Mar 08, 2018 at 05:08:03PM -0800, Jeykumar Sankaran wrote:
> > On 2018-03-02 06:56, Sean Paul wrote:
> > > On Thu, Mar 01, 2018 at 07:37:10PM -0500, Rob Clark wrote:
> > > > On Thu, Mar 1, 2018 at 3:37 PM,   wrote:
> > > > > On 2018-03-01 07:27, Sean Paul wrote:
> > > > >>
> > > > >> On Wed, Feb 28, 2018 at 08:07:00PM -0800, jsa...@codeaurora.org
> > > wrote:
> > > > >>>
> > > > >>> On 2018-02-28 11:19, Sean Paul wrote:
> > > > >>> > Moving further towards switching fully to the the atomic helpers,
> > > this
> > > > >>> > patch removes the hand-rolled kthread nonblock commit code and
> > > uses
> > > > >>
> > > > >> the
> > > > >>>
> > > > >>> > atomic helpers commit_work model.
> > > > >>> >
> > > > >>> > There's still a lot of copypasta here, but it's still needed to
> > > > >>> > facilitate the swap_state and prepare_fence private functions.
> > > These
> > > > >>> > will be sorted out in a follow-on patch.
> > > > >>> >
> > > > >>> > Change-Id: I9fcba27824ba63d3fab96cb2bc194bfa6f3475b7
> > > > >>> > Signed-off-by: Sean Paul 
> > > > >>> > ---



> > > > >>
> > > > >>> > - /* only return zero if work
> > > is
> > > > >>> > -  * queued successfully.
> > > > >>> > -  */
> > > > >>> > - ret = 0;
> > > > >>> > - } else {
> > > > >>> > - DRM_ERROR(" Error for
> > > crtc_id:
> > > > >>> > %d\n",
> > > > >>> > -
> > > > >>> > priv->disp_thread[j].crtc_id);
> > > > >>> > - }
> > > > >>> > - break;
> > > > >>> > - }
> > > > >>> > - }
> > 
> > Care to remove priv->disp_thread and all its references as a part of this
> > change?
> 
> Definitely! Will revise.
> 

Now that I look at it, disp_thread doesn't seem relevant to this change. It
seems like it's used for deferred cleanup. So perhaps we could get rid of it,
but IMO that would be a different patch.

> Sean
> 
> > 
> > - Jeykumar S



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

Re: [PATCH v2 00/11] drm/tinydrm: Support device unplug

[Oleksandr Andrushchenko]

On 03/19/2018 03:45 PM, Daniel Vetter wrote:

On Sat, Mar 17, 2018 at 03:40:29PM +0100, Noralf Trønnes wrote:

Den 16.03.2018 09.03, skrev Daniel Vetter:

On Fri, Sep 8, 2017 at 6:33 PM, Daniel Vetter  wrote:

Hi Noralf,

On Fri, Sep 08, 2017 at 05:07:19PM +0200, Noralf Trønnes wrote:

This adds device unplug support to drm_fb_helper, drm_fb_cma_helper
(fbdev) and tinydrm.

There are several changes in this version:

I've used Daniel's idea of protecting drm_device.unplugged with srcu to
provide race free drm_dev_unplug().

The fbdev helper unplug patch has become very small with Daniel's help.
Ref is now taken and dropped in the existing helpers, so I could drop
drm_fb_helper_simple_init().

I has annoyed me that fbdev is restored in drm_driver.last_close even if
fbdev isn't used. I've added a patch to fix that. This means I can drop
calling drm_atomic_helper_shutdown() in tinydrm_unregister(), since I
now can easily disable the pipeline from userspace by just closing the
users. Disabled pipeline means balanced regulator_enable/disable.

The 'Embed drm_device in tinydrm_device' patch has gained
drm_driver.release functions after a discussion with Laurent. My
previous version relied on obscure freeing in tinydrm_release().
This means that I didn't retain the ack's.

Laurent also caught an ugly devm_kmalloc() in
tinydrm_display_pipe_init() that I've fixed.

I'm practically packing for my 2 weeks of conference travel already, so
only very cursory read of the initial patches for core I think
this looks really splendid now.

But I won't have time for review for the next few week, would be good if
you could drag some others into this discussions. Iirc there's recently
been a few different people interested in udl (even some patches I think),
they might be able to help out with testing

Also, would be great if you can submit this to intel-gfx on the next
round, so that our CI can pick it up and give it a solid beating. Touching
critical core paths like in patch 1 is always a bit scary.

While reviewing xen-front's hotunplug handling I just realized this
never landed. Can you pls resend and nag me to review it properly? I'd
really like to get the drm_dev_unplug stuff sorted out better.

My plan was to pick this up after switching tinydrm over to vmalloc buffers,
but that work is now waiting for the generic fbdev emulation to land.

I'm currently wandering around inside drm_fb_helper looking for a way out,
I can feel the draft so there has to be an exit somewhere. I hope that in
a week or two I'm done with the next version of the RFC using the
drm_fb_helper mode setting code instead of the ioctl's.

At that point it will be a good thing to flush my "caches" of the
drm_fb_helper code, since after looking at it for a long time, I really
don't see the details anymore. So I'll pick up the unplug series then, at
least the core patches should be trivial to review and get merged if the CI
agrees.

Sounds great. I chatted some more with Oleksandr on irc and explained how
he can at least prototype correct unplug code using the current upstream
stuff. He's also willing to help get your stuff landed I think.

Yes, I can try helping with this - please let me know
if you need something.
And at least I can plumb that into my driver and have it tested.

  And afair
the unplug stuff pretty much looked ready for merging already, at least I
don't remember anything big pending.
-Daniel


Noralf.


Thanks, Daniel


Thanks, Daniel


Noralf.

Noralf Trønnes (11):
drm: Use srcu to protect drm_device.unplugged
drm/fb-helper: Support device unplug
drm/fb-helper: Ensure driver module is pinned in fb_open()
drm/fb-helper: Don't restore if fbdev is not in use
drm/fb-cma-helper: Make struct drm_fbdev_cma public
drm/fb-cma-helper: Support device unplug
drm/tinydrm: Drop driver registered message
drm/tinydrm: Embed drm_device in tinydrm_device
drm/tinydrm: Support device unplug in core
drm/tinydrm/mi0283qt: Let the display pipe handle power
drm/tinydrm: Support device unplug in drivers

   drivers/gpu/drm/drm_drv.c   |  54 +--
   drivers/gpu/drm/drm_fb_cma_helper.c |  13 +--
   drivers/gpu/drm/drm_fb_helper.c | 108 --
   drivers/gpu/drm/tinydrm/core/tinydrm-core.c | 135 
+++-
   drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c |  28 +++---
   drivers/gpu/drm/tinydrm/mi0283qt.c  |  81 +
   drivers/gpu/drm/tinydrm/mipi-dbi.c  |  58 +---
   drivers/gpu/drm/tinydrm/repaper.c   |  62 -
   drivers/gpu/drm/tinydrm/st7586.c|  54 ++-
   include/drm/drm_device.h|   9 +-
   include/drm/drm_drv.h   |  15 +++-
   include/drm/drm_fb_cma_helper.h |  11 ++-
   include/drm/drm_fb_helper.h |  28 ++
   include/drm/tinydrm/mipi-dbi.h  |   1 +
   

[Bug 199139] System freezes (kernel, amdgpu NULL pointer dereference) when video enters powersafe state

[bugzilla-daemon]

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

Harry Wentland (harry.wentl...@amd.com) changed:

   What|Removed |Added

 CC||harry.wentl...@amd.com

--- Comment #3 from Harry Wentland (harry.wentl...@amd.com) ---
Created attachment 274819
  --> https://bugzilla.kernel.org/attachment.cgi?id=274819=edit
0001-drm-amd-display-Don-t-blow-up-if-TG-is-NULL-in-dce11.patch

Does this patch help?

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

Re: [PATCH] libdrm: Use readdir instead of readdir_r to avoid build warnings

[Eric Engestrom]

On Monday, 2018-03-19 06:47:32 -0700, John Stultz wrote:
> Building libdrm under AOSP, we see the following build warning:
> external/libdrm/xf86drm.c:2861:12: warning: 'readdir_r' is deprecated: 
> readdir_r is deprecated; use readdir instead [-Wdeprecated-declarations]
> while (readdir_r(sysdir, pent, ) == 0 && ent != NULL) {
>^
> 
> Thus, this patch replaces readdir_r with readdir.
> 
> Cc: Robert Foss 
> Cc: Rob Herring 
> Cc: Stefan Schake 
> Signed-off-by: John Stultz 
> ---
>  xf86drm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/xf86drm.c b/xf86drm.c
> index 344326d..b9058c2 100644
> --- a/xf86drm.c
> +++ b/xf86drm.c
> @@ -2858,7 +2858,7 @@ static char *drmGetMinorNameForFD(int fd, int type)
>  if (pent == NULL)
>   goto out_close_dir;
>  
> -while (readdir_r(sysdir, pent, ) == 0 && ent != NULL) {
> +while ((ent = readdir(sysdir))) {

I've had the same patch locally for some time, and while this line is
correct, it's missing other changes to clean up unnecessary code around.

I don't have the change on this machine, I'll look at it tonight, but if
you beat me to it, from memory there's a malloc()+free() around, and
a couple unused variables now that should be removed at the start of
the scope.

>  if (strncmp(ent->d_name, name, len) == 0) {
>  snprintf(dev_name, sizeof(dev_name), DRM_DIR_NAME "/%s",
>   ent->d_name);
> -- 
> 2.7.4
> 
> ___
> 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 RESEND v2 1/2] drm/xen-front: Add support for Xen PV display frontend

[Oleksandr Andrushchenko]

On 03/19/2018 03:51 PM, Daniel Vetter wrote:

On Fri, Mar 16, 2018 at 12:52:09PM +0200, Oleksandr Andrushchenko wrote:

Hi, Daniel!
Sorry, if I strip the patch too much below.

On 03/16/2018 10:23 AM, Daniel Vetter wrote:

S-o-b line went missing here :-)

will restore it back ;)

I've read through it, 2 actual review comments (around hot-unplug and
around the error recovery for failed flips), a few bikesheds, but looks
all reasonable to me. And much easier to read as one big patch (it's just
3k).

One more thing I'd do as a follow-up (don't rewrite everything, this is
close to merge, better to get it in first): You have a lot of indirections
and function calls across sources files. That's kinda ok if you have a
huge driver with 100+k lines of code where you have to split things up.
But for a small driver like yours here it's a bit overkill.

will review and try to rework after the driver is in

I'll probably merge xen_drm_front_drv.c and xen_drm_front.c now as
anyway I have to re-work driver unloading, e.g. "fishy" code below.

Personally I'd merge at least the xen backend stuff into the corresponding
kms code, but that's up to you.

I prefer to have it in smaller chunks and all related code at
one place, so it is easier to maintain. That is why I didn't
plumb frontend <-> backend code right into the KMS code.

And as mentioned, if you decide to do
that, a follow-up patch (once this has merged) is perfectly fine.

Ok, after the merge

If you prefer your current layout, then pls keep it. Bikeshed = personal
style nit, feel free to ignore if you like stuff differently. In the end
it's your driver, not mine, and I can easily navigate the current code
(with a few extra jumps).

Some of the indirections will be removed by merging
xen_drm_front_drv.c and xen_drm_front.c. Are these what you
mean or is there anything else?

-Daniel


-Daniel


+int xen_drm_front_dbuf_create_from_sgt(struct xen_drm_front_info *front_info,
+   uint64_t dbuf_cookie, uint32_t width, uint32_t height,
+   uint32_t bpp, uint64_t size, struct sg_table *sgt)
+{
+   return be_dbuf_create_int(front_info, dbuf_cookie, width, height,
+   bpp, size, NULL, sgt);
+}
+
+int xen_drm_front_dbuf_create_from_pages(struct xen_drm_front_info *front_info,
+   uint64_t dbuf_cookie, uint32_t width, uint32_t height,
+   uint32_t bpp, uint64_t size, struct page **pages)
+{
+   return be_dbuf_create_int(front_info, dbuf_cookie, width, height,
+   bpp, size, pages, NULL);
+}

The above two wrappers seem a bit much, just to set sgt = NULL or pages =
NULL in one of them. I'd drop them, but that's a bikeshed so feel free to
ignore.

I had that the way you say in some of the previous implementations,
but finally decided to have these dummy wrappers: seems
to be cleaner this way

+static void displback_disconnect(struct xen_drm_front_info *front_info)
+{
+   bool removed = true;
+
+   if (front_info->drm_pdev) {
+   if (xen_drm_front_drv_is_used(front_info->drm_pdev)) {
+   DRM_WARN("DRM driver still in use, deferring 
removal\n");
+   removed = false;
+   } else
+   xen_drv_remove_internal(front_info);

Ok this logic here is fishy, since you're open-coding the drm unplug
infrastructure, but slightly differently and slightyl racy. If you have a
driver where your underlying "hw" (well it's virtual here, but same idea)
can disappear any time while userspace is still using the drm driver, you
need to use the drm_dev_unplug() function and related code.
drm_dev_unplug() works like drm_dev_unregister, except for the hotplug
case.

Then you also have to guard all the driver entry points where you do
access the backchannel using drm_dev_is_unplugged() (I've seen a few of
those already). Then you can rip out all the logic here and the 
xen_drm_front_drv_is_used() helper.

Will rework it with drm_dev_unplug, thank you

I thought there's some patches from Noralf in-flight that improved the
docs on this, I need to check

Yes, I will definitely use those as soon as they are available.
But at the moment let me clarify a bit on the use-cases for driver
unplugging and backend disconnection.

The backend, by disconnecting, expects full DRM driver teardown, because,
for example, it might need to replace current frontend’s configuration
completely or stop supporting para-virtualized display for some reason.

This means that once I have displback_disconnected callback (on XenBus state
change) I am trying to unregister and remove the DRM driver which seems 
to be
not possible if I have relevant code in DRM callbacks (e.g. I cannot try 
removing

driver from driver's callback).

So, even if I add drm_dev_unplug (which anyway seems to be the right thing)
I’ll have to have that fishy code for XenBus state handling.

These are the unplug/disconnect use-cases we have:

1. Rmmod

1.1. If DRM 

Re: [PATCH] drm: Reduce object size of DRM_DEV_ uses

[Daniel Vetter]

On Fri, Mar 16, 2018 at 01:56:27PM -0700, Joe Perches wrote:
> These macros are similar to the DRM_ with the addition
> of a struct device * to the arguments.
> 
> Convert the single drm_dev_printk function into 2 separate functions.
> drm_dev_printk with a KERN_ * for generic use and drm_dev_dbg
> for conditional masked use.
> 
> Remove the __func__ argument and use __builtin_return_address(0) to be
> similar to the DRM_ macros uses.
> 
> Convert the DRM_DEV_ macros to remove now unnecessary arguments
> and use a consistent style.
> 
> These macros are rarely used in the generic gpu/drm code so the code
> size does not change much for a defconfig, but when more drivers are
> enabled, there is ~4k savings.
> 
> Many of these macros have no existing use at all.
> 
> $ size -t drivers/gpu/drm/built-in.a | tail -1
> 1877530 44651 995 1923176  1d5868 (TOTALS)
> 
> $ size -t drivers/gpu/drm/built-in.a | tail -1
> 1877527 44651 995 1923173  1d5865 (TOTALS)
> 
> $ size -t drivers/gpu/drm/built-in.a | tail -1
> 17166750  2689238  108352 19964340130a1b4 (TOTALS)
> 
> $ size -t drivers/gpu/drm/built-in.a | tail -1
> 1716  2691734  108352 19968974130b3ce (TOTALS)
> 
> Signed-off-by: Joe Perches 

Thanks for the resend, applied.
-Daniel

> ---
>  drivers/gpu/drm/drm_print.c | 37 +-
>  include/drm/drm_print.h | 94 
> ++---
>  2 files changed, 74 insertions(+), 57 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
> index 79abf6d5b4db..b25f98f33f6c 100644
> --- a/drivers/gpu/drm/drm_print.c
> +++ b/drivers/gpu/drm/drm_print.c
> @@ -63,16 +63,34 @@ void drm_printf(struct drm_printer *p, const char *f, ...)
>  }
>  EXPORT_SYMBOL(drm_printf);
>  
> -#define DRM_PRINTK_FMT "[" DRM_NAME ":%s]%s %pV"
> -
>  void drm_dev_printk(const struct device *dev, const char *level,
> - unsigned int category, const char *function_name,
> - const char *prefix, const char *format, ...)
> + const char *format, ...)
> +{
> + struct va_format vaf;
> + va_list args;
> +
> + va_start(args, format);
> + vaf.fmt = format;
> + vaf.va = 
> +
> + if (dev)
> + dev_printk(level, dev, "[" DRM_NAME ":%ps] %pV",
> +__builtin_return_address(0), );
> + else
> + printk("%s" "[" DRM_NAME ":%ps] %pV",
> +level, __builtin_return_address(0), );
> +
> + va_end(args);
> +}
> +EXPORT_SYMBOL(drm_dev_printk);
> +
> +void drm_dev_dbg(const struct device *dev, unsigned int category,
> +  const char *format, ...)
>  {
>   struct va_format vaf;
>   va_list args;
>  
> - if (category != DRM_UT_NONE && !(drm_debug & category))
> + if (!(drm_debug & category))
>   return;
>  
>   va_start(args, format);
> @@ -80,14 +98,15 @@ void drm_dev_printk(const struct device *dev, const char 
> *level,
>   vaf.va = 
>  
>   if (dev)
> - dev_printk(level, dev, DRM_PRINTK_FMT, function_name, prefix,
> -);
> + dev_printk(KERN_DEBUG, dev, "[" DRM_NAME ":%ps] %pV",
> +__builtin_return_address(0), );
>   else
> - printk("%s" DRM_PRINTK_FMT, level, function_name, prefix, );
> + printk(KERN_DEBUG "[" DRM_NAME ":%ps] %pV",
> +__builtin_return_address(0), );
>  
>   va_end(args);
>  }
> -EXPORT_SYMBOL(drm_dev_printk);
> +EXPORT_SYMBOL(drm_dev_dbg);
>  
>  void drm_dbg(unsigned int category, const char *format, ...)
>  {
> diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
> index 3a40c5a3a5fa..e1a46e9991cc 100644
> --- a/include/drm/drm_print.h
> +++ b/include/drm/drm_print.h
> @@ -196,10 +196,13 @@ static inline struct drm_printer 
> drm_debug_printer(const char *prefix)
>  #define DRM_UT_STATE 0x40
>  #define DRM_UT_LEASE 0x80
>  
> -__printf(6, 7)
> +__printf(3, 4)
>  void drm_dev_printk(const struct device *dev, const char *level,
> - unsigned int category, const char *function_name,
> - const char *prefix, const char *format, ...);
> + const char *format, ...);
> +__printf(3, 4)
> +void drm_dev_dbg(const struct device *dev, unsigned int category,
> +  const char *format, ...);
> +
>  __printf(2, 3)
>  void drm_dbg(unsigned int category, const char *format, ...);
>  __printf(1, 2)
> @@ -208,10 +211,7 @@ void drm_err(const char *format, ...);
>  /* Macros to make printk easier */
>  
>  #define _DRM_PRINTK(once, level, fmt, ...)   \
> - do {\
> - printk##once(KERN_##level "[" DRM_NAME "] " fmt,\
> -  ##__VA_ARGS__);\
> - } while (0)
> + 

Re: linux-next: manual merge of the drm-misc tree with the drm tree

[Ville Syrjälä]

On Mon, Mar 19, 2018 at 12:29:29PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the drm-misc tree got a conflict in:
> 
>   drivers/gpu/drm/i915/intel_color.c
> 
> between commit:
> 
>   db61d160b3ed ("drm/i915: Remove the pointless 1:1 matrix copy")
> 
> from the drm tree and commit:
> 
>   d5517a39dce4 ("drm/i915: Remove the blob->data casts")
> 
> from the drm-misc tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc drivers/gpu/drm/i915/intel_color.c
> index 89ab0f70aa22,768f1c26080e..
> --- a/drivers/gpu/drm/i915/intel_color.c
> +++ b/drivers/gpu/drm/i915/intel_color.c
> @@@ -140,28 -140,20 +140,27 @@@ static void ilk_load_csc_matrix(struct 
>   int i, pipe = intel_crtc->pipe;
>   uint16_t coeffs[9] = { 0, };
>   struct intel_crtc_state *intel_crtc_state = 
> to_intel_crtc_state(crtc_state);
>  +bool limited_color_range = false;
>  +
>  +/*
>  + * FIXME if there's a gamma LUT after the CSC, we should
>  + * do the range compression using the gamma LUT instead.
>  + */
>  +if (INTEL_GEN(dev_priv) >= 8 || IS_HASWELL(dev_priv))
>  +limited_color_range = intel_crtc_state->limited_color_range;
>   
>   if (intel_crtc_state->ycbcr420) {
>  -i9xx_load_ycbcr_conversion_matrix(intel_crtc);
>  +ilk_load_ycbcr_conversion_matrix(intel_crtc);
>   return;
>   } else if (crtc_state->ctm) {
> - struct drm_color_ctm *ctm =
> - (struct drm_color_ctm *)crtc_state->ctm->data;
> + struct drm_color_ctm *ctm = crtc_state->ctm->data;
>  -uint64_t input[9] = { 0, };
>  +const u64 *input;
>  +u64 temp[9];

Yep. Looks correct.

>   
>  -if (intel_crtc_state->limited_color_range) {
>  -ctm_mult_by_limited(input, ctm->matrix);
>  -} else {
>  -for (i = 0; i < ARRAY_SIZE(input); i++)
>  -input[i] = ctm->matrix[i];
>  -}
>  +if (limited_color_range)
>  +input = ctm_mult_by_limited(temp, ctm->matrix);
>  +else
>  +input = ctm->matrix;
>   
>   /*
>* Convert fixed point S31.32 input to format supported by the

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

Re: [Outreachy kernel] [PATCH DRM] drm: remove drm_mode_object_{un/reference} aliases

[Daniel Vetter]

On Mon, Mar 19, 2018 at 01:58:20AM -0400, Haneen Mohammed wrote:
> This patch remove the compatibility aliases
> drm_mode_object_{reference/unreference} of drm_mode_object_{get/put}
> since all callers have been converted to the prefered _{get/put}.
> 
> Remove the helpers from the semantic patch drm-get-put-cocci.
> 
> Signed-off-by: Haneen Mohammed 

Yay, one set down, a few more to go!

Thanks for taking care of this.
-Daniel

> ---
>  include/drm/drm_mode_object.h| 24 
>  scripts/coccinelle/api/drm-get-put.cocci | 10 --
>  2 files changed, 34 deletions(-)
> 
> diff --git a/include/drm/drm_mode_object.h b/include/drm/drm_mode_object.h
> index 7ba3913..c34a3e8 100644
> --- a/include/drm/drm_mode_object.h
> +++ b/include/drm/drm_mode_object.h
> @@ -120,30 +120,6 @@ struct drm_mode_object *drm_mode_object_find(struct 
> drm_device *dev,
>  void drm_mode_object_get(struct drm_mode_object *obj);
>  void drm_mode_object_put(struct drm_mode_object *obj);
>  
> -/**
> - * drm_mode_object_reference - acquire a mode object reference
> - * @obj: DRM mode object
> - *
> - * This is a compatibility alias for drm_mode_object_get() and should not be
> - * used by new code.
> - */
> -static inline void drm_mode_object_reference(struct drm_mode_object *obj)
> -{
> - drm_mode_object_get(obj);
> -}
> -
> -/**
> - * drm_mode_object_unreference - release a mode object reference
> - * @obj: DRM mode object
> - *
> - * This is a compatibility alias for drm_mode_object_put() and should not be
> - * used by new code.
> - */
> -static inline void drm_mode_object_unreference(struct drm_mode_object *obj)
> -{
> - drm_mode_object_put(obj);
> -}
> -
>  int drm_object_property_set_value(struct drm_mode_object *obj,
> struct drm_property *property,
> uint64_t val);
> diff --git a/scripts/coccinelle/api/drm-get-put.cocci 
> b/scripts/coccinelle/api/drm-get-put.cocci
> index 91fceb8..ceb71ea 100644
> --- a/scripts/coccinelle/api/drm-get-put.cocci
> +++ b/scripts/coccinelle/api/drm-get-put.cocci
> @@ -16,12 +16,6 @@ expression object;
>  @@
>  
>  (
> -- drm_mode_object_reference(object)
> -+ drm_mode_object_get(object)
> -|
> -- drm_mode_object_unreference(object)
> -+ drm_mode_object_put(object)
> -|
>  - drm_connector_reference(object)
>  + drm_connector_get(object)
>  |
> @@ -62,10 +56,6 @@ position p;
>  @@
>  
>  (
> -drm_mode_object_unreference@p(object)
> -|
> -drm_mode_object_reference@p(object)
> -|
>  drm_connector_unreference@p(object)
>  |
>  drm_connector_reference@p(object)
> -- 
> 2.7.4
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/outreachy-kernel/20180319055820.GA17502%40haneen-VirtualBox.
> For more options, visit https://groups.google.com/d/optout.

-- 
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: [Outreachy kernel] [PATCH] gpu: drm: Use list_{next/prev}_entry instead of list_entry

[Daniel Vetter]

On Mon, Mar 19, 2018 at 10:35:30AM +0530, Arushi Singhal wrote:
> This patch replace list_entry with list_{next/prev}_entry as it makes
> the code more clear to read.
> Done using coccinelle:
> 
> @@
> expression e1;
> identifier e3;
> type t;
> @@
> (
> - list_entry(e1->e3.next,t,e3)
> + list_next_entry(e1,e3)
> |
> - list_entry(e1->e3.prev,t,e3)
> + list_prev_entry(e1,e3)
> )
> 
> Signed-off-by: Arushi Singhal 

Thanks for your patch. Looks correct, but for merge technical reasons can
you please split it into 2 patches? One for drm_lease.c, with a drm/lease:
prefix, and one for the nouveau driver change, with a nouveau: prefix.
Both patches need to be submitted to slightly different sets of
maintainers too, pls consult scripts/get_maintainers.pl

Thanks, Daniel

> ---
>  drivers/gpu/drm/drm_lease.c| 2 +-
>  drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lease.c
> index 1402c0e..4dcfb5f 100644
> --- a/drivers/gpu/drm/drm_lease.c
> +++ b/drivers/gpu/drm/drm_lease.c
> @@ -340,7 +340,7 @@ static void _drm_lease_revoke(struct drm_master *top)
>   break;
>  
>   /* Over */
> - master = list_entry(master->lessee_list.next, struct 
> drm_master, lessee_list);
> + master = list_next_entry(master, lessee_list);
>   }
>   }
>  }
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c 
> b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c
> index e4c8d31..81c3567 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c
> @@ -134,7 +134,7 @@ nvkm_cstate_find_best(struct nvkm_clk *clk, struct 
> nvkm_pstate *pstate,
>  nvkm_volt_map(volt, volt->max2_id, clk->temp));
>  
>   for (cstate = start; >head != >list;
> -  cstate = list_entry(cstate->head.prev, typeof(*cstate), head)) {
> +  cstate = list_prev_entry(cstate, head)) {
>   if (nvkm_cstate_valid(clk, cstate, max_volt, clk->temp))
>   break;
>   }
> -- 
> 2.7.4
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/outreachy-kernel/20180319050530.GA25589%40seema-Inspiron-15-3567.
> For more options, visit https://groups.google.com/d/optout.

-- 
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] libdrm: Use readdir instead of readdir_r to avoid build warnings

[Emil Velikov]

On 19 March 2018 at 13:47, John Stultz  wrote:
> Building libdrm under AOSP, we see the following build warning:
> external/libdrm/xf86drm.c:2861:12: warning: 'readdir_r' is deprecated: 
> readdir_r is deprecated; use readdir instead [-Wdeprecated-declarations]
> while (readdir_r(sysdir, pent, ) == 0 && ent != NULL) {
>^
>
> Thus, this patch replaces readdir_r with readdir.
>
When C runtime suggests new behaviour before the manual/spec is updated... sigh.

readdir(3)
It is expected that a future version of POSIX.1 will require that
readdir() be thread-safe when concurrently employed on different
directory streams

readdir_r(3)
It is expected that a future version of POSIX.1 will make readdir_r()
obsolete, and require that readdir(3) be thread-safe when concurrently
employed on different directory streams.


Regardless, patch is
Reviewed-by: Emil Velikov 

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

[Bug 105534] amdgpu cannot set 2560x1440@60 mode even though monitor,gpu and motherboard support it

[bugzilla-daemon]

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

--- Comment #8 from Harry Wentland  ---
(In reply to philipmorant from comment #4)
> I understand if AMD object to coding for something that hasn't been
> validated (I'd do the same myself).  Would it be possible alternatively to
> provide hints in log output or code comments or on a wiki somewhere, such
> that people in my position can hack the source themselves ?

The easiest way to hack this is probably to double TMDS_MAX_PIXEL_CLOCK in
amd/display/include/signal_types.h from 165000 to 33.

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

Re: [PATCH 2/3] drm/vc4: Add color transformation matrix (CTM) support

[Ville Syrjälä]

On Fri, Mar 16, 2018 at 10:50:58PM +0100, Stefan Schake wrote:
> The hardware supports a CTM with S0.9 values. We therefore only allow
> a value of 1.0 or fractional only and reject all others with integer
> parts. This restriction is mostly inconsequential in practice since
> commonly used transformation matrices have all scalars <= 1.0.
> 
> Signed-off-by: Stefan Schake 
> ---
>  drivers/gpu/drm/vc4/vc4_crtc.c | 99 
> --
>  1 file changed, 96 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
> index 8d71098..5c83fd2 100644
> --- a/drivers/gpu/drm/vc4/vc4_crtc.c
> +++ b/drivers/gpu/drm/vc4/vc4_crtc.c
> @@ -315,6 +315,81 @@ vc4_crtc_update_gamma_lut(struct drm_crtc *crtc)
>   vc4_crtc_lut_load(crtc);
>  }
>  
> +/* Converts a DRM S31.32 value to the HW S0.9 format. */
> +static u16 vc4_crtc_s31_32_to_s0_9(u64 in)
> +{
> + u16 r;
> +
> + /* Sign bit. */
> + r = in & BIT_ULL(63) ? BIT(9) : 0;
> + /* We have zero integer bits so we can only saturate here. */
> + if ((in & GENMASK_ULL(62, 32)) > 0)
> + r |= GENMASK(8, 0);
> + /* Otherwise take the 9 most important fractional bits. */
> + else
> + r |= (in >> 22) & GENMASK(8, 0);
> + return r;
> +}
> +
> +static void
> +vc4_crtc_update_ctm(struct drm_crtc *crtc)
> +{
> + struct drm_device *dev = crtc->dev;
> + struct vc4_dev *vc4 = to_vc4_dev(dev);
> + struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
> + struct drm_color_ctm *ctm = crtc->state->ctm->data;
> +
> + HVS_WRITE(SCALER_OLEDCOEF2,
> +   VC4_SET_FIELD(vc4_crtc_s31_32_to_s0_9(ctm->matrix[0]),
> + SCALER_OLEDCOEF2_R_TO_R) |
> +   VC4_SET_FIELD(vc4_crtc_s31_32_to_s0_9(ctm->matrix[3]),
> + SCALER_OLEDCOEF2_R_TO_G) |
> +   VC4_SET_FIELD(vc4_crtc_s31_32_to_s0_9(ctm->matrix[6]),
> + SCALER_OLEDCOEF2_R_TO_B));
> + HVS_WRITE(SCALER_OLEDCOEF1,
> +   VC4_SET_FIELD(vc4_crtc_s31_32_to_s0_9(ctm->matrix[1]),
> + SCALER_OLEDCOEF1_G_TO_R) |
> +   VC4_SET_FIELD(vc4_crtc_s31_32_to_s0_9(ctm->matrix[4]),
> + SCALER_OLEDCOEF1_G_TO_G) |
> +   VC4_SET_FIELD(vc4_crtc_s31_32_to_s0_9(ctm->matrix[7]),
> + SCALER_OLEDCOEF1_G_TO_B));
> + HVS_WRITE(SCALER_OLEDCOEF0,
> +   VC4_SET_FIELD(vc4_crtc_s31_32_to_s0_9(ctm->matrix[2]),
> + SCALER_OLEDCOEF0_B_TO_R) |
> +   VC4_SET_FIELD(vc4_crtc_s31_32_to_s0_9(ctm->matrix[5]),
> + SCALER_OLEDCOEF0_B_TO_G) |
> +   VC4_SET_FIELD(vc4_crtc_s31_32_to_s0_9(ctm->matrix[8]),
> + SCALER_OLEDCOEF0_B_TO_B));
> +
> + /* Channel is 0-based but for DISPFIFO, 0 means disabled. */
> + HVS_WRITE(SCALER_OLEDOFFS, VC4_SET_FIELD(vc4_crtc->channel + 1,
> +  SCALER_OLEDOFFS_DISPFIFO));
> +}
> +
> +/* Check if the CTM contains valid input.
> + *
> + * DRM exposes CTM with S31.32 scalars, but the HW only supports S0.9.
> + * We don't allow integer values >1, and 1 only without fractional part
> + * to handle the common 1.0 value.
> + */
> +static int vc4_crtc_atomic_check_ctm(struct drm_crtc_state *state)
> +{
> + struct drm_color_ctm *ctm = state->ctm->data;
> + u32 i;
> +
> + for (i = 0; i < ARRAY_SIZE(ctm->matrix); i++) {
> + u64 val = ctm->matrix[i];
> +
> + val &= ~BIT_ULL(63);
> + if ((val >> 32) > 1)
> + return -EINVAL;
> + if ((val >> 32) == 1 && (val & GENMASK_ULL(31, 0)) != 0)
> + return -EINVAL;

'val > BIT_ULL(32)' ?

> + }
> +
> + return 0;
> +}
> +
>  static u32 vc4_get_fifo_full_level(u32 format)
>  {
>   static const u32 fifo_len_bytes = 64;
> @@ -621,6 +696,15 @@ static int vc4_crtc_atomic_check(struct drm_crtc *crtc,
>   if (hweight32(state->connector_mask) > 1)
>   return -EINVAL;
>  
> + if (state->ctm) {
> + /* The CTM hardware has no integer bits, so we check
> +  * and reject scalars >1.0 that we have no chance of
> +  * approximating.
> +  */
> + if (vc4_crtc_atomic_check_ctm(state))
> + return -EINVAL;
> + }
> +
>   drm_atomic_crtc_state_for_each_plane_state(plane, plane_state, state)
>   dlist_count += vc4_plane_dlist_size(plane_state);
>  
> @@ -697,8 +781,17 @@ static void vc4_crtc_atomic_flush(struct drm_crtc *crtc,
>   if (crtc->state->active && old_state->active)
>   vc4_crtc_update_dlist(crtc);
>  
> - if (crtc->state->color_mgmt_changed && crtc->state->gamma_lut)
> - vc4_crtc_update_gamma_lut(crtc);
> + if 

Re: RFC: unpinned DMA-buf exporting v2

[Daniel Vetter]

On Fri, Mar 16, 2018 at 02:20:44PM +0100, Christian König wrote:
> Hi everybody,
> 
> since I've got positive feedback from Daniel I continued working on this 
> approach.
> 
> A few issues are still open:
> 1. Daniel suggested that I make the invalidate_mappings callback a parameter 
> of dma_buf_attach().
> 
> This approach unfortunately won't work because when the attachment is
> created the importer is not necessarily ready to handle invalidation
> events.

Why do you have this constraint? This sounds a bit like inverted
create/teardown sequence troubles, where you make an object "life" before
the thing is fully set up.

Can't we fix this by creating the entire ttm scaffolding you'll need for a
dma-buf upfront, and only once you have everything we grab the dma_buf
attachment? At that point you really should be able to evict buffers
again.

Not requiring invalidate_mapping to be set together with the attachment
means we can't ever require importers to support it (e.g. to address your
concern with the userspace dma-buf userptr magic).

> E.g. in the amdgpu example we first need to setup the imported GEM/TMM
> objects and install that in the attachment.
> 
> My solution is to introduce a separate function to grab the locks and
> set the callback, this function could then be used to pin the buffer
> later on if that turns out to be necessary after all.
> 
> 2. With my example setup this currently results in a ping/pong situation
> because the exporter prefers a VRAM placement while the importer prefers
> a GTT placement.
> 
> This results in quite a performance drop, but can be fixed by a simple
> mesa patch which allows shred BOs to be placed in both VRAM and GTT.
> 
> Question is what should we do in the meantime? Accept the performance
> drop or only allow unpinned sharing with new Mesa?

Maybe the exporter should not try to move stuff back into VRAM as long as
there's an active dma-buf? I mean it's really cool that it works, but
maybe let's just do this for a tech demo :-)

Of course if it then runs out of TT then it could still try to move it
back in. And "let's not move it when it's imported" is probably too stupid
too, and will need to be improved again with more heuristics, but would at
least get it off the ground.

Long term you might want to move perhaps once per 10 seconds or so, to get
idle importers to detach. Adjust 10s to match whatever benchmark/workload
you care about.
-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 1/5] dma-buf: add optional invalidate_mappings callback v2

[Daniel Vetter]

On Fri, Mar 16, 2018 at 02:20:45PM +0100, Christian König wrote:
> Each importer can now provide an invalidate_mappings callback.
> 
> This allows the exporter to provide the mappings without the need to pin
> the backing store.
> 
> v2: don't try to invalidate mappings when the callback is NULL,
> lock the reservation obj while using the attachments,
> add helper to set the callback
> 
> Signed-off-by: Christian König 

Replying here to avoid thread split, but not entirely related.

I thought some more about the lockdep splat discussion, and specifically
that amdgpu needs the reservations for the vm objects when doing a gpu
reset.

Since they're in the same ww_class as all other dma-buf reservations I'm
pretty sure lockdep will complain, at least when cross-release lockdep and
cross-release annotations for dma_fence are merged.

And as long as there's some case where amdgpu needs both the vm object
reservation and other reservations (CS?) then we must have them in the
same class, and in that case the deadlock is real. It'll require an
impressive set of circumstances most likely (the minimal number of threads
we generally needed to actually hit the cross-release stuff was 4+ or
something nuts like that, all doing something else), but it'll be real.

Otoh I think the invalidate stuff here doesn't actually make this worse,
so we can bang our heads against the gpu reset problem at leisure :-)

This stuff here has much more potential to interact badly with core mm
paths, and anything related to that (which ime also means all the cpu
hotplug machinery, which includes suspend/resume, and anything related to
the vfs because someone always manages to drag sysfs into the picture).

It's going to be fun times.

Cheers, Daniel
> ---
>  drivers/dma-buf/dma-buf.c | 60 
> +++
>  include/linux/dma-buf.h   | 38 ++
>  2 files changed, 98 insertions(+)
> 
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index d78d5fc173dc..ed2b3559ba25 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -572,7 +572,9 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf 
> *dmabuf,
>   if (ret)
>   goto err_attach;
>   }
> + reservation_object_lock(dmabuf->resv, NULL);
>   list_add(>node, >attachments);
> + reservation_object_unlock(dmabuf->resv);
>  
>   mutex_unlock(>lock);
>   return attach;
> @@ -598,7 +600,9 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct 
> dma_buf_attachment *attach)
>   return;
>  
>   mutex_lock(>lock);
> + reservation_object_lock(dmabuf->resv, NULL);
>   list_del(>node);
> + reservation_object_unlock(dmabuf->resv);
>   if (dmabuf->ops->detach)
>   dmabuf->ops->detach(dmabuf, attach);
>  
> @@ -632,10 +636,23 @@ struct sg_table *dma_buf_map_attachment(struct 
> dma_buf_attachment *attach,
>   if (WARN_ON(!attach || !attach->dmabuf))
>   return ERR_PTR(-EINVAL);
>  
> + /*
> +  * Mapping a DMA-buf can trigger its invalidation, prevent sending this
> +  * event to the caller by temporary removing this attachment from the
> +  * list.
> +  */
> + if (attach->invalidate_mappings) {
> + reservation_object_assert_held(attach->dmabuf->resv);
> + list_del(>node);
> + }
> +
>   sg_table = attach->dmabuf->ops->map_dma_buf(attach, direction);
>   if (!sg_table)
>   sg_table = ERR_PTR(-ENOMEM);
>  
> + if (attach->invalidate_mappings)
> + list_add(>node, >dmabuf->attachments);
> +
>   return sg_table;
>  }
>  EXPORT_SYMBOL_GPL(dma_buf_map_attachment);
> @@ -656,6 +673,9 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment 
> *attach,
>  {
>   might_sleep();
>  
> + if (attach->invalidate_mappings)
> + reservation_object_assert_held(attach->dmabuf->resv);
> +
>   if (WARN_ON(!attach || !attach->dmabuf || !sg_table))
>   return;
>  
> @@ -664,6 +684,44 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment 
> *attach,
>  }
>  EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment);
>  
> +/**
> + * dma_buf_set_invalidate_callback - set the invalidate_mappings callback
> + *
> + * @attach:  [in]attachment where to set the callback
> + * @cb:  [in]the callback to set
> + *
> + * Makes sure to take the appropriate locks when updating the invalidate
> + * mappings callback.
> + */
> +void dma_buf_set_invalidate_callback(struct dma_buf_attachment *attach,
> +  void (*cb)(struct dma_buf_attachment *))
> +{
> + reservation_object_lock(attach->dmabuf->resv, NULL);
> + attach->invalidate_mappings = cb;
> + reservation_object_unlock(attach->dmabuf->resv);
> +}
> +EXPORT_SYMBOL_GPL(dma_buf_set_invalidate_callback);
> +
> +/**
> + * dma_buf_invalidate_mappings - invalidate 

Re: [DPU PATCH 2/2] drm/msm: Add hardware catalog file for SDM845

[Sean Paul]

On Wed, Mar 14, 2018 at 11:21:38AM +0530, Sravanthi Kollukuduru wrote:
> This change adds the hardware catalog information in driver source
> for SDM845. This removes the current logic of dt based parsing
> of target catalog information.
> 
> Signed-off-by: Sravanthi Kollukuduru 
> ---
>  drivers/gpu/drm/msm/Makefile   |1 +
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 3071 
> +---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h |   17 +-
>  .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog_sdm845.c  |  744 +
>  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c|2 +-
>  5 files changed, 767 insertions(+), 3068 deletions(-)

Hi Sravanthi,
Thank you for the patch, it's great to see diffstats like this :)



> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog_sdm845.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog_sdm845.c
> new file mode 100644
> index 000..3ca5dc7
> --- /dev/null
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog_sdm845.c
> @@ -0,0 +1,744 @@
> +/* Copyright (c) 2018, The Linux Foundation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.

We should be using SPDX license tags from now on.

> + */
> +
> +#include "dpu_hw_catalog.h"
> +#include "dpu_hw_catalog_format.h"
> +#include "dpu_hw_mdss.h"
> +#include "dpu_hwio.h"
> +
> +/* VIG layer capability */
> +#define VIG_40X_MASK \
> + (BIT(DPU_SSPP_SRC) | BIT(DPU_SSPP_SCALER_QSEED3) | BIT(DPU_SSPP_QOS) |\
> + BIT(DPU_SSPP_CSC_10BIT) | BIT(DPU_SSPP_CDP) | BIT(DPU_SSPP_QOS_8LVL) |\
> + BIT(DPU_SSPP_TS_PREFILL) | BIT(DPU_SSPP_EXCL_RECT))
> +
> +/* DMA layer capability */
> +#define DMA_40X_MASK \
> + (BIT(DPU_SSPP_SRC) | BIT(DPU_SSPP_QOS) | BIT(DPU_SSPP_QOS_8LVL) |\
> + BIT(DPU_SSPP_TS_PREFILL) | BIT(DPU_SSPP_CDP) | BIT(DPU_SSPP_EXCL_RECT))
> +
> +#define MIXER_40X_MASK \
> + (BIT(DPU_MIXER_SOURCESPLIT) | BIT(DPU_DIM_LAYER))
> +
> +#define DSPP_40X_MASK \
> + (BIT(DPU_DSPP_IGC) | BIT(DPU_DSPP_PCC) | BIT(DPU_DSPP_GC) |\
> + BIT(DPU_DSPP_HSIC) | BIT(DPU_DSPP_GAMUT) | BIT(DPU_DSPP_HIST) |\
> + BIT(DPU_DSPP_MEMCOLOR) | BIT(DPU_DSPP_SIXZONE) | BIT(DPU_DSPP_VLUT))
> +
> +#define DSPP_AD_40X_MASK \
> + (DSPP_40X_MASK | BIT(DPU_DSPP_AD))
> +
> +#define PINGPONG_40X_MASK BIT(DPU_PINGPONG_DITHER)
> +
> +#define PINGPONG_40X_SPLIT_MASK \
> + (PINGPONG_40X_MASK | BIT(DPU_PINGPONG_SPLIT) | BIT(DPU_PINGPONG_TE2))
> +
> +#define WB2_40X_MASK \
> + (BIT(DPU_WB_LINE_MODE) | BIT(DPU_WB_TRAFFIC_SHAPER) | BIT(DPU_WB_CDP) |\
> + BIT(DPU_WB_YUV_CONFIG) | BIT(DPU_WB_QOS_8LVL) | BIT(DPU_WB_UBWC))
> +
> +#define DECIMATION_40X_MAX_H 4
> +#define DECIMATION_40X_MAX_V 4
> +
> +/*
> + * set_cfg_xxx_init(): populate dpu sub-blocks reg offsets
> + * and instance counts.
> + */
> +static inline int set_cfg_40X_init(struct dpu_mdss_cfg *dpu_cfg)
> +{
> + /* Layer capability */
> + static const struct dpu_sspp_sub_blks vig_sblk_0 = {
> + .maxlinewidth = 2560,
> + .pixel_ram_size = 50 * 1024,
> + .maxdwnscale = 4,
> + .maxupscale = 20,
> + .maxhdeciexp = DECIMATION_40X_MAX_H,
> + .maxvdeciexp = DECIMATION_40X_MAX_V,
> + .smart_dma_priority = 5,
> + .src_blk = {.name = "sspp_src_0", .id = DPU_SSPP_SRC,
> + .base = 0x00, .len = 0x150,},
> + .scaler_blk = {.name = "sspp_scaler0",
> + .id = DPU_SSPP_SCALER_QSEED3,
> + .base = 0xa00, .len = 0xa0,},
> + .csc_blk = {.name = "sspp_csc0", .id = DPU_SSPP_CSC_10BIT,
> + .base = 0x1a00, .len = 0x100,},
> + .format_list = plane_formats_yuv,
> + .virt_format_list = plane_formats,
> + };

Instead of locating all of these parameters in one file, these should be
located in their respective driver file. It also seems like you could separate
out the common stuff such as line width, ram size, scaling, format, etc
parameters from the pipeline setup.

The same comments apply to the other blocks. Move things into the drivers,
use compatibility string to determine the version, and then associate the common
parameters with of_device_id.data.

Sean


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

Re: [Intel-gfx] [PATCH libdrm 0/5] improve reuse implementation

[Daniel Vetter]

On Fri, Mar 16, 2018 at 05:10:44PM +, Emil Velikov wrote:
> On 16 March 2018 at 08:43, Daniel Vetter  wrote:
> > On Thu, Mar 15, 2018 at 06:20:09PM -0700, James Xiong wrote:
> >> From: "Xiong, James" 
> >>
> >> With gem_reuse enabled, when a buffer size is different than
> >> the sizes of buckets, it is aligned to the next bucket's size,
> >> which means about 25% more memory than the requested is allocated
> >> in the worst senario. For example:
> >>
> >> Orignal sizeActual
> >> 32KB+1Byte  40KB
> >> .
> >> .
> >> .
> >> 8MB+1Byte   10MB
> >> .
> >> .
> >> .
> >> 96MB+1Byte  112MB
> >>
> >> This is very memory expensive and make the reuse feature less
> >> favorable than it deserves to be.
> >>
> >> This series aligns the reuse buffer size on page size instead to
> >> save memory. Performed gfxbench tests on Gen9 without LLC, the
> >> performances and reuse ratioes (reuse count/allocation count) were
> >> same as before, saved memory usage by 1% ~ 7%(gl_manhattan: peak
> >> allocated memory size was reduced from 448401408 to 419078144).
> >>
> >> v2: split the patch to a series of small functional changes (Chris)
> >
> > Mesa gen driver stopped using the libdrm buffer allocator. The gen2/3
> > driver still uses it, but I think that's not the one you benchmarked. The
> > 17.1 release was the first one with that change.
> >
> > I think you want to port your changes over to mesa to future proof it,
> > merging this to upstream makes little sense.
> 
> Perhaps it can have in both? After all i915, libva and beignet still
> make use of libdrm_intel.
> The Mesa copy has changed drastically so this series might need serious 
> rework.

Yeah, we can have both, but then the series needs to be updated to have
relative improvements for the stacks still using libdrm. Apparently our
new media stack has it's own copy of libdrm (like everyone else nowadays),
so fairly limited. But I think the platform this was done for is still
using the older libva, so would benefit.

Just want to make sure the commit justification reflects actual upstream
reality instead of what we had 2 years ago.
-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

[Bug 198123] Console is the wrong color at boot with radeon 6670

[bugzilla-daemon]

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

--- Comment #46 from Harry Wentland (harry.wentl...@amd.com) ---
Michel, nobody jumps out to me in dce5_crtc_load_lut but I have only cursory
familiary with those registers.

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

Re: [PATCH] drm: Reduce object size of DRM_ERROR and DRM_DEBUG uses

[Daniel Vetter]

On Fri, Mar 16, 2018 at 05:29:02AM -0700, Joe Perches wrote:
> On Fri, 2018-03-16 at 08:41 +0100, Daniel Vetter wrote:
> > On Tue, Mar 13, 2018 at 03:02:15PM -0700, Joe Perches wrote:
> > > drm_printk is used for both DRM_ERROR and DRM_DEBUG with unnecessary
> > > arguments that can be removed by creating separate functins.
> > > 
> > > Create specific functions for these calls to reduce x86/64 defconfig
> > > size by ~20k.
> > > 
> > > Modify the existing macros to use the specific calls.
> > > 
> > > new:
> > > $ size -t drivers/gpu/drm/built-in.a | tail -1
> > > 1876562 44542 995 1922099  1d5433 (TOTALS)
> > > 
> > > old:
> > > $ size -t drivers/gpu/drm/built-in.a | tail -1
> > > 1897565 44542 995 1943102  1da63e (TOTALS)
> > > 
> > > Miscellanea:
> > > 
> > > o intel_display requires a change to use the specific calls.
> > > 
> > > Signed-off-by: Joe Perches 
> > 
> > Impressed with the size of the bikeshed piled on top of this I decided to
> > cut this all short by merging it.
> 
> Thanks.
> 
> There was a similar patch for the DRM_DEV_ macros
> awhile ago that also reduced object code.
> 
> https://lkml.org/lkml/2017/9/25/247
> 
> Never applied.
> 
> Want a remerge resend?

Yeah dropped out of my inbox, resending is easier. Please do so.

In case you wonder, I try to fairly intentionally drop stuff on the floor,
to force other people on dri-devel to not load everything onto me, making
me a bottleneck. But then occasionally a patch drops through all nets
because tracking mailing lists is impossible :-/
-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 RESEND v2 1/2] drm/xen-front: Add support for Xen PV display frontend

[Daniel Vetter]

On Fri, Mar 16, 2018 at 12:52:09PM +0200, Oleksandr Andrushchenko wrote:
> Hi, Daniel!
> Sorry, if I strip the patch too much below.
> 
> On 03/16/2018 10:23 AM, Daniel Vetter wrote:
> > 
> > S-o-b line went missing here :-)
> will restore it back ;)
> > 
> > I've read through it, 2 actual review comments (around hot-unplug and
> > around the error recovery for failed flips), a few bikesheds, but looks
> > all reasonable to me. And much easier to read as one big patch (it's just
> > 3k).
> > 
> > One more thing I'd do as a follow-up (don't rewrite everything, this is
> > close to merge, better to get it in first): You have a lot of indirections
> > and function calls across sources files. That's kinda ok if you have a
> > huge driver with 100+k lines of code where you have to split things up.
> > But for a small driver like yours here it's a bit overkill.
> will review and try to rework after the driver is in
> > 
> > Personally I'd merge at least the xen backend stuff into the corresponding
> > kms code, but that's up to you.
> I prefer to have it in smaller chunks and all related code at
> one place, so it is easier to maintain. That is why I didn't
> plumb frontend <-> backend code right into the KMS code.
> > And as mentioned, if you decide to do
> > that, a follow-up patch (once this has merged) is perfectly fine.
> Ok, after the merge

If you prefer your current layout, then pls keep it. Bikeshed = personal
style nit, feel free to ignore if you like stuff differently. In the end
it's your driver, not mine, and I can easily navigate the current code
(with a few extra jumps).
-Daniel

> > -Daniel
> > 
> > > +int xen_drm_front_dbuf_create_from_sgt(struct xen_drm_front_info 
> > > *front_info,
> > > + uint64_t dbuf_cookie, uint32_t width, uint32_t height,
> > > + uint32_t bpp, uint64_t size, struct sg_table *sgt)
> > > +{
> > > + return be_dbuf_create_int(front_info, dbuf_cookie, width, height,
> > > + bpp, size, NULL, sgt);
> > > +}
> > > +
> > > +int xen_drm_front_dbuf_create_from_pages(struct xen_drm_front_info 
> > > *front_info,
> > > + uint64_t dbuf_cookie, uint32_t width, uint32_t height,
> > > + uint32_t bpp, uint64_t size, struct page **pages)
> > > +{
> > > + return be_dbuf_create_int(front_info, dbuf_cookie, width, height,
> > > + bpp, size, pages, NULL);
> > > +}
> > The above two wrappers seem a bit much, just to set sgt = NULL or pages =
> > NULL in one of them. I'd drop them, but that's a bikeshed so feel free to
> > ignore.
> I had that the way you say in some of the previous implementations,
> but finally decided to have these dummy wrappers: seems
> to be cleaner this way
> > > +static void displback_disconnect(struct xen_drm_front_info *front_info)
> > > +{
> > > + bool removed = true;
> > > +
> > > + if (front_info->drm_pdev) {
> > > + if (xen_drm_front_drv_is_used(front_info->drm_pdev)) {
> > > + DRM_WARN("DRM driver still in use, deferring 
> > > removal\n");
> > > + removed = false;
> > > + } else
> > > + xen_drv_remove_internal(front_info);
> > Ok this logic here is fishy, since you're open-coding the drm unplug
> > infrastructure, but slightly differently and slightyl racy. If you have a
> > driver where your underlying "hw" (well it's virtual here, but same idea)
> > can disappear any time while userspace is still using the drm driver, you
> > need to use the drm_dev_unplug() function and related code.
> > drm_dev_unplug() works like drm_dev_unregister, except for the hotplug
> > case.
> > 
> > Then you also have to guard all the driver entry points where you do
> > access the backchannel using drm_dev_is_unplugged() (I've seen a few of
> > those already). Then you can rip out all the logic here and the 
> > xen_drm_front_drv_is_used() helper.
> Will rework it with drm_dev_unplug, thank you
> > I thought there's some patches from Noralf in-flight that improved the
> > docs on this, I need to check
> > 
> > > +#define XEN_DRM_NUM_VIDEO_MODES  1
> > > +#define XEN_DRM_CRTC_VREFRESH_HZ 60
> > > +
> > > +static int connector_get_modes(struct drm_connector *connector)
> > > +{
> > > + struct xen_drm_front_drm_pipeline *pipeline =
> > > + to_xen_drm_pipeline(connector);
> > > + struct drm_display_mode *mode;
> > > + struct videomode videomode;
> > > + int width, height;
> > > +
> > > + mode = drm_mode_create(connector->dev);
> > > + if (!mode)
> > > + return 0;
> > > +
> > > + memset(, 0, sizeof(videomode));
> > > + videomode.hactive = pipeline->width;
> > > + videomode.vactive = pipeline->height;
> > > + width = videomode.hactive + videomode.hfront_porch +
> > > + videomode.hback_porch + videomode.hsync_len;
> > > + height = videomode.vactive + videomode.vfront_porch +
> > > + videomode.vback_porch + videomode.vsync_len;
> > > + videomode.pixelclock = width * height * XEN_DRM_CRTC_VREFRESH_HZ;

Re: [PATCH v1] drm/dp/mst: Fix off-by-one typo when dump payload table

[Daniel Vetter]

On Thu, Jan 11, 2018 at 05:33:03PM +0200, Andy Shevchenko wrote:
> It seems there is a classical off-by-one typo from the beginning
> when commit
> 
>   ad7f8a1f9ced ("drm/helper: add Displayport multi-stream helper (v0.6)")
> 
> introduced a new helper.
> 
> Fix a typo by introducing a macro constant.
> 
> Cc: Dave Airlie 
> Signed-off-by: Andy Shevchenko 
> ---
>  drivers/gpu/drm/drm_dp_mst_topology.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 70dcfa58d3c2..51c5fc11f852 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -2936,12 +2936,14 @@ static void drm_dp_mst_dump_mstb(struct seq_file *m,
>   }
>  }
>  
> +#define DP_PAYLOAD_TABLE_SIZE64
> +
>  static bool dump_dp_payload_table(struct drm_dp_mst_topology_mgr *mgr,
> char *buf)
>  {
>   int i;
>  
> - for (i = 0; i < 64; i += 16) {
> + for (i = 0; i < DP_PAYLOAD_TABLE_SIZE; i += 16) {
>   if (drm_dp_dpcd_read(mgr->aux,
>DP_PAYLOAD_TABLE_UPDATE_STATUS + i,
>[i], 16) != 16)
> @@ -3028,8 +3030,7 @@ void drm_dp_mst_dump_topology(struct seq_file *m,

There's a u8 buf[64] a few lines above, can you pls convert that one too
to the new #define?

With that this looks good to me.
-Daniel

>   seq_printf(m, " revision: hw: %x.%x sw: %x.%x\n",
>  buf[0x9] >> 4, buf[0x9] & 0xf, buf[0xa], buf[0xb]);
>   if (dump_dp_payload_table(mgr, buf))
> - seq_printf(m, "payload table: %*ph\n", 63, buf);
> -
> + seq_printf(m, "payload table: %*ph\n", 
> DP_PAYLOAD_TABLE_SIZE, buf);
>   }
>  
>   mutex_unlock(>lock);
> -- 
> 2.15.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

[PATCH] libdrm: Use readdir instead of readdir_r to avoid build warnings

[John Stultz]

Building libdrm under AOSP, we see the following build warning:
external/libdrm/xf86drm.c:2861:12: warning: 'readdir_r' is deprecated: 
readdir_r is deprecated; use readdir instead [-Wdeprecated-declarations]
while (readdir_r(sysdir, pent, ) == 0 && ent != NULL) {
   ^

Thus, this patch replaces readdir_r with readdir.

Cc: Robert Foss 
Cc: Rob Herring 
Cc: Stefan Schake 
Signed-off-by: John Stultz 
---
 xf86drm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xf86drm.c b/xf86drm.c
index 344326d..b9058c2 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -2858,7 +2858,7 @@ static char *drmGetMinorNameForFD(int fd, int type)
 if (pent == NULL)
  goto out_close_dir;
 
-while (readdir_r(sysdir, pent, ) == 0 && ent != NULL) {
+while ((ent = readdir(sysdir))) {
 if (strncmp(ent->d_name, name, len) == 0) {
 snprintf(dev_name, sizeof(dev_name), DRM_DIR_NAME "/%s",
  ent->d_name);
-- 
2.7.4

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

Re: [PATCH v2 00/11] drm/tinydrm: Support device unplug

[Daniel Vetter]

On Sat, Mar 17, 2018 at 03:40:29PM +0100, Noralf Trønnes wrote:
> 
> Den 16.03.2018 09.03, skrev Daniel Vetter:
> > On Fri, Sep 8, 2017 at 6:33 PM, Daniel Vetter  wrote:
> > > Hi Noralf,
> > > 
> > > On Fri, Sep 08, 2017 at 05:07:19PM +0200, Noralf Trønnes wrote:
> > > > This adds device unplug support to drm_fb_helper, drm_fb_cma_helper
> > > > (fbdev) and tinydrm.
> > > > 
> > > > There are several changes in this version:
> > > > 
> > > > I've used Daniel's idea of protecting drm_device.unplugged with srcu to
> > > > provide race free drm_dev_unplug().
> > > > 
> > > > The fbdev helper unplug patch has become very small with Daniel's help.
> > > > Ref is now taken and dropped in the existing helpers, so I could drop
> > > > drm_fb_helper_simple_init().
> > > > 
> > > > I has annoyed me that fbdev is restored in drm_driver.last_close even if
> > > > fbdev isn't used. I've added a patch to fix that. This means I can drop
> > > > calling drm_atomic_helper_shutdown() in tinydrm_unregister(), since I
> > > > now can easily disable the pipeline from userspace by just closing the
> > > > users. Disabled pipeline means balanced regulator_enable/disable.
> > > > 
> > > > The 'Embed drm_device in tinydrm_device' patch has gained
> > > > drm_driver.release functions after a discussion with Laurent. My
> > > > previous version relied on obscure freeing in tinydrm_release().
> > > > This means that I didn't retain the ack's.
> > > > 
> > > > Laurent also caught an ugly devm_kmalloc() in
> > > > tinydrm_display_pipe_init() that I've fixed.
> > > I'm practically packing for my 2 weeks of conference travel already, so
> > > only very cursory read of the initial patches for core I think
> > > this looks really splendid now.
> > > 
> > > But I won't have time for review for the next few week, would be good if
> > > you could drag some others into this discussions. Iirc there's recently
> > > been a few different people interested in udl (even some patches I think),
> > > they might be able to help out with testing
> > > 
> > > Also, would be great if you can submit this to intel-gfx on the next
> > > round, so that our CI can pick it up and give it a solid beating. Touching
> > > critical core paths like in patch 1 is always a bit scary.
> > While reviewing xen-front's hotunplug handling I just realized this
> > never landed. Can you pls resend and nag me to review it properly? I'd
> > really like to get the drm_dev_unplug stuff sorted out better.
> 
> My plan was to pick this up after switching tinydrm over to vmalloc buffers,
> but that work is now waiting for the generic fbdev emulation to land.
> 
> I'm currently wandering around inside drm_fb_helper looking for a way out,
> I can feel the draft so there has to be an exit somewhere. I hope that in
> a week or two I'm done with the next version of the RFC using the
> drm_fb_helper mode setting code instead of the ioctl's.
> 
> At that point it will be a good thing to flush my "caches" of the
> drm_fb_helper code, since after looking at it for a long time, I really
> don't see the details anymore. So I'll pick up the unplug series then, at
> least the core patches should be trivial to review and get merged if the CI
> agrees.

Sounds great. I chatted some more with Oleksandr on irc and explained how
he can at least prototype correct unplug code using the current upstream
stuff. He's also willing to help get your stuff landed I think. And afair
the unplug stuff pretty much looked ready for merging already, at least I
don't remember anything big pending.
-Daniel

> 
> Noralf.
> 
> > Thanks, Daniel
> > 
> > > Thanks, Daniel
> > > 
> > > > Noralf.
> > > > 
> > > > Noralf Trønnes (11):
> > > >drm: Use srcu to protect drm_device.unplugged
> > > >drm/fb-helper: Support device unplug
> > > >drm/fb-helper: Ensure driver module is pinned in fb_open()
> > > >drm/fb-helper: Don't restore if fbdev is not in use
> > > >drm/fb-cma-helper: Make struct drm_fbdev_cma public
> > > >drm/fb-cma-helper: Support device unplug
> > > >drm/tinydrm: Drop driver registered message
> > > >drm/tinydrm: Embed drm_device in tinydrm_device
> > > >drm/tinydrm: Support device unplug in core
> > > >drm/tinydrm/mi0283qt: Let the display pipe handle power
> > > >drm/tinydrm: Support device unplug in drivers
> > > > 
> > > >   drivers/gpu/drm/drm_drv.c   |  54 +--
> > > >   drivers/gpu/drm/drm_fb_cma_helper.c |  13 +--
> > > >   drivers/gpu/drm/drm_fb_helper.c | 108 
> > > > --
> > > >   drivers/gpu/drm/tinydrm/core/tinydrm-core.c | 135 
> > > > +++-
> > > >   drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c |  28 +++---
> > > >   drivers/gpu/drm/tinydrm/mi0283qt.c  |  81 +
> > > >   drivers/gpu/drm/tinydrm/mipi-dbi.c  |  58 +---
> > > >   drivers/gpu/drm/tinydrm/repaper.c   |  62 -
> > > >   

Re: [PATCH] drm/doc: Put all driver docs into a separate chapter

[Daniel Vetter]

On Fri, Mar 16, 2018 at 03:24:14PM -0400, Alex Deucher wrote:
> On Fri, Mar 16, 2018 at 3:59 AM, Daniel Vetter  wrote:
> > We have quite a few driver docs now, which is great, but having them
> > all in the top-level gpu documentation chapter makes it harder to spot
> > the core/shared bits.
> >
> > Stuff them into a separate chapter and ecourage people to add even
> > more!
> >
> > Signed-off-by: Daniel Vetter 
> 
> Reviewed-by: Alex Deucher 

Applied, thanks for your review.
-Daniel

> 
> > ---
> >  Documentation/gpu/drivers.rst | 21 +
> >  Documentation/gpu/index.rst   |  9 +
> >  2 files changed, 22 insertions(+), 8 deletions(-)
> >  create mode 100644 Documentation/gpu/drivers.rst
> >
> > diff --git a/Documentation/gpu/drivers.rst b/Documentation/gpu/drivers.rst
> > new file mode 100644
> > index ..e8c84419a2a1
> > --- /dev/null
> > +++ b/Documentation/gpu/drivers.rst
> > @@ -0,0 +1,21 @@
> > +
> > +GPU Driver Documentation
> > +
> > +
> > +.. toctree::
> > +
> > +   i915
> > +   meson
> > +   pl111
> > +   tegra
> > +   tinydrm
> > +   tve200
> > +   vc4
> > +   bridge/dw-hdmi
> > +
> > +.. only::  subproject and html
> > +
> > +   Indices
> > +   ===
> > +
> > +   * :ref:`genindex`
> > diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst
> > index c36586dad29d..00288f34c5a6 100644
> > --- a/Documentation/gpu/index.rst
> > +++ b/Documentation/gpu/index.rst
> > @@ -10,16 +10,9 @@ Linux GPU Driver Developer's Guide
> > drm-kms
> > drm-kms-helpers
> > drm-uapi
> > -   i915
> > -   meson
> > -   pl111
> > -   tegra
> > -   tinydrm
> > -   tve200
> > -   vc4
> > +   drivers
> > vga-switcheroo
> > vgaarbiter
> > -   bridge/dw-hdmi
> > todo
> >
> >  .. only::  subproject and html
> > --
> > 2.16.2
> >
> > ___
> > 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

[PATCH] drm/i915/gvt: fix spelling mistake: "registeration" -> "registration"

[Colin King]

From: Colin Ian King 

Trivial fix to spelling mistake in gvt_err error message text

Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/i915/gvt/gvt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gvt/gvt.c b/drivers/gpu/drm/i915/gvt/gvt.c
index 61bd14fcb649..8c3422578cc4 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.c
+++ b/drivers/gpu/drm/i915/gvt/gvt.c
@@ -444,7 +444,7 @@ int intel_gvt_init_device(struct drm_i915_private *dev_priv)
 
ret = intel_gvt_debugfs_init(gvt);
if (ret)
-   gvt_err("debugfs registeration failed, go on.\n");
+   gvt_err("debugfs registration failed, go on.\n");
 
gvt_dbg_core("gvt device initialization is done\n");
dev_priv->gvt = gvt;
-- 
2.15.1

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

Re: [PATCH 1/4] GPU: drm: Fixed Spacing issue

[Sean Paul]

On Mon, Mar 19, 2018 at 12:52:22AM +, Paul McQuade wrote:
> "foo * bar" should be "foo *bar"
> 
> Signed-off-by: Paul McQuade 

Thank you for your patches. I've squashed them all into one, fixed up the commit
message and applied them to drm-misc-next.

Sean

> ---
>  drivers/gpu/drm/drm_bufs.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
> index 1ee84dd802d4..83b3d0801262 100644
> --- a/drivers/gpu/drm/drm_bufs.c
> +++ b/drivers/gpu/drm/drm_bufs.c
> @@ -129,7 +129,7 @@ static int drm_map_handle(struct drm_device *dev, struct 
> drm_hash_item *hash,
>   * type.  Adds the map to the map list drm_device::maplist. Adds MTRR's where
>   * applicable and if supported by the kernel.
>   */
> -static int drm_addmap_core(struct drm_device * dev, resource_size_t offset,
> +static int drm_addmap_core(struct drm_device *dev, resource_size_t offset,
>  unsigned int size, enum drm_map_type type,
>  enum drm_map_flags flags,
>  struct drm_map_list ** maplist)
> @@ -361,7 +361,7 @@ static int drm_addmap_core(struct drm_device * dev, 
> resource_size_t offset,
>   return 0;
>  }
>  
> -int drm_legacy_addmap(struct drm_device * dev, resource_size_t offset,
> +int drm_legacy_addmap(struct drm_device *dev, resource_size_t offset,
> unsigned int size, enum drm_map_type type,
> enum drm_map_flags flags, struct drm_local_map **map_ptr)
>  {
> @@ -637,8 +637,8 @@ int drm_legacy_rmmap_ioctl(struct drm_device *dev, void 
> *data,
>   *
>   * Frees any pages and buffers associated with the given entry.
>   */
> -static void drm_cleanup_buf_error(struct drm_device * dev,
> -   struct drm_buf_entry * entry)
> +static void drm_cleanup_buf_error(struct drm_device *dev,
> +   struct drm_buf_entry *entry)
>  {
>   int i;
>  
> -- 
> 2.16.2
> 

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

Re: [PATCH DRM] drm: remove drm_mode_object_{un/reference} aliases

[Sean Paul]

On Mon, Mar 19, 2018 at 01:58:20AM -0400, Haneen Mohammed wrote:
> This patch remove the compatibility aliases
> drm_mode_object_{reference/unreference} of drm_mode_object_{get/put}
> since all callers have been converted to the prefered _{get/put}.
> 
> Remove the helpers from the semantic patch drm-get-put-cocci.
> 
> Signed-off-by: Haneen Mohammed 

Thanks for your patch, applied to drm-misc-next.

Sean

> ---
>  include/drm/drm_mode_object.h| 24 
>  scripts/coccinelle/api/drm-get-put.cocci | 10 --
>  2 files changed, 34 deletions(-)
> 
> diff --git a/include/drm/drm_mode_object.h b/include/drm/drm_mode_object.h
> index 7ba3913..c34a3e8 100644
> --- a/include/drm/drm_mode_object.h
> +++ b/include/drm/drm_mode_object.h
> @@ -120,30 +120,6 @@ struct drm_mode_object *drm_mode_object_find(struct 
> drm_device *dev,
>  void drm_mode_object_get(struct drm_mode_object *obj);
>  void drm_mode_object_put(struct drm_mode_object *obj);
>  
> -/**
> - * drm_mode_object_reference - acquire a mode object reference
> - * @obj: DRM mode object
> - *
> - * This is a compatibility alias for drm_mode_object_get() and should not be
> - * used by new code.
> - */
> -static inline void drm_mode_object_reference(struct drm_mode_object *obj)
> -{
> - drm_mode_object_get(obj);
> -}
> -
> -/**
> - * drm_mode_object_unreference - release a mode object reference
> - * @obj: DRM mode object
> - *
> - * This is a compatibility alias for drm_mode_object_put() and should not be
> - * used by new code.
> - */
> -static inline void drm_mode_object_unreference(struct drm_mode_object *obj)
> -{
> - drm_mode_object_put(obj);
> -}
> -
>  int drm_object_property_set_value(struct drm_mode_object *obj,
> struct drm_property *property,
> uint64_t val);
> diff --git a/scripts/coccinelle/api/drm-get-put.cocci 
> b/scripts/coccinelle/api/drm-get-put.cocci
> index 91fceb8..ceb71ea 100644
> --- a/scripts/coccinelle/api/drm-get-put.cocci
> +++ b/scripts/coccinelle/api/drm-get-put.cocci
> @@ -16,12 +16,6 @@ expression object;
>  @@
>  
>  (
> -- drm_mode_object_reference(object)
> -+ drm_mode_object_get(object)
> -|
> -- drm_mode_object_unreference(object)
> -+ drm_mode_object_put(object)
> -|
>  - drm_connector_reference(object)
>  + drm_connector_get(object)
>  |
> @@ -62,10 +56,6 @@ position p;
>  @@
>  
>  (
> -drm_mode_object_unreference@p(object)
> -|
> -drm_mode_object_reference@p(object)
> -|
>  drm_connector_unreference@p(object)
>  |
>  drm_connector_reference@p(object)
> -- 
> 2.7.4
> 

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

Re: [Outreachy kernel] Re: [PATCH] gpu: drm: Use list_first_entry instead of list_entry

[Christian König]

Am 19.03.2018 um 12:06 schrieb Julia Lawall:


On Mon, 19 Mar 2018, Christian König wrote:


Mhm, actually that patch isn't correct. What we grab get here is the next
entry, not the first one.

We don't have an alias list_next_entry for list_first_entry?

As compared to the semantic patch I proposed earlier today, it would seem
that list_first_entry is useful when the types are different?  One would
have to check the result of course, but a list eleemnt with the same type
as the structure that contains the list might be unlikely?


The list element and the list head have different types in this case:

if (sa_manager->hole->next == _manager->olist)
return;
   -sa_bo = list_entry(sa_manager->hole->next, struct amdgpu_sa_bo, olist);
+   sa_bo = list_first_entry(sa_manager->hole, struct amdgpu_sa_bo, olist);


sa_manager->olist is the head of the list and sa_manager->hole can point 
to both the head and any element in the list.


The statement "if (sa_manager->hole->next == _manager->olist)" now 
checks if the next pointer points to the head and if so aborts the function.


Then the statement "sa_bo = list_entry(sa_manager->hole->next, struct 
amdgpu_sa_bo, olist);" returns the next element after the hole to try to 
release it.


So with the automated change the code is still correct, but NOT easier 
to understand because we actually don't grab the first element here.


Regards,
Christian.



julia


Regards,
Christian.

Am 18.03.2018 um 22:51 schrieb Arushi Singhal:

This patch replaces list_entry with list_first_entry as it makes the
code more clear.
Done using coccinelle:

@@
expression e;
@@
(
- list_entry(e->next,
+ list_first_entry(e,
...)
|
- list_entry(e->prev,
+ list_last_entry(e,
...)
)

Signed-off-by: Arushi Singhal 
---
   drivers/gpu/drm/amd/amdgpu/amdgpu_sa.c | 4 ++--
   drivers/gpu/drm/omapdrm/dss/display.c  | 4 ++--
   drivers/gpu/drm/radeon/radeon_sa.c | 4 ++--
   3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_sa.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_sa.c
index 3144400..646f593 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_sa.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_sa.c
@@ -158,7 +158,7 @@ static void amdgpu_sa_bo_try_free(struct
amdgpu_sa_manager *sa_manager)
if (sa_manager->hole->next == _manager->olist)
return;
   -sa_bo = list_entry(sa_manager->hole->next, struct amdgpu_sa_bo,
olist);
+   sa_bo = list_first_entry(sa_manager->hole, struct amdgpu_sa_bo,
olist);
list_for_each_entry_safe_from(sa_bo, tmp, _manager->olist, olist) {
if (sa_bo->fence == NULL ||
!dma_fence_is_signaled(sa_bo->fence)) {
@@ -183,7 +183,7 @@ static inline unsigned amdgpu_sa_bo_hole_eoffset(struct
amdgpu_sa_manager *sa_ma
struct list_head *hole = sa_manager->hole;
if (hole->next != _manager->olist) {
-   return list_entry(hole->next, struct amdgpu_sa_bo,
olist)->soffset;
+   return list_first_entry(hole, struct amdgpu_sa_bo,
olist)->soffset;
}
return sa_manager->size;
   }
diff --git a/drivers/gpu/drm/omapdrm/dss/display.c
b/drivers/gpu/drm/omapdrm/dss/display.c
index 0c9480b..fb9ecae 100644
--- a/drivers/gpu/drm/omapdrm/dss/display.c
+++ b/drivers/gpu/drm/omapdrm/dss/display.c
@@ -158,8 +158,8 @@ struct omap_dss_device *omap_dss_get_next_device(struct
omap_dss_device *from)
goto out;
}
   -dssdev = list_entry(l->next, struct omap_dss_device,
-   panel_list);
+   dssdev = list_first_entry(l, struct omap_dss_device,
+ panel_list);
omap_dss_get_device(dssdev);
goto out;
}
diff --git a/drivers/gpu/drm/radeon/radeon_sa.c
b/drivers/gpu/drm/radeon/radeon_sa.c
index 197b157..66c0482 100644
--- a/drivers/gpu/drm/radeon/radeon_sa.c
+++ b/drivers/gpu/drm/radeon/radeon_sa.c
@@ -158,7 +158,7 @@ static void radeon_sa_bo_try_free(struct
radeon_sa_manager *sa_manager)
if (sa_manager->hole->next == _manager->olist)
return;
   -sa_bo = list_entry(sa_manager->hole->next, struct radeon_sa_bo,
olist);
+   sa_bo = list_first_entry(sa_manager->hole, struct radeon_sa_bo,
olist);
list_for_each_entry_safe_from(sa_bo, tmp, _manager->olist, olist) {
if (sa_bo->fence == NULL ||
!radeon_fence_signaled(sa_bo->fence)) {
return;
@@ -182,7 +182,7 @@ static inline unsigned radeon_sa_bo_hole_eoffset(struct
radeon_sa_manager *sa_ma
struct list_head *hole = sa_manager->hole;
if (hole->next != _manager->olist) {
-   return list_entry(hole->next, struct radeon_sa_bo,
olist)->soffset;
+   return list_first_entry(hole, struct radeon_sa_bo,

Re: [PATCH 3/3] arm64: dts: meson-gxl-s905x-libretech-cc: add cec-disable

[Neil Armstrong]

On 19/03/2018 12:43, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> This board has two CEC controllers: the DesignWare controller and
> a meson-specific controller. Disable the DW controller since the
> CEC line is hooked up to the meson controller.
> 
> Signed-off-by: Hans Verkuil 
> ---
>  arch/arm64/boot/dts/amlogic/meson-gxl-s905x-libretech-cc.dts | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-libretech-cc.dts 
> b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-libretech-cc.dts
> index 9671f1e3c74a..271bd486fd65 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-libretech-cc.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-libretech-cc.dts
> @@ -155,6 +155,7 @@
>   status = "okay";
>   pinctrl-0 = <_hpd_pins>, <_i2c_pins>;
>   pinctrl-names = "default";
> + cec-disable;
>  };
>  
>  _tx_tmds_port {
> 

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

Re: [PATCH 2/3] drm: bridge: dw-hdmi: check the cec-disable property

[Neil Armstrong]

On 19/03/2018 12:43, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> If the cec-disable property was set, then disable the DW CEC
> controller. This is needed for boards that have their own
> CEC controller.
> 
> Signed-off-by: Hans Verkuil 
> ---
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index a38db40ce990..597220e40541 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -2508,7 +2508,8 @@ __dw_hdmi_probe(struct platform_device *pdev,
>   hdmi->audio = platform_device_register_full();
>   }
>  
> - if (config0 & HDMI_CONFIG0_CEC) {
> + if ((config0 & HDMI_CONFIG0_CEC) &&
> + !of_property_read_bool(np, "cec-disable")) {
>   cec.hdmi = hdmi;
>   cec.ops = _hdmi_cec_ops;
>   cec.irq = irq;
> 

I suspected the bit was off for the Amlogic GX SoCs, I was wrong...

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

Re: [PATCH 1/3] dt-bindings: display: dw_hdmi.txt

[Neil Armstrong]

On 19/03/2018 12:43, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> Some boards have both a DesignWare and their own CEC controller.
> The CEC pin is only hooked up to their own CEC controller and not
> to the DW controller.
> 
> Add the cec-disable property to disable the DW CEC controller.
> 
> This particular situation happens on Amlogic boards that have their
> own meson CEC controller.
> 
> Signed-off-by: Hans Verkuil 
> ---
>  Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt 
> b/Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt
> index 33bf981fbe33..4a13f4858bc0 100644
> --- a/Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt
> +++ b/Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt
> @@ -27,6 +27,9 @@ responsible for defining whether each property is required 
> or optional.
>- "isfr" is the internal register configuration clock (mandatory).
>- "cec" is the HDMI CEC controller main clock (optional).
>  
> +- cec-disable: Do not use the DWC CEC controller since the CEC line is not
> +  hooked up even though the CEC DWC IP is present.
> +
>  - ports: The connectivity of the DWC HDMI TX with the rest of the system is
>expressed in using ports as specified in the device graph bindings defined
>in Documentation/devicetree/bindings/graph.txt. The numbering of the ports
> 

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

Re: [PATCH 0/3] dw-hdmi: add property to disable CEC

[Neil Armstrong]

Hi Hans,

On 19/03/2018 12:43, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> Some boards (amlogic) have two CEC controllers: the DesignWare controller
> and their own CEC controller (meson ao-cec).
> 
> Since the CEC line is not hooked up to the DW controller we need a way
> to disable that controller. This patch series adds the cec-disable
> property for that purpose.
> 
> Neil, I have added cec-disable to meson-gxl-s905x-libretech-cc.dts
> only, but I suspect it is probably valid for all meson-glx devices?
> Should I move it to meson-gxl.dtsi?

It's valid on all GX devices, so you can add to meson-gx.dtsi

Neil

> 
> Regards,
> 
>   Hans
> 
> Hans Verkuil (3):
>   dt-bindings: display: dw_hdmi.txt
>   drm: bridge: dw-hdmi: check the cec-disable property
>   arm64: dts: meson-gxl-s905x-libretech-cc: add cec-disable
> 
>  Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt | 3 +++
>  arch/arm64/boot/dts/amlogic/meson-gxl-s905x-libretech-cc.dts | 1 +
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c| 3 ++-
>  3 files changed, 6 insertions(+), 1 deletion(-)
> 

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

Re: [PATCH v4 1/3] drm/panel: refactor INNOLUX P079ZCA panel driver

[Emil Velikov]

On 15 March 2018 at 02:35, hl  wrote:
> Hi Emil,
>
>
>
> On Wednesday, March 14, 2018 08:02 PM, Emil Velikov wrote:
>>
>> Hi Lin,
>>
>> On 14 March 2018 at 09:12, Lin Huang  wrote:
>>>
>>> From: huang lin 
>>>
>>> Refactor Innolux P079ZCA panel driver, let it support
>>> multi panel.
>>>
>>> Change-Id: If89be5e56dba8cb498e2d50c1bbeb0e8016123a2
>>> Signed-off-by: Lin Huang 
>>> ---
>>> Changes in v2:
>>> - Change regulator property name to meet the panel datasheet
>>> Changes in v3:
>>> - this patch only refactor P079ZCA panel to support multi panel, support
>>> P097PFG panel in another patch
>>> Changes in v4:
>>> - Modify the patch which suggest by Thierry
>>>
>> Thanks for splitting this up. I think there's another piece that fell
>> through the cracks.
>> I'm not deeply familiar with the driver, so just sharing some quick notes.
>>
>>
>>>   struct innolux_panel {
>>>  struct drm_panel base;
>>>  struct mipi_dsi_device *link;
>>> +   const struct panel_desc *desc;
>>>
>>>  struct backlight_device *backlight;
>>> -   struct regulator *supply;
>>> +   struct regulator *vddi;
>>> +   struct regulator *avdd;
>>> +   struct regulator *avee;
>>
>> These two seem are new addition, as opposed to a dummy refactor.
>> Are they optional, does one need them for the existing panel (separate
>> patch?) or only for the new one (squash with the new panel code)?
>>
>>
>>>  struct gpio_desc *enable_gpio;
>>>
>>>  bool prepared;
>>> @@ -77,9 +93,9 @@ static int innolux_panel_unprepare(struct drm_panel
>>> *panel)
>>>  /* T8: 80ms - 1000ms */
>>>  msleep(80);
>>>
>>> -   err = regulator_disable(innolux->supply);
>>> -   if (err < 0)
>>> -   return err;
>>
>> Good call on dropping the early return here.
>>
>>
>>> @@ -207,19 +248,28 @@ static const struct drm_panel_funcs
>>> innolux_panel_funcs = {
>>> -   innolux->supply = devm_regulator_get(dev, "power");
>>> -   if (IS_ERR(innolux->supply))
>>> -   return PTR_ERR(innolux->supply);
>>> +   innolux = devm_kzalloc(dev, sizeof(*innolux), GFP_KERNEL);
>>> +   if (!innolux)
>>> +   return -ENOMEM;
>>> +
>>> +   innolux->desc = desc;
>>> +   innolux->vddi = devm_regulator_get(dev, "power");
>>> +   innolux->avdd = devm_regulator_get(dev, "avdd");
>>> +   innolux->avee = devm_regulator_get(dev, "avee");
>>>
>> AFAICT devm_regulator_get returns a pointer which is unsuitable to be
>> passed into regulator_{enable,disable}.
>> Hence, the IS_ERR check should stay. If any of the regulators are
>> optional, you want to call regulator_{enable,disable} only as
>> applicable.
>
>
> devm_regulator_get() will use dummy_regulator if there not regulator pass to
> driver, so it not affect regulator_{enable, disable}.

One of us is getting confused here:
devm_regulator_get does not _use_ a regulator, it returns a pointer to
a regulator, right?

According to the 4.16-rc6 codebase - one error devm_regulator_get
returns a ERR_PTR [1].
With the pointer dereferenced in regulator_enable [2], without a
IS_ERR check, hence thing will go boom(?)

> These three regulator are
> optional,
> the p079zca will use "power" and ,
> so i think it better not to check ERR here.
>
What should happen if p079zca is missing "power" or p097pgf - "avdd" and "avee"?
Obviously the latter two should be introduced with the p097pgf support.

HTH
Emil

[1] 
https://elixir.bootlin.com/linux/v4.16-rc6/source/drivers/regulator/devres.c#L27
[2] 
https://elixir.bootlin.com/linux/v4.16-rc6/source/drivers/regulator/core.c#L2189
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] dt-bindings: display: dw_hdmi.txt

[Hans Verkuil]

On 03/19/2018 12:46 PM, Fabio Estevam wrote:
> Hi Hans,
> 
> On Mon, Mar 19, 2018 at 8:43 AM, Hans Verkuil  wrote:
>> From: Hans Verkuil 
> 
> It seems the Subject line is missing some content?

Oops. That should have been:

dt-bindings: display: dw_hdmi.txt: add cec-disable property

Thanks for pointing this out.

Regards,

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

Re: [PATCH 1/3] dt-bindings: display: dw_hdmi.txt

[Fabio Estevam]

Hi Hans,

On Mon, Mar 19, 2018 at 8:43 AM, Hans Verkuil  wrote:
> From: Hans Verkuil 

It seems the Subject line is missing some content?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/3] dw-hdmi: add property to disable CEC

[Hans Verkuil]

From: Hans Verkuil 

Some boards (amlogic) have two CEC controllers: the DesignWare controller
and their own CEC controller (meson ao-cec).

Since the CEC line is not hooked up to the DW controller we need a way
to disable that controller. This patch series adds the cec-disable
property for that purpose.

Neil, I have added cec-disable to meson-gxl-s905x-libretech-cc.dts
only, but I suspect it is probably valid for all meson-glx devices?
Should I move it to meson-gxl.dtsi?

Regards,

Hans

Hans Verkuil (3):
  dt-bindings: display: dw_hdmi.txt
  drm: bridge: dw-hdmi: check the cec-disable property
  arm64: dts: meson-gxl-s905x-libretech-cc: add cec-disable

 Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt | 3 +++
 arch/arm64/boot/dts/amlogic/meson-gxl-s905x-libretech-cc.dts | 1 +
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c| 3 ++-
 3 files changed, 6 insertions(+), 1 deletion(-)

-- 
2.15.1

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

[PATCH 2/3] drm: bridge: dw-hdmi: check the cec-disable property

[Hans Verkuil]

From: Hans Verkuil 

If the cec-disable property was set, then disable the DW CEC
controller. This is needed for boards that have their own
CEC controller.

Signed-off-by: Hans Verkuil 
---
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index a38db40ce990..597220e40541 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -2508,7 +2508,8 @@ __dw_hdmi_probe(struct platform_device *pdev,
hdmi->audio = platform_device_register_full();
}
 
-   if (config0 & HDMI_CONFIG0_CEC) {
+   if ((config0 & HDMI_CONFIG0_CEC) &&
+   !of_property_read_bool(np, "cec-disable")) {
cec.hdmi = hdmi;
cec.ops = _hdmi_cec_ops;
cec.irq = irq;
-- 
2.15.1

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

[PATCH 1/3] dt-bindings: display: dw_hdmi.txt

[Hans Verkuil]

From: Hans Verkuil 

Some boards have both a DesignWare and their own CEC controller.
The CEC pin is only hooked up to their own CEC controller and not
to the DW controller.

Add the cec-disable property to disable the DW CEC controller.

This particular situation happens on Amlogic boards that have their
own meson CEC controller.

Signed-off-by: Hans Verkuil 
---
 Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt 
b/Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt
index 33bf981fbe33..4a13f4858bc0 100644
--- a/Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt
+++ b/Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt
@@ -27,6 +27,9 @@ responsible for defining whether each property is required or 
optional.
   - "isfr" is the internal register configuration clock (mandatory).
   - "cec" is the HDMI CEC controller main clock (optional).
 
+- cec-disable: Do not use the DWC CEC controller since the CEC line is not
+  hooked up even though the CEC DWC IP is present.
+
 - ports: The connectivity of the DWC HDMI TX with the rest of the system is
   expressed in using ports as specified in the device graph bindings defined
   in Documentation/devicetree/bindings/graph.txt. The numbering of the ports
-- 
2.15.1

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

[PATCH 3/3] arm64: dts: meson-gxl-s905x-libretech-cc: add cec-disable

[Hans Verkuil]

From: Hans Verkuil 

This board has two CEC controllers: the DesignWare controller and
a meson-specific controller. Disable the DW controller since the
CEC line is hooked up to the meson controller.

Signed-off-by: Hans Verkuil 
---
 arch/arm64/boot/dts/amlogic/meson-gxl-s905x-libretech-cc.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-libretech-cc.dts 
b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-libretech-cc.dts
index 9671f1e3c74a..271bd486fd65 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-libretech-cc.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-libretech-cc.dts
@@ -155,6 +155,7 @@
status = "okay";
pinctrl-0 = <_hpd_pins>, <_i2c_pins>;
pinctrl-names = "default";
+   cec-disable;
 };
 
 _tx_tmds_port {
-- 
2.15.1

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

Re: [Outreachy kernel] Re: [PATCH] gpu: drm: Use list_first_entry instead of list_entry

[Julia Lawall]

On Mon, 19 Mar 2018, Christian König wrote:

> Mhm, actually that patch isn't correct. What we grab get here is the next
> entry, not the first one.
>
> We don't have an alias list_next_entry for list_first_entry?

As compared to the semantic patch I proposed earlier today, it would seem
that list_first_entry is useful when the types are different?  One would
have to check the result of course, but a list eleemnt with the same type
as the structure that contains the list might be unlikely?

julia

>
> Regards,
> Christian.
>
> Am 18.03.2018 um 22:51 schrieb Arushi Singhal:
> > This patch replaces list_entry with list_first_entry as it makes the
> > code more clear.
> > Done using coccinelle:
> >
> > @@
> > expression e;
> > @@
> > (
> > - list_entry(e->next,
> > + list_first_entry(e,
> >...)
> > |
> > - list_entry(e->prev,
> > + list_last_entry(e,
> >...)
> > )
> >
> > Signed-off-by: Arushi Singhal 
> > ---
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_sa.c | 4 ++--
> >   drivers/gpu/drm/omapdrm/dss/display.c  | 4 ++--
> >   drivers/gpu/drm/radeon/radeon_sa.c | 4 ++--
> >   3 files changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_sa.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_sa.c
> > index 3144400..646f593 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_sa.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_sa.c
> > @@ -158,7 +158,7 @@ static void amdgpu_sa_bo_try_free(struct
> > amdgpu_sa_manager *sa_manager)
> > if (sa_manager->hole->next == _manager->olist)
> > return;
> >   - sa_bo = list_entry(sa_manager->hole->next, struct amdgpu_sa_bo,
> > olist);
> > +   sa_bo = list_first_entry(sa_manager->hole, struct amdgpu_sa_bo,
> > olist);
> > list_for_each_entry_safe_from(sa_bo, tmp, _manager->olist, olist) {
> > if (sa_bo->fence == NULL ||
> > !dma_fence_is_signaled(sa_bo->fence)) {
> > @@ -183,7 +183,7 @@ static inline unsigned amdgpu_sa_bo_hole_eoffset(struct
> > amdgpu_sa_manager *sa_ma
> > struct list_head *hole = sa_manager->hole;
> > if (hole->next != _manager->olist) {
> > -   return list_entry(hole->next, struct amdgpu_sa_bo,
> > olist)->soffset;
> > +   return list_first_entry(hole, struct amdgpu_sa_bo,
> > olist)->soffset;
> > }
> > return sa_manager->size;
> >   }
> > diff --git a/drivers/gpu/drm/omapdrm/dss/display.c
> > b/drivers/gpu/drm/omapdrm/dss/display.c
> > index 0c9480b..fb9ecae 100644
> > --- a/drivers/gpu/drm/omapdrm/dss/display.c
> > +++ b/drivers/gpu/drm/omapdrm/dss/display.c
> > @@ -158,8 +158,8 @@ struct omap_dss_device *omap_dss_get_next_device(struct
> > omap_dss_device *from)
> > goto out;
> > }
> >   - dssdev = list_entry(l->next, struct omap_dss_device,
> > -   panel_list);
> > +   dssdev = list_first_entry(l, struct omap_dss_device,
> > + panel_list);
> > omap_dss_get_device(dssdev);
> > goto out;
> > }
> > diff --git a/drivers/gpu/drm/radeon/radeon_sa.c
> > b/drivers/gpu/drm/radeon/radeon_sa.c
> > index 197b157..66c0482 100644
> > --- a/drivers/gpu/drm/radeon/radeon_sa.c
> > +++ b/drivers/gpu/drm/radeon/radeon_sa.c
> > @@ -158,7 +158,7 @@ static void radeon_sa_bo_try_free(struct
> > radeon_sa_manager *sa_manager)
> > if (sa_manager->hole->next == _manager->olist)
> > return;
> >   - sa_bo = list_entry(sa_manager->hole->next, struct radeon_sa_bo,
> > olist);
> > +   sa_bo = list_first_entry(sa_manager->hole, struct radeon_sa_bo,
> > olist);
> > list_for_each_entry_safe_from(sa_bo, tmp, _manager->olist, olist) {
> > if (sa_bo->fence == NULL ||
> > !radeon_fence_signaled(sa_bo->fence)) {
> > return;
> > @@ -182,7 +182,7 @@ static inline unsigned radeon_sa_bo_hole_eoffset(struct
> > radeon_sa_manager *sa_ma
> > struct list_head *hole = sa_manager->hole;
> > if (hole->next != _manager->olist) {
> > -   return list_entry(hole->next, struct radeon_sa_bo,
> > olist)->soffset;
> > +   return list_first_entry(hole, struct radeon_sa_bo,
> > olist)->soffset;
> > }
> > return sa_manager->size;
> >   }
>
> --
> You received this message because you are subscribed to the Google Groups
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/outreachy-kernel/8b1e22f8-7a05-b66b-8825-7d4d97e46dac%40amd.com.
> For more options, visit https://groups.google.com/d/optout.
>___
dri-devel mailing list
dri-devel@lists.freedesktop.org

[GIT PULL] drm/tegra: Changes for v4.17-rc1

[Thierry Reding]

Hi Dave,

The following changes since commit 7928b2cbe55b2a410a0f5c1f154610059c57b1b2:

  Linux 4.16-rc1 (2018-02-11 15:04:29 -0800)

are available in the Git repository at:

  git://anongit.freedesktop.org/tegra/linux tags/drm/tegra/for-4.17-rc1

for you to fetch changes up to 27e92f1f1600c214bf649daddb9b88b68330a8d1:

  drm/tegra: prime: Implement ->{begin,end}_cpu_access() (2018-03-17 00:04:20 
+0100)

Apologies for the delay. I originally wanted to send this out on Friday
but then ran into a pair of bugs that I thought might be caused by this
branch. Turns out that they were both already broken in v4.16-rc1 and I
just hadn't tested for the corner case, so I caught them only very late
in the release cycle.

Anyway, the fixes for that are on the drm/tegra/fixes branch for which
I sent an updated pull request earlier. The stuff here's fairly trivial
and incremental improvements.

Thanks,
Thierry


drm/tegra: Changes for v4.17-rc1

This fixes mmap() for fbdev devices by providing a custom implementation
based on the KMS variant. This is a fairly exotic case these days, hence
why it is not flagged for stable.

There is also support for dedicating one of the overlay planes to serve
as a hardware cursor on older Tegra that did support hardware cursors
but not RGBA formats for it.

Planes will now also export the IN_FORMATS property by supporting the
various block-linear tiling modifiers for RGBA pixel formats.

Other than that, there's a bit of cleanup of DMA API abuse, use of the
private object infrastructure for global state (rather than subclassing
atomic state objects) and an implementation of ->{begin,end}_cpu_access
callbacks for PRIME exported buffers, which allow users to perform cache
maintenance on these buffers.


Dmitry Osipenko (2):
  drm/tegra: plane: Make tegra_plane_get_overlap_index() static
  drm/tegra: dc: Dedicate overlay plane to cursor on older Tegra's

Thierry Reding (8):
  drm/tegra: gem: Reshuffle declarations
  drm/tegra: gem: Make __tegra_gem_mmap() available more widely
  drm/tegra: fb: Implement ->fb_mmap() callback
  drm/tegra: plane: Support format modifiers
  drm/tegra: fb: Properly support linear modifier
  drm/tegra: hub: Use private object for global state
  drm/tegra: gem: Map pages via the DMA API
  drm/tegra: prime: Implement ->{begin,end}_cpu_access()

 drivers/gpu/drm/tegra/dc.c|  82 ---
 drivers/gpu/drm/tegra/dc.h|   1 +
 drivers/gpu/drm/tegra/drm.c   |  36 ++--
 drivers/gpu/drm/tegra/drm.h   |  14 -
 drivers/gpu/drm/tegra/fb.c|  25 -
 drivers/gpu/drm/tegra/gem.c   |  69 ---
 drivers/gpu/drm/tegra/gem.h   |   5 +-
 drivers/gpu/drm/tegra/hub.c   | 125 +++---
 drivers/gpu/drm/tegra/hub.h   |  17 ++
 drivers/gpu/drm/tegra/plane.c |  20 ++-
 10 files changed, 280 insertions(+), 114 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105597] [CI] igt@kms_cursor_legacy@cursora-vs-flipa-atomic-transition - incomplete - Build timed out (after 18 minutes)

[bugzilla-daemon]

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

Marta Löfstedt  changed:

   What|Removed |Added

   See Also||https://bugs.freedesktop.or
   ||g/show_bug.cgi?id=105598

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

[Bug 105598] [CI] igt@kms_frontbuffer_tracking@drrs-2p-scndscrn-spr-indfb-move - Build timed out (after 18 minutes)

[bugzilla-daemon]

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

Marta Löfstedt  changed:

   What|Removed |Added

   See Also||https://bugs.freedesktop.or
   ||g/show_bug.cgi?id=105597

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

[Bug 105523] [CI] igt@pm_rpm@universal-planes - incomplete - Build timed out (after 18 minutes)

[bugzilla-daemon]

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

Marta Löfstedt  changed:

   What|Removed |Added

Summary|[Ci]|[CI]
   |igt@pm_rpm@universal-planes |igt@pm_rpm@universal-planes
   |- incomplete - Build timed  |- incomplete - Build timed
   |out (after 18 minutes)  |out (after 18 minutes)

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

[Bug 105598] [CI] igt@kms_frontbuffer_tracking@drrs-2p-scndscrn-spr-indfb-move - Build timed out (after 18 minutes)

[bugzilla-daemon]

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

Marta Löfstedt  changed:

   What|Removed |Added

 Whiteboard||ReadyForDev
   See Also||https://bugs.freedesktop.or
   ||g/show_bug.cgi?id=105523

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

[Bug 105598] [CI] igt@kms_frontbuffer_tracking@drrs-2p-scndscrn-spr-indfb-move - Build timed out (after 18 minutes)

[bugzilla-daemon]

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

Bug ID: 105598
   Summary: [CI]
igt@kms_frontbuffer_tracking@drrs-2p-scndscrn-spr-indf
b-move - Build timed out (after 18 minutes)
   Product: DRI
   Version: DRI git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: IGT
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: marta.lofst...@intel.com

https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_2/fi-snb-2520m/igt@kms_frontbuffer_track...@drrs-2p-scndscrn-spr-indfb-move.html

running: igt/kms_frontbuffer_tracking/drrs-2p-scndscrn-spr-indfb-move

[14/98] skip: 9, pass: 2, dmesg-warn: 3 -
Build timed out (after 18 minutes). Marking the build as aborted.

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

[Bug 105523] [Ci] igt@pm_rpm@universal-planes - incomplete - Build timed out (after 18 minutes)

[bugzilla-daemon]

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

Marta Löfstedt  changed:

   What|Removed |Added

   See Also||https://bugs.freedesktop.or
   ||g/show_bug.cgi?id=105598

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

[Bug 105523] [Ci] igt@pm_rpm@universal-planes - incomplete - Build timed out (after 18 minutes)

[bugzilla-daemon]

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

Marta Löfstedt  changed:

   What|Removed |Added

 QA Contact|intel-gfx-bugs@lists.freede |
   |sktop.org   |
  Component|DRM/Intel   |IGT
   Assignee|intel-gfx-bugs@lists.freede |dri-devel@lists.freedesktop
   |sktop.org   |.org

--- Comment #2 from Marta Löfstedt  ---
I changed this to IGT since there is no Component for the Intel CI system. I
believe that the shard size need to be smaller

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

[Bug 105597] [CI] igt@kms_cursor_legacy@cursora-vs-flipa-atomic-transition - incomplete - Build timed out (after 18 minutes)

[bugzilla-daemon]

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

Marta Löfstedt  changed:

   What|Removed |Added

   See Also||https://bugs.freedesktop.or
   ||g/show_bug.cgi?id=105523

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

[Bug 105597] [CI] igt@kms_cursor_legacy@cursora-vs-flipa-atomic-transition - incomplete - Build timed out (after 18 minutes)

[bugzilla-daemon]

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

Marta Löfstedt  changed:

   What|Removed |Added

  Component|DRM/Intel   |IGT
   Assignee|intel-gfx-bugs@lists.freede |dri-devel@lists.freedesktop
   |sktop.org   |.org
 QA Contact|intel-gfx-bugs@lists.freede |
   |sktop.org   |
 Whiteboard||ReadyForDev

--- Comment #1 from Marta Löfstedt  ---
I file this on IGT since there is no Component for the Intel CI system.

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

[Bug 198123] Console is the wrong color at boot with radeon 6670

[bugzilla-daemon]

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

--- Comment #45 from sh...@tuta.io ---
Created attachment 274815
  --> https://bugzilla.kernel.org/attachment.cgi?id=274815=edit
radeonreg grey background

Linux 4.15.10-1-ARCH SMP PREEMPT x86_64

I made 11 dumps from different boots and selected one that has the most bits in
common with other dumps. The console background is light grey on most of these
boots, but there were a couple of dark grey. The kernel, modules, and the
command line are the same as for the black dumps.

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