[Bug 80419] XCOM: Enemy Unknown Causes lockup
https://bugs.freedesktop.org/show_bug.cgi?id=80419 Jose Fonseca changed: What|Removed |Added CC||brianp at vmware.com, ||jfonseca at vmware.com --- Comment #88 from Jose Fonseca --- (In reply to Kamil Páral from comment #87) > The apitrace developer patched glretrace, so that it no longer crashes > during replay. He says it's a bug inside XCOM. He also says the problem > might likely cause the radeonsi driver crash as well. See his comment here: > https://github.com/apitrace/apitrace/issues/407#issuecomment-166619366 > > (If this indeed turns out to be an XCOM bug, it would be nice if we could > put some safeguards into the driver and didn't crash for invalid commands, > but I'm saying that as someone who knows exactly zero about gpu driver > programming). Yep. We could add a new drirc hack for ignoring the start/end params of glDrawRangeElementsBaseVertex for applications like XCOM, ie, assume 0..~0. XCOM is not unique here -- we've seen this happening on a Direct3D9 once at VMware. It looks like some of the proprietary OpenGL/Direct3D drivers out there simply outright ignore the min/max index hints. -- 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/20151222/f1f6c46b/attachment.html>
[Bug 80419] XCOM: Enemy Unknown Causes lockup
https://bugs.freedesktop.org/show_bug.cgi?id=80419 --- Comment #87 from Kamil Páral --- Created attachment 120655 --> https://bugs.freedesktop.org/attachment.cgi?id=120655&action=edit gdb backtrace from xorg when system locks up during glretrace replay Thanks Nicolai and others for looking into this. I have some good news. The apitrace developer patched glretrace, so that it no longer crashes during replay. He says it's a bug inside XCOM. He also says the problem might likely cause the radeonsi driver crash as well. See his comment here: https://github.com/apitrace/apitrace/issues/407#issuecomment-166619366 (If this indeed turns out to be an XCOM bug, it would be nice if we could put some safeguards into the driver and didn't crash for invalid commands, but I'm saying that as someone who knows exactly zero about gpu driver programming). Also, now that glretrace does not crash, I'm able to easily loop the trace until its very end. In just a handful of replays, my system locked up 3 times. I haven't seen all lockups, but at least once it occurred exactly at the point where the lockup occurred while recording (at the very end). So it seems I'm able to reproduce this with reasonable likelihood, and therefore can test some fixes if needed. (In reply to Michel Dänzer from comment #77) > No need, it's not important. The assumption for now is that the Xorg crash > is caused by the GPU hang. If you happen to get a gdb backtrace of it in the > future, that will help verify this assumption, but it's no more than nice to > have. I have it now, attaching. -- 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/20151222/1feeb0e3/attachment.html>
[Bug 92229] [APITRACE] SOMA have serious graphical errors
https://bugs.freedesktop.org/show_bug.cgi?id=92229 --- Comment #10 from Henri Valta --- The game works now great with Grazvydas' patch. Applied to mesa 11.1.0 Tested on Radeon HD4870 Thank you for the fix! -- 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/20151222/f90b1d0b/attachment.html>
[PATCH v11 17/19] drm: bridge: analogix/dp: expand the look time for waiting AUX CH reply
On Wednesday, December 16, 2015 12:58 PM, Yakir Yang wrote:
>
> After test on rockchiop platform, i found sometims driver would failed
> at reading EDID message. After debugging more, i found that it's okay
> to read_a byte from i2c, but it would failed at AUX transcation if we
> try to ready multi-bytes from i2c.
>
> Driver just can't received the AUX CH reply command, even no AUX error
> code. I may guess that the AUX wait time is not enough, so I try to
> expand the AUX wait time, and i do see this could fix the EDID read
> failed at rockchip platform.
>
> And I thought that expand the wait time won't hurt Exynos platform too
> much, cause Exynos didn't have this problem, then driver would received
> the reply command very soon, so no more additional wait time would bring
> to Exynos platform.
>
> Signed-off-by: Yakir Yang
> ---
> Changes in v11: None
> Changes in v10: None
> Changes in v9: None
> Changes in v8: None
> Changes in v7: None
> Changes in v6: None
> Changes in v5: None
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
>
> drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> index c7e2959..dc376bd 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> @@ -482,7 +482,7 @@ int analogix_dp_start_aux_transaction(struct
> analogix_dp_device *dp)
> reg = readl(dp->reg_base + ANALOGIX_DP_INT_STA);
> while (!(reg & RPLY_RECEIV)) {
> timeout_loop++;
> - if (DP_TIMEOUT_LOOP_COUNT < timeout_loop) {
> + if (DP_TIMEOUT_LOOP_COUNT * 10 < timeout_loop) {
No, I hate this coding.
analogix_dp_reg.c is the common code that can be shared by various SoCs.
Please, find another way.
Best regards,
Jingoo Han
> dev_err(dp->dev, "AUX CH command reply failed!\n");
> return -ETIMEDOUT;
> }
> --
> 1.9.1
[PATCH v11 09/19] phy: Add driver for rockchip Display Port PHY
On Wednesday, December 16, 2015 12:41 PM, Yakir Yang wrote:
>
> Add phy driver for the Rockchip DisplayPort PHY module. This
> is required to get DisplayPort working in Rockchip SoCs.
>
> Signed-off-by: Yakir Yang
> Reviewed-by: Heiko Stuebner
> ---
> Changes in v11: None
> Changes in v10:
> - Fix the wrong macro value of GRF_EDP_REF_CLK_SEL_INTER_HIWORD_MASK
> BIT(4) -> BIT(20)
>
> Changes in v9:
> - Removed the unused the variable "res" in probe function. (Heiko)
> - Removed the unused head file.
>
> Changes in v8:
> - Fix the mixed spacers on macro definitions. (Heiko)
> - Remove the unnecessary empty line after clk_prepare_enable. (Heiko)
>
> Changes in v7:
> - Simply the commit message. (Kishon)
> - Symmetrical enable/disbale the phy clock and power. (Kishon)
>
> Changes in v6: None
> Changes in v5:
> - Remove "reg" DT property, cause driver could poweron/poweroff phy via
> the exist "grf" syscon already. And rename the example DT node from
> "edp_phy: phy at ff770274" to "edp_phy: edp-phy" directly. (Heiko)
> - Add deivce_node at the front of driver, update phy_ops type from "static
> struct" to "static const struct". And correct the input paramters of
> devm_phy_create() interfaces. (Heiko)
>
> Changes in v4:
> - Add commit message, and remove the redundant rockchip_dp_phy_init()
> function, move those code to probe() method. And remove driver .owner
> number. (Kishon)
>
> Changes in v3:
> - Suggest, add rockchip dp phy driver, collect the phy clocks and
> power control. (Heiko)
>
> Changes in v2: None
>
> drivers/phy/Kconfig | 7 ++
> drivers/phy/Makefile | 1 +
> drivers/phy/phy-rockchip-dp.c | 151
> ++
> 3 files changed, 159 insertions(+)
> create mode 100644 drivers/phy/phy-rockchip-dp.c
>
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 7eb5859d..7355819 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -319,6 +319,13 @@ config PHY_ROCKCHIP_USB
> help
> Enable this to support the Rockchip USB 2.0 PHY.
>
> +config PHY_ROCKCHIP_DP
> + tristate "Rockchip Display Port PHY Driver"
> + depends on ARCH_ROCKCHIP && OF
> + select GENERIC_PHY
> + help
> + Enable this to support the Rockchip Display Port PHY.
> +
> config PHY_ST_SPEAR1310_MIPHY
> tristate "ST SPEAR1310-MIPHY driver"
> select GENERIC_PHY
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index 075db1a..b1700cd 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -35,6 +35,7 @@ phy-exynos-usb2-$(CONFIG_PHY_S5PV210_USB2) +=
> phy-s5pv210-usb2.o
> obj-$(CONFIG_PHY_EXYNOS5_USBDRD) += phy-exynos5-usbdrd.o
> obj-$(CONFIG_PHY_QCOM_APQ8064_SATA) += phy-qcom-apq8064-sata.o
> obj-$(CONFIG_PHY_ROCKCHIP_USB) += phy-rockchip-usb.o
> +obj-$(CONFIG_PHY_ROCKCHIP_DP)+= phy-rockchip-dp.o
> obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA) += phy-qcom-ipq806x-sata.o
> obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY) += phy-spear1310-miphy.o
> obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY) += phy-spear1340-miphy.o
> diff --git a/drivers/phy/phy-rockchip-dp.c b/drivers/phy/phy-rockchip-dp.c
> new file mode 100644
> index 000..3cb3bf8
> --- /dev/null
> +++ b/drivers/phy/phy-rockchip-dp.c
> @@ -0,0 +1,151 @@
> +/*
> + * Rockchip DP PHY driver
> + *
> + * Copyright (C) 2015 FuZhou Rockchip Co., Ltd.
> + * Author: Yakir Yang
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
Please order these headers alphabetically.
It will enhance the readability.
Best regards,
Jingoo Han
> +
> +#define GRF_SOC_CON12 0x0274
> +
> +#define GRF_EDP_REF_CLK_SEL_INTER_HIWORD_MASK BIT(20)
> +#define GRF_EDP_REF_CLK_SEL_INTER BIT(4)
> +
> +#define GRF_EDP_PHY_SIDDQ_HIWORD_MASK BIT(21)
> +#define GRF_EDP_PHY_SIDDQ_ON0
> +#define GRF_EDP_PHY_SIDDQ_OFF BIT(5)
> +
> +struct rockchip_dp_phy {
> + struct device *dev;
> + struct regmap *grf;
> + struct clk *phy_24m;
> +};
> +
> +static int rockchip_set_phy_state(struct phy *phy, bool enable)
> +{
> + struct rockchip_dp_phy *dp = phy_get_drvdata(phy);
> + int ret;
> +
> + if (enable) {
> + ret = regmap_write(dp->grf, GRF_SOC_CON12,
> +GRF_EDP_PHY_SIDDQ_HIWORD_MASK |
> +GRF_EDP_PHY_SIDDQ_ON);
> + if (ret < 0) {
> + dev_err(dp->dev, "Can't enable PHY power %d\n", ret);
> + return ret;
> + }
> +
> + ret = clk_prepare_enable(dp->phy_24m);
> + } else {
> + clk_disable_unprepare(dp->phy_2
[PATCH v11 06/19] ARM: dts: exynos/dp: remove some properties that deprecated by analogix_dp driver
On Wednesday, December 16, 2015 12:35 PM, Yakir Yang wrote:
>
> After exynos_dp have been split the common IP code into analogix_dp driver,
> the analogix_dp driver have deprecated some Samsung platform properties which
> could be dynamically parsed from EDID/MODE/DPCD message, so this is an update
> for Exynos DTS file for dp-controller.
>
> Beside the backward compatibility is fully preserved, so there are no
> bisectability break that make this change in a separate patch.
>
> Signed-off-by: Yakir Yang
> Reviewed-by: Krzysztof Kozlowski
> Tested-by: Javier Martinez Canillas
Reviewed-by: Jingoo Han < jingoohan1 at gmail.com >
Best regards,
Jingoo Han
> ---
> Changes in v11: None
> Changes in v10: None
> Changes in v9: None
> Changes in v8: None
> Changes in v7: None
> Changes in v6:
> - Fix Peach Pit hpd property name error:
> - hpd-gpio = <&gpx2 6 0>;
> + hpd-gpios = <&gpx2 6 0>;
>
> Changes in v5:
> - Correct the misspell in commit message. (Krzysztof)
>
> Changes in v4:
> - Separate all DTS changes to a separate patch. (Krzysztof)
>
> Changes in v3: None
> Changes in v2: None
>
> arch/arm/boot/dts/exynos5250-arndale.dts | 2 --
> arch/arm/boot/dts/exynos5250-smdk5250.dts | 2 --
> arch/arm/boot/dts/exynos5250-snow-common.dtsi | 4 +---
> arch/arm/boot/dts/exynos5250-spring.dts | 4 +---
> arch/arm/boot/dts/exynos5420-peach-pit.dts| 4 +---
> arch/arm/boot/dts/exynos5420-smdk5420.dts | 2 --
> arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 +---
> 7 files changed, 4 insertions(+), 18 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts
> b/arch/arm/boot/dts/exynos5250-arndale.dts
> index c000532..b1790cf 100644
> --- a/arch/arm/boot/dts/exynos5250-arndale.dts
> +++ b/arch/arm/boot/dts/exynos5250-arndale.dts
> @@ -124,8 +124,6 @@
> &dp {
> status = "okay";
> samsung,color-space = <0>;
> - samsung,dynamic-range = <0>;
> - samsung,ycbcr-coeff = <0>;
> samsung,color-depth = <1>;
> samsung,link-rate = <0x0a>;
> samsung,lane-count = <4>;
> diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
> b/arch/arm/boot/dts/exynos5250-smdk5250.dts
> index 0f5dcd4..f30c2db 100644
> --- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
> +++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
> @@ -80,8 +80,6 @@
>
> &dp {
> samsung,color-space = <0>;
> - samsung,dynamic-range = <0>;
> - samsung,ycbcr-coeff = <0>;
> samsung,color-depth = <1>;
> samsung,link-rate = <0x0a>;
> samsung,lane-count = <4>;
> diff --git a/arch/arm/boot/dts/exynos5250-snow-common.dtsi
> b/arch/arm/boot/dts/exynos5250-snow-
> common.dtsi
> index 5cb33ba..b96624b 100644
> --- a/arch/arm/boot/dts/exynos5250-snow-common.dtsi
> +++ b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
> @@ -236,12 +236,10 @@
> pinctrl-names = "default";
> pinctrl-0 = <&dp_hpd>;
> samsung,color-space = <0>;
> - samsung,dynamic-range = <0>;
> - samsung,ycbcr-coeff = <0>;
> samsung,color-depth = <1>;
> samsung,link-rate = <0x0a>;
> samsung,lane-count = <2>;
> - samsung,hpd-gpio = <&gpx0 7 GPIO_ACTIVE_HIGH>;
> + hpd-gpios = <&gpx0 7 GPIO_ACTIVE_HIGH>;
>
> ports {
> port at 0 {
> diff --git a/arch/arm/boot/dts/exynos5250-spring.dts
> b/arch/arm/boot/dts/exynos5250-spring.dts
> index c1edd6d..91881d7 100644
> --- a/arch/arm/boot/dts/exynos5250-spring.dts
> +++ b/arch/arm/boot/dts/exynos5250-spring.dts
> @@ -74,12 +74,10 @@
> pinctrl-names = "default";
> pinctrl-0 = <&dp_hpd_gpio>;
> samsung,color-space = <0>;
> - samsung,dynamic-range = <0>;
> - samsung,ycbcr-coeff = <0>;
> samsung,color-depth = <1>;
> samsung,link-rate = <0x0a>;
> samsung,lane-count = <1>;
> - samsung,hpd-gpio = <&gpc3 0 GPIO_ACTIVE_HIGH>;
> + hpd-gpios = <&gpc3 0 GPIO_ACTIVE_HIGH>;
> };
>
> &ehci {
> diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
> b/arch/arm/boot/dts/exynos5420-peach-pit.dts
> index 35cfb07..2f37c87 100644
> --- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
> +++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
> @@ -148,12 +148,10 @@
> pinctrl-names = "default";
> pinctrl-0 = <&dp_hpd_gpio>;
> samsung,color-space = <0>;
> - samsung,dynamic-range = <0>;
> - samsung,ycbcr-coeff = <0>;
> samsung,color-depth = <1>;
> samsung,link-rate = <0x06>;
> samsung,lane-count = <2>;
> - samsung,hpd-gpio = <&gpx2 6 GPIO_ACTIVE_HIGH>;
> + hpd-gpios = <&gpx2 6 GPIO_ACTIVE_HIGH>;
>
> ports {
> port at 0 {
> diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts
> b/arch/arm/boot/dts/exynos5420-smdk5420.dts
> index ac35aef..f67344f 100644
> --- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
> +++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
> @@ -93,8 +93,6 @@
> pinctrl-names = "default";
> pinctrl-0 = <&dp_hpd>;
> samsung,color-space = <0>;
> - samsung,dynami
[PATCH v11 03/19] drm: bridge: analogix/dp: remove duplicate configuration of link rate and link count
On Wednesday, December 16, 2015 12:28 PM, Yakir Yang wrote:
>
> link_rate and lane_count already configured in analogix_dp_set_link_train(),
> so we don't need to config those repeatly after training finished, just
> remove them out.
>
> Beside Display Port 1.2 already support 5.4Gbps link rate, the maximum sets
> would change from {1.62Gbps, 2.7Gbps} to {1.62Gbps, 2.7Gbps, 5.4Gbps}.
>
> Signed-off-by: Yakir Yang
> Tested-by: Javier Martinez Canillas
> ---
> Changes in v11: None
> Changes in v10: None
> Changes in v9: None
> Changes in v8: None
> Changes in v7: None
> Changes in v6: None
> Changes in v5: None
> Changes in v4:
> - Update commit message more readable. (Jingoo)
> - Adjust the order from 05 to 04
>
> Changes in v3:
> - The link_rate and lane_count shouldn't config to the DT property value
> directly, but we can take those as hardware limite. For example, RK3288
> only support 4 physical lanes of 2.7/1.62 Gbps/lane, so DT property would
> like "link-rate = 0x0a" "lane-count = 4". (Thierry)
>
> Changes in v2: None
>
> drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 8
> drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 5 +++--
> 2 files changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index 4a05c2b..6f899cd 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -624,6 +624,8 @@ static void analogix_dp_get_max_rx_bandwidth(struct
> analogix_dp_device *dp,
> /*
>* For DP rev.1.1, Maximum link rate of Main Link lanes
>* 0x06 = 1.62 Gbps, 0x0a = 2.7 Gbps
> + * For DP rev.1.2, Maximum link rate of Main Link lanes
> + * 0x06 = 1.62 Gbps, 0x0a = 2.7 Gbps, 0x14 = 5.4Gbps
>*/
> analogix_dp_read_byte_from_dpcd(dp, DP_MAX_LINK_RATE, &data);
> *bandwidth = data;
> @@ -657,7 +659,8 @@ static void analogix_dp_init_training(struct
> analogix_dp_device *dp,
> analogix_dp_get_max_rx_lane_count(dp, &dp->link_train.lane_count);
>
> if ((dp->link_train.link_rate != LINK_RATE_1_62GBPS) &&
> - (dp->link_train.link_rate != LINK_RATE_2_70GBPS)) {
> + (dp->link_train.link_rate != LINK_RATE_2_70GBPS) &&
> + (dp->link_train.link_rate != LINK_RATE_5_40GBPS)) {
> dev_err(dp->dev, "Rx Max Link Rate is abnormal :%x !\n",
> dp->link_train.link_rate);
> dp->link_train.link_rate = LINK_RATE_1_62GBPS;
> @@ -898,9 +901,6 @@ static void analogix_dp_commit(struct analogix_dp_device
> *dp)
> analogix_dp_enable_rx_to_enhanced_mode(dp, 1);
> analogix_dp_enable_enhanced_mode(dp, 1);
>
> - analogix_dp_set_lane_count(dp, dp->video_info->lane_count);
> - analogix_dp_set_link_bandwidth(dp, dp->video_info->link_rate);
> -
> analogix_dp_init_video(dp);
> ret = analogix_dp_config_video(dp);
> if (ret)
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
> index 8e84208..57aa4b0d 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
> @@ -21,8 +21,9 @@
> #define MAX_EQ_LOOP 5
>
> enum link_rate_type {
> - LINK_RATE_1_62GBPS = 0x06,
> - LINK_RATE_2_70GBPS = 0x0a
> + LINK_RATE_1_62GBPS = DP_LINK_BW_1_62,
> + LINK_RATE_2_70GBPS = DP_LINK_BW_2_7,
> + LINK_RATE_5_40GBPS = DP_LINK_BW_5_4,
Then, how about removing 'enum link_rate_type'?
If DP_LINK_BW_* are used, LINK_RATE_* are not necessary.
Best regards,
Jingoo Han
> };
>
> enum link_lane_count_type {
> --
> 1.9.1
[PATCH v11 02/19] drm: bridge: analogix/dp: fix some obvious code style
On Wednesday, December 16, 2015 12:26 PM, Yakir Yang wrote:
>
> Fix some obvious alignment problems, like alignment and line
> over 80 characters problems, make this easy to be maintained
> later.
>
> Signed-off-by: Yakir Yang
> Reviewed-by: Krzysztof Kozlowski
> Tested-by: Javier Martinez Canillas
Acked-by: Jingoo Han
Best regards,
Jingoo Han
> ---
> Changes in v11: None
> Changes in v10: None
> Changes in v9: None
> Changes in v8: None
> Changes in v7: None
> Changes in v6: None
> Changes in v5:
> - Resequence this patch after analogix_dp driver have been split
> from exynos_dp code, and rephrase reasonable commit message, and
> remove some controversial style (Krzysztof)
> - analogix_dp_write_byte_to_dpcd(
> - dp, DP_TEST_RESPONSE,
> + analogix_dp_write_byte_to_dpcd(dp,
> + DP_TEST_RESPONSE,
> DP_TEST_EDID_CHECKSUM_WRITE);
>
> Changes in v4: None
> Changes in v3: None
> Changes in v2:
> - Improved commit message more readable, and avoid using some
> uncommon style like bellow: (Joe Preches)
> - retval = exynos_dp_read_bytes_from_i2c(...
> ...);
> + retval =
> + exynos_dp_read_bytes_from_i2c(..);
>
> drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 129
> ++---
> drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 72 ++--
> drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 124 ++--
> 3 files changed, 163 insertions(+), 162 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index fb8bda8..4a05c2b 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -61,7 +61,7 @@ static int analogix_dp_detect_hpd(struct analogix_dp_device
> *dp)
>
> while (analogix_dp_get_plug_in_status(dp) != 0) {
> timeout_loop++;
> - if (DP_TIMEOUT_LOOP_COUNT < timeout_loop) {
> + if (timeout_loop > DP_TIMEOUT_LOOP_COUNT) {
> dev_err(dp->dev, "failed to get hpd plug status\n");
> return -ETIMEDOUT;
> }
> @@ -98,8 +98,8 @@ static int analogix_dp_read_edid(struct analogix_dp_device
> *dp)
>
> /* Read Extension Flag, Number of 128-byte EDID extension blocks */
> retval = analogix_dp_read_byte_from_i2c(dp, I2C_EDID_DEVICE_ADDR,
> - EDID_EXTENSION_FLAG,
> - &extend_block);
> + EDID_EXTENSION_FLAG,
> + &extend_block);
> if (retval)
> return retval;
>
> @@ -107,7 +107,8 @@ static int analogix_dp_read_edid(struct
> analogix_dp_device *dp)
> dev_dbg(dp->dev, "EDID data includes a single extension!\n");
>
> /* Read EDID data */
> - retval = analogix_dp_read_bytes_from_i2c(dp,
> I2C_EDID_DEVICE_ADDR,
> + retval = analogix_dp_read_bytes_from_i2c(dp,
> + I2C_EDID_DEVICE_ADDR,
> EDID_HEADER_PATTERN,
> EDID_BLOCK_LENGTH,
> &edid[EDID_HEADER_PATTERN]);
> @@ -138,7 +139,7 @@ static int analogix_dp_read_edid(struct
> analogix_dp_device *dp)
> }
>
> analogix_dp_read_byte_from_dpcd(dp, DP_TEST_REQUEST,
> - &test_vector);
> + &test_vector);
> if (test_vector & DP_TEST_LINK_EDID_READ) {
> analogix_dp_write_byte_to_dpcd(dp,
> DP_TEST_EDID_CHECKSUM,
> @@ -152,10 +153,8 @@ static int analogix_dp_read_edid(struct
> analogix_dp_device *dp)
>
> /* Read EDID data */
> retval = analogix_dp_read_bytes_from_i2c(dp,
> - I2C_EDID_DEVICE_ADDR,
> - EDID_HEADER_PATTERN,
> - EDID_BLOCK_LENGTH,
> - &edid[EDID_HEADER_PATTERN]);
> + I2C_EDID_DEVICE_ADDR, EDID_HEADER_PATTERN,
> + EDID_BLOCK_LENGTH, &edid[EDID_HEADER_PATTERN]);
> if (retval != 0) {
> dev_err(dp->dev, "EDID Read failed!\n");
> return -EIO;
> @@ -166,16 +165,13 @@ static int analogix_dp_read_edid(struct
> analogix_dp_device *dp)
> return -EIO;
> }
>
> - analogix_dp_read_byte_from_dpcd(dp,
> - DP_TEST_REQUEST,
> - &test_vector);
> + analogix_dp_read_byte_from_dpcd(dp, DP_TEST_REQUEST,
[PATCH v6 4/5] drm/i915: Implement end_cpu_access
On Fri, Dec 18, 2015 at 05:19:24PM -0200, Tiago Vignatti wrote:
> On 12/18/2015 05:02 PM, Tiago Vignatti wrote:
> >On 12/17/2015 06:01 AM, Chris Wilson wrote:
> >>On Wed, Dec 16, 2015 at 08:25:36PM -0200, Tiago Vignatti wrote:
> >>>This function is meant to be used with dma-buf mmap, when finishing
> >>>the CPU
> >>>access of the mapped pointer.
> >>>
> >>>+static void i915_gem_end_cpu_access(struct dma_buf *dma_buf, enum
> >>>dma_data_direction direction)
> >>>+{
> >>>+struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
> >>>+struct drm_device *dev = obj->base.dev;
> >>>+struct drm_i915_private *dev_priv = to_i915(dev);
> >>>+bool was_interruptible, write = (direction == DMA_BIDIRECTIONAL
> >>>|| direction == DMA_TO_DEVICE);
> >>>+int ret;
> >>>+
> >>>+mutex_lock(&dev->struct_mutex);
> >>>+was_interruptible = dev_priv->mm.interruptible;
> >>>+dev_priv->mm.interruptible = false;
> >>>+
> >>>+ret = i915_gem_object_set_to_gtt_domain(obj, write);
> >>
> >>This only needs to pass .write=false. The dma-buf direction is
> >>only for the period of the user access, and we are now flushing the
> >>caches. This is equivalent to the sw-finish ioctl and ideally we just
> >>want the i915_gem_object_flush_cpu_write_domain().
> >
> >in fact the only usage so far I found for end_cpu_access is when the
> >pinned buffer is scanout out. Should I pretty much copy sw-finish in
> >end_cpu_access then?
>
> And do you think it's okay to declare
> i915_gem_object_flush_cpu_write_domain outside its file's only
> scope?
Whilst the simplicity of just doing the flush appeals, calling
set_gtt_domain(write=false) isn't that much heavier (the difference will
be lost in the noise of any clflushing) and is going to be always correct.
Whereas just flushing the CPU domain may be a hassle for us in future.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
[Bug 93478] [amdgpu] [tonga] VM Faults and card lock up
https://bugs.freedesktop.org/show_bug.cgi?id=93478 Bug ID: 93478 Summary: [amdgpu] [tonga] VM Faults and card lock up Product: DRI Version: DRI git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel at lists.freedesktop.org Reporter: mike at fireburn.co.uk Created attachment 120653 --> https://bugs.freedesktop.org/attachment.cgi?id=120653&action=edit Dmesg with errors When I was playing Bioshock the game locked up - I'm not sure if this was due to overheating, I'd been playing a while The dmesg was full of VM faults - my desktop still continued to work but no games launched with DRI_PRIME=1 would work I had to force power off the machine to allow it to shut down -- 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/20151222/1a9c3fe5/attachment.html>
[Bug 80419] XCOM: Enemy Unknown Causes lockup
https://bugs.freedesktop.org/show_bug.cgi?id=80419 --- Comment #86 from Nicolai Hähnle --- Many thanks for your patience! While I still did not see a crash, valgrind does indeed report errors when playing back your crash. It is possible that such errors are indirectly related to the lockup, if they lead to bad data being sent to the card. Today's my last day before the holidays, but I'll look into this next week. -- 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/20151222/6ebf0f5f/attachment.html>
[PATCH igt v7 6/6] tests: Add prime_mmap_coherency for cache coherency tests
Different than kms_mmap_write_crc that captures the coherency issues within the
scanout mapped buffer, this one is meant for test dma-buf mmap on !llc
platforms mostly and provoke coherency bugs so we know where we need the sync
ioctls.
I tested this with !llc and llc platforms, BTY and IVY respectively.
Signed-off-by: Tiago Vignatti
---
tests/Makefile.sources | 1 +
tests/prime_mmap_coherency.c | 246 +++
2 files changed, 247 insertions(+)
create mode 100644 tests/prime_mmap_coherency.c
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index ad2dd6a..78605c6 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -97,6 +97,7 @@ TESTS_progs_M = \
pm_rc6_residency \
pm_sseu \
prime_mmap \
+ prime_mmap_coherency \
prime_self_import \
template \
$(NULL)
diff --git a/tests/prime_mmap_coherency.c b/tests/prime_mmap_coherency.c
new file mode 100644
index 000..a9a2664
--- /dev/null
+++ b/tests/prime_mmap_coherency.c
@@ -0,0 +1,246 @@
+/*
+ * Copyright © 2015 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ *Tiago Vignatti
+ */
+
+/** @file prime_mmap_coherency.c
+ *
+ * TODO: need to show the need for prime_sync_end().
+ */
+
+#include "igt.h"
+
+IGT_TEST_DESCRIPTION("Test dma-buf mmap on !llc platforms mostly and provoke"
+ " coherency bugs so we know for sure where we need the sync
ioctls.");
+
+#define ROUNDS 20
+
+int fd;
+int stale = 0;
+static drm_intel_bufmgr *bufmgr;
+struct intel_batchbuffer *batch;
+static int width = 1024, height = 1024;
+
+/*
+ * Exercises the need for read flush:
+ * 1. create a BO and write '0's, in GTT domain.
+ * 2. read BO using the dma-buf CPU mmap.
+ * 3. write '1's, in GTT domain.
+ * 4. read again through the mapped dma-buf.
+ */
+static void test_read_flush(bool expect_stale_cache)
+{
+ drm_intel_bo *bo_1;
+ drm_intel_bo *bo_2;
+ uint32_t *ptr_cpu;
+ uint32_t *ptr_gtt;
+ int dma_buf_fd, i;
+
+ if (expect_stale_cache)
+ igt_require(!gem_has_llc(fd));
+
+ bo_1 = drm_intel_bo_alloc(bufmgr, "BO 1", width * height * 4, 4096);
+
+ /* STEP #1: put the BO 1 in GTT domain. We use the blitter to copy and
fill
+* zeros to BO 1, so commands will be submitted and likely to place BO
1 in
+* the GTT domain. */
+ bo_2 = drm_intel_bo_alloc(bufmgr, "BO 2", width * height * 4, 4096);
+ intel_copy_bo(batch, bo_1, bo_2, width * height);
+ gem_sync(fd, bo_1->handle);
+ drm_intel_bo_unreference(bo_2);
+
+ /* STEP #2: read BO 1 using the dma-buf CPU mmap. This dirties the CPU
caches. */
+ dma_buf_fd = prime_handle_to_fd_for_mmap(fd, bo_1->handle);
+ igt_skip_on(errno == EINVAL);
+
+ ptr_cpu = mmap(NULL, width * height, PROT_READ | PROT_WRITE,
+ MAP_SHARED, dma_buf_fd, 0);
+ igt_assert(ptr_cpu != MAP_FAILED);
+
+ for (i = 0; i < (width * height) / 4; i++)
+ igt_assert_eq(ptr_cpu[i], 0);
+
+ /* STEP #3: write 0x11 into BO 1. */
+ bo_2 = drm_intel_bo_alloc(bufmgr, "BO 2", width * height * 4, 4096);
+ ptr_gtt = gem_mmap__gtt(fd, bo_2->handle, width * height, PROT_READ |
PROT_WRITE);
+ memset(ptr_gtt, 0x11, width * height);
+ munmap(ptr_gtt, width * height);
+
+ intel_copy_bo(batch, bo_1, bo_2, width * height);
+ gem_sync(fd, bo_1->handle);
+ drm_intel_bo_unreference(bo_2);
+
+ /* STEP #4: read again using the CPU mmap. Doing #1 before #3 makes
sure we
+* don't do a full CPU cache flush in step #3 again. That makes sure
all the
+* stale cachelines from step #2 survive (mostly, a few will be evicted)
+* until we try to read them again in step #4. This behavior could be
fixed
+* by flush C
[PATCH igt v7 5/6] tests: Add kms_mmap_write_crc for cache coherency tests
This program can be used to detect when CPU writes in the dma-buf mapped object
don't land in scanout due cache incoherency.
Although this seems a problem inherently of non-LCC machines ("Atom"), this
particular test catches a cache dirt on scanout on LLC machines as well. It's
inspired in Ville's kms_pwrite_crc.c and can be used also to test the
correctness of the driver's begin_cpu_access and end_cpu_access (which requires
i915 implementation.
To see the need for flush, one has to run using '-n' option to not call the
sync ioctls which, via a rather simple CPU hog the system will trashes the
caches, while the test will catch the coherency issue. If you now suppress
'-n', then things should just work like expected.
I tested this with !llc and llc platforms, BTY and IVY respectively.
v2: use prime_handle_to_fd_for_mmap instead.
v3: merge end_cpu_access() patch with this and provide options to disable sync.
v4: use library's prime_sync_{start,end} instead.
v7: use CPU hog instead and use testing rounds to catch the sync problems.
Signed-off-by: Tiago Vignatti
---
tests/Makefile.sources | 1 +
tests/kms_mmap_write_crc.c | 313 +
2 files changed, 314 insertions(+)
create mode 100644 tests/kms_mmap_write_crc.c
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 75f3cb0..ad2dd6a 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -168,6 +168,7 @@ TESTS_progs = \
kms_3d \
kms_fence_pin_leak \
kms_force_connector_basic \
+ kms_mmap_write_crc \
kms_pwrite_crc \
kms_sink_crc_basic \
prime_udl \
diff --git a/tests/kms_mmap_write_crc.c b/tests/kms_mmap_write_crc.c
new file mode 100644
index 000..6984bbd
--- /dev/null
+++ b/tests/kms_mmap_write_crc.c
@@ -0,0 +1,313 @@
+/*
+ * Copyright © 2015 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ *Tiago Vignatti
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include "drmtest.h"
+#include "igt_debugfs.h"
+#include "igt_kms.h"
+#include "intel_chipset.h"
+#include "ioctl_wrappers.h"
+#include "igt_aux.h"
+
+IGT_TEST_DESCRIPTION(
+ "Use the display CRC support to validate mmap write to an already uncached
future scanout buffer.");
+
+#define ROUNDS 10
+
+typedef struct {
+ int drm_fd;
+ igt_display_t display;
+ struct igt_fb fb[2];
+ igt_output_t *output;
+ igt_plane_t *primary;
+ enum pipe pipe;
+ igt_crc_t ref_crc;
+ igt_pipe_crc_t *pipe_crc;
+ uint32_t devid;
+} data_t;
+
+static int ioctl_sync = true;
+int dma_buf_fd;
+
+static char *dmabuf_mmap_framebuffer(int drm_fd, struct igt_fb *fb)
+{
+ char *ptr = NULL;
+
+ dma_buf_fd = prime_handle_to_fd_for_mmap(drm_fd, fb->gem_handle);
+ igt_skip_on(dma_buf_fd == -1 && errno == EINVAL);
+
+ ptr = mmap(NULL, fb->size, PROT_READ | PROT_WRITE, MAP_SHARED,
dma_buf_fd, 0);
+ igt_assert(ptr != MAP_FAILED);
+
+ return ptr;
+}
+
+static void test(data_t *data)
+{
+ igt_display_t *display = &data->display;
+ igt_output_t *output = data->output;
+ struct igt_fb *fb = &data->fb[1];
+ drmModeModeInfo *mode;
+ cairo_t *cr;
+ char *ptr;
+ uint32_t caching;
+ void *buf;
+ igt_crc_t crc;
+
+ mode = igt_output_get_mode(output);
+
+ /* create a non-white fb where we can write later */
+ igt_create_fb(data->drm_fd, mode->hdisplay, mode->vdisplay,
+ DRM_FORMAT_XRGB, LOCAL_DRM_FORMAT_MOD_NONE, fb);
+
+ ptr = dmabuf_mmap_framebuffer(data->drm_fd, fb);
+
+ cr = igt_get_cairo_ctx(data->drm_fd, fb);
+ igt_paint_test_pattern(cr, fb->width, fb->height);
+ cairo_destroy(cr);
+
+ /* flip to it to make it UC/WC and fully flushed */
+ igt_plane_set_fb(data->primary, fb);
+
[PATCH igt v7 4/6] lib: Add prime_sync_start and prime_sync_end helpers
This patch adds dma-buf mmap synchronization ioctls that can be used by tests
for cache coherency management e.g. when CPU and GPU domains are being accessed
through dma-buf at the same time.
v7: add sync invalid flags test.
Signed-off-by: Tiago Vignatti
---
lib/ioctl_wrappers.c | 26 ++
lib/ioctl_wrappers.h | 17 +
tests/prime_mmap.c | 25 +
3 files changed, 68 insertions(+)
diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c
index 86a61ba..0d84d00 100644
--- a/lib/ioctl_wrappers.c
+++ b/lib/ioctl_wrappers.c
@@ -1400,6 +1400,32 @@ off_t prime_get_size(int dma_buf_fd)
}
/**
+ * prime_sync_start
+ * @dma_buf_fd: dma-buf fd handle
+ */
+void prime_sync_start(int dma_buf_fd)
+{
+ struct local_dma_buf_sync sync_start;
+
+ memset(&sync_start, 0, sizeof(sync_start));
+ sync_start.flags = LOCAL_DMA_BUF_SYNC_START | LOCAL_DMA_BUF_SYNC_RW;
+ do_ioctl(dma_buf_fd, LOCAL_DMA_BUF_IOCTL_SYNC, &sync_start);
+}
+
+/**
+ * prime_sync_end
+ * @dma_buf_fd: dma-buf fd handle
+ */
+void prime_sync_end(int dma_buf_fd)
+{
+ struct local_dma_buf_sync sync_end;
+
+ memset(&sync_end, 0, sizeof(sync_end));
+ sync_end.flags = LOCAL_DMA_BUF_SYNC_END | LOCAL_DMA_BUF_SYNC_RW;
+ do_ioctl(dma_buf_fd, LOCAL_DMA_BUF_IOCTL_SYNC, &sync_end);
+}
+
+/**
* igt_require_fb_modifiers:
* @fd: Open DRM file descriptor.
*
diff --git a/lib/ioctl_wrappers.h b/lib/ioctl_wrappers.h
index d3ffba2..d004165 100644
--- a/lib/ioctl_wrappers.h
+++ b/lib/ioctl_wrappers.h
@@ -148,6 +148,21 @@ void gem_require_caching(int fd);
void gem_require_ring(int fd, int ring_id);
/* prime */
+struct local_dma_buf_sync {
+ uint64_t flags;
+};
+
+#define LOCAL_DMA_BUF_SYNC_READ (1 << 0)
+#define LOCAL_DMA_BUF_SYNC_WRITE (2 << 0)
+#define LOCAL_DMA_BUF_SYNC_RW(LOCAL_DMA_BUF_SYNC_READ |
LOCAL_DMA_BUF_SYNC_WRITE)
+#define LOCAL_DMA_BUF_SYNC_START (0 << 2)
+#define LOCAL_DMA_BUF_SYNC_END (1 << 2)
+#define LOCAL_DMA_BUF_SYNC_VALID_FLAGS_MASK \
+ (LOCAL_DMA_BUF_SYNC_RW | LOCAL_DMA_BUF_SYNC_END)
+
+#define LOCAL_DMA_BUF_BASE 'b'
+#define LOCAL_DMA_BUF_IOCTL_SYNC _IOW(LOCAL_DMA_BUF_BASE, 0, struct
local_dma_buf_sync)
+
int prime_handle_to_fd(int fd, uint32_t handle);
#ifndef DRM_RDWR
#define DRM_RDWR O_RDWR
@@ -155,6 +170,8 @@ int prime_handle_to_fd(int fd, uint32_t handle);
int prime_handle_to_fd_for_mmap(int fd, uint32_t handle);
uint32_t prime_fd_to_handle(int fd, int dma_buf_fd);
off_t prime_get_size(int dma_buf_fd);
+void prime_sync_start(int dma_buf_fd);
+void prime_sync_end(int dma_buf_fd);
/* addfb2 fb modifiers */
struct local_drm_mode_fb_cmd2 {
diff --git a/tests/prime_mmap.c b/tests/prime_mmap.c
index 269ada6..29a0cfd 100644
--- a/tests/prime_mmap.c
+++ b/tests/prime_mmap.c
@@ -401,6 +401,30 @@ test_errors(void)
gem_close(fd, handle);
}
+/* Test for invalid flags on sync ioctl */
+static void
+test_invalid_sync_flags(void)
+{
+ int i, dma_buf_fd;
+ uint32_t handle;
+ struct local_dma_buf_sync sync;
+ int invalid_flags[] = {-1,
+ 0x00,
+ LOCAL_DMA_BUF_SYNC_RW + 1,
+ LOCAL_DMA_BUF_SYNC_VALID_FLAGS_MASK + 1};
+
+ handle = gem_create(fd, BO_SIZE);
+ dma_buf_fd = prime_handle_to_fd(fd, handle);
+ for (i = 0; i < sizeof(invalid_flags) / sizeof(invalid_flags[0]); i++) {
+ memset(&sync, 0, sizeof(sync));
+ sync.flags = invalid_flags[i];
+
+ drmIoctl(dma_buf_fd, LOCAL_DMA_BUF_IOCTL_SYNC, &sync);
+ igt_assert_eq(errno, EINVAL);
+ errno = 0;
+ }
+}
+
static void
test_aperture_limit(void)
{
@@ -473,6 +497,7 @@ igt_main
{ "test_dup", test_dup },
{ "test_userptr", test_userptr },
{ "test_errors", test_errors },
+ { "test_invalid_sync_flags", test_invalid_sync_flags },
{ "test_aperture_limit", test_aperture_limit },
};
int i;
--
2.1.4
[PATCH igt v7 3/6] prime_mmap: Add basic tests to write in a bo using CPU
This patch adds test_correct_cpu_write, which maps the texture buffer through a
prime fd and then writes directly to it using the CPU. It stresses the driver
to guarantee cache synchronization among the different domains.
This test also adds test_forked_cpu_write, which creates the GEM bo in one
process and pass the prime handle of the it to another process, which in turn
uses the handle only to map and write. Roughly speaking this test simulates
Chrome OS architecture, where the Web content ("unpriviledged process") maps
and CPU-draws a buffer, which was previously allocated in the GPU process
("priviledged process").
This requires kernel modifications (Daniel Thompson's "drm: prime: Honour
O_RDWR during prime-handle-to-fd") and therefore prime_handle_to_fd_for_mmap is
added to fail in case these lack. Also, upcoming tests (e.g. next patch) are
going to use it as well, so make it public and available in the lib.
v2: adds prime_handle_to_fd_with_mmap for skipping test in older kernels and
test for invalid flags.
Signed-off-by: Tiago Vignatti
---
lib/ioctl_wrappers.c | 25 +++
lib/ioctl_wrappers.h | 4 +++
tests/prime_mmap.c | 89
3 files changed, 112 insertions(+), 6 deletions(-)
diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c
index 6cad8a2..86a61ba 100644
--- a/lib/ioctl_wrappers.c
+++ b/lib/ioctl_wrappers.c
@@ -1329,6 +1329,31 @@ int prime_handle_to_fd(int fd, uint32_t handle)
}
/**
+ * prime_handle_to_fd_for_mmap:
+ * @fd: open i915 drm file descriptor
+ * @handle: file-private gem buffer object handle
+ *
+ * Same as prime_handle_to_fd above but with DRM_RDWR capabilities, which can
+ * be useful for writing into the mmap'ed dma-buf file-descriptor.
+ *
+ * Returns: The created dma-buf fd handle or -1 if the ioctl fails.
+ */
+int prime_handle_to_fd_for_mmap(int fd, uint32_t handle)
+{
+ struct drm_prime_handle args;
+
+ memset(&args, 0, sizeof(args));
+ args.handle = handle;
+ args.flags = DRM_CLOEXEC | DRM_RDWR;
+ args.fd = -1;
+
+ if (drmIoctl(fd, DRM_IOCTL_PRIME_HANDLE_TO_FD, &args) != 0)
+ return -1;
+
+ return args.fd;
+}
+
+/**
* prime_fd_to_handle:
* @fd: open i915 drm file descriptor
* @dma_buf_fd: dma-buf fd handle
diff --git a/lib/ioctl_wrappers.h b/lib/ioctl_wrappers.h
index bb8a858..d3ffba2 100644
--- a/lib/ioctl_wrappers.h
+++ b/lib/ioctl_wrappers.h
@@ -149,6 +149,10 @@ void gem_require_ring(int fd, int ring_id);
/* prime */
int prime_handle_to_fd(int fd, uint32_t handle);
+#ifndef DRM_RDWR
+#define DRM_RDWR O_RDWR
+#endif
+int prime_handle_to_fd_for_mmap(int fd, uint32_t handle);
uint32_t prime_fd_to_handle(int fd, int dma_buf_fd);
off_t prime_get_size(int dma_buf_fd);
diff --git a/tests/prime_mmap.c b/tests/prime_mmap.c
index 95304a9..269ada6 100644
--- a/tests/prime_mmap.c
+++ b/tests/prime_mmap.c
@@ -22,6 +22,7 @@
*
* Authors:
*Rob Bradford
+ *Tiago Vignatti
*
*/
@@ -66,6 +67,12 @@ fill_bo(uint32_t handle, size_t size)
}
static void
+fill_bo_cpu(char *ptr)
+{
+ memcpy(ptr, pattern, sizeof(pattern));
+}
+
+static void
test_correct(void)
{
int dma_buf_fd;
@@ -180,6 +187,65 @@ test_forked(void)
gem_close(fd, handle);
}
+/* test simple CPU write */
+static void
+test_correct_cpu_write(void)
+{
+ int dma_buf_fd;
+ char *ptr;
+ uint32_t handle;
+
+ handle = gem_create(fd, BO_SIZE);
+
+ dma_buf_fd = prime_handle_to_fd_for_mmap(fd, handle);
+
+ /* Skip if DRM_RDWR is not supported */
+ igt_skip_on(errno == EINVAL);
+
+ /* Check correctness of map using write protection (PROT_WRITE) */
+ ptr = mmap(NULL, BO_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED,
dma_buf_fd, 0);
+ igt_assert(ptr != MAP_FAILED);
+
+ /* Fill bo using CPU */
+ fill_bo_cpu(ptr);
+
+ /* Check pattern correctness */
+ igt_assert(memcmp(ptr, pattern, sizeof(pattern)) == 0);
+
+ munmap(ptr, BO_SIZE);
+ close(dma_buf_fd);
+ gem_close(fd, handle);
+}
+
+/* map from another process and then write using CPU */
+static void
+test_forked_cpu_write(void)
+{
+ int dma_buf_fd;
+ char *ptr;
+ uint32_t handle;
+
+ handle = gem_create(fd, BO_SIZE);
+
+ dma_buf_fd = prime_handle_to_fd_for_mmap(fd, handle);
+
+ /* Skip if DRM_RDWR is not supported */
+ igt_skip_on(errno == EINVAL);
+
+ igt_fork(childno, 1) {
+ ptr = mmap(NULL, BO_SIZE, PROT_READ | PROT_WRITE , MAP_SHARED,
dma_buf_fd, 0);
+ igt_assert(ptr != MAP_FAILED);
+ fill_bo_cpu(ptr);
+
+ igt_assert(memcmp(ptr, pattern, sizeof(pattern)) == 0);
+ munmap(ptr, BO_SIZE);
+ close(dma_buf_fd);
+ }
+ close(dma_buf_fd);
+ igt_waitchildren();
+ gem_close(fd, handle);
+}
+
static void
test_refcounting(void)
{
@@ -224,15 +290,14 @@ test_dup(v
[PATCH igt v7 2/6] prime_mmap: Add new test for calling mmap() on dma-buf fds
From: Rob Bradford
This test has the following subtests:
- test_correct for correctness of the data
- test_map_unmap checks for mapping idempotency
- test_reprime checks for dma-buf creation idempotency
- test_forked checks for multiprocess access
- test_refcounting checks for buffer reference counting
- test_dup checks that dup()ing the fd works
- test_userptr make sure it fails when mmaping due the lack of obj->base.filp
in a userptr.
- test_errors checks the error return values for failures
- test_aperture_limit tests multiple buffer creation at the gtt aperture
limit
v2 (Tiago): Removed pattern_check(), which was walking through a useless
iterator. Removed superfluous PROT_WRITE from gem_mmap, in test_correct().
Added binary file to .gitignore
v3 (Tiago): squash patch "prime_mmap: Test for userptr mmap" into this one.
v4 (Tiago): use synchronized userptr for testing. Add test for buffer
overlapping.
Signed-off-by: Rob Bradford
Signed-off-by: Tiago Vignatti
---
tests/Makefile.sources | 1 +
tests/prime_mmap.c | 417 +
2 files changed, 418 insertions(+)
create mode 100644 tests/prime_mmap.c
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index d594038..75f3cb0 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -96,6 +96,7 @@ TESTS_progs_M = \
pm_rps \
pm_rc6_residency \
pm_sseu \
+ prime_mmap \
prime_self_import \
template \
$(NULL)
diff --git a/tests/prime_mmap.c b/tests/prime_mmap.c
new file mode 100644
index 000..95304a9
--- /dev/null
+++ b/tests/prime_mmap.c
@@ -0,0 +1,417 @@
+/*
+ * Copyright © 2014 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ *Rob Bradford
+ *
+ */
+
+/*
+ * Testcase: Check whether mmap()ing dma-buf works
+ */
+#define _GNU_SOURCE
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "drm.h"
+#include "i915_drm.h"
+#include "drmtest.h"
+#include "igt_debugfs.h"
+#include "ioctl_wrappers.h"
+
+#define BO_SIZE (16*1024)
+
+static int fd;
+
+char pattern[] = {0xff, 0x00, 0x00, 0x00,
+ 0x00, 0xff, 0x00, 0x00,
+ 0x00, 0x00, 0xff, 0x00,
+ 0x00, 0x00, 0x00, 0xff};
+
+static void
+fill_bo(uint32_t handle, size_t size)
+{
+ off_t i;
+ for (i = 0; i < size; i+=sizeof(pattern))
+ {
+ gem_write(fd, handle, i, pattern, sizeof(pattern));
+ }
+}
+
+static void
+test_correct(void)
+{
+ int dma_buf_fd;
+ char *ptr1, *ptr2;
+ uint32_t handle;
+
+ handle = gem_create(fd, BO_SIZE);
+ fill_bo(handle, BO_SIZE);
+
+ dma_buf_fd = prime_handle_to_fd(fd, handle);
+ igt_assert(errno == 0);
+
+ /* Check correctness vs GEM_MMAP_GTT */
+ ptr1 = gem_mmap__gtt(fd, handle, BO_SIZE, PROT_READ);
+ ptr2 = mmap(NULL, BO_SIZE, PROT_READ, MAP_SHARED, dma_buf_fd, 0);
+ igt_assert(ptr1 != MAP_FAILED);
+ igt_assert(ptr2 != MAP_FAILED);
+ igt_assert(memcmp(ptr1, ptr2, BO_SIZE) == 0);
+
+ /* Check pattern correctness */
+ igt_assert(memcmp(ptr2, pattern, sizeof(pattern)) == 0);
+
+ munmap(ptr1, BO_SIZE);
+ munmap(ptr2, BO_SIZE);
+ close(dma_buf_fd);
+ gem_close(fd, handle);
+}
+
+static void
+test_map_unmap(void)
+{
+ int dma_buf_fd;
+ char *ptr;
+ uint32_t handle;
+
+ handle = gem_create(fd, BO_SIZE);
+ fill_bo(handle, BO_SIZE);
+
+ dma_buf_fd = prime_handle_to_fd(fd, handle);
+ igt_assert(errno == 0);
+
+ ptr = mmap(NULL, BO_SIZE, PROT_READ, MAP_SHARED, dma_buf_fd, 0);
+ igt_assert(ptr != MAP_FAILED);
+ igt_assert(memcmp(ptr, pattern, sizeof(pattern)) == 0);
+
+ /* Unmap and remap */
+ munmap(ptr, BO_SIZE);
+ ptr = mmap(NULL, BO_SIZE, PROT_READ,
[PATCH igt v7 1/6] lib: Add gem_userptr and __gem_userptr helpers
This patch moves userptr definitions and helpers implementation that were
locally in gem_userptr_benchmark and gem_userptr_blits to the library, so other
tests can make use of them as well. There's no functional changes.
v2: added __ function to differentiate when errors want to be handled back in
the caller; bring gem_userptr_sync back to gem_userptr_blits; added gtkdoc.
Signed-off-by: Tiago Vignatti
---
benchmarks/gem_userptr_benchmark.c | 55 +++-
lib/ioctl_wrappers.c | 41 +++
lib/ioctl_wrappers.h | 13 +
tests/gem_userptr_blits.c | 104 ++---
4 files changed, 86 insertions(+), 127 deletions(-)
diff --git a/benchmarks/gem_userptr_benchmark.c
b/benchmarks/gem_userptr_benchmark.c
index 1eae7ff..f7716df 100644
--- a/benchmarks/gem_userptr_benchmark.c
+++ b/benchmarks/gem_userptr_benchmark.c
@@ -58,17 +58,6 @@
#define PAGE_SIZE 4096
#endif
-#define LOCAL_I915_GEM_USERPTR 0x33
-#define LOCAL_IOCTL_I915_GEM_USERPTR DRM_IOWR (DRM_COMMAND_BASE +
LOCAL_I915_GEM_USERPTR, struct local_i915_gem_userptr)
-struct local_i915_gem_userptr {
- uint64_t user_ptr;
- uint64_t user_size;
- uint32_t flags;
-#define LOCAL_I915_USERPTR_READ_ONLY (1<<0)
-#define LOCAL_I915_USERPTR_UNSYNCHRONIZED (1<<31)
- uint32_t handle;
-};
-
static uint32_t userptr_flags = LOCAL_I915_USERPTR_UNSYNCHRONIZED;
#define BO_SIZE (65536)
@@ -83,30 +72,6 @@ static void gem_userptr_test_synchronized(void)
userptr_flags = 0;
}
-static int gem_userptr(int fd, void *ptr, int size, int read_only, uint32_t
*handle)
-{
- struct local_i915_gem_userptr userptr;
- int ret;
-
- userptr.user_ptr = (uintptr_t)ptr;
- userptr.user_size = size;
- userptr.flags = userptr_flags;
- if (read_only)
- userptr.flags |= LOCAL_I915_USERPTR_READ_ONLY;
-
- ret = drmIoctl(fd, LOCAL_IOCTL_I915_GEM_USERPTR, &userptr);
- if (ret)
- ret = errno;
- igt_skip_on_f(ret == ENODEV &&
- (userptr_flags & LOCAL_I915_USERPTR_UNSYNCHRONIZED) == 0
&&
- !read_only,
- "Skipping, synchronized mappings with no kernel
CONFIG_MMU_NOTIFIER?");
- if (ret == 0)
- *handle = userptr.handle;
-
- return ret;
-}
-
static void **handle_ptr_map;
static unsigned int num_handle_ptr_map;
@@ -144,8 +109,7 @@ static uint32_t create_userptr_bo(int fd, int size)
ret = posix_memalign(&ptr, PAGE_SIZE, size);
igt_assert(ret == 0);
- ret = gem_userptr(fd, (uint32_t *)ptr, size, 0, &handle);
- igt_assert(ret == 0);
+ gem_userptr(fd, (uint32_t *)ptr, size, 0, userptr_flags, &handle);
add_handle_ptr(handle, ptr);
return handle;
@@ -167,7 +131,7 @@ static int has_userptr(int fd)
assert(posix_memalign(&ptr, PAGE_SIZE, PAGE_SIZE) == 0);
oldflags = userptr_flags;
gem_userptr_test_unsynchronized();
- ret = gem_userptr(fd, ptr, PAGE_SIZE, 0, &handle);
+ ret = __gem_userptr(fd, ptr, PAGE_SIZE, 0, userptr_flags, &handle);
userptr_flags = oldflags;
if (ret != 0) {
free(ptr);
@@ -379,9 +343,7 @@ static void test_impact_overlap(int fd, const char *prefix)
for (i = 0, p = block; i < nr_bos[subtest];
i++, p += PAGE_SIZE)
- ret = gem_userptr(fd, (uint32_t *)p, BO_SIZE, 0,
- &handles[i]);
- igt_assert(ret == 0);
+ gem_userptr(fd, (uint32_t *)p, BO_SIZE, 0,
userptr_flags, &handles[i]);
}
if (nr_bos[subtest] > 0)
@@ -427,7 +389,6 @@ static void test_single(int fd)
char *ptr, *bo_ptr;
uint32_t handle = 0;
unsigned long iter = 0;
- int ret;
unsigned long map_size = BO_SIZE + PAGE_SIZE - 1;
ptr = mmap(NULL, map_size, PROT_READ | PROT_WRITE,
@@ -439,8 +400,7 @@ static void test_single(int fd)
start_test(test_duration_sec);
while (run_test) {
- ret = gem_userptr(fd, bo_ptr, BO_SIZE, 0, &handle);
- assert(ret == 0);
+ gem_userptr(fd, bo_ptr, BO_SIZE, 0, userptr_flags, &handle);
gem_close(fd, handle);
iter++;
}
@@ -456,7 +416,6 @@ static void test_multiple(int fd, unsigned int batch, int
random)
uint32_t handles[1];
int map[1];
unsigned long iter = 0;
- int ret;
int i;
unsigned long map_size = batch * BO_SIZE + PAGE_SIZE - 1;
@@ -478,10 +437,8 @@ static void test_multiple(int fd, unsigned int batch, int
random)
if (random)
igt_permute_array(map, batch, igt_exchange_int);
for (i = 0; i < batch; i++) {
- r
[PATCH v7 5/5] drm/i915: Use CPU mapping for userspace dma-buf mmap()
Userspace is the one in charge of flush CPU by wrapping mmap with
begin{,end}_cpu_access.
v2: Remove LLC check cause we have dma-buf sync providers now. Also, fix return
before transferring ownership when mmap fails.
v3: Fix return values.
v4: !obj->base.filp is user triggerable, so removed the WARN_ON.
Reviewed-by: Chris Wilson
Signed-off-by: Tiago Vignatti
---
drivers/gpu/drm/i915/i915_gem_dmabuf.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
index 8c9ed2a..1f3eef6 100644
--- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
@@ -193,7 +193,23 @@ static void i915_gem_dmabuf_kunmap(struct dma_buf
*dma_buf, unsigned long page_n
static int i915_gem_dmabuf_mmap(struct dma_buf *dma_buf, struct vm_area_struct
*vma)
{
- return -EINVAL;
+ struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
+ int ret;
+
+ if (obj->base.size < vma->vm_end - vma->vm_start)
+ return -EINVAL;
+
+ if (!obj->base.filp)
+ return -ENODEV;
+
+ ret = obj->base.filp->f_op->mmap(obj->base.filp, vma);
+ if (ret)
+ return ret;
+
+ fput(vma->vm_file);
+ vma->vm_file = get_file(obj->base.filp);
+
+ return 0;
}
static int i915_gem_begin_cpu_access(struct dma_buf *dma_buf, enum
dma_data_direction direction)
--
2.1.4
[PATCH v7 4/5] drm/i915: Implement end_cpu_access
This function is meant to be used with dma-buf mmap, when finishing the CPU
access of the mapped pointer.
The error case should be rare to happen though, requiring the buffer become
active during the sync period and for the end_cpu_access to be interrupted. So
we use a uninterruptible mutex_lock to spit out when it ever happens.
v2: disable interruption to make sure errors are reported.
v3: update to the new end_cpu_access API.
v7: use .write = false cause it doesn't need to know whether it's write.
Reviewed-by: Chris Wilson
Signed-off-by: Tiago Vignatti
---
drivers/gpu/drm/i915/i915_gem_dmabuf.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
index 65ab2bd..8c9ed2a 100644
--- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
@@ -212,6 +212,27 @@ static int i915_gem_begin_cpu_access(struct dma_buf
*dma_buf, enum dma_data_dire
return ret;
}
+static void i915_gem_end_cpu_access(struct dma_buf *dma_buf, enum
dma_data_direction direction)
+{
+ struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
+ struct drm_device *dev = obj->base.dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
+ bool was_interruptible;
+ int ret;
+
+ mutex_lock(&dev->struct_mutex);
+ was_interruptible = dev_priv->mm.interruptible;
+ dev_priv->mm.interruptible = false;
+
+ ret = i915_gem_object_set_to_gtt_domain(obj, false);
+
+ dev_priv->mm.interruptible = was_interruptible;
+ mutex_unlock(&dev->struct_mutex);
+
+ if (unlikely(ret))
+ DRM_ERROR("unable to flush buffer following CPU access;
rendering may be corrupt\n");
+}
+
static const struct dma_buf_ops i915_dmabuf_ops = {
.map_dma_buf = i915_gem_map_dma_buf,
.unmap_dma_buf = i915_gem_unmap_dma_buf,
@@ -224,6 +245,7 @@ static const struct dma_buf_ops i915_dmabuf_ops = {
.vmap = i915_gem_dmabuf_vmap,
.vunmap = i915_gem_dmabuf_vunmap,
.begin_cpu_access = i915_gem_begin_cpu_access,
+ .end_cpu_access = i915_gem_end_cpu_access,
};
struct dma_buf *i915_gem_prime_export(struct drm_device *dev,
--
2.1.4
[PATCH v7 3/5] dma-buf: Add ioctls to allow userspace to flush
From: Daniel Vetter
The userspace might need some sort of cache coherency management e.g. when CPU
and GPU domains are being accessed through dma-buf at the same time. To
circumvent this problem there are begin/end coherency markers, that forward
directly to existing dma-buf device drivers vfunc hooks. Userspace can make use
of those markers through the DMA_BUF_IOCTL_SYNC ioctl. The sequence would be
used like following:
- mmap dma-buf fd
- for each drawing/upload cycle in CPU 1. SYNC_START ioctl, 2. read/write
to mmap area 3. SYNC_END ioctl. This can be repeated as often as you
want (with the new data being consumed by the GPU or say scanout device)
- munmap once you don't need the buffer any more
v2 (Tiago): Fix header file type names (u64 -> __u64)
v3 (Tiago): Add documentation. Use enum dma_buf_sync_flags to the begin/end
dma-buf functions. Check for overflows in start/length.
v4 (Tiago): use 2d regions for sync.
v5 (Tiago): forget about 2d regions (v4); use _IOW in DMA_BUF_IOCTL_SYNC and
remove range information from struct dma_buf_sync.
v6 (Tiago): use __u64 structured padded flags instead enum. Adjust
documentation about the recommendation on using sync ioctls.
v7 (Tiago): Alex' nit on flags definition and being even more wording in the
doc about sync usage.
Cc: Sumit Semwal
Signed-off-by: Daniel Vetter
Signed-off-by: Tiago Vignatti
---
Documentation/dma-buf-sharing.txt | 21 ++-
drivers/dma-buf/dma-buf.c | 43 +++
include/uapi/linux/dma-buf.h | 38 ++
3 files changed, 101 insertions(+), 1 deletion(-)
create mode 100644 include/uapi/linux/dma-buf.h
diff --git a/Documentation/dma-buf-sharing.txt
b/Documentation/dma-buf-sharing.txt
index 4f4a84b..32ac32e 100644
--- a/Documentation/dma-buf-sharing.txt
+++ b/Documentation/dma-buf-sharing.txt
@@ -350,7 +350,26 @@ Being able to mmap an export dma-buf buffer object has 2
main use-cases:
handles, too). So it's beneficial to support this in a similar fashion on
dma-buf to have a good transition path for existing Android userspace.
- No special interfaces, userspace simply calls mmap on the dma-buf fd.
+ No special interfaces, userspace simply calls mmap on the dma-buf fd, making
+ sure that the cache synchronization ioctl (DMA_BUF_IOCTL_SYNC) is *always*
+ used when the access happens. This is discussed next paragraphs.
+
+ Some systems might need some sort of cache coherency management e.g. when
+ CPU and GPU domains are being accessed through dma-buf at the same time. To
+ circumvent this problem there are begin/end coherency markers, that forward
+ directly to existing dma-buf device drivers vfunc hooks. Userspace can make
+ use of those markers through the DMA_BUF_IOCTL_SYNC ioctl. The sequence
+ would be used like following:
+ - mmap dma-buf fd
+ - for each drawing/upload cycle in CPU 1. SYNC_START ioctl, 2. read/write
+ to mmap area 3. SYNC_END ioctl. This can be repeated as often as you
+ want (with the new data being consumed by the GPU or say scanout device)
+ - munmap once you don't need the buffer any more
+
+Therefore, for correctness and optimal performance, systems with the memory
+cache shared by the GPU and CPU i.e. the "coherent" and also the
+"incoherent" are always required to use SYNC_START and SYNC_END before and
+after, respectively, when accessing the mapped address.
2. Supporting existing mmap interfaces in importers
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index b2ac13b..9a298bd 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -34,6 +34,8 @@
#include
#include
+#include
+
static inline int is_dma_buf_file(struct file *);
struct dma_buf_list {
@@ -251,11 +253,52 @@ out:
return events;
}
+static long dma_buf_ioctl(struct file *file,
+ unsigned int cmd, unsigned long arg)
+{
+ struct dma_buf *dmabuf;
+ struct dma_buf_sync sync;
+ enum dma_data_direction direction;
+
+ dmabuf = file->private_data;
+
+ if (!is_dma_buf_file(file))
+ return -EINVAL;
+
+ switch (cmd) {
+ case DMA_BUF_IOCTL_SYNC:
+ if (copy_from_user(&sync, (void __user *) arg, sizeof(sync)))
+ return -EFAULT;
+
+ if (sync.flags & DMA_BUF_SYNC_RW)
+ direction = DMA_BIDIRECTIONAL;
+ else if (sync.flags & DMA_BUF_SYNC_READ)
+ direction = DMA_FROM_DEVICE;
+ else if (sync.flags & DMA_BUF_SYNC_WRITE)
+ direction = DMA_TO_DEVICE;
+ else
+ return -EINVAL;
+
+ if (sync.flags & ~DMA_BUF_SYNC_VALID_FLAGS_MASK)
+ return -EINVAL;
+
+ if (sync.flags & DMA_BUF_SYNC_END)
+ dma_buf_end_cpu_ac
[PATCH v7 2/5] dma-buf: Remove range-based flush
This patch removes range-based information used for optimizations in
begin_cpu_access and end_cpu_access.
We don't have any user nor implementation using range-based flush. It seems a
consensus that if we ever want something like that again (or even more robust
using 2D, 3D sub-range regions) we can use the upcoming dma-buf sync ioctl for
such.
Cc: Sumit Semwal
Cc: Daniel Vetter
Signed-off-by: Tiago Vignatti
---
Documentation/dma-buf-sharing.txt | 19 ---
drivers/dma-buf/dma-buf.c | 13 -
drivers/gpu/drm/i915/i915_gem_dmabuf.c| 2 +-
drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 4 ++--
drivers/gpu/drm/udl/udl_fb.c | 2 --
drivers/staging/android/ion/ion.c | 6 ++
drivers/staging/android/ion/ion_test.c| 4 ++--
include/linux/dma-buf.h | 12 +---
8 files changed, 24 insertions(+), 38 deletions(-)
diff --git a/Documentation/dma-buf-sharing.txt
b/Documentation/dma-buf-sharing.txt
index 480c8de..4f4a84b 100644
--- a/Documentation/dma-buf-sharing.txt
+++ b/Documentation/dma-buf-sharing.txt
@@ -257,17 +257,15 @@ Access to a dma_buf from the kernel context involves
three steps:
Interface:
int dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
- size_t start, size_t len,
enum dma_data_direction direction)
This allows the exporter to ensure that the memory is actually available for
cpu access - the exporter might need to allocate or swap-in and pin the
backing storage. The exporter also needs to ensure that cpu access is
- coherent for the given range and access direction. The range and access
- direction can be used by the exporter to optimize the cache flushing, i.e.
- access outside of the range or with a different direction (read instead of
- write) might return stale or even bogus data (e.g. when the exporter needs
to
- copy the data to temporary storage).
+ coherent for the access direction. The direction can be used by the exporter
+ to optimize the cache flushing, i.e. access with a different direction (read
+ instead of write) might return stale or even bogus data (e.g. when the
+ exporter needs to copy the data to temporary storage).
This step might fail, e.g. in oom conditions.
@@ -322,14 +320,13 @@ Access to a dma_buf from the kernel context involves
three steps:
3. Finish access
- When the importer is done accessing the range specified in begin_cpu_access,
- it needs to announce this to the exporter (to facilitate cache flushing and
- unpinning of any pinned resources). The result of any dma_buf kmap calls
- after end_cpu_access is undefined.
+ When the importer is done accessing the CPU, it needs to announce this to
+ the exporter (to facilitate cache flushing and unpinning of any pinned
+ resources). The result of any dma_buf kmap calls after end_cpu_access is
+ undefined.
Interface:
void dma_buf_end_cpu_access(struct dma_buf *dma_buf,
- size_t start, size_t len,
enum dma_data_direction dir);
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 155c146..b2ac13b 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -539,13 +539,11 @@ EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment);
* preparations. Coherency is only guaranteed in the specified range for the
* specified access direction.
* @dmabuf:[in]buffer to prepare cpu access for.
- * @start: [in]start of range for cpu access.
- * @len: [in]length of range for cpu access.
* @direction: [in]length of range for cpu access.
*
* Can return negative error values, returns 0 on success.
*/
-int dma_buf_begin_cpu_access(struct dma_buf *dmabuf, size_t start, size_t len,
+int dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
enum dma_data_direction direction)
{
int ret = 0;
@@ -554,8 +552,7 @@ int dma_buf_begin_cpu_access(struct dma_buf *dmabuf, size_t
start, size_t len,
return -EINVAL;
if (dmabuf->ops->begin_cpu_access)
- ret = dmabuf->ops->begin_cpu_access(dmabuf, start,
- len, direction);
+ ret = dmabuf->ops->begin_cpu_access(dmabuf, direction);
return ret;
}
@@ -567,19 +564,17 @@ EXPORT_SYMBOL_GPL(dma_buf_begin_cpu_access);
* actions. Coherency is only guaranteed in the specified range for the
* specified access direction.
* @dmabuf:[in]buffer to complete cpu access for.
- * @start: [in]start of range for cpu access.
- * @len: [in]length of range for cpu access.
* @direction: [in]length of range for cpu access.
*
* This call must always succeed.
*/
-void dma_buf_end_cpu_access(struct dma_buf *dmabuf, size_t start, size_t len,
+void dma_buf_end_cpu_a
[PATCH v7 1/5] drm: prime: Honour O_RDWR during prime-handle-to-fd
From: Daniel Thompson
Currently DRM_IOCTL_PRIME_HANDLE_TO_FD rejects all flags except
(DRM|O)_CLOEXEC making it difficult (maybe impossible) for userspace
to mmap() the resulting dma-buf even when this is supported by the
DRM driver.
It is trivial to relax the restriction and permit read/write access.
This is safe because the flags are seldom touched by drm; mostly they
are passed verbatim to dma_buf calls.
v3 (Tiago): removed unused flags variable from drm_prime_handle_to_fd_ioctl.
Reviewed-by: Chris Wilson
Signed-off-by: Daniel Thompson
Signed-off-by: Tiago Vignatti
---
drivers/gpu/drm/drm_prime.c | 10 +++---
include/uapi/drm/drm.h | 1 +
2 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 27aa718..df6cdc7 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -329,7 +329,7 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops =
{
* drm_gem_prime_export - helper library implementation of the export callback
* @dev: drm_device to export from
* @obj: GEM object to export
- * @flags: flags like DRM_CLOEXEC
+ * @flags: flags like DRM_CLOEXEC and DRM_RDWR
*
* This is the implementation of the gem_prime_export functions for GEM drivers
* using the PRIME helpers.
@@ -628,7 +628,6 @@ int drm_prime_handle_to_fd_ioctl(struct drm_device *dev,
void *data,
struct drm_file *file_priv)
{
struct drm_prime_handle *args = data;
- uint32_t flags;
if (!drm_core_check_feature(dev, DRIVER_PRIME))
return -EINVAL;
@@ -637,14 +636,11 @@ int drm_prime_handle_to_fd_ioctl(struct drm_device *dev,
void *data,
return -ENOSYS;
/* check flags are valid */
- if (args->flags & ~DRM_CLOEXEC)
+ if (args->flags & ~(DRM_CLOEXEC | DRM_RDWR))
return -EINVAL;
- /* we only want to pass DRM_CLOEXEC which is == O_CLOEXEC */
- flags = args->flags & DRM_CLOEXEC;
-
return dev->driver->prime_handle_to_fd(dev, file_priv,
- args->handle, flags, &args->fd);
+ args->handle, args->flags, &args->fd);
}
int drm_prime_fd_to_handle_ioctl(struct drm_device *dev, void *data,
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index b4e92eb..a0ebfe7 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -669,6 +669,7 @@ struct drm_set_client_cap {
__u64 value;
};
+#define DRM_RDWR O_RDWR
#define DRM_CLOEXEC O_CLOEXEC
struct drm_prime_handle {
__u32 handle;
--
2.1.4
Direct userspace dma-buf mmap (v7)
Hey back, Thank you Daniel, Chris, Alex and Thomas for reviewing the last series. I think I addressed most of the comments now in version 7, including: - being even more wording in the doc about sync usage. - pass .write = false always in i915 end_cpu_access. - add sync invalid flags test (igt). - in kms_mmap_write_crc, use CPU hog and testing rounds to catch the sync problems (igt). Here are the trees: https://github.com/tiagovignatti/drm-intel/commits/drm-intel-nightly_dma-buf-mmap-v7 https://github.com/tiagovignatti/intel-gpu-tools/commits/dma-buf-mmap-v7 Also, Chrome OS side is in progress. This past week I've been mostly struggling with fail attempts to build it (boots and goes to a black screen. Sigh.) and also finding a way to make my funky BayTrail-T laptop with 32-bit UEFI firmware boot up (success with Ubuntu but no success yet in CrOS). A WIP of Chromium changes can be seen here anyways: https://codereview.chromium.org/1262043002/ Happy Holidays! Tiago -- 2.1.4
[Bug 93032] [radeonsi] Civilization Beyond Earth segfaults
https://bugs.freedesktop.org/show_bug.cgi?id=93032 --- Comment #18 from Paulo Dias --- ill test the update tonight and if it fixes it, ill report it here and close the bug -- 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/20151222/0c4e3c73/attachment.html>
[Bug 76490] Hang during boot when DPM is on (R9 270X)
https://bugs.freedesktop.org/show_bug.cgi?id=76490 --- Comment #92 from Maxim Sheviakov --- So, got my PSU yesterday. Compiled 4.3.3-zen with -Ofast + those patches, quirk removed and firmware added to initrd. Modesetting works, I'm able to see Plymouth finishing its animation. However, at X start stage I get a complete hang, but monitor's active. It's likely a PM error, as else there would be a hang at modesetting stage. It's similar to an issue I had when compiled the kernel with quirk containing my card's normal MEM and CORE clock values - hang due to PM error. Should I do something else? And is there a way to make the card work at its normal frequencies? -- 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/20151222/96a28c2e/attachment.html>
[Bug 93032] [radeonsi] Civilization Beyond Earth segfaults
https://bugs.freedesktop.org/show_bug.cgi?id=93032 --- Comment #17 from Mike Lothian --- I realise I'm not the reporter of the bug but there's been a recent update to the game that fixes things for me on radeonsi -- 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/20151222/b1a9d573/attachment.html>
[pull] radeon and amdgpu drm-next-4.5
Hi Dave, Sorry if you get this several times, I've been having trouble with git-send-email and gmail the last couple of days. Radeon and amdgpu changes for drm-next. Big changes: - Drop UMS support in radeon - Support vbios fetch directly from rom on dGPU - Support for EDC init on CZ - DP audio fix for DCE8 - GPUVM optimizations - Scheduler optimizations - DP display fixes - Add new drm pci helpers for pcie gen and lane info - Add powerplay modules for amdgpu (tonga, fiji, CZ, ST) The following changes since commit 80d69009ef67d0753c1c30c62056a04275898531: Merge tag 'drm-intel-next-2015-11-20-merged' of git://anongit.freedesktop.org/drm-intel into drm-next (2015-12-01 08:01:53 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-next-4.5 for you to fetch changes up to eafbbd9883d0121811a9388988b80476dc12b1bf: amd/powerplay: fix copy paste typo in hardwaremanager.c (2015-12-21 17:13:05 -0500) Alex Deucher (33): drm/radeon: remove UMS support drm/amdgpu: call hpd_irq_event on resume drm/radeon: call hpd_irq_event on resume drm/amdgpu: add a callback for reading the bios from the rom directly drm/amdgpu: add read_bios_from_rom callback for CI parts drm/amdgpu: add read_bios_from_rom callback for VI parts drm/amd: add new gfx8 register definitions for EDC drm/amdgpu: add EDC support for CZ (v3) drm/amdgpu: add more debugging output for driver failures drm/amdgpu: limit visible vram if it's smaller than the BAR drm/amdgpu: fix dp link rate selection (v2) drm/radeon: fix dp link rate selection (v2) drm/radeon: clean up fujitsu quirks drm/amd/powerplay: add basic powerplay framework drm/amd/powerplay/tonga: enable pcie and mclk forcing for low drm/amd/powerplay/fiji: enable pcie and mclk forcing for low drm/amdgpu: extract pcie helpers to common header drm: add drm_pcie_get_max_link_width helper (v2) drm/amdgpu: store pcie gen mask and link width drm/amdgpu/cgs: add sys info query for pcie gen and link width drm/amdgpu/powerplay/tonga: query supported pcie info from cgs (v2) drm/amdgpu/powerplay/fiji: query supported pcie info from cgs (v2) drm/amd/powerplay/tonga: Add UVD DPM init drm/amd/powerplay: add atomctrl function to calculate CZ sclk dividers drm/amd/powerplay: implement smc state upload for CZ drm/amdgpu/powerplay: enable sysfs and debugfs interfaces late drm/powerplay: add debugging output to tonga_processpptables.c drm/powerplay: add debugging output to processpptables.c drm/powerplay/hwmgr: log errors in tonga_hwmgr_backend_init drm/amd/powerplay: Don't return an error if fan table is missing amd/powerplay: don't enable ucode fan control if vbios has no fan table amd/powerplay: disable powerplay by default initially amd/powerplay: fix copy paste typo in hardwaremanager.c Christian König (3): drm/amdgpu: put VM page tables directly into duplicates list drm/amdgpu: split VM PD and PT handling during CS drm/amdgpu: keep the PTs validation list in the VM v2 Chunming Zhou (7): drm/amd: abstract kernel rq and normal rq to priority of run queue drm/amdgpu: add err check for pin userptr drm/amdgpu: add entity only when first job come drm/amdgpu: handle error case for ctx drm/amdgpu: unify AMDGPU_CTX_MAX_CS_PENDING and amdgpu_sched_jobs drm/amdgpu: change default sched jobs to 32 drm/amdgpu: restrict the sched jobs number to power of two Daniel Vetter (2): drm/amdgpu: Use unlocked gem unreferencing drm/radeon: Use unlocked gem unreferencing David Rokhvarg (2): drm/amd/powerplay: Add PPLib debug print macro. drm/amdgpu/powerplay: Program a calculated value as Deep Sleep clock. Eric Huang (19): drm/amd/powerplay: add/update headers for Fiji SMU and DPM drm/amd/powerplay: update atomctrl for fiji drm/amd/powerplay: add Fiji SMU support. drm/amd/powerplay: add Fiji DPM support. drm/amd/amdgpu: enable powerplay and smc firmware loading for Fiji. drm/amd/amdgpu: add gfx clock gating support for Fiji. drm/amd/amdgpu: add gmc clock gating support for Fiji. drm/amdgpu: add sdma clock gating support for Fiji. drm/amd/powerplay: add parts of system clock gating support for Fiji. (v2) drm/amd/powerplay: enable clock gating for Fiji. drm/amd/powerplay: add multimedia power gating support for Fiji. drm/amd/amdgpu: add uvd6.0 clock gating support. (v2) drm/amd/amdgpu: add vce3.0 clock gating support. (v2) drm/amd/amdgpu: enable uvd&vce clock gating for Fiji. drm/amd/powerplay: add display configeration changed function in hwmgr for Fiji. drm/amd/powerplay: Add thermal protection support for Fiji. drm/amd/powerplay: Fix a b
[Bug 92229] [APITRACE] SOMA have serious graphical errors
https://bugs.freedesktop.org/show_bug.cgi?id=92229 --- Comment #9 from Alberto Salvia Novella --- I can test it myself because I have returned the game (for a while ;) -- 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/20151222/46c52f8c/attachment.html>
[PATCH v7 4/4] MAINTAINERS: Add Liviu Dudau as maintainer for ARM HDLCD driver.
Update MAINTAINERS file for HDLCD driver. Cc: Greg KH Cc: Andrew Morton Cc: Mauro Carvalho Chehab Cc: David S. Miller Signed-off-by: Liviu Dudau --- MAINTAINERS | 6 ++ 1 file changed, 6 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 9a68ea9..050bbf2 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -820,6 +820,12 @@ S: Maintained F: drivers/net/arcnet/ F: include/uapi/linux/if_arcnet.h +ARM HDLCD DRM DRIVER +M: Liviu Dudau +S: Supported +F: drivers/gpu/drm/arm/ +F: Documentation/devicetree/bindings/display/arm,hdlcd.txt + ARM MFM AND FLOPPY DRIVERS M: Ian Molton S: Maintained -- 2.6.4
[PATCH v7 3/4] arm64: Juno: Add HDLCD support to the Juno boards.
ARM's Juno board has two HDLCD controllers, each linked to an NXP
TDA19988 HDMI transmitter that provides output encoding. Add them
to the device tree.
Signed-off-by: Liviu Dudau
Acked-by: Sudeep Holla
---
arch/arm64/boot/dts/arm/juno-base.dtsi | 46 +++---
1 file changed, 42 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/arm/juno-base.dtsi
b/arch/arm64/boot/dts/arm/juno-base.dtsi
index dd5158e..8ee094a 100644
--- a/arch/arm64/boot/dts/arm/juno-base.dtsi
+++ b/arch/arm64/boot/dts/arm/juno-base.dtsi
@@ -92,8 +92,8 @@
scpi_clk: scpi_clocks at 3 {
compatible = "arm,scpi-variable-clocks";
#clock-cells = <1>;
- clock-indices = <3>, <4>;
- clock-output-names = "pxlclk0", "pxlclk1";
+ clock-indices = <3>;
+ clock-output-names = "pxlclk";
};
};
@@ -123,6 +123,34 @@
clock-names = "apb_pclk";
};
+ hdlcd at 7ff5 {
+ compatible = "arm,hdlcd";
+ reg = <0 0x7ff5 0 0x1000>;
+ interrupts = ;
+ clocks = <&scpi_clk 3>;
+ clock-names = "pxlclk";
+
+ port {
+ hdlcd1_output: endpoint at 0 {
+ remote-endpoint = <&tda998x_1_input>;
+ };
+ };
+ };
+
+ hdlcd at 7ff6 {
+ compatible = "arm,hdlcd";
+ reg = <0 0x7ff6 0 0x1000>;
+ interrupts = ;
+ clocks = <&scpi_clk 3>;
+ clock-names = "pxlclk";
+
+ port {
+ hdlcd0_output: endpoint at 0 {
+ remote-endpoint = <&tda998x_0_input>;
+ };
+ };
+ };
+
soc_uart0: uart at 7ff8 {
compatible = "arm,pl011", "arm,primecell";
reg = <0x0 0x7ff8 0x0 0x1000>;
@@ -141,14 +169,24 @@
i2c-sda-hold-time-ns = <500>;
clocks = <&soc_smc50mhz>;
- dvi0: dvi-transmitter at 70 {
+ hdmi-transmitter at 70 {
compatible = "nxp,tda998x";
reg = <0x70>;
+ port {
+ tda998x_0_input: endpoint at 0 {
+ remote-endpoint = <&hdlcd0_output>;
+ };
+ };
};
- dvi1: dvi-transmitter at 71 {
+ hdmi-transmitter at 71 {
compatible = "nxp,tda998x";
reg = <0x71>;
+ port {
+ tda998x_1_input: endpoint at 0 {
+ remote-endpoint = <&hdlcd1_output>;
+ };
+ };
};
};
--
2.6.4
[PATCH v7 2/4] drm: Add support for ARM's HDLCD controller.
The HDLCD controller is a display controller that supports resolutions
up to 4096x4096 pixels. It is present on various development boards
produced by ARM Ltd and emulated by the latest Fast Models from the
company.
Cc: David Airlie
Cc: Robin Murphy
Signed-off-by: Liviu Dudau
Acked-by: Daniel Vetter
---
drivers/gpu/drm/Kconfig | 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/arm/Kconfig | 29 ++
drivers/gpu/drm/arm/Makefile | 2 +
drivers/gpu/drm/arm/hdlcd_crtc.c | 327 ++
drivers/gpu/drm/arm/hdlcd_drv.c | 567 +++
drivers/gpu/drm/arm/hdlcd_drv.h | 42 +++
drivers/gpu/drm/arm/hdlcd_regs.h | 87 ++
8 files changed, 1057 insertions(+)
create mode 100644 drivers/gpu/drm/arm/Kconfig
create mode 100644 drivers/gpu/drm/arm/Makefile
create mode 100644 drivers/gpu/drm/arm/hdlcd_crtc.c
create mode 100644 drivers/gpu/drm/arm/hdlcd_drv.c
create mode 100644 drivers/gpu/drm/arm/hdlcd_drv.h
create mode 100644 drivers/gpu/drm/arm/hdlcd_regs.h
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index b02ac62..6cb9df0 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -106,6 +106,8 @@ config DRM_TDFX
Choose this option if you have a 3dfx Banshee or Voodoo3 (or later),
graphics card. If M is selected, the module will be called tdfx.
+source "drivers/gpu/drm/arm/Kconfig"
+
config DRM_R128
tristate "ATI Rage 128"
depends on DRM && PCI
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index f858aa2..81bd95c 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -35,6 +35,7 @@ CFLAGS_drm_trace_points.o := -I$(src)
obj-$(CONFIG_DRM) += drm.o
obj-$(CONFIG_DRM_MIPI_DSI) += drm_mipi_dsi.o
+obj-$(CONFIG_DRM_ARM) += arm/
obj-$(CONFIG_DRM_TTM) += ttm/
obj-$(CONFIG_DRM_TDFX) += tdfx/
obj-$(CONFIG_DRM_R128) += r128/
diff --git a/drivers/gpu/drm/arm/Kconfig b/drivers/gpu/drm/arm/Kconfig
new file mode 100644
index 000..5e8c8a8
--- /dev/null
+++ b/drivers/gpu/drm/arm/Kconfig
@@ -0,0 +1,29 @@
+config DRM_ARM
+ bool "ARM Ltd. drivers"
+ depends on DRM && OF && (ARM || ARM64)
+ select DRM_KMS_HELPER
+ help
+ Choose this option to select drivers for ARM's devices
+
+config DRM_HDLCD
+ tristate "ARM HDLCD"
+ depends on DRM_ARM
+ depends on COMMON_CLK
+ select COMMON_CLK_SCPI
+ select DMA_CMA
+ select DRM_KMS_CMA_HELPER
+ select DRM_GEM_CMA_HELPER
+ help
+ Choose this option if you have an ARM High Definition Colour LCD
+ controller.
+
+ If M is selected the module will be called hdlcd.
+
+config DRM_HDLCD_SHOW_UNDERRUN
+ bool "Show underrun conditions"
+ depends on DRM_HDLCD
+ default n
+ help
+ Enable this option to show in red colour the pixels that the
+ HDLCD device did not fetch from framebuffer due to underrun
+ conditions.
diff --git a/drivers/gpu/drm/arm/Makefile b/drivers/gpu/drm/arm/Makefile
new file mode 100644
index 000..89dcb7b
--- /dev/null
+++ b/drivers/gpu/drm/arm/Makefile
@@ -0,0 +1,2 @@
+hdlcd-y := hdlcd_drv.o hdlcd_crtc.o
+obj-$(CONFIG_DRM_HDLCD)+= hdlcd.o
diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
new file mode 100644
index 000..fef1b04
--- /dev/null
+++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
@@ -0,0 +1,327 @@
+/*
+ * Copyright (C) 2013-2015 ARM Limited
+ * Author: Liviu Dudau
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file COPYING in the main directory of this archive
+ * for more details.
+ *
+ * Implementation of a CRTC class for the HDLCD driver.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "hdlcd_drv.h"
+#include "hdlcd_regs.h"
+
+/*
+ * The HDLCD controller is a dumb RGB streamer that gets connected to
+ * a single HDMI transmitter or in the case of the ARM Models it gets
+ * emulated by the software that does the actual rendering.
+ *
+ */
+
+static const struct drm_crtc_funcs hdlcd_crtc_funcs = {
+ .destroy = drm_crtc_cleanup,
+ .set_config = drm_atomic_helper_set_config,
+ .page_flip = drm_atomic_helper_page_flip,
+ .reset = drm_atomic_helper_crtc_reset,
+ .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
+ .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
+};
+
+static struct simplefb_format supported_formats[] = SIMPLEFB_FORMATS;
+
+/*
+ * Setup the HDLCD registers for decoding the pixels out of the framebuffer
+ */
+static int hdlcd_set_pxl_fmt(struct drm_crtc *crtc)
+{
+ unsigned int btpp;
+ struct hdlcd_drm_private *hdlcd = crtc_to_hdlcd_priv(crtc);
+ uint32_t pixel_format;
+ struct simplefb_format *format = NULL;
+
[PATCH v7 1/4] drm: arm: Add DT bindings documentation for HDLCD driver.
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Signed-off-by: Liviu Dudau
Acked-by: Rob Herring
---
.../devicetree/bindings/display/arm,hdlcd.txt | 79 ++
1 file changed, 79 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/arm,hdlcd.txt
diff --git a/Documentation/devicetree/bindings/display/arm,hdlcd.txt
b/Documentation/devicetree/bindings/display/arm,hdlcd.txt
new file mode 100644
index 000..78bc242
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/arm,hdlcd.txt
@@ -0,0 +1,79 @@
+ARM HDLCD
+
+This is a display controller found on several development platforms produced
+by ARM Ltd and in more modern of its' Fast Models. The HDLCD is an RGB
+streamer that reads the data from a framebuffer and sends it to a single
+digital encoder (DVI or HDMI).
+
+Required properties:
+ - compatible: "arm,hdlcd"
+ - reg: Physical base address and length of the controller's registers.
+ - interrupts: One interrupt used by the display controller to notify the
+interrupt controller when any of the interrupt sources programmed in
+the interrupt mask register have activated.
+ - clocks: A list of phandle + clock-specifier pairs, one for each
+entry in 'clock-names'.
+ - clock-names: A list of clock names. For HDLCD it should contain:
+ - "pxlclk" for the clock feeding the output PLL of the controller.
+
+Required sub-nodes:
+ - port: The HDLCD connection to an encoder chip. The connection is modeled
+using the OF graph bindings specified in
+Documentation/devicetree/bindings/graph.txt.
+
+Optional properties:
+ - memory-region: phandle to a node describing memory (see
+Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt) to
be
+used for the framebuffer; if not present, the framebuffer may be located
+anywhere in memory.
+
+
+Example:
+
+/ {
+ ...
+
+ hdlcd at 2b00 {
+ compatible = "arm,hdlcd";
+ reg = <0 0x2b00 0 0x1000>;
+ interrupts = ;
+ clocks = <&oscclk5>;
+ clock-names = "pxlclk";
+ port {
+ hdlcd_output: endpoint at 0 {
+ remote-endpoint = <&hdmi_enc_input>;
+ };
+ };
+ };
+
+ /* HDMI encoder on I2C bus */
+ i2c at 7ffa {
+
+ hdmi-transmitter at 70 {
+ compatible = ".";
+ reg = <0x70>;
+ port at 0 {
+ hdmi_enc_input: endpoint {
+ remote-endpoint = <&hdlcd_output>;
+ };
+
+ hdmi_enc_output: endpoint {
+ remote-endpoint = <&hdmi_1_port>;
+ };
+ };
+ };
+
+ };
+
+ hdmi1: connector at 1 {
+ compatible = "hdmi-connector";
+ type = "a";
+ port {
+ hdmi_1_port: endpoint {
+ remote-endpoint = <&hdmi_enc_output>;
+ };
+ };
+ };
+
+ ...
+};
--
2.6.4
[PATCH v7 0/4] drm: Add support for the ARM HDLCD display controller
This series adds support for ARM's HDLCD display controller found in Juno and ARM TC2 Coretile. The HDLCD outputs an RGB stream that feeds into a single digital encoder (DVI or HDMI). A few days after sending the v6 series and a timid pull request I've discovered that the changes piled in linux-next will break my driver, so this is a refresh to make it compile on top of Dave Airlie's drm-next. There are still a few dependencies that haven't made it in linux-next that will hamper testing of the series, so I've pushed the full set into [1]. Those of you lucky enough to have a Juno board can give it a spin. Only the Juno functionality has been tested as the TC2 Coretile require a working SiI9022 driver for VExpress that is not subject of this patchset. I haven't got any answer from Dave on my pull request, so I'm guessing he is not ready to take it. I would appreciate some feedback on this version if he thinks there are still issues to address. Changelog: v7: Updated the use of component API to match the updates queued by Russell King, as well as all the DRM changes that happened since 4.3-rc3 (remove drm_dev_set_unique() that is now done in drm_dev_alloc(), add the missing parameter in drm_universal_plane_init() and drm_crtc_init_with_planes()). This should compile cleanly on top of drm-next as of 22nd of December. v6: Addressed the style nits pointed by Robin Murphy and fixed the use of default color to highlight underrun errors. Also modified MAINTAINERS file to change the status to Supported for HDLCD. [2] v5: Queue the pending vblank events sent by userspace using a list instead of keeping the last event seen. Suggested by Daniel Stone . [3] v4: Remove some debugging code that could return an error on a critical path and updated the check for valid format in hdlcd_set_pxl_fmt() to only WARN() if an invalid format found (unlikely case). Added the ACKs received. [4] v3: Changed the driver to use the memory-region phandle for bespoke framebuffers. [5] v2: Added support for atomic modeset [6] v1: Original DRM submission [7] [1] git://linux-arm.org/linux-ld testing/hdlcd [2] http://lists.freedesktop.org/archives/dri-devel/2015-December/096872.html [3] http://lists.freedesktop.org/archives/dri-devel/2015-December/096432.html [4] http://lists.freedesktop.org/archives/dri-devel/2015-December/095990.html [5] http://lists.freedesktop.org/archives/dri-devel/2015-December/095877.html [6] http://lists.freedesktop.org/archives/dri-devel/2015-November/094177.html [7] http://lists.freedesktop.org/archives/dri-devel/2015-August/087685.html Best regards, Liviu Liviu Dudau (4): drm: arm: Add DT bindings documentation for HDLCD driver. drm: Add support for ARM's HDLCD controller. arm64: Juno: Add HDLCD support to the Juno boards. MAINTAINERS: Add Liviu Dudau as maintainer for ARM HDLCD driver. .../devicetree/bindings/display/arm,hdlcd.txt | 79 +++ MAINTAINERS| 6 + arch/arm64/boot/dts/arm/juno-base.dtsi | 46 +- drivers/gpu/drm/Kconfig| 2 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/arm/Kconfig| 29 ++ drivers/gpu/drm/arm/Makefile | 2 + drivers/gpu/drm/arm/hdlcd_crtc.c | 327 drivers/gpu/drm/arm/hdlcd_drv.c| 567 + drivers/gpu/drm/arm/hdlcd_drv.h| 42 ++ drivers/gpu/drm/arm/hdlcd_regs.h | 87 11 files changed, 1184 insertions(+), 4 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/arm,hdlcd.txt create mode 100644 drivers/gpu/drm/arm/Kconfig create mode 100644 drivers/gpu/drm/arm/Makefile create mode 100644 drivers/gpu/drm/arm/hdlcd_crtc.c create mode 100644 drivers/gpu/drm/arm/hdlcd_drv.c create mode 100644 drivers/gpu/drm/arm/hdlcd_drv.h create mode 100644 drivers/gpu/drm/arm/hdlcd_regs.h -- 2.6.4
[PATCH v2 0/2] Improve drm_of_component_probe() and move rockchip to use it
On Fri, Nov 20, 2015 at 02:22:03PM +, Liviu Dudau wrote: > Hello, > > This is v2 of the patchset trying to make drm_of_component_probe() cope with > finding > both local crtc ports and remote encoder ones. Heiko Stübner was nice enough > to test > an earlier version that was patched following Russell's suggestions on > rk3288, but > I haven't seen any reports from iMX or Armada users. > > Changelog: > v2: Updated the drm_of_component_probe() comment to explain why the > reference count > is not dropped. Fixed the compare_port() function for rockchip as > described by > Russell. > v1: Original submission. > http://lists.freedesktop.org/archives/dri-devel/2015-November/094546.html Gentle ping, this has now been tested by Rockchip people and fixes the earlier version that had to be reverted in mainline. Can it be included in the -next somewhere? Many thanks, Liviu > > Liviu Dudau (2): > drm: Improve drm_of_component_probe() to correctly handle ports and remote > ports. > drm/rockchip: Convert the probe function to the generic > drm_of_component_probe() > > drivers/gpu/drm/armada/armada_drv.c | 3 +- > drivers/gpu/drm/drm_of.c| 19 -- > drivers/gpu/drm/imx/imx-drm-core.c | 3 +- > drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 98 > ++--- > include/drm/drm_of.h| 6 +- > 5 files changed, 40 insertions(+), 89 deletions(-) > > -- > 2.6.2 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ã)_/¯
[PATCH v4 0/4] drm: Add support for the ARM HDLCD display controller
On Thu, Dec 03, 2015 at 04:56:07PM +, Russell King - ARM Linux wrote: > On Thu, Dec 03, 2015 at 10:40:45AM +, Liviu Dudau wrote: > > This series depends on Sudeep Holla's SCPI driver (now in mainline) and on > > the tda998x patches that have been queued on Russell's patch system here > > [1]. > > Now merged into my tree. Hi Russell, Can I ask about the faith of the patches that I have queued here: http://www.arm.linux.org.uk/developer/patches/search.php?uid=2895 I can't find them in any of your public git branches (or I failed at git 101). Best regards, Liviu > > Can I ask a fairly obvious question... > > > drivers/gpu/drm/Kconfig| 2 + > > drivers/gpu/drm/Makefile | 1 + > > drivers/gpu/drm/arm/Kconfig| 29 ++ > > drivers/gpu/drm/arm/Makefile | 2 + > > drivers/gpu/drm/arm/hdlcd_crtc.c | 327 > > drivers/gpu/drm/arm/hdlcd_drv.c| 555 > > + > > drivers/gpu/drm/arm/hdlcd_drv.h| 42 ++ > > drivers/gpu/drm/arm/hdlcd_regs.h | 87 > > Why is the subdirectory called "arm" and not "hdlcd" ? > > ARM Ltd have more than one display controller (they have the AMBA PL110 > and PL111 in addition to this), and (afaics) this doesn't drive these. > HDLCD probably won't be the last display hardware which ARM Ltd comes > out with either. > > So, I think naming the subdirectory after the vendor is probably a > mistake. > > -- > FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up > according to speedtest.net. > -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ã)_/¯
[GIT PULL] TDA998x I2C driver development updates
David, Please incorporate the latest TDA998x I2C driver development updates, which can be found at: git://ftp.arm.linux.org.uk/~rmk/linux-arm.git drm-tda998x-devel with SHA1 9736e988d32807d5a186c722928a97f37346fec8. These changes from Liviu add support for atomic mode setting, add the TMDS clock limitation according to the device, and ensure that we correctly clean up in the unbind function. This will update the following files: drivers/gpu/drm/i2c/tda998x_drv.c | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) through these changes: Liviu Dudau (ARM) (3): drm/i2c: tda998x: unregister the connector in the unbind function drm/i2c: tda998x: increase the supported dotclock frequency to 165MHz for TDA19988 drm/i2c: tda998x: Add support for atomic modesetting Many thanks.
[GIT PULL] Armada DRM development updates development updates
David, Please incorporate the latest Armada DRM development updates development updates, which can be found at: git://ftp.arm.linux.org.uk/~rmk/linux-arm.git drm-armada-devel with SHA1 0b8ebeacf5ef43a467c7ec5400ccc1ffc3fbdfba. These are the patches from Daniel Vetter, getting rid of struct_mutex from the Armada DRM driver. This will update the following files: drivers/gpu/drm/armada/armada_crtc.c| 9 ++--- drivers/gpu/drm/armada/armada_debugfs.c | 4 ++-- drivers/gpu/drm/armada/armada_drm.h | 3 ++- drivers/gpu/drm/armada/armada_drv.c | 1 + drivers/gpu/drm/armada/armada_gem.c | 29 +++-- 5 files changed, 22 insertions(+), 24 deletions(-) through these changes: Daniel Vetter (5): drm/armada: use unlocked gem unreferencing drm/armada: plug leak in dumb_map_offset drm/armada: don't grab dev->struct_mutex for in mmap offset ioctl drm/armada: drop struct_mutex from cursor paths drm/armada: use a private mutex to protect priv->linear Many thanks.
[Intel-gfx] [PULL] drm-intel-next
On 22/12/15 14:31, Chris Wilson wrote: > On Tue, Dec 22, 2015 at 03:05:14PM +0100, Daniel Vetter wrote: >> On Tue, Dec 22, 2015 at 11:37:18AM +0100, Daniel Vetter wrote: >>> Hi Dave, >>> >>> Final 4.5 feature pull for drm/i915! >>> >>> drm-intel-next-2015-12-18: >>> - fix atomic watermark recomputation logic (Maarten) >>> - modeset sequence fixes for LPT (Ville) >>> - more kbl enabling&prep work (Rodrigo, Wayne) >>> - first bits for mst audio >>> - page dirty tracking fixes from Dave Gordon >>> - new get_eld hook from Takashi, also included in the sound tree >>> - fixup cursor handling when placed at address 0 (Ville) >>> - refactor VBT parsing code (Jani) >>> - rpm wakelock debug infrastructure ( Imre) >>> - fbdev is pinned again (Chris) >>> - tune the busywait logic to avoid wasting cpu cycles (Chris) >>> >>> Two small caveats as a heads up: >>> - the runtime pm wakelock debug stuff catches a few bugs. rpm is disabled >>>by default, but lots enable it (e.g. powertop does), and we iirc have >>>fixes floating for most. If we can't squeeze them all in for 4.5 because >>>too big or late we can just tune down the dmesg noise since the >>>uncovered bugs are all as old as rpm support. >>> - softpin is still thrashing around: Chris complains that the ABI can't be >>>used of anything else than beignet, but I think that's ok since easy to >>>remedy and softpin was done primarily for buffered svm opencl mode. And >>>then there's some confusion around canonical 48bit addresses that I >>>don't fully understand myself. I expect Tvrtko to handle this before >>>your merge window pull goes out. >> >> So just with Tvrtko and the canonical address is something >> userspace/beignet will never hit under legitimate usage. So it's just a >> bit of closing a corner-case, and the patch+testcase is ready except for >> bit of final polish and unfortunately people going on holidays already. > > Nope, it was reported in the wild and it imposes an ABI constraint on > the execobject.offsets. Plan is for "drm/i915: Avoid writing relocs with addresses in non-canonical form" to be ready as a fixup either before, or slightly after rc1. As long as we hit that, slight wobbling in the ABI between two release candidates shouldn't be an issue. That is my understanding at least. Especially given how the announced user plans to pass in user pointer allocated addresses which will already be in canonical format. Regards, Tvrtko
[PULL] drm-intel-next
On Tue, Dec 22, 2015 at 11:37:18AM +0100, Daniel Vetter wrote:
> Hi Dave,
>
> Final 4.5 feature pull for drm/i915!
>
> drm-intel-next-2015-12-18:
> - fix atomic watermark recomputation logic (Maarten)
> - modeset sequence fixes for LPT (Ville)
> - more kbl enabling&prep work (Rodrigo, Wayne)
> - first bits for mst audio
> - page dirty tracking fixes from Dave Gordon
> - new get_eld hook from Takashi, also included in the sound tree
> - fixup cursor handling when placed at address 0 (Ville)
> - refactor VBT parsing code (Jani)
> - rpm wakelock debug infrastructure ( Imre)
> - fbdev is pinned again (Chris)
> - tune the busywait logic to avoid wasting cpu cycles (Chris)
>
> Two small caveats as a heads up:
> - the runtime pm wakelock debug stuff catches a few bugs. rpm is disabled
> by default, but lots enable it (e.g. powertop does), and we iirc have
> fixes floating for most. If we can't squeeze them all in for 4.5 because
> too big or late we can just tune down the dmesg noise since the
> uncovered bugs are all as old as rpm support.
> - softpin is still thrashing around: Chris complains that the ABI can't be
> used of anything else than beignet, but I think that's ok since easy to
> remedy and softpin was done primarily for buffered svm opencl mode. And
> then there's some confusion around canonical 48bit addresses that I
> don't fully understand myself. I expect Tvrtko to handle this before
> your merge window pull goes out.
So just with Tvrtko and the canonical address is something
userspace/beignet will never hit under legitimate usage. So it's just a
bit of closing a corner-case, and the patch+testcase is ready except for
bit of final polish and unfortunately people going on holidays already.
Summary: I think that part is ok too, and we should have the final bits as
soon as folks return next year.
Cheers, Daniel
>
> Looking at -nightly I don't see a conflict with drm-next (but there's some
> with Linus' tree).
>
> I'll also send out another drm-misc before I go on vacations, there's 1-2
> patches in there after the last pull.
>
> Cheers, Daniel
>
>
> The following changes since commit e876b41ab074561d65f213bf5e0fc68cf5bc7380:
>
> Back merge tag 'v4.4-rc4' into drm-next (2015-12-08 11:04:26 +1000)
>
> are available in the git repository at:
>
> git://anongit.freedesktop.org/drm-intel tags/drm-intel-next-2015-12-18
>
> for you to fetch changes up to 7447a2b221cd4df3960e82478a4ee29312589611:
>
> drm/i915: Update DRIVER_DATE to 20151218 (2015-12-18 20:26:17 +0100)
>
>
> - fix atomic watermark recomputation logic (Maarten)
> - modeset sequence fixes for LPT (Ville)
> - more kbl enabling&prep work (Rodrigo, Wayne)
> - first bits for mst audio
> - page dirty tracking fixes from Dave Gordon
> - new get_eld hook from Takashi, also included in the sound tree
> - fixup cursor handling when placed at address 0 (Ville)
> - refactor VBT parsing code (Jani)
> - rpm wakelock debug infrastructure ( Imre)
> - fbdev is pinned again (Chris)
> - tune the busywait logic to avoid wasting cpu cycles (Chris)
>
>
> Chris Wilson (6):
> drm/i915: Add soft-pinning API for execbuffer
> drm/i915: Set the map-and-fenceable flag for preallocated objects
> drm/i915: Pin the ifbdev for the info->system_base GGTT mmapping
> drm/i915: Break busywaiting for requests on pending signals
> drm/i915: Limit the busy wait on requests to 5us not 10ms!
> drm/i915: Only spin whilst waiting on the current request
>
> Daniel Vetter (3):
> Merge tag 'drm-i915-get-eld' of tiwai/sound into drm-intel-next-queued
> drm/i915: mdelay(10) considered harmful
> drm/i915: Update DRIVER_DATE to 20151218
>
> Dave Gordon (4):
> drm/i915: eliminate 'temp' in gen8_for_each_{pdd, pdpe, pml4e} macros
> drm/i915: intel_ring_initialized() must be simple and inline
> drm/i915: mark GEM object pages dirty when mapped & written by the CPU
> drm/i915: mark a newly-created GEM object dirty when filled with data
>
> Deepak M (3):
> drm/i915: add VBT address and size fields to ASLE mailbox struct
> drm/i915: dual link pipe selection for bxt
> drm/i915: Add Intel opregion mailbox 5 structure
>
> Imre Deak (12):
> drm/i915: vlv: clamp minimum RPS frequency to what Punit allows
> drm/i915: clarify comment about mandatory RPM put/get during driver
> load/unload
> drm/i915: refactor RPM disabling due to RC6 being disabled
> drm/i915: get a permanent RPM reference on platforms w/o RPM support
> drm/i915: remove HAS_RUNTIME_PM check from RPM get/put/assert helpers
> drm/i915: add assert_rpm_wakelock_held helper
> drm/i915: use assert_rpm_wakelock_held instead of opencoding it
> drm/i915: add support for checking if we hold an RPM reference
> drm/i915: check tha
[PATCH v6.2 4/6] drm: rockchip: Support Synopsys DW MIPI DSI
Add support for Synopsys DesignWare MIPI DSI controller which is embedded in the rk3288 SoCs. Signed-off-by: Chris Zhong --- Changes in v6.2: - Remove the atomic feature check (Mark Yao) Changes in v6.1: - Add atomic API support (Heiko Stübne) Changes in v6: - Do not use bridge driver (Thierry Reding) - Optimization the phy init sequence Changes in v5: None Changes in v4: None Changes in v3: None drivers/gpu/drm/rockchip/Kconfig| 10 + drivers/gpu/drm/rockchip/Makefile |1 + drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 1196 +++ drivers/gpu/drm/rockchip/rockchip_drm_vop.c |3 + 4 files changed, 1210 insertions(+) create mode 100644 drivers/gpu/drm/rockchip/dw-mipi-dsi.c diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig index 686cb49..1db1b86 100644 --- a/drivers/gpu/drm/rockchip/Kconfig +++ b/drivers/gpu/drm/rockchip/Kconfig @@ -34,3 +34,13 @@ config ROCKCHIP_ANALOGIX_DP This selects support for Rockchip SoC specific extensions for the Analogix Core DP driver. If you want to enable DP on RK3288 based SoC, you should selet this option. + +config ROCKCHIP_DW_MIPI_DSI + bool "Rockchip specific extensions for Synopsys DW MIPI DSI" + depends on DRM_ROCKCHIP + select DRM_MIPI_DSI + help +This selects support for Rockchip SoC specific extensions +for the Synopsys DesignWare HDMI driver. If you want to +enable MIPI DSI on RK3288 based SoC, you should selet this +option. diff --git a/drivers/gpu/drm/rockchip/Makefile b/drivers/gpu/drm/rockchip/Makefile index 8ad01fb..c5c2d61 100644 --- a/drivers/gpu/drm/rockchip/Makefile +++ b/drivers/gpu/drm/rockchip/Makefile @@ -7,5 +7,6 @@ rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o rockchip_drm_fbdev.o \ obj-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o obj-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o +obj-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o rockchip_drm_vop.o diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c new file mode 100644 index 000..1fe631e --- /dev/null +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c @@ -0,0 +1,1196 @@ +/* + * Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "rockchip_drm_drv.h" +#include "rockchip_drm_vop.h" + +#define DRIVER_NAME"dw-mipi-dsi" + +#define GRF_SOC_CON60x025c +#define DSI0_SEL_VOP_LIT(1 << 6) +#define DSI1_SEL_VOP_LIT(1 << 9) + +#define DSI_VERSION0x00 +#define DSI_PWR_UP 0x04 +#define RESET 0 +#define POWERUPBIT(0) + +#define DSI_CLKMGR_CFG 0x08 +#define TO_CLK_DIVIDSION(div) (((div) & 0xff) << 8) +#define TX_ESC_CLK_DIVIDSION(div) (((div) & 0xff) << 0) + +#define DSI_DPI_VCID 0x0c +#define DPI_VID(vid) (((vid) & 0x3) << 0) + +#define DSI_DPI_COLOR_CODING 0x10 +#define EN18_LOOSELY BIT(8) +#define DPI_COLOR_CODING_16BIT_1 0x0 +#define DPI_COLOR_CODING_16BIT_2 0x1 +#define DPI_COLOR_CODING_16BIT_3 0x2 +#define DPI_COLOR_CODING_18BIT_1 0x3 +#define DPI_COLOR_CODING_18BIT_2 0x4 +#define DPI_COLOR_CODING_24BIT 0x5 + +#define DSI_DPI_CFG_POL0x14 +#define COLORM_ACTIVE_LOW BIT(4) +#define SHUTD_ACTIVE_LOW BIT(3) +#define HSYNC_ACTIVE_LOW BIT(2) +#define VSYNC_ACTIVE_LOW BIT(1) +#define DATAEN_ACTIVE_LOW BIT(0) + +#define DSI_DPI_LP_CMD_TIM 0x18 +#define OUTVACT_LPCMD_TIME(p) (((p) & 0xff) << 16) +#define INVACT_LPCMD_TIME(p) ((p) & 0xff) + +#define DSI_DBI_CFG0x20 +#define DSI_DBI_CMDSIZE0x28 + +#define DSI_PCKHDL_CFG 0x2c +#define EN_CRC_RX BIT(4) +#define EN_ECC_RX BIT(3) +#define EN_BTA BIT(2) +#define EN_EOTP_RX BIT(1) +#define EN_EOTP_TX BIT(0) + +#define DSI_MODE_CFG 0x34 +#define ENABLE_VIDEO_MODE 0 +#define ENABLE_CMD_MODEBIT(0) + +#define DSI_VID_MODE_CFG 0x38 +#define FRAME_BTA_ACK BIT(14) +#define ENABLE_LOW_POWER
[Intel-gfx] [PULL] drm-intel-next
On Tue, Dec 22, 2015 at 03:05:14PM +0100, Daniel Vetter wrote: > On Tue, Dec 22, 2015 at 11:37:18AM +0100, Daniel Vetter wrote: > > Hi Dave, > > > > Final 4.5 feature pull for drm/i915! > > > > drm-intel-next-2015-12-18: > > - fix atomic watermark recomputation logic (Maarten) > > - modeset sequence fixes for LPT (Ville) > > - more kbl enabling&prep work (Rodrigo, Wayne) > > - first bits for mst audio > > - page dirty tracking fixes from Dave Gordon > > - new get_eld hook from Takashi, also included in the sound tree > > - fixup cursor handling when placed at address 0 (Ville) > > - refactor VBT parsing code (Jani) > > - rpm wakelock debug infrastructure ( Imre) > > - fbdev is pinned again (Chris) > > - tune the busywait logic to avoid wasting cpu cycles (Chris) > > > > Two small caveats as a heads up: > > - the runtime pm wakelock debug stuff catches a few bugs. rpm is disabled > > by default, but lots enable it (e.g. powertop does), and we iirc have > > fixes floating for most. If we can't squeeze them all in for 4.5 because > > too big or late we can just tune down the dmesg noise since the > > uncovered bugs are all as old as rpm support. > > - softpin is still thrashing around: Chris complains that the ABI can't be > > used of anything else than beignet, but I think that's ok since easy to > > remedy and softpin was done primarily for buffered svm opencl mode. And > > then there's some confusion around canonical 48bit addresses that I > > don't fully understand myself. I expect Tvrtko to handle this before > > your merge window pull goes out. > > So just with Tvrtko and the canonical address is something > userspace/beignet will never hit under legitimate usage. So it's just a > bit of closing a corner-case, and the patch+testcase is ready except for > bit of final polish and unfortunately people going on holidays already. Nope, it was reported in the wild and it imposes an ABI constraint on the execobject.offsets. -Chris -- Chris Wilson, Intel Open Source Technology Centre
[Bug 93475] Saints Row IV causes GPU lockup on Linux
https://bugs.freedesktop.org/show_bug.cgi?id=93475 Bug ID: 93475 Summary: Saints Row IV causes GPU lockup on Linux Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: DRM/Radeon Assignee: dri-devel at lists.freedesktop.org Reporter: holthuis.jan at googlemail.com When running Saints Row IV (the Linux version that was released yesterday), I'm getting GPU lockups on my AMD A6-3410MX APU (Radeon HD 6520G) when using mesa drivers (happens with 11.0.7 and 11.2.0-devel (git-d191066). Heres some dmesg output: http://hastebin.com/gaxemomefo.log My system: $ uname -a Linux jan-laptop 4.2.5-1-ARCH #1 SMP PREEMPT Tue Oct 27 08:13:28 CET 2015 x86_64 GNU/Linux $ glxinfo | grep string server glx vendor string: SGI server glx version string: 1.4 client glx vendor string: Mesa Project and SGI client glx version string: 1.4 OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD SUMO (DRM 2.43.0, LLVM 3.8.0) OpenGL core profile version string: 3.3 (Core Profile) Mesa 11.2.0-devel (git-d191066) OpenGL core profile shading language version string: 3.30 OpenGL version string: 3.0 Mesa 11.2.0-devel (git-d191066) OpenGL shading language version string: 1.30 OpenGL ES profile version string: OpenGL ES 3.0 Mesa 11.2.0-devel (git-d191066) OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00 $ cat /proc/cpuinfo processor: 0 vendor_id: AuthenticAMD cpu family: 18 model: 1 model name: AMD A6-3410MX APU with Radeon(tm) HD Graphics stepping: 0 microcode: 0x327 cpu MHz: 1000.000 cache size: 1024 KB physical id: 0 siblings: 4 core id: 0 cpu cores: 4 apicid: 0 initial apicid: 0 fpu: yes fpu_exception: yes cpuid level: 6 wp: yes flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt arat cpb hw_pstate npt lbrv svm_lock nrip_save pausefilter vmmcall bugs: fxsave_leak sysret_ss_attrs bogomips: 3195.31 TLB size: 1536 4K pages clflush size: 64 cache_alignment: 64 address sizes: 40 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate cpb -- 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/20151222/4d7366bf/attachment-0001.html>
[Bug 80419] XCOM: Enemy Unknown Causes lockup
https://bugs.freedesktop.org/show_bug.cgi?id=80419 --- Comment #85 from Kamil Páral --- (In reply to Daniel Exner from comment #80) > Now I get (with radeonsi): > > glretrace game.x86_64.trace > apitrace: warning: caught signal 11 > 47062: error: caught an unhandled exception Great to see it does not crash just for me :-) (In reply to Michael Eagle from comment #82) > On Fedora 23 I'm using this copr: > https://copr.fedoraproject.org/coprs/griever/mesa-git/ Thanks, that helps a lot! (In reply to Daniel Exner from comment #83) > Managed to get some more infos about glretrace crash: Please note I uploaded a gdb backtrace to the apitrace bug mentioned in comment 73. Now that I tested latest mesa git (ea8c0b1, 2012-12-21), I can confirm apitrace still crashes, and I uploaded an updated gdb backtrace: https://github.com/apitrace/apitrace/files/69636/gdb.backtrace2.txt However, the question is whether that apitrace crash is related to the gpu hang we see in XCOM. It certainly makes debugging harder. -- 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/20151222/1edcbe78/attachment.html>
linux-next: manual merge of the drm-intel tree with Linus' tree
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/intel_pm.c
between commit:
344df9809f45 ("drm/i915/skl: Disable coarse power gating up until F0")
from Linus' tree and commit:
06e668ac91c9 ("drm/i915: Apply broader WaRsDisableCoarsePowerGating for guc
also")
from the drm-intel tree.
I fixed it up (I just used the latter version) and can carry the fix as
necessary (no action is required).
--
Cheers,
Stephen Rothwellsfr at canb.auug.org.au
[Bug 89780] Vertex drawing error on Civilization Beyond Earth
https://bugs.freedesktop.org/show_bug.cgi?id=89780 Peter Asplund changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution|--- |FIXED --- Comment #3 from Peter Asplund --- No, this was fixed sometime around 11.0 or LLVM 3.7. -- 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/20151222/83c49326/attachment.html>
[PULL] drm-intel-next
Hi Dave,
Final 4.5 feature pull for drm/i915!
drm-intel-next-2015-12-18:
- fix atomic watermark recomputation logic (Maarten)
- modeset sequence fixes for LPT (Ville)
- more kbl enabling&prep work (Rodrigo, Wayne)
- first bits for mst audio
- page dirty tracking fixes from Dave Gordon
- new get_eld hook from Takashi, also included in the sound tree
- fixup cursor handling when placed at address 0 (Ville)
- refactor VBT parsing code (Jani)
- rpm wakelock debug infrastructure ( Imre)
- fbdev is pinned again (Chris)
- tune the busywait logic to avoid wasting cpu cycles (Chris)
Two small caveats as a heads up:
- the runtime pm wakelock debug stuff catches a few bugs. rpm is disabled
by default, but lots enable it (e.g. powertop does), and we iirc have
fixes floating for most. If we can't squeeze them all in for 4.5 because
too big or late we can just tune down the dmesg noise since the
uncovered bugs are all as old as rpm support.
- softpin is still thrashing around: Chris complains that the ABI can't be
used of anything else than beignet, but I think that's ok since easy to
remedy and softpin was done primarily for buffered svm opencl mode. And
then there's some confusion around canonical 48bit addresses that I
don't fully understand myself. I expect Tvrtko to handle this before
your merge window pull goes out.
Looking at -nightly I don't see a conflict with drm-next (but there's some
with Linus' tree).
I'll also send out another drm-misc before I go on vacations, there's 1-2
patches in there after the last pull.
Cheers, Daniel
The following changes since commit e876b41ab074561d65f213bf5e0fc68cf5bc7380:
Back merge tag 'v4.4-rc4' into drm-next (2015-12-08 11:04:26 +1000)
are available in the git repository at:
git://anongit.freedesktop.org/drm-intel tags/drm-intel-next-2015-12-18
for you to fetch changes up to 7447a2b221cd4df3960e82478a4ee29312589611:
drm/i915: Update DRIVER_DATE to 20151218 (2015-12-18 20:26:17 +0100)
- fix atomic watermark recomputation logic (Maarten)
- modeset sequence fixes for LPT (Ville)
- more kbl enabling&prep work (Rodrigo, Wayne)
- first bits for mst audio
- page dirty tracking fixes from Dave Gordon
- new get_eld hook from Takashi, also included in the sound tree
- fixup cursor handling when placed at address 0 (Ville)
- refactor VBT parsing code (Jani)
- rpm wakelock debug infrastructure ( Imre)
- fbdev is pinned again (Chris)
- tune the busywait logic to avoid wasting cpu cycles (Chris)
Chris Wilson (6):
drm/i915: Add soft-pinning API for execbuffer
drm/i915: Set the map-and-fenceable flag for preallocated objects
drm/i915: Pin the ifbdev for the info->system_base GGTT mmapping
drm/i915: Break busywaiting for requests on pending signals
drm/i915: Limit the busy wait on requests to 5us not 10ms!
drm/i915: Only spin whilst waiting on the current request
Daniel Vetter (3):
Merge tag 'drm-i915-get-eld' of tiwai/sound into drm-intel-next-queued
drm/i915: mdelay(10) considered harmful
drm/i915: Update DRIVER_DATE to 20151218
Dave Gordon (4):
drm/i915: eliminate 'temp' in gen8_for_each_{pdd, pdpe, pml4e} macros
drm/i915: intel_ring_initialized() must be simple and inline
drm/i915: mark GEM object pages dirty when mapped & written by the CPU
drm/i915: mark a newly-created GEM object dirty when filled with data
Deepak M (3):
drm/i915: add VBT address and size fields to ASLE mailbox struct
drm/i915: dual link pipe selection for bxt
drm/i915: Add Intel opregion mailbox 5 structure
Imre Deak (12):
drm/i915: vlv: clamp minimum RPS frequency to what Punit allows
drm/i915: clarify comment about mandatory RPM put/get during driver
load/unload
drm/i915: refactor RPM disabling due to RC6 being disabled
drm/i915: get a permanent RPM reference on platforms w/o RPM support
drm/i915: remove HAS_RUNTIME_PM check from RPM get/put/assert helpers
drm/i915: add assert_rpm_wakelock_held helper
drm/i915: use assert_rpm_wakelock_held instead of opencoding it
drm/i915: add support for checking if we hold an RPM reference
drm/i915: check that we hold an RPM wakelock ref before we put it
drm/i915: add support for checking RPM atomic sections
drm/i915: check that we are in an RPM atomic section in GGTT PTE updaters
drm/i915: don't enable autosuspend on platforms without RPM support
Jani Nikula (16):
drm/i915: move "no VBT in opregion" quirk to intel_opregion_setup()
drm/i915/bios: have functions return vbt, not bdb, header pointer
drm/i915/bios: move debug logging about VBT source to intel_parse_bios()
drm/i915/bios: rename intel_parse_bios to intel_bios_init
drm/i915: refactor VBT validation
drm/i915/opregion: make VBT size limit more stric
[Bug 80419] XCOM: Enemy Unknown Causes lockup
https://bugs.freedesktop.org/show_bug.cgi?id=80419 --- Comment #84 from Daniel Exner --- Disabled DRI3 and the trace run through (without GPU crash) but glretrace crash: Wow, such stacktrace many interesting: Stack trace of thread 26634: #0 0x7fc683d6ce6e __memcpy_sse2_unaligned (libc.so.6) #1 0x7fc67f565f5f u_upload_data (radeonsi_dri.so) #2 0x7fc67f567c88 u_vbuf_draw_vbo (radeonsi_dri.so) #3 0x7fc67f3cce57 st_draw_vbo (radeonsi_dri.so) #4 0x7fc67f39dad4 vbo_validated_drawrangeelements (radeonsi_dri.so) #5 0x7fc67f39ddd4 vbo_exec_DrawRangeElementsBaseVertex (radeonsi_dri.so) #6 0x004fcaee _ZL37retrace_glDrawRangeElementsBaseVertexRN5trace4CallE (glretrace) #7 0x0043a4a5 _ZN7retrace8Retracer7retraceERN5trace4CallE (glretrace) #8 0x0042fb36 _ZN7retraceL11retraceCallEPN5trace4CallE (glretrace) #9 0x0043183f _ZN7retrace11RelayRunner6runLegEPN5trace4CallE (glretrace) #10 0x004317a8 _ZN7retrace11RelayRunner7runRaceEv (glretrace) #11 0x0042fc3a _ZN7retrace11RelayRunner12runnerThreadEPS0_ (glretrace) #12 0x00433eb2 _ZN2os6thread13CallbackParamIFvPN7retrace11RelayRunnerEES4_EclEv (glretrace) #13 0x00433631 _ZN2os6thread9_callbackINS0_13CallbackParamIFvPN7retrace11RelayRunnerEES5_PvS8_ (glretrace) #14 0x7fc68515e484 start_thread (libpthread.so.0) #15 0x7fc683dc4aed __clone (libc.so.6) Stack trace of thread 26629: #0 0x7fc68516405f pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0) #1 0x00430be1 _ZN2os18condition_variable4waitERNS_11unique_lockINS_5mutexEEE (glretrace) #2 0x00431749 _ZN7retrace11RelayRunner7runRaceEv (glretrace) #3 0x0042fead _ZN7retrace9RelayRace3runEv (glretrace) #4 0x00430073 _ZN7retraceL8mainLoopEv (glretrace) #5 0x00430957 main (glretrace) #6 0x7fc683cfc5e0 __libc_start_main (libc.so.6) #7 0x0042c5e9 _start (glretrace) Stack trace of thread 26630: #0 0x7fc68516405f pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0) #1 0x7fc67f83dba3 radeon_drm_cs_emit_ioctl (radeonsi_dri.so) #2 0x7fc67f83d3e7 impl_thrd_routine (radeonsi_dri.so) #3 0x7fc68515e484 start_thread (libpthread.so.0) #4 0x7fc683dc4aed __clone (libc.so.6) Stack trace of thread 26632: #0 0x7fc68516405f pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0) #1 0x00430be1 _ZN2os18condition_variable4waitERNS_11unique_lockINS_5mutexEEE (glretrace) #2 0x00431749 _ZN7retrace11RelayRunner7runRaceEv (glretrace) #3 0x0042fc3a _ZN7retrace11RelayRunner12runnerThreadEPS0_ (glretrace) #4 0x00433eb2 _ZN2os6thread13CallbackParamIFvPN7retrace11RelayRunnerEES4_EclEv (glretrace) #5 0x00433631 _ZN2os6thread9_callbackINS0_13CallbackParamIFvPN7retrace11RelayRunnerEES5_PvS8_ (glretrace) #6 0x7fc68515e484 start_thread (libpthread.so.0) #7 0x7fc683dc4aed __clone (libc.so.6) Stack trace of thread 26633: #0 0x7fc68516405f pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0) #1 0x00430be1 _ZN2os18condition_variable4waitERNS_11unique_lockINS_5mutexEEE (glretrace) #2 0x00431749 _ZN7retrace11RelayRunner7runRaceEv (glretrace) #3 0x0042fc3a _ZN7retrace11RelayRunner12runnerThreadEPS0_ (glretrace) #4 0x00433eb2 _ZN2os6thread13CallbackParamIFvPN7retrace11RelayRunnerEES4_EclEv (glretrace) #5 0x00433631 _ZN2os6thread9_callbackINS0_13CallbackParamIFvPN7retrace11RelayRunnerEES5_PvS8_ (glretrace) #6 0x7fc68515e484 start_thread (libpthread.so.0) #7 0x7fc683dc4aed __clone (libc.so.6) -- 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/20151222/1df529f0/attachment.html>
[Bug 80419] XCOM: Enemy Unknown Causes lockup
https://bugs.freedesktop.org/show_bug.cgi?id=80419 --- Comment #83 from Daniel Exner --- Managed to get some more infos about glretrace crash: Stack trace of thread 13986: #0 0x7fca93b67945 loader_dri3_wait_gl (libGL.so.1) #1 0x0042e6e1 _ZN4glws11GlxDrawable6resizeEii (glretrace) #2 0x004405d7 _ZN9glretrace14updateDrawableEii (glretrace) #3 0x004ffca1 _ZL25retrace_glBlitFramebufferRN5trace4CallE (glretrace) #4 0x0043a4a5 _ZN7retrace8Retracer7retraceERN5trace4CallE (glretrace) #5 0x0042fb36 _ZN7retraceL11retraceCallEPN5trace4CallE (glretrace) #6 0x0043183f _ZN7retrace11RelayRunner6runLegEPN5trace4CallE (glretrace) #7 0x004317a8 _ZN7retrace11RelayRunner7runRaceEv (glretrace) #8 0x0042fc3a _ZN7retrace11RelayRunner12runnerThreadEPS0_ (glretrace) #9 0x00433eb2 _ZN2os6thread13CallbackParamIFvPN7retrace11RelayRunnerEES4_EclEv (glretrace) #10 0x00433631 _ZN2os6thread9_callbackINS0_13CallbackParamIFvPN7retrace11RelayRunnerEES5_PvS8_ (glretrace) #11 0x7fca95856484 start_thread (libpthread.so.0) #12 0x7fca944bcaed __clone (libc.so.6) Stack trace of thread 13984: #0 0x7fca9585c05f pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0) #1 0x00430be1 _ZN2os18condition_variable4waitERNS_11unique_lockINS_5mutexEEE (glretrace) #2 0x00431749 _ZN7retrace11RelayRunner7runRaceEv (glretrace) #3 0x0042fc3a _ZN7retrace11RelayRunner12runnerThreadEPS0_ (glretrace) #4 0x00433eb2 _ZN2os6thread13CallbackParamIFvPN7retrace11RelayRunnerEES4_EclEv (glretrace) #5 0x00433631 _ZN2os6thread9_callbackINS0_13CallbackParamIFvPN7retrace11RelayRunnerEES5_PvS8_ (glretrace) #6 0x7fca95856484 start_thread (libpthread.so.0) #7 0x7fca944bcaed __clone (libc.so.6) Stack trace of thread 13983: #0 0x7fca9585c05f pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0) #1 0x00430be1 _ZN2os18condition_variable4waitERNS_11unique_lockINS_5mutexEEE (glretrace) #2 0x00431749 _ZN7retrace11RelayRunner7runRaceEv (glretrace) #3 0x0042fc3a _ZN7retrace11RelayRunner12runnerThreadEPS0_ (glretrace) #4 0x00433eb2 _ZN2os6thread13CallbackParamIFvPN7retrace11RelayRunnerEES4_EclEv (glretrace) #5 0x00433631 _ZN2os6thread9_callbackINS0_13CallbackParamIFvPN7retrace11RelayRunnerEES5_PvS8_ (glretrace) #6 0x7fca95856484 start_thread (libpthread.so.0) #7 0x7fca944bcaed __clone (libc.so.6) Stack trace of thread 13981: #0 0x7fca9585c05f pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0) #1 0x00430be1 _ZN2os18condition_variable4waitERNS_11unique_lockINS_5mutexEEE (glretrace) #2 0x00431749 _ZN7retrace11RelayRunner7runRaceEv (glretrace) #3 0x0042fead _ZN7retrace9RelayRace3runEv (glretrace) #4 0x00430073 _ZN7retraceL8mainLoopEv (glretrace) #5 0x00430957 main (glretrace) #6 0x7fca943f45e0 __libc_start_main (libc.so.6) #7 0x0042c5e9 _start (glretrace) Stack trace of thread 13982: #0 0x7fca9585c05f pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0) #1 0x7fca8ff35ba3 radeon_drm_cs_emit_ioctl (radeonsi_dri.so) #2 0x7fca8ff353e7 impl_thrd_routine (radeonsi_dri.so) #3 0x7fca95856484 start_thread (libpthread.so.0) #4 0x7fca944bcaed __clone (libc.so.6) loader_dri3_wait_gl looks suspicious. Will retry with DRI3 disabled. -- 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/20151222/f50e1fcb/attachment.html>
[PATCH 0/6] add rk3036 vop support
Hi I want to push these patches in a couple of days, So just Ping if anyone interested or have some doubt on it. Thanks. -Mark On 2015å¹´12æ17æ¥ 11:37, Mark Yao wrote: > This series of patches add rk3036 vop support. > > RK3036 registers layout is quite difference with rk3288 layout, > The IC design with different framework, rk3036 vop is VOP LITE, > and rk3288 is VOP FULL. > > RK3036 support two overlay plane and one hwc plane, max output > resolution is 1080p. it support IOMMU, and its IOMMU same as > rk3288's. > > This patches is based on drm/rockchip atomic patches. [0] > > Tested on kylin board, kylin runs on 4.1 kernel. > > backport to 4.1, and picked Yakir Yang's inno hdmi patches [1]. > works with test program atomictest[2] and modetest. > > [0]: https://lkml.org/lkml/2015/12/16/824 > [1]: https://lkml.org/lkml/2015/11/11/53 > [2]: https://github.com/markyzq/libdrm.git atomictest > > Mark Yao (6): >drm/rockchip: vop: merge vop cfg_done into vop_data >drm/rockchip: vop: move interrupt registers into vop_data >drm/rockchip: vop: spilt register related into rockchip_reg_vop.c >drm/rockchip: vop: spilt scale regsters to common and extension >drm/rockchip: vop: add rk3036 vop support >dt-bindings: add document for rk3036-vop > > .../bindings/display/rockchip/rockchip-vop.txt |1 + > drivers/gpu/drm/rockchip/Makefile |3 +- > drivers/gpu/drm/rockchip/rockchip_drm_vop.c| 411 > > drivers/gpu/drm/rockchip/rockchip_drm_vop.h| 230 ++- > drivers/gpu/drm/rockchip/rockchip_vop_reg.c| 316 +++ > drivers/gpu/drm/rockchip/rockchip_vop_reg.h| 169 > 6 files changed, 696 insertions(+), 434 deletions(-) > create mode 100644 drivers/gpu/drm/rockchip/rockchip_vop_reg.c > create mode 100644 drivers/gpu/drm/rockchip/rockchip_vop_reg.h >
[Bug 80419] XCOM: Enemy Unknown Causes lockup
https://bugs.freedesktop.org/show_bug.cgi?id=80419 --- Comment #82 from Michael Eagle --- (In reply to Kamil Páral from comment #74) > > (I'm sorry, I still have the same month-old mesa as in comment 70, I didn't > figure out how to update it easily before I started tinkering with the > replays). Hello, On Fedora 23 I'm using this copr: https://copr.fedoraproject.org/coprs/griever/mesa-git/ It provides the following packages as of today: [root at mike-laptop mike]# rpm -qa | grep mesa mesa-filesystem-11.2.0-0.devel.22.ea8c0b1.fc23.x86_64 mesa-libGLES-11.2.0-0.devel.22.ea8c0b1.fc23.x86_64 mesa-libOSMesa-11.2.0-0.devel.22.ea8c0b1.fc23.x86_64 mesa-libgbm-11.2.0-0.devel.22.ea8c0b1.fc23.i686 mesa-libxatracker-11.2.0-0.devel.22.ea8c0b1.fc23.x86_64 mesa-libEGL-11.2.0-0.devel.22.ea8c0b1.fc23.i686 mesa-libGLU-9.0.0-9.fc23.x86_64 mesa-filesystem-11.2.0-0.devel.22.ea8c0b1.fc23.i686 mesa-libglapi-11.2.0-0.devel.22.ea8c0b1.fc23.x86_64 mesa-libglapi-11.2.0-0.devel.22.ea8c0b1.fc23.i686 mesa-libgbm-11.2.0-0.devel.22.ea8c0b1.fc23.x86_64 mesa-libGL-11.2.0-0.devel.22.ea8c0b1.fc23.i686 mesa-dri-drivers-11.2.0-0.devel.22.ea8c0b1.fc23.x86_64 mesa-libGL-11.2.0-0.devel.22.ea8c0b1.fc23.x86_64 mesa-dri-drivers-11.2.0-0.devel.22.ea8c0b1.fc23.i686 mesa-libEGL-11.2.0-0.devel.22.ea8c0b1.fc23.x86_64 mesa-libwayland-egl-11.2.0-0.devel.22.ea8c0b1.fc23.x86_64 Hope it helps. -- 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/20151222/1a94599a/attachment.html>
[Bug 80419] XCOM: Enemy Unknown Causes lockup
https://bugs.freedesktop.org/show_bug.cgi?id=80419 --- Comment #81 from Daniel Exner --- Don't get this error with llvmpipe. But also no crash. (Still running, slow as hell). -- 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/20151222/a58bd638/attachment.html>
[PATCH] drm/vc4: Remove broken attempt at GPU reset using genpd.
On Mon, Dec 21, 2015 at 06:08:44PM -0800, Eric Anholt wrote: > I've tested and confirmed that it doesn't actually work. We'll need > to sort out how to do this properly later, but for now just remove it > since it also caused build breakage due to using CONFIG_PM_SLEEP > functions without our Kconfig depending on PM_SLEEP. > > Signed-off-by: Eric Anholt Acked-by: Sudip Mukherjee regards sudip
[Bug 80419] XCOM: Enemy Unknown Causes lockup
https://bugs.freedesktop.org/show_bug.cgi?id=80419 --- Comment #80 from Daniel Exner --- Yes, you where right. Some guy at my distro removed it without telling anyone. Is back now. Now I get (with radeonsi): glretrace game.x86_64.trace apitrace: warning: caught signal 11 47062: error: caught an unhandled exception glretrace+0x28d196 glretrace+0x28c92c glretrace+0x289ccd /lib/libpthread.so.0+0x10d3f /usr/lib/libGL.so.1+0x48945 glretrace+0x2e6e0 glretrace+0x405d6 glretrace+0xffca0 glretrace+0x3a4a4 glretrace+0x2fb35 glretrace+0x3183e glretrace+0x317a7 glretrace+0x2fc39 glretrace+0x33eb1 glretrace+0x33630 /lib/libpthread.so.0+0x7483 /lib/libc.so.6: clone+0x6c ? apitrace: info: taking default action for signal 11 -- 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/20151222/6dcabd6a/attachment.html>
[PATCH] drm/fb-helper: Use proper plane mask for fb cleanup
Op 19-12-15 om 02:27 schreef Matt Roper: > pan_display_atomic() calls drm_atomic_clean_old_fb() to sanitize the > legacy FB fields (plane->fb and plane->old_fb). However it was building > the plane mask to pass to this function incorrectly (the bitwise OR was > using plane indices rather than plane masks). The end result was that > sometimes the legacy pointers would become out of sync with the atomic > pointers. If another operation tried to re-set the same FB onto the > plane, we might end up with the pointers back in sync, but improper > reference counts, which would eventually lead to system crashes when we > accessed a pointer to a prematurely-destroyed FB. > > The cause here was a very subtle bug introduced in commit: > > commit 07d3bad6c1210bd21e85d084807ef4ee4ac43a78 > Author: Maarten Lankhorst > Date: Wed Nov 11 11:29:11 2015 +0100 > > drm/core: Fix old_fb handling in pan_display_atomic. > > I found the crashes were most easily reproduced (on i915 at least) by > starting X and then VT switching to a VT that wasn't running a console > instance...the sequence of vt/fbcon entries that happen in that case > trigger a reference count mismatch and crash the system. > > Cc: Maarten Lankhorst > Cc: Daniel Vetter > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93313 > Signed-off-by: Matt Roper > --- > drivers/gpu/drm/drm_fb_helper.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c > index 69cbab5..1e103c4 100644 > --- a/drivers/gpu/drm/drm_fb_helper.c > +++ b/drivers/gpu/drm/drm_fb_helper.c > @@ -1251,7 +1251,7 @@ retry: > goto fail; > > plane = mode_set->crtc->primary; > - plane_mask |= drm_plane_index(plane); > + plane_mask |= (1 << drm_plane_index(plane)); > plane->old_fb = plane->fb; > } > Signed-off-by: Maarten Lankhorst
[Bug 80419] XCOM: Enemy Unknown Causes lockup
https://bugs.freedesktop.org/show_bug.cgi?id=80419 --- Comment #79 from Michel Dänzer --- (In reply to Daniel Exner from comment #78) > >10536: message: major api error 1: GL_INVALID_ENUM in > >glCompressedTexImage2D(internalFormat=0x8c4d) > >10536 @1 glCompressedTexImage2DARB(target = GL_TEXTURE_2D, level = 0, > >>internalformat = GL_COMPRESSED_SRGB_ALPHA_S3TC_DXT1_EXT, width = 64, height > >= >64, border = 0, imageSize = 2048, data = blob(2048)) > >10536: warning: glGetError(glCompressedTexImage2DARB) = GL_INVALID_ENUM Looks like you may be missing GL_EXT_texture_compression_s3tc. Do you have libtxc-dxtn(-s2tc) packages installed? -- 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/20151222/22121864/attachment.html>
[Bug 80419] XCOM: Enemy Unknown Causes lockup
https://bugs.freedesktop.org/show_bug.cgi?id=80419 --- Comment #78 from Daniel Exner --- I tried to replay the trace attached: > glretrace game.x86_64.trace But all I get is this (many times repeated): >10536: message: major api error 1: GL_INVALID_ENUM in >glCompressedTexImage2D(internalFormat=0x8c4d) >10536 @1 glCompressedTexImage2DARB(target = GL_TEXTURE_2D, level = 0, >>internalformat = GL_COMPRESSED_SRGB_ALPHA_S3TC_DXT1_EXT, width = 64, height = >>64, border = 0, imageSize = 2048, data = blob(2048)) >10536: warning: glGetError(glCompressedTexImage2DARB) = GL_INVALID_ENUM Mesa: OpenGL core profile version string: 4.1 (Core Profile) Mesa 11.1.0 Hardware: OpenGL renderer string: Gallium 0.4 on AMD PITCAIRN (DRM 2.43.0, LLVM 3.7.0) Kernel: Linux 4.4.0-rc6-5-g9d951f9 #4 SMP PREEMPT Mon Dec 21 18:33:34 CET 2015 x86_64 x86_64 x86_64 GNU/Linux Will try now with llvmpipe -- 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/20151222/312c0cb5/attachment.html>
[Bug 93471] [radeonsi] power consumption on pitcairn card stays high after 2. monitor disconnected
https://bugs.freedesktop.org/show_bug.cgi?id=93471 --- Comment #3 from Michel Dänzer --- Any chance you could try the current xf86-video-ati release 7.6.1? http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=ddaba449e8d6fe9fc0d97085e4045843fd8d7af9 might help. -- 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/20151222/c72e0e75/attachment.html>
[Bug 93471] [radeonsi] power consumption on pitcairn card stays high after 2. monitor disconnected
https://bugs.freedesktop.org/show_bug.cgi?id=93471 --- Comment #2 from Malte --- Created attachment 120649 --> https://bugs.freedesktop.org/attachment.cgi?id=120649&action=edit Xorg.log startup with second monitor attached -- 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/20151222/6c329a26/attachment-0001.html>
[Bug 80419] XCOM: Enemy Unknown Causes lockup
https://bugs.freedesktop.org/show_bug.cgi?id=80419 --- Comment #77 from Michel Dänzer --- (In reply to Kamil Páral from comment #76) > I could try to reproduce it by looping the replay over, if needed. No need, it's not important. The assumption for now is that the Xorg crash is caused by the GPU hang. If you happen to get a gdb backtrace of it in the future, that will help verify this assumption, but it's no more than nice to have. -- 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/20151222/f5491fbd/attachment.html>
[Bug 80419] XCOM: Enemy Unknown Causes lockup
https://bugs.freedesktop.org/show_bug.cgi?id=80419 --- Comment #76 from Kamil Páral --- > That said, we could probably confirm either way if we could look at a gdb > backtrace of the Xorg crash. Unfortunately I don't have it. ABRT deleted it due to some unfortunate circumstances. I could try to reproduce it by looping the replay over, if needed. -- 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/20151222/11251713/attachment.html>
[Bug 88263] Civilization Beyond Earth crashes on r600
https://bugs.freedesktop.org/show_bug.cgi?id=88263 Ernst Sjöstrand changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #7 from Ernst Sjöstrand --- There's been a lot of updates since this bug was reported, is this still an issue? -- 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/20151222/9e4df887/attachment.html>
[Bug 93032] [radeonsi] Civilization Beyond Earth segfaults
https://bugs.freedesktop.org/show_bug.cgi?id=93032 Ernst Sjöstrand changed: What|Removed |Added Status|NEW |NEEDINFO CC||ernstp at gmail.com --- Comment #16 from Ernst Sjöstrand --- Is this still an issue with latest git for you? Kernel 3.4... that's really old. Tried with a newer kernel? -- 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/20151222/01f4897a/attachment.html>
[Bug 89780] Vertex drawing error on Civilization Beyond Earth
https://bugs.freedesktop.org/show_bug.cgi?id=89780 Ernst Sjöstrand changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #2 from Ernst Sjöstrand --- I don't think this is an issue anymore with latest git at least? -- 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/20151222/b0d9d9eb/attachment.html>
[Bug 80419] XCOM: Enemy Unknown Causes lockup
https://bugs.freedesktop.org/show_bug.cgi?id=80419 --- Comment #75 from Michel Dänzer --- (In reply to Kamil Páral from comment #74) > There's this line: > (EE) 2: /lib64/libc.so.6 (__memcpy_avx_unaligned+0x1ab) [0x7fe7ee3ffafb] > which is the same function that I reported to be crashing in apitrace: > https://github.com/apitrace/apitrace/issues/407 > > Is this just a coincidence, or these two bugs are related (or the very same)? Presumably coincidence. The apitrace crashes are segmentation faults, i.e. probably due to overrunning some buffer[0]. The Xorg crash is a bus error, which is probably fallout of the GPU hang. That said, we could probably confirm either way if we could look at a gdb backtrace of the Xorg crash. [0] FWIW, replaying the apitrace with valgrind on llvmpipe, I'm also seeing invalid memory access, so it might be a bug in apitrace or some shared Gallium / Mesa code rather than in the radeonsi 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/20151222/5d7d7d30/attachment.html>
[Bug 92428] Sword Coast Legends causing GPU lockup. radeon 0000:01:00.0: GPU lockup (current fence id 0x000000000000afd1 last fence id 0x000000000000b194 on ring 3)
https://bugs.freedesktop.org/show_bug.cgi?id=92428 --- Comment #10 from James --- (In reply to James from comment #9) > (In reply to Michel Dänzer from comment #8) > > (In reply to James from comment #7) > > > The link is here. > > > https://www.dropbox.com/s/15mfgng35b2rmt2/SwordCoast.x86_64.1.trace?dl=0 > > > > I don't get any VM faults when replaying that, let alone a lockup, neither > > on Kaveri nor Verde. Does replaying this apitrace reproduce the problem for > > you? > > Yes, it replays up to the splash screen then hard locks my PC. Although I'm > using a 7850 so it wouldn't be Kaveri or Verde. It would be Pitcarin/GCN. > Don't > know if that makes a difference. -- 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/20151222/8b6d74cd/attachment.html>
[Bug 92428] Sword Coast Legends causing GPU lockup. radeon 0000:01:00.0: GPU lockup (current fence id 0x000000000000afd1 last fence id 0x000000000000b194 on ring 3)
https://bugs.freedesktop.org/show_bug.cgi?id=92428 --- Comment #9 from James --- (In reply to Michel Dänzer from comment #8) > (In reply to James from comment #7) > > The link is here. > > https://www.dropbox.com/s/15mfgng35b2rmt2/SwordCoast.x86_64.1.trace?dl=0 > > I don't get any VM faults when replaying that, let alone a lockup, neither > on Kaveri nor Verde. Does replaying this apitrace reproduce the problem for > you? Yes, it replays up to the splash screen then hard locks my PC. Although I'm using a 7850 wouldn't be Kaveri or Verde. It would be Pitcarin/GCN. Don't know if that makes a difference. -- 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/20151222/a3b98779/attachment-0001.html>
[Bug 93460] [amdgpu] Ooops during shutdown - amdgpu_vm_grab_id
https://bugs.freedesktop.org/show_bug.cgi?id=93460 --- Comment #8 from david1.zhou at amd.com --- (In reply to Christian König from comment #7) > (In reply to david1.zhou at amd.com from comment #6) > > Maybe we shall avoid to use fence for vmid, instead using LRU list. > > Yeah, thought about that as well. The problem is that we used to have an LRU > list and I switched to fences because they had less overhead. > > We still need to keep the fences around for synchronization, so I'm not sure > if that would really help. > > The real price question is what is going wrong here? yes, we need to identify why the contexts of two fences are different, where two fences come from, what the kind of two fences are, which ring two fences belong. -- 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/20151222/0a084e05/attachment.html>
[Bug 92229] [APITRACE] SOMA have serious graphical errors
https://bugs.freedesktop.org/show_bug.cgi?id=92229 --- Comment #8 from Grazvydas Ignotas --- This fixes the trace for me: http://lists.freedesktop.org/archives/mesa-dev/2015-December/103647.html Does it also fix the game? -- 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/20151222/009ea31b/attachment.html>
[Bug 93471] [radeonsi] power consumption on pitcairn card stays high after 2. monitor disconnected
https://bugs.freedesktop.org/show_bug.cgi?id=93471 --- Comment #1 from Michel Dänzer --- Please attach the corresponding Xorg log file. -- 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/20151222/c27f4005/attachment.html>
