RE: [PATCH 2/9] drm/syncobj: add new drm_syncobj_add_point interface v4

[Zhou, David(ChunMing)]

> -Original Message-
> From: Lionel Landwerlin 
> Sent: Saturday, March 30, 2019 10:09 PM
> To: Koenig, Christian ; Zhou, David(ChunMing)
> ; dri-devel@lists.freedesktop.org; amd-
> g...@lists.freedesktop.org; ja...@jlekstrand.net; Hector, Tobias
> 
> Subject: Re: [PATCH 2/9] drm/syncobj: add new drm_syncobj_add_point
> interface v4
> 
> On 28/03/2019 15:18, Christian König wrote:
> > Am 28.03.19 um 14:50 schrieb Lionel Landwerlin:
> >> On 25/03/2019 08:32, Chunming Zhou wrote:
> >>> From: Christian König 
> >>>
> >>> Use the dma_fence_chain object to create a timeline of fence objects
> >>> instead of just replacing the existing fence.
> >>>
> >>> v2: rebase and cleanup
> >>> v3: fix garbage collection parameters
> >>> v4: add unorder point check, print a warn calltrace
> >>>
> >>> Signed-off-by: Christian König 
> >>> Cc: Lionel Landwerlin 
> >>> ---
> >>>   drivers/gpu/drm/drm_syncobj.c | 39
> >>> +++
> >>>   include/drm/drm_syncobj.h |  5 +
> >>>   2 files changed, 44 insertions(+)
> >>>
> >>> diff --git a/drivers/gpu/drm/drm_syncobj.c
> >>> b/drivers/gpu/drm/drm_syncobj.c index 5329e66598c6..19a9ce638119
> >>> 100644
> >>> --- a/drivers/gpu/drm/drm_syncobj.c
> >>> +++ b/drivers/gpu/drm/drm_syncobj.c
> >>> @@ -122,6 +122,45 @@ static void drm_syncobj_remove_wait(struct
> >>> drm_syncobj *syncobj,
> >>>   spin_unlock(>lock);
> >>>   }
> >>>   +/**
> >>> + * drm_syncobj_add_point - add new timeline point to the syncobj
> >>> + * @syncobj: sync object to add timeline point do
> >>> + * @chain: chain node to use to add the point
> >>> + * @fence: fence to encapsulate in the chain node
> >>> + * @point: sequence number to use for the point
> >>> + *
> >>> + * Add the chain node as new timeline point to the syncobj.
> >>> + */
> >>> +void drm_syncobj_add_point(struct drm_syncobj *syncobj,
> >>> +   struct dma_fence_chain *chain,
> >>> +   struct dma_fence *fence,
> >>> +   uint64_t point)
> >>> +{
> >>> +    struct syncobj_wait_entry *cur, *tmp;
> >>> +    struct dma_fence *prev;
> >>> +
> >>> +    dma_fence_get(fence);
> >>> +
> >>> +    spin_lock(>lock);
> >>> +
> >>> +    prev = drm_syncobj_fence_get(syncobj);
> >>> +    /* You are adding an unorder point to timeline, which could
> >>> cause payload returned from query_ioctl is 0! */
> >>> +    WARN_ON_ONCE(prev && prev->seqno >= point);
> >>
> >>
> >> I think the WARN/BUG macros should only fire when there is an issue
> >> with programming from within the kernel.
> >>
> >> But this particular warning can be triggered by an application.
> >>
> >>
> >> Probably best to just remove it?
> >
> > Yeah, that was also my argument against it.
> >
> > Key point here is that we still want to note somehow that userspace
> > did something wrong and returning an error is not an option.
> >
> > Maybe just use DRM_ERROR with a static variable to print the message
> > only once.
> >
> > Christian.
> 
> I don't really see any point in printing an error once. If you run your
> application twice you end up thinking there was an issue just on the first run
> but it's actually always wrong.
> 

Except this nitpick, is there any other concern to push whole patch set? Is 
that time to push whole patch set?

-David

> 
> Unless we're willing to take the syncobj lock for longer periods of time when
> adding points, I guess we'll have to defer validation to validation layers.
> 
> 
> -Lionel
> 
> >
> >>
> >>
> >> -Lionel
> >>
> >>
> >>> +    dma_fence_chain_init(chain, prev, fence, point);
> >>> +    rcu_assign_pointer(syncobj->fence, >base);
> >>> +
> >>> +    list_for_each_entry_safe(cur, tmp, >cb_list, node) {
> >>> +    list_del_init(>node);
> >>> +    syncobj_wait_syncobj_func(syncobj, cur);
> >>> +    }
> >>> +    spin_unlock(>lock);
> >>> +
> >>> +    /* Walk the chain once to trigger garbage collection */
> >>> +    dma_fence_chain_for_each(fence, prev);
> >>> +    dma_fence_put(prev);
> >>> +}
> >>> +EXPORT_SYMBOL(drm_syncobj_add_point);
> >>> +
> >>>   /**
> >>>    * drm_syncobj_replace_fence - replace fence in a sync object.
> >>>    * @syncobj: Sync object to replace fence in diff --git
> >>> a/include/drm/drm_syncobj.h b/include/drm/drm_syncobj.h index
> >>> 0311c9fdbd2f..6cf7243a1dc5 100644
> >>> --- a/include/drm/drm_syncobj.h
> >>> +++ b/include/drm/drm_syncobj.h
> >>> @@ -27,6 +27,7 @@
> >>>   #define __DRM_SYNCOBJ_H__
> >>>     #include 
> >>> +#include 
> >>>     struct drm_file;
> >>>   @@ -112,6 +113,10 @@ drm_syncobj_fence_get(struct drm_syncobj
> >>> *syncobj)
> >>>     struct drm_syncobj *drm_syncobj_find(struct drm_file
> >>> *file_private,
> >>>    u32 handle);
> >>> +void drm_syncobj_add_point(struct drm_syncobj *syncobj,
> >>> +   struct dma_fence_chain *chain,
> >>> +   struct dma_fence *fence,
> >>> +   uint64_t point);
> >>>   void drm_syncobj_replace_fence(struct drm_syncobj *syncobj,
> >>>    

[Bug 105832] radeonsi NIR missing bindless textures support

[bugzilla-daemon]

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

Timothy Arceri  changed:

   What|Removed |Added

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

--- Comment #22 from Timothy Arceri  ---
I'm going to close this bug. We have had partial bindless support in NIR for a
while now and full support should land along with MR 519 [1]. This bug doesn't
gain us anything extra.

[1] https://gitlab.freedesktop.org/mesa/mesa/merge_requests/519/

-- 
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-next: manual merge of the drm-intel tree with the drm-intel-fixes tree

[Stephen Rothwell]

Hi all,

This is now a conflict between the drm tree and Linus' tree.

On Fri, 22 Mar 2019 10:57:28 +1100 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the drm-intel tree got a conflict in:
> 
>   drivers/gpu/drm/i915/gvt/mmio_context.c
> 
> between commit:
> 
>   1e8b15a1988e ("drm/i915/gvt: Add in context mmio 0x20D8 to gen9 mmio list")
> 
> from the drm-intel-fixes tree and commit:
> 
>   8a68d464366e ("drm/i915: Store the BIT(engine->id) as the engine's mask")
> 
> from the drm-intel tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> diff --cc drivers/gpu/drm/i915/gvt/mmio_context.c
> index 7902fb162d09,a00a807a1d55..
> --- a/drivers/gpu/drm/i915/gvt/mmio_context.c
> +++ b/drivers/gpu/drm/i915/gvt/mmio_context.c
> @@@ -73,71 -73,70 +73,71 @@@ static struct engine_mmio gen8_engine_m
>   };
>   
>   static struct engine_mmio gen9_engine_mmio_list[] __cacheline_aligned = {
> - {RCS, GFX_MODE_GEN7, 0x, false}, /* 0x229c */
> - {RCS, GEN9_CTX_PREEMPT_REG, 0x0, false}, /* 0x2248 */
> - {RCS, HWSTAM, 0x0, false}, /* 0x2098 */
> - {RCS, INSTPM, 0x, true}, /* 0x20c0 */
> - {RCS, RING_FORCE_TO_NONPRIV(RENDER_RING_BASE, 0), 0, false}, /* 0x24d0 
> */
> - {RCS, RING_FORCE_TO_NONPRIV(RENDER_RING_BASE, 1), 0, false}, /* 0x24d4 
> */
> - {RCS, RING_FORCE_TO_NONPRIV(RENDER_RING_BASE, 2), 0, false}, /* 0x24d8 
> */
> - {RCS, RING_FORCE_TO_NONPRIV(RENDER_RING_BASE, 3), 0, false}, /* 0x24dc 
> */
> - {RCS, RING_FORCE_TO_NONPRIV(RENDER_RING_BASE, 4), 0, false}, /* 0x24e0 
> */
> - {RCS, RING_FORCE_TO_NONPRIV(RENDER_RING_BASE, 5), 0, false}, /* 0x24e4 
> */
> - {RCS, RING_FORCE_TO_NONPRIV(RENDER_RING_BASE, 6), 0, false}, /* 0x24e8 
> */
> - {RCS, RING_FORCE_TO_NONPRIV(RENDER_RING_BASE, 7), 0, false}, /* 0x24ec 
> */
> - {RCS, RING_FORCE_TO_NONPRIV(RENDER_RING_BASE, 8), 0, false}, /* 0x24f0 
> */
> - {RCS, RING_FORCE_TO_NONPRIV(RENDER_RING_BASE, 9), 0, false}, /* 0x24f4 
> */
> - {RCS, RING_FORCE_TO_NONPRIV(RENDER_RING_BASE, 10), 0, false}, /* 0x24f8 
> */
> - {RCS, RING_FORCE_TO_NONPRIV(RENDER_RING_BASE, 11), 0, false}, /* 0x24fc 
> */
> - {RCS, CACHE_MODE_1, 0x, true}, /* 0x7004 */
> - {RCS, GEN7_GT_MODE, 0x, true}, /* 0x7008 */
> - {RCS, CACHE_MODE_0_GEN7, 0x, true}, /* 0x7000 */
> - {RCS, GEN7_COMMON_SLICE_CHICKEN1, 0x, true}, /* 0x7010 */
> - {RCS, HDC_CHICKEN0, 0x, true}, /* 0x7300 */
> - {RCS, VF_GUARDBAND, 0x, true}, /* 0x83a4 */
> - 
> - {RCS, GEN8_PRIVATE_PAT_LO, 0, false}, /* 0x40e0 */
> - {RCS, GEN8_PRIVATE_PAT_HI, 0, false}, /* 0x40e4 */
> - {RCS, GEN8_CS_CHICKEN1, 0x, true}, /* 0x2580 */
> - {RCS, COMMON_SLICE_CHICKEN2, 0x, true}, /* 0x7014 */
> - {RCS, GEN9_CS_DEBUG_MODE1, 0x, false}, /* 0x20ec */
> - {RCS, GEN8_L3SQCREG4, 0, false}, /* 0xb118 */
> - {RCS, GEN7_HALF_SLICE_CHICKEN1, 0x, true}, /* 0xe100 */
> - {RCS, HALF_SLICE_CHICKEN2, 0x, true}, /* 0xe180 */
> - {RCS, HALF_SLICE_CHICKEN3, 0x, true}, /* 0xe184 */
> - {RCS, GEN9_HALF_SLICE_CHICKEN5, 0x, true}, /* 0xe188 */
> - {RCS, GEN9_HALF_SLICE_CHICKEN7, 0x, true}, /* 0xe194 */
> - {RCS, GEN8_ROW_CHICKEN, 0x, true}, /* 0xe4f0 */
> - {RCS, TRVATTL3PTRDW(0), 0, false}, /* 0x4de0 */
> - {RCS, TRVATTL3PTRDW(1), 0, false}, /* 0x4de4 */
> - {RCS, TRNULLDETCT, 0, false}, /* 0x4de8 */
> - {RCS, TRINVTILEDETCT, 0, false}, /* 0x4dec */
> - {RCS, TRVADR, 0, false}, /* 0x4df0 */
> - {RCS, TRTTE, 0, false}, /* 0x4df4 */
> - 
> - {BCS, RING_GFX_MODE(BLT_RING_BASE), 0x, false}, /* 0x2229c */
> - {BCS, RING_MI_MODE(BLT_RING_BASE), 0x, false}, /* 0x2209c */
> - {BCS, RING_INSTPM(BLT_RING_BASE), 0x, false}, /* 0x220c0 */
> - {BCS, RING_HWSTAM(BLT_RING_BASE), 0x0, false}, /* 0x22098 */
> - {BCS, RING_EXCC(BLT_RING_BASE), 0x0, false}, /* 0x22028 */
> - 
> - {VCS2, RING_EXCC(GEN8_BSD2_RING_BASE), 0x, false}, /* 0x1c028 */
> - 
> - {VECS, RING_EXCC(VEBOX_RING_BASE), 0x, false}, /* 0x1a028 */
> - 
> - {RCS, GEN8_HDC_CHICKEN1, 0x, true}, /* 0x7304 */
> - {RCS, GEN9_CTX_PREEMPT_REG, 0x0, false}, /* 0x2248 */
> - {RCS, GEN7_UCGCTL4, 0x0, false}, /* 0x940c */
> - {RCS, GAMT_CHKN_BIT_REG, 0x0, false}, /* 0x4ab8 */
> - 
> - {RCS, GEN9_GAMT_ECO_REG_RW_IA, 0x0, false}, /* 0x4ab0 */
> - {RCS, GEN9_CSFE_CHICKEN1_RCS, 0x, false}, /* 0x20d4 */
> - {RCS, _MMIO(0x20D8), 0x, true}, /* 0x20d8 */
> - 
> - {RCS, GEN8_GARBCNTL, 0x0, false}, /* 0xb004 */
> - {RCS, GEN7_FF_THREAD_MODE, 0x0, false}, /* 0x20a0 */
> - 

[Bug 110214] radeonsi: xterm scrollback buffer disappears while paging up/down

[bugzilla-daemon]

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

--- Comment #31 from Diego Viola  ---
I can't reproduce it on Ubuntu 18.04.2 or 19.04 beta.

-- 
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 110214] radeonsi: xterm scrollback buffer disappears while paging up/down

[bugzilla-daemon]

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

--- Comment #30 from Diego Viola  ---
I can reproduce this on Fedora 29 (workstation), I don't think the problem is
Arch Linux specific.

- XTerm(334)
- Linux 5.0.4-200.fc29.x86_64
- GNOME Version 3.30.2
- xorg-x11-server-Xorg-1.20.4-1.fc29.x86_64

-- 
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] fbdev: fix divide error in fb_var_to_videomode

[Fredrik Noring]

Hi Shile,

Thank you for your report and patch.

On Tue, Mar 26, 2019 at 01:54:13PM +0800, Shile Zhang wrote:
> Hi, Bartlomiej, Fredrik, Daniel,
> 
> Could you please help to have a look at this patch?

I have tested your patch with a MIPS R5900 system and indeed there is
a division by zero, although my kernel inhibits the exception that you
observed.

The statements

mode->refresh = 0;

if (!var->pixclock)
return;

a bit further up in fb_var_to_videomode seem to suggest that setting
mode->refresh to zero signals an invalid value. Your patch makes sense
to me in that having htotal or vtotal zero is equally absurd.

The note above the function could be improved to clarify the meaning
of assigning zero to mode->refresh. The refresh field is marked as
optional in the fb_videomode structure definition; perhaps zero is a
special value for this purpose.

Interestingly, the division by zero on the MIPS R5900 assigns -1 to
mode->refresh, which isn't zero as one might prefer for a video mode
that is invalid. Your patch would correct this anomaly.

Hopefully Bartlomiej or someone else with authority to approve your
patch submission will have a look at it.

Fredrik

> On 2019/3/19 20:20, shile.zh...@linux.alibaba.com wrote:
> > From: Shile Zhang 
> >
> > To fix following divide-by-zero error found by Syzkaller:
> >
> >divide error:  [#1] SMP PTI
> >CPU: 7 PID: 8447 Comm: test Kdump: loaded Not tainted 
> > 4.19.24-8.al7.x86_64 #1
> >Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 
> > rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org 04/01/2014
> >RIP: 0010:fb_var_to_videomode+0xae/0xc0
> >Code: 04 44 03 46 78 03 4e 7c 44 03 46 68 03 4e 70 89 ce d1 ee 69 c0 e8 
> > 03 00 00 f6 c2 01 0f 45 ce 83 e2 02 8d 34 09 0f 45 ce 31 d2 <41> f7 f0 31 
> > d2 f7 f1 89 47 08 f3 c3 66 0f 1f 44 00 00 0f 1f 44 00
> >RSP: 0018:b7e189347bf0 EFLAGS: 00010246
> >RAX: e1692410 RBX: b7e189347d60 RCX: 
> >RDX:  RSI:  RDI: b7e189347c10
> >RBP: 99972a091c00 R08:  R09: 
> >R10:  R11:  R12: 0100
> >R13: 0001 R14: 7ffd66baf6d0 R15: 
> >FS:  7f2054d11740() GS:99972fbc() 
> > knlGS:
> >CS:  0010 DS:  ES:  CR0: 80050033
> >CR2: 7f205481fd20 CR3: 0004288a0001 CR4: 001606a0
> >Call Trace:
> > fb_set_var+0x257/0x390
> > ? lookup_fast+0xbb/0x2b0
> > ? fb_open+0xc0/0x140
> > ? chrdev_open+0xa6/0x1a0
> > do_fb_ioctl+0x445/0x5a0
> > do_vfs_ioctl+0x92/0x5f0
> > ? __alloc_fd+0x3d/0x160
> > ksys_ioctl+0x60/0x90
> > __x64_sys_ioctl+0x16/0x20
> > do_syscall_64+0x5b/0x190
> > entry_SYSCALL_64_after_hwframe+0x44/0xa9
> >RIP: 0033:0x7f20548258d7
> >Code: 44 00 00 48 8b 05 b9 15 2d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff 
> > ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 
> > ff ff 73 01 c3 48 8b 0d 89 15 2d 00 f7 d8 64 89 01 48
> >
> > It can be triggered easily with following test code:
> >
> >#include 
> >#include 
> >#include 
> >int main(void)
> >{
> >struct fb_var_screeninfo var = {.activate = 0x100, .pixclock = 
> > 60};
> >int fd = open("/dev/fb0", O_RDWR);
> >if (fd < 0)
> >return 1;
> >
> >if (ioctl(fd, FBIOPUT_VSCREENINFO, ))
> >return 1;
> >
> >return 0;
> >}
> >
> > Signed-off-by: Shile Zhang 
> > ---
> >   drivers/video/fbdev/core/modedb.c | 3 +++
> >   1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/video/fbdev/core/modedb.c 
> > b/drivers/video/fbdev/core/modedb.c
> > index 283d9307..ac04987 100644
> > --- a/drivers/video/fbdev/core/modedb.c
> > +++ b/drivers/video/fbdev/core/modedb.c
> > @@ -935,6 +935,9 @@ void fb_var_to_videomode(struct fb_videomode *mode,
> > if (var->vmode & FB_VMODE_DOUBLE)
> > vtotal *= 2;
> >   
> > +   if (!htotal || !vtotal)
> > +   return;
> > +
> > hfreq = pixclock/htotal;
> > mode->refresh = hfreq/vtotal;
> >   }
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH] staging: android: ion: refactory ion_alloc for kernel driver use

