Re: [PATCH v3] drm/amd: Fix memory leak according to error branch

[Markus Elfring]

> The function kobject_init_and_add alloc memory like:
> kobject_init_and_add->kobject_add_varg->kobject_set_name_vargs
> ->kvasprintf_const->kstrdup_const->kstrdup->kmalloc_track_caller
> ->kmalloc_slab, in err branch this memory not free. If use
> kmemleak, this path maybe catched.
> These changes are to add kobject_put in kobject_init_and_add
> failed branch, fix potential memleak.
…
> Changes since V2:
> *remove duplicate kobject_put in kfd_procfs_init.

Under which circumstances are going to improve this change description 
accordingly?

Would you like to add the tag “Fixes” to the commit message?

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

Re: [Linaro-mm-sig] [PATCH 04/18] dma-fence: prime lockdep annotations

[Jason Gunthorpe]

On Fri, Jun 19, 2020 at 06:19:41PM +0200, Daniel Vetter wrote:

> The madness is only that device B's mmu notifier might need to wait
> for fence_B so that the dma operation finishes. Which in turn has to
> wait for device A to finish first.

So, it sound, fundamentally you've got this graph of operations across
an unknown set of drivers and the kernel cannot insert itself in
dma_fence hand offs to re-validate any of the buffers involved?
Buffers which by definition cannot be touched by the hardware yet.

That really is a pretty horrible place to end up..

Pinning really is right answer for this kind of work flow. I think
converting pinning to notifers should not be done unless notifier
invalidation is relatively bounded. 

I know people like notifiers because they give a bit nicer performance
in some happy cases, but this cripples all the bad cases..

If pinning doesn't work for some reason maybe we should address that?

> Full disclosure: We are aware that we've designed ourselves into an
> impressive corner here, and there's lots of talks going on about
> untangling the dma synchronization from the memory management
> completely. But

I think the documenting is really important: only GPU should be using
this stuff and driving notifiers this way. Complete NO for any
totally-not-a-GPU things in drivers/accel for sure.

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

[PATCH v2] dmabuf: use spinlock to access dmabuf->name

[Charan Teja Kalla]

There exists a sleep-while-atomic bug while accessing the dmabuf->name
under mutex in the dmabuffs_dname(). This is caused from the SELinux
permissions checks on a process where it tries to validate the inherited
files from fork() by traversing them through iterate_fd() (which
traverse files under spin_lock) and call
match_file(security/selinux/hooks.c) where the permission checks happen.
This audit information is logged using dump_common_audit_data() where it
calls d_path() to get the file path name. If the file check happen on
the dmabuf's fd, then it ends up in ->dmabuffs_dname() and use mutex to
access dmabuf->name. The flow will be like below:
flush_unauthorized_files()
  iterate_fd()
spin_lock() --> Start of the atomic section.
  match_file()
file_has_perm()
  avc_has_perm()
avc_audit()
  slow_avc_audit()
common_lsm_audit()
  dump_common_audit_data()
audit_log_d_path()
  d_path()
dmabuffs_dname()
  mutex_lock()--> Sleep while atomic.

Call trace captured (on 4.19 kernels) is below:
___might_sleep+0x204/0x208
__might_sleep+0x50/0x88
__mutex_lock_common+0x5c/0x1068
__mutex_lock_common+0x5c/0x1068
mutex_lock_nested+0x40/0x50
dmabuffs_dname+0xa0/0x170
d_path+0x84/0x290
audit_log_d_path+0x74/0x130
common_lsm_audit+0x334/0x6e8
slow_avc_audit+0xb8/0xf8
avc_has_perm+0x154/0x218
file_has_perm+0x70/0x180
match_file+0x60/0x78
iterate_fd+0x128/0x168
selinux_bprm_committing_creds+0x178/0x248
security_bprm_committing_creds+0x30/0x48
install_exec_creds+0x1c/0x68
load_elf_binary+0x3a4/0x14e0
search_binary_handler+0xb0/0x1e0

So, use spinlock to access dmabuf->name to avoid sleep-while-atomic.

Cc:  [5.3+]
Signed-off-by: Charan Teja Reddy 
---

Changes in V2: Addressed review comments from Ruhl, Michael J

Changes in V1: https://lore.kernel.org/patchwork/patch/1255055/

 drivers/dma-buf/dma-buf.c | 11 +++
 include/linux/dma-buf.h   |  1 +
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 01ce125..d81d298 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -45,10 +45,10 @@ static char *dmabuffs_dname(struct dentry *dentry, char 
*buffer, int buflen)
size_t ret = 0;
 
dmabuf = dentry->d_fsdata;
-   dma_resv_lock(dmabuf->resv, NULL);
+   spin_lock(&dmabuf->name_lock);
if (dmabuf->name)
ret = strlcpy(name, dmabuf->name, DMA_BUF_NAME_LEN);
-   dma_resv_unlock(dmabuf->resv);
+   spin_unlock(&dmabuf->name_lock);
 
return dynamic_dname(dentry, buffer, buflen, "/%s:%s",
 dentry->d_name.name, ret > 0 ? name : "");
@@ -341,8 +341,10 @@ static long dma_buf_set_name(struct dma_buf *dmabuf, const 
char __user *buf)
kfree(name);
goto out_unlock;
}
+   spin_lock(&dmabuf->name_lock);
kfree(dmabuf->name);
dmabuf->name = name;
+   spin_unlock(&dmabuf->name_lock);
 
 out_unlock:
