[Bug 109206] Kernel 4.20 amdgpu fails to load firmware on Ryzen 2500U
https://bugs.freedesktop.org/show_bug.cgi?id=109206 Bug ID: 109206 Summary: Kernel 4.20 amdgpu fails to load firmware on Ryzen 2500U Product: DRI Version: DRI git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: grak...@gmail.com On Kernel 4.20.0-arch1, amdgpu psp fails to load firmware, crashing system during boot. modprobe.blacklist=amdgpu allowed system to boot, without dm. System is an HP Envy x360 Ryzen 5 2500U Laptop. Jan 01 08:36:42 mimisbrunnr kernel: Linux agpgart interface v0.103 Jan 01 08:36:42 mimisbrunnr kernel: AMD IOMMUv2 driver by Joerg Roedel Jan 01 08:36:42 mimisbrunnr kernel: [drm] amdgpu kernel modesetting enabled. Jan 01 08:36:42 mimisbrunnr kernel: Parsing CRAT table with 1 nodes Jan 01 08:36:42 mimisbrunnr kernel: Ignoring ACPI CRAT on non-APU system Jan 01 08:36:42 mimisbrunnr kernel: Virtual CRAT table created for CPU Jan 01 08:36:42 mimisbrunnr kernel: Parsing CRAT table with 1 nodes Jan 01 08:36:42 mimisbrunnr kernel: Creating topology SYSFS entries Jan 01 08:36:42 mimisbrunnr kernel: Topology: Add CPU node Jan 01 08:36:42 mimisbrunnr kernel: Finished initializing topology Jan 01 08:36:42 mimisbrunnr kernel: checking generic (e000 7f) vs hw (e000 1000) Jan 01 08:36:42 mimisbrunnr kernel: fb0: switching to amdgpudrmfb from EFI VGA Jan 01 08:36:42 mimisbrunnr kernel: Console: switching to colour dummy device 80x25 Jan 01 08:36:42 mimisbrunnr kernel: amdgpu :03:00.0: enabling device (0006 -> 0007) Jan 01 08:36:42 mimisbrunnr kernel: [drm] initializing kernel modesetting (RAVEN 0x1002:0x15DD 0x103C:0x83C6 0xC4). Jan 01 08:36:42 mimisbrunnr kernel: [drm] register mmio base: 0xFE00 Jan 01 08:36:42 mimisbrunnr kernel: [drm] register mmio size: 524288 Jan 01 08:36:42 mimisbrunnr kernel: [drm] add ip block number 0 Jan 01 08:36:42 mimisbrunnr kernel: [drm] add ip block number 1 Jan 01 08:36:42 mimisbrunnr kernel: [drm] add ip block number 2 Jan 01 08:36:42 mimisbrunnr kernel: [drm] add ip block number 3 Jan 01 08:36:42 mimisbrunnr kernel: [drm] add ip block number 4 Jan 01 08:36:42 mimisbrunnr kernel: [drm] add ip block number 5 Jan 01 08:36:42 mimisbrunnr kernel: [drm] add ip block number 6 Jan 01 08:36:42 mimisbrunnr kernel: [drm] add ip block number 7 Jan 01 08:36:42 mimisbrunnr kernel: [drm] add ip block number 8 Jan 01 08:36:42 mimisbrunnr kernel: [drm] VCN decode is enabled in VM mode Jan 01 08:36:42 mimisbrunnr kernel: [drm] VCN encode is enabled in VM mode Jan 01 08:36:42 mimisbrunnr kernel: [drm] VCN jpeg decode is enabled in VM mode Jan 01 08:36:42 mimisbrunnr kernel: ATOM BIOS: SWBRT25890.001 Jan 01 08:36:42 mimisbrunnr kernel: [drm] vm size is 262144 GB, 4 levels, block size is 9-bit, fragment size is 9-bit Jan 01 08:36:42 mimisbrunnr kernel: amdgpu :03:00.0: VRAM: 256M 0x00F4 - 0x00F40FFF (256M used) Jan 01 08:36:42 mimisbrunnr kernel: amdgpu :03:00.0: GART: 1024M 0x - 0x3FFF Jan 01 08:36:42 mimisbrunnr kernel: amdgpu :03:00.0: AGP: 267419648M 0x00F8 - 0x Jan 01 08:36:42 mimisbrunnr kernel: [drm] Detected VRAM RAM=256M, BAR=256M Jan 01 08:36:42 mimisbrunnr kernel: [drm] RAM width 128bits UNKNOWN Jan 01 08:36:42 mimisbrunnr kernel: [TTM] Zone kernel: Available graphics memory: 3964154 kiB Jan 01 08:36:42 mimisbrunnr kernel: [TTM] Zone dma32: Available graphics memory: 2097152 kiB Jan 01 08:36:42 mimisbrunnr kernel: [TTM] Initializing pool allocator Jan 01 08:36:42 mimisbrunnr kernel: [TTM] Initializing DMA pool allocator Jan 01 08:36:42 mimisbrunnr kernel: [drm] amdgpu: 256M of VRAM memory ready Jan 01 08:36:42 mimisbrunnr kernel: [drm] amdgpu: 3072M of GTT memory ready. Jan 01 08:36:42 mimisbrunnr kernel: [drm] GART: num cpu pages 262144, num gpu pages 262144 Jan 01 08:36:42 mimisbrunnr kernel: [drm] PCIE GART of 1024M enabled (table at 0x00F4007E9000). Jan 01 08:36:42 mimisbrunnr kernel: [drm] use_doorbell being set to: [true] Jan 01 08:36:42 mimisbrunnr kernel: [drm] Found VCN firmware Version: 1.73 Family ID: 18 Jan 01 08:36:42 mimisbrunnr kernel: [drm] PSP loading VCN firmware Jan 01 08:36:42 mimisbrunnr kernel: [drm] reserve 0x40 from 0xf400b0 for PSP TMR SIZE Jan 01 08:36:43 mimisbrunnr kernel: [drm:psp_cmd_submit_buf [amdgpu]] *ERROR* failed loading with status (-65530) and ucode id (19) Jan 01 08:36:43 mimisbrunnr kernel: [drm:psp_hw_init [amdgpu]] *ERROR* PSP firmware loading failed Jan 01 08:36:43 mimisbrunnr kernel: [drm:amdgpu_device_fw_loading [amdgpu]] *ERROR* hw_init of IP block failed -22 Jan 01 08:36:43 mimisbrunnr kernel: amdgpu :03:00.0: amdgpu_device_ip_init failed Jan 01 08:36:43 mimisbrunnr kernel: amdgpu :03:00.0: Fatal error during GPU init Jan 01 0
[Bug 109206] Kernel 4.20 amdgpu fails to load firmware on Ryzen 2500U
https://bugs.freedesktop.org/show_bug.cgi?id=109206 --- Comment #1 from grak...@gmail.com --- Created attachment 142935 --> https://bugs.freedesktop.org/attachment.cgi?id=142935&action=edit Kernel 4.20 log showing firmware loading crash -- 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 108771] [amdgpu] hang with The Last Story on the Dolphin emulator
https://bugs.freedesktop.org/show_bug.cgi?id=108771 Alex Deucher changed: What|Removed |Added Summary|[amdgpu] *ERROR* ring gfx |[amdgpu] hang with The Last |timeout |Story on the Dolphin ||emulator -- 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 107261] [drm:generic_reg_wait [amdgpu]] *ERROR* REG_WAIT timeout 1us * 10 tries - optc1_lock line:628
https://bugs.freedesktop.org/show_bug.cgi?id=107261 --- Comment #12 from Alex Deucher --- Depending on your configuration, it may be fixed with this patch: https://cgit.freedesktop.org/drm/drm/commit/?id=8c9d90eebd23b6d40ddf4ce5df5ca2b932336a06 -- 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 108992] Regression: Lenovo e585 (ryzen 2500u) freezes during boot with 4.20-rc5/rc6, amdgpu error
https://bugs.freedesktop.org/show_bug.cgi?id=108992 --- Comment #20 from Ian Kidd --- Seeing same issue with Dell 5575 (AMD 2500u, Vega mobile) on 4.20 Release. iommu=soft seems to allow boot. Kernel Log: https://gist.github.com/ikidd/692dea4c63cc7656247071322d066405 -- 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 104206] [drm:construct [amdgpu]] *ERROR* construct: Invalid Connector ObjectID from Adapter Service for connector index:2!
https://bugs.freedesktop.org/show_bug.cgi?id=104206 JerryD changed: What|Removed |Added CC||jvdeli...@charter.net --- Comment #21 from JerryD --- Created attachment 142936 --> https://bugs.freedesktop.org/attachment.cgi?id=142936&action=edit More recent dmesg with the error. There are a number of other issues with this machine still, but it appears to be running stable. Providing this as a datapoint if you need it. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Nouveau module results in total lockups without any dmesg trace on a NP900X5N Kaby Lake machine
On Tue, Jan 1, 2019 at 4:06 PM Jan Vlietland wrote: > > Hi Ben, David and Daniel , > > First of all happy new year. Based on advice of Greg K-H herewith a mail > about a number of Nouveau issues with my laptop. > > I installed various Kali linux versions up to Linux 4.20.0-rc7 > (downloaded, compiled and installed) on a Samsung NP900X5N laptop and > have an issue with the driver after loading. > > My configuration: > > - i7 7500 > - 16 gb / 256 gb ssd > - nvidia 940MX (for 3D graphics) > > When I enable loading of the nouveau module for my Nvidia 3D card I get > three MMIO faults: > > [ 35.984104] nouveau :01:00.0: bus: MMIO read of FAULT at > 6013d4 [ IBUS ] > [ 35.997510] nouveau :01:00.0: bus: MMIO read of FAULT at > 10ac08 [ IBUS ] > [ 37.551790] nouveau :01:00.0: bus: MMIO read of FAULT at > 619444 [ IBUS ] > > I see currenty varous discussions on bugzilla: (as summarized by Bruno > Pagani) https://bugs.freedesktop.org/show_bug.cgi?id=100423. > > But I do not see any confirmed solutions on the MMIO faults. > > The module is loaded but X server cannot run in framebuffer mode. I > assume that the module does not provide any video memory to X to run in > graphics mode. > > First of all I would like to understand what the faults impose. > And I also would like to help you providing testing to fix the errors. The faults are, generally, nothing to worry about, esp if they occur infrequently. It's one bit or another of code that's poking at a part of the GPU it shouldn't be touching. To the best of my knowledge, 940MX (GM108) should work reasonably well. Perhaps it would make most sense if you posted about some of your other issues (usually GM108's are have no outputs, so only usable as offload devices). Feel free to join #nouveau on irc.freenode.net to get more info as well. Cheers, -ilia ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 20/25] powerpc, fbdev: Use arch_nvram_ops methods instead of nvram_read_byte() and nvram_write_byte()
Finn Thain a écrit :
Make use of arch_nvram_ops in device drivers so that the nvram_* function
exports can be removed.
Since they are no longer global symbols, rename the PPC32 nvram_* functions
appropriately.
Signed-off-by: Finn Thain
---
arch/powerpc/kernel/setup_32.c | 8
drivers/char/generic_nvram.c | 4 ++--
drivers/video/fbdev/controlfb.c| 4 ++--
drivers/video/fbdev/imsttfb.c | 4 ++--
drivers/video/fbdev/matrox/matroxfb_base.c | 2 +-
drivers/video/fbdev/platinumfb.c | 4 ++--
drivers/video/fbdev/valkyriefb.c | 4 ++--
7 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index e0d045677472..bdbe6acbef11 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -152,20 +152,18 @@ __setup("l3cr=", ppc_setup_l3cr);
#ifdef CONFIG_GENERIC_NVRAM
-unsigned char nvram_read_byte(int addr)
+static unsigned char ppc_nvram_read_byte(int addr)
{
if (ppc_md.nvram_read_val)
return ppc_md.nvram_read_val(addr);
return 0xff;
}
-EXPORT_SYMBOL(nvram_read_byte);
-void nvram_write_byte(unsigned char val, int addr)
+static void ppc_nvram_write_byte(unsigned char val, int addr)
{
if (ppc_md.nvram_write_val)
ppc_md.nvram_write_val(addr, val);
}
-EXPORT_SYMBOL(nvram_write_byte);
static ssize_t ppc_nvram_get_size(void)
{
@@ -182,6 +180,8 @@ static long ppc_nvram_sync(void)
}
const struct nvram_ops arch_nvram_ops = {
+ .read_byte = ppc_nvram_read_byte,
+ .write_byte = ppc_nvram_write_byte,
.get_size = ppc_nvram_get_size,
.sync = ppc_nvram_sync,
};
diff --git a/drivers/char/generic_nvram.c b/drivers/char/generic_nvram.c
index f32d5663de95..41b76bf9614e 100644
--- a/drivers/char/generic_nvram.c
+++ b/drivers/char/generic_nvram.c
@@ -48,7 +48,7 @@ static ssize_t read_nvram(struct file *file, char
__user *buf,
if (*ppos >= nvram_len)
return 0;
for (i = *ppos; count > 0 && i < nvram_len; ++i, ++p, --count)
- if (__put_user(nvram_read_byte(i), p))
+ if (__put_user(arch_nvram_ops.read_byte(i), p))
Instead of modifying all drivers (in this patch and previous ones
related to other arches), wouldn't it be better to add helpers like
the following in nvram.h:
Static inline unsigned char nvram_read_byte(int addr)
{
return arch_nvram_ops.read_byte(addr);
}
Christophe
return -EFAULT;
*ppos = i;
return p - buf;
@@ -68,7 +68,7 @@ static ssize_t write_nvram(struct file *file,
const char __user *buf,
for (i = *ppos; count > 0 && i < nvram_len; ++i, ++p, --count) {
if (__get_user(c, p))
return -EFAULT;
- nvram_write_byte(c, i);
+ arch_nvram_ops.write_byte(c, i);
}
*ppos = i;
return p - buf;
diff --git a/drivers/video/fbdev/controlfb.c
b/drivers/video/fbdev/controlfb.c
index 9cb0ef7ac29e..27ff33ccafcb 100644
--- a/drivers/video/fbdev/controlfb.c
+++ b/drivers/video/fbdev/controlfb.c
@@ -413,7 +413,7 @@ static int __init init_control(struct fb_info_control *p)
/* Try to pick a video mode out of NVRAM if we have one. */
#ifdef CONFIG_NVRAM
if (default_cmode == CMODE_NVRAM) {
- cmode = nvram_read_byte(NV_CMODE);
+ cmode = arch_nvram_ops.read_byte(NV_CMODE);
if(cmode < CMODE_8 || cmode > CMODE_32)
cmode = CMODE_8;
} else
@@ -421,7 +421,7 @@ static int __init init_control(struct fb_info_control *p)
cmode=default_cmode;
#ifdef CONFIG_NVRAM
if (default_vmode == VMODE_NVRAM) {
- vmode = nvram_read_byte(NV_VMODE);
+ vmode = arch_nvram_ops.read_byte(NV_VMODE);
if (vmode < 1 || vmode > VMODE_MAX ||
control_mac_modes[vmode - 1].m[full] < cmode) {
sense = read_control_sense(p);
diff --git a/drivers/video/fbdev/imsttfb.c b/drivers/video/fbdev/imsttfb.c
index 8d231591ff0e..e9f3b8914145 100644
--- a/drivers/video/fbdev/imsttfb.c
+++ b/drivers/video/fbdev/imsttfb.c
@@ -1393,12 +1393,12 @@ static void init_imstt(struct fb_info *info)
int vmode = init_vmode, cmode = init_cmode;
if (vmode == -1) {
- vmode = nvram_read_byte(NV_VMODE);
+ vmode = arch_nvram_ops.read_byte(NV_VMODE);
if (vmode <= 0 || vmode > VMODE_MAX)
vmode = VMODE_640_480_67;
}
if (cmode == -1) {
- cmode = nvram_read_byte(NV_CMODE);
+ cmode = arch_nvram_ops.read_byte(NV_CMODE);
if (cmode < CMODE_8 || cmode > CMODE_32)
[PATCH v2 6/7] ARM: dts: rockchip: add rk3066 hdmi nodes
From: Zheng Yang
This patch adds the hdmi nodes to rk3066.
Signed-off-by: Zheng Yang
Signed-off-by: Johan Jonker
---
arch/arm/boot/dts/rk3066a.dtsi | 44 ++
1 file changed, 44 insertions(+)
diff --git a/arch/arm/boot/dts/rk3066a.dtsi b/arch/arm/boot/dts/rk3066a.dtsi
index 653127a37..f95ce9881 100644
--- a/arch/arm/boot/dts/rk3066a.dtsi
+++ b/arch/arm/boot/dts/rk3066a.dtsi
@@ -80,6 +80,10 @@
vop0_out: port {
#address-cells = <1>;
#size-cells = <0>;
+ vop0_out_hdmi: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&hdmi_in_vop0>;
+ };
};
};
@@ -101,6 +105,36 @@
vop1_out: port {
#address-cells = <1>;
#size-cells = <0>;
+ vop1_out_hdmi: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&hdmi_in_vop1>;
+ };
+ };
+ };
+
+ hdmi: hdmi@10116000 {
+ compatible = "rockchip,rk3066-hdmi";
+ reg = <0x10116000 0x2000>;
+ interrupts = ;
+ clocks = <&cru HCLK_HDMI>;
+ clock-names = "hclk";
+ power-domains = <&power RK3066_PD_VIO>;
+ rockchip,grf = <&grf>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&hdmii2c_xfer>, <&hdmi_hpd>;
+ status = "disabled";
+
+ hdmi_in: port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ hdmi_in_vop0: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&vop0_out_hdmi>;
+ };
+ hdmi_in_vop1: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&vop1_out_hdmi>;
+ };
};
};
@@ -415,6 +449,16 @@
};
};
+ hdmi {
+ hdmi_hpd: hdmi-hpd {
+ rockchip,pins = <0 RK_PA0 1 &pcfg_pull_default>;
+ };
+ hdmii2c_xfer: hdmii2c-xfer {
+ rockchip,pins = <0 RK_PA1 1 &pcfg_pull_none>,
+ <0 RK_PA2 1 &pcfg_pull_none>;
+ };
+ };
+
pwm0 {
pwm0_out: pwm0-out {
rockchip,pins = ;
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/3] drm/exynos: rotator: Add support for s5pv210
This commit adds support for s5pv210.
Currently only NV12 and XRGB formats are supported.
It was tested by using tool from
https://www.spinics.net/lists/linux-samsung-soc/msg60498.html
Signed-off-by: Paweł Chmiel
---
drivers/gpu/drm/exynos/exynos_drm_rotator.c | 23 +
1 file changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
index 8d67b2a54be3..05abfed6f7f8 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
@@ -356,6 +356,11 @@ static int rotator_runtime_resume(struct device *dev)
}
#endif
+static const struct drm_exynos_ipp_limit rotator_s5pv210_rbg888_limits[] = {
+ { IPP_SIZE_LIMIT(BUFFER, .h = { 8, SZ_16K }, .v = { 8, SZ_16K }) },
+ { IPP_SIZE_LIMIT(AREA, .h.align = 2, .v.align = 2) },
+};
+
static const struct drm_exynos_ipp_limit rotator_4210_rbg888_limits[] = {
{ IPP_SIZE_LIMIT(BUFFER, .h = { 8, SZ_16K }, .v = { 8, SZ_16K }) },
{ IPP_SIZE_LIMIT(AREA, .h.align = 4, .v.align = 4) },
@@ -371,6 +376,11 @@ static const struct drm_exynos_ipp_limit
rotator_5250_rbg888_limits[] = {
{ IPP_SIZE_LIMIT(AREA, .h.align = 2, .v.align = 2) },
};
+static const struct drm_exynos_ipp_limit rotator_s5pv210_yuv_limits[] = {
+ { IPP_SIZE_LIMIT(BUFFER, .h = { 32, SZ_64K }, .v = { 32, SZ_64K }) },
+ { IPP_SIZE_LIMIT(AREA, .h.align = 8, .v.align = 8) },
+};
+
static const struct drm_exynos_ipp_limit rotator_4210_yuv_limits[] = {
{ IPP_SIZE_LIMIT(BUFFER, .h = { 32, SZ_64K }, .v = { 32, SZ_64K }) },
{ IPP_SIZE_LIMIT(AREA, .h.align = 8, .v.align = 8) },
@@ -381,6 +391,11 @@ static const struct drm_exynos_ipp_limit
rotator_4412_yuv_limits[] = {
{ IPP_SIZE_LIMIT(AREA, .h.align = 8, .v.align = 8) },
};
+static const struct exynos_drm_ipp_formats rotator_s5pv210_formats[] = {
+ { IPP_SRCDST_FORMAT(XRGB, rotator_s5pv210_rbg888_limits) },
+ { IPP_SRCDST_FORMAT(NV12, rotator_s5pv210_yuv_limits) },
+};
+
static const struct exynos_drm_ipp_formats rotator_4210_formats[] = {
{ IPP_SRCDST_FORMAT(XRGB, rotator_4210_rbg888_limits) },
{ IPP_SRCDST_FORMAT(NV12, rotator_4210_yuv_limits) },
@@ -396,6 +411,11 @@ static const struct exynos_drm_ipp_formats
rotator_5250_formats[] = {
{ IPP_SRCDST_FORMAT(NV12, rotator_4412_yuv_limits) },
};
+static const struct rot_variant rotator_s5pv210_data = {
+ .formats = rotator_s5pv210_formats,
+ .num_formats = ARRAY_SIZE(rotator_s5pv210_formats),
+};
+
static const struct rot_variant rotator_4210_data = {
.formats = rotator_4210_formats,
.num_formats = ARRAY_SIZE(rotator_4210_formats),
@@ -413,6 +433,9 @@ static const struct rot_variant rotator_5250_data = {
static const struct of_device_id exynos_rotator_match[] = {
{
+ .compatible = "samsung,s5pv210-rotator",
+ .data = &rotator_s5pv210_data,
+ }, {
.compatible = "samsung,exynos4210-rotator",
.data = &rotator_4210_data,
}, {
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 4/5] drm/bridge: lvds-encoder: add dev helper variable in .probe()
Make the code easier to read and modify.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/bridge/lvds-encoder.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/bridge/lvds-encoder.c
b/drivers/gpu/drm/bridge/lvds-encoder.c
index 75b0d3f6e4de..f6770e83d49d 100644
--- a/drivers/gpu/drm/bridge/lvds-encoder.c
+++ b/drivers/gpu/drm/bridge/lvds-encoder.c
@@ -34,48 +34,47 @@ static struct drm_bridge_funcs funcs = {
static int lvds_encoder_probe(struct platform_device *pdev)
{
+ struct device *dev = &pdev->dev;
struct device_node *port;
struct device_node *endpoint;
struct device_node *panel_node;
struct drm_panel *panel;
struct lvds_encoder *lvds_encoder;
- lvds_encoder = devm_kzalloc(&pdev->dev, sizeof(*lvds_encoder),
- GFP_KERNEL);
+ lvds_encoder = devm_kzalloc(dev, sizeof(*lvds_encoder), GFP_KERNEL);
if (!lvds_encoder)
return -ENOMEM;
/* Locate the panel DT node. */
- port = of_graph_get_port_by_id(pdev->dev.of_node, 1);
+ port = of_graph_get_port_by_id(dev->of_node, 1);
if (!port) {
- dev_dbg(&pdev->dev, "port 1 not found\n");
+ dev_dbg(dev, "port 1 not found\n");
return -ENXIO;
}
endpoint = of_get_child_by_name(port, "endpoint");
of_node_put(port);
if (!endpoint) {
- dev_dbg(&pdev->dev, "no endpoint for port 1\n");
+ dev_dbg(dev, "no endpoint for port 1\n");
return -ENXIO;
}
panel_node = of_graph_get_remote_port_parent(endpoint);
of_node_put(endpoint);
if (!panel_node) {
- dev_dbg(&pdev->dev, "no remote endpoint for port 1\n");
+ dev_dbg(dev, "no remote endpoint for port 1\n");
return -ENXIO;
}
panel = of_drm_find_panel(panel_node);
of_node_put(panel_node);
if (!panel) {
- dev_dbg(&pdev->dev, "panel not found, deferring probe\n");
+ dev_dbg(dev, "panel not found, deferring probe\n");
return -EPROBE_DEFER;
}
lvds_encoder->panel_bridge =
- devm_drm_panel_bridge_add(&pdev->dev,
- panel, DRM_MODE_CONNECTOR_LVDS);
+ devm_drm_panel_bridge_add(dev, panel, DRM_MODE_CONNECTOR_LVDS);
if (IS_ERR(lvds_encoder->panel_bridge))
return PTR_ERR(lvds_encoder->panel_bridge);
@@ -83,7 +82,7 @@ static int lvds_encoder_probe(struct platform_device *pdev)
* but we need a bridge attached to our of_node for our user
* to look up.
*/
- lvds_encoder->bridge.of_node = pdev->dev.of_node;
+ lvds_encoder->bridge.of_node = dev->of_node;
lvds_encoder->bridge.funcs = &funcs;
drm_bridge_add(&lvds_encoder->bridge);
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 5/5] drm/bridge: lvds-encoder: add powerdown-gpios support
Optionally power down the LVDS-encoder when it is not in use.
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/bridge/lvds-encoder.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/bridge/lvds-encoder.c
b/drivers/gpu/drm/bridge/lvds-encoder.c
index f6770e83d49d..36d8557bc097 100644
--- a/drivers/gpu/drm/bridge/lvds-encoder.c
+++ b/drivers/gpu/drm/bridge/lvds-encoder.c
@@ -11,11 +11,13 @@
#include
#include
+#include
#include
struct lvds_encoder {
struct drm_bridge bridge;
struct drm_bridge *panel_bridge;
+ struct gpio_desc *powerdown_gpio;
};
static int lvds_encoder_attach(struct drm_bridge *bridge)
@@ -28,8 +30,30 @@ static int lvds_encoder_attach(struct drm_bridge *bridge)
bridge);
}
+static void lvds_encoder_enable(struct drm_bridge *bridge)
+{
+ struct lvds_encoder *lvds_encoder = container_of(bridge,
+struct lvds_encoder,
+bridge);
+
+ if (lvds_encoder->powerdown_gpio)
+ gpiod_set_value_cansleep(lvds_encoder->powerdown_gpio, 0);
+}
+
+static void lvds_encoder_disable(struct drm_bridge *bridge)
+{
+ struct lvds_encoder *lvds_encoder = container_of(bridge,
+struct lvds_encoder,
+bridge);
+
+ if (lvds_encoder->powerdown_gpio)
+ gpiod_set_value_cansleep(lvds_encoder->powerdown_gpio, 1);
+}
+
static struct drm_bridge_funcs funcs = {
.attach = lvds_encoder_attach,
+ .enable = lvds_encoder_enable,
+ .disable = lvds_encoder_disable,
};
static int lvds_encoder_probe(struct platform_device *pdev)
@@ -45,6 +69,16 @@ static int lvds_encoder_probe(struct platform_device *pdev)
if (!lvds_encoder)
return -ENOMEM;
+ lvds_encoder->powerdown_gpio = devm_gpiod_get_optional(dev, "powerdown",
+ GPIOD_OUT_HIGH);
+ if (IS_ERR(lvds_encoder->powerdown_gpio)) {
+ int err = PTR_ERR(lvds_encoder->powerdown_gpio);
+
+ if (err != -EPROBE_DEFER)
+ dev_err(dev, "powerdown GPIO failure: %d\n", err);
+ return err;
+ }
+
/* Locate the panel DT node. */
port = of_graph_get_port_by_id(dev->of_node, 1);
if (!port) {
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/14] drm: minimize drmP.h dependencies
On 12/30/18 11:08 AM, Sam Ravnborg wrote: > On Sun, Dec 30, 2018 at 06:48:24PM +0100, Sam Ravnborg wrote: >> The goal with this small series > > The series should have been a reply to this cover letter, > but my tooling lost me - sorry! > > Sam > Hi Sam, And the $subjects that say "reply" should say "rely" I think. cheers, -- ~Randy ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 20/25] powerpc, fbdev: Use arch_nvram_ops methods instead of nvram_read_byte() and nvram_write_byte()
On Sat, 29 Dec 2018, LEROY Christophe wrote:
> Finn Thain a ?crit?:
>
> > Make use of arch_nvram_ops in device drivers so that the nvram_* function
> > exports can be removed.
> >
> > Since they are no longer global symbols, rename the PPC32 nvram_* functions
> > appropriately.
> >
> > Signed-off-by: Finn Thain
> > ---
> > arch/powerpc/kernel/setup_32.c | 8
> > drivers/char/generic_nvram.c | 4 ++--
> > drivers/video/fbdev/controlfb.c| 4 ++--
> > drivers/video/fbdev/imsttfb.c | 4 ++--
> > drivers/video/fbdev/matrox/matroxfb_base.c | 2 +-
> > drivers/video/fbdev/platinumfb.c | 4 ++--
> > drivers/video/fbdev/valkyriefb.c | 4 ++--
> > 7 files changed, 15 insertions(+), 15 deletions(-)
> >
> > diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
> > index e0d045677472..bdbe6acbef11 100644
> > --- a/arch/powerpc/kernel/setup_32.c
> > +++ b/arch/powerpc/kernel/setup_32.c
> > @@ -152,20 +152,18 @@ __setup("l3cr=", ppc_setup_l3cr);
> >
> > #ifdef CONFIG_GENERIC_NVRAM
> >
> > -unsigned char nvram_read_byte(int addr)
> > +static unsigned char ppc_nvram_read_byte(int addr)
> > {
> > if (ppc_md.nvram_read_val)
> > return ppc_md.nvram_read_val(addr);
> > return 0xff;
> > }
> > -EXPORT_SYMBOL(nvram_read_byte);
> >
> > -void nvram_write_byte(unsigned char val, int addr)
> > +static void ppc_nvram_write_byte(unsigned char val, int addr)
> > {
> > if (ppc_md.nvram_write_val)
> > ppc_md.nvram_write_val(addr, val);
> > }
> > -EXPORT_SYMBOL(nvram_write_byte);
> >
> > static ssize_t ppc_nvram_get_size(void)
> > {
> > @@ -182,6 +180,8 @@ static long ppc_nvram_sync(void)
> > }
> >
> > const struct nvram_ops arch_nvram_ops = {
> > + .read_byte = ppc_nvram_read_byte,
> > + .write_byte = ppc_nvram_write_byte,
> > .get_size = ppc_nvram_get_size,
> > .sync = ppc_nvram_sync,
> > };
> > diff --git a/drivers/char/generic_nvram.c b/drivers/char/generic_nvram.c
> > index f32d5663de95..41b76bf9614e 100644
> > --- a/drivers/char/generic_nvram.c
> > +++ b/drivers/char/generic_nvram.c
> > @@ -48,7 +48,7 @@ static ssize_t read_nvram(struct file *file, char __user
> > *buf,
> > if (*ppos >= nvram_len)
> > return 0;
> > for (i = *ppos; count > 0 && i < nvram_len; ++i, ++p, --count)
> > - if (__put_user(nvram_read_byte(i), p))
> > + if (__put_user(arch_nvram_ops.read_byte(i), p))
>
> Instead of modifying all drivers (in this patch and previous ones related to
> other arches), wouldn't it be better to add helpers like the following in
> nvram.h:
>
> Static inline unsigned char nvram_read_byte(int addr)
> {
>return arch_nvram_ops.read_byte(addr);
> }
>
Is there some benefit, or is that just personal taste?
Avoiding changes to call sites avoids code review, but I think 1) the
thinkpad_acpi changes have already been reviewed and 2) the fbdev changes
need review anyway.
Your suggesion would add several new entities and one extra layer of
indirection.
I think indirection harms readability because now the reader now has to go
and look up the meaning of the new entities.
It's not the case that we need to choose between definitions of
nvram_read_byte() at compile time, or stub them out:
#ifdef CONFIG_FOO
static inline unsigned char nvram_read_byte(int addr)
{
return arch_nvram_ops.read_byte(addr);
}
#else
static inline unsigned char nvram_read_byte(int addr) { }
#endif
And I don't anticipate a need for a macro here either:
#define nvram_read_byte(a) random_nvram_read_byte_impl(a)
I think I've used the simplest solution.
--
> Christophe
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/7] ARM: dts: rockchip: rk3066: add HCLK_HDMI to pmu node
A MK808 TV stick with rk3066 processor boots normal with logo and console, but after booting the monitor remains black. This patch fixes a vblank wait time out by adding HCLK_HDMI to the pmu node. The HCLK_HDMI clock is now part of the logic that enables the RK3066_PD_VIO power domain. Signed-off-by: Johan Jonker --- arch/arm/boot/dts/rk3066a.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/rk3066a.dtsi b/arch/arm/boot/dts/rk3066a.dtsi index 30dc8af0b..b6b3a77da 100644 --- a/arch/arm/boot/dts/rk3066a.dtsi +++ b/arch/arm/boot/dts/rk3066a.dtsi @@ -669,6 +669,7 @@ <&cru SCLK_CIF0>, <&cru ACLK_CIF0>, <&cru HCLK_CIF0>, +<&cru HCLK_HDMI>, <&cru ACLK_IPP>, <&cru HCLK_IPP>, <&cru ACLK_RGA>, -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] qcom-scm: Include header
On Fri 28 Dec 07:39 PST 2018, Jonathan marek wrote:
> FYI, I already had a patch fixing this error (it is in linux-next:
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/log/include/linux/qcom_scm.h).
> This one is probably better though.
>
I thought I had seen this before, but I was unable to find your patch
when searching my inbox.
That patch has been sent to and picked up by arm-soc for v4.21, so we're
good.
Thanks,
Bjorn
> On 12/28/2018 02:31 PM, Bjorn Andersson wrote:
> > On Wed 26 Dec 04:06 PST 2018, Fabio Estevam wrote:
> >
> > > Since commit e6f6d63ed14c ("drm/msm: add headless gpu device for imx5")
> > > the DRM_MSM symbol can be selected by SOC_IMX5 causing the following
> > > error when building imx_v6_v7_defconfig:
> > >
> > > In file included from ../drivers/gpu/drm/msm/adreno/a5xx_gpu.c:17:0:
> > > ../include/linux/qcom_scm.h: In function 'qcom_scm_set_cold_boot_addr':
> > > ../include/linux/qcom_scm.h:73:10: error: 'ENODEV' undeclared (first use
> > > in this function)
> > >return -ENODEV;
> > >
> > > Include the header file to fix this problem.
> > >
> >
> > Reviewed-by: Bjorn Andersson
> >
> > Andy, please pick up for inclusion in -rc
> >
> > Fabio, please use get_maintainers, so your patches hits the appropriate
> > mailing lists (linux-arm-msm@ in this case)
> >
> > Regards,
> > Bjorn
> >
> > > Reported-by: kernelci.org bot
> > > Fixes: e6f6d63ed14c ("drm/msm: add headless gpu device for imx5")
> > > Signed-off-by: Fabio Estevam
> > > ---
> > > include/linux/qcom_scm.h | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/include/linux/qcom_scm.h b/include/linux/qcom_scm.h
> > > index 06996ad4f2bc..ce5a476fd733 100644
> > > --- a/include/linux/qcom_scm.h
> > > +++ b/include/linux/qcom_scm.h
> > > @@ -13,6 +13,7 @@
> > > #ifndef __QCOM_SCM_H
> > > #define __QCOM_SCM_H
> > > +#include
> > > #include
> > > #include
> > > --
> > > 2.17.1
> > >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] qcom-scm: Include header
On Sat, Dec 29, 2018 at 10:19:32AM -0200, Fabio Estevam wrote: > Hi Bjorn, > > On Fri, Dec 28, 2018 at 10:27 PM Bjorn Andersson > wrote: > > > Sorry about that, I forgot that the header file is not covered by the > > MAINTAINERS file. > > > > Your second patch looks good, but I'm hoping we can merge the upcoming > > v3 of Amit's patch right after the merge window. It fixes this and a lot > > of other pieces where we would like to include linux-arm-msm@: > > > > https://lore.kernel.org/lkml/d153a86748f99526e7790bfc4ef8781a2016fd51.1545126964.git.amit.kuche...@linaro.org/ > > Amit's patch adds the following entry: > > +F: include/linux/*/qcom* > > but it does not catch include/linux/qcom_scm.h > > It also needs > > +F: include/linux/qcom* > > in order to catch include/linux/qcom-geni-se.h and include/linux/qcom_scm.h > > I can add that entry after Amit's patch gets applied. Or I can add it to Amit's. I'll ping him to make sure that's ok. Thanks, Andy ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/3] dt-bindings: gpu: samsung-rotator: Document s5pv210 support
This commit documents new compatible for s5pv210 soc, which will be also supported by this driver. Signed-off-by: Paweł Chmiel --- Changes from v1: - Removed list enumeration - Placed s5pv210 at beginning of list (it's the oldest chipset) --- Documentation/devicetree/bindings/gpu/samsung-rotator.txt | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/gpu/samsung-rotator.txt b/Documentation/devicetree/bindings/gpu/samsung-rotator.txt index 82cd1ed0be93..3aca2578da0b 100644 --- a/Documentation/devicetree/bindings/gpu/samsung-rotator.txt +++ b/Documentation/devicetree/bindings/gpu/samsung-rotator.txt @@ -2,9 +2,10 @@ Required properties: - compatible : value should be one of the following: - (a) "samsung,exynos4210-rotator" for Rotator IP in Exynos4210 - (b) "samsung,exynos4212-rotator" for Rotator IP in Exynos4212/4412 - (c) "samsung,exynos5250-rotator" for Rotator IP in Exynos5250 + * "samsung,s5pv210-rotator" for Rotator IP in S5PV210 + * "samsung,exynos4210-rotator" for Rotator IP in Exynos4210 + * "samsung,exynos4212-rotator" for Rotator IP in Exynos4212/4412 + * "samsung,exynos5250-rotator" for Rotator IP in Exynos5250 - reg : Physical base address of the IP registers and length of memory mapped region. -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
INFO: trying to register non-static key in __flush_work
Hello, syzbot found the following crash on: HEAD commit:5694cecdb092 Merge tag 'arm64-upstream' of git://git.kerne.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=124eebc740 kernel config: https://syzkaller.appspot.com/x/.config?x=91a256823ef17263 dashboard link: https://syzkaller.appspot.com/bug?extid=12f1b031b6da017e34f8 compiler: gcc (GCC) 8.0.1 20180413 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1174a1dd40 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1336e38b40 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+12f1b031b6da017e3...@syzkaller.appspotmail.com INFO: trying to register non-static key. the code is fine but needs lockdep annotation. turning off the locking correctness validator. CPU: 0 PID: 8039 Comm: syz-executor964 Not tainted 4.20.0+ #389 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1d3/0x2c6 lib/dump_stack.c:113 assign_lock_key kernel/locking/lockdep.c:727 [inline] register_lock_class+0x21c5/0x29d0 kernel/locking/lockdep.c:753 __lock_acquire+0x184/0x4c20 kernel/locking/lockdep.c:3227 lock_acquire+0x1ed/0x520 kernel/locking/lockdep.c:3844 __flush_work+0x752/0x9b0 kernel/workqueue.c:2912 flush_work+0x17/0x20 kernel/workqueue.c:2938 vkms_atomic_crtc_destroy_state+0x2b/0x40 drivers/gpu/drm/vkms/vkms_crtc.c:139 drm_atomic_state_default_clear+0x37c/0xda0 drivers/gpu/drm/drm_atomic.c:171 drm_atomic_state_clear+0x9f/0xd0 drivers/gpu/drm/drm_atomic.c:240 __drm_atomic_state_free+0x3a/0xf0 drivers/gpu/drm/drm_atomic.c:256 kref_put include/linux/kref.h:70 [inline] drm_atomic_state_put include/drm/drm_atomic.h:385 [inline] drm_atomic_helper_set_config+0xe6/0x160 drivers/gpu/drm/drm_atomic_helper.c:2947 drm_mode_setcrtc+0x767/0x1890 drivers/gpu/drm/drm_crtc.c:748 drm_ioctl_kernel+0x278/0x330 drivers/gpu/drm/drm_ioctl.c:758 drm_ioctl+0x58f/0xb90 drivers/gpu/drm/drm_ioctl.c:858 vfs_ioctl fs/ioctl.c:46 [inline] file_ioctl fs/ioctl.c:509 [inline] do_vfs_ioctl+0x1de/0x1790 fs/ioctl.c:696 ksys_ioctl+0xa9/0xd0 fs/ioctl.c:713 __do_sys_ioctl fs/ioctl.c:720 [inline] __se_sys_ioctl fs/ioctl.c:718 [inline] __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:718 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x443e59 Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 7b d8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7fff2bc037c8 EFLAGS: 0213 ORIG_RAX: 0010 RAX: ffda RBX: 004002e0 RCX: 00443e59 RDX: 2100 RSI: c06864a2 RDI: 0003 RBP: 006ce018 R08: R09: 004002e0 R10: 000f R11: 0213 R12: 00401b60 R13: 00401bf0 R14: R15: 0 --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with syzbot. syzbot can test patches for this bug, for details see: https://goo.gl/tpsmEJ#testing-patches ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING: lock held when returning to user space in set_property_atomic
Hello,
syzbot found the following crash on:
HEAD commit:903b77c63167 Merge tag 'linux-kselftest-4.21-rc1' of git:/..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=12d0f55340
kernel config: https://syzkaller.appspot.com/x/.config?x=53a2f2aa0b1f7606
dashboard link: https://syzkaller.appspot.com/bug?extid=6ea337c427f5083ebdf2
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=120d906f40
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1024673b40
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+6ea337c427f5083eb...@syzkaller.appspotmail.com
RBP: 7ffe369ca7a0 R08: 0001 R09: 004009ce
R10: R11: 0246 R12: 0005
R13: R14: R15:
WARNING: lock held when returning to user space!
4.20.0+ #174 Not tainted
syz-executor556/8153 is leaving the kernel with locks still held!
1 lock held by syz-executor556/8153:
#0: 5100c85c (crtc_ww_class_acquire){+.+.}, at:
set_property_atomic+0xb3/0x330 drivers/gpu/drm/drm_mode_object.c:462
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/7] clk: rockchip: rk3188: add CLK_SET_RATE_PARENT for lcdc dclk
From: Finley Xiao
Add CLK_SET_RATE_PARENT for lcdc dclk.
Signed-off-by: Finley Xiao
Signed-off-by: Johan Jonker
---
drivers/clk/rockchip/clk-rk3188.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/rockchip/clk-rk3188.c
b/drivers/clk/rockchip/clk-rk3188.c
index 7ea20341e..5ecf28854 100644
--- a/drivers/clk/rockchip/clk-rk3188.c
+++ b/drivers/clk/rockchip/clk-rk3188.c
@@ -586,12 +586,12 @@ static struct rockchip_clk_branch rk3066a_clk_branches[]
__initdata = {
COMPOSITE(0, "dclk_lcdc0_src", mux_pll_src_cpll_gpll_p, 0,
RK2928_CLKSEL_CON(27), 0, 1, MFLAGS, 8, 8, DFLAGS,
RK2928_CLKGATE_CON(3), 1, GFLAGS),
- MUX(DCLK_LCDC0, "dclk_lcdc0", mux_rk3066_lcdc0_p, 0,
+ MUX(DCLK_LCDC0, "dclk_lcdc0", mux_rk3066_lcdc0_p, CLK_SET_RATE_PARENT,
RK2928_CLKSEL_CON(27), 4, 1, MFLAGS),
COMPOSITE(0, "dclk_lcdc1_src", mux_pll_src_cpll_gpll_p, 0,
RK2928_CLKSEL_CON(28), 0, 1, MFLAGS, 8, 8, DFLAGS,
RK2928_CLKGATE_CON(3), 2, GFLAGS),
- MUX(DCLK_LCDC1, "dclk_lcdc1", mux_rk3066_lcdc1_p, 0,
+ MUX(DCLK_LCDC1, "dclk_lcdc1", mux_rk3066_lcdc1_p, CLK_SET_RATE_PARENT,
RK2928_CLKSEL_CON(28), 4, 1, MFLAGS),
COMPOSITE_NOMUX(0, "cif1_pre", "cif_src", 0,
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 7/7] ARM: dts: rockchip: rk3066a-mk808: enable vop0 and hdmi nodes
This patch enables the vop0 and hdmi nodes
for a MK808 with rk3066 processor.
Signed-off-by: Johan Jonker
---
arch/arm/boot/dts/rk3066a-mk808.dts | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/rk3066a-mk808.dts
b/arch/arm/boot/dts/rk3066a-mk808.dts
index b6a8a82d2..14a560598 100644
--- a/arch/arm/boot/dts/rk3066a-mk808.dts
+++ b/arch/arm/boot/dts/rk3066a-mk808.dts
@@ -91,6 +91,14 @@
};
};
+&hdmi {
+ status = "okay";
+};
+
+&hdmi_in_vop1 {
+ status = "disabled";
+};
+
&mmc0 {
bus-width = <4>;
cap-mmc-highspeed;
@@ -151,6 +159,10 @@
status = "okay";
};
+&vop0 {
+ status = "okay";
+};
+
&wdt {
status = "okay";
};
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH -next] drm: Fix error handling in drm_legacy_addctx
'ctx->handle' is unsigned, it never less than zero.
This patch use int 'tmp_handle' to handle the err condition.
Fixes: 62968144e673 ("drm: convert drm context code to use Linux idr")
Signed-off-by: YueHaibing
---
drivers/gpu/drm/drm_context.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_context.c b/drivers/gpu/drm/drm_context.c
index 506663c..8e73fab 100644
--- a/drivers/gpu/drm/drm_context.c
+++ b/drivers/gpu/drm/drm_context.c
@@ -361,23 +361,26 @@ int drm_legacy_addctx(struct drm_device *dev, void *data,
{
struct drm_ctx_list *ctx_entry;
struct drm_ctx *ctx = data;
+ int tmp_handle;
if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT) &&
!drm_core_check_feature(dev, DRIVER_LEGACY))
return -EOPNOTSUPP;
- ctx->handle = drm_legacy_ctxbitmap_next(dev);
- if (ctx->handle == DRM_KERNEL_CONTEXT) {
+ tmp_handle = drm_legacy_ctxbitmap_next(dev);
+ if (tmp_handle == DRM_KERNEL_CONTEXT) {
/* Skip kernel's context and get a new one. */
- ctx->handle = drm_legacy_ctxbitmap_next(dev);
+ tmp_handle = drm_legacy_ctxbitmap_next(dev);
}
- DRM_DEBUG("%d\n", ctx->handle);
- if (ctx->handle < 0) {
+ DRM_DEBUG("%d\n", tmp_handle);
+ if (tmp_handle < 0) {
DRM_DEBUG("Not enough free contexts.\n");
/* Should this return -EBUSY instead? */
- return -ENOMEM;
+ return tmp_handle;
}
+ ctx->handle = tmp_handle;
+
ctx_entry = kmalloc(sizeof(*ctx_entry), GFP_KERNEL);
if (!ctx_entry) {
DRM_DEBUG("out of memory\n");
--
2.7.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/3] ARM: dts: s5pv210: Add node for exynos-rotator
This commit adds node for Exynos Rorator device,
so it can be used on all s5pv210 based devices.
Signed-off-by: Paweł Chmiel
---
arch/arm/boot/dts/s5pv210.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/s5pv210.dtsi b/arch/arm/boot/dts/s5pv210.dtsi
index 75f454a210d6..a5463003c7f6 100644
--- a/arch/arm/boot/dts/s5pv210.dtsi
+++ b/arch/arm/boot/dts/s5pv210.dtsi
@@ -542,6 +542,15 @@
#dma-requests = <1>;
};
+ rotator: rotator@fa30 {
+ compatible = "samsung,s5pv210-rotator";
+ reg = <0xfa30 0x1000>;
+ interrupt-parent = <&vic2>;
+ interrupts = <4>;
+ clocks = <&clocks CLK_ROTATOR>;
+ clock-names = "rotator";
+ };
+
i2c1: i2c@fab0 {
compatible = "samsung,s3c2440-i2c";
reg = <0xfab0 0x1000>;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] qcom-scm: Include header
On Fri 28 Dec 11:52 PST 2018, Fabio Estevam wrote: > Hi Bjorn, > > On Fri, Dec 28, 2018 at 5:31 PM Bjorn Andersson > wrote: [..] > > Fabio, please use get_maintainers, so your patches hits the appropriate > > mailing lists (linux-arm-msm@ in this case) [..] > By the way, I just ran get_maintainers in this patch and linux-arm-msm > is not listed. > Sorry about that, I forgot that the header file is not covered by the MAINTAINERS file. Your second patch looks good, but I'm hoping we can merge the upcoming v3 of Amit's patch right after the merge window. It fixes this and a lot of other pieces where we would like to include linux-arm-msm@: https://lore.kernel.org/lkml/d153a86748f99526e7790bfc4ef8781a2016fd51.1545126964.git.amit.kuche...@linaro.org/ Regards, Bjorn ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/3] drm/exynos: rotator: Add support for s5pv210
This patchset adds support for s5pv210 soc, into Samsung DRM Rotator driver. Currently only NV12 and XRGB formats are supported. It was tested by using simple tool from https://www.spinics.net/lists/linux-samsung-soc/msg60498.html Changes from v1: - fixed order of chipsets in documentation and removed ordering from it Paweł Chmiel (3): drm/exynos: rotator: Add support for s5pv210 dt-bindings: gpu: samsung-rotator: Document s5pv210 support ARM: dts: s5pv210: Add node for exynos-rotator .../bindings/gpu/samsung-rotator.txt | 7 +++--- arch/arm/boot/dts/s5pv210.dtsi| 9 drivers/gpu/drm/exynos/exynos_drm_rotator.c | 23 +++ 3 files changed, 36 insertions(+), 3 deletions(-) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/5] dt-bindings: display: bridge: lvds-transmitter: cleanup example
Drop #address-cells and #size-cells from the root node in the
example, they are unused.
Reviewed-by: Rob Herring
Signed-off-by: Peter Rosin
---
Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt | 2 --
1 file changed, 2 deletions(-)
diff --git
a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
index fd39ad34c383..36ce07c8d8e6 100644
--- a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
+++ b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
@@ -38,8 +38,6 @@ Example
lvds-encoder {
compatible = "lvds-encoder";
- #address-cells = <1>;
- #size-cells = <0>;
ports {
#address-cells = <1>;
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/5] dt-bindings: display: bridge: fork out ti,ds90c185 from lvds-transmitter
DS90C185 has a shutdown pin which does not fit in the lvds-transmitter
binding, which is meant to be generic.
The sister chip DS90C187 is similar to DS90C185, describe it here as well.
Signed-off-by: Peter Rosin
---
.../bindings/display/bridge/lvds-transmitter.txt | 8 +---
.../bindings/display/bridge/ti,ds90c185.txt| 55 ++
2 files changed, 56 insertions(+), 7 deletions(-)
create mode 100644
Documentation/devicetree/bindings/display/bridge/ti,ds90c185.txt
diff --git
a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
index 50220190c203..fd39ad34c383 100644
--- a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
+++ b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
@@ -22,13 +22,7 @@ among others.
Required properties:
-- compatible: Must be one or more of the following
- - "ti,ds90c185" for the TI DS90C185 FPD-Link Serializer
- - "lvds-encoder" for a generic LVDS encoder device
-
- When compatible with the generic version, nodes must list the
- device-specific version corresponding to the device first
- followed by the generic version.
+- compatible: Must be "lvds-encoder"
Required nodes:
diff --git a/Documentation/devicetree/bindings/display/bridge/ti,ds90c185.txt
b/Documentation/devicetree/bindings/display/bridge/ti,ds90c185.txt
new file mode 100644
index ..e575f996959a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ti,ds90c185.txt
@@ -0,0 +1,55 @@
+Texas Instruments FPD-Link (LVDS) Serializer
+
+
+The DS90C185 and DS90C187 are low-power serializers for portable
+battery-powered applications that reduces the size of the RGB
+interface between the host GPU and the display.
+
+Required properties:
+
+- compatible: Should be
+ "ti,ds90c185", "lvds-encoder" for the TI DS90C185 FPD-Link Serializer
+ "ti,ds90c187", "lvds-encoder" for the TI DS90C187 FPD-Link Serializer
+
+Optional properties:
+
+- powerdown-gpios: Power down control GPIO (the PDB pin, active-low)
+
+Required nodes:
+
+The devices have two video ports. Their connections are modeled using the OF
+graph bindings specified in Documentation/devicetree/bindings/graph.txt.
+
+- Video port 0 for parallel input
+- Video port 1 for LVDS output
+
+
+Example
+---
+
+lvds-encoder {
+ compatible = "ti,ds90c185", "lvds-encoder";
+
+ powerdown-gpios = <&gpio 17 GPIO_ACTIVE_LOW>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ lvds_enc_in: endpoint {
+ remote-endpoint = <&lcdc_out_rgb>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ lvds_enc_out: endpoint {
+ remote-endpoint = <&lvds_panel_in>;
+ };
+ };
+ };
+};
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/7] drm: rockchip: introduce rk3066 hdmi
From: Zheng Yang
Introduce rk3066 hdmi.
Signed-off-by: Zheng Yang
Signed-off-by: Johan Jonker
---
drivers/gpu/drm/rockchip/Kconfig| 8 +
drivers/gpu/drm/rockchip/Makefile | 1 +
drivers/gpu/drm/rockchip/rk3066_hdmi.c | 928
drivers/gpu/drm/rockchip/rk3066_hdmi.h | 235 +++
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 +
drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 1 +
6 files changed, 1175 insertions(+)
create mode 100644 drivers/gpu/drm/rockchip/rk3066_hdmi.c
create mode 100644 drivers/gpu/drm/rockchip/rk3066_hdmi.h
diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 26438d457..db284b6c9 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -77,4 +77,12 @@ config ROCKCHIP_RGB
Some Rockchip CRTCs, like rv1108, can directly output parallel
and serial RGB format to panel or connect to a conversion chip.
say Y to enable its driver.
+
+config ROCKCHIP_RK3066_HDMI
+ bool "Rockchip specific extensions for RK3066 HDMI"
+ depends on DRM_ROCKCHIP
+ help
+ This selects support for Rockchip SoC specific extensions
+ for the RK3066 HDMI driver. If you want to enable
+ HDMI on RK3066 based SoC, you should select this option.
endif
diff --git a/drivers/gpu/drm/rockchip/Makefile
b/drivers/gpu/drm/rockchip/Makefile
index 868263ff0..41b3baee4 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -15,5 +15,6 @@ rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
rockchipdrm-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
rockchipdrm-$(CONFIG_ROCKCHIP_LVDS) += rockchip_lvds.o
rockchipdrm-$(CONFIG_ROCKCHIP_RGB) += rockchip_rgb.o
+rockchipdrm-$(CONFIG_ROCKCHIP_RK3066_HDMI) += rk3066_hdmi.o
obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o
diff --git a/drivers/gpu/drm/rockchip/rk3066_hdmi.c
b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
new file mode 100644
index 0..6e1843b64
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
@@ -0,0 +1,928 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
+ *Zheng Yang
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include "rockchip_drm_drv.h"
+#include "rockchip_drm_vop.h"
+
+#include "rk3066_hdmi.h"
+
+#define DEFAULT_PLLA_RATE 3000
+
+struct hdmi_data_info {
+ int vic;
+ bool sink_is_hdmi;
+ unsigned int enc_in_format;
+ unsigned int enc_out_format;
+ unsigned int colorimetry;
+};
+
+struct rk3066_hdmi_i2c {
+ struct i2c_adapter adap;
+
+ u8 ddc_addr;
+ u8 segment_addr;
+ u8 stat;
+
+ struct mutex lock; /*for i2c operation*/
+ struct completion cmp;
+};
+
+struct rk3066_hdmi {
+ struct device *dev;
+ struct drm_device *drm_dev;
+ struct regmap *regmap;
+ int irq;
+ struct clk *hclk;
+ void __iomem *regs;
+
+ struct drm_connectorconnector;
+ struct drm_encoder encoder;
+
+ struct rk3066_hdmi_i2c *i2c;
+ struct i2c_adapter *ddc;
+
+ unsigned int tmdsclk;
+
+ struct hdmi_data_info hdmi_data;
+ struct drm_display_mode previous_mode;
+};
+
+#define to_rk3066_hdmi(x) container_of(x, struct rk3066_hdmi, x)
+
+static inline u8 hdmi_readb(struct rk3066_hdmi *hdmi, u16 offset)
+{
+ return readl_relaxed(hdmi->regs + offset);
+}
+
+static inline void hdmi_writeb(struct rk3066_hdmi *hdmi, u16 offset, u32 val)
+{
+ writel_relaxed(val, hdmi->regs + offset);
+}
+
+static inline void hdmi_modb(struct rk3066_hdmi *hdmi, u16 offset,
+u32 msk, u32 val)
+{
+ u8 temp = hdmi_readb(hdmi, offset) & ~msk;
+
+ temp |= val & msk;
+ hdmi_writeb(hdmi, offset, temp);
+}
+
+static void rk3066_hdmi_i2c_init(struct rk3066_hdmi *hdmi)
+{
+ int ddc_bus_freq;
+
+ ddc_bus_freq = (hdmi->tmdsclk >> 2) / HDMI_SCL_RATE;
+
+ hdmi_writeb(hdmi, HDMI_DDC_BUS_FREQ_L, ddc_bus_freq & 0xFF);
+ hdmi_writeb(hdmi, HDMI_DDC_BUS_FREQ_H, (ddc_bus_freq >> 8) & 0xFF);
+
+ /* Clear the EDID interrupt flag and mute the interrupt */
+ hdmi_modb(hdmi, HDMI_INTR_MASK1, HDMI_INTR_EDID_MASK, 0);
+ hdmi_writeb(hdmi, HDMI_INTR_STATUS1, HDMI_INTR_EDID_MASK);
+}
+
+static inli
[PATCH v5 2/2] drm/amd: validate user GEM object size
When creating frame buffer, userspace may request to attach to a
previously allocated GEM object that is smaller than what GPU
requires. Validation must be done to prevent out-of-bound DMA,
otherwise it could be exploited to reveal sensitive data.
This fix is not done in a common code path because individual
driver might have different requirement.
Cc: sta...@vger.kernel.org # v4.2+
Signed-off-by: Yu Zhao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index 16af80ccd0a0..61c075a78ee1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -527,6 +527,7 @@ amdgpu_display_user_framebuffer_create(struct drm_device
*dev,
struct drm_gem_object *obj;
struct amdgpu_framebuffer *amdgpu_fb;
int ret;
+ int height;
struct amdgpu_device *adev = dev->dev_private;
int cpp = drm_format_plane_cpp(mode_cmd->pixel_format, 0);
int pitch = mode_cmd->pitches[0] / cpp;
@@ -557,6 +558,13 @@ amdgpu_display_user_framebuffer_create(struct drm_device
*dev,
return ERR_PTR(-EINVAL);
}
+ height = ALIGN(mode_cmd->height, 8);
+ if (obj->size < pitch * height) {
+ DRM_DEBUG_KMS("Invalid GEM size: expecting >= %d but got %zu\n",
+ pitch * height, obj->size);
+ return ERR_PTR(-EINVAL);
+ }
+
amdgpu_fb = kzalloc(sizeof(*amdgpu_fb), GFP_KERNEL);
if (amdgpu_fb == NULL) {
drm_gem_object_put_unlocked(obj);
--
2.20.1.415.g653613c723-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 1/2] drm/amd: validate user pitch alignment
Userspace may request pitch alignment that is not supported by GPU.
Some requests 32, but GPU ignores it and uses default 64 when cpp is
4. If GEM object is allocated based on the smaller alignment, GPU
DMA will go out of bound.
Cc: sta...@vger.kernel.org # v4.2+
Signed-off-by: Yu Zhao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index 15ce7e681d67..16af80ccd0a0 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -527,6 +527,22 @@ amdgpu_display_user_framebuffer_create(struct drm_device
*dev,
struct drm_gem_object *obj;
struct amdgpu_framebuffer *amdgpu_fb;
int ret;
+ struct amdgpu_device *adev = dev->dev_private;
+ int cpp = drm_format_plane_cpp(mode_cmd->pixel_format, 0);
+ int pitch = mode_cmd->pitches[0] / cpp;
+
+ if (pitch < mode_cmd->width) {
+ DRM_DEBUG_KMS("Expecting pitch(%d)/cpp(%d) >= width(%d)\n",
+ mode_cmd->pitches[0], cpp, mode_cmd->width);
+ return ERR_PTR(-EINVAL);
+ }
+
+ pitch = amdgpu_align_pitch(adev, pitch, cpp, false);
+ if (mode_cmd->pitches[0] != pitch) {
+ DRM_DEBUG_KMS("Invalid pitch: expecting %d but got %d\n",
+ pitch, mode_cmd->pitches[0]);
+ return ERR_PTR(-EINVAL);
+ }
obj = drm_gem_object_lookup(file_priv, mode_cmd->handles[0]);
if (obj == NULL) {
--
2.20.1.415.g653613c723-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] qcom-scm: Include header
FYI, I already had a patch fixing this error (it is in linux-next:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/log/include/linux/qcom_scm.h).
This one is probably better though.
On 12/28/2018 02:31 PM, Bjorn Andersson wrote:
On Wed 26 Dec 04:06 PST 2018, Fabio Estevam wrote:
Since commit e6f6d63ed14c ("drm/msm: add headless gpu device for imx5")
the DRM_MSM symbol can be selected by SOC_IMX5 causing the following
error when building imx_v6_v7_defconfig:
In file included from ../drivers/gpu/drm/msm/adreno/a5xx_gpu.c:17:0:
../include/linux/qcom_scm.h: In function 'qcom_scm_set_cold_boot_addr':
../include/linux/qcom_scm.h:73:10: error: 'ENODEV' undeclared (first use in
this function)
return -ENODEV;
Include the header file to fix this problem.
Reviewed-by: Bjorn Andersson
Andy, please pick up for inclusion in -rc
Fabio, please use get_maintainers, so your patches hits the appropriate
mailing lists (linux-arm-msm@ in this case)
Regards,
Bjorn
Reported-by: kernelci.org bot
Fixes: e6f6d63ed14c ("drm/msm: add headless gpu device for imx5")
Signed-off-by: Fabio Estevam
---
include/linux/qcom_scm.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/qcom_scm.h b/include/linux/qcom_scm.h
index 06996ad4f2bc..ce5a476fd733 100644
--- a/include/linux/qcom_scm.h
+++ b/include/linux/qcom_scm.h
@@ -13,6 +13,7 @@
#ifndef __QCOM_SCM_H
#define __QCOM_SCM_H
+#include
#include
#include
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/5] dt-bindings: display: bridge: thc63lvdm83d: use standard powerdown-gpios
The name powerdown-gpios is the standard property name for the functionality covered by the previous pwdn-gpios name. This rename should be safe to do since the linux driver supporting the binding (lvds-encoder.c) never implemented the property, and no dts file names it. At least not upstream. Signed-off-by: Peter Rosin --- Documentation/devicetree/bindings/display/bridge/thine,thc63lvdm83d.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvdm83d.txt b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvdm83d.txt index 527e236e9a2a..fee3c88e1a17 100644 --- a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvdm83d.txt +++ b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvdm83d.txt @@ -10,7 +10,7 @@ Required properties: Optional properties: -- pwdn-gpios: Power down control GPIO +- powerdown-gpios: Power down control GPIO (the /PWDN pin, active low). Required nodes: -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/7] Enable rk3066 VOP and HDMI for MK808
DISCLAIMER: Use at your own risk. For testing only! Version: V2 Title: Enable rk3066 VOP and HDMI for MK808. This patch serie only works in combination with a MK808 TV stick and a rk3066 processor. Other boxes and tablets with a rk3066 need extra software for power management and lcd's. What does it do: With these 7 kernel patches a MK808 can show 2 penquins and a console on a DVI-D monitor in combination with a framebuffer. Not tested: HDMI TV DRM Xorg Display managers Android etc. Problems: Fixed screen size for DVI-D. HDMI sound not included. etc. /// # How to make rkfs.cpio find . | cpio -o --format=newc > ../rkfs.cpio # How to compile/flash make menuconfig ARCH=arm CROSS_COMPILE=/usr/bin/arm-linux-gnueabi- make -j4 ARCH=arm CROSS_COMPILE=/usr/bin/arm-linux-gnueabi- cp ./arch/arm/boot/zImage ../zImage-dtb cat ./arch/arm/boot/dts/rk3066a-mk808.dtb >> ../zImage-dtb ../tools/rkcrc -k ../zImage-dtb ../mk808.img sudo ../tools/rkflashtool w 0x4000 0x8000 < ../mk808.img sudo ../tools/rkflashtool b /// Finley Xiao (1): clk: rockchip: rk3188: add CLK_SET_RATE_PARENT for lcdc dclk Johan Jonker (2): ARM: dts: rockchip: rk3066: add HCLK_HDMI to pmu node ARM: dts: rockchip: rk3066a-mk808: enable vop0 and hdmi nodes Mark Yao (2): drm: rockchip: vop: add rk3066 vop definitions ARM: dts: rockchip: add rk3066 vop display nodes Zheng Yang (2): drm: rockchip: introduce rk3066 hdmi ARM: dts: rockchip: add rk3066 hdmi nodes .../bindings/display/rockchip/rockchip-vop.txt | 1 + arch/arm/boot/dts/rk3066a-mk808.dts| 12 + arch/arm/boot/dts/rk3066a.dtsi | 92 ++ drivers/clk/rockchip/clk-rk3188.c | 4 +- drivers/gpu/drm/rockchip/Kconfig | 8 + drivers/gpu/drm/rockchip/Makefile | 1 + drivers/gpu/drm/rockchip/rk3066_hdmi.c | 928 + drivers/gpu/drm/rockchip/rk3066_hdmi.h | 235 ++ drivers/gpu/drm/rockchip/rockchip_drm_drv.c| 2 + drivers/gpu/drm/rockchip/rockchip_drm_drv.h| 1 + drivers/gpu/drm/rockchip/rockchip_vop_reg.c| 110 +++ drivers/gpu/drm/rockchip/rockchip_vop_reg.h| 53 ++ 12 files changed, 1445 insertions(+), 2 deletions(-) create mode 100644 drivers/gpu/drm/rockchip/rk3066_hdmi.c create mode 100644 drivers/gpu/drm/rockchip/rk3066_hdmi.h -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 20/25] powerpc, fbdev: Use arch_nvram_ops methods instead of nvram_read_byte() and nvram_write_byte()
On Mon, 31 Dec 2018, Arnd Bergmann wrote:
> On Sun, Dec 30, 2018 at 12:43 AM Finn Thain
> wrote:
>
> >
> > Is there some benefit, or is that just personal taste?
> >
> > Avoiding changes to call sites avoids code review, but I think 1) the
> > thinkpad_acpi changes have already been reviewed and 2) the fbdev changes
> > need review anyway.
> >
> > Your suggesion would add several new entities and one extra layer of
> > indirection.
> >
> > I think indirection harms readability because now the reader now has to go
> > and look up the meaning of the new entities.
> >
> > It's not the case that we need to choose between definitions of
> > nvram_read_byte() at compile time, or stub them out:
> >
> > #ifdef CONFIG_FOO
> > static inline unsigned char nvram_read_byte(int addr)
> > {
> > return arch_nvram_ops.read_byte(addr);
> > }
> > #else
> > static inline unsigned char nvram_read_byte(int addr) { }
> > #endif
> >
> > And I don't anticipate a need for a macro here either:
> >
> > #define nvram_read_byte(a) random_nvram_read_byte_impl(a)
> >
> > I think I've used the simplest solution.
>
> Having the indirection would help if the inline function can
> encapsulate the NULL pointer check, like
>
> static inline unsigned char nvram_read_byte(loff_t addr)
> {
>char data;
>
>if (!IS_ENABLED(CONFIG_NVRAM))
> return 0xff;
>
>if (arch_nvram_ops.read_byte)
> return arch_nvram_ops.read_byte(addr);
>
>if (arch_nvram_ops.read)
> return arch_nvram_ops.read(char, 1, &addr);
>
> return 0xff;
> }
>
The semantics of .read_byte and .read are subtly different. For CONFIG_X86
and CONFIG_ATARI, .read implies checksum validation and .read_byte does
not.
In particular, in the thinkpad_acpi case, checksum validation isn't used,
but in the atari_scsi case, it is.
So I like to see drivers explicitly call the method they want. I didn't
want to obscure this distinction in a helper.
--
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/nouveau: fix incorrect FB_BACKLIGHT usage in Kconfig
On 12/28/18 7:15 AM, Bartlomiej Zolnierkiewicz wrote:
> Making FB_BACKLIGHT tristate by commit b4a1ed0cd18b ("fbdev:
> make FB_BACKLIGHT a tristate") caused unmet dependencies in
> some configurations:
>
> WARNING: unmet direct dependencies detected for FB_BACKLIGHT
> Depends on [m]: HAS_IOMEM [=y] && FB [=m]
> Selected by [y]:
> - DRM_NOUVEAU [=y] && HAS_IOMEM [=y] && DRM [=y] && PCI [=y] && MMU [=y] &&
> DRM_NOUVEAU_BACKLIGHT [=y]
> Selected by [m]:
> - FB_NVIDIA [=m] && HAS_IOMEM [=y] && FB [=m] && PCI [=y] &&
> FB_NVIDIA_BACKLIGHT [=y]
>
> Fix it by making DRM_NOUVEAU select BACKLIGHT_CLASS_DEVICE and
> BACKLIGHT_LCD_SUPPORT instead of FB_BACKLIGHT.
>
> Fixes: b4a1ed0cd18b ("fbdev: make FB_BACKLIGHT a tristate")
> Reported-by: Randy Dunlap
> Cc: Rob Clark
> Cc: Arnd Bergmann
> Cc: Ben Skeggs
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Stephen Rothwell
> Signed-off-by: Bartlomiej Zolnierkiewicz
Works for me. Thanks.
Acked-by: Randy Dunlap # build-tested
> ---
> I would like to merge this patch through fbdev tree for v4.21
> (as it is needed to fix commit currently in fbdev tree).
>
> drivers/gpu/drm/nouveau/Kconfig |3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> Index: b/drivers/gpu/drm/nouveau/Kconfig
> ===
> --- a/drivers/gpu/drm/nouveau/Kconfig 2018-11-30 11:46:55.716464505 +0100
> +++ b/drivers/gpu/drm/nouveau/Kconfig 2018-12-28 14:54:51.655965845 +0100
> @@ -4,7 +4,8 @@ config DRM_NOUVEAU
> select FW_LOADER
> select DRM_KMS_HELPER
> select DRM_TTM
> - select FB_BACKLIGHT if DRM_NOUVEAU_BACKLIGHT
> + select BACKLIGHT_CLASS_DEVICE if DRM_NOUVEAU_BACKLIGHT
> + select BACKLIGHT_LCD_SUPPORT if DRM_NOUVEAU_BACKLIGHT
> select ACPI_VIDEO if ACPI && X86 && BACKLIGHT_CLASS_DEVICE && INPUT
> select X86_PLATFORM_DEVICES if ACPI && X86
> select ACPI_WMI if ACPI && X86
>
--
~Randy
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Nouveau module results in total lockups without any dmesg trace on a NP900X5N Kaby Lake machine
Hi Ben, David and Daniel , First of all happy new year. Based on advice of Greg K-H herewith a mail about a number of Nouveau issues with my laptop. I installed various Kali linux versions up to Linux 4.20.0-rc7 (downloaded, compiled and installed) on a Samsung NP900X5N laptop and have an issue with the driver after loading. My configuration: - i7 7500 - 16 gb / 256 gb ssd - nvidia 940MX (for 3D graphics) When I enable loading of the nouveau module for my Nvidia 3D card I get three MMIO faults: [ 35.984104] nouveau :01:00.0: bus: MMIO read of FAULT at 6013d4 [ IBUS ] [ 35.997510] nouveau :01:00.0: bus: MMIO read of FAULT at 10ac08 [ IBUS ] [ 37.551790] nouveau :01:00.0: bus: MMIO read of FAULT at 619444 [ IBUS ] I see currenty varous discussions on bugzilla: (as summarized by Bruno Pagani) https://bugs.freedesktop.org/show_bug.cgi?id=100423. But I do not see any confirmed solutions on the MMIO faults. The module is loaded but X server cannot run in framebuffer mode. I assume that the module does not provide any video memory to X to run in graphics mode. First of all I would like to understand what the faults impose. And I also would like to help you providing testing to fix the errors. Many thanks for your kind support. -- Met vriendelijke groet, *dr. Jan Vlietland*, namens spin-off Nederlands Instituut voor de Software Industrie _j.vlietland@nisi.nl_| 06 – 20 411 834 | 030 – 268 53 98 Princetonplein 5 | 3584 CC Utrecht | www.nisi.nl ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/7] drm: rockchip: vop: add rk3066 vop definitions
From: Mark Yao
This patch adds the rk3066 VOP definitions.
The VOP or LCD Controller serves as interface between
framebuffer memory and a display device (LCD panel or TV set).
This SOC has two symmetrical LCDC's for a dual panel application.
A LCDC has 5 display layers.
Only 3 are used here.
- Video layer 0 (Win0)
- Video layer 1 (Win1)
- OSD layer (Win2)
Win0 and Win1 are exchangeable.
Maximum resolution is 1920x1080.
The LCDC0 output is connected to:
- LCDC0 IO (without IOMUX)
- HDMI TX video input
The LCDC1 output is connected to:
- LCDC1 IO (with IOMUX)
- HDMI TX video input
The HDMI TX input can switch between LCDC0 and LCDC1.
Signed-off-by: Mark Yao
Signed-off-by: Johan Jonker
---
.../bindings/display/rockchip/rockchip-vop.txt | 1 +
drivers/gpu/drm/rockchip/rockchip_vop_reg.c| 110 +
drivers/gpu/drm/rockchip/rockchip_vop_reg.h| 53 ++
3 files changed, 164 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
index b79e5769f..4f58c5a2d 100644
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
@@ -10,6 +10,7 @@ Required properties:
"rockchip,rk3126-vop";
"rockchip,px30-vop-lit";
"rockchip,px30-vop-big";
+ "rockchip,rk3066-vop";
"rockchip,rk3188-vop";
"rockchip,rk3288-vop";
"rockchip,rk3368-vop";
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index a6db3cd55..2799c7e8e 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -299,6 +299,114 @@ static const struct vop_data px30_vop_lit = {
.win_size = ARRAY_SIZE(px30_vop_lit_win_data),
};
+static const struct vop_scl_regs rk3066_win_scl = {
+ .scale_yrgb_x = VOP_REG(RK3066_WIN0_SCL_FACTOR_YRGB, 0x, 0x0),
+ .scale_yrgb_y = VOP_REG(RK3066_WIN0_SCL_FACTOR_YRGB, 0x, 16),
+ .scale_cbcr_x = VOP_REG(RK3066_WIN0_SCL_FACTOR_CBR, 0x, 0x0),
+ .scale_cbcr_y = VOP_REG(RK3066_WIN0_SCL_FACTOR_CBR, 0x, 16),
+};
+
+static const struct vop_win_phy rk3066_win0_data = {
+ .scl = &rk3066_win_scl,
+ .data_formats = formats_win_full,
+ .nformats = ARRAY_SIZE(formats_win_full),
+ .enable = VOP_REG(RK3066_SYS_CTRL1, 0x1, 0),
+ .format = VOP_REG(RK3066_SYS_CTRL0, 0x7, 4),
+ .rb_swap = VOP_REG(RK3066_SYS_CTRL0, 0x1, 19),
+ .act_info = VOP_REG(RK3066_WIN0_ACT_INFO, 0x1fff1fff, 0),
+ .dsp_info = VOP_REG(RK3066_WIN0_DSP_INFO, 0x0fff0fff, 0),
+ .dsp_st = VOP_REG(RK3066_WIN0_DSP_ST, 0x1fff1fff, 0),
+ .yrgb_mst = VOP_REG(RK3066_WIN0_YRGB_MST0, 0x, 0),
+ .uv_mst = VOP_REG(RK3066_WIN0_CBR_MST0, 0x, 0),
+ .yrgb_vir = VOP_REG(RK3066_WIN0_VIR, 0x, 0),
+ .uv_vir = VOP_REG(RK3066_WIN0_VIR, 0x1fff, 16),
+};
+
+static const struct vop_win_phy rk3066_win1_data = {
+ .scl = &rk3066_win_scl,
+ .data_formats = formats_win_full,
+ .nformats = ARRAY_SIZE(formats_win_full),
+ .enable = VOP_REG(RK3066_SYS_CTRL1, 0x1, 1),
+ .format = VOP_REG(RK3066_SYS_CTRL0, 0x7, 7),
+ .rb_swap = VOP_REG(RK3066_SYS_CTRL0, 0x1, 23),
+ .act_info = VOP_REG(RK3066_WIN1_ACT_INFO, 0x1fff1fff, 0),
+ .dsp_info = VOP_REG(RK3066_WIN1_DSP_INFO, 0x0fff0fff, 0),
+ .dsp_st = VOP_REG(RK3066_WIN1_DSP_ST, 0x1fff1fff, 0),
+ .yrgb_mst = VOP_REG(RK3066_WIN1_YRGB_MST, 0x, 0),
+ .uv_mst = VOP_REG(RK3066_WIN1_CBR_MST, 0x, 0),
+ .yrgb_vir = VOP_REG(RK3066_WIN1_VIR, 0x, 0),
+ .uv_vir = VOP_REG(RK3066_WIN1_VIR, 0x1fff, 16),
+};
+
+static const struct vop_win_phy rk3066_win2_data = {
+ .data_formats = formats_win_lite,
+ .nformats = ARRAY_SIZE(formats_win_lite),
+ .enable = VOP_REG(RK3066_SYS_CTRL1, 0x1, 2),
+ .format = VOP_REG(RK3066_SYS_CTRL0, 0x7, 10),
+ .rb_swap = VOP_REG(RK3066_SYS_CTRL0, 0x1, 27),
+ .dsp_info = VOP_REG(RK3066_WIN2_DSP_INFO, 0x0fff0fff, 0),
+ .dsp_st = VOP_REG(RK3066_WIN2_DSP_ST, 0x1fff1fff, 0),
+ .yrgb_mst = VOP_REG(RK3066_WIN2_MST, 0x, 0),
+ .yrgb_vir = VOP_REG(RK3066_WIN2_VIR, 0x, 0),
+};
+
+static const struct vop_modeset rk3066_modeset = {
+ .htotal_pw = VOP_REG(RK3066_DSP_HTOTAL_HS_END, 0x1fff1fff, 0),
+ .hact_st_end = VOP_REG(RK3066_DSP_HACT_ST_END, 0x1fff1fff, 0),
+ .vtotal_pw = VOP_REG(RK3066_DSP_VTOTAL_VS_END, 0x1fff1fff, 0),
+ .vact_st_end = VOP_REG(RK3066_DSP_VACT_ST_END, 0x1fff1fff, 0),
+};
+
+static const struct vop_output rk3066_output = {
+ .pin_pol = VOP_REG(RK3066_DSP_CTRL0, 0x7, 4),
+};
+
+static const struct vop_common rk3066_common = {
+ .standby = VOP_REG(RK3066_SYS_CTR
[PATCH v2 5/7] ARM: dts: rockchip: add rk3066 vop display nodes
From: Mark Yao
This patch adds the core display subsystem and vop nodes to rk3066.
Signed-off-by: Mark Yao
Signed-off-by: Johan Jonker
---
arch/arm/boot/dts/rk3066a.dtsi | 47 ++
1 file changed, 47 insertions(+)
diff --git a/arch/arm/boot/dts/rk3066a.dtsi b/arch/arm/boot/dts/rk3066a.dtsi
index b6b3a77da..653127a37 100644
--- a/arch/arm/boot/dts/rk3066a.dtsi
+++ b/arch/arm/boot/dts/rk3066a.dtsi
@@ -44,6 +44,11 @@
};
};
+ display-subsystem {
+ compatible = "rockchip,display-subsystem";
+ ports = <&vop0_out>, <&vop1_out>;
+ };
+
sram: sram@1008 {
compatible = "mmio-sram";
reg = <0x1008 0x1>;
@@ -57,6 +62,48 @@
};
};
+ vop0: vop@1010c000 {
+ compatible = "rockchip,rk3066-vop";
+ reg = <0x1010c000 0x19c>;
+ interrupts = ;
+ clocks = <&cru ACLK_LCDC0>,
+<&cru DCLK_LCDC0>,
+<&cru HCLK_LCDC0>;
+ clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
+ power-domains = <&power RK3066_PD_VIO>;
+ resets = <&cru SRST_LCDC0_AXI>,
+<&cru SRST_LCDC0_AHB>,
+<&cru SRST_LCDC0_DCLK>;
+ reset-names = "axi", "ahb", "dclk";
+ status = "disabled";
+
+ vop0_out: port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+
+ vop1: vop@1010e000 {
+ compatible = "rockchip,rk3066-vop";
+ reg = <0x1010e000 0x19c>;
+ interrupts = ;
+ clocks = <&cru ACLK_LCDC1>,
+<&cru DCLK_LCDC1>,
+<&cru HCLK_LCDC1>;
+ clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
+ power-domains = <&power RK3066_PD_VIO>;
+ resets = <&cru SRST_LCDC1_AXI>,
+<&cru SRST_LCDC1_AHB>,
+<&cru SRST_LCDC1_DCLK>;
+ reset-names = "axi", "ahb", "dclk";
+ status = "disabled";
+
+ vop1_out: port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+
i2s0: i2s@10118000 {
compatible = "rockchip,rk3066-i2s";
reg = <0x10118000 0x2000>;
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 0/5] drm/bridge: various small lvds-encoder things
Hi! I'm not sure if I should have added the texas chips to the lvds_encoder_match list in the driver, right next to the thine,thc63lvdm83d entry, but ended up not doing that. That can always be added later, if needed... Changes since v2: - changed from pwdn-gpios to powerdown-gpios after discussion with Rob with new patch 3/5 updating the thine,thc63lvdm83d binding as well as a consequence - added patch 4/5 which helps keep lines shorter in the lvds-encoder driver - added tag from Rob on patch 2/5 Changes since v1: - fork out the bindings for the texas chips into their own file in order to avoid clutter in the generic lvds-transmitter binding. - added a patch to remove some surplus stuff in the generic lvds-transmitter binding. Cheers, Peter Peter Rosin (5): dt-bindings: display: bridge: fork out ti,ds90c185 from lvds-transmitter dt-bindings: display: bridge: lvds-transmitter: cleanup example dt-bindings: display: bridge: thc63lvdm83d: use standard powerdown-gpios drm/bridge: lvds-encoder: add dev helper variable in .probe() drm/bridge: lvds-encoder: add powerdown-gpios support .../bindings/display/bridge/lvds-transmitter.txt | 10 +--- .../bindings/display/bridge/thine,thc63lvdm83d.txt | 2 +- .../bindings/display/bridge/ti,ds90c185.txt| 55 ++ drivers/gpu/drm/bridge/lvds-encoder.c | 53 + 4 files changed, 100 insertions(+), 20 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,ds90c185.txt -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] qcom-scm: Include header
On Wed 26 Dec 04:06 PST 2018, Fabio Estevam wrote:
> Since commit e6f6d63ed14c ("drm/msm: add headless gpu device for imx5")
> the DRM_MSM symbol can be selected by SOC_IMX5 causing the following
> error when building imx_v6_v7_defconfig:
>
> In file included from ../drivers/gpu/drm/msm/adreno/a5xx_gpu.c:17:0:
> ../include/linux/qcom_scm.h: In function 'qcom_scm_set_cold_boot_addr':
> ../include/linux/qcom_scm.h:73:10: error: 'ENODEV' undeclared (first use in
> this function)
> return -ENODEV;
>
> Include the header file to fix this problem.
>
Reviewed-by: Bjorn Andersson
Andy, please pick up for inclusion in -rc
Fabio, please use get_maintainers, so your patches hits the appropriate
mailing lists (linux-arm-msm@ in this case)
Regards,
Bjorn
> Reported-by: kernelci.org bot
> Fixes: e6f6d63ed14c ("drm/msm: add headless gpu device for imx5")
> Signed-off-by: Fabio Estevam
> ---
> include/linux/qcom_scm.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/linux/qcom_scm.h b/include/linux/qcom_scm.h
> index 06996ad4f2bc..ce5a476fd733 100644
> --- a/include/linux/qcom_scm.h
> +++ b/include/linux/qcom_scm.h
> @@ -13,6 +13,7 @@
> #ifndef __QCOM_SCM_H
> #define __QCOM_SCM_H
>
> +#include
> #include
> #include
>
> --
> 2.17.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
ATI FirePro 2260 doesn't work after the update 'drm-next-2018-12-14'
Hello, An end user reportet that his ATI FirePro 2260 doesn't work anymore with the latest Git kernel. We are a first level Linux support and we usually compile Git kernels during the merge window time for testing. After the update 'drm-next-2018-12-14', his ATI FirePro 2260 doesn't work anymore. We removed the update 'drm-next-2018-12-14' and after that he reported that his ATI FirePro 2260 works again. Unfortunately we can't test because we don't have an ATI FirePro 2260. Please check the update. Currently we release test kernels without your latest updates for our end users. Further information in the support thread: http://forum.hyperion-entertainment.com/viewtopic.php?f=58&t=4181&start=30#p46644 Cheers, Christian ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109178] Keyboard backlight on Samsung Np900X5N not working due to not loading samsung-laptop.ko module
https://bugs.freedesktop.org/show_bug.cgi?id=109178 Jan changed: What|Removed |Added Version|unspecified |DRI git Priority|medium |high Hardware|Other |x86-64 (AMD64) OS|All |Linux (All) -- 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 109162] Bugs Bunny: Lost in Time
https://bugs.freedesktop.org/show_bug.cgi?id=109162 --- Comment #11 from Roland Scheidegger --- These kind of bugs is usually due to app error (not requesting a depth buffer but still needing one, relying on the implementation to provide one anyway). Although in this case, I suppose wine could be involved too, maybe there's some pecularities when emulating wgl with glx. Seems unlikely to me though that the bug is in mesa code. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Nouveau module X server not starting on a NP900X5N Kaby Lake machine
On Tue, Jan 1, 2019 at 5:30 PM Jan Vlietland wrote: > > Hi Ilia, many thanks for answering my mail. > > Tonight I tried to see what happens if I generate a xorg.conf file and place > it in /etc/X11/xorg.conf, as described here: > https://askubuntu.com/questions/4662/where-is-the-x-org-config-file-how-do-i-configure-x-there > > When I do that X starts without the framebuffer error. X starts with a > backtrace list in the shell and then stops with the error: > > 'Segmentation fault at address 0x0. > > Fatal sever error etc etc etc. Unless you're an advanced user, you'll get the best results by not supplying a manual xorg.conf. Generically, this indicates that you messed something up. Without knowing precisely what the contents of that file are, it would be difficult to say what exactly went wrong. However I wouldn't advise this path without a good reason. > > Hope this helps! > > In fact the above is part of a much bigger issue I have with the > machine. When I enable the i915 module (Kaby lake native video) my > screen goed black after a while. The machine is totally stuck in that > state. Even ssh connection is not possible. It shows no errors in the > (saved) logs after restarting the machine. > > So I disabled the i915 module and try to get the nvidia card running. > Without any luck. > > Thank you for inviting me for irc.freenode.net. What it the procss to > get access? It's an IRC network like any other. More info about the network available at https://freenode.net/ It's open to anyone... #nouveau for nouveau, #intel-gfx for intel. > > I have included the full dmesg in zip format. > > For me it is a showstopper using the machine with Linux. I really do not > understand that I am the only person on this planet that cannot run > Linux on a plain vanilla Kaby lake machine. I don't know the specifics of your laptop, but on many other GM108M laptops, the displays are only attached to the Intel GPU. So running without i915 is just not an option, if you want anything displayed. You would be able to use the GM108M chip for 3D acceleration if you chose, but nothing to do with actual display. If your screen goes black with i915 loaded, I suspect that you'd be better served reporting this issue to Intel. From your logs, you also appear to have a variety of combinations of nomodeset/.modeset=0 combinations -- these will just impede the proper mode of operation. The i915 and nouveau drivers effectively do nothing under those conditions. Cheers, -ilia ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107613] [amdgpu] reproducible crashes in 3D games, amdgpu_dm_commit_planes: acrtc 0, already busy
https://bugs.freedesktop.org/show_bug.cgi?id=107613 --- Comment #1 from J. Andrew Lanz-O'Brien --- Update: this bug is still present as of kernel 4.20.0-arch1-1-ARCH #1 SMP PREEMPT Mon Dec 24 03:00:40 UTC 2018 x86_64 GNU/Linux Setting amdgpu.dc=0 in the GRUB command fixes the issue, but then HDMI audio doesn't work. -- 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 107561] [amdgpu] / rx550 / half the fps after thaw
https://bugs.freedesktop.org/show_bug.cgi?id=107561 arne_woer...@yahoo.com changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from arne_woer...@yahoo.com --- Hi! Since kernel-4.20.0 the fps after thaw are as before thaw... Thx. Bye. -- 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 0/6] drm/i915: drmP.h include removal w/ drm prep work
On Fri, 28 Dec 2018, Jani Nikula wrote: > Thanks for all the reviews, pushed patches 1-5 to topic/drmp-cleanup > with $(git merge-base drm-misc-next drm-intel-next-queued) as the > starting point. It's also included in drm-tip now. So I did this *before* I got the review feedback from Laurent, based on Daniel's review only. Would you all like me to redo the branch with Laurent's comments addressed and r-b added? BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