[Zengtao (B)]

>-Original Message-
>From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org]
>Sent: Saturday, March 30, 2019 12:04 AM
>To: Zengtao (B) 
>Cc: labb...@redhat.com; sumit.sem...@linaro.org;
>de...@driverdev.osuosl.org; Todd Kjos ;
>linux-ker...@vger.kernel.org; dri-devel@lists.freedesktop.org;
>linaro-mm-...@lists.linaro.org; Arve Hjønnevåg ;
>Joel Fernandes ; Martijn Coenen
>; Christian Brauner 
>Subject: Re: [PATCH] staging: android: ion: refactory ion_alloc for kernel
>driver use
>
>On Sat, Mar 30, 2019 at 02:40:16AM +0800, Zeng Tao wrote:
>> There are two reasons for this patch:
>> 1. There are some potential requirements for ion_alloc in kernel
>> space, some media drivers need to allocate media buffers from ion
>> instead of buddy or dma framework, this is more convient and clean
>> very for media drivers. And In that case, ion is the only media buffer
>> provider, it's more easier to maintain.
>
>As this really is just DMA, what is wrong with the existing dma framework
>that makes it hard to use?  You have seen all of the changes recently to it,
>right?

The current dma framework is powerful enough(to me, and more complex ^_^)
, CMA, IOMMU are all integrated, it's good. But buffer sharing, statistics, 
debug,
 are not so friendly for media drivers(each driver has to do all, but duplicate 
jobs).

>
>thanks,
>
>greg k-h
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/stm: ltdc: fix data enable polarity

[Mukesh Ojha]

On 3/29/2019 9:20 PM, Yannick Fertré wrote:

Wrong DISPLAY_FLAGS used to set the data enable polarity.

Used or checked?
Can you also explain how it is wrong to check against this FLAG in commit?


Signed-off-by: Yannick Fertré 
---
  drivers/gpu/drm/stm/ltdc.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index b1741a9..6ba326a 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++ b/drivers/gpu/drm/stm/ltdc.c
@@ -555,7 +555,7 @@ static void ltdc_crtc_mode_set_nofb(struct drm_crtc *crtc)
if (vm.flags & DISPLAY_FLAGS_VSYNC_HIGH)
val |= GCR_VSPOL;
  
-	if (vm.flags & DISPLAY_FLAGS_DE_HIGH)

+   if (vm.flags & DISPLAY_FLAGS_DE_LOW)
val |= GCR_DEPOL;
  
  	if (vm.flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE)

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

RE: [PATCH] staging: android: ion: refactory ion_alloc for kernel driver use

[Zengtao (B)]

