[Bug 155141] New: [KMS] Artifacts with OpenSource Radeon driver

[bugzilla-dae...@bugzilla.kernel.org]

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

Bug ID: 155141
   Summary: [KMS] Artifacts with OpenSource Radeon driver
   Product: Drivers
   Version: 2.5
Kernel Version: 4.7
  Hardware: x86-64
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-dri at kernel-bugs.osdl.org
  Reporter: tinctura.ginseng at gmail.com
Regression: No

OS: Arch Linux
Hardware: Notebook ASUS F8Vr, CPU Intel Core 2 Duo P8400 2.26GHz, 4 GB RAM,
Mobility Radeon HD 3470 (RV620)

After update kernel from 4.6.4 to 4.7 I found artifacts when KMS activated -
blue dots drop down in console and graphics mode. Downgrade to 4.6.4 - not
found any artifacts. Upgrade to 4.7.1 and 4.7.2 - artifacts is found. When I
disable KMS with 'nomodeset' kernel parameter the artifacts disappear.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

Plan to support Rockchip VPU in DRM, is it a good idea

[Theodore Kilgore]

On Fri, 26 Aug 2016, Randy Li wrote:

>
>
> On 08/26/2016 05:34 PM, Hans Verkuil wrote:
>> Hi Randi,
>> 
>> On 08/26/2016 04:13 AM, Randy Li wrote:
>>> Hello,
>>>We always use some kind of hack work to make our Video Process
>>> Unit(Multi-format Video Encoder/Decoder) work in kernel. From a
>>> customize driver(vpu service) to the customize V4L2 driver. The V4L2
>>> subsystem is really not suitable for the stateless Video process or it
>>> could make driver too fat.
>>>After talking to some kindness Intel guys and moving our userspace
>>> library to VA-API driver, I find the DRM may the good choice for us.
>>> But I don't know whether it is welcome to to submit a video driver in
>>> DRM subsystem?
>>>Also our VPU(Video process unit) is not just like the Intel's, we
>>> don't have VCS, we based on registers to set the encoder/decoder. I
>>> think we may need a lots of IOCTL then. Also we do have a IOMMU in VPU
>>> but also not a isolated memory for VPU, I don't know I should use TT
>>> memory or GEM memory.
>>>I am actually not a member of the department in charge of VPU, and I
>>> am just beginning to learning DRM(thank the help from Intel again), I am
>>> not so good at memory part as well(I am more familiar with CMA not the
>>> IOMMU way), I may need know guide about the implementations when I am
>>> going to submit driver, I hope I could get help from someone.
>>> 
>> 
>> It makes no sense to do this in the DRM subsystem IMHO. There are already
>> quite a few HW codecs implemented in the V4L2 subsystem and more are in the
>> pipeline. Putting codec support in different subsystems will just make
>> userspace software much harder to write.
>> 
>> One of the codecs that was posted to linux-media was actually from 
>> Rockchip:
>> 
>> https://lkml.org/lkml/2016/2/29/861
>> 
>> There is also a libVA driver (I think) that sits on top of it:
>> 
>> https://github.com/rockchip-linux/rockchip-va-driver/tree/v4l2-libvpu
> It is old version, I am the author of this
> https://github.com/rockchip-linux/rockchip-va-driver
>> 
>> For the Allwinner a patch series was posted yesterday:
>> 
>> https://lkml.org/lkml/2016/8/25/246
>> 
>> They created a pretty generic libVA userspace that looks very promising at
>> first glance.
>> 
>> What these have in common is that they depend on the Request API and Frame 
>> API,
>> neither of which has been merged. The problem is that the Request API 
>> requires
>> more work since not only controls have to be part of a request, but also 
>> formats,
>> selection rectangles, and even dynamic routing changes. While that is not 
>> relevant
>> for codecs, it is relevant for Android CameraHAL in general and complex 
>> devices
>> like Google's Project Ara.
> Actually just as the Intel did, our hardware decoder/encoder need full 
> settings for them, most of them are relevant to the codec. You may notice 
> that there is four extra control need to be set before. If the libvpu(a 
> helper library we offered to parse each slice to generate decoder settings) 
> is remove(in process now, only three decoder settings can't got from VA-API 
> directly), it would be more clearly.
> We really a lots decoder settings information to make the decoder work.
>> 
>> This is being worked on, but it is simply not yet ready. The core V4L2 
>> developers
>> involved in this plan to discuss this on the Monday before the ELCE in 
>> Berlin,
>> to see if we can fast track this work somehow so this support can be 
>> merged.
>> 
> I am glad to hear that. I hope that I could have an opportunity to show our 
> problems.
>> If there are missing features in V4L2 (other that the two APIs discussed 
>> above)
>> that prevent you from creating a good driver, then please discuss that with 
>> us.
>> We are always open to suggestions and improvements and want to work with 
>> you on
>> that.
> I have a few experience with the s5p-mfc, and I do wrote a V4L2 encoder 
> plugin for Gstreamer.  I don't think the V4L2 is good place for us stateless 
> video processor, unless it would break the present implementation.
>
>  The stateful and stateless are operated quite differently. The stateless 
> must parse the header and set those settings for every frames.