dma_resv_unlock(dmabuf->resv);
@@ -405,10 +407,10 @@ static void dma_buf_show_fdinfo(struct seq_file *m, 
struct file *file)
/* Don't count the temporary reference taken inside procfs seq_show */
seq_printf(m, "count:\t%ld\n", file_count(dmabuf->file) - 1);
seq_printf(m, "exp_name:\t%s\n", dmabuf->exp_name);
-   dma_resv_lock(dmabuf->resv, NULL);
+   spin_lock(&dmabuf->name_lock);
if (dmabuf->name)
seq_printf(m, "name:\t%s\n", dmabuf->name);
-   dma_resv_unlock(dmabuf->resv);
+   spin_unlock(&dmabuf->name_lock);
 }
 
 static const struct file_operations dma_buf_fops = {
@@ -546,6 +548,7 @@ struct dma_buf *dma_buf_export(const struct 
dma_buf_export_info *exp_info)
dmabuf->size = exp_info->size;
dmabuf->exp_name = exp_info->exp_name;
dmabuf->owner = exp_info->owner;
+   spin_lock_init(&dmabuf->name_lock);
init_waitqueue_head(&dmabuf->poll);
dmabuf->cb_excl.poll = dmabuf->cb_shared.poll = &dmabuf->poll;
dmabuf->cb_excl.active = dmabuf->cb_shared.active = 0;
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index ab0c156..93108fd 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -311,6 +311,7 @@ struct dma_buf {
void *vmap_ptr;
const char *exp_name;
const char *name;
+   spinlock_t name_lock;
struct module *owner;
struct list_head list_node;
void *priv;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a 
Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] mm: Track mmu notifiers in fs_reclaim_acquire/release

[Qian Cai]

On Wed, Jun 10, 2020 at 09:41:01PM +0200, Daniel Vetter wrote:
> fs_reclaim_acquire/release nicely catch recursion issues when
> allocating GFP_KERNEL memory against shrinkers (which gpu drivers tend
> to use to keep the excessive caches in check). For mmu notifier
> recursions we do have lockdep annotations since 23b68395c7c7
> ("mm/mmu_notifiers: add a lockdep map for invalidate_range_start/end").
> 
> But these only fire if a path actually results in some pte
> invalidation - for most small allocations that's very rarely the case.
> The other trouble is that pte invalidation can happen any time when
> __GFP_RECLAIM is set. Which means only really GFP_ATOMIC is a safe
> choice, GFP_NOIO isn't good enough to avoid potential mmu notifier
> recursion.
> 
> I was pondering whether we should just do the general annotation, but
> there's always the risk for false positives. Plus I'm assuming that
> the core fs and io code is a lot better reviewed and tested than
> random mmu notifier code in drivers. Hence why I decide to only
> annotate for that specific case.
> 
> Furthermore even if we'd create a lockdep map for direct reclaim, we'd
> still need to explicit pull in the mmu notifier map - there's a lot
> more places that do pte invalidation than just direct reclaim, these
> two contexts arent the same.
> 
> Note that the mmu notifiers needing their own independent lockdep map
> is also the reason we can't hold them from fs_reclaim_acquire to
> fs_reclaim_release - it would nest with the acquistion in the pte
> invalidation code, causing a lockdep splat. And we can't remove the
> annotations from pte invalidation and all the other places since
> they're called from many other places than page reclaim. Hence we can
> only do the equivalent of might_lock, but on the raw lockdep map.
> 
> With this we can also remove the lockdep priming added in 66204f1d2d1b
> ("mm/mmu_notifiers: prime lockdep") since the new annotations are
> strictly more powerful.
> 
> v2: Review from Thomas Hellstrom:
> - unbotch the fs_reclaim context check, I accidentally inverted it,
>   but it didn't blow up because I inverted it immediately
> - fix compiling for !CONFIG_MMU_NOTIFIER
> 
> Cc: Thomas Hellström (Intel) 
> Cc: Andrew Morton 
> Cc: Jason Gunthorpe 
> Cc: linux...@kvack.org
> Cc: linux-r...@vger.kernel.org
> Cc: Maarten Lankhorst 
> Cc: Christian König 
> Signed-off-by: Daniel Vetter 

Replying the right patch here...

Reverting this commit [1] fixed the lockdep warning below while applying
some memory pressure.

[1] linux-next cbf7c9d86d75 ("mm: track mmu notifiers in 
fs_reclaim_acquire/release")

[  190.455003][  T369] WARNING: possible circular locking dependency detected
[  190.487291][  T369] 5.8.0-rc1-next-20200621 #1 Not tainted
[  190.512363][  T369] --
[  190.543354][  T369] kswapd3/369 is trying to acquire lock:
[  190.568523][  T369] 889fcf694528 (&xfs_nondir_ilock_class){}-{3:3}, 
at: xfs_reclaim_inode+0xdf/0x860
spin_lock at include/linux/spinlock.h:353
(inlined by) xfs_iflags_test_and_set at fs/xfs/xfs_inode.h:166
(inlined by) xfs_iflock_nowait at fs/xfs/xfs_inode.h:249
(inlined by) xfs_reclaim_inode at fs/xfs/xfs_icache.c:1127
[  190.614359][  T369]
[  190.614359][  T369] but task is already holding lock:
[  190.647763][  T369] b50ced00 (fs_reclaim){+.+.}-{0:0}, at: 
__fs_reclaim_acquire+0x0/0x30
__fs_reclaim_acquire at mm/page_alloc.c:4200
[  190.687845][  T369]
[  190.687845][  T369] which lock already depends on the new lock.
[  190.687845][  T369]
[  190.734890][  T369]
[  190.734890][  T369] the existing dependency chain (in reverse order) is:
[  190.775991][  T369]
[  190.775991][  T369] -> #1 (fs_reclaim){+.+.}-{0:0}:
[  190.808150][  T369]fs_reclaim_acquire+0x77/0x80
[  190.832152][  T369]slab_pre_alloc_hook.constprop.52+0x20/0x120
slab_pre_alloc_hook at mm/slab.h:507
[  190.862173][  T369]kmem_cache_alloc+0x43/0x2a0
[  190.885602][  T369]kmem_zone_alloc+0x113/0x3ef
kmem_zone_alloc at fs/xfs/kmem.c:129
[  190.908702][  T369]xfs_inode_item_init+0x1d/0xa0
xfs_inode_item_init at fs/xfs/xfs_inode_item.c:639
[  190.934461][  T369]xfs_trans_ijoin+0x96/0x100
xfs_trans_ijoin at fs/xfs/libxfs/xfs_trans_inode.c:34
[  190.961530][  T369]xfs_setattr_nonsize+0x1a6/0xcd0
xfs_setattr_nonsize at fs/xfs/xfs_iops.c:716
[  190.987331][  T369]xfs_vn_setattr+0x133/0x160
xfs_vn_setattr at fs/xfs/xfs_iops.c:1081
[  191.010476][  T369]notify_change+0x6c5/0xba1
notify_change at fs/attr.c:336
[  191.033317][  T369]chmod_common+0x19b/0x390
[  191.055770][  T369]ksys_fchmod+0x28/0x60
[  191.077957][  T369]__x64_sys_fchmod+0x4e/0x70
[  191.102767][  T369]do_syscall_64+0x5f/0x310
[  191.125090][  T369]entry_SYSCALL_64_after_hwframe+0x44/0xa9
[  191.153749][  T369]
[  191.153749][  T369] -> #0 (&xfs_nondir_ilock_class){}-{3:3}:
[  191.191267][  T369]  

Re: [Linaro-mm-sig] [PATCH 04/18] dma-fence: prime lockdep annotations

[Jason Gunthorpe]

On Fri, Jun 19, 2020 at 02:09:35PM -0400, Jerome Glisse wrote:
> On Fri, Jun 19, 2020 at 02:23:08PM -0300, Jason Gunthorpe wrote:
> > On Fri, Jun 19, 2020 at 06:19:41PM +0200, Daniel Vetter wrote:
> > 
> > > The madness is only that device B's mmu notifier might need to wait
> > > for fence_B so that the dma operation finishes. Which in turn has to
> > > wait for device A to finish first.
> > 
> > So, it sound, fundamentally you've got this graph of operations across
> > an unknown set of drivers and the kernel cannot insert itself in
> > dma_fence hand offs to re-validate any of the buffers involved?
> > Buffers which by definition cannot be touched by the hardware yet.
> > 
> > That really is a pretty horrible place to end up..
> > 
> > Pinning really is right answer for this kind of work flow. I think
> > converting pinning to notifers should not be done unless notifier
> > invalidation is relatively bounded. 
> > 
> > I know people like notifiers because they give a bit nicer performance
> > in some happy cases, but this cripples all the bad cases..
> > 
> > If pinning doesn't work for some reason maybe we should address that?
> 
> Note that the dma fence is only true for user ptr buffer which predate
> any HMM work and thus were using mmu notifier already. You need the
> mmu notifier there because of fork and other corner cases.

I wonder if we should try to fix the fork case more directly - RDMA
has this same problem and added MADV_DONTFORK a long time ago as a
hacky way to deal with it.

Some crazy page pin that resolved COW in a way that always kept the
physical memory with the mm that initiated the pin?

(isn't this broken for O_DIRECT as well anyhow?)

How does mmu_notifiers help the fork case anyhow? Block fork from
progressing?

> I probably need to warn AMD folks again that using HMM means that you
> must be able to update the GPU page table asynchronously without
> fence wait.

It is kind of unrelated to HMM, it just shouldn't be using mmu
notifiers to replace page pinning..

> The issue for AMD is that they already update their GPU page table
> using DMA engine. I believe this is still doable if they use a
> kernel only DMA engine context, where only kernel can queue up jobs
> so that you do not need to wait for unrelated things and you can
> prioritize GPU page table update which should translate in fast GPU
> page table update without DMA fence.

Make sense

I'm not sure I saw this in the AMD hmm stuff - it would be good if
someone would look at that. Every time I do it looks like the locking
is wrong.

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

[PATCH v1 07/11] soc: mediatek: cmdq: add write_s_mask value function

[Dennis YC Hsieh]

add write_s_mask_value function in cmdq helper functions which
writes a constant value to address with mask and large dma
access support.

Signed-off-by: Dennis YC Hsieh 
---
 drivers/soc/mediatek/mtk-cmdq-helper.c |   21 +
 include/linux/soc/mediatek/mtk-cmdq.h  |   15 +++
 2 files changed, 36 insertions(+)

diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c 
b/drivers/soc/mediatek/mtk-cmdq-helper.c
index 2ad78df46636..e372ae065240 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -293,6 +293,27 @@ int cmdq_pkt_write_s_value(struct cmdq_pkt *pkt, u8 
high_addr_reg_idx,
 }
 EXPORT_SYMBOL(cmdq_pkt_write_s_value);
 
+int cmdq_pkt_write_s_mask_value(struct cmdq_pkt *pkt, u8 high_addr_reg_idx,
+   u16 addr_low, u32 value, u32 mask)
+{
+   struct cmdq_instruction inst = {};
+   int err;
+
+   inst.op = CMDQ_CODE_MASK;
+   inst.mask = ~mask;
+   err = cmdq_pkt_append_command(pkt, inst);
+   if (err < 0)
+   return err;
+
+   inst.op = CMDQ_CODE_WRITE_S_MASK;
+   inst.sop = high_addr_reg_idx;
+   inst.offset = addr_low;
+   inst.value = value;
+
+   return cmdq_pkt_append_command(pkt, inst);
+}
+EXPORT_SYMBOL(cmdq_pkt_write_s_mask_value);
+
 int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
 {
struct cmdq_instruction inst = { {0} };
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h 
b/include/linux/soc/mediatek/mtk-cmdq.h
index 7f1c115a66b8..6e8caacedc80 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -165,6 +165,21 @@ int cmdq_pkt_write_s_value(struct cmdq_pkt *pkt, u8 
high_addr_reg_idx,
   u16 addr_low, u32 value);
 
 /**
+ * cmdq_pkt_write_s_mask_value() - append write_s command with mask to the CMDQ
+ *packet which write value to a physical
+ *address
+ * @pkt:   the CMDQ packet
+ * @high_addr_reg_idx: internal register ID which contains high address of pa
+ * @addr_low:  low address of pa
+ * @value: the specified target value
+ * @mask:  the specified target mask
+ *
+ * Return: 0 for success; else the error code is returned
+ */
+int cmdq_pkt_write_s_mask_value(struct cmdq_pkt *pkt, u8 high_addr_reg_idx,
+   u16 addr_low, u32 value, u32 mask);
+
+/**
  * cmdq_pkt_wfe() - append wait for event command to the CMDQ packet
  * @pkt:   the CMDQ packet
  * @event: the desired event type to "wait and CLEAR"
-- 
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Linaro-mm-sig] [PATCH 04/18] dma-fence: prime lockdep annotations

[Jason Gunthorpe]

On Fri, Jun 19, 2020 at 03:30:32PM -0400, Felix Kuehling wrote:
> We have a potential problem with CPU updating page tables while the GPU
> is retrying on page table entries because 64 bit CPU transactions don't
> arrive in device memory atomically.

Except for 32 bit platforms atomicity is guarenteed if you use uncached
writeq() to aligned addresses..

The linux driver model breaks of the writeX() stuff is not atomic.

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

Re: [PATCH v4 3/5] drm: panel: Add Xingbangda XBD599 panel (ST7703 controller)

[Ondřej Jirman]

On Sat, Jun 20, 2020 at 11:25:29PM +0200, Sam Ravnborg wrote:
> Hi Ondrej et al.
> 
> On Wed, Jun 17, 2020 at 02:32:07AM +0200, Ondrej Jirman wrote:
> > From: Icenowy Zheng 
> > 
> > Xingbangda XBD599 is a 5.99" 720x1440 MIPI-DSI IPS LCD panel made by
> > Xingbangda, which is used on PinePhone final assembled phones.
> > 
> > It is based on Sitronix ST7703 LCD controller.
> 
> I am a little late to the game here - so sorry if this has been
> discussed before.
> We already have panel-rocktech-jh057n00900.c which is a panle driver
> based on st7703.
> Why is it we need a new driver?

No reason other than the driver not being named after the controller,
so I didn't notice.

> Would it not be better to have one st7703 driver that suipports both
> panels?
>
> The driver would need dedicated init functions depending on the panel.
> But a lot could also be shared.

I guess I can move the code there. 

regards,
o.

>   Sam
> 
> > 
> > Add support for it.
> > 
> > Signed-off-by: Icenowy Zheng 
> > Signed-off-by: Ondrej Jirman 
> > ---
> >  drivers/gpu/drm/panel/Kconfig |  10 +
> >  drivers/gpu/drm/panel/Makefile|   1 +
> >  drivers/gpu/drm/panel/panel-sitronix-st7703.c | 535 ++
> >  3 files changed, 546 insertions(+)
> >  create mode 100644 drivers/gpu/drm/panel/panel-sitronix-st7703.c
> > 
> > diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> > index 39055c1f0e2f..b7bc157b0612 100644
> > --- a/drivers/gpu/drm/panel/Kconfig
> > +++ b/drivers/gpu/drm/panel/Kconfig
> > @@ -395,6 +395,16 @@ config DRM_PANEL_SITRONIX_ST7701
> >   ST7701 controller for 480X864 LCD panels with MIPI/RGB/SPI
> >   system interfaces.
> >  
> > +config DRM_PANEL_SITRONIX_ST7703
> > +   tristate "Sitronix ST7703 panel driver"
> > +   depends on OF
> > +   depends on DRM_MIPI_DSI
> > +   depends on BACKLIGHT_CLASS_DEVICE
> > +   help
> > + Say Y here if you want to enable support for the Sitronix
> > + ST7703 controller for 720X1440 LCD panels with MIPI/RGB/SPI
> > + system interfaces.
> > +
> >  config DRM_PANEL_SITRONIX_ST7789V
> > tristate "Sitronix ST7789V panel"
> > depends on OF && SPI
> > diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> > index de74f282c433..47f4789a8685 100644
> > --- a/drivers/gpu/drm/panel/Makefile
> > +++ b/drivers/gpu/drm/panel/Makefile
> > @@ -41,6 +41,7 @@ obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += 
> > panel-sharp-lq101r1sx01.o
> >  obj-$(CONFIG_DRM_PANEL_SHARP_LS037V7DW01) += panel-sharp-ls037v7dw01.o
> >  obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
> >  obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7701) += panel-sitronix-st7701.o
> > +obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7703) += panel-sitronix-st7703.o
> >  obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
> >  obj-$(CONFIG_DRM_PANEL_SONY_ACX424AKP) += panel-sony-acx424akp.o
> >  obj-$(CONFIG_DRM_PANEL_SONY_ACX565AKM) += panel-sony-acx565akm.o
> > diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c 
> > b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> > new file mode 100644
> > index ..dbd46b6c0b46
> > --- /dev/null
> > +++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> > @@ -0,0 +1,535 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * DRM driver for Sitronix ST7703 MIPI DSI panel
> > + *
> > + * Copyright (C) 2020 Ondrej Jirman 
> > + * Copyright (C) 2019-2020 Icenowy Zheng 
> > + *
> > + * Based on panel-rocktech-jh057n00900.c, which is:
> > + *   Copyright (C) Purism SPC 2019
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +/* Manufacturer specific DCS commands */
> > +#define ST7703_CMD_SETDISP 0xB2
> > +#define ST7703_CMD_SETRGBIF0xB3
> > +#define ST7703_CMD_SETCYC  0xB4
> > +#define ST7703_CMD_SETBGP  0xB5
> > +#define ST7703_CMD_SETVCOM 0xB6
> > +#define ST7703_CMD_SETOTP  0xB7
> > +#define ST7703_CMD_SETPOWER_EXT0xB8
> > +#define ST7703_CMD_SETEXTC 0xB9
> > +#define ST7703_CMD_SETMIPI 0xBA
> > +#define ST7703_CMD_SETVDC  0xBC
> > +#define ST7703_CMD_UNK_BF  0xBF
> > +#define ST7703_CMD_SETSCR  0xC0
> > +#define ST7703_CMD_SETPOWER0xC1
> > +#define ST7703_CMD_UNK_C6  0xC6
> > +#define ST7703_CMD_SETPANEL0xCC
> > +#define ST7703_CMD_RDID1   0xDA
> > +#define ST7703_CMD_RDID2   0xDB
> > +#define ST7703_CMD_RDID3   0xDC
> > +#define ST7703_CMD_SETGAMMA0xE0
> > +#define ST7703_CMD_SETEQ   0xE3
> > +#define ST7703_CMD_SETGIP1 0xE9
> > +#define ST7703_CMD_SETGIP2 0xEA
> > +
> > +struct st7703_panel_desc {
> > +   const struct drm_display_mode *mode;
> > +   unsigned int lanes;
> > +   unsigned long flags;
> > +   enum mipi_dsi_pixel_format format;
> > +   const char *const *supply_names;
> > +   unsigned int num_supplies;
> > +};
> > +
> > +struct st7703 {
> > +   struct device *dev;

Re: [Linaro-mm-sig] [PATCH 04/18] dma-fence: prime lockdep annotations

[Jason Gunthorpe]

On Fri, Jun 19, 2020 at 05:06:04PM +0200, Daniel Vetter wrote:
> On Fri, Jun 19, 2020 at 1:39 PM Jason Gunthorpe  wrote:
> >
> > On Fri, Jun 19, 2020 at 09:22:09AM +0200, Daniel Vetter wrote:
> > > > As I've understood GPU that means you need to show that the commands
> > > > associated with the buffer have completed. This is all local stuff
> > > > within the driver, right? Why use fence (other than it already exists)
> > >
> > > Because that's the end-of-dma thing. And it's cross-driver for the
> > > above reasons, e.g.
> > > - device A renders some stuff. Userspace gets dma_fence A out of that
> > > (well sync_file or one of the other uapi interfaces, but you get the
> > > idea)
> > > - userspace (across process or just different driver) issues more
> > > rendering for device B, which depends upon the rendering done on
> > > device A. So dma_fence A is an dependency and will block this dma
> > > operation. Userspace (and the kernel) gets dma_fence B out of this
> > > - because unfortunate reasons, the same rendering on device B also
> > > needs a userptr buffer, which means that dma_fence B is also the one
> > > that the mmu_range_notifier needs to wait on before it can tell core
> > > mm that it can go ahead and release those pages
> >
> > I was afraid you'd say this - this is complete madness for other DMA
> > devices to borrow the notifier hook of the first device!
> 
> The first device might not even have a notifier. This is the 2nd
> device, waiting on a dma_fence of its own, but which happens to be
> queued up as a dma operation behind something else.
> 
> > What if the first device is a page faulting device and doesn't call
> > dma_fence??
> 
> Not sure what you mean with this ... even if it does page-faulting for
> some other reasons, it'll emit a dma_fence which the 2nd device can
> consume as a dependency.

At some point the pages under the buffer have to be either pinned
or protected by mmu notifier. So each and every single device doing
DMA to these pages must either pin, or use mmu notifier.

Driver A should never 'borrow' a notifier from B

If each driver controls its own lifetime of the buffers, why can't the
driver locally wait for its device to finish?

Can't the GPUs cancel work that is waiting on a DMA fence? Ie if
Driver A detects that work completed and wants to trigger a DMA fence,
but it now knows the buffer is invalidated, can't it tell driver B to
give up?

> The problem is that there's piles of other dependencies for a dma job.
> GPU doesn't just consume a single buffer each time, it consumes entire
> lists of buffers and mixes them all up in funny ways. Some of these
> buffers are userptr, entirely local to the device. Other buffers are
> just normal device driver allocations (and managed with some shrinker
> to keep them in check). And then there's the actually shared dma-buf
> with other devices. The trouble is that they're all bundled up
> together.

But why does this matter? Does the GPU itself consume some work and
then stall internally waiting for an external DMA fence?

Otherwise I would expect this dependency chain should be breakable by
aborting work waiting on fences upon invalidation (without stalling)

> > Do not need to wait on dma_fence in notifiers.
> 
> Maybe :-) The goal of this series is more to document current rules
> and make them more consistent. Fixing them if we don't like them might
> be a follow-up task, but that would likely be a pile more work. First
> we need to know what the exact shape of the problem even is.

Fair enough

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

Re: [PATCH v2] drm/amdkfd: Fix memory leaks according to error branches

[Markus Elfring]

> The function kobject_init_and_add alloc memory like:
> kobject_init_and_add->kobject_add_varg->kobject_set_name_vargs
> ->kvasprintf_const->kstrdup_const->kstrdup->kmalloc_track_caller
> ->kmalloc_slab, in err branch this memory not free. If use
> kmemleak, this path maybe catched.
> These changes are to add kobject_put in kobject_init_and_add
> failed branch, fix potential memleak.

I suggest to improve this change description.

* Can an other wording variant be nicer?

* Will the tag “Fixes” become helpful for the commit message?

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

Re: [PATCH 0/6] remove deprecated i2c_new_device API

[Wolfram Sang]

On Mon, Jun 15, 2020 at 09:58:09AM +0200, Wolfram Sang wrote:
> I want to remove the above API this cycle, and just a few patches have
> not made it into 5.8-rc1. They have been reviewed and most had been
> promised to get into linux-next, but well, things happen. So, I hope it
> is okay for everyone to collect them like this and push them via I2C for
> 5.8-rc2.
> 
> One minor exception is the media documentation patch which I simply have
> missed so far, but it is trivial.
> 
> And then, finally, there is the removal of the old API as the final
> patch. Phew, that's been a long ride.
> 
> I am open for comments, of course.

Applied to for-current, thanks!



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

[PATCH v1 05/11] soc: mediatek: cmdq: add read_s function

[Dennis YC Hsieh]

Add read_s function in cmdq helper functions which support read value from
register or dma physical address into gce internal register.

Signed-off-by: Dennis YC Hsieh 
---
 drivers/soc/mediatek/mtk-cmdq-helper.c   |   15 +++
 include/linux/mailbox/mtk-cmdq-mailbox.h |1 +
 include/linux/soc/mediatek/mtk-cmdq.h|   12 
 3 files changed, 28 insertions(+)

diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c 
b/drivers/soc/mediatek/mtk-cmdq-helper.c
index 13b888779093..58075589509b 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -226,6 +226,21 @@ int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u8 subsys,
 }
 EXPORT_SYMBOL(cmdq_pkt_write_mask);
 
+int cmdq_pkt_read_s(struct cmdq_pkt *pkt, u16 high_addr_reg_idx, u16 addr_low,
+   u16 reg_idx)
+{
+   struct cmdq_instruction inst = {};
+
+   inst.op = CMDQ_CODE_READ_S;
+   inst.dst_t = CMDQ_REG_TYPE;
+   inst.sop = high_addr_reg_idx;
+   inst.reg_dst = reg_idx;
+   inst.src_reg = addr_low;
+
+   return cmdq_pkt_append_command(pkt, inst);
+}
+EXPORT_SYMBOL(cmdq_pkt_read_s);
+
 int cmdq_pkt_write_s(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
 u16 addr_low, u16 src_reg_idx)
 {
diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h 
b/include/linux/mailbox/mtk-cmdq-mailbox.h
index 8ef87e1bd03b..3f6bc0dfd5da 100644
--- a/include/linux/mailbox/mtk-cmdq-mailbox.h
+++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
@@ -59,6 +59,7 @@ enum cmdq_code {
CMDQ_CODE_JUMP = 0x10,
CMDQ_CODE_WFE = 0x20,
CMDQ_CODE_EOC = 0x40,
+   CMDQ_CODE_READ_S = 0x80,
CMDQ_CODE_WRITE_S = 0x90,
CMDQ_CODE_WRITE_S_MASK = 0x91,
CMDQ_CODE_LOGIC = 0xa0,
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h 
b/include/linux/soc/mediatek/mtk-cmdq.h
index ca9c75fd8125..40fe1eb52190 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -104,6 +104,18 @@ struct cmdq_client *cmdq_mbox_create(struct device *dev, 
int index,
 int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u8 subsys,
u16 offset, u32 value, u32 mask);
 
+/*
+ * cmdq_pkt_read_s() - append read_s command to the CMDQ packet
+ * @pkt:   the CMDQ packet
+ * @high_addr_reg_idx: internal register ID which contains high address of pa
+ * @addr_low:  low address of pa
+ * @reg_idx:   the CMDQ internal register ID to cache read data
+ *
+ * Return: 0 for success; else the error code is returned
+ */
+int cmdq_pkt_read_s(struct cmdq_pkt *pkt, u16 high_addr_reg_idx, u16 addr_low,
+   u16 reg_idx);
+
 /**
  * cmdq_pkt_write_s() - append write_s command to the CMDQ packet
  * @pkt:   the CMDQ packet
-- 
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v8 7/7] drm/panel-simple: Add missing connector type for some panels

[Dmitry Osipenko]

20.06.2020 17:31, Sam Ravnborg пишет:
> Hi Dmitry
> 
>>
>> Oops! Good catch!
> Yep, thanks Laurent. Should have taken a better look before applying.
> 
>> Indeed, I blindly set the LVDS type to all these
>> panels. Please revert this patch, I'll double check each panel and
>> prepare an updated version of this patch. Thank you very much for the
>> review!
> 
> If you can prepare a fix within a few days then lets wait for that.
> I will do a better review next time.

Hello Sam,

I should be able to make it later today or tomorrow. Could you please
clarify what do you mean by the fix, do you what it to be as an
additional patch on top of the applied one or a new version of the patch?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: fix double free for gbo in drm_gem_vram_init and drm_gem_vram_create

[Jia Yang]

I got a use-after-free report when doing some fuzz test:

If ttm_bo_init() fails, the "gbo" and "gbo->bo.base" will be
freed by ttm_buffer_object_destroy() in ttm_bo_init(). But
then drm_gem_vram_create() and drm_gem_vram_init() will free
"gbo" and "gbo->bo.base" again.

BUG: KMSAN: use-after-free in drm_vma_offset_remove+0xb3/0x150
CPU: 0 PID: 24282 Comm: syz-executor.1 Tainted: GB   W 
5.7.0-rc4-msan #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Ubuntu-1.8.2-1ubuntu1 04/01/2014
Call Trace:
 __dump_stack
 dump_stack+0x1c9/0x220
 kmsan_report+0xf7/0x1e0
 __msan_warning+0x58/0xa0
 drm_vma_offset_remove+0xb3/0x150
 drm_gem_free_mmap_offset
 drm_gem_object_release+0x159/0x180
 drm_gem_vram_init
 drm_gem_vram_create+0x7c5/0x990
 drm_gem_vram_fill_create_dumb
 drm_gem_vram_driver_dumb_create+0x238/0x590
 drm_mode_create_dumb
 drm_mode_create_dumb_ioctl+0x41d/0x450
 drm_ioctl_kernel+0x5a4/0x710
 drm_ioctl+0xc6f/0x1240
 vfs_ioctl
 ksys_ioctl
 __do_sys_ioctl
 __se_sys_ioctl+0x2e9/0x410
 __x64_sys_ioctl+0x4a/0x70
 do_syscall_64+0xb8/0x160
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x4689b9
Code: fd e0 fa ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 
89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 
cb e0 fa ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:7f368fa4dc98 EFLAGS: 0246 ORIG_RAX: 0010
RAX: ffda RBX: 0076bf00 RCX: 004689b9
RDX: 2240 RSI: c02064b2 RDI: 0003
RBP: 0004 R08:  R09: 
R10:  R11: 0246 R12: 
R13: 004d17e0 R14: 7f368fa4e6d4 R15: 0076bf0c

Uninit was created at:
 kmsan_save_stack_with_flags
 kmsan_internal_poison_shadow+0x66/0xd0
 kmsan_slab_free+0x6e/0xb0
 slab_free_freelist_hook
 slab_free
 kfree+0x571/0x30a0
 drm_gem_vram_destroy
 ttm_buffer_object_destroy+0xc8/0x130
 ttm_bo_release
 kref_put
 ttm_bo_put+0x117d/0x23e0
 ttm_bo_init_reserved+0x11c0/0x11d0
 ttm_bo_init+0x289/0x3f0
 drm_gem_vram_init
 drm_gem_vram_create+0x775/0x990
 drm_gem_vram_fill_create_dumb
 drm_gem_vram_driver_dumb_create+0x238/0x590
 drm_mode_create_dumb
 drm_mode_create_dumb_ioctl+0x41d/0x450
 drm_ioctl_kernel+0x5a4/0x710
 drm_ioctl+0xc6f/0x1240
 vfs_ioctl
 ksys_ioctl
 __do_sys_ioctl
 __se_sys_ioctl+0x2e9/0x410
 __x64_sys_ioctl+0x4a/0x70
 do_syscall_64+0xb8/0x160
 entry_SYSCALL_64_after_hwframe+0x44/0xa9

If ttm_bo_init() fails, the "gbo" will be freed by
ttm_buffer_object_destroy() in ttm_bo_init(). But then
drm_gem_vram_create() and drm_gem_vram_init() will free
"gbo" again.

Reported-by: Hulk Robot 
Signed-off-by: Jia Yang 
---
 drivers/gpu/drm/drm_gem_vram_helper.c | 28 +++
 1 file changed, 16 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c 
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 8b2d5c945c95..1d85af9a481a 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -175,6 +175,10 @@ static void drm_gem_vram_placement(struct 
drm_gem_vram_object *gbo,
}
 }
 
+/*
+ * Note that on error, drm_gem_vram_init will free the buffer object.
+ */
+
 static int drm_gem_vram_init(struct drm_device *dev,
 struct drm_gem_vram_object *gbo,
 size_t size, unsigned long pg_align)
@@ -184,15 +188,19 @@ static int drm_gem_vram_init(struct drm_device *dev,
int ret;
size_t acc_size;
 
-   if (WARN_ONCE(!vmm, "VRAM MM not initialized"))
+   if (WARN_ONCE(!vmm, "VRAM MM not initialized")) {
+   kfree(gbo);
return -EINVAL;
+   }
bdev = &vmm->bdev;
 
gbo->bo.base.funcs = &drm_gem_vram_object_funcs;
 
ret = drm_gem_object_init(dev, &gbo->bo.base, size);
-   if (ret)
+   if (ret) {
+   kfree(gbo);
return ret;
+   }
 
acc_size = ttm_bo_dma_acc_size(bdev, size, sizeof(*gbo));
 
@@ -203,13 +211,13 @@ static int drm_gem_vram_init(struct drm_device *dev,
  &gbo->placement, pg_align, false, acc_size,
  NULL, NULL, ttm_buffer_object_destroy);
if (ret)
-   goto err_drm_gem_object_release;
+   /*
+* A failing ttm_bo_init will call ttm_buffer_object_destroy
+* to release gbo->bo.base and kfree gbo.
+*/
+   return ret;
 
return 0;
-
-err_drm_gem_object_release:
-   drm_gem_object_release(&gbo->bo.base);
-   return ret;
 }
 
 /**
@@ -243,13 +251,9 @@ struct drm_gem_vram_object *drm_gem_vram_create(struct 
drm_device *dev,
 
ret = drm_gem_vram_init(dev, gbo, size, pg_align);
if (ret < 0)
-   goto err_kfree;
+   return ERR_PTR(ret);
 
return gbo;
-
-err_kfree:
-   kfree(gbo);
-   return ERR_PTR(ret);

[PATCH v1 03/11] soc: mediatek: cmdq: add write_s function

[Dennis YC Hsieh]

add write_s function in cmdq helper functions which
writes value contains in internal register to address
with large dma access support.

Signed-off-by: Dennis YC Hsieh 
---
 drivers/soc/mediatek/mtk-cmdq-helper.c   |   19 +++
 include/linux/mailbox/mtk-cmdq-mailbox.h |1 +
 include/linux/soc/mediatek/mtk-cmdq.h|   19 +++
 3 files changed, 39 insertions(+)

diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c 
b/drivers/soc/mediatek/mtk-cmdq-helper.c
index bf32e3b2ca6c..817a5a97dbe5 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -18,6 +18,10 @@ struct cmdq_instruction {
union {
u32 value;
u32 mask;
+   struct {
+   u16 arg_c;
+   u16 src_reg;
+   };
};
union {
u16 offset;
@@ -222,6 +226,21 @@ int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u8 subsys,
 }
 EXPORT_SYMBOL(cmdq_pkt_write_mask);
 
+int cmdq_pkt_write_s(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
+u16 addr_low, u16 src_reg_idx)
+{
+   struct cmdq_instruction inst = {};
+
+   inst.op = CMDQ_CODE_WRITE_S;
+   inst.src_t = CMDQ_REG_TYPE;
+   inst.sop = high_addr_reg_idx;
+   inst.offset = addr_low;
+   inst.src_reg = src_reg_idx;
+
+   return cmdq_pkt_append_command(pkt, inst);
+}
+EXPORT_SYMBOL(cmdq_pkt_write_s);
+
 int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
 {
struct cmdq_instruction inst = { {0} };
diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h 
b/include/linux/mailbox/mtk-cmdq-mailbox.h
index 121c3bb6d3de..ee67dd3b86f5 100644
--- a/include/linux/mailbox/mtk-cmdq-mailbox.h
+++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
@@ -59,6 +59,7 @@ enum cmdq_code {
CMDQ_CODE_JUMP = 0x10,
CMDQ_CODE_WFE = 0x20,
CMDQ_CODE_EOC = 0x40,
+   CMDQ_CODE_WRITE_S = 0x90,
CMDQ_CODE_LOGIC = 0xa0,
 };
 
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h 
b/include/linux/soc/mediatek/mtk-cmdq.h
index 83340211e1d3..e1c5a7549b4f 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -12,6 +12,8 @@
 #include 
 
 #define CMDQ_NO_TIMEOUT0xu
+#define CMDQ_ADDR_HIGH(addr)   ((u32)(((addr) >> 16) & GENMASK(31, 0)))
+#define CMDQ_ADDR_LOW(addr)((u16)(addr) | BIT(1))
 
 struct cmdq_pkt;
 
@@ -103,6 +105,23 @@ int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u8 subsys,
u16 offset, u32 value, u32 mask);
 
 /**
+ * cmdq_pkt_write_s() - append write_s command to the CMDQ packet
+ * @pkt:   the CMDQ packet
+ * @high_addr_reg_idx: internal register ID which contains high address of pa
+ * @addr_low:  low address of pa
+ * @src_reg_idx:   the CMDQ internal register ID which cache source value
+ *
+ * Return: 0 for success; else the error code is returned
+ *
+ * Support write value to physical address without subsys. Use CMDQ_ADDR_HIGH()
+ * to get high address and call cmdq_pkt_assign() to assign value into internal
+ * reg. Also use CMDQ_ADDR_LOW() to get low address for addr_low parameter when
+ * call to this function.
+ */
+int cmdq_pkt_write_s(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
+u16 addr_low, u16 src_reg_idx);
+
+/**
  * cmdq_pkt_wfe() - append wait for event command to the CMDQ packet
  * @pkt:   the CMDQ packet
  * @event: the desired event type to "wait and CLEAR"
-- 
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/mediatek: check plane visibility in atomic_update

[Hsin-Yi Wang]

Disable the plane if it's not visible. Otherwise mtk_ovl_layer_config()
would proceed with invalid plane and we may see vblank timeout.

Signed-off-by: Hsin-Yi Wang 
---
 drivers/gpu/drm/mediatek/mtk_drm_plane.c | 23 +--
 1 file changed, 13 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c 
b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
index c2bd683a87c8..74dc71c7f3b6 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
@@ -164,6 +164,16 @@ static int mtk_plane_atomic_check(struct drm_plane *plane,
   true, true);
 }
 
+static void mtk_plane_atomic_disable(struct drm_plane *plane,
+struct drm_plane_state *old_state)
+{
+   struct mtk_plane_state *state = to_mtk_plane_state(plane->state);
+
+   state->pending.enable = false;
+   wmb(); /* Make sure the above parameter is set before update */
+   state->pending.dirty = true;
+}
+
 static void mtk_plane_atomic_update(struct drm_plane *plane,
struct drm_plane_state *old_state)
 {
@@ -178,6 +188,9 @@ static void mtk_plane_atomic_update(struct drm_plane *plane,
if (!crtc || WARN_ON(!fb))
return;
 
+   if (!plane->state->visible)
+   return mtk_plane_atomic_disable(plane, old_state);
+
gem = fb->obj[0];
mtk_gem = to_mtk_gem_obj(gem);
addr = mtk_gem->dma_addr;
@@ -200,16 +213,6 @@ static void mtk_plane_atomic_update(struct drm_plane 
*plane,
state->pending.dirty = true;
 }
 
-static void mtk_plane_atomic_disable(struct drm_plane *plane,
-struct drm_plane_state *old_state)
-{
-   struct mtk_plane_state *state = to_mtk_plane_state(plane->state);
-
-   state->pending.enable = false;
-   wmb(); /* Make sure the above parameter is set before update */
-   state->pending.dirty = true;
-}
-
 static const struct drm_plane_helper_funcs mtk_plane_helper_funcs = {
.prepare_fb = drm_gem_fb_prepare_fb,
.atomic_check = mtk_plane_atomic_check,
-- 
2.27.0.111.gc72c7da667-goog

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

Re: [PATCH v2] drm/amdkfd: Fix memory leaks according to error branches

[Markus Elfring]

>> I suggest to improve this change description.
>>
>> * Can an other wording variant be nicer?
>
> Markus's suggestion is as usual extremely imprecise.

I pointed a general possibility out. I did not propose an exact wording
alternative as it happened for other patches.


> However, I also find the message quite unclear.

I find this response interesting.


> It would be good to always use English words.

I am curious how this review will evolve further with such information
also after the third patch version.
https://lore.kernel.org/lkml/20200620091152.11206-1-bern...@vivo.com/
https://lore.kernel.org/patchwork/patch/1260303/

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

Re: [PATCH v7 31/36] staging: tegra-vde: fix common struct sg_table related issues

[Dmitry Osipenko]

В Fri, 19 Jun 2020 12:36:31 +0200
Marek Szyprowski  пишет:

> The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg()
> function returns the number of the created entries in the DMA address
> space. However the subsequent calls to the
> dma_sync_sg_for_{device,cpu}() and dma_unmap_sg must be called with
> the original number of the entries passed to the dma_map_sg().
> 
> struct sg_table is a common structure used for describing a
> non-contiguous memory buffer, used commonly in the DRM and graphics
> subsystems. It consists of a scatterlist with memory pages and DMA
> addresses (sgl entry), as well as the number of scatterlist entries:
> CPU pages (orig_nents entry) and DMA mapped pages (nents entry).
> 
> It turned out that it was a common mistake to misuse nents and
> orig_nents entries, calling DMA-mapping functions with a wrong number
> of entries or ignoring the number of mapped entries returned by the
> dma_map_sg() function.
> 
> To avoid such issues, lets use a common dma-mapping wrappers operating
> directly on the struct sg_table objects and use scatterlist page
> iterators where possible. This, almost always, hides references to the
> nents and orig_nents entries, making the code robust, easier to follow
> and copy/paste safe.
> 
> Signed-off-by: Marek Szyprowski 
> Reviewed-by: Dmitry Osipenko 
> ---
>  drivers/staging/media/tegra-vde/iommu.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/media/tegra-vde/iommu.c
> b/drivers/staging/media/tegra-vde/iommu.c index
> 6af863d92123..adf8dc7ee25c 100644 ---
> a/drivers/staging/media/tegra-vde/iommu.c +++
> b/drivers/staging/media/tegra-vde/iommu.c @@ -36,8 +36,8 @@ int
> tegra_vde_iommu_map(struct tegra_vde *vde, 
>   addr = iova_dma_addr(&vde->iova, iova);
>  
> - size = iommu_map_sg(vde->domain, addr, sgt->sgl, sgt->nents,
> - IOMMU_READ | IOMMU_WRITE);
> + size = iommu_map_sgtable(vde->domain, addr, sgt,
> +  IOMMU_READ | IOMMU_WRITE);
>   if (!size) {
>   __free_iova(&vde->iova, iova);
>   return -ENXIO;

Ahh, I saw the build failure report. You're changing the DMA API in
this series, while DMA API isn't used by this driver, it uses IOMMU
API. Hence there is no need to touch this code. Similar problem in the
host1x driver patch.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3] drm/amd: Fix memory leak according to error branch

[Julia Lawall]

On Sat, 20 Jun 2020, Markus Elfring wrote:

> > The function kobject_init_and_add alloc memory like:
> > kobject_init_and_add->kobject_add_varg->kobject_set_name_vargs
> > ->kvasprintf_const->kstrdup_const->kstrdup->kmalloc_track_caller
> > ->kmalloc_slab, in err branch this memory not free. If use
> > kmemleak, this path maybe catched.
> > These changes are to add kobject_put in kobject_init_and_add
> > failed branch, fix potential memleak.
> …
> > Changes since V2:
> > *remove duplicate kobject_put in kfd_procfs_init.
>
> Under which circumstances are going to improve this change description 
> accordingly?

Bernard, please update the log message as well.  The mail you sent was
much more clear, but mail just gets lost over time.  The log message
itself should be improved.

julia

>
> Would you like to add the tag “Fixes” to the commit message?
>
> Regards,
> Markus
>___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v1 10/11] soc: mediatek: cmdq: add clear option in cmdq_pkt_wfe api

[Dennis YC Hsieh]

Add clear parameter to let client decide if
event should be clear to 0 after GCE receive it.

Signed-off-by: Dennis YC Hsieh 
Reviewed-by: CK Hu 
---
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c  |2 +-
 drivers/soc/mediatek/mtk-cmdq-helper.c   |5 +++--
 include/linux/mailbox/mtk-cmdq-mailbox.h |3 +--
 include/linux/soc/mediatek/mtk-cmdq.h|5 +++--
 4 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c 
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 7daaabc26eb1..a065b3a412cf 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -488,7 +488,7 @@ static void mtk_drm_crtc_hw_config(struct mtk_drm_crtc 
*mtk_crtc)
if (mtk_crtc->cmdq_client) {
cmdq_handle = cmdq_pkt_create(mtk_crtc->cmdq_client, PAGE_SIZE);
cmdq_pkt_clear_event(cmdq_handle, mtk_crtc->cmdq_event);
-   cmdq_pkt_wfe(cmdq_handle, mtk_crtc->cmdq_event);
+   cmdq_pkt_wfe(cmdq_handle, mtk_crtc->cmdq_event, false);
mtk_crtc_ddp_config(crtc, cmdq_handle);
cmdq_pkt_finalize(cmdq_handle);
cmdq_pkt_flush_async(cmdq_handle, ddp_cmdq_cb, cmdq_handle);
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c 
b/drivers/soc/mediatek/mtk-cmdq-helper.c
index 009f86ae72c6..13f78c9b5901 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -315,15 +315,16 @@ int cmdq_pkt_write_s_mask_value(struct cmdq_pkt *pkt, u8 
high_addr_reg_idx,
 }
 EXPORT_SYMBOL(cmdq_pkt_write_s_mask_value);
 
-int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
+int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event, bool clear)
 {
struct cmdq_instruction inst = { {0} };
+   u32 clear_option = clear ? CMDQ_WFE_UPDATE : 0;
 
if (event >= CMDQ_MAX_EVENT)
return -EINVAL;
 
inst.op = CMDQ_CODE_WFE;
-   inst.value = CMDQ_WFE_OPTION;
+   inst.value = CMDQ_WFE_OPTION | clear_option;
inst.event = event;
 
return cmdq_pkt_append_command(pkt, inst);
diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h 
b/include/linux/mailbox/mtk-cmdq-mailbox.h
index 3f6bc0dfd5da..42d2a30e6a70 100644
--- a/include/linux/mailbox/mtk-cmdq-mailbox.h
+++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
@@ -27,8 +27,7 @@
  * bit 16-27: update value
  * bit 31: 1 - update, 0 - no update
  */
-#define CMDQ_WFE_OPTION(CMDQ_WFE_UPDATE | 
CMDQ_WFE_WAIT | \
-   CMDQ_WFE_WAIT_VALUE)
+#define CMDQ_WFE_OPTION(CMDQ_WFE_WAIT | 
CMDQ_WFE_WAIT_VALUE)
 
 /** cmdq event maximum */
 #define CMDQ_MAX_EVENT 0x3ff
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h 
b/include/linux/soc/mediatek/mtk-cmdq.h
index 18364d81e8f7..4b5f5d154bad 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -182,11 +182,12 @@ int cmdq_pkt_write_s_mask_value(struct cmdq_pkt *pkt, u8 
high_addr_reg_idx,
 /**
  * cmdq_pkt_wfe() - append wait for event command to the CMDQ packet
  * @pkt:   the CMDQ packet
- * @event: the desired event type to "wait and CLEAR"
+ * @event: the desired event type to wait
+ * @clear: clear event or not after event arrive
  *
  * Return: 0 for success; else the error code is returned
  */
-int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event);
+int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event, bool clear);
 
 /**
  * cmdq_pkt_clear_event() - append clear event command to the CMDQ packet
-- 
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v1 2/2] drm/panel-simple: Add missing BUS descriptions for some panels

[Dmitry Osipenko]

This patch adds missing BUS fields to the display panel descriptions of
the panels which are found on NVIDIA Tegra devices:

  1. AUO B101AW03
  2. Chunghwa CLAA070WP03XG
  3. Chunghwa CLAA101WA01A
  4. Chunghwa CLAA101WB01
  5. Innolux N156BGE L21
  6. Samsung LTN101NT05

Suggested-by: Laurent Pinchart 
Signed-off-by: Dmitry Osipenko 
---
 drivers/gpu/drm/panel/panel-simple.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 87edd2bdf09a..986df9937650 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -698,6 +698,8 @@ static const struct panel_desc auo_b101aw03 = {
.width = 223,
.height = 125,
},
+   .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
+   .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE,
.connector_type = DRM_MODE_CONNECTOR_LVDS,
 };
 
@@ -1352,6 +1354,8 @@ static const struct panel_desc chunghwa_claa070wp03xg = {
.width = 94,
.height = 150,
},
+   .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
+   .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE,
.connector_type = DRM_MODE_CONNECTOR_LVDS,
 };
 
@@ -1375,6 +1379,8 @@ static const struct panel_desc chunghwa_claa101wa01a = {
.width = 220,
.height = 120,
},
+   .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
+   .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE,
.connector_type = DRM_MODE_CONNECTOR_LVDS,
 };
 
@@ -1398,6 +1404,8 @@ static const struct panel_desc chunghwa_claa101wb01 = {
.width = 223,
.height = 125,
},
+   .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
+   .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE,
.connector_type = DRM_MODE_CONNECTOR_LVDS,
 };
 
@@ -2071,6 +2079,8 @@ static const struct panel_desc innolux_n156bge_l21 = {
.width = 344,
.height = 193,
},
+   .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
+   .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE,
.connector_type = DRM_MODE_CONNECTOR_LVDS,
 };
 
@@ -3018,6 +3028,8 @@ static const struct panel_desc samsung_ltn101nt05 = {
.width = 223,
.height = 125,
},
+   .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
+   .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE,
.connector_type = DRM_MODE_CONNECTOR_LVDS,
 };
 
-- 
2.26.0

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

Re: [Linaro-mm-sig] [PATCH 04/18] dma-fence: prime lockdep annotations

[Jason Gunthorpe]

On Fri, Jun 19, 2020 at 03:48:49PM -0400, Felix Kuehling wrote:
> Am 2020-06-19 um 2:18 p.m. schrieb Jason Gunthorpe:
> > On Fri, Jun 19, 2020 at 02:09:35PM -0400, Jerome Glisse wrote:
> >> On Fri, Jun 19, 2020 at 02:23:08PM -0300, Jason Gunthorpe wrote:
> >>> On Fri, Jun 19, 2020 at 06:19:41PM +0200, Daniel Vetter wrote:
> >>>
>  The madness is only that device B's mmu notifier might need to wait
>  for fence_B so that the dma operation finishes. Which in turn has to
>  wait for device A to finish first.
> >>> So, it sound, fundamentally you've got this graph of operations across
> >>> an unknown set of drivers and the kernel cannot insert itself in
> >>> dma_fence hand offs to re-validate any of the buffers involved?
> >>> Buffers which by definition cannot be touched by the hardware yet.
> >>>
> >>> That really is a pretty horrible place to end up..
> >>>
> >>> Pinning really is right answer for this kind of work flow. I think
> >>> converting pinning to notifers should not be done unless notifier
> >>> invalidation is relatively bounded. 
> >>>
> >>> I know people like notifiers because they give a bit nicer performance
> >>> in some happy cases, but this cripples all the bad cases..
> >>>
> >>> If pinning doesn't work for some reason maybe we should address that?
> >> Note that the dma fence is only true for user ptr buffer which predate
> >> any HMM work and thus were using mmu notifier already. You need the
> >> mmu notifier there because of fork and other corner cases.
> > I wonder if we should try to fix the fork case more directly - RDMA
> > has this same problem and added MADV_DONTFORK a long time ago as a
> > hacky way to deal with it.
> >
> > Some crazy page pin that resolved COW in a way that always kept the
> > physical memory with the mm that initiated the pin?
> >
> > (isn't this broken for O_DIRECT as well anyhow?)
> >
> > How does mmu_notifiers help the fork case anyhow? Block fork from
> > progressing?
> 
> How much the mmu_notifier blocks fork progress depends, on quickly we
> can preempt GPU jobs accessing affected memory. If we don't have
> fine-grained preemption capability (graphics), the best we can do is
> wait for the GPU jobs to complete. We can also delay submission of new
> GPU jobs to the same memory until the MMU notifier is done. Future jobs
> would use the new page addresses.
> 
> With fine-grained preemption (ROCm compute), we can preempt GPU work on
> the affected adders space to minimize the delay seen by fork.
> 
> With recoverable device page faults, we can invalidate GPU page table
> entries, so device access to the affected pages stops immediately.
> 
> In all cases, the end result is, that the device page table gets updated
> with the address of the copied pages before the GPU accesses the COW
> memory again.Without the MMU notifier, we'd end up with the GPU
> corrupting memory of the other process.

The model here in fork has been wrong for a long time, and I do wonder
how O_DIRECT manages to not be broken too.. I guess the time windows
there are too small to get unlucky.

If you have a write pin on a page then it should not be COW'd into the
fork'd process but copied with the originating page remaining with the
original mm. 

I wonder if there is some easy way to achive that - if that is the
main reason to use notifiers then it would be a better solution.

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

[PATCH v1 1/2] drm/panel-simple: Correct EDT ET057090DHU connector type

[Dmitry Osipenko]

The EDT ET057090DHU panel has a DPI connector and not LVDS. This patch
corrects the panel's description.

Reported-by: Laurent Pinchart 
Fixes: 94f07917ebe8 ("drm/panel-simple: Add missing connector type for some 
panels")
Signed-off-by: Dmitry Osipenko 
---
 drivers/gpu/drm/panel/panel-simple.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index ea6973d5cf54..87edd2bdf09a 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1588,7 +1588,7 @@ static const struct panel_desc edt_et057090dhu = {
},
.bus_format = MEDIA_BUS_FMT_RGB666_1X18,
.bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE,
-   .connector_type = DRM_MODE_CONNECTOR_LVDS,
+   .connector_type = DRM_MODE_CONNECTOR_DPI,
 };
 
 static const struct drm_display_mode edt_etm0700g0dh6_mode = {
-- 
2.26.0

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

[PATCH] drm/lima: Expose job_hang_limit module parameter

[Andrey Lebedev]

From: Andrey Lebedev 

Some pp or gp jobs can be successfully repeated even after they time outs.
Introduce lima module parameter to specify number of times a job can hang
before being dropped.

Signed-off-by: Andrey Lebedev 
---

Now all types are correct (uint).

 drivers/gpu/drm/lima/lima_drv.c   | 4 
 drivers/gpu/drm/lima/lima_drv.h   | 1 +
 drivers/gpu/drm/lima/lima_sched.c | 5 +++--
 3 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/lima/lima_drv.c b/drivers/gpu/drm/lima/lima_drv.c
index a831565af813..ab460121fd52 100644
--- a/drivers/gpu/drm/lima/lima_drv.c
+++ b/drivers/gpu/drm/lima/lima_drv.c
@@ -19,6 +19,7 @@
 int lima_sched_timeout_ms;
 uint lima_heap_init_nr_pages = 8;
 uint lima_max_error_tasks;
+uint lima_job_hang_limit;
 
 MODULE_PARM_DESC(sched_timeout_ms, "task run timeout in ms");
 module_param_named(sched_timeout_ms, lima_sched_timeout_ms, int, 0444);
@@ -29,6 +30,9 @@ module_param_named(heap_init_nr_pages, 
lima_heap_init_nr_pages, uint, 0444);
 MODULE_PARM_DESC(max_error_tasks, "max number of error tasks to save");
 module_param_named(max_error_tasks, lima_max_error_tasks, uint, 0644);
 
+MODULE_PARM_DESC(job_hang_limit, "number of times to allow a job to hang 
before dropping it (default 0)");
+module_param_named(job_hang_limit, lima_job_hang_limit, uint, 0444);
+
 static int lima_ioctl_get_param(struct drm_device *dev, void *data, struct 
drm_file *file)
 {
struct drm_lima_get_param *args = data;
diff --git a/drivers/gpu/drm/lima/lima_drv.h b/drivers/gpu/drm/lima/lima_drv.h
index fdbd4077c768..c738d288547b 100644
--- a/drivers/gpu/drm/lima/lima_drv.h
+++ b/drivers/gpu/drm/lima/lima_drv.h
@@ -11,6 +11,7 @@
 extern int lima_sched_timeout_ms;
 extern uint lima_heap_init_nr_pages;
 extern uint lima_max_error_tasks;
+extern uint lima_job_hang_limit;
 
 struct lima_vm;
 struct lima_bo;
diff --git a/drivers/gpu/drm/lima/lima_sched.c 
b/drivers/gpu/drm/lima/lima_sched.c
index e6cefda00279..1602985dfa04 100644
--- a/drivers/gpu/drm/lima/lima_sched.c
+++ b/drivers/gpu/drm/lima/lima_sched.c
@@ -503,8 +503,9 @@ int lima_sched_pipe_init(struct lima_sched_pipe *pipe, 
const char *name)
 
INIT_WORK(&pipe->recover_work, lima_sched_recover_work);
 
-   return drm_sched_init(&pipe->base, &lima_sched_ops, 1, 0,
- msecs_to_jiffies(timeout), name);
+   return drm_sched_init(&pipe->base, &lima_sched_ops, 1,
+ lima_job_hang_limit, msecs_to_jiffies(timeout),
+ name);
 }
 
 void lima_sched_pipe_fini(struct lima_sched_pipe *pipe)
-- 
2.25.1

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

[PATCH] video: fbdev: savage: fix memory leak on error handling path in probe

[Evgeny Novikov]

savagefb_probe() calls savage_init_fb_info() that can successfully
allocate memory for info->pixmap.addr but then fail when
fb_alloc_cmap() fails. savagefb_probe() goes to label failed_init and
does not free allocated memory. It is not valid to go to label
failed_mmio since savage_init_fb_info() can fail during memory
allocation as well. So, the patch free allocated memory on the error
handling path in savage_init_fb_info() itself.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Evgeny Novikov 
---
 drivers/video/fbdev/savage/savagefb_driver.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/video/fbdev/savage/savagefb_driver.c 
b/drivers/video/fbdev/savage/savagefb_driver.c
index 3c8ae87f0ea7..3fd87aeb6c79 100644
--- a/drivers/video/fbdev/savage/savagefb_driver.c
+++ b/drivers/video/fbdev/savage/savagefb_driver.c
@@ -2157,6 +2157,8 @@ static int savage_init_fb_info(struct fb_info *info, 
struct pci_dev *dev,
info->flags |= FBINFO_HWACCEL_COPYAREA |
   FBINFO_HWACCEL_FILLRECT |
   FBINFO_HWACCEL_IMAGEBLIT;
+   else
+   kfree(info->pixmap.addr);
}
 #endif
return err;
-- 
2.16.4

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

[PATCH v1 02/11] soc: mediatek: cmdq: add assign function

[Dennis YC Hsieh]

Add assign function in cmdq helper which assign constant value into
internal register by index.

Signed-off-by: Dennis YC Hsieh 
---
 drivers/soc/mediatek/mtk-cmdq-helper.c   |   24 +++-
 include/linux/mailbox/mtk-cmdq-mailbox.h |1 +
 include/linux/soc/mediatek/mtk-cmdq.h|   14 ++
 3 files changed, 38 insertions(+), 1 deletion(-)

diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c 
b/drivers/soc/mediatek/mtk-cmdq-helper.c
index 98f23ba3ba47..bf32e3b2ca6c 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -12,6 +12,7 @@
 #define CMDQ_WRITE_ENABLE_MASK BIT(0)
 #define CMDQ_POLL_ENABLE_MASK  BIT(0)
 #define CMDQ_EOC_IRQ_ENBIT(0)
+#define CMDQ_REG_TYPE  1
 
 struct cmdq_instruction {
union {
@@ -21,8 +22,17 @@ struct cmdq_instruction {
union {
u16 offset;
u16 event;
+   u16 reg_dst;
+   };
+   union {
+   u8 subsys;
+   struct {
+   u8 sop:5;
+   u8 arg_c_t:1;
+   u8 src_t:1;
+   u8 dst_t:1;
+   };
};
-   u8 subsys;
u8 op;
 };
 
@@ -277,6 +287,18 @@ int cmdq_pkt_poll_mask(struct cmdq_pkt *pkt, u8 subsys,
 }
 EXPORT_SYMBOL(cmdq_pkt_poll_mask);
 
+int cmdq_pkt_assign(struct cmdq_pkt *pkt, u16 reg_idx, u32 value)
+{
+   struct cmdq_instruction inst = {};
+
+   inst.op = CMDQ_CODE_LOGIC;
+   inst.dst_t = CMDQ_REG_TYPE;
+   inst.reg_dst = reg_idx;
+   inst.value = value;
+   return cmdq_pkt_append_command(pkt, inst);
+}
+EXPORT_SYMBOL(cmdq_pkt_assign);
+
 static int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
 {
struct cmdq_instruction inst = { {0} };
diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h 
b/include/linux/mailbox/mtk-cmdq-mailbox.h
index dfe5b2eb85cc..121c3bb6d3de 100644
--- a/include/linux/mailbox/mtk-cmdq-mailbox.h
+++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
@@ -59,6 +59,7 @@ enum cmdq_code {
CMDQ_CODE_JUMP = 0x10,
CMDQ_CODE_WFE = 0x20,
CMDQ_CODE_EOC = 0x40,
+   CMDQ_CODE_LOGIC = 0xa0,
 };
 
 enum cmdq_cb_status {
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h 
b/include/linux/soc/mediatek/mtk-cmdq.h
index a74c1d5acdf3..83340211e1d3 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -152,6 +152,20 @@ int cmdq_pkt_poll(struct cmdq_pkt *pkt, u8 subsys,
  */
 int cmdq_pkt_poll_mask(struct cmdq_pkt *pkt, u8 subsys,
   u16 offset, u32 value, u32 mask);
+
+/**
+ * cmdq_pkt_assign() - Append logic assign command to the CMDQ packet, ask GCE
+ *to execute an instruction that set a constant value into
+ *internal register and use as value, mask or address in
+ *read/write instruction.
+ * @pkt:   the CMDQ packet
+ * @reg_idx:   the CMDQ internal register ID
+ * @value: the specified value
+ *
+ * Return: 0 for success; else the error code is returned
+ */
+int cmdq_pkt_assign(struct cmdq_pkt *pkt, u16 reg_idx, u32 value);
+
 /**
  * cmdq_pkt_flush_async() - trigger CMDQ to asynchronously execute the CMDQ
  *  packet and call back at the end of done packet
-- 
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 01/18] mm: Track mmu notifiers in fs_reclaim_acquire/release

[Qian Cai]

On Thu, Jun 04, 2020 at 10:12:07AM +0200, Daniel Vetter wrote:
> fs_reclaim_acquire/release nicely catch recursion issues when
> allocating GFP_KERNEL memory against shrinkers (which gpu drivers tend
> to use to keep the excessive caches in check). For mmu notifier
> recursions we do have lockdep annotations since 23b68395c7c7
> ("mm/mmu_notifiers: add a lockdep map for invalidate_range_start/end").
> 
> But these only fire if a path actually results in some pte
> invalidation - for most small allocations that's very rarely the case.
> The other trouble is that pte invalidation can happen any time when
> __GFP_RECLAIM is set. Which means only really GFP_ATOMIC is a safe
> choice, GFP_NOIO isn't good enough to avoid potential mmu notifier
> recursion.
> 
> I was pondering whether we should just do the general annotation, but
> there's always the risk for false positives. Plus I'm assuming that
> the core fs and io code is a lot better reviewed and tested than
> random mmu notifier code in drivers. Hence why I decide to only
> annotate for that specific case.
> 
> Furthermore even if we'd create a lockdep map for direct reclaim, we'd
> still need to explicit pull in the mmu notifier map - there's a lot
> more places that do pte invalidation than just direct reclaim, these
> two contexts arent the same.
> 
> Note that the mmu notifiers needing their own independent lockdep map
> is also the reason we can't hold them from fs_reclaim_acquire to
> fs_reclaim_release - it would nest with the acquistion in the pte
> invalidation code, causing a lockdep splat. And we can't remove the
> annotations from pte invalidation and all the other places since
> they're called from many other places than page reclaim. Hence we can
> only do the equivalent of might_lock, but on the raw lockdep map.
> 
> With this we can also remove the lockdep priming added in 66204f1d2d1b
> ("mm/mmu_notifiers: prime lockdep") since the new annotations are
> strictly more powerful.
> 
> Cc: Andrew Morton 
> Cc: Jason Gunthorpe 
> Cc: linux...@kvack.org
> Cc: linux-r...@vger.kernel.org
> Cc: Maarten Lankhorst 
> Cc: Christian König 
> Signed-off-by: Daniel Vetter 

Reverting this commit fixed the lockdep splat below while applying some
memory pressure,

[  190.455003][  T369] WARNING: possible circular locking dependency detected
[  190.487291][  T369] 5.8.0-rc1-next-20200621 #1 Not tainted
[  190.512363][  T369] --
[  190.543354][  T369] kswapd3/369 is trying to acquire lock:
[  190.568523][  T369] 889fcf694528 (&xfs_nondir_ilock_class){}-{3:3}, 
at: xfs_reclaim_inode+0xdf/0x860
spin_lock at include/linux/spinlock.h:353
(inlined by) xfs_iflags_test_and_set at fs/xfs/xfs_inode.h:166
(inlined by) xfs_iflock_nowait at fs/xfs/xfs_inode.h:249
(inlined by) xfs_reclaim_inode at fs/xfs/xfs_icache.c:1127
[  190.614359][  T369]
[  190.614359][  T369] but task is already holding lock:
[  190.647763][  T369] b50ced00 (fs_reclaim){+.+.}-{0:0}, at: 
__fs_reclaim_acquire+0x0/0x30
__fs_reclaim_acquire at mm/page_alloc.c:4200
[  190.687845][  T369]
[  190.687845][  T369] which lock already depends on the new lock.
[  190.687845][  T369]
[  190.734890][  T369]
[  190.734890][  T369] the existing dependency chain (in reverse order) is:
[  190.775991][  T369]
[  190.775991][  T369] -> #1 (fs_reclaim){+.+.}-{0:0}:
[  190.808150][  T369]fs_reclaim_acquire+0x77/0x80
[  190.832152][  T369]slab_pre_alloc_hook.constprop.52+0x20/0x120
slab_pre_alloc_hook at mm/slab.h:507
[  190.862173][  T369]kmem_cache_alloc+0x43/0x2a0
[  190.885602][  T369]kmem_zone_alloc+0x113/0x3ef
kmem_zone_alloc at fs/xfs/kmem.c:129
[  190.908702][  T369]xfs_inode_item_init+0x1d/0xa0
xfs_inode_item_init at fs/xfs/xfs_inode_item.c:639
[  190.934461][  T369]xfs_trans_ijoin+0x96/0x100
xfs_trans_ijoin at fs/xfs/libxfs/xfs_trans_inode.c:34
[  190.961530][  T369]xfs_setattr_nonsize+0x1a6/0xcd0
xfs_setattr_nonsize at fs/xfs/xfs_iops.c:716
[  190.987331][  T369]xfs_vn_setattr+0x133/0x160
xfs_vn_setattr at fs/xfs/xfs_iops.c:1081
[  191.010476][  T369]notify_change+0x6c5/0xba1
notify_change at fs/attr.c:336
[  191.033317][  T369]chmod_common+0x19b/0x390
[  191.055770][  T369]ksys_fchmod+0x28/0x60
[  191.077957][  T369]__x64_sys_fchmod+0x4e/0x70
[  191.102767][  T369]do_syscall_64+0x5f/0x310
[  191.125090][  T369]entry_SYSCALL_64_after_hwframe+0x44/0xa9
[  191.153749][  T369]
[  191.153749][  T369] -> #0 (&xfs_nondir_ilock_class){}-{3:3}:
[  191.191267][  T369]__lock_acquire+0x2efc/0x4da0
[  191.215974][  T369]lock_acquire+0x1ac/0xaf0
[  191.238953][  T369]down_write_nested+0x92/0x150
[  191.262955][  T369]xfs_reclaim_inode+0xdf/0x860
[  191.287149][  T369]xfs_reclaim_inodes_ag+0x505/0xb00
[  191.313291][  T369]xfs_reclaim_inodes_nr+0x93/0xd0
[  191.338357][  T369]super_ca

[PATCH v1 0/2] Improve descriptions of a few simple-panels

[Dmitry Osipenko]

Hello,

This is a follow up to [1], which was already applied to drm-misc and then
Laurent Pinchart spotted some problems. This series addresses those problems.

[1] 
https://patchwork.ozlabs.org/project/linux-tegra/patch/20200617222703.17080-8-dig...@gmail.com/

Dmitry Osipenko (2):
  drm/panel-simple: Correct EDT ET057090DHU connector type
  drm/panel-simple: Add missing BUS descriptions for some panels

 drivers/gpu/drm/panel/panel-simple.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

-- 
2.26.0

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

Re: [PATCH] mm: Track mmu notifiers in fs_reclaim_acquire/release

[Qian Cai]

On Sun, Jun 21, 2020 at 10:01:03PM +0200, Daniel Vetter wrote:
> On Sun, Jun 21, 2020 at 08:07:08PM +0200, Daniel Vetter wrote:
> > On Sun, Jun 21, 2020 at 7:42 PM Qian Cai  wrote:
> > >
> > > On Wed, Jun 10, 2020 at 09:41:01PM +0200, Daniel Vetter wrote:
> > > > fs_reclaim_acquire/release nicely catch recursion issues when
> > > > allocating GFP_KERNEL memory against shrinkers (which gpu drivers tend
> > > > to use to keep the excessive caches in check). For mmu notifier
> > > > recursions we do have lockdep annotations since 23b68395c7c7
> > > > ("mm/mmu_notifiers: add a lockdep map for invalidate_range_start/end").
> > > >
> > > > But these only fire if a path actually results in some pte
> > > > invalidation - for most small allocations that's very rarely the case.
> > > > The other trouble is that pte invalidation can happen any time when
> > > > __GFP_RECLAIM is set. Which means only really GFP_ATOMIC is a safe
> > > > choice, GFP_NOIO isn't good enough to avoid potential mmu notifier
> > > > recursion.
> > > >
> > > > I was pondering whether we should just do the general annotation, but
> > > > there's always the risk for false positives. Plus I'm assuming that
> > > > the core fs and io code is a lot better reviewed and tested than
> > > > random mmu notifier code in drivers. Hence why I decide to only
> > > > annotate for that specific case.
> > > >
> > > > Furthermore even if we'd create a lockdep map for direct reclaim, we'd
> > > > still need to explicit pull in the mmu notifier map - there's a lot
> > > > more places that do pte invalidation than just direct reclaim, these
> > > > two contexts arent the same.
> > > >
> > > > Note that the mmu notifiers needing their own independent lockdep map
> > > > is also the reason we can't hold them from fs_reclaim_acquire to
> > > > fs_reclaim_release - it would nest with the acquistion in the pte
> > > > invalidation code, causing a lockdep splat. And we can't remove the
> > > > annotations from pte invalidation and all the other places since
> > > > they're called from many other places than page reclaim. Hence we can
> > > > only do the equivalent of might_lock, but on the raw lockdep map.
> > > >
> > > > With this we can also remove the lockdep priming added in 66204f1d2d1b
> > > > ("mm/mmu_notifiers: prime lockdep") since the new annotations are
> > > > strictly more powerful.
> > > >
> > > > v2: Review from Thomas Hellstrom:
> > > > - unbotch the fs_reclaim context check, I accidentally inverted it,
> > > >   but it didn't blow up because I inverted it immediately
> > > > - fix compiling for !CONFIG_MMU_NOTIFIER
> > > >
> > > > Cc: Thomas Hellström (Intel) 
> > > > Cc: Andrew Morton 
> > > > Cc: Jason Gunthorpe 
> > > > Cc: linux...@kvack.org
> > > > Cc: linux-r...@vger.kernel.org
> > > > Cc: Maarten Lankhorst 
> > > > Cc: Christian König 
> > > > Signed-off-by: Daniel Vetter 
> > >
> > > Replying the right patch here...
> > >
> > > Reverting this commit [1] fixed the lockdep warning below while applying
> > > some memory pressure.
> > >
> > > [1] linux-next cbf7c9d86d75 ("mm: track mmu notifiers in 
> > > fs_reclaim_acquire/release")
> > 
> > Hm, then I'm confused because
> > - there's not mmut notifier lockdep map in the splat at a..
> > - the patch is supposed to not change anything for fs_reclaim (but the
> > interim version got that wrong)
> > - looking at the paths it's kmalloc vs kswapd, both places I totally
> > expect fs_reflaim to be used.
> > 
> > But you're claiming reverting this prevents the lockdep splat. If
> > that's right, then my reasoning above is broken somewhere. Someone
> > less blind than me having an idea?
> > 
> > Aside this is the first email I've typed, until I realized the first
> > report was against the broken patch and that looked like a much more
> > reasonable explanation (but didn't quite match up with the code
> > paths).
> 
> Below diff should undo the functional change in my patch. Can you pls test
> whether the lockdep splat is really gone with that? Might need a lot of
> testing and memory pressure to be sure, since all these reclaim paths
> aren't very deterministic.

Well, I am running even heavy memory pressure workloads on linux-next
like every day, and never saw this splat until today where your patch
first show up.

Since I am rather busy tracking another regression, here is the steps to
reproduce (super easy to reproduce on multiple machines here.):

# git clone https://github.com/cailca/linux-mm.git
# cd linux-mm; make
# ./random 0

The .config is in there as well if ever matters.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Linaro-mm-sig] [PATCH 04/18] dma-fence: prime lockdep annotations

[Jason Gunthorpe]

On Fri, Jun 19, 2020 at 09:22:09AM +0200, Daniel Vetter wrote:
> > As I've understood GPU that means you need to show that the commands
> > associated with the buffer have completed. This is all local stuff
> > within the driver, right? Why use fence (other than it already exists)
> 
> Because that's the end-of-dma thing. And it's cross-driver for the
> above reasons, e.g.
> - device A renders some stuff. Userspace gets dma_fence A out of that
> (well sync_file or one of the other uapi interfaces, but you get the
> idea)
> - userspace (across process or just different driver) issues more
> rendering for device B, which depends upon the rendering done on
> device A. So dma_fence A is an dependency and will block this dma
> operation. Userspace (and the kernel) gets dma_fence B out of this
> - because unfortunate reasons, the same rendering on device B also
> needs a userptr buffer, which means that dma_fence B is also the one
> that the mmu_range_notifier needs to wait on before it can tell core
> mm that it can go ahead and release those pages

I was afraid you'd say this - this is complete madness for other DMA
devices to borrow the notifier hook of the first device!

What if the first device is a page faulting device and doesn't call
dma_fence??

It you are going to treat things this way then the mmu notifier really
needs to be part of the some core DMA buf, and not randomly sprinkled
in drivers

But really this is what page pinning is supposed to be used for, the
MM behavior when it blocks on a pinned page is less invasive than if
it stalls inside a mmu notifier.

You can mix it, use mmu notififers to keep track if the buffer is
still live, but when you want to trigger DMA then pin the pages and
keep them pinned until DMA is done. The pin protects things (well,
fork is still a problem)

Do not need to wait on dma_fence in notifiers.

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

[PATCH v1 09/11] soc: mediatek: cmdq: add jump function

[Dennis YC Hsieh]

Add jump function so that client can jump to any address which
contains instruction.

Signed-off-by: Dennis YC Hsieh 
---
 drivers/soc/mediatek/mtk-cmdq-helper.c |   13 +
 include/linux/soc/mediatek/mtk-cmdq.h  |   11 +++
 2 files changed, 24 insertions(+)

diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c 
b/drivers/soc/mediatek/mtk-cmdq-helper.c
index 248945108a36..009f86ae72c6 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -13,6 +13,7 @@
 #define CMDQ_POLL_ENABLE_MASK  BIT(0)
 #define CMDQ_EOC_IRQ_ENBIT(0)
 #define CMDQ_REG_TYPE  1
+#define CMDQ_JUMP_RELATIVE 1
 
 struct cmdq_instruction {
union {
@@ -391,6 +392,18 @@ int cmdq_pkt_assign(struct cmdq_pkt *pkt, u16 reg_idx, u32 
value)
 }
 EXPORT_SYMBOL(cmdq_pkt_assign);
 
+int cmdq_pkt_jump(struct cmdq_pkt *pkt, dma_addr_t addr)
+{
+   struct cmdq_instruction inst = {};
+
+   inst.op = CMDQ_CODE_JUMP;
+   inst.offset = CMDQ_JUMP_RELATIVE;
+   inst.value = addr >>
+   cmdq_mbox_shift(((struct cmdq_client *)pkt->cl)->chan);
+   return cmdq_pkt_append_command(pkt, inst);
+}
+EXPORT_SYMBOL(cmdq_pkt_jump);
+
 int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
 {
struct cmdq_instruction inst = { {0} };
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h 
b/include/linux/soc/mediatek/mtk-cmdq.h
index eac1405e4872..18364d81e8f7 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -244,6 +244,17 @@ int cmdq_pkt_poll_mask(struct cmdq_pkt *pkt, u8 subsys,
 int cmdq_pkt_assign(struct cmdq_pkt *pkt, u16 reg_idx, u32 value);
 
 /**
+ * cmdq_pkt_jump() - Append jump command to the CMDQ packet, ask GCE
+ *  to execute an instruction that change current thread PC to
+ *  a physical address which should contains more instruction.
+ * @pkt:the CMDQ packet
+ * @addr:   physical address of target instruction buffer
+ *
+ * Return: 0 for success; else the error code is returned
+ */
+int cmdq_pkt_jump(struct cmdq_pkt *pkt, dma_addr_t addr);
+
+/**
  * cmdq_pkt_finalize() - Append EOC and jump command to pkt.
  * @pkt:   the CMDQ packet
  *
-- 
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3] drm/amd: fix potential memleak in err branch

[Bernard Zhao]

The function kobject_init_and_add alloc memory like:
kobject_init_and_add->kobject_add_varg->kobject_set_name_vargs
->kvasprintf_const->kstrdup_const->kstrdup->kmalloc_track_caller
->kmalloc_slab, in err branch this memory not free. If use
kmemleak, this path maybe catched.
These changes are to add kobject_put in kobject_init_and_add
failed branch, fix potential memleak.

Signed-off-by: Bernard Zhao 
---
Changes since V2:
*remove duplicate kobject_put in kfd_procfs_init.

Link for V1:
*https://lore.kernel.org/patchwork/patch/1258608/
---
 drivers/gpu/drm/amd/amdkfd/kfd_process.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
index d27221ddcdeb..0e0c42e9f6a3 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
@@ -428,6 +428,7 @@ struct kfd_process *kfd_create_process(struct file *filep)
   (int)process->lead_thread->pid);
if (ret) {
pr_warn("Creating procfs pid directory failed");
+   kobject_put(process->kobj);
goto out;
}
 
-- 
2.17.1

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

Re: [PATCH] drm/rockchip: vop: fix vop full rgb24 r/b color error

[Huang Jiachai]

Hi heiko,

在 2020/6/19 15:02, Heiko Stuebner 写道:

Hi Sandy,

Am Freitag, 19. Juni 2020, 04:12:51 CEST schrieb Sandy Huang:

RGB888 format msb is red component and the lsb is blue component,
at vop full platform this is swapped, and this is different from vop
lite and vop next, so add this patch to fix it.

just me struggling with color formats ... and wondering why this never
came up so far - with Version 3 being all major SoCs of the last years.

So I guess the reason that nobody noticed so far is, that most things
will use ARGB888 instead of RGB888?

yes, most gpu output format is ARGB888, so we didn't noticed it before.

One implementation nit below as well.


Signed-off-by: Sandy Huang 
---
  drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 8 
  1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index c80f7d9fd13f..1c17048ad737 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -132,6 +132,7 @@ struct vop_win {
  
  struct rockchip_rgb;

  struct vop {
+   uint32_t version;
struct drm_crtc crtc;
struct device *dev;
struct drm_device *drm_dev;
@@ -989,6 +990,12 @@ static void vop_plane_atomic_update(struct drm_plane 
*plane,
VOP_WIN_SET(vop, win, dsp_st, dsp_st);
  
  	rb_swap = has_rb_swapped(fb->format->format);

+   /*
+* VOP full need to do rb swap to show rgb888/bgr888 format color 
correctly
+*/

one-line-comment?
/* VOP-full needs rb_swap for correctly showing rgb888/bgr888 */


+   if ((fb->format->format == DRM_FORMAT_RGB888 || fb->format->format == 
DRM_FORMAT_BGR888) &&
+   VOP_MAJOR(vop->version) == 3)
+   rb_swap = !rb_swap;

can we move this into the existing has_rb_swapped() function?
Like doing
rb_swap = has_rb_swapped(vop, fb->format->format)
and adding your conditional to the end there?


OK, update at v2.

Thanks
Heiko



VOP_WIN_SET(vop, win, rb_swap, rb_swap);
  
  	/*

@@ -2091,6 +2098,7 @@ static int vop_bind(struct device *dev, struct device 
*master, void *data)
vop->dev = dev;
vop->data = vop_data;
vop->drm_dev = drm_dev;
+   vop->version = vop_data->version;
dev_set_drvdata(dev, vop);
  
  	vop_win_init(vop);









--
Best Regard

黄家钗
Sandy Huang
Addr: 福州市鼓楼区铜盘路软件大道89号福州软件园A区21号楼(350003)
  No. 21 Building, A District, No.89,software Boulevard Fuzhou,Fujian,PRC
Tel：+86 0591-87884919  8690
E-mail：h...@rock-chips.com



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

[PATCH] drm/amd: fix potential memleak in err branch

[Bernard Zhao]

The function kobject_init_and_add alloc memory like:
kobject_init_and_add->kobject_add_varg->kobject_set_name_vargs
->kvasprintf_const->kstrdup_const->kstrdup->kmalloc_track_caller
->kmalloc_slab, in err branch this memory not free. If use
kmemleak, this path maybe catched.
These changes are to add kobject_put in kobject_init_and_add
failed branch, fix potential memleak.

Signed-off-by: Bernard Zhao 
---
 drivers/gpu/drm/amd/amdkfd/kfd_process.c  |  2 ++
 drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 20 +++-
 2 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
index d27221ddcdeb..5ee4d6cfb16d 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
@@ -124,6 +124,7 @@ void kfd_procfs_init(void)
if (ret) {
pr_warn("Could not create procfs proc folder");
/* If we fail to create the procfs, clean up */
+   kobject_put(procfs.kobj);
kfd_procfs_shutdown();
}
 }
@@ -428,6 +429,7 @@ struct kfd_process *kfd_create_process(struct file *filep)
   (int)process->lead_thread->pid);
if (ret) {
pr_warn("Creating procfs pid directory failed");
+   kobject_put(process->kobj);
goto out;
}
 
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
index bb77f7af2b6d..dc3c4149f860 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
@@ -632,8 +632,10 @@ static int kfd_build_sysfs_node_entry(struct 
kfd_topology_device *dev,
 
ret = kobject_init_and_add(dev->kobj_node, &node_type,
sys_props.kobj_nodes, "%d", id);
-   if (ret < 0)
+   if (ret < 0) {
+   kobject_put(dev->kobj_node);
return ret;
+   }
 
dev->kobj_mem = kobject_create_and_add("mem_banks", dev->kobj_node);
if (!dev->kobj_mem)
@@ -680,8 +682,10 @@ static int kfd_build_sysfs_node_entry(struct 
kfd_topology_device *dev,
return -ENOMEM;
ret = kobject_init_and_add(mem->kobj, &mem_type,
dev->kobj_mem, "%d", i);
-   if (ret < 0)
+   if (ret < 0) {
+   kobject_put(mem->kobj);
return ret;
+   }
 
mem->attr.name = "properties";
mem->attr.mode = KFD_SYSFS_FILE_MODE;
@@ -699,8 +703,10 @@ static int kfd_build_sysfs_node_entry(struct 
kfd_topology_device *dev,
return -ENOMEM;
ret = kobject_init_and_add(cache->kobj, &cache_type,
dev->kobj_cache, "%d", i);
-   if (ret < 0)
+   if (ret < 0) {
+   kobject_put(cache->kobj);
return ret;
+   }
 
cache->attr.name = "properties";
cache->attr.mode = KFD_SYSFS_FILE_MODE;
@@ -718,8 +724,10 @@ static int kfd_build_sysfs_node_entry(struct 
kfd_topology_device *dev,
return -ENOMEM;
ret = kobject_init_and_add(iolink->kobj, &iolink_type,
dev->kobj_iolink, "%d", i);
-   if (ret < 0)
+   if (ret < 0) {
+   kobject_put(iolink->kobj);
return ret;
+   }
 
iolink->attr.name = "properties";
iolink->attr.mode = KFD_SYSFS_FILE_MODE;
@@ -798,8 +806,10 @@ static int kfd_topology_update_sysfs(void)
ret = kobject_init_and_add(sys_props.kobj_topology,
&sysprops_type,  &kfd_device->kobj,
"topology");
-   if (ret < 0)
+   if (ret < 0) {
+   kobject_put(sys_props.kobj_topology);
return ret;
+   }
 
sys_props.kobj_nodes = kobject_create_and_add("nodes",
sys_props.kobj_topology);
-- 
2.17.1

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

[PATCH v2] drm/rockchip: vop: fix vop full rgb24 r/b color error

[Sandy Huang]

RGB888 format msb is red component and the lsb is blue component,
at vop full platform this is swapped, and this is different from vop
lite and vop next, so add this patch to fix it.

v2:
move to has_rb_swapped() function.

Signed-off-by: Sandy Huang 
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 21 +
 1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index c80f7d9fd13f..99bdb5a2a185 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -132,6 +132,7 @@ struct vop_win {
 
 struct rockchip_rgb;
 struct vop {
+   uint32_t version;
struct drm_crtc crtc;
struct device *dev;
struct drm_device *drm_dev;
@@ -248,17 +249,28 @@ static inline void vop_cfg_done(struct vop *vop)
VOP_REG_SET(vop, common, cfg_done, 1);
 }
 
-static bool has_rb_swapped(uint32_t format)
+static bool has_rb_swapped(struct vop *vop, uint32_t format)
 {
+   bool rb_swapped;
+
switch (format) {
case DRM_FORMAT_XBGR:
case DRM_FORMAT_ABGR:
case DRM_FORMAT_BGR888:
case DRM_FORMAT_BGR565:
-   return true;
+   rb_swapped = true;
default:
-   return false;
+   rb_swapped = false;
}
+
+   /*
+* VOP full need to do rb swap to show rgb888/bgr888 format color 
correctly
+*/
+   if ((format == DRM_FORMAT_RGB888 || format == DRM_FORMAT_BGR888) &&
+   VOP_MAJOR(vop->version) == 3)
+   rb_swapped = !rb_swapped;
+
+   return rb_swapped;
 }
 
 static enum vop_data_format vop_convert_format(uint32_t format)
@@ -988,7 +1000,7 @@ static void vop_plane_atomic_update(struct drm_plane 
*plane,
VOP_WIN_SET(vop, win, dsp_info, dsp_info);
VOP_WIN_SET(vop, win, dsp_st, dsp_st);
 
-   rb_swap = has_rb_swapped(fb->format->format);
+   rb_swap = has_rb_swapped(vop, fb->format->format);
VOP_WIN_SET(vop, win, rb_swap, rb_swap);
 
/*
@@ -2091,6 +2103,7 @@ static int vop_bind(struct device *dev, struct device 
*master, void *data)
vop->dev = dev;
vop->data = vop_data;
vop->drm_dev = drm_dev;
+   vop->version = vop_data->version;
dev_set_drvdata(dev, vop);
 
vop_win_init(vop);
-- 
2.17.1



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

Re:Re: [PATCH v2] drm/amdkfd: Fix memory leaks according to error branches

[Bernard]

From: Julia Lawall 
Date: 2020-06-20 17:37:19
To:  Markus Elfring 
Cc:  Bernard Zhao 
,opensource.ker...@vivo.com,amd-...@lists.freedesktop.org,dri-devel@lists.freedesktop.org,kernel-janit...@vger.kernel.org,linux-ker...@vger.kernel.org,Alex
 Deucher ,"Christian König" 
,"Felix Kühling" ,Daniel 
Vetter ,David Airlie 
Subject: Re: [PATCH v2] drm/amdkfd: Fix memory leaks according to error 
branches>
>
>On Sat, 20 Jun 2020, Markus Elfring wrote:
>
>> > The function kobject_init_and_add alloc memory like:
>> > kobject_init_and_add->kobject_add_varg->kobject_set_name_vargs
>> > ->kvasprintf_const->kstrdup_const->kstrdup->kmalloc_track_caller
>> > ->kmalloc_slab, in err branch this memory not free. If use
>> > kmemleak, this path maybe catched.
>> > These changes are to add kobject_put in kobject_init_and_add
>> > failed branch, fix potential memleak.
>>
>> I suggest to improve this change description.
>>
>> * Can an other wording variant be nicer?
>
>Markus's suggestion is as usual extremely imprecise.  However, I also find
>the message quite unclear.
>
>It would be good to always use English words.  alloc and err are not
>English words.  Perhaps most people will figure out what they are
>abbreviations for, but it would be better to use a few more letters to
>make it so that no one has to guess.
>
>Then there are a bunch of things that are connected by arrows with no
>spaces between them.  The most obvious meaning of an arrow with no space
>around it is a variable dereference.  After spending some mental effort,
>one can realize that that is not what you mean here.  A layout like:
>
>   first_function ->
> second_function ->
>   third_function
>
>would be much more readable.
>
>I don't know what "this patch maybe catched" means.  Is "catched" supposed
>to be "caught" or "cached"?  Overall, the sentence could be "Kmemleak
>could possibly detect this issue", or something like that.  But I don't
>know what this means.  Did you detect the problem with kmemleak?  if you
>did not detect the problem with kmemleak, and overall you don't know
>whether kmemleak would detect the bug or not, is this information useful
>at all for the patch?

Hi:

Kmemleak detected a memory leak as below:
kobject_init_and_add->
kobject_add_varg->
kobject_set_name_vargs->
kvasprintf_const->
kstrdup_const->
kstrdup->
kmalloc_track_caller->
kmalloc_slab

If kobject_init_and_add is called, but kobject_put is not called in the error 
branch.
This will be detected by kmemleak.

BR//Bernard

>"These changes are to" makes a lot of words with no information.  While it
>is perhaps not necessary to slavishly follow the rule about using the
>imperative, if it is convenient to use the imperative, doing so eliminates
>such meaningless phrases.
>
>memleak is also not an English word.  Memory leak is only a few more
>characters, and doesn't require the reader to make the small extra effort
>to figure out what you mean.
>
>julia
>
>>
>> * Will the tag “Fixes” become helpful for the commit message?
>>
>> Regards,
>> Markus
>>


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

[PATCH v1 01/11] soc: mediatek: cmdq: add address shift in jump

[Dennis YC Hsieh]

Add address shift when compose jump instruction
to compatible with 35bit format.

Signed-off-by: Dennis YC Hsieh 
---
 drivers/soc/mediatek/mtk-cmdq-helper.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c 
b/drivers/soc/mediatek/mtk-cmdq-helper.c
index c67081759728..98f23ba3ba47 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -291,7 +291,8 @@ static int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
 
/* JUMP to end */
inst.op = CMDQ_CODE_JUMP;
-   inst.value = CMDQ_JUMP_PASS;
+   inst.value = CMDQ_JUMP_PASS >>
+   cmdq_mbox_shift(((struct cmdq_client *)pkt->cl)->chan);
err = cmdq_pkt_append_command(pkt, inst);
 
return err;
-- 
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v1 04/11] soc: mediatek: cmdq: add write_s_mask function

[Dennis YC Hsieh]

add write_s_mask function in cmdq helper functions which
writes value contains in internal register to address
with mask and large dma access support.

Signed-off-by: Dennis YC Hsieh 
---
 drivers/soc/mediatek/mtk-cmdq-helper.c   |   23 +++
 include/linux/mailbox/mtk-cmdq-mailbox.h |1 +
 include/linux/soc/mediatek/mtk-cmdq.h|   18 ++
 3 files changed, 42 insertions(+)

diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c 
b/drivers/soc/mediatek/mtk-cmdq-helper.c
index 817a5a97dbe5..13b888779093 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -241,6 +241,29 @@ int cmdq_pkt_write_s(struct cmdq_pkt *pkt, u16 
high_addr_reg_idx,
 }
 EXPORT_SYMBOL(cmdq_pkt_write_s);
 
+int cmdq_pkt_write_s_mask(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
+ u16 addr_low, u16 src_reg_idx, u32 mask)
+{
+   struct cmdq_instruction inst = {};
+   int err;
+
+   inst.op = CMDQ_CODE_MASK;
+   inst.mask = ~mask;
+   err = cmdq_pkt_append_command(pkt, inst);
+   if (err < 0)
+   return err;
+
+   inst.mask = 0;
+   inst.op = CMDQ_CODE_WRITE_S_MASK;
+   inst.src_t = CMDQ_REG_TYPE;
+   inst.sop = high_addr_reg_idx;
+   inst.offset = addr_low;
+   inst.src_reg = src_reg_idx;
+
+   return cmdq_pkt_append_command(pkt, inst);
+}
+EXPORT_SYMBOL(cmdq_pkt_write_s_mask);
+
 int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
 {
struct cmdq_instruction inst = { {0} };
diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h 
b/include/linux/mailbox/mtk-cmdq-mailbox.h
index ee67dd3b86f5..8ef87e1bd03b 100644
--- a/include/linux/mailbox/mtk-cmdq-mailbox.h
+++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
@@ -60,6 +60,7 @@ enum cmdq_code {
CMDQ_CODE_WFE = 0x20,
CMDQ_CODE_EOC = 0x40,
CMDQ_CODE_WRITE_S = 0x90,
+   CMDQ_CODE_WRITE_S_MASK = 0x91,
CMDQ_CODE_LOGIC = 0xa0,
 };
 
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h 
b/include/linux/soc/mediatek/mtk-cmdq.h
index e1c5a7549b4f..ca9c75fd8125 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -122,6 +122,24 @@ int cmdq_pkt_write_s(struct cmdq_pkt *pkt, u16 
high_addr_reg_idx,
 u16 addr_low, u16 src_reg_idx);
 
 /**
+ * cmdq_pkt_write_s_mask() - append write_s with mask command to the CMDQ 
packet
+ * @pkt:   the CMDQ packet
+ * @high_addr_reg_idx: internal register ID which contains high address of pa
+ * @addr_low:  low address of pa
+ * @src_reg_idx:   the CMDQ internal register ID which cache source value
+ * @mask:  the specified target address mask, use U32_MAX if no need
+ *
+ * Return: 0 for success; else the error code is returned
+ *
+ * Support write value to physical address without subsys. Use CMDQ_ADDR_HIGH()
+ * to get high address and call cmdq_pkt_assign() to assign value into internal
+ * reg. Also use CMDQ_ADDR_LOW() to get low address for addr_low parameter when
+ * call to this function.
+ */
+int cmdq_pkt_write_s_mask(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
+ u16 addr_low, u16 src_reg_idx, u32 mask);
+
+/**
  * cmdq_pkt_wfe() - append wait for event command to the CMDQ packet
  * @pkt:   the CMDQ packet
  * @event: the desired event type to "wait and CLEAR"
-- 
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2] drm/amd: fix potential memleak in err branch

[Bernard Zhao]

The function kobject_init_and_add alloc memory like:
kobject_init_and_add->kobject_add_varg->kobject_set_name_vargs
->kvasprintf_const->kstrdup_const->kstrdup->kmalloc_track_caller
->kmalloc_slab, in err branch this memory not free. If use
kmemleak, this path maybe catched.
These changes are to add kobject_put in kobject_init_and_add
failed branch, fix potential memleak.

Signed-off-by: Bernard Zhao 
---
Changes since V1:
*Remove duplicate changed file kfd_topology.c, this file`s fix
already applied to the main line.
---
 drivers/gpu/drm/amd/amdkfd/kfd_process.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
index d27221ddcdeb..5ee4d6cfb16d 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
@@ -124,6 +124,7 @@ void kfd_procfs_init(void)
if (ret) {
pr_warn("Could not create procfs proc folder");
/* If we fail to create the procfs, clean up */
+   kobject_put(procfs.kobj);
kfd_procfs_shutdown();
}
 }
@@ -428,6 +429,7 @@ struct kfd_process *kfd_create_process(struct file *filep)
   (int)process->lead_thread->pid);
if (ret) {
pr_warn("Creating procfs pid directory failed");
+   kobject_put(process->kobj);
goto out;
}
 
-- 
2.17.1

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

Re:Re: [PATCH v2] drm/amdkfd: Fix memory leaks according to error branches

[Julia Lawall]

On Sat, 20 Jun 2020, Bernard wrote:

>
>
> From: Julia Lawall 
> Date: 2020-06-20 17:37:19
> To:  Markus Elfring 
> Cc:  Bernard Zhao 
> ,opensource.ker...@vivo.com,amd-...@lists.freedesktop.org,dri-devel@lists.freedesktop.org,kernel-janit...@vger.kernel.org,linux-ker...@vger.kernel.org,Alex
>  Deucher ,"Christian König" 
> ,"Felix Kühling" ,Daniel 
> Vetter ,David Airlie 
> Subject: Re: [PATCH v2] drm/amdkfd: Fix memory leaks according to error 
> branches>
> >
> >On Sat, 20 Jun 2020, Markus Elfring wrote:
> >
> >> > The function kobject_init_and_add alloc memory like:
> >> > kobject_init_and_add->kobject_add_varg->kobject_set_name_vargs
> >> > ->kvasprintf_const->kstrdup_const->kstrdup->kmalloc_track_caller
> >> > ->kmalloc_slab, in err branch this memory not free. If use
> >> > kmemleak, this path maybe catched.
> >> > These changes are to add kobject_put in kobject_init_and_add
> >> > failed branch, fix potential memleak.
> >>
> >> I suggest to improve this change description.
> >>
> >> * Can an other wording variant be nicer?
> >
> >Markus's suggestion is as usual extremely imprecise.  However, I also find
> >the message quite unclear.
> >
> >It would be good to always use English words.  alloc and err are not
> >English words.  Perhaps most people will figure out what they are
> >abbreviations for, but it would be better to use a few more letters to
> >make it so that no one has to guess.
> >
> >Then there are a bunch of things that are connected by arrows with no
> >spaces between them.  The most obvious meaning of an arrow with no space
> >around it is a variable dereference.  After spending some mental effort,
> >one can realize that that is not what you mean here.  A layout like:
> >
> >   first_function ->
> > second_function ->
> >   third_function
> >
> >would be much more readable.
> >
> >I don't know what "this patch maybe catched" means.  Is "catched" supposed
> >to be "caught" or "cached"?  Overall, the sentence could be "Kmemleak
> >could possibly detect this issue", or something like that.  But I don't
> >know what this means.  Did you detect the problem with kmemleak?  if you
> >did not detect the problem with kmemleak, and overall you don't know
> >whether kmemleak would detect the bug or not, is this information useful
> >at all for the patch?
>
> Hi:
>
> Kmemleak detected a memory leak as below:
> kobject_init_and_add->
>   kobject_add_varg->
>   kobject_set_name_vargs->
>   kvasprintf_const->
>   kstrdup_const->
>   kstrdup->
>   kmalloc_track_caller->
>   kmalloc_slab
>
> If kobject_init_and_add is called, but kobject_put is not called in the error 
> branch.
> This will be detected by kmemleak.

Thanks.  This is much more understandable.  The last part still seems a
bit hypothetical.  After the trace, which explain why you made the change,
just say what you did in the patch to fix the problem.

julia

>
> BR//Bernard
>
> >"These changes are to" makes a lot of words with no information.  While it
> >is perhaps not necessary to slavishly follow the rule about using the
> >imperative, if it is convenient to use the imperative, doing so eliminates
> >such meaningless phrases.
> >
> >memleak is also not an English word.  Memory leak is only a few more
> >characters, and doesn't require the reader to make the small extra effort
> >to figure out what you mean.
> >
> >julia
> >
> >>
> >> * Will the tag “Fixes” become helpful for the commit message?
> >>
> >> Regards,
> >> Markus
> >>
>
>
>___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm/amdkfd: Fix memory leaks according to error branches

[Julia Lawall]

On Sat, 20 Jun 2020, Markus Elfring wrote:

> > The function kobject_init_and_add alloc memory like:
> > kobject_init_and_add->kobject_add_varg->kobject_set_name_vargs
> > ->kvasprintf_const->kstrdup_const->kstrdup->kmalloc_track_caller
> > ->kmalloc_slab, in err branch this memory not free. If use
> > kmemleak, this path maybe catched.
> > These changes are to add kobject_put in kobject_init_and_add
> > failed branch, fix potential memleak.
>
> I suggest to improve this change description.
>
> * Can an other wording variant be nicer?

Markus's suggestion is as usual extremely imprecise.  However, I also find
the message quite unclear.

It would be good to always use English words.  alloc and err are not
English words.  Perhaps most people will figure out what they are
abbreviations for, but it would be better to use a few more letters to
make it so that no one has to guess.

Then there are a bunch of things that are connected by arrows with no
spaces between them.  The most obvious meaning of an arrow with no space
around it is a variable dereference.  After spending some mental effort,
one can realize that that is not what you mean here.  A layout like:

   first_function ->
 second_function ->
   third_function

would be much more readable.

I don't know what "this patch maybe catched" means.  Is "catched" supposed
to be "caught" or "cached"?  Overall, the sentence could be "Kmemleak
could possibly detect this issue", or something like that.  But I don't
know what this means.  Did you detect the problem with kmemleak?  if you
did not detect the problem with kmemleak, and overall you don't know
whether kmemleak would detect the bug or not, is this information useful
at all for the patch?

"These changes are to" makes a lot of words with no information.  While it
is perhaps not necessary to slavishly follow the rule about using the
imperative, if it is convenient to use the imperative, doing so eliminates
such meaningless phrases.

memleak is also not an English word.  Memory leak is only a few more
characters, and doesn't require the reader to make the small extra effort
to figure out what you mean.

julia

>
> * Will the tag “Fixes” become helpful for the commit message?
>
> Regards,
> Markus
>___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/msm/dpu: Fix usage of ERR_PTR()

[Zenghui Yu]

ping for this obvious fix...

On 2020/5/28 21:08, Zenghui Yu wrote:

ERR_PTR() is used in the kernel to encode an usual *negative* errno code
into a pointer.  Passing a positive value (ENOMEM) to it will break the
following IS_ERR() check.

Though memory allocation is unlikely to fail, it's still worth fixing.
And grepping shows that this is the only misuse of ERR_PTR() in kernel.

Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Signed-off-by: Zenghui Yu 
---
  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index a1b79ee2bd9d..a2f6b688a976 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -2173,7 +2173,7 @@ struct drm_encoder *dpu_encoder_init(struct drm_device 
*dev,
  
  	dpu_enc = devm_kzalloc(dev->dev, sizeof(*dpu_enc), GFP_KERNEL);

if (!dpu_enc)
-   return ERR_PTR(ENOMEM);
+   return ERR_PTR(-ENOMEM);
  
  	rc = drm_encoder_init(dev, &dpu_enc->base, &dpu_encoder_funcs,

drm_enc_mode, NULL);


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

[PATCH v1 06/11] soc: mediatek: cmdq: add write_s value function

[Dennis YC Hsieh]

add write_s function in cmdq helper functions which
writes a constant value to address with large dma
access support.

Signed-off-by: Dennis YC Hsieh 
---
 drivers/soc/mediatek/mtk-cmdq-helper.c |   14 ++
 include/linux/soc/mediatek/mtk-cmdq.h  |   13 +
 2 files changed, 27 insertions(+)

diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c 
b/drivers/soc/mediatek/mtk-cmdq-helper.c
index 58075589509b..2ad78df46636 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -279,6 +279,20 @@ int cmdq_pkt_write_s_mask(struct cmdq_pkt *pkt, u16 
high_addr_reg_idx,
 }
 EXPORT_SYMBOL(cmdq_pkt_write_s_mask);
 
+int cmdq_pkt_write_s_value(struct cmdq_pkt *pkt, u8 high_addr_reg_idx,
+  u16 addr_low, u32 value)
+{
+   struct cmdq_instruction inst = {};
+
+   inst.op = CMDQ_CODE_WRITE_S;
+   inst.sop = high_addr_reg_idx;
+   inst.offset = addr_low;
+   inst.value = value;
+
+   return cmdq_pkt_append_command(pkt, inst);
+}
+EXPORT_SYMBOL(cmdq_pkt_write_s_value);
+
 int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
 {
struct cmdq_instruction inst = { {0} };
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h 
b/include/linux/soc/mediatek/mtk-cmdq.h
index 40fe1eb52190..7f1c115a66b8 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -152,6 +152,19 @@ int cmdq_pkt_write_s_mask(struct cmdq_pkt *pkt, u16 
high_addr_reg_idx,
  u16 addr_low, u16 src_reg_idx, u32 mask);
 
 /**
+ * cmdq_pkt_write_s_value() - append write_s command to the CMDQ packet which
+ *   write value to a physical address
+ * @pkt:   the CMDQ packet
+ * @high_addr_reg_idx: internal register ID which contains high address of pa
+ * @addr_low:  low address of pa
+ * @value: the specified target value
+ *
+ * Return: 0 for success; else the error code is returned
+ */
+int cmdq_pkt_write_s_value(struct cmdq_pkt *pkt, u8 high_addr_reg_idx,
+  u16 addr_low, u32 value);
+
+/**
  * cmdq_pkt_wfe() - append wait for event command to the CMDQ packet
  * @pkt:   the CMDQ packet
  * @event: the desired event type to "wait and CLEAR"
-- 
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/amdkfd: Fix memory leaks according to error branches

[Markus Elfring]

> The function kobject_init_and_add alloc memory like:
> kobject_init_and_add->kobject_add_varg->kobject_set_name_vargs
> ->kvasprintf_const->kstrdup_const->kstrdup->kmalloc_track_caller
> ->kmalloc_slab, in err branch this memory not free. If use
> kmemleak, this path maybe catched.
> These changes are to add kobject_put in kobject_init_and_add
> failed branch, fix potential memleak.

I suggest to improve this change description.

* Can an other wording variant be nicer?

* Will the tag “Fixes” become helpful?

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

[PATCH v1 0/11] support cmdq helper function on mt6779 platform

[Dennis YC Hsieh]

This patch support cmdq helper function on mt6779 platform,
based on "support gce on mt6779 platform" patchset.


Dennis YC Hsieh (11):
  soc: mediatek: cmdq: add address shift in jump
  soc: mediatek: cmdq: add assign function
  soc: mediatek: cmdq: add write_s function
  soc: mediatek: cmdq: add write_s_mask function
  soc: mediatek: cmdq: add read_s function
  soc: mediatek: cmdq: add write_s value function
  soc: mediatek: cmdq: add write_s_mask value function
  soc: mediatek: cmdq: export finalize function
  soc: mediatek: cmdq: add jump function
  soc: mediatek: cmdq: add clear option in cmdq_pkt_wfe api
  soc: mediatek: cmdq: add set event function

 drivers/gpu/drm/mediatek/mtk_drm_crtc.c  |   3 +-
 drivers/soc/mediatek/mtk-cmdq-helper.c   | 159 +--
 include/linux/mailbox/mtk-cmdq-mailbox.h |   8 +-
 include/linux/soc/mediatek/mtk-cmdq.h| 124 +-
 4 files changed, 280 insertions(+), 14 deletions(-)

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

Re: [PATCH v8 7/7] drm/panel-simple: Add missing connector type for some panels

[Dmitry Osipenko]

20.06.2020 14:49, Laurent Pinchart пишет:
> Hi Sam and Dmitry,
> 
> On Sat, Jun 20, 2020 at 01:21:32PM +0200, Sam Ravnborg wrote:
>> On Thu, Jun 18, 2020 at 01:27:03AM +0300, Dmitry Osipenko wrote:
>>> The DRM panel bridge core requires connector type to be set up properly,
>>> otherwise it rejects the panel. The missing connector type problem popped
>>> up while I was trying to wrap CLAA070WP03XG panel into a DRM bridge in
>>> order to test whether panel's rotation property work properly using
>>> panel-simple driver on NVIDIA Tegra30 Nexus 7 tablet device, which uses
>>> CLAA070WP03XG display panel.
>>>
>>> The NVIDIA Tegra DRM driver recently gained DRM bridges support for the
>>> RGB output and now driver wraps directly-connected panels into DRM bridge.
>>> Hence all panels should have connector type set properly now, otherwise
>>> the panel's wrapping fails.
>>>
>>> This patch adds missing connector types for the LVDS panels that are found
>>> on NVIDIA Tegra devices:
>>>
>>>   1. AUO B101AW03
>>>   2. Chunghwa CLAA070WP03XG
>>>   3. Chunghwa CLAA101WA01A
>>>   4. Chunghwa CLAA101WB01
>>>   5. EDT ET057090DHU
>>>   6. Innolux N156BGE L21
>>>   7. Samsung LTN101NT05
>>>
>>> Signed-off-by: Dmitry Osipenko 
>>
>> Very good to have this fixed.
>> I went ahead and pushed this commit to drm-misc-next as it is really
>> independent from the rest of the series.
>>
>>> ---
>>>  drivers/gpu/drm/panel/panel-simple.c | 7 +++
>>>  1 file changed, 7 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/panel/panel-simple.c 
>>> b/drivers/gpu/drm/panel/panel-simple.c
>>> index 6764ac630e22..9eb2dbb7bfa6 100644
>>> --- a/drivers/gpu/drm/panel/panel-simple.c
>>> +++ b/drivers/gpu/drm/panel/panel-simple.c
>>> @@ -687,6 +687,7 @@ static const struct panel_desc auo_b101aw03 = {
>>> .width = 223,
>>> .height = 125,
>>> },
>>> +   .connector_type = DRM_MODE_CONNECTOR_LVDS,
> 
> Note that, for LVDS panels, the bus_format field is mandatory. This
> panel, for instance, according to
> http://www.vslcd.com/Specification/B101AW03%20V.0.pdf, uses
> MEDIA_BUS_FMT_RGB666_1X7X3_SPWG (see
> https://linuxtv.org/downloads/v4l-dvb-apis/userspace-api/v4l/subdev-formats.html#v4l2-mbus-pixelcode).
> The panels below need to be investigated similarly.

Okay! I'll add the missing field in v9.

>>>  };
>>>  
>>>  static const struct display_timing auo_b101ean01_timing = {
>>> @@ -1340,6 +1341,7 @@ static const struct panel_desc chunghwa_claa070wp03xg 
>>> = {
>>> .width = 94,
>>> .height = 150,
>>> },
>>> +   .connector_type = DRM_MODE_CONNECTOR_LVDS,
>>>  };
>>>  
>>>  static const struct drm_display_mode chunghwa_claa101wa01a_mode = {
>>> @@ -1362,6 +1364,7 @@ static const struct panel_desc chunghwa_claa101wa01a 
>>> = {
>>> .width = 220,
>>> .height = 120,
>>> },
>>> +   .connector_type = DRM_MODE_CONNECTOR_LVDS,
>>>  };
>>>  
>>>  static const struct drm_display_mode chunghwa_claa101wb01_mode = {
>>> @@ -1384,6 +1387,7 @@ static const struct panel_desc chunghwa_claa101wb01 = 
>>> {
>>> .width = 223,
>>> .height = 125,
>>> },
>>> +   .connector_type = DRM_MODE_CONNECTOR_LVDS,
>>>  };
>>>  
>>>  static const struct drm_display_mode dataimage_scf0700c48ggu18_mode = {
>>> @@ -1573,6 +1577,7 @@ static const struct panel_desc edt_et057090dhu = {
>>> },
>>> .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
>>> .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE,
>>> +   .connector_type = DRM_MODE_CONNECTOR_LVDS,
> 
> This contradicts .bus_format and .bus_flags that hint that the panel is
> a DPI panel, not an LVDS panel. According to
> https://www.lcdtek.co.uk/dwpdf/ET057090DHU-RoHS.pdf, this isn't an LVDS
> panel.
> 
> I'm worried enough research hasn't gone into this patch, and I'd prefer
> reverting it until we check each panel individually.

Hello Sam and Laurent,

Oops! Good catch! Indeed, I blindly set the LVDS type to all these
panels. Please revert this patch, I'll double check each panel and
prepare an updated version of this patch. Thank you very much for the
review!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v1 08/11] soc: mediatek: cmdq: export finalize function

[Dennis YC Hsieh]

Export finalize function to client which helps append eoc and jump
command to pkt. Let client decide call finalize or not.

Signed-off-by: Dennis YC Hsieh 
Reviewed-by: CK Hu 
Acked-by: Chun-Kuang Hu 
---
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c |1 +
 drivers/soc/mediatek/mtk-cmdq-helper.c  |7 ++-
 include/linux/soc/mediatek/mtk-cmdq.h   |8 
 3 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c 
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 0dfcd1787e65..7daaabc26eb1 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -490,6 +490,7 @@ static void mtk_drm_crtc_hw_config(struct mtk_drm_crtc 
*mtk_crtc)
cmdq_pkt_clear_event(cmdq_handle, mtk_crtc->cmdq_event);
cmdq_pkt_wfe(cmdq_handle, mtk_crtc->cmdq_event);
mtk_crtc_ddp_config(crtc, cmdq_handle);
+   cmdq_pkt_finalize(cmdq_handle);
cmdq_pkt_flush_async(cmdq_handle, ddp_cmdq_cb, cmdq_handle);
}
 #endif
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c 
b/drivers/soc/mediatek/mtk-cmdq-helper.c
index e372ae065240..248945108a36 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -391,7 +391,7 @@ int cmdq_pkt_assign(struct cmdq_pkt *pkt, u16 reg_idx, u32 
value)
 }
 EXPORT_SYMBOL(cmdq_pkt_assign);
 
-static int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
+int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
 {
struct cmdq_instruction inst = { {0} };
int err;
@@ -411,6 +411,7 @@ static int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
 
return err;
 }
+EXPORT_SYMBOL(cmdq_pkt_finalize);
 
 static void cmdq_pkt_flush_async_cb(struct cmdq_cb_data data)
 {
@@ -445,10 +446,6 @@ int cmdq_pkt_flush_async(struct cmdq_pkt *pkt, 
cmdq_async_flush_cb cb,
unsigned long flags = 0;
struct cmdq_client *client = (struct cmdq_client *)pkt->cl;
 
-   err = cmdq_pkt_finalize(pkt);
-   if (err < 0)
-   return err;
-
pkt->cb.cb = cb;
pkt->cb.data = data;
pkt->async_cb.cb = cmdq_pkt_flush_async_cb;
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h 
b/include/linux/soc/mediatek/mtk-cmdq.h
index 6e8caacedc80..eac1405e4872 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -244,6 +244,14 @@ int cmdq_pkt_poll_mask(struct cmdq_pkt *pkt, u8 subsys,
 int cmdq_pkt_assign(struct cmdq_pkt *pkt, u16 reg_idx, u32 value);
 
 /**
+ * cmdq_pkt_finalize() - Append EOC and jump command to pkt.
+ * @pkt:   the CMDQ packet
+ *
+ * Return: 0 for success; else the error code is returned
+ */
+int cmdq_pkt_finalize(struct cmdq_pkt *pkt);
+
+/**
  * cmdq_pkt_flush_async() - trigger CMDQ to asynchronously execute the CMDQ
  *  packet and call back at the end of done packet
  * @pkt:   the CMDQ packet
-- 
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 01/18] mm: Track mmu notifiers in fs_reclaim_acquire/release

[Qian Cai]

On Sun, Jun 21, 2020 at 07:28:40PM +0200, Daniel Vetter wrote:
> On Sun, Jun 21, 2020 at 7:01 PM Qian Cai  wrote:
> >
> > On Thu, Jun 04, 2020 at 10:12:07AM +0200, Daniel Vetter wrote:
> > > fs_reclaim_acquire/release nicely catch recursion issues when
> > > allocating GFP_KERNEL memory against shrinkers (which gpu drivers tend
> > > to use to keep the excessive caches in check). For mmu notifier
> > > recursions we do have lockdep annotations since 23b68395c7c7
> > > ("mm/mmu_notifiers: add a lockdep map for invalidate_range_start/end").
> > >
> > > But these only fire if a path actually results in some pte
> > > invalidation - for most small allocations that's very rarely the case.
> > > The other trouble is that pte invalidation can happen any time when
> > > __GFP_RECLAIM is set. Which means only really GFP_ATOMIC is a safe
> > > choice, GFP_NOIO isn't good enough to avoid potential mmu notifier
> > > recursion.
> > >
> > > I was pondering whether we should just do the general annotation, but
> > > there's always the risk for false positives. Plus I'm assuming that
> > > the core fs and io code is a lot better reviewed and tested than
> > > random mmu notifier code in drivers. Hence why I decide to only
> > > annotate for that specific case.
> > >
> > > Furthermore even if we'd create a lockdep map for direct reclaim, we'd
> > > still need to explicit pull in the mmu notifier map - there's a lot
> > > more places that do pte invalidation than just direct reclaim, these
> > > two contexts arent the same.
> > >
> > > Note that the mmu notifiers needing their own independent lockdep map
> > > is also the reason we can't hold them from fs_reclaim_acquire to
> > > fs_reclaim_release - it would nest with the acquistion in the pte
> > > invalidation code, causing a lockdep splat. And we can't remove the
> > > annotations from pte invalidation and all the other places since
> > > they're called from many other places than page reclaim. Hence we can
> > > only do the equivalent of might_lock, but on the raw lockdep map.
> > >
> > > With this we can also remove the lockdep priming added in 66204f1d2d1b
> > > ("mm/mmu_notifiers: prime lockdep") since the new annotations are
> > > strictly more powerful.
> > >
> > > Cc: Andrew Morton 
> > > Cc: Jason Gunthorpe 
> > > Cc: linux...@kvack.org
> > > Cc: linux-r...@vger.kernel.org
> > > Cc: Maarten Lankhorst 
> > > Cc: Christian König 
> > > Signed-off-by: Daniel Vetter 
> >
> > Reverting this commit fixed the lockdep splat below while applying some
> > memory pressure,
> 
> This is a broken version of the patch, please use the one Andrew
> merged into -mm.

Yes, since it is 5.8.0-rc1-next-20200621 which I believe it includes the
latest version from -mm. Anyway, I replied again to your latest patch,

https://lore.kernel.org/lkml/20200621174205.gb1...@lca.pw/

> 
> Thanks, Daniel
> 
> 
> >
> > [  190.455003][  T369] WARNING: possible circular locking dependency 
> > detected
> > [  190.487291][  T369] 5.8.0-rc1-next-20200621 #1 Not tainted
> > [  190.512363][  T369] 
> > --
> > [  190.543354][  T369] kswapd3/369 is trying to acquire lock:
> > [  190.568523][  T369] 889fcf694528 
> > (&xfs_nondir_ilock_class){}-{3:3}, at: xfs_reclaim_inode+0xdf/0x860
> > spin_lock at include/linux/spinlock.h:353
> > (inlined by) xfs_iflags_test_and_set at fs/xfs/xfs_inode.h:166
> > (inlined by) xfs_iflock_nowait at fs/xfs/xfs_inode.h:249
> > (inlined by) xfs_reclaim_inode at fs/xfs/xfs_icache.c:1127
> > [  190.614359][  T369]
> > [  190.614359][  T369] but task is already holding lock:
> > [  190.647763][  T369] b50ced00 (fs_reclaim){+.+.}-{0:0}, at: 
> > __fs_reclaim_acquire+0x0/0x30
> > __fs_reclaim_acquire at mm/page_alloc.c:4200
> > [  190.687845][  T369]
> > [  190.687845][  T369] which lock already depends on the new lock.
> > [  190.687845][  T369]
> > [  190.734890][  T369]
> > [  190.734890][  T369] the existing dependency chain (in reverse order) is:
> > [  190.775991][  T369]
> > [  190.775991][  T369] -> #1 (fs_reclaim){+.+.}-{0:0}:
> > [  190.808150][  T369]fs_reclaim_acquire+0x77/0x80
> > [  190.832152][  T369]slab_pre_alloc_hook.constprop.52+0x20/0x120
> > slab_pre_alloc_hook at mm/slab.h:507
> > [  190.862173][  T369]kmem_cache_alloc+0x43/0x2a0
> > [  190.885602][  T369]kmem_zone_alloc+0x113/0x3ef
> > kmem_zone_alloc at fs/xfs/kmem.c:129
> > [  190.908702][  T369]xfs_inode_item_init+0x1d/0xa0
> > xfs_inode_item_init at fs/xfs/xfs_inode_item.c:639
> > [  190.934461][  T369]xfs_trans_ijoin+0x96/0x100
> > xfs_trans_ijoin at fs/xfs/libxfs/xfs_trans_inode.c:34
> > [  190.961530][  T369]xfs_setattr_nonsize+0x1a6/0xcd0
> > xfs_setattr_nonsize at fs/xfs/xfs_iops.c:716
> > [  190.987331][  T369]xfs_vn_setattr+0x133/0x160
> > xfs_vn_setattr at fs/xfs/xfs_iops.c:1081
> > [  191.010476][  T369]notify_change+0x6c5/0xba1
> > notify_change at fs/att

Re: drivers/gpu/drm/panel/panel-samsung-ld9040.c:240:12: warning: stack frame size of 8312 bytes in function 'ld9040_prepare'

[Vladimir Oltean]

On Sat, 20 Jun 2020 at 21:22, kernel test robot  wrote:
>
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
> master
> head:   4333a9b0b67bb4e8bcd91bdd80da80b0ec151162
> commit: 79591b7db21d255db158afaa48c557dcab631a1c spi: Add a PTP system 
> timestamp to the transfer structure
> date:   9 months ago
> config: x86_64-randconfig-a014-20200620 (attached as .config)
> compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project 
> f5bbe390d23d7da0ffb110cdb24b583c2dc87eba)
> reproduce (this is a W=1 build):
> wget 
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # install x86_64 cross compiling tool for clang build
> # apt-get install binutils-x86-64-linux-gnu
> git checkout 79591b7db21d255db158afaa48c557dcab631a1c
> # save the attached .config to linux build tree
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot 
>
> All warnings (new ones prefixed by >>, old ones prefixed by <<):
>
> >> drivers/gpu/drm/panel/panel-samsung-ld9040.c:240:12: warning: stack frame 
> >> size of 8312 bytes in function 'ld9040_prepare' [-Wframe-larger-than=]
> static int ld9040_prepare(struct drm_panel *panel)
> ^
> 1 warning generated.
>
> vim +/ld9040_prepare +240 drivers/gpu/drm/panel/panel-samsung-ld9040.c
>
> ff219937763253 drivers/gpu/drm/panel/panel-ld9040.c Andrzej Hajda 2014-03-26  
> 239
> 099b3e8699322e drivers/gpu/drm/panel/panel-ld9040.c Ajay Kumar2014-07-31 
> @240  static int ld9040_prepare(struct drm_panel *panel)
> ff219937763253 drivers/gpu/drm/panel/panel-ld9040.c Andrzej Hajda 2014-03-26  
> 241  {
> ff219937763253 drivers/gpu/drm/panel/panel-ld9040.c Andrzej Hajda 2014-03-26  
> 242   struct ld9040 *ctx = panel_to_ld9040(panel);
> ff219937763253 drivers/gpu/drm/panel/panel-ld9040.c Andrzej Hajda 2014-03-26  
> 243   int ret;
> ff219937763253 drivers/gpu/drm/panel/panel-ld9040.c Andrzej Hajda 2014-03-26  
> 244
> ff219937763253 drivers/gpu/drm/panel/panel-ld9040.c Andrzej Hajda 2014-03-26  
> 245   ret = ld9040_power_on(ctx);
> ff219937763253 drivers/gpu/drm/panel/panel-ld9040.c Andrzej Hajda 2014-03-26  
> 246   if (ret < 0)
> ff219937763253 drivers/gpu/drm/panel/panel-ld9040.c Andrzej Hajda 2014-03-26  
> 247   return ret;
> ff219937763253 drivers/gpu/drm/panel/panel-ld9040.c Andrzej Hajda 2014-03-26  
> 248
> ff219937763253 drivers/gpu/drm/panel/panel-ld9040.c Andrzej Hajda 2014-03-26  
> 249   ld9040_init(ctx);
> ff219937763253 drivers/gpu/drm/panel/panel-ld9040.c Andrzej Hajda 2014-03-26  
> 250
> ff219937763253 drivers/gpu/drm/panel/panel-ld9040.c Andrzej Hajda 2014-03-26  
> 251   ret = ld9040_clear_error(ctx);
> ff219937763253 drivers/gpu/drm/panel/panel-ld9040.c Andrzej Hajda 2014-03-26  
> 252
> ff219937763253 drivers/gpu/drm/panel/panel-ld9040.c Andrzej Hajda 2014-03-26  
> 253   if (ret < 0)
> 8141028278c2ea drivers/gpu/drm/panel/panel-ld9040.c Ajay Kumar2014-07-31  
> 254   ld9040_unprepare(panel);
> ff219937763253 drivers/gpu/drm/panel/panel-ld9040.c Andrzej Hajda 2014-03-26  
> 255
> ff219937763253 drivers/gpu/drm/panel/panel-ld9040.c Andrzej Hajda 2014-03-26  
> 256   return ret;
> ff219937763253 drivers/gpu/drm/panel/panel-ld9040.c Andrzej Hajda 2014-03-26  
> 257  }
> ff219937763253 drivers/gpu/drm/panel/panel-ld9040.c Andrzej Hajda 2014-03-26  
> 258
>
> :: The code at line 240 was first introduced by commit
> :: 099b3e8699322efb7229913d2c1651588205f182 drm/panel: ld9040: Add dummy 
> prepare and unprepare routines
>
> :: TO: Ajay Kumar 
> :: CC: Thierry Reding 
>
> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org

I really don't get what's the problem here. The listing of
ld9040_prepare at the given commit and with the given .config is:

0630 :
{
 630:f3 0f 1e fa  endbr64
 634:e8 00 00 00 00   callq  639 
635: R_X86_64_PLT32__fentry__-0x4
 639:41 56push   %r14
ret = regulator_bulk_enable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
 63b:48 8d 77 30  lea0x30(%rdi),%rsi
{
 63f:41 55push   %r13
 641:41 54push   %r12
ret = regulator_bulk_enable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
 643:4c 8d 67 f8  lea-0x8(%rdi),%r12
{
 647:55   push   %rbp
 648:48 89 fd mov%rdi,%rbp
ret = regulator_bulk_enable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
 64b:bf 02 00 00 00   mov$0x2,%edi
 650:e8 00 00 00 00   callq  655 
651: R_X86_64_PLT32regulator_bulk_enable-0x4
 655:41 89 c5 mov%e

Re: [v2] drm/amdkfd: Fix memory leaks according to error branches

[Markus Elfring]

> memleak is also not an English word.  Memory leak is only a few more
> characters, and doesn't require the reader to make the small extra effort
> to figure out what you mean.

Would you like to achieve similar adjustments at any more places?

How do you think about effects from a corresponding jargon?
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/gpu/drm/msm/msm_submitqueue.c?id=177d3819633cd520e3f95df541a04644aab4c657

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

Re: [PATCH v8 7/7] drm/panel-simple: Add missing connector type for some panels

[Dmitry Osipenko]

20.06.2020 18:30, Sam Ravnborg пишет:
> Hi Dmitry
> On Sat, Jun 20, 2020 at 06:05:37PM +0300, Dmitry Osipenko wrote:
>> 20.06.2020 17:31, Sam Ravnborg пишет:
>>> Hi Dmitry
>>>

 Oops! Good catch!
>>> Yep, thanks Laurent. Should have taken a better look before applying.
>>>
 Indeed, I blindly set the LVDS type to all these
 panels. Please revert this patch, I'll double check each panel and
 prepare an updated version of this patch. Thank you very much for the
 review!
>>>
>>> If you can prepare a fix within a few days then lets wait for that.
>>> I will do a better review next time.
>>
>> Hello Sam,
>>
>> I should be able to make it later today or tomorrow. Could you please
>> clarify what do you mean by the fix, do you what it to be as an
>> additional patch on top of the applied one or a new version of the patch?
> An additional patch on top of the one applied.
> It shall carry a proper fixes: tag like this:
> 
> Fixes: 94f07917ebe8 ("drm/panel-simple: Add missing connector type for some 
> panels")
> Cc: Dmitry Osipenko 
> Cc: Sam Ravnborg 
> Cc: Thierry Reding 
> Cc: dri-devel@lists.freedesktop.org

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

[PATCH RESEND v1] drm/meson: viu: fix setting the OSD burst length in VIU_OSD1_FIFO_CTRL_STAT

[Martin Blumenstingl]

The burst length is configured in VIU_OSD1_FIFO_CTRL_STAT[31] and
VIU_OSD1_FIFO_CTRL_STAT[11:10]. The public S905D3 datasheet describes
this as:
- 0x0 = up to 24 per burst
- 0x1 = up to 32 per burst
- 0x2 = up to 48 per burst
- 0x3 = up to 64 per burst
- 0x4 = up to 96 per burst
- 0x5 = up to 128 per burst

The lower two bits map to VIU_OSD1_FIFO_CTRL_STAT[11:10] while the upper
bit maps to VIU_OSD1_FIFO_CTRL_STAT[31].

Replace meson_viu_osd_burst_length_reg() with pre-defined macros which
set these values. meson_viu_osd_burst_length_reg() always returned 0
(for the two used values: 32 and 64 at least) and thus incorrectly set
the burst size to 24.

Fixes: 147ae1cbaa1842 ("drm: meson: viu: use proper macros instead of magic 
constants")
Signed-off-by: Martin Blumenstingl 
---
re-send of v1 [0] with no changes as I still noticed that this is
sitting in my tree and I wasn't asked to change anything in v1.


[0] https://patchwork.kernel.org/patch/11510045/


 drivers/gpu/drm/meson/meson_registers.h |  6 ++
 drivers/gpu/drm/meson/meson_viu.c   | 11 ++-
 2 files changed, 8 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/meson/meson_registers.h 
b/drivers/gpu/drm/meson/meson_registers.h
index 8ea00546cd4e..049c4bfe2a3a 100644
--- a/drivers/gpu/drm/meson/meson_registers.h
+++ b/drivers/gpu/drm/meson/meson_registers.h
@@ -261,6 +261,12 @@
 #define VIU_OSD_FIFO_DEPTH_VAL(val)  ((val & 0x7f) << 12)
 #define VIU_OSD_WORDS_PER_BURST(words)   (((words & 0x4) >> 1) << 22)
 #define VIU_OSD_FIFO_LIMITS(size)((size & 0xf) << 24)
+#define VIU_OSD_BURST_LENGTH_24  (0x0 << 31 | 0x0 << 10)
+#define VIU_OSD_BURST_LENGTH_32  (0x0 << 31 | 0x1 << 10)
+#define VIU_OSD_BURST_LENGTH_48  (0x0 << 31 | 0x2 << 10)
+#define VIU_OSD_BURST_LENGTH_64  (0x0 << 31 | 0x3 << 10)
+#define VIU_OSD_BURST_LENGTH_96  (0x1 << 31 | 0x0 << 10)
+#define VIU_OSD_BURST_LENGTH_128 (0x1 << 31 | 0x1 << 10)
 
 #define VD1_IF0_GEN_REG 0x1a50
 #define VD1_IF0_CANVAS0 0x1a51
diff --git a/drivers/gpu/drm/meson/meson_viu.c 
b/drivers/gpu/drm/meson/meson_viu.c
index 304f8ff1339c..aede0c67a57f 100644
--- a/drivers/gpu/drm/meson/meson_viu.c
+++ b/drivers/gpu/drm/meson/meson_viu.c
@@ -411,13 +411,6 @@ void meson_viu_gxm_disable_osd1_afbc(struct meson_drm 
*priv)
priv->io_base + _REG(VIU_MISC_CTRL1));
 }
 
-static inline uint32_t meson_viu_osd_burst_length_reg(uint32_t length)
-{
-   uint32_t val = (((length & 0x80) % 24) / 12);
-
-   return (((val & 0x3) << 10) | (((val & 0x4) >> 2) << 31));
-}
-
 void meson_viu_init(struct meson_drm *priv)
 {
uint32_t reg;
@@ -444,9 +437,9 @@ void meson_viu_init(struct meson_drm *priv)
VIU_OSD_FIFO_LIMITS(2);  /* fifo_lim: 2*16=32 */
 
if (meson_vpu_is_compatible(priv, VPU_COMPATIBLE_G12A))
-   reg |= meson_viu_osd_burst_length_reg(32);
+   reg |= VIU_OSD_BURST_LENGTH_32;
else
-   reg |= meson_viu_osd_burst_length_reg(64);
+   reg |= VIU_OSD_BURST_LENGTH_64;
 
writel_relaxed(reg, priv->io_base + _REG(VIU_OSD1_FIFO_CTRL_STAT));
writel_relaxed(reg, priv->io_base + _REG(VIU_OSD2_FIFO_CTRL_STAT));
-- 
2.27.0

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

[PATCH v4] display/drm/bridge: TC358775 DSI/LVDS driver

[Vinay Simha BN]

Signed-off-by: Vinay Simha BN 

---
v1:
 Initial version

v2:
* Andrzej Hajda review comments incorporated
  SPDX identifier
  development debug removed
  alphabetic order headers
  u32 instead of unit32_t
  magic numbers to macros for CLRSI and mux registers
  ignored return value

* Laurent Pinchart review comments incorporated
  mdelay to usleep_range
  bus_formats added

v3:
* Andrzej Hajda review comments incorporated
  drm_connector_status removed
  u32 rev removed and local variabl is used
  regulator enable disable with proper orders and delays
  as per the spec
  devm_drm_panel_bridge_add method used instead of panel
  description modified
  dual port implemented

v4:
* Sam Ravnborg review comments incorporated
  panel->connector_type removed

* Reported-by: kernel test robot 
  parse_dt to static function
  removed the if (endpoint), since data-lanes has to be
  present for dsi dts ports
---
 drivers/gpu/drm/bridge/Kconfig|  10 +
 drivers/gpu/drm/bridge/Makefile   |   1 +
 drivers/gpu/drm/bridge/tc358775.c | 721 ++
 3 files changed, 732 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/tc358775.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 43271c21d3fc..084e9853944a 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -181,6 +181,16 @@ config DRM_TOSHIBA_TC358768
help
  Toshiba TC358768AXBG/TC358778XBG DSI bridge chip driver.
 
+config DRM_TOSHIBA_TC358775
+tristate "Toshiba TC358775 LVDS bridge"
+depends on OF
+select DRM_KMS_HELPER
+select REGMAP_I2C
+select DRM_PANEL
+   select DRM_MIPI_DSI
+---help---
+  Toshiba TC358775 LVDS bridge chip driver.
+
 config DRM_TI_TFP410
tristate "TI TFP410 DVI/HDMI bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index d63d4b7e4347..23c770b3bfe4 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o
 obj-$(CONFIG_DRM_TOSHIBA_TC358764) += tc358764.o
 obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
 obj-$(CONFIG_DRM_TOSHIBA_TC358768) += tc358768.o
+obj-$(CONFIG_DRM_TOSHIBA_TC358775) += tc358775.o
 obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
 obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o
 obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
diff --git a/drivers/gpu/drm/bridge/tc358775.c 
b/drivers/gpu/drm/bridge/tc358775.c
new file mode 100644
index ..8c9bd4e77bfd
--- /dev/null
+++ b/drivers/gpu/drm/bridge/tc358775.c
@@ -0,0 +1,721 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * tc358775 DSI to LVDS bridge driver
+ *
+ * Copyright (C) 2020 SMART Wireless Computing
+ * Author: Vinay Simha BN 
+ *
+ */
+//#define DEBUG
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define FLD_MASK(start, end)(((1 << ((start) - (end) + 1)) - 1) << (end))
+#define FLD_VAL(val, start, end) (((val) << (end)) & FLD_MASK(start, end))
+
+/* Registers */
+
+/* DSI D-PHY Layer Registers */
+#define D0W_DPHYCONTTX  0x0004  /* Data Lane 0 DPHY Tx Control */
+#define CLW_DPHYCONTRX  0x0020  /* Clock Lane DPHY Rx Control */
+#define D0W_DPHYCONTRX  0x0024  /* Data Lane 0 DPHY Rx Control */
+#define D1W_DPHYCONTRX  0x0028  /* Data Lane 1 DPHY Rx Control */
+#define D2W_DPHYCONTRX  0x002C  /* Data Lane 2 DPHY Rx Control */
+#define D3W_DPHYCONTRX  0x0030  /* Data Lane 3 DPHY Rx Control */
+#define COM_DPHYCONTRX  0x0038  /* DPHY Rx Common Control */
+#define CLW_CNTRL   0x0040  /* Clock Lane Control */
+#define D0W_CNTRL   0x0044  /* Data Lane 0 Control */
+#define D1W_CNTRL   0x0048  /* Data Lane 1 Control */
+#define D2W_CNTRL   0x004C  /* Data Lane 2 Control */
+#define D3W_CNTRL   0x0050  /* Data Lane 3 Control */
+#define DFTMODE_CNTRL   0x0054  /* DFT Mode Control */
+
+/* DSI PPI Layer Registers */
+#define PPI_STARTPPI0x0104  /* START control bit of PPI-TX function. */
+#define PPI_START_FUNCTION  1
+
+#define PPI_BUSYPPI 0x0108
+#define PPI_LINEINITCNT 0x0110  /* Line Initialization Wait Counter  */
+#define PPI_LPTXTIMECNT 0x0114
+#define PPI_LANEENABLE  0x0134  /* Enables each lane at the PPI layer. */
+#define PPI_TX_RX_TA0x013C  /* DSI Bus Turn Around timing parameters */
+
+/* Analog timer function enable */
+#define PPI_CLS_ATMR0x0140  /* Delay for Clock Lane in LPRX  */
+#define PPI_D0S_ATMR0x0144  /* Delay for Data Lane 0 in LPRX */
+#define PPI_D1S_ATMR0x0148  /* Delay for Data Lane 1 in LPRX */
+#define PPI_D2S_ATMR0x014C  /* Delay for Data Lane 2 in LPRX */
+#define PPI_D3S_ATMR0x0150  /* Delay for Data Lane 3 in LPRX */
+
+#define PPI_D0S_CLRSIPOCOUNT0x0164  /* For lane 0 */
+#define PPI_D1S_CLRSIPOCOUNT0x0168  /* For lane 1

Re: [PATCH v3 3/3] drm/bridge: Introduce LT9611 DSI to HDMI bridge

[Vinod Koul]

Hello Sam,

On 20-06-20, 20:05, Sam Ravnborg wrote:
> Hi Vinod.
> 
> Looks good but some some of small nits.

Great :)

> And a few larger things in the following.
> The larger things is releated to prepare the bridge driver to live in a
> world with chained bridges.

Sure, so that entails adding the callbacks specified below right or is
there anything else required to do?

> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> Please add empty lines between each group of includes.
> They are already sorted within each group and in preferred order - good.

Okay if that is the preference, sure

> > +static int lt9611_mipi_input_analog(struct lt9611 *lt9611)
> > +{
> > +   const struct reg_sequence reg_cfg[] = {
> > +   { 0x8106, 0x40 }, /*port A rx current*/
> > +   { 0x810a, 0xfe }, /*port A ldo voltage set*/
> > +   { 0x810b, 0xbf }, /*enable port A lprx*/
> > +   { 0x8111, 0x40 }, /*port B rx current*/
> > +   { 0x8115, 0xfe }, /*port B ldo voltage set*/
> > +   { 0x8116, 0xbf }, /*enable port B lprx*/
> > +
> > +   { 0x811c, 0x03 }, /*PortA clk lane no-LP mode*/
> > +   { 0x8120, 0x03 }, /*PortB clk lane with-LP mode*/
> Add space after "/*" and before closing "*/".
> Like is done a few lines up in lt9611_modes[]

Oops seems to have missed these, will fix this and others if any

> > +static int lt9611_mipi_input_digital(struct lt9611 *lt9611,
> > +const struct drm_display_mode *mode)
> > +{
> > +   struct reg_sequence reg_cfg[] = {
> > +   { 0x8300, LT9611_4LANES },
> > +   { 0x830a, 0x00 },
> > +   { 0x824f, 0x80 },
> > +   { 0x8250, 0x10 },
> > +   { 0x8302, 0x0a },
> > +   { 0x8306, 0x0a },
> > +   };
> > +
> > +   if (mode->hdisplay == 3840)
> > +   reg_cfg[1].def = 0x03;
> Please check if some of these constants be replaced by something readable
> from the datasheet.
> Same goes for other places where constants are used.

The problem is that the datasheet I have doesn't define register names.
Worse some of them are not even documented. I did give it a shot to
define these, but gave up half way due to lack on inventive names :(

I would like to keep the registers and replace them in future if we get
a good spec from vendor.. or i can define REG_1...REG_N!

> > +static void lt9611_mipi_video_setup(struct lt9611 *lt9611,
> > +   const struct drm_display_mode *mode)
> > +{
> > +   u32 h_total, h_act, hpw, hfp, hss;
> > +   u32 v_total, v_act, vpw, vfp, vss;
> > +
> > +   h_total = mode->htotal;
> > +   v_total = mode->vtotal;
> > +
> > +   h_act = mode->hdisplay;
> > +   hpw = mode->hsync_end - mode->hsync_start;
> > +   hfp = mode->hsync_start - mode->hdisplay;
> > +   hss = (mode->hsync_end - mode->hsync_start) +
> > + (mode->htotal - mode->hsync_end);
> > +
> > +   v_act = mode->vdisplay;
> > +   vpw = mode->vsync_end - mode->vsync_start;
> > +   vfp = mode->vsync_start - mode->vdisplay;
> > +   vss = (mode->vsync_end - mode->vsync_start) +
> > + (mode->vtotal - mode->vsync_end);
> Using the names from display_timings would make this easier to recognize
> for the reader.
> Examples:
> vfp versus vfront_porch
> vss versus vsync_len
> 
> I do not say the names from display_timing are much better, only that they
> are more recognizeable.

okay will do

> > +static irqreturn_t lt9611_irq_thread_handler(int irq, void *dev_id)
> > +{
> > +   struct lt9611 *lt9611 = dev_id;
> > +   unsigned int irq_flag0 = 0;
> > +   unsigned int irq_flag3 = 0;
> > +
> > +   regmap_read(lt9611->regmap, 0x820f, &irq_flag3);
> > +   regmap_read(lt9611->regmap, 0x820c, &irq_flag0);
> > +
> > +   pr_debug("%s() irq_flag0: %#x irq_flag3: %#x\n",
> > +__func__, irq_flag0, irq_flag3);
> debug artifact you can delete now?

Okay, will remove this and rest

> 
> > +
> > +/* hpd changed low */
> Drop extra space in indent of this comment and following comments as
> well.

Ok

> > +static int lt9611_bridge_attach(struct drm_bridge *bridge,
> > +   enum drm_bridge_attach_flags flags)
> > +{
> > +   struct lt9611 *lt9611 = bridge_to_lt9611(bridge);
> > +   int ret;
> > +
> > +   dev_dbg(lt9611->dev, "bridge attach\n");
> > +
> > +   if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) {
> > +   DRM_ERROR("Fix bridge driver to make connector optional!");
> > +   return -EINVAL;
> > +   }
> Please fix bridge so connector creation is optional.
> for new bridge driver this is mandatory.

Can you elaborate what is means by fixing bridge here, what are the
things that should be done and are expected for new bridge drivers

> > +static const struct drm_bridge_funcs lt9611_bridge_funcs = {
> > +   .attach = lt9611_bridge_attach,
> > +   .detach = lt9611_bridge_detach

[PATCH v1 11/11] soc: mediatek: cmdq: add set event function

[Dennis YC Hsieh]

Add set event function in cmdq helper functions to set specific event.

Signed-off-by: Dennis YC Hsieh 
---
 drivers/soc/mediatek/mtk-cmdq-helper.c   |   15 +++
 include/linux/mailbox/mtk-cmdq-mailbox.h |1 +
 include/linux/soc/mediatek/mtk-cmdq.h|9 +
 3 files changed, 25 insertions(+)

diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c 
b/drivers/soc/mediatek/mtk-cmdq-helper.c
index 13f78c9b5901..e6133a42d229 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -346,6 +346,21 @@ int cmdq_pkt_clear_event(struct cmdq_pkt *pkt, u16 event)
 }
 EXPORT_SYMBOL(cmdq_pkt_clear_event);
 
+int cmdq_pkt_set_event(struct cmdq_pkt *pkt, u16 event)
+{
+   struct cmdq_instruction inst = {};
+
+   if (event >= CMDQ_MAX_EVENT)
+   return -EINVAL;
+
+   inst.op = CMDQ_CODE_WFE;
+   inst.value = CMDQ_WFE_UPDATE | CMDQ_WFE_UPDATE_VALUE;
+   inst.event = event;
+
+   return cmdq_pkt_append_command(pkt, inst);
+}
+EXPORT_SYMBOL(cmdq_pkt_set_event);
+
 int cmdq_pkt_poll(struct cmdq_pkt *pkt, u8 subsys,
  u16 offset, u32 value)
 {
diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h 
b/include/linux/mailbox/mtk-cmdq-mailbox.h
index 42d2a30e6a70..ba2d811183a9 100644
--- a/include/linux/mailbox/mtk-cmdq-mailbox.h
+++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
@@ -17,6 +17,7 @@
 #define CMDQ_JUMP_PASS CMDQ_INST_SIZE
 
 #define CMDQ_WFE_UPDATEBIT(31)
+#define CMDQ_WFE_UPDATE_VALUE  BIT(16)
 #define CMDQ_WFE_WAIT  BIT(15)
 #define CMDQ_WFE_WAIT_VALUE0x1
 
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h 
b/include/linux/soc/mediatek/mtk-cmdq.h
index 4b5f5d154bad..960704d75994 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -199,6 +199,15 @@ int cmdq_pkt_write_s_mask_value(struct cmdq_pkt *pkt, u8 
high_addr_reg_idx,
 int cmdq_pkt_clear_event(struct cmdq_pkt *pkt, u16 event);
 
 /**
+ * cmdq_pkt_set_event() - append set event command to the CMDQ packet
+ * @pkt:   the CMDQ packet
+ * @event: the desired event to be set
+ *
+ * Return: 0 for success; else the error code is returned
+ */
+int cmdq_pkt_set_event(struct cmdq_pkt *pkt, u16 event);
+
+/**
  * cmdq_pkt_poll() - Append polling command to the CMDQ packet, ask GCE to
  *  execute an instruction that wait for a specified
  *  hardware register to check for the value w/o mask.
-- 
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v11 1/4] drm/panel: Add helper for reading DT rotation

[Dmitry Osipenko]

18.06.2020 02:18, Dmitry Osipenko пишет:
> From: Derek Basehore 
> 
> This adds a helper function for reading the rotation (panel
> orientation) from the device tree.
> 
> Signed-off-by: Derek Basehore 
> Reviewed-by: Sam Ravnborg 
> ---

My t-b accidentally got lost after rebase, here it is:

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

Re: [PATCH v3 03/15] pwm: lpss: Fix off by one error in base_unit math in pwm_lpss_prepare()

[Uwe Kleine-König]

On Sat, Jun 20, 2020 at 02:17:46PM +0200, Hans de Goede wrote:
> According to the data-sheet the way the PWM controller works is that
> each input clock-cycle the base_unit gets added to a N bit counter and
> that counter overflowing determines the PWM output frequency.
> 
> So assuming e.g. a 16 bit counter this means that if base_unit is set to 1,
> after 65535 input clock-cycles the counter has been increased from 0 to
> 65535 and it will overflow on the next cycle, so it will overflow after
> every 65536 clock cycles and thus the calculations done in
> pwm_lpss_prepare() should use 65536 and not 65535.
> 
> This commit fixes this. Note this also aligns the calculations in
> pwm_lpss_prepare() with those in pwm_lpss_get_state().
> 
> Note this effectively reverts commit 684309e5043e ("pwm: lpss: Avoid
> potential overflow of base_unit"). The next patch in this series really
> fixes the potential overflow of the base_unit value.
> 
> Fixes: 684309e5043e ("pwm: lpss: Avoid potential overflow of base_unit")
> Reviewed-by: Andy Shevchenko 
> Signed-off-by: Hans de Goede 
> ---
> Changes in v3:
> - Add Fixes tag
> - Add Reviewed-by: Andy Shevchenko tag
> ---
>  drivers/pwm/pwm-lpss.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c
> index 9d965ffe66d1..43b1fc634af1 100644
> --- a/drivers/pwm/pwm-lpss.c
> +++ b/drivers/pwm/pwm-lpss.c
> @@ -93,7 +93,7 @@ static void pwm_lpss_prepare(struct pwm_lpss_chip *lpwm, 
> struct pwm_device *pwm,
>* The equation is:
>* base_unit = round(base_unit_range * freq / c)
>*/
> - base_unit_range = BIT(lpwm->info->base_unit_bits) - 1;
> + base_unit_range = BIT(lpwm->info->base_unit_bits);
>   freq *= base_unit_range;
>  
>   base_unit = DIV_ROUND_CLOSEST_ULL(freq, c);
> @@ -104,8 +104,8 @@ static void pwm_lpss_prepare(struct pwm_lpss_chip *lpwm, 
> struct pwm_device *pwm,
>  
>   orig_ctrl = ctrl = pwm_lpss_read(pwm);
>   ctrl &= ~PWM_ON_TIME_DIV_MASK;
> - ctrl &= ~(base_unit_range << PWM_BASE_UNIT_SHIFT);
> - base_unit &= base_unit_range;
> + ctrl &= ~((base_unit_range - 1) << PWM_BASE_UNIT_SHIFT);
> + base_unit &= (base_unit_range - 1);
>   ctrl |= (u32) base_unit << PWM_BASE_UNIT_SHIFT;
>   ctrl |= on_time_div;

I willing to believe your change is right, what I don't like is that the
calculation is really hard to follow. But that's nothing I want to
burden on you to improve. (If however you are motivated, adding some
comments about the hardware would probably help.)

Acked-by: Uwe Kleine-König 

Thanks
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |


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

Re: [PATCH v3 04/15] pwm: lpss: Add range limit check for the base_unit register value

[Uwe Kleine-König]

On Sat, Jun 20, 2020 at 02:17:47PM +0200, Hans de Goede wrote:
> When the user requests a high enough period ns value, then the
> calculations in pwm_lpss_prepare() might result in a base_unit value of 0.
> 
> But according to the data-sheet the way the PWM controller works is that
> each input clock-cycle the base_unit gets added to a N bit counter and
> that counter overflowing determines the PWM output frequency. Adding 0
> to the counter is a no-op. The data-sheet even explicitly states that
> writing 0 to the base_unit bits will result in the PWM outputting a
> continuous 0 signal.
> 
> When the user requestes a low enough period ns value, then the
> calculations in pwm_lpss_prepare() might result in a base_unit value
> which is bigger then base_unit_range - 1. Currently the codes for this
> deals with this by applying a mask:
> 
>   base_unit &= (base_unit_range - 1);
> 
> But this means that we let the value overflow the range, we throw away the
> higher bits and store whatever value is left in the lower bits into the
> register leading to a random output frequency, rather then clamping the
> output frequency to the highest frequency which the hardware can do.
> 
> This commit fixes both issues by clamping the base_unit value to be
> between 1 and (base_unit_range - 1).
> 
> Fixes: 684309e5043e ("pwm: lpss: Avoid potential overflow of base_unit")
> Signed-off-by: Hans de Goede 
> ---
> Changes in v3:
> - Change upper limit of clamp to (base_unit_range - 1)
> - Add Fixes tag
> ---
>  drivers/pwm/pwm-lpss.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c
> index 43b1fc634af1..80d0f9c64f9d 100644
> --- a/drivers/pwm/pwm-lpss.c
> +++ b/drivers/pwm/pwm-lpss.c
> @@ -97,6 +97,9 @@ static void pwm_lpss_prepare(struct pwm_lpss_chip *lpwm, 
> struct pwm_device *pwm,
>   freq *= base_unit_range;
>  
>   base_unit = DIV_ROUND_CLOSEST_ULL(freq, c);

DIV_ROUND_CLOSEST_ULL is most probably wrong, too. But I didn't spend
the time to actually confirm that.

> + /* base_unit must not be 0 and we also want to avoid overflowing it */
> + base_unit = clamp_t(unsigned long long, base_unit, 1,
> + base_unit_range - 1);

.get_state seems to handle base_unit == 0 just fine?! Though this
doesn't look right either ...

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |


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

Re: [PATCH v3 09/15] pwm: crc: Enable/disable PWM output on enable/disable

[Uwe Kleine-König]

Hello,

[adding Shobhit Kumar  to Cc who is the author
of this driver according to the comment on the top of the driver]

On Sat, Jun 20, 2020 at 02:17:52PM +0200, Hans de Goede wrote:
> The pwm-crc code is using 2 different enable bits:
> 1. bit 7 of the PWM0_CLK_DIV (PWM_OUTPUT_ENABLE)
> 2. bit 0 of the BACKLIGHT_EN register
> 
> So far we've kept the PWM_OUTPUT_ENABLE bit set when disabling the PWM,
> this commit makes crc_pwm_disable() clear it on disable and makes
> crc_pwm_enable() set it again on re-enable.
> 
> Signed-off-by: Hans de Goede 
> ---
> Changes in v3:
> - Remove paragraph about tri-stating the output from the commit message,
>   we don't have a datasheet so this was just an unfounded guess

I have the impression you spend quite some time with this driver trying
to understand it. What I still think is a bit unfortunate is that there
is quite some guesswork involved. I wonder if it would be possible to
get the manual of that PWM. Do I understand correctly that this is IP
from Intel? There are quite some Intel people on Cc; maybe someone can
help/put in a good word/check and ack the changes?

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |


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

Re: [PATCH v3 11/15] pwm: crc: Implement get_state() method

[Uwe Kleine-König]

On Sat, Jun 20, 2020 at 02:17:54PM +0200, Hans de Goede wrote:
> Implement the pwm_ops.get_state() method to complete the support for the
> new atomic PWM API.
> 
> Reviewed-by: Andy Shevchenko 
> Signed-off-by: Hans de Goede 
> ---
> Changes in v3:
> - Add Andy's Reviewed-by tag
> - Remove extra whitespace to align some code after assignments (requested by
>   Uwe Kleine-König)
> ---
>  drivers/pwm/pwm-crc.c | 29 +
>  1 file changed, 29 insertions(+)
> 
> diff --git a/drivers/pwm/pwm-crc.c b/drivers/pwm/pwm-crc.c
> index 8a7f4707279c..b311354d40a3 100644
> --- a/drivers/pwm/pwm-crc.c
> +++ b/drivers/pwm/pwm-crc.c
> @@ -119,8 +119,37 @@ static int crc_pwm_apply(struct pwm_chip *chip, struct 
> pwm_device *pwm,
>   return 0;
>  }
>  
> +static void crc_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
> +struct pwm_state *state)
> +{
> + struct crystalcove_pwm *crc_pwm = to_crc_pwm(chip);
> + struct device *dev = crc_pwm->chip.dev;
> + unsigned int clk_div, clk_div_reg, duty_cycle_reg;
> + int error;
> +
> + error = regmap_read(crc_pwm->regmap, PWM0_CLK_DIV, &clk_div_reg);
> + if (error) {
> + dev_err(dev, "Error reading PWM0_CLK_DIV %d\n", error);
> + return;
> + }
> +
> + error = regmap_read(crc_pwm->regmap, PWM0_DUTY_CYCLE, &duty_cycle_reg);
> + if (error) {
> + dev_err(dev, "Error reading PWM0_DUTY_CYCLE %d\n", error);
> + return;
> + }
> +
> + clk_div = (clk_div_reg & ~PWM_OUTPUT_ENABLE) + 1;
> +
> + state->period = clk_div * NSEC_PER_USEC * 256 / PWM_BASE_CLK_MHZ;
> + state->duty_cycle = duty_cycle_reg * state->period / PWM_MAX_LEVEL;

Please round up here.

> + state->polarity = PWM_POLARITY_NORMAL;
> + state->enabled = !!(clk_div_reg & PWM_OUTPUT_ENABLE);
> +}
> +

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |


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

Re: [PATCH 2/3] drm: uapi: Use SPDX in DRM drivers uAPI headers

[Christian König]

Am 21.06.20 um 04:07 schrieb Laurent Pinchart:

Most of the DRM drivers uAPI headers are licensed under the MIT license,
and carry copies of the license with slight variations. Replace them
with SPDX headers.


My personal opinion is that this is a really good idea, but my 
professional is that we need the acknowledgment from our legal 
department for this.


Please separate that change into one for each driver/company/maintainer. 
Amdgpu, radeon, r128 can be one for example.


Thanks,
Christian.



Signed-off-by: Laurent Pinchart 
---
  include/uapi/drm/amdgpu_drm.h  | 19 +--
  include/uapi/drm/i915_drm.h| 22 +-
  include/uapi/drm/mga_drm.h | 20 +---
  include/uapi/drm/msm_drm.h | 20 +---
  include/uapi/drm/nouveau_drm.h | 20 +---
  include/uapi/drm/qxl_drm.h | 20 +---
  include/uapi/drm/r128_drm.h| 20 +---
  include/uapi/drm/radeon_drm.h  | 20 +---
  include/uapi/drm/savage_drm.h  | 20 +---
  include/uapi/drm/sis_drm.h | 21 +
  include/uapi/drm/tegra_drm.h   | 19 +--
  include/uapi/drm/v3d_drm.h | 20 +---
  include/uapi/drm/vc4_drm.h | 20 +---
  include/uapi/drm/vgem_drm.h| 22 +-
  include/uapi/drm/via_drm.h | 20 +---
  include/uapi/drm/virtgpu_drm.h | 20 +---
  include/uapi/drm/vmwgfx_drm.h  | 21 +
  17 files changed, 17 insertions(+), 327 deletions(-)

diff --git a/include/uapi/drm/amdgpu_drm.h b/include/uapi/drm/amdgpu_drm.h
index 4e873dcbe68f..c6adda72bec7 100644
--- a/include/uapi/drm/amdgpu_drm.h
+++ b/include/uapi/drm/amdgpu_drm.h
@@ -1,3 +1,4 @@
+/* SPDX-License-Identifier: MIT */
  /* amdgpu_drm.h -- Public header for the amdgpu driver -*- linux-c -*-
   *
   * Copyright 2000 Precision Insight, Inc., Cedar Park, Texas.
@@ -5,24 +6,6 @@
   * Copyright 2002 Tungsten Graphics, Inc., Cedar Park, Texas.
   * Copyright 2014 Advanced Micro Devices, Inc.
   *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the "Software"),
- * to deal in the Software without restriction, including without limitation
- * the rights to use, copy, modify, merge, publish, distribute, sublicense,
- * and/or sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following conditions:
- *
- * The above copyright notice and this permission notice shall be included in
- * all copies or substantial portions of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
- * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
- * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
- * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
- * OTHER DEALINGS IN THE SOFTWARE.
- *
   * Authors:
   *Kevin E. Martin 
   *Gareth Hughes 
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 14b67cd6b54b..c29e3acb3026 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -1,27 +1,7 @@
+/* SPDX-License-Identifier: MIT */
  /*
   * Copyright 2003 Tungsten Graphics, Inc., Cedar Park, Texas.
   * All Rights Reserved.
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the
- * "Software"), to deal in the Software without restriction, including
- * without limitation the rights to use, copy, modify, merge, publish,
- * distribute, sub license, and/or sell copies of the Software, and to
- * permit persons to whom the Software is furnished to do so, subject to
- * the following conditions:
- *
- * The above copyright notice and this permission notice (including the
- * next paragraph) shall be included in all copies or substantial portions
- * of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
- * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
- * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.
- * IN NO EVENT SHALL TUNGSTEN GRAPHICS AND/OR ITS SUPPLIERS BE LIABLE FOR
- * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
- * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
- * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
- *
   */
  
  #ifndef _UAPI_I915_DRM_H_

diff --git a/include/uapi/drm/mga_drm.h b/include/uapi/drm/mga_drm.h
index 8c4337548ab5..4415efefe0cf 100644
--- a/include/uapi/drm/mga_drm.h
+++ b/include/uapi/drm/mga_drm.h
@@ -1,3 +1,4 @@
+/* SPDX-License-

Re: [PATCH RESEND v1] drm/meson: viu: fix setting the OSD burst length in VIU_OSD1_FIFO_CTRL_STAT

[Neil Armstrong]

Hi Martin,

On 20/06/2020 17:57, Martin Blumenstingl wrote:
> The burst length is configured in VIU_OSD1_FIFO_CTRL_STAT[31] and
> VIU_OSD1_FIFO_CTRL_STAT[11:10]. The public S905D3 datasheet describes
> this as:
> - 0x0 = up to 24 per burst
> - 0x1 = up to 32 per burst
> - 0x2 = up to 48 per burst
> - 0x3 = up to 64 per burst
> - 0x4 = up to 96 per burst
> - 0x5 = up to 128 per burst
> 
> The lower two bits map to VIU_OSD1_FIFO_CTRL_STAT[11:10] while the upper
> bit maps to VIU_OSD1_FIFO_CTRL_STAT[31].
> 
> Replace meson_viu_osd_burst_length_reg() with pre-defined macros which
> set these values. meson_viu_osd_burst_length_reg() always returned 0
> (for the two used values: 32 and 64 at least) and thus incorrectly set
> the burst size to 24.
> 
> Fixes: 147ae1cbaa1842 ("drm: meson: viu: use proper macros instead of magic 
> constants")
> Signed-off-by: Martin Blumenstingl 
> ---
> re-send of v1 [0] with no changes as I still noticed that this is
> sitting in my tree and I wasn't asked to change anything in v1.
> 
> 
> [0] https://patchwork.kernel.org/patch/11510045/
> 
> 
>  drivers/gpu/drm/meson/meson_registers.h |  6 ++
>  drivers/gpu/drm/meson/meson_viu.c   | 11 ++-
>  2 files changed, 8 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/meson/meson_registers.h 
> b/drivers/gpu/drm/meson/meson_registers.h
> index 8ea00546cd4e..049c4bfe2a3a 100644
> --- a/drivers/gpu/drm/meson/meson_registers.h
> +++ b/drivers/gpu/drm/meson/meson_registers.h
> @@ -261,6 +261,12 @@
>  #define VIU_OSD_FIFO_DEPTH_VAL(val)  ((val & 0x7f) << 12)
>  #define VIU_OSD_WORDS_PER_BURST(words)   (((words & 0x4) >> 1) << 22)
>  #define VIU_OSD_FIFO_LIMITS(size)((size & 0xf) << 24)
> +#define VIU_OSD_BURST_LENGTH_24  (0x0 << 31 | 0x0 << 10)
> +#define VIU_OSD_BURST_LENGTH_32  (0x0 << 31 | 0x1 << 10)
> +#define VIU_OSD_BURST_LENGTH_48  (0x0 << 31 | 0x2 << 10)
> +#define VIU_OSD_BURST_LENGTH_64  (0x0 << 31 | 0x3 << 10)
> +#define VIU_OSD_BURST_LENGTH_96  (0x1 << 31 | 0x0 << 10)
> +#define VIU_OSD_BURST_LENGTH_128 (0x1 << 31 | 0x1 << 10)
>  
>  #define VD1_IF0_GEN_REG 0x1a50
>  #define VD1_IF0_CANVAS0 0x1a51
> diff --git a/drivers/gpu/drm/meson/meson_viu.c 
> b/drivers/gpu/drm/meson/meson_viu.c
> index 304f8ff1339c..aede0c67a57f 100644
> --- a/drivers/gpu/drm/meson/meson_viu.c
> +++ b/drivers/gpu/drm/meson/meson_viu.c
> @@ -411,13 +411,6 @@ void meson_viu_gxm_disable_osd1_afbc(struct meson_drm 
> *priv)
>   priv->io_base + _REG(VIU_MISC_CTRL1));
>  }
>  
> -static inline uint32_t meson_viu_osd_burst_length_reg(uint32_t length)
> -{
> - uint32_t val = (((length & 0x80) % 24) / 12);
> -
> - return (((val & 0x3) << 10) | (((val & 0x4) >> 2) << 31));
> -}
> -
>  void meson_viu_init(struct meson_drm *priv)
>  {
>   uint32_t reg;
> @@ -444,9 +437,9 @@ void meson_viu_init(struct meson_drm *priv)
>   VIU_OSD_FIFO_LIMITS(2);  /* fifo_lim: 2*16=32 */
>  
>   if (meson_vpu_is_compatible(priv, VPU_COMPATIBLE_G12A))
> - reg |= meson_viu_osd_burst_length_reg(32);
> + reg |= VIU_OSD_BURST_LENGTH_32;
>   else
> - reg |= meson_viu_osd_burst_length_reg(64);
> + reg |= VIU_OSD_BURST_LENGTH_64;
>  
>   writel_relaxed(reg, priv->io_base + _REG(VIU_OSD1_FIFO_CTRL_STAT));
>   writel_relaxed(reg, priv->io_base + _REG(VIU_OSD2_FIFO_CTRL_STAT));
> 

Completely forgot this one, will test asap.

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

Re: [PATCH v4 3/5] drm: panel: Add Xingbangda XBD599 panel (ST7703 controller)

[Sam Ravnborg]

On Sun, Jun 21, 2020 at 12:30:10AM +0200, Ondřej Jirman wrote:
> On Sat, Jun 20, 2020 at 11:25:29PM +0200, Sam Ravnborg wrote:
> > Hi Ondrej et al.
> > 
> > On Wed, Jun 17, 2020 at 02:32:07AM +0200, Ondrej Jirman wrote:
> > > From: Icenowy Zheng 
> > > 
> > > Xingbangda XBD599 is a 5.99" 720x1440 MIPI-DSI IPS LCD panel made by
> > > Xingbangda, which is used on PinePhone final assembled phones.
> > > 
> > > It is based on Sitronix ST7703 LCD controller.
> > 
> > I am a little late to the game here - so sorry if this has been
> > discussed before.
> > We already have panel-rocktech-jh057n00900.c which is a panle driver
> > based on st7703.
> > Why is it we need a new driver?
> 
> No reason other than the driver not being named after the controller,
> so I didn't notice.
> 
> > Would it not be better to have one st7703 driver that suipports both
> > panels?
> >
> > The driver would need dedicated init functions depending on the panel.
> > But a lot could also be shared.
> 
> I guess I can move the code there. 
In the same process the river should then be renamed to follow other
sitronix based drivers.
So the next developer will recognize this and use the correct driver.

Sam

> 
> regards,
>   o.
> 
> > Sam
> > 
> > > 
> > > Add support for it.
> > > 
> > > Signed-off-by: Icenowy Zheng 
> > > Signed-off-by: Ondrej Jirman 
> > > ---
> > >  drivers/gpu/drm/panel/Kconfig |  10 +
> > >  drivers/gpu/drm/panel/Makefile|   1 +
> > >  drivers/gpu/drm/panel/panel-sitronix-st7703.c | 535 ++
> > >  3 files changed, 546 insertions(+)
> > >  create mode 100644 drivers/gpu/drm/panel/panel-sitronix-st7703.c
> > > 
> > > diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> > > index 39055c1f0e2f..b7bc157b0612 100644
> > > --- a/drivers/gpu/drm/panel/Kconfig
> > > +++ b/drivers/gpu/drm/panel/Kconfig
> > > @@ -395,6 +395,16 @@ config DRM_PANEL_SITRONIX_ST7701
> > > ST7701 controller for 480X864 LCD panels with MIPI/RGB/SPI
> > > system interfaces.
> > >  
> > > +config DRM_PANEL_SITRONIX_ST7703
> > > + tristate "Sitronix ST7703 panel driver"
> > > + depends on OF
> > > + depends on DRM_MIPI_DSI
> > > + depends on BACKLIGHT_CLASS_DEVICE
> > > + help
> > > +   Say Y here if you want to enable support for the Sitronix
> > > +   ST7703 controller for 720X1440 LCD panels with MIPI/RGB/SPI
> > > +   system interfaces.
> > > +
> > >  config DRM_PANEL_SITRONIX_ST7789V
> > >   tristate "Sitronix ST7789V panel"
> > >   depends on OF && SPI
> > > diff --git a/drivers/gpu/drm/panel/Makefile 
> > > b/drivers/gpu/drm/panel/Makefile
> > > index de74f282c433..47f4789a8685 100644
> > > --- a/drivers/gpu/drm/panel/Makefile
> > > +++ b/drivers/gpu/drm/panel/Makefile
> > > @@ -41,6 +41,7 @@ obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += 
> > > panel-sharp-lq101r1sx01.o
> > >  obj-$(CONFIG_DRM_PANEL_SHARP_LS037V7DW01) += panel-sharp-ls037v7dw01.o
> > >  obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
> > >  obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7701) += panel-sitronix-st7701.o
> > > +obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7703) += panel-sitronix-st7703.o
> > >  obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
> > >  obj-$(CONFIG_DRM_PANEL_SONY_ACX424AKP) += panel-sony-acx424akp.o
> > >  obj-$(CONFIG_DRM_PANEL_SONY_ACX565AKM) += panel-sony-acx565akm.o
> > > diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c 
> > > b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> > > new file mode 100644
> > > index ..dbd46b6c0b46
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> > > @@ -0,0 +1,535 @@
> > > +// SPDX-License-Identifier: GPL-2.0
> > > +/*
> > > + * DRM driver for Sitronix ST7703 MIPI DSI panel
> > > + *
> > > + * Copyright (C) 2020 Ondrej Jirman 
> > > + * Copyright (C) 2019-2020 Icenowy Zheng 
> > > + *
> > > + * Based on panel-rocktech-jh057n00900.c, which is:
> > > + *   Copyright (C) Purism SPC 2019
> > > + */
> > > +
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +
> > > +/* Manufacturer specific DCS commands */
> > > +#define ST7703_CMD_SETDISP   0xB2
> > > +#define ST7703_CMD_SETRGBIF  0xB3
> > > +#define ST7703_CMD_SETCYC0xB4
> > > +#define ST7703_CMD_SETBGP0xB5
> > > +#define ST7703_CMD_SETVCOM   0xB6
> > > +#define ST7703_CMD_SETOTP0xB7
> > > +#define ST7703_CMD_SETPOWER_EXT  0xB8
> > > +#define ST7703_CMD_SETEXTC   0xB9
> > > +#define ST7703_CMD_SETMIPI   0xBA
> > > +#define ST7703_CMD_SETVDC0xBC
> > > +#define ST7703_CMD_UNK_BF0xBF
> > > +#define ST7703_CMD_SETSCR0xC0
> > > +#define ST7703_CMD_SETPOWER  0xC1
> > > +#define ST7703_CMD_UNK_C60xC6
> > > +#define ST7703_CMD_SETPANEL  0xCC
> > > +#define ST7703_CMD_RDID1 0xDA
> > > +#define ST7703_CMD

Re: [Intel-gfx] [PATCH 03/18] dma-fence: basic lockdep annotations

[Daniel Vetter]

On Fri, Jun 19, 2020 at 3:12 PM Chris Wilson  wrote:
>
> Quoting Daniel Vetter (2020-06-19 10:43:09)
> > On Fri, Jun 19, 2020 at 10:13:35AM +0100, Chris Wilson wrote:
> > > Quoting Daniel Vetter (2020-06-19 09:51:59)
> > > > On Fri, Jun 19, 2020 at 10:25 AM Chris Wilson 
> > > >  wrote:
> > > > > Forcing a generic primitive to always be part of the same global map 
> > > > > is
> > > > > horrible.
> > > >
> > > > And  no concrete example or reason for why that's not possible.
> > > > Because frankly it's not horrible, this is what upstream is all about:
> > > > Shared concepts, shared contracts, shared code.
> > > >
> > > > The proposed patches might very well encode the wrong contract, that's
> > > > all up for discussion. But fundamentally questioning that we need one
> > > > is missing what upstream is all about.
> > >
> > > Then I have not clearly communicated, as my opinion is not that
> > > validation is worthless, but that the implementation is enshrining a
> > > global property on a low level primitive that prevents it from being
> > > used elsewhere. And I want to replace completion [chains] with fences, and
> > > bio with fences, and closures with fences, and what other equivalencies
> > > there are in the kernel. The fence is as central a locking construct as
> > > struct completion and deserves to be a foundational primitive provided
> > > by kernel/ used throughout all drivers for discrete problem domains.
> > >
> > > This is narrowing dma_fence whereby adding
> > >   struct lockdep_map *dma_fence::wait_map
> > > and annotating linkage, allows you to continue to specify that all
> > > dma_fence used for a particular purpose must follow common rules,
> > > without restricting the primitive for uses outside of this scope.
> >
> > Somewhere else in this thread I had discussions with Jason Gunthorpe about
> > this topic. It might maybe change somewhat depending upon exact rules, but
> > his take is very much "I don't want dma_fence in rdma". Or pretty close to
> > that at least.
> >
> > Similar discussions with habanalabs, they're using dma_fence internally
> > without any of the uapi. Discussion there has also now concluded that it's
> > best if they remove them, and simply switch over to a wait_queue or
> > completion like every other driver does.
> >
> > The next round of the patches already have a paragraph to at least
> > somewhat limit how non-gpu drivers use dma_fence. And I guess actual
> > consensus might be pointing even more strongly at dma_fence being solely
> > something for gpus and closely related subsystem (maybe media) for syncing
> > dma-buf access.
> >
> > So dma_fence as general replacement for completion chains I think just
> > wont happen.
>
> That is sad. I cannot comprehend going back to pure completions after a
> taste of fence scheduling. And we are not even close to fully utilising
> them, as not all the async cpu [allocation!] tasks are fully tracked by
> fences yet and are still stuck in a FIFO workqueue.
>
> > What might make sense is if e.g. the lockdep annotations could be reused,
> > at least in design, for wait_queue or completion or anything else
> > really. I do think that has a fair chance compared to the automagic
> > cross-release annotations approach, which relied way too heavily on
> > guessing where barriers are. My experience from just a bit of playing
> > around with these patches here and discussing them with other driver
> > maintainers is that accurately deciding where critical sections start and
> > end is a job for humans only. And if you get it wrong, you will have a
> > false positive.
> >
> > And you're indeed correct that if we'd do annotations for completions and
> > wait queues, then that would need to have a class per semantically
> > equivalent user, like we have lockdep classes for mutexes, not just one
> > overall.
> >
> > But dma_fence otoh is something very specific, which comes with very
> > specific rules attached - it's not a generic wait_queue at all. Originally
> > it did start out as one even, but it is a very specialized wait_queue.
> >
> > So there's imo two cases:
> >
> > - Your completion is entirely orthogonal of dma_fences, and can never ever
> >   block a dma_fence. Don't use dma_fence for this, and no problem. It's
> >   just another wait_queue somewhere.
> >
> > - Your completion can eventually, maybe through lots of convolutions and
> >   depdencies, block a dma_fence. In that case full dma_fence rules apply,
> >   and the only thing you can do with a custom annotation is make the rules
> >   even stricter. E.g. if a sub-timeline in the scheduler isn't allowed to
> >   take certain scheduler locks. But the userspace visible/published fence
> >   do take them, maybe as part of command submission or retirement.
> >   Entirely hypotethical, no idea any driver actually needs this.
>
> I think we are faced with this very real problem.
>
> The papering we have today over userptr is so very thin, and if you
> squint you can 

Re: [PATCH 1/3] drm: uapi: Use SPDX in DRM core uAPI headers

[Daniel Vetter]

On Sun, Jun 21, 2020 at 05:07:01AM +0300, Laurent Pinchart wrote:
> The DRM core uAPI headers are licensed under the MIT license, and carry
> copies of the license with slight variations. Replace them with SPDX
> headers.
> 
> Following a discussion with Daniel Vetter on this topic, add a
> clarification in the drm-uapi.rst file that independent closed-source
> userspace implementations of software using the DRM uAPI are accepted,
> as allowed by the MIT license.
> 
> Signed-off-by: Laurent Pinchart 
> Reviewed-by: Greg Kroah-Hartman 
> Reviewed-by: Thomas Gleixner 

Reviewed-by: Daniel Vetter 

> ---
>  Documentation/gpu/drm-uapi.rst |  4 
>  include/uapi/drm/drm.h | 20 +---
>  include/uapi/drm/drm_fourcc.h  | 20 +---
>  include/uapi/drm/drm_mode.h| 19 +--
>  include/uapi/drm/drm_sarea.h   | 20 +---
>  5 files changed, 8 insertions(+), 75 deletions(-)
> 
> diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
> index 56fec6ed1ad8..de2ecc76dd6c 100644
> --- a/Documentation/gpu/drm-uapi.rst
> +++ b/Documentation/gpu/drm-uapi.rst
> @@ -107,6 +107,10 @@ is already rather painful for the DRM subsystem, with 
> multiple different uAPIs
>  for the same thing co-existing. If we add a few more complete mistakes into 
> the
>  mix every year it would be entirely unmanageable.
>  
> +The DRM subsystem has however no concern with independent closed-source
> +userspace implementations. To officialize that position, the DRM uAPI headers
> +are covered by the MIT license.
> +
>  .. _drm_render_node:
>  
>  Render nodes
> diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> index 808b48a93330..14d57361e580 100644
> --- a/include/uapi/drm/drm.h
> +++ b/include/uapi/drm/drm.h
> @@ -1,3 +1,4 @@
> +/* SPDX-License-Identifier: MIT */
>  /**
>   * \file drm.h
>   * Header for the Direct Rendering Manager
> @@ -12,25 +13,6 @@
>   * Copyright 1999 Precision Insight, Inc., Cedar Park, Texas.
>   * Copyright 2000 VA Linux Systems, Inc., Sunnyvale, California.
>   * All rights reserved.
> - *
> - * Permission is hereby granted, free of charge, to any person obtaining a
> - * copy of this software and associated documentation files (the "Software"),
> - * to deal in the Software without restriction, including without limitation
> - * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> - * and/or sell copies of the Software, and to permit persons to whom the
> - * Software is furnished to do so, subject to the following conditions:
> - *
> - * The above copyright notice and this permission notice (including the next
> - * paragraph) shall be included in all copies or substantial portions of the
> - * Software.
> - *
> - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> - * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> - * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> - * VA LINUX SYSTEMS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
> - * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> - * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> - * OTHER DEALINGS IN THE SOFTWARE.
>   */
>  
>  #ifndef _DRM_H_
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 490143500a50..d2c4a597620f 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -1,24 +1,6 @@
> +/* SPDX-License-Identifier: MIT */
>  /*
>   * Copyright 2011 Intel Corporation
> - *
> - * Permission is hereby granted, free of charge, to any person obtaining a
> - * copy of this software and associated documentation files (the "Software"),
> - * to deal in the Software without restriction, including without limitation
> - * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> - * and/or sell copies of the Software, and to permit persons to whom the
> - * Software is furnished to do so, subject to the following conditions:
> - *
> - * The above copyright notice and this permission notice (including the next
> - * paragraph) shall be included in all copies or substantial portions of the
> - * Software.
> - *
> - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> - * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> - * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> - * VA LINUX SYSTEMS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
> - * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> - * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> - * OTHER DEALINGS IN THE SOFTWARE.
>   */
>  
>  #ifndef DRM_FOURCC_H
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index 735c8cfdaaa1..c34a544fdf29 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode

Re: [PATCH 3/3] drm: uapi: Remove copies of GPL license text from headers

[Daniel Vetter]

On Sun, Jun 21, 2020 at 05:07:03AM +0300, Laurent Pinchart wrote:
> Several DRM drivers uAPI headers that are licensed under the GPL carry
> both an SPDX header and a copy of the license text. Drop the latter.
> 
> Signed-off-by: Laurent Pinchart 

I do kinda wonder how much lolz these gpl-only headers are. With or
without syscall exception, the ioctls in here are imo very far away from a
standardized syscall of any form.

But also not my problem :-)

Reviewed-by: Daniel Vetter 

> ---
>  include/uapi/drm/armada_drm.h  |  4 
>  include/uapi/drm/etnaviv_drm.h | 12 
>  include/uapi/drm/exynos_drm.h  |  5 -
>  include/uapi/drm/omap_drm.h| 12 
>  4 files changed, 33 deletions(-)
> 
> diff --git a/include/uapi/drm/armada_drm.h b/include/uapi/drm/armada_drm.h
> index af1c14c837c5..f711e63a9758 100644
> --- a/include/uapi/drm/armada_drm.h
> +++ b/include/uapi/drm/armada_drm.h
> @@ -2,10 +2,6 @@
>  /*
>   * Copyright (C) 2012 Russell King
>   *  With inspiration from the i915 driver
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License version 2 as
> - * published by the Free Software Foundation.
>   */
>  #ifndef DRM_ARMADA_IOCTL_H
>  #define DRM_ARMADA_IOCTL_H
> diff --git a/include/uapi/drm/etnaviv_drm.h b/include/uapi/drm/etnaviv_drm.h
> index 09d0df8b71c5..e23e0f885655 100644
> --- a/include/uapi/drm/etnaviv_drm.h
> +++ b/include/uapi/drm/etnaviv_drm.h
> @@ -1,18 +1,6 @@
>  /* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
>  /*
>   * Copyright (C) 2015 Etnaviv Project
> - *
> - * This program is free software; you can redistribute it and/or modify it
> - * under the terms of the GNU General Public License version 2 as published 
> by
> - * the Free Software Foundation.
> - *
> - * This program is distributed in the hope that it will be useful, but 
> WITHOUT
> - * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> - * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> - * more details.
> - *
> - * You should have received a copy of the GNU General Public License along 
> with
> - * this program.  If not, see .
>   */
>  
>  #ifndef __ETNAVIV_DRM_H__
> diff --git a/include/uapi/drm/exynos_drm.h b/include/uapi/drm/exynos_drm.h
> index a51aa1c618c1..a96fa566433c 100644
> --- a/include/uapi/drm/exynos_drm.h
> +++ b/include/uapi/drm/exynos_drm.h
> @@ -6,11 +6,6 @@
>   *   Inki Dae 
>   *   Joonyoung Shim 
>   *   Seung-Woo Kim 
> - *
> - * This program is free software; you can redistribute  it and/or modify it
> - * under  the terms of  the GNU General  Public License as published by the
> - * Free Software Foundation;  either version 2 of the  License, or (at your
> - * option) any later version.
>   */
>  
>  #ifndef _UAPI_EXYNOS_DRM_H_
> diff --git a/include/uapi/drm/omap_drm.h b/include/uapi/drm/omap_drm.h
> index 5a142fad473c..b51dad32122d 100644
> --- a/include/uapi/drm/omap_drm.h
> +++ b/include/uapi/drm/omap_drm.h
> @@ -4,18 +4,6 @@
>   *
>   * Copyright (C) 2011 Texas Instruments
>   * Author: Rob Clark 
> - *
> - * This program is free software; you can redistribute it and/or modify it
> - * under the terms of the GNU General Public License version 2 as published 
> by
> - * the Free Software Foundation.
> - *
> - * This program is distributed in the hope that it will be useful, but 
> WITHOUT
> - * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> - * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> - * more details.
> - *
> - * You should have received a copy of the GNU General Public License along 
> with
> - * this program.  If not, see .
>   */
>  
>  #ifndef __OMAP_DRM_H__
> -- 
> Regards,
> 
> Laurent Pinchart
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [kbuild-all] Re: [PATCH 4/4] drm: pl111: Update documentation

[Rong Chen]

On 6/12/20 8:40 PM, Philip Li wrote:

On Fri, Jun 12, 2020 at 01:04:02PM +0200, Linus Walleij wrote:

On Wed, Jun 10, 2020 at 9:38 AM kernel test robot  wrote:


I love your patch! Perhaps something to improve:

[auto build test WARNING on drm-exynos/exynos-drm-next]
[also build test WARNING on drm-intel/for-linux-next 
tegra-drm/drm/tegra/for-next linus/master v5.7 next-20200609]
[cannot apply to drm-tip/drm-tip drm/drm-next]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:
https://github.com/0day-ci/linux/commits/Linus-Walleij/drm-pl111-Credit-where-credit-is-due/20200610-041025
base:   https://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git 
exynos-drm-next
reproduce: make htmldocs

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

What on earth was that. The robot reports on a patch only adding a few lines
of comments as breaking the whole universe, and none of these systems
even use the PL111.

Thanks for feedback, this is supposed to check make htmldocs. We will double
check this to fix issue. Sorry for noise.


Hi Linus,

We won't show unrelated htmldocs warnings in the future,
but the warning (with prefix '>>') was found in this patch,
could you take a look?


drivers/gpu/drm/pl111/pl111_drv.c:1: warning: 'ARM PrimeCell PL111 CLCD Driver' 
not found



Best Regards,
Rong Chen
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/3] drm: uapi: Use SPDX in DRM drivers uAPI headers

[Daniel Vetter]

On Mon, Jun 22, 2020 at 09:58:44AM +0200, Christian König wrote:
> Am 21.06.20 um 04:07 schrieb Laurent Pinchart:
> > Most of the DRM drivers uAPI headers are licensed under the MIT license,
> > and carry copies of the license with slight variations. Replace them
> > with SPDX headers.
> 
> My personal opinion is that this is a really good idea, but my professional
> is that we need the acknowledgment from our legal department for this.

I think official ack from amd on first patch, especially the .rst snippet,
would be really good indeed.

> Please separate that change into one for each driver/company/maintainer.
> Amdgpu, radeon, r128 can be one for example.

You can leave all the other legacy drivers in one patch (mga, savage, sis,
via), since there's likely no one around anymore and will just boil down
to drm maintainer ack from Dave&me.
-Daniel

> 
> Thanks,
> Christian.
> 
> > 
> > Signed-off-by: Laurent Pinchart 
> > ---
> >   include/uapi/drm/amdgpu_drm.h  | 19 +--
> >   include/uapi/drm/i915_drm.h| 22 +-
> >   include/uapi/drm/mga_drm.h | 20 +---
> >   include/uapi/drm/msm_drm.h | 20 +---
> >   include/uapi/drm/nouveau_drm.h | 20 +---
> >   include/uapi/drm/qxl_drm.h | 20 +---
> >   include/uapi/drm/r128_drm.h| 20 +---
> >   include/uapi/drm/radeon_drm.h  | 20 +---
> >   include/uapi/drm/savage_drm.h  | 20 +---
> >   include/uapi/drm/sis_drm.h | 21 +
> >   include/uapi/drm/tegra_drm.h   | 19 +--
> >   include/uapi/drm/v3d_drm.h | 20 +---
> >   include/uapi/drm/vc4_drm.h | 20 +---
> >   include/uapi/drm/vgem_drm.h| 22 +-
> >   include/uapi/drm/via_drm.h | 20 +---
> >   include/uapi/drm/virtgpu_drm.h | 20 +---
> >   include/uapi/drm/vmwgfx_drm.h  | 21 +
> >   17 files changed, 17 insertions(+), 327 deletions(-)
> > 
> > diff --git a/include/uapi/drm/amdgpu_drm.h b/include/uapi/drm/amdgpu_drm.h
> > index 4e873dcbe68f..c6adda72bec7 100644
> > --- a/include/uapi/drm/amdgpu_drm.h
> > +++ b/include/uapi/drm/amdgpu_drm.h
> > @@ -1,3 +1,4 @@
> > +/* SPDX-License-Identifier: MIT */
> >   /* amdgpu_drm.h -- Public header for the amdgpu driver -*- linux-c -*-
> >*
> >* Copyright 2000 Precision Insight, Inc., Cedar Park, Texas.
> > @@ -5,24 +6,6 @@
> >* Copyright 2002 Tungsten Graphics, Inc., Cedar Park, Texas.
> >* Copyright 2014 Advanced Micro Devices, Inc.
> >*
> > - * Permission is hereby granted, free of charge, to any person obtaining a
> > - * copy of this software and associated documentation files (the 
> > "Software"),
> > - * to deal in the Software without restriction, including without 
> > limitation
> > - * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> > - * and/or sell copies of the Software, and to permit persons to whom the
> > - * Software is furnished to do so, subject to the following conditions:
> > - *
> > - * The above copyright notice and this permission notice shall be included 
> > in
> > - * all copies or substantial portions of the Software.
> > - *
> > - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS 
> > OR
> > - * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> > - * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> > - * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
> > - * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> > - * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> > - * OTHER DEALINGS IN THE SOFTWARE.
> > - *
> >* Authors:
> >*Kevin E. Martin 
> >*Gareth Hughes 
> > diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> > index 14b67cd6b54b..c29e3acb3026 100644
> > --- a/include/uapi/drm/i915_drm.h
> > +++ b/include/uapi/drm/i915_drm.h
> > @@ -1,27 +1,7 @@
> > +/* SPDX-License-Identifier: MIT */
> >   /*
> >* Copyright 2003 Tungsten Graphics, Inc., Cedar Park, Texas.
> >* All Rights Reserved.
> > - *
> > - * Permission is hereby granted, free of charge, to any person obtaining a
> > - * copy of this software and associated documentation files (the
> > - * "Software"), to deal in the Software without restriction, including
> > - * without limitation the rights to use, copy, modify, merge, publish,
> > - * distribute, sub license, and/or sell copies of the Software, and to
> > - * permit persons to whom the Software is furnished to do so, subject to
> > - * the following conditions:
> > - *
> > - * The above copyright notice and this permission notice (including the
> > - * next paragraph) shall be included in all copies or substantial portions
> > - * of the Software.
> > - *
> > - * THE SOFTWARE IS PRO

Re: [PATCH v2 1/8] drm: Add dummy page per device or GEM object

[Daniel Vetter]

On Sun, Jun 21, 2020 at 02:03:01AM -0400, Andrey Grodzovsky wrote:
> Will be used to reroute CPU mapped BO's page faults once
> device is removed.
> 
> Signed-off-by: Andrey Grodzovsky 
> ---
>  drivers/gpu/drm/drm_file.c  |  8 
>  drivers/gpu/drm/drm_prime.c | 10 ++
>  include/drm/drm_file.h  |  2 ++
>  include/drm/drm_gem.h   |  2 ++
>  4 files changed, 22 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> index c4c704e..67c0770 100644
> --- a/drivers/gpu/drm/drm_file.c
> +++ b/drivers/gpu/drm/drm_file.c
> @@ -188,6 +188,12 @@ struct drm_file *drm_file_alloc(struct drm_minor *minor)
>   goto out_prime_destroy;
>   }
>  
> + file->dummy_page = alloc_page(GFP_KERNEL | __GFP_ZERO);
> + if (!file->dummy_page) {
> + ret = -ENOMEM;
> + goto out_prime_destroy;
> + }
> +
>   return file;
>  
>  out_prime_destroy:
> @@ -284,6 +290,8 @@ void drm_file_free(struct drm_file *file)
>   if (dev->driver->postclose)
>   dev->driver->postclose(dev, file);
>  
> + __free_page(file->dummy_page);
> +
>   drm_prime_destroy_file_private(&file->prime);
>  
>   WARN_ON(!list_empty(&file->event_list));
> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> index 1de2cde..c482e9c 100644
> --- a/drivers/gpu/drm/drm_prime.c
> +++ b/drivers/gpu/drm/drm_prime.c
> @@ -335,6 +335,13 @@ int drm_gem_prime_fd_to_handle(struct drm_device *dev,
>  
>   ret = drm_prime_add_buf_handle(&file_priv->prime,
>   dma_buf, *handle);
> +
> + if (!ret) {
> + obj->dummy_page = alloc_page(GFP_KERNEL | __GFP_ZERO);
> + if (!obj->dummy_page)
> + ret = -ENOMEM;
> + }
> +
>   mutex_unlock(&file_priv->prime.lock);
>   if (ret)
>   goto fail;
> @@ -1006,6 +1013,9 @@ void drm_prime_gem_destroy(struct drm_gem_object *obj, 
> struct sg_table *sg)
>   dma_buf_unmap_attachment(attach, sg, DMA_BIDIRECTIONAL);
>   dma_buf = attach->dmabuf;
>   dma_buf_detach(attach->dmabuf, attach);
> +
> + __free_page(obj->dummy_page);
> +
>   /* remove the reference */
>   dma_buf_put(dma_buf);
>  }
> diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
> index 19df802..349a658 100644
> --- a/include/drm/drm_file.h
> +++ b/include/drm/drm_file.h
> @@ -335,6 +335,8 @@ struct drm_file {
>*/
>   struct drm_prime_file_private prime;
>  

Kerneldoc for these please, including why we need them and when. E.g. the
one in gem_bo should say it's only for exported buffers, so that we're not
colliding security spaces.

> + struct page *dummy_page;
> +
>   /* private: */
>  #if IS_ENABLED(CONFIG_DRM_LEGACY)
>   unsigned long lock_count; /* DRI1 legacy lock count */
> diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
> index 0b37506..47460d1 100644
> --- a/include/drm/drm_gem.h
> +++ b/include/drm/drm_gem.h
> @@ -310,6 +310,8 @@ struct drm_gem_object {
>*
>*/
>   const struct drm_gem_object_funcs *funcs;
> +
> + struct page *dummy_page;
>  };

I think amdgpu doesn't care, but everyone else still might care somewhat
about flink. That also shares buffers, so also needs to allocate the
per-bo dummy page.

I also wonder whether we shouldn't have a helper to look up the dummy
page, just to encode in core code how it's supposedo to cascade.
-Daniel

>  
>  /**
> -- 
> 2.7.4
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 2/8] drm/ttm: Remap all page faults to per process dummy page.

[Daniel Vetter]

On Sun, Jun 21, 2020 at 02:03:02AM -0400, Andrey Grodzovsky wrote:
> On device removal reroute all CPU mappings to dummy page per drm_file
> instance or imported GEM object.
> 
> Signed-off-by: Andrey Grodzovsky 
> ---
>  drivers/gpu/drm/ttm/ttm_bo_vm.c | 65 
> -
>  1 file changed, 57 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> index 389128b..2f8bf5e 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> @@ -35,6 +35,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -328,19 +330,66 @@ vm_fault_t ttm_bo_vm_fault(struct vm_fault *vmf)

Hm I think diff and code flow look a bit bad now. What about renaming the
current function to __ttm_bo_vm_fault and then having something like the
below:

ttm_bo_vm_fault(args) {

if (drm_dev_enter()) {
__ttm_bo_vm_fault(args);
drm_dev_exit();
} else  {
drm_gem_insert_dummy_pfn();
}
}

I think drm_gem_insert_dummy_pfn(); should be portable across drivers, so
another nice point to try to unifiy drivers as much as possible.
-Daniel

>   pgprot_t prot;
>   struct ttm_buffer_object *bo = vma->vm_private_data;
>   vm_fault_t ret;
> + int idx;
> + struct drm_device *ddev = bo->base.dev;
>  
> - ret = ttm_bo_vm_reserve(bo, vmf);
> - if (ret)
> - return ret;
> + if (drm_dev_enter(ddev, &idx)) {
> + ret = ttm_bo_vm_reserve(bo, vmf);
> + if (ret)
> + goto exit;
> +
> + prot = vma->vm_page_prot;
>  
> - prot = vma->vm_page_prot;
> - ret = ttm_bo_vm_fault_reserved(vmf, prot, TTM_BO_VM_NUM_PREFAULT);
> - if (ret == VM_FAULT_RETRY && !(vmf->flags & FAULT_FLAG_RETRY_NOWAIT))
> + ret = ttm_bo_vm_fault_reserved(vmf, prot, 
> TTM_BO_VM_NUM_PREFAULT);
> + if (ret == VM_FAULT_RETRY && !(vmf->flags & 
> FAULT_FLAG_RETRY_NOWAIT))
> + goto exit;
> +
> + dma_resv_unlock(bo->base.resv);
> +
> +exit:
> + drm_dev_exit(idx);
>   return ret;
> + } else {
>  
> - dma_resv_unlock(bo->base.resv);
> + struct drm_file *file = NULL;
> + struct page *dummy_page = NULL;
> + int handle;
>  
> - return ret;
> + /* We are faulting on imported BO from dma_buf */
> + if (bo->base.dma_buf && bo->base.import_attach) {
> + dummy_page = bo->base.dummy_page;
> + /* We are faulting on non imported BO, find drm_file owning the 
> BO*/

Uh, we can't fish that out of the vma->vm_file pointer somehow? Or is that
one all wrong? Doing this kind of list walk looks pretty horrible.

If the vma doesn't have the right pointer I guess next option is that we
store the drm_file page in gem_bo->dummy_page, and replace it on first
export. But that's going to be tricky to track ...

> + } else {
> + struct drm_gem_object *gobj;
> +
> + mutex_lock(&ddev->filelist_mutex);
> + list_for_each_entry(file, &ddev->filelist, lhead) {
> + spin_lock(&file->table_lock);
> + idr_for_each_entry(&file->object_idr, gobj, 
> handle) {
> + if (gobj == &bo->base) {
> + dummy_page = file->dummy_page;
> + break;
> + }
> + }
> + spin_unlock(&file->table_lock);
> + }
> + mutex_unlock(&ddev->filelist_mutex);
> + }
> +
> + if (dummy_page) {
> + /*
> +  * Let do_fault complete the PTE install e.t.c using 
> vmf->page
> +  *
> +  * TODO - should i call free_page somewhere ?

Nah, instead don't call get_page. The page will be around as long as
there's a reference for the drm_file or gem_bo, which is longer than any
mmap. Otherwise yes this would like really badly.

> +  */
> + get_page(dummy_page);
> + vmf->page = dummy_page;
> + return 0;
> + } else {
> + return VM_FAULT_SIGSEGV;

Hm that would be a kernel bug, wouldn't it? WARN_ON() required here imo.
-Daniel

> + }
> + }
>  }
>  EXPORT_SYMBOL(ttm_bo_vm_fault);
>  
> -- 
> 2.7.4
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 3/8] drm/ttm: Add unampping of the entire device address space

[Daniel Vetter]

On Sun, Jun 21, 2020 at 02:03:03AM -0400, Andrey Grodzovsky wrote:
> Helper function to be used to invalidate all BOs CPU mappings
> once device is removed.
> 
> Signed-off-by: Andrey Grodzovsky 

This seems to be missing the code to invalidate all the dma-buf mmaps?

Probably needs more testcases if you're not yet catching this. Or am I
missing something, and we're exchanging the the address space also for
dma-buf?
-Daniel

> ---
>  drivers/gpu/drm/ttm/ttm_bo.c| 8 ++--
>  include/drm/ttm/ttm_bo_driver.h | 7 +++
>  2 files changed, 13 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index c5b516f..926a365 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -1750,10 +1750,14 @@ void ttm_bo_unmap_virtual(struct ttm_buffer_object 
> *bo)
>   ttm_bo_unmap_virtual_locked(bo);
>   ttm_mem_io_unlock(man);
>  }
> -
> -
>  EXPORT_SYMBOL(ttm_bo_unmap_virtual);
>  
> +void ttm_bo_unmap_virtual_address_space(struct ttm_bo_device *bdev)
> +{
> + unmap_mapping_range(bdev->dev_mapping, 0, 0, 1);
> +}
> +EXPORT_SYMBOL(ttm_bo_unmap_virtual_address_space);
> +
>  int ttm_bo_wait(struct ttm_buffer_object *bo,
>   bool interruptible, bool no_wait)
>  {
> diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
> index c9e0fd0..39ea44f 100644
> --- a/include/drm/ttm/ttm_bo_driver.h
> +++ b/include/drm/ttm/ttm_bo_driver.h
> @@ -601,6 +601,13 @@ int ttm_bo_device_init(struct ttm_bo_device *bdev,
>  void ttm_bo_unmap_virtual(struct ttm_buffer_object *bo);
>  
>  /**
> + * ttm_bo_unmap_virtual_address_space
> + *
> + * @bdev: tear down all the virtual mappings for this device
> + */
> +void ttm_bo_unmap_virtual_address_space(struct ttm_bo_device *bdev);
> +
> +/**
>   * ttm_bo_unmap_virtual
>   *
>   * @bo: tear down the virtual mappings for this BO
> -- 
> 2.7.4
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 0/8] RFC Support hot device unplug in amdgpu

[Daniel Vetter]

On Sun, Jun 21, 2020 at 02:03:00AM -0400, Andrey Grodzovsky wrote:
> This RFC is more of a proof of concept then a fully working solution as there 
> are a few unresolved issues we are hoping to get advise on from people on the 
> mailing list.
> Until now extracting a card either by physical extraction (e.g. eGPU with 
> thunderbolt connection or by emulation through syfs -> 
> /sys/bus/pci/devices/device_id/remove)
> would cause random crashes in user apps. The random crashes in apps were 
> mostly due to the app having mapped a device backed BO into its address space 
> was still
> trying to access the BO while the backing device was gone.
> To answer this first problem Christian suggested to fix the handling of 
> mapped memory in the clients when the device goes away by forcibly unmap all 
> buffers
> the user processes has by clearing their respective VMAs mapping the device 
> BOs. Then when the VMAs try to fill in the page tables again we check in the 
> fault handler
> if the device is removed and if so, return an error. This will generate a 
> SIGBUS to the application which can then cleanly terminate.
> This indeed was done but this in turn created a problem of kernel OOPs were 
> the OOPSes were due to the fact that while the app was terminating because of 
> the SIGBUS
> it would trigger use after free in the driver by calling to accesses device 
> structures that were already released from the pci remove sequence.
> This was handled by introducing a 'flush' sequence during device removal were 
> we wait for drm file reference to drop to 0 meaning all user clients directly 
> using this device terminated.
> With this I was able to cleanly emulate device unplug with X and glxgears 
> running and later emulate device plug back and restart of X and glxgears.
> 
> v2:
> Based on discussions in the mailing list with Daniel and Pekka [1] and based 
> on the document produced by Pekka from those discussions [2] the whole 
> approach with returning SIGBUS
> and waiting for all user clients having CPU mapping of device BOs to die was 
> dropped. Instead as per the document suggestion the device structures are 
> kept alive until the last
> reference to the device is dropped by user client and in the meanwhile all 
> existing and new CPU mappings of the BOs belonging to the device directly or 
> by dma-buf import are rerouted
> to per user process dummy rw page.
> Also, I skipped the 'Requirements for KMS UAPI' section of [2] since i am 
> trying to get the minimal set of requiremnts that still give useful solution 
> to work and this is the
> 'Requirements for Render and Cross-Device UAPI' section and so my test case 
> is removing a secondary device, which is render only and is not involved in 
> KMS.
>  
> This iteration is still more of a draft as I am still facing a few unsolved 
> issues such as a crash in user client when trying to CPU map imported BO if 
> the map happens after device was
> removed and HW failure to plug back a removed device. Also since i don't have 
> real life setup with external GPU connected through TB I am using sysfs to 
> emulate pci remove and i
> expect to encounter more issues once i try this on real life case. I am also 
> expecting some help on this from a user who volunteered to test in the 
> related gitlab ticket.
> So basically this is more of a  way to get feedback if I am moving in the 
> right direction.
> 
> [1] - Discussions during v1 of the patchset 
> https://lists.freedesktop.org/archives/dri-devel/2020-May/265386.html
> [2] - drm/doc: device hot-unplug for userspace 
> https://www.spinics.net/lists/dri-devel/msg259755.html
> [3] - Related gitlab ticket 
> https://gitlab.freedesktop.org/drm/amd/-/issues/1081

A few high-level commments on the generic parts, I didn't really look at
the amdgpu side yet.

Also a nit: Please tell your mailer to break long lines, it looks funny
and inconsistent otherwise, at least in some of the mailers I use here :-/
-Daniel
>  
> 
> Andrey Grodzovsky (8):
>   drm: Add dummy page per device or GEM object
>   drm/ttm: Remap all page faults to per process dummy page.
>   drm/ttm: Add unampping of the entire device address space
>   drm/amdgpu: Split amdgpu_device_fini into early and late
>   drm/amdgpu: Refactor sysfs removal
>   drm/amdgpu: Unmap entire device address space on device remove.
>   drm/amdgpu: Fix sdma code crash post device unplug
>   drm/amdgpu: Prevent any job recoveries after device is unplugged.
> 
>  drivers/gpu/drm/amd/amdgpu/amdgpu.h  | 19 +++-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c |  7 ++-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c   | 50 +
>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c  | 23 --
>  drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c  | 12 +++--
>  drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c  | 24 ++
>  drivers/gpu/drm/amd/amdgpu/amdgpu_irq.h  |  1 +
>  drivers/gpu/drm/amd/amdgpu/amdgpu_job.c  |  8 
>  drivers/gpu/drm/amd/a

Re: [PATCH v2 4/8] drm/amdgpu: Split amdgpu_device_fini into early and late

[Daniel Vetter]

On Sun, Jun 21, 2020 at 02:03:04AM -0400, Andrey Grodzovsky wrote:
> Some of the stuff in amdgpu_device_fini such as HW interrupts
> disable and pending fences finilization must be done right away on
> pci_remove while most of the stuff which relates to finilizing and releasing
> driver data structures can be kept until drm_driver.release hook is called, 
> i.e.
> when the last device reference is dropped.
> 
> Signed-off-by: Andrey Grodzovsky 

Long term I think best if as much of this code is converted over to devm
(for hw stuff) and drmm (for sw stuff and allocations). Doing this all
manually is very error prone.

I've started various such patches and others followed, but thus far only
very simple drivers tackled. But it should be doable step by step at
least, so you should have incremental benefits in code complexity right
away I hope.
-Daniel

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu.h|  6 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 15 +++
>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|  6 ++
>  drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c| 24 +++-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_irq.h|  1 +
>  drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c| 23 +--
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c|  3 +++
>  7 files changed, 54 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index 2a806cb..604a681 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -1003,7 +1003,9 @@ int amdgpu_device_init(struct amdgpu_device *adev,
>  struct drm_device *ddev,
>  struct pci_dev *pdev,
>  uint32_t flags);
> -void amdgpu_device_fini(struct amdgpu_device *adev);
> +void amdgpu_device_fini_early(struct amdgpu_device *adev);
> +void amdgpu_device_fini_late(struct amdgpu_device *adev);
> +
>  int amdgpu_gpu_wait_for_idle(struct amdgpu_device *adev);
>  
>  void amdgpu_device_vram_access(struct amdgpu_device *adev, loff_t pos,
> @@ -1188,6 +1190,8 @@ void amdgpu_driver_lastclose_kms(struct drm_device 
> *dev);
>  int amdgpu_driver_open_kms(struct drm_device *dev, struct drm_file 
> *file_priv);
>  void amdgpu_driver_postclose_kms(struct drm_device *dev,
>struct drm_file *file_priv);
> +void amdgpu_driver_release_kms(struct drm_device *dev);
> +
>  int amdgpu_device_ip_suspend(struct amdgpu_device *adev);
>  int amdgpu_device_suspend(struct drm_device *dev, bool fbcon);
>  int amdgpu_device_resume(struct drm_device *dev, bool fbcon);
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index cc41e8f..e7b9065 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -2309,6 +2309,8 @@ static int amdgpu_device_ip_fini(struct amdgpu_device 
> *adev)
>  {
>   int i, r;
>  
> + //DRM_ERROR("adev 0x%llx", (long long unsigned int)adev);
> +
>   amdgpu_ras_pre_fini(adev);
>  
>   if (adev->gmc.xgmi.num_physical_nodes > 1)
> @@ -3304,10 +3306,8 @@ int amdgpu_device_init(struct amdgpu_device *adev,
>   * Tear down the driver info (all asics).
>   * Called at driver shutdown.
>   */
> -void amdgpu_device_fini(struct amdgpu_device *adev)
> +void amdgpu_device_fini_early(struct amdgpu_device *adev)
>  {
> - int r;
> -
>   DRM_INFO("amdgpu: finishing device.\n");
>   flush_delayed_work(&adev->delayed_init_work);
>   adev->shutdown = true;
> @@ -3330,7 +3330,13 @@ void amdgpu_device_fini(struct amdgpu_device *adev)
>   if (adev->pm_sysfs_en)
>   amdgpu_pm_sysfs_fini(adev);
>   amdgpu_fbdev_fini(adev);
> - r = amdgpu_device_ip_fini(adev);
> +
> + amdgpu_irq_fini_early(adev);
> +}
> +
> +void amdgpu_device_fini_late(struct amdgpu_device *adev)
> +{
> + amdgpu_device_ip_fini(adev);
>   if (adev->firmware.gpu_info_fw) {
>   release_firmware(adev->firmware.gpu_info_fw);
>   adev->firmware.gpu_info_fw = NULL;
> @@ -3368,6 +3374,7 @@ void amdgpu_device_fini(struct amdgpu_device *adev)
>   amdgpu_pmu_fini(adev);
>   if (amdgpu_discovery && adev->asic_type >= CHIP_NAVI10)
>   amdgpu_discovery_fini(adev);
> +
>  }
>  
>  
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> index 9e5afa5..43592dc 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> @@ -1134,12 +1134,9 @@ amdgpu_pci_remove(struct pci_dev *pdev)
>  {
>   struct drm_device *dev = pci_get_drvdata(pdev);
>  
> -#ifdef MODULE
> - if (THIS_MODULE->state != MODULE_STATE_GOING)
> -#endif
> - DRM_ERROR("Hotplug removal is not supported\n");
>   drm_dev_unplug(dev);
>   amdgpu_driver_unload_kms(dev);
> +
>   pci_disable_device(pdev);
>   p

Re: [PATCH v2 5/8] drm/amdgpu: Refactor sysfs removal

[Daniel Vetter]

On Sun, Jun 21, 2020 at 02:03:05AM -0400, Andrey Grodzovsky wrote:
> Track sysfs files in a list so they all can be removed during pci remove
> since otherwise their removal after that causes crash because parent
> folder was already removed during pci remove.
> 
> Signed-off-by: Andrey Grodzovsky 

Uh I thought sysfs just gets yanked completely. Please check with Greg KH
whether hand-rolling all this really is the right solution here ... Feels
very wrong. I thought this was all supposed to work by adding attributes
before publishing the sysfs node, and then letting sysfs clean up
everything. Not by cleaning up manually yourself.

Adding Greg for an authoritative answer.
-Daniel

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu.h  | 13 +++
>  drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c |  7 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c   | 35 
> 
>  drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c  | 12 ++
>  drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c  |  8 ++-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 17 --
>  drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 13 ++-
>  drivers/gpu/drm/amd/amdgpu/df_v3_6.c | 10 +---
>  8 files changed, 99 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index 604a681..ba3775f 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -726,6 +726,15 @@ struct amd_powerplay {
>  
>  #define AMDGPU_RESET_MAGIC_NUM 64
>  #define AMDGPU_MAX_DF_PERFMONS 4
> +
> +struct amdgpu_sysfs_list_node {
> + struct list_head head;
> + struct device_attribute *attr;
> +};
> +
> +#define AMDGPU_DEVICE_ATTR_LIST_NODE(_attr) \
> + struct amdgpu_sysfs_list_node dev_attr_handle_##_attr = {.attr = 
> &dev_attr_##_attr}
> +
>  struct amdgpu_device {
>   struct device   *dev;
>   struct drm_device   *ddev;
> @@ -992,6 +1001,10 @@ struct amdgpu_device {
>   charproduct_number[16];
>   charproduct_name[32];
>   charserial[16];
> +
> + struct list_head sysfs_files_list;
> + struct mutex sysfs_files_list_lock;
> +
>  };
>  
>  static inline struct amdgpu_device *amdgpu_ttm_adev(struct ttm_bo_device 
> *bdev)
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
> index fdd52d8..c1549ee 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
> @@ -1950,8 +1950,10 @@ static ssize_t 
> amdgpu_atombios_get_vbios_version(struct device *dev,
>   return snprintf(buf, PAGE_SIZE, "%s\n", ctx->vbios_version);
>  }
>  
> +
>  static DEVICE_ATTR(vbios_version, 0444, amdgpu_atombios_get_vbios_version,
>  NULL);
> +static AMDGPU_DEVICE_ATTR_LIST_NODE(vbios_version);
>  
>  /**
>   * amdgpu_atombios_fini - free the driver info and callbacks for atombios
> @@ -1972,7 +1974,6 @@ void amdgpu_atombios_fini(struct amdgpu_device *adev)
>   adev->mode_info.atom_context = NULL;
>   kfree(adev->mode_info.atom_card_info);
>   adev->mode_info.atom_card_info = NULL;
> - device_remove_file(adev->dev, &dev_attr_vbios_version);
>  }
>  
>  /**
> @@ -2038,6 +2039,10 @@ int amdgpu_atombios_init(struct amdgpu_device *adev)
>   return ret;
>   }
>  
> + mutex_lock(&adev->sysfs_files_list_lock);
> + list_add_tail(&dev_attr_handle_vbios_version.head, 
> &adev->sysfs_files_list);
> + mutex_unlock(&adev->sysfs_files_list_lock);
> +
>   return 0;
>  }
>  
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index e7b9065..3173046 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -2928,6 +2928,12 @@ static const struct attribute *amdgpu_dev_attributes[] 
> = {
>   NULL
>  };
>  
> +static AMDGPU_DEVICE_ATTR_LIST_NODE(product_name);
> +static AMDGPU_DEVICE_ATTR_LIST_NODE(product_number);
> +static AMDGPU_DEVICE_ATTR_LIST_NODE(serial_number);
> +static AMDGPU_DEVICE_ATTR_LIST_NODE(pcie_replay_count);
> +
> +
>  /**
>   * amdgpu_device_init - initialize the driver
>   *
> @@ -3029,6 +3035,9 @@ int amdgpu_device_init(struct amdgpu_device *adev,
>   INIT_LIST_HEAD(&adev->shadow_list);
>   mutex_init(&adev->shadow_list_lock);
>  
> + INIT_LIST_HEAD(&adev->sysfs_files_list);
> + mutex_init(&adev->sysfs_files_list_lock);
> +
>   INIT_DELAYED_WORK(&adev->delayed_init_work,
> amdgpu_device_delayed_init_work_handler);
>   INIT_DELAYED_WORK(&adev->gfx.gfx_off_delay_work,
> @@ -3281,6 +3290,13 @@ int amdgpu_device_init(struct amdgpu_device *adev,
>   if (r) {
>   dev_err(adev->dev, "Could not create amdgpu device attr\n");
> 

Re: [PATCH v2 8/8] drm/amdgpu: Prevent any job recoveries after device is unplugged.

[Daniel Vetter]

On Sun, Jun 21, 2020 at 02:03:08AM -0400, Andrey Grodzovsky wrote:
> No point to try recovery if device is gone, just messes up things.
> 
> Signed-off-by: Andrey Grodzovsky 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 16 
>  drivers/gpu/drm/amd/amdgpu/amdgpu_job.c |  8 
>  2 files changed, 24 insertions(+)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> index 6932d75..5d6d3d9 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> @@ -1129,12 +1129,28 @@ static int amdgpu_pci_probe(struct pci_dev *pdev,
>   return ret;
>  }
>  
> +static void amdgpu_cancel_all_tdr(struct amdgpu_device *adev)
> +{
> + int i;
> +
> + for (i = 0; i < AMDGPU_MAX_RINGS; ++i) {
> + struct amdgpu_ring *ring = adev->rings[i];
> +
> + if (!ring || !ring->sched.thread)
> + continue;
> +
> + cancel_delayed_work_sync(&ring->sched.work_tdr);
> + }
> +}

I think this is a function that's supposed to be in drm/scheduler, not
here. Might also just be your cleanup code being ordered wrongly, or your
split in one of the earlier patches not done quite right.
-Daniel

> +
>  static void
>  amdgpu_pci_remove(struct pci_dev *pdev)
>  {
>   struct drm_device *dev = pci_get_drvdata(pdev);
> + struct amdgpu_device *adev = dev->dev_private;
>  
>   drm_dev_unplug(dev);
> + amdgpu_cancel_all_tdr(adev);
>   ttm_bo_unmap_virtual_address_space(&adev->mman.bdev);
>   amdgpu_driver_unload_kms(dev);
>  
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
> index 4720718..87ff0c0 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
> @@ -28,6 +28,8 @@
>  #include "amdgpu.h"
>  #include "amdgpu_trace.h"
>  
> +#include 
> +
>  static void amdgpu_job_timedout(struct drm_sched_job *s_job)
>  {
>   struct amdgpu_ring *ring = to_amdgpu_ring(s_job->sched);
> @@ -37,6 +39,12 @@ static void amdgpu_job_timedout(struct drm_sched_job 
> *s_job)
>  
>   memset(&ti, 0, sizeof(struct amdgpu_task_info));
>  
> + if (drm_dev_is_unplugged(adev->ddev)) {
> + DRM_INFO("ring %s timeout, but device unplugged, skipping.\n",
> +   s_job->sched->name);
> + return;
> + }
> +
>   if (amdgpu_ring_soft_recovery(ring, job->vmid, s_job->s_fence->parent)) 
> {
>   DRM_ERROR("ring %s timeout, but soft recovered\n",
> s_job->sched->name);
> -- 
> 2.7.4
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 7/8] drm/amdgpu: Fix sdma code crash post device unplug

[Daniel Vetter]

On Sun, Jun 21, 2020 at 02:03:07AM -0400, Andrey Grodzovsky wrote:
> entity->rq becomes null aftre device unplugged so just return early
> in that case.
> 
> Signed-off-by: Andrey Grodzovsky 

That looks very deep in amdgpu internals ... how do you even get in here
after the device is fully unplugged on the sw side?

Is this amdkfd doing something stupid because entirely unaware of what
amdgpu has done? Something else? Just feels like this is just duct-taping
over a more fundamental problem, after hotunplug no one should be able to
even submit anything new, or do bo moves, or well anything really.
-Daniel

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c | 21 -
>  1 file changed, 16 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c
> index 8d9c6fe..d252427 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c
> @@ -24,6 +24,7 @@
>  #include "amdgpu_job.h"
>  #include "amdgpu_object.h"
>  #include "amdgpu_trace.h"
> +#include 
>  
>  #define AMDGPU_VM_SDMA_MIN_NUM_DW256u
>  #define AMDGPU_VM_SDMA_MAX_NUM_DW(16u * 1024u)
> @@ -94,7 +95,12 @@ static int amdgpu_vm_sdma_commit(struct 
> amdgpu_vm_update_params *p,
>   struct drm_sched_entity *entity;
>   struct amdgpu_ring *ring;
>   struct dma_fence *f;
> - int r;
> + int r, idx;
> +
> + if (!drm_dev_enter(p->adev->ddev, &idx)) {
> + r = -ENODEV;
> + goto nodev;
> + }
>  
>   entity = p->immediate ? &p->vm->immediate : &p->vm->delayed;
>   ring = container_of(entity->rq->sched, struct amdgpu_ring, sched);
> @@ -104,7 +110,7 @@ static int amdgpu_vm_sdma_commit(struct 
> amdgpu_vm_update_params *p,
>   WARN_ON(ib->length_dw > p->num_dw_left);
>   r = amdgpu_job_submit(p->job, entity, AMDGPU_FENCE_OWNER_VM, &f);
>   if (r)
> - goto error;
> + goto job_fail;
>  
>   if (p->unlocked) {
>   struct dma_fence *tmp = dma_fence_get(f);
> @@ -118,10 +124,15 @@ static int amdgpu_vm_sdma_commit(struct 
> amdgpu_vm_update_params *p,
>   if (fence && !p->immediate)
>   swap(*fence, f);
>   dma_fence_put(f);
> - return 0;
>  
> -error:
> - amdgpu_job_free(p->job);
> + r = 0;
> +
> +job_fail:
> + drm_dev_exit(idx);
> +nodev:
> + if (r)
> + amdgpu_job_free(p->job);
> +
>   return r;
>  }
>  
> -- 
> 2.7.4
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 6/8] drm/amdgpu: Unmap entire device address space on device remove.

[Daniel Vetter]

On Sun, Jun 21, 2020 at 02:03:06AM -0400, Andrey Grodzovsky wrote:
> Use the new TTM interface to invalidate all exsisting BO CPU mappings
> form all user proccesses.
> 
> Signed-off-by: Andrey Grodzovsky 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> index 43592dc..6932d75 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> @@ -1135,6 +1135,7 @@ amdgpu_pci_remove(struct pci_dev *pdev)
>   struct drm_device *dev = pci_get_drvdata(pdev);
>  
>   drm_dev_unplug(dev);
> + ttm_bo_unmap_virtual_address_space(&adev->mman.bdev);
>   amdgpu_driver_unload_kms(dev);

Hm a ttm, or maybe even vram helper function which wraps drm_dev_unplug +
ttm unmapping into one would be nice I think? I suspect there's going to
be more in the future here.
-Daniel

>  
>   pci_disable_device(pdev);
> -- 
> 2.7.4
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4] drm/fourcc: document modifier uniqueness requirements

[Brian Starkey]

On Fri, Jun 19, 2020 at 06:36:17PM +0200, Daniel Vetter wrote:
> On Fri, Jun 19, 2020 at 01:39:34PM +0100, Brian Starkey wrote:
> > Hi Simon,
> > 
> > On Fri, Jun 19, 2020 at 11:12:25AM +, Simon Ser wrote:
> > > There have suggestions to bake pitch alignment, address alignement,
> > > contiguous memory or other placement (hidden VRAM, GTT/BAR, etc)
> > > constraints into modifiers. Last time this was brought up it seemed
> > > like the consensus was to not allow this. Document this in drm_fourcc.h.
> > > 
> > > There are several reasons for this.
> > > 
> > > - Encoding all of these constraints in the modifiers would explode the
> > >   search space pretty quickly (we only have 64 bits to work with).
> > > - Modifiers need to be unambiguous: a buffer can only have a single
> > >   modifier.
> > > - Modifier users aren't expected to parse modifiers (except drivers).
> > > 
> > > v2: add paragraph about aliases (Daniel)
> > > 
> > > v3: fix unrelated changes sent with the patch
> > > 
> > > v4: disambiguate users between driver and higher-level programs (Brian,
> > > Daniel)
> > > 
> > > Signed-off-by: Simon Ser 
> > > Reviewed-by: Daniel Vetter 
> > > Cc: Daniel Stone 
> > > Cc: Bas Nieuwenhuizen 
> > > Cc: Dave Airlie 
> > > Cc: Marek Olšák 
> > > Cc: Alex Deucher 
> > > Cc: Neil Armstrong 
> > > Cc: Michel Dänzer 
> > > Cc: Brian Starkey 
> > > ---
> > >  include/uapi/drm/drm_fourcc.h | 22 ++
> > >  1 file changed, 22 insertions(+)
> > > 
> > > diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> > > index 490143500a50..4d3f819dca0b 100644
> > > --- a/include/uapi/drm/drm_fourcc.h
> > > +++ b/include/uapi/drm/drm_fourcc.h
> > > @@ -58,6 +58,28 @@ extern "C" {
> > >   * may preserve meaning - such as number of planes - from the fourcc 
> > > code,
> > >   * whereas others may not.
> > >   *
> > > + * Modifiers must uniquely encode buffer layout. In other words, a 
> > > buffer must
> > > + * match only a single modifier. A modifier must not be a subset of 
> > > layouts of
> > > + * another modifier. For instance, it's incorrect to encode pitch 
> > > alignment in
> > > + * a modifier: a buffer may match a 64-pixel aligned modifier and a 
> > > 32-pixel
> > > + * aligned modifier. That said, modifiers can have implicit minimal
> > > + * requirements.
> > > + *
> > > + * For modifiers where the combination of fourcc code and modifier can 
> > > alias,
> > > + * a canonical pair needs to be defined and used by all drivers. An 
> > > example
> > > + * is AFBC, where both ARGB and ABGR have the exact same compressed 
> > > layout.
> > 
> > I still don't agree with this sentence. ARGB and ABGR have different
> > compressed layouts in AFBC.
> 
> Hm then maybe I got confused for the exact reason why afbc has defined
> canonical fourcc codes in Documentation/gpu/afbc.rst? They all use the
> BGR versions, no RGB anywhere to be found.
> 
> What's the reason then behind the "Formats which are not listed should be
> avoided." in that doc? That's the case I wanted to refer to here.

Basically there's hardware which supports only BGR, hardware which
"ignores" swizzle (treats all as BGR), and hardware which supports
both BGR and RGB. Even amongst first-party implementations it's
inconsistent.

This leads to a potentially confusing situation where someone with
hardware which "ignores" swizzle assumes that's always the case.

To avoid that, we wanted to be explicit that ordering is important:

 | The assignment of input/output color channels must be consistent
 | between the encoder and the decoder for correct operation, otherwise
 | the consumer will interpret the decoded data incorrectly.
 | ...
 | The component ordering is communicated via the fourcc code in the
 | fourcc:modifier pair. In general, component '0' is considered to
 | reside in the least-significant bits of the corresponding linear
 | format. For example, COMP(bits):

And, to try and ensure best cross compatibility, we want BGR to be
used most often. We expect that to be supported by the most hardware:

 | For maximum compatibility across devices, the table below defines
 | canonical formats for use between AFBC-enabled devices. Formats which
 | are listed here must be used exactly as specified when using the AFBC
 | modifiers. Formats which are not listed should be avoided.

Cheers,
-Brian

> -Daniel
> 
> > 
> > Thanks,
> > -Brian
> > 
> > > + *
> > > + * There are two kinds of modifier users:
> > > + *
> > > + * - Kernel and user-space drivers: for drivers it's important that 
> > > modifiers
> > > + *   don't alias, otherwise two drivers might support the same format 
> > > but use
> > > + *   different aliases, preventing them from sharing buffers in an 
> > > efficient
> > > + *   format.
> > > + * - Higher-level programs interfacing with KMS/GBM/EGL/Vulkan/etc: 
> > > these users
> > > + *   see modifiers as opaque tokens they can check for equality and 
> > > intersect.
> > > + *   These users musn't n

Re: [PATCH] dt-bindings: backlight: Convert common backlight bindings to DT schema

[Daniel Thompson]

On Fri, Jun 19, 2020 at 11:53:41PM +0200, Sam Ravnborg wrote:
> Good to have these converted. A few comments in the following. One
> comment is for the backlight people as you copied the original text.

... and I've sliced out everything except that in this reply.

> On Thu, Jun 18, 2020 at 04:44:13PM -0600, Rob Herring wrote:
> > diff --git 
> > a/Documentation/devicetree/bindings/leds/backlight/led-backlight.yaml 
> > b/Documentation/devicetree/bindings/leds/backlight/led-backlight.yaml
> > new file mode 100644
> > index ..ae50945d2798
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/leds/backlight/led-backlight.yaml
> > @@ -0,0 +1,58 @@
> > ...
> > +
> > +  default-brightness-level:
> > +description: The default brightness level (index into the array defined
> > +  by the "brightness-levels" property).
>
> This description does not match my understading.
> The description says "index into", but in reality this is a value that
> matches somewhere in the range specified by brightness-levels.
> So it is not an index.
> 
> Maybe I just read it wrong and the description is fine. But when I read
> index the when it says 6 I would look for brightness-levels[6] equals
> 128 in the example below.

When the brightness-levels array is not present then backlight
brightness and led brightness have a 1:1 mapping. In this case the
meaning of "default brightness level" is (hopefully) obvious and the
parenthetic text does not apply.

When the array is present then we have two different scales of
brightness and it is important to describe which scale we use for the
default brightness. The language about "index into" was adopted to avoid
having to introduce extra terminology whilst making it clear that
setting the default brightness-level to 128 is invalid (because it is
not an acceptable index) and that a value of 6 will result in the LED
brightness being set to 128.


> And this is not how it is coded.

That had me worried for a moment but I think the code and bindings are
in agreement.

There is some code to map the LED scale (128) to the backlight scale (6)
but this used to ensure we supply the correct brightness level to user
space when an active backlight is handed over from bootloader to kernel.

If a default-brightness-level is provided then the above logic is
overridden and the value read from the DT gets placed directly into
props.brightness where it will act as in index into the brightness
table.


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

Re: [PATCH v1 02/11] soc: mediatek: cmdq: add assign function

[Matthias Brugger]

On 21/06/2020 16:18, Dennis YC Hsieh wrote:
> Add assign function in cmdq helper which assign constant value into
> internal register by index.
> 
> Signed-off-by: Dennis YC Hsieh 

Applied to v5.8-next/soc

Thanks

> ---
>  drivers/soc/mediatek/mtk-cmdq-helper.c   |   24 +++-
>  include/linux/mailbox/mtk-cmdq-mailbox.h |1 +
>  include/linux/soc/mediatek/mtk-cmdq.h|   14 ++
>  3 files changed, 38 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c 
> b/drivers/soc/mediatek/mtk-cmdq-helper.c
> index 98f23ba3ba47..bf32e3b2ca6c 100644
> --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> @@ -12,6 +12,7 @@
>  #define CMDQ_WRITE_ENABLE_MASK   BIT(0)
>  #define CMDQ_POLL_ENABLE_MASKBIT(0)
>  #define CMDQ_EOC_IRQ_EN  BIT(0)
> +#define CMDQ_REG_TYPE1
>  
>  struct cmdq_instruction {
>   union {
> @@ -21,8 +22,17 @@ struct cmdq_instruction {
>   union {
>   u16 offset;
>   u16 event;
> + u16 reg_dst;
> + };
> + union {
> + u8 subsys;
> + struct {
> + u8 sop:5;
> + u8 arg_c_t:1;
> + u8 src_t:1;
> + u8 dst_t:1;
> + };
>   };
> - u8 subsys;
>   u8 op;
>  };
>  
> @@ -277,6 +287,18 @@ int cmdq_pkt_poll_mask(struct cmdq_pkt *pkt, u8 subsys,
>  }
>  EXPORT_SYMBOL(cmdq_pkt_poll_mask);
>  
> +int cmdq_pkt_assign(struct cmdq_pkt *pkt, u16 reg_idx, u32 value)
> +{
> + struct cmdq_instruction inst = {};
> +
> + inst.op = CMDQ_CODE_LOGIC;
> + inst.dst_t = CMDQ_REG_TYPE;
> + inst.reg_dst = reg_idx;
> + inst.value = value;
> + return cmdq_pkt_append_command(pkt, inst);
> +}
> +EXPORT_SYMBOL(cmdq_pkt_assign);
> +
>  static int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
>  {
>   struct cmdq_instruction inst = { {0} };
> diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h 
> b/include/linux/mailbox/mtk-cmdq-mailbox.h
> index dfe5b2eb85cc..121c3bb6d3de 100644
> --- a/include/linux/mailbox/mtk-cmdq-mailbox.h
> +++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
> @@ -59,6 +59,7 @@ enum cmdq_code {
>   CMDQ_CODE_JUMP = 0x10,
>   CMDQ_CODE_WFE = 0x20,
>   CMDQ_CODE_EOC = 0x40,
> + CMDQ_CODE_LOGIC = 0xa0,
>  };
>  
>  enum cmdq_cb_status {
> diff --git a/include/linux/soc/mediatek/mtk-cmdq.h 
> b/include/linux/soc/mediatek/mtk-cmdq.h
> index a74c1d5acdf3..83340211e1d3 100644
> --- a/include/linux/soc/mediatek/mtk-cmdq.h
> +++ b/include/linux/soc/mediatek/mtk-cmdq.h
> @@ -152,6 +152,20 @@ int cmdq_pkt_poll(struct cmdq_pkt *pkt, u8 subsys,
>   */
>  int cmdq_pkt_poll_mask(struct cmdq_pkt *pkt, u8 subsys,
>  u16 offset, u32 value, u32 mask);
> +
> +/**
> + * cmdq_pkt_assign() - Append logic assign command to the CMDQ packet, ask 
> GCE
> + *  to execute an instruction that set a constant value into
> + *  internal register and use as value, mask or address in
> + *  read/write instruction.
> + * @pkt: the CMDQ packet
> + * @reg_idx: the CMDQ internal register ID
> + * @value:   the specified value
> + *
> + * Return: 0 for success; else the error code is returned
> + */
> +int cmdq_pkt_assign(struct cmdq_pkt *pkt, u16 reg_idx, u32 value);
> +
>  /**
>   * cmdq_pkt_flush_async() - trigger CMDQ to asynchronously execute the CMDQ
>   *  packet and call back at the end of done packet
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v1 03/11] soc: mediatek: cmdq: add write_s function

[Matthias Brugger]

On 21/06/2020 16:18, Dennis YC Hsieh wrote:
> add write_s function in cmdq helper functions which
> writes value contains in internal register to address
> with large dma access support.
> 
> Signed-off-by: Dennis YC Hsieh 
> ---
>  drivers/soc/mediatek/mtk-cmdq-helper.c   |   19 +++
>  include/linux/mailbox/mtk-cmdq-mailbox.h |1 +
>  include/linux/soc/mediatek/mtk-cmdq.h|   19 +++
>  3 files changed, 39 insertions(+)
> 
> diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c 
> b/drivers/soc/mediatek/mtk-cmdq-helper.c
> index bf32e3b2ca6c..817a5a97dbe5 100644
> --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> @@ -18,6 +18,10 @@ struct cmdq_instruction {
>   union {
>   u32 value;
>   u32 mask;
> + struct {
> + u16 arg_c;
> + u16 src_reg;
> + };
>   };
>   union {
>   u16 offset;
> @@ -222,6 +226,21 @@ int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u8 subsys,
>  }
>  EXPORT_SYMBOL(cmdq_pkt_write_mask);
>  
> +int cmdq_pkt_write_s(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
> +  u16 addr_low, u16 src_reg_idx)
> +{

Do I understand correctly that we use CMDQ_ADDR_HIGH(addr) and
CMDQ_ADDR_LOW(addr) to calculate in the client high_addr_reg_idx and addr_low
respectively?

In that case I think a better interface would be to pass the address and do the
high/low calculation in the cmdq_pkt_write_s

Regards,
Matthias

> + struct cmdq_instruction inst = {};
> +
> + inst.op = CMDQ_CODE_WRITE_S;
> + inst.src_t = CMDQ_REG_TYPE;
> + inst.sop = high_addr_reg_idx;
> + inst.offset = addr_low;
> + inst.src_reg = src_reg_idx;
> +
> + return cmdq_pkt_append_command(pkt, inst);
> +}
> +EXPORT_SYMBOL(cmdq_pkt_write_s);
> +
>  int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
>  {
>   struct cmdq_instruction inst = { {0} };
> diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h 
> b/include/linux/mailbox/mtk-cmdq-mailbox.h
> index 121c3bb6d3de..ee67dd3b86f5 100644
> --- a/include/linux/mailbox/mtk-cmdq-mailbox.h
> +++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
> @@ -59,6 +59,7 @@ enum cmdq_code {
>   CMDQ_CODE_JUMP = 0x10,
>   CMDQ_CODE_WFE = 0x20,
>   CMDQ_CODE_EOC = 0x40,
> + CMDQ_CODE_WRITE_S = 0x90,
>   CMDQ_CODE_LOGIC = 0xa0,
>  };
>  
> diff --git a/include/linux/soc/mediatek/mtk-cmdq.h 
> b/include/linux/soc/mediatek/mtk-cmdq.h
> index 83340211e1d3..e1c5a7549b4f 100644
> --- a/include/linux/soc/mediatek/mtk-cmdq.h
> +++ b/include/linux/soc/mediatek/mtk-cmdq.h
> @@ -12,6 +12,8 @@
>  #include 
>  
>  #define CMDQ_NO_TIMEOUT  0xu
> +#define CMDQ_ADDR_HIGH(addr) ((u32)(((addr) >> 16) & GENMASK(31, 0)))
> +#define CMDQ_ADDR_LOW(addr)  ((u16)(addr) | BIT(1))
>  
>  struct cmdq_pkt;
>  
> @@ -103,6 +105,23 @@ int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u8 subsys,
>   u16 offset, u32 value, u32 mask);
>  
>  /**
> + * cmdq_pkt_write_s() - append write_s command to the CMDQ packet
> + * @pkt: the CMDQ packet
> + * @high_addr_reg_idx:   internal register ID which contains high 
> address of pa
> + * @addr_low:low address of pa
> + * @src_reg_idx: the CMDQ internal register ID which cache source value
> + *
> + * Return: 0 for success; else the error code is returned
> + *
> + * Support write value to physical address without subsys. Use 
> CMDQ_ADDR_HIGH()
> + * to get high address and call cmdq_pkt_assign() to assign value into 
> internal
> + * reg. Also use CMDQ_ADDR_LOW() to get low address for addr_low parameter 
> when
> + * call to this function.
> + */
> +int cmdq_pkt_write_s(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
> +  u16 addr_low, u16 src_reg_idx);
> +
> +/**
>   * cmdq_pkt_wfe() - append wait for event command to the CMDQ packet
>   * @pkt: the CMDQ packet
>   * @event:   the desired event type to "wait and CLEAR"
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC PATCH 2/2] MAINTAINERS: Add maintainer for hyperv video device

[Deepak Rawat]

Maintainer for hyperv synthetic video device.

Signed-off-by: Deepak Rawat 
---
 MAINTAINERS | 8 
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index f437f42b73ad..102f734b99bd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5316,6 +5316,14 @@ T:   git git://anongit.freedesktop.org/drm/drm-misc
 F: Documentation/devicetree/bindings/display/himax,hx8357d.txt
 F: drivers/gpu/drm/tiny/hx8357d.c
 
+DRM DRIVER FOR HYPERV SYNTHETIC VIDEO DEVICE
+M: Deepak Rawat 
+L: linux-hyp...@vger.kernel.org
+L: dri-devel@lists.freedesktop.org
+S: Maintained
+T: git git://anongit.freedesktop.org/drm/drm-misc
+F: drivers/gpu/drm/tiny/hyperv_drm.c
+
 DRM DRIVER FOR ILITEK ILI9225 PANELS
 M: David Lechner 
 S: Maintained
-- 
2.27.0

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

[RFC PATCH 0/2] DRM driver for hyper-v synthetic video device

[Deepak Rawat]

Hi All,

First draft of DRM driver for hyper-v synthetic video device. This synthetic
device is already supported by hyper-v and a corresponding framebuffer driver
exist at drivers/video/fbdev/hyperv_fb.c. With this patch, just reworked the
framebuffer driver into DRM, in doing so got mode-setting support. The code is
similar to cirrus DRM driver, using simple display pipe and shmem backed
GEM objects.

The device support more features like hardware cursor, EDID, multiple dirty
regions, etc, which were not supported with framebuffer driver. The plan is to
add support for those in future iteration. Wanted to get initial feedback and
discuss cursor support with simple kms helper. Is there any value to add cursor
support to drm_simple_kms_helper.c so that others can use it, or should I just
add cursor plane as device private? I believe we can still keep this driver
in drm/tiny?

For testing, ran GNOME and Weston with current changes in a Linux VM on
Windows 10 with hyper-v enabled.

Thanks,
Deepak

Deepak Rawat (2):
  drm/hyperv: Add DRM driver for hyperv synthetic video device
  MAINTAINERS: Add maintainer for hyperv video device

 MAINTAINERS   |8 +
 drivers/gpu/drm/tiny/Kconfig  |9 +
 drivers/gpu/drm/tiny/Makefile |1 +
 drivers/gpu/drm/tiny/hyperv_drm.c | 1007 +
 4 files changed, 1025 insertions(+)
 create mode 100644 drivers/gpu/drm/tiny/hyperv_drm.c

-- 
2.27.0

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

[RFC PATCH 1/2] drm/hyperv: Add DRM driver for hyperv synthetic video device

[Deepak Rawat]

DRM driver for hyperv synthetic video device, based on hyperv_fb
framebuffer driver. Also added config option "DRM_HYPERV" to enabled
this driver.

Signed-off-by: Deepak Rawat 
---
 drivers/gpu/drm/tiny/Kconfig  |9 +
 drivers/gpu/drm/tiny/Makefile |1 +
 drivers/gpu/drm/tiny/hyperv_drm.c | 1007 +
 3 files changed, 1017 insertions(+)
 create mode 100644 drivers/gpu/drm/tiny/hyperv_drm.c

diff --git a/drivers/gpu/drm/tiny/Kconfig b/drivers/gpu/drm/tiny/Kconfig
index 2b6414f0fa75..e6d53e60a9c2 100644
--- a/drivers/gpu/drm/tiny/Kconfig
+++ b/drivers/gpu/drm/tiny/Kconfig
@@ -28,6 +28,15 @@ config DRM_GM12U320
 This is a KMS driver for projectors which use the GM12U320 chipset
 for video transfer over USB2/3, such as the Acer C120 mini projector.
 
+config DRM_HYPERV
+   tristate "DRM Support for hyperv synthetic video device"
+   depends on DRM && PCI && MMU && HYPERV
+   select DRM_KMS_HELPER
+   select DRM_GEM_SHMEM_HELPER
+   help
+This is a KMS driver for for hyperv synthetic video device.
+If M is selected the module will be called hyperv_drm.
+
 config TINYDRM_HX8357D
tristate "DRM support for HX8357D display panels"
depends on DRM && SPI
diff --git a/drivers/gpu/drm/tiny/Makefile b/drivers/gpu/drm/tiny/Makefile
index 6ae4e9e5a35f..837cb2c2637e 100644
--- a/drivers/gpu/drm/tiny/Makefile
+++ b/drivers/gpu/drm/tiny/Makefile
@@ -2,6 +2,7 @@
 
 obj-$(CONFIG_DRM_CIRRUS_QEMU)  += cirrus.o
 obj-$(CONFIG_DRM_GM12U320) += gm12u320.o
+obj-$(CONFIG_DRM_HYPERV)   += hyperv_drm.o
 obj-$(CONFIG_TINYDRM_HX8357D)  += hx8357d.o
 obj-$(CONFIG_TINYDRM_ILI9225)  += ili9225.o
 obj-$(CONFIG_TINYDRM_ILI9341)  += ili9341.o
diff --git a/drivers/gpu/drm/tiny/hyperv_drm.c 
b/drivers/gpu/drm/tiny/hyperv_drm.c
new file mode 100644
index ..3d020586056e
--- /dev/null
+++ b/drivers/gpu/drm/tiny/hyperv_drm.c
@@ -0,0 +1,1007 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2012-2020 Microsoft
+ *
+ * Authors:
+ * Deepak Rawat 
+ *
+ * Portions of this code is derived from hyperv_fb.c
+ * drivers/video/fbdev/hyperv_fb.c - framebuffer driver for hyperv synthetic
+ * video device.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DRIVER_NAME "hyperv_drm"
+#define DRIVER_DESC "DRM driver for hyperv synthetic video device"
+#define DRIVER_DATE "2020"
+#define DRIVER_MAJOR 1
+#define DRIVER_MINOR 0
+
+#define VMBUS_MAX_PACKET_SIZE 0x4000
+#define VMBUS_RING_BUFSIZE (256 * 1024)
+#define VMBUS_VSP_TIMEOUT (10 * HZ)
+
+#define PCI_VENDOR_ID_MICROSOFT 0x1414
+#define PCI_DEVICE_ID_HYPERV_VIDEO 0x5353
+
+struct hyperv_device {
+   /* drm */
+   struct drm_device dev;
+   struct drm_simple_display_pipe pipe;
+   struct drm_connector connector;
+
+   /* mode */
+   u32 screen_width_max;
+   u32 screen_height_max;
+   u32 preferred_width;
+   u32 preferred_height;
+   u32 screen_depth;
+
+   /* hw */
+   void __iomem *vram;
+   unsigned long fb_base;
+   unsigned long fb_size;
+   struct completion wait;
+   u32 synthvid_version;
+   u32 mmio_megabytes;
+   bool init_done;
+
+   u8 init_buf[VMBUS_MAX_PACKET_SIZE];
+   u8 recv_buf[VMBUS_MAX_PACKET_SIZE];
+
+   struct hv_device *hdev;
+};
+
+#define to_hv(_dev) container_of(_dev, struct hyperv_device, dev)
+
+/* -- */
+/* Hyper-V Synthetic Video Protocol   */
+
+#define SYNTHVID_VERSION(major, minor) ((minor) << 16 | (major))
+#define SYNTHVID_VER_GET_MAJOR(ver) (ver & 0x)
+#define SYNTHVID_VER_GET_MINOR(ver) ((ver & 0x) >> 16)
+#define SYNTHVID_VERSION_WIN7 SYNTHVID_VERSION(3, 0)
+#define SYNTHVID_VERSION_WIN8 SYNTHVID_VERSION(3, 2)
+#define SYNTHVID_VERSION_WIN10 SYNTHVID_VERSION(3, 5)
+
+#define SYNTHVID_DEPTH_WIN7 16
+#define SYNTHVID_DEPTH_WIN8 32
+#define SYNTHVID_FB_SIZE_WIN7 (4 * 1024 * 1024)
+#define SYNTHVID_FB_SIZE_WIN8 (8 * 1024 * 1024)
+#define SYNTHVID_WIDTH_MAX_WIN7 1600
+#define SYNTHVID_HEIGHT_MAX_WIN7 1200
+
+enum pipe_msg_type {
+   PIPE_MSG_INVALID,
+   PIPE_MSG_DATA,
+   PIPE_MSG_MAX
+};
+
+enum synthvid_msg_type {
+   SYNTHVID_ERROR  = 0,
+   SYNTHVID_VERSION_REQUEST= 1,
+   SYNTHVID_VERSION_RESPONSE   = 2,
+   SYNTHVID_VRAM_LOCATION  = 3,
+   SYNTHVID_VRAM_LOCATION_ACK  = 4,
+   SYNTHVID_SITUATION_UPDATE   = 5,
+   SYNTHVID_SITUATION_UPDATE_ACK   = 6,
+   SYNTHVID_POINTER_POSITION   = 7,
+   SYNTHVID_POINTER_SHAPE  = 8,
+   SYNTHVID_FEATURE_CHANGE = 9,
+   SYNTHVID_DIRT   

Re: [PATCH v1 08/11] soc: mediatek: cmdq: export finalize function

[Matthias Brugger]

On 21/06/2020 16:18, Dennis YC Hsieh wrote:
> Export finalize function to client which helps append eoc and jump
> command to pkt. Let client decide call finalize or not.
> 
> Signed-off-by: Dennis YC Hsieh 
> Reviewed-by: CK Hu 
> Acked-by: Chun-Kuang Hu 
> ---
>  drivers/gpu/drm/mediatek/mtk_drm_crtc.c |1 +
>  drivers/soc/mediatek/mtk-cmdq-helper.c  |7 ++-
>  include/linux/soc/mediatek/mtk-cmdq.h   |8 
>  3 files changed, 11 insertions(+), 5 deletions(-)
> 


Applied to v5.8-next/soc

Thanks!

> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index 0dfcd1787e65..7daaabc26eb1 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -490,6 +490,7 @@ static void mtk_drm_crtc_hw_config(struct mtk_drm_crtc 
> *mtk_crtc)
>   cmdq_pkt_clear_event(cmdq_handle, mtk_crtc->cmdq_event);
>   cmdq_pkt_wfe(cmdq_handle, mtk_crtc->cmdq_event);
>   mtk_crtc_ddp_config(crtc, cmdq_handle);
> + cmdq_pkt_finalize(cmdq_handle);
>   cmdq_pkt_flush_async(cmdq_handle, ddp_cmdq_cb, cmdq_handle);
>   }
>  #endif
> diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c 
> b/drivers/soc/mediatek/mtk-cmdq-helper.c
> index e372ae065240..248945108a36 100644
> --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> @@ -391,7 +391,7 @@ int cmdq_pkt_assign(struct cmdq_pkt *pkt, u16 reg_idx, 
> u32 value)
>  }
>  EXPORT_SYMBOL(cmdq_pkt_assign);
>  
> -static int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
> +int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
>  {
>   struct cmdq_instruction inst = { {0} };
>   int err;
> @@ -411,6 +411,7 @@ static int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
>  
>   return err;
>  }
> +EXPORT_SYMBOL(cmdq_pkt_finalize);
>  
>  static void cmdq_pkt_flush_async_cb(struct cmdq_cb_data data)
>  {
> @@ -445,10 +446,6 @@ int cmdq_pkt_flush_async(struct cmdq_pkt *pkt, 
> cmdq_async_flush_cb cb,
>   unsigned long flags = 0;
>   struct cmdq_client *client = (struct cmdq_client *)pkt->cl;
>  
> - err = cmdq_pkt_finalize(pkt);
> - if (err < 0)
> - return err;
> -
>   pkt->cb.cb = cb;
>   pkt->cb.data = data;
>   pkt->async_cb.cb = cmdq_pkt_flush_async_cb;
> diff --git a/include/linux/soc/mediatek/mtk-cmdq.h 
> b/include/linux/soc/mediatek/mtk-cmdq.h
> index 6e8caacedc80..eac1405e4872 100644
> --- a/include/linux/soc/mediatek/mtk-cmdq.h
> +++ b/include/linux/soc/mediatek/mtk-cmdq.h
> @@ -244,6 +244,14 @@ int cmdq_pkt_poll_mask(struct cmdq_pkt *pkt, u8 subsys,
>  int cmdq_pkt_assign(struct cmdq_pkt *pkt, u16 reg_idx, u32 value);
>  
>  /**
> + * cmdq_pkt_finalize() - Append EOC and jump command to pkt.
> + * @pkt: the CMDQ packet
> + *
> + * Return: 0 for success; else the error code is returned
> + */
> +int cmdq_pkt_finalize(struct cmdq_pkt *pkt);
> +
> +/**
>   * cmdq_pkt_flush_async() - trigger CMDQ to asynchronously execute the CMDQ
>   *  packet and call back at the end of done packet
>   * @pkt: the CMDQ packet
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v1 10/11] soc: mediatek: cmdq: add clear option in cmdq_pkt_wfe api

[Matthias Brugger]

On 21/06/2020 16:18, Dennis YC Hsieh wrote:
> Add clear parameter to let client decide if
> event should be clear to 0 after GCE receive it.
> 
> Signed-off-by: Dennis YC Hsieh 
> Reviewed-by: CK Hu 
> ---
>  drivers/gpu/drm/mediatek/mtk_drm_crtc.c  |2 +-
>  drivers/soc/mediatek/mtk-cmdq-helper.c   |5 +++--
>  include/linux/mailbox/mtk-cmdq-mailbox.h |3 +--
>  include/linux/soc/mediatek/mtk-cmdq.h|5 +++--
>  4 files changed, 8 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index 7daaabc26eb1..a065b3a412cf 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -488,7 +488,7 @@ static void mtk_drm_crtc_hw_config(struct mtk_drm_crtc 
> *mtk_crtc)
>   if (mtk_crtc->cmdq_client) {
>   cmdq_handle = cmdq_pkt_create(mtk_crtc->cmdq_client, PAGE_SIZE);
>   cmdq_pkt_clear_event(cmdq_handle, mtk_crtc->cmdq_event);
> - cmdq_pkt_wfe(cmdq_handle, mtk_crtc->cmdq_event);
> + cmdq_pkt_wfe(cmdq_handle, mtk_crtc->cmdq_event, false);

This does not set CMDQ_WFE_UPDATE while the old code did. Is this a bug fix or a
bug in the code?
If it's a fix, please provide a fixes tag.

Thanks,
Matthias

>   mtk_crtc_ddp_config(crtc, cmdq_handle);
>   cmdq_pkt_finalize(cmdq_handle);
>   cmdq_pkt_flush_async(cmdq_handle, ddp_cmdq_cb, cmdq_handle);
> diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c 
> b/drivers/soc/mediatek/mtk-cmdq-helper.c
> index 009f86ae72c6..13f78c9b5901 100644
> --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> @@ -315,15 +315,16 @@ int cmdq_pkt_write_s_mask_value(struct cmdq_pkt *pkt, 
> u8 high_addr_reg_idx,
>  }
>  EXPORT_SYMBOL(cmdq_pkt_write_s_mask_value);
>  
> -int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
> +int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event, bool clear)
>  {
>   struct cmdq_instruction inst = { {0} };
> + u32 clear_option = clear ? CMDQ_WFE_UPDATE : 0;
>  
>   if (event >= CMDQ_MAX_EVENT)
>   return -EINVAL;
>  
>   inst.op = CMDQ_CODE_WFE;
> - inst.value = CMDQ_WFE_OPTION;
> + inst.value = CMDQ_WFE_OPTION | clear_option;
>   inst.event = event;
>  
>   return cmdq_pkt_append_command(pkt, inst);
> diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h 
> b/include/linux/mailbox/mtk-cmdq-mailbox.h
> index 3f6bc0dfd5da..42d2a30e6a70 100644
> --- a/include/linux/mailbox/mtk-cmdq-mailbox.h
> +++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
> @@ -27,8 +27,7 @@
>   * bit 16-27: update value
>   * bit 31: 1 - update, 0 - no update
>   */
> -#define CMDQ_WFE_OPTION  (CMDQ_WFE_UPDATE | 
> CMDQ_WFE_WAIT | \
> - CMDQ_WFE_WAIT_VALUE)
> +#define CMDQ_WFE_OPTION  (CMDQ_WFE_WAIT | 
> CMDQ_WFE_WAIT_VALUE)
>  
>  /** cmdq event maximum */
>  #define CMDQ_MAX_EVENT   0x3ff
> diff --git a/include/linux/soc/mediatek/mtk-cmdq.h 
> b/include/linux/soc/mediatek/mtk-cmdq.h
> index 18364d81e8f7..4b5f5d154bad 100644
> --- a/include/linux/soc/mediatek/mtk-cmdq.h
> +++ b/include/linux/soc/mediatek/mtk-cmdq.h
> @@ -182,11 +182,12 @@ int cmdq_pkt_write_s_mask_value(struct cmdq_pkt *pkt, 
> u8 high_addr_reg_idx,
>  /**
>   * cmdq_pkt_wfe() - append wait for event command to the CMDQ packet
>   * @pkt: the CMDQ packet
> - * @event:   the desired event type to "wait and CLEAR"
> + * @event:   the desired event type to wait
> + * @clear:   clear event or not after event arrive
>   *
>   * Return: 0 for success; else the error code is returned
>   */
> -int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event);
> +int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event, bool clear);
>  
>  /**
>   * cmdq_pkt_clear_event() - append clear event command to the CMDQ packet
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 5/8] drm/amdgpu: Refactor sysfs removal

[Greg KH]

On Mon, Jun 22, 2020 at 11:51:24AM +0200, Daniel Vetter wrote:
> On Sun, Jun 21, 2020 at 02:03:05AM -0400, Andrey Grodzovsky wrote:
> > Track sysfs files in a list so they all can be removed during pci remove
> > since otherwise their removal after that causes crash because parent
> > folder was already removed during pci remove.

Huh?  That should not happen, do you have a backtrace of that crash?

> > Signed-off-by: Andrey Grodzovsky 
> 
> Uh I thought sysfs just gets yanked completely. Please check with Greg KH
> whether hand-rolling all this really is the right solution here ... Feels
> very wrong. I thought this was all supposed to work by adding attributes
> before publishing the sysfs node, and then letting sysfs clean up
> everything. Not by cleaning up manually yourself.

Yes, that is supposed to be the correct thing to do.

> 
> Adding Greg for an authoritative answer.
> -Daniel
> 
> > ---
> >  drivers/gpu/drm/amd/amdgpu/amdgpu.h  | 13 +++
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c |  7 +-
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c   | 35 
> > 
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c  | 12 ++
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c  |  8 ++-
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 17 --
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 13 ++-
> >  drivers/gpu/drm/amd/amdgpu/df_v3_6.c | 10 +---
> >  8 files changed, 99 insertions(+), 16 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > index 604a681..ba3775f 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > @@ -726,6 +726,15 @@ struct amd_powerplay {
> >  
> >  #define AMDGPU_RESET_MAGIC_NUM 64
> >  #define AMDGPU_MAX_DF_PERFMONS 4
> > +
> > +struct amdgpu_sysfs_list_node {
> > +   struct list_head head;
> > +   struct device_attribute *attr;
> > +};

You know we have lists of attributes already, called attribute groups,
if you really wanted to do something like this.  But, I don't think so.

Either way, don't hand-roll your own stuff that the driver core has
provided for you for a decade or more, that's just foolish :)

> > +
> > +#define AMDGPU_DEVICE_ATTR_LIST_NODE(_attr) \
> > +   struct amdgpu_sysfs_list_node dev_attr_handle_##_attr = {.attr = 
> > &dev_attr_##_attr}
> > +
> >  struct amdgpu_device {
> > struct device   *dev;
> > struct drm_device   *ddev;
> > @@ -992,6 +1001,10 @@ struct amdgpu_device {
> > charproduct_number[16];
> > charproduct_name[32];
> > charserial[16];
> > +
> > +   struct list_head sysfs_files_list;
> > +   struct mutex sysfs_files_list_lock;
> > +
> >  };
> >  
> >  static inline struct amdgpu_device *amdgpu_ttm_adev(struct ttm_bo_device 
> > *bdev)
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c 
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
> > index fdd52d8..c1549ee 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
> > @@ -1950,8 +1950,10 @@ static ssize_t 
> > amdgpu_atombios_get_vbios_version(struct device *dev,
> > return snprintf(buf, PAGE_SIZE, "%s\n", ctx->vbios_version);
> >  }
> >  
> > +
> >  static DEVICE_ATTR(vbios_version, 0444, amdgpu_atombios_get_vbios_version,
> >NULL);
> > +static AMDGPU_DEVICE_ATTR_LIST_NODE(vbios_version);
> >  
> >  /**
> >   * amdgpu_atombios_fini - free the driver info and callbacks for atombios
> > @@ -1972,7 +1974,6 @@ void amdgpu_atombios_fini(struct amdgpu_device *adev)
> > adev->mode_info.atom_context = NULL;
> > kfree(adev->mode_info.atom_card_info);
> > adev->mode_info.atom_card_info = NULL;
> > -   device_remove_file(adev->dev, &dev_attr_vbios_version);
> >  }
> >  
> >  /**
> > @@ -2038,6 +2039,10 @@ int amdgpu_atombios_init(struct amdgpu_device *adev)
> > return ret;
> > }
> >  
> > +   mutex_lock(&adev->sysfs_files_list_lock);
> > +   list_add_tail(&dev_attr_handle_vbios_version.head, 
> > &adev->sysfs_files_list);
> > +   mutex_unlock(&adev->sysfs_files_list_lock);
> > +
> > return 0;
> >  }
> >  
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > index e7b9065..3173046 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > @@ -2928,6 +2928,12 @@ static const struct attribute 
> > *amdgpu_dev_attributes[] = {
> > NULL
> >  };
> >  
> > +static AMDGPU_DEVICE_ATTR_LIST_NODE(product_name);
> > +static AMDGPU_DEVICE_ATTR_LIST_NODE(product_number);
> > +static AMDGPU_DEVICE_ATTR_LIST_NODE(serial_number);
> > +static AMDGPU_DEVICE_ATTR_LIST_NODE(pcie_replay_count);
> > +
> > +
> >  /**
> >   * amdgpu_device_init - initiali

Re: [PATCH v1 11/11] soc: mediatek: cmdq: add set event function

[Matthias Brugger]

On 21/06/2020 16:18, Dennis YC Hsieh wrote:
> Add set event function in cmdq helper functions to set specific event.
> 
> Signed-off-by: Dennis YC Hsieh 
> ---
>  drivers/soc/mediatek/mtk-cmdq-helper.c   |   15 +++
>  include/linux/mailbox/mtk-cmdq-mailbox.h |1 +
>  include/linux/soc/mediatek/mtk-cmdq.h|9 +
>  3 files changed, 25 insertions(+)
> 

Applied to v5.8-next/soc

Thanks!

> diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c 
> b/drivers/soc/mediatek/mtk-cmdq-helper.c
> index 13f78c9b5901..e6133a42d229 100644
> --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> @@ -346,6 +346,21 @@ int cmdq_pkt_clear_event(struct cmdq_pkt *pkt, u16 event)
>  }
>  EXPORT_SYMBOL(cmdq_pkt_clear_event);
>  
> +int cmdq_pkt_set_event(struct cmdq_pkt *pkt, u16 event)
> +{
> + struct cmdq_instruction inst = {};
> +
> + if (event >= CMDQ_MAX_EVENT)
> + return -EINVAL;
> +
> + inst.op = CMDQ_CODE_WFE;
> + inst.value = CMDQ_WFE_UPDATE | CMDQ_WFE_UPDATE_VALUE;
> + inst.event = event;
> +
> + return cmdq_pkt_append_command(pkt, inst);
> +}
> +EXPORT_SYMBOL(cmdq_pkt_set_event);
> +
>  int cmdq_pkt_poll(struct cmdq_pkt *pkt, u8 subsys,
> u16 offset, u32 value)
>  {
> diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h 
> b/include/linux/mailbox/mtk-cmdq-mailbox.h
> index 42d2a30e6a70..ba2d811183a9 100644
> --- a/include/linux/mailbox/mtk-cmdq-mailbox.h
> +++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
> @@ -17,6 +17,7 @@
>  #define CMDQ_JUMP_PASS   CMDQ_INST_SIZE
>  
>  #define CMDQ_WFE_UPDATE  BIT(31)
> +#define CMDQ_WFE_UPDATE_VALUEBIT(16)
>  #define CMDQ_WFE_WAITBIT(15)
>  #define CMDQ_WFE_WAIT_VALUE  0x1
>  
> diff --git a/include/linux/soc/mediatek/mtk-cmdq.h 
> b/include/linux/soc/mediatek/mtk-cmdq.h
> index 4b5f5d154bad..960704d75994 100644
> --- a/include/linux/soc/mediatek/mtk-cmdq.h
> +++ b/include/linux/soc/mediatek/mtk-cmdq.h
> @@ -199,6 +199,15 @@ int cmdq_pkt_write_s_mask_value(struct cmdq_pkt *pkt, u8 
> high_addr_reg_idx,
>  int cmdq_pkt_clear_event(struct cmdq_pkt *pkt, u16 event);
>  
>  /**
> + * cmdq_pkt_set_event() - append set event command to the CMDQ packet
> + * @pkt: the CMDQ packet
> + * @event:   the desired event to be set
> + *
> + * Return: 0 for success; else the error code is returned
> + */
> +int cmdq_pkt_set_event(struct cmdq_pkt *pkt, u16 event);
> +
> +/**
>   * cmdq_pkt_poll() - Append polling command to the CMDQ packet, ask GCE to
>   *execute an instruction that wait for a specified
>   *hardware register to check for the value w/o mask.
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH v2] dmabuf: use spinlock to access dmabuf->name

[Ruhl, Michael J]

>-Original Message-
>From: charante=codeaurora@mg.codeaurora.org
> On Behalf Of Charan Teja
>Kalla
>Sent: Monday, June 22, 2020 5:26 AM
>To: Ruhl, Michael J ; Sumit Semwal
>; david.lai...@aculab.com; open list:DMA
>BUFFER SHARING FRAMEWORK ; DRI mailing
>list 
>Cc: Linaro MM SIG ; LKML ker...@vger.kernel.org>
>Subject: Re: [PATCH v2] dmabuf: use spinlock to access dmabuf->name
>
>Hello Mike,
>
>On 6/19/2020 7:11 PM, Ruhl, Michael J wrote:
>>> -Original Message-
>>> From: charante=codeaurora@mg.codeaurora.org
>>>  On Behalf Of Charan
>Teja
>>> Kalla
>>> Sent: Friday, June 19, 2020 7:57 AM
>>> To: Sumit Semwal ; Ruhl, Michael J
>>> ; david.lai...@aculab.com; open list:DMA
>>> BUFFER SHARING FRAMEWORK ; DRI
>mailing
>>> list 
>>> Cc: Linaro MM SIG ; LKML >> ker...@vger.kernel.org>
>>> Subject: [PATCH v2] dmabuf: use spinlock to access dmabuf->name
>>>
>>> There exists a sleep-while-atomic bug while accessing the dmabuf->name
>>> under mutex in the dmabuffs_dname(). This is caused from the SELinux
>>> permissions checks on a process where it tries to validate the inherited
>>> files from fork() by traversing them through iterate_fd() (which
>>> traverse files under spin_lock) and call
>>> match_file(security/selinux/hooks.c) where the permission checks
>happen.
>>> This audit information is logged using dump_common_audit_data() where
>it
>>> calls d_path() to get the file path name. If the file check happen on
>>> the dmabuf's fd, then it ends up in ->dmabuffs_dname() and use mutex to
>>> access dmabuf->name. The flow will be like below:
>>> flush_unauthorized_files()
>>>  iterate_fd()
>>>spin_lock() --> Start of the atomic section.
>>>  match_file()
>>>file_has_perm()
>>>  avc_has_perm()
>>>avc_audit()
>>>  slow_avc_audit()
>>> common_lsm_audit()
>>>   dump_common_audit_data()
>>> audit_log_d_path()
>>>   d_path()
>>>dmabuffs_dname()
>>>  mutex_lock()--> Sleep while atomic.
>>>
>>> Call trace captured (on 4.19 kernels) is below:
>>> ___might_sleep+0x204/0x208
>>> __might_sleep+0x50/0x88
>>> __mutex_lock_common+0x5c/0x1068
>>> __mutex_lock_common+0x5c/0x1068
>>> mutex_lock_nested+0x40/0x50
>>> dmabuffs_dname+0xa0/0x170
>>> d_path+0x84/0x290
>>> audit_log_d_path+0x74/0x130
>>> common_lsm_audit+0x334/0x6e8
>>> slow_avc_audit+0xb8/0xf8
>>> avc_has_perm+0x154/0x218
>>> file_has_perm+0x70/0x180
>>> match_file+0x60/0x78
>>> iterate_fd+0x128/0x168
>>> selinux_bprm_committing_creds+0x178/0x248
>>> security_bprm_committing_creds+0x30/0x48
>>> install_exec_creds+0x1c/0x68
>>> load_elf_binary+0x3a4/0x14e0
>>> search_binary_handler+0xb0/0x1e0
>>>
>>> So, use spinlock to access dmabuf->name to avoid sleep-while-atomic.
>>>
>>> Cc:  [5.3+]
>>> Signed-off-by: Charan Teja Reddy 
>>> ---
>>>
>>> Changes in V2: Addressed review comments from Ruhl, Michael J
>>>
>>> Changes in V1: https://lore.kernel.org/patchwork/patch/1255055/
>>>
>>> drivers/dma-buf/dma-buf.c | 11 +++
>>> include/linux/dma-buf.h   |  1 +
>>> 2 files changed, 8 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
>>> index 01ce125..d81d298 100644
>>> --- a/drivers/dma-buf/dma-buf.c
>>> +++ b/drivers/dma-buf/dma-buf.c
>>> @@ -45,10 +45,10 @@ static char *dmabuffs_dname(struct dentry
>*dentry,
>>> char *buffer, int buflen)
>>> size_t ret = 0;
>>>
>>> dmabuf = dentry->d_fsdata;
>>> -   dma_resv_lock(dmabuf->resv, NULL);
>>> +   spin_lock(&dmabuf->name_lock);
>>> if (dmabuf->name)
>>> ret = strlcpy(name, dmabuf->name, DMA_BUF_NAME_LEN);
>>> -   dma_resv_unlock(dmabuf->resv);
>>> +   spin_unlock(&dmabuf->name_lock);
>>>
>>> return dynamic_dname(dentry, buffer, buflen, "/%s:%s",
>>>  dentry->d_name.name, ret > 0 ? name : "");
>>> @@ -341,8 +341,10 @@ static long dma_buf_set_name(struct dma_buf
>>> *dmabuf, const char __user *buf)
>>> kfree(name);
>>> goto out_unlock;
>>> }
>>> +   spin_lock(&dmabuf->name_lock);
>>> kfree(dmabuf->name);
>>> dmabuf->name = name;
>>> +   spin_unlock(&dmabuf->name_lock);
>>
>> While this code path is ok, I would have separated the protection of the
>> attachment list and the name manipulation.
>>
>> dma_resv_lock(resv)
>> if (!list_empty(attachment)
>>  ret = -EBUSY
>> dma_resv_unlock(resv)
>>
>> if (ret) {
>>  kfree(name)
>>  return ret;
>> }
>
>Is it that the name should be visible before importer attaches to the
>dmabuf,(using dma_buf_attach()), thus _buf_set_name() is under the
>_resv_lock() as well?

That is the name that was being freed in the error path of the lock block.
Alternatively:

dma_resv_lock(resv)
if (!list_empty(attachment) {
ret = -EBUSY
kfree(name)
}
dma_resv_unlock(resv)

if (ret)
return ret;

I was limiting what was happening in the lock block.

You have two dis

Re: [RFC PATCH 1/2] drm/hyperv: Add DRM driver for hyperv synthetic video device

[Gerd Hoffmann]

  Hi,

> +/* Should be done only once during init and resume */
> +static int synthvid_update_vram_location(struct hv_device *hdev,
> +   phys_addr_t vram_pp)
> +{
> + struct hyperv_device *hv = hv_get_drvdata(hdev);
> + struct synthvid_msg *msg = (struct synthvid_msg *)hv->init_buf;
> + unsigned long t;
> + int ret = 0;
> +
> + memset(msg, 0, sizeof(struct synthvid_msg));
> + msg->vid_hdr.type = SYNTHVID_VRAM_LOCATION;
> + msg->vid_hdr.size = sizeof(struct synthvid_msg_hdr) +
> + sizeof(struct synthvid_vram_location);
> + msg->vram.user_ctx = msg->vram.vram_gpa = vram_pp;
> + msg->vram.is_vram_gpa_specified = 1;
> + synthvid_send(hdev, msg);

That suggests it is possible to define multiple framebuffers in vram,
then pageflip by setting vram.vram_gpa.  If that is the case I'm
wondering whenever vram helpers are a better fit maybe?  You don't have
to blit each and every display update then.

FYI: cirrus goes the blit route because (a) the amount of vram is very
small so trying to store multiple framebuffers there is out of question,
and (b) cirrus converts formats on the fly to hide some hardware
oddities.

take care,
  Gerd

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

Re: [PATCH v2 1/8] drm: Add dummy page per device or GEM object

[Christian König]

Am 21.06.20 um 08:03 schrieb Andrey Grodzovsky:

Will be used to reroute CPU mapped BO's page faults once
device is removed.

Signed-off-by: Andrey Grodzovsky 
---
  drivers/gpu/drm/drm_file.c  |  8 
  drivers/gpu/drm/drm_prime.c | 10 ++
  include/drm/drm_file.h  |  2 ++
  include/drm/drm_gem.h   |  2 ++
  4 files changed, 22 insertions(+)

diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index c4c704e..67c0770 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -188,6 +188,12 @@ struct drm_file *drm_file_alloc(struct drm_minor *minor)
goto out_prime_destroy;
}
  
+	file->dummy_page = alloc_page(GFP_KERNEL | __GFP_ZERO);

+   if (!file->dummy_page) {
+   ret = -ENOMEM;
+   goto out_prime_destroy;
+   }
+
return file;
  
  out_prime_destroy:

@@ -284,6 +290,8 @@ void drm_file_free(struct drm_file *file)
if (dev->driver->postclose)
dev->driver->postclose(dev, file);
  
+	__free_page(file->dummy_page);

+
drm_prime_destroy_file_private(&file->prime);
  
  	WARN_ON(!list_empty(&file->event_list));

diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 1de2cde..c482e9c 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -335,6 +335,13 @@ int drm_gem_prime_fd_to_handle(struct drm_device *dev,
  
  	ret = drm_prime_add_buf_handle(&file_priv->prime,

dma_buf, *handle);
+
+   if (!ret) {
+   obj->dummy_page = alloc_page(GFP_KERNEL | __GFP_ZERO);
+   if (!obj->dummy_page)
+   ret = -ENOMEM;
+   }
+


While the per file case still looks acceptable this is a clear NAK since 
it will massively increase the memory needed for a prime exported object.


I think that this is quite overkill in the first place and for the hot 
unplug case we can just use the global dummy page as well.


Christian.


mutex_unlock(&file_priv->prime.lock);
if (ret)
goto fail;
@@ -1006,6 +1013,9 @@ void drm_prime_gem_destroy(struct drm_gem_object *obj, 
struct sg_table *sg)
dma_buf_unmap_attachment(attach, sg, DMA_BIDIRECTIONAL);
dma_buf = attach->dmabuf;
dma_buf_detach(attach->dmabuf, attach);
+
+   __free_page(obj->dummy_page);
+
/* remove the reference */
dma_buf_put(dma_buf);
  }
diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
index 19df802..349a658 100644
--- a/include/drm/drm_file.h
+++ b/include/drm/drm_file.h
@@ -335,6 +335,8 @@ struct drm_file {
 */
struct drm_prime_file_private prime;
  
+	struct page *dummy_page;

+
/* private: */
  #if IS_ENABLED(CONFIG_DRM_LEGACY)
unsigned long lock_count; /* DRI1 legacy lock count */
diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
index 0b37506..47460d1 100644
--- a/include/drm/drm_gem.h
+++ b/include/drm/drm_gem.h
@@ -310,6 +310,8 @@ struct drm_gem_object {
 *
 */
const struct drm_gem_object_funcs *funcs;
+
+   struct page *dummy_page;
  };
  
  /**


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

Re: [PATCH v2 5/8] drm/amdgpu: Refactor sysfs removal

[Christian König]

Am 21.06.20 um 08:03 schrieb Andrey Grodzovsky:

Track sysfs files in a list so they all can be removed during pci remove
since otherwise their removal after that causes crash because parent
folder was already removed during pci remove.


That looks extremely fishy to me.

It sounds like we just don't remove stuff in the right order.

Christian.



Signed-off-by: Andrey Grodzovsky 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu.h  | 13 +++
  drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c |  7 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c   | 35 
  drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c  | 12 ++
  drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c  |  8 ++-
  drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 17 --
  drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 13 ++-
  drivers/gpu/drm/amd/amdgpu/df_v3_6.c | 10 +---
  8 files changed, 99 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 604a681..ba3775f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -726,6 +726,15 @@ struct amd_powerplay {
  
  #define AMDGPU_RESET_MAGIC_NUM 64

  #define AMDGPU_MAX_DF_PERFMONS 4
+
+struct amdgpu_sysfs_list_node {
+   struct list_head head;
+   struct device_attribute *attr;
+};
+
+#define AMDGPU_DEVICE_ATTR_LIST_NODE(_attr) \
+   struct amdgpu_sysfs_list_node dev_attr_handle_##_attr = {.attr = 
&dev_attr_##_attr}
+
  struct amdgpu_device {
struct device   *dev;
struct drm_device   *ddev;
@@ -992,6 +1001,10 @@ struct amdgpu_device {
charproduct_number[16];
charproduct_name[32];
charserial[16];
+
+   struct list_head sysfs_files_list;
+   struct mutex sysfs_files_list_lock;
+
  };
  
  static inline struct amdgpu_device *amdgpu_ttm_adev(struct ttm_bo_device *bdev)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
index fdd52d8..c1549ee 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
@@ -1950,8 +1950,10 @@ static ssize_t amdgpu_atombios_get_vbios_version(struct 
device *dev,
return snprintf(buf, PAGE_SIZE, "%s\n", ctx->vbios_version);
  }
  
+

  static DEVICE_ATTR(vbios_version, 0444, amdgpu_atombios_get_vbios_version,
   NULL);
+static AMDGPU_DEVICE_ATTR_LIST_NODE(vbios_version);
  
  /**

   * amdgpu_atombios_fini - free the driver info and callbacks for atombios
@@ -1972,7 +1974,6 @@ void amdgpu_atombios_fini(struct amdgpu_device *adev)
adev->mode_info.atom_context = NULL;
kfree(adev->mode_info.atom_card_info);
adev->mode_info.atom_card_info = NULL;
-   device_remove_file(adev->dev, &dev_attr_vbios_version);
  }
  
  /**

@@ -2038,6 +2039,10 @@ int amdgpu_atombios_init(struct amdgpu_device *adev)
return ret;
}
  
+	mutex_lock(&adev->sysfs_files_list_lock);

+   list_add_tail(&dev_attr_handle_vbios_version.head, 
&adev->sysfs_files_list);
+   mutex_unlock(&adev->sysfs_files_list_lock);
+
return 0;
  }
  
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c

index e7b9065..3173046 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -2928,6 +2928,12 @@ static const struct attribute *amdgpu_dev_attributes[] = 
{
NULL
  };
  
+static AMDGPU_DEVICE_ATTR_LIST_NODE(product_name);

+static AMDGPU_DEVICE_ATTR_LIST_NODE(product_number);
+static AMDGPU_DEVICE_ATTR_LIST_NODE(serial_number);
+static AMDGPU_DEVICE_ATTR_LIST_NODE(pcie_replay_count);
+
+
  /**
   * amdgpu_device_init - initialize the driver
   *
@@ -3029,6 +3035,9 @@ int amdgpu_device_init(struct amdgpu_device *adev,
INIT_LIST_HEAD(&adev->shadow_list);
mutex_init(&adev->shadow_list_lock);
  
+	INIT_LIST_HEAD(&adev->sysfs_files_list);

+   mutex_init(&adev->sysfs_files_list_lock);
+
INIT_DELAYED_WORK(&adev->delayed_init_work,
  amdgpu_device_delayed_init_work_handler);
INIT_DELAYED_WORK(&adev->gfx.gfx_off_delay_work,
@@ -3281,6 +3290,13 @@ int amdgpu_device_init(struct amdgpu_device *adev,
if (r) {
dev_err(adev->dev, "Could not create amdgpu device attr\n");
return r;
+   } else {
+   mutex_lock(&adev->sysfs_files_list_lock);
+   list_add_tail(&dev_attr_handle_product_name.head, 
&adev->sysfs_files_list);
+   list_add_tail(&dev_attr_handle_product_number.head, 
&adev->sysfs_files_list);
+   list_add_tail(&dev_attr_handle_serial_number.head, 
&adev->sysfs_files_list);
+   list_add_tail(&dev_attr_handle_pcie_replay_count.hea

Re: [PATCH v7 04/36] drm: amdgpu: fix common struct sg_table related issues

[Christian König]

Am 19.06.20 um 12:36 schrieb Marek Szyprowski:

The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_map_sg().

struct sg_table is a common structure used for describing a non-contiguous
memory buffer, used commonly in the DRM and graphics subsystems. It
consists of a scatterlist with memory pages and DMA addresses (sgl entry),
as well as the number of scatterlist entries: CPU pages (orig_nents entry)
and DMA mapped pages (nents entry).

It turned out that it was a common mistake to misuse nents and orig_nents
entries, calling DMA-mapping functions with a wrong number of entries or
ignoring the number of mapped entries returned by the dma_map_sg()
function.

To avoid such issues, lets use a common dma-mapping wrappers operating
directly on the struct sg_table objects and use scatterlist page
iterators where possible. This, almost always, hides references to the
nents and orig_nents entries, making the code robust, easier to follow
and copy/paste safe.

Signed-off-by: Marek Szyprowski 
Reviewed-by: Christian König 


Any objection that we pick this one and the radeon up into our branches 
for upstreaming?


That should about clashes with other driver changes.

Thanks,
Christian.


---
  drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c  | 6 +++---
  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c  | 9 +++--
  drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 8 
  3 files changed, 10 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
index 43d8ed7dbd00..519ce4427fce 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
@@ -307,8 +307,8 @@ static struct sg_table *amdgpu_dma_buf_map(struct 
dma_buf_attachment *attach,
if (IS_ERR(sgt))
return sgt;
  
-		if (!dma_map_sg_attrs(attach->dev, sgt->sgl, sgt->nents, dir,

- DMA_ATTR_SKIP_CPU_SYNC))
+   if (dma_map_sgtable(attach->dev, sgt, dir,
+   DMA_ATTR_SKIP_CPU_SYNC))
goto error_free;
break;
  
@@ -349,7 +349,7 @@ static void amdgpu_dma_buf_unmap(struct dma_buf_attachment *attach,

struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
  
  	if (sgt->sgl->page_link) {

-   dma_unmap_sg(attach->dev, sgt->sgl, sgt->nents, dir);
+   dma_unmap_sgtable(attach->dev, sgt, dir, 0);
sg_free_table(sgt);
kfree(sgt);
} else {
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 5129a996e941..97fb73e5a6ae 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1025,7 +1025,6 @@ static int amdgpu_ttm_tt_pin_userptr(struct ttm_tt *ttm)
  {
struct amdgpu_device *adev = amdgpu_ttm_adev(ttm->bdev);
struct amdgpu_ttm_tt *gtt = (void *)ttm;
-   unsigned nents;
int r;
  
  	int write = !(gtt->userflags & AMDGPU_GEM_USERPTR_READONLY);

@@ -1040,9 +1039,8 @@ static int amdgpu_ttm_tt_pin_userptr(struct ttm_tt *ttm)
goto release_sg;
  
  	/* Map SG to device */

-   r = -ENOMEM;
-   nents = dma_map_sg(adev->dev, ttm->sg->sgl, ttm->sg->nents, direction);
-   if (nents == 0)
+   r = dma_map_sgtable(adev->dev, ttm->sg, direction, 0);
+   if (r)
goto release_sg;
  
  	/* convert SG to linear array of pages and dma addresses */

@@ -1073,8 +1071,7 @@ static void amdgpu_ttm_tt_unpin_userptr(struct ttm_tt 
*ttm)
return;
  
  	/* unmap the pages mapped to the device */

-   dma_unmap_sg(adev->dev, ttm->sg->sgl, ttm->sg->nents, direction);
-
+   dma_unmap_sgtable(adev->dev, ttm->sg, direction, 0);
sg_free_table(ttm->sg);
  
  #if IS_ENABLED(CONFIG_DRM_AMDGPU_USERPTR)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
index d399e5893170..c281aa13f5ec 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
@@ -477,11 +477,11 @@ int amdgpu_vram_mgr_alloc_sgt(struct amdgpu_device *adev,
if (r)
goto error_free;
  
-	for_each_sg((*sgt)->sgl, sg, num_entries, i)

+   for_each_sgtable_sg((*sgt), sg, i)
sg->length = 0;
  
  	node = mem->mm_node;

-   for_each_sg((*sgt)->sgl, sg, num_entries, i) {
+   for_each_sgtable_sg((*sgt), sg, i) {
phys_addr_t phys = (node->start << PAGE_SHIFT) +
adev->gmc.aper_base;
size_t size = node->size << PAGE_SHIFT;
@@ -501,7 +501,7 @@ int amdgpu_vram

[PATCH v4] drm/doc: device hot-unplug for userspace

[Pekka Paalanen]

From: Pekka Paalanen 

Set up the expectations on how hot-unplugging a DRM device should look like to
userspace.

Written by Daniel Vetter's request and largely based on his comments in IRC and
from https://lists.freedesktop.org/archives/dri-devel/2020-May/265484.html .

A related Wayland protocol change proposal is at
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/35

Signed-off-by: Pekka Paalanen 
Reviewed-by: Daniel Vetter 
Cc: Andrey Grodzovsky 
Cc: Dave Airlie 
Cc: Sean Paul 
Cc: Simon Ser 
Cc: Noralf Trønnes 
Cc: Ben Skeggs 
Cc: Christian König 
Cc: Harry Wentland 
Cc: Karol Herbst 

---

Harry and Christian, could one of you ack this on behalf of AMD
drivers?

Ben or Karol, could you ack on behalf of Nouveau?

Noralf, would this work for the tiny drivers etc.?

This is only about laying out plans for the future, not about what
drivers do today. We'd just like to be sure the goals are reasonable and
everyone is aware of the idea.

Thanks,
pq

v4:
- two typo fixes (Daniel)

v3:
- update ENODEV doc (Daniel)
- clarify existing vs. new mmaps (Andrey)
- split into KMS and render/cross sections (Andrey, Daniel)
- open() returns ENXIO (open(2) man page)
- ioctls may return ENODEV (Andrey, Daniel)
- new wayland-protocols MR

v2:
- mmap reads/writes undefined (Daniel)
- make render ioctl behaviour driver-specific (Daniel)
- restructure the mmap paragraphs (Daniel)
- chardev minor notes (Simon)
- open behaviour (Daniel)
- DRM leasing behaviour (Daniel)
- added links

Disclaimer: I am a userspace developer writing for other userspace developers.
I took some liberties in defining what should happen without knowing what is
actually possible or what existing drivers already implement.
---
 Documentation/gpu/drm-uapi.rst | 114 -
 1 file changed, 113 insertions(+), 1 deletion(-)

diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
index 56fec6ed1ad8..b2585ea6a83e 100644
--- a/Documentation/gpu/drm-uapi.rst
+++ b/Documentation/gpu/drm-uapi.rst
@@ -1,3 +1,5 @@
+.. Copyright 2020 DisplayLink (UK) Ltd.
+
 ===
 Userland interfaces
 ===
@@ -162,6 +164,116 @@ other hand, a driver requires shared state between 
clients which is
 visible to user-space and accessible beyond open-file boundaries, they
 cannot support render nodes.
 
+Device Hot-Unplug
+=
+
+.. note::
+   The following is the plan. Implementation is not there yet
+   (2020 May).
+
+Graphics devices (display and/or render) may be connected via USB (e.g.
+display adapters or docking stations) or Thunderbolt (e.g. eGPU). An end
+user is able to hot-unplug this kind of devices while they are being
+used, and expects that the very least the machine does not crash. Any
+damage from hot-unplugging a DRM device needs to be limited as much as
+possible and userspace must be given the chance to handle it if it wants
+to. Ideally, unplugging a DRM device still lets a desktop continue to
+run, but that is going to need explicit support throughout the whole
+graphics stack: from kernel and userspace drivers, through display
+servers, via window system protocols, and in applications and libraries.
+
+Other scenarios that should lead to the same are: unrecoverable GPU
+crash, PCI device disappearing off the bus, or forced unbind of a driver
+from the physical device.
+
+In other words, from userspace perspective everything needs to keep on
+working more or less, until userspace stops using the disappeared DRM
+device and closes it completely. Userspace will learn of the device
+disappearance from the device removed uevent, ioctls returning ENODEV
+(or driver-specific ioctls returning driver-specific things), or open()
+returning ENXIO.
+
+Only after userspace has closed all relevant DRM device and dmabuf file
+descriptors and removed all mmaps, the DRM driver can tear down its
+instance for the device that no longer exists. If the same physical
+device somehow comes back in the mean time, it shall be a new DRM
+device.
+
+Similar to PIDs, chardev minor numbers are not recycled immediately. A
+new DRM device always picks the next free minor number compared to the
+previous one allocated, and wraps around when minor numbers are
+exhausted.
+
+The goal raises at least the following requirements for the kernel and
+drivers.
+
+Requirements for KMS UAPI
+-
+
+- KMS connectors must change their status to disconnected.
+
+- Legacy modesets and pageflips, and atomic commits, both real and
+  TEST_ONLY, and any other ioctls either fail with ENODEV or fake
+  success.
+
+- Pending non-blocking KMS operations deliver the DRM events userspace
+  is expecting. This applies also to ioctls that faked success.
+
+- open() on a device node whose underlying device has disappeared will
+  fail with ENXIO.
+
+- Attempting to create a DRM lease on a disappeared DRM device will
+  fail with ENODEV. Existing DRM leases remain and work as listed

[Bug 207673] amdgpu/radeon: crash due to over temperature

[bugzilla-daemon]

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

phileimer (p...@jpmr.org) changed:

   What|Removed |Added

Summary|radeon: crash due to over   |amdgpu/radeon: crash due to
   |temperature |over temperature

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

[Bug 207673] amdgpu/radeon: crash due to over temperature

[bugzilla-daemon]

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

phileimer (p...@jpmr.org) changed:

   What|Removed |Added

 Kernel Version|5.6.x and previous  |5.6.x, 5.7.x

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

[Bug 207673] amdgpu/radeon: crash due to over temperature

[bugzilla-daemon]

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

--- Comment #3 from phileimer (p...@jpmr.org) ---
Created attachment 289807
  --> https://bugzilla.kernel.org/attachment.cgi?id=289807&action=edit
amdgpu: lower the temperature limit to avoid kernel crash

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

[Bug 207673] amdgpu/radeon: crash due to over temperature

[bugzilla-daemon]

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

--- Comment #4 from phileimer (p...@jpmr.org) ---
I modified my kernel configuration to use the new amdgpu driver for this SI
chip, instead of the legacy radeon.
The same problem occurs: to avoid frequent kernel crashes, I must apply a patch
to lower the maximum temperature allowed.

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

Re: [PATCH] drm/mediatek: check plane visibility in atomic_update

[Chun-Kuang Hu]

Hi, Hsin-Yi:

Hsin-Yi Wang  於 2020年6月22日 週一 下午1:32寫道：
>
> Disable the plane if it's not visible. Otherwise mtk_ovl_layer_config()
> would proceed with invalid plane and we may see vblank timeout.

Except the Fixes tag,

Reviewed-by: Chun-Kuang Hu 

>
> Signed-off-by: Hsin-Yi Wang 
> ---
>  drivers/gpu/drm/mediatek/mtk_drm_plane.c | 23 +--
>  1 file changed, 13 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> index c2bd683a87c8..74dc71c7f3b6 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> @@ -164,6 +164,16 @@ static int mtk_plane_atomic_check(struct drm_plane 
> *plane,
>true, true);
>  }
>
> +static void mtk_plane_atomic_disable(struct drm_plane *plane,
> +struct drm_plane_state *old_state)
> +{
> +   struct mtk_plane_state *state = to_mtk_plane_state(plane->state);
> +
> +   state->pending.enable = false;
> +   wmb(); /* Make sure the above parameter is set before update */
> +   state->pending.dirty = true;
> +}
> +
>  static void mtk_plane_atomic_update(struct drm_plane *plane,
> struct drm_plane_state *old_state)
>  {
> @@ -178,6 +188,9 @@ static void mtk_plane_atomic_update(struct drm_plane 
> *plane,
> if (!crtc || WARN_ON(!fb))
> return;
>
> +   if (!plane->state->visible)
> +   return mtk_plane_atomic_disable(plane, old_state);
> +
> gem = fb->obj[0];
> mtk_gem = to_mtk_gem_obj(gem);
> addr = mtk_gem->dma_addr;
> @@ -200,16 +213,6 @@ static void mtk_plane_atomic_update(struct drm_plane 
> *plane,
> state->pending.dirty = true;
>  }
>
> -static void mtk_plane_atomic_disable(struct drm_plane *plane,
> -struct drm_plane_state *old_state)
> -{
> -   struct mtk_plane_state *state = to_mtk_plane_state(plane->state);
> -
> -   state->pending.enable = false;
> -   wmb(); /* Make sure the above parameter is set before update */
> -   state->pending.dirty = true;
> -}
> -
>  static const struct drm_plane_helper_funcs mtk_plane_helper_funcs = {
> .prepare_fb = drm_gem_fb_prepare_fb,
> .atomic_check = mtk_plane_atomic_check,
> --
> 2.27.0.111.gc72c7da667-goog
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [RFC PATCH 2/2] drm: xlnx: driver for Xilinx DSI TX Subsystem

[Venkateshwar Rao Gannavarapu]

Hi Laurent,

Thanks for the comment.

>-Original Message-
>From: Laurent Pinchart 
>Sent: Wednesday, June 17, 2020 3:18 AM
>To: Venkateshwar Rao Gannavarapu 
>Cc: Hyun Kwon ; dri-devel@lists.freedesktop.org;
>airl...@linux.ie; dan...@ffwll.ch; linux-ker...@vger.kernel.org; Sandip Kothari
>; Vishal Sagar 
>Subject: Re: [RFC PATCH 2/2] drm: xlnx: driver for Xilinx DSI TX Subsystem
>
>Hi GVRao,
>
>Sorry for the delayed reply.
>
>On Tue, Jun 09, 2020 at 02:48:25AM +, Venkateshwar Rao Gannavarapu
>wrote:
>> Hi Laurent,
>>
>> Thanks for the review.
>> Please see my comments about D-PHY and bridge driver implementation.
>>
>> On Sunday, June 7, 2020 7:55 AM, Laurent Pinchart wrote:
>> > On Sun, May 31, 2020 at 05:41:50PM +, Venkateshwar Rao
>Gannavarapu wrote:
>> >> On Sunday, May 24, 2020 8:38 AM, Laurent Pinchart wrote:
>> >>> On Mon, May 04, 2020 at 11:43:48AM -0700, Hyun Kwon wrote:
>>  On Mon, 2020-04-20 at 14:20:56 -0700, Venkateshwar Rao Gannavarapu
>wrote:
>> > The Xilinx MIPI DSI Tx Subsystem soft IP is used to display
>> > video data from AXI-4 stream interface.
>> >
>> > It supports upto 4 lanes, optional register interface for the
>> > DPHY,
>> 
>>  I don't see the register interface for dphy support.
>> >>>
>> >>> I think the D-PHY should be supported through a PHY driver, as it
>> >>> seems to be shared between different subsystems.
>> >>
>> >> IP has the provision to read DPHY register for debug purpose only.
>> >> No programming of DPHY is required in subsystem.
>> >
>> > Do you know if this is the same D-PHY as used in the CSI2-RX subsystem ?
>>
>> Same D-PHY core has been used in MIPI CSI2 RXSS, but with different
>configuration.
>>
>> > multiple RGB color formats, command mode and video mode.
>> > This is a MIPI-DSI host driver and provides DSI bus for panels.
>> > This driver also helps to communicate with its panel using panel
>> > framework.
>> >
>> > Signed-off-by: Venkateshwar Rao Gannavarapu
>> > 
>> > ---
>> >  drivers/gpu/drm/xlnx/Kconfig|  11 +
>> >  drivers/gpu/drm/xlnx/Makefile   |   2 +
>> >  drivers/gpu/drm/xlnx/xlnx_dsi.c | 755
>> > 
>> >>>
>> >>> Daniel Vetter has recently expressed his opiion that bridge
>> >>> drivers should go to drivers/gpu/drm/bridge/. It would then be
>> >>> drivers/gpu/drm/bridge/xlnx/. I don't have a strong opinion myself.
>>
>> The DSI-TX subsystem IP block is not a bridge driver.
>> The DSI-TX subsystem IP block itself contains all the drm
>> encoder/connector functionality and it’s the last node in display pipe line.
>
>The DSI-TX subsystem IP block is indeed an encoder from a hardware point of
>view, but it's not necessarily the last block in the display pipeline. While 
>the
>output of the IP core goes of the the SoC, tt would be entirely feasible to
>connect it to a DP to HDMI bridge on the board, such as the ANX7737 ([1]) for
>instance. This is why we're pushing for all encoder (from a hardware point of
>view) drivers to be implemented as DRM bridge, in order to make them usable
>in different display pipelines, without hardcoding the assumption they will be
>the last encoder in the pipeline.

Thanks for the details.
I can understand it as SoC requirement where crtc is fixed, but as a FPGA 
product
encoder driver should work with any of crtc driver.  And I still not see bridge 
implementation as hard requirement.
Could you please explain what problem we face, if implemented as encoder driver.
>
>> I didn't see any hard
>> requirement to implement it into bridge driver and I see many DSI
>> drivers are implemented as encoder drivers.
>> Xilinx PL DRM encoder drivers are implemented in modular approach so
>> that they can work with any CRTC driver which handles the DMA calls.
>> So, at this stage we want to upstream as encoder driver only.
>>
>> >  3 files changed, 768 insertions(+)  create mode 100644
>> > drivers/gpu/drm/xlnx/xlnx_dsi.c
>
>[1] https://www.analogix.com/en/products/convertersbridges/anx7737
>
>--
>Regards,
>
>Laurent Pinchart

Regards,
GVRao
 

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