[PATCH v2] drm/fb-helper: add DRM_FB_HELPER_DEFAULT_OPS for fb_ops
The define DRM_FB_HELPER_DEFAULT_OPS provides the drm_fb_helper default
implementations for functions in struct fb_ops. A drm driver can use it
like:
static struct fb_ops drm_fbdev_cma_ops = {
.owner = THIS_MODULE,
DRM_FB_HELPER_DEFAULT_OPS,
/* driver specific implementations */
};
Suggested-by: Daniel Vetter
Signed-off-by: Stefan Christ
---
v2: Fix sphinx error:
warning: Cannot understand * @DRM_FB_HELPER_DEFAULT_OPS:
---
include/drm/drm_fb_helper.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index db8d478..f7d7126 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -214,6 +214,19 @@ struct drm_fb_helper {
bool delayed_hotplug;
};
+/**
+ * define DRM_FB_HELPER_DEFAULT_OPS - helper define for drm drivers
+ *
+ * Helper define to register default implementations of drm_fb_helper
+ * functions. To be used in struct fb_ops of drm drivers.
+ */
+#define DRM_FB_HELPER_DEFAULT_OPS \
+ .fb_check_var = drm_fb_helper_check_var, \
+ .fb_set_par = drm_fb_helper_set_par, \
+ .fb_setcmap = drm_fb_helper_setcmap, \
+ .fb_blank = drm_fb_helper_blank, \
+ .fb_pan_display = drm_fb_helper_pan_display
+
#ifdef CONFIG_DRM_FBDEV_EMULATION
int drm_fb_helper_modinit(void);
void drm_fb_helper_prepare(struct drm_device *dev, struct drm_fb_helper
*helper,
--
2.1.4
[Bug 98028] Guns of Icarus Online segfaults on startup since AMDGPU: Partially fix control flow at -O0
https://bugs.freedesktop.org/show_bug.cgi?id=98028 --- Comment #6 from Daniel Scharrer --- Created attachment 127008 --> https://bugs.freedesktop.org/attachment.cgi?id=127008&action=edit Valgrind log I managed to get a Valgrind log, the backtrace of the first invalid read seems consistent. Here are the options I used, let me know if you want me to try any others: valgrind --tool=memcheck --error-limit=no --log-file=valgrind-%p.log -v --trace-children=yes --track-origins=yes --read-var-info=yes --redzone-size=1024 -- I also noticed that the game's engine (Unity) overrides operator new and friends, maybe that's involved somehow. -- 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/20161004/d0cc0d8b/attachment.html>
[Bug 98003] Tonga fails to boot since drm/amdgpu:exclude 5dw digest for entry
https://bugs.freedesktop.org/show_bug.cgi?id=98003 Andy Furniss changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Andy Furniss --- I see this is gone from latest 4.9-wip which is booting OK so closing. -- 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/20161004/f42c3d3e/attachment-0001.html>
[PATCH] drm: simple_kms_helper: Handle the vblank events
On 10/03/2016 03:51 PM, Daniel Vetter wrote: > On Sun, Oct 2, 2016 at 7:15 PM, Marek Vasut wrote: >>> One thing we could look into for simple pipe helpers is to have a >>> drm_simple_pipe_state which contains both states, and pass that >>> simple_state into all callbacks. Needs a bit of trickery in the >>> atomic_duplicate_state hooks though, so not sure whether that's worth >>> it. But merging plane/crtc state for simple pipe would be nice, since >>> the plane/crtc itself are also merged. >> >> I took a brief look into this, but I don't think I see the benefit of >> it. What am I missing here ? > > Well if there's no benefit, then let's not do it - it was just an idea I had. But I'm a newcomer to DRM/KMS framework, most of the time I barely know what I'm doing, so it's easily possible I missed something obvious. I can only think of reducing the number of memory allocations a little, but I am not convinced this is worth it. > -Daniel > -- Best regards, Marek Vasut
[Bug 98020] Tonga agd5f 4.9-wip WARNING: at drivers/gpu/drm/drm_irq.c:1168 drm_vblank_put+0xaa/0xb0
https://bugs.freedesktop.org/show_bug.cgi?id=98020 Andy Furniss changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Andy Furniss --- This is in 4.9-wip now and I guess elsewhere so closing. -- 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/20161004/f9012e34/attachment.html>
[PATCH V2] OMAPDSS: Kconfig: Add HDMI for OMAP4 and OMAP5 dependencies
Make "HDMI for OMAP4" and "HDMI for OMAP5" depend on ARCH_OMAP4 and SOC_OMAP5/DRA7XX respectively. Signed-off-by: Adam Ford Changes in v2: Add dependancy for DRA7XX or OMAP5 diff --git a/drivers/gpu/drm/omapdrm/dss/Kconfig b/drivers/gpu/drm/omapdrm/dss/Kconfig index d1fa730..befdd7a 100644 --- a/drivers/gpu/drm/omapdrm/dss/Kconfig +++ b/drivers/gpu/drm/omapdrm/dss/Kconfig @@ -69,13 +69,15 @@ config OMAP2_DSS_HDMI_COMMON config OMAP4_DSS_HDMI bool "HDMI support for OMAP4" -default y + depends on ARCH_OMAP4 + default y select OMAP2_DSS_HDMI_COMMON help HDMI support for OMAP4 based SoCs. config OMAP5_DSS_HDMI bool "HDMI support for OMAP5" + depends on SOC_OMAP5 || SOC_DRA7XX default n select OMAP2_DSS_HDMI_COMMON help diff --git a/drivers/video/fbdev/omap2/omapfb/dss/Kconfig b/drivers/video/fbdev/omap2/omapfb/dss/Kconfig index 27d2202..19e2e7b 100644 --- a/drivers/video/fbdev/omap2/omapfb/dss/Kconfig +++ b/drivers/video/fbdev/omap2/omapfb/dss/Kconfig @@ -65,13 +65,15 @@ config FB_OMAP2_DSS_HDMI_COMMON config FB_OMAP4_DSS_HDMI bool "HDMI support for OMAP4" -default y + depends on ARCH_OMAP4 + default y select FB_OMAP2_DSS_HDMI_COMMON help HDMI support for OMAP4 based SoCs. config FB_OMAP5_DSS_HDMI bool "HDMI support for OMAP5" + depends on SOC_OMAP5 || SOC_DRA7XX default n select FB_OMAP2_DSS_HDMI_COMMON help -- 2.7.4
[Bug 176311] Fiji DisplayPort amdgpu_crtc_page_flip *ERROR* failed to get vblank before flip
https://bugzilla.kernel.org/show_bug.cgi?id=176311 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #1 from Alex Deucher --- Please attach your dmesg output and xorg log. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 176301] Fiji DisplayPort drm_crtc_helper_set_config *ERROR* failed to set mode on
https://bugzilla.kernel.org/show_bug.cgi?id=176301 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #1 from Alex Deucher --- Please attach your dmesg output and xorg log. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 176311] New: Fiji DisplayPort amdgpu_crtc_page_flip *ERROR* failed to get vblank before flip
https://bugzilla.kernel.org/show_bug.cgi?id=176311 Bug ID: 176311 Summary: Fiji DisplayPort amdgpu_crtc_page_flip *ERROR* failed to get vblank before flip Product: Drivers Version: 2.5 Kernel Version: 4.7.5-200.fc24.x86_64 Hardware: All 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: vedran at miletic.net Regression: No As said in bug 176301, I have a Fiji card 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Fiji [Radeon R9 FURY / NANO Series] (rev ca) with two LG DisplayPort 27" 4K monitors. Locking screen while GNOME is running on X makes both monitors go to sleep, all fine. Upon moving a mouse or pressing a key, only one of them will wake up, and always the same one. Dmesg shows: [drm:amdgpu_crtc_page_flip [amdgpu]] *ERROR* failed to get vblank before flip The other monitor will wake up if one switches to a console (e.g. Ctrl+Alt+F3) and back or one powers any of the monitors off and back on. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 176301] New: Fiji DisplayPort drm_crtc_helper_set_config *ERROR* failed to set mode on
https://bugzilla.kernel.org/show_bug.cgi?id=176301 Bug ID: 176301 Summary: Fiji DisplayPort drm_crtc_helper_set_config *ERROR* failed to set mode on Product: Drivers Version: 2.5 Kernel Version: 4.7.5-200.fc24.x86_64 Hardware: All OS: Linux Tree: Fedora Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri at kernel-bugs.osdl.org Reporter: vedran at miletic.net Regression: No I have a Fiji card 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Fiji [Radeon R9 FURY / NANO Series] (rev ca) with two LG DisplayPort 27" 4K monitors. If one of the displays is powered off, but connected, dmesg shows error messages [drm:drm_crtc_helper_set_config [drm_kms_helper]] *ERROR* failed to set mode on [CRTC:34:crtc-1] and GDM/X will refuse to run. -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH 2/2] drm: rcar-du: Add support for LVDS mode selection
Retrieve the LVDS mode from the panel node and configure the LVDS
encoder accordingly. LVDS mode selection is static as LVDS panels can't
be hot-plugged on any of the device supported by the driver. Support for
dynamic mode selection can be implemented in the future if needed
without any impact on the DT bindings.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c | 29 +
drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 11 +--
drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h | 13 +
3 files changed, 51 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c
b/drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c
index 64e9f0b86e58..71a70b06f16b 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c
@@ -24,6 +24,7 @@
#include "rcar_du_encoder.h"
#include "rcar_du_kms.h"
#include "rcar_du_lvdscon.h"
+#include "rcar_du_lvdsenc.h"
struct rcar_du_lvds_connector {
struct rcar_du_connector connector;
@@ -33,6 +34,8 @@ struct rcar_du_lvds_connector {
unsigned int height_mm; /* Panel height in mm */
struct videomode mode;
} panel;
+
+ unsigned int mode;
};
#define to_rcar_lvds_connector(c) \
@@ -100,6 +103,32 @@ int rcar_du_lvds_connector_init(struct rcar_du_device
*rcdu,
of_property_read_u32(np, "width-mm", &lvdscon->panel.width_mm);
of_property_read_u32(np, "height-mm", &lvdscon->panel.height_mm);
+ if (of_device_is_compatible(np, "panel-lvds")) {
+ enum rcar_lvds_mode mode = 0;
+ const char *mapping = NULL;
+
+ of_property_read_string(np, "data-mapping", &mapping);
+ if (!mapping) {
+ dev_dbg(rcdu->dev,
+ "required property %s not found in %s node\n",
+ "data-mapping", np->full_name);
+ return -EINVAL;
+ }
+
+ if (!strcmp(mapping, "jeida-18") ||
+ !strcmp(mapping, "jeida-24"))
+ mode = RCAR_LVDS_MODE_JEIDA;
+ else if (!strcmp(mapping, "vesa-24"))
+ mode = RCAR_LVDS_MODE_VESA;
+ else
+ return -EINVAL;
+
+ if (of_find_property(np, "data-mirror", NULL))
+ mode |= RCAR_LVDS_MODE_MIRROR;
+
+ rcar_du_lvdsenc_set_mode(renc->lvds, mode);
+ }
+
connector = &lvdscon->connector.connector;
connector->display_info.width_mm = lvdscon->panel.width_mm;
connector->display_info.height_mm = lvdscon->panel.height_mm;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
b/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
index b74105a80a6e..c8c22850947a 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
@@ -31,6 +31,7 @@ struct rcar_du_lvdsenc {
bool enabled;
enum rcar_lvds_input input;
+ enum rcar_lvds_mode mode;
};
static void rcar_lvds_write(struct rcar_du_lvdsenc *lvds, u32 reg, u32 data)
@@ -61,7 +62,7 @@ static void rcar_du_lvdsenc_start_gen2(struct rcar_du_lvdsenc
*lvds,
/* Select the input, hardcode mode 0, enable LVDS operation and turn
* bias circuitry on.
*/
- lvdcr0 = LVDCR0_BEN | LVDCR0_LVEN;
+ lvdcr0 = (lvds->mode << LVDCR0_LVMD_SHIFT) | LVDCR0_BEN | LVDCR0_LVEN;
if (rcrtc->index == 2)
lvdcr0 |= LVDCR0_DUSEL;
rcar_lvds_write(lvds, LVDCR0, lvdcr0);
@@ -107,7 +108,7 @@ static void rcar_du_lvdsenc_start_gen3(struct
rcar_du_lvdsenc *lvds,
/* Turn the PLL on, set it to LVDS normal mode, wait for the startup
* delay and turn the output on.
*/
- lvdcr0 = LVDCR0_PLLON;
+ lvdcr0 = (lvds->mode << LVDCR0_LVMD_SHIFT) | LVDCR0_PLLON;
rcar_lvds_write(lvds, LVDCR0, lvdcr0);
lvdcr0 |= LVDCR0_PWD;
@@ -210,6 +211,12 @@ void rcar_du_lvdsenc_atomic_check(struct rcar_du_lvdsenc
*lvds,
mode->clock = clamp(mode->clock, 25175, 148500);
}
+void rcar_du_lvdsenc_set_mode(struct rcar_du_lvdsenc *lvds,
+ enum rcar_lvds_mode mode)
+{
+ lvds->mode = mode;
+}
+
static int rcar_du_lvdsenc_get_resources(struct rcar_du_lvdsenc *lvds,
struct platform_device *pdev)
{
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h
b/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h
index dfdba746edf4..7218ac89333e 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h
@@ -26,8 +26,17 @@ enum rcar_lvds_input {
RCAR_LVDS_INPUT_DU2,
};
+/* Keep in sync with the LVDCR0.LVMD hardware register values. */
+enum rcar_lvds_mode {
+ RCAR_LVDS_MODE_JEIDA = 0,
+ RCAR_LVDS_MODE_MIRROR = 1,
+ RCAR_LVDS_MODE_VESA = 4,
+};
+
[PATCH 1/2] devicetree/bindings: display: Add bindings for LVDS panels
LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A.
Multiple incompatible data link layers have been used over time to
transmit image data to LVDS panels. This binding supports display panels
compatible with the JEIDA-59-1999, Open-LDI and VESA SWPG
specifications.
Signed-off-by: Laurent Pinchart
---
.../bindings/display/panel/panel-lvds.txt | 119 +
1 file changed, 119 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/panel-lvds.txt
diff --git a/Documentation/devicetree/bindings/display/panel/panel-lvds.txt
b/Documentation/devicetree/bindings/display/panel/panel-lvds.txt
new file mode 100644
index ..250861f2673e
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/panel-lvds.txt
@@ -0,0 +1,119 @@
+Generic LVDS Panel
+==
+
+LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A. Multiple
+incompatible data link layers have been used over time to transmit image data
+to LVDS panels. This bindings supports display panels compatible with the
+following specifications.
+
+[JEIDA] "Digital Interface Standards for Monitor", JEIDA-59-1999, February
+1999 (Version 1.0), Japan Electronic Industry Development Association (JEIDA)
+[LDI] "Open LVDS Display Interface", May 1999 (Version 0.95), National
+Semiconductor
+[VESA] "VESA Notebook Panel Standard", October 2007 (Version 1.0), Video
+Electronics Standards Association (VESA)
+
+Device compatible with those specifications have been marketed under the
+FPD-Link and FlatLink brands.
+
+
+Required properties:
+- compatible: shall contain "panel-lvds"
+- width-mm: panel display width in millimeters
+- height-mm: panel display height in millimeters
+- data-mapping: the color signals mapping order, "jeida-18", "jeida-24"
+ or "vesa-24"
+
+Optional properties:
+- label: a symbolic name for the panel
+- avdd-supply: reference to the regulator that powers the panel analog supply
+- dvdd-supply: reference to the regulator that powers the panel digital supply
+- data-mirror: if set, reverse the bit order on all data lanes (6 to 0 instead
+ of 0 to 6)
+
+Required nodes:
+- One "panel-timing" node containing video timings, in accordance with the
+ display timing bindings defined in
+ Documentation/devicetree/bindings/display/display-timing.txt.
+- One "port" child node for the LVDS input port, in accordance with the
+ video interface bindings defined in
+ Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+
+LVDS data mappings are defined as follows.
+
+- "jeida-18" - 18-bit data mapping compatible with the [JEIDA], [LDI] and
+ [VESA] specifications. Data are transferred as follows on 3 LVDS lanes.
+
+Slot 0 1 2 3 4 5 6
+ _
+Clock \___/
+ __ __ __ __ __ __ __
+DATA0 ><__G0__><__R5__><__R4__><__R3__><__R2__><__R1__><__R0__><
+DATA1 ><__B1__><__B0__><__G5__><__G4__><__G3__><__G2__><__G1__><
+DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B5__><__B4__><__B3__><__B2__><
+
+- "jeida-24" - 24-bit data mapping compatible with the [DSIM] and [LDI]
+ specifications. Data are transferred as follows on 4 LVDS lanes.
+
+Slot 0 1 2 3 4 5 6
+ _
+Clock \___/
+ __ __ __ __ __ __ __
+DATA0 ><__G2__><__R7__><__R6__><__R5__><__R4__><__R3__><__R2__><
+DATA1 ><__B3__><__B2__><__G7__><__G6__><__G5__><__G4__><__G3__><
+DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B7__><__B6__><__B5__><__B4__><
+DATA3 ><_CTL3_><__B1__><__B0__><__G1__><__G0__><__R1__><__R0__><
+
+- "vesa-24" - 24-bit data mapping compatible with the [VESA] specification.
+ Data are transferred as follows on 4 LVDS lanes.
+
+Slot 0 1 2 3 4 5 6
+ _
+Clock \___/
+ __ __ __ __ __ __ __
+DATA0 ><__G0__><__R5__><__R4__><__R3__><__R2__><__R1__><__R0__><
+DATA1 ><__B1__><__B0__><__G5__><__G4__><__G3__><__G2__><__G1__><
+DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B5__><__B4__><__B3__><__B2__><
+DATA3 ><_CTL3_><__B7__><__B6__><__G7__><__G6__><__R7__><__R6__><
+
+
+Control signals are mapped as follows.
+
+CTL0: HSync
+CTL1: VSync
+CTL2: Data Enable
+CTL3: 0
+
+
+Example
+---
+
+panel {
+ compatible = "mitsubishi,aa121td01", "panel-lvds";
+ label = "lcd";
+
+ width-mm = <261>;
+ height-mm = <163>;
+
+ data-mapping = "jeida-24";
+
+ panel-timing {
+ /* 1280x800 @60Hz */
+ clock-frequency = <7100>;
+ hactive = <1280>;
+ vactive = <800>;
+ hsync-len = <70>
[PATCH 0/2] R-Car DU: Add support for LVDS mode selection
Hello,
This patch series adds support for LVDS mode selection in the R-Car DU driver.
Patch 1/2 defines a new DT binding for LVDS panel. Compared to the existing
DPI panel bindings that are currently abused by the driver for LVDS panel,
this new binding specifies the LVDS more explicitly. Patch 2/2 then adds
support for the new bindings to the driver, retrieving the mode from DT and
configuring the hardware accordingly.
The LVDS panel DT bindings are based on the relevant standards I have been
able to find, as well as on existing LVDS-related code and DT bindings
available in the mainline kernel. Those include
- the LVDS formats MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
MEDIA_BUS_FMT_RGB888_1X7X4_SPWG and MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA
(Documentation/media/uapi/v4l/subdev-formats.rst)
- iMX display DT bindings available in
(Documentation/devicetree/bindings/display/imx/ldb.txt)
- the drivers/gpu/drm/imx/ driver
In addition to the three modes specified in the LVDS panel DT bindings, the
Renesas R-Car DU also supports the following two modes.
Slot 0 1 2 3 4 5 6
_
Clock \___/
__ __ __ __ __ __ __
DATA0 ><_CTL0_><__R7__><__R6__><__R5__><__R4__><__R3__><__R2__><
DATA1 ><_CTL1_><__G7__><__G6__><__G5__><__G4__><__G3__><__G2__><
DATA2 ><_CTL2_><__B7__><__B6__><__B5__><__B4__><__B3__><__B2__><
DATA3 ><_CTL3_><__B1__><__B0__><__G1__><__G0__><__R1__><__R0__><
__ __ __ __ __ __ __
DATA0 ><_CTL0_><__R5__><__R4__><__R3__><__R2__><__R1__><__R0__><
DATA1 ><_CTL1_><__G5__><__G4__><__G3__><__G2__><__G1__><__G0__><
DATA2 ><_CTL2_><__B5__><__B4__><__B3__><__B2__><__B1__><__B0__><
DATA3 ><_CTL3_><__B7__><__B6__><__G7__><__G6__><__R7__><__R6__><
and their mirrored version.
I haven't been able to find any standard defining those data mappings, nor any
panel using them. The control signals positions correspond to DC-balanced LVDS
(see figure 18 on page 19 of http://www.ti.com/lit/ds/symlink/ds90cf388.pdf),
but the R-Car DU doesn't support DC-balanced LVDS as far as I can tell, so
it's not a match. If anyone knows of other devices supporting these data
mappings or of standards defining them I would appreciate the information and
will update the bindings accordingly.
Laurent Pinchart (2):
devicetree/bindings: display: Add bindings for LVDS panels
drm: rcar-du: Add support for LVDS mode selection
.../bindings/display/panel/panel-lvds.txt | 119 +
drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c | 29 +
drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 11 +-
drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h | 13 +++
4 files changed, 170 insertions(+), 2 deletions(-)
create mode 100644
Documentation/devicetree/bindings/display/panel/panel-lvds.txt
--
Regards,
Laurent Pinchart
[Bug 98028] Guns of Icarus Online segfaults on startup since AMDGPU: Partially fix control flow at -O0
https://bugs.freedesktop.org/show_bug.cgi?id=98028 --- Comment #5 from Daniel Scharrer --- Created attachment 127002 --> https://bugs.freedesktop.org/attachment.cgi?id=127002&action=edit Another R600_DEBUG=vs,tcs,tes,gs,ps,cs log Looks like the crashes don't always happen for the same shader. -- 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/20161004/e2cb2cfa/attachment.html>
[Bug 98028] Guns of Icarus Online segfaults on startup since AMDGPU: Partially fix control flow at -O0
https://bugs.freedesktop.org/show_bug.cgi?id=98028 --- Comment #4 from Daniel Scharrer --- Created attachment 127001 --> https://bugs.freedesktop.org/attachment.cgi?id=127001&action=edit R600_DEBUG=vs,tcs,tes,gs,ps,cs log (In reply to Nicolai Hähnle from comment #3) > I haven't been able to reproduce this with Mesa master and LLVM r283219 so > far. Does this happen with clean re-builds? Yes, all LLVM and Mesa builds were done through the package manager, starting with an empty build directory. And I don't use ccache. I just re-checked with an updated LLVM & Mesa and the game still crashes: Mesa: git-0e85ff3 LLVM: r283225 I also verified that it still starts properly with amdgpu-pro (running on top of the upstream 4.7.5 amdgpu module). > If this still happens with current LLVM and clean re-builds, please provide > logs with R600_DEBUG=vs,tcs,tes,gs,ps,cs. > > The wide range of different backtraces suggests that it might be random > memory corruption, so running under Valgrind may also be worth a shot. It does look like it. I'll get a valgrind memcheck log, but will first need to recompile a couple of libraries because valgrind still doesn't support all the instructions of my CPU :/ -- 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/20161004/6d33f460/attachment-0001.html>
[PATCH 3/3] drm/fsl-dcu: enable pixel clock when enabling CRTC
The pixel clock should not be on if the CRTC is not in use, hence
move clock enable/disable calls into CRTC callbacks.
Signed-off-by: Stefan Agner
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 7 +++
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 16 +---
2 files changed, 8 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
index 3371635..4fe0403 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
@@ -51,13 +51,20 @@ static void fsl_dcu_drm_disable_crtc(struct drm_crtc *crtc)
DCU_MODE_DCU_MODE(DCU_MODE_OFF));
regmap_write(fsl_dev->regmap, DCU_UPDATE_MODE,
DCU_UPDATE_MODE_READREG);
+ clk_disable_unprepare(fsl_dev->pix_clk);
}
static void fsl_dcu_drm_crtc_enable(struct drm_crtc *crtc)
{
struct drm_device *dev = crtc->dev;
struct fsl_dcu_drm_device *fsl_dev = dev->dev_private;
+ int ret;
+ ret = clk_prepare_enable(fsl_dev->pix_clk);
+ if (ret < 0) {
+ dev_err(fsl_dev->dev, "failed to enable pix clk\n");
+ return;
+ }
regmap_update_bits(fsl_dev->regmap, DCU_DCU_MODE,
DCU_MODE_DCU_MODE_MASK,
DCU_MODE_DCU_MODE(DCU_MODE_NORMAL));
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
index 0884c45..a6863f9 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
@@ -267,12 +267,6 @@ static int fsl_dcu_drm_pm_resume(struct device *dev)
return ret;
}
- ret = clk_prepare_enable(fsl_dev->pix_clk);
- if (ret < 0) {
- dev_err(dev, "failed to enable pix clk\n");
- goto disable_dcu_clk;
- }
-
fsl_dcu_drm_init_planes(fsl_dev->drm);
drm_atomic_helper_resume(fsl_dev->drm, fsl_dev->state);
@@ -401,18 +395,12 @@ static int fsl_dcu_drm_probe(struct platform_device *pdev)
goto disable_clk;
}
- ret = clk_prepare_enable(fsl_dev->pix_clk);
- if (ret < 0) {
- dev_err(dev, "failed to enable pix clk\n");
- goto unregister_pix_clk;
- }
-
fsl_dev->tcon = fsl_tcon_init(dev);
drm = drm_dev_alloc(driver, dev);
if (IS_ERR(drm)) {
ret = PTR_ERR(drm);
- goto disable_pix_clk;
+ goto unregister_pix_clk;
}
fsl_dev->dev = dev;
@@ -433,8 +421,6 @@ static int fsl_dcu_drm_probe(struct platform_device *pdev)
unref:
drm_dev_unref(drm);
-disable_pix_clk:
- clk_disable_unprepare(fsl_dev->pix_clk);
unregister_pix_clk:
clk_unregister(fsl_dev->pix_clk);
disable_clk:
--
2.10.0
[PATCH 2/3] drm/fsl-dcu: do not explicitly transfer registers on plane init
There is no need to explicitly initiate a register transfer and turn off the DCU after initializing the plane registers. In fact, this is harmful and leads to unnecessary flickers if the DCU has been left on by the bootloader. Signed-off-by: Stefan Agner --- If you could give this and 3/3 a try on LS1021a I would be glad. Since those are fixes I would like to send them for v4.9... drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c | 5 - 1 file changed, 5 deletions(-) diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c index a7e5486..9e6f7d8 100644 --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c @@ -211,11 +211,6 @@ void fsl_dcu_drm_init_planes(struct drm_device *dev) for (j = 1; j <= fsl_dev->soc->layer_regs; j++) regmap_write(fsl_dev->regmap, DCU_CTRLDESCLN(i, j), 0); } - regmap_update_bits(fsl_dev->regmap, DCU_DCU_MODE, - DCU_MODE_DCU_MODE_MASK, - DCU_MODE_DCU_MODE(DCU_MODE_OFF)); - regmap_write(fsl_dev->regmap, DCU_UPDATE_MODE, -DCU_UPDATE_MODE_READREG); } struct drm_plane *fsl_dcu_drm_primary_create_plane(struct drm_device *dev) -- 2.10.0
[PATCH 1/3] drm/fsl-dcu: enable TCON bypass mode by default
Do not use encoder disable/enable callbacks to control bypass
mode as this seems to mess with the signals not liked by
displays. This also makes more sense since the encoder is
already defined to be parallel RGB/LVDS at creation time.
Signed-off-by: Stefan Agner
---
I tested that on Vybrid. Meng, since LS1021a does not use TCON this
should not affect LS1021a, so I think we are fine.
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 24
1 file changed, 4 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
index 26edcc8..e26c820 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
@@ -28,28 +28,8 @@ fsl_dcu_drm_encoder_atomic_check(struct drm_encoder *encoder,
return 0;
}
-static void fsl_dcu_drm_encoder_disable(struct drm_encoder *encoder)
-{
- struct drm_device *dev = encoder->dev;
- struct fsl_dcu_drm_device *fsl_dev = dev->dev_private;
-
- if (fsl_dev->tcon)
- fsl_tcon_bypass_disable(fsl_dev->tcon);
-}
-
-static void fsl_dcu_drm_encoder_enable(struct drm_encoder *encoder)
-{
- struct drm_device *dev = encoder->dev;
- struct fsl_dcu_drm_device *fsl_dev = dev->dev_private;
-
- if (fsl_dev->tcon)
- fsl_tcon_bypass_enable(fsl_dev->tcon);
-}
-
static const struct drm_encoder_helper_funcs encoder_helper_funcs = {
.atomic_check = fsl_dcu_drm_encoder_atomic_check,
- .disable = fsl_dcu_drm_encoder_disable,
- .enable = fsl_dcu_drm_encoder_enable,
};
static void fsl_dcu_drm_encoder_destroy(struct drm_encoder *encoder)
@@ -68,6 +48,10 @@ int fsl_dcu_drm_encoder_create(struct fsl_dcu_drm_device
*fsl_dev,
int ret;
encoder->possible_crtcs = 1;
+
+ /* Use bypass mode for parallel RGB/LVDS encoder */
+ fsl_tcon_bypass_enable(fsl_dev->tcon);
+
ret = drm_encoder_init(fsl_dev->drm, encoder, &encoder_funcs,
DRM_MODE_ENCODER_LVDS, NULL);
if (ret < 0)
--
2.10.0
[PATCH] drm/atomic-helper: add unlocked disable all outputs helper
Hi Lucas,
On Fri, Aug 12, 2016 at 11:07:14AM +0200, Lucas Stach wrote:
>This adds the unlocked variant of drm_atomic_helper_disable_all(),
>which takes all the required modeset locks itself. This is intended
>to be used when shutting down the driver, without retaining any
>state.
>
Is this meant to be analogous to:
drm_for_each_plane(plane, dev)
drm_plane_force_disable(plane);
drm_for_each_crtc(crtc, dev)
drm_crtc_force_disable(crtc);
?
I may have misunderstood the intention here, but it seems like this
patch only disables the outputs and doesn't disable planes or
remove their framebuffers (which I think we'd want for driver
shutdown).
Thanks,
Brian
>Signed-off-by: Lucas Stach
>---
> drivers/gpu/drm/drm_atomic_helper.c | 43 +
> include/drm/drm_atomic_helper.h | 1 +
> 2 files changed, 44 insertions(+)
>
>diff --git a/drivers/gpu/drm/drm_atomic_helper.c
>b/drivers/gpu/drm/drm_atomic_helper.c
>index 99365087645b..6673021ab21e 100644
>--- a/drivers/gpu/drm/drm_atomic_helper.c
>+++ b/drivers/gpu/drm/drm_atomic_helper.c
>@@ -2435,6 +2435,49 @@ free:
> EXPORT_SYMBOL(drm_atomic_helper_disable_all);
>
> /**
>+ * drm_atomic_helper_disable_all_unlocked - disable all currently active
>+ * outputs taking the modeset locks itself
>+ * @dev: DRM device
>+ *
>+ * Loops through all connectors, finding those that aren't turned off and then
>+ * turns them off by setting their DPMS mode to OFF and deactivating the CRTC
>+ * that they are connected to.
>+ *
>+ * This is used for example when shutting down the DRM device.
>+ *
>+ * Returns:
>+ * 0 on success or a negative error code on failure.
>+ */
>+int drm_atomic_helper_disable_all_unlocked(struct drm_device *dev)
>+{
>+ struct drm_modeset_acquire_ctx ctx;
>+ int err;
>+
>+ drm_modeset_acquire_init(&ctx, 0);
>+
>+retry:
>+ err = drm_modeset_lock_all_ctx(dev, &ctx);
>+ if (err < 0)
>+ goto unlock;
>+
>+ err = drm_atomic_helper_disable_all(dev, &ctx);
>+ if (err < 0)
>+ goto unlock;
>+
>+unlock:
>+ if (err == -EDEADLK) {
>+ drm_modeset_backoff(&ctx);
>+ goto retry;
>+ }
>+
>+ drm_modeset_drop_locks(&ctx);
>+ drm_modeset_acquire_fini(&ctx);
>+
>+ return err;
>+}
>+EXPORT_SYMBOL(drm_atomic_helper_disable_all_unlocked);
>+
>+/**
> * drm_atomic_helper_suspend - subsystem-level suspend helper
> * @dev: DRM device
> *
>diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h
>index d86ae5dcd7b4..104d310c2c70 100644
>--- a/include/drm/drm_atomic_helper.h
>+++ b/include/drm/drm_atomic_helper.h
>@@ -99,6 +99,7 @@ int __drm_atomic_helper_set_config(struct drm_mode_set *set,
>
> int drm_atomic_helper_disable_all(struct drm_device *dev,
> struct drm_modeset_acquire_ctx *ctx);
>+int drm_atomic_helper_disable_all_unlocked(struct drm_device *dev);
> struct drm_atomic_state *drm_atomic_helper_suspend(struct drm_device *dev);
> int drm_atomic_helper_resume(struct drm_device *dev,
>struct drm_atomic_state *state);
>--
>2.8.1
>
>___
>dri-devel mailing list
>dri-devel at lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 2/2] drm/panel: simple: add support for Sharp LQ150X1LG11 panels
From: Gustaf Lindström
The Sharp 15" LQ150X1LG11 panel is an XGA TFT LCD panel.
The simple-panel driver is used to get support for essential
functionality of the panel.
Signed-off-by: Gustaf Lindström
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/panel/panel-simple.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 85143d1b9b31..58cfe0a7a9d6 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1386,6 +1386,30 @@ static const struct panel_desc sharp_lq123p1jx31 = {
},
};
+static const struct drm_display_mode sharp_lq150x1lg11_mode = {
+ .clock = 71100,
+ .hdisplay = 1024,
+ .hsync_start = 1024 + 168,
+ .hsync_end = 1024 + 168 + 64,
+ .htotal = 1024 + 168 + 64 + 88,
+ .vdisplay = 768,
+ .vsync_start = 768 + 37,
+ .vsync_end = 768 + 37 + 2,
+ .vtotal = 768 + 37 + 2 + 8,
+ .vrefresh = 60,
+};
+
+static const struct panel_desc sharp_lq150x1lg11 = {
+ .modes = &sharp_lq150x1lg11_mode,
+ .num_modes = 1,
+ .bpc = 8,
+ .size = {
+ .width = 304,
+ .height = 228,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB565_1X16,
+};
+
static const struct drm_display_mode shelly_sca07010_bfn_lnn_mode = {
.clock = 33300,
.hdisplay = 800,
@@ -1641,6 +1665,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "sharp,lq123p1jx31",
.data = &sharp_lq123p1jx31,
}, {
+ .compatible = "sharp,lq150x1lg11",
+ .data = &sharp_lq150x1lg11,
+ }, {
.compatible = "shelly,sca07010-bfn-lnn",
.data = &shelly_sca07010_bfn_lnn,
}, {
--
2.1.4
[PATCH v4 1/2] dt-bindings: display: Add Sharp LQ150X1LG11 panel binding
The Sharp 15" LQ150X1LG11 panel is an XGA TFT LCD panel.
Signed-off-by: Peter Rosin
---
.../bindings/display/panel/sharp,lq150x1lg11.txt | 36 ++
1 file changed, 36 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/sharp,lq150x1lg11.txt
diff --git
a/Documentation/devicetree/bindings/display/panel/sharp,lq150x1lg11.txt
b/Documentation/devicetree/bindings/display/panel/sharp,lq150x1lg11.txt
new file mode 100644
index ..0f57c3143506
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/sharp,lq150x1lg11.txt
@@ -0,0 +1,36 @@
+Sharp 15" LQ150X1LG11 XGA TFT LCD panel
+
+Required properties:
+- compatible: should be "sharp,lq150x1lg11"
+- power-supply: regulator to provide the VCC supply voltage (3.3 volts)
+
+Optional properties:
+- backlight: phandle of the backlight device
+- rlud-gpios: a single GPIO for the RL/UD (rotate 180 degrees) pin.
+- sellvds-gpios: a single GPIO for the SELLVDS pin.
+
+If rlud-gpios and/or sellvds-gpios are not specified, the RL/UD and/or SELLVDS
+pins are assumed to be handled appropriately by the hardware.
+
+Example:
+
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = <&pwm 0 10>; /* VBR */
+
+ brightness-levels = <0 20 40 60 80 100>;
+ default-brightness-level = <2>;
+
+ power-supply = <&vdd_12v_reg>; /* VDD */
+ enable-gpios = <&gpio 42 GPIO_ACTIVE_HIGH>; /* XSTABY */
+ };
+
+ panel {
+ compatible = "sharp,lq150x1lg11";
+
+ power-supply = <&vcc_3v3_reg>; /* VCC */
+
+ backlight = <&backlight>;
+ rlud-gpios = <&gpio 17 GPIO_ACTIVE_HIGH>;/* RL/UD */
+ sellvds-gpios = <&gpio 18 GPIO_ACTIVE_HIGH>; /* SELLVDS */
+ };
--
2.1.4
[PATCH v4 0/2] drm/panel: simple: add support for Sharp LQ150X1LG11 panels
Hi! New attempt to get this upstreamed. v4 addresses review comments from Rob (lvds -> sellvds and a couple of typos). Cheers, Peter Gustaf Lindström (1): drm/panel: simple: add support for Sharp LQ150X1LG11 panels Peter Rosin (1): dt-bindings: display: Add Sharp LQ150X1LG11 panel binding .../bindings/display/panel/sharp,lq150x1lg11.txt | 36 ++ drivers/gpu/drm/panel/panel-simple.c | 27 2 files changed, 63 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/sharp,lq150x1lg11.txt -- 2.1.4
Unix Device Memory Allocation project
Hello everyone, As many are aware, we took up the issue of surface/memory allocation at XDC this year. The outcome of that discussion was the beginnings of a design proposal for a library that would server as a cross-device, cross-process surface allocator. In the past week I've started to condense some of my notes from that discussion down to code & a design document. I've posted the first pieces to a github repository here: https://github.com/cubanismo/allocator This isn't anything close to usable code yet. Just headers and docs, and incomplete ones at that. However, feel free to check it out if you're interested in discussing the design. Thanks, -James
[Bug 98002] Mud rendering bug in Portal 2
https://bugs.freedesktop.org/show_bug.cgi?id=98002 --- Comment #1 from Nicolai Hähnle --- Thank you for the report. I can reproduce this and will investigate. -- 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/20161004/c307b6cf/attachment-0001.html>
[Bug 97988] [radeonsi] playing back videos with VDPAU exhibits deinterlacing/anti-aliasing issues not visible with VA-API
https://bugs.freedesktop.org/show_bug.cgi?id=97988 --- Comment #16 from Nicolai Hähnle --- Looks like we'd need the opposite of the convergent attribute. And that attribute should only apply to one argument of the texture sampling intrinsic (i.e. not to the texture coordinate). I don't know if something like that already exists in LLVM. -- 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/20161004/d405ca5c/attachment.html>
[Bug 94900] HD6950 GPU lockup loop with various steam games (octodad[always], saints row 4[always], dead island[always], grid autosport[sometimes])
https://bugs.freedesktop.org/show_bug.cgi?id=94900 --- Comment #33 from Marek Olšák --- The EVENT_WRITE errors are from a different issue that should be fixed in master now. -- 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/20161004/aa7040b4/attachment.html>
[Bug 97500] Cannot unbind GPU from AMDGPU
https://bugs.freedesktop.org/show_bug.cgi?id=97500
Andreas Grosse changed:
What|Removed |Added
CC||m-bugs-freedesktop at andig.ne
||t
--- Comment #7 from Andreas Grosse ---
Created attachment 126997
--> https://bugs.freedesktop.org/attachment.cgi?id=126997&action=edit
dmesg: boot then unbind
I am getting a kernel panic with Linux 4.8.0 when I unbind my RX480 (XFX Radeon
RX 480 GTR Black 8GB, if that helps) from amdgpu. The system freezes
immediately and only pushes this to the serial console (which is why it is not
in the attached dmesg):
[ 80.266963] {1}[Hardware Error]: event severity: fatal
[ 80.266964] {1}[Hardware Error]: Error 0, type: fatal
[ 80.266964] {1}[Hardware Error]: section_type: PCIe error
[ 80.266964] {1}[Hardware Error]: port_type: 4, root port
[ 80.266965] {1}[Hardware Error]: version: 1.16
[ 80.266965] {1}[Hardware Error]: command: 0x4010, status: 0x0547
[ 80.266965] {1}[Hardware Error]: device_id: :00:01.0
[ 80.266966] {1}[Hardware Error]: slot: 0
[ 80.266966] {1}[Hardware Error]: secondary_bus: 0x01
[ 80.266966] {1}[Hardware Error]: vendor_id: 0x8086, device_id: 0x0c01
[ 80.266967] {1}[Hardware Error]: class_code: 000406
[ 80.266967] {1}[Hardware Error]: bridge: secondary_status: 0x2000,
control: 0x0003
[ 80.266967] Kernel panic - not syncing: Fatal hardware error!
[ 80.705884] Kernel Offset: disabled
Is this the same issue?
I have attached the kernel output from boot until I got the panic after
unbinding with this command:
echo :01:00.0 > /sys/bus/pci/drivers/amdgpu/unbind
Is there any further information that I can provide to address this issue?
--
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/20161004/269e98ec/attachment.html>
[Bug 97988] [radeonsi] playing back videos with VDPAU exhibits deinterlacing/anti-aliasing issues not visible with VA-API
https://bugs.freedesktop.org/show_bug.cgi?id=97988 --- Comment #15 from Marek Olšák --- Created attachment 126996 --> https://bugs.freedesktop.org/attachment.cgi?id=126996&action=edit piglit test The attached test reproduces the issue. CFGSimplificationPass is the culprit. Note that CFGSimplificationPass also doesn't preserve the !amdgpu.uniform metadata when transforming the loads, which is a change in behavior. -- 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/20161004/de93aa47/attachment.html>
[Bug 98028] Guns of Icarus Online segfaults on startup since AMDGPU: Partially fix control flow at -O0
https://bugs.freedesktop.org/show_bug.cgi?id=98028 --- Comment #3 from Nicolai Hähnle --- I haven't been able to reproduce this with Mesa master and LLVM r283219 so far. Does this happen with clean re-builds? If this still happens with current LLVM and clean re-builds, please provide logs with R600_DEBUG=vs,tcs,tes,gs,ps,cs. The wide range of different backtraces suggests that it might be random memory corruption, so running under Valgrind may also be worth a shot. -- 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/20161004/5f750feb/attachment.html>
[PATCH 6/6] drm: rcar-du: Fix crash in encoder failure error path
When an encoder fails to initialize the driver prints an error message to the kernel log. The message contains the name of the encoder's DT node, which is NULL for internal encoders. Use the of_node_full_name() macro to avoid dereferencing a NULL pointer, print the output number to add more context to the error, and make sure we still own a reference to the encoder's DT node by delaying the of_node_put() call. Signed-off-by: Laurent Pinchart --- drivers/gpu/drm/rcar-du/rcar_du_kms.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c b/drivers/gpu/drm/rcar-du/rcar_du_kms.c index bd9c3bb9252c..d3ab10602e3e 100644 --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c @@ -445,13 +445,13 @@ static int rcar_du_encoders_init_one(struct rcar_du_device *rcdu, } ret = rcar_du_encoder_init(rcdu, enc_type, output, encoder, connector); - of_node_put(encoder); - of_node_put(connector); - if (ret && ret != -EPROBE_DEFER) dev_warn(rcdu->dev, -"failed to initialize encoder %s (%d), skipping\n", -encoder->full_name, ret); +"failed to initialize encoder %s on output %u (%d), skipping\n", +of_node_full_name(encoder), output, ret); + + of_node_put(encoder); + of_node_put(connector); return ret; } -- Regards, Laurent Pinchart
[PATCH 5/6] drm: rcar-du: Remove memory allocation error message
Memory allocation failures print messages to the kernel log, there's no
need to print an extra one. Remove the duplicate message.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
b/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
index ef3a50321ecc..b74105a80a6e 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
@@ -241,10 +241,8 @@ int rcar_du_lvdsenc_init(struct rcar_du_device *rcdu)
for (i = 0; i < rcdu->info->num_lvds; ++i) {
lvds = devm_kzalloc(&pdev->dev, sizeof(*lvds), GFP_KERNEL);
- if (lvds == NULL) {
- dev_err(&pdev->dev, "failed to allocate private
data\n");
+ if (lvds == NULL)
return -ENOMEM;
- }
lvds->dev = rcdu;
lvds->index = i;
--
Regards,
Laurent Pinchart
[PATCH 4/6] drm: rcar-du: Remove test for impossible error condition
The driver has lost platform data support a long time ago. R-Car DU
devices can only be instantiated through DT now, making it impossible to
have a NULL DT node pointer. Remove the error check.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index 73c971e39b1c..b619a8024ec9 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -294,17 +294,11 @@ static int rcar_du_remove(struct platform_device *pdev)
static int rcar_du_probe(struct platform_device *pdev)
{
- struct device_node *np = pdev->dev.of_node;
struct rcar_du_device *rcdu;
struct drm_device *ddev;
struct resource *mem;
int ret;
- if (np == NULL) {
- dev_err(&pdev->dev, "no device tree node\n");
- return -ENODEV;
- }
-
/* Allocate and initialize the DRM and R-Car device structures. */
rcdu = devm_kzalloc(&pdev->dev, sizeof(*rcdu), GFP_KERNEL);
if (rcdu == NULL)
--
Regards,
Laurent Pinchart
[PATCH 3/6] drm: rcar-du: Bring HDMI encoder comments in line with the driver
Capitalize acronyms and use determiners and punctuation. Signed-off-by: Laurent Pinchart --- drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c b/drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c index e03004f4588d..f9515f53cc5b 100644 --- a/drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c +++ b/drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c @@ -108,7 +108,7 @@ int rcar_du_hdmienc_init(struct rcar_du_device *rcdu, if (hdmienc == NULL) return -ENOMEM; - /* Locate drm bridge from the hdmi encoder DT node */ + /* Locate the DRM bridge from the HDMI encoder DT node. */ bridge = of_drm_find_bridge(np); if (!bridge) return -EPROBE_DEFER; @@ -123,7 +123,7 @@ int rcar_du_hdmienc_init(struct rcar_du_device *rcdu, renc->hdmi = hdmienc; hdmienc->renc = renc; - /* Link drm_bridge to encoder */ + /* Link the bridge to the encoder. */ bridge->encoder = encoder; encoder->bridge = bridge; -- Regards, Laurent Pinchart
[PATCH 2/6] drm: rcar-du: Constify node argument to rcar_du_lvds_connector_init()
The node passed as a pointer to the rcar_du_lvds_connector_init()
function is never modified, make it const.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c | 2 +-
drivers/gpu/drm/rcar-du/rcar_du_lvdscon.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
Cc: David Airlie
Cc: Tomi Valkeinen
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c
b/drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c
index 6afd0af312ba..64e9f0b86e58 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c
@@ -79,7 +79,7 @@ static const struct drm_connector_funcs connector_funcs = {
int rcar_du_lvds_connector_init(struct rcar_du_device *rcdu,
struct rcar_du_encoder *renc,
- /* TODO const */ struct device_node *np)
+ const struct device_node *np)
{
struct drm_encoder *encoder = rcar_encoder_to_drm_encoder(renc);
struct rcar_du_lvds_connector *lvdscon;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_lvdscon.h
b/drivers/gpu/drm/rcar-du/rcar_du_lvdscon.h
index d4881ee0be7e..639071dd235c 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_lvdscon.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_lvdscon.h
@@ -19,6 +19,6 @@ struct rcar_du_encoder;
int rcar_du_lvds_connector_init(struct rcar_du_device *rcdu,
struct rcar_du_encoder *renc,
- struct device_node *np);
+ const struct device_node *np);
#endif /* __RCAR_DU_LVDSCON_H__ */
--
Regards,
Laurent Pinchart
[PATCH 1/6] video: of: Constify node argument to display timing functions
The node pointer passed to the display timing functions is never
modified, make it const.
Signed-off-by: Laurent Pinchart
---
drivers/video/of_display_timing.c | 6 +++---
include/video/of_display_timing.h | 15 ---
2 files changed, 11 insertions(+), 10 deletions(-)
Cc: David Airlie
Cc: Tomi Valkeinen
diff --git a/drivers/video/of_display_timing.c
b/drivers/video/of_display_timing.c
index 8a1076beecd3..26c88f7839d2 100644
--- a/drivers/video/of_display_timing.c
+++ b/drivers/video/of_display_timing.c
@@ -110,7 +110,7 @@ static int of_parse_display_timing(const struct device_node
*np,
* @name: name of the timing node
* @dt: display_timing struct to fill
**/
-int of_get_display_timing(struct device_node *np, const char *name,
+int of_get_display_timing(const struct device_node *np, const char *name,
struct display_timing *dt)
{
struct device_node *timing_np;
@@ -133,7 +133,7 @@ EXPORT_SYMBOL_GPL(of_get_display_timing);
* of_get_display_timings - parse all display_timing entries from a device_node
* @np: device_node with the subnodes
**/
-struct display_timings *of_get_display_timings(struct device_node *np)
+struct display_timings *of_get_display_timings(const struct device_node *np)
{
struct device_node *timings_np;
struct device_node *entry;
@@ -249,7 +249,7 @@ EXPORT_SYMBOL_GPL(of_get_display_timings);
* of_display_timings_exist - check if a display-timings node is provided
* @np: device_node with the timing
**/
-int of_display_timings_exist(struct device_node *np)
+int of_display_timings_exist(const struct device_node *np)
{
struct device_node *timings_np;
diff --git a/include/video/of_display_timing.h
b/include/video/of_display_timing.h
index ea755b5616d8..956455fc9f9a 100644
--- a/include/video/of_display_timing.h
+++ b/include/video/of_display_timing.h
@@ -16,21 +16,22 @@ struct display_timings;
#define OF_USE_NATIVE_MODE -1
#ifdef CONFIG_OF
-int of_get_display_timing(struct device_node *np, const char *name,
+int of_get_display_timing(const struct device_node *np, const char *name,
struct display_timing *dt);
-struct display_timings *of_get_display_timings(struct device_node *np);
-int of_display_timings_exist(struct device_node *np);
+struct display_timings *of_get_display_timings(const struct device_node *np);
+int of_display_timings_exist(const struct device_node *np);
#else
-static inline int of_get_display_timing(struct device_node *np, const char
*name,
- struct display_timing *dt)
+static inline int of_get_display_timing(const struct device_node *np,
+ const char *name, struct display_timing *dt)
{
return -ENOSYS;
}
-static inline struct display_timings *of_get_display_timings(struct
device_node *np)
+static inline struct display_timings *
+of_get_display_timings(const struct device_node *np)
{
return NULL;
}
-static inline int of_display_timings_exist(struct device_node *np)
+static inline int of_display_timings_exist(const struct device_node *np)
{
return -ENOSYS;
}
--
Regards,
Laurent Pinchart
[PATCH 0/6] R-Car DU fixes and cleanups
Hello, This patch series contains five simple cleanups and fixes for the rcar-du-drm driver, as well as an argument constification patch for video/of. The patches themselves are straightforward, see individual commit messages for details. Patch 2/6 (normally merged through the DRM tree) depends on patch 1/6 (normally merged through the fbdev tree). As they don't conflict with patches 3/6 to 6/6, we can either merge the whole series through the DRM tree, or merge patches 1/6 and 2/6 through the fbdev tree and the rest through the DRM tree. My preference would go for merging the whole series through the DRM tree to avoid potential conflicts with the other patches I'm working on for v4.10. There is no foreseen conflict at the moment, but I might rework encoder handling in the driver that could possibly result in a conflict. Dave, Tomi, any preference ? If you're fine with patches not going through your tree, could you please ack them ? Cc: David Airlie Cc: Tomi Valkeinen Laurent Pinchart (6): video: of: Constify node argument to display timing functions drm: rcar-du: Constify node argument to rcar_du_lvds_connector_init() drm: rcar-du: Bring HDMI encoder comments in line with the driver drm: rcar-du: Remove test for impossible error condition drm: rcar-du: Remove memory allocation error message drm: rcar-du: Fix crash in encoder failure error path drivers/gpu/drm/rcar-du/rcar_du_drv.c | 6 -- drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c | 4 ++-- drivers/gpu/drm/rcar-du/rcar_du_kms.c | 10 +- drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c | 2 +- drivers/gpu/drm/rcar-du/rcar_du_lvdscon.h | 2 +- drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 4 +--- drivers/video/of_display_timing.c | 6 +++--- include/video/of_display_timing.h | 15 --- 8 files changed, 21 insertions(+), 28 deletions(-) -- Regards, Laurent Pinchart
[Bug 98021] Applications and games crash after opengl version overrides
https://bugs.freedesktop.org/show_bug.cgi?id=98021 Nicolai Hähnle changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID -- 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/20161004/fdde1a63/attachment.html>
[Bug 98021] Applications and games crash after opengl version overrides
https://bugs.freedesktop.org/show_bug.cgi?id=98021 --- Comment #1 from Nicolai Hähnle --- Hi Stepan, it's called an override for a reason. When you enable it, you're operating outside of the supported parameters, and shouldn't be surprised when something crashes. Don't report a bug for something like that. That said, radeonsi has supported OpenGL 4.3 for several months now. For SI-based cards like yours, you need a more recent kernel. The radeon module of older kernels lacks some of the functionality that is required for compute shaders. -- 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/20161004/8fb86498/attachment.html>
[PATCH v8 2/4] drm: Add API for capturing frame CRCs
On Tue, Oct 04, 2016 at 02:23:13PM +0200, Lukas Wunner wrote: > On Tue, Oct 04, 2016 at 01:25:23PM +0200, Daniel Vetter wrote: > > On Tue, Oct 4, 2016 at 12:10 PM, Jon Hunter wrote: > > > Looks like crtc is a errno in the above case. I see this function is > > > called by looping through all the crtc and we never check to see if > > > they are valid. Should we? > > nouveau is exploding as well on driver load! > > > Tegra is still using the load/unload hooks. That didn't mesh well with > > Tomeu's patches (and Tomeu's patches have been thrown out meanwhile > > because of that). > > They're still on drm-intel-nightly, please revert if they're broken. Never mind, I hadn't rebased on today's drm-intel-nightly yet, I see it's gone now. Thanks, Lukas
[Bug 98037] HD6450 KMS failure
https://bugs.freedesktop.org/show_bug.cgi?id=98037 --- Comment #5 from Alex Deucher --- (In reply to Will Lewis from comment #4) > The error occurs before I even get to X. This machine boots to a console > login screen, at which point I login and potentially start X. However, > during the initial boot, I get kernel output until the radeon module gets > loaded, at which point the screen goes blank and tells me it has no signal. > > Do you want me to try to start X in the dark, so to speak, and grab the log > after rebooting? Yes please. -- 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/20161004/bcd35f74/attachment.html>
[Bug 98037] HD6450 KMS failure
https://bugs.freedesktop.org/show_bug.cgi?id=98037 --- Comment #4 from Will Lewis --- The error occurs before I even get to X. This machine boots to a console login screen, at which point I login and potentially start X. However, during the initial boot, I get kernel output until the radeon module gets loaded, at which point the screen goes blank and tells me it has no signal. Do you want me to try to start X in the dark, so to speak, and grab the log after rebooting? -- 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/20161004/d9296cda/attachment.html>
[PATCH v8 2/4] drm: Add API for capturing frame CRCs
On Tue, Oct 04, 2016 at 01:25:23PM +0200, Daniel Vetter wrote: > On Tue, Oct 4, 2016 at 12:10 PM, Jon Hunter wrote: > > Looks like crtc is a errno in the above case. I see this function is > > called by looping through all the crtc and we never check to see if > > they are valid. Should we? nouveau is exploding as well on driver load! > Tegra is still using the load/unload hooks. That didn't mesh well with > Tomeu's patches (and Tomeu's patches have been thrown out meanwhile > because of that). They're still on drm-intel-nightly, please revert if they're broken. Thanks, Lukas
[Bug 98025] [radeonsi] incorrect primitive restart index used
https://bugs.freedesktop.org/show_bug.cgi?id=98025 Marek Olšák changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Marek Olšák --- Pushed as e33f31d61f5e9019f8b0bac0378dfb8fd1147421. Thanks for the patch. Closing. -- 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/20161004/f7bda09f/attachment.html>
[Bug 98037] HD6450 KMS failure
https://bugs.freedesktop.org/show_bug.cgi?id=98037 --- Comment #3 from Alex Deucher --- Please attach your xorg log as well. -- 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/20161004/c2e5ee4c/attachment.html>
[Bug 98028] Guns of Icarus Online segfaults on startup since AMDGPU: Partially fix control flow at -O0
https://bugs.freedesktop.org/show_bug.cgi?id=98028 --- Comment #2 from Daniel Scharrer --- Created attachment 126992 --> https://bugs.freedesktop.org/attachment.cgi?id=126992&action=edit Backtraces recorded for the crashes Here is a list of backtraces I have seen - it's probably not complete. -- 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/20161004/5a9efc5c/attachment-0001.html>
[PATCH v10 3/3] SMAF: add test secure module
This module is allow testing secure calls of SMAF.
Signed-off-by: Benjamin Gaignard
---
drivers/smaf/Kconfig | 6 +++
drivers/smaf/Makefile | 1 +
drivers/smaf/smaf-testsecure.c | 90 ++
3 files changed, 97 insertions(+)
create mode 100644 drivers/smaf/smaf-testsecure.c
diff --git a/drivers/smaf/Kconfig b/drivers/smaf/Kconfig
index cfdfffd..73f2ebf 100644
--- a/drivers/smaf/Kconfig
+++ b/drivers/smaf/Kconfig
@@ -9,3 +9,9 @@ config SMAF_CMA
depends on SMAF
help
Choose this option to enable CMA allocation within SMAF
+
+config SMAF_TEST_SECURE
+ tristate "SMAF secure module for test"
+ depends on SMAF
+ help
+ Choose this option to enable secure module for test purpose
diff --git a/drivers/smaf/Makefile b/drivers/smaf/Makefile
index 05bab01b..bca6b9c 100644
--- a/drivers/smaf/Makefile
+++ b/drivers/smaf/Makefile
@@ -1,2 +1,3 @@
obj-$(CONFIG_SMAF) += smaf-core.o
obj-$(CONFIG_SMAF_CMA) += smaf-cma.o
+obj-$(CONFIG_SMAF_TEST_SECURE) += smaf-testsecure.o
diff --git a/drivers/smaf/smaf-testsecure.c b/drivers/smaf/smaf-testsecure.c
new file mode 100644
index 000..823d0dc
--- /dev/null
+++ b/drivers/smaf/smaf-testsecure.c
@@ -0,0 +1,90 @@
+/*
+ * smaf-testsecure.c
+ *
+ * Copyright (C) Linaro SA 2015
+ * Author: Benjamin Gaignard for Linaro.
+ * License terms: GNU General Public License (GPL), version 2
+ */
+#include
+#include
+#include
+
+#define MAGIC 0xDEADBEEF
+
+struct test_private {
+ int magic;
+};
+
+#define to_priv(x) (struct test_private *)(x)
+
+static void *smaf_testsecure_create(void)
+{
+ struct test_private *priv;
+
+ priv = kzalloc(sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return NULL;
+
+ priv->magic = MAGIC;
+
+ return priv;
+}
+
+static int smaf_testsecure_destroy(void *ctx)
+{
+ struct test_private *priv = to_priv(ctx);
+
+ WARN_ON(!priv || (priv->magic != MAGIC));
+ kfree(priv);
+
+ return 0;
+}
+
+static bool smaf_testsecure_grant_access(void *ctx,
+struct device *dev,
+size_t addr, size_t size,
+enum dma_data_direction direction)
+{
+ struct test_private *priv = to_priv(ctx);
+
+ WARN_ON(!priv || (priv->magic != MAGIC));
+ pr_debug("grant requested by device %s\n",
+dev->driver ? dev->driver->name : "cpu");
+
+ return priv->magic == MAGIC;
+}
+
+static void smaf_testsecure_revoke_access(void *ctx,
+ struct device *dev,
+ size_t addr, size_t size,
+ enum dma_data_direction direction)
+{
+ struct test_private *priv = to_priv(ctx);
+
+ WARN_ON(!priv || (priv->magic != MAGIC));
+ pr_debug("revoke requested by device %s\n",
+dev->driver ? dev->driver->name : "cpu");
+}
+
+static struct smaf_secure test = {
+ .create_ctx = smaf_testsecure_create,
+ .destroy_ctx = smaf_testsecure_destroy,
+ .grant_access = smaf_testsecure_grant_access,
+ .revoke_access = smaf_testsecure_revoke_access,
+};
+
+static int __init smaf_testsecure_init(void)
+{
+ return smaf_register_secure(&test);
+}
+module_init(smaf_testsecure_init);
+
+static void __exit smaf_testsecure_deinit(void)
+{
+ smaf_unregister_secure(&test);
+}
+module_exit(smaf_testsecure_deinit);
+
+MODULE_DESCRIPTION("SMAF secure module for test purpose");
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Benjamin Gaignard ");
--
1.9.1
[PATCH v10 2/3] SMAF: add CMA allocator
SMAF CMA allocator implement helpers functions to allow SMAF
to allocate contiguous memory.
match() each if at least one of the attached devices have coherent_dma_mask
set to DMA_BIT_MASK(32).
For allocation it use dma_alloc_attrs() with DMA_ATTR_WRITE_COMBINE and not
dma_alloc_writecombine to be compatible with ARM 64bits architecture
Signed-off-by: Benjamin Gaignard
---
drivers/smaf/Kconfig| 6 ++
drivers/smaf/Makefile | 1 +
drivers/smaf/smaf-cma.c | 186
3 files changed, 193 insertions(+)
create mode 100644 drivers/smaf/smaf-cma.c
diff --git a/drivers/smaf/Kconfig b/drivers/smaf/Kconfig
index d36651a..cfdfffd 100644
--- a/drivers/smaf/Kconfig
+++ b/drivers/smaf/Kconfig
@@ -3,3 +3,9 @@ config SMAF
depends on DMA_SHARED_BUFFER
help
Choose this option to enable Secure Memory Allocation Framework
+
+config SMAF_CMA
+ tristate "SMAF CMA allocator"
+ depends on SMAF
+ help
+ Choose this option to enable CMA allocation within SMAF
diff --git a/drivers/smaf/Makefile b/drivers/smaf/Makefile
index 40cd882..05bab01b 100644
--- a/drivers/smaf/Makefile
+++ b/drivers/smaf/Makefile
@@ -1 +1,2 @@
obj-$(CONFIG_SMAF) += smaf-core.o
+obj-$(CONFIG_SMAF_CMA) += smaf-cma.o
diff --git a/drivers/smaf/smaf-cma.c b/drivers/smaf/smaf-cma.c
new file mode 100644
index 000..6c9840b
--- /dev/null
+++ b/drivers/smaf/smaf-cma.c
@@ -0,0 +1,186 @@
+/*
+ * smaf-cma.c
+ *
+ * Copyright (C) Linaro SA 2015
+ * Author: Benjamin Gaignard for Linaro.
+ * License terms: GNU General Public License (GPL), version 2
+ */
+
+#include
+#include
+#include
+#include
+
+struct smaf_cma_buffer_info {
+ struct device *dev;
+ size_t size;
+ void *vaddr;
+ dma_addr_t paddr;
+};
+
+/**
+ * find_matching_device - iterate over the attached devices to find one
+ * with coherent_dma_mask correctly set to DMA_BIT_MASK(32).
+ * Matching device (if any) will be used to aim CMA area.
+ */
+static struct device *find_matching_device(struct dma_buf *dmabuf)
+{
+ struct dma_buf_attachment *attach_obj;
+
+ list_for_each_entry(attach_obj, &dmabuf->attachments, node) {
+ if (attach_obj->dev->coherent_dma_mask == DMA_BIT_MASK(32))
+ return attach_obj->dev;
+ }
+
+ return NULL;
+}
+
+/**
+ * smaf_cma_match - return true if at least one device has been found
+ */
+static bool smaf_cma_match(struct dma_buf *dmabuf)
+{
+ return !!find_matching_device(dmabuf);
+}
+
+static void smaf_cma_release(struct dma_buf *dmabuf)
+{
+ struct smaf_cma_buffer_info *info = dmabuf->priv;
+
+ dma_free_attrs(info->dev, info->size, info->vaddr,
+ info->paddr, DMA_ATTR_WRITE_COMBINE);
+
+ kfree(info);
+}
+
+static struct sg_table *smaf_cma_map(struct dma_buf_attachment *attachment,
+enum dma_data_direction direction)
+{
+ struct smaf_cma_buffer_info *info = attachment->dmabuf->priv;
+ struct sg_table *sgt;
+ int ret;
+
+ sgt = kzalloc(sizeof(*sgt), GFP_KERNEL);
+ if (!sgt)
+ return NULL;
+
+ ret = dma_get_sgtable(info->dev, sgt, info->vaddr,
+ info->paddr, info->size);
+ if (ret < 0)
+ goto out;
+
+ sg_dma_address(sgt->sgl) = info->paddr;
+ return sgt;
+
+out:
+ kfree(sgt);
+ return NULL;
+}
+
+static void smaf_cma_unmap(struct dma_buf_attachment *attachment,
+ struct sg_table *sgt,
+ enum dma_data_direction direction)
+{
+ /* do nothing */
+}
+
+static int smaf_cma_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma)
+{
+ struct smaf_cma_buffer_info *info = dmabuf->priv;
+
+ if (info->size < vma->vm_end - vma->vm_start)
+ return -EINVAL;
+
+ vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP;
+ return dma_mmap_attrs(info->dev, vma, info->vaddr, info->paddr,
+ info->size, DMA_ATTR_WRITE_COMBINE);
+}
+
+static void *smaf_cma_vmap(struct dma_buf *dmabuf)
+{
+ struct smaf_cma_buffer_info *info = dmabuf->priv;
+
+ return info->vaddr;
+}
+
+static void *smaf_kmap_atomic(struct dma_buf *dmabuf, unsigned long offset)
+{
+ struct smaf_cma_buffer_info *info = dmabuf->priv;
+
+ return (void *)info->vaddr + offset;
+}
+
+static const struct dma_buf_ops smaf_cma_ops = {
+ .map_dma_buf = smaf_cma_map,
+ .unmap_dma_buf = smaf_cma_unmap,
+ .mmap = smaf_cma_mmap,
+ .release = smaf_cma_release,
+ .kmap_atomic = smaf_kmap_atomic,
+ .kmap = smaf_kmap_atomic,
+ .vmap = smaf_cma_vmap,
+};
+
+static struct dma_buf *smaf_cma_allocate(struct dma_buf *dmabuf, size_t length)
+{
+ struct dma_buf_attachment *attach_obj;
+ struct smaf_cma_buffer_info *info;
+ struct dma_buf *cma_dmabuf;
+
+
[PATCH v10 1/3] create SMAF module
Secure Memory Allocation Framework goal is to be able
to allocate memory that can be securing.
There is so much ways to allocate and securing memory that SMAF
doesn't do it by itself but need help of additional modules.
To be sure to use the correct allocation method SMAF implement
deferred allocation (i.e. allocate memory when only really needed)
Allocation modules (smaf-alloctor.h):
SMAF could manage with multiple allocation modules at same time.
To select the good one SMAF call match() to be sure that a module
can allocate memory for a given list of devices. It is to the module
to check if the devices are compatible or not with it allocation
method.
Securing module (smaf-secure.h):
The way of how securing memory it is done is platform specific.
Secure module is responsible of grant/revoke memory access.
Signed-off-by: Benjamin Gaignard
---
drivers/Kconfig| 2 +
drivers/Makefile | 1 +
drivers/smaf/Kconfig | 5 +
drivers/smaf/Makefile | 1 +
drivers/smaf/smaf-core.c | 818 +
include/linux/smaf-allocator.h | 45 +++
include/linux/smaf-secure.h| 65
include/uapi/linux/smaf.h | 85 +
8 files changed, 1022 insertions(+)
create mode 100644 drivers/smaf/Kconfig
create mode 100644 drivers/smaf/Makefile
create mode 100644 drivers/smaf/smaf-core.c
create mode 100644 include/linux/smaf-allocator.h
create mode 100644 include/linux/smaf-secure.h
create mode 100644 include/uapi/linux/smaf.h
diff --git a/drivers/Kconfig b/drivers/Kconfig
index e1e2066..0697466 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -202,4 +202,6 @@ source "drivers/hwtracing/intel_th/Kconfig"
source "drivers/fpga/Kconfig"
+source "drivers/smaf/Kconfig"
+
endmenu
diff --git a/drivers/Makefile b/drivers/Makefile
index 53abb4a..b129ba1 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -173,3 +173,4 @@ obj-$(CONFIG_STM) += hwtracing/stm/
obj-$(CONFIG_ANDROID) += android/
obj-$(CONFIG_NVMEM)+= nvmem/
obj-$(CONFIG_FPGA) += fpga/
+obj-$(CONFIG_SMAF) += smaf/
diff --git a/drivers/smaf/Kconfig b/drivers/smaf/Kconfig
new file mode 100644
index 000..d36651a
--- /dev/null
+++ b/drivers/smaf/Kconfig
@@ -0,0 +1,5 @@
+config SMAF
+ tristate "Secure Memory Allocation Framework"
+ depends on DMA_SHARED_BUFFER
+ help
+ Choose this option to enable Secure Memory Allocation Framework
diff --git a/drivers/smaf/Makefile b/drivers/smaf/Makefile
new file mode 100644
index 000..40cd882
--- /dev/null
+++ b/drivers/smaf/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_SMAF) += smaf-core.o
diff --git a/drivers/smaf/smaf-core.c b/drivers/smaf/smaf-core.c
new file mode 100644
index 000..1cfd6a7
--- /dev/null
+++ b/drivers/smaf/smaf-core.c
@@ -0,0 +1,818 @@
+/*
+ * smaf-core.c
+ *
+ * Copyright (C) Linaro SA 2015
+ * Author: Benjamin Gaignard for Linaro.
+ * License terms: GNU General Public License (GPL), version 2
+ *
+ * Secure Memory Allocator Framework (SMAF) allow to register memory
+ * allocators and a secure module under a common API.
+ * Multiple allocators can be registered to fit with hardwrae devices
+ * requirement. Each allocator must provide a match() function to check
+ * it capaticity to handle the devices attached (like defined by dmabuf).
+ * Only one secure module can be registered since it dedicated to one
+ * hardware platform.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct smaf_handle {
+ struct dma_buf *dmabuf;
+ struct smaf_allocator *allocator;
+ struct dma_buf *db_alloc;
+ size_t length;
+ unsigned int flags;
+ int fd;
+ atomic_t is_secure;
+ void *secure_ctx;
+};
+
+/**
+ * struct smaf_device - smaf device node private data
+ * @misc_dev: the misc device
+ * @head: list of allocator
+ * @lock: list and secure pointer mutex
+ * @secure:pointer to secure functions helpers
+ */
+struct smaf_device {
+ struct miscdevice misc_dev;
+ struct list_head head;
+ /* list and secure pointer lock*/
+ struct mutex lock;
+ struct smaf_secure *secure;
+};
+
+static long smaf_ioctl(struct file *file, unsigned int cmd, unsigned long arg);
+
+static const struct file_operations smaf_fops = {
+ .unlocked_ioctl = smaf_ioctl,
+};
+
+static struct smaf_device smaf_dev = {
+ .misc_dev.minor = MISC_DYNAMIC_MINOR,
+ .misc_dev.name = "smaf",
+ .misc_dev.fops = &smaf_fops,
+};
+
+static bool have_secure_module(void)
+{
+ return !!smaf_dev.secure;
+}
+
+/**
+ * smaf_grant_access - return true if the specified device can get access
+ * to the memory area
+ *
+ * This function must be called with smaf_dev.lock set
+ */
+static bool smaf_grant_access(struct smaf_handle *handle, struct device *dev,
+
[PATCH v10 0/3] Secure Memory Allocation Framework
version 10 changes:
- rebased on kernel 4.8 tag
- minor typo fix
version 9 changes:
- rebased on 4.8-rc5
- struct dma_attrs doesn't exist anymore so update CMA allocator
to compile with new dma_*_attr functions
- add example SMAF use case in cover letter
version 8 changes:
- rework of the structures used within ioctl
by adding a version field and padding to be futur proof
- rename fake secure moduel to test secure module
- fix the various remarks done on the previous patcheset
version 7 changes:
- rebased on kernel 4.6-rc7
- simplify secure module API
- add vma ops to be able to detect mmap/munmap calls
- add ioctl to get number and allocator names
- update libsmaf with adding tests
https://git.linaro.org/people/benjamin.gaignard/libsmaf.git
- add debug log in fake secure module
version 6 changes:
- rebased on kernel 4.5-rc4
- fix mmapping bug while requested allocation size isn't a a multiple of
PAGE_SIZE (add a test for this in libsmaf)
version 5 changes:
- rebased on kernel 4.3-rc6
- rework locking schema and make handle status use an atomic_t
- add a fake secure module to allow performing tests without trusted
environment
version 4 changes:
- rebased on kernel 4.3-rc3
- fix missing EXPORT_SYMBOL for smaf_create_handle()
version 3 changes:
- Remove ioctl for allocator selection instead provide the name of
the targeted allocator with allocation request.
Selecting allocator from userland isn't the prefered way of working
but is needed when the first user of the buffer is a software component.
- Fix issues in case of error while creating smaf handle.
- Fix module license.
- Update libsmaf and tests to care of the SMAF API evolution
https://git.linaro.org/people/benjamin.gaignard/libsmaf.git
version 2 changes:
- Add one ioctl to allow allocator selection from userspace.
This is required for the uses case where the first user of
the buffer is a software IP which can't perform dma_buf attachement.
- Add name and ranking to allocator structure to be able to sort them.
- Create a tiny library to test SMAF:
https://git.linaro.org/people/benjamin.gaignard/libsmaf.git
- Fix one issue when try to secure buffer without secure module registered
SMAF aim to solve two problems: allocating memory that fit with hardware IPs
constraints and secure those data from bus point of view.
One example of SMAF usage is camera preview: on SoC you may use either an USB
webcam or the built-in camera interface and the frames could be send directly
to the dipslay Ip or handle by GPU.
Most of USB interfaces and GPU have mmu but almost all built-in camera
interace and display Ips don't have mmu so when selecting how allocate
buffer you need to be aware of each devices constraints (contiguous memroy,
stride, boundary, alignment ...).
ION has solve this problem by let userland decide which allocator (heap) to use
but this require to adapt userland for each platform and sometime for each
use case.
To be sure to select the best allocation method for devices SMAF implement
deferred allocation mechanism: memory allocation is only done when the first
device effectively required it.
Allocator modules have to implement a match() to let SMAF know if they are
compatibles with devices needs.
This patch set provide an example of allocator module which use
dma_{alloc/free/mmap}_attrs() and check if at least one device have
coherent_dma_mask set to DMA_BIT_MASK(32) in match function.
In the same camera preview use case, SMAF allow to protect the data from being
read by unauthorized IPs (i.e. a malware to dump camera stream).
Until now I have only see access rights protection at process/thread level
(PKeys/MPK) or on file (SELinux) but nothing allow to drive data bus firewalls.
SMAF propose an interface to control and implement those firewalls.
Like IOMMU, firewalls IPs can help to protect memory from malicious/faulty
devices
that are attempting DMA attacks.
Secure modules are responsibles of granting and revoking devices access rights
on the memory. Secure module is also called to check if CPU map memory into
kernel and user address spaces.
An example of secure module implementation can be found here:
http://git.linaro.org/people/benjamin.gaignard/optee-sdp.git
This code isn't yet part of the patch set because it depends on generic TEE
which is still under discussion (https://lwn.net/Articles/644646/)
For allocation part of SMAF code I get inspirated by Sumit Semwal work about
constraint aware allocator.
Benjamin Gaignard (3):
create SMAF module
SMAF: add CMA allocator
SMAF: add test secure module
drivers/Kconfig| 2 +
drivers/Makefile | 1 +
drivers/smaf/Kconfig | 17 +
drivers/smaf/Makefile | 3 +
drivers/smaf/smaf-cma.c| 186 ++
drivers/smaf/smaf-core.c | 818 +
drivers/smaf/smaf-testsecure.c | 90 +
include/linux/smaf-allocator.h | 45 +++
[PATCH v8 2/4] drm: Add API for capturing frame CRCs
On 04/10/16 12:25, Daniel Vetter wrote: > On Tue, Oct 4, 2016 at 12:10 PM, Jon Hunter wrote: >> Looks like crtc is a errno in the above case. I see this function is >> called by looping through all the crtc and we never check to see if >> they are valid. Should we? > > Tegra is still using the load/unload hooks. That didn't mesh well with > Tomeu's patches (and Tomeu's patches have been thrown out meanwhile > because of that). Still would be neat if tegra could be demidlayered > and loose it's load/unload hooks. See the kerneldoc in drm_drv.c > (especially the DOC: section). Adding Thierry and Alex as this is more their domain and CC'ing linux-tegra. Cheers Jon -- nvpublic
[Bug 98025] [radeonsi] incorrect primitive restart index used
https://bugs.freedesktop.org/show_bug.cgi?id=98025 --- Comment #3 from James Legg --- I've sent the patch to mesa-dev. It now appears here: https://patchwork.freedesktop.org/patch/113613/ -- 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/20161004/e285279e/attachment.html>
[PATCH v8 2/4] drm: Add API for capturing frame CRCs
On Tue, Oct 4, 2016 at 12:10 PM, Jon Hunter wrote: > Looks like crtc is a errno in the above case. I see this function is > called by looping through all the crtc and we never check to see if > they are valid. Should we? Tegra is still using the load/unload hooks. That didn't mesh well with Tomeu's patches (and Tomeu's patches have been thrown out meanwhile because of that). Still would be neat if tegra could be demidlayered and loose it's load/unload hooks. See the kerneldoc in drm_drv.c (especially the DOC: section). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH] drm: virtio: reinstate drm_virtio_set_busid()
On 4 October 2016 at 03:43, Laszlo Ersek wrote:
> Before commit a325725633c2 ("drm: Lobotomize set_busid nonsense for !pci
> drivers"), several DRM drivers for platform devices used to expose an
> explicit "drm_driver.set_busid" callback, invariably backed by
> drm_platform_set_busid().
>
> Commit a325725633c2 removed drm_platform_set_busid(), along with the
> referring .set_busid field initializations. This was justified because
> interchangeable functionality had been implemented in drm_dev_alloc() /
> drm_dev_init(), which DRM_IOCTL_SET_VERSION would rely on going forward.
>
> However, commit a325725633c2 also removed drm_virtio_set_busid(), for
> which the same consolidation was not appropriate: this .set_busid callback
> had been implemented with drm_pci_set_busid(), and not
> drm_platform_set_busid(). The error regressed Xorg/xserver on QEMU's
> "virtio-vga" card; the drmGetBusid() function from libdrm would no longer
> return stable PCI identifiers like "pci::00:02.0", but rather unstable
> platform ones like "virtio0".
>
> Reinstate drm_virtio_set_busid() with judicious use of
>
> git checkout -p a325725633c2^ -- drivers/gpu/drm/virtio
Thanks guys, I've pushed this into drm-next.
Dave.
[PULL] topic/drm-misc
On 3 October 2016 at 23:39, Daniel Vetter wrote: > Hi Dave, > > As promised another pull request. A bit late because flu. > - generic pipe crc from Tomeu, required a backmerge to apply > - fixes for my fumbled drm_plane.c extraction > - display_info cleanup/fixes from Ville > - misc stuff all over I pulled this, it fell over I force pushed drm-next back to what it was, I'm sad panda. Hopefully nobody had pulled drm-next too much in that time period. The pipe crc stuff is pretty broken wrt driver that still have ->load, since we register the minors before we call load, and on ->load driver the mode resources haven't been configured at that point. I'd really like the rest of drm-misc, but I might at least cherry-pick out the major patch I want which is the drm_plane.c fixup. Dave.
[Bug 98003] Tonga fails to boot since drm/amdgpu:exclude 5dw digest for entry
https://bugs.freedesktop.org/show_bug.cgi?id=98003 --- Comment #4 from Grazvydas Ignotas --- It seems this Monk's patch series is problematic, for me "4/9 drm/amdgpu:keep bo pinned in prefered domain" is causing ring test failures on polaris 10, the one in this bug report is 1/9. bug 98016 might also be related to this, I've also had a hang once while bisecting, but then it just went away without changing anything. I wasn't doing cold boots though, bug 98016 suggests that may be required to fully reproduce this. -- 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/20161004/aea9ca73/attachment.html>
[Bug 97988] [radeonsi] playing back videos with VDPAU exhibits deinterlacing/anti-aliasing issues not visible with VA-API
https://bugs.freedesktop.org/show_bug.cgi?id=97988 --- Comment #14 from Christian König --- (In reply to Marek Olšák from comment #13) > (In reply to Tom Stellard from comment #12) > > > > I think the best solution here would be to teach the backend how to do a > > scalar select based on value of vccz. > > You are missing the point. The condition code (VCC) isn't the same across > all threads. The problem is that the conditional assignment is transformed > into a form that makes descriptor load addresses non-uniform (dependent on a > VGPR). There is nothing the AMDGPU backend can do about it. It's not a > problem in the backend. Well the backend could iterate over all the variants to handle that, but I have strong doubts that this would result in optimal performance. So I think the best solution for now would be to mark the texture intrinsic in a way which disallows such optimizations. -- 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/20161004/7f0d9e1a/attachment.html>
[Bug 98025] [radeonsi] incorrect primitive restart index used
https://bugs.freedesktop.org/show_bug.cgi?id=98025 --- Comment #2 from Grazvydas Ignotas --- It's best to send patches to mesa-dev for review and inclusion. You might need to subscribe, but you can opt-out of receiving anything from the list. -- 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/20161004/7beb2ae0/attachment.html>
[PATCH v8 2/4] drm: Add API for capturing frame CRCs
gt; *connector)
> connector->debugfs_entry = NULL;
> }
>
> -#endif /* CONFIG_DEBUG_FS */
> +int drm_debugfs_crtc_add(struct drm_crtc *crtc)
> +{
> + struct drm_minor *minor = crtc->dev->primary;
After this patch was applied Tegra boards started crashing here when
dereferencing crtc pointer above ...
[6.789318] Unable to handle kernel paging request at virtual address
fff8
[6.796537] pgd = c0004000
[6.799270] [fff8] *pgd=afffd861, *pte=, *ppte=
[6.805572] Internal error: Oops: 37 [#1] PREEMPT SMP ARM
[6.810969] Modules linked in:
[6.814038] CPU: 2 PID: 72 Comm: kworker/2:1 Not tainted
4.8.0-next-20161004-126151-gc7d3b91 #1
[6.822728] Hardware name: NVIDIA Tegra SoC (Flattened Device Tree)
[6.829000] Workqueue: events deferred_probe_work_func
[6.834150] task: ee00f880 task.stack: ee01
[6.838682] PC is at drm_debugfs_crtc_add+0x8/0x70
[6.843481] LR is at drm_minor_register+0xa4/0x1b0
[6.848267] pc : []lr : []psr: a113
[6.848267] sp : ee011d20 ip : ee2f4914 fp : c0d02100
[6.859732] r10: 0001 r9 : r8 :
[6.864949] r7 : ee2f3800 r6 : ee2f3a4c r5 : ee2f4900 r4 : fff8
[6.871472] r3 : 0001 r2 : r1 : ee011c70 r0 : fff8
[6.877992] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
[6.885123] Control: 10c5387d Table: 8000406a DAC: 0051
[6.890871] Process kworker/2:1 (pid: 72, stack limit = 0xee010210)
[6.897129] Stack: (0xee011d20 to 0xee012000)
[6.901491] 1d20: fff8 ee2f4900 ee2f3a4c c0428a60 ee00f880 ee2f3800
[6.909670] 1d40: c0d34794 001e c0428be8 ee2f3800 eebae800
c0d3467c c0442008
[6.917839] 1d60: eebae818 c0d34794 001e eebae810 c0dabfec
c0407578
[6.926014] 1d80: c040755c c045ac3c ee011db8 c045af10 0001
c0dabfc8 c045922c
[6.934190] 1da0: eeaaa370 eebac0b8 eebae810 eebae844 c0d33fa0 c045a9c4
eebae810 0001
[6.942366] 1dc0: c0d02100 eebae810 eebae810 c0d33fa0 ee9b6e10 c045a0b4
eebae810
[6.950544] 1de0: eebae818 c0458624 c0d6404c 6113 c0d02100 c0817664
eebae800 ee2f3c10
[6.958713] 1e00: ee034ec0 eebae9d8 eebae9b0 eefa5580 eebae810 c0407744
eefbf974 eebaeb94
[6.966887] 1e20: c0d3400c c0d33f68 ee2f3c10 eebaea10 c0408058
ee2f3c10 ee9b6810
[6.975064] 1e40: ee9b6800 c044bb4c ee9b4940
ee2f3c10
[6.983241] 1e60: ffed ee9b6810 fdfb c0d348f8 001e c045c20c
c045c1bc ee9b6810
[6.991417] 1e80: c0dabfec c0d348f8 c045ac3c ee011ec0
c045af10 0001
[6.999595] 1ea0: c045922c ee8a3d70 eebacfb8 ee9b6810 ee9b6844
c0d34de8 c045a9c4
[7.007763] 1ec0: ee9b6810 0001 c0d02100 ee9b6810 ee9b6810 c0d34de8
eefa8800 c045a0b4
[7.015938] 1ee0: ee9b6810 c0d34d70 c0d34d90 c045a4e8 eeb78f00 c0d34d98
eefa5580 c0134890
[7.024115] 1f00: ee171484 eefa5580 eeb78f00 eeb78f18 0001 eefa5580
eeb78f18 eefa5580
[7.032292] 1f20: 0008 c0134ab4 eefa88f5 eeb78f00 eefa5598 c0134cc8
eeaf6fc0
[7.040469] 1f40: eeaf6fc0 eeb78f00 c0134ac4
[7.048637] 1f60: c0139d68 fffc ffef eeb78f00
[7.056812] 1f80: ee011f80 ee011f80 ee011f90 ee011f90
ee011fac eeaf6fc0
[7.064988] 1fa0: c0139c90 c0107938
[7.073165] 1fc0:
[7.081342] 1fe0: 0013
fff3 efbf
[7.089538] [] (drm_debugfs_crtc_add) from []
(drm_minor_register+0xa4/0x1b0)
[7.098405] [] (drm_minor_register) from []
(drm_dev_register+0x7c/0xd0)
[7.106856] [] (drm_dev_register) from []
(host1x_drm_probe+0x38/0x90)
[7.115135] [] (host1x_drm_probe) from []
(host1x_device_probe+0x1c/0x28)
[7.123672] [] (host1x_device_probe) from []
(driver_probe_device+0x1f0/0x2a8)
[7.132642] [] (driver_probe_device) from []
(bus_for_each_drv+0x44/0x8c)
[7.141178] [] (bus_for_each_drv) from []
(__device_attach+0x9c/0x100)
[7.149454] [] (__device_attach) from []
(bus_probe_device+0x84/0x8c)
[7.157624] [] (bus_probe_device) from []
(device_add+0x380/0x528)
[7.165551] [] (device_add) from []
(host1x_subdev_register+0xb0/0xd4)
[7.173827] [] (host1x_subdev_register) from []
(host1x_client_register+0xf4/0x11c)
[7.183231] [] (host1x_client_register) from []
(tegra_hdmi_probe+0x1c8/0x2c8)
[7.192201] [] (tegra_hdmi_probe) from []
(platform_drv_probe+0x50/0xb0)
[7.200653] [] (platform_drv_probe) from []
(driver_probe_device+0x1f0/0x2a8)
[7.209536] [] (driver_probe_device) from []
(bus_for_each_drv+0x44/0x8c)
[7.218053] [] (bus_for_each_drv) from []
(__device
[PATCH v2 2/4] drm/bridge: analogix_dp: get sync PM when init eDP
On Fri, Sep 30, 2016 at 8:40 AM, zain wang wrote: Can you please add a commit message describing why this is needed. Sean > Signed-off-by: zain wang > > --- > > Changes in v2: None > > drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c > b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c > index b4ce16a..1bd190e 100644 > --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c > +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c > @@ -1411,10 +1411,12 @@ int analogix_dp_bind(struct device *dev, struct > drm_device *drm_dev, > } > > pm_runtime_enable(dev); > + pm_runtime_get_sync(dev); > > phy_power_on(dp->phy); > > analogix_dp_init_dp(dp); > + pm_runtime_put_sync(dev); > > ret = devm_request_threaded_irq(&pdev->dev, dp->irq, > analogix_dp_hardirq, > -- > 1.9.1 > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
Regression: drm: Lobotomize set_busid nonsense for !pci drivers (a325725633c2)
Hi, > diff --git a/drivers/gpu/drm/virtio/virtgpu_drm_bus.c > b/drivers/gpu/drm/virtio/virtgpu_drm_bus.c > index a59d0e309bfc..1fcf739bf509 100644 > --- a/drivers/gpu/drm/virtio/virtgpu_drm_bus.c > +++ b/drivers/gpu/drm/virtio/virtgpu_drm_bus.c > @@ -68,6 +68,10 @@ int drm_virtio_init(struct drm_driver *driver, > struct virtio_device *vdev) > dev->pdev = pdev; > if (vga) > virtio_pci_kick_out_firmware_fb(pdev); > + > + ret = drm_dev_set_unique(dev, dev_name(dev->pdev)); > + if (ret) > + goto err_free; > } Approach looks sensible to me, I'll give it a try ... cheers, Gerd
[Bug 98016] [bisected] Fury fails to boot on drm-next-4.9
https://bugs.freedesktop.org/show_bug.cgi?id=98016 --- Comment #5 from Andy Furniss --- Also the way 4.9-wip changes and things get merged may not make bisecting a long way back that easy compared to something like mesa. I notice it's changed again 17 hours ago - it may even work now without you being able to see any sign od a revert or fix in the history. Maybe testing other branches (after power off of course) would give you a better idea where you are. -- 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/20161004/47edc3ed/attachment.html>
[Bug 98016] [bisected] Fury fails to boot on drm-next-4.9
https://bugs.freedesktop.org/show_bug.cgi?id=98016 --- Comment #4 from Andy Furniss --- (In reply to Ernst Sjöstrand from comment #3) > This seems to be very hard to reproduce. Perhaps it's related to the kernel > I'm rebooting from or some complex combination. > Pretty hard to debug when the computer simply stops responding without any > text etc. Yea, it's tricky sometimes. For my (I guess different) tonga start up issue I had to power down "properly" between bisect steps. By properly I mean shutdown/halt then cut the power to the PSU and wait a couple of minutes before powering up again. -- 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/20161004/749e73a9/attachment.html>
[Bug 97969] [radeonsi, bisected: fb827c0] Video decoding shows green artifacts
https://bugs.freedesktop.org/show_bug.cgi?id=97969 --- Comment #8 from Nicolai Hähnle --- Now that I actually got to test this on radeon rather than just amdgpu, the problem was pretty obvious. It's fixed for me with https://patchwork.freedesktop.org/patch/113573/. I apologize for the inconvenience. -- 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/20161004/98c08920/attachment.html>
[Bug 98037] HD6450 KMS failure
https://bugs.freedesktop.org/show_bug.cgi?id=98037 Michel Dänzer changed: What|Removed |Added Component|Driver/Radeon |DRM/Radeon QA Contact|xorg-team at lists.x.org | Assignee|xorg-driver-ati at lists.x.org |dri-devel at lists.freedesktop ||.org Version|7.7 (2012.06) |unspecified Product|xorg|DRI --- Comment #2 from Michel Dänzer --- Did it work with older kernels? If yes, can you bisect? -- 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/20161004/dd3bbcdd/attachment.html>
[Bug 98028] Guns of Icarus Online segfaults on startup since AMDGPU: Partially fix control flow at -O0
https://bugs.freedesktop.org/show_bug.cgi?id=98028 --- Comment #1 from Michel Dänzer --- Please attach a backtrace of a segfault. -- 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/20161004/b174dd9c/attachment.html>
[PATCH v3 1/2] dt-bindings: display: Add Sharp LQ150X1LG11 panel binding
On Mon, Oct 3, 2016 at 11:58 PM, Peter Rosin wrote: > On 2016-10-03 20:46, Rob Herring wrote: >> On Tue, Sep 27, 2016 at 12:27:11AM +0200, Peter Rosin wrote: >>> The Sharp 15" LQ150X1LG11 panel is an XGA TFT LCD panel. >>> >>> Signed-off-by: Peter Rosin >>> --- >>> .../bindings/display/panel/sharp,lq150x1lg11.txt | 36 >>> ++ >>> 1 file changed, 36 insertions(+) >>> create mode 100644 >>> Documentation/devicetree/bindings/display/panel/sharp,lq150x1lg11.txt >>> >>> diff --git >>> a/Documentation/devicetree/bindings/display/panel/sharp,lq150x1lg11.txt >>> b/Documentation/devicetree/bindings/display/panel/sharp,lq150x1lg11.txt >>> new file mode 100644 >>> index ..715ff7e332f2 >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/display/panel/sharp,lq150x1lg11.txt >>> @@ -0,0 +1,36 @@ >>> +Sharp 15" LQ150X1LG11 XGA TFT LCD panel >>> + >>> +Required properties: >>> +- compatible: should be "sharp,lq150x1lg11" >>> +- power-supply: regulator to provide the VCC supply voltage (3.3 volts) >> >> Should be named according to the input, so vcc-supply. > > Right, I wanted to do that, but the simple-panel bindings has power-supply > as required and I desperately wanted to be compatible in order to make use > of the simple-panel driver. That driver does require this entry, so I do > not see any way around it. Any advice for this situation? Okay, it's fine given it's a single supply. Rob
[PATCH v3 1/2] dt-bindings: display: Add Sharp LQ150X1LG11 panel binding
On 2016-10-03 20:46, Rob Herring wrote:
> On Tue, Sep 27, 2016 at 12:27:11AM +0200, Peter Rosin wrote:
>> The Sharp 15" LQ150X1LG11 panel is an XGA TFT LCD panel.
>>
>> Signed-off-by: Peter Rosin
>> ---
>> .../bindings/display/panel/sharp,lq150x1lg11.txt | 36
>> ++
>> 1 file changed, 36 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/display/panel/sharp,lq150x1lg11.txt
>>
>> diff --git
>> a/Documentation/devicetree/bindings/display/panel/sharp,lq150x1lg11.txt
>> b/Documentation/devicetree/bindings/display/panel/sharp,lq150x1lg11.txt
>> new file mode 100644
>> index ..715ff7e332f2
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/display/panel/sharp,lq150x1lg11.txt
>> @@ -0,0 +1,36 @@
>> +Sharp 15" LQ150X1LG11 XGA TFT LCD panel
>> +
>> +Required properties:
>> +- compatible: should be "sharp,lq150x1lg11"
>> +- power-supply: regulator to provide the VCC supply voltage (3.3 volts)
>
> Should be named according to the input, so vcc-supply.
Right, I wanted to do that, but the simple-panel bindings has power-supply
as required and I desperately wanted to be compatible in order to make use
of the simple-panel driver. That driver does require this entry, so I do
not see any way around it. Any advice for this situation?
>> +
>> +Optional properties:
>> +- backlight: phandle of the backlight device
>> +- rlud-gpios: a single GPIO for the RL/UD (rotate 180 degrees) pin.
>> +- lvds-gpios: a single GPIO for the SELLVDS pin.
>
> Why not sellvds-gpios?
I'll change that in v4.
>> +
>> +If lrud-gpios and/or ldvs-gpios are not specified, the RL/UD and/or SELLVDS
>
> typos...
Good thing you added the plural, I found s/lrud/rlud/ and s/ldvs/lvds/
Nice catch btw, thanks!
>> +pins are assumed to be handled appropriately by the hardware.
>> +
>> +Example:
>> +
>> +backlight: backlight {
>> +compatible = "pwm-backlight";
>> +pwms = <&pwm 0 10>; /* VBR */
>> +
>> +brightness-levels = <0 20 40 60 80 100>;
>> +default-brightness-level = <2>;
>> +
>> +power-supply = <&vdd_12v_reg>; /* VDD */
>> +enable-gpios = <&gpio 42 GPIO_ACTIVE_HIGH>; /* XSTABY */
>> +};
>> +
>> +panel {
>> +compatible = "sharp,lq150x1lg11";
>> +
>> +power-supply = <&vcc_3v3_reg>; /* VCC */
>> +
>> +backlight = <&backlight>;
>> +rlud-gpios = <&gpio 17 GPIO_ACTIVE_HIGH>;/* RL/UD */
>> +lvds-gpios = <&gpio 18 GPIO_ACTIVE_HIGH>;/* SELLVDS */
>> +};
>> --
>> 2.1.4
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe devicetree" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
