Re: [PATCH] drm: Reduce EDID warnings from DRM_ERROR to DRM_NOTE

[Thierry Reding]

On Fri, Feb 10, 2017 at 07:59:13PM +, Chris Wilson wrote:
> The warnings from parsing the EDID are not driver errors, but the
> "normal but significant" conditions from the external device. As such,
> they do not need the ferocity of an *ERROR*, but can use the less harsh
> DRM_NOTE instead.
> 
> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/drm_edid.c | 15 ---
>  1 file changed, 8 insertions(+), 7 deletions(-)

The below are all conditions that happen when the EDID is bad. I'm not
sure that really qualifies as "normal".

From a quick look through the code we don't always trigger an error from
the below failure paths at higher levels, so decreasing the level here
has the potential to let this kind of exceptional condition go
unnoticed.

Thierry


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [radeon-alex:drm-next-4.12-wip 34/40] drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c:620:4: warning: left shift count >= width of type

[Thierry Reding]

On Sat, Feb 11, 2017 at 08:55:50AM +0100, Christian König wrote:
> Mhm, guys any idea why the build bot is spamming us with that warning?
> 
> The type is 64bit and the shift is 63, so that should work fine.

1UL will be an unsigned long, which is 64 bit on 64 bit architectures
only. Xtensa is a 32 bit platform, hence 1UL will effectively be 32 bits
and 1UL << 63 would effectively be 0.

I think the safe thing to do here would be to change 1UL to 1ULL to make
sure there are enough bits. unsigned long long is guaranteed to be at
least 64 bits.

Alternatively if you no longer want to support 32 bit architectures you
could depend on the Kconfig symbol 64BIT, but I suspect you don't want
to do that.

Thierry

> Am 10.02.2017 um 20:48 schrieb kbuild test robot:
> > tree:   git://people.freedesktop.org/~agd5f/linux.git drm-next-4.12-wip
> > head:   d32ff0ea8e22964abcc6406e00a0646f2bfb94c7
> > commit: 382a21d981661dbc8198c37dc95707e1e381ce76 [34/40] drm/amdgpu: IOCTL 
> > interface for PRT support v4
> > config: xtensa-allmodconfig (attached as .config)
> > compiler: xtensa-linux-gcc (GCC) 4.9.0
> > reproduce:
> >  wget 
> > https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
> >  -O ~/bin/make.cross
> >  chmod +x ~/bin/make.cross
> >  git checkout 382a21d981661dbc8198c37dc95707e1e381ce76
> >  # save the attached .config to linux build tree
> >  make.cross ARCH=xtensa
> > 
> > All warnings (new ones prefixed by >>):
> > 
> > drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c: In function 
> > 'amdgpu_gem_va_ioctl':
> > > > drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c:620:4: warning: left shift 
> > > > count >= width of type
> > va_flags |= AMDGPU_PTE_PRT;
> > ^
> > 
> > vim +620 drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> > 
> > 604 r = -ENOENT;
> > 605 goto error_backoff;
> > 606 }
> > 607 } else {
> > 608 bo_va = fpriv->prt_va;
> > 609 }
> > 610 
> > 611 switch (args->operation) {
> > 612 case AMDGPU_VA_OP_MAP:
> > 613 if (args->flags & AMDGPU_VM_PAGE_READABLE)
> > 614 va_flags |= AMDGPU_PTE_READABLE;
> > 615 if (args->flags & AMDGPU_VM_PAGE_WRITEABLE)
> > 616 va_flags |= AMDGPU_PTE_WRITEABLE;
> > 617 if (args->flags & AMDGPU_VM_PAGE_EXECUTABLE)
> > 618 va_flags |= AMDGPU_PTE_EXECUTABLE;
> > 619 if (args->flags & AMDGPU_VM_PAGE_PRT)
> >   > 620 va_flags |= AMDGPU_PTE_PRT;
> > 621 r = amdgpu_vm_bo_map(adev, bo_va, 
> > args->va_address,
> > 622  args->offset_in_bo, 
> > args->map_size,
> > 623  va_flags);
> > 624 break;
> > 625 case AMDGPU_VA_OP_UNMAP:
> > 626 r = amdgpu_vm_bo_unmap(adev, bo_va, 
> > args->va_address);
> > 627 break;
> > 628 default:
> > 
> > ---
> > 0-DAY kernel test infrastructureOpen Source Technology 
> > Center
> > https://lists.01.org/pipermail/kbuild-all   Intel 
> > Corporation
> > 
> > 
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> 

> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/exynos: dsi: Remove bridge node reference in removal

[Hoegeun Kwon]

Since bridge node is referenced during in the probe, it should be
released on removal.

Suggested-by: Andrzej Hajda 
Signed-off-by: Hoegeun Kwon 
---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 214d486..2d4e118 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1821,6 +1821,10 @@ static int exynos_dsi_probe(struct platform_device *pdev)
 
 static int exynos_dsi_remove(struct platform_device *pdev)
 {
+   struct exynos_dsi *dsi = platform_get_drvdata(pdev);
+
+   of_node_put(dsi->bridge_node);
+
pm_runtime_disable(&pdev->dev);
 
component_del(&pdev->dev, &exynos_dsi_component_ops);
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99784] AMD 7470m When VGA plugged into laptop, only one monitor working at a time

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

  Component|Driver/Radeon   |DRM/Radeon
Product|xorg|DRI
 QA Contact|xorg-t...@lists.x.org   |
   Assignee|xorg-driver-...@lists.x.org |dri-devel@lists.freedesktop
   ||.org
Version|7.7 (2012.06)   |unspecified

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [bug report] drm/msm/dsi: Move PHY operations out of host

[Archit Taneja]

On 02/11/2017 10:47 AM, Dan Carpenter wrote:

Hello Hai Li,

This is a semi-automatic email about new static checker warnings.

The patch b62aa70a98c5: "drm/msm/dsi: Move PHY operations out of
host" from Jan 7, 2017, leads to the following Smatch complaint:

./drivers/gpu/drm/msm/dsi/dsi_manager.c:174 dsi_mgr_phy_enable()
 error: we previously assumed 'mdsi' could be null (see line 157)

./drivers/gpu/drm/msm/dsi/dsi_manager.c
   156   */
   157  if (IS_DUAL_DSI() && mdsi && sdsi) {
 
Check for NULL.

   158  if (!mdsi->phy_enabled && !sdsi->phy_enabled) {
   159  msm_dsi_host_reset_phy(mdsi->host);
   160  msm_dsi_host_reset_phy(sdsi->host);
   161  
   162  ret = enable_phy(mdsi, src_pll_id,
   163   
&shared_timings[DSI_CLOCK_MASTER]);
   164  if (ret)
   165  return ret;
   166  ret = enable_phy(sdsi, src_pll_id,
   167   
&shared_timings[DSI_CLOCK_SLAVE]);
   168  if (ret) {
   169  msm_dsi_phy_disable(mdsi->phy);
   170  return ret;
   171  }
   172  }
   173  } else {
   174  msm_dsi_host_reset_phy(mdsi->host);
   ^^
Unchecked dereference.


This looks like a typo, it should have been msm_dsi->host. Will post a patch
to fix this.

Thanks,
Archit



   175  ret = enable_phy(msm_dsi, src_pll_id, 
&shared_timings[id]);
   176  if (ret)

regards,
dan carpenter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel



--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99747] Problems with mesa 13.0.x and ubuntu 17.04

[bugzilla-daemon]

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

--- Comment #5 from Michel Dänzer  ---
Are there any remaining problems? If yes, what are they?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 194559] amdgpu problems loading 2 firmwares on multi-smp system

[bugzilla-daemon]

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

fin4...@hotmail.com changed:

   What|Removed |Added

 CC||fin4...@hotmail.com

--- Comment #1 from fin4...@hotmail.com ---

Stock kernels have very little amdgpu code, see kernel.org and click diff.
Use the command: 
git clone -b drm-next-4.11-wip git://people.freedesktop.org/~agd5f/linux

The kernel configuration file of Debian Official kernel are available in /boot,
named after the kernel release. Copy the .config file to the linux directory.
Connect all your devices and run the command: make localmodconfig. You can use
the command make defconfig too for creating initial .config file. 

Use the command: make xconfig and check that you have enabled: Reroute Broken
IRQ, Virtualization KVM and 300Hz CPU timer, I also disabled Swap, Kernel
Debug, CPU Freq scaling , Cpu handling in Acpi, Used Bios to control CPU and
devices. In the drivers->graphics->amdgpu enable cik support for a gcn 1.1 gpu
and si support for a gcn 1.0 gpu.

Create debian kernel package:
export CONCURRENCY_LEVEL=4
fakeroot make-kpkg --initrd kernel_image

Install the kernel package with Gdebi. To make a custom kernel to boot, add a
line to /etc/initramfs-tools/modules:
unix
And run: sudo update-initramfs
Reboot.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 97879] [amdgpu] Rocket League: long hangs (several seconds) when loading assets (models/textures/shaders?)

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

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

--- Comment #83 from Michel Dänzer  ---
Thanks for the report and everyone's cooperation in getting it resolved. Fixed
in Git master:

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

Author: Marek Olšák 
Date:   Thu Feb  9 03:14:22 2017 +0100

gallium/radeon: fix performance of buffer readbacks

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [radeon-alex:drm-next-4.12-wip 34/40] drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c:620:4: warning: left shift count >= width of type

[Zhang, Jerry]

Hi Christian,

Maybe we need a change.
{{{
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
index 4d26e9b..fb5448b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
@@ -65,7 +65,7 @@

#define AMDGPU_PTE_FRAG(x) ((x & 0x1f) << 7)

-#define AMDGPU_PTE_PRT (1UL << 63)
+#define AMDGPU_PTE_PRT (1ULL << 63)

/* How to programm VM fault handling */
#define AMDGPU_VM_FAULT_STOP_NEVER 0
}}}

Regards,
Jerry (Junwei Zhang)

Linux Base Graphics
SRDC Software Development
_

From: Christian König [mailto:deathsim...@vodafone.de]
Sent: Saturday, February 11, 2017 15:56
To: Zhang, Jerry
Cc: Deucher, Alexander; Haehnle, Nicolai; dri-devel@lists.freedesktop.org; 
Koenig, Christian
Subject: Re: [radeon-alex:drm-next-4.12-wip 34/40] 
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c:620:4: warning: left shift count >= 
width of type

Mhm, guys any idea why the build bot is spamming us with that warning?

The type is 64bit and the shift is 63, so that should work fine.

Regards,
Christian.

Am 10.02.2017 um 20:48 schrieb kbuild test robot:

tree:   git://people.freedesktop.org/~agd5f/linux.git drm-next-4.12-wip

head:   d32ff0ea8e22964abcc6406e00a0646f2bfb94c7

commit: 382a21d981661dbc8198c37dc95707e1e381ce76 [34/40] drm/amdgpu: IOCTL 
interface for PRT support v4

config: xtensa-allmodconfig (attached as .config)

compiler: xtensa-linux-gcc (GCC) 4.9.0

reproduce:

wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross

chmod +x ~/bin/make.cross

git checkout 382a21d981661dbc8198c37dc95707e1e381ce76

# save the attached .config to linux build tree

make.cross ARCH=xtensa



All warnings (new ones prefixed by >>):



   drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c: In function 'amdgpu_gem_va_ioctl':

drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c:620:4: warning: left shift count >= 
width of type

   va_flags |= AMDGPU_PTE_PRT;

   ^



vim +620 drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c



   604 r = -ENOENT;

   605 goto error_backoff;

   606  }

   607  } else {

   608  bo_va = fpriv->prt_va;

   609  }

   610

   611  switch (args->operation) {

   612  case AMDGPU_VA_OP_MAP:

   613  if (args->flags & AMDGPU_VM_PAGE_READABLE)

   614 va_flags |= AMDGPU_PTE_READABLE;

   615  if (args->flags & AMDGPU_VM_PAGE_WRITEABLE)

   616 va_flags |= AMDGPU_PTE_WRITEABLE;

   617  if (args->flags & AMDGPU_VM_PAGE_EXECUTABLE)

   618 va_flags |= AMDGPU_PTE_EXECUTABLE;

   619  if (args->flags & AMDGPU_VM_PAGE_PRT)

 > 620 va_flags |= AMDGPU_PTE_PRT;

   621  r = amdgpu_vm_bo_map(adev, bo_va, args->va_address,

   622  args->offset_in_bo, args->map_size,

   623  va_flags);

   624  break;

   625  case AMDGPU_VA_OP_UNMAP:

   626  r = amdgpu_vm_bo_unmap(adev, bo_va, args->va_address);

   627  break;

   628  default:



---

0-DAY kernel test infrastructureOpen Source Technology Center

https://lists.01.org/pipermail/kbuild-all   Intel Corporation




___

dri-devel mailing list

dri-devel@lists.freedesktop.org

https://lists.freedesktop.org/mailman/listinfo/dri-devel


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99275] Kernel 4.9: amdgpu regression; gui flickers; amd radeon rx 460

[bugzilla-daemon]

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

--- Comment #25 from Michel Dänzer  ---
(In reply to Reimar Imhof from comment #23)
> 
> Do these scheduler changes somehow break amdgpu?

That's unlikely. See comment #15.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: imxdrm issue on Hummingboard with LVDS enabled

[Fabio Estevam]

Hi Russell,

On Sun, Feb 12, 2017 at 11:18 AM, Russell King - ARM Linux
 wrote:
> Hi,
>
> Here's another issue with imxdrm.  I got this while trying to reproduce
> Dan's problem by enabling the lvds output using the patch below
> originally from Fabio, but updated a bit.  This doesn't occur if I leave
> LVDS disabled.
>
> The taint is due to the IMX capture modules from Steve, who chose to put
> his code in drivers/staging/media rather than drivers/media.  However,
> the last module to make the capture stuff active (imx-csi) which interfaces
> the drivers/gpu/ipu-v3 code with the capture code has not been loaded.
>
> [ cut here ]
> WARNING: CPU: 1 PID: 1049 at 
> /home/rmk/git/linux-rmk/drivers/gpu/drm/drm_atomic_helper.c:1149 
> drm_atomic_helper_wait_for_vblanks+0x218/0x224
> [CRTC:29] vblank wait timed out

I am getting the same warning when trying to add HDMI support on
imx6sx-udoo-neo board via TDA19988:

[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[drm] No driver support for vblank timestamp query.
tda998x 2-0070: Falling back to first CRTC
random: fast init done
tda998x 2-0070: found TDA19988
mxsfb 222.lcdif: bound 2-0070 (ops tda998x_ops)
[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[drm] No driver support for vblank timestamp query.
 [ cut here ]
WARNING: CPU: 0 PID: 1 at drivers/gpu/drm/drm_atomic_helper.c:1149
drm_atomic_helper_wait_for_vblanks+00
[CRTC:26] vblank wait timed out
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.10.0-rc7-00034-g2217172 #155
Hardware name: Freescale i.MX6 SoloX (Device Tree)
Backtrace:
[] (dump_backtrace) from [] (show_stack+0x18/0x1c)
r7: r6:6013 r5: r4:c0e29258
[] (show_stack) from [] (dump_stack+0xb4/0xe8)
[] (dump_stack) from [] (__warn+0xd8/0x104)
r9:c04d63ac r8:047d r7:0009 r6:c0c1f2b4 r5: r4:ef05f8c8
[] (__warn) from [] (warn_slowpath_fmt+0x3c/0x44)
r9:ef35 r8:ef037028 r7: r6:ef3bd600 r5:ef3d2c00 r4:c0c1f3d0
[] (warn_slowpath_fmt) from []
(drm_atomic_helper_wait_for_vblanks+0x230/0x240)
r3:001a r2:c0c1f3d0
r4:
[] (drm_atomic_helper_wait_for_vblanks) from []
(drm_atomic_helper_commit_tail+0x50)
r10:0001 r9:ef3cd100 r8:ef350484 r7:ef35 r6: r5:ef35
r4:ef3d2c00


I haven't had a chance to debug this yet. If anyone makes any
progress, please keep me on Cc.

Thanks
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/8] ARM: sun4i: Add display blocks for the sun4i dtsi.

[Priit Laes]

Added basic display pipeline consisting of tcon, display backend and
frontend blocks.

Signed-off-by: Priit Laes 
---
 arch/arm/boot/dts/sun4i-a10.dtsi | 104 +++
 1 file changed, 104 insertions(+)

diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi
index ba20b48..70991c9 100644
--- a/arch/arm/boot/dts/sun4i-a10.dtsi
+++ b/arch/arm/boot/dts/sun4i-a10.dtsi
@@ -779,6 +779,45 @@
#size-cells = <0>;
};
 
+   tcon0: lcd-controller@1c0c000 {
+   compatible = "allwinner,sun5i-a13-tcon";
+   reg = <0x01c0c000 0x1000>;
+   interrupts = <44>;
+   resets = <&tcon0_ch0_clk 1>;
+   reset-names = "lcd";
+   clocks = <&ahb_gates 36>,
+<&tcon0_ch0_clk>,
+<&tcon0_ch1_clk>;
+   clock-names = "ahb",
+ "tcon-ch0",
+ "tcon-ch1";
+   clock-output-names = "tcon-pixel-clock";
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   tcon0_in: port@0 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0>;
+
+   tcon0_in_be0: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = 
<&be0_out_tcon0>;
+   };
+   };
+
+   tcon0_out: port@1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <1>;
+   };
+   };
+   };
+
+
mmc0: mmc@01c0f000 {
compatible = "allwinner,sun4i-a10-mmc";
reg = <0x01c0f000 0x1000>;
@@ -1328,5 +1367,70 @@
clocks = <&apb1_gates 7>;
status = "disabled";
};
+
+   fe0: display-frontend@1e0 {
+   compatible = "allwinner,sun5i-a13-display-frontend";
+   reg = <0x01e0 0x2>;
+   interrupts = <47>;
+   clocks = <&ahb_gates 46>, <&de_fe0_clk>,
+<&dram_gates 25>;
+   clock-names = "ahb", "mod",
+ "ram";
+   resets = <&de_fe0_clk>;
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   fe0_out: port@1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <1>;
+
+   fe0_out_be0: endpoint {
+   remote-endpoint = <&be0_in_fe0>;
+   };
+   };
+   };
+   };
+
+   be0: display-backend@1e6 {
+   compatible = "allwinner,sun5i-a13-display-backend";
+   reg = <0x01e6 0x1>;
+   clocks = <&ahb_gates 44>, <&de_be0_clk>,
+<&dram_gates 26>;
+   clock-names = "ahb", "mod",
+ "ram";
+   resets = <&de_be0_clk>;
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   be0_in: port@0 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0>;
+
+   be0_in_fe0: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = 
<&fe0_out_be0>;
+   };
+   };
+
+   be0_out: port@1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <1>;
+
+   

