[Bug 92836] amdgpu does not resume properly from suspend

2015-11-05 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=92836

--- Comment #2 from Alex Deucher  ---
Please attach your xorg log and dmesg output.

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

[Bug 92836] amdgpu does not resume properly from suspend

2015-11-05 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=92836

--- Comment #1 from Alex Deucher  ---
Can you try kernel 4.3?

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

[Bug 92836] amdgpu does not resume properly from suspend

2015-11-05 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=92836

Bug ID: 92836
   Summary: amdgpu does not resume properly from suspend
   Product: DRI
   Version: XOrg git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: David at WalkerStreet.info

My laptop does not resume properly after a suspend.  The problem seems to be
with the amdgpu kernel module; it's often accompanied by a long stream of dmesg
errors reported.  Here's a sampling:

 [ 1494.980561] amdgpu :00:01.0: GPU fault detected: 146 0x0b020504
 [ 1494.980561] amdgpu :00:01.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x
 [ 1494.980561] amdgpu :00:01.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x
 [ 1494.980561] VM fault (0x00, vmid 0) at page 0, read from '' (0x)
(0)
 [ 1494.995478] systemd-journald[498]: /dev/kmsg buffer overrun, some messages
lost.
 [ 1494.980561] amdgpu :00:01.0: GPU fault detected: 146 0x0b0a4004
 [ 1494.980561] amdgpu :00:01.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x
 [ 1494.980561] amdgpu :00:01.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x
 [ 1494.980561] VM fault (0x00, vmid 0) at page 0, read from '' (0x)
(0)
 [ 1494.995486] systemd-journald[498]: /dev/kmsg buffer overrun, some messages
lost.

Any ideas?  I'm running the 4.2.4-1-default under openSUSE Tumbleweed.  Here's
some hwinfo data:

 09: PCI 01.0: 0300 VGA compatible controller (VGA)  
  [Created at pci.366]
  Unique ID: vSkL.bMI5Iw7ysWD
  SysFS ID: /devices/pci:00/:00:01.0
  SysFS BusID: :00:01.0
  Hardware Class: graphics card
  Model: "ATI Carrizo"
  Vendor: pci 0x1002 "ATI Technologies Inc"
  Device: pci 0x9874 "Carrizo"
  SubVendor: pci 0x103c "Hewlett-Packard Company"
  SubDevice: pci 0x80af 
  Revision: 0xc5
  Driver: "amdgpu"
  Driver Modules: "drm"
  Memory Range: 0xe000-0xefff (ro,non-prefetchable)
  Memory Range: 0xf000-0xf07f (ro,non-prefetchable)
  I/O Ports: 0xf000-0xf0ff (rw)
  Memory Range: 0xff70-0xff73 (rw,non-prefetchable)
  Memory Range: 0xff74-0xff75 (ro,non-prefetchable,disabled)
  IRQ: 47 (129945 events)
  Module Alias: "pci:v1002d9874sv103Csd80AFbc03sc00i00"
  Driver Info #0:
Driver Status: amdgpu is active
Driver Activation Cmd: "modprobe amdgpu"
  Config Status: cfg=new, avail=yes, need=no, active=unknown

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

Mobility Radeon HD 4530/4570/545v: flicker in 1920x1080

2015-11-05 Thread Pavel Machek 


> RADEON_PLL_PREFER_MINM_OVER_MAXP).
> >>>The flickering would vanish completely if that's the reason for the issue
> >>>you are seeing.
> >>>Try setting ref_div_min and ref_div_max to 2 in
> >>>  radeon_compute_pll_avivo().
> >>Ok, I did this, but no luck, still flickers. But the flicker only
> >>happens when something changes on screen, like dragging a big
> >>window. Is that consistent with wrong PLL timings?
> >Does it go away with radeon.dpm=0?  Sounds more like either memory
> >reclocking happening outside of vblank, or underflow to the display
> >controllers.
> 
> Sounds like my suspicion was right, that doesn't seem to be a PLL issue
> after all.
> 
> Just to rule out the obvious your system works fine with windows and you
> don't have a extra long cable for the monitor or something like
>this?

Cable is something like 2 meters. It does not seem to be EMI, because
it only happens when the display is being updated.

The system had some thermal issues before, but a) there's big fan
cooling it now and b) it does not get worse with more usage. I don't
think its heat.

I don't have Windows for a test, sorry.

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Mobility Radeon HD 4530/4570/545v: flicker in 1920x1080

2015-11-05 Thread Pavel Machek 
Hi!

> >> The flickering would vanish completely if that's the reason for the issue
> >> you are seeing.
> >
> >> Try setting ref_div_min and ref_div_max to 2 in
> >>  radeon_compute_pll_avivo().
> >
> > Ok, I did this, but no luck, still flickers. But the flicker only
> > happens when something changes on screen, like dragging a big
> > window. Is that consistent with wrong PLL timings?
> 
> Does it go away with radeon.dpm=0?  Sounds more like either memory
> reclocking happening outside of vblank, or underflow to the display
> controllers.

No, it does not:

pavel at half:~$ cat /proc/cmdline
BOOT_IMAGE=(hd0,2)/l/linux/arch/x86/boot/bzImage root=/dev/sda4
resume=/dev/sda1 radeon.dpm=0

..and same issue. And yes, it looks like an underflow to me. How can I
debug reclocking / underflows?

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[RFC PATCH 7/7] drm/tegra: tegra: remove redundant "depends on RESET_CONTROLLER"

2015-11-05 Thread Masahiro Yamada 
ARCH_TEGRA selects RESET_CONTROLLER.
The dependency "depends on RESET_CONTROLLER" is already met.

Signed-off-by: Masahiro Yamada 
---

 drivers/gpu/drm/tegra/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/tegra/Kconfig b/drivers/gpu/drm/tegra/Kconfig
index 74d9d62..a188994 100644
--- a/drivers/gpu/drm/tegra/Kconfig
+++ b/drivers/gpu/drm/tegra/Kconfig
@@ -3,7 +3,6 @@ config DRM_TEGRA
depends on ARCH_TEGRA || (ARM && COMPILE_TEST)
depends on COMMON_CLK
depends on DRM
-   depends on RESET_CONTROLLER
select DRM_KMS_HELPER
select DRM_MIPI_DSI
select DRM_PANEL
-- 
1.9.1

[RFC PATCH 6/7] drm/rockchip: remove redundant "depends on RESET_CONTROLLER"

2015-11-05 Thread Masahiro Yamada 
ARCH_ROCKCHIP selects RESET_CONTROLLER.
The dependency "depends on RESET_CONTROLLER" is already met.

Signed-off-by: Masahiro Yamada 
---

 drivers/gpu/drm/rockchip/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 35215f6..cb21e38 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -1,7 +1,6 @@
 config DRM_ROCKCHIP
tristate "DRM Support for Rockchip"
depends on DRM && ROCKCHIP_IOMMU
-   depends on RESET_CONTROLLER
select DRM_KMS_HELPER
select DRM_KMS_FB_HELPER
select DRM_PANEL
-- 
1.9.1

[RFC PATCH 5/7] drm/sti: replace "select RESET_CONTROLLER" with "depends on ..."

2015-11-05 Thread Masahiro Yamada 
RESET_CONTROLLER should be select'ed by SoCs that support reset
controllers.  Use "depends on RESET_CONTROLLER" to describe dependency
between two drivers.

Signed-off-by: Masahiro Yamada 
---

 drivers/gpu/drm/sti/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/sti/Kconfig b/drivers/gpu/drm/sti/Kconfig
index fbccc10..27daa8f 100644
--- a/drivers/gpu/drm/sti/Kconfig
+++ b/drivers/gpu/drm/sti/Kconfig
@@ -1,7 +1,7 @@
 config DRM_STI
tristate "DRM Support for STMicroelectronics SoC stiH41x Series"
-   depends on DRM && (SOC_STIH415 || SOC_STIH416 || ARCH_MULTIPLATFORM) && 
HAVE_DMA_ATTRS
-   select RESET_CONTROLLER
+   depends on DRM && (SOC_STIH415 || SOC_STIH416 || ARCH_MULTIPLATFORM) && 
\
+   HAVE_DMA_ATTRS && RESET_CONTROLLER
select DRM_KMS_HELPER
select DRM_GEM_CMA_HELPER
select DRM_KMS_CMA_HELPER
-- 
1.9.1

[RFC PATCH 0/7] reset: make RESET_CONTROLLER a select'ed option

2015-11-05 Thread Masahiro Yamada 
When I was implementing a new reset controller for my SoCs,
I struggled to make my sub-menu shown under the reset
controller menu.
I noticed the Kconfig in reset sub-system are screwed up due to two
config options (ARCH_HAS_RESET_CONTROLLER and RESET_CONTROLLER).

I think only the former should be select'ed by relevant SoCs,
but in fact the latter is also select'ed here and there.
Mixing "select" to a user-configurable option is a mess.

Finally, I started to wonder whether it could be more simpler?

The first patch drops ARCH_HAS_RESET_CONTROLLER.
RESET_CONTROLLER should be directly selected by SoCs.

The rest of this series are minor clean ups in other
sub-systems.
I can postpone them if changes over cross sub-systems
are not preferred.



Masahiro Yamada (7):
  reset: drop ARCH_HAS_RESET_CONTROLLER
  spi: sunxi: remove redundant "depends on RESET_CONTROLLER"
  spi: tegra: remove redundant "depends on RESET_CONTROLLER"
  pinctrl: sunxi: remove redundant "depends on RESET_CONTROLLER"
  drm/sti: replace "select RESET_CONTROLLER" with "depends on ..."
  drm/rockchip: remove redundant "depends on RESET_CONTROLLER"
  drm/tegra: tegra: remove redundant "depends on RESET_CONTROLLER"

 arch/arm/Kconfig |  3 +--
 arch/arm/mach-berlin/Kconfig |  2 +-
 arch/arm/mach-imx/Kconfig|  2 +-
 arch/arm/mach-mmp/Kconfig|  4 ++--
 arch/arm/mach-prima2/Kconfig |  2 +-
 arch/arm/mach-rockchip/Kconfig   |  2 +-
 arch/arm/mach-sti/Kconfig|  1 -
 arch/arm/mach-sunxi/Kconfig  |  1 -
 arch/arm/mach-tegra/Kconfig  |  1 -
 arch/arm64/Kconfig.platforms |  3 +--
 arch/mips/Kconfig|  4 +---
 drivers/gpu/drm/rockchip/Kconfig |  1 -
 drivers/gpu/drm/sti/Kconfig  |  4 ++--
 drivers/gpu/drm/tegra/Kconfig|  1 -
 drivers/pinctrl/sunxi/Kconfig|  2 --
 drivers/reset/Kconfig| 12 +++-
 drivers/reset/sti/Kconfig|  1 -
 drivers/spi/Kconfig  |  6 ++
 18 files changed, 20 insertions(+), 32 deletions(-)

