Re: [PATCH] dma-buf: fix reservation_object_wait_timeout_rcu once more v2
Am 22.01.2018 um 21:09 schrieb Chris Wilson:
Quoting Christian König (2018-01-22 20:00:03)
We need to set shared_count even if we already have a fence to wait for.
v2: init i to -1 as well
Signed-off-by: Christian König
Cc: sta...@vger.kernel.org
Tested-by: Lyude Paul
Reviewed-by: Lyude Paul
---
drivers/dma-buf/reservation.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index 461afa9febd4..314eb1071cce 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -484,13 +484,15 @@ long reservation_object_wait_timeout_rcu(struct
reservation_object *obj,
unsigned long timeout)
{
struct dma_fence *fence;
- unsigned seq, shared_count, i = 0;
+ unsigned seq, shared_count;
long ret = timeout ? timeout : 1;
+ int i;
retry:
shared_count = 0;
seq = read_seqcount_begin(&obj->seq);
rcu_read_lock();
+ i = -1;
Could be before the seqlock, but
Reviewed-by: Chris Wilson
Are we at the point where just grabbing the snapshot of fences with your
new get_fences_rcu() returning a single array will be simpler? (It also
has the change in behaviour of not updating the snapshot across the long
lived wait.)
Yeah, thought about that as well.
If you want to avoid the kmalloc, we could teach it populate the
caller's stack allocated array first.
Something like a helper function which just grabs all fences and puts
them in an array of size n? And if the array is to small we return
-ENOSPC and the caller needs to resize it.
Good idea, putting this on my TODO list, but no idea when I can get
around to actually doing it.
Christian.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104723] [CI] igt@[kms_3d|igt@kms_panel_fitting] - fail - Could not open data file "1080p-left.png": No such file or directoryReceived signal SIGSEGV.
https://bugs.freedesktop.org/show_bug.cgi?id=104723 --- Comment #4 from Marta Löfstedt --- The issue is now hidden since we are currently building with autotools. I will archive the bug from cibuglog, but the bug should remain open until the patch is merged and tested on a Meson based build. -- 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
[RFC][PATCH] HACK: drm_atomic: Don't try to set vblank if crtc isn't active
In trying to use the drm_hwcomposer on HiKey, I found things
wouldn't initialize due to the following check in
drm_atomic_crtc_check() failing:
if (state->event && !state->active && !crtc->state->active) {
DRM_DEBUG_ATOMIC("[CRTC:%d:%s] requesting event but off\n",
crtc->base.id, crtc->name);
return -EINVAL;
}
This case fails because the crtc_state hasn't been set to active
yet.
However, this trips on the first call to drm_atomic_commit(),
where the drm_hwcomposer is trying to setup the initial mode.
Digging further its seems the state->event value is set because
before we get into handling the atomic mode, we call
prepare_crtc_signaling(), which sees a fence ptr, and calls
create_vblank_event().
So to hack around this, I've added a check in
prepare_crtc_signaling() to see if the crtc_state is active and
if not, skip trying to create the vblank event.
I suspect this isn't correct, but I'm a bit confused on what the
right solution is. I was thinking the drm_hwcomposer was missing
something to enable the display before calling
drmModeAtomicCommit(), but as I look at the logic it seems that
should be ok. I'm starting to suspect I only see this issue
because I don't have the framebuffer console enabled, so the
kernel has yet to initialize the crtc, and that's probably not
commonly used.
Any thoughts or feedback on a better approach to solving this
issue would be greatly appreciated!
Cc: Marissa Wall
Cc: Sean Paul
Cc: Dmitry Shmidt
Cc: Matt Szczesiak
Cc: Liviu Dudau
Cc: David Hanna
Cc: Rob Herring
Cc: Sumit Semwal
Cc: Robert Foss
Cc: Gustavo Padovan
Cc: Rob Clark
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz
---
drivers/gpu/drm/drm_atomic.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index c2da558..e6404b2 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -2072,6 +2072,9 @@ static int prepare_crtc_signaling(struct drm_device *dev,
for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
s32 __user *fence_ptr;
+ if (!crtc_state->active)
+ continue;
+
fence_ptr = get_out_fence_for_crtc(crtc_state->state, crtc);
if (arg->flags & DRM_MODE_PAGE_FLIP_EVENT || fence_ptr) {
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/sun4i: Handle DRM_MODE_FLAG_**SYNC_POSITIVE correctly
Hi, Il 22/01/2018 09:51, Maxime Ripard ha scritto: On Sat, Jan 20, 2018 at 07:50:21PM +0100, Giulio Benetti wrote: On previous handling, if specified DRM_MODE_FLAG_N*SYNC, it was ignored, because only PHSYNC and PVSYNC were taken into account. DRM_MODE_FLAG_P*SYNC and DRM_MODE_FLAG_N*SYNC are not exclusive. If flags contains PVSYNC, it doesn't mean it is NVSYNC. And it's true also the contrary. Also, as I've checked with scope on A20, if (flags & PVSYNC) then SUN4I_TCON0_IO_POL_VSYNC_POSITIVE must be set, as name suggests. It seems all display io polarities starts inverted if 0. Signed-off-by: Giulio Benetti PVSYNC and PHSYNC only Signed-off-by: Giulio Benetti Checkpatch: WARNING: Duplicate signature Sorry I didn't use ./scripts/checkpatch.pl --- drivers/gpu/drm/sun4i/sun4i_tcon.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c index 6121210..e873a37 100644 --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c @@ -224,10 +224,10 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon *tcon, SUN4I_TCON0_BASIC3_H_SYNC(hsync)); /* Setup the polarity of the various signals */ - if (!(mode->flags & DRM_MODE_FLAG_PHSYNC)) + if (mode->flags & DRM_MODE_FLAG_PHSYNC) val |= SUN4I_TCON0_IO_POL_HSYNC_POSITIVE; - if (!(mode->flags & DRM_MODE_FLAG_PVSYNC)) + if (mode->flags & DRM_MODE_FLAG_PVSYNC) val |= SUN4I_TCON0_IO_POL_VSYNC_POSITIVE; I'm not sure why you were talking of the differences between NVSYNC and PVSYNC if you're not making use of any of it here? Thinking about it more now, the point is that all Lcd IOs seem to be inverted by default(at least on A20). With inverted, I mean that if for example PVSYNC, I should see vsync line low and when asserted to give VSync, it goes high. This is what I've checked with oscilloscope on A20. Can someone give a try on A33? Otherwise I will, but I will take some time. On uboot, everything is treated equal to kernel, but to have my falling edge dclk and low h/vsync I had to specify: CONFIG_VIDEO_LCD_DCLK_PHASE=0 (giving me falling edge on dclk) and CONFIG_VIDEO_LCD_MODE=",sync:3,..." but digging into code, I see "sync:3" means H/VSYNC HIGH, but I experience both LOW during their pulse. Also, how was it tested? This seems quite weird that we haven't caught that one sooner, and I'm a bit worried about the possible regressions here. It sounds really strange to me too, because everybody under uboot use "sync:3"(HIGH). I will retry to measure, unfortunately at home I don't have a scope, but I think I'm going to have one soon, because of this. :) Maxime -- Giulio Benetti R&D Manager & Advanced Research MICRONOVA SRL Sede: Via A. Niedda 3 - 35010 Vigonza (PD) Tel. 049/8931563 - Fax 049/8931346 Cod.Fiscale - P.IVA 02663420285 Capitale Sociale € 26.000 i.v. Iscritta al Reg. Imprese di Padova N. 02663420285 Numero R.E.A. 258642 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: panels: lvds: fix driver description heading
Cc: Laurent Pinchart Signed-off-by: Baruch Siach --- drivers/gpu/drm/panel/panel-lvds.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/panel/panel-lvds.c b/drivers/gpu/drm/panel/panel-lvds.c index e2d57c01200b..e651bf07df9a 100644 --- a/drivers/gpu/drm/panel/panel-lvds.c +++ b/drivers/gpu/drm/panel/panel-lvds.c @@ -1,5 +1,5 @@ /* - * rcar_du_crtc.c -- R-Car Display Unit CRTCs + * Generic LVDS panel driver * * Copyright (C) 2016 Laurent Pinchart * Copyright (C) 2016 Renesas Electronics Corporation -- 2.15.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104738] Radeon HD 6970M/6990M crash on iMac on boot - only nomodeset helps
https://bugs.freedesktop.org/show_bug.cgi?id=104738 --- Comment #1 from Michel Dänzer --- Does radeon.uvd=0 on the kernel command line help? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/sun4i: Fix build warnings in sunxi_engine.h
On Mon, Jan 22, 2018 at 12:42:59PM -0500, Sean Paul wrote:
> Fixes the following build warnings:
> In file included from ../drivers/gpu/drm/sun4i/sun8i_mixer.h:18:0,
> from ../drivers/gpu/drm/sun4i/sun8i_vi_scaler.h:13,
> from ../drivers/gpu/drm/sun4i/sun8i_vi_scaler.c:12:
> ../drivers/gpu/drm/sun4i/sunxi_engine.h:36:16: warning: ‘struct
> drm_crtc_state’ declared inside parameter list will not be visible outside of
> this definition or declaration
> struct drm_crtc_state *old_state);
> ^~
> ../drivers/gpu/drm/sun4i/sunxi_engine.h:53:15: warning: ‘struct
> drm_crtc_state’ declared inside parameter list will not be visible outside of
> this definition or declaration
> struct drm_crtc_state *state);
>^~
> In file included from ../drivers/gpu/drm/sun4i/sun8i_mixer.h:18:0,
> from ../drivers/gpu/drm/sun4i/sun8i_ui_scaler.h:12,
> from ../drivers/gpu/drm/sun4i/sun8i_ui_scaler.c:12:
> ../drivers/gpu/drm/sun4i/sunxi_engine.h:36:16: warning: ‘struct
> drm_crtc_state’ declared inside parameter list will not be visible outside of
> this definition or declaration
> struct drm_crtc_state *old_state);
> ^~
> ../drivers/gpu/drm/sun4i/sunxi_engine.h:53:15: warning: ‘struct
> drm_crtc_state’ declared inside parameter list will not be visible outside of
> this definition or declaration
> struct drm_crtc_state *state);
>^~
>
> Fixes: 6b8562c86e24 ("drm/sun4i: engine: Create an atomic_begin
> callback")
> Fixes: 656e5f654903 ("drm/sun4i: engine: Add a custom crtc
> atomic_check")
> Cc: Chen-Yu Tsai
> Cc: Neil Armstrong
> Cc: Maxime Ripard
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-arm-ker...@lists.infradead.org
> Signed-off-by: Sean Paul
Sorry for that, I just pushed it.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v18 01/10] video: backlight: Add helpers to enable and disable backlight
On Mon, Jan 22, 2018 at 02:49:28PM +, Meghana Madhyastha wrote:
> Add helper functions backlight_enable and backlight_disable to
> enable/disable a backlight device. These helper functions can
> then be used by different drm and tinydrm drivers to avoid
> repetition of code and also to enforce a uniform and consistent
> way to enable/disable a backlight device.
>
> Signed-off-by: Meghana Madhyastha
> ---
> Acked-by: Daniel Thompson
> Reviewed-by: Noralf Trønnes
> Reviewed-by: Sean Paul
Just in case there's another spin... the additional tags are normally
presented above the --- (otherwise they are unlikely to be copied into
the git history when they are applied).
Daniel.
>
> include/linux/backlight.h | 32
> 1 file changed, 32 insertions(+)
>
> diff --git a/include/linux/backlight.h b/include/linux/backlight.h
> index af7003548..ace825e2c 100644
> --- a/include/linux/backlight.h
> +++ b/include/linux/backlight.h
> @@ -130,6 +130,38 @@ static inline int backlight_update_status(struct
> backlight_device *bd)
> return ret;
> }
>
> +/**
> + * backlight_enable - Enable backlight
> + * @bd: the backlight device to enable
> + */
> +static inline int backlight_enable(struct backlight_device *bd)
> +{
> + if (!bd)
> + return 0;
> +
> + bd->props.power = FB_BLANK_UNBLANK;
> + bd->props.fb_blank = FB_BLANK_UNBLANK;
> + bd->props.state &= ~BL_CORE_FBBLANK;
> +
> + return backlight_update_status(bd);
> +}
> +
> +/**
> + * backlight_disable - Disable backlight
> + * @bd: the backlight device to disable
> + */
> +static inline int backlight_disable(struct backlight_device *bd)
> +{
> + if (!bd)
> + return 0;
> +
> + bd->props.power = FB_BLANK_POWERDOWN;
> + bd->props.fb_blank = FB_BLANK_POWERDOWN;
> + bd->props.state |= BL_CORE_FBBLANK;
> +
> + return backlight_update_status(bd);
> +}
> +
> extern struct backlight_device *backlight_device_register(const char *name,
> struct device *dev, void *devdata, const struct backlight_ops *ops,
> const struct backlight_properties *props);
> --
> 2.11.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/bridge/sii8620: fix display modes validation
Current implementation of mode_valid() and mode_fixup() callbacks
handle packed pixel modes improperly.
Fix it by using proper maximum clock values from the documentation.
Signed-off-by: Maciej Purski
---
drivers/gpu/drm/bridge/sil-sii8620.c | 90
1 file changed, 51 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c
b/drivers/gpu/drm/bridge/sil-sii8620.c
index 5168783..1718c2e 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -34,8 +34,11 @@
#define SII8620_BURST_BUF_LEN 288
#define VAL_RX_HDMI_CTRL2_DEFVAL VAL_RX_HDMI_CTRL2_IDLE_CNT(3)
-#define MHL1_MAX_LCLK 225000
-#define MHL3_MAX_LCLK 60
+
+#define MHL1_MAX_PCLK 75000
+#define MHL1_MAX_PCLK_PP_MODE 15
+#define MHL3_MAX_PCLK 20
+#define MHL3_MAX_PCLK_PP_MODE 30
enum sii8620_mode {
CM_DISCONNECTED,
@@ -2123,61 +2126,70 @@ static void sii8620_detach(struct drm_bridge *bridge)
rc_unregister_device(ctx->rc_dev);
}
+static int sii8620_is_packing_required(struct sii8620 *ctx,
+const struct drm_display_mode *mode)
+{
+ int ret;
+
+ if (sii8620_is_mhl3(ctx)) {
+ if (mode->clock < MHL3_MAX_PCLK)
+ ret = 0;
+ else if (mode->clock < MHL3_MAX_PCLK_PP_MODE)
+ ret = 1;
+ else
+ ret = -1;
+ } else {
+ if (mode->clock < MHL1_MAX_PCLK)
+ ret = 0;
+ else if (mode->clock < MHL1_MAX_PCLK_PP_MODE)
+ ret = 1;
+ else
+ ret = -1;
+ }
+
+ return ret;
+}
+
static enum drm_mode_status sii8620_mode_valid(struct drm_bridge *bridge,
const struct drm_display_mode *mode)
{
+ enum drm_mode_status ret;
struct sii8620 *ctx = bridge_to_sii8620(bridge);
+ int pack_required = sii8620_is_packing_required(ctx, mode);
bool can_pack = ctx->devcap[MHL_DCAP_VID_LINK_MODE] &
MHL_DCAP_VID_LINK_PPIXEL;
- unsigned int max_pclk = sii8620_is_mhl3(ctx) ? MHL3_MAX_LCLK :
- MHL1_MAX_LCLK;
- max_pclk /= can_pack ? 2 : 3;
- return (mode->clock > max_pclk) ? MODE_CLOCK_HIGH : MODE_OK;
+ switch (pack_required) {
+ case -1:
+ ret = MODE_CLOCK_HIGH;
+ break;
+ case 1:
+ ret = (can_pack) ? MODE_OK : MODE_CLOCK_HIGH;
+ break;
+ case 0:
+ ret = MODE_OK;
+ break;
+ }
+
+ return ret;
}
+
static bool sii8620_mode_fixup(struct drm_bridge *bridge,
const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode)
{
struct sii8620 *ctx = bridge_to_sii8620(bridge);
- int max_lclk;
- bool ret = true;
mutex_lock(&ctx->lock);
- max_lclk = sii8620_is_mhl3(ctx) ? MHL3_MAX_LCLK : MHL1_MAX_LCLK;
- if (max_lclk > 3 * adjusted_mode->clock) {
- ctx->use_packed_pixel = 0;
- goto end;
- }
- if ((ctx->devcap[MHL_DCAP_VID_LINK_MODE] & MHL_DCAP_VID_LINK_PPIXEL) &&
- max_lclk > 2 * adjusted_mode->clock) {
- ctx->use_packed_pixel = 1;
- goto end;
- }
- ret = false;
-end:
- if (ret) {
- u8 vic = drm_match_cea_mode(adjusted_mode);
-
- if (!vic) {
- union hdmi_infoframe frm;
- u8 mhl_vic[] = { 0, 95, 94, 93, 98 };
-
- /* FIXME: We need the connector here */
- drm_hdmi_vendor_infoframe_from_display_mode(
- &frm.vendor.hdmi, NULL, adjusted_mode);
- vic = frm.vendor.hdmi.vic;
- if (vic >= ARRAY_SIZE(mhl_vic))
- vic = 0;
- vic = mhl_vic[vic];
- }
- ctx->video_code = vic;
- ctx->pixel_clock = adjusted_mode->clock;
- }
+ ctx->use_packed_pixel = sii8620_is_packing_required(ctx, adjusted_mode);
+ ctx->video_code = drm_match_cea_mode(adjusted_mode);
+ ctx->pixel_clock = adjusted_mode->clock;
+
mutex_unlock(&ctx->lock);
- return ret;
+
+ return true;
}
static const struct drm_bridge_funcs sii8620_bridge_funcs = {
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Nouveau] [PATCH] drm/nouveau/mmu: Fix trailing semicolon
Reviewed-by: Karol Herbst
On Wed, Jan 17, 2018 at 7:53 PM, Luis de Bethencourt wrote:
> The trailing semicolon is an empty statement that does no operation.
> Removing it since it doesn't do anything.
>
> Signed-off-by: Luis de Bethencourt
> ---
>
> Hi,
>
> After fixing the same thing in drivers/staging/rtl8723bs/, Joe Perches
> suggested I fix it treewide [0].
>
> Best regards
> Luis
>
>
> [0]
> http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2018-January/115410.html
> [1]
> http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2018-January/115390.html
>
> drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c
> index e35d3e17cd7c..93946dcee319 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c
> @@ -642,7 +642,7 @@ nvkm_vmm_ptes_sparse(struct nvkm_vmm *vmm, u64 addr, u64
> size, bool ref)
> else
> block = (size >> page[i].shift) <<
> page[i].shift;
> } else {
> - block = (size >> page[i].shift) << page[i].shift;;
> + block = (size >> page[i].shift) << page[i].shift;
> }
>
> /* Perform operation. */
> --
> 2.15.1
>
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge/synopsys: dsi: Adopt SPDX identifiers
Hi Laurent, A big *thank* for your review On 01/23/2018 12:30 AM, Laurent Pinchart wrote: > Hi Philippe, > > Thank you for the patch. > > On Monday, 22 January 2018 12:26:08 EET Philippe Cornu wrote: >> Add SPDX identifiers to the Synopsys DesignWare MIPI DSI >> host controller driver. >> >> Signed-off-by: Philippe Cornu >> --- >> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 6 +- >> 1 file changed, 1 insertion(+), 5 deletions(-) >> >> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c >> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c index >> 46b0e73404d1..e06836dec77c 100644 >> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c >> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c >> @@ -1,12 +1,8 @@ >> +// SPDX-License-Identifier: GPL-2.0 > > According to Documentation/process/license-rules.txt this would change the > existing license. The correct identifier is GPL-2.0+. > You are right, I did not put the correct identifier :( After reading more spdx.org, I wonder if the correct value should be GPL-2.0-or-later instead of GPL-2.0+ https://spdx.org/licenses/GPL-2.0-or-later.html https://spdx.org/licenses/GPL-2.0+.html What is your opinion? Many thanks, Philippe :-) >> /* >>* Copyright (c) 2016, Fuzhou Rockchip Electronics Co., Ltd >>* Copyright (C) STMicroelectronics SA 2017 >>* >> - * This program is free software; you can redistribute it and/or modify >> - * it under the terms of the GNU General Public License as published by >> - * the Free Software Foundation; either version 2 of the License, or >> - * (at your option) any later version. >> - * >>* Modified by Philippe Cornu >>* This generic Synopsys DesignWare MIPI DSI host driver is based on the >>* Rockchip version from rockchip/dw-mipi-dsi.c with phy & bridge APIs. > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/bridge/sii8620: fix display of packed pixel modes in MHL2
Currently packed pixel modes in MHL2 can't be displayed. The device
automatically recognizes output format, so setting format other than
RGB causes failure. Fix it by writing proper values to registers.
Tested on MHL1 and MHL2 using various vendors' dongles both in
DVI and HDMI mode.
Signed-off-by: Maciej Purski
---
drivers/gpu/drm/bridge/sil-sii8620.c | 17 +
1 file changed, 1 insertion(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c
b/drivers/gpu/drm/bridge/sil-sii8620.c
index 1718c2e..e13708d 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -1005,20 +1005,11 @@ static void sii8620_stop_video(struct sii8620 *ctx)
static void sii8620_set_format(struct sii8620 *ctx)
{
- u8 out_fmt;
-
if (sii8620_is_mhl3(ctx)) {
sii8620_setbits(ctx, REG_M3_P0CTRL,
BIT_M3_P0CTRL_MHL3_P0_PIXEL_MODE_PACKED,
ctx->use_packed_pixel ? ~0 : 0);
} else {
- if (ctx->use_packed_pixel)
- sii8620_write_seq_static(ctx,
- REG_VID_MODE, BIT_VID_MODE_M1080P,
- REG_MHL_TOP_CTL, BIT_MHL_TOP_CTL_MHL_PP_SEL | 1,
- REG_MHLTX_CTL6, 0x60
- );
- else
sii8620_write_seq_static(ctx,
REG_VID_MODE, 0,
REG_MHL_TOP_CTL, 1,
@@ -1026,15 +1017,9 @@ static void sii8620_set_format(struct sii8620 *ctx)
);
}
- if (ctx->use_packed_pixel)
- out_fmt = VAL_TPI_FORMAT(YCBCR422, FULL) |
- BIT_TPI_OUTPUT_CSCMODE709;
- else
- out_fmt = VAL_TPI_FORMAT(RGB, FULL);
-
sii8620_write_seq(ctx,
REG_TPI_INPUT, VAL_TPI_FORMAT(RGB, FULL),
- REG_TPI_OUTPUT, out_fmt,
+ REG_TPI_OUTPUT, VAL_TPI_FORMAT(RGB, FULL),
);
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:amd-staging-drm-next 1493/1624] sound/soc//amd/raven/acp3x-pcm-dma.c:638:22: error: implicit declaration of function 'devm_ioremap'; did you mean 'of_ioremap'?
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: 052e3ef222d2d8b0819aaf07e0063b5a0ea72762
commit: 4ab7d004f9ff2e877caa267887360e1804b4edcf [1493/1624] ASoC: AMD: enable
ACP3x drivers build
config: sparc64-allmodconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 4ab7d004f9ff2e877caa267887360e1804b4edcf
# save the attached .config to linux build tree
make.cross ARCH=sparc64
All errors (new ones prefixed by >>):
In file included from sound/soc//amd/raven/acp3x-pcm-dma.c:26:0:
sound/soc//amd/raven/acp3x.h: In function 'rv_readl':
sound/soc//amd/raven/acp3x.h:28:9: error: implicit declaration of function
'readl'; did you mean 'vread'? [-Werror=implicit-function-declaration]
return readl(base_addr - ACP3x_PHY_BASE_ADDRESS);
^
vread
sound/soc//amd/raven/acp3x.h: In function 'rv_writel':
sound/soc//amd/raven/acp3x.h:33:2: error: implicit declaration of function
'writel'; did you mean 'vwrite'? [-Werror=implicit-function-declaration]
writel(val, base_addr - ACP3x_PHY_BASE_ADDRESS);
^~
vwrite
sound/soc//amd/raven/acp3x-pcm-dma.c: In function 'acp3x_audio_probe':
>> sound/soc//amd/raven/acp3x-pcm-dma.c:638:22: error: implicit declaration of
>> function 'devm_ioremap'; did you mean 'of_ioremap'?
>> [-Werror=implicit-function-declaration]
adata->acp3x_base = devm_ioremap(&pdev->dev, res->start,
^~~~
of_ioremap
sound/soc//amd/raven/acp3x-pcm-dma.c:638:20: warning: assignment makes
pointer from integer without a cast [-Wint-conversion]
adata->acp3x_base = devm_ioremap(&pdev->dev, res->start,
^
cc1: some warnings being treated as errors
vim +638 sound/soc//amd/raven/acp3x-pcm-dma.c
023ab7b3 Maruthi Srinivas Bayyavarapu 2017-03-29 616
023ab7b3 Maruthi Srinivas Bayyavarapu 2017-03-29 617 static int
acp3x_audio_probe(struct platform_device *pdev)
023ab7b3 Maruthi Srinivas Bayyavarapu 2017-03-29 618 {
023ab7b3 Maruthi Srinivas Bayyavarapu 2017-03-29 619 int status;
023ab7b3 Maruthi Srinivas Bayyavarapu 2017-03-29 620 struct resource *res;
023ab7b3 Maruthi Srinivas Bayyavarapu 2017-03-29 621 struct i2s_dev_data
*adata;
023ab7b3 Maruthi Srinivas Bayyavarapu 2017-03-29 622 unsigned int irqflags;
023ab7b3 Maruthi Srinivas Bayyavarapu 2017-03-29 623
023ab7b3 Maruthi Srinivas Bayyavarapu 2017-03-29 624 if
(pdev->dev.platform_data == NULL) {
023ab7b3 Maruthi Srinivas Bayyavarapu 2017-03-29 625
dev_err(&pdev->dev, "platform_data not retrieved\n");
023ab7b3 Maruthi Srinivas Bayyavarapu 2017-03-29 626 return -ENODEV;
023ab7b3 Maruthi Srinivas Bayyavarapu 2017-03-29 627 }
023ab7b3 Maruthi Srinivas Bayyavarapu 2017-03-29 628 irqflags = *((unsigned
int *)(pdev->dev.platform_data));
023ab7b3 Maruthi Srinivas Bayyavarapu 2017-03-29 629
023ab7b3 Maruthi Srinivas Bayyavarapu 2017-03-29 630 adata =
devm_kzalloc(&pdev->dev, sizeof(struct i2s_dev_data),
023ab7b3 Maruthi Srinivas Bayyavarapu 2017-03-29 631
GFP_KERNEL);
023ab7b3 Maruthi Srinivas Bayyavarapu 2017-03-29 632 res =
platform_get_resource(pdev, IORESOURCE_MEM, 0);
023ab7b3 Maruthi Srinivas Bayyavarapu 2017-03-29 633 if (!res) {
023ab7b3 Maruthi Srinivas Bayyavarapu 2017-03-29 634
dev_err(&pdev->dev, "IORESOURCE_IRQ FAILED\n");
023ab7b3 Maruthi Srinivas Bayyavarapu 2017-03-29 635 return
-ENODEV;
023ab7b3 Maruthi Srinivas Bayyavarapu 2017-03-29 636 }
023ab7b3 Maruthi Srinivas Bayyavarapu 2017-03-29 637
023ab7b3 Maruthi Srinivas Bayyavarapu 2017-03-29 @638 adata->acp3x_base =
devm_ioremap(&pdev->dev, res->start,
023ab7b3 Maruthi Srinivas Bayyavarapu 2017-03-29 639
resource_size(res));
023ab7b3 Maruthi Srinivas Bayyavarapu 2017-03-29 640
090795ff Maruthi Srinivas Bayyavarapu 2017-03-30 641 res =
platform_get_resource(pdev, IORESOURCE_IRQ, 0);
090795ff Maruthi Srinivas Bayyavarapu 2017-03-30 642 if (!res) {
090795ff Maruthi Srinivas Bayyavarapu 2017-03-30 643
dev_err(&pdev->dev, "IORESOURCE_IRQ FAILED\n");
090795ff Maruthi Srinivas Bayyavarapu 2017-03-30 644 return -ENODEV;
090795ff Maruthi Srinivas Bayyavarapu 2017-03-30 645 }
090795ff Maruthi Srinivas Bayyavarapu 2017-03-30 646
090795ff Maruthi Srinivas Bayyavarapu 2017-03-30 647 adata->i2s_irq =
res->start;
023ab7b3 Maruthi Srinivas Bayyavarapu 2017-03-29 648 adata->play_stream =
NULL;
023ab7b3 Maruthi Srinivas Bayyavarapu 2017-03-29 649 adata->capture_stream =
NULL;
023ab7b3 Maruthi Srinivas Bayyavarapu 2017-03-29 650
023ab7b3 Maruthi Srinivas Bayyavarapu 2017-03-29 651
dev_set_drvdata(&pdev->de
[PATCH v2] drm/bridge/sii8620: fix HDMI cable connection to dongle
MHL bridge is usually connected to TV via MHL dongle. Currently plugging
HDMI cable to dongle is handled improperly.
Fix it by splitting connecting of a dongle and a HDMI cable. The driver
should now handle unplugging a sink from a dongle and plugging a
different sink with new edid.
Tested on MHL1, MHL2 and MHL3 using various vendors' dongles both in
DVI and HDMI mode.
Signed-off-by: Maciej Purski
---
Changes in v2:
- handle MHL1 and MHL2 initialization sequence
- rename hpd_plugged() function to identify_sink(), as it is now used
in different contexts
- fix commit message
---
drivers/gpu/drm/bridge/sil-sii8620.c | 64 +++-
1 file changed, 41 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c
b/drivers/gpu/drm/bridge/sil-sii8620.c
index 46ccceb..5168783 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -78,6 +78,9 @@ struct sii8620 {
u8 devcap[MHL_DCAP_SIZE];
u8 xdevcap[MHL_XDC_SIZE];
u8 avif[HDMI_INFOFRAME_SIZE(AVI)];
+ bool feature_complete;
+ bool devcap_read;
+ bool sink_detected;
struct edid *edid;
unsigned int gen2_write_burst:1;
enum sii8620_mt_state mt_state;
@@ -470,7 +473,7 @@ static void sii8620_update_array(u8 *dst, u8 *src, int
count)
}
}
-static void sii8620_sink_detected(struct sii8620 *ctx, int ret)
+static void sii8620_identify_sink(struct sii8620 *ctx)
{
static const char * const sink_str[] = {
[SINK_NONE] = "NONE",
@@ -481,7 +484,7 @@ static void sii8620_sink_detected(struct sii8620 *ctx, int
ret)
char sink_name[20];
struct device *dev = ctx->dev;
- if (ret < 0)
+ if (!ctx->sink_detected || !ctx->devcap_read)
return;
sii8620_fetch_edid(ctx);
@@ -490,6 +493,7 @@ static void sii8620_sink_detected(struct sii8620 *ctx, int
ret)
sii8620_mhl_disconnected(ctx);
return;
}
+ sii8620_set_upstream_edid(ctx);
if (drm_detect_hdmi_monitor(ctx->edid))
ctx->sink_type = SINK_HDMI;
@@ -502,15 +506,6 @@ static void sii8620_sink_detected(struct sii8620 *ctx, int
ret)
sink_str[ctx->sink_type], sink_name);
}
-static void sii8620_edid_read(struct sii8620 *ctx, int ret)
-{
- if (ret < 0)
- return;
-
- sii8620_set_upstream_edid(ctx);
- sii8620_enable_hpd(ctx);
-}
-
static void sii8620_mr_devcap(struct sii8620 *ctx)
{
u8 dcap[MHL_DCAP_SIZE];
@@ -526,6 +521,8 @@ static void sii8620_mr_devcap(struct sii8620 *ctx)
dcap[MHL_DCAP_ADOPTER_ID_H], dcap[MHL_DCAP_ADOPTER_ID_L],
dcap[MHL_DCAP_DEVICE_ID_H], dcap[MHL_DCAP_DEVICE_ID_L]);
sii8620_update_array(ctx->devcap, dcap, MHL_DCAP_SIZE);
+ ctx->devcap_read = true;
+ sii8620_identify_sink(ctx);
}
static void sii8620_mr_xdevcap(struct sii8620 *ctx)
@@ -1491,6 +1488,16 @@ static void sii8620_set_mode(struct sii8620 *ctx, enum
sii8620_mode mode)
);
}
+static void sii8620_hpd_unplugged(struct sii8620 *ctx)
+{
+ sii8620_disable_hpd(ctx);
+ ctx->sink_type = SINK_NONE;
+ ctx->sink_detected = false;
+ ctx->feature_complete = false;
+ kfree(ctx->edid);
+ ctx->edid = NULL;
+}
+
static void sii8620_disconnect(struct sii8620 *ctx)
{
sii8620_disable_gen2_write_burst(ctx);
@@ -1518,7 +1525,7 @@ static void sii8620_disconnect(struct sii8620 *ctx)
REG_MHL_DP_CTL6, 0x2A,
REG_MHL_DP_CTL7, 0x03
);
- sii8620_disable_hpd(ctx);
+ sii8620_hpd_unplugged(ctx);
sii8620_write_seq_static(ctx,
REG_M3_CTRL, VAL_M3_CTRL_MHL3_VALUE,
REG_MHL_COC_CTL1, 0x07,
@@ -1566,10 +1573,8 @@ static void sii8620_disconnect(struct sii8620 *ctx)
memset(ctx->xstat, 0, sizeof(ctx->xstat));
memset(ctx->devcap, 0, sizeof(ctx->devcap));
memset(ctx->xdevcap, 0, sizeof(ctx->xdevcap));
+ ctx->devcap_read = false;
ctx->cbus_status = 0;
- ctx->sink_type = SINK_NONE;
- kfree(ctx->edid);
- ctx->edid = NULL;
sii8620_mt_cleanup(ctx);
}
@@ -1660,9 +1665,6 @@ static void sii8620_status_changed_path(struct sii8620
*ctx)
sii8620_mt_write_stat(ctx, MHL_DST_REG(LINK_MODE),
MHL_DST_LM_CLK_MODE_NORMAL
| MHL_DST_LM_PATH_ENABLED);
- if (!sii8620_is_mhl3(ctx))
- sii8620_mt_read_devcap(ctx, false);
- sii8620_mt_set_cont(ctx, sii8620_sink_detected);
} else {
sii8620_mt_write_stat(ctx, MHL_DST_REG(LINK_MODE),
MHL_DST_LM_CLK_MODE_NORMAL);
@@ -1679,9 +1681,13 @@ static void sii8620_msc_mr_write_stat(struct sii8620
*ctx)
sii8620_update_array(ctx->stat, st, MHL_DST_
[PATCH] drm/pl111: Use max memory bandwidth for resolution
We were previously selecting 1024x768 and 32BPP as the default
set-up for the PL111 consumers.
This does not work on elder systems: the device tree bindings
support a property "max-memory-bandwidth" in bytes/second that
states that if you exceed this the memory bus will saturate.
The result is flickering and unstable images.
Parse the "max-memory-bandwidth" and respect it when
intializing the driver. On the RealView PB11MP we get a nice
1024x768 console with RGB565 as default with this code.
If the device tree does not specify the maximum memory
bandwidth we keep the old assumption that we can support
1024x768, 32BPP.
Signed-off-by: Linus Walleij
---
drivers/gpu/drm/pl111/pl111_drm.h | 1 +
drivers/gpu/drm/pl111/pl111_drv.c | 99 +--
2 files changed, 97 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/pl111/pl111_drm.h
b/drivers/gpu/drm/pl111/pl111_drm.h
index 440f53ebee8c..770ef5ce3645 100644
--- a/drivers/gpu/drm/pl111/pl111_drm.h
+++ b/drivers/gpu/drm/pl111/pl111_drm.h
@@ -56,6 +56,7 @@ struct pl111_drm_dev_private {
struct drm_fbdev_cma *fbdev;
void *regs;
+ u32 memory_bw;
u32 ienb;
u32 ctrl;
/* The pixel clock (a reference to our clock divider off of CLCDCLK). */
diff --git a/drivers/gpu/drm/pl111/pl111_drv.c
b/drivers/gpu/drm/pl111/pl111_drv.c
index 101a9c7db6ff..1b47ee67097d 100644
--- a/drivers/gpu/drm/pl111/pl111_drv.c
+++ b/drivers/gpu/drm/pl111/pl111_drv.c
@@ -58,6 +58,7 @@
#include
#include
#include
+#include
#include
#include
@@ -80,21 +81,107 @@ static const struct drm_mode_config_funcs
mode_config_funcs = {
.atomic_commit = drm_atomic_helper_commit,
};
+/**
+ * pl111_choose_max_resolution() - choose max resolution
+ * @dev: DRM device
+ * @memory_bw: the graphics maximum memory bandwidth in bytes/s
+ * @max_width: returns the maximum width
+ * @max_height: returns the maximum height
+ * @bpp: returns the maximum bips per pixed (32 or 16)
+ *
+ * This function attempts to cut down the maximum supported resolution
+ * to something the system memory bus can handle. The PL111 and pixel
+ * clocks may be able to support higher resolutions and color depths
+ * but as we go up the memory bus get saturated and becomes the
+ * bottleneck for the resolution. On several systems using e.g.
+ * 1024x768 with 32 BPP results in instable flickering images.
+ */
+static void pl111_choose_max_resolution(struct drm_device *dev,
+ u32 memory_bw,
+ int *max_width,
+ int *max_height,
+ unsigned int *bpp)
+{
+ /* No limitations, this is the most aggressive */
+ if (!memory_bw) {
+ *max_width = 1024;
+ *max_height = 768;
+ *bpp = 32;
+ return;
+ }
+
+ /*
+* 1024x768 with RGBX requires a memory bandwidth of
+* 65Mhz * 4 bytes = 26000 bytes per second.
+*/
+ if (memory_bw >= 26000) {
+ *max_width = 1024;
+ *max_height = 768;
+ *bpp = 32;
+ return;
+ }
+
+ /*
+* 800x600 with RGB requires a memory bandwidth of
+* 36Mhz * 4 bytes = 14400 bytes per second. But we
+* assume the user prefer higher resolution over more
+* color depth, so we do not add this mode here.
+*/
+
+ /*
+* 1024x768 with RGB565 requires a memory bandwidth of
+* 65Mhz * 2 bytes = 13000 bytes per second.
+*/
+ if (memory_bw >= 13000) {
+ *max_width = 1024;
+ *max_height = 768;
+ *bpp = 16;
+ return;
+ }
+
+ /*
+* 800x600 with RGB565 requires a memory bandwidth of
+* 36Mhz * 2 bytes = 7200 bytes per second.
+*/
+ if (memory_bw >= 7200) {
+ *max_width = 800;
+ *max_height = 600;
+ *bpp = 16;
+ return;
+ }
+
+ /*
+* 640x480 with RGB565 requires a memory bandwidth of
+* 25.175Mhz * 2 bytes = 5035 bytes per second.
+*/
+ if (memory_bw < 5035)
+ dev_err(dev->dev, "can't even do 640x480 VGA RGB565, proceed
anyway\n");
+
+ *max_width = 640;
+ *max_height = 480;
+ *bpp = 16;
+}
+
static int pl111_modeset_init(struct drm_device *dev)
{
struct drm_mode_config *mode_config;
struct pl111_drm_dev_private *priv = dev->dev_private;
struct drm_panel *panel;
struct drm_bridge *bridge;
+ unsigned int bpp; /* bits per pixel */
int ret = 0;
drm_mode_config_init(dev);
mode_config = &dev->mode_config;
mode_config->funcs = &mode_config_funcs;
mode_config->min_width = 1;
- mode_config->max_width =
Re: [PATCH v18 07/10] drm/panel: Use backlight_enable/disable helpers
Den 22.01.2018 15.54, skrev Meghana Madhyastha:
Use backlight_enable/disable helpers instead of changing
the property and calling backlight_update_status for cleaner
and simpler code and also to avoid repetitions.
Signed-off-by: Meghana Madhyastha
---
Reviewed-by: Noralf Trønnes
drivers/gpu/drm/panel/panel-innolux-p079zca.c | 6 ++
drivers/gpu/drm/panel/panel-jdi-lt070me05000.c | 6 ++
drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c | 10 ++
drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c | 10 ++
4 files changed, 8 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
index 6ba93449f..4c1b29eec 100644
--- a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
+++ b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
@@ -45,8 +45,7 @@ static int innolux_panel_disable(struct drm_panel *panel)
if (!innolux->enabled)
return 0;
- innolux->backlight->props.power = FB_BLANK_POWERDOWN;
- backlight_update_status(innolux->backlight);
+ backlight_disable(innolux->backlight);
err = mipi_dsi_dcs_set_display_off(innolux->link);
if (err < 0)
@@ -151,8 +150,7 @@ static int innolux_panel_enable(struct drm_panel *panel)
if (innolux->enabled)
return 0;
- innolux->backlight->props.power = FB_BLANK_UNBLANK;
- ret = backlight_update_status(innolux->backlight);
+ ret = backlight_enable(innolux->backlight);
if (ret) {
DRM_DEV_ERROR(panel->drm->dev,
"Failed to enable backlight %d\n", ret);
diff --git a/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
b/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
index 5b2340ef7..0a94ab79a 100644
--- a/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
+++ b/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
@@ -192,8 +192,7 @@ static int jdi_panel_disable(struct drm_panel *panel)
if (!jdi->enabled)
return 0;
- jdi->backlight->props.power = FB_BLANK_POWERDOWN;
- backlight_update_status(jdi->backlight);
+ backlight_disable(jdi->backlight);
jdi->enabled = false;
@@ -289,8 +288,7 @@ static int jdi_panel_enable(struct drm_panel *panel)
if (jdi->enabled)
return 0;
- jdi->backlight->props.power = FB_BLANK_UNBLANK;
- backlight_update_status(jdi->backlight);
+ backlight_enable(jdi->backlight);
jdi->enabled = true;
diff --git a/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c b/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c
index 3cce3ca19..072c0fc79 100644
--- a/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c
+++ b/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c
@@ -96,10 +96,7 @@ static int sharp_panel_disable(struct drm_panel *panel)
if (!sharp->enabled)
return 0;
- if (sharp->backlight) {
- sharp->backlight->props.power = FB_BLANK_POWERDOWN;
- backlight_update_status(sharp->backlight);
- }
+ backlight_disable(sharp->backlight);
sharp->enabled = false;
@@ -263,10 +260,7 @@ static int sharp_panel_enable(struct drm_panel *panel)
if (sharp->enabled)
return 0;
- if (sharp->backlight) {
- sharp->backlight->props.power = FB_BLANK_UNBLANK;
- backlight_update_status(sharp->backlight);
- }
+ backlight_enable(sharp->backlight);
sharp->enabled = true;
diff --git a/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c b/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c
index 3aeb0bda4..8a5137963 100644
--- a/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c
+++ b/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c
@@ -117,10 +117,7 @@ static int sharp_nt_panel_disable(struct drm_panel *panel)
if (!sharp_nt->enabled)
return 0;
- if (sharp_nt->backlight) {
- sharp_nt->backlight->props.power = FB_BLANK_POWERDOWN;
- backlight_update_status(sharp_nt->backlight);
- }
+ backlight_disable(sharp_nt->backlight);
sharp_nt->enabled = false;
@@ -203,10 +200,7 @@ static int sharp_nt_panel_enable(struct drm_panel *panel)
if (sharp_nt->enabled)
return 0;
- if (sharp_nt->backlight) {
- sharp_nt->backlight->props.power = FB_BLANK_UNBLANK;
- backlight_update_status(sharp_nt->backlight);
- }
+ backlight_enable(sharp_nt->backlight);
sharp_nt->enabled = true;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v18 08/10] drm/omapdrm: Use backlight_enable/disable helpers
Den 22.01.2018 15.54, skrev Meghana Madhyastha:
Use backlight_enable/disable helpers instead of changing
the property and calling backlight_update_status for cleaner
and simpler code and also to avoid repetitions.
Signed-off-by: Meghana Madhyastha
---
Reviewed-by: Noralf Trønnes
drivers/gpu/drm/omapdrm/displays/panel-dpi.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-dpi.c
b/drivers/gpu/drm/omapdrm/displays/panel-dpi.c
index e065f7e10..ac9596251 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-dpi.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-dpi.c
@@ -87,11 +87,7 @@ static int panel_dpi_enable(struct omap_dss_device *dssdev)
}
gpiod_set_value_cansleep(ddata->enable_gpio, 1);
-
- if (ddata->backlight) {
- ddata->backlight->props.power = FB_BLANK_UNBLANK;
- backlight_update_status(ddata->backlight);
- }
+ backlight_enable(ddata->backlight);
dssdev->state = OMAP_DSS_DISPLAY_ACTIVE;
@@ -106,10 +102,7 @@ static void panel_dpi_disable(struct omap_dss_device *dssdev)
if (!omapdss_device_is_enabled(dssdev))
return;
- if (ddata->backlight) {
- ddata->backlight->props.power = FB_BLANK_POWERDOWN;
- backlight_update_status(ddata->backlight);
- }
+ backlight_disable(ddata->backlight);
gpiod_set_value_cansleep(ddata->enable_gpio, 0);
regulator_disable(ddata->vcc_supply);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 197327] radeon 0000:01:00.0: failed VCE resume (-110).
https://bugzilla.kernel.org/show_bug.cgi?id=197327 mirh (m...@protonmail.ch) changed: What|Removed |Added CC||m...@protonmail.ch --- Comment #3 from mirh (m...@protonmail.ch) --- Duplicate of bug 107381? -- 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 v18 09/10] drm/panel: Use of_find_backlight helper
Den 22.01.2018 15.55, skrev Meghana Madhyastha:
Replace of_find_backlight_by_node and of the code around it
with of_find_backlight helper to avoid repetition of code.
Signed-off-by: Meghana Madhyastha
---
Reviewed-by: Noralf Trønnes
Changes in v18:
-Fixed warnings resulting from passing device_node* to of_find_backlight.
Fixed it by passing struct device* to of_find_backlight
drivers/gpu/drm/panel/panel-innolux-p079zca.c | 24 -
drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c | 28 +
drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c | 27
3 files changed, 13 insertions(+), 66 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
index 4c1b29eec..57df39b5c 100644
--- a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
+++ b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
@@ -215,7 +215,6 @@ MODULE_DEVICE_TABLE(of, innolux_of_match);
static int innolux_panel_add(struct innolux_panel *innolux)
{
struct device *dev = &innolux->link->dev;
- struct device_node *np;
int err;
innolux->supply = devm_regulator_get(dev, "power");
@@ -230,37 +229,22 @@ static int innolux_panel_add(struct innolux_panel
*innolux)
innolux->enable_gpio = NULL;
}
- np = of_parse_phandle(dev->of_node, "backlight", 0);
- if (np) {
- innolux->backlight = of_find_backlight_by_node(np);
- of_node_put(np);
+ innolux->backlight = devm_of_find_backlight(dev);
- if (!innolux->backlight)
- return -EPROBE_DEFER;
- }
+ if (IS_ERR(innolux->backlight))
+ return PTR_ERR(innolux->backlight);
drm_panel_init(&innolux->base);
innolux->base.funcs = &innolux_panel_funcs;
innolux->base.dev = &innolux->link->dev;
- err = drm_panel_add(&innolux->base);
- if (err < 0)
- goto put_backlight;
-
- return 0;
-
-put_backlight:
- put_device(&innolux->backlight->dev);
-
- return err;
+ return drm_panel_add(&innolux->base);
}
static void innolux_panel_del(struct innolux_panel *innolux)
{
if (innolux->base.dev)
drm_panel_remove(&innolux->base);
-
- put_device(&innolux->backlight->dev);
}
static int innolux_panel_probe(struct mipi_dsi_device *dsi)
diff --git a/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c
b/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c
index 072c0fc79..6bf8730f1 100644
--- a/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c
+++ b/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c
@@ -318,8 +318,7 @@ MODULE_DEVICE_TABLE(of, sharp_of_match);
static int sharp_panel_add(struct sharp_panel *sharp)
{
- struct device_node *np;
- int err;
+ struct device *dev = &sharp->link1->dev;
sharp->mode = &default_mode;
@@ -327,30 +326,16 @@ static int sharp_panel_add(struct sharp_panel *sharp)
if (IS_ERR(sharp->supply))
return PTR_ERR(sharp->supply);
- np = of_parse_phandle(sharp->link1->dev.of_node, "backlight", 0);
- if (np) {
- sharp->backlight = of_find_backlight_by_node(np);
- of_node_put(np);
+ sharp->backlight = devm_of_find_backlight(dev);
- if (!sharp->backlight)
- return -EPROBE_DEFER;
- }
+ if (IS_ERR(sharp->backlight))
+ return PTR_ERR(sharp->backlight);
drm_panel_init(&sharp->base);
sharp->base.funcs = &sharp_panel_funcs;
sharp->base.dev = &sharp->link1->dev;
- err = drm_panel_add(&sharp->base);
- if (err < 0)
- goto put_backlight;
-
- return 0;
-
-put_backlight:
- if (sharp->backlight)
- put_device(&sharp->backlight->dev);
-
- return err;
+ return drm_panel_add(&sharp->base);
}
static void sharp_panel_del(struct sharp_panel *sharp)
@@ -358,9 +343,6 @@ static void sharp_panel_del(struct sharp_panel *sharp)
if (sharp->base.dev)
drm_panel_remove(&sharp->base);
- if (sharp->backlight)
- put_device(&sharp->backlight->dev);
-
if (sharp->link2)
put_device(&sharp->link2->dev);
}
diff --git a/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c
b/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c
index 8a5137963..494aa9b16 100644
--- a/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c
+++ b/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c
@@ -253,8 +253,6 @@ static const struct drm_panel_funcs sharp_nt_panel_funcs = {
static int sharp_nt_panel_add(struct sharp_nt_panel *sharp_nt)
{
struct device *dev = &sharp_nt->dsi->dev;
- struct device_node *np;
- int ret;
sharp_nt->mode = &default_mode;
@@ -271,39 +269,22 @@ static int sharp_nt_panel_add(struct sharp_nt_panel *sharp_nt)
gpiod_set_value(sharp_nt->reset
[PATCH v1 2/2] drm/bridge/synopsys: dsi: Add a warning msg on dsi read operations
The DCS/GENERIC DSI read feature is not yet implemented so it
is important to warn the host_transfer() caller in case of
read operation requests.
Signed-off-by: Philippe Cornu
---
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index 096cf5e5bb30..e46ddff8601c 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -417,7 +417,14 @@ static ssize_t dw_mipi_dsi_host_transfer(struct
mipi_dsi_host *host,
if (ret)
return ret;
- nb_bytes = packet.size;
+ if (msg->rx_buf && msg->rx_len > 0) {
+ /* TODO dw drv improvements: implement read feature */
+ dev_warn(dsi->dev, "read operations not yet implemented\n");
+ return -EPERM;
+
+ } else {
+ nb_bytes = packet.size;
+ }
return nb_bytes;
}
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 1/2] drm/bridge/synopsys: dsi: Fix dsi_host_transfer() return value
The dw_mipi_dsi_host_transfer() must return the number of
bytes transmitted/received on success instead of 0.
Note: nb_bytes is introduced in this patch as it will be
re-used with the future dcs/generic dsi read feature.
Signed-off-by: Philippe Cornu
---
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index f458798af788..096cf5e5bb30 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -403,7 +403,7 @@ static ssize_t dw_mipi_dsi_host_transfer(struct
mipi_dsi_host *host,
{
struct dw_mipi_dsi *dsi = host_to_dsi(host);
struct mipi_dsi_packet packet;
- int ret;
+ int ret, nb_bytes;
ret = mipi_dsi_create_packet(&packet, msg);
if (ret) {
@@ -413,7 +413,13 @@ static ssize_t dw_mipi_dsi_host_transfer(struct
mipi_dsi_host *host,
dw_mipi_message_config(dsi, msg);
- return dw_mipi_dsi_write(dsi, &packet);
+ ret = dw_mipi_dsi_write(dsi, &packet);
+ if (ret)
+ return ret;
+
+ nb_bytes = packet.size;
+
+ return nb_bytes;
}
static const struct mipi_dsi_host_ops dw_mipi_dsi_host_ops = {
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 0/2] drm/bridge/synopsys: dsi: Add fix & warning in dsi_host_transfer()
Add a fix & a warning in the dsi_host_transfer(). Philippe Cornu (2): drm/bridge/synopsys: dsi: Fix dsi_host_transfer() return value drm/bridge/synopsys: dsi: Add a warning msg on dsi read operations drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 17 +++-- 1 file changed, 15 insertions(+), 2 deletions(-) -- 2.15.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v18 10/10] drm/omapdrm: Use of_find_backlight helper
Den 22.01.2018 15.56, skrev Meghana Madhyastha:
Replace of_find_backlight_by_node and of the code around it
with of_find_backlight helper to avoid repetition of code.
Signed-off-by: Meghana Madhyastha
---
Changes in v18:
-Fixed warnings resulting from passing device_node* to of_find_backlight.
Fixed it by passing struct device* to of_find_backlight
drivers/gpu/drm/omapdrm/displays/panel-dpi.c | 33 ++--
1 file changed, 11 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-dpi.c
b/drivers/gpu/drm/omapdrm/displays/panel-dpi.c
index ac9596251..93b7a176d 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-dpi.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-dpi.c
@@ -156,14 +156,14 @@ static struct omap_dss_driver panel_dpi_ops = {
static int panel_dpi_probe_of(struct platform_device *pdev)
{
struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+ struct device *dev = &pdev->dev;
struct device_node *node = pdev->dev.of_node;
- struct device_node *bl_node;
struct omap_dss_device *in;
int r;
struct display_timing timing;
struct gpio_desc *gpio;
- gpio = devm_gpiod_get_optional(&pdev->dev, "enable", GPIOD_OUT_LOW);
+ gpio = devm_gpiod_get_optional(dev, "enable", GPIOD_OUT_LOW);
Please don't make unrelated changes like this. It clutters the patch.
You can just as well use &pdev->dev when getting the backlight also.
if (IS_ERR(gpio))
return PTR_ERR(gpio);
@@ -175,47 +175,36 @@ static int panel_dpi_probe_of(struct platform_device *pdev)
* timing and order relative to the enable gpio. So for now it's just
* ensured that the reset line isn't active.
*/
- gpio = devm_gpiod_get_optional(&pdev->dev, "reset", GPIOD_OUT_LOW);
+ gpio = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_LOW);
if (IS_ERR(gpio))
return PTR_ERR(gpio);
- ddata->vcc_supply = devm_regulator_get(&pdev->dev, "vcc");
+ ddata->vcc_supply = devm_regulator_get(dev, "vcc");
if (IS_ERR(ddata->vcc_supply))
return PTR_ERR(ddata->vcc_supply);
- bl_node = of_parse_phandle(node, "backlight", 0);
- if (bl_node) {
- ddata->backlight = of_find_backlight_by_node(bl_node);
- of_node_put(bl_node);
+ ddata->backlight = of_find_backlight(dev);
Any reason you don't use the devm_ version here?
You do remove error_free_backlight...
With the devm_ version remember to drop the put_device in
panel_dpi_remove().
Noralf.
- if (!ddata->backlight)
- return -EPROBE_DEFER;
- }
+ if (IS_ERR(ddata->backlight))
+ return PTR_ERR(ddata->backlight);
r = of_get_display_timing(node, "panel-timing", &timing);
if (r) {
- dev_err(&pdev->dev, "failed to get video timing\n");
- goto error_free_backlight;
+ dev_err(dev, "failed to get video timing\n");
+ return r;
}
videomode_from_timing(&timing, &ddata->vm);
in = omapdss_of_find_source_for_first_ep(node);
if (IS_ERR(in)) {
- dev_err(&pdev->dev, "failed to find video source\n");
- r = PTR_ERR(in);
- goto error_free_backlight;
+ dev_err(dev, "failed to find video source\n");
+ return PTR_ERR(in);
}
ddata->in = in;
return 0;
-
-error_free_backlight:
- if (ddata->backlight)
- put_device(&ddata->backlight->dev);
-
- return r;
}
static int panel_dpi_probe(struct platform_device *pdev)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/dp: Add HBR3 support in existing DRM DP helpers
On 2018-01-22 05:43 PM, Manasi Navare wrote: > Existing helpers add support upto HBR2. This patch > adds support for HBR3 rate (8.1 Gbps) introduced as > part of DP 1.4 specification. > > Cc: Rodrigo Vivi > Cc: Jani Nikula > Cc: dri-devel@lists.freedesktop.org > Signed-off-by: Manasi Navare Both patches look right according to DP 1.4 spec. Series is Reviewed-by: Harry Wentland Harry > --- > drivers/gpu/drm/drm_dp_helper.c | 4 > drivers/gpu/drm/drm_dp_mst_topology.c | 3 +++ > include/drm/drm_dp_helper.h | 1 + > 3 files changed, 8 insertions(+) > > diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c > index adf79be..ffe14ec 100644 > --- a/drivers/gpu/drm/drm_dp_helper.c > +++ b/drivers/gpu/drm/drm_dp_helper.c > @@ -146,6 +146,8 @@ u8 drm_dp_link_rate_to_bw_code(int link_rate) > return DP_LINK_BW_2_7; > case 54: > return DP_LINK_BW_5_4; > + case 81: > + return DP_LINK_BW_8_1; > } > } > EXPORT_SYMBOL(drm_dp_link_rate_to_bw_code); > @@ -161,6 +163,8 @@ int drm_dp_bw_code_to_link_rate(u8 link_bw) > return 27; > case DP_LINK_BW_5_4: > return 54; > + case DP_LINK_BW_8_1: > + return 81; > } > } > EXPORT_SYMBOL(drm_dp_bw_code_to_link_rate); > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c > b/drivers/gpu/drm/drm_dp_mst_topology.c > index 70dcfa5..36df7df 100644 > --- a/drivers/gpu/drm/drm_dp_mst_topology.c > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c > @@ -2087,6 +2087,9 @@ static bool drm_dp_get_vc_payload_bw(int dp_link_bw, > case DP_LINK_BW_5_4: > *out = 10 * dp_link_count; > break; > + case DP_LINK_BW_8_1: > + *out = 15 * dp_link_count; > + break; > } > return true; > } > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h > index 9d3ce3b..c80fa92 100644 > --- a/include/drm/drm_dp_helper.h > +++ b/include/drm/drm_dp_helper.h > @@ -334,6 +334,7 @@ > # define DP_LINK_BW_1_62 0x06 > # define DP_LINK_BW_2_7 0x0a > # define DP_LINK_BW_5_4 0x14/* 1.2 */ > +# define DP_LINK_BW_8_1 0x1e/* 1.4 */ > > #define DP_LANE_COUNT_SET0x101 > # define DP_LANE_COUNT_MASK 0x0f > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v18 01/10] video: backlight: Add helpers to enable and disable backlight
Den 23.01.2018 11.00, skrev Daniel Thompson:
On Mon, Jan 22, 2018 at 02:49:28PM +, Meghana Madhyastha wrote:
Add helper functions backlight_enable and backlight_disable to
enable/disable a backlight device. These helper functions can
then be used by different drm and tinydrm drivers to avoid
repetition of code and also to enforce a uniform and consistent
way to enable/disable a backlight device.
Signed-off-by: Meghana Madhyastha
---
Acked-by: Daniel Thompson
Reviewed-by: Noralf Trønnes
Reviewed-by: Sean Paul
Just in case there's another spin... the additional tags are normally
presented above the --- (otherwise they are unlikely to be copied into
the git history when they are applied).
Indeed, they should be part of the commit message.
Noralf.
Daniel.
include/linux/backlight.h | 32
1 file changed, 32 insertions(+)
diff --git a/include/linux/backlight.h b/include/linux/backlight.h
index af7003548..ace825e2c 100644
--- a/include/linux/backlight.h
+++ b/include/linux/backlight.h
@@ -130,6 +130,38 @@ static inline int backlight_update_status(struct
backlight_device *bd)
return ret;
}
+/**
+ * backlight_enable - Enable backlight
+ * @bd: the backlight device to enable
+ */
+static inline int backlight_enable(struct backlight_device *bd)
+{
+ if (!bd)
+ return 0;
+
+ bd->props.power = FB_BLANK_UNBLANK;
+ bd->props.fb_blank = FB_BLANK_UNBLANK;
+ bd->props.state &= ~BL_CORE_FBBLANK;
+
+ return backlight_update_status(bd);
+}
+
+/**
+ * backlight_disable - Disable backlight
+ * @bd: the backlight device to disable
+ */
+static inline int backlight_disable(struct backlight_device *bd)
+{
+ if (!bd)
+ return 0;
+
+ bd->props.power = FB_BLANK_POWERDOWN;
+ bd->props.fb_blank = FB_BLANK_POWERDOWN;
+ bd->props.state |= BL_CORE_FBBLANK;
+
+ return backlight_update_status(bd);
+}
+
extern struct backlight_device *backlight_device_register(const char *name,
struct device *dev, void *devdata, const struct backlight_ops *ops,
const struct backlight_properties *props);
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104738] Radeon HD 6970M/6990M crash on iMac on boot - only nomodeset helps
https://bugs.freedesktop.org/show_bug.cgi?id=104738 --- Comment #2 from Alex Deucher --- Can you attach your full dmesg output? -- 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: [RFC][PATCH] HACK: drm_atomic: Don't try to set vblank if crtc isn't active
On Tue, Jan 23, 2018 at 12:30:58AM -0800, John Stultz wrote:
> In trying to use the drm_hwcomposer on HiKey, I found things
> wouldn't initialize due to the following check in
> drm_atomic_crtc_check() failing:
>
> if (state->event && !state->active && !crtc->state->active) {
> DRM_DEBUG_ATOMIC("[CRTC:%d:%s] requesting event but off\n",
> crtc->base.id, crtc->name);
> return -EINVAL;
> }
I think the answer is in the comment directly above this code. Having an event
present while the crtc _stays_ off is the problem. So drm_hwc is requesting an
event (or providing a fence) for a crtc which it does not turn on. So I think
you should go back into hwc and find out how this situation arises.
AFAIK, requesting an event in a commit with both a modeset and plane update
should work.
Sean
>
> This case fails because the crtc_state hasn't been set to active
> yet.
>
> However, this trips on the first call to drm_atomic_commit(),
> where the drm_hwcomposer is trying to setup the initial mode.
>
> Digging further its seems the state->event value is set because
> before we get into handling the atomic mode, we call
> prepare_crtc_signaling(), which sees a fence ptr, and calls
> create_vblank_event().
>
> So to hack around this, I've added a check in
> prepare_crtc_signaling() to see if the crtc_state is active and
> if not, skip trying to create the vblank event.
>
> I suspect this isn't correct, but I'm a bit confused on what the
> right solution is. I was thinking the drm_hwcomposer was missing
> something to enable the display before calling
> drmModeAtomicCommit(), but as I look at the logic it seems that
> should be ok. I'm starting to suspect I only see this issue
> because I don't have the framebuffer console enabled, so the
> kernel has yet to initialize the crtc, and that's probably not
> commonly used.
>
> Any thoughts or feedback on a better approach to solving this
> issue would be greatly appreciated!
>
> Cc: Marissa Wall
> Cc: Sean Paul
> Cc: Dmitry Shmidt
> Cc: Matt Szczesiak
> Cc: Liviu Dudau
> Cc: David Hanna
> Cc: Rob Herring
> Cc: Sumit Semwal
> Cc: Robert Foss
> Cc: Gustavo Padovan
> Cc: Rob Clark
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: John Stultz
> ---
> drivers/gpu/drm/drm_atomic.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index c2da558..e6404b2 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -2072,6 +2072,9 @@ static int prepare_crtc_signaling(struct drm_device
> *dev,
> for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
> s32 __user *fence_ptr;
>
> + if (!crtc_state->active)
> + continue;
> +
> fence_ptr = get_out_fence_for_crtc(crtc_state->state, crtc);
>
> if (arg->flags & DRM_MODE_PAGE_FLIP_EVENT || fence_ptr) {
> --
> 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: [PATCH 00/15] drm: More plane clipping polish
On Thu, Nov 23, 2017 at 09:04:47PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > This series first unifies all users of drm_atomic_helper_check_plane_state() > to populate the clip rectangle with drm_mode_get_hv_timing(), and once > everything is unified the clip rectangle handling is sucked into > drm_atomic_helper_check_plane_state() away from driver code. > > Entire series available here: > git://github.com/vsyrjala/linux.git atomic_plane_helper_clip > > Cc: Archit Taneja > Cc: Ben Skeggs > Cc: Brian Starkey > Cc: CK Hu > Cc: Daniel Vetter > Cc: freedr...@lists.freedesktop.org > Cc: Laurent Pinchart > Cc: linux-amlo...@lists.infradead.org > Cc: linux-arm-...@vger.kernel.org > Cc: linux-te...@vger.kernel.org > Cc: Liviu Dudau > Cc: Mali DP Maintainers > Cc: Mark Yao > Cc: Neil Armstrong > Cc: Noralf Trønnes > Cc: nouv...@lists.freedesktop.org > Cc: Philipp Zabel > Cc: Rob Clark > Cc: Shawn Guo > Cc: Sinclair Yeh > Cc: Thierry Reding > Cc: Thomas Hellstrom > Cc: VMware Graphics > > Ville Syrjälä (15): > drm/i915: Reject odd pipe source width with double wide/dual link > drm/i915: Use drm_mode_get_hv_timing() to populate plane clip > rectangle > drm/arm/hdlcd: Use drm_mode_get_hv_timing() to populate plane clip > rectangle > drm/arm/mali-dp: Use drm_mode_get_hv_timing() to populate plane clip > rectangle > drm/simple_kms_helper: Use drm_mode_get_hv_timing() to populate plane > clip rectangle > drm/imx: Use drm_mode_get_hv_timing() to populate plane clip rectangle > drm/mediatek: Use drm_mode_get_hv_timing() to populate plane clip > rectangle > drm/meson: Use drm_mode_get_hv_timing() to populate plane clip > rectangle > drm/msm/mdp5: Use drm_mode_get_hv_timing() to populate plane clip > rectangle > drm/nouveau/kms/nv50: Use drm_mode_get_hv_timing() to populate plane > clip rectangle > drm/rockchip: Use drm_mode_get_hv_timing() to populate plane clip > rectangle > drm/tegra/dc: Use drm_mode_get_hv_timing() to populate plane clip > rectangle > drm/vmwgfx: Use drm_mode_get_hv_timing() to populate plane clip > rectangle > drm/zte: Use drm_mode_get_hv_timing() to populate plane clip rectangle Everything up to here pushed to drm-misc-next. Thanks for the reviews. There have been a few new users of the clip helper so I'll have to take care of those and respin the final patch. Also armada looks broken to me since it has started to use the atomic version of the helper without actually being an atomic driver. So I'll have to figure out what's going on there as well. > drm: Don't pass clip to drm_atomic_helper_check_plane_state() > > drivers/gpu/drm/arm/hdlcd_crtc.c| 6 +- > drivers/gpu/drm/arm/malidp_planes.c | 5 + > drivers/gpu/drm/armada/armada_overlay.c | 2 +- > drivers/gpu/drm/drm_atomic_helper.c | 12 +++- > drivers/gpu/drm/drm_plane_helper.c | 11 +++ > drivers/gpu/drm/drm_simple_kms_helper.c | 5 - > drivers/gpu/drm/i915/intel_atomic_plane.c | 8 > drivers/gpu/drm/i915/intel_display.c| 12 +++- > drivers/gpu/drm/i915/intel_drv.h| 1 - > drivers/gpu/drm/i915/intel_sprite.c | 8 ++-- > drivers/gpu/drm/imx/ipuv3-plane.c | 7 +-- > drivers/gpu/drm/mediatek/mtk_drm_plane.c| 6 +- > drivers/gpu/drm/meson/meson_plane.c | 6 +- > drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 14 ++ > drivers/gpu/drm/nouveau/nv50_display.c | 8 > drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 8 +--- > drivers/gpu/drm/tegra/dc.c | 8 +--- > drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 8 +--- > drivers/gpu/drm/zte/zx_plane.c | 15 +-- > include/drm/drm_atomic_helper.h | 1 - > include/drm/drm_plane_helper.h | 1 - > 21 files changed, 35 insertions(+), 117 deletions(-) > > -- > 2.13.6 -- Ville Syrjälä Intel OTC ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] Documentation/ABI: add sysfs interface for s6e63m0 lcd driver
Document sysfs attributes of s6e63m0 lcd panel driver by looking through git logs and reading code. Signed-off-by: Aishwarya Pant --- Documentation/ABI/testing/sysfs-class-lcd-s6e63m0 | 22 ++ 1 file changed, 22 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-class-lcd-s6e63m0 diff --git a/Documentation/ABI/testing/sysfs-class-lcd-s6e63m0 b/Documentation/ABI/testing/sysfs-class-lcd-s6e63m0 new file mode 100644 index ..db056bd38404 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-lcd-s6e63m0 @@ -0,0 +1,22 @@ +sysfs interface for the S6E63M0 AMOLED LCD panel driver +--- + +What: /sys/class/lcd//gamma_mode +Date: May, 2010 +KernelVersion: v2.6.35 +Contact: Linux kernel mailing list +Description: + (RW) Read or write the gamma mode. Following three modes are + supported: + 0 - gamma value 2.2, + 1 - gamma value 1.9 and + 2 - gamma value 1.7. + + +What: /sys/class/lcd//gamma_table +Date: May, 2010 +KernelVersion: v2.6.35 +Contact: Linux kernel mailing list +Description: + (RO) Displays the size of the gamma table i.e. the number of + gamma modes available. -- 2.16.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Per file OOM badness
On Thu, Jan 18, 2018 at 06:00:06PM +0100, Michal Hocko wrote: > On Thu 18-01-18 11:47:48, Andrey Grodzovsky wrote: > > Hi, this series is a revised version of an RFC sent by Christian König > > a few years ago. The original RFC can be found at > > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_archives_dri-2Ddevel_2015-2DSeptember_089778.html&d=DwIDAw&c=5VD0RTtNlTh3ycd41b3MUw&r=jJYgtDM7QT-W-Fz_d29HYQ&m=R-JIQjy8rqmH5qD581_VYL0Q7cpWSITKOnBCE-3LI8U&s=QZGqKpKuJ2BtioFGSy8_721owcWJ0J6c6d4jywOwN4w&; > Here is the origin cover letter text > : I'm currently working on the issue that when device drivers allocate memory > on > : behalf of an application the OOM killer usually doesn't knew about that > unless > : the application also get this memory mapped into their address space. > : > : This is especially annoying for graphics drivers where a lot of the VRAM > : usually isn't CPU accessible and so doesn't make sense to map into the > : address space of the process using it. > : > : The problem now is that when an application starts to use a lot of VRAM > those > : buffers objects sooner or later get swapped out to system memory, but when > we > : now run into an out of memory situation the OOM killer obviously doesn't > knew > : anything about that memory and so usually kills the wrong process. > : > : The following set of patches tries to address this problem by introducing a > per > : file OOM badness score, which device drivers can use to give the OOM killer > a > : hint how many resources are bound to a file descriptor so that it can make > : better decisions which process to kill. > : > : So question at every one: What do you think about this approach? > : > : My biggest concern right now is the patches are messing with a core kernel > : structure (adding a field to struct file). Any better idea? I'm considering > : to put a callback into file_ops instead. Hello! I wonder if groupoom (aka cgroup-aware OOM killer) can work for you? We do have kmem accounting on the memory cgroup level, and the cgroup-aware OOM selection logic takes cgroup's kmem size into account. So, you don't need to introduce another accounting mechanism for OOM. You can find the current implementation in the mm tree. Thanks! Roman ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Per file OOM badness
On Fri 19-01-18 17:54:36, Christian König wrote: > Am 19.01.2018 um 13:20 schrieb Michal Hocko: > > On Fri 19-01-18 13:13:51, Michal Hocko wrote: > > > On Fri 19-01-18 12:37:51, Christian König wrote: > > > [...] > > > > The per file descriptor badness is/was just the much easier approach to > > > > solve the issue, because the drivers already knew which client is > > > > currently > > > > using which buffer objects. > > > > > > > > I of course agree that file descriptors can be shared between processes > > > > and > > > > are by themselves not killable. But at least for our graphics driven use > > > > case I don't see much of a problem killing all processes when a file > > > > descriptor is used by more than one at the same time. > > > Ohh, I absolutely see why you have chosen this way for your particular > > > usecase. I am just arguing that this would rather be more generic to be > > > merged. If there is absolutely no other way around we can consider it > > > but right now I do not see that all other options have been considered > > > properly. Especially when the fd based approach is basically wrong for > > > almost anybody else. > > And more importantly. Iterating over _all_ fd which is what is your > > approach is based on AFAIU is not acceptable for the OOM path. Even > > though oom_badness is not a hot path we do not really want it to take a > > lot of time either. Even the current iteration over all processes is > > quite time consuming. Now you want to add the number of opened files and > > that might be quite many per process. > > Mhm, crap that is a really good argument. > > How about adding a linked list of callbacks to check for the OOM killer to > check for each process? > > This way we can avoid finding the process where we need to account things on > when memory is allocated and still allow the OOM killer to only check the > specific callbacks it needs to determine the score of a process? I might be oversimplifying but there really have to be a boundary when you have the target user context, no? Then do the accounting when you get data to the user. -- Michal Hocko SUSE Labs ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Per file OOM badness
On Tue 23-01-18 15:27:00, Roman Gushchin wrote: > On Thu, Jan 18, 2018 at 06:00:06PM +0100, Michal Hocko wrote: > > On Thu 18-01-18 11:47:48, Andrey Grodzovsky wrote: > > > Hi, this series is a revised version of an RFC sent by Christian König > > > a few years ago. The original RFC can be found at > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_archives_dri-2Ddevel_2015-2DSeptember_089778.html&d=DwIDAw&c=5VD0RTtNlTh3ycd41b3MUw&r=jJYgtDM7QT-W-Fz_d29HYQ&m=R-JIQjy8rqmH5qD581_VYL0Q7cpWSITKOnBCE-3LI8U&s=QZGqKpKuJ2BtioFGSy8_721owcWJ0J6c6d4jywOwN4w&; > > Here is the origin cover letter text > > : I'm currently working on the issue that when device drivers allocate > > memory on > > : behalf of an application the OOM killer usually doesn't knew about that > > unless > > : the application also get this memory mapped into their address space. > > : > > : This is especially annoying for graphics drivers where a lot of the VRAM > > : usually isn't CPU accessible and so doesn't make sense to map into the > > : address space of the process using it. > > : > > : The problem now is that when an application starts to use a lot of VRAM > > those > > : buffers objects sooner or later get swapped out to system memory, but > > when we > > : now run into an out of memory situation the OOM killer obviously doesn't > > knew > > : anything about that memory and so usually kills the wrong process. > > : > > : The following set of patches tries to address this problem by introducing > > a per > > : file OOM badness score, which device drivers can use to give the OOM > > killer a > > : hint how many resources are bound to a file descriptor so that it can make > > : better decisions which process to kill. > > : > > : So question at every one: What do you think about this approach? > > : > > : My biggest concern right now is the patches are messing with a core kernel > > : structure (adding a field to struct file). Any better idea? I'm > > considering > > : to put a callback into file_ops instead. > > Hello! > > I wonder if groupoom (aka cgroup-aware OOM killer) can work for you? I do not think so. The problem is that the allocating context is not identical with the end consumer. -- Michal Hocko SUSE Labs ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Per file OOM badness
On 2018-01-23 04:36 PM, Michal Hocko wrote: > On Tue 23-01-18 15:27:00, Roman Gushchin wrote: >> On Thu, Jan 18, 2018 at 06:00:06PM +0100, Michal Hocko wrote: >>> On Thu 18-01-18 11:47:48, Andrey Grodzovsky wrote: Hi, this series is a revised version of an RFC sent by Christian König a few years ago. The original RFC can be found at https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_archives_dri-2Ddevel_2015-2DSeptember_089778.html&d=DwIDAw&c=5VD0RTtNlTh3ycd41b3MUw&r=jJYgtDM7QT-W-Fz_d29HYQ&m=R-JIQjy8rqmH5qD581_VYL0Q7cpWSITKOnBCE-3LI8U&s=QZGqKpKuJ2BtioFGSy8_721owcWJ0J6c6d4jywOwN4w&; >>> Here is the origin cover letter text >>> : I'm currently working on the issue that when device drivers allocate >>> memory on >>> : behalf of an application the OOM killer usually doesn't knew about that >>> unless >>> : the application also get this memory mapped into their address space. >>> : >>> : This is especially annoying for graphics drivers where a lot of the VRAM >>> : usually isn't CPU accessible and so doesn't make sense to map into the >>> : address space of the process using it. >>> : >>> : The problem now is that when an application starts to use a lot of VRAM >>> those >>> : buffers objects sooner or later get swapped out to system memory, but >>> when we >>> : now run into an out of memory situation the OOM killer obviously doesn't >>> knew >>> : anything about that memory and so usually kills the wrong process. >>> : >>> : The following set of patches tries to address this problem by introducing >>> a per >>> : file OOM badness score, which device drivers can use to give the OOM >>> killer a >>> : hint how many resources are bound to a file descriptor so that it can make >>> : better decisions which process to kill. >>> : >>> : So question at every one: What do you think about this approach? >>> : >>> : My biggest concern right now is the patches are messing with a core kernel >>> : structure (adding a field to struct file). Any better idea? I'm >>> considering >>> : to put a callback into file_ops instead. >> >> Hello! >> >> I wonder if groupoom (aka cgroup-aware OOM killer) can work for you? > > I do not think so. The problem is that the allocating context is not > identical with the end consumer. That's actually not really true. Even in cases where a BO is shared with a different process, it is still used at least occasionally in the process which allocated it as well. Otherwise there would be no point in sharing it between processes. There should be no problem if the memory of a shared BO is accounted for in each process sharing it. It might be nice to scale each process' "debt" by 1 / (number of processes sharing it) if possible, but in the worst case accounting it fully in each process should be fine. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/arm/malidp: Disable pixel alpha blending for colors that do not have alpha
From: Ayan Halder
Mali dp needs to disable pixel alpha blending (use layer alpha blending) to
display color formats that do not contain alpha bits per pixel
This patch depends on:
"[PATCH v2 01/19] drm/fourcc: Add a alpha field to drm_format_info"
Signed-off-by: Ayan Kumar Halder
---
Change in v2:
- Use struct drm_format_info->has_alpha (boolean) to determine if a color
format has alpha channel
drivers/gpu/drm/arm/malidp_planes.c | 27 ++-
1 file changed, 22 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_planes.c
b/drivers/gpu/drm/arm/malidp_planes.c
index e741979..3b445d9 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -35,6 +35,9 @@
#define LAYER_COMP_MASK (0x3 << 12)
#define LAYER_COMP_PIXEL (0x3 << 12)
#define LAYER_COMP_PLANE (0x2 << 12)
+#define LAYER_ALPHA_OFFSET (16)
+#define LAYER_ALPHA_MASK (0xff)
+#define LAYER_ALPHA(x) (((x) & LAYER_ALPHA_MASK) <<
LAYER_ALPHA_OFFSET)
#define MALIDP_LAYER_COMPOSE 0x008
#define MALIDP_LAYER_SIZE 0x00c
#define LAYER_H_VAL(x) (((x) & 0x1fff) << 0)
@@ -268,6 +271,7 @@ static void malidp_de_plane_update(struct drm_plane *plane,
struct malidp_plane_state *ms = to_malidp_plane_state(plane->state);
u32 src_w, src_h, dest_w, dest_h, val;
int i;
+ bool format_has_alpha = plane->state->fb->format->has_alpha;
mp = to_malidp_plane(plane);
@@ -319,12 +323,25 @@ static void malidp_de_plane_update(struct drm_plane
*plane,
if (plane->state->rotation & DRM_MODE_REFLECT_Y)
val |= LAYER_V_FLIP;
- /*
-* always enable pixel alpha blending until we have a way to change
-* blend modes
-*/
val &= ~LAYER_COMP_MASK;
- val |= LAYER_COMP_PIXEL;
+ if (format_has_alpha) {
+
+ /*
+* always enable pixel alpha blending until we have a way
+* to change blend modes
+*/
+ val |= LAYER_COMP_PIXEL;
+ } else {
+
+ /*
+* do not enable pixel alpha blending as the color channel
+* does not have any alpha information
+*/
+ val |= LAYER_COMP_PLANE;
+
+ /* Set layer alpha coefficient to 0xff ie fully opaque */
+ val |= LAYER_ALPHA(0xff);
+ }
val &= ~LAYER_FLOWCFG(LAYER_FLOWCFG_MASK);
if (plane->state->crtc) {
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v18 10/10] drm/omapdrm: Use of_find_backlight helper
On Tue, Jan 23, 2018 at 03:37:38PM +0100, Noralf Trønnes wrote:
>
> Den 22.01.2018 15.56, skrev Meghana Madhyastha:
> >Replace of_find_backlight_by_node and of the code around it
> >with of_find_backlight helper to avoid repetition of code.
> >
> >Signed-off-by: Meghana Madhyastha
> >---
> >Changes in v18:
> >-Fixed warnings resulting from passing device_node* to of_find_backlight.
> > Fixed it by passing struct device* to of_find_backlight
> >
> > drivers/gpu/drm/omapdrm/displays/panel-dpi.c | 33
> > ++--
> > 1 file changed, 11 insertions(+), 22 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/omapdrm/displays/panel-dpi.c
> >b/drivers/gpu/drm/omapdrm/displays/panel-dpi.c
> >index ac9596251..93b7a176d 100644
> >--- a/drivers/gpu/drm/omapdrm/displays/panel-dpi.c
> >+++ b/drivers/gpu/drm/omapdrm/displays/panel-dpi.c
> >@@ -156,14 +156,14 @@ static struct omap_dss_driver panel_dpi_ops = {
> > static int panel_dpi_probe_of(struct platform_device *pdev)
> > {
> > struct panel_drv_data *ddata = platform_get_drvdata(pdev);
> >+struct device *dev = &pdev->dev;
> > struct device_node *node = pdev->dev.of_node;
> >-struct device_node *bl_node;
> > struct omap_dss_device *in;
> > int r;
> > struct display_timing timing;
> > struct gpio_desc *gpio;
> >-gpio = devm_gpiod_get_optional(&pdev->dev, "enable", GPIOD_OUT_LOW);
> >+gpio = devm_gpiod_get_optional(dev, "enable", GPIOD_OUT_LOW);
>
> Please don't make unrelated changes like this. It clutters the patch.
> You can just as well use &pdev->dev when getting the backlight also.
I had made the change in order to be more consistent with how the other
drivers were doing this. Most of them had a variable struct device *dev.
However, I can undo this if necessary.
> > if (IS_ERR(gpio))
> > return PTR_ERR(gpio);
> >@@ -175,47 +175,36 @@ static int panel_dpi_probe_of(struct platform_device
> >*pdev)
> > * timing and order relative to the enable gpio. So for now it's just
> > * ensured that the reset line isn't active.
> > */
> >-gpio = devm_gpiod_get_optional(&pdev->dev, "reset", GPIOD_OUT_LOW);
> >+gpio = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_LOW);
> > if (IS_ERR(gpio))
> > return PTR_ERR(gpio);
> >-ddata->vcc_supply = devm_regulator_get(&pdev->dev, "vcc");
> >+ddata->vcc_supply = devm_regulator_get(dev, "vcc");
> > if (IS_ERR(ddata->vcc_supply))
> > return PTR_ERR(ddata->vcc_supply);
> >-bl_node = of_parse_phandle(node, "backlight", 0);
> >-if (bl_node) {
> >-ddata->backlight = of_find_backlight_by_node(bl_node);
> >-of_node_put(bl_node);
> >+ddata->backlight = of_find_backlight(dev);
>
> Any reason you don't use the devm_ version here?
> You do remove error_free_backlight...
>
> With the devm_ version remember to drop the put_device in
> panel_dpi_remove().
>
> Noralf.
>
> >-if (!ddata->backlight)
> >-return -EPROBE_DEFER;
> >-}
> >+if (IS_ERR(ddata->backlight))
> >+return PTR_ERR(ddata->backlight);
> > r = of_get_display_timing(node, "panel-timing", &timing);
> > if (r) {
> >-dev_err(&pdev->dev, "failed to get video timing\n");
> >-goto error_free_backlight;
> >+dev_err(dev, "failed to get video timing\n");
> >+return r;
> > }
> > videomode_from_timing(&timing, &ddata->vm);
> > in = omapdss_of_find_source_for_first_ep(node);
> > if (IS_ERR(in)) {
> >-dev_err(&pdev->dev, "failed to find video source\n");
> >-r = PTR_ERR(in);
> >-goto error_free_backlight;
> >+dev_err(dev, "failed to find video source\n");
> >+return PTR_ERR(in);
> > }
> > ddata->in = in;
> > return 0;
> >-
> >-error_free_backlight:
> >-if (ddata->backlight)
> >-put_device(&ddata->backlight->dev);
> >-
> >-return r;
> > }
> > static int panel_dpi_probe(struct platform_device *pdev)
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3] drm/bridge/synopsys: dsi: add optional pixel clock
The pixel clock is optional. When available, it offers a better
preciseness for timing computations and allows to reduce the extra dsi
bandwidth in burst mode (from ~20% to ~10-12%, hw platform dependant).
Reviewed-by: Andrzej Hajda
Signed-off-by: Philippe Cornu
---
Changes in v3: Simplify px_clk probing thanks to Andrzej Hajda comments
Changes in v2: Improve px_clk probing in case of ENOENT dt returned value
(thanks to Philipp Zabel & Andrzej Hajda comments)
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 25 +++--
1 file changed, 19 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index ed8af32f8e52..9fb35385c348 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -217,6 +217,7 @@ struct dw_mipi_dsi {
void __iomem *base;
struct clk *pclk;
+ struct clk *px_clk;
unsigned int lane_mbps; /* per lane */
u32 channel;
@@ -703,24 +704,28 @@ static void dw_mipi_dsi_bridge_mode_set(struct drm_bridge
*bridge,
struct dw_mipi_dsi *dsi = bridge_to_dsi(bridge);
const struct dw_mipi_dsi_phy_ops *phy_ops = dsi->plat_data->phy_ops;
void *priv_data = dsi->plat_data->priv_data;
+ struct drm_display_mode px_clk_mode = *mode;
int ret;
clk_prepare_enable(dsi->pclk);
- ret = phy_ops->get_lane_mbps(priv_data, mode, dsi->mode_flags,
+ if (dsi->px_clk)
+ px_clk_mode.clock = clk_get_rate(dsi->px_clk) / 1000;
+
+ ret = phy_ops->get_lane_mbps(priv_data, &px_clk_mode, dsi->mode_flags,
dsi->lanes, dsi->format, &dsi->lane_mbps);
if (ret)
DRM_DEBUG_DRIVER("Phy get_lane_mbps() failed\n");
pm_runtime_get_sync(dsi->dev);
dw_mipi_dsi_init(dsi);
- dw_mipi_dsi_dpi_config(dsi, mode);
+ dw_mipi_dsi_dpi_config(dsi, &px_clk_mode);
dw_mipi_dsi_packet_handler_config(dsi);
dw_mipi_dsi_video_mode_config(dsi);
- dw_mipi_dsi_video_packet_config(dsi, mode);
+ dw_mipi_dsi_video_packet_config(dsi, &px_clk_mode);
dw_mipi_dsi_command_mode_config(dsi);
- dw_mipi_dsi_line_timer_config(dsi, mode);
- dw_mipi_dsi_vertical_timing_config(dsi, mode);
+ dw_mipi_dsi_line_timer_config(dsi, &px_clk_mode);
+ dw_mipi_dsi_vertical_timing_config(dsi, &px_clk_mode);
dw_mipi_dsi_dphy_init(dsi);
dw_mipi_dsi_dphy_timing_config(dsi);
@@ -734,7 +739,7 @@ static void dw_mipi_dsi_bridge_mode_set(struct drm_bridge
*bridge,
dw_mipi_dsi_dphy_enable(dsi);
- dw_mipi_dsi_wait_for_two_frames(mode);
+ dw_mipi_dsi_wait_for_two_frames(&px_clk_mode);
/* Switch to cmd mode for panel-bridge pre_enable & panel prepare */
dw_mipi_dsi_set_mode(dsi, 0);
@@ -828,6 +833,14 @@ __dw_mipi_dsi_probe(struct platform_device *pdev,
return ERR_PTR(ret);
}
+ dsi->px_clk = devm_clk_get(dev, "px_clk");
+ if (IS_ERR(dsi->px_clk)) {
+ ret = PTR_ERR(dsi->px_clk);
+ if (ret != ENOENT)
+ dev_err(dev, "Unable to get opt. px_clk: %d\n", ret);
+ dsi->px_clk = NULL;
+ }
+
/*
* Note that the reset was not defined in the initial device tree, so
* we have to be prepared for it not being found.
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/5] drm/armada: Construct a temporary crtc state for plane checks
From: Ville Syrjälä
As armada isn't an atomic driver trying to pass a non-populated
crtc->state to drm_atomic_helper_check_plane_state() will end in tears.
Construct a temporary crtc state a la drm_plane_helper_check_update()
and pass that instead. For now we just really need crtc_state->enable
to be there.
Cc: Dave Airlie
Cc: Russell King
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/armada/armada_crtc.c| 6 +-
drivers/gpu/drm/armada/armada_overlay.c | 6 +-
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/armada/armada_crtc.c
b/drivers/gpu/drm/armada/armada_crtc.c
index e2adfbef7d6b..9621ed5d3f98 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -1200,13 +1200,17 @@ static int armada_drm_primary_update(struct drm_plane
*plane,
.crtc_h = crtc_h,
.rotation = DRM_MODE_ROTATE_0,
};
+ struct drm_crtc_state crtc_state = {
+ .crtc = crtc,
+ .enable = crtc->enabled,
+ };
const struct drm_rect clip = {
.x2 = crtc->mode.hdisplay,
.y2 = crtc->mode.vdisplay,
};
int ret;
- ret = drm_atomic_helper_check_plane_state(&state, crtc->state, &clip, 0,
+ ret = drm_atomic_helper_check_plane_state(&state, &crtc_state, &clip, 0,
INT_MAX, true, false);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/armada/armada_overlay.c
b/drivers/gpu/drm/armada/armada_overlay.c
index 77b55adaa2ac..825cb642b55e 100644
--- a/drivers/gpu/drm/armada/armada_overlay.c
+++ b/drivers/gpu/drm/armada/armada_overlay.c
@@ -205,6 +205,10 @@ armada_ovl_plane_update(struct drm_plane *plane, struct
drm_crtc *crtc,
.crtc_h = crtc_h,
.rotation = DRM_MODE_ROTATE_0,
};
+ struct drm_crtc_state crtc_state = {
+ .crtc = crtc,
+ .enable = crtc->enabled,
+ };
const struct drm_rect clip = {
.x2 = crtc->mode.hdisplay,
.y2 = crtc->mode.vdisplay,
@@ -215,7 +219,7 @@ armada_ovl_plane_update(struct drm_plane *plane, struct
drm_crtc *crtc,
crtc_x, crtc_y, crtc_w, crtc_h,
src_x, src_y, src_w, src_h);
- ret = drm_atomic_helper_check_plane_state(&state, crtc->state, &clip, 0,
+ ret = drm_atomic_helper_check_plane_state(&state, &crtc_state, &clip, 0,
INT_MAX, true, false);
if (ret)
return ret;
--
2.13.6
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/5] drm/rcar-du: Use drm_mode_get_hv_timing() to populate plane clip rectangle
From: Ville Syrjälä
Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.
No functional changes as the code already uses crtc_state->mode
to populate the clip, which is also what drm_mode_get_hv_timing()
uses.
Once everyone agrees on this we can move the clip handling into
drm_atomic_helper_check_plane_state().
Cc: Laurent Pinchart
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/rcar-du/rcar_du_plane.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
index 4a3d16cf3ed6..5687a94d4cb1 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
@@ -572,7 +572,7 @@ int __rcar_du_plane_atomic_check(struct drm_plane *plane,
{
struct drm_device *dev = plane->dev;
struct drm_crtc_state *crtc_state;
- struct drm_rect clip;
+ struct drm_rect clip = {};
int ret;
if (!state->crtc) {
@@ -589,10 +589,9 @@ int __rcar_du_plane_atomic_check(struct drm_plane *plane,
if (IS_ERR(crtc_state))
return PTR_ERR(crtc_state);
- clip.x1 = 0;
- clip.y1 = 0;
- clip.x2 = crtc_state->mode.hdisplay;
- clip.y2 = crtc_state->mode.vdisplay;
+ if (crtc_state->enable)
+ drm_mode_get_hv_timing(&crtc_state->mode,
+ &clip.x2, &clip.y2);
ret = drm_atomic_helper_check_plane_state(state, crtc_state, &clip,
DRM_PLANE_HELPER_NO_SCALING,
--
2.13.6
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/5] drm/armada: Use drm_mode_get_hv_timing() to populate plane clip rectangle
From: Ville Syrjälä
Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.
Since armada isn't atomic we'll use crtc->enabled and crtc->mode instead
of the stuff under crtc_state.
Once everyone agrees on how the clip rectangle gets set up we can
move the code into drm_atomic_helper_check_plane_state().
Cc: Dave Airlie
Cc: Russell King
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/armada/armada_crtc.c| 9 +
drivers/gpu/drm/armada/armada_overlay.c | 9 +
2 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/armada/armada_crtc.c
b/drivers/gpu/drm/armada/armada_crtc.c
index 9621ed5d3f98..fdc34ad4ca62 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -1204,12 +1204,13 @@ static int armada_drm_primary_update(struct drm_plane
*plane,
.crtc = crtc,
.enable = crtc->enabled,
};
- const struct drm_rect clip = {
- .x2 = crtc->mode.hdisplay,
- .y2 = crtc->mode.vdisplay,
- };
+ struct drm_rect clip = {};
int ret;
+ if (crtc->enabled)
+ drm_mode_get_hv_timing(&crtc->mode,
+ &clip.x2, &clip.y2);
+
ret = drm_atomic_helper_check_plane_state(&state, &crtc_state, &clip, 0,
INT_MAX, true, false);
if (ret)
diff --git a/drivers/gpu/drm/armada/armada_overlay.c
b/drivers/gpu/drm/armada/armada_overlay.c
index 825cb642b55e..4f2a7a6e0fd3 100644
--- a/drivers/gpu/drm/armada/armada_overlay.c
+++ b/drivers/gpu/drm/armada/armada_overlay.c
@@ -209,16 +209,17 @@ armada_ovl_plane_update(struct drm_plane *plane, struct
drm_crtc *crtc,
.crtc = crtc,
.enable = crtc->enabled,
};
- const struct drm_rect clip = {
- .x2 = crtc->mode.hdisplay,
- .y2 = crtc->mode.vdisplay,
- };
+ struct drm_rect clip = {};
int ret;
trace_armada_ovl_plane_update(plane, crtc, fb,
crtc_x, crtc_y, crtc_w, crtc_h,
src_x, src_y, src_w, src_h);
+ if (crtc->enabled)
+ drm_mode_get_hv_timing(&crtc->mode,
+ &clip.x2, &clip.y2);
+
ret = drm_atomic_helper_check_plane_state(&state, &crtc_state, &clip, 0,
INT_MAX, true, false);
if (ret)
--
2.13.6
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/5] drm: Don't pass clip to drm_atomic_helper_check_plane_state()
From: Ville Syrjälä
Move the plane clip rectangle handling into
drm_atomic_helper_check_plane_state(). Drivers no longer
have to worry about such mundane details.
v2: Convert armada, rcar, and sun4i as well
Cc: Liviu Dudau
Cc: Brian Starkey
Cc: Mali DP Maintainers
Cc: Daniel Vetter
Cc: Gustavo Padovan
Cc: Sean Paul
Cc: Philipp Zabel
Cc: CK Hu
Cc: Neil Armstrong
Cc: Rob Clark
Cc: Ben Skeggs
Cc: Laurent Pinchart
Cc: Sandy Huang
Cc: "Heiko Stübner"
Cc: Maxime Ripard
Cc: Thierry Reding
Cc: VMware Graphics
Cc: Sinclair Yeh
Cc: Thomas Hellstrom
Cc: Shawn Guo
Cc: Archit Taneja
Cc: linux-amlo...@lists.infradead.org
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Cc: linux-renesas-...@vger.kernel.org
Cc: linux-te...@vger.kernel.org
Cc: Russell King
Suggested-by: Daniel Vetter
Signed-off-by: Ville Syrjälä
Reviewed-by: Daniel Vetter
Reviewed-by: Thierry Reding
Reviewed-by: Archit Taneja #msm
---
drivers/gpu/drm/arm/hdlcd_crtc.c| 7 +--
drivers/gpu/drm/arm/malidp_planes.c | 7 +--
drivers/gpu/drm/armada/armada_crtc.c| 8 ++--
drivers/gpu/drm/armada/armada_overlay.c | 8 ++--
drivers/gpu/drm/drm_atomic_helper.c | 12 +++-
drivers/gpu/drm/drm_plane_helper.c | 11 +++
drivers/gpu/drm/drm_simple_kms_helper.c | 6 --
drivers/gpu/drm/i915/intel_display.c| 12
drivers/gpu/drm/imx/ipuv3-plane.c | 7 +--
drivers/gpu/drm/mediatek/mtk_drm_plane.c| 7 +--
drivers/gpu/drm/meson/meson_plane.c | 7 +--
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 14 ++
drivers/gpu/drm/nouveau/nv50_display.c | 12
drivers/gpu/drm/rcar-du/rcar_du_plane.c | 7 +--
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 7 +--
drivers/gpu/drm/sun4i/sun8i_ui_layer.c | 7 +--
drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 7 +--
drivers/gpu/drm/tegra/plane.c | 7 +--
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 7 +--
drivers/gpu/drm/zte/zx_plane.c | 13 +
include/drm/drm_atomic_helper.h | 1 -
include/drm/drm_plane_helper.h | 1 -
22 files changed, 28 insertions(+), 147 deletions(-)
diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
index 877647ef35a9..cf5cbd63ecdf 100644
--- a/drivers/gpu/drm/arm/hdlcd_crtc.c
+++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
@@ -229,7 +229,6 @@ static const struct drm_crtc_helper_funcs
hdlcd_crtc_helper_funcs = {
static int hdlcd_plane_atomic_check(struct drm_plane *plane,
struct drm_plane_state *state)
{
- struct drm_rect clip = { 0 };
struct drm_crtc_state *crtc_state;
u32 src_h = state->src_h >> 16;
@@ -249,11 +248,7 @@ static int hdlcd_plane_atomic_check(struct drm_plane
*plane,
return -EINVAL;
}
- if (crtc_state->enable)
- drm_mode_get_hv_timing(&crtc_state->mode,
- &clip.x2, &clip.y2);
-
- return drm_atomic_helper_check_plane_state(state, crtc_state, &clip,
+ return drm_atomic_helper_check_plane_state(state, crtc_state,
DRM_PLANE_HELPER_NO_SCALING,
DRM_PLANE_HELPER_NO_SCALING,
false, true);
diff --git a/drivers/gpu/drm/arm/malidp_planes.c
b/drivers/gpu/drm/arm/malidp_planes.c
index 2885d69af456..ee32361c87ac 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -141,18 +141,13 @@ static int malidp_se_check_scaling(struct malidp_plane
*mp,
struct drm_crtc_state *crtc_state =
drm_atomic_get_existing_crtc_state(state->state, state->crtc);
struct malidp_crtc_state *mc;
- struct drm_rect clip = { 0 };
u32 src_w, src_h;
int ret;
if (!crtc_state)
return -EINVAL;
- if (crtc_state->enable)
- drm_mode_get_hv_timing(&crtc_state->mode,
- &clip.x2, &clip.y2);
-
- ret = drm_atomic_helper_check_plane_state(state, crtc_state, &clip,
+ ret = drm_atomic_helper_check_plane_state(state, crtc_state,
0, INT_MAX, true, true);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/armada/armada_crtc.c
b/drivers/gpu/drm/armada/armada_crtc.c
index fdc34ad4ca62..0311dd5b 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -1203,15 +1203,11 @@ static int armada_drm_primary_update(struct drm_plane
*plane,
struct drm_crtc_state crtc_state = {
.crtc = crtc,
.enable = crtc->enabled,
+ .mode = crtc->mo
[PATCH 2/5] drm/sun4i: Use drm_mode_get_hv_timing() to populate plane clip rectangle
From: Ville Syrjälä
Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.
Note that this replaces crtc_state->adjusted_mode usage with
crtc_state->mode. The latter is the correct choice since that's the
mode the user provided and it matches the plane crtc coordinates
the user also provided.
Once everyone agrees on this we can move the clip handling into
drm_atomic_helper_check_plane_state().
Cc: Maxime Ripard
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/sun4i/sun8i_ui_layer.c | 9 -
drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 9 -
2 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
b/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
index 28d7c48d50fe..2f0ccd50b54d 100644
--- a/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
@@ -211,7 +211,7 @@ static int sun8i_ui_layer_atomic_check(struct drm_plane
*plane,
struct drm_crtc *crtc = state->crtc;
struct drm_crtc_state *crtc_state;
int min_scale, max_scale;
- struct drm_rect clip;
+ struct drm_rect clip = {};
if (!crtc)
return 0;
@@ -220,10 +220,9 @@ static int sun8i_ui_layer_atomic_check(struct drm_plane
*plane,
if (WARN_ON(!crtc_state))
return -EINVAL;
- clip.x1 = 0;
- clip.y1 = 0;
- clip.x2 = crtc_state->adjusted_mode.hdisplay;
- clip.y2 = crtc_state->adjusted_mode.vdisplay;
+ if (crtc_state->enable)
+ drm_mode_get_hv_timing(&crtc_state->mode,
+ &clip.x2, &clip.y2);
min_scale = DRM_PLANE_HELPER_NO_SCALING;
max_scale = DRM_PLANE_HELPER_NO_SCALING;
diff --git a/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
b/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
index 40c3b303068a..eb3bf2d7291a 100644
--- a/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
@@ -239,7 +239,7 @@ static int sun8i_vi_layer_atomic_check(struct drm_plane
*plane,
struct drm_crtc *crtc = state->crtc;
struct drm_crtc_state *crtc_state;
int min_scale, max_scale;
- struct drm_rect clip;
+ struct drm_rect clip = {};
if (!crtc)
return 0;
@@ -248,10 +248,9 @@ static int sun8i_vi_layer_atomic_check(struct drm_plane
*plane,
if (WARN_ON(!crtc_state))
return -EINVAL;
- clip.x1 = 0;
- clip.y1 = 0;
- clip.x2 = crtc_state->adjusted_mode.hdisplay;
- clip.y2 = crtc_state->adjusted_mode.vdisplay;
+ if (crtc_state->enable)
+ drm_mode_get_hv_timing(&crtc_state->mode,
+ &clip.x2, &clip.y2);
min_scale = DRM_PLANE_HELPER_NO_SCALING;
max_scale = DRM_PLANE_HELPER_NO_SCALING;
--
2.13.6
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101900] No HDMI HBR audio on Polaris (no TrueHD, no Atmos, no Neo:X, no HD Master audio) and static noise in sound when LPCM on amdgpu Xorg driver
https://bugs.freedesktop.org/show_bug.cgi?id=101900 --- Comment #29 from letha...@gmail.com --- Thank you Andy, i will look into your previous comments and make some tests, hope i will be able to confirm somehow. I suppose these are all ati/radeon audio+cpu related? Because i'ved used hdmi-audio on nvidia for years without problems, so it's not "general" as in every hdmi-audio driver. >From what i've seen in the code, amdgpu reuse the same audio code than previous radeon cards. This could explain that the problem is still present, even years laters (?) -- 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 101900] No HDMI HBR audio on Polaris (no TrueHD, no Atmos, no Neo:X, no HD Master audio) and static noise in sound when LPCM on amdgpu Xorg driver
https://bugs.freedesktop.org/show_bug.cgi?id=101900 --- Comment #30 from letha...@gmail.com --- @andy: Indeed, when i make -j3 on the kernel, the sound gets right. When i kill the make, the audio gets glitchy ! -- 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 v18 10/10] drm/omapdrm: Use of_find_backlight helper
Den 23.01.2018 17.55, skrev Meghana Madhyastha:
On Tue, Jan 23, 2018 at 03:37:38PM +0100, Noralf Trønnes wrote:
Den 22.01.2018 15.56, skrev Meghana Madhyastha:
Replace of_find_backlight_by_node and of the code around it
with of_find_backlight helper to avoid repetition of code.
Signed-off-by: Meghana Madhyastha
---
Changes in v18:
-Fixed warnings resulting from passing device_node* to of_find_backlight.
Fixed it by passing struct device* to of_find_backlight
drivers/gpu/drm/omapdrm/displays/panel-dpi.c | 33 ++--
1 file changed, 11 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-dpi.c
b/drivers/gpu/drm/omapdrm/displays/panel-dpi.c
index ac9596251..93b7a176d 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-dpi.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-dpi.c
@@ -156,14 +156,14 @@ static struct omap_dss_driver panel_dpi_ops = {
static int panel_dpi_probe_of(struct platform_device *pdev)
{
struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+ struct device *dev = &pdev->dev;
struct device_node *node = pdev->dev.of_node;
- struct device_node *bl_node;
struct omap_dss_device *in;
int r;
struct display_timing timing;
struct gpio_desc *gpio;
- gpio = devm_gpiod_get_optional(&pdev->dev, "enable", GPIOD_OUT_LOW);
+ gpio = devm_gpiod_get_optional(dev, "enable", GPIOD_OUT_LOW);
Please don't make unrelated changes like this. It clutters the patch.
You can just as well use &pdev->dev when getting the backlight also.
I had made the change in order to be more consistent with how the other
drivers were doing this. Most of them had a variable struct device *dev.
However, I can undo this if necessary.
It's best to be consistent with the coding style in the driver you're
changing. If you make an extra dev variable or not isn't that important,
unless the driver maintainer have a strict coding style for their driver.
I try to stay on the safe side, change as little as possible and do thing
the way it's done in the driver to increase the change of getting the
patch accepted as-is the first time around.
The important feedback from me is to remove the unrelated changes.
Noralf.
if (IS_ERR(gpio))
return PTR_ERR(gpio);
@@ -175,47 +175,36 @@ static int panel_dpi_probe_of(struct platform_device
*pdev)
* timing and order relative to the enable gpio. So for now it's just
* ensured that the reset line isn't active.
*/
- gpio = devm_gpiod_get_optional(&pdev->dev, "reset", GPIOD_OUT_LOW);
+ gpio = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_LOW);
if (IS_ERR(gpio))
return PTR_ERR(gpio);
- ddata->vcc_supply = devm_regulator_get(&pdev->dev, "vcc");
+ ddata->vcc_supply = devm_regulator_get(dev, "vcc");
if (IS_ERR(ddata->vcc_supply))
return PTR_ERR(ddata->vcc_supply);
- bl_node = of_parse_phandle(node, "backlight", 0);
- if (bl_node) {
- ddata->backlight = of_find_backlight_by_node(bl_node);
- of_node_put(bl_node);
+ ddata->backlight = of_find_backlight(dev);
Any reason you don't use the devm_ version here?
You do remove error_free_backlight...
With the devm_ version remember to drop the put_device in
panel_dpi_remove().
Noralf.
- if (!ddata->backlight)
- return -EPROBE_DEFER;
- }
+ if (IS_ERR(ddata->backlight))
+ return PTR_ERR(ddata->backlight);
r = of_get_display_timing(node, "panel-timing", &timing);
if (r) {
- dev_err(&pdev->dev, "failed to get video timing\n");
- goto error_free_backlight;
+ dev_err(dev, "failed to get video timing\n");
+ return r;
}
videomode_from_timing(&timing, &ddata->vm);
in = omapdss_of_find_source_for_first_ep(node);
if (IS_ERR(in)) {
- dev_err(&pdev->dev, "failed to find video source\n");
- r = PTR_ERR(in);
- goto error_free_backlight;
+ dev_err(dev, "failed to find video source\n");
+ return PTR_ERR(in);
}
ddata->in = in;
return 0;
-
-error_free_backlight:
- if (ddata->backlight)
- put_device(&ddata->backlight->dev);
-
- return r;
}
static int panel_dpi_probe(struct platform_device *pdev)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v18 10/10] drm/omapdrm: Use of_find_backlight helper
Den 23.01.2018 18.41, skrev Noralf Trønnes:
Den 23.01.2018 17.55, skrev Meghana Madhyastha:
On Tue, Jan 23, 2018 at 03:37:38PM +0100, Noralf Trønnes wrote:
Den 22.01.2018 15.56, skrev Meghana Madhyastha:
Replace of_find_backlight_by_node and of the code around it
with of_find_backlight helper to avoid repetition of code.
Signed-off-by: Meghana Madhyastha
---
Changes in v18:
-Fixed warnings resulting from passing device_node* to
of_find_backlight.
Fixed it by passing struct device* to of_find_backlight
drivers/gpu/drm/omapdrm/displays/panel-dpi.c | 33
++--
1 file changed, 11 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-dpi.c
b/drivers/gpu/drm/omapdrm/displays/panel-dpi.c
index ac9596251..93b7a176d 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-dpi.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-dpi.c
@@ -156,14 +156,14 @@ static struct omap_dss_driver panel_dpi_ops = {
static int panel_dpi_probe_of(struct platform_device *pdev)
{
struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+ struct device *dev = &pdev->dev;
struct device_node *node = pdev->dev.of_node;
- struct device_node *bl_node;
struct omap_dss_device *in;
int r;
struct display_timing timing;
struct gpio_desc *gpio;
- gpio = devm_gpiod_get_optional(&pdev->dev, "enable",
GPIOD_OUT_LOW);
+ gpio = devm_gpiod_get_optional(dev, "enable", GPIOD_OUT_LOW);
Please don't make unrelated changes like this. It clutters the patch.
You can just as well use &pdev->dev when getting the backlight also.
I had made the change in order to be more consistent with how the other
drivers were doing this. Most of them had a variable struct device *dev.
However, I can undo this if necessary.
It's best to be consistent with the coding style in the driver you're
changing. If you make an extra dev variable or not isn't that important,
unless the driver maintainer have a strict coding style for their driver.
I try to stay on the safe side, change as little as possible and do thing
the way it's done in the driver to increase the change of getting the
patch accepted as-is the first time around.
The important feedback from me is to remove the unrelated changes.
and the use of the devm_ version ofc.
Noralf.
if (IS_ERR(gpio))
return PTR_ERR(gpio);
@@ -175,47 +175,36 @@ static int panel_dpi_probe_of(struct
platform_device *pdev)
* timing and order relative to the enable gpio. So for now
it's just
* ensured that the reset line isn't active.
*/
- gpio = devm_gpiod_get_optional(&pdev->dev, "reset",
GPIOD_OUT_LOW);
+ gpio = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_LOW);
if (IS_ERR(gpio))
return PTR_ERR(gpio);
- ddata->vcc_supply = devm_regulator_get(&pdev->dev, "vcc");
+ ddata->vcc_supply = devm_regulator_get(dev, "vcc");
if (IS_ERR(ddata->vcc_supply))
return PTR_ERR(ddata->vcc_supply);
- bl_node = of_parse_phandle(node, "backlight", 0);
- if (bl_node) {
- ddata->backlight = of_find_backlight_by_node(bl_node);
- of_node_put(bl_node);
+ ddata->backlight = of_find_backlight(dev);
Any reason you don't use the devm_ version here?
You do remove error_free_backlight...
With the devm_ version remember to drop the put_device in
panel_dpi_remove().
Noralf.
- if (!ddata->backlight)
- return -EPROBE_DEFER;
- }
+ if (IS_ERR(ddata->backlight))
+ return PTR_ERR(ddata->backlight);
r = of_get_display_timing(node, "panel-timing", &timing);
if (r) {
- dev_err(&pdev->dev, "failed to get video timing\n");
- goto error_free_backlight;
+ dev_err(dev, "failed to get video timing\n");
+ return r;
}
videomode_from_timing(&timing, &ddata->vm);
in = omapdss_of_find_source_for_first_ep(node);
if (IS_ERR(in)) {
- dev_err(&pdev->dev, "failed to find video source\n");
- r = PTR_ERR(in);
- goto error_free_backlight;
+ dev_err(dev, "failed to find video source\n");
+ return PTR_ERR(in);
}
ddata->in = in;
return 0;
-
-error_free_backlight:
- if (ddata->backlight)
- put_device(&ddata->backlight->dev);
-
- return r;
}
static int panel_dpi_probe(struct platform_device *pdev)
___
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 5/5] drm: Don't pass clip to drm_atomic_helper_check_plane_state()
On Tue, Jan 23, 2018 at 07:08:57PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Move the plane clip rectangle handling into
> drm_atomic_helper_check_plane_state(). Drivers no longer
> have to worry about such mundane details.
>
> v2: Convert armada, rcar, and sun4i as well
>
> Cc: Liviu Dudau
> Cc: Brian Starkey
> Cc: Mali DP Maintainers
> Cc: Daniel Vetter
> Cc: Gustavo Padovan
> Cc: Sean Paul
> Cc: Philipp Zabel
> Cc: CK Hu
> Cc: Neil Armstrong
> Cc: Rob Clark
> Cc: Ben Skeggs
> Cc: Laurent Pinchart
> Cc: Sandy Huang
> Cc: "Heiko Stübner"
> Cc: Maxime Ripard
> Cc: Thierry Reding
> Cc: VMware Graphics
> Cc: Sinclair Yeh
> Cc: Thomas Hellstrom
> Cc: Shawn Guo
> Cc: Archit Taneja
> Cc: linux-amlo...@lists.infradead.org
> Cc: linux-arm-...@vger.kernel.org
> Cc: freedr...@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Cc: linux-renesas-...@vger.kernel.org
> Cc: linux-te...@vger.kernel.org
> Cc: Russell King
> Suggested-by: Daniel Vetter
> Signed-off-by: Ville Syrjälä
> Reviewed-by: Daniel Vetter
> Reviewed-by: Thierry Reding
> Reviewed-by: Archit Taneja #msm
> ---
> drivers/gpu/drm/arm/hdlcd_crtc.c| 7 +--
> drivers/gpu/drm/arm/malidp_planes.c | 7 +--
> drivers/gpu/drm/armada/armada_crtc.c| 8 ++--
> drivers/gpu/drm/armada/armada_overlay.c | 8 ++--
> drivers/gpu/drm/drm_atomic_helper.c | 12 +++-
> drivers/gpu/drm/drm_plane_helper.c | 11 +++
> drivers/gpu/drm/drm_simple_kms_helper.c | 6 --
> drivers/gpu/drm/i915/intel_display.c| 12
> drivers/gpu/drm/imx/ipuv3-plane.c | 7 +--
> drivers/gpu/drm/mediatek/mtk_drm_plane.c| 7 +--
> drivers/gpu/drm/meson/meson_plane.c | 7 +--
> drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 14 ++
> drivers/gpu/drm/nouveau/nv50_display.c | 12
> drivers/gpu/drm/rcar-du/rcar_du_plane.c | 7 +--
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 7 +--
> drivers/gpu/drm/sun4i/sun8i_ui_layer.c | 7 +--
> drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 7 +--
> drivers/gpu/drm/tegra/plane.c | 7 +--
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 7 +--
> drivers/gpu/drm/zte/zx_plane.c | 13 +
> include/drm/drm_atomic_helper.h | 1 -
> include/drm/drm_plane_helper.h | 1 -
> 22 files changed, 28 insertions(+), 147 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c
> b/drivers/gpu/drm/arm/hdlcd_crtc.c
> index 877647ef35a9..cf5cbd63ecdf 100644
> --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
> +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
> @@ -229,7 +229,6 @@ static const struct drm_crtc_helper_funcs
> hdlcd_crtc_helper_funcs = {
> static int hdlcd_plane_atomic_check(struct drm_plane *plane,
> struct drm_plane_state *state)
> {
> - struct drm_rect clip = { 0 };
> struct drm_crtc_state *crtc_state;
> u32 src_h = state->src_h >> 16;
>
> @@ -249,11 +248,7 @@ static int hdlcd_plane_atomic_check(struct drm_plane
> *plane,
> return -EINVAL;
> }
>
> - if (crtc_state->enable)
> - drm_mode_get_hv_timing(&crtc_state->mode,
> -&clip.x2, &clip.y2);
> -
> - return drm_atomic_helper_check_plane_state(state, crtc_state, &clip,
> + return drm_atomic_helper_check_plane_state(state, crtc_state,
> DRM_PLANE_HELPER_NO_SCALING,
> DRM_PLANE_HELPER_NO_SCALING,
> false, true);
> diff --git a/drivers/gpu/drm/arm/malidp_planes.c
> b/drivers/gpu/drm/arm/malidp_planes.c
> index 2885d69af456..ee32361c87ac 100644
> --- a/drivers/gpu/drm/arm/malidp_planes.c
> +++ b/drivers/gpu/drm/arm/malidp_planes.c
> @@ -141,18 +141,13 @@ static int malidp_se_check_scaling(struct malidp_plane
> *mp,
> struct drm_crtc_state *crtc_state =
> drm_atomic_get_existing_crtc_state(state->state, state->crtc);
> struct malidp_crtc_state *mc;
> - struct drm_rect clip = { 0 };
> u32 src_w, src_h;
> int ret;
>
> if (!crtc_state)
> return -EINVAL;
>
> - if (crtc_state->enable)
> - drm_mode_get_hv_timing(&crtc_state->mode,
> -&clip.x2, &clip.y2);
> -
> - ret = drm_atomic_helper_check_plane_state(state, crtc_state, &clip,
> + ret = drm_atomic_helper_check_plane_state(state, crtc_state,
> 0, INT_MAX, true, true);
> if (ret)
> return ret;
For the HDLCD and Mali DP changes:
Acked-by: Liviu Dudau
Best regards,
Liviu
> diff --git a/drivers/gpu/drm/armada/armada_crtc.c
> b/drivers/gpu/drm/armada/armada_crtc.c
> index fdc34ad4ca62..0311d
[Bug 86351] HDMI audio garbled output on Radeon R9 280X
https://bugzilla.kernel.org/show_bug.cgi?id=86351 letha...@gmail.com changed: What|Removed |Added CC||letha...@gmail.com --- Comment #30 from letha...@gmail.com --- after discussing https://bugs.freedesktop.org/show_bug.cgi?id=101900 this bug seems to be still present in the amdgpu drivers. When i have a cpuload, amdgpu sound is fine. when the cpu is mostly idle, the sound is very glitchy. So all RXxxx cards are affected. -- 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 5/5] drm: Don't pass clip to drm_atomic_helper_check_plane_state()
On Tue, 2018-01-23 at 19:08 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Move the plane clip rectangle handling into
> drm_atomic_helper_check_plane_state(). Drivers no longer
> have to worry about such mundane details.
>
> v2: Convert armada, rcar, and sun4i as well
>
> Cc: Liviu Dudau
> Cc: Brian Starkey
> Cc: Mali DP Maintainers
> Cc: Daniel Vetter
> Cc: Gustavo Padovan
> Cc: Sean Paul
> Cc: Philipp Zabel
> Cc: CK Hu
> Cc: Neil Armstrong
> Cc: Rob Clark
> Cc: Ben Skeggs
> Cc: Laurent Pinchart
> Cc: Sandy Huang
> Cc: "Heiko Stübner"
> Cc: Maxime Ripard
> Cc: Thierry Reding
> Cc: VMware Graphics
> Cc: Sinclair Yeh
> Cc: Thomas Hellstrom
> Cc: Shawn Guo
> Cc: Archit Taneja
> Cc: linux-amlo...@lists.infradead.org
> Cc: linux-arm-...@vger.kernel.org
> Cc: freedr...@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Cc: linux-renesas-...@vger.kernel.org
> Cc: linux-te...@vger.kernel.org
> Cc: Russell King
> Suggested-by: Daniel Vetter
> Signed-off-by: Ville Syrjälä
> Reviewed-by: Daniel Vetter
> Reviewed-by: Thierry Reding
> Reviewed-by: Archit Taneja #msm
> ---
> drivers/gpu/drm/arm/hdlcd_crtc.c| 7 +--
> drivers/gpu/drm/arm/malidp_planes.c | 7 +--
> drivers/gpu/drm/armada/armada_crtc.c| 8 ++--
> drivers/gpu/drm/armada/armada_overlay.c | 8 ++--
> drivers/gpu/drm/drm_atomic_helper.c | 12 +++-
> drivers/gpu/drm/drm_plane_helper.c | 11 +++
> drivers/gpu/drm/drm_simple_kms_helper.c | 6 --
> drivers/gpu/drm/i915/intel_display.c| 12
> drivers/gpu/drm/imx/ipuv3-plane.c | 7 +--
> drivers/gpu/drm/mediatek/mtk_drm_plane.c| 7 +--
> drivers/gpu/drm/meson/meson_plane.c | 7 +--
> drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 14 ++
> drivers/gpu/drm/nouveau/nv50_display.c | 12
> drivers/gpu/drm/rcar-du/rcar_du_plane.c | 7 +--
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 7 +--
> drivers/gpu/drm/sun4i/sun8i_ui_layer.c | 7 +--
> drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 7 +--
> drivers/gpu/drm/tegra/plane.c | 7 +--
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 7 +--
> drivers/gpu/drm/zte/zx_plane.c | 13 +
> include/drm/drm_atomic_helper.h | 1 -
> include/drm/drm_plane_helper.h | 1 -
> 22 files changed, 28 insertions(+), 147 deletions(-)
>
[...]
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index ab4032167094..9fb96f9cc36e 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -699,7 +699,6 @@ EXPORT_SYMBOL(drm_atomic_helper_check_modeset);
> * drm_atomic_helper_check_plane_state() - Check plane state for validity
> * @plane_state: plane state to check
> * @crtc_state: crtc state to check
> - * @clip: integer clipping coordinates
> * @min_scale: minimum @src:@dest scaling factor in 16.16 fixed point
> * @max_scale: maximum @src:@dest scaling factor in 16.16 fixed point
> * @can_position: is it legal to position the plane such that it
> @@ -719,7 +718,6 @@ EXPORT_SYMBOL(drm_atomic_helper_check_modeset);
> */
> int drm_atomic_helper_check_plane_state(struct drm_plane_state *plane_state,
> const struct drm_crtc_state *crtc_state,
> - const struct drm_rect *clip,
> int min_scale,
> int max_scale,
> bool can_position,
> @@ -729,6 +727,7 @@ int drm_atomic_helper_check_plane_state(struct
> drm_plane_state *plane_state,
> struct drm_rect *src = &plane_state->src;
> struct drm_rect *dst = &plane_state->dst;
> unsigned int rotation = plane_state->rotation;
> + struct drm_rect clip = {};
> int hscale, vscale;
>
> WARN_ON(plane_state->crtc && plane_state->crtc != crtc_state->crtc);
> @@ -764,7 +763,10 @@ int drm_atomic_helper_check_plane_state(struct
> drm_plane_state *plane_state,
> return -ERANGE;
> }
>
> - plane_state->visible = drm_rect_clip_scaled(src, dst, clip, hscale,
> vscale);
> + if (crtc_state->enable)
> + drm_mode_get_hv_timing(&crtc_state->mode, &clip.x2, &clip.y2);
> +
> + plane_state->visible = drm_rect_clip_scaled(src, dst, &clip, hscale,
> vscale);
>
> drm_rect_rotate_inv(src, fb->width << 16, fb->height << 16, rotation);
>
> @@ -778,10 +780,10 @@ int drm_atomic_helper_check_plane_state(struct
> drm_plane_state *plane_state,
>*/
> return 0;
>
> - if (!can_position && !drm_rect_equals(dst, clip)) {
> + if (!can_position && !drm_rect_equals(dst, &clip)) {
> DRM_DEBUG_KMS("Plane must cover entire CRTC\n");
> dr
Re: [PATCH 3/5] drm/armada: Construct a temporary crtc state for plane checks
On Tue, Jan 23, 2018 at 06:42:00PM +, Russell King - ARM Linux wrote: > On Tue, Jan 23, 2018 at 07:08:55PM +0200, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > As armada isn't an atomic driver trying to pass a non-populated > > crtc->state to drm_atomic_helper_check_plane_state() will end in tears. > > Construct a temporary crtc state a la drm_plane_helper_check_update() > > and pass that instead. For now we just really need crtc_state->enable > > to be there. > > Would it be possible to solve this by having the atomic state setup > for non-atomic drivers instead, so we're not unwinding some of the > work that's already been done to try and convert drivers /to/ > atomic modeset? Dunno. Feels like a wasted effort adding more code that'll just get ripped out as soon as the atomic conversion happens. And I'd rather not have to worry about potentially stale states hanging around, in case you forgot to update something somewhere. In any case, I don't think this is unwinding anything. Once you have the atomic conversion done sufficiently you can just drop these temporary states. We already have the temp state for the plane here anyway, and pairing that with a crtc state seems rather logical. -- Ville Syrjälä Intel OTC ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 98974] Can't see borders/empires in Stellaris
https://bugs.freedesktop.org/show_bug.cgi?id=98974 --- Comment #19 from lukas.fuernkranz+bugzil...@gmail.com --- (In reply to Gert Wollny from comment #14) > Could you check whether the bug persists in 17.3.0? It includes patches > that improve the register allocation on r600. > > If this doesn't fix the bug, could you post an apitrace? I can test it in two weeks at the earliest. If someone beat me to it that would be great. However, if nobody does that and you don't hear back from me within three weeks please remind me about this issue. -- 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: [RFC][PATCH] HACK: drm_atomic: Don't try to set vblank if crtc isn't active
On Tue, Jan 23, 2018 at 7:58 AM, Sean Paul wrote:
> On Tue, Jan 23, 2018 at 12:30:58AM -0800, John Stultz wrote:
>> In trying to use the drm_hwcomposer on HiKey, I found things
>> wouldn't initialize due to the following check in
>> drm_atomic_crtc_check() failing:
>>
>> if (state->event && !state->active && !crtc->state->active) {
>> DRM_DEBUG_ATOMIC("[CRTC:%d:%s] requesting event but off\n",
>> crtc->base.id, crtc->name);
>> return -EINVAL;
>> }
>
> I think the answer is in the comment directly above this code. Having an event
> present while the crtc _stays_ off is the problem. So drm_hwc is requesting an
> event (or providing a fence) for a crtc which it does not turn on. So I think
> you should go back into hwc and find out how this situation arises.
So in this case, its providing a fence which causes the event to be set.
I'll look some more, but it seems that we call this check
(drm_atomic_check_only) before we do the commit apply the modeset that
would turn on the crtc.
Thus the check fails and we don't do the commit:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/drm_atomic.c#n1659
Just commenting out the EINVAL in the snippet above causes the crtc to
start up fine.
So it seems like either the first modeset/plane update shouldn't be
done along w/ a fence, or the kernel should maybe skip setting the
event?
> AFAIK, requesting an event in a commit with both a modeset and plane update
> should work.
That's what it looks like to me too, which is why I'm confused.
thanks
-john
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH] HACK: drm_atomic: Don't try to set vblank if crtc isn't active
On Tue, Jan 23, 2018 at 2:23 PM, John Stultz wrote:
> On Tue, Jan 23, 2018 at 7:58 AM, Sean Paul wrote:
>> On Tue, Jan 23, 2018 at 12:30:58AM -0800, John Stultz wrote:
>>> In trying to use the drm_hwcomposer on HiKey, I found things
>>> wouldn't initialize due to the following check in
>>> drm_atomic_crtc_check() failing:
>>>
>>> if (state->event && !state->active && !crtc->state->active) {
>>> DRM_DEBUG_ATOMIC("[CRTC:%d:%s] requesting event but off\n",
>>> crtc->base.id, crtc->name);
>>> return -EINVAL;
>>> }
>>
>> I think the answer is in the comment directly above this code. Having an
>> event
>> present while the crtc _stays_ off is the problem. So drm_hwc is requesting
>> an
>> event (or providing a fence) for a crtc which it does not turn on. So I think
>> you should go back into hwc and find out how this situation arises.
>
> So in this case, its providing a fence which causes the event to be set.
>
> I'll look some more, but it seems that we call this check
> (drm_atomic_check_only) before we do the commit apply the modeset that
> would turn on the crtc.
> Thus the check fails and we don't do the commit:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/drm_atomic.c#n1659
>
> Just commenting out the EINVAL in the snippet above causes the crtc to
> start up fine.
>
> So it seems like either the first modeset/plane update shouldn't be
> done along w/ a fence, or the kernel should maybe skip setting the
> event?
>
I'd tend to focus more on why the crtc is not active in the new state.
Which is something that's specified in the atomic commit coming from
hwc, right?
Sean
>> AFAIK, requesting an event in a commit with both a modeset and plane update
>> should work.
>
> That's what it looks like to me too, which is why I'm confused.
>
> thanks
> -john
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] drm/bridge/synopsys: dsi: add optional pixel clock
Hi,
Philippe asked me to review the last version. I'm not sure I have a lot
to contribute. Maybe Rockchip folks who wrote this stuff in the first
place might. I've CC'd some.
On Tue, Jan 23, 2018 at 06:08:06PM +0100, Philippe Cornu wrote:
> The pixel clock is optional. When available, it offers a better
> preciseness for timing computations and allows to reduce the extra dsi
> bandwidth in burst mode (from ~20% to ~10-12%, hw platform dependant).
>
> Reviewed-by: Andrzej Hajda
> Signed-off-by: Philippe Cornu
> ---
> Changes in v3: Simplify px_clk probing thanks to Andrzej Hajda comments
>
> Changes in v2: Improve px_clk probing in case of ENOENT dt returned value
> (thanks to Philipp Zabel & Andrzej Hajda comments)
>
> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 25 +++--
> 1 file changed, 19 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> index ed8af32f8e52..9fb35385c348 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> @@ -217,6 +217,7 @@ struct dw_mipi_dsi {
> void __iomem *base;
>
> struct clk *pclk;
> + struct clk *px_clk;
>
> unsigned int lane_mbps; /* per lane */
> u32 channel;
> @@ -703,24 +704,28 @@ static void dw_mipi_dsi_bridge_mode_set(struct
> drm_bridge *bridge,
> struct dw_mipi_dsi *dsi = bridge_to_dsi(bridge);
> const struct dw_mipi_dsi_phy_ops *phy_ops = dsi->plat_data->phy_ops;
> void *priv_data = dsi->plat_data->priv_data;
> + struct drm_display_mode px_clk_mode = *mode;
> int ret;
>
> clk_prepare_enable(dsi->pclk);
>
> - ret = phy_ops->get_lane_mbps(priv_data, mode, dsi->mode_flags,
> + if (dsi->px_clk)
> + px_clk_mode.clock = clk_get_rate(dsi->px_clk) / 1000;
> +
> + ret = phy_ops->get_lane_mbps(priv_data, &px_clk_mode, dsi->mode_flags,
>dsi->lanes, dsi->format, &dsi->lane_mbps);
> if (ret)
> DRM_DEBUG_DRIVER("Phy get_lane_mbps() failed\n");
>
> pm_runtime_get_sync(dsi->dev);
> dw_mipi_dsi_init(dsi);
> - dw_mipi_dsi_dpi_config(dsi, mode);
> + dw_mipi_dsi_dpi_config(dsi, &px_clk_mode);
> dw_mipi_dsi_packet_handler_config(dsi);
> dw_mipi_dsi_video_mode_config(dsi);
> - dw_mipi_dsi_video_packet_config(dsi, mode);
> + dw_mipi_dsi_video_packet_config(dsi, &px_clk_mode);
> dw_mipi_dsi_command_mode_config(dsi);
> - dw_mipi_dsi_line_timer_config(dsi, mode);
> - dw_mipi_dsi_vertical_timing_config(dsi, mode);
> + dw_mipi_dsi_line_timer_config(dsi, &px_clk_mode);
> + dw_mipi_dsi_vertical_timing_config(dsi, &px_clk_mode);
>
> dw_mipi_dsi_dphy_init(dsi);
> dw_mipi_dsi_dphy_timing_config(dsi);
> @@ -734,7 +739,7 @@ static void dw_mipi_dsi_bridge_mode_set(struct drm_bridge
> *bridge,
>
> dw_mipi_dsi_dphy_enable(dsi);
>
> - dw_mipi_dsi_wait_for_two_frames(mode);
> + dw_mipi_dsi_wait_for_two_frames(&px_clk_mode);
>
> /* Switch to cmd mode for panel-bridge pre_enable & panel prepare */
> dw_mipi_dsi_set_mode(dsi, 0);
> @@ -828,6 +833,14 @@ __dw_mipi_dsi_probe(struct platform_device *pdev,
> return ERR_PTR(ret);
> }
>
> + dsi->px_clk = devm_clk_get(dev, "px_clk");
Did you write a device tree binding document update for this anywhere?
Brian
> + if (IS_ERR(dsi->px_clk)) {
> + ret = PTR_ERR(dsi->px_clk);
> + if (ret != ENOENT)
> + dev_err(dev, "Unable to get opt. px_clk: %d\n", ret);
> + dsi->px_clk = NULL;
> + }
> +
> /*
>* Note that the reset was not defined in the initial device tree, so
>* we have to be prepared for it not being found.
> --
> 2.15.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH] HACK: drm_atomic: Don't try to set vblank if crtc isn't active
On Tue, Jan 23, 2018 at 12:44 PM, Sean Paul wrote:
> On Tue, Jan 23, 2018 at 2:23 PM, John Stultz wrote:
>> On Tue, Jan 23, 2018 at 7:58 AM, Sean Paul wrote:
>>> On Tue, Jan 23, 2018 at 12:30:58AM -0800, John Stultz wrote:
In trying to use the drm_hwcomposer on HiKey, I found things
wouldn't initialize due to the following check in
drm_atomic_crtc_check() failing:
if (state->event && !state->active && !crtc->state->active) {
DRM_DEBUG_ATOMIC("[CRTC:%d:%s] requesting event but off\n",
crtc->base.id, crtc->name);
return -EINVAL;
}
>>>
>>> I think the answer is in the comment directly above this code. Having an
>>> event
>>> present while the crtc _stays_ off is the problem. So drm_hwc is requesting
>>> an
>>> event (or providing a fence) for a crtc which it does not turn on. So I
>>> think
>>> you should go back into hwc and find out how this situation arises.
>>
>> So in this case, its providing a fence which causes the event to be set.
>>
>> I'll look some more, but it seems that we call this check
>> (drm_atomic_check_only) before we do the commit apply the modeset that
>> would turn on the crtc.
>> Thus the check fails and we don't do the commit:
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/drm_atomic.c#n1659
>>
>> Just commenting out the EINVAL in the snippet above causes the crtc to
>> start up fine.
>>
>> So it seems like either the first modeset/plane update shouldn't be
>> done along w/ a fence, or the kernel should maybe skip setting the
>> event?
>>
>
> I'd tend to focus more on why the crtc is not active in the new state.
> Which is something that's specified in the atomic commit coming from
> hwc, right?
Ah. Sounds like I've been mixing up the kernel's state of the hardware
with the requested state to be committed.
Many thanks for the clarification. I'll dig a bit further.
thanks
-john
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge/synopsys: dsi: use common mipi_dsi_create_packet()
Hi Philippe, On Thu, Jan 18, 2018 at 11:40:48AM +, Philippe CORNU wrote: > On 01/11/2018 12:16 PM, Philippe CORNU wrote: > > To be honest, I do not really like the memcpy here too and I agree with > > you regarding the BE issue. > > > > My first "stm" driver (ie. before using this "freescale/rockchip" > > dw-mipi-dsi driver with the memcpy) used the "exact" same code as the > > Tegra dsi tegra_dsi_writesl() function with the 2 loops. > > > > https://elixir.free-electrons.com/linux/v4.14/source/drivers/gpu/drm/tegra/dsi.c#L1248 > > > > > > > > IMHO, it is better than memcpy... > > I added these 3 "documentation" lines, maybe we may reuse them or > > something similar... > > > > /* > > * Write 8-bit payload data into the 32-bit payload data register. > > * ex: payload data "0x01, 0x02, 0x03, 0x04, 0x05, 0x06" will become > > * "0x04030201 0x0605" 32-bit writes > > */ > > > > Not sure it helps to fix the BE issue but we may add a TODO stating that > > "this loop has not been tested on BE"... > > > > What is your opinion? I'm sorry, I don't think I noticed your reply here. I'm trying to unbury some email, but that's sometimes a losing battle... That code actually does look correct, and it's perhaps marginally better-looking in my opinion. It's up to you if you want to propose another patch :) At this point, it's only a matter of nice code, not correctness I believe. > As your patch has been merged, I have few short questions and for each > related new patch, I would like to know if you prefer that I implement > it or if you prefer to do it by yourself, it's really like you want, on > my side, no problem to make them all, some or none, I don't want us to > implement these in parallel :-) > > * Do you have any opinion regarding Tegra-like loops vs the memcpy? (see > my comment above) If you think the Tegra-like loops is a better approach > than memcpy, there is a small patch to write. My opinion is above. > * Returned value with number of bytes received/transferred: there is a > small patch to write I don't think I followed that one very well. I'm not sure my opinion really matters, as long as you get someone else to agree. I do not plan to write any such patch in the near term. > * Regarding read operations: I propose to add a TODO + DRM_WARN in case > someone want to use the API for read operations. Note that I plan to > implement the read feature but I do not know yet when and maybe Rockchip > people already have something ~ready? The warning would be nice to do now, regardless. Rockchip folks wrote up something for read support here [1], but it's based on a semi-forked version of the driver (we're trying to clean up the divergence, but it's not there yet). Perhaps it would provide useful fodder for your work. I don't think Rockchip is immediately working on upstreaming this particular patch, so it's totally fair to handle it yourself. It's got the GPL sign-off ;) Brian [1] https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/863347 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 2/2] drm/bridge/synopsys: dsi: Add a warning msg on dsi read operations
Hi Philippe,
I see you sent this out already today, while I only just responded
(late) to your questions about it... oh well :)
On Tue, Jan 23, 2018 at 6:26 AM, Philippe Cornu wrote:
> The DCS/GENERIC DSI read feature is not yet implemented so it
> is important to warn the host_transfer() caller in case of
> read operation requests.
>
> Signed-off-by: Philippe Cornu
> ---
> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> index 096cf5e5bb30..e46ddff8601c 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> @@ -417,7 +417,14 @@ static ssize_t dw_mipi_dsi_host_transfer(struct
> mipi_dsi_host *host,
> if (ret)
> return ret;
>
> - nb_bytes = packet.size;
> + if (msg->rx_buf && msg->rx_len > 0) {
It feels like you should do this check *before* you start writing
anything. It's possible to have a combination TX/RX command, and it
would be counterintuitive to only do half the operation then return
with an argument error.
> + /* TODO dw drv improvements: implement read feature */
> + dev_warn(dsi->dev, "read operations not yet implemented\n");
> + return -EPERM;
I'm not sure -EPERM is right. Feels like -EINVAL, -ENOSYS, or
-EOPNOTSUPP. I think -ENOSYS actually has been abused somewhat, so
maybe one of the other two.
> +
Spurious blank line?
> + } else {
> + nb_bytes = packet.size;
> + }
You don't actually need to put this sort of thing in the 'else' case.
The other branch is an error-handling case, which definitely 'return's
early, and it's pretty standard coding style to avoid indenting the
"good" path like this.
Brian
>
> return nb_bytes;
> }
> --
> 2.15.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 1/2] drm/bridge/synopsys: dsi: Fix dsi_host_transfer() return value
Hi Philippe,
On Tue, Jan 23, 2018 at 6:26 AM, Philippe Cornu wrote:
> The dw_mipi_dsi_host_transfer() must return the number of
> bytes transmitted/received on success instead of 0.
I'm a little confused. As of the latest drm-misc-next I'm looking at,
this still has conflicting documentation.
For ->transfer():
On success it shall return the number of bytes
* transmitted for write packets or the number of bytes received for read
* packets.
While mipi_dsi_generic_read() says:
* Return: The number of bytes successfully read or a negative error code on
* failure.
But it just returns the value that ->transfer() returns.
So I'm not sure whether the documentation is still wrong, or if the
implementation is.
Anyway, I guess maybe that isn't super-critical to *this* patch, since
we don't have RX support yet...
> Note: nb_bytes is introduced in this patch as it will be
> re-used with the future dcs/generic dsi read feature.
It feels like you could just wait to add that when you need it? It
really feels trivial and useless right now :)
Brian
>
> Signed-off-by: Philippe Cornu
> ---
> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> index f458798af788..096cf5e5bb30 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> @@ -403,7 +403,7 @@ static ssize_t dw_mipi_dsi_host_transfer(struct
> mipi_dsi_host *host,
> {
> struct dw_mipi_dsi *dsi = host_to_dsi(host);
> struct mipi_dsi_packet packet;
> - int ret;
> + int ret, nb_bytes;
>
> ret = mipi_dsi_create_packet(&packet, msg);
> if (ret) {
> @@ -413,7 +413,13 @@ static ssize_t dw_mipi_dsi_host_transfer(struct
> mipi_dsi_host *host,
>
> dw_mipi_message_config(dsi, msg);
>
> - return dw_mipi_dsi_write(dsi, &packet);
> + ret = dw_mipi_dsi_write(dsi, &packet);
> + if (ret)
> + return ret;
> +
> + nb_bytes = packet.size;
> +
> + return nb_bytes;
> }
>
> static const struct mipi_dsi_host_ops dw_mipi_dsi_host_ops = {
> --
> 2.15.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH] HACK: drm_atomic: Don't try to set vblank if crtc isn't active
On Tue, Jan 23, 2018 at 12:44 PM, Sean Paul wrote:
> On Tue, Jan 23, 2018 at 2:23 PM, John Stultz wrote:
>> On Tue, Jan 23, 2018 at 7:58 AM, Sean Paul wrote:
>>> On Tue, Jan 23, 2018 at 12:30:58AM -0800, John Stultz wrote:
In trying to use the drm_hwcomposer on HiKey, I found things
wouldn't initialize due to the following check in
drm_atomic_crtc_check() failing:
if (state->event && !state->active && !crtc->state->active) {
DRM_DEBUG_ATOMIC("[CRTC:%d:%s] requesting event but off\n",
crtc->base.id, crtc->name);
return -EINVAL;
}
>>>
>>> I think the answer is in the comment directly above this code. Having an
>>> event
>>> present while the crtc _stays_ off is the problem. So drm_hwc is requesting
>>> an
>>> event (or providing a fence) for a crtc which it does not turn on. So I
>>> think
>>> you should go back into hwc and find out how this situation arises.
>>
>> So in this case, its providing a fence which causes the event to be set.
>>
>> I'll look some more, but it seems that we call this check
>> (drm_atomic_check_only) before we do the commit apply the modeset that
>> would turn on the crtc.
>> Thus the check fails and we don't do the commit:
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/drm_atomic.c#n1659
>>
>> Just commenting out the EINVAL in the snippet above causes the crtc to
>> start up fine.
>>
>> So it seems like either the first modeset/plane update shouldn't be
>> done along w/ a fence, or the kernel should maybe skip setting the
>> event?
>>
>
> I'd tend to focus more on why the crtc is not active in the new state.
> Which is something that's specified in the atomic commit coming from
> hwc, right?
Yes! hwc isn't setting the active property, I'll send a fix to
drm_hwcomposer soon. Thanks so much again for the guidance here!
thanks
-john
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104736] Kernel panic with agd5's drm-next-4.17-wip & GFX8/Polaris10/Ellesmere/Rx-480-8GiB
https://bugs.freedesktop.org/show_bug.cgi?id=104736 --- Comment #2 from Alex Deucher --- does manually loading gpu_sched before amdgpu fix the issue? -- 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 104756] [bisected] [kabini] [regression] [drm:amdgpufb_create] *ERROR* failed to create fbcon object -12
https://bugs.freedesktop.org/show_bug.cgi?id=104756 Bug ID: 104756 Summary: [bisected] [kabini] [regression] [drm:amdgpufb_create] *ERROR* failed to create fbcon object -12 Product: DRI Version: DRI git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: m...@fireburn.co.uk Created attachment 136922 --> https://bugs.freedesktop.org/attachment.cgi?id=136922&action=edit Dmesg with errors I've been seeing messages about being unable to allocate an fbcon object I've bisected it back to: 4983e48c8539282be15f660bdd2c4260467b1190 is the first bad commit commit 4983e48c8539282be15f660bdd2c4260467b1190 Author: Lucas Stach Date: Wed Dec 6 17:49:40 2017 +0100 drm/sched: move fence slab handling to module init/exit This is the only part of the scheduler which must not be called from different drivers. Move it to module init/exit so it is done a single time when loading the scheduler. Reviewed-by: Chunming Zhou Tested-by: Dieter Nützel Acked-by: Alex Deucher Signed-off-by: Lucas Stach Signed-off-by: Alex Deucher I see the issue with both DC and the old display setting 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 104756] [bisected] [kabini] [regression] [drm:amdgpufb_create] *ERROR* failed to create fbcon object -12
https://bugs.freedesktop.org/show_bug.cgi?id=104756 Mike Lothian changed: What|Removed |Added CC||m...@fireburn.co.uk --- Comment #1 from Mike Lothian --- Created attachment 136923 --> https://bugs.freedesktop.org/attachment.cgi?id=136923&action=edit Dmesg with revert -- 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 104756] [bisected] [kabini] [regression] [drm:amdgpufb_create] *ERROR* failed to create fbcon object -12
https://bugs.freedesktop.org/show_bug.cgi?id=104756 Alex Deucher changed: What|Removed |Added Attachment #136922|application/x-dc-rom|text/plain mime type|| -- 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 102372] [dc] [kabini] Errors during startup - X doesn't start
https://bugs.freedesktop.org/show_bug.cgi?id=102372 --- Comment #11 from Mike Lothian --- Whilst I still get the following message: [0.583506] [drm:construct] *ERROR* construct: Invalid Connector ObjectID from Adapter Service for connector index:1! type 0 expected 3 DC does now work on Kabini, so can the following revert be applied -- 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 102372] [dc] [kabini] Errors during startup - X doesn't start
https://bugs.freedesktop.org/show_bug.cgi?id=102372 --- Comment #12 from Mike Lothian --- Created attachment 136924 --> https://bugs.freedesktop.org/attachment.cgi?id=136924&action=edit Revert of the Kabini DC disablement I can send this to the list, though happy for you just to apply it -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC][PATCH 1/4 v2] drm_hwcomposer: Make sure we set the active state when doing modesets
In trying to use drm_hwcomposer with HiKey/HiKey960 boards, I
found that the crtc wouldn't intitalize and the atomic commit
calls were failing.
I initially chased this down to following check in the kernel
drm_atomic_crtc_check() function failing:
if (state->event && !state->active && !crtc->state->active) {
DRM_DEBUG_ATOMIC("[CRTC:%d:%s] requesting event but off\n",
crtc->base.id, crtc->name);
return -EINVAL;
}
Where because a fence was submitted state->event was set, but
the crtc state was not active. This results in the atomic commit
to fail and no mode to be set.
After hacking around this in the kernel, Sean Paul helped me
understand that it was the kernel complaining about the crtc
state being provided in the atomic commit which did not have the
active flag set.
Thus, the proper fix is to make sure when we do the modesetting
that we also set the crtc state active flag in property set.
With this change, the kernel no longer rejects the atomic commit
and the crtc initializes properly.
Cc: Marissa Wall
Cc: Sean Paul
Cc: Dmitry Shmidt
Cc: Robert Foss
Cc: Matt Szczesiak
Cc: Liviu Dudau
Cc: David Hanna
Cc: Rob Herring
Signed-off-by: John Stultz
---
drmdisplaycompositor.cpp | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drmdisplaycompositor.cpp b/drmdisplaycompositor.cpp
index acd13b8..3a20b31 100644
--- a/drmdisplaycompositor.cpp
+++ b/drmdisplaycompositor.cpp
@@ -520,6 +520,13 @@ int
DrmDisplayCompositor::CommitFrame(DrmDisplayComposition *display_comp,
}
if (mode_.needs_modeset) {
+ret = drmModeAtomicAddProperty(pset, crtc->id(),
crtc->active_property().id(), 1);
+if (ret < 0) {
+ ALOGE("Failed to add crtc active to pset\n");
+ drmModeAtomicFree(pset);
+ return ret;
+}
+
ret = drmModeAtomicAddProperty(pset, crtc->id(),
crtc->mode_property().id(),
mode_.blob_id) < 0 ||
drmModeAtomicAddProperty(pset, connector->id(),
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC][PATCH 4/4 v2] drm_hwcomposer: Try to fallback if GLCompisition fails
When using drm_hwcomposer with the hikey board, the resulting
display shows lots of tearing.
This seems to be due to EGLcomposition not initializing
properly, potentially due to I'm guessing limitations of what
the utgard mali driver can do. I've noted that with the
HiKey960 board, this patch is *not* necessary.
Hacking around a bit, I found that since the glworker code
isn't running properly, we never call glFinish(), which
is required to fix the tearing.
Ideas for a better way to implement this would be greatly
appreciated!
Cc: Marissa Wall
Cc: Sean Paul
Cc: Dmitry Shmidt
Cc: Robert Foss
Cc: Matt Szczesiak
Cc: Liviu Dudau
Cc: David Hanna
Cc: Rob Herring
Signed-off-by: John Stultz
---
v2:
* Simplified, focusing on the key glFinsh() call
---
drmdisplaycompositor.cpp | 4
1 file changed, 4 insertions(+)
diff --git a/drmdisplaycompositor.cpp b/drmdisplaycompositor.cpp
index 3a20b31..eb0b77a 100644
--- a/drmdisplaycompositor.cpp
+++ b/drmdisplaycompositor.cpp
@@ -439,6 +439,10 @@ int
DrmDisplayCompositor::PrepareFrame(DrmDisplayComposition *display_comp) {
fb.set_release_fence_fd(ret);
ret = 0;
+} else {
+ /*If we're not doing anything, block to avoid tearing */
+ glFinish();
+ return 0;
}
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC][PATCH 3/4 v2] drm_hwcomposer: Use client compositing if there is only one plane
Originally based on work by Rob Herring, this patch changes
ValidateDisplay() so that if there is only one plane, we modify
Device composited layers to be Client composited.
Without this, on devices with just one plane, nothing gets
displayed on the screen.
Suggestions for alternative solutions here would be greatly
appreciated!
Cc: Marissa Wall
Cc: Sean Paul
Cc: Dmitry Shmidt
Cc: Robert Foss
Cc: Matt Szczesiak
Cc: Liviu Dudau
Cc: David Hanna
Cc: Rob Herring
Signed-off-by: John Stultz
---
v2:
* Rework Rob's change to check planes
---
drmhwctwo.cpp | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drmhwctwo.cpp b/drmhwctwo.cpp
index dfca1a6..6d88c5c 100644
--- a/drmhwctwo.cpp
+++ b/drmhwctwo.cpp
@@ -695,6 +695,13 @@ HWC2::Error
DrmHwcTwo::HwcDisplay::ValidateDisplay(uint32_t *num_types,
layer.set_validated_type(HWC2::Composition::Client);
++*num_types;
break;
+ case HWC2::Composition::Device:
+ /* If we only have one plane, always do Client composition */
+if (primary_planes_.size() + overlay_planes_.size() == 1) {
+ layer.set_validated_type(HWC2::Composition::Client);
+ ++*num_types;
+ break;
+}
default:
layer.set_validated_type(layer.sf_type());
break;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC][PATCH 2/4 v2] drm_hwcomposer: Add platformhisi buffer importer for hikey and hikey960
This allows for importing buffers allocated from the
hikey and hikey960 gralloc implelementations.
Cc: Marissa Wall
Cc: Sean Paul
Cc: Dmitry Shmidt
Cc: Robert Foss
Cc: Matt Szczesiak
Cc: Liviu Dudau
Cc: David Hanna
Cc: Rob Herring
Signed-off-by: John Stultz
---
v2:
* Make platformhisi and the generic importer exclusive in the build
* Fixup vendor check
---
Android.mk | 15 -
platformhisi.cpp | 200 +++
platformhisi.h | 50 ++
3 files changed, 264 insertions(+), 1 deletion(-)
create mode 100644 platformhisi.cpp
create mode 100644 platformhisi.h
diff --git a/Android.mk b/Android.mk
index 8b11e37..4a91383 100644
--- a/Android.mk
+++ b/Android.mk
@@ -66,7 +66,6 @@ LOCAL_SRC_FILES := \
glworker.cpp \
hwcutils.cpp \
platform.cpp \
- platformdrmgeneric.cpp \
separate_rects.cpp \
virtualcompositorworker.cpp \
vsyncworker.cpp
@@ -75,7 +74,21 @@ LOCAL_CPPFLAGS += \
-DHWC2_USE_CPP11 \
-DHWC2_INCLUDE_STRINGIFICATION
+
+ifeq ($(TARGET_PRODUCT),hikey960)
+LOCAL_CPPFLAGS += -DUSE_HISI_IMPORTER
+LOCAL_C_INCLUDES += device/linaro/hikey/gralloc960/
+LOCAL_SRC_FILES += platformhisi.cpp
+else
+ifeq ($(TARGET_PRODUCT),hikey)
+LOCAL_CPPFLAGS += -DUSE_HISI_IMPORTER -DHIKEY
+LOCAL_C_INCLUDES += device/linaro/hikey/gralloc/
+LOCAL_SRC_FILES += platformhisi.cpp
+else
LOCAL_CPPFLAGS += -DUSE_DRM_GENERIC_IMPORTER
+LOCAL_SRC_FILES += platformdrmgeneric.cpp
+endif
+endif
LOCAL_MODULE := hwcomposer.drm
LOCAL_MODULE_TAGS := optional
diff --git a/platformhisi.cpp b/platformhisi.cpp
new file mode 100644
index 000..b46bf7c
--- /dev/null
+++ b/platformhisi.cpp
@@ -0,0 +1,200 @@
+/*
+ * Copyright (C) 2015 The Android Open Source Project
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+#define LOG_TAG "hwc-platform-hisi"
+
+#include "drmresources.h"
+#include "platform.h"
+#include "platformhisi.h"
+
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include "gralloc_priv.h"
+
+
+namespace android {
+
+#ifdef USE_HISI_IMPORTER
+// static
+Importer *Importer::CreateInstance(DrmResources *drm) {
+ HisiImporter *importer = new HisiImporter(drm);
+ if (!importer)
+return NULL;
+
+ int ret = importer->Init();
+ if (ret) {
+ALOGE("Failed to initialize the hisi importer %d", ret);
+delete importer;
+return NULL;
+ }
+ return importer;
+}
+#endif
+
+HisiImporter::HisiImporter(DrmResources *drm) : drm_(drm) {
+}
+
+HisiImporter::~HisiImporter() {
+}
+
+int HisiImporter::Init() {
+ int ret = hw_get_module(GRALLOC_HARDWARE_MODULE_ID,
+ (const hw_module_t **)&gralloc_);
+ if (ret) {
+ALOGE("Failed to open gralloc module %d", ret);
+return ret;
+ }
+
+ if (strcasecmp(gralloc_->common.author, "ARM Ltd."))
+ALOGW("Using non-ARM gralloc module: %s/%s\n", gralloc_->common.name,
+ gralloc_->common.author);
+
+ return 0;
+}
+
+#ifdef HIKEY
+uint32_t HisiImporter::ConvertHalFormatToDrm(uint32_t hal_format) {
+ switch (hal_format) {
+case HAL_PIXEL_FORMAT_RGB_888:
+ return DRM_FORMAT_BGR888;
+case HAL_PIXEL_FORMAT_BGRA_:
+ return DRM_FORMAT_ARGB;
+case HAL_PIXEL_FORMAT_RGBX_:
+ return DRM_FORMAT_XBGR;
+case HAL_PIXEL_FORMAT_RGBA_:
+ return DRM_FORMAT_ABGR;
+case HAL_PIXEL_FORMAT_RGB_565:
+ return DRM_FORMAT_BGR565;
+case HAL_PIXEL_FORMAT_YV12:
+ return DRM_FORMAT_YVU420;
+default:
+ ALOGE("Cannot convert hal format to drm format %u", hal_format);
+ return -EINVAL;
+ }
+}
+#else /* HIKEY960 case*/
+uint32_t HisiImporter::ConvertHalFormatToDrm(uint32_t hal_format) {
+ switch (hal_format) {
+case HAL_PIXEL_FORMAT_RGB_888:
+ return DRM_FORMAT_BGR888;
+case HAL_PIXEL_FORMAT_BGRA_:
+ return DRM_FORMAT_XBGR;
+case HAL_PIXEL_FORMAT_RGBX_:
+ return DRM_FORMAT_XBGR;
+case HAL_PIXEL_FORMAT_RGBA_:
+ return DRM_FORMAT_XBGR;
+case HAL_PIXEL_FORMAT_RGB_565:
+ return DRM_FORMAT_BGR565;
+case HAL_PIXEL_FORMAT_YV12:
+ return DRM_FORMAT_YVU420;
+default:
+ ALOGE("Cannot convert hal format to drm format %u", hal_format);
+ return -EINVAL;
+ }
+}
+#endif /* HIKEY */
+
+EGLImageKHR HisiImporter::ImportImage(EGLDisplay egl_display, buffer_handle_t
handle) {
+ private_handle_t const *hnd = reinterpret_cast <
[RFC][PATCH 0/4 v2] drm_hwcomposer: Changes to support HiKey/HiKey960
Here is a second revision of the early RFC patch set I wanted to send out to get some review and feedback on. I've been working to enable the drm_hwcomposer for HiKey and HiKey960 boards in AOSP, and this patchset contains the required changes to the drm_hwcomposer code to get things working. I'm really quite naive when it comes to graphics, and I'm sure I don't fully understand the drm_hwcomposer code, so forgive me if I've done anything terribly stupid here. The first two patches are, I think, mostly straightforward, the first being a bug fix, and the second adding an importer for the ARM gralloc implementations. The next two patches, while largely reworked from v1, are still a bit iffy, and I'd appreciate guidance on how to improve them. The third forcing client composition if there is only one layer and the fourth providing a glFinish() fallback which fixes on-screen tearing when the gl compositior fails to initalize. I also have two additional patches, which I've not included here - as they still need work, which get the glcompositor to properly function on HiKey960. But the curious can find them here: https://github.com/johnstultz-work/drm_hwcomposer/commits/drm_hwc If anyone wants to try the code out on either a HiKey or HiKey960, you will need just the 4 patches here on top of the freedesktop/master branch of drm_hwcomposer. You'll also need the freedesktop/master branch of libdrm. You'll need the following patches to the device/linaro/hikey project: https://github.com/johnstultz-work/android_device_linaro_hikey/commits/drm_hwc And you'll need to replace the kernel Image-dtb with one built from the following tree: https://git.linaro.org/people/john.stultz/android-dev.git/log/?h=dev/hikey-hwcomposer-deps Any thoughts or feedback will be very much appreciated! Many thanks to Rob Herring and Matt Szczesiak for help to get this working so far! And Sean Paul for his recent help working out the crtc activiation bug. Thanks so much for your time! -john Cc: Marissa Wall Cc: Sean Paul Cc: Dmitry Shmidt Cc: Robert Foss Cc: Matt Szczesiak Cc: Liviu Dudau Cc: David Hanna Cc: Rob Herring John Stultz (4): drm_hwcomposer: Make sure we set the active state when doing modesets drm_hwcomposer: Add platformhisi buffer importer for hikey and hikey960 drm_hwcomposer: Use client compositing if there is only one plane drm_hwcomposer: Try to fallback if GLCompisition fails Android.mk | 15 +++- drmdisplaycompositor.cpp | 11 +++ drmhwctwo.cpp| 7 ++ platformhisi.cpp | 200 +++ platformhisi.h | 50 5 files changed, 282 insertions(+), 1 deletion(-) create mode 100644 platformhisi.cpp create mode 100644 platformhisi.h -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge/synopsys: dsi: Adopt SPDX identifiers
Hi Philippe, On Tuesday, 23 January 2018 12:25:51 EET Philippe CORNU wrote: > On 01/23/2018 12:30 AM, Laurent Pinchart wrote: > > On Monday, 22 January 2018 12:26:08 EET Philippe Cornu wrote: > >> Add SPDX identifiers to the Synopsys DesignWare MIPI DSI > >> host controller driver. > >> > >> Signed-off-by: Philippe Cornu > >> --- > >> > >> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 6 +- > >> 1 file changed, 1 insertion(+), 5 deletions(-) > >> > >> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c > >> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c index > >> 46b0e73404d1..e06836dec77c 100644 > >> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c > >> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c > >> @@ -1,12 +1,8 @@ > >> +// SPDX-License-Identifier: GPL-2.0 > > > > According to Documentation/process/license-rules.txt this would change > > the existing license. The correct identifier is GPL-2.0+. > > You are right, I did not put the correct identifier :( > > After reading more spdx.org, I wonder if the correct value should be > GPL-2.0-or-later instead of GPL-2.0+ > > https://spdx.org/licenses/GPL-2.0-or-later.html > https://spdx.org/licenses/GPL-2.0+.html > > What is your opinion? I agree in principle, and I've even asked for that before, but I've been told that we should stick to the license identifiers defined in Documentation/ process/license-rules.txt. The file might get updated to use GPL-2.0-or-later and GPL-2.0-only later, and kernel sources will likely then get patched in one go. > >> /* > >> * Copyright (c) 2016, Fuzhou Rockchip Electronics Co., Ltd > >> * Copyright (C) STMicroelectronics SA 2017 > >> * > >> - * This program is free software; you can redistribute it and/or modify > >> - * it under the terms of the GNU General Public License as published by > >> - * the Free Software Foundation; either version 2 of the License, or > >> - * (at your option) any later version. > >> - * > >> * Modified by Philippe Cornu > >> * This generic Synopsys DesignWare MIPI DSI host driver is based on the > >> * Rockchip version from rockchip/dw-mipi-dsi.c with phy & bridge APIs. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/5] drm/rcar-du: Use drm_mode_get_hv_timing() to populate plane clip rectangle
Hi Ville,
Thank you for the patch.
On Tuesday, 23 January 2018 19:08:53 EET Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.
>
> No functional changes as the code already uses crtc_state->mode
> to populate the clip, which is also what drm_mode_get_hv_timing()
> uses.
>
> Once everyone agrees on this we can move the clip handling into
> drm_atomic_helper_check_plane_state().
>
> Cc: Laurent Pinchart
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/rcar-du/rcar_du_plane.c | 9 -
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> b/drivers/gpu/drm/rcar-du/rcar_du_plane.c index 4a3d16cf3ed6..5687a94d4cb1
> 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> @@ -572,7 +572,7 @@ int __rcar_du_plane_atomic_check(struct drm_plane
> *plane, {
> struct drm_device *dev = plane->dev;
> struct drm_crtc_state *crtc_state;
> - struct drm_rect clip;
> + struct drm_rect clip = {};
Nitpicking, isn't the correct C99 zero initializer { 0 } ? I doesn't matter
too much as the variable is removed in patch 5/5 but we could as well fix it
if needed.
Apart from that,
Reviewed-by: Laurent Pinchart
> int ret;
>
> if (!state->crtc) {
> @@ -589,10 +589,9 @@ int __rcar_du_plane_atomic_check(struct drm_plane
> *plane, if (IS_ERR(crtc_state))
> return PTR_ERR(crtc_state);
>
> - clip.x1 = 0;
> - clip.y1 = 0;
> - clip.x2 = crtc_state->mode.hdisplay;
> - clip.y2 = crtc_state->mode.vdisplay;
> + if (crtc_state->enable)
> + drm_mode_get_hv_timing(&crtc_state->mode,
> +&clip.x2, &clip.y2);
>
> ret = drm_atomic_helper_check_plane_state(state, crtc_state, &clip,
> DRM_PLANE_HELPER_NO_SCALING,
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/5] drm: Don't pass clip to drm_atomic_helper_check_plane_state()
Hi Ville,
Thank you for the patch.
On Tuesday, 23 January 2018 19:08:57 EET Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Move the plane clip rectangle handling into
> drm_atomic_helper_check_plane_state(). Drivers no longer
> have to worry about such mundane details.
>
> v2: Convert armada, rcar, and sun4i as well
>
> Cc: Liviu Dudau
> Cc: Brian Starkey
> Cc: Mali DP Maintainers
> Cc: Daniel Vetter
> Cc: Gustavo Padovan
> Cc: Sean Paul
> Cc: Philipp Zabel
> Cc: CK Hu
> Cc: Neil Armstrong
> Cc: Rob Clark
> Cc: Ben Skeggs
> Cc: Laurent Pinchart
> Cc: Sandy Huang
> Cc: "Heiko Stübner"
> Cc: Maxime Ripard
> Cc: Thierry Reding
> Cc: VMware Graphics
> Cc: Sinclair Yeh
> Cc: Thomas Hellstrom
> Cc: Shawn Guo
> Cc: Archit Taneja
> Cc: linux-amlo...@lists.infradead.org
> Cc: linux-arm-...@vger.kernel.org
> Cc: freedr...@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Cc: linux-renesas-...@vger.kernel.org
> Cc: linux-te...@vger.kernel.org
> Cc: Russell King
> Suggested-by: Daniel Vetter
> Signed-off-by: Ville Syrjälä
> Reviewed-by: Daniel Vetter
> Reviewed-by: Thierry Reding
> Reviewed-by: Archit Taneja #msm
> ---
> drivers/gpu/drm/arm/hdlcd_crtc.c| 7 +--
> drivers/gpu/drm/arm/malidp_planes.c | 7 +--
> drivers/gpu/drm/armada/armada_crtc.c| 8 ++--
> drivers/gpu/drm/armada/armada_overlay.c | 8 ++--
> drivers/gpu/drm/drm_atomic_helper.c | 12 +++-
> drivers/gpu/drm/drm_plane_helper.c | 11 +++
> drivers/gpu/drm/drm_simple_kms_helper.c | 6 --
> drivers/gpu/drm/i915/intel_display.c| 12
> drivers/gpu/drm/imx/ipuv3-plane.c | 7 +--
> drivers/gpu/drm/mediatek/mtk_drm_plane.c| 7 +--
> drivers/gpu/drm/meson/meson_plane.c | 7 +--
> drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 14 ++
> drivers/gpu/drm/nouveau/nv50_display.c | 12
> drivers/gpu/drm/rcar-du/rcar_du_plane.c | 7 +--
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 7 +--
> drivers/gpu/drm/sun4i/sun8i_ui_layer.c | 7 +--
> drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 7 +--
> drivers/gpu/drm/tegra/plane.c | 7 +--
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 7 +--
> drivers/gpu/drm/zte/zx_plane.c | 13 +
> include/drm/drm_atomic_helper.h | 1 -
> include/drm/drm_plane_helper.h | 1 -
> 22 files changed, 28 insertions(+), 147 deletions(-)
[snip]
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c index ab4032167094..9fb96f9cc36e
> 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -699,7 +699,6 @@ EXPORT_SYMBOL(drm_atomic_helper_check_modeset);
> * drm_atomic_helper_check_plane_state() - Check plane state for validity
> * @plane_state: plane state to check
> * @crtc_state: crtc state to check
> - * @clip: integer clipping coordinates
> * @min_scale: minimum @src:@dest scaling factor in 16.16 fixed point
> * @max_scale: maximum @src:@dest scaling factor in 16.16 fixed point
> * @can_position: is it legal to position the plane such that it
> @@ -719,7 +718,6 @@ EXPORT_SYMBOL(drm_atomic_helper_check_modeset);
> */
> int drm_atomic_helper_check_plane_state(struct drm_plane_state
> *plane_state, const struct drm_crtc_state *crtc_state,
> - const struct drm_rect *clip,
> int min_scale,
> int max_scale,
> bool can_position,
> @@ -729,6 +727,7 @@ int drm_atomic_helper_check_plane_state(struct
> drm_plane_state *plane_state, struct drm_rect *src = &plane_state->src;
> struct drm_rect *dst = &plane_state->dst;
> unsigned int rotation = plane_state->rotation;
> + struct drm_rect clip = {};
Isn't the correct C99 zero initializer { 0, } ?
Apart from that,
Reviewed-by: Laurent Pinchart
> int hscale, vscale;
>
> WARN_ON(plane_state->crtc && plane_state->crtc != crtc_state->crtc);
> @@ -764,7 +763,10 @@ int drm_atomic_helper_check_plane_state(struct
> drm_plane_state *plane_state, return -ERANGE;
> }
>
> - plane_state->visible = drm_rect_clip_scaled(src, dst, clip, hscale,
> vscale);
> + if (crtc_state->enable)
> + drm_mode_get_hv_timing(&crtc_state->mode, &clip.x2, &clip.y2);
> +
> + plane_state->visible = drm_rect_clip_scaled(src, dst, &clip, hscale,
> vscale);
>
> drm_rect_rotate_inv(src, fb->width << 16, fb->height << 16, rotation);
>
> @@ -778,10 +780,10 @@ int drm_atomic_helper_check_plane_state(struct
> drm_plane_state *plane_state, */
> return 0;
>
> - if (!can_position && !drm_rect_equals(dst, clip)) {
> + if (!can_position && !drm_rect_equals(dst, &clip)) {
> DRM_DEBUG_KMS(
[Bug 104602] [apitrace] Graphical artifacts in Civilization VI on RX Vega
https://bugs.freedesktop.org/show_bug.cgi?id=104602 Jason Playne changed: What|Removed |Added Summary|Graphical artifacts in |[apitrace] Graphical |Civilization VI on RX Vega |artifacts in Civilization ||VI on RX Vega -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104736] Kernel panic with agd5's drm-next-4.17-wip & GFX8/Polaris10/Ellesmere/Rx-480-8GiB
https://bugs.freedesktop.org/show_bug.cgi?id=104736
--- Comment #3 from Robin Kauffman ---
(In reply to Alex Deucher from comment #2)
> does manually loading gpu_sched before amdgpu fix the issue?
Can try to do so, but unsure as to how given that pretty much the entire
graphics stack is compiled into the kernel image.
Reverting commit 4983e48c8539282be15f660bdd2c4260467b1190 ('drm/sched: move
fence slab handling to module init/exit') fixes the issue, and thus this bug
may be a duplicate of bug #104756. If so, this bug can be closed as a
duplicate, or I can experiment with trying to force gpu_sched up first.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/5] drm: rename {drm_clflush_sg, drm_clflush_pages}
Since clfush is an x86-only instruction, these function names won't
make much sense if we start adding cases for other architectures.
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/drm_cache.c | 12 ++--
drivers/gpu/drm/i915/i915_gem.c | 2 +-
drivers/gpu/drm/i915/i915_gem_clflush.c | 2 +-
drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 2 +-
drivers/gpu/drm/ttm/ttm_tt.c| 2 +-
drivers/gpu/drm/vgem/vgem_drv.c | 2 +-
include/drm/drm_cache.h | 4 ++--
7 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
index 3bd76e918b5d..89cdd32fe1f3 100644
--- a/drivers/gpu/drm/drm_cache.c
+++ b/drivers/gpu/drm/drm_cache.c
@@ -70,7 +70,7 @@ static void drm_cache_flush_clflush(struct page *pages[],
#endif
/**
- * drm_clflush_pages - Flush dcache lines of a set of pages.
+ * drm_flush_pages - Flush dcache lines of a set of pages.
* @pages: List of pages to be flushed.
* @num_pages: Number of pages in the array.
*
@@ -78,7 +78,7 @@ static void drm_cache_flush_clflush(struct page *pages[],
* to a page in the array.
*/
void
-drm_clflush_pages(struct page *pages[], unsigned long num_pages)
+drm_flush_pages(struct page *pages[], unsigned long num_pages)
{
#if defined(CONFIG_X86)
@@ -109,17 +109,17 @@ drm_clflush_pages(struct page *pages[], unsigned long
num_pages)
WARN_ON_ONCE(1);
#endif
}
-EXPORT_SYMBOL(drm_clflush_pages);
+EXPORT_SYMBOL(drm_flush_pages);
/**
- * drm_clflush_sg - Flush dcache lines pointing to a scather-gather.
+ * drm_flush_sg - Flush dcache lines pointing to a scather-gather.
* @st: struct sg_table.
*
* Flush every data cache line entry that points to an address in the
* sg.
*/
void
-drm_clflush_sg(struct sg_table *st)
+drm_flush_sg(struct sg_table *st)
{
#if defined(CONFIG_X86)
if (static_cpu_has(X86_FEATURE_CLFLUSH)) {
@@ -140,7 +140,7 @@ drm_clflush_sg(struct sg_table *st)
WARN_ON_ONCE(1);
#endif
}
-EXPORT_SYMBOL(drm_clflush_sg);
+EXPORT_SYMBOL(drm_flush_sg);
/**
* drm_clflush_virt_range - Flush dcache lines of a region
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 8bc3283484be..a8c0703a096d 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -259,7 +259,7 @@ __i915_gem_object_release_shmem(struct drm_i915_gem_object
*obj,
if (needs_clflush &&
(obj->base.read_domains & I915_GEM_DOMAIN_CPU) == 0 &&
!(obj->cache_coherent & I915_BO_CACHE_COHERENT_FOR_READ))
- drm_clflush_sg(pages);
+ drm_flush_sg(pages);
__start_cpu_write(obj);
}
diff --git a/drivers/gpu/drm/i915/i915_gem_clflush.c
b/drivers/gpu/drm/i915/i915_gem_clflush.c
index b9b53ac14176..f6cff6e5c520 100644
--- a/drivers/gpu/drm/i915/i915_gem_clflush.c
+++ b/drivers/gpu/drm/i915/i915_gem_clflush.c
@@ -71,7 +71,7 @@ static const struct dma_fence_ops i915_clflush_ops = {
static void __i915_do_clflush(struct drm_i915_gem_object *obj)
{
GEM_BUG_ON(!i915_gem_object_has_pages(obj));
- drm_clflush_sg(obj->mm.pages);
+ drm_flush_sg(obj->mm.pages);
intel_fb_obj_flush(obj, ORIGIN_CPU);
}
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index 1d9655576b6e..8ac7eb25e46d 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
@@ -100,7 +100,7 @@ static int rockchip_gem_get_pages(struct
rockchip_gem_object *rk_obj)
* Fake up the SG table so that dma_sync_sg_for_device() can be used
* to flush the pages associated with it.
*
-* TODO: Replace this by drm_clflush_sg() once it can be implemented
+* TODO: Replace this by drm_flush_sg() once it can be implemented
* without relying on symbols that are not exported.
*/
for_each_sg(rk_obj->sgt->sgl, s, rk_obj->sgt->nents, i)
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 5a046a3c543a..54b1971cd817 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -122,7 +122,7 @@ static int ttm_tt_set_caching(struct ttm_tt *ttm,
}
if (ttm->caching_state == tt_cached)
- drm_clflush_pages(ttm->pages, ttm->num_pages);
+ drm_flush_pages(ttm->pages, ttm->num_pages);
for (i = 0; i < ttm->num_pages; ++i) {
cur_page = ttm->pages[i];
diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index 2524ff116f00..802a97e1a4bf 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -325,7 +325,7 @@ static int vgem_prime_pin(struct drm_gem_object *obj)
/* Flush the object from the CPU cache so that importers can rely
* on coherent indirect access via the exported dma-address.
[PATCH 3/5] drm: add ARM64 flush implementations
This patch uses the __dma_map_area function to flush the cache
on ARM64.
v2: Don't use DMA API, call functions directly (Daniel)
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/drm_cache.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
index 5124582451c6..250cdfbb711f 100644
--- a/drivers/gpu/drm/drm_cache.c
+++ b/drivers/gpu/drm/drm_cache.c
@@ -159,6 +159,12 @@ drm_flush_pages(struct page *pages[], unsigned long
num_pages)
for (i = 0; i < num_pages; i++)
drm_cache_maint_page(pages[i], 0, PAGE_SIZE, DMA_TO_DEVICE,
dmac_map_area);
+#elif defined(CONFIG_ARM64)
+ unsigned long i;
+
+ for (i = 0; i < num_pages; i++)
+ __dma_map_area(phys_to_virt(page_to_phys(pages[i])), PAGE_SIZE,
+ DMA_TO_DEVICE);
#else
pr_err("Architecture has no drm_cache.c support\n");
WARN_ON_ONCE(1);
@@ -196,6 +202,13 @@ drm_flush_sg(struct sg_table *st)
for_each_sg_page(st->sgl, &sg_iter, st->nents, 0)
drm_cache_maint_page(sg_page_iter_page(&sg_iter), 0, PAGE_SIZE,
DMA_TO_DEVICE, dmac_map_area);
+#elif defined(CONFIG_ARM64)
+ int i;
+ struct scatterlist *sg;
+
+ for_each_sg(st->sgl, sg, st->nents, i)
+ __dma_map_area(phys_to_virt(sg_phys(sg)), sg->length,
+ DMA_TO_DEVICE);
#else
pr_err("Architecture has no drm_cache.c support\n");
WARN_ON_ONCE(1);
--
2.13.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/5] drm: use drm_flush_sg where possible
We should use our common cache maintenance functions when possible. Signed-off-by: Gurchetan Singh --- drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 7 ++- drivers/gpu/drm/tegra/gem.c | 7 ++- 2 files changed, 4 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c index 8ac7eb25e46d..0652c2f79719 100644 --- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c +++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c @@ -14,6 +14,7 @@ #include #include +#include #include #include #include @@ -99,15 +100,11 @@ static int rockchip_gem_get_pages(struct rockchip_gem_object *rk_obj) /* * Fake up the SG table so that dma_sync_sg_for_device() can be used * to flush the pages associated with it. -* -* TODO: Replace this by drm_flush_sg() once it can be implemented -* without relying on symbols that are not exported. */ for_each_sg(rk_obj->sgt->sgl, s, rk_obj->sgt->nents, i) sg_dma_address(s) = sg_phys(s); - dma_sync_sg_for_device(drm->dev, rk_obj->sgt->sgl, rk_obj->sgt->nents, - DMA_TO_DEVICE); + drm_flush_sg(rk_obj->sgt); return 0; diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c index 49b9bf28f872..0db403653adc 100644 --- a/drivers/gpu/drm/tegra/gem.c +++ b/drivers/gpu/drm/tegra/gem.c @@ -15,6 +15,7 @@ #include #include +#include #include #include "drm.h" @@ -229,15 +230,11 @@ static int tegra_bo_get_pages(struct drm_device *drm, struct tegra_bo *bo) /* * Fake up the SG table so that dma_sync_sg_for_device() can be used * to flush the pages associated with it. -* -* TODO: Replace this by drm_clflash_sg() once it can be implemented -* without relying on symbols that are not exported. */ for_each_sg(bo->sgt->sgl, s, bo->sgt->nents, i) sg_dma_address(s) = sg_phys(s); - dma_sync_sg_for_device(drm->dev, bo->sgt->sgl, bo->sgt->nents, - DMA_TO_DEVICE); + drm_flush_sg(bo->sgt); return 0; -- 2.13.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/5] drm: add ARM flush implementation
The dma_cache_maint_page function is important for cache maintenance on
ARM32 (this was determined via testing).
Since we desire direct control of the caches in drm_cache.c, let's make
a copy of the function, rename it and use it.
v2: Don't use DMA API, call functions directly (Daniel)
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/drm_cache.c | 61 +
1 file changed, 61 insertions(+)
diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
index 89cdd32fe1f3..5124582451c6 100644
--- a/drivers/gpu/drm/drm_cache.c
+++ b/drivers/gpu/drm/drm_cache.c
@@ -69,6 +69,55 @@ static void drm_cache_flush_clflush(struct page *pages[],
}
#endif
+#if defined(CONFIG_ARM)
+static void drm_cache_maint_page(struct page *page, unsigned long offset,
+size_t size, enum dma_data_direction dir,
+void (*op)(const void *, size_t, int))
+{
+ unsigned long pfn;
+ size_t left = size;
+
+ pfn = page_to_pfn(page) + offset / PAGE_SIZE;
+ offset %= PAGE_SIZE;
+
+ /*
+* A single sg entry may refer to multiple physically contiguous
+* pages. But we still need to process highmem pages individually.
+* If highmem is not configured then the bulk of this loop gets
+* optimized out.
+*/
+ do {
+ size_t len = left;
+ void *vaddr;
+
+ page = pfn_to_page(pfn);
+
+ if (PageHighMem(page)) {
+ if (len + offset > PAGE_SIZE)
+ len = PAGE_SIZE - offset;
+
+ if (cache_is_vipt_nonaliasing()) {
+ vaddr = kmap_atomic(page);
+ op(vaddr + offset, len, dir);
+ kunmap_atomic(vaddr);
+ } else {
+ vaddr = kmap_high_get(page);
+ if (vaddr) {
+ op(vaddr + offset, len, dir);
+ kunmap_high(page);
+ }
+ }
+ } else {
+ vaddr = page_address(page) + offset;
+ op(vaddr, len, dir);
+ }
+ offset = 0;
+ pfn++;
+ left -= len;
+ } while (left);
+}
+#endif
+
/**
* drm_flush_pages - Flush dcache lines of a set of pages.
* @pages: List of pages to be flushed.
@@ -104,6 +153,12 @@ drm_flush_pages(struct page *pages[], unsigned long
num_pages)
(unsigned long)page_virtual + PAGE_SIZE);
kunmap_atomic(page_virtual);
}
+#elif defined(CONFIG_ARM)
+ unsigned long i;
+
+ for (i = 0; i < num_pages; i++)
+ drm_cache_maint_page(pages[i], 0, PAGE_SIZE, DMA_TO_DEVICE,
+dmac_map_area);
#else
pr_err("Architecture has no drm_cache.c support\n");
WARN_ON_ONCE(1);
@@ -135,6 +190,12 @@ drm_flush_sg(struct sg_table *st)
if (wbinvd_on_all_cpus())
pr_err("Timed out waiting for cache flush\n");
+#elif defined(CONFIG_ARM)
+ struct sg_page_iter sg_iter;
+
+ for_each_sg_page(st->sgl, &sg_iter, st->nents, 0)
+ drm_cache_maint_page(sg_page_iter_page(&sg_iter), 0, PAGE_SIZE,
+DMA_TO_DEVICE, dmac_map_area);
#else
pr_err("Architecture has no drm_cache.c support\n");
WARN_ON_ONCE(1);
--
2.13.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/5] drm/vgem: flush page during page fault
This is required to use buffers allocated by vgem on AMD and ARM devices. We're experiencing a case where eviction of the cache races with userspace writes. To fix this, flush the cache after retrieving a page. Signed-off-by: Gurchetan Singh --- drivers/gpu/drm/vgem/vgem_drv.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c index 802a97e1a4bf..ed6db7218f04 100644 --- a/drivers/gpu/drm/vgem/vgem_drv.c +++ b/drivers/gpu/drm/vgem/vgem_drv.c @@ -112,6 +112,7 @@ static int vgem_gem_fault(struct vm_fault *vmf) break; } + drm_flush_pages(&page, 1); } return ret; } -- 2.13.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 00/10] rockchip: kevin: Enable edp display
Hi Thierry, Thanks for posting these :) Hi Archit, Thanks for your reply. On 01/10/2018 05:46 PM, Archit Taneja wrote: I don't know if the rest of the rockchip patches in the series depend on the 4 bridge patches. If they do, the rockchip maintainer can queue both rockchip and bridge patches. If not, I can pick up the bridge patches. Mark is no longer maintain rockchip drm driver, i will ask Sandy Huang to check these, thanks. Thanks, Archit ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
