[AMD Official Use Only]
@Daniel Vetter @Grodzovsky, Andrey @Koenig, Christian
Do you have any concern on the kthread_park() approach ?
Theoretically speaking sched_main shall run there exclusively with job_timeout
since they both touches jobs, and stop scheduler during job_timeout won't
impac
On Mon, 16 Aug 2021 16:30:46 +0200
lnx7...@gregdf.com wrote:
> From: Greg Depoire--Ferrer
>
> Commit 69de4421bb4c ("drm/ttm: Initialize debugfs from
> ttm_global_init()") unintentionally made ttm_global_init() return
> early with an error when debugfs_create_file() fails. When
> CONFIG_DEBUG_FS
Note that you do not want GUP to succeed on device page, i do not see
where that is handled in the new code.
On Sun, Aug 15, 2021 at 1:40 PM John Hubbard wrote:
>
> On 8/15/21 8:37 AM, Christoph Hellwig wrote:
> >> diff --git a/include/linux/mm.h b/include/linux/mm.h
> >> index 8ae31622deef..d48a
Hello,
syzbot found the following issue on:
HEAD commit:614cb2751d31 Merge tag 'trace-v5.14-rc6' of git://git.kern..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1462cb6130
kernel config: https://syzkaller.appspot.com/x/.config?x=96f0602203250753
das
This was found by coccicheck:
./drivers/gpu/drm/kmb/kmb_drv.c:503:2-8:
ERROR missing put_device; call of_find_device_by_node on line 490,
but without a corresponding object release within this function.
Reported-by: Zeal Robot
Signed-off-by: jing yangyang
---
drivers/gpu/drm/kmb/kmb_drv.c | 7
Kees Cook writes:
> In preparation for FORTIFY_SOURCE performing compile-time and run-time
> field bounds checking for memset(), avoid intentionally writing across
> neighboring fields.
>
> Use memset_startat() so memset() doesn't get confused about writing
> beyond the destination member that is
No, that perfectly works for me.
The problem we used to have with this approach was that we potentially
have multiple timeouts at the same time.
But when we serialize the timeout handling by using a single workqueue
as suggested by Daniel now as well then that isn't an issue any more.
Regar
On Fri, Aug 20, 2021 at 1:06 AM Jason Gunthorpe wrote:
> On Wed, Aug 18, 2021 at 11:34:51AM +0200, Daniel Vetter wrote:
> > On Wed, Aug 18, 2021 at 9:45 AM Gal Pressman wrote:
> > >
> > > Hey all,
> > >
> > > Currently, the RDMA subsystem can only work with dynamic dmabuf
> > > attachments, which
On Thu, Aug 19, 2021 at 11:00 AM Sierra Guiza, Alejandro (Alex)
wrote:
>
>
> On 8/18/2021 2:28 PM, Ralph Campbell wrote:
> > On 8/17/21 5:35 PM, Felix Kuehling wrote:
> >> Am 2021-08-17 um 8:01 p.m. schrieb Ralph Campbell:
> >>> On 8/12/21 11:31 PM, Alex Sierra wrote:
> From: Ralph Campbell
On Thu, Aug 19, 2021 at 10:05 PM Christoph Hellwig wrote:
>
> On Tue, Aug 17, 2021 at 11:44:54AM -0400, Felix Kuehling wrote:
> > >> That's a good catch. Existing drivers shouldn't need a page_free
> > >> callback if they didn't have one before. That means we need to add a
> > >> NULL-pointer chec
Kees Cook writes:
> In preparation for FORTIFY_SOURCE performing compile-time and run-time
> field bounds checking for memset(), avoid intentionally writing across
> neighboring fields.
>
> Add a struct_group() for the spe registers so that memset() can correctly
> reason
> about the size:
>
>
Le 20/08/2021 à 09:49, Michael Ellerman a écrit :
Kees Cook writes:
In preparation for FORTIFY_SOURCE performing compile-time and run-time
field bounds checking for memset(), avoid intentionally writing across
neighboring fields.
Add a struct_group() for the spe registers so that memset() c
Users reported that after commit 2bbd6dba84d4 ("drm/i915: Try to use
fast+narrow link on eDP again and fall back to the old max strategy on
failure"), the screen starts to have wobbly effect.
Commit a5c936add6a2 ("drm/i915/dp: Use slow and wide link training for
everything") doesn't help either, t
[Why]
for bailing job, this commit will delete it from pending list thus the
bailing job will never have a chance to be resubmitted even in advance
tdr mode.
[How]
after embeded hw_fence into amdgpu_job is done, the race condition that
this commit tries to work around is completely solved.So rever
Hi Ezequiel,
Thanks for your detail feedback.
On Thu, 2021-08-19 at 11:10 -0300, Ezequiel Garcia wrote:
> On Thu, 19 Aug 2021 at 04:13, yunfei.d...@mediatek.com
> wrote:
> >
> > Hi Ezequiel,
> >
> > Thanks for your suggestion.
> >
> > On Wed, 2021-08-18 at 11:11 -0300, Ezequiel Garcia wrote:
>
Hi, Jason:
On Thu, 2021-08-19 at 10:23 +0800, jason-jh.lin wrote:
> Add MERGE engine file:
> MERGE module is used to merge two slice-per-line inputs
> into one side-by-side output.
>
> Signed-off-by: jason-jh.lin
> ---
[snip]
> +
> +int mtk_merge_clk_enable(struct device *dev)
> +{
> + int
Hi,
Thanks for all the helpful feedback on the previous version.
Taking all the suggestions together, this series now converts
drm_device.master_mutex into master_rwsem, and also attempts to remove
drm_file.master_lookup_lock. There might still be lock inversions
lurking, so the output from Intel
drm_master_release can be called on a drm_file without a master, which
results in a null ptr dereference of file_priv->master->magic_map. The
three cases are:
1. Error path in drm_open_helper
drm_open():
drm_open_helper():
drm_master_open():
drm_new_set_master(); <--- returns -
drm_device.master_mutex currently protects the following:
- drm_device.master
- drm_file.master
- drm_file.was_master
- drm_file.is_master
- drm_master.unique
- drm_master.unique_len
- drm_master.magic_map
There is a clear separation between functions that read or change
these attributes. Hence, c
In a future patch, a read lock on drm_device.master_rwsem is
held in the ioctl handler before the check for ioctl
permissions. However, this inverts the lock hierarchy of
drm_global_mutex --> master_rwsem.
To avoid this, we do some prep work to grab the drm_global_mutex
before checking for ioctl p
In drm_client_modeset.c and drm_fb_helper.c,
drm_master_internal_{acquire,release} are used to avoid races with DRM
userspace. These functions hold onto drm_device.master_rwsem while
committing, and bail if there's already a master.
However, there are other places where modesetting rights can race
Previously, master_lookup_lock was introduced in
commit 0b0860a3cf5e ("drm: serialize drm_file.master with a new
spinlock") to serialize accesses to drm_file.master. This then allowed
us to write drm_file_get_master in commit 56f0729a510f ("drm: protect
drm_master pointers in drm_lease.c").
The ra
Clean up the following includecheck warning:
./drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c: linux/phy/phy.h is
included more than once.
Reported-by: Abaci Robot
Fixes: 71f68fe7f121 ("drm/rockchip: dsi: add ability to work as a phy instead
of full dsi")
Signed-off-by: Jiapeng Chong
---
dri
Hi, Nancy:
On Wed, 2021-08-18 at 17:18 +0800, Nancy.Lin wrote:
> Add MDP_RDMA driver for MT8195. MDP_RDMA is the DMA engine of
> the ovl_adaptor component.
>
> Signed-off-by: Nancy.Lin
> ---
[snip]
> +
> +#define MDP_RDMA_EN0x000
> +#define FLD_ROT_
The auo,b101uan08.3 panel (already supported by this driver) has
a 3.3V rail that needs to be turned on. For previous users of
this panel this voltage was directly output by pmic. On a new
user (the not-yet-upstream sc7180-trogdor-mrbland board) we need
to turn the 3.3V rail on. Add support in the
We want to test the upstream progress.
Signed-off-by: xuxinxiong
---
drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
index dc49079a74d1..ce7437d1b
[Public]
> -Original Message-
> From: Lyude Paul
> Sent: Thursday, August 19, 2021 2:59 AM
> To: Lin, Wayne ; dri-devel@lists.freedesktop.org
> Cc: Kazlauskas, Nicholas ; Wentland, Harry
> ; Zuo, Jerry
> ; Wu, Hersen ; Juston Li
> ; Imre Deak ;
> Ville Syrjälä ; Daniel Vetter
> ; Sean
On Fri, Aug 20, 2021 at 01:37:13AM +0300, Dmitry Osipenko wrote:
> 19.08.2021 20:03, Thierry Reding пишет:
> > On Tue, Aug 17, 2021 at 04:27:40AM +0300, Dmitry Osipenko wrote:
> >> The SDHCI on Tegra belongs to the core power domain and we're going to
> >> enable GENPD support for the core domain.
On Fri, Aug 20, 2021 at 01:09:46AM +0300, Dmitry Osipenko wrote:
> 19.08.2021 19:54, Thierry Reding пишет:
> > On Wed, Aug 18, 2021 at 08:11:03PM +0300, Dmitry Osipenko wrote:
> >> 18.08.2021 19:42, Thierry Reding пишет:
> >>> On Wed, Aug 18, 2021 at 06:05:21PM +0300, Dmitry Osipenko wrote:
>
Hi Andrew,
Daniel suggested that I ping you once more about this.
Basically we want to add a barrier function to make sure that our TTM pool
shrinker is not freeing up pages from a device while the device is being
unplugged.
Currently we are having a global mutex to serialize all of this, but
Switch back to using a spinlock again by moving the IOMMU unmap outside
of the locked region.
This avoids contention especially while freeing pages.
v2: Add a comment explaining why we need sync_shrinkers().
Signed-off-by: Christian König
Acked-by: Huang Rui
Reviewed-by: Daniel Vetter
---
dr
From: Christian König
While unplugging a device the TTM shrinker implementation
needs a barrier to make sure that all concurrent shrink
operations are done and no other CPU is referring to a
device specific pool any more.
Taking and releasing the shrinker semaphore on the write
side after unmapp
Hi all,
I just submit a v3 patch according your opinion on using kthread_park
instead.
Thanks,
Jingwen
On Fri Aug 20, 2021 at 09:20:42AM +0200, Christian König wrote:
> No, that perfectly works for me.
>
> The problem we used to have with this approach was that we potentially have
> multiple tim
Christophe Leroy writes:
> Le 20/08/2021 à 09:49, Michael Ellerman a écrit :
>> Kees Cook writes:
>>> In preparation for FORTIFY_SOURCE performing compile-time and run-time
>>> field bounds checking for memset(), avoid intentionally writing across
>>> neighboring fields.
>>>
>>> Add a struct_grou
On Fri, Aug 20, 2021 at 09:25:30AM +0200, Daniel Vetter wrote:
> On Fri, Aug 20, 2021 at 1:06 AM Jason Gunthorpe wrote:
> > On Wed, Aug 18, 2021 at 11:34:51AM +0200, Daniel Vetter wrote:
> > > On Wed, Aug 18, 2021 at 9:45 AM Gal Pressman wrote:
> > > >
> > > > Hey all,
> > > >
> > > > Currently,
On Thu, Aug 19, 2021 at 11:14:37AM -0700, Kees Cook wrote:
> Which do you mean? When doing the conversions I tended to opt for
> struct_group() since it provides more robust "intentionality". Strictly
> speaking, the new memset helpers are doing field-spanning writes, but the
> "clear to the end"
On Thu, 19 Aug 2021 at 21:35, Dmitry Osipenko wrote:
>
> 19.08.2021 16:07, Ulf Hansson пишет:
> > On Wed, 18 Aug 2021 at 17:43, Dmitry Osipenko wrote:
> >>
> >> 18.08.2021 13:08, Ulf Hansson пишет:
> >>> On Wed, 18 Aug 2021 at 11:50, Viresh Kumar
> >>> wrote:
>
> On 18-08-21, 11:41, U
On Fri, 20 Aug 2021 at 07:18, Viresh Kumar wrote:
>
> On 19-08-21, 16:55, Ulf Hansson wrote:
> > Right, that sounds reasonable.
> >
> > We already have pm_genpd_opp_to_performance_state() which translates
> > an OPP to a performance state. This function invokes the
> > ->opp_to_performance_state()
On Tue, 17 Aug 2021, Kees Cook wrote:
> In preparation for FORTIFY_SOURCE performing compile-time and run-time
> field bounds checking for memcpy(), memmove(), and memset(), avoid
> intentionally writing across neighboring fields.
>
> Use struct_group() in struct cp2112_string_report around membe
On Tue, 17 Aug 2021, Kees Cook wrote:
> In preparation for FORTIFY_SOURCE performing compile-time and run-time
> field bounds checking for memset(), avoid intentionally writing across
> neighboring fields.
>
> Add struct_group() to mark region of struct kone_mouse_event that should
> be initializ
[...]
> >
> > I'm creating platform device for the clocks that require DVFS. These
> > clocks don't use regulator, they are attached to the CORE domain.
> > GENPD framework manages the performance state, aggregating perf votes
> > from each device, i.e. from each clock individually.
> >
> > You wa
I believe we have some minor confusion here
On 2021-08-20 4:09 a.m., Jingwen Chen wrote:
Hi all,
I just submit a v3 patch according your opinion on using kthread_park
instead.
Thanks,
Jingwen
On Fri Aug 20, 2021 at 09:20:42AM +0200, Christian König wrote:
No, that perfectly works for me.
The
On 2021-08-20 3:12 a.m., Liu, Monk wrote:
[AMD Official Use Only]
@Daniel Vetter @Grodzovsky, Andrey @Koenig, Christian
Do you have any concern on the kthread_park() approach ?
Theoretically speaking sched_main shall run there exclusively with job_timeout
since they both touches jobs, an
On Fri, Aug 20, 2021 at 03:58:33PM +0300, Gal Pressman wrote:
> Though it would've been nicer if we could agree on a solution that could work
> for more than 1-2 RDMA devices, using the existing tools the RDMA subsystem
> has.
I don't think it can really be done, revoke is necessary, and isn't a
On Fri, Aug 20, 2021, 6:02 AM Jiri Kosina wrote:
> On Tue, 17 Aug 2021, Kees Cook wrote:
>
> > In preparation for FORTIFY_SOURCE performing compile-time and run-time
> > field bounds checking for memset(), avoid intentionally writing across
> > neighboring fields.
> >
> > Add struct_group() to ma
On Fri, Aug 20, 2021, 6:01 AM Jiri Kosina wrote:
> On Tue, 17 Aug 2021, Kees Cook wrote:
>
> > In preparation for FORTIFY_SOURCE performing compile-time and run-time
> > field bounds checking for memcpy(), memmove(), and memset(), avoid
> > intentionally writing across neighboring fields.
> >
> >
On Fri, 20 Aug 2021, Kees Cook wrote:
> > > In preparation for FORTIFY_SOURCE performing compile-time and run-time
> > > field bounds checking for memset(), avoid intentionally writing across
> > > neighboring fields.
> > >
> > > Add struct_group() to mark region of struct kone_mouse_event that sh
On Thu, Aug 19, 2021 at 4:14 PM Kees Cook wrote:
>
> In preparation for FORTIFY_SOURCE performing compile-time and run-time
> field bounds checking for memcpy(), memmove(), and memset(), avoid
> intentionally writing across neighboring fields.
>
> The "Board Parameters" members of the structs:
>
Hi, Jason:
jason-jh.lin 於 2021年8月19日 週四 上午10:23寫道：
>
> Add MERGE engine file:
> MERGE module is used to merge two slice-per-line inputs
> into one side-by-side output.
>
> Signed-off-by: jason-jh.lin
> ---
> drivers/gpu/drm/mediatek/Makefile | 1 +
> drivers/gpu/drm/mediatek/mtk_dis
Move vga_arb_integrated_gpu() earlier in file to prepare for future patch.
No functional change intended.
[bhelgaas: split to separate patch]
Signed-off-by: Huacai Chen
Signed-off-by: Bjorn Helgaas
---
drivers/pci/vgaarb.c | 28 ++--
1 file changed, 14 insertions(+), 14
Current default VGA device selection fails in some cases:
- On BMC system, the AST2500 bridge [1a03:1150] does not implement
PCI_BRIDGE_CTL_VGA [1]. This is perfectly legal but means the
legacy VGA resources won't reach downstream devices unless they're
included in the usual bridge
From: Bjorn Helgaas
Per Documentation/process/license-rules.rst, the SPDX MIT identifier is
equivalent to including the entire MIT license text from
LICENSES/preferred/MIT.
Replace the MIT license text with the equivalent SPDX identifier.
Signed-off-by: Bjorn Helgaas
---
drivers/pci/vgaarb.c
syzbot has bisected this issue to:
commit ea40d7857d5250e5400f38c69ef9e17321e9c4a2
Author: Daniel Vetter
Date: Fri Oct 9 23:21:56 2020 +
drm/vkms: fbdev emulation support
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=11c31d5530
start commit: 614cb2751d31 Merge tag
Previously vga_arb_device_init() iterated through all VGA devices and
indicated whether legacy VGA routing to each could be controlled by an
upstream bridge.
But we determine that information in vga_arbiter_add_pci_device(), which we
call for every device, so we can log it there without iterating
If there's no default VGA device, and we find a VGA device that owns the
legacy VGA resources, we make that device the default. Split this logic
out from vga_arbiter_add_pci_device() into a new function,
vga_arb_update_default_device().
[bhelgaas: split another piece to separate patch]
Signed-off
My original work is at [1].
Bjorn do some rework and extension in V2. It moves the VGA arbiter to
the PCI subsystem, fixes a few nits, and breaks a few pieces to make
the main patch a little smaller.
V3 rewrite the commit log of the last patch (which is also summarized
by Bjorn).
All comments we
From: Bjorn Helgaas
The VGA arbiter is really PCI-specific and doesn't depend on any GPU
things. Move it to the PCI subsystem.
Signed-off-by: Bjorn Helgaas
---
drivers/gpu/vga/Kconfig | 19 ---
drivers/gpu/vga/Makefile | 1 -
drivers/pci/Kconfig
Use the vga_default_device() interface consistently instead of directly
testing vga_default. No functional change intended.
[bhelgaas: split to separate patch and extended]
Signed-off-by: Huacai Chen
Signed-off-by: Bjorn Helgaas
---
drivers/pci/vgaarb.c | 6 +++---
1 file changed, 3 insertions
From: Bjorn Helgaas
In struct vga_device, io_lock_cnt and mem_lock_cnt are unsigned, but we
previously printed them with "%d", the signed decimal format. Print them
with the unsigned format "%u" instead.
Signed-off-by: Bjorn Helgaas
---
drivers/pci/vgaarb.c | 2 +-
1 file changed, 1 insertion
From: Bjorn Helgaas
vga_arb_device_card_gone() has always been empty. Remove it.
Signed-off-by: Bjorn Helgaas
---
drivers/pci/vgaarb.c | 16 +---
1 file changed, 1 insertion(+), 15 deletions(-)
diff --git a/drivers/pci/vgaarb.c b/drivers/pci/vgaarb.c
index e4153ab70481..c984c76b3
On Fri, Aug 20, 2021 at 03:01:43PM +0200, Jiri Kosina wrote:
> On Tue, 17 Aug 2021, Kees Cook wrote:
>
> > In preparation for FORTIFY_SOURCE performing compile-time and run-time
> > field bounds checking for memcpy(), memmove(), and memset(), avoid
> > intentionally writing across neighboring fiel
In
commit 8e02cceb1f1f4f254625e5338dd997ff61ab40d7
Author: Daniel Vetter
Date: Tue Aug 3 14:48:33 2021 +0200
drm/i915: delete gpu reloc code
I deleted the gpu relocation code and the selftest include and
enabling, but accidentally forgot about the selftest source code.
Fix this oversight
On Fri, Aug 20, 2021 at 05:27:35PM +0200, Jiri Kosina wrote:
> On Fri, 20 Aug 2021, Kees Cook wrote:
>
> > > > In preparation for FORTIFY_SOURCE performing compile-time and run-time
> > > > field bounds checking for memset(), avoid intentionally writing across
> > > > neighboring fields.
> > > >
>
On Thu, Jul 29, 2021 at 12:39:12PM +0300, Leon Romanovsky wrote:
> +/**
> + * __sg_free_table - Free a previously mapped sg table
> + * @table: The sg table header to use
> + * @max_ents:The maximum number of entries per single scatterlist
> + * @total_ents: The total number of entr
On Fri, Aug 20, 2021 at 05:49:35PM +1000, Michael Ellerman wrote:
> Kees Cook writes:
> > In preparation for FORTIFY_SOURCE performing compile-time and run-time
> > field bounds checking for memset(), avoid intentionally writing across
> > neighboring fields.
> >
> > Add a struct_group() for the s
On Fri, Aug 20, 2021 at 09:34:00AM -0300, Jason Gunthorpe wrote:
> On Thu, Aug 19, 2021 at 11:14:37AM -0700, Kees Cook wrote:
>
> > Which do you mean? When doing the conversions I tended to opt for
> > struct_group() since it provides more robust "intentionality". Strictly
> > speaking, the new me
On Fri, Aug 20, 2021 at 05:27:35PM +0200, Jiri Kosina wrote:
> On Fri, 20 Aug 2021, Kees Cook wrote:
>
> > > > In preparation for FORTIFY_SOURCE performing compile-time and run-time
> > > > field bounds checking for memset(), avoid intentionally writing across
> > > > neighboring fields.
> > > >
>
On Fri, Aug 20, 2021 at 12:54:25PM -0300, Jason Gunthorpe wrote:
> On Thu, Jul 29, 2021 at 12:39:12PM +0300, Leon Romanovsky wrote:
>
> > +/**
> > + * __sg_free_table - Free a previously mapped sg table
> > + * @table: The sg table header to use
> > + * @max_ents: The maximum number of entrie
On Tue, Aug 03, 2021 at 11:06:52AM +0200, Thomas Zimmermann wrote:
> Drop the DRM IRQ midlayer in favor of Linux IRQ interfaces. DRM's
> IRQ helpers are mostly useful for UMS drivers. Modern KMS drivers
> don't benefit from using it.
>
> DRM IRQ callbacks are now being called directly or inlined.
On Thu, Aug 19, 2021 at 09:07:26PM +0300, Ville Syrjälä wrote:
> > ef79d62b5ce5 ("drm/i915: Encapsulate dbuf state handling harder")
> >
> > With that commit the display is not detected anymore, one commit
> > before that it still works. So this one seems to be broken.
> >
> > Ville, Stanislav, a
On Fri, 20 Aug 2021, Kees Cook wrote:
> > > > > In preparation for FORTIFY_SOURCE performing compile-time and run-time
> > > > > field bounds checking for memset(), avoid intentionally writing across
> > > > > neighboring fields.
> > > > >
> > > > > Add struct_group() to mark region of struct kone
On Thu, Jul 29, 2021 at 12:39:10PM +0300, Leon Romanovsky wrote:
> From: Leon Romanovsky
>
> Changelog:
> v3:
> * Rewrote to new API suggestion
> * Split for more patches
> v2: https://lore.kernel.org/lkml/cover.1626605893.git.leo...@nvidia.com
> * Changed implementation of first patch, based
On Fri, Aug 13, 2021 at 04:01:06PM +0200, Thomas Hellström wrote:
>
> On 8/13/21 1:36 PM, Dan Carpenter wrote:
> > If the intel_engine_create_pinned_context() function returns an error
> > pointer, then dereferencing "ce" will Oops. Use "vm" instead of
> > "ce->vm".
> >
> > Fixes: cf586021642d (
Hi Andrzej,
On Wed, Aug 04, 2021 at 04:09:38PM +0200, a.hajda wrote:
> Hi Maxime,
>
> I have been busy with other tasks, and I did not follow the list last
> time, so sorry for my late response.
>
> On 28.07.2021 15:32, Maxime Ripard wrote:
> > Hi,
> >
> > We've encountered an issue with the R
On Fri, Aug 20, 2021 at 05:49:32PM +0200, Daniel Vetter wrote:
> In
>
> commit 8e02cceb1f1f4f254625e5338dd997ff61ab40d7
> Author: Daniel Vetter
> Date: Tue Aug 3 14:48:33 2021 +0200
>
> drm/i915: delete gpu reloc code
it would be better with dim cite format...
do we need the Fixes: tag?
Hi Dave, Daniel,
Updates for 5.15. Mainly bug fixes and cleanups.
The following changes since commit 554594567b1fa3da74f88ec7b2dc83d000c58e98:
drm/display: fix possible null-pointer dereference in dcn10_set_clock()
(2021-08-11 17:19:54 -0400)
are available in the Git repository at:
https
On Fri, Aug 20, 2021 at 03:52:59PM +0800, Kai-Heng Feng wrote:
> Users reported that after commit 2bbd6dba84d4 ("drm/i915: Try to use
> fast+narrow link on eDP again and fall back to the old max strategy on
> failure"), the screen starts to have wobbly effect.
>
> Commit a5c936add6a2 ("drm/i915/dp
Hi Dave, Daniel,
things are still slow in etnaviv land. Just one hardware support
addition for the GPU found on the NXP Layerscape LS1028A SoC from
Michael and the GEM mmap cleanup from Thomas.
Regards,
Lucas
The following changes since commit 8a02ea42bc1d4c448caf1bab0e05899dad503f74:
Merge t
Hello drm-misc and drm-intel maintainers,
My "Add support for out-of-band hotplug notification" patchset:
https://patchwork.freedesktop.org/series/93763/
Is ready for merging now, as discussed on IRC I based this series
on top drm-tip and when trying to apply the i915 parts on top
of drm-misc thi
On Fri, Aug 20, 2021 at 7:00 PM Rodrigo Vivi wrote:
>
> On Fri, Aug 20, 2021 at 05:49:32PM +0200, Daniel Vetter wrote:
> > In
> >
> > commit 8e02cceb1f1f4f254625e5338dd997ff61ab40d7
> > Author: Daniel Vetter
> > Date: Tue Aug 3 14:48:33 2021 +0200
> >
> > drm/i915: delete gpu reloc code
>
>
On Wed, Aug 18, 2021 at 8:18 AM Thierry Reding wrote:
>
> On Wed, Aug 18, 2021 at 11:24:28AM +0300, Mikko Perttunen wrote:
> > On 8/18/21 12:20 AM, Rob Herring wrote:
> > > On Wed, Aug 11, 2021 at 01:50:28PM +0300, Mikko Perttunen wrote:
> > > > Add YAML device tree bindings for NVDEC, now in a mo
On 8/18/2021 11:16 PM, Matthew Brost wrote:
Kick tasklet after queuing a request so it submitted in a timely manner.
Fixes: 3a4cdf1982f0 ("drm/i915/guc: Implement GuC context operations for new
inteface")
Is this actually a bug or just a performance issue? in the latter case I
don't think
On Fri, Aug 20, 2021 at 11:31:56AM -0700, Daniele Ceraolo Spurio wrote:
>
>
> On 8/18/2021 11:16 PM, Matthew Brost wrote:
> > Kick tasklet after queuing a request so it submitted in a timely manner.
> >
> > Fixes: 3a4cdf1982f0 ("drm/i915/guc: Implement GuC context operations for
> > new intefac
On 8/18/2021 11:16 PM, Matthew Brost wrote:
When unblocking a context, do not enable scheduling if the context is
banned, guc_id invalid, or not registered.
Fixes: 62eaf0ae217d ("drm/i915/guc: Support request cancellation")
Signed-off-by: Matthew Brost
Cc:
---
drivers/gpu/drm/i915/gt/uc/i
On Fri, Aug 20, 2021 at 11:42:38AM -0700, Daniele Ceraolo Spurio wrote:
>
>
> On 8/18/2021 11:16 PM, Matthew Brost wrote:
> > When unblocking a context, do not enable scheduling if the context is
> > banned, guc_id invalid, or not registered.
> >
> > Fixes: 62eaf0ae217d ("drm/i915/guc: Support r
Hi
Am 20.08.21 um 17:45 schrieb syzbot:
syzbot has bisected this issue to:
Good bot!
commit ea40d7857d5250e5400f38c69ef9e17321e9c4a2
Author: Daniel Vetter
Date: Fri Oct 9 23:21:56 2020 +
drm/vkms: fbdev emulation support
Here's a guess.
GEM SHMEM + fbdev emulation requires t
On Fri, Aug 20, 2021 at 9:23 PM Thomas Zimmermann wrote:
> Hi
>
> Am 20.08.21 um 17:45 schrieb syzbot:
> > syzbot has bisected this issue to:
>
> Good bot!
>
> >
> > commit ea40d7857d5250e5400f38c69ef9e17321e9c4a2
> > Author: Daniel Vetter
> > Date: Fri Oct 9 23:21:56 2020 +
> >
> > dr
On Thu, Aug 19, 2021 at 1:22 AM Matthew Brost wrote:
>
> Propagating errors to dependent fences is wrong, don't do it. A selftest
> in the following exposed the propagating of an error to a dependent
> fence after an engine reset.
I feel like we could still have a bit of a better message. Maybe
On Fri, Aug 20, 2021 at 04:17:24PM +0200, Christoph Hellwig wrote:
> On Thu, Aug 19, 2021 at 04:29:29PM +0800, Zhenyu Wang wrote:
> > I'm working on below patch to resolve this. But I met a weird issue in
> > case when building i915 as module and also kvmgt module, it caused
> > busy wait on reques
The pull request you sent on Fri, 20 Aug 2021 15:36:29 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2021-08-20-3
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/8ba9fbe1e4b8a28050c283792344ee8b6bc3465c
Thank you!
--
Deet-doot-dot, I am a bot.
https:/
Being able to have the refcount manipulation in an assignment makes
it much easier to parse the code.
Cc: sta...@vger.kernel.org # 5.4
Signed-off-by: Lucas Stach
Tested-by: Michael Walle
---
drivers/gpu/drm/etnaviv/etnaviv_buffer.c | 3 +--
drivers/gpu/drm/etnaviv/etnaviv_gem.c| 3 +
The prev context is the MMU context at the time of the job
queueing in hardware. As a job might be queued multiple times
due to recovery after a GPU hang, we need to make sure to put
the stale prev MMU context from a prior queuing, to avoid the
reference and thus the MMU context leaking.
Cc: sta..
When we forcefully evict a mapping from the the address space and thus the
MMU context, the MMU context is leaked, as the mapping no longer points to
it, so it doesn't get freed when the GEM object is destroyed. Add the
mssing context put to fix the leak.
Cc: sta...@vger.kernel.org # 5.4
Signed-of
Move the refcount manipulation of the MMU context to the point where the
hardware state is programmed. At that point it is also known if a previous
MMU state is still there, or the state needs to be reprogrammed with a
potentially different context.
Cc: sta...@vger.kernel.org # 5.4
Signed-off-by:
After a reset the GPU is no longer using the MMU context and may be
restarted with a different context. While the mmu_state proeprly was
cleared, the context wasn't unreferenced, leading to a memory leak.
Cc: sta...@vger.kernel.org # 5.4
Reported-by: Michael Walle
Signed-off-by: Lucas Stach
Test
When the GPU is reset both the current exec state, as well as all MMU
state is lost. Move the driver side state tracking into the reset function
to keep hardware and software state from diverging.
Cc: sta...@vger.kernel.org # 5.4
Signed-off-by: Lucas Stach
Tested-by: Michael Walle
---
drivers/g
The MMU state may be kept across a runtime suspend/resume cycle, as we
avoid a full hardware reset to keep the latency of the runtime PM small.
Don't pretend that the MMU state is lost in driver state. The MMU
context is pushed out when new HW jobs with a different context are
coming in. The only
While the DMA frontend can only be active when the MMU context is set, the
reverse isn't necessarily true, as the frontend can be stopped while the
MMU state is kept. Stop treating mmu_context being set as a indication that
the frontend is running and instead add a explicit property.
Cc: sta...@vg
On Fri, 2021-08-20 at 11:20 +, Lin, Wayne wrote:
> [Public]
>
> > -Original Message-
> > From: Lyude Paul
> > Sent: Thursday, August 19, 2021 2:59 AM
> > To: Lin, Wayne ; dri-devel@lists.freedesktop.org
> > Cc: Kazlauskas, Nicholas ; Wentland, Harry <
> > harry.wentl...@amd.com>; Zuo,
Chris Morgan reported UBSAN errors in panfrost and tracked them down to
the size computation in lock_region. This calculation is overcomplicated
(seemingly cargo culted from kbase) and can be simplified with kernel
helpers and some mathematical identities. The first patch in the series
rewrites the
1 - 100 of 137 matches
Mail list logo