Then one needs to incorporate in the driver a way to detect whether one 
has to support "stateless" or "stateful." There must be a way to do this 
kind of thing, even if it is not documented by anybody. One way, perhaps, 
might be to look at the data and see if there is any header, or not. Then 
parse the header if it is present, otherwise don't.

> The request data may quite different from vendor to vendor, even chip to 
> chip.

By "request data" and "chip to chip" I assume you mean the initialization 
of a video chip, or something analogous or similar. Believe it or not, 
this kind of problem has been seen before and dealt with. Look at 
drivers/media/usb/gspca/mr97310a.c for an example. The exact problem that 
we faced was that different cameras 

[v17 2/2] drm/bridge: Add I2C based driver for ps8640 bridge

[Jitao Shi]

This patch adds drm_bridge driver for parade DSI to eDP bridge chip.

Signed-off-by: Jitao Shi 
Reviewed-by: Daniel Kurtz 
---
Changes since v16:
 - Disable ps8640 DSI MCS Function.
 - Rename gpios name more clearly.
 - Tune the ps8640 power on sequence.

Changes since v15:
 - Drop drm_connector_(un)register calls from parade ps8640.
   The main DRM driver mtk_drm_drv now calls
   drm_connector_register_all() after drm_dev_register() in the
   mtk_drm_bind() function. That function should iterate over all
   connectors and call drm_connector_register() for each of them.
   So, remove drm_connector_(un)register calls from parade ps8640.

Changes since v14:
 - update copyright info.
 - change bridge_to_ps8640 and connector_to_ps8640 to inline function.
 - fix some coding style.
 - use sizeof as array counter.
 - use drm_get_edid when read edid.
 - add mutex when firmware updating. 

Changes since v13:
 - add const on data, ps8640_write_bytes(struct i2c_client *client, const u8 
*data, u16 data_len)
 - fix PAGE2_SW_REST tyro.
 - move the buf[3] init to entrance of the function.

Changes since v12:
 - fix hw_chip_id build warning

Changes since v11:
 - Remove depends on I2C, add DRM depends
 - Reuse ps8640_write_bytes() in ps8640_write_byte()
 - Use timer check for polling like the routines in 
 - Fix no drm_connector_unregister/drm_connector_cleanup when 
ps8640_bridge_attach fail
 - Check the ps8640 hardware id in ps8640_validate_firmware
 - Remove fw_version check
 - Move ps8640_validate_firmware before ps8640_enter_bl
 - Add ddc_i2c unregister when probe fail and ps8640_remove
---
 drivers/gpu/drm/bridge/Kconfig |   12 +
 drivers/gpu/drm/bridge/Makefile|1 +
 drivers/gpu/drm/bridge/parade-ps8640.c | 1077 
 3 files changed, 1090 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/parade-ps8640.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index b590e67..c59d043 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -50,6 +50,18 @@ config DRM_PARADE_PS8622
---help---
  Parade eDP-LVDS bridge chip driver.

+config DRM_PARADE_PS8640
+   tristate "Parade PS8640 MIPI DSI to eDP Converter"
+   depends on DRM
+   depends on OF
+   select DRM_KMS_HELPER
+   select DRM_MIPI_DSI
+   select DRM_PANEL
+   ---help---
+ Choose this option if you have PS8640 for display
+ The PS8640 is a high-performance and low-power
+ MIPI DSI to eDP converter
+
 config DRM_SII902X
tristate "Silicon Image sii902x RGB/HDMI bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index efdb07e..3360537 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
 obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
 obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
 obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
+obj-$(CONFIG_DRM_PARADE_PS8640) += parade-ps8640.o
 obj-$(CONFIG_DRM_SII902X) += sii902x.o
 obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
 obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c 
