RE: [v8 3/3] drm/debug: Expose connector VRR monitor range via debugfs
> -Original Message-
> From: Navare, Manasi D
> Sent: Saturday, June 20, 2020 12:13 AM
> To: Modem, Bhanuprakash
> Cc: dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org
> Subject: Re: [v8 3/3] drm/debug: Expose connector VRR monitor range via
> debugfs
>
> Hi Bhanu,
>
> Thanks for the patch, functionality wise looks good. Have you tested this
> with kms_vrr IGT, do we see the vrr_range properly exposed?
[Bhanu]
Yes, the vrr_range is exposing properly. I have verified the debugfs node
manually and through IGT.
>
> Also please find some comments below
>
> On Sat, Jun 20, 2020 at 02:53:56AM +0530, Bhanuprakash Modem wrote:
> > [Why]
> > It's useful to know the min and max vrr range for IGT testing.
> >
> > [How]
> > Expose the min and max vfreq for the connector via a debugfs file
> > on the connector, "vrr_range".
> >
> > Example usage: cat /sys/kernel/debug/dri/0/DP-1/vrr_range
> >
> > v2:
> > * Fix the typo in max_vfreq (Manasi)
> > * Change the name of node to i915_vrr_info so we can add
> > other vrr info for more debug info (Manasi)
> > * Change the VRR capable to display Yes or No (Manasi)
> > * Fix indentation checkpatch errors (Manasi)
> > v3:
> > * Remove the unnecessary debug print (Manasi)
> > v4:
> > * Rebase
> > v5:
> > * Rename to vrr_range to match AMD debugfs
> > v6:
> > * Rebase (manasi)
> > v7:
> > * Fix cmpilation due to rebase
> > v8:
> > * Move debugfs node creation logic to DRM (Emil)
> > * Remove AMD specific logic (Emil)
> >
> > Signed-off-by: Bhanuprakash Modem
> > Signed-off-by: Manasi Navare
> > Cc: Jani Nikula
> > Cc: Ville Syrjälä
> > Cc: Harry Wentland
> > ---
> > .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 20 -
> > drivers/gpu/drm/drm_debugfs.c | 22 +++
> > 2 files changed, 22 insertions(+), 20 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> > index 076af267b488..71387d2af2ed 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> > @@ -820,24 +820,6 @@ static int output_bpc_show(struct seq_file *m, void
> *data)
> > return res;
> > }
> >
> > -/*
> > - * Returns the min and max vrr vfreq through the connector's debugfs
> file.
> > - * Example usage: cat /sys/kernel/debug/dri/0/DP-1/vrr_range
> > - */
> > -static int vrr_range_show(struct seq_file *m, void *data)
> > -{
> > - struct drm_connector *connector = m->private;
> > - struct amdgpu_dm_connector *aconnector =
> to_amdgpu_dm_connector(connector);
> > -
> > - if (connector->status != connector_status_connected)
> > - return -ENODEV;
> > -
> > - seq_printf(m, "Min: %u\n", (unsigned int)aconnector->min_vfreq);
> > - seq_printf(m, "Max: %u\n", (unsigned int)aconnector->max_vfreq);
> > -
> > - return 0;
> > -}
> > -
> > #ifdef CONFIG_DRM_AMD_DC_HDCP
> > /*
> > * Returns the HDCP capability of the Display (1.4 for now).
> > @@ -1001,7 +983,6 @@ static ssize_t dp_dpcd_data_read(struct file *f,
> char __user *buf,
> > DEFINE_SHOW_ATTRIBUTE(dmub_fw_state);
> > DEFINE_SHOW_ATTRIBUTE(dmub_tracebuffer);
> > DEFINE_SHOW_ATTRIBUTE(output_bpc);
> > -DEFINE_SHOW_ATTRIBUTE(vrr_range);
> > #ifdef CONFIG_DRM_AMD_DC_HDCP
> > DEFINE_SHOW_ATTRIBUTE(hdcp_sink_capability);
> > #endif
> > @@ -1059,7 +1040,6 @@ static const struct {
> > {"phy_settings", _phy_settings_debugfs_fop},
> > {"test_pattern", _phy_test_pattern_fops},
> > {"output_bpc", _bpc_fops},
> > - {"vrr_range", _range_fops},
> > #ifdef CONFIG_DRM_AMD_DC_HDCP
> > {"hdcp_sink_capability", _sink_capability_fops},
> > #endif
>
> I think the AMD sepecific debugfs removal should be in a separate patch
> follwing the drm_debugfs addition
> patch because from merging pov that patch will get merged through AMD tree
> and drm patch will get merged through drm_misc
> Also cc the amd dev mailing list for that patch.
[Bhanu] Sure
>
> @Harry does that sound okay from merging pov?
>
> Manasi
>
> > diff --git a/drivers/gpu/drm/drm_debugfs.c
> b/drivers/gpu/drm/drm_debugfs.c
> > index bfe4602f206b..3d7182001004 100644
> > --- a/drivers/gpu/drm/drm_debugfs.c
> > +++ b/drivers/gpu/drm/drm_debugfs.c
> > @@ -376,6 +376,24 @@ static ssize_t edid_write(struct file *file, const
> char __user *ubuf,
> > return (ret) ? ret : len;
> > }
> >
> > +/*
> > + * Returns the min and max vrr vfreq through the connector's debugfs
> file.
> > + * Example usage: cat /sys/kernel/debug/dri/0/DP-1/vrr_range
> > + */
> > +static int vrr_range_show(struct seq_file *m, void *data)
> > +{
> > + struct drm_connector *connector = m->private;
> > +
> > + if (connector->status != connector_status_connected)
> > + return -ENODEV;
> > +
> > + seq_printf(m, "Min: %u\n", (u8)connector-
> >display_info.monitor_range.min_vfreq);
> >
Re: [PATCH v1 01/11] soc: mediatek: cmdq: add address shift in jump
Reviewed-by: Bibby Hsieh Thanks. On Sun, 2020-06-21 at 22:18 +0800, Dennis YC Hsieh wrote: > 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; ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 0/11] support cmdq helper function on mt6779 platform
Hi, Dennis, Please add "depends on patch: support gce on mt6779 platform" in cover letter. Thanks Bibby On Sun, 2020-06-21 at 22:18 +0800, Dennis YC Hsieh wrote: > 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(-) > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 1/2] drm/panel-simple: Correct EDT ET057090DHU connector type
Hi Dmitry,
Thank you for the patch.
On Mon, Jun 22, 2020 at 01:27:41AM +0300, Dmitry Osipenko wrote:
> 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
Reviewed-by: Laurent Pinchart
> ---
> 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 = {
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH][next] drm/mm/selftests: fix unsigned comparison with less than zero
On 6/18/20 12:39 PM, Dan Carpenter wrote:
On Wed, Jun 17, 2020 at 04:59:59PM +0100, Colin King wrote:
From: Colin Ian King
Function get_insert_time can return error values that are cast
to a u64. The checks of insert_time1 and insert_time2 check for
the errors but because they are u64 variables the check for less
than zero can never be true. Fix this by casting the value to s64
to allow of the negative error check to succeed.
Addresses-Coverity: ("Unsigned compared against 0, no effect")
Fixes: 6e60d5ded06b ("drm/mm: add ig_frag selftest")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/selftests/test-drm_mm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/selftests/test-drm_mm.c
b/drivers/gpu/drm/selftests/test-drm_mm.c
index 3846b0f5bae3..671a152a6df2 100644
--- a/drivers/gpu/drm/selftests/test-drm_mm.c
+++ b/drivers/gpu/drm/selftests/test-drm_mm.c
@@ -1124,12 +1124,12 @@ static int igt_frag(void *ignored)
insert_time1 = get_insert_time(, insert_size,
nodes + insert_size, mode);
- if (insert_time1 < 0)
+ if ((s64)insert_time1 < 0)
goto err;
The error codes in this function seem pretty messed up.
Speaking of error codes, what the heck is going on with
prepare_igt_frag().
This is on me. I will send a patch to correct this mistake.
Thanks,
Nirmoy
1037 static int prepare_igt_frag(struct drm_mm *mm,
1038 struct drm_mm_node *nodes,
1039 unsigned int num_insert,
1040 const struct insert_mode *mode)
1041 {
1042 unsigned int size = 4096;
1043 unsigned int i;
1044 u64 ret = -EINVAL;
^^
Why is it u64?
1045
1046 for (i = 0; i < num_insert; i++) {
1047 if (!expect_insert(mm, [i], size, 0, i,
1048 mode) != 0) {
1049 pr_err("%s insert failed\n", mode->name);
1050 goto out;
One of the common bugs with do nothing gotos is that we forget to set
the error code. If we did a direct "return -EINVAL;" here, then there
would be no ambiguity.
1051 }
1052 }
1053
1054 /* introduce fragmentation by freeing every other node */
1055 for (i = 0; i < num_insert; i++) {
1056 if (i % 2 == 0)
1057 drm_mm_remove_node([i]);
1058 }
1059
1060 out:
1061 return ret;
1062
1063 }
regards,
dan carpenter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-develdata=02%7C01%7Cnirmoy.das%40amd.com%7C74bcb0163ea04eaf0ca008d8137403ac%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637280736306420244sdata=kZ7BUVaFWI5aV4OztJr8GMS8QWjz%2F7JIb9jwRM3ct5g%3Dreserved=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
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.
-Daniel
---
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index d807587c9ae6..27ea763c6155 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -4191,11 +4191,6 @@ void fs_reclaim_acquire(gfp_t gfp_mask)
if (gfp_mask & __GFP_FS)
__fs_reclaim_acquire();
-#ifdef CONFIG_MMU_NOTIFIER
- lock_map_acquire(&__mmu_notifier_invalidate_range_start_map);
- lock_map_release(&__mmu_notifier_invalidate_range_start_map);
-#endif
-
}
}
EXPORT_SYMBOL_GPL(fs_reclaim_acquire);
--
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] mm: Track mmu notifiers in fs_reclaim_acquire/release
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).
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
> (_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.775
[Bug 208269] Polaris HDMI passthrough for TrueHD and DTS-HD does not work without snoop enabled, which leads to clipping
https://bugzilla.kernel.org/show_bug.cgi?id=208269 --- Comment #5 from Brady (brady.w.cl...@gmail.com) --- I should add (headdesk) that the driver in question is amdgpu. -- 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 01/18] mm: Track mmu notifiers in fs_reclaim_acquire/release
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.
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
> (_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]chm
[Bug 208269] Polaris HDMI passthrough for TrueHD and DTS-HD does not work without snoop enabled, which leads to clipping
https://bugzilla.kernel.org/show_bug.cgi?id=208269 --- Comment #4 from Brady (brady.w.cl...@gmail.com) --- Created attachment 289779 --> https://bugzilla.kernel.org/attachment.cgi?id=289779=edit alsa-info.sh results with snoop forced enabled in snd_hda_intel -- 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 208269] Polaris HDMI passthrough for TrueHD and DTS-HD does not work without snoop enabled, which leads to clipping
https://bugzilla.kernel.org/show_bug.cgi?id=208269 Brady (brady.w.cl...@gmail.com) changed: What|Removed |Added Attachment #289775|0 |1 is obsolete|| --- Comment #3 from Brady (brady.w.cl...@gmail.com) --- Created attachment 289777 --> https://bugzilla.kernel.org/attachment.cgi?id=289777=edit alsa-info.sh results without snoop -- 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 208269] Polaris HDMI passthrough for TrueHD and DTS-HD does not work without snoop enabled, which leads to clipping
https://bugzilla.kernel.org/show_bug.cgi?id=208269 --- Comment #2 from Brady (brady.w.cl...@gmail.com) --- Created attachment 289775 --> https://bugzilla.kernel.org/attachment.cgi?id=289775=edit alsa-test.sh results without snoop -- 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 208269] Polaris HDMI passthrough for TrueHD and DTS-HD does not work without snoop enabled, which leads to clipping
https://bugzilla.kernel.org/show_bug.cgi?id=208269 --- Comment #1 from Brady (brady.w.cl...@gmail.com) --- Created attachment 289773 --> https://bugzilla.kernel.org/attachment.cgi?id=289773=edit \proc\asound\card0\eld#0.3 -- 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 208269] New: Polaris HDMI passthrough for TrueHD and DTS-HD does not work without snoop enabled, which leads to clipping
https://bugzilla.kernel.org/show_bug.cgi?id=208269 Bug ID: 208269 Summary: Polaris HDMI passthrough for TrueHD and DTS-HD does not work without snoop enabled, which leads to clipping Product: Drivers Version: 2.5 Kernel Version: Tested on 5.1.16 and 5.6.18 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: brady.w.cl...@gmail.com Regression: No Motherboard: Asus P8H61-M LX3 R2.0 CPU: Celeron G1610 RAM: 4GB GPU: Yeston RX550-4G D5 LP (POLARIS11) Receiver: Denon x6500h Tested in Kodi on 5.1.16 (LibreELEC 9.2.3) and on 5.6.18 (Fedora 32 with Pulseaudio disabled) Out of the box sound is crystal clear but passthrough does not work for TrueHD and DTS-HD, receiver does not show the codec and there is no audio at all with TrueHD and DTS-HD passthrough enabled. Other codecs (AC3, DTS) passthrough fine. Capabilities seem to be detected correctly (contents of \proc\asound\card0\eld#0.3 attached). If I set "options snd_hda_intel snoop=1", passthrough for all codecs works as expected, but I get horrible clipping with passthrough audio, and Kodi UI clicks repeat. alsa-test.sh results with and without snoop enabled are attached. To note: This hardware combination works as expected in Windows, and with an nVidia GT 1030 this setup does all HDMI passthrough correctly in LibreElec as well, although it does not, of course, allow HEVC hardware decoding in LibreELEC. -- 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][next] drm/mm/selftests: fix unsigned comparison with less than zero
Am 17.06.20 um 17:59 schrieb Colin King:
From: Colin Ian King
Function get_insert_time can return error values that are cast
to a u64. The checks of insert_time1 and insert_time2 check for
the errors but because they are u64 variables the check for less
than zero can never be true. Fix this by casting the value to s64
to allow of the negative error check to succeed.
Addresses-Coverity: ("Unsigned compared against 0, no effect")
Fixes: 6e60d5ded06b ("drm/mm: add ig_frag selftest")
Signed-off-by: Colin Ian King
Reviewed-by: Christian König
Going to pick that up for drm-misc-fixes tomorrow.
---
drivers/gpu/drm/selftests/test-drm_mm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/selftests/test-drm_mm.c
b/drivers/gpu/drm/selftests/test-drm_mm.c
index 3846b0f5bae3..671a152a6df2 100644
--- a/drivers/gpu/drm/selftests/test-drm_mm.c
+++ b/drivers/gpu/drm/selftests/test-drm_mm.c
@@ -1124,12 +1124,12 @@ static int igt_frag(void *ignored)
insert_time1 = get_insert_time(, insert_size,
nodes + insert_size, mode);
- if (insert_time1 < 0)
+ if ((s64)insert_time1 < 0)
goto err;
insert_time2 = get_insert_time(, (insert_size * 2),
nodes + insert_size * 2, mode);
- if (insert_time2 < 0)
+ if ((s64)insert_time2 < 0)
goto err;
pr_info("%s fragmented insert of %u and %u insertions took %llu and %llu nsecs\n",
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 26/36] drm: host1x: fix common struct sg_table related issues
Hi Marek,
I love your patch! Yet something to improve:
[auto build test ERROR on next-20200618]
[also build test ERROR on v5.8-rc1]
[cannot apply to linuxtv-media/master staging/staging-testing
drm-exynos/exynos-drm-next drm-intel/for-linux-next linus/master v5.8-rc1 v5.7
v5.7-rc7]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Marek-Szyprowski/DRM-fix-struct-sg_table-nents-vs-orig_nents-misuse/20200619-184302
base:ce2cc8efd7a40cbd17841add878cb691d0ce0bba
config: arm64-randconfig-r036-20200621 (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project
ef455a55bcf2cfea04a99c361b182ad18b7f03f1)
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 arm64 cross compiling tool for clang build
# apt-get install binutils-aarch64-linux-gnu
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
>> drivers/gpu/host1x/job.c:230:10: error: implicit declaration of function
>> 'iommu_map_sgtable' [-Werror,-Wimplicit-function-declaration]
err = iommu_map_sgtable(host->domain,
^
drivers/gpu/host1x/job.c:230:10: note: did you mean 'dma_map_sgtable'?
include/linux/dma-mapping.h:628:19: note: 'dma_map_sgtable' declared here
static inline int dma_map_sgtable(struct device *dev, struct sg_table *sgt,
^
1 error generated.
vim +/iommu_map_sgtable +230 drivers/gpu/host1x/job.c
100
101 static unsigned int pin_job(struct host1x *host, struct host1x_job *job)
102 {
103 struct host1x_client *client = job->client;
104 struct device *dev = client->dev;
105 struct iommu_domain *domain;
106 unsigned int i;
107 int err;
108
109 domain = iommu_get_domain_for_dev(dev);
110 job->num_unpins = 0;
111
112 for (i = 0; i < job->num_relocs; i++) {
113 struct host1x_reloc *reloc = >relocs[i];
114 dma_addr_t phys_addr, *phys;
115 struct sg_table *sgt;
116
117 reloc->target.bo = host1x_bo_get(reloc->target.bo);
118 if (!reloc->target.bo) {
119 err = -EINVAL;
120 goto unpin;
121 }
122
123 /*
124 * If the client device is not attached to an IOMMU, the
125 * physical address of the buffer object can be used.
126 *
127 * Similarly, when an IOMMU domain is shared between all
128 * host1x clients, the IOVA is already available, so no
129 * need to map the buffer object again.
130 *
131 * XXX Note that this isn't always safe to do because it
132 * relies on an assumption that no cache maintenance is
133 * needed on the buffer objects.
134 */
135 if (!domain || client->group)
136 phys = _addr;
137 else
138 phys = NULL;
139
140 sgt = host1x_bo_pin(dev, reloc->target.bo, phys);
141 if (IS_ERR(sgt)) {
142 err = PTR_ERR(sgt);
143 goto unpin;
144 }
145
146 if (sgt) {
147 unsigned long mask = HOST1X_RELOC_READ |
148 HOST1X_RELOC_WRITE;
149 enum dma_data_direction dir;
150
151 switch (reloc->flags & mask) {
152 case HOST1X_RELOC_READ:
153 dir = DMA_TO_DEVICE;
154 break;
155
156 case HOST1X_RELOC_WRITE:
157 dir = DMA_FROM_DEVICE;
158 break;
159
160 case HOST1X_RELOC_READ | HOST1X_RELOC_WRITE:
161 dir = DMA_BIDIRECTIONAL;
162 break;
163
164 default:
Re: [PATCH 27/27] drm: Add default modes for connectors in unknown state
On Tue, May 26, 2020 at 04:15:05AM +0300, Laurent Pinchart wrote:
> The DRM CRTC helpers add default modes to connectors in the connected
> state if no mode can be retrieved from the connector. This behaviour is
> useful for VGA or DVI outputs that have no connected DDC bus. However,
> in such cases, the status of the output usually can't be retrieved and
> is reported as connector_status_unknown.
>
> Extend the addition of default modes to connectors in an unknown state
> to support outputs that can retrieve neither the modes nor the
> connection status.
>
> Signed-off-by: Laurent Pinchart
>From your description sounds like an OK approach.
But this is not something I feel too familiar with.
Acked-by: Sam Ravnborg
> ---
> drivers/gpu/drm/drm_probe_helper.c | 3 ++-
> include/drm/drm_modeset_helper_vtables.h | 8 +++-
> 2 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_probe_helper.c
> b/drivers/gpu/drm/drm_probe_helper.c
> index f5d141e0400f..9055d9573c90 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -491,7 +491,8 @@ int drm_helper_probe_single_connector_modes(struct
> drm_connector *connector,
> if (count == 0 && connector->status == connector_status_connected)
> count = drm_add_override_edid_modes(connector);
>
> - if (count == 0 && connector->status == connector_status_connected)
> + if (count == 0 && (connector->status == connector_status_connected ||
> +connector->status == connector_status_unknown))
> count = drm_add_modes_noedid(connector, 1024, 768);
> count += drm_helper_probe_add_cmdline_mode(connector);
> if (count == 0)
> diff --git a/include/drm/drm_modeset_helper_vtables.h
> b/include/drm/drm_modeset_helper_vtables.h
> index 421a30f08463..afe55e2e93d2 100644
> --- a/include/drm/drm_modeset_helper_vtables.h
> +++ b/include/drm/drm_modeset_helper_vtables.h
> @@ -876,13 +876,19 @@ struct drm_connector_helper_funcs {
>* The usual way to implement this is to cache the EDID retrieved in the
>* probe callback somewhere in the driver-private connector structure.
>* In this function drivers then parse the modes in the EDID and add
> - * them by calling drm_add_edid_modes(). But connectors that driver a
> + * them by calling drm_add_edid_modes(). But connectors that drive a
>* fixed panel can also manually add specific modes using
>* drm_mode_probed_add(). Drivers which manually add modes should also
>* make sure that the _connector.display_info,
>* _connector.width_mm and _connector.height_mm fields are
>* filled in.
>*
> + * Note that the caller function will automatically add standard VESA
> + * DMT modes up to 1024x768 if the .get_modes() helper operation returns
> + * no mode and if the connector status is connector_status_connected or
> + * connector_status_unknown. There is no need to call
> + * drm_add_edid_modes() manually in that case.
> + *
>* Virtual drivers that just want some standard VESA mode with a given
>* resolution can call drm_add_modes_noedid(), and mark the preferred
>* one using drm_set_preferred_mode().
> --
> Regards,
>
> Laurent Pinchart
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 09/27] drm: edid: Constify connector argument to infoframe functions
On Tue, May 26, 2020 at 04:14:47AM +0300, Laurent Pinchart wrote:
> The drm_hdmi_avi_infoframe_from_display_mode(),
> drm_hdmi_vendor_infoframe_from_display_mode() and
> drm_hdmi_avi_infoframe_quant_range() functions take a drm_connector that
> they don't modify. Mark it as const.
>
> Signed-off-by: Laurent Pinchart
Acked-by: Sam Ravnborg
> ---
> drivers/gpu/drm/drm_edid.c | 12 ++--
> include/drm/drm_edid.h | 6 +++---
> 2 files changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 3bd95c4b02eb..e6b26f16c21f 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -5365,7 +5365,7 @@ void drm_set_preferred_mode(struct drm_connector
> *connector,
> }
> EXPORT_SYMBOL(drm_set_preferred_mode);
>
> -static bool is_hdmi2_sink(struct drm_connector *connector)
> +static bool is_hdmi2_sink(const struct drm_connector *connector)
> {
> /*
>* FIXME: sil-sii8620 doesn't have a connector around when
> @@ -5450,7 +5450,7 @@ drm_hdmi_infoframe_set_hdr_metadata(struct
> hdmi_drm_infoframe *frame,
> }
> EXPORT_SYMBOL(drm_hdmi_infoframe_set_hdr_metadata);
>
> -static u8 drm_mode_hdmi_vic(struct drm_connector *connector,
> +static u8 drm_mode_hdmi_vic(const struct drm_connector *connector,
> const struct drm_display_mode *mode)
> {
> bool has_hdmi_infoframe = connector ?
> @@ -5466,7 +5466,7 @@ static u8 drm_mode_hdmi_vic(struct drm_connector
> *connector,
> return drm_match_hdmi_mode(mode);
> }
>
> -static u8 drm_mode_cea_vic(struct drm_connector *connector,
> +static u8 drm_mode_cea_vic(const struct drm_connector *connector,
> const struct drm_display_mode *mode)
> {
> u8 vic;
> @@ -5504,7 +5504,7 @@ static u8 drm_mode_cea_vic(struct drm_connector
> *connector,
> */
> int
> drm_hdmi_avi_infoframe_from_display_mode(struct hdmi_avi_infoframe *frame,
> - struct drm_connector *connector,
> + const struct drm_connector *connector,
>const struct drm_display_mode *mode)
> {
> enum hdmi_picture_aspect picture_aspect;
> @@ -5651,7 +5651,7 @@ EXPORT_SYMBOL(drm_hdmi_avi_infoframe_colorspace);
> */
> void
> drm_hdmi_avi_infoframe_quant_range(struct hdmi_avi_infoframe *frame,
> -struct drm_connector *connector,
> +const struct drm_connector *connector,
> const struct drm_display_mode *mode,
> enum hdmi_quantization_range rgb_quant_range)
> {
> @@ -5755,7 +5755,7 @@ s3d_structure_from_display_mode(const struct
> drm_display_mode *mode)
> */
> int
> drm_hdmi_vendor_infoframe_from_display_mode(struct hdmi_vendor_infoframe
> *frame,
> - struct drm_connector *connector,
> + const struct drm_connector
> *connector,
> const struct drm_display_mode *mode)
> {
> /*
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> index 34b15e3d070c..43254319ab19 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -361,11 +361,11 @@ drm_load_edid_firmware(struct drm_connector *connector)
>
> int
> drm_hdmi_avi_infoframe_from_display_mode(struct hdmi_avi_infoframe *frame,
> - struct drm_connector *connector,
> + const struct drm_connector *connector,
>const struct drm_display_mode *mode);
> int
> drm_hdmi_vendor_infoframe_from_display_mode(struct hdmi_vendor_infoframe
> *frame,
> - struct drm_connector *connector,
> + const struct drm_connector
> *connector,
> const struct drm_display_mode
> *mode);
>
> void
> @@ -378,7 +378,7 @@ drm_hdmi_avi_infoframe_bars(struct hdmi_avi_infoframe
> *frame,
>
> void
> drm_hdmi_avi_infoframe_quant_range(struct hdmi_avi_infoframe *frame,
> -struct drm_connector *connector,
> +const struct drm_connector *connector,
> const struct drm_display_mode *mode,
> enum hdmi_quantization_range
> rgb_quant_range);
>
> --
> Regards,
>
> Laurent Pinchart
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 05/27] drm: bridge: Return NULL on error from drm_bridge_get_edid()
On Tue, May 26, 2020 at 04:14:43AM +0300, Laurent Pinchart wrote:
> The drm_bridge_get_edid() function is documented to return an error
> pointer on error. The underlying .get_edid() operation, however, returns
> NULL on error, and so do the drm_get_edid() and drm_do_get_edid()
> functions upon which .get_edid() is usually implemented. Make
> drm_bridge_get_edid() return NULL on error to be consistent.
>
> Signed-off-by: Laurent Pinchart
Acked-by: Sam Ravnborg
> ---
> drivers/gpu/drm/bridge/ti-tfp410.c | 10 +++---
> drivers/gpu/drm/drm_bridge.c | 6 +++---
> 2 files changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c
> b/drivers/gpu/drm/bridge/ti-tfp410.c
> index e3eb6364c0f7..f065a96a0917 100644
> --- a/drivers/gpu/drm/bridge/ti-tfp410.c
> +++ b/drivers/gpu/drm/bridge/ti-tfp410.c
> @@ -51,11 +51,15 @@ static int tfp410_get_modes(struct drm_connector
> *connector)
> struct edid *edid;
> int ret;
>
> - edid = drm_bridge_get_edid(dvi->next_bridge, connector);
> - if (IS_ERR_OR_NULL(edid)) {
> - if (edid != ERR_PTR(-ENOTSUPP))
> + if (dvi->next_bridge->ops & DRM_BRIDGE_OP_EDID) {
> + edid = drm_bridge_get_edid(dvi->next_bridge, connector);
> + if (!edid)
> DRM_INFO("EDID read failed. Fallback to standard
> modes\n");
> + } else {
> + edid = NULL;
> + }
>
> + if (!edid) {
> /*
>* No EDID, fallback on the XGA standard modes and prefer a mode
>* pretty much anything can handle.
> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> index afdec8e5fc68..fe1e3460b486 100644
> --- a/drivers/gpu/drm/drm_bridge.c
> +++ b/drivers/gpu/drm/drm_bridge.c
> @@ -1086,16 +1086,16 @@ EXPORT_SYMBOL_GPL(drm_bridge_get_modes);
> *
> * If the bridge supports output EDID retrieval, as reported by the
> * DRM_BRIDGE_OP_EDID bridge ops flag, call _bridge_funcs.get_edid to
> - * get the EDID and return it. Otherwise return ERR_PTR(-ENOTSUPP).
> + * get the EDID and return it. Otherwise return NULL.
> *
> * RETURNS:
> - * The retrieved EDID on success, or an error pointer otherwise.
> + * The retrieved EDID on success, or NULL otherwise.
> */
> struct edid *drm_bridge_get_edid(struct drm_bridge *bridge,
>struct drm_connector *connector)
> {
> if (!(bridge->ops & DRM_BRIDGE_OP_EDID))
> - return ERR_PTR(-ENOTSUPP);
> + return NULL;
>
> return bridge->funcs->get_edid(bridge, connector);
> }
> --
> Regards,
>
> Laurent Pinchart
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 03/27] drm: bridge: adv7511: Implement bridge connector operations
On Tue, May 26, 2020 at 04:14:41AM +0300, Laurent Pinchart wrote:
> Implement the bridge connector-related .get_edid(), .detect() and
> .hpd_notify() operations, and report the related bridge capabilities.
>
> Output status detection is implemented using the same backend as for the
> DRM connector, but requires making mode retrieval at detection time
> optional as no pointer to the connector is available to the bridge
> .detect() operation. The reason for the need to retrieve modes at
> detection time is unclear to me, and this may benefit from further
> refactoring of hot plug handling code.
As discussed before the get_modes is likely not needed.
But this patch should not remove it - so fine
>
> Hot plug detection is notified through the bridge HPD notification
> framework when the bridge is used without creating a connector, and
> falls back to the existing implementation otherwise. CEC handling of
> disconnection is handled in the new .hpd_notify() operation in the new
> code path.
>
> Signed-off-by: Laurent Pinchart
Acked-by: Sam Ravnborg
> ---
> drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 43 ++--
> 1 file changed, 39 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> index f0992b6d654f..2662f28f8007 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> @@ -443,9 +443,14 @@ static void adv7511_hpd_work(struct work_struct *work)
>
> if (adv7511->connector.status != status) {
> adv7511->connector.status = status;
> - if (status == connector_status_disconnected)
> - cec_phys_addr_invalidate(adv7511->cec_adap);
> - drm_kms_helper_hotplug_event(adv7511->connector.dev);
> +
> + if (adv7511->connector.dev) {
> + if (status == connector_status_disconnected)
> + cec_phys_addr_invalidate(adv7511->cec_adap);
> + drm_kms_helper_hotplug_event(adv7511->connector.dev);
> + } else {
> + drm_bridge_hpd_notify(>bridge, status);
> + }
> }
> }
>
> @@ -661,7 +666,8 @@ adv7511_detect(struct adv7511 *adv7511, struct
> drm_connector *connector)
> if (status == connector_status_connected && hpd && adv7511->powered) {
> regcache_mark_dirty(adv7511->regmap);
> adv7511_power_on(adv7511);
> - adv7511_get_modes(adv7511, connector);
> + if (connector)
> + adv7511_get_modes(adv7511, connector);
> if (adv7511->status == connector_status_connected)
> status = connector_status_disconnected;
> } else {
> @@ -917,11 +923,38 @@ static int adv7511_bridge_attach(struct drm_bridge
> *bridge,
> return ret;
> }
>
> +static enum drm_connector_status adv7511_bridge_detect(struct drm_bridge
> *bridge)
> +{
> + struct adv7511 *adv = bridge_to_adv7511(bridge);
> +
> + return adv7511_detect(adv, NULL);
> +}
> +
> +static struct edid *adv7511_bridge_get_edid(struct drm_bridge *bridge,
> + struct drm_connector *connector)
> +{
> + struct adv7511 *adv = bridge_to_adv7511(bridge);
> +
> + return adv7511_get_edid(adv, connector);
> +}
> +
> +static void adv7511_bridge_hpd_notify(struct drm_bridge *bridge,
> + enum drm_connector_status status)
> +{
> + struct adv7511 *adv = bridge_to_adv7511(bridge);
> +
> + if (status == connector_status_disconnected)
> + cec_phys_addr_invalidate(adv->cec_adap);
> +}
> +
> static const struct drm_bridge_funcs adv7511_bridge_funcs = {
> .enable = adv7511_bridge_enable,
> .disable = adv7511_bridge_disable,
> .mode_set = adv7511_bridge_mode_set,
> .attach = adv7511_bridge_attach,
> + .detect = adv7511_bridge_detect,
> + .get_edid = adv7511_bridge_get_edid,
> + .hpd_notify = adv7511_bridge_hpd_notify,
> };
>
> /*
> -
> @@ -1250,6 +1283,8 @@ static int adv7511_probe(struct i2c_client *i2c, const
> struct i2c_device_id *id)
> goto err_unregister_cec;
>
> adv7511->bridge.funcs = _bridge_funcs;
> + adv7511->bridge.ops = DRM_BRIDGE_OP_DETECT | DRM_BRIDGE_OP_EDID
> + | DRM_BRIDGE_OP_HPD;
> adv7511->bridge.of_node = dev->of_node;
>
> drm_bridge_add(>bridge);
> --
> Regards,
>
> Laurent Pinchart
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] video: fbdev: uvesafb: fix "noblank" option handling
On Tue, Jun 09, 2020 at 11:29:43AM +0200, Bartlomiej Zolnierkiewicz wrote:
> Fix the recent regression.
>
> Fixes: dbc7ece12a38 ("video: uvesafb: use true,false for bool variables")
> Cc: Jason Yan
> Reviewed-by: Sam Ravnborg
> Signed-off-by: Bartlomiej Zolnierkiewicz
Hi Bartlomiej
I was processing drm-misc-fixes patches so I went ahead and applied
this.
Thanks for fixing this up.
Sam
> ---
> v2:
> - added Reviewed-by tag from Sam
> - removed no longer working Michal's email address from Cc:
>
> drivers/video/fbdev/uvesafb.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index: b/drivers/video/fbdev/uvesafb.c
> ===
> --- a/drivers/video/fbdev/uvesafb.c
> +++ b/drivers/video/fbdev/uvesafb.c
> @@ -1836,7 +1836,7 @@ static int uvesafb_setup(char *options)
> else if (!strcmp(this_opt, "noedid"))
> noedid = true;
> else if (!strcmp(this_opt, "noblank"))
> - blank = true;
> + blank = false;
> else if (!strncmp(this_opt, "vtotal:", 7))
> vram_total = simple_strtoul(this_opt + 7, NULL, 0);
> else if (!strncmp(this_opt, "vremap:", 7))
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v13 2/2] drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP
Hi Xin.
On Tue, Jun 09, 2020 at 03:19:50PM +0800, Xin Ji wrote:
> The ANX7625 is an ultra-low power 4K Mobile HD Transmitter designed
> for portable device. It converts MIPI DSI/DPI to DisplayPort 1.3 4K.
>
> Signed-off-by: Xin Ji
The bridge driver now implements the bridge functions for get_edid +
detect which is good.
But the bridge driver also needs to check the flags argument
of anx7625_bridge_attach() so the connector creation is optional.
This is required to prepare the bridge driver to fully support a
chain of bridges and is mandatory for new bridge drivers.
Futhermore the bridge driver needs to be converted to use the bridge
panel. See what other bridge drivers do.
In short - the drm_panel shall be replaced by a bridge in your
platform data structure.
Usual this end up in less code after the conversion.
Sam
> ---
> drivers/gpu/drm/bridge/analogix/Kconfig |9 +
> drivers/gpu/drm/bridge/analogix/Makefile |1 +
> drivers/gpu/drm/bridge/analogix/anx7625.c | 1999
> +
> drivers/gpu/drm/bridge/analogix/anx7625.h | 397 ++
> 4 files changed, 2406 insertions(+)
> create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.c
> create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.h
>
> diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig
> b/drivers/gpu/drm/bridge/analogix/Kconfig
> index e1fa7d8..024ea2a 100644
> --- a/drivers/gpu/drm/bridge/analogix/Kconfig
> +++ b/drivers/gpu/drm/bridge/analogix/Kconfig
> @@ -25,3 +25,12 @@ config DRM_ANALOGIX_ANX78XX
> config DRM_ANALOGIX_DP
> tristate
> depends on DRM
> +
> +config DRM_ANALOGIX_ANX7625
> + tristate "Analogix Anx7625 MIPI to DP interface support"
> + depends on DRM
> + depends on OF
> + help
> + ANX7625 is an ultra-low power 4K mobile HD transmitter
> + designed for portable devices. It converts MIPI/DPI to
> + DisplayPort1.3 4K.
> diff --git a/drivers/gpu/drm/bridge/analogix/Makefile
> b/drivers/gpu/drm/bridge/analogix/Makefile
> index 97669b3..44da392 100644
> --- a/drivers/gpu/drm/bridge/analogix/Makefile
> +++ b/drivers/gpu/drm/bridge/analogix/Makefile
> @@ -1,5 +1,6 @@
> # SPDX-License-Identifier: GPL-2.0-only
> analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o analogix-i2c-dptx.o
> obj-$(CONFIG_DRM_ANALOGIX_ANX6345) += analogix-anx6345.o
> +obj-$(CONFIG_DRM_ANALOGIX_ANX7625) += anx7625.o
> obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
> obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix_dp.o
> diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
> b/drivers/gpu/drm/bridge/analogix/anx7625.c
> new file mode 100644
> index 000..db37f68
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
> @@ -0,0 +1,1999 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright(c) 2020, Analogix Semiconductor. All rights reserved.
> + *
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#include "anx7625.h"
> +
> +/*
> + * There is a sync issue while access I2C register between AP(CPU) and
> + * internal firmware(OCM), to avoid the race condition, AP should access
> + * the reserved slave address before slave address occurs changes.
> + */
> +static int i2c_access_workaround(struct anx7625_data *ctx,
> + struct i2c_client *client)
> +{
> + u8 offset;
> + struct device *dev = >dev;
> + int ret;
> +
> + if (client == ctx->last_client)
> + return 0;
> +
> + ctx->last_client = client;
> +
> + if (client == ctx->i2c.tcpc_client)
> + offset = RSVD_00_ADDR;
> + else if (client == ctx->i2c.tx_p0_client)
> + offset = RSVD_D1_ADDR;
> + else if (client == ctx->i2c.tx_p1_client)
> + offset = RSVD_60_ADDR;
> + else if (client == ctx->i2c.rx_p0_client)
> + offset = RSVD_39_ADDR;
> + else if (client == ctx->i2c.rx_p1_client)
> + offset = RSVD_7F_ADDR;
> + else
> + offset = RSVD_00_ADDR;
> +
> + ret = i2c_smbus_write_byte_data(client, offset, 0x00);
> + if (ret < 0)
> + DRM_DEV_ERROR(dev,
> + "fail to access i2c id=%x\n:%x",
> + client->addr, offset);
> +
> + return ret;
> +}
> +
> +static int anx7625_reg_read(struct anx7625_data *ctx,
> + struct i2c_client *client, u8 reg_addr)
> +{
> + int ret;
> + struct device *dev = >dev;
> +
> + i2c_access_workaround(ctx, client);
> +
> + ret = i2c_smbus_read_byte_data(client, reg_addr);
> + if (ret < 0)
> + DRM_DEV_ERROR(dev, "read i2c fail id=%x:%x\n",
> + client->addr, reg_addr);
> +
> +
Re: [PATCH] drm/panel-simple: fix connector type for newhaven_nhd_43_480272ef_atxl
Hi Tomi
On Tue, Jun 09, 2020 at 01:28:09PM +0300, Tomi Valkeinen wrote:
> Add connector type for newhaven_nhd_43_480272ef_atxl, as
> drm_panel_bridge_add() requires connector type to be set.
>
> Signed-off-by: Tomi Valkeinen
> Cc: sta...@vger.kernel.org # v5.5+
Applied to drm-misc-fixes.
I looked at adding a Fixes: tag for the original commit introducing
newhaven_nhd_43_480272ef_atxl, but we did not have connector_type back
then.
Sam
> ---
> drivers/gpu/drm/panel/panel-simple.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c
> b/drivers/gpu/drm/panel/panel-simple.c
> index 3ad828eaefe1..00c1a8dc4ce8 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -2465,6 +2465,7 @@ static const struct panel_desc
> newhaven_nhd_43_480272ef_atxl = {
> .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
> .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE |
>DRM_BUS_FLAG_SYNC_DRIVE_POSEDGE,
> + .connector_type = DRM_MODE_CONNECTOR_DPI,
> };
>
> static const struct display_timing nlt_nl192108ac18_02d_timing = {
> --
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 207383] [Regression] 5.7 amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail
https://bugzilla.kernel.org/show_bug.cgi?id=207383 --- Comment #15 from Duncan (1i5t5.dun...@cox.net) --- Bug's in v5.8-rc1-226-g4333a9b0b too. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RESEND v2 0/4] panel-simple: CDTech S070PWS19HP-FC21 and S070SWV29HG-DC44, Tianma TM070JVHG33
Hi Matthias On Fri, Jun 12, 2020 at 09:22:15AM +0200, Matthias Schiffer wrote: > From: Matthias Schiffer > > This adds a few panels TQ-Systems uses with various starterkit > mainboards. Device trees actually using these panels will be added with > a later submission. > > > Matthias Schiffer (2): > dt-bindings: display: simple: add CDTech S070PWS19HP-FC21 and > S070SWV29HG-DC44 > dt-bindings: display: simple: add Tianma TM070JVHG33 > > Max Merchel (1): > drm/panel: simple: add Tianma TM070JVHG33 > > Michael Krummsdorf (1): > drm/panel: simple: add CDTech S070PWS19HP-FC21 and S070SWV29HG-DC44 Thanks, all applied to drm-misc-next. Sam > > .../bindings/display/panel/panel-simple.yaml | 6 ++ > drivers/gpu/drm/panel/panel-simple.c | 75 +++ > 2 files changed, 81 insertions(+) > > -- > 2.17.1 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panel-simple: fix connector type for LogicPD Type28 Display
Hi Adam.
On Mon, Jun 15, 2020 at 09:53:45AM -0500, Adam Ford wrote:
> On Mon, Jun 15, 2020 at 9:46 AM Fabio Estevam wrote:
> >
> > On Mon, Jun 15, 2020 at 10:19 AM Adam Ford wrote:
> > >
> > > The LogicPD Type28 display used by several Logic PD products has not
> > > worked since v5.5.
> >
> > Maybe you could tell which commit exactly and then put a Fixes tag?
>
> I honestly don't know. I reached out to the omap mailing list,
> because I noted this issue. Tomi V from TI responded with a link that
> he posted which fixes this for another display.
>
> https://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg312208.html
>
> I tested that patch and it worked for a different LCD, so I did the
> same thing to the Logic PD Type 28 display as well.
>
> My patch and commit message were modeled after his, and his commit
> CC's stable with a note about being required for v5.5+
>
> I added him to the CC list, so maybe he knows which hash needs to be
> referenced from a fixes tag. I was hoping to not have to go back and
> bisect if it's not required, but I will if necessary.
git blame is your friend - the panel was added here:
0d35408afbeb6 (Adam Ford 2019-10-16 08:51:45 -0500 2469) static
const struct panel_desc logicpd_type_28 = {
0d35408afbeb6 (Adam Ford 2019-10-16 08:51:45 -0500 2470) .modes
= _type_28_mode,
0d35408afbeb6 (Adam Ford 2019-10-16 08:51:45 -0500 2471)
.num_modes = 1,
0d35408afbeb6 (Adam Ford 2019-10-16 08:51:45 -0500 2472) .bpc =
8,
0d35408afbeb6 (Adam Ford 2019-10-16 08:51:45 -0500 2473) .size =
{
0d35408afbeb6 (Adam Ford 2019-10-16 08:51:45 -0500 2474)
.width = 105,
0d35408afbeb6 (Adam Ford 2019-10-16 08:51:45 -0500 2475)
.height = 67,
0d35408afbeb6 (Adam Ford 2019-10-16 08:51:45 -0500 2476) },
So this gives us fllowing fixes info:
Fixes: 0d35408afbeb ("drm/panel: simple: Add Logic PD Type 28 display support")
Cc: Adam Ford
Cc: Sam Ravnborg
Cc: Thierry Reding
Cc: dri-devel@lists.freedesktop.org
Cc: # v5.6+
I have adjusted the changelog to say 5.6 and applied to drm-misc-fixes
Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/8] drm/amdgpu: Split amdgpu_device_fini into early and late
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
---
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(>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);
pci_set_drvdata(pdev, NULL);
drm_dev_put(dev);
@@ -1445,6 +1442,7 @@ static struct drm_driver kms_driver = {
.dumb_create = amdgpu_mode_dumb_create,
.dumb_map_offset = amdgpu_mode_dumb_mmap,
.fops = _driver_kms_fops,
+ .release = _driver_release_kms,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
index 0cc4c67..1697655 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
@@ -49,6 +49,7 @@
#include
[PATCH v2 8/8] drm/amdgpu: Prevent any job recoveries after device is unplugged.
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(>sched.work_tdr);
+ }
+}
+
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(>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(, 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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 6/8] drm/amdgpu: Unmap entire device address space on device remove.
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(>mman.bdev); amdgpu_driver_unload_kms(dev); pci_disable_device(pdev); -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/8] drm/ttm: Add unampping of the entire device address space
Helper function to be used to invalidate all BOs CPU mappings
once device is removed.
Signed-off-by: Andrey Grodzovsky
---
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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 5/8] drm/amdgpu: Refactor sysfs removal
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
---
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 =
_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, _attr_vbios_version);
}
/**
@@ -2038,6 +2039,10 @@ int amdgpu_atombios_init(struct amdgpu_device *adev)
return ret;
}
+ mutex_lock(>sysfs_files_list_lock);
+ list_add_tail(_attr_handle_vbios_version.head,
>sysfs_files_list);
+ mutex_unlock(>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(>shadow_list);
mutex_init(>shadow_list_lock);
+ INIT_LIST_HEAD(>sysfs_files_list);
+ mutex_init(>sysfs_files_list_lock);
+
INIT_DELAYED_WORK(>delayed_init_work,
amdgpu_device_delayed_init_work_handler);
INIT_DELAYED_WORK(>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(>sysfs_files_list_lock);
+ list_add_tail(_attr_handle_product_name.head,
>sysfs_files_list);
+ list_add_tail(_attr_handle_product_number.head,
>sysfs_files_list);
+ list_add_tail(_attr_handle_serial_number.head,
>sysfs_files_list);
+ list_add_tail(_attr_handle_pcie_replay_count.head,
>sysfs_files_list);
+ mutex_unlock(>sysfs_files_list_lock);
}
if (IS_ENABLED(CONFIG_PERF_EVENTS))
@@ -3298,6 +3314,16 @@ int amdgpu_device_init(struct amdgpu_device *adev,
return r;
}
+static void amdgpu_sysfs_remove_files(struct amdgpu_device *adev)
[PATCH v2 7/8] drm/amdgpu: Fix sdma code crash post device unplug
entity->rq becomes null aftre device unplugged so just return early
in that case.
Signed-off-by: Andrey Grodzovsky
---
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_DW 256u
#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, )) {
+ r = -ENODEV;
+ goto nodev;
+ }
entity = p->immediate ? >vm->immediate : >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, );
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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/8] drm/ttm: Remap all page faults to per process dummy page.
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)
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, )) {
+ 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*/
+ } else {
+ struct drm_gem_object *gobj;
+
+ mutex_lock(>filelist_mutex);
+ list_for_each_entry(file, >filelist, lhead) {
+ spin_lock(>table_lock);
+ idr_for_each_entry(>object_idr, gobj,
handle) {
+ if (gobj == >base) {
+ dummy_page = file->dummy_page;
+ break;
+ }
+ }
+ spin_unlock(>table_lock);
+ }
+ mutex_unlock(>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 ?
+*/
+ get_page(dummy_page);
+ vmf->page = dummy_page;
+ return 0;
+ } else {
+ return VM_FAULT_SIGSEGV;
+ }
+ }
}
EXPORT_SYMBOL(ttm_bo_vm_fault);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/8] drm: Add dummy page per device or GEM object
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(>prime);
WARN_ON(!list_empty(>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(_priv->prime,
dma_buf, *handle);
+
+ if (!ret) {
+ obj->dummy_page = alloc_page(GFP_KERNEL | __GFP_ZERO);
+ if (!obj->dummy_page)
+ ret = -ENOMEM;
+ }
+
mutex_unlock(_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;
};
/**
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/8] RFC Support hot device unplug in amdgpu
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 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/amdgpu/amdgpu_kms.c | 23 +++--- drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 8 +++- drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 3 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c | 21 ++--- 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 +++-- drivers/gpu/drm/drm_file.c | 8 drivers/gpu/drm/drm_prime.c | 10
