Re: [PATCH 4/4] drm/panel: Add Rondo RB070D30 panel
Hi Konstantin
> >> + ctx->gpios.updn = devm_gpiod_get(>dev, "updn", GPIOD_OUT_LOW);
> >> + if (IS_ERR(ctx->gpios.updn)) {
> >> + dev_err(>dev, "Couldn't get our updn GPIO\n");
> >> + return PTR_ERR(ctx->gpios.updn);
> >> + }
> > This gpio is never used, it is only read from DT
> The gpio is initialized with low state. The state may be inverted by DT. The
> same for the "shlr".
> It is a vertical / horizontal inversion.
Ohh, then it makes sense again.
Consider adding a comment so this becomes more obvious
Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
linux-next: Signed-off-by missing for commit in the drm-intel tree
Hi all,
Commit
8e525cb4a622 ("drm/i915/execlists: Move RPCS setup to context pin")
is missing a Signed-off-by from its committer.
--
Cheers,
Stephen Rothwell
pgpCvtnpeFPUo.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
linux-next: Fixes tag needs some work in the drm-misc-fixes tree
Hi all,
In commit
053ff09f1a8f ("drm/rockchip: rgb: update SPDX license identifier")
Fixes tag
Fixes: 1f0f01515172 ("Add support for Rockchip Soc RGB output interface")
has these problem(s):
- Subject does not match target commit subject
--
Cheers,
Stephen Rothwell
pgpsISYlJuMI_.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109462] [bisected] Latest amd-staging-drm-next vega10 MCLK stuck on lowest level
https://bugs.freedesktop.org/show_bug.cgi?id=109462 Bug ID: 109462 Summary: [bisected] Latest amd-staging-drm-next vega10 MCLK stuck on lowest level Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: b...@basnieuwenhuizen.nl CC: alexdeuc...@gmail.com Performance is more than halved in games (used Talos Principle on RADV for bisection) due to the mclk being stuck at 167 MHz. commit 42a2d4839bc4f095621d259a3ff5401063b914cc (HEAD, refs/bisect/bad) Author: Evan Quan Date: Fri Jan 25 14:09:40 2019 +0800 drm/amd/powerplay: support Vega10 SOCclk and DCEFclk dpm level settings Enable SOCclk and DCEFclk dpm level retrieving and setting on Vega10. Change-Id: Iab35a6cc85cdfcf48f06f7d20b95a52c6feb60d1 Signed-off-by: Evan Quan Reviewed-by: Alex Deucher Kernel cmdline has amdgpu.exp_hw_support=1 log_buf_len=1 amdgpu.sched_hw_submission=64 amdgpu.gpu_recovery=1 amdgpu.cik_support=1 radeon.cik_support=0 amdgpu.cg_mask=0 amdgpu.pg_mask=0 idle=nomwait and nothing interesting showing up in dmesg. I can't CC Evan Quan due to lack of bugzilla account. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/panel: Add driver for Samsung S6E63M0 panel
Hi Pawel.
Thanks for this nice patch too.
Comment follows and you need to judge what to follow.
The timing part will not be commented as this was covered in
feedback on the binding.
Using a sysfs file to select the gamma mode looks like a local hack.
Someone with more drm knowledge needs comment on that.
On Fri, Jan 25, 2019 at 05:46:45PM +0100, Paweł Chmiel wrote:
> This patch adds Samsung S6E63M0 AMOLED LCD panel driver, connected over
> spi. It's based on already removed, non dt s6e63m0 driver and
> panel-samsung-ld9040. There is possibility to choose one from 3
> different gamma tables.
> It can be found for example in some of Samsung Aries based phones.
>
> Signed-off-by: Paweł Chmiel
> ---
> drivers/gpu/drm/panel/Kconfig | 7 +
> drivers/gpu/drm/panel/Makefile| 1 +
> drivers/gpu/drm/panel/panel-samsung-s6e63m0.c | 712 ++
> 3 files changed, 720 insertions(+)
> create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e63m0.c
>
> diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e63m0.c
> b/drivers/gpu/drm/panel/panel-samsung-s6e63m0.c
> new file mode 100644
> index ..cb5c090621ad
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-samsung-s6e63m0.c
> @@ -0,0 +1,712 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * S6E63M0 AMOLED LCD drm_panel driver.
> + *
> + * Copyright (C) 2019 Paweł Chmiel
> + * Derived from drivers/gpu/drm/panel-samsung-ld9040.c
> + *
> + * Andrzej Hajda
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include
> +#include
For new drivers please do not use drmP.h, we are working
on gettting rid of it.
The list is sorted in alphabetical order - good.
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +
> +/* Manufacturer Command Set */
> +#define MCS_STAND_BY_OFF0x11
> +#define MCS_DISPLAY_ON 0x29
> +#define MCS_ELVSS_ON0xb1
> +#define MCS_ACL_CTRL0xc0
> +#define MCS_DISPLAY_CONDITION 0xf2
> +#define MCS_ETC_CONDITION 0xf6
> +#define MCS_PANEL_CONDITION 0xF8
> +#define MCS_GAMMA_CTRL 0xfa
> +
> +#define MAX_GAMMA_LEVEL 11
> +#define GAMMA_TABLE_COUNT 23
> +
> +#define MAX_BRIGHTNESS (MAX_GAMMA_LEVEL - 1)
> +#define GAMMA_MODE_22 0
> +#define GAMMA_MODE_19 1
> +#define GAMMA_MODE_17 2
> +
> +/* array of gamma tables for gamma value 2.2 */
> +static u8 const s6e63m0_gamma_19[MAX_GAMMA_LEVEL][GAMMA_TABLE_COUNT] = {
> + { MCS_GAMMA_CTRL, 0x00,
> + 0x18, 0x08, 0x24, 0x84, 0x45, 0x4F, 0xCA,
> + 0xCB, 0xBC, 0xC9, 0xCB, 0xBC, 0xDA, 0xDA,
> + 0xD0, 0x00, 0x35, 0x00, 0x34, 0x00, 0x4E },
> + { MCS_GAMMA_CTRL, 0x00,
> + 0x18, 0x08, 0x24, 0x74, 0x60, 0x4A, 0xC3,
> + 0xC6, 0xB5, 0xBF, 0xC3, 0xB2, 0xD2, 0xD3,
> + 0xC8, 0x00, 0x5B, 0x00, 0x5B, 0x00, 0x81 },
> + { MCS_GAMMA_CTRL, 0x00,
> + 0x18, 0x08, 0x24, 0x6F, 0x65, 0x46, 0xC2,
> + 0xC4, 0xB3, 0xBF, 0xC2, 0xB2, 0xCF, 0xD1,
> + 0xC6, 0x00, 0x64, 0x00, 0x64, 0x00, 0x8D },
> + { MCS_GAMMA_CTRL, 0x00,
> + 0x18, 0x08, 0x24, 0x6E, 0x65, 0x45, 0xC0,
> + 0xC3, 0xB2, 0xBA, 0xBE, 0xAE, 0xCD, 0xD0,
> + 0xC4, 0x00, 0x70, 0x00, 0x70, 0x00, 0x9C },
> + { MCS_GAMMA_CTRL, 0x00,
> + 0x18, 0x08, 0x24, 0x69, 0x64, 0x40, 0xBF,
> + 0xC1, 0xB0, 0xB9, 0xBE, 0xAD, 0xCB, 0xCD,
> + 0xC2, 0x00, 0x7A, 0x00, 0x7B, 0x00, 0xAA },
> + { MCS_GAMMA_CTRL, 0x00,
> + 0x18, 0x08, 0x24, 0x68, 0x64, 0x3F, 0xBE,
> + 0xC0, 0xB0, 0xB6, 0xBB, 0xAB, 0xC8, 0xCB,
> + 0xBF, 0x00, 0x85, 0x00, 0x86, 0x00, 0xB8 },
> + { MCS_GAMMA_CTRL, 0x00,
> + 0x18, 0x08, 0x24, 0x68, 0x64, 0x40, 0xBC,
> + 0xBF, 0xAF, 0xB4, 0xBA, 0xA9, 0xC8, 0xCA,
> + 0xBE, 0x00, 0x8B, 0x00, 0x8C, 0x00, 0xC0 },
> + { MCS_GAMMA_CTRL, 0x00,
> + 0x18, 0x08, 0x24, 0x67, 0x64, 0x3F, 0xBB,
> + 0xBE, 0xAD, 0xB3, 0xB9, 0xA7, 0xC8, 0xC9,
> + 0xBE, 0x00, 0x90, 0x00, 0x92, 0x00, 0xC8 },
> + { MCS_GAMMA_CTRL, 0x00,
> + 0x18, 0x08, 0x24, 0x63, 0x61, 0x3B, 0xBA,
> + 0xBE, 0xAC, 0xB3, 0xB8, 0xA7, 0xC6, 0xC8,
> + 0xBD, 0x00, 0x96, 0x00, 0x98, 0x00, 0xCF },
> + { MCS_GAMMA_CTRL, 0x00,
> + 0x18, 0x08, 0x24, 0x61, 0x60, 0x39, 0xBB,
> + 0xBE, 0xAD, 0xB2, 0xB6, 0xA6, 0xC5, 0xC7,
> + 0xBD, 0x00, 0x9B, 0x00, 0x9E, 0x00, 0xD5 },
> + { MCS_GAMMA_CTRL, 0x00,
> + 0x18, 0x08, 0x24, 0x61, 0x5F, 0x39, 0xBA,
> + 0xBD, 0xAD, 0xB1, 0xB6, 0xA5, 0xC4, 0xC5,
> + 0xBC, 0x00, 0xA0, 0x00, 0xA4, 0x00, 0xDB },
> +};
> +
> +/* array of gamma tables for gamma value 1.7 */
> +static u8 const s6e63m0_gamma_17[MAX_GAMMA_LEVEL][GAMMA_TABLE_COUNT] = {
> + {
Re: [PATCH 1/2] drm: panel: Add Samsung s6e63m0 panel documentation
Hi Pawel.
Thanks for the patch, some comments follows.
Please judge what comments you chose to follow, see this as suggestions.
According to Documentation/devicetree/bindings/submitting-patches.rst:
The preferred subject prefix for binding patches is:
"dt-bindings: : ..."
It would be a good idea to follow this practice in next revision.
On Fri, Jan 25, 2019 at 05:46:44PM +0100, Paweł Chmiel wrote:
> From: Jonathan Bakker
>
> This commit adds documentation for Samsung s6e63m0 AMOLED LCD panel
> driver.
>
> Signed-off-by: Jonathan Bakker
> Signed-off-by: Paweł Chmiel
> ---
> .../display/panel/samsung,s6e63m0.txt | 60 +++
> 1 file changed, 60 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/panel/samsung,s6e63m0.txt
>
> diff --git
> a/Documentation/devicetree/bindings/display/panel/samsung,s6e63m0.txt
> b/Documentation/devicetree/bindings/display/panel/samsung,s6e63m0.txt
> new file mode 100644
> index ..4979200e2dd2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e63m0.txt
> @@ -0,0 +1,60 @@
> +Samsung s6e63m0 AMOLED LCD panel
> +
> +Required properties:
> + - compatible: "samsung,s6e63m0"
> + - reset-gpio: GPIO spec for reset pin
The preferred name is reset-gpios (added 's')
> + - vdd3-supply: VDD regulator
> + - vci-supply: VCI regulator
> + - display-timings: timings for the connected panel as described by [1]
Today, as is my best understanding, it is encouraged to specify the timing
in the actual driver and not in DT,
The example include a spi-max-frequency which is not mentioned?
> +
> +Optional properties:
> + - reset-delay: Delay in ms after adjusting reset-gpio, default 120ms
> + - power-on-delay: Delay in ms after powering on, default 25ms
> + - power-off-delay: Delay in ms before powering off, default 200ms
> + - panel-width-mm: physical panel width in mm
> + - panel-height-mm: physical panel height in mm
Likewise these delays are also properties that today are included in the driver.
I cannot explain the background for this, this is just how things are done.
> +
> +The device node can contain one 'port' child node with one child
> +'endpoint' node, according to the bindings defined in [2]. This
> +node should describe panel's video bus.
> +
> +[1]: Documentation/devicetree/bindings/display/panel/display-timing.txt
> +[2]: Documentation/devicetree/bindings/media/video-interfaces.txt
> +
> +Example:
> +
> + s6e63m0: display@0 {
> + compatible = "samsung,s6e63m0";
> + reg = <0>;
> + reset-gpio = < 5 1>;
> + vdd3-supply = <_reg>;
> + vci-supply = <_reg>;
> + spi-max-frequency = <100>;
> +
> + power-on-delay = <0>;
> + power-off-delay = <0>;
> + reset-delay = <10>;
> + panel-width-mm = <53>;
> + panel-height-mm = <89>;
> +
> + display-timings {
> + timing-0 {
> + /* 480x800@60Hz */
> + clock-frequency = <25628040>;
> + hactive = <480>;
> + vactive = <800>;
> + hfront-porch = <16>;
> + hback-porch = <16>;
> + hsync-len = <2>;
> + vfront-porch = <28>;
> + vback-porch = <1>;
> + vsync-len = <2>;
> + };
> + };
> +
> + port {
> + lcd_ep: endpoint {
> + remote-endpoint = <_ep>;
> + };
> + };
> + };
Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/i915: Disable -Wuninitialized
This warning is disabled by default in scripts/Makefile.extrawarn when
W= is not provided but this Makefile adds -Wall after this warning is
disabled so it shows up in the build when it shouldn't:
In file included from drivers/gpu/drm/i915/intel_breadcrumbs.c:895:
drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c:350:34: error:
variable 'wq' is uninitialized when used within its own initialization
[-Werror,-Wuninitialized]
DECLARE_WAIT_QUEUE_HEAD_ONSTACK(wq);
^~
./include/linux/wait.h:74:63: note: expanded from macro
'DECLARE_WAIT_QUEUE_HEAD_ONSTACK'
struct wait_queue_head name = __WAIT_QUEUE_HEAD_INIT_ONSTACK(name)
^~~~
./include/linux/wait.h:72:33: note: expanded from macro
'__WAIT_QUEUE_HEAD_INIT_ONSTACK'
({ init_waitqueue_head(); name; })
^~~~
1 error generated.
Explicitly disable the warning like commit 46e2068081e9 ("drm/i915:
Disable some extra clang warnings").
Link: https://github.com/ClangBuiltLinux/linux/issues/220
Signed-off-by: Nathan Chancellor
---
v1 -> v2:
* Rather than disable the warning for the problematic folder, disable it
for the entire folder like Matthias's commit.
drivers/gpu/drm/i915/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 8300efe60fe1..210d0e8777b6 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -22,6 +22,7 @@ subdir-ccflags-y += $(call cc-disable-warning,
unused-but-set-variable)
subdir-ccflags-y += $(call cc-disable-warning, sign-compare)
subdir-ccflags-y += $(call cc-disable-warning, sometimes-uninitialized)
subdir-ccflags-y += $(call cc-disable-warning, initializer-overrides)
+subdir-ccflags-y += $(call cc-disable-warning, uninitialized)
subdir-ccflags-$(CONFIG_DRM_I915_WERROR) += -Werror
# Fine grained warnings disable
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm: panel: Add Samsung s6e63m0 panel documentation
From: Jonathan Bakker
This commit adds documentation for Samsung s6e63m0 AMOLED LCD panel
driver.
Signed-off-by: Jonathan Bakker
Signed-off-by: Paweł Chmiel
---
.../display/panel/samsung,s6e63m0.txt | 60 +++
1 file changed, 60 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/samsung,s6e63m0.txt
diff --git
a/Documentation/devicetree/bindings/display/panel/samsung,s6e63m0.txt
b/Documentation/devicetree/bindings/display/panel/samsung,s6e63m0.txt
new file mode 100644
index ..4979200e2dd2
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e63m0.txt
@@ -0,0 +1,60 @@
+Samsung s6e63m0 AMOLED LCD panel
+
+Required properties:
+ - compatible: "samsung,s6e63m0"
+ - reset-gpio: GPIO spec for reset pin
+ - vdd3-supply: VDD regulator
+ - vci-supply: VCI regulator
+ - display-timings: timings for the connected panel as described by [1]
+
+Optional properties:
+ - reset-delay: Delay in ms after adjusting reset-gpio, default 120ms
+ - power-on-delay: Delay in ms after powering on, default 25ms
+ - power-off-delay: Delay in ms before powering off, default 200ms
+ - panel-width-mm: physical panel width in mm
+ - panel-height-mm: physical panel height in mm
+
+The device node can contain one 'port' child node with one child
+'endpoint' node, according to the bindings defined in [2]. This
+node should describe panel's video bus.
+
+[1]: Documentation/devicetree/bindings/display/panel/display-timing.txt
+[2]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+
+ s6e63m0: display@0 {
+ compatible = "samsung,s6e63m0";
+ reg = <0>;
+ reset-gpio = < 5 1>;
+ vdd3-supply = <_reg>;
+ vci-supply = <_reg>;
+ spi-max-frequency = <100>;
+
+ power-on-delay = <0>;
+ power-off-delay = <0>;
+ reset-delay = <10>;
+ panel-width-mm = <53>;
+ panel-height-mm = <89>;
+
+ display-timings {
+ timing-0 {
+ /* 480x800@60Hz */
+ clock-frequency = <25628040>;
+ hactive = <480>;
+ vactive = <800>;
+ hfront-porch = <16>;
+ hback-porch = <16>;
+ hsync-len = <2>;
+ vfront-porch = <28>;
+ vback-porch = <1>;
+ vsync-len = <2>;
+ };
+ };
+
+ port {
+ lcd_ep: endpoint {
+ remote-endpoint = <_ep>;
+ };
+ };
+ };
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/5] drm/i2c: tda998x: improve correctness of quantisation range
CEA-861 says: "A Source shall not send a non-zero Q value that does
not correspond to the default RGB Quantization Range for the
transmitted Picture unless the Sink indicates support for the Q bit
in a Video Capabilities Data Block."
Make TDA998x compliant by using the helper to set the quantisation
range in the infoframe, and using the TDA998x's colour scaling to
appropriately adjust the RGB values sent to the monitor.
This ensures that monitors that do not support the Q bit are sent
RGB values that are within the expected range. Monitors with
support for the Q bit will be sent full-range RGB.
Signed-off-by: Russell King
---
drivers/gpu/drm/i2c/tda998x_drv.c | 39 ++-
1 file changed, 34 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
index b0ed2ef49c62..7d9aea79aff2 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -50,6 +50,8 @@ struct tda998x_priv {
bool is_on;
bool supports_infoframes;
bool sink_has_audio;
+ bool has_rgb_quant;
+ enum hdmi_quantization_range rgb_quant_range;
u8 vip_cntrl_0;
u8 vip_cntrl_1;
u8 vip_cntrl_2;
@@ -869,7 +871,9 @@ tda998x_write_avi(struct tda998x_priv *priv, const struct
drm_display_mode *mode
drm_hdmi_avi_infoframe_from_display_mode(,
>connector, mode);
- frame.avi.quantization_range = HDMI_QUANTIZATION_RANGE_FULL;
+ drm_hdmi_avi_infoframe_quant_range(, mode,
+ priv->rgb_quant_range,
+ priv->has_rgb_quant, false);
tda998x_write_if(priv, DIP_IF_FLAGS_IF2, REG_IF2_HB0, );
}
@@ -1259,6 +1263,7 @@ static int tda998x_connector_get_modes(struct
drm_connector *connector)
mutex_lock(>audio_mutex);
n = drm_add_edid_modes(connector, edid);
priv->sink_has_audio = drm_detect_monitor_audio(edid);
+ priv->has_rgb_quant = drm_rgb_quant_range_selectable(edid);
mutex_unlock(>audio_mutex);
kfree(edid);
@@ -1385,6 +1390,15 @@ static void tda998x_bridge_mode_set(struct drm_bridge
*bridge,
u8 reg, div, rep, sel_clk;
/*
+* Since we are "computer" like, our source invariably produces
+* full-range RGB. If the monitor supports full-range, then use
+* it, otherwise reduce to limited-range.
+*/
+ priv->rgb_quant_range = priv->has_rgb_quant ?
+ HDMI_QUANTIZATION_RANGE_FULL :
+ drm_default_rgb_quant_range(adjusted_mode);
+
+ /*
* Internally TDA998x is using ITU-R BT.656 style sync but
* we get VESA style sync. TDA998x is using a reference pixel
* relative to ITU to sync to the input frame and for output
@@ -1499,10 +1513,25 @@ static void tda998x_bridge_mode_set(struct drm_bridge
*bridge,
reg_write(priv, REG_PLL_SERIAL_2, PLL_SERIAL_2_SRL_NOSC(div) |
PLL_SERIAL_2_SRL_PR(rep));
- /* set color matrix bypass flag: */
- reg_write(priv, REG_MAT_CONTRL, MAT_CONTRL_MAT_BP |
- MAT_CONTRL_MAT_SC(1));
- reg_set(priv, REG_FEAT_POWERDOWN, FEAT_POWERDOWN_CSC);
+ /* set color matrix according to output rgb quant range */
+ if (priv->rgb_quant_range == HDMI_QUANTIZATION_RANGE_LIMITED) {
+ static u8 tda998x_full_to_limited_range[] = {
+ MAT_CONTRL_MAT_SC(2),
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x03, 0x6f, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x03, 0x6f, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x03, 0x6f,
+ 0x00, 0x40, 0x00, 0x40, 0x00, 0x40
+ };
+ reg_clear(priv, REG_FEAT_POWERDOWN, FEAT_POWERDOWN_CSC);
+ reg_write_range(priv, REG_MAT_CONTRL,
+ tda998x_full_to_limited_range,
+ sizeof(tda998x_full_to_limited_range));
+ } else {
+ reg_write(priv, REG_MAT_CONTRL, MAT_CONTRL_MAT_BP |
+ MAT_CONTRL_MAT_SC(1));
+ reg_set(priv, REG_FEAT_POWERDOWN, FEAT_POWERDOWN_CSC);
+ }
/* set BIAS tmds value: */
reg_write(priv, REG_ANA_GENERAL, 0x09);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/5] drm/i2c: tda998x: add support for pixel repeated modes
TDA998x has no support for pixel repeated modes, and the code notes this
as a "TODO" item. The implementation appears to be relatively simple,
so lets add it.
We need to calculate the serializer clock divisor based on the TMDS
clock rate, set the repeat control, and set the serializer pixel
repeat count. Since the audio code needs the actual TMDS clock,
record that.
Signed-off-by: Russell King
---
drivers/gpu/drm/i2c/tda998x_drv.c | 26 --
1 file changed, 16 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
index ecdb8070ed35..a7bc3b7a9bcc 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -241,6 +241,7 @@ struct tda998x_priv {
# define HVF_CNTRL_1_PAD(x) (((x) & 3) << 4)
# define HVF_CNTRL_1_SEMI_PLANAR (1 << 6)
#define REG_RPT_CNTRL REG(0x00, 0xf0) /* write */
+# define RPT_CNTRL_REPEAT(x) ((x) & 15)
#define REG_I2S_FORMATREG(0x00, 0xfc) /* read/write */
# define I2S_FORMAT(x)(((x) & 3) << 0)
#define REG_AIP_CLKSELREG(0x00, 0xfd) /* write */
@@ -1351,7 +1352,7 @@ static void tda998x_bridge_mode_set(struct drm_bridge
*bridge,
u16 vwin1_line_s, vwin1_line_e;
u16 vwin2_line_s, vwin2_line_e;
u16 de_pix_s, de_pix_e;
- u8 reg, div, rep;
+ u8 reg, div, rep, sel_clk;
/*
* Internally TDA998x is using ITU-R BT.656 style sync but
@@ -1414,7 +1415,16 @@ static void tda998x_bridge_mode_set(struct drm_bridge
*bridge,
(mode->vsync_end - mode->vsync_start)/2;
}
- tmds_clock = mode->clock;
+ /*
+* Select pixel repeat depending on the double-clock flag
+* (which means we have to repeat each pixel once.)
+*/
+ rep = mode->flags & DRM_MODE_FLAG_DBLCLK ? 1 : 0;
+ sel_clk = SEL_CLK_ENA_SC_CLK | SEL_CLK_SEL_CLK1 |
+ SEL_CLK_SEL_VRF_CLK(rep ? 2 : 0);
+
+ /* the TMDS clock is scaled up by the pixel repeat */
+ tmds_clock = mode->clock * (1 + rep);
/*
* The divisor is power-of-2. The TDA9983B datasheet gives
@@ -1430,6 +1440,8 @@ static void tda998x_bridge_mode_set(struct drm_bridge
*bridge,
mutex_lock(>audio_mutex);
+ priv->tmds_clock = tmds_clock;
+
/* mute the audio FIFO: */
reg_set(priv, REG_AIP_CNTRL_0, AIP_CNTRL_0_RST_FIFO);
@@ -1452,12 +1464,8 @@ static void tda998x_bridge_mode_set(struct drm_bridge
*bridge,
reg_write(priv, REG_SERIALIZER, 0);
reg_write(priv, REG_HVF_CNTRL_1, HVF_CNTRL_1_VQR(0));
- /* TODO enable pixel repeat for pixel rates less than 25Msamp/s */
- rep = 0;
- reg_write(priv, REG_RPT_CNTRL, 0);
- reg_write(priv, REG_SEL_CLK, SEL_CLK_SEL_VRF_CLK(0) |
- SEL_CLK_SEL_CLK1 | SEL_CLK_ENA_SC_CLK);
-
+ reg_write(priv, REG_RPT_CNTRL, RPT_CNTRL_REPEAT(rep));
+ reg_write(priv, REG_SEL_CLK, sel_clk);
reg_write(priv, REG_PLL_SERIAL_2, PLL_SERIAL_2_SRL_NOSC(div) |
PLL_SERIAL_2_SRL_PR(rep));
@@ -1525,8 +1533,6 @@ static void tda998x_bridge_mode_set(struct drm_bridge
*bridge,
/* must be last register set: */
reg_write(priv, REG_TBG_CNTRL_0, 0);
- priv->tmds_clock = adjusted_mode->clock;
-
/* CEA-861B section 6 says that:
* CEA version 1 (CEA-861) has no support for infoframes.
* CEA version 2 (CEA-861A) supports version 1 AVI infoframes,
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/display: Pass app_tf by value rather than by reference
On Fri, Dec 14, 2018 at 08:09:00PM +, Wentland, Harry wrote:
> On 2018-12-11 5:07 p.m., Nick Desaulniers wrote:
> > On Tue, Dec 11, 2018 at 1:42 PM Nathan Chancellor
> > wrote:
> >>
> >> On Tue, Dec 11, 2018 at 01:25:00PM -0800, Nick Desaulniers wrote:
> >>> On Mon, Dec 10, 2018 at 3:42 PM Nathan Chancellor
> >>> wrote:
>
> Clang warns when an expression that equals zero is used as a null
> pointer constant (in lieu of NULL):
>
> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:4435:3:
> warning: expression which evaluates to zero treated as a null pointer
> constant of type 'const enum color_transfer_func *'
> [-Wnon-literal-null-conversion]
> TRANSFER_FUNC_UNKNOWN,
> ^
> 1 warning generated.
>
> This warning is caused by commit bb47de736661 ("drm/amdgpu: Set FreeSync
> state using drm VRR properties") and it could be solved by using NULL
> instead of TRANSFER_FUNC_UNKNOWN or casting TRANSFER_FUNC_UNKNOWN as a
> pointer. However, after looking into it, there doesn't appear to be a
> good reason to pass app_tf by reference as it is never mutated along the
> way. This is the only code path in which app_tf is used:
>
> mod_freesync_build_vrr_infopacket ->
> build_vrr_infopacket_v2 ->
> build_vrr_infopacket_fs2_data
>
> Neither mod_freesync_build_vrr_infopacket or build_vrr_infopacket_v2
> modify app_tf's value and build_vrr_infopacket_fs2_data expects just
> the value so we can avoid dereferencing anything by just passing in
> app_tf's value to mod_freesync_build_vrr_infopacket and
> build_vrr_infopacket_v2.
>
> There is no functional change because build_vrr_infopacket_fs2_data
> doesn't do anything if TRANSFER_FUNC_UNKNOWN is passed to it, the same
> as not calling build_vrr_infopacket_fs2_data at all like before this
> change when NULL was used for app_tf.
> >>>
> >>> Nathan,
> >>> Thanks for sending this patch. I was hoping to provide review sooner,
> >>> but have been quite busy lately.
> >>>
> >>
> >> Late review is better than no review, I appeciate you taking the time to
> >> do this!
> >>
> >>> Yeah, especially for LP64 targets, the pointer to enum is larger than
> >>> just the enum, and if it's not being updated ("in/out paramter")
> >>> there's no need to pass by pointer.
> >>>
> >>
> >> Thanks for confirming!
> >>
>
> Signed-off-by: Nathan Chancellor
> ---
> drivers/gpu/drm/amd/display/modules/freesync/freesync.c | 7 +++
> drivers/gpu/drm/amd/display/modules/inc/mod_freesync.h | 2 +-
> 2 files changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
> b/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
> index 620a171620ee..520665a9d81a 100644
> --- a/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
> +++ b/drivers/gpu/drm/amd/display/modules/freesync/freesync.c
> @@ -656,7 +656,7 @@ static void build_vrr_infopacket_v1(enum signal_type
> signal,
>
> static void build_vrr_infopacket_v2(enum signal_type signal,
> const struct mod_vrr_params *vrr,
> - const enum color_transfer_func *app_tf,
> + enum color_transfer_func app_tf,
> struct dc_info_packet *infopacket)
> {
> unsigned int payload_size = 0;
> @@ -664,8 +664,7 @@ static void build_vrr_infopacket_v2(enum signal_type
> signal,
> build_vrr_infopacket_header_v2(signal, infopacket,
> _size);
> build_vrr_infopacket_data(vrr, infopacket);
>
> - if (app_tf != NULL)
> - build_vrr_infopacket_fs2_data(*app_tf, infopacket);
> + build_vrr_infopacket_fs2_data(app_tf, infopacket);
>
> build_vrr_infopacket_checksum(_size, infopacket);
>
> @@ -676,7 +675,7 @@ void mod_freesync_build_vrr_infopacket(struct
> mod_freesync *mod_freesync,
> const struct dc_stream_state *stream,
> const struct mod_vrr_params *vrr,
> enum vrr_packet_type packet_type,
> - const enum color_transfer_func *app_tf,
> + enum color_transfer_func app_tf,
> struct dc_info_packet *infopacket)
> {
> /* SPD info packet for FreeSync */
> diff --git a/drivers/gpu/drm/amd/display/modules/inc/mod_freesync.h
> b/drivers/gpu/drm/amd/display/modules/inc/mod_freesync.h
> index 949a8b62aa98..063af6258fd9 100644
> --- a/drivers/gpu/drm/amd/display/modules/inc/mod_freesync.h
> +++ b/drivers/gpu/drm/amd/display/modules/inc/mod_freesync.h
> @@ -145,7 +145,7 @@ void mod_freesync_build_vrr_infopacket(struct
>
[PATCH 2/5] drm/i2c: tda998x: add bridge timing information
Add bridge timing information so that bridge users can figure out the
timing parameters that are necessary for TDA998x.
Signed-off-by: Russell King
---
drivers/gpu/drm/i2c/tda998x_drv.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
index a7bc3b7a9bcc..c399a7b73e2b 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -1572,6 +1572,18 @@ static const struct drm_bridge_funcs
tda998x_bridge_funcs = {
.enable = tda998x_bridge_enable,
};
+static const struct drm_bridge_timings tda9989_timings = {
+ .sampling_edge = DRM_BUS_FLAG_PIXDATA_POSEDGE,
+ .setup_time_ps = 1500,
+ .hold_time_ps = 1000,
+};
+
+static const struct drm_bridge_timings tda19988_timings = {
+ .sampling_edge = DRM_BUS_FLAG_PIXDATA_POSEDGE,
+ .setup_time_ps = 1600,
+ .hold_time_ps = 1200,
+};
+
/* I2C driver functions */
static int tda998x_get_audio_ports(struct tda998x_priv *priv,
@@ -1842,6 +1854,17 @@ static int tda998x_create(struct device *dev)
priv->bridge.of_node = dev->of_node;
#endif
+ switch (priv->rev) {
+ case TDA9989N2:
+ case TDA19989:
+ case TDA19989N2:
+ priv->bridge.timings = _timings;
+ break;
+ case TDA19988:
+ priv->bridge.timings = _timings;
+ break;
+ }
+
drm_bridge_add(>bridge);
return 0;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/armada: add mmp2 support
On Tue, 2019-01-22 at 19:10 +, Russell King - ARM Linux admin
wrote:
> On Mon, Jan 21, 2019 at 07:03:49AM +0100, Lubomir Rintel wrote:
> > Heavily based on the Armada 510 (Dove) support. Like with 510 support, this
> > also just supports a single source clock -- the "Display 1" clock as
> > generated by the APMU. This one was chosen because the OLPC XO 1.75 laptop
> > uses it for its internal panel.
> >
> > If anyone uses this to drive a MIPI or HDMI encoder, they may want to
> > extend this to choose a different source for the pixel clock -- it should
> > be a reasonably straightforward thing to do.
> >
> > The data sheet is not available, but James Cameron of OLPC kindly
> > provided some details about the LCD_SCLK_DIV register.
> >
> > Link:
> > https://lists.freedesktop.org/archives/dri-devel/2018-December/201021.html
> > Signed-off-by: Lubomir Rintel
> > ---
> > drivers/gpu/drm/armada/Makefile | 1 +
> > drivers/gpu/drm/armada/armada_610.c | 93
> > drivers/gpu/drm/armada/armada_crtc.c | 4 ++
> > drivers/gpu/drm/armada/armada_drm.h | 1 +
> > drivers/gpu/drm/armada/armada_hw.h | 10 +++
> > 5 files changed, 109 insertions(+)
> > create mode 100644 drivers/gpu/drm/armada/armada_610.c
> >
> > diff --git a/drivers/gpu/drm/armada/Makefile
> > b/drivers/gpu/drm/armada/Makefile
> > index 9bc3c3213724..5bbf86324cda 100644
> > --- a/drivers/gpu/drm/armada/Makefile
> > +++ b/drivers/gpu/drm/armada/Makefile
> > @@ -2,6 +2,7 @@
> > armada-y := armada_crtc.o armada_drv.o armada_fb.o armada_fbdev.o \
> >armada_gem.o armada_overlay.o armada_plane.o armada_trace.o
> > armada-y += armada_510.o
> > +armada-y += armada_610.o
> > armada-$(CONFIG_DEBUG_FS) += armada_debugfs.o
> >
> > obj-$(CONFIG_DRM_ARMADA) := armada.o
> > diff --git a/drivers/gpu/drm/armada/armada_610.c
> > b/drivers/gpu/drm/armada/armada_610.c
> > new file mode 100644
> > index ..278b204038ea
> > --- /dev/null
> > +++ b/drivers/gpu/drm/armada/armada_610.c
> > @@ -0,0 +1,93 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2012 Russell King
> > + * Copyright (C) 2018,2019 Lubomir Rintel
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + *
> > + * Armada MMP2 variant support
> > + */
> > +#include
> > +#include
> > +#include
> > +#include "armada_crtc.h"
> > +#include "armada_drm.h"
> > +#include "armada_hw.h"
> > +
> > +static int armada610_crtc_init(struct armada_crtc *dcrtc, struct device
> > *dev)
> > +{
> > + struct clk *clk;
> > +
> > + clk = devm_clk_get(dev, "disp0");
> > + if (IS_ERR(clk))
> > + return PTR_ERR(clk) == -ENOENT ? -EPROBE_DEFER : PTR_ERR(clk);
> > +
> > + dcrtc->extclk[0] = clk;
>
> I've been reworking the clocking support for Armada, you can find the
> current code in my git tree's drm-armada-devel branch (as mentioned
> in MAINTAINERS). You'll need to update to that before I can apply
> this.
>
> The clocks are named in Dove's TRM as:
>
>0 = AXIbus: Select AXI bus clock as pixel clock source.
>1 = EXT_REF_CLK0: LCD_EXT_REF_CLK[0]
>2 = PLLDivider: Select PLL divider input clock as pixel clock source.
>3 = EXT_REF_CLK1: LCD_EXT_REF_CLK[1]
What we know (from [1]) about MMP2 clock sources is:
0 AXI
1 LCD Display 1
2 LCD Display 2
3 HDMI PLL
[1]
https://lists.freedesktop.org/archives/dri-devel/2018-December/201021.html
> So I chose to use these neumonics in the Armada 510. Please can we
> keep to naming the clock inputs as per documented names please?
Are you suggesting that clocks that are available on MMP2 are
essentially the same as on 510? Like this?
0 AXI -- axiclk
1 LCD Display 1 -- ext_ref_clk0
2 LCD Display 2 --
ext_ref_clk1
3 HDMI PLL -- plldivider
If that is the case, then I'm happy to take your word on it. I had to
guess.
Why I guessed differently was because the clock numbers in
the LCD_SCLK_DIV register don't seem to match and I thought the
"external" clock sources on 510 are external to the SoC (while they two
"LCD Display" clocks on MMP2 are generated by the PMU).
> Also, have a look at how Armada 510 gets its clocks from DT - note
> that the array they're placed in is ordered by priority (iow, if we
> have an external clock, we use that in preference to the more
> restricted axibus and plldivider clocks.)
Okay. I'll follow up with an updated patch over the course of the next
week.
>
> Thanks.
Thank you
Lubo
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/panel: Add driver for Samsung S6E63M0 panel
This patch adds Samsung S6E63M0 AMOLED LCD panel driver, connected over
spi. It's based on already removed, non dt s6e63m0 driver and
panel-samsung-ld9040. There is possibility to choose one from 3
different gamma tables.
It can be found for example in some of Samsung Aries based phones.
Signed-off-by: Paweł Chmiel
---
drivers/gpu/drm/panel/Kconfig | 7 +
drivers/gpu/drm/panel/Makefile| 1 +
drivers/gpu/drm/panel/panel-samsung-s6e63m0.c | 712 ++
3 files changed, 720 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e63m0.c
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 3f3537719beb..4a4b64f74e70 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -82,6 +82,13 @@ config DRM_PANEL_SAMSUNG_LD9040
depends on OF && SPI
select VIDEOMODE_HELPERS
+config DRM_PANEL_SAMSUNG_S6E63M0
+ tristate "Samsung S6E63M0 RGB/SPI panel"
+ depends on OF
+ depends on SPI
+ depends on BACKLIGHT_CLASS_DEVICE
+ select VIDEOMODE_HELPERS
+
config DRM_PANEL_LG_LG4573
tristate "LG4573 RGB/SPI panel"
depends on OF && SPI
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 4396658a7996..3e5d53fdee47 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_DRM_PANEL_RASPBERRYPI_TOUCHSCREEN) +=
panel-raspberrypi-touchscreen
obj-$(CONFIG_DRM_PANEL_RAYDIUM_RM68200) += panel-raydium-rm68200.o
obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += panel-samsung-ld9040.o
obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6D16D0) += panel-samsung-s6d16d0.o
+obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E63M0) += panel-samsung-s6e63m0.o
obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E3HA2) += panel-samsung-s6e3ha2.o
obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E63J0X03) += panel-samsung-s6e63j0x03.o
obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0) += panel-samsung-s6e8aa0.o
diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e63m0.c
b/drivers/gpu/drm/panel/panel-samsung-s6e63m0.c
new file mode 100644
index ..cb5c090621ad
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-samsung-s6e63m0.c
@@ -0,0 +1,712 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * S6E63M0 AMOLED LCD drm_panel driver.
+ *
+ * Copyright (C) 2019 Paweł Chmiel
+ * Derived from drivers/gpu/drm/panel-samsung-ld9040.c
+ *
+ * Andrzej Hajda
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+/* Manufacturer Command Set */
+#define MCS_STAND_BY_OFF0x11
+#define MCS_DISPLAY_ON 0x29
+#define MCS_ELVSS_ON0xb1
+#define MCS_ACL_CTRL0xc0
+#define MCS_DISPLAY_CONDITION 0xf2
+#define MCS_ETC_CONDITION 0xf6
+#define MCS_PANEL_CONDITION 0xF8
+#define MCS_GAMMA_CTRL 0xfa
+
+#define MAX_GAMMA_LEVEL 11
+#define GAMMA_TABLE_COUNT 23
+
+#define MAX_BRIGHTNESS (MAX_GAMMA_LEVEL - 1)
+#define GAMMA_MODE_22 0
+#define GAMMA_MODE_19 1
+#define GAMMA_MODE_17 2
+
+/* array of gamma tables for gamma value 2.2 */
+static u8 const s6e63m0_gamma_22[MAX_GAMMA_LEVEL][GAMMA_TABLE_COUNT] = {
+ { MCS_GAMMA_CTRL, 0x00,
+ 0x18, 0x08, 0x24, 0x78, 0xEC, 0x3D, 0xC8,
+ 0xC2, 0xB6, 0xC4, 0xC7, 0xB6, 0xD5, 0xD7,
+ 0xCC, 0x00, 0x39, 0x00, 0x36, 0x00, 0x51 },
+ { MCS_GAMMA_CTRL, 0x00,
+ 0x18, 0x08, 0x24, 0x73, 0x4A, 0x3D, 0xC0,
+ 0xC2, 0xB1, 0xBB, 0xBE, 0xAC, 0xCE, 0xCF,
+ 0xC5, 0x00, 0x5D, 0x00, 0x5E, 0x00, 0x82 },
+ { MCS_GAMMA_CTRL, 0x00,
+ 0x18, 0x08, 0x24, 0x70, 0x51, 0x3E, 0xBF,
+ 0xC1, 0xAF, 0xB9, 0xBC, 0xAB, 0xCC, 0xCC,
+ 0xC2, 0x00, 0x65, 0x00, 0x67, 0x00, 0x8D },
+ { MCS_GAMMA_CTRL, 0x00,
+ 0x18, 0x08, 0x24, 0x6C, 0x54, 0x3A, 0xBC,
+ 0xBF, 0xAC, 0xB7, 0xBB, 0xA9, 0xC9, 0xC9,
+ 0xBE, 0x00, 0x71, 0x00, 0x73, 0x00, 0x9E },
+ { MCS_GAMMA_CTRL, 0x00,
+ 0x18, 0x08, 0x24, 0x69, 0x54, 0x37, 0xBB,
+ 0xBE, 0xAC, 0xB4, 0xB7, 0xA6, 0xC7, 0xC8,
+ 0xBC, 0x00, 0x7B, 0x00, 0x7E, 0x00, 0xAB },
+ { MCS_GAMMA_CTRL, 0x00,
+ 0x18, 0x08, 0x24, 0x66, 0x55, 0x34, 0xBA,
+ 0xBD, 0xAB, 0xB1, 0xB5, 0xA3, 0xC5, 0xC6,
+ 0xB9, 0x00, 0x85, 0x00, 0x88, 0x00, 0xBA },
+ { MCS_GAMMA_CTRL, 0x00,
+ 0x18, 0x08, 0x24, 0x63, 0x53, 0x31, 0xB8,
+ 0xBC, 0xA9, 0xB0, 0xB5, 0xA2, 0xC4, 0xC4,
+ 0xB8, 0x00, 0x8B, 0x00, 0x8E, 0x00, 0xC2 },
+ { MCS_GAMMA_CTRL, 0x00,
+ 0x18, 0x08, 0x24, 0x62, 0x54, 0x30, 0xB9,
+ 0xBB, 0xA9, 0xB0, 0xB3, 0xA1, 0xC1, 0xC3,
+ 0xB7, 0x00, 0x91, 0x00,
Re: [PATCH v2] drm/i915: Disable -Wuninitialized
On Sat, Jan 26, 2019 at 12:11:23AM -0700, Nathan Chancellor wrote:
> This warning is disabled by default in scripts/Makefile.extrawarn when
> W= is not provided but this Makefile adds -Wall after this warning is
> disabled so it shows up in the build when it shouldn't:
>
> In file included from drivers/gpu/drm/i915/intel_breadcrumbs.c:895:
> drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c:350:34: error:
> variable 'wq' is uninitialized when used within its own initialization
> [-Werror,-Wuninitialized]
> DECLARE_WAIT_QUEUE_HEAD_ONSTACK(wq);
> ^~
> ./include/linux/wait.h:74:63: note: expanded from macro
> 'DECLARE_WAIT_QUEUE_HEAD_ONSTACK'
> struct wait_queue_head name = __WAIT_QUEUE_HEAD_INIT_ONSTACK(name)
> ^~~~
> ./include/linux/wait.h:72:33: note: expanded from macro
> '__WAIT_QUEUE_HEAD_INIT_ONSTACK'
> ({ init_waitqueue_head(); name; })
>^~~~
> 1 error generated.
>
> Explicitly disable the warning like commit 46e2068081e9 ("drm/i915:
> Disable some extra clang warnings").
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/220
> Signed-off-by: Nathan Chancellor
> ---
>
> v1 -> v2:
>
> * Rather than disable the warning for the problematic folder, disable it
> for the entire folder like Matthias's commit.
>
Link to v1:
https://lore.kernel.org/lkml/20181025193601.11746-1-natechancel...@gmail.com/
Since I forgot '--in-reply-to' :(
> drivers/gpu/drm/i915/Makefile | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 8300efe60fe1..210d0e8777b6 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -22,6 +22,7 @@ subdir-ccflags-y += $(call cc-disable-warning,
> unused-but-set-variable)
> subdir-ccflags-y += $(call cc-disable-warning, sign-compare)
> subdir-ccflags-y += $(call cc-disable-warning, sometimes-uninitialized)
> subdir-ccflags-y += $(call cc-disable-warning, initializer-overrides)
> +subdir-ccflags-y += $(call cc-disable-warning, uninitialized)
> subdir-ccflags-$(CONFIG_DRM_I915_WERROR) += -Werror
>
> # Fine grained warnings disable
> --
> 2.20.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH -next] drm/xen-front: Drop pointless static qualifier in fb_destroy()
There is no need to have the 'struct drm_framebuffer *fb' variable
static since new value always be assigned before use it.
Signed-off-by: YueHaibing
---
drivers/gpu/drm/xen/xen_drm_front_kms.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/xen/xen_drm_front_kms.c
b/drivers/gpu/drm/xen/xen_drm_front_kms.c
index 860da05..c2955d3 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_kms.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_kms.c
@@ -54,7 +54,7 @@ static void fb_destroy(struct drm_framebuffer *fb)
const struct drm_mode_fb_cmd2 *mode_cmd)
{
struct xen_drm_front_drm_info *drm_info = dev->dev_private;
- static struct drm_framebuffer *fb;
+ struct drm_framebuffer *fb;
struct drm_gem_object *gem_obj;
int ret;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: enable uncached DMA optimization for ARM and arm64
On Fri, 25 Jan 2019 at 12:30, Christian König wrote: > > Am 25.01.19 um 09:43 schrieb Ard Biesheuvel: > > On Thu, 24 Jan 2019 at 15:01, Alex Deucher wrote: > >> On Thu, Jan 24, 2019 at 9:00 AM Ard Biesheuvel > >> wrote: > >>> On Thu, 24 Jan 2019 at 13:31, Koenig, Christian > >>> wrote: > Am 24.01.19 um 13:06 schrieb Ard Biesheuvel: > > The DRM driver stack is designed to work with cache coherent devices > > only, but permits an optimization to be enabled in some cases, where > > for some buffers, both the CPU and the GPU use uncached mappings, > > removing the need for DMA snooping and allocation in the CPU caches. > > > > The use of uncached GPU mappings relies on the correct implementation > > of the PCIe NoSnoop TLP attribute by the platform, otherwise the GPU > > will use cached mappings nonetheless. On x86 platforms, this does not > > seem to matter, as uncached CPU mappings will snoop the caches in any > > case. However, on ARM and arm64, enabling this optimization on a > > platform where NoSnoop is ignored results in loss of coherency, which > > breaks correct operation of the device. Since we have no way of > > detecting whether NoSnoop works or not, just disable this > > optimization entirely for ARM and arm64. > > > > Cc: Christian Koenig > > Cc: Alex Deucher > > Cc: David Zhou > > Cc: Huang Rui > > Cc: Junwei Zhang > > Cc: Michel Daenzer > > Cc: David Airlie > > Cc: Daniel Vetter > > Cc: Maarten Lankhorst > > Cc: Maxime Ripard > > Cc: Sean Paul > > Cc: Michael Ellerman > > Cc: Benjamin Herrenschmidt > > Cc: Will Deacon > > Cc: Christoph Hellwig > > Cc: Robin Murphy > > Cc: amd-gfx list > > Cc: dri-devel > > Reported-by: Carsten Haitzler > > Signed-off-by: Ard Biesheuvel > The subject line should probably read "disable uncached...". > > >>> Ugh, of course ... > >>> > With that fixed the patch is Reviewed-by: Christian König > . > > >> Same: > >> Reviewed-by: Alex Deucher > >> > > Thanks all > > > > Should I resend the patch with the subject corrected? > > I will update the subject line and push it upstream through > drm-misc-next if nobody objects. > Wonderful, thanks. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 00/13] drm/tegra: Fix IOVA space on Tegra186 and later
25.01.2019 12:23, Thierry Reding пишет: > On Fri, Jan 25, 2019 at 12:38:01AM +0300, Dmitry Osipenko wrote: >> 24.01.2019 21:02, Thierry Reding пишет: >>> From: Thierry Reding >>> >>> Tegra186 and later are different from earlier generations in that they >>> use an ARM SMMU rather than the Tegra SMMU. The ARM SMMU driver behaves >>> slightly differently in that the geometry for IOMMU domains is set only >>> after a device was attached to it. This is to make sure that the SMMU >>> instance that the domain belongs to is known, because each instance can >>> have a different input address space (i.e. geometry). >>> >>> Work around this by moving all IOVA allocations to a point where the >>> geometry of the domain is properly initialized. >>> >>> This second version of the series addresses all review comments and adds >>> a number of patches that will actually allow host1x to work with an SMMU >>> enabled on Tegra186. The patches also add programming required to >>> address the full 40 bits of address space. >>> >>> This supersedes the following patch: >>> >>> https://patchwork.kernel.org/patch/10775579/ >> >> My understanding is that falcon won't boot because source DMA address >> of the firmware isn't set up correctly if the address is >32bit. >> Please correct me if I'm wrong, otherwise that need to be addressed in >> this series as well for completeness. > > What makes you say so? I was runtime testing this series as I was > developing these patches and this works properly on Tegra186 with a 40 > bit address space. Since the carveout is allocated from the top of the > IOMMU aperture, the addresses that the Falcon sees are always from the > top of the 40 bit IOVA space and this works flawlessly. I looked again at the code and noticed this time that the address is *shifted* by 256 bytes. Mikko told yesterday about the alignment requirement, but I just wasn't seeing the shifting in the code. Looks good then! ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] i2c: of: Try to find an I2C adapter matching the parent
Am 25.01.19 um 14:11 schrieb Thierry Reding:
From: Thierry Reding
If an I2C adapter doesn't match the provided device tree node, also try
matching the parent's device tree node. This allows finding an adapter
based on the device node of the parent device that was used to register
it.
This fixes a regression on Tegra124-based Chromebooks (Nyan) where the
eDP controller registers an I2C adapter that is used to read to EDID.
After commit 993a815dcbb2 ("dt-bindings: panel: Add missing .txt
suffix") this stopped working because the I2C adapter could no longer
be found. The approach in this patch fixes the regression without
introducing the issues that the above commit solved.
Fixes: 17ab7806de0c ("drm: don't link DP aux i2c adapter to the hardware device
node")
Signed-off-by: Thierry Reding
---
Changes in v2:
- check for both device and parent device tree nodes for each device
instead of looping through the list of devices twice
drivers/i2c/i2c-core-of.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/i2c-core-of.c b/drivers/i2c/i2c-core-of.c
index 6cb7ad608bcd..0f01cdba9d2c 100644
--- a/drivers/i2c/i2c-core-of.c
+++ b/drivers/i2c/i2c-core-of.c
@@ -121,6 +121,17 @@ static int of_dev_node_match(struct device *dev, void
*data)
return dev->of_node == data;
}
+static int of_dev_or_parent_node_match(struct device *dev, void *data)
+{
+ if (dev->of_node == data)
+ return 1;
+
+ if (dev->parent)
+ return dev->parent->of_node == data;
+
+ return 0;
+}
+
/* must call put_device() when done with returned i2c_client device */
struct i2c_client *of_find_i2c_device_by_node(struct device_node *node)
{
@@ -145,7 +156,8 @@ struct i2c_adapter *of_find_i2c_adapter_by_node(struct
device_node *node)
struct device *dev;
struct i2c_adapter *adapter;
- dev = bus_find_device(_bus_type, NULL, node, of_dev_node_match);
+ dev = bus_find_device(_bus_type, NULL, node,
+ of_dev_or_parent_node_match);
if (!dev)
return NULL;
I've tested this and can confirm that this fixes the issue on the
nyan-big chromebook.
Is this fix going to be applied to the LTS kernels too?
Thanks.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amd/powerplay: Fix missing break in switch
Add missing break statement in order to prevent the code from falling
through to the default case.
The resoning for this is that pclk_vol_table is an automatic variable.
So, it makes no sense to update it just before falling through to the
default case and return -EINVAL.
This bug was found thanks to the ongoing efforts to enabling
-Wimplicit-fallthrough.
Fixes: cd70f3d6e3fa ("drm/amd/powerplay: PP/DAL interface changes for dynamic
clock switch")
Cc: sta...@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva
---
drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
index f95c5f50eb0f..5273de3c5b98 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
@@ -1033,6 +1033,7 @@ static int smu10_get_clock_by_type_with_latency(struct
pp_hwmgr *hwmgr,
break;
case amd_pp_dpp_clock:
pclk_vol_table = pinfo->vdd_dep_on_dppclk;
+ break;
default:
return -EINVAL;
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] Re: [PATCH v6 14/22] dt-bindings: sun6i-dsi: Add A64 DSI compatible (w/ A31 fallback)
On 25/01/19 9:22 PM, Maxime Ripard wrote: On Fri, Jan 25, 2019 at 01:28:52AM +0530, Jagan Teki wrote: The MIPI DSI controller in Allwinner A64 is similar to A33. But unlike A33, A64 doesn't have DSI_SCLK gating which eventually set the mod clock rate for the controller. So, use the DSI_DPHY gating for the similar purpose of mod clock so-that the controller can operate properly. Signed-off-by: Jagan Teki Reviewed-by: Rob Herring --- Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt b/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt index 69e233e8fad1..dbda2e567760 100644 --- a/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt +++ b/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt @@ -12,6 +12,7 @@ The DSI Encoder generates the DSI signal from the TCON's. Required properties: - compatible: value must be one of: * allwinner,sun6i-a31-mipi-dsi +* "allwinner,sun50i-a64-mipi-dsi", "allwinner,sun6i-a31-mipi-dsi" The other line doesn't have quotes, we should be consistent You mean to say, remove quotes like this allwinner,sun50i-a64-mipi-dsi, allwinner,sun6i-a31-mipi-dsi This make confusion with comma with allwinner vs next compatible string isn't it? (In fact I did follow the similar like TCON in sun4i-drm.txt) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/i915: Disable -Wuninitialized
On Fri, Jan 25, 2019 at 11:34 PM Nick Desaulniers
wrote:
>
> On Fri, Jan 25, 2019 at 11:13 PM Nathan Chancellor
> wrote:
> >
> > This warning is disabled by default in scripts/Makefile.extrawarn when
> > W= is not provided but this Makefile adds -Wall after this warning is
> > disabled so it shows up in the build when it shouldn't:
> >
> > In file included from drivers/gpu/drm/i915/intel_breadcrumbs.c:895:
> > drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c:350:34: error:
> > variable 'wq' is uninitialized when used within its own initialization
> > [-Werror,-Wuninitialized]
> > DECLARE_WAIT_QUEUE_HEAD_ONSTACK(wq);
> > ^~
> > ./include/linux/wait.h:74:63: note: expanded from macro
> > 'DECLARE_WAIT_QUEUE_HEAD_ONSTACK'
> > struct wait_queue_head name = __WAIT_QUEUE_HEAD_INIT_ONSTACK(name)
> > ^~~~
> > ./include/linux/wait.h:72:33: note: expanded from macro
> > '__WAIT_QUEUE_HEAD_INIT_ONSTACK'
> > ({ init_waitqueue_head(); name; })
> >^~~~
> > 1 error generated.
> >
> > Explicitly disable the warning like commit 46e2068081e9 ("drm/i915:
> > Disable some extra clang warnings").
> >
> > Link: https://github.com/ClangBuiltLinux/linux/issues/220
> > Signed-off-by: Nathan Chancellor
>
> Reviewed-by: Nick Desaulniers
gah! I am on my work device, in that case it should be:
Reviewed-by: Nick Desaulniers
>
> probably could give Chris Wilson the suggested by tag.
> https://lore.kernel.org/lkml/154513398652.1108.7150969916024071452@skylake-alporthouse-com/
>
> > ---
> >
> > v1 -> v2:
> >
> > * Rather than disable the warning for the problematic folder, disable it
> > for the entire folder like Matthias's commit.
>
> Thanks for following up with a v2.
>
> --
> Thanks,
> ~Nick Desaulniers
--
Thanks,
~Nick Desaulniers
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: etnaviv: try harder to generate a core dump
It is possible that the size of the BOs currently queued for the GPU
exceed our available memory for dumping a device core dump. If this
occures, try generating a core dump without containing the contents
of the BOs.
Signed-off-by: Russell King
---
drivers/gpu/drm/etnaviv/etnaviv_dump.c | 30 ++
1 file changed, 22 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_dump.c
b/drivers/gpu/drm/etnaviv/etnaviv_dump.c
index 9146e30e24a6..ed53a88eaea4 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_dump.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_dump.c
@@ -118,6 +118,7 @@ void etnaviv_core_dump(struct etnaviv_gpu *gpu)
unsigned int n_obj, n_bomap_pages;
size_t file_size, mmu_size;
__le64 *bomap, *bomap_start;
+ bool bos = true;
/* Only catch the first event, or when manually re-armed */
if (!etnaviv_dump_core)
@@ -126,6 +127,7 @@ void etnaviv_core_dump(struct etnaviv_gpu *gpu)
mmu_size = etnaviv_iommu_dump_size(gpu->mmu);
+again:
/* We always dump registers, mmu, ring and end marker */
n_obj = 4;
n_bomap_pages = 0;
@@ -148,9 +150,12 @@ void etnaviv_core_dump(struct etnaviv_gpu *gpu)
continue;
obj = vram->object;
- file_size += obj->base.size;
n_bomap_pages += obj->base.size >> PAGE_SHIFT;
- n_obj++;
+
+ if (bos) {
+ file_size += obj->base.size;
+ n_obj++;
+ }
}
/* If we have any buffer objects, add a bomap object */
@@ -166,6 +171,11 @@ void etnaviv_core_dump(struct etnaviv_gpu *gpu)
iter.start = __vmalloc(file_size, GFP_KERNEL | __GFP_NOWARN |
__GFP_NORETRY,
PAGE_KERNEL);
if (!iter.start) {
+ if (bos) {
+ dev_warn(gpu->dev, "devcoredump too big, trying without
bos\n");
+ bos = false;
+ goto again;
+ }
dev_warn(gpu->dev, "failed to allocate devcoredump file\n");
return;
}
@@ -223,14 +233,18 @@ void etnaviv_core_dump(struct etnaviv_gpu *gpu)
*bomap++ = cpu_to_le64(page_to_phys(*pages++));
}
- iter.hdr->iova = cpu_to_le64(vram->iova);
+ if (bos) {
+ iter.hdr->iova = cpu_to_le64(vram->iova);
- vaddr = etnaviv_gem_vmap(>base);
- if (vaddr)
- memcpy(iter.data, vaddr, obj->base.size);
+ vaddr = etnaviv_gem_vmap(>base);
+ dev_crit(gpu->dev, "Copying object %p ops %pS vaddr %p
to %p size %zu\n",
+ obj, obj->ops, vaddr, iter.data,
obj->base.size);
+ if (vaddr)
+ memcpy(iter.data, vaddr, obj->base.size);
- etnaviv_core_dump_header(, ETDUMP_BUF_BO, iter.data +
-obj->base.size);
+ etnaviv_core_dump_header(, ETDUMP_BUF_BO,
iter.data +
+obj->base.size);
+ }
}
etnaviv_core_dump_header(, ETDUMP_BUF_END, iter.data);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 00/13] drm/tegra: Fix IOVA space on Tegra186 and later
25.01.2019 11:57, Mikko Perttunen пишет: > On 24.1.2019 23.53, Dmitry Osipenko wrote: >> 24.01.2019 21:02, Thierry Reding пишет: >>> From: Thierry Reding >>> >>> Tegra186 and later are different from earlier generations in that they >>> use an ARM SMMU rather than the Tegra SMMU. The ARM SMMU driver behaves >>> slightly differently in that the geometry for IOMMU domains is set only >>> after a device was attached to it. This is to make sure that the SMMU >>> instance that the domain belongs to is known, because each instance can >>> have a different input address space (i.e. geometry). >>> >>> Work around this by moving all IOVA allocations to a point where the >>> geometry of the domain is properly initialized. >>> >>> This second version of the series addresses all review comments and adds >>> a number of patches that will actually allow host1x to work with an SMMU >>> enabled on Tegra186. The patches also add programming required to >>> address the full 40 bits of address space. >>> >>> This supersedes the following patch: >>> >>> https://patchwork.kernel.org/patch/10775579/ >> >> Secondly, seems there are additional restrictions for the host1x jobs on >> T186, at least T186 TRM suggests so. In particular looks like each client is >> hardwired to a specific sync point and to a specific channel. Or maybe there >> is assumption that upstream kernel could work only in a hypervisor mode or >> with all protections disable. Could you please clarify? >> > > There are no such syncpoint/channel restrictions. The upstream driver indeed > currently only supports the case where there is no "hypervisor" (that is, > server process that allocates host1x resources) running and the kernel has > access to the Host1x COMMON/"hypervisor" register aperture. > > Adding support for the situation where this is not the case shouldn't be very > difficult, but we currently don't have any upstream platforms where the > Host1x server exists (it's only there on automotive platforms). Thank you very much for the clarification! ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/5] drm/i2c: tda998x: add support for writing SPD
Add support for writing the SPD infoframe to the TDA998x. Identify us
as "Generic" vendor "PC" product, and as "PC general" source device
information.
Signed-off-by: Russell King
---
drivers/gpu/drm/i2c/tda998x_drv.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
index c399a7b73e2b..dad7396ebe2b 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -845,6 +845,23 @@ static int tda998x_write_aif(struct tda998x_priv *priv,
return 0;
}
+static void tda998x_write_spd(struct tda998x_priv *priv)
+{
+ union hdmi_infoframe frame;
+ int ret;
+
+ ret = hdmi_spd_infoframe_init(, "Generic", "PC");
+ if (ret < 0) {
+ dev_err(>hdmi->dev, "failed to fill SPD infoframe: %d\n",
+ ret);
+ return;
+ }
+
+ frame.spd.sdi = HDMI_SPD_SDI_PC;
+
+ tda998x_write_if(priv, DIP_IF_FLAGS_IF3, REG_IF3_HB0, );
+}
+
static void
tda998x_write_avi(struct tda998x_priv *priv, const struct drm_display_mode
*mode)
{
@@ -1554,6 +1571,7 @@ static void tda998x_bridge_mode_set(struct drm_bridge
*bridge,
reg_set(priv, REG_TX33, TX33_HDMI);
tda998x_write_avi(priv, adjusted_mode);
+ tda998x_write_spd(priv);
if (priv->audio_params.format != AFMT_UNUSED &&
priv->sink_has_audio)
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/i915: Disable -Wuninitialized
On Fri, Jan 25, 2019 at 11:13 PM Nathan Chancellor
wrote:
>
> This warning is disabled by default in scripts/Makefile.extrawarn when
> W= is not provided but this Makefile adds -Wall after this warning is
> disabled so it shows up in the build when it shouldn't:
>
> In file included from drivers/gpu/drm/i915/intel_breadcrumbs.c:895:
> drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c:350:34: error:
> variable 'wq' is uninitialized when used within its own initialization
> [-Werror,-Wuninitialized]
> DECLARE_WAIT_QUEUE_HEAD_ONSTACK(wq);
> ^~
> ./include/linux/wait.h:74:63: note: expanded from macro
> 'DECLARE_WAIT_QUEUE_HEAD_ONSTACK'
> struct wait_queue_head name = __WAIT_QUEUE_HEAD_INIT_ONSTACK(name)
> ^~~~
> ./include/linux/wait.h:72:33: note: expanded from macro
> '__WAIT_QUEUE_HEAD_INIT_ONSTACK'
> ({ init_waitqueue_head(); name; })
>^~~~
> 1 error generated.
>
> Explicitly disable the warning like commit 46e2068081e9 ("drm/i915:
> Disable some extra clang warnings").
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/220
> Signed-off-by: Nathan Chancellor
Reviewed-by: Nick Desaulniers
probably could give Chris Wilson the suggested by tag.
https://lore.kernel.org/lkml/154513398652.1108.7150969916024071452@skylake-alporthouse-com/
> ---
>
> v1 -> v2:
>
> * Rather than disable the warning for the problematic folder, disable it
> for the entire folder like Matthias's commit.
Thanks for following up with a v2.
--
Thanks,
~Nick Desaulniers
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/5] drm/i2c: tda998x: add vendor specific infoframe support
Add support for the vendor specific infoframe.
Signed-off-by: Russell King
---
drivers/gpu/drm/i2c/tda998x_drv.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
index dad7396ebe2b..b0ed2ef49c62 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -874,6 +874,19 @@ tda998x_write_avi(struct tda998x_priv *priv, const struct
drm_display_mode *mode
tda998x_write_if(priv, DIP_IF_FLAGS_IF2, REG_IF2_HB0, );
}
+static void tda998x_write_vsi(struct tda998x_priv *priv,
+ struct drm_display_mode *mode)
+{
+ union hdmi_infoframe frame;
+
+ if (drm_hdmi_vendor_infoframe_from_display_mode(,
+ >connector,
+ mode))
+ reg_clear(priv, REG_DIP_IF_FLAGS, DIP_IF_FLAGS_IF1);
+ else
+ tda998x_write_if(priv, DIP_IF_FLAGS_IF1, REG_IF1_HB0, );
+}
+
/* Audio support */
static void tda998x_audio_mute(struct tda998x_priv *priv, bool on)
@@ -1572,6 +1585,7 @@ static void tda998x_bridge_mode_set(struct drm_bridge
*bridge,
tda998x_write_avi(priv, adjusted_mode);
tda998x_write_spd(priv);
+ tda998x_write_vsi(priv, adjusted_mode);
if (priv->audio_params.format != AFMT_UNUSED &&
priv->sink_has_audio)
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/i915: Disable -Wuninitialized
On Fri, Jan 25, 2019 at 11:34:19PM -0800, Nick Desaulniers wrote:
> On Fri, Jan 25, 2019 at 11:13 PM Nathan Chancellor
> wrote:
> >
> > This warning is disabled by default in scripts/Makefile.extrawarn when
> > W= is not provided but this Makefile adds -Wall after this warning is
> > disabled so it shows up in the build when it shouldn't:
> >
> > In file included from drivers/gpu/drm/i915/intel_breadcrumbs.c:895:
> > drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c:350:34: error:
> > variable 'wq' is uninitialized when used within its own initialization
> > [-Werror,-Wuninitialized]
> > DECLARE_WAIT_QUEUE_HEAD_ONSTACK(wq);
> > ^~
> > ./include/linux/wait.h:74:63: note: expanded from macro
> > 'DECLARE_WAIT_QUEUE_HEAD_ONSTACK'
> > struct wait_queue_head name = __WAIT_QUEUE_HEAD_INIT_ONSTACK(name)
> > ^~~~
> > ./include/linux/wait.h:72:33: note: expanded from macro
> > '__WAIT_QUEUE_HEAD_INIT_ONSTACK'
> > ({ init_waitqueue_head(); name; })
> >^~~~
> > 1 error generated.
> >
> > Explicitly disable the warning like commit 46e2068081e9 ("drm/i915:
> > Disable some extra clang warnings").
> >
> > Link: https://github.com/ClangBuiltLinux/linux/issues/220
> > Signed-off-by: Nathan Chancellor
>
> Reviewed-by: Nick Desaulniers
>
> probably could give Chris Wilson the suggested by tag.
> https://lore.kernel.org/lkml/154513398652.1108.7150969916024071452@skylake-alporthouse-com/
>
Ugh you're right, completely slipped my mind.
Suggested-by: Chris Wilson
> > ---
> >
> > v1 -> v2:
> >
> > * Rather than disable the warning for the problematic folder, disable it
> > for the entire folder like Matthias's commit.
>
> Thanks for following up with a v2.
Thank you for the review!
Nathan
>
> --
> Thanks,
> ~Nick Desaulniers
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 1/1] drm: drop drm_bus from todo
David Herrmann removed the last bits of drm_bus in:
c5786fe5f1c50941dbe27fc8b4aa1afee46ae893 ("drm: Goody bye, drm_bus!")
Remove the todo item.
Signed-off-by: Sam Ravnborg
Cc: David Herrmann
Cc: David Airlie
Cc: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Sean Paul
---
Documentation/gpu/todo.rst | 19 ---
1 file changed, 19 deletions(-)
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 38360ede1221..d9515b17d36f 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -10,25 +10,6 @@ graphics subsystem useful as newbie projects. Or for slow
rainy days.
Subsystem-wide refactorings
===
-De-midlayer drivers
-
-With the recent ``drm_bus`` cleanup patches for 3.17 it is no longer required
-to have a ``drm_bus`` structure set up. Drivers can directly set up the
-``drm_device`` structure instead of relying on bus methods in ``drm_usb.c``
-and ``drm_pci.c``. The goal is to get rid of the driver's ``->load`` /
-``->unload`` callbacks and open-code the load/unload sequence properly, using
-the new two-stage ``drm_device`` setup/teardown.
-
-Once all existing drivers are converted we can also remove those bus support
-files for USB and platform devices.
-
-All you need is a GPU for a non-converted driver (currently almost all of
-them, but also all the virtual ones used by KVM, so everyone qualifies).
-
-Contact: Daniel Vetter, Thierry Reding, respective driver maintainers
-
-
Remove custom dumb_map_offset implementations
-
--
2.12.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/i915: Disable -Wuninitialized
Quoting Nathan Chancellor (2019-01-26 07:57:49)
> On Fri, Jan 25, 2019 at 11:34:19PM -0800, Nick Desaulniers wrote:
> > On Fri, Jan 25, 2019 at 11:13 PM Nathan Chancellor
> > wrote:
> > >
> > > This warning is disabled by default in scripts/Makefile.extrawarn when
> > > W= is not provided but this Makefile adds -Wall after this warning is
> > > disabled so it shows up in the build when it shouldn't:
> > >
> > > In file included from drivers/gpu/drm/i915/intel_breadcrumbs.c:895:
> > > drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c:350:34: error:
> > > variable 'wq' is uninitialized when used within its own initialization
> > > [-Werror,-Wuninitialized]
> > > DECLARE_WAIT_QUEUE_HEAD_ONSTACK(wq);
> > > ^~
> > > ./include/linux/wait.h:74:63: note: expanded from macro
> > > 'DECLARE_WAIT_QUEUE_HEAD_ONSTACK'
> > > struct wait_queue_head name = __WAIT_QUEUE_HEAD_INIT_ONSTACK(name)
> > > ^~~~
> > > ./include/linux/wait.h:72:33: note: expanded from macro
> > > '__WAIT_QUEUE_HEAD_INIT_ONSTACK'
> > > ({ init_waitqueue_head(); name; })
> > >^~~~
> > > 1 error generated.
> > >
> > > Explicitly disable the warning like commit 46e2068081e9 ("drm/i915:
> > > Disable some extra clang warnings").
> > >
> > > Link: https://github.com/ClangBuiltLinux/linux/issues/220
> > > Signed-off-by: Nathan Chancellor
> >
> > Reviewed-by: Nick Desaulniers
> >
> > probably could give Chris Wilson the suggested by tag.
> > https://lore.kernel.org/lkml/154513398652.1108.7150969916024071452@skylake-alporthouse-com/
> >
>
> Ugh you're right, completely slipped my mind.
>
> Suggested-by: Chris Wilson
Ignorance is bliss. Applied to dinq, thanks!
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109461] [amdgpu/radeonsi,HAWAII] Hand of Fate 2 leads to GPU lock up (display powered off, SSH works, keyboard dead): "flip_done timed out"
https://bugs.freedesktop.org/show_bug.cgi?id=109461 Bug ID: 109461 Summary: [amdgpu/radeonsi,HAWAII] Hand of Fate 2 leads to GPU lock up (display powered off, SSH works, keyboard dead): "flip_done timed out" Product: DRI Version: DRI git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: k...@dev.carbon-project.org Blocks: 77449 Created attachment 143232 --> https://bugs.freedesktop.org/attachment.cgi?id=143232=edit dmesg excerpt showing the backtraces and other DRM related entries Playing Hand of Fate 2 leads to reproducible lock ups of my HAWAII Pro GPU. Sometimes directly on initial load, sometimes after playing for a while. The system can be reached over SSH, but the attached input devices are dead (not even num lock changes work). In addition to this the display gets powered off (display turns black and shows behaviour as if looking for input, ie. the connector identifier is show. In dmesg I can see "flip_done timed out" errors and two backtraces (see attached dmesg excerpt for all the details): > [15465.441663] [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] > *ERROR* [CRTC:44:crtc-0] flip_done timed out > [15465.451746] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, > signaled seq=1164561, emitted seq=1164563 > [15465.451751] [drm] GPU recovery disabled. > [15467.233739] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma0 timeout, > signaled seq=171220, emitted seq=171221 > [15467.233746] [drm] GPU recovery disabled. > [15475.681643] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] > *ERROR* [CRTC:44:crtc-0] flip_done timed out > [15485.921664] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] > *ERROR* [PLANE:42:plane-5] flip_done timed out > [15485.921779] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* > amdgpu_dm_commit_planes: acrtc 0, already busy If you need data logged with umr, please provide me with the exact command I should run. The bug is reproducible with the following stack (Debian testing as a base): GPU: Hawaii PRO [Radeon R9 290] (ChipID = 0x67b1) Mesa: Git:master/8e9ad592c3 libdrm: 2.4.97 LLVM: SVN:trunk/r351739 (9.0 devel) X.Org: 2:1.20.3-1 Linux: 4.20.4 Firmware (firmware-amd-graphics): 20190114-1 libclc: Git:master/428e821c1e DDX (xserver-xorg-video-amdgpu): 18.1.0-1 Let me know if you need anything else. Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=77449 [Bug 77449] Tracker bug for all bugs related to Steam titles -- 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 4/4] drm/panel: Add Rondo RB070D30 panel
Hi Maxime / Konstantin.
Nice welstructured and small driver.
Please see a few comments below
Some of the comments in the following apply to a lot of
the existing panel drivers as well.
But lets see if we can get new drivers to be even better.
Sam
On Wed, Jan 23, 2019 at 04:54:24PM +0100, Maxime Ripard wrote:
> From: Konstantin Sudakov
>
> The Rondo RB070D30 panel is a MIPI-DSI panel based on a Fitipower EK79007
> controller and a 1024x600 panel.
>
> Signed-off-by: Konstantin Sudakov
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/panel/Kconfig| 9 +-
> drivers/gpu/drm/panel/Makefile | 1 +-
> drivers/gpu/drm/panel/panel-rondo-rb070d30.c | 258 -
> 3 files changed, 268 insertions(+)
> create mode 100644 drivers/gpu/drm/panel/panel-rondo-rb070d30.c
>
> diff --git a/drivers/gpu/drm/panel/panel-rondo-rb070d30.c
> b/drivers/gpu/drm/panel/panel-rondo-rb070d30.c
> new file mode 100644
> index ..4f8e63f367b1
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-rondo-rb070d30.c
> @@ -0,0 +1,258 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2018, Bridge Systems BV
> + * Copyright (C) 2018, Bootlin
> + * Copyright (C) 2017, Free Electrons
> + *
> + * This file based on panel-ilitek-ili9881c.c
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +#include
> +#include
> +#include
Please do not use drmP.h in new drivers. We are trying to get rid of it.
> +
> +#include
> +#include
> +#include
> +
> +struct rb070d30_panel {
> + struct drm_panel panel;
> + struct mipi_dsi_device *dsi;
> + struct backlight_device *backlight;
> + struct regulator *supply;
> +
> + struct {
> + struct gpio_desc *power;
> + struct gpio_desc *reset;
> + struct gpio_desc *updn;
> + struct gpio_desc *shlr;
> + } gpios;
> +};
> +
> +static inline struct rb070d30_panel *panel_to_rb070d30_panel(struct
> drm_panel *panel)
> +{
> + return container_of(panel, struct rb070d30_panel, panel);
> +}
> +
> +static int rb070d30_panel_prepare(struct drm_panel *panel)
> +{
> + struct rb070d30_panel *ctx = panel_to_rb070d30_panel(panel);
> + int ret;
> +
> + ret = regulator_enable(ctx->supply);
> + if (ret < 0) {
> + dev_err(>dsi->dev, "Failed to enable supply: %d\n", ret);
Use DRM_DEV_ERROR(...) to have consistent error message for the drm drivers.
This is general for the whole file.
> + return ret;
> + }
> +
> + /* Reset */
> + msleep(20);
> + gpiod_set_value(ctx->gpios.power, 1);
> + msleep(20);
> + gpiod_set_value(ctx->gpios.reset, 1);
> + msleep(20);
> + return 0;
> +}
To verify the above pointer to a datasheet would be nice.
> +
> +static int rb070d30_panel_unprepare(struct drm_panel *panel)
> +{
> + struct rb070d30_panel *ctx = panel_to_rb070d30_panel(panel);
> +
> + gpiod_set_value(ctx->gpios.power, 0);
> + gpiod_set_value(ctx->gpios.reset, 0);
> + regulator_disable(ctx->supply);
> +
> + return 0;
> +}
There is sometimes timing constrains after deassert reset..
The order is not strictly reverse of prepare - is that on purpose?
> +
> +static int rb070d30_panel_enable(struct drm_panel *panel)
> +{
> + struct rb070d30_panel *ctx = panel_to_rb070d30_panel(panel);
> + int ret;
> +
> + ret = mipi_dsi_dcs_exit_sleep_mode(ctx->dsi);
> + if (ret)
> + return ret;
> +
> + ret = backlight_enable(ctx->backlight);
> + if (ret)
> + goto out;
> +
> + return 0;
> +
> +out:
> + mipi_dsi_dcs_enter_sleep_mode(ctx->dsi);
> + return ret;
> +}
> +
> +static int rb070d30_panel_disable(struct drm_panel *panel)
> +{
> + struct rb070d30_panel *ctx = panel_to_rb070d30_panel(panel);
> +
> + backlight_disable(ctx->backlight);
> + return mipi_dsi_dcs_enter_sleep_mode(ctx->dsi);
> +}
> +
> +/* Default timings */
> +static const struct drm_display_mode default_mode = {
> + .clock = 51206,
> + .hdisplay = 1024,
> + .hsync_start= 1024 + 160,
> + .hsync_end = 1024 + 160 + 80,
> + .htotal = 1024 + 160 + 80 + 80,
> + .vdisplay = 600,
> + .vsync_start= 600 + 12,
> + .vsync_end = 600 + 12 + 10,
> + .vtotal = 600 + 12 + 10 + 13,
> + .vrefresh = 60,
> +};
height and width missing here. Seems better to add them here than hiding in
code below.
Is it on purpose that no flags are specified?
> +
> +static int rb070d30_panel_get_modes(struct drm_panel *panel)
> +{
> + struct drm_connector *connector = panel->connector;
> + struct rb070d30_panel *ctx = panel_to_rb070d30_panel(panel);
> + struct drm_display_mode *mode;
> + static const u32 bus_format = MEDIA_BUS_FMT_RGB888_1X24;
> +
> + mode = drm_mode_duplicate(panel->drm,
Re: [PATCH v9 2/2] drm/panel: Add Sitronix ST7701 panel driver
Hi Thierry. > ST7701 designed for small and medium sizes of TFT LCD display, is > capable of supporting up to 480RGBX864 in resolution. It provides > several system interfaces like MIPI/RGB/SPI. > > Currently added support for Techstar TS8550B which is ST7701 based > 480x854, 2-lane MIPI DSI LCD panel. > > Driver now registering mipi_dsi device, but indeed it can extendable > for RGB if any requirement trigger in future. > > Signed-off-by: Jagan Teki > Reviewed-by: Sam Ravnborg The driver is, as far as I can tell, ready to be committed to drm-misc. I assume you will take it. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/rockchip: check yuv2yuv existence before assigning window data
On Sat, 2019-01-26 at 01:24 +0100, Heiko Stuebner wrote:
> Before assigning window data, we should check if the yuv2yuv vop-data
> is set at all, because it looks like it can otherwise reference something
> wrong, as I saw on my rk3188 today which ended up in a null pointer
> dereference in vop_plane_atomic_update when accessing the yuv2yuv data.
>
> Fixes: 1c21aa8f2b68 ("drm/rockchip: Fix YUV buffers color rendering")
> Signed-off-by: Heiko Stuebner
> ---
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index 619b6db05d58..1dc9fd1ffbe3 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -1675,7 +1675,9 @@ static void vop_win_init(struct vop *vop)
>
> vop_win->data = win_data;
> vop_win->vop = vop;
> - vop_win->yuv2yuv_data = _data->win_yuv2yuv[i];
> +
> + if (vop_data->win_yuv2yuv)
> + vop_win->yuv2yuv_data = _data->win_yuv2yuv[i];
> }
> }
>
Ugh, another one of these.
Reviewed-by: Ezequiel Garcia
Thanks,
Eze
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105733] Amdgpu randomly hangs and only ssh works. Mouse cursor moves sometimes but does nothing. Keyboard stops working.
https://bugs.freedesktop.org/show_bug.cgi?id=105733 --- Comment #63 from l...@protonmail.ch --- Well, my GPU doesn't even work properly on Windows anymore. I do not think the GPU was originally faulty, as it *did* work without problems on Windows before, but now after having used it on Linux, it has the exact same problems on Windows. Hopefully I can get it replaced, but I will not use it on Linux anymore for fear of fucking it up again. -- 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 v6 4/5] drm: prepare for drmP.h removal from drm_modeset_helper.h
The use of drmP.h is discouraged and removal of it from drm_modeset_helper.h caused drm/ to fail to build. This patch introduce the necessary fixes to prepare for the drmP.h removal from drm_modeset_helper.h. Build tested on x86, arm, alpha, ia64 allmodconfig/allyesconfig. Signed-off-by: Sam Ravnborg Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Sean Paul Cc: David Airlie Cc: Daniel Vetter --- drivers/gpu/drm/drm_damage_helper.c | 1 + drivers/gpu/drm/drm_modeset_helper.c | 2 ++ 2 files changed, 3 insertions(+) diff --git a/drivers/gpu/drm/drm_damage_helper.c b/drivers/gpu/drm/drm_damage_helper.c index e16aa5ae00b4..ee67c96841fa 100644 --- a/drivers/gpu/drm/drm_damage_helper.c +++ b/drivers/gpu/drm/drm_damage_helper.c @@ -32,6 +32,7 @@ #include #include +#include /** * DOC: overview diff --git a/drivers/gpu/drm/drm_modeset_helper.c b/drivers/gpu/drm/drm_modeset_helper.c index 890eee07892d..da483125e063 100644 --- a/drivers/gpu/drm/drm_modeset_helper.c +++ b/drivers/gpu/drm/drm_modeset_helper.c @@ -22,8 +22,10 @@ #include #include +#include #include #include +#include #include /** -- 2.12.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 2/5] drm/i915: prepare for drmP.h removal from drm_modeset_helper.h
The use of drmP.h is discouraged and removal of it from
drm_modeset_helper.h caused i915 to fail to build.
This patch introduce the necessary fixes to prepare for the
drmP.h removal from drm_modeset_helper.h.
In the files touched the lists of include files was grouped
and sorted.
Build tested on x86 and arm allmodconfig / allyesconfig.
Signed-off-by: Sam Ravnborg
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: David Airlie
Cc: Daniel Vetter
Cc: intel-...@lists.freedesktop.org
---
drivers/gpu/drm/i915/i915_drv.c | 4 +++-
drivers/gpu/drm/i915/intel_atomic.c | 2 ++
drivers/gpu/drm/i915/intel_atomic_plane.c | 2 ++
drivers/gpu/drm/i915/intel_display.c | 29 -
drivers/gpu/drm/i915/intel_pm.c | 7 +--
5 files changed, 28 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 9883921013b1..8c8f36a91e7e 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -41,8 +41,10 @@
#include
#include
-#include
#include
+#include
+#include
+#include
#include
#include "i915_drv.h"
diff --git a/drivers/gpu/drm/i915/intel_atomic.c
b/drivers/gpu/drm/i915/intel_atomic.c
index d8dbc9980281..f415ed239184 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -31,7 +31,9 @@
#include
#include
+#include
#include
+
#include "intel_drv.h"
/**
diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index 683a75dad4fb..79139d496c78 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -32,7 +32,9 @@
*/
#include
+#include
#include
+
#include "intel_drv.h"
struct intel_plane *intel_plane_alloc(void)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 15d758cd0c1b..e0f40be07131 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -24,29 +24,32 @@
* Eric Anholt
*/
-#include
-#include
#include
+#include
+#include
#include
+#include
+#include
#include
#include
-#include
-#include "intel_drv.h"
-#include "intel_frontbuffer.h"
-#include
-#include "i915_drv.h"
-#include "i915_gem_clflush.h"
-#include "intel_dsi.h"
-#include "i915_trace.h"
+
#include
#include
+#include
#include
+#include
+#include
#include
#include
#include
-#include
-#include
-#include
+#include
+
+#include "i915_drv.h"
+#include "i915_gem_clflush.h"
+#include "i915_trace.h"
+#include "intel_drv.h"
+#include "intel_dsi.h"
+#include "intel_frontbuffer.h"
/* Primary plane formats for gen <= 3 */
static const uint32_t i8xx_primary_formats[] = {
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 83b01cde8113..48c755dc895b 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -26,13 +26,16 @@
*/
#include
+#include
#include
+
+#include
+#include
#include
+
#include "i915_drv.h"
#include "intel_drv.h"
#include "../../../platform/x86/intel_ips.h"
-#include
-#include
/**
* DOC: RC6
--
2.12.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 3/5] drm/rcar-du: prepare for drmP.h removal from drm_modeset_helper.h
The use of drmP.h is discouraged and removal of it from drm_modeset_helper.h caused rcar-du to fail to build. This patch introduce the necessary fixes to prepare for the drmP.h removal from drm_modeset_helper.h. Build tested on arm allmodconfig/allyesconfig. v2: - new patch. Changes like drm_probe_helper and other required several updates Signed-off-by: Sam Ravnborg Cc: Laurent Pinchart Cc: Kieran Bingham Cc: David Airlie Cc: Daniel Vetter Cc: linux-renesas-...@vger.kernel.org --- drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 3 +++ drivers/gpu/drm/rcar-du/rcar_du_drv.c | 1 + drivers/gpu/drm/rcar-du/rcar_du_kms.c | 2 ++ drivers/gpu/drm/rcar-du/rcar_du_plane.c | 2 ++ drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 1 + 5 files changed, 9 insertions(+) diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c index 93ee0020c9b1..4d1e5098b70e 100644 --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c @@ -9,14 +9,17 @@ #include #include +#include #include #include #include #include +#include #include #include #include +#include #include "rcar_du_crtc.h" #include "rcar_du_drv.h" diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c b/drivers/gpu/drm/rcar-du/rcar_du_drv.c index abd70d2931b0..75ab17af13a9 100644 --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c @@ -20,6 +20,7 @@ #include #include #include +#include #include #include diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c b/drivers/gpu/drm/rcar-du/rcar_du_kms.c index 663ab98d1f97..18d21bc1d265 100644 --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c @@ -10,10 +10,12 @@ #include #include #include +#include #include #include #include #include +#include #include #include diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c b/drivers/gpu/drm/rcar-du/rcar_du_plane.c index 321ac80b48d3..c6430027169f 100644 --- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c +++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c @@ -10,7 +10,9 @@ #include #include #include +#include #include +#include #include #include diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c index 76a39eee7c9c..0878accbd134 100644 --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c @@ -13,6 +13,7 @@ #include #include #include +#include #include #include -- 2.12.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 5/5] drm: remove drmP.h from drm_modeset_helper.h
With the removal of drmP.h from drm_modeset_helper.h the drmP.h are no longer included by any include files in include/drm. The drmP.h file is thus only included explicit either in .c files or in local .h files. This makes the process of deleting the drmP.h includes easier as we have a more local dependency chain. v2: - moved updates of .c files in drm/ to a dedicated patch. This allows the updates to the *.c files to be committed without the removal part. So this patch can wait if it causes build failures due to pending changes Signed-off-by: Sam Ravnborg Reviewed-by: Laurent Pinchart Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Sean Paul Cc: David Airlie Cc: Daniel Vetter --- include/drm/drm_modeset_helper.h | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/include/drm/drm_modeset_helper.h b/include/drm/drm_modeset_helper.h index efa337f03129..995fd981cab0 100644 --- a/include/drm/drm_modeset_helper.h +++ b/include/drm/drm_modeset_helper.h @@ -23,7 +23,11 @@ #ifndef __DRM_KMS_HELPER_H__ #define __DRM_KMS_HELPER_H__ -#include +struct drm_crtc; +struct drm_crtc_funcs; +struct drm_device; +struct drm_framebuffer; +struct drm_mode_fb_cmd2; void drm_helper_move_panel_connectors_to_head(struct drm_device *); -- 2.12.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 0/5] drm: minimize drmP.h dependencies
Updated patchset, with merged patches removed, new patches added.
> From the original mail:
- drmP.h is now stripped down to include files
and forward declarations.
- All header files in include/drm/ no longer include drmP.h.
The series was made on top of drm-misc-next:
f1a2a540c86441016ce3dff6590b7a09080871de ("video/hdmi: Add an enum for HDMI
packet types")
Build tested using arm and x86, ia64, alpha, sparc32, sparc64
Included staging/vboxvideo in the build test - which revealed
the build issues Daniel had identifed
This series include fixes to i915 as it looks in drm-misc.
This series also include fixes to stagin/vboxvideo, which I
expect to be committet to drm-misc due to the final patch
(drmP.h removal from drm_modeset_helper.h) depending on this patch.
Daniel - thanks for being paitent and applying this piecemal.
Sam
v6:
- include fixes to vboxvideo (Daniel)
- include i915 build fixes
- revised/new rcar-du patch (lots of new build failures popped up)
- split updates to drm/*.c file to dedicated patch,
to make the final removal patch slimmer
v5:
- Rebased on top of drm-misc-next and dropped patches already merged
- Sorted list of include files where they are touched (Laurent)
- Collected ack's, reviewed by's
v4:
- Rebased on top of drm-misc-next and dropped patches already merged
- Include build test of kirin (Daniel)
- Plug drm_util.h into drm-internals.rst (Daniel)
- Fix kernel-doc syntax in drm_util.h (Daniel)
- Split removal of drmP.h from drm_modeset_helper.h
in smaller patches, to ease the merge process
v3:
- Added Acks/Reviewed annotations (thanks!)
- Add forward of drm_gem_object to drm_framebuffer.h (Noralf)
- Drop "drm: move DRM_IF_VERSION to drm_internal.h" as it is applied to drm-misc
- Drop "drm: make drm_file.h self contained" as Jan made a similar patch that
was appleid to drm-misc
- Rebased on top of drm-misc-next
v2:
- DRM_SWITCH_POWER as enum (Daniel Vetter)
- Prefer forward decalration over includes (Laurent Pinchart)
- Updated drm_device to use kerneldoc style (Daniel Vetter)
- Improved commit messages (David Lechner)
- Split up patch when removing drmP.h from drm_gem_cma_helper.h
- rebased on top of drm-misc-next
- dropped patch already applied
- added reviewed-by from Laurent Pinchart (Laurent Pinchart)
- add drm_framebuffer.h patch
- add kernel-doc comments to drm_util.h
- moved EXPORT_SYMBOL_FOR_TESTS_ONLY to drm_util.h
- added note to drmP.h not to add new stuff and not to use in new files
Sam Ravnborg (5):
staging/vboxvideo: prepare for drmP.h removal from drm_modeset_helper.h
drm/i915: prepare for drmP.h removal from drm_modeset_helper.h
drm/rcar-du: prepare for drmP.h removal from drm_modeset_helper.h
drm: prepare for drmP.h removal from drm_modeset_helper.h
drm: remove drmP.h from drm_modeset_helper.h
drivers/gpu/drm/drm_damage_helper.c | 1 +
drivers/gpu/drm/drm_modeset_helper.c | 2 ++
drivers/gpu/drm/i915/i915_drv.c | 4 +++-
drivers/gpu/drm/i915/intel_atomic.c | 2 ++
drivers/gpu/drm/i915/intel_atomic_plane.c | 2 ++
drivers/gpu/drm/i915/intel_display.c | 29 -
drivers/gpu/drm/i915/intel_pm.c | 7 +--
drivers/gpu/drm/rcar-du/rcar_du_crtc.c| 3 +++
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 1 +
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 2 ++
drivers/gpu/drm/rcar-du/rcar_du_plane.c | 2 ++
drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 1 +
drivers/staging/vboxvideo/vbox_drv.c | 6 +-
drivers/staging/vboxvideo/vbox_fb.c | 18 ++
drivers/staging/vboxvideo/vbox_mode.c | 5 -
include/drm/drm_modeset_helper.h | 6 +-
16 files changed, 64 insertions(+), 27 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 1/5] staging/vboxvideo: prepare for drmP.h removal from drm_modeset_helper.h
The use of drmP.h is discouraged and removal of it from drm_modeset_helper.h caused vboxvideo to fail to build. This patch introduce the necessary fixes to prepare for the drmP.h removal from drm_modeset_helper.h. In the files touched sort the include files Build tested on x86 and arm allmodconfig / allyesconfig. Signed-off-by: Sam Ravnborg Cc: Greg Kroah-Hartman Cc: Hans de Goede Cc: Daniel Vetter --- drivers/staging/vboxvideo/vbox_drv.c | 6 +- drivers/staging/vboxvideo/vbox_fb.c | 18 ++ drivers/staging/vboxvideo/vbox_mode.c | 5 - 3 files changed, 19 insertions(+), 10 deletions(-) diff --git a/drivers/staging/vboxvideo/vbox_drv.c b/drivers/staging/vboxvideo/vbox_drv.c index cc6532d8c2fa..d1b0d7b4886a 100644 --- a/drivers/staging/vboxvideo/vbox_drv.c +++ b/drivers/staging/vboxvideo/vbox_drv.c @@ -7,11 +7,15 @@ * Michael Thayer */ -#include #include +#include +#include #include #include +#include +#include +#include #include "vbox_drv.h" diff --git a/drivers/staging/vboxvideo/vbox_fb.c b/drivers/staging/vboxvideo/vbox_fb.c index 397496cf0bdf..83a04afd1766 100644 --- a/drivers/staging/vboxvideo/vbox_fb.c +++ b/drivers/staging/vboxvideo/vbox_fb.c @@ -6,20 +6,22 @@ * Authors: Dave Airlie * Michael Thayer -#include -#include -#include -#include -#include -#include #include +#include #include #include +#include +#include +#include +#include +#include +#include +#include #include -#include #include +#include +#include #include "vbox_drv.h" #include "vboxvideo.h" diff --git a/drivers/staging/vboxvideo/vbox_mode.c b/drivers/staging/vboxvideo/vbox_mode.c index 1aaff02c07ff..213551394495 100644 --- a/drivers/staging/vboxvideo/vbox_mode.c +++ b/drivers/staging/vboxvideo/vbox_mode.c @@ -10,14 +10,17 @@ * Hans de Goede */ #include + #include #include +#include #include #include +#include +#include "hgsmi_channels.h" #include "vbox_drv.h" #include "vboxvideo.h" -#include "hgsmi_channels.h" /* * Set a graphics mode. Poke any required values into registers, do an HGSMI -- 2.12.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109177] Blender 2.8 triggers GPU lockup when entering Edit Mode
https://bugs.freedesktop.org/show_bug.cgi?id=109177 MirceaKitsune changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from MirceaKitsune --- This does seem to have been solved in either the latest Blender 2.8 build or Mesa version: I can now go into Edit Mode on meshes with a lot of vertices, no longer getting either the graphical corruption or any GPU crashes. As the issue appears to be fixed and I no longer have a test case, we can close this. Will reopen in case the same issue surfaces again anytime soon. -- 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 109102] At dual monitor intel_do_flush_locked failed: Resource deadlock avoided
https://bugs.freedesktop.org/show_bug.cgi?id=109102 --- Comment #4 from Gert vd Kraats --- Created attachment 143231 --> https://bugs.freedesktop.org/attachment.cgi?id=143231=edit libdrm-patch -- 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 109102] At dual monitor intel_do_flush_locked failed: Resource deadlock avoided
https://bugs.freedesktop.org/show_bug.cgi?id=109102 --- Comment #3 from Gert vd Kraats --- I am using intel i915 gen 3 with 16 fence registers. When displaying the variable total_fences at function drm_intel_gem_check_aperture_space at libdrm-2.4.95/intel/intel_bufmgr_gem.c, it is seen that the deadlock-abort is occurring at total_fences == 16, where the previous display shows total_fences == 14, so there is an increment of 2 fences in stead of the usual increment of 1. Apparently the deadlock occurs at the "freeing fences phase", that is started if total_fences is too high. I decided to lower the available_fences from 14 to 13 (see proposed patch). This solved the problem. After this patch I still saw sometimes total_fences == 16, where the previous display shows total_fences == 13, so there is an increment of 3 fences. This did not cause a deadlock at the "freeing fences phase". -- 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
