date:20160909

[PATCH v15.1 3/5] drm/rockchip: cdn-dp: add cdn DP support for rk3399

2016-09-09 Thread Chris Zhong

Add support for cdn DP controller which is embedded in the rk3399
SoCs. The DP is compliant with DisplayPort Specification,
Version 1.3, This IP is compatible with the rockchip type-c PHY IP.
There is a uCPU in DP controller, it need a firmware to work,
please put the firmware file to /lib/firmware/rockchip/dptx.bin. The
uCPU in charge of aux communication and link training, the host use
mailbox to communicate with the ucpu.
The dclk pin_pol of vop must not be invert for DP.

Signed-off-by: Chris Zhong 
Signed-off-by: Sean Paul 
Reviewed-by: Sean Paul 
Acked-by: Mark Yao 

---

Changes in v15.1:
- do better for err case

Changes in v15:
Chris Zhong's changes:
- fix disable phy unbalance
- support Apple Dock hot-plug in HDMI port
- retraining when Apple Dock hpd irq coming
Sean Paul's changes:
- Restructured the worker
- Synchronized between worker & drm hooks
- Properly implemented enable/disable
- Added error checking
- Use devm variant of extcon
- Use DRM_DEV_* logging
- Refactored code to (hopefully) be more clear

Changes in v14:
- Modify some grammatical errors
- remove the mutex around cdn_dp_audio_get_eld
- power on the power domain after clk_enable
- retry to read edid
- change super speed property name to EXTCON_PROP_USB_SS
- do a correct mode_valid check when bpc is 0

Changes in v13:
- support suspend/resume
- switch power domain dynamically
- re-training when hpd signal is triggered

Changes in v12:
- use EXTCON_PROP_USB_SUPERSPEED to replace EXTCON_USB_HOST

Changes in v11:
- add best_encoder back, since it required by drm_atomic_helper_check

Changes in v10:
- remove best_encoder ops
- support read sink count from DPCD
- control the grf_clk in DP

Changes in v9:
- do not need reset the phy before power_on
- add a orientation information for set_capability
- retry to read dpcd in 10 seconds

Changes in v8:
- optimization the err log

Changes in v7:
- support firmware standby when no dptx connection
- optimization the calculation of tu size and valid symbol

Changes in v6:
- add a port struct
- select SND_SOC_HDMI_CODEC
- force reset the phy when hpd detected

Changes in v5:
- alphabetical order
- do not use long, use u32 or u64
- return MODE_CLOCK_HIGH when requested > actual
- Optimized Coding Style
- add a formula to get better tu size and symbol value.
- modify according to Sean Paul's comments
- fixed the fw_wait always 0

Changes in v4:
- use phy framework to control DP phy
- support 2 phys

Changes in v3:
- use EXTCON_DISP_DP and EXTCON_DISP_DP_ALT cable to get dp port state.
- reset spdif before config it
- modify the firmware clk to 100Mhz
- retry load firmware if fw file is requested too early

Changes in v2:
- Alphabetic order
- remove excess error message
- use define clk_rate
- check all return value
- remove dev_set_name(dp->dev, "cdn-dp");
- use schedule_delayed_work
- remove never-called functions
- remove some unnecessary ()

Changes in v1:
- use extcon API
- use hdmi-codec for the DP Asoc
- do not initialize the "ret"
- printk a err log when drm_of_encoder_active_endpoint_id
- modify the dclk pin_pol to a single line

 drivers/gpu/drm/rockchip/Kconfig|   10 +
 drivers/gpu/drm/rockchip/Makefile   |1 +
 drivers/gpu/drm/rockchip/cdn-dp-core.c  | 1163 +++
 drivers/gpu/drm/rockchip/cdn-dp-core.h  |  108 +++
 drivers/gpu/drm/rockchip/cdn-dp-reg.c   |  956 ++
 drivers/gpu/drm/rockchip/cdn-dp-reg.h   |  482 +++
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |   13 +-
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h |9 +
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c |2 +
 9 files changed, 2741 insertions(+), 3 deletions(-)
 create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-core.c
 create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-core.h
 create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-reg.c
 create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-reg.h

diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index d30bdc3..20aaafe 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -25,6 +25,16 @@ config ROCKCHIP_ANALOGIX_DP
  for the Analogix Core DP driver. If you want to enable DP
  on RK3288 based SoC, you should selet this option.

+config ROCKCHIP_CDN_DP
+tristate "Rockchip cdn DP"
+depends on DRM_ROCKCHIP
+   select SND_SOC_HDMI_CODEC if SND_SOC
+help
+ This selects support for Rockchip SoC specific extensions
+ for the cdn DP driver. If you want to enable Dp on
+ RK3399 based SoC, you should select this
+ option.
+
 config ROCKCHIP_DW_HDMI
 tristate "Rockchip specific extensions for Synopsys DW HDMI"
 depends on DRM_ROCKCHIP
diff --git a/drivers/gpu/drm/rockchip/Makefile 
b/drivers/gpu/drm/rockchip/Makefile
index 9746365..6a07809 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -7,6 +7,7 @@

[PATCH v3 2/4] ARM: sun5i: a13-olinuxino: Enable VGA bridge

2016-09-09 Thread Chen-Yu Tsai

On Thu, Sep 8, 2016 at 8:17 PM, Maxime Ripard
 wrote:
> Now that we have support for the VGA bridges using our DRM driver, enable
> the display engine for the Olimex A13-Olinuxino.
>
> Signed-off-by: Maxime Ripard 

Assuming the bridge bindings are good,

Acked-by: Chen-Yu Tsai

[Bug 97643] Shader crashes radeon driver and brings the whole system down

2016-09-09 Thread bugzilla-dae...@freedesktop.org

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

Cris  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #7 from Cris  ---
(In reply to Nicolai HÃ¤hnle from comment #6)
> Cris, do please try with more recent Mesa + LLVM as well.
> 
> If that still crashes, can you provide a backtrace of where mpv crashes?
> dmesg output from the crash could also give some context.

I did, I upgraded to llvm-3.9.0 and mesa-git, and the issue went away. Most
conservative distros might have a hard time though.

Thanks anyway.

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

[PATCH 21/20] drm/exynos: Fix iommu_dma_init_domain prototype change

2016-09-09 Thread Robin Murphy

When adding an extra argument to a function, one really should try a bit
harder to catch *all* the callers...

CC: Marek Szyprowski 
CC: Inki Dae 
CC: David Airlie 
CC: dri-devel at lists.freedesktop.org
Signed-off-by: Robin Murphy 

---

Ideally, this should be squashed into "iommu/dma: Avoid PCI host bridge
windows" to avoid potential bisection breakage. Sorry!

 drivers/gpu/drm/exynos/exynos_drm_iommu.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_iommu.h 
b/drivers/gpu/drm/exynos/exynos_drm_iommu.h
index c8de4913fdbe..87f6b5672e11 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_iommu.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_iommu.h
@@ -66,7 +66,7 @@ static inline int __exynos_iommu_create_mapping(struct 
exynos_drm_private *priv,
if (ret)
goto free_domain;

-   ret = iommu_dma_init_domain(domain, start, size);
+   ret = iommu_dma_init_domain(domain, start, size, NULL);
if (ret)
goto put_cookie;

-- 
2.8.1.dirty

[PATCH v15 4/5] drm/rockchip: cdn-dp: support audio hot-plug

2016-09-09 Thread Chris Zhong

Issue hot-plug detection, EDID update, and ELD update notifications
from DP drivers.

Signed-off-by: Chris Zhong 
---

Changes in v15: None
Changes in v14: None
Changes in v13: None
Changes in v12: None
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
Changes in v1: None

 drivers/gpu/drm/rockchip/cdn-dp-core.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c 
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index 8d708d3..de1cf3e 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -233,6 +234,7 @@ static int cdn_dp_connector_get_modes(struct drm_connector 
*connector)
drm_mode_connector_update_edid_property(connector,
edid);
drm_edid_to_eld(connector, edid);
+   hdmi_event_new_eld(dp->dev, connector->eld);
}
kfree(edid);
}
@@ -631,6 +633,7 @@ static void cdn_dp_encoder_enable(struct drm_encoder 
*encoder)

 out:
mutex_unlock(>lock);
+   hdmi_event_connect(dp->dev);
 }

 static void cdn_dp_encoder_disable(struct drm_encoder *encoder)
@@ -647,6 +650,7 @@ static void cdn_dp_encoder_disable(struct drm_encoder 
*encoder)
}
}
mutex_unlock(>lock);
+   hdmi_event_disconnect(dp->dev);
 }

 static int cdn_dp_encoder_atomic_check(struct drm_encoder *encoder,
-- 
1.9.1

[PATCH v15 3/5] drm/rockchip: cdn-dp: add cdn DP support for rk3399

2016-09-09 Thread Chris Zhong

Add support for cdn DP controller which is embedded in the rk3399
SoCs. The DP is compliant with DisplayPort Specification,
Version 1.3, This IP is compatible with the rockchip type-c PHY IP.
There is a uCPU in DP controller, it need a firmware to work,
please put the firmware file to /lib/firmware/rockchip/dptx.bin. The
uCPU in charge of aux communication and link training, the host use
mailbox to communicate with the ucpu.
The dclk pin_pol of vop must not be invert for DP.

Signed-off-by: Chris Zhong 
Signed-off-by: Sean Paul 
Reviewed-by: Sean Paul 
Acked-by: Mark Yao 

---

Changes in v15:
Chris Zhong's changes:
- fix disable phy unbalance
- support Apple Dock hot-plug in HDMI port
- retraining when Apple Dock hpd irq coming
Sean Paul's changes:
- Restructured the worker
- Synchronized between worker & drm hooks
- Properly implemented enable/disable
- Added error checking
- Use devm variant of extcon
- Use DRM_DEV_* logging
- Refactored code to (hopefully) be more clear

Changes in v14:
- Modify some grammatical errors
- remove the mutex around cdn_dp_audio_get_eld
- power on the power domain after clk_enable
- retry to read edid
- change super speed property name to EXTCON_PROP_USB_SS
- do a correct mode_valid check when bpc is 0

Changes in v13:
- support suspend/resume
- switch power domain dynamically
- re-training when hpd signal is triggered

Changes in v12:
- use EXTCON_PROP_USB_SUPERSPEED to replace EXTCON_USB_HOST

Changes in v11:
- add best_encoder back, since it required by drm_atomic_helper_check

Changes in v10:
- remove best_encoder ops
- support read sink count from DPCD
- control the grf_clk in DP

Changes in v9:
- do not need reset the phy before power_on
- add a orientation information for set_capability
- retry to read dpcd in 10 seconds

Changes in v8:
- optimization the err log

Changes in v7:
- support firmware standby when no dptx connection
- optimization the calculation of tu size and valid symbol

Changes in v6:
- add a port struct
- select SND_SOC_HDMI_CODEC
- force reset the phy when hpd detected

Changes in v5:
- alphabetical order
- do not use long, use u32 or u64
- return MODE_CLOCK_HIGH when requested > actual
- Optimized Coding Style
- add a formula to get better tu size and symbol value.
- modify according to Sean Paul's comments
- fixed the fw_wait always 0

Changes in v4:
- use phy framework to control DP phy
- support 2 phys

Changes in v3:
- use EXTCON_DISP_DP and EXTCON_DISP_DP_ALT cable to get dp port state.
- reset spdif before config it
- modify the firmware clk to 100Mhz
- retry load firmware if fw file is requested too early

Changes in v2:
- Alphabetic order
- remove excess error message
- use define clk_rate
- check all return value
- remove dev_set_name(dp->dev, "cdn-dp");
- use schedule_delayed_work
- remove never-called functions
- remove some unnecessary ()

Changes in v1:
- use extcon API
- use hdmi-codec for the DP Asoc
- do not initialize the "ret"
- printk a err log when drm_of_encoder_active_endpoint_id
- modify the dclk pin_pol to a single line

 drivers/gpu/drm/rockchip/Kconfig|   10 +
 drivers/gpu/drm/rockchip/Makefile   |1 +
 drivers/gpu/drm/rockchip/cdn-dp-core.c  | 1161 +++
 drivers/gpu/drm/rockchip/cdn-dp-core.h  |  108 +++
 drivers/gpu/drm/rockchip/cdn-dp-reg.c   |  956 ++
 drivers/gpu/drm/rockchip/cdn-dp-reg.h   |  482 +++
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |   13 +-
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h |9 +
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c |2 +
 9 files changed, 2739 insertions(+), 3 deletions(-)
 create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-core.c
 create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-core.h
 create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-reg.c
 create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-reg.h

diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index d30bdc3..20aaafe 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -25,6 +25,16 @@ config ROCKCHIP_ANALOGIX_DP
  for the Analogix Core DP driver. If you want to enable DP
  on RK3288 based SoC, you should selet this option.

+config ROCKCHIP_CDN_DP
+tristate "Rockchip cdn DP"
+depends on DRM_ROCKCHIP
+   select SND_SOC_HDMI_CODEC if SND_SOC
+help
+ This selects support for Rockchip SoC specific extensions
+ for the cdn DP driver. If you want to enable Dp on
+ RK3399 based SoC, you should select this
+ option.
+
 config ROCKCHIP_DW_HDMI
 tristate "Rockchip specific extensions for Synopsys DW HDMI"
 depends on DRM_ROCKCHIP
diff --git a/drivers/gpu/drm/rockchip/Makefile 
b/drivers/gpu/drm/rockchip/Makefile
index 9746365..6a07809 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -7,6 +7,7 @@ rockchipdrm-y := rockchip_drm_drv.o

[PATCH v15 0/5] Rockchip Type-C DisplayPort driver

2016-09-09 Thread Chris Zhong


Hi all

This series patch is for rockchip Type-C DisplayPort controller driver.

The USB Type-C PHY is designed to support the USB3 and DP applications.
The PHY basically has two main components: USB3 and DisplyPort. USB3
operates in SuperSpeed mode and the DP can operate at RBR, HBR and HBR2
data rates. The Type-C cable orientation detection and Power Delivery
(PD) is accomplished using a PD PHY or a exernal PD chip.

The DP controller is compliant with DisplayPort Specification,
Version 1.3, This IP is compatible with the rockchip type-c PHY IP.
There is a uCPU in DP controller, it need a firmware to work, please
put the firmware file[0] rockchip/dptx.bin to
/lib/firmware/rockchip/dptx.bin. The uCPU in charge of aux communication
and link training, the host use mailbox to communicate with the ucpu.

The DP contoller has register a notification with extcon API, to get the
alt mode from PD, the PD driver need call the devm_extcon_dev_allocate
to create a extcon device and use extcon_set_state to notify DP
controller. And call extcon_set_cable_property to set orientation.

About the DP audio, cdn-dp registered 2 DAIs: 0 is I2S, 1 is SPDIF.
We can reference them in rk3399-gru machine driver. It base on the
hdmi-notify patches[1], they are both in reviewing.

This series is based on Mark Yao's branch[2], the extcon API backport
from linux-next[3].

I test this patches on the rk3399-evb board, with a fusb302 driver,
this branch has no rk3399.dtsi, so the patch about dts is not included
in this series.

>From V9, the Type-C PHY is split into two PHYs: DP and USB3. The PHY
will be init, no matter which PHY be power_on. The DP module will
enter A2 mode (standby mode) after phy_init, if DP PHY is powered on,
the DP module will enter to A0 mode(running mode). Then if DP PHY is
powered off, DP module will back to A2 mode. If everything is
un-plugged, phy will be deinit.

[0]
kernel/git/firmware/linux-firmware.git
[1]
https://patchwork.kernel.org/patch/8887261/
https://patchwork.kernel.org/patch/8887251/
[2]
https://github.com/markyzq/kernel-drm-rockchip/tree/drm-rockchip-next-2016-05-23
[3]
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master


Changes in v15:
Chris Zhong's changes:
- fix disable phy unbalance
- support Apple Dock hot-plug in HDMI port
- retraining when Apple Dock hpd irq coming
Sean Paul's changes:
- Restructured the worker
- Synchronized between worker & drm hooks
- Properly implemented enable/disable
- Added error checking
- Use devm variant of extcon
- Use DRM_DEV_* logging
- Refactored code to (hopefully) be more clear

Changes in v14:
- Modify some grammatical errors
- remove the mutex around cdn_dp_audio_get_eld
- power on the power domain after clk_enable
- retry to read edid
- change super speed property name to EXTCON_PROP_USB_SS
- do a correct mode_valid check when bpc is 0

Changes in v13:
- add dptx and apb reset
- support suspend/resume
- switch power domain dynamically
- re-training when hpd signal is triggered

Changes in v12:
- use EXTCON_PROP_USB_SUPERSPEED to replace EXTCON_USB_HOST

Changes in v11:
- refer dp phy
- add best_encoder back, since it required by drm_atomic_helper_check

Changes in v10:
- add pclk_vio_grf clock
- remove best_encoder ops
- support read sink count from DPCD
- control the grf_clk in DP

Changes in v9:
- modify the reference phy = < 0>, < 0>;
- do not need reset the phy before power_on
- add a orientation information for set_capability
- retry to read dpcd in 10 seconds

Changes in v8:
- optimization the err log

Changes in v7:
- support firmware standby when no dptx connection
- optimization the calculation of tu size and valid symbol

Changes in v6:
- add assigned-clocks and assigned-clock-rates
- add power-domains
- add a port struct
- select SND_SOC_HDMI_CODEC
- force reset the phy when hpd detected

Changes in v5:
- alphabetical order
- do not use long, use u32 or u64
- return MODE_CLOCK_HIGH when requested > actual
- Optimized Coding Style
- add a formula to get better tu size and symbol value.
- modify according to Sean Paul's comments
- fixed the fw_wait always 0

Changes in v4:
- add a reset node
- support 2 phys
- use phy framework to control DP phy
- support 2 phys

Changes in v3:
- add SoC specific compatible string
- remove reg = <1>;
- use EXTCON_DISP_DP and EXTCON_DISP_DP_ALT cable to get dp port state.
- reset spdif before config it
- modify the firmware clk to 100Mhz
- retry load firmware if fw file is requested too early
- change spdif to i2s2

Changes in v2:
- Alphabetic order
- remove excess error message
- use define clk_rate
- check all return value
- remove dev_set_name(dp->dev, "cdn-dp");
- use schedule_delayed_work
- remove never-called functions
- remove some unnecessary ()
- correct the commit message

Changes in v1:
- add extcon node description
- add #sound-dai-cells description
- use extcon API
- use hdmi-codec for the DP Asoc
- do not initialize the "ret"
- printk a err log when

[Bug 97123] [AMDGPU][CIK] Suspend to disk deadlocks system on resume always (Linus master + drm-next-4.9-wip)

2016-09-09 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #5 from Shawn Starr  ---
[PATCH v2] drm/amd/amdgpu: S4 issue for amdgpu - Works

Still have corruption on freeze() but its non-fatal for thaw() on resume from
reboot hibernation.

Will Continue to test additional patches, no lockups so far.

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

[Bug 97610] [CIK] Fullscreen video with Firefox only shows "tiled pixel garbage"

2016-09-09 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #6 from Kai  ---
(In reply to Marek OlÅ¡Ã¡k from comment #5)
> Mesa doesn't use the PRT tile modes.

Thanks for the information!

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

[Bug 97610] [CIK] Fullscreen video with Firefox only shows "tiled pixel garbage"

2016-09-09 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #5 from Marek OlÅ¡Ã¡k  ---
Mesa doesn't use the PRT tile modes.

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

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

2016-09-09 Thread bugzilla-dae...@freedesktop.org

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

Kai  changed:

   What|Removed |Added

 Status|RESOLVED|VERIFIED

--- Comment #8 from Kai  ---
(In reply to Michel DÃ¤nzer from comment #7)
> This issue wasn't limited to mobile Bonaire. One interesting hint from bug
> 97610 is that it works fine with the radeon kernel driver, so maybe it's
> related to addrlib or the amdgpu winsys.
> 
> Anyway, fixed for now in Git master. Note that you need to start X with the
> fixed Mesa, because it affects glamor as well.
> 
> Module: Mesa
> Branch: master
> Commit: 93f3d8e10d712336b86ebe17dafaee0aac7ec429
> URL: 
> <http://cgit.freedesktop.org/mesa/mesa/commit/?id=93f3d8e10d712336b86ebe17dafaee0aac7ec429>
> 
> Author: Marek OlÅ¡Ã¡k 
> Date:   Thu Sep  8 18:21:04 2016 +0200
> 
> Revert "radeonsi: enable SDMA on CIK"

I can confirm this fixes the corruption I've reported in bug 97610.

Since Marek mentioned in the commit message of the revert, that it's maybe some
tile configuration issue, I was wondering if Tom was correct in bug 97610,
comment #1? Should I do the test â obviously with the revert undone â with 
the
tiling configurations copied from radeon (bug 97610, comment #2)? Or is this
something else?

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

[PATCH v3 3/3] drm/bridge: analogix_dp: detect Sink PSR state after configuring the PSR

2016-09-09 Thread Yakir Yang

Make sure the request PSR state takes effect in analogix_dp_send_psr_spd()
function, or print the sink PSR error state if we failed to apply the
requested PSR setting.

Signed-off-by: Yakir Yang 
---
Changes in v3:
- Update commit message
- Add DP_TIMEOUT_PSR_LOOP_MS marcos
- Correct the return values of analogix_dp_send_psr_spd()

Changes in v2:
- A bunch of good fixes from Sean

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c |  6 ++
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  5 +++--
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  | 25 --
 3 files changed, 28 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 5fe3982..c0ce16a 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -116,8 +116,7 @@ int analogix_dp_enable_psr(struct device *dev)
psr_vsc.DB0 = 0;
psr_vsc.DB1 = EDP_VSC_PSR_STATE_ACTIVE | EDP_VSC_PSR_CRC_VALUES_VALID;

-   analogix_dp_send_psr_spd(dp, _vsc);
-   return 0;
+   return analogix_dp_send_psr_spd(dp, _vsc);
 }
 EXPORT_SYMBOL_GPL(analogix_dp_enable_psr);

@@ -139,8 +138,7 @@ int analogix_dp_disable_psr(struct device *dev)
psr_vsc.DB0 = 0;
psr_vsc.DB1 = 0;

-   analogix_dp_send_psr_spd(dp, _vsc);
-   return 0;
+   return analogix_dp_send_psr_spd(dp, _vsc);
 }
 EXPORT_SYMBOL_GPL(analogix_dp_disable_psr);

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index d564e90..a27f1e3 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -20,6 +20,7 @@
 #define MAX_EQ_LOOP 5

 #define DP_TIMEOUT_LOOP_MS msecs_to_jiffies(1)
+#define DP_TIMEOUT_PSR_LOOP_MS msecs_to_jiffies(300)

 /* DP_MAX_LANE_COUNT */
 #define DPCD_ENHANCED_FRAME_CAP(x) (((x) >> 7) & 0x1)
@@ -248,8 +249,8 @@ void analogix_dp_config_video_slave_mode(struct 
analogix_dp_device *dp);
 void analogix_dp_enable_scrambling(struct analogix_dp_device *dp);
 void analogix_dp_disable_scrambling(struct analogix_dp_device *dp);
 void analogix_dp_enable_psr_crc(struct analogix_dp_device *dp);
-void analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
- struct edp_vsc_psr *vsc);
+int analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
+struct edp_vsc_psr *vsc);
 ssize_t analogix_dp_transfer(struct analogix_dp_device *dp,
 struct drm_dp_aux_msg *msg);
 #endif /* _ANALOGIX_DP_CORE_H */
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index 15a4cf0..7fd4ed0 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -1004,10 +1004,12 @@ void analogix_dp_enable_psr_crc(struct 
analogix_dp_device *dp)
writel(PSR_VID_CRC_ENABLE, dp->reg_base + ANALOGIX_DP_CRC_CON);
 }

