[Bug 78221] 3.16 RC1: AMD R9 270 GPU locks up on some heavy 2D activity - GPU VM fault occurs. (possibly DMA copying issue strikes back?)
https://bugzilla.kernel.org/show_bug.cgi?id=78221 Linux Tester changed: What|Removed |Added CC||linux.tester at sharklasers.co ||m --- Comment #24 from Linux Tester --- After some updates to MESA and kernel this bug no longer happens at all - 2D now rock solid for me on R9 270 and I can run even most troublesome workloads for weeks without any issues. While I failed to pinpoint what exactly has fixed bug, thanks anyway. I think it is now safe to close this bug as fixed. I bet you've got dozens of other GPU lockups to chew on, so I'm glad to inform you at least one nasty thing has been nailed down. (it's me, original bug reporter who has forgot password on both original mailbox and bugzilla account, dammit) -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 86351] HDMI audio garbled output on Radeon R9 280X
https://bugzilla.kernel.org/show_bug.cgi?id=86351 Lorenzo Bona changed: What|Removed |Added CC||lorenz.bona at gmail.com --- Comment #14 from Lorenzo Bona --- Same issue on drm-fixes-4.2. -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH v2 2/2] drm/rockchip: Drop owner assignment from platform_driver
platform_driver does not need to set an owner because
platform_driver_register() will set it.
Signed-off-by: Krzysztof Kozlowski
---
Changes since v1:
1. Split owner removal from rockchip to separate patch (spotted by Mark
Yao).
---
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index 01b558fe3695..9a0c2911272a 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -555,7 +555,6 @@ static struct platform_driver rockchip_drm_platform_driver
= {
.probe = rockchip_drm_platform_probe,
.remove = rockchip_drm_platform_remove,
.driver = {
- .owner = THIS_MODULE,
.name = "rockchip-drm",
.of_match_table = rockchip_drm_dt_ids,
.pm = &rockchip_drm_pm_ops,
--
1.9.1
[PATCH v2 1/2] drm/bridge: Drop owner assignment from i2c_driver
i2c_driver does not need to set an owner because i2c_register_driver()
will set it.
Signed-off-by: Krzysztof Kozlowski
---
The coccinelle script which generated the patch was sent here:
http://www.spinics.net/lists/kernel/msg2029903.html
Changes since v1:
1. Split owner removal from rockchip to separate patch (spotted by Mark
Yao).
---
drivers/gpu/drm/bridge/ps8622.c | 1 -
drivers/gpu/drm/bridge/ptn3460.c | 1 -
2 files changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ps8622.c b/drivers/gpu/drm/bridge/ps8622.c
index 1a6607beb29f..be881e9fef8f 100644
--- a/drivers/gpu/drm/bridge/ps8622.c
+++ b/drivers/gpu/drm/bridge/ps8622.c
@@ -668,7 +668,6 @@ static struct i2c_driver ps8622_driver = {
.remove = ps8622_remove,
.driver = {
.name = "ps8622",
- .owner = THIS_MODULE,
.of_match_table = ps8622_devices,
},
};
diff --git a/drivers/gpu/drm/bridge/ptn3460.c b/drivers/gpu/drm/bridge/ptn3460.c
index 1b1bf2384815..0ffa3a6a206a 100644
--- a/drivers/gpu/drm/bridge/ptn3460.c
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -400,7 +400,6 @@ static struct i2c_driver ptn3460_driver = {
.remove = ptn3460_remove,
.driver = {
.name = "nxp,ptn3460",
- .owner = THIS_MODULE,
.of_match_table = ptn3460_match,
},
};
--
1.9.1
[PATCH] Drop owner assignment from i2c_driver (and platform left-overs)
Hi, The i2c drivers also do not have to set 'owner' field because i2c_register_driver() will do it instead. 'owner' is removed from i2c drivers, which I was able to compile with allyesconfig (arm, arm64, i386, x86_64, ppc64). Only compile-tested. The coccinelle script which generated the patch was sent here: http://www.spinics.net/lists/kernel/msg2029903.html Best regards, Krzysztof Krzysztof Kozlowski (2): drm/bridge: Drop owner assignment from i2c_driver drm/rockchip: Drop owner assignment from platform_driver drivers/gpu/drm/bridge/ps8622.c | 1 - drivers/gpu/drm/bridge/ptn3460.c| 1 - drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 1 - 3 files changed, 3 deletions(-) -- 1.9.1
[PATCH v7 4/4] arm/dts/ls1021a: Add a TFT LCD panel dts node
Add a TFT LCD panel. the TFT LCD panel is WQVGA "480x272",
and the bpp is 24.
Signed-off-by: Alison Wang
Signed-off-by: Xiubo Li
Signed-off-by: Jianwei Wang
---
arch/arm/boot/dts/ls1021a-twr.dts | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/ls1021a-twr.dts
b/arch/arm/boot/dts/ls1021a-twr.dts
index a2c591e..f6ad7ba 100644
--- a/arch/arm/boot/dts/ls1021a-twr.dts
+++ b/arch/arm/boot/dts/ls1021a-twr.dts
@@ -56,6 +56,17 @@
enet0_sgmii_phy = &sgmii_phy2;
enet1_sgmii_phy = &sgmii_phy0;
};
+
+ panel: panel {
+ compatible = "nec,nl4827hc19_05b";
+ };
+
+};
+
+&dcu {
+ panel = <&panel>;
+ status = "okay";
+
};
&dspi1 {
--
2.1.0.27.g96db324
[PATCH v7 3/4] arm/dts/ls1021a: Add DCU dts node
Add DCU node, DCU is a display controller of Freescale
named 2D-ACE.
Signed-off-by: Alison Wang
Signed-off-by: Xiubo Li
Signed-off-by: Jianwei Wang
---
.../devicetree/bindings/drm/fsl-dcu/fsl,dcu.txt| 49 ++
MAINTAINERS| 1 +
arch/arm/boot/dts/ls1021a.dtsi | 10 +
3 files changed, 60 insertions(+)
create mode 100644 Documentation/devicetree/bindings/drm/fsl-dcu/fsl,dcu.txt
diff --git a/Documentation/devicetree/bindings/drm/fsl-dcu/fsl,dcu.txt
b/Documentation/devicetree/bindings/drm/fsl-dcu/fsl,dcu.txt
new file mode 100644
index 000..d65631d
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/fsl-dcu/fsl,dcu.txt
@@ -0,0 +1,49 @@
+Device Tree bindings for Freescale DCU DRM Driver
+
+Required properties:
+- compatible: Should be one of
+ * "fsl,ls1021a-dcu".
+ * "fsl,vf610-dcu".
+- reg: Address and length of the register set for dcu.
+- clocks: From common clock binding: handle to dcu clock.
+- clock-names: From common clock binding: Shall be "dcu".
+- display: The phandle to display node.
+
+Required properties:
+- bits-per-pixel: <16> for RGB565,
+ <24> for RGB888,
+ <32> for RGB.
+
+Required timing node for dispplay sub-node:
+- display-timings: Refer to binding doc display-timing.txt for details.
+
+Examples:
+dcu: dcu at 2ce {
+ compatible = "fsl,ls1021a-dcu";
+ reg = <0x0 0x2ce 0x0 0x1>;
+ clocks = <&platform_clk 0>;
+ clock-names = "dcu";
+ big-endian;
+ display = <&display>;
+
+ display: display at 0 {
+ bits-per-pixel = <24>;
+
+ display-timings {
+ native-mode = <&timing0>;
+ timing0: nl4827hc19 {
+ clock-frequency = <1087>;
+ hactive = <480>;
+ vactive = <272>;
+ hback-porch = <2>;
+ hfront-porch = <2>;
+ vback-porch = <1>;
+ vfront-porch = <1>;
+ hsync-len = <41>;
+ vsync-len = <2>;
+ hsync-active = <1>;
+ vsync-active = <1>;
+ };
+ };
+ };
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index e191ded..fffb8c9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3410,6 +3410,7 @@ M:Alison Wang
L: dri-devel at lists.freedesktop.org
S: Supported
F: drivers/gpu/drm/fsl-dcu/
+F: Documentation/devicetree/bindings/drm/fsl-dcu/
F: Documentation/devicetree/bindings/panel/nec,nl4827hc19_05b.txt
DRM DRIVERS FOR NVIDIA TEGRA
diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index c70bb27..6d6e3e2 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -383,6 +383,16 @@
<&platform_clk 1>;
};
+ dcu: dcu at 2ce {
+ compatible = "fsl,ls1021a-dcu";
+ reg = <0x0 0x2ce 0x0 0x1>;
+ interrupts = ;
+ clocks = <&platform_clk 0>;
+ clock-names = "dcu";
+ big-endian;
+ status = "disabled";
+ };
+
mdio0: mdio at 2d24000 {
compatible = "gianfar";
device_type = "mdio";
--
2.1.0.27.g96db324
[PATCH v7 2/4] drm/panel: simple: Add support for NEC NL4827HC19-05B 480x272 panel
This adds support for the NEC NL4827HC19-05B 480x272 panel to the DRM
simple panel driver.
Signed-off-by: Jianwei Wang
---
.../bindings/panel/nec,nl4827hc19_05b.txt | 7 ++
.../devicetree/bindings/vendor-prefixes.txt| 1 +
MAINTAINERS| 1 +
drivers/gpu/drm/panel/panel-simple.c | 26 ++
4 files changed, 35 insertions(+)
create mode 100644
Documentation/devicetree/bindings/panel/nec,nl4827hc19_05b.txt
diff --git a/Documentation/devicetree/bindings/panel/nec,nl4827hc19_05b.txt
b/Documentation/devicetree/bindings/panel/nec,nl4827hc19_05b.txt
new file mode 100644
index 000..20e9473
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/nec,nl4827hc19_05b.txt
@@ -0,0 +1,7 @@
+NEC LCD Technologies,Ltd. WQVGA TFT LCD panel
+
+Required properties:
+- compatible: should be "nec,nl4827hc19_05b"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 8033919..9f22b3e 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -131,6 +131,7 @@ mundoreader Mundo Reader S.L.
murata Murata Manufacturing Co., Ltd.
mxicy Macronix International Co., Ltd.
national National Semiconductor
+necNEC LCD Technologies, Ltd.
neonodeNeonode Inc.
netgearNETGEAR
netlogic Broadcom Corporation (formerly NetLogic Microsystems)
diff --git a/MAINTAINERS b/MAINTAINERS
index b25b948..e191ded 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3410,6 +3410,7 @@ M:Alison Wang
L: dri-devel at lists.freedesktop.org
S: Supported
F: drivers/gpu/drm/fsl-dcu/
+F: Documentation/devicetree/bindings/panel/nec,nl4827hc19_05b.txt
DRM DRIVERS FOR NVIDIA TEGRA
M: Thierry Reding
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index f94201b..eee95f4 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1036,6 +1036,29 @@ static const struct panel_desc shelly_sca07010_bfn_lnn =
{
.bus_format = MEDIA_BUS_FMT_RGB666_1X18,
};
+static const struct drm_display_mode nec_nl4827hc19_05b_mode = {
+ .clock = 10870,
+ .hdisplay = 480,
+ .hsync_start = 480 + 2,
+ .hsync_end = 480 + 2 + 41,
+ .htotal = 480 + 2 + 41 + 2,
+ .vdisplay = 272,
+ .vsync_start = 272 + 2,
+ .vsync_end = 272 + 2 + 4,
+ .vtotal = 272 + 2 + 4 + 2,
+ .vrefresh = 74,
+};
+
+static const struct panel_desc nec_nl4827hc19_05b = {
+ .modes = &nec_nl4827hc19_05b_mode,
+ .num_modes = 1,
+ .size = {
+ .width = 480,
+ .height = 272,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X24
+};
+
static const struct of_device_id platform_of_match[] = {
{
.compatible = "ampire,am800480r3tmqwa1h",
@@ -1125,6 +1148,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "shelly,sca07010-bfn-lnn",
.data = &shelly_sca07010_bfn_lnn,
}, {
+ .compatible = "nec,nl4827hc19_05b",
+ .data = &nec_nl4827hc19_05b,
+ }, {
/* sentinel */
}
};
--
2.1.0.27.g96db324
[PATCH v7 1/4] drm/layerscape: Add Freescale DCU DRM driver
This patch add support for Two Dimensional Animation and Compositing Engine (2D-ACE) on the Freescale SoCs. 2D-ACE is a Freescale display controller. 2D-ACE describes the functionality of the module extremely well its name is a value that cannot be used as a token in programming languages. Instead the valid token "DCU" is used to tag the register names and function names. The Display Controller Unit (DCU) module is a system master that fetches graphics stored in internal or external memory and displays them on a TFT LCD panel. A wide range of panel sizes is supported and the timing of the interface signals is highly configurable. Graphics are read directly from memory and then blended in real-time, which allows for dynamic content creation with minimal CPU intervention. The features: (1) Full RGB888 output to TFT LCD panel. (2) For the current LCD panel, WQVGA "480x272" is supported. (3) Blending of each pixel using up to 4 source layers dependent on size of panel. (4) Each graphic layer can be placed with one pixel resolution in either axis. (5) Each graphic layer support RGB565 and RGB888 direct colors without alpha channel and BGRA BGRA ARGB1555 direct colors with an alpha channel and YUV422 format. (6) Each graphic layer support alpha blending with 8-bit resolution. This is a simplified version, only one primary plane, one framebuffer created for fbdev, one crtc, one connector for TFT LCD panel, an encoder. Signed-off-by: Alison Wang Signed-off-by: Xiubo Li Signed-off-by: Jianwei Wang --- Changed in V7 - Remove redundant functions and replace deprecated hooker Adviced by Daniel Vetter - Replace drm_platform_init with drm_dev_alloc/register Adviced by Daniel Vetter Changed in V6 - Add NEC nl4827hc19_05b panel to panel-simple.c Adviced by Mark Yao - Add DRIVER_ATOMIC for driver_features Adviced by Mark Yao - check fsl_dev if it's NULL at PM suspend/resume Adviced by Mark Yao Changed in V5 - Update commit message - Add layer registers initialization - Remove unused functions - Rename driver folder Adviced by Stefan Agner - Move pixel clock control functions to fsl_dcu_drm_drv.c - remove redundant enable the clock implicitly using regmap - Add maintainer message Changed in V4: -This version doesn't have functionality changed Just a minor adjustment. Changed in V3: - Test driver on Vybrid board and add compatible string - Remove unused functions - set default crtc for encoder - replace legacy functions with atomic help functions Adviced by Daniel Vetter - Set the unique name of the DRM device - Implement irq handle function for vblank interrupt Changed in v2: - Add atomic support Adviced by Daniel Vetter - Modify bindings file - Rename node for compatibility - Move platform related code out for compatibility Adviced by Stefan Agner MAINTAINERS | 7 + drivers/gpu/drm/Kconfig | 2 + drivers/gpu/drm/Makefile| 1 + drivers/gpu/drm/fsl-dcu/Kconfig | 18 ++ drivers/gpu/drm/fsl-dcu/Makefile| 7 + drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_connector.c | 183 +++ drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_connector.h | 31 ++ drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 159 ++ drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.h | 22 ++ drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 401 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h | 223 + drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_fbdev.c | 26 ++ drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c | 42 +++ drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.h | 17 + drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c | 195 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.h | 23 ++ 16 files changed, 1357 insertions(+) create mode 100644 drivers/gpu/drm/fsl-dcu/Kconfig create mode 100644 drivers/gpu/drm/fsl-dcu/Makefile create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_connector.c create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_connector.h create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.h create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_fbdev.c create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.h create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.h diff --git a/MAINTAINERS b/MAINTAINERS index 6761318..b25b948 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3404,6 +3404,13 @@ S: Maintained F: drivers/gpu/drm/imx/ F: Documentation/devicetree/bindings/drm/imx/ +DRM DRIVERS FOR FREESCALE DCU +M: Jianwei Wang +M: Alison Wang +L: dri-devel at lists.freedesktop.org +S: Sup
[PATCH] drm/i915: Use drm_for_each_fb in i915_debugfs.c
Just so I have a user for this macro.
v2: Use the right macro - somehow I thought gcc should scream at me,
but list_for_each isn't really typesafe unfortunately. Spotted by
Ville.
Cc: Ville Syrjälä
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_debugfs.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 053adbb97037..ab8364984a89 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1855,6 +1855,7 @@ static int i915_gem_framebuffer_info(struct seq_file *m,
void *data)
struct drm_device *dev = node->minor->dev;
struct intel_fbdev *ifbdev = NULL;
struct intel_framebuffer *fb;
+ struct drm_framebuffer *drm_fb;
#ifdef CONFIG_DRM_I915_FBDEV
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -1874,7 +1875,8 @@ static int i915_gem_framebuffer_info(struct seq_file *m,
void *data)
#endif
mutex_lock(&dev->mode_config.fb_lock);
- list_for_each_entry(fb, &dev->mode_config.fb_list, base.head) {
+ drm_for_each_fb(drm_fb, dev) {
+ fb = to_intel_framebuffer(drm_fb);
if (ifbdev && &fb->base == ifbdev->helper.fb)
continue;
--
2.1.4
[PATCH v7 1/4] drm/layerscape: Add Freescale DCU DRM driver
On Fri, Jul 10, 2015 at 07:17:40PM +0800, Jianwei Wang wrote: > This patch add support for Two Dimensional Animation and Compositing > Engine (2D-ACE) on the Freescale SoCs. > > 2D-ACE is a Freescale display controller. 2D-ACE describes > the functionality of the module extremely well its name is a value > that cannot be used as a token in programming languages. > Instead the valid token "DCU" is used to tag the register names and > function names. > > The Display Controller Unit (DCU) module is a system master that > fetches graphics stored in internal or external memory and displays > them on a TFT LCD panel. A wide range of panel sizes is supported > and the timing of the interface signals is highly configurable. > Graphics are read directly from memory and then blended in real-time, > which allows for dynamic content creation with minimal CPU > intervention. > > The features: > (1) Full RGB888 output to TFT LCD panel. > (2) For the current LCD panel, WQVGA "480x272" is supported. > (3) Blending of each pixel using up to 4 source layers > dependent on size of panel. > (4) Each graphic layer can be placed with one pixel resolution > in either axis. > (5) Each graphic layer support RGB565 and RGB888 direct colors > without alpha > channel and BGRA BGRA ARGB1555 direct colors with an > alpha channel and > YUV422 format. > (6) Each graphic layer support alpha blending with 8-bit > resolution. > > This is a simplified version, only one primary plane, one > framebuffer created for > fbdev, one crtc, one connector for TFT LCD panel, an encoder. > > Signed-off-by: Alison Wang > Signed-off-by: Xiubo Li > Signed-off-by: Jianwei Wang Can't find any other use of deprecated functions or legacy code patterns or anything else that we've recently started cleaning up, looks good. No detailed review though (for one I lack hw docs). Acked-by: Daniel Vetter Might be good to get some cross-review from some other arm soc drm driver team, then send a pull request to Dave for 4.3. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH v6 1/4] drm/layerscape: Add Freescale DCU DRM driver
On Fri, Jul 10, 2015 at 10:43:11AM +, Wang J.W. wrote:
> Hi Daniel,
>
> Thank you very much for your review!
> See below...
>
> > -Original Message-
> > From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of Daniel
> > Vetter
> > Sent: Friday, July 10, 2015 4:00 PM
> > To: Wang Jianwei-B52261
> > Cc: dri-devel at lists.freedesktop.org; linux-kernel at vger.kernel.org;
> > linux-
> > arm-kernel at lists.infradead.org; devicetree at vger.kernel.org;
> > airlied at linux.ie; daniel.vetter at ffwll.ch; mark.yao at rock-chips.com;
> > Wood
> > Scott-B07421; Wang Huan-B18965; Xiubo Li
> > Subject: Re: [PATCH v6 1/4] drm/layerscape: Add Freescale DCU DRM driver
> >
> > On Fri, Jul 10, 2015 at 03:26:52PM +0800, Jianwei Wang wrote:
> > > + .atomic_check = fsl_dcu_drm_encoder_atomic_check,
> >
> > .atomic_check is optional
> >
>
> I try to remove .atomic_check, but it will cause CPU hang when starting up
> And I find this in drivers/gpu/drm/drm_atomic_helper.c
>
> 293 if (funcs->atomic_check) {
> 294 ret = funcs->atomic_check(encoder, crtc_state,
> 295 conn_state);
> 296 if (ret) {
> 297 DRM_DEBUG_ATOMIC("[ENCODER:%d:%s] check
> failed\n",
> 298 encoder->base.id,
> encoder->name);
> 299 return ret;
> 300 }
> 301 } else {
> 302 ret = funcs->mode_fixup(encoder,
> &crtc_state->mode,
> 303
> &crtc_state->adjusted_mode);
> 304 if (!ret) {
> 305 DRM_DEBUG_ATOMIC("[ENCODER:%d:%s] fixup
> failed\n",
> 306 encoder->base.id,
> encoder->name);
> 307 return -EINVAL;
> 308 }
> 309 }
> It means that I have to implement at least one of atomic_check and mode_fixup.
> So I reserve atomic_check.
> Is there problem? Please give me some more comments if necessary. Thanks!
Ah sorry you are right, atomic check is not optional. Unfortunately the
optional-or-not thing has grown a bit organically so there's no clear
rules.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Device enumeration support in libdrm
On 9 July 2015 at 03:26, Zhou, Jammy wrote: > Although I don't like the method of manually iterating sysfs, it seems the > last resort if we want to avoid introducing libudev dependency. > I have the same feeling, so if anyone can come with an better solution I'm all ears. > Besides, you mentioned that you would spend some time on the device > enumeration interface, do you have some chance to look at it? > Not really bth. Waiting for a month someone to ack the revert inspired me to push this at the bottom on my list. Now that there is some interest I'll bring it back up. -Emil
[Intel-gfx] [v3 0/7] Crystalcove (CRC) PMIC based panel and pwm control
On Mon, Jun 29, 2015 at 3:48 AM, Paul Gortmaker wrote: > [Re: [Intel-gfx] [v3 0/7] Crystalcove (CRC) PMIC based panel and pwm control] > On 26/06/2015 (Fri 20:47) Ville Syrjälä wrote: > >> On Fri, Jun 26, 2015 at 06:31:37PM +0200, Daniel Vetter wrote: >> > On Fri, Jun 26, 2015 at 02:32:03PM +0530, Shobhit Kumar wrote: >> > > Hi, >> > > Next update of the series reviewed at >> > > https://lkml.org/lkml/2015/6/22/155 >> > > >> > > Major changes are few review comments from Varka and Ville being >> > > addressed. Also except >> > > for intel-gfx patches, all patches reviesion history is moved out of >> > > commit message. >> > > >> > > Hope this series finally finds its mark. >> > > >> > > Regards >> > > Shobhit >> > > >> > > Shobhit Kumar (7): >> > > gpiolib: Add support for removing registered consumer lookup table >> > > mfd: intel_soc_pmic_core: Add lookup table for Panel Control as GPIO >> > > signal >> > > mfd: intel_soc_pmic_crc: Add PWM cell device for Crystalcove PMIC >> > > mfd: intel_soc_pmic_core: ADD PWM lookup table for CRC PMIC based PWM >> > > pwm: crc: Add Crystalcove (CRC) PWM driver >> > > drm/i915: Use the CRC gpio for panel enable/disable >> > > drm/i915: Backlight control using CRC PMIC based PWM driver >> > >> > I think we have r-b/acks on all the patches now. Ok if I pull this in >> > through drm-intel.git for 4.3? Or should I make a topic branch with tag >> > and then send out pull requests to everyone? Or will each maintainer merge >> > on their own since it's all only coupled at runtime anyway? Any of these >> > would suit me. >> >> I forgot to mention that I had a build failure due to >> builtin_platform_driver() when I tried this (just changed it to >> module_platform_driver() to get past it). So I'm not sure if this >> now depends on some tree which isn't included in -nightly... > > builtin_platform_register does not yet exist in mainline; as Paul (the > other one) said earlier. So you can either open-code what it does for > now, or use module_platform_register. If you do the latter, then > ensure you (temorarily) also include module.h or you risk additional > breakage in the future. > Guess its in mainline now. Whats the plan for the merge of these patches ? Regards Shobhit > Paul. > -- > >> >> -- >> Ville Syrjälä >> Intel OTC > ___ > Intel-gfx mailing list > Intel-gfx at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Bug 91294] [R7 370] DPM and power profile change crash the system
https://bugs.freedesktop.org/show_bug.cgi?id=91294 --- Comment #4 from Elia Argentieri --- Created attachment 117037 --> https://bugs.freedesktop.org/attachment.cgi?id=117037&action=edit Xorg.log -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150710/1c4c1608/attachment-0001.html>
[Bug 91294] [R7 370] DPM and power profile change crash the system
https://bugs.freedesktop.org/show_bug.cgi?id=91294 Elia Argentieri changed: What|Removed |Added Attachment #117032|0 |1 is obsolete|| --- Comment #3 from Elia Argentieri --- Created attachment 117036 --> https://bugs.freedesktop.org/attachment.cgi?id=117036&action=edit Full dmesg with radeon.dpm=0 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150710/51f84869/attachment.html>
[Bug 76490] Hang during boot when DPM is on (R9 270X)
https://bugs.freedesktop.org/show_bug.cgi?id=76490 --- Comment #43 from Tobias Droste --- I don't think the voltage is a problem as the voltage used by the linux driver seems to be the same as by the windows driver. For my card it's 1238mV for high(er) clocks in windows and linux. I even tried to set 1238mV for all power profiles in the bios and it was still not working as expected. All these cards seem to use GDDR5 VRAM. Maybe the driver has to do something different for this type of RAM? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150710/700bdfba/attachment.html>
[Bug 91294] [R7 370] DPM and power profile change crash the system
https://bugs.freedesktop.org/show_bug.cgi?id=91294 --- Comment #2 from Elia Argentieri --- Created attachment 117035 --> https://bugs.freedesktop.org/attachment.cgi?id=117035&action=edit VBIOS MSI R7 370 Armor 2X -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150710/9a1abdd9/attachment.html>
[Bug 76490] Hang during boot when DPM is on (R9 270X)
https://bugs.freedesktop.org/show_bug.cgi?id=76490 --- Comment #42 from Daniel Exner --- My best guess is that clocks are propably ok, but voltage is too low, perhaps confused by the fact that all of those cards are "factory overclocked". -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150710/5ceef297/attachment.html>
[Bug 91294] [R7 370] DPM and power profile change crash the system
https://bugs.freedesktop.org/show_bug.cgi?id=91294 --- Comment #1 from Alex Deucher --- Please attach your full dmesg output and xorg log. Also attach a copy of your vbios. (as root) (use lspci to get the bus id) cd /sys/bus/pci/devices/ echo 1 > rom cat rom > /tmp/vbios.rom echo 0 > rom -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150710/de454fb4/attachment.html>
[Bug 76490] Hang during boot when DPM is on (R9 270X)
https://bugs.freedesktop.org/show_bug.cgi?id=76490 --- Comment #41 from Alex Deucher --- (In reply to Tobias Droste from comment #40) > > Do you think it's a problem with the kernel code or with the firmware? Does > windows use the same firmware for DPM? I think it's probably a driver bug. Windows and Linux use the same ucode. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150710/a8b39ddf/attachment.html>
[Bug 76490] Hang during boot when DPM is on (R9 270X)
https://bugs.freedesktop.org/show_bug.cgi?id=76490 --- Comment #40 from Tobias Droste --- Ah sorry the difference in the bios versions was me. I fiddled with it to try to get it to boot in linux without the workaround in the kernel. You are correct in linux and windows they are the same but GPU-Z seems to add some padding to the end. Here's another one with a pitcairn where DPM is not working: http://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/open-source-amd-linux/809784-r7-370-msi-armor-2x-2gb Do you think it's a problem with the kernel code or with the firmware? Does windows use the same firmware for DPM? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150710/23fd1c91/attachment.html>
[PATCH] drm/msm: Enable clocks during enable/disable_vblank() callbacks
AHB clock should be enabled before accessing registers during
enable/disable_vblank(). Since these 2 callbacks are called in
atomic context while clk_prepare may cause thread sleep, a work
is scheduled to control vblanks.
Signed-off-by: Hai Li
---
drivers/gpu/drm/msm/mdp/mdp4/mdp4_irq.c | 9
drivers/gpu/drm/msm/mdp/mdp5/mdp5_irq.c | 9
drivers/gpu/drm/msm/msm_drv.c | 73 -
drivers/gpu/drm/msm/msm_drv.h | 8
4 files changed, 97 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_irq.c
b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_irq.c
index 7369ee7f..64d24fc 100644
--- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_irq.c
+++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_irq.c
@@ -86,13 +86,22 @@ irqreturn_t mdp4_irq(struct msm_kms *kms)
int mdp4_enable_vblank(struct msm_kms *kms, struct drm_crtc *crtc)
{
+ struct mdp4_kms *mdp4_kms = to_mdp4_kms(to_mdp_kms(kms));
+
+ mdp4_enable(mdp4_kms);
mdp_update_vblank_mask(to_mdp_kms(kms),
mdp4_crtc_vblank(crtc), true);
+ mdp4_disable(mdp4_kms);
+
return 0;
}
void mdp4_disable_vblank(struct msm_kms *kms, struct drm_crtc *crtc)
{
+ struct mdp4_kms *mdp4_kms = to_mdp4_kms(to_mdp_kms(kms));
+
+ mdp4_enable(mdp4_kms);
mdp_update_vblank_mask(to_mdp_kms(kms),
mdp4_crtc_vblank(crtc), false);
+ mdp4_disable(mdp4_kms);
}
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_irq.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_irq.c
index 33bd4c6..2a578f2 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_irq.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_irq.c
@@ -112,15 +112,24 @@ irqreturn_t mdp5_irq(struct msm_kms *kms)
int mdp5_enable_vblank(struct msm_kms *kms, struct drm_crtc *crtc)
{
+ struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(kms));
+
+ mdp5_enable(mdp5_kms);
mdp_update_vblank_mask(to_mdp_kms(kms),
mdp5_crtc_vblank(crtc), true);
+ mdp5_disable(mdp5_kms);
+
return 0;
}
void mdp5_disable_vblank(struct msm_kms *kms, struct drm_crtc *crtc)
{
+ struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(kms));
+
+ mdp5_enable(mdp5_kms);
mdp_update_vblank_mask(to_mdp_kms(kms),
mdp5_crtc_vblank(crtc), false);
+ mdp5_disable(mdp5_kms);
}
/*
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index b7ef56e..5265933 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -116,6 +116,65 @@ u32 msm_readl(const void __iomem *addr)
return val;
}
+struct vblank_event {
+ struct list_head node;
+ int crtc_id;
+ bool enable;
+};
+
+static void vblank_ctrl_worker(struct work_struct *work)
+{
+ struct msm_vblank_ctrl *vbl_ctrl = container_of(work,
+ struct msm_vblank_ctrl, work);
+ struct msm_drm_private *priv = container_of(vbl_ctrl,
+ struct msm_drm_private, vblank_ctrl);
+ struct msm_kms *kms = priv->kms;
+ struct vblank_event *vbl_ev, *tmp;
+ unsigned long flags;
+
+ spin_lock_irqsave(&vbl_ctrl->lock, flags);
+ list_for_each_entry_safe(vbl_ev, tmp, &vbl_ctrl->event_list, node) {
+ list_del(&vbl_ev->node);
+ spin_unlock_irqrestore(&vbl_ctrl->lock, flags);
+
+ if (vbl_ev->enable)
+ kms->funcs->enable_vblank(kms,
+ priv->crtcs[vbl_ev->crtc_id]);
+ else
+ kms->funcs->disable_vblank(kms,
+ priv->crtcs[vbl_ev->crtc_id]);
+
+ kfree(vbl_ev);
+
+ spin_lock_irqsave(&vbl_ctrl->lock, flags);
+ }
+
+ spin_unlock_irqrestore(&vbl_ctrl->lock, flags);
+}
+
+static int vblank_ctrl_queue_work(struct msm_drm_private *priv,
+ int crtc_id, bool enable)
+{
+ struct msm_vblank_ctrl *vbl_ctrl = &priv->vblank_ctrl;
+ struct vblank_event *vbl_ev;
+ unsigned long flags;
+
+ vbl_ev = kzalloc(sizeof(*vbl_ev), GFP_ATOMIC);
+ if (!vbl_ev)
+ return -ENOMEM;
+
+ vbl_ev->crtc_id = crtc_id;
+ vbl_ev->enable = enable;
+
+ spin_lock_irqsave(&vbl_ctrl->lock, flags);
+ list_add_tail(&vbl_ev->node, &vbl_ctrl->event_list);
+ spin_unlock_irqrestore(&vbl_ctrl->lock, flags);
+
+ queue_work(priv->wq, &vbl_ctrl->work);
+
+ return 0;
+}
+
/*
* DRM operations:
*/
@@ -125,6 +184,14 @@ static int msm_unload(struct drm_device *dev)
struct msm_drm_private *priv = dev->dev_private;
struct msm_kms *kms = priv->kms;
struct msm_gpu *gpu = priv->gpu;
+ struct msm_vblank_ctrl *vbl_ctrl = &priv->vblank_ctrl;
+ struct vblank_event *vbl_ev, *tmp;
+
+ cancel_work_sync(&vbl_ctrl-
[Bug 91294] [R7 370] DPM and power profile change crash the system
https://bugs.freedesktop.org/show_bug.cgi?id=91294 Bug ID: 91294 Summary: [R7 370] DPM and power profile change crash the system Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: DRM/Radeon Assignee: dri-devel at lists.freedesktop.org Reporter: elia.argentieri at openmailbox.org Created attachment 117032 --> https://bugs.freedesktop.org/attachment.cgi?id=117032&action=edit dmesg | grep radeon with radeon.dpm=0 My system is unable to boot with an MSI R7 370 Armor 2X unless I put radeon.dpm=0 (or nomodeset) to the boot parameter. Also any change to the power profile results in an immediate lock up with blank screen or, sometimes, black and white vertical stripes. I think my issue is related with #77394 and #76490. Probably wrong frequency or voltages given that the MSI R7 370 Gaming 4G (which is the better version with higher frequency) works with DPM (http://www.phoronix.com/scan.php?page=article&item=linux-411-gallium&num=1) Tested with Linux 3.16, 4.0 and 4.1. lspci -nnk | grep VGA: 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Curacao PRO [Radeon R7 370 / R9 270/370 OEM] [1002:6811] (rev 81) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150710/62f980ed/attachment.html>
[PATCH] drm: Drop owner assignment from i2c_driver
On 10.07.2015 15:50, Mark yao wrote:
> On 2015å¹´07æ10æ¥ 13:36, Krzysztof Kozlowski wrote:
>> i2c_driver does not need to set an owner because i2c_register_driver()
>> will set it.
>>
>> Signed-off-by: Krzysztof Kozlowski
>>
>> ---
>>
>> The coccinelle script which generated the patch was sent here:
>> http://www.spinics.net/lists/kernel/msg2029903.html
>> ---
>> drivers/gpu/drm/bridge/ps8622.c | 1 -
>> drivers/gpu/drm/bridge/ptn3460.c| 1 -
>> drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 1 -
>> 3 files changed, 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/ps8622.c
>> b/drivers/gpu/drm/bridge/ps8622.c
>> index 1a6607beb29f..be881e9fef8f 100644
>> --- a/drivers/gpu/drm/bridge/ps8622.c
>> +++ b/drivers/gpu/drm/bridge/ps8622.c
>> @@ -668,7 +668,6 @@ static struct i2c_driver ps8622_driver = {
>> .remove= ps8622_remove,
>> .driver= {
>> .name= "ps8622",
>> -.owner= THIS_MODULE,
>> .of_match_table = ps8622_devices,
>> },
>> };
>> diff --git a/drivers/gpu/drm/bridge/ptn3460.c
>> b/drivers/gpu/drm/bridge/ptn3460.c
>> index 1b1bf2384815..0ffa3a6a206a 100644
>> --- a/drivers/gpu/drm/bridge/ptn3460.c
>> +++ b/drivers/gpu/drm/bridge/ptn3460.c
>> @@ -400,7 +400,6 @@ static struct i2c_driver ptn3460_driver = {
>> .remove= ptn3460_remove,
>> .driver= {
>> .name= "nxp,ptn3460",
>> -.owner= THIS_MODULE,
>> .of_match_table = ptn3460_match,
>> },
>> };
>> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
>> b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
>> index 01b558fe3695..9a0c2911272a 100644
>> --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
>> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
>> @@ -555,7 +555,6 @@ static struct platform_driver
>> rockchip_drm_platform_driver = {
>> .probe = rockchip_drm_platform_probe,
>> .remove = rockchip_drm_platform_remove,
>> .driver = {
>> -.owner = THIS_MODULE,
>
> But rockchip drm is platform driver not i2c_driver, why remove its .owner ?
Oh, indeed. Thanks for spotting this.
The 'owner' is set by core for platform drivers as well. Most platform
drivers were already converted (I think by Wolfram Sang). I extended
existing coccinelle script to fix also i2c_drivers and sometimes did not
notice that it was platform_driver.
I can split it into two different patches. Would that be ok?
Best regards,
Krzysztof
[PATCH v6 4/4] arm/dts/ls1021a: Add a TFT LCD panel dts node
Add a TFT LCD panel node. the TFT LCD panel is
WQVGA "480x272", and the bpp is 24.
Signed-off-by: Alison Wang
Signed-off-by: Xiubo Li
Signed-off-by: Jianwei Wang
---
arch/arm/boot/dts/ls1021a-twr.dts | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/ls1021a-twr.dts
b/arch/arm/boot/dts/ls1021a-twr.dts
index a2c591e..f6ad7ba 100644
--- a/arch/arm/boot/dts/ls1021a-twr.dts
+++ b/arch/arm/boot/dts/ls1021a-twr.dts
@@ -56,6 +56,17 @@
enet0_sgmii_phy = &sgmii_phy2;
enet1_sgmii_phy = &sgmii_phy0;
};
+
+ panel: panel {
+ compatible = "nec,nl4827hc19_05b";
+ };
+
+};
+
+&dcu {
+ panel = <&panel>;
+ status = "okay";
+
};
&dspi1 {
--
2.1.0.27.g96db324
[PATCH v6 3/4] arm/dts/ls1021a: Add DCU dts node
Add DCU node, DCU is a display controller of Freescale
named 2D-ACE.
Signed-off-by: Alison Wang
Signed-off-by: Xiubo Li
Signed-off-by: Jianwei Wang
---
.../devicetree/bindings/drm/fsl-dcu/fsl,dcu.txt| 49 ++
MAINTAINERS| 1 +
arch/arm/boot/dts/ls1021a.dtsi | 10 +
3 files changed, 60 insertions(+)
create mode 100644 Documentation/devicetree/bindings/drm/fsl-dcu/fsl,dcu.txt
diff --git a/Documentation/devicetree/bindings/drm/fsl-dcu/fsl,dcu.txt
b/Documentation/devicetree/bindings/drm/fsl-dcu/fsl,dcu.txt
new file mode 100644
index 000..d65631d
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/fsl-dcu/fsl,dcu.txt
@@ -0,0 +1,49 @@
+Device Tree bindings for Freescale DCU DRM Driver
+
+Required properties:
+- compatible: Should be one of
+ * "fsl,ls1021a-dcu".
+ * "fsl,vf610-dcu".
+- reg: Address and length of the register set for dcu.
+- clocks: From common clock binding: handle to dcu clock.
+- clock-names: From common clock binding: Shall be "dcu".
+- display: The phandle to display node.
+
+Required properties:
+- bits-per-pixel: <16> for RGB565,
+ <24> for RGB888,
+ <32> for RGB.
+
+Required timing node for dispplay sub-node:
+- display-timings: Refer to binding doc display-timing.txt for details.
+
+Examples:
+dcu: dcu at 2ce {
+ compatible = "fsl,ls1021a-dcu";
+ reg = <0x0 0x2ce 0x0 0x1>;
+ clocks = <&platform_clk 0>;
+ clock-names = "dcu";
+ big-endian;
+ display = <&display>;
+
+ display: display at 0 {
+ bits-per-pixel = <24>;
+
+ display-timings {
+ native-mode = <&timing0>;
+ timing0: nl4827hc19 {
+ clock-frequency = <1087>;
+ hactive = <480>;
+ vactive = <272>;
+ hback-porch = <2>;
+ hfront-porch = <2>;
+ vback-porch = <1>;
+ vfront-porch = <1>;
+ hsync-len = <41>;
+ vsync-len = <2>;
+ hsync-active = <1>;
+ vsync-active = <1>;
+ };
+ };
+ };
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index 9047c2b..b8d6ef5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3410,6 +3410,7 @@ M:Alison Wang
L: dri-devel at lists.freedesktop.org
S: Supported
F: drivers/gpu/drm/fsl-dcu/
+F: Documentation/devicetree/bindings/drm/fsl-dcu/
F: Documentation/devicetree/bindings/panel/nec,nl4827hc19_05b.txt
DRM DRIVERS FOR NVIDIA TEGRA
diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index c70bb27..6d6e3e2 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -383,6 +383,16 @@
<&platform_clk 1>;
};
+ dcu: dcu at 2ce {
+ compatible = "fsl,ls1021a-dcu";
+ reg = <0x0 0x2ce 0x0 0x1>;
+ interrupts = ;
+ clocks = <&platform_clk 0>;
+ clock-names = "dcu";
+ big-endian;
+ status = "disabled";
+ };
+
mdio0: mdio at 2d24000 {
compatible = "gianfar";
device_type = "mdio";
--
2.1.0.27.g96db324
[PATCH v6 2/4] drm/panel: simple: Add support for NEC NL4827HC19-05B 480x272 panel
This adds support for the NEC NL4827HC19-05B 480x272 panel to
the DRM simple panel driver.
Signed-off-by: Jianwei Wang
---
.../bindings/panel/nec,nl4827hc19_05b.txt | 8 +++
.../devicetree/bindings/vendor-prefixes.txt| 1 +
MAINTAINERS| 1 +
drivers/gpu/drm/panel/panel-simple.c | 26 ++
4 files changed, 36 insertions(+)
create mode 100644
Documentation/devicetree/bindings/panel/nec,nl4827hc19_05b.txt
diff --git a/Documentation/devicetree/bindings/panel/nec,nl4827hc19_05b.txt
b/Documentation/devicetree/bindings/panel/nec,nl4827hc19_05b.txt
new file mode 100644
index 000..6f6dbdd
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/nec,nl4827hc19_05b.txt
@@ -0,0 +1,7 @@
+NEC LCD Technologies,Ltd. WQVGA TFT LCD panel
+
+Required properties:
+- compatible: should be "nec,nl4827hc19_05b"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 8033919..9f22b3e 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -131,6 +131,7 @@ mundoreader Mundo Reader S.L.
murata Murata Manufacturing Co., Ltd.
mxicy Macronix International Co., Ltd.
national National Semiconductor
+necNEC LCD Technologies, Ltd.
neonodeNeonode Inc.
netgearNETGEAR
netlogic Broadcom Corporation (formerly NetLogic Microsystems)
diff --git a/MAINTAINERS b/MAINTAINERS
index b25b948..9047c2b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3410,6 +3410,7 @@ M:Alison Wang
L: dri-devel at lists.freedesktop.org
S: Supported
F: drivers/gpu/drm/fsl-dcu/
+F: Documentation/devicetree/bindings/panel/nec,nl4827hc19_05b.txt
DRM DRIVERS FOR NVIDIA TEGRA
M: Thierry Reding
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index f94201b..eee95f4 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1036,6 +1036,29 @@ static const struct panel_desc shelly_sca07010_bfn_lnn =
{
.bus_format = MEDIA_BUS_FMT_RGB666_1X18,
};
+static const struct drm_display_mode nec_nl4827hc19_05b_mode = {
+ .clock = 10870,
+ .hdisplay = 480,
+ .hsync_start = 480 + 2,
+ .hsync_end = 480 + 2 + 41,
+ .htotal = 480 + 2 + 41 + 2,
+ .vdisplay = 272,
+ .vsync_start = 272 + 2,
+ .vsync_end = 272 + 2 + 4,
+ .vtotal = 272 + 2 + 4 + 2,
+ .vrefresh = 74,
+};
+
+static const struct panel_desc nec_nl4827hc19_05b = {
+ .modes = &nec_nl4827hc19_05b_mode,
+ .num_modes = 1,
+ .size = {
+ .width = 480,
+ .height = 272,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X24
+};
+
static const struct of_device_id platform_of_match[] = {
{
.compatible = "ampire,am800480r3tmqwa1h",
@@ -1125,6 +1148,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "shelly,sca07010-bfn-lnn",
.data = &shelly_sca07010_bfn_lnn,
}, {
+ .compatible = "nec,nl4827hc19_05b",
+ .data = &nec_nl4827hc19_05b,
+ }, {
/* sentinel */
}
};
--
2.1.0.27.g96db324
[PATCH v6 1/4] drm/layerscape: Add Freescale DCU DRM driver
This patch add support for Two Dimensional Animation and Compositing Engine (2D-ACE) on the Freescale SoCs. 2D-ACE is a Freescale display controller. 2D-ACE describes the functionality of the module extremely well its name is a value that cannot be used as a token in programming languages. Instead the valid token "DCU" is used to tag the register names and function names. The Display Controller Unit (DCU) module is a system master that fetches graphics stored in internal or external memory and displays them on a TFT LCD panel. A wide range of panel sizes is supported and the timing of the interface signals is highly configurable. Graphics are read directly from memory and then blended in real-time, which allows for dynamic content creation with minimal CPU intervention. The features: (1) Full RGB888 output to TFT LCD panel. (2) For the current LCD panel, WQVGA "480x272" is supported. (3) Blending of each pixel using up to 4 source layers dependent on size of panel. (4) Each graphic layer can be placed with one pixel resolution in either axis. (5) Each graphic layer support RGB565 and RGB888 direct colors without alpha channel and BGRA BGRA ARGB1555 direct colors with an alpha channel and YUV422 format. (6) Each graphic layer support alpha blending with 8-bit resolution. This is a simplified version, only one primary plane, one framebuffer created for fbdev, one crtc, one connector for TFT LCD panel, an encoder. Signed-off-by: Alison Wang Signed-off-by: Xiubo Li Signed-off-by: Jianwei Wang --- Changed in V6 - Add NEC nl4827hc19_05b panel to panel-simple.c Adviced by Mark Yao - Add DRIVER_ATOMIC for driver_features Adviced by Mark Yao - check fsl_dev if it's NULL at PM suspend/resume Adviced by Mark Yao Changed in V5 - Update commit message - Add layer registers initialization - Remove unused functions - Rename driver folder Adviced by Stefan Agner - Move pixel clock control functions to fsl_dcu_drm_drv.c - remove redundant enable the clock implicitly using regmap - Add maintainer message Changed in V4: -This version doesn't have functionality changed Just a minor adjustment. Changed in V3: - Test driver on Vybrid board and add compatible string - Remove unused functions - set default crtc for encoder - replace legacy functions with atomic help functions Adviced by Daniel Vetter - Set the unique name of the DRM device - Implement irq handle function for vblank interrupt Changed in v2: - Add atomic support Adviced by Daniel Vetter - Modify bindings file - Rename node for compatibility - Move platform related code out for compatibility Adviced by Stefan Agner MAINTAINERS | 7 + drivers/gpu/drm/Kconfig | 2 + drivers/gpu/drm/Makefile| 1 + drivers/gpu/drm/fsl-dcu/Kconfig | 18 ++ drivers/gpu/drm/fsl-dcu/Makefile| 7 + drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_connector.c | 200 + drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_connector.h | 31 ++ drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 172 +++ drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.h | 22 ++ drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 379 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h | 223 ++ drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_fbdev.c | 26 ++ drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c | 42 +++ drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.h | 17 ++ drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c | 195 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.h | 23 ++ 16 files changed, 1365 insertions(+) create mode 100644 drivers/gpu/drm/fsl-dcu/Kconfig create mode 100644 drivers/gpu/drm/fsl-dcu/Makefile create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_connector.c create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_connector.h create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.h create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_fbdev.c create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.h create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.h diff --git a/MAINTAINERS b/MAINTAINERS index 6761318..b25b948 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3404,6 +3404,13 @@ S: Maintained F: drivers/gpu/drm/imx/ F: Documentation/devicetree/bindings/drm/imx/ +DRM DRIVERS FOR FREESCALE DCU +M: Jianwei Wang +M: Alison Wang +L: dri-devel at lists.freedesktop.org +S: Supported +F: drivers/gpu/drm/fsl-dcu/ + DRM DRIVERS FOR NVIDIA TEGRA M: Thierry Reding M: Terje Bergström diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm
[alsa-devel] [PATCH v2 02/12] device: property: find dependencies of a firmware node
On 2 July 2015 at 02:02, Rafael J. Wysocki wrote:
> On Wednesday, July 01, 2015 11:40:57 AM Tomeu Vizoso wrote:
>> Adds API that allows callers to find out what other firmware nodes a
>> node depends on.
>>
>> Implementors of bindings documentation can register callbacks that
>> return the dependencies of a node.
>>
>> Dependency information can be used to change the order in which devices
>> are probed, or to print a warning when a device node is going to be
>> probed without all its dependencies fulfilled.
>>
>> Signed-off-by: Tomeu Vizoso
>
> I'd like to see a description of the new API in English in the changelog.
Agreed.
>> ---
>>
>> Changes in v2:
>> - Allow bindings implementations register a function instead of using
>> class callbacks, as not only subsystems implement firmware bindings.
>>
>> drivers/base/property.c | 91
>>
>> include/linux/fwnode.h | 5 +++
>> include/linux/property.h | 12 +++
>> 3 files changed, 108 insertions(+)
>>
>> diff --git a/drivers/base/property.c b/drivers/base/property.c
>> index 8ead1ba..9d38ede 100644
>> --- a/drivers/base/property.c
>> +++ b/drivers/base/property.c
>> @@ -19,7 +19,13 @@
>> #include
>> #include
>>
>
> Please add a comment describing this structure. In particular, what it is
> supposed to be used for and how it is supposed to be used.
Ok.
>> +struct dependency_parser {
>> + struct list_head parser;
>
> I'd rather call this "list_node" or something like that.
Ok.
>> + void (*func)(struct fwnode_handle *fwnode, struct list_head *deps);
>> +};
>> +
>> static bool fwnode_match_enable = false;
>> +static LIST_HEAD(dependency_parsers);
>>
>> /**
>> * device_add_property_set - Add a collection of properties to a device
>> object.
>> @@ -553,6 +559,27 @@ bool device_dma_is_coherent(struct device *dev)
>> EXPORT_SYMBOL_GPL(device_dma_is_coherent);
>>
>> /**
>> + * fwnode_add_dependency - add firmware node to the passed dependency list
>> + * @fwnode: Firmware node to add to dependency list
>> + * @list: Dependency list to add the fwnode to
>> + */
>> +void fwnode_add_dependency(struct fwnode_handle *fwnode,
>> +struct list_head *list)
>> +{
>> + struct fwnode_dependency *dep;
>> +
>> + dep = kzalloc(sizeof(*dep), GFP_KERNEL);
>> + if (!dep)
>> + return;
>> +
>> + INIT_LIST_HEAD(&dep->dependency);
>> + dep->fwnode = fwnode;
>> +
>> + list_add_tail(&dep->dependency, list);
>> +}
>> +EXPORT_SYMBOL_GPL(fwnode_add_dependency);
>> +
>> +/**
>> * fwnode_get_parent - return the parent node of a device node
>> * @fwnode: Device node to find the parent node of
>> */
>> @@ -600,6 +627,70 @@ bool fwnode_is_compatible(struct fwnode_handle *fwnode,
>> const char *compatible)
>> EXPORT_SYMBOL_GPL(fwnode_is_compatible);
>>
>> /**
>> + * fwnode_add_dependency_parser - register dependency parser
>> + * @func: Function that will be called to find out dependencies of a node
>> + *
>> + * Registers a callback that will be called when collecting the dependencies
>> + * of a firmware node. The callback should inspect the properties of the
>> node
>> + * and call fwnode_add_dependency() for each dependency it recognizes, from
>> + * the bindings documentation.
>> + */
>> +void fwnode_add_dependency_parser(
>> + void (*func)(struct fwnode_handle *fwnode, struct list_head *deps))
>> +{
>> + struct dependency_parser *parser;
>> +
>> + parser = kzalloc(sizeof(*parser), GFP_KERNEL);
>> + if (!parser)
>> + return;
>> +
>> + INIT_LIST_HEAD(&parser->parser);
>> + parser->func = func;
>> +
>> + list_add_tail(&parser->parser, &dependency_parsers);
>
> We're modifying a global list here. Any locking needed? RCU? Whatever?
Oops.
>> +}
>> +EXPORT_SYMBOL_GPL(fwnode_add_dependency_parser);
>> +
>> +/**
>> + * fwnode_remove_dependency_parser - unregister dependency parser
>> + * @func: Function that was to be called to find out dependencies of a node
>> + */
>> +void fwnode_remove_dependency_parser(
>> + void (*func)(struct fwnode_handle *fwnode, struct list_head *deps))
>> +{
>> + struct dependency_parser *parser, *tmp;
>> +
>> + list_for_each_entry_safe(parser, tmp, &dependency_parsers, parser) {
>> + if (parser->func == func) {
>> + list_del(&parser->parser);
>> + kfree(parser);
>> + return;
>> + }
>> + }
>> +}
>> +EXPORT_SYMBOL_GPL(fwnode_remove_dependency_parser);
>> +
>> +/**
>> + * fwnode_get_dependencies - find out what dependencies a firmware node has
>> + * @fwnode: firmware node to find its dependencies
>> + * @deps: list of struct fwnode_dependency in which dependencies will be
>> placed
>> + */
>> +void fwnode_get_dependencies(struct fwnode_handle *fwnode,
>> + struct list_head *deps)
>> +{
>> + struct dependency_parser *parser;
>> + struct fwnode_handl
[PATCH] drm: Drop owner assignment from i2c_driver
On 2015å¹´07æ10æ¥ 15:01, Krzysztof Kozlowski wrote:
> On 10.07.2015 15:50, Mark yao wrote:
>> On 2015å¹´07æ10æ¥ 13:36, Krzysztof Kozlowski wrote:
>>> i2c_driver does not need to set an owner because i2c_register_driver()
>>> will set it.
>>>
>>> Signed-off-by: Krzysztof Kozlowski
>>>
>>> ---
>>>
>>> The coccinelle script which generated the patch was sent here:
>>> http://www.spinics.net/lists/kernel/msg2029903.html
>>> ---
>>>drivers/gpu/drm/bridge/ps8622.c | 1 -
>>>drivers/gpu/drm/bridge/ptn3460.c| 1 -
>>>drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 1 -
>>>3 files changed, 3 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/bridge/ps8622.c
>>> b/drivers/gpu/drm/bridge/ps8622.c
>>> index 1a6607beb29f..be881e9fef8f 100644
>>> --- a/drivers/gpu/drm/bridge/ps8622.c
>>> +++ b/drivers/gpu/drm/bridge/ps8622.c
>>> @@ -668,7 +668,6 @@ static struct i2c_driver ps8622_driver = {
>>>.remove= ps8622_remove,
>>>.driver= {
>>>.name= "ps8622",
>>> -.owner= THIS_MODULE,
>>>.of_match_table = ps8622_devices,
>>>},
>>>};
>>> diff --git a/drivers/gpu/drm/bridge/ptn3460.c
>>> b/drivers/gpu/drm/bridge/ptn3460.c
>>> index 1b1bf2384815..0ffa3a6a206a 100644
>>> --- a/drivers/gpu/drm/bridge/ptn3460.c
>>> +++ b/drivers/gpu/drm/bridge/ptn3460.c
>>> @@ -400,7 +400,6 @@ static struct i2c_driver ptn3460_driver = {
>>>.remove= ptn3460_remove,
>>>.driver= {
>>>.name= "nxp,ptn3460",
>>> -.owner= THIS_MODULE,
>>>.of_match_table = ptn3460_match,
>>>},
>>>};
>>> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
>>> b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
>>> index 01b558fe3695..9a0c2911272a 100644
>>> --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
>>> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
>>> @@ -555,7 +555,6 @@ static struct platform_driver
>>> rockchip_drm_platform_driver = {
>>>.probe = rockchip_drm_platform_probe,
>>>.remove = rockchip_drm_platform_remove,
>>>.driver = {
>>> -.owner = THIS_MODULE,
>> But rockchip drm is platform driver not i2c_driver, why remove its .owner ?
> Oh, indeed. Thanks for spotting this.
>
> The 'owner' is set by core for platform drivers as well. Most platform
> drivers were already converted (I think by Wolfram Sang). I extended
> existing coccinelle script to fix also i2c_drivers and sometimes did not
> notice that it was platform_driver.
>
> I can split it into two different patches. Would that be ok?
>
> Best regards,
> Krzysztof
>
Ok, Thanks for the fix.:-)
--
ï¼ark
[PATCH] drm: Drop owner assignment from i2c_driver
On 2015å¹´07æ10æ¥ 13:36, Krzysztof Kozlowski wrote:
> i2c_driver does not need to set an owner because i2c_register_driver()
> will set it.
>
> Signed-off-by: Krzysztof Kozlowski
>
> ---
>
> The coccinelle script which generated the patch was sent here:
> http://www.spinics.net/lists/kernel/msg2029903.html
> ---
> drivers/gpu/drm/bridge/ps8622.c | 1 -
> drivers/gpu/drm/bridge/ptn3460.c| 1 -
> drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 1 -
> 3 files changed, 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/ps8622.c b/drivers/gpu/drm/bridge/ps8622.c
> index 1a6607beb29f..be881e9fef8f 100644
> --- a/drivers/gpu/drm/bridge/ps8622.c
> +++ b/drivers/gpu/drm/bridge/ps8622.c
> @@ -668,7 +668,6 @@ static struct i2c_driver ps8622_driver = {
> .remove = ps8622_remove,
> .driver = {
> .name = "ps8622",
> - .owner = THIS_MODULE,
> .of_match_table = ps8622_devices,
> },
> };
> diff --git a/drivers/gpu/drm/bridge/ptn3460.c
> b/drivers/gpu/drm/bridge/ptn3460.c
> index 1b1bf2384815..0ffa3a6a206a 100644
> --- a/drivers/gpu/drm/bridge/ptn3460.c
> +++ b/drivers/gpu/drm/bridge/ptn3460.c
> @@ -400,7 +400,6 @@ static struct i2c_driver ptn3460_driver = {
> .remove = ptn3460_remove,
> .driver = {
> .name = "nxp,ptn3460",
> - .owner = THIS_MODULE,
> .of_match_table = ptn3460_match,
> },
> };
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> index 01b558fe3695..9a0c2911272a 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> @@ -555,7 +555,6 @@ static struct platform_driver
> rockchip_drm_platform_driver = {
> .probe = rockchip_drm_platform_probe,
> .remove = rockchip_drm_platform_remove,
> .driver = {
> - .owner = THIS_MODULE,
But rockchip drm is platform driver not i2c_driver, why remove its .owner ?
-Mark
> .name = "rockchip-drm",
> .of_match_table = rockchip_drm_dt_ids,
> .pm = &rockchip_drm_pm_ops,
[PATCH] drm: Drop owner assignment from i2c_driver
i2c_driver does not need to set an owner because i2c_register_driver()
will set it.
Signed-off-by: Krzysztof Kozlowski
---
The coccinelle script which generated the patch was sent here:
http://www.spinics.net/lists/kernel/msg2029903.html
---
drivers/gpu/drm/bridge/ps8622.c | 1 -
drivers/gpu/drm/bridge/ptn3460.c| 1 -
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 1 -
3 files changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ps8622.c b/drivers/gpu/drm/bridge/ps8622.c
index 1a6607beb29f..be881e9fef8f 100644
--- a/drivers/gpu/drm/bridge/ps8622.c
+++ b/drivers/gpu/drm/bridge/ps8622.c
@@ -668,7 +668,6 @@ static struct i2c_driver ps8622_driver = {
.remove = ps8622_remove,
.driver = {
.name = "ps8622",
- .owner = THIS_MODULE,
.of_match_table = ps8622_devices,
},
};
diff --git a/drivers/gpu/drm/bridge/ptn3460.c b/drivers/gpu/drm/bridge/ptn3460.c
index 1b1bf2384815..0ffa3a6a206a 100644
--- a/drivers/gpu/drm/bridge/ptn3460.c
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -400,7 +400,6 @@ static struct i2c_driver ptn3460_driver = {
.remove = ptn3460_remove,
.driver = {
.name = "nxp,ptn3460",
- .owner = THIS_MODULE,
.of_match_table = ptn3460_match,
},
};
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index 01b558fe3695..9a0c2911272a 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -555,7 +555,6 @@ static struct platform_driver rockchip_drm_platform_driver
= {
.probe = rockchip_drm_platform_probe,
.remove = rockchip_drm_platform_remove,
.driver = {
- .owner = THIS_MODULE,
.name = "rockchip-drm",
.of_match_table = rockchip_drm_dt_ids,
.pm = &rockchip_drm_pm_ops,
--
1.9.1
[PATCH] Drop owner assignment from i2c_driver (and platform left-overs)
Hi, The i2c drivers also do not have to set 'owner' field because i2c_register_driver() will do it instead. 'owner' is removed from i2c drivers, which I was able to compile with allyesconfig (arm, arm64, i386, x86_64, ppc64). Only compile-tested. The coccinelle script which generated the patch was sent here: http://www.spinics.net/lists/kernel/msg2029903.html Best regards, Krzysztof Krzysztof Kozlowski (1): drm: Drop owner assignment from i2c_driver drivers/gpu/drm/bridge/ps8622.c | 1 - drivers/gpu/drm/bridge/ptn3460.c| 1 - drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 1 - 3 files changed, 3 deletions(-) -- 1.9.1
[PATCH v3 2/2] 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 | 200
3 files changed, 207 insertions(+)
create mode 100644 drivers/smaf/smaf-cma.c
diff --git a/drivers/smaf/Kconfig b/drivers/smaf/Kconfig
index d36651a..058ec4c 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 && HAVE_DMA_ATTRS
+ help
+ Choose this option to enable CMA allocation within SMAF
diff --git a/drivers/smaf/Makefile b/drivers/smaf/Makefile
index 40cd882..05bab01 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..ab38717
--- /dev/null
+++ b/drivers/smaf/smaf-cma.c
@@ -0,0 +1,200 @@
+/*
+ * 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;
+ DEFINE_DMA_ATTRS(attrs);
+
+ dma_set_attr(DMA_ATTR_WRITE_COMBINE, &attrs);
+
+ dma_free_attrs(info->dev, info->size, info->vaddr, info->paddr, &attrs);
+
+ 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;
+ int ret;
+ DEFINE_DMA_ATTRS(attrs);
+
+ dma_set_attr(DMA_ATTR_WRITE_COMBINE, &attrs);
+
+ if (info->size < vma->vm_end - vma->vm_start)
+ return -EINVAL;
+
+ vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP;
+ ret = dma_mmap_attrs(info->dev, vma, info->vaddr, info->paddr,
+info->size, &attrs);
+
+ return ret;
+}
+
+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->paddr + offset;
+}
+
+static 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
[PATCH v3 1/2] 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 | 735 +
include/linux/smaf-allocator.h | 54 +++
include/linux/smaf-secure.h| 62
include/uapi/linux/smaf.h | 52 +++
8 files changed, 912 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 c0cc96b..2421fcb 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -182,4 +182,6 @@ source "drivers/thunderbolt/Kconfig"
source "drivers/android/Kconfig"
+source "drivers/smaf/Kconfig"
+
endmenu
diff --git a/drivers/Makefile b/drivers/Makefile
index 46d2554..0cca66e 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -165,3 +165,4 @@ obj-$(CONFIG_RAS) += ras/
obj-$(CONFIG_THUNDERBOLT) += thunderbolt/
obj-$(CONFIG_CORESIGHT)+= hwtracing/coresight/
obj-$(CONFIG_ANDROID) += android/
+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..90a7a97
--- /dev/null
+++ b/drivers/smaf/smaf-core.c
@@ -0,0 +1,735 @@
+/*
+ * smaf.c
+ *
+ * Copyright (C) Linaro SA 2015
+ * Author: Benjamin Gaignard for Linaro.
+ * License terms: GNU General Public License (GPL), version 2
+ */
+
+#include
+#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;
+ bool 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 struct smaf_device smaf_dev;
+
+/**
+ * smaf_allow_cpu_access return true if CPU can access to memory
+ * if their is no secure module associated to SMAF assume that CPU can get
+ * access to the memory.
+ */
+static bool smaf_allow_cpu_access(struct smaf_handle *handle,
+ unsigned long flags)
+{
+ if (!handle->is_secure)
+ return true;
+
+ if (!smaf_dev.secure)
+ return true;
+
+ if (!smaf_dev.secure->allow_cpu_access)
+ return true;
+
+ return smaf_dev.secure->allow_cpu_access(handle->secure_ctx, flags);
+}
+
+static int smaf_grant_access(struct smaf_handle *handle, struct device *dev,
+dma_addr_t addr, size_t size,
+enum dma_data_direction dir)
+{
+ if (!handle->is_secure)
+ return 0;
+
+ if (!smaf_dev.secure)
+ return -EINVAL;
+
+ if (!smaf_dev.secure->grant_access)
+ return -EINVAL;
+
+ return smaf_dev.secure->grant_access(handle->secure_ctx,
+
[PATCH v3 0/2] RFC: Secure Memory Allocation Framework
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
The outcome of the previous RFC about how do secure data path was the need
of a secure memory allocator (https://lkml.org/lkml/2015/5/5/551)
SMAF goal is to provide a framework that allow allocating and securing
memory by using dma_buf. Each platform have it own way to perform those two
features so SMAF design allow to register helper modules to perform them.
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.
I have named smaf-cma.c like it is done for drm_gem_cma_helper.c even if
a better name could be found for this file.
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 (2):
create SMAF module
SMAF: add CMA allocator
drivers/Kconfig| 2 +
drivers/Makefile | 1 +
drivers/smaf/Kconfig | 11 +
drivers/smaf/Makefile | 2 +
drivers/smaf/smaf-cma.c| 200 +++
drivers/smaf/smaf-core.c | 735 +
include/linux/smaf-allocator.h | 54 +++
include/linux/smaf-secure.h| 62
include/uapi/linux/smaf.h | 52 +++
9 files changed, 1119 insertions(+)
create mode 100644 drivers/smaf/Kconfig
create mode 100644 drivers/smaf/Makefile
create mode 100644 drivers/smaf/smaf-cma.c
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
--
1.9.1
Wayland and GLES1 (Re: R200 DRM/KMS)
On Thu Jul 9 17:02:12 2015 GMT+0100, Steven Newbury wrote: > On Thu Jul 9 16:04:35 2015 GMT+0100, Alex Deucher wrote: > > On Thu, Jul 9, 2015 at 2:58 AM, Steven Newbury > > wrote: > > > > > > > > > On Thu Jul 9 03:32:40 2015 GMT+0100, Michel Dänzer wrote: > > >> On 09.07.2015 06:01, Steven Newbury wrote: > > >> > On Wed, 2015-07-08 at 21:56 +0100, Steven Newbury wrote: > > >> >> On Tue, 2015-07-07 at 09:18 +0300, Pekka Paalanen wrote: > > >> >>> On Mon, 06 Jul 2015 22:50:30 +0100 Steven Newbury > > >> >>> wrote: > > >> >>> > > >> Would gles1 be sufficient to run a Wayland compositor, I'm > > >> guessing probably not..? > > >> >>> > > >> >>> If you can find a Wayland compositor that is written to composite > > >> >>> with GLES1, that's all you need from the "Wayland side". (Yeah, > > >> >>> this has nothing to do with Wayland per se.) Compositing in > > >> >>> itself without any effects is very simple, as long as you get the > > >> >>> textures up. > > >> >>> > > >> >>> Or, if you find a Wayland compositor written to use desktop > > >> >>> OpenGL for compositing and does not use features your GL driver > > >> >>> does not expose, that's good too. > > >> >>> > > >> >> Is desktop OpenGL accessible from "EGL_PLATFORM=drm"? > > >> >> > > >> > To answer my own question, it seems that is possible. I wonder if > > >> > it works with mutter/cogl??? > > >> > > >> It does. > > >> > > >> However, your problem seems rather that gnome-shell/mutter doesn't > > >> support R200 anymore. > > > Yes, that's true. I wonder if I can revert the incompatible change or > > > better create a env variable to revert to the compatible behaviour or > > > something? I'll need to take a look... > > > > I'm not sure how valid this is any more: > > https://bugs.freedesktop.org/show_bug.cgi?id=51658 > > > > Basic issue is that r1xx/r2xx hw only has a limited number of render > > buffer formats while they support a lot of texture formats. Gnome > > shell expects to be able to render to the same formats they can > > texture from. > > > It looks like a bit of a hack, it's a pity to lose valid texture formats, but > I've applied the patches from the bug after a little manual intervention. > It's building now, will take some time! Didn't work. Still get the same error! :-( On the other hand, I've got muffin to work compositor is actually okay, so thought I'd try cinnamon, but it's trying to use 1.5GB which isn't going to work! ;-) Will probably revert to Xfce... -- Sent from my Jolla
Wayland and GLES1 (Re: R200 DRM/KMS)
On Thu Jul 9 17:02:12 2015 GMT+0100, Steven Newbury wrote: > On Thu Jul 9 16:04:35 2015 GMT+0100, Alex Deucher wrote: > > On Thu, Jul 9, 2015 at 2:58 AM, Steven Newbury > > wrote: > > > > > > > > > On Thu Jul 9 03:32:40 2015 GMT+0100, Michel Dänzer wrote: > > >> On 09.07.2015 06:01, Steven Newbury wrote: > > >> > On Wed, 2015-07-08 at 21:56 +0100, Steven Newbury wrote: > > >> >> On Tue, 2015-07-07 at 09:18 +0300, Pekka Paalanen wrote: > > >> >>> On Mon, 06 Jul 2015 22:50:30 +0100 Steven Newbury > > >> >>> wrote: > > >> >>> > > >> Would gles1 be sufficient to run a Wayland compositor, I'm > > >> guessing probably not..? > > >> >>> > > >> >>> If you can find a Wayland compositor that is written to composite > > >> >>> with GLES1, that's all you need from the "Wayland side". (Yeah, > > >> >>> this has nothing to do with Wayland per se.) Compositing in > > >> >>> itself without any effects is very simple, as long as you get the > > >> >>> textures up. > > >> >>> > > >> >>> Or, if you find a Wayland compositor written to use desktop > > >> >>> OpenGL for compositing and does not use features your GL driver > > >> >>> does not expose, that's good too. > > >> >>> > > >> >> Is desktop OpenGL accessible from "EGL_PLATFORM=drm"? > > >> >> > > >> > To answer my own question, it seems that is possible. I wonder if > > >> > it works with mutter/cogl??? > > >> > > >> It does. > > >> > > >> However, your problem seems rather that gnome-shell/mutter doesn't > > >> support R200 anymore. > > > Yes, that's true. I wonder if I can revert the incompatible change or > > > better create a env variable to revert to the compatible behaviour or > > > something? I'll need to take a look... > > > > I'm not sure how valid this is any more: > > https://bugs.freedesktop.org/show_bug.cgi?id=51658 > > > > Basic issue is that r1xx/r2xx hw only has a limited number of render > > buffer formats while they support a lot of texture formats. Gnome > > shell expects to be able to render to the same formats they can > > texture from. > > > It looks like a bit of a hack, it's a pity to lose valid texture formats, but > I've applied the patches from the bug after a little manual intervention. > It's building now, will take some time! Didn't work. Still get the same error! :-( On the other hand, I've got muffin to work compositor is actually okay, so thought I'd try cinnamon, but it's trying to use 1.5GB which isn't going to work! ;-) Will probably revert to Xfce... -- Sent from my Jolla
[PATCH v2 01/12] device: property: delay device-driver matches
On 2 July 2015 at 01:29, Rafael J. Wysocki wrote:
> On Wednesday, July 01, 2015 11:40:56 AM Tomeu Vizoso wrote:
>> Delay matches of platform devices until late_initcall, when we are sure
>> that all built-in drivers have been registered already. This is needed
>> to prevent deferred probes because of some dependencies' drivers not
>> having registered yet.
>>
>> This reduces the total amount of work that the kernel does during boot
>> because it won't try to match devices to drivers when built-in drivers
>> are still registering but also reduces some parallelism, so total boot
>> time might slightly increase or decrease depending on the platform and
>> kernel configuration.
>>
>> This change will make make possible to prevent any deferred probes once
>> devices are probed in dependency order.
>>
>> Signed-off-by: Tomeu Vizoso
>> ---
>>
>> Changes in v2:
>> - Instead of delaying all probes until late_initcall, only delay matches
>> of platform devices that have a firmware node attached.
>>
>> drivers/base/property.c | 29 +
>> 1 file changed, 29 insertions(+)
>>
>> diff --git a/drivers/base/property.c b/drivers/base/property.c
>> index 8528eb9..8ead1ba 100644
>> --- a/drivers/base/property.c
>> +++ b/drivers/base/property.c
>> @@ -16,8 +16,11 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>>
>> +static bool fwnode_match_enable = false;
>> +
>> /**
>> * device_add_property_set - Add a collection of properties to a device
>> object.
>> * @dev: Device to add properties to.
>> @@ -604,6 +607,15 @@ EXPORT_SYMBOL_GPL(fwnode_is_compatible);
>> bool fwnode_driver_match_device(struct device *dev,
>> const struct device_driver *drv)
>> {
>> + /*
>> + * Delay matches of platform devices until late_initcall, when we are
>> + * sure that all built-in drivers have been registered already. This
>> + * is needed to prevent deferred probes because of some drivers
>> + * not having registered yet.
>> + */
>> + if(dev->bus == &platform_bus_type && !fwnode_match_enable)
>> + return false;
>
> I'm not particularly enthusiastic about referring to specific bus types in
> generic code like that.
Agreed.
> What about having a special version of fwnode_driver_match_device()
> specifically
> for the platform bus type that will do the check?
Have moved all this code to base/platform.c instead, as I don't see
any reason to have it in property.c.
Thanks,
Tomeu
>> +
>> if (is_of_node(dev->fwnode))
>> return of_driver_match_device(dev, drv);
>> else if (is_acpi_node(dev->fwnode))
>> @@ -612,3 +624,20 @@ bool fwnode_driver_match_device(struct device *dev,
>> return false;
>> }
>> EXPORT_SYMBOL_GPL(fwnode_driver_match_device);
>> +
>> +static int __device_attach(struct device *dev, void *data)
>> +{
>> + device_initial_probe(dev);
>> +
>> + return 0;
>> +}
>> +
>> +static int fwnode_match_initcall(void)
>> +{
>> + fwnode_match_enable = true;
>> +
>> + bus_for_each_dev(&platform_bus_type, NULL, NULL, __device_attach);
>> +
>> + return 0;
>> +}
>> +late_initcall(fwnode_match_initcall);
>>
>
> --
> I speak only for myself.
> Rafael J. Wysocki, Intel Open Source Technology Center.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the drm-intel tree with the drm-intel-fixes tree
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/intel_ringbuffer.h
between commit:
ee412ecc74c4 ("drm/i915: Snapshot seqno of most recently submitted request.")
from the drm-intel-fixes tree and commit:
bccca494f75c ("drm/i915: Remove the now obsolete 'outstanding_lazy_request'")
from the drm-intel tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwellsfr at canb.auug.org.au
diff --cc drivers/gpu/drm/i915/intel_ringbuffer.h
index 4be66f60504d,0ea89ea30182..
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@@ -271,17 -292,6 +292,13 @@@ struct intel_engine_cs
*/
struct list_head request_list;
+ /**
-* Do we have some not yet emitted requests outstanding?
-*/
- struct drm_i915_gem_request *outstanding_lazy_request;
- /**
+ * Seqno of request most recently submitted to request_list.
+ * Used exclusively by hang checker to avoid grabbing lock while
+ * inspecting request list.
+ */
+ u32 last_submitted_seqno;
+
bool gpu_caches_dirty;
wait_queue_head_t irq_queue;
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150710/523b57a9/attachment.sig>
linux-next: manual merge of the drm-intel tree with the drm-intel-fixes tree
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/i915_drv.h
between commit:
8146ba1637a7 ("drm/i915: Store device pointer in contexts for late tracepoint
usafe")
from the drm-intel-fixes tree and commit:
b1b38278e12b ("drm/i915: add a context parameter to {en, dis}able zero
address mapping")
from the drm-intel tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwellsfr at canb.auug.org.au
diff --cc drivers/gpu/drm/i915/i915_drv.h
index 580762001f31,52d07fbd9cc8..
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@@ -826,7 -866,7 +866,8 @@@ struct intel_context
struct kref ref;
int user_handle;
uint8_t remap_slice;
+ struct drm_i915_private *i915;
+ int flags;
struct drm_i915_file_private *file_priv;
struct i915_ctx_hang_stats hang_stats;
struct i915_hw_ppgtt *ppgtt;
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150710/a2ed76e2/attachment.sig>
[Bug 91279] agd5f drm tonga occasional traps error:0 in libdrm_amdgpu.so.1.0.0
https://bugs.freedesktop.org/show_bug.cgi?id=91279 --- Comment #3 from Andy Furniss --- Should add - I've been playing around quite a bit with vdpau/uvd with mplayer, mpv and ffmpeg - AFAICT I haven't managed to trigger this using them. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150710/9e1dd7e3/attachment.html>
[PATCH v6 1/4] drm/layerscape: Add Freescale DCU DRM driver
Hi Emil, Thank you for your guidance. I'll pay attention about this next time. BR. Jianwei > -Original Message- > From: linux-kernel-owner at vger.kernel.org [mailto:linux-kernel- > owner at vger.kernel.org] On Behalf Of Emil Velikov > Sent: Friday, July 10, 2015 4:42 PM > To: Wang Jianwei-B52261 > Cc: mark.yao; devicetree at vger.kernel.org; Xiubo Li; Wang Huan-B18965; > daniel.vetter at ffwll.ch; linux-kernel at vger.kernel.org; dri- > devel at lists.freedesktop.org; Wood Scott-B07421; linux-arm- > kernel at lists.infradead.org > Subject: Re: [PATCH v6 1/4] drm/layerscape: Add Freescale DCU DRM driver > > Hi Jianwei, > > On 10 July 2015 at 08:47, Wang J.W. wrote: > > Hi Mark, > > > > Thank you very much for your review! I have update my DRM driver. > > All your three comments have been applied in this latest version. > > I replied the last email several times, but all refused the mailist. > I'd suspect that the ML automatically refused the email due to its size. > To avoid that in the future you can trim the email to include only the > relevant parts (not applicable in this case I know). At the same time it > makes reading a bit easier, and missing buried comments harder :-) > > Hope that helps, > Emil > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo at vger.kernel.org More majordomo info at > http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/
R200 DRM/KMS
On Wed, 2015-07-08 at 23:44 +0100, Emil Velikov wrote: ... > > > > > I guess it doesn't really matter since patching out the code > > "fixes" > > it... > As you wish. Personally I tend to give it a bit more before giving > up. > I typically would, but it isn't my machine, and my priority is getting the system up as that's what I promised to do! Also, given there doesn't really seem to be any point to the call to drmSetInterfaceVersion(), as has been pointed out, simply removing it doesn't hurt - although it admittedly irks me as to how/why it can be failing. > As this is getting a bit long/messy I'd suspect that a bugzilla entry > with information/logs might be good. It's up-to you, as I won't be > able to help much more. Simply getting feedback has been helpful. Yes, I should open a bugzilla entry, I'll get to it after I have the system up and running. It's probably getting tough to maintain R200 support at this point, particularly on ancient pre-millennial PCI only systems with buggy* BIOSes! ;-) * The BIOS option to disable the onboard video is present, and the help test lists 3 options, Enabled - 512KB, Enabled - 1MB, Disabled. Only the first two options actually appear on the menu! Even better, the system only (re-)boots on the second attempt, first attempt always hangs post-POST, before attempting to read from boot media!
[Bug 91291] kernel panic and freeze on resume in [radeon] [ttm]
https://bugs.freedesktop.org/show_bug.cgi?id=91291 --- Comment #2 from Kamil Páral --- Created attachment 117027 --> https://bugs.freedesktop.org/attachment.cgi?id=117027&action=edit kernel trace - shot2 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150710/d4d8ca23/attachment.html>
[Bug 91291] kernel panic and freeze on resume in [radeon] [ttm]
https://bugs.freedesktop.org/show_bug.cgi?id=91291 --- Comment #1 from Kamil Páral --- Created attachment 117026 --> https://bugs.freedesktop.org/attachment.cgi?id=117026&action=edit kernel trace - shot1 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150710/ebac6921/attachment.html>
[Bug 91291] kernel panic and freeze on resume in [radeon] [ttm]
https://bugs.freedesktop.org/show_bug.cgi?id=91291 Bug ID: 91291 Summary: kernel panic and freeze on resume in [radeon] [ttm] Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel at lists.freedesktop.org Reporter: kparal at redhat.com A few times in a month, my computer fails to resume and just hangs, with black screen, and needs hard reset. This time I got lucky and kernel panic text was shown on my screen, so I took a shot of it. There's a lot of [ttm] and [radeon] strings in it, so it looks like it is related to my Radeon card. The text on the screen has "scrolled" once in a while (it seemed to be rotation), I hope I captured everything important. Components: Radeon R9 270: 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Curacao PRO [Radeon R7 370 / R9 270/370 OEM] [1002:6811] fully updated Fedora 22: kernel-4.0.7-300.fc22.x86_64 xorg-x11-server-Xorg-1.17.2-1.fc22.x86_64 xorg-x11-drv-ati-7.5.0-3.fc22.x86_64 libdrm-2.4.61-3.fc22.x86_64 mesa-dri-drivers-10.6.1-1.20150629.fc22.x86_64 Please tell me if I can add more useful information somehow. That issue is not easily reproducible, it happens rarely and usually I just see a black screen, so I can't even tell whether it is always the same issue or not. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150710/9839e126/attachment.html>
[Bug 91279] agd5f drm tonga occasional traps error:0 in libdrm_amdgpu.so.1.0.0
https://bugs.freedesktop.org/show_bug.cgi?id=91279 --- Comment #2 from Andy Furniss --- (In reply to Michel Dänzer from comment #1) > Can you get a gdb backtrace of such a crash? Yea - should have thought to enable core dumps. So it seems it's flash (even though I have an apparently functioning flashblock enabled in seamonkey) Core was generated by `/usr/lib/seamonkey-2.33.1/plugin-container /usr/lib/mozilla/plugins/libflashpla'. Program terminated with signal SIGSEGV, Segmentation fault. #0 list_del (item=0x5a5a5a5a5a5a5a5a) at ../util_double_list.h:79 79 item->prev->next = item->next; (gdb) bt #0 list_del (item=0x5a5a5a5a5a5a5a5a) at ../util_double_list.h:79 #1 amdgpu_vamgr_deinit (mgr=0x7fa26ec0b4c0 ) at amdgpu_vamgr.c:47 #2 amdgpu_vamgr_reference (dst=0x7fa274e19ea0, src=0x0) at amdgpu_vamgr.c:67 #3 0x7fa26ea07d82 in amdgpu_device_free_internal (dev=0x7fa274e19c00) at amdgpu_device.c:228 #4 0x7fa26ea07e09 in amdgpu_device_reference (dst=dst at entry=0x7ffd04cca7a8, src=src at entry=0x0) at amdgpu_device.c:246 #5 0x7fa26ea08125 in amdgpu_device_deinitialize (dev=0x7fa274e19c00) at amdgpu_device.c:238 #6 0x7fa26f54fa1f in amdgpu_winsys_destroy (rws=0x7fa274e91800) at amdgpu_winsys.c:296 #7 0x7fa26f553f5f in r600_destroy_common_screen (rscreen=0x7fa274e1a000) at r600_pipe_common.c:963 #8 0x7fa26f46a7a1 in vl_screen_destroy (vscreen=0x7fa274e2cb00) at vl/vl_winsys_dri.c:431 #9 0x7fa26f464776 in vlVdpDeviceFree (dev=dev at entry=0x7fa274eb3140) at device.c:230 #10 0x7fa26f464874 in DeviceReference (dev=0x0, ptr=) at vdpau_private.h:553 #11 vlVdpDeviceDestroy (device=1) at device.c:215 #12 0x7fa273ea8df8 in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so #13 0x7fa273b08475 in ?? () from /usr/lib/mozilla/plugins/libflashplayer.so -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150710/d5a347e4/attachment.html>
[Intel-gfx] [PATCH 06/14] drm/i915: Use drm_for_each_fb in i915_debugfs.c
On Thu, Jul 09, 2015 at 11:44:29PM +0200, Daniel Vetter wrote:
> Just so I have a user for this macro.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 053adbb97037..60eebf5f6da8 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -1855,6 +1855,7 @@ static int i915_gem_framebuffer_info(struct seq_file
> *m, void *data)
> struct drm_device *dev = node->minor->dev;
> struct intel_fbdev *ifbdev = NULL;
> struct intel_framebuffer *fb;
> + struct drm_framebuffer *drm_fb;
>
> #ifdef CONFIG_DRM_I915_FBDEV
> struct drm_i915_private *dev_priv = dev->dev_private;
> @@ -1874,7 +1875,8 @@ static int i915_gem_framebuffer_info(struct seq_file
> *m, void *data)
> #endif
>
> mutex_lock(&dev->mode_config.fb_lock);
> - list_for_each_entry(fb, &dev->mode_config.fb_list, base.head) {
> + drm_for_each_plane(drm_fb, dev) {
^
That's no fb.
> + fb = to_intel_framebuffer(drm_fb);
> if (ifbdev && &fb->base == ifbdev->helper.fb)
> continue;
>
> --
> 2.1.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
[PATCH v6 1/4] drm/layerscape: Add Freescale DCU DRM driver
Hi Daniel, Thank you very much for your review! See below... > -Original Message- > From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of Daniel > Vetter > Sent: Friday, July 10, 2015 4:00 PM > To: Wang Jianwei-B52261 > Cc: dri-devel at lists.freedesktop.org; linux-kernel at vger.kernel.org; > linux- > arm-kernel at lists.infradead.org; devicetree at vger.kernel.org; > airlied at linux.ie; daniel.vetter at ffwll.ch; mark.yao at rock-chips.com; > Wood > Scott-B07421; Wang Huan-B18965; Xiubo Li > Subject: Re: [PATCH v6 1/4] drm/layerscape: Add Freescale DCU DRM driver > > On Fri, Jul 10, 2015 at 03:26:52PM +0800, Jianwei Wang wrote: > > This patch add support for Two Dimensional Animation and Compositing > > Engine (2D-ACE) on the Freescale SoCs. > > > > 2D-ACE is a Freescale display controller. 2D-ACE describes > > the functionality of the module extremely well its name is a value > > that cannot be used as a token in programming languages. > > Instead the valid token "DCU" is used to tag the register names and > > function names. > > > > The Display Controller Unit (DCU) module is a system master that > > fetches graphics stored in internal or external memory and displays > > them on a TFT LCD panel. A wide range of panel sizes is supported > > and the timing of the interface signals is highly configurable. > > Graphics are read directly from memory and then blended in real-time, > > which allows for dynamic content creation with minimal CPU > > intervention. > > > > The features: > > (1) Full RGB888 output to TFT LCD panel. > > (2) For the current LCD panel, WQVGA "480x272" is supported. > > (3) Blending of each pixel using up to 4 source layers > > dependent on size of panel. > > (4) Each graphic layer can be placed with one pixel resolution > > in either axis. > > (5) Each graphic layer support RGB565 and RGB888 direct colors > > without alpha > > channel and BGRA BGRA ARGB1555 direct colors with an > > alpha channel and > > YUV422 format. > > (6) Each graphic layer support alpha blending with 8-bit > > resolution. > > > > This is a simplified version, only one primary plane, one > > framebuffer created for > > fbdev, one crtc, one connector for TFT LCD panel, an encoder. > > > > Signed-off-by: Alison Wang > > Signed-off-by: Xiubo Li > > Signed-off-by: Jianwei Wang > > A few small things to polish that I spotted. > -Daniel > > > --- > > > > > > Changed in V6 > > > > - Add NEC nl4827hc19_05b panel to panel-simple.c > > Adviced by Mark Yao > > - Add DRIVER_ATOMIC for driver_features > > Adviced by Mark Yao > > - check fsl_dev if it's NULL at PM suspend/resume > > Adviced by Mark Yao > > > > Changed in V5 > > > > - Update commit message > > - Add layer registers initialization > > - Remove unused functions > > - Rename driver folder > > Adviced by Stefan Agner > > - Move pixel clock control functions to fsl_dcu_drm_drv.c > > - remove redundant enable the clock implicitly using regmap > > - Add maintainer message > > > > Changed in V4: > > > > -This version doesn't have functionality changed > > Just a minor adjustment. > > > > Changed in V3: > > > > - Test driver on Vybrid board and add compatible string > > - Remove unused functions > > - set default crtc for encoder > > - replace legacy functions with atomic help functions > > Adviced by Daniel Vetter > > - Set the unique name of the DRM device > > - Implement irq handle function for vblank interrupt > > > > Changed in v2: > > - Add atomic support > > Adviced by Daniel Vetter > > - Modify bindings file > > - Rename node for compatibility > > - Move platform related code out for compatibility > > Adviced by Stefan Agner > > > > > > MAINTAINERS | 7 + > > drivers/gpu/drm/Kconfig | 2 + > > drivers/gpu/drm/Makefile| 1 + > > drivers/gpu/drm/fsl-dcu/Kconfig | 18 ++ > > drivers/gpu/drm/fsl-dcu/Makefile| 7 + > > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_connector.c | 200 + > > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_connector.h | 31 ++ > > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 172 +++ > > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.h | 22 ++ > > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 379 > > > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h | 223 ++ > > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_fbdev.c | 26 ++ > > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c | 42 +++ > > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.h | 17 ++ > > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c | 195 > > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.h | 23 ++ > > 16 files changed, 1365 insertions(+) > > create mode 100644 drivers/gpu/drm/fsl-dcu/Kconfig > > create mode 100644 drivers/gpu/drm/fsl-dcu/Makefile > > create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_connector.c > > create mode 100644 drivers
[Bug 89987] Slow VDPAU (rv770_restrict_performance_levels_before_switch failed)
https://bugs.freedesktop.org/show_bug.cgi?id=89987 --- Comment #8 from Christian König --- (In reply to James Le Cuirot from comment #7) > And still a problem in 4.2.0-rc1. Is there nothing I can do to move this > along? It's really irritating. I have tried my best to fix it myself but to > no avail. The only thing which came to my mind we haven't tried so far is if you are sure that it works with the 3.17 release (with UVD acceleration) and not 3.18 you could try to bisect the changes between the two. But apart from that I unfortunately don't have any idea either. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150710/69d10cdc/attachment.html>
[PATCH v6 1/4] drm/layerscape: Add Freescale DCU DRM driver
On Fri, Jul 10, 2015 at 03:26:52PM +0800, Jianwei Wang wrote: > This patch add support for Two Dimensional Animation and Compositing > Engine (2D-ACE) on the Freescale SoCs. > > 2D-ACE is a Freescale display controller. 2D-ACE describes > the functionality of the module extremely well its name is a value > that cannot be used as a token in programming languages. > Instead the valid token "DCU" is used to tag the register names and > function names. > > The Display Controller Unit (DCU) module is a system master that > fetches graphics stored in internal or external memory and displays > them on a TFT LCD panel. A wide range of panel sizes is supported > and the timing of the interface signals is highly configurable. > Graphics are read directly from memory and then blended in real-time, > which allows for dynamic content creation with minimal CPU > intervention. > > The features: > (1) Full RGB888 output to TFT LCD panel. > (2) For the current LCD panel, WQVGA "480x272" is supported. > (3) Blending of each pixel using up to 4 source layers > dependent on size of panel. > (4) Each graphic layer can be placed with one pixel resolution > in either axis. > (5) Each graphic layer support RGB565 and RGB888 direct colors > without alpha > channel and BGRA BGRA ARGB1555 direct colors with an > alpha channel and > YUV422 format. > (6) Each graphic layer support alpha blending with 8-bit > resolution. > > This is a simplified version, only one primary plane, one > framebuffer created for > fbdev, one crtc, one connector for TFT LCD panel, an encoder. > > Signed-off-by: Alison Wang > Signed-off-by: Xiubo Li > Signed-off-by: Jianwei Wang A few small things to polish that I spotted. -Daniel > --- > > > Changed in V6 > > - Add NEC nl4827hc19_05b panel to panel-simple.c > Adviced by Mark Yao > - Add DRIVER_ATOMIC for driver_features > Adviced by Mark Yao > - check fsl_dev if it's NULL at PM suspend/resume > Adviced by Mark Yao > > Changed in V5 > > - Update commit message > - Add layer registers initialization > - Remove unused functions > - Rename driver folder > Adviced by Stefan Agner > - Move pixel clock control functions to fsl_dcu_drm_drv.c > - remove redundant enable the clock implicitly using regmap > - Add maintainer message > > Changed in V4: > > -This version doesn't have functionality changed > Just a minor adjustment. > > Changed in V3: > > - Test driver on Vybrid board and add compatible string > - Remove unused functions > - set default crtc for encoder > - replace legacy functions with atomic help functions > Adviced by Daniel Vetter > - Set the unique name of the DRM device > - Implement irq handle function for vblank interrupt > > Changed in v2: > - Add atomic support > Adviced by Daniel Vetter > - Modify bindings file > - Rename node for compatibility > - Move platform related code out for compatibility > Adviced by Stefan Agner > > > MAINTAINERS | 7 + > drivers/gpu/drm/Kconfig | 2 + > drivers/gpu/drm/Makefile| 1 + > drivers/gpu/drm/fsl-dcu/Kconfig | 18 ++ > drivers/gpu/drm/fsl-dcu/Makefile| 7 + > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_connector.c | 200 + > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_connector.h | 31 ++ > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 172 +++ > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.h | 22 ++ > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 379 > > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h | 223 ++ > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_fbdev.c | 26 ++ > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c | 42 +++ > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.h | 17 ++ > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c | 195 > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.h | 23 ++ > 16 files changed, 1365 insertions(+) > create mode 100644 drivers/gpu/drm/fsl-dcu/Kconfig > create mode 100644 drivers/gpu/drm/fsl-dcu/Makefile > create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_connector.c > create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_connector.h > create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c > create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.h > create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c > create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h > create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_fbdev.c > create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c > create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.h > create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c > create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.h > > diff --git a/MAINTAINERS b/MAINTAINERS > index 6761318..b25b948 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -3404,6 +3404,13 @@ S: Maintained > F: drivers/gpu/drm
[PATCH v2 12/23] drm/exynos: don't track enabled state at exynos_crtc
On 07/10/2015 07:56 AM, Gustavo Padovan wrote:
> 2015-07-09 Joonyoung Shim :
>
>> +Cc Andrzej,
>>
>> On 07/07/2015 02:41 AM, Daniel Vetter wrote:
>>> On Mon, Jul 06, 2015 at 11:20:13AM -0300, Gustavo Padovan wrote:
From: Gustavo Padovan
struct drm_crtc already stores the enabled state of the crtc
thus we don't need to replicate enabled in exynos_drm_crtc.
>>
>> I think exynos_crtc->enabled can replace flags for power state of each
>> hw driver(e.g. "powered" of mixer driver, "suspended" of fimd driver).
>> Further, we can add other flag bit for instead of using special flag
>> in hw driver like vsync state("int_en" of mixer driver, "irq_flags" of
>> fimd driver.)
>
> The reason I removed it is because crtc->state->active already stores
> the same information as exynos_crtc->enabled. I think we could rely
> on active as well for mixer powered and suspended.
>
Then it may need another stuff on struct exynos_crtc if we try to
replace other hw flag like int_en or irq_flags.
Anyway, the reason that you remove it is ok to me now.
Thanks.
[PATCH v6 1/4] drm/layerscape: Add Freescale DCU DRM driver
Hi Jianwei, On 10 July 2015 at 08:47, Wang J.W. wrote: > Hi Mark, > > Thank you very much for your review! I have update my DRM driver. > All your three comments have been applied in this latest version. > I replied the last email several times, but all refused the mailist. I'd suspect that the ML automatically refused the email due to its size. To avoid that in the future you can trim the email to include only the relevant parts (not applicable in this case I know). At the same time it makes reading a bit easier, and missing buried comments harder :-) Hope that helps, Emil
[RFCv3 0/5] enable migration of driver pages
2015-07-09 ì¤í 10:08ì Daniel Vetter ì´(ê°) ì´ ê¸: > Also there's a bit a lack of gpu drivers from the arm world in upstream, > which is probabyl why this patch series doesn't come with a user. Might be > better to first upstream the driver before talking about additional > infrastructure that it needs. > -Daniel I'm not from ARM but I just got the idea of driver page migration during I worked with ARM gpu driver. I'm sure this patch is good for zram and balloon and hope it can be applied to drivers consuming many pages and generating fragmentation, such as GPU or gfx driver.
[PATCH v6 1/4] drm/layerscape: Add Freescale DCU DRM driver
Hi Mark, Thank you very much for your review! I have update my DRM driver. All your three comments have been applied in this latest version. I replied the last email several times, but all refused the mailist. Any other comments for this driver? BR. Jianwei > -Original Message- > From: Jianwei Wang [mailto:jianwei.wang at freescale.com] > Sent: Friday, July 10, 2015 3:27 PM > To: dri-devel at lists.freedesktop.org > Cc: linux-kernel at vger.kernel.org; linux-arm-kernel at lists.infradead.org; > devicetree at vger.kernel.org; airlied at linux.ie; daniel.vetter at ffwll.ch; > mark.yao at rock-chips.com; Wood Scott-B07421; Wang Jianwei-B52261; Wang > Huan-B18965; Xiubo Li > Subject: [PATCH v6 1/4] drm/layerscape: Add Freescale DCU DRM driver > > This patch add support for Two Dimensional Animation and Compositing > Engine (2D-ACE) on the Freescale SoCs. > > 2D-ACE is a Freescale display controller. 2D-ACE describes the > functionality of the module extremely well its name is a value that cannot > be used as a token in programming languages. > Instead the valid token "DCU" is used to tag the register names and > function names. > > The Display Controller Unit (DCU) module is a system master that fetches > graphics stored in internal or external memory and displays them on a TFT > LCD panel. A wide range of panel sizes is supported and the timing of the > interface signals is highly configurable. > Graphics are read directly from memory and then blended in real-time, > which allows for dynamic content creation with minimal CPU intervention. > > The features: > (1) Full RGB888 output to TFT LCD panel. > (2) For the current LCD panel, WQVGA "480x272" is supported. > (3) Blending of each pixel using up to 4 source layers dependent on size > of panel. > (4) Each graphic layer can be placed with one pixel resolution in either > axis. > (5) Each graphic layer support RGB565 and RGB888 direct colors without > alpha channel and BGRA BGRA ARGB1555 direct colors with an alpha > channel and > YUV422 format. > (6) Each graphic layer support alpha blending with 8-bit resolution. > > This is a simplified version, only one primary plane, one framebuffer > created for fbdev, one crtc, one connector for TFT LCD panel, an encoder. > > Signed-off-by: Alison Wang > Signed-off-by: Xiubo Li > Signed-off-by: Jianwei Wang > --- > > > Changed in V6 > > - Add NEC nl4827hc19_05b panel to panel-simple.c Adviced by Mark Yao > - Add DRIVER_ATOMIC for driver_features > Adviced by Mark Yao > - check fsl_dev if it's NULL at PM suspend/resume Adviced by Mark Yao > > Changed in V5 > > - Update commit message > - Add layer registers initialization > - Remove unused functions > - Rename driver folder > Adviced by Stefan Agner > - Move pixel clock control functions to fsl_dcu_drm_drv.c > - remove redundant enable the clock implicitly using regmap > - Add maintainer message > > Changed in V4: > > -This version doesn't have functionality changed Just a minor adjustment. > > Changed in V3: > > - Test driver on Vybrid board and add compatible string > - Remove unused functions > - set default crtc for encoder > - replace legacy functions with atomic help functions Adviced by Daniel > Vetter > - Set the unique name of the DRM device > - Implement irq handle function for vblank interrupt > > Changed in v2: > - Add atomic support > Adviced by Daniel Vetter > - Modify bindings file > - Rename node for compatibility > - Move platform related code out for compatibility Adviced by Stefan Agner > > > MAINTAINERS | 7 + > drivers/gpu/drm/Kconfig | 2 + > drivers/gpu/drm/Makefile| 1 + > drivers/gpu/drm/fsl-dcu/Kconfig | 18 ++ > drivers/gpu/drm/fsl-dcu/Makefile| 7 + > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_connector.c | 200 + > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_connector.h | 31 ++ > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 172 +++ > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.h | 22 ++ > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 379 > > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h | 223 ++ > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_fbdev.c | 26 ++ > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c | 42 +++ > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.h | 17 ++ > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c | 195 > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.h | 23 ++ > 16 files changed, 1365 insertions(+) > create mode 100644 drivers/gpu/drm/fsl-dcu/Kconfig create mode 100644 > drivers/gpu/drm/fsl-dcu/Makefile create mode 100644 drivers/gpu/drm/fsl- > dcu/fsl_dcu_drm_connector.c > create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_connector.h > create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c > create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.h > creat
[git pull] drm fixes
Hi Linus, back from vacation (another one is coming up in August though), thanks for taking care of direct pulls while I was out. a bunch of fixes for radeon, intel, omap and one amdkfd fix. radeon fixes are all over, but it does fix some cursor corruption across suspend/resume i915 should fix the second warn you were seeing, so let us know if not. omap is a bunch of small fixes, Regards, Dave. The following changes since commit c4b5fd3fb2058b650447372472ad24e2a989f9f6: Merge branch 'hpfs-patches' (patches from Mikulas Patocka) (2015-07-09 13:35:39 -0700) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes for you to fetch changes up to 2d28b633c3fa8f53b919a5de86eb1c8e78dde818: Merge tag 'omapdrm-4.2-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux into drm-fixes (2015-07-10 15:59:35 +1000) Alex Deucher (2): Revert "Revert "drm/radeon: dont switch vt on suspend"" drm/radeon: disable vce init on cayman (v2) Chris Wilson (1): drm/i915: Declare the swizzling unknown for L-shaped configurations Christian König (3): drm/radeon: allways add the VM clear duplicate drm/radeon: check if BO_VA is set before adding it to the invalidation list drm/amdgpu: fix timeout calculation Dan Carpenter (1): drm/radeon: fix underflow in r600_cp_dispatch_texture() Daniel Vetter (2): drm/i915: Check crtc->active in intel_crtc_disable_planes drm/i915: Use crtc_state->active in primary check_plane func Dave Airlie (4): Merge branch 'drm-fixes-4.2' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Merge tag 'drm-amdkfd-fixes-2015-07-09' of git://people.freedesktop.org/~gabbayo/linux into drm-fixes Merge tag 'drm-intel-fixes-2015-07-09' of git://anongit.freedesktop.org/drm-intel into drm-fixes Merge tag 'omapdrm-4.2-fixes' of git://git.kernel.org/.../tomba/linux into drm-fixes Fabian Frederick (1): drm/omap: replace ALIGN(PAGE_SIZE) by PAGE_ALIGN Grigori Goronzy (4): drm/radeon: use RCU query for GEM_BUSY syscall drm/radeon: fix HDP flushing drm/radeon: default to 2048 MB GART size on SI+ drm/radeon: unpin cursor BOs on suspend and pin them again on resume (v2) Imre Deak (1): drm/i915/chv: fix HW readout of the port PLL fractional divider Maninder Singh (1): drm/amdkfd: validate pdd where it acquired first Mario Kleiner (2): drm/radeon: Handle irqs only based on irq ring, not irq status regs. drm/amdgpu: Handle irqs only based on irq ring, not irq status regs. Michel Dänzer (2): drm/radeon: Clean up reference counting and pinning of the cursor BOs drm/radeon: Fold radeon_set_cursor() into radeon_show_cursor() Tomi Valkeinen (6): drm/omap: return error if dma_alloc_writecombine fails drm/omap: check that plane is inside crtc drm/omap: increase DMM transaction timeout drm/omap: fix omap_framebuffer_unpin() error handling drm/omap: fix omap_gem_put_paddr() error handling drm/omap: fix align_pitch() for 24 bits per pixel Tvrtko Ursulin (1): drm/i915: Restore all GGTT VMAs on resume Ville Syrjälä (1): Revert "drm/i915: Allocate context objects from stolen" drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 2 +- drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 22 +- drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 22 +- drivers/gpu/drm/amd/amdgpu/dce_v8_0.c| 22 +- drivers/gpu/drm/amd/amdkfd/kfd_process.c | 9 +- drivers/gpu/drm/i915/i915_gem_context.c | 4 +- drivers/gpu/drm/i915/i915_gem_gtt.c | 23 +- drivers/gpu/drm/i915/i915_gem_tiling.c | 12 +- drivers/gpu/drm/i915/intel_display.c | 12 +- drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 2 +- drivers/gpu/drm/omapdrm/omap_drv.h | 6 +- drivers/gpu/drm/omapdrm/omap_fb.c| 16 +- drivers/gpu/drm/omapdrm/omap_fbdev.c | 2 +- drivers/gpu/drm/omapdrm/omap_gem.c | 26 +- drivers/gpu/drm/omapdrm/omap_plane.c | 26 ++ drivers/gpu/drm/radeon/cik.c | 336 ++ drivers/gpu/drm/radeon/evergreen.c | 392 +-- drivers/gpu/drm/radeon/ni.c | 25 +- drivers/gpu/drm/radeon/r600.c| 155 ++-- drivers/gpu/drm/radeon/r600_cp.c | 2 +- drivers/gpu/drm/radeon/radeon_cursor.c | 109 - drivers/gpu/drm/radeon/radeon_device.c | 66 -- drivers/gpu/drm/radeon/radeon_fb.c | 1 + drivers/gpu/drm/radeon/radeon_gem.c | 12 +- drivers/gpu/drm/radeon/radeon_mode.h | 1 - drivers/gpu/drm/radeon/radeon_vm.c | 40 ++-- drivers/gpu/drm/radeon/si.c | 336 ++ 27 files changed, 964 insertions(+), 717 deletions(-)
[Bug 91263] R600 Segfault in finalize_textures
https://bugs.freedesktop.org/show_bug.cgi?id=91263 Michel Dänzer changed: What|Removed |Added Component|Drivers/Gallium/r600|Mesa core Assignee|dri-devel at lists.freedesktop |mesa-dev at lists.freedesktop. |.org|org QA Contact|dri-devel at lists.freedesktop |mesa-dev at lists.freedesktop. |.org|org --- Comment #1 from Michel Dänzer --- ctx->FragmentProgram._Current is NULL. #0 0x7fffe50d in finalize_textures (st=0xd21d70) at ../../../src/mesa/state_tracker/st_atom_texture.c:519 #1 0x7fffe5095265 in st_validate_state (st=st at entry=0xd21d70) at ../../../src/mesa/state_tracker/st_atom.c:214 #2 0x7fffe509c580 in st_BlitFramebuffer (ctx=0xcdfb40, readFB=0x1285450, drawFB=0xa8ecf0, srcX0=0, srcY0=0, srcX1=376, srcY1=413, dstX0=12, dstY0=175, dstX1=388, dstY1=588, mask=16384, filter=9728) at ../../../src/mesa/state_tracker/st_cb_blit.c:95 #3 0x7fffe4e67a3e in _mesa_blit_framebuffer (func=0x7fffe5593dc8 "glBlitFramebuffer", filter=9728, mask=16384, dstY1=588, dstX1=388, dstY0=175, dstX0=12, srcY1=413, srcX1=376, srcY0=0, srcX0=0, drawFb=, readFb=, ctx=) at ../../../src/mesa/main/blit.c:525 #4 _mesa_BlitFramebuffer (srcX0=0, srcY0=0, srcX1=376, srcY1=413, dstX0=12, dstY0=175, dstX1=388, dstY1=588, mask=16384, filter=9728) at ../../../src/mesa/main/blit.c:553 #5 0x77254352 in gdk_cairo_draw_from_gl () from /usr/lib/x86_64-linux-gnu/libgdk-3.so.0 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150710/ed1c65b3/attachment-0001.html>
[Bug 76490] Hang during boot when DPM is on (R9 270X)
https://bugs.freedesktop.org/show_bug.cgi?id=76490 --- Comment #39 from Alex Deucher --- (In reply to Tobias Droste from comment #35) > 3) This card works fine with any sclk/mclk combination with the same vddc > (1238mV) in windows and I can overclock there! There is apparently some aspect of the set up that we are not programming correctly that manifests with higher clocks on certain boards. > > I'm also wondering why I get a different VBIOS size if I get the bios in > windows (gpu-z) and linux. Is it because different firmware gets loaded? The > (working) vbios under windows is twice as large as the linux one (see > attachments). The vbios is loaded from rom on the card. The firmware for the various micro-controllers on the GPU are loaded by the driver and are not part of the vbios. I'm not sure off hand why they differ. Perhaps gpuz always returns a 128K image regardless of what size the actual bios is? Or maybe it asks the driver windows driver for a copy and the windows driver always stores 128K images regardless of the actual image size. I quick look at the tables and I only see one small difference in the overdrive table: -OD max sclk: 14, max mclk: 162500 (win) +OD max sclk: 107000, max mclk: 14 (linux) Everything else appears to be the same. I'm guessing the windows driver patched that and gpuz fetches the copy from the driver. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150710/1f8cb3d6/attachment.html>
[Bug 91279] agd5f drm tonga occasional traps error:0 in libdrm_amdgpu.so.1.0.0
https://bugs.freedesktop.org/show_bug.cgi?id=91279 --- Comment #1 from Michel Dänzer --- Can you get a gdb backtrace of such a crash? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150710/bafaadce/attachment.html>