[PATCH 5/8] drm/sun4i: Add encoder type argument to sun4i_tcon0_mode_set

[Priit Laes]

Depending on the output type, we have to enable/disable some
bits conditionally.

Signed-off-by: Priit Laes 
---
 drivers/gpu/drm/sun4i/sun4i_rgb.c  | 2 +-
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 3 ++-
 drivers/gpu/drm/sun4i/sun4i_tcon.h | 3 ++-
 3 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_rgb.c 
b/drivers/gpu/drm/sun4i/sun4i_rgb.c
index f5e86fe..3d4eb05 100644
--- a/drivers/gpu/drm/sun4i/sun4i_rgb.c
+++ b/drivers/gpu/drm/sun4i/sun4i_rgb.c
@@ -179,7 +179,7 @@ static void sun4i_rgb_encoder_mode_set(struct drm_encoder 
*encoder,
struct sun4i_drv *drv = rgb->drv;
struct sun4i_tcon *tcon = drv->tcon;
 
-   sun4i_tcon0_mode_set(tcon, mode);
+   sun4i_tcon0_mode_set(tcon, mode, DRM_MODE_ENCODER_DAC);
 
clk_set_rate(tcon->dclk, mode->crtc_clock * 1000);
 
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index ea2906f..71d0087 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -124,7 +124,8 @@ static int sun4i_tcon_get_clk_delay(struct drm_display_mode 
*mode,
 }
 
 void sun4i_tcon0_mode_set(struct sun4i_tcon *tcon,
- struct drm_display_mode *mode)
+ struct drm_display_mode *mode,
+ int type)
 {
unsigned int bp, hsync, vsync;
u8 clk_delay;
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h 
b/drivers/gpu/drm/sun4i/sun4i_tcon.h
index 166064b..b040e10 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
@@ -188,7 +188,8 @@ void sun4i_tcon_enable_vblank(struct sun4i_tcon *tcon, bool 
enable);
 void sun4i_tcon_switch_interlace(struct sun4i_tcon *tcon,
 bool enable);
 void sun4i_tcon0_mode_set(struct sun4i_tcon *tcon,
- struct drm_display_mode *mode);
+ struct drm_display_mode *mode,
+ int type);
 void sun4i_tcon1_mode_set(struct sun4i_tcon *tcon,
  struct drm_display_mode *mode);
 
-- 
2.9.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/8] drm/sun4i: Add optional 'mode' property to TCON

[Philippe Fouquet]

First way thank for this work
But I can't use it, I'm explain myself.

My LVDS connexion works fine because I display correctly the console under 
uboot (I work with CONFIG_VIDEO_LCD_MODE)

I use the wiki : http://linux-sunxi.org/LCD to convert my fex config to 
CONFIG_VIDEO_LCD_MODE for the uboot all work fine

But for the kernel nothing, I have some crazy line or black screen.

   - I add my lcd configuration into simple_panel.c (
   http://linux-sunxi.org/LCD)
   - I can seen the debug ligne came from LVDS driver.
   - My LCD screen is a dlc070ddg 7' 800x480 LVDS 18bits.
   - I work with a Olimex_A20-OLinuXino-Micro 
   .

I don't know where I can search If some body have a idea?

Thanks 

Le samedi 11 février 2017 18:44:59 UTC+1, Priit Laes a écrit :
>
> Add variable to enable either 'rgb' or 'lvds' output. 
>
> Signed-off-by: Priit Laes > 
> --- 
>  Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 3 +++ 
>  1 file changed, 3 insertions(+) 
>
> diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt 
> b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt 
> index b82c004..c367ede 100644 
> --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt 
> +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt 
> @@ -43,6 +43,9 @@ Required properties: 
>   - reset-names: the reset names mentioned above 
>   - clock-output-names: Name of the pixel clock created 
>   
> +- mode: Defines which encoder will be enabled. Values are 'rgb', 'lvds'. 
> +  Defaults to 'rgb' if not set. 
> + 
>  - ports: A ports node with endpoint definitions as defined in 
>Documentation/devicetree/bindings/media/video-interfaces.txt. The 
>first port should be the input endpoint, the second one the output 
> -- 
> 2.9.3 
>
>___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 7/8] drm/sun4i: Add various bits and pieces to enable LVDS support on sun4i

[Priit Laes]

TODO: We still rely on u-boot for lvds reset bit setup :(

Signed-off-by: Priit Laes 
---
 drivers/gpu/drm/sun4i/sun4i_lvds.c | 29 
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 54 --
 drivers/gpu/drm/sun4i/sun4i_tcon.h | 15 +++
 3 files changed, 90 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_lvds.c 
b/drivers/gpu/drm/sun4i/sun4i_lvds.c
index 2ba4705..de738e5 100644
--- a/drivers/gpu/drm/sun4i/sun4i_lvds.c
+++ b/drivers/gpu/drm/sun4i/sun4i_lvds.c
@@ -114,6 +114,35 @@ static void sun4i_lvds_encoder_enable(struct drm_encoder 
*encoder)
/* encoder->bridge can be NULL; drm_bridge_enable checks for it */
drm_bridge_enable(encoder->bridge);
 
+   /* Enable the LVDS */
+   regmap_update_bits(tcon->regs, SUN4I_TCON0_LVDS_IF_REG,
+  SUN4I_TCON0_LVDS_IF_ENABLE,
+  SUN4I_TCON0_LVDS_IF_ENABLE);
+
+   /*
+* TODO: SUN4I_TCON0_LVDS_ANA0_REG_C and SUN4I_TCON0_LVDS_ANA0_PD
+* registers span 3 bits, but we only set upper 2 for both
+* of them based on values taken from Allwinner driver.
+*/
+   regmap_write(tcon->regs, SUN4I_TCON0_LVDS_ANA0_REG,
+SUN4I_TCON0_LVDS_ANA0_CK_EN |
+SUN4I_TCON0_LVDS_ANA0_REG_V |
+SUN4I_TCON0_LVDS_ANA0_REG_C |
+SUN4I_TCON0_LVDS_ANA0_EN_MB |
+SUN4I_TCON0_LVDS_ANA0_PD |
+SUN4I_TCON0_LVDS_ANA0_DCHS);
+
+   udelay(2000);
+
+   regmap_write(tcon->regs, SUN4I_TCON0_LVDS_ANA1_REG,
+SUN4I_TCON0_LVDS_ANA1_INIT);
+
+   udelay(1000);
+
+   regmap_update_bits(tcon->regs, SUN4I_TCON0_LVDS_ANA1_REG,
+  SUN4I_TCON0_LVDS_ANA1_UPDATE,
+  SUN4I_TCON0_LVDS_ANA1_UPDATE);
+
sun4i_tcon_channel_enable(tcon, 0);
 }
 
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 71d0087..468a3ce 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -18,6 +18,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -29,6 +30,7 @@
 #include "sun4i_crtc.h"
 #include "sun4i_dotclock.h"
 #include "sun4i_drv.h"
+#include "sun4i_lvds.h"
 #include "sun4i_rgb.h"
 #include "sun4i_tcon.h"
 
@@ -169,12 +171,29 @@ void sun4i_tcon0_mode_set(struct sun4i_tcon *tcon,
 SUN4I_TCON0_BASIC2_V_BACKPORCH(bp));
 
/* Set Hsync and Vsync length */
-   hsync = mode->crtc_hsync_end - mode->crtc_hsync_start;
-   vsync = mode->crtc_vsync_end - mode->crtc_vsync_start;
-   DRM_DEBUG_DRIVER("Setting HSYNC %d, VSYNC %d\n", hsync, vsync);
-   regmap_write(tcon->regs, SUN4I_TCON0_BASIC3_REG,
-SUN4I_TCON0_BASIC3_V_SYNC(vsync) |
-SUN4I_TCON0_BASIC3_H_SYNC(hsync));
+   if (type != DRM_MODE_ENCODER_LVDS) {
+   // Not needed for LVDS?
+   hsync = mode->crtc_hsync_end - mode->crtc_hsync_start;
+   vsync = mode->crtc_vsync_end - mode->crtc_vsync_start;
+   DRM_DEBUG_DRIVER("Setting HSYNC %d, VSYNC %d\n", hsync, vsync);
+   regmap_write(tcon->regs, SUN4I_TCON0_BASIC3_REG,
+SUN4I_TCON0_BASIC3_V_SYNC(vsync) |
+SUN4I_TCON0_BASIC3_H_SYNC(hsync));
+   }
+
+   if (type == DRM_MODE_ENCODER_LVDS) {
+   /* Setup bit depth */
+   /* TODO: Figure out where to get display bit depth
+* val = (1: 18-bit, 0: 24-bit)
+* TODO: Should we set more registers:
+* BIT(28) - LVDS_DIRECTION
+* BIT(27) - LVDS_MODE
+* BIT(23) - LVDS_CORRECT_MODE
+*/
+   regmap_update_bits(tcon->regs, SUN4I_TCON0_LVDS_IF_REG,
+  SUN4I_TCON0_LVDS_IF_BITWIDTH,
+  SUN4I_TCON0_LVDS_IF_BITWIDTH);
+   }
 