b/drivers/gpu/drm/bridge/parade-ps8640.c
new file mode 100644
index 000..7d67431
--- /dev/null
+++ b/drivers/gpu/drm/bridge/parade-ps8640.c
@@ -0,0 +1,1077 @@
+/*
+ * Copyright (c) 2016 MediaTek Inc.
+ *
+ * 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.
+ *
+ * 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 
+#include 
+#include 
+#include 
+
+#define PAGE1_VSTART   0x6b
+#define PAGE2_SPI_CFG3 0x82
+#define I2C_TO_SPI_RESET   0x20
+#define PAGE2_ROMADD_BYTE1 0x8e
+#define PAGE2_ROMADD_BYTE2 0x8f
+#define PAGE2_SWSPI_WDATA  0x90
+#define PAGE2_SWSPI_RDATA  0x91
+#define PAGE2_SWSPI_LEN0x92
+#define PAGE2_SWSPI_CTL0x93
+#define TRIGGER_NO_READBACK0x05
+#define TRIGGER_READBACK   0x01
+#define PAGE2_SPI_STATUS   0x9e
+#define SPI_READY  0x0c
+#define PAGE2_GPIO_L   0xa6
+#define PAGE2_GPIO_H   0xa7
+#define PS_GPIO9   BIT(1)
+#define PAGE2_IROM_CTRL0xb0
+#define IROM_ENABLE0xc0
+#define IROM_DISABLE   0x80
+#define PAGE2_SW_RESET 0xbc
+#define SPI_SW_RESET   BIT(7)
+#define MPU_SW_RESET  

[v17 1/2] Documentation: bridge: Add documentation for ps8640 DT properties

[Jitao Shi]

Add documentation for DT properties supported by
ps8640 DSI-eDP converter.

Signed-off-by: Jitao Shi 
Acked-by: Rob Herring 
Reviewed-by: Philipp Zabel 
---
Changes since v16:
 - No change.

Changes since v15:
 - No change.

Changes since v14:
 - change mode-sel-gpios as optional.
---
 .../devicetree/bindings/display/bridge/ps8640.txt  |   44 
 1 file changed, 44 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/bridge/ps8640.txt

diff --git a/Documentation/devicetree/bindings/display/bridge/ps8640.txt 
b/Documentation/devicetree/bindings/display/bridge/ps8640.txt
new file mode 100644
index 000..7b13f92
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ps8640.txt
@@ -0,0 +1,44 @@
+ps8640-bridge bindings
+
+Required properties:
+   - compatible: "parade,ps8640"
+   - reg: first page address of the bridge.
+   - sleep-gpios: OF device-tree gpio specification for PD pin.
+   - reset-gpios: OF device-tree gpio specification for reset pin.
+   - vdd12-supply: OF device-tree regulator specification for 1.2V power.
+   - vdd33-supply: OF device-tree regulator specification for 3.3V power.
+   - ports: The device node can contain video interface port nodes per
+the video-interfaces bind[1]. For port at 0,set the reg = <0> 
as
+ps8640 dsi in and port at 1,set the reg = <1> as ps8640 eDP 
out.
+
+Optional properties:
+   - mode-sel-gpios: OF device-tree gpio specification for mode-sel pin.
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+   edp-bridge at 18 {
+   compatible = "parade,ps8640";
+   reg = <0x18>;
+   sleep-gpios = < 116 GPIO_ACTIVE_LOW>;
+   reset-gpios = < 115 GPIO_ACTIVE_LOW>;
+   mode-sel-gpios = < 92 GPIO_ACTIVE_HIGH>;
+   vdd12-supply = <_fixed_1v2>;
+   vdd33-supply = <_vgp2_reg>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   port at 0 {
+   reg = <0>;
+   ps8640_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   port at 1 {
+   reg = <1>;
+   ps8640_out: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+   };
-- 
1.7.9.5

[PATCH] omapdrm: dss: drop unneeded of_node_put() on ref passed to of_get_next_parent()

[Matthijs van Duin]

> [8.842806] OF: ERROR: Bad of_node_put() on /encoder/ports/port at 
> 1/endpoint
> [8.843014] [] (omapdss_of_find_source_for_first_ep [omapdss])

I can confirm that reverting 2ab9f5879162 fixes this regression,
tested on omap5-uevm.

Matthijs

[PATCH] omapdrm: dss: drop unneeded of_node_put() on ref passed to of_get_next_parent()

[Matthijs van Duin]

To clarify, this patch effectively reverts

commit 2ab9f5879162499e1c4e48613287e3f59e593c4f
gpu: drm: omapdrm: dss-of: add missing of_node_put after calling
of_parse_phandle

except it leaves behind unnecessary verbiage that this commit
introduced. And to be clear, that commit *should* indeed be reverted,
although preferably in its entirety obviously.

of_get_next_parent already drops a ref on its argument, so of_node_put
was never "missing" here.

Matthijs

[PATCH] drm/atomic: Don't potentially reset color_mgmt_changed on successive property updates.

[Mario Kleiner]

Due to assigning the 'replaced' value instead of or'ing it,
if drm_atomic_crtc_set_property() gets called multiple times,
the last call will define the color_mgmt_changed flag, so
a non-updating call to a property can reset the flag and
prevent actual hw state updates required by preceding
property updates.

Signed-off-by: Mario Kleiner 
Cc: Daniel Vetter 
Cc:  # v4.6+
---
 drivers/gpu/drm/drm_atomic.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 8d2f111..3a985d6 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -475,7 +475,7 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
val,
-1,
);
-   state->color_mgmt_changed = replaced;
+   state->color_mgmt_changed |= replaced;
return ret;
} else if (property == config->ctm_property) {
ret = drm_atomic_replace_property_blob_from_id(crtc,
@@ -483,7 +483,7 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
val,
sizeof(struct drm_color_ctm),
);
-   state->color_mgmt_changed = replaced;
+   state->color_mgmt_changed |= replaced;
return ret;
} else if (property == config->gamma_lut_property) {
ret = drm_atomic_replace_property_blob_from_id(crtc,
@@ -491,7 +491,7 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
val,
-1,
);
-   state->color_mgmt_changed = replaced;
+   state->color_mgmt_changed |= replaced;
return ret;
} else if (crtc->funcs->atomic_set_property)
return crtc->funcs->atomic_set_property(crtc, state, property, 
val);
-- 
2.7.0

[Bug 97504] Enabling SDMA on CIK (0241d8300f66ee2c6c2c55fe64ac88d76440c591) causes corruption on a mobile Bonaire with AMDGPU DDX / video desktop recording

[bugzilla-dae...@freedesktop.org]

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

Shawn Starr  changed:

   What|Removed |Added

 QA Contact||dri-devel at lists.freedesktop
   ||.org
Version|unspecified |git
Product|DRI |Mesa
  Component|DRM/AMDgpu  |Drivers/Gallium/radeonsi

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160827/76939f5e/attachment.html>

[Bug 97504] Enabling SDMA on CIK (0241d8300f66ee2c6c2c55fe64ac88d76440c591) causes corruption on a mobile Bonaire with AMDGPU DDX / video desktop recording

[bugzilla-dae...@freedesktop.org]

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

Bug ID: 97504
   Summary: Enabling SDMA on CIK
(0241d8300f66ee2c6c2c55fe64ac88d76440c591) causes
corruption on a mobile Bonaire with AMDGPU DDX / video
desktop recording
   Product: DRI
   Version: unspecified
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: shawn.starr at rogers.com

With latest agd5f drm-fixes-4.8 / drm-next-4.9-wip + Linus master kernel:

Latest git mesa master with SDMA enabled on CIK patch:

1) AMDGPU DDX shows squared corruption, X locks up
2) Using vlc desktop recording / vokoscreen desktop recording get corrupted
video recording

Kernel spits out GPUVPM faults:

[ 6612.359198] amdgpu :01:00.0: GPU fault detected: 146 0x0248770c
[ 6612.359199] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x0010C836
[ 6612.359199] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x0807700C
[ 6612.359200] VM fault (0x0c, vmid 4) at page 1099830, read from 'SDM0'
(0x53444d30) (119)

  Revert "radeonsi: enable SDMA on CIK"

This reverts commit 0241d8300f66ee2c6c2c55fe64ac88d76440c591.


When reverted problems go away.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160827/079e5c53/attachment.html>

[Bug 97340] POSTAL 2 poor performance at certain times, RadeonSI driver

[bugzilla-dae...@freedesktop.org]

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

--- Comment #2 from Declan Hoare  ---
It seems that this situation has been improved somewhat on Mesa Git in the last
12 hours. The freezes are still there, but they're shorter and less frequent.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[PATCH] drm: rockchip: drop unused 'irq' member from inno_hdmi

[Shawn Guo]

The 'irq' member in struct inno_hdmi is used nowhere.  Drop it.

Cc: Mark Yao 
Signed-off-by: Shawn Guo 
---
 drivers/gpu/drm/rockchip/inno_hdmi.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c 
b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 006260de9dbd..24d18e66034f 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -59,7 +59,6 @@ struct inno_hdmi {
struct device *dev;
struct drm_device *drm_dev;

-   int irq;
struct clk *pclk;
void __iomem *regs;

-- 
1.9.1