-- 
1.9.1

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

2015-11-05 Thread Rob Herring 
On Mon, Nov 02, 2015 at 10:09:25AM +0800, Jitao Shi wrote:
> Add documentation for DT properties supported by
> ps8640 DSI-eDP converter.
> 
> Signed-off-by: Jitao Shi 

Acked-by: Rob Herring 

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

[Bug 92790] Radeon.mst error

2015-11-05 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=92790

--- Comment #2 from Adrian <A.Fiergolski+bugzilla at gmail.com> ---
I have tried to run the newest kernel 4.3.0
(http://ubuntuhandbook.org/index.php/2015/11/linux-kernel-4-3-released/) and
got exactly the same issues.

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

[PATCH 3/3] drm/radeon: Only prompt for enabling PAT when we'd allow write-combining

2015-11-05 Thread Michel Dänzer 
From: Michel Dänzer 

No use bothering users about this for whom we disable write-combining for
other reasons anyway.

Signed-off-by: Michel Dänzer 
---
 drivers/gpu/drm/radeon/radeon_object.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_object.c 
b/drivers/gpu/drm/radeon/radeon_object.c
index dda2ecf..84d4563 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -241,8 +241,9 @@ int radeon_bo_create(struct radeon_device *rdev,
 #warning Please enable CONFIG_MTRR and CONFIG_X86_PAT for better performance \
 thanks to write-combining

-   DRM_INFO_ONCE("Please enable CONFIG_MTRR and CONFIG_X86_PAT for "
- "better performance thanks to write-combining\n");
+   if (bo->flags & RADEON_GEM_GTT_WC)
+   DRM_INFO_ONCE("Please enable CONFIG_MTRR and CONFIG_X86_PAT for 
"
+ "better performance thanks to write-combining\n");
bo->flags &= ~(RADEON_GEM_GTT_WC | RADEON_GEM_GTT_UC);
 #endif

-- 
2.6.2

[PATCH 2/3] drm/radeon: Always disable RADEON_GEM_GTT_UC along with RADEON_GEM_GTT_WC

2015-11-05 Thread Michel Dänzer 
From: Michel Dänzer 

Write-combining is a CPU feature. From the GPU POV, these both simply
mean no GPU<->CPU cache coherency.

Signed-off-by: Michel Dänzer 
---
 drivers/gpu/drm/radeon/radeon_object.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_object.c 
b/drivers/gpu/drm/radeon/radeon_object.c
index a35f5af..dda2ecf 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -231,7 +231,7 @@ int radeon_bo_create(struct radeon_device *rdev,
/* XXX: Write-combined CPU mappings of GTT seem broken on 32-bit
 * See https://bugs.freedesktop.org/show_bug.cgi?id=84627
 */
-   bo->flags &= ~RADEON_GEM_GTT_WC;
+   bo->flags &= ~(RADEON_GEM_GTT_WC | RADEON_GEM_GTT_UC);
 #elif defined(CONFIG_X86) && !defined(CONFIG_X86_PAT)
/* Don't try to enable write-combining when it can't work, or things
 * may be slow
@@ -243,7 +243,7 @@ int radeon_bo_create(struct radeon_device *rdev,

DRM_INFO_ONCE("Please enable CONFIG_MTRR and CONFIG_X86_PAT for "
  "better performance thanks to write-combining\n");
-   bo->flags &= ~RADEON_GEM_GTT_WC;
+   bo->flags &= ~(RADEON_GEM_GTT_WC | RADEON_GEM_GTT_UC);
 #endif

radeon_ttm_placement_from_domain(bo, domain);
-- 
2.6.2

[PATCH 1/3] drm/radeon: Disable uncacheable CPU mappings of GTT with RV6xx

2015-11-05 Thread Michel Dänzer 
From: Michel Dänzer 

They reportedly cause random GPU hangs.

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

Cc: stable at vger.kernel.org
Signed-off-by: Michel Dänzer 
---
 drivers/gpu/drm/radeon/radeon_object.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/radeon/radeon_object.c 
b/drivers/gpu/drm/radeon/radeon_object.c
index d302488..a35f5af 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -221,6 +221,12 @@ int radeon_bo_create(struct radeon_device *rdev,
if (!(rdev->flags & RADEON_IS_PCIE))
bo->flags &= ~(RADEON_GEM_GTT_WC | RADEON_GEM_GTT_UC);

+   /* Write-combined CPU mappings of GTT cause GPU hangs with RV6xx
+* See https://bugs.freedesktop.org/show_bug.cgi?id=91268
+*/
+   if (rdev->family >= CHIP_RV610 && rdev->family <= CHIP_RV635)
+   bo->flags &= ~(RADEON_GEM_GTT_WC | RADEON_GEM_GTT_UC);
+
 #ifdef CONFIG_X86_32
/* XXX: Write-combined CPU mappings of GTT seem broken on 32-bit
 * See https://bugs.freedesktop.org/show_bug.cgi?id=84627
-- 
2.6.2

[PATCH] drm/ttm: Set CPU caching mode to cached for BOs being swapped out

2015-11-05 Thread Michel Dänzer 
From: Michel Dänzer 

I ran into the BUG_ON in ttm_tt_swapout, presumably the BO being swapped
out was using a write-combined CPU mapping.

Instead of BUGging out, just set the caching mode to what's needed.

Signed-off-by: Michel Dänzer 
---
 drivers/gpu/drm/ttm/ttm_tt.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 4e19d0f..c2794eb 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -334,7 +334,8 @@ int ttm_tt_swapout(struct ttm_tt *ttm, struct file 
*persistent_swap_storage)
int ret = -ENOMEM;

BUG_ON(ttm->state != tt_unbound && ttm->state != tt_unpopulated);
-   BUG_ON(ttm->caching_state != tt_cached);
+
+   ttm_tt_set_caching(ttm, tt_cached);

if (!persistent_swap_storage) {
swap_storage = shmem_file_setup("ttm swap",
-- 
2.6.2

[PATCH RFC] drm/atomic: Disable planes on blanked CRTC and enable on unblank

2015-11-05 Thread Jyri Sarha 
Disable planes if they are on to be blanked CRTC and enable them when
the CRTC is turned back on by DMPS.

This is desirable on HW that loses its context on blanking. When
planes are enabled and disabled with the associated CRTCs, there is no
need to restore the plane context in runtime_resume callback.

Signed-off-by: Jyri Sarha 
---
We would need something like this to get rid off OMAPDSS somewhat
messy runtime_resume code. How does this look, could this generic
solution be refined to be acceptable to mainline, or should we start
looking a local solution to omapdrm?

BTW, with this patch the planes are sometimes disabled multiple
times. So probably a boolean (or maybe two like on crtc) should be
added to drm_plane_state to track and avoid multiple shutdowns.

 drivers/gpu/drm/drm_atomic_helper.c | 19 +--
 include/drm/drm_atomic_helper.h |  7 +++
 2 files changed, 24 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index aecb5d6..92fcaef 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1994,8 +1994,8 @@ EXPORT_SYMBOL(drm_atomic_helper_page_flip);
  *
  * This is the main helper function provided by the atomic helper framework for
  * implementing the legacy DPMS connector interface. It computes the new 
desired
- * ->active state for the corresponding CRTC (if the connector is enabled) and
- *  updates it.
+ * ->active state for the corresponding CRTC and planes on it (if the connector
+ * is enabled) and updates it.
  *
  * Returns:
  * Returns 0 on success, negative errno numbers on failure.
@@ -2008,6 +2008,7 @@ int drm_atomic_helper_connector_dpms(struct drm_connector 
*connector,
struct drm_crtc_state *crtc_state;
struct drm_crtc *crtc;
struct drm_connector *tmp_connector;
+   struct drm_plane *tmp_plane;
int ret;
bool active = false;
int old_mode = connector->dpms;
@@ -2046,6 +2047,20 @@ retry:
}
crtc_state->active = active;

+   /* Collect associated plane states to global state object. */
+   list_for_each_entry(tmp_plane, >plane_list, head) {
+   struct drm_plane_state *plane_state;
+
+   if (tmp_plane->state->crtc != crtc)
+   continue;
+
+   plane_state = drm_atomic_get_plane_state(state, tmp_plane);
+   if (IS_ERR(plane_state)) {
+   ret = PTR_ERR(plane_state);
+   goto fail;
+   }
+   }
+
ret = drm_atomic_commit(state);
if (ret != 0)
goto fail;
diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h
index 11266d14..89c327f 100644
--- a/include/drm/drm_atomic_helper.h
+++ b/include/drm/drm_atomic_helper.h
@@ -173,6 +173,13 @@ drm_atomic_plane_disabling(struct drm_plane *plane,
(plane->state->crtc != NULL && plane->state->fb == NULL));

/*
+* If the plane is on a crtc that is not going to be active the plane
+* it self can be disabled too.
+*/
+   if (plane->state->crtc && !plane->state->crtc->state->active)
+   return true;
+
+   /*
 * When using the transitional helpers, old_state may be NULL. If so,
 * we know nothing about the current state and have to assume that it
 * might be enabled.
-- 
1.9.1

[Intel-gfx] [PATCH] drm: Use userspace compatible type in fourcc_mod_code macro

2015-11-05 Thread Rob Clark 
On Thu, Nov 5, 2015 at 7:51 AM, Jani Nikula  
wrote:
> On Wed, 23 Sep 2015, Ville Syrjälä  wrote:
>> On Wed, Sep 23, 2015 at 10:10:31AM +0100, Tvrtko Ursulin wrote:
>>> From: Tvrtko Ursulin 
>>>
>>> __u64 should be used instead of u64.
>>>
>>> Feature originally added in:
>>>
>>> commit e3eb3250d84ef97b766312345774367b6a310db8
>>> Author: Rob Clark 
>>> Date:   Thu Feb 5 14:41:52 2015 +
>>>
>>> drm: add support for tiled/compressed/etc modifier in addfb2
>>>
>>> Signed-off-by: Tvrtko Ursulin 
>>> Cc: Rob Clark 
>>> Cc: Daniel Stone 
>>> Cc: Daniel Vetter 
>>> Cc: dri-devel at lists.freedesktop.org
>>> Cc: stable at vger.kernel.org
>>
>> Reviewed-by: Ville Syrjälä 
>
> Pushed to our topic/drm-fixes branch, thanks for the patch and review.

and I've pushed the libdrm part

BR,
-R

> BR,
> Jani.
>
>>
>>> ---
>>>  include/uapi/drm/drm_fourcc.h | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
>>> index 8c5e8b91a3cb..0b69a7753558 100644
>>> --- a/include/uapi/drm/drm_fourcc.h
>>> +++ b/include/uapi/drm/drm_fourcc.h
>>> @@ -158,7 +158,7 @@
>>>  /* add more to the end as needed */
>>>
>>>  #define fourcc_mod_code(vendor, val) \
>>> -u64)DRM_FORMAT_MOD_VENDOR_## vendor) << 56) | (val & 
>>> 0x00ffULL))
>>> +__u64)DRM_FORMAT_MOD_VENDOR_## vendor) << 56) | (val & 
>>> 0x00ffULL))
>>>
>>>  /*
>>>   * Format Modifier tokens:
>>> --
>>> 2.5.1
>>>
>>> ___
>>> Intel-gfx mailing list
>>> Intel-gfx at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Jani Nikula, Intel Open Source Technology Center
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[RFC v5 01/12] dt-bindings: drm/mediatek: Add Mediatek display subsystem dts binding

2015-11-05 Thread Philipp Zabel 
Am Mittwoch, den 04.11.2015, 21:28 -0600 schrieb Rob Herring:
> On Wed, Nov 04, 2015 at 12:44:58PM +0100, Philipp Zabel wrote:
> > From: CK Hu 
> > 
> > Add device tree binding documentation for the display subsystem in
> > Mediatek MT8173 SoCs.
> > 
> > Signed-off-by: CK Hu 
> > Signed-off-by: Philipp Zabel 
> 
> If this wasn't an RFC, I'd ack it. :) One thing you missed below though.

Alright, thanks for your help in sorting these bindings out.

[...]
> > diff --git 
> > a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt 
> > b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> > new file mode 100644
> > index 000..cc3d884
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
[...]
> > +DISP function blocks
> > +
> > +
> > +A display stream starts at a source function block that reads pixel data 
> > from
> > +memory and ends with a sink function block that drives pixels on a display
> > +interface, or writes pixels back to memory. All DISP function blocks have
> > +their own register space, interrupt, and clock gate. The blocks that can
> > +access memory additionally have to list the IOMMU and local arbiter they 
> > are
> > +connected to.
> > +
> > +For a description of the display interface sink function blocks, see
> > +Documentation/devicetree/bindings/drm/mediatek/mediatek,dsi.txt and
> > +Documentation/devicetree/bindings/drm/mediatek/mediatek,dpi.txt.
> 
> Need to update these paths.

Will do.

regards
Philipp

[RFC v5 02/12] drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.

2015-11-05 Thread Philipp Zabel 
Hi Daniel,

Am Donnerstag, den 05.11.2015, 02:49 +0800 schrieb Daniel Kurtz:
> Hi Philipp,
> 
> A bunch of review comments inline.

A bunch indeed. Thank you for the feedback.

> On Wed, Nov 4, 2015 at 7:44 PM, Philipp Zabel  
> wrote:
[...]
> > +struct mtk_drm_crtc {
> > +   struct drm_crtc base;
> > +   unsigned intpipe;
> 
> There is one pipe too many :-)
> I think this one is not used."
> 
> > +   boolenabled;
> > +   struct mtk_crtc_ddp_context *ctx;
> 
> I think you should be able to just embed the "mtk_crtc_ddp_context"
> right into mtk_drm_crtc.
> Or maybe just get rid of mtk_crtc_ddp_context completely and just use
> mtk_drm_crtc eveywhere.

I'll combine them and get rid of the superfluous pipe.

[...]
> > +static void mtk_crtc_ddp_hw_init(struct mtk_drm_crtc *crtc)
> > +{
[...]
> > +   /* disp_mtcmos */
> > +   ret = pm_runtime_get_sync(drm->dev);
> > +   if (ret < 0)
> > +   DRM_ERROR("Failed to enable power domain: %d\n", ret);
> > +
> > +   mtk_ddp_clock_on(ctx->mutex_dev);
> > +   mtk_crtc_ddp_power_on(ctx);
> 
> get_sync(), clock_on() and ddp_power_on() really can fail; we are just
> ignoring errors here.
> Since they can fail, shouldn't they be moved out of the atomic
> "->enable()" path into the ->check() path that is allowed to fail?