/* Setup the polarity of the various signals */
if (!(mode->flags & DRM_MODE_FLAG_PHSYNC))
@@ -183,8 +202,15 @@ void sun4i_tcon0_mode_set(struct sun4i_tcon *tcon,
if (!(mode->flags & DRM_MODE_FLAG_PVSYNC))
val |= SUN4I_TCON0_IO_POL_VSYNC_POSITIVE;
 
+
+   /* Set proper DCLK phase value */
+   if (type == DRM_MODE_ENCODER_LVDS)
+   val |= SUN4I_TCON0_IO_POL_DCLK_PHASE(1);
+
regmap_update_bits(tcon->regs, SUN4I_TCON0_IO_POL_REG,
-  SUN4I_TCON0_IO_POL_HSYNC_POSITIVE | 
SUN4I_TCON0_IO_POL_VSYNC_POSITIVE,
+  SUN4I_TCON0_IO_POL_HSYNC_POSITIVE |
+  SUN4I_TCON0_IO_POL_VSYNC_POSITIVE |
+  SUN4I_TCON0_IO_POL_DCLK_PHASE_MASK,
   val);
 
/* Map output pins to channel 0 */
@@ -480,6 +506,7 @@ static int sun4i_tcon_bind(struct device *dev, stru

Re: [PATCH 2/5] drm: of: introduce drm_of_find_panel_or_bridge

[Frank Rowand]

On 02/03/17 19:36, Rob Herring wrote:
> Many drivers have a common pattern of searching the OF graph for either an
> attached panel or bridge and then finding the DRM struct for the panel
> or bridge. Also, most drivers need to handle deferred probing when the
> DRM device is not yet instantiated. Create a common function,
> drm_of_find_panel_or_bridge, to find the connected node and the
> associated DRM panel or bridge device.
> 
> Signed-off-by: Rob Herring 
> ---
>  drivers/gpu/drm/drm_of.c | 50 
> 
>  include/drm/drm_of.h | 13 +
>  2 files changed, 63 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
> index 47848ed8ca48..b29ce2f52113 100644
> --- a/drivers/gpu/drm/drm_of.c
> +++ b/drivers/gpu/drm/drm_of.c
> @@ -3,7 +3,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
> +#include 
>  #include 
>  
>  static void drm_release_of(struct device *dev, void *data)
> @@ -207,3 +209,51 @@ int drm_of_encoder_active_endpoint(struct device_node 
> *node,
>   return -EINVAL;
>  }
>  EXPORT_SYMBOL_GPL(drm_of_encoder_active_endpoint);
> +
> +/*
> + * drm_of_find_panel_or_bridge - return connected panel or bridge device
> + * @np: device tree node containing encoder input ports

  @port: 
  @endpoint: 


> + * @panel: pointer to hold returned drm_panel
> + * @bridge: pointer to hold returned drm_bridge
> + *
> + * Given a DT node's port and endpoint number, find the connected node and
> + * return either the associated struct drm_panel or drm_bridge device.
> + *
> + * Returns zero if successful, or one of the standard error codes if it 
> fails.
> + */
> +int drm_of_find_panel_or_bridge(const struct device_node *np,
> + int port, int endpoint,
> + struct drm_panel **panel,
> + struct drm_bridge **bridge)
> +{

< snip >

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

imxdrm issue on SABRE Lite

[Dan MacDonald]

Hi Phillipp

I'm having trouble getting xf86-video-armada working properly on a
Element 14 / Embest SABRE Lite board running Arch Linux with kernel
4.9.8. I have been in touch with RMK and he's confident the crash
below is caused by a kernel issue relating to imxdrm and a null
pointer dereference.

The first indiction of X/armada not being happy it that it only starts
in 720x480 when connected to a 4K HDMI display, and when I try
running:

xrandr --output HDMI1 --mode 1920x1080

X crashes.

Here's the serial console output for X loading and then crashing after
I try running that xrandr command:

 Arch Linux 4.9.8-1-ARCH (ttymxc1)

alarm login: [   19.197477] fec 2188000.ethernet eth0: Link is Up -
1Gbps/Full - flow control rx/tx
[   19.205165] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   33.08] vgaarb: this pci device is not a vga device
[   33.203520] vgaarb: this pci device is not a vga device
[   33.447051] imx-ipuv3 240.ipu: DC stop timeout after 50 ms
[   33.707042] [ cut here ]
[   33.711682] WARNING: CPU: 1 PID: 316 at
drivers/gpu/drm/drm_atomic_helper.c:1140
drm_atomic_helper_wait_for_vblanks+0x274/0x278
[   33.723187] [CRTC:24] vblank wait timed out
[   33.727395] Modules linked in: snd_soc_sgtl5000 snd_soc_fsl_ssi
snd_soc_imx_sgtl5000 imx_pcm_fiq imx_pcm_dma snd_soc_fsl_asrc
snd_soc_fsl_asoc_card snd_soc_core dw_hdmi_ahb_audio snd_pcm_dmaengine
caam_jr imx_ipuv3_crtc snd_ac97_codec coda v4l2_mem2mem
videobuf2_dma_contig ac97_bus imx_ipu_v3 snd_soc_imx_audmux snd_pcm
videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core
dw_hdmi_imx caam imx2_wdt ofpart spi_imx evdev dw_hdmi etnaviv imx_ldb
pwm_imx snd_timer parallel_display uio_pdrv_genirq uio imxdrm
sch_fq_codel ip_tables x_tables
[   33.776237] CPU: 1 PID: 316 Comm: Xorg Not tainted 4.9.8-1-ARCH #1
[   33.782419] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[   33.788965] [] (unwind_backtrace) from []
(show_stack+0x10/0x14)
[   33.796719] [] (show_stack) from []
(dump_stack+0x88/0x9c)
[   33.803951] [] (dump_stack) from [] (__warn+0xe8/0x100)
[   33.810919] [] (__warn) from []
(warn_slowpath_fmt+0x48/0x6c)
[   33.818410] [] (warn_slowpath_fmt) from []
(drm_atomic_helper_wait_for_vblanks+0x274/0x278)
[   33.828516] [] (drm_atomic_helper_wait_for_vblanks) from
[] (imx_drm_atomic_commit_tail+0x48/0x58 [imxdrm])
[   33.840004] [] (imx_drm_atomic_commit_tail [imxdrm]) from
[] (commit_tail+0x40/0x5c)
[   33.849489] [] (commit_tail) from []
(drm_atomic_helper_commit+0x94/0xd8)
[   33.858019] [] (drm_atomic_helper_commit) from
[] (drm_atomic_helper_set_config+0x78/0x9c)
[   33.868028] [] (drm_atomic_helper_set_config) from
[] (drm_mode_set_config_internal+0x58/0xdc)
[   33.878382] [] (drm_mode_set_config_internal) from
[] (drm_mode_setcrtc+0x4a4/0x550)
[   33.887867] [] (drm_mode_setcrtc) from []
(drm_ioctl+0x214/0x44c)
[   33.895704] [] (drm_ioctl) from []
(do_vfs_ioctl+0xac/0x980)
[   33.903104] [] (do_vfs_ioctl) from []
(SyS_ioctl+0x6c/0x7c)
[   33.910422] [] (SyS_ioctl) from []
(ret_fast_syscall+0x0/0x3c)
[   33.918023] ---[ end trace e8a77aa320be7e55 ]---
[   43.997066] [drm:drm_atomic_helper_commit_cleanup_done] *ERROR*
[CRTC:24:crtc-0] flip_done timed out
[   55.517063] [drm:drm_atomic_helper_commit_cleanup_done] *ERROR*
[CRTC:24:crtc-0] flip_done timed out
[   56.958264] alloc_contig_range: [4d0b7, 4d0b8) PFNs busy
[   90.896615] usb 1-1.2.3: new low-speed USB device number 6 using ci_hdrc
[   91.050796] usb 1-1.2.3: New USB device found, idVendor=0458, idProduct=003a
[   91.057888] usb 1-1.2.3: New USB device strings: Mfr=1, Product=2,
SerialNumber=0
[   91.065382] usb 1-1.2.3: Product: Optical Mouse
[   91.069944] usb 1-1.2.3: Manufacturer: Genius
[   91.082071] input: Genius Optical Mouse as
/devices/soc0/soc/210.aips-bus/2184200.usb/ci_hdrc.1/usb1/1-1/1-1.2/1-1.2.3/1-1.2.3:1.0/0003:0458:003A.0003/input/input3
[   91.098116] hid-generic 0003:0458:003A.0003: input,hidraw2: USB HID
v1.11 Mouse [Genius Optical Mouse] on usb-ci_hdrc.1-1.2.3/input0
[   91.162048] mousedev: PS/2 mouse device common for all mice
[  214.765689] imx-ipuv3 240.ipu: DC stop timeout after 50 ms
[  214.825688] Unable to handle kernel NULL pointer dereference at
virtual address 
[  214.833783] pgd = ed1b8000
[  214.836491] [] *pgd=4c974831
[  214.840084] Internal error: Oops: 17 [#1] SMP ARM
[  214.844789] Modules linked in: mousedev snd_soc_sgtl5000
snd_soc_fsl_ssi snd_soc_imx_sgtl5000 imx_pcm_fiq imx_pcm_dma
snd_soc_fsl_asrc snd_soc_fsl_asoc_card snd_soc_core dw_hdmi_ahb_audio
snd_pcm_dmaengine caam_jr imx_ipuv3_crtc snd_ac97_codec coda
v4l2_mem2mem videobuf2_dma_contig ac97_bus imx_ipu_v3
snd_soc_imx_audmux snd_pcm videobuf2_vmalloc videobuf2_memops
videobuf2_v4l2 videobuf2_core dw_hdmi_imx caam imx2_wdt ofpart spi_imx
evdev dw_hdmi etnaviv imx_ldb pwm_imx snd_timer parallel_display
uio_pdrv_genirq uio imxdrm sch_fq_codel ip_tables x_tables
[  214.894338] CPU: 2 PID: 316 Comm

[PATCH 1/8] ARM: sunxi_defconfig: Enable simple panel

[Priit Laes]

From: Jonathan Liu 

Signed-off-by: Jonathan Liu 
---
 arch/arm/configs/sunxi_defconfig | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig
index da92c25..7abe6a4 100644
--- a/arch/arm/configs/sunxi_defconfig
+++ b/arch/arm/configs/sunxi_defconfig
@@ -153,3 +153,7 @@ CONFIG_NLS_ISO8859_1=y
 CONFIG_PRINTK_TIME=y
 CONFIG_DEBUG_FS=y
 CONFIG_CRYPTO_DEV_SUN4I_SS=y
+CONFIG_BACKLIGHT_CLASS_DEVICE=y
+CONFIG_BACKLIGHT_LCD_SUPPORT=y
+CONFIG_BACKLIGHT_PWM=y
+CONFIG_DRM_PANEL_SIMPLE=y
-- 
2.9.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 0/4] Introduce drmfs pseudo filesystem for drm subsystem

[sourab gupta]

On Mon, 2016-12-19 at 17:15 -0800, Laurent Pinchart wrote:
> Hi Swati,
> 
> On Monday 19 Dec 2016 16:12:22 swati.dhin...@intel.com wrote:
> > From: Swati Dhingra 
> >
> > Currently, we don't have a stable ABI which can be used for the purpose of
> > providing output debug/loggging/crc and other such data from DRM.
> > The ABI in current use (filesystems, ioctls, et al.) have their own
> > constraints and are intended to output a particular type of data.
> > Few cases in point:
> > sysfs - stable ABI, but constrained to one textual value per file
> > debugfs   - unstable ABI, free-for-all
> > ioctls- not as suitable to many single purpose continuous data
> > dumping, we would very quickly run out ioctl space; requires more
> > userspace support than "cat"
> > device nodes -  a real possibilty, kernel instantiation is more tricky,
> >   requires udev (+udev.rules) or userspace discovery of the
> >   dynamic major:minor (via sysfs) [mounting a registered
> >   filesystem is easy in comparison]
> > netlink   - stream based, therefore involves numerous copies.
> >
> > Debugfs is the lesser among the evils here, thereby we have grown used to
> > the convenience and flexibility in presentation that debugfs gives us
> > (including relayfs inodes) that we want some of that hierachy in stable user
> > ABI form.
> 
> Seriously, why ? A subsystem growing its own file system sounds so wrong. It
> seems that you want to have all the benefits of a stable ABI without going
> through the standardization effort that this requires. I can see so many ways
> that drmfs could be abused, with drivers throwing in new data with little or
> no review. You'll need very compelling arguments to convince me.
> 

Hi Laurent,
Can you please let us know how to address the standardization issues? As
per our (limited) knowledge, drmfs seemed to be the most suitable
solution for exposing usecases such as microprocessor logs in i915, and
possibly other such usecases, which ideally can't fit in with
sysfs/debugfs/ioctls due to reasons mentioned above.

But having said that, standardization requires a lot more effort
(defining the constraints etc.), which we're not familiar with, frankly.
Can you please provide your views on how to proceed as such, since the
idea seemed worth pursuing to us (It's a drm based filesystem, whose
existence depends on drm, and directory contents solely controlled by
the corresponding drm driver - as such the contents shouldn't be
controllable by an external driver).
Or, should this be dropped, if the idea of a subsystem having its own
filesystem is fundamentally wrong to its core?

Regards,
Sourab

> > Due to these limitations, there is a need for a new pseudo filesytem, that
> > would act as a stable 'free-for-all' ABI, with the heirarchial structure and
> > thus convenience of debugfs. This will be managed by drm, thus named
> > 'drmfs'. DRM would register this filesystem to manage a canonical
> > mountpoint, but this wouldn't limit everyone to only using that pseudofs
> > underneath.
> >
> > This can serve to hold various kinds of output data from Linux DRM
> > subsystems, for the files which can't truely fit anywhere else with
> > existing ABI's but present so, for the lack of a better place.
> >
> > In this patch series, we have introduced a pseudo filesystem named as
> > 'drmfs' for now. The filesystem is introduced in the first patch, and the
> > subsequent patches make use of the filesystem interfaces, in drm driver,
> > and making them available for use by the drm subsystem components, one of
> > which is i915. We've moved the location of i915 GuC logs from debugfs to
> > drmfs in the last patch. Subsequently, more such files such as pipe_crc,
> > error states, memory stats, etc. can be move to this filesystem, if the
> > idea introduced here is acceptable per se. The filesystem introduced is
> > being used to house the data generated by i915 driver in this patch series,
> > but will hopefully be generic enough to provide scope for usage by any
> > other drm subsystem component.
> >
> > The patch series is being floated as RFC to gather feedback on the idea and
> > infrastructure proposed here and it's suitability to address the specific
> > problem statement/use case.
> >
> > v2: fix the bat failures caused due to missing config check
> >
> > v3: Changes made:
> > - Move the location of drmfs from fs/ to drivers/gpu/drm/ (Chris)
> > - Moving config checks to header (Chris,Daniel)
> >
> > v4: Added the kernel Documentaion (using Sphinx).
> >
> > Sourab Gupta (4):
> >   drm: Introduce drmfs pseudo filesystem interfaces
> >   drm: Register drmfs filesystem from drm init
> >   drm: Create driver specific root directory inside drmfs
> >   drm/i915: Creating guc log file in drmfs instead of debugfs
> >
> >  Documentation/gpu/drm-uapi.rst |  76 
> >  drivers/gpu/drm/Kconfig|   9 +
> >  drivers/gpu/drm/M

[PATCH 8/8] ARM: dts: sun4i: gemei-g9: Add LVDS display support

[Priit Laes]

Signed-off-by: Priit Laes 
---
 arch/arm/boot/dts/sun4i-a10-gemei-g9.dts | 95 +---
 1 file changed, 86 insertions(+), 9 deletions(-)

diff --git a/arch/arm/boot/dts/sun4i-a10-gemei-g9.dts 
b/arch/arm/boot/dts/sun4i-a10-gemei-g9.dts
index 9616cde..c19f906 100644
--- a/arch/arm/boot/dts/sun4i-a10-gemei-g9.dts
+++ b/arch/arm/boot/dts/sun4i-a10-gemei-g9.dts
@@ -1,5 +1,5 @@
 /*
- * Copyright 2015 Priit Laes
+ * Copyright 2015-2017 Priit Laes
  *
  * Priit Laes 
  *
@@ -48,28 +48,69 @@
 #include 
 #include 
 #include 
+#include 
 
 / {
model = "Gemei G9 Tablet";
compatible = "gemei,g9", "allwinner,sun4i-a10";
 
+   /*
+* TODO:
+*   2x cameras via CSI
+*   AXP battery management
+*   NAND
+*   OTG
+*   Touchscreen - gt801_2plus1 @ i2c adapter 2 @ 0x48
+*   HDMI output
+*/
+
aliases {
serial0 = &uart0;
};
 
+   backlight: backlight {
+   compatible = "pwm-backlight";
+   pinctrl-names = "default";
+   pinctrl-0 = <&lcd_backlight_pin>;
+   /* TODO: Figure out proper parameters */
+   pwms = <&pwm 0 5 PWM_POLARITY_INVERTED>;
+   brightness-levels = <0 10 20 30 40 50 60 70 80 90 100>;
+   enable-gpios = <&pio 7 7 GPIO_ACTIVE_HIGH>; /* PH7 */
+   default-brightness-level = <8>;
+   };
+
chosen {
stdout-path = "serial0:115200n8";
};
+
+   panel: panel {
+   compatible = "lg,lp097x02-slq2";
+   pinctrl-names = "default";
+   pinctrl-0 = <&lcd_enable_pin &lcd_lvds0_pins>;
+   enable-gpios = <&pio 7 8 GPIO_ACTIVE_HIGH>; /* PH8 */
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   panel_input: endpoint {
+   remote-endpoint = <&tcon0_out_panel>;
+   };
+   };
+   };
+
+   display-engine {
+   compatible = "allwinner,sun5i-a13-display-engine";
+   allwinner,pipelines = <&fe0>;
+   };
+};
+
+&be0 {
+   status = "okay";
 };
 
-/*
- * TODO:
- *   2x cameras via CSI
- *   AXP battery management
- *   NAND
- *   OTG
- *   Touchscreen - gt801_2plus1 @ i2c adapter 2 @ 0x48
- */
 &codec {
/* PH15 controls power to external amplifier (ft2012q) */
pinctrl-names = "default";
@@ -90,6 +131,10 @@
status = "okay";
 };
 
+&fe0 {
+   status = "okay";
+};
+
 &i2c0 {
pinctrl-names = "default";
pinctrl-0 = <&i2c0_pins_a>;
@@ -159,6 +204,27 @@
pins = "PH15";
function = "gpio_out";
};
+
+   lcd_backlight_pin: lcd_backlight_pin@0 {
+   pins = "PH7";
+   function = "gpio_out";
+   };
+
+   lcd_enable_pin: lcd_enable_pin@0 {
+   pins = "PH8";
+   function = "gpio_out";
+   };
+
+   lcd_lvds0_pins: lcd_lvds0_pins@0 {
+   pins =  "PD0", "PD1", "PD2", "PD3", "PD4", "PD5", "PD6", "PD7", 
"PD8", "PD9";
+   function = "lvds0";
+   };
+};
+
+&pwm {
+pinctrl-names = "default";
+pinctrl-0 = <&pwm0_pins_a>;
+status = "okay";
 };
 
 ®_dcdc2 {
@@ -194,6 +260,17 @@
status = "okay";
 };
 
+&tcon0 {
+   mode = "lvds";
+   status = "okay";
+};
+
+&tcon0_out {
+   tcon0_out_panel: endpoint@1 {
+   reg = <0>;
+   remote-endpoint = <&panel_input>;
+   };
+};
 
 &uart0  {
pinctrl-names = "default";
-- 
2.9.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: change connector disconnected debug message to an error

[Shuah Khan]

On 02/03/2017 01:06 AM, Daniel Vetter wrote:
> On Thu, Feb 02, 2017 at 10:25:44AM -0700, Shuah Khan wrote:
>> On 02/02/2017 01:32 AM, Jani Nikula wrote:
>>> On Thu, 02 Feb 2017, Shuah Khan  wrote:
 Change drm_helper_probe_single_connector_modes() to print an error to
 report connector disconnected status instead of a debug message.

 When this condition occurs, application doesn't know the real error and
 reports it as driver lacking support for mode setting. Change it to an
 error to make it easier to debug.
>>>
>>> Please explain what makes this condition an error. Connectors get
>>> connected and disconnected, business as usual, why should this be an
>>> error?
>>>
>>> BR,
>>> Jani.
>>
>> Disconnecting connector itself isn't an error. When user-space tries
>> to access it, it would be useful to report the status that the connector
>> is disconnected.
>>
>> I use embedded system(s) that don't like it when HDMI is hot added or
>> removed. Also, because of return power, it is safer to disconnect HDMI
>> and then apply power to the board. It chased a few libdrm and user-space
>> dead ends before I enabled drm debug and was able to fix the real issue,
>> which is a disconnected cable.
>>
>> User-space prints rather confusing messages as it doesn't really know
>> the disconnected status as it isn't returned to it.
>>
>> I figured it might be a good idea to at least print a message and this can
>> be a notice or info instead of an error. I do think its is worth while in
>> some cases.
> 
> This sounds like a very specific use-case you have here, and it can easily
> be supported by a small deamon in userspace (only on debug builds ofc)
> that tell you that someone unplugged the screen when it shouldn't have
> been.

drm_helper_probe_single_connector_modes() finds the condition and doesn't
have a means to return it to the user-space.

Instead of error or debug message, would it be useful to add a trace event
to report status of connector to drm_helper_probe_single_connector_modes()
Trace could be triggered as needed and turned off.

Please let me know what you think of this idea? If it sounds useful, I can
add it.

> 
> Because upstream runs also on non-embedded systems, where unplugging is
> normal, and we definitely don't want to spam dmesg.
> -Daniel
> 

thanks,
-- Shuah

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/8] drm/panel: simple: Add support for LG LP097x02-slq2 panel

[Priit Laes]

Add simple-panel support for the LG LP097x02-slq2, which is 10"
1024x768 LVDS panel.

Signed-off-by: Priit Laes 
---
 drivers/gpu/drm/panel/panel-simple.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 06aaf79..2948fed 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1205,6 +1205,28 @@ static const struct panel_desc lg_lp097qx1_spa1 = {
},
 };
 