-void analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
- struct edp_vsc_psr *vsc)
+int analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
+struct edp_vsc_psr *vsc)
 {
+   unsigned long timeout;
unsigned int val;
+   u8 sink;

/* don't send info frame */
val = readl(dp->reg_base + ANALOGIX_DP_PKT_SEND_CTL);
@@ -1048,6 +1050,25 @@ void analogix_dp_send_psr_spd(struct analogix_dp_device 
*dp,
val = readl(dp->reg_base + ANALOGIX_DP_PKT_SEND_CTL);
val |= IF_EN;
writel(val, dp->reg_base + ANALOGIX_DP_PKT_SEND_CTL);
+
+   timeout = jiffies + DP_TIMEOUT_PSR_LOOP_MS;
+   while (time_before(jiffies, timeout)) {
+   val = drm_dp_dpcd_readb(>aux, DP_PSR_STATUS, );
+   if (val != 1) {
+   dev_err(dp->dev, "PSR_STATUS read failed ret=%d", val);
+   return -EBUSY;
+   }
+
+   if ((vsc->DB1 && sink == DP_PSR_SINK_ACTIVE_RFB) ||
+   (!vsc->DB1 && sink == DP_PSR_SINK_INACTIVE))
+   return 0;
+
+   usleep_range(1000, 1500);
+   }
+
+   dev_warn(dp->dev, "Failed to apply PSR, sink state was [%x]", sink);
+
+   return -ETIMEDOUT;
 }

 ssize_t analogix_dp_transfer(struct analogix_dp_device *dp,
-- 
1.9.1

[PATCH v3 2/3] drm/bridge: analogix_dp: use jiffies to simulate timeout loop

2016-09-09 Thread Yakir Yang

Signed-off-by: Yakir Yang 
---
Changes in v3:
- Suggested by Sean

Changes in v2: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  3 ++-
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  | 18 +-
 2 files changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index a15f076..d564e90 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -16,10 +16,11 @@
 #include 
 #include 

-#define DP_TIMEOUT_LOOP_COUNT 100
 #define MAX_CR_LOOP 5
 #define MAX_EQ_LOOP 5

+#define DP_TIMEOUT_LOOP_MS msecs_to_jiffies(1)
+
 /* DP_MAX_LANE_COUNT */
 #define DPCD_ENHANCED_FRAME_CAP(x) (((x) >> 7) & 0x1)
 #define DPCD_MAX_LANE_COUNT(x) ((x) & 0x1f)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index a4d17b8..15a4cf0 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -335,7 +335,7 @@ void analogix_dp_set_analog_power_down(struct 
analogix_dp_device *dp,
 void analogix_dp_init_analog_func(struct analogix_dp_device *dp)
 {
u32 reg;
-   int timeout_loop = 0;
+   unsigned long timeout;

analogix_dp_set_analog_power_down(dp, POWER_ALL, 0);

@@ -350,9 +350,9 @@ void analogix_dp_init_analog_func(struct analogix_dp_device 
*dp)
if (analogix_dp_get_pll_lock_status(dp) == PLL_UNLOCKED) {
analogix_dp_set_pll_power_down(dp, 0);

+   timeout = jiffies + DP_TIMEOUT_LOOP_MS;
while (analogix_dp_get_pll_lock_status(dp) == PLL_UNLOCKED) {
-   timeout_loop++;
-   if (DP_TIMEOUT_LOOP_COUNT < timeout_loop) {
+   if (time_after(jiffies, timeout)) {
dev_err(dp->dev, "failed to get pll lock 
status\n");
return;
}
@@ -501,7 +501,7 @@ int analogix_dp_start_aux_transaction(struct 
analogix_dp_device *dp)
 {
int reg;
int retval = 0;
-   int timeout_loop = 0;
+   unsigned long timeout;

/* Enable AUX CH operation */
reg = readl(dp->reg_base + ANALOGIX_DP_AUX_CH_CTL_2);
@@ -509,10 +509,10 @@ int analogix_dp_start_aux_transaction(struct 
analogix_dp_device *dp)
writel(reg, dp->reg_base + ANALOGIX_DP_AUX_CH_CTL_2);

/* Is AUX CH command reply received? */
+   timeout = jiffies + DP_TIMEOUT_LOOP_MS;
reg = readl(dp->reg_base + ANALOGIX_DP_INT_STA);
while (!(reg & RPLY_RECEIV)) {
-   timeout_loop++;
-   if (DP_TIMEOUT_LOOP_COUNT < timeout_loop) {
+   if (time_after(jiffies, timeout)) {
dev_err(dp->dev, "AUX CH command reply failed!\n");
return -ETIMEDOUT;
}
@@ -1055,7 +1055,7 @@ ssize_t analogix_dp_transfer(struct analogix_dp_device 
*dp,
 {
u32 reg;
u8 *buffer = msg->buffer;
-   int timeout_loop = 0;
+   unsigned long timeout;
unsigned int i;
int num_transferred = 0;

@@ -1123,10 +1123,10 @@ ssize_t analogix_dp_transfer(struct analogix_dp_device 
*dp,

/* Is AUX CH command reply received? */
/* TODO: Wait for an interrupt instead of looping? */
+   timeout = jiffies + DP_TIMEOUT_LOOP_MS;
reg = readl(dp->reg_base + ANALOGIX_DP_INT_STA);
while (!(reg & RPLY_RECEIV)) {
-   timeout_loop++;
-   if (timeout_loop > DP_TIMEOUT_LOOP_COUNT) {
+   if (time_after(jiffies, timeout)) {
dev_err(dp->dev, "AUX CH command reply failed!\n");
return -ETIMEDOUT;
}
-- 
1.9.1

[Bug 97730] Monitor not recognized after upgrading to a Radeon RX 480

2016-09-09 Thread bugzilla-dae...@freedesktop.org

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

Bug ID: 97730
   Summary: Monitor not recognized after upgrading to a Radeon RX
480
   Product: DRI
   Version: DRI git
  Hardware: Other
OS: All
Status: NEW
  Severity: major
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: damien at grassart.com

Created attachment 126413
  --> https://bugs.freedesktop.org/attachment.cgi?id=126413=edit
/sys/class/drm/card0-DP-2/edid

I upgraded my video card from a Radeon HD 8770 to a Radeon RX 480 after which
my monitor stopped working. I believe it is an EDID problem since dmesg
contains this repeated 4 times:

[  +0.120622] [drm:drm_edid_block_valid [drm]] *ERROR* EDID checksum is
invalid, remainder is 128
[  +0.11] Raw EDID:
[  +0.05]   ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  +0.04]   ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  +0.05]   ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  +0.04]   ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  +0.05]   ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  +0.05]   ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  +0.04]   ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  +0.05]   ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

As well as:

[  +0.05] amdgpu :01:00.0: DP-2: Ignoring invalid EDID block 1.
[  +0.149608] amdgpu :01:00.0: No connectors reported connected with modes

xrandr shows this error message when I run it: "xrandr: Output DisplayPort-1 is
not disconnected but has no modes".

I can actually get the monitor working by manually adding a mode:

$ cvt 2560 1440
# 2560x1440 59.96 Hz (CVT 3.69M9) hsync: 89.52 kHz; pclk: 312.25 MHz
Modeline "2560x1440_60.00"  312.25  2560 2752 3024 3488  1440 1443 1448 1493
-hsync +vsync
$ xrandr --newmode "2560x1440" 312.25  2560 2752 3024 3488  1440 1443 1448 1493
-hsync +vsync
$ xrandr --addmode DisplayPort-1 2560x1440

I've attached the /sys/class/drm/card0-DP-2/edid file if that is helpful.
Please let me know if I can provide anything else.

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

[GIT PULL] TDA998x I2C driver development updates

2016-09-09 Thread Russell King

David,

Please incorporate the latest TDA998x I2C driver development updates,
which can be found at:

  git://git.armlinux.org.uk/~rmk/linux-arm.git drm-tda998x-devel

with SHA1 3e980591945eadbfdf4cbc05d56e5f44010a5a87.

This adds the ASoC codec interfaces for TDA998x HDMI audio from
Jyri Sarha.

This will update the following files:

 .../devicetree/bindings/display/bridge/tda998x.txt |  18 ++
 arch/arm/boot/dts/am335x-boneblack.dts |  71 -
 drivers/gpu/drm/i2c/Kconfig|   1 +
 drivers/gpu/drm/i2c/tda998x_drv.c  | 297 ++---
 include/drm/i2c/tda998x.h  |  29 +-
 include/dt-bindings/display/tda998x.h  |   7 +
 6 files changed, 368 insertions(+), 55 deletions(-)
 create mode 100644 include/dt-bindings/display/tda998x.h

through these changes:

Jyri Sarha (3):
  drm/i2c: tda998x: Improve tda998x_configure_audio() audio related pdata
  drm/i2c: tda998x: Register ASoC hdmi-codec and add audio DT binding
  ARM: dts: am335x-boneblack: Add HDMI audio support

Many thanks.

[PATCH v2 2/2] drm/bridge: analogix_dp: detect Sink PSR state after configuring the PSR

2016-09-09 Thread Yakir Yang

On 09/08/2016 10:12 PM, Sean Paul wrote:
> On Wed, Sep 7, 2016 at 11:48 PM, Yakir Yang  wrote:
>> Make sure the request PSR state could effect in analogix_dp_send_psr_spd()
>> function, or printing the error Sink PSR state if we failed to effect
>> the request PSR setting.
>>
>
> Let's change to:
>
> Make sure the request PSR state takes effect in analogix_dp_send_psr_spd()
> function, or print the sink PSR error state if we failed to apply the
> requested PSR
> setting.
Done,
>> Signed-off-by: Yakir Yang 
>> ---
>> Changes in v2:
>> - A bunch of good fixes from Sean
>>
>>   drivers/gpu/drm/bridge/analogix/analogix_dp_core.c |  6 ++
>>   drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  4 ++--
>>   drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  | 25 
>> --
>>   3 files changed, 27 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
>> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>> index 5fe3982..c0ce16a 100644
>> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>> @@ -116,8 +116,7 @@ int analogix_dp_enable_psr(struct device *dev)
>>  psr_vsc.DB0 = 0;
>>  psr_vsc.DB1 = EDP_VSC_PSR_STATE_ACTIVE | 
>> EDP_VSC_PSR_CRC_VALUES_VALID;
>>
>> -   analogix_dp_send_psr_spd(dp, _vsc);
>> -   return 0;
>> +   return analogix_dp_send_psr_spd(dp, _vsc);
>>   }
>>   EXPORT_SYMBOL_GPL(analogix_dp_enable_psr);
>>
>> @@ -139,8 +138,7 @@ int analogix_dp_disable_psr(struct device *dev)
>>  psr_vsc.DB0 = 0;
>>  psr_vsc.DB1 = 0;
>>
>> -   analogix_dp_send_psr_spd(dp, _vsc);
>> -   return 0;
>> +   return analogix_dp_send_psr_spd(dp, _vsc);
>>   }
>>   EXPORT_SYMBOL_GPL(analogix_dp_disable_psr);
>>
>> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h 
>> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
>> index a15f076..6c07a50 100644
>> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
>> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
>> @@ -247,8 +247,8 @@ void analogix_dp_config_video_slave_mode(struct 
>> analogix_dp_device *dp);
>>   void analogix_dp_enable_scrambling(struct analogix_dp_device *dp);
>>   void analogix_dp_disable_scrambling(struct analogix_dp_device *dp);
>>   void analogix_dp_enable_psr_crc(struct analogix_dp_device *dp);
>> -void analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
>> - struct edp_vsc_psr *vsc);
>> +int analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
>> +struct edp_vsc_psr *vsc);
>>   ssize_t analogix_dp_transfer(struct analogix_dp_device *dp,
>>   struct drm_dp_aux_msg *msg);
>>   #endif /* _ANALOGIX_DP_CORE_H */
>> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c 
>> b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
>> index a4d17b8..09d703b 100644
>> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
>> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
>> @@ -1004,10 +1004,12 @@ void analogix_dp_enable_psr_crc(struct 
>> analogix_dp_device *dp)
>>  writel(PSR_VID_CRC_ENABLE, dp->reg_base + ANALOGIX_DP_CRC_CON);
>>   }
>>
>> -void analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
>> - struct edp_vsc_psr *vsc)
>> +int analogix_dp_send_psr_spd(struct analogix_dp_device *dp,
>> +struct edp_vsc_psr *vsc)
>>   {
>> +   unsigned long timeout;
>>  unsigned int val;
>> +   u8 sink;
>>
>>  /* don't send info frame */
>>  val = readl(dp->reg_base + ANALOGIX_DP_PKT_SEND_CTL);
>> @@ -1048,6 +1050,25 @@ void analogix_dp_send_psr_spd(struct 
>> analogix_dp_device *dp,
>>  val = readl(dp->reg_base + ANALOGIX_DP_PKT_SEND_CTL);
>>  val |= IF_EN;
>>  writel(val, dp->reg_base + ANALOGIX_DP_PKT_SEND_CTL);
>> +
>> +   timeout = jiffies + msecs_to_jiffies(DP_TIMEOUT_LOOP_COUNT);
> Mismatched units here. DP_TIMEOUT_LOOP_COUNT is defined as number of
> retries, whereas you're using it as number of ms. Fortunately, the
> retry number is so high that this works out :)
>
> In a separate patch preceding this one, can you change
> DP_TIMEOUT_LOOP_COUNT to DP_TIMEOUT_LOOP_MS and alter the other
> timeout loops to use time_before() like this one instead of blindly
> looping 100 times? After that, you can use DP_TIMEOUT_LOOP_MS here.

Done, and after do some experiments, I found we need to set the timeout 
to 300ms. Cause in some case we would take about 290ms here to get the 
right psr state.


>> +   while (time_before(jiffies, timeout)) {
>> +   val = drm_dp_dpcd_readb(>aux, DP_PSR_STATUS, );
>> +   if (val != 1) {
>> +   dev_err(dp->dev, "PSR_STATUS read failed ret=%d", 
>> val);
>> +   return val;
> Ok, since this is my snippet this comment is my fault,

[PATCH v2 6/9] drm/panel: Add Netron DY E231732

2016-09-09 Thread Maxime Ripard

On Wed, Sep 07, 2016 at 12:01:56AM +0800, Chen-Yu Tsai wrote:
> Hi,
> 
> On Tue, Sep 6, 2016 at 10:46 PM, Maxime Ripard
>  wrote:
> > The E231732 is a 7" panel with a resolution of 800x480.
> 
> From what I could make out of an archived version of Netron's website
> (it's unreachable from my place), they are a manufacturer of printed
> ribbon cables, not LCD panels. This is probably a no-go.

I don't know. I haven't been able to find any website for Netron DY,
however, googling the part number I used find numerous matches on ebay
and alibaba.

Maxime
-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160909/d5206795/attachment.sig>

[PATCH 3/6] drm/panel: simple: Add A10 EVB 5 inch panel support

2016-09-09 Thread Maxime Ripard

Hi,

On Mon, Sep 05, 2016 at 10:00:01PM +0800, Chen-Yu Tsai wrote:
> On Wed, Aug 31, 2016 at 4:18 PM, Maxime Ripard
>  wrote:
> > The A10-EVB from Allwinner comes with an unidentified panel, with the only
> > mark on the PCB being A10-SUB-EVB-5LCD.
> >
> > Add timings to simple panel to handle it.
> >
> > Signed-off-by: Maxime Ripard 
> > ---
> >  drivers/gpu/drm/panel/panel-simple.c | 26 ++
> >  1 file changed, 26 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/panel/panel-simple.c 
> > b/drivers/gpu/drm/panel/panel-simple.c
> > index 85143d1b9b31..be371b053aab 100644
> > --- a/drivers/gpu/drm/panel/panel-simple.c
> > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > @@ -386,6 +386,29 @@ static void panel_simple_shutdown(struct device *dev)
> > panel_simple_disable(>base);
> >  }
> >
> > +static const struct drm_display_mode allwinner_a10_sub_evb_5lcd_mode = {
> > +   .clock = 33000,
> > +   .hdisplay = 800,
> > +   .hsync_start = 800 + 209,
> > +   .hsync_end = 800 + 209 + 1,
> > +   .htotal = 800 + 209 + 1 + 45,
> > +   .vdisplay = 480,
> > +   .vsync_start = 480 + 22,
> > +   .vsync_end = 480 + 22 + 1,
> > +   .vtotal = 480 + 22 + 1 + 22,
> > +   .vrefresh = 60,
> 
> I assume the numbers came from the fex file? Allwinner LCD timing numbers
> aren't very precise. This seems to yield a refresh rate of 58.x Hz.
> The dot clock can go below MHz resolution, so it should be possible
> to set it to a more proper clock rate here.

Indeed.

Upon closer inspection, it seems (from the ribbon) that the display is
an hannstar, but there's no screen reference anywhere.

By looking into it using the available references, the date of
production found on that panel, and so on, it seems like it is an
HSD050IDW1-A, whose timings do not seem to far off. But it's pure
speculation at this point.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160909/d72d8656/attachment.sig>

[PATCH 1/2] drm/ttm: remove unused placement flags

2016-09-09 Thread Christian König

Am 09.09.2016 um 15:54 schrieb Emil Velikov:
> On 9 September 2016 at 12:24, Christian KÃ¶nig  
> wrote:
>> Hi Hawking,
>>
>>> Removing the flag will make ttm_mem_type_from_place skip counting the
>>> corresponding placement and thus have impact on mem region create and bo
>>> movement.
>> And that is exactly the reason why I want to remove the unused flags.
>>
>>> There is no guarantee that amdgpu would never introduce new memory domain
>>> in future.
>> Irrelevant, if any driver wants to use additional domains it should add them
>> when they are used.
>>
>> BTW: Why would we want to add another TTM domain? I really don't see any
>> need for that.
>>
>>> Then how about keep these flags?
>> Actually we used to have automated scanners which complain about unused
>> code. I'm wondering why they don't detected that earlier.
>>
>> Anyway any code which isn't used in a while should be removed.
>>
> Fwiw I second Christian here. If they are unused in open-source
> drivers there's no reason to keep them.
> If/as that changes the (newly introduced) user can add back the relevant code.

Crap to late :( I was about to send a V2 of the patch to keep the PRIV 
flags.

> If closed-source driver(s) use them, then they can keep it as part of
> their blob. Upstream kernel does not cater for closed-source drivers,
> period.
> I realise that's not the answer some are hoping for, so if you want to
> question it take it up with Linus and co.

It's not an issue between closed vs. open, but rather additional work of 
rebasing the open code when we start to use additional domains.

But on the other hand I still haven't seen a good reason for using 
those. As far as I know we have covered all resource in the current and 
next hardware generation with the existing flags.

Regards,
Christian.

> Regards,
> Emil

[PATCH v8 12/12] drm/i915: Check TMDS clock DP to HDMI dongle

2016-09-09 Thread Mika Kahola

On Fri, 2016-09-09 at 12:09 +0300, Ville SyrjÃ¤lÃ¤ wrote:
> On Fri, Sep 09, 2016 at 10:45:27AM +0300, Mika Kahola wrote:
> > 
> > On Thu, 2016-09-08 at 15:48 +0300, Ville SyrjÃ¤lÃ¤ wrote:
> > > 
> > > On Wed, Aug 17, 2016 at 01:49:49PM +0300, Mika Kahola wrote:
> > > > 
> > > > 
> > > > Respect max TMDS clock frequency from DPCD for active
> > > > DP to HDMI adapters.
> > > > 
> > > > Signed-off-by: Mika Kahola 
> > > > ---
> > > > Â drivers/gpu/drm/i915/intel_drv.hÂ Â |Â Â 3 +++
> > > > Â drivers/gpu/drm/i915/intel_hdmi.c | 27
> > > > +++
> > > > Â 2 files changed, 30 insertions(+)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > > > b/drivers/gpu/drm/i915/intel_drv.h
> > > > index 1c700b0..b7fd551 100644
> > > > --- a/drivers/gpu/drm/i915/intel_drv.h
> > > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > > @@ -817,6 +817,9 @@ struct intel_hdmi {
> > > > Â   i915_reg_t hdmi_reg;
> > > > Â   int ddc_bus;
> > > > Â   struct {
> > > > +   int max_tmds_clock;
> > > > +   } dp_to_hdmi;
> > > > +   struct {
> > > > Â   enum drm_dp_dual_mode_type type;
> > > > Â   int max_tmds_clock;
> > > > Â   } dp_dual_mode;
> > > > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> > > > b/drivers/gpu/drm/i915/intel_hdmi.c
> > > > index 4df9f38..1469d00 100644
> > > > --- a/drivers/gpu/drm/i915/intel_hdmi.c
> > > > +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> > > > @@ -1204,6 +1204,9 @@ static int hdmi_port_clock_limit(struct
> > > > intel_hdmi *hdmi,
> > > > Â   int max_tmds_clock =
> > > > intel_hdmi_source_max_tmds_clock(to_i915(dev));
> > > > Â 
> > > > Â   if (respect_downstream_limits) {
> > > > +   if (hdmi->dp_to_hdmi.max_tmds_clock)
> > > > +   max_tmds_clock = min(max_tmds_clock,
> > > > +   Â Â Â Â Â hdmi-
> > > > > 
> > > > > dp_to_hdmi.max_tmds_clock);
> > > > Â   if (hdmi->dp_dual_mode.max_tmds_clock)
> > > > Â   max_tmds_clock = min(max_tmds_clock,
> > > > Â   Â Â Â Â Â hdmi-
> > > > > 
> > > > > dp_dual_mode.max_tmds_clock);
> > > > @@ -1373,11 +1376,33 @@ intel_hdmi_unset_edid(struct
> > > > drm_connector
> > > > *connector)
> > > > Â   intel_hdmi->dp_dual_mode.type = DRM_DP_DUAL_MODE_NONE;
> > > > Â   intel_hdmi->dp_dual_mode.max_tmds_clock = 0;
> > > > Â 
> > > > +   intel_hdmi->dp_to_hdmi.max_tmds_clock = 0;
> > > > +
> > > > Â   kfree(to_intel_connector(connector)->detect_edid);
> > > > Â   to_intel_connector(connector)->detect_edid = NULL;
> > > > Â }
> > > > Â 
> > > > Â static void
> > > > +intel_hdmi_dp_adapter_detect(struct drm_connector *connector)
> > > > +{
> > > > +   struct intel_hdmi *intel_hdmi =
> > > > intel_attached_hdmi(connector);
> > > > +   struct intel_digital_port *intel_dig_port =
> > > > +   hdmi_to_dig_port(intel_hdmi);
> > > > +   struct intel_dp *intel_dp = _dig_port->dp;
> > > > +   int type = intel_dp->downstream_ports[0] &
> > > > DP_DS_PORT_TYPE_MASK;
> > > > +
> > > > +   if (type != DP_DS_PORT_TYPE_HDMI)
> > > > +   return;
> > > > +
> > > > +   intel_hdmi->dp_to_hdmi.max_tmds_clock =
> > > > +   drm_dp_downstream_max_clock(intel_dp->dpcd,
> > > > +   Â Â Â Â intel_dp-
> > > > > 
> > > > > downstream_ports);
> > > Poets driven by intel_hdmi don't have DPCD, so I don't know what
> > > this
> > > is supposed to achieve.
> > My understanding is that these HDMI adapters has DPCD and therefore
> > I
> > placed this function. In addition, I think we should respect the
> > clocks
> > if the adapter provides that information.
> Only stuff driven by intel_dp has DPCD.
All right. Then this patch can be discarded. Or maybe I move this stuff
into intel_dp.

> 
> > 
> > 
> > > 
> > > 
> > > > 
> > > > 
> > > > +
> > > > +   DRM_DEBUG_KMS("DP HDMI adaptor detected (max TMDS
> > > > clock :
> > > > %d kHz\n",
> > > > +   Â Â Â Â Â Â intel_hdmi->dp_to_hdmi.max_tmds_clock);
> > > > +}
> > > > +
> > > > +static void
> > > > Â intel_hdmi_dp_dual_mode_detect(struct drm_connector
> > > > *connector,
> > > > bool has_edid)
> > > > Â {
> > > > Â   struct drm_i915_private *dev_priv = to_i915(connector-
> > > > > 
> > > > > dev);
> > > > @@ -1438,6 +1463,8 @@ intel_hdmi_set_edid(struct drm_connector
> > > > *connector, bool force)
> > > > Â 
> > > > Â   intel_hdmi_dp_dual_mode_detect(connector, edid
> > > > !=
> > > > NULL);
> > > > Â 
> > > > +   intel_hdmi_dp_adapter_detect(connector);
> > > > +
> > > > Â   intel_display_power_put(dev_priv,
> > > > POWER_DOMAIN_GMBUS);
> > > > Â   }
> > > > Â 
> > > > --Â 
> > > > 1.9.1
> > --Â 
> > Mika Kahola - Intel OTC
-- 
Mika Kahola - Intel OTC

[PATCH 1/2] drm/ttm: remove unused placement flags

2016-09-09 Thread Christian König

Am 09.09.2016 um 15:41 schrieb Deucher, Alexander:
>> -Original Message-
>> From: amd-gfx [mailto:amd-gfx-bounces at lists.freedesktop.org] On Behalf
>> Of Christian KÃ¶nig
>> Sent: Friday, September 09, 2016 7:24 AM
>> To: Zhang, Hawking; Koenig, Christian; Cui, Flora; Zhou, David(ChunMing);
>> amd-gfx at lists.freedesktop.org
>> Cc: dri-devel at lists.freedesktop.org
>> Subject: Re: [PATCH 1/2] drm/ttm: remove unused placement flags
>>
>> Hi Hawking,
>>
>>> Removing the flag will make ttm_mem_type_from_place skip counting the
>> corresponding placement and thus have impact on mem region create and
>> bo movement.
>> And that is exactly the reason why I want to remove the unused flags.
>>
>>> There is no guarantee that amdgpu would never introduce new memory
>> domain in future.
>> Irrelevant, if any driver wants to use additional domains it should add
>> them when they are used.
>>
>> BTW: Why would we want to add another TTM domain? I really don't see any
>> need for that.
> We need it for the hybrid driver in the near feature and the open driver may 
> use it in the future depending on the use cases.  Removing it just makes our 
> lives more difficult for supporting dkms and distro integration for very 
> minimal gain.

Yeah, agree. The problem is I already did so without knowing that.

I will send out a V2 only removing the stuff we explicitly don't need.

Hopefully nobody will notice and question further,
Christian.

>
> Alex
>
>>> Then how about keep these flags?
>> Actually we used to have automated scanners which complain about unused
>> code. I'm wondering why they don't detected that earlier.
>>
>> Anyway any code which isn't used in a while should be removed.
>>
>> Regards,
>> Christian.
>>
>> Am 09.09.2016 um 12:35 schrieb Zhang, Hawking:
>>> Hi Chris,
>>>
>>> Removing the flag will make ttm_mem_type_from_place skip counting the
>> corresponding placement and thus have impact on mem region create and
>> bo movement. There is no guarantee that amdgpu would never introduce
>> new memory domain in future. In such case, I'd like to vote for keeping
>> these flags instead of adding them back when amdgpu need to add new
>> memory domain.
>>> As you mentioned that it just a two liner. And there is actually no
>> functionality break with these flags. Then how about keep these flags?
>>> Regards,
>>> Hawking
>>>
>>> -Original Message-
>>> From: amd-gfx [mailto:amd-gfx-bounces at lists.freedesktop.org] On Behalf
>> Of Christian K?nig
>>> Sent: Friday, September 09, 2016 17:07
>>> To: Cui, Flora ; Zhou, David(ChunMing)
>> 
>>> Cc: amd-gfx at lists.freedesktop.org; dri-devel at lists.freedesktop.org
>>> Subject: Re: [PATCH 1/2] drm/ttm: remove unused placement flags
>>>
>>> In this case please just add them back in your tree. That should be a two
>> liner.
>>> For upstream it certainly doesn't make sense to keep them.
>>>
>>> Regards,
>>> Christian.
>>>
>>> Am 09.09.2016 um 09:01 schrieb Flora Cui:
 yes. please don't do this, I need them.

 On Fri, Sep 09, 2016 at 02:41:16PM +0800, zhoucm1 wrote:
> On 2016å¹´09æ08æ¥ 21:41, Christian KÃ¶nig wrote:
>> From: Christian KÃ¶nig 
>>
>> Either never used or not used in quite a while.
> No, I remember Flora's Direct GMA is using them like GDS use PRIV0-2.
> And you cannot make sure there isn't no one using them in other
> closed projects, right?
> If you removed now, that obviously will break her implementation and
> brings her many troubles.
>
>
> Regards,
> David Zhou
>> Signed-off-by: Christian KÃ¶nig 
>> ---
>> drivers/gpu/drm/ttm/ttm_bo.c|  2 +-
>> include/drm/ttm/ttm_placement.h | 19 ---
>> 2 files changed, 1 insertion(+), 20 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c
>> b/drivers/gpu/drm/ttm/ttm_bo.c index bc37f02..4d2e8f2 100644
>> --- a/drivers/gpu/drm/ttm/ttm_bo.c
>> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
>> @@ -59,7 +59,7 @@ static inline int ttm_mem_type_from_place(const
>> struct ttm_place *place,
>> {
>>  int i;
>> -for (i = 0; i <= TTM_PL_PRIV5; i++)
>> +for (i = 0; i <= TTM_PL_PRIV2; i++)
>>  if (place->flags & (1 << i)) {
>>  *mem_type = i;
>>  return 0;
>> diff --git a/include/drm/ttm/ttm_placement.h
>> b/include/drm/ttm/ttm_placement.h index 8ed44f9..20219d9 100644
>> --- a/include/drm/ttm/ttm_placement.h
>> +++ b/include/drm/ttm/ttm_placement.h
>> @@ -40,10 +40,6 @@
>> #define TTM_PL_PRIV03
>> #define TTM_PL_PRIV14
>> #define TTM_PL_PRIV25
>> -#define TTM_PL_PRIV36
>> -#define TTM_PL_PRIV47
>> -#define TTM_PL_PRIV58
>> -#define TTM_PL_SWAPPED  15
>> #define TTM_PL_FLAG_SYSTEM  (1 << TTM_PL_SYSTEM)
>>

[PATCH 1/2] drm/ttm: remove unused placement flags

2016-09-09 Thread Emil Velikov

On 9 September 2016 at 15:30, Christian KÃ¶nig  
wrote:
> Am 09.09.2016 um 15:54 schrieb Emil Velikov:
>>
>> On 9 September 2016 at 12:24, Christian KÃ¶nig 
>> wrote:
>>>
>>> Hi Hawking,
>>>
 Removing the flag will make ttm_mem_type_from_place skip counting the
 corresponding placement and thus have impact on mem region create and bo
 movement.
>>>
>>> And that is exactly the reason why I want to remove the unused flags.
>>>
 There is no guarantee that amdgpu would never introduce new memory
 domain
 in future.
>>>
>>> Irrelevant, if any driver wants to use additional domains it should add
>>> them
>>> when they are used.
>>>
>>> BTW: Why would we want to add another TTM domain? I really don't see any
>>> need for that.
>>>
 Then how about keep these flags?
>>>
>>> Actually we used to have automated scanners which complain about unused
>>> code. I'm wondering why they don't detected that earlier.
>>>
>>> Anyway any code which isn't used in a while should be removed.
>>>
>> Fwiw I second Christian here. If they are unused in open-source
>> drivers there's no reason to keep them.
>> If/as that changes the (newly introduced) user can add back the relevant
>> code.
>
>
> Crap to late :( I was about to send a V2 of the patch to keep the PRIV
> flags.
>
Oops, sorry :-)

>> If closed-source driver(s) use them, then they can keep it as part of
>> their blob. Upstream kernel does not cater for closed-source drivers,
>> period.
>> I realise that's not the answer some are hoping for, so if you want to
>> question it take it up with Linus and co.
>
>
> It's not an issue between closed vs. open, but rather additional work of
> rebasing the open code when we start to use additional domains.
>
This should serve as a greater initiative to develop and upstream
things in a gradual manner, no ?
We all get carried away sometimes creating a massive branch which just
cannot go in at once.

> But on the other hand I still haven't seen a good reason for using those. As
> far as I know we have covered all resource in the current and next hardware
> generation with the existing flags.
>
This in itself is a pretty good point as well, considering you know
the hardware fairly well and you've worked in the kernel for quite a
while now.

Regards,
Emil

[Bug 97055] Black screens on A10-8780P (Carrizo) + R7 M260/M265 (Topaz) Combo

2016-09-09 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #10 from Thomas J. Moore  ---
4.8-rc5 appears to no longer prevent X from starting.  I guess that's some sort
of progress (or at least no longer regress).  Still doesn't fix this bug,
though.

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

[Bug 35457] [rs690m] Graphics corruption with ati x1200

2016-09-09 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #111 from Micha  ---
I still have my laptop, but I am a complete noob and do not know how to test
this


Actually installed is Mint Mate 18 if I am not wrong

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

[PATCH 1/2] drm/ttm: remove unused placement flags

2016-09-09 Thread Flora Cui

yes. please don't do this, I need them.

On Fri, Sep 09, 2016 at 02:41:16PM +0800, zhoucm1 wrote:
> 
> 
> On 2016å¹´09æ08æ¥ 21:41, Christian KÃ¶nig wrote:
> >From: Christian KÃ¶nig 
> >
> >Either never used or not used in quite a while.
> No, I remember Flora's Direct GMA is using them like GDS use PRIV0-2. And
> you cannot make sure there isn't no one using them in other closed projects,
> right?
> If you removed now, that obviously will break her implementation and brings
> her many troubles.
> 
> 
> Regards,
> David Zhou
> >
> >Signed-off-by: Christian KÃ¶nig 
> >---
> >  drivers/gpu/drm/ttm/ttm_bo.c|  2 +-
> >  include/drm/ttm/ttm_placement.h | 19 ---
> >  2 files changed, 1 insertion(+), 20 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> >index bc37f02..4d2e8f2 100644
> >--- a/drivers/gpu/drm/ttm/ttm_bo.c
> >+++ b/drivers/gpu/drm/ttm/ttm_bo.c
> >@@ -59,7 +59,7 @@ static inline int ttm_mem_type_from_place(const struct 
> >ttm_place *place,
> >  {
> > int i;
> >-for (i = 0; i <= TTM_PL_PRIV5; i++)
> >+for (i = 0; i <= TTM_PL_PRIV2; i++)
> > if (place->flags & (1 << i)) {
> > *mem_type = i;
> > return 0;
> >diff --git a/include/drm/ttm/ttm_placement.h 
> >b/include/drm/ttm/ttm_placement.h
> >index 8ed44f9..20219d9 100644
> >--- a/include/drm/ttm/ttm_placement.h
> >+++ b/include/drm/ttm/ttm_placement.h
> >@@ -40,10 +40,6 @@
> >  #define TTM_PL_PRIV03
> >  #define TTM_PL_PRIV14
> >  #define TTM_PL_PRIV25
> >-#define TTM_PL_PRIV36
> >-#define TTM_PL_PRIV47
> >-#define TTM_PL_PRIV58
> >-#define TTM_PL_SWAPPED  15
> >  #define TTM_PL_FLAG_SYSTEM  (1 << TTM_PL_SYSTEM)
> >  #define TTM_PL_FLAG_TT  (1 << TTM_PL_TT)
> >@@ -51,10 +47,6 @@
> >  #define TTM_PL_FLAG_PRIV0   (1 << TTM_PL_PRIV0)
> >  #define TTM_PL_FLAG_PRIV1   (1 << TTM_PL_PRIV1)
> >  #define TTM_PL_FLAG_PRIV2   (1 << TTM_PL_PRIV2)
> >-#define TTM_PL_FLAG_PRIV3   (1 << TTM_PL_PRIV3)
> >-#define TTM_PL_FLAG_PRIV4   (1 << TTM_PL_PRIV4)
> >-#define TTM_PL_FLAG_PRIV5   (1 << TTM_PL_PRIV5)
> >-#define TTM_PL_FLAG_SWAPPED (1 << TTM_PL_SWAPPED)
> >  #define TTM_PL_MASK_MEM 0x
> >  /*
> >@@ -72,7 +64,6 @@
> >  #define TTM_PL_FLAG_CACHED  (1 << 16)
> >  #define TTM_PL_FLAG_UNCACHED(1 << 17)
> >  #define TTM_PL_FLAG_WC  (1 << 18)
> >-#define TTM_PL_FLAG_SHARED  (1 << 20)
> >  #define TTM_PL_FLAG_NO_EVICT(1 << 21)
> >  #define TTM_PL_FLAG_TOPDOWN (1 << 22)
> >@@ -82,14 +73,4 @@
> >  #define TTM_PL_MASK_MEMTYPE (TTM_PL_MASK_MEM | TTM_PL_MASK_CACHING)
> >-/*
> >- * Access flags to be used for CPU- and GPU- mappings.
> >- * The idea is that the TTM synchronization mechanism will
> >- * allow concurrent READ access and exclusive write access.
> >- * Currently GPU- and CPU accesses are exclusive.
> >- */
> >-
> >-#define TTM_ACCESS_READ (1 << 0)
> >-#define TTM_ACCESS_WRITE(1 << 1)
> >-
> >  #endif
> 
> ___
> amd-gfx mailing list
> amd-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 1/2] drm/ttm: remove unused placement flags

2016-09-09 Thread Emil Velikov

On 9 September 2016 at 12:24, Christian KÃ¶nig  
wrote:
> Hi Hawking,
>
>> Removing the flag will make ttm_mem_type_from_place skip counting the
>> corresponding placement and thus have impact on mem region create and bo
>> movement.
>
> And that is exactly the reason why I want to remove the unused flags.
>
>> There is no guarantee that amdgpu would never introduce new memory domain
>> in future.
>
> Irrelevant, if any driver wants to use additional domains it should add them
> when they are used.
>
> BTW: Why would we want to add another TTM domain? I really don't see any
> need for that.
>
>> Then how about keep these flags?
>
> Actually we used to have automated scanners which complain about unused
> code. I'm wondering why they don't detected that earlier.
>
> Anyway any code which isn't used in a while should be removed.
>
Fwiw I second Christian here. If they are unused in open-source
drivers there's no reason to keep them.
If/as that changes the (newly introduced) user can add back the relevant code.

If closed-source driver(s) use them, then they can keep it as part of
their blob. Upstream kernel does not cater for closed-source drivers,
period.
I realise that's not the answer some are hoping for, so if you want to
question it take it up with Linus and co.

Regards,
Emil

[PATCH 2/2] drm/ttm: move placement structures into ttm_placement.h

2016-09-09 Thread zhoucm1



On 2016å¹´09æ08æ¥ 21:41, Christian KÃ¶nig wrote:
> From: Christian KÃ¶nig 
>
> Makes more sense to keep that together.
>
> Signed-off-by: Christian KÃ¶nig 
Reviewed-by: Chunming Zhou 
> ---
>   include/drm/ttm/ttm_bo_api.h| 32 +---
>   include/drm/ttm/ttm_placement.h | 35 +++
>   2 files changed, 36 insertions(+), 31 deletions(-)
>
> diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
> index 97aaf5c..d73c7c2 100644
> --- a/include/drm/ttm/ttm_bo_api.h
> +++ b/include/drm/ttm/ttm_bo_api.h
> @@ -45,37 +45,7 @@ struct ttm_bo_device;
>   
>   struct drm_mm_node;
>   
> -/**
> - * struct ttm_place
> - *
> - * @fpfn:first valid page frame number to put the object
> - * @lpfn:last valid page frame number to put the object
> - * @flags:   memory domain and caching flags for the object
> - *
> - * Structure indicating a possible place to put an object.
> - */
> -struct ttm_place {
> - unsignedfpfn;
> - unsignedlpfn;
> - uint32_tflags;
> -};
> -
> -/**
> - * struct ttm_placement
> - *
> - * @num_placement:   number of preferred placements
> - * @placement:   preferred placements
> - * @num_busy_placement:  number of preferred placements when need to 
> evict buffer
> - * @busy_placement:  preferred placements when need to evict buffer
> - *
> - * Structure indicating the placement you request for an object.
> - */
> -struct ttm_placement {
> - unsignednum_placement;
> - const struct ttm_place  *placement;
> - unsignednum_busy_placement;
> - const struct ttm_place  *busy_placement;
> -};
> +struct ttm_placement;
>   
>   /**
>* struct ttm_bus_placement
> diff --git a/include/drm/ttm/ttm_placement.h b/include/drm/ttm/ttm_placement.h
> index 20219d9..ff5195c 100644
> --- a/include/drm/ttm/ttm_placement.h
> +++ b/include/drm/ttm/ttm_placement.h
> @@ -30,6 +30,9 @@
>   
>   #ifndef _TTM_PLACEMENT_H_
>   #define _TTM_PLACEMENT_H_
> +
> +#include 
> +
>   /*
>* Memory regions for data placement.
>*/
> @@ -73,4 +76,36 @@
>   
>   #define TTM_PL_MASK_MEMTYPE (TTM_PL_MASK_MEM | TTM_PL_MASK_CACHING)
>   
> +/**
> + * struct ttm_place
> + *
> + * @fpfn:first valid page frame number to put the object
> + * @lpfn:last valid page frame number to put the object
> + * @flags:   memory domain and caching flags for the object
> + *
> + * Structure indicating a possible place to put an object.
> + */
> +struct ttm_place {
> + unsignedfpfn;
> + unsignedlpfn;
> + uint32_tflags;
> +};
> +
> +/**
> + * struct ttm_placement
> + *
> + * @num_placement:   number of preferred placements
> + * @placement:   preferred placements
> + * @num_busy_placement:  number of preferred placements when need to 
> evict buffer
> + * @busy_placement:  preferred placements when need to evict buffer
> + *
> + * Structure indicating the placement you request for an object.
> + */
> +struct ttm_placement {
> + unsignednum_placement;
> + const struct ttm_place  *placement;
> + unsignednum_busy_placement;
> + const struct ttm_place  *busy_placement;
> +};
> +
>   #endif

[PATCH 1/2] drm/ttm: remove unused placement flags

2016-09-09 Thread zhoucm1



On 2016å¹´09æ08æ¥ 21:41, Christian KÃ¶nig wrote:
> From: Christian KÃ¶nig 
>
> Either never used or not used in quite a while.
No, I remember Flora's Direct GMA is using them like GDS use PRIV0-2. 
And you cannot make sure there isn't no one using them in other closed 
projects, right?
If you removed now, that obviously will break her implementation and 
brings  her many troubles.


Regards,
David Zhou
>
> Signed-off-by: Christian KÃ¶nig 
> ---
>   drivers/gpu/drm/ttm/ttm_bo.c|  2 +-
>   include/drm/ttm/ttm_placement.h | 19 ---
>   2 files changed, 1 insertion(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index bc37f02..4d2e8f2 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -59,7 +59,7 @@ static inline int ttm_mem_type_from_place(const struct 
> ttm_place *place,
>   {
>   int i;
>   
> - for (i = 0; i <= TTM_PL_PRIV5; i++)
> + for (i = 0; i <= TTM_PL_PRIV2; i++)
>   if (place->flags & (1 << i)) {
>   *mem_type = i;
>   return 0;
> diff --git a/include/drm/ttm/ttm_placement.h b/include/drm/ttm/ttm_placement.h
> index 8ed44f9..20219d9 100644
> --- a/include/drm/ttm/ttm_placement.h
> +++ b/include/drm/ttm/ttm_placement.h
> @@ -40,10 +40,6 @@
>   #define TTM_PL_PRIV03
>   #define TTM_PL_PRIV14
>   #define TTM_PL_PRIV25
> -#define TTM_PL_PRIV36
> -#define TTM_PL_PRIV47
> -#define TTM_PL_PRIV58
> -#define TTM_PL_SWAPPED  15
>   
>   #define TTM_PL_FLAG_SYSTEM  (1 << TTM_PL_SYSTEM)
>   #define TTM_PL_FLAG_TT  (1 << TTM_PL_TT)
> @@ -51,10 +47,6 @@
>   #define TTM_PL_FLAG_PRIV0   (1 << TTM_PL_PRIV0)
>   #define TTM_PL_FLAG_PRIV1   (1 << TTM_PL_PRIV1)
>   #define TTM_PL_FLAG_PRIV2   (1 << TTM_PL_PRIV2)
> -#define TTM_PL_FLAG_PRIV3   (1 << TTM_PL_PRIV3)
> -#define TTM_PL_FLAG_PRIV4   (1 << TTM_PL_PRIV4)
> -#define TTM_PL_FLAG_PRIV5   (1 << TTM_PL_PRIV5)
> -#define TTM_PL_FLAG_SWAPPED (1 << TTM_PL_SWAPPED)
>   #define TTM_PL_MASK_MEM 0x
>   
>   /*
> @@ -72,7 +64,6 @@
>   #define TTM_PL_FLAG_CACHED  (1 << 16)
>   #define TTM_PL_FLAG_UNCACHED(1 << 17)
>   #define TTM_PL_FLAG_WC  (1 << 18)
> -#define TTM_PL_FLAG_SHARED  (1 << 20)
>   #define TTM_PL_FLAG_NO_EVICT(1 << 21)
>   #define TTM_PL_FLAG_TOPDOWN (1 << 22)
>   
> @@ -82,14 +73,4 @@
>   
>   #define TTM_PL_MASK_MEMTYPE (TTM_PL_MASK_MEM | TTM_PL_MASK_CACHING)
>   
> -/*
> - * Access flags to be used for CPU- and GPU- mappings.
> - * The idea is that the TTM synchronization mechanism will
> - * allow concurrent READ access and exclusive write access.
> - * Currently GPU- and CPU accesses are exclusive.
> - */
> -
> -#define TTM_ACCESS_READ (1 << 0)
> -#define TTM_ACCESS_WRITE(1 << 1)
> -
>   #endif

[Bug 119831] "nomodeset" required to boot - MSI laptop G72 6QE, nouveau graphics

2016-09-09 Thread bugzilla-dae...@bugzilla.kernel.org

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

Peter Wu  changed:

   What|Removed |Added

 CC||peter at lekensteyn.nl

--- Comment #15 from Peter Wu  ---
The lockup issue was reported for a similar model (MSI GE62 6QE) in Bug 156341.
To workaround that issue on that specific machine, he had to boot with:

 acpi_osi=! acpi_osi="Windows 2009"

Sam, can you upload the tarball (with acpidump and others) according to
https://bugs.launchpad.net/lpbugreporter/+bug/752542?

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

[PATCH v9 12/12] drm/i915: Check TMDS clock DP to HDMI dongle

2016-09-09 Thread Mika Kahola

Respect max TMDS clock frequency from DPCD for active
DP to HDMI adapters.

Reviewed-by: Jim Bride 
Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/i915/intel_drv.h  |  3 +++
 drivers/gpu/drm/i915/intel_hdmi.c | 27 +++
 2 files changed, 30 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 7868d5c..16374a1 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -823,6 +823,9 @@ struct intel_hdmi {
i915_reg_t hdmi_reg;
int ddc_bus;
struct {
+   int max_tmds_clock;
+   } dp_to_hdmi;
+   struct {
enum drm_dp_dual_mode_type type;
int max_tmds_clock;
} dp_dual_mode;
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index c51073f..1066114 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1220,6 +1220,9 @@ static int hdmi_port_clock_limit(struct intel_hdmi *hdmi,
int max_tmds_clock = intel_hdmi_source_max_tmds_clock(to_i915(dev));

if (respect_downstream_limits) {
+   if (hdmi->dp_to_hdmi.max_tmds_clock)
+   max_tmds_clock = min(max_tmds_clock,
+hdmi->dp_to_hdmi.max_tmds_clock);
if (hdmi->dp_dual_mode.max_tmds_clock)
max_tmds_clock = min(max_tmds_clock,
 hdmi->dp_dual_mode.max_tmds_clock);
@@ -1390,11 +1393,33 @@ intel_hdmi_unset_edid(struct drm_connector *connector)
intel_hdmi->dp_dual_mode.type = DRM_DP_DUAL_MODE_NONE;
intel_hdmi->dp_dual_mode.max_tmds_clock = 0;

+   intel_hdmi->dp_to_hdmi.max_tmds_clock = 0;
+
kfree(to_intel_connector(connector)->detect_edid);
to_intel_connector(connector)->detect_edid = NULL;
 }

 static void
+intel_hdmi_dp_adapter_detect(struct drm_connector *connector)
+{
+   struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
+   struct intel_digital_port *intel_dig_port =
+   hdmi_to_dig_port(intel_hdmi);
+   struct intel_dp *intel_dp = _dig_port->dp;
+   int type = intel_dp->downstream_ports[0] & DP_DS_PORT_TYPE_MASK;
+
+   if (type != DP_DS_PORT_TYPE_HDMI)
+   return;
+
+   intel_hdmi->dp_to_hdmi.max_tmds_clock =
+   drm_dp_downstream_max_clock(intel_dp->dpcd,
+   intel_dp->downstream_ports);
+
+   DRM_DEBUG_KMS("DP HDMI adaptor detected (max TMDS clock : %d kHz\n",
+ intel_hdmi->dp_to_hdmi.max_tmds_clock);
+}
+
+static void
 intel_hdmi_dp_dual_mode_detect(struct drm_connector *connector, bool has_edid)
 {
struct drm_i915_private *dev_priv = to_i915(connector->dev);
@@ -1454,6 +1479,8 @@ intel_hdmi_set_edid(struct drm_connector *connector)

intel_hdmi_dp_dual_mode_detect(connector, edid != NULL);

+   intel_hdmi_dp_adapter_detect(connector);
+
intel_display_power_put(dev_priv, POWER_DOMAIN_GMBUS);

to_intel_connector(connector)->detect_edid = edid;
-- 
2.7.4

[PATCH v9 11/12] drm: Add DP branch device info on debugfs

2016-09-09 Thread Mika Kahola

Read DisplayPort branch device info from through debugfs
interface.

v2: use drm_dp_helper routines to collect data
v3: cleanup to match the drm_dp_helper.c patches introduced
earlier in this series
v4: move DP branch device info to function 'intel_dp_branch_device_info()'
v5: initial step to move debugging info from intel_dp. to drm_dp_helper.c 
(Daniel)
v6: read hw and sw revision without using specific drm_dp_helper routines
v7: indentation fixes (Jim Bride)

Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/drm_dp_helper.c | 85 +
 drivers/gpu/drm/i915/i915_debugfs.c |  3 ++
 include/drm/drm_dp_helper.h |  2 +
 3 files changed, 90 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 01ee7af..a536514 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -526,6 +526,91 @@ int drm_dp_downstream_id(struct drm_dp_aux *aux, char 
id[6])
 }
 EXPORT_SYMBOL(drm_dp_downstream_id);

+/**
+ * drm_dp_downstream_debug() - debug DP branch devices
+ * @m: pointer for debugfs file
+ * @dpcd: DisplayPort configuration data
+ * @port_cap: port capabilities
+ * @aux: DisplayPort AUX channel
+ *
+ */
+void drm_dp_downstream_debug(struct seq_file *m,
+const u8 dpcd[DP_RECEIVER_CAP_SIZE],
+const u8 port_cap[4], struct drm_dp_aux *aux)
+{
+   bool detailed_cap_info = dpcd[DP_DOWNSTREAMPORT_PRESENT] &
+DP_DETAILED_CAP_INFO_AVAILABLE;
+   int clk;
+   int bpc;
+   char id[6];
+   int len;
+   uint8_t rev[2];
+   int type = port_cap[0] & DP_DS_PORT_TYPE_MASK;
+   bool branch_device = dpcd[DP_DOWNSTREAMPORT_PRESENT] &
+DP_DWN_STRM_PORT_PRESENT;
+
+   seq_printf(m, "\tDP branch device present: %s\n",
+  branch_device ? "yes" : "no");
+
+   if (!branch_device)
+   return;
+
+   switch (type) {
+   case DP_DS_PORT_TYPE_DP:
+   seq_puts(m, "\t\tType: DisplayPort\n");
+   break;
+   case DP_DS_PORT_TYPE_VGA:
+   seq_puts(m, "\t\tType: VGA\n");
+   break;
+   case DP_DS_PORT_TYPE_DVI:
+   seq_puts(m, "\t\tType: DVI\n");
+   break;
+   case DP_DS_PORT_TYPE_HDMI:
+   seq_puts(m, "\t\tType: HDMI\n");
+   break;
+   case DP_DS_PORT_TYPE_NON_EDID:
+   seq_puts(m, "\t\tType: others without EDID support\n");
+   break;
+   case DP_DS_PORT_TYPE_DP_DUALMODE:
+   seq_puts(m, "\t\tType: DP++\n");
+   break;
+   case DP_DS_PORT_TYPE_WIRELESS:
+   seq_puts(m, "\t\tType: Wireless\n");
+   break;
+   default:
+   seq_puts(m, "\t\tType: N/A\n");
+   }
+
+   drm_dp_downstream_id(aux, id);
+   seq_printf(m, "\t\tID: %s\n", id);
+
+   len = drm_dp_dpcd_read(aux, DP_BRANCH_HW_REV, [0], 1);
+   if (len > 0)
+   seq_printf(m, "\t\tHW: %d.%d\n",
+  (rev[0] & 0xf0) >> 4, rev[0] & 0xf);
+
+   len = drm_dp_dpcd_read(aux, DP_BRANCH_SW_REV, , 2);
+   if (len > 0)
+   seq_printf(m, "\t\tSW: %d.%d\n", rev[0], rev[1]);
+
+   if (detailed_cap_info) {
+   clk = drm_dp_downstream_max_clock(dpcd, port_cap);
+
+   if (clk > 0) {
+   if (type == DP_DS_PORT_TYPE_VGA)
+   seq_printf(m, "\t\tMax dot clock: %d kHz\n", 
clk);
+   else
+   seq_printf(m, "\t\tMax TMDS clock: %d kHz\n", 
clk);
+   }
+
+   bpc = drm_dp_downstream_max_bpc(dpcd, port_cap);
+
+   if (bpc > 0)
+   seq_printf(m, "\t\tMax bpc: %d\n", bpc);
+   }
+}
+EXPORT_SYMBOL(drm_dp_downstream_debug);
+
 /*
  * I2C-over-AUX implementation
  */
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 02b627e..44fab14 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2851,6 +2851,9 @@ static void intel_dp_info(struct seq_file *m,
seq_printf(m, "\taudio support: %s\n", yesno(intel_dp->has_audio));
if (intel_connector->base.connector_type == DRM_MODE_CONNECTOR_eDP)
intel_panel_info(m, _connector->panel);
+
+   drm_dp_downstream_debug(m, intel_dp->dpcd, intel_dp->downstream_ports,
+   _dp->aux);
 }

 static void intel_hdmi_info(struct seq_file *m,
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 215202f..2a79882 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -823,6 +823,8 @@ int drm_dp_downstream_max_clock(const u8 
dpcd[DP_RECEIVER_CAP_SIZE],
 int drm_dp_downstream_max_bpc(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
  const

[PATCH v9 10/12] drm/i915: Update bits per component for display info

2016-09-09 Thread Mika Kahola

DisplayPort branch device may define max supported bits per
component. Update display info based on this value if bpc
is defined.

v2: cleanup to match the drm_dp_helper.c patches introduced
earlier in this series
v3: Fill bpc for connector's display info in separate
drm_dp_helper function (Daniel)
v4: remove updating bpc for display info as it may be overridden
when parsing EDID. Instead, check bpc for DP branch device
during compute_config
v5: Indentation fixes (Jim Bride)

Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/i915/intel_dp.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 8f17c88..69cee9b 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1524,6 +1524,20 @@ void intel_dp_compute_rate(struct intel_dp *intel_dp, 
int port_clock,
}
 }

+int intel_dp_compute_bpp(struct intel_dp *intel_dp,
+struct intel_crtc_state *pipe_config)
+{
+   int bpp, bpc;
+
+   bpp = pipe_config->pipe_bpp;
+   bpc = drm_dp_downstream_max_bpc(intel_dp->dpcd, 
intel_dp->downstream_ports);
+
+   if (bpc > 0)
+   bpp = min(bpp, 3*bpc);
+
+   return bpp;
+}
+
 bool
 intel_dp_compute_config(struct intel_encoder *encoder,
struct intel_crtc_state *pipe_config,
@@ -1590,7 +1604,7 @@ intel_dp_compute_config(struct intel_encoder *encoder,

/* Walk through all bpp values. Luckily they're all nicely spaced with 2
 * bpc in between. */
-   bpp = pipe_config->pipe_bpp;
+   bpp = intel_dp_compute_bpp(intel_dp, pipe_config);
if (is_edp(intel_dp)) {

/* Get bpp from vbt only for panels that dont have bpp in edid 
*/
-- 
2.7.4

[PATCH v9 09/12] drm/i915: Check pixel rate for DP to VGA dongle

2016-09-09 Thread Mika Kahola

Filter out a mode that exceeds the max pixel rate setting
for DP to VGA dongle. This is defined in DPCD register 0x81
if detailed cap info i.e. info field is 4 bytes long and
it is available for DP downstream port.

The register defines the pixel rate divided by 8 in MP/s.

v2: DPCD read outs and computation moved to drm (Ville, Daniel)
v3: Sink pixel rate computation moved to drm_dp_max_sink_dotclock()
function (Daniel)
v4: Use of drm_dp_helper.c routines to compute max pixel clock (Ville)
v5: Use of intel_dp->downstream_ports to read out port capabilities.
Code restructuring (Ville)
v6: Move DP branch device check to drm_dp_helper.c (Daniel)
v7: Cleanup as suggested by Ville

Reviewed-by: Jim Bride 
Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/i915/intel_dp.c | 27 ++-
 1 file changed, 26 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 7428c72..8f17c88 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -190,6 +190,29 @@ intel_dp_max_data_rate(int max_link_clock, int max_lanes)
return (max_link_clock * max_lanes * 8) / 10;
 }

+static int
+intel_dp_downstream_max_dotclock(struct intel_dp *intel_dp)
+{
+   struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+   struct intel_encoder *encoder = _dig_port->base;
+   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+   int max_dotclk = dev_priv->max_dotclk_freq;
+   int ds_max_dotclk;
+
+   int type = intel_dp->downstream_ports[0] & DP_DS_PORT_TYPE_MASK;
+
+   if (type != DP_DS_PORT_TYPE_VGA)
+   return max_dotclk;
+
+   ds_max_dotclk = drm_dp_downstream_max_clock(intel_dp->dpcd,
+   intel_dp->downstream_ports);
+
+   if (ds_max_dotclk != 0)
+   max_dotclk = min(max_dotclk, ds_max_dotclk);
+
+   return max_dotclk;
+}
+
 static enum drm_mode_status
 intel_dp_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode)
@@ -199,7 +222,9 @@ intel_dp_mode_valid(struct drm_connector *connector,
struct drm_display_mode *fixed_mode = intel_connector->panel.fixed_mode;
int target_clock = mode->clock;
int max_rate, mode_rate, max_lanes, max_link_clock;
-   int max_dotclk = to_i915(connector->dev)->max_dotclk_freq;
+   int max_dotclk;
+
+   max_dotclk = intel_dp_downstream_max_dotclock(intel_dp);

if (is_edp(intel_dp) && fixed_mode) {
if (mode->hdisplay > fixed_mode->hdisplay)
-- 
2.7.4

[PATCH v9 08/12] drm/i915: Read DP branch device SW revision

2016-09-09 Thread Mika Kahola

SW revision is mandatory field for DisplayPort branch
devices. This is defined in DPCD register fields 0x50A
and 0x50B.

v2: move drm_dp_ds_revision structure to be part of
drm_dp_link structure (Daniel)
v3: remove dependency to drm_dp_helper but instead parse
DPCD and print SW revision info to dmesg (Ville)
v4: commit message fix (Jim Bride)

Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/i915/intel_dp.c | 20 
 include/drm/drm_dp_helper.h |  1 +
 2 files changed, 21 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index bb0417c..7428c72 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1438,6 +1438,25 @@ static void intel_dp_print_hw_revision(struct intel_dp 
*intel_dp)
DRM_DEBUG_KMS("sink hw revision: %d.%d\n", (rev & 0xf0) >> 4, rev & 
0xf);
 }

+static void intel_dp_print_sw_revision(struct intel_dp *intel_dp)
+{
+   uint8_t rev[2];
+   int len;
+
+   if ((drm_debug & DRM_UT_KMS) == 0)
+   return;
+
+   if (!(intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] &
+ DP_DWN_STRM_PORT_PRESENT))
+   return;
+
+   len = drm_dp_dpcd_read(_dp->aux, DP_BRANCH_SW_REV, , 2);
+   if (len < 0)
+   return;
+
+   DRM_DEBUG_KMS("sink sw revision: %d.%d\n", rev[0], rev[1]);
+}
+
 static int rate_to_index(int find, const int *rates)
 {
int i = 0;
@@ -4332,6 +4351,7 @@ intel_dp_long_pulse(struct intel_connector 
*intel_connector)
intel_dp_probe_oui(intel_dp);

intel_dp_print_hw_revision(intel_dp);
+   intel_dp_print_sw_revision(intel_dp);

intel_dp_configure_mst(intel_dp);

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 19ac599..215202f 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -447,6 +447,7 @@
 #define DP_BRANCH_OUI  0x500
 #define DP_BRANCH_ID0x503
 #define DP_BRANCH_HW_REV0x509
+#define DP_BRANCH_SW_REV0x50A

 #define DP_SET_POWER0x600
 # define DP_SET_POWER_D00x1
-- 
2.7.4

[PATCH v9 07/12] drm/i915: Read DP branch device HW revision

2016-09-09 Thread Mika Kahola

HW revision is mandatory field for DisplayPort branch
devices. This is defined in DPCD register field 0x509.

v2: move drm_dp_ds_revision structure to be part of
drm_dp_link structure (Daniel)
v3: remove dependency to drm_dp_helper but instead parse
DPCD and print HW revision info to dmesg (Ville)

Reviewed-by: Jim Bride 
Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/i915/intel_dp.c | 21 +
 include/drm/drm_dp_helper.h |  1 +
 2 files changed, 22 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index c69ad13..bb0417c 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1419,6 +1419,25 @@ static void intel_dp_print_rates(struct intel_dp 
*intel_dp)
DRM_DEBUG_KMS("common rates: %s\n", str);
 }

+static void intel_dp_print_hw_revision(struct intel_dp *intel_dp)
+{
+   uint8_t rev;
+   int len;
+
+   if ((drm_debug & DRM_UT_KMS) == 0)
+   return;
+
+   if (!(intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] &
+ DP_DWN_STRM_PORT_PRESENT))
+   return;
+
+   len = drm_dp_dpcd_read(_dp->aux, DP_BRANCH_HW_REV, , 1);
+   if (len < 0)
+   return;
+
+   DRM_DEBUG_KMS("sink hw revision: %d.%d\n", (rev & 0xf0) >> 4, rev & 
0xf);
+}
+
 static int rate_to_index(int find, const int *rates)
 {
int i = 0;
@@ -4312,6 +4331,8 @@ intel_dp_long_pulse(struct intel_connector 
*intel_connector)

intel_dp_probe_oui(intel_dp);

+   intel_dp_print_hw_revision(intel_dp);
+
intel_dp_configure_mst(intel_dp);

if (intel_dp->is_mst) {
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index faea76b..19ac599 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -446,6 +446,7 @@
 #define DP_SINK_OUI0x400
 #define DP_BRANCH_OUI  0x500
 #define DP_BRANCH_ID0x503
+#define DP_BRANCH_HW_REV0x509

 #define DP_SET_POWER0x600
 # define DP_SET_POWER_D00x1
-- 
2.7.4

[PATCH v9 06/12] drm/i915: Cleanup DisplayPort AUX channel initialization

2016-09-09 Thread Mika Kahola

Let's remove reference to "struct intel_connector *connector"
in intel_dp_aux_init() function as it is no longer required.

Reviewed-by: Jim Bride 
Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/i915/intel_dp.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 75ac62f..c69ad13 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1243,7 +1243,7 @@ intel_dp_aux_fini(struct intel_dp *intel_dp)
 }

 static void
-intel_dp_aux_init(struct intel_dp *intel_dp, struct intel_connector *connector)
+intel_dp_aux_init(struct intel_dp *intel_dp)
 {
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
enum port port = intel_dig_port->port;
@@ -5624,7 +5624,7 @@ intel_dp_init_connector(struct intel_digital_port 
*intel_dig_port,
connector->interlace_allowed = true;
connector->doublescan_allowed = 0;

-   intel_dp_aux_init(intel_dp, intel_connector);
+   intel_dp_aux_init(intel_dp);

INIT_DELAYED_WORK(_dp->panel_vdd_work,
  edp_panel_vdd_work);
-- 
2.7.4

[PATCH v9 05/12] drm: Read DP branch device id

2016-09-09 Thread Mika Kahola

Read DisplayPort branch device id string.

Reviewed-by: Jim Bride 
Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/drm_dp_helper.c | 12 
 include/drm/drm_dp_helper.h |  2 ++
 2 files changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 14e8ea0..01ee7af 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -514,6 +514,18 @@ int drm_dp_downstream_max_bpc(const u8 
dpcd[DP_RECEIVER_CAP_SIZE],
 }
 EXPORT_SYMBOL(drm_dp_downstream_max_bpc);

+/**
+ * drm_dp_downstream_id() - identify branch device
+ * @aux: DisplayPort AUX channel
+ *
+ * Returns branch device id on success or NULL on failure
+ */
+int drm_dp_downstream_id(struct drm_dp_aux *aux, char id[6])
+{
+   return drm_dp_dpcd_read(aux, DP_BRANCH_ID, id, 6);
+}
+EXPORT_SYMBOL(drm_dp_downstream_id);
+
 /*
  * I2C-over-AUX implementation
  */
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index f3d1424..faea76b 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -445,6 +445,7 @@
 #define DP_SOURCE_OUI  0x300
 #define DP_SINK_OUI0x400
 #define DP_BRANCH_OUI  0x500
+#define DP_BRANCH_ID0x503

 #define DP_SET_POWER0x600
 # define DP_SET_POWER_D00x1
@@ -819,6 +820,7 @@ int drm_dp_downstream_max_clock(const u8 
dpcd[DP_RECEIVER_CAP_SIZE],
const u8 port_cap[4]);
 int drm_dp_downstream_max_bpc(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
  const u8 port_cap[4]);
+int drm_dp_downstream_id(struct drm_dp_aux *aux, char id[6]);

 void drm_dp_aux_init(struct drm_dp_aux *aux);
 int drm_dp_aux_register(struct drm_dp_aux *aux);
-- 
2.7.4

[PATCH v9 04/12] drm: Helper to read max bits per component

2016-09-09 Thread Mika Kahola

Helper routine to read out maximum supported bits per
component for DisplayPort legay converters.

v2: Return early if detailed port cap info is not available.
Replace if-else ladder with switch-case (Ville)

Reviewed-by: Jim Bride 
Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/drm_dp_helper.c | 42 +
 include/drm/drm_dp_helper.h |  2 ++
 2 files changed, 44 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 7497490..14e8ea0 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -472,6 +472,48 @@ int drm_dp_downstream_max_clock(const u8 
dpcd[DP_RECEIVER_CAP_SIZE],
 }
 EXPORT_SYMBOL(drm_dp_downstream_max_clock);

+/**
+ * drm_dp_downstream_max_bpc() - extract branch device max
+ *   bits per component
+ * @dpcd: DisplayPort configuration data
+ * @port_cap: port capabilities
+ *
+ * Returns max bpc on success or 0 if max bpc not defined
+ */
+int drm_dp_downstream_max_bpc(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
+ const u8 port_cap[4])
+{
+   int type = port_cap[0] & DP_DS_PORT_TYPE_MASK;
+   bool detailed_cap_info = dpcd[DP_DOWNSTREAMPORT_PRESENT] &
+   DP_DETAILED_CAP_INFO_AVAILABLE;
+   int bpc;
+
+   if (!detailed_cap_info)
+   return 0;
+
+   switch (type) {
+   case DP_DS_PORT_TYPE_VGA:
+   case DP_DS_PORT_TYPE_DVI:
+   case DP_DS_PORT_TYPE_HDMI:
+   case DP_DS_PORT_TYPE_DP_DUALMODE:
+   bpc = port_cap[2] & DP_DS_MAX_BPC_MASK;
+
+   switch (bpc) {
+   case DP_DS_8BPC:
+   return 8;
+   case DP_DS_10BPC:
+   return 10;
+   case DP_DS_12BPC:
+   return 12;
+   case DP_DS_16BPC:
+   return 16;
+   }
+   default:
+   return 0;
+   }
+}
+EXPORT_SYMBOL(drm_dp_downstream_max_bpc);
+
 /*
  * I2C-over-AUX implementation
  */
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 60dd9dc..f3d1424 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -817,6 +817,8 @@ int drm_dp_link_power_down(struct drm_dp_aux *aux, struct 
drm_dp_link *link);
 int drm_dp_link_configure(struct drm_dp_aux *aux, struct drm_dp_link *link);
 int drm_dp_downstream_max_clock(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
const u8 port_cap[4]);
+int drm_dp_downstream_max_bpc(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
+ const u8 port_cap[4]);

 void drm_dp_aux_init(struct drm_dp_aux *aux);
 int drm_dp_aux_register(struct drm_dp_aux *aux);
-- 
2.7.4

[PATCH v9 03/12] drm: Helper to read max clock rate

2016-09-09 Thread Mika Kahola

Helper routine to read out maximum supported pixel rate
for DisplayPort legay VGA converter or TMDS clock rate
for other digital legacy converters. The helper returns
clock rate in kHz.

v2: Return early if detailed port cap info is not available.
Replace if-else ladder with switch-case (Ville)

Reviewed-by: Jim Bride 
Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/drm_dp_helper.c | 33 +
 include/drm/drm_dp_helper.h |  2 ++
 2 files changed, 35 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 031c4d3..7497490 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -439,6 +439,39 @@ int drm_dp_link_configure(struct drm_dp_aux *aux, struct 
drm_dp_link *link)
 }
 EXPORT_SYMBOL(drm_dp_link_configure);

+/**
+ * drm_dp_downstream_max_clock() - extract branch device max
+ * pixel rate for legacy VGA
+ * converter or max TMDS clock
+ * rate for others
+ * @dpcd: DisplayPort configuration data
+ * @port_cap: port capabilities
+ *
+ * Returns max clock in kHz on success or 0 if max clock not defined
+ */
+int drm_dp_downstream_max_clock(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
+   const u8 port_cap[4])
+{
+   int type = port_cap[0] & DP_DS_PORT_TYPE_MASK;
+   bool detailed_cap_info = dpcd[DP_DOWNSTREAMPORT_PRESENT] &
+   DP_DETAILED_CAP_INFO_AVAILABLE;
+
+   if (!detailed_cap_info)
+   return 0;
+
+   switch (type) {
+   case DP_DS_PORT_TYPE_VGA:
+   return port_cap[1] * 8 * 1000;
+   case DP_DS_PORT_TYPE_DVI:
+   case DP_DS_PORT_TYPE_HDMI:
+   case DP_DS_PORT_TYPE_DP_DUALMODE:
+   return port_cap[1] * 2500;
+   default:
+   return 0;
+   }
+}
+EXPORT_SYMBOL(drm_dp_downstream_max_clock);
+
 /*
  * I2C-over-AUX implementation
  */
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 0d84046..60dd9dc 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -815,6 +815,8 @@ int drm_dp_link_probe(struct drm_dp_aux *aux, struct 
drm_dp_link *link);
 int drm_dp_link_power_up(struct drm_dp_aux *aux, struct drm_dp_link *link);
 int drm_dp_link_power_down(struct drm_dp_aux *aux, struct drm_dp_link *link);
 int drm_dp_link_configure(struct drm_dp_aux *aux, struct drm_dp_link *link);
+int drm_dp_downstream_max_clock(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
+   const u8 port_cap[4]);

 void drm_dp_aux_init(struct drm_dp_aux *aux);
 int drm_dp_aux_register(struct drm_dp_aux *aux);
-- 
2.7.4

[PATCH v9 02/12] drm: Drop VGA from bpc definitions

2016-09-09 Thread Mika Kahola

Drop "VGA" from bits per component definitions as these
are also used by other standards such as DVI, HDMI,
DP++.

Reviewed-by: Jim Bride 
Signed-off-by: Mika Kahola 
---
 include/drm/drm_dp_helper.h | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index ba9731e..0d84046 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -216,11 +216,11 @@
 # define DP_DS_PORT_HPD(1 << 3)
 /* offset 1 for VGA is maximum megapixels per second / 8 */
 /* offset 2 */
-# define DP_DS_VGA_MAX_BPC_MASK(3 << 0)
-# define DP_DS_VGA_8BPC0
-# define DP_DS_VGA_10BPC   1
-# define DP_DS_VGA_12BPC   2
-# define DP_DS_VGA_16BPC   3
+# define DP_DS_MAX_BPC_MASK(3 << 0)
+# define DP_DS_8BPC0
+# define DP_DS_10BPC   1
+# define DP_DS_12BPC   2
+# define DP_DS_16BPC   3

 /* link configuration */
 #defineDP_LINK_BW_SET  0x100
-- 
2.7.4

[PATCH v9 01/12] drm: Add missing DP downstream port types

2016-09-09 Thread Mika Kahola

Add missing DisplayPort downstream port types. The introduced
new port types are DP++ and Wireless.

Reviewed-by: Jim Bride 
Signed-off-by: Mika Kahola 
---
 include/drm/drm_dp_helper.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 63b8bd5..ba9731e 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -211,6 +211,8 @@
 # define DP_DS_PORT_TYPE_DVI   2
 # define DP_DS_PORT_TYPE_HDMI  3
 # define DP_DS_PORT_TYPE_NON_EDID  4
+# define DP_DS_PORT_TYPE_DP_DUALMODE5
+# define DP_DS_PORT_TYPE_WIRELESS   6
 # define DP_DS_PORT_HPD(1 << 3)
 /* offset 1 for VGA is maximum megapixels per second / 8 */
 /* offset 2 */
-- 
2.7.4

[PATCH v9 00/12] drm/i915: DP branch devices

2016-09-09 Thread Mika Kahola

Prep work for DP branch device handling

This series of patches reads DPCD register 0x80h for receiver
capabilities for DP branch devices. The branch device types are
converters for the following standards

 - DP to VGA
 - DP to DVI
 - DP to HDMI
 - DP++ dual mode
 - Wireless WiGig

DPCD register defines max pixel rate for VGA dongles. This
check is carried out during mode validation. 

[1] git://github.com/mkahola/drm-intel-mika.git dp_branch_device

v2: DPCD register read outs moved to drm (Ville, Daniel)
v3: Max pixel rate computation moved to drm (Daniel)
v4: Use of drm_dp_helper routines to collect data (Ville)
v5: Remove duplicate code and unnecessary functions from drm_dp_helper (Ville)
v6: Rebase and i915_debugfs cleanup
v7: Structure cleanups and initial step to move DP debugging info to 
drm_dp_helpers
v8: Cleanups and TMDS clock frequency check for HDMI adapter
v9: Indentation fixes (Jim Bride)

Mika Kahola (12):
  drm: Add missing DP downstream port types
  drm: Drop VGA from bpc definitions
  drm: Helper to read max clock rate
  drm: Helper to read max bits per component
  drm: Read DP branch device id
  drm/i915: Cleanup DisplayPort AUX channel initialization
  drm/i915: Read DP branch device HW revision
  drm/i915: Read DP branch device SW revision
  drm/i915: Check pixel rate for DP to VGA dongle
  drm/i915: Update bits per component for display info
  drm: Add DP branch device info on debugfs
  drm/i915: Check TMDS clock DP to HDMI dongle

 drivers/gpu/drm/drm_dp_helper.c | 172 
 drivers/gpu/drm/i915/i915_debugfs.c |   3 +
 drivers/gpu/drm/i915/intel_dp.c |  88 +-
 drivers/gpu/drm/i915/intel_drv.h|   3 +
 drivers/gpu/drm/i915/intel_hdmi.c   |  27 ++
 include/drm/drm_dp_helper.h |  22 +++--
 6 files changed, 306 insertions(+), 9 deletions(-)

-- 
2.7.4

[PATCH libdrm] configure.ac: Allow explicit enabling of cunit tests

2016-09-09 Thread Marek Olšák

Reviewed-by: Marek OlÅ¡Ã¡k 

Marek

On Mon, Sep 5, 2016 at 2:46 PM, Jussi Kukkonen  
wrote:
> Add --with-cunit to make it easier to do reproducible builds. Default
> is still to probe cunit and build opportunistically.
>
> Signed-off-by: Jussi Kukkonen 
> ---
>  configure.ac | 14 --
>  1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index e3048c7..918d21d 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -137,6 +137,12 @@ AC_ARG_ENABLE(install-test-programs,
>   [Install test programs (default: no)]),
>   [INSTALL_TESTS=$enableval], [INSTALL_TESTS=no])
>
> +AC_ARG_WITH([cunit],
> +[AS_HELP_STRING([--with-cunit],
> +[Build tests that use cunit (default: auto)])],
> +[],
> +[with_cunit=auto])
> +
>  dnl 
> ===
>  dnl check compiler flags
>  AC_DEFUN([LIBDRM_CC_TRY_FLAG], [
> @@ -372,7 +378,7 @@ if test "x$RADEON" = xyes; then
> AC_DEFINE(HAVE_RADEON, 1, [Have radeon support])
>  fi
>
> -if test "x$AMDGPU" != xno; then
> +if test "x$with_cunit" != xno -a "x$AMDGPU" != xno; then
> # Detect cunit library
> PKG_CHECK_MODULES([CUNIT], [cunit >= 2.1], [have_cunit=yes], 
> [have_cunit=no])
> # If pkg-config does not find cunit, check it using AC_CHECK_LIB.  We
> @@ -399,7 +406,11 @@ if test "x$AMDGPU" = xyes; then
> AC_DEFINE(HAVE_CUNIT, [test "x$have_cunit" != "xno"], [Enable CUNIT 
> Have amdgpu support])
>
> if test "x$have_cunit" = "xno"; then
> -   AC_MSG_WARN([Could not find cunit library. Disabling amdgpu 
> tests])
> +   if test "x$with_cunit" = "xyes"; then
> +   AC_MSG_ERROR([Could not find cunit library but 
> --with-cunit was given])
> +   elif test "x$with_cunit" = "xauto"; then
> +   AC_MSG_WARN([Could not find cunit library. Disabling 
> amdgpu tests])
> +   fi
> fi
>  fi
>
> --
> 2.1.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 05/14] drm: sti: Replace drm_fb_get_bpp_depth() with drm_format_plane_cpp()

2016-09-09 Thread Vincent ABRIOU

Hi Laurent,

I plan to take this patch in my pull request that will be done next week.

BR
Vincent

On 09/08/2016 04:44 PM, Laurent Pinchart wrote:
> The driver needs the number of bytes per pixel, not the bpp and depth
> info meant for fbdev compatibility. Use the right API.
>
> Signed-off-by: Laurent Pinchart 
> Acked-by: Vincent Abriou 
> ---
>  drivers/gpu/drm/sti/sti_gdp.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> Cc: Benjamin Gaignard 
> Cc: Vincent Abriou 
>
> diff --git a/drivers/gpu/drm/sti/sti_gdp.c b/drivers/gpu/drm/sti/sti_gdp.c
> index b8d942ca45e8..3fc62c1ea9c2 100644
> --- a/drivers/gpu/drm/sti/sti_gdp.c
> +++ b/drivers/gpu/drm/sti/sti_gdp.c
> @@ -719,7 +719,7 @@ static void sti_gdp_atomic_update(struct drm_plane 
> *drm_plane,
>   u32 dma_updated_top;
>   u32 dma_updated_btm;
>   int format;
> - unsigned int depth, bpp;
> + unsigned int bpp;
>   u32 ydo, xdo, yds, xds;
>
>   if (!crtc || !fb)
> @@ -758,9 +758,9 @@ static void sti_gdp_atomic_update(struct drm_plane 
> *drm_plane,
>(unsigned long)cma_obj->paddr);
>
>   /* pixel memory location */
> - drm_fb_get_bpp_depth(fb->pixel_format, , );
> + bpp = drm_format_plane_cpp(fb->pixel_format, 0);
>   top_field->gam_gdp_pml = (u32)cma_obj->paddr + fb->offsets[0];
> - top_field->gam_gdp_pml += src_x * (bpp >> 3);
> + top_field->gam_gdp_pml += src_x * bpp;
>   top_field->gam_gdp_pml += src_y * fb->pitches[0];
>
>   /* output parameters (clamped / cropped) */
>

drm: GPF in drm_getcap

2016-09-09 Thread Dmitry Vyukov

Hello,

The following program triggers GPF in drm_getcap:

// autogenerated by syzkaller (http://github.com/google/syzkaller)
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

int main()
{
  int fd = open("/dev/dri/card0", O_RDONLY);
  uint64_t data[2] = {0x11, 0x80};
  ioctl(fd, 0xc010640cul /*DRM_IOCTL_GET_CAP*/, data);
  return 0;
}


general protection fault:  [#1] SMP DEBUG_PAGEALLOC KASAN
Modules linked in:
CPU: 1 PID: 5745 Comm: syz-executor Not tainted 4.8.0-rc5-next-20160905+ #14
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: 8800310dc540 task.stack: 88003cbc
RIP: 0010:[]  []
drm_getcap+0x34b/0x4f0 drivers/gpu/drm/drm_ioctl.c:260
RSP: 0018:88003cbc7c28  EFLAGS: 00010202
RAX: 0058 RBX: 88003cbc7cf8 RCX: c90001db
RDX: 005d RSI: 88003cbc7cf8 RDI: 02c0
RBP: 88003cbc7c50 R08: ed0007978fa1 R09: ed0007978fa0
R10: 88003cbc7d07 R11: ed0007978fa1 R12: fff0
R13: dc00 R14: 88003bcc6850 R15: fff2
FS:  7fcbf4e03700() GS:88003ed0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 006dce00 CR3: 66135000 CR4: 06e0
DR0: 001e DR1: 001e DR2: 
DR3:  DR6: 0ff0 DR7: 0600
Stack:
 88003c26db00 88003cbc7cf8 875a3000 88cf0ee0
 fff2 88003cbc7dc0 834cb57c e200
 1101 875a1ba0 882ae930 0010
Call Trace:
 [] drm_ioctl+0x54c/0xaf0 drivers/gpu/drm/drm_ioctl.c:728
 [< inline >] vfs_ioctl fs/ioctl.c:43
 [] do_vfs_ioctl+0x18c/0x1080 fs/ioctl.c:675
 [< inline >] SYSC_ioctl fs/ioctl.c:690
 [] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:681
 [] entry_SYSCALL_64_fastpath+0x23/0xc1
Code: 3c 28 00 0f 85 88 01 00 00 49 8b 44 24 10 49 39 c6 4c 8d 60 f0
74 82 e8 64 19 10 fe 49 8d bc 24 d0 02 00 00 48 89 f8 48 c1 e8 03 <42>
80 3c 28 00 0f 85 6f 01 00 00 4d 8b bc 24 d0 02 00 00 49 8d
RIP  [] drm_getcap+0x34b/0x4f0 drivers/gpu/drm/drm_ioctl.c:260
 RSP 
---[ end trace c6e1afa8cd73b880 ]---


On commit 4affa544adb8077403893e62b9e327fcf87de6f7 (Sep 8) of linux-next.

[PATCH] drm/sti: mark symbols static where possible

2016-09-09 Thread Emil Velikov

On 8 September 2016 at 10:56, Arnd Bergmann  wrote:
> On Thursday, September 8, 2016 10:35:17 AM CEST Emil Velikov wrote:
>> On 7 September 2016 at 12:05, Baoyou Xie  wrote:
>> > We get 2 warnings when building kernel with W=1:
>> As you're going through DRM I was wondering if you have a rough number
>> of warnings we get at the various W levels 1,2,...
>
> I've looked at the W=1 warnings overall, and the count I got a
> month ago was 648 warnings for drivers/gpu/::
>
> 471 -Werror=missing-prototypes
>  12 -Werror=type-limits
> 124 -Werror=unused-but-set-variable
>  41 -Werror=unused-const-variable=
>
> vs for the whole kernel
>
>2033 -Werror=missing-prototypes
>  58 -Werror=suggest-attribute=format
> 167 -Werror=type-limits
>1398 -Werror=unused-but-set-variable
>1526 -Werror=unused-const-variable=
>
> but that was after I had already fixed some of the other warnings
> locally. It shouldn't be hard to fix all of them for any given
> subsystem, often a single line change gets rid of a number
> of individual warnings.
>
Considering the LOC in the kernel, the number are quite small. Still a
fair bit to go.

> My basic idea however is not to do it by subsystem but instead
> do it one warning at a time for the entire kernel and then enable
> that warning by default without W=1.
>
Makes perfect sense. Thanks Arnd !

Keep up the good work gents.

Regards,
Emil

[PATCH 1/2] drm/ttm: remove unused placement flags

2016-09-09 Thread Deucher, Alexander

> -Original Message-
> From: amd-gfx [mailto:amd-gfx-bounces at lists.freedesktop.org] On Behalf
> Of Christian KÃ¶nig
> Sent: Friday, September 09, 2016 7:24 AM
> To: Zhang, Hawking; Koenig, Christian; Cui, Flora; Zhou, David(ChunMing);
> amd-gfx at lists.freedesktop.org
> Cc: dri-devel at lists.freedesktop.org
> Subject: Re: [PATCH 1/2] drm/ttm: remove unused placement flags
> 
> Hi Hawking,
> 
> > Removing the flag will make ttm_mem_type_from_place skip counting the
> corresponding placement and thus have impact on mem region create and
> bo movement.
> And that is exactly the reason why I want to remove the unused flags.
> 
> > There is no guarantee that amdgpu would never introduce new memory
> domain in future.
> Irrelevant, if any driver wants to use additional domains it should add
> them when they are used.
> 
> BTW: Why would we want to add another TTM domain? I really don't see any
> need for that.

We need it for the hybrid driver in the near feature and the open driver may 
use it in the future depending on the use cases.  Removing it just makes our 
lives more difficult for supporting dkms and distro integration for very 
minimal gain.

Alex

> 
> > Then how about keep these flags?
> Actually we used to have automated scanners which complain about unused
> code. I'm wondering why they don't detected that earlier.
> 
> Anyway any code which isn't used in a while should be removed.
> 
> Regards,
> Christian.
> 
> Am 09.09.2016 um 12:35 schrieb Zhang, Hawking:
> > Hi Chris,
> >
> > Removing the flag will make ttm_mem_type_from_place skip counting the
> corresponding placement and thus have impact on mem region create and
> bo movement. There is no guarantee that amdgpu would never introduce
> new memory domain in future. In such case, I'd like to vote for keeping
> these flags instead of adding them back when amdgpu need to add new
> memory domain.
> >
> > As you mentioned that it just a two liner. And there is actually no
> functionality break with these flags. Then how about keep these flags?
> >
> > Regards,
> > Hawking
> >
> > -Original Message-
> > From: amd-gfx [mailto:amd-gfx-bounces at lists.freedesktop.org] On Behalf
> Of Christian K?nig
> > Sent: Friday, September 09, 2016 17:07
> > To: Cui, Flora ; Zhou, David(ChunMing)
> 
> > Cc: amd-gfx at lists.freedesktop.org; dri-devel at lists.freedesktop.org
> > Subject: Re: [PATCH 1/2] drm/ttm: remove unused placement flags
> >
> > In this case please just add them back in your tree. That should be a two
> liner.
> >
> > For upstream it certainly doesn't make sense to keep them.
> >
> > Regards,
> > Christian.
> >
> > Am 09.09.2016 um 09:01 schrieb Flora Cui:
> >> yes. please don't do this, I need them.
> >>
> >> On Fri, Sep 09, 2016 at 02:41:16PM +0800, zhoucm1 wrote:
> >>> On 2016å¹´09æ08æ¥ 21:41, Christian KÃ¶nig wrote:
>  From: Christian KÃ¶nig 
> 
>  Either never used or not used in quite a while.
> >>> No, I remember Flora's Direct GMA is using them like GDS use PRIV0-2.
> >>> And you cannot make sure there isn't no one using them in other
> >>> closed projects, right?
> >>> If you removed now, that obviously will break her implementation and
> >>> brings her many troubles.
> >>>
> >>>
> >>> Regards,
> >>> David Zhou
>  Signed-off-by: Christian KÃ¶nig 
>  ---
> drivers/gpu/drm/ttm/ttm_bo.c|  2 +-
> include/drm/ttm/ttm_placement.h | 19 ---
> 2 files changed, 1 insertion(+), 20 deletions(-)
> 
>  diff --git a/drivers/gpu/drm/ttm/ttm_bo.c
>  b/drivers/gpu/drm/ttm/ttm_bo.c index bc37f02..4d2e8f2 100644
>  --- a/drivers/gpu/drm/ttm/ttm_bo.c
>  +++ b/drivers/gpu/drm/ttm/ttm_bo.c
>  @@ -59,7 +59,7 @@ static inline int ttm_mem_type_from_place(const
> struct ttm_place *place,
> {
>   int i;
>  -for (i = 0; i <= TTM_PL_PRIV5; i++)
>  +for (i = 0; i <= TTM_PL_PRIV2; i++)
>   if (place->flags & (1 << i)) {
>   *mem_type = i;
>   return 0;
>  diff --git a/include/drm/ttm/ttm_placement.h
>  b/include/drm/ttm/ttm_placement.h index 8ed44f9..20219d9 100644
>  --- a/include/drm/ttm/ttm_placement.h
>  +++ b/include/drm/ttm/ttm_placement.h
>  @@ -40,10 +40,6 @@
> #define TTM_PL_PRIV03
> #define TTM_PL_PRIV14
> #define TTM_PL_PRIV25
>  -#define TTM_PL_PRIV36
>  -#define TTM_PL_PRIV47
>  -#define TTM_PL_PRIV58
>  -#define TTM_PL_SWAPPED  15
> #define TTM_PL_FLAG_SYSTEM  (1 << TTM_PL_SYSTEM)
> #define TTM_PL_FLAG_TT  (1 << TTM_PL_TT)
>  @@ -51,10 +47,6 @@
> #define TTM_PL_FLAG_PRIV0   (1 << TTM_PL_PRIV0)
> #define TTM_PL_FLAG_PRIV1   (1 << TTM_PL_PRIV1)
> #define TTM_PL_FLAG_PRIV2   (1 << TTM_PL_PRIV2)
>  -#define

[PATCH 001/001] drivers/gpu/radeon: NULL pointer deference workaround

2016-09-09 Thread Mark Fortescue

On 09/09/16 13:20, Deucher, Alexander wrote:
>> -Original Message-
>> From: Koenig, Christian
>> Sent: Friday, September 09, 2016 4:16 AM
>> To: Mark Fortescue; Koenig, Christian; David Airlie
>> Cc: Deucher, Alexander; linux-kernel at vger.kernel.org; dri-
>> devel at lists.freedesktop.org
>> Subject: Re: [PATCH 001/001] drivers/gpu/radeon: NULL pointer deference
>> workaround
>>
 On this motherboard, DP-1 is a single channel 18bit LVDS LCD panel
 interface and DP-2 is a DVI interface (which I can connect to my
 monitor if testing this is useful). There are no displayport connectors.
>>>
>>> Yeah, but from the driver point of view there are only DP connectors on
>>> the chip. The LVDS and DVI are probably realized with external DP to
>>> whatever converter ICs.
>>>
>>>
>>> That would explain why some similar boards have 24bit LVDS and others
>>> only 18bit LVDS.
>>
>> It could be that this is actually a configuration we don't support yet
>> with radeon and/or the display stack.
>>
>> E.g. that the connector only uses the displayport LVDS lanes, but not
>> actual the displayport protocol to train those lanes.
>>
>> Instead it rather expects a fixed training which is configured somewhere
>> in the BIOS.
>>
>> Anyway Alex needs to take a look, he knows displayport much better than
>> I do (and hates it passionately :).
>
> Generally these sorts of setups are supported by exposing an LVDS or eDP 
> connector rather than a regular DP.  In the case of LVDS and eDP, we have 
> code to fallback to a hardcoded EDID in the vbios if DDC is not available.  
> I'll take a closer look when I'm back.
>
> Alex

Thanks Alex,

I look forward to hearing from you when you have finished recovering 
from your holiday and the associated work backlog :).

I raised a bug (https://bugs.freedesktop.org/show_bug.cgi?id=97637) - 
probably on the wrong component but fixing that should be easy.
It has a more complete copy of the Opps.

Regards
Mark.
>
>>
>> Cheers,
>> Christian.
>>
>> Am 08.09.2016 um 13:18 schrieb Mark Fortescue:
>>> On 08/09/16 11:25, Christian KÃ¶nig wrote:
 Am 08.09.2016 um 11:09 schrieb Mark Fortescue:
> Hi Christian,
>
> Thank you for the feedback.
>
> On 08/09/16 08:14, Christian KÃ¶nig wrote:
>> Am 07.09.2016 um 19:38 schrieb Mark Fortescue:
>>>
>>> On an LV-683 (AMD Dual-core G-T56N) Mini-ITX board, I get a Kernel
>>> Oops because Connector 0 (LCD Panel interface) does not have DDC.
>>
>> I'm not an expert on this, but that is really odd cause even LCD
>> Panels
>> should have a DDC interface.
>>
>>>
>>> Ubuntu 16.04 LTS Kernel (4.4 series):
>>>
>>> ...
>>> [ 8.262990] [drm] ib test on ring 5 succeeded
>>> [ 8.288897] [drm] Radeon Display Connectors
>>> [ 8.293175] [drm] Connector 0:
>>> [ 8.296252] [drm] DP-1
>>
>> Especially since the BIOS claims that this is a displayport connector
>> and there is no physical way to have a DP without an DDC as far as I
>> know.
>>
>> Please open a bug report on FDO and attach you BIOS image.
>
> FDO ? I am not familiar with this. Please can you enlighten me.
>

 See here: http://bugs.freedesktop.org/

> I do not have a BIOS image so will need some assistance in
> understanding what is required here and how I extract the BIOS
> information you are after.
>

 Sorry my fault. Mullins is an APU, so you don't have a dedicated video
 BIOS. As usually I didn't got enough sleep :) But please open up a bug
 report anyway.
>>>
>>> Know the problem of being awake too long :). I will raise a bug.
>>>

> On this motherboard, DP-1 is a single channel 18bit LVDS LCD panel
> interface and DP-2 is a DVI interface (which I can connect to my
> monitor if testing this is useful). There are no displayport
> connectors.

 Yeah, but from the driver point of view there are only DP connectors on
 the chip. The LVDS and DVI are probably realized with external DP to
 whatever converter ICs.

>>>
>>> That would explain why some similar boards have 24bit LVDS and others
>>> only 18bit LVDS.
>>>
>
> On industrial motherboards, I have noticed that it is not uncommon to
> hard code the information for the LCD panel into the BIOS so no DDC is
> required. In this case, there is no LCD panel connected to the
> interface anyway.
>

 That is correct and as far as I know well supported by Radeon, but the
 crux is there should still be a DDC channel even if there isn't anything
 attached to it.

 See with displayport you got four LVDS channels to submit the actual
 picture and an AUX channel to configure and query the device. The DDC is
 just represented as certain packets over the AUX channel.

 If the AUX channel doesn't work or isn't connect then the link training
 wouldn't be possible as well and so you

[PATCH 1/2] drm/ttm: remove unused placement flags

2016-09-09 Thread Christian König

Hi Hawking,

> Removing the flag will make ttm_mem_type_from_place skip counting the 
> corresponding placement and thus have impact on mem region create and bo 
> movement.
And that is exactly the reason why I want to remove the unused flags.

> There is no guarantee that amdgpu would never introduce new memory domain in 
> future.
Irrelevant, if any driver wants to use additional domains it should add 
them when they are used.

BTW: Why would we want to add another TTM domain? I really don't see any 
need for that.

> Then how about keep these flags?
Actually we used to have automated scanners which complain about unused 
code. I'm wondering why they don't detected that earlier.

Anyway any code which isn't used in a while should be removed.

Regards,
Christian.

Am 09.09.2016 um 12:35 schrieb Zhang, Hawking:
> Hi Chris,
>
> Removing the flag will make ttm_mem_type_from_place skip counting the 
> corresponding placement and thus have impact on mem region create and bo 
> movement. There is no guarantee that amdgpu would never introduce new memory 
> domain in future. In such case, I'd like to vote for keeping these flags 
> instead of adding them back when amdgpu need to add new memory domain.
>
> As you mentioned that it just a two liner. And there is actually no 
> functionality break with these flags. Then how about keep these flags?
>
> Regards,
> Hawking
>
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-bounces at lists.freedesktop.org] On Behalf Of 
> Christian K?nig
> Sent: Friday, September 09, 2016 17:07
> To: Cui, Flora ; Zhou, David(ChunMing)  amd.com>
> Cc: amd-gfx at lists.freedesktop.org; dri-devel at lists.freedesktop.org
> Subject: Re: [PATCH 1/2] drm/ttm: remove unused placement flags
>
> In this case please just add them back in your tree. That should be a two 
> liner.
>
> For upstream it certainly doesn't make sense to keep them.
>
> Regards,
> Christian.
>
> Am 09.09.2016 um 09:01 schrieb Flora Cui:
>> yes. please don't do this, I need them.
>>
>> On Fri, Sep 09, 2016 at 02:41:16PM +0800, zhoucm1 wrote:
>>> On 2016å¹´09æ08æ¥ 21:41, Christian KÃ¶nig wrote:
 From: Christian KÃ¶nig 

 Either never used or not used in quite a while.
>>> No, I remember Flora's Direct GMA is using them like GDS use PRIV0-2.
>>> And you cannot make sure there isn't no one using them in other
>>> closed projects, right?
>>> If you removed now, that obviously will break her implementation and
>>> brings her many troubles.
>>>
>>>
>>> Regards,
>>> David Zhou
 Signed-off-by: Christian KÃ¶nig 
 ---
drivers/gpu/drm/ttm/ttm_bo.c|  2 +-
include/drm/ttm/ttm_placement.h | 19 ---
2 files changed, 1 insertion(+), 20 deletions(-)

 diff --git a/drivers/gpu/drm/ttm/ttm_bo.c
 b/drivers/gpu/drm/ttm/ttm_bo.c index bc37f02..4d2e8f2 100644
 --- a/drivers/gpu/drm/ttm/ttm_bo.c
 +++ b/drivers/gpu/drm/ttm/ttm_bo.c
 @@ -59,7 +59,7 @@ static inline int ttm_mem_type_from_place(const struct 
 ttm_place *place,
{
int i;
 -  for (i = 0; i <= TTM_PL_PRIV5; i++)
 +  for (i = 0; i <= TTM_PL_PRIV2; i++)
if (place->flags & (1 << i)) {
*mem_type = i;
return 0;
 diff --git a/include/drm/ttm/ttm_placement.h
 b/include/drm/ttm/ttm_placement.h index 8ed44f9..20219d9 100644
 --- a/include/drm/ttm/ttm_placement.h
 +++ b/include/drm/ttm/ttm_placement.h
 @@ -40,10 +40,6 @@
#define TTM_PL_PRIV03
#define TTM_PL_PRIV14
#define TTM_PL_PRIV25
 -#define TTM_PL_PRIV36
 -#define TTM_PL_PRIV47
 -#define TTM_PL_PRIV58
 -#define TTM_PL_SWAPPED  15
#define TTM_PL_FLAG_SYSTEM  (1 << TTM_PL_SYSTEM)
#define TTM_PL_FLAG_TT  (1 << TTM_PL_TT)
 @@ -51,10 +47,6 @@
#define TTM_PL_FLAG_PRIV0   (1 << TTM_PL_PRIV0)
#define TTM_PL_FLAG_PRIV1   (1 << TTM_PL_PRIV1)
#define TTM_PL_FLAG_PRIV2   (1 << TTM_PL_PRIV2)
 -#define TTM_PL_FLAG_PRIV3   (1 << TTM_PL_PRIV3)
 -#define TTM_PL_FLAG_PRIV4   (1 << TTM_PL_PRIV4)
 -#define TTM_PL_FLAG_PRIV5   (1 << TTM_PL_PRIV5)
 -#define TTM_PL_FLAG_SWAPPED (1 << TTM_PL_SWAPPED)
#define TTM_PL_MASK_MEM 0x
/*
 @@ -72,7 +64,6 @@
#define TTM_PL_FLAG_CACHED  (1 << 16)
#define TTM_PL_FLAG_UNCACHED(1 << 17)
#define TTM_PL_FLAG_WC  (1 << 18)
 -#define TTM_PL_FLAG_SHARED  (1 << 20)
#define TTM_PL_FLAG_NO_EVICT(1 << 21)
#define TTM_PL_FLAG_TOPDOWN (1 << 22)
 @@ -82,14 +73,4 @@
#define TTM_PL_MASK_MEMTYPE (TTM_PL_MASK_MEM | TTM_PL_MASK_CACHING)
 -/*
 - * Access flags to be used for CPU- and GPU- mappings.
 - * The idea is that the TTM synchronization mechanism

[PATCH 001/001] drivers/gpu/radeon: NULL pointer deference workaround

2016-09-09 Thread Deucher, Alexander

> -Original Message-
> From: Koenig, Christian
> Sent: Friday, September 09, 2016 4:16 AM
> To: Mark Fortescue; Koenig, Christian; David Airlie
> Cc: Deucher, Alexander; linux-kernel at vger.kernel.org; dri-
> devel at lists.freedesktop.org
> Subject: Re: [PATCH 001/001] drivers/gpu/radeon: NULL pointer deference
> workaround
> 
> >> On this motherboard, DP-1 is a single channel 18bit LVDS LCD panel
> >> interface and DP-2 is a DVI interface (which I can connect to my
> >> monitor if testing this is useful). There are no displayport connectors.
> >
> > Yeah, but from the driver point of view there are only DP connectors on
> > the chip. The LVDS and DVI are probably realized with external DP to
> > whatever converter ICs.
> >
> >
> > That would explain why some similar boards have 24bit LVDS and others
> > only 18bit LVDS.
> 
> It could be that this is actually a configuration we don't support yet
> with radeon and/or the display stack.
> 
> E.g. that the connector only uses the displayport LVDS lanes, but not
> actual the displayport protocol to train those lanes.
> 
> Instead it rather expects a fixed training which is configured somewhere
> in the BIOS.
> 
> Anyway Alex needs to take a look, he knows displayport much better than
> I do (and hates it passionately :).

Generally these sorts of setups are supported by exposing an LVDS or eDP 
connector rather than a regular DP.  In the case of LVDS and eDP, we have code 
to fallback to a hardcoded EDID in the vbios if DDC is not available.  I'll 
take a closer look when I'm back.

Alex

> 
> Cheers,
> Christian.
> 
> Am 08.09.2016 um 13:18 schrieb Mark Fortescue:
> > On 08/09/16 11:25, Christian KÃ¶nig wrote:
> >> Am 08.09.2016 um 11:09 schrieb Mark Fortescue:
> >>> Hi Christian,
> >>>
> >>> Thank you for the feedback.
> >>>
> >>> On 08/09/16 08:14, Christian KÃ¶nig wrote:
>  Am 07.09.2016 um 19:38 schrieb Mark Fortescue:
> >
> > On an LV-683 (AMD Dual-core G-T56N) Mini-ITX board, I get a Kernel
> > Oops because Connector 0 (LCD Panel interface) does not have DDC.
> 
>  I'm not an expert on this, but that is really odd cause even LCD
>  Panels
>  should have a DDC interface.
> 
> >
> > Ubuntu 16.04 LTS Kernel (4.4 series):
> >
> > ...
> > [ 8.262990] [drm] ib test on ring 5 succeeded
> > [ 8.288897] [drm] Radeon Display Connectors
> > [ 8.293175] [drm] Connector 0:
> > [ 8.296252] [drm] DP-1
> 
>  Especially since the BIOS claims that this is a displayport connector
>  and there is no physical way to have a DP without an DDC as far as I
>  know.
> 
>  Please open a bug report on FDO and attach you BIOS image.
> >>>
> >>> FDO ? I am not familiar with this. Please can you enlighten me.
> >>>
> >>
> >> See here: http://bugs.freedesktop.org/
> >>
> >>> I do not have a BIOS image so will need some assistance in
> >>> understanding what is required here and how I extract the BIOS
> >>> information you are after.
> >>>
> >>
> >> Sorry my fault. Mullins is an APU, so you don't have a dedicated video
> >> BIOS. As usually I didn't got enough sleep :) But please open up a bug
> >> report anyway.
> >
> > Know the problem of being awake too long :). I will raise a bug.
> >
> >>
> >>> On this motherboard, DP-1 is a single channel 18bit LVDS LCD panel
> >>> interface and DP-2 is a DVI interface (which I can connect to my
> >>> monitor if testing this is useful). There are no displayport
> >>> connectors.
> >>
> >> Yeah, but from the driver point of view there are only DP connectors on
> >> the chip. The LVDS and DVI are probably realized with external DP to
> >> whatever converter ICs.
> >>
> >
> > That would explain why some similar boards have 24bit LVDS and others
> > only 18bit LVDS.
> >
> >>>
> >>> On industrial motherboards, I have noticed that it is not uncommon to
> >>> hard code the information for the LCD panel into the BIOS so no DDC is
> >>> required. In this case, there is no LCD panel connected to the
> >>> interface anyway.
> >>>
> >>
> >> That is correct and as far as I know well supported by Radeon, but the
> >> crux is there should still be a DDC channel even if there isn't anything
> >> attached to it.
> >>
> >> See with displayport you got four LVDS channels to submit the actual
> >> picture and an AUX channel to configure and query the device. The DDC is
> >> just represented as certain packets over the AUX channel.
> >>
> >> If the AUX channel doesn't work or isn't connect then the link training
> >> wouldn't be possible as well and so you wouldn't be able to get any
> >> picture on the LVDS.
> >>
> >
> > Interesting.
> >
> >>> See http://www.commell.com.tw/product/SBC/LV-683.HTM for more
> >>> information on the board. Looking at the web site, there is a BIOS
> >>> image available form Commell if that is of use.
> >>
> >> Alex clearly needs to take a look on this. I think for the time being
> >> you could hack together a patch which just ignores DP

[Bug 97643] Shader crashes radeon driver and brings the whole system down

2016-09-09 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #6 from Nicolai HÃ¤hnle  ---
Cris, do please try with more recent Mesa + LLVM as well.

If that still crashes, can you provide a backtrace of where mpv crashes? dmesg
output from the crash could also give some context.

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

[PATCH] drm/vc4: mark vc4_bo_cache_purge() static

2016-09-09 Thread Eric Anholt

Baoyou Xie  writes:

> We get 1 warning when building kernel with W=1:
> drivers/gpu/drm/vc4/vc4_bo.c:147:6: warning: no previous prototype for 
> 'vc4_bo_cache_purge' [-Wmissing-prototypes]
>
> In fact, this function is only used in the file in which it is
> declared and don't need a declaration, but can be made static.
> So this patch marks it 'static'.
>
> Signed-off-by: Baoyou Xie 

Applied to -fixes.  Thanks!
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160909/4499cdcd/attachment.sig>

[PATCH v8 12/12] drm/i915: Check TMDS clock DP to HDMI dongle

2016-09-09 Thread Ville Syrjälä

On Fri, Sep 09, 2016 at 10:45:27AM +0300, Mika Kahola wrote:
> On Thu, 2016-09-08 at 15:48 +0300, Ville SyrjÃ¤lÃ¤ wrote:
> > On Wed, Aug 17, 2016 at 01:49:49PM +0300, Mika Kahola wrote:
> > > 
> > > Respect max TMDS clock frequency from DPCD for active
> > > DP to HDMI adapters.
> > > 
> > > Signed-off-by: Mika Kahola 
> > > ---
> > > Â drivers/gpu/drm/i915/intel_drv.hÂ Â |Â Â 3 +++
> > > Â drivers/gpu/drm/i915/intel_hdmi.c | 27 +++
> > > Â 2 files changed, 30 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > > b/drivers/gpu/drm/i915/intel_drv.h
> > > index 1c700b0..b7fd551 100644
> > > --- a/drivers/gpu/drm/i915/intel_drv.h
> > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > @@ -817,6 +817,9 @@ struct intel_hdmi {
> > > Â i915_reg_t hdmi_reg;
> > > Â int ddc_bus;
> > > Â struct {
> > > + int max_tmds_clock;
> > > + } dp_to_hdmi;
> > > + struct {
> > > Â enum drm_dp_dual_mode_type type;
> > > Â int max_tmds_clock;
> > > Â } dp_dual_mode;
> > > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> > > b/drivers/gpu/drm/i915/intel_hdmi.c
> > > index 4df9f38..1469d00 100644
> > > --- a/drivers/gpu/drm/i915/intel_hdmi.c
> > > +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> > > @@ -1204,6 +1204,9 @@ static int hdmi_port_clock_limit(struct
> > > intel_hdmi *hdmi,
> > > Â int max_tmds_clock =
> > > intel_hdmi_source_max_tmds_clock(to_i915(dev));
> > > Â 
> > > Â if (respect_downstream_limits) {
> > > + if (hdmi->dp_to_hdmi.max_tmds_clock)
> > > + max_tmds_clock = min(max_tmds_clock,
> > > + Â Â Â Â Â hdmi-
> > > >dp_to_hdmi.max_tmds_clock);
> > > Â if (hdmi->dp_dual_mode.max_tmds_clock)
> > > Â max_tmds_clock = min(max_tmds_clock,
> > > Â Â Â Â Â Â hdmi-
> > > >dp_dual_mode.max_tmds_clock);
> > > @@ -1373,11 +1376,33 @@ intel_hdmi_unset_edid(struct drm_connector
> > > *connector)
> > > Â intel_hdmi->dp_dual_mode.type = DRM_DP_DUAL_MODE_NONE;
> > > Â intel_hdmi->dp_dual_mode.max_tmds_clock = 0;
> > > Â 
> > > + intel_hdmi->dp_to_hdmi.max_tmds_clock = 0;
> > > +
> > > Â kfree(to_intel_connector(connector)->detect_edid);
> > > Â to_intel_connector(connector)->detect_edid = NULL;
> > > Â }
> > > Â 
> > > Â static void
> > > +intel_hdmi_dp_adapter_detect(struct drm_connector *connector)
> > > +{
> > > + struct intel_hdmi *intel_hdmi =
> > > intel_attached_hdmi(connector);
> > > + struct intel_digital_port *intel_dig_port =
> > > + hdmi_to_dig_port(intel_hdmi);
> > > + struct intel_dp *intel_dp = _dig_port->dp;
> > > + int type = intel_dp->downstream_ports[0] &
> > > DP_DS_PORT_TYPE_MASK;
> > > +
> > > + if (type != DP_DS_PORT_TYPE_HDMI)
> > > + return;
> > > +
> > > + intel_hdmi->dp_to_hdmi.max_tmds_clock =
> > > + drm_dp_downstream_max_clock(intel_dp->dpcd,
> > > + Â Â Â Â intel_dp-
> > > >downstream_ports);
> > Poets driven by intel_hdmi don't have DPCD, so I don't know what this
> > is supposed to achieve.
> My understanding is that these HDMI adapters has DPCD and therefore I
> placed this function. In addition, I think we should respect the clocks
> if the adapter provides that information.

Only stuff driven by intel_dp has DPCD.

> 
> > 
> > > 
> > > +
> > > + DRM_DEBUG_KMS("DP HDMI adaptor detected (max TMDS clock :
> > > %d kHz\n",
> > > + Â Â Â Â Â Â intel_hdmi->dp_to_hdmi.max_tmds_clock);
> > > +}
> > > +
> > > +static void
> > > Â intel_hdmi_dp_dual_mode_detect(struct drm_connector *connector,
> > > bool has_edid)
> > > Â {
> > > Â struct drm_i915_private *dev_priv = to_i915(connector-
> > > >dev);
> > > @@ -1438,6 +1463,8 @@ intel_hdmi_set_edid(struct drm_connector
> > > *connector, bool force)
> > > Â 
> > > Â intel_hdmi_dp_dual_mode_detect(connector, edid !=
> > > NULL);
> > > Â 
> > > + intel_hdmi_dp_adapter_detect(connector);
> > > +
> > > Â intel_display_power_put(dev_priv,
> > > POWER_DOMAIN_GMBUS);
> > > Â }
> > > Â 
> > > --Â 
> > > 1.9.1
> -- 
> Mika Kahola - Intel OTC

-- 
Ville SyrjÃ¤lÃ¤
Intel OTC

[PATCH] drm: Set depth and bpp for XRGB4444 family formats

2016-09-09 Thread Laurent Pinchart

Hi Fabien,

On Friday 19 Aug 2016 11:01:37 Fabien DESSENNE wrote:
> Hi Laurent,
> 
> Daniel talked about a planned reorg from you around DRM formats (or
> something like this) and I have proposed to fix some missing parts with
> the XRGB444 formats.
> 
> Can you let us know if you can consider this fix as part of your reorg?

I don't, because it's already there :-) See "[PATCH v4 00/14] Centralize 
format information" posted to this mailing list.

The series removes the drm_fb_get_bpp_depth() function. You have several 
options:

- Use drm_format_info() to retrieve format information that include the depth 
and the number of bytes per pixel per plane.

- Use drm_format_plane_cpp() if you only need the number of bytes per pixel 
per plane.

- Check the formats directly in your driver instead of basing decisions on the 
number of bytes per pixel, as Daniel mentioned.

> If you can't what would be the best option to get this fixed?

-- 
Regards,

Laurent Pinchart

[PATCH v8 4/4] drm/i915: Put "cooked" vlank counters in frame CRC lines

2016-09-09 Thread Tomeu Vizoso

Use drm_accurate_vblank_count so we have the full 32 bit to represent
the frame counter and userspace has a simpler way of knowing when the
counter wraps around.

Signed-off-by: Tomeu Vizoso 
Reviewed-by: Emil Velikov 
---

 drivers/gpu/drm/i915/i915_irq.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index e56c7f627093..6d3d4ad62498 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1489,7 +1489,6 @@ static void display_pipe_crc_irq_handler(struct 
drm_i915_private *dev_priv,
struct drm_driver *driver = dev_priv->drm.driver;
uint32_t crcs[5];
int head, tail, ret;
-   u32 frame;

spin_lock(_crc->lock);
if (pipe_crc->source) {
@@ -1545,8 +1544,9 @@ static void display_pipe_crc_irq_handler(struct 
drm_i915_private *dev_priv,
crcs[2] = crc2;
crcs[3] = crc3;
crcs[4] = crc4;
-   frame = driver->get_vblank_counter(_priv->drm, pipe);
-   ret = drm_crtc_add_crc_entry(crtc, true, frame, crcs);
+   ret = drm_crtc_add_crc_entry(crtc, true,
+drm_accurate_vblank_count(crtc),
+crcs);
spin_unlock(>crc.lock);
if (!ret)
wake_up_interruptible(>crc.wq);
-- 
2.7.4

[PATCH v8 2/4] drm: Add API for capturing frame CRCs

2016-09-09 Thread Tomeu Vizoso

Adds files and directories to debugfs for controlling and reading frame
CRCs, per CRTC:

dri/0/crtc-0/crc
dri/0/crtc-0/crc/control
dri/0/crtc-0/crc/data

Drivers can implement the set_crc_source callback() in drm_crtc_funcs to
start and stop generating frame CRCs and can add entries to the output
by calling drm_crtc_add_crc_entry.

v2:
- Lots of good fixes suggested by Thierry.
- Added documentation.
- Changed the debugfs layout.
- Moved to allocate the entries circular queue once when frame
  generation gets enabled for the first time.
v3:
- Use the control file just to select the source, and start and stop
  capture when the data file is opened and closed, respectively.
- Make variable the number of CRC values per entry, per source.
- Allocate entries queue each time we start capturing as now there
  isn't a fixed number of CRC values per entry.
- Store the frame counter in the data file as a 8-digit hex number.
- For sources that cannot provide useful frame numbers, place
   in the frame field.

v4:
- Build only if CONFIG_DEBUG_FS is enabled.
- Use memdup_user_nul.
- Consolidate calculation of the size of an entry in a helper.
- Add 0x prefix to hex numbers in the data file.
- Remove unnecessary snprintf and strlen usage in read callback.

v5:
- Made the crcs array in drm_crtc_crc_entry fixed-size
- Lots of other smaller improvements suggested by Emil Velikov

v7:
- Move definition of drm_debugfs_crtc_crc_add to drm_internal.h

v8:
- Call debugfs_remove_recursive when we fail to create the minor
  device

Signed-off-by: Tomeu Vizoso 
Reviewed-by: Emil Velikov 
---

 Documentation/gpu/drm-uapi.rst|   6 +
 drivers/gpu/drm/Makefile  |   3 +-
 drivers/gpu/drm/drm_crtc.c|  29 +++-
 drivers/gpu/drm/drm_debugfs.c |  34 +++-
 drivers/gpu/drm/drm_debugfs_crc.c | 351 ++
 drivers/gpu/drm/drm_drv.c |  19 +++
 drivers/gpu/drm/drm_internal.h|  16 ++
 include/drm/drm_crtc.h|  41 +
 include/drm/drm_debugfs_crc.h |  73 
 9 files changed, 569 insertions(+), 3 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_debugfs_crc.c
 create mode 100644 include/drm/drm_debugfs_crc.h

diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
index 1ba301cebe16..de3ac9f90f8f 100644
--- a/Documentation/gpu/drm-uapi.rst
+++ b/Documentation/gpu/drm-uapi.rst
@@ -216,3 +216,9 @@ interfaces. Especially since all hardware-acceleration 
interfaces to
 userspace are driver specific for efficiency and other reasons these
 interfaces can be rather substantial. Hence every driver has its own
 chapter.
+
+Testing and validation
+==
+
+.. kernel-doc:: drivers/gpu/drm/drm_debugfs_crc.c
+   :doc: CRC ABI
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 439d89b25ae0..60db76bbb02a 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -9,7 +9,7 @@ drm-y   :=  drm_auth.o drm_bufs.o drm_cache.o \
drm_scatter.o drm_pci.o \
drm_platform.o drm_sysfs.o drm_hashtab.o drm_mm.o \
drm_crtc.o drm_fourcc.o drm_modes.o drm_edid.o \
-   drm_info.o drm_debugfs.o drm_encoder_slave.o \
+   drm_info.o drm_encoder_slave.o \
drm_trace_points.o drm_global.o drm_prime.o \
drm_rect.o drm_vma_manager.o drm_flip_work.o \
drm_modeset_lock.o drm_atomic.o drm_bridge.o \
@@ -22,6 +22,7 @@ drm-$(CONFIG_PCI) += ati_pcigart.o
 drm-$(CONFIG_DRM_PANEL) += drm_panel.o
 drm-$(CONFIG_OF) += drm_of.o
 drm-$(CONFIG_AGP) += drm_agpsupport.o
+drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o

 drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index d84a0ead8100..9363dd597d3c 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -40,7 +40,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 

 #include "drm_crtc_internal.h"
 #include "drm_internal.h"
@@ -141,6 +141,25 @@ static void drm_crtc_unregister_all(struct drm_device *dev)
}
 }

+static int drm_crtc_crc_init(struct drm_crtc *crtc)
+{
+#ifdef CONFIG_DEBUG_FS
+   spin_lock_init(>crc.lock);
+   init_waitqueue_head(>crc.wq);
+   crtc->crc.source = kstrdup("auto", GFP_KERNEL);
+   if (!crtc->crc.source)
+   return -ENOMEM;
+#endif
+   return 0;
+}
+
+static void drm_crtc_crc_fini(struct drm_crtc *crtc)
+{
+#ifdef CONFIG_DEBUG_FS
+   kfree(crtc->crc.source);
+#endif
+}
+
 /**
  * drm_crtc_init_with_planes - Initialise a new CRTC object with
  *specified primary and cursor planes.
@@ -206,6 +225,12 @@ int drm_crtc_init_with_planes(struct drm_device *dev, 
struct drm_crtc *crtc,
if

[PATCH v8 1/4] drm/i915/debugfs: Move out pipe CRC code

2016-09-09 Thread Tomeu Vizoso

In preparation to using a generic API in the DRM core for continuous CRC
generation, move the related code out of i915_debugfs.c into a new file.

Eventually, only the Intel-specific code will remain in this new file.

v2: Rebased.

v6: Rebased.

v7: Fix whitespace issue.

Signed-off-by: Tomeu Vizoso 
Reviewed-by: Emil Velikov 
---

 drivers/gpu/drm/i915/Makefile |   2 +-
 drivers/gpu/drm/i915/i915_debugfs.c   | 886 +--
 drivers/gpu/drm/i915/i915_drv.c   |   2 +-
 drivers/gpu/drm/i915/i915_drv.h   |   2 +-
 drivers/gpu/drm/i915/intel_drv.h  |   5 +
 drivers/gpu/drm/i915/intel_pipe_crc.c | 944 ++
 6 files changed, 956 insertions(+), 885 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_pipe_crc.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index a7da24640e88..6238f8042426 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -23,7 +23,7 @@ i915-y := i915_drv.o \
  intel_runtime_pm.o

 i915-$(CONFIG_COMPAT)   += i915_ioc32.o
-i915-$(CONFIG_DEBUG_FS) += i915_debugfs.o
+i915-$(CONFIG_DEBUG_FS) += i915_debugfs.o intel_pipe_crc.o

 # GEM code
 i915-y += i915_cmd_parser.o \
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 02b627e03dd8..daa1b5a5c423 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -26,19 +26,9 @@
  *
  */

-#include 
-#include 
-#include 
 #include 
-#include 
-#include 
 #include 
-#include 
-#include 
 #include "intel_drv.h"
-#include "intel_ringbuffer.h"
-#include 
-#include "i915_drv.h"

 static inline struct drm_i915_private *node_to_i915(struct drm_info_node *node)
 {
@@ -3378,12 +3368,6 @@ static int i915_drrs_status(struct seq_file *m, void 
*unused)
return 0;
 }

-struct pipe_crc_info {
-   const char *name;
-   struct drm_i915_private *dev_priv;
-   enum pipe pipe;
-};
-
 static int i915_dp_mst_info(struct seq_file *m, void *unused)
 {
struct drm_i915_private *dev_priv = node_to_i915(m->private);
@@ -3413,848 +3397,6 @@ static int i915_dp_mst_info(struct seq_file *m, void 
*unused)
return 0;
 }

-static int i915_pipe_crc_open(struct inode *inode, struct file *filep)
-{
-   struct pipe_crc_info *info = inode->i_private;
-   struct drm_i915_private *dev_priv = info->dev_priv;
-   struct intel_pipe_crc *pipe_crc = _priv->pipe_crc[info->pipe];
-
-   if (info->pipe >= INTEL_INFO(dev_priv)->num_pipes)
-   return -ENODEV;
-
-   spin_lock_irq(_crc->lock);
-
-   if (pipe_crc->opened) {
-   spin_unlock_irq(_crc->lock);
-   return -EBUSY; /* already open */
-   }
-
-   pipe_crc->opened = true;
-   filep->private_data = inode->i_private;
-
-   spin_unlock_irq(_crc->lock);
-
-   return 0;
-}
-
-static int i915_pipe_crc_release(struct inode *inode, struct file *filep)
-{
-   struct pipe_crc_info *info = inode->i_private;
-   struct drm_i915_private *dev_priv = info->dev_priv;
-   struct intel_pipe_crc *pipe_crc = _priv->pipe_crc[info->pipe];
-
-   spin_lock_irq(_crc->lock);
-   pipe_crc->opened = false;
-   spin_unlock_irq(_crc->lock);
-
-   return 0;
-}
-
-/* (6 fields, 8 chars each, space separated (5) + '\n') */
-#define PIPE_CRC_LINE_LEN  (6 * 8 + 5 + 1)
-/* account for \'0' */
-#define PIPE_CRC_BUFFER_LEN(PIPE_CRC_LINE_LEN + 1)
-
-static int pipe_crc_data_count(struct intel_pipe_crc *pipe_crc)
-{
-   assert_spin_locked(_crc->lock);
-   return CIRC_CNT(pipe_crc->head, pipe_crc->tail,
-   INTEL_PIPE_CRC_ENTRIES_NR);
-}
-
-static ssize_t
-i915_pipe_crc_read(struct file *filep, char __user *user_buf, size_t count,
-  loff_t *pos)
-{
-   struct pipe_crc_info *info = filep->private_data;
-   struct drm_i915_private *dev_priv = info->dev_priv;
-   struct intel_pipe_crc *pipe_crc = _priv->pipe_crc[info->pipe];
-   char buf[PIPE_CRC_BUFFER_LEN];
-   int n_entries;
-   ssize_t bytes_read;
-
-   /*
-* Don't allow user space to provide buffers not big enough to hold
-* a line of data.
-*/
-   if (count < PIPE_CRC_LINE_LEN)
-   return -EINVAL;
-
-   if (pipe_crc->source == INTEL_PIPE_CRC_SOURCE_NONE)
-   return 0;
-
-   /* nothing to read */
-   spin_lock_irq(_crc->lock);
-   while (pipe_crc_data_count(pipe_crc) == 0) {
-   int ret;
-
-   if (filep->f_flags & O_NONBLOCK) {
-   spin_unlock_irq(_crc->lock);
-   return -EAGAIN;
-   }
-
-   ret = wait_event_interruptible_lock_irq(pipe_crc->wq,
-   pipe_crc_data_count(pipe_crc), pipe_crc->lock);
-   if (ret) {
-   spin_unlock_irq(_crc->lock);
-   return ret;
-

[PATCH v8 0/4] New debugfs API for capturing CRC of frames

2016-09-09 Thread Tomeu Vizoso

Hi,

this series basically takes the facility for continuously capturing CRCs
of frames from the i915 driver and into the DRM core.

The idea is that test suites such as IGT use this information to check
that frames that are exected to be identical, also have identical CRC
values.

Other drivers for hardware that can provide frame CRCs (including eDP
panels that support self-refresh) can easily implement the new callback
and provide userspace with the CRC values.

Thanks,

Tomeu

Tomeu Vizoso (4):
  drm/i915/debugfs: Move out pipe CRC code
  drm: Add API for capturing frame CRCs
  drm/i915: Use new CRC debugfs API
  drm/i915: Put "cooked" vlank counters in frame CRC lines

 Documentation/gpu/drm-uapi.rst|6 +
 drivers/gpu/drm/Makefile  |3 +-
 drivers/gpu/drm/drm_crtc.c|   29 +-
 drivers/gpu/drm/drm_debugfs.c |   34 +-
 drivers/gpu/drm/drm_debugfs_crc.c |  351 
 drivers/gpu/drm/drm_drv.c |   19 +
 drivers/gpu/drm/drm_internal.h|   16 +
 drivers/gpu/drm/i915/Makefile |2 +-
 drivers/gpu/drm/i915/i915_debugfs.c   |  886 +---
 drivers/gpu/drm/i915/i915_drv.c   |2 +-
 drivers/gpu/drm/i915/i915_drv.h   |3 +-
 drivers/gpu/drm/i915/i915_irq.c   |   83 ++-
 drivers/gpu/drm/i915/intel_display.c  |1 +
 drivers/gpu/drm/i915/intel_drv.h  |7 +
 drivers/gpu/drm/i915/intel_pipe_crc.c | 1014 +
 include/drm/drm_crtc.h|   41 ++
 include/drm/drm_debugfs_crc.h |   73 +++
 17 files changed, 1656 insertions(+), 914 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_debugfs_crc.c
 create mode 100644 drivers/gpu/drm/i915/intel_pipe_crc.c
 create mode 100644 include/drm/drm_debugfs_crc.h

-- 
2.7.4

[PATCH] drm/qxl: reapply cursor after SetCrtc calls

2016-09-09 Thread Ray Strode

From: Ray Strode 

The qxl driver currently destroys and recreates the
qxl "primary" any time the first crtc is set.

A side-effect of destroying the primary is mouse state
associated with the crtc is lost, which leads to
disappearing mouse cursors on wayland sessions.

This commit changes the driver to reapply the cursor
any time SetCrtc is called. It achieves this by keeping
a reference to the cursor bo on the qxl_crtc struct.

Signed-off-by: Ray Strode 

https://bugzilla.redhat.com/show_bug.cgi?id=1200901
---
 drivers/gpu/drm/qxl/qxl_display.c | 56 ++-
 drivers/gpu/drm/qxl/qxl_drv.h |  1 +
 2 files changed, 56 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/qxl/qxl_display.c 
b/drivers/gpu/drm/qxl/qxl_display.c
index 3aef127..a61c0d4 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -184,60 +184,61 @@ static struct mode_size {
{1440,  900},
{1400, 1050},
{1680, 1050},
{1600, 1200},
{1920, 1080},
{1920, 1200}
 };

 static int qxl_add_common_modes(struct drm_connector *connector,
 unsigned pwidth,
 unsigned pheight)
 {
struct drm_device *dev = connector->dev;
struct drm_display_mode *mode = NULL;
int i;
for (i = 0; i < ARRAY_SIZE(common_modes); i++) {
mode = drm_cvt_mode(dev, common_modes[i].w, common_modes[i].h,
60, false, false, false);
if (common_modes[i].w == pwidth && common_modes[i].h == pheight)
mode->type |= DRM_MODE_TYPE_PREFERRED;
drm_mode_probed_add(connector, mode);
}
return i - 1;
 }

 static void qxl_crtc_destroy(struct drm_crtc *crtc)
 {
struct qxl_crtc *qxl_crtc = to_qxl_crtc(crtc);

drm_crtc_cleanup(crtc);
+   qxl_bo_unref(_crtc->cursor_bo);
kfree(qxl_crtc);
 }

 static int qxl_crtc_page_flip(struct drm_crtc *crtc,
   struct drm_framebuffer *fb,
   struct drm_pending_vblank_event *event,
   uint32_t page_flip_flags)
 {
struct drm_device *dev = crtc->dev;
struct qxl_device *qdev = dev->dev_private;
struct qxl_framebuffer *qfb_src = to_qxl_framebuffer(fb);
struct qxl_framebuffer *qfb_old = to_qxl_framebuffer(crtc->primary->fb);
struct qxl_bo *bo_old = gem_to_qxl_bo(qfb_old->obj);
struct qxl_bo *bo = gem_to_qxl_bo(qfb_src->obj);
unsigned long flags;
struct drm_clip_rect norect = {
.x1 = 0,
.y1 = 0,
.x2 = fb->width,
.y2 = fb->height
};
int inc = 1;
int one_clip_rect = 1;
int ret = 0;

crtc->primary->fb = fb;
bo_old->is_primary = false;
bo->is_primary = true;

ret = qxl_bo_reserve(bo, false);
@@ -269,60 +270,106 @@ static int qxl_crtc_page_flip(struct drm_crtc *crtc,
return 0;
 }

 static int
 qxl_hide_cursor(struct qxl_device *qdev)
 {
struct qxl_release *release;
struct qxl_cursor_cmd *cmd;
int ret;

ret = qxl_alloc_release_reserved(qdev, sizeof(*cmd), 
QXL_RELEASE_CURSOR_CMD,
 , NULL);
if (ret)
return ret;

ret = qxl_release_reserve_list(release, true);
if (ret) {
qxl_release_free(qdev, release);
return ret;
}

cmd = (struct qxl_cursor_cmd *)qxl_release_map(qdev, release);
cmd->type = QXL_CURSOR_HIDE;
qxl_release_unmap(qdev, release, >release_info);

qxl_push_cursor_ring_release(qdev, release, QXL_CMD_CURSOR, false);
qxl_release_fence_buffer_objects(release);
return 0;
 }

+static int qxl_crtc_apply_cursor(struct drm_crtc *crtc)
+{
+   struct qxl_crtc *qcrtc = to_qxl_crtc(crtc);
+   struct drm_device *dev = crtc->dev;
+   struct qxl_device *qdev = dev->dev_private;
+   struct qxl_cursor_cmd *cmd;
+   struct qxl_release *release;
+   int ret = 0;
+
+   if (!qcrtc->cursor_bo)
+   return 0;
+
+   ret = qxl_alloc_release_reserved(qdev, sizeof(*cmd),
+QXL_RELEASE_CURSOR_CMD,
+, NULL);
+   if (ret)
+   return ret;
+
+   ret = qxl_release_list_add(release, qcrtc->cursor_bo);
+   if (ret)
+   goto out_free_release;
+
+   ret = qxl_release_reserve_list(release, false);
+   if (ret)
+   goto out_free_release;
+
+   cmd = (struct qxl_cursor_cmd *)qxl_release_map(qdev, release);
+   cmd->type = QXL_CURSOR_SET;
+   cmd->u.set.position.x = qcrtc->cur_x + qcrtc->hot_spot_x;
+   cmd->u.set.position.y = qcrtc->cur_y + qcrtc->hot_spot_y;
+
+

[PATCH 1/2] drm/ttm: remove unused placement flags

2016-09-09 Thread Christian König

In this case please just add them back in your tree. That should be a 
two liner.

For upstream it certainly doesn't make sense to keep them.

Regards,
Christian.

Am 09.09.2016 um 09:01 schrieb Flora Cui:
> yes. please don't do this, I need them.
>
> On Fri, Sep 09, 2016 at 02:41:16PM +0800, zhoucm1 wrote:
>>
>> On 2016å¹´09æ08æ¥ 21:41, Christian KÃ¶nig wrote:
>>> From: Christian KÃ¶nig 
>>>
>>> Either never used or not used in quite a while.
>> No, I remember Flora's Direct GMA is using them like GDS use PRIV0-2. And
>> you cannot make sure there isn't no one using them in other closed projects,
>> right?
>> If you removed now, that obviously will break her implementation and brings
>> her many troubles.
>>
>>
>> Regards,
>> David Zhou
>>> Signed-off-by: Christian KÃ¶nig 
>>> ---
>>>   drivers/gpu/drm/ttm/ttm_bo.c|  2 +-
>>>   include/drm/ttm/ttm_placement.h | 19 ---
>>>   2 files changed, 1 insertion(+), 20 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
>>> index bc37f02..4d2e8f2 100644
>>> --- a/drivers/gpu/drm/ttm/ttm_bo.c
>>> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
>>> @@ -59,7 +59,7 @@ static inline int ttm_mem_type_from_place(const struct 
>>> ttm_place *place,
>>>   {
>>> int i;
>>> -   for (i = 0; i <= TTM_PL_PRIV5; i++)
>>> +   for (i = 0; i <= TTM_PL_PRIV2; i++)
>>> if (place->flags & (1 << i)) {
>>> *mem_type = i;
>>> return 0;
>>> diff --git a/include/drm/ttm/ttm_placement.h 
>>> b/include/drm/ttm/ttm_placement.h
>>> index 8ed44f9..20219d9 100644
>>> --- a/include/drm/ttm/ttm_placement.h
>>> +++ b/include/drm/ttm/ttm_placement.h
>>> @@ -40,10 +40,6 @@
>>>   #define TTM_PL_PRIV03
>>>   #define TTM_PL_PRIV14
>>>   #define TTM_PL_PRIV25
>>> -#define TTM_PL_PRIV36
>>> -#define TTM_PL_PRIV47
>>> -#define TTM_PL_PRIV58
>>> -#define TTM_PL_SWAPPED  15
>>>   #define TTM_PL_FLAG_SYSTEM  (1 << TTM_PL_SYSTEM)
>>>   #define TTM_PL_FLAG_TT  (1 << TTM_PL_TT)
>>> @@ -51,10 +47,6 @@
>>>   #define TTM_PL_FLAG_PRIV0   (1 << TTM_PL_PRIV0)
>>>   #define TTM_PL_FLAG_PRIV1   (1 << TTM_PL_PRIV1)
>>>   #define TTM_PL_FLAG_PRIV2   (1 << TTM_PL_PRIV2)
>>> -#define TTM_PL_FLAG_PRIV3   (1 << TTM_PL_PRIV3)
>>> -#define TTM_PL_FLAG_PRIV4   (1 << TTM_PL_PRIV4)
>>> -#define TTM_PL_FLAG_PRIV5   (1 << TTM_PL_PRIV5)
>>> -#define TTM_PL_FLAG_SWAPPED (1 << TTM_PL_SWAPPED)
>>>   #define TTM_PL_MASK_MEM 0x
>>>   /*
>>> @@ -72,7 +64,6 @@
>>>   #define TTM_PL_FLAG_CACHED  (1 << 16)
>>>   #define TTM_PL_FLAG_UNCACHED(1 << 17)
>>>   #define TTM_PL_FLAG_WC  (1 << 18)
>>> -#define TTM_PL_FLAG_SHARED  (1 << 20)
>>>   #define TTM_PL_FLAG_NO_EVICT(1 << 21)
>>>   #define TTM_PL_FLAG_TOPDOWN (1 << 22)
>>> @@ -82,14 +73,4 @@
>>>   #define TTM_PL_MASK_MEMTYPE (TTM_PL_MASK_MEM | TTM_PL_MASK_CACHING)
>>> -/*
>>> - * Access flags to be used for CPU- and GPU- mappings.
>>> - * The idea is that the TTM synchronization mechanism will
>>> - * allow concurrent READ access and exclusive write access.
>>> - * Currently GPU- and CPU accesses are exclusive.
>>> - */
>>> -
>>> -#define TTM_ACCESS_READ (1 << 0)
>>> -#define TTM_ACCESS_WRITE(1 << 1)
>>> -
>>>   #endif
>> ___
>> amd-gfx mailing list
>> amd-gfx at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH v8 12/12] drm/i915: Check TMDS clock DP to HDMI dongle

2016-09-09 Thread Mika Kahola

On Thu, 2016-09-08 at 15:48 +0300, Ville SyrjÃ¤lÃ¤ wrote:
> On Wed, Aug 17, 2016 at 01:49:49PM +0300, Mika Kahola wrote:
> > 
> > Respect max TMDS clock frequency from DPCD for active
> > DP to HDMI adapters.
> > 
> > Signed-off-by: Mika Kahola 
> > ---
> > Â drivers/gpu/drm/i915/intel_drv.hÂ Â |Â Â 3 +++
> > Â drivers/gpu/drm/i915/intel_hdmi.c | 27 +++
> > Â 2 files changed, 30 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 1c700b0..b7fd551 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -817,6 +817,9 @@ struct intel_hdmi {
> > Â   i915_reg_t hdmi_reg;
> > Â   int ddc_bus;
> > Â   struct {
> > +   int max_tmds_clock;
> > +   } dp_to_hdmi;
> > +   struct {
> > Â   enum drm_dp_dual_mode_type type;
> > Â   int max_tmds_clock;
> > Â   } dp_dual_mode;
> > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> > b/drivers/gpu/drm/i915/intel_hdmi.c
> > index 4df9f38..1469d00 100644
> > --- a/drivers/gpu/drm/i915/intel_hdmi.c
> > +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> > @@ -1204,6 +1204,9 @@ static int hdmi_port_clock_limit(struct
> > intel_hdmi *hdmi,
> > Â   int max_tmds_clock =
> > intel_hdmi_source_max_tmds_clock(to_i915(dev));
> > Â 
> > Â   if (respect_downstream_limits) {
> > +   if (hdmi->dp_to_hdmi.max_tmds_clock)
> > +   max_tmds_clock = min(max_tmds_clock,
> > +   Â Â Â Â Â hdmi-
> > >dp_to_hdmi.max_tmds_clock);
> > Â   if (hdmi->dp_dual_mode.max_tmds_clock)
> > Â   max_tmds_clock = min(max_tmds_clock,
> > Â   Â Â Â Â Â hdmi-
> > >dp_dual_mode.max_tmds_clock);
> > @@ -1373,11 +1376,33 @@ intel_hdmi_unset_edid(struct drm_connector
> > *connector)
> > Â   intel_hdmi->dp_dual_mode.type = DRM_DP_DUAL_MODE_NONE;
> > Â   intel_hdmi->dp_dual_mode.max_tmds_clock = 0;
> > Â 
> > +   intel_hdmi->dp_to_hdmi.max_tmds_clock = 0;
> > +
> > Â   kfree(to_intel_connector(connector)->detect_edid);
> > Â   to_intel_connector(connector)->detect_edid = NULL;
> > Â }
> > Â 
> > Â static void
> > +intel_hdmi_dp_adapter_detect(struct drm_connector *connector)
> > +{
> > +   struct intel_hdmi *intel_hdmi =
> > intel_attached_hdmi(connector);
> > +   struct intel_digital_port *intel_dig_port =
> > +   hdmi_to_dig_port(intel_hdmi);
> > +   struct intel_dp *intel_dp = _dig_port->dp;
> > +   int type = intel_dp->downstream_ports[0] &
> > DP_DS_PORT_TYPE_MASK;
> > +
> > +   if (type != DP_DS_PORT_TYPE_HDMI)
> > +   return;
> > +
> > +   intel_hdmi->dp_to_hdmi.max_tmds_clock =
> > +   drm_dp_downstream_max_clock(intel_dp->dpcd,
> > +   Â Â Â Â intel_dp-
> > >downstream_ports);
> Poets driven by intel_hdmi don't have DPCD, so I don't know what this
> is supposed to achieve.
My understanding is that these HDMI adapters has DPCD and therefore I
placed this function. In addition, I think we should respect the clocks
if the adapter provides that information.

> 
> > 
> > +
> > +   DRM_DEBUG_KMS("DP HDMI adaptor detected (max TMDS clock :
> > %d kHz\n",
> > +   Â Â Â Â Â Â intel_hdmi->dp_to_hdmi.max_tmds_clock);
> > +}
> > +
> > +static void
> > Â intel_hdmi_dp_dual_mode_detect(struct drm_connector *connector,
> > bool has_edid)
> > Â {
> > Â   struct drm_i915_private *dev_priv = to_i915(connector-
> > >dev);
> > @@ -1438,6 +1463,8 @@ intel_hdmi_set_edid(struct drm_connector
> > *connector, bool force)
> > Â 
> > Â   intel_hdmi_dp_dual_mode_detect(connector, edid !=
> > NULL);
> > Â 
> > +   intel_hdmi_dp_adapter_detect(connector);
> > +
> > Â   intel_display_power_put(dev_priv,
> > POWER_DOMAIN_GMBUS);
> > Â   }
> > Â 
> > --Â 
> > 1.9.1
-- 
Mika Kahola - Intel OTC

[PATCH 1/2] drm/ttm: remove unused placement flags

2016-09-09 Thread Zhang, Hawking

Hi Chris,

Removing the flag will make ttm_mem_type_from_place skip counting the 
corresponding placement and thus have impact on mem region create and bo 
movement. There is no guarantee that amdgpu would never introduce new memory 
domain in future. In such case, I'd like to vote for keeping these flags 
instead of adding them back when amdgpu need to add new memory domain.

As you mentioned that it just a two liner. And there is actually no 
functionality break with these flags. Then how about keep these flags?

Regards,
Hawking

-Original Message-
From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of 
Christian K?nig
Sent: Friday, September 09, 2016 17:07
To: Cui, Flora ; Zhou, David(ChunMing) 
Cc: amd-gfx at lists.freedesktop.org; dri-devel at lists.freedesktop.org
Subject: Re: [PATCH 1/2] drm/ttm: remove unused placement flags

In this case please just add them back in your tree. That should be a two liner.

For upstream it certainly doesn't make sense to keep them.

Regards,
Christian.

Am 09.09.2016 um 09:01 schrieb Flora Cui:
> yes. please don't do this, I need them.
>
> On Fri, Sep 09, 2016 at 02:41:16PM +0800, zhoucm1 wrote:
>>
>> On 2016å¹´09æ08æ¥ 21:41, Christian KÃ¶nig wrote:
>>> From: Christian KÃ¶nig 
>>>
>>> Either never used or not used in quite a while.
>> No, I remember Flora's Direct GMA is using them like GDS use PRIV0-2. 
>> And you cannot make sure there isn't no one using them in other 
>> closed projects, right?
>> If you removed now, that obviously will break her implementation and 
>> brings her many troubles.
>>
>>
>> Regards,
>> David Zhou
>>> Signed-off-by: Christian KÃ¶nig 
>>> ---
>>>   drivers/gpu/drm/ttm/ttm_bo.c|  2 +-
>>>   include/drm/ttm/ttm_placement.h | 19 ---
>>>   2 files changed, 1 insertion(+), 20 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c 
>>> b/drivers/gpu/drm/ttm/ttm_bo.c index bc37f02..4d2e8f2 100644
>>> --- a/drivers/gpu/drm/ttm/ttm_bo.c
>>> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
>>> @@ -59,7 +59,7 @@ static inline int ttm_mem_type_from_place(const struct 
>>> ttm_place *place,
>>>   {
>>> int i;
>>> -   for (i = 0; i <= TTM_PL_PRIV5; i++)
>>> +   for (i = 0; i <= TTM_PL_PRIV2; i++)
>>> if (place->flags & (1 << i)) {
>>> *mem_type = i;
>>> return 0;
>>> diff --git a/include/drm/ttm/ttm_placement.h 
>>> b/include/drm/ttm/ttm_placement.h index 8ed44f9..20219d9 100644
>>> --- a/include/drm/ttm/ttm_placement.h
>>> +++ b/include/drm/ttm/ttm_placement.h
>>> @@ -40,10 +40,6 @@
>>>   #define TTM_PL_PRIV03
>>>   #define TTM_PL_PRIV14
>>>   #define TTM_PL_PRIV25
>>> -#define TTM_PL_PRIV36
>>> -#define TTM_PL_PRIV47
>>> -#define TTM_PL_PRIV58
>>> -#define TTM_PL_SWAPPED  15
>>>   #define TTM_PL_FLAG_SYSTEM  (1 << TTM_PL_SYSTEM)
>>>   #define TTM_PL_FLAG_TT  (1 << TTM_PL_TT)
>>> @@ -51,10 +47,6 @@
>>>   #define TTM_PL_FLAG_PRIV0   (1 << TTM_PL_PRIV0)
>>>   #define TTM_PL_FLAG_PRIV1   (1 << TTM_PL_PRIV1)
>>>   #define TTM_PL_FLAG_PRIV2   (1 << TTM_PL_PRIV2)
>>> -#define TTM_PL_FLAG_PRIV3   (1 << TTM_PL_PRIV3)
>>> -#define TTM_PL_FLAG_PRIV4   (1 << TTM_PL_PRIV4)
>>> -#define TTM_PL_FLAG_PRIV5   (1 << TTM_PL_PRIV5)
>>> -#define TTM_PL_FLAG_SWAPPED (1 << TTM_PL_SWAPPED)
>>>   #define TTM_PL_MASK_MEM 0x
>>>   /*
>>> @@ -72,7 +64,6 @@
>>>   #define TTM_PL_FLAG_CACHED  (1 << 16)
>>>   #define TTM_PL_FLAG_UNCACHED(1 << 17)
>>>   #define TTM_PL_FLAG_WC  (1 << 18)
>>> -#define TTM_PL_FLAG_SHARED  (1 << 20)
>>>   #define TTM_PL_FLAG_NO_EVICT(1 << 21)
>>>   #define TTM_PL_FLAG_TOPDOWN (1 << 22)
>>> @@ -82,14 +73,4 @@
>>>   #define TTM_PL_MASK_MEMTYPE (TTM_PL_MASK_MEM | TTM_PL_MASK_CACHING)
>>> -/*
>>> - * Access flags to be used for CPU- and GPU- mappings.
>>> - * The idea is that the TTM synchronization mechanism will
>>> - * allow concurrent READ access and exclusive write access.
>>> - * Currently GPU- and CPU accesses are exclusive.
>>> - */
>>> -
>>> -#define TTM_ACCESS_READ (1 << 0)
>>> -#define TTM_ACCESS_WRITE(1 << 1)
>>> -
>>>   #endif
>> ___
>> amd-gfx mailing list
>> amd-gfx at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx


___
amd-gfx mailing list
amd-gfx at lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH] gpu: Remove depends on RESET_CONTROLLER when not a provider

2016-09-09 Thread Philipp Zabel

Am Donnerstag, den 08.09.2016, 18:36 -0700 schrieb Stephen Boyd:
> These GPU drivers only depend on the RESET_CONTROLLER config
> option to fix build issues that existed when there weren't stub
> reset APIs for reset controller consumers. Given that these
> drivers aren't providing any reset controllers themselves, they
> don't actually depend on the API to build (just to function) so
> they don't need to depend on it. Remove the dependency to fix
> recursive build errors like the following:
> 
> drivers/usb/Kconfig:39:error: recursive dependency detected!
> drivers/usb/Kconfig:39: symbol USB is selected by MOUSE_APPLETOUCH
> drivers/input/mouse/Kconfig:187:symbol MOUSE_APPLETOUCH depends on 
> INPUT
> drivers/input/Kconfig:8:symbol INPUT is selected by VT
> drivers/tty/Kconfig:12: symbol VT is selected by FB_STI
> drivers/video/fbdev/Kconfig:674:symbol FB_STI depends on FB
> drivers/video/fbdev/Kconfig:5:  symbol FB is selected by DRM_KMS_FB_HELPER
> drivers/gpu/drm/Kconfig:42: symbol DRM_KMS_FB_HELPER is selected by 
> DRM_KMS_CMA_HELPER
> drivers/gpu/drm/Kconfig:98: symbol DRM_KMS_CMA_HELPER is selected by 
> DRM_IMX
> drivers/gpu/drm/imx/Kconfig:1:  symbol DRM_IMX depends on IMX_IPUV3_CORE
> drivers/gpu/ipu-v3/Kconfig:1:   symbol IMX_IPUV3_CORE depends on 
> RESET_CONTROLLER
> drivers/reset/Kconfig:4:symbol RESET_CONTROLLER is selected by 
> USB_CHIPIDEA
> drivers/usb/chipidea/Kconfig:1: symbol USB_CHIPIDEA depends on USB_EHCI_HCD
> drivers/usb/host/Kconfig:84:symbol USB_EHCI_HCD depends on USB
> 
> Cc: Arnd Bergmann 
> Cc: Heiko Stuebner 
> Cc: Mark Yao 
> Cc: Philipp Zabel 
> Cc: Peter Chen 
> Signed-off-by: Stephen Boyd 

Acked-by: Philipp Zabel 

thanks
Philipp

[PATCH 1/2] drm/ttm: remove unused placement flags

2016-09-09 Thread Zhang, Hawking

Hi Chris,

Removing the flag will make ttm_mem_type_from_place skip counting the 
corresponding placement and thus have impact on mem region create and bo 
movement. There is no guarantee that amdgpu would never introduce new memory 
domain in future. In such case, I'd like to vote for keeping these flags 
instead of adding them back when amdgpu need to add new memory domain.

As you mentioned that it just a two liner. And there is actually no 
functionality break with these flags. Then how about keep these flags?

Regards,
Hawking

-Original Message-
From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of 
Christian K?nig
Sent: Friday, September 09, 2016 17:07
To: Cui, Flora ; Zhou, David(ChunMing) 
Cc: amd-gfx at lists.freedesktop.org; dri-devel at lists.freedesktop.org
Subject: Re: [PATCH 1/2] drm/ttm: remove unused placement flags

In this case please just add them back in your tree. That should be a two liner.

For upstream it certainly doesn't make sense to keep them.

Regards,
Christian.

Am 09.09.2016 um 09:01 schrieb Flora Cui:
> yes. please don't do this, I need them.
>
> On Fri, Sep 09, 2016 at 02:41:16PM +0800, zhoucm1 wrote:
>>
>> On 2016å¹´09æ08æ¥ 21:41, Christian KÃ¶nig wrote:
>>> From: Christian KÃ¶nig 
>>>
>>> Either never used or not used in quite a while.
>> No, I remember Flora's Direct GMA is using them like GDS use PRIV0-2. 
>> And you cannot make sure there isn't no one using them in other 
>> closed projects, right?
>> If you removed now, that obviously will break her implementation and 
>> brings her many troubles.
>>
>>
>> Regards,
>> David Zhou
>>> Signed-off-by: Christian KÃ¶nig 
>>> ---
>>>   drivers/gpu/drm/ttm/ttm_bo.c|  2 +-
>>>   include/drm/ttm/ttm_placement.h | 19 ---
>>>   2 files changed, 1 insertion(+), 20 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c 
>>> b/drivers/gpu/drm/ttm/ttm_bo.c index bc37f02..4d2e8f2 100644
>>> --- a/drivers/gpu/drm/ttm/ttm_bo.c
>>> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
>>> @@ -59,7 +59,7 @@ static inline int ttm_mem_type_from_place(const struct 
>>> ttm_place *place,
>>>   {
>>> int i;
>>> -   for (i = 0; i <= TTM_PL_PRIV5; i++)
>>> +   for (i = 0; i <= TTM_PL_PRIV2; i++)
>>> if (place->flags & (1 << i)) {
>>> *mem_type = i;
>>> return 0;
>>> diff --git a/include/drm/ttm/ttm_placement.h 
>>> b/include/drm/ttm/ttm_placement.h index 8ed44f9..20219d9 100644
>>> --- a/include/drm/ttm/ttm_placement.h
>>> +++ b/include/drm/ttm/ttm_placement.h
>>> @@ -40,10 +40,6 @@
>>>   #define TTM_PL_PRIV03
>>>   #define TTM_PL_PRIV14
>>>   #define TTM_PL_PRIV25
>>> -#define TTM_PL_PRIV36
>>> -#define TTM_PL_PRIV47
>>> -#define TTM_PL_PRIV58
>>> -#define TTM_PL_SWAPPED  15
>>>   #define TTM_PL_FLAG_SYSTEM  (1 << TTM_PL_SYSTEM)
>>>   #define TTM_PL_FLAG_TT  (1 << TTM_PL_TT)
>>> @@ -51,10 +47,6 @@
>>>   #define TTM_PL_FLAG_PRIV0   (1 << TTM_PL_PRIV0)
>>>   #define TTM_PL_FLAG_PRIV1   (1 << TTM_PL_PRIV1)
>>>   #define TTM_PL_FLAG_PRIV2   (1 << TTM_PL_PRIV2)
>>> -#define TTM_PL_FLAG_PRIV3   (1 << TTM_PL_PRIV3)
>>> -#define TTM_PL_FLAG_PRIV4   (1 << TTM_PL_PRIV4)
>>> -#define TTM_PL_FLAG_PRIV5   (1 << TTM_PL_PRIV5)
>>> -#define TTM_PL_FLAG_SWAPPED (1 << TTM_PL_SWAPPED)
>>>   #define TTM_PL_MASK_MEM 0x
>>>   /*
>>> @@ -72,7 +64,6 @@
>>>   #define TTM_PL_FLAG_CACHED  (1 << 16)
>>>   #define TTM_PL_FLAG_UNCACHED(1 << 17)
>>>   #define TTM_PL_FLAG_WC  (1 << 18)
>>> -#define TTM_PL_FLAG_SHARED  (1 << 20)
>>>   #define TTM_PL_FLAG_NO_EVICT(1 << 21)
>>>   #define TTM_PL_FLAG_TOPDOWN (1 << 22)
>>> @@ -82,14 +73,4 @@
>>>   #define TTM_PL_MASK_MEMTYPE (TTM_PL_MASK_MEM | TTM_PL_MASK_CACHING)
>>> -/*
>>> - * Access flags to be used for CPU- and GPU- mappings.
>>> - * The idea is that the TTM synchronization mechanism will
>>> - * allow concurrent READ access and exclusive write access.
>>> - * Currently GPU- and CPU accesses are exclusive.
>>> - */
>>> -
>>> -#define TTM_ACCESS_READ (1 << 0)
>>> -#define TTM_ACCESS_WRITE(1 << 1)
>>> -
>>>   #endif
>> ___
>> amd-gfx mailing list
>> amd-gfx at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx


___
amd-gfx mailing list
amd-gfx at lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[Bug 69076] [r300g] RS690: triangle flickering

2016-09-09 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #14 from Max Staudt  ---
The patch just hit Mesa master:

https://cgit.freedesktop.org/mesa/mesa/commit/?id=02675622b02742960678c438f1b239321c075f50

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

[PATCH] drm/i915: Before pageflip, also wait for shared dmabuf fences.

2016-09-09 Thread Michel Dänzer

On 09/09/16 01:23 AM, Chris Wilson wrote:
> On Thu, Sep 08, 2016 at 05:21:42PM +0200, Mario Kleiner wrote:
>> On 09/08/2016 08:30 AM, Chris Wilson wrote:
>>> On Thu, Sep 08, 2016 at 02:14:43AM +0200, Mario Kleiner wrote:
 amdgpu-kms uses shared fences for its prime exported dmabufs,
 instead of an exclusive fence. Therefore we need to wait for
 all fences of the dmabuf reservation object to prevent
 unsynchronized rendering and flipping.
>>>
>>> No. Fix the root cause as this affects not just flips but copies -
>>> this implies that everybody using the resv object must wait for all
>>> fences. The resv object is not just used for prime, but all fencing, so
>>> this breaks the ability to schedule parallel operations across engine.
>>> -Chris
>>>
>>
>> Ok. I think i now understand the difference, but let's check: The
>> exclusive fence is essentially acting a bit like a write-lock, and
>> the shared fences as readers-locks? So you can have multiple readers
>> but only one writer at a time?
> 
> That's how we (i915.ko and I hope the rest of the world) are using them.
> In the model where here is just one reservation object on the GEM
> object, that reservation object is then shared between internal driver
> scheduling and external. We are reliant on being able to use buffers on
> multiple engines through the virtue of the shared fences, and to serialise
> after writes by waiting on the exclusive fence. (So we can have concurrent
> reads on the display engine, render engines and on the CPU - or
> alternatively an exclusive writer.)
> 
> In the near future, i915 flips will wait on the common reservation object
> not only for dma-bufs, but also its own GEM objects.
>  
>> Ie.:
>>
>> Writer must wait for all fences before starting write access to a
>> buffer, then attach the exclusive fence and signal it on end of
>> write access. E.g., write to renderbuffer, write to texture etc.
> 
> Yes.
>  
>> Readers must wait for exclusive fence, then attach a shared fence
>> per reader and signal it on end of read access? E.g., read from
>> texture, fb, scanout?
> 
> Yes.
>  
>> Is that correct? In that case we'd have a missing exclusive fence in
>> amdgpu for the linear target dmabuf? Probably beyond my level of
>> knowledge to fix this?
> 
> i915.ko requires the client to mark which buffers are written to.
> 
> In ttm, there are ttm_validate_buffer objects which mark whether they
> should be using shared or exclusive fences. Afaict, in amdgpu they are
> all set to shared, the relevant user interface seems to be
> amdgpu_bo_list_set().

This all makes sense to me.

Christian, why is amdgpu setting only shared fences? Can we fix that?


-- 
Earthling Michel DÃ¤nzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

[PATCH 001/001] drivers/gpu/radeon: NULL pointer deference workaround

2016-09-09 Thread Christian König

>> On this motherboard, DP-1 is a single channel 18bit LVDS LCD panel
>> interface and DP-2 is a DVI interface (which I can connect to my
>> monitor if testing this is useful). There are no displayport connectors.
>
> Yeah, but from the driver point of view there are only DP connectors on
> the chip. The LVDS and DVI are probably realized with external DP to
> whatever converter ICs.
>
>
> That would explain why some similar boards have 24bit LVDS and others 
> only 18bit LVDS. 

It could be that this is actually a configuration we don't support yet 
with radeon and/or the display stack.

E.g. that the connector only uses the displayport LVDS lanes, but not 
actual the displayport protocol to train those lanes.

Instead it rather expects a fixed training which is configured somewhere 
in the BIOS.

Anyway Alex needs to take a look, he knows displayport much better than 
I do (and hates it passionately :).

Cheers,
Christian.

Am 08.09.2016 um 13:18 schrieb Mark Fortescue:
> On 08/09/16 11:25, Christian KÃ¶nig wrote:
>> Am 08.09.2016 um 11:09 schrieb Mark Fortescue:
>>> Hi Christian,
>>>
>>> Thank you for the feedback.
>>>
>>> On 08/09/16 08:14, Christian KÃ¶nig wrote:
 Am 07.09.2016 um 19:38 schrieb Mark Fortescue:
>
> On an LV-683 (AMD Dual-core G-T56N) Mini-ITX board, I get a Kernel
> Oops because Connector 0 (LCD Panel interface) does not have DDC.

 I'm not an expert on this, but that is really odd cause even LCD 
 Panels
 should have a DDC interface.

>
> Ubuntu 16.04 LTS Kernel (4.4 series):
>
> ...
> [ 8.262990] [drm] ib test on ring 5 succeeded
> [ 8.288897] [drm] Radeon Display Connectors
> [ 8.293175] [drm] Connector 0:
> [ 8.296252] [drm] DP-1

 Especially since the BIOS claims that this is a displayport connector
 and there is no physical way to have a DP without an DDC as far as I
 know.

 Please open a bug report on FDO and attach you BIOS image.
>>>
>>> FDO ? I am not familiar with this. Please can you enlighten me.
>>>
>>
>> See here: http://bugs.freedesktop.org/
>>
>>> I do not have a BIOS image so will need some assistance in
>>> understanding what is required here and how I extract the BIOS
>>> information you are after.
>>>
>>
>> Sorry my fault. Mullins is an APU, so you don't have a dedicated video
>> BIOS. As usually I didn't got enough sleep :) But please open up a bug
>> report anyway.
>
> Know the problem of being awake too long :). I will raise a bug.
>
>>
>>> On this motherboard, DP-1 is a single channel 18bit LVDS LCD panel
>>> interface and DP-2 is a DVI interface (which I can connect to my
>>> monitor if testing this is useful). There are no displayport 
>>> connectors.
>>
>> Yeah, but from the driver point of view there are only DP connectors on
>> the chip. The LVDS and DVI are probably realized with external DP to
>> whatever converter ICs.
>>
>
> That would explain why some similar boards have 24bit LVDS and others 
> only 18bit LVDS.
>
>>>
>>> On industrial motherboards, I have noticed that it is not uncommon to
>>> hard code the information for the LCD panel into the BIOS so no DDC is
>>> required. In this case, there is no LCD panel connected to the
>>> interface anyway.
>>>
>>
>> That is correct and as far as I know well supported by Radeon, but the
>> crux is there should still be a DDC channel even if there isn't anything
>> attached to it.
>>
>> See with displayport you got four LVDS channels to submit the actual
>> picture and an AUX channel to configure and query the device. The DDC is
>> just represented as certain packets over the AUX channel.
>>
>> If the AUX channel doesn't work or isn't connect then the link training
>> wouldn't be possible as well and so you wouldn't be able to get any
>> picture on the LVDS.
>>
>
> Interesting.
>
>>> See http://www.commell.com.tw/product/SBC/LV-683.HTM for more
>>> information on the board. Looking at the web site, there is a BIOS
>>> image available form Commell if that is of use.
>>
>> Alex clearly needs to take a look on this. I think for the time being
>> you could hack together a patch which just ignores DP connectors during
>> probing if they don't have an associated DDC instead of changing the
>> code everywhere the DDC object is required.
>>
>
> I will try to find the time to look at this in more detail. GPU/DRM is 
> not something I have done any real work on in the past so I do not 
> know how it all fits together. The overkill on the code changes is the 
> result, as that way I don't need to understand where and why the 
> helper function (radeon_dp_getsinktype) gets called or what other code 
> paths can be executed that could fail.
>
> I will wait for Alex to have a think about it and respond before I do 
> any more - that way I can finish the work I am paid to do first :).
>
>> Regards,
>> Christian.
>>
> Regards
> Mark.
>>>

 Alex can probably take a look when he's back from vacation.

 Regards,

[PATCH v9 11/12] drm: Add DP branch device info on debugfs

2016-09-09 Thread Jim Bride

On Fri, Sep 09, 2016 at 02:10:57PM +0300, Mika Kahola wrote:
> Read DisplayPort branch device info from through debugfs
> interface.
> 
> v2: use drm_dp_helper routines to collect data
> v3: cleanup to match the drm_dp_helper.c patches introduced
> earlier in this series
> v4: move DP branch device info to function 'intel_dp_branch_device_info()'
> v5: initial step to move debugging info from intel_dp. to drm_dp_helper.c 
> (Daniel)
> v6: read hw and sw revision without using specific drm_dp_helper routines
> v7: indentation fixes (Jim Bride)
> 
> Signed-off-by: Mika Kahola 

Reviewed-by: Jim Bride 

> ---
>  drivers/gpu/drm/drm_dp_helper.c | 85 
> +
>  drivers/gpu/drm/i915/i915_debugfs.c |  3 ++
>  include/drm/drm_dp_helper.h |  2 +
>  3 files changed, 90 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 01ee7af..a536514 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -526,6 +526,91 @@ int drm_dp_downstream_id(struct drm_dp_aux *aux, char 
> id[6])
>  }
>  EXPORT_SYMBOL(drm_dp_downstream_id);
>  
> +/**
> + * drm_dp_downstream_debug() - debug DP branch devices
> + * @m: pointer for debugfs file
> + * @dpcd: DisplayPort configuration data
> + * @port_cap: port capabilities
> + * @aux: DisplayPort AUX channel
> + *
> + */
> +void drm_dp_downstream_debug(struct seq_file *m,
> +  const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> +  const u8 port_cap[4], struct drm_dp_aux *aux)
> +{
> + bool detailed_cap_info = dpcd[DP_DOWNSTREAMPORT_PRESENT] &
> +  DP_DETAILED_CAP_INFO_AVAILABLE;
> + int clk;
> + int bpc;
> + char id[6];
> + int len;
> + uint8_t rev[2];
> + int type = port_cap[0] & DP_DS_PORT_TYPE_MASK;
> + bool branch_device = dpcd[DP_DOWNSTREAMPORT_PRESENT] &
> +  DP_DWN_STRM_PORT_PRESENT;
> +
> + seq_printf(m, "\tDP branch device present: %s\n",
> +branch_device ? "yes" : "no");
> +
> + if (!branch_device)
> + return;
> +
> + switch (type) {
> + case DP_DS_PORT_TYPE_DP:
> + seq_puts(m, "\t\tType: DisplayPort\n");
> + break;
> + case DP_DS_PORT_TYPE_VGA:
> + seq_puts(m, "\t\tType: VGA\n");
> + break;
> + case DP_DS_PORT_TYPE_DVI:
> + seq_puts(m, "\t\tType: DVI\n");
> + break;
> + case DP_DS_PORT_TYPE_HDMI:
> + seq_puts(m, "\t\tType: HDMI\n");
> + break;
> + case DP_DS_PORT_TYPE_NON_EDID:
> + seq_puts(m, "\t\tType: others without EDID support\n");
> + break;
> + case DP_DS_PORT_TYPE_DP_DUALMODE:
> + seq_puts(m, "\t\tType: DP++\n");
> + break;
> + case DP_DS_PORT_TYPE_WIRELESS:
> + seq_puts(m, "\t\tType: Wireless\n");
> + break;
> + default:
> + seq_puts(m, "\t\tType: N/A\n");
> + }
> +
> + drm_dp_downstream_id(aux, id);
> + seq_printf(m, "\t\tID: %s\n", id);
> +
> + len = drm_dp_dpcd_read(aux, DP_BRANCH_HW_REV, [0], 1);
> + if (len > 0)
> + seq_printf(m, "\t\tHW: %d.%d\n",
> +(rev[0] & 0xf0) >> 4, rev[0] & 0xf);
> +
> + len = drm_dp_dpcd_read(aux, DP_BRANCH_SW_REV, , 2);
> + if (len > 0)
> + seq_printf(m, "\t\tSW: %d.%d\n", rev[0], rev[1]);
> +
> + if (detailed_cap_info) {
> + clk = drm_dp_downstream_max_clock(dpcd, port_cap);
> +
> + if (clk > 0) {
> + if (type == DP_DS_PORT_TYPE_VGA)
> + seq_printf(m, "\t\tMax dot clock: %d kHz\n", 
> clk);
> + else
> + seq_printf(m, "\t\tMax TMDS clock: %d kHz\n", 
> clk);
> + }
> +
> + bpc = drm_dp_downstream_max_bpc(dpcd, port_cap);
> +
> + if (bpc > 0)
> + seq_printf(m, "\t\tMax bpc: %d\n", bpc);
> + }
> +}
> +EXPORT_SYMBOL(drm_dp_downstream_debug);
> +
>  /*
>   * I2C-over-AUX implementation
>   */
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 02b627e..44fab14 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2851,6 +2851,9 @@ static void intel_dp_info(struct seq_file *m,
>   seq_printf(m, "\taudio support: %s\n", yesno(intel_dp->has_audio));
>   if (intel_connector->base.connector_type == DRM_MODE_CONNECTOR_eDP)
>   intel_panel_info(m, _connector->panel);
> +
> + drm_dp_downstream_debug(m, intel_dp->dpcd, intel_dp->downstream_ports,
> + _dp->aux);
>  }
>  
>  static void intel_hdmi_info(struct seq_file *m,
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 215202f..2a79882 100644
> ---

[PATCH v9 10/12] drm/i915: Update bits per component for display info

2016-09-09 Thread Jim Bride

On Fri, Sep 09, 2016 at 02:10:56PM +0300, Mika Kahola wrote:
> DisplayPort branch device may define max supported bits per
> component. Update display info based on this value if bpc
> is defined.
> 
> v2: cleanup to match the drm_dp_helper.c patches introduced
> earlier in this series
> v3: Fill bpc for connector's display info in separate
> drm_dp_helper function (Daniel)
> v4: remove updating bpc for display info as it may be overridden
> when parsing EDID. Instead, check bpc for DP branch device
> during compute_config
> v5: Indentation fixes (Jim Bride)
> 
> Signed-off-by: Mika Kahola 

Reviewed-by: Jim Bride 

> ---
>  drivers/gpu/drm/i915/intel_dp.c | 16 +++-
>  1 file changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 8f17c88..69cee9b 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1524,6 +1524,20 @@ void intel_dp_compute_rate(struct intel_dp *intel_dp, 
> int port_clock,
>   }
>  }
>  
> +int intel_dp_compute_bpp(struct intel_dp *intel_dp,
> +  struct intel_crtc_state *pipe_config)
> +{
> + int bpp, bpc;
> +
> + bpp = pipe_config->pipe_bpp;
> + bpc = drm_dp_downstream_max_bpc(intel_dp->dpcd, 
> intel_dp->downstream_ports);
> +
> + if (bpc > 0)
> + bpp = min(bpp, 3*bpc);
> +
> + return bpp;
> +}
> +
>  bool
>  intel_dp_compute_config(struct intel_encoder *encoder,
>   struct intel_crtc_state *pipe_config,
> @@ -1590,7 +1604,7 @@ intel_dp_compute_config(struct intel_encoder *encoder,
>  
>   /* Walk through all bpp values. Luckily they're all nicely spaced with 2
>* bpc in between. */
> - bpp = pipe_config->pipe_bpp;
> + bpp = intel_dp_compute_bpp(intel_dp, pipe_config);
>   if (is_edp(intel_dp)) {
>  
>   /* Get bpp from vbt only for panels that dont have bpp in edid 
> */
> -- 
> 2.7.4

[PATCH v9 08/12] drm/i915: Read DP branch device SW revision

2016-09-09 Thread Jim Bride

On Fri, Sep 09, 2016 at 02:10:54PM +0300, Mika Kahola wrote:
> SW revision is mandatory field for DisplayPort branch
> devices. This is defined in DPCD register fields 0x50A
> and 0x50B.
> 
> v2: move drm_dp_ds_revision structure to be part of
> drm_dp_link structure (Daniel)
> v3: remove dependency to drm_dp_helper but instead parse
> DPCD and print SW revision info to dmesg (Ville)
> v4: commit message fix (Jim Bride)
> 
> Signed-off-by: Mika Kahola 

Reviewed-by: Jim Bride 

> ---
>  drivers/gpu/drm/i915/intel_dp.c | 20 
>  include/drm/drm_dp_helper.h |  1 +
>  2 files changed, 21 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index bb0417c..7428c72 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1438,6 +1438,25 @@ static void intel_dp_print_hw_revision(struct intel_dp 
> *intel_dp)
>   DRM_DEBUG_KMS("sink hw revision: %d.%d\n", (rev & 0xf0) >> 4, rev & 
> 0xf);
>  }
>  
> +static void intel_dp_print_sw_revision(struct intel_dp *intel_dp)
> +{
> + uint8_t rev[2];
> + int len;
> +
> + if ((drm_debug & DRM_UT_KMS) == 0)
> + return;
> +
> + if (!(intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] &
> +   DP_DWN_STRM_PORT_PRESENT))
> + return;
> +
> + len = drm_dp_dpcd_read(_dp->aux, DP_BRANCH_SW_REV, , 2);
> + if (len < 0)
> + return;
> +
> + DRM_DEBUG_KMS("sink sw revision: %d.%d\n", rev[0], rev[1]);
> +}
> +
>  static int rate_to_index(int find, const int *rates)
>  {
>   int i = 0;
> @@ -4332,6 +4351,7 @@ intel_dp_long_pulse(struct intel_connector 
> *intel_connector)
>   intel_dp_probe_oui(intel_dp);
>  
>   intel_dp_print_hw_revision(intel_dp);
> + intel_dp_print_sw_revision(intel_dp);
>  
>   intel_dp_configure_mst(intel_dp);
>  
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 19ac599..215202f 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -447,6 +447,7 @@
>  #define DP_BRANCH_OUI0x500
>  #define DP_BRANCH_ID0x503
>  #define DP_BRANCH_HW_REV0x509
> +#define DP_BRANCH_SW_REV0x50A
>  
>  #define DP_SET_POWER0x600
>  # define DP_SET_POWER_D00x1
> -- 
> 2.7.4

[Bug 96541] Tonga Unreal elemental bad rendering since radeonsi: Decompress DCC textures in a render feedback loop

2016-09-09 Thread bugzilla-dae...@freedesktop.org

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

Andy Furniss  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #2 from Andy Furniss  ---
Working with current mesa/llvm.

Not sure when/what fixed as I haven't tested for a while.

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

[Bug 35457] [rs690m] Graphics corruption with ati x1200

2016-09-09 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #110 from Michel DÃ¤nzer  ---
Does current Mesa Git master work better WRT any of these issues? An RSxxx
specific fix just landed:
https://cgit.freedesktop.org/mesa/mesa/commit/?id=02675622b02742960678c438f1b239321c075f50

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

[Bug 96602] [radeonsi] Dreamfall Chapters: one shader fails to compile, minor visual corruption

2016-09-09 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #7 from Nicolai HÃ¤hnle  ---
Created attachment 126364
  --> https://bugs.freedesktop.org/attachment.cgi?id=126364=edit
Simplified version that also used to trigger the error

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

[Bug 96602] [radeonsi] Dreamfall Chapters: one shader fails to compile, minor visual corruption

2016-09-09 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #6 from Nicolai HÃ¤hnle  ---
Created attachment 126363
  --> https://bugs.freedesktop.org/attachment.cgi?id=126363=edit
The problematic shader

Adding the extracted shader for future reference.

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

[Bug 97639] Intermittent flickering artifacts with AMD R7 260x

2016-09-09 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #3 from nucrap at hotmail.com ---
Created attachment 126362
  --> https://bugs.freedesktop.org/attachment.cgi?id=126362=edit
dmesg

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

[Bug 94900] HD6950 GPU lockup loop with various steam games (octodad[always], saints row 4[always], dead island[always], grid autosport[sometimes])

2016-09-09 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #23 from Alex  ---
This also happens 100% of the time under Faeria and Rocket League.

The bug that appeared during a Rocket League session :
[36447.794626] BUG: unable to handle kernel paging request at c90401d40ffc
[36447.794656] IP: [] radeon_ring_backup+0xda/0x190 [radeon]
[36447.794697] PGD 40e099067 PUD 0
[36447.794710] Oops:  [#1] SMP
[36447.794723] Modules linked in: pci_stub vboxpci(OE) vboxnetadp(OE)
vboxnetflt(OE) snd_hrtimer vboxdrv(OE) binfmt_misc intel_rapl x86_pkg_te
mp_thermal intel_powerclamp kvm_intel kvm irqbypass crct10dif_pclmul
crc32_pclmul aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper
cryptd serio_raw hid_logitech_hidpp lpc_ich joydev input_leds
snd_hda_codec_realtek arc4 snd_hda_codec_hdmi snd_hda_codec_generic ath9k
ath9k_
common snd_usb_audio ath9k_hw snd_usbmidi_lib ath mac80211 cfg80211
snd_hda_intel snd_hda_codec snd_ctxfi snd_hda_core snd_hwdep snd_seq_midi
snd_seq_midi_event snd_pcm snd_rawmidi snd_seq snd_seq_device snd_timer snd
mei_me mei soundcore tpm_infineon shpchp mac_hid it87 hwmon_vid co
retemp parport_pc ppdev lp parport autofs4 hid_logitech_dj uas usb_storage
wacom hid_generic usbhid
[36447.794999]  hid mxm_wmi amdkfd amd_iommu_v2 radeon psmouse firewire_ohci
firewire_core crc_itu_t atl1c i2c_algo_bit ttm ahci drm_kms_helpe
r libahci syscopyarea sysfillrect sysimgblt fb_sys_fops e1000e drm ptp pps_core
video fjes wmi
[36447.795083] CPU: 2 PID: 3667 Comm: Xorg Tainted: G   OE  
4.4.0-36-generic #55-Ubuntu
[36447.795109] Hardware name: Gigabyte Technology Co., Ltd. To be filled by
O.E.M./Z77X-UD5H, BIOS F4 03/09/2012
[36447.795137] task: 8804072c5280 ti: 8800d9ed task.ti:
8800d9ed
[36447.795158] RIP: 0010:[]  []
radeon_ring_backup+0xda/0x190 [radeon]
[36447.795197] RSP: :8800d9ed3c48  EFLAGS: 00010202
[36447.795213] RAX: c90002313000 RBX:  RCX:

[36447.795233] RDX:  RSI: c90401d40ffc RDI:
00096440
[36447.795253] RBP: 8800d9ed3c78 R08: 88010c011e00 R09:
8163
[36447.795274] R10:  R11: 81ccf5ea R12:
8800358494e0
[36447.795294] R13: 8800358494b8 R14: 00025911 R15:
8800d9ed3cc0
[36447.795314] FS:  7fc9397a1a00() GS:88041ed0()
knlGS:
[36447.795337] CS:  0010 DS:  ES:  CR0: 80050033
[36447.795354] CR2: c90401d40ffc CR3: 00040a177000 CR4:
000406e0
[36447.795374] Stack:
[36447.795380]  880035848000 880035848000 8800358494e0
8800d9ed3cc0
[36447.795406]  8800358494e0  8800d9ed3d30
c020acdd
[36447.795430]  880035848740 00ff88040001 880035848018
8803216e3000
[36447.795455] Call Trace:
[36447.795472]  [] radeon_gpu_reset+0xcd/0x330 [radeon]
[36447.795492]  [] ? fence_wait_timeout+0x7d/0x160
[36447.795521]  [] radeon_gem_handle_lockup.part.3+0xe/0x20
[radeon]
[36447.795553]  [] radeon_gem_wait_idle_ioctl+0xdf/0x130
[radeon]
[36447.795584]  [] drm_ioctl+0x152/0x540 [drm]
[36447.795611]  [] ? radeon_gem_busy_ioctl+0xe0/0xe0 [radeon]
[36447.795639]  [] radeon_drm_ioctl+0x4c/0x80 [radeon]
[36447.795659]  [] do_vfs_ioctl+0x29f/0x490
[36447.795677]  [] ? SyS_futex+0x81/0x180
[36447.795693]  [] SyS_ioctl+0x79/0x90
[36447.795709]  [] entry_SYSCALL_64_fastpath+0x16/0x71
[36447.795727] Code: fb c0 48 85 c0 49 89 07 74 6c 41 8d 7e ff 31 d2 48 c1 e7
02 eb 07 49 8b 07 48 83 c2 04 49 8b 74 24 08 8d 4b 01 89 db 48 8
d 34 9e <8b> 36 89 34 10 41 23 4c 24 54 48 39 d7 89 cb 75 da 4c 89 ef e8
[36447.795850] RIP  [] radeon_ring_backup+0xda/0x190 [radeon]
[36447.795882]  RSP 
[36447.795893] CR2: c90401d40ffc
[36447.809449] ---[ end trace ffefc2413ee46759 ]---

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

[Bug 95306] Random Blank(black) screens on "Carrizo"

2016-09-09 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #16 from Patrick Laurin  ---
This affects me as well.
HP Pavillion A10-8700P - Carrizo - R6
Linux Manjaro Daniella 16.06 w. kernel 4.4

I can't wait to see this resolved. I can observe that the performance is quite
impressive with this AMDGPU driver (before the black screen happens...)
compared to the proprietary catalyst display driver.

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

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

2016-09-09 Thread bugzilla-dae...@freedesktop.org

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

Michel DÃ¤nzer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Michel DÃ¤nzer  ---
This issue wasn't limited to mobile Bonaire. One interesting hint from bug
97610 is that it works fine with the radeon kernel driver, so maybe it's
related to addrlib or the amdgpu winsys.

Anyway, fixed for now in Git master. Note that you need to start X with the
fixed Mesa, because it affects glamor as well.

Module: Mesa
Branch: master
Commit: 93f3d8e10d712336b86ebe17dafaee0aac7ec429
URL:   
http://cgit.freedesktop.org/mesa/mesa/commit/?id=93f3d8e10d712336b86ebe17dafaee0aac7ec429

Author: Marek OlÅ¡Ã¡k 
Date:   Thu Sep  8 18:21:04 2016 +0200

Revert "radeonsi: enable SDMA on CIK"

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

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

2016-09-09 Thread bugzilla-dae...@freedesktop.org

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

Michel DÃ¤nzer  changed:

   What|Removed |Added

 CC||kai at dev.carbon-project.org

--- Comment #6 from Michel DÃ¤nzer  ---
*** Bug 97610 has been marked as a duplicate of this bug. ***

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

[Bug 97610] [CIK] Fullscreen video with Firefox only shows "tiled pixel garbage"

2016-09-09 Thread bugzilla-dae...@freedesktop.org

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

Michel DÃ¤nzer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from Michel DÃ¤nzer  ---
Looks like this was an SDMA issue.

*** This bug has been marked as a duplicate of bug 97504 ***

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

[Bug 97643] Shader crashes radeon driver and brings the whole system down

2016-09-09 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #5 from smoki  ---

 You can try both mesa and llvm from git, as that is what Iaroslav probably
using.

 12.0.1 mesa and llvm 3.8-rc2 does not sound current, even for stable mesa/llvm
branches.

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

[Bug 97643] Shader crashes radeon driver and brings the whole system down

2016-09-09 Thread bugzilla-dae...@freedesktop.org

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

Michel DÃ¤nzer  changed:

   What|Removed |Added

  Component|Mesa core   |Drivers/Gallium/radeonsi
 QA Contact|mesa-dev at lists.freedesktop. |dri-devel at 
lists.freedesktop
   |org |.org
   Assignee|mesa-dev at lists.freedesktop. |dri-devel at 
lists.freedesktop
   |org |.org

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

[Bug 97639] Intermittent flickering artifacts with AMD R7 260x

2016-09-09 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #2 from Michel DÃ¤nzer  ---
Please attach the corresponding dmesg output.

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

[Bug 97639] Intermittent flickering artifacts with AMD R7 260x

2016-09-09 Thread bugzilla-dae...@freedesktop.org

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

Michel DÃ¤nzer  changed:

   What|Removed |Added

 Attachment #126306|text/x-log  |text/plain
  mime type||

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

[Bug 51381] [drm:atom_op_jump] ERROR atombios stuck in loop for more than 5secs aborting, when disabled via vgaswitcheroo

2016-09-09 Thread bugzilla-dae...@bugzilla.kernel.org

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

--- Comment #48 from Teofilis Martisius  ---
Hi, 

I ran two tests over the weekend.

First, I tried booting up stock 4.8-rc4. glxgears runs fine both on APU and
dGPU. But it fails when I try to turn OFF my dGPU by doing:

echo OFF >/sys/kernel/debug/vgaswitcheroo/switch

dmesg output attached.

Second, I modified 4.8-rc4 & removed my computer from radeon_device.c quirks
list (it has RADEON_PX_QUIRK_DISABLE_PX quirk assigned) and rebooted. dmesg
attached. It does bootup but with DRI_PRIME=1 glxgears displays just a blank
window. dmesg still shows the "atombios stuck in loop" error.

I won't be able to run more tests soon as I bricked the laptop trying to
upgrade BIOS. I plan to repair/recover it but it will take a while.

OS being used is Debian/Sid. I used stock kernel from kernel.org, with 1 line
change in 2nd test. Same laptop as before, described in previous comments. 

I hope any of this helps.

Sincerely,
Teofilis Martisius

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

[Bug 51381] [drm:atom_op_jump] ERROR atombios stuck in loop for more than 5secs aborting, when disabled via vgaswitcheroo

2016-09-09 Thread bugzilla-dae...@bugzilla.kernel.org

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

--- Comment #47 from Teofilis Martisius  ---
Created attachment 232771
  --> https://bugzilla.kernel.org/attachment.cgi?id=232771=edit
dmesg output from 4.8-rc4 with RADEON_PX_QUIRK_DISABLE_PX quirks removed

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

[Bug 51381] [drm:atom_op_jump] ERROR atombios stuck in loop for more than 5secs aborting, when disabled via vgaswitcheroo

2016-09-09 Thread bugzilla-dae...@bugzilla.kernel.org

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

--- Comment #46 from Teofilis Martisius  ---
Created attachment 232761
  --> https://bugzilla.kernel.org/attachment.cgi?id=232761=edit
dmesg output from 4.8-rc4 when turning OFF dGPU via vgaswitcheroo

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

[PATCH 1/2] libdrm: add etnaviv drm support

2016-09-09 Thread Christian Gmeiner

Hi Rob,

2016-09-08 20:52 GMT+02:00 Rob Herring :
> On Thu, Sep 1, 2016 at 2:08 PM, Christian Gmeiner
>  wrote:
>> Hi Emil,
>>
>> thanks a lot for the review.
>>
>> 2016-08-30 15:03 GMT+02:00 Emil Velikov :
>>> On 30 August 2016 at 08:14, Christian Gmeiner
>>>  wrote:
 From: The etnaviv authors 

 Add the libdrm_etnaviv helper library to encapsulate etnaviv-specific 
 interfaces to the DRM.

 Signed-off-by: Christian Gmeiner 
 Signed-off-by: Lucas Stach 
>>> Just double-checking:
>>>  - you've looked that all the relevant freedreno patches have been
>>> ported over, correct ?
>>>  - the feature checking bug (mentioned on IRC) has been fixed ?
>>>
 diff --git a/configure.ac b/configure.ac
 index e3048c7..64f3e6c 100644
 --- a/configure.ac
 +++ b/configure.ac
>>>
 @@ -274,6 +279,9 @@ if test "x$drm_cv_atomic_primitives" = "xnone"; then

 LIBDRM_ATOMICS_NOT_FOUND_MSG($TEGRA, tegra, NVIDIA Tegra, 
 tegra-experimental-api)
 TEGRA=no
 +
 +   LIBDRM_ATOMICS_NOT_FOUND_MSG($ETNAVIV, etnaviv, Vivante, 
 etnaviv-experimental-api)
>>> Reading this hunk reminds me what a bad name I've used. Then again
>>> nothing better comes up atm. If you can think of any please shout.
>>>
 +++ b/etnaviv/Android.mk
>>> Have you tried building/using etna on Android ?
>>>
>>
>> No.. if it is an easy job I would give it a try. Shall I drop it?
>
> But I have. libdrm just needs this patch (for master and N):
>

Great!

> @@ -9,7 +9,7 @@ LOCAL_MODULE_TAGS := optional
>
>  LOCAL_SHARED_LIBRARIES := libdrm
>
> -LOCAL_SRC_FILES := $(LIBDRM_ETNAVIV_FILES)
> +LOCAL_SRC_FILES := $(patsubst %.h, , $(LIBDRM_ETNAVIV_FILES))
>  LOCAL_EXPORT_C_INCLUDE_DIRS := $(LOCAL_PATH)
>
>  LOCAL_CFLAGS := \
>
>
> I've got mesa building on Android, too. It's a few patches so far of
> Android.mk additions and things that break with clang or post 12.0.
> The etnaviv branch also breaks other drivers with the max vertex
> buffer capability addition.
>

Yeah I am aware of that and I am currently working on a fix for that.

thanks
--
Christian Gmeiner, MSc

https://soundcloud.com/christian-gmeiner

88 matches

Mail list logo