>-Original Message-
>From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org]
>Sent: Saturday, March 30, 2019 12:02 AM
>To: Zengtao (B) 
>Cc: labb...@redhat.com; sumit.sem...@linaro.org;
>de...@driverdev.osuosl.org; Todd Kjos ;
>linux-ker...@vger.kernel.org; dri-devel@lists.freedesktop.org;
>linaro-mm-...@lists.linaro.org; Arve Hjønnevåg ;
>Joel Fernandes ; Martijn Coenen
>; Christian Brauner 
>Subject: Re: [PATCH] staging: android: ion: refactory ion_alloc for kernel
>driver use
>
>On Sat, Mar 30, 2019 at 02:40:16AM +0800, Zeng Tao wrote:
>> There are two reasons for this patch:
>> 1. There are some potential requirements for ion_alloc in kernel
>> space, some media drivers need to allocate media buffers from ion
>> instead of buddy or dma framework, this is more convient and clean
>> very for media drivers. And In that case, ion is the only media buffer
>> provider, it's more easier to maintain.
>> 2. Fd is only needed by user processes, not the kernel space, so
>> dma_buf should be returned instead of fd for kernel space, and
>> dma_buf_fd should be called only for userspace api.
>>
>> Signed-off-by: Zeng Tao 
>> ---
>>  drivers/staging/android/ion/ion.c | 32
>> +---
>>  1 file changed, 17 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/staging/android/ion/ion.c
>> b/drivers/staging/android/ion/ion.c
>> index 92c2914..e93fb49 100644
>> --- a/drivers/staging/android/ion/ion.c
>> +++ b/drivers/staging/android/ion/ion.c
>> @@ -387,13 +387,13 @@ static const struct dma_buf_ops
>dma_buf_ops = {
>>  .unmap = ion_dma_buf_kunmap,
>>  };
>>
>> -static int ion_alloc(size_t len, unsigned int heap_id_mask, unsigned
>> int flags)
>> +struct dma_buf *ion_alloc(size_t len, unsigned int heap_id_mask,
>> +  unsigned int flags)
>>  {
>>  struct ion_device *dev = internal_dev;
>>  struct ion_buffer *buffer = NULL;
>>  struct ion_heap *heap;
>>  DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
>> -int fd;
>>  struct dma_buf *dmabuf;
>>
>>  pr_debug("%s: len %zu heap_id_mask %u flags %x\n", __func__,
>@@
>> -407,7 +407,7 @@ static int ion_alloc(size_t len, unsigned int
>heap_id_mask, unsigned int flags)
>>  len = PAGE_ALIGN(len);
>>
>>  if (!len)
>> -return -EINVAL;
>> +return ERR_PTR(-EINVAL);
>>
>>  down_read(>lock);
>>  plist_for_each_entry(heap, >heaps, node) { @@ -421,10
>+421,10
>> @@ static int ion_alloc(size_t len, unsigned int heap_id_mask,
>unsigned int flags)
>>  up_read(>lock);
>>
>>  if (!buffer)
>> -return -ENODEV;
>> +return ERR_PTR(-ENODEV);
>>
>>  if (IS_ERR(buffer))
>> -return PTR_ERR(buffer);
>> +return ERR_PTR(PTR_ERR(buffer));
>>
>>  exp_info.ops = _buf_ops;
>>  exp_info.size = buffer->size;
>> @@ -432,17 +432,12 @@ static int ion_alloc(size_t len, unsigned int
>heap_id_mask, unsigned int flags)
>>  exp_info.priv = buffer;
>>
>>  dmabuf = dma_buf_export(_info);
>> -if (IS_ERR(dmabuf)) {
>> +if (IS_ERR(dmabuf))
>>  _ion_buffer_destroy(buffer);
>> -return PTR_ERR(dmabuf);
>> -}
>>
>> -fd = dma_buf_fd(dmabuf, O_CLOEXEC);
>> -if (fd < 0)
>> -dma_buf_put(dmabuf);
>> -
>> -return fd;
>> +return dmabuf;
>>  }
>> +EXPORT_SYMBOL(ion_alloc);
>
>If you are going to do this (and personally I'm with Laura in that I don't
>think you need it) this should be EXPORT_SYMBOL_GPL() please.
>
Agree, thanks 

Regards
Zengtao 

>thanks,
>
>greg k-h
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v6 1/4] drm: rockchip: introduce rk3066 hdmi

[Johan Jonker]

From: Zheng Yang 

The RK3066 HDMI TX serves as interface between a LCD Controller and
a HDMI bus. A HDMI TX consists of one HDMI transmitter controller and
one HDMI transmitter PHY. The interface has three (3) 8-bit data channels
which can be configured for a number of bus widths (8/10/12/16/20/24-bit)
and different video formats (RGB, YCbCr).

Features:
HDMI version 1.4a, HDCP revision 1.4 and
DVI version 1.0 compliant transmitter.
Supports DTV resolutions from 480i to 1080i/p HD.
Master I2C interface for a DDC connection.
HDMI TX supports multiple power save modes.
The HDMI TX input can switch between LCDC0 and LCDC1.
(Sound support is not included in this patch)

Signed-off-by: Zheng Yang 
Signed-off-by: Johan Jonker 
---
 drivers/gpu/drm/rockchip/Kconfig|   8 +
 drivers/gpu/drm/rockchip/Makefile   |   1 +
 drivers/gpu/drm/rockchip/rk3066_hdmi.c  | 869 
 drivers/gpu/drm/rockchip/rk3066_hdmi.h  | 229 
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c |   2 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h |   1 +
 6 files changed, 1110 insertions(+)
 create mode 100644 drivers/gpu/drm/rockchip/rk3066_hdmi.c
 create mode 100644 drivers/gpu/drm/rockchip/rk3066_hdmi.h

diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 1e75196f9..2cdf3b62d 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -77,4 +77,12 @@ config ROCKCHIP_RGB
  Some Rockchip CRTCs, like rv1108, can directly output parallel
  and serial RGB format to panel or connect to a conversion chip.
  say Y to enable its driver.
+
+config ROCKCHIP_RK3066_HDMI
+   bool "Rockchip specific extensions for RK3066 HDMI"
+   depends on DRM_ROCKCHIP
+   help
+ This selects support for Rockchip SoC specific extensions
+ for the RK3066 HDMI driver. If you want to enable
+ HDMI on RK3066 based SoC, you should select this option.
 endif
diff --git a/drivers/gpu/drm/rockchip/Makefile 
b/drivers/gpu/drm/rockchip/Makefile
index f6fc9d5dd..524684ba7 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -15,5 +15,6 @@ rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += 
dw-mipi-dsi-rockchip.o
 rockchipdrm-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
 rockchipdrm-$(CONFIG_ROCKCHIP_LVDS) += rockchip_lvds.o
 rockchipdrm-$(CONFIG_ROCKCHIP_RGB) += rockchip_rgb.o
+rockchipdrm-$(CONFIG_ROCKCHIP_RK3066_HDMI) += rk3066_hdmi.o
 
 obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o
diff --git a/drivers/gpu/drm/rockchip/rk3066_hdmi.c 
b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
new file mode 100644
index 0..dd7bd3159
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
@@ -0,0 +1,869 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
+ *Zheng Yang 
+ */
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include "rk3066_hdmi.h"
+
+#include "rockchip_drm_drv.h"
+#include "rockchip_drm_vop.h"
+
+#define DEFAULT_PLLA_RATE 3000
+
+struct hdmi_data_info {
+   int vic; /* The CEA Video ID (VIC) of the current drm display mode. */
+   bool sink_is_hdmi;
+   unsigned int enc_out_format;
+   unsigned int colorimetry;
+};
+
+struct rk3066_hdmi_i2c {
+   struct i2c_adapter adap;
+
+   u8 ddc_addr;
+   u8 segment_addr;
+   u8 stat;
+
+   struct mutex i2c_lock; /* For i2c operation. */
+   struct completion cmpltn;
+};
+
+struct rk3066_hdmi {
+   struct device *dev;
+   struct drm_device *drm_dev;
+   struct regmap *grf_regmap;
+   int irq;
+   struct clk *hclk;
+   void __iomem *regs;
+
+   struct drm_connector connector;
+   struct drm_encoder encoder;
+
+   struct rk3066_hdmi_i2c *i2c;
+   struct i2c_adapter *ddc;
+
+   unsigned int tmdsclk;
+
+   struct hdmi_data_info hdmi_data;
+   struct drm_display_mode previous_mode;
+};
+
+#define to_rk3066_hdmi(x) container_of(x, struct rk3066_hdmi, x)
+
+static inline u8 hdmi_readb(struct rk3066_hdmi *hdmi, u16 offset)
+{
+   return readl_relaxed(hdmi->regs + offset);
+}
+
+static inline void hdmi_writeb(struct rk3066_hdmi *hdmi, u16 offset, u32 val)
+{
+   writel_relaxed(val, hdmi->regs + offset);
+}
+
+static inline void hdmi_modb(struct rk3066_hdmi *hdmi, u16 offset,
+u32 msk, u32 val)
+{
+   u8 temp = hdmi_readb(hdmi, offset) & ~msk;
+
+   temp |= val & msk;
+   hdmi_writeb(hdmi, offset, temp);
+}
+
+static void rk3066_hdmi_i2c_init(struct rk3066_hdmi *hdmi)
+{
+   int ddc_bus_freq;
+
+   ddc_bus_freq = (hdmi->tmdsclk >> 2) / HDMI_SCL_RATE;
+
+   hdmi_writeb(hdmi, HDMI_DDC_BUS_FREQ_L, ddc_bus_freq & 0xFF);
+   hdmi_writeb(hdmi, HDMI_DDC_BUS_FREQ_H, (ddc_bus_freq >> 8) & 0xFF);
+
+   /* Clear the EDID interrupt flag and mute the interrupt. */
+   hdmi_modb(hdmi, HDMI_INTR_MASK1, 

Re: Re: [PATCH v3 1/4] drm/bridge: sil_sii8620: depend on INPUT instead of selecting it.

[Life is hard, and then you die]

On Thu, Mar 28, 2019 at 12:48:39PM +0100, Andrzej Hajda wrote:
> On 28.03.2019 01:07, Life is hard, and then you die wrote:
> >
> > On Wed, Mar 27, 2019 at 03:13:37PM +0100, Andrzej Hajda wrote:
> >> +cc: dri-devel
[snip]
> > It seems your mail client doesn't like me :-) I got neither of your
> > responses. Sorry, I should've checked the archives when I didn't hear
> > anything. In any case thank you for your review, and I will update
> > that patch and send out a new version shortly.
> 
> I see where is the problem: Your mail client (mutt I suppose) sets
> Mail-Followup-To header to all recipients (To and Cc) without the
> sender. And my client (thunderbird) after pressing "Reply-All" checks
> for Mail-Followup-To field, if present it uses only it to set
> recipients, so in your case it does not response to the original author.
> 
> I do not know which mail client works incorrectly in this case, but for
> sure it is not what we want :)
> 
> I do not know how to solve the issue in thunderbird, maybe mutt is more
> configurable?

Thanks for debugging this! I'm sorry, but it looks like this was an
error on my part. So for anybody else using mutt: by default, mutt
will add a Mail-Followup-To header without your own address when
sending mail to any lists you are subscribed to, as defined by the
'subscribe' command (to avoid receiving replies in duplicate, i.e.
once via to/cc and once via the list). Unfortunately I was using a
regex there that included all freedesktop.org lists, not just ones I'm
actually subscribed to, and hence it thought I was subscribed
dri-devel too, leading to the this screwup.

Apologies for this - I guess even after more than 2 decades of mutt
and mailing lists I still manage to not know all its ins and outs.
But it should be fixed now.


  Cheers,

  Ronald

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

RE: [PATCH] staging: android: ion: refactory ion_alloc for kernel driver use

[Zengtao (B)]

>-Original Message-
>From: Dan Carpenter [mailto:dan.carpen...@oracle.com]
>Sent: Friday, March 29, 2019 7:03 PM
>To: Zengtao (B) 
>Cc: labb...@redhat.com; sumit.sem...@linaro.org;
>de...@driverdev.osuosl.org; Todd Kjos ; Greg
>Kroah-Hartman ;
>linux-ker...@vger.kernel.org; dri-devel@lists.freedesktop.org;
>linaro-mm-...@lists.linaro.org; Arve Hjønnevåg ;
>Joel Fernandes ; Martijn Coenen
>; Christian Brauner 
>Subject: Re: [PATCH] staging: android: ion: refactory ion_alloc for kernel
>driver use
>
>If we're going to export ion_alloc() for other drivers to use then let's make
>an ion_free() helper function as well.
>

Good catch, thanks. 

Regards
Zengtao 

>void ion_free(struct dma_buf *dmabuf)
>{
>   dma_buf_put(dmabuf);
>}
>
>regards,
>dan carpenter

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

Re: linux-next: Tree for Mar 29 (i915, no ACPI)

[Randy Dunlap]

On 3/28/19 8:18 PM, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20190328:
> 
> The pidfd tree lost its build failures.
> 

on x86_64, when # CONFIG_ACPI is not set/enabled:

ld: drivers/gpu/drm/i915/intel_panel.o: in function 
`intel_backlight_device_register':
intel_panel.c:(.text+0x2c49): undefined reference to `backlight_device_register'
ld: drivers/gpu/drm/i915/intel_panel.o: in function 
`intel_backlight_device_unregister':
intel_panel.c:(.text+0x2d01): undefined reference to 
`backlight_device_unregister'



Full randconfig file is attached.

-- 
~Randy
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 5.1.0-rc2 Kernel Configuration
#

#
# Compiler: gcc (SUSE Linux) 4.8.5
#
CONFIG_CC_IS_GCC=y
CONFIG_GCC_VERSION=40805
CONFIG_CLANG_VERSION=0
CONFIG_CC_HAS_ASM_GOTO=y
CONFIG_CC_HAS_WARN_MAYBE_UNINITIALIZED=y
CONFIG_CC_DISABLE_WARN_MAYBE_UNINITIALIZED=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y

#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_BUILD_SALT=""
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SYSVIPC=y
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_CROSS_MEMORY_ATTACH is not set
CONFIG_USELIB=y
# CONFIG_AUDIT is not set
CONFIG_HAVE_ARCH_AUDITSYSCALL=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_GENERIC_MSI_IRQ=y
CONFIG_GENERIC_MSI_IRQ_DOMAIN=y
CONFIG_GENERIC_IRQ_MATRIX_ALLOCATOR=y
CONFIG_GENERIC_IRQ_RESERVATION_MODE=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
# CONFIG_GENERIC_IRQ_DEBUGFS is not set
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_ARCH_CLOCKSOURCE_INIT=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
# CONFIG_NO_HZ is not set
# CONFIG_HIGH_RES_TIMERS is not set
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_COUNT=y

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set
# CONFIG_IRQ_TIME_ACCOUNTING is not set
# CONFIG_PSI is not set

#
# RCU Subsystem
#
CONFIG_PREEMPT_RCU=y
# CONFIG_RCU_EXPERT is not set
CONFIG_SRCU=y
CONFIG_TREE_SRCU=y
CONFIG_TASKS_RCU=y
CONFIG_RCU_STALL_COMMON=y
CONFIG_RCU_NEED_SEGCBLIST=y
CONFIG_BUILD_BIN2C=y
CONFIG_IKCONFIG=m
CONFIG_LOG_BUF_SHIFT=17
CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT=13
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH=y
CONFIG_ARCH_SUPPORTS_INT128=y
CONFIG_CGROUPS=y
CONFIG_PAGE_COUNTER=y
CONFIG_MEMCG=y
CONFIG_MEMCG_KMEM=y
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
# CONFIG_CFS_BANDWIDTH is not set
CONFIG_RT_GROUP_SCHED=y
CONFIG_CGROUP_PIDS=y
# CONFIG_CGROUP_RDMA is not set
CONFIG_CGROUP_FREEZER=y
# CONFIG_CGROUP_HUGETLB is not set
# CONFIG_CGROUP_DEVICE is not set
CONFIG_CGROUP_CPUACCT=y
CONFIG_CGROUP_PERF=y
CONFIG_CGROUP_BPF=y
# CONFIG_CGROUP_DEBUG is not set
CONFIG_SOCK_CGROUP_DATA=y
CONFIG_CHECKPOINT_RESTORE=y
CONFIG_SCHED_AUTOGROUP=y
# CONFIG_SYSFS_DEPRECATED is not set
CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
CONFIG_RD_BZIP2=y
# CONFIG_RD_LZMA is not set
# CONFIG_RD_XZ is not set
# CONFIG_RD_LZO is not set
# CONFIG_RD_LZ4 is not set
CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_ANON_INODES=y
CONFIG_SYSCTL_EXCEPTION_TRACE=y
CONFIG_HAVE_PCSPKR_PLATFORM=y
CONFIG_BPF=y
CONFIG_EXPERT=y
# CONFIG_MULTIUSER is not set
# CONFIG_SGETMASK_SYSCALL is not set
CONFIG_SYSFS_SYSCALL=y
CONFIG_FHANDLE=y
CONFIG_POSIX_TIMERS=y
CONFIG_PRINTK=y
CONFIG_PRINTK_NMI=y
CONFIG_BUG=y
CONFIG_PCSPKR_PLATFORM=y
# CONFIG_BASE_FULL is not set
# CONFIG_FUTEX is not set
# CONFIG_EPOLL is not set
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
# CONFIG_AIO is not set
CONFIG_IO_URING=y
CONFIG_ADVISE_SYSCALLS=y
CONFIG_MEMBARRIER=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_KALLSYMS_BASE_RELATIVE=y
CONFIG_BPF_SYSCALL=y
# CONFIG_USERFAULTFD is not set
CONFIG_ARCH_HAS_MEMBARRIER_SYNC_CORE=y
CONFIG_RSEQ=y
CONFIG_DEBUG_RSEQ=y
CONFIG_EMBEDDED=y
CONFIG_HAVE_PERF_EVENTS=y
CONFIG_PERF_USE_VMALLOC=y
# CONFIG_PC104 is not set

#
# Kernel Performance Events And Counters
#
CONFIG_PERF_EVENTS=y

[PATCH v6 0/4] Enable rk3066 VOP and HDMI for MK808

[Johan Jonker]

For testing only.

Version: V6

Title: Enable rk3066 VOP and HDMI for MK808.

This patch serie only works in combination with a MK808 TV stick and
a rk3066 processor. Other boxes and tablets with a rk3066
need extra software for power management and lcd's.

What does it do:

With these kernel patches a MK808 can show 2 penguins and a console
on a DVI-D monitor in combination with a framebuffer.

Not tested:

HDMI TV
HDCP
DRM
Xorg
Display managers
Android
etc.

Problems:

DRM functions keep changing every rc.
With v5.1-rc1 the monitor doesn't blank on poweroff, it freezes
due to a patch revert some time ago.

  drm/rockchip: shutdown drm subsystem on shutdown
https://patchwork.kernel.org/patch/10556151/
  drm/rockchip: Allow driver to be shutdown on reboot/kexec
https://patchwork.kernel.org/patch/10556135/
  [for-4.20] Revert "drm/rockchip: Allow driver to be shutdown on reboot/kexec"
https://patchwork.kernel.org/patch/10714725/

DVI-D monitors without CEA modes can add a fixed mode
to the kernel command line as workaround.
For example: video=HDMI-A-1:1280x720@60

HDMI sound not included.
etc.

///
Changes V6:

rk3066_hdmi.c
  add goto err_cleanup_hdmi to rk3066_hdmi_bind function
  small text style changes

///
Changes V5:

rockchip,rk3066-hdmi.txt
  add Reviewed-by tag

rk3066_hdmi.c
  change order in unbind function
  add goto err_disable_i2c to rk3066_hdmi_bind function
  change dev_foobar calls to their DRM_* equivalents
  remove rk3066_hdmi_i2c_irq function
  use define constants in rk3066_hdmi_encoder_enable function
  add comment to rk3066_hdmi_config_phy function
  small text style changes
  remove DVI-D support

rk3066_hdmi.h
  add define constants

///
Changes V4:

rockchip,rk3066-hdmi.txt
  change document name

rk3066_hdmi.c
  add more info in commit message
  replace deprecated drmP.h include
  small text style changes
  explain vic variable
  remove enc_in_format
  change lock name
  change regmap name
  change cmp name
  replace hdmi->dev by dev
  use sentinel
  use HDMI_VIDEO_VSYNC_OFFSET_SHIFT define
  remove unused module macros
  change driver name for dmesg

///
Changes V3:

updated to v5.0-rc8
removed patches that are already added to linux-next

rk3066_hdmi.c
  removed gpl text
  small style changes
  removed unused includes
  add include for:
drm_helper_hpd_irq_event
drm_helper_probe_single_connector_modes
  update drm_hdmi_avi_infoframe_from_display_mode function call

rk3066_hdmi.h
  removed gpl text

rk3066a.dtsi
  add extra port for hdmi connector node

rk3066a-mk808.dts
  add hdmi connector node
  connect hdmi_out with hdmi_con_in

rk3066-hdmi.txt
  add extra port for hdmi connector node

///

# How to make rkfs.cpio

find . | cpio -o --format=newc > ../rkfs.cpio

# How to compile/flash

make menuconfig  ARCH=arm CROSS_COMPILE=/usr/bin/arm-linux-gnueabi-
make -j4  ARCH=arm CROSS_COMPILE=/usr/bin/arm-linux-gnueabi-

cp ./arch/arm/boot/zImage ../zImage-dtb
cat ./arch/arm/boot/dts/rk3066a-mk808.dtb >> ../zImage-dtb
../tools/rkcrc -k ../zImage-dtb ../mk808.img
sudo ../tools/rkflashtool w 0x4000 0x8000 < ../mk808.img
sudo ../tools/rkflashtool b

///

Johan Jonker (2):
  ARM: dts: rockchip: rk3066a-mk808: enable vop0 and hdmi nodes
  dt-bindings: display: rockchip: add document for rk3066 hdmi

Zheng Yang (2):
  drm: rockchip: introduce rk3066 hdmi
  ARM: dts: rockchip: add rk3066 hdmi nodes

 .../display/rockchip/rockchip,rk3066-hdmi.txt  |  72 ++
 arch/arm/boot/dts/rk3066a-mk808.dts|  29 +
 arch/arm/boot/dts/rk3066a.dtsi |  52 ++
 drivers/gpu/drm/rockchip/Kconfig   |   8 +
 drivers/gpu/drm/rockchip/Makefile  |   1 +
 drivers/gpu/drm/rockchip/rk3066_hdmi.c | 869 +
 drivers/gpu/drm/rockchip/rk3066_hdmi.h | 229 ++
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c|   2 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h|   1 +
 9 files changed, 1263 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.txt
 create mode 100644 drivers/gpu/drm/rockchip/rk3066_hdmi.c
 create mode 100644 drivers/gpu/drm/rockchip/rk3066_hdmi.h

-- 
2.11.0

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

Re: WARNING in bpf_jit_free

[syzbot]

syzbot has bisected this bug to:

commit 0fff724a33917ac581b5825375d0b57affedee76
Author: Paul Kocialkowski 
Date:   Fri Jan 18 14:51:13 2019 +

drm/sun4i: backend: Use explicit fourcc helpers for packed YUV422 check

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=1467550f20
start commit:   0e40da3e Merge tag 'kbuild-fixes-v5.1' of git://git.kernel..
git tree:   upstream
final crash:https://syzkaller.appspot.com/x/report.txt?x=1667550f20
console output: https://syzkaller.appspot.com/x/log.txt?x=1267550f20
kernel config:  https://syzkaller.appspot.com/x/.config?x=8dcdce25ea72bedf
dashboard link: https://syzkaller.appspot.com/bug?extid=2ff1e7cb738fd3c41113
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=1697365320

Reported-by: syzbot+2ff1e7cb738fd3c41...@syzkaller.appspotmail.com
Fixes: 0fff724a3391 ("drm/sun4i: backend: Use explicit fourcc helpers for  
packed YUV422 check")


For information about bisection process see: https://goo.gl/tpsmEJ#bisection
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2] drm: prefix header search paths with $(srctree)/

[Masahiro Yamada]

Currently, the Kbuild core manipulates header search paths in a crazy
way [1].

To fix this mess, I want all Makefiles to add explicit $(srctree)/ to
the search paths in the srctree. Some Makefiles are already written in
that way, but not all. The goal of this work is to make the notation
consistent, and finally get rid of the gross hacks.

Having whitespaces after -I does not matter since commit 48f6e3cf5bc6
("kbuild: do not drop -I without parameter").

[1]: https://patchwork.kernel.org/patch/9632347/

Signed-off-by: Masahiro Yamada 
Reviewed-by: Sam Ravnborg 
---

I put all gpu/drm changes into a single patch because
they are trivial conversion.

If you are interested in the big picture of this work,
the full patch set is available at the following URL.

git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git 
build-test


Changes in v2:
  - fix up the new driver komeda
  - Add Sam's Reviewed-by

 drivers/gpu/drm/amd/amdgpu/Makefile | 2 +-
 drivers/gpu/drm/amd/lib/Makefile| 2 +-
 drivers/gpu/drm/arm/display/komeda/Makefile | 4 ++--
 drivers/gpu/drm/i915/gvt/Makefile   | 2 +-
 drivers/gpu/drm/msm/Makefile| 6 +++---
 drivers/gpu/drm/nouveau/Kbuild  | 8 
 6 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile 
b/drivers/gpu/drm/amd/amdgpu/Makefile
index 466da59..62bf9da 100644
--- a/drivers/gpu/drm/amd/amdgpu/Makefile
+++ b/drivers/gpu/drm/amd/amdgpu/Makefile
@@ -23,7 +23,7 @@
 # Makefile for the drm device driver.  This driver provides support for the
 # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
 
-FULL_AMD_PATH=$(src)/..
+FULL_AMD_PATH=$(srctree)/$(src)/..
 DISPLAY_FOLDER_NAME=display
 FULL_AMD_DISPLAY_PATH = $(FULL_AMD_PATH)/$(DISPLAY_FOLDER_NAME)
 
diff --git a/drivers/gpu/drm/amd/lib/Makefile b/drivers/gpu/drm/amd/lib/Makefile
index 6902430..d534992 100644
--- a/drivers/gpu/drm/amd/lib/Makefile
+++ b/drivers/gpu/drm/amd/lib/Makefile
@@ -27,6 +27,6 @@
 # driver components or later moved to kernel/lib for sharing with
 # other drivers.
 
-ccflags-y := -I$(src)/../include
+ccflags-y := -I $(srctree)/$(src)/../include
 
 obj-$(CONFIG_CHASH) += chash.o
diff --git a/drivers/gpu/drm/arm/display/komeda/Makefile 
b/drivers/gpu/drm/arm/display/komeda/Makefile
index 1b875e5..a72e30c 100644
--- a/drivers/gpu/drm/arm/display/komeda/Makefile
+++ b/drivers/gpu/drm/arm/display/komeda/Makefile
@@ -1,8 +1,8 @@
 # SPDX-License-Identifier: GPL-2.0
 
 ccflags-y := \
-   -I$(src)/../include \
-   -I$(src)
+   -I $(srctree)/$(src)/../include \
+   -I $(srctree)/$(src)
 
 komeda-y := \
komeda_drv.o \
diff --git a/drivers/gpu/drm/i915/gvt/Makefile 
b/drivers/gpu/drm/i915/gvt/Makefile
index 271fb46..ea8324a 100644
--- a/drivers/gpu/drm/i915/gvt/Makefile
+++ b/drivers/gpu/drm/i915/gvt/Makefile
@@ -5,5 +5,5 @@ GVT_SOURCE := gvt.o aperture_gm.o handlers.o vgpu.o 
trace_points.o firmware.o \
execlist.o scheduler.o sched_policy.o mmio_context.o cmd_parser.o 
debugfs.o \
fb_decoder.o dmabuf.o page_track.o
 
-ccflags-y  += -I$(src) -I$(src)/$(GVT_DIR)
+ccflags-y  += -I $(srctree)/$(src) -I 
$(srctree)/$(src)/$(GVT_DIR)/
 i915-y += $(addprefix $(GVT_DIR)/, 
$(GVT_SOURCE))
diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 56a70c7..b7b1ebd 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -1,7 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
-ccflags-y := -Idrivers/gpu/drm/msm
-ccflags-y += -Idrivers/gpu/drm/msm/disp/dpu1
-ccflags-$(CONFIG_DRM_MSM_DSI) += -Idrivers/gpu/drm/msm/dsi
+ccflags-y := -I $(srctree)/$(src)
+ccflags-y += -I $(srctree)/$(src)/disp/dpu1
+ccflags-$(CONFIG_DRM_MSM_DSI) += -I $(srctree)/$(src)/dsi
 
 msm-y := \
adreno/adreno_device.o \
diff --git a/drivers/gpu/drm/nouveau/Kbuild b/drivers/gpu/drm/nouveau/Kbuild
index ea3035e..4fae728 100644
--- a/drivers/gpu/drm/nouveau/Kbuild
+++ b/drivers/gpu/drm/nouveau/Kbuild
@@ -1,7 +1,7 @@
-ccflags-y += -I$(src)/include
-ccflags-y += -I$(src)/include/nvkm
-ccflags-y += -I$(src)/nvkm
-ccflags-y += -I$(src)
+ccflags-y += -I $(srctree)/$(src)/include
+ccflags-y += -I $(srctree)/$(src)/include/nvkm
+ccflags-y += -I $(srctree)/$(src)/nvkm
+ccflags-y += -I $(srctree)/$(src)
 
 # NVKM - HW resource manager
 #- code also used by various userspace tools/tests
-- 
2.7.4

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

Re: [PATCH] fbdev: fix divide error in fb_var_to_videomode

[Mukesh Ojha]

On 3/19/2019 5:50 PM, shile.zh...@linux.alibaba.com wrote:

From: Shile Zhang 

To fix following divide-by-zero error found by Syzkaller:

   divide error:  [#1] SMP PTI
   CPU: 7 PID: 8447 Comm: test Kdump: loaded Not tainted 4.19.24-8.al7.x86_64 #1
   Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 
rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org 04/01/2014
   RIP: 0010:fb_var_to_videomode+0xae/0xc0
   Code: 04 44 03 46 78 03 4e 7c 44 03 46 68 03 4e 70 89 ce d1 ee 69 c0 e8 03 00 00 
f6 c2 01 0f 45 ce 83 e2 02 8d 34 09 0f 45 ce 31 d2 <41> f7 f0 31 d2 f7 f1 89 47 
08 f3 c3 66 0f 1f 44 00 00 0f 1f 44 00
   RSP: 0018:b7e189347bf0 EFLAGS: 00010246
   RAX: e1692410 RBX: b7e189347d60 RCX: 
   RDX:  RSI:  RDI: b7e189347c10
   RBP: 99972a091c00 R08:  R09: 
   R10:  R11:  R12: 0100
   R13: 0001 R14: 7ffd66baf6d0 R15: 
   FS:  7f2054d11740() GS:99972fbc() knlGS:
   CS:  0010 DS:  ES:  CR0: 80050033
   CR2: 7f205481fd20 CR3: 0004288a0001 CR4: 001606a0
   Call Trace:
fb_set_var+0x257/0x390
? lookup_fast+0xbb/0x2b0
? fb_open+0xc0/0x140
? chrdev_open+0xa6/0x1a0
do_fb_ioctl+0x445/0x5a0
do_vfs_ioctl+0x92/0x5f0
? __alloc_fd+0x3d/0x160
ksys_ioctl+0x60/0x90
__x64_sys_ioctl+0x16/0x20
do_syscall_64+0x5b/0x190
entry_SYSCALL_64_after_hwframe+0x44/0xa9
   RIP: 0033:0x7f20548258d7
   Code: 44 00 00 48 8b 05 b9 15 2d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 
66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 
48 8b 0d 89 15 2d 00 f7 d8 64 89 01 48

It can be triggered easily with following test code:

   #include 
   #include 
   #include 
   int main(void)
   {
   struct fb_var_screeninfo var = {.activate = 0x100, .pixclock = 60};
   int fd = open("/dev/fb0", O_RDWR);
   if (fd < 0)
   return 1;

   if (ioctl(fd, FBIOPUT_VSCREENINFO, ))
   return 1;

   return 0;
   }

Signed-off-by: Shile Zhang 


To avoid any exception we should include the check.
Looks fine to me.
Reviewed-by: Mukesh Ojha 

Cheers,
-Mukesh


---
  drivers/video/fbdev/core/modedb.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/drivers/video/fbdev/core/modedb.c 
b/drivers/video/fbdev/core/modedb.c
index 283d9307..ac04987 100644
--- a/drivers/video/fbdev/core/modedb.c
+++ b/drivers/video/fbdev/core/modedb.c
@@ -935,6 +935,9 @@ void fb_var_to_videomode(struct fb_videomode *mode,
if (var->vmode & FB_VMODE_DOUBLE)
vtotal *= 2;
  
+	if (!htotal || !vtotal)

+   return;
+
hfreq = pixclock/htotal;
mode->refresh = hfreq/vtotal;
  }

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

RE: [PATCH] staging: android: ion: refactory ion_alloc for kernel driver use

[Zengtao (B)]

Hi laura: 

>-Original Message-
>From: Laura Abbott [mailto:labb...@redhat.com]
>Sent: Friday, March 29, 2019 9:27 PM
>To: Zengtao (B) ; sumit.sem...@linaro.org
>Cc: Greg Kroah-Hartman ; Arve Hjønnevåg
>; Todd Kjos ; Martijn Coenen
>; Joel Fernandes ;
>Christian Brauner ; de...@driverdev.osuosl.org;
>dri-devel@lists.freedesktop.org; linaro-mm-...@lists.linaro.org;
>linux-ker...@vger.kernel.org
>Subject: Re: [PATCH] staging: android: ion: refactory ion_alloc for kernel
>driver use
>
>On 3/29/19 11:40 AM, Zeng Tao wrote:
>> There are two reasons for this patch:
>> 1. There are some potential requirements for ion_alloc in kernel
>> space, some media drivers need to allocate media buffers from ion
>> instead of buddy or dma framework, this is more convient and clean
>> very for media drivers. And In that case, ion is the only media buffer
>> provider, it's more easier to maintain.
>> 2. Fd is only needed by user processes, not the kernel space, so
>> dma_buf should be returned instead of fd for kernel space, and
>> dma_buf_fd should be called only for userspace api.
>>
>
>I really want to just NAK this because it doesn't seem like something
>that's necessary. The purpose of Ion is to provide buffers to userspace
>because there's no other way for userspace to get access to the memory.
>The kernel already has other APIs to access the memory. This also
>complicates the re-work that's been happening where the requirement is
>only userspace.
>
>Can you be more detailed about which media drivers you are referring to
>and why they can't just use other APIs?
>

I think I 've got your point, the ION is designed for usespace, but for kernel
 space, we are really lacking of someone which plays the same role,(allocate 
media memory, share the memory using dma_buf, provide debug and statistics
for media memory).

In fact, for kernel space, we have the dma framework, dma-buf, etc..
And we can work on top of such apis, but some duplicate jobs(everyone has
 to maintain its own buffer sharing, debug and statistics).
So we need to have some to do the common things(ION's the best choice now)

When the ION was introduced, a lot of media memory frameworks existed, the
dma framework was not so good, so ION heaps, integrated buffer sharing, 
statistics
and usespace api were the required features, but now dma framework is more 
powerful,
we don't even need ION heaps now, but the userspace api, buffer sharing, 
statistics are
still needed, and the buffer sharing, statistics can be re-worked and export to 
kernel space,
not only used by userspace, , and that is my point.

>
>> Signed-off-by: Zeng Tao 
>> ---
>>   drivers/staging/android/ion/ion.c | 32
>+---
>>   1 file changed, 17 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/staging/android/ion/ion.c
>> b/drivers/staging/android/ion/ion.c
>> index 92c2914..e93fb49 100644
>> --- a/drivers/staging/android/ion/ion.c
>> +++ b/drivers/staging/android/ion/ion.c
>> @@ -387,13 +387,13 @@ static const struct dma_buf_ops
>dma_buf_ops = {
>>  .unmap = ion_dma_buf_kunmap,
>>   };
>>
>> -static int ion_alloc(size_t len, unsigned int heap_id_mask, unsigned
>> int flags)
>> +struct dma_buf *ion_alloc(size_t len, unsigned int heap_id_mask,
>> +  unsigned int flags)
>>   {
>>  struct ion_device *dev = internal_dev;
>>  struct ion_buffer *buffer = NULL;
>>  struct ion_heap *heap;
>>  DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
>> -int fd;
>>  struct dma_buf *dmabuf;
>>
>>  pr_debug("%s: len %zu heap_id_mask %u flags %x\n", __func__,
>@@
>> -407,7 +407,7 @@ static int ion_alloc(size_t len, unsigned int
>heap_id_mask, unsigned int flags)
>>  len = PAGE_ALIGN(len);
>>
>>  if (!len)
>> -return -EINVAL;
>> +return ERR_PTR(-EINVAL);
>>
>>  down_read(>lock);
>>  plist_for_each_entry(heap, >heaps, node) { @@ -421,10
>+421,10
>> @@ static int ion_alloc(size_t len, unsigned int heap_id_mask,
>unsigned int flags)
>>  up_read(>lock);
>>
>>  if (!buffer)
>> -return -ENODEV;
>> +return ERR_PTR(-ENODEV);
>>
>>  if (IS_ERR(buffer))
>> -return PTR_ERR(buffer);
>> +return ERR_PTR(PTR_ERR(buffer));
>>
>>  exp_info.ops = _buf_ops;
>>  exp_info.size = buffer->size;
>> @@ -432,17 +432,12 @@ static int ion_alloc(size_t len, unsigned int
>heap_id_mask, unsigned int flags)
>>  exp_info.priv = buffer;
>>
>>  dmabuf = dma_buf_export(_info);
>> -if (IS_ERR(dmabuf)) {
>> +if (IS_ERR(dmabuf))
>>  _ion_buffer_destroy(buffer);
>> -return PTR_ERR(dmabuf);
>> -}
>>
>> -fd = dma_buf_fd(dmabuf, O_CLOEXEC);
>> -if (fd < 0)
>> -dma_buf_put(dmabuf);
>> -
>> -return fd;
>> +return dmabuf;
>>   }
>> +EXPORT_SYMBOL(ion_alloc);
>>
>>   static int ion_query_heaps(struct ion_heap_query *query)
>>   {
>> @@ -539,12 +534,19 @@ static long ion_ioctl(struct file *filp, unsigned

Re: [RFC][PATCH 0/6 v3] DMA-BUF Heaps (destaging ION)

[Liam Mark]

On Fri, 29 Mar 2019, Andrew F. Davis wrote:

> On 3/28/19 7:15 PM, John Stultz wrote:
> > Here is another RFC of the dma-buf heaps patchset Andrew and I
> > have been working on which tries to destage a fair chunk of ION
> > functionality.
> > 
> > The patchset implements per-heap devices which can be opened
> > directly and then an ioctl is used to allocate a dmabuf from the
> > heap.
> > 
> > The interface is similar, but much simpler then IONs, only
> > providing an ALLOC ioctl.
> > 
> > Also, I've provided simple system and cma heaps. The system
> > heap in particular is missing the page-pool optimizations ION
> > had, but works well enough to validate the interface.
> > 
> > I've booted and tested these patches with AOSP on the HiKey960
> > using the kernel tree here:
> >   
> > https://git.linaro.org/people/john.stultz/android-dev.git/log/?h=dev/dma-buf-heap
> > 
> > And the userspace changes here:
> >   https://android-review.googlesource.com/c/device/linaro/hikey/+/909436
> > 
> > 
> > Compared to ION, this patchset is missing the system-contig,
> > carveout and chunk heaps, as I don't have a device that uses
> > those, so I'm unable to do much useful validation there.
> > Additionally we have no upstream users of chunk or carveout,
> > and the system-contig has been deprecated in the common/andoid-*
> > kernels, so this should be ok.
> > 
> 
> 
> I'd like to go over my use-cases for a moment to see if we can get some
> agreement on what to do with the carveout/chunk heaps.
> 
> We used DRM (omapdrm) to get buffers for display, GPU, and multi-media.
> Our out-of-tree CMEM driver[0] for remote processing (OpenCL/CV/VX)
> buffers. And for secure heaps we use what are basically slightly
> modified ION carveout heaps.
> 
> Now with the DMA-Heap framework what we can do is for sub-systems with
> IOMMUs use 'system' heap (GPU). For those that need contiguous memory
> (display, MM) we have 'cma' heap (and maybe 'system-contig' at some
> point). For our SRAM areas used in remote processing I've posted an RFC
> for a heap[1] to provide allocations from those areas.
> 
> The above leaves one last gap for us, uncached/unmapped areas from
> regular memory. I propose this is where we use the 'carveout' heap.
> Right now to get some contiguous/cached memory with DT you can:
> 
> reserved-memory {
>   [...]
>   cma_memory {
>   compatible = "shared-dma-pool";
>   reg = <0x7900 0x40>;
>   reusable;
>   };
> 
>   coherent_memory@7800 {
>   reg = <0x7800 0x80>;
>   no-map;
>   };
> };
> 
> 'cma_memory' will show up as a 'cma' heap, so all good there.
> 
> Looking at 'coherent_memory' it will not have valid backing 'struct
> page' and so cannot be given cached mappings as the standard dma memory
> ops would fail. This would give this area the right properties for both
> users who don't want to do all the cache maintenance ops (Liam?) and for
> secure heaps that have restrictions on access from Linux running CPU.
> 

So our main use case in which we use uncached memory to avoid cache 
maintenance is for multimedia memory (which is generally only accessed by 
devices), there can be both a lot of this memory allocated for these use 
cases and the amount varies so a carveout wouldn't work for us.
However I am still holding out hope that we will be able to drop this 
requirement for uncached memory through changes to both Android and 
ION/dma-buf heaps, such as the proposal where Android keeps devices 
attached and ION/dma-buf heaps track of which buffers are 'dirty'. 
Investigations still ongoing... 

We have a number of use cases which use uncached memory, the major reason 
that our clients use uncached is for the performance benefit above. I 
am currently doing a review of client use cases to determine all our 
uncached requirements, for example if CMA heaps will need to support 
uncached allocations, once that is done I will be able to better 
articulate our requirements.

One use case where I have seen carveouts uses which doesn't sound like it 
would be supported under the current proposals is when clients need to 
allocate a lot of cached memory quickly.
I have seen cases where a large carveout is used for camera use cases.
Basically they allocate cached memory from the carveout and any extra 
memory they need (after the carveout is full) is allocated from the system 
heap.

This allows for memory heavy performance sensitive apps, such as camera, 
to be launched quickly.

> The question then is how to mark these areas for export with DMA-Heaps?
> Maybe a cma_for_each_area() like function but for dma coherent areas?
> 

That sounds reasonable to me.

> Anyway for now this is not super important and I can post a patchset at
> some later point for this when I get it working and tested internally.
> 
> [0]
> http://software-dl.ti.com/processor-sdk-linux/esd/docs/latest/linux/Foundational_Components_CMEM.html
> [1] 

[PATCH v6 3/4] ARM: dts: rockchip: rk3066a-mk808: enable vop0 and hdmi nodes

[Johan Jonker]

This patch enables the vop0 and hdmi nodes
for a MK808 with rk3066 processor.

Signed-off-by: Johan Jonker 
---
 arch/arm/boot/dts/rk3066a-mk808.dts | 29 +
 1 file changed, 29 insertions(+)

diff --git a/arch/arm/boot/dts/rk3066a-mk808.dts 
b/arch/arm/boot/dts/rk3066a-mk808.dts
index 9d2216d71..8bc259d3e 100644
--- a/arch/arm/boot/dts/rk3066a-mk808.dts
+++ b/arch/arm/boot/dts/rk3066a-mk808.dts
@@ -30,6 +30,17 @@
};
};
 
+   hdmi_con {
+   compatible = "hdmi-connector";
+   type = "c";
+
+   port {
+   hdmi_con_in: endpoint {
+   remote-endpoint = <_out_con>;
+   };
+   };
+   };
+
vcc_io: vcc-io {
compatible = "regulator-fixed";
regulator-name = "vcc_io";
@@ -91,6 +102,20 @@
};
 };
 
+ {
+   status = "okay";
+};
+
+_in_vop1 {
+   status = "disabled";
+};
+
+_out {
+   hdmi_out_con: endpoint {
+   remote-endpoint = <_con_in>;
+   };
+};
+
  {
bus-width = <4>;
cap-mmc-highspeed;
@@ -150,6 +175,10 @@
status = "okay";
 };
 
+ {
+   status = "okay";
+};
+
  {
status = "okay";
 };
-- 
2.11.0

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

[PATCH -next] video: fbdev: remove set but not used variable 'size'

[YueHaibing]

Fixes gcc '-Wunused-but-set-variable' warning:

drivers/video/fbdev/pvr2fb.c: In function 'pvr2fb_init':
drivers/video/fbdev/pvr2fb.c:1074:6: warning:
 variable 'size' set but not used [-Wunused-but-set-variable]

It's not used since commit 9cd1c6743454 ("pvr2fb: Fix oops when
pseudo_palette is written")

Signed-off-by: YueHaibing 
---
 drivers/video/fbdev/pvr2fb.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/video/fbdev/pvr2fb.c b/drivers/video/fbdev/pvr2fb.c
index 41390c8e0f67..4e4d6a0df978 100644
--- a/drivers/video/fbdev/pvr2fb.c
+++ b/drivers/video/fbdev/pvr2fb.c
@@ -1071,7 +1071,6 @@ static struct pvr2_board {
 static int __init pvr2fb_init(void)
 {
int i, ret = -ENODEV;
-   int size;
 
 #ifndef MODULE
char *option = NULL;
@@ -1080,7 +1079,6 @@ static int __init pvr2fb_init(void)
return -ENODEV;
pvr2fb_setup(option);
 #endif
-   size = sizeof(struct fb_info) + sizeof(struct pvr2fb_par) + 16 * 
sizeof(u32);
 
fb_info = framebuffer_alloc(sizeof(struct pvr2fb_par), NULL);



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

Re: [RFC PATCH Xilinx Alveo 0/6] Xilinx PCIe accelerator driver

[Ronan KERYELL]

I am adding linux-f...@vger.kernel.org, since this is why I missed this
thread in the first place...

> On Fri, 29 Mar 2019 14:56:17 +1000, Dave Airlie  said:

Hi Dave!

Dave> On Thu, 28 Mar 2019 at 10:14, Sonal Santan  wrote:

>>> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch]

[...]

>>> Note: There's no expectation for the fully optimizing compiler,
>>> and we're totally ok if there's an optimizing proprietary
>>> compiler and a basic open one (amd, and bunch of other
>>> companies all have such dual stacks running on top of drm
>>> kernel drivers). But a basic compiler that can convert basic
>>> kernels into machine code is expected.

>> Although the compiler is not open source the compilation flow
>> lets users examine output from various stages. For example if you
>> write your kernel in OpenCL/C/C++ you can view the RTL
>> (Verilog/VHDL) output produced by first stage of compilation.
>> Note that the compiler is really generating a custom circuit
>> given a high level input which in the last phase gets synthesized
>> into bitstream. Expert hardware designers can handcraft a circuit
>> in RTL and feed it to the compiler. Our FPGA tools let you view
>> the generated hardware design, the register map, etc. You can get
>> more information about a compiled design by running XRT tool like
>> xclbinutil on the generated file.

>> In essence compiling for FPGAs is quite different than compiling
>> for GPU/CPU/DSP.  Interestingly FPGA compilers can run anywhere
>> from 30 mins to a few hours to compile a testcase.

Dave> So is there any open source userspace generator for what this
Dave> interface provides? Is the bitstream format that gets fed into
Dave> the FPGA proprietary and is it signed?

Short answer:

- a bitstream is an opaque content similar to various firmware handled
  by Linux, EFI capsules, x86 microcode, WiFi modems, etc.

- there is no open-source generator for what the interface consume;

- I do not know if it is signed;

- it is probably similar to what Intel FPGA (not GPU) drivers provide
  already inside the Linux kernel and I guess there is no pure
  open-source way to generate their bit-stream either.


Long answer:

- processors, GPU and other digital circuits are designed from a lot of
  elementary transistors, wires, capacitors, resistors... using some
  very complex (and expensive) tools from some EDA companies but at the
  end, after months of work, they come often with a "simple" public
  interface, the... instruction set! So it is rather "easy" at the end
  to generate some instructions with a compiler such as LLVM from a
  description of this ISA or some reverse engineering. Note that even if
  the ISA is public, it is very difficult to make another efficient
  processor from scratch just from this ISA, so there is often no
  concern about making this ISA public to develop the ecosystem ;

- FPGA are field-programmable gate arrays, made also from a lot of
  elementary transistors, wires, capacitors, resistors... but organized
  in billions of very low-level elementary gates, memory elements, DSP
  blocks, I/O blocks, clock generators, specific
  accelerators... directly exposed to the user and that can be
  programmed according to a configuration memory (the bitstream) that
  details how to connect each part, routing element, configuring each
  elemental piece of hardware.  So instead of just writing instructions
  like on a CPU or a GPU, you need to configure each bit of the
  architecture in such a way it does something interesting for
  you. Concretely, you write some programs in RTL languages (Verilog,
  VHDL) or higher-level (C/C++, OpenCL, SYCL...)  and you use some very
  complex (and expensive) tools from some EDA companies to generate the
  bitstream implementing an equivalent circuit with the same
  semantics. Since the architecture is so low level, there is a direct
  mapping between the configuration memory (bitstream) and the hardware
  architecture itself, so if it is public then it is easy to duplicate
  the FPGA itself and to start a new FPGA company. That is unfortunately
  something the existing FPGA companies do not want... ;-)

To summarize:

- on a CPU & GPU, the vendor used the expensive EDA tools once already
  for you and provide the simpler ISA interface;

- on an FPGA, you have access to a pile of low-level hardware and it is
  up to you to use the lengthy process of building your own computing
  architecture using the heavy expensive very subtle EDA tools that will
  run for hours or days to generate some good-enough placement for your
  pleasure.

There is some public documentation on-line:
https://www.xilinx.com/products/silicon-devices/fpga/virtex-ultrascale-plus.html#documentation

To have an idea of the elementary architecture:
https://www.xilinx.com/support/documentation/user_guides/ug574-ultrascale-clb.pdf

Re: [PATCH] drm/stm: ltdc: fix data enable polarity

[Mukesh Ojha]

On 3/29/2019 9:20 PM, Yannick Fertré wrote:

Wrong DISPLAY_FLAGS used to set the data enable polarity.

Used or checked.
Can you also explain how it is wrong to check against this FLAG in commit?


Signed-off-by: Yannick Fertré 
---
  drivers/gpu/drm/stm/ltdc.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index b1741a9..6ba326a 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++ b/drivers/gpu/drm/stm/ltdc.c
@@ -555,7 +555,7 @@ static void ltdc_crtc_mode_set_nofb(struct drm_crtc *crtc)
if (vm.flags & DISPLAY_FLAGS_VSYNC_HIGH)
val |= GCR_VSPOL;
  
-	if (vm.flags & DISPLAY_FLAGS_DE_HIGH)

+   if (vm.flags & DISPLAY_FLAGS_DE_LOW)
val |= GCR_DEPOL;
  
  	if (vm.flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE)

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

[PATCH v6 4/4] dt-bindings: display: rockchip: add document for rk3066 hdmi

[Johan Jonker]

This patch adds a binding that describes the HDMI controller for
rk3066.

Signed-off-by: Johan Jonker 
Reviewed-by: Rob Herring 
---
 .../display/rockchip/rockchip,rk3066-hdmi.txt  | 72 ++
 1 file changed, 72 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.txt

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.txt 
b/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.txt
new file mode 100644
index 0..d1ad31bca
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.txt
@@ -0,0 +1,72 @@
+Rockchip specific extensions for rk3066 HDMI
+
+
+Required properties:
+- compatible:
+   "rockchip,rk3066-hdmi";
+- reg:
+   Physical base address and length of the controller's registers.
+- clocks, clock-names:
+   Phandle to HDMI controller clock, name should be "hclk".
+- interrupts:
+   HDMI interrupt number.
+- power-domains:
+   Phandle to the RK3066_PD_VIO power domain.
+- rockchip,grf:
+   This soc uses GRF regs to switch the HDMI TX input between vop0 and 
vop1.
+- ports:
+   Contains one port node with two endpoints, numbered 0 and 1,
+   connected respectively to vop0 and vop1.
+   Contains one port node with one endpoint
+   connected to a hdmi-connector node.
+- pinctrl-0, pinctrl-name:
+   Switch the iomux for the HPD/I2C pins to HDMI function.
+
+Example:
+   hdmi: hdmi@10116000 {
+   compatible = "rockchip,rk3066-hdmi";
+   reg = <0x10116000 0x2000>;
+   interrupts = ;
+   clocks = < HCLK_HDMI>;
+   clock-names = "hclk";
+   power-domains = < RK3066_PD_VIO>;
+   rockchip,grf = <>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_xfer>, <_hpd>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   hdmi_in: port@0 {
+   reg = <0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   hdmi_in_vop0: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <_out_hdmi>;
+   };
+   hdmi_in_vop1: endpoint@1 {
+   reg = <1>;
+   remote-endpoint = <_out_hdmi>;
+   };
+   };
+   hdmi_out: port@1 {
+   reg = <1>;
+   hdmi_out_con: endpoint {
+   remote-endpoint = <_con_in>;
+   };
+   };
+   };
+   };
+
+ {
+   hdmi {
+   hdmi_hpd: hdmi-hpd {
+   rockchip,pins = <0 RK_PA0 1 _pull_default>;
+   };
+   hdmii2c_xfer: hdmii2c-xfer {
+   rockchip,pins = <0 RK_PA1 1 _pull_none>,
+   <0 RK_PA2 1 _pull_none>;
+   };
+   };
+};
-- 
2.11.0

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

[PATCH v6 2/4] ARM: dts: rockchip: add rk3066 hdmi nodes

[Johan Jonker]

From: Zheng Yang 

This patch adds the hdmi nodes to rk3066.

Signed-off-by: Zheng Yang 
Signed-off-by: Johan Jonker 
---
 arch/arm/boot/dts/rk3066a.dtsi | 52 ++
 1 file changed, 52 insertions(+)

diff --git a/arch/arm/boot/dts/rk3066a.dtsi b/arch/arm/boot/dts/rk3066a.dtsi
index 653127a37..9c43b985a 100644
--- a/arch/arm/boot/dts/rk3066a.dtsi
+++ b/arch/arm/boot/dts/rk3066a.dtsi
@@ -80,6 +80,10 @@
vop0_out: port {
#address-cells = <1>;
#size-cells = <0>;
+   vop0_out_hdmi: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <_in_vop0>;
+   };
};
};
 
@@ -101,6 +105,44 @@
vop1_out: port {
#address-cells = <1>;
#size-cells = <0>;
+   vop1_out_hdmi: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <_in_vop1>;
+   };
+   };
+   };
+
+   hdmi: hdmi@10116000 {
+   compatible = "rockchip,rk3066-hdmi";
+   reg = <0x10116000 0x2000>;
+   interrupts = ;
+   clocks = < HCLK_HDMI>;
+   clock-names = "hclk";
+   power-domains = < RK3066_PD_VIO>;
+   rockchip,grf = <>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_xfer>, <_hpd>;
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   hdmi_in: port@0 {
+   reg = <0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   hdmi_in_vop0: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <_out_hdmi>;
+   };
+   hdmi_in_vop1: endpoint@1 {
+   reg = <1>;
+   remote-endpoint = <_out_hdmi>;
+   };
+   };
+   hdmi_out: port@1 {
+   reg = <1>;
+   };
};
};
 