+static const struct drm_display_mode lg_lp097x02_slq2_mode = {
+.clock = 10,
+.hdisplay = 1024,
+.hsync_start = 1024 + 260,
+.hsync_end = 1024 + 260 + 1,
+.htotal = 1024 + 260 + 1 + 799,
+.vdisplay = 768,
+.vsync_start = 768 + 16,
+.vsync_end = 768 + 16 + 1,
+.vtotal = 768 + 16 + 1 + 15,
+.vrefresh = 60,
+};
+
+static const struct panel_desc lg_lp097x02_slq2 = {
+.modes = &lg_lp097x02_slq2_mode,
+.num_modes = 1,
+.size = {
+.width = 197,
+.height = 147,
+},
+};
+
 static const struct drm_display_mode lg_lp120up1_mode = {
.clock = 162300,
.hdisplay = 1920,
@@ -1817,6 +1839,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "lg,lp097qx1-spa1",
.data = &lg_lp097qx1_spa1,
}, {
+   .compatible = "lg,lp097x02-slq2",
+   .data = &lg_lp097x02_slq2,
+   }, {
.compatible = "lg,lp120up1",
.data = &lg_lp120up1,
}, {
-- 
2.9.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 6/8] drm/sun4i: Add initial LVDS stub

[Priit Laes]

Signed-off-by: Priit Laes 
---
 drivers/gpu/drm/sun4i/Makefile |   1 +
 drivers/gpu/drm/sun4i/sun4i_lvds.c | 247 +
 drivers/gpu/drm/sun4i/sun4i_lvds.h |  15 +++
 3 files changed, 263 insertions(+)
 create mode 100644 drivers/gpu/drm/sun4i/sun4i_lvds.c
 create mode 100644 drivers/gpu/drm/sun4i/sun4i_lvds.h

diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
index d625a82..5dfbe16 100644
--- a/drivers/gpu/drm/sun4i/Makefile
+++ b/drivers/gpu/drm/sun4i/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_DRM_SUN4I)   += sun4i-drm.o 
sun4i-tcon.o
 obj-$(CONFIG_DRM_SUN4I)+= sun4i_backend.o
 obj-$(CONFIG_DRM_SUN4I)+= sun6i_drc.o
 obj-$(CONFIG_DRM_SUN4I)+= sun4i_tv.o
