Re: [PATCH v9 03/10] mm/rmap: Split try_to_munlock from try_to_unmap
* Shakeel Butt [210604 20:41]:
> On Fri, Jun 4, 2021 at 1:49 PM Liam Howlett wrote:
> >
> > * Shakeel Butt [210525 19:45]:
> > > On Tue, May 25, 2021 at 11:40 AM Liam Howlett
> > > wrote:
> > > >
> > > [...]
> > > > >
> > > > > +/*
> > > > > + * Walks the vma's mapping a page and mlocks the page if any locked
> > > > > vma's are
> > > > > + * found. Once one is found the page is locked and the scan can be
> > > > > terminated.
> > > > > + */
> > > >
> > > > Can you please add that this requires the mmap_sem() lock to the
> > > > comments?
> > > >
> > >
> > > Why does this require mmap_sem() lock? Also mmap_sem() lock of which
> > > mm_struct?
> >
> >
> > Doesn't the mlock_vma_page() require the mmap_sem() for reading? The
> > mm_struct in vma->vm_mm;
> >
>
> We are traversing all the vmas where this page is mapped of possibly
> different mm_structs. I don't think we want to take mmap_sem() of all
> those mm_structs. The commit b87537d9e2fe ("mm: rmap use pte lock not
> mmap_sem to set PageMlocked") removed exactly that.
>
> >
> > From what I can see, at least the following paths have mmap_lock held
> > for writing:
> >
> > munlock_vma_pages_range() from __do_munmap()
> > munlokc_vma_pages_range() from remap_file_pages()
> >
>
> The following path does not hold mmap_sem:
>
> exit_mmap() -> munlock_vma_pages_all() -> munlock_vma_pages_range().
Isn't this the benign race referenced by Hugh in the commit you point to
below?
>
> I would really suggest all to carefully read the commit message of
> b87537d9e2fe ("mm: rmap use pte lock not mmap_sem to set
> PageMlocked").
>
> Particularly the following paragraph:
> ...
> Vlastimil Babka points out another race which this patch protects against.
> try_to_unmap_one() might reach its mlock_vma_page() TestSetPageMlocked a
> moment after munlock_vma_pages_all() did its Phase 1 TestClearPageMlocked:
> leaving PageMlocked and unevictable when it should be evictable. mmap_sem
> is ineffective because exit_mmap() does not hold it; page lock ineffective
> because __munlock_pagevec() only takes it afterwards, in Phase 2; pte lock
> is effective because __munlock_pagevec_fill() takes it to get the page,
> after VM_LOCKED was cleared from vm_flags, so visible to try_to_unmap_one.
> ...
So this is saying the race with exit_mmap() isn't benign after all?
>
> Alistair, please bring back the VM_LOCKED check with pte lock held and
> the comment "Holding pte lock, we do *not* need mmap_lock here".
>
> One positive outcome of this cleanup patch is the removal of
> unnecessary invalidation (unmapping for kvm case) of secondary mmus.
Re: [PATCH] Verify Gamma & Degamma LUT sizes in amdgpu_dm_atomic_check
Hi Mark,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on tegra-drm/drm/tegra/for-next]
[also build test WARNING on linus/master v5.13-rc4 next-20210604]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Mark-Yacoub/Verify-Gamma-Degamma-LUT-sizes-in-amdgpu_dm_atomic_check/20210605-010052
base: git://anongit.freedesktop.org/tegra/linux.git drm/tegra/for-next
config: x86_64-randconfig-a014-20210604 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project
5c0d1b2f902aa6a9cf47cc7e42c5b83bb2217cf9)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
#
https://github.com/0day-ci/linux/commit/69d2510b404de1ebb3ee54e37daff71f1df02a29
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Mark-Yacoub/Verify-Gamma-Degamma-LUT-sizes-in-amdgpu_dm_atomic_check/20210605-010052
git checkout 69d2510b404de1ebb3ee54e37daff71f1df02a29
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_color.c:288:
>> warning: This comment starts with '/**', but isn't a kernel-doc comment.
>> Refer Documentation/doc-guide/kernel-doc.rst
* Verifies that the Degamma and Gamma LUTs attached to the |crtc_state| are
of
vim +288 drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_color.c
286
287 /**
> 288 * Verifies that the Degamma and Gamma LUTs attached to the
> |crtc_state| are of
289 * the expected size.
290 * Returns 0 on success.
291 */
292 int amdgpu_dm_verify_lut_sizes(const struct drm_crtc_state *crtc_state)
293 {
294 const struct drm_color_lut *lut = NULL;
295 uint32_t size = 0;
296
297 lut = __extract_blob_lut(crtc_state->degamma_lut, );
298 if (lut && size != MAX_COLOR_LUT_ENTRIES) {
299 DRM_DEBUG_DRIVER(
300 "Invalid Degamma LUT size. Should be %u but got
%u.\n",
301 MAX_COLOR_LUT_ENTRIES, size);
302 return -EINVAL;
303 }
304
305 lut = __extract_blob_lut(crtc_state->gamma_lut, );
306 if (lut && size != MAX_COLOR_LUT_ENTRIES &&
307 size != MAX_COLOR_LEGACY_LUT_ENTRIES) {
308 DRM_DEBUG_DRIVER(
309 "Invalid Gamma LUT size. Should be %u (or %u
for legacy) but got %u.\n",
310 MAX_COLOR_LUT_ENTRIES,
MAX_COLOR_LEGACY_LUT_ENTRIES,
311 size);
312 return -EINVAL;
313 }
314
315 return 0;
316 }
317
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
[PATCH] drm/i915/display: remove duplicated argument
Fix the following coccicheck warning: ./drivers/gpu/drm/i915/display/intel_display_power.c:3081:1-28: duplicated argument to & or | This commit fixes duplicate argument. It might be a typo. But what I can do is to remove it now. Signed-off-by: Wan Jiabing --- drivers/gpu/drm/i915/display/intel_display_power.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c b/drivers/gpu/drm/i915/display/intel_display_power.c index 3e1f6ec61514..4298ae684d7d 100644 --- a/drivers/gpu/drm/i915/display/intel_display_power.c +++ b/drivers/gpu/drm/i915/display/intel_display_power.c @@ -3078,7 +3078,6 @@ intel_display_power_put_mask_in_set(struct drm_i915_private *i915, BIT_ULL(POWER_DOMAIN_PORT_DDI_C_LANES) |\ BIT_ULL(POWER_DOMAIN_PORT_DDI_LANES_D_XELPD) | \ BIT_ULL(POWER_DOMAIN_PORT_DDI_LANES_E_XELPD) | \ - BIT_ULL(POWER_DOMAIN_AUX_C) | \ BIT_ULL(POWER_DOMAIN_PORT_DDI_LANES_TC1) | \ BIT_ULL(POWER_DOMAIN_PORT_DDI_LANES_TC2) | \ BIT_ULL(POWER_DOMAIN_PORT_DDI_LANES_TC3) | \ -- 2.20.1
[PATCH] drm/amdkfd: remove duplicate include of kfd_svm.h
kfd_svm.h is included duplicately in commit 42de677f7
("drm/amdkfd: register svm range").
After checking possible related header files,
remove the former one to make the code format more reasonable.
Signed-off-by: Wan Jiabing
---
drivers/gpu/drm/amd/amdkfd/kfd_process.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
index bfa6c4cd2f44..f1f40bba5c60 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
@@ -35,7 +35,6 @@
#include
#include "amdgpu_amdkfd.h"
#include "amdgpu.h"
-#include "kfd_svm.h"
struct mm_struct;
--
2.20.1
Re: [PATCH] vgaarb: Call vga_arb_device_init() after PCI enumeration
Hi, Bjorn, On Sat, Jun 5, 2021 at 3:56 AM Bjorn Helgaas wrote: > > On Fri, Jun 04, 2021 at 12:50:03PM +0800, Huacai Chen wrote: > > On Thu, Jun 3, 2021 at 2:31 AM Bjorn Helgaas wrote: > > > > > > [+cc linux-pci] > > > > > > On Wed, Jun 2, 2021 at 11:22 AM Daniel Vetter wrote: > > > > On Wed, Jun 02, 2021 at 06:36:03PM +0800, Huacai Chen wrote: > > > > > On Wed, Jun 2, 2021 at 2:03 AM Daniel Vetter wrote: > > > > > > On Tue, Jun 01, 2021 at 07:12:27PM +0200, Greg KH wrote: > > > > > > > On Tue, Jun 01, 2021 at 05:56:40PM +0200, Daniel Vetter wrote: > > > > > > > > On Fri, May 28, 2021 at 04:26:07PM +0800, Huacai Chen wrote: > > > > > > > > > We should call vga_arb_device_init() after PCI enumeration, > > > > > > > > > otherwise it > > > > > > > > > may fail to select the default VGA device. Since > > > > > > > > > vga_arb_device_init() > > > > > > > > > and PCI enumeration function (i.e., pcibios_init() or > > > > > > > > > acpi_init()) are > > > > > > > > > both wrapped by subsys_initcall(), their sequence is not > > > > > > > > > assured. So, we > > > > > > > > > use subsys_initcall_sync() instead of subsys_initcall() to > > > > > > > > > wrap vga_arb_ > > > > > > > > > device_init(). > > > > > > > > > > > > > > Trying to juggle levels like this always fails if you build the > > > > > > > code as > > > > > > > a module. > > > > > > > > > > > > > > Why not fix it properly and handle the out-of-order loading by > > > > > > > returning > > > > > > > a "deferred" error if you do not have your resources yet? > > > > > > > > > > > > It's not a driver, it's kinda a bolted-on-the-side subsytem of pci. > > > > > > So not > > > > > > something you can -EPROBE_DEFER I think, without potentially > > > > > > upsetting the > > > > > > drivers that need this. > > > > > > > > > > > > Which might mean we should move this into pci subsystem proper > > > > > > perhaps? > > > > > > Then adding the init call at the right time becomes trivial since > > > > > > we just > > > > > > plug it in at the end of pci init. > > > > > > > > > > > > Also maybe that's how distros avoid this pain, pci is built-in, > > > > > > vgaarb is > > > > > > generally a module, problem solved. > > > > > > > > > > > > Bjorn, would you take this entire vgaarb.c thing? From a quick look > > > > > > I > > > > > > don't think it has a drm-ism in it (unlike vga_switcheroo, but that > > > > > > works > > > > > > a bit differently and doesn't have this init order issue). > > > > > Emmm, this patch cannot handle the hotplug case and module case, it > > > > > just handles the case that vgaarb, drm driver and pci all built-in. > > > > > But I think this is enough, because the original problem only happens > > > > > on very few BMC-based VGA cards (BMC doesn't set the VGA Enable bit on > > > > > the bridge, which breaks vgaarb). > > > > > > > > I'm not talking aout hotplug, just ordering the various pieces > > > > correctly. > > > > That vgaarb isn't really a driver and also can't really handle hotplug > > > > is > > > > my point. I guess that got lost a bit? > > > > > > > > Anyway my proposal is essentially to do a > > > > > > > > $ git move drivers/gpu/vga/vgaarb.c drivers/pci > > > > > > > > But I just realized that vgaarb is a bool option, so module isn't > > > > possible > > > > anyway, and we could fix this by calling vgaarb from pcibios init (with > > > > an > > > > empty static inline in the header if vgaarb is disabled). That makes the > > > > dependency very explicit and guarantees it works correctly. > > > > > > pcibios_init() is also an initcall and is implemented by every arch. > > > I agree that calling vga_arb_device_init() directly from > > > pcibios_init() would probably fix this problem, and it would be really > > > nice to have it not be an initcall. But it's also kind of a pain to > > > have to update all those copies of pcibios_init(), and I would be > > > looking for a way to unify it since it's not really an arch-specific > > > thing. > > > > > > I think the simplest solution, which I suggested earlier [1], would be > > > to explicitly call vga_arbiter_add_pci_device() directly from the PCI > > > core when it enumerates a VGA device. Then there's no initcall and no > > > need for the BUS_NOTIFY_ADD/DEL_DEVICE stuff. > > > vga_arbiter_add_pci_device() could set the default VGA device when it > > > is enumerated, and change the default device if we enumerate a > > > "better" one. And hotplug VGA devices would work automatically. > > Emm, It seems that your solution has some difficulties to remove the > > whole initcall(vga_arb_device_init): we call > > vga_arbiter_add_pci_device() in pci_bus_add_device(), the > > list_for_each_entry() loop can be moved to > > vga_arbiter_check_bridge_sharing(), vga_arb_select_default_device() > > can be renamed to vga_arb_update_default_device() and be called in > > vga_arbiter_add_pci_device(), but how to handle > > misc_register(_arb_device)? > > Might need to keep
[Bug 213145] AMDGPU resets, timesout and crashes after "*ERROR* Waiting for fences timed out!"
https://bugzilla.kernel.org/show_bug.cgi?id=213145 --- Comment #5 from m...@binary-kitchen.de --- https://gitlab.freedesktop.org/mesa/mesa/-/issues/4866 seems exactly same Problem, same config as another guy. seems to be introduced with removing some check from mesa to test size of drawbuffer against zero. not yet decided if its a bug to remove this, or if radeonsi or amdgpu firmware should handle this case. there are some solutions and quickfixes posted, you could try them and report back then. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[PATCH] dma-buf: fix build due to missing export
Commit 0c6b522abc2a ("dma-buf: cleanup dma-resv shared fence debugging a bit
v2")
turned dma_resv_reset_shared_max() into a function when
CONFIG_DEBUG_MUTEXES is set, but forgot to export it. That resulted in a
broken build:
ERROR: modpost: "dma_resv_reset_shared_max"
[drivers/gpu/drm/vgem/vgem.ko] undefined!
ERROR: modpost: "dma_resv_reset_shared_max"
[drivers/gpu/drm/i915/i915.ko] undefined!
ERROR: modpost: "dma_resv_reset_shared_max"
[drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
ERROR: modpost: "dma_resv_reset_shared_max"
[drivers/gpu/drm/ttm/ttm.ko] undefined!
ERROR: modpost: "dma_resv_reset_shared_max" [drivers/gpu/drm/drm.ko]
undefined!
ERROR: modpost: "dma_resv_reset_shared_max"
[drivers/gpu/drm/drm_vram_helper.ko] undefined!
make[1]: *** [scripts/Makefile.modpost:150: modules-only.symvers] Error
1
Fixes: 0c6b522abc2a ("dma-buf: cleanup dma-resv shared fence debugging a bit
v2")
Cc: Christian König
Cc: Daniel Vetter
Cc: Sumit Semwal
Cc: "Christian König"
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Lucas De Marchi
---
drivers/dma-buf/dma-resv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
index 3964df438505..6132ba631991 100644
--- a/drivers/dma-buf/dma-resv.c
+++ b/drivers/dma-buf/dma-resv.c
@@ -226,6 +226,7 @@ void dma_resv_reset_shared_max(struct dma_resv *obj)
fence->shared_max = fence->shared_count;
}
}
+EXPORT_SYMBOL(dma_resv_reset_shared_max);
#endif
/**
--
2.31.1
Re: [PATCH] Verify Gamma & Degamma LUT sizes in amdgpu_dm_atomic_check
Hi Mark,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on tegra-drm/drm/tegra/for-next]
[also build test WARNING on linus/master v5.13-rc4 next-20210604]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Mark-Yacoub/Verify-Gamma-Degamma-LUT-sizes-in-amdgpu_dm_atomic_check/20210605-010052
base: git://anongit.freedesktop.org/tegra/linux.git drm/tegra/for-next
config: arc-allyesconfig (attached as .config)
compiler: arceb-elf-gcc (GCC) 9.3.0
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
#
https://github.com/0day-ci/linux/commit/69d2510b404de1ebb3ee54e37daff71f1df02a29
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Mark-Yacoub/Verify-Gamma-Degamma-LUT-sizes-in-amdgpu_dm_atomic_check/20210605-010052
git checkout 69d2510b404de1ebb3ee54e37daff71f1df02a29
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_color.c:288:
>> warning: This comment starts with '/**', but isn't a kernel-doc comment.
>> Refer Documentation/doc-guide/kernel-doc.rst
* Verifies that the Degamma and Gamma LUTs attached to the |crtc_state| are
of
vim +288 drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_color.c
286
287 /**
> 288 * Verifies that the Degamma and Gamma LUTs attached to the
> |crtc_state| are of
289 * the expected size.
290 * Returns 0 on success.
291 */
292 int amdgpu_dm_verify_lut_sizes(const struct drm_crtc_state *crtc_state)
293 {
294 const struct drm_color_lut *lut = NULL;
295 uint32_t size = 0;
296
297 lut = __extract_blob_lut(crtc_state->degamma_lut, );
298 if (lut && size != MAX_COLOR_LUT_ENTRIES) {
299 DRM_DEBUG_DRIVER(
300 "Invalid Degamma LUT size. Should be %u but got
%u.\n",
301 MAX_COLOR_LUT_ENTRIES, size);
302 return -EINVAL;
303 }
304
305 lut = __extract_blob_lut(crtc_state->gamma_lut, );
306 if (lut && size != MAX_COLOR_LUT_ENTRIES &&
307 size != MAX_COLOR_LEGACY_LUT_ENTRIES) {
308 DRM_DEBUG_DRIVER(
309 "Invalid Gamma LUT size. Should be %u (or %u
for legacy) but got %u.\n",
310 MAX_COLOR_LUT_ENTRIES,
MAX_COLOR_LEGACY_LUT_ENTRIES,
311 size);
312 return -EINVAL;
313 }
314
315 return 0;
316 }
317
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH v2] drm/panel: db7430: Add driver for Samsung DB7430
On Tue, Jun 1, 2021 at 11:31 PM Doug Anderson wrote: > Still hoping that this can work atop DBI so we can avoid the raw SPI > writes. You said you're trying for it for v3 so I'm looking forward to > checking it out there. Struggling with this. The DBI bus is only used by tiny DRM for the panel drivers that are jitted with that display controller ATM. No normal panel driver is using it. > panel-simple also sets the bpc in the "display_info". Do you need to? > > I didn't see a reply, so I'm still curious about the answer. I think it depends on whether the display controller/bridge actually make use of this or not. It is implied from the MEDIA_BUS_FMT* in practice and this controller (MCDE) only had settings for BPP, no fine grained bits to fiddle for BPC. But I added it for completeness, why not! Who knows who else will come along. I think I should patch a few other drivers with this as well. Yours, Linus Walleij
Re: [Freedreno] [PATCH 4/4] drm/msm/dp: Add support for SC8180x eDP
Quoting abhin...@codeaurora.org (2021-05-28 16:40:32) > On 2021-05-10 21:20, Bjorn Andersson wrote: > > The eDP controller found in SC8180x is at large compatible with the > > current implementation, but has its register blocks at slightly > > different offsets. > > > > Add the compatible and the new register layout. > > > I am not able to completely recall the history of why in the DP bindings > we added DP register base as a big hunk and let catalog handle the > submodule > offsets. I complained that there were many I/O regions for the DP block that didn't seem to be changing between SoCs. Nobody objected to removing it back then, but if the plan was to move things around later on then it makes sense to split it out like it was done initially. > > I guess earlier that made sense because DP sub-block offsets were fixed. > But if we plan to re-use the DP driver for eDP as well like this series, > then maybe it might be > better if this comes from device tree like the earlier version was > planning to > > https://patchwork.kernel.org/project/dri-devel/patch/0101016ec6ddf446-e87ab1ce-5cbf-40a0-a0bb-cd0151cd577a-000...@us-west-2.amazonses.com/ > Agreed.
Re: [PATCH 2/2] drm/vc4: hdmi: Convert to gpiod
On Fri, Jun 4, 2021 at 10:01 AM Maxime Ripard wrote: > On Fri, May 28, 2021 at 01:57:56AM +0200, Linus Walleij wrote: > > On Mon, May 24, 2021 at 3:19 PM Maxime Ripard wrote: > > > > > The new gpiod interface takes care of parsing the GPIO flags and to > > > return the logical value when accessing an active-low GPIO, so switching > > > to it simplifies a lot the driver. > > > > > > Signed-off-by: Maxime Ripard > > > > Thanks for fixing this! > > Reviewed-by: Linus Walleij > > Is it for both patches or just this one? I went and added Reviewed-by: to 1/2 as well so you can merge the patches. Was simple enough even though I'm not a VC4 expert. Yours, Linus Walleij
Re: [PATCH 1/2] drm/vc4: hdmi: Fix error path of hpd-gpios
On Mon, May 24, 2021 at 3:19 PM Maxime Ripard wrote:
> If the of_get_named_gpio_flags call fails in vc4_hdmi_bind, we jump to
> the err_unprepare_hsm label. That label will then call
> pm_runtime_disable and put_device on the DDC device.
>
> We just retrieved the DDC device, so the latter is definitely justified.
> However at that point we still haven't called pm_runtime_enable, so the
> call to pm_runtime_disable is not supposed to be there.
>
> Fixes: 10ee275cb12f ("drm/vc4: prepare for CEC support")
> Signed-off-by: Maxime Ripard
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
[Bug 213145] AMDGPU resets, timesout and crashes after "*ERROR* Waiting for fences timed out!"
https://bugzilla.kernel.org/show_bug.cgi?id=213145 Tomas Gayoso (tgay...@gmail.com) changed: What|Removed |Added Kernel Version|5.10.37 and 5.10.38 |5.10.37 until 5.10.42 -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 213145] AMDGPU resets, timesout and crashes after "*ERROR* Waiting for fences timed out!"
https://bugzilla.kernel.org/show_bug.cgi?id=213145 --- Comment #4 from Tomas Gayoso (tgay...@gmail.com) --- Created attachment 297161 --> https://bugzilla.kernel.org/attachment.cgi?id=297161=edit 5.10.42 dmesg output with crash aftrer reset Bug is still present on 5.10.42. Locking and crashing X after driver fails to reset. Attaching dmesg output. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[drm-intel:drm-intel-gt-next 1/19] drivers/gpu/drm/i915/gt/uc/intel_uc.c:162:20: error: function 'guc_communication_enabled' is not needed and will not be emitted
tree: git://anongit.freedesktop.org/drm-intel drm-intel-gt-next
head: 84bdf4571d4dc36207bbc4b0fb2711723ee313d4
commit: 1fb12c5871521eab5fa428bf265841b1a3827a97 [1/19] drm/i915/guc: skip
disabling CTBs before sanitizing the GuC
config: x86_64-randconfig-r012-20210604 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project
5c0d1b2f902aa6a9cf47cc7e42c5b83bb2217cf9)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
git remote add drm-intel git://anongit.freedesktop.org/drm-intel
git fetch --no-tags drm-intel drm-intel-gt-next
git checkout 1fb12c5871521eab5fa428bf265841b1a3827a97
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
>> drivers/gpu/drm/i915/gt/uc/intel_uc.c:162:20: error: function
>> 'guc_communication_enabled' is not needed and will not be emitted
>> [-Werror,-Wunneeded-internal-declaration]
static inline bool guc_communication_enabled(struct intel_guc *guc)
^
1 error generated.
vim +/guc_communication_enabled +162 drivers/gpu/drm/i915/gt/uc/intel_uc.c
a9410a62506430 Daniele Ceraolo Spurio 2020-03-26 161
8c69bd74a00baf Daniele Ceraolo Spurio 2019-12-16 @162 static inline bool
guc_communication_enabled(struct intel_guc *guc)
8c69bd74a00baf Daniele Ceraolo Spurio 2019-12-16 163 {
8c69bd74a00baf Daniele Ceraolo Spurio 2019-12-16 164 return
intel_guc_ct_enabled(>ct);
8c69bd74a00baf Daniele Ceraolo Spurio 2019-12-16 165 }
8c69bd74a00baf Daniele Ceraolo Spurio 2019-12-16 166
:: The code at line 162 was first introduced by commit
:: 8c69bd74a00baff85f4ef46b9f79263a42e0d82c drm/i915/guc: Remove function
pointers for send/receive calls
:: TO: Daniele Ceraolo Spurio
:: CC: Daniele Ceraolo Spurio
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [Freedreno] [PATCH v3 4/4] drm/msm/dpu: hw_blk: make dpu_hw_blk empty opaque structure
On 2021-05-15 12:09, Dmitry Baryshkov wrote:
The code does not really use dpu_hw_blk fields, so drop them, making
dpu_hw_blk empty structure.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/Makefile | 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_blk.c| 24 ---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_blk.h| 4 +---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c| 2 --
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c | 2 --
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 2 --
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c | 2 --
.../gpu/drm/msm/disp/dpu1/dpu_hw_merge3d.c| 2 --
.../gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c | 2 --
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 2 --
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c| 2 --
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c| 2 +-
12 files changed, 2 insertions(+), 45 deletions(-)
delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_blk.c
diff --git a/drivers/gpu/drm/msm/Makefile
b/drivers/gpu/drm/msm/Makefile
index 610d630326bb..55dbde30c2a2 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -58,7 +58,6 @@ msm-y := \
disp/dpu1/dpu_encoder_phys_cmd.o \
disp/dpu1/dpu_encoder_phys_vid.o \
disp/dpu1/dpu_formats.o \
- disp/dpu1/dpu_hw_blk.o \
disp/dpu1/dpu_hw_catalog.o \
disp/dpu1/dpu_hw_ctl.o \
disp/dpu1/dpu_hw_interrupts.o \
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_blk.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_blk.c
deleted file mode 100644
index 1f2b74b9eb65..
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_blk.c
+++ /dev/null
@@ -1,24 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/* Copyright (c) 2017-2018, The Linux Foundation. All rights reserved.
- */
-
-#define pr_fmt(fmt)"[drm:%s:%d] " fmt, __func__, __LINE__
-
-#include
-#include
-#include
-
-#include "dpu_hw_mdss.h"
-#include "dpu_hw_blk.h"
-
-/**
- * dpu_hw_blk_init - initialize hw block object
- * @hw_blk: pointer to hw block object
- * @type: hw block type - enum dpu_hw_blk_type
- * @id: instance id of the hw block
- */
-void dpu_hw_blk_init(struct dpu_hw_blk *hw_blk, u32 type, int id)
-{
- hw_blk->type = type;
- hw_blk->id = id;
-}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_blk.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_blk.h
index 7768694b558a..52e92f37eda4 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_blk.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_blk.h
@@ -19,9 +19,7 @@ struct dpu_hw_blk;
* @refcount: reference/usage count
*/
struct dpu_hw_blk {
- u32 type;
- int id;
+ /* opaque */
};
-void dpu_hw_blk_init(struct dpu_hw_blk *hw_blk, u32 type, int id);
#endif /*_DPU_HW_BLK_H */
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
index 441f66a4fb37..f8a74f6cdc4c 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
@@ -613,8 +613,6 @@ struct dpu_hw_ctl *dpu_hw_ctl_init(enum dpu_ctl
idx,
c->mixer_count = m->mixer_count;
c->mixer_hw_caps = m->mixer;
- dpu_hw_blk_init(>base, DPU_HW_BLK_CTL, idx);
-
return c;
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c
index 977b25968f34..a98e964c3b6f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c
@@ -110,8 +110,6 @@ struct dpu_hw_dspp *dpu_hw_dspp_init(enum dpu_dspp
idx,
c->cap = cfg;
_setup_dspp_ops(c, c->cap->features);
- dpu_hw_blk_init(>base, DPU_HW_BLK_DSPP, idx);
-
return c;
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
index 17224556d5a8..116e2b5b1a90 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
@@ -325,8 +325,6 @@ struct dpu_hw_intf *dpu_hw_intf_init(enum dpu_intf
idx,
c->mdss = m;
_setup_intf_ops(>ops, c->cap->features);
- dpu_hw_blk_init(>base, DPU_HW_BLK_INTF, idx);
-
return c;
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
index 76f8b8f75b82..cb6bb7a22c15 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
@@ -182,8 +182,6 @@ struct dpu_hw_mixer *dpu_hw_lm_init(enum dpu_lm
idx,
c->cap = cfg;
_setup_mixer_ops(m, >ops, c->cap->features);
- dpu_hw_blk_init(>base, DPU_HW_BLK_LM, idx);
-
return c;
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_merge3d.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_merge3d.c
index 406ba950a066..c06d595d5df0 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_merge3d.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_merge3d.c
@@ -79,8 +79,6 @@ struct dpu_hw_merge_3d *dpu_hw_merge_3d_init(enum
[PATCH] udmabuf: Add support for mapping hugepages (v3)
If the VMM's (Qemu) memory backend is backed up by memfd + Hugepages
(hugetlbfs and not THP), we have to first find the hugepage(s) where
the Guest allocations are located and then extract the regular 4k
sized subpages from them.
v2: Ensure that the subpage and hugepage offsets are calculated correctly
when the range of subpage allocations cuts across multiple hugepages.
v3: Instead of repeatedly looking up the hugepage for each subpage,
only do it when the subpage allocation crosses over into a different
hugepage. (suggested by Gerd and DW)
Cc: Gerd Hoffmann
Signed-off-by: Vivek Kasireddy
Signed-off-by: Dongwon Kim
---
drivers/dma-buf/udmabuf.c | 51 +--
1 file changed, 44 insertions(+), 7 deletions(-)
diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
index db732f71e59a..2e02bbfe30fd 100644
--- a/drivers/dma-buf/udmabuf.c
+++ b/drivers/dma-buf/udmabuf.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
static const u32list_limit = 1024; /* udmabuf_create_list->count limit */
static const size_t size_limit_mb = 64; /* total dmabuf size, in megabytes */
@@ -163,7 +164,9 @@ static long udmabuf_create(struct miscdevice *device,
struct udmabuf *ubuf;
struct dma_buf *buf;
pgoff_t pgoff, pgcnt, pgidx, pgbuf = 0, pglimit;
- struct page *page;
+ struct page *page, *hpage = NULL;
+ pgoff_t subpgoff, maxsubpgs;
+ struct hstate *hpstate;
int seals, ret = -EINVAL;
u32 i, flags;
@@ -194,7 +197,8 @@ static long udmabuf_create(struct miscdevice *device,
memfd = fget(list[i].memfd);
if (!memfd)
goto err;
- if (!shmem_mapping(file_inode(memfd)->i_mapping))
+ if (!shmem_mapping(file_inode(memfd)->i_mapping) &&
+ !is_file_hugepages(memfd))
goto err;
seals = memfd_fcntl(memfd, F_GET_SEALS, 0);
if (seals == -EINVAL)
@@ -205,17 +209,50 @@ static long udmabuf_create(struct miscdevice *device,
goto err;
pgoff = list[i].offset >> PAGE_SHIFT;
pgcnt = list[i].size >> PAGE_SHIFT;
+ if (is_file_hugepages(memfd)) {
+ hpstate = hstate_file(memfd);
+ pgoff = list[i].offset >> huge_page_shift(hpstate);
+ subpgoff = (list[i].offset &
+ ~huge_page_mask(hpstate)) >> PAGE_SHIFT;
+ maxsubpgs = huge_page_size(hpstate) >> PAGE_SHIFT;
+ }
for (pgidx = 0; pgidx < pgcnt; pgidx++) {
- page = shmem_read_mapping_page(
- file_inode(memfd)->i_mapping, pgoff + pgidx);
- if (IS_ERR(page)) {
- ret = PTR_ERR(page);
- goto err;
+ if (is_file_hugepages(memfd)) {
+ if (!hpage) {
+ hpage = find_get_page_flags(
+ file_inode(memfd)->i_mapping,
+ pgoff, FGP_ACCESSED);
+ if (IS_ERR(hpage)) {
+ ret = PTR_ERR(hpage);
+ goto err;
+ }
+ }
+ page = hpage + subpgoff;
+ get_page(page);
+ subpgoff++;
+ if (subpgoff == maxsubpgs) {
+ put_page(hpage);
+ hpage = NULL;
+ subpgoff = 0;
+ pgoff++;
+ }
+ } else {
+ page = shmem_read_mapping_page(
+ file_inode(memfd)->i_mapping,
+ pgoff + pgidx);
+ if (IS_ERR(page)) {
+ ret = PTR_ERR(page);
+ goto err;
+ }
}
ubuf->pages[pgbuf++] = page;
}
fput(memfd);
memfd = NULL;
+ if (hpage) {
+ put_page(hpage);
+ hpage = NULL;
+ }
}
exp_info.ops = _ops;
--
2.30.2
Re: [Freedreno] [PATCH v3 3/4] drm/msm/dpu: use struct dpu_hw_merge_3d in dpu_hw_pingpong
On 2021-05-15 12:09, Dmitry Baryshkov wrote:
Use struct dpu_hw_merge_3d pointer in struct dpu_hw_pingpong rather
than using struct dpu_hw_blk. This is the only user of dpu_hw_blk.id,
which will be cleaned in the next patch.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 11 ---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h | 4 +++-
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 2 +-
3 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
index 0e06b7e73c7a..4feec24162bc 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
@@ -284,7 +284,7 @@ static void
dpu_encoder_phys_vid_setup_timing_engine(
intf_cfg.stream_sel = 0; /* Don't care value for video mode */
intf_cfg.mode_3d = dpu_encoder_helper_get_3d_blend_mode(phys_enc);
if (phys_enc->hw_pp->merge_3d)
- intf_cfg.merge_3d = phys_enc->hw_pp->merge_3d->id;
+ intf_cfg.merge_3d = phys_enc->hw_pp->merge_3d->idx;
spin_lock_irqsave(phys_enc->enc_spinlock, lock_flags);
phys_enc->hw_intf->ops.setup_timing_gen(phys_enc->hw_intf,
@@ -298,11 +298,8 @@ static void
dpu_encoder_phys_vid_setup_timing_engine(
true,
phys_enc->hw_pp->idx);
- if (phys_enc->hw_pp->merge_3d) {
- struct dpu_hw_merge_3d *merge_3d =
to_dpu_hw_merge_3d(phys_enc->hw_pp->merge_3d);
-
- merge_3d->ops.setup_3d_mode(merge_3d, intf_cfg.mode_3d);
- }
+ if (phys_enc->hw_pp->merge_3d)
+
phys_enc->hw_pp->merge_3d->ops.setup_3d_mode(phys_enc->hw_pp->merge_3d,
intf_cfg.mode_3d);
spin_unlock_irqrestore(phys_enc->enc_spinlock, lock_flags);
@@ -461,7 +458,7 @@ static void dpu_encoder_phys_vid_enable(struct
dpu_encoder_phys *phys_enc)
ctl->ops.update_pending_flush_intf(ctl, phys_enc->hw_intf->idx);
if (ctl->ops.update_pending_flush_merge_3d &&
phys_enc->hw_pp->merge_3d)
- ctl->ops.update_pending_flush_merge_3d(ctl,
phys_enc->hw_pp->merge_3d->id);
+ ctl->ops.update_pending_flush_merge_3d(ctl,
phys_enc->hw_pp->merge_3d->idx);
skip_flush:
DPU_DEBUG_VIDENC(phys_enc,
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h
index 845b9ce80e31..89d08a715c16 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h
@@ -126,6 +126,8 @@ struct dpu_hw_pingpong_ops {
struct dpu_hw_dither_cfg *cfg);
};
+struct dpu_hw_merge_3d;
+
struct dpu_hw_pingpong {
struct dpu_hw_blk base;
struct dpu_hw_blk_reg_map hw;
@@ -133,7 +135,7 @@ struct dpu_hw_pingpong {
/* pingpong */
enum dpu_pingpong idx;
const struct dpu_pingpong_cfg *caps;
- struct dpu_hw_blk *merge_3d;
+ struct dpu_hw_merge_3d *merge_3d;
/* ops */
struct dpu_hw_pingpong_ops ops;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
index fd2d104f0a91..c0eec12498e7 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
@@ -162,7 +162,7 @@ int dpu_rm_init(struct dpu_rm *rm,
goto fail;
}
if (pp->merge_3d && pp->merge_3d < MERGE_3D_MAX)
- hw->merge_3d = rm->merge_3d_blks[pp->merge_3d -
MERGE_3D_0];
+ hw->merge_3d =
to_dpu_hw_merge_3d(rm->merge_3d_blks[pp->merge_3d -
MERGE_3D_0]);
rm->pingpong_blks[pp->id - PINGPONG_0] = >base;
}
Re: [Freedreno] [PATCH v3 2/4] drm/msm/dpu: drop dpu_hw_blk_destroy function
On 2021-05-15 12:09, Dmitry Baryshkov wrote:
The dpu_hw_blk_destroy() function is empty, so we can drop it now.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_blk.c | 13 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_blk.h | 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 2 --
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c | 3 ---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 2 --
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c | 2 --
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_merge3d.c | 2 --
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c | 2 --
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 2 --
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c | 2 --
10 files changed, 31 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_blk.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_blk.c
index abad043f35f5..1f2b74b9eb65 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_blk.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_blk.c
@@ -22,16 +22,3 @@ void dpu_hw_blk_init(struct dpu_hw_blk *hw_blk, u32
type, int id)
hw_blk->type = type;
hw_blk->id = id;
}
-
-/**
- * dpu_hw_blk_destroy - destroy hw block object.
- * @hw_blk: pointer to hw block object
- * return: none
- */
-void dpu_hw_blk_destroy(struct dpu_hw_blk *hw_blk)
-{
- if (!hw_blk) {
- pr_err("invalid parameters\n");
- return;
- }
-}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_blk.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_blk.h
index fb3be9a36a50..7768694b558a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_blk.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_blk.h
@@ -24,5 +24,4 @@ struct dpu_hw_blk {
};
void dpu_hw_blk_init(struct dpu_hw_blk *hw_blk, u32 type, int id);
-void dpu_hw_blk_destroy(struct dpu_hw_blk *hw_blk);
#endif /*_DPU_HW_BLK_H */
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
index 04a2c4b9a357..441f66a4fb37 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
@@ -620,7 +620,5 @@ struct dpu_hw_ctl *dpu_hw_ctl_init(enum dpu_ctl
idx,
void dpu_hw_ctl_destroy(struct dpu_hw_ctl *ctx)
{
- if (ctx)
- dpu_hw_blk_destroy(>base);
kfree(ctx);
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c
index d2f1045a736a..977b25968f34 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c
@@ -117,9 +117,6 @@ struct dpu_hw_dspp *dpu_hw_dspp_init(enum dpu_dspp
idx,
void dpu_hw_dspp_destroy(struct dpu_hw_dspp *dspp)
{
- if (dspp)
- dpu_hw_blk_destroy(>base);
-
kfree(dspp);
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
index 6ffe97601716..17224556d5a8 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
@@ -332,8 +332,6 @@ struct dpu_hw_intf *dpu_hw_intf_init(enum dpu_intf
idx,
void dpu_hw_intf_destroy(struct dpu_hw_intf *intf)
{
- if (intf)
- dpu_hw_blk_destroy(>base);
kfree(intf);
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
index 554bb881de3a..76f8b8f75b82 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
@@ -189,7 +189,5 @@ struct dpu_hw_mixer *dpu_hw_lm_init(enum dpu_lm
idx,
void dpu_hw_lm_destroy(struct dpu_hw_mixer *lm)
{
- if (lm)
- dpu_hw_blk_destroy(>base);
kfree(lm);
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_merge3d.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_merge3d.c
index 863229dd0140..406ba950a066 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_merge3d.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_merge3d.c
@@ -86,7 +86,5 @@ struct dpu_hw_merge_3d *dpu_hw_merge_3d_init(enum
dpu_merge_3d idx,
void dpu_hw_merge_3d_destroy(struct dpu_hw_merge_3d *hw)
{
- if (hw)
- dpu_hw_blk_destroy(>base);
kfree(hw);
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
index 334d5b28f533..92cd724263ce 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
@@ -289,7 +289,5 @@ struct dpu_hw_pingpong *dpu_hw_pingpong_init(enum
dpu_pingpong idx,
void dpu_hw_pingpong_destroy(struct dpu_hw_pingpong *pp)
{
- if (pp)
- dpu_hw_blk_destroy(>base);
kfree(pp);
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
index ceb2488ea270..8734a47040aa 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
@@ -740,8 +740,6 @@ struct dpu_hw_pipe *dpu_hw_sspp_init(enum
Re: [Freedreno] [PATCH v3 1/4] drm/msm/dpu: remove unused dpu_hw_blk features
On 2021-05-15 12:09, Dmitry Baryshkov wrote:
Remove all unused dpu_hw_blk features and functions:
- dpu_hw_blk_get()/_put() and respective refcounting,
- global list of all dpu_hw_blk instances,
- dpu_hw_blk_ops and empty implementation inside each hw_blk subdriver.
This leaves dpu_hw_blk as a placeholder with just type and index.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_blk.c| 104 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_blk.h| 19 +---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c| 4 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c | 4 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 4 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c | 4 +-
.../gpu/drm/msm/disp/dpu1/dpu_hw_merge3d.c| 4 +-
.../gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c | 4 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 4 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c| 4 +-
10 files changed, 10 insertions(+), 145 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_blk.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_blk.c
index 819b26e660b9..abad043f35f5 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_blk.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_blk.c
@@ -11,33 +11,16 @@
#include "dpu_hw_mdss.h"
#include "dpu_hw_blk.h"
-/* Serialization lock for dpu_hw_blk_list */
-static DEFINE_MUTEX(dpu_hw_blk_lock);
-
-/* List of all hw block objects */
-static LIST_HEAD(dpu_hw_blk_list);
-
/**
* dpu_hw_blk_init - initialize hw block object
* @hw_blk: pointer to hw block object
* @type: hw block type - enum dpu_hw_blk_type
* @id: instance id of the hw block
- * @ops: Pointer to block operations
*/
-void dpu_hw_blk_init(struct dpu_hw_blk *hw_blk, u32 type, int id,
- struct dpu_hw_blk_ops *ops)
+void dpu_hw_blk_init(struct dpu_hw_blk *hw_blk, u32 type, int id)
{
- INIT_LIST_HEAD(_blk->list);
hw_blk->type = type;
hw_blk->id = id;
- atomic_set(_blk->refcount, 0);
-
- if (ops)
- hw_blk->ops = *ops;
-
- mutex_lock(_hw_blk_lock);
- list_add(_blk->list, _hw_blk_list);
- mutex_unlock(_hw_blk_lock);
}
/**
@@ -51,89 +34,4 @@ void dpu_hw_blk_destroy(struct dpu_hw_blk *hw_blk)
pr_err("invalid parameters\n");
return;
}
-
- if (atomic_read(_blk->refcount))
- pr_err("hw_blk:%d.%d invalid refcount\n", hw_blk->type,
- hw_blk->id);
-
- mutex_lock(_hw_blk_lock);
- list_del(_blk->list);
- mutex_unlock(_hw_blk_lock);
-}
-
-/**
- * dpu_hw_blk_get - get hw_blk from free pool
- * @hw_blk: if specified, increment reference count only
- * @type: if hw_blk is not specified, allocate the next available of
this type
- * @id: if specified (>= 0), allocate the given instance of the above
type
- * return: pointer to hw block object
- */
-struct dpu_hw_blk *dpu_hw_blk_get(struct dpu_hw_blk *hw_blk, u32 type,
int id)
-{
- struct dpu_hw_blk *curr;
- int rc, refcount;
-
- if (!hw_blk) {
- mutex_lock(_hw_blk_lock);
- list_for_each_entry(curr, _hw_blk_list, list) {
- if ((curr->type != type) ||
- (id >= 0 && curr->id != id) ||
- (id < 0 &&
- atomic_read(>refcount)))
- continue;
-
- hw_blk = curr;
- break;
- }
- mutex_unlock(_hw_blk_lock);
- }
-
- if (!hw_blk) {
- pr_debug("no hw_blk:%d\n", type);
- return NULL;
- }
-
- refcount = atomic_inc_return(_blk->refcount);
-
- if (refcount == 1 && hw_blk->ops.start) {
- rc = hw_blk->ops.start(hw_blk);
- if (rc) {
- pr_err("failed to start hw_blk:%d rc:%d\n", type, rc);
- goto error_start;
- }
- }
-
- pr_debug("hw_blk:%d.%d refcount:%d\n", hw_blk->type,
- hw_blk->id, refcount);
- return hw_blk;
-
-error_start:
- dpu_hw_blk_put(hw_blk);
- return ERR_PTR(rc);
-}
-
-/**
- * dpu_hw_blk_put - put hw_blk to free pool if decremented refcount is
zero
- * @hw_blk: hw block to be freed
- */
-void dpu_hw_blk_put(struct dpu_hw_blk *hw_blk)
-{
- if (!hw_blk) {
- pr_err("invalid parameters\n");
- return;
- }
-
- pr_debug("hw_blk:%d.%d refcount:%d\n", hw_blk->type, hw_blk->id,
- atomic_read(_blk->refcount));
-
- if (!atomic_read(_blk->refcount)) {
- pr_err("hw_blk:%d.%d invalid put\n", hw_blk->type, hw_blk->id);
- return;
- }
-
- if (atomic_dec_return(_blk->refcount))
- return;
-
- if (hw_blk->ops.stop)
-
Re: [PATCH] drm/amdgpu: Use vma_lookup() in amdgpu_ttm_tt_get_user_pages()
On Fri, Jun 4, 2021 at 7:11 AM Christian König
wrote:
>
> Am 03.06.21 um 18:09 schrieb Liam Howlett:
> > Use vma_lookup() to find the VMA at a specific address. As vma_lookup()
> > will return NULL if the address is not within any VMA, the start address
> > no longer needs to be validated.
> >
> > Signed-off-by: Liam R. Howlett
>
> Reviewed-by: Christian König
>
I'm fine to have this go through whatever tree makes sense.
Acked-by: Alex Deucher
> > ---
> > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> > index 7cb7ffdd1900..dfb5ca3f8da8 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> > @@ -680,9 +680,9 @@ int amdgpu_ttm_tt_get_user_pages(struct amdgpu_bo *bo,
> > struct page **pages)
> > return -ESRCH;
> >
> > mmap_read_lock(mm);
> > - vma = find_vma(mm, start);
> > + vma = vma_lookup(mm, start);
> > mmap_read_unlock(mm);
> > - if (unlikely(!vma || start < vma->vm_start)) {
> > + if (unlikely(!vma)) {
> > r = -EFAULT;
> > goto out_putmm;
> > }
>
Re: [PATCH v9 03/10] mm/rmap: Split try_to_munlock from try_to_unmap
* Shakeel Butt [210525 19:45]:
> On Tue, May 25, 2021 at 11:40 AM Liam Howlett wrote:
> >
> [...]
> > >
> > > +/*
> > > + * Walks the vma's mapping a page and mlocks the page if any locked
> > > vma's are
> > > + * found. Once one is found the page is locked and the scan can be
> > > terminated.
> > > + */
> >
> > Can you please add that this requires the mmap_sem() lock to the
> > comments?
> >
>
> Why does this require mmap_sem() lock? Also mmap_sem() lock of which
> mm_struct?
Doesn't the mlock_vma_page() require the mmap_sem() for reading? The
mm_struct in vma->vm_mm;
>From what I can see, at least the following paths have mmap_lock held
for writing:
munlock_vma_pages_range() from __do_munmap()
munlokc_vma_pages_range() from remap_file_pages()
>
> > > +static bool page_mlock_one(struct page *page, struct vm_area_struct *vma,
> > > + unsigned long address, void *unused)
> > > +{
> > > + struct page_vma_mapped_walk pvmw = {
> > > + .page = page,
> > > + .vma = vma,
> > > + .address = address,
> > > + };
> > > +
> > > + /* An un-locked vma doesn't have any pages to lock, continue the
> > > scan */
> > > + if (!(vma->vm_flags & VM_LOCKED))
> > > + return true;
> > > +
> > > + while (page_vma_mapped_walk()) {
> > > + /* PTE-mapped THP are never mlocked */
> > > + if (!PageTransCompound(page))
> > > + mlock_vma_page(page);
> > > + page_vma_mapped_walk_done();
> > > +
> > > + /*
> > > + * no need to continue scanning other vma's if the page has
> > > + * been locked.
> > > + */
> > > + return false;
> > > + }
> > > +
> > > + return true;
> > > +}
munlock_vma_pages_range() comments still references try_to_{munlock|unmap}
Re: [PATCH 1/2] dt-bindings: Add SONY Synaptics JDI panel
On Tue, May 25, 2021 at 01:31:02PM +0200, Konrad Dybcio wrote:
> Add bindings for the SONY Synaptics JDI panel used in
> Xperia X, X Performance, X Compact, XZ and XZs smartphones.
>
> Due to the nature of phone manufacturing and lack of any docs
> whatsoever, replacement names have been used to indicate the
> devices that this panel is used on.
>
> Signed-off-by: Konrad Dybcio
> ---
> .../display/panel/sony,synaptics-jdi.yaml | 100 ++
> 1 file changed, 100 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/panel/sony,synaptics-jdi.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/panel/sony,synaptics-jdi.yaml
> b/Documentation/devicetree/bindings/display/panel/sony,synaptics-jdi.yaml
> new file mode 100644
> index ..81d841c049e8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/sony,synaptics-jdi.yaml
> @@ -0,0 +1,100 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/sony,synaptics-jdi.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: SONY Synaptics JDI panel
> +
> +maintainers:
> + - Konrad Dybcio
> +
> +description: |+
Do you need the formatting? If not, drop '|+'.
> + This panel seems to only be found in SONY Xperia
> + X, X Performance, X Compact, XZ and XZs
> + smartphones and we have no straightforward way of
> + actually getting the correct model number,
> + as no schematics are released publicly.
Odd choice of line break length. 80 char please.
> +
> +allOf:
> + - $ref: panel-common.yaml#
> +
> +properties:
> + compatible:
> +items:
> + - enum:
> + - sony,synaptics-jdi-dora
> + - sony,synaptics-jdi-kagura
> + - sony,synaptics-jdi-keyaki
> + - sony,synaptics-jdi-kugo
> + - sony,synaptics-jdi-suzu
> +
> + reg: true
> +
> + reset-gpios: true
> +
> + avdd-supply:
> +description: avdd supply
> +
> + vddio-supply:
> +description: vddio supply
> +
> + vsn-supply:
> +description: voltage negative supply
> +
> + vsp-supply:
> +description: voltage positive supply
> +
> + tvdd-supply:
> +description: tvdd supply
> +
> + preset-gpio:
> +description: panel reset pin
What's reset-gpios then?
> +
> + pvddio-gpio:
> +description: panel vddio pin
> +
> + treset-gpio:
> +description: touch reset pin
Use '-gpios'
And need to define how many (maxItems: 1).
> +
> +required:
> + - compatible
> + - reg
> + - preset-gpio
> + - pvddio-gpio
> + - treset-gpio
> + - avdd-supply
> + - vddio-supply
> + - vsn-supply
> + - vsp-supply
> + - tvdd-supply
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +
> +dsi {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +panel: panel@0 {
> +reg = <0>;
> +
> +pvddio-gpio = < 51 GPIO_ACTIVE_HIGH>;
> +preset-gpio = < 8 GPIO_ACTIVE_HIGH>;
> +treset-gpio = < 89 GPIO_ACTIVE_HIGH>;
> +
> +vddio-supply = <_s4>;
> +avdd-supply = <_l2>;
> +tvdd-supply = <_tvdd>;
> +
> +backlight = <_wled>;
> +
> +port {
> + panel_in: endpoint {
> +remote-endpoint = <_out>;
> + };
Consistent indentation please. 4 spaces is good.
> +};
> +};
> +};
> --
> 2.31.1
Re: [PATCH] drm/amd/display: Verify Gamma & Degamma LUT sizes in amdgpu_dm_atomic_check
On 2021-06-04 1:01 p.m., Mark Yacoub wrote:
> From: Mark Yacoub
>
> For each CRTC state, check the size of Gamma and Degamma LUTs so
> unexpected and larger sizes wouldn't slip through.
>
> TEST: IGT:kms_color::pipe-invalid-gamma-lut-sizes
>
> Signed-off-by: Mark Yacoub
> Change-Id: I9d513a38e8ac2af1b4bf802e1feb1a4d726fba4c
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 ++
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 1 +
> .../amd/display/amdgpu_dm/amdgpu_dm_color.c | 40 ---
> 3 files changed, 38 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 38d497d30dba8..f6cd522b42a80 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -9402,6 +9402,9 @@ static int amdgpu_dm_atomic_check(struct drm_device
> *dev,
> dm_old_crtc_state->dsc_force_changed == false)
> continue;
>
> + if ((ret = amdgpu_dm_verify_lut_sizes(new_crtc_state)))
> + goto fail;
> +
> if (!new_crtc_state->enable)
> continue;
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> index 8bfe901cf2374..1b77cd2612691 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> @@ -541,6 +541,7 @@ void amdgpu_dm_trigger_timing_sync(struct drm_device
> *dev);
> #define MAX_COLOR_LEGACY_LUT_ENTRIES 256
>
> void amdgpu_dm_init_color_mod(void);
> +int amdgpu_dm_verify_lut_sizes(const struct drm_crtc_state *crtc_state);
> int amdgpu_dm_update_crtc_color_mgmt(struct dm_crtc_state *crtc);
> int amdgpu_dm_update_plane_color_mgmt(struct dm_crtc_state *crtc,
> struct dc_plane_state *dc_plane_state);
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
> index 157fe4efbb599..da6f9fcc0b415 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
> @@ -284,6 +284,37 @@ static int __set_input_tf(struct dc_transfer_func *func,
> return res ? 0 : -ENOMEM;
> }
>
> +/**
> + * Verifies that the Degamma and Gamma LUTs attached to the |crtc_state| are
> of
> + * the expected size.
> + * Returns 0 on success.
> + */
> +int amdgpu_dm_verify_lut_sizes(const struct drm_crtc_state *crtc_state)
> +{
> + const struct drm_color_lut *lut = NULL;
> + uint32_t size = 0;
> +
> + lut = __extract_blob_lut(crtc_state->degamma_lut, );
> + if (lut && size != MAX_COLOR_LUT_ENTRIES) {
Isn't the point of the LUT size that it can be variable? Did you observe any
problems with LUTs that are not of size 4096?
Legacy X-based userspace will give us 256 size LUTs. We can't break support for
that. See MAX_COLOR_LEGACY_LUT_ENTRIES.
Harry
> + DRM_DEBUG_DRIVER(
> + "Invalid Degamma LUT size. Should be %u but got %u.\n",
> + MAX_COLOR_LUT_ENTRIES, size);
> + return -EINVAL;
> + }
> +
> + lut = __extract_blob_lut(crtc_state->gamma_lut, );
> + if (lut && size != MAX_COLOR_LUT_ENTRIES &&
> + size != MAX_COLOR_LEGACY_LUT_ENTRIES) {
> + DRM_DEBUG_DRIVER(
> + "Invalid Gamma LUT size. Should be %u (or %u for
> legacy) but got %u.\n",
> + MAX_COLOR_LUT_ENTRIES, MAX_COLOR_LEGACY_LUT_ENTRIES,
> + size);
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> /**
> * amdgpu_dm_update_crtc_color_mgmt: Maps DRM color management to DC stream.
> * @crtc: amdgpu_dm crtc state
> @@ -317,14 +348,11 @@ int amdgpu_dm_update_crtc_color_mgmt(struct
> dm_crtc_state *crtc)
> bool is_legacy;
> int r;
>
> - degamma_lut = __extract_blob_lut(crtc->base.degamma_lut, _size);
> - if (degamma_lut && degamma_size != MAX_COLOR_LUT_ENTRIES)
> - return -EINVAL;
> + if ((r = amdgpu_dm_verify_lut_sizes(>base)))
> + return r;
>
> + degamma_lut = __extract_blob_lut(crtc->base.degamma_lut, _size);
> regamma_lut = __extract_blob_lut(crtc->base.gamma_lut, _size);
> - if (regamma_lut && regamma_size != MAX_COLOR_LUT_ENTRIES &&
> - regamma_size != MAX_COLOR_LEGACY_LUT_ENTRIES)
> - return -EINVAL;
>
> has_degamma =
> degamma_lut && !__is_lut_linear(degamma_lut, degamma_size);
>
Re: [Intel-gfx] [PATCH 5/9] drm/i915: Move engine->schedule to i915_sched_engine
On Fri, Jun 04, 2021 at 02:03:46PM -0500, Jason Ekstrand wrote:
> On Thu, Jun 3, 2021 at 4:09 PM Matthew Brost wrote:
> >
> > The schedule function should be in the schedule object.
> >
> > Signed-off-by: Matthew Brost
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_wait.c | 4 ++--
> > drivers/gpu/drm/i915/gt/intel_engine_cs.c| 3 ---
> > drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c | 4 ++--
> > drivers/gpu/drm/i915/gt/intel_engine_types.h | 8
> > drivers/gpu/drm/i915/gt/intel_engine_user.c | 2 +-
> > .../gpu/drm/i915/gt/intel_execlists_submission.c | 4 ++--
> > drivers/gpu/drm/i915/gt/selftest_execlists.c | 16
> > drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 4 ++--
> > .../gpu/drm/i915/gt/uc/intel_guc_submission.c| 2 +-
> > drivers/gpu/drm/i915/i915_request.c | 10 +-
> > drivers/gpu/drm/i915/i915_scheduler_types.h | 8
> > 11 files changed, 31 insertions(+), 34 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_wait.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_wait.c
> > index 4b9856d5ba14..af1fbf8e2a9a 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_wait.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_wait.c
> > @@ -104,8 +104,8 @@ static void fence_set_priority(struct dma_fence *fence,
> > engine = rq->engine;
> >
> > rcu_read_lock(); /* RCU serialisation for set-wedged protection */
> > - if (engine->schedule)
> > - engine->schedule(rq, attr);
> > + if (engine->sched_engine->schedule)
> > + engine->sched_engine->schedule(rq, attr);
> > rcu_read_unlock();
> > }
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > index 33d879137908..b480fcb1aad1 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > @@ -326,9 +326,6 @@ static int intel_engine_setup(struct intel_gt *gt, enum
> > intel_engine_id id)
> > if (engine->context_size)
> > DRIVER_CAPS(i915)->has_logical_contexts = true;
> >
> > - /* Nothing to do here, execute in order of dependencies */
> > - engine->schedule = NULL;
> > -
> > ewma__engine_latency_init(>latency);
> > seqcount_init(>stats.lock);
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> > b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> > index b99ac41695f3..b6a305e6a974 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> > @@ -121,7 +121,7 @@ static void heartbeat(struct work_struct *wrk)
> > * but all other contexts, including the kernel
> > * context are stuck waiting for the signal.
> > */
> > - } else if (engine->schedule &&
> > + } else if (engine->sched_engine->schedule &&
> >rq->sched.attr.priority < I915_PRIORITY_BARRIER)
> > {
> > /*
> > * Gradually raise the priority of the heartbeat to
> > @@ -136,7 +136,7 @@ static void heartbeat(struct work_struct *wrk)
> > attr.priority = I915_PRIORITY_BARRIER;
> >
> > local_bh_disable();
> > - engine->schedule(rq, );
> > + engine->sched_engine->schedule(rq, );
> > local_bh_enable();
> > } else {
> > if (IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM))
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> > b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> > index 7197b9fa5e35..f1b14aff5118 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> > @@ -426,14 +426,6 @@ struct intel_engine_cs {
> > void(*bond_execute)(struct i915_request *rq,
> > struct dma_fence *signal);
> >
> > - /*
> > -* Call when the priority on a request has changed and it and its
> > -* dependencies may need rescheduling. Note the request itself may
> > -* not be ready to run!
> > -*/
> > - void(*schedule)(struct i915_request *request,
> > - const struct i915_sched_attr *attr);
> > -
> > void(*release)(struct intel_engine_cs *engine);
> >
> > struct intel_engine_execlists execlists;
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c
> > b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> > index 3cca7ea2d6ea..84142127ebd8 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> > @@ -108,7 +108,7 @@ static void set_scheduler_caps(struct drm_i915_private
Re: [PATCH 8/9] drm/i915: Move submission tasklet to i915_sched_engine
On Fri, Jun 04, 2021 at 02:26:38PM -0500, Jason Ekstrand wrote:
> On Thu, Jun 3, 2021 at 4:09 PM Matthew Brost wrote:
> >
> > The submission tasklet operates on i915_sched_engine, thus it is the
> > correct place for it.
> >
> > Signed-off-by: Matthew Brost
> > ---
> > drivers/gpu/drm/i915/gt/intel_engine.h| 14 ---
> > drivers/gpu/drm/i915/gt/intel_engine_cs.c | 12 +--
> > drivers/gpu/drm/i915/gt/intel_engine_types.h | 5 --
> > .../drm/i915/gt/intel_execlists_submission.c | 86 ++-
> > drivers/gpu/drm/i915/gt/mock_engine.c | 1 +
> > drivers/gpu/drm/i915/gt/selftest_execlists.c | 16 ++--
> > drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 2 +-
> > drivers/gpu/drm/i915/gt/selftest_lrc.c| 6 +-
> > drivers/gpu/drm/i915/gt/selftest_reset.c | 2 +-
> > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 25 +++---
> > drivers/gpu/drm/i915/i915_scheduler.c | 1 +
> > drivers/gpu/drm/i915/i915_scheduler.h | 14 +++
> > drivers/gpu/drm/i915/i915_scheduler_types.h | 8 ++
> > 13 files changed, 99 insertions(+), 93 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
> > b/drivers/gpu/drm/i915/gt/intel_engine.h
> > index a8b2174b4395..988d9688ae4d 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine.h
> > @@ -123,20 +123,6 @@ execlists_active(const struct intel_engine_execlists
> > *execlists)
> > return active;
> > }
> >
> > -static inline void
> > -execlists_active_lock_bh(struct intel_engine_execlists *execlists)
> > -{
> > - local_bh_disable(); /* prevent local softirq and lock recursion */
> > - tasklet_lock(>tasklet);
> > -}
> > -
> > -static inline void
> > -execlists_active_unlock_bh(struct intel_engine_execlists *execlists)
> > -{
> > - tasklet_unlock(>tasklet);
> > - local_bh_enable(); /* restore softirq, and kick ksoftirqd! */
> > -}
> > -
> > struct i915_request *
> > execlists_unwind_incomplete_requests(struct intel_engine_execlists
> > *execlists);
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > index b480fcb1aad1..837d2132e31b 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > @@ -711,6 +711,7 @@ static int engine_setup_common(struct intel_engine_cs
> > *engine)
> > err = -ENOMEM;
> > goto err_sched_engine;
> > }
> > + engine->sched_engine->engine = engine;
>
> This bothers me. If we're trying to separate things, why do we have a
> back pointer? Yes, I know it's because we need to access our engine
> back-end somehow. Makes me wonder if it should be some sort of a
> void* private data pointer instead of the engine. That's probably
> less safe but it seems more "right" in some sense? I don't know.
>
This was new moving from internal to upstream because of the new tasklet
API that has landed. Previously the tasklet function was setup with u64
data which we used to point to the engine. Now it uses a callback with
the tasklet structure as the argument and can only use a container_of to
resolve the object which in this case a i915_sched_engine. In execlists
we still need the engine object to do the submit, hence the back
pointer.
Longterm we really should have an execlists_submit_engine which
encapsulates the i915_sched_engine and everything we need for execlists
submission (and with DRM scheduler the i915_sched_engine encapsulates
the drm_gpu_scheduler object and common variables between execlists and
GuC).
I already have an object like this for the GuC, guc_submit_eninge,
albeit slightly out of order in patch series.
Agree void* private is better as for the GuC code we likely need this to
be a backpointer to the GuC structure until the aforementioned
guc_submit_engine lands.
Are you ok with landing this with a void* and taking a note this needs
to be reworked?
> Also, dumb question but what's a tasklet?
>
All submissions in the current i915 go through a tasklet. The GuC
submission that will initially land uses this too. Once the DRM
scheduler lands this will go away, at least for GuC submission. If this
is still around for execlists we likely stick this in
execlists_submit_engine object and forget about it.
Matt
> --Jason
>
> >
> > err = intel_engine_init_cmd_parser(engine);
> > if (err)
> > @@ -935,7 +936,6 @@ int intel_engines_init(struct intel_gt *gt)
> > void intel_engine_cleanup_common(struct intel_engine_cs *engine)
> > {
> > GEM_BUG_ON(!list_empty(>sched_engine->requests));
> > - tasklet_kill(>execlists.tasklet); /* flush the callback */
> >
> > i915_sched_engine_put(engine->sched_engine);
> > intel_breadcrumbs_free(engine->breadcrumbs);
> > @@ -1221,7 +1221,7 @@ static bool ring_is_idle(struct intel_engine_cs
> > *engine)
> >
> > void
Re: [PATCH] vgaarb: Call vga_arb_device_init() after PCI enumeration
On Fri, Jun 04, 2021 at 12:50:03PM +0800, Huacai Chen wrote: > On Thu, Jun 3, 2021 at 2:31 AM Bjorn Helgaas wrote: > > > > [+cc linux-pci] > > > > On Wed, Jun 2, 2021 at 11:22 AM Daniel Vetter wrote: > > > On Wed, Jun 02, 2021 at 06:36:03PM +0800, Huacai Chen wrote: > > > > On Wed, Jun 2, 2021 at 2:03 AM Daniel Vetter wrote: > > > > > On Tue, Jun 01, 2021 at 07:12:27PM +0200, Greg KH wrote: > > > > > > On Tue, Jun 01, 2021 at 05:56:40PM +0200, Daniel Vetter wrote: > > > > > > > On Fri, May 28, 2021 at 04:26:07PM +0800, Huacai Chen wrote: > > > > > > > > We should call vga_arb_device_init() after PCI enumeration, > > > > > > > > otherwise it > > > > > > > > may fail to select the default VGA device. Since > > > > > > > > vga_arb_device_init() > > > > > > > > and PCI enumeration function (i.e., pcibios_init() or > > > > > > > > acpi_init()) are > > > > > > > > both wrapped by subsys_initcall(), their sequence is not > > > > > > > > assured. So, we > > > > > > > > use subsys_initcall_sync() instead of subsys_initcall() to wrap > > > > > > > > vga_arb_ > > > > > > > > device_init(). > > > > > > > > > > > > Trying to juggle levels like this always fails if you build the > > > > > > code as > > > > > > a module. > > > > > > > > > > > > Why not fix it properly and handle the out-of-order loading by > > > > > > returning > > > > > > a "deferred" error if you do not have your resources yet? > > > > > > > > > > It's not a driver, it's kinda a bolted-on-the-side subsytem of pci. > > > > > So not > > > > > something you can -EPROBE_DEFER I think, without potentially > > > > > upsetting the > > > > > drivers that need this. > > > > > > > > > > Which might mean we should move this into pci subsystem proper > > > > > perhaps? > > > > > Then adding the init call at the right time becomes trivial since we > > > > > just > > > > > plug it in at the end of pci init. > > > > > > > > > > Also maybe that's how distros avoid this pain, pci is built-in, > > > > > vgaarb is > > > > > generally a module, problem solved. > > > > > > > > > > Bjorn, would you take this entire vgaarb.c thing? From a quick look I > > > > > don't think it has a drm-ism in it (unlike vga_switcheroo, but that > > > > > works > > > > > a bit differently and doesn't have this init order issue). > > > > Emmm, this patch cannot handle the hotplug case and module case, it > > > > just handles the case that vgaarb, drm driver and pci all built-in. > > > > But I think this is enough, because the original problem only happens > > > > on very few BMC-based VGA cards (BMC doesn't set the VGA Enable bit on > > > > the bridge, which breaks vgaarb). > > > > > > I'm not talking aout hotplug, just ordering the various pieces correctly. > > > That vgaarb isn't really a driver and also can't really handle hotplug is > > > my point. I guess that got lost a bit? > > > > > > Anyway my proposal is essentially to do a > > > > > > $ git move drivers/gpu/vga/vgaarb.c drivers/pci > > > > > > But I just realized that vgaarb is a bool option, so module isn't possible > > > anyway, and we could fix this by calling vgaarb from pcibios init (with an > > > empty static inline in the header if vgaarb is disabled). That makes the > > > dependency very explicit and guarantees it works correctly. > > > > pcibios_init() is also an initcall and is implemented by every arch. > > I agree that calling vga_arb_device_init() directly from > > pcibios_init() would probably fix this problem, and it would be really > > nice to have it not be an initcall. But it's also kind of a pain to > > have to update all those copies of pcibios_init(), and I would be > > looking for a way to unify it since it's not really an arch-specific > > thing. > > > > I think the simplest solution, which I suggested earlier [1], would be > > to explicitly call vga_arbiter_add_pci_device() directly from the PCI > > core when it enumerates a VGA device. Then there's no initcall and no > > need for the BUS_NOTIFY_ADD/DEL_DEVICE stuff. > > vga_arbiter_add_pci_device() could set the default VGA device when it > > is enumerated, and change the default device if we enumerate a > > "better" one. And hotplug VGA devices would work automatically. > Emm, It seems that your solution has some difficulties to remove the > whole initcall(vga_arb_device_init): we call > vga_arbiter_add_pci_device() in pci_bus_add_device(), the > list_for_each_entry() loop can be moved to > vga_arbiter_check_bridge_sharing(), vga_arb_select_default_device() > can be renamed to vga_arb_update_default_device() and be called in > vga_arbiter_add_pci_device(), but how to handle > misc_register(_arb_device)? Might need to keep vga_arb_device_init() as an initcall, but remove everything from it except the misc_register().
[PATCH 8/8] usb: typec: altmodes/displayport: Notify drm subsys of hotplug events
Use the new drm_connector_oob_hotplug_event() functions to let drm/kms
drivers know about DisplayPort over Type-C hotplug events.
Reviewed-by: Heikki Krogerus
Tested-by: Heikki Krogerus
Signed-off-by: Hans de Goede
---
Changes in v3:
- Only call drm_connector_oob_hotplug_event() on hpd status bit change
- Adjust for drm_connector_oob_hotplug_event() no longer having a data
argument
Changes in v2:
- Add missing depends on DRM to TYPEC_DP_ALTMODE Kconfig entry
---
drivers/usb/typec/altmodes/Kconfig | 1 +
drivers/usb/typec/altmodes/displayport.c | 23 +++
2 files changed, 24 insertions(+)
diff --git a/drivers/usb/typec/altmodes/Kconfig
b/drivers/usb/typec/altmodes/Kconfig
index 60d375e9c3c7..1a6b5e872b0d 100644
--- a/drivers/usb/typec/altmodes/Kconfig
+++ b/drivers/usb/typec/altmodes/Kconfig
@@ -4,6 +4,7 @@ menu "USB Type-C Alternate Mode drivers"
config TYPEC_DP_ALTMODE
tristate "DisplayPort Alternate Mode driver"
+ depends on DRM
help
DisplayPort USB Type-C Alternate Mode allows DisplayPort
displays and adapters to be attached to the USB Type-C
diff --git a/drivers/usb/typec/altmodes/displayport.c
b/drivers/usb/typec/altmodes/displayport.c
index aa669b9cf70e..c1d8c23baa39 100644
--- a/drivers/usb/typec/altmodes/displayport.c
+++ b/drivers/usb/typec/altmodes/displayport.c
@@ -11,8 +11,10 @@
#include
#include
#include
+#include
#include
#include
+#include
#include "displayport.h"
#define DP_HEADER(_dp, ver, cmd) (VDO((_dp)->alt->svid, 1, ver, cmd)
\
@@ -57,11 +59,13 @@ struct dp_altmode {
struct typec_displayport_data data;
enum dp_state state;
+ bool hpd;
struct mutex lock; /* device lock */
struct work_struct work;
struct typec_altmode *alt;
const struct typec_altmode *port;
+ struct fwnode_handle *connector_fwnode;
};
static int dp_altmode_notify(struct dp_altmode *dp)
@@ -125,6 +129,7 @@ static int dp_altmode_configure(struct dp_altmode *dp, u8
con)
static int dp_altmode_status_update(struct dp_altmode *dp)
{
bool configured = !!DP_CONF_GET_PIN_ASSIGN(dp->data.conf);
+ bool hpd = !!(dp->data.status & DP_STATUS_HPD_STATE);
u8 con = DP_STATUS_CONNECTION(dp->data.status);
int ret = 0;
@@ -137,6 +142,11 @@ static int dp_altmode_status_update(struct dp_altmode *dp)
ret = dp_altmode_configure(dp, con);
if (!ret)
dp->state = DP_STATE_CONFIGURE;
+ } else {
+ if (dp->hpd != hpd) {
+ drm_connector_oob_hotplug_event(dp->connector_fwnode);
+ dp->hpd = hpd;
+ }
}
return ret;
@@ -512,6 +522,7 @@ static const struct attribute_group dp_altmode_group = {
int dp_altmode_probe(struct typec_altmode *alt)
{
const struct typec_altmode *port = typec_altmode_get_partner(alt);
+ struct fwnode_handle *fwnode;
struct dp_altmode *dp;
int ret;
@@ -540,6 +551,11 @@ int dp_altmode_probe(struct typec_altmode *alt)
alt->desc = "DisplayPort";
alt->ops = _altmode_ops;
+ fwnode = dev_fwnode(alt->dev.parent->parent); /* typec_port fwnode */
+ dp->connector_fwnode = fwnode_find_reference(fwnode, "displayport", 0);
+ if (IS_ERR(dp->connector_fwnode))
+ dp->connector_fwnode = NULL;
+
typec_altmode_set_drvdata(alt, dp);
dp->state = DP_STATE_ENTER;
@@ -555,6 +571,13 @@ void dp_altmode_remove(struct typec_altmode *alt)
sysfs_remove_group(>dev.kobj, _altmode_group);
cancel_work_sync(>work);
+
+ if (dp->connector_fwnode) {
+ if (dp->hpd)
+ drm_connector_oob_hotplug_event(dp->connector_fwnode);
+
+ fwnode_handle_put(dp->connector_fwnode);
+ }
}
EXPORT_SYMBOL_GPL(dp_altmode_remove);
--
2.31.1
[PATCH 7/8] usb: typec: altmodes/displayport: Make dp_altmode_notify() more generic
Make dp_altmode_notify() handle the dp->data.conf == 0 case too,
rather then having separate code-paths for this in various places
which call it.
Reviewed-by: Heikki Krogerus
Tested-by: Heikki Krogerus
Signed-off-by: Hans de Goede
---
drivers/usb/typec/altmodes/displayport.c | 35 +---
1 file changed, 13 insertions(+), 22 deletions(-)
diff --git a/drivers/usb/typec/altmodes/displayport.c
b/drivers/usb/typec/altmodes/displayport.c
index b7f094435b00..aa669b9cf70e 100644
--- a/drivers/usb/typec/altmodes/displayport.c
+++ b/drivers/usb/typec/altmodes/displayport.c
@@ -66,10 +66,17 @@ struct dp_altmode {
static int dp_altmode_notify(struct dp_altmode *dp)
{
- u8 state = get_count_order(DP_CONF_GET_PIN_ASSIGN(dp->data.conf));
+ unsigned long conf;
+ u8 state;
+
+ if (dp->data.conf) {
+ state = get_count_order(DP_CONF_GET_PIN_ASSIGN(dp->data.conf));
+ conf = TYPEC_MODAL_STATE(state);
+ } else {
+ conf = TYPEC_STATE_USB;
+ }
- return typec_altmode_notify(dp->alt, TYPEC_MODAL_STATE(state),
- >data);
+ return typec_altmode_notify(dp->alt, conf, >data);
}
static int dp_altmode_configure(struct dp_altmode *dp, u8 con)
@@ -137,21 +144,10 @@ static int dp_altmode_status_update(struct dp_altmode *dp)
static int dp_altmode_configured(struct dp_altmode *dp)
{
- int ret;
-
sysfs_notify(>alt->dev.kobj, "displayport", "configuration");
-
- if (!dp->data.conf)
- return typec_altmode_notify(dp->alt, TYPEC_STATE_USB,
- >data);
-
- ret = dp_altmode_notify(dp);
- if (ret)
- return ret;
-
sysfs_notify(>alt->dev.kobj, "displayport", "pin_assignment");
- return 0;
+ return dp_altmode_notify(dp);
}
static int dp_altmode_configure_vdm(struct dp_altmode *dp, u32 conf)
@@ -172,13 +168,8 @@ static int dp_altmode_configure_vdm(struct dp_altmode *dp,
u32 conf)
}
ret = typec_altmode_vdm(dp->alt, header, , 2);
- if (ret) {
- if (DP_CONF_GET_PIN_ASSIGN(dp->data.conf))
- dp_altmode_notify(dp);
- else
- typec_altmode_notify(dp->alt, TYPEC_STATE_USB,
->data);
- }
+ if (ret)
+ dp_altmode_notify(dp);
return ret;
}
--
2.31.1
[PATCH 6/8] drm/i915/dp: Add support for out-of-bound hotplug events
On some Cherry Trail devices, DisplayPort over Type-C is supported through
a USB-PD microcontroller (e.g. a fusb302) + a mux to switch the superspeed
datalines between USB-3 and DP (e.g. a pi3usb30532). The kernel in this
case does the PD/alt-mode negotiation itself, rather then everything being
handled in firmware.
So the kernel itself picks an alt-mode, tells the Type-C "dongle" to switch
to DP mode and sets the mux accordingly. In this setup the HPD pin is not
connected, so the i915 driver needs to respond to a software event and scan
the DP port for changes manually.
This commit adds support for this. Together with the recent addition of
DP alt-mode support to the Type-C subsystem this makes DP over Type-C
work on these devices.
Tested-by: Heikki Krogerus
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/display/intel_dp.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 5c983044..5d6cf2657fa3 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4598,6 +4598,17 @@ static int intel_dp_connector_atomic_check(struct
drm_connector *conn,
return intel_modeset_synced_crtcs(state, conn);
}
+static void intel_dp_oob_hotplug_event(struct drm_connector *connector)
+{
+ struct intel_encoder *encoder =
intel_attached_encoder(to_intel_connector(connector));
+ struct drm_i915_private *i915 = to_i915(connector->dev);
+
+ spin_lock_irq(>irq_lock);
+ i915->hotplug.event_bits |= BIT(encoder->hpd_pin);
+ spin_unlock_irq(>irq_lock);
+ queue_delayed_work(system_wq, >hotplug.hotplug_work, 0);
+}
+
static const struct drm_connector_funcs intel_dp_connector_funcs = {
.force = intel_dp_force,
.fill_modes = drm_helper_probe_single_connector_modes,
@@ -4608,6 +4619,7 @@ static const struct drm_connector_funcs
intel_dp_connector_funcs = {
.destroy = intel_connector_destroy,
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
.atomic_duplicate_state = intel_digital_connector_duplicate_state,
+ .oob_hotplug_event = intel_dp_oob_hotplug_event,
};
static const struct drm_connector_helper_funcs intel_dp_connector_helper_funcs
= {
--
2.31.1
[PATCH 5/8] drm/i915: Associate ACPI connector nodes with connector entries (v2)
From: Heikki Krogerus
On Intel platforms we know that the ACPI connector device
node order will follow the order the driver (i915) decides.
The decision is made using the custom Intel ACPI OpRegion
(intel_opregion.c), though the driver does not actually know
that the values it sends to ACPI there are used for
associating a device node for the connectors, and assigning
address for them.
In reality that custom Intel ACPI OpRegion actually violates
ACPI specification (we supply dynamic information to objects
that are defined static, for example _ADR), however, it
makes assigning correct connector node for a connector entry
straightforward (it's one-on-one mapping).
Changes in v2 (Hans de goede):
- Take a reference on the fwnode which we assign to the connector,
for ACPI nodes this is a no-op but in the future we may see
software-fwnodes assigned to connectors which are ref-counted.
Signed-off-by: Heikki Krogerus
Tested-by: Heikki Krogerus
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/display/intel_acpi.c| 46
drivers/gpu/drm/i915/display/intel_acpi.h| 3 ++
drivers/gpu/drm/i915/display/intel_display.c | 1 +
3 files changed, 50 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_acpi.c
b/drivers/gpu/drm/i915/display/intel_acpi.c
index 833d0c1be4f1..37077b19cf58 100644
--- a/drivers/gpu/drm/i915/display/intel_acpi.c
+++ b/drivers/gpu/drm/i915/display/intel_acpi.c
@@ -263,3 +263,49 @@ void intel_acpi_device_id_update(struct drm_i915_private
*dev_priv)
}
drm_connector_list_iter_end(_iter);
}
+
+/* NOTE: The connector order must be final before this is called. */
+void intel_acpi_assign_connector_fwnodes(struct drm_i915_private *i915)
+{
+ struct drm_connector_list_iter conn_iter;
+ struct drm_device *drm_dev = >drm;
+ struct fwnode_handle *fwnode = NULL;
+ struct drm_connector *connector;
+ struct acpi_device *adev;
+
+ drm_connector_list_iter_begin(drm_dev, _iter);
+ drm_for_each_connector_iter(connector, _iter) {
+ /* Always getting the next, even when the last was not used. */
+ fwnode = device_get_next_child_node(drm_dev->dev, fwnode);
+ if (!fwnode)
+ break;
+
+ switch (connector->connector_type) {
+ case DRM_MODE_CONNECTOR_LVDS:
+ case DRM_MODE_CONNECTOR_eDP:
+ case DRM_MODE_CONNECTOR_DSI:
+ /*
+* Integrated displays have a specific address 0x1f on
+* most Intel platforms, but not on all of them.
+*/
+ adev =
acpi_find_child_device(ACPI_COMPANION(drm_dev->dev),
+ 0x1f, 0);
+ if (adev) {
+ connector->fwnode =
+
fwnode_handle_get(acpi_fwnode_handle(adev));
+ break;
+ }
+ fallthrough;
+ default:
+ connector->fwnode = fwnode_handle_get(fwnode);
+ break;
+ }
+ }
+ drm_connector_list_iter_end(_iter);
+ /*
+* device_get_next_child_node() takes a reference on the fwnode, if
+* we stopped iterating because we are out of connectors we need to
+* put this, otherwise fwnode is NULL and the put is a no-op.
+*/
+ fwnode_handle_put(fwnode);
+}
diff --git a/drivers/gpu/drm/i915/display/intel_acpi.h
b/drivers/gpu/drm/i915/display/intel_acpi.h
index e8b068661d22..d2435691f4b5 100644
--- a/drivers/gpu/drm/i915/display/intel_acpi.h
+++ b/drivers/gpu/drm/i915/display/intel_acpi.h
@@ -12,11 +12,14 @@ struct drm_i915_private;
void intel_register_dsm_handler(void);
void intel_unregister_dsm_handler(void);
void intel_acpi_device_id_update(struct drm_i915_private *i915);
+void intel_acpi_assign_connector_fwnodes(struct drm_i915_private *i915);
#else
static inline void intel_register_dsm_handler(void) { return; }
static inline void intel_unregister_dsm_handler(void) { return; }
static inline
void intel_acpi_device_id_update(struct drm_i915_private *i915) { return; }
+static inline
+void intel_acpi_assign_connector_fwnodes(struct drm_i915_private *i915) {
return; }
#endif /* CONFIG_ACPI */
#endif /* __INTEL_ACPI_H__ */
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index caf0414e0b50..4133f657f6a0 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -12381,6 +12381,7 @@ int intel_modeset_init_nogem(struct drm_i915_private
*i915)
drm_modeset_lock_all(dev);
intel_modeset_setup_hw_state(dev, dev->mode_config.acquire_ctx);
+ intel_acpi_assign_connector_fwnodes(i915);
[PATCH 4/8] drm/connector: Add support for out-of-band hotplug notification (v3)
Add a new drm_connector_oob_hotplug_event() function and
oob_hotplug_event drm_connector_funcs member.
On some hardware a hotplug event notification may come from outside the
display driver / device. An example of this is some USB Type-C setups
where the hardware muxes the DisplayPort data and aux-lines but does
not pass the altmode HPD status bit to the GPU's DP HPD pin.
In cases like this the new drm_connector_oob_hotplug_event() function can
be used to report these out-of-band events.
Changes in v2:
- Make drm_connector_oob_hotplug_event() take a fwnode as argument and
have it call drm_connector_find_by_fwnode() internally. This allows
making drm_connector_find_by_fwnode() a drm-internal function and
avoids code outside the drm subsystem potentially holding on the
a drm_connector reference for a longer period.
Changes in v3:
- Drop the data argument to the drm_connector_oob_hotplug_event
function since it is not used atm. This can be re-added later when
a use for it actually arises.
Tested-by: Heikki Krogerus
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/drm_connector.c | 27 +++
include/drm/drm_connector.h | 9 +
2 files changed, 36 insertions(+)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 14644053a678..88ff7a011002 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -2592,6 +2592,33 @@ struct drm_connector
*drm_connector_find_by_fwnode(struct fwnode_handle *fwnode)
return found;
}
+/**
+ * drm_connector_oob_hotplug_event - Report out-of-band hotplug event to
connector
+ * @connector: connector to report the event on
+ *
+ * On some hardware a hotplug event notification may come from outside the
display
+ * driver / device. An example of this is some USB Type-C setups where the
hardware
+ * muxes the DisplayPort data and aux-lines but does not pass the altmode HPD
+ * status bit to the GPU's DP HPD pin.
+ *
+ * This function can be used to report these out-of-band events after obtaining
+ * a drm_connector reference through calling drm_connector_find_by_fwnode().
+ */
+void drm_connector_oob_hotplug_event(struct fwnode_handle *connector_fwnode)
+{
+ struct drm_connector *connector;
+
+ connector = drm_connector_find_by_fwnode(connector_fwnode);
+ if (IS_ERR(connector))
+ return;
+
+ if (connector->funcs->oob_hotplug_event)
+ connector->funcs->oob_hotplug_event(connector);
+
+ drm_connector_put(connector);
+}
+EXPORT_SYMBOL(drm_connector_oob_hotplug_event);
+
/**
* DOC: Tile group
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index b4b08c7a538e..1d896a8e3fa7 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1079,6 +1079,14 @@ struct drm_connector_funcs {
*/
void (*atomic_print_state)(struct drm_printer *p,
const struct drm_connector_state *state);
+
+ /**
+* @oob_hotplug_event:
+*
+* This will get called when a hotplug-event for a drm-connector
+* has been received from a source outside the display driver / device.
+*/
+ void (*oob_hotplug_event)(struct drm_connector *connector);
};
/**
@@ -1661,6 +1669,7 @@ drm_connector_is_unregistered(struct drm_connector
*connector)
DRM_CONNECTOR_UNREGISTERED;
}
+void drm_connector_oob_hotplug_event(struct fwnode_handle *connector_fwnode);
const char *drm_get_connector_type_name(unsigned int connector_type);
const char *drm_get_connector_status_name(enum drm_connector_status status);
const char *drm_get_subpixel_order_name(enum subpixel_order order);
--
2.31.1
[PATCH 3/8] drm/connector: Add drm_connector_find_by_fwnode() function (v3)
Add a function to find a connector based on a fwnode.
This will be used by the new drm_connector_oob_hotplug_event()
function which is added by the next patch in this patch-set.
Changes in v2:
- Complete rewrite to use a global connector list in drm_connector.c
rather then using a class-dev-iter in drm_sysfs.c
Changes in v3:
- Add forward declaration for struct fwnode_handle to drm_crtc_internal.h
(fixes warning reported by kernel test robot )
Tested-by: Heikki Krogerus
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/drm_connector.c | 50 +
drivers/gpu/drm/drm_crtc_internal.h | 2 ++
include/drm/drm_connector.h | 8 +
3 files changed, 60 insertions(+)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index eb3bd362c23f..14644053a678 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -65,6 +65,14 @@
* support can instead use e.g. drm_helper_hpd_irq_event().
*/
+/*
+ * Global connector list for drm_connector_find_by_fwnode().
+ * Note drm_connector_[un]register() first take connector->lock and then
+ * take the connector_list_lock.
+ */
+static DEFINE_MUTEX(connector_list_lock);
+static LIST_HEAD(connector_list);
+
struct drm_conn_prop_enum_list {
int type;
const char *name;
@@ -267,6 +275,7 @@ int drm_connector_init(struct drm_device *dev,
goto out_put_type_id;
}
+ INIT_LIST_HEAD(>global_connector_list_entry);
INIT_LIST_HEAD(>probed_modes);
INIT_LIST_HEAD(>modes);
mutex_init(>mutex);
@@ -534,6 +543,9 @@ int drm_connector_register(struct drm_connector *connector)
/* Let userspace know we have a new connector */
drm_sysfs_hotplug_event(connector->dev);
+ mutex_lock(_list_lock);
+ list_add_tail(>global_connector_list_entry, _list);
+ mutex_unlock(_list_lock);
goto unlock;
err_debugfs:
@@ -562,6 +574,10 @@ void drm_connector_unregister(struct drm_connector
*connector)
return;
}
+ mutex_lock(_list_lock);
+ list_del_init(>global_connector_list_entry);
+ mutex_unlock(_list_lock);
+
if (connector->funcs->early_unregister)
connector->funcs->early_unregister(connector);
@@ -2542,6 +2558,40 @@ int drm_mode_getconnector(struct drm_device *dev, void
*data,
return ret;
}
+/**
+ * drm_connector_find_by_fwnode - Find a connector based on the associated
fwnode
+ * @fwnode: fwnode for which to find the matching drm_connector
+ *
+ * This functions looks up a drm_connector based on its associated fwnode. When
+ * a connector is found a reference to the connector is returned. The caller
must
+ * call drm_connector_put() to release this reference when it is done with the
+ * connector.
+ *
+ * Returns: A reference to the found connector or an ERR_PTR().
+ */
+struct drm_connector *drm_connector_find_by_fwnode(struct fwnode_handle
*fwnode)
+{
+ struct drm_connector *connector, *found = ERR_PTR(-ENODEV);
+
+ if (!fwnode)
+ return ERR_PTR(-ENODEV);
+
+ mutex_lock(_list_lock);
+
+ list_for_each_entry(connector, _list,
global_connector_list_entry) {
+ if (connector->fwnode == fwnode ||
+ (connector->fwnode && connector->fwnode->secondary ==
fwnode)) {
+ drm_connector_get(connector);
+ found = connector;
+ break;
+ }
+ }
+
+ mutex_unlock(_list_lock);
+
+ return found;
+}
+
/**
* DOC: Tile group
diff --git a/drivers/gpu/drm/drm_crtc_internal.h
b/drivers/gpu/drm/drm_crtc_internal.h
index 54d4cf1233e9..1e676a41d58b 100644
--- a/drivers/gpu/drm/drm_crtc_internal.h
+++ b/drivers/gpu/drm/drm_crtc_internal.h
@@ -57,6 +57,7 @@ struct drm_property;
struct edid;
struct kref;
struct work_struct;
+struct fwnode_handle;
/* drm_crtc.c */
int drm_mode_crtc_set_obj_prop(struct drm_mode_object *obj,
@@ -185,6 +186,7 @@ int drm_connector_set_obj_prop(struct drm_mode_object *obj,
int drm_connector_create_standard_properties(struct drm_device *dev);
const char *drm_get_connector_force_name(enum drm_connector_force force);
void drm_connector_free_work_fn(struct work_struct *work);
+struct drm_connector *drm_connector_find_by_fwnode(struct fwnode_handle
*fwnode);
/* IOCTL */
int drm_connector_property_set_ioctl(struct drm_device *dev,
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 56aae0d5e2f8..b4b08c7a538e 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1242,6 +1242,14 @@ struct drm_connector {
*/
struct list_head head;
+ /**
+* @global_connector_list_entry:
+*
+* Connector entry in the global connector-list, used by
+* drm_connector_find_by_fwnode().
+*/
+ struct list_head global_connector_list_entry;
+
[PATCH 2/8] drm/connector: Add a fwnode pointer to drm_connector and register with ACPI (v2)
Add a fwnode pointer to struct drm_connector and register an acpi_bus_type
for the connectors with the ACPI subsystem (when CONFIG_ACPI is enabled).
The adding of the fwnode pointer allows drivers to associate a fwnode
that represents a connector with that connector.
When the new fwnode pointer points to an ACPI-companion, then the new
acpi_bus_type will cause the ACPI subsys to bind the device instantiated
for the connector with the fwnode by calling acpi_bind_one(). This will
result in a firmware_node symlink under /sys/class/card#-/
which helps to verify that the fwnode-s and connectors are properly
matched.
Changes in v2:
- Make drm_connector_cleanup() call fwnode_handle_put() on
connector->fwnode and document this
Co-developed-by: Heikki Krogerus
Signed-off-by: Heikki Krogerus
Tested-by: Heikki Krogerus
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/drm_connector.c | 2 ++
drivers/gpu/drm/drm_sysfs.c | 37 +
include/drm/drm_connector.h | 8 +++
3 files changed, 47 insertions(+)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index da39e7ff6965..eb3bd362c23f 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -474,6 +474,8 @@ void drm_connector_cleanup(struct drm_connector *connector)
drm_mode_object_unregister(dev, >base);
kfree(connector->name);
connector->name = NULL;
+ fwnode_handle_put(connector->fwnode);
+ connector->fwnode = NULL;
spin_lock_irq(>mode_config.connector_list_lock);
list_del(>head);
dev->mode_config.num_connector--;
diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
index f9d92bbb1f98..bf9edce8e2d1 100644
--- a/drivers/gpu/drm/drm_sysfs.c
+++ b/drivers/gpu/drm/drm_sysfs.c
@@ -10,6 +10,7 @@
* Copyright (c) 2003-2004 IBM Corp.
*/
+#include
#include
#include
#include
@@ -56,6 +57,39 @@ static struct device_type drm_sysfs_device_connector = {
struct class *drm_class;
+#ifdef CONFIG_ACPI
+static bool drm_connector_acpi_bus_match(struct device *dev)
+{
+ return dev->type == _sysfs_device_connector;
+}
+
+static struct acpi_device *drm_connector_acpi_find_companion(struct device
*dev)
+{
+ struct drm_connector *connector = to_drm_connector(dev);
+
+ return to_acpi_device_node(connector->fwnode);
+}
+
+static struct acpi_bus_type drm_connector_acpi_bus = {
+ .name = "drm_connector",
+ .match = drm_connector_acpi_bus_match,
+ .find_companion = drm_connector_acpi_find_companion,
+};
+
+static void drm_sysfs_acpi_register(void)
+{
+ register_acpi_bus_type(_connector_acpi_bus);
+}
+
+static void drm_sysfs_acpi_unregister(void)
+{
+ unregister_acpi_bus_type(_connector_acpi_bus);
+}
+#else
+static void drm_sysfs_acpi_register(void) { }
+static void drm_sysfs_acpi_unregister(void) { }
+#endif
+
static char *drm_devnode(struct device *dev, umode_t *mode)
{
return kasprintf(GFP_KERNEL, "dri/%s", dev_name(dev));
@@ -89,6 +123,8 @@ int drm_sysfs_init(void)
}
drm_class->devnode = drm_devnode;
+
+ drm_sysfs_acpi_register();
return 0;
}
@@ -101,6 +137,7 @@ void drm_sysfs_destroy(void)
{
if (IS_ERR_OR_NULL(drm_class))
return;
+ drm_sysfs_acpi_unregister();
class_remove_file(drm_class, _attr_version.attr);
class_destroy(drm_class);
drm_class = NULL;
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 714d1a01c065..56aae0d5e2f8 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1223,6 +1223,14 @@ struct drm_connector {
struct device *kdev;
/** @attr: sysfs attributes */
struct device_attribute *attr;
+ /**
+* @fwnode: associated fwnode supplied by platform firmware
+*
+* Drivers can set this to associate a fwnode with a connector, drivers
+* are expected to get a reference on the fwnode when setting this.
+* drm_connector_cleanup() will call fwnode_handle_put() on this.
+*/
+ struct fwnode_handle *fwnode;
/**
* @head:
--
2.31.1
[PATCH 1/8] drm/connector: Give connector sysfs devices there own device_type
Give connector sysfs devices there own device_type, this allows us to
check if a device passed to functions dealing with generic devices is
a drm_connector or not.
A check like this is necessary in the drm_connector_acpi_bus_match()
function added in the next patch in this series.
Tested-by: Heikki Krogerus
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/drm_sysfs.c | 50 +++--
1 file changed, 37 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
index 968a9560b4aa..f9d92bbb1f98 100644
--- a/drivers/gpu/drm/drm_sysfs.c
+++ b/drivers/gpu/drm/drm_sysfs.c
@@ -50,6 +50,10 @@ static struct device_type drm_sysfs_device_minor = {
.name = "drm_minor"
};
+static struct device_type drm_sysfs_device_connector = {
+ .name = "drm_connector",
+};
+
struct class *drm_class;
static char *drm_devnode(struct device *dev, umode_t *mode)
@@ -102,6 +106,11 @@ void drm_sysfs_destroy(void)
drm_class = NULL;
}
+static void drm_sysfs_release(struct device *dev)
+{
+ kfree(dev);
+}
+
/*
* Connector properties
*/
@@ -273,27 +282,47 @@ static const struct attribute_group
*connector_dev_groups[] = {
int drm_sysfs_connector_add(struct drm_connector *connector)
{
struct drm_device *dev = connector->dev;
+ struct device *kdev;
+ int r;
if (connector->kdev)
return 0;
- connector->kdev =
- device_create_with_groups(drm_class, dev->primary->kdev, 0,
- connector, connector_dev_groups,
- "card%d-%s", dev->primary->index,
- connector->name);
+ kdev = kzalloc(sizeof(*kdev), GFP_KERNEL);
+ if (!kdev)
+ return -ENOMEM;
+
+ device_initialize(kdev);
+ kdev->class = drm_class;
+ kdev->type = _sysfs_device_connector;
+ kdev->parent = dev->primary->kdev;
+ kdev->groups = connector_dev_groups;
+ kdev->release = drm_sysfs_release;
+ dev_set_drvdata(kdev, connector);
+
+ r = dev_set_name(kdev, "card%d-%s", dev->primary->index,
connector->name);
+ if (r)
+ goto err_free;
+
DRM_DEBUG("adding \"%s\" to sysfs\n",
connector->name);
- if (IS_ERR(connector->kdev)) {
- DRM_ERROR("failed to register connector device: %ld\n",
PTR_ERR(connector->kdev));
- return PTR_ERR(connector->kdev);
+ r = device_add(kdev);
+ if (r) {
+ DRM_ERROR("failed to register connector device: %d\n", r);
+ goto err_free;
}
+ connector->kdev = kdev;
+
if (connector->ddc)
return sysfs_create_link(>kdev->kobj,
>ddc->dev.kobj, "ddc");
return 0;
+
+err_free:
+ put_device(kdev);
+ return r;
}
void drm_sysfs_connector_remove(struct drm_connector *connector)
@@ -374,11 +403,6 @@ void drm_sysfs_connector_status_event(struct drm_connector
*connector,
}
EXPORT_SYMBOL(drm_sysfs_connector_status_event);
-static void drm_sysfs_release(struct device *dev)
-{
- kfree(dev);
-}
-
struct device *drm_sysfs_minor_alloc(struct drm_minor *minor)
{
const char *minor_str;
--
2.31.1
[PATCH 0/8] drm + usb-type-c: Add support for out-of-band hotplug notification (v4)
Here is v3 of my patchset making DP over Type-C work on devices where the Type-C controller does not drive the HPD pin on the GPU, but instead we need to forward HPD events from the Type-C controller to the DRM driver. Changes in v4: - Rebase on top of latest drm-tip - Add forward declaration for struct fwnode_handle to drm_crtc_internal.h (fixes warning reported by kernel test robot ) - Add Heikki's Reviewed-by to patch 7 & 8 - Add Heikki's Tested-by to the series Changes in v3: - Base on top of latest drm-tip, which should fix the CI being unable to apply (and thus to test) the patches - Make intel_acpi_assign_connector_fwnodes() take a ref on the fwnode it stores in connector->fwnode and have drm_connector_cleanup() put this reference - Drop data argument from drm_connector_oob_hotplug_event() - Make the Type-C DP altmode code only call drm_connector_oob_hotplug_event() when the HPD bit in the status vdo changes - Drop the platform/x86/intel_cht_int33fe: Correct "displayport" fwnode reference patch, this will be merged independently through the pdx86 tree Changes in v2: - Replace the bogus "drm/connector: Make the drm_sysfs connector->kdev device hold a reference to the connector" patch with: "drm/connector: Give connector sysfs devices there own device_type" the new patch is a dep for patch 2/9 see the patches - Stop using a class-dev-iter, instead at a global connector list to drm_connector.c and use that to find the connector by the fwnode, similar to how we already do this in drm_panel.c and drm_bridge.c - Make drm_connector_oob_hotplug_event() take a fwnode pointer as argument, rather then a drm_connector pointer and let it do the lookup itself. This allows making drm_connector_find_by_fwnode() a drm-internal function and avoids code outside the drm subsystem potentially holding on the a drm_connector reference for a longer period. This series not only touches drm subsys files but it also touches drivers/usb/typec/altmodes/typec_displayport.c, that file usually does not see a whole lot of changes. So I believe it would be best to just merge the entire series through drm-misc, Assuming we can get an ack from Greg for merging the typec_displayport.c changes this way. Regards, Hans Hans de Goede (7): drm/connector: Give connector sysfs devices there own device_type drm/connector: Add a fwnode pointer to drm_connector and register with ACPI (v2) drm/connector: Add drm_connector_find_by_fwnode() function (v3) drm/connector: Add support for out-of-band hotplug notification (v3) drm/i915/dp: Add support for out-of-bound hotplug events usb: typec: altmodes/displayport: Make dp_altmode_notify() more generic usb: typec: altmodes/displayport: Notify drm subsys of hotplug events Heikki Krogerus (1): drm/i915: Associate ACPI connector nodes with connector entries (v2) drivers/gpu/drm/drm_connector.c | 79 ++ drivers/gpu/drm/drm_crtc_internal.h | 2 + drivers/gpu/drm/drm_sysfs.c | 87 +--- drivers/gpu/drm/i915/display/intel_acpi.c| 46 +++ drivers/gpu/drm/i915/display/intel_acpi.h| 3 + drivers/gpu/drm/i915/display/intel_display.c | 1 + drivers/gpu/drm/i915/display/intel_dp.c | 12 +++ drivers/usb/typec/altmodes/Kconfig | 1 + drivers/usb/typec/altmodes/displayport.c | 58 - include/drm/drm_connector.h | 25 ++ 10 files changed, 279 insertions(+), 35 deletions(-) -- 2.31.1
Re: [Mesa-dev] [Intel-gfx] [RFC PATCH 1/2] drm/doc/rfc: i915 GuC submission / DRM scheduler
On Sat, 5 Jun 2021 at 03:39, Daniel Vetter wrote: > > On Wed, May 26, 2021 at 04:33:56PM -0700, Matthew Brost wrote: > > Add entry for i915 GuC submission / DRM scheduler integration plan. > > Follow up patch with details of new parallel submission uAPI to come. > > > > v2: > > (Daniel Vetter) > > - Expand explaination of why bonding isn't supported for GuC > > submission > > - CC some of the DRM scheduler maintainers > > - Add priority inheritance / boosting use case > > - Add reasoning for removing in order assumptions > > (Daniel Stone) > > - Add links to priority spec > > > > Cc: Christian König > > Cc: Luben Tuikov > > Cc: Alex Deucher > > Cc: Steven Price > > Cc: Jon Bloomfield > > Cc: Jason Ekstrand > > Cc: Dave Airlie > > Cc: Daniel Vetter > > Cc: Jason Ekstrand > > Cc: dri-devel@lists.freedesktop.org > > Signed-off-by: Matthew Brost > > You have a one-line hunk in the next patch that probably should be here. > With that moved. > > Reviewed-by: Daniel Vetter Acked-by: Dave Airlie And yes having the todos for GuC tracked would be good externally, so pressure can be applied for new fw releases with those features. Dave.
[PATCH] treewide: Add missing semicolons to __assign_str uses
The __assign_str macro has an unusual ending semicolon but the vast
majority of uses of the macro already have semicolon termination.
$ git grep -P '\b__assign_str\b' | wc -l
551
$ git grep -P '\b__assign_str\b.*;' | wc -l
480
Add semicolons to the __assign_str() uses without semicolon termination
and all the other uses without semicolon termination via additional defines
that are equivalent to __assign_str() with the eventual goal of removing
the semicolon from the __assign_str() macro definition.
Link:
https://lore.kernel.org/lkml/1e068d21106bb6db05b735b4916bb420e6c9842a.ca...@perches.com/
Signed-off-by: Joe Perches
---
Resending without all the direct cc's, only the mailing lists as
it seems not to have gone through via vger.
Compiled x84-64 allyesconfig
On Fri, 2021-06-04 at 12:21 -0400, Steven Rostedt wrote:
> I have no problem taking a clean up patch that adds semicolons to all
> use cases of "__assign_str()" and ever remove the one from where it is
> defined. As long as it doesn't break any builds, I'm fine with that.
Removing the semicolon from the macro definition is left for another patch.
drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 14
drivers/gpu/drm/lima/lima_trace.h | 2 +-
drivers/infiniband/hw/hfi1/trace_misc.h| 4 +--
drivers/infiniband/hw/hfi1/trace_rc.h | 4 +--
drivers/infiniband/hw/hfi1/trace_tid.h | 6 ++--
drivers/infiniband/hw/hfi1/trace_tx.h | 8 ++---
drivers/infiniband/sw/rdmavt/trace_cq.h| 4 +--
drivers/infiniband/sw/rdmavt/trace_mr.h| 2 +-
drivers/infiniband/sw/rdmavt/trace_qp.h| 4 +--
drivers/infiniband/sw/rdmavt/trace_rc.h| 2 +-
drivers/infiniband/sw/rdmavt/trace_tx.h| 4 +--
drivers/misc/mei/mei-trace.h | 6 ++--
.../net/ethernet/marvell/octeontx2/af/rvu_trace.h | 12 +++
drivers/net/fjes/fjes_trace.h | 4 +--
drivers/usb/cdns3/cdnsp-trace.h| 2 +-
fs/nfs/nfs4trace.h | 6 ++--
fs/nfs/nfstrace.h | 4 +--
include/trace/events/btrfs.h | 2 +-
include/trace/events/dma_fence.h | 4 +--
include/trace/events/rpcgss.h | 4 +--
include/trace/events/sunrpc.h | 40 +++---
net/mac80211/trace.h | 2 +-
22 files changed, 70 insertions(+), 70 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
index 0527772fe1b80..d855cb53c7e09 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
@@ -176,10 +176,10 @@ TRACE_EVENT(amdgpu_cs_ioctl,
TP_fast_assign(
__entry->sched_job_id = job->base.id;
- __assign_str(timeline,
AMDGPU_JOB_GET_TIMELINE_NAME(job))
+ __assign_str(timeline,
AMDGPU_JOB_GET_TIMELINE_NAME(job));
__entry->context =
job->base.s_fence->finished.context;
__entry->seqno = job->base.s_fence->finished.seqno;
- __assign_str(ring,
to_amdgpu_ring(job->base.sched)->name)
+ __assign_str(ring,
to_amdgpu_ring(job->base.sched)->name);
__entry->num_ibs = job->num_ibs;
),
TP_printk("sched_job=%llu, timeline=%s, context=%u, seqno=%u,
ring_name=%s, num_ibs=%u",
@@ -201,10 +201,10 @@ TRACE_EVENT(amdgpu_sched_run_job,
TP_fast_assign(
__entry->sched_job_id = job->base.id;
- __assign_str(timeline,
AMDGPU_JOB_GET_TIMELINE_NAME(job))
+ __assign_str(timeline,
AMDGPU_JOB_GET_TIMELINE_NAME(job));
__entry->context =
job->base.s_fence->finished.context;
__entry->seqno = job->base.s_fence->finished.seqno;
- __assign_str(ring,
to_amdgpu_ring(job->base.sched)->name)
+ __assign_str(ring,
to_amdgpu_ring(job->base.sched)->name);
__entry->num_ibs = job->num_ibs;
),
TP_printk("sched_job=%llu, timeline=%s, context=%u, seqno=%u,
ring_name=%s, num_ibs=%u",
@@ -229,7 +229,7 @@ TRACE_EVENT(amdgpu_vm_grab_id,
TP_fast_assign(
__entry->pasid = vm->pasid;
- __assign_str(ring, ring->name)
+ __assign_str(ring, ring->name);
__entry->vmid = job->vmid;
__entry->vm_hub = ring->funcs->vmhub,
__entry->pd_addr = job->vm_pd_addr;
@@ -424,7 +424,7 @@ TRACE_EVENT(amdgpu_vm_flush,
Re: [PATCH 8/9] drm/i915: Move submission tasklet to i915_sched_engine
On Thu, Jun 3, 2021 at 4:09 PM Matthew Brost wrote:
>
> The submission tasklet operates on i915_sched_engine, thus it is the
> correct place for it.
>
> Signed-off-by: Matthew Brost
> ---
> drivers/gpu/drm/i915/gt/intel_engine.h| 14 ---
> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 12 +--
> drivers/gpu/drm/i915/gt/intel_engine_types.h | 5 --
> .../drm/i915/gt/intel_execlists_submission.c | 86 ++-
> drivers/gpu/drm/i915/gt/mock_engine.c | 1 +
> drivers/gpu/drm/i915/gt/selftest_execlists.c | 16 ++--
> drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 2 +-
> drivers/gpu/drm/i915/gt/selftest_lrc.c| 6 +-
> drivers/gpu/drm/i915/gt/selftest_reset.c | 2 +-
> .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 25 +++---
> drivers/gpu/drm/i915/i915_scheduler.c | 1 +
> drivers/gpu/drm/i915/i915_scheduler.h | 14 +++
> drivers/gpu/drm/i915/i915_scheduler_types.h | 8 ++
> 13 files changed, 99 insertions(+), 93 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
> b/drivers/gpu/drm/i915/gt/intel_engine.h
> index a8b2174b4395..988d9688ae4d 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine.h
> +++ b/drivers/gpu/drm/i915/gt/intel_engine.h
> @@ -123,20 +123,6 @@ execlists_active(const struct intel_engine_execlists
> *execlists)
> return active;
> }
>
> -static inline void
> -execlists_active_lock_bh(struct intel_engine_execlists *execlists)
> -{
> - local_bh_disable(); /* prevent local softirq and lock recursion */
> - tasklet_lock(>tasklet);
> -}
> -
> -static inline void
> -execlists_active_unlock_bh(struct intel_engine_execlists *execlists)
> -{
> - tasklet_unlock(>tasklet);
> - local_bh_enable(); /* restore softirq, and kick ksoftirqd! */
> -}
> -
> struct i915_request *
> execlists_unwind_incomplete_requests(struct intel_engine_execlists
> *execlists);
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index b480fcb1aad1..837d2132e31b 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -711,6 +711,7 @@ static int engine_setup_common(struct intel_engine_cs
> *engine)
> err = -ENOMEM;
> goto err_sched_engine;
> }
> + engine->sched_engine->engine = engine;
This bothers me. If we're trying to separate things, why do we have a
back pointer? Yes, I know it's because we need to access our engine
back-end somehow. Makes me wonder if it should be some sort of a
void* private data pointer instead of the engine. That's probably
less safe but it seems more "right" in some sense? I don't know.
Also, dumb question but what's a tasklet?
--Jason
>
> err = intel_engine_init_cmd_parser(engine);
> if (err)
> @@ -935,7 +936,6 @@ int intel_engines_init(struct intel_gt *gt)
> void intel_engine_cleanup_common(struct intel_engine_cs *engine)
> {
> GEM_BUG_ON(!list_empty(>sched_engine->requests));
> - tasklet_kill(>execlists.tasklet); /* flush the callback */
>
> i915_sched_engine_put(engine->sched_engine);
> intel_breadcrumbs_free(engine->breadcrumbs);
> @@ -1221,7 +1221,7 @@ static bool ring_is_idle(struct intel_engine_cs *engine)
>
> void __intel_engine_flush_submission(struct intel_engine_cs *engine, bool
> sync)
> {
> - struct tasklet_struct *t = >execlists.tasklet;
> + struct tasklet_struct *t = >sched_engine->tasklet;
>
> if (!t->callback)
> return;
> @@ -1482,8 +1482,8 @@ static void intel_engine_print_registers(struct
> intel_engine_cs *engine,
>
> drm_printf(m, "\tExeclist tasklet queued? %s (%s), preempt?
> %s, timeslice? %s\n",
>yesno(test_bit(TASKLET_STATE_SCHED,
> - >execlists.tasklet.state)),
> -
> enableddisabled(!atomic_read(>execlists.tasklet.count)),
> +
> >sched_engine->tasklet.state)),
> +
> enableddisabled(!atomic_read(>sched_engine->tasklet.count)),
>repr_timer(>execlists.preempt),
>repr_timer(>execlists.timer));
>
> @@ -1507,7 +1507,7 @@ static void intel_engine_print_registers(struct
> intel_engine_cs *engine,
>idx, hws[idx * 2], hws[idx * 2 + 1]);
> }
>
> - execlists_active_lock_bh(execlists);
> + i915_sched_engine_active_lock_bh(engine->sched_engine);
> rcu_read_lock();
> for (port = execlists->active; (rq = *port); port++) {
> char hdr[160];
> @@ -1538,7 +1538,7 @@ static void intel_engine_print_registers(struct
> intel_engine_cs *engine,
> i915_request_show(m, rq, hdr, 0);
> }
> rcu_read_unlock();
Re: [PATCH 6/9] drm/i915: Add kick_backend function to i915_sched_engine
On Fri, Jun 04, 2021 at 02:09:46PM -0500, Jason Ekstrand wrote:
> On Thu, Jun 3, 2021 at 4:09 PM Matthew Brost wrote:
> >
> > Rather than touching execlist specific structures in the generic
> > scheduling code, add a callback function in the backend.
>
> Seems reasonable but why does the function that's there today do
> nothing for the ringbuffer and current GuC back-ends? I'm sure
> there's some reason but it's not immediately obvious to me.
>
This code isn't used for ringbuffer submission and the current GuC
back-end is non-functional. The upcoming backend doesn't use these
structures nor does it is need to be kicked as it is always running if
requests are in the queue. So for the upcoming backend this function is
NULL.
Matt
> --Jason
>
>
> > Signed-off-by: Matthew Brost
> > ---
> > .../drm/i915/gt/intel_execlists_submission.c | 52
> > drivers/gpu/drm/i915/i915_scheduler.c | 62 +--
> > drivers/gpu/drm/i915/i915_scheduler_types.h | 4 ++
> > 3 files changed, 58 insertions(+), 60 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > index 23fd03815ad0..3fac17103837 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > @@ -3116,10 +3116,61 @@ static bool can_preempt(struct intel_engine_cs
> > *engine)
> > return engine->class != RENDER_CLASS;
> > }
> >
> > +static void kick_execlists(const struct i915_request *rq, int prio)
> > +{
> > + struct intel_engine_cs *engine = rq->engine;
> > + struct i915_sched_engine *sched_engine = engine->sched_engine;
> > + const struct i915_request *inflight;
> > +
> > + /*
> > +* We only need to kick the tasklet once for the high priority
> > +* new context we add into the queue.
> > +*/
> > + if (prio <= sched_engine->queue_priority_hint)
> > + return;
> > +
> > + rcu_read_lock();
> > +
> > + /* Nothing currently active? We're overdue for a submission! */
> > + inflight = execlists_active(>execlists);
> > + if (!inflight)
> > + goto unlock;
> > +
> > + /*
> > +* If we are already the currently executing context, don't
> > +* bother evaluating if we should preempt ourselves.
> > +*/
> > + if (inflight->context == rq->context)
> > + goto unlock;
> > +
> > + ENGINE_TRACE(engine,
> > +"bumping queue-priority-hint:%d for rq:%llx:%lld,
> > inflight:%llx:%lld prio %d\n",
> > +prio,
> > +rq->fence.context, rq->fence.seqno,
> > +inflight->fence.context, inflight->fence.seqno,
> > +inflight->sched.attr.priority);
> > +
> > + sched_engine->queue_priority_hint = prio;
> > +
> > + /*
> > +* Allow preemption of low -> normal -> high, but we do
> > +* not allow low priority tasks to preempt other low priority
> > +* tasks under the impression that latency for low priority
> > +* tasks does not matter (as much as background throughput),
> > +* so kiss.
> > +*/
> > + if (prio >= max(I915_PRIORITY_NORMAL, rq_prio(inflight)))
> > + tasklet_hi_schedule(>execlists.tasklet);
> > +
> > +unlock:
> > + rcu_read_unlock();
> > +}
> > +
> > static void execlists_set_default_submission(struct intel_engine_cs
> > *engine)
> > {
> > engine->submit_request = execlists_submit_request;
> > engine->sched_engine->schedule = i915_schedule;
> > + engine->sched_engine->kick_backend = kick_execlists;
> > engine->execlists.tasklet.callback = execlists_submission_tasklet;
> > }
> >
> > @@ -3702,6 +3753,7 @@ intel_execlists_create_virtual(struct intel_engine_cs
> > **siblings,
> > ve->base.request_alloc = execlists_request_alloc;
> >
> > ve->base.sched_engine->schedule = i915_schedule;
> > + ve->base.sched_engine->kick_backend = kick_execlists;
> > ve->base.submit_request = virtual_submit_request;
> > ve->base.bond_execute = virtual_bond_execute;
> >
> > diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
> > b/drivers/gpu/drm/i915/i915_scheduler.c
> > index 4bc6969f6a97..035b88f2e4aa 100644
> > --- a/drivers/gpu/drm/i915/i915_scheduler.c
> > +++ b/drivers/gpu/drm/i915/i915_scheduler.c
> > @@ -157,65 +157,6 @@ sched_lock_engine(const struct i915_sched_node *node,
> > return locked;
> > }
> >
> > -static inline int rq_prio(const struct i915_request *rq)
> > -{
> > - return rq->sched.attr.priority;
> > -}
> > -
> > -static inline bool need_preempt(int prio, int active)
> > -{
> > - /*
> > -* Allow preemption of low -> normal -> high, but we do
> > -* not allow low priority tasks to preempt other low priority
> > -*
Re: [Intel-gfx] [PATCH 7/9] drm/i915: Update i915_scheduler to operate on i915_sched_engine
On Fri, Jun 04, 2021 at 02:17:58PM -0500, Jason Ekstrand wrote:
> On Thu, Jun 3, 2021 at 4:09 PM Matthew Brost wrote:
> >
> > Rather passing around an intel_engine_cs in the scheduling code, pass
> > around a i915_sched_engine.
>
>
>
> > Signed-off-by: Matthew Brost
> > ---
> > .../drm/i915/gt/intel_execlists_submission.c | 11 +++--
> > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 2 +-
> > drivers/gpu/drm/i915/i915_scheduler.c | 46 +--
> > drivers/gpu/drm/i915/i915_scheduler.h | 2 +-
> > 4 files changed, 32 insertions(+), 29 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > index 3fac17103837..7240c153be35 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > @@ -382,7 +382,8 @@ __unwind_incomplete_requests(struct intel_engine_cs
> > *engine)
> > GEM_BUG_ON(rq_prio(rq) == I915_PRIORITY_INVALID);
> > if (rq_prio(rq) != prio) {
> > prio = rq_prio(rq);
> > - pl = i915_sched_lookup_priolist(engine, prio);
> > + pl =
> > i915_sched_lookup_priolist(engine->sched_engine,
> > + prio);
> > }
> >
> > GEM_BUG_ON(i915_sched_engine_is_empty(engine->sched_engine));
> >
> > @@ -1096,7 +1097,8 @@ static void defer_active(struct intel_engine_cs
> > *engine)
> > if (!rq)
> > return;
> >
> > - defer_request(rq, i915_sched_lookup_priolist(engine, rq_prio(rq)));
> > + defer_request(rq, i915_sched_lookup_priolist(engine->sched_engine,
> > +rq_prio(rq)));
> > }
> >
> > static bool
> > @@ -2083,7 +2085,7 @@ static void __execlists_unhold(struct i915_request
> > *rq)
> >
> > i915_request_clear_hold(rq);
> > list_move_tail(>sched.link,
> > - i915_sched_lookup_priolist(rq->engine,
> > +
> > i915_sched_lookup_priolist(rq->engine->sched_engine,
> > rq_prio(rq)));
> > set_bit(I915_FENCE_FLAG_PQUEUE, >fence.flags);
> >
> > @@ -2452,7 +2454,8 @@ static void queue_request(struct intel_engine_cs
> > *engine,
> > {
> > GEM_BUG_ON(!list_empty(>sched.link));
> > list_add_tail(>sched.link,
> > - i915_sched_lookup_priolist(engine, rq_prio(rq)));
> > + i915_sched_lookup_priolist(engine->sched_engine,
> > +rq_prio(rq)));
> > set_bit(I915_FENCE_FLAG_PQUEUE, >fence.flags);
> > }
> >
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > index 4c5bbec0775d..7ed21670ef14 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > @@ -529,7 +529,7 @@ static inline void queue_request(struct intel_engine_cs
> > *engine,
> > {
> > GEM_BUG_ON(!list_empty(>sched.link));
> > list_add_tail(>sched.link,
> > - i915_sched_lookup_priolist(engine, prio));
> > + i915_sched_lookup_priolist(engine->sched_engine,
> > prio));
> > set_bit(I915_FENCE_FLAG_PQUEUE, >fence.flags);
> > }
> >
> > diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
> > b/drivers/gpu/drm/i915/i915_scheduler.c
> > index 035b88f2e4aa..3d36e4447b5d 100644
> > --- a/drivers/gpu/drm/i915/i915_scheduler.c
> > +++ b/drivers/gpu/drm/i915/i915_scheduler.c
> > @@ -61,14 +61,13 @@ static void assert_priolists(struct i915_sched_engine *
> > const sched_engine)
> > }
> >
> > struct list_head *
> > -i915_sched_lookup_priolist(struct intel_engine_cs *engine, int prio)
> > +i915_sched_lookup_priolist(struct i915_sched_engine *sched_engine, int
> > prio)
> > {
> > - struct i915_sched_engine * const sched_engine =
> > engine->sched_engine;
> > struct i915_priolist *p;
> > struct rb_node **parent, *rb;
> > bool first = true;
> >
> > - lockdep_assert_held(>sched_engine->lock);
> > + lockdep_assert_held(_engine->lock);
> > assert_priolists(sched_engine);
> >
> > if (unlikely(sched_engine->no_priolist))
> > @@ -130,13 +129,13 @@ struct sched_cache {
> > struct list_head *priolist;
> > };
> >
> > -static struct intel_engine_cs *
> > -sched_lock_engine(const struct i915_sched_node *node,
> > - struct intel_engine_cs *locked,
> > +static struct i915_sched_engine *
> > +lock_sched_engine(struct i915_sched_node *node,
> > + struct i915_sched_engine *locked,
> > struct sched_cache *cache)
> > {
> > const
Re: [PATCH 4/9] drm/i915: Move active tracking to i915_sched_engine
On Fri, Jun 04, 2021 at 02:00:33PM -0500, Jason Ekstrand wrote:
> On Thu, Jun 3, 2021 at 4:09 PM Matthew Brost wrote:
> >
> > Move active request tracking and its lock to i915_sched_engine. This
> > lock is also the submission lock so having it in the i915_sched_engine
> > is the correct place.
> >
> > Signed-off-by: Matthew Brost
> > ---
> > drivers/gpu/drm/i915/gt/intel_engine.h| 2 -
> > drivers/gpu/drm/i915/gt/intel_engine_cs.c | 43 +++-
> > drivers/gpu/drm/i915/gt/intel_engine_types.h | 6 --
> > .../drm/i915/gt/intel_execlists_submission.c | 98 ++-
> > .../gpu/drm/i915/gt/intel_ring_submission.c | 12 +--
> > drivers/gpu/drm/i915/gt/mock_engine.c | 7 +-
> > drivers/gpu/drm/i915/gt/selftest_execlists.c | 4 +-
> > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 20 ++--
> > drivers/gpu/drm/i915/i915_gpu_error.c | 4 +-
> > drivers/gpu/drm/i915/i915_request.c | 32 +++---
> > drivers/gpu/drm/i915/i915_request.h | 2 +-
> > drivers/gpu/drm/i915/i915_scheduler.c | 30 --
> > drivers/gpu/drm/i915/i915_scheduler_types.h | 9 ++
> > 13 files changed, 134 insertions(+), 135 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
> > b/drivers/gpu/drm/i915/gt/intel_engine.h
> > index 8d9184920c51..a8b2174b4395 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine.h
> > @@ -257,8 +257,6 @@ intel_engine_find_active_request(struct intel_engine_cs
> > *engine);
> >
> > u32 intel_engine_context_size(struct intel_gt *gt, u8 class);
> >
> > -void intel_engine_init_active(struct intel_engine_cs *engine,
> > - unsigned int subclass);
> > #define ENGINE_PHYSICAL0
> > #define ENGINE_MOCK1
> > #define ENGINE_VIRTUAL 2
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > index 85f2effe9dc6..33d879137908 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > @@ -719,7 +719,6 @@ static int engine_setup_common(struct intel_engine_cs
> > *engine)
> > if (err)
> > goto err_cmd_parser;
> >
> > - intel_engine_init_active(engine, ENGINE_PHYSICAL);
> > intel_engine_init_execlists(engine);
> > intel_engine_init__pm(engine);
> > intel_engine_init_retire(engine);
> > @@ -778,11 +777,11 @@ static int measure_breadcrumb_dw(struct intel_context
> > *ce)
> > frame->rq.ring = >ring;
> >
> > mutex_lock(>timeline->mutex);
> > - spin_lock_irq(>active.lock);
> > + spin_lock_irq(>sched_engine->lock);
> >
> > dw = engine->emit_fini_breadcrumb(>rq, frame->cs) -
> > frame->cs;
> >
> > - spin_unlock_irq(>active.lock);
> > + spin_unlock_irq(>sched_engine->lock);
> > mutex_unlock(>timeline->mutex);
> >
> > GEM_BUG_ON(dw & 1); /* RING_TAIL must be qword aligned */
> > @@ -791,28 +790,6 @@ static int measure_breadcrumb_dw(struct intel_context
> > *ce)
> > return dw;
> > }
> >
> > -void
> > -intel_engine_init_active(struct intel_engine_cs *engine, unsigned int
> > subclass)
> > -{
> > - INIT_LIST_HEAD(>active.requests);
> > - INIT_LIST_HEAD(>active.hold);
> > -
> > - spin_lock_init(>active.lock);
> > - lockdep_set_subclass(>active.lock, subclass);
> > -
> > - /*
> > -* Due to an interesting quirk in lockdep's internal debug tracking,
> > -* after setting a subclass we must ensure the lock is used.
> > Otherwise,
> > -* nr_unused_locks is incremented once too often.
> > -*/
> > -#ifdef CONFIG_DEBUG_LOCK_ALLOC
> > - local_irq_disable();
> > - lock_map_acquire(>active.lock.dep_map);
> > - lock_map_release(>active.lock.dep_map);
> > - local_irq_enable();
> > -#endif
> > -}
> > -
> > static struct intel_context *
> > create_pinned_context(struct intel_engine_cs *engine,
> > unsigned int hwsp,
> > @@ -960,7 +937,7 @@ int intel_engines_init(struct intel_gt *gt)
> > */
> > void intel_engine_cleanup_common(struct intel_engine_cs *engine)
> > {
> > - GEM_BUG_ON(!list_empty(>active.requests));
> > + GEM_BUG_ON(!list_empty(>sched_engine->requests));
> > tasklet_kill(>execlists.tasklet); /* flush the callback */
> >
> > i915_sched_engine_put(engine->sched_engine);
> > @@ -1353,7 +1330,7 @@ static struct intel_timeline *get_timeline(struct
> > i915_request *rq)
> > struct intel_timeline *tl;
> >
> > /*
> > -* Even though we are holding the engine->active.lock here, there
> > +* Even though we are holding the engine->sched_engine->lock here,
> > there
> > * is no control over the submission queue per-se and we are
> > * inspecting the active state at a random point in time, with an
> > * unknown queue. Play safe
Re: [Intel-gfx] [PATCH 7/9] drm/i915: Update i915_scheduler to operate on i915_sched_engine
On Thu, Jun 3, 2021 at 4:09 PM Matthew Brost wrote:
>
> Rather passing around an intel_engine_cs in the scheduling code, pass
> around a i915_sched_engine.
> Signed-off-by: Matthew Brost
> ---
> .../drm/i915/gt/intel_execlists_submission.c | 11 +++--
> .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 2 +-
> drivers/gpu/drm/i915/i915_scheduler.c | 46 +--
> drivers/gpu/drm/i915/i915_scheduler.h | 2 +-
> 4 files changed, 32 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> index 3fac17103837..7240c153be35 100644
> --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> @@ -382,7 +382,8 @@ __unwind_incomplete_requests(struct intel_engine_cs
> *engine)
> GEM_BUG_ON(rq_prio(rq) == I915_PRIORITY_INVALID);
> if (rq_prio(rq) != prio) {
> prio = rq_prio(rq);
> - pl = i915_sched_lookup_priolist(engine, prio);
> + pl = i915_sched_lookup_priolist(engine->sched_engine,
> + prio);
> }
> GEM_BUG_ON(i915_sched_engine_is_empty(engine->sched_engine));
>
> @@ -1096,7 +1097,8 @@ static void defer_active(struct intel_engine_cs *engine)
> if (!rq)
> return;
>
> - defer_request(rq, i915_sched_lookup_priolist(engine, rq_prio(rq)));
> + defer_request(rq, i915_sched_lookup_priolist(engine->sched_engine,
> +rq_prio(rq)));
> }
>
> static bool
> @@ -2083,7 +2085,7 @@ static void __execlists_unhold(struct i915_request *rq)
>
> i915_request_clear_hold(rq);
> list_move_tail(>sched.link,
> - i915_sched_lookup_priolist(rq->engine,
> +
> i915_sched_lookup_priolist(rq->engine->sched_engine,
> rq_prio(rq)));
> set_bit(I915_FENCE_FLAG_PQUEUE, >fence.flags);
>
> @@ -2452,7 +2454,8 @@ static void queue_request(struct intel_engine_cs
> *engine,
> {
> GEM_BUG_ON(!list_empty(>sched.link));
> list_add_tail(>sched.link,
> - i915_sched_lookup_priolist(engine, rq_prio(rq)));
> + i915_sched_lookup_priolist(engine->sched_engine,
> +rq_prio(rq)));
> set_bit(I915_FENCE_FLAG_PQUEUE, >fence.flags);
> }
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> index 4c5bbec0775d..7ed21670ef14 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> @@ -529,7 +529,7 @@ static inline void queue_request(struct intel_engine_cs
> *engine,
> {
> GEM_BUG_ON(!list_empty(>sched.link));
> list_add_tail(>sched.link,
> - i915_sched_lookup_priolist(engine, prio));
> + i915_sched_lookup_priolist(engine->sched_engine, prio));
> set_bit(I915_FENCE_FLAG_PQUEUE, >fence.flags);
> }
>
> diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
> b/drivers/gpu/drm/i915/i915_scheduler.c
> index 035b88f2e4aa..3d36e4447b5d 100644
> --- a/drivers/gpu/drm/i915/i915_scheduler.c
> +++ b/drivers/gpu/drm/i915/i915_scheduler.c
> @@ -61,14 +61,13 @@ static void assert_priolists(struct i915_sched_engine *
> const sched_engine)
> }
>
> struct list_head *
> -i915_sched_lookup_priolist(struct intel_engine_cs *engine, int prio)
> +i915_sched_lookup_priolist(struct i915_sched_engine *sched_engine, int prio)
> {
> - struct i915_sched_engine * const sched_engine = engine->sched_engine;
> struct i915_priolist *p;
> struct rb_node **parent, *rb;
> bool first = true;
>
> - lockdep_assert_held(>sched_engine->lock);
> + lockdep_assert_held(_engine->lock);
> assert_priolists(sched_engine);
>
> if (unlikely(sched_engine->no_priolist))
> @@ -130,13 +129,13 @@ struct sched_cache {
> struct list_head *priolist;
> };
>
> -static struct intel_engine_cs *
> -sched_lock_engine(const struct i915_sched_node *node,
> - struct intel_engine_cs *locked,
> +static struct i915_sched_engine *
> +lock_sched_engine(struct i915_sched_node *node,
> + struct i915_sched_engine *locked,
> struct sched_cache *cache)
> {
> const struct i915_request *rq = node_to_request(node);
> - struct intel_engine_cs *engine;
> + struct i915_sched_engine *sched_engine;
>
> GEM_BUG_ON(!locked);
>
> @@ -146,14 +145,14 @@ sched_lock_engine(const struct i915_sched_node *node,
> * engine lock. The simple ploy we use is to take the lock
[PATCH] treewide: Add missing semicolons to __assign_str uses
The __assign_str macro has an unusual ending semicolon but the vast
majority of uses of the macro already have semicolon termination.
$ git grep -P '\b__assign_str\b' | wc -l
551
$ git grep -P '\b__assign_str\b.*;' | wc -l
480
Add semicolons to the __assign_str() uses without semicolon termination
and all the other uses without semicolon termination via additional defines
that are equivalent to __assign_str() with the eventual goal of removing
the semicolon from the __assign_str() macro definition.
Link:
https://lore.kernel.org/lkml/1e068d21106bb6db05b735b4916bb420e6c9842a.ca...@perches.com/
Signed-off-by: Joe Perches
---
Compiled x84-64 allyesconfig
On Fri, 2021-06-04 at 12:21 -0400, Steven Rostedt wrote:
> I have no problem taking a clean up patch that adds semicolons to all
> use cases of "__assign_str()" and ever remove the one from where it is
> defined. As long as it doesn't break any builds, I'm fine with that.
Removing the semicolon from the macro definition is left for another patch.
drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 14
drivers/gpu/drm/lima/lima_trace.h | 2 +-
drivers/infiniband/hw/hfi1/trace_misc.h| 4 +--
drivers/infiniband/hw/hfi1/trace_rc.h | 4 +--
drivers/infiniband/hw/hfi1/trace_tid.h | 6 ++--
drivers/infiniband/hw/hfi1/trace_tx.h | 8 ++---
drivers/infiniband/sw/rdmavt/trace_cq.h| 4 +--
drivers/infiniband/sw/rdmavt/trace_mr.h| 2 +-
drivers/infiniband/sw/rdmavt/trace_qp.h| 4 +--
drivers/infiniband/sw/rdmavt/trace_rc.h| 2 +-
drivers/infiniband/sw/rdmavt/trace_tx.h| 4 +--
drivers/misc/mei/mei-trace.h | 6 ++--
.../net/ethernet/marvell/octeontx2/af/rvu_trace.h | 12 +++
drivers/net/fjes/fjes_trace.h | 4 +--
drivers/usb/cdns3/cdnsp-trace.h| 2 +-
fs/nfs/nfs4trace.h | 6 ++--
fs/nfs/nfstrace.h | 4 +--
include/trace/events/btrfs.h | 2 +-
include/trace/events/dma_fence.h | 4 +--
include/trace/events/rpcgss.h | 4 +--
include/trace/events/sunrpc.h | 40 +++---
net/mac80211/trace.h | 2 +-
22 files changed, 70 insertions(+), 70 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
index 0527772fe1b80..d855cb53c7e09 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
@@ -176,10 +176,10 @@ TRACE_EVENT(amdgpu_cs_ioctl,
TP_fast_assign(
__entry->sched_job_id = job->base.id;
- __assign_str(timeline,
AMDGPU_JOB_GET_TIMELINE_NAME(job))
+ __assign_str(timeline,
AMDGPU_JOB_GET_TIMELINE_NAME(job));
__entry->context =
job->base.s_fence->finished.context;
__entry->seqno = job->base.s_fence->finished.seqno;
- __assign_str(ring,
to_amdgpu_ring(job->base.sched)->name)
+ __assign_str(ring,
to_amdgpu_ring(job->base.sched)->name);
__entry->num_ibs = job->num_ibs;
),
TP_printk("sched_job=%llu, timeline=%s, context=%u, seqno=%u,
ring_name=%s, num_ibs=%u",
@@ -201,10 +201,10 @@ TRACE_EVENT(amdgpu_sched_run_job,
TP_fast_assign(
__entry->sched_job_id = job->base.id;
- __assign_str(timeline,
AMDGPU_JOB_GET_TIMELINE_NAME(job))
+ __assign_str(timeline,
AMDGPU_JOB_GET_TIMELINE_NAME(job));
__entry->context =
job->base.s_fence->finished.context;
__entry->seqno = job->base.s_fence->finished.seqno;
- __assign_str(ring,
to_amdgpu_ring(job->base.sched)->name)
+ __assign_str(ring,
to_amdgpu_ring(job->base.sched)->name);
__entry->num_ibs = job->num_ibs;
),
TP_printk("sched_job=%llu, timeline=%s, context=%u, seqno=%u,
ring_name=%s, num_ibs=%u",
@@ -229,7 +229,7 @@ TRACE_EVENT(amdgpu_vm_grab_id,
TP_fast_assign(
__entry->pasid = vm->pasid;
- __assign_str(ring, ring->name)
+ __assign_str(ring, ring->name);
__entry->vmid = job->vmid;
__entry->vm_hub = ring->funcs->vmhub,
__entry->pd_addr = job->vm_pd_addr;
@@ -424,7 +424,7 @@ TRACE_EVENT(amdgpu_vm_flush,
),
TP_fast_assign(
- __assign_str(ring, ring->name)
+
Re: [PATCH 6/9] drm/i915: Add kick_backend function to i915_sched_engine
On Thu, Jun 3, 2021 at 4:09 PM Matthew Brost wrote:
>
> Rather than touching execlist specific structures in the generic
> scheduling code, add a callback function in the backend.
Seems reasonable but why does the function that's there today do
nothing for the ringbuffer and current GuC back-ends? I'm sure
there's some reason but it's not immediately obvious to me.
--Jason
> Signed-off-by: Matthew Brost
> ---
> .../drm/i915/gt/intel_execlists_submission.c | 52
> drivers/gpu/drm/i915/i915_scheduler.c | 62 +--
> drivers/gpu/drm/i915/i915_scheduler_types.h | 4 ++
> 3 files changed, 58 insertions(+), 60 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> index 23fd03815ad0..3fac17103837 100644
> --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> @@ -3116,10 +3116,61 @@ static bool can_preempt(struct intel_engine_cs
> *engine)
> return engine->class != RENDER_CLASS;
> }
>
> +static void kick_execlists(const struct i915_request *rq, int prio)
> +{
> + struct intel_engine_cs *engine = rq->engine;
> + struct i915_sched_engine *sched_engine = engine->sched_engine;
> + const struct i915_request *inflight;
> +
> + /*
> +* We only need to kick the tasklet once for the high priority
> +* new context we add into the queue.
> +*/
> + if (prio <= sched_engine->queue_priority_hint)
> + return;
> +
> + rcu_read_lock();
> +
> + /* Nothing currently active? We're overdue for a submission! */
> + inflight = execlists_active(>execlists);
> + if (!inflight)
> + goto unlock;
> +
> + /*
> +* If we are already the currently executing context, don't
> +* bother evaluating if we should preempt ourselves.
> +*/
> + if (inflight->context == rq->context)
> + goto unlock;
> +
> + ENGINE_TRACE(engine,
> +"bumping queue-priority-hint:%d for rq:%llx:%lld,
> inflight:%llx:%lld prio %d\n",
> +prio,
> +rq->fence.context, rq->fence.seqno,
> +inflight->fence.context, inflight->fence.seqno,
> +inflight->sched.attr.priority);
> +
> + sched_engine->queue_priority_hint = prio;
> +
> + /*
> +* Allow preemption of low -> normal -> high, but we do
> +* not allow low priority tasks to preempt other low priority
> +* tasks under the impression that latency for low priority
> +* tasks does not matter (as much as background throughput),
> +* so kiss.
> +*/
> + if (prio >= max(I915_PRIORITY_NORMAL, rq_prio(inflight)))
> + tasklet_hi_schedule(>execlists.tasklet);
> +
> +unlock:
> + rcu_read_unlock();
> +}
> +
> static void execlists_set_default_submission(struct intel_engine_cs *engine)
> {
> engine->submit_request = execlists_submit_request;
> engine->sched_engine->schedule = i915_schedule;
> + engine->sched_engine->kick_backend = kick_execlists;
> engine->execlists.tasklet.callback = execlists_submission_tasklet;
> }
>
> @@ -3702,6 +3753,7 @@ intel_execlists_create_virtual(struct intel_engine_cs
> **siblings,
> ve->base.request_alloc = execlists_request_alloc;
>
> ve->base.sched_engine->schedule = i915_schedule;
> + ve->base.sched_engine->kick_backend = kick_execlists;
> ve->base.submit_request = virtual_submit_request;
> ve->base.bond_execute = virtual_bond_execute;
>
> diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
> b/drivers/gpu/drm/i915/i915_scheduler.c
> index 4bc6969f6a97..035b88f2e4aa 100644
> --- a/drivers/gpu/drm/i915/i915_scheduler.c
> +++ b/drivers/gpu/drm/i915/i915_scheduler.c
> @@ -157,65 +157,6 @@ sched_lock_engine(const struct i915_sched_node *node,
> return locked;
> }
>
> -static inline int rq_prio(const struct i915_request *rq)
> -{
> - return rq->sched.attr.priority;
> -}
> -
> -static inline bool need_preempt(int prio, int active)
> -{
> - /*
> -* Allow preemption of low -> normal -> high, but we do
> -* not allow low priority tasks to preempt other low priority
> -* tasks under the impression that latency for low priority
> -* tasks does not matter (as much as background throughput),
> -* so kiss.
> -*/
> - return prio >= max(I915_PRIORITY_NORMAL, active);
> -}
> -
> -static void kick_submission(struct intel_engine_cs *engine,
> - const struct i915_request *rq,
> - int prio)
> -{
> - const struct i915_request *inflight;
> -
> - /*
> -* We only need to kick the tasklet once for the high priority
> -* new context we add into the queue.
> -
Re: [Intel-gfx] [PATCH 5/9] drm/i915: Move engine->schedule to i915_sched_engine
On Thu, Jun 3, 2021 at 4:09 PM Matthew Brost wrote:
>
> The schedule function should be in the schedule object.
>
> Signed-off-by: Matthew Brost
> ---
> drivers/gpu/drm/i915/gem/i915_gem_wait.c | 4 ++--
> drivers/gpu/drm/i915/gt/intel_engine_cs.c| 3 ---
> drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c | 4 ++--
> drivers/gpu/drm/i915/gt/intel_engine_types.h | 8
> drivers/gpu/drm/i915/gt/intel_engine_user.c | 2 +-
> .../gpu/drm/i915/gt/intel_execlists_submission.c | 4 ++--
> drivers/gpu/drm/i915/gt/selftest_execlists.c | 16
> drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 4 ++--
> .../gpu/drm/i915/gt/uc/intel_guc_submission.c| 2 +-
> drivers/gpu/drm/i915/i915_request.c | 10 +-
> drivers/gpu/drm/i915/i915_scheduler_types.h | 8
> 11 files changed, 31 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_wait.c
> b/drivers/gpu/drm/i915/gem/i915_gem_wait.c
> index 4b9856d5ba14..af1fbf8e2a9a 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_wait.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_wait.c
> @@ -104,8 +104,8 @@ static void fence_set_priority(struct dma_fence *fence,
> engine = rq->engine;
>
> rcu_read_lock(); /* RCU serialisation for set-wedged protection */
> - if (engine->schedule)
> - engine->schedule(rq, attr);
> + if (engine->sched_engine->schedule)
> + engine->sched_engine->schedule(rq, attr);
> rcu_read_unlock();
> }
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index 33d879137908..b480fcb1aad1 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -326,9 +326,6 @@ static int intel_engine_setup(struct intel_gt *gt, enum
> intel_engine_id id)
> if (engine->context_size)
> DRIVER_CAPS(i915)->has_logical_contexts = true;
>
> - /* Nothing to do here, execute in order of dependencies */
> - engine->schedule = NULL;
> -
> ewma__engine_latency_init(>latency);
> seqcount_init(>stats.lock);
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> index b99ac41695f3..b6a305e6a974 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> @@ -121,7 +121,7 @@ static void heartbeat(struct work_struct *wrk)
> * but all other contexts, including the kernel
> * context are stuck waiting for the signal.
> */
> - } else if (engine->schedule &&
> + } else if (engine->sched_engine->schedule &&
>rq->sched.attr.priority < I915_PRIORITY_BARRIER) {
> /*
> * Gradually raise the priority of the heartbeat to
> @@ -136,7 +136,7 @@ static void heartbeat(struct work_struct *wrk)
> attr.priority = I915_PRIORITY_BARRIER;
>
> local_bh_disable();
> - engine->schedule(rq, );
> + engine->sched_engine->schedule(rq, );
> local_bh_enable();
> } else {
> if (IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM))
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> index 7197b9fa5e35..f1b14aff5118 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> @@ -426,14 +426,6 @@ struct intel_engine_cs {
> void(*bond_execute)(struct i915_request *rq,
> struct dma_fence *signal);
>
> - /*
> -* Call when the priority on a request has changed and it and its
> -* dependencies may need rescheduling. Note the request itself may
> -* not be ready to run!
> -*/
> - void(*schedule)(struct i915_request *request,
> - const struct i915_sched_attr *attr);
> -
> void(*release)(struct intel_engine_cs *engine);
>
> struct intel_engine_execlists execlists;
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c
> b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> index 3cca7ea2d6ea..84142127ebd8 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> @@ -108,7 +108,7 @@ static void set_scheduler_caps(struct drm_i915_private
> *i915)
> for_each_uabi_engine(engine, i915) { /* all engines must agree! */
> int i;
>
> - if (engine->schedule)
> + if (engine->sched_engine->schedule)
> enabled |=
Re: [PATCH 4/9] drm/i915: Move active tracking to i915_sched_engine
On Thu, Jun 3, 2021 at 4:09 PM Matthew Brost wrote:
>
> Move active request tracking and its lock to i915_sched_engine. This
> lock is also the submission lock so having it in the i915_sched_engine
> is the correct place.
>
> Signed-off-by: Matthew Brost
> ---
> drivers/gpu/drm/i915/gt/intel_engine.h| 2 -
> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 43 +++-
> drivers/gpu/drm/i915/gt/intel_engine_types.h | 6 --
> .../drm/i915/gt/intel_execlists_submission.c | 98 ++-
> .../gpu/drm/i915/gt/intel_ring_submission.c | 12 +--
> drivers/gpu/drm/i915/gt/mock_engine.c | 7 +-
> drivers/gpu/drm/i915/gt/selftest_execlists.c | 4 +-
> .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 20 ++--
> drivers/gpu/drm/i915/i915_gpu_error.c | 4 +-
> drivers/gpu/drm/i915/i915_request.c | 32 +++---
> drivers/gpu/drm/i915/i915_request.h | 2 +-
> drivers/gpu/drm/i915/i915_scheduler.c | 30 --
> drivers/gpu/drm/i915/i915_scheduler_types.h | 9 ++
> 13 files changed, 134 insertions(+), 135 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
> b/drivers/gpu/drm/i915/gt/intel_engine.h
> index 8d9184920c51..a8b2174b4395 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine.h
> +++ b/drivers/gpu/drm/i915/gt/intel_engine.h
> @@ -257,8 +257,6 @@ intel_engine_find_active_request(struct intel_engine_cs
> *engine);
>
> u32 intel_engine_context_size(struct intel_gt *gt, u8 class);
>
> -void intel_engine_init_active(struct intel_engine_cs *engine,
> - unsigned int subclass);
> #define ENGINE_PHYSICAL0
> #define ENGINE_MOCK1
> #define ENGINE_VIRTUAL 2
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index 85f2effe9dc6..33d879137908 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -719,7 +719,6 @@ static int engine_setup_common(struct intel_engine_cs
> *engine)
> if (err)
> goto err_cmd_parser;
>
> - intel_engine_init_active(engine, ENGINE_PHYSICAL);
> intel_engine_init_execlists(engine);
> intel_engine_init__pm(engine);
> intel_engine_init_retire(engine);
> @@ -778,11 +777,11 @@ static int measure_breadcrumb_dw(struct intel_context
> *ce)
> frame->rq.ring = >ring;
>
> mutex_lock(>timeline->mutex);
> - spin_lock_irq(>active.lock);
> + spin_lock_irq(>sched_engine->lock);
>
> dw = engine->emit_fini_breadcrumb(>rq, frame->cs) - frame->cs;
>
> - spin_unlock_irq(>active.lock);
> + spin_unlock_irq(>sched_engine->lock);
> mutex_unlock(>timeline->mutex);
>
> GEM_BUG_ON(dw & 1); /* RING_TAIL must be qword aligned */
> @@ -791,28 +790,6 @@ static int measure_breadcrumb_dw(struct intel_context
> *ce)
> return dw;
> }
>
> -void
> -intel_engine_init_active(struct intel_engine_cs *engine, unsigned int
> subclass)
> -{
> - INIT_LIST_HEAD(>active.requests);
> - INIT_LIST_HEAD(>active.hold);
> -
> - spin_lock_init(>active.lock);
> - lockdep_set_subclass(>active.lock, subclass);
> -
> - /*
> -* Due to an interesting quirk in lockdep's internal debug tracking,
> -* after setting a subclass we must ensure the lock is used.
> Otherwise,
> -* nr_unused_locks is incremented once too often.
> -*/
> -#ifdef CONFIG_DEBUG_LOCK_ALLOC
> - local_irq_disable();
> - lock_map_acquire(>active.lock.dep_map);
> - lock_map_release(>active.lock.dep_map);
> - local_irq_enable();
> -#endif
> -}
> -
> static struct intel_context *
> create_pinned_context(struct intel_engine_cs *engine,
> unsigned int hwsp,
> @@ -960,7 +937,7 @@ int intel_engines_init(struct intel_gt *gt)
> */
> void intel_engine_cleanup_common(struct intel_engine_cs *engine)
> {
> - GEM_BUG_ON(!list_empty(>active.requests));
> + GEM_BUG_ON(!list_empty(>sched_engine->requests));
> tasklet_kill(>execlists.tasklet); /* flush the callback */
>
> i915_sched_engine_put(engine->sched_engine);
> @@ -1353,7 +1330,7 @@ static struct intel_timeline *get_timeline(struct
> i915_request *rq)
> struct intel_timeline *tl;
>
> /*
> -* Even though we are holding the engine->active.lock here, there
> +* Even though we are holding the engine->sched_engine->lock here,
> there
> * is no control over the submission queue per-se and we are
> * inspecting the active state at a random point in time, with an
> * unknown queue. Play safe and make sure the timeline remains valid.
> @@ -1700,7 +1677,7 @@ void intel_engine_dump(struct intel_engine_cs *engine,
>
> drm_printf(m, "\tRequests:\n");
>
> - spin_lock_irqsave(>active.lock, flags);
> + spin_lock_irqsave(>sched_engine->lock, flags);
> rq =
Re: [Intel-gfx] [PATCH 3/9] drm/i915: Add i915_sched_engine_reset_on_empty function
On Fri, Jun 04, 2021 at 01:31:42PM -0500, Jason Ekstrand wrote:
> On Thu, Jun 3, 2021 at 4:09 PM Matthew Brost wrote:
> >
> > Rather than touching schedule state in the generic PM code, reset the
> > priolist allocation when empty in the submission code. Add a wrapper
> > function to do this and update the backends to call it in the correct
> > place.
>
> Seems reasonable, I think. I'm by no means an expert but
>
> Reviewed-by: Jason Ekstrand
>
> anyway. My one suggestion would be to tweak the commit message to
> talk about the functional change rather than the helper. Something
> like
>
> drm/i915: Reset sched_engine.no_priolist immediately after dequeue
>
> Typically patches which say "add a helper function" don't come with a
> non-trivial functional change.
>
Agree.
Thanks - Matt
> --Jason
>
>
> > Signed-off-by: Matthew Brost
> > ---
> > drivers/gpu/drm/i915/gt/intel_engine_pm.c| 2 --
> > drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 1 +
> > drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c| 2 ++
> > drivers/gpu/drm/i915/i915_scheduler.h| 7 +++
> > 4 files changed, 10 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > index b6a00dd72808..1f07ac4e0672 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > @@ -280,8 +280,6 @@ static int __engine_park(struct intel_wakeref *wf)
> > if (engine->park)
> > engine->park(engine);
> >
> > - engine->sched_engine->no_priolist = false;
> > -
> > /* While gt calls i915_vma_parked(), we have to break the lock
> > cycle */
> > intel_gt_pm_put_async(engine->gt);
> > return 0;
> > diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > index 2326a73af6d3..609753b5401a 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > @@ -1553,6 +1553,7 @@ static void execlists_dequeue(struct intel_engine_cs
> > *engine)
> > * interrupt for secondary ports).
> > */
> > sched_engine->queue_priority_hint = queue_prio(sched_engine);
> > + i915_sched_engine_reset_on_empty(sched_engine);
> > spin_unlock(>active.lock);
> >
> > /*
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > index 5d00f2e3c1de..f4a6fbfaf82e 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > @@ -263,6 +263,8 @@ static void guc_submission_tasklet(struct
> > tasklet_struct *t)
> >
> > __guc_dequeue(engine);
> >
> > + i915_sched_engine_reset_on_empty(engine->sched_engine);
> > +
> > spin_unlock_irqrestore(>active.lock, flags);
> > }
> >
> > diff --git a/drivers/gpu/drm/i915/i915_scheduler.h
> > b/drivers/gpu/drm/i915/i915_scheduler.h
> > index 5bec7b3b8456..713c38c99de9 100644
> > --- a/drivers/gpu/drm/i915/i915_scheduler.h
> > +++ b/drivers/gpu/drm/i915/i915_scheduler.h
> > @@ -72,6 +72,13 @@ i915_sched_engine_is_empty(struct i915_sched_engine
> > *sched_engine)
> > return RB_EMPTY_ROOT(_engine->queue.rb_root);
> > }
> >
> > +static inline void
> > +i915_sched_engine_reset_on_empty(struct i915_sched_engine *sched_engine)
> > +{
> > + if (i915_sched_engine_is_empty(sched_engine))
> > + sched_engine->no_priolist = false;
> > +}
> > +
> > void i915_request_show_with_schedule(struct drm_printer *m,
> > const struct i915_request *rq,
> > const char *prefix,
> > --
> > 2.28.0
> >
> > ___
> > Intel-gfx mailing list
> > intel-...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Bug 212333] Bisected: 5.11.7 breaks amdgpu resume from S3
https://bugzilla.kernel.org/show_bug.cgi?id=212333 Timo Valtoaho (timo.valto...@gmail.com) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |CODE_FIX --- Comment #4 from Timo Valtoaho (timo.valto...@gmail.com) --- The link above helps. Suspend (S0ix) seems to work fine. Every now and then I need to hard reboot my laptop, I can't find any logic for that. One minor issue left. When ACPI events (charging and battery gets full) occur while suspended, I need to close and reopen the lid on resume if I have suspended using power button. Vanilla kernels 5.12.x work like described with these 6 patches applied: https://gitlab.freedesktop.org/agd5f/linux/-/commits/s0ix-8 -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [bug report] Commit ccf953d8f3d6 ("fb_defio: Remove custom address_space_operations") breaks Hyper-V FB driver
On Fri, Jun 04, 2021 at 06:37:49PM +, Dexuan Cui wrote: > > From: Dexuan Cui > > Sent: Friday, June 4, 2021 11:17 AM > > > >> ... > > > > I've heard a similar report from Vineeth but we didn't get to the bottom > > > > of this. > > > I have just tried reverting the commit mentioned above and it solves the > > > GUI freeze > > > I was also seeing. Previously, login screen was just freezing, but VM > > > was accessible > > > through ssh. With the above commit reverted, I can login to Gnome. > > > > > > Looks like I am also experiencing the same bug mentioned here. > > > > > > Thanks, > > > Vineeth > > > > As Matthew mentioned, this is a known issue: > > https://lwn.net/ml/linux-kernel/ylzehv0cpzp8u...@casper.infradead.org/ > > > > Matthew has reverted ccf953d8f3d6: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id= > > 0b78f8bcf4951af30b0ae83ea4fad27d641ab617 > > so the latest mainline should work now. > > > > Thanks, > > Dexuan > > Hi Matthew, > With today's latest mainline 16f0596fc1d78a1f3ae4628cff962bb297dc908c, > the Xorg works again in Linux VM on Hyper-V, but when I reboot the VM, I > always see a lot of "BUG: Bad page state in process Xorg " warnings (there > are about 60 such warnings) before the VM reboots. > > BTW, I happen to have an older Mar-28 mainline kernel (36a14638f7c0654), > which has the same warnings. > > Any idea which change introduced the warnings? Looks like someone forgot to call fb_deferred_io_cleanup()?
Re: [PATCH 0/9] Enhance pipe color support for multi segmented luts
On 2021-06-01 6:41 a.m., Uma Shankar wrote: > Modern hardwares have multi segmented lut approach to prioritize > the darker regions of the spectrum. This series introduces a new > UAPI to define the lut ranges supported by the respective hardware. > > This also enables Pipe Color Management Support for Intel's XE_LPD hw. > Enable Support for Pipe Degamma with the increased lut samples > supported by hardware. This also adds support for newly introduced > Logarithmic Gamma for XE_LPD. Also added the gamma readout support. > > The Logarithmic gamma implementation on XE_LPD is non linear and adds 25 > segments with non linear lut samples in each segment. The expectation > is userspace will create the luts as per this distribution and pass > the final samples to driver to be programmed in hardware. > Is this design targetting Intel XE_LPD HW in particular or is it intended to be generic? If this is intended to be generic I think it would benefit from a lot more documentation. At this point it's difficult for me to see how to adapt this to AMD HW. It would take me a while to be comfortable to make a call on whether we can use it or not. And what about other vendors? I think we need to be cautious in directly exposing HW functionality through UAPI. The CM parts of AMD HW seem to be changing in some way each generation and it looks like the same is true for Intel. The trouble we have with adapting the old gamma/degamma properties to modern HW is some indication to me that this approach is somewhat problematic. It would be useful to understand and document the specific use-cases we want to provide to userspace implementers with this functionality. Do we want to support modern transfer functions such as PQ or HLG? If so, it might be beneficial to have an API to explicitly specify that, and then use LUT tables in drivers that are optimized for the implementing HW. Or is the use case tone mapping? If so, would a parametric definition of tone mapping be easier to manage? > +-+--+ > | x | 2 pow x segment|No of Entries > | | 0 | 1 | > | 0 | 1 | 1 | > | 1 | 2 | 2 | > | 2 | 4 | 2 | > | 3 | 8 | 2 | > | 4 | 16 | 2 | > | 5 | 32 | 4 | > | 6 | 64 | 4 | > | 7 | 128| 4 | > | 8 | 256| 8 | > | 9 | 512| 8 | > | 10 | 1024 | 8 | > | 11 | 2048 | 16 | > | 12 | 4096 | 16 | > | 13 | 8192 | 16 | > | 14 | 16384 | 32 | > | 15 | 32768 | 32 | > | 16 | 65536 | 64 | > | 17 | 131072 | 64 | > | 18 | 262144 | 64 | > | 19 | 524288 | 32 | > | 20 | 1048576| 32 | > | 21 | 2097152| 32 | > | 22 | 4194304| 32 | > | 23 | 8388608| 32 | > | 24 | 16777216 | 1 | > | | Total Entries | 511| > -+-++ > > Credits: Special mention and credits to Ville Syrjala for coming up > with a design for this feature and inputs. This series is based on > his original design. > > Note: Userspace support for this new UAPI will be done on Chrome and > plan is to get this supported on mutter as well. We will notify the > list once we have that ready for review. > Is this an RFC? If so it would be good to mark it as such. Harry > Uma Shankar (9): > drm: Add gamma mode property > drm/i915/xelpd: Define color lut range structure > drm/i915/xelpd: Add support for Logarithmic gamma mode > drm/i915/xelpd: Attach gamma mode property > drm: Add Client Cap for advance gamma mode > drm/i915/xelpd: logarithmic gamma enabled only with advance gamma mode > drm/i915/xelpd: Enable Pipe Degamma > drm/i915/xelpd: Add Pipe Color Lut caps to platform config > drm/i915/xelpd: Enable XE_LPD Gamma Lut readout > > drivers/gpu/drm/drm_atomic_uapi.c | 8 + > drivers/gpu/drm/drm_color_mgmt.c | 75 > drivers/gpu/drm/drm_ioctl.c| 5 + > drivers/gpu/drm/i915/display/intel_color.c | 454 - > drivers/gpu/drm/i915/i915_pci.c| 3 +- > drivers/gpu/drm/i915/i915_reg.h| 7 + > include/drm/drm_atomic.h | 1 + > include/drm/drm_color_mgmt.h | 8 + > include/drm/drm_crtc.h | 25 ++ > include/drm/drm_file.h | 8 + > include/uapi/drm/drm.h | 8 + > include/uapi/drm/drm_mode.h| 43 ++ > 12 files changed, 630 insertions(+), 15 deletions(-) >
Re: [Intel-gfx] [PATCH 13/20] drm/i915/guc: Relax CTB response timeout
On Fri, Jun 04, 2021 at 10:33:07AM +0200, Daniel Vetter wrote:
> On Wed, Jun 02, 2021 at 10:16:23PM -0700, Matthew Brost wrote:
> > From: Michal Wajdeczko
> >
> > In upcoming patch we will allow more CTB requests to be sent in
> > parallel to the GuC for processing, so we shouldn't assume any more
> > that GuC will always reply without 10ms.
> >
> > Use bigger value from CONFIG_DRM_I915_GUC_CTB_TIMEOUT instead.
> >
> > v2: Add CONFIG_DRM_I915_GUC_CTB_TIMEOUT config option
> >
> > Signed-off-by: Michal Wajdeczko
> > Signed-off-by: Matthew Brost
> > Reviewed-by: Matthew Brost
>
> So this is a rant, but for upstream we really need to do better than
> internal:
>
> - The driver must work by default in the optimal configuration.
>
> - Any config change that we haven't validated _must_ taint the kernel
> (this is especially for module options, but also for config settings)
>
> - Config need a real reason beyond "was useful for bring-up".
>
> Our internal tree is an absolute disaster right now, with multi-line
> kernel configs (different on each platform) and bespoke kernel config or
> the driver just fails. We're the expert on our own hw, we should know how
> it works, not offload that to users essentially asking them "how shitty do
> you think Intel hw is in responding timely".
>
> Yes I know there's a lot of these there already, they don't make a lot of
> sense either.
>
> Except if there's a real reason for this (aside from us just offloading
> testing to our users instead of doing it ourselves properly) I think we
> should hardcode this, with a comment explaining why. Maybe with a switch
> between the PF/VF case once that's landed.
>
> > ---
> > drivers/gpu/drm/i915/Kconfig.profile | 10 ++
> > drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 5 -
> > 2 files changed, 14 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/Kconfig.profile
> > b/drivers/gpu/drm/i915/Kconfig.profile
> > index 39328567c200..0d5475b5f28a 100644
> > --- a/drivers/gpu/drm/i915/Kconfig.profile
> > +++ b/drivers/gpu/drm/i915/Kconfig.profile
> > @@ -38,6 +38,16 @@ config DRM_I915_USERFAULT_AUTOSUSPEND
> > May be 0 to disable the extra delay and solely use the device level
> > runtime pm autosuspend delay tunable.
> >
> > +config DRM_I915_GUC_CTB_TIMEOUT
> > + int "How long to wait for the GuC to make forward progress on CTBs (ms)"
> > + default 1500 # milliseconds
> > + range 10 6
>
> Also range is definitely off, drm/scheduler will probably nuke you
> beforehand :-)
>
> That's kinda another issue I have with all these kconfig knobs: Maybe we
> need a knob for "relax with reset attempts, my workloads overload my gpus
> routinely", which then scales _all_ timeouts proportionally. But letting
> the user set them all, with silly combiniations like resetting the
> workload before heartbeat or stuff like that doesn't make much sense.
>
Yes, the code as is the user could do some wacky stuff that doesn't make
sense at all.
> Anyway, tiny patch so hopefully I can leave this one out for now until
> we've closed this.
No issue leaving this out as blocking CTBs are never really used anyways
until SRIOV aside from setup / debugging. That being said, we might
still want a higher hardcoded value in the meantime, perhaps around a
second. I can follow up on that if needed.
Matt
> -Daniel
>
> > + help
> > + Configures the default timeout waiting for GuC the to make forward
> > + progress on CTBs. e.g. Waiting for a response to a requeset.
> > +
> > + A range of 10 ms to 6 ms is allowed.
> > +
> > config DRM_I915_HEARTBEAT_INTERVAL
> > int "Interval between heartbeat pulses (ms)"
> > default 2500 # milliseconds
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > index 916c2b80c841..cf1fb09ef766 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > @@ -436,6 +436,7 @@ static int ct_write(struct intel_guc_ct *ct,
> > */
> > static int wait_for_ct_request_update(struct ct_request *req, u32 *status)
> > {
> > + long timeout;
> > int err;
> >
> > /*
> > @@ -443,10 +444,12 @@ static int wait_for_ct_request_update(struct
> > ct_request *req, u32 *status)
> > * up to that length of time, then switch to a slower sleep-wait loop.
> > * No GuC command should ever take longer than 10ms.
> > */
> > + timeout = CONFIG_DRM_I915_GUC_CTB_TIMEOUT;
> > +
> > #define done INTEL_GUC_MSG_IS_RESPONSE(READ_ONCE(req->status))
> > err = wait_for_us(done, 10);
> > if (err)
> > - err = wait_for(done, 10);
> > + err = wait_for(done, timeout);
> > #undef done
> >
> > if (unlikely(err))
> > --
> > 2.28.0
> >
> > ___
> > Intel-gfx mailing list
> > intel-...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/9] drm/i915: Add i915_sched_engine_reset_on_empty function
On Thu, Jun 3, 2021 at 4:09 PM Matthew Brost wrote:
>
> Rather than touching schedule state in the generic PM code, reset the
> priolist allocation when empty in the submission code. Add a wrapper
> function to do this and update the backends to call it in the correct
> place.
Seems reasonable, I think. I'm by no means an expert but
Reviewed-by: Jason Ekstrand
anyway. My one suggestion would be to tweak the commit message to
talk about the functional change rather than the helper. Something
like
drm/i915: Reset sched_engine.no_priolist immediately after dequeue
Typically patches which say "add a helper function" don't come with a
non-trivial functional change.
--Jason
> Signed-off-by: Matthew Brost
> ---
> drivers/gpu/drm/i915/gt/intel_engine_pm.c| 2 --
> drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 1 +
> drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c| 2 ++
> drivers/gpu/drm/i915/i915_scheduler.h| 7 +++
> 4 files changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> index b6a00dd72808..1f07ac4e0672 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> @@ -280,8 +280,6 @@ static int __engine_park(struct intel_wakeref *wf)
> if (engine->park)
> engine->park(engine);
>
> - engine->sched_engine->no_priolist = false;
> -
> /* While gt calls i915_vma_parked(), we have to break the lock cycle
> */
> intel_gt_pm_put_async(engine->gt);
> return 0;
> diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> index 2326a73af6d3..609753b5401a 100644
> --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> @@ -1553,6 +1553,7 @@ static void execlists_dequeue(struct intel_engine_cs
> *engine)
> * interrupt for secondary ports).
> */
> sched_engine->queue_priority_hint = queue_prio(sched_engine);
> + i915_sched_engine_reset_on_empty(sched_engine);
> spin_unlock(>active.lock);
>
> /*
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> index 5d00f2e3c1de..f4a6fbfaf82e 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> @@ -263,6 +263,8 @@ static void guc_submission_tasklet(struct tasklet_struct
> *t)
>
> __guc_dequeue(engine);
>
> + i915_sched_engine_reset_on_empty(engine->sched_engine);
> +
> spin_unlock_irqrestore(>active.lock, flags);
> }
>
> diff --git a/drivers/gpu/drm/i915/i915_scheduler.h
> b/drivers/gpu/drm/i915/i915_scheduler.h
> index 5bec7b3b8456..713c38c99de9 100644
> --- a/drivers/gpu/drm/i915/i915_scheduler.h
> +++ b/drivers/gpu/drm/i915/i915_scheduler.h
> @@ -72,6 +72,13 @@ i915_sched_engine_is_empty(struct i915_sched_engine
> *sched_engine)
> return RB_EMPTY_ROOT(_engine->queue.rb_root);
> }
>
> +static inline void
> +i915_sched_engine_reset_on_empty(struct i915_sched_engine *sched_engine)
> +{
> + if (i915_sched_engine_is_empty(sched_engine))
> + sched_engine->no_priolist = false;
> +}
> +
> void i915_request_show_with_schedule(struct drm_printer *m,
> const struct i915_request *rq,
> const char *prefix,
> --
> 2.28.0
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [PATCH 02/21] drm: Add Plane Degamma Mode property
On 2021-06-01 6:51 a.m., Uma Shankar wrote:
> Add Plane Degamma Mode as an enum property. Create a helper
> function for all plane color management features.
>
> This is an enum property with values as blob_id's and exposes
> the various gamma modes supported and the lut ranges. Getting
> the blob id in userspace, user can get the mode supported and
> also the range of gamma mode supported with number of lut
> coefficients. It can then set one of the modes using this
> enum property.
>
> Lut values will be sent through separate GAMMA_LUT blob property.
>
> Signed-off-by: Uma Shankar
> ---
> Documentation/gpu/drm-kms.rst | 90 ++
> drivers/gpu/drm/drm_atomic.c | 1 +
> drivers/gpu/drm/drm_atomic_state_helper.c | 2 +
> drivers/gpu/drm/drm_atomic_uapi.c | 4 +
> drivers/gpu/drm/drm_color_mgmt.c | 93 ++-
> include/drm/drm_mode_object.h | 2 +-
> include/drm/drm_plane.h | 23 ++
> 7 files changed, 212 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> index 87e5023e3f55..752be545e7d7 100644
> --- a/Documentation/gpu/drm-kms.rst
> +++ b/Documentation/gpu/drm-kms.rst
> @@ -514,9 +514,99 @@ Damage Tracking Properties
> Color Management Properties
> ---
>
> +Below is how a typical hardware pipeline for color
> +will look like:
> +
> +.. kernel-render:: DOT
> + :alt: Display Color Pipeline
> + :caption: Display Color Pipeline Overview
> +
> + digraph "KMS" {
> + node [shape=box]
> +
> + subgraph cluster_static {
> + style=dashed
> + label="Display Color Hardware Blocks"
> +
> + node [bgcolor=grey style=filled]
> + "Plane Degamma A" -> "Plane CSC/CTM A"
> + "Plane CSC/CTM A" -> "Plane Gamma A"
> + "Pipe Blender" [color=lightblue,style=filled, width=5.25,
> height=0.75];
> + "Plane Gamma A" -> "Pipe Blender"
> + "Pipe Blender" -> "Pipe DeGamma"
> + "Pipe DeGamma" -> "Pipe CSC/CTM"
> + "Pipe CSC/CTM" -> "Pipe Gamma"
> + "Pipe Gamma" -> "Pipe Output"
> + }
> +
It might be worthwhile to also highlight the YCbCr coefficient matrix in the
pipeline,
between the FB and Plane degamma, i.e.
YCbCr coefficients > plane degamma > csc > ...
One problem with this view is that not all HW will support all (or any) of these
CM blocks on all planes. For example, on AMD HW cursors are very different from
other planes and don't really have full CM support.
> + subgraph cluster_static {
> + style=dashed
> +
> + node [shape=box]
> + "Plane Degamma B" -> "Plane CSC/CTM B"
> + "Plane CSC/CTM B" -> "Plane Gamma B"
> + "Plane Gamma B" -> "Pipe Blender"
> + }
> +
> + subgraph cluster_static {
> + style=dashed
> +
> + node [shape=box]
> + "Plane Degamma C" -> "Plane CSC/CTM C"
> + "Plane CSC/CTM C" -> "Plane Gamma C"
> + "Plane Gamma C" -> "Pipe Blender"
> + }
> +
> + subgraph cluster_fb {
> + style=dashed
> + label="RAM"
> +
> + node [shape=box width=1.7 height=0.2]
> +
> + "FB 1" -> "Plane Degamma A"
> + "FB 2" -> "Plane Degamma B"
> + "FB 3" -> "Plane Degamma C"
> + }
> + }
> +
> +In real world usecases,
> +
> +1. Plane Degamma can be used to linearize a non linear gamma
> +encoded framebuffer. This is needed to do any linear math like
> +color space conversion. For ex, linearize frames encoded in SRGB
> +or by HDR curve.
> +
> +2. Later Plane CTM block can convert the content to some different
> +colorspace. For ex, SRGB to BT2020 etc.
> +
> +3. Plane Gamma block can be used later to re-apply the non-linear
> +curve. This can also be used to apply Tone Mapping for HDR usecases.
> +
This would mean you're blending in gamma space which is likely not what
most compositors expect. There are numerous articles that describe why
blending in gamma space is problematic, such as [1]
[1] https://ninedegreesbelow.com/photography/linear-gamma-blur-normal-blend.html
To blend in linear space this should be configured to do
Plane Degamma > Plane CTM > CRTC Gamma
I think it would also be good if we moved away from calling this gamma. It's
really only gamma for legacy SDR scenarios. For HDR cases I would never expect
these to use gamma and even though the sRGB transfer function is based on gamma
functions it's complicated [2].
[2] https://en.wikipedia.org/wiki/SRGB
A better way to describe these would be as "transfer function" and "inverse
transfer function." The space at various stages could then be described as
linear
or non-linear, specifically PQ, HLG, sRGB, BT709, or using another transfer
function.
Harry
> +All the layers or framebuffers need to be converted to same color
> +space and format before blending. The plane color hardware
Re: [PATCH 20/20] drm/i915/guc: Use guc_class instead of engine_class in fw interface
On Fri, Jun 04, 2021 at 10:44:31AM +0200, Daniel Vetter wrote:
> On Wed, Jun 02, 2021 at 10:16:30PM -0700, Matthew Brost wrote:
> > From: Daniele Ceraolo Spurio
> >
> > GuC has its own defines for the engine classes. They're currently
> > mapping 1:1 to the defines used by the driver, but there is no guarantee
> > this will continue in the future. Given that we've been caught off-guard
> > in the past by similar divergences, we can prepare for the changes by
> > introducing helper functions to convert from engine class to GuC class and
> > back again.
> >
> > Signed-off-by: Daniele Ceraolo Spurio
> > Signed-off-by: Matthew Brost
> > Reviewed-by: Matthew Brost
> > Cc: John Harrison
> > Cc: Michal Wajdeczko
>
> Applied all up to this, except the Kconfig one.
>
Thanks, that one isn't really a blocker to next post which will update
the GuC firmware to the latest and greatest version.
Let me look at the issue with that patch now.
Matt
> Thanks, Daniel
>
> > ---
> > drivers/gpu/drm/i915/gt/intel_engine_cs.c | 6 +++--
> > drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 20 +---
> > drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 26 +
> > 3 files changed, 42 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > index 3f9a811eb02b..69281b5aba51 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > @@ -265,6 +265,7 @@ static int intel_engine_setup(struct intel_gt *gt, enum
> > intel_engine_id id)
> > const struct engine_info *info = _engines[id];
> > struct drm_i915_private *i915 = gt->i915;
> > struct intel_engine_cs *engine;
> > + u8 guc_class;
> >
> > BUILD_BUG_ON(MAX_ENGINE_CLASS >= BIT(GEN11_ENGINE_CLASS_WIDTH));
> > BUILD_BUG_ON(MAX_ENGINE_INSTANCE >= BIT(GEN11_ENGINE_INSTANCE_WIDTH));
> > @@ -293,9 +294,10 @@ static int intel_engine_setup(struct intel_gt *gt,
> > enum intel_engine_id id)
> > engine->i915 = i915;
> > engine->gt = gt;
> > engine->uncore = gt->uncore;
> > - engine->mmio_base = __engine_mmio_base(i915, info->mmio_bases);
> > engine->hw_id = info->hw_id;
> > - engine->guc_id = MAKE_GUC_ID(info->class, info->instance);
> > + guc_class = engine_class_to_guc_class(info->class);
> > + engine->guc_id = MAKE_GUC_ID(guc_class, info->instance);
> > + engine->mmio_base = __engine_mmio_base(i915, info->mmio_bases);
> >
> > engine->irq_handler = nop_irq_handler;
> >
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> > index 17526717368c..efdce309b6f1 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> > @@ -6,6 +6,7 @@
> > #include "gt/intel_gt.h"
> > #include "gt/intel_lrc.h"
> > #include "intel_guc_ads.h"
> > +#include "intel_guc_fwif.h"
> > #include "intel_uc.h"
> > #include "i915_drv.h"
> >
> > @@ -104,7 +105,7 @@ static void guc_mapping_table_init(struct intel_gt *gt,
> > GUC_MAX_INSTANCES_PER_CLASS;
> >
> > for_each_engine(engine, gt, id) {
> > - u8 guc_class = engine->class;
> > + u8 guc_class = engine_class_to_guc_class(engine->class);
> >
> > system_info->mapping_table[guc_class][engine->instance] =
> > engine->instance;
> > @@ -124,7 +125,7 @@ static void __guc_ads_init(struct intel_guc *guc)
> > struct __guc_ads_blob *blob = guc->ads_blob;
> > const u32 skipped_size = LRC_PPHWSP_SZ * PAGE_SIZE + LR_HW_CONTEXT_SIZE;
> > u32 base;
> > - u8 engine_class;
> > + u8 engine_class, guc_class;
> >
> > /* GuC scheduling policies */
> > guc_policies_init(>policies);
> > @@ -140,22 +141,25 @@ static void __guc_ads_init(struct intel_guc *guc)
> > for (engine_class = 0; engine_class <= MAX_ENGINE_CLASS;
> > ++engine_class) {
> > if (engine_class == OTHER_CLASS)
> > continue;
> > +
> > + guc_class = engine_class_to_guc_class(engine_class);
> > +
> > /*
> > * TODO: Set context pointer to default state to allow
> > * GuC to re-init guilty contexts after internal reset.
> > */
> > - blob->ads.golden_context_lrca[engine_class] = 0;
> > - blob->ads.eng_state_size[engine_class] =
> > + blob->ads.golden_context_lrca[guc_class] = 0;
> > + blob->ads.eng_state_size[guc_class] =
> > intel_engine_context_size(guc_to_gt(guc),
> > engine_class) -
> > skipped_size;
> > }
> >
> > /* System info */
> > - blob->system_info.engine_enabled_masks[RENDER_CLASS] = 1;
> > - blob->system_info.engine_enabled_masks[COPY_ENGINE_CLASS] = 1;
> > - blob->system_info.engine_enabled_masks[VIDEO_DECODE_CLASS]
Re: [PATCH 1/9] drm/i915: Move priolist to new i915_sched_engine object
On Fri, Jun 4, 2021 at 12:59 PM Matthew Brost wrote:
>
> On Fri, Jun 04, 2021 at 12:51:43PM -0500, Jason Ekstrand wrote:
> > On Fri, Jun 4, 2021 at 12:42 PM Matthew Brost
> > wrote:
> > >
> > > On Fri, Jun 04, 2021 at 12:38:22PM -0500, Jason Ekstrand wrote:
> > > > On Thu, Jun 3, 2021 at 4:09 PM Matthew Brost
> > > > wrote:
> > > > >
> > > > > Introduce i915_sched_engine object which is lower level data structure
> > > > > that i915_scheduler / generic code can operate on without touching
> > > > > execlist specific structures. This allows additional submission
> > > > > backends
> > > > > to be added without breaking the layering.
> > > > >
> > > > > This is a bit of detour to integrating the i915 with the DRM scheduler
> > > > > but this object will still exist when the DRM scheduler lands in the
> > > > > i915. It will however look a bit different. It will encapsulate the
> > > > > drm_gpu_scheduler object plus and common variables (to the backends)
> > > > > related to scheduling. Regardless this is a step in the right
> > > > > direction.
> > > > >
> > > > > This patch starts the aforementioned transition by moving the the
> > > > > priolist into the i915_sched_engine object.
> > > > >
> > > > > Signed-off-by: Matthew Brost
> > > > > ---
> > > > > drivers/gpu/drm/i915/gt/intel_engine_cs.c | 14 +++-
> > > > > drivers/gpu/drm/i915/gt/intel_engine_pm.c | 4 +-
> > > > > drivers/gpu/drm/i915/gt/intel_engine_types.h | 30 +--
> > > > > .../drm/i915/gt/intel_execlists_submission.c | 81
> > > > > +++
> > > > > drivers/gpu/drm/i915/gt/mock_engine.c | 9 ++-
> > > > > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 19 ++---
> > > > > drivers/gpu/drm/i915/i915_scheduler.c | 51 +---
> > > > > drivers/gpu/drm/i915/i915_scheduler.h | 18 +
> > > > > drivers/gpu/drm/i915/i915_scheduler_types.h | 33
> > > > > 9 files changed, 169 insertions(+), 90 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > > > > b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > > > > index 3f9a811eb02b..d0f3814440f6 100644
> > > > > --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > > > > +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > > > > @@ -583,9 +583,6 @@ void intel_engine_init_execlists(struct
> > > > > intel_engine_cs *engine)
> > > > > memset(execlists->pending, 0, sizeof(execlists->pending));
> > > > > execlists->active =
> > > > > memset(execlists->inflight, 0,
> > > > > sizeof(execlists->inflight));
> > > > > -
> > > > > - execlists->queue_priority_hint = INT_MIN;
> > > > > - execlists->queue = RB_ROOT_CACHED;
> > > > > }
> > > > >
> > > > > static void cleanup_status_page(struct intel_engine_cs *engine)
> > > > > @@ -712,6 +709,12 @@ static int engine_setup_common(struct
> > > > > intel_engine_cs *engine)
> > > > > goto err_status;
> > > > > }
> > > > >
> > > > > + engine->sched_engine =
> > > > > i915_sched_engine_create(ENGINE_PHYSICAL);
> > > > > + if (!engine->sched_engine) {
> > > > > + err = -ENOMEM;
> > > > > + goto err_sched_engine;
> > > > > + }
> > > > > +
> > > > > err = intel_engine_init_cmd_parser(engine);
> > > > > if (err)
> > > > > goto err_cmd_parser;
> > > > > @@ -735,6 +738,8 @@ static int engine_setup_common(struct
> > > > > intel_engine_cs *engine)
> > > > > return 0;
> > > > >
> > > > > err_cmd_parser:
> > > > > + i915_sched_engine_put(engine->sched_engine);
> > > > > +err_sched_engine:
> > > > > intel_breadcrumbs_free(engine->breadcrumbs);
> > > > > err_status:
> > > > > cleanup_status_page(engine);
> > > > > @@ -958,6 +963,7 @@ void intel_engine_cleanup_common(struct
> > > > > intel_engine_cs *engine)
> > > > > GEM_BUG_ON(!list_empty(>active.requests));
> > > > > tasklet_kill(>execlists.tasklet); /* flush the
> > > > > callback */
> > > > >
> > > > > + i915_sched_engine_put(engine->sched_engine);
> > > > > intel_breadcrumbs_free(engine->breadcrumbs);
> > > > >
> > > > > intel_engine_fini_retire(engine);
> > > > > @@ -1281,7 +1287,7 @@ bool intel_engine_is_idle(struct
> > > > > intel_engine_cs *engine)
> > > > > intel_engine_flush_submission(engine);
> > > > >
> > > > > /* ELSP is empty, but there are ready requests? E.g. after
> > > > > reset */
> > > > > - if (!RB_EMPTY_ROOT(>execlists.queue.rb_root))
> > > > > + if (!RB_EMPTY_ROOT(>sched_engine->queue.rb_root))
> > > > > return false;
> > > > >
> > > > > /* Ring stopped? */
> > > > > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > > > > b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > > > > index 47f4397095e5..b6a00dd72808 100644
> > > > > --- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > > > > +++
Re: [Intel-gfx] [RFC PATCH 64/97] drm/i915/guc: Reset implementation for new GuC interface
On Fri, Jun 04, 2021 at 10:16:14AM +0200, Daniel Vetter wrote:
> On Fri, Jun 4, 2021 at 5:25 AM Matthew Brost wrote:
> >
> > On Wed, Jun 02, 2021 at 03:33:43PM +0100, Tvrtko Ursulin wrote:
> > >
> > > On 06/05/2021 20:14, Matthew Brost wrote:
> > > > Reset implementation for new GuC interface. This is the legacy reset
> > > > implementation which is called when the i915 owns the engine hang check.
> > > > Future patches will offload the engine hang check to GuC but we will
> > > > continue to maintain this legacy path as a fallback and this code path
> > > > is also required if the GuC dies.
> > > >
> > > > With the new GuC interface it is not possible to reset individual
> > > > engines - it is only possible to reset the GPU entirely. This patch
> > > > forces an entire chip reset if any engine hangs.
> > > >
> > > > Cc: John Harrison
> > > > Signed-off-by: Matthew Brost
> > > > ---
> > > > drivers/gpu/drm/i915/gt/intel_context.c | 3 +
> > > > drivers/gpu/drm/i915/gt/intel_context_types.h | 7 +
> > > > drivers/gpu/drm/i915/gt/intel_engine_types.h | 6 +
> > > > .../drm/i915/gt/intel_execlists_submission.c | 40 ++
> > > > drivers/gpu/drm/i915/gt/intel_gt_pm.c | 6 +-
> > > > drivers/gpu/drm/i915/gt/intel_reset.c | 18 +-
> > > > .../gpu/drm/i915/gt/intel_ring_submission.c | 22 +
> > > > drivers/gpu/drm/i915/gt/mock_engine.c | 31 +
> > > > drivers/gpu/drm/i915/gt/uc/intel_guc.c| 16 +-
> > > > drivers/gpu/drm/i915/gt/uc/intel_guc.h| 8 +-
> > > > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 580 ++
> > > > drivers/gpu/drm/i915/gt/uc/intel_uc.c | 34 +-
> > > > drivers/gpu/drm/i915/gt/uc/intel_uc.h | 3 +
> > > > drivers/gpu/drm/i915/i915_request.c | 41 +-
> > > > drivers/gpu/drm/i915/i915_request.h | 2 +
> > > > 15 files changed, 643 insertions(+), 174 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
> > > > b/drivers/gpu/drm/i915/gt/intel_context.c
> > > > index b24a1b7a3f88..2f01437056a8 100644
> > > > --- a/drivers/gpu/drm/i915/gt/intel_context.c
> > > > +++ b/drivers/gpu/drm/i915/gt/intel_context.c
> > > > @@ -392,6 +392,9 @@ intel_context_init(struct intel_context *ce, struct
> > > > intel_engine_cs *engine)
> > > > spin_lock_init(>guc_state.lock);
> > > > INIT_LIST_HEAD(>guc_state.fences);
> > > > + spin_lock_init(>guc_active.lock);
> > > > + INIT_LIST_HEAD(>guc_active.requests);
> > > > +
> > > > ce->guc_id = GUC_INVALID_LRC_ID;
> > > > INIT_LIST_HEAD(>guc_id_link);
> > > > diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
> > > > b/drivers/gpu/drm/i915/gt/intel_context_types.h
> > > > index 6945963a31ba..b63c8cf7823b 100644
> > > > --- a/drivers/gpu/drm/i915/gt/intel_context_types.h
> > > > +++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
> > > > @@ -165,6 +165,13 @@ struct intel_context {
> > > > struct list_head fences;
> > > > } guc_state;
> > > > + struct {
> > > > + /** lock: protects everything in guc_active */
> > > > + spinlock_t lock;
> > > > + /** requests: active requests on this context */
> > > > + struct list_head requests;
> > > > + } guc_active;
> > >
> > > More accounting, yeah, this is more of that where GuC gives with one hand
> > > and takes away with the other. :(
> > >
> >
> > Yep but we probably can drop this once we switch to the DRM scheduler.
> > The drm_gpu_scheduler has a list of jobs and if don't mind searching the
> > whole thing on a reset that will probably work too. I think the only
> > reason we have a per context list is because of feedback I received a
> > a while go saying resets are per context with GuC so keep a list on the
> > context and engine list didn't really fit either. I'll make a to circle
> > back to this when we hook into the DRM scheduler.
>
> Please add a FIXME or similar to the kerneldoc comment for stuff like
> this. We have a lot of things to recheck once the big picture is
> sorted, and it's easy to forget them.
>
Sure, will do in next rev. But I think a lot things like this will come
naturally when we switch over to the DRM scheduler. I didn't quite get
to deleting this list the in my PoC but could clearly see this was no
longer needed and actually have a TODO in the code to delete this.
Matt
> Similar for anything else where we have opens about how to structure
> things once it's cut over.
> -Daniel
>
> >
> > > > +
> > > > /* GuC scheduling state that does not require a lock. */
> > > > atomic_t guc_sched_state_no_lock;
> > > > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> > > > b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> > > > index f7b6eed586ce..b84562b2708b 100644
> > > > --- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> > > > +++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> > > > @@ -432,6 +432,12 @@ struct
Re: [Intel-gfx] [RFC PATCH 2/2] drm/doc/rfc: i915 new parallel submission uAPI plan
On Wed, May 26, 2021 at 04:33:57PM -0700, Matthew Brost wrote:
> Add entry for i915 new parallel submission uAPI plan.
>
> v2:
> (Daniel Vetter):
> - Expand logical order explaination
> - Add dummy header
> - Only allow N BBs in execbuf IOCTL
> - Configure parallel submission per slot not per gem context
> v3:
> (Marcin Ślusarz):
> - Lot's of typos / bad english fixed
> (Tvrtko Ursulin):
> - Consistent pseudo code, clean up wording in descriptions
>
> Cc: Tvrtko Ursulin
> Cc: Tony Ye
> CC: Carl Zhang
> Cc: Daniel Vetter
> Cc: Jason Ekstrand
> Signed-off-by: Matthew Brost
> ---
> Documentation/gpu/rfc/i915_parallel_execbuf.h | 145 ++
> Documentation/gpu/rfc/i915_scheduler.rst | 55 ++-
> 2 files changed, 198 insertions(+), 2 deletions(-)
> create mode 100644 Documentation/gpu/rfc/i915_parallel_execbuf.h
>
> diff --git a/Documentation/gpu/rfc/i915_parallel_execbuf.h
> b/Documentation/gpu/rfc/i915_parallel_execbuf.h
> new file mode 100644
> index ..20de206e3ab4
> --- /dev/null
> +++ b/Documentation/gpu/rfc/i915_parallel_execbuf.h
> @@ -0,0 +1,145 @@
> +#define I915_CONTEXT_ENGINES_EXT_PARALLEL_SUBMIT 2 /* see
> i915_context_engines_parallel_submit */
> +
> +/*
> + * i915_context_engines_parallel_submit:
So the idea is to make these kerneldoc and pull them into the rfc section.
Then when we merge, move them to the real uapi section, like what Matt has
done for lmem.
> + *
> + * Setup a slot in the context engine map to allow multiple BBs to be
> submitted
> + * in a single execbuf IOCTL. Those BBs will then be scheduled to run on the
> GPU
> + * in parallel. Multiple hardware contexts are created internally in the i915
> + * run these BBs. Once a slot is configured for N BBs only N BBs can be
> + * submitted in each execbuf IOCTL and this is implicit behavior e.g. The
> user
> + * doesn't tell the execbuf IOCTL there are N BBs, the execbuf IOCTL know how
> + * many BBs there are based on the slots configuration. The N BBs are the
> last N
> + * buffer objects for first N if I915_EXEC_BATCH_FIRST is set.
s/for/or/
> + *
> + * There are two currently defined ways to control the placement of the
> + * hardware contexts on physical engines: default behavior (no flags) and
> + * I915_PARALLEL_IMPLICIT_BONDS (a flag). More flags may be added the in the
> + * future as new hardware / use cases arise. Details of how to use this
> + * interface above the flags field in this structure.
> + *
> + * Returns -EINVAL if hardware context placement configuration is invalid or
> if
> + * the placement configuration isn't supported on the platform / submission
> + * interface.
> + * Returns -ENODEV if extension isn't supported on the platform / submission
> + * inteface.
> + */
> +struct i915_context_engines_parallel_submit {
> + struct i915_user_extension base;
> +
> + __u16 engine_index; /* slot for parallel engine */
Kernel doc here for the inline comments too.
> + __u16 width;/* number of contexts per parallel engine */
> + __u16 num_siblings; /* number of siblings per context */
> + __u16 mbz16;
> +/*
> + * Default placement behavior (currently unsupported):
> + *
> + * Allow BBs to be placed on any available engine instance. In this case each
> + * context's engine mask indicates where that context can be placed. It is
> + * implied in this mode that all contexts have mutual exclusive placement.
> + * e.g. If one context is running CSX[0] no other contexts can run on
> CSX[0]).
> + *
> + * Example 1 pseudo code:
> + * CSX,Y[N] = generic engine class X or Y, logical instance N
> + * INVALID = I915_ENGINE_CLASS_INVALID, I915_ENGINE_CLASS_INVALID_NONE
> + * set_engines(INVALID)
> + * set_parallel(engine_index=0, width=2, num_siblings=2,
> + * engines=CSX[0],CSX[1],CSY[0],CSY[1])
> + *
> + * Results in the following valid placements:
> + * CSX[0], CSY[0]
> + * CSX[0], CSY[1]
> + * CSX[1], CSY[0]
> + * CSX[1], CSY[1]
> + *
> + * This can also be thought of as 2 virtual engines described by 2-D array in
> + * the engines the field:
> + * VE[0] = CSX[0], CSX[1]
> + * VE[1] = CSY[0], CSY[1]
> + *
> + * Example 2 pseudo code:
> + * CSX[Y] = generic engine of same class X, logical instance N
> + * INVALID = I915_ENGINE_CLASS_INVALID, I915_ENGINE_CLASS_INVALID_NONE
> + * set_engines(INVALID)
> + * set_parallel(engine_index=0, width=2, num_siblings=3,
> + * engines=CSX[0],CSX[1],CSX[2],CSX[0],CSX[1],CSX[2])
> + *
> + * Results in the following valid placements:
> + * CSX[0], CSX[1]
> + * CSX[0], CSX[2]
> + * CSX[1], CSX[0]
> + * CSX[1], CSX[2]
> + * CSX[2], CSX[0]
> + * CSX[2], CSX[1]
> + *
> + * This can also be thought of as 2 virtual engines described by 2-D array in
> + * the engines the field:
> + * VE[0] = CSX[0], CSX[1], CSX[2]
> + * VE[1] = CSX[0], CSX[1], CSX[2]
> +
> + * This enables a use case where all engines are created equally, we don't
> care
> + * where they are scheduled, we
Re: [PATCH 1/9] drm/i915: Move priolist to new i915_sched_engine object
On Fri, Jun 04, 2021 at 12:51:43PM -0500, Jason Ekstrand wrote:
> On Fri, Jun 4, 2021 at 12:42 PM Matthew Brost wrote:
> >
> > On Fri, Jun 04, 2021 at 12:38:22PM -0500, Jason Ekstrand wrote:
> > > On Thu, Jun 3, 2021 at 4:09 PM Matthew Brost
> > > wrote:
> > > >
> > > > Introduce i915_sched_engine object which is lower level data structure
> > > > that i915_scheduler / generic code can operate on without touching
> > > > execlist specific structures. This allows additional submission backends
> > > > to be added without breaking the layering.
> > > >
> > > > This is a bit of detour to integrating the i915 with the DRM scheduler
> > > > but this object will still exist when the DRM scheduler lands in the
> > > > i915. It will however look a bit different. It will encapsulate the
> > > > drm_gpu_scheduler object plus and common variables (to the backends)
> > > > related to scheduling. Regardless this is a step in the right direction.
> > > >
> > > > This patch starts the aforementioned transition by moving the the
> > > > priolist into the i915_sched_engine object.
> > > >
> > > > Signed-off-by: Matthew Brost
> > > > ---
> > > > drivers/gpu/drm/i915/gt/intel_engine_cs.c | 14 +++-
> > > > drivers/gpu/drm/i915/gt/intel_engine_pm.c | 4 +-
> > > > drivers/gpu/drm/i915/gt/intel_engine_types.h | 30 +--
> > > > .../drm/i915/gt/intel_execlists_submission.c | 81 +++
> > > > drivers/gpu/drm/i915/gt/mock_engine.c | 9 ++-
> > > > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 19 ++---
> > > > drivers/gpu/drm/i915/i915_scheduler.c | 51 +---
> > > > drivers/gpu/drm/i915/i915_scheduler.h | 18 +
> > > > drivers/gpu/drm/i915/i915_scheduler_types.h | 33
> > > > 9 files changed, 169 insertions(+), 90 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > > > b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > > > index 3f9a811eb02b..d0f3814440f6 100644
> > > > --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > > > +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > > > @@ -583,9 +583,6 @@ void intel_engine_init_execlists(struct
> > > > intel_engine_cs *engine)
> > > > memset(execlists->pending, 0, sizeof(execlists->pending));
> > > > execlists->active =
> > > > memset(execlists->inflight, 0,
> > > > sizeof(execlists->inflight));
> > > > -
> > > > - execlists->queue_priority_hint = INT_MIN;
> > > > - execlists->queue = RB_ROOT_CACHED;
> > > > }
> > > >
> > > > static void cleanup_status_page(struct intel_engine_cs *engine)
> > > > @@ -712,6 +709,12 @@ static int engine_setup_common(struct
> > > > intel_engine_cs *engine)
> > > > goto err_status;
> > > > }
> > > >
> > > > + engine->sched_engine =
> > > > i915_sched_engine_create(ENGINE_PHYSICAL);
> > > > + if (!engine->sched_engine) {
> > > > + err = -ENOMEM;
> > > > + goto err_sched_engine;
> > > > + }
> > > > +
> > > > err = intel_engine_init_cmd_parser(engine);
> > > > if (err)
> > > > goto err_cmd_parser;
> > > > @@ -735,6 +738,8 @@ static int engine_setup_common(struct
> > > > intel_engine_cs *engine)
> > > > return 0;
> > > >
> > > > err_cmd_parser:
> > > > + i915_sched_engine_put(engine->sched_engine);
> > > > +err_sched_engine:
> > > > intel_breadcrumbs_free(engine->breadcrumbs);
> > > > err_status:
> > > > cleanup_status_page(engine);
> > > > @@ -958,6 +963,7 @@ void intel_engine_cleanup_common(struct
> > > > intel_engine_cs *engine)
> > > > GEM_BUG_ON(!list_empty(>active.requests));
> > > > tasklet_kill(>execlists.tasklet); /* flush the callback
> > > > */
> > > >
> > > > + i915_sched_engine_put(engine->sched_engine);
> > > > intel_breadcrumbs_free(engine->breadcrumbs);
> > > >
> > > > intel_engine_fini_retire(engine);
> > > > @@ -1281,7 +1287,7 @@ bool intel_engine_is_idle(struct intel_engine_cs
> > > > *engine)
> > > > intel_engine_flush_submission(engine);
> > > >
> > > > /* ELSP is empty, but there are ready requests? E.g. after
> > > > reset */
> > > > - if (!RB_EMPTY_ROOT(>execlists.queue.rb_root))
> > > > + if (!RB_EMPTY_ROOT(>sched_engine->queue.rb_root))
> > > > return false;
> > > >
> > > > /* Ring stopped? */
> > > > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > > > b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > > > index 47f4397095e5..b6a00dd72808 100644
> > > > --- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > > > +++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > > > @@ -275,12 +275,12 @@ static int __engine_park(struct intel_wakeref *wf)
> > > > intel_breadcrumbs_park(engine->breadcrumbs);
> > > >
> > > > /* Must be reset upon idling, or we may miss the busy wakeup. */
> > > > -
Re: [PATCH 1/9] drm/i915: Move priolist to new i915_sched_engine object
On Fri, Jun 4, 2021 at 12:42 PM Matthew Brost wrote:
>
> On Fri, Jun 04, 2021 at 12:38:22PM -0500, Jason Ekstrand wrote:
> > On Thu, Jun 3, 2021 at 4:09 PM Matthew Brost
> > wrote:
> > >
> > > Introduce i915_sched_engine object which is lower level data structure
> > > that i915_scheduler / generic code can operate on without touching
> > > execlist specific structures. This allows additional submission backends
> > > to be added without breaking the layering.
> > >
> > > This is a bit of detour to integrating the i915 with the DRM scheduler
> > > but this object will still exist when the DRM scheduler lands in the
> > > i915. It will however look a bit different. It will encapsulate the
> > > drm_gpu_scheduler object plus and common variables (to the backends)
> > > related to scheduling. Regardless this is a step in the right direction.
> > >
> > > This patch starts the aforementioned transition by moving the the
> > > priolist into the i915_sched_engine object.
> > >
> > > Signed-off-by: Matthew Brost
> > > ---
> > > drivers/gpu/drm/i915/gt/intel_engine_cs.c | 14 +++-
> > > drivers/gpu/drm/i915/gt/intel_engine_pm.c | 4 +-
> > > drivers/gpu/drm/i915/gt/intel_engine_types.h | 30 +--
> > > .../drm/i915/gt/intel_execlists_submission.c | 81 +++
> > > drivers/gpu/drm/i915/gt/mock_engine.c | 9 ++-
> > > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 19 ++---
> > > drivers/gpu/drm/i915/i915_scheduler.c | 51 +---
> > > drivers/gpu/drm/i915/i915_scheduler.h | 18 +
> > > drivers/gpu/drm/i915/i915_scheduler_types.h | 33
> > > 9 files changed, 169 insertions(+), 90 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > > b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > > index 3f9a811eb02b..d0f3814440f6 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > > +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > > @@ -583,9 +583,6 @@ void intel_engine_init_execlists(struct
> > > intel_engine_cs *engine)
> > > memset(execlists->pending, 0, sizeof(execlists->pending));
> > > execlists->active =
> > > memset(execlists->inflight, 0,
> > > sizeof(execlists->inflight));
> > > -
> > > - execlists->queue_priority_hint = INT_MIN;
> > > - execlists->queue = RB_ROOT_CACHED;
> > > }
> > >
> > > static void cleanup_status_page(struct intel_engine_cs *engine)
> > > @@ -712,6 +709,12 @@ static int engine_setup_common(struct
> > > intel_engine_cs *engine)
> > > goto err_status;
> > > }
> > >
> > > + engine->sched_engine = i915_sched_engine_create(ENGINE_PHYSICAL);
> > > + if (!engine->sched_engine) {
> > > + err = -ENOMEM;
> > > + goto err_sched_engine;
> > > + }
> > > +
> > > err = intel_engine_init_cmd_parser(engine);
> > > if (err)
> > > goto err_cmd_parser;
> > > @@ -735,6 +738,8 @@ static int engine_setup_common(struct intel_engine_cs
> > > *engine)
> > > return 0;
> > >
> > > err_cmd_parser:
> > > + i915_sched_engine_put(engine->sched_engine);
> > > +err_sched_engine:
> > > intel_breadcrumbs_free(engine->breadcrumbs);
> > > err_status:
> > > cleanup_status_page(engine);
> > > @@ -958,6 +963,7 @@ void intel_engine_cleanup_common(struct
> > > intel_engine_cs *engine)
> > > GEM_BUG_ON(!list_empty(>active.requests));
> > > tasklet_kill(>execlists.tasklet); /* flush the callback */
> > >
> > > + i915_sched_engine_put(engine->sched_engine);
> > > intel_breadcrumbs_free(engine->breadcrumbs);
> > >
> > > intel_engine_fini_retire(engine);
> > > @@ -1281,7 +1287,7 @@ bool intel_engine_is_idle(struct intel_engine_cs
> > > *engine)
> > > intel_engine_flush_submission(engine);
> > >
> > > /* ELSP is empty, but there are ready requests? E.g. after reset
> > > */
> > > - if (!RB_EMPTY_ROOT(>execlists.queue.rb_root))
> > > + if (!RB_EMPTY_ROOT(>sched_engine->queue.rb_root))
> > > return false;
> > >
> > > /* Ring stopped? */
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > > b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > > index 47f4397095e5..b6a00dd72808 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > > +++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > > @@ -275,12 +275,12 @@ static int __engine_park(struct intel_wakeref *wf)
> > > intel_breadcrumbs_park(engine->breadcrumbs);
> > >
> > > /* Must be reset upon idling, or we may miss the busy wakeup. */
> > > - GEM_BUG_ON(engine->execlists.queue_priority_hint != INT_MIN);
> > > + GEM_BUG_ON(engine->sched_engine->queue_priority_hint != INT_MIN);
> > >
> > > if (engine->park)
> > > engine->park(engine);
> > >
> > > - engine->execlists.no_priolist = false;
> > > +
Re: [Intel-gfx] [PATCH 2/9] drm/i915: Add i915_sched_engine_is_empty function
Reviewed-by: Jason Ekstrand
On Thu, Jun 3, 2021 at 4:09 PM Matthew Brost wrote:
>
> Add wrapper function around RB tree to determine if i915_sched_engine is
> empty.
>
> Signed-off-by: Matthew Brost
> ---
> drivers/gpu/drm/i915/gt/intel_engine_cs.c| 2 +-
> drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 6 +++---
> drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c| 2 +-
> drivers/gpu/drm/i915/i915_scheduler.h| 6 ++
> 4 files changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index d0f3814440f6..85f2effe9dc6 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -1287,7 +1287,7 @@ bool intel_engine_is_idle(struct intel_engine_cs
> *engine)
> intel_engine_flush_submission(engine);
>
> /* ELSP is empty, but there are ready requests? E.g. after reset */
> - if (!RB_EMPTY_ROOT(>sched_engine->queue.rb_root))
> + if (!i915_sched_engine_is_empty(engine->sched_engine))
> return false;
>
> /* Ring stopped? */
> diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> index d1dc1db3e378..2326a73af6d3 100644
> --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> @@ -384,7 +384,7 @@ __unwind_incomplete_requests(struct intel_engine_cs
> *engine)
> prio = rq_prio(rq);
> pl = i915_sched_lookup_priolist(engine, prio);
> }
> -
> GEM_BUG_ON(RB_EMPTY_ROOT(>sched_engine->queue.rb_root));
> + GEM_BUG_ON(i915_sched_engine_is_empty(engine->sched_engine));
>
> list_move(>sched.link, pl);
> set_bit(I915_FENCE_FLAG_PQUEUE, >fence.flags);
> @@ -1139,7 +1139,7 @@ static bool needs_timeslice(const struct
> intel_engine_cs *engine,
> }
>
> /* Otherwise, ELSP[0] is by itself, but may be waiting in the queue */
> - if (!RB_EMPTY_ROOT(>sched_engine->queue.rb_root)) {
> + if (!i915_sched_engine_is_empty(engine->sched_engine)) {
> ENGINE_TRACE(engine, "timeslice required for queue\n");
> return true;
> }
> @@ -2487,7 +2487,7 @@ static void execlists_submit_request(struct
> i915_request *request)
> } else {
> queue_request(engine, request);
>
> -
> GEM_BUG_ON(RB_EMPTY_ROOT(>sched_engine->queue.rb_root));
> + GEM_BUG_ON(i915_sched_engine_is_empty(engine->sched_engine));
> GEM_BUG_ON(list_empty(>sched.link));
>
> if (submit_queue(engine, request))
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> index d42dea79ee64..5d00f2e3c1de 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> @@ -541,7 +541,7 @@ static void guc_submit_request(struct i915_request *rq)
>
> queue_request(engine, rq, rq_prio(rq));
>
> - GEM_BUG_ON(RB_EMPTY_ROOT(>sched_engine->queue.rb_root));
> + GEM_BUG_ON(i915_sched_engine_is_empty(engine->sched_engine));
> GEM_BUG_ON(list_empty(>sched.link));
>
> tasklet_hi_schedule(>execlists.tasklet);
> diff --git a/drivers/gpu/drm/i915/i915_scheduler.h
> b/drivers/gpu/drm/i915/i915_scheduler.h
> index 91a04e34cac5..5bec7b3b8456 100644
> --- a/drivers/gpu/drm/i915/i915_scheduler.h
> +++ b/drivers/gpu/drm/i915/i915_scheduler.h
> @@ -66,6 +66,12 @@ i915_sched_engine_put(struct i915_sched_engine
> *sched_engine)
> kref_put(_engine->ref, i915_sched_engine_free);
> }
>
> +static inline bool
> +i915_sched_engine_is_empty(struct i915_sched_engine *sched_engine)
> +{
> + return RB_EMPTY_ROOT(_engine->queue.rb_root);
> +}
> +
> void i915_request_show_with_schedule(struct drm_printer *m,
> const struct i915_request *rq,
> const char *prefix,
> --
> 2.28.0
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [PATCH v8 00/15] Restricted DMA
Hi Claire, On Thu, May 27, 2021 at 08:58:30PM +0800, Claire Chang wrote: > This series implements mitigations for lack of DMA access control on > systems without an IOMMU, which could result in the DMA accessing the > system memory at unexpected times and/or unexpected addresses, possibly > leading to data leakage or corruption. > > For example, we plan to use the PCI-e bus for Wi-Fi and that PCI-e bus is > not behind an IOMMU. As PCI-e, by design, gives the device full access to > system memory, a vulnerability in the Wi-Fi firmware could easily escalate > to a full system exploit (remote wifi exploits: [1a], [1b] that shows a > full chain of exploits; [2], [3]). > > To mitigate the security concerns, we introduce restricted DMA. Restricted > DMA utilizes the existing swiotlb to bounce streaming DMA in and out of a > specially allocated region and does memory allocation from the same region. > The feature on its own provides a basic level of protection against the DMA > overwriting buffer contents at unexpected times. However, to protect > against general data leakage and system memory corruption, the system needs > to provide a way to restrict the DMA to a predefined memory region (this is > usually done at firmware level, e.g. MPU in ATF on some ARM platforms [4]). > > [1a] > https://googleprojectzero.blogspot.com/2017/04/over-air-exploiting-broadcoms-wi-fi_4.html > [1b] > https://googleprojectzero.blogspot.com/2017/04/over-air-exploiting-broadcoms-wi-fi_11.html > [2] https://blade.tencent.com/en/advisories/qualpwn/ > [3] > https://www.bleepingcomputer.com/news/security/vulnerabilities-found-in-highly-popular-firmware-for-wifi-chips/ > [4] > https://github.com/ARM-software/arm-trusted-firmware/blob/master/plat/mediatek/mt8183/drivers/emi_mpu/emi_mpu.c#L132 > > v8: > - Fix reserved-memory.txt and add the reg property in example. > - Fix sizeof for of_property_count_elems_of_size in > drivers/of/address.c#of_dma_set_restricted_buffer. > - Apply Will's suggestion to try the OF node having DMA configuration in > drivers/of/address.c#of_dma_set_restricted_buffer. > - Fix typo in the comment of > drivers/of/address.c#of_dma_set_restricted_buffer. > - Add error message for PageHighMem in > kernel/dma/swiotlb.c#rmem_swiotlb_device_init and move it to > rmem_swiotlb_setup. > - Fix the message string in rmem_swiotlb_setup. Thanks for the v8. It works for me out of the box on arm64 under KVM, so: Tested-by: Will Deacon Note that something seems to have gone wrong with the mail threading, so the last 5 patches ended up as a separate thread for me. Probably worth posting again with all the patches in one place, if you can. Cheers, Will
Re: [PATCH 1/9] drm/i915: Move priolist to new i915_sched_engine object
On Fri, Jun 04, 2021 at 12:38:22PM -0500, Jason Ekstrand wrote:
> On Thu, Jun 3, 2021 at 4:09 PM Matthew Brost wrote:
> >
> > Introduce i915_sched_engine object which is lower level data structure
> > that i915_scheduler / generic code can operate on without touching
> > execlist specific structures. This allows additional submission backends
> > to be added without breaking the layering.
> >
> > This is a bit of detour to integrating the i915 with the DRM scheduler
> > but this object will still exist when the DRM scheduler lands in the
> > i915. It will however look a bit different. It will encapsulate the
> > drm_gpu_scheduler object plus and common variables (to the backends)
> > related to scheduling. Regardless this is a step in the right direction.
> >
> > This patch starts the aforementioned transition by moving the the
> > priolist into the i915_sched_engine object.
> >
> > Signed-off-by: Matthew Brost
> > ---
> > drivers/gpu/drm/i915/gt/intel_engine_cs.c | 14 +++-
> > drivers/gpu/drm/i915/gt/intel_engine_pm.c | 4 +-
> > drivers/gpu/drm/i915/gt/intel_engine_types.h | 30 +--
> > .../drm/i915/gt/intel_execlists_submission.c | 81 +++
> > drivers/gpu/drm/i915/gt/mock_engine.c | 9 ++-
> > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 19 ++---
> > drivers/gpu/drm/i915/i915_scheduler.c | 51 +---
> > drivers/gpu/drm/i915/i915_scheduler.h | 18 +
> > drivers/gpu/drm/i915/i915_scheduler_types.h | 33
> > 9 files changed, 169 insertions(+), 90 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > index 3f9a811eb02b..d0f3814440f6 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > @@ -583,9 +583,6 @@ void intel_engine_init_execlists(struct intel_engine_cs
> > *engine)
> > memset(execlists->pending, 0, sizeof(execlists->pending));
> > execlists->active =
> > memset(execlists->inflight, 0, sizeof(execlists->inflight));
> > -
> > - execlists->queue_priority_hint = INT_MIN;
> > - execlists->queue = RB_ROOT_CACHED;
> > }
> >
> > static void cleanup_status_page(struct intel_engine_cs *engine)
> > @@ -712,6 +709,12 @@ static int engine_setup_common(struct intel_engine_cs
> > *engine)
> > goto err_status;
> > }
> >
> > + engine->sched_engine = i915_sched_engine_create(ENGINE_PHYSICAL);
> > + if (!engine->sched_engine) {
> > + err = -ENOMEM;
> > + goto err_sched_engine;
> > + }
> > +
> > err = intel_engine_init_cmd_parser(engine);
> > if (err)
> > goto err_cmd_parser;
> > @@ -735,6 +738,8 @@ static int engine_setup_common(struct intel_engine_cs
> > *engine)
> > return 0;
> >
> > err_cmd_parser:
> > + i915_sched_engine_put(engine->sched_engine);
> > +err_sched_engine:
> > intel_breadcrumbs_free(engine->breadcrumbs);
> > err_status:
> > cleanup_status_page(engine);
> > @@ -958,6 +963,7 @@ void intel_engine_cleanup_common(struct intel_engine_cs
> > *engine)
> > GEM_BUG_ON(!list_empty(>active.requests));
> > tasklet_kill(>execlists.tasklet); /* flush the callback */
> >
> > + i915_sched_engine_put(engine->sched_engine);
> > intel_breadcrumbs_free(engine->breadcrumbs);
> >
> > intel_engine_fini_retire(engine);
> > @@ -1281,7 +1287,7 @@ bool intel_engine_is_idle(struct intel_engine_cs
> > *engine)
> > intel_engine_flush_submission(engine);
> >
> > /* ELSP is empty, but there are ready requests? E.g. after reset */
> > - if (!RB_EMPTY_ROOT(>execlists.queue.rb_root))
> > + if (!RB_EMPTY_ROOT(>sched_engine->queue.rb_root))
> > return false;
> >
> > /* Ring stopped? */
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > index 47f4397095e5..b6a00dd72808 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > @@ -275,12 +275,12 @@ static int __engine_park(struct intel_wakeref *wf)
> > intel_breadcrumbs_park(engine->breadcrumbs);
> >
> > /* Must be reset upon idling, or we may miss the busy wakeup. */
> > - GEM_BUG_ON(engine->execlists.queue_priority_hint != INT_MIN);
> > + GEM_BUG_ON(engine->sched_engine->queue_priority_hint != INT_MIN);
> >
> > if (engine->park)
> > engine->park(engine);
> >
> > - engine->execlists.no_priolist = false;
> > + engine->sched_engine->no_priolist = false;
> >
> > /* While gt calls i915_vma_parked(), we have to break the lock
> > cycle */
> > intel_gt_pm_put_async(engine->gt);
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> > b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> > index
Re: [Intel-gfx] [RFC PATCH 1/2] drm/doc/rfc: i915 GuC submission / DRM scheduler
On Wed, May 26, 2021 at 04:33:56PM -0700, Matthew Brost wrote: > Add entry for i915 GuC submission / DRM scheduler integration plan. > Follow up patch with details of new parallel submission uAPI to come. > > v2: > (Daniel Vetter) > - Expand explaination of why bonding isn't supported for GuC > submission > - CC some of the DRM scheduler maintainers > - Add priority inheritance / boosting use case > - Add reasoning for removing in order assumptions > (Daniel Stone) > - Add links to priority spec > > Cc: Christian König > Cc: Luben Tuikov > Cc: Alex Deucher > Cc: Steven Price > Cc: Jon Bloomfield > Cc: Jason Ekstrand > Cc: Dave Airlie > Cc: Daniel Vetter > Cc: Jason Ekstrand > Cc: dri-devel@lists.freedesktop.org > Signed-off-by: Matthew Brost You have a one-line hunk in the next patch that probably should be here. With that moved. Reviewed-by: Daniel Vetter Also did you get an ack from Carl on these? -Daniel > --- > Documentation/gpu/rfc/i915_scheduler.rst | 85 > Documentation/gpu/rfc/index.rst | 4 ++ > 2 files changed, 89 insertions(+) > create mode 100644 Documentation/gpu/rfc/i915_scheduler.rst > > diff --git a/Documentation/gpu/rfc/i915_scheduler.rst > b/Documentation/gpu/rfc/i915_scheduler.rst > new file mode 100644 > index ..7faa46cde088 > --- /dev/null > +++ b/Documentation/gpu/rfc/i915_scheduler.rst > @@ -0,0 +1,85 @@ > += > +I915 GuC Submission/DRM Scheduler Section > += > + > +Upstream plan > += > +For upstream the overall plan for landing GuC submission and integrating the > +i915 with the DRM scheduler is: > + > +* Merge basic GuC submission > + * Basic submission support for all gen11+ platforms > + * Not enabled by default on any current platforms but can be enabled via > + modparam enable_guc > + * Lots of rework will need to be done to integrate with DRM scheduler so > + no need to nit pick everything in the code, it just should be > + functional, no major coding style / layering errors, and not regress > + execlists > + * Update IGTs / selftests as needed to work with GuC submission > + * Enable CI on supported platforms for a baseline > + * Rework / get CI heathly for GuC submission in place as needed > +* Merge new parallel submission uAPI > + * Bonding uAPI completely incompatible with GuC submission, plus it has > + severe design issues in general, which is why we want to retire it no > + matter what > + * New uAPI adds I915_CONTEXT_ENGINES_EXT_PARALLEL context setup step > + which configures a slot with N contexts > + * After I915_CONTEXT_ENGINES_EXT_PARALLEL a user can submit N batches to > + a slot in a single execbuf IOCTL and the batches run on the GPU in > + paralllel > + * Initially only for GuC submission but execlists can be supported if > + needed > +* Convert the i915 to use the DRM scheduler > + * GuC submission backend fully integrated with DRM scheduler > + * All request queues removed from backend (e.g. all backpressure > + handled in DRM scheduler) > + * Resets / cancels hook in DRM scheduler > + * Watchdog hooks into DRM scheduler > + * Lots of complexity of the GuC backend can be pulled out once > + integrated with DRM scheduler (e.g. state machine gets > + simplier, locking gets simplier, etc...) > + * Execlist backend will do the minimum required to hook in the DRM > + scheduler so it can live next to the fully integrated GuC backend > + * Legacy interface > + * Features like timeslicing / preemption / virtual engines would > + be difficult to integrate with the DRM scheduler and these > + features are not required for GuC submission as the GuC does > + these things for us > + * ROI low on fully integrating into DRM scheduler > + * Fully integrating would add lots of complexity to DRM > + scheduler > + * Port i915 priority inheritance / boosting feature in DRM scheduler > + * Used for i915 page flip, may be useful to other DRM drivers as > + well > + * Will be an optional feature in the DRM scheduler > + * Remove in-order completion assumptions from DRM scheduler > + * Even when using the DRM scheduler the backends will handle > + preemption, timeslicing, etc... so it is possible for jobs to > + finish out of order > + * Pull out i915 priority levels and use DRM priority levels > + * Optimize DRM scheduler as needed > + > +New uAPI for basic GuC submission > += > +No major changes are required to the uAPI for basic GuC submission. The only > +change is a new
Re: [PATCH 1/9] drm/i915: Move priolist to new i915_sched_engine object
On Thu, Jun 3, 2021 at 4:09 PM Matthew Brost wrote:
>
> Introduce i915_sched_engine object which is lower level data structure
> that i915_scheduler / generic code can operate on without touching
> execlist specific structures. This allows additional submission backends
> to be added without breaking the layering.
>
> This is a bit of detour to integrating the i915 with the DRM scheduler
> but this object will still exist when the DRM scheduler lands in the
> i915. It will however look a bit different. It will encapsulate the
> drm_gpu_scheduler object plus and common variables (to the backends)
> related to scheduling. Regardless this is a step in the right direction.
>
> This patch starts the aforementioned transition by moving the the
> priolist into the i915_sched_engine object.
>
> Signed-off-by: Matthew Brost
> ---
> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 14 +++-
> drivers/gpu/drm/i915/gt/intel_engine_pm.c | 4 +-
> drivers/gpu/drm/i915/gt/intel_engine_types.h | 30 +--
> .../drm/i915/gt/intel_execlists_submission.c | 81 +++
> drivers/gpu/drm/i915/gt/mock_engine.c | 9 ++-
> .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 19 ++---
> drivers/gpu/drm/i915/i915_scheduler.c | 51 +---
> drivers/gpu/drm/i915/i915_scheduler.h | 18 +
> drivers/gpu/drm/i915/i915_scheduler_types.h | 33
> 9 files changed, 169 insertions(+), 90 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index 3f9a811eb02b..d0f3814440f6 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -583,9 +583,6 @@ void intel_engine_init_execlists(struct intel_engine_cs
> *engine)
> memset(execlists->pending, 0, sizeof(execlists->pending));
> execlists->active =
> memset(execlists->inflight, 0, sizeof(execlists->inflight));
> -
> - execlists->queue_priority_hint = INT_MIN;
> - execlists->queue = RB_ROOT_CACHED;
> }
>
> static void cleanup_status_page(struct intel_engine_cs *engine)
> @@ -712,6 +709,12 @@ static int engine_setup_common(struct intel_engine_cs
> *engine)
> goto err_status;
> }
>
> + engine->sched_engine = i915_sched_engine_create(ENGINE_PHYSICAL);
> + if (!engine->sched_engine) {
> + err = -ENOMEM;
> + goto err_sched_engine;
> + }
> +
> err = intel_engine_init_cmd_parser(engine);
> if (err)
> goto err_cmd_parser;
> @@ -735,6 +738,8 @@ static int engine_setup_common(struct intel_engine_cs
> *engine)
> return 0;
>
> err_cmd_parser:
> + i915_sched_engine_put(engine->sched_engine);
> +err_sched_engine:
> intel_breadcrumbs_free(engine->breadcrumbs);
> err_status:
> cleanup_status_page(engine);
> @@ -958,6 +963,7 @@ void intel_engine_cleanup_common(struct intel_engine_cs
> *engine)
> GEM_BUG_ON(!list_empty(>active.requests));
> tasklet_kill(>execlists.tasklet); /* flush the callback */
>
> + i915_sched_engine_put(engine->sched_engine);
> intel_breadcrumbs_free(engine->breadcrumbs);
>
> intel_engine_fini_retire(engine);
> @@ -1281,7 +1287,7 @@ bool intel_engine_is_idle(struct intel_engine_cs
> *engine)
> intel_engine_flush_submission(engine);
>
> /* ELSP is empty, but there are ready requests? E.g. after reset */
> - if (!RB_EMPTY_ROOT(>execlists.queue.rb_root))
> + if (!RB_EMPTY_ROOT(>sched_engine->queue.rb_root))
> return false;
>
> /* Ring stopped? */
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> index 47f4397095e5..b6a00dd72808 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> @@ -275,12 +275,12 @@ static int __engine_park(struct intel_wakeref *wf)
> intel_breadcrumbs_park(engine->breadcrumbs);
>
> /* Must be reset upon idling, or we may miss the busy wakeup. */
> - GEM_BUG_ON(engine->execlists.queue_priority_hint != INT_MIN);
> + GEM_BUG_ON(engine->sched_engine->queue_priority_hint != INT_MIN);
>
> if (engine->park)
> engine->park(engine);
>
> - engine->execlists.no_priolist = false;
> + engine->sched_engine->no_priolist = false;
>
> /* While gt calls i915_vma_parked(), we have to break the lock cycle
> */
> intel_gt_pm_put_async(engine->gt);
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> index 9ef349cd5cea..86b41ddec373 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> @@ -59,6 +59,7 @@ struct drm_i915_reg_table;
> struct i915_gem_context;
> struct i915_request;
> struct i915_sched_attr;
> +struct i915_sched_engine;
>
Re: [Intel-gfx] [PATCH 9/9] drm/i915/doc: Add kernel doc for i915_sched_engine
On Fri, Jun 04, 2021 at 12:20:36PM -0500, Jason Ekstrand wrote:
> On Thu, Jun 3, 2021 at 4:09 PM Matthew Brost wrote:
> >
> > Signed-off-by: Matthew Brost
> > ---
> > Documentation/gpu/i915.rst | 6
> > drivers/gpu/drm/i915/i915_scheduler_types.h | 37 ++---
> > 2 files changed, 38 insertions(+), 5 deletions(-)
> >
> > diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
> > index 42ce0196930a..8f4f5471a05b 100644
> > --- a/Documentation/gpu/i915.rst
> > +++ b/Documentation/gpu/i915.rst
> > @@ -425,6 +425,12 @@ User Batchbuffer Execution
> > .. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > :doc: User command execution
> >
> > +Scheduling
> > +--
> > +.. kernel-doc:: drivers/gpu/drm/i915/i915_scheduler_types.h
> > + :functions: i915_sched_engine
> > +
> > +
> > Logical Rings, Logical Ring Contexts and Execlists
> > --
> >
> > diff --git a/drivers/gpu/drm/i915/i915_scheduler_types.h
> > b/drivers/gpu/drm/i915/i915_scheduler_types.h
> > index 9d79514450de..e3da7517853f 100644
> > --- a/drivers/gpu/drm/i915/i915_scheduler_types.h
> > +++ b/drivers/gpu/drm/i915/i915_scheduler_types.h
> > @@ -91,7 +91,21 @@ struct i915_dependency {
> > &(rq__)->sched.signalers_list, \
> > signal_link)
> >
> > +/**
> > + * sturct i915_sched_engine - scheduler engine
> > + *
> > + * A schedule engine represents a submission queue with different priority
> > + * bands. It contains all the common state (relative to the backend) to
> > queue,
> > + * track, and submit a request.
> > + *
> > + * This object at the moment is quite i915 specific but will transition
> > into a
> > + * container for the drm_gpu_scheduler plus a few other variables once the
> > i915
> > + * is integrated with the DRM scheduler.
> > + */
>
> Why is this its own patch? The above comment would be nice to have in
> patch 1/9 and the kref could be documented there too.
>
I thought it make the review easier? Either way, can squash this patch into the
previous 8 as needed in next rev.
Matt
> > struct i915_sched_engine {
> > + /**
> > +* @ref: reference count of schedule engine object
> > +*/
> > struct kref ref;
> >
> > /**
> > @@ -100,11 +114,18 @@ struct i915_sched_engine {
> > */
> > spinlock_t lock;
> >
> > + /**
> > +* @requests: list of requests inflight on this schedule engine
> > +*/
> > struct list_head requests;
> > - struct list_head hold; /* ready requests, but on hold */
> >
> > /**
> > -* @tasklet: softirq tasklet for bottom handler
> > +* @hold: list of requests on hold.
> > +*/
> > + struct list_head hold;
> > +
> > + /**
> > +* @tasklet: softirq tasklet for submission
> > */
> > struct tasklet_struct tasklet;
> >
> > @@ -137,14 +158,20 @@ struct i915_sched_engine {
> > */
> > bool no_priolist;
> >
> > - /* Back pointer to engine */
> > + /**
> > +* @engine: back pointer to engine
> > +*/
> > struct intel_engine_cs *engine;
> >
> > - /* Kick backend */
> > + /**
> > +* @kick_backed: kick back after a request's priority has changed
> > +*/
> > void(*kick_backend)(const struct i915_request *rq,
> > int prio);
> >
> > - /*
> > + /**
> > +* @schedule: schedule function to adjust priority of request
> > +*
> > * Call when the priority on a request has changed and it and its
> > * dependencies may need rescheduling. Note the request itself may
> > * not be ready to run!
> > --
> > 2.28.0
> >
> > ___
> > Intel-gfx mailing list
> > intel-...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [PATCH 4/4] drm/i915/display: Add handling for new "active bpc" property
On Fri, Jun 04, 2021 at 07:17:23PM +0200, Werner Sembach wrote:
> This commits implements the "active bpc" drm property for the Intel GPU
> driver.
>
> Signed-off-by: Werner Sembach
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 13 +
> drivers/gpu/drm/i915/display/intel_dp.c | 8 ++--
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 4 +++-
> drivers/gpu/drm/i915/display/intel_hdmi.c| 4 +++-
> 4 files changed, 25 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 64e9107d70f7..f7898d9d7438 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -10164,6 +10164,8 @@ static void intel_atomic_commit_tail(struct
> intel_atomic_state *state)
> struct drm_i915_private *dev_priv = to_i915(dev);
> struct intel_crtc_state *new_crtc_state, *old_crtc_state;
> struct intel_crtc *crtc;
> + struct drm_connector *connector;
> + struct drm_connector_state *new_conn_state;
> u64 put_domains[I915_MAX_PIPES] = {};
> intel_wakeref_t wakeref = 0;
> int i;
> @@ -10324,6 +10326,17 @@ static void intel_atomic_commit_tail(struct
> intel_atomic_state *state)
> }
> intel_runtime_pm_put(_priv->runtime_pm, state->wakeref);
>
> + /* Extract information from crtc to communicate it to userspace as
> connector properties */
> + for_each_new_connector_in_state(>base, connector,
> new_conn_state, i) {
> + struct drm_crtc *crtc = new_conn_state->crtc;
> + if (crtc) {
> + new_crtc_state =
> to_intel_crtc_state(drm_atomic_get_new_crtc_state(>base, crtc));
intel_atomic_get_new_crtc_state()
> + new_conn_state->active_bpc = new_crtc_state->pipe_bpp /
> 3;
> + }
> + else
> + new_conn_state->active_bpc = 0;
> + }
This also seems too late. I think the whole thing should be
done somewhere around the normal swap_state() stuff.
> +
> /*
>* Defer the cleanup of the old state to a separate worker to not
>* impede the current task (userspace for blocking modesets) that
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 642c60f3d9b1..67826ba976ed 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -4671,10 +4671,14 @@ intel_dp_add_properties(struct intel_dp *intel_dp,
> struct drm_connector *connect
> intel_attach_force_audio_property(connector);
>
> intel_attach_broadcast_rgb_property(connector);
> - if (HAS_GMCH(dev_priv))
> + if (HAS_GMCH(dev_priv)) {
> drm_connector_attach_max_bpc_property(connector, 6, 10);
> - else if (DISPLAY_VER(dev_priv) >= 5)
> + drm_connector_attach_active_bpc_property(connector, 6, 10);
> + }
> + else if (DISPLAY_VER(dev_priv) >= 5) {
> drm_connector_attach_max_bpc_property(connector, 6, 12);
> + drm_connector_attach_active_bpc_property(connector, 6, 12);
> + }
>
> /* Register HDMI colorspace for case of lspcon */
> if (intel_bios_is_lspcon_present(dev_priv, port)) {
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index 2daa3f67791e..5a1869dc2210 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -844,8 +844,10 @@ static struct drm_connector
> *intel_dp_add_mst_connector(struct drm_dp_mst_topolo
>*/
> connector->max_bpc_property =
> intel_dp->attached_connector->base.max_bpc_property;
> - if (connector->max_bpc_property)
> + if (connector->max_bpc_property) {
> drm_connector_attach_max_bpc_property(connector, 6, 12);
> + drm_connector_attach_active_bpc_property(connector, 6, 12);
> + }
>
> return connector;
>
> diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
> b/drivers/gpu/drm/i915/display/intel_hdmi.c
> index d69f0a6dc26d..8af78b27b6ce 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
> @@ -2463,8 +2463,10 @@ intel_hdmi_add_properties(struct intel_hdmi
> *intel_hdmi, struct drm_connector *c
> drm_object_attach_property(>base,
>
> connector->dev->mode_config.hdr_output_metadata_property, 0);
>
> - if (!HAS_GMCH(dev_priv))
> + if (!HAS_GMCH(dev_priv)) {
> drm_connector_attach_max_bpc_property(connector, 8, 12);
> + drm_connector_attach_active_bpc_property(connector, 8, 12);
> + }
> }
>
> /*
> --
> 2.25.1
--
Ville Syrjälä
Intel
Re: [PATCH 2/4] drm/uAPI: Add "active bpc" as feedback channel for "max bpc" drm property
On Fri, Jun 04, 2021 at 07:17:21PM +0200, Werner Sembach wrote:
> Add a new general drm property "active bpc" which can be used by graphic
> drivers
> to report the applied bit depth per pixel back to userspace.
>
> While "max bpc" can be used to change the color depth, there was no way to
> check
> which one actually got used. While in theory the driver chooses the
> best/highest
> color depth within the max bpc setting a user might not be fully aware what
> his
> hardware is or isn't capable off. This is meant as a quick way to double check
> the setup.
>
> In the future, automatic color calibration for screens might also depend on
> this
> information available.
>
> Signed-off-by: Werner Sembach
> ---
> drivers/gpu/drm/drm_atomic_uapi.c | 2 ++
> drivers/gpu/drm/drm_connector.c | 40 +++
> include/drm/drm_connector.h | 15
> 3 files changed, 57 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index 268bb69c2e2f..7ae4e40936b5 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -873,6 +873,8 @@ drm_atomic_connector_get_property(struct drm_connector
> *connector,
> *val = 0;
> } else if (property == connector->max_bpc_property) {
> *val = state->max_requested_bpc;
> + } else if (property == connector->active_bpc_property) {
> + *val = state->active_bpc;
> } else if (connector->funcs->atomic_get_property) {
> return connector->funcs->atomic_get_property(connector,
> state, property, val);
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 7631f76e7f34..5f42a5be5822 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1195,6 +1195,13 @@ static const struct drm_prop_enum_list
> dp_colorspaces[] = {
> * drm_connector_attach_max_bpc_property() to create and attach the
> * property to the connector during initialization.
> *
> + * active bpc:
> + * This read-only range property is used by userspace check the bit depth
> + * actually applied by the GPU driver after evaluation all hardware
> + * capabilities and max bpc. Drivers to use the function
> + * drm_connector_attach_active_bpc_property() to create and attach the
> + * property to the connector during initialization.
> + *
> * Connectors also have one standardized atomic property:
> *
> * CRTC_ID:
> @@ -2150,6 +2157,39 @@ int drm_connector_attach_max_bpc_property(struct
> drm_connector *connector,
> }
> EXPORT_SYMBOL(drm_connector_attach_max_bpc_property);
>
> +/**
> + * drm_connector_attach_active_bpc_property - attach "active bpc" property
> + * @connector: connector to attach active bpc property on.
> + * @min: The minimum bit depth supported by the connector.
> + * @max: The maximum bit depth supported by the connector.
> + *
> + * This is used to check the applied bit depth on a connector.
> + *
> + * Returns:
> + * Zero on success, negative errno on failure.
> + */
> +int drm_connector_attach_active_bpc_property(struct drm_connector *connector,
> + int min, int max)
> +{
> + struct drm_device *dev = connector->dev;
> + struct drm_property *prop;
> +
> + prop = connector->active_bpc_property;
> + if (!prop) {
> + prop = drm_property_create_range(dev, 0, "active bpc", min,
> max);
Should be immutable.
Also wondering what the semantics of this should be when eg. DSC
is active?
> + if (!prop)
> + return -ENOMEM;
> +
> + connector->active_bpc_property = prop;
> + }
> +
> + drm_object_attach_property(>base, prop, 0);
> + connector->state->active_bpc = 0;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_connector_attach_active_bpc_property);
> +
> /**
> * drm_connector_set_vrr_capable_property - sets the variable refresh rate
> * capable property for a connector
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 1922b278ffad..c58cba2b6afe 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -781,6 +781,13 @@ struct drm_connector_state {
>*/
> u8 max_bpc;
>
> + /**
> + * @active_bpc: Read only property set by the GPU driver to the actually
> + * applied bit depth of the pixels after evaluating all hardware
> + * limitations.
> + */
> + u8 active_bpc;
> +
> /**
>* @hdr_output_metadata:
>* DRM blob property for HDR output metadata
> @@ -1380,6 +1387,12 @@ struct drm_connector {
>*/
> struct drm_property *max_bpc_property;
>
> + /**
> + * @active_bpc_property: Default connector property for the active bpc
> + * to be driven out of the connector.
> + */
> + struct drm_property *active_bpc_property;
> +
>
Re: [git pull] drm fixes for 5.13-rc5
The pull request you sent on Fri, 4 Jun 2021 11:54:28 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2021-06-04-1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/3a3c5ab3d6988afdcd63f3fc8e33d157ca1d9c67 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [PATCH v4 2/2] radeon: use memcpy_to/fromio for UVD fw upload
Applied with the RB fixed.
Thanks!
Alex
On Fri, Jun 4, 2021 at 7:53 AM Chen Li wrote:
>
>
> I met a gpu addr bug recently and the kernel log
> tells me the pc is memcpy/memset and link register is
> radeon_uvd_resume.
>
> As we know, in some architectures, optimized memcpy/memset
> may not work well on device memory. Trival memcpy_toio/memset_io
> can fix this problem.
>
> BTW, amdgpu has already done it in:
> commit ba0b2275a678 ("drm/amdgpu: use memcpy_to/fromio for UVD fw upload"),
> that's why it has no this issue on the same gpu and platform.
>
> Signed-off-by: Chen Li
> Reviewed-by: Christian König
> ---
> drivers/gpu/drm/radeon/radeon_uvd.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c
> b/drivers/gpu/drm/radeon/radeon_uvd.c
> index 85a1f2c31749..753da95e6abb 100644
> --- a/drivers/gpu/drm/radeon/radeon_uvd.c
> +++ b/drivers/gpu/drm/radeon/radeon_uvd.c
> @@ -288,7 +288,7 @@ int radeon_uvd_resume(struct radeon_device *rdev)
> if (rdev->uvd.vcpu_bo == NULL)
> return -EINVAL;
>
> - memcpy(rdev->uvd.cpu_addr, rdev->uvd_fw->data, rdev->uvd_fw->size);
> + memcpy_toio((void __iomem *)rdev->uvd.cpu_addr, rdev->uvd_fw->data,
> rdev->uvd_fw->size);
>
> size = radeon_bo_size(rdev->uvd.vcpu_bo);
> size -= rdev->uvd_fw->size;
> @@ -296,7 +296,7 @@ int radeon_uvd_resume(struct radeon_device *rdev)
> ptr = rdev->uvd.cpu_addr;
> ptr += rdev->uvd_fw->size;
>
> - memset(ptr, 0, size);
> + memset_io((void __iomem *)ptr, 0, size);
>
> return 0;
> }
> --
> 2.31.1
>
>
>
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [Intel-gfx] [PATCH 9/9] drm/i915/doc: Add kernel doc for i915_sched_engine
On Thu, Jun 3, 2021 at 4:09 PM Matthew Brost wrote:
>
> Signed-off-by: Matthew Brost
> ---
> Documentation/gpu/i915.rst | 6
> drivers/gpu/drm/i915/i915_scheduler_types.h | 37 ++---
> 2 files changed, 38 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
> index 42ce0196930a..8f4f5471a05b 100644
> --- a/Documentation/gpu/i915.rst
> +++ b/Documentation/gpu/i915.rst
> @@ -425,6 +425,12 @@ User Batchbuffer Execution
> .. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> :doc: User command execution
>
> +Scheduling
> +--
> +.. kernel-doc:: drivers/gpu/drm/i915/i915_scheduler_types.h
> + :functions: i915_sched_engine
> +
> +
> Logical Rings, Logical Ring Contexts and Execlists
> --
>
> diff --git a/drivers/gpu/drm/i915/i915_scheduler_types.h
> b/drivers/gpu/drm/i915/i915_scheduler_types.h
> index 9d79514450de..e3da7517853f 100644
> --- a/drivers/gpu/drm/i915/i915_scheduler_types.h
> +++ b/drivers/gpu/drm/i915/i915_scheduler_types.h
> @@ -91,7 +91,21 @@ struct i915_dependency {
> &(rq__)->sched.signalers_list, \
> signal_link)
>
> +/**
> + * sturct i915_sched_engine - scheduler engine
> + *
> + * A schedule engine represents a submission queue with different priority
> + * bands. It contains all the common state (relative to the backend) to
> queue,
> + * track, and submit a request.
> + *
> + * This object at the moment is quite i915 specific but will transition into
> a
> + * container for the drm_gpu_scheduler plus a few other variables once the
> i915
> + * is integrated with the DRM scheduler.
> + */
Why is this its own patch? The above comment would be nice to have in
patch 1/9 and the kref could be documented there too.
> struct i915_sched_engine {
> + /**
> +* @ref: reference count of schedule engine object
> +*/
> struct kref ref;
>
> /**
> @@ -100,11 +114,18 @@ struct i915_sched_engine {
> */
> spinlock_t lock;
>
> + /**
> +* @requests: list of requests inflight on this schedule engine
> +*/
> struct list_head requests;
> - struct list_head hold; /* ready requests, but on hold */
>
> /**
> -* @tasklet: softirq tasklet for bottom handler
> +* @hold: list of requests on hold.
> +*/
> + struct list_head hold;
> +
> + /**
> +* @tasklet: softirq tasklet for submission
> */
> struct tasklet_struct tasklet;
>
> @@ -137,14 +158,20 @@ struct i915_sched_engine {
> */
> bool no_priolist;
>
> - /* Back pointer to engine */
> + /**
> +* @engine: back pointer to engine
> +*/
> struct intel_engine_cs *engine;
>
> - /* Kick backend */
> + /**
> +* @kick_backed: kick back after a request's priority has changed
> +*/
> void(*kick_backend)(const struct i915_request *rq,
> int prio);
>
> - /*
> + /**
> +* @schedule: schedule function to adjust priority of request
> +*
> * Call when the priority on a request has changed and it and its
> * dependencies may need rescheduling. Note the request itself may
> * not be ready to run!
> --
> 2.28.0
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [PATCH v4 1/2] radeon: fix coding issues reported from sparse
Applied. Thanks!
Alex
On Fri, Jun 4, 2021 at 7:53 AM Chen Li wrote:
>
>
> Also fix some coding issues reported from sparse.
>
> Signed-off-by: Chen Li
> Acked-by: Christian König
> ---
> drivers/gpu/drm/radeon/radeon_uvd.c | 24 +---
> 1 file changed, 13 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c
> b/drivers/gpu/drm/radeon/radeon_uvd.c
> index dfa9fdbe98da..85a1f2c31749 100644
> --- a/drivers/gpu/drm/radeon/radeon_uvd.c
> +++ b/drivers/gpu/drm/radeon/radeon_uvd.c
> @@ -152,9 +152,11 @@ int radeon_uvd_init(struct radeon_device *rdev)
>
> rdev->uvd.fw_header_present = true;
>
> - family_id = le32_to_cpu(hdr->ucode_version) & 0xff;
> - version_major = (le32_to_cpu(hdr->ucode_version) >>
> 24) & 0xff;
> - version_minor = (le32_to_cpu(hdr->ucode_version) >>
> 8) & 0xff;
> + family_id = (__force u32)(hdr->ucode_version) & 0xff;
> + version_major = (le32_to_cpu((__force
> __le32)(hdr->ucode_version))
> +>> 24) & 0xff;
> + version_minor = (le32_to_cpu((__force
> __le32)(hdr->ucode_version))
> +>> 8) & 0xff;
> DRM_INFO("Found UVD firmware Version: %u.%u Family
> ID: %u\n",
> version_major, version_minor, family_id);
>
> @@ -791,17 +793,17 @@ int radeon_uvd_get_create_msg(struct radeon_device
> *rdev, int ring,
> return r;
>
> /* stitch together an UVD create msg */
> - writel(cpu_to_le32(0x0de4), [0]);
> + writel((__force u32)cpu_to_le32(0x0de4), [0]);
> writel(0x0, (void __iomem *)[1]);
> - writel(cpu_to_le32(handle), [2]);
> + writel((__force u32)cpu_to_le32(handle), [2]);
> writel(0x0, [3]);
> writel(0x0, [4]);
> writel(0x0, [5]);
> writel(0x0, [6]);
> - writel(cpu_to_le32(0x0780), [7]);
> - writel(cpu_to_le32(0x0440), [8]);
> + writel((__force u32)cpu_to_le32(0x0780), [7]);
> + writel((__force u32)cpu_to_le32(0x0440), [8]);
> writel(0x0, [9]);
> - writel(cpu_to_le32(0x01b37000), [10]);
> + writel((__force u32)cpu_to_le32(0x01b37000), [10]);
> for (i = 11; i < 1024; ++i)
> writel(0x0, [i]);
>
> @@ -827,9 +829,9 @@ int radeon_uvd_get_destroy_msg(struct radeon_device
> *rdev, int ring,
> return r;
>
> /* stitch together an UVD destroy msg */
> - writel(cpu_to_le32(0x0de4), [0]);
> - writel(cpu_to_le32(0x0002), [1]);
> - writel(cpu_to_le32(handle), [2]);
> + writel((__force u32)cpu_to_le32(0x0de4), [0]);
> + writel((__force u32)cpu_to_le32(0x0002), [1]);
> + writel((__force u32)cpu_to_le32(handle), [2]);
> writel(0x0, [3]);
> for (i = 4; i < 1024; ++i)
> writel(0x0, [i]);
> --
> 2.31.1
>
>
>
>
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 1/4] drm/amd/display: Add missing cases convert_dc_color_depth_into_bpc
convert_dc_color_depth_into_bpc() that converts the enum dc_color_depth to an integer had the casses for COLOR_DEPTH_999 and COLOR_DEPTH_11 missing. Signed-off-by: Werner Sembach --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index 389eff96fcf6..6e82889271d5 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -6515,6 +6515,10 @@ static int convert_dc_color_depth_into_bpc (enum dc_color_depth display_color_de return 14; case COLOR_DEPTH_161616: return 16; + case COLOR_DEPTH_999: + return 9; + case COLOR_DEPTH_11: + return 11; default: break; } -- 2.25.1
[PATCH 3/4] drm/amd/display: Add handling for new "active bpc" property
This commits implements the "active bpc" drm property for the AMD GPU driver.
Signed-off-by: Werner Sembach
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 18 +-
.../display/amdgpu_dm/amdgpu_dm_mst_types.c| 4 +++-
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 6e82889271d5..52a057c585b1 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -7519,8 +7519,10 @@ void amdgpu_dm_connector_init_helper(struct
amdgpu_display_manager *dm,
adev->mode_info.underscan_vborder_property,
0);
- if (!aconnector->mst_port)
+ if (!aconnector->mst_port) {
drm_connector_attach_max_bpc_property(>base, 8, 16);
+ drm_connector_attach_active_bpc_property(>base, 8,
16);
+ }
/* This defaults to the max in the range, but we want 8bpc for non-edp.
*/
aconnector->base.state->max_bpc = (connector_type ==
DRM_MODE_CONNECTOR_eDP) ? 16 : 8;
@@ -8890,6 +8892,20 @@ static void amdgpu_dm_atomic_commit_tail(struct
drm_atomic_state *state)
mutex_unlock(>dc_lock);
}
+ /* Extract information from crtc to communicate it to userspace as
connector properties */
+ for_each_new_connector_in_state(state, connector, new_con_state, i) {
+ struct drm_crtc *crtc = new_con_state->crtc;
+ if (crtc) {
+ new_crtc_state = drm_atomic_get_new_crtc_state(state,
crtc);
+ dm_new_crtc_state = to_dm_crtc_state(new_crtc_state);
+ if (dm_new_crtc_state->stream)
+ new_con_state->active_bpc =
convert_dc_color_depth_into_bpc(
+
dm_new_crtc_state->stream->timing.display_color_depth);
+ }
+ else
+ new_con_state->active_bpc = 0;
+ }
+
/* Count number of newly disabled CRTCs for dropping PM refs later. */
for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state,
new_crtc_state, i) {
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 9b221db526dc..2a8dc6b2c6c7 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -397,8 +397,10 @@ dm_dp_add_mst_connector(struct drm_dp_mst_topology_mgr
*mgr,
}
connector->max_bpc_property = master->base.max_bpc_property;
- if (connector->max_bpc_property)
+ if (connector->max_bpc_property) {
drm_connector_attach_max_bpc_property(connector, 8, 16);
+ drm_connector_attach_active_bpc_property(>base, 8,
16);
+ }
connector->vrr_capable_property = master->base.vrr_capable_property;
if (connector->vrr_capable_property)
--
2.25.1
[PATCH 2/4] drm/uAPI: Add "active bpc" as feedback channel for "max bpc" drm property
Add a new general drm property "active bpc" which can be used by graphic drivers
to report the applied bit depth per pixel back to userspace.
While "max bpc" can be used to change the color depth, there was no way to check
which one actually got used. While in theory the driver chooses the best/highest
color depth within the max bpc setting a user might not be fully aware what his
hardware is or isn't capable off. This is meant as a quick way to double check
the setup.
In the future, automatic color calibration for screens might also depend on this
information available.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/drm_atomic_uapi.c | 2 ++
drivers/gpu/drm/drm_connector.c | 40 +++
include/drm/drm_connector.h | 15
3 files changed, 57 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 268bb69c2e2f..7ae4e40936b5 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -873,6 +873,8 @@ drm_atomic_connector_get_property(struct drm_connector
*connector,
*val = 0;
} else if (property == connector->max_bpc_property) {
*val = state->max_requested_bpc;
+ } else if (property == connector->active_bpc_property) {
+ *val = state->active_bpc;
} else if (connector->funcs->atomic_get_property) {
return connector->funcs->atomic_get_property(connector,
state, property, val);
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 7631f76e7f34..5f42a5be5822 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1195,6 +1195,13 @@ static const struct drm_prop_enum_list dp_colorspaces[]
= {
* drm_connector_attach_max_bpc_property() to create and attach the
* property to the connector during initialization.
*
+ * active bpc:
+ * This read-only range property is used by userspace check the bit depth
+ * actually applied by the GPU driver after evaluation all hardware
+ * capabilities and max bpc. Drivers to use the function
+ * drm_connector_attach_active_bpc_property() to create and attach the
+ * property to the connector during initialization.
+ *
* Connectors also have one standardized atomic property:
*
* CRTC_ID:
@@ -2150,6 +2157,39 @@ int drm_connector_attach_max_bpc_property(struct
drm_connector *connector,
}
EXPORT_SYMBOL(drm_connector_attach_max_bpc_property);
+/**
+ * drm_connector_attach_active_bpc_property - attach "active bpc" property
+ * @connector: connector to attach active bpc property on.
+ * @min: The minimum bit depth supported by the connector.
+ * @max: The maximum bit depth supported by the connector.
+ *
+ * This is used to check the applied bit depth on a connector.
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_connector_attach_active_bpc_property(struct drm_connector *connector,
+ int min, int max)
+{
+ struct drm_device *dev = connector->dev;
+ struct drm_property *prop;
+
+ prop = connector->active_bpc_property;
+ if (!prop) {
+ prop = drm_property_create_range(dev, 0, "active bpc", min,
max);
+ if (!prop)
+ return -ENOMEM;
+
+ connector->active_bpc_property = prop;
+ }
+
+ drm_object_attach_property(>base, prop, 0);
+ connector->state->active_bpc = 0;
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_connector_attach_active_bpc_property);
+
/**
* drm_connector_set_vrr_capable_property - sets the variable refresh rate
* capable property for a connector
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 1922b278ffad..c58cba2b6afe 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -781,6 +781,13 @@ struct drm_connector_state {
*/
u8 max_bpc;
+ /**
+* @active_bpc: Read only property set by the GPU driver to the actually
+* applied bit depth of the pixels after evaluating all hardware
+* limitations.
+*/
+ u8 active_bpc;
+
/**
* @hdr_output_metadata:
* DRM blob property for HDR output metadata
@@ -1380,6 +1387,12 @@ struct drm_connector {
*/
struct drm_property *max_bpc_property;
+ /**
+* @active_bpc_property: Default connector property for the active bpc
+* to be driven out of the connector.
+*/
+ struct drm_property *active_bpc_property;
+
#define DRM_CONNECTOR_POLL_HPD (1 << 0)
#define DRM_CONNECTOR_POLL_CONNECT (1 << 1)
#define DRM_CONNECTOR_POLL_DISCONNECT (1 << 2)
@@ -1698,6 +1711,8 @@ int drm_connector_set_panel_orientation_with_quirk(
int width, int height);
int drm_connector_attach_max_bpc_property(struct drm_connector *connector,
[PATCH 4/4] drm/i915/display: Add handling for new "active bpc" property
This commits implements the "active bpc" drm property for the Intel GPU driver.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/i915/display/intel_display.c | 13 +
drivers/gpu/drm/i915/display/intel_dp.c | 8 ++--
drivers/gpu/drm/i915/display/intel_dp_mst.c | 4 +++-
drivers/gpu/drm/i915/display/intel_hdmi.c| 4 +++-
4 files changed, 25 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 64e9107d70f7..f7898d9d7438 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -10164,6 +10164,8 @@ static void intel_atomic_commit_tail(struct
intel_atomic_state *state)
struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_crtc_state *new_crtc_state, *old_crtc_state;
struct intel_crtc *crtc;
+ struct drm_connector *connector;
+ struct drm_connector_state *new_conn_state;
u64 put_domains[I915_MAX_PIPES] = {};
intel_wakeref_t wakeref = 0;
int i;
@@ -10324,6 +10326,17 @@ static void intel_atomic_commit_tail(struct
intel_atomic_state *state)
}
intel_runtime_pm_put(_priv->runtime_pm, state->wakeref);
+ /* Extract information from crtc to communicate it to userspace as
connector properties */
+ for_each_new_connector_in_state(>base, connector,
new_conn_state, i) {
+ struct drm_crtc *crtc = new_conn_state->crtc;
+ if (crtc) {
+ new_crtc_state =
to_intel_crtc_state(drm_atomic_get_new_crtc_state(>base, crtc));
+ new_conn_state->active_bpc = new_crtc_state->pipe_bpp /
3;
+ }
+ else
+ new_conn_state->active_bpc = 0;
+ }
+
/*
* Defer the cleanup of the old state to a separate worker to not
* impede the current task (userspace for blocking modesets) that
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 642c60f3d9b1..67826ba976ed 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4671,10 +4671,14 @@ intel_dp_add_properties(struct intel_dp *intel_dp,
struct drm_connector *connect
intel_attach_force_audio_property(connector);
intel_attach_broadcast_rgb_property(connector);
- if (HAS_GMCH(dev_priv))
+ if (HAS_GMCH(dev_priv)) {
drm_connector_attach_max_bpc_property(connector, 6, 10);
- else if (DISPLAY_VER(dev_priv) >= 5)
+ drm_connector_attach_active_bpc_property(connector, 6, 10);
+ }
+ else if (DISPLAY_VER(dev_priv) >= 5) {
drm_connector_attach_max_bpc_property(connector, 6, 12);
+ drm_connector_attach_active_bpc_property(connector, 6, 12);
+ }
/* Register HDMI colorspace for case of lspcon */
if (intel_bios_is_lspcon_present(dev_priv, port)) {
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 2daa3f67791e..5a1869dc2210 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -844,8 +844,10 @@ static struct drm_connector
*intel_dp_add_mst_connector(struct drm_dp_mst_topolo
*/
connector->max_bpc_property =
intel_dp->attached_connector->base.max_bpc_property;
- if (connector->max_bpc_property)
+ if (connector->max_bpc_property) {
drm_connector_attach_max_bpc_property(connector, 6, 12);
+ drm_connector_attach_active_bpc_property(connector, 6, 12);
+ }
return connector;
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index d69f0a6dc26d..8af78b27b6ce 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -2463,8 +2463,10 @@ intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi,
struct drm_connector *c
drm_object_attach_property(>base,
connector->dev->mode_config.hdr_output_metadata_property, 0);
- if (!HAS_GMCH(dev_priv))
+ if (!HAS_GMCH(dev_priv)) {
drm_connector_attach_max_bpc_property(connector, 8, 12);
+ drm_connector_attach_active_bpc_property(connector, 8, 12);
+ }
}
/*
--
2.25.1
[PATCH 0/4] Add "activ bpc" drm property and use it in AMD and Intel driver
I started work on my proposal for better color handling in Linux display drivers: https://lkml.org/lkml/2021/5/12/764 Since the first read-only property is now implemented for amdgpu and i915 I wanted to collect some feedback, since the other two read-only properties will be quite similar, I hope. I have already commited the first patch in this series independently as it fixes a function already in use. The actuall update of the values is implemented in patch three and four in the atomic_commit_tail() function of amdgpu and i915 respectifly. It does get updated more often than needed with the current approach, but without harm since just the same value is written again. A check if the update is required would be the same amount of computation. Let me know if you know a better place to put the update than attomic_commit_tail().
Re: [Lima] LIMA kernel bug - help!
On Thu, Jun 3, 2021 at 11:51 PM Linus Walleij wrote: > > Hi Qiang, Hey Linus, > I am using Lima on the ST-Ericsson U8500 SoC. It is one > of the very earliest versions of MALI 400 MP. It mostly works > on the mobile phones I have using PostmarkeOS and > the Phosh UI (Wayland with MESA), but now I have an issue with > one single specimen. > > I have this bug in my dmesg and after this the graphics > start to act weird: > > [ 48.662336] lima a030.gpu: mmu page fault at 0x2020400 from bus > id 0 of type read on ppmmu0 > [ 48.662464] lima a030.gpu: fail to save task state from phoc > pid 1581: error task list is full > [ 48.662481] lima a030.gpu: pp task error 0 int_state=0 status=1 > [ 48.662494] lima a030.gpu: mmu resume It's not a kernel bug, GPU MMU just catched invalid memory access by fragment shader. It's likely a mesa bug. What mesa version do you use? > In interrupts: > > 75: 5 0 GIC-0 147 Level gp > 76: 0 0 GIC-0 146 Level gpmmu > 77: 3 0 GIC-0 145 Level pp0 > 78: 1 0 GIC-0 144 Level ppmmu0 > > My UI definitely want to render some more stuff so it gets > stuck here. It's stuck because context is marked as tainted and all the jobs that are submitted from this context afterwards are essentially no-op. > Any hints on how to troubleshoot this? Please make sure that you still can reproduce the bug with mesa from git main (ex-master), if it's still reproducible please open an issue at https://gitlab.freedesktop.org/mesa/mesa/issues Please also try to capture an apitrace of the failing app. See "Bug Reporting" on [1]. [1] https://docs.mesa3d.org/drivers/lima.html > Yours, > Linus Walleij > ___ > lima mailing list > l...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/lima
Re: [PATCH] Verify Gamma & Degamma LUT sizes in amdgpu_dm_atomic_check
Ignore this patch, in favor of (
https://patchwork.freedesktop.org/series/91023/), which appends the commit
title with drm/amd/display.
On Fri, Jun 4, 2021 at 12:59 PM Mark Yacoub wrote:
> From: Mark Yacoub
>
> For each CRTC state, check the size of Gamma and Degamma LUTs so
> unexpected and larger sizes wouldn't slip through.
>
> TEST: IGT:kms_color::pipe-invalid-gamma-lut-sizes
>
> Signed-off-by: Mark Yacoub
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 ++
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 1 +
> .../amd/display/amdgpu_dm/amdgpu_dm_color.c | 40 ---
> 3 files changed, 38 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 38d497d30dba8..f6cd522b42a80 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -9402,6 +9402,9 @@ static int amdgpu_dm_atomic_check(struct drm_device
> *dev,
> dm_old_crtc_state->dsc_force_changed == false)
> continue;
>
> + if ((ret = amdgpu_dm_verify_lut_sizes(new_crtc_state)))
> + goto fail;
> +
> if (!new_crtc_state->enable)
> continue;
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> index 8bfe901cf2374..1b77cd2612691 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
> @@ -541,6 +541,7 @@ void amdgpu_dm_trigger_timing_sync(struct drm_device
> *dev);
> #define MAX_COLOR_LEGACY_LUT_ENTRIES 256
>
> void amdgpu_dm_init_color_mod(void);
> +int amdgpu_dm_verify_lut_sizes(const struct drm_crtc_state *crtc_state);
> int amdgpu_dm_update_crtc_color_mgmt(struct dm_crtc_state *crtc);
> int amdgpu_dm_update_plane_color_mgmt(struct dm_crtc_state *crtc,
> struct dc_plane_state
> *dc_plane_state);
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
> index 157fe4efbb599..da6f9fcc0b415 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
> @@ -284,6 +284,37 @@ static int __set_input_tf(struct dc_transfer_func
> *func,
> return res ? 0 : -ENOMEM;
> }
>
> +/**
> + * Verifies that the Degamma and Gamma LUTs attached to the |crtc_state|
> are of
> + * the expected size.
> + * Returns 0 on success.
> + */
> +int amdgpu_dm_verify_lut_sizes(const struct drm_crtc_state *crtc_state)
> +{
> + const struct drm_color_lut *lut = NULL;
> + uint32_t size = 0;
> +
> + lut = __extract_blob_lut(crtc_state->degamma_lut, );
> + if (lut && size != MAX_COLOR_LUT_ENTRIES) {
> + DRM_DEBUG_DRIVER(
> + "Invalid Degamma LUT size. Should be %u but got
> %u.\n",
> + MAX_COLOR_LUT_ENTRIES, size);
> + return -EINVAL;
> + }
> +
> + lut = __extract_blob_lut(crtc_state->gamma_lut, );
> + if (lut && size != MAX_COLOR_LUT_ENTRIES &&
> + size != MAX_COLOR_LEGACY_LUT_ENTRIES) {
> + DRM_DEBUG_DRIVER(
> + "Invalid Gamma LUT size. Should be %u (or %u for
> legacy) but got %u.\n",
> + MAX_COLOR_LUT_ENTRIES,
> MAX_COLOR_LEGACY_LUT_ENTRIES,
> + size);
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> /**
> * amdgpu_dm_update_crtc_color_mgmt: Maps DRM color management to DC
> stream.
> * @crtc: amdgpu_dm crtc state
> @@ -317,14 +348,11 @@ int amdgpu_dm_update_crtc_color_mgmt(struct
> dm_crtc_state *crtc)
> bool is_legacy;
> int r;
>
> - degamma_lut = __extract_blob_lut(crtc->base.degamma_lut,
> _size);
> - if (degamma_lut && degamma_size != MAX_COLOR_LUT_ENTRIES)
> - return -EINVAL;
> + if ((r = amdgpu_dm_verify_lut_sizes(>base)))
> + return r;
>
> + degamma_lut = __extract_blob_lut(crtc->base.degamma_lut,
> _size);
> regamma_lut = __extract_blob_lut(crtc->base.gamma_lut,
> _size);
> - if (regamma_lut && regamma_size != MAX_COLOR_LUT_ENTRIES &&
> - regamma_size != MAX_COLOR_LEGACY_LUT_ENTRIES)
> - return -EINVAL;
>
> has_degamma =
> degamma_lut && !__is_lut_linear(degamma_lut, degamma_size);
> --
> 2.32.0.rc1.229.g3e70b5a671-goog
>
>
[PATCH] drm/amd/display: Verify Gamma & Degamma LUT sizes in amdgpu_dm_atomic_check
From: Mark Yacoub
For each CRTC state, check the size of Gamma and Degamma LUTs so
unexpected and larger sizes wouldn't slip through.
TEST: IGT:kms_color::pipe-invalid-gamma-lut-sizes
Signed-off-by: Mark Yacoub
Change-Id: I9d513a38e8ac2af1b4bf802e1feb1a4d726fba4c
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 ++
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 1 +
.../amd/display/amdgpu_dm/amdgpu_dm_color.c | 40 ---
3 files changed, 38 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 38d497d30dba8..f6cd522b42a80 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -9402,6 +9402,9 @@ static int amdgpu_dm_atomic_check(struct drm_device *dev,
dm_old_crtc_state->dsc_force_changed == false)
continue;
+ if ((ret = amdgpu_dm_verify_lut_sizes(new_crtc_state)))
+ goto fail;
+
if (!new_crtc_state->enable)
continue;
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
index 8bfe901cf2374..1b77cd2612691 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
@@ -541,6 +541,7 @@ void amdgpu_dm_trigger_timing_sync(struct drm_device *dev);
#define MAX_COLOR_LEGACY_LUT_ENTRIES 256
void amdgpu_dm_init_color_mod(void);
+int amdgpu_dm_verify_lut_sizes(const struct drm_crtc_state *crtc_state);
int amdgpu_dm_update_crtc_color_mgmt(struct dm_crtc_state *crtc);
int amdgpu_dm_update_plane_color_mgmt(struct dm_crtc_state *crtc,
struct dc_plane_state *dc_plane_state);
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
index 157fe4efbb599..da6f9fcc0b415 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
@@ -284,6 +284,37 @@ static int __set_input_tf(struct dc_transfer_func *func,
return res ? 0 : -ENOMEM;
}
+/**
+ * Verifies that the Degamma and Gamma LUTs attached to the |crtc_state| are of
+ * the expected size.
+ * Returns 0 on success.
+ */
+int amdgpu_dm_verify_lut_sizes(const struct drm_crtc_state *crtc_state)
+{
+ const struct drm_color_lut *lut = NULL;
+ uint32_t size = 0;
+
+ lut = __extract_blob_lut(crtc_state->degamma_lut, );
+ if (lut && size != MAX_COLOR_LUT_ENTRIES) {
+ DRM_DEBUG_DRIVER(
+ "Invalid Degamma LUT size. Should be %u but got %u.\n",
+ MAX_COLOR_LUT_ENTRIES, size);
+ return -EINVAL;
+ }
+
+ lut = __extract_blob_lut(crtc_state->gamma_lut, );
+ if (lut && size != MAX_COLOR_LUT_ENTRIES &&
+ size != MAX_COLOR_LEGACY_LUT_ENTRIES) {
+ DRM_DEBUG_DRIVER(
+ "Invalid Gamma LUT size. Should be %u (or %u for
legacy) but got %u.\n",
+ MAX_COLOR_LUT_ENTRIES, MAX_COLOR_LEGACY_LUT_ENTRIES,
+ size);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
/**
* amdgpu_dm_update_crtc_color_mgmt: Maps DRM color management to DC stream.
* @crtc: amdgpu_dm crtc state
@@ -317,14 +348,11 @@ int amdgpu_dm_update_crtc_color_mgmt(struct dm_crtc_state
*crtc)
bool is_legacy;
int r;
- degamma_lut = __extract_blob_lut(crtc->base.degamma_lut, _size);
- if (degamma_lut && degamma_size != MAX_COLOR_LUT_ENTRIES)
- return -EINVAL;
+ if ((r = amdgpu_dm_verify_lut_sizes(>base)))
+ return r;
+ degamma_lut = __extract_blob_lut(crtc->base.degamma_lut, _size);
regamma_lut = __extract_blob_lut(crtc->base.gamma_lut, _size);
- if (regamma_lut && regamma_size != MAX_COLOR_LUT_ENTRIES &&
- regamma_size != MAX_COLOR_LEGACY_LUT_ENTRIES)
- return -EINVAL;
has_degamma =
degamma_lut && !__is_lut_linear(degamma_lut, degamma_size);
--
2.32.0.rc1.229.g3e70b5a671-goog
[PATCH] Verify Gamma & Degamma LUT sizes in amdgpu_dm_atomic_check
From: Mark Yacoub
For each CRTC state, check the size of Gamma and Degamma LUTs so
unexpected and larger sizes wouldn't slip through.
TEST: IGT:kms_color::pipe-invalid-gamma-lut-sizes
Signed-off-by: Mark Yacoub
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 ++
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 1 +
.../amd/display/amdgpu_dm/amdgpu_dm_color.c | 40 ---
3 files changed, 38 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 38d497d30dba8..f6cd522b42a80 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -9402,6 +9402,9 @@ static int amdgpu_dm_atomic_check(struct drm_device *dev,
dm_old_crtc_state->dsc_force_changed == false)
continue;
+ if ((ret = amdgpu_dm_verify_lut_sizes(new_crtc_state)))
+ goto fail;
+
if (!new_crtc_state->enable)
continue;
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
index 8bfe901cf2374..1b77cd2612691 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
@@ -541,6 +541,7 @@ void amdgpu_dm_trigger_timing_sync(struct drm_device *dev);
#define MAX_COLOR_LEGACY_LUT_ENTRIES 256
void amdgpu_dm_init_color_mod(void);
+int amdgpu_dm_verify_lut_sizes(const struct drm_crtc_state *crtc_state);
int amdgpu_dm_update_crtc_color_mgmt(struct dm_crtc_state *crtc);
int amdgpu_dm_update_plane_color_mgmt(struct dm_crtc_state *crtc,
struct dc_plane_state *dc_plane_state);
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
index 157fe4efbb599..da6f9fcc0b415 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
@@ -284,6 +284,37 @@ static int __set_input_tf(struct dc_transfer_func *func,
return res ? 0 : -ENOMEM;
}
+/**
+ * Verifies that the Degamma and Gamma LUTs attached to the |crtc_state| are of
+ * the expected size.
+ * Returns 0 on success.
+ */
+int amdgpu_dm_verify_lut_sizes(const struct drm_crtc_state *crtc_state)
+{
+ const struct drm_color_lut *lut = NULL;
+ uint32_t size = 0;
+
+ lut = __extract_blob_lut(crtc_state->degamma_lut, );
+ if (lut && size != MAX_COLOR_LUT_ENTRIES) {
+ DRM_DEBUG_DRIVER(
+ "Invalid Degamma LUT size. Should be %u but got %u.\n",
+ MAX_COLOR_LUT_ENTRIES, size);
+ return -EINVAL;
+ }
+
+ lut = __extract_blob_lut(crtc_state->gamma_lut, );
+ if (lut && size != MAX_COLOR_LUT_ENTRIES &&
+ size != MAX_COLOR_LEGACY_LUT_ENTRIES) {
+ DRM_DEBUG_DRIVER(
+ "Invalid Gamma LUT size. Should be %u (or %u for
legacy) but got %u.\n",
+ MAX_COLOR_LUT_ENTRIES, MAX_COLOR_LEGACY_LUT_ENTRIES,
+ size);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
/**
* amdgpu_dm_update_crtc_color_mgmt: Maps DRM color management to DC stream.
* @crtc: amdgpu_dm crtc state
@@ -317,14 +348,11 @@ int amdgpu_dm_update_crtc_color_mgmt(struct dm_crtc_state
*crtc)
bool is_legacy;
int r;
- degamma_lut = __extract_blob_lut(crtc->base.degamma_lut, _size);
- if (degamma_lut && degamma_size != MAX_COLOR_LUT_ENTRIES)
- return -EINVAL;
+ if ((r = amdgpu_dm_verify_lut_sizes(>base)))
+ return r;
+ degamma_lut = __extract_blob_lut(crtc->base.degamma_lut, _size);
regamma_lut = __extract_blob_lut(crtc->base.gamma_lut, _size);
- if (regamma_lut && regamma_size != MAX_COLOR_LUT_ENTRIES &&
- regamma_size != MAX_COLOR_LEGACY_LUT_ENTRIES)
- return -EINVAL;
has_degamma =
degamma_lut && !__is_lut_linear(degamma_lut, degamma_size);
--
2.32.0.rc1.229.g3e70b5a671-goog
Re: [PATCH] drm: amdgpu: Remove unneeded semicolon in amdgpu_vm.c
Applied. Thanks! Alex On Fri, Jun 4, 2021 at 3:03 AM Christian König wrote: > > Am 03.06.21 um 05:28 schrieb Wan Jiabing: > > Fix following coccicheck warning: > > ./drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:1726:2-3: Unneeded semicolon > > > > Signed-off-by: Wan Jiabing > > Reviewed-by: Christian König > > > --- > > drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c > > index 2460371..231745b 100644 > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c > > @@ -1723,7 +1723,7 @@ int amdgpu_vm_bo_update_mapping(struct amdgpu_device > > *adev, > > > > amdgpu_res_next(, num_entries * AMDGPU_GPU_PAGE_SIZE); > > start = tmp; > > - }; > > + } > > > > r = vm->update_funcs->commit(, fence); > > >
Re: [PATCH][next] drm/amd/pm: Fix fall-through warning for Clang
Applied. Thanks! Alex On Fri, Jun 4, 2021 at 1:05 AM Gustavo A. R. Silva wrote: > > In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning > by explicitly adding a break statement instead of letting the code fall > through to the next case. > > Link: https://github.com/KSPP/linux/issues/115 > Signed-off-by: Gustavo A. R. Silva > --- > JFYI: We had thousands of these sorts of warnings and now we are down > to just 22 in linux-next. This is one of those last remaining > warnings. :) > > drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.c > b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.c > index 8f71f6a4bb49..43c3f6e755e7 100644 > --- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.c > +++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.c > @@ -831,6 +831,7 @@ static int smu10_dpm_force_dpm_level(struct pp_hwmgr > *hwmgr, > break; > case AMD_DPM_FORCED_LEVEL_MANUAL: > data->fine_grain_enabled = 1; > + break; > case AMD_DPM_FORCED_LEVEL_PROFILE_EXIT: > default: > break; > -- > 2.27.0 >
Re: [PATCH v4] drm/panfrost: Add AFBC_FEATURES parameter
> Repeated word ;) But I've fixed that up and pushed it to drm-misc-next. Whoops! Thanks. Next up would be v2 of the cycle counter series, which means adding timestamp queries to the GL driver so I can test new UABI for a TIMESTAMP parameter...
Re: [Freedreno] [PATCH] drm/msm/dsi: print error code when MIPI DSI host registration fails
On 2021-06-04 03:44, Dmitry Baryshkov wrote:
In order to ease debugging of DSI host registration issues, print
return
code of dsi_mgr_setup_components().
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/dsi/dsi_manager.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c
b/drivers/gpu/drm/msm/dsi/dsi_manager.c
index cd016576e8c5..4df5defdbf4c 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_manager.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c
@@ -817,8 +817,8 @@ int msm_dsi_manager_register(struct msm_dsi
*msm_dsi)
ret = dsi_mgr_setup_components(id);
if (ret) {
- pr_err("%s: failed to register mipi dsi host for DSI %d\n",
- __func__, id);
+ pr_err("%s: failed to register mipi dsi host for DSI %d: %d\n",
+ __func__, id, ret);
goto fail;
}
Re: [PATCH] dma-buf: add missing EXPORT_SYMBOL
Reviewed-by: Jason Ekstrand On Fri, Jun 4, 2021 at 10:59 AM Alex Deucher wrote: > > On Fri, Jun 4, 2021 at 11:52 AM Christian König > wrote: > > > > The newly added dma_resv_reset_shared_max() is used from an inline > > function, so it can appear in drivers as well. > > > > Signed-off-by: Christian König > > Acked-by: Alex Deucher > > > --- > > drivers/dma-buf/dma-resv.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c > > index 3964df438505..6132ba631991 100644 > > --- a/drivers/dma-buf/dma-resv.c > > +++ b/drivers/dma-buf/dma-resv.c > > @@ -226,6 +226,7 @@ void dma_resv_reset_shared_max(struct dma_resv *obj) > > fence->shared_max = fence->shared_count; > > } > > } > > +EXPORT_SYMBOL(dma_resv_reset_shared_max); > > #endif > > > > /** > > -- > > 2.25.1 > >
Re: [PATCH v8 07/11] drm/panel: panel-simple: Stash DP AUX bus; allow using it for DDC
Hi Doug,
panel->no_hpd = of_property_read_bool(dev->of_node, "no-hpd");
if (!panel->no_hpd) {
@@ -708,6 +712,8 @@ static int panel_simple_probe(struct device *dev,
const struct panel_desc *desc)
if (!panel->ddc)
return -EPROBE_DEFER;
+ } else if (aux) {
+ panel->ddc = >ddc;
}
In panel_simple_probe(), the put_device(>ddc->dev) call is
causing issue when the aux->ddc is used to assign panel->ddc
It works well when "ddc-i2c-bus" is used to assign panel->ddc
static int panel_simple_probe(...)
{
...
free_ddc:
if (panel->ddc)
put_device(>ddc->dev);
return err;
}
== Log start ==
[2.393970] [ cut here ]
[2.398747] kobject: '(null)' ((ptrval)): is not initialized,
yet kobject_put() is being called.
[2.408554] WARNING: CPU: 7 PID: 7 at lib/kobject.c:752
kobject_put+0x38/0xe0
...
...
[2.528574] Call trace:
[2.531092] kobject_put+0x38/0xe0
[2.534594] put_device+0x20/0x2c
[2.538002] panel_simple_probe+0x4bc/0x550
[2.542300] panel_simple_dp_aux_ep_probe+0x44/0x5c
[2.547305] dp_aux_ep_probe+0x58/0x80
== Log end ==
Sincerely,
Rajeev
Re: [PATCH] dma-buf: add missing EXPORT_SYMBOL
On Fri, Jun 4, 2021 at 11:52 AM Christian König wrote: > > The newly added dma_resv_reset_shared_max() is used from an inline > function, so it can appear in drivers as well. > > Signed-off-by: Christian König Acked-by: Alex Deucher > --- > drivers/dma-buf/dma-resv.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c > index 3964df438505..6132ba631991 100644 > --- a/drivers/dma-buf/dma-resv.c > +++ b/drivers/dma-buf/dma-resv.c > @@ -226,6 +226,7 @@ void dma_resv_reset_shared_max(struct dma_resv *obj) > fence->shared_max = fence->shared_count; > } > } > +EXPORT_SYMBOL(dma_resv_reset_shared_max); > #endif > > /** > -- > 2.25.1 >
Re: [PATCH v4] drm/i915: Invoke another _DSM to enable MUX on HP Workstation laptops
On Thu, May 20, 2021 at 2:58 PM Kai-Heng Feng
wrote:
>
> On HP Fury G7 Workstations, graphics output is re-routed from Intel GFX
> to discrete GFX after S3. This is not desirable, because userspace will
> treat connected display as a new one, losing display settings.
>
> The expected behavior is to let discrete GFX drives all external
> displays.
>
> The platform in question uses ACPI method \_SB.PCI0.HGME to enable MUX.
> The method is inside the another _DSM, so add the _DSM and call it
> accordingly.
>
> I also tested some MUX-less and iGPU only laptops with that _DSM, no
> regression was found.
>
> v4:
> - Rebase.
> - Change the DSM name to avoid confusion.
> - Move the function call to intel_opregion.
>
> v3:
> - Remove BXT from names.
> - Change the parameter type.
> - Fold the function into intel_modeset_init_hw().
>
> v2:
> - Forward declare struct pci_dev.
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3113
> References:
> https://lore.kernel.org/intel-gfx/1460040732-31417-4-git-send-email-animesh.ma...@intel.com/
> Signed-off-by: Kai-Heng Feng
A gentle ping...
> ---
> drivers/gpu/drm/i915/display/intel_acpi.c | 19 +++
> drivers/gpu/drm/i915/display/intel_acpi.h | 3 +++
> drivers/gpu/drm/i915/display/intel_opregion.c | 3 +++
> 3 files changed, 25 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_acpi.c
> b/drivers/gpu/drm/i915/display/intel_acpi.c
> index 833d0c1be4f1..7cfe91fc05f2 100644
> --- a/drivers/gpu/drm/i915/display/intel_acpi.c
> +++ b/drivers/gpu/drm/i915/display/intel_acpi.c
> @@ -19,6 +19,12 @@ static const guid_t intel_dsm_guid =
> GUID_INIT(0x7ed873d3, 0xc2d0, 0x4e4f,
> 0xa8, 0x54, 0x0f, 0x13, 0x17, 0xb0, 0x1c, 0x2c);
>
> +#define INTEL_DSM_FN_GET_BIOS_DATA_FUNCS_SUPPORTED 0 /* No args */
> +
> +static const guid_t intel_dsm_guid2 =
> + GUID_INIT(0x3e5b41c6, 0xeb1d, 0x4260,
> + 0x9d, 0x15, 0xc7, 0x1f, 0xba, 0xda, 0xe4, 0x14);
> +
> static char *intel_dsm_port_name(u8 id)
> {
> switch (id) {
> @@ -176,6 +182,19 @@ void intel_unregister_dsm_handler(void)
> {
> }
>
> +void intel_dsm_get_bios_data_funcs_supported(struct drm_i915_private *i915)
> +{
> + struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
> + acpi_handle dhandle;
> +
> + dhandle = ACPI_HANDLE(>dev);
> + if (!dhandle)
> + return;
> +
> + acpi_evaluate_dsm(dhandle, _dsm_guid2, INTEL_DSM_REVISION_ID,
> + INTEL_DSM_FN_GET_BIOS_DATA_FUNCS_SUPPORTED, NULL);
> +}
> +
> /*
> * ACPI Specification, Revision 5.0, Appendix B.3.2 _DOD (Enumerate All
> Devices
> * Attached to the Display Adapter).
> diff --git a/drivers/gpu/drm/i915/display/intel_acpi.h
> b/drivers/gpu/drm/i915/display/intel_acpi.h
> index e8b068661d22..9f197401c313 100644
> --- a/drivers/gpu/drm/i915/display/intel_acpi.h
> +++ b/drivers/gpu/drm/i915/display/intel_acpi.h
> @@ -11,11 +11,14 @@ struct drm_i915_private;
> #ifdef CONFIG_ACPI
> void intel_register_dsm_handler(void);
> void intel_unregister_dsm_handler(void);
> +void intel_dsm_get_bios_data_funcs_supported(struct drm_i915_private *i915);
> void intel_acpi_device_id_update(struct drm_i915_private *i915);
> #else
> static inline void intel_register_dsm_handler(void) { return; }
> static inline void intel_unregister_dsm_handler(void) { return; }
> static inline
> +void intel_dsm_get_bios_data_funcs_supported(struct drm_i915_private *i915)
> { return; }
> +static inline
> void intel_acpi_device_id_update(struct drm_i915_private *i915) { return; }
> #endif /* CONFIG_ACPI */
>
> diff --git a/drivers/gpu/drm/i915/display/intel_opregion.c
> b/drivers/gpu/drm/i915/display/intel_opregion.c
> index dfd724e506b5..3855fba70980 100644
> --- a/drivers/gpu/drm/i915/display/intel_opregion.c
> +++ b/drivers/gpu/drm/i915/display/intel_opregion.c
> @@ -1078,6 +1078,9 @@ void intel_opregion_resume(struct drm_i915_private
> *i915)
> opregion->asle->ardy = ASLE_ARDY_READY;
> }
>
> + /* Some platforms abuse the _DSM to enable MUX */
> + intel_dsm_get_bios_data_funcs_supported(i915);
> +
> intel_opregion_notify_adapter(i915, PCI_D0);
> }
>
> --
> 2.31.1
>
Re: [PATCH] drm/i915: only disable default vga device
On Fri, 4 Jun 2021 at 15:08, Ville Syrjälä wrote: > > On Fri, Jun 04, 2021 at 02:47:16PM +0100, Emil Velikov wrote: > > On Wed, 26 May 2021 at 17:21, Emil Velikov wrote: > > > > > > Hi Ville, > > > > > > On Tue, 18 May 2021 at 12:17, Ville Syrjälä > > > wrote: > > > > > > > > On Tue, May 18, 2021 at 12:09:56PM +0100, Emil Velikov wrote: > > > > > Hi Ville, > > > > > > > > > > On Mon, 17 May 2021 at 18:24, Ville Syrjälä > > > > > wrote: > > > > > > > > > > > > On Sun, May 16, 2021 at 06:14:32PM +0100, Emil Velikov wrote: > > > > > > > From: Vivek Das Mohapatra > > > > > > > > > > > > > > This patch is to do with seamless handover, eg when the sequence > > > > > > > is > > > > > > > bootloader → plymouth → desktop. > > > > > > > > > > > > > > It switches the vga arbiter from the "other" GPU to the default > > > > > > > one > > > > > > > (intel in this case), so the driver can issue some io(). > > > > > > > > > > > > I don't understand what this commit message is trying to say. > > > > > > > > > > > Bunch of context is lost due to the patch age, so I'm not 100% sure of > > > > > the actual hardware setup where this occurs. > > > > > Does the following make sense? > > > > > > > > > > Currently on dual GPU systems, we do not get seamless handover as the > > > > > output flickers during the transition bootloader -> plymouth -> > > > > > desktop. > > > > > This happens as a result of switching (via the VGA arbiter) from the > > > > > "other" GPU back to the default i915 one and issuing io() commands. > > > > > > > > Hmm. Does this work? > > > > > > > > --- a/drivers/gpu/drm/i915/display/intel_vga.c > > > > +++ b/drivers/gpu/drm/i915/display/intel_vga.c > > > > @@ -29,6 +29,9 @@ void intel_vga_disable(struct drm_i915_private > > > > *dev_priv) > > > > i915_reg_t vga_reg = intel_vga_cntrl_reg(dev_priv); > > > > u8 sr1; > > > > > > > > + if (intel_de_read(dev_priv, vga_reg) & VGA_DISP_DISABLE) > > > > + return; > > > > + > > > > /* WaEnableVGAAccessThroughIOPort:ctg,elk,ilk,snb,ivb,vlv,hsw */ > > > > vga_get_uninterruptible(pdev, VGA_RSRC_LEGACY_IO); > > > > outb(SR01, VGA_SR_INDEX); > > > > > > > Was able to replicate the issue somewhat and the above does help quite a > > > lot. > > > Feel free to add my: > > > Reviewed-by: Emil Velikov > > > Tested-by: Emil Velikov > > > > > Humble poke. > > > > Cannot see this patch in the drm-misc or drm-intel trees. Is there > > anything I do to help move it forward? > > Can you just respin the patch with this? > I've used your suggestion and redone the commit message completely. Hope it's far less cryptic now. Patch is on the ML - realised I didn't CC you, just as it went out. https://lore.kernel.org/dri-devel/20210604154905.660142-1-emil.l.veli...@gmail.com/T/#u Thanks -Emil
[PATCH] dma-buf: add missing EXPORT_SYMBOL
The newly added dma_resv_reset_shared_max() is used from an inline function, so it can appear in drivers as well. Signed-off-by: Christian König --- drivers/dma-buf/dma-resv.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c index 3964df438505..6132ba631991 100644 --- a/drivers/dma-buf/dma-resv.c +++ b/drivers/dma-buf/dma-resv.c @@ -226,6 +226,7 @@ void dma_resv_reset_shared_max(struct dma_resv *obj) fence->shared_max = fence->shared_count; } } +EXPORT_SYMBOL(dma_resv_reset_shared_max); #endif /** -- 2.25.1
[PATCH] drm/i915: apply WaEnableVGAAccessThroughIOPort as needed
From: Emil Velikov Currently as the workaround is applied the screen flickers. As a result we do not achieve seamless boot experience. Avoiding the issue in the common use-case might be hard, although we can resolve it for dual GPU setups - when the "other" GPU is primary and/or outputs are connected to it. With this I was able to get seamless experience on my Intel/Nvidia box, running systemd-boot and sddm/Xorg. Note that the i915 driver is within initrd while the Nvidia one is not. Without this patch, the splash presented by systemd-boot (UEFI BGRT) is torn down as the code-path kicks in, leaving the monitor blank until the login manager starts. Same issue were reported with plymouth/grub, although personally I wasn't able to get them to behave on my setup. Suggested-by: Ville Syrjälä Signed-off-by: Emil Velikov --- Supersedes https://lore.kernel.org/dri-devel/20210516171432.1734268-1-emil.l.veli...@gmail.com/ Ville, others, Patch is based against drm-intel/drm-intel-next and will apply cleanly against drm-intel/drm-intel-fixes. If possible, can one of the i915 maintainers apply it to the latter? Thanks Emil --- drivers/gpu/drm/i915/display/intel_vga.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_vga.c b/drivers/gpu/drm/i915/display/intel_vga.c index be333699c515..7beef1206097 100644 --- a/drivers/gpu/drm/i915/display/intel_vga.c +++ b/drivers/gpu/drm/i915/display/intel_vga.c @@ -29,6 +29,9 @@ void intel_vga_disable(struct drm_i915_private *dev_priv) i915_reg_t vga_reg = intel_vga_cntrl_reg(dev_priv); u8 sr1; + if (intel_de_read(dev_priv, vga_reg) & VGA_DISP_DISABLE) + return; + /* WaEnableVGAAccessThroughIOPort:ctg,elk,ilk,snb,ivb,vlv,hsw */ vga_get_uninterruptible(pdev, VGA_RSRC_LEGACY_IO); outb(SR01, VGA_SR_INDEX); -- 2.31.1
Re: [PATCH 01/21] drm: Add Enhanced Gamma and color lut range attributes
On 2021-06-02 4:26 p.m., Shankar, Uma wrote:
>
>
>> -Original Message-
>> From: Pekka Paalanen
>> Sent: Wednesday, June 2, 2021 3:04 PM
>> To: Shankar, Uma
>> Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Modem,
>> Bhanuprakash
>> Subject: Re: [PATCH 01/21] drm: Add Enhanced Gamma and color lut range
>> attributes
>>
>> On Tue, 1 Jun 2021 16:21:58 +0530
>> Uma Shankar wrote:
>>
>>> Existing LUT precision structure is having only 16 bit precision. This
>>> is not enough for upcoming enhanced hardwares and advance usecases
>>> like HDR processing. Hence added a new structure with 32 bit precision
>>> values.
>>>
>>> This also defines a new structure to define color lut ranges, along
>>> with related macro definitions and enums. This will help describe
>>> multi segmented lut ranges in the hardware.
>>>
>>> Signed-off-by: Uma Shankar
>>> ---
>>> include/uapi/drm/drm_mode.h | 58
>>> +
>>> 1 file changed, 58 insertions(+)
>>>
>>> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
>>> index 9b6722d45f36..d0ce48d2e732 100644
>>> --- a/include/uapi/drm/drm_mode.h
>>> +++ b/include/uapi/drm/drm_mode.h
>>> @@ -819,6 +819,64 @@ struct hdr_output_metadata {
>>> };
>>> };
>>>
>>> +/*
>>> + * DRM_MODE_LUT_GAMMA|DRM_MODE_LUT_DEGAMMA is legal and means
>> the LUT
>>> + * can be used for either purpose, but not simultaneously. To expose
>>> + * modes that support gamma and degamma simultaneously the gamma mode
>>> + * must declare distinct DRM_MODE_LUT_GAMMA and
>> DRM_MODE_LUT_DEGAMMA
>>> + * ranges.
>>> + */
>>> +/* LUT is for gamma (after CTM) */
>>> +#define DRM_MODE_LUT_GAMMA BIT(0)
>>> +/* LUT is for degamma (before CTM) */ #define DRM_MODE_LUT_DEGAMMA
>>> +BIT(1)
>>> +/* linearly interpolate between the points */ #define
>>> +DRM_MODE_LUT_INTERPOLATE BIT(2)
>>> +/*
>>> + * the last value of the previous range is the
>>> + * first value of the current range.
>>> + */
>>> +#define DRM_MODE_LUT_REUSE_LAST BIT(3)
>>> +/* the curve must be non-decreasing */ #define
>>> +DRM_MODE_LUT_NON_DECREASING BIT(4)
>>> +/* the curve is reflected across origin for negative inputs */
>>> +#define DRM_MODE_LUT_REFLECT_NEGATIVE BIT(5)
>>> +/* the same curve (red) is used for blue and green channels as well
>>> +*/ #define DRM_MODE_LUT_SINGLE_CHANNEL BIT(6)
>>> +
>>> +struct drm_color_lut_range {
>>> + /* DRM_MODE_LUT_* */
>>> + __u32 flags;
>>> + /* number of points on the curve */
>>> + __u16 count;
>>> + /* input/output bits per component */
>>> + __u8 input_bpc, output_bpc;
>>> + /* input start/end values */
>>> + __s32 start, end;
>>> + /* output min/max values */
>>> + __s32 min, max;
>>> +};
>>> +
>>> +enum lut_type {
>>
>> Unprefixed type name in UAPI headers is probably not a good idea.
>
> Ok, will rename these.
>
>>> + LUT_TYPE_DEGAMMA = 0,
>>> + LUT_TYPE_GAMMA = 1,
>>> +};
>>
>> All the above stuff seems to be the same in your other patch series'
>> patch "[PATCH 1/9] drm: Add gamma mode property". Is this series replacing
>> the
>> series "[PATCH 0/9] Enhance pipe color support for multi segmented luts" or
>> what
>> does this mean?
>
> The concept and idea is similar and the range definition is also common. But
> this series
> focuses on plane color management while the other one is for pipe/crtc color
> features.
> Hence separated and floated them as unique series for review.
>
Might be better in this case to combine both patchsets. It wasn't entirely
clear to
me whether I could base one patchset on top of the other (doesn't look like it)
and
what base to apply them on. I had success applying the plane stuff on drm-next
and
the crtc stuff on drm-intel.
Harry
> Regards,
> Uma Shankar
>>
>> Thanks,
>> pq
>>
>>> +
>>> +/*
>>> + * Creating 64 bit palette entries for better data
>>> + * precision. This will be required for HDR and
>>> + * similar color processing usecases.
>>> + */
>>> +struct drm_color_lut_ext {
>>> + /*
>>> +* Data is U32.32 fixed point format.
>>> +*/
>>> + __u64 red;
>>> + __u64 green;
>>> + __u64 blue;
>>> + __u64 reserved;
>>> +};
>>> +
>>> #define DRM_MODE_PAGE_FLIP_EVENT 0x01 #define
>>> DRM_MODE_PAGE_FLIP_ASYNC 0x02 #define
>>> DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE 0x4
>
Re: [PATCH v9 07/10] mm: Device exclusive memory access
On Fri, Jun 04, 2021 at 11:07:42AM +1000, Alistair Popple wrote:
> On Friday, 4 June 2021 12:47:40 AM AEST Peter Xu wrote:
> > External email: Use caution opening links or attachments
> >
> > On Thu, Jun 03, 2021 at 09:39:32PM +1000, Alistair Popple wrote:
> > > Reclaim won't run on the page due to the extra references from the special
> > > swap entries.
> >
> > That sounds reasonable, but I didn't find the point that stops it, probably
> > due to my limited knowledge on the reclaim code. Could you elaborate?
>
> Sure, it isn't immediately obvious but it ends up being detected at the start
> of is_page_cache_freeable() in the pageout code:
>
>
> static pageout_t pageout(struct page *page, struct address_space *mapping)
> {
>
> [...]
>
> if (!is_page_cache_freeable(page))
> return PAGE_KEEP;
I did look at pageout() but still missed this small helper indeed (while it's
so important to know..), thanks!
--
Peter Xu
Re: [PATCH v4] drm/panfrost: Add AFBC_FEATURES parameter
On 04/06/2021 14:00, Alyssa Rosenzweig wrote:
> The value of the AFBC_FEATURES register is required by userspace to
> determine AFBC support on Bifrost. A user on our IRC channel (#panfrost)
> reported a workload that raised a fault on one system's Mali G31 but
> worked flawlessly with another system's Mali G31. We determined the
> cause to be missing AFBC support on one vendor's Mali implementation --
> it turns out AFBC is optional on Bifrost!
>
> Whether AFBC is supported or not is exposed in the AFBC_FEATURES
> register on Bifrost, which reads back as 0 on Midgard. A zero value
> indicates AFBC is fully supported, provided the architecture itself
> supports AFBC, allowing backwards-compatibility with Midgard. Bits 0 and
> 15 indicate that AFBC support is absent for texturing and rendering
> respectively.
>
> The user experiencing the fault reports that AFBC_FEATURES reads back
> 0x10001 on their system, confirming the architectural lack of AFBC.
> Userspace needs this this parameter to know to disable AFBC on that
^
Repeated word ;) But I've fixed that up and pushed it to drm-misc-next.
Thanks,
Steve
> chip, and perhaps others.
>
> v2: Fix typo from copy-paste fail.
>
> v3: Bump the UABI version. This commit was cherry-picked from another
> series so chalking this up to a rebase fail.
>
> Signed-off-by: Alyssa Rosenzweig
> Reviewed-by: Steven Price
> Cc: Rob Herring
> Cc: Tomeu Vizoso
> ---
> drivers/gpu/drm/panfrost/panfrost_device.h | 1 +
> drivers/gpu/drm/panfrost/panfrost_drv.c| 4 +++-
> drivers/gpu/drm/panfrost/panfrost_gpu.c| 1 +
> drivers/gpu/drm/panfrost/panfrost_regs.h | 1 +
> include/uapi/drm/panfrost_drm.h| 1 +
> 5 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_device.h
> b/drivers/gpu/drm/panfrost/panfrost_device.h
> index 597cf1459..f614e9877 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_device.h
> +++ b/drivers/gpu/drm/panfrost/panfrost_device.h
> @@ -45,6 +45,7 @@ struct panfrost_features {
> u32 thread_max_workgroup_sz;
> u32 thread_max_barrier_sz;
> u32 coherency_features;
> + u32 afbc_features;
> u32 texture_features[4];
> u32 js_features[16];
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
> b/drivers/gpu/drm/panfrost/panfrost_drv.c
> index ca07098a6..1596559f3 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_drv.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
> @@ -63,6 +63,7 @@ static int panfrost_ioctl_get_param(struct drm_device
> *ddev, void *data, struct
> PANFROST_FEATURE(THREAD_MAX_BARRIER_SZ,
> thread_max_barrier_sz);
> PANFROST_FEATURE(COHERENCY_FEATURES, coherency_features);
> + PANFROST_FEATURE(AFBC_FEATURES, afbc_features);
> PANFROST_FEATURE_ARRAY(TEXTURE_FEATURES, texture_features, 3);
> PANFROST_FEATURE_ARRAY(JS_FEATURES, js_features, 15);
> PANFROST_FEATURE(NR_CORE_GROUPS, nr_core_groups);
> @@ -547,6 +548,7 @@ DEFINE_DRM_GEM_FOPS(panfrost_drm_driver_fops);
> * Panfrost driver version:
> * - 1.0 - initial interface
> * - 1.1 - adds HEAP and NOEXEC flags for CREATE_BO
> + * - 1.2 - adds AFBC_FEATURES query
> */
> static const struct drm_driver panfrost_drm_driver = {
> .driver_features= DRIVER_RENDER | DRIVER_GEM | DRIVER_SYNCOBJ,
> @@ -559,7 +561,7 @@ static const struct drm_driver panfrost_drm_driver = {
> .desc = "panfrost DRM",
> .date = "20180908",
> .major = 1,
> - .minor = 1,
> + .minor = 2,
>
> .gem_create_object = panfrost_gem_create_object,
> .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
> diff --git a/drivers/gpu/drm/panfrost/panfrost_gpu.c
> b/drivers/gpu/drm/panfrost/panfrost_gpu.c
> index 2aae636f1..0e70e27fd 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_gpu.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_gpu.c
> @@ -228,6 +228,7 @@ static void panfrost_gpu_init_features(struct
> panfrost_device *pfdev)
> pfdev->features.thread_max_workgroup_sz = gpu_read(pfdev,
> GPU_THREAD_MAX_WORKGROUP_SIZE);
> pfdev->features.thread_max_barrier_sz = gpu_read(pfdev,
> GPU_THREAD_MAX_BARRIER_SIZE);
> pfdev->features.coherency_features = gpu_read(pfdev,
> GPU_COHERENCY_FEATURES);
> + pfdev->features.afbc_features = gpu_read(pfdev, GPU_AFBC_FEATURES);
> for (i = 0; i < 4; i++)
> pfdev->features.texture_features[i] = gpu_read(pfdev,
> GPU_TEXTURE_FEATURES(i));
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_regs.h
> b/drivers/gpu/drm/panfrost/panfrost_regs.h
> index eddaa62ad..dc9df5457 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_regs.h
> +++ b/drivers/gpu/drm/panfrost/panfrost_regs.h
> @@ -82,6 +82,7 @@
>
> #define GPU_TEXTURE_FEATURES(n) (0x0B0 + ((n) * 4))
>
Re: [Intel-gfx] Merging TTM branches through the Intel tree?
Am 04.06.21 um 16:11 schrieb Thomas Hellström: On Fri, 2021-06-04 at 16:06 +0200, Christian König wrote: Am 04.06.21 um 16:03 schrieb Thomas Hellström: On Fri, 2021-06-04 at 15:38 +0200, Christian König wrote: Am 04.06.21 um 11:12 schrieb Daniel Vetter: On Fri, Jun 04, 2021 at 11:01:40AM +0200, Thomas Hellström wrote: On 6/4/21 9:51 AM, Christian König wrote: Am 03.06.21 um 09:36 schrieb Daniel Vetter: On Thu, Jun 3, 2021 at 8:50 AM Thomas Hellström wrote: On 6/2/21 8:40 PM, Daniel Vetter wrote: On Wed, Jun 02, 2021 at 11:48:41AM +0200, Christian König wrote: Am 02.06.21 um 11:16 schrieb Thomas Hellström (Intel): On 6/2/21 10:32 AM, Christian König wrote: Uff I'm just waiting for feedback from Philip to merge a large patch set for TTM through drm-misc-next. I'm pretty sure we will run into merge conflicts if you try to push your changes through the Intel tree. Christian. OK, so what would be the best approach here?, Adding the TTM patches to drm-misc-next when your set has landed? I think I will send out out my set to Matthew once more for review, then push the common TTM stuff to drm-misc-next as much as possible. Then you should be able to land your stuff to drm-misc-next and rebase on the end result. Just need to note to David that drm-misc-next should be merged to drm-next before the Intel patches depending on that stuff land as well. Other option (because the backmerges tend to be slow) is a topic branch, and we just eat/resolve the conflicts in both drm- misc- next and drm-intel-gt-next in the merge commit. If it's not too bad (I haven't looked at what exactly we need for the i915 side from ttm in detail). But also often figuring out the topic branch logistics takes longer than just merging to drm-misc-next as the patches get ready. -Daniel Daniel: So the thing we need to get into TTM is the iterator-based move_memcpy which is more adaptable than the current one and needed to support non-linear lmem buffers, some bug-fixes and minor changes to be able to keep our short-term-pinning while on the LRU. A necessary evil. Christian: it looks like you have landed some TTM changes already, in particular the >mem -> bo->resource change which is the main conflict I think. Yes, I thought that pushing this with Matthew rb should solve at least a bit of the conflict. Is the 10 patches self-allocation series the main remaining part? Yes, exactly. I only need Matthew's, Daniel's or your ok and I'm good to go as well That will probably cause some conflicts with already pushed i915 TTM setup code, but otherwise will not conflict with the rest of the TTM code I think, which should make it possible to bring in our TTM changes after conflict resolution with what you've already pushed. The memcpy code is pretty self-contained. I think in that case topic branch on top of drm-next (once the ttm bits we conflict with are there) is probably best, and then pull that into drm-misc-next and drm-intel-gt-next. Merge window freeze is also approach, so without topic branch we'd be stuck until like - rc2 when drm-next reopens. I guess Maarten can do the topic branch logistics in drm-misc.git for this. That approach sounds good to me as well. The amdgpu branch had some merge conflicts as well, but nothing we couldn't fix. OK, so this is going to be a little tricky, I guess. From what I can tell, the memcpy TTM stuff is resolved locally and can be merged to drm-misc-next immediately. It might have a very minor conflict with your 10 patches I think, if any. Your 10 patches will conflict slightly with current drm- intel-gt- next I think. Remaining intel patches will conflict only with current drm- misc- next. So We could have pull order - drm-misc-next up to bot not including your 10 patches, - drm-intel-gt-next - drm-misc-next from your 10 paches and onwards, - Intel's ttm enablement topic branch. If it's just slight conflicts then I wouldn't bother with careful merge order. Because if we do this we can get around to the i915 ttm topic branch only when we're back to -rc2. I've just pushed the remaining 10 patches to drm-misc-next and ran into minor merge conflicts in drm-tip. I'm working on this, but I'm not very familiar with drm-tip handling. Christian. Np, I'll hold off until Monday. Ok I've fixed up drm-tip for amdgpu, but there are also merge conflicts for i915. Can you handle those? Doesn't looks to hard, but I would prefer not to touch code I can't test. Christian. Hi, Christian, Unfortunately I can't (not until monday at least as I'm off for the weekend). But I did warn you twice about those. Ok in this case I will just fix them up as best as I can. Thanks, Christian. /Thomas /Thomas
Re: [Intel-gfx] Merging TTM branches through the Intel tree?
On Fri, 2021-06-04 at 16:06 +0200, Christian König wrote: > Am 04.06.21 um 16:03 schrieb Thomas Hellström: > > On Fri, 2021-06-04 at 15:38 +0200, Christian König wrote: > > > Am 04.06.21 um 11:12 schrieb Daniel Vetter: > > > > On Fri, Jun 04, 2021 at 11:01:40AM +0200, Thomas Hellström > > > > wrote: > > > > > On 6/4/21 9:51 AM, Christian König wrote: > > > > > > Am 03.06.21 um 09:36 schrieb Daniel Vetter: > > > > > > > On Thu, Jun 3, 2021 at 8:50 AM Thomas Hellström > > > > > > > wrote: > > > > > > > > On 6/2/21 8:40 PM, Daniel Vetter wrote: > > > > > > > > > On Wed, Jun 02, 2021 at 11:48:41AM +0200, Christian > > > > > > > > > König > > > > > > > > > wrote: > > > > > > > > > > Am 02.06.21 um 11:16 schrieb Thomas Hellström > > > > > > > > > > (Intel): > > > > > > > > > > > On 6/2/21 10:32 AM, Christian König wrote: > > > > > > > > > > > > Uff I'm just waiting for feedback from Philip > > > > > > > > > > > > to > > > > > > > > > > > > merge a large patch > > > > > > > > > > > > set for TTM through drm-misc-next. > > > > > > > > > > > > > > > > > > > > > > > > I'm pretty sure we will run into merge > > > > > > > > > > > > conflicts if > > > > > > > > > > > > you try to push > > > > > > > > > > > > your changes through the Intel tree. > > > > > > > > > > > > > > > > > > > > > > > > Christian. > > > > > > > > > > > OK, so what would be the best approach here?, > > > > > > > > > > > Adding > > > > > > > > > > > the TTM patches to > > > > > > > > > > > drm-misc-next when your set has landed? > > > > > > > > > > I think I will send out out my set to Matthew once > > > > > > > > > > more > > > > > > > > > > for review, then > > > > > > > > > > push the common TTM stuff to drm-misc-next as much > > > > > > > > > > as > > > > > > > > > > possible. > > > > > > > > > > > > > > > > > > > > Then you should be able to land your stuff to > > > > > > > > > > drm-misc-next and rebase on > > > > > > > > > > the end result. > > > > > > > > > > > > > > > > > > > > Just need to note to David that drm-misc-next > > > > > > > > > > should be > > > > > > > > > > merged to drm-next > > > > > > > > > > before the Intel patches depending on that stuff > > > > > > > > > > land > > > > > > > > > > as well. > > > > > > > > > Other option (because the backmerges tend to be slow) > > > > > > > > > is > > > > > > > > > a > > > > > > > > > topic branch, > > > > > > > > > and we just eat/resolve the conflicts in both drm- > > > > > > > > > misc- > > > > > > > > > next and > > > > > > > > > drm-intel-gt-next in the merge commit. If it's not > > > > > > > > > too > > > > > > > > > bad (I haven't > > > > > > > > > looked at what exactly we need for the i915 side from > > > > > > > > > ttm > > > > > > > > > in detail). > > > > > > > > > > > > > > > > > > But also often figuring out the topic branch > > > > > > > > > logistics > > > > > > > > > takes > > > > > > > > > longer than > > > > > > > > > just merging to drm-misc-next as the patches get > > > > > > > > > ready. > > > > > > > > > -Daniel > > > > > > > > Daniel: So the thing we need to get into TTM is the > > > > > > > > iterator-based > > > > > > > > move_memcpy which is more adaptable than the current > > > > > > > > one > > > > > > > > and needed to > > > > > > > > support non-linear lmem buffers, some bug-fixes and > > > > > > > > minor > > > > > > > > changes to be > > > > > > > > able to keep our short-term-pinning while on the LRU. A > > > > > > > > necessary evil. > > > > > > > > > > > > > > > > Christian: it looks like you have landed some TTM > > > > > > > > changes > > > > > > > > already, in > > > > > > > > particular the >mem -> bo->resource change which is > > > > > > > > the > > > > > > > > main > > > > > > > > conflict I think. > > > > > > Yes, I thought that pushing this with Matthew rb should > > > > > > solve > > > > > > at least a > > > > > > bit of the conflict. > > > > > > > > > > > > > > Is the 10 patches self-allocation series the main > > > > > > > > remaining part? > > > > > > Yes, exactly. I only need Matthew's, Daniel's or your ok > > > > > > and > > > > > > I'm good to > > > > > > go as well > > > > > > > > > > > > > > That will probably cause some conflicts with already > > > > > > > > pushed i915 TTM setup code, but otherwise will not > > > > > > > > conflict > > > > > > > > with the > > > > > > > > rest of the TTM code I think, which should make it > > > > > > > > possible > > > > > > > > to bring in > > > > > > > > our TTM changes after conflict resolution with what > > > > > > > > you've > > > > > > > > already > > > > > > > > pushed. The memcpy code is pretty self-contained. > > > > > > > I think in that case topic branch on top of drm-next > > > > > > > (once > > > > > > > the ttm > > > > > > > bits we conflict with are there) is probably best, and > > > > > > > then > > > > > > > pull that > > > > > > > into drm-misc-next and drm-intel-gt-next. Merge window > > > > > > > freeze > > > > > > > is also > > > > > > > approach, so without topic
Re: [PATCH] drm/i915: only disable default vga device
On Fri, Jun 04, 2021 at 02:47:16PM +0100, Emil Velikov wrote: > On Wed, 26 May 2021 at 17:21, Emil Velikov wrote: > > > > Hi Ville, > > > > On Tue, 18 May 2021 at 12:17, Ville Syrjälä > > wrote: > > > > > > On Tue, May 18, 2021 at 12:09:56PM +0100, Emil Velikov wrote: > > > > Hi Ville, > > > > > > > > On Mon, 17 May 2021 at 18:24, Ville Syrjälä > > > > wrote: > > > > > > > > > > On Sun, May 16, 2021 at 06:14:32PM +0100, Emil Velikov wrote: > > > > > > From: Vivek Das Mohapatra > > > > > > > > > > > > This patch is to do with seamless handover, eg when the sequence is > > > > > > bootloader → plymouth → desktop. > > > > > > > > > > > > It switches the vga arbiter from the "other" GPU to the default one > > > > > > (intel in this case), so the driver can issue some io(). > > > > > > > > > > I don't understand what this commit message is trying to say. > > > > > > > > > Bunch of context is lost due to the patch age, so I'm not 100% sure of > > > > the actual hardware setup where this occurs. > > > > Does the following make sense? > > > > > > > > Currently on dual GPU systems, we do not get seamless handover as the > > > > output flickers during the transition bootloader -> plymouth -> > > > > desktop. > > > > This happens as a result of switching (via the VGA arbiter) from the > > > > "other" GPU back to the default i915 one and issuing io() commands. > > > > > > Hmm. Does this work? > > > > > > --- a/drivers/gpu/drm/i915/display/intel_vga.c > > > +++ b/drivers/gpu/drm/i915/display/intel_vga.c > > > @@ -29,6 +29,9 @@ void intel_vga_disable(struct drm_i915_private > > > *dev_priv) > > > i915_reg_t vga_reg = intel_vga_cntrl_reg(dev_priv); > > > u8 sr1; > > > > > > + if (intel_de_read(dev_priv, vga_reg) & VGA_DISP_DISABLE) > > > + return; > > > + > > > /* WaEnableVGAAccessThroughIOPort:ctg,elk,ilk,snb,ivb,vlv,hsw */ > > > vga_get_uninterruptible(pdev, VGA_RSRC_LEGACY_IO); > > > outb(SR01, VGA_SR_INDEX); > > > > > Was able to replicate the issue somewhat and the above does help quite a > > lot. > > Feel free to add my: > > Reviewed-by: Emil Velikov > > Tested-by: Emil Velikov > > > Humble poke. > > Cannot see this patch in the drm-misc or drm-intel trees. Is there > anything I do to help move it forward? Can you just respin the patch with this? -- Ville Syrjälä Intel
Re: [Intel-gfx] Merging TTM branches through the Intel tree?
Am 04.06.21 um 16:03 schrieb Thomas Hellström: On Fri, 2021-06-04 at 15:38 +0200, Christian König wrote: Am 04.06.21 um 11:12 schrieb Daniel Vetter: On Fri, Jun 04, 2021 at 11:01:40AM +0200, Thomas Hellström wrote: On 6/4/21 9:51 AM, Christian König wrote: Am 03.06.21 um 09:36 schrieb Daniel Vetter: On Thu, Jun 3, 2021 at 8:50 AM Thomas Hellström wrote: On 6/2/21 8:40 PM, Daniel Vetter wrote: On Wed, Jun 02, 2021 at 11:48:41AM +0200, Christian König wrote: Am 02.06.21 um 11:16 schrieb Thomas Hellström (Intel): On 6/2/21 10:32 AM, Christian König wrote: Uff I'm just waiting for feedback from Philip to merge a large patch set for TTM through drm-misc-next. I'm pretty sure we will run into merge conflicts if you try to push your changes through the Intel tree. Christian. OK, so what would be the best approach here?, Adding the TTM patches to drm-misc-next when your set has landed? I think I will send out out my set to Matthew once more for review, then push the common TTM stuff to drm-misc-next as much as possible. Then you should be able to land your stuff to drm-misc-next and rebase on the end result. Just need to note to David that drm-misc-next should be merged to drm-next before the Intel patches depending on that stuff land as well. Other option (because the backmerges tend to be slow) is a topic branch, and we just eat/resolve the conflicts in both drm-misc- next and drm-intel-gt-next in the merge commit. If it's not too bad (I haven't looked at what exactly we need for the i915 side from ttm in detail). But also often figuring out the topic branch logistics takes longer than just merging to drm-misc-next as the patches get ready. -Daniel Daniel: So the thing we need to get into TTM is the iterator-based move_memcpy which is more adaptable than the current one and needed to support non-linear lmem buffers, some bug-fixes and minor changes to be able to keep our short-term-pinning while on the LRU. A necessary evil. Christian: it looks like you have landed some TTM changes already, in particular the >mem -> bo->resource change which is the main conflict I think. Yes, I thought that pushing this with Matthew rb should solve at least a bit of the conflict. Is the 10 patches self-allocation series the main remaining part? Yes, exactly. I only need Matthew's, Daniel's or your ok and I'm good to go as well That will probably cause some conflicts with already pushed i915 TTM setup code, but otherwise will not conflict with the rest of the TTM code I think, which should make it possible to bring in our TTM changes after conflict resolution with what you've already pushed. The memcpy code is pretty self-contained. I think in that case topic branch on top of drm-next (once the ttm bits we conflict with are there) is probably best, and then pull that into drm-misc-next and drm-intel-gt-next. Merge window freeze is also approach, so without topic branch we'd be stuck until like - rc2 when drm-next reopens. I guess Maarten can do the topic branch logistics in drm-misc.git for this. That approach sounds good to me as well. The amdgpu branch had some merge conflicts as well, but nothing we couldn't fix. OK, so this is going to be a little tricky, I guess. From what I can tell, the memcpy TTM stuff is resolved locally and can be merged to drm-misc-next immediately. It might have a very minor conflict with your 10 patches I think, if any. Your 10 patches will conflict slightly with current drm-intel-gt- next I think. Remaining intel patches will conflict only with current drm-misc- next. So We could have pull order - drm-misc-next up to bot not including your 10 patches, - drm-intel-gt-next - drm-misc-next from your 10 paches and onwards, - Intel's ttm enablement topic branch. If it's just slight conflicts then I wouldn't bother with careful merge order. Because if we do this we can get around to the i915 ttm topic branch only when we're back to -rc2. I've just pushed the remaining 10 patches to drm-misc-next and ran into minor merge conflicts in drm-tip. I'm working on this, but I'm not very familiar with drm-tip handling. Christian. Np, I'll hold off until Monday. Ok I've fixed up drm-tip for amdgpu, but there are also merge conflicts for i915. Can you handle those? Doesn't looks to hard, but I would prefer not to touch code I can't test. Christian. /Thomas
Re: [Intel-gfx] Merging TTM branches through the Intel tree?
On Fri, 2021-06-04 at 15:38 +0200, Christian König wrote: > Am 04.06.21 um 11:12 schrieb Daniel Vetter: > > On Fri, Jun 04, 2021 at 11:01:40AM +0200, Thomas Hellström wrote: > > > On 6/4/21 9:51 AM, Christian König wrote: > > > > Am 03.06.21 um 09:36 schrieb Daniel Vetter: > > > > > On Thu, Jun 3, 2021 at 8:50 AM Thomas Hellström > > > > > wrote: > > > > > > On 6/2/21 8:40 PM, Daniel Vetter wrote: > > > > > > > On Wed, Jun 02, 2021 at 11:48:41AM +0200, Christian König > > > > > > > wrote: > > > > > > > > Am 02.06.21 um 11:16 schrieb Thomas Hellström (Intel): > > > > > > > > > On 6/2/21 10:32 AM, Christian König wrote: > > > > > > > > > > Uff I'm just waiting for feedback from Philip to > > > > > > > > > > merge a large patch > > > > > > > > > > set for TTM through drm-misc-next. > > > > > > > > > > > > > > > > > > > > I'm pretty sure we will run into merge conflicts if > > > > > > > > > > you try to push > > > > > > > > > > your changes through the Intel tree. > > > > > > > > > > > > > > > > > > > > Christian. > > > > > > > > > OK, so what would be the best approach here?, Adding > > > > > > > > > the TTM patches to > > > > > > > > > drm-misc-next when your set has landed? > > > > > > > > I think I will send out out my set to Matthew once more > > > > > > > > for review, then > > > > > > > > push the common TTM stuff to drm-misc-next as much as > > > > > > > > possible. > > > > > > > > > > > > > > > > Then you should be able to land your stuff to > > > > > > > > drm-misc-next and rebase on > > > > > > > > the end result. > > > > > > > > > > > > > > > > Just need to note to David that drm-misc-next should be > > > > > > > > merged to drm-next > > > > > > > > before the Intel patches depending on that stuff land > > > > > > > > as well. > > > > > > > Other option (because the backmerges tend to be slow) is > > > > > > > a > > > > > > > topic branch, > > > > > > > and we just eat/resolve the conflicts in both drm-misc- > > > > > > > next and > > > > > > > drm-intel-gt-next in the merge commit. If it's not too > > > > > > > bad (I haven't > > > > > > > looked at what exactly we need for the i915 side from ttm > > > > > > > in detail). > > > > > > > > > > > > > > But also often figuring out the topic branch logistics > > > > > > > takes > > > > > > > longer than > > > > > > > just merging to drm-misc-next as the patches get ready. > > > > > > > -Daniel > > > > > > Daniel: So the thing we need to get into TTM is the > > > > > > iterator-based > > > > > > move_memcpy which is more adaptable than the current one > > > > > > and needed to > > > > > > support non-linear lmem buffers, some bug-fixes and minor > > > > > > changes to be > > > > > > able to keep our short-term-pinning while on the LRU. A > > > > > > necessary evil. > > > > > > > > > > > > Christian: it looks like you have landed some TTM changes > > > > > > already, in > > > > > > particular the >mem -> bo->resource change which is the > > > > > > main > > > > > > conflict I think. > > > > Yes, I thought that pushing this with Matthew rb should solve > > > > at least a > > > > bit of the conflict. > > > > > > > > > > Is the 10 patches self-allocation series the main > > > > > > remaining part? > > > > Yes, exactly. I only need Matthew's, Daniel's or your ok and > > > > I'm good to > > > > go as well > > > > > > > > > > That will probably cause some conflicts with already > > > > > > pushed i915 TTM setup code, but otherwise will not conflict > > > > > > with the > > > > > > rest of the TTM code I think, which should make it possible > > > > > > to bring in > > > > > > our TTM changes after conflict resolution with what you've > > > > > > already > > > > > > pushed. The memcpy code is pretty self-contained. > > > > > I think in that case topic branch on top of drm-next (once > > > > > the ttm > > > > > bits we conflict with are there) is probably best, and then > > > > > pull that > > > > > into drm-misc-next and drm-intel-gt-next. Merge window freeze > > > > > is also > > > > > approach, so without topic branch we'd be stuck until like - > > > > > rc2 when > > > > > drm-next reopens. I guess Maarten can do the topic branch > > > > > logistics in > > > > > drm-misc.git for this. > > > > That approach sounds good to me as well. > > > > > > > > The amdgpu branch had some merge conflicts as well, but nothing > > > > we > > > > couldn't fix. > > > OK, so this is going to be a little tricky, I guess. > > > > > > From what I can tell, the memcpy TTM stuff is resolved locally > > > and can be > > > merged to drm-misc-next immediately. It might have a very minor > > > conflict > > > with your 10 patches I think, if any. > > > > > > Your 10 patches will conflict slightly with current drm-intel-gt- > > > next I > > > think. > > > > > > Remaining intel patches will conflict only with current drm-misc- > > > next. > > > > > > So We could have pull order > > > > > > - drm-misc-next up to bot not including your 10 patches, > > > - drm-intel-gt-next >