@@ -415,6 +457,16 @@
};
};
 
+   hdmi {
+   hdmi_hpd: hdmi-hpd {
+   rockchip,pins = <0 RK_PA0 1 _pull_default>;
+   };
+   hdmii2c_xfer: hdmii2c-xfer {
+   rockchip,pins = <0 RK_PA1 1 _pull_none>,
+   <0 RK_PA2 1 _pull_none>;
+   };
+   };
+
pwm0 {
pwm0_out: pwm0-out {
rockchip,pins = ;
-- 
2.11.0

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

[PATCH] staging: android: ion: refactory ion_alloc for kernel driver use

[Zeng Tao]

There are two reasons for this patch:
1. There are some potential requirements for ion_alloc in kernel space,
some media drivers need to allocate media buffers from ion instead of
buddy or dma framework, this is more convient and clean very for media
drivers. And In that case, ion is the only media buffer provider, it's
more easier to maintain.
2. Fd is only needed by user processes, not the kernel space, so dma_buf
should be returned instead of fd for kernel space, and dma_buf_fd should
be called only for userspace api.

Signed-off-by: Zeng Tao 
---
 drivers/staging/android/ion/ion.c | 32 +---
 1 file changed, 17 insertions(+), 15 deletions(-)

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 92c2914..e93fb49 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -387,13 +387,13 @@ static const struct dma_buf_ops dma_buf_ops = {
.unmap = ion_dma_buf_kunmap,
 };
 
-static int ion_alloc(size_t len, unsigned int heap_id_mask, unsigned int flags)
+struct dma_buf *ion_alloc(size_t len, unsigned int heap_id_mask,
+ unsigned int flags)
 {
struct ion_device *dev = internal_dev;
struct ion_buffer *buffer = NULL;
struct ion_heap *heap;
DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
-   int fd;
struct dma_buf *dmabuf;
 
pr_debug("%s: len %zu heap_id_mask %u flags %x\n", __func__,
@@ -407,7 +407,7 @@ static int ion_alloc(size_t len, unsigned int heap_id_mask, 
unsigned int flags)
len = PAGE_ALIGN(len);
 
if (!len)
-   return -EINVAL;
+   return ERR_PTR(-EINVAL);
 
down_read(>lock);
plist_for_each_entry(heap, >heaps, node) {
@@ -421,10 +421,10 @@ static int ion_alloc(size_t len, unsigned int 
heap_id_mask, unsigned int flags)
up_read(>lock);
 
if (!buffer)
-   return -ENODEV;
+   return ERR_PTR(-ENODEV);
 
if (IS_ERR(buffer))
-   return PTR_ERR(buffer);
+   return ERR_PTR(PTR_ERR(buffer));
 
exp_info.ops = _buf_ops;
exp_info.size = buffer->size;
@@ -432,17 +432,12 @@ static int ion_alloc(size_t len, unsigned int 
heap_id_mask, unsigned int flags)
exp_info.priv = buffer;
 
dmabuf = dma_buf_export(_info);
-   if (IS_ERR(dmabuf)) {
+   if (IS_ERR(dmabuf))
_ion_buffer_destroy(buffer);
-   return PTR_ERR(dmabuf);
-   }
 
-   fd = dma_buf_fd(dmabuf, O_CLOEXEC);
-   if (fd < 0)
-   dma_buf_put(dmabuf);
-
-   return fd;
+   return dmabuf;
 }
+EXPORT_SYMBOL(ion_alloc);
 
 static int ion_query_heaps(struct ion_heap_query *query)
 {
@@ -539,12 +534,19 @@ static long ion_ioctl(struct file *filp, unsigned int 
cmd, unsigned long arg)
case ION_IOC_ALLOC:
{
int fd;
+   struct dma_buf *dmabuf;
 
-   fd = ion_alloc(data.allocation.len,
+   dmabuf = ion_alloc(data.allocation.len,
   data.allocation.heap_id_mask,
   data.allocation.flags);
-   if (fd < 0)
+   if (IS_ERR(dmabuf))
+   return PTR_ERR(dmabuf);
+
+   fd = dma_buf_fd(dmabuf, O_CLOEXEC);
+   if (fd < 0) {
+   dma_buf_put(dmabuf);
return fd;
+   }
 
data.allocation.fd = fd;
 
-- 
2.7.4

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

Re: [Intel-gfx] [PATCH 00/16] drm/fb-helper: Move modesetting code to drm_client

[Noralf Trønnes]

Den 28.03.2019 10.31, skrev Daniel Vetter:
> On Tue, Mar 26, 2019 at 06:55:30PM +0100, Noralf Trønnes wrote:
>> This moves the modesetting code from drm_fb_helper to drm_client so it
>> can be shared by all internal clients.
>>
>> I have also added a client display abstraction and a bootsplash example
>> client to show where this might be heading. Hopefully Max Staudt will be
>> able to pick up his bootsplash work now.
> 
> First a fairly unrelated thing that I noticed while reading stuff:
> 
> In drm_fbdev_generic_setup() we register the drm_client to the world (with
> drm_client_add) before it's fully set up. And the checks in the setup code
> aren't safe against a concurrent hotplug call from another thread. Which
> can happen, because usually by that point, and definitely by the time the
> driver called drm_dev_register() the hotplug handler is running.
> 

Ah, this hasn't crossed my mind. I'll move drm_client_add() after setup.

> Maybe good idea to rename drm_client_add to drm_client_register (to stay
> consistent with our naming scheme of _register() = others can start
> calling us from any thread).
> 

Makes sense, I'll change the name.

> We need to do the basic setup code _before_ we call drm_client_register.
> The kerneldoc for the various fbdev setup functions have explanations for
> when exactly it's ok to handle hotplug events.
> 
> The other bit is kinda the high-level review on the drm_client modeset
> api:
> - Allowing multiple different modeset clients per drm_client feels like
>   overkill. I think we can just require a 1:1 mapping between drm_client
>   and modeset config. If a client wants to have multiple different modeset
>   configs per drm_device they can create more drm_clients.
> 

The reason I ended up doing this is that there can be more than one
display connected. So for me the natural choice was to have each display
represented individually with its own modeset(s).

I did consider having the modeset array attached to drm_client and use a
modesets mask to tell the displays apart. It would have been easier if
we didn't have those tiled monitors driven by multiple outputs, because
that would have given us one modeset per display.

drm_fb_helper uses the same framebuffer for all displays, sizing it to
match the smallest.

Ofc the easy way out is to only support one display per drm_device. I
don't see how multiple drm_clients per drm_device should work. Should
the client keep an array of drm_client for as many displays as it supports?

The bootsplash client example I made, puts a splash on all displays it
can find. But maybe it should do it on only one display? If so we need
some heuristics to determine which is the primary display.

Not sure how kmscon is supposed to work, but I believe it is meant to be
a developer console. So I guess it will also just use the primary display.

> - That also fixes your "do we need embedding" question, since drm_client
>   supports that already.
> 
> - That means we could clean up the api considerably by embedding all the
>   modeset stuff into drm_client, and e.g. allocating the modeset arrays at
>   drm_client_init() time.
> 
> - Except that wouldn't work with the current fbdev emulation code, because
>   that one isn't always using drm_client.
> 
> Hence my question/suggestion: Could we rework the fbdev emulation to
> always allocate a drm_client, but only use drm_client for buffer
> allocation for generic_setup(). That could also provide us with a smoother
> upgrade path for other drivers to generic_setup, e.g. we could ditch all
> the hotplug handling already.
> 
> I'm thinking of embedding a drm_client into drm_fb_helper, and calling
> drm_client_init() on it at the right time. But only call drm_client_add()
> for generic_setup(). At least as a first step.
> 

Yeah, this certainly makes sense if we have the modesets attached to
drm_client_dev.

> Related question: What's the plan for drivers which don't support
> generic_setup()? If we eventually have stuff like kmscon running on top of
> drm_client, we'd have to somehow port them all ...
> 

It should just work as long the driver supports ->dumb_create and
->gem_prime_vmap.

rockchip and mediatek (I think) don't provide a virtual address on its
buffers because of limited virtual address space.
We could add a ->dumb_create_internal hook so these drivers could
provide an address to internal clients. This way they could use the
generic fbdev emualtion as well. Unless Rob finds a way to vmap a dma
buffer after allocation. He has looked at converting rockchip to generic
fbdev.

> And finally the bikeshed: I thik drm_client_modeset would be a good prefix
> for all this (maybe even in a separate file):

I have used prefix drm_client_modesets_ for all functions that operates
on the modeset array.

Emmanuel Vadot alerted me to the fact that dm_fb_helper is MIT licensed.
I was now planning to change drm_client to MIT as well, so I can legally
move over code. If we add drm_client_modeset.c with a 

Re: [PATCH v2 7/7] MAINTAINERS: sm712fb: list myself as one maintainer.

[Sudip Mukherjee]

On Fri, Mar 22, 2019 at 01:17:59PM +0800, Yifeng Li wrote:
> I have working on the sm712fb driver for a while and have some familiarity
> with this hardware, I'll be helping working on and testing problems of this
> driver, so add myself to the MAINTAINERS file.

Technically I donot have any problem with this, you seem to know more
about SM712 than I know. But Teddy Wang is also an existing maintainer
and I think there should be an ack from him before this is accepted.

> 
> Signed-off-by: Yifeng Li 
> ---
>  MAINTAINERS | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index dce5c099f43c..3f6686f0f020 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -13871,6 +13871,7 @@ F:drivers/input/touchscreen/silead.c
>  F:   drivers/platform/x86/touchscreen_dmi.c
>  
>  SILICON MOTION SM712 FRAME BUFFER DRIVER
> +M:   Tom Li 

Sorry, I am confused. Is your name "Tom Li"? Then why is your
Signed-off-by: and From: name different?

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

Re: [PATCH v2 6/7] fbdev: sm712fb: Kconfig: add information about docs.

[Sudip Mukherjee]

On Fri, Mar 22, 2019 at 01:17:58PM +0800, Yifeng Li wrote:
> This commits update the Kconfig description of sm712fb,
> and inform the user about the existence of documentation.
> 
> Signed-off-by: Yifeng Li 
> ---
>  Documentation/fb/sm712fb.txt | 44 
>  drivers/video/fbdev/Kconfig  |  4 
>  2 files changed, 29 insertions(+), 19 deletions(-)
> 
> diff --git a/Documentation/fb/sm712fb.txt b/Documentation/fb/sm712fb.txt
> index 906b48aa40e4..c9a8fe059ac7 100644
> --- a/Documentation/fb/sm712fb.txt
> +++ b/Documentation/fb/sm712fb.txt
> @@ -18,9 +18,10 @@ and it was also an inexpensive platform for non-x86 
> hobbyists to explore.
>  How to use it?
>  ==
>  
> -You should not compile-in vesafb, since SM7xx can be used in a VGA
> -compatible mode, resulting conflicts with this driver. In addition,
> -the VGA compatible mode was never tested by the maintainers.
> +SM7xx can be used in a VGA compatible mode and a native framebuffer mode,
> +this driver is a native driver. By default, it has no problem taking over
> +the VGA driver automatically, but you should not attempt to use both at
> +the same time.

You added this in the documentation with just the previous patch.

>  



>  
>  2D acceleration
>  ==
> @@ -97,7 +103,7 @@ Missing Features
>  
>  The following features are not implemented in this driver,
>  
> - * 2D acceleration on SM720 and Big-Endian CPUs.
> + * 2D acceleration on Big-Endian CPUs.
>   * More VGA modes.
>   * dual-head support
>   * hardware cursor support

You might want to squash the two patches for documentation instead of
having a separate patch to fix what you added in a previous patch.

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

Re: [PATCH v2 5/7] Documentation: fb: sm712fb: add information mainly about 2D.

[Sudip Mukherjee]

On Fri, Mar 22, 2019 at 01:17:57PM +0800, Yifeng Li wrote:
> This commits add information about 32-bit color, 2D acceleration,
> as well as adding additional, general information about the hardware
> and many existing problems of the sm712fb driver.
> 
> Signed-off-by: Yifeng Li 
> ---
>  Documentation/fb/sm712fb.txt | 123 +++
>  1 file changed, 110 insertions(+), 13 deletions(-)
> 
> diff --git a/Documentation/fb/sm712fb.txt b/Documentation/fb/sm712fb.txt
> index c388442edf51..906b48aa40e4 100644
> --- a/Documentation/fb/sm712fb.txt
> +++ b/Documentation/fb/sm712fb.txt
> @@ -1,31 +1,128 @@
>  What is sm712fb?
>  =
>  
> -This is a graphics framebuffer driver for Silicon Motion SM712 based 
> processors.
> +"sm712fb" is a graphics framebuffer driver for Silicon Motion SM710 (LynxEM),
> +SM712 (LynxEM+), and SM720 (Lynx3DM, Lynx3DM+, aka. LynxEM4+) series of
> +video controllers. This series of video controller is a legacy from ~1998,
> +and was used on many classic, "prehistoric" laptops from 1998-2004, such as
> +IBM Thinkpad S30 and 240X. It was also used on some servers, industrial
> +computers, x86 and non-x86 embedded devices where only basic graphics was
> +needed.

I think this is wrong. Loongson 3A Notebook was released around 2011-2012
and had SM712.

> +
> +Notably, Lemote YeeLoong 8089, a MIPS laptop based on the Chinese Loongson



> + * More VGA modes.
>   * dual-head support
> + * hardware cursor support
> +
> +The first feature is planned to be implemented soon, but the maintainer
> +does not receive any monetary or hardware support from any company or OEMs,
> +and he has to purchase a test platform personally. The 1998's hardware
> +still costs 200 USD+, so don't expected an ETA. If you have a Big-Endian
> +platform and willing to help testing, please contact the maintainer, thanks!

I am not sure why will you want to mention about monetary or hardware
support. Maintainers are supposed to work voluntarily.

> +
> +Other VGA modes, dual-head, or hardware cursor support should be possible to
> +implement, but parts of the code must be rewritten, and there's little demand
> +for them on this legacy (retro?) platform, so there's no plan to implement 
> them.
> +If you have a genuine need for them, please contact the maintainers.

If there is any need for new features then I think the plan should be to
make a drm driver.

> +
> +Maintainers
> +
> +
> +This driver is maintained by
> +
> + * Tom Li 

??
I didn't know this. MAINTAINERS file doesnot say so.

> + * Sudip Mukherjee 
> + * Teddy Wang 
> +
> +Tom Li was the last contributor of this driver who implemented 2D 
> acceleration,
> +and is the main author of this documentation, please send any bug reports or
> +requests to Tom, but don't forget to CC other maintainers as well to make 
> everyone
> +be informed.

There is a MAINTAINERS file to list the maintainers. There is no need to
add that in documentation.

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

Re: [PATCH v2 4/7] fbdev: sm712fb: add 32-bit color modes, drops some other modes.

[Sudip Mukherjee]

On Fri, Mar 22, 2019 at 01:17:56PM +0800, Yifeng Li wrote:
> The modesetting in sm712fb is an ugly hack. First, all the registers
> are programmed by hardcoded register arrays, which makes it difficult
> to support different variations of color depths, refresh rates, CRT/LCD
> panel, etc of the same resolution. Second, it means the standard
> fb_find_mode() cannot be used and a confusing non-standard "vga="
> parameter is needed. Third, there's only minimum differences between
> some modes, yet around 70 lines of code and 100 registers are needed to
> be indepentently specified for each mode. Fourth, the register between
> some modes are inconsistent: the register configuration of different
> color depths in 640 x 480 modes are identical, but for 800 x 600 modes
> it's completely different. Also, some modes can drive the LCD panel
> properly yet some other modes will only show a white screen of death on
> the LCD panel. Fifth, some modes, such as 32-bit color modes, are
> supported but never listed, and some modes are listed, such as 1280x1024
> modes, but never supported by the register configuration arrays. And
> some modes are partially implemented but neither listed nor supported,
> i.e. the 8-bit color modes.
> 
> Fixing these problems requires a complete rewrite of modesetting code,
> which is well-beyond my motivation. This commit only perform a minimum
> cleanup:
> 
> 1. Remove the 320 x 240 register settings, since there are never listed
> and never actually being used. This resolution is not even supported by
> vesafb, so it's safe to assume that no one is using such hardware. Future
> developers who needs them can simply recover them from the git history.

Why are you removing existing functionality from the driver? These are
supported but were never listed so could not be used. I think you can
just add these to vesa_mode_table[] and they can be used. I have an old
CRT in India which supports 320x240 mode and can test there when I am
there next.

> 
> 2. Remove 1280x1024 modes and 8-bit color modes. They are listed but never
> supported by the register array. So it doesn't work in the beginning, and
> only gives a black screen.
> 
> 3. Add 32-bit color modes. They are supported but never listed, and are
> useful to some users.
> 
> Signed-off-by: Yifeng Li 
> ---
>  drivers/video/fbdev/sm712fb.c | 158 +++---
>  1 file changed, 31 insertions(+), 127 deletions(-)
> 
> diff --git a/drivers/video/fbdev/sm712fb.c b/drivers/video/fbdev/sm712fb.c
> index 75d60ea63883..5e887653ef5d 100644
> --- a/drivers/video/fbdev/sm712fb.c
> +++ b/drivers/video/fbdev/sm712fb.c
> @@ -118,25 +118,48 @@ struct vesa_mode {
>  };
>  
>  static const struct vesa_mode vesa_mode_table[] = {
> - {"0x301", 640,  480,  8},
> - {"0x303", 800,  600,  8},
> - {"0x305", 1024, 768,  8},
> - {"0x307", 1280, 1024, 8},
> -
>   {"0x311", 640,  480,  16},
>   {"0x314", 800,  600,  16},
>   {"0x317", 1024, 768,  16},
> - {"0x31A", 1280, 1024, 16},
>  
>   {"0x312", 640,  480,  24},
>   {"0x315", 800,  600,  24},
>   {"0x318", 1024, 768,  24},
> - {"0x31B", 1280, 1024, 24},
> +
> + {"0x329", 640,  480,  32},
> + {"0x32e", 800,  600,  32},
> + {"0x338", 1024, 768,  32},
>  };
>  
>  /**
>SM712 Mode table.
> - **/
> +
> + The modesetting in sm712fb is an ugly hack. First, all the registers
> + are programmed by hardcoded register arrays, which makes it difficult
> + to support different variations of color depths, refresh rates, CRT/LCD
> + panel, etc of the same resolution. Second, it means the standard
> + fb_find_mode() cannot be used and a confusing non-standard "vga="
> + parameter is needed. Third, there's only minimum differences between
> + some modes, yet around 70 lines of code and 100 registers are needed to
> + be indepentently specified for each mode. Fourth, the register between
> + some modes are inconsistent: the register configuration of different
> + color depths in 640 x 480 modes are identical, but for 800 x 600 modes
> + it's completely different. Also, some modes can drive the LCD panel
> + properly yet some other modes will only show a white screen of death on
> + the LCD panel. Fifth, there is a specific hack for Lemote Loongson 8089D
> + laptop, the 1024x768, 16-bit color mode was modified to drive its LCD panel
> + and changed to 1024x600, but the original mode was not preserved, so
> + 1024x768 16-bit color mode is completely unsupported. And previously,
> + some modes are listed, such as 1280x1024 modes, but never supported by
> + the register configuration arrays, so they are now removed. And some modes
> + are partially implemented but neither listed nor supported, i.e. the 8-bit
> + color modes, so they have been removed from vesa_mode_table, too.

I think this 

Re: [PATCH v2 3/7] fbdev: sm712fb: support 2D acceleration on SM712 w/ Little-Endian CPU.

[Sudip Mukherjee]

On Fri, Mar 22, 2019 at 01:17:55PM +0800, Yifeng Li wrote:
> Previously, in staging/sm7xxfb (now fbdev/sm712fb), 2D acceleration
> was implemented, but after its submission, a critical bug that causes
> total system hang was discovered, as a stopgap measure, 2D ops was
> completele removed in commit 3af805735a25 ("staging: sm7xx: remove the
> buggy 2D acceleration support") and never implemented again.
> 
> It created a massive usability problem - on YeeLoong 8089, a notable
> MIPS platform which uses SM712 - even scrolling a single line of text
> on the console required an unaccelerated screen redraw, running "dmesg"
> typically takes 8-11 seconds, and absurdly, printf(), became a significant
> performance bottleneck that slows down GCC and "make", make the computer
> largely unusable.
> 
> So I decided to take a look. Most of the my actual development was done
> in 2014 in a personal out-of-tree driver, I did not mainline it because
> 2D acceleration was not working properly in 24-bit color. I discovered
> the solution in early 2019 and now it's ready to be mainlined.
> 
> This commit reimplements the 2D acceleration for sm712fb. Unlike the
> original implementation, which was messy and unnecessarily complicated
> by calling a 2D acceleration wrapper file with many unneeded functions,
> this is a minimum and (relatively) clean implementation. My tests have
> shown that running "dmesg" only takes 0.9 seconds, a performance boost
> of 950%. System hangs did not occur in my tests.

I didnot notice any performace improvement in my system. Infact, I have
never seen the performance problem that you mentioned. But, it will be
good to have the 2D feature back again.

> 

> +  */
> + smtcfb_reset_accel();
> +
>   smtc_set_timing(sfb);
> +
> + /*
> +  * Currently, 2D acceleration is only supported on SM712 with
> +  * little-endian CPUs, it's disabled on Big Endian systems and SM720
> +  * chips as a safety measure. Since I don't have monetary or hardware
> +  * support from any company or OEMs, I don't have the hardware and
> +  * it's completely untested. I should be also to purchase a Big Endian
> +  * test platform and add proper support soon. I still have to spend
> +  * 200 USD+ to purchase this piece of 1998's hardware, yikes! If you
> +  * have a Big-Endian platform with SM7xx available for testing, please
> +  * send an E-mail to Tom, thanks!
> +  */

comments in the code are usually used to increase the readability, and
I dont think adding this comment adds to the readibility. I also spent
personal money to get these hardwares but that was never added to any
commit message or comment. Please remove this comment.

> +#ifdef __BIG_ENDIAN
> + sfb->accel = false;
> + if (accel)
> + dev_info(>pdev->dev,
> + "2D acceleration is unsupported on Big Endian.\n");
> +#endif
> + if (!accel) {
> + sfb->accel = false;
> + dev_info(>pdev->dev,
> + "2D acceleration is disabled by the user.\n");
> + }
> +
> + /* reset 2D engine after a modesetting is mandatory */
> + smtcfb_reset_accel();

If it is a big endian, acceleration is disabled, but you are still
calling smtcfb_reset_accel() which will "enable Zoom Video Port,
2D Drawing Engine and Video Processor". Will that not create any problem
in a big endian system?

> + smtcfb_init_accel(sfb);
>  }
>  
>  static int smtc_check_var(struct fb_var_screeninfo *var, struct fb_info 
> *info)
> @@ -1401,6 +1459,316 @@ static struct fb_ops smtcfb_ops = {
>   .fb_write = smtcfb_write,
>  };
>  
> +static int smtcfb_wait(struct smtcfb_info *fb)
> +{
> + int i;
> + u8 reg;
> +
> + smtc_dprr(DPR_DE_CTRL);
> + for (i = 0; i < 1; i++) {
> + reg = smtc_seqr(SCR_DE_STATUS);
> + if ((reg & SCR_DE_STATUS_MASK) == SCR_DE_ENGINE_IDLE)
> + return 0;
> + udelay(1);
> + }
> + dev_err(>pdev->dev, "2D engine hang detected!\n");
> + return -EBUSY;
> +}
> +
> +static void
> +smtcfb_fillrect(struct fb_info *info, const struct fb_fillrect *rect)
> +{
> + u32 width = rect->width, height = rect->height;
> + u32 dx = rect->dx, dy = rect->dy;
> + u32 color;
> +
> + struct smtcfb_info *sfb = info->par;
> +
> + if (unlikely(info->state != FBINFO_STATE_RUNNING))
> + return;

Did you measure the performance difference with and without "unlikely"?
Quoting GregKH from https://lkml.org/lkml/2018/11/7/36
"don't do stuff like this unless you can actually measure the
difference".

> +

> +  * & HIGH with 0x (all ones, and we have already set
> +  * that in smtcfb_init_accel). Since the color of this mono
> +  * pattern is controlled by DPR_FG_COLOR, BITBLTing it with
> +  * ROP_COPY is effectively a rectfill().
> +  */
> + smtc_dprw(DPR_FG_COLOR, 

Re: [PATCH v2 2/7] fbdev: sm712fb: add 2D-related I/O headers and functions.

[Sudip Mukherjee]

On Fri, Mar 22, 2019 at 01:17:54PM +0800, Yifeng Li wrote:
> This commit adds I/O macros and functions related to 2D opeartions.
> A hunk of hardware register definitions are taken verbatim from
> OpenBSD.
> 
> In addition, a utility function pad_to_dword() is added to help
> padding data for the 2D engine. It  accepts 3, 2, or 1 byte(s) of
> data, and pads it to a 32-bit word suitable for 2D Drawing Engine.
> 
> Yes, we can set info->pixmap.scan_align/buf_align = 4 and forget
> about padding, but it's incompatible with cfb_imageblit() w/
> depth == 1. In case we need to fallback (e.g. debugging), it would
> be inconvenient, so we pad it manually.
> 
> Signed-off-by: Yifeng Li 
> ---
>  drivers/video/fbdev/sm712.h | 96 +
>  1 file changed, 96 insertions(+)
> 
> diff --git a/drivers/video/fbdev/sm712.h b/drivers/video/fbdev/sm712.h
> index 89e446db2ac7..4892fd485f08 100644
> --- a/drivers/video/fbdev/sm712.h
> +++ b/drivers/video/fbdev/sm712.h
> @@ -91,6 +91,102 @@ static inline u8 smtc_seqr(u8 reg)
>   return smtc_mmiorb(0x3c5);
>  }
>  
> +/*
> + * DPR (2D drawing engine)
> + */
> +#define DPR_COORDS(x, y) (((x) << 16) | (y))
> +

> +#define DPR_SRC_WINDOW   0x3c
> +#define DPR_SRC_BASE 0x40
> +#define DPR_DST_BASE 0x44
> +
> +#define DE_CTRL_START0x8000
> +#define DE_CTRL_RTOL 0x0800
> +#define DE_CTRL_COMMAND_MASK 0x001f
> +#define DE_CTRL_COMMAND_SHIFT16
> +#define DE_CTRL_COMMAND_BITBLT   0x00
> +#define DE_CTRL_COMMAND_SOLIDFILL0x01
> +#define DE_CTRL_COMMAND_HOSTWRITE0x08
> +#define DE_CTRL_ROP2_SELECT  0x8000
> +#define DE_CTRL_ROP2_SRC_IS_PATTERN  0x4000
> +#define DE_CTRL_ROP2_SHIFT   0
> +#define DE_CTRL_ROP2_COPY0x0c
> +#define DE_CTRL_HOST_SHIFT   22
> +#define DE_CTRL_HOST_SRC_IS_MONO 0x01
> +#define DE_CTRL_FORMAT_XY0x00
> +#define DE_CTRL_FORMAT_24BIT 0x30

Please fix the alignment. Some of them are right aligned and some are left.

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

Re: [PATCH v2 1/7] fbdev: sm712fb: use type "u8" for 8-bit I/O.

[Sudip Mukherjee]

On Fri, Mar 22, 2019 at 01:17:53PM +0800, Yifeng Li wrote:
> This commit converts "unsigned int" and "int" in I/O wrappers
> to "u8". It improves readability since it's consistent with
> the prototypes of readb() and writeb(). More importantly, it
> reduces readers' confusion, since the upcoming 2D acceleration
> code will use a different wordsize.
> 
> Signed-off-by: Yifeng Li 

Tested-by: Sudip Mukherjee 

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

[Bug 110290] install of amdgpu failed

[bugzilla-daemon]

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

--- Comment #6 from Andre Klapper  ---
Which steps in the links that I provided did you follow, and what was the exact
result?

-- 
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 110290] install of amdgpu failed

[bugzilla-daemon]

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

--- Comment #7 from Andre Klapper  ---
(Also, please avoid unneeded full quotes of previous messages to keep things
readable. Thanks!)

-- 
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 5/5] drm: rockchip: add fixed screen size DVI-D support for rk3066 hdmi

[Heiko Stuebner]

Hi Johan,

Am Donnerstag, 21. März 2019, 01:14:40 CEST schrieb Johan Jonker:
> Add fixed screen size DVI-D support
> for rk3066 hdmi with an extra patch.
> 
> Signed-off-by: Johan Jonker 

> +static const struct drm_display_mode edid_cea_modes[] = {
> + /* 4 - 1280x720@60Hz 16:9 */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1390,
> +1430, 1650, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
> +};

you already dropped this patch from v6, but just for completeness sake,
I don't think there should be a static mode for dvi displays.

Similar to hdmi, dvi also can use ddc to read the monitor edid and some
sort of static mode might behave badly if for example a display with less
than this 720p is connected.

I think I remember reading in the Rockchip tree that they added that for
the case reading the edid fails, but if that happens the reading should
be fixed and not worked around a failure :-)


Heiko


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

[Bug 110290] install of amdgpu failed

[bugzilla-daemon]

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

--- Comment #5 from Godfrey Lee  ---
I should mention it was a fresh install of ubuntu.

On Sun, Mar 31, 2019, 12:01 PM Godfrey Lee  wrote:

> I am not familiar with the stack.  What do you mean upstream?  It is
> installation problem that during installation it corrupted the whole Ubuntu
> os to the point that I can no longer install any other software, and found
> no way to reverse the damage.  Seems to me to be a two party problem.
> Amdgpu on Ubuntu!
>
> On Sun, Mar 31, 2019, 8:52 AM  wrote:
>
>> *Comment # 3  on
>> bug 110290  from Andre
>> Klapper  *
>>
>> Again, why is this an upstream problem and not an Ubuntu problem?
>> https://askubuntu.com/questions/979950/amdgpu-pro-drivers-fail-to-install-on-ubuntu-16-04-how-to-fix-ithttps://askubuntu.com/questions/987778/how-to-fix-broken-packages-after-amdgpu-pro-install-failhttps://askubuntu.com/questions/1107272/installing-amdgpu-18-50-for-ubuntu-18-04-resulting-in-dependency-issueshttps://ubuntuforums.org/showthread.php?t=2404946
>>
>> --
>> You are receiving this mail because:
>>
>>- You reported the bug.
>>
>>

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

[Bug 110290] install of amdgpu failed

[bugzilla-daemon]

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

--- Comment #4 from Godfrey Lee  ---
I am not familiar with the stack.  What do you mean upstream?  It is
installation problem that during installation it corrupted the whole Ubuntu
os to the point that I can no longer install any other software, and found
no way to reverse the damage.  Seems to me to be a two party problem.
Amdgpu on Ubuntu!

On Sun, Mar 31, 2019, 8:52 AM  wrote:

> *Comment # 3  on
> bug 110290  from Andre
> Klapper  *
>
> Again, why is this an upstream problem and not an Ubuntu problem?
> https://askubuntu.com/questions/979950/amdgpu-pro-drivers-fail-to-install-on-ubuntu-16-04-how-to-fix-ithttps://askubuntu.com/questions/987778/how-to-fix-broken-packages-after-amdgpu-pro-install-failhttps://askubuntu.com/questions/1107272/installing-amdgpu-18-50-for-ubuntu-18-04-resulting-in-dependency-issueshttps://ubuntuforums.org/showthread.php?t=2404946
>
> --
> You are receiving this mail because:
>
>- You reported the bug.
>
>

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

Re: [PATCH v6 3/4] ARM: dts: rockchip: rk3066a-mk808: enable vop0 and hdmi nodes

[Heiko Stuebner]

Am Samstag, 30. März 2019, 10:56:38 CEST schrieb Johan Jonker:
> This patch enables the vop0 and hdmi nodes
> for a MK808 with rk3066 processor.
> 
> Signed-off-by: Johan Jonker 

applied for 5.2

Thanks
Heiko


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

Re: [PATCH v6 2/4] ARM: dts: rockchip: add rk3066 hdmi nodes

[Heiko Stuebner]

Am Samstag, 30. März 2019, 10:56:37 CEST schrieb Johan Jonker:
> From: Zheng Yang 
> 
> This patch adds the hdmi nodes to rk3066.
> 
> Signed-off-by: Zheng Yang 
> Signed-off-by: Johan Jonker 

applied for 5.2 after correcting the alphabetical sorting of some
properties.

Thanks
Heiko


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

Re: [PATCH v6 1/4] drm: rockchip: introduce rk3066 hdmi

[Heiko Stuebner]

Hi Johan,

Am Samstag, 30. März 2019, 10:56:36 CEST schrieb Johan Jonker:
> From: Zheng Yang 
> 
> The RK3066 HDMI TX serves as interface between a LCD Controller and
> a HDMI bus. A HDMI TX consists of one HDMI transmitter controller and
> one HDMI transmitter PHY. The interface has three (3) 8-bit data channels
> which can be configured for a number of bus widths (8/10/12/16/20/24-bit)
> and different video formats (RGB, YCbCr).
> 
> Features:
> HDMI version 1.4a, HDCP revision 1.4 and
> DVI version 1.0 compliant transmitter.
> Supports DTV resolutions from 480i to 1080i/p HD.
> Master I2C interface for a DDC connection.
> HDMI TX supports multiple power save modes.
> The HDMI TX input can switch between LCDC0 and LCDC1.
> (Sound support is not included in this patch)
> 
> Signed-off-by: Zheng Yang 
> Signed-off-by: Johan Jonker 

applied to drm-misc-next with a smallish change as described below,
please double check. [0]

> +static int
> +rk3066_hdmi_probe_single_connector_modes(struct drm_connector *connector,
> +  uint32_t maxX, uint32_t maxY)
> +{

instead of

> + return drm_helper_probe_single_connector_modes(connector, 1920, 1080);

it is now doing

+   if (maxX > 1920)
+   maxX = 1920;
+   if (maxY > 1080)
+   maxY = 1080;
+
+   return drm_helper_probe_single_connector_modes(connector, maxX, maxY);

to take into account maxX / maxY being already below 1920x1080

> +}


Heiko

[0] 
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=f84d3d37b7fbb022e33b79d54374466f6fbc7186


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

Re: [PATCH v6 4/4] dt-bindings: display: rockchip: add document for rk3066 hdmi

[Heiko Stuebner]

Am Samstag, 30. März 2019, 10:56:39 CEST schrieb Johan Jonker:
> This patch adds a binding that describes the HDMI controller for
> rk3066.
> 
> Signed-off-by: Johan Jonker 
> Reviewed-by: Rob Herring 

applied to drm-misc-next, so should land in 5.2

Thanks
Heiko


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

[Bug 110290] install of amdgpu failed

[bugzilla-daemon]

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

--- Comment #3 from Andre Klapper  ---
Again, why is this an upstream problem and not an Ubuntu problem?

https://askubuntu.com/questions/979950/amdgpu-pro-drivers-fail-to-install-on-ubuntu-16-04-how-to-fix-it
https://askubuntu.com/questions/987778/how-to-fix-broken-packages-after-amdgpu-pro-install-fail
https://askubuntu.com/questions/1107272/installing-amdgpu-18-50-for-ubuntu-18-04-resulting-in-dependency-issues
https://ubuntuforums.org/showthread.php?t=2404946

-- 
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 110293] add support for AMD Ryzen 5 3550H

[bugzilla-daemon]

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

--- Comment #1 from djip.per...@free.fr ---

on my laptop "ASUS TUF505DY" the RAVEN APU have device 1002:15d8 that is
missing in "drivers/gpu/drm/amd/amdkfd/kfd_device.c" on kernel 5.0.5 (and any
kernel before it I think.

[2.478498] kfd kfd: DID 15d8 is missing in supported_devices

Add patch I made and test again the main kernel v5.0.5.

cool be nice to be added in future kernel release

thanks

-- 
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 110293] add support for AMD Ryzen 5 3550H

[bugzilla-daemon]

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

Bug ID: 110293
   Summary: add support for AMD Ryzen 5 3550H
   Product: DRI
   Version: DRI git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/amdkfd
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: djip.per...@free.fr

Created attachment 143823
  --> https://bugs.freedesktop.org/attachment.cgi?id=143823=edit
patch_V0

on my laptop "ASUS TUF505DY" the RAVEN APU have device 1002:15d8 that is
missing in "drivers/gpu/drm/amd/amdkfd/kfd_device.c" on kernel 5.0.5 (and any
kernel before it I think.

[2.478498] kfd kfd: DID 15d8 is missing in supported_devices

Add patch I made and test again the main kernel v5.0.5.

cool be nice to be added in future kernel release

thanks

-- 
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 7/8] fbdev: sm712fb: fix support for 1024x768-16 mode.

[Sudip Mukherjee]

On Sun, Mar 17, 2019 at 06:25:03AM +0800, Yifeng Li wrote:
> In order to support the 1024x600 panel on Yeeloong Loongson MIPS
> laptop, the original 1024x768-16 table was modified to 1024x600-16,
> without leaving the original. It causes problem on x86 laptop as
> the 1024x768-16 support was still claimed but not working.
> 
> Fix it by introducing the 1024x768-16 mode.
> 
> Signed-off-by: Yifeng Li 
> Cc: sta...@vger.kernel.org  # v4.4+

Tested-by: Sudip Mukherjee 

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

Re: [PATCH 8/8] fbdev: sm712fb: use 1024x768 by default on non-MIPS, fix garbled display.

[Sudip Mukherjee]

On Sun, Mar 17, 2019 at 06:25:04AM +0800, Yifeng Li wrote:
> Loongson MIPS netbooks use 1024x600 LCD panels, which is the original
> target platform of this driver, but nearly all old x86 laptops have
> 1024x768. Lighting 768 panels using 600's timings would partially
> garble the display. Since it's not possible to distinguish them reliably,
> we change the default to 768, but keep 600 as-is on MIPS.
> 
> Further, earlier laptops, such as IBM Thinkpad 240X, has a 800x600 LCD
> panel, this driver would probably garbled those display. As we don't
> have one for testing, the original behavior of the driver is kept as-is,
> but the problem has been documented is the comments.
> 
> Signed-off-by: Yifeng Li 
> Cc: sta...@vger.kernel.org  # v4.4+

Tested-by: Sudip Mukherjee 

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

Re: [PATCH 6/8] fbdev: sm712fb: fix crashes and garbled display during DPMS modesetting.

[Sudip Mukherjee]

On Sun, Mar 17, 2019 at 06:25:02AM +0800, Yifeng Li wrote:
> On a Thinkpad s30 (Pentium III / i440MX, Lynx3DM), blanking the display
> or starting the X server will crash and freeze the system, or garble the
> display.
> 
> Experiments showed this problem can mostly be solved by adjusting the
> order of register writes. Also, sm712fb failed to consider the difference
> of clock frequency when unblanking the display, and programs the clock for
> SM712 to SM720.
> 
> Fix them by adjusting the order of register writes, and adding an
> additional check for SM720 for programming the clock frequency.
> 
> Signed-off-by: Yifeng Li 
> Cc: sta...@vger.kernel.org  # v4.4+

Tested-by: Sudip Mukherjee 

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

Re: [PATCH 4/8] fbdev: sm712fb: fix boot screen glitch when sm712fb replaces VGA.

[Sudip Mukherjee]

On Sun, Mar 17, 2019 at 06:25:00AM +0800, Yifeng Li wrote:
> When the machine is booted in VGA mode, loading sm712fb would cause
> a glitch of random pixels shown on the screen. To prevent it from
> happening, we first clear the entire framebuffer, and we also need
> to stop calling smtcfb_setmode() during initialization, the fbdev
> layer will call it for us later when it's ready.
> 
> Signed-off-by: Yifeng Li 
> Cc: sta...@vger.kernel.org  # v4.4+

Tested-by: Sudip Mukherjee 

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

Re: [PATCH 5/8] fbdev: sm712fb: fix crashes during framebuffer writes by correctly mapping VRAM.

[Sudip Mukherjee]

On Sun, Mar 17, 2019 at 06:25:01AM +0800, Yifeng Li wrote:
> On a Thinkpad s30 (Pentium III / i440MX, Lynx3DM), running fbtest or X
> will crash the machine instantly, because the VRAM/framebuffer is not
> mapped correctly.
> 
> On SM712, the framebuffer starts at the beginning of address space, but
> SM720's framebuffer starts at the 1 MiB offset from the beginning. However,
> sm712fb fails to take this into account, as a result, writing to the
> framebuffer will destroy all the registers and kill the system immediately.
> Another problem is the driver assumes 8 MiB of VRAM for SM720, but some
> SM720 system, such as this IBM Thinkpad, only has 4 MiB of VRAM.
> 
> Fix this problem by removing the hardcoded VRAM size, adding a function to
> query the amount of VRAM from register MCR76 on SM720, and adding proper
> framebuffer offset.
> 
> Please note that the memory map may have additional problems on Big-Endian
> system, which is not available for testing by myself. But I highly suspect
> that the original code is also broken on Big-Endian machines for SM720, so
> at least we are not making the problem worse. More, the driver also assumed
> SM710/SM712 has 4 MiB of VRAM, but it has a 2 MiB version as well, and used
> in earlier laptops, such as IBM Thinkpad 240X, the driver would probably
> crash on them. I've never seen one of those machines and cannot fix it, but
> I have documented these problems in the comments.
> 
> Signed-off-by: Yifeng Li 
> Cc: sta...@vger.kernel.org  # v4.4+

Tested-by: Sudip Mukherjee 

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

Re: [PATCH 3/8] fbdev: sm712fb: fix VRAM detection, don't set SR70/71/74/75.

[Sudip Mukherjee]

On Sun, Mar 17, 2019 at 06:24:59AM +0800, Yifeng Li wrote:
> On a Thinkpad s30 (Pentium III / i440MX, Lynx3DM), the amount of Video
> RAM is not detected correctly by the xf86-video-siliconmotion driver.
> This is because sm712fb overwrites the GPR71 Scratch Pad Register, which
> is set by BIOS on x86 and used to indicate amount of VRAM.
> 
> Other Scratch Pad Registers, including GPR70/74/75, don't have the same
> side-effect, but overwriting to them is still questionable, as they are
> not related to modesetting.
> 
> Stop writing to SR70/71/74/75 (a.k.a GPR70/71/74/75).
> 
> Signed-off-by: Yifeng Li 
> Cc: sta...@vger.kernel.org  # v4.4+

Tested-by: Sudip Mukherjee 

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

Re: [PATCH 2/8] fbdev: sm712fb: fix brightness control on reboot, don't set SR30.

[Sudip Mukherjee]

On Sun, Mar 17, 2019 at 06:24:58AM +0800, Yifeng Li wrote:
> On a Thinkpad s30 (Pentium III / i440MX, Lynx3DM), rebooting with
> sm712fb framebuffer driver would cause the role of brightness up/down
> button to swap.
> 
> Experiments showed the FPR30 register caused this behavior. Moreover,
> even if this register don't have side-effect on other systems, over-
> writing it is also highly questionable, since it was originally
> configurated by the motherboard manufacturer by hardwiring pull-down
> resistors to indicate the type of LCD panel. We should not mess with
> it.
> 
> Stop writing to the SR30 (a.k.a FPR30) register.
> 
> Signed-off-by: Yifeng Li 
> Cc: sta...@vger.kernel.org  # v4.4+

Tested-by: Sudip Mukherjee 

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

Re: [PATCH 1/8] fbdev: sm712fb: fix white screen of death on reboot, don't set CR3B-CR3F.

[Sudip Mukherjee]

On Sun, Mar 17, 2019 at 06:24:57AM +0800, Yifeng Li wrote:
> On a Thinkpad s30 (Pentium III / i440MX, Lynx3DM), rebooting with
> sm712fb framebuffer driver would cause a white screen of death on
> the next POST, presumably the proper timings for the LCD panel was
> not reprogrammed properly by the BIOS.
> 
> Experiments showed a few CRTC Scratch Registers, including CRT3D,
> CRT3E and CRT3F may be used internally by BIOS as some flags. CRT3B is
> a hardware testing register, we shouldn't mess with it. CRT3C has
> blanking signal and line compare control, which is not needed for this
> driver.
> 
> Stop writing to CR3B-CR3F (a.k.a CRT3B-CRT3F) registers. Even if these
> registers don't have side-effect on other systems, writing to them is
> also highly questionable.
> 
> Signed-off-by: Yifeng Li 
> Cc: sta...@vger.kernel.org  # v4.4+

Tested-by: Sudip Mukherjee 

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

Re: [PATCH 0/8] fbdev: sm712fb: fix a series of lockups, crashes and gliches.

[Sudip Mukherjee]

On Sun, Mar 17, 2019 at 06:24:56AM +0800, Yifeng Li wrote:
> Hi all,
> 
> This patchset contains a series of important fixes to various problems,
> including lockups, crashes, screen gliches, and missing video modes.
> These patches are crucial to the correct operation to the hardware,
> especially Lynx3DM+ (SM720). I have tested and verified them on x86.
> 
> Please review and queue them for linux-stable.

Thanks for the changes.
Verified the register changes from the datasheet and also tested the full
series (separate test for individual patches) with SM712 on little endian
for any regression.

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

[gabbayo:habanalabs-next 5/21] drivers/misc/habanalabs/firmware_if.c:58:3: error: implicit declaration of function 'writeq'

[kbuild test robot]

tree:   git://people.freedesktop.org/~gabbayo/linux habanalabs-next
head:   fd467452d554d95e0294e6e34781028f6d3f69f5
commit: 6c57cab11132dcddb91af2ff98bcb8c5f3d2da89 [5/21] habanalabs: Move device 
CPU code into common file
config: i386-randconfig-a0-201913 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
git checkout 6c57cab11132dcddb91af2ff98bcb8c5f3d2da89
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/misc/habanalabs/firmware_if.c: In function 'hl_fw_push_fw_to_device':
>> drivers/misc/habanalabs/firmware_if.c:58:3: error: implicit declaration of 
>> function 'writeq' [-Werror=implicit-function-declaration]
  writeq(*fw_data, dst);
  ^
   cc1: some warnings being treated as errors

vim +/writeq +58 drivers/misc/habanalabs/firmware_if.c

12  
13  /**
14   * hl_fw_push_fw_to_device() - Push FW code to device.
15   * @hdev: pointer to hl_device structure.
16   *
17   * Copy fw code from firmware file to device memory.
18   *
19   * Return: 0 on success, non-zero for failure.
20   */
21  int hl_fw_push_fw_to_device(struct hl_device *hdev, const char *fw_name,
22  void __iomem *dst)
23  {
24  const struct firmware *fw;
25  const u64 *fw_data;
26  size_t fw_size, i;
27  int rc;
28  
29  rc = request_firmware(, fw_name, hdev->dev);
30  if (rc) {
31  dev_err(hdev->dev, "Failed to request %s\n", fw_name);
32  goto out;
33  }
34  
35  fw_size = fw->size;
36  if ((fw_size % 4) != 0) {
37  dev_err(hdev->dev, "illegal %s firmware size %zu\n",
38  fw_name, fw_size);
39  rc = -EINVAL;
40  goto out;
41  }
42  
43  dev_dbg(hdev->dev, "%s firmware size == %zu\n", fw_name, 
fw_size);
44  
45  fw_data = (const u64 *) fw->data;
46  
47  if ((fw->size % 8) != 0)
48  fw_size -= 8;
49  
50  for (i = 0 ; i < fw_size ; i += 8, fw_data++, dst += 8) {
51  if (!(i & (0x8 - 1))) {
52  dev_dbg(hdev->dev,
53  "copied so far %zu out of %zu for %s 
firmware",
54  i, fw_size, fw_name);
55  usleep_range(20, 100);
56  }
57  
  > 58  writeq(*fw_data, dst);
59  }
60  
61  if ((fw->size % 8) != 0)
62  writel(*(const u32 *) fw_data, dst);
63  
64  out:
65  release_firmware(fw);
66  return rc;
67  }
68  

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

[gabbayo:habanalabs-next 5/21] drivers/misc//habanalabs/firmware_if.c:58:3: error: implicit declaration of function 'writeq'; did you mean 'writel'?

[kbuild test robot]

tree:   git://people.freedesktop.org/~gabbayo/linux habanalabs-next
head:   fd467452d554d95e0294e6e34781028f6d3f69f5
commit: 6c57cab11132dcddb91af2ff98bcb8c5f3d2da89 [5/21] habanalabs: Move device 
CPU code into common file
config: i386-randconfig-x018-201913 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
git checkout 6c57cab11132dcddb91af2ff98bcb8c5f3d2da89
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/misc//habanalabs/firmware_if.c: In function 
'hl_fw_push_fw_to_device':
>> drivers/misc//habanalabs/firmware_if.c:58:3: error: implicit declaration of 
>> function 'writeq'; did you mean 'writel'? 
>> [-Werror=implicit-function-declaration]
  writeq(*fw_data, dst);
  ^~
  writel
   cc1: some warnings being treated as errors

vim +58 drivers/misc//habanalabs/firmware_if.c

12  
13  /**
14   * hl_fw_push_fw_to_device() - Push FW code to device.
15   * @hdev: pointer to hl_device structure.
16   *
17   * Copy fw code from firmware file to device memory.
18   *
19   * Return: 0 on success, non-zero for failure.
20   */
21  int hl_fw_push_fw_to_device(struct hl_device *hdev, const char *fw_name,
22  void __iomem *dst)
23  {
24  const struct firmware *fw;
25  const u64 *fw_data;
26  size_t fw_size, i;
27  int rc;
28  
29  rc = request_firmware(, fw_name, hdev->dev);
30  if (rc) {
31  dev_err(hdev->dev, "Failed to request %s\n", fw_name);
32  goto out;
33  }
34  
35  fw_size = fw->size;
36  if ((fw_size % 4) != 0) {
37  dev_err(hdev->dev, "illegal %s firmware size %zu\n",
38  fw_name, fw_size);
39  rc = -EINVAL;
40  goto out;
41  }
42  
43  dev_dbg(hdev->dev, "%s firmware size == %zu\n", fw_name, 
fw_size);
44  
45  fw_data = (const u64 *) fw->data;
46  
47  if ((fw->size % 8) != 0)
48  fw_size -= 8;
49  
50  for (i = 0 ; i < fw_size ; i += 8, fw_data++, dst += 8) {
51  if (!(i & (0x8 - 1))) {
52  dev_dbg(hdev->dev,
53  "copied so far %zu out of %zu for %s 
firmware",
54  i, fw_size, fw_name);
55  usleep_range(20, 100);
56  }
57  
  > 58  writeq(*fw_data, dst);
59  }
60  
61  if ((fw->size % 8) != 0)
62  writel(*(const u32 *) fw_data, dst);
63  
64  out:
65  release_firmware(fw);
66  return rc;
67  }
68  

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

[gabbayo:habanalabs-next 14/21] drivers/misc/habanalabs/mmu.c:36:8: warning: cast to pointer from integer of different size

[kbuild test robot]

tree:   git://people.freedesktop.org/~gabbayo/linux habanalabs-next
head:   fd467452d554d95e0294e6e34781028f6d3f69f5
commit: 9b588e636ae2944f65223e2bb0df67772f97a178 [14/21] habanalabs: add MMU 
shadow mapping
config: mips-allyesconfig (attached as .config)
compiler: mips-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 9b588e636ae2944f65223e2bb0df67772f97a178
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=mips 

All warnings (new ones prefixed by >>):

   drivers/misc/habanalabs/mmu.c: In function 'free_hop':
>> drivers/misc/habanalabs/mmu.c:36:8: warning: cast to pointer from integer of 
>> different size [-Wint-to-pointer-cast]
 kfree((u64 *) pgt_info->shadow_addr);
   ^
   drivers/misc/habanalabs/mmu.c: In function 'alloc_hop':
>> drivers/misc/habanalabs/mmu.c:58:16: warning: cast from pointer to integer 
>> of different size [-Wpointer-to-int-cast]
 shadow_addr = (u64) kzalloc(prop->mmu_hop_table_size, GFP_KERNEL);
   ^
   drivers/misc/habanalabs/mmu.c: In function 'write_pte':
   drivers/misc/habanalabs/mmu.c:114:3: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
 *(u64 *) shadow_pte_addr = val;
  ^
   drivers/misc/habanalabs/mmu.c: In function 'write_final_pte':
   drivers/misc/habanalabs/mmu.c:124:3: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
 *(u64 *) shadow_pte_addr = val;
  ^
   drivers/misc/habanalabs/mmu.c: In function '_hl_mmu_unmap':
   drivers/misc/habanalabs/mmu.c:541:14: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
 curr_pte = *(u64 *) hop0_pte_addr;
 ^
   drivers/misc/habanalabs/mmu.c:550:14: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
 curr_pte = *(u64 *) hop1_pte_addr;
 ^
   drivers/misc/habanalabs/mmu.c:559:14: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
 curr_pte = *(u64 *) hop2_pte_addr;
 ^
   drivers/misc/habanalabs/mmu.c:568:14: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
 curr_pte = *(u64 *) hop3_pte_addr;
 ^
   drivers/misc/habanalabs/mmu.c:586:15: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
  curr_pte = *(u64 *) hop4_pte_addr;
  ^
   drivers/misc/habanalabs/mmu.c: In function '_hl_mmu_map':
   drivers/misc/habanalabs/mmu.c:748:14: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
 curr_pte = *(u64 *) hop0_pte_addr;
 ^
   drivers/misc/habanalabs/mmu.c:755:14: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
 curr_pte = *(u64 *) hop1_pte_addr;
 ^
   drivers/misc/habanalabs/mmu.c:762:14: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
 curr_pte = *(u64 *) hop2_pte_addr;
 ^
   drivers/misc/habanalabs/mmu.c:769:14: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
 curr_pte = *(u64 *) hop3_pte_addr;
 ^
   drivers/misc/habanalabs/mmu.c:777:15: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
  curr_pte = *(u64 *) hop4_pte_addr;
  ^
   In file included from include/linux/printk.h:330:0,
from include/linux/kernel.h:15,
from include/linux/list.h:9,
from include/linux/kobject.h:19,
from include/linux/cdev.h:5,
from drivers/misc/habanalabs/habanalabs.h:16,
from drivers/misc/habanalabs/mmu.c:8:
   drivers/misc/habanalabs/mmu.c:805:5: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
   *(u64 *) hop0_pte_addr, hop0_pte_addr);
^
   include/linux/dynamic_debug.h:118:15: note: in definition of macro 
'__dynamic_func_call'
  func(, ##__VA_ARGS__);  \
  ^~~
   include/linux/dynamic_debug.h:150:2: note: in expansion of macro 
'_dynamic_func_call'
 _dynamic_func_call(fmt,__dynamic_dev_dbg,   \
 ^~
   include/linux/device.h:1495:2: note: in expansion of macro 'dynamic_dev_dbg'
 dynamic_dev_dbg(dev, dev_fmt(fmt), ##__VA_ARGS__)
 ^~~
>> drivers/misc/habanalabs/mmu.c:804:3: note: in expansion of macro 'dev_dbg'
  dev_dbg(hdev->dev, "hop0 pte: 0x%llx (0x%llx)\n",
  ^~~
   drivers/misc/habanalabs/mmu.c:807:5: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
   *(u64 *) hop1_pte_addr, hop1_pte_addr);
^
   include/linux/dynamic_debug.h:118:15: note: in 

Re: [PATCH v2 4/4] drm/panel: Add Novatek NT35596 panel driver

[Sam Ravnborg]

Hi Jagan.

Thanks for this new panel driver.

A few notes, please see inline comments below.

On Thu, Mar 21, 2019 at 07:29:55PM +0530, Jagan Teki wrote:
> Novatek NT35596 is a single-chip IC solution for small or medium-sized
> LTPS TFT LCD panels. NT35596 provides  several system interfaces like
> MIPI/SPI/I2C.
> 
> Currently added support for Microtech MTF050FHDI-03 is 1080x1920,
> 4-lane MIPI DSI LCD panel which has inbuilt NT35596 IC chip.
> 
> NT35596 support several regulators on the chip, among those only 4
> regulators like VCI, VDDI/DVDD, AVDD, AVEE are used for power-on
> sequence.
> 
> This driver added code for 3-regulator based power-on sequence as
> of now since MTF050FHDI-03 panel support it. This power-on sequence
> may be moved to panel_desc in future, if any new panel would come
> up with other type of sequence.
> 
> Signed-off-by: Jagan Teki 
> ---
> diff --git a/MAINTAINERS b/MAINTAINERS
> index a6d18acda78a..4de80222cffb 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4922,6 +4922,12 @@ S: Maintained
>  F:   drivers/gpu/drm/tinydrm/hx8357d.c
>  F:   Documentation/devicetree/bindings/display/himax,hx8357d.txt
>  
> +DRM DRIVER FOR NOVATEK NT35596 MIPI-DSI LCD PANELS
> +M:   Jagan Teki 
> +S:   Maintained
> +F:   drivers/gpu/drm/panel/panel-novatek-nt35596.c
> +F:   Documentation/devicetree/bindings/display/panel/novatek,nt35596.txt
> +

I recall the entries in MAINTAINERS come in alphabetic order
based on their headline.
So this is the wrong order as "I" comes before "N":
DRM DRIVER FOR NOVATEK NT35596 MIPI-DSI LCD PANELS
DRM DRIVER FOR INTEL I810 VIDEO CARDS

Please move

> +#define NT35596_CMD_LEN  2
> +
> +struct nt35596_panel_desc {
> + const struct drm_display_mode   *mode;
> + unsigned intlanes;
> + unsigned long   flags;
> + enum mipi_dsi_pixel_format  format;
> + const struct nt35596_init_cmd   *panel_cmds;
> + unsigned intnum_panel_cmds;
> +};
> +
> +struct nt35596 {
> + struct drm_panelpanel;
> + struct mipi_dsi_device  *dsi;
> + const struct nt35596_panel_desc *desc;
> +
> + struct backlight_device *backlight;
> + struct regulator*dvdd;
> + struct regulator*avdd;
> + struct regulator*avee;
> + struct gpio_desc*reset;
> +

> + boolprepared;
> + boolenabled;
We should move these flags to the core as more and more
drivers seems to neeed them.
Something you could take a shot at?

> +};
> +
> +static inline struct nt35596 *panel_to_nt35596(struct drm_panel *panel)
> +{
> + return container_of(panel, struct nt35596, panel);
> +}
> +
> +struct nt35596_init_cmd {
> + u8 data[NT35596_CMD_LEN];
> +};
> +
> +static const struct nt35596_init_cmd microtech_mtf050fhdi_cmds[] = {
> + { .data = { 0xFF, 0xEE } },
...
> + /* Exit CMD1, Turn-off Tear ON */
> + { .data = { 0xFF, 0x00 } },
> + { .data = { 0x35, 0x00 } },
> +};
> +
> +static int nt35596_power_on(struct nt35596 *nt35596)
> +{
> + int ret;
> +
> + ret = regulator_enable(nt35596->dvdd);
> + if (ret)
> + return ret;
> +
> + /* T_power_ramp_up for VDDI */
> + msleep(2);
> +
> + ret = regulator_enable(nt35596->avdd);
> + if (ret)
> + return ret;
> +
> + /* T_power_ramp_up for AVDD/AVEE */
> + msleep(5);
> +
> + ret = regulator_enable(nt35596->avee);
> + if (ret)
> + return ret;
> +
> + msleep(10);
> +
> + gpiod_set_value(nt35596->reset, 0);
> +
> + msleep(120);
> +
> + gpiod_set_value(nt35596->reset, 1);
> +
> + /* wait for 120ms after reset deassert */
> + msleep(120);
> +
> + return 0;
> +}
> +
> +static int nt35596_power_off(struct nt35596 *nt35596)

This function never fails. Should you check regulator_disable()?
(Mst drivers skips check of regulator_disable() and it seems safe
to skip it here too.

Make it a void function if it cannot error out.

> +{
> + gpiod_set_value(nt35596->reset, 0);
> +
> + msleep(10);
> +
> + regulator_disable(nt35596->avee);
> +
> + /* T_power_ramp_down for AVEE/AVDD */
> + msleep(5);
> +
> + regulator_disable(nt35596->avdd);
> +
> + /* T_power_ramp_down for VDDI */
> + msleep(2);
> +
> + regulator_disable(nt35596->dvdd);
> +
> + return 0;
> +}
> +
> +static int nt35596_prepare(struct drm_panel *panel)
> +{
> + struct nt35596 *nt35596 = panel_to_nt35596(panel);
> + struct mipi_dsi_device *dsi = nt35596->dsi;
> + const struct nt35596_panel_desc *desc = nt35596->desc;
> + int ret, i;
> +
> + if (nt35596->prepared)
> + return 0;
> +
> + ret = nt35596_power_on(nt35596);
> + if (ret)
> + return ret;
> +
> + for (i = 0; i < desc->num_panel_cmds; i++) {
> + const struct 

Re: [PATCH v2 02/25] dt-bindings: mediatek: add binding for mt8183 display

[Rob Herring]

On Wed, Mar 27, 2019 at 02:18:58PM +0800, yongqiang@mediatek.com wrote:
> From: Yongqiang Niu 
> 
> Update device tree binding documention for the display subsystem for
> Mediatek MT8183 SOCs
> 
> Signed-off-by: Yongqiang Niu 
> ---
>  .../bindings/display/mediatek/mediatek,disp.txt| 37 
> ++
>  1 file changed, 23 insertions(+), 14 deletions(-)
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt 
> b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> index 8469de5..5467470c 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> @@ -27,20 +27,23 @@ 
> Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt.
>  
>  Required properties (all function blocks):
>  - compatible: "mediatek,-disp-", one of
> - "mediatek,-disp-ovl"   - overlay (4 layers, blending, csc)
> - "mediatek,-disp-rdma"  - read DMA / line buffer
> - "mediatek,-disp-wdma"  - write DMA
> - "mediatek,-disp-color" - color processor
> - "mediatek,-disp-aal"   - adaptive ambient light controller
> - "mediatek,-disp-gamma" - gamma correction
> - "mediatek,-disp-merge" - merge streams from two RDMA sources
> - "mediatek,-disp-split" - split stream to two encoders
> - "mediatek,-disp-ufoe"  - data compression engine
> - "mediatek,-dsi"- DSI controller, see mediatek,dsi.txt
> - "mediatek,-dpi"- DPI controller, see mediatek,dpi.txt
> - "mediatek,-disp-mutex" - display mutex
> - "mediatek,-disp-od"- overdrive
> -  the supported chips are mt2701, mt2712 and mt8173.
> + "mediatek,-disp-ovl"  - overlay (4 layers, blending, 
> csc)
> + "mediatek,-disp-ovl-2l"   - overlay (2 layers, blending, 
> csc)
> + "mediatek,-disp-rdma" - read DMA / line buffer
> + "mediatek,-disp-wdma" - write DMA
> + "mediatek,-disp-ccorr"- color correction
> + "mediatek,-disp-color"- color processor
> + "mediatek,-disp-dither"   - dither
> + "mediatek,-disp-aal"  - adaptive ambient light 
> controller
> + "mediatek,-disp-gamma"- gamma correction
> + "mediatek,-disp-merge"- merge streams from two RDMA 
> sources
> + "mediatek,-disp-split"- split stream to two encoders
> + "mediatek,-disp-ufoe" - data compression engine
> + "mediatek,-dsi"   - DSI controller, see 
> mediatek,dsi.txt
> + "mediatek,-dpi"   - DPI controller, see 
> mediatek,dpi.txt
> + "mediatek,-disp-mutex"- display mutex
> + "mediatek,-disp-od"   - overdrive
> +  the supported chips are mt2701, mt2712, mt8173 and mt8183.
>  - reg: Physical base address and length of the function block register space
>  - interrupts: The interrupt signal from the function block (required, except 
> for
>merge and split function blocks).
> @@ -71,6 +74,12 @@ mmsys: clock-controller@1400 {
>   #clock-cells = <1>;
>  };
>  
> +display_components: dispsys@1400 {
> + compatible = "mediatek,mt8183-display";

Documented?

> + reg = <0 0x1400 0 0x1000>;
> + power-domains = < MT8183_POWER_DOMAIN_DISP>;
> +};
> +
>  ovl0: ovl@1400c000 {
>   compatible = "mediatek,mt8173-disp-ovl";
>   reg = <0 0x1400c000 0 0x1000>;
> -- 
> 1.8.1.1.dirty
> 

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

Re: [PATCH] dt-bindings: display/panel: Add missing unit names

[Rob Herring]

On Mon, 25 Mar 2019 17:08:10 +0100, =?UTF-8?q?Guido=20G=C3=BCnther?= wrote:
> Some examples were missing the unit names triggering
> 
>  Warning (unit_address_vs_reg): .../panel: node has a reg or ranges property, 
> but no unit name
> 
> warnings when used verbatim in DTs and running dtc with W=1.
> 
> Signed-off-by: Guido Günther 
> ---
>  .../devicetree/bindings/display/panel/innolux,p079zca.txt   | 2 +-
>  .../devicetree/bindings/display/panel/innolux,p097pfg.txt   | 2 +-
>  .../devicetree/bindings/display/panel/kingdisplay,kd097d04.txt  | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
> 

Reviewed-by: Rob Herring 

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

Re: [PATCHv2 22/22] dt-bindings: tc358767: add IRQ & HPD support

[Rob Herring]

On Tue, Mar 26, 2019 at 12:31:46PM +0200, Tomi Valkeinen wrote:
> Add DT properties needed for IRQ and HPD support.
> 
> Signed-off-by: Tomi Valkeinen 
> Cc: devicet...@vger.kernel.org
> Cc: Rob Herring 
> ---
> 
> A quick summary of tc358767's HPD/GPIO support:
> 
> tc358767 has two pins that can be used as GPIOs. Those can be used for
> HPD by configuring the pin as input. tc358767 supports HW detection of a
> "short" HPD pulse (programmable length) which can be used to detect
> DisplayPort IRQ from the monitor. Afaik, this kind of short pulse
> detection is not possible with common GPIOs found in SoCs.
> 
> While I think the HPD support works ok, I'm unsure about the DT binding.
> I first tried implementing the HPD as a gpiochip, but for interrupts I
> then needed irqchip, and the amount of code started to increase a lot.
> 
> I decided that gpiochip + irqchip just isn't worth the effort and
> complexity here, as most likely the pins will ever be used for HPD.
> 
> So, here I have a simple 'hpd-num' DT property to mark which (if any) of
> the two GPIO pins is used for HPD.

There's similar properties for other chips where some signal has a 
selectable pin assignment.

> 
> Suggestions welcome.
> 
> 
>  .../devicetree/bindings/display/bridge/toshiba,tc358767.txt| 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.txt 
> b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.txt
> index e3f6aa6a214d..79c71e7eb71f 100644
> --- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.txt
> +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.txt
> @@ -12,6 +12,9 @@ Optional properties:
> (active high shutdown input)
>   - reset-gpios: OF device-tree gpio specification for RSTX pin
>  (active low system reset)
> + - interrupt-parent: phandle of the parent interrupt controller

Drop this, it is implied or in the parent.

> + - interrupts: interrupt specifier for the bridge's interrupt
> + - hpd-num: TC358767 GPIO pin number to which HPD is connected to (0 or 1)

ti,hpd-pin

>   - ports: the ports node can contain video interface port nodes to connect
> to a DPI/DSI source and to an eDP/DP sink according to [1][2]:
>  - port@0: DSI input port
> -- 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> 

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

Re: [PATCH v2 2/4] dt-bindings: Add vendor prefix for microtech

[Rob Herring]

On Thu, 21 Mar 2019 19:29:53 +0530, Jagan Teki wrote:
> Add vendor prefix for microtech, known as
> Microtech Technology Company Limited. a known producer for
> Liquid Crytal Display modules and Touch Panels.
> 
> Signed-off-by: Jagan Teki 
> ---
>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>  1 file changed, 1 insertion(+)
> 

Reviewed-by: Rob Herring 

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

Re: [PATCH v2 1/4] dt-bindings: Add vendor prefix for novatek

[Rob Herring]

On Thu, 21 Mar 2019 19:29:52 +0530, Jagan Teki wrote:
> Add vendor prefix for novatek.
> 
> Novatek Microelectronics Corp. is a leading fabless chip design
> company specializing in the design, development and sales of a
> wide range of display driver ICs & SoC solutions.
> 
> Signed-off-by: Jagan Teki 
> ---
>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>  1 file changed, 1 insertion(+)
> 

Reviewed-by: Rob Herring 

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

Re: [PATCH v2 3/4] dt-bindings: display: Add Novatek NT35596 panel documentation

[Rob Herring]

On Thu, 21 Mar 2019 19:29:54 +0530, Jagan Teki wrote:
> Novatek NT35596 is a single-chip IC solution for small or medium-sized
> LTPS TFT LCD panels. NT35596 provides  several system interfaces like
> MIPI/SPI/I2C.
> 
> Microtech MTF050FHDI-03 is 1080x1920, 4-lane MIPI DSI LCD panel which
> has inbuilt NT35596 IC chip.
> 
> NT35596 support several regulators on the chip, among those only 4 regulators
> like VCI, VDDI/DVDD, AVDD, AVEE are used during power-on sequence.
> 
> Out of four regulators MTF050FHDI-03 panel do support 3-regulator based
> power-on sequence, so this patch documented these 3 needful regulators
> and rest can be add while supporting new panels on the similar chip IC.
> 
> Signed-off-by: Jagan Teki 
> ---
>  .../display/panel/novatek,nt35596.txt | 32 +++
>  1 file changed, 32 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/novatek,nt35596.txt
> 

Reviewed-by: Rob Herring 

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

Re: [PATCH v1 2/6] dt-bindings: reset: hisilicon: Update compatible documentation

[Rob Herring]

On Mon, 18 Mar 2019 19:38:47 +, Peter Griffin wrote:
> The reset driver now supports the ao reset controller, so update the
> documentation to match.
> 
> Signed-off-by: Peter Griffin 
> ---
>  Documentation/devicetree/bindings/reset/hisilicon,hi6220-reset.txt | 1 +
>  1 file changed, 1 insertion(+)
> 

Reviewed-by: Rob Herring 

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

Re: [PATCH v1 1/6] dt-bindings: gpu: mali-utgard: add hisilicon, hi6220-mali compatible

[Rob Herring]

On Mon, 18 Mar 2019 19:38:46 +, Peter Griffin wrote:
> The Hisilicon hi6220 uses a Mali-450MP4 with 4 PPs, so add
> a compatible for it.
> 
> Signed-off-by: Peter Griffin 
> ---
>  Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt | 5 +
>  1 file changed, 5 insertions(+)
> 

Reviewed-by: Rob Herring 

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

Re: [PATCH v1 5/6] dt-bindings: reset: hisilicon: Add ao reset controller

[Rob Herring]

On Mon, 18 Mar 2019 19:38:50 +, Peter Griffin wrote:
> This is required to bring Mali450 gpu out of reset.
> 
> Signed-off-by: Peter Griffin 
> ---
>  include/dt-bindings/reset/hisi,hi6220-resets.h | 7 +++
>  1 file changed, 7 insertions(+)
> 

Reviewed-by: Rob Herring 

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

Re: [PATCH v2 1/2] dt-bindings: gpu: mali-midgard: Add resets property

[Rob Herring]

On Fri, 15 Mar 2019 14:56:54 +0100, Neil Armstrong wrote:
> The Amlogic ARM Mali Midgard requires reset controls to power on and
> software reset the GPU, adds these as optional in the bindings.
> 
> Signed-off-by: Neil Armstrong 
> ---
>  .../devicetree/bindings/gpu/arm,mali-midgard.txt   | 14 ++
>  1 file changed, 14 insertions(+)
> 

Reviewed-by: Rob Herring 

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