+obj-$(CONFIG_DRM_SUN4I)+= sun4i_lvds.o
diff --git a/drivers/gpu/drm/sun4i/sun4i_lvds.c 
b/drivers/gpu/drm/sun4i/sun4i_lvds.c
new file mode 100644
index 000..2ba4705
--- /dev/null
+++ b/drivers/gpu/drm/sun4i/sun4i_lvds.c
@@ -0,0 +1,247 @@
+/*
+ * Copyright (C) 2016 Priit Laes
+ *
+ * Priit Laes 
+ *
+ * Based on sun4i_rgb.c by Maxime Ripard 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ */
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include "sun4i_drv.h"
+#include "sun4i_tcon.h"
+
+struct sun4i_lvds {
+   struct drm_connectorconnector;
+   struct drm_encoder  encoder;
+
+   struct sun4i_drv*drv;
+};
+
+static inline struct sun4i_lvds *
+drm_connector_to_sun4i_lvds(struct drm_connector *connector)
+{
+   return container_of(connector, struct sun4i_lvds,
+   connector);
+}
+
+static inline struct sun4i_lvds *
+drm_encoder_to_sun4i_lvds(struct drm_encoder *encoder)
+{
+   return container_of(encoder, struct sun4i_lvds,
+   encoder);
+}
+
+static int sun4i_lvds_get_modes(struct drm_connector *connector)
+{
+   struct sun4i_lvds *lvds =
+   drm_connector_to_sun4i_lvds(connector);
+   struct sun4i_drv *drv = lvds->drv;
+   struct sun4i_tcon *tcon = drv->tcon;
+
+   return drm_panel_get_modes(tcon->panel);
+}
+
+static int sun4i_lvds_mode_valid(struct drm_connector *connector,
+struct drm_display_mode *mode)
+{
+   DRM_DEBUG_DRIVER("LVDS mode valid!\n");
+   return MODE_OK;
+}
+
+static struct drm_connector_helper_funcs sun4i_lvds_con_helper_funcs = {
+   .get_modes  = sun4i_lvds_get_modes,
+   .mode_valid = sun4i_lvds_mode_valid,
+};
+
+static enum drm_connector_status
+sun4i_lvds_connector_detect(struct drm_connector *connector, bool force)
+{
+   return connector_status_connected;
+}
+
+static void
+sun4i_lvds_connector_destroy(struct drm_connector *connector)
+{
+   struct sun4i_lvds *lvds = drm_connector_to_sun4i_lvds(connector);
+   struct sun4i_drv *drv = lvds->drv;
+   struct sun4i_tcon *tcon = drv->tcon;
+
+   drm_panel_detach(tcon->panel);
+   drm_connector_cleanup(connector);
+}
+
+static struct drm_connector_funcs sun4i_lvds_con_funcs = {
+   .dpms   = drm_atomic_helper_connector_dpms,
+   .detect = sun4i_lvds_connector_detect,
+   .fill_modes = drm_helper_probe_single_connector_modes,
+   .destroy= sun4i_lvds_connector_destroy,
+   .reset  = drm_atomic_helper_connector_reset,
+   .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+   .atomic_destroy_state   = drm_atomic_helper_connector_destroy_state,
+};
+
+static int sun4i_lvds_atomic_check(struct drm_encoder *encoder,
+ struct drm_crtc_state *crtc_state,
+ struct drm_connector_state *conn_state)
+{
+   return 0;
+}
+
+static void sun4i_lvds_encoder_enable(struct drm_encoder *encoder)
+{
+   struct sun4i_lvds *lvds = drm_encoder_to_sun4i_lvds(encoder);
+   struct sun4i_drv *drv = lvds->drv;
+   struct sun4i_tcon *tcon = drv->tcon;
+
+   DRM_DEBUG_DRIVER("Enabling LVDS output\n");
+
+   if (!IS_ERR(tcon->panel)) {
+   drm_panel_prepare(tcon->panel);
+   drm_panel_enable(tcon->panel);
+   }
+
+   /* encoder->bridge can be NULL; drm_bridge_enable checks for it */
+   drm_bridge_enable(encoder->bridge);
+
+   sun4i_tcon_channel_enable(tcon, 0);
+}
+
+static void sun4i_lvds_encoder_disable(struct drm_encoder *encoder)
+{
+   struct sun4i_lvds *lvds = drm_encoder_to_sun4i_lvds(encoder);
+   struct sun4i_drv *drv = lvds->drv;
+   struct sun4i_tcon *tcon = drv->tcon;
+
+   DRM_DEBUG_DRIVER("Disabling LVDS output\n");
+
+   sun4i_tcon_channel_disable(tcon, 0);
+
+   /* encoder->bri

Re: imxdrm issue on Hummingboard with LVDS enabled

[Russell King - ARM Linux]

On Sun, Feb 12, 2017 at 01:18:54PM +, Russell King - ARM Linux wrote:
> Hi,
> 
> Here's another issue with imxdrm.  I got this while trying to reproduce
> Dan's problem by enabling the lvds output using the patch below
> originally from Fabio, but updated a bit.  This doesn't occur if I leave
> LVDS disabled.
> 
> The taint is due to the IMX capture modules from Steve, who chose to put
> his code in drivers/staging/media rather than drivers/media.  However,
> the last module to make the capture stuff active (imx-csi) which interfaces
> the drivers/gpu/ipu-v3 code with the capture code has not been loaded.
> 
> [ cut here ]
> WARNING: CPU: 1 PID: 1049 at 
> /home/rmk/git/linux-rmk/drivers/gpu/drm/drm_atomic_helper.c:1149 
> drm_atomic_helper_wait_for_vblanks+0x218/0x224
> [CRTC:29] vblank wait timed out

Can someone please explain to me how you go from something like
"[CRTC:29]" to something meaningful, such as identifying which
exact CRTC failed here?

Given that the ID numbers given out by DRM for individual components
come from the dev->mode_config.crtc_idr IDR, without knowing in
exact detail the precise registration order of these objects with
drm_mode_object_get(), printing "[CRTC:29]" is utterly meaningless -
it conveys zero useful information.  DRM might as well be printing
random numbers instead.

At least the pre-atomic DRM code printed crtc->name as well, which
would at least indicate which _CRTC_ in numeric order of registration
was the cause, which is slightly easier to guess which hardware CRTC
in question caused the problem.

Some consistency in DRM land would be nice...

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/8] drm/sun4i: Add basic LVDS support for A10

[Priit Laes]

This series adds initial LVDS functionality for A10 SoC and includes
display blocks (TCON, backend and frontend) for A10 dtsi and implements 
of mode property for TCON to allow switching between rgb/lvds output.

This series has been tested on Gemei G9 A10 tablet, but still relies
on u-boot to properly set up LVDS reset controller.

---

Jonathan Liu (1):
  ARM: sunxi_defconfig: Enable simple panel

Priit Laes (7):
  ARM: sun4i: Add display blocks for the sun4i dtsi.
  drm/panel: simple: Add support for LG LP097x02-slq2 panel
  drm/sun4i: Add optional 'mode' property to TCON
  drm/sun4i: Add encoder type argument to sun4i_tcon0_mode_set
  drm/sun4i: Add initial LVDS stub
  drm/sun4i: Add various bits and pieces to enable LVDS support on sun4i
  ARM: dts: sun4i: gemei-g9: Add LVDS display support

 .../bindings/display/sunxi/sun4i-drm.txt   |   3 +
 arch/arm/boot/dts/sun4i-a10-gemei-g9.dts   |  95 ++-
 arch/arm/boot/dts/sun4i-a10.dtsi   | 104 
 arch/arm/configs/sunxi_defconfig   |   4 +
 drivers/gpu/drm/panel/panel-simple.c   |  25 ++
 drivers/gpu/drm/sun4i/Makefile |   1 +
 drivers/gpu/drm/sun4i/sun4i_lvds.c | 276 +
 drivers/gpu/drm/sun4i/sun4i_lvds.h |  15 ++
 drivers/gpu/drm/sun4i/sun4i_rgb.c  |   2 +-
 drivers/gpu/drm/sun4i/sun4i_tcon.c |  57 -
 drivers/gpu/drm/sun4i/sun4i_tcon.h |  18 +-
 11 files changed, 580 insertions(+), 20 deletions(-)
 create mode 100644 drivers/gpu/drm/sun4i/sun4i_lvds.c
 create mode 100644 drivers/gpu/drm/sun4i/sun4i_lvds.h

-- 
2.9.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

imxdrm issue on Hummingboard with LVDS enabled

[Russell King - ARM Linux]

Hi,

Here's another issue with imxdrm.  I got this while trying to reproduce
Dan's problem by enabling the lvds output using the patch below
originally from Fabio, but updated a bit.  This doesn't occur if I leave
LVDS disabled.

The taint is due to the IMX capture modules from Steve, who chose to put
his code in drivers/staging/media rather than drivers/media.  However,
the last module to make the capture stuff active (imx-csi) which interfaces
the drivers/gpu/ipu-v3 code with the capture code has not been loaded.

[ cut here ]
WARNING: CPU: 1 PID: 1049 at 
/home/rmk/git/linux-rmk/drivers/gpu/drm/drm_atomic_helper.c:1149 
drm_atomic_helper_wait_for_vblanks+0x218/0x224
[CRTC:29] vblank wait timed out
Modules linked in: imx_camif(C) imx_ic(C) imx_smfc(C) caam_jr uvcvideo 
snd_soc_imx_sgtl5000 snd_soc_fsl_asoc_card snd_soc_imx_spdif imx_media(C) 
snd_soc_imx_audmux imx_mipi_csi2(C) imx_media_core(C) snd_soc_sgtl5000 imx219 
caam imx_sdma video_multiplexer imx2_wdt coda v4l2_mem2mem videobuf2_v4l2 
videobuf2_dma_contig snd_soc_fsl_spdif videobuf2_core snd_soc_fsl_ssi 
imx_pcm_dma videobuf2_vmalloc videobuf2_memops imx_thermal nfsd 
rc_pinnacle_pctv_hd dw_hdmi_cec dw_hdmi_ahb_audio imx_ldb etnaviv
CPU: 1 PID: 1049 Comm: Xorg Tainted: G C  4.10.0-rc7+ #2106
Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
Backtrace: 
[] (dump_backtrace) from [] (show_stack+0x18/0x1c)
 r6:600f0013 r5: r4: r3:
[] (show_stack) from [] (dump_stack+0xa4/0xdc)
[] (dump_stack) from [] (__warn+0xdc/0x108)
 r6:c08db088 r5: r4:ee9a5c98 r3:d039ee40
[] (__warn) from [] (warn_slowpath_fmt+0x40/0x48)
 r10:d01d5018 r8:00b0 r7:d01d4000 r6:eea7d000 r5:eaab4480 r4:0001
[] (warn_slowpath_fmt) from [] 
(drm_atomic_helper_wait_for_vblanks+0x218/0x224)
 r3:001d r2:c08db1b4
[] (drm_atomic_helper_wait_for_vblanks) from [] 
(imx_drm_atomic_commit_tail+0x50/0x60)
 r10:d02be400 r9:eaab4a00 r8: r7:d01d4000 r6: r5:d01d4000
 r4:eaab4480
[] (imx_drm_atomic_commit_tail) from [] 
(commit_tail+0x48/0x94)
 r5:c0a456a4 r4:eaab4480
[] (commit_tail) from [] 
(drm_atomic_helper_commit+0xc4/0x150)
 r5: r4:eaab4480
[] (drm_atomic_helper_commit) from [] 
(drm_atomic_commit+0x4c/0x60)
 r8:ed57f000 r7:ee9a5dd8 r6:d01d4000 r5: r4:eaab4480 r3:c03daf04
[] (drm_atomic_commit) from [] 
(drm_atomic_helper_set_config+0x80/0xd0)
 r6:d01d5018 r5: r4:eaab4480 r3:0004
[] (drm_atomic_helper_set_config) from [] 
(drm_mode_set_config_internal+0x60/0xe4)
 r7:d01d5018 r6:d01d4000 r5:eaab4a00 r4:ed57f000
[] (drm_mode_set_config_internal) from [] 
(drm_mode_setcrtc+0xdc/0x47c)
 r7:0001 r6:d01d4000 r5:eaab4a00 r4:ee9a5e58
[] (drm_mode_setcrtc) from [] (drm_ioctl+0x204/0x41c)
 r10:c06864a2 r9:d01d4000 r8:c07495a0 r7:ee9a5e58 r6:d03e3400 r5:0068
 r4:
[] (drm_ioctl) from [] (do_vfs_ioctl+0x98/0x9a0)
 r10:ed4ba068 r9:ee9a4000 r8:be9fa5c0 r7:0008 r6:0008 r5:ee1a4500
 r4:c018961c
[] (do_vfs_ioctl) from [] (SyS_ioctl+0x3c/0x60)
 r10: r9:ee9a4000 r8:be9fa5c0 r7:0008 r6:c06864a2 r5:ee1a4500
 r4:ee1a4500
[] (SyS_ioctl) from [] (ret_fast_syscall+0x0/0x1c)
 r8:c000ff04 r7:0036 r6:c06864a2 r5:be9fa5c0 r4:b6c4ace8 r3:0001
---[ end trace e9cdd5f49e5cc87f ]---


diff --git a/arch/arm/boot/dts/imx6dl-hummingboard.dts 
b/arch/arm/boot/dts/imx6dl-hummingboard.dts
index d5c966031962..9f605d14c50f 100644
--- a/arch/arm/boot/dts/imx6dl-hummingboard.dts
+++ b/arch/arm/boot/dts/imx6dl-hummingboard.dts
@@ -48,3 +48,10 @@
model = "SolidRun HummingBoard Solo/DualLite";
compatible = "solidrun,hummingboard/dl", "fsl,imx6dl";
 };
+
+&clks {
+   assigned-clocks = <&clks IMX6QDL_CLK_LDB_DI0_SEL>,
+ <&clks IMX6QDL_CLK_LDB_DI1_SEL>;
+   assigned-clock-parents = <&clks IMX6QDL_CLK_PLL3_USB_OTG>,
+<&clks IMX6QDL_CLK_PLL3_USB_OTG>;
+};
diff --git a/arch/arm/boot/dts/imx6qdl-hummingboard.dtsi 
b/arch/arm/boot/dts/imx6qdl-hummingboard.dtsi
index d6c2358ffad4..258107246d64 100644
--- a/arch/arm/boot/dts/imx6qdl-hummingboard.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-hummingboard.dtsi
@@ -302,3 +302,28 @@
cd-gpios = <&gpio1 4 GPIO_ACTIVE_LOW>;
status = "okay";
 };
+
+&ldb {
+   status = "okay";
+
+   lvds-channel@1 {
+   fsl,data-mapping = "spwg";
+   fsl,data-width = <18>;
+   status = "okay";
+
+   display-timings {
+   native-mode = <&timing0>;
+   timing0: hsd100pxn1 {
+   clock-frequency = <6500>;
+   hactive = <1024>;
+   vactive = <768>;
+   hback-porch = <220>;
+   hfront-porch = <40>;
+   vback-porch = <21>;
+   vfront-porch = <7>;
+   hsyn

[PATCH 4/8] drm/sun4i: Add optional 'mode' property to TCON

[Priit Laes]

Add variable to enable either 'rgb' or 'lvds' output.

Signed-off-by: Priit Laes 
---
 Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt 
b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
index b82c004..c367ede 100644
--- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
+++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
@@ -43,6 +43,9 @@ Required properties:
  - reset-names: the reset names mentioned above
  - clock-output-names: Name of the pixel clock created
 
+- mode: Defines which encoder will be enabled. Values are 'rgb', 'lvds'.
+  Defaults to 'rgb' if not set.
+
 - ports: A ports node with endpoint definitions as defined in
   Documentation/devicetree/bindings/media/video-interfaces.txt. The
   first port should be the input endpoint, the second one the output
-- 
2.9.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: imxdrm issue on Hummingboard with LVDS enabled

[Russell King - ARM Linux]

On Sun, Feb 12, 2017 at 01:42:38PM +, Russell King - ARM Linux wrote:
> On Sun, Feb 12, 2017 at 01:18:54PM +, Russell King - ARM Linux wrote:
> > Hi,
> > 
> > Here's another issue with imxdrm.  I got this while trying to reproduce
> > Dan's problem by enabling the lvds output using the patch below
> > originally from Fabio, but updated a bit.  This doesn't occur if I leave
> > LVDS disabled.
> > 
> > The taint is due to the IMX capture modules from Steve, who chose to put
> > his code in drivers/staging/media rather than drivers/media.  However,
> > the last module to make the capture stuff active (imx-csi) which interfaces
> > the drivers/gpu/ipu-v3 code with the capture code has not been loaded.
> > 
> > [ cut here ]
> > WARNING: CPU: 1 PID: 1049 at 
> > /home/rmk/git/linux-rmk/drivers/gpu/drm/drm_atomic_helper.c:1149 
> > drm_atomic_helper_wait_for_vblanks+0x218/0x224
> > [CRTC:29] vblank wait timed out
> 
> Can someone please explain to me how you go from something like
> "[CRTC:29]" to something meaningful, such as identifying which
> exact CRTC failed here?
> 
> Given that the ID numbers given out by DRM for individual components
> come from the dev->mode_config.crtc_idr IDR, without knowing in
> exact detail the precise registration order of these objects with
> drm_mode_object_get(), printing "[CRTC:29]" is utterly meaningless -
> it conveys zero useful information.  DRM might as well be printing
> random numbers instead.
> 
> At least the pre-atomic DRM code printed crtc->name as well, which
> would at least indicate which _CRTC_ in numeric order of registration
> was the cause, which is slightly easier to guess which hardware CRTC
> in question caused the problem.
> 
> Some consistency in DRM land would be nice...

Eventually, we get:

WARNING: CPU: 1 PID: 1049 at 
/home/rmk/git/linux-rmk/drivers/gpu/drm/drm_atomic_helper.c:1151 
drm_atomic_helper_wait_for_vblanks+0x220/0x22c
[CRTC:26:crtc-0] vblank wait timed out

which is the "crtc" providing the HDMI output, and there is no HDMI
output anymore.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: imxdrm issue on SABRE Lite

[Russell King - ARM Linux]

On Sat, Feb 11, 2017 at 09:09:34PM +, Dan MacDonald wrote:
> [   43.997066] [drm:drm_atomic_helper_commit_cleanup_done] *ERROR*
> [CRTC:24:crtc-0] flip_done timed out
> [   55.517063] [drm:drm_atomic_helper_commit_cleanup_done] *ERROR*
> [CRTC:24:crtc-0] flip_done timed out

This seems to lay the foundation for the kernel to Oops itself later.
The problem seems to be this:

drm_atomic_helper_commit(state->dev, state, false)
- drm_atomic_helper_setup_commit(state, false)
  - foreach crtc in state
- commit->event = kzalloc()
- crtc_state->event = commit->event
- crtc_state->event->base.completion = &commit->flip_done
...
- commit_tail(state)
  - funcs->atomic_commit_tail(state)
...
- drm_atomic_helper_commit_planes(dev, state,
DRM_PLANE_COMMIT_ACTIVE_ONLY |

DRM_PLANE_COMMIT_NO_DISABLE_AFTER_MODES$  - foreach active crtc in state
- funcs->atomic_begin(crtc, old_crtc_state)
  - ipu_crtc_atomic_begin()
- drm_crtc_vblank_on()
- if crtc->state->event
  - drm_crtc_arm_vblank_event(crtc, crtc->state->event)
  - crtc->state->event = NULL

At this point, the "commit->flip_done" completion is queued with the
event onto the vblank list.
...
  - drm_atomic_helper_commit_cleanup_done(state)
- foreach crtc in state
  - try_wait_for_completion(&commit->hw_done)
  - wait_for_completion_timeout(&commit->flip_done, 10sec)

This is where we get the timeout message.

  - drm_atomic_state_free(state)

This "clears" the commit state (calling drm_crtc_commit_put() on it)
which has the effect of kfree()'ing the structure containing the
flip_done, but which is still on the vblank list.

The next time we try to set a mode, the result is that a call to
drm_crtc_vblank_off() causes all queued events to be sent, including
the now kfree()'d flip_done completion, resulting in the reported
kernel oops.

It seems others are also suffering similar issues when the flip_done
completion times out with other drivers:

https://lkml.org/lkml/2016/12/1/171
https://bugs.freedesktop.org/show_bug.cgi?id=96781
https://lists.opensuse.org/opensuse-bugs/2016-10/msg03011.html
https://patchwork.kernel.org/patch/9280223/ (which is me...)

This is likely the same, although the timeout line was not captured:
https://bugzilla.redhat.com/show_bug.cgi?id=1415180
https://bodhi.fedoraproject.org/updates/kernel-4.8.7-200.fc24

So, can we please avoid killing the kernel when the hardware doesn't
quite behave as we want it to?

Right now, when we oops the kernel, we're leaking all the memory
associated with the atomic modeset, so if we stop oopsing the kernel
but still leak the memory, surely that would be an improvement?
Maybe something like the untested patch at the bottom of this mail?

It would give the opportunity to poke about on a failed system to
work out what happened and maybe why the hardware misbehaved.

The real answer is for the hardware to behave, but we can't always
have our cake.

Note - I can't reproduce Dan's problem here on 4.10-rc7 as I suspect
it needs multiple CRTCs/outputs running in the IPU to trigger it,
which Sabre lite has.  I'll try enabling the (disconnected) LVDS
output tomorrow (I have Fabio's LVDS patch knocking about), but I
suspect those with a deeper knowledge of the IPU need to investigate
what's going on.

> [  214.765689] imx-ipuv3 240.ipu: DC stop timeout after 50 ms
> [  214.825688] Unable to handle kernel NULL pointer dereference at
> virtual address 
> [  214.833783] pgd = ed1b8000
> [  214.836491] [] *pgd=4c974831
> [  214.840084] Internal error: Oops: 17 [#1] SMP ARM
> [  214.844789] Modules linked in: mousedev snd_soc_sgtl5000
> snd_soc_fsl_ssi snd_soc_imx_sgtl5000 imx_pcm_fiq imx_pcm_dma
> snd_soc_fsl_asrc snd_soc_fsl_asoc_card snd_soc_core dw_hdmi_ahb_audio
> snd_pcm_dmaengine caam_jr imx_ipuv3_crtc snd_ac97_codec coda
> v4l2_mem2mem videobuf2_dma_contig ac97_bus imx_ipu_v3
> snd_soc_imx_audmux snd_pcm videobuf2_vmalloc videobuf2_memops
> videobuf2_v4l2 videobuf2_core dw_hdmi_imx caam imx2_wdt ofpart spi_imx
> evdev dw_hdmi etnaviv imx_ldb pwm_imx snd_timer parallel_display
> uio_pdrv_genirq uio imxdrm sch_fq_codel ip_tables x_tables
> [  214.894338] CPU: 2 PID: 316 Comm: Xorg Tainted: GW
> 4.9.8-1-ARCH #1
> [  214.901735] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
> [  214.908264] task: ed2c4d00 task.stack: ed2a6000
> [  214.912803] PC is at __wake_up_common+0x1c/0x80
> [  214.917337] LR is at __wake_up_locked+0x14/0x1c
> [  214.921871] pc : []lr : []psr: a0070093
> [  214.921871] sp : ed2a7c68  ip :   fp : c0fa2a70
> [  214.933348] r10: c0f37384  r9 : 0003  r8 : 
> [  214.938574] r7 :   r6 : edbf3410  r5 : edbf3408  r4 : edbf340c
> [  214.945101] r3 :   r2 :   r1 :   r0 : edbf340c
> [  214.951630] Flags: NzCv  IRQs off  FIQs on  Mode SVC_3

[Bug 99780] Flickering artifacts in radeonsi driver with divergent texture reads.

[bugzilla-daemon]

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

--- Comment #9 from Matias N. Goldberg  ---
Thanks for the referral.

I commented there, and they replied back with a potential fix:

> I believe it is very easy to fix, no need to change LLVM: marking the texture 
> operation as having unknown side-effect should be enough.

Any comments? (perhaps you already know this but the performance hit could be
huge?)

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 97362] Low performance after suspend on RX 480

[bugzilla-daemon]

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

--- Comment #4 from Gašper Sedej  ---
The issue is still present. After resume, I can make GPU to max MHz, but the
memory stays at 300MHz.

Ubuntu 16.04 + kernek 4.10rc7 + oibaf ppa (mesa git)

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 98869] Electronic Super Joy graphic artefacts (regression,bisected)

[bugzilla-daemon]

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

--- Comment #21 from cosiek...@o2.pl ---
Can you explain this bug and patch to my? :) What now?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99275] Kernel 4.9: amdgpu regression; gui flickers; amd radeon rx 460

[bugzilla-daemon]

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

--- Comment #24 from Reimar Imhof  ---
I forgot to mention: When running the 4.8 kernel with high cpu load (about
100%) (for example building a kernel) the 4.8 kernel also produces flickering
and shows artifacts from the background when re-sizing a window.
But the 4.9 kernel shows this bug even with very low cpu load when the machine
is idle (see comment#5).

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99780] Flickering artifacts in radeonsi driver with divergent texture reads.

[bugzilla-daemon]

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

--- Comment #8 from Bas Nieuwenhuizen  ---
I think this is the issue described in 

https://reviews.llvm.org/D26348

Not idea when the fix is going to go through though.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99542] vdpau logging errors since gallium/radeon: adjust the rule for using the LINEAR_ALIGNED layout

[bugzilla-daemon]

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

--- Comment #8 from Kai  ---
(In reply to Marek Olšák from comment #7)
> It's a bug in mpv. It calls vlVdpOutputSurfacePutBitsNative with a zero-area
> destination_rect.
> 
> I'm really glad I haven't reverted the Mesa commit. The workaround is on
> mesa-dev:
> "vdpau: skip vlVdpOutputSurfacePutBitsNative with a zero-area rectangle"

I can confirm, that the patch on the mailing list suppresses these errors as
well.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99780] Flickering artifacts in radeonsi driver with divergent texture reads.

[bugzilla-daemon]

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

--- Comment #7 from Matias N. Goldberg  ---
Analyzing the ASM it's clear what's happening: the 3.9.1 version branches
everything.
The 4.0 version branches the calculations, then at the end uses readfirstlane
(this is WRONG) and finally performs one sample.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99782] Driver lockup using dolphin in specific areas

[bugzilla-daemon]

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

Bug ID: 99782
   Summary: Driver lockup using dolphin in specific areas
   Product: Mesa
   Version: git
  Hardware: Other
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: radeon.20.mathi...@dfgh.net
QA Contact: dri-devel@lists.freedesktop.org

Created attachment 129537
  --> https://bugs.freedesktop.org/attachment.cgi?id=129537&action=edit
Dolphin FIFO log that triggers the lockup

Using my RX 470 card and mesa, my video driver locks up in specific parts of a
game (Fire Emblem: Radiant Dawn) using the Dolphin emulator.

I can still interact with the system using ssh, but the screen stays frozen at
the exact moment and stays unresponsive until reboot (trying to kill dolphin
leads to a zombie).

I tried with all stable mesa versions between 13.0 and 13.0.4, and a fairly
recent git version (3f064e9a40), and I can reproduce the lockup every time.

I attached a dolphin fifo log which triggers the bug and can be run without
owning the game.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 97879] [amdgpu] Rocket League: long hangs (several seconds) when loading assets (models/textures/shaders?)

[bugzilla-daemon]

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

--- Comment #82 from Timothee Besset  ---
Thanks Marek. The game has been updated to use a malloc and memcpy, this fix
will have rolled out to everyone by now.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99628] AMD Radeon HD 8600M graphics card doesn't work with amdgpu

[bugzilla-daemon]

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

--- Comment #14 from mohsen2120habibik...@gmail.com ---
Now everything works. this bug report could be closed if the second patch of
Alex lands in linux kernel.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99780] Flickering artifacts in radeonsi driver with divergent texture reads.

[bugzilla-daemon]

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

--- Comment #6 from Matias N. Goldberg  ---
Created attachment 129536
  --> https://bugs.freedesktop.org/attachment.cgi?id=129536&action=edit
ASM from 3.9.1

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99275] Kernel 4.9: amdgpu regression; gui flickers; amd radeon rx 460

[bugzilla-daemon]

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

--- Comment #23 from Reimar Imhof  ---
After freedektop-drm-next-4.9-wip was ok, I build some pre 4.9 kernels:
(repository: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git)

7af8a0f8088831428051976cb06cc1e450f8bab5
Merge tag 'arm64-upstream' of
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
--> ok

d7a0dab82fef61bebd34f2bbb9314b075153b646
Merge branch 'core-smp-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
--> ok

e606d81d2d9596ab2b4fd0dc052eea0485b7e8c2
Merge branch 'ras-core-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
--> ok

af79ad2b1f337a00aa150b993635b10bc68dc842
Merge branch 'sched-core-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
--> bug, flickers

So af79ad2b1f337a00aa150b993635b10bc68dc842 turns out to be the first buggy
commit.
Pull scheduler changes from Ingo Molnar:
 "The main changes are:

   - irqtime accounting cleanups and enhancements. (Frederic Weisbecker)

   - schedstat debugging enhancements, make it more broadly runtime
 available. (Josh Poimboeuf)

   - More work on asymmetric topology/capacity scheduling. (Morten
 Rasmussen)

   - sched/wait fixes and cleanups. (Oleg Nesterov)

   - PELT (per entity load tracking) improvements. (Peter Zijlstra)

   - Rewrite and enhance select_idle_siblings(). (Peter Zijlstra)

   - sched/numa enhancements/fixes (Rik van Riel)

   - sched/cputime scalability improvements (Stanislaw Gruszka)

   - Load calculation arithmetics fixes. (Dietmar Eggemann)

   - sched/deadline enhancements (Tommaso Cucinotta)

   - Fix utilization accounting when switching to the SCHED_NORMAL
 policy. (Vincent Guittot)

   - ... plus misc cleanups and enhancements"

Do these scheduler changes somehow break amdgpu?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99780] Flickering artifacts in radeonsi driver with divergent texture reads.

[bugzilla-daemon]

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

--- Comment #5 from Matias N. Goldberg  ---
Created attachment 129535
  --> https://bugs.freedesktop.org/attachment.cgi?id=129535&action=edit
ASM 4.0

Those readfirstlane instructions are incredibly suspicious

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99780] Flickering artifacts in radeonsi driver with divergent texture reads.

[bugzilla-daemon]

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

--- Comment #4 from Matias N. Goldberg  ---
Created attachment 129534
  --> https://bugs.freedesktop.org/attachment.cgi?id=129534&action=edit
IR Generated by LLVM 4.0

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99780] Flickering artifacts in radeonsi driver with divergent texture reads.

[bugzilla-daemon]

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

--- Comment #3 from Matias N. Goldberg  ---
Created attachment 129533
  --> https://bugs.freedesktop.org/attachment.cgi?id=129533&action=edit
IR Generated by LLVM 3.9.1

Took me a while to find the IR out of all the noise.

You should consider adding a Mesa extension to give human-readable names to
shaders. It would help everyone in debugging A LOT.

I don't mind having
glSetNameMESA( shaderId, "My Filename" );
and internally Mesa keeps a std::map or similar.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 194561] New: [drm:atom_op_jump [radeon]] *ERROR* atombios stuck in loop for more than 5secs (blank screen happens after launching directx app through wine)

[bugzilla-daemon]

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

Bug ID: 194561
   Summary: [drm:atom_op_jump [radeon]] *ERROR* atombios stuck in
loop for more than 5secs (blank screen happens after
launching directx app through wine)
   Product: Drivers
   Version: 2.5
Kernel Version: 4.8.0-36-generic #36~16.04.1-Ubuntu SMP Sun Feb 5
09:39:57 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
  Hardware: x86-64
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-...@kernel-bugs.osdl.org
  Reporter: m...@azazar.com
Regression: No

Created attachment 254711
  --> https://bugzilla.kernel.org/attachment.cgi?id=254711&action=edit
dmesg output

When I'm launching any DirectX app through wine, blank screen happens.
Restaring lightdm through ssh after some time helps to recover.

$ uname -a
Linux a.azazar.com 4.8.0-36-generic #36~16.04.1-Ubuntu SMP Sun Feb 5 09:39:57
UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

dmesg output right after launching wine app:

[   90.848821] [drm:atom_op_jump [radeon]] *ERROR* atombios stuck in loop for
more than 5secs aborting
[   90.848833] [drm:atom_execute_table_locked [radeon]] *ERROR* atombios stuck
executing D33C (len 62, WS 0, PS 0) @ 0xD358
[   95.852246] [drm:atom_op_jump [radeon]] *ERROR* atombios stuck in loop for
more than 5secs aborting
[   95.852258] [drm:atom_execute_table_locked [radeon]] *ERROR* atombios stuck
executing D33C (len 62, WS 0, PS 0) @ 0xD358
[   95.852267] [drm:atom_execute_table_locked [radeon]] *ERROR* atombios stuck
executing C654 (len 1318, WS 0, PS 0) @ 0xC721

# lspci | grep Radeon
02:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
Pitcairn XT [Radeon HD 7870 GHz Edition]
02:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Cape
Verde/Pitcairn HDMI Audio [Radeon HD 7700/7800 Series]

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99275] Kernel 4.9: amdgpu regression; gui flickers; amd radeon rx 460

[bugzilla-daemon]

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

--- Comment #22 from Reimar Imhof  ---
I also tried to build a 4.8 kernel with 4.9 drm:
git clone -b drm-next-4.9-wip git://people.freedesktop.org/~agd5f/linux
freedektop-drm-next-4.9-wip
cd freedektop-drm-next-4.9-wip
make rpm

That kernel showed no problems.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99275] Kernel 4.9: amdgpu regression; gui flickers; amd radeon rx 460

[bugzilla-daemon]

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

--- Comment #21 from Reimar Imhof  ---
at
https://bugzilla.kernel.org/show_bug.cgi?id=193651#c8
I found the hint about drm-next-4.11-wip.
I build that kernel but still had the same bug.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 194559] amdgpu problems loading 2 firmwares on multi-smp system

[bugzilla-daemon]

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

Janpieter Sollie (janpieter.sol...@dommel.be) changed:

   What|Removed |Added

 Kernel Version|4.4.9   |4.9.9

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH RESEND 1/1] media: platform: Renesas IMR driver

[Laurent Pinchart]

Hi Sergei,

(CC'ing the dri-evel mailing list)

Thank you for the patch.

On Saturday 11 Feb 2017 23:02:01 Sergei Shtylyov wrote:
> From: Konstantin Kozhevnikov 
> 
> The image renderer light extended 4 (IMR-LX4) or the distortion correction
> engine is a drawing processor with a simple  instruction system capable of
> referencing data on an external memory as 2D texture data and performing
> texture mapping and drawing with respect to any shape that is split into
> triangular objects.
> 
> This V4L2 memory-to-memory device driver only supports image renderer found
> in the R-Car gen3 SoCs; the R-Car gen2 support  can be added later...

Let's start with the main question : given that this is a rendering engine, it 
looks like it should use the DRM subsystem.

> [Sergei: merged 2 original patches, added the patch description, removed
> unrelated parts,  added the binding document, ported the driver to the
> modern kernel, renamed the UAPI header file and the guard  macros to match
> the driver name, extended the copyrights, fixed up Kconfig prompt/depends/
> help, made use of the BIT()/GENMASK() macros, sorted #include's, removed
> leading  dots and fixed grammar in the comments, fixed up indentation to
> use tabs where possible, renamed IMR_DLSR to IMR_DLPR to match the manual,
> separated the register offset/bit #define's, removed *inline* from .c file,
> fixed lines over 80 columns, removed useless parens, operators, casts,
> braces, variables, #include's, (commented out) statements, and even
> function, inserted empty line after desclaration, removed extra empty
> lines, reordered some local variable desclarations, removed calls to
> 4l2_err() on kmalloc() failure, fixed the error returned by imr_default(),
> avoided code duplication in the IRQ handler, used '__packed' for the UAPI
> structures, enclosed the macro parameters in parens, exchanged the values
> of IMR_MAP_AUTO[SD]G macros.]
> 
> Signed-off-by: Konstantin Kozhevnikov
>  Signed-off-by: Sergei Shtylyov
> 
> 
> ---
> This patch is against the 'media_tree.git' repo's 'master' branch.
> 
>  Documentation/devicetree/bindings/media/rcar_imr.txt |   23
>  drivers/media/platform/Kconfig   |   13
>  drivers/media/platform/Makefile  |1
>  drivers/media/platform/rcar_imr.c| 1923 +++
>  include/uapi/linux/rcar_imr.h|   94
>  5 files changed, 2054 insertions(+)

-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99780] Flickering artifacts in radeonsi driver with divergent texture reads.

[bugzilla-daemon]

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

--- Comment #2 from Matias N. Goldberg  ---
Created attachment 129532
  --> https://bugs.freedesktop.org/attachment.cgi?id=129532&action=edit
Vertex Shader used to receive these shadows (already stripped down & with tint)

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99780] Flickering artifacts in radeonsi driver with divergent texture reads.

[bugzilla-daemon]

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

--- Comment #1 from Matias N. Goldberg  ---
Created attachment 129531
  --> https://bugs.freedesktop.org/attachment.cgi?id=129531&action=edit
Pixel Shader used to receive these shadows (already stripped down & with tint)

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99780] Flickering artifacts in radeonsi driver with divergent texture reads.

[bugzilla-daemon]

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

Bug ID: 99780
   Summary: Flickering artifacts in radeonsi driver with divergent
texture reads.
   Product: Mesa
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: dark_syl...@yahoo.com.ar
QA Contact: dri-devel@lists.freedesktop.org

Created attachment 129530
  --> https://bugs.freedesktop.org/attachment.cgi?id=129530&action=edit
Sample repro

I'm an Ogre3D developer.

We noticed after updating to LLVM 4.0 that there were visual glitches:
http://imgur.com/43tIuI6
http://imgur.com/iBhxoBj
(this glitches tend to flicker over time *even if everything is stationary*)
This bug is *NOT* present if using LLVM 3.9.1
This bug happens with radeon open source drivers. Using llvmpipe works as
intended.

I tried to reproduce this bug in a clean environment but failed. So instead I
stripped down as much as possible to a minimal repro sample out of our code;
which I am attaching.

We noticed that this flicker happens alongside the difference between the PSSM
splits, but not always:
http://imgur.com/130B4mE
We added a tint to differentiate the splits. But as you can see there are a few
artifacts that happens within one tint; though the vast majority of the
artifacts happens alongside the line.

A PSSM split in shader code means this:
uniform sampler2DShadow texShadowMap[2];
float fShadow = 1.0;
vec3 tint = vec3( 1, 1, 1 );
if( inPs.depth <= pass.pssmSplitPoints0 )
{
fShadow = getShadow( texShadowMap[0], inPs.posL0, vec4( 0.000488281,
0.000488281, 1, 1 ) );
tint = vec3( 0.0, 0, 1 );
}
else if( inPs.depth <= pass.pssmSplitPoints1 )
{
fShadow = getShadow( texShadowMap[1], inPs.posL1, vec4( 0.000976562,
0.000976562, 1, 1 ) );
tint = vec3(0.0, 1.0, 0.0 );
}

Everything from inPs comes from the vertex shader.

After stripping down as much as possible, our getShadow declaration is this:
float getShadow( sampler2DShadow shadowMap, vec4 psPosLN, vec4 invShadowMapSize
)
{
float fDepth = psPosLN.z;
vec2 uv = psPosLN.xy / psPosLN.w;

float retVal = 0;

vec2 fW;
vec4 c;

retVal += texture( shadowMap, vec3( uv, fDepth ) ).r;

return retVal;
}


I've seen a similar artifact before in the Windows AMD drivers back when I was
experimenting with bindless textures and I purposedly managed to mix textures
from divergent branches into the same wavefront. Not sure if that's what's
happening here though.

Just run launchapp.sh; select OpenGL renderer, and click accept. It will launch
the sample.

NOTE: If when running the sample you encounter this problem:
Created GL 4.3 context
libGL error: failed to create drawable
libGL error: failed to create drawable
X Error of failed request:  0
  Major opcode of failed request:  156 (GLX)
  Minor opcode of failed request:  26 (X_GLXMakeContextCurrent)
  Serial number of failed request:  28
  Current serial number in output stream:  28

The just run it again. I do not know why this happens, it happens rarely (like
1 in 10 runs) and I haven't yet been able to determine why. It sounds like a
race condition inside Mesa (because the bug won't manifest while debugging
where loading is significantly slowed down loading all symbols), but I don't
have enough evidence to back this up, and it's not the reason of this bug
ticket. 

If you have more issues running the sample let me know, I can provide
assistance. This sample needs SDL2 to be installed in your system.

I'm using AMD Radeon HD 7770 1GB
Ubuntu 16.10
Mesa git 5bc222ebafddd14f2329f5096287b51d798a6431
LLVM 4.0 SVN 293947
Kernel 4.8.0-37-generic

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 2/7] drm/tinydrm: Add helper functions

[Noralf Trønnes]

Den 12.02.2017 12.50, skrev Andy Shevchenko:

On Sat, Feb 11, 2017 at 8:48 PM, Noralf Trønnes  wrote:

Add common functionality needed by many tinydrm drivers.
+int tinydrm_enable_backlight(struct backlight_device *backlight)
+{
+   unsigned int old_state;
+   int ret;
+
+   if (!backlight)
+   return 0;
+
+   old_state = backlight->props.state;
+   backlight->props.state &= ~BL_CORE_FBBLANK;
+   DRM_DEBUG_KMS("Backlight state: 0x%x -> 0x%x\n", old_state,
+ backlight->props.state);

"%#x" ?
(And elsewhere)


+#if IS_ENABLED(CONFIG_SPI)
+size_t tinydrm_spi_max_transfer_size(struct spi_device *spi, size_t max_len)
+{
+   size_t ret;
+
+   ret = min(spi_max_transfer_size(spi), spi->master->max_dma_len);

I don't get why DMA constrain somehow affects this framework?


The reason is that spi-bcm2835 reverts to PIO on larger buffers.
Looking at __spi_map_msg() and spi_map_buf() it becomes clear that the
core breaks up the buffer into manageable parts. So this must be a bug
in spi-bcm2835 (and spi-pxa2xx) since no other drivers have a upper
limit in the .can_dma() callback.
So you're rightly confused, with drivers fixed, this limit can be lifted.


What if max_dma_len is zero (imagine SPI master that works only by PIO
by some reason)?


It can't be zero:

int spi_register_master(struct spi_master *master)
{
...
if (!master->max_dma_len)
master->max_dma_len = INT_MAX;


+   if (max_len)
+   ret = min(ret, max_len);
+   if (spi_max)
+   ret = min_t(size_t, ret, spi_max);
+   ret &= ~0x3;

Why alignment is that? Why do we need it? Isn't a busyness of SPI
framework to cope with it?


This minimum capping doesn't look good. I should probably put >16
instead, that would cover the minimum for the 9-bit emulation code.

The reason I let the user change the transfer size, is that some usb
audio card on Raspberry Pi stuttered with 4k fbtft transfers.


+   if (ret < 4)

It's effectively check for 0.


+   ret = 4;
+
+   return ret;
+}
+EXPORT_SYMBOL(tinydrm_spi_max_transfer_size);
+static void
+tinydrm_dbg_spi_print(struct spi_device *spi, struct spi_transfer *tr,
+ const void *buf, int idx, bool tx)
+{
+   u32 speed_hz = tr->speed_hz ? tr->speed_hz : spi->max_speed_hz;
+   char linebuf[3 * 32];
+
+   hex_dump_to_buffer(buf, tr->len, 16,
+  DIV_ROUND_UP(tr->bits_per_word, 8),
+  linebuf, sizeof(linebuf), false);
+
+   printk(KERN_DEBUG
+  "tr(%i): speed=%u%s, bpw=%i, len=%u, %s_buf=[%s%s]\n", idx,
+  speed_hz > 100 ? speed_hz / 100 : speed_hz / 1000,
+  speed_hz > 100 ? "MHz" : "kHz", tr->bits_per_word, tr->len,
+  tx ? "tx" : "rx", linebuf, tr->len > 16 ? " ..." : "");

I hope at some point we will have some extension to print speeds,
sizes and so on based on algo in string_get_size().


+}
+int tinydrm_spi_transfer(struct spi_device *spi, u32 speed_hz,
+struct spi_transfer *header, u8 bpw, const void *buf,
+size_t len)
+{
+   struct spi_transfer tr = {
+   .bits_per_word = bpw,
+   .speed_hz = speed_hz,
+   };
+   struct spi_message m;
+   u16 *swap_buf = NULL;
+   size_t max_chunk;
+   size_t chunk;
+   int ret = 0;
+
+   if (WARN_ON_ONCE(bpw != 8 && bpw != 16))
+   return -EINVAL;
+
+   max_chunk = tinydrm_spi_max_transfer_size(spi, 0);
+
+   if (drm_debug & DRM_UT_DRIVER)
+   pr_debug("[drm:%s] bpw=%u, max_chunk=%zu, transfers:\n",
+__func__, bpw, max_chunk);

For all of your dev_dbg() / pr_debug() __func__ argument might be
redundant. Dynamic Debug may include this by request from user.


+/**
+ * tinydrm_machine_little_endian - Machine is little endian
+ *
+ * Returns:
+ * true if *defined(__LITTLE_ENDIAN)*, false otherwise
+ */
+static inline bool tinydrm_machine_little_endian(void)
+{
+#if defined(__LITTLE_ENDIAN)
+   return true;
+#else
+   return false;
+#endif
+}

Hmm... What is the typical code of a caller for this?


If the bus can't do 16-bit natively, it will have to swap the bytes on
little endian machines before transfer as 8-bit (Raspberry Pi can't do
16-bit SPI with it's DMA capable controller).
So this function is to avoid #ifdef's elsewhere.

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 97879] [amdgpu] Rocket League: long hangs (several seconds) when loading assets (models/textures/shaders?)

[bugzilla-daemon]

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

--- Comment #81 from Marek Olšák  ---
I merged a different patch that just improves GL_MAP_READ_BIT and returns a
mapping with CPU caches enabled, with the downside that it does a copy from the
uncached buffer into a cached temporary buffer, maps that, and if
GL_MAP_WRITE_BIT is set, the temporary buffer is copied into the original
buffer on unmap.

The reason GPU drivers prefer uncached allocations is that the GPU access to
the buffer is faster while the CPU access is slower (except for sequential
writes). If we enabled caching, the GPU access would be slower, but the CPU
access would be faster. Or we could have 2 buffers and do copying back and
forth like for GL_MAP_READ_BIT, but again the copy also isn't free and it's
worse if you have to do 2 copies - one in Map and the other in Unmap.

The malloc + memcpy solution on the app side is probably the best one.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99542] vdpau logging errors since gallium/radeon: adjust the rule for using the LINEAR_ALIGNED layout