You suggest I move them into atomic_check?

To me it sounds like this should not be called from check, but from the
drm_mode_config_funcs atomic_commit callback, right after calling 
drm_atomic_helper_prepare_planes. But there is no prepare equivalent to
drm_atomic_helper_commit_modeset_enables.

> > +
> > +   DRM_INFO("mediatek_ddp_ddp_path_setup\n");
> > +   for (i = 0; i < (ctx->ddp_comp_nr - 1); i++) {
> 
> nit: the inner () are not necessary.

Will remove those.

> > +   mtk_ddp_add_comp_to_path(ctx->config_regs, ctx->pipe,
> > +ctx->ddp_comp[i].funcs->comp_id,
> > +ctx->ddp_comp[i+1].funcs->comp_id);
> > +   mtk_ddp_add_comp_to_mutex(ctx->mutex_dev, ctx->pipe,
> > + ctx->ddp_comp[i].funcs->comp_id,
> > + 
> > ctx->ddp_comp[i+1].funcs->comp_id);
> > +   }
> 
> Do you really have to do this here in the enable path?  This looks
> like something that should be done in bind()?
> 
> Perhaps all we really need here is to walk the path and write to
> DISP_REG_MUTEX_EN at the end of mtk_ddp_add_comp_to_mutex().
> By the way, where are those bits cleared in the disable path?

Disabling or changing the path is not implemented, the currently static
setup could well be moved into bind().

