Re: Slower 3D with kernel 4.11.x

[Daniel Mota Leite]

On Sat, 3 Jun 2017 01:53:04 +, "Bridgman, John"
 wrote:
> OK, no powerplay messages that time. Was performance back to what you
> expected ?

Yes, performance on 4.10.12 is what i call normal

higuita
-- 
Naturally the common people don't want war... but after all it is the
leaders of a country who determine the policy, and it is always a 
simple matter to drag the people along, whether it is a democracy, or
a fascist dictatorship, or a parliament, or a communist dictatorship.
Voice or no voice, the people can always be brought to the bidding of
the leaders. That is easy. All you have to do is tell them they are 
being attacked, and denounce the pacifists for lack of patriotism and
exposing the country to danger.  It works the same in every country.
   -- Hermann Goering, Nazi and war criminal, 1883-1946


pgp8uAN1_JOAx.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 35/37] drm/vmwgfx: Drop drm_vblank_cleanup

[Sinclair Yeh]

Looks ok.  I won't get around to testing this until maybe mid next week though.

On Wed, May 24, 2017 at 04:52:10PM +0200, Daniel Vetter wrote:
> Again stopping the vblank before uninstalling the irq handler is kinda
> the wrong way round, but the fb_off stuff should take care of
> disabling the dsiplay at least in most cases. So drop the
typo ^