[bugzilla-daemon]

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

--- Comment #7 from Marek Olšák  ---
It's a bug in mpv. It calls vlVdpOutputSurfacePutBitsNative with a zero-area
destination_rect.

I'm really glad I haven't reverted the Mesa commit. The workaround is on
mesa-dev:
"vdpau: skip vlVdpOutputSurfacePutBitsNative with a zero-area rectangle"

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99748] [radeonsi] Civ6 Assert in LLVM SIMachineScheduler.cpp with R600_DEBUG=sisched

[bugzilla-daemon]

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

--- Comment #2 from Mike Lothian  ---
Created attachment 129529
  --> https://bugs.freedesktop.org/attachment.cgi?id=129529&action=edit
Revert Patch

Here's the revert patch to make things easier for other folk reverting

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99779] Lenovo Thinkpad E450 (Kaveri A6-7000 Radeon R4) Blank Screen after suspend (displayport link issues)

[bugzilla-daemon]

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

--- Comment #1 from Kyle Brooks  ---
Created attachment 129528
  --> https://bugs.freedesktop.org/attachment.cgi?id=129528&action=edit
Xorg log

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99779] Lenovo Thinkpad E450 (Kaveri A6-7000 Radeon R4) Blank Screen after suspend (displayport link issues)

[bugzilla-daemon]

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

Bug ID: 99779
   Summary: Lenovo Thinkpad E450 (Kaveri A6-7000 Radeon R4) Blank
Screen after suspend (displayport link issues)
   Product: DRI
   Version: XOrg git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: critical
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: brook...@gmail.com

Created attachment 129527
  --> https://bugs.freedesktop.org/attachment.cgi?id=129527&action=edit
dmesg 4.9.8

If I shut my laptop lit it suspends, then when opening the lid and resuming I
get a blank screen and am unable to get the display to work again unless I
reboot.  I can ssh into computer and I get displayport link errors in the
attached dmesg log.

This issue does not occur if I use the radeon kernel module instead of amdgpu.

This seems very similar to bug 90320 but I filed this one because it is amdgpu
not radeon:
https://bugs.freedesktop.org/show_bug.cgi?id=90320

I've also attached the Xorg.0.log but it does not have any errors indicated. 
It indicates successful exit because I stopped the server over ssh and tried to
restart gdm a few times which is why there are multiple displayport link status
failed messages in dmesg.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 194559] New: amdgpu problems loading 2 firmwares on multi-smp system

[bugzilla-daemon]

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

Bug ID: 194559
   Summary: amdgpu problems loading 2 firmwares on multi-smp
system
   Product: Drivers
   Version: 2.5
Kernel Version: 4.4.9
  Hardware: x86-64
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-...@kernel-bugs.osdl.org
  Reporter: janpieter.sol...@dommel.be
Regression: No

Created attachment 254705
  --> https://bugzilla.kernel.org/attachment.cgi?id=254705&action=edit
dmesg.txt, lspci.txt and .config

System: opteron 2876 (*2), 128GB ram, x86_64.
VGA1: SI, cape verde pro.
VGA2: R9 nano.
VGA3: onboard mgag200.
Distribution: gentoo.
kernel: vanilla-sources-4.9.9.
kernel loader: lilo 24
firmware: linux-firmware-20170126.
bug: amdgpu loading on the system causes a reboot. even when disabling panic,
the kernel does not wait for me to reset the system. the issue occurs even when
booting the system with init=/bin/bash and then modprobe amdgpu.
solutions:
1) removing /lib/firmware/radeon.
2) removing /lib/firmware/amdgpu.
3) boot the kernel with nosmp.
Each of these solutions works, but causes hardware not to be initialized
Tried without success:
1) using the radeon module instead of amdgpu.
2) using amdgpu-pro.
3) using a different kernel version (4.4.39).
4) boot with iommu=soft.
5) first load drm (works), then load amdgpu (crashes).

I suspect a nonsafe threaded kernel bug in drm.

In attachment:
1) dmesg of noSMP boot.
2) lspci output.
3) config of current 4.9.9 kernel.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 1/7] drm: Add DRM support for tiny LCD displays

[Noralf Trønnes]

Den 12.02.2017 12.05, skrev Andy Shevchenko:

On Sat, Feb 11, 2017 at 8:48 PM, Noralf Trønnes  wrote:

tinydrm provides helpers for very simple displays that can use
CMA backed framebuffers and need flushing on changes.
+/**
+ * tinydrm_gem_cma_free_object - Free resources associated with a CMA GEM
+ *   object

Keep on one line?


That means 81 columns and checkpatch complaint.
This in one of the annoying things about Linux
kernel coding. Always trying
to avoid
breaking up lines.
Because for me it hinders redability.


+const struct file_operations tinydrm_fops = {
+   .owner  = THIS_MODULE,

Do we still need this?


Looks like it, see drm_stub_open()


+static int tinydrm_init(struct device *parent, struct tinydrm_device *tdev,
+   const struct drm_framebuffer_funcs *fb_funcs,
+   struct drm_driver *driver)
+{
+   struct drm_device *drm;
+
+   mutex_init(&tdev->dirty_lock);
+   tdev->fb_funcs = fb_funcs;
+
+   /*
+* We don't embed drm_device, because that prevent us from using
+* devm_kzalloc() to allocate tinydrm_device in the driver since
+* drm_dev_unref() frees the structure. The devm_ functions provide

"devm_ functions" -> "devm_kzalloc()" ?

Otherwise what else do you refer to and why here?


yes, that last sentence can be dropped.


+* for easy error handling.
+*/
+static int tinydrm_register(struct tinydrm_device *tdev)
+{
+   struct drm_device *drm = tdev->drm;
+   int bpp = drm->mode_config.preferred_depth;
+   struct drm_fbdev_cma *fbdev;
+   int ret;
+
+   ret = drm_dev_register(tdev->drm, 0);
+   if (ret)
+   return ret;
+
+   fbdev = drm_fbdev_cma_init_with_funcs(drm, bpp ? bpp : 32,
+ drm->mode_config.num_connector,
+ tdev->fb_funcs);
+   if (IS_ERR(fbdev))
+   DRM_ERROR("Failed to initialize fbdev: %ld\n", PTR_ERR(fbdev));
+   else
+   tdev->fbdev_cma = fbdev;

Apparently I missed previous round of reviews, can you just put in
short words why error is not propagated here to the caller?


A comment might have helped here:
/* fbdev is of minor importance, don't let it stop us */


+
+   return 0;
+}
+/**
+ * tinydrm_display_pipe_init - Initialize display pipe
+ * @tdev: tinydrm device
+ * @funcs: Display pipe functions
+ * @connector_type: Connector type
+ * @formats: Array of supported formats (DRM_FORMAT\_\*)

DRM_FORMAT_* ?


sphinx wants it that way.


+ * @format_count: Number of elements in @formats
+ * @mode: Supported mode
+ * @rotation: Initial @mode rotation in degrees Counter Clock Wise
+ *
+ * This function sets up a &drm_simple_display_pipe with a &drm_connector that
+ * has one fixed &drm_display_mode which is rotated according to @rotation.
+ *
+ * Returns:
+ * Zero on success, negative error code on failure.
+ */
+{
+   struct drm_device *drm = tdev->drm;
+   struct drm_display_mode *mode_copy;
+   struct drm_connector *connector;
+   int ret;
+   connector = tinydrm_connector_create(drm, mode_copy, connector_type);
+   if (IS_ERR(connector))
+   return PTR_ERR(connector);
+
+   ret = drm_simple_display_pipe_init(drm, &tdev->pipe, funcs, formats,
+  format_count, connector);
+   if (ret)
+   return ret;
+
+   return 0;

return drm_... ?


Yep.


tinydrm will be merged the way it is now, unless someone points to
something that is broken. But I collect your comments for a later
cleanup patchset. It takes a lot of effort for me as an amateur to
keeps this code up-to-date out-of-tree for months. It's not even
sure that I've hit the mark with this, so there will most likely be
changes when I start converting fbtft drivers, and I'll implement the
remaining bits and pieces as I make changes. The core of tinydrm won't
change because of unforseen fbtft quirks, but other parts might.


Noralf.


+}
+EXPORT_SYMBOL(tinydrm_display_pipe_init);


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 0/7] drm/atomic: Add accessor macros for all atomic state.

[Laurent Pinchart]

Hi Maarten,

Do you plan to post a v4 ? I have two drivers that depends on this series for 
fence support, and I'd like to get that merged in v4.12.

On Monday 16 Jan 2017 10:37:37 Maarten Lankhorst wrote:
> Fourth iteration. Instead of trying to convert all drivers straight away,
> implement all macros that are required to get state working.
> 
> Old situation:
> Use obj->state, which can refer to old or new state.
> Use drm_atomic_get_(existing_)obj_state, which can refer to new or old
> state. Use for_each_obj_in_state, which refers to new or old state.
> 
> New situation:
> 
> During atomic check:
> - Use drm_atomic_get_obj_state to add a object to the atomic state,
>   or get the new state.
> - Use drm_atomic_get_(old/new)_obj_state to peek at the new/old state,
>   without adding the object. This will return NULL if the object is
>   not part of the state. For planes and connectors the relevant crtc_state
>   is added, so this will work to get the crtc_state from obj_state->crtc
>   too, this means not having to write some error handling.
> 
> During atomic commit:
> - Do not use drm_atomic_get_obj_state, obj->state or
> drm_atomic_get_(existing_)obj_state any more, replace with
> drm_atomic_get_old/new_obj_state calls as required.
> 
> During both:
> - Use for_each_(new,old,oldnew)_obj_in_state to get the old or new state as
> needed. oldnew will be renamed to for_each_obj_in_state after all callers
> are converted to the new api.
> 
> When not doing atomic updates:
> Look at obj->state for now. I have some patches to fix this but I was asked
> to make it return a const state. This breaks a lot of users though so I
> skipped that patch in this iteration.
> 
> This series will return the correct state regardless of swapping.
> 
> Maarten Lankhorst (7):
>   drm/atomic: Add new iterators over all state, v3.
>   drm/atomic: Make add_affected_connectors look at crtc_state.
>   drm/atomic: Use new atomic iterator macros.
>   drm/atomic: Fix atomic helpers to use the new iterator macros.
>   drm/atomic: Add macros to access existing old/new state
>   drm/atomic: Convert get_existing_state callers to get_old/new_state, v2.
>   drm/blend: Use new atomic iterator macros.
> 
>  drivers/gpu/drm/drm_atomic.c |  39 ++--
>  drivers/gpu/drm/drm_atomic_helper.c  | 377 ++--
>  drivers/gpu/drm/drm_blend.c  |  23 +--
>  drivers/gpu/drm/i915/intel_display.c |  13 +-
>  include/drm/drm_atomic.h | 180 -
>  include/drm/drm_atomic_helper.h  |   2 +
>  6 files changed, 438 insertions(+), 196 deletions(-)

-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/3] drm: rcar-du: Clear handled event pointer in CRTC state

[Laurent Pinchart]

The atomic commit helper requires drivers to clear the event pointer
stored in the CRTC state when the event is handled. In preparation to
using the helper, fix the driver.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 04046c0faffd..7391dd95c733 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -501,16 +501,16 @@ static void rcar_du_crtc_disable(struct drm_crtc *crtc)
 static void rcar_du_crtc_atomic_begin(struct drm_crtc *crtc,
  struct drm_crtc_state *old_crtc_state)
 {
-   struct drm_pending_vblank_event *event = crtc->state->event;
struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
struct drm_device *dev = rcrtc->crtc.dev;
unsigned long flags;
 
-   if (event) {
+   if (crtc->state->event) {
WARN_ON(drm_crtc_vblank_get(crtc) != 0);
 
spin_lock_irqsave(&dev->event_lock, flags);
-   rcrtc->event = event;
+   rcrtc->event = crtc->state->event;
+   crtc->state->event = NULL;
spin_unlock_irqrestore(&dev->event_lock, flags);
}
 
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/3] drm: rcar-du: Handle event when disabling CRTCs

[Laurent Pinchart]

The driver currently handles vblank events only when updating planes on
a CRTC. The atomic update API however allows requesting an event when
disabling a CRTC. This currently leads to event objects being leaked in
the kernel and to events not being sent out. Fix it.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index edcbe2e3625d..04046c0faffd 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -488,6 +488,13 @@ static void rcar_du_crtc_disable(struct drm_crtc *crtc)
rcar_du_crtc_stop(rcrtc);
rcar_du_crtc_put(rcrtc);
 
+   spin_lock_irq(&crtc->dev->event_lock);
+   if (crtc->state->event) {
+   drm_crtc_send_vblank_event(crtc, crtc->state->event);
+   crtc->state->event = NULL;
+   }
+   spin_unlock_irq(&crtc->dev->event_lock);
+
rcrtc->outputs = 0;
 }
 
-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/3] drm: rcar-du: Use DRM core's atomic commit helper

[Laurent Pinchart]

The DRM core atomic helper now supports asynchronous commits natively.
The custom rcar-du implementation isn't needed anymore, remove it.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_kms.c | 99 ---
 1 file changed, 9 insertions(+), 90 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index ff61f6032f2c..2e0b35afa69f 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -249,18 +249,9 @@ static int rcar_du_atomic_check(struct drm_device *dev,
return rcar_du_atomic_check_planes(dev, state);
 }
 
-struct rcar_du_commit {
-   struct work_struct work;
-   struct drm_device *dev;
-   struct drm_atomic_state *state;
-   u32 crtcs;
-};
-
-static void rcar_du_atomic_complete(struct rcar_du_commit *commit)
+static void rcar_du_atomic_commit_tail(struct drm_atomic_state *old_state)
 {
-   struct drm_device *dev = commit->dev;
-   struct rcar_du_device *rcdu = dev->dev_private;
-   struct drm_atomic_state *old_state = commit->state;
+   struct drm_device *dev = old_state->dev;
 
/* Apply the atomic update. */
drm_atomic_helper_commit_modeset_disables(dev, old_state);
@@ -268,98 +259,25 @@ static void rcar_du_atomic_complete(struct rcar_du_commit 
*commit)
drm_atomic_helper_commit_planes(dev, old_state,
DRM_PLANE_COMMIT_ACTIVE_ONLY);
 
+   drm_atomic_helper_commit_hw_done(old_state);
drm_atomic_helper_wait_for_vblanks(dev, old_state);
 
drm_atomic_helper_cleanup_planes(dev, old_state);
-
-   drm_atomic_state_put(old_state);
-
-   /* Complete the commit, wake up any waiter. */
-   spin_lock(&rcdu->commit.wait.lock);
-   rcdu->commit.pending &= ~commit->crtcs;
-   wake_up_all_locked(&rcdu->commit.wait);
-   spin_unlock(&rcdu->commit.wait.lock);
-
-   kfree(commit);
-}
-
-static void rcar_du_atomic_work(struct work_struct *work)
-{
-   struct rcar_du_commit *commit =
-   container_of(work, struct rcar_du_commit, work);
-
-   rcar_du_atomic_complete(commit);
-}
-
-static int rcar_du_atomic_commit(struct drm_device *dev,
-struct drm_atomic_state *state,
-bool nonblock)
-{
-   struct rcar_du_device *rcdu = dev->dev_private;
-   struct rcar_du_commit *commit;
-   struct drm_crtc *crtc;
-   struct drm_crtc_state *crtc_state;
-   unsigned int i;
-   int ret;
-
-   ret = drm_atomic_helper_prepare_planes(dev, state);
-   if (ret)
-   return ret;
-
-   /* Allocate the commit object. */
-   commit = kzalloc(sizeof(*commit), GFP_KERNEL);
-   if (commit == NULL) {
-   ret = -ENOMEM;
-   goto error;
-   }
-
-   INIT_WORK(&commit->work, rcar_du_atomic_work);
-   commit->dev = dev;
-   commit->state = state;
-
-   /* Wait until all affected CRTCs have completed previous commits and
-* mark them as pending.
-*/
-   for_each_crtc_in_state(state, crtc, crtc_state, i)
-   commit->crtcs |= drm_crtc_mask(crtc);
-
-   spin_lock(&rcdu->commit.wait.lock);
-   ret = wait_event_interruptible_locked(rcdu->commit.wait,
-   !(rcdu->commit.pending & commit->crtcs));
-   if (ret == 0)
-   rcdu->commit.pending |= commit->crtcs;
-   spin_unlock(&rcdu->commit.wait.lock);
-
-   if (ret) {
-   kfree(commit);
-   goto error;
-   }
-
-   /* Swap the state, this is the point of no return. */
-   drm_atomic_helper_swap_state(state, true);
-
-   drm_atomic_state_get(state);
-   if (nonblock)
-   schedule_work(&commit->work);
-   else
-   rcar_du_atomic_complete(commit);
-
-   return 0;
-
-error:
-   drm_atomic_helper_cleanup_planes(dev, state);
-   return ret;
 }
 
 /* 
-
  * Initialization
  */
 
+static const struct drm_mode_config_helper_funcs rcar_du_mode_config_helper = {
+   .atomic_commit_tail = rcar_du_atomic_commit_tail,
+};
+
 static const struct drm_mode_config_funcs rcar_du_mode_config_funcs = {
.fb_create = rcar_du_fb_create,
.output_poll_changed = rcar_du_output_poll_changed,
.atomic_check = rcar_du_atomic_check,
-   .atomic_commit = rcar_du_atomic_commit,
+   .atomic_commit = drm_atomic_helper_commit,
 };
 
 static int rcar_du_encoders_init_one(struct rcar_du_device *rcdu,
@@ -561,6 +479,7 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu)
dev->mode_config.max_width = 4095;
dev->mode_config.max_height = 2047;
dev->mode_config.funcs = &rcar_du_mode_config_funcs;
+   dev->mode_config.helper_private = &rcar_du_mode_config_helper;
 