[...]
> > +static void mtk_crtc_ddp_hw_fini(struct mtk_drm_crtc *crtc)
> > +{
[...]
> > +   pm_runtime_put_sync(drm->dev);
> 
> Why sync?

I can think of no reason, will use the async version here.

[...]
> > +static void mtk_drm_crtc_disable(struct drm_crtc *crtc)
> > +{
> > +   struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
> > +   struct mtk_crtc_state *state = to_mtk_crtc_state(crtc->state);
> > +
> > +   DRM_INFO("mtk_drm_crtc_disable %d\n", crtc->base.id);
> > +   if (WARN_ON(!mtk_crtc->enabled))
> > +   return;
> > +
> > +   mtk_crtc_ddp_hw_fini(mtk_crtc);
> > +   mtk_crtc->do_flush = false;
> > +   if (state->event)
> > +   mtk_drm_crtc_finish_page_flip(mtk_crtc);
> 
> It is a bit awkward to send the page flip event before the actual page
> flip has completed (in this case, for a page flip that you are
> canceling by disabling the crtc).
> Would it be better to wait for vblank here in crtc_disable instead?

Yes, I will wait for vblank here instead.

[...]
> > +static void mtk_drm_crtc_atomic_begin(struct drm_crtc *crtc,
> > + struct drm_crtc_state *old_crtc_state)
> > +{
> > +   struct mtk_crtc_state *state = to_mtk_crtc_state(crtc->state);
> > +
> > +   if (state->base.event) {
> > +   state->base.event->pipe = drm_crtc_index(crtc);
> > +   WARN_ON(drm_crtc_vblank_get(crtc) != 0);
> > +   state->event = state->base.event;
> > +   state->base.event = NULL;
> 
> Hmm. Why are we "stealing" event from drm_crtc_state and handing it
> over to the wrapper mtk_crtc_state?
> Won't we still be able to retrieve state->base.event later when we
> need it in the mtk_drm_crtc_finish_page_flip?

Hmm, good point. I'll try that.

[...]
> > +static void mtk_crtc_ddp_irq(struct mtk_crtc_ddp_context *ctx)
> 
> ==> So, this is the part of the driver that makes me the most nervous.
> Why are we writing the actual hardware registers in the *vblank
> interrupt handler*?!
> Every other display controller that I've ever seen has shadow
> registers that are used to stage a page flip at the next vblank.
> Are you

[RFC PATCH 0/7] reset: make RESET_CONTROLLER a select'ed option

2015-11-05 Thread Arnd Bergmann 
On Thursday 05 November 2015 20:15:21 Masahiro Yamada wrote:
> When I was implementing a new reset controller for my SoCs,
> I struggled to make my sub-menu shown under the reset
> controller menu.
> I noticed the Kconfig in reset sub-system are screwed up due to two
> config options (ARCH_HAS_RESET_CONTROLLER and RESET_CONTROLLER).
> 
> I think only the former should be select'ed by relevant SoCs,
> but in fact the latter is also select'ed here and there.
> Mixing "select" to a user-configurable option is a mess.
> 
> Finally, I started to wonder whether it could be more simpler?
> 
> The first patch drops ARCH_HAS_RESET_CONTROLLER.
> RESET_CONTROLLER should be directly selected by SoCs.
> 
> The rest of this series are minor clean ups in other
> sub-systems.
> I can postpone them if changes over cross sub-systems
> are not preferred.

Thanks a lot for picking up this topic! It has been annoying me
for a while and I have submitted an experimental patch some time
ago, but not finished it myself.

For some reason, I only see a subset of your patches here (patch 1, 4 and 6),
so I don't know exactly what you did. For reference, you can find
my original patch below. Please check if I did things that your
series doesn't do, and whether those are still needed.

Arnd

commit 7983ffe5e07a5aac0c9bdd657858e3b2b9842b30
Author: Arnd Bergmann 
Date:   Tue Feb 24 15:30:30 2015 +0100

rework RESET_CONTROLLER handling

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 2f5f6d0b09a6..ab137ae8dcc8 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -319,6 +319,7 @@ choice

 config ARCH_MULTIPLATFORM
bool "Allow multiple platforms to be selected"
+   select ARCH_HAS_RESET_CONTROLLER
select ARCH_WANT_OPTIONAL_GPIOLIB
select ARM_HAS_SG_CHAIN
select ARM_PATCH_PHYS_VIRT
diff --git a/arch/arm/mach-berlin/Kconfig b/arch/arm/mach-berlin/Kconfig
index 344434ca366c..2dc8f3df39e6 100644
--- a/arch/arm/mach-berlin/Kconfig
+++ b/arch/arm/mach-berlin/Kconfig
@@ -1,6 +1,5 @@
 menuconfig ARCH_BERLIN
bool "Marvell Berlin SoCs" if ARCH_MULTI_V7
-   select ARCH_HAS_RESET_CONTROLLER
select ARCH_REQUIRE_GPIOLIB
select ARM_GIC
select DW_APB_ICTL
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index 8ceda2844c4f..1b1134adc188 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -58,7 +58,6 @@ config HAVE_IMX_MMDC

 config HAVE_IMX_SRC
def_bool y if SMP
-   select ARCH_HAS_RESET_CONTROLLER

 config IMX_HAVE_IOMUX_V1
bool
diff --git a/arch/arm/mach-mmp/Kconfig b/arch/arm/mach-mmp/Kconfig
index 4773fe1d8b3f..116502d776ab 100644
--- a/arch/arm/mach-mmp/Kconfig
+++ b/arch/arm/mach-mmp/Kconfig
@@ -113,6 +113,7 @@ config MACH_MMP_DT
select PINCTRL_SINGLE
select COMMON_CLK
select ARCH_HAS_RESET_CONTROLLER
+   select RESET_CONTROLLER
select CPU_MOHAWK
help
  Include support for Marvell MMP2 based platforms using
@@ -125,6 +126,7 @@ config MACH_MMP2_DT
select PINCTRL
select PINCTRL_SINGLE
select ARCH_HAS_RESET_CONTROLLER
+   select RESET_CONTROLLER
select CPU_PJ4
help
  Include support for Marvell MMP2 based platforms using
diff --git a/arch/arm/mach-prima2/Kconfig b/arch/arm/mach-prima2/Kconfig
index 9ab8932403e5..00adfc4a5cd6 100644
--- a/arch/arm/mach-prima2/Kconfig
+++ b/arch/arm/mach-prima2/Kconfig
@@ -1,12 +1,12 @@
 menuconfig ARCH_SIRF
bool "CSR SiRF" if ARCH_MULTI_V7
-   select ARCH_HAS_RESET_CONTROLLER
select ARCH_REQUIRE_GPIOLIB
select GENERIC_IRQ_CHIP
select NO_IOPORT_MAP
select REGMAP
select PINCTRL
select PINCTRL_SIRF
+   select RESET_CONTROLLER
help
  Support for CSR SiRFprimaII/Marco/Polo platforms

diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index ae4eb7cc4bcc..17d2df427c3c 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -2,7 +2,6 @@ config ARCH_ROCKCHIP
bool "Rockchip RK2928 and RK3xxx SOCs" if ARCH_MULTI_V7
select PINCTRL
select PINCTRL_ROCKCHIP
-   select ARCH_HAS_RESET_CONTROLLER
select ARCH_REQUIRE_GPIOLIB
select ARM_AMBA
select ARM_GIC
@@ -12,6 +11,7 @@ config ARCH_ROCKCHIP
select HAVE_ARM_TWD if SMP
select DW_APB_TIMER_OF
select REGULATOR if PM
+   select RESET_CONTROLLER
select ROCKCHIP_TIMER
select ARM_GLOBAL_TIMER
select CLKSRC_ARM_GLOBAL_TIMER_SCHED_CLOCK
diff --git a/arch/arm/mach-sti/Kconfig b/arch/arm/mach-sti/Kconfig
index 125865daaf17..8092f4f84ee6 100644
--- a/arch/arm/mach-sti/Kconfig
+++ b/arch/arm/mach-sti/Kconfig
@@ -6,7 +6,6 @@ menuconfig ARCH_STI
select PINCTRL
select PINCTRL_ST
select MFD_SYSCON
-   select ARCH_HAS_RESET_CONTROLLER
select HAVE_ARM_SCU if SMP
select

[PATCH v9 10/17] phy: Add driver for rockchip Display Port PHY

2015-11-05 Thread Brian Norris 
Hi,

A few updates:

On Tue, Nov 03, 2015 at 05:13:48PM -0800, Brian Norris wrote:
> On Wed, Nov 04, 2015 at 08:48:38AM +0800, Yakir Yang wrote:
> > On 11/03/2015 12:38 PM, Brian Norris wrote:
> > >On Thu, Oct 29, 2015 at 09:58:38AM +0800, Yakir Yang wrote:
> > >(FYI, I came across this by inspection when comparing Heiko's
> > >'somewhat-stable' branch [1] with this series. The former brings up eDP
> > >fine on veyron-jaq, whereas this one doesn't yet, even with the above
> > >change. Still debugging the issue.)

Some time after the above comment, I managed to kill the panel on my
Jaq :( I think the wiring around the hinge was a bit flaky, and it
finally went out for good.

> > Hmm... I'm not sure whether your eDP screen have the hotplug signal, so I
> 
> I believe hotplug is hooked up but...
> 
> > think you can try to add "analogix,force-hpd" flag into
> > rk3288-veyron-jaq.dts
> > 
> >  {
> > analogix,need-force-hpd;
> > }
> 
> ...already tried, just in case. No luck.

However, now when testing a different Jaq device, now this series +
Heiko's DTS updates + the "analogix,force-hpd" (i.e., [1]) works fine,
modulo a few log warnings, some of which are probably expected (for
instance, I believe the EDID is known not-so-helpful). Snippets:

[3.170176] rockchip-dp ff97.dp: AUX CH command reply failed!
[3.178058] rockchip-dp ff97.dp: AUX CH command reply failed!
[3.184166] rockchip-dp ff97.dp: unable to handle edid

and later:

[3.953300] rockchip-dp ff97.dp: EDID data does not include any 
extensions.
[3.966731] rockchip-dp ff97.dp: EDID data does not include any 
extensions.
[3.979409] rockchip-dp ff97.dp: EDID data does not include any 
extensions.
[3.998730] rockchip-dp ff97.dp: Link Training Clock Recovery success
[4.007046] rockchip-dp ff97.dp: Link Training success!
[4.115040] rockchip-dp ff97.dp: Timeout of video streamclk ok
[4.121211] rockchip-dp ff97.dp: unable to config video
[4.127616] rockchip-dp ff97.dp: EDID data does not include any 
extensions.


So, I'll chalk that earlier failure up to a hardware failure (or
possibly a still yet-undiagnosed hardware difference; my new Jaq has
some small differences from the previous unit).

Also, it's still not real clear why HPD isn't working upstream (and we
have to use the "force-hpd" property), when it appears to work on our
downstream Chrome OS tree.

Finally, I'll leave you with some small bits I've noticed from exploring
this issue on Jaq:

 * The Chrome OS driver for this IP has a much longer timeout in (the
   equivalent of) analogix_dp_detect_hpd; it polls in 10-20 ms intervals
   (rather than 10-11 us) and takes something around 60 to 120 ms to
   notice the panel.
 * AFAICT, the Chrome OS driver never actually used the HPD interrupt;
   it was only polling the HPD status bit. So I can't claim that the
   functionality that Yakir is supporting here has ever been tested on
   these platforms. (Now, I'm not sure this is extremely important,
   since we still can fall back to polled status checks; see
   drm_kms_helper_poll_init().)

That's all I've got for now.

Regards,
Brian

[1] https://github.com/mmind/linux-rockchip/commits/tmp/analogixdp-veyron

plus this diff:

diff --git a/arch/arm/boot/dts/rk3288-veyron-jaq.dts 
b/arch/arm/boot/dts/rk3288-veyron-jaq.dts
index 5c97e3153526..e77ae4c5531e 100644
--- a/arch/arm/boot/dts/rk3288-veyron-jaq.dts
+++ b/arch/arm/boot/dts/rk3288-veyron-jaq.dts
@@ -88,6 +88,18 @@
};
 };

+ {
+   power-supply = <_regulator>;
+};
+
+ {
+   power-supply = <_regulator>;
+};
+
+ {
+   analogix,need-force-hpd;
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_int_l _1 _2>;
diff --git a/drivers/phy/phy-rockchip-dp.c b/drivers/phy/phy-rockchip-dp.c
index c82c22f3d0e1..994189f49db5 100644
--- a/drivers/phy/phy-rockchip-dp.c
+++ b/drivers/phy/phy-rockchip-dp.c
@@ -22,7 +22,7 @@

 #define GRF_SOC_CON12   0x0274

-#define GRF_EDP_REF_CLK_SEL_INTER_HIWORD_MASK   BIT(4)
+#define GRF_EDP_REF_CLK_SEL_INTER_HIWORD_MASK   BIT(20)
 #define GRF_EDP_REF_CLK_SEL_INTER   BIT(4)

 #define GRF_EDP_PHY_SIDDQ_HIWORD_MASK   BIT(21)

[Intel-gfx] [PATCH] drm: Use userspace compatible type in fourcc_mod_code macro

2015-11-05 Thread Jani Nikula 
On Wed, 23 Sep 2015, Ville Syrjälä  wrote:
> On Wed, Sep 23, 2015 at 10:10:31AM +0100, Tvrtko Ursulin wrote:
>> From: Tvrtko Ursulin 
>> 
>> __u64 should be used instead of u64.
>> 
>> Feature originally added in:
>> 
>> commit e3eb3250d84ef97b766312345774367b6a310db8
>> Author: Rob Clark 
>> Date:   Thu Feb 5 14:41:52 2015 +
>> 
>> drm: add support for tiled/compressed/etc modifier in addfb2
>> 
>> Signed-off-by: Tvrtko Ursulin 
>> Cc: Rob Clark 
>> Cc: Daniel Stone 
>> Cc: Daniel Vetter 
>> Cc: dri-devel at lists.freedesktop.org
>> Cc: stable at vger.kernel.org
>
> Reviewed-by: Ville Syrjälä 

Pushed to our topic/drm-fixes branch, thanks for the patch and review.

BR,
Jani.

>
>> ---
>>  include/uapi/drm/drm_fourcc.h | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
>> index 8c5e8b91a3cb..0b69a7753558 100644
>> --- a/include/uapi/drm/drm_fourcc.h
>> +++ b/include/uapi/drm/drm_fourcc.h
>> @@ -158,7 +158,7 @@
>>  /* add more to the end as needed */
>>  
>>  #define fourcc_mod_code(vendor, val) \
>> -u64)DRM_FORMAT_MOD_VENDOR_## vendor) << 56) | (val & 
>> 0x00ffULL))
>> +__u64)DRM_FORMAT_MOD_VENDOR_## vendor) << 56) | (val & 
>> 0x00ffULL))
>>  
>>  /*
>>   * Format Modifier tokens:
>> -- 
>> 2.5.1
>> 
>> ___
>> Intel-gfx mailing list
>> Intel-gfx at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH 1/3] drm/radeon: Disable uncacheable CPU mappings of GTT with RV6xx

2015-11-05 Thread Alex Deucher 
On Thu, Nov 5, 2015 at 5:41 AM, Christian König  
wrote:
> On 05.11.2015 09:25, Michel Dänzer wrote:
>>
>> From: Michel Dänzer 
>>
>> They reportedly cause random GPU hangs.
>>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91268
>>
>> Cc: stable at vger.kernel.org
>> Signed-off-by: Michel Dänzer 
>
>
> For this series Reviewed-by: Christian König 

Applied.  thanks!

Alex

>
>> ---
>>   drivers/gpu/drm/radeon/radeon_object.c | 6 ++
>>   1 file changed, 6 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/radeon/radeon_object.c
>> b/drivers/gpu/drm/radeon/radeon_object.c
>> index d302488..a35f5af 100644
>> --- a/drivers/gpu/drm/radeon/radeon_object.c
>> +++ b/drivers/gpu/drm/radeon/radeon_object.c
>> @@ -221,6 +221,12 @@ int radeon_bo_create(struct radeon_device *rdev,
>> if (!(rdev->flags & RADEON_IS_PCIE))
>> bo->flags &= ~(RADEON_GEM_GTT_WC | RADEON_GEM_GTT_UC);
>>   + /* Write-combined CPU mappings of GTT cause GPU hangs with RV6xx
>> +* See https://bugs.freedesktop.org/show_bug.cgi?id=91268
>> +*/
>> +   if (rdev->family >= CHIP_RV610 && rdev->family <= CHIP_RV635)
>> +   bo->flags &= ~(RADEON_GEM_GTT_WC | RADEON_GEM_GTT_UC);
>> +
>>   #ifdef CONFIG_X86_32
>> /* XXX: Write-combined CPU mappings of GTT seem broken on 32-bit
>>  * See https://bugs.freedesktop.org/show_bug.cgi?id=84627
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/amdgpu: Fix default page access routing

2015-11-05 Thread Jay Cornwall 
The VM default page (used when a VM translation fails) is allocated in
system memory. The VM is misconfigured to interpret the physical address
as referencing a VRAM physical page.

Route default page accesses to system memory.

Signed-off-by: Jay Cornwall 
Cc:  # v4.2+
---
 drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 1 +
 drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c 
b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
index fab5471..b9836f6 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
@@ -474,6 +474,7 @@ static int gmc_v7_0_gart_enable(struct amdgpu_device *adev)
tmp = REG_SET_FIELD(tmp, VM_L2_CNTL, 
ENABLE_L2_PDE0_CACHE_LRU_UPDATE_BY_WRITE, 1);
tmp = REG_SET_FIELD(tmp, VM_L2_CNTL, EFFECTIVE_L2_QUEUE_SIZE, 7);
tmp = REG_SET_FIELD(tmp, VM_L2_CNTL, CONTEXT1_IDENTITY_ACCESS_MODE, 1);
+   tmp = REG_SET_FIELD(tmp, VM_L2_CNTL, 
ENABLE_DEFAULT_PAGE_OUT_TO_SYSTEM_MEMORY, 1);
WREG32(mmVM_L2_CNTL, tmp);
tmp = REG_SET_FIELD(0, VM_L2_CNTL2, INVALIDATE_ALL_L1_TLBS, 1);
tmp = REG_SET_FIELD(tmp, VM_L2_CNTL2, INVALIDATE_L2_CACHE, 1);
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c 
b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
index 7bc9e9f..cb4e2bb 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
@@ -588,6 +588,7 @@ static int gmc_v8_0_gart_enable(struct amdgpu_device *adev)
tmp = REG_SET_FIELD(tmp, VM_L2_CNTL, 
ENABLE_L2_PDE0_CACHE_LRU_UPDATE_BY_WRITE, 1);
tmp = REG_SET_FIELD(tmp, VM_L2_CNTL, EFFECTIVE_L2_QUEUE_SIZE, 7);
tmp = REG_SET_FIELD(tmp, VM_L2_CNTL, CONTEXT1_IDENTITY_ACCESS_MODE, 1);
+   tmp = REG_SET_FIELD(tmp, VM_L2_CNTL, 
ENABLE_DEFAULT_PAGE_OUT_TO_SYSTEM_MEMORY, 1);
WREG32(mmVM_L2_CNTL, tmp);
tmp = RREG32(mmVM_L2_CNTL2);
tmp = REG_SET_FIELD(tmp, VM_L2_CNTL2, INVALIDATE_ALL_L1_TLBS, 1);
-- 
1.9.1

Mobility Radeon HD 4530/4570/545v: flicker in 1920x1080

2015-11-05 Thread Christian König 
On 04.11.2015 23:13, Alex Deucher wrote:
> On Wed, Nov 4, 2015 at 5:10 PM, Pavel Machek  wrote:
>> Hi!
>>
>>> index dac78ad..b86f06a 100644
>>> --- a/drivers/gpu/drm/radeon/atombios_crtc.c
>>> +++ b/drivers/gpu/drm/radeon/atombios_crtc.c
>>> @@ -569,6 +569,8 @@ static u32 atombios_adjust_pll(struct drm_crtc 
>>> *crtc,
>>>  radeon_crtc->pll_flags = 0;
>>>
>>>  if (ASIC_IS_AVIVO(rdev)) {
>>> +   radeon_crtc->pll_flags |= 
>>> RADEON_PLL_PREFER_MINM_OVER_MAXP;
>>> +
>>>  if ((rdev->family == CHIP_RS600) ||
>>>  (rdev->family == CHIP_RS690) ||
>>>  (rdev->family == CHIP_RS740))
>>>
>> Help.. maybe... it is tricky to tell. It definitely does _not_ fix the
>> issue completely.
> You could also try the old pll algorithm:
 I reverted the patch above, and switched to the old algorithm.

 The flicker is still there. (But maybe its less horrible, like with
 RADEON_PLL_PREFER_MINM_OVER_MAXP).
>>> The flickering would vanish completely if that's the reason for the issue
>>> you are seeing.
>>> Try setting ref_div_min and ref_div_max to 2 in
>>>   radeon_compute_pll_avivo().
>> Ok, I did this, but no luck, still flickers. But the flicker only
>> happens when something changes on screen, like dragging a big
>> window. Is that consistent with wrong PLL timings?
> Does it go away with radeon.dpm=0?  Sounds more like either memory
> reclocking happening outside of vblank, or underflow to the display
> controllers.

Sounds like my suspicion was right, that doesn't seem to be a PLL issue 
after all.

Just to rule out the obvious your system works fine with windows and you 
don't have a extra long cable for the monitor or something like this?

Regards,
Christian.

>
> Alex
>
>> diff --git a/config.32 b/config.32
>> index 00e5dd2..4734158 100644
>> --- a/config.32
>> +++ b/config.32
>> @@ -1090,7 +1090,7 @@ CONFIG_DEVTMPFS_MOUNT=y
>>   CONFIG_PREVENT_FIRMWARE_BUILD=y
>>   CONFIG_FW_LOADER=y
>>   CONFIG_FIRMWARE_IN_KERNEL=y
>> -CONFIG_EXTRA_FIRMWARE="radeon/R700_rlc.bin"
>> +CONFIG_EXTRA_FIRMWARE="radeon/R700_rlc.bin radeon/RV710_smc.bin 
>> radeon/RV710_uvd.bin"
>>   CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware"
>>   # CONFIG_FW_LOADER_USER_HELPER_FALLBACK is not set
>>   CONFIG_ALLOW_DEV_COREDUMP=y
>> diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c 
>> b/drivers/gpu/drm/radeon/atombios_crtc.c
>> index dac78ad..dcc4f4d 100644
>> --- a/drivers/gpu/drm/radeon/atombios_crtc.c
>> +++ b/drivers/gpu/drm/radeon/atombios_crtc.c
>> @@ -569,6 +569,8 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
>>  radeon_crtc->pll_flags = 0;
>>
>>  if (ASIC_IS_AVIVO(rdev)) {
>> +   //radeon_crtc->pll_flags |= RADEON_PLL_PREFER_MINM_OVER_MAXP;
>> +
>>  if ((rdev->family == CHIP_RS600) ||
>>  (rdev->family == CHIP_RS690) ||
>>  (rdev->family == CHIP_RS740))
>> diff --git a/drivers/gpu/drm/radeon/radeon_display.c 
>> b/drivers/gpu/drm/radeon/radeon_display.c
>> index 6743174..bebaf4f 100644
>> --- a/drivers/gpu/drm/radeon/radeon_display.c
>> +++ b/drivers/gpu/drm/radeon/radeon_display.c
>> @@ -947,6 +947,7 @@ void radeon_compute_pll_avivo(struct radeon_pll *pll,
>>  fb_div_max = pll->max_feedback_div;
>>
>>  if (pll->flags & RADEON_PLL_USE_FRAC_FB_DIV) {
>> +   printk("radeon: fractional divider\n");
>>  fb_div_min *= 10;
>>  fb_div_max *= 10;
>>  }
>> @@ -966,6 +967,9 @@ void radeon_compute_pll_avivo(struct radeon_pll *pll,
>>  else
>>  ref_div_max = pll->max_ref_div;
>>
>> +   ref_div_min = 2;
>> +   ref_div_max = 2;
>> +
>>  /* determine allowed post divider range */
>>  if (pll->flags & RADEON_PLL_USE_POST_DIV) {
>>  post_div_min = pll->post_div;
>> @@ -1020,6 +1024,8 @@ void radeon_compute_pll_avivo(struct radeon_pll *pll,
>>  diff = abs(target_clock - (pll->reference_freq * fb_div) /
>>  (ref_div * post_div));
>>
>> +   printk("post_div = %d, diff = %d\n", post_div, diff);
>> +
>>  if (diff < diff_best || (diff == diff_best &&
>>  !(pll->flags & RADEON_PLL_PREFER_MINM_OVER_MAXP))) {
>>
>> @@ -1028,6 +1034,7 @@ void radeon_compute_pll_avivo(struct radeon_pll *pll,
>>  }
>>  }
>>  post_div = post_div_best;
>> +   printk("Selected post_div = %d\n", post_div);
>>
>>  /* get the feedback and reference divider for the optimal value */
>>  avivo_get_fb_ref_div(nom, den, post_div, fb_div_max, ref_div_max,
>> @@ -1062,7 +1069,7 @@ void radeon_compute_pll_avivo(struct radeon_pll *pll,
>>  *ref_div_p = ref_div;
>>  *post_div_p = post_div;
>>
>> -   DRM_DEBUG_KMS("%d - %d, pll dividers - fb: %d.%d ref: %d, post

[PATCH 1/3] drm/radeon: Disable uncacheable CPU mappings of GTT with RV6xx

2015-11-05 Thread Christian König 
On 05.11.2015 09:25, Michel Dänzer wrote:
> From: Michel Dänzer 
>
> They reportedly cause random GPU hangs.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91268
>
> Cc: stable at vger.kernel.org
> Signed-off-by: Michel Dänzer 

For this series Reviewed-by: Christian König 

> ---
>   drivers/gpu/drm/radeon/radeon_object.c | 6 ++
>   1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_object.c 
> b/drivers/gpu/drm/radeon/radeon_object.c
> index d302488..a35f5af 100644
> --- a/drivers/gpu/drm/radeon/radeon_object.c
> +++ b/drivers/gpu/drm/radeon/radeon_object.c
> @@ -221,6 +221,12 @@ int radeon_bo_create(struct radeon_device *rdev,
>   if (!(rdev->flags & RADEON_IS_PCIE))
>   bo->flags &= ~(RADEON_GEM_GTT_WC | RADEON_GEM_GTT_UC);
>   
> + /* Write-combined CPU mappings of GTT cause GPU hangs with RV6xx
> +  * See https://bugs.freedesktop.org/show_bug.cgi?id=91268
> +  */
> + if (rdev->family >= CHIP_RV610 && rdev->family <= CHIP_RV635)
> + bo->flags &= ~(RADEON_GEM_GTT_WC | RADEON_GEM_GTT_UC);
> +
>   #ifdef CONFIG_X86_32
>   /* XXX: Write-combined CPU mappings of GTT seem broken on 32-bit
>* See https://bugs.freedesktop.org/show_bug.cgi?id=84627

[PATCH v2 2/2] drm/panel: Add Sharp LS043T1LE01 MIPI DSI panel

2015-11-05 Thread Archit Taneja 


On 10/31/2015 04:04 AM, Bjorn Andersson wrote:
> From: Werner Johansson 
>
> This adds support for the Sharp panel found on the Qualcomm
> Snapdragon 800 Dragonboard (APQ8074)
>
> Signed-off-by: Werner Johansson 
> Signed-off-by: Bjorn Andersson 

Reviewed-by: Archit Taneja 

> ---
>
> Change since v1:
> - Dropped -vid suffix from compatible
>
>   drivers/gpu/drm/panel/Kconfig   |   9 +
>   drivers/gpu/drm/panel/Makefile  |   1 +
>   drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c | 387 
> 
>   3 files changed, 397 insertions(+)
>   create mode 100644 drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c
>
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index 7d4704b1292b..da3b9c7889c4 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -51,4 +51,13 @@ config DRM_PANEL_SHARP_LQ101R1SX01
> To compile this driver as a module, choose M here: the module
> will be called panel-sharp-lq101r1sx01.
>
> +config DRM_PANEL_SHARP_LS043T1LE01
> + tristate "Sharp LS043T1LE01 qHD video mode panel"
> + depends on OF
> + depends on DRM_MIPI_DSI
> + depends on BACKLIGHT_CLASS_DEVICE
> + help
> +   Say Y here if you want to enable support for Sharp LS043T1LE01 qHD
> +   (540x960) DSI panel as found on the Qualcomm APQ8074 Dragonboard
> +
>   endmenu
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index d0f016dd7ddb..53de90aa49cd 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -3,3 +3,4 @@ obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
>   obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += panel-samsung-ld9040.o
>   obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0) += panel-samsung-s6e8aa0.o
>   obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
> +obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
> diff --git a/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c 
> b/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c
> new file mode 100644
> index ..3aeb0bda4947
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c
> @@ -0,0 +1,387 @@
> +/*
> + * Copyright (C) 2015 Red Hat
> + * Copyright (C) 2015 Sony Mobile Communications Inc.
> + * Author: Werner Johansson 
> + *
> + * Based on AUO panel driver by Rob Clark 
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published 
> by
> + * the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but 
> WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program.  If not, see .
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +struct sharp_nt_panel {
> + struct drm_panel base;
> + struct mipi_dsi_device *dsi;
> +
> + struct backlight_device *backlight;
> + struct regulator *supply;
> + struct gpio_desc *reset_gpio;
> +
> + bool prepared;
> + bool enabled;
> +
> + const struct drm_display_mode *mode;
> +};
> +
> +static inline struct sharp_nt_panel *to_sharp_nt_panel(struct drm_panel 
> *panel)
> +{
> + return container_of(panel, struct sharp_nt_panel, base);
> +}
> +
> +static int sharp_nt_panel_init(struct sharp_nt_panel *sharp_nt)
> +{
> + struct mipi_dsi_device *dsi = sharp_nt->dsi;
> + int ret;
> +
> + dsi->mode_flags |= MIPI_DSI_MODE_LPM;
> +
> + ret = mipi_dsi_dcs_exit_sleep_mode(dsi);
> + if (ret < 0)
> + return ret;
> +
> + msleep(120);
> +
> + /* Novatek two-lane operation */
> + ret = mipi_dsi_dcs_write(dsi, 0xae, (u8[]){ 0x03 }, 1);
> + if (ret < 0)
> + return ret;
> +
> + /* Set both MCU and RGB I/F to 24bpp */
> + ret = mipi_dsi_dcs_set_pixel_format(dsi, MIPI_DCS_PIXEL_FMT_24BIT |
> + (MIPI_DCS_PIXEL_FMT_24BIT << 4));
> + if (ret < 0)
> + return ret;
> +
> + return 0;
> +}
> +
> +static int sharp_nt_panel_on(struct sharp_nt_panel *sharp_nt)
> +{
> + struct mipi_dsi_device *dsi = sharp_nt->dsi;
> + int ret;
> +
> + dsi->mode_flags |= MIPI_DSI_MODE_LPM;
> +
> + ret = mipi_dsi_dcs_set_display_on(dsi);
> + if (ret < 0)
> + return ret;
> +
> + return 0;
> +}
> +
> +static int sharp_nt_panel_off(struct sharp_nt_panel *sharp_nt)
> +{
> + struct mipi_dsi_device *dsi = sharp_nt->dsi;
> + int ret;
> +
> + dsi->mode_flags &= ~MIPI_DSI_MODE_LPM;
> +
> + ret =

[git pull] drm/sti: drm-next 2015-11-03

2015-11-05 Thread Dave Airlie 
On 4 November 2015 at 00:23, Vincent ABRIOU  wrote:
> Hello Dave,
>
> This serie of patches is a bunch of pending patches related with sti/drm
> driver.
>


This breaks my build as the patches it relies on aren't upstream yet.

It relies on platform_register_drivers which I'm sure will be merged in -rc1,
but isn't in drm-next.

You should mention that sort of dependency in the pull request.

I've left is out of my tree for now, I might send to Linus once the main
merge is done.

Dave.

[PATCH] drm: modes: replace simple_strtoul by kstrtouint

2015-11-05 Thread LABBE Corentin 
The simple_strtoul function is marked as obsolete.
This patch replace it by kstrtouint.

Signed-off-by: LABBE Corentin 
---
 drivers/gpu/drm/drm_modes.c | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index cd74a09..bde9b29 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1230,7 +1230,7 @@ bool drm_mode_parse_command_line_for_connector(const char 
*mode_option,
unsigned int xres = 0, yres = 0, bpp = 32, refresh = 0;
bool yres_specified = false, cvt = false, rb = false;
bool interlace = false, margins = false, was_digit = false;
-   int i;
+   int i, err;
enum drm_connector_force force = DRM_FORCE_UNSPECIFIED;

 #ifdef CONFIG_FB
@@ -1250,7 +1250,9 @@ bool drm_mode_parse_command_line_for_connector(const char 
*mode_option,
case '@':
if (!refresh_specified && !bpp_specified &&
!yres_specified && !cvt && !rb && was_digit) {
-   refresh = simple_strtol([i+1], NULL, 10);
+   err = kstrtouint([i + 1], 10, );
+   if (err)
+   return false;
refresh_specified = true;
was_digit = false;
} else
@@ -1259,7 +1261,9 @@ bool drm_mode_parse_command_line_for_connector(const char 
*mode_option,
case '-':
if (!bpp_specified && !yres_specified && !cvt &&
!rb && was_digit) {
-   bpp = simple_strtol([i+1], NULL, 10);
+   err = kstrtouint([i + 1], 10, );
+   if (err)
+   return false;
bpp_specified = true;
was_digit = false;
} else
@@ -1267,7 +1271,9 @@ bool drm_mode_parse_command_line_for_connector(const char 
*mode_option,
break;
case 'x':
if (!yres_specified && was_digit) {
-   yres = simple_strtol([i+1], NULL, 10);
+   err = kstrtouint([i + 1], 10, );
+   if (err)
+   return false;
yres_specified = true;
was_digit = false;
} else
@@ -1491,4 +1497,4 @@ int drm_mode_convert_umode(struct drm_display_mode *out,

 out:
return ret;
-}
\ No newline at end of file
+}
-- 
2.4.10

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

2015-11-05 Thread Philipp Zabel 
Hi Jitao,

some things I missed before.

Am Montag, den 02.11.2015, 10:09 +0800 schrieb Jitao Shi:
[...]
> +static int ps8640_regr(struct i2c_client *client, u16 i2c_addr,
> +u8 reg, u8 *value)
> +{
> + int ret;
> +
> + client->addr = i2c_addr;

I think i2c_new_dummy should be used to create additional clients for
the secondary addresses, instead of changing the address of the client
with every transfer.

> + ret = i2c_master_send(client, , 1);
> + if (ret <= 0) {
> + DRM_ERROR("Failed to send i2c command, ret=%d\n", ret);
> + return ret;
> + }
> +
> + ret = i2c_master_recv(client, value, 1);
> + if (ret <= 0) {
> + DRM_ERROR("Failed to recv i2c data, ret=%d\n", ret);
> + return ret;
> + }
> +
> + return 0;
> +}
[...]
> +static int ps8640_probe(struct i2c_client *client,
> + const struct i2c_device_id *id)
> +{
> + struct device *dev = >dev;
> + struct ps8640 *ps_bridge;
> + struct device_node *np = dev->of_node;
> + struct device_node *in_ep, *out_ep;
> + struct device_node *panel_node = NULL;
> + int ret;
> + u32 temp_reg;
> +
> + ps_bridge = devm_kzalloc(dev, sizeof(*ps_bridge), GFP_KERNEL);
> + if (!ps_bridge)
> + return -ENOMEM;
> +
> + in_ep = of_graph_get_next_endpoint(np, NULL);
> + if (in_ep) {
> + out_ep = of_graph_get_next_endpoint(np, in_ep);
> + of_node_put(in_ep);
> + if (out_ep) {
> + panel_node = of_graph_get_remote_port_parent(out_ep);
> + of_node_put(out_ep);
> + }
> + }
> + if (panel_node) {
> + ps_bridge->panel = of_drm_find_panel(panel_node);
> + of_node_put(panel_node);
> + if (!ps_bridge->panel)
> + return -EPROBE_DEFER;
> + }
> +
> + ps_bridge->client = client;
> +
> + ps_bridge->pwr_3v3_supply = devm_regulator_get(dev, "vdd33-supply");

Should be "vdd3", regulator_get will add the "-supply" suffix.

> + if (IS_ERR(ps_bridge->pwr_3v3_supply)) {
> + dev_err(dev, "cannot get ps_bridge->pwr_3v3_supply\n");
> + return PTR_ERR(ps_bridge->pwr_3v3_supply);
> + }
> +
> + ps_bridge->pwr_1v2_supply = devm_regulator_get(dev, "vdd12-supply");

Same here, "vdd12".

> + if (IS_ERR(ps_bridge->pwr_1v2_supply)) {
> + dev_err(dev, "cannot get ps_bridge->pwr_1v2_supply\n");
> + return PTR_ERR(ps_bridge->pwr_1v2_supply);
> + }
> +
> + ps_bridge->gpio_mode_sel_n = devm_gpiod_get(>dev, "mode-sel",
> + GPIOD_OUT_HIGH);
> + if (IS_ERR(ps_bridge->gpio_mode_sel_n)) {
> + ret = PTR_ERR(ps_bridge->gpio_mode_sel_n);
> + DRM_ERROR("cannot get gpio_mode_sel_n %d\n", ret);
> + return ret;
> + }
> +
> + ret = gpiod_direction_output(ps_bridge->gpio_mode_sel_n, 1);
> + if (ret) {
> + DRM_ERROR("cannot configure gpio_mode_sel_n\n");
> + return ret;
> + }
> +
> + ps_bridge->gpio_slp_n = devm_gpiod_get(>dev, "sleep-gpios",
> +GPIOD_OUT_HIGH);

Should be "sleep", gpiod_get will add the "-gpios" suffix.

> + if (IS_ERR(ps_bridge->gpio_slp_n)) {
> + ret = PTR_ERR(ps_bridge->gpio_slp_n);
> + DRM_ERROR("cannot get gpio_slp_n %d\n", ret);
> + return ret;
> + }
> +
> + ret = gpiod_direction_output(ps_bridge->gpio_slp_n, 1);
> + if (ret) {
> + DRM_ERROR("cannot configure gpio_slp_n\n");
> + return ret;
> + }

This can be removed, the "devm_gpiod_get(..., GPIOD_OUT_HIGH);" already
does the same.

> +
> + ps_bridge->gpio_rst_n = devm_gpiod_get(>dev, "reset",
> +GPIOD_OUT_HIGH);
> + if (IS_ERR(ps_bridge->gpio_rst_n)) {
> + ret = PTR_ERR(ps_bridge->gpio_rst_n);
> + DRM_ERROR("cannot get gpio_rst_n %d\n", ret);
> + return ret;
> + }
> +
> + ret = gpiod_direction_output(ps_bridge->gpio_rst_n, 1);
> + if (ret) {
> + DRM_ERROR("cannot configure gpio_rst_n\n");
> + return ret;
> + }

Same here, the gpiod_direction_output can be removed.

best regards
Philipp

[Bug 84662] Long pauses with Unreal demo Elemental on R9270X since : Always flush the HDP cache before submitting a CS to the GPU

2015-11-05 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=84662

Andy Furniss  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #58 from Andy Furniss  ---
(In reply to Michel Dänzer from comment #57)
> I'm currently getting a "run time to unreal logo" of just over three minutes
> on my Kaveri. How about you, Andy? You said 3:45 is "good", so if it's below
> that now, this report can be resolved, right? :)
> 
> AFAICT the remaining pauses are mostly due to delayed shader compiles, which
> Marek has been working on reducing.

Yes, this should be resolved -

I can't test 270X as it died and I now have a Tonga (so can't compare
times/glitching  due to low clocks.

IIRC the "big" glitches were fixed with only smaller ones remaining.

Since I got the Tonga I tried with fglrx and there are some glitches with that,
so maybe the demo its self is "special".

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

[PATCH] drm/ttm: Set CPU caching mode to cached for BOs being swapped out

2015-11-05 Thread Thomas Hellstrom 
Hi, Michel,

On 11/05/2015 09:08 AM, Michel Dänzer wrote:
> From: Michel Dänzer 
>
> I ran into the BUG_ON in ttm_tt_swapout, presumably the BO being swapped
> out was using a write-combined CPU mapping.
>
> Instead of BUGging out, just set the caching mode to what's needed.
>
> Signed-off-by: Michel Dänzer 
> ---
>  drivers/gpu/drm/ttm/ttm_tt.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
> index 4e19d0f..c2794eb 100644
> --- a/drivers/gpu/drm/ttm/ttm_tt.c
> +++ b/drivers/gpu/drm/ttm/ttm_tt.c
> @@ -334,7 +334,8 @@ int ttm_tt_swapout(struct ttm_tt *ttm, struct file 
> *persistent_swap_storage)
>   int ret = -ENOMEM;
>  
>   BUG_ON(ttm->state != tt_unbound && ttm->state != tt_unpopulated);
> - BUG_ON(ttm->caching_state != tt_cached);
> +
> + ttm_tt_set_caching(ttm, tt_cached);
>  
>   if (!persistent_swap_storage) {
>   swap_storage = shmem_file_setup("ttm swap",

This *is* actually a bug somewhere, since before ttm_tt_swapout,
ttm_bo_swapout should have moved out the bo to system and set
the correct caching. A WARN_ON_ONCE instead of BUG_ON is ok, but this
should never happen.

/Thomas

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

2015-11-05 Thread jitao shi 
Hi Philipp

I'll fixed those comments on V3.

Thank you very much.

Best Regards.

On Mon, 2015-11-02 at 12:34 +0100, Philipp Zabel wrote:
> Hi Jitao,
> 
> a few comments below.
> 
> Am Montag, den 02.11.2015, 11:54 +0800 schrieb jitao shi:
> [...]
> > > +static int ps8640_check_valid_id(struct ps8640 *ps_bridge)
> 
> This could be bool and return true/false.
> 
> > > +{
> > > + struct i2c_client *client = ps_bridge->client;
> > > + u8 rev_id_low, rev_id_high, chip_id_low, chip_id_high;
> > > + int retry_cnt = 0;
> > > +
> > > + do {
> > > + ps8640_regr(client, ps_bridge->base_reg + 4, PAGE4_CHIP_H,
> > > + _id_high);
> > > + if (chip_id_high != 0x30)
> > > + DRM_INFO("chip_id_high = 0x%x\n", chip_id_high);
> > > + } while ((retry_cnt++ < 2) && (chip_id_high != 0x30));
> > > +
> > > + ps8640_regr(client, ps_bridge->base_reg + 4, PAGE4_REV_L, _id_low);
> > > + ps8640_regr(client, ps_bridge->base_reg + 4, PAGE4_REV_H, _id_high);
> > > + ps8640_regr(client, ps_bridge->base_reg + 4, PAGE4_CHIP_L,
> > > + _id_low);
> > > +
> > > + if ((rev_id_low == 0x00) && (rev_id_high == 0x0a) &&
> > > + (chip_id_low == 0x00) && (chip_id_high == 0x30))
> > > + return 1;
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static void ps8640_show_mcu_fw_version(struct ps8640 *ps_bridge)
> > > +{
> > > + struct i2c_client *client = ps_bridge->client;
> > > + u8 major_ver, minor_ver;
> > > +
> > > + ps8640_regr(client, ps_bridge->base_reg + 5, 0x4, _ver);
> > > + ps8640_regr(client, ps_bridge->base_reg + 5, 0x5, _ver);
> > > +
> > > + DRM_INFO_ONCE("ps8640 rom fw version %d.%d\n", major_ver, minor_ver);
> > > +}
> > > +
> > > +static int ps8640_bdg_enable(struct ps8640 *ps_bridge)
> > > +{
> > > + struct i2c_client *client = ps_bridge->client;
> > > +
> > > + if (ps8640_check_valid_id(ps_bridge)) {
> > > + ps8640_regw(client, ps_bridge->base_reg + 3, 0xfe, 0x13);
> > > + ps8640_regw(client, ps_bridge->base_reg + 3, 0xff, 0x18);
> > > + ps8640_regw(client, ps_bridge->base_reg + 3, 0xfe, 0x13);
> > > + ps8640_regw(client, ps_bridge->base_reg + 3, 0xff, 0x1c);
> 
> Can you introduce #defines with descriptive names for those magic
> constants and register offsets, and maybe also i2c address offsets?
> 
> > > +
> > > + return 0;
> > > + }
> > > +
> > > + return -1;
> 
> Never return -1 to signal a problem.
> If there was an error, use a proper error code.
> 
> > > +}
> > > +
> > > +static void ps8640_prepare(struct ps8640 *ps_bridge)
> > > +{
> > > + struct i2c_client *client = ps_bridge->client;
> > > + int err, retry_cnt = 0;
> > > + u8 set_vdo_done;
> > > +
> > > + if (ps_bridge->enabled)
> > > + return;
> > > +
> > > + if (drm_panel_prepare(ps_bridge->panel)) {
> > > + DRM_ERROR("failed to prepare panel\n");
> > > + return;
> > > + }
> > > +
> > > + err = regulator_enable(ps_bridge->pwr_1v2_supply);
> > > + if (err < 0) {
> > > + DRM_ERROR("failed to enable pwr_1v2_supply: %d\n", err);
> 
> Missing panel unprepare.
> 
> > > + return;
> > > + }
> > > +
> > > + err = regulator_enable(ps_bridge->pwr_3v3_supply);
> > > + if (err < 0) {
> > > + DRM_ERROR("failed to enable pwr_3v3_supply: %d\n", err);
> 
> Missing panel unprepare and vdd12 regulator disable.
> 
> > > + return;
> > > + }
> > > +
> > > + gpiod_set_value(ps_bridge->gpio_slp_n, 1);
> > > + gpiod_set_value(ps_bridge->gpio_rst_n, 0);
> > > + usleep_range(500, 700);
> > > + gpiod_set_value(ps_bridge->gpio_rst_n, 1);
> > > +
> > > + do {
> > > + msleep(50);
> > > + ps8640_regr(client, ps_bridge->base_reg + 2, PAGE2_GPIO_H,
> > > + _vdo_done);
> > > + } while ((retry_cnt++ < 70) && ((set_vdo_done & PS_GPIO9) != PS_GPIO9));
> > > +
> > > + ps8640_show_mcu_fw_version(ps_bridge);
> > > + ps_bridge->enabled = true;
> > > +}
> > > +
> > > +static void ps8640_pre_enable(struct drm_bridge *bridge)
> > > +{
> > > + struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
> > > +
> > > + ps8640_prepare(ps_bridge);
> > > +}
> > > +
> > > +static void ps8640_enable(struct drm_bridge *bridge)
> > > +{
> > > + struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
> > > +
> > > + ps8640_bdg_enable(ps_bridge);
> > > +
> > > + if (drm_panel_enable(ps_bridge->panel)) {
> > > + DRM_ERROR("failed to enable panel\n");
> > > + return;
> 
> The return is superfluous.
> 
> > > + }
> > > +}
> > > +
> > > +static void ps8640_disable(struct drm_bridge *bridge)
> > > +{
> > > + struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
> > > +
> > > + if (!ps_bridge->enabled)
> > > + return;
> > > +
> > > + ps_bridge->enabled = false;
> > > +
> > > + if (drm_panel_disable(ps_bridge->panel)) {
> > > + DRM_ERROR("failed to disable panel\n");
> > > + return;
> 
> Shouldn't we still disable the bridge, even if panel disable fails?
> 
> > > + }
> > > +
> > > +

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

2015-11-05 Thread jitao shi 
On Mon, 2015-11-02 at 12:09 +0100, Philipp Zabel wrote:
> Hi Jitao,
> 
> Am Montag, den 02.11.2015, 11:53 +0800 schrieb jitao shi:
> [...]
> > > +Example:
> > > + edp-bridge at 18 {
> > > + compatible = "parade,ps8640";
> > > + reg = <0x18>;
> > > + sleep-gpios = < 116 GPIO_ACTIVE_HIGH>;
> > > + reset-gpios = < 115 GPIO_ACTIVE_HIGH>;
> > > + mode-sel-gpios = < 92 GPIO_ACTIVE_HIGH>;
> > > + ps8640-1v2-supply = <_fixed_1v2>;
> 
> This should be vdd12-supply now.

Thanks a lot.  I'll fix it on V3.

> 
> > > + ps8640-3v3-supply = <_vgp2_reg>;
> 
> Should be vdd33-supply now.

I'll fix it on V3.

> 
> regards
> Philipp
>

[Bug 84662] Long pauses with Unreal demo Elemental on R9270X since : Always flush the HDP cache before submitting a CS to the GPU

2015-11-05 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=84662

--- Comment #57 from Michel Dänzer  ---
I'm currently getting a "run time to unreal logo" of just over three minutes on
my Kaveri. How about you, Andy? You said 3:45 is "good", so if it's below that
now, this report can be resolved, right? :)

AFAICT the remaining pauses are mostly due to delayed shader compiles, which
Marek has been working on reducing.

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

[Bug 92806] 1 second freezes during new effects UT4

2015-11-05 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=92806

--- Comment #6 from Michel Dänzer  ---
Meanwhile, make sure you're not using a debugging build of LLVM.

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

[Bug 92806] 1 second freezes during new effects UT4

2015-11-05 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=92806

--- Comment #5 from Michel Dänzer  ---
So it looks like the freezes are due to delayed shader compilations in the
radeonsi driver (and to a lesser extent in the Mesa state tracker). Marek 
Olšák
has been working on improving this (which is probably the main reason why it's
a little better now), but it'll probably take a while until delayed shader
compilations are completely eliminated.

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

[Bug 106901] Brightness / WIFI Key does not generate any events

2015-11-05 Thread bugzilla-dae...@bugzilla.kernel.org 
https://bugzilla.kernel.org/show_bug.cgi?id=106901

Aaron Lu  changed:

   What|Removed |Added

 Status|NEEDINFO|ASSIGNED
  Component|Power-Video |Video(DRI - non Intel)
   Assignee|aaron.lu at intel.com  |drivers_video-dri at 
kernel-bu
   ||gs.osdl.org
Product|ACPI|Drivers

--- Comment #15 from Aaron Lu  ---
I have no idea why the acpi_video inteface doesn't work, the _BCM control
method is there, but just doesn't work.
The _BCM control method did some setting on the GPU's PCI config space, that
may trigger GPU driver to do the actual handling, but then this is driver
specific, maybe nvidia/nouveau driver has this knowledge.

As for the notification, the firmware decides to send the notification only
when the _DCS control method returns 0x1f:

Method (_Q0E, 0, NotSerialized)  // _Qxx: EC Query
{
If ((MSOS () < OSW8))
{
SBRN ()
}

If ((MSOS () >= OSVT))
{
Local0 = LBTN /* \_SB_.LBTN */
If (^^^PEG0.GFX0.PRST ())
{
If ((^^^PEG0.GFX0.LCDD._DCS () != 0x1F))
{
If ((^^^PEG0.GFX0.EDPD._DCS () != 0x1F))
{
Return (One)
}
}

^^^PEG0.GFX0.DWBL ()
ASBN = One
}

The _DCS is:
Method (_DCS, 0, NotSerialized)  // _DCS: Display
Current Status
{
CHA1 = One
CHA2 = One
CHA3 = Zero
Notify (GFX0, 0xF0) // Hardware-Specific
While ((CHA2 == One))
{
Sleep (0x32)
If ((CHA3 != One))
{
CHA2 = Zero
}
}

ACTD = MD2A (ACTD)
AVLD = MD2A (AVLD)
Local0 = ACTD /* \_SB_.ACTD */
Local0 = AVLD /* \_SB_.AVLD */
If (Local0)
{
If ((Local0 & EDPM))
{
Return (0x1F)
}
}
Return (0x1D)
}

The AVLD is retrieved from a memory field, I doubt it depends on the GPU driver
to set this value.

We should let the GPU people to take a look.

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

[RFC v5 02/12] drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.

2015-11-05 Thread Daniel Kurtz 
Hi Philipp,

A bunch of review comments inline.

On Wed, Nov 4, 2015 at 7:44 PM, Philipp Zabel  wrote:
> From: CK Hu 
>
> This patch adds an initial DRM driver for the Mediatek MT8173 DISP
> subsystem. It currently supports two fixed output streams from the
> OVL0/OVL1 sources to the DSI0/DPI0 sinks, respectively.
>
> Signed-off-by: CK Hu 
> Signed-off-by: YT Shen 
> Signed-off-by: Philipp Zabel 
> ---
> Changes since v4:
>  - Add mtk_crtc_state to keep pending state
>  - Move drm pending vblank event into mtk_crtc_state
>  - Make mtk_drm_crtc private
>  - Use drm_dev_alloc and drm_dev_register directly instead of
>drm_platform_init
>  - Drop unnecessary locking in mtk_drm_gem_dump_map_offset
>  - Remove currently unused mtk_drm_gem_mmap_buf
>  - Stop referencing plane framebuffers manually
>  - Set RDMA FIFO output threshold depending on frame width/height/rate
> ---
>  drivers/gpu/drm/Kconfig |   2 +
>  drivers/gpu/drm/Makefile|   1 +
>  drivers/gpu/drm/mediatek/Kconfig|  16 +
>  drivers/gpu/drm/mediatek/Makefile   |  10 +
>  drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 590 
> 
>  drivers/gpu/drm/mediatek/mtk_drm_crtc.h |  56 +++
>  drivers/gpu/drm/mediatek/mtk_drm_ddp.c  | 218 ++
>  drivers/gpu/drm/mediatek/mtk_drm_ddp.h  |  39 ++
>  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 424 
>  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h |  86 
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c  | 572 +++
>  drivers/gpu/drm/mediatek/mtk_drm_drv.h  |  61 +++
>  drivers/gpu/drm/mediatek/mtk_drm_fb.c   | 151 +++
>  drivers/gpu/drm/mediatek/mtk_drm_fb.h   |  29 ++
>  drivers/gpu/drm/mediatek/mtk_drm_gem.c  | 189 +
>  drivers/gpu/drm/mediatek/mtk_drm_gem.h  |  56 +++
>  drivers/gpu/drm/mediatek/mtk_drm_plane.c| 167 
>  drivers/gpu/drm/mediatek/mtk_drm_plane.h|  41 ++
>  18 files changed, 2708 insertions(+)
>  create mode 100644 drivers/gpu/drm/mediatek/Kconfig
>  create mode 100644 drivers/gpu/drm/mediatek/Makefile
>  create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_crtc.c
>  create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_crtc.h
>  create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_ddp.c
>  create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_ddp.h
>  create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
>  create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
>  create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_drv.c
>  create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_drv.h
>  create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_fb.c
>  create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_fb.h
>  create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_gem.c
>  create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_gem.h
>  create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_plane.c
>  create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_plane.h
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 1a0a8df..9e9987b 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -264,3 +264,5 @@ source "drivers/gpu/drm/sti/Kconfig"
>  source "drivers/gpu/drm/amd/amdkfd/Kconfig"
>
>  source "drivers/gpu/drm/imx/Kconfig"
> +
> +source "drivers/gpu/drm/mediatek/Kconfig"
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 45e7719..af6b592 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -67,6 +67,7 @@ obj-$(CONFIG_DRM_MSM) += msm/
>  obj-$(CONFIG_DRM_TEGRA) += tegra/
>  obj-$(CONFIG_DRM_STI) += sti/
>  obj-$(CONFIG_DRM_IMX) += imx/
> +obj-$(CONFIG_DRM_MEDIATEK) += mediatek/
>  obj-y  += i2c/
>  obj-y  += panel/
>  obj-y  += bridge/
> diff --git a/drivers/gpu/drm/mediatek/Kconfig 
> b/drivers/gpu/drm/mediatek/Kconfig
> new file mode 100644
> index 000..5343cf1
> --- /dev/null
> +++ b/drivers/gpu/drm/mediatek/Kconfig
> @@ -0,0 +1,16 @@
> +config DRM_MEDIATEK
> +   tristate "DRM Support for Mediatek SoCs"
> +   depends on DRM
> +   depends on ARCH_MEDIATEK || (ARM && COMPILE_TEST)
> +   select MTK_SMI
> +   select DRM_PANEL
> +   select DRM_MIPI_DSI
> +   select DRM_PANEL_SIMPLE
> +   select DRM_KMS_HELPER
> +   select IOMMU_DMA
> +   help
> + Choose this option if you have a Mediatek SoCs.
> + The module will be called mediatek-drm
> + This driver provides kernel mode setting and
> + buffer management to userspace.
> +
> diff --git a/drivers/gpu/drm/mediatek/Makefile 
> b/drivers/gpu/drm/mediatek/Makefile
> new file mode 100644
> index 000..ba6d3fc
> --- /dev/null
> +++ b/drivers/gpu/drm/mediatek/Makefile
> @@ -0,0 +1,10 @@
> +mediatek-drm-y := mtk_drm_drv.o \
> + mtk_drm_crtc.o \
> + mtk_drm_ddp.o \
> + mtk_drm_ddp_comp.o \
> +

[Bug 92827] Tonga: No Sound over HDMI with connected AV receiver

2015-11-05 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=92827

Bug ID: 92827
   Summary: Tonga: No Sound over HDMI with connected AV receiver
   Product: DRI
   Version: XOrg git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: winlux at gmail.com

Created attachment 119417
  --> https://bugs.freedesktop.org/attachment.cgi?id=119417=edit
cat /proc/asound/card1/eld#0.0

I'm using the new amdgpu driver on Linux 4.2 and 4.3 RC7 with my new Radeon R9
380.
I want to use my 5.1 receiver to get audio over HDMI, it works just fine under
Windows 8.1. Under Manjaro Linux, I have configured a standard FullHD output on
HDMI with 60 Hz – with my former Radeon HD 7770 using radeonsi this was the
rule to get audio (don't get me started on broken HDMI audio on radeonsi. With
Linux 4.0+ until now, I needed to use the 3.18 kernel to *not* see only
"unplugged" outputs in PulseAudio. See bug 90777.).
In fortunate distinction to radeonsi on Linux 4.0+, PulseAudio shows 2.0, 5.1
and 7.1 output over HDMI as plugged in and available. But I don't get any
output.
No HDMI audio output on Tonga using amdgpu on Linux 4.2 and 4.3 RC7.

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

[Bug 90777] radeon/audio: Removed CRC control programing broke HDMI audio in Linux 4.0

2015-11-05 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=90777

Maximilian Böhm  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #11 from Maximilian Böhm  ---
Definitely still broken on Linux 4.2 and 4.3 RC7. Works here with 3.18.

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