> drm_vblank_cleanup code since it's not really doing anything, it looks
> all cargo-culted.
> 
> v2: Appease gcc better.
> 
> Cc: Sinclair Yeh 
> Cc: Thomas Hellstrom 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c  |  9 +++--
>  drivers/gpu/drm/vmwgfx/vmwgfx_kms.h  |  2 --
>  drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c  |  4 
>  drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c |  9 -
>  drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 27 +--
>  5 files changed, 4 insertions(+), 47 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> index a8876b070168..d1f742478b03 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> @@ -1771,7 +1771,7 @@ int vmw_kms_init(struct vmw_private *dev_priv)
>  
>  int vmw_kms_close(struct vmw_private *dev_priv)
>  {
> - int ret;
> + int ret = 0;
>  
>   /*
>* Docs says we should take the lock before calling this function
> @@ -1779,11 +1779,8 @@ int vmw_kms_close(struct vmw_private *dev_priv)
>* drm_encoder_cleanup which takes the lock we deadlock.
>*/
>   drm_mode_config_cleanup(dev_priv->dev);
> - if (dev_priv->active_display_unit == vmw_du_screen_object)
> - ret = vmw_kms_sou_close_display(dev_priv);
> - else if (dev_priv->active_display_unit == vmw_du_screen_target)
> - ret = vmw_kms_stdu_close_display(dev_priv);
> - else
> + if (dev_priv->active_display_unit != vmw_du_screen_object &&
> + dev_priv->active_display_unit != vmw_du_screen_target)
>   ret = vmw_kms_ldu_close_display(dev_priv);
>  
>   return ret;
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
> index 13f2f1d2818a..f94b4ca38ab2 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
> @@ -405,7 +405,6 @@ int vmw_kms_update_proxy(struct vmw_resource *res,
>   * Screen Objects display functions - vmwgfx_scrn.c
>   */
>  int vmw_kms_sou_init_display(struct vmw_private *dev_priv);
> -int vmw_kms_sou_close_display(struct vmw_private *dev_priv);
>  int vmw_kms_sou_do_surface_dirty(struct vmw_private *dev_priv,
>struct vmw_framebuffer *framebuffer,
>struct drm_clip_rect *clips,
> @@ -433,7 +432,6 @@ int vmw_kms_sou_readback(struct vmw_private *dev_priv,
>   * Screen Target Display Unit functions - vmwgfx_stdu.c
>   */
>  int vmw_kms_stdu_init_display(struct vmw_private *dev_priv);
> -int vmw_kms_stdu_close_display(struct vmw_private *dev_priv);
>  int vmw_kms_stdu_surface_dirty(struct vmw_private *dev_priv,
>  struct vmw_framebuffer *framebuffer,
>  struct drm_clip_rect *clips,
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
> index d3987bcf53f8..449ed4fba0f2 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
> @@ -582,13 +582,9 @@ int vmw_kms_ldu_init_display(struct vmw_private 
> *dev_priv)
>  
>  int vmw_kms_ldu_close_display(struct vmw_private *dev_priv)
>  {
> - struct drm_device *dev = dev_priv->dev;
> -
>   if (!dev_priv->ldu_priv)
>   return -ENOSYS;
>  
> - drm_vblank_cleanup(dev);
> -
>   BUG_ON(!list_empty(_priv->ldu_priv->active));
>  
>   kfree(dev_priv->ldu_priv);
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
> index 8d7dc9def7c2..3b917c9b0c21 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
> @@ -746,15 +746,6 @@ int vmw_kms_sou_init_display(struct vmw_private 
> *dev_priv)
>   return 0;
>  }
>  
> -int vmw_kms_sou_close_display(struct vmw_private *dev_priv)
> -{
> - struct drm_device *dev = dev_priv->dev;
> -
> - drm_vblank_cleanup(dev);
> -
> - return 0;
> -}
> -
>  static int do_dmabuf_define_gmrfb(struct vmw_private *dev_priv,
> struct vmw_framebuffer *framebuffer)
>  {
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
> index bad31bdf09b6..b4d4074c0ae0 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
> @@ -1634,36 +1634,11 @@ int vmw_kms_stdu_init_display(struct vmw_private 
> *dev_priv)
>  
>   if (unlikely(ret != 0)) {
>   DRM_ERROR("Failed to initialize 

Re: Kernel panic on nouveau during boot on NVIDIA NV118 (GM108)

[Ben Skeggs]

On 06/03/2017 12:24 AM, Daniel Drake wrote:

On Fri, Jun 2, 2017 at 4:01 AM, Chris Chiu  wrote:

We are working with new desktop that have the NVIDIA NV118
chipset.

During boot, the display becomes unusable at the point where the
nouveau driver loads. We have reproduced on 4.8, 4.11 and linux
master (4.12-rc3).

Can you get a kernel log with "nouveau.debug=debug" set please?

Also worth trying with "nouveau.config=NvForcePost=1" to see if that 
works around the issue.


Ben.



To save digging into the attachment, here is the crash:

nouveau :01:00.0: pci: failed to adjust cap speed
nouveau :01:00.0: pci: failed to adjust lnkctl speed
nouveau :01:00.0: fb: 0 MiB DDR3
divide error:  [#1] SMP
Modules linked in: hid_generic usbmouse usbkbd usbhid i915 nouveau(+)
mxm_wmi i2c_algo_bit drm_kms_helper sdhci_pci syscopyarea sysfillrect
sysimgblt fb_sys_fops ttm sdhci drm ahci libahci wmi i2c_hid hid video
CPU: 3 PID: 200 Comm: systemd-udevd Not tainted 4.11.0-2-generic
#7+dev143.9f9ecd2beos3.2.2-Endless
Hardware name: Acer Aspire Z20-730/IPMAL-BR3, BIOS D01 07/07/2016
task: 8a3070288000 task.stack: a3eb4103c000
RIP: 0010:gf100_ltc_oneinit_tag_ram+0xba/0x100 [nouveau]
RSP: 0018:a3eb4103f6b8 EFLAGS: 00010206
RAX: 1000ffefdfff RBX: 8a306f915000 RCX: 8a3075570030
RDX:  RSI: dead0200 RDI: 8a307fd9b700
RBP: a3eb4103f6d0 R08: 0001e980 R09: 8a3077003900
R10: a3eb40cdbda0 R11: 8a307fd986a4 R12: 
R13: 00015fff R14: 8a306fa2e400 R15: 8a306f914e00
FS:  7f456d052900() GS:8a307fd8() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7fefceb1c020 CR3: 00026fbc5000 CR4: 003406e0
Call Trace:
  gm107_ltc_oneinit+0x7c/0x90 [nouveau]
  nvkm_ltc_oneinit+0x13/0x20 [nouveau]
  nvkm_subdev_init+0x50/0x210 [nouveau]
  nvkm_device_init+0x151/0x270 [nouveau]
  nvkm_udevice_init+0x48/0x60 [nouveau]
  nvkm_object_init+0x40/0x190 [nouveau]
  nvkm_ioctl_new+0x179/0x290 [nouveau]
  ? nvkm_client_notify+0x30/0x30 [nouveau]
  ? nvkm_udevice_rd08+0x30/0x30 [nouveau]
  nvkm_ioctl+0x168/0x240 [nouveau]
  ? nvif_client_init+0x42/0x110 [nouveau]
  nvkm_client_ioctl+0x12/0x20 [nouveau]
  nvif_object_ioctl+0x42/0x50 [nouveau]
  nvif_object_init+0xc2/0x130 [nouveau]
  nvif_device_init+0x12/0x30 [nouveau]
  nouveau_cli_init+0x15e/0x1d0 [nouveau]
  nouveau_drm_load+0x67/0x8b0 [nouveau]
  ? sysfs_do_create_link_sd.isra.2+0x70/0xb0
  drm_dev_register+0x148/0x1e0 [drm]
  drm_get_pci_dev+0xa0/0x160 [drm]
  nouveau_drm_probe+0x1d9/0x260 [nouveau]

Daniel
___
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 100101] [SNB GT1] GPU HANG: ecode 6:0:0x85deffbc, in gnome-shell [3664], reason: Hang on render ring, action: reset

[bugzilla-daemon]

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

Jason Ekstrand  changed:

   What|Removed |Added

 QA Contact|dri-devel@lists.freedesktop |intel-3d-bugs@lists.freedes
   |.org|ktop.org
   Assignee|dri-devel@lists.freedesktop |intel-3d-bugs@lists.freedes
   |.org|ktop.org
  Component|Drivers/DRI/i915|Drivers/DRI/i965

--- Comment #6 from Jason Ekstrand  ---
Sandy Bridge uses the i965 driver.  Moving.

-- 
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

[PATCH] drm/pl111: Fix offset calculation for the primary plane.

[Eric Anholt]

If src_x/y were nonzero, we failed to shift them down by 16 to get the
pixel offset.  The recent CMA helper function gets it right.

Signed-off-by: Eric Anholt 
Fixes: bed41005e617 ("drm/pl111: Initial drm/kms driver for pl111")
Reported-by: Mircea Carausu 
---
 drivers/gpu/drm/pl111/pl111_display.c | 15 ++-
 1 file changed, 2 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/pl111/pl111_display.c 
b/drivers/gpu/drm/pl111/pl111_display.c
index 3e0a4fa73ddb..c6ca4f1bbd49 100644
--- a/drivers/gpu/drm/pl111/pl111_display.c
+++ b/drivers/gpu/drm/pl111/pl111_display.c
@@ -50,17 +50,6 @@ irqreturn_t pl111_irq(int irq, void *data)
return status;
 }
 
-static u32 pl111_get_fb_offset(struct drm_plane_state *pstate)
-{
-   struct drm_framebuffer *fb = pstate->fb;
-   struct drm_gem_cma_object *obj = drm_fb_cma_get_gem_obj(fb, 0);
-
-   return (obj->paddr +
-   fb->offsets[0] +
-   fb->format->cpp[0] * pstate->src_x +
-   fb->pitches[0] * pstate->src_y);
-}
-
 static int pl111_display_check(struct drm_simple_display_pipe *pipe,
   struct drm_plane_state *pstate,
   struct drm_crtc_state *cstate)
@@ -73,7 +62,7 @@ static int pl111_display_check(struct drm_simple_display_pipe 
*pipe,
return -EINVAL;
 
if (fb) {
-   u32 offset = pl111_get_fb_offset(pstate);
+   u32 offset = drm_fb_cma_get_gem_addr(fb, pstate, 0);
 
/* FB base address must be dword aligned. */
if (offset & 3)
@@ -249,7 +238,7 @@ static void pl111_display_update(struct 
drm_simple_display_pipe *pipe,
struct drm_framebuffer *fb = pstate->fb;
 
if (fb) {
-   u32 addr = pl111_get_fb_offset(pstate);
+   u32 addr = drm_fb_cma_get_gem_addr(fb, pstate, 0);
 
writel(addr, priv->regs + CLCD_UBAS);
}
-- 
2.11.0

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

RE: Slower 3D with kernel 4.11.x

[Bridgman, John]

>-Original Message-
>From: Daniel Mota Leite [mailto:dan...@motaleite.net]
>Sent: Friday, June 02, 2017 9:47 PM
>To: Bridgman, John
>Cc: Alex Deucher; DRI Development
>Subject: Re: Slower 3D with kernel 4.11.x
>
>On Thu, 1 Jun 2017 21:09:03 +, "Bridgman, John"
> wrote:
>> Hmm... more powerplay error messages than I am used to seeing, plus a
>> bunch of GPUVM faults, plus a stack trace.
>>
>> My first thought would be to ask if you could go back to the previous
>> kernel, boot up and send a dmesg from that to see how many of those
>> error messages are new.
>
>   See attached file in kernel 4.10.12, boot and after running mad max
>vulkan benchmark , opengl benchmark and then war thunder benchmark.

OK, no powerplay messages that time. Was performance back to what you expected ?

>
>   I would say that the gpu faults are happening in vulkan.
>I can try to update mesa to the latest git or downgrade to 17.1 if you want or
>change the libdrm version (2.4.80 right now)
>
>Thanks
>higuita
>--
>Naturally the common people don't want war... but after all it is the leaders 
>of
>a country who determine the policy, and it is always a simple matter to drag
>the people along, whether it is a democracy, or a fascist dictatorship, or a
>parliament, or a communist dictatorship.
>Voice or no voice, the people can always be brought to the bidding of the
>leaders. That is easy. All you have to do is tell them they are being attacked,
>and denounce the pacifists for lack of patriotism and exposing the country to
>danger.  It works the same in every country.
>   -- Hermann Goering, Nazi and war criminal, 1883-1946
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Slower 3D with kernel 4.11.x

[Daniel Mota Leite]

On Thu, 1 Jun 2017 21:09:03 +, "Bridgman, John"
 wrote:
> Hmm... more powerplay error messages than I am used to seeing, plus a
> bunch of GPUVM faults, plus a stack trace. 
> 
> My first thought would be to ask if you could go back to the previous
> kernel, boot up and send a dmesg from that to see how many of those
> error messages are new. 

See attached file in kernel 4.10.12, boot and after running
mad max vulkan benchmark , opengl benchmark and then war thunder 
benchmark.

I would say that the gpu faults are happening in vulkan.
I can try to update mesa to the latest git or downgrade to 17.1 if you
want or change the libdrm version (2.4.80 right now)

Thanks
higuita
-- 
Naturally the common people don't want war... but after all it is the
leaders of a country who determine the policy, and it is always a 
simple matter to drag the people along, whether it is a democracy, or
a fascist dictatorship, or a parliament, or a communist dictatorship.
Voice or no voice, the people can always be brought to the bidding of
the leaders. That is easy. All you have to do is tell them they are 
being attacked, and denounce the pacifists for lack of patriotism and
exposing the country to danger.  It works the same in every country.
   -- Hermann Goering, Nazi and war criminal, 1883-1946
[0.00] Linux version 4.10.12-slack (root@Couracado) (gcc version 5.4.0 (GCC) ) #7 SMP Fri Apr 21 22:11:34 WEST 2017
[0.00] Command line: BOOT_IMAGE=/vmlinuz-4.10.12-slack-smp root=/dev/mapper/vdisk-root ro vt.default_utf8=1 resume=/dev/sda1 memory_corruption_check=1 usbcore.autosuspend=1 radeon.dpm=1 zcache iommu=pt console=tty0 console=ttyS0,38400n8 no_console_suspend radeon.bapm=1 video=DVI-D-1:1920x1080 video=VGA-1:1280x1024
[0.00] KERNEL supported cpus:
[0.00]   Intel GenuineIntel
[0.00]   AMD AuthenticAMD
[0.00]   Centaur CentaurHauls
[0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format.
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0fff] reserved
[0.00] BIOS-e820: [mem 0x1000-0x0008] usable
[0.00] BIOS-e820: [mem 0x0009-0x00090fff] type 20
[0.00] BIOS-e820: [mem 0x00091000-0x0009dfff] usable
[0.00] BIOS-e820: [mem 0x0009e000-0x0009] unusable
[0.00] BIOS-e820: [mem 0x0010-0xdd278fff] usable
[0.00] BIOS-e820: [mem 0xdd279000-0xdd28dfff] reserved
[0.00] BIOS-e820: [mem 0xdd28e000-0xdd2a4fff] ACPI data
[0.00] BIOS-e820: [mem 0xdd2a5000-0xdd2a8fff] reserved
[0.00] BIOS-e820: [mem 0xdd2a9000-0xdd2c4fff] ACPI data
[0.00] BIOS-e820: [mem 0xdd2c5000-0xdd800fff] ACPI NVS
[0.00] BIOS-e820: [mem 0xdd801000-0xde352fff] reserved
[0.00] BIOS-e820: [mem 0xde353000-0xde3adfff] type 20
[0.00] BIOS-e820: [mem 0xde3ae000-0xde3aefff] usable
[0.00] BIOS-e820: [mem 0xde3af000-0xde5b4fff] ACPI NVS
[0.00] BIOS-e820: [mem 0xde5b5000-0xde9f2fff] usable
[0.00] BIOS-e820: [mem 0xde9f3000-0xdeff3fff] reserved
[0.00] BIOS-e820: [mem 0xdeff4000-0xdeff] usable
[0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved
[0.00] BIOS-e820: [mem 0xfeb8-0xfec01fff] reserved
[0.00] BIOS-e820: [mem 0xfec1-0xfec10fff] reserved
[0.00] BIOS-e820: [mem 0xfed0-0xfed00fff] reserved
[0.00] BIOS-e820: [mem 0xfed8-0xfed8] reserved
[0.00] BIOS-e820: [mem 0xff00-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00021eff] usable
[0.00] NX (Execute Disable) protection: active
[0.00] efi: EFI v32.31 by American Megatrends
[0.00] efi:  ACPI=0xdd2ae000  ACPI 2.0=0xdd2ae000  SMBIOS=0xde351418 
[0.00] SMBIOS 2.7 present.
[0.00] DMI: System manufacturer System Product Name/A88X-PLUS, BIOS 3003 03/10/2016
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] e820: last_pfn = 0x21f000 max_arch_pfn = 0x4
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 

Re: [GIT PULL] omapdrm changes for v4.13 v2

[Dave Airlie]

On 2 June 2017 at 18:48, Tomi Valkeinen  wrote:
> Hi Dave,
>
> Here's second attempt for omapdrm changes for v4.13. The first version 
> conflicts
> with the latest drm-next due to the DRM_ROTATE flag changes. This one is 
> rebased
> on top of the latest drm-next.

As much as I dislike rebases (hope you tested), I did try and pull the
original yesterday, saw conflict nightmare, and held off until I had
more brain bandwidth to look. Thanks for providing a clean pull in the
meantime, read my mind!

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

[Bug 99851] [drm:.r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD)

[bugzilla-daemon]

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

erhar...@mailbox.org changed:

   What|Removed |Added

 Attachment #131537|0   |1
is obsolete||

--- Comment #47 from erhar...@mailbox.org ---
Created attachment 131686
  --> https://bugs.freedesktop.org/attachment.cgi?id=131686=edit
bisect kernel .config

-- 
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 99851] [drm:.r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD)

[bugzilla-daemon]

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

--- Comment #46 from erhar...@mailbox.org ---
Created attachment 131685
  --> https://bugs.freedesktop.org/attachment.cgi?id=131685=edit
pgtable fix bisect.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 99851] [drm:.r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD)

[bugzilla-daemon]

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

erhar...@mailbox.org changed:

   What|Removed |Added

 Attachment #131536|0   |1
is obsolete||

--- Comment #45 from erhar...@mailbox.org ---
Created attachment 131684
  --> https://bugs.freedesktop.org/attachment.cgi?id=131684=edit
ring0 bisect.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 99851] [drm:.r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD)

[bugzilla-daemon]

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

--- Comment #44 from erhar...@mailbox.org ---
Finally I was able to finish the bisect with some help from slyfox from
#gentoo-powerpc. At last...

I made a second bisect in search of the fix for the "Couldn't allocate pmd
pagetable caches" error, which I found in commit
bf5ca68dd2eef59a936969e802d811bdac4709c2 (powerpc: Fix pgtable pmd cache init).
I applied this commit via git cherry-pick --no-commit to my first bisect and
was able to continue withouth further skips. So, the final candidate for the
"ring 0" error is:

commit 60db3a4d8cc9073cf56264785197ba75ee1caca4 (refs/bisect/bad)
Author: Sinan Kaya 

PCI: Enable PCIe Extended Tags if supported

-- 
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: [linux-sunxi] Re: [RFC PATCH 07/11] drm: sun4i: add support for the TV encoder in H3 SoC

[Maxime Ripard]

On Thu, Jun 01, 2017 at 10:11:14PM +0800, icen...@aosc.io wrote:
> 在 2017-06-01 02:43，Maxime Ripard 写道：
> > On Wed, May 24, 2017 at 04:25:46PM +0800, Icenowy Zheng wrote:
> > > 
> > > 
> > > 于 2017年5月24日 GMT+08:00 下午3:30:19, Maxime Ripard
> > >  写到:
> > > >On Tue, May 23, 2017 at 09:00:59PM +0800, icen...@aosc.io wrote:
> > > >> 在 2017-05-23 20:53，Maxime Ripard 写道：
> > > >> > On Mon, May 22, 2017 at 07:55:56PM +0200, Jernej Škrabec wrote:
> > > >> > > Hi,
> > > >> > >
> > > >> > > Dne sobota, 20. maj 2017 ob 03:37:53 CEST je Chen-Yu Tsai
> > > >napisal(a):
> > > >> > > > On Sat, May 20, 2017 at 2:23 AM, Jernej Škrabec
> > > >
> > > >> > > wrote:
> > > >> > > > > Hi,
> > > >> > > > >
> > > >> > > > > Dne petek, 19. maj 2017 ob 20:08:18 CEST je Icenowy Zheng
> > > >napisal(a):
> > > >> > > > >> 于 2017年5月20日 GMT+08:00 上午2:03:30, Maxime Ripard
> > > > > > >> > > > >
> > > >> > > > > electrons.com> 写到:
> > > >> > > > >> >On Thu, May 18, 2017 at 12:43:50AM +0800, Icenowy Zheng
> > > >wrote:
> > > >> > > > >> >> Allwinner H3 features a TV encoder similar to the one in
> > > >earlier
> > > >> > > > >> >
> > > >> > > > >> >SoCs,
> > > >> > > > >> >
> > > >> > > > >> >> but with some different points about clocks:
> > > >> > > > >> >> - It has a mod clock and a bus clock.
> > > >> > > > >> >> - The mod clock must be at a fixed rate to generate
> > > >signal.
> > > >> > > > >> >
> > > >> > > > >> >Why?
> > > >> > > > >>
> > > >> > > > >> It's experiment result by Jernej.
> > > >> > > > >>
> > > >> > > > >> The clock rates in BSP kernel is also specially designed
> > > >> > > > >> (PLL_DE at 432MHz) in order to be able to feed the TVE.
> > > >> > > > >
> > > >> > > > > My experiments and search through BSP code showed that TVE
> > > >seems to have
> > > >> > > > > additional fixed predivider 8. So if you want to generate 27
> > > >MHz clock,
> > > >> > > > > unit has to be feed with 216 MHz.
> > > >> > > > >
> > > >> > > > > TVE has only one PLL source PLL_DE. And since 216 MHz is a
> > > >bit low for
> > > >> > > > > DE2,
> > > >> > > > > BSP defaults to 432 MHz for PLL_DE and use divider 2 to
> > > >generate 216 MHz.
> > > >> > > > > This clock is then divided by 8 internaly to get final 27
> > > >MHz.
> > > >> > > > >
> > > >> > > > > Please note that I don't have any hard evidence to support
> > > >that, only
> > > >> > > > > experimental data. However, only that explanation make sense
> > > >to me.
> > > >> > > > >
> > > >> > > > > BTW, BSP H3/H5 TV driver supports only PAL and NTSC which
> > > >both use 27 MHz
> > > >> > > > > base clock. Further experiments are needed to check if there
> > > >is any
> > > >> > > > > possibility to have other resolutions by manipulating clocks
> > > >and give
> > > >> > > > > other proper settings. I plan to do that, but not in very
> > > >near future.
> > > >> > > >
> > > >> > > > You only have composite video output, and those are the only 2
> > > >standard
> > > >> > > > resolutions that make any sense.
> > > >> > >
> > > >> > > Right, other resolutions are for VGA.
> > > >> > >
> > > >> > > Anyway, I did some more digging in A10 and R40 datasheets. I
> > > >think
> > > >> > > that H3 TVE
> > > >> > > unit is something in between. R40 TVE has a setting to select "up
> > > >> > > sample".
> > > >> >
> > > >> > That might be just another translation of oversampling :)
> > > >> >
> > > >> > I didn't know it could be applied to composite signals though, but
> > > >I
> > > >> > guess this is just another analog signal after all.
> > > >> >
> > > >> > > Possible settings are 27 MHz, 54 MHz, 108 MHz and 216 MHz. BSP
> > > >> > > driver on R40
> > > >> > > has this setting enabled only for PAL and NTSC and it is always
> > > >216
> > > >> > > MHz. I
> > > >> > > think that H3 may have this hardwired to 216 MHz and this would
> > > >be
> > > >> > > the reason
> > > >> > > why 216 MHz is needed.
> > > >> > >
> > > >> > > Has anyone else any better explanation?
> > > >> >
> > > >> > That's already a pretty good one.
> > > >> >
> > > >> > Either way, wether this is upsampling, oversampling or just a
> > > >> > pre-divider, this can and should be dealt with in the mode_set
> > > >> > callback, and not in the probe.
> > > >>
> > > >> I got a better idea -- let TVE driver have the CLK_TVE as an
> > > >> input and create a subclock output with divider 16, and feed this
> > > >> subclock to TCON lcd-ch1.
> > > >>
> > > >> This is a model of the real hardware -- the clock divider is in
> > > >> TVE, not TCON.
> > > >
> > > >That's definitely not a good representation of the hardware. There's
> > > >one clock, it goes to the TCON, period.
> > > 
> > > No, I still think it goes to the TVE as:
> > > 
> > > 1. it's named TVE in datasheet.
> > 
> > Feel free to come up with a better, more sensible explanation?
> > 
> > > 2. Generating signal with such a low resolution but such
> > > a high dotclock is not a good 

Re: [PATCH] vc4_bo.c: always set bo->resv

[Eric Anholt]

Hans Verkuil  writes:

> The bo->resv pointer could be NULL, leading to kernel oopses like the one 
> below.
> It looks like .fb_probe -> drm_fbdev_cma_create() -> drm_gem_cma_create() 
> would
> end up not initializing resv, because we're doing that in vc4_bo_create(), not
> vc4_create_object().
>
> This patch ensures that bo->resv is always set in vc4_create_object
> ensuring that it is never NULL.
>
> Thanks to Eric Anholt for pointing to the correct solution.

Folks that know dma-buf better: Will having two reservations around for
the lifetime of the BO in the case of CMA dma-buf imports be a bad
thing?  I'm assuming reservations are cheap, given that we're
unconditionally allocating them per BO for un-shared BOs already.

> Signed-off-by: Hans Verkuil 
> ---
>   drivers/gpu/drm/vc4/vc4_bo.c | 12 
>   1 file changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
> index 80b2f9e55c5c..2231ee76cd8d 100644
> --- a/drivers/gpu/drm/vc4/vc4_bo.c
> +++ b/drivers/gpu/drm/vc4/vc4_bo.c
> @@ -91,8 +91,7 @@ static void vc4_bo_destroy(struct vc4_bo *bo)
>   vc4->bo_stats.num_allocated--;
>   vc4->bo_stats.size_allocated -= obj->size;
>
> - if (bo->resv == >_resv)
> - reservation_object_fini(bo->resv);
> + reservation_object_fini(bo->resv);

This one would need to be "reservation_object_fini(>_resv);" -- we
need to free the reservation that we created (and left unused in the
case of an import), not the one that was imported from someone else.

>   drm_gem_cma_free_object(obj);
>   }
> @@ -212,6 +211,8 @@ struct drm_gem_object *vc4_create_object(struct 
> drm_device *dev, size_t size)
>   vc4->bo_stats.num_allocated++;
>   vc4->bo_stats.size_allocated += size;
>   mutex_unlock(>bo_lock);
> + bo->resv = >_resv;
> + reservation_object_init(bo->resv);
>
>   return >base.base;
>   }
> @@ -250,12 +251,7 @@ struct vc4_bo *vc4_bo_create(struct drm_device *dev, 
> size_t unaligned_size,
>   return ERR_PTR(-ENOMEM);
>   }
>   }
> - bo = to_vc4_bo(_obj->base);
> -
> - bo->resv = >_resv;
> - reservation_object_init(bo->resv);
> -
> - return bo;
> + return to_vc4_bo(_obj->base);
>   }
>
>   int vc4_dumb_create(struct drm_file *file_priv,
> -- 
> 2.11.0


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

[PATCH] vc4_bo.c: always set bo->resv

[Hans Verkuil]

The bo->resv pointer could be NULL, leading to kernel oopses like the one below.
It looks like .fb_probe -> drm_fbdev_cma_create() -> drm_gem_cma_create() would
end up not initializing resv, because we're doing that in vc4_bo_create(), not
vc4_create_object().

This patch ensures that bo->resv is always set in vc4_create_object
ensuring that it is never NULL.

Thanks to Eric Anholt for pointing to the correct solution.

[   19.738487] Unable to handle kernel NULL pointer dereference at virtual 
address 
[   19.746805] pgd = 8000275fc000
[   19.750319] [] *pgd=
[   19.754715] Internal error: Oops: 9604 [#1] PREEMPT SMP
[   19.760369] Modules linked in: smsc95xx usbnet vc4 drm_kms_helper drm 
pwm_bcm2835 i2c_bcm2835 bcm2835_rng rng_core bcm2835_dma virt_dma
[   19.772767] CPU: 0 PID: 1297 Comm: Xorg Not tainted 4.12.0-rc1-rpi3 #58
[   19.779476] Hardware name: Raspberry Pi 3 Model B (DT)
[   19.784688] task: 800028268000 task.stack: 800026c08000
[   19.790705] PC is at ww_mutex_lock_interruptible+0x14/0xc0
[   19.796329] LR is at vc4_submit_cl_ioctl+0x4fc/0x998 [vc4]
[   19.801892] pc : [] lr : [] pstate: 
a145
[   19.809391] sp : 800026c0bc30
[   19.812750] x29: 800026c0bc30 x28: 
[   19.818142] x27: 80003a385a00 x26: 
[   19.823534] x25:  x24: 
[   19.828925] x23: 800027510200 x22: 800026393800
[   19.834316] x21: 800027510270 x20: 800027510b00
[   19.839707] x19: 80003a00a418 x18: 0011
[   19.845099] x17: 0008 x16: 001d
[   19.850490] x15: 001b x14: 001c
[   19.855881] x13:  x12: 0001
[   19.861272] x11: 001a x10: 
[   19.82] x9 :  x8 : 80003a385a00
[   19.872053] x7 : 0073 x6 : 
[   19.877445] x5 : 0001 x4 : 0019
[   19.882835] x3 : 800028268000 x2 : 
[   19.888226] x1 : 800026c0bce8 x0 : 
[   19.893621] Process Xorg (pid: 1297, stack limit = 0x800026c08000)
[   19.900244] Stack: (0x800026c0bc30 to 0x800026c0c000)
[   19.906073] bc20:   800026c0bc60 
009b3ea4
[   19.914019] bc40:   80002809fc00 
15f5
[   19.921964] bc60: 800026c0bd00 008f75f8 009bdd80 
c0a06440
[   19.929910] bc80: 00a0 800027a58600 eb48d398 
00a0
[   19.937856] bca0: 0091ad58 0040 800026393800 
800027510b00
[   19.945802] bcc0: 009bdd80 c0a06440 800027a58650 
800027c42684
[   19.953747] bce0: eb48d398 800028268000 0001 

[   19.961693] bd00: 800026c0be00 0821383c 800028abb8d8 
80003a31eb00
[   19.969638] bd20: eb48d398 80003a31eb00 c0a06440 
eb48d398
[   19.977585] bd40: 0124 001d 088b2000 
800028268000
[   19.985530] bd60: 800026c0bd80 00a0 009b39a8 
800026c0bd80
[   19.993476] bd80: 007f8000 000a 800026c0bda0 
08097b58
[   20.001422] bda0: 800026c0be00 080812cc 088bb308 
8207
[   20.009366] bdc0: 088bb438 a9b56178 800026c0bec0 
0020
[   20.017313] bde0: 8207 a9b56178 0001 
800028268000
[   20.025258] be00: 800026c0be80 08213fe4  
800032374000
[   20.033204] be20: 80003a31eb00 0018 8000 
800026c0be30
[   20.041150] be40: 800026c0be80 08213fa8  
80003a31eb00
[   20.049096] be60: 800026c0be70 08220300 800026c0be80 
08213f88
[   20.057042] be80:  08082f30  
800032374000
[   20.064988] bea0:  aad04cdc 4000 
0015
[   20.072933] bec0: 0018 c0a06440 eb48d398 

[   20.080879] bee0: e7550b00  0040 
e7550910
[   20.088824] bf00: 001d e7550b50  

[   20.096769] bf20:   0008 
eb48d1a8
[   20.104714] bf40: ab0472a0 aad04cd0 e754a3a0 
aa21d000
[   20.112659] bf60: eb48d398 c0a06440 0018 
aa21f000
[   20.120605] bf80: e754bd80 eb48d498 e751e8c0 
e6d346b0
[   20.128551] bfa0: e6d4f3f0 eb48d310 ab02d884 
eb48d310
[   20.136496] bfc0: aad04cdc 4000 0018 
001d
[   20.11] bfe0:   

[PULL] drm-misc-next

[Sean Paul]

Hi Dave,
Smallish (by series count) -next pull request here comprised of a few moderately
sized series'. We gained mode_valid() hooks for crtc/encoder/bridge, and now 
have
a clearer seperation between irq and vblank. Additionally we cleaned up some 
legacy
code by turfing drm_for_each_connector and a number of drm_vblank_cleanup 
copypasta.

drm-misc-next-2017-06-02:
Core Changes:
- Stop proliferation of drm_vblank_cleanup by adding to the docs and deleting
  boilerplate (Daniel)
- Roll out and use mode_valid hooks across crtc/encoder/bridge (Jose)
- Add drm_vblank.[hc] to isolate vblank code from optional irq helpers (Daniel)

Driver Changes:
- Replace drm_for_each_connector with drm_for_each_connector_iter (Gustavo)
- A couple misc driver fixes

Cc: Gustavo Padovan 
Cc: Jose Abreu 
Cc: Daniel Vetter 

Cheers, Sean


The following changes since commit 71ebc9a3795818eab52e81bbcbdfae130ee35d9e:

  dma-buf/sync-file: Defer creation of sync_file->name (2017-05-24 13:08:29 
-0300)

are available in the git repository at:

  git://anongit.freedesktop.org/git/drm-misc tags/drm-misc-next-2017-06-02

for you to fetch changes up to 7f696942a7e52df2a99410bf23da513f9aad04fb:

  drm/vc4: Mark the device as active when enabling runtime PM. (2017-06-02 
13:00:47 -0700)


Core Changes:
- Stop proliferation of drm_vblank_cleanup by adding to the docs and deleting
  boilerplate (Daniel)
- Roll out and use mode_valid hooks across crtc/encoder/bridge (Jose)
- Add drm_vblank.[hc] to isolate vblank code from optional irq helpers (Daniel)

Driver Changes:
- Replace drm_for_each_connector with drm_for_each_connector_iter (Gustavo)
- A couple misc driver fixes

Cc: Gustavo Padovan 
Cc: Jose Abreu 
Cc: Daniel Vetter 


Arnd Bergmann (2):
  drm/pl111: select DRM_PANEL
  drm/pl111: fix warnings without CONFIG_ARM_AMBA

Boris Brezillon (1):
  drm/vc4: Fix comment in vc4_drv.h

Corentin Labbe (1):
  drm: remove writeq/readq function definitions

Daniel Vetter (13):
  drm: Remove drm_device->virtdev
  drm/doc: move printf helpers out of drmP.h
  drm: better document how to send out the crtc disable event
  drm/sun4i: Drop drm_vblank_cleanup
  drm/stm: Drop drm_vblank_cleanup
  drm/meson: Drop drm_vblank_cleanup
  drm/imx: Drop drm_vblank_cleanup
  drm/atmel: Drop drm_vblank_cleanup
  drm/arcgpu: Drop drm_vblank_cleanup
  drm: Extract drm_vblank.[hc]
  drm/doc: Polish irq helper documentation
  drm/hdlcd|mali: Drop drm_vblank_cleanup
  drm/exynos: Drop drm_vblank_cleanup

Eric Anholt (1):
  drm/vc4: Mark the device as active when enabling runtime PM.

Gustavo Padovan (8):
  drm/exynos: use drm_for_each_connector_iter()
  drm/rockchip: use drm_for_each_connector_iter()
  drm/i915: use drm_for_each_connector_iter()
  drm/mediatek: use drm_for_each_connector_iter()
  drm/nouveau: use drm_for_each_connector_iter()
  drm/vc4: use drm_for_each_connector_iter()
  drm: remove unsafe drm_for_each_connector()
  drm: todo: remove task about switch to drm_connector_list_iter

Joe Perches (1):
  drm: Use vsnprintf extension %ph

Jose Abreu (6):
  drm: Add drm_{crtc/encoder/connector}_mode_valid()
  drm: Introduce drm_bridge_mode_valid()
  drm: Use new mode_valid() helpers in connector probe helper
  drm: Use mode_valid() in atomic modeset
  drm/bridge: analogix-anx78xx: Use bridge->mode_valid() callback
  drm/atmel-hlcdc: Use crtc->mode_valid() callback

Ville Syrjälä (1):
  drm/atomic: Consitfy mode parameter to drm_atomic_set_mode_for_crtc()

 Documentation/gpu/drm-internals.rst|   63 +-
 Documentation/gpu/drm-kms.rst  |4 +-
 Documentation/gpu/todo.rst |   13 -
 drivers/gpu/drm/Makefile   |2 +-
 drivers/gpu/drm/arc/arcpgu_drv.c   |1 -
 drivers/gpu/drm/arm/hdlcd_drv.c|2 -
 drivers/gpu/drm/arm/malidp_drv.c   |2 -
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c |   10 +-
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c   |6 +-
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h   |5 +-
 drivers/gpu/drm/bridge/analogix-anx78xx.c  |   14 +-
 drivers/gpu/drm/drm_atomic.c   |2 +-
 drivers/gpu/drm/drm_atomic_helper.c|   76 +-
 drivers/gpu/drm/drm_bridge.c   |   33 +
 drivers/gpu/drm/drm_crtc_helper_internal.h |   12 +
 drivers/gpu/drm/drm_dp_mst_topology.c  |   51 +-
 drivers/gpu/drm/drm_internal.h |3 +-
 drivers/gpu/drm/drm_irq.c  | 1643 +--
 drivers/gpu/drm/drm_probe_helper.c 

Re: [PATCH v3 1/6] drm/stm: ltdc: Add panel-bridge support

[Eric Anholt]

Philippe CORNU  writes:

> Add the panel-bridge support for both panels & bridges (used by DSI host &
> HDMI/LVDS bridges).

This looks like a great cleanup.  Just a couple of things I noticed, and
hopefully once the DT is reviewed we can merge it.  I've also
resubmitted the panel-bridge patch so that hopefully we can land it
soon.

> -static struct drm_encoder *ltdc_rgb_encoder_create(struct drm_device *ddev)
> +static int ltdc_encoder_init(struct drm_device *ddev)
>  {
> + struct ltdc_device *ldev = ddev->dev_private;
>   struct drm_encoder *encoder;
> + int ret;
>  
>   encoder = devm_kzalloc(ddev->dev, sizeof(*encoder), GFP_KERNEL);
>   if (!encoder)
> - return NULL;
> + return -ENOMEM;
>  
>   encoder->possible_crtcs = CRTC_MASK;
>   encoder->possible_clones = 0; /* No cloning support */
>  
> - drm_encoder_init(ddev, encoder, _rgb_encoder_funcs,
> + drm_encoder_init(ddev, encoder, _encoder_funcs,
>DRM_MODE_ENCODER_DPI, NULL);
>  
> - drm_encoder_helper_add(encoder, _rgb_encoder_helper_funcs);
> -
> - DRM_DEBUG_DRIVER("RGB encoder:%d created\n", encoder->base.id);
> -
> - return encoder;
> -}
> -
> -/*
> - * DRM_CONNECTOR
> - */
> -
> -static int ltdc_rgb_connector_get_modes(struct drm_connector *connector)
> -{
> - struct drm_device *ddev = connector->dev;
> - struct ltdc_device *ldev = ddev->dev_private;
> - int ret = 0;
> -
> - DRM_DEBUG_DRIVER("\n");
> -
> - if (ldev->panel)
> - ret = drm_panel_get_modes(ldev->panel);
> -
> - return ret < 0 ? 0 : ret;
> -}
> -
> -static struct drm_connector_helper_funcs ltdc_rgb_connector_helper_funcs = {
> - .get_modes = ltdc_rgb_connector_get_modes,
> -};
> -
> -static enum drm_connector_status
> -ltdc_rgb_connector_detect(struct drm_connector *connector, bool force)
> -{
> - struct ltdc_device *ldev = connector_to_ltdc(connector);
> -
> - return ldev->panel ? connector_status_connected :
> -connector_status_disconnected;
> -}
> -
> -static void ltdc_rgb_connector_destroy(struct drm_connector *connector)
> -{
> - DRM_DEBUG_DRIVER("\n");
> -
> - drm_connector_unregister(connector);
> - drm_connector_cleanup(connector);
> -}
> -
> -static const struct drm_connector_funcs ltdc_rgb_connector_funcs = {
> - .dpms = drm_atomic_helper_connector_dpms,
> - .fill_modes = drm_helper_probe_single_connector_modes,
> - .detect = ltdc_rgb_connector_detect,
> - .destroy = ltdc_rgb_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,
> -};
> -
> -struct drm_connector *ltdc_rgb_connector_create(struct drm_device *ddev)
> -{
> - struct drm_connector *connector;
> - int err;
> -
> - connector = devm_kzalloc(ddev->dev, sizeof(*connector), GFP_KERNEL);
> - if (!connector) {
> - DRM_ERROR("Failed to allocate connector\n");
> - return NULL;
> - }
> -
> - connector->polled = DRM_CONNECTOR_POLL_HPD;
> + drm_encoder_helper_add(encoder, NULL);

I think the funcs table should be NULL by default, so you can just drop
this line.

>  
> - err = drm_connector_init(ddev, connector, _rgb_connector_funcs,
> -  DRM_MODE_CONNECTOR_DPI);
> - if (err) {
> - DRM_ERROR("Failed to initialize connector\n");
> - return NULL;
> + ret = drm_bridge_attach(encoder, ldev->bridge, NULL);
> + if (ret) {
> + drm_encoder_cleanup(encoder);
> + return -EINVAL;
>   }
>  
> - drm_connector_helper_add(connector, _rgb_connector_helper_funcs);
> -
> - DRM_DEBUG_DRIVER("RGB connector:%d created\n", connector->base.id);
> + DRM_DEBUG_DRIVER("Bridge encoder:%d created\n", encoder->base.id);
>  
> - return connector;
> + return 0;
>  }



> @@ -1129,9 +988,9 @@ int ltdc_load(struct drm_device *ddev)
>   ddev->irq_enabled = 1;
>  
>   return 0;
> +
>  err:
> - if (ldev->panel)
> - drm_panel_detach(ldev->panel);
> + drm_panel_bridge_remove(bridge);
>  
>   clk_disable_unprepare(ldev->pixel_clk);
>  
> @@ -1146,8 +1005,7 @@ void ltdc_unload(struct drm_device *ddev)
>  
>   drm_vblank_cleanup(ddev);
>  
> - if (ldev->panel)
> - drm_panel_detach(ldev->panel);
> + drm_panel_bridge_remove(ldev->bridge);

If you had no panel, this would try to kfree some other module's bridge
structure.  I guess you could track ldev->is_panel_bridge (like I did
for vc4) and conditionally drm_panel_bridge_remove().


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

[Bug 194761] amdgpu driver breaks on Oland (SI)

[bugzilla-daemon]

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

--- Comment #35 from Alex Deucher (alexdeuc...@gmail.com) ---
Created attachment 256845
  --> https://bugzilla.kernel.org/attachment.cgi?id=256845=edit
another possible fix

This sets mc_arb_ramcfg properly for userspace.

-- 
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 194761] amdgpu driver breaks on Oland (SI)

[bugzilla-daemon]

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

--- Comment #34 from Marek Olšák (mar...@gmail.com) ---
BTW, adev->gfx.config.mc_arb_ramcfg is not set for SI. That might cause addrlib
to do something incorrect.

-- 
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

[PATCH v3] drm/bridge: Refactor out the panel wrapper from the lvds-encoder bridge.

[Eric Anholt]

Many DRM drivers have common code to make a stub connector
implementation that wraps a drm_panel.  By wrapping the panel in a DRM
bridge, all of the connector code (including calls during encoder
enable/disable) goes away.

v2: Fix build with CONFIG_DRM=m, drop "dev" argument that should just
be the panel's dev, move kerneldoc up a level and document
_remove().
v3: Fix another breakage with CONFIG_DRM=m, fix breakage with
CONFIG_OF=n, move protos under CONFIG_DRM_PANEL_BRIDGE, wrap a
line.

Signed-off-by: Eric Anholt 
Acked-by: Daniel Vetter  (v1)
Reviewed-by: Boris Brezillon  (v2)
Acked-by: Archit Taneja  (v2)
---

New version of the first patch with build fixes.  I've re-pushed to
get another round of kbuild test, but if it comes back clean, I'd like
to merge this one, the vc4 patches (unchanged), and atmel-hlcdc (acked
by the maintainer).  I'd be dropping my STM patch (replaced by their
DSI series), and mediatek (I'd like an ack from the maintainer first).

 Documentation/gpu/drm-kms-helpers.rst |   6 +
 drivers/gpu/drm/Makefile  |   1 +
 drivers/gpu/drm/bridge/Kconfig|  11 +-
 drivers/gpu/drm/bridge/lvds-encoder.c | 157 +++---
 drivers/gpu/drm/bridge/panel.c| 200 ++
 include/drm/drm_bridge.h  |   7 ++
 6 files changed, 241 insertions(+), 141 deletions(-)
 create mode 100644 drivers/gpu/drm/bridge/panel.c

diff --git a/Documentation/gpu/drm-kms-helpers.rst 
b/Documentation/gpu/drm-kms-helpers.rst
index c075aadd7078..7c5e2549a58a 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -143,6 +143,12 @@ Bridge Helper Reference
 .. kernel-doc:: drivers/gpu/drm/drm_bridge.c
:export:
 
+Panel-Bridge Helper Reference
+-
+
+.. kernel-doc:: drivers/gpu/drm/bridge/panel.c
+   :export:
+
 .. _drm_panel_helper:
 
 Panel Helper Reference
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index acc88942c2e5..dc69175255b1 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -24,6 +24,7 @@ drm-$(CONFIG_COMPAT) += drm_ioc32.o
 drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
 drm-$(CONFIG_PCI) += ati_pcigart.o
 drm-$(CONFIG_DRM_PANEL) += drm_panel.o
+drm-$(CONFIG_DRM_PANEL_BRIDGE) += bridge/panel.o
 drm-$(CONFIG_OF) += drm_of.o
 drm-$(CONFIG_AGP) += drm_agpsupport.o
 drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index f6968d3b4b41..adf9ae0e0b7c 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -4,6 +4,14 @@ config DRM_BRIDGE
help
  Bridge registration and lookup framework.
 
+config DRM_PANEL_BRIDGE
+   def_bool y
+   depends on DRM_BRIDGE
+   depends on DRM_KMS_HELPER
+   select DRM_PANEL
+   help
+ DRM bridge wrapper of DRM panels
+
 menu "Display Interface Bridges"
depends on DRM && DRM_BRIDGE
 
@@ -27,8 +35,7 @@ config DRM_DUMB_VGA_DAC
 config DRM_LVDS_ENCODER
tristate "Transparent parallel to LVDS encoder support"
depends on OF
-   select DRM_KMS_HELPER
-   select DRM_PANEL
+   select DRM_PANEL_BRIDGE
help
  Support for transparent parallel to LVDS encoders that don't require
  any configuration.
diff --git a/drivers/gpu/drm/bridge/lvds-encoder.c 
b/drivers/gpu/drm/bridge/lvds-encoder.c
index f1f67a279426..0903ba574f61 100644
--- a/drivers/gpu/drm/bridge/lvds-encoder.c
+++ b/drivers/gpu/drm/bridge/lvds-encoder.c
@@ -8,144 +8,18 @@
  */
 
 #include 
-#include 
-#include 
-#include 
-#include 
-#include 
+#include 
 #include 
 
 #include 
 
-struct lvds_encoder {
-   struct device *dev;
-
-   struct drm_bridge bridge;
-   struct drm_connector connector;
-   struct drm_panel *panel;
-};
-
-static inline struct lvds_encoder *
-drm_bridge_to_lvds_encoder(struct drm_bridge *bridge)
-{
-   return container_of(bridge, struct lvds_encoder, bridge);
-}
-
-static inline struct lvds_encoder *
-drm_connector_to_lvds_encoder(struct drm_connector *connector)
-{
-   return container_of(connector, struct lvds_encoder, connector);
-}
-
-static int lvds_connector_get_modes(struct drm_connector *connector)
-{
-   struct lvds_encoder *lvds = drm_connector_to_lvds_encoder(connector);
-
-   return drm_panel_get_modes(lvds->panel);
-}
-
-static const struct drm_connector_helper_funcs lvds_connector_helper_funcs = {
-   .get_modes = lvds_connector_get_modes,
-};
-
-static const struct drm_connector_funcs lvds_connector_funcs = {
-   .dpms = drm_atomic_helper_connector_dpms,
-   .reset = drm_atomic_helper_connector_reset,
-   .fill_modes = drm_helper_probe_single_connector_modes,
-   .destroy = drm_connector_cleanup,
-   

Re: [PATCH v5 10/10] drm: vc4: Use crtc->mode_valid() and encoder->mode_valid() callbacks

[Eric Anholt]

Jose Abreu  writes:

> Now that we have a callback to check if crtc and encoder supports a
> given mode we can use it in vc4 so that we restrict the number of
> probbed modes to the ones we can actually display.

"probed"

>
> Also, remove the mode_fixup() calls as these are no longer needed
> because mode_valid() will be called before.
>
> NOTE: Not even compiled tested

Compile-tested and Reviewed-by: Eric Anholt 


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

Re: [PATCH 19/19] ARM: sun6i: a31s: Enable HDMI display output on the MSI Primo81 tablet

[Maxime Ripard]

On Fri, Jun 02, 2017 at 06:10:24PM +0800, Chen-Yu Tsai wrote:
> The MSI Primo81 tablet has a micro HDMI connector at the bottom.
> This is connected to the SoCs HDMI output.
> 
> Enable the display pipeline and the HDMI output.
> 
> Signed-off-by: Chen-Yu Tsai 
> ---
>  arch/arm/boot/dts/sun6i-a31s-primo81.dts | 25 +
>  1 file changed, 25 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/sun6i-a31s-primo81.dts 
> b/arch/arm/boot/dts/sun6i-a31s-primo81.dts
> index f3712753fa42..26154b2f87a3 100644
> --- a/arch/arm/boot/dts/sun6i-a31s-primo81.dts
> +++ b/arch/arm/boot/dts/sun6i-a31s-primo81.dts
> @@ -52,17 +52,42 @@
>  / {
>   model = "MSI Primo81 tablet";
>   compatible = "msi,primo81", "allwinner,sun6i-a31s";
> +
> + hdmi-connector {
> + compatible = "hdmi-connector";
> + type = "c";

Should we add a connector type for this one?

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [PATCH 14/19] drm/sun4i: hdmi: Add support for A31's HDMI controller

[Maxime Ripard]

On Fri, Jun 02, 2017 at 06:10:19PM +0800, Chen-Yu Tsai wrote:
> The HDMI controller found in the A31 SoCs is slightly different
> from the one already supported, which is found in the A10s:
> 
>   - Need different initial values for the PLL related registers
> 
>   - Different behavior of the DDC and TMDS clocks
> 
>   - Different register layout for the DDC portion
> 
>   - Separate DDC parent clock
> 
> This patch adds support for it.
> 
> Signed-off-by: Chen-Yu Tsai 
> ---
>  drivers/gpu/drm/sun4i/sun4i_hdmi.h |   3 +
>  drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 141 
> +
>  2 files changed, 144 insertions(+)
> 
> diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi.h 
> b/drivers/gpu/drm/sun4i/sun4i_hdmi.h
> index c63d0bd95963..2589bc92be59 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_hdmi.h
> +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi.h
> @@ -56,10 +56,13 @@
>  #define SUN4I_HDMI_PAD_CTRL0_TXENBIT(23)
>  
>  #define SUN4I_HDMI_PAD_CTRL1_REG 0x204
> +#define SUN4I_HDMI_PAD_CTRL1_UNKNOWN BIT(24) /* set on A31 */
>  #define SUN4I_HDMI_PAD_CTRL1_AMP_OPT BIT(23)
>  #define SUN4I_HDMI_PAD_CTRL1_AMPCK_OPT   BIT(22)
>  #define SUN4I_HDMI_PAD_CTRL1_EMP_OPT BIT(20)
>  #define SUN4I_HDMI_PAD_CTRL1_EMPCK_OPT   BIT(19)
> +#define SUN4I_HDMI_PAD_CTRL1_PWSCK   BIT(18)
> +#define SUN4I_HDMI_PAD_CTRL1_PWSDT   BIT(17)
>  #define SUN4I_HDMI_PAD_CTRL1_REG_DEN BIT(15)
>  #define SUN4I_HDMI_PAD_CTRL1_REG_DENCK   BIT(14)
>  #define SUN4I_HDMI_PAD_CTRL1_REG_EMP(n)  (((n) & 7) << 10)
> diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c 
> b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> index 9ded40aaed32..e9abf93eb41c 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> @@ -293,6 +293,109 @@ static const struct drm_connector_helper_funcs 
> sun4i_hdmi_connector_helper_funcs
>   .get_modes  = sun4i_hdmi_get_modes,
>  };
>  
> +static int sun6i_hdmi_read_sub_block(struct sun4i_hdmi *hdmi,
> +  unsigned int blk, unsigned int offset,
> +  u8 *buf, unsigned int count)
> +{
> + unsigned long reg;
> + int i;
> +
> + reg = readl(hdmi->base + SUN6I_HDMI_DDC_FIFO_CTRL_REG);
> + writel(reg | SUN6I_HDMI_DDC_FIFO_CTRL_CLEAR,
> +hdmi->base + SUN6I_HDMI_DDC_FIFO_CTRL_REG);
> + writel(SUN6I_HDMI_DDC_ADDR_SEGMENT(offset >> 8) |
> +SUN6I_HDMI_DDC_ADDR_EDDC(DDC_SEGMENT_ADDR << 1) |
> +SUN6I_HDMI_DDC_ADDR_OFFSET(offset) |
> +SUN6I_HDMI_DDC_ADDR_SLAVE(DDC_ADDR),
> +hdmi->base + SUN6I_HDMI_DDC_ADDR_REG);
> +
> + writel(SUN6I_HDMI_DDC_CMD_EXPLICIT_EDDC_READ |
> +SUN6I_HDMI_DDC_CMD_BYTE_COUNT(count),
> +hdmi->base + SUN6I_HDMI_DDC_CMD_REG);
> +
> + reg = readl(hdmi->base + SUN6I_HDMI_DDC_CTRL_REG);
> + writel(reg | SUN6I_HDMI_DDC_CTRL_START_CMD,
> +hdmi->base + SUN6I_HDMI_DDC_CTRL_REG);
> +
> + if (readl_poll_timeout(hdmi->base + SUN6I_HDMI_DDC_CTRL_REG, reg,
> +!(reg & SUN6I_HDMI_DDC_CTRL_START_CMD),
> +100, 10))
> + return -EIO;
> +
> + for (i = 0; i < count; i++)
> + buf[i] = readb(hdmi->base + SUN6I_HDMI_DDC_FIFO_DATA_REG);
> +
> + return 0;
> +}
> +
> +static int sun6i_hdmi_read_edid_block(void *data, u8 *buf, unsigned int blk,
> +   size_t length)
> +{
> + struct sun4i_hdmi *hdmi = data;
> + int retry = 2, i;
> +
> + do {
> + for (i = 0; i < length; i += SUN4I_HDMI_DDC_FIFO_SIZE) {
> + unsigned char offset = blk * EDID_LENGTH + i;
> + unsigned int count = min((unsigned 
> int)SUN4I_HDMI_DDC_FIFO_SIZE,
> +  length - i);
> + int ret;
> +
> + ret = sun6i_hdmi_read_sub_block(hdmi, blk, offset,
> + buf + i, count);
> + if (ret)
> + return ret;
> + }
> + } while (!drm_edid_block_valid(buf, blk, true, NULL) && (retry--));
> +
> + return 0;
> +}
> +
> +static int sun6i_hdmi_get_modes(struct drm_connector *connector)
> +{
> + struct sun4i_hdmi *hdmi = drm_connector_to_sun4i_hdmi(connector);
> + u32 reg;
> + struct edid *edid;
> + int ret;
> +
> + clk_set_rate(hdmi->ddc_clk, 10);
> + clk_prepare_enable(hdmi->ddc_clk);
> +
> + /* Reset i2c controller */
> + writel(SUN6I_HDMI_DDC_CTRL_ENABLE | SUN6I_HDMI_DDC_CTRL_RESET |
> +SUN6I_HDMI_DDC_CTRL_SDA_ENABLE |
> +SUN6I_HDMI_DDC_CTRL_SCL_ENABLE,
> +hdmi->base + SUN6I_HDMI_DDC_CTRL_REG);
> + if (readl_poll_timeout(hdmi->base + SUN6I_HDMI_DDC_CTRL_REG, reg,
> +  

Re: [PATCH 13/19] drm/sun4i: hdmi: Add support for controller hardware variants

[Maxime Ripard]

On Fri, Jun 02, 2017 at 06:10:18PM +0800, Chen-Yu Tsai wrote:
> The HDMI controller found in earlier Allwinner SoCs have slight
> differences:
> 
>   - Need different initial values for the PLL related registers
> 
>   - Different behavior of the DDC and TMDS clocks
> 
>   - Different register layout for the DDC portion
> 
>   - Separate DDC parent clock on the A31
> 
>   - Explicit reset control
> 
> The clock variants are supported within their implementations,
> which only expose a create function for each variant.
> 
> The different layout of the DDC registers necessitates a separate
> version of struct drm_connector_helper_funcs.
> 
> A new variant data structure is created to store pointers to the
> above functions, structures, and the different initial values.
> Another flag notates whether there is a separate DDC parent clock.
> If not, the TMDS clock is passed to the DDC clock create function,
> as before.
> 
> Signed-off-by: Chen-Yu Tsai 
> ---
>  drivers/clk/sunxi-ng/ccu-sun6i-a31.c   |   2 +-
>  drivers/gpu/drm/sun4i/sun4i_hdmi.h |   8 +++
>  drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 114 
> ++---
>  3 files changed, 100 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/clk/sunxi-ng/ccu-sun6i-a31.c 
> b/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
> index 4d6078fca9ac..e48186985a51 100644
> --- a/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
> +++ b/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
> @@ -610,7 +610,7 @@ static SUNXI_CCU_M_WITH_MUX_GATE(hdmi_clk, "hdmi", 
> lcd_ch1_parents,
>  
>  static SUNXI_CCU_GATE(hdmi_ddc_clk, "hdmi-ddc", "osc24M", 0x150, BIT(30), 0);
>  
> -static SUNXI_CCU_GATE(ps_clk, "ps", "lcd1-ch1", 0x140, BIT(31), 0);
> +static SUNXI_CCU_GATE(ps_clk, "ps", "lcd1-ch1", 0x154, BIT(31), 0);

Unrelated change?

>  
>  static const char * const mbus_parents[] = { "osc24M", "pll-periph",
>"pll-ddr" };
> diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi.h 
> b/drivers/gpu/drm/sun4i/sun4i_hdmi.h
> index c39c2a245339..c63d0bd95963 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_hdmi.h
> +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi.h
> @@ -155,6 +155,8 @@ enum sun4i_hdmi_pkt_type {
>   SUN4I_HDMI_PKT_END = 15,
>  };
>  
> +struct sun4i_hdmi_variant;
> +
>  struct sun4i_hdmi {
>   struct drm_connectorconnector;
>   struct drm_encoder  encoder;
> @@ -162,9 +164,13 @@ struct sun4i_hdmi {
>  
>   void __iomem*base;
>  
> + /* Reset control */
> + struct reset_control*reset;
> +
>   /* Parent clocks */
>   struct clk  *bus_clk;
>   struct clk  *mod_clk;
> + struct clk  *ddc_parent_clk;
>   struct clk  *pll0_clk;
>   struct clk  *pll1_clk;
>  
> @@ -175,6 +181,8 @@ struct sun4i_hdmi {
>   struct sun4i_drv*drv;
>  
>   boolhdmi_monitor;
> +
> + const struct sun4i_hdmi_variant *variant;
>  };
>  
>  int sun4i_ddc_create(struct sun4i_hdmi *hdmi, struct clk *clk);
> diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c 
> b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> index 457614073501..9ded40aaed32 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> @@ -20,8 +20,10 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
> +#include 
>  
>  #include "sun4i_backend.h"
>  #include "sun4i_crtc.h"
> @@ -315,6 +317,56 @@ static const struct drm_connector_funcs 
> sun4i_hdmi_connector_funcs = {
>   .atomic_destroy_state   = drm_atomic_helper_connector_destroy_state,
>  };
>  
> +struct sun4i_hdmi_variant {
> + const struct drm_connector_helper_funcs *connector_helpers;
> + int (*ddc_create)(struct sun4i_hdmi *hdmi, struct clk *clk);
> + int (*tmds_create)(struct sun4i_hdmi *hdmi);
> + bool has_ddc_parent_clk;
> + bool has_reset_control;
> +
> + u32 pad_ctrl0_init_val;
> + u32 pad_ctrl1_init_val;
> + u32 pll_ctrl_init_val;
> +};
> +
> +#define SUN4I_HDMI_PAD_CTRL1_MASK(GENMASK(24, 7) | GENMASK(5, 0))
> +#define SUN4I_HDMI_PLL_CTRL_MASK (GENMASK(31, 8) | GENMASK(3, 0))
> +
> +static const struct sun4i_hdmi_variant sun5i_variant = {
> + .connector_helpers  = _hdmi_connector_helper_funcs,
> + .ddc_create = sun4i_ddc_create,
> + .tmds_create= sun4i_tmds_create,

If we store the variants info for those clocks in that structure, we
don't need those functions anymore. This would be cleaner imho.

> + .has_ddc_parent_clk = false,
> + .has_reset_control  = false,

Those two are the default values


Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [PATCH 12/19] drm/sun4i: hdmi: Support the DDC clock in the A31's HDMI controller

[Maxime Ripard]

On Fri, Jun 02, 2017 at 06:10:17PM +0800, Chen-Yu Tsai wrote:
> On the A31, the HDMI DDC block is different from the one in the
> other SoCs. As far as the DDC clock goes, it has no pre-divider,
> as it is clocked from a slower parent clock, not the TMDS clock.
> The divider offset from the register value is different. And the
> clock control register is at a different offset.
> 
> This patch adds support for this variant.
> 
> Signed-off-by: Chen-Yu Tsai 
> ---
>  drivers/gpu/drm/sun4i/sun4i_hdmi.h |  1 +
>  drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c | 11 +++
>  2 files changed, 12 insertions(+)
> 
> diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi.h 
> b/drivers/gpu/drm/sun4i/sun4i_hdmi.h
> index 08c514672fd3..c39c2a245339 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_hdmi.h
> +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi.h
> @@ -178,6 +178,7 @@ struct sun4i_hdmi {
>  };
>  
>  int sun4i_ddc_create(struct sun4i_hdmi *hdmi, struct clk *clk);
> +int sun6i_ddc_create(struct sun4i_hdmi *hdmi, struct clk *clk);
>  int sun4i_tmds_create(struct sun4i_hdmi *hdmi);
>  int sun6i_tmds_create(struct sun4i_hdmi *hdmi);
>  
> diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c 
> b/drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c
> index 9a6b6243e977..b1395e7b242c 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c
> @@ -151,3 +151,14 @@ int sun4i_ddc_create(struct sun4i_hdmi *hdmi, struct clk 
> *parent)
>  {
>   return _sun4i_ddc_create(hdmi, parent, _variant);
>  }
> +
> +static const struct sun4i_ddc_variant sun6i_variant = {
> + .reg_offset = SUN6I_HDMI_DDC_CLK_REG,

This one should be handled through a regmap_field.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [PATCH 10/19] drm/sun4i: hdmi: Rename internal DDC clock to avoid name collision

[Maxime Ripard]

On Fri, Jun 02, 2017 at 06:10:15PM +0800, Chen-Yu Tsai wrote:
> The DDC parent clock on the A31 SoC is also conveniently named
> "hdmi-ddc", which results in a name collision when the hdmi driver
> registers its internal DDC divider clock.
> 
> Rename the internal clock to "hdmi-ddc-divider".
> 
> Signed-off-by: Chen-Yu Tsai 
> ---
>  drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c 
> b/drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c
> index e1071838f487..9a6b6243e977 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c
> @@ -125,7 +125,7 @@ static int _sun4i_ddc_create(struct sun4i_hdmi *hdmi, 
> struct clk *parent,
>   if (!ddc)
>   return -ENOMEM;
>  
> - init.name = "hdmi-ddc";
> + init.name = "hdmi-ddc-divider";

Can't we rename the CCU clock instead? Having the clock called
hdmi-ddc being the actual clock output on the DDC bus feels more
natural.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [PATCH 02/19] drm/sun4i: add components in two passes with encoders added in second pass

[Maxime Ripard]

On Fri, Jun 02, 2017 at 06:10:07PM +0800, Chen-Yu Tsai wrote:
> The encoder drivers use drm_of_find_possible_crtcs to get upstream
> crtcs from the device tree using of_graph. For the results to be
> correct, encoders must be probed/bound after _all_ crtcs have been
> created. The existing code uses a depth first recursive traversal
> of the of_graph, which means the encoders downstream of the TCON
> get add right after the first TCON. The second TCON or CRTC will
> never be properly associated with encoders connected to it.
> 
> Other platforms, such as Rockchip, deal with this by probing all
> crtcs first, then all subsequent components. This is easy to do
> since the crtcs correspond to just one device node, and are the
> first nodes in the pipeline.
> 
> However with Allwinner SoCs, the function of the CRTC is split between
> the display backend (DE 1.0) or mixer (DE 2.0), which does scan-out
> and compositing, and the TCON, which generating the display timing
> signals. Further complicating the process, there may be a Dynamic Range
> Controller between the backend and the TCON. Also, the backend is
> preceded by the frontend, with a Display Enhancement Unit possibly
> in between.
> 
> One solution would be, instead of a depth first traversal of the
> component of_graph, we do a breadth first traversal, so that components
> at the same depth are grouped together. This however requires us to
> implement extra code for a queue structure that is only used here.
> 
> Instead, since we can identify TCON device nodes, and since the
> component system can gracefully deal with duplicate entries, we can add
> components in two passes, using the existing recursive depth code. The
> first pass stops right after the TCON is added. The second pass will
> re-add all components up to the TCON, but these will be skipped since
> they will have already been bound with the entries from the first pass.
> The encoders added in the second pass will be the last entries in the
> list.
> 
> Signed-off-by: Chen-Yu Tsai 

This commit log is great. So great actually that it should be a
comment in the code ;)

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

[PULL] drm-misc-fixes

[Sean Paul]

Hi Dave,
Here's this week's fixes pull. Most noteworthy is the drm_unplug_dev change.
We've previously had discussion around cleanup on unplug for rockchip, but that
was mostly an academic issue (they wanted to unbind/bind at runtime). At the
time, this usecase was determined not to warrant the complexity required to fix
it, however now that we're seeing normal usecase issues, it's worth taking a
deeper dive (ie: find a longer term fix).

drm-misc-fixes-2017-06-02:
Core Changes:
- Grab locks in drm_atomic_helper_resume() (Daniel)
- Fix oops when unplugging USB device (expand cleanup in drm_unplug_dev) (Hans)

Driver Changes:
- rockchip: Don't output 10-bit format to 8-bit encoders (Mark)

Cc: Mark yao 
Cc: Daniel Vetter 
Cc: Hans de Goede 

Cheers, Sean


The following changes since commit 82bc9a42cf854fdf63155759c0aa790bd1f361b0:

  drm/gma500/psb: Actually use VBT mode when it is found (2017-05-23 22:01:07 
+0200)

are available in the git repository at:

  git://anongit.freedesktop.org/git/drm-misc tags/drm-misc-fixes-2017-06-02

for you to fetch changes up to 75fb636324a839c2c31be9f81644034c6142e469:

  drm: Fix oops + Xserver hang when unplugging USB drm devices (2017-06-02 
11:09:35 -0400)


Core Changes:
- Grab locks in drm_atomic_helper_resume() (Daniel)
- Fix oops when unplugging USB device (expand cleanup in drm_unplug_dev) (Hans)

Driver Changes:
- rockchip: Don't output 10-bit format to 8-bit encoders (Mark)

Cc: Mark yao 
Cc: Daniel Vetter 
Cc: Hans de Goede 


Daniel Vetter (1):
  drm: Fix locking in drm_atomic_helper_resume

Hans de Goede (1):
  drm: Fix oops + Xserver hang when unplugging USB drm devices

Mark yao (1):
  drm/rockchip: Correct vop out_mode configure

 drivers/gpu/drm/drm_atomic_helper.c | 11 +++
 drivers/gpu/drm/drm_drv.c   |  7 ++-
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 12 
 drivers/gpu/drm/rockchip/cdn-dp-core.c  |  9 ++---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  8 
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h |  3 +++
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c |  2 ++
 7 files changed, 32 insertions(+), 20 deletions(-)

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/1] e1000e: Undo e1000e_pm_freeze if __e1000_shutdown fails

[David Miller]

From: Jani Nikula 
Date: Wed, 31 May 2017 18:50:43 +0300

> From: Chris Wilson 
> 
> An error during suspend (e100e_pm_suspend),
 ...
> lead to complete failure:
 ...
> The unwind failures stems from commit 2800209994f8 ("e1000e: Refactor PM
> flows"), but it may be a later patch that introduced the non-recoverable
> behaviour.
> 
> Fixes: 2800209994f8 ("e1000e: Refactor PM flows")
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99847
> Cc: Tvrtko Ursulin 
> Cc: Jeff Kirsher 
> Cc: Dave Ertman 
> Cc: Bruce Allan 
> Cc: intel-wired-...@lists.osuosl.org
> Cc: net...@vger.kernel.org
> Signed-off-by: Chris Wilson 
> [Jani: bikeshed repainted]
> Signed-off-by: Jani Nikula 

Jeff, please make sure this gets submitted to me soon.

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

[Bug 99349] Failed to build shader (translation from TGSI)

[bugzilla-daemon]

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

--- Comment #12 from Gert Wollny  ---
Created attachment 131683
  --> https://bugs.freedesktop.org/attachment.cgi?id=131683=edit
Patch proposed on mesa-dev to work around too many temporaries

-- 
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] drm: remove writeq/readq function definitions

[Sean Paul]

On Fri, Jun 02, 2017 at 01:25:10PM +0200, Corentin Labbe wrote:
> Instead of rewriting write/readq, use linux/io-64-nonatomic-lo-hi.h which
> already have them.
> 
> Signed-off-by: Corentin Labbe 

Applied to drm-misc-next

Thanks,

Sean

> ---
>  include/drm/drm_os_linux.h | 14 +-
>  1 file changed, 1 insertion(+), 13 deletions(-)
> 
> diff --git a/include/drm/drm_os_linux.h b/include/drm/drm_os_linux.h
> index 35e1482ba8a1..10122353b744 100644
> --- a/include/drm/drm_os_linux.h
> +++ b/include/drm/drm_os_linux.h
> @@ -6,19 +6,7 @@
>  #include  /* For task queue support */
>  #include 
>  #include 
> -
> -#ifndef readq
> -static inline u64 readq(void __iomem *reg)
> -{
> - return ((u64) readl(reg)) | (((u64) readl(reg + 4UL)) << 32);
> -}
> -
> -static inline void writeq(u64 val, void __iomem *reg)
> -{
> - writel(val & 0x, reg);
> - writel(val >> 32, reg + 0x4UL);
> -}
> -#endif
> +#include 
>  
>  /** Current process ID */
>  #define DRM_CURRENTPID   task_pid_nr(current)
> -- 
> 2.13.0

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: Fix oops + Xserver hang when unplugging USB drm devices

[Sean Paul]

On Thu, Jun 01, 2017 at 01:14:56PM +0100, Chris Wilson wrote:
> On Thu, Jun 01, 2017 at 01:54:30PM +0200, Hans de Goede wrote:
> > commit a39be606f99d ("drm: Do a full device unregister when unplugging")
> > causes backtraces like this one when unplugging an usb drm device while
> > it is in use:
> > 
> > usb 2-3: USB disconnect, device number 25
> > [ cut here ]
> > WARNING: CPU: 0 PID: 242 at drivers/gpu/drm/drm_mode_config.c:424
> >drm_mode_config_cleanup+0x220/0x280 [drm]
> > ...
> > RIP: 0010:drm_mode_config_cleanup+0x220/0x280 [drm]
> > ...
> > Call Trace:
> >  gm12u320_modeset_cleanup+0xe/0x10 [gm12u320]
> >  gm12u320_driver_unload+0x35/0x70 [gm12u320]
> >  drm_dev_unregister+0x3c/0xe0 [drm]
> >  drm_unplug_dev+0x12/0x60 [drm]
> >  gm12u320_usb_disconnect+0x36/0x40 [gm12u320]
> >  usb_unbind_interface+0x72/0x280
> >  device_release_driver_internal+0x158/0x210
> >  device_release_driver+0x12/0x20
> >  bus_remove_device+0x104/0x180
> >  device_del+0x1d2/0x350
> >  usb_disable_device+0x9f/0x270
> >  usb_disconnect+0xc6/0x260
> > ...
> > [drm:drm_mode_config_cleanup [drm]] *ERROR* connector Unknown-1 leaked!
> > [ cut here ]
> > WARNING: CPU: 0 PID: 242 at drivers/gpu/drm/drm_mode_config.c:458
> >drm_mode_config_cleanup+0x268/0x280 [drm]
> > ...
> > 
> > ---[ end trace 80df975dae439ed6 ]---
> > general protection fault:  [#1] SMP
> > ...
> > Call Trace:
> >  ? __switch_to+0x225/0x450
> >  drm_mode_rmfb_work_fn+0x55/0x70 [drm]
> >  process_one_work+0x193/0x3c0
> >  worker_thread+0x4a/0x3a0
> > ...
> > RIP: drm_framebuffer_remove+0x62/0x3f0 [drm] RSP: b776c39dfd98
> > ---[ end trace 80df975dae439ed7 ]---
> > 
> > After which the system is unusable this is caused by drm_dev_unregister
> > getting called immediately on unplug, which calls the drivers unload
> > function which calls drm_mode_config_cleanup which removes the framebuffer
> > object while userspace is still holding a reference to it.
> > 
> > Reverting commit a39be606f99d ("drm: Do a full device unregister
> > when unplugging") leads to the following oops on unplug instead,
> > when userspace closes the last fd referencing the drm_dev:
> > 
> > sysfs group 'power' not found for kobject 'card1-Unknown-1'
> > [ cut here ]
> > WARNING: CPU: 0 PID: 2459 at fs/sysfs/group.c:237
> >sysfs_remove_group+0x80/0x90
> > ...
> > RIP: 0010:sysfs_remove_group+0x80/0x90
> > ...
> > Call Trace:
> >  dpm_sysfs_remove+0x57/0x60
> >  device_del+0xfd/0x350
> >  device_unregister+0x1a/0x60
> >  drm_sysfs_connector_remove+0x39/0x50 [drm]
> >  drm_connector_unregister+0x5a/0x70 [drm]
> >  drm_connector_unregister_all+0x45/0xa0 [drm]
> >  drm_modeset_unregister_all+0x12/0x30 [drm]
> >  drm_dev_unregister+0xca/0xe0 [drm]
> >  drm_put_dev+0x32/0x60 [drm]
> >  drm_release+0x2f3/0x380 [drm]
> >  __fput+0xdf/0x1e0
> > ...
> > ---[ end trace ecfb91ac85688bbe ]---
> > BUG: unable to handle kernel NULL pointer dereference at 00a8
> > IP: down_write+0x1f/0x40
> > ...
> > Call Trace:
> >  debugfs_remove_recursive+0x55/0x1b0
> >  drm_debugfs_connector_remove+0x21/0x40 [drm]
> >  drm_connector_unregister+0x62/0x70 [drm]
> >  drm_connector_unregister_all+0x45/0xa0 [drm]
> >  drm_modeset_unregister_all+0x12/0x30 [drm]
> >  drm_dev_unregister+0xca/0xe0 [drm]
> >  drm_put_dev+0x32/0x60 [drm]
> >  drm_release+0x2f3/0x380 [drm]
> >  __fput+0xdf/0x1e0
> > ...
> > ---[ end trace ecfb91ac85688bbf ]---
> > 
> > This is caused by the revert moving back to drm_unplug_dev calling
> > drm_minor_unregister which does:
> > 
> > device_del(minor->kdev);
> > dev_set_drvdata(minor->kdev, NULL); /* safety belt */
> > drm_debugfs_cleanup(minor);
> > 
> > Causing the sysfs entries to already be removed even though we still
> > have references to them in e.g. drm_connector.
> > 
> > Note we must call drm_minor_unregister to notify userspace of the unplug
> > of the device, so calling drm_dev_unregister is not completely wrong the
> > problem is that drm_dev_unregister does too much.
> > 
> > This commit fixes drm_unplug_dev by not only reverting
> > commit a39be606f99d ("drm: Do a full device unregister when unplugging")
> > but by also adding a call to drm_modeset_unregister_all before the
> > drm_minor_unregister calls to make sure all sysfs entries are removed
> > before calling device_del(minor->kdev) thereby also fixing the second
> > set of oopses caused by just reverting the commit.
> 
> That really does sound like a step in the wrong direction though. But
> that seems to because of the call to driver->unload() from the middle of
> unregister that is catching me by surprise.
> 
> Regression fix trumps niceties, so
> Reviewed-by: Chris Wilson 

Indeed it does seem like we'll need to sort this out, but agreed let's
put out the fire before renovating the house.

Applied to -misc-fixes

Sean


> 
> Looks like about 50% of the remaining 

[Bug 101189] Latest git fails to compile with radeon

[bugzilla-daemon]

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

--- Comment #14 from Emil Velikov  ---
For anyone wondering why patches have not been merged, yet.

Patch 2/5 neuters the partial Opencl support in r600, in an attempt to untangle
the convoluted dependencies. A few people are unhappy about it (understandably
so) and I've not pushed the patches so that they can resolve this better.

-- 
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 libdrm 2/2] headers: sync drm_sarea.h with airlied/drm-next

[Emil Velikov]

On 31 May 2017 at 16:10, Eric Engestrom  wrote:
> Adds the C++ extern guards from
> ebbb0e5cfd2ceb1150b1 drm: add extern C guard for the UAPI headers
>
> Generated using `make headers_install` from airlied/drm-next
> at commit 2a1720376adda5ecf8e636fbfb05339c7dad1c55
>
> Signed-off-by: Eric Engestrom 

Looks spot-on. Thanks!
For the series
Reviewed-by: Emil Velikov 

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

[Bug 194761] amdgpu driver breaks on Oland (SI)

[bugzilla-daemon]

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

Alex Deucher (alexdeuc...@gmail.com) changed:

   What|Removed |Added

 Attachment #256727|0   |1
is obsolete||

--- Comment #33 from Alex Deucher (alexdeuc...@gmail.com) ---
Created attachment 256831
  --> https://bugzilla.kernel.org/attachment.cgi?id=256831=edit
possible fix

Based on the feedback on this bug, it appears the logic should be reversed.  I
verified the vram width detection and that is correct.

-- 
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: [RFC 0/1] drm: Add Grain Media GM12U320 kms driver

[Emil Velikov]

Hi Marco,

Disclaimer: I'm mostly lurking around, barring the occasional patch so
please take my input with a grain of salt.

On 1 June 2017 at 23:46, Marco Diego Aurélio Mesquita
 wrote:
> Hi Devs!
>
> On Thu, Jun 1, 2017 at 8:59 AM, Hans de Goede  wrote:
>> Hi All,
>>
>> This is a resend of a patch I send out a while back, rebased on top
>> of 4.12-rc3. Back then the main comment was can you try to make this
>> driver use the drm_simple_kms_helper stuff? Unfortunately I have
>> not had time yet to look into this.
>>
>> Recently I've been contacted by Marco Diego Aurélio Mesquita (in the Cc)
>> who wants to work on getting this driver ready for mainline.
>>
>> He has has some questions / ideas about how to do this, so the
>> main reason for reposting this is to give him a thread to reply to
>> which provides context for his questions / ideas.
>>
>
> Hans, thanks for citing me.
>
> I'm an owner of a c120 miniprojector and would like to have this
> driver on mainline. As far as I could test (previous versions) it
> works reasonably well. From what I've seen[1], main obstacle for this
> driver been mainlined is the duplicated code from the udl driver.
>
> I've been playing with the code of this driver for a few days and I
> think that moving the common code between the udl and gm12u320 is a
> sound idea. It would greatly simplify the code of both drivers and
> both would become much smaller.
>
> Since I'm a coder myself, I would like to do it myself. Common code
> and differences from both drivers are very easy to spot and moving
> that into a common lib is something that I think a can do without any
> problems. The only reason I still have not started it is because I
> don't know if such work would be accepted.
>
> So, my question for you devs is: do you agree in factoring out some
> code from the udl driver so that both drivers (udl and gm12u320) can
> be smaller and simpler?
>
> If the answer to this question is yes, then I'll start coding and plan
> to comeback just to ask about minor details about what is really
> specific (even if equal) for any driver and what is not.
>
As Daniel mentioned in the earlier thread, factoring out things can be
done as a follow-up.
On the other hand, I _think_ that the blocker for this driver that
it's not doing atomic mode setting.

There's some example resources in Daniel's blog [1], although you
could skim through any of the existing drivers that were converted
recently (git log -p | grep DRIVER_ATOMIC)

-Emil

[1] http://blog.ffwll.ch/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 100979] Radeon r4 on a6-6310(BEEMA) APU hard lockup on hibernate and on second resume from suspend

[bugzilla-daemon]

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

--- Comment #6 from Daniel  ---
The situation over here is maybe related:

Hibernating/suspend-to-disk/s4 on my new AMD Carrizo box fails.

Upon hibernate, the system just reboots. No hints in the logs.

Suspend-to-RAM/S3 works fine.

When I disable amdgpu, hibernate & resume work fine.

Linux-4.11.3-gentoo-x86_64-AMD_A12-9800_RADEON_R7,_12_COMPUTE_CORES_4C+8G-with-gentoo-2.3,
sys-kernel/linux-firmware-20170519

Cheers, Daniel

-- 
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: iMac 10,1 with Ubuntu 16.04: black screen after suspend

[Alex Deucher]

On Fri, Jun 2, 2017 at 3:35 AM, Florian Echtler  wrote:
> On 01.06.2017 19:53, Alex Deucher wrote:
>> On Thu, Jun 1, 2017 at 4:27 AM, Florian Echtler  wrote:
>>> On 31.05.2017 14:57, Alex Deucher wrote:
 On Wed, May 31, 2017 at 5:21 AM, Lukas Wunner  wrote:
>>>
>>> Here's the (substantial) dmesg output, with drm.debug=0xf:
>>> http://floe.butterbrot.org/external/radeon/dmesg_after_suspend
>>>
>>> I haven't been able to find any references to link training, though.
>>
>> I need your dmesg from boot to confirm the display topology, but eDP
>> with r7xx asics was pretty rare.  I suspect your system just uses
>> LVDS; as such there is no link training involved.
>
> I've updated the trace with increased log_buf_len so nothing is truncated:
>
> http://floe.butterbrot.org/external/radeon/dmesg_after_suspend.txt
>
> (trace now contains a full boot including suspend and wakeup)
>
> However, what I'm seeing now does sound like the internal connection is 
> indeed eDP:
>
> [  166.816162] [drm:drm_mode_setcrtc] [CRTC:34:crtc-0]
> [  166.816166] [drm:drm_mode_setcrtc] [CONNECTOR:40:eDP-1]
> [  166.816167] [drm:drm_crtc_helper_set_config]
> [  166.816169] [drm:drm_crtc_helper_set_config] [CRTC:34:crtc-0] [FB:54]
> #connectors=1 (x y) (0 0)
> [  166.816170] [drm:drm_crtc_helper_set_config] crtc has no fb, full mode set
> [  166.816172] [drm:drm_mode_object_reference] OBJ ID: 40 (4)
> [  166.816173] [drm:drm_crtc_helper_set_config] encoder changed, full mode 
> switch
> [  166.816174] [drm:drm_crtc_helper_set_config] crtc changed, full mode switch
> [  166.816174] [drm:drm_crtc_helper_set_config] [CONNECTOR:40:eDP-1] to
> [CRTC:34:crtc-0]
> [  166.816175] [drm:drm_crtc_helper_set_config] attempting to set mode from
> userspace
> [  166.816177] [drm:drm_mode_debug_printmodeline] Modeline 65:"" 0 241500 2560
> 2608 2640 2720 1440 1443 1448 1481 0x0 0x9
> [  166.816180] [drm:radeon_encoder_set_active_device] setting active device to
> 0002 from 0002 0002 for encoder 3
> [  166.816183] [drm:radeon_get_monitor_bpc] eDP-1: Display bpc=8, returned 
> bpc=8
> [  166.816185] [drm:drm_detect_monitor_audio] Monitor has basic audio support
> [  166.816186] [drm:radeon_get_monitor_bpc] eDP-1: Display bpc=8, returned 
> bpc=8
> [  166.816188] [drm:drm_detect_monitor_audio] Monitor has basic audio support
> [  166.816192] [drm:drm_crtc_helper_set_mode] [CRTC:34:crtc-0]
> [  166.816208] [drm:radeon_get_monitor_bpc] eDP-1: Display bpc=8, returned 
> bpc=8
> [  166.816210] [drm:radeon_atom_encoder_dpms] encoder dpms 30 to mode 3, 
> devices
> 0008, active_devices 
> [  166.816213] [drm:radeon_atom_encoder_dpms] encoder dpms 22 to mode 3, 
> devices
> 0010, active_devices 
> [  166.816235] [drm:drm_detect_monitor_audio] Monitor has basic audio support
> [  166.816237] [drm:radeon_compute_pll_avivo] 36 - 36, pll dividers -
> fb: 80.0 ref: 2, post 3
> [  166.824475] done.

Yes it is eDP:

[3.197364] [drm] Radeon Display Connectors
[3.197365] [drm] Connector 0:
[3.197365] [drm]   DP-1
[3.197366] [drm]   HPD1
[3.197367] [drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48
0x7e4c 0x7e4c
[3.197367] [drm]   Encoders:
[3.197368] [drm] DFP1: INTERNAL_UNIPHY
[3.197369] [drm] Connector 1:
[3.197369] [drm]   eDP-1
[3.197370] [drm]   HPD2
[3.197371] [drm]   DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58
0x7e5c 0x7e5c
[3.197371] [drm]   Encoders:
[3.197372] [drm] LCD1: INTERNAL_UNIPHY
[3.197372] [drm] Connector 2:
[3.197372] [drm]   VGA-1
[3.197373] [drm]   DDC: 0x7f10 0x7f10 0x7f14 0x7f14 0x7f18 0x7f18
0x7f1c 0x7f1c
[3.197374] [drm]   Encoders:
[3.197374] [drm] CRT2: INTERNAL_KLDSCP_DAC2


>
> ... and a bit later:
>
> [  166.853787] [drm:radeon_dp_link_train_cr] clock recovery at voltage 0
> pre-emphasis 0
> [  166.853788] [drm:drm_detect_monitor_audio] Monitor has basic audio support
> [  166.855953] [drm:radeon_dp_link_train_ce] channel eq at voltage 0 
> pre-emphasis 0
>

Yes, the link training appears to complete fine.  I guess it's
something to do with the proprietary mux or backlight controls.

Alex

> Best, Florian
> --
> SENT FROM MY DEC VT50 TERMINAL
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Kernel panic on nouveau during boot on NVIDIA NV118 (GM108)

[Daniel Drake]

On Fri, Jun 2, 2017 at 4:01 AM, Chris Chiu  wrote:
> We are working with new desktop that have the NVIDIA NV118
> chipset.
>
> During boot, the display becomes unusable at the point where the
> nouveau driver loads. We have reproduced on 4.8, 4.11 and linux
> master (4.12-rc3).

To save digging into the attachment, here is the crash:

nouveau :01:00.0: pci: failed to adjust cap speed
nouveau :01:00.0: pci: failed to adjust lnkctl speed
nouveau :01:00.0: fb: 0 MiB DDR3
divide error:  [#1] SMP
Modules linked in: hid_generic usbmouse usbkbd usbhid i915 nouveau(+)
mxm_wmi i2c_algo_bit drm_kms_helper sdhci_pci syscopyarea sysfillrect
sysimgblt fb_sys_fops ttm sdhci drm ahci libahci wmi i2c_hid hid video
CPU: 3 PID: 200 Comm: systemd-udevd Not tainted 4.11.0-2-generic
#7+dev143.9f9ecd2beos3.2.2-Endless
Hardware name: Acer Aspire Z20-730/IPMAL-BR3, BIOS D01 07/07/2016
task: 8a3070288000 task.stack: a3eb4103c000
RIP: 0010:gf100_ltc_oneinit_tag_ram+0xba/0x100 [nouveau]
RSP: 0018:a3eb4103f6b8 EFLAGS: 00010206
RAX: 1000ffefdfff RBX: 8a306f915000 RCX: 8a3075570030
RDX:  RSI: dead0200 RDI: 8a307fd9b700
RBP: a3eb4103f6d0 R08: 0001e980 R09: 8a3077003900
R10: a3eb40cdbda0 R11: 8a307fd986a4 R12: 
R13: 00015fff R14: 8a306fa2e400 R15: 8a306f914e00
FS:  7f456d052900() GS:8a307fd8() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7fefceb1c020 CR3: 00026fbc5000 CR4: 003406e0
Call Trace:
 gm107_ltc_oneinit+0x7c/0x90 [nouveau]
 nvkm_ltc_oneinit+0x13/0x20 [nouveau]
 nvkm_subdev_init+0x50/0x210 [nouveau]
 nvkm_device_init+0x151/0x270 [nouveau]
 nvkm_udevice_init+0x48/0x60 [nouveau]
 nvkm_object_init+0x40/0x190 [nouveau]
 nvkm_ioctl_new+0x179/0x290 [nouveau]
 ? nvkm_client_notify+0x30/0x30 [nouveau]
 ? nvkm_udevice_rd08+0x30/0x30 [nouveau]
 nvkm_ioctl+0x168/0x240 [nouveau]
 ? nvif_client_init+0x42/0x110 [nouveau]
 nvkm_client_ioctl+0x12/0x20 [nouveau]
 nvif_object_ioctl+0x42/0x50 [nouveau]
 nvif_object_init+0xc2/0x130 [nouveau]
 nvif_device_init+0x12/0x30 [nouveau]
 nouveau_cli_init+0x15e/0x1d0 [nouveau]
 nouveau_drm_load+0x67/0x8b0 [nouveau]
 ? sysfs_do_create_link_sd.isra.2+0x70/0xb0
 drm_dev_register+0x148/0x1e0 [drm]
 drm_get_pci_dev+0xa0/0x160 [drm]
 nouveau_drm_probe+0x1d9/0x260 [nouveau]

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

[Bug 101274] [DC] Native display resolution blured even without graphical shell.

[bugzilla-daemon]

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

Alexandr  changed:

   What|Removed |Added

Summary|[DC] Native display |[DC] Native display
   |resolution blued even   |resolution blured even
   |without graphical shell.|without graphical shell.

-- 
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 4/4] drm/bridge: dw-hdmi: add cec driver

[Hans Verkuil]

On 06/02/17 14:07, Russell King - ARM Linux wrote:
> On Thu, Jun 01, 2017 at 10:31:10AM +0200, Hans Verkuil wrote:
>> This will change. Patches to fix the config handling are pending for 4.12.
>>
>> Here you can see the pending patches:
>> https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=drm-cec
>>
>> The patches from 'cec-notifier.h: handle unreachable CONFIG_CEC_CORE' to
>> 'cec: drop MEDIA_CEC_DEBUG' should all be merged in 4.12.
> 
> Hi Hans,
> 
> I'll wait until these have hit mainline before generating another
> patch series.  Do you have any idea when that might happen?

rc6? Hard to tell, I know Mauro is very busy so it can be difficult to
predict.

Regards,

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

[Bug 101262] Need help in running Dying Light

[bugzilla-daemon]

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

--- Comment #3 from Emil Velikov  ---
(In reply to Anthony Jagers from comment #2)
> My guess is I need help in tracing this.
> How would you trace a steam game?
See https://wiki.archlinux.org/index.php/Steam/Troubleshooting#Debugging_Steam

No idea which extension the game uses, so it may be that Mesa does not
implement it.


IIRC only GLX_MESA_query_renderer is done - see the output of glxinfo.
You'll get something like

Extended renderer info (GLX_MESA_query_renderer):
Vendor: Intel Open Source Technology Center (0x8086)
Device: Mesa DRI Intel(R) HD Graphics 5500 (Broadwell GT2)  (0x1616)
Version: 17.0.7
Accelerated: yes
Video memory: 3072MB
Unified memory: yes
Preferred profile: core (0x1)
Max core profile version: 4.5
Max compat profile version: 3.0
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.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

[PATCH v2 1/2] drm/bridge: Add Cadence DSI driver

[Boris Brezillon]

Add a driver for Cadence DPI -> DSI bridge.

Signed-off-by: Boris Brezillon 
---
Changes in v2:
- rebase on v4.12-rc1 and adapt to driver to the drm_bridge API changes
- return the correct error when devm_clk_get(sysclk) fails
- add missing depends on OF and select DRM_PANEL in the Kconfig entry
---
 drivers/gpu/drm/bridge/Kconfig|9 +
 drivers/gpu/drm/bridge/Makefile   |1 +
 drivers/gpu/drm/bridge/cdns-dsi.c | 1077 +
 3 files changed, 1087 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/cdns-dsi.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index f6968d3b4b41..7d24b0e11634 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -17,6 +17,15 @@ config DRM_ANALOGIX_ANX78XX
  the HDMI output of an application processor to MyDP
  or DisplayPort.
 
+config DRM_CDNS_DSI
+   tristate "Cadence DPI/DSI bridge"
+   select DRM_KMS_HELPER
+   select DRM_MIPI_DSI
+   select DRM_PANEL
+   depends on OF
+   help
+ Support Cadence DPI to DSI bridge.
+
 config DRM_DUMB_VGA_DAC
tristate "Dumb VGA DAC Bridge support"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 3fe2226ee2f2..73a3e32a8005 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -1,6 +1,7 @@
 ccflags-y := -Iinclude/drm
 
 obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
+obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
 obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
 obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o
 obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) += 
megachips-stdp-ge-b850v3-fw.o
diff --git a/drivers/gpu/drm/bridge/cdns-dsi.c 
b/drivers/gpu/drm/bridge/cdns-dsi.c
new file mode 100644
index ..70a4b91c80ee
--- /dev/null
+++ b/drivers/gpu/drm/bridge/cdns-dsi.c
@@ -0,0 +1,1077 @@
+/*
+ * Copyright: 2017 Cadence Design Systems, Inc.
+ *
+ * Author: Boris Brezillon 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#define MCTL_MAIN_DATA_CTL 0x4
+#define DIS_DYN_CLK_CTLBIT(30)
+#define IF_INTERLACED_EN(x)BIT(26 + (x))
+#define TE_MIPI_POLLING_EN BIT(25)
+#define TE_HW_POLLING_EN   BIT(24)
+#define DISP_EOT_GEN   BIT(18)
+#define HOST_EOT_GEN   BIT(17)
+#define DISP_GEN_CHECKSUM  BIT(16)
+#define DISP_GEN_ECC   BIT(15)
+#define BTA_EN BIT(14)
+#define READ_ENBIT(13)
+#define REG_TE_EN  BIT(12)
+#define IF_TE_EN(x)BIT(8 + (x))
+#define TBG_SELBIT(7)
+#define TVG_SELBIT(6)
+#define VID_EN BIT(5)
+#define IF_VID_SELECT(x)   ((x) << 2)
+#define IF_VID_SELECT_MASK GENMASK(4, 2)
+#define IF_VID_MODEBIT(1)
+#define LINK_ENBIT(0)
+
+#define MCTL_MAIN_PHY_CTL  0x8
+#define CLK_FORCE_STOP BIT(14)
+#define WAIT_BURST_TIME(x) ((x) << 10)
+#define DATA_ULPM_EN(x)BIT(6 + (x))
+#define CLK_ULPM_ENBIT(5)
+#define CLK_CONTINUOUS BIT(4)
+#define DATA_FORCE_STOPBIT(3)
+#define DATA_LANE_EN(x)BIT((x) - 1)
+
+#define MCTL_LANE_STS  0x10
+#define LANE_STATE_START   0
+#define LANE_STATE_IDLE1
+#define LANE_STATE_WRITE   2
+#define LANE_STATE_ULPM3
+#define LANE_STATE_READ4
+#define DATA_LANE_STATE(l, val)\
+   (((val) >> (2 + 2 * (l) + ((l) ? 1 : 0))) & GENMASK((l) ? 1 : 2, 0))
+#define CLK_LANE_STATE_HS  2
+#define CLK_LANE_STATE(val)((val) & GENMASK(1, 0))
+
+#define MCTL_DPHY_TIMEOUT1 0x14
+#define CLK_DIV(x) (x)
+#define HSTX_TIMEOUT(x)((x) << 4)
+
+#define MCTL_DPHY_TIMEOUT2 0x18
+#define LPRX_TIMEOUT(x) 

[PATCH v2 2/2] dt-bindings: drm/bridge: Document Cadence DSI bridge bindings

[Boris Brezillon]

Document the bindings used for the Cadence DSI bridge.

Signed-off-by: Boris Brezillon 
---
 .../bindings/display/bridge/cdns,dsi.txt   | 55 ++
 1 file changed, 55 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt

diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt 
b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt
new file mode 100644
index ..770c5c5b1e93
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt
@@ -0,0 +1,55 @@
+Cadence DSI bridge
+==
+
+The Cadence DSI bridge is a DPI to DSI bridge supporting up to 4 DSI lanes.
+
+Required properties:
+- compatible: should be set to "cdns,dsi".
+- reg: physical base address and length of the controller's registers.
+- interrupts: interrupt line connected to the DSI bridge.
+- clocks: DSI bridge clocks.
+- clock-names: must contain "pclk" and "sysclk".
+- phys: phandle link to the MIPI D-PHY controller.
+- phy-names: must contain "dphy".
+- #address-cells: must be set to 1.
+- #size-cells: must be set to 0.
+
+Required subnodes:
+- ports: Ports as described in Documentation/devicetree/bindings/graph.txt.
+  Currently contains a single input port at address 0 representing the DPI
+  input. Other ports will be added later to support the SDI inputs.
+  Port 0 should be connected to a DPI encoder output.
+- one subnode per DSI device connected on the DSI bus. Each DSI device should
+  contain a reg property encoding its address on the bus.
+
+Example:
+
+   dsi0: dsi@fd0c {
+   compatible = "cdns,dsi";
+   reg = <0x0 0xfd0c 0x0 0x1000>;
+   clocks = <>, <>;
+   clock-names = "pclk", "hclk";
+   interrupts = <1>;
+   phys = <>;
+   phy-names = "dphy";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   dsi0_dpi_input: endpoint {
+   remote-endpoint = <_dpi_output>;
+   };
+   };
+   };
+
+   panel: dsi-dev@0 {
+   compatible = "";
+   reg = <0>;
+   };
+   };
+
-- 
2.7.4

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

Re: [PATCH 1/2] drm/bridge: Add Cadence DSI driver

[Boris Brezillon]

On Fri, 2 Jun 2017 19:07:28 +0800
kbuild test robot <l...@intel.com> wrote:

> Hi Boris,
> 
> [auto build test ERROR on robh/for-next]
> [also build test ERROR on v4.12-rc3 next-20170602]
> [cannot apply to drm/drm-next drm-intel/for-linux-next]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
> 
> url:
> https://github.com/0day-ci/linux/commits/Boris-Brezillon/drm-bridge-Add-Cadence-DSI-driver/20170602-162006
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git 
> for-next
> config: i386-allmodconfig (attached as .config)
> compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=i386 
> 
> All errors (new ones prefixed by >>):
> 
>drivers/gpu/drm/bridge/cdns-dsi.c: In function 'cdns_dsi_bridge_attach':
> >> drivers/gpu/drm/bridge/cdns-dsi.c:550:27: error: passing argument 1 of 
> >> 'drm_bridge_attach' from incompatible pointer type 
> >> [-Werror=incompatible-pointer-types]  
>   ret = drm_bridge_attach(bridge->dev, output->bridge);
>   ^~
>In file included from include/drm/drm_crtc.h:43:0,
> from include/drm/drm_atomic_helper.h:31,
> from drivers/gpu/drm/bridge/cdns-dsi.c:19:
>include/drm/drm_bridge.h:210:5: note: expected 'struct drm_encoder *' but 
> argument is of type 'struct drm_device *'
> int drm_bridge_attach(struct drm_encoder *encoder, struct drm_bridge 
> *bridge,
> ^
> >> drivers/gpu/drm/bridge/cdns-dsi.c:550:9: error: too few arguments to 
> >> function 'drm_bridge_attach'  
>   ret = drm_bridge_attach(bridge->dev, output->bridge);
> ^
>In file included from include/drm/drm_crtc.h:43:0,
> from include/drm/drm_atomic_helper.h:31,
> from drivers/gpu/drm/bridge/cdns-dsi.c:19:
>include/drm/drm_bridge.h:210:5: note: declared here
> int drm_bridge_attach(struct drm_encoder *encoder, struct drm_bridge 
> *bridge,
> ^
>drivers/gpu/drm/bridge/cdns-dsi.c: In function 'cdns_dsi_bridge_detach':
> >> drivers/gpu/drm/bridge/cdns-dsi.c:566:3: error: implicit declaration of 
> >> function 'drm_bridge_detach' [-Werror=implicit-function-declaration]  
>   drm_bridge_detach(output->bridge);
>   ^
>cc1: some warnings being treated as errors
> 
> coccinelle warnings: (new ones prefixed by >>)
> 
> >> drivers/gpu/drm/bridge/cdns-dsi.c:980:5-11: inconsistent IS_ERR and 
> >> PTR_ERR on line 981.  
> 
> Please review and possibly fold the followup patch.
> 
> vim +/drm_bridge_attach +550 drivers/gpu/drm/bridge/cdns-dsi.c

Oops. Forgot to rebase on a v4.12-rc1 before sending the patches. I'll
a send new version fixing these errors.

Sorry for the noise.

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

[PATCH 4/4] drm/tinydrm: Add RePaper e-ink driver

[Noralf Trønnes]

This adds support for the Pervasive Displays RePaper branded displays.
The controller code is taken from the userspace driver available
through repaper.org. Only the V231 film is supported since the others
are EOL.

Signed-off-by: Noralf Trønnes 
---
 MAINTAINERS   |6 +
 drivers/gpu/drm/tinydrm/Kconfig   |   12 +
 drivers/gpu/drm/tinydrm/Makefile  |1 +
 drivers/gpu/drm/tinydrm/repaper.c | 1095 +
 4 files changed, 1114 insertions(+)
 create mode 100644 drivers/gpu/drm/tinydrm/repaper.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 757d487..800afa2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4446,6 +4446,12 @@ M:   Dave Airlie 
 S: Odd Fixes
 F: drivers/gpu/drm/mgag200/
 
+DRM DRIVER FOR PERVASIVE DISPLAYS REPAPER PANELS
+M: Noralf Trønnes 
+S: Maintained
+F: drivers/gpu/drm/tinydrm/repaper.c
+F: Documentation/devicetree/bindings/display/repaper.txt
+
 DRM DRIVER FOR RAGE 128 VIDEO CARDS
 S: Orphan / Obsolete
 F: drivers/gpu/drm/r128/
diff --git a/drivers/gpu/drm/tinydrm/Kconfig b/drivers/gpu/drm/tinydrm/Kconfig
index 3504c53..9596e44 100644
--- a/drivers/gpu/drm/tinydrm/Kconfig
+++ b/drivers/gpu/drm/tinydrm/Kconfig
@@ -19,3 +19,15 @@ config TINYDRM_MI0283QT
help
  DRM driver for the Multi-Inno MI0283QT display panel
  If M is selected the module will be called mi0283qt.
+
+config TINYDRM_REPAPER
+   tristate "DRM support for Pervasive Displays RePaper panels (V231)"
+   depends on DRM_TINYDRM && SPI
+   help
+ DRM driver for the following Pervasive Displays panels:
+ 1.44" TFT EPD Panel (E1144CS021)
+ 1.90" TFT EPD Panel (E1190CS021)
+ 2.00" TFT EPD Panel (E2200CS021)
+ 2.71" TFT EPD Panel (E2271CS021)
+
+ If M is selected the module will be called repaper.
diff --git a/drivers/gpu/drm/tinydrm/Makefile b/drivers/gpu/drm/tinydrm/Makefile
index 7a3604c..95bb4d4 100644
--- a/drivers/gpu/drm/tinydrm/Makefile
+++ b/drivers/gpu/drm/tinydrm/Makefile
@@ -5,3 +5,4 @@ obj-$(CONFIG_TINYDRM_MIPI_DBI)  += mipi-dbi.o
 
 # Displays
 obj-$(CONFIG_TINYDRM_MI0283QT) += mi0283qt.o
+obj-$(CONFIG_TINYDRM_REPAPER)  += repaper.o
diff --git a/drivers/gpu/drm/tinydrm/repaper.c 
b/drivers/gpu/drm/tinydrm/repaper.c
new file mode 100644
index 000..d1eaa88
--- /dev/null
+++ b/drivers/gpu/drm/tinydrm/repaper.c
@@ -0,0 +1,1095 @@
+/*
+ * DRM driver for Pervasive Displays RePaper branded e-ink panels
+ *
+ * Copyright 2013-2017 Pervasive Displays, Inc.
+ * Copyright 2017 Noralf Trønnes
+ *
+ * The driver supports:
+ * Material Film: Aurora Mb (V231)
+ * Driver IC: G2 (eTC)
+ *
+ * The controller code was taken from the userspace driver:
+ * https://github.com/repaper/gratis
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#define REPAPER_RID_G2_COG_ID  0x12
+
+enum repaper_model {
+   E1144CS021 = 1,
+   E1190CS021,
+   E2200CS021,
+   E2271CS021,
+};
+
+enum repaper_stage { /* Image pixel -> Display pixel */
+   REPAPER_COMPENSATE,  /* B -> W, W -> B (Current Image) */
+   REPAPER_WHITE,   /* B -> N, W -> W (Current Image) */
+   REPAPER_INVERSE, /* B -> N, W -> B (New Image) */
+   REPAPER_NORMAL   /* B -> B, W -> W (New Image) */
+};
+
+enum repaper_epd_border_byte {
+   REPAPER_BORDER_BYTE_NONE,
+   REPAPER_BORDER_BYTE_ZERO,
+   REPAPER_BORDER_BYTE_SET,
+};
+
+struct repaper_epd {
+   struct tinydrm_device tinydrm;
+   struct spi_device *spi;
+
+   struct gpio_desc *panel_on;
+   struct gpio_desc *border;
+   struct gpio_desc *discharge;
+   struct gpio_desc *reset;
+   struct gpio_desc *busy;
+
+   struct thermal_zone_device *thermal;
+
+   unsigned int height;
+   unsigned int width;
+   unsigned int bytes_per_scan;
+   const u8 *channel_select;
+   unsigned int stage_time;
+   unsigned int factored_stage_time;
+   bool middle_scan;
+   bool pre_border_byte;
+   enum repaper_epd_border_byte border_byte;
+
+   u8 *line_buffer;
+   void *current_frame;
+
+   bool enabled;
+   bool cleared;
+   bool partial;
+};
+
+static inline struct repaper_epd *
+epd_from_tinydrm(struct tinydrm_device *tdev)
+{
+   return container_of(tdev, struct repaper_epd, tinydrm);
+}
+
+static int repaper_spi_transfer(struct spi_device *spi, u8 header,
+   const void *tx, void *rx, size_t len)
+{
+   void *txbuf = NULL, *rxbuf = NULL;
+   struct spi_transfer tr[2] = {};
+   u8 

[PATCH 0/4] drm/tinydrm: Add support for Pervasive Displays RePaper monochrome e-ink panels

[Noralf Trønnes]

This adds support for the 1.44", 1.9", 2.0" and 2.7" Pervasive Diplays
monochrome e-ink panels. The code was taken from the userspace driver
available through repaper.org.

Monochrome
Since drm doesn't have support for monochrome, I have added a helper to
convert XRGB to greyscale8. XRGB is very common so that's why I
chose that format, but maybe some YUV format is better suited, I don't
know. There are some greyscale e-ink panels, so that's why I chose
greyscale instead of going directly to monochrome.

I have hacked together a python drm library to make it easy to use these
displays, mainly targeted at the maker community:
https://github.com/notro/pydrm

Noralf.

Noralf Trønnes (4):
  of: Add vendor prefix for Pervasive Displays
  dt-bindings: Add Pervasive Displays RePaper bindings
  drm/tinydrm: Add tinydrm_xrgb_to_gray8() helper
  drm/tinydrm: Add RePaper e-ink driver

 .../devicetree/bindings/display/repaper.txt|   52 +
 .../devicetree/bindings/vendor-prefixes.txt|1 +
 MAINTAINERS|6 +
 drivers/gpu/drm/tinydrm/Kconfig|   12 +
 drivers/gpu/drm/tinydrm/Makefile   |1 +
 drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c |   74 +-
 drivers/gpu/drm/tinydrm/repaper.c  | 1095 
 include/drm/tinydrm/tinydrm-helpers.h  |1 +
 8 files changed, 1240 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/display/repaper.txt
 create mode 100644 drivers/gpu/drm/tinydrm/repaper.c

-- 
2.7.4

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

[PATCH 2/4] dt-bindings: Add Pervasive Displays RePaper bindings

[Noralf Trønnes]

Add device-tree binding documentation for the 1.44", 1.9", 2.0" and 2.7"
display panels.

Signed-off-by: Noralf Trønnes 
---
 .../devicetree/bindings/display/repaper.txt| 52 ++
 1 file changed, 52 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/repaper.txt

diff --git a/Documentation/devicetree/bindings/display/repaper.txt 
b/Documentation/devicetree/bindings/display/repaper.txt
new file mode 100644
index 000..f5f9f9c
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/repaper.txt
@@ -0,0 +1,52 @@
+Pervasive Displays RePaper branded e-ink displays
+
+Required properties:
+- compatible:  "pervasive,e1144cs021" for 1.44" display
+   "pervasive,e1190cs021" for 1.9" display
+   "pervasive,e2200cs021" for 2.0" display
+   "pervasive,e2271cs021" for 2.7" display
+
+- panel-on-gpios:  Timing controller power control
+- discharge-gpios: Discharge control
+- reset-gpios: RESET pin
+- busy-gpios:  BUSY pin
+
+Required property for e2271cs021:
+- border-gpios:Border control
+
+The node for this driver must be a child node of a SPI controller, hence
+all mandatory properties described in ../spi/spi-bus.txt must be specified.
+
+Optional property:
+- pervasive,thermal-zone:  name of thermometer's thermal zone
+
+Example:
+
+   display_temp: lm75@48 {
+   compatible = "lm75b";
+   reg = <0x48>;
+   #thermal-sensor-cells = <0>;
+   };
+
+   thermal-zones {
+   display {
+   polling-delay-passive = <0>;
+   polling-delay = <0>;
+   thermal-sensors = <_temp>;
+   };
+   };
+
+   papirus27@0{
+   compatible = "pervasive,e2271cs021";
+   reg = <0>;
+
+   spi-max-frequency = <800>;
+
+   panel-on-gpios = < 23 0>;
+   border-gpios = < 14 0>;
+   discharge-gpios = < 15 0>;
+   reset-gpios = < 24 0>;
+   busy-gpios = < 25 0>;
+
+   pervasive,thermal-zone = "display";
+   };
-- 
2.7.4

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

[PATCH 3/4] drm/tinydrm: Add tinydrm_xrgb8888_to_gray8() helper

[Noralf Trønnes]

Drm has no monochrome or greyscale support so add a conversion
from the common format XR24.

Also reorder includes into the common order.

Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c | 74 +-
 include/drm/tinydrm/tinydrm-helpers.h  |  1 +
 2 files changed, 73 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c 
b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
index d4cda33..75808bb 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
@@ -7,13 +7,15 @@
  * (at your option) any later version.
  */
 
-#include 
-#include 
 #include 
+#include 
 #include 
 #include 
 #include 
 
+#include 
+#include 
+
 static unsigned int spi_max;
 module_param(spi_max, uint, 0400);
 MODULE_PARM_DESC(spi_max, "Set a lower SPI max transfer size");
@@ -181,6 +183,74 @@ void tinydrm_xrgb_to_rgb565(u16 *dst, void *vaddr,
 EXPORT_SYMBOL(tinydrm_xrgb_to_rgb565);
 
 /**
+ * tinydrm_xrgb_to_gray8 - Convert XRGB to grayscale
+ * @dst: 8-bit grayscale destination buffer
+ * @fb: DRM framebuffer
+ *
+ * Drm doesn't have native monochrome or grayscale support.
+ * Such drivers can announce the commonly supported XR24 format to userspace
+ * and use this function to convert to the native format.
+ *
+ * Monochrome drivers will use the most significant bit,
+ * where 1 means foreground color and 0 background color.
+ *
+ * ITU BT.601 is used for the RGB -> luma (brightness) conversion.
+ *
+ * Returns:
+ * Zero on success, negative error code on failure.
+ */
+int tinydrm_xrgb_to_gray8(u8 *dst, struct drm_framebuffer *fb)
+{
+   struct drm_gem_cma_object *cma_obj = drm_fb_cma_get_gem_obj(fb, 0);
+   struct dma_buf_attachment *import_attach = cma_obj->base.import_attach;
+   unsigned int x, y, pitch = fb->pitches[0];
+   int ret = 0;
+   void *buf;
+   u32 *src;
+
+   if (WARN_ON(fb->format->format != DRM_FORMAT_XRGB))
+   return -EINVAL;
+   /*
+* The cma memory is write-combined so reads are uncached.
+* Speed up by fetching one line at a time.
+*/
+   buf = kmalloc(pitch, GFP_KERNEL);
+   if (!buf)
+   return -ENOMEM;
+
+   if (import_attach) {
+   ret = dma_buf_begin_cpu_access(import_attach->dmabuf,
+  DMA_FROM_DEVICE);
+   if (ret)
+   goto err_free;
+   }
+
+   for (y = 0; y < fb->height; y++) {
+   src = cma_obj->vaddr + (y * pitch);
+   memcpy(buf, src, pitch);
+   src = buf;
+   for (x = 0; x < fb->width; x++) {
+   u8 r = (*src & 0x00ff) >> 16;
+   u8 g = (*src & 0xff00) >> 8;
+   u8 b =  *src & 0x00ff;
+
+   /* ITU BT.601: Y = 0.299 R + 0.587 G + 0.114 B */
+   *dst++ = (3 * r + 6 * g + b) / 10;
+   src++;
+   }
+   }
+
+   if (import_attach)
+   ret = dma_buf_end_cpu_access(import_attach->dmabuf,
+DMA_FROM_DEVICE);
+err_free:
+   kfree(buf);
+
+   return ret;
+}
+EXPORT_SYMBOL(tinydrm_xrgb_to_gray8);
+
+/**
  * tinydrm_of_find_backlight - Find backlight device in device-tree
  * @dev: Device
  *
diff --git a/include/drm/tinydrm/tinydrm-helpers.h 
b/include/drm/tinydrm/tinydrm-helpers.h
index 9b9b6cf..a6c387f 100644
--- a/include/drm/tinydrm/tinydrm-helpers.h
+++ b/include/drm/tinydrm/tinydrm-helpers.h
@@ -43,6 +43,7 @@ void tinydrm_swab16(u16 *dst, void *vaddr, struct 
drm_framebuffer *fb,
 void tinydrm_xrgb_to_rgb565(u16 *dst, void *vaddr,
struct drm_framebuffer *fb,
struct drm_clip_rect *clip, bool swap);
+int tinydrm_xrgb_to_gray8(u8 *dst, struct drm_framebuffer *fb);
 
 struct backlight_device *tinydrm_of_find_backlight(struct device *dev);
 int tinydrm_enable_backlight(struct backlight_device *backlight);
-- 
2.7.4

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

[PATCH 1/4] of: Add vendor prefix for Pervasive Displays

[Noralf Trønnes]

Pervasive Displays Inc. designs, develops, and manufactures low-power
electrophoretic (e-ink) display modules and supporting electronics for
commercial and industrial display applications.

Signed-off-by: Noralf Trønnes 
---
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index c03d201..6885c75 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -240,6 +240,7 @@ oxsemi  Oxford Semiconductor, Ltd.
 panasonic  Panasonic Corporation
 parade Parade Technologies Inc.
 pericomPericom Technology Inc.
+pervasive  Pervasive Displays, Inc.
 phytec PHYTEC Messtechnik GmbH
 picochip   Picochip Ltd
 pine64 Pine64
-- 
2.7.4

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

[PATCH] drm: remove writeq/readq function definitions

[Corentin Labbe]

Instead of rewriting write/readq, use linux/io-64-nonatomic-lo-hi.h which
already have them.

Signed-off-by: Corentin Labbe 
---
 include/drm/drm_os_linux.h | 14 +-
 1 file changed, 1 insertion(+), 13 deletions(-)

diff --git a/include/drm/drm_os_linux.h b/include/drm/drm_os_linux.h
index 35e1482ba8a1..10122353b744 100644
--- a/include/drm/drm_os_linux.h
+++ b/include/drm/drm_os_linux.h
@@ -6,19 +6,7 @@
 #include/* For task queue support */
 #include 
 #include 
-
-#ifndef readq
-static inline u64 readq(void __iomem *reg)
-{
-   return ((u64) readl(reg)) | (((u64) readl(reg + 4UL)) << 32);
-}
-
-static inline void writeq(u64 val, void __iomem *reg)
-{
-   writel(val & 0x, reg);
-   writel(val >> 32, reg + 0x4UL);
-}
-#endif
+#include 
 
 /** Current process ID */
 #define DRM_CURRENTPID task_pid_nr(current)
-- 
2.13.0

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

Re: [PATCH 1/2] drm/bridge: Add Cadence DSI driver

[kbuild test robot]

Hi Boris,

[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.12-rc3 next-20170602]
[cannot apply to drm/drm-next drm-intel/for-linux-next]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Boris-Brezillon/drm-bridge-Add-Cadence-DSI-driver/20170602-162006
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/bridge/cdns-dsi.c: In function 'cdns_dsi_bridge_attach':
>> drivers/gpu/drm/bridge/cdns-dsi.c:550:27: error: passing argument 1 of 
>> 'drm_bridge_attach' from incompatible pointer type 
>> [-Werror=incompatible-pointer-types]
  ret = drm_bridge_attach(bridge->dev, output->bridge);
  ^~
   In file included from include/drm/drm_crtc.h:43:0,
from include/drm/drm_atomic_helper.h:31,
from drivers/gpu/drm/bridge/cdns-dsi.c:19:
   include/drm/drm_bridge.h:210:5: note: expected 'struct drm_encoder *' but 
argument is of type 'struct drm_device *'
int drm_bridge_attach(struct drm_encoder *encoder, struct drm_bridge 
*bridge,
^
>> drivers/gpu/drm/bridge/cdns-dsi.c:550:9: error: too few arguments to 
>> function 'drm_bridge_attach'
  ret = drm_bridge_attach(bridge->dev, output->bridge);
^
   In file included from include/drm/drm_crtc.h:43:0,
from include/drm/drm_atomic_helper.h:31,
from drivers/gpu/drm/bridge/cdns-dsi.c:19:
   include/drm/drm_bridge.h:210:5: note: declared here
int drm_bridge_attach(struct drm_encoder *encoder, struct drm_bridge 
*bridge,
^
   drivers/gpu/drm/bridge/cdns-dsi.c: In function 'cdns_dsi_bridge_detach':
>> drivers/gpu/drm/bridge/cdns-dsi.c:566:3: error: implicit declaration of 
>> function 'drm_bridge_detach' [-Werror=implicit-function-declaration]
  drm_bridge_detach(output->bridge);
  ^
   cc1: some warnings being treated as errors

coccinelle warnings: (new ones prefixed by >>)

>> drivers/gpu/drm/bridge/cdns-dsi.c:980:5-11: inconsistent IS_ERR and PTR_ERR 
>> on line 981.

Please review and possibly fold the followup patch.

vim +/drm_bridge_attach +550 drivers/gpu/drm/bridge/cdns-dsi.c

   544  case CDNS_DSI_PANEL:
   545  ret = cdns_dsi_output_attach_panel(output);
   546  break;
   547  
   548  case CDNS_DSI_BRIDGE:
   549  output->bridge->encoder = bridge->encoder;
 > 550  ret = drm_bridge_attach(bridge->dev, output->bridge);
   551  break;
   552  
   553  default:
   554  ret = -ENOTSUPP;
   555  }
   556  
   557  return ret;
   558  }
   559  
   560  static void cdns_dsi_bridge_detach(struct drm_bridge *bridge)
   561  {
   562  struct cdns_dsi_input *input = bridge_to_cdns_dsi_input(bridge);
   563  struct cdns_dsi_output *output = input->dsi->output;
   564  
   565  if (output->type == CDNS_DSI_BRIDGE && output->bridge->dev)
 > 566  drm_bridge_detach(output->bridge);
   567  }
   568  
   569  static bool cdns_dsi_bridge_mode_fixup(struct drm_bridge *bridge,

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/bridge: fix odd_ptr_err.cocci warnings

[kbuild test robot]

drivers/gpu/drm/bridge/cdns-dsi.c:980:5-11: inconsistent IS_ERR and PTR_ERR on 
line 981.

 PTR_ERR should access the value just tested by IS_ERR

Semantic patch information:
 There can be false positives in the patch case, where it is the call to
 IS_ERR that is wrong.

Generated by: scripts/coccinelle/tests/odd_ptr_err.cocci

CC: Boris Brezillon 
Signed-off-by: Fengguang Wu 
---

Please take the patch only if it's a positive warning. Thanks!

 cdns-dsi.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpu/drm/bridge/cdns-dsi.c
+++ b/drivers/gpu/drm/bridge/cdns-dsi.c
@@ -978,7 +978,7 @@ static int cdns_dsi_drm_probe(struct pla
 
dsi->sysclk = devm_clk_get(>dev, "sysclk");
if (IS_ERR(dsi->sysclk))
-   return PTR_ERR(dsi->pclk);
+   return PTR_ERR(dsi->sysclk);
 
irq = platform_get_irq(pdev, 0);
if (irq < 0)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101278] Severe slowdown on Shadow of Mordor between 17.1.0 and 17.1.1

[bugzilla-daemon]

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

--- Comment #1 from nagrigoria...@gmail.com ---
Apologies, I forgot some important related details:

I'm on kernel 4.11.1-gentoo right now, but observed the same on 4.10.8
libdrm-2.4.80
llvm-4.0.0-r2
xorg-server-1.19.3
xf86-video-ati-7.9.0
using the "radeon" kernel module.

-- 
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 101278] Severe slowdown on Shadow of Mordor between 17.1.0 and 17.1.1

[bugzilla-daemon]

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

Bug ID: 101278
   Summary: Severe slowdown on Shadow of Mordor between 17.1.0 and
17.1.1
   Product: Mesa
   Version: 17.1
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: nagrigoria...@gmail.com
QA Contact: dri-devel@lists.freedesktop.org

Shadow of Mordor slowed down significantly for me on my notebook between Mesa
17.1.0 and 17.1.1

My system:
Gentoo Linux 64-bit
Dell Precision M4700
Intel i7-3720QM quad-core
16 Gig RAM
AMD FirePro M4000 (Cape Verde, 512su, 1GB DDR5 RAM, 675Mhz)

I then did a bisect to find the commit where the slowdown happened (used the
built-in benchmark tool manually, some custom medium-low settings):
35ec26bb00536639b9571f31d8e3f2bcbcfc32fb 30.31fps
ad3b5b7f5f7590fd4359ea3483e2309e4cebc472 18.12fps

So the commit that causes the big slowdown:
https://cgit.freedesktop.org/mesa/mesa/commit/?h=17.1=ad3b5b7f5f7590fd4359ea3483e2309e4cebc472
seems to be specific to SI, but appears to fix an issue in tessellation.
I double-checked, and tessellation is off in the game settings, so I'm
surprised this caused a performance difference.

-- 
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 v5 09/10] drm/atmel-hlcdc: Use crtc->mode_valid() callback

[Boris Brezillon]

On Thu, 25 May 2017 15:19:21 +0100
Jose Abreu  wrote:

> Now that we have a callback to check if crtc supports a given mode
> we can use it in atmel-hlcdc so that we restrict the number of probbed
> modes to the ones we can actually display.
> 
> Also, remove the mode_fixup() callback as this is no longer needed
> because mode_valid() will be called before.
> 
> NOTE: Not even compiled tested

Applied to drm-misc-next after fixing a compilation warning and
reformating to checkpatch happy.

Thanks,

Boris

> 
> Signed-off-by: Jose Abreu 
> Cc: Carlos Palminha 
> Cc: Daniel Vetter 
> Cc: Boris Brezillon 
> Cc: David Airlie 
> ---
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 9 -
>  1 file changed, 4 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c 
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> index 53bfa56..bdfe74e 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> @@ -140,13 +140,12 @@ static void atmel_hlcdc_crtc_mode_set_nofb(struct 
> drm_crtc *c)
>  cfg);
>  }
>  
> -static bool atmel_hlcdc_crtc_mode_fixup(struct drm_crtc *c,
> - const struct drm_display_mode *mode,
> - struct drm_display_mode *adjusted_mode)
> +static enum drm_mode_status atmel_hlcdc_crtc_mode_valid(struct drm_crtc *c,
> + const struct 
> drm_display_mode *mode)
>  {
>   struct atmel_hlcdc_crtc *crtc = drm_crtc_to_atmel_hlcdc_crtc(c);
>  
> - return atmel_hlcdc_dc_mode_valid(crtc->dc, adjusted_mode) == MODE_OK;
> + return atmel_hlcdc_dc_mode_valid(crtc->dc, mode);
>  }
>  
>  static void atmel_hlcdc_crtc_disable(struct drm_crtc *c)
> @@ -315,7 +314,7 @@ static void atmel_hlcdc_crtc_atomic_flush(struct drm_crtc 
> *crtc,
>  }
>  
>  static const struct drm_crtc_helper_funcs lcdc_crtc_helper_funcs = {
> - .mode_fixup = atmel_hlcdc_crtc_mode_fixup,
> + .mode_valid = atmel_hlcdc_crtc_mode_valid,
>   .mode_set = drm_helper_crtc_mode_set,
>   .mode_set_nofb = atmel_hlcdc_crtc_mode_set_nofb,
>   .mode_set_base = drm_helper_crtc_mode_set_base,

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

Re: [PATCH v6 5/5] drm/amdgpu: resize VRAM BAR for CPU access v2

[Christian König]

Hi Bjorn,

sorry for not responding earlier and thanks for picking this thread up 
again.


Am 01.06.2017 um 22:14 schrieb Bjorn Helgaas:

[+cc ADMGPU, DRM folks]

On Tue, May 09, 2017 at 06:49:07PM +0200, Christian König wrote:

[SNIP]
+/**
+ * amdgpu_resize_bar0 - try to resize BAR0
+ *
+ * @adev: amdgpu_device pointer
+ *
+ * Try to resize BAR0 to make all VRAM CPU accessible.
+ */
+void amdgpu_resize_bar0(struct amdgpu_device *adev)
+{
+   u64 space_needed = roundup_pow_of_two(adev->mc.real_vram_size);
+   u32 rbar_size = order_base_2(((space_needed >> 20) | 1)) -1;
+   u16 cmd;
+   int r;
+
+   /* Free the doorbell mapping, it most likely needs to move as well */
+   amdgpu_doorbell_fini(adev);
+   pci_release_resource(adev->pdev, 2);
+
+   /* Disable memory decoding while we change the BAR addresses and size */
+   pci_read_config_word(adev->pdev, PCI_COMMAND, );
+   pci_write_config_word(adev->pdev, PCI_COMMAND,
+ cmd & ~PCI_COMMAND_MEMORY);
+
+   r = pci_resize_resource(adev->pdev, 0, rbar_size);
+   if (r == -ENOSPC)
+   DRM_INFO("Not enough PCI address space for a large BAR.");
+   else if (r && r != -ENOTSUPP)
+   DRM_ERROR("Problem resizing BAR0 (%d).", r);
+
+   pci_write_config_word(adev->pdev, PCI_COMMAND, cmd);
+
+   /* When the doorbell BAR isn't available we have no chance of
+* using the device.
+*/
+   BUG_ON(amdgpu_doorbell_init(adev));

This amdgpu_doorbell_fini()/amdgpu_doorbell_init() thing doesn't look
right.  amdgpu_device_init() only calls amdgpu_doorbell_init() for
"adev->asic_type >= CHIP_BONAIRE", but we call it unconditionally
here.

This is the call graph:

   amdgpu_device_init
 adev->rmmio_base = pci_resource_start(adev->pdev, 5)   # 2 for < BONAIRE
 adev->rmmio = ioremap(adev->rmmio_base, ...)
 DRM_INFO("register mmio base: 0x%08X\n", (uint32_t)adev->rmmio_base)
 if (adev->asic_type >= CHIP_BONAIRE) {
   amdgpu_doorbell_init
adev->doorbell.base = pci_resource_start(adev->pdev, 2)
adev->doorbell.ptr = ioremap(adev->doorbell.base, ...)
 }
 amdgpu_init
   gmc_v7_0_sw_init  # gmc_v7_0_ip_funcs.sw_init
gmc_v7_0_mc_init
   + amdgpu_resize_bar0
   +   amdgpu_doorbell_fini
   +   pci_release_resource(adev->pdev, 2)
   +   pci_resize_resource(adev->pdev, 0, size)
   +   amdgpu_doorbell_init
  adev->mc.aper_base = pci_resource_start(adev->pdev, 0)

If "asic_type < CHIP_BONAIRE", we ioremapped BAR 2 in
amdgpu_device_init(), then we released the resource here and never
updated the ioremap.


The first hardware with a resizeable BAR I could find is a Tonga, and 
that is even a generation later than Bonaire.


So we are never going to call this code on earlier hardware generations.

But I think I will just move the asic_type check into the function to be 
absolute sure.



 From the PCI core perspective, it would be much cleaner to do the BAR
resize before the driver calls pci_enable_device().  If that could be
done, there would be no need for this sort of shutdown/reinit stuff
and we wouldn't have to worry about issues like these.  The amdgpu
init path is pretty complicated, so I don't know whether this is
possible.


I completely agree on this and it is actually the approach I tried first.

There are just two problems with this approach:
1. When the amdgpu driver is loaded there can already be the VGA 
console, Vesa or EFI driver active for the device and displaying the 
splash screen.


When we resize and most likely relocate the BAR while those drivers are 
active it will certainly cause problems.


What amdgpu does before trying to resize the BAR is kicking out other 
driver and making sure it has exclusive access to the hardware.


2. Without taking a look at the registers you don't know how much memory 
there actually is on the board.


We could always resize it to the maximum supported, but that would mean 
we could easily waste 128GB of address space while the hardware only has 
8GB of VRAM.


That would not necessarily hurt us when we have enough address space, 
but at least kind of sucks.



I would also like to simplify the driver usage model and get the
PCI_COMMAND_MEMORY twiddling into the PCI core instead of the driver.
Ideally, the driver would do something like this:

   pci_resize_resource(adev->pdev, 0, rbar_size);
   pci_enable_device(adev->pdev);

And the PCI core would be something along these lines:

   int pci_resize_resource(dev, bar, size)
   {
 if (pci_is_enabled(dev))
   return -EBUSY;

 pci_disable_decoding(dev);  # turn off MEM, IO decoding
 pci_release_resources(dev); # (all of them)
 err = pci_resize_bar(dev, bar, size); # change BAR size (only)
 if (err)
   return err;

 pci_assign_resources(dev);  # reassign all "dev" resources
 return 0;
   }

Re: [PATCH 4/4] drm/bridge: dw-hdmi: add cec driver

[Hans Verkuil]

On 06/02/17 11:15, Russell King - ARM Linux wrote:
> On Fri, Jun 02, 2017 at 06:02:28AM +0100, Jose Abreu wrote:
>> You should check that CEC is: not in standy, acknowledges
>> broadcast messages, signal free time is 5bit period, and not lost
>> arbitration, which basically means CEC_CTRL must be 0x2 and
>> IH_CEC_STAT0 must not have ARB_LOST set.
> 
> If ARB_LOST is set, that will trigger an interrupt, and the interrupt
> handler will clear the bit.  So all the time that the interrupt handler
> is present, ARB_LOST should be clear whenever we try to send a message.
> 
> When we enable the CEC interface, we zero the CEC_CTRL register, which
> takes the controller out of standby, and initialises the command
> register.
> 
> Bits 2:1 select the signal free time, and there's no requirement
> specified to require them to be set to '01' before writing the
> message - in fact, it's legal for them to be set to other values,
> particularly when retrying, which is something I've missed.
> 
>  2-1 Frame Type bit
>   FRAME_TYP
>  00Signal Free Time = 3-bit periods. Previous
>  attempt to send frame is unsuccessful.
>  01Signal Free Time = 5-bit periods. New initiator
>  wants to send a frame.
>  10Signal Free Time = 7-bit periods. Present
>  initiator wants to send another frame
>  immediately after its previous frame. (spec
>  CEC 9.1)
>  11Illegal value. If software write this value,
>  hardware will set the value to the default 2'b01.

The 'signal_free_time' argument of adap_transmit will have the recommended
signal free time. You can test against the CEC_SIGNAL_FREE_TIME_* defines
from media/cec.h. You probably saw this already, but just in case you missed
this...

Regards,

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

Re: [PATCH v5 0/3] drm/mali-dp: Add support for memory writeback engine

[Liviu Dudau]

On Fri, Jun 02, 2017 at 10:34:26AM +0200, Boris Brezillon wrote:
> On Mon, 15 May 2017 18:23:59 +0100
> Liviu Dudau  wrote:
> 
> > Hi,
> > 
> > This series introduces support for Mali DP's memory writeback engine
> > using the generic writeback connector support introduced in the
> > "[PATCH v5 0/2] drm: Introduce writeback connectors" series [1]
> > 
> > This version updates the Mali DP code to remove the bespoke encoder used
> > with the drm_writeback_connector and instead rely on the builtin one from
> > the v5 series.
> > 
> > v4 series can be found here [2].
> 
> Whole series is
> 
> Reviewed-by: Boris Brezillon 

Thanks! I'm starting to trickle the igt patches to Petri Latvala and once they
get accepted I'll send a pull request with this series if there are no votes
against it.

Best regards,
Liviu

> 
> > 
> > Best regards,
> > Liviu
> > 
> > [1] https://lists.freedesktop.org/archives/dri-devel/2017-May/141796.html
> > [2] https://lists.freedesktop.org/archives/dri-devel/2017-May/140850.html
> > 
> > Brian Starkey (2):
> >   drm: mali-dp: Add RGB writeback formats for DP550/DP650
> >   drm: mali-dp: Add writeback connector
> > 
> > Liviu Dudau (1):
> >   drm: mali-dp: Add support for writeback on DP550/DP650
> > 
> >  drivers/gpu/drm/arm/Makefile  |   1 +
> >  drivers/gpu/drm/arm/malidp_crtc.c |   9 ++
> >  drivers/gpu/drm/arm/malidp_drv.c  |  19 ++-
> >  drivers/gpu/drm/arm/malidp_drv.h  |   3 +
> >  drivers/gpu/drm/arm/malidp_hw.c   |  88 ++---
> >  drivers/gpu/drm/arm/malidp_hw.h   |  18 +++
> >  drivers/gpu/drm/arm/malidp_mw.c   | 252 
> > ++
> >  drivers/gpu/drm/arm/malidp_mw.h   |  18 +++
> >  drivers/gpu/drm/arm/malidp_regs.h |  15 +++
> >  9 files changed, 402 insertions(+), 21 deletions(-)
> >  create mode 100644 drivers/gpu/drm/arm/malidp_mw.c
> >  create mode 100644 drivers/gpu/drm/arm/malidp_mw.h
> > 
> 

-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/4] drm/bridge: dw-hdmi: add cec driver

[Hans Verkuil]

On 06/02/17 08:43, Jose Abreu wrote:
> Hi Hans,
> 
> 
> On 02-06-2017 07:31, Hans Verkuil wrote:
>> On 06/01/2017 03:47 PM, Neil Armstrong wrote:
>>> On 05/30/2017 04:23 PM, Russell King wrote:
 Add a CEC driver for the dw-hdmi hardware.

 Signed-off-by: Russell King 
 ---
   drivers/gpu/drm/bridge/synopsys/Kconfig   |   8 +
   drivers/gpu/drm/bridge/synopsys/Makefile  |   1 +
   drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c | 320
 ++
   drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.h |  19 ++
   drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |  40 +++-
   5 files changed, 387 insertions(+), 1 deletion(-)
   create mode 100644
 drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c
   create mode 100644
 drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.h

 diff --git a/drivers/gpu/drm/bridge/synopsys/Kconfig
 b/drivers/gpu/drm/bridge/synopsys/Kconfig
 index 40d2827a6d19..bd30a0a07272 100644
 --- a/drivers/gpu/drm/bridge/synopsys/Kconfig
 +++ b/drivers/gpu/drm/bridge/synopsys/Kconfig
 @@ -21,3 +21,11 @@ config DRM_DW_HDMI_I2S_AUDIO
   help
 Support the I2S Audio interface which is part of the
 Synopsys
 Designware HDMI block.
 +
 +config DRM_DW_HDMI_CEC
 +tristate "Synopsis Designware CEC interface"
 +depends on DRM_DW_HDMI && MEDIA_CEC_SUPPORT
 +select MEDIA_CEC_NOTIFIER
 +help
 +  Support the CE interface which is part of the Synopsis
 +  Designware HDMI block.
 diff --git a/drivers/gpu/drm/bridge/synopsys/Makefile
 b/drivers/gpu/drm/bridge/synopsys/Makefile
 index 17aa7a65b57e..6fe415903668 100644
 --- a/drivers/gpu/drm/bridge/synopsys/Makefile
 +++ b/drivers/gpu/drm/bridge/synopsys/Makefile
 @@ -3,3 +3,4 @@
   obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
   obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
   obj-$(CONFIG_DRM_DW_HDMI_I2S_AUDIO) += dw-hdmi-i2s-audio.o
 +obj-$(CONFIG_DRM_DW_HDMI_CEC) += dw-hdmi-cec.o
 diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c
 b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c
 new file mode 100644
 index ..761ef5ae687d
 --- /dev/null
 +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c
 @@ -0,0 +1,320 @@
 +/*
 + * Designware HDMI CEC driver
 + *
 + * Copyright (C) 2015-2017 Russell King.
 + *
 + * This program is free software; you can redistribute it
 and/or modify
 + * it under the terms of the GNU General Public License
 version 2 as
 + * published by the Free Software Foundation.
 + */
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +
 +#include 
 +
 +#include 
 +#include 
 +
 +#include "dw-hdmi-cec.h"
 +
 +enum {
 +HDMI_IH_CEC_STAT0= 0x0106,
 +HDMI_IH_MUTE_CEC_STAT0= 0x0186,
 +
 +HDMI_CEC_CTRL= 0x7d00,
 +CEC_CTRL_START= BIT(0),
 +CEC_CTRL_NORMAL= 1 << 1,
 +
 +HDMI_CEC_STAT= 0x7d01,
 +CEC_STAT_DONE= BIT(0),
 +CEC_STAT_EOM= BIT(1),
 +CEC_STAT_NACK= BIT(2),
 +CEC_STAT_ARBLOST= BIT(3),
 +CEC_STAT_ERROR_INIT= BIT(4),
 +CEC_STAT_ERROR_FOLL= BIT(5),
 +CEC_STAT_WAKEUP= BIT(6),
>>
>> I hadn't realized until Jose Abreu's latest reply, but you need
>> to check the
>> ARBLOST status and set the TX state to CEC_TX_STATUS_ARB_LOST.
>>
>> I think CEC_STAT_ERROR_FOLL might equal
>> CEC_TX_STATUS_LOW_DRIVE, but without
>> documentation I can't be sure.
>>
>> My experience is that this low drive condition tends to be
>> poorly reported by
>> hardware. Either that or poorly documented. This is why I added a
>> CEC_TX_STATUS_ERROR status as a catch-all error status when it
>> is unclear from
>> the hardware/documentation what error occurred.
>>
>> Jose, do you know which status bit is used to report a follower
>> pulling the
>> CEC line low for a long time (approx. 3.6 ms) to signal a CEC
>> error?
> 
> Bit 5 for follower error, bit 4 for initiator error.

I gathered that from the define names :-)

But what does it mean? What sort of error is reported here?

I'm guessing here that "follower error" means that one of the remote
CEC devices forced a Low Drive condition, where "initiator error"
means that our adapter forced a Low Drive condition on the bus.

Would that be correct?

If so, then the CEC_STAT_ERROR_INIT can be ignored and ERROR_FOLL
maps to the LOW_DRIVE status.

(Low Drive condition is what is described in section CEC 7.4 "CEC Line
Error Handling" of the HDMI 1.4 Specification).

Regards,

Hans
___
dri-devel mailing list
dri-devel@lists.freedesktop.org

[GIT PULL] omapdrm changes for v4.13 v2

[Tomi Valkeinen]

Hi Dave,

Here's second attempt for omapdrm changes for v4.13. The first version conflicts
with the latest drm-next due to the DRM_ROTATE flag changes. This one is rebased
on top of the latest drm-next.

 Tomi


The following changes since commit 2a1720376adda5ecf8e636fbfb05339c7dad1c55:

  Backmerge tag 'v4.12-rc3' into drm-next (2017-05-30 15:54:15 +1000)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git 
tags/omapdrm-4.13-v2

for you to fetch changes up to cc8dd7661ccc2d8dc88921da8e6cc7c2fcdb0341:

  drm/omap: fix tiled buffer stride calculations (2017-06-02 11:09:34 +0300)


omapdrm changes for v4.13

* dmabuf fence support
* TILER rotation fixes
* big pile of various cleanups and refactorings


Laurent Pinchart (24):
  drm: omapdrm: Handle events when enabling/disabling CRTCs
  drm: omapdrm: Use DRM core's atomic commit helper
  drm: omapdrm: Remove legacy buffer synchronization support
  drm: omapdrm: Store the Z order in the plane state zpos field
  drm: omapdrm: Remove custom plane state
  drm: omapdrm: Add zpos property
  drm: omapdrm: Remove remap argument to omap_gem_get_paddr()
  drm: omapdrm: Rename occurrences of paddr to dma_addr
  drm: omapdrm: Rename omap_gem_(get|put)_paddr() to omap_gem_(un)pin()
  drm: omapdrm: Lower indentation level in omap_gem_dma_sync_buffer()
  drm: omapdrm: Rename the omap_gem_object addrs field to dma_addrs
  drm: omapdrm: Rename GEM DMA sync functions
  drm: omapdrm: Fix incorrect usage of the term 'cache coherency'
  drm: omapdrm: DMA-unmap pages for all buffer types when freeing buffers
  drm: omapdrm: Map pages for DMA in DMA_TO_DEVICE direction
  drm: omapdrm: Take GEM object reference when exporting dmabuf
  drm: omapdrm: Remove duplicate error messages when mapping memory
  drm: omapdrm: Drop support for non-DT devices
  drm: omapdrm: Remove unused dss_get_core_pdev() function
  drm: omapdrm: Remove unused default display name support
  drm: omapdrm: Infer the OMAP version from the SoC family
  drm: omapdrm: dpi: Remove platform driver
  drm: omapdrm: sdi: Remove platform driver
  drm/omap: Remove unused omap_dss_find_output() function

Tomi Valkeinen (40):
  drm/omap: add new connector types
  drm/omap: remove unused ovl_enabled()
  drm/omap: remove ovl_set_channel_out
  drm/omap: remove read_irqenable()
  drm/omap: 64bit compile fixes
  drm/omap: define compat_ioctl
  drm/omap: panel-dpi: remove non-DT support
  drm/omap: acx565akm: remove non-DT support
  drm/omap: connector-analog-tv: remove non-DT support
  drm/omap: connector-dvi/hdmi: remove extra include
  drm/omap: sdi: remove legacy set_datapairs
  drm/omap: venc: remove set_type & invert_vid_out_polarity
  drm/omap: remove recommended_bpp
  drm/omap: dpi: remove legacy data_lines
  drm/omap: remove rfbi
  drm/omap: remove unused get_dimensions()
  drm/omap: remove legacy get_resolution
  drm/omap: remove unused fields
  drm/omap: remove omap_overlay & omap_overlay_manager
  drm/omap: fix setting & clearing DOUBLESTRIDE
  drm/omap: remove CLUT
  drm/omap: ratelimit OCP error
  drm/omap: remove dma & vrfb rotation
  drm/omap: cleanup offset calculation
  drm/omap: add format_is_yuv() helper
  drm/omap: remove unneeded prototypes
  drm/omap: change supported_modes to an array
  drm/omap: use u32 instead of enum omap_color_mode
  drm/omap: use DRM_FORMAT_* instead of OMAP_DSS_COLOR_*
  drm/omap: remove omap_framebuffer_get_formats()
  drm/omap: cleanup formats array
  drm/omap: rename color_mode to fourcc
  drm/omap: add drm_rotation_to_tiler helper()
  drm/omap: remove omap_drm_win
  drm/omap: use DRM_MODE_ROTATE_* instead of OMAP_DSS_ROT_*
  drm/omap: DRM_MODE_REFLECT_* instead of mirror boolean
  drm/omap: pass rotation to dispc
  drm/omap: fix YUV422 rotation with TILER
  drm/omap: fix YUV422 90/270 rotation with mirroring
  drm/omap: fix tiled buffer stride calculations

 .../gpu/drm/omapdrm/displays/connector-analog-tv.c |   51 +-
 drivers/gpu/drm/omapdrm/displays/connector-dvi.c   |3 -
 drivers/gpu/drm/omapdrm/displays/connector-hdmi.c  |3 -
 drivers/gpu/drm/omapdrm/displays/encoder-opa362.c  |   10 -
 drivers/gpu/drm/omapdrm/displays/encoder-tfp410.c  |4 -
 drivers/gpu/drm/omapdrm/displays/panel-dpi.c   |   83 +-
 drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c|   10 -
 .../omapdrm/displays/panel-lgphilips-lb035q02.c|7 -
 .../drm/omapdrm/displays/panel-nec-nl8048hl11.c|6 -
 .../drm/omapdrm/displays/panel-sharp-ls037v7dw01.c |7 -
 .../drm/omapdrm/displays/panel-sony-acx565akm.c|   49 +-
 

Re: [PATCH v5 0/3] drm/mali-dp: Add support for memory writeback engine

[Boris Brezillon]

On Mon, 15 May 2017 18:23:59 +0100
Liviu Dudau  wrote:

> Hi,
> 
> This series introduces support for Mali DP's memory writeback engine
> using the generic writeback connector support introduced in the
> "[PATCH v5 0/2] drm: Introduce writeback connectors" series [1]
> 
> This version updates the Mali DP code to remove the bespoke encoder used
> with the drm_writeback_connector and instead rely on the builtin one from
> the v5 series.
> 
> v4 series can be found here [2].

Whole series is

Reviewed-by: Boris Brezillon 

> 
> Best regards,
> Liviu
> 
> [1] https://lists.freedesktop.org/archives/dri-devel/2017-May/141796.html
> [2] https://lists.freedesktop.org/archives/dri-devel/2017-May/140850.html
> 
> Brian Starkey (2):
>   drm: mali-dp: Add RGB writeback formats for DP550/DP650
>   drm: mali-dp: Add writeback connector
> 
> Liviu Dudau (1):
>   drm: mali-dp: Add support for writeback on DP550/DP650
> 
>  drivers/gpu/drm/arm/Makefile  |   1 +
>  drivers/gpu/drm/arm/malidp_crtc.c |   9 ++
>  drivers/gpu/drm/arm/malidp_drv.c  |  19 ++-
>  drivers/gpu/drm/arm/malidp_drv.h  |   3 +
>  drivers/gpu/drm/arm/malidp_hw.c   |  88 ++---
>  drivers/gpu/drm/arm/malidp_hw.h   |  18 +++
>  drivers/gpu/drm/arm/malidp_mw.c   | 252 
> ++
>  drivers/gpu/drm/arm/malidp_mw.h   |  18 +++
>  drivers/gpu/drm/arm/malidp_regs.h |  15 +++
>  9 files changed, 402 insertions(+), 21 deletions(-)
>  create mode 100644 drivers/gpu/drm/arm/malidp_mw.c
>  create mode 100644 drivers/gpu/drm/arm/malidp_mw.h
> 

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

[PATCH 0/7] drm/vc4: Add writeback support to the VC4 driver

[Boris Brezillon]

Hello,

This series adds a driver for the TXP (transposer) block which is
providing writeback support.

Note that adding support for this IP required reworking a bit how the
VC4 driver handles commits (vc4_kms.c). I also had to support a new use
case in vc4_crtc.c because the TXP IP is completely bypassing the
pixelvalve element (it's taking its data directly from the HVS FIFO).

First patch is adding a new helper to the core to wait for all pageflips
to be done. It can be used as a replacement for
drm_atomic_helper_wait_for_vblanks() when your HW is only generating
a single frame (AKA oneshot mode), which implies a single VBLANK event.
In this situation, if drm_atomic_helper_wait_for_vblanks() is called
after the VBLANK event has been sent, we face a timeout because vblank
counter (used to detect when vblanks are happening) is never updated
again.
Daniel, I'm not sure this is exactly what you had in mind when you
proposed this approach, so feel free to comment on this patch.

Patches 2 to 4 are modifying the current logic to make it work with
the TXP block.

Patches 5 and 6 are adding code to support the TXP and documenting the
bindings.
And the last patch is defining the TXP block in bcm283x.dtsi.

This series depends on Brian Starkey/Liviu Dudau patchset [1] and has
been tested on a RPi2 with the kms_writeback tests provided here [2].

Regards,

Boris

[1]https://lists.freedesktop.org/archives/dri-devel/2017-May/141796.html
[2]https://github.com/dliviu/intel-gpu-tools/tree/master

Boris Brezillon (7):
  drm: Add drm_atomic_helper_wait_for_flip_done()
  drm/vc4: Fix vblank handling
  drm/vc4: Mimic drm_atomic_helper_commit() behavior
  drm/vc4: Use drm_atomic_helper_wait_for_flip_done()
  drm/vc4: Add support for the TXP (transposer) block
  dt-bindings: Document the VC4 TXP module nodes.
  ARM: dts: bcm283x: Add Transposer block

 .../devicetree/bindings/display/brcm,bcm-vc4.txt   |  12 +
 arch/arm/boot/dts/bcm283x.dtsi |   6 +
 drivers/gpu/drm/drm_atomic_helper.c|  30 ++
 drivers/gpu/drm/vc4/Makefile   |   1 +
 drivers/gpu/drm/vc4/vc4_crtc.c | 206 +++--
 drivers/gpu/drm/vc4/vc4_debugfs.c  |   1 +
 drivers/gpu/drm/vc4/vc4_drv.c  |   1 +
 drivers/gpu/drm/vc4/vc4_drv.h  |  10 +
 drivers/gpu/drm/vc4/vc4_kms.c  |  47 +-
 drivers/gpu/drm/vc4/vc4_regs.h |   1 +
 drivers/gpu/drm/vc4/vc4_txp.c  | 509 +
 include/drm/drm_atomic_helper.h|   3 +
 12 files changed, 755 insertions(+), 72 deletions(-)
 create mode 100644 drivers/gpu/drm/vc4/vc4_txp.c

-- 
2.7.4

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

[PATCH 7/7] ARM: dts: bcm283x: Add Transposer block

[Boris Brezillon]

The transposer block is allowing one to write the result of the VC4
composition back to memory.

Signed-off-by: Boris Brezillon 
---
 arch/arm/boot/dts/bcm283x.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi
index 35cea3fcaf5c..d5b11483556c 100644
--- a/arch/arm/boot/dts/bcm283x.dtsi
+++ b/arch/arm/boot/dts/bcm283x.dtsi
@@ -35,6 +35,12 @@
clock-frequency = <100>;
};
 
+   txp@7e004000 {
+   compatible = "brcm,bcm2835-txp";
+   reg = <0x7e004000 0x20>;
+   interrupts = <1 11>;
+   };
+
dma: dma@7e007000 {
compatible = "brcm,bcm2835-dma";
reg = <0x7e007000 0xf00>;
-- 
2.7.4

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

[PATCH 4/7] drm/vc4: Use drm_atomic_helper_wait_for_flip_done()

[Boris Brezillon]

Replace the drm_atomic_helper_wait_for_vblanks() with a call to
drm_atomic_helper_wait_for_flip_done(). This allows better detection of
page flip done events which what we are really waiting for in
vc4_atomic_complete_commit().

With this approach, we also addresse the 'missed single vblank event'
problem that can arise when the CRTC is configured in oneshot mode
(only a single frame is generated and the CRTC is immediately paused
after this frame). Note that this oneshot mode will be used for the
writeback connector feature.

Signed-off-by: Boris Brezillon 
---
 drivers/gpu/drm/vc4/vc4_kms.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index f229abc0991b..86a60e9b623d 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -63,7 +63,7 @@ vc4_atomic_complete_commit(struct vc4_commit *c)
 
drm_atomic_helper_commit_hw_done(state);
 
-   drm_atomic_helper_wait_for_vblanks(dev, state);
+   drm_atomic_helper_wait_for_flip_done(dev, state);
 
drm_atomic_helper_cleanup_planes(dev, state);
 
-- 
2.7.4

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

[PATCH 3/7] drm/vc4: Mimic drm_atomic_helper_commit() behavior

[Boris Brezillon]

The VC4 KMS driver is implementing its own ->atomic_commit() but there
are a few generic helpers we can use instead of open-coding the logic.

Signed-off-by: Boris Brezillon 
---
 drivers/gpu/drm/vc4/vc4_kms.c | 38 --
 1 file changed, 12 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index ad7925a9e0ea..f229abc0991b 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -42,6 +42,10 @@ vc4_atomic_complete_commit(struct vc4_commit *c)
struct drm_device *dev = state->dev;
struct vc4_dev *vc4 = to_vc4_dev(dev);
 
+   drm_atomic_helper_wait_for_fences(dev, state, false);
+
+   drm_atomic_helper_wait_for_dependencies(state);
+
drm_atomic_helper_commit_modeset_disables(dev, state);
 
drm_atomic_helper_commit_planes(dev, state, 0);
@@ -57,10 +61,14 @@ vc4_atomic_complete_commit(struct vc4_commit *c)
 */
state->legacy_cursor_update = false;
 
+   drm_atomic_helper_commit_hw_done(state);
+
drm_atomic_helper_wait_for_vblanks(dev, state);
 
drm_atomic_helper_cleanup_planes(dev, state);
 
+   drm_atomic_helper_commit_cleanup_done(state);
+
drm_atomic_state_put(state);
 
up(>async_modeset);
@@ -117,32 +125,10 @@ static int vc4_atomic_commit(struct drm_device *dev,
if (!c)
return -ENOMEM;
 
-   /* Make sure that any outstanding modesets have finished. */
-   if (nonblock) {
-   struct drm_crtc *crtc;
-   struct drm_crtc_state *crtc_state;
-   unsigned long flags;
-   bool busy = false;
-
-   /*
-* If there's an undispatched event to send then we're
-* obviously still busy.  If there isn't, then we can
-* unconditionally wait for the semaphore because it
-* shouldn't be contended (for long).
-*
-* This is to prevent a race where queuing a new flip
-* from userspace immediately on receipt of an event
-* beats our clean-up and returns EBUSY.
-*/
-   spin_lock_irqsave(>event_lock, flags);
-   for_each_crtc_in_state(state, crtc, crtc_state, i)
-   busy |= vc4_event_pending(crtc);
-   spin_unlock_irqrestore(>event_lock, flags);
-   if (busy) {
-   kfree(c);
-   return -EBUSY;
-   }
-   }
+   ret = drm_atomic_helper_setup_commit(state, nonblock);
+   if (ret)
+   return ret;
+
ret = down_interruptible(>async_modeset);
if (ret) {
kfree(c);
-- 
2.7.4

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

[PATCH 6/7] dt-bindings: Document the VC4 TXP module nodes.

[Boris Brezillon]

These are part of the vc4 display pipeline.

Signed-off-by: Boris Brezillon 
---
 Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt | 12 
 1 file changed, 12 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt 
b/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
index ca02d3e4db91..aeed89cc7f05 100644
--- a/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
+++ b/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
@@ -20,6 +20,12 @@ Required properties for HVS:
 - interrupts:  The interrupt number
  See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
 
+Required properties for TXP:
+- compatible:  Should be "brcm,bcm2835-txp"
+- reg: Physical base address and length of the TXP's registers
+- interrupts:  The interrupt number
+ See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
+
 Required properties for HDMI
 - compatible:  Should be "brcm,bcm2835-hdmi"
 - reg: Physical base address and length of the two register ranges
@@ -86,6 +92,12 @@ hvs@7e40 {
interrupts = <2 1>;
 };
 
+txp@7e004000 {
+   compatible = "brcm,bcm2835-txp";
+   reg = <0x7e004000 0x20>;
+   interrupts = <1 11>;
+};
+
 hdmi: hdmi@7e902000 {
compatible = "brcm,bcm2835-hdmi";
reg = <0x7e902000 0x600>,
-- 
2.7.4

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

[PATCH 1/7] drm: Add drm_atomic_helper_wait_for_flip_done()

[Boris Brezillon]

Add an helper to wait for all page flips of an atomic state to be done.

Signed-off-by: Boris Brezillon 
---
 drivers/gpu/drm/drm_atomic_helper.c | 30 ++
 include/drm/drm_atomic_helper.h |  3 +++
 2 files changed, 33 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index fa2d8d7a602a..11f2d644771b 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1166,6 +1166,36 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device 
*dev,
 EXPORT_SYMBOL(drm_atomic_helper_wait_for_vblanks);
 
 /**
+ * drm_atomic_helper_wait_for_flip_done - wait for all page flips to be done
+ * @state: atomic state object
+ *
+ * Helper to, after atomic commit, wait for page flips on all effected
+ * crtcs (ie. before cleaning up old framebuffers using
+ * drm_atomic_helper_cleanup_planes()).
+ */
+void drm_atomic_helper_wait_for_flip_done(struct drm_device *dev,
+ struct drm_atomic_state *state)
+{
+   struct drm_crtc_state *crtc_state;
+   struct drm_crtc *crtc;
+   int i;
+
+   for_each_crtc_in_state(state, crtc, crtc_state, i) {
+   struct drm_crtc_commit *commit = state->crtcs[i].commit;
+   int ret;
+
+   if (!commit)
+   continue;
+
+   ret = wait_for_completion_timeout(>flip_done, 10 * HZ);
+   if (ret == 0)
+   DRM_ERROR("[CRTC:%d:%s] flip_done timed out\n",
+ crtc->base.id, crtc->name);
+   }
+}
+EXPORT_SYMBOL(drm_atomic_helper_wait_for_flip_done);
+
+/**
  * drm_atomic_helper_commit_tail - commit atomic update to hardware
  * @old_state: atomic state object with old state structures
  *
diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h
index f0a8678ae98e..7192e7ac117f 100644
--- a/include/drm/drm_atomic_helper.h
+++ b/include/drm/drm_atomic_helper.h
@@ -52,6 +52,9 @@ int drm_atomic_helper_wait_for_fences(struct drm_device *dev,
 void drm_atomic_helper_wait_for_vblanks(struct drm_device *dev,
struct drm_atomic_state *old_state);
 
+void drm_atomic_helper_wait_for_flip_done(struct drm_device *dev,
+ struct drm_atomic_state *state);
+
 void
 drm_atomic_helper_update_legacy_modeset_state(struct drm_device *dev,
  struct drm_atomic_state 
*old_state);
-- 
2.7.4

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

[PATCH 5/7] drm/vc4: Add support for the TXP (transposer) block

[Boris Brezillon]

The TXP block is providing writeback support. Add a driver to expose this
feature.

Supporting this engine requires reworking the CRTC because it's not using
the usual 'HVS -> PV -> VC4 Encoder' scheme. Instead, the TXP block is
directly connected to HVS FIFO2, and the PV is completely bypassed.

In order to make things work, we have to detect when the TXP is enabled,
avoid enabling the PV when this is the case, and generate fake VBLANK
events when the TXP is done writing the frame back to memory.

Signed-off-by: Boris Brezillon 
---
 drivers/gpu/drm/vc4/Makefile  |   1 +
 drivers/gpu/drm/vc4/vc4_crtc.c| 126 --
 drivers/gpu/drm/vc4/vc4_debugfs.c |   1 +
 drivers/gpu/drm/vc4/vc4_drv.c |   1 +
 drivers/gpu/drm/vc4/vc4_drv.h |  10 +
 drivers/gpu/drm/vc4/vc4_kms.c |   7 +
 drivers/gpu/drm/vc4/vc4_regs.h|   1 +
 drivers/gpu/drm/vc4/vc4_txp.c | 509 ++
 8 files changed, 634 insertions(+), 22 deletions(-)
 create mode 100644 drivers/gpu/drm/vc4/vc4_txp.c

diff --git a/drivers/gpu/drm/vc4/Makefile b/drivers/gpu/drm/vc4/Makefile
index 61f45d122bd0..660b3363400f 100644
--- a/drivers/gpu/drm/vc4/Makefile
+++ b/drivers/gpu/drm/vc4/Makefile
@@ -18,6 +18,7 @@ vc4-y := \
vc4_plane.o \
vc4_render_cl.o \
vc4_trace_points.o \
+   vc4_txp.o \
vc4_v3d.o \
vc4_validate.o \
vc4_validate_shaders.o
diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index df1d81533076..564fd795803d 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -66,6 +66,7 @@ struct vc4_crtc_state {
struct drm_crtc_state base;
/* Dlist area for this CRTC configuration. */
struct drm_mm_node mm;
+   bool feed_txp;
 };
 
 static inline struct vc4_crtc *
@@ -369,10 +370,8 @@ static struct drm_encoder *vc4_get_crtc_encoder(struct 
drm_crtc *crtc)
return NULL;
 }
 
-static void vc4_crtc_mode_set_nofb(struct drm_crtc *crtc)
+static void vc4_crtc_config_pv(struct drm_crtc *crtc)
 {
-   struct drm_device *dev = crtc->dev;
-   struct vc4_dev *vc4 = to_vc4_dev(dev);
struct drm_encoder *encoder = vc4_get_crtc_encoder(crtc);
struct vc4_encoder *vc4_encoder = to_vc4_encoder(encoder);
struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
@@ -383,12 +382,6 @@ static void vc4_crtc_mode_set_nofb(struct drm_crtc *crtc)
bool is_dsi = (vc4_encoder->type == VC4_ENCODER_TYPE_DSI0 ||
   vc4_encoder->type == VC4_ENCODER_TYPE_DSI1);
u32 format = is_dsi ? PV_CONTROL_FORMAT_DSIV_24 : PV_CONTROL_FORMAT_24;
-   bool debug_dump_regs = false;
-
-   if (debug_dump_regs) {
-   DRM_INFO("CRTC %d regs before:\n", drm_crtc_index(crtc));
-   vc4_crtc_dump_regs(vc4_crtc);
-   }
 
/* Reset the PV fifo. */
CRTC_WRITE(PV_CONTROL, 0);
@@ -464,6 +457,51 @@ static void vc4_crtc_mode_set_nofb(struct drm_crtc *crtc)
 PV_CONTROL_CLK_SELECT) |
   PV_CONTROL_FIFO_CLR |
   PV_CONTROL_EN);
+}
+
+static void vc4_crtc_mode_set_nofb(struct drm_crtc *crtc)
+{
+   struct drm_device *dev = crtc->dev;
+   struct vc4_dev *vc4 = to_vc4_dev(dev);
+   struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
+   struct vc4_crtc_state *vc4_state = to_vc4_crtc_state(crtc->state);
+   struct drm_display_mode *mode = >state->adjusted_mode;
+   bool interlace = mode->flags & DRM_MODE_FLAG_INTERLACE;
+   bool debug_dump_regs = false;
+
+   if (debug_dump_regs) {
+   DRM_INFO("CRTC %d regs before:\n", drm_crtc_index(crtc));
+   vc4_crtc_dump_regs(vc4_crtc);
+   }
+
+   if (vc4_crtc->channel == 2) {
+   u32 dispctrl, olddispctrl;
+
+   olddispctrl = HVS_READ(SCALER_DISPCTRL);
+   dispctrl = olddispctrl & ~SCALER_DISPCTRL_DSP3_MUX_MASK;
+
+   /* SCALER_DISPCTRL_DSP3 = X, where X < 2 means 'connect DSP3 to
+* FIFO X'.
+* SCALER_DISPCTRL_DSP3 = 3 means 'disable DSP 3'.
+*
+* DSP3 is connected to FIFO2 unless the transposer is
+* enabled. In this case, FIFO 2 is directly accessed by the
+* TXP IP, and we need to disable the FIFO2 -> pixelvalve1
+* route.
+*/
+   if (vc4_state->feed_txp)
+   dispctrl |= VC4_SET_FIELD(3, SCALER_DISPCTRL_DSP3_MUX);
+   else
+   dispctrl |= VC4_SET_FIELD(2, SCALER_DISPCTRL_DSP3_MUX);
+
+   /* Reconfigure the DSP3 mux if required. */
+   if (olddispctrl != dispctrl)
+   HVS_WRITE(SCALER_DISPCTRL, dispctrl);
+   }
+
+   /* Only configure the pixelvalve if we're not feeding the TXP block. */
+   if (!vc4_state->feed_txp)
+   

[PATCH 2/7] drm/vc4: Fix vblank handling

[Boris Brezillon]

There are two problems related to VBLANK handling in the current CRTC
driver:

* VBLANK events are missed when the CRTC is being disabled because the
  driver does not wait till the end of the frame before stopping the
  HVS and PV blocks. In this case, we should explicitly issue a VBLANK
  event if there's one waiting
* when we are enabling a CRTC, drm_crtc_vblank_get() is called before
  drm_crtc_vblank_on(), which is not supposed to happen (hence the
  WARN_ON() in the code). To solve the problem, we delay the 'update
  display list' operation after the CRTC is actually enabled.

Signed-off-by: Boris Brezillon 
---
 drivers/gpu/drm/vc4/vc4_crtc.c | 80 ++
 1 file changed, 57 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index d86c8cce3182..df1d81533076 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -528,6 +528,47 @@ static void vc4_crtc_disable(struct drm_crtc *crtc)
WARN_ON_ONCE((HVS_READ(SCALER_DISPSTATX(chan)) &
  (SCALER_DISPSTATX_FULL | SCALER_DISPSTATX_EMPTY)) !=
 SCALER_DISPSTATX_EMPTY);
+
+   /*
+* Make sure we issue a vblank event after disabling the CRTC if
+* someone was waiting it.
+*/
+   if (crtc->state->event) {
+   unsigned long flags;
+
+   spin_lock_irqsave(>event_lock, flags);
+   drm_crtc_send_vblank_event(crtc, crtc->state->event);
+   crtc->state->event = NULL;
+   spin_unlock_irqrestore(>event_lock, flags);
+   }
+}
+
+static void vc4_crtc_update_dlist(struct drm_crtc *crtc)
+{
+   struct drm_device *dev = crtc->dev;
+   struct vc4_dev *vc4 = to_vc4_dev(dev);
+   struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
+   struct vc4_crtc_state *vc4_state = to_vc4_crtc_state(crtc->state);
+
+   if (crtc->state->event) {
+   unsigned long flags;
+
+   crtc->state->event->pipe = drm_crtc_index(crtc);
+
+   WARN_ON(drm_crtc_vblank_get(crtc) != 0);
+
+   spin_lock_irqsave(>event_lock, flags);
+   vc4_crtc->event = crtc->state->event;
+   crtc->state->event = NULL;
+
+   HVS_WRITE(SCALER_DISPLISTX(vc4_crtc->channel),
+ vc4_state->mm.start);
+
+   spin_unlock_irqrestore(>event_lock, flags);
+   } else {
+   HVS_WRITE(SCALER_DISPLISTX(vc4_crtc->channel),
+ vc4_state->mm.start);
+   }
 }
 
 static void vc4_crtc_enable(struct drm_crtc *crtc)
@@ -540,6 +581,12 @@ static void vc4_crtc_enable(struct drm_crtc *crtc)
 
require_hvs_enabled(dev);
 
+   /* Enable vblank irq handling before crtc is started otherwise
+* drm_crtc_get_vblank() fails in vc4_crtc_update_dlist().
+*/
+   drm_crtc_vblank_on(crtc);
+   vc4_crtc_update_dlist(crtc);
+
/* Turn on the scaler, which will wait for vstart to start
 * compositing.
 */
@@ -551,9 +598,6 @@ static void vc4_crtc_enable(struct drm_crtc *crtc)
/* Turn on the pixel valve, which will emit the vstart signal. */
CRTC_WRITE(PV_V_CONTROL,
   CRTC_READ(PV_V_CONTROL) | PV_VCONTROL_VIDEN);
-
-   /* Enable vblank irq handling after crtc is started. */
-   drm_crtc_vblank_on(crtc);
 }
 
 static bool vc4_crtc_mode_fixup(struct drm_crtc *crtc,
@@ -608,7 +652,6 @@ static void vc4_crtc_atomic_flush(struct drm_crtc *crtc,
 {
struct drm_device *dev = crtc->dev;
struct vc4_dev *vc4 = to_vc4_dev(dev);
-   struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
struct vc4_crtc_state *vc4_state = to_vc4_crtc_state(crtc->state);
struct drm_plane *plane;
bool debug_dump_regs = false;
@@ -630,25 +673,16 @@ static void vc4_crtc_atomic_flush(struct drm_crtc *crtc,
 
WARN_ON_ONCE(dlist_next - dlist_start != vc4_state->mm.size);
 
-   if (crtc->state->event) {
-   unsigned long flags;
-
-   crtc->state->event->pipe = drm_crtc_index(crtc);
-
-   WARN_ON(drm_crtc_vblank_get(crtc) != 0);
-
-   spin_lock_irqsave(>event_lock, flags);
-   vc4_crtc->event = crtc->state->event;
-   crtc->state->event = NULL;
-
-   HVS_WRITE(SCALER_DISPLISTX(vc4_crtc->channel),
- vc4_state->mm.start);
-
-   spin_unlock_irqrestore(>event_lock, flags);
-   } else {
-   HVS_WRITE(SCALER_DISPLISTX(vc4_crtc->channel),
- vc4_state->mm.start);
-   }
+   /*
+* Only update DISPLIST if the CRTC was already running and is not
+* being disabled.
+* vc4_crtc_enable() takes care of updating the dlist just after
+* re-enabling VBLANK interrupts and before enabling the engine.
+* If the 

Re: iMac 10,1 with Ubuntu 16.04: black screen after suspend

[Florian Echtler]

On 01.06.2017 19:53, Alex Deucher wrote:
> On Thu, Jun 1, 2017 at 4:27 AM, Florian Echtler  wrote:
>> On 31.05.2017 14:57, Alex Deucher wrote:
>>> On Wed, May 31, 2017 at 5:21 AM, Lukas Wunner  wrote:
>>
>> Here's the (substantial) dmesg output, with drm.debug=0xf:
>> http://floe.butterbrot.org/external/radeon/dmesg_after_suspend
>>
>> I haven't been able to find any references to link training, though.
> 
> I need your dmesg from boot to confirm the display topology, but eDP
> with r7xx asics was pretty rare.  I suspect your system just uses
> LVDS; as such there is no link training involved.

I've updated the trace with increased log_buf_len so nothing is truncated:

http://floe.butterbrot.org/external/radeon/dmesg_after_suspend.txt

(trace now contains a full boot including suspend and wakeup)

However, what I'm seeing now does sound like the internal connection is indeed 
eDP:

[  166.816162] [drm:drm_mode_setcrtc] [CRTC:34:crtc-0]
[  166.816166] [drm:drm_mode_setcrtc] [CONNECTOR:40:eDP-1]
[  166.816167] [drm:drm_crtc_helper_set_config]
[  166.816169] [drm:drm_crtc_helper_set_config] [CRTC:34:crtc-0] [FB:54]
#connectors=1 (x y) (0 0)
[  166.816170] [drm:drm_crtc_helper_set_config] crtc has no fb, full mode set
[  166.816172] [drm:drm_mode_object_reference] OBJ ID: 40 (4)
[  166.816173] [drm:drm_crtc_helper_set_config] encoder changed, full mode 
switch
[  166.816174] [drm:drm_crtc_helper_set_config] crtc changed, full mode switch
[  166.816174] [drm:drm_crtc_helper_set_config] [CONNECTOR:40:eDP-1] to
[CRTC:34:crtc-0]
[  166.816175] [drm:drm_crtc_helper_set_config] attempting to set mode from
userspace
[  166.816177] [drm:drm_mode_debug_printmodeline] Modeline 65:"" 0 241500 2560
2608 2640 2720 1440 1443 1448 1481 0x0 0x9
[  166.816180] [drm:radeon_encoder_set_active_device] setting active device to
0002 from 0002 0002 for encoder 3
[  166.816183] [drm:radeon_get_monitor_bpc] eDP-1: Display bpc=8, returned bpc=8
[  166.816185] [drm:drm_detect_monitor_audio] Monitor has basic audio support
[  166.816186] [drm:radeon_get_monitor_bpc] eDP-1: Display bpc=8, returned bpc=8
[  166.816188] [drm:drm_detect_monitor_audio] Monitor has basic audio support
[  166.816192] [drm:drm_crtc_helper_set_mode] [CRTC:34:crtc-0]
[  166.816208] [drm:radeon_get_monitor_bpc] eDP-1: Display bpc=8, returned bpc=8
[  166.816210] [drm:radeon_atom_encoder_dpms] encoder dpms 30 to mode 3, devices
0008, active_devices 
[  166.816213] [drm:radeon_atom_encoder_dpms] encoder dpms 22 to mode 3, devices
0010, active_devices 
[  166.816235] [drm:drm_detect_monitor_audio] Monitor has basic audio support
[  166.816237] [drm:radeon_compute_pll_avivo] 36 - 36, pll dividers -
fb: 80.0 ref: 2, post 3
[  166.824475] done.

... and a bit later:

[  166.853787] [drm:radeon_dp_link_train_cr] clock recovery at voltage 0
pre-emphasis 0
[  166.853788] [drm:drm_detect_monitor_audio] Monitor has basic audio support
[  166.855953] [drm:radeon_dp_link_train_ce] channel eq at voltage 0 
pre-emphasis 0

Best, Florian
-- 
SENT FROM MY DEC VT50 TERMINAL



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

Re: [PATCH 4/4] drm/bridge: dw-hdmi: add cec driver

[Jose Abreu]

Hi Hans,


On 02-06-2017 07:31, Hans Verkuil wrote:
> On 06/01/2017 03:47 PM, Neil Armstrong wrote:
>> On 05/30/2017 04:23 PM, Russell King wrote:
>>> Add a CEC driver for the dw-hdmi hardware.
>>>
>>> Signed-off-by: Russell King 
>>> ---
>>>   drivers/gpu/drm/bridge/synopsys/Kconfig   |   8 +
>>>   drivers/gpu/drm/bridge/synopsys/Makefile  |   1 +
>>>   drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c | 320
>>> ++
>>>   drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.h |  19 ++
>>>   drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |  40 +++-
>>>   5 files changed, 387 insertions(+), 1 deletion(-)
>>>   create mode 100644
>>> drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c
>>>   create mode 100644
>>> drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.h
>>>
>>> diff --git a/drivers/gpu/drm/bridge/synopsys/Kconfig
>>> b/drivers/gpu/drm/bridge/synopsys/Kconfig
>>> index 40d2827a6d19..bd30a0a07272 100644
>>> --- a/drivers/gpu/drm/bridge/synopsys/Kconfig
>>> +++ b/drivers/gpu/drm/bridge/synopsys/Kconfig
>>> @@ -21,3 +21,11 @@ config DRM_DW_HDMI_I2S_AUDIO
>>>   help
>>> Support the I2S Audio interface which is part of the
>>> Synopsys
>>> Designware HDMI block.
>>> +
>>> +config DRM_DW_HDMI_CEC
>>> +tristate "Synopsis Designware CEC interface"
>>> +depends on DRM_DW_HDMI && MEDIA_CEC_SUPPORT
>>> +select MEDIA_CEC_NOTIFIER
>>> +help
>>> +  Support the CE interface which is part of the Synopsis
>>> +  Designware HDMI block.
>>> diff --git a/drivers/gpu/drm/bridge/synopsys/Makefile
>>> b/drivers/gpu/drm/bridge/synopsys/Makefile
>>> index 17aa7a65b57e..6fe415903668 100644
>>> --- a/drivers/gpu/drm/bridge/synopsys/Makefile
>>> +++ b/drivers/gpu/drm/bridge/synopsys/Makefile
>>> @@ -3,3 +3,4 @@
>>>   obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
>>>   obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
>>>   obj-$(CONFIG_DRM_DW_HDMI_I2S_AUDIO) += dw-hdmi-i2s-audio.o
>>> +obj-$(CONFIG_DRM_DW_HDMI_CEC) += dw-hdmi-cec.o
>>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c
>>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c
>>> new file mode 100644
>>> index ..761ef5ae687d
>>> --- /dev/null
>>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c
>>> @@ -0,0 +1,320 @@
>>> +/*
>>> + * Designware HDMI CEC driver
>>> + *
>>> + * Copyright (C) 2015-2017 Russell King.
>>> + *
>>> + * This program is free software; you can redistribute it
>>> and/or modify
>>> + * it under the terms of the GNU General Public License
>>> version 2 as
>>> + * published by the Free Software Foundation.
>>> + */
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +#include 
>>> +
>>> +#include 
>>> +#include 
>>> +
>>> +#include "dw-hdmi-cec.h"
>>> +
>>> +enum {
>>> +HDMI_IH_CEC_STAT0= 0x0106,
>>> +HDMI_IH_MUTE_CEC_STAT0= 0x0186,
>>> +
>>> +HDMI_CEC_CTRL= 0x7d00,
>>> +CEC_CTRL_START= BIT(0),
>>> +CEC_CTRL_NORMAL= 1 << 1,
>>> +
>>> +HDMI_CEC_STAT= 0x7d01,
>>> +CEC_STAT_DONE= BIT(0),
>>> +CEC_STAT_EOM= BIT(1),
>>> +CEC_STAT_NACK= BIT(2),
>>> +CEC_STAT_ARBLOST= BIT(3),
>>> +CEC_STAT_ERROR_INIT= BIT(4),
>>> +CEC_STAT_ERROR_FOLL= BIT(5),
>>> +CEC_STAT_WAKEUP= BIT(6),
>
> I hadn't realized until Jose Abreu's latest reply, but you need
> to check the
> ARBLOST status and set the TX state to CEC_TX_STATUS_ARB_LOST.
>
> I think CEC_STAT_ERROR_FOLL might equal
> CEC_TX_STATUS_LOW_DRIVE, but without
> documentation I can't be sure.
>
> My experience is that this low drive condition tends to be
> poorly reported by
> hardware. Either that or poorly documented. This is why I added a
> CEC_TX_STATUS_ERROR status as a catch-all error status when it
> is unclear from
> the hardware/documentation what error occurred.
>
> Jose, do you know which status bit is used to report a follower
> pulling the
> CEC line low for a long time (approx. 3.6 ms) to signal a CEC
> error?

Bit 5 for follower error, bit 4 for initiator error.

Best regards,
Jose Miguel Abreu

>
> Regards,
>
> Hans

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

Re: [PATCH 4/4] drm/bridge: dw-hdmi: add cec driver

[Jose Abreu]

On 01-06-2017 23:30, Russell King - ARM Linux wrote:
> On Thu, Jun 01, 2017 at 01:53:21AM +0100, Jose Abreu wrote:
>> Hi Russell,
>>
>>
>> On 30-05-2017 15:23, Russell King wrote:
>>> +static int dw_hdmi_cec_transmit(struct cec_adapter *adap, u8 attempts,
>>> +   u32 signal_free_time, struct cec_msg *msg)
>>> +{
>>> +   struct dw_hdmi_cec *cec = adap->priv;
>>> +   unsigned i;
>>> +
>>> +   cec->retries = attempts;
>> I think you should check first if CEC engine is in normal
>> operation mode, as a safety measure.
> I'm not sure what you mean there, because the iMX6 manuals don't mention
> anything about that.  The only "modes" it talks about is initiator mode
> and follower mode.  Moreover, there's nothing in what was FSL's driver
> that hints at that either.
>
> Maybe you could provide some further technical information on this
> point?
>

You should check that CEC is: not in standy, acknowledges
broadcast messages, signal free time is 5bit period, and not lost
arbitration, which basically means CEC_CTRL must be 0x2 and
IH_CEC_STAT0 must not have ARB_LOST set. I do know you set 0x3 at
the end of this function but according to all the docs I have you
must first set 0x2 before writing message.

Best regards,
Jose Miguel Abreu
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm/bridge: Add Cadence DSI driver

[Boris Brezillon]

Add a driver for Cadence DPI -> DSI bridge.

Signed-off-by: Boris Brezillon 
---
 drivers/gpu/drm/bridge/Kconfig|7 +
 drivers/gpu/drm/bridge/Makefile   |1 +
 drivers/gpu/drm/bridge/cdns-dsi.c | 1087 +
 3 files changed, 1095 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/cdns-dsi.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index f6968d3b4b41..07175dca1f8a 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -17,6 +17,13 @@ config DRM_ANALOGIX_ANX78XX
  the HDMI output of an application processor to MyDP
  or DisplayPort.
 
+config DRM_CDNS_DSI
+   tristate "Cadence DPI/DSI bridge"
+   select DRM_KMS_HELPER
+   select DRM_MIPI_DSI
+   help
+ Support Cadence DPI to DSI bridge.
+
 config DRM_DUMB_VGA_DAC
tristate "Dumb VGA DAC Bridge support"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 3fe2226ee2f2..73a3e32a8005 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -1,6 +1,7 @@
 ccflags-y := -Iinclude/drm
 
 obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
+obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
 obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
 obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o
 obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) += 
megachips-stdp-ge-b850v3-fw.o
diff --git a/drivers/gpu/drm/bridge/cdns-dsi.c 
b/drivers/gpu/drm/bridge/cdns-dsi.c
new file mode 100644
index ..aa049367f4b9
--- /dev/null
+++ b/drivers/gpu/drm/bridge/cdns-dsi.c
@@ -0,0 +1,1087 @@
+/*
+ * Copyright: 2017 Cadence Design Systems, Inc.
+ *
+ * Author: Boris Brezillon 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#define MCTL_MAIN_DATA_CTL 0x4
+#define DIS_DYN_CLK_CTLBIT(30)
+#define IF_INTERLACED_EN(x)BIT(26 + (x))
+#define TE_MIPI_POLLING_EN BIT(25)
+#define TE_HW_POLLING_EN   BIT(24)
+#define DISP_EOT_GEN   BIT(18)
+#define HOST_EOT_GEN   BIT(17)
+#define DISP_GEN_CHECKSUM  BIT(16)
+#define DISP_GEN_ECC   BIT(15)
+#define BTA_EN BIT(14)
+#define READ_ENBIT(13)
+#define REG_TE_EN  BIT(12)
+#define IF_TE_EN(x)BIT(8 + (x))
+#define TBG_SELBIT(7)
+#define TVG_SELBIT(6)
+#define VID_EN BIT(5)
+#define IF_VID_SELECT(x)   ((x) << 2)
+#define IF_VID_SELECT_MASK GENMASK(4, 2)
+#define IF_VID_MODEBIT(1)
+#define LINK_ENBIT(0)
+
+#define MCTL_MAIN_PHY_CTL  0x8
+#define CLK_FORCE_STOP BIT(14)
+#define WAIT_BURST_TIME(x) ((x) << 10)
+#define DATA_ULPM_EN(x)BIT(6 + (x))
+#define CLK_ULPM_ENBIT(5)
+#define CLK_CONTINUOUS BIT(4)
+#define DATA_FORCE_STOPBIT(3)
+#define DATA_LANE_EN(x)BIT((x) - 1)
+
+#define MCTL_LANE_STS  0x10
+#define LANE_STATE_START   0
+#define LANE_STATE_IDLE1
+#define LANE_STATE_WRITE   2
+#define LANE_STATE_ULPM3
+#define LANE_STATE_READ4
+#define DATA_LANE_STATE(l, val)\
+   (((val) >> (2 + 2 * (l) + ((l) ? 1 : 0))) & GENMASK((l) ? 1 : 2, 0))
+#define CLK_LANE_STATE_HS  2
+#define CLK_LANE_STATE(val)((val) & GENMASK(1, 0))
+
+#define MCTL_DPHY_TIMEOUT1 0x14
+#define CLK_DIV(x) (x)
+#define HSTX_TIMEOUT(x)((x) << 4)
+
+#define MCTL_DPHY_TIMEOUT2 0x18
+#define LPRX_TIMEOUT(x)(x)
+
+#define MCTL_ULPOUT_TIME   0x1c
+#define DATA_LANE_ULPOUT_TIME(x)   ((x) << 9)
+#define CLK_LANE_ULPOUT_TIME(x)(x)
+
+#define MCTL_DPHY_STATIC   0x20
+#define CLK_UNIT_INTERVAL(x)   (((x) / 4) 

[PATCH 2/2] dt-bindings: drm/bridge: Document Cadence DSI bridge bindings

[Boris Brezillon]

Document the bindings used for the Cadence DSI bridge.

Signed-off-by: Boris Brezillon 
---
 .../bindings/display/bridge/cdns,dsi.txt   | 55 ++
 1 file changed, 55 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt

diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt 
b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt
new file mode 100644
index ..770c5c5b1e93
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt
@@ -0,0 +1,55 @@
+Cadence DSI bridge
+==
+
+The Cadence DSI bridge is a DPI to DSI bridge supporting up to 4 DSI lanes.
+
+Required properties:
+- compatible: should be set to "cdns,dsi".
+- reg: physical base address and length of the controller's registers.
+- interrupts: interrupt line connected to the DSI bridge.
+- clocks: DSI bridge clocks.
+- clock-names: must contain "pclk" and "sysclk".
+- phys: phandle link to the MIPI D-PHY controller.
+- phy-names: must contain "dphy".
+- #address-cells: must be set to 1.
+- #size-cells: must be set to 0.
+
+Required subnodes:
+- ports: Ports as described in Documentation/devicetree/bindings/graph.txt.
+  Currently contains a single input port at address 0 representing the DPI
+  input. Other ports will be added later to support the SDI inputs.
+  Port 0 should be connected to a DPI encoder output.
+- one subnode per DSI device connected on the DSI bus. Each DSI device should
+  contain a reg property encoding its address on the bus.
+
+Example:
+
+   dsi0: dsi@fd0c {
+   compatible = "cdns,dsi";
+   reg = <0x0 0xfd0c 0x0 0x1000>;
+   clocks = <>, <>;
+   clock-names = "pclk", "hclk";
+   interrupts = <1>;
+   phys = <>;
+   phy-names = "dphy";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   dsi0_dpi_input: endpoint {
+   remote-endpoint = <_dpi_output>;
+   };
+   };
+   };
+
+   panel: dsi-dev@0 {
+   compatible = "";
+   reg = <0>;
+   };
+   };
+
-- 
2.7.4

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

[PATCH] cec: add cec_transmit_attempt_done helper function

[Hans Verkuil]

A simpler variant of cec_transmit_done to be used where the HW does
just a single attempt at a transmit. So if the status indicates an
error, then the corresponding error count will always be 1 and this
function figures that out based on the status argument.

Signed-off-by: Hans Verkuil 
---
Russell, this should simplify things for you.
---
 Documentation/media/kapi/cec-core.rst | 10 ++
 drivers/media/cec/cec-adap.c  | 26 ++
 include/media/cec.h   |  6 ++
 3 files changed, 42 insertions(+)

diff --git a/Documentation/media/kapi/cec-core.rst 
b/Documentation/media/kapi/cec-core.rst
index 7a04c5386dc8..25728545e4ec 100644
--- a/Documentation/media/kapi/cec-core.rst
+++ b/Documentation/media/kapi/cec-core.rst
@@ -194,6 +194,11 @@ When a transmit finished (successfully or otherwise):
void cec_transmit_done(struct cec_adapter *adap, u8 status, u8 
arb_lost_cnt,
   u8 nack_cnt, u8 low_drive_cnt, u8 error_cnt);

+or:
+
+.. c:function::
+   void cec_transmit_attempt_done(struct cec_adapter *adap, u8 status);
+
 The status can be one of:

 CEC_TX_STATUS_OK:
@@ -231,6 +236,11 @@ to 1, if the hardware does support retry then either set 
these counters to
 0 if the hardware provides no feedback of which errors occurred and how many
 times, or fill in the correct values as reported by the hardware.

+The cec_transmit_attempt_done() function is a helper for cases where the
+hardware never retries, so the transmit was always for just a single
+attempt. It will call cec_transmit_done() in turn, filling in 1 for the
+count argument corresponding to the status. Or all 0 if the status was OK.
+
 When a CEC message was received:

 .. c:function::
diff --git a/drivers/media/cec/cec-adap.c b/drivers/media/cec/cec-adap.c
index f5fe01c9da8a..0f4621cd8748 100644
--- a/drivers/media/cec/cec-adap.c
+++ b/drivers/media/cec/cec-adap.c
@@ -544,6 +544,32 @@ void cec_transmit_done(struct cec_adapter *adap, u8 
status, u8 arb_lost_cnt,
 }
 EXPORT_SYMBOL_GPL(cec_transmit_done);

+void cec_transmit_attempt_done(struct cec_adapter *adap, u8 status)
+{
+   switch (status) {
+   case CEC_TX_STATUS_OK:
+   cec_transmit_done(adap, status, 0, 0, 0, 0);
+   return;
+   case CEC_TX_STATUS_ARB_LOST:
+   cec_transmit_done(adap, status, 1, 0, 0, 0);
+   return;
+   case CEC_TX_STATUS_NACK:
+   cec_transmit_done(adap, status, 0, 1, 0, 0);
+   return;
+   case CEC_TX_STATUS_LOW_DRIVE:
+   cec_transmit_done(adap, status, 0, 0, 1, 0);
+   return;
+   case CEC_TX_STATUS_ERROR:
+   cec_transmit_done(adap, status, 0, 0, 0, 1);
+   return;
+   default:
+   /* Should never happen */
+   WARN(1, "cec-%s: invalid status 0x%02x\n", adap->name, status);
+   return;
+   }
+}
+EXPORT_SYMBOL_GPL(cec_transmit_attempt_done);
+
 /*
  * Called when waiting for a reply times out.
  */
diff --git a/include/media/cec.h b/include/media/cec.h
index b8eb895731d5..5582e1cac1b9 100644
--- a/include/media/cec.h
+++ b/include/media/cec.h
@@ -223,6 +223,12 @@ int cec_transmit_msg(struct cec_adapter *adap, struct 
cec_msg *msg,
 /* Called by the adapter */
 void cec_transmit_done(struct cec_adapter *adap, u8 status, u8 arb_lost_cnt,
   u8 nack_cnt, u8 low_drive_cnt, u8 error_cnt);
+/*
+ * Simplified version of cec_transmit_done for hardware that doesn't retry
+ * failed transmits. So this is was always just one attempt in which case
+ * the status is sufficient.
+ */
+void cec_transmit_attempt_done(struct cec_adapter *adap, u8 status);
 void cec_received_msg(struct cec_adapter *adap, struct cec_msg *msg);

 /**
--
2.11.0

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

Re: [PATCH] drm/vc4: Mark the device as active when enabling runtime PM.

[Boris Brezillon]

On Mon, 15 May 2017 10:16:15 -0700
Eric Anholt  wrote:

> Failing to do so meant that we got a resume() callback on first use of
> the device, so we would leak the bin BO that we allocated during
> probe.
> 
> Signed-off-by: Eric Anholt 
> Fixes: 553c942f8b2c ("drm/vc4: Allow using more than 256MB of CMA memory.")

Reviewed-by: Boris Brezillon 

> ---
>  drivers/gpu/drm/vc4/vc4_v3d.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/vc4/vc4_v3d.c b/drivers/gpu/drm/vc4/vc4_v3d.c
> index e3d5c59dbd4a..825a8462a63b 100644
> --- a/drivers/gpu/drm/vc4/vc4_v3d.c
> +++ b/drivers/gpu/drm/vc4/vc4_v3d.c
> @@ -403,6 +403,7 @@ static int vc4_v3d_bind(struct device *dev, struct device 
> *master, void *data)
>   return ret;
>   }
>  
> + pm_runtime_set_active(dev);
>   pm_runtime_use_autosuspend(dev);
>   pm_runtime_set_autosuspend_delay(dev, 40); /* a little over 2 frames. */
>   pm_runtime_enable(dev);

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

Re: [PATCH 4/4] drm/bridge: dw-hdmi: add cec driver

[Hans Verkuil]

On 06/01/2017 03:47 PM, Neil Armstrong wrote:

On 05/30/2017 04:23 PM, Russell King wrote:

Add a CEC driver for the dw-hdmi hardware.

Signed-off-by: Russell King 
---
  drivers/gpu/drm/bridge/synopsys/Kconfig   |   8 +
  drivers/gpu/drm/bridge/synopsys/Makefile  |   1 +
  drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c | 320 ++
  drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.h |  19 ++
  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |  40 +++-
  5 files changed, 387 insertions(+), 1 deletion(-)
  create mode 100644 drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c
  create mode 100644 drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.h

diff --git a/drivers/gpu/drm/bridge/synopsys/Kconfig 
b/drivers/gpu/drm/bridge/synopsys/Kconfig
index 40d2827a6d19..bd30a0a07272 100644
--- a/drivers/gpu/drm/bridge/synopsys/Kconfig
+++ b/drivers/gpu/drm/bridge/synopsys/Kconfig
@@ -21,3 +21,11 @@ config DRM_DW_HDMI_I2S_AUDIO
help
  Support the I2S Audio interface which is part of the Synopsys
  Designware HDMI block.
+
+config DRM_DW_HDMI_CEC
+   tristate "Synopsis Designware CEC interface"
+   depends on DRM_DW_HDMI && MEDIA_CEC_SUPPORT
+   select MEDIA_CEC_NOTIFIER
+   help
+ Support the CE interface which is part of the Synopsis
+ Designware HDMI block.
diff --git a/drivers/gpu/drm/bridge/synopsys/Makefile 
b/drivers/gpu/drm/bridge/synopsys/Makefile
index 17aa7a65b57e..6fe415903668 100644
--- a/drivers/gpu/drm/bridge/synopsys/Makefile
+++ b/drivers/gpu/drm/bridge/synopsys/Makefile
@@ -3,3 +3,4 @@
  obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
  obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
  obj-$(CONFIG_DRM_DW_HDMI_I2S_AUDIO) += dw-hdmi-i2s-audio.o
+obj-$(CONFIG_DRM_DW_HDMI_CEC) += dw-hdmi-cec.o
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c
new file mode 100644
index ..761ef5ae687d
--- /dev/null
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-cec.c
@@ -0,0 +1,320 @@
+/*
+ * Designware HDMI CEC driver
+ *
+ * Copyright (C) 2015-2017 Russell King.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+
+#include "dw-hdmi-cec.h"
+
+enum {
+   HDMI_IH_CEC_STAT0   = 0x0106,
+   HDMI_IH_MUTE_CEC_STAT0  = 0x0186,
+
+   HDMI_CEC_CTRL   = 0x7d00,
+   CEC_CTRL_START  = BIT(0),
+   CEC_CTRL_NORMAL = 1 << 1,
+
+   HDMI_CEC_STAT   = 0x7d01,
+   CEC_STAT_DONE   = BIT(0),
+   CEC_STAT_EOM= BIT(1),
+   CEC_STAT_NACK   = BIT(2),
+   CEC_STAT_ARBLOST= BIT(3),
+   CEC_STAT_ERROR_INIT = BIT(4),
+   CEC_STAT_ERROR_FOLL = BIT(5),
+   CEC_STAT_WAKEUP = BIT(6),


I hadn't realized until Jose Abreu's latest reply, but you need to check the
ARBLOST status and set the TX state to CEC_TX_STATUS_ARB_LOST.

I think CEC_STAT_ERROR_FOLL might equal CEC_TX_STATUS_LOW_DRIVE, but without
documentation I can't be sure.

My experience is that this low drive condition tends to be poorly reported by
hardware. Either that or poorly documented. This is why I added a
CEC_TX_STATUS_ERROR status as a catch-all error status when it is unclear from
the hardware/documentation what error occurred.

Jose, do you know which status bit is used to report a follower pulling the
CEC line low for a long time (approx. 3.6 ms) to signal a CEC error?

Regards,

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