rcdu->num_crtcs = 

[PATCH 0/3] rcar-du: Enable fences support using atomic commit helper

[Laurent Pinchart]

Hello,

This patch series enables fences support in the rcar-du driver through
switching to the atomic commit helper.

Patches 1/3 and 2/3 prepare the driver to handle CRTC events the way expected
by the atomic commit helper. Patch 3/3 then replaces the custom atomic commit
handler with the atomic commit helper, using a custom commit tail handler to
support the driver-specific CRTC enable/disable and plane commit order.

Patch 3/3 depends on the "[PATCH] drm: Constify drm_mode_config atomic helper
private pointer" (merged in drm-misc) for proper compilation, and on
"[PATCH v3 0/7] drm/atomic: Add accessor macros for all atomic state" (posted
to the dri-devel mailing list) for proper runtime operation of asynchronous
commits.

Laurent Pinchart (3):
  drm: rcar-du: Handle event when disabling CRTCs
  drm: rcar-du: Clear handled event pointer in CRTC state
  drm: rcar-du: Use DRM core's atomic commit helper

 drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 13 +++--
 drivers/gpu/drm/rcar-du/rcar_du_kms.c  | 99 --
 2 files changed, 19 insertions(+), 93 deletions(-)

-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/2] drm/cma-helper: Add multi buffer support for cma fbdev

[Laurent Pinchart]

Hi Maxime,

Thank you for the patch.

On Thursday 02 Feb 2017 11:31:56 Maxime Ripard wrote:
> From: Xinliang Liu 
> 
> This patch add a config to support to create multi buffer for cma fbdev.
> Such as double buffer and triple buffer.
> 
> Cma fbdev is convient to add a legency fbdev. And still many Android
> devices use fbdev now and at least double buffer is needed for these
> Android devices, so that a buffer flip can be operated. It will need
> some time for Android device vendors to abondon legency fbdev. So multi
> buffer for fbdev is needed.

How exactly do we expect Android to move away from fbdev if we add features to 
the fbdev compat layer ? I'd much rather make it clear to them that fbdev is a 
thing from the past and that they'd better migrate now.

> Signed-off-by: Xinliang Liu 
> [s.chr...@phytec.de: Picking patch from
>  https://lkml.org/lkml/2015/9/14/188]
> Signed-off-by: Stefan Christ 
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/gpu/drm/Kconfig | 8 
>  drivers/gpu/drm/drm_fb_cma_helper.c | 8 +++-
>  2 files changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index ebfe8404c25f..2ca9bb26a4e4 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -121,6 +121,14 @@ config DRM_KMS_CMA_HELPER
>   help
> Choose this if you need the KMS CMA helper functions
> 
> +config DRM_CMA_FBDEV_BUFFER_NUM
> + int "Cma Fbdev Buffer Number"
> + depends on DRM_KMS_CMA_HELPER
> + default 1
> + help
> +   Defines the buffer number of cma fbdev.  Default is one buffer.
> +   For double buffer please set to 2 and 3 for triple buffer.
> +
>  source "drivers/gpu/drm/i2c/Kconfig"
> 
>  source "drivers/gpu/drm/arm/Kconfig"
> diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
> b/drivers/gpu/drm/drm_fb_cma_helper.c index 81b3558302b5..e3f8b9e720a0
> 100644
> --- a/drivers/gpu/drm/drm_fb_cma_helper.c
> +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
> @@ -411,6 +411,12 @@ static void drm_fbdev_cma_defio_fini(struct fb_info
> *fbi) kfree(fbi->fbops);
>  }
> 
> +static int fbdev_num_buffers = CONFIG_DRM_CMA_FBDEV_BUFFER_NUM;
> +module_param(fbdev_num_buffers, int, 0444);
> +MODULE_PARM_DESC(fbdev_num_buffers,
> +  "Number of frame buffers to allocate [default="
> +  __MODULE_STRING(CONFIG_DRM_CMA_FBDEV_BUFFER_NUM) "]");
> +
>  /*
>   * For use in a (struct drm_fb_helper_funcs *)->fb_probe callback function
> that * needs custom struct drm_framebuffer_funcs, like dirty() for
> deferred_io use. @@ -437,7 +443,7 @@ int
> drm_fbdev_cma_create_with_funcs(struct drm_fb_helper *helper,
> bytes_per_pixel = DIV_ROUND_UP(sizes->surface_bpp, 8);
> 
>   mode_cmd.width = sizes->surface_width;
> - mode_cmd.height = sizes->surface_height;
> + mode_cmd.height = sizes->surface_height * fbdev_num_buffers;
>   mode_cmd.pitches[0] = sizes->surface_width * bytes_per_pixel;
>   mode_cmd.pixel_format = drm_mode_legacy_fb_format(sizes->surface_bpp,
>   sizes->surface_depth);

-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 1/7] drm/atomic: Add new iterators over all state, v3.

[Laurent Pinchart]

Hi Maarten,

Thank you for the patch.

On Monday 16 Jan 2017 10:37:38 Maarten Lankhorst wrote:
> Add for_each_(old)(new)_(plane,connector,crtc)_in_state iterators to
> replace the old for_each_xxx_in_state ones. This is useful for >1 flip
> depth and getting rid of all xxx->state dereferences.
> 
> This requires extra fixups done when committing a state after
> duplicating, which in general isn't valid but is used by suspend/resume.
> To handle these, introduce drm_atomic_helper_commit_duplicated_state
> which performs those fixups before checking & committing the state.
> 
> Changes since v1:
> - Remove nonblock parameter for commit_duplicated_state.
> Changes since v2:
> - Use commit_duplicated_state for i915 load detection.
> - Add WARN_ON(old_state != obj->state) before swapping.
> 
> Signed-off-by: Maarten Lankhorst 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/drm_atomic.c |  6 +++
>  drivers/gpu/drm/drm_atomic_helper.c  | 65 +
>  drivers/gpu/drm/i915/intel_display.c | 13 +++---
>  include/drm/drm_atomic.h | 81 +++-- 
> include/drm/drm_atomic_helper.h  |  2 +
>  5 files changed, 149 insertions(+), 18 deletions(-)

-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 1/7] drm/atomic: Add new iterators over all state, v3.

[Laurent Pinchart]

Hi Daniel,

On Monday 23 Jan 2017 09:48:54 Daniel Vetter wrote:
> On Thu, Jan 19, 2017 at 12:56:29AM +0200, Laurent Pinchart wrote:
> > On Tuesday 17 Jan 2017 08:41:03 Maarten Lankhorst wrote:
> >> Op 17-01-17 om 00:11 schreef Laurent Pinchart:
> >>> On Monday 16 Jan 2017 10:37:38 Maarten Lankhorst wrote:
>  @@ -2512,6 +2518,47 @@ struct drm_atomic_state
>  *drm_atomic_helper_suspend(struct drm_device *dev)
>  EXPORT_SYMBOL(drm_atomic_helper_suspend);
>  
>   /**
>  
>  + * drm_atomic_helper_commit_duplicated_state - commit duplicated
>  state
>  + * @state: duplicated atomic state to commit
>  + * @ctx: pointer to acquire_ctx to use for commit.
>  + *
>  + * The state returned by drm_atomic_helper_duplicate_state() and
>  + * drm_atomic_helper_suspend() is partially invalid, and needs to
>  + * be fixed up before commit.
> >>> 
> >>> Can't you fix the state in drm_atomic_helper_suspend() to avoid the
> >>> need for this function ?
> >> 
> >> We would have to fix up other areas that duplicate state too, like i915
> >> suspend and load detect. This means moving it to a helper.
> >> 
> >> It was my original approach, but Daniel preferred this approach.
> > 
> > We have to fix it somewhere, that's for sure. I think it's better to fix
> > it as close as possible to state duplication, instead of carrying a state
> > that we know is invalid and fix it at the last minute. The drawback of
> > this approach is that the window during which the state will be invalid
> > is much larger, which could cause bugs later when new code will try to
> > touch that state.
> > 
> > Daniel, is there a specific reason why you prefer this approach ?
> 
> You can't fix it in suspend? The issue is that on resume, we have reset
> states (to reflect the hw state of everything being off), so we can only
> do this on commit. That holds in general for the duplicate, do something
> nasty, restore state pattern.

Ok, I got it now. You can't fix the state up at suspend time because you need 
to set the old_state pointers to the state allocated by the .reset() handlers, 
which are called at resume time.

> And then I think a dedicated helper to commit duplicated state makes
> sense. The kernel-doc might need a bit of work to explain this better
> though. I think it should explain what exactly is partially invalid with
> duplicated states.

Yes, the documentation should be clarified, and include the above explanation 
in some form.

-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 2/7] drm/tinydrm: Add helper functions

[Andy Shevchenko]

On Sat, Feb 11, 2017 at 8:48 PM, Noralf Trønnes  wrote:
> Add common functionality needed by many tinydrm drivers.

> +int tinydrm_enable_backlight(struct backlight_device *backlight)
> +{
> +   unsigned int old_state;
> +   int ret;
> +
> +   if (!backlight)
> +   return 0;
> +
> +   old_state = backlight->props.state;
> +   backlight->props.state &= ~BL_CORE_FBBLANK;
> +   DRM_DEBUG_KMS("Backlight state: 0x%x -> 0x%x\n", old_state,
> + backlight->props.state);

"%#x" ?
(And elsewhere)

> +#if IS_ENABLED(CONFIG_SPI)

> +size_t tinydrm_spi_max_transfer_size(struct spi_device *spi, size_t max_len)
> +{
> +   size_t ret;
> +

> +   ret = min(spi_max_transfer_size(spi), spi->master->max_dma_len);

I don't get why DMA constrain somehow affects this framework?

What if max_dma_len is zero (imagine SPI master that works only by PIO
by some reason)?

> +   if (max_len)
> +   ret = min(ret, max_len);
> +   if (spi_max)
> +   ret = min_t(size_t, ret, spi_max);

> +   ret &= ~0x3;

Why alignment is that? Why do we need it? Isn't a busyness of SPI
framework to cope with it?

> +   if (ret < 4)

It's effectively check for 0.

> +   ret = 4;
> +
> +   return ret;

> +}
> +EXPORT_SYMBOL(tinydrm_spi_max_transfer_size);

> +static void
> +tinydrm_dbg_spi_print(struct spi_device *spi, struct spi_transfer *tr,
> + const void *buf, int idx, bool tx)
> +{
> +   u32 speed_hz = tr->speed_hz ? tr->speed_hz : spi->max_speed_hz;
> +   char linebuf[3 * 32];
> +

> +   hex_dump_to_buffer(buf, tr->len, 16,
> +  DIV_ROUND_UP(tr->bits_per_word, 8),
> +  linebuf, sizeof(linebuf), false);

> +
> +   printk(KERN_DEBUG
> +  "tr(%i): speed=%u%s, bpw=%i, len=%u, %s_buf=[%s%s]\n", idx,
> +  speed_hz > 100 ? speed_hz / 100 : speed_hz / 1000,
> +  speed_hz > 100 ? "MHz" : "kHz", tr->bits_per_word, tr->len,
> +  tx ? "tx" : "rx", linebuf, tr->len > 16 ? " ..." : "");

I hope at some point we will have some extension to print speeds,
sizes and so on based on algo in string_get_size().

> +}

> +int tinydrm_spi_transfer(struct spi_device *spi, u32 speed_hz,
> +struct spi_transfer *header, u8 bpw, const void *buf,
> +size_t len)
> +{
> +   struct spi_transfer tr = {
> +   .bits_per_word = bpw,
> +   .speed_hz = speed_hz,
> +   };
> +   struct spi_message m;
> +   u16 *swap_buf = NULL;
> +   size_t max_chunk;
> +   size_t chunk;
> +   int ret = 0;
> +
> +   if (WARN_ON_ONCE(bpw != 8 && bpw != 16))
> +   return -EINVAL;
> +
> +   max_chunk = tinydrm_spi_max_transfer_size(spi, 0);
> +

> +   if (drm_debug & DRM_UT_DRIVER)
> +   pr_debug("[drm:%s] bpw=%u, max_chunk=%zu, transfers:\n",
> +__func__, bpw, max_chunk);

For all of your dev_dbg() / pr_debug() __func__ argument might be
redundant. Dynamic Debug may include this by request from user.

> +/**
> + * tinydrm_machine_little_endian - Machine is little endian
> + *
> + * Returns:
> + * true if *defined(__LITTLE_ENDIAN)*, false otherwise
> + */
> +static inline bool tinydrm_machine_little_endian(void)
> +{
> +#if defined(__LITTLE_ENDIAN)
> +   return true;
> +#else
> +   return false;
> +#endif
> +}

Hmm... What is the typical code of a caller for this?

-- 
With Best Regards,
Andy Shevchenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: Constify drm_mode_config atomic helper private pointer

[Daniel Vetter]

On Mon, Jan 02, 2017 at 06:39:03PM -0200, Gabriel Krisman Bertazi wrote:
> Laurent Pinchart  writes:
> 
> > The drm_mode_config helper private field points to a structure of
> > function pointers that don't need to be modified at runtime. Make it
> > const.
> 
> Reviewed-by: Gabriel Krisman Bertazi 

Applied to drm-misc, thanks for patch&review.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 1/7] drm: Add DRM support for tiny LCD displays

[Andy Shevchenko]

On Sat, Feb 11, 2017 at 8:48 PM, Noralf Trønnes  wrote:
> tinydrm provides helpers for very simple displays that can use
> CMA backed framebuffers and need flushing on changes.

> +/**

> + * tinydrm_gem_cma_free_object - Free resources associated with a CMA GEM
> + *   object

Keep on one line?

> +const struct file_operations tinydrm_fops = {

> +   .owner  = THIS_MODULE,

Do we still need this?

> +static int tinydrm_init(struct device *parent, struct tinydrm_device *tdev,
> +   const struct drm_framebuffer_funcs *fb_funcs,
> +   struct drm_driver *driver)
> +{
> +   struct drm_device *drm;
> +
> +   mutex_init(&tdev->dirty_lock);
> +   tdev->fb_funcs = fb_funcs;
> +
> +   /*
> +* We don't embed drm_device, because that prevent us from using
> +* devm_kzalloc() to allocate tinydrm_device in the driver since

> +* drm_dev_unref() frees the structure. The devm_ functions provide

"devm_ functions" -> "devm_kzalloc()" ?

Otherwise what else do you refer to and why here?

> +* for easy error handling.
> +*/

> +static int tinydrm_register(struct tinydrm_device *tdev)
> +{
> +   struct drm_device *drm = tdev->drm;
> +   int bpp = drm->mode_config.preferred_depth;
> +   struct drm_fbdev_cma *fbdev;
> +   int ret;
> +
> +   ret = drm_dev_register(tdev->drm, 0);
> +   if (ret)
> +   return ret;
> +
> +   fbdev = drm_fbdev_cma_init_with_funcs(drm, bpp ? bpp : 32,
> + drm->mode_config.num_connector,
> + tdev->fb_funcs);

> +   if (IS_ERR(fbdev))
> +   DRM_ERROR("Failed to initialize fbdev: %ld\n", 
> PTR_ERR(fbdev));
> +   else
> +   tdev->fbdev_cma = fbdev;

Apparently I missed previous round of reviews, can you just put in
short words why error is not propagated here to the caller?

> +
> +   return 0;
> +}

> +/**
> + * tinydrm_display_pipe_init - Initialize display pipe
> + * @tdev: tinydrm device
> + * @funcs: Display pipe functions
> + * @connector_type: Connector type

> + * @formats: Array of supported formats (DRM_FORMAT\_\*)

DRM_FORMAT_* ?

> + * @format_count: Number of elements in @formats
> + * @mode: Supported mode
> + * @rotation: Initial @mode rotation in degrees Counter Clock Wise
> + *
> + * This function sets up a &drm_simple_display_pipe with a &drm_connector 
> that
> + * has one fixed &drm_display_mode which is rotated according to @rotation.
> + *
> + * Returns:
> + * Zero on success, negative error code on failure.
> + */

> +{
> +   struct drm_device *drm = tdev->drm;
> +   struct drm_display_mode *mode_copy;
> +   struct drm_connector *connector;
> +   int ret;

> +   connector = tinydrm_connector_create(drm, mode_copy, connector_type);
> +   if (IS_ERR(connector))
> +   return PTR_ERR(connector);
> +

> +   ret = drm_simple_display_pipe_init(drm, &tdev->pipe, funcs, formats,
> +  format_count, connector);
> +   if (ret)
> +   return ret;
> +
> +   return 0;

return drm_... ?

> +}
> +EXPORT_SYMBOL(tinydrm_display_pipe_init);

-- 
With Best Regards,
Andy Shevchenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel