LIMA kernel bug - help!
Hi Qiang, 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 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. Any hints on how to troubleshoot this? Yours, Linus Walleij
[PATCH v3] backlight: ktd253: Stabilize backlight
Remove interrupt disablement during backlight setting. It is
way to dangerous and makes platforms instable by having it
miss vblank IRQs leading to the graphics derailing.
The code is using ndelay() which is not available on
platforms such as ARM and will result in 32 * udelay(1)
which is substantial.
Add some code to detect if an interrupt occurs during the
tight loop and in that case just redo it from the top.
Fixes: 5317f37e48b9 ("backlight: Add Kinetic KTD253 backlight driver")
Cc: Stephan Gerhold
Reported-by: newb...@disroot.org
Signed-off-by: Linus Walleij
---
ChangeLog v2->v3:
- Read my own patch and realized a bug: when we get a timeout
we bounce back to max period, but still count down the pwm
with one leading to an off-by-one error. Fix it by extending
some else clauses.
ChangeLog v1->v2:
- Alter the dimming code to check for how many ns the pulse
is low, and if it gets to ~100 us then redo from start.
This is to account for the advent that an IRQ arrives while
setting backlight and hits the low pulse making it way
too long.
---
drivers/video/backlight/ktd253-backlight.c | 75 --
1 file changed, 55 insertions(+), 20 deletions(-)
diff --git a/drivers/video/backlight/ktd253-backlight.c
b/drivers/video/backlight/ktd253-backlight.c
index a7df5bcca9da..37aa5a669530 100644
--- a/drivers/video/backlight/ktd253-backlight.c
+++ b/drivers/video/backlight/ktd253-backlight.c
@@ -25,6 +25,7 @@
#define KTD253_T_LOW_NS (200 + 10) /* Additional 10ns as safety factor */
#define KTD253_T_HIGH_NS (200 + 10) /* Additional 10ns as safety factor */
+#define KTD253_T_OFF_CRIT_NS 10 /* 100 us, now it doesn't look good */
#define KTD253_T_OFF_MS 3
struct ktd253_backlight {
@@ -34,13 +35,50 @@ struct ktd253_backlight {
u16 ratio;
};
+static void ktd253_backlight_set_max_ratio(struct ktd253_backlight *ktd253)
+{
+ gpiod_set_value_cansleep(ktd253->gpiod, 1);
+ ndelay(KTD253_T_HIGH_NS);
+ /* We always fall back to this when we power on */
+}
+
+static int ktd253_backlight_stepdown(struct ktd253_backlight *ktd253)
+{
+ /*
+* These GPIO operations absolutely can NOT sleep so no _cansleep
+* suffixes, and no using GPIO expanders on slow buses for this!
+*
+* The maximum number of cycles of the loop is 32 so the time taken
+* should nominally be:
+* (T_LOW_NS + T_HIGH_NS + loop_time) * 32
+*
+* Architectures do not always support ndelay() and we will get a few us
+* instead. If we get to a critical time limit an interrupt has likely
+* occured in the low part of the loop and we need to restart from the
+* top so we have the backlight in a known state.
+*/
+ u64 ns;
+
+ ns = ktime_get_ns();
+ gpiod_set_value(ktd253->gpiod, 0);
+ ndelay(KTD253_T_LOW_NS);
+ gpiod_set_value(ktd253->gpiod, 1);
+ ns = ktime_get_ns() - ns;
+ if (ns >= KTD253_T_OFF_CRIT_NS) {
+ dev_err(ktd253->dev, "PCM on backlight took too long (%llu
ns)\n", ns);
+ return -EAGAIN;
+ }
+ ndelay(KTD253_T_HIGH_NS);
+ return 0;
+}
+
static int ktd253_backlight_update_status(struct backlight_device *bl)
{
struct ktd253_backlight *ktd253 = bl_get_data(bl);
int brightness = backlight_get_brightness(bl);
u16 target_ratio;
u16 current_ratio = ktd253->ratio;
- unsigned long flags;
+ int ret;
dev_dbg(ktd253->dev, "new brightness/ratio: %d/32\n", brightness);
@@ -62,37 +100,34 @@ static int ktd253_backlight_update_status(struct
backlight_device *bl)
}
if (current_ratio == 0) {
- gpiod_set_value_cansleep(ktd253->gpiod, 1);
- ndelay(KTD253_T_HIGH_NS);
- /* We always fall back to this when we power on */
+ ktd253_backlight_set_max_ratio(ktd253);
current_ratio = KTD253_MAX_RATIO;
}
- /*
-* WARNING:
-* The loop to set the correct current level is performed
-* with interrupts disabled as it is timing critical.
-* The maximum number of cycles of the loop is 32
-* so the time taken will be (T_LOW_NS + T_HIGH_NS + loop_time) * 32,
-*/
- local_irq_save(flags);
while (current_ratio != target_ratio) {
/*
* These GPIO operations absolutely can NOT sleep so no
* _cansleep suffixes, and no using GPIO expanders on
* slow buses for this!
*/
- gpiod_set_value(ktd253->gpiod, 0);
- ndelay(KTD253_T_LOW_NS);
- gpiod_set_value(ktd253->gpiod, 1);
- ndelay(KTD253_T_HIGH_NS);
- /* After 1/32 we loop back to 32/32 */
- if (current_ratio == KTD253_MIN_RATIO)
+ ret = ktd253_backlight_stepdown(ktd253);
+ if (ret == -EAGAIN)
[Bug 213053] WARNING on dcn30_hwseq.c dcn30_set_hubp_blank, AMD Radeon 6700XT
https://bugzilla.kernel.org/show_bug.cgi?id=213053 Erik Badman (erik.bad...@yahoo.com) changed: What|Removed |Added CC||erik.bad...@yahoo.com --- Comment #1 from Erik Badman (erik.bad...@yahoo.com) --- Created attachment 297145 --> https://bugzilla.kernel.org/attachment.cgi?id=297145&action=edit full dmesg I see the same in dmesg every boot, since the 5.12 kernel. AMD 6800 XT here. Started around 5.12.4 somewhere I think. -- 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: [PATCH] udmabuf: Add support for mapping hugepages (v2)
Hi,
> for (pgidx = 0; pgidx < pgcnt; pgidx++) {
> + if (is_file_hugepages(memfd)) {
> + 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 % maxsubpgs);
> + get_page(page);
> + put_page(hpage);
if (hpage && subpgoff == maxsubpgs) {
put_page(hpage);
hpage = NULL;
}
if (!hpage) {
hpage = find_get_page_flags(...)
[ ... ]
}
Only lookup the huge page when you cross a hugepage border.
take care,
Gerd
Re: [Mesa-dev] Linux Graphics Next: Userspace submission update
On Thu., Jun. 3, 2021, 15:18 Daniel Vetter, wrote: > On Thu, Jun 3, 2021 at 7:53 PM Marek Olšák wrote: > > > > Daniel, I think what you are suggesting is that we need to enable user > queues with the drm scheduler and dma_fence first, and once that works, we > can investigate how much of that kernel logic can be moved to the hw. Would > that work? In theory it shouldn't matter whether the kernel does it or the > hw does it. It's the same code, just in a different place. > > Yeah I guess that's another way to look at it. Maybe in practice > you'll just move it from the kernel to userspace, which then programs > the hw waits directly into its IB. That's at least how I'd do it on > i915, assuming I'd have such hw. So these fences that userspace > programs directly (to sync within itself) won't even show up as > dependencies in the kernel. > > And then yes on the other side you can lift work from the > drm/scheduler wrt dependencies you get in the kernel (whether explicit > sync with sync_file, or implicit sync fished out of dma_resv) and > program the hw directly that way. That would mean that userspace wont > fill the ringbuffer directly, but the kernel would do that, so that > you have space to stuff in the additional waits. Again assuming i915 > hw model, maybe works differently on amd. Iirc we have some of that > already in the i915 scheduler, but I'd need to recheck how much it > really uses the hw semaphores. > I was thinking we would pass per process syncobj handles and buffer handles into commands in the user queue, or something equivalent. We do have a large degree of programmability in the hw that we can do something like that. The question is whether this high level user->hw interface would have any advantage over trivial polling on memory, etc. My impression is no because the kernel would be robust enough that it wouldn't matter what userspace does, but I don't know. Anyway, all we need is user queues and what your proposed seems totally sufficient. Marek -Daniel > > > Thanks, > > Marek > > > > On Thu, Jun 3, 2021 at 7:22 AM Daniel Vetter wrote: > >> > >> On Thu, Jun 3, 2021 at 12:55 PM Marek Olšák wrote: > >> > > >> > On Thu., Jun. 3, 2021, 06:03 Daniel Vetter, wrote: > >> >> > >> >> On Thu, Jun 03, 2021 at 04:20:18AM -0400, Marek Olšák wrote: > >> >> > On Thu, Jun 3, 2021 at 3:47 AM Daniel Vetter > wrote: > >> >> > > >> >> > > On Wed, Jun 02, 2021 at 11:16:39PM -0400, Marek Olšák wrote: > >> >> > > > On Wed, Jun 2, 2021 at 2:48 PM Daniel Vetter > wrote: > >> >> > > > > >> >> > > > > On Wed, Jun 02, 2021 at 05:38:51AM -0400, Marek Olšák wrote: > >> >> > > > > > On Wed, Jun 2, 2021 at 5:34 AM Marek Olšák < > mar...@gmail.com> wrote: > >> >> > > > > > > >> >> > > > > > > Yes, we can't break anything because we don't want to > complicate > >> >> > > things > >> >> > > > > > > for us. It's pretty much all NAK'd already. We are > trying to gather > >> >> > > > > more > >> >> > > > > > > knowledge and then make better decisions. > >> >> > > > > > > > >> >> > > > > > > The idea we are considering is that we'll expose > memory-based sync > >> >> > > > > objects > >> >> > > > > > > to userspace for read only, and the kernel or hw will > strictly > >> >> > > control > >> >> > > > > the > >> >> > > > > > > memory writes to those sync objects. The hole in that > idea is that > >> >> > > > > > > userspace can decide not to signal a job, so even if > userspace > >> >> > > can't > >> >> > > > > > > overwrite memory-based sync object states arbitrarily, > it can still > >> >> > > > > decide > >> >> > > > > > > not to signal them, and then a future fence is born. > >> >> > > > > > > > >> >> > > > > > > >> >> > > > > > This would actually be treated as a GPU hang caused by > that context, > >> >> > > so > >> >> > > > > it > >> >> > > > > > should be fine. > >> >> > > > > > >> >> > > > > This is practically what I proposed already, except your not > doing it > >> >> > > with > >> >> > > > > dma_fence. And on the memory fence side this also doesn't > actually give > >> >> > > > > what you want for that compute model. > >> >> > > > > > >> >> > > > > This seems like a bit a worst of both worlds approach to me? > Tons of > >> >> > > work > >> >> > > > > in the kernel to hide these not-dma_fence-but-almost, and > still pain to > >> >> > > > > actually drive the hardware like it should be for compute or > direct > >> >> > > > > display. > >> >> > > > > > >> >> > > > > Also maybe I've missed it, but I didn't see any replies to my > >> >> > > suggestion > >> >> > > > > how to fake the entire dma_fence stuff on top of new hw. > Would be > >> >> > > > > interesting to know what doesn't work there instead of amd > folks going > >> >> > > of > >> >> > > > > into internal again and then coming back with another rfc > from out of > >> >> > > > > nowhere :-) > >> >> > > > > > >> >> > > > > >> >> > > > Going internal again is probably a good idea to spare you the > long > >> >> > > > discussions and not waste your time,
[PATCH][next] drm/amd/pm: Fix fall-through warning for Clang
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] vgaarb: Call vga_arb_device_init() after PCI enumeration
Hi, Bjorn, 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(&vga_arb_device)? Huacai > > > Whether we move vgaarb into drivers/pci or not is then kinda orthogonal. > > I'm fine with moving it to drivers/pci if that makes anything easier. > It definitely is PCI-related stuff, not GPU-related stuff. > > [1] https://lore.kernel.org/r/20210526182940.GA1303599@bjorn-Precision-5520
Re: [PATCH RESEND][next] drm/nouveau/clk: Fix fall-through warnings for Clang
Hi all, If you don't mind, I'm taking this in my -next[1] branch for v5.14. Thanks -- Gustavo [1] https://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux.git/log/?h=for-next/kspp On 6/1/21 17:57, Gustavo A. R. Silva wrote: > Hi, > > Friendly second ping: who can take this? > > I can add this to my -next branch for 5.14 if you don't mind. > > JFYI: We had thousands of these sorts of warnings and now we are down > to just 23 in linux-next. This is one of those last remaining warnings. > > Thanks > -- > Gustavo > > On 4/20/21 15:13, Gustavo A. R. Silva wrote: >> Hi all, >> >> Friendly ping: who can take this, please? >> >> Thanks >> -- >> Gustavo >> >> On 3/5/21 03:56, 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 >>> --- >>> drivers/gpu/drm/nouveau/nvkm/subdev/clk/nv50.c | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/nv50.c >>> b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/nv50.c >>> index 83067763c0ec..e1d31c62f9ec 100644 >>> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/nv50.c >>> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/nv50.c >>> @@ -313,6 +313,7 @@ nv50_clk_read(struct nvkm_clk *base, enum nv_clk_src >>> src) >>> default: >>> break; >>> } >>> + break; >>> default: >>> break; >>> } >>>
Re: [Nouveau] [PATCH RESEND][next] drm/nouveau: Fix fall-through warnings for Clang
On 6/1/21 19:10, Karol Herbst wrote: > all three nouveau patches are > > Reviewed-by: Karol Herbst > > and I don't think anybody would mind if those get into through other > trees, but maybe drm-mist would be a good place for it if other > patches involve other drm drivers? No other person has replied after pinging multiple times and resending these patches, so I guess people don't care. I'll add this and the other similar patches to my -next branch for 5.14. Thanks, Karol. -- Gustavo > > On Wed, Jun 2, 2021 at 1:16 AM Gustavo A. R. Silva > wrote: >> >> Hi, >> >> Friendly second ping: who can take this? >> >> I can add this to my -next branch for 5.14 if you don't mind. >> >> JFYI: We had thousands of these sorts of warnings and now we are down >> to just 23 in linux-next. This is one of those last remaining warnings. >> >> Thanks >> -- >> Gustavo >> >> On 4/20/21 15:13, Gustavo A. R. Silva wrote: >>> Hi all, >>> >>> Friendly ping: who can take this, please? >>> >>> Thanks >>> -- >>> Gustavo >>> >>> On 3/5/21 03:56, Gustavo A. R. Silva wrote: In preparation to enable -Wimplicit-fallthrough for Clang, fix a couple of warnings by explicitly adding a couple of break statements 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 --- drivers/gpu/drm/nouveau/nouveau_bo.c| 1 + drivers/gpu/drm/nouveau/nouveau_connector.c | 1 + 2 files changed, 2 insertions(+) diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c index 2375711877cf..62903c3b368d 100644 --- a/drivers/gpu/drm/nouveau/nouveau_bo.c +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c @@ -443,6 +443,7 @@ nouveau_bo_pin(struct nouveau_bo *nvbo, uint32_t domain, bool contig) break; case TTM_PL_TT: error |= !(domain & NOUVEAU_GEM_DOMAIN_GART); +break; default: break; } diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c b/drivers/gpu/drm/nouveau/nouveau_connector.c index 61e6d7412505..eb844cdcaec2 100644 --- a/drivers/gpu/drm/nouveau/nouveau_connector.c +++ b/drivers/gpu/drm/nouveau/nouveau_connector.c @@ -157,6 +157,7 @@ nouveau_conn_atomic_set_property(struct drm_connector *connector, default: break; } +break; case DRM_MODE_SCALE_FULLSCREEN: case DRM_MODE_SCALE_CENTER: case DRM_MODE_SCALE_ASPECT: >> ___ >> Nouveau mailing list >> nouv...@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/nouveau >> >
Re: [PATCH RESEND][next] drm/nouveau/therm: Fix fall-through warnings for Clang
Hi all, If you don't mind, I'm taking this in my -next[1] branch for v5.14. Thanks -- Gustavo [1] https://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux.git/log/?h=for-next/kspp On 6/1/21 17:58, Gustavo A. R. Silva wrote: > Hi, > > Friendly second ping: who can take this? > > I can add this to my -next branch for 5.14 if you don't mind. > > JFYI: We had thousands of these sorts of warnings and now we are down > to just 23 in linux-next. This is one of those last remaining warnings. > > Thanks > -- > Gustavo > > On 4/20/21 15:13, Gustavo A. R. Silva wrote: >> Hi all, >> >> Friendly ping: who can take this, please? >> >> Thanks >> -- >> Gustavo >> >> On 3/5/21 03:58, 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 >>> --- >>> drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf119.c | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf119.c >>> b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf119.c >>> index 2b031d4eaeb6..684aff7437ee 100644 >>> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf119.c >>> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf119.c >>> @@ -41,6 +41,7 @@ pwm_info(struct nvkm_therm *therm, int line) >>> default: >>> break; >>> } >>> + break; >>> default: >>> break; >>> } >>>
Re: [PATCH V5 2/2] drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver
Hi Marek,
I love your patch! Perhaps something to improve:
[auto build test WARNING on robh/for-next]
[also build test WARNING on drm-intel/for-linux-next drm-tip/drm-tip
drm-exynos/exynos-drm-next tegra-drm/drm/tegra/for-next linus/master v5.13-rc4
next-20210603]
[cannot apply to drm/drm-next]
[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/Marek-Vasut/dt-bindings-drm-bridge-ti-sn65dsi83-Add-TI-SN65DSI83-and-SN65DSI84-bindings/20210603-045141
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: riscv-randconfig-r021-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 riscv cross compiling tool for clang build
# apt-get install binutils-riscv64-linux-gnu
#
https://github.com/0day-ci/linux/commit/98230a7ee966724a2b4bae97cb2f918c06fb2506
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Marek-Vasut/dt-bindings-drm-bridge-ti-sn65dsi83-Add-TI-SN65DSI83-and-SN65DSI84-bindings/20210603-045141
git checkout 98230a7ee966724a2b4bae97cb2f918c06fb2506
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=riscv
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/bridge/ti-sn65dsi83.c:642:11: warning: cast to smaller
>> integer type 'enum sn65dsi83_model' from 'const void *'
>> [-Wvoid-pointer-to-enum-cast]
model = (enum sn65dsi83_model)of_device_get_match_data(dev);
^~~
1 warning generated.
Kconfig warnings: (for reference only)
WARNING: unmet direct dependencies detected for LOCKDEP
Depends on DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT && (FRAME_POINTER || MIPS
|| PPC || S390 || MICROBLAZE || ARM || ARC || X86)
Selected by
- PROVE_LOCKING && DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT
- DEBUG_LOCK_ALLOC && DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT
vim +642 drivers/gpu/drm/bridge/ti-sn65dsi83.c
626
627 static int sn65dsi83_probe(struct i2c_client *client,
628 const struct i2c_device_id *id)
629 {
630 struct device *dev = &client->dev;
631 enum sn65dsi83_model model;
632 struct sn65dsi83 *ctx;
633 int ret;
634
635 ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
636 if (!ctx)
637 return -ENOMEM;
638
639 ctx->dev = dev;
640
641 if (dev->of_node)
> 642 model = (enum
> sn65dsi83_model)of_device_get_match_data(dev);
643 else
644 model = id->driver_data;
645
646 ctx->enable_gpio = devm_gpiod_get(ctx->dev, "enable",
GPIOD_OUT_LOW);
647 if (IS_ERR(ctx->enable_gpio))
648 return PTR_ERR(ctx->enable_gpio);
649
650 ret = sn65dsi83_parse_dt(ctx, model);
651 if (ret)
652 return ret;
653
654 ctx->regmap = devm_regmap_init_i2c(client,
&sn65dsi83_regmap_config);
655 if (IS_ERR(ctx->regmap))
656 return PTR_ERR(ctx->regmap);
657
658 dev_set_drvdata(dev, ctx);
659 i2c_set_clientdata(client, ctx);
660
661 ctx->bridge.funcs = &sn65dsi83_funcs;
662 ctx->bridge.of_node = dev->of_node;
663 drm_bridge_add(&ctx->bridge);
664
665 return 0;
666 }
667
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
[PATCH] video: fbdev: aty: mach64_gx: Added parentheses for the macro
From: lijian Macros with complex values should be enclosed in parentheses， so Added parentheses for the macro 'MAX_N'. Signed-off-by: lijian --- drivers/video/fbdev/aty/mach64_gx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/fbdev/aty/mach64_gx.c b/drivers/video/fbdev/aty/mach64_gx.c index 9619661b7843..4d89c05e5a65 100644 --- a/drivers/video/fbdev/aty/mach64_gx.c +++ b/drivers/video/fbdev/aty/mach64_gx.c @@ -33,7 +33,7 @@ #define MIN_M 2 #define MAX_M 30 #define MIN_N 35 -#define MAX_N 255-8 +#define MAX_N (255-8) /* -- 2.25.1
[PATCH] video: fbdev: aty: mach64_gx: Removed unnecessary 'return'
From: lijian
Removed unnecessary 'return' in void functions.
Signed-off-by: lijian
---
drivers/video/fbdev/aty/mach64_gx.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/video/fbdev/aty/mach64_gx.c
b/drivers/video/fbdev/aty/mach64_gx.c
index 9c37e28fb78b..9619661b7843 100644
--- a/drivers/video/fbdev/aty/mach64_gx.c
+++ b/drivers/video/fbdev/aty/mach64_gx.c
@@ -58,7 +58,6 @@ static void aty_StrobeClock(const struct atyfb_par *par)
tmp = aty_ld_8(CLOCK_CNTL, par);
aty_st_8(CLOCK_CNTL + par->clk_wr_offset, tmp | CLOCK_STROBE, par);
- return;
}
@@ -423,7 +422,6 @@ static void aty_ICS2595_put1bit(u8 data, const struct
atyfb_par *par)
par);
aty_StrobeClock(par);
- return;
}
static void aty_set_pll18818(const struct fb_info *info,
@@ -480,7 +478,6 @@ static void aty_set_pll18818(const struct fb_info *info,
mdelay(50); /* delay for 50 (15) ms */
aty_st_8(CLOCK_CNTL + par->clk_wr_offset,
((pll->ics2595.locationAddr & 0x0F) | CLOCK_STROBE), par);
- return;
}
const struct aty_pll_ops aty_pll_ati18818_1 = {
@@ -596,7 +593,6 @@ static void aty_set_pll_1703(const struct fb_info *info,
(void) aty_ld_8(DAC_REGS, par); /* Clear DAC Counter */
aty_st_8(CRTC_GEN_CNTL + 3, old_crtc_ext_disp, par);
- return;
}
const struct aty_pll_ops aty_pll_stg1703 = {
@@ -718,8 +714,6 @@ static void aty_set_pll_8398(const struct fb_info *info,
(void) aty_ld_8(DAC_REGS, par); /* Clear DAC Counter */
aty_st_8(CRTC_GEN_CNTL + 3, old_crtc_ext_disp, par);
-
- return;
}
const struct aty_pll_ops aty_pll_ch8398 = {
@@ -866,7 +860,6 @@ static void aty_set_pll_408(const struct fb_info *info,
(void) aty_ld_8(DAC_REGS, par); /* Clear DAC Counter */
aty_st_8(CRTC_GEN_CNTL + 3, old_crtc_ext_disp, par);
- return;
}
const struct aty_pll_ops aty_pll_att20c408 = {
--
2.25.1
Re: [PATCH 0/7] libdrm tests for hot-unplug feature
On 2021-06-03 10:53 p.m., Alex Deucher wrote: On Thu, Jun 3, 2021 at 9:37 PM Dave Airlie wrote: On Fri, 4 Jun 2021 at 07:20, Alex Deucher wrote: Please open a gitlab MR for these. I'd really prefer these tests all get migrated out of here into igt. I don't think libdrm_amdgpu really should have tests that test the kernel level infrastructure. I am also a bit confused now what's the policy about libdrm - is it being slowly deprecated ? What tests should go to IGT and what to libdrm ? The kernel feature itself is strictly amdgpu specific and not generic DRM level feature - why then it's not a good fit for amdgpu tester ? We are providing equivalent patches for IGT as well. There are some teams and customers that would prefer to stick with libdrm_amdgpu. Here are the patches in my cloned gitlab repo - https://gitlab.freedesktop.org/agrodzov/igt-gpu-tools/-/commits/master and I sent today for review to igt-...@lists.freedesktop.org too. Andrey I know some people at AMD had issues in the past with igt because the i might have stood for intel back in time, but at this point I think we should be moving past that. I don't think that was ever an issue. It's more that some teams built a bunch of infrastructure that used libdrm tests and haven't had the resources to switch to IGT yet. Alex
Re: [Intel-gfx] [RFC PATCH 64/97] drm/i915/guc: Reset implementation for new GuC interface
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(&ce->guc_state.lock);
> > INIT_LIST_HEAD(&ce->guc_state.fences);
> > + spin_lock_init(&ce->guc_active.lock);
> > + INIT_LIST_HEAD(&ce->guc_active.requests);
> > +
> > ce->guc_id = GUC_INVALID_LRC_ID;
> > INIT_LIST_HEAD(&ce->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.
> > +
> > /* 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 intel_engine_cs {
> > */
> > void(*release)(struct intel_engine_cs *engine);
> > + /*
> > +* Add / remove request from engine active tracking
> > +*/
> > + void(*add_active_request)(struct i915_request *rq);
> > + void(*remove_active_request)(struct i915_request *rq);
> > +
> > struct intel_engine_execlists execlists;
> > /*
> > diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > index 396b1356ea3e..54518b64bdbd 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > @@ -3117,6 +3117,42 @@ static void execlists_park(struct intel_engine_cs
> > *engine)
> > cancel_timer(&engine->execlists.preempt);
> > }
> > +static void add_to_engine(struct i915_request *rq)
> > +{
> > + lockdep_assert_held(&rq->engine->sched_engine->lock);
> > + list_move_tail(&rq->sched.link, &rq->engine->sched_
[PATCH] video: fbdev: uvesafb: Removed unnecessary 'return'
From: lijian Removed unnecessary 'return' in void function uvesafb_vbe_getmonspecs() and uvesafb_cn_callback(). Signed-off-by: lijian --- drivers/video/fbdev/uvesafb.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/video/fbdev/uvesafb.c b/drivers/video/fbdev/uvesafb.c index 4df6772802d7..28f353da668c 100644 --- a/drivers/video/fbdev/uvesafb.c +++ b/drivers/video/fbdev/uvesafb.c @@ -106,7 +106,6 @@ static void uvesafb_cn_callback(struct cn_msg *msg, struct netlink_skb_parms *ns memcpy(task->buf, utask + 1, task->t.buf_len); complete(task->done); - return; } static int uvesafb_helper_start(void) @@ -748,8 +747,6 @@ static void uvesafb_vbe_getmonspecs(struct uvesafb_ktask *task, fb_add_videomode(&info->monspecs.modedb[i], &info->modelist); } - - return; } static void uvesafb_vbe_getstatesize(struct uvesafb_ktask *task, -- 2.25.1
[PATCH] video: fbdev: cirrusfb: Removed unnecessary 'return'
From: lijian Removed unnecessary 'return' in void function init_vgachip(). Signed-off-by: lijian --- drivers/video/fbdev/cirrusfb.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/video/fbdev/cirrusfb.c b/drivers/video/fbdev/cirrusfb.c index 93802abbbc72..e726e7ac3eeb 100644 --- a/drivers/video/fbdev/cirrusfb.c +++ b/drivers/video/fbdev/cirrusfb.c @@ -1662,7 +1662,6 @@ static void init_vgachip(struct fb_info *info) /* misc... */ WHDR(cinfo, 0); /* Hidden DAC register: - */ - return; } static void switch_monitor(struct cirrusfb_info *cinfo, int on) -- 2.25.1
[PATCH] video: fbdev: hyperv_fb: Removed unnecessary 'return'
From: lijian Removed unnecessary 'return' in void function hvfb_get_option(). Signed-off-by: lijian --- drivers/video/fbdev/hyperv_fb.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_fb.c index 23999df52739..c8e57a513896 100644 --- a/drivers/video/fbdev/hyperv_fb.c +++ b/drivers/video/fbdev/hyperv_fb.c @@ -952,7 +952,6 @@ static void hvfb_get_option(struct fb_info *info) screen_width = x; screen_height = y; - return; } /* -- 2.25.1
Re: [PATCH 0/7] libdrm tests for hot-unplug feature
On Thu, Jun 3, 2021 at 9:37 PM Dave Airlie wrote: > > On Fri, 4 Jun 2021 at 07:20, Alex Deucher wrote: > > > > Please open a gitlab MR for these. > > > > I'd really prefer these tests all get migrated out of here into igt. I > don't think libdrm_amdgpu really should have tests that test the > kernel level infrastructure. > We are providing equivalent patches for IGT as well. There are some teams and customers that would prefer to stick with libdrm_amdgpu. > I know some people at AMD had issues in the past with igt because the > i might have stood for intel back in time, but at this point I think > we should be moving past that. I don't think that was ever an issue. It's more that some teams built a bunch of infrastructure that used libdrm tests and haven't had the resources to switch to IGT yet. Alex
[PATCH] video: fbdev: cyber2000fb: Removed unnecessary 'return'
From: lijian
Removed unnecessary 'return' in void functions.
Signed-off-by: lijian
---
drivers/video/fbdev/cyber2000fb.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/fbdev/cyber2000fb.c
b/drivers/video/fbdev/cyber2000fb.c
index d45355b9a58c..ee17e7fa8f4b 100644
--- a/drivers/video/fbdev/cyber2000fb.c
+++ b/drivers/video/fbdev/cyber2000fb.c
@@ -231,7 +231,6 @@ static void
cyber2000fb_imageblit(struct fb_info *info, const struct fb_image *image)
{
cfb_imageblit(info, image);
- return;
}
static int cyber2000fb_sync(struct fb_info *info)
--
2.25.1
Re: linux-next: manual merge of the amdgpu tree with the drm-misc tree
Hi all,
On Thu, 3 Jun 2021 12:48:47 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the amdgpu tree got conflicts in:
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>
> between commit:
>
> d3116756a710 ("drm/ttm: rename bo->mem and make it a pointer")
>
> from the drm-misc tree and commits:
>
> b453e42a6e8b ("drm/amdgpu: Add new placement for preemptible SG BOs")
> 2a675640bc2d ("drm/amdgpu: move shadow bo validation to VM code")
> 59276f056fb7 ("drm/amdgpu: switch to amdgpu_bo_vm for vm code")
> 19a1d9350be6 ("drm/amdgpu: flush gart changes after all BO recovery")
>
> from the amdgpu tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> index 663aa7d2e2ea,86259435803e..
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> @@@ -459,10 -479,11 +461,11 @@@ static int amdgpu_bo_move(struct ttm_bu
> {
> struct amdgpu_device *adev;
> struct amdgpu_bo *abo;
> -struct ttm_resource *old_mem = &bo->mem;
> +struct ttm_resource *old_mem = bo->resource;
> int r;
>
> - if (new_mem->mem_type == TTM_PL_TT) {
> + if (new_mem->mem_type == TTM_PL_TT ||
> + new_mem->mem_type == AMDGPU_PL_PREEMPT) {
> r = amdgpu_ttm_backend_bind(bo->bdev, bo->ttm, new_mem);
> if (r)
> return r;
> @@@ -989,8 -1012,9 +995,9 @@@ int amdgpu_ttm_alloc_gart(struct ttm_bu
> return r;
> }
>
> + amdgpu_gart_invalidate_tlb(adev);
> -ttm_resource_free(bo, &bo->mem);
> -bo->mem = tmp;
> +ttm_resource_free(bo, bo->resource);
> +ttm_bo_assign_mem(bo, &tmp);
> }
>
> return 0;
> @@@ -1348,7 -1373,16 +1356,16 @@@ static bool amdgpu_ttm_bo_eviction_valu
> }
> }
>
> -switch (bo->mem.mem_type) {
> +switch (bo->resource->mem_type) {
> + case AMDGPU_PL_PREEMPT:
> + /* Preemptible BOs don't own system resources managed by the
> + * driver (pages, VRAM, GART space). They point to resources
> + * owned by someone else (e.g. pageable memory in user mode
> + * or a DMABuf). They are used in a preemptible context so we
> + * can guarantee no deadlocks and good QoS in case of MMU
> + * notifiers or DMABuf move notifiers from the resource owner.
> + */
> + return false;
> case TTM_PL_TT:
> if (amdgpu_bo_is_amdgpu_bo(bo) &&
> amdgpu_bo_encrypted(ttm_to_amdgpu_bo(bo)))
> @@@ -1767,8 -1809,13 +1791,9 @@@ void amdgpu_ttm_fini(struct amdgpu_devi
> amdgpu_bo_free_kernel(&adev->mman.discovery_memory, NULL, NULL);
> amdgpu_ttm_fw_reserve_vram_fini(adev);
>
> -if (adev->mman.aper_base_kaddr)
> -iounmap(adev->mman.aper_base_kaddr);
> -adev->mman.aper_base_kaddr = NULL;
> -
> amdgpu_vram_mgr_fini(adev);
> amdgpu_gtt_mgr_fini(adev);
> + amdgpu_preempt_mgr_fini(adev);
> ttm_range_man_fini(&adev->mman.bdev, AMDGPU_PL_GDS);
> ttm_range_man_fini(&adev->mman.bdev, AMDGPU_PL_GWS);
> ttm_range_man_fini(&adev->mman.bdev, AMDGPU_PL_OA);
> @@@ -1919,7 -2010,12 +1944,12 @@@ int amdgpu_fill_buffer(struct amdgpu_b
> return -EINVAL;
> }
>
> -if (bo->tbo.mem.mem_type == AMDGPU_PL_PREEMPT) {
> ++if (bo->tbo.resource->mem_type == AMDGPU_PL_PREEMPT) {
> + DRM_ERROR("Trying to clear preemptible memory.\n");
> + return -EINVAL;
> + }
> +
> -if (bo->tbo.mem.mem_type == TTM_PL_TT) {
> +if (bo->tbo.resource->mem_type == TTM_PL_TT) {
> r = amdgpu_ttm_alloc_gart(&bo->tbo);
> if (r)
> return r;
> diff --cc drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> index bcfd4a8d0288,1923f035713a..
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> @@@ -657,11 -657,10 +658,11 @@@ void amdgpu_vm_move_to_lru_tail(struct
> if (!bo->parent)
> continue;
>
> -ttm_bo_move_to_lru_tail(&bo->tbo, &bo->tbo.mem,
> +ttm_bo_move_to_lru_tail(&bo->tbo, bo->tbo.resource,
> &vm->lru_bulk_move);
> - if (bo->shadow)
> - ttm_bo_move_to_lru_tail(&bo->shadow->tbo,
> + if (shadow)
> -ttm_bo_move_to_lr
Re: [Freedreno] [RFC PATCH 00/13] drm/msm: Add Display Stream Compression Support
On Wed, Jun 2, 2021 at 4:01 AM Vinod Koul wrote: > > On 27-05-21, 16:30, Rob Clark wrote: > > On Wed, May 26, 2021 at 8:00 AM Jeffrey Hugo > > wrote: > > > On Tue, May 25, 2021 at 11:46 PM Vinod Koul wrote: > > > > Frankly, I don't like the MSM ACPI solution that I've seen on the laptops. > > > The ACPI assumes the entire MDSS (including DSI parts) and GPU is one > > > device, and ultimately handled by one driver. That driver needs to > > > get a value from UEFI (set by the bootloader) that is the "panel id". > > > Then the driver calls into ACPI (I think its _ROM, but I might be > > > mistaken, doing this from memory) with that id. It gets back a binary > > > blob which is mostly an xml file (format is publicly documented) that > > > contains the panel timings and such. > > > > tbh, I kinda suspect that having a single "gpu" device (which also > > includes venus, in addition to display, IIRC) in the ACPI tables is a > > windowsism, trying to make things look to userspace like a single "GPU > > card" in the x86 world.. but either way, I think the ACPI tables on > > the windows arm laptops which use dsi->bridge->edp is too much of a > > lost cause to even consider here. Possibly ACPI boot on these devices > > would be more feasible on newer devices which have direct eDP out of > > the SoC without requiring external bridge/panel glue. > > yeah that is always a very different world. although it might make sense > to use information in tables and try to deduce information about the > system can be helpful... > > > I'd worry more about what makes sense in a DT world, when it comes to > > DT bindings. > > And do you have thoughts on that..? Only that I wouldn't get too hung up on existing snapdragon ACPI tables.. not sure if there is prior art as far as ACPI tables for this on x86 systems, if so that *might* be a thing to consider, but otherwise it does sound a bit like we want less qcom specific bindings here. But other than that I'll leave it to folks who spend more time thinking about bindings.. left to my own devices I'd come up with a point solution and go back to working on mesa, so that probably isn't the opinion you want to follow ;-) BR, -R
Re: [PATCH 0/7] libdrm tests for hot-unplug fe goature
Code review happens on gitlab now for libdrm. Alex On Thu, Jun 3, 2021 at 6:02 PM Grodzovsky, Andrey wrote: > > Is libdrm on gitlab ? I wasn't aware of this. I assumed code reviews still go > through dri-devel. > > Andrey > > > From: Alex Deucher > Sent: 03 June 2021 17:20 > To: Grodzovsky, Andrey > Cc: Maling list - DRI developers ; amd-gfx > list ; Deucher, Alexander > ; Christian König > > Subject: Re: [PATCH 0/7] libdrm tests for hot-unplug feature > > Please open a gitlab MR for these. > > Alex > > On Tue, Jun 1, 2021 at 4:17 PM Andrey Grodzovsky > wrote: > > > > Adding some tests to acompany the recently added hot-unplug > > feature. For now the test suite is disabled until the feature > > propagates from drm-misc-next to drm-next. > > > > Andrey Grodzovsky (7): > > tests/amdgpu: Fix valgrind warning > > xf86drm: Add function to retrieve char device path > > test/amdgpu: Add helper functions for hot unplug > > test/amdgpu/hotunplug: Add test suite for GPU unplug > > test/amdgpu/hotunplug: Add basic test > > tests/amdgpu/hotunplug: Add unplug with cs test. > > tests/amdgpu/hotunplug: Add hotunplug with exported bo test > > > > tests/amdgpu/amdgpu_test.c | 42 +++- > > tests/amdgpu/amdgpu_test.h | 26 +++ > > tests/amdgpu/basic_tests.c | 5 +- > > tests/amdgpu/hotunplug_tests.c | 357 + > > tests/amdgpu/meson.build | 1 + > > xf86drm.c | 23 +++ > > xf86drm.h | 1 + > > 7 files changed, 450 insertions(+), 5 deletions(-) > > create mode 100644 tests/amdgpu/hotunplug_tests.c > > > > -- > > 2.25.1 > > > > ___ > > amd-gfx mailing list > > amd-...@lists.freedesktop.org > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=04%7C01%7Candrey.grodzovsky%40amd.com%7C8fb7f614798b4d19572e08d926d57530%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637583520507282588%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ozqlNQACGvLJugQ2GNvFl8CKgAH0thqMRpWjHpURlyc%3D&reserved=0
Re: [PATCH 08/20] drm/i915: Promote ptrdiff() to i915_utils.h
On Thu, Jun 03, 2021 at 11:35:28PM +0200, Daniel Vetter wrote:
> On Wed, Jun 02, 2021 at 10:16:18PM -0700, Matthew Brost wrote:
> > From: Michal Wajdeczko
> >
> > Generic helpers should be placed in i915_utils.h.
>
> Random rant, but we're _way_ too happy to just stuff random things into
> i915_utils.h without trying to properly upstream it.
>
> For thinks like this the general dumping ground would be kernel.h, there's
> a few pointer helpers there already. Follow up patch maybe nice.
> -Daniel
>
Sure. I've added this to a list of follow ups so this comment doesn't
get lost.
Matt
> >
> > Signed-off-by: Michal Wajdeczko
> > Signed-off-by: Matthew Brost
> > Reviewed-by: Matthew Brost
> > ---
> > drivers/gpu/drm/i915/i915_utils.h | 5 +
> > drivers/gpu/drm/i915/i915_vma.h | 5 -
> > 2 files changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_utils.h
> > b/drivers/gpu/drm/i915/i915_utils.h
> > index f02f52ab5070..5259edacde38 100644
> > --- a/drivers/gpu/drm/i915/i915_utils.h
> > +++ b/drivers/gpu/drm/i915/i915_utils.h
> > @@ -201,6 +201,11 @@ __check_struct_size(size_t base, size_t arr, size_t
> > count, size_t *size)
> > __T;\
> > })
> >
> > +static __always_inline ptrdiff_t ptrdiff(const void *a, const void *b)
> > +{
> > + return a - b;
> > +}
> > +
> > /*
> > * container_of_user: Extract the superclass from a pointer to a member.
> > *
> > diff --git a/drivers/gpu/drm/i915/i915_vma.h
> > b/drivers/gpu/drm/i915/i915_vma.h
> > index dc6926d89626..eca452a9851f 100644
> > --- a/drivers/gpu/drm/i915/i915_vma.h
> > +++ b/drivers/gpu/drm/i915/i915_vma.h
> > @@ -151,11 +151,6 @@ static inline void i915_vma_put(struct i915_vma *vma)
> > i915_gem_object_put(vma->obj);
> > }
> >
> > -static __always_inline ptrdiff_t ptrdiff(const void *a, const void *b)
> > -{
> > - return a - b;
> > -}
> > -
> > static inline long
> > i915_vma_compare(struct i915_vma *vma,
> > struct i915_address_space *vm,
> > --
> > 2.28.0
> >
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
[git pull] drm fixes for 5.13-rc5
Hey Linus, Two big regression reverts in here, one for fbdev and one i915. Otherwise it's mostly amdgpu display fixes, and tegra fixes. Seems about right for rc5. Dave. drm-fixes-2021-06-04-1: drm fixes for 5.13-rc5 fb: - revert broken fb_defio patch amdgpu: - Display fixes - FRU EEPROM error handling fix - RAS fix - PSP fix - Releasing pinned BO fix i915: - Revert conversion to io_mapping_map_user() which lead to BUG_ON() - Fix check for error valued returns in a selftest tegra: - SOR power domain race condition fix - build warning fix - runtime pm ref leak fix - modifier fix The following changes since commit 8124c8a6b35386f73523d27eacb71b5364a68c4c: Linux 5.13-rc4 (2021-05-30 11:58:25 -1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2021-06-04-1 for you to fetch changes up to 37e2f2e800dc6d65aa77f9d4dbc4512d841e2f0b: Merge tag 'drm/tegra/for-5.13-rc5' of ssh://git.freedesktop.org/git/tegra/linux into drm-fixes (2021-06-04 10:23:57 +1000) drm fixes for 5.13-rc5 fb: - revert broken fb_defio patch amdgpu: - Display fixes - FRU EEPROM error handling fix - RAS fix - PSP fix - Releasing pinned BO fix i915: - Revert conversion to io_mapping_map_user() which lead to BUG_ON() - Fix check for error valued returns in a selftest tegra: - SOR power domain race condition fix - build warning fix - runtime pm ref leak fix - modifier fix Asher Song (1): drm/amdgpu: add judgement for dc support Bindu Ramamurthy (1): drm/amd/display: Allow bandwidth validation for 0 streams. Dave Airlie (4): Merge tag 'drm-misc-fixes-2021-06-03' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Merge tag 'drm-intel-fixes-2021-06-03' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes Merge tag 'amd-drm-fixes-5.13-2021-06-02' of https://gitlab.freedesktop.org/agd5f/linux into drm-fixes Merge tag 'drm/tegra/for-5.13-rc5' of ssh://git.freedesktop.org/git/tegra/linux into drm-fixes Dmitry Osipenko (1): drm/tegra: Correct DRM_FORMAT_MOD_NVIDIA_SECTOR_LAYOUT Jiansong Chen (1): drm/amdgpu: refine amdgpu_fru_get_product_info Luben Tuikov (1): drm/amdgpu: Don't query CE and UE errors Lyude Paul (1): drm/tegra: Get ref for DP AUX channel, not its ddc adapter Matthew Auld (1): Revert "i915: use io_mapping_map_user" Matthew Wilcox (1): Revert "fb_defio: Remove custom address_space_operations" Nathan Chancellor (1): drm/tegra: Fix shift overflow in tegra_shared_plane_atomic_update Nicholas Kazlauskas (1): drm/amd/display: Fix GPU scaling regression by FS video support Nirmoy Das (1): drm/amdgpu: make sure we unpin the UVD BO Pavel Machek (CIP) (1): drm/tegra: sor: Do not leak runtime PM reference Rodrigo Siqueira (1): drm/amd/display: Fix overlay validation by considering cursors Roman Li (1): drm/amd/display: Fix potential memory leak in DMUB hw_init Simon Ser (1): amd/display: convert DRM_DEBUG_ATOMIC to drm_dbg_atomic Thierry Reding (3): gpu: host1x: Split up client initalization and registration drm/tegra: sor: Fully initialize SOR before registration drm/tegra: sor: Fix AUX device reference leak Victor Zhao (1): drm/amd/amdgpu:save psp ring wptr to avoid attack Zhihao Cheng (1): drm/i915/selftests: Fix return value check in live_breadcrumbs_smoketest() drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c| 16 - drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_fru_eeprom.c | 42 +++-- drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h| 1 + drivers/gpu/drm/amd/amdgpu/psp_v11_0.c | 3 +- drivers/gpu/drm/amd/amdgpu/psp_v3_1.c | 3 +- drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c | 1 + drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 30 ++ .../gpu/drm/amd/display/dc/dcn20/dcn20_resource.c | 2 +- drivers/gpu/drm/i915/Kconfig | 1 - drivers/gpu/drm/i915/gem/i915_gem_mman.c | 9 +-- drivers/gpu/drm/i915/i915_drv.h| 3 + drivers/gpu/drm/i915/i915_mm.c | 44 ++ drivers/gpu/drm/i915/selftests/i915_request.c | 4 +- drivers/gpu/drm/tegra/drm.h| 2 +- drivers/gpu/drm/tegra/hub.c| 2 +- drivers/gpu/drm/tegra/sor.c| 70 +- drivers/gpu/host1x/bus.c | 30 -- drivers/video/fbdev/core/fb_defio.c| 35 +++ drivers/video/fbdev/core/fbmem.c | 4 ++ include/linux/fb.h | 3 + include/linux/host1x.h | 30 -- 22 files changed, 240 insertions(+), 99 del
[Bug 213321] Laptop not waking from sleep
https://bugzilla.kernel.org/show_bug.cgi?id=213321 --- Comment #5 from Sujay1844 (sujay1...@protonmail.com) --- K that guy says, it'll be fixed by 5.14 When will that be released?? I heard that 5.14 will be having support for the new Alder Lake M CPUs from Intel. So I think, we can expect 5.14 to released right around the time of release of the processors right?? -- 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 v2] drm/pl111: Actually fix CONFIG_VEXPRESS_CONFIG depends
VEXPRESS_CONFIG needs to either be missing, built-in, or modular when
pl111 is modular. Update the Kconfig to reflect the need.
Fixes: 4dc7c97d04dc ("drm/pl111: depend on CONFIG_VEXPRESS_CONFIG")
Signed-off-by: Kees Cook
---
v2: use expected Kconfig style to express this. :)
v1: https://lore.kernel.org/lkml/20210603215819.3904733-1-keesc...@chromium.org
---
drivers/gpu/drm/pl111/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/pl111/Kconfig b/drivers/gpu/drm/pl111/Kconfig
index c5210a5bef1b..3aae387a96af 100644
--- a/drivers/gpu/drm/pl111/Kconfig
+++ b/drivers/gpu/drm/pl111/Kconfig
@@ -2,7 +2,8 @@
config DRM_PL111
tristate "DRM Support for PL111 CLCD Controller"
depends on DRM
- depends on VEXPRESS_CONFIG
+ depends on ARM || ARM64 || COMPILE_TEST
+ depends on VEXPRESS_CONFIG || VEXPRESS_CONFIG=n
depends on COMMON_CLK
select DRM_KMS_HELPER
select DRM_KMS_CMA_HELPER
--
2.25.1
Re: [PATCH 0/7] libdrm tests for hot-unplug feature
On Fri, 4 Jun 2021 at 07:20, Alex Deucher wrote: > > Please open a gitlab MR for these. > I'd really prefer these tests all get migrated out of here into igt. I don't think libdrm_amdgpu really should have tests that test the kernel level infrastructure. I know some people at AMD had issues in the past with igt because the i might have stood for intel back in time, but at this point I think we should be moving past that. Dave.
Re: [PATCH] drm/pl111: Actually fix CONFIG_VEXPRESS_CONFIG depends
On Fri, Jun 04, 2021 at 12:30:00AM +0200, Daniel Vetter wrote:
> [gmail is funny]
>
> On Thu, Jun 3, 2021 at 11:58 PM Kees Cook wrote:
> >
> > VEXPRESS_CONFIG needs to either be missing, built-in, or modular when
> > pl111 is modular. Update the Kconfig to reflect the need.
> >
> > Cc: Emma Anholt
> > Cc: David Airlie
> > Cc: Daniel Vetter
> > Cc: dri-devel@lists.freedesktop.org
> > Fixes: 4dc7c97d04dc ("drm/pl111: depend on CONFIG_VEXPRESS_CONFIG")
> > Signed-off-by: Kees Cook
> > ---
> > drivers/gpu/drm/pl111/Kconfig | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/pl111/Kconfig b/drivers/gpu/drm/pl111/Kconfig
> > index c5210a5bef1b..b84879ca430d 100644
> > --- a/drivers/gpu/drm/pl111/Kconfig
> > +++ b/drivers/gpu/drm/pl111/Kconfig
> > @@ -2,7 +2,8 @@
> > config DRM_PL111
> > tristate "DRM Support for PL111 CLCD Controller"
> > depends on DRM
> > - depends on VEXPRESS_CONFIG
> > + depends on ARM || ARM64 || COMPILE_TEST
> > + depends on !VEXPRESS_CONFIG || VEXPRESS_CONFIG=DRM
>
> I thought the canonical way to represent optional dependencies was
> depends on FOO || FOO=n
Ah-ha! So it is:
drm/Kconfig:depends on (AGP || AGP=n) && !EMULATED_CMPXCHG && HAS_DMA
drm/Kconfig:depends on FB_SIS || FB_SIS=n
drm/msm/Kconfig:depends on QCOM_OCMEM || QCOM_OCMEM=n
drm/msm/Kconfig:depends on QCOM_LLCC || QCOM_LLCC=n
drm/msm/Kconfig:depends on QCOM_COMMAND_DB || QCOM_COMMAND_DB=n
I'll resping and retest. Thanks for the pointer!
-Kees
--
Kees Cook
Re: [PATCH v9 07/10] mm: Device exclusive memory access
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;
- Alistair
> --
> Peter Xu
Re: [RESEND 14/26] drm/msm/dp/dp_link: Fix some potential doc-rot
On 02/06/2021 17:32, Lee Jones wrote: Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/msm/dp/dp_link.c:374: warning: expecting prototype for dp_parse_video_pattern_params(). Prototype was for dp_link_parse_video_pattern_params() instead drivers/gpu/drm/msm/dp/dp_link.c:573: warning: expecting prototype for dp_parse_phy_test_params(). Prototype was for dp_link_parse_phy_test_params() instead drivers/gpu/drm/msm/dp/dp_link.c:975: warning: expecting prototype for dp_link_process_downstream_port_status_change(). Prototype was for dp_link_process_ds_port_status_change() instead Cc: Rob Clark Cc: Sean Paul Cc: David Airlie Cc: Daniel Vetter Cc: Chandan Uddaraju Cc: Kuogee Hsieh Cc: linux-arm-...@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: freedr...@lists.freedesktop.org Signed-off-by: Lee Jones Reviewed-by: Dmitry Baryshkov --- drivers/gpu/drm/msm/dp/dp_link.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/msm/dp/dp_link.c b/drivers/gpu/drm/msm/dp/dp_link.c index be986da78c4a5..1099604bd1c86 100644 --- a/drivers/gpu/drm/msm/dp/dp_link.c +++ b/drivers/gpu/drm/msm/dp/dp_link.c @@ -364,7 +364,7 @@ static int dp_link_parse_timing_params3(struct dp_link_private *link, } /** - * dp_parse_video_pattern_params() - parses video pattern parameters from DPCD + * dp_link_parse_video_pattern_params() - parses video pattern parameters from DPCD * @link: Display Port Driver data * * Returns 0 if it successfully parses the video link pattern and the link @@ -563,7 +563,7 @@ static int dp_link_parse_link_training_params(struct dp_link_private *link) } /** - * dp_parse_phy_test_params() - parses the phy link parameters + * dp_link_parse_phy_test_params() - parses the phy link parameters * @link: Display Port Driver data * * Parses the DPCD (Byte 0x248) for the DP PHY link pattern that is being @@ -961,7 +961,7 @@ static int dp_link_process_link_status_update(struct dp_link_private *link) } /** - * dp_link_process_downstream_port_status_change() - process port status changes + * dp_link_process_ds_port_status_change() - process port status changes * @link: Display Port Driver data * * This function will handle downstream port updates that are initiated by -- With best wishes Dmitry
Re: [RESEND 12/26] drm/msm/msm_gem: Demote kernel-doc abuses
On 02/06/2021 17:32, Lee Jones wrote: Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/msm/msm_gem.c:364: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst drivers/gpu/drm/msm/msm_gem.c:763: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst Cc: Rob Clark Cc: Sean Paul Cc: David Airlie Cc: Daniel Vetter Cc: Sumit Semwal Cc: "Christian König" Cc: linux-arm-...@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: freedr...@lists.freedesktop.org Cc: linux-me...@vger.kernel.org Cc: linaro-mm-...@lists.linaro.org Signed-off-by: Lee Jones Reviewed-by: Dmitry Baryshkov --- drivers/gpu/drm/msm/msm_gem.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c index 56df86e5f7400..15434deb19334 100644 --- a/drivers/gpu/drm/msm/msm_gem.c +++ b/drivers/gpu/drm/msm/msm_gem.c @@ -372,7 +372,7 @@ static void del_vma(struct msm_gem_vma *vma) kfree(vma); } -/** +/* * If close is true, this also closes the VMA (releasing the allocated * iova range) in addition to removing the iommu mapping. In the eviction * case (!close), we keep the iova allocated, but only remove the iommu @@ -773,7 +773,7 @@ void msm_gem_purge(struct drm_gem_object *obj) 0, (loff_t)-1); } -/** +/* * Unpin the backing pages and make them available to be swapped out. */ void msm_gem_evict(struct drm_gem_object *obj) -- With best wishes Dmitry
[PATCH] udmabuf: Add support for mapping hugepages (v2)
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 offsets are calculated correctly when the
range of subpage allocations cuts across multiple hugepages.
Cc: Gerd Hoffmann
Signed-off-by: Vivek Kasireddy
---
drivers/dma-buf/udmabuf.c | 46 ---
1 file changed, 38 insertions(+), 8 deletions(-)
diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
index db732f71e59a..f053d12a1eb3 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 */
@@ -162,8 +163,10 @@ static long udmabuf_create(struct miscdevice *device,
struct file *memfd = NULL;
struct udmabuf *ubuf;
struct dma_buf *buf;
- pgoff_t pgoff, pgcnt, pgidx, pgbuf = 0, pglimit;
- struct page *page;
+ pgoff_t pgoff, pgcnt, pgidx, pgbuf = 0, pglimit, subpgoff;
+ uint32_t maxsubpgs;
+ struct page *page, *hpage = NULL;
+ 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,12 +209,38 @@ 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)) {
+ 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 % maxsubpgs);
+ get_page(page);
+ put_page(hpage);
+
+ subpgoff++;
+ if (subpgoff % maxsubpgs == 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;
}
--
2.30.2
[PATCH v5] drm/msm/dp: power off DP phy at suspend
Normal DP suspend operation contains two steps, display off followed
by dp suspend, to complete system wide suspending cycle if display is
up at that time. In this case, DP phy will be powered off at display
off. However there is an exception case that depending on the timing
of dongle plug in during system wide suspending, sometimes display off
procedure may be skipped and dp suspend was called directly. In this
case, dp phy is stay at powered on (phy->power_count = 1) so that at
next resume dp driver crash at main link clock enable due to phy is
not physically powered on. This patch will call dp_ctrl_off_link_stream()
to tear down main link and power off phy at dp_pm_suspend() if main link
had been brought up.
Changes in V2:
-- stashed changes into dp_ctrl.c
-- add is_phy_on to monitor phy state
Changes in V3:
-- delete is_phy_on
-- call dp_ctrl_off_link_stream() from dp_pm_suspend()
Changes in V4:
-- delete changes made at dp_power.c
-- move main link status checking to dp_pm_suspend
Changes in V5:
-- correct commit id at Fixes tag
Fixes: 8dbde399044b ("drm/msm/dp: handle irq_hpd with sink_count = 0 correctly)
Signed-off-by: Kuogee Hsieh
Tested-by: Stephen Boyd
Reviewed-by: Stephen Boyd
---
drivers/gpu/drm/msm/dp/dp_ctrl.c| 10 ++
drivers/gpu/drm/msm/dp/dp_display.c | 7 ++-
2 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index dbd8943..caf71fa 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -1827,10 +1827,12 @@ int dp_ctrl_off_link_stream(struct dp_ctrl *dp_ctrl)
dp_catalog_ctrl_mainlink_ctrl(ctrl->catalog, false);
- ret = dp_power_clk_enable(ctrl->power, DP_STREAM_PM, false);
- if (ret) {
- DRM_ERROR("Failed to disable pixel clocks. ret=%d\n", ret);
- return ret;
+ if (dp_power_clk_status(ctrl->power, DP_STREAM_PM)) {
+ ret = dp_power_clk_enable(ctrl->power, DP_STREAM_PM, false);
+ if (ret) {
+ DRM_ERROR("Failed to disable pclk. ret=%d\n", ret);
+ return ret;
+ }
}
ret = dp_power_clk_enable(ctrl->power, DP_CTRL_PM, false);
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index cdec0a3..9c59def 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -1327,8 +1327,13 @@ static int dp_pm_suspend(struct device *dev)
mutex_lock(&dp->event_mutex);
- if (dp->core_initialized == true)
+ if (dp->core_initialized == true) {
+ /* mainlink enabled */
+ if (dp_power_clk_status(dp->power, DP_CTRL_PM))
+ dp_ctrl_off_link_stream(dp->ctrl);
+
dp_display_host_deinit(dp);
+ }
dp->hpd_state = ST_SUSPENDED;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [Freedreno] [RFC PATCH 00/13] drm/msm: Add Display Stream Compression Support
On 2021-06-02 04:01, Vinod Koul wrote: On 27-05-21, 16:30, Rob Clark wrote: On Wed, May 26, 2021 at 8:00 AM Jeffrey Hugo wrote: > On Tue, May 25, 2021 at 11:46 PM Vinod Koul wrote: > Frankly, I don't like the MSM ACPI solution that I've seen on the laptops. > The ACPI assumes the entire MDSS (including DSI parts) and GPU is one > device, and ultimately handled by one driver. That driver needs to > get a value from UEFI (set by the bootloader) that is the "panel id". > Then the driver calls into ACPI (I think its _ROM, but I might be > mistaken, doing this from memory) with that id. It gets back a binary > blob which is mostly an xml file (format is publicly documented) that > contains the panel timings and such. tbh, I kinda suspect that having a single "gpu" device (which also includes venus, in addition to display, IIRC) in the ACPI tables is a windowsism, trying to make things look to userspace like a single "GPU card" in the x86 world.. but either way, I think the ACPI tables on the windows arm laptops which use dsi->bridge->edp is too much of a lost cause to even consider here. Possibly ACPI boot on these devices would be more feasible on newer devices which have direct eDP out of the SoC without requiring external bridge/panel glue. yeah that is always a very different world. although it might make sense to use information in tables and try to deduce information about the system can be helpful... I'd worry more about what makes sense in a DT world, when it comes to DT bindings. And do you have thoughts on that..? At the moment, I will comment on the bindings first and my idea on how to proceed. The bindings mentioned here: https://lore.kernel.org/dri-devel/20210521124946.3617862-3-vk...@kernel.org/ seem to be just taken directly from downstream which was not the plan. I think all of these should be part of the generic panel bindings as none of these are QC specific: @@ -188,6 +195,14 @@ Example: qcom,master-dsi; qcom,sync-dual-dsi; + qcom,mdss-dsc-enabled; + qcom,mdss-slice-height = <16>; + qcom,mdss-slice-width = <540>; + qcom,mdss-slice-per-pkt = <1>; + qcom,mdss-bit-per-component = <8>; + qcom,mdss-bit-per-pixel = <8>; + qcom,mdss-block-prediction-enable; + How about having a panel-dsc.yaml which will have these properties and have a panel-dsc node to have this information? I would like to hear the feedback on this proposal then the series can be reworked. Thanks Abhinav
[Bug 213333] New: Regression: amdgpu_gfxhub raises protection fault, crashes display
https://bugzilla.kernel.org/show_bug.cgi?id=21 Bug ID: 21 Summary: Regression: amdgpu_gfxhub raises protection fault, crashes display Product: Drivers Version: 2.5 Kernel Version: 5.13.0-rc4 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: unse...@protonmail.com Regression: No Created attachment 297137 --> https://bugzilla.kernel.org/attachment.cgi?id=297137&action=edit commit message and fault logs Change intended to clean up code functionally changes pointer arithmetic, and causes protection fault when amdgpu_bo_gpu_offset(bo) < adev->gmc.vram_start: bad commit: 0ca565ab97083, CC: oak.z...@amd.com, harish.kasiviswanat...@amd.com, christian.koe...@amd.com, alexander.deuc...@amd.com -- 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] drm/panel: nt35510: Do not fail if DSI read fails
Failing to read the MTP over DSI should not bring down the
system and make us bail out from using the display, it turns
out that this happens when toggling the display off and on,
and that write is often still working so the display output
is just fine. Printing an error is enough.
Tested by killing the Gnome session repeatedly on the
Samsung Skomer.
Fixes: 899f24ed8d3a ("drm/panel: Add driver for Novatek NT35510-based panels")
Cc: Stephan Gerhold
Reported-by: newb...@disroot.org
Signed-off-by: Linus Walleij
---
drivers/gpu/drm/panel/panel-novatek-nt35510.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-novatek-nt35510.c
b/drivers/gpu/drm/panel/panel-novatek-nt35510.c
index ef70140c5b09..873cbd38e6d3 100644
--- a/drivers/gpu/drm/panel/panel-novatek-nt35510.c
+++ b/drivers/gpu/drm/panel/panel-novatek-nt35510.c
@@ -706,9 +706,7 @@ static int nt35510_power_on(struct nt35510 *nt)
if (ret)
return ret;
- ret = nt35510_read_id(nt);
- if (ret)
- return ret;
+ nt35510_read_id(nt);
/* Set up stuff in manufacturer control, page 1 */
ret = nt35510_send_long(nt, dsi, MCS_CMD_MAUCCTR,
--
2.31.1
[PATCH v2] backlight: ktd253: Stabilize backlight
Remove interrupt disablement during backlight setting. It is
way to dangerous and makes platforms instable by having it
miss vblank IRQs leading to the graphics derailing.
The code is using ndelay() which is not available on
platforms such as ARM and will result in 32 * udelay(1)
which is substantial.
Add some code to detect if an interrupt occurs during the
tight loop and in that case just redo it from the top.
Fixes: 5317f37e48b9 ("backlight: Add Kinetic KTD253 backlight driver")
Cc: Stephan Gerhold
Reported-by: newb...@disroot.org
Signed-off-by: Linus Walleij
---
ChangeLog v1->v2:
- Alter the dimming code to check for how many ns the pulse
is low, and if it gets to ~100 us then redo from start.
This is to account for the advent that an IRQ arrives while
setting backlight and hits the low pulse making it way
too long.
---
drivers/video/backlight/ktd253-backlight.c | 70 --
1 file changed, 53 insertions(+), 17 deletions(-)
diff --git a/drivers/video/backlight/ktd253-backlight.c
b/drivers/video/backlight/ktd253-backlight.c
index a7df5bcca9da..dca19769846e 100644
--- a/drivers/video/backlight/ktd253-backlight.c
+++ b/drivers/video/backlight/ktd253-backlight.c
@@ -25,6 +25,7 @@
#define KTD253_T_LOW_NS (200 + 10) /* Additional 10ns as safety factor */
#define KTD253_T_HIGH_NS (200 + 10) /* Additional 10ns as safety factor */
+#define KTD253_T_OFF_CRIT_NS 10 /* 100 us, now it doesn't look good */
#define KTD253_T_OFF_MS 3
struct ktd253_backlight {
@@ -34,13 +35,50 @@ struct ktd253_backlight {
u16 ratio;
};
+static void ktd253_backlight_set_max_ratio(struct ktd253_backlight *ktd253)
+{
+ gpiod_set_value_cansleep(ktd253->gpiod, 1);
+ ndelay(KTD253_T_HIGH_NS);
+ /* We always fall back to this when we power on */
+}
+
+static int ktd253_backlight_stepdown(struct ktd253_backlight *ktd253)
+{
+ /*
+* These GPIO operations absolutely can NOT sleep so no _cansleep
+* suffixes, and no using GPIO expanders on slow buses for this!
+*
+* The maximum number of cycles of the loop is 32 so the time taken
+* should nominally be:
+* (T_LOW_NS + T_HIGH_NS + loop_time) * 32
+*
+* Architectures do not always support ndelay() and we will get a few us
+* instead. If we get to a critical time limit an interrupt has likely
+* occured in the low part of the loop and we need to restart from the
+* top so we have the backlight in a known state.
+*/
+ u64 ns;
+
+ ns = ktime_get_ns();
+ gpiod_set_value(ktd253->gpiod, 0);
+ ndelay(KTD253_T_LOW_NS);
+ gpiod_set_value(ktd253->gpiod, 1);
+ ns = ktime_get_ns() - ns;
+ if (ns >= KTD253_T_OFF_CRIT_NS) {
+ dev_err(ktd253->dev, "PCM on backlight took too long (%llu
ns)\n", ns);
+ return -EAGAIN;
+ }
+ ndelay(KTD253_T_HIGH_NS);
+ return 0;
+}
+
static int ktd253_backlight_update_status(struct backlight_device *bl)
{
struct ktd253_backlight *ktd253 = bl_get_data(bl);
int brightness = backlight_get_brightness(bl);
u16 target_ratio;
u16 current_ratio = ktd253->ratio;
- unsigned long flags;
+ int ret;
dev_dbg(ktd253->dev, "new brightness/ratio: %d/32\n", brightness);
@@ -62,37 +100,35 @@ static int ktd253_backlight_update_status(struct
backlight_device *bl)
}
if (current_ratio == 0) {
- gpiod_set_value_cansleep(ktd253->gpiod, 1);
- ndelay(KTD253_T_HIGH_NS);
- /* We always fall back to this when we power on */
+ ktd253_backlight_set_max_ratio(ktd253);
current_ratio = KTD253_MAX_RATIO;
}
- /*
-* WARNING:
-* The loop to set the correct current level is performed
-* with interrupts disabled as it is timing critical.
-* The maximum number of cycles of the loop is 32
-* so the time taken will be (T_LOW_NS + T_HIGH_NS + loop_time) * 32,
-*/
- local_irq_save(flags);
while (current_ratio != target_ratio) {
/*
* These GPIO operations absolutely can NOT sleep so no
* _cansleep suffixes, and no using GPIO expanders on
* slow buses for this!
*/
- gpiod_set_value(ktd253->gpiod, 0);
- ndelay(KTD253_T_LOW_NS);
- gpiod_set_value(ktd253->gpiod, 1);
- ndelay(KTD253_T_HIGH_NS);
+ ret = ktd253_backlight_stepdown(ktd253);
+ if (ret == -EAGAIN) {
+ /*
+* Something disturbed the backlight setting code when
+* running so we need to bring the PWM back to a known
+* state. This shouldn't happen too much.
+*/
+ gpiod_set_value_cansleep(ktd25
[v3 PATCH 1/2] drm/i915/guc: Replace CTB array with explicit members
From: Michal Wajdeczko
Upcoming GuC firmware will always require just two CTBs and we
also plan to configure them with different sizes, so definining
them as array is no longer suitable.
v2: Use %p for ptrdiff print
v3: Use %tx for ptrdiff print
Signed-off-by: Michal Wajdeczko
Signed-off-by: Matthew Brost
Reviewed-by: Matthew Brost
Reported-by: kernel test robot
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 46 ---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 7 +++-
2 files changed, 30 insertions(+), 23 deletions(-)
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 34c582105860..ec795d7c3a7d 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -168,10 +168,10 @@ int intel_guc_ct_init(struct intel_guc_ct *ct)
struct intel_guc *guc = ct_to_guc(ct);
struct guc_ct_buffer_desc *desc;
u32 blob_size;
+ u32 cmds_size;
void *blob;
u32 *cmds;
int err;
- int i;
GEM_BUG_ON(ct->vma);
@@ -207,15 +207,23 @@ int intel_guc_ct_init(struct intel_guc_ct *ct)
CT_DEBUG(ct, "base=%#x size=%u\n", intel_guc_ggtt_offset(guc, ct->vma),
blob_size);
- /* store pointers to desc and cmds */
- for (i = 0; i < ARRAY_SIZE(ct->ctbs); i++) {
- GEM_BUG_ON((i != CTB_SEND) && (i != CTB_RECV));
+ /* store pointers to desc and cmds for send ctb */
+ desc = blob;
+ cmds = blob + PAGE_SIZE / 2;
+ cmds_size = PAGE_SIZE / 4;
+ CT_DEBUG(ct, "%s desc %#tx cmds %#tx size %u\n", "send",
+ptrdiff(desc, blob), ptrdiff(cmds, blob), cmds_size);
- desc = blob + PAGE_SIZE / 4 * i;
- cmds = blob + PAGE_SIZE / 4 * i + PAGE_SIZE / 2;
+ guc_ct_buffer_init(&ct->ctbs.send, desc, cmds, cmds_size);
- guc_ct_buffer_init(&ct->ctbs[i], desc, cmds, PAGE_SIZE / 4);
- }
+ /* store pointers to desc and cmds for recv ctb */
+ desc = blob + PAGE_SIZE / 4;
+ cmds = blob + PAGE_SIZE / 4 + PAGE_SIZE / 2;
+ cmds_size = PAGE_SIZE / 4;
+ CT_DEBUG(ct, "%s desc %#tx cmds %#tx size %u\n", "recv",
+ptrdiff(desc, blob), ptrdiff(cmds, blob), cmds_size);
+
+ guc_ct_buffer_init(&ct->ctbs.recv, desc, cmds, cmds_size);
return 0;
}
@@ -246,7 +254,6 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
u32 base, cmds;
void *blob;
int err;
- int i;
GEM_BUG_ON(ct->enabled);
@@ -257,28 +264,25 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
/* blob should start with send descriptor */
blob = __px_vaddr(ct->vma->obj);
- GEM_BUG_ON(blob != ct->ctbs[CTB_SEND].desc);
+ GEM_BUG_ON(blob != ct->ctbs.send.desc);
/* (re)initialize descriptors */
- for (i = 0; i < ARRAY_SIZE(ct->ctbs); i++) {
- GEM_BUG_ON((i != CTB_SEND) && (i != CTB_RECV));
+ cmds = base + ptrdiff(ct->ctbs.send.cmds, blob);
+ guc_ct_buffer_reset(&ct->ctbs.send, cmds);
- cmds = base + ptrdiff(ct->ctbs[i].cmds, blob);
- CT_DEBUG(ct, "%d: cmds addr=%#x\n", i, cmds);
-
- guc_ct_buffer_reset(&ct->ctbs[i], cmds);
- }
+ cmds = base + ptrdiff(ct->ctbs.recv.cmds, blob);
+ guc_ct_buffer_reset(&ct->ctbs.recv, cmds);
/*
* Register both CT buffers starting with RECV buffer.
* Descriptors are in first half of the blob.
*/
- err = ct_register_buffer(ct, base + ptrdiff(ct->ctbs[CTB_RECV].desc,
blob),
+ err = ct_register_buffer(ct, base + ptrdiff(ct->ctbs.recv.desc, blob),
INTEL_GUC_CT_BUFFER_TYPE_RECV);
if (unlikely(err))
goto err_out;
- err = ct_register_buffer(ct, base + ptrdiff(ct->ctbs[CTB_SEND].desc,
blob),
+ err = ct_register_buffer(ct, base + ptrdiff(ct->ctbs.send.desc, blob),
INTEL_GUC_CT_BUFFER_TYPE_SEND);
if (unlikely(err))
goto err_deregister;
@@ -341,7 +345,7 @@ static int ct_write(struct intel_guc_ct *ct,
u32 len /* in dwords */,
u32 fence)
{
- struct intel_guc_ct_buffer *ctb = &ct->ctbs[CTB_SEND];
+ struct intel_guc_ct_buffer *ctb = &ct->ctbs.send;
struct guc_ct_buffer_desc *desc = ctb->desc;
u32 head = desc->head;
u32 tail = desc->tail;
@@ -557,7 +561,7 @@ static inline bool ct_header_is_response(u32 header)
static int ct_read(struct intel_guc_ct *ct, u32 *data)
{
- struct intel_guc_ct_buffer *ctb = &ct->ctbs[CTB_RECV];
+ struct intel_guc_ct_buffer *ctb = &ct->ctbs.recv;
struct guc_ct_buffer_desc *desc = ctb->desc;
u32 head = desc->head;
u32 tail = desc->tail;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
inde
[v3 PATCH 2/2] drm/i915/guc: Update sizes of CTB buffers
From: Michal Wajdeczko
Future GuC will require CTB buffers sizes to be multiple of 4K.
Make these changes now as this shouldn't impact us too much.
Signed-off-by: Michal Wajdeczko
Signed-off-by: Matthew Brost
Reviewed-by: Matthew Brost
Cc: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 60 ---
1 file changed, 32 insertions(+), 28 deletions(-)
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 ec795d7c3a7d..8d1173032431 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -38,6 +38,32 @@ static inline struct drm_device *ct_to_drm(struct
intel_guc_ct *ct)
#define CT_PROBE_ERROR(_ct, _fmt, ...) \
i915_probe_error(ct_to_i915(ct), "CT: " _fmt, ##__VA_ARGS__)
+/**
+ * DOC: CTB Blob
+ *
+ * We allocate single blob to hold both CTB descriptors and buffers:
+ *
+ * ++---+--+
+ * | offset | contents | size |
+ * ++===+==+
+ * | 0x | H2G `CTB Descriptor`_ (send) | |
+ * ++---+ 4K |
+ * | 0x0800 | G2H `CTB Descriptor`_ (recv) | |
+ * ++---+--+
+ * | 0x1000 | H2G `CT Buffer`_ (send) | n*4K |
+ * || | |
+ * ++---+--+
+ * | 0x1000 | G2H `CT Buffer`_ (recv) | m*4K |
+ * | + n*4K | | |
+ * ++---+--+
+ *
+ * Size of each `CT Buffer`_ must be multiple of 4K.
+ * As we don't expect too many messages, for now use minimum sizes.
+ */
+#define CTB_DESC_SIZE ALIGN(sizeof(struct guc_ct_buffer_desc), SZ_2K)
+#define CTB_H2G_BUFFER_SIZE(SZ_4K)
+#define CTB_G2H_BUFFER_SIZE(SZ_4K)
+
struct ct_request {
struct list_head link;
u32 fence;
@@ -175,29 +201,7 @@ int intel_guc_ct_init(struct intel_guc_ct *ct)
GEM_BUG_ON(ct->vma);
- /* We allocate 1 page to hold both descriptors and both buffers.
-* ___.
-* |desc (SEND)| :
-* |___| PAGE/4
-* :___:
-* |desc (RECV)| :
-* |___| PAGE/4
-* :___:
-* |cmds (SEND)|
-* | PAGE/4
-* |___|
-* |cmds (RECV)|
-* | PAGE/4
-* |___|
-*
-* Each message can use a maximum of 32 dwords and we don't expect to
-* have more than 1 in flight at any time, so we have enough space.
-* Some logic further ahead will rely on the fact that there is only 1
-* page and that it is always mapped, so if the size is changed the
-* other code will need updating as well.
-*/
-
- blob_size = PAGE_SIZE;
+ blob_size = 2 * CTB_DESC_SIZE + CTB_H2G_BUFFER_SIZE +
CTB_G2H_BUFFER_SIZE;
err = intel_guc_allocate_and_map_vma(guc, blob_size, &ct->vma, &blob);
if (unlikely(err)) {
CT_PROBE_ERROR(ct, "Failed to allocate %u for CTB data (%pe)\n",
@@ -209,17 +213,17 @@ int intel_guc_ct_init(struct intel_guc_ct *ct)
/* store pointers to desc and cmds for send ctb */
desc = blob;
- cmds = blob + PAGE_SIZE / 2;
- cmds_size = PAGE_SIZE / 4;
+ cmds = blob + 2 * CTB_DESC_SIZE;
+ cmds_size = CTB_H2G_BUFFER_SIZE;
CT_DEBUG(ct, "%s desc %#tx cmds %#tx size %u\n", "send",
ptrdiff(desc, blob), ptrdiff(cmds, blob), cmds_size);
guc_ct_buffer_init(&ct->ctbs.send, desc, cmds, cmds_size);
/* store pointers to desc and cmds for recv ctb */
- desc = blob + PAGE_SIZE / 4;
- cmds = blob + PAGE_SIZE / 4 + PAGE_SIZE / 2;
- cmds_size = PAGE_SIZE / 4;
+ desc = blob + CTB_DESC_SIZE;
+ cmds = blob + 2 * CTB_DESC_SIZE + CTB_H2G_BUFFER_SIZE;
+ cmds_size = CTB_G2H_BUFFER_SIZE;
CT_DEBUG(ct, "%s desc %#tx cmds %#tx size %u\n", "recv",
ptrdiff(desc, blob), ptrdiff(cmds, blob), cmds_size);
--
2.28.0
Re: [PATCH] drm/pl111: Actually fix CONFIG_VEXPRESS_CONFIG depends
[gmail is funny]
On Thu, Jun 3, 2021 at 11:58 PM Kees Cook wrote:
>
> VEXPRESS_CONFIG needs to either be missing, built-in, or modular when
> pl111 is modular. Update the Kconfig to reflect the need.
>
> Cc: Emma Anholt
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: dri-devel@lists.freedesktop.org
> Fixes: 4dc7c97d04dc ("drm/pl111: depend on CONFIG_VEXPRESS_CONFIG")
> Signed-off-by: Kees Cook
> ---
> drivers/gpu/drm/pl111/Kconfig | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/pl111/Kconfig b/drivers/gpu/drm/pl111/Kconfig
> index c5210a5bef1b..b84879ca430d 100644
> --- a/drivers/gpu/drm/pl111/Kconfig
> +++ b/drivers/gpu/drm/pl111/Kconfig
> @@ -2,7 +2,8 @@
> config DRM_PL111
> tristate "DRM Support for PL111 CLCD Controller"
> depends on DRM
> - depends on VEXPRESS_CONFIG
> + depends on ARM || ARM64 || COMPILE_TEST
> + depends on !VEXPRESS_CONFIG || VEXPRESS_CONFIG=DRM
I thought the canonical way to represent optional dependencies was
depends on FOO || FOO=n
Since we don't really care whether it's the same as DRM (that's
sufficient, but a bit too much), it needs to match DRM_PL111, or be
disabled. It's at least the pattern various drm drivers use for AGP.
If that still works in testing, can you pls respin?
-Daniel
> depends on COMMON_CLK
> select DRM_KMS_HELPER
> select DRM_KMS_CMA_HELPER
> --
> 2.25.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH] drm/pl111: Actually fix CONFIG_VEXPRESS_CONFIG depends
On Thu, Jun 3, 2021 at 11:58 PM Kees Cook wrote:
>
> VEXPRESS_CONFIG needs to either be missing, built-in, or modular when
> pl111 is modular. Update the Kconfig to reflect the need.
>
> Cc: Emma Anholt
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: dri-devel@lists.freedesktop.org
> Fixes: 4dc7c97d04dc ("drm/pl111: depend on CONFIG_VEXPRESS_CONFIG")
> Signed-off-by: Kees Cook
> ---
> drivers/gpu/drm/pl111/Kconfig | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/pl111/Kconfig b/drivers/gpu/drm/pl111/Kconfig
> index c5210a5bef1b..b84879ca430d 100644
> --- a/drivers/gpu/drm/pl111/Kconfig
> +++ b/drivers/gpu/drm/pl111/Kconfig
> @@ -2,7 +2,8 @@
> config DRM_PL111
> tristate "DRM Support for PL111 CLCD Controller"
> depends on DRM
> - depends on VEXPRESS_CONFIG
> + depends on ARM || ARM64 || COMPILE_TEST
> + depends on !VEXPRESS_CONFIG || VEXPRESS_CONFIG=DRM
Hm I thought the canonical way to express optional depdencies was
> depends on COMMON_CLK
> select DRM_KMS_HELPER
> select DRM_KMS_CMA_HELPER
> --
> 2.25.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH 1/2] drm/i915/guc: Replace CTB array with explicit members
From: Michal Wajdeczko
Upcoming GuC firmware will always require just two CTBs and we
also plan to configure them with different sizes, so definining
them as array is no longer suitable.
Signed-off-by: Michal Wajdeczko
Signed-off-by: Matthew Brost
Reviewed-by: Matthew Brost
Reported-by: kernel test robot
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 46 ---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 7 +++-
2 files changed, 30 insertions(+), 23 deletions(-)
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 34c582105860..882ae1ed41b0 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -168,10 +168,10 @@ int intel_guc_ct_init(struct intel_guc_ct *ct)
struct intel_guc *guc = ct_to_guc(ct);
struct guc_ct_buffer_desc *desc;
u32 blob_size;
+ u32 cmds_size;
void *blob;
u32 *cmds;
int err;
- int i;
GEM_BUG_ON(ct->vma);
@@ -207,15 +207,23 @@ int intel_guc_ct_init(struct intel_guc_ct *ct)
CT_DEBUG(ct, "base=%#x size=%u\n", intel_guc_ggtt_offset(guc, ct->vma),
blob_size);
- /* store pointers to desc and cmds */
- for (i = 0; i < ARRAY_SIZE(ct->ctbs); i++) {
- GEM_BUG_ON((i != CTB_SEND) && (i != CTB_RECV));
+ /* store pointers to desc and cmds for send ctb */
+ desc = blob;
+ cmds = blob + PAGE_SIZE / 2;
+ cmds_size = PAGE_SIZE / 4;
+ CT_DEBUG(ct, "%s desc %#p cmds %#p size %u\n", "send",
+ptrdiff(desc, blob), ptrdiff(cmds, blob), cmds_size);
- desc = blob + PAGE_SIZE / 4 * i;
- cmds = blob + PAGE_SIZE / 4 * i + PAGE_SIZE / 2;
+ guc_ct_buffer_init(&ct->ctbs.send, desc, cmds, cmds_size);
- guc_ct_buffer_init(&ct->ctbs[i], desc, cmds, PAGE_SIZE / 4);
- }
+ /* store pointers to desc and cmds for recv ctb */
+ desc = blob + PAGE_SIZE / 4;
+ cmds = blob + PAGE_SIZE / 4 + PAGE_SIZE / 2;
+ cmds_size = PAGE_SIZE / 4;
+ CT_DEBUG(ct, "%s desc %#p cmds %#p size %u\n", "recv",
+ptrdiff(desc, blob), ptrdiff(cmds, blob), cmds_size);
+
+ guc_ct_buffer_init(&ct->ctbs.recv, desc, cmds, cmds_size);
return 0;
}
@@ -246,7 +254,6 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
u32 base, cmds;
void *blob;
int err;
- int i;
GEM_BUG_ON(ct->enabled);
@@ -257,28 +264,25 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
/* blob should start with send descriptor */
blob = __px_vaddr(ct->vma->obj);
- GEM_BUG_ON(blob != ct->ctbs[CTB_SEND].desc);
+ GEM_BUG_ON(blob != ct->ctbs.send.desc);
/* (re)initialize descriptors */
- for (i = 0; i < ARRAY_SIZE(ct->ctbs); i++) {
- GEM_BUG_ON((i != CTB_SEND) && (i != CTB_RECV));
+ cmds = base + ptrdiff(ct->ctbs.send.cmds, blob);
+ guc_ct_buffer_reset(&ct->ctbs.send, cmds);
- cmds = base + ptrdiff(ct->ctbs[i].cmds, blob);
- CT_DEBUG(ct, "%d: cmds addr=%#x\n", i, cmds);
-
- guc_ct_buffer_reset(&ct->ctbs[i], cmds);
- }
+ cmds = base + ptrdiff(ct->ctbs.recv.cmds, blob);
+ guc_ct_buffer_reset(&ct->ctbs.recv, cmds);
/*
* Register both CT buffers starting with RECV buffer.
* Descriptors are in first half of the blob.
*/
- err = ct_register_buffer(ct, base + ptrdiff(ct->ctbs[CTB_RECV].desc,
blob),
+ err = ct_register_buffer(ct, base + ptrdiff(ct->ctbs.recv.desc, blob),
INTEL_GUC_CT_BUFFER_TYPE_RECV);
if (unlikely(err))
goto err_out;
- err = ct_register_buffer(ct, base + ptrdiff(ct->ctbs[CTB_SEND].desc,
blob),
+ err = ct_register_buffer(ct, base + ptrdiff(ct->ctbs.send.desc, blob),
INTEL_GUC_CT_BUFFER_TYPE_SEND);
if (unlikely(err))
goto err_deregister;
@@ -341,7 +345,7 @@ static int ct_write(struct intel_guc_ct *ct,
u32 len /* in dwords */,
u32 fence)
{
- struct intel_guc_ct_buffer *ctb = &ct->ctbs[CTB_SEND];
+ struct intel_guc_ct_buffer *ctb = &ct->ctbs.send;
struct guc_ct_buffer_desc *desc = ctb->desc;
u32 head = desc->head;
u32 tail = desc->tail;
@@ -557,7 +561,7 @@ static inline bool ct_header_is_response(u32 header)
static int ct_read(struct intel_guc_ct *ct, u32 *data)
{
- struct intel_guc_ct_buffer *ctb = &ct->ctbs[CTB_RECV];
+ struct intel_guc_ct_buffer *ctb = &ct->ctbs.recv;
struct guc_ct_buffer_desc *desc = ctb->desc;
u32 head = desc->head;
u32 tail = desc->tail;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h
index 4009e2dd0de4..fc9486779e87 100644
--- a/drivers/gpu/drm/i915/g
[PATCH 2/2] drm/i915/guc: Update sizes of CTB buffers
From: Michal Wajdeczko
Future GuC will require CTB buffers sizes to be multiple of 4K.
Make these changes now as this shouldn't impact us too much.
Signed-off-by: Michal Wajdeczko
Signed-off-by: Matthew Brost
Reviewed-by: Matthew Brost
Cc: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 60 ---
1 file changed, 32 insertions(+), 28 deletions(-)
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 882ae1ed41b0..8d70f637640b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -38,6 +38,32 @@ static inline struct drm_device *ct_to_drm(struct
intel_guc_ct *ct)
#define CT_PROBE_ERROR(_ct, _fmt, ...) \
i915_probe_error(ct_to_i915(ct), "CT: " _fmt, ##__VA_ARGS__)
+/**
+ * DOC: CTB Blob
+ *
+ * We allocate single blob to hold both CTB descriptors and buffers:
+ *
+ * ++---+--+
+ * | offset | contents | size |
+ * ++===+==+
+ * | 0x | H2G `CTB Descriptor`_ (send) | |
+ * ++---+ 4K |
+ * | 0x0800 | G2H `CTB Descriptor`_ (recv) | |
+ * ++---+--+
+ * | 0x1000 | H2G `CT Buffer`_ (send) | n*4K |
+ * || | |
+ * ++---+--+
+ * | 0x1000 | G2H `CT Buffer`_ (recv) | m*4K |
+ * | + n*4K | | |
+ * ++---+--+
+ *
+ * Size of each `CT Buffer`_ must be multiple of 4K.
+ * As we don't expect too many messages, for now use minimum sizes.
+ */
+#define CTB_DESC_SIZE ALIGN(sizeof(struct guc_ct_buffer_desc), SZ_2K)
+#define CTB_H2G_BUFFER_SIZE(SZ_4K)
+#define CTB_G2H_BUFFER_SIZE(SZ_4K)
+
struct ct_request {
struct list_head link;
u32 fence;
@@ -175,29 +201,7 @@ int intel_guc_ct_init(struct intel_guc_ct *ct)
GEM_BUG_ON(ct->vma);
- /* We allocate 1 page to hold both descriptors and both buffers.
-* ___.
-* |desc (SEND)| :
-* |___| PAGE/4
-* :___:
-* |desc (RECV)| :
-* |___| PAGE/4
-* :___:
-* |cmds (SEND)|
-* | PAGE/4
-* |___|
-* |cmds (RECV)|
-* | PAGE/4
-* |___|
-*
-* Each message can use a maximum of 32 dwords and we don't expect to
-* have more than 1 in flight at any time, so we have enough space.
-* Some logic further ahead will rely on the fact that there is only 1
-* page and that it is always mapped, so if the size is changed the
-* other code will need updating as well.
-*/
-
- blob_size = PAGE_SIZE;
+ blob_size = 2 * CTB_DESC_SIZE + CTB_H2G_BUFFER_SIZE +
CTB_G2H_BUFFER_SIZE;
err = intel_guc_allocate_and_map_vma(guc, blob_size, &ct->vma, &blob);
if (unlikely(err)) {
CT_PROBE_ERROR(ct, "Failed to allocate %u for CTB data (%pe)\n",
@@ -209,17 +213,17 @@ int intel_guc_ct_init(struct intel_guc_ct *ct)
/* store pointers to desc and cmds for send ctb */
desc = blob;
- cmds = blob + PAGE_SIZE / 2;
- cmds_size = PAGE_SIZE / 4;
+ cmds = blob + 2 * CTB_DESC_SIZE;
+ cmds_size = CTB_H2G_BUFFER_SIZE;
CT_DEBUG(ct, "%s desc %#p cmds %#p size %u\n", "send",
ptrdiff(desc, blob), ptrdiff(cmds, blob), cmds_size);
guc_ct_buffer_init(&ct->ctbs.send, desc, cmds, cmds_size);
/* store pointers to desc and cmds for recv ctb */
- desc = blob + PAGE_SIZE / 4;
- cmds = blob + PAGE_SIZE / 4 + PAGE_SIZE / 2;
- cmds_size = PAGE_SIZE / 4;
+ desc = blob + CTB_DESC_SIZE;
+ cmds = blob + 2 * CTB_DESC_SIZE + CTB_H2G_BUFFER_SIZE;
+ cmds_size = CTB_G2H_BUFFER_SIZE;
CT_DEBUG(ct, "%s desc %#p cmds %#p size %u\n", "recv",
ptrdiff(desc, blob), ptrdiff(cmds, blob), cmds_size);
--
2.28.0
Re: [PATCH 0/7] libdrm tests for hot-unplug fe goature
Is libdrm on gitlab ? I wasn't aware of this. I assumed code reviews still go through dri-devel. Andrey From: Alex Deucher Sent: 03 June 2021 17:20 To: Grodzovsky, Andrey Cc: Maling list - DRI developers ; amd-gfx list ; Deucher, Alexander ; Christian König Subject: Re: [PATCH 0/7] libdrm tests for hot-unplug feature Please open a gitlab MR for these. Alex On Tue, Jun 1, 2021 at 4:17 PM Andrey Grodzovsky wrote: > > Adding some tests to acompany the recently added hot-unplug > feature. For now the test suite is disabled until the feature > propagates from drm-misc-next to drm-next. > > Andrey Grodzovsky (7): > tests/amdgpu: Fix valgrind warning > xf86drm: Add function to retrieve char device path > test/amdgpu: Add helper functions for hot unplug > test/amdgpu/hotunplug: Add test suite for GPU unplug > test/amdgpu/hotunplug: Add basic test > tests/amdgpu/hotunplug: Add unplug with cs test. > tests/amdgpu/hotunplug: Add hotunplug with exported bo test > > tests/amdgpu/amdgpu_test.c | 42 +++- > tests/amdgpu/amdgpu_test.h | 26 +++ > tests/amdgpu/basic_tests.c | 5 +- > tests/amdgpu/hotunplug_tests.c | 357 + > tests/amdgpu/meson.build | 1 + > xf86drm.c | 23 +++ > xf86drm.h | 1 + > 7 files changed, 450 insertions(+), 5 deletions(-) > create mode 100644 tests/amdgpu/hotunplug_tests.c > > -- > 2.25.1 > > ___ > amd-gfx mailing list > amd-...@lists.freedesktop.org > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=04%7C01%7Candrey.grodzovsky%40amd.com%7C8fb7f614798b4d19572e08d926d57530%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637583520507282588%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ozqlNQACGvLJugQ2GNvFl8CKgAH0thqMRpWjHpURlyc%3D&reserved=0
Re: [PATCH v2] drm/pl111: Fix CONFIG_VEXPRESS_CONFIG depend
On Thu, Jun 03, 2021 at 02:34:12PM -0700, Kees Cook wrote:
> Avoid randconfig build failures by requiring VEXPRESS_CONFIG either be
> missing, built-in, or modular when pl111 is modular. Fixing this warning
> when:
>
> CONFIG_VEXPRESS_CONFIG=m
> CONFIG_DRM_PL111=y
>
> aarch64-linux-gnu-ld: drivers/gpu/drm/pl111/pl111_versatile.o: in function
> `pl111_vexpress_clcd_init':
> pl111_versatile.c:(.text+0x220): undefined reference to
> `devm_regmap_init_vexpress_config'
Please ignore this in favor of:
https://lore.kernel.org/lkml/20210603215819.3904733-1-keesc...@chromium.org
Thanks!
-Kees
>
> Reported-by: kernel test robot
> Link: https://lore.kernel.org/lkml/202105300926.fx0myysp-...@intel.com/
> Fixes: 826fc86b5903 ("drm: pl111: Move VExpress setup into versatile init")
> Signed-off-by: Kees Cook
> ---
> v2: avoid forcing VEXPRESS_CONFIG be enabled
> v1: https://lore.kernel.org/lkml/20210602215252.695994-4-keesc...@chromium.org
> ---
> drivers/gpu/drm/pl111/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/pl111/Kconfig b/drivers/gpu/drm/pl111/Kconfig
> index 80f6748055e3..b84879ca430d 100644
> --- a/drivers/gpu/drm/pl111/Kconfig
> +++ b/drivers/gpu/drm/pl111/Kconfig
> @@ -3,6 +3,7 @@ config DRM_PL111
> tristate "DRM Support for PL111 CLCD Controller"
> depends on DRM
> depends on ARM || ARM64 || COMPILE_TEST
> + depends on !VEXPRESS_CONFIG || VEXPRESS_CONFIG=DRM
> depends on COMMON_CLK
> select DRM_KMS_HELPER
> select DRM_KMS_CMA_HELPER
> --
> 2.25.1
>
--
Kees Cook
[PATCH] drm/pl111: Actually fix CONFIG_VEXPRESS_CONFIG depends
VEXPRESS_CONFIG needs to either be missing, built-in, or modular when
pl111 is modular. Update the Kconfig to reflect the need.
Cc: Emma Anholt
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Fixes: 4dc7c97d04dc ("drm/pl111: depend on CONFIG_VEXPRESS_CONFIG")
Signed-off-by: Kees Cook
---
drivers/gpu/drm/pl111/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/pl111/Kconfig b/drivers/gpu/drm/pl111/Kconfig
index c5210a5bef1b..b84879ca430d 100644
--- a/drivers/gpu/drm/pl111/Kconfig
+++ b/drivers/gpu/drm/pl111/Kconfig
@@ -2,7 +2,8 @@
config DRM_PL111
tristate "DRM Support for PL111 CLCD Controller"
depends on DRM
- depends on VEXPRESS_CONFIG
+ depends on ARM || ARM64 || COMPILE_TEST
+ depends on !VEXPRESS_CONFIG || VEXPRESS_CONFIG=DRM
depends on COMMON_CLK
select DRM_KMS_HELPER
select DRM_KMS_CMA_HELPER
--
2.25.1
Re: [PATCH 3/3] drm/pl111: depend on CONFIG_VEXPRESS_CONFIG
On Thu, Jun 03, 2021 at 11:41:01PM +0200, Daniel Vetter wrote: > On Thu, Jun 3, 2021 at 11:29 PM Kees Cook wrote: > > > > On Thu, Jun 03, 2021 at 02:19:52PM -0700, Kees Cook wrote: > > > On Thu, Jun 03, 2021 at 09:19:42PM +0200, Daniel Vetter wrote: > > > > On Thu, Jun 3, 2021 at 8:43 PM Rob Herring wrote: > > > > > > > > > > On Wed, Jun 2, 2021 at 4:53 PM Kees Cook > > > > > wrote: > > > > > > > > > > > > Avoid randconfig build failures by requiring VEXPRESS_CONFIG: > > > > > > > > > > > > aarch64-linux-gnu-ld: drivers/gpu/drm/pl111/pl111_versatile.o: in > > > > > > function `pl111_vexpress_clcd_init': > > > > > > pl111_versatile.c:(.text+0x220): undefined reference to > > > > > > `devm_regmap_init_vexpress_config' > > > > > > > > > > pl111_vexpress_clcd_init() starts with: > > > > > > > > > > if (!IS_ENABLED(CONFIG_VEXPRESS_CONFIG)) > > > > > return -ENODEV; > > > > > > > > > > Isn't that supposed to be enough to avoid an undefined reference? > > > > > > Ah! I missed that when reading the code. I see the problem now. It's > > > because of: > > > > > > CONFIG_VEXPRESS_CONFIG=m > > > CONFIG_DRM_PL111=y > > > > > > I think the right fix is: > > > > > > diff --git a/drivers/gpu/drm/pl111/Kconfig b/drivers/gpu/drm/pl111/Kconfig > > > index 80f6748055e3..662fc38f92ba 100644 > > > --- a/drivers/gpu/drm/pl111/Kconfig > > > +++ b/drivers/gpu/drm/pl111/Kconfig > > > @@ -3,6 +3,7 @@ config DRM_PL111 > > > tristate "DRM Support for PL111 CLCD Controller" > > > depends on DRM > > > depends on ARM || ARM64 || COMPILE_TEST > > > + depends on VEXPRESS_CONFIG=y || VEXPRESS_CONFIG=DRM > > > > Oops, no, I had this backwairds: > > > > depends on !VEXPRESS_CONFIG || VEXPRESS_CONFIG=DRM > > Can you pls throw this into an incremental patch on top of > drm-misc-next? It's a non-rebasing tree and all that (linux-next > should have it next day too I guess). Ah! Yes, sorry. I wasn't sure if you'd reverted it yet. One moment... -Kees -- Kees Cook
Re: [PATCH 3/3] drm/pl111: depend on CONFIG_VEXPRESS_CONFIG
On Thu, Jun 3, 2021 at 11:29 PM Kees Cook wrote:
>
> On Thu, Jun 03, 2021 at 02:19:52PM -0700, Kees Cook wrote:
> > On Thu, Jun 03, 2021 at 09:19:42PM +0200, Daniel Vetter wrote:
> > > On Thu, Jun 3, 2021 at 8:43 PM Rob Herring wrote:
> > > >
> > > > On Wed, Jun 2, 2021 at 4:53 PM Kees Cook wrote:
> > > > >
> > > > > Avoid randconfig build failures by requiring VEXPRESS_CONFIG:
> > > > >
> > > > > aarch64-linux-gnu-ld: drivers/gpu/drm/pl111/pl111_versatile.o: in
> > > > > function `pl111_vexpress_clcd_init':
> > > > > pl111_versatile.c:(.text+0x220): undefined reference to
> > > > > `devm_regmap_init_vexpress_config'
> > > >
> > > > pl111_vexpress_clcd_init() starts with:
> > > >
> > > > if (!IS_ENABLED(CONFIG_VEXPRESS_CONFIG))
> > > > return -ENODEV;
> > > >
> > > > Isn't that supposed to be enough to avoid an undefined reference?
> >
> > Ah! I missed that when reading the code. I see the problem now. It's
> > because of:
> >
> > CONFIG_VEXPRESS_CONFIG=m
> > CONFIG_DRM_PL111=y
> >
> > I think the right fix is:
> >
> > diff --git a/drivers/gpu/drm/pl111/Kconfig b/drivers/gpu/drm/pl111/Kconfig
> > index 80f6748055e3..662fc38f92ba 100644
> > --- a/drivers/gpu/drm/pl111/Kconfig
> > +++ b/drivers/gpu/drm/pl111/Kconfig
> > @@ -3,6 +3,7 @@ config DRM_PL111
> > tristate "DRM Support for PL111 CLCD Controller"
> > depends on DRM
> > depends on ARM || ARM64 || COMPILE_TEST
> > + depends on VEXPRESS_CONFIG=y || VEXPRESS_CONFIG=DRM
>
> Oops, no, I had this backwairds:
>
> depends on !VEXPRESS_CONFIG || VEXPRESS_CONFIG=DRM
Can you pls throw this into an incremental patch on top of
drm-misc-next? It's a non-rebasing tree and all that (linux-next
should have it next day too I guess).
Thanks, Daniel
> _that_ lets me build with:
>
> # CONFIG_VEXPRESS_CONFIG is not set
> CONFIG_DRM_PL111=y
>
> CONFIG_VEXPRESS_CONFIG=y
> CONFIG_DRM_PL111=y
>
> CONFIG_VEXPRESS_CONFIG=m
> CONFIG_DRM_PL111=m
>
> CONFIG_VEXPRESS_CONFIG=y
> CONFIG_DRM_PL111=m
>
> and disallows:
>
> CONFIG_VEXPRESS_CONFIG=m
> CONFIG_DRM_PL111=y
>
> (this will force CONFIG_DRM_PL111=m)
>
> -Kees
>
> > depends on COMMON_CLK
> > select DRM_KMS_HELPER
> > select DRM_KMS_CMA_HELPER
> >
> > I will go check the defconfigs Rob mentioned...
> >
> > > > Making the whole file depend on VEXPRESS_CONFIG is not right either.
> > > > Not all platforms need it.
> > >
> > > It needs a compile-time status inline then for the functions we're
> > > using in pl111.
> >
> > FYI, this is the config I was working from, which was throwing link errors:
> > https://lore.kernel.org/lkml/202105300926.fx0myysp-...@intel.com/
> >
> > > -Daniel
> > >
> > > >
> > > > >
> > > > > Fixes: 826fc86b5903 ("drm: pl111: Move VExpress setup into versatile
> > > > > init")
> > > > > Signed-off-by: Kees Cook
> > > > > ---
> > > > > drivers/gpu/drm/pl111/Kconfig | 2 +-
> > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/pl111/Kconfig
> > > > > b/drivers/gpu/drm/pl111/Kconfig
> > > > > index 80f6748055e3..c5210a5bef1b 100644
> > > > > --- a/drivers/gpu/drm/pl111/Kconfig
> > > > > +++ b/drivers/gpu/drm/pl111/Kconfig
> > > > > @@ -2,7 +2,7 @@
> > > > > config DRM_PL111
> > > > > tristate "DRM Support for PL111 CLCD Controller"
> > > > > depends on DRM
> > > > > - depends on ARM || ARM64 || COMPILE_TEST
> > > > > + depends on VEXPRESS_CONFIG
> > > > > depends on COMMON_CLK
> > > > > select DRM_KMS_HELPER
> > > > > select DRM_KMS_CMA_HELPER
> > > > > --
> > > > > 2.25.1
> > > > >
> > >
> > >
> > >
> > > --
> > > Daniel Vetter
> > > Software Engineer, Intel Corporation
> > > http://blog.ffwll.ch
> >
> > --
> > Kees Cook
>
> --
> Kees Cook
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [Intel-gfx] [PATCH 11/20] drm/i915/guc: Replace CTB array with explicit members
On Thu, Jun 03, 2021 at 03:25:29PM +0800, kernel test robot wrote:
> Hi Matthew,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on drm-tip/drm-tip]
> [also build test ERROR on drm-exynos/exynos-drm-next
> tegra-drm/drm/tegra/for-next v5.13-rc4 next-20210602]
> [cannot apply to drm-intel/for-linux-next drm/drm-next]
> [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/Matthew-Brost/GuC-CTBs-changes-a-few-misc-patches/20210603-130102
> base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
> config: i386-randconfig-a015-20210603 (attached as .config)
> compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
> reproduce (this is a W=1 build):
> #
> https://github.com/0day-ci/linux/commit/7672d3ecddcd8af3a2a856facac49ca93d4bdf9e
> git remote add linux-review https://github.com/0day-ci/linux
> git fetch --no-tags linux-review
> Matthew-Brost/GuC-CTBs-changes-a-few-misc-patches/20210603-130102
> git checkout 7672d3ecddcd8af3a2a856facac49ca93d4bdf9e
> # save the attached .config to linux build tree
> make W=1 ARCH=i386
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot
>
> All errors (new ones prefixed by >>):
>
>In file included from include/drm/drm_mm.h:49,
> from include/drm/drm_vma_manager.h:26,
> from include/drm/drm_gem.h:40,
> from drivers/gpu/drm/i915/i915_drv.h:54,
> from drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c:6:
>drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c: In function 'intel_guc_ct_init':
> >> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c:34:26: error: format '%lx'
> >> expects argument of type 'long unsigned int', but argument 5 has type
> >> 'ptrdiff_t' {aka 'int'} [-Werror=format=]
> 34 | drm_dbg(ct_to_drm(_ct), "CT: " _fmt, ##__VA_ARGS__)
> | ^~
>..
> 215 |ptrdiff(desc, blob), ptrdiff(cmds, blob), cmds_size);
> |~~~
> ||
> |ptrdiff_t {aka int}
>include/drm/drm_print.h:448:56: note: in definition of macro 'drm_dbg'
> 448 | drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_DRIVER, fmt,
> ##__VA_ARGS__)
> |^~~
>drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c:214:2: note: in expansion of
> macro 'CT_DEBUG'
> 214 | CT_DEBUG(ct, "%s desc %#lx cmds %#lx size %u\n", "send",
> | ^~~~
>drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c:214:27: note: format string is
> defined here
> 214 | CT_DEBUG(ct, "%s desc %#lx cmds %#lx size %u\n", "send",
> |~~~^
> | |
> | long unsigned int
32bit ptrdiff vs 64bit printk modifier. You need something else here.
I've stuffed all the previous patches into drm-intel-gt-next. If you
resend with just this one fixed here I'll continue tomorrow (--in-reply-to
resend I mean).
Thanks, Daniel
> |%#x
>In file included from include/drm/drm_mm.h:49,
> from include/drm/drm_vma_manager.h:26,
> from include/drm/drm_gem.h:40,
> from drivers/gpu/drm/i915/i915_drv.h:54,
> from drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c:6:
>drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c:34:26: error: format '%lx'
> expects argument of type 'long unsigned int', but argument 6 has type
> 'ptrdiff_t' {aka 'int'} [-Werror=format=]
> 34 | drm_dbg(ct_to_drm(_ct), "CT: " _fmt, ##__VA_ARGS__)
> | ^~
>..
> 215 |ptrdiff(desc, blob), ptrdiff(cmds, blob), cmds_size);
> | ~~~
> | |
> | ptrdiff_t {aka int}
>include/drm/drm_print.h:448:56: note: in definition of macro 'drm_dbg'
> 448 | drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_DRIVER, fmt,
> ##__VA_ARGS__)
> |^~~
>drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c:214:2: note: in expansion of
> macro 'CT_DEBUG
Re: [PATCH 08/20] drm/i915: Promote ptrdiff() to i915_utils.h
On Wed, Jun 02, 2021 at 10:16:18PM -0700, Matthew Brost wrote:
> From: Michal Wajdeczko
>
> Generic helpers should be placed in i915_utils.h.
Random rant, but we're _way_ too happy to just stuff random things into
i915_utils.h without trying to properly upstream it.
For thinks like this the general dumping ground would be kernel.h, there's
a few pointer helpers there already. Follow up patch maybe nice.
-Daniel
>
> Signed-off-by: Michal Wajdeczko
> Signed-off-by: Matthew Brost
> Reviewed-by: Matthew Brost
> ---
> drivers/gpu/drm/i915/i915_utils.h | 5 +
> drivers/gpu/drm/i915/i915_vma.h | 5 -
> 2 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_utils.h
> b/drivers/gpu/drm/i915/i915_utils.h
> index f02f52ab5070..5259edacde38 100644
> --- a/drivers/gpu/drm/i915/i915_utils.h
> +++ b/drivers/gpu/drm/i915/i915_utils.h
> @@ -201,6 +201,11 @@ __check_struct_size(size_t base, size_t arr, size_t
> count, size_t *size)
> __T;\
> })
>
> +static __always_inline ptrdiff_t ptrdiff(const void *a, const void *b)
> +{
> + return a - b;
> +}
> +
> /*
> * container_of_user: Extract the superclass from a pointer to a member.
> *
> diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h
> index dc6926d89626..eca452a9851f 100644
> --- a/drivers/gpu/drm/i915/i915_vma.h
> +++ b/drivers/gpu/drm/i915/i915_vma.h
> @@ -151,11 +151,6 @@ static inline void i915_vma_put(struct i915_vma *vma)
> i915_gem_object_put(vma->obj);
> }
>
> -static __always_inline ptrdiff_t ptrdiff(const void *a, const void *b)
> -{
> - return a - b;
> -}
> -
> static inline long
> i915_vma_compare(struct i915_vma *vma,
>struct i915_address_space *vm,
> --
> 2.28.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH v2] drm/pl111: Fix CONFIG_VEXPRESS_CONFIG depend
Avoid randconfig build failures by requiring VEXPRESS_CONFIG either be
missing, built-in, or modular when pl111 is modular. Fixing this warning
when:
CONFIG_VEXPRESS_CONFIG=m
CONFIG_DRM_PL111=y
aarch64-linux-gnu-ld: drivers/gpu/drm/pl111/pl111_versatile.o: in function
`pl111_vexpress_clcd_init':
pl111_versatile.c:(.text+0x220): undefined reference to
`devm_regmap_init_vexpress_config'
Reported-by: kernel test robot
Link: https://lore.kernel.org/lkml/202105300926.fx0myysp-...@intel.com/
Fixes: 826fc86b5903 ("drm: pl111: Move VExpress setup into versatile init")
Signed-off-by: Kees Cook
---
v2: avoid forcing VEXPRESS_CONFIG be enabled
v1: https://lore.kernel.org/lkml/20210602215252.695994-4-keesc...@chromium.org
---
drivers/gpu/drm/pl111/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/pl111/Kconfig b/drivers/gpu/drm/pl111/Kconfig
index 80f6748055e3..b84879ca430d 100644
--- a/drivers/gpu/drm/pl111/Kconfig
+++ b/drivers/gpu/drm/pl111/Kconfig
@@ -3,6 +3,7 @@ config DRM_PL111
tristate "DRM Support for PL111 CLCD Controller"
depends on DRM
depends on ARM || ARM64 || COMPILE_TEST
+ depends on !VEXPRESS_CONFIG || VEXPRESS_CONFIG=DRM
depends on COMMON_CLK
select DRM_KMS_HELPER
select DRM_KMS_CMA_HELPER
--
2.25.1
Re: [PATCH 3/3] drm/pl111: depend on CONFIG_VEXPRESS_CONFIG
On Thu, Jun 03, 2021 at 02:19:52PM -0700, Kees Cook wrote:
> On Thu, Jun 03, 2021 at 09:19:42PM +0200, Daniel Vetter wrote:
> > On Thu, Jun 3, 2021 at 8:43 PM Rob Herring wrote:
> > >
> > > On Wed, Jun 2, 2021 at 4:53 PM Kees Cook wrote:
> > > >
> > > > Avoid randconfig build failures by requiring VEXPRESS_CONFIG:
> > > >
> > > > aarch64-linux-gnu-ld: drivers/gpu/drm/pl111/pl111_versatile.o: in
> > > > function `pl111_vexpress_clcd_init':
> > > > pl111_versatile.c:(.text+0x220): undefined reference to
> > > > `devm_regmap_init_vexpress_config'
> > >
> > > pl111_vexpress_clcd_init() starts with:
> > >
> > > if (!IS_ENABLED(CONFIG_VEXPRESS_CONFIG))
> > > return -ENODEV;
> > >
> > > Isn't that supposed to be enough to avoid an undefined reference?
>
> Ah! I missed that when reading the code. I see the problem now. It's
> because of:
>
> CONFIG_VEXPRESS_CONFIG=m
> CONFIG_DRM_PL111=y
>
> I think the right fix is:
>
> diff --git a/drivers/gpu/drm/pl111/Kconfig b/drivers/gpu/drm/pl111/Kconfig
> index 80f6748055e3..662fc38f92ba 100644
> --- a/drivers/gpu/drm/pl111/Kconfig
> +++ b/drivers/gpu/drm/pl111/Kconfig
> @@ -3,6 +3,7 @@ config DRM_PL111
> tristate "DRM Support for PL111 CLCD Controller"
> depends on DRM
> depends on ARM || ARM64 || COMPILE_TEST
> + depends on VEXPRESS_CONFIG=y || VEXPRESS_CONFIG=DRM
Oops, no, I had this backwairds:
depends on !VEXPRESS_CONFIG || VEXPRESS_CONFIG=DRM
_that_ lets me build with:
# CONFIG_VEXPRESS_CONFIG is not set
CONFIG_DRM_PL111=y
CONFIG_VEXPRESS_CONFIG=y
CONFIG_DRM_PL111=y
CONFIG_VEXPRESS_CONFIG=m
CONFIG_DRM_PL111=m
CONFIG_VEXPRESS_CONFIG=y
CONFIG_DRM_PL111=m
and disallows:
CONFIG_VEXPRESS_CONFIG=m
CONFIG_DRM_PL111=y
(this will force CONFIG_DRM_PL111=m)
-Kees
> depends on COMMON_CLK
> select DRM_KMS_HELPER
> select DRM_KMS_CMA_HELPER
>
> I will go check the defconfigs Rob mentioned...
>
> > > Making the whole file depend on VEXPRESS_CONFIG is not right either.
> > > Not all platforms need it.
> >
> > It needs a compile-time status inline then for the functions we're
> > using in pl111.
>
> FYI, this is the config I was working from, which was throwing link errors:
> https://lore.kernel.org/lkml/202105300926.fx0myysp-...@intel.com/
>
> > -Daniel
> >
> > >
> > > >
> > > > Fixes: 826fc86b5903 ("drm: pl111: Move VExpress setup into versatile
> > > > init")
> > > > Signed-off-by: Kees Cook
> > > > ---
> > > > drivers/gpu/drm/pl111/Kconfig | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/pl111/Kconfig
> > > > b/drivers/gpu/drm/pl111/Kconfig
> > > > index 80f6748055e3..c5210a5bef1b 100644
> > > > --- a/drivers/gpu/drm/pl111/Kconfig
> > > > +++ b/drivers/gpu/drm/pl111/Kconfig
> > > > @@ -2,7 +2,7 @@
> > > > config DRM_PL111
> > > > tristate "DRM Support for PL111 CLCD Controller"
> > > > depends on DRM
> > > > - depends on ARM || ARM64 || COMPILE_TEST
> > > > + depends on VEXPRESS_CONFIG
> > > > depends on COMMON_CLK
> > > > select DRM_KMS_HELPER
> > > > select DRM_KMS_CMA_HELPER
> > > > --
> > > > 2.25.1
> > > >
> >
> >
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
>
> --
> Kees Cook
--
Kees Cook
[PATCH v3] drm/panfrost: Add AFBC_FEATURES parameter
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
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
Cc: Rob Herring
Cc: Tomeu Vizoso
Cc: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_device.h | 1 +
drivers/gpu/drm/panfrost/panfrost_drv.c| 3 ++-
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, 6 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..365ee53f0 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);
@@ -559,7 +560,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))
#define GPU_JS_FEATURES(n) (0x0C0 + ((n) * 4))
+#define GPU_AFBC_FEATURES (0x4C) /* (RO) AFBC support on Bifrost
*/
#define GPU_SHADER_PRESENT_LO 0x100 /* (RO) Shader core present
bitmap, low word */
#define GPU_SHADER_PRESENT_HI 0x104 /* (RO) Shader core present
bitmap, high word */
diff --git a/include/uapi/drm/panfrost_drm.h b/include/uapi/drm/panfrost_drm.h
index ec19db1ee..061e700dd 100644
--- a/include/uapi/drm/panfrost_drm.h
+++ b/include/uapi/drm/panfrost_drm.h
@@ -171,6 +171,7 @@ enum drm_panfrost_param {
DRM_PANFROST_PARAM_JS_FEATURES15,
DRM_PANFROST_PARAM_NR_CORE_GROUPS,
DRM_PANFROST_PARAM_
Re: [PATCH 0/7] libdrm tests for hot-unplug feature
Please open a gitlab MR for these. Alex On Tue, Jun 1, 2021 at 4:17 PM Andrey Grodzovsky wrote: > > Adding some tests to acompany the recently added hot-unplug > feature. For now the test suite is disabled until the feature > propagates from drm-misc-next to drm-next. > > Andrey Grodzovsky (7): > tests/amdgpu: Fix valgrind warning > xf86drm: Add function to retrieve char device path > test/amdgpu: Add helper functions for hot unplug > test/amdgpu/hotunplug: Add test suite for GPU unplug > test/amdgpu/hotunplug: Add basic test > tests/amdgpu/hotunplug: Add unplug with cs test. > tests/amdgpu/hotunplug: Add hotunplug with exported bo test > > tests/amdgpu/amdgpu_test.c | 42 +++- > tests/amdgpu/amdgpu_test.h | 26 +++ > tests/amdgpu/basic_tests.c | 5 +- > tests/amdgpu/hotunplug_tests.c | 357 + > tests/amdgpu/meson.build | 1 + > xf86drm.c | 23 +++ > xf86drm.h | 1 + > 7 files changed, 450 insertions(+), 5 deletions(-) > create mode 100644 tests/amdgpu/hotunplug_tests.c > > -- > 2.25.1 > > ___ > amd-gfx mailing list > amd-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 0/7] libdrm tests for hot-unplug feature
On Thu, Jun 3, 2021 at 5:11 PM Daniel Vetter wrote: > > On Thu, Jun 03, 2021 at 10:22:37AM -0400, Andrey Grodzovsky wrote: > > Ping > > > > Andrey > > > > On 2021-06-02 10:20 a.m., Andrey Grodzovsky wrote: > > > > > > On 2021-06-02 3:59 a.m., Daniel Vetter wrote: > > > > On Tue, Jun 1, 2021 at 10:17 PM Andrey Grodzovsky > > > > wrote: > > > > > Adding some tests to acompany the recently added hot-unplug > > > > > feature. For now the test suite is disabled until the feature > > > > > propagates from drm-misc-next to drm-next. > > > > > > > > > > Andrey Grodzovsky (7): > > > > >tests/amdgpu: Fix valgrind warning > > > > >xf86drm: Add function to retrieve char device path > > > > >test/amdgpu: Add helper functions for hot unplug > > > > >test/amdgpu/hotunplug: Add test suite for GPU unplug > > > > >test/amdgpu/hotunplug: Add basic test > > > > >tests/amdgpu/hotunplug: Add unplug with cs test. > > > > >tests/amdgpu/hotunplug: Add hotunplug with exported bo test > > > > Given how nasty hotunplug is I really think collaborating on igt tests > > > > on this would be best for everyone ... do we have to keep doing > > > > parallel tests here for amdgpu? > > > > -Daniel > > > > > > AFAIK as far as AMD goes a lot of developers use libdrm for regression > > > testing > > > while developing their features and also QA as i can see from some > > > internal ticket > > > specifically opened for failing to pass libdrm tests. From my bitter > > > experience with > > > GPU reset - features which are not part of a common use case such as > > > device loading, > > > mode setting or commands submissions tend to very quickly break as > > > people develop > > > features but never test them in those uncommon use cases - this is why I > > > feel it will be > > > very helpful to include those tests in libdrm. > > > > > > Also given that this is libdrm amdgpu code it fits naturally into libdrm. > > > > > > Regarding IGT - as you may remember I have them there too - > > > https://gitlab.freedesktop.org/agrodzov/igt-gpu-tools/-/commits/master > > > I hit some compile breakage on debian platform there which i need to > > > resolve before i will submit for review there too. > > Why can't amd run the igt tests? Afaiui on the display side this is > happening already, at least sometimes. > > And yes regression tests matter, it just feels silly that we need to have > them 2x for amdgpu. For old stuff the old repo is all fine, but for new > feature it looks a bit silly. Different teams, different CI infrastructures... It ends up being easier to port tests between frameworks than to switch frameworks in some cases. Alex > -Daniel > > > > > > > Andrey > > > > > > > > > > > > > > > tests/amdgpu/amdgpu_test.c | 42 +++- > > > > > tests/amdgpu/amdgpu_test.h | 26 +++ > > > > > tests/amdgpu/basic_tests.c | 5 +- > > > > > tests/amdgpu/hotunplug_tests.c | 357 > > > > > + > > > > > tests/amdgpu/meson.build | 1 + > > > > > xf86drm.c | 23 +++ > > > > > xf86drm.h | 1 + > > > > > 7 files changed, 450 insertions(+), 5 deletions(-) > > > > > create mode 100644 tests/amdgpu/hotunplug_tests.c > > > > > > > > > > -- > > > > > 2.25.1 > > > > > > > > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch
Re: [PATCH 3/3] drm/pl111: depend on CONFIG_VEXPRESS_CONFIG
On Thu, Jun 03, 2021 at 09:19:42PM +0200, Daniel Vetter wrote:
> On Thu, Jun 3, 2021 at 8:43 PM Rob Herring wrote:
> >
> > On Wed, Jun 2, 2021 at 4:53 PM Kees Cook wrote:
> > >
> > > Avoid randconfig build failures by requiring VEXPRESS_CONFIG:
> > >
> > > aarch64-linux-gnu-ld: drivers/gpu/drm/pl111/pl111_versatile.o: in
> > > function `pl111_vexpress_clcd_init':
> > > pl111_versatile.c:(.text+0x220): undefined reference to
> > > `devm_regmap_init_vexpress_config'
> >
> > pl111_vexpress_clcd_init() starts with:
> >
> > if (!IS_ENABLED(CONFIG_VEXPRESS_CONFIG))
> > return -ENODEV;
> >
> > Isn't that supposed to be enough to avoid an undefined reference?
Ah! I missed that when reading the code. I see the problem now. It's
because of:
CONFIG_VEXPRESS_CONFIG=m
CONFIG_DRM_PL111=y
I think the right fix is:
diff --git a/drivers/gpu/drm/pl111/Kconfig b/drivers/gpu/drm/pl111/Kconfig
index 80f6748055e3..662fc38f92ba 100644
--- a/drivers/gpu/drm/pl111/Kconfig
+++ b/drivers/gpu/drm/pl111/Kconfig
@@ -3,6 +3,7 @@ config DRM_PL111
tristate "DRM Support for PL111 CLCD Controller"
depends on DRM
depends on ARM || ARM64 || COMPILE_TEST
+ depends on VEXPRESS_CONFIG=y || VEXPRESS_CONFIG=DRM
depends on COMMON_CLK
select DRM_KMS_HELPER
select DRM_KMS_CMA_HELPER
I will go check the defconfigs Rob mentioned...
> > Making the whole file depend on VEXPRESS_CONFIG is not right either.
> > Not all platforms need it.
>
> It needs a compile-time status inline then for the functions we're
> using in pl111.
FYI, this is the config I was working from, which was throwing link errors:
https://lore.kernel.org/lkml/202105300926.fx0myysp-...@intel.com/
> -Daniel
>
> >
> > >
> > > Fixes: 826fc86b5903 ("drm: pl111: Move VExpress setup into versatile
> > > init")
> > > Signed-off-by: Kees Cook
> > > ---
> > > drivers/gpu/drm/pl111/Kconfig | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/pl111/Kconfig b/drivers/gpu/drm/pl111/Kconfig
> > > index 80f6748055e3..c5210a5bef1b 100644
> > > --- a/drivers/gpu/drm/pl111/Kconfig
> > > +++ b/drivers/gpu/drm/pl111/Kconfig
> > > @@ -2,7 +2,7 @@
> > > config DRM_PL111
> > > tristate "DRM Support for PL111 CLCD Controller"
> > > depends on DRM
> > > - depends on ARM || ARM64 || COMPILE_TEST
> > > + depends on VEXPRESS_CONFIG
> > > depends on COMMON_CLK
> > > select DRM_KMS_HELPER
> > > select DRM_KMS_CMA_HELPER
> > > --
> > > 2.25.1
> > >
>
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Kees Cook
Re: [PATCH 0/7] libdrm tests for hot-unplug feature
On Thu, Jun 03, 2021 at 10:22:37AM -0400, Andrey Grodzovsky wrote: > Ping > > Andrey > > On 2021-06-02 10:20 a.m., Andrey Grodzovsky wrote: > > > > On 2021-06-02 3:59 a.m., Daniel Vetter wrote: > > > On Tue, Jun 1, 2021 at 10:17 PM Andrey Grodzovsky > > > wrote: > > > > Adding some tests to acompany the recently added hot-unplug > > > > feature. For now the test suite is disabled until the feature > > > > propagates from drm-misc-next to drm-next. > > > > > > > > Andrey Grodzovsky (7): > > > > tests/amdgpu: Fix valgrind warning > > > > xf86drm: Add function to retrieve char device path > > > > test/amdgpu: Add helper functions for hot unplug > > > > test/amdgpu/hotunplug: Add test suite for GPU unplug > > > > test/amdgpu/hotunplug: Add basic test > > > > tests/amdgpu/hotunplug: Add unplug with cs test. > > > > tests/amdgpu/hotunplug: Add hotunplug with exported bo test > > > Given how nasty hotunplug is I really think collaborating on igt tests > > > on this would be best for everyone ... do we have to keep doing > > > parallel tests here for amdgpu? > > > -Daniel > > > > AFAIK as far as AMD goes a lot of developers use libdrm for regression > > testing > > while developing their features and also QA as i can see from some > > internal ticket > > specifically opened for failing to pass libdrm tests. From my bitter > > experience with > > GPU reset - features which are not part of a common use case such as > > device loading, > > mode setting or commands submissions tend to very quickly break as > > people develop > > features but never test them in those uncommon use cases - this is why I > > feel it will be > > very helpful to include those tests in libdrm. > > > > Also given that this is libdrm amdgpu code it fits naturally into libdrm. > > > > Regarding IGT - as you may remember I have them there too - > > https://gitlab.freedesktop.org/agrodzov/igt-gpu-tools/-/commits/master > > I hit some compile breakage on debian platform there which i need to > > resolve before i will submit for review there too. Why can't amd run the igt tests? Afaiui on the display side this is happening already, at least sometimes. And yes regression tests matter, it just feels silly that we need to have them 2x for amdgpu. For old stuff the old repo is all fine, but for new feature it looks a bit silly. -Daniel > > > > Andrey > > > > > > > > > > > tests/amdgpu/amdgpu_test.c | 42 +++- > > > > tests/amdgpu/amdgpu_test.h | 26 +++ > > > > tests/amdgpu/basic_tests.c | 5 +- > > > > tests/amdgpu/hotunplug_tests.c | 357 > > > > + > > > > tests/amdgpu/meson.build | 1 + > > > > xf86drm.c | 23 +++ > > > > xf86drm.h | 1 + > > > > 7 files changed, 450 insertions(+), 5 deletions(-) > > > > create mode 100644 tests/amdgpu/hotunplug_tests.c > > > > > > > > -- > > > > 2.25.1 > > > > > > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH 5/9] drm/i915: Move engine->schedule to i915_sched_engine
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(&engine->latency);
seqcount_init(&engine->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, &attr);
+ engine->sched_engine->schedule(rq, &attr);
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 |= (I915_SCHEDULER_CAP_ENABLED |
I915_SCHEDULER_CAP_PRIORITY);
else
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index
[PATCH 8/9] drm/i915: Move submission tasklet to i915_sched_engine
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(&execlists->tasklet);
-}
-
-static inline void
-execlists_active_unlock_bh(struct intel_engine_execlists *execlists)
-{
- tasklet_unlock(&execlists->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;
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(&engine->sched_engine->requests));
- tasklet_kill(&engine->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 = &engine->execlists.tasklet;
+ struct tasklet_struct *t = &engine->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,
- &engine->execlists.tasklet.state)),
-
enableddisabled(!atomic_read(&engine->execlists.tasklet.count)),
+
&engine->sched_engine->tasklet.state)),
+
enableddisabled(!atomic_read(&engine->sched_engine->tasklet.count)),
repr_timer(&engine->execlists.preempt),
repr_timer(&engine->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();
- execlists_active_unlock_bh(execlists);
+ i915_sched_engine_active_unlock_bh(engine->sched_engine);
} else if (INTEL_GEN(dev_priv) > 6) {
drm_printf(m, "\tPP_DIR_BASE: 0x%08x\n",
ENGINE_READ(engine, RING_PP_DIR_BASE));
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index f1b14aff5118..6f2fd6f13ac4 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -
[PATCH 7/9] drm/i915: Update i915_scheduler to operate on i915_sched_engine
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(&rq->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, &rq->fence.flags);
@@ -2452,7 +2454,8 @@ static void queue_request(struct intel_engine_cs *engine,
{
GEM_BUG_ON(!list_empty(&rq->sched.link));
list_add_tail(&rq->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, &rq->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(&rq->sched.link));
list_add_tail(&rq->sched.link,
- i915_sched_lookup_priolist(engine, prio));
+ i915_sched_lookup_priolist(engine->sched_engine, prio));
set_bit(I915_FENCE_FLAG_PQUEUE, &rq->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(&engine->sched_engine->lock);
+ lockdep_assert_held(&sched_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 then
* check that the rq still belongs to the newly locked engine.
*/
- while (locked != (engine = READ_ONCE(rq->engine))) {
- spin_unlock(&locked->sched_engine->lock);
+ whil
[PATCH 3/9] drm/i915: Add i915_sched_engine_reset_on_empty function
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.
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(&engine->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(&engine->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(&sched_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
[PATCH 2/9] drm/i915: Add i915_sched_engine_is_empty function
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(&engine->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(&engine->sched_engine->queue.rb_root));
+ GEM_BUG_ON(i915_sched_engine_is_empty(engine->sched_engine));
list_move(&rq->sched.link, pl);
set_bit(I915_FENCE_FLAG_PQUEUE, &rq->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(&engine->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(&engine->sched_engine->queue.rb_root));
+ GEM_BUG_ON(i915_sched_engine_is_empty(engine->sched_engine));
GEM_BUG_ON(list_empty(&request->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(&engine->sched_engine->queue.rb_root));
+ GEM_BUG_ON(i915_sched_engine_is_empty(engine->sched_engine));
GEM_BUG_ON(list_empty(&rq->sched.link));
tasklet_hi_schedule(&engine->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(&sched_engine->ref, i915_sched_engine_free);
}
+static inline bool
+i915_sched_engine_is_empty(struct i915_sched_engine *sched_engine)
+{
+ return RB_EMPTY_ROOT(&sched_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
[PATCH 9/9] drm/i915/doc: Add kernel doc for i915_sched_engine
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.
+ */
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
[PATCH 4/9] drm/i915: Move active tracking to i915_sched_engine
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 = &frame->ring;
mutex_lock(&ce->timeline->mutex);
- spin_lock_irq(&engine->active.lock);
+ spin_lock_irq(&engine->sched_engine->lock);
dw = engine->emit_fini_breadcrumb(&frame->rq, frame->cs) - frame->cs;
- spin_unlock_irq(&engine->active.lock);
+ spin_unlock_irq(&engine->sched_engine->lock);
mutex_unlock(&ce->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(&engine->active.requests);
- INIT_LIST_HEAD(&engine->active.hold);
-
- spin_lock_init(&engine->active.lock);
- lockdep_set_subclass(&engine->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(&engine->active.lock.dep_map);
- lock_map_release(&engine->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(&engine->active.requests));
+ GEM_BUG_ON(!list_empty(&engine->sched_engine->requests));
tasklet_kill(&engine->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(&engine->active.lock, flags);
+ spin_lock_irqsave(&engine->sched_engine->lock, flags);
rq = intel_engine_find_active_request(engine);
if (rq) {
struct intel_timeline *tl = get_timeline(rq);
@@ -1731,8 +1708,9 @@ void intel_eng
[PATCH 6/9] drm/i915: Add kick_backend function to i915_sched_engine
Rather than touching execlist specific structures in the generic
scheduling code, add a callback function in the backend.
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(&engine->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(&engine->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.
-*/
- if (prio <= engine->sched_engine->queue_priority_hint)
- return;
-
- rcu_read_lock();
-
- /* Nothing currently active? We're overdue for a submission! */
- inflight = execlists_active(&engine->execlists);
- if (!inflight)
- goto unlock;
-
- /*
-* If we are already the currently executing context, don't
-* bother evaluating if we should preempt ourselves.
-*/
- if (infli
[PATCH 1/9] drm/i915: Move priolist to new i915_sched_engine object
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(&engine->active.requests));
tasklet_kill(&engine->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(&engine->execlists.queue.rb_root))
+ if (!RB_EMPTY_ROOT(&engine->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;
struct intel_gt;
struct intel_ring;
struct intel_uncore;
@@ -152,11 +153,6 @@ struct intel_engine_execlists {
*/
struct timer_list preempt;
- /**
-* @default_priolist: priority list for I915_PRIORITY_NO
[PATCH 0/9] Introduce i915_sched_engine object
As discussed in [1] we are breaking that large series into a several smaller ones. This series is stand alone patch part of step #4 which has no other dependencies or patches relevant to it. v2: (Daniel Vetter): - Split into several smaller patches - Add kernel doc for i915_sched_engine (Matthew Brost): - Drop wrapper functions for tasklet as eventually tasklet will be dropped Signed-off-by: Matthew Brost [1] https://patchwork.freedesktop.org/series/89844/ Matthew Brost (9): drm/i915: Move priolist to new i915_sched_engine object drm/i915: Add i915_sched_engine_is_empty function drm/i915: Add i915_sched_engine_reset_on_empty function drm/i915: Move active tracking to i915_sched_engine drm/i915: Move engine->schedule to i915_sched_engine drm/i915: Add kick_backend function to i915_sched_engine drm/i915: Update i915_scheduler to operate on i915_sched_engine drm/i915: Move submission tasklet to i915_sched_engine drm/i915/doc: Add kernel doc for i915_sched_engine Documentation/gpu/i915.rst| 6 + drivers/gpu/drm/i915/gem/i915_gem_wait.c | 4 +- drivers/gpu/drm/i915/gt/intel_engine.h| 16 - drivers/gpu/drm/i915/gt/intel_engine_cs.c | 72 ++-- .../gpu/drm/i915/gt/intel_engine_heartbeat.c | 4 +- drivers/gpu/drm/i915/gt/intel_engine_pm.c | 4 +- drivers/gpu/drm/i915/gt/intel_engine_types.h | 47 +-- drivers/gpu/drm/i915/gt/intel_engine_user.c | 2 +- .../drm/i915/gt/intel_execlists_submission.c | 323 +++--- .../gpu/drm/i915/gt/intel_ring_submission.c | 12 +- drivers/gpu/drm/i915/gt/mock_engine.c | 17 +- drivers/gpu/drm/i915/gt/selftest_execlists.c | 36 +- drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 6 +- 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 | 70 ++-- drivers/gpu/drm/i915/i915_gpu_error.c | 4 +- drivers/gpu/drm/i915/i915_request.c | 42 +-- drivers/gpu/drm/i915/i915_request.h | 2 +- drivers/gpu/drm/i915/i915_scheduler.c | 168 + drivers/gpu/drm/i915/i915_scheduler.h | 47 ++- drivers/gpu/drm/i915/i915_scheduler_types.h | 89 + 22 files changed, 554 insertions(+), 425 deletions(-) -- 2.28.0
[PATCH] drm/vgem: use shmem helpers
Aside from deleting lots of code the real motivation here is to switch
the mmap over to VM_PFNMAP, to be more consistent with what real gpu
drivers do. They're all VM_PFNMP, which means get_user_pages doesn't
work, and even if you try and there's a struct page behind that,
touching it and mucking around with its refcount can upset drivers
real bad.
v2: Review from Thomas:
- sort #include
- drop more dead code that I didn't spot somehow
v3: select DRM_GEM_SHMEM_HELPER to make it build (intel-gfx-ci)
v4: I got tricked by 0cf2ef46c6c0 ("drm/shmem-helper: Use cached
mappings by default"), and we need WC in vgem because vgem doesn't
have explicit begin/end cpu access ioctls.
Also add a comment why exactly vgem has to use wc.
v5: Don't set obj->base.funcs, it will default to drm_gem_shmem_funcs
(Thomas)
v6: vgem also needs an MMU for remapping
Cc: Thomas Zimmermann
Acked-by: Thomas Zimmermann
Cc: John Stultz
Cc: Sumit Semwal
Cc: "Christian König"
Signed-off-by: Daniel Vetter
Cc: Melissa Wen
Cc: Chris Wilson
---
drivers/gpu/drm/Kconfig | 5 +-
drivers/gpu/drm/vgem/vgem_drv.c | 342 ++--
2 files changed, 16 insertions(+), 331 deletions(-)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 9c21527b791f..1b785ec4b80a 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -267,7 +267,8 @@ source "drivers/gpu/drm/kmb/Kconfig"
config DRM_VGEM
tristate "Virtual GEM provider"
- depends on DRM
+ depends on DRM && MMU
+ select DRM_GEM_SHMEM_HELPER
help
Choose this option to get a virtual graphics memory manager,
as used by Mesa's software renderer for enhanced performance.
@@ -275,7 +276,7 @@ config DRM_VGEM
config DRM_VKMS
tristate "Virtual KMS (EXPERIMENTAL)"
- depends on DRM
+ depends on DRM && MMU
select DRM_KMS_HELPER
select DRM_GEM_SHMEM_HELPER
select CRC32
diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index bf38a7e319d1..a87eafa89e9f 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -38,6 +38,7 @@
#include
#include
+#include
#include
#include
#include
@@ -50,87 +51,11 @@
#define DRIVER_MAJOR 1
#define DRIVER_MINOR 0
-static const struct drm_gem_object_funcs vgem_gem_object_funcs;
-
static struct vgem_device {
struct drm_device drm;
struct platform_device *platform;
} *vgem_device;
-static void vgem_gem_free_object(struct drm_gem_object *obj)
-{
- struct drm_vgem_gem_object *vgem_obj = to_vgem_bo(obj);
-
- kvfree(vgem_obj->pages);
- mutex_destroy(&vgem_obj->pages_lock);
-
- if (obj->import_attach)
- drm_prime_gem_destroy(obj, vgem_obj->table);
-
- drm_gem_object_release(obj);
- kfree(vgem_obj);
-}
-
-static vm_fault_t vgem_gem_fault(struct vm_fault *vmf)
-{
- struct vm_area_struct *vma = vmf->vma;
- struct drm_vgem_gem_object *obj = vma->vm_private_data;
- /* We don't use vmf->pgoff since that has the fake offset */
- unsigned long vaddr = vmf->address;
- vm_fault_t ret = VM_FAULT_SIGBUS;
- loff_t num_pages;
- pgoff_t page_offset;
- page_offset = (vaddr - vma->vm_start) >> PAGE_SHIFT;
-
- num_pages = DIV_ROUND_UP(obj->base.size, PAGE_SIZE);
-
- if (page_offset >= num_pages)
- return VM_FAULT_SIGBUS;
-
- mutex_lock(&obj->pages_lock);
- if (obj->pages) {
- get_page(obj->pages[page_offset]);
- vmf->page = obj->pages[page_offset];
- ret = 0;
- }
- mutex_unlock(&obj->pages_lock);
- if (ret) {
- struct page *page;
-
- page = shmem_read_mapping_page(
- file_inode(obj->base.filp)->i_mapping,
- page_offset);
- if (!IS_ERR(page)) {
- vmf->page = page;
- ret = 0;
- } else switch (PTR_ERR(page)) {
- case -ENOSPC:
- case -ENOMEM:
- ret = VM_FAULT_OOM;
- break;
- case -EBUSY:
- ret = VM_FAULT_RETRY;
- break;
- case -EFAULT:
- case -EINVAL:
- ret = VM_FAULT_SIGBUS;
- break;
- default:
- WARN_ON(PTR_ERR(page));
- ret = VM_FAULT_SIGBUS;
- break;
- }
-
- }
- return ret;
-}
-
-static const struct vm_operations_struct vgem_gem_vm_ops = {
- .fault = vgem_gem_fault,
- .open = drm_gem_vm_open,
- .close = drm_gem_vm_close,
-};
-
static int v
[PATCH] drm/shmem-helper: Switch to vmf_insert_pfn
We want to stop gup, which isn't the case if we use vmf_insert_page
and VM_MIXEDMAP, because that does not set pte_special.
v2: With this shmem gem helpers now definitely need CONFIG_MMU (0day)
v3: add more depends on MMU. For usb drivers this is a bit awkward,
but really it's correct: To be able to provide a contig mapping of
buffers to userspace on !MMU platforms we'd need to use the cma
helpers for these drivers on those platforms. As-is this wont work.
Also not exactly sure why vm_insert_page doesn't go boom, because that
definitely wont fly in practice since the pages are non-contig to
begin with.
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/Kconfig| 2 +-
drivers/gpu/drm/drm_gem_shmem_helper.c | 4 ++--
drivers/gpu/drm/gud/Kconfig| 2 +-
drivers/gpu/drm/tiny/Kconfig | 4 ++--
drivers/gpu/drm/udl/Kconfig| 1 +
5 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 56a55a6e6239..9c21527b791f 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -206,7 +206,7 @@ config DRM_KMS_CMA_HELPER
config DRM_GEM_SHMEM_HELPER
bool
- depends on DRM
+ depends on DRM && MMU
help
Choose this if you need the GEM shmem helper functions
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index 6d625cee7a6a..11edd54f0580 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -542,7 +542,7 @@ static vm_fault_t drm_gem_shmem_fault(struct vm_fault *vmf)
} else {
page = shmem->pages[page_offset];
- ret = vmf_insert_page(vma, vmf->address, page);
+ ret = vmf_insert_pfn(vma, vmf->address, page_to_pfn(page));
}
mutex_unlock(&shmem->pages_lock);
@@ -612,7 +612,7 @@ int drm_gem_shmem_mmap(struct drm_gem_object *obj, struct
vm_area_struct *vma)
return ret;
}
- vma->vm_flags |= VM_MIXEDMAP | VM_DONTEXPAND;
+ vma->vm_flags |= VM_PFNMAP | VM_DONTEXPAND;
vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
if (shmem->map_wc)
vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
diff --git a/drivers/gpu/drm/gud/Kconfig b/drivers/gpu/drm/gud/Kconfig
index 1c8601bf4d91..9c1e61f9eec3 100644
--- a/drivers/gpu/drm/gud/Kconfig
+++ b/drivers/gpu/drm/gud/Kconfig
@@ -2,7 +2,7 @@
config DRM_GUD
tristate "GUD USB Display"
- depends on DRM && USB
+ depends on DRM && USB && MMU
select LZ4_COMPRESS
select DRM_KMS_HELPER
select DRM_GEM_SHMEM_HELPER
diff --git a/drivers/gpu/drm/tiny/Kconfig b/drivers/gpu/drm/tiny/Kconfig
index d46f95d9196d..a15f57ace9e7 100644
--- a/drivers/gpu/drm/tiny/Kconfig
+++ b/drivers/gpu/drm/tiny/Kconfig
@@ -31,7 +31,7 @@ config DRM_CIRRUS_QEMU
config DRM_GM12U320
tristate "GM12U320 driver for USB projectors"
- depends on DRM && USB
+ depends on DRM && USB && MMU
select DRM_KMS_HELPER
select DRM_GEM_SHMEM_HELPER
help
@@ -40,7 +40,7 @@ config DRM_GM12U320
config DRM_SIMPLEDRM
tristate "Simple framebuffer driver"
- depends on DRM
+ depends on DRM && MMU
select DRM_GEM_SHMEM_HELPER
select DRM_KMS_HELPER
help
diff --git a/drivers/gpu/drm/udl/Kconfig b/drivers/gpu/drm/udl/Kconfig
index 1f497d8f1ae5..c744175c6992 100644
--- a/drivers/gpu/drm/udl/Kconfig
+++ b/drivers/gpu/drm/udl/Kconfig
@@ -4,6 +4,7 @@ config DRM_UDL
depends on DRM
depends on USB
depends on USB_ARCH_HAS_HCD
+ depends on MMU
select DRM_GEM_SHMEM_HELPER
select DRM_KMS_HELPER
help
--
2.31.0
[PATCH v2] drm/panfrost: Add AFBC_FEATURES parameter
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
chip, and perhaps others.
v2: Fix typo from copy-paste fail.
Signed-off-by: Alyssa Rosenzweig
Cc: Rob Herring
Cc: Tomeu Vizoso
Cc: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_device.h | 1 +
drivers/gpu/drm/panfrost/panfrost_drv.c| 1 +
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, 5 insertions(+)
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..3383c8200 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);
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))
#define GPU_JS_FEATURES(n) (0x0C0 + ((n) * 4))
+#define GPU_AFBC_FEATURES (0x4C) /* (RO) AFBC support on Bifrost
*/
#define GPU_SHADER_PRESENT_LO 0x100 /* (RO) Shader core present
bitmap, low word */
#define GPU_SHADER_PRESENT_HI 0x104 /* (RO) Shader core present
bitmap, high word */
diff --git a/include/uapi/drm/panfrost_drm.h b/include/uapi/drm/panfrost_drm.h
index ec19db1ee..061e700dd 100644
--- a/include/uapi/drm/panfrost_drm.h
+++ b/include/uapi/drm/panfrost_drm.h
@@ -171,6 +171,7 @@ enum drm_panfrost_param {
DRM_PANFROST_PARAM_JS_FEATURES15,
DRM_PANFROST_PARAM_NR_CORE_GROUPS,
DRM_PANFROST_PARAM_THREAD_TLS_ALLOC,
+ DRM_PANFROST_PARAM_AFBC_FEATURES,
};
struct drm_panfrost_get_param {
--
2.30.2
Re: [RESEND PATCH v4 5/6] drm/msm: Add crashdump support for stalled SMMU
Hi Rob,
I love your patch! Yet something to improve:
[auto build test ERROR on iommu/next]
[also build test ERROR on drm-intel/for-linux-next drm-tip/drm-tip
drm-exynos/exynos-drm-next tegra-drm/drm/tegra/for-next linus/master v5.13-rc4
next-20210603]
[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/Rob-Clark/iommu-arm-smmu-adreno-smmu-page-fault-handling/20210603-005246
base: https://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git next
config: arm64-randconfig-r001-20210603 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project
d8e0ae9a76a62bdc6117630d59bf9967ac9bb4ea)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install arm64 cross compiling tool for clang build
# apt-get install binutils-aarch64-linux-gnu
#
https://github.com/0day-ci/linux/commit/cdbd07b471b955a50c15ea2a86f73c39bea6dfa5
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Rob-Clark/iommu-arm-smmu-adreno-smmu-page-fault-handling/20210603-005246
git checkout cdbd07b471b955a50c15ea2a86f73c39bea6dfa5
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
>> drivers/gpu/drm/msm/msm_gpu.c:510:53: error: too many arguments to function
>> call, expected 4, have 5
msm_gpu_crashstate_capture(gpu, submit, comm, cmd, false);
~~ ^
drivers/gpu/drm/msm/msm_gpu.c:432:13: note: 'msm_gpu_crashstate_capture'
declared here
static void msm_gpu_crashstate_capture(struct msm_gpu *gpu,
^
1 error generated.
vim +510 drivers/gpu/drm/msm/msm_gpu.c
460
461 static void recover_worker(struct kthread_work *work)
462 {
463 struct msm_gpu *gpu = container_of(work, struct msm_gpu,
recover_work);
464 struct drm_device *dev = gpu->dev;
465 struct msm_drm_private *priv = dev->dev_private;
466 struct msm_gem_submit *submit;
467 struct msm_ringbuffer *cur_ring = gpu->funcs->active_ring(gpu);
468 char *comm = NULL, *cmd = NULL;
469 int i;
470
471 mutex_lock(&dev->struct_mutex);
472
473 DRM_DEV_ERROR(dev->dev, "%s: hangcheck recover!\n", gpu->name);
474
475 submit = find_submit(cur_ring, cur_ring->memptrs->fence + 1);
476 if (submit) {
477 struct task_struct *task;
478
479 /* Increment the fault counts */
480 gpu->global_faults++;
481 submit->queue->faults++;
482
483 task = get_pid_task(submit->pid, PIDTYPE_PID);
484 if (task) {
485 comm = kstrdup(task->comm, GFP_KERNEL);
486 cmd = kstrdup_quotable_cmdline(task,
GFP_KERNEL);
487 put_task_struct(task);
488 }
489
490 /* msm_rd_dump_submit() needs bo locked to dump: */
491 for (i = 0; i < submit->nr_bos; i++)
492 msm_gem_lock(&submit->bos[i].obj->base);
493
494 if (comm && cmd) {
495 DRM_DEV_ERROR(dev->dev, "%s: offending task: %s
(%s)\n",
496 gpu->name, comm, cmd);
497
498 msm_rd_dump_submit(priv->hangrd, submit,
499 "offending task: %s (%s)", comm, cmd);
500 } else {
501 msm_rd_dump_submit(priv->hangrd, submit, NULL);
502 }
503
504 for (i = 0; i < submit->nr_bos; i++)
505 msm_gem_unlock(&submit->bos[i].obj->base);
506 }
507
508 /* Record the crash state */
509 pm_runtime_get_sync(&gpu->pdev->dev);
> 510 msm_gpu_crashstate_capture(gpu, submit, comm, cmd, false);
511 pm_runtime_put_sync(&gpu->pdev->dev);
512
513 kfree(cmd);
514 kfree(comm);
515
516 /*
517 * Update all the rings with the latest and greatest fence..
[PATCH] drm/panfrost: Add AFBC_FEATURES parameter
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
chip, and perhaps others.
Signed-off-by: Alyssa Rosenzweig
Cc: Rob Herring
Cc: Tomeu Vizoso
Cc: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_device.h | 1 +
drivers/gpu/drm/panfrost/panfrost_drv.c| 1 +
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, 5 insertions(+)
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..558d3f3af 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, 3);
PANFROST_FEATURE_ARRAY(TEXTURE_FEATURES, texture_features, 3);
PANFROST_FEATURE_ARRAY(JS_FEATURES, js_features, 15);
PANFROST_FEATURE(NR_CORE_GROUPS, nr_core_groups);
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))
#define GPU_JS_FEATURES(n) (0x0C0 + ((n) * 4))
+#define GPU_AFBC_FEATURES (0x4C) /* (RO) AFBC support on Bifrost
*/
#define GPU_SHADER_PRESENT_LO 0x100 /* (RO) Shader core present
bitmap, low word */
#define GPU_SHADER_PRESENT_HI 0x104 /* (RO) Shader core present
bitmap, high word */
diff --git a/include/uapi/drm/panfrost_drm.h b/include/uapi/drm/panfrost_drm.h
index ec19db1ee..061e700dd 100644
--- a/include/uapi/drm/panfrost_drm.h
+++ b/include/uapi/drm/panfrost_drm.h
@@ -171,6 +171,7 @@ enum drm_panfrost_param {
DRM_PANFROST_PARAM_JS_FEATURES15,
DRM_PANFROST_PARAM_NR_CORE_GROUPS,
DRM_PANFROST_PARAM_THREAD_TLS_ALLOC,
+ DRM_PANFROST_PARAM_AFBC_FEATURES,
};
struct drm_panfrost_get_param {
--
2.30.2
Re: [Intel-gfx] [PATCH v2 2/4] drm/shmem-helper: Switch to vmf_insert_pfn
Hi Daniel, I love your patch! Yet something to improve: [auto build test ERROR on drm-intel/for-linux-next] [also build test ERROR on drm-tip/drm-tip drm-exynos/exynos-drm-next tegra-drm/drm/tegra/for-next linus/master v5.13-rc4 next-20210603] [cannot apply to drm/drm-next] [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/Daniel-Vetter/shmem-helpers-for-igt/20210603-230602 base: git://anongit.freedesktop.org/drm-intel for-linux-next config: h8300-randconfig-r021-20210603 (attached as .config) compiler: h8300-linux-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/5ce1f8f44bf2a1a96bb1a56ef34453d958142b45 git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Daniel-Vetter/shmem-helpers-for-igt/20210603-230602 git checkout 5ce1f8f44bf2a1a96bb1a56ef34453d958142b45 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=h8300 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): h8300-linux-ld: section .init.text LMA [0059b760,005de3d5] overlaps section .text LMA [0158,0171c08b] h8300-linux-ld: section .data VMA [0040,0059b75f] overlaps section .text VMA [0158,0171c08b] h8300-linux-ld: drivers/gpu/drm/drm_gem_shmem_helper.o: in function `.Llt5': >> drm_gem_shmem_helper.c:(.text+0x16f): undefined reference to `vmf_insert_pfn' Kconfig warnings: (for reference only) WARNING: unmet direct dependencies detected for DRM_GEM_SHMEM_HELPER Depends on HAS_IOMEM && DRM && MMU Selected by - DRM_VKMS && HAS_IOMEM && DRM - DRM_UDL && HAS_IOMEM && DRM && USB && USB_ARCH_HAS_HCD - DRM_GM12U320 && HAS_IOMEM && DRM && USB --- 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 0/2] allow simple{fb,drm} drivers to be used on non-x86 EFI platforms
On Tue, Jun 01, 2021 at 04:59:10PM +0200, Javier Martinez Canillas wrote: > The series touches different subystems and will need coordination between > maintainers. Ard Biesheuvel said that can be merged through the EFI tree. I'm always happy when code from arch/x86/ moves away so Acked-by: Borislav Petkov Btw, for the future, please CC everyone on the whole patchset - I had to go look at your 2/2 on lore to see what it does because I had only 1/2 in my mbox. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette
Re: [PATCH 3/3] drm/pl111: depend on CONFIG_VEXPRESS_CONFIG
On Thu, Jun 3, 2021 at 1:42 PM Rob Herring wrote: > > On Wed, Jun 2, 2021 at 4:53 PM Kees Cook wrote: > > > > Avoid randconfig build failures by requiring VEXPRESS_CONFIG: > > > > aarch64-linux-gnu-ld: drivers/gpu/drm/pl111/pl111_versatile.o: in function > > `pl111_vexpress_clcd_init': > > pl111_versatile.c:(.text+0x220): undefined reference to > > `devm_regmap_init_vexpress_config' > > pl111_vexpress_clcd_init() starts with: > > if (!IS_ENABLED(CONFIG_VEXPRESS_CONFIG)) > return -ENODEV; > > Isn't that supposed to be enough to avoid an undefined reference? > > Making the whole file depend on VEXPRESS_CONFIG is not right either. > Not all platforms need it. Specifically, these defconfigs will break as they all use PL111 but don't need nor enable VEXPRESS_CONFIG: arch/arm/configs/integrator_defconfig:CONFIG_DRM_PL111=y arch/arm/configs/lpc18xx_defconfig:CONFIG_DRM_PL111=y arch/arm/configs/lpc32xx_defconfig:CONFIG_DRM_PL111=y arch/arm/configs/nhk8815_defconfig:CONFIG_DRM_PL111=y arch/arm/configs/realview_defconfig:CONFIG_DRM_PL111=y arch/arm/configs/spear3xx_defconfig:CONFIG_DRM_PL111=y arch/arm/configs/versatile_defconfig:CONFIG_DRM_PL111=y These defconfigs should all be failing with the same error, but don't from what I've tried nor have I seen any kernelci failures. Rob
Re: [PATCH] drm/i915: Add relocation exceptions for two other platforms
On Wed, Jun 2, 2021 at 12:25 AM Zbigniew Kempczyński
wrote:
>
> We have established previously we stop using relocations starting
> from gen12 platforms with Tigerlake as an exception. We keep this
> statement but we want to enable relocations conditionally for
> Rocketlake and Alderlake under require_force_probe flag set.
>
> Keeping relocations under require_force_probe flag is interim solution
> until IGTs will be rewritten to use softpin.
>
> v2: - remove inline from function definition (Jani)
> - fix indentation
>
> Signed-off-by: Zbigniew Kempczyński
> Cc: Dave Airlie
> Cc: Daniel Vetter
> Cc: Jason Ekstrand
Acked-by: Dave Airlie
> ---
> .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 24 +++
> 1 file changed, 19 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index 297143511f99..78b86a7bc39a 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -491,16 +491,30 @@ eb_unreserve_vma(struct eb_vma *ev)
> ev->flags &= ~__EXEC_OBJECT_RESERVED;
> }
>
> +static bool platform_has_relocs_enabled(const struct i915_execbuffer *eb)
> +{
> + /*
> +* Relocations are disallowed starting from gen12 with Tigerlake
> +* as an exception. We allow temporarily use relocations for
> Rocketlake
> +* and Alderlake when require_force_probe flag is set.
> +*/
> + if (INTEL_GEN(eb->i915) < 12 || IS_TIGERLAKE(eb->i915))
> + return true;
> +
> + if (INTEL_INFO(eb->i915)->require_force_probe &&
> + (IS_ROCKETLAKE(eb->i915) || IS_ALDERLAKE_S(eb->i915) ||
> +IS_ALDERLAKE_P(eb->i915)))
> + return true;
> +
> + return false;
> +}
> +
> static int
> eb_validate_vma(struct i915_execbuffer *eb,
> struct drm_i915_gem_exec_object2 *entry,
> struct i915_vma *vma)
> {
> - /* Relocations are disallowed for all platforms after TGL-LP. This
> -* also covers all platforms with local memory.
> -*/
> - if (entry->relocation_count &&
> - INTEL_GEN(eb->i915) >= 12 && !IS_TIGERLAKE(eb->i915))
> + if (entry->relocation_count && !platform_has_relocs_enabled(eb))
> return -EINVAL;
>
> if (unlikely(entry->flags & eb->invalid_flags))
> --
> 2.26.0
>
[Bug 213321] Laptop not waking from sleep
https://bugzilla.kernel.org/show_bug.cgi?id=213321 Alex Deucher (alexdeuc...@gmail.com) changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #4 from Alex Deucher (alexdeuc...@gmail.com) --- This is probably a S0ix laptop and requires a number of platform fixes as well. See: https://gitlab.freedesktop.org/drm/amd/-/issues/1230 -- 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: [PATCH] radeon: use memcpy_to/fromio for UVD fw upload
On Thu, Jun 3, 2021 at 3:35 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.
>
> Also fix some coding issues reported from sparse.
Can you split the sparse fixes and the mmio fixes into two patches?
Thanks,
Alex
>
> Signed-off-by: Chen Li
> ---
> drivers/gpu/drm/radeon/radeon_uvd.c | 30 -
> 1 file changed, 17 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c
> b/drivers/gpu/drm/radeon/radeon_uvd.c
> index dfa9fdbe98da..0d6a5cfa2abf 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);
>
> @@ -286,7 +288,9 @@ 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,
> + le32_to_cpu((__force
> __le32)rdev->uvd_fw->size));
>
> size = radeon_bo_size(rdev->uvd.vcpu_bo);
> size -= rdev->uvd_fw->size;
> @@ -294,7 +298,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;
> }
> @@ -791,17 +795,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), &msg[0]);
> + writel((__force u32)cpu_to_le32(0x0de4), &msg[0]);
> writel(0x0, (void __iomem *)&msg[1]);
> - writel(cpu_to_le32(handle), &msg[2]);
> + writel((__force u32)cpu_to_le32(handle), &msg[2]);
> writel(0x0, &msg[3]);
> writel(0x0, &msg[4]);
> writel(0x0, &msg[5]);
> writel(0x0, &msg[6]);
> - writel(cpu_to_le32(0x0780), &msg[7]);
> - writel(cpu_to_le32(0x0440), &msg[8]);
> + writel((__force u32)cpu_to_le32(0x0780), &msg[7]);
> + writel((__force u32)cpu_to_le32(0x0440), &msg[8]);
> writel(0x0, &msg[9]);
> - writel(cpu_to_le32(0x01b37000), &msg[10]);
> + writel((__force u32)cpu_to_le32(0x01b37000), &msg[10]);
> for (i = 11; i < 1024; ++i)
> writel(0x0, &msg[i]);
>
> @@ -827,9 +831,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), &msg[0]);
> - writel(cpu_to_le32(0x0002), &msg[1]);
> - writel(cpu_to_le32(handle), &msg[2]);
> + writel((__force u32)cpu_to_le32(0x0de4), &msg[0]);
> + writel((__force u32)cpu_to_le32(0x0002), &msg[1]);
> + writel((__force u32)cpu_to_le32(handle), &msg[2]);
> writel(0x0, &msg[3]);
> for (i = 4; i < 1024; ++i)
> writel(0x0, &msg[i]);
> --
> 2.31.1
>
>
>
Re: [PATCH 3/3] drm/pl111: depend on CONFIG_VEXPRESS_CONFIG
On Thu, Jun 3, 2021 at 8:43 PM Rob Herring wrote:
>
> On Wed, Jun 2, 2021 at 4:53 PM Kees Cook wrote:
> >
> > Avoid randconfig build failures by requiring VEXPRESS_CONFIG:
> >
> > aarch64-linux-gnu-ld: drivers/gpu/drm/pl111/pl111_versatile.o: in function
> > `pl111_vexpress_clcd_init':
> > pl111_versatile.c:(.text+0x220): undefined reference to
> > `devm_regmap_init_vexpress_config'
>
> pl111_vexpress_clcd_init() starts with:
>
> if (!IS_ENABLED(CONFIG_VEXPRESS_CONFIG))
> return -ENODEV;
>
> Isn't that supposed to be enough to avoid an undefined reference?
>
> Making the whole file depend on VEXPRESS_CONFIG is not right either.
> Not all platforms need it.
It needs a compile-time status inline then for the functions we're
using in pl111.
-Daniel
>
> >
> > Fixes: 826fc86b5903 ("drm: pl111: Move VExpress setup into versatile init")
> > Signed-off-by: Kees Cook
> > ---
> > drivers/gpu/drm/pl111/Kconfig | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/pl111/Kconfig b/drivers/gpu/drm/pl111/Kconfig
> > index 80f6748055e3..c5210a5bef1b 100644
> > --- a/drivers/gpu/drm/pl111/Kconfig
> > +++ b/drivers/gpu/drm/pl111/Kconfig
> > @@ -2,7 +2,7 @@
> > config DRM_PL111
> > tristate "DRM Support for PL111 CLCD Controller"
> > depends on DRM
> > - depends on ARM || ARM64 || COMPILE_TEST
> > + depends on VEXPRESS_CONFIG
> > depends on COMMON_CLK
> > select DRM_KMS_HELPER
> > select DRM_KMS_CMA_HELPER
> > --
> > 2.25.1
> >
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [Mesa-dev] Linux Graphics Next: Userspace submission update
On Thu, Jun 3, 2021 at 7:53 PM Marek Olšák wrote: > > Daniel, I think what you are suggesting is that we need to enable user queues > with the drm scheduler and dma_fence first, and once that works, we can > investigate how much of that kernel logic can be moved to the hw. Would that > work? In theory it shouldn't matter whether the kernel does it or the hw does > it. It's the same code, just in a different place. Yeah I guess that's another way to look at it. Maybe in practice you'll just move it from the kernel to userspace, which then programs the hw waits directly into its IB. That's at least how I'd do it on i915, assuming I'd have such hw. So these fences that userspace programs directly (to sync within itself) won't even show up as dependencies in the kernel. And then yes on the other side you can lift work from the drm/scheduler wrt dependencies you get in the kernel (whether explicit sync with sync_file, or implicit sync fished out of dma_resv) and program the hw directly that way. That would mean that userspace wont fill the ringbuffer directly, but the kernel would do that, so that you have space to stuff in the additional waits. Again assuming i915 hw model, maybe works differently on amd. Iirc we have some of that already in the i915 scheduler, but I'd need to recheck how much it really uses the hw semaphores. -Daniel > Thanks, > Marek > > On Thu, Jun 3, 2021 at 7:22 AM Daniel Vetter wrote: >> >> On Thu, Jun 3, 2021 at 12:55 PM Marek Olšák wrote: >> > >> > On Thu., Jun. 3, 2021, 06:03 Daniel Vetter, wrote: >> >> >> >> On Thu, Jun 03, 2021 at 04:20:18AM -0400, Marek Olšák wrote: >> >> > On Thu, Jun 3, 2021 at 3:47 AM Daniel Vetter wrote: >> >> > >> >> > > On Wed, Jun 02, 2021 at 11:16:39PM -0400, Marek Olšák wrote: >> >> > > > On Wed, Jun 2, 2021 at 2:48 PM Daniel Vetter >> >> > > > wrote: >> >> > > > >> >> > > > > On Wed, Jun 02, 2021 at 05:38:51AM -0400, Marek Olšák wrote: >> >> > > > > > On Wed, Jun 2, 2021 at 5:34 AM Marek Olšák >> >> > > > > > wrote: >> >> > > > > > >> >> > > > > > > Yes, we can't break anything because we don't want to >> >> > > > > > > complicate >> >> > > things >> >> > > > > > > for us. It's pretty much all NAK'd already. We are trying to >> >> > > > > > > gather >> >> > > > > more >> >> > > > > > > knowledge and then make better decisions. >> >> > > > > > > >> >> > > > > > > The idea we are considering is that we'll expose memory-based >> >> > > > > > > sync >> >> > > > > objects >> >> > > > > > > to userspace for read only, and the kernel or hw will strictly >> >> > > control >> >> > > > > the >> >> > > > > > > memory writes to those sync objects. The hole in that idea is >> >> > > > > > > that >> >> > > > > > > userspace can decide not to signal a job, so even if userspace >> >> > > can't >> >> > > > > > > overwrite memory-based sync object states arbitrarily, it can >> >> > > > > > > still >> >> > > > > decide >> >> > > > > > > not to signal them, and then a future fence is born. >> >> > > > > > > >> >> > > > > > >> >> > > > > > This would actually be treated as a GPU hang caused by that >> >> > > > > > context, >> >> > > so >> >> > > > > it >> >> > > > > > should be fine. >> >> > > > > >> >> > > > > This is practically what I proposed already, except your not >> >> > > > > doing it >> >> > > with >> >> > > > > dma_fence. And on the memory fence side this also doesn't >> >> > > > > actually give >> >> > > > > what you want for that compute model. >> >> > > > > >> >> > > > > This seems like a bit a worst of both worlds approach to me? Tons >> >> > > > > of >> >> > > work >> >> > > > > in the kernel to hide these not-dma_fence-but-almost, and still >> >> > > > > pain to >> >> > > > > actually drive the hardware like it should be for compute or >> >> > > > > direct >> >> > > > > display. >> >> > > > > >> >> > > > > Also maybe I've missed it, but I didn't see any replies to my >> >> > > suggestion >> >> > > > > how to fake the entire dma_fence stuff on top of new hw. Would be >> >> > > > > interesting to know what doesn't work there instead of amd folks >> >> > > > > going >> >> > > of >> >> > > > > into internal again and then coming back with another rfc from >> >> > > > > out of >> >> > > > > nowhere :-) >> >> > > > > >> >> > > > >> >> > > > Going internal again is probably a good idea to spare you the long >> >> > > > discussions and not waste your time, but we haven't talked about the >> >> > > > dma_fence stuff internally other than acknowledging that it can be >> >> > > solved. >> >> > > > >> >> > > > The compute use case already uses the hw as-is with no inter-process >> >> > > > sharing, which mostly keeps the kernel out of the picture. It uses >> >> > > glFinish >> >> > > > to sync with GL. >> >> > > > >> >> > > > The gfx use case needs new hardware logic to support implicit and >> >> > > explicit >> >> > > > sync. When we propose a solution, it's usually torn apart the next >> >> > > > day by >> >> > > > ourselves. >> >> > > > >
Re: [PATCH] drm: fix doc warnings in drm_atomic.h
Applied. Thanks!
Alex
On Thu, Jun 3, 2021 at 7:21 AM Yu Kuai wrote:
>
> Add description for parameters for
> for_each_new_plane_in_state_reverse to fix warnings:
>
> include/drm/drm_atomic.h:908: warning: Function parameter or member '__state'
> not described in 'for_each_new_plane_in_state_reverse'
> include/drm/drm_atomic.h:908: warning: Function parameter or member 'plane'
> not described in 'for_each_new_plane_in_state_reverse'
> include/drm/drm_atomic.h:908: warning: Function parameter or member
> 'new_plane_state' not described in 'for_each_new_plane_in_state_reverse'
> include/drm/drm_atomic.h:908: warning: Function parameter or member '__i' not
> described in 'for_each_new_plane_in_state_reverse'
>
> Fixes: a6c3c37b661d ("drm/amd/display: fix gcc set but not used warning of
> variable 'old_plane_state'")
> Signed-off-by: Yu Kuai
> ---
> include/drm/drm_atomic.h | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
> index 8f1350e599eb..1701c2128a5c 100644
> --- a/include/drm/drm_atomic.h
> +++ b/include/drm/drm_atomic.h
> @@ -898,6 +898,10 @@ void drm_state_dump(struct drm_device *dev, struct
> drm_printer *p);
> /**
> * for_each_new_plane_in_state_reverse - other than only tracking new state,
> * it's the same as for_each_oldnew_plane_in_state_reverse
> + * @__state: &struct drm_atomic_state pointer
> + * @plane: &struct drm_plane iteration cursor
> + * @new_plane_state: &struct drm_plane_state iteration cursor for the new
> state
> + * @__i: int iteration cursor, for macro-internal use
> */
> #define for_each_new_plane_in_state_reverse(__state, plane, new_plane_state,
> __i) \
> for ((__i) = ((__state)->dev->mode_config.num_total_plane - 1); \
> --
> 2.31.1
>
Re: [PATCH] drm/amd/display: remove variable active_disp
Applied. Thanks!
Alex
On Thu, Jun 3, 2021 at 8:42 AM Colin King wrote:
>
> From: Colin Ian King
>
> The variable active_disp is being initialized with a value that
> is never read, it is being re-assigned immediately afterwards.
> Clean up the code by removing the need for variable active_disp.
>
> Addresses-Coverity: ("Unused value")
> Signed-off-by: Colin Ian King
> ---
> drivers/gpu/drm/amd/display/dc/bios/bios_parser_helper.c | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser_helper.c
> b/drivers/gpu/drm/amd/display/dc/bios/bios_parser_helper.c
> index 53d7513b5083..adc710fe4a45 100644
> --- a/drivers/gpu/drm/amd/display/dc/bios/bios_parser_helper.c
> +++ b/drivers/gpu/drm/amd/display/dc/bios/bios_parser_helper.c
> @@ -82,9 +82,6 @@ void bios_set_scratch_critical_state(
> uint32_t bios_get_vga_enabled_displays(
> struct dc_bios *bios)
> {
> - uint32_t active_disp = 1;
> -
> - active_disp = REG_READ(BIOS_SCRATCH_3) & 0X;
> - return active_disp;
> + return REG_READ(BIOS_SCRATCH_3) & 0X;
> }
>
> --
> 2.31.1
>
Re: [PATCH v2 3/4] drm/shmem-helper: Align to page size in dumb_create
Am 03.06.21 um 17:03 schrieb Daniel Vetter:
shmem helpers seem a bit sloppy here by automatically rounding up when
actually creating the buffer, which results in under-reporting of what
we actually have. Caught by igt/vgem_basic tests.
Acked-by: Thomas Zimmermann
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
Acked-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index 32f1d7601ec6..2985744b4300 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -506,13 +506,13 @@ int drm_gem_shmem_dumb_create(struct drm_file *file,
struct drm_device *dev,
if (!args->pitch || !args->size) {
args->pitch = min_pitch;
- args->size = args->pitch * args->height;
+ args->size = PAGE_ALIGN(args->pitch * args->height);
} else {
/* ensure sane minimum values */
if (args->pitch < min_pitch)
args->pitch = min_pitch;
if (args->size < args->pitch * args->height)
- args->size = args->pitch * args->height;
+ args->size = PAGE_ALIGN(args->pitch * args->height);
}
shmem = drm_gem_shmem_create_with_handle(file, dev, args->size, &args->handle);
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
Re: [Intel-gfx] [PATCH v2 4/4] drm/vgem: use shmem helpers
On Thu, Jun 03, 2021 at 09:42:00PM +0300, Andi Shyti wrote:
> Hi Daniel,
>
> > +/*
> > + * This just sets wc mode for shmem helpers. vgem doesn't have any
> > begin/end cpu
> > + * access ioctls, there must use coherent memory or dma-buf sharing just
> > wont
> > + * work.
> > + */
> > +static struct drm_gem_object *vgem_gem_create_object(struct drm_device
> > *dev, size_t size)
> > {
> > - struct drm_vgem_gem_object *obj;
> > - int npages;
> > + struct drm_gem_shmem_object *obj;
> >
> > - obj = __vgem_gem_create(dev, attach->dmabuf->size);
> > - if (IS_ERR(obj))
> > - return ERR_CAST(obj);
> > -
> > - npages = PAGE_ALIGN(attach->dmabuf->size) / PAGE_SIZE;
> > + obj = kzalloc(sizeof(*obj), GFP_KERNEL);
> > + if (!obj)
> > + return NULL;
> >
> > - obj->table = sg;
> > - obj->pages = kvmalloc_array(npages, sizeof(struct page *), GFP_KERNEL);
> > - if (!obj->pages) {
> > - __vgem_gem_destroy(obj);
> > - return ERR_PTR(-ENOMEM);
> > - }
> > + obj->base.funcs = &drm_gem_shmem_funcs;
> > + obj->map_wc = true;
> >
> > - obj->pages_pin_count++; /* perma-pinned */
> > - drm_prime_sg_to_page_array(obj->table, obj->pages, npages);
> > return &obj->base;
>
> here you are allocating a bigger object than what you are
> returning, in size. How does it get freed?
We're using the drm_gem_shmem_helper.c helpers, which set up all the shmem
functions for us, including an appropriate free callback.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH 1/3] drm: Avoid circular dependencies for CONFIG_FB
On Thu, Jun 3, 2021 at 3:48 AM Daniel Vetter wrote: > > On Wed, Jun 02, 2021 at 02:52:50PM -0700, Kees Cook wrote: > > When cleaning up other drm config dependencies, it is too easy to create > > larger problems. Instead, mark CONFIG_FB as a "depends": > > > > drivers/gpu/drm/Kconfig:74:error: recursive dependency detected! > > > > Suggested-by: Arnd Bergmann > > Link: > > https://lore.kernel.org/lkml/cak8p3a3juqs6c5tessnmbqfuymewj9fhqrizyhcfoxf8rgy...@mail.gmail.com/ > > Signed-off-by: Kees Cook > > I rebased this one for -next and applied all three patches to > drm-misc-next. Patch 3 is not the right fix and I think breaks some platforms. Rob
Re: [PATCH 3/3] drm/pl111: depend on CONFIG_VEXPRESS_CONFIG
On Wed, Jun 2, 2021 at 4:53 PM Kees Cook wrote:
>
> Avoid randconfig build failures by requiring VEXPRESS_CONFIG:
>
> aarch64-linux-gnu-ld: drivers/gpu/drm/pl111/pl111_versatile.o: in function
> `pl111_vexpress_clcd_init':
> pl111_versatile.c:(.text+0x220): undefined reference to
> `devm_regmap_init_vexpress_config'
pl111_vexpress_clcd_init() starts with:
if (!IS_ENABLED(CONFIG_VEXPRESS_CONFIG))
return -ENODEV;
Isn't that supposed to be enough to avoid an undefined reference?
Making the whole file depend on VEXPRESS_CONFIG is not right either.
Not all platforms need it.
>
> Fixes: 826fc86b5903 ("drm: pl111: Move VExpress setup into versatile init")
> Signed-off-by: Kees Cook
> ---
> drivers/gpu/drm/pl111/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/pl111/Kconfig b/drivers/gpu/drm/pl111/Kconfig
> index 80f6748055e3..c5210a5bef1b 100644
> --- a/drivers/gpu/drm/pl111/Kconfig
> +++ b/drivers/gpu/drm/pl111/Kconfig
> @@ -2,7 +2,7 @@
> config DRM_PL111
> tristate "DRM Support for PL111 CLCD Controller"
> depends on DRM
> - depends on ARM || ARM64 || COMPILE_TEST
> + depends on VEXPRESS_CONFIG
> depends on COMMON_CLK
> select DRM_KMS_HELPER
> select DRM_KMS_CMA_HELPER
> --
> 2.25.1
>
Re: [Intel-gfx] [PATCH v2 4/4] drm/vgem: use shmem helpers
Hi Daniel,
> +/*
> + * This just sets wc mode for shmem helpers. vgem doesn't have any begin/end
> cpu
> + * access ioctls, there must use coherent memory or dma-buf sharing just wont
> + * work.
> + */
> +static struct drm_gem_object *vgem_gem_create_object(struct drm_device *dev,
> size_t size)
> {
> - struct drm_vgem_gem_object *obj;
> - int npages;
> + struct drm_gem_shmem_object *obj;
>
> - obj = __vgem_gem_create(dev, attach->dmabuf->size);
> - if (IS_ERR(obj))
> - return ERR_CAST(obj);
> -
> - npages = PAGE_ALIGN(attach->dmabuf->size) / PAGE_SIZE;
> + obj = kzalloc(sizeof(*obj), GFP_KERNEL);
> + if (!obj)
> + return NULL;
>
> - obj->table = sg;
> - obj->pages = kvmalloc_array(npages, sizeof(struct page *), GFP_KERNEL);
> - if (!obj->pages) {
> - __vgem_gem_destroy(obj);
> - return ERR_PTR(-ENOMEM);
> - }
> + obj->base.funcs = &drm_gem_shmem_funcs;
> + obj->map_wc = true;
>
> - obj->pages_pin_count++; /* perma-pinned */
> - drm_prime_sg_to_page_array(obj->table, obj->pages, npages);
> return &obj->base;
here you are allocating a bigger object than what you are
returning, in size. How does it get freed?
Andi
Re: [Mesa-dev] Linux Graphics Next: Userspace submission update
Daniel, I think what you are suggesting is that we need to enable user queues with the drm scheduler and dma_fence first, and once that works, we can investigate how much of that kernel logic can be moved to the hw. Would that work? In theory it shouldn't matter whether the kernel does it or the hw does it. It's the same code, just in a different place. Thanks, Marek On Thu, Jun 3, 2021 at 7:22 AM Daniel Vetter wrote: > On Thu, Jun 3, 2021 at 12:55 PM Marek Olšák wrote: > > > > On Thu., Jun. 3, 2021, 06:03 Daniel Vetter, wrote: > >> > >> On Thu, Jun 03, 2021 at 04:20:18AM -0400, Marek Olšák wrote: > >> > On Thu, Jun 3, 2021 at 3:47 AM Daniel Vetter wrote: > >> > > >> > > On Wed, Jun 02, 2021 at 11:16:39PM -0400, Marek Olšák wrote: > >> > > > On Wed, Jun 2, 2021 at 2:48 PM Daniel Vetter > wrote: > >> > > > > >> > > > > On Wed, Jun 02, 2021 at 05:38:51AM -0400, Marek Olšák wrote: > >> > > > > > On Wed, Jun 2, 2021 at 5:34 AM Marek Olšák > wrote: > >> > > > > > > >> > > > > > > Yes, we can't break anything because we don't want to > complicate > >> > > things > >> > > > > > > for us. It's pretty much all NAK'd already. We are trying > to gather > >> > > > > more > >> > > > > > > knowledge and then make better decisions. > >> > > > > > > > >> > > > > > > The idea we are considering is that we'll expose > memory-based sync > >> > > > > objects > >> > > > > > > to userspace for read only, and the kernel or hw will > strictly > >> > > control > >> > > > > the > >> > > > > > > memory writes to those sync objects. The hole in that idea > is that > >> > > > > > > userspace can decide not to signal a job, so even if > userspace > >> > > can't > >> > > > > > > overwrite memory-based sync object states arbitrarily, it > can still > >> > > > > decide > >> > > > > > > not to signal them, and then a future fence is born. > >> > > > > > > > >> > > > > > > >> > > > > > This would actually be treated as a GPU hang caused by that > context, > >> > > so > >> > > > > it > >> > > > > > should be fine. > >> > > > > > >> > > > > This is practically what I proposed already, except your not > doing it > >> > > with > >> > > > > dma_fence. And on the memory fence side this also doesn't > actually give > >> > > > > what you want for that compute model. > >> > > > > > >> > > > > This seems like a bit a worst of both worlds approach to me? > Tons of > >> > > work > >> > > > > in the kernel to hide these not-dma_fence-but-almost, and still > pain to > >> > > > > actually drive the hardware like it should be for compute or > direct > >> > > > > display. > >> > > > > > >> > > > > Also maybe I've missed it, but I didn't see any replies to my > >> > > suggestion > >> > > > > how to fake the entire dma_fence stuff on top of new hw. Would > be > >> > > > > interesting to know what doesn't work there instead of amd > folks going > >> > > of > >> > > > > into internal again and then coming back with another rfc from > out of > >> > > > > nowhere :-) > >> > > > > > >> > > > > >> > > > Going internal again is probably a good idea to spare you the long > >> > > > discussions and not waste your time, but we haven't talked about > the > >> > > > dma_fence stuff internally other than acknowledging that it can be > >> > > solved. > >> > > > > >> > > > The compute use case already uses the hw as-is with no > inter-process > >> > > > sharing, which mostly keeps the kernel out of the picture. It uses > >> > > glFinish > >> > > > to sync with GL. > >> > > > > >> > > > The gfx use case needs new hardware logic to support implicit and > >> > > explicit > >> > > > sync. When we propose a solution, it's usually torn apart the > next day by > >> > > > ourselves. > >> > > > > >> > > > Since we are talking about next hw or next next hw, preemption > should be > >> > > > better. > >> > > > > >> > > > user queue = user-mapped ring buffer > >> > > > > >> > > > For implicit sync, we will only let userspace lock access to a > buffer > >> > > via a > >> > > > user queue, which waits for the per-buffer sequence counter in > memory to > >> > > be > >> > > > >= the number assigned by the kernel, and later unlock the access > with > >> > > > another command, which increments the per-buffer sequence counter > in > >> > > memory > >> > > > with atomic_inc regardless of the number assigned by the kernel. > The > >> > > kernel > >> > > > counter and the counter in memory can be out-of-sync, and I'll > explain > >> > > why > >> > > > it's OK. If a process increments the kernel counter but not the > memory > >> > > > counter, that's its problem and it's the same as a GPU hang > caused by > >> > > that > >> > > > process. If a process increments the memory counter but not the > kernel > >> > > > counter, the ">=" condition alongside atomic_inc guarantee that > >> > > signaling n > >> > > > will signal n+1, so it will never deadlock but also it will > effectively > >> > > > disable synchronization. This method of disabling synchronization > is > >> > > > similar to a proc
[PATCH v3 1/7] drm/i915/gt: replace IS_GEN and friends with GRAPHICS_VER
This was done by the following semantic patch:
@@ expression i915; @@
- INTEL_GEN(i915)
+ GRAPHICS_VER(i915)
@@ expression i915; expression E; @@
- INTEL_GEN(i915) >= E
+ GRAPHICS_VER(i915) >= E
@@ expression dev_priv; expression E; @@
- !IS_GEN(dev_priv, E)
+ GRAPHICS_VER(dev_priv) != E
@@ expression dev_priv; expression E; @@
- IS_GEN(dev_priv, E)
+ GRAPHICS_VER(dev_priv) == E
@@
expression dev_priv;
expression from, until;
@@
- IS_GEN_RANGE(dev_priv, from, until)
+ IS_GRAPHICS_VER(dev_priv, from, until)
@def@
expression E;
identifier id =~ "^gen$";
@@
- id = GRAPHICS_VER(E)
+ ver = GRAPHICS_VER(E)
@@
identifier def.id;
@@
- id
+ ver
It also takes care of renaming the variable we assign to GRAPHICS_VER()
so to use "ver" rather than "gen".
Signed-off-by: Lucas De Marchi
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/gt/debugfs_gt_pm.c | 38 +--
drivers/gpu/drm/i915/gt/gen2_engine_cs.c | 2 +-
drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 2 +-
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 2 +-
drivers/gpu/drm/i915/gt/intel_context_sseu.c | 2 +-
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 54 +++
.../drm/i915/gt/intel_execlists_submission.c | 18 ++---
drivers/gpu/drm/i915/gt/intel_ggtt.c | 18 ++---
drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 34 +-
drivers/gpu/drm/i915/gt/intel_gt.c| 27
.../gpu/drm/i915/gt/intel_gt_clock_utils.c| 12 ++--
drivers/gpu/drm/i915/gt/intel_gt_irq.c| 6 +-
drivers/gpu/drm/i915/gt/intel_gt_pm_irq.c | 10 +--
drivers/gpu/drm/i915/gt/intel_gtt.c | 14 ++--
drivers/gpu/drm/i915/gt/intel_llc.c | 6 +-
drivers/gpu/drm/i915/gt/intel_lrc.c | 46 ++---
drivers/gpu/drm/i915/gt/intel_mocs.c | 8 +--
drivers/gpu/drm/i915/gt/intel_ppgtt.c | 6 +-
drivers/gpu/drm/i915/gt/intel_rc6.c | 16 ++---
drivers/gpu/drm/i915/gt/intel_renderstate.c | 2 +-
drivers/gpu/drm/i915/gt/intel_reset.c | 14 ++--
.../gpu/drm/i915/gt/intel_ring_submission.c | 64 +-
drivers/gpu/drm/i915/gt/intel_rps.c | 60 -
drivers/gpu/drm/i915/gt/intel_sseu.c | 14 ++--
drivers/gpu/drm/i915/gt/intel_workarounds.c | 66 +--
drivers/gpu/drm/i915/gt/selftest_engine_cs.c | 6 +-
drivers/gpu/drm/i915/gt/selftest_engine_pm.c | 2 +-
drivers/gpu/drm/i915/gt/selftest_execlists.c | 4 +-
drivers/gpu/drm/i915/gt/selftest_gt_pm.c | 8 +--
drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 8 +--
drivers/gpu/drm/i915/gt/selftest_llc.c| 4 +-
drivers/gpu/drm/i915/gt/selftest_lrc.c| 8 +--
drivers/gpu/drm/i915/gt/selftest_mocs.c | 2 +-
drivers/gpu/drm/i915/gt/selftest_rc6.c| 4 +-
.../drm/i915/gt/selftest_ring_submission.c| 6 +-
drivers/gpu/drm/i915/gt/selftest_rps.c| 16 ++---
drivers/gpu/drm/i915/gt/selftest_timeline.c | 6 +-
.../gpu/drm/i915/gt/selftest_workarounds.c| 8 +--
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 4 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c| 2 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c | 2 +-
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 10 +--
drivers/gpu/drm/i915/gt/uc/intel_huc.c| 2 +-
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 4 +-
44 files changed, 324 insertions(+), 323 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/debugfs_gt_pm.c
b/drivers/gpu/drm/i915/gt/debugfs_gt_pm.c
index d4f4452ce5ed..0389bceebd06 100644
--- a/drivers/gpu/drm/i915/gt/debugfs_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/debugfs_gt_pm.c
@@ -85,14 +85,14 @@ static int gen6_drpc(struct seq_file *m)
gt_core_status = intel_uncore_read_fw(uncore, GEN6_GT_CORE_STATUS);
rcctl1 = intel_uncore_read(uncore, GEN6_RC_CONTROL);
- if (INTEL_GEN(i915) >= 9) {
+ if (GRAPHICS_VER(i915) >= 9) {
gen9_powergate_enable =
intel_uncore_read(uncore, GEN9_PG_ENABLE);
gen9_powergate_status =
intel_uncore_read(uncore, GEN9_PWRGT_DOMAIN_STATUS);
}
- if (INTEL_GEN(i915) <= 7)
+ if (GRAPHICS_VER(i915) <= 7)
sandybridge_pcode_read(i915, GEN6_PCODE_READ_RC6VIDS,
&rc6vids, NULL);
@@ -100,7 +100,7 @@ static int gen6_drpc(struct seq_file *m)
yesno(rcctl1 & GEN6_RC_CTL_RC1e_ENABLE));
seq_printf(m, "RC6 Enabled: %s\n",
yesno(rcctl1 & GEN6_RC_CTL_RC6_ENABLE));
- if (INTEL_GEN(i915) >= 9) {
+ if (GRAPHICS_VER(i915) >= 9) {
seq_printf(m, "Render Well Gating Enabled: %s\n",
yesno(gen9_powerg
[PATCH v3 4/7] drm/i915/gvt: replace IS_GEN and friends with GRAPHICS_VER
This was done by the following semantic patch:
@@ expression i915; @@
- INTEL_GEN(i915)
+ GRAPHICS_VER(i915)
@@ expression i915; expression E; @@
- INTEL_GEN(i915) >= E
+ GRAPHICS_VER(i915) >= E
@@ expression dev_priv; expression E; @@
- !IS_GEN(dev_priv, E)
+ GRAPHICS_VER(dev_priv) != E
@@ expression dev_priv; expression E; @@
- IS_GEN(dev_priv, E)
+ GRAPHICS_VER(dev_priv) == E
@@
expression dev_priv;
expression from, until;
@@
- IS_GEN_RANGE(dev_priv, from, until)
+ IS_GRAPHICS_VER(dev_priv, from, until)
@def@
expression E;
identifier id =~ "^gen$";
@@
- id = GRAPHICS_VER(E)
+ ver = GRAPHICS_VER(E)
@@
identifier def.id;
@@
- id
+ ver
It also takes care of renaming the variable we assign to GRAPHICS_VER()
so to use "ver" rather than "gen".
Cc: intel-gvt-...@lists.freedesktop.org
Cc: Zhenyu Wang
Signed-off-by: Lucas De Marchi
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/gvt/cmd_parser.c | 8
drivers/gpu/drm/i915/gvt/dmabuf.c | 2 +-
drivers/gpu/drm/i915/gvt/fb_decoder.c | 10 +-
drivers/gpu/drm/i915/gvt/gtt.c | 4 ++--
drivers/gpu/drm/i915/gvt/handlers.c | 6 +++---
drivers/gpu/drm/i915/gvt/interrupt.c| 2 +-
drivers/gpu/drm/i915/gvt/mmio_context.c | 10 +-
drivers/gpu/drm/i915/gvt/scheduler.c| 4 ++--
drivers/gpu/drm/i915/gvt/vgpu.c | 4 ++--
9 files changed, 25 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/cmd_parser.c
b/drivers/gpu/drm/i915/gvt/cmd_parser.c
index ca9c9e27a43d..c4118b808268 100644
--- a/drivers/gpu/drm/i915/gvt/cmd_parser.c
+++ b/drivers/gpu/drm/i915/gvt/cmd_parser.c
@@ -1006,7 +1006,7 @@ static int cmd_reg_handler(struct parser_exec_state *s,
* update reg values in it into vregs, so LRIs in workload with
* inhibit context will restore with correct values
*/
- if (IS_GEN(s->engine->i915, 9) &&
+ if (GRAPHICS_VER(s->engine->i915) == 9 &&
intel_gvt_mmio_is_sr_in_ctx(gvt, offset) &&
!strncmp(cmd, "lri", 3)) {
intel_gvt_hypervisor_read_gpa(s->vgpu,
@@ -1390,7 +1390,7 @@ static int gen8_check_mi_display_flip(struct
parser_exec_state *s,
if (!info->async_flip)
return 0;
- if (INTEL_GEN(s->engine->i915) >= 9) {
+ if (GRAPHICS_VER(s->engine->i915) >= 9) {
stride = vgpu_vreg_t(s->vgpu, info->stride_reg) & GENMASK(9, 0);
tile = (vgpu_vreg_t(s->vgpu, info->ctrl_reg) &
GENMASK(12, 10)) >> 10;
@@ -1418,7 +1418,7 @@ static int gen8_update_plane_mmio_from_mi_display_flip(
set_mask_bits(&vgpu_vreg_t(vgpu, info->surf_reg), GENMASK(31, 12),
info->surf_val << 12);
- if (INTEL_GEN(dev_priv) >= 9) {
+ if (GRAPHICS_VER(dev_priv) >= 9) {
set_mask_bits(&vgpu_vreg_t(vgpu, info->stride_reg), GENMASK(9,
0),
info->stride_val);
set_mask_bits(&vgpu_vreg_t(vgpu, info->ctrl_reg), GENMASK(12,
10),
@@ -1446,7 +1446,7 @@ static int decode_mi_display_flip(struct
parser_exec_state *s,
{
if (IS_BROADWELL(s->engine->i915))
return gen8_decode_mi_display_flip(s, info);
- if (INTEL_GEN(s->engine->i915) >= 9)
+ if (GRAPHICS_VER(s->engine->i915) >= 9)
return skl_decode_mi_display_flip(s, info);
return -ENODEV;
diff --git a/drivers/gpu/drm/i915/gvt/dmabuf.c
b/drivers/gpu/drm/i915/gvt/dmabuf.c
index d4f883f35b95..8e65cd8258b9 100644
--- a/drivers/gpu/drm/i915/gvt/dmabuf.c
+++ b/drivers/gpu/drm/i915/gvt/dmabuf.c
@@ -223,7 +223,7 @@ static struct drm_i915_gem_object *vgpu_create_gem(struct
drm_device *dev,
obj->read_domains = I915_GEM_DOMAIN_GTT;
obj->write_domain = 0;
- if (INTEL_GEN(dev_priv) >= 9) {
+ if (GRAPHICS_VER(dev_priv) >= 9) {
unsigned int tiling_mode = 0;
unsigned int stride = 0;
diff --git a/drivers/gpu/drm/i915/gvt/fb_decoder.c
b/drivers/gpu/drm/i915/gvt/fb_decoder.c
index 0889ad8291b0..11a8baba6822 100644
--- a/drivers/gpu/drm/i915/gvt/fb_decoder.c
+++ b/drivers/gpu/drm/i915/gvt/fb_decoder.c
@@ -151,7 +151,7 @@ static u32 intel_vgpu_get_stride(struct intel_vgpu *vgpu,
int pipe,
u32 stride_reg = vgpu_vreg_t(vgpu, DSPSTRIDE(pipe)) & stride_mask;
u32 stride = stride_reg;
- if (INTEL_GEN(dev_priv) >= 9) {
+ if (GRAPHICS_VER(dev_priv) >= 9) {
switch (tiled) {
case PLANE_CTL_TILED_LINEAR:
stride = stride_reg * 64;
@@ -215,7 +215,7 @@ int intel_vgpu_decode_primary_plane(struct intel_vgpu *vgpu,
if (!plane->enabled)
return -ENODEV;
- if (INTEL_GEN(dev_priv) >
[PATCH v3 7/7] drm/i915/display: replace IS_GEN() in commented code
Since we are replacing IS_GEN() with GRAPHICS_VER(), make sure we take
care of the comments as well.
Signed-off-by: Lucas De Marchi
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/display/intel_tv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_tv.c
b/drivers/gpu/drm/i915/display/intel_tv.c
index ce73ebdfc669..aa52af7891f0 100644
--- a/drivers/gpu/drm/i915/display/intel_tv.c
+++ b/drivers/gpu/drm/i915/display/intel_tv.c
@@ -1307,7 +1307,7 @@ intel_tv_compute_config(struct intel_encoder *encoder,
* the active portion. Hence following this formula seems
* more trouble that it's worth.
*
-* if (IS_GEN(dev_priv, 4)) {
+* if (GRAPHICS_VER(dev_priv) == 4) {
* num = cdclk * (tv_mode->oversample >> !tv_mode->progressive);
* den = tv_mode->clock;
* } else {
--
2.31.1
[PATCH v3 6/7] drm/i915: Add remaining conversions to GRAPHICS_VER
For some reason coccinelle misses a few cases in header files with calls to INTEL_GEN()/IS_GEN(). Do a manual conversion for those. Signed-off-by: Lucas De Marchi Reviewed-by: Matt Roper --- drivers/gpu/drm/i915/i915_drv.h | 37 - drivers/gpu/drm/i915/i915_reg.h | 26 +++ 2 files changed, 31 insertions(+), 32 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 91fda14f8f6c..38ff2fb89744 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -1552,9 +1552,9 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915, (IS_ALDERLAKE_P(__i915) && \ IS_GT_STEP(__i915, since, until)) -#define IS_LP(dev_priv)(INTEL_INFO(dev_priv)->is_lp) -#define IS_GEN9_LP(dev_priv) (IS_GEN(dev_priv, 9) && IS_LP(dev_priv)) -#define IS_GEN9_BC(dev_priv) (IS_GEN(dev_priv, 9) && !IS_LP(dev_priv)) +#define IS_LP(dev_priv)(INTEL_INFO(dev_priv)->is_lp) +#define IS_GEN9_LP(dev_priv) (GRAPHICS_VER(dev_priv) == 9 && IS_LP(dev_priv)) +#define IS_GEN9_BC(dev_priv) (GRAPHICS_VER(dev_priv) == 9 && !IS_LP(dev_priv)) #define __HAS_ENGINE(engine_mask, id) ((engine_mask) & BIT(id)) #define HAS_ENGINE(gt, id) __HAS_ENGINE((gt)->info.engine_mask, id) @@ -1574,12 +1574,12 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915, * The Gen7 cmdparser copies the scanned buffer to the ggtt for execution * All later gens can run the final buffer from the ppgtt */ -#define CMDPARSER_USES_GGTT(dev_priv) IS_GEN(dev_priv, 7) +#define CMDPARSER_USES_GGTT(dev_priv) (GRAPHICS_VER(dev_priv) == 7) #define HAS_LLC(dev_priv) (INTEL_INFO(dev_priv)->has_llc) #define HAS_SNOOP(dev_priv)(INTEL_INFO(dev_priv)->has_snoop) #define HAS_EDRAM(dev_priv)((dev_priv)->edram_size_mb) -#define HAS_SECURE_BATCHES(dev_priv) (INTEL_GEN(dev_priv) < 6) +#define HAS_SECURE_BATCHES(dev_priv) (GRAPHICS_VER(dev_priv) < 6) #define HAS_WT(dev_priv) HAS_EDRAM(dev_priv) #define HWS_NEEDS_PHYSICAL(dev_priv) (INTEL_INFO(dev_priv)->hws_needs_physical) @@ -1612,7 +1612,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915, #define HAS_BROKEN_CS_TLB(dev_priv)(IS_I830(dev_priv) || IS_I845G(dev_priv)) #define NEEDS_RC6_CTX_CORRUPTION_WA(dev_priv) \ - (IS_BROADWELL(dev_priv) || IS_GEN(dev_priv, 9)) + (IS_BROADWELL(dev_priv) || GRAPHICS_VER(dev_priv) == 9) /* WaRsDisableCoarsePowerGating:skl,cnl */ #define NEEDS_WaRsDisableCoarsePowerGating(dev_priv) \ @@ -1620,23 +1620,22 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915, IS_SKL_GT3(dev_priv) ||\ IS_SKL_GT4(dev_priv)) -#define HAS_GMBUS_IRQ(dev_priv) (INTEL_GEN(dev_priv) >= 4) -#define HAS_GMBUS_BURST_READ(dev_priv) (INTEL_GEN(dev_priv) >= 10 || \ +#define HAS_GMBUS_IRQ(dev_priv) (GRAPHICS_VER(dev_priv) >= 4) +#define HAS_GMBUS_BURST_READ(dev_priv) (GRAPHICS_VER(dev_priv) >= 10 || \ IS_GEMINILAKE(dev_priv) || \ IS_KABYLAKE(dev_priv)) /* With the 945 and later, Y tiling got adjusted so that it was 32 128-byte * rows, which changed the alignment requirements and fence programming. */ -#define HAS_128_BYTE_Y_TILING(dev_priv) (!IS_GEN(dev_priv, 2) && \ -!(IS_I915G(dev_priv) || \ -IS_I915GM(dev_priv))) +#define HAS_128_BYTE_Y_TILING(dev_priv) (GRAPHICS_VER(dev_priv) != 2 && \ +!(IS_I915G(dev_priv) || IS_I915GM(dev_priv))) #define SUPPORTS_TV(dev_priv) (INTEL_INFO(dev_priv)->display.supports_tv) #define I915_HAS_HOTPLUG(dev_priv) (INTEL_INFO(dev_priv)->display.has_hotplug) -#define HAS_FW_BLC(dev_priv) (INTEL_GEN(dev_priv) > 2) +#define HAS_FW_BLC(dev_priv) (GRAPHICS_VER(dev_priv) > 2) #define HAS_FBC(dev_priv) (INTEL_INFO(dev_priv)->display.has_fbc) -#define HAS_CUR_FBC(dev_priv) (!HAS_GMCH(dev_priv) && INTEL_GEN(dev_priv) >= 7) +#define HAS_CUR_FBC(dev_priv) (!HAS_GMCH(dev_priv) && GRAPHICS_VER(dev_priv) >= 7) #define HAS_IPS(dev_priv) (IS_HSW_ULT(dev_priv) || IS_BROADWELL(dev_priv)) @@ -1647,7 +1646,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915, #define HAS_PSR(dev_priv) (INTEL_INFO(dev_priv)->display.has_psr) #define HAS_PSR_HW_TRACKING(dev_priv) \ (INTEL_INFO(dev_priv)->display.has_psr_hw_tracking) -#define HAS_PSR2_SEL_FETCH(dev_priv)(INTEL_GEN(dev_priv) >= 12) +#define HAS_PSR2_SEL_FETCH(dev_priv)(GRAPHICS_VER(dev_priv) >= 12) #define HAS_TRANSCODER(dev_priv, trans) ((INTEL_INFO(dev_priv)->cpu_transcoder_mask & BIT(trans)) != 0) #define HAS_RC6(dev_priv) (INTEL_INFO(dev_priv)->has_rc6) @@ -1658,7 +1657,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915, #define HAS_DMC(dev_priv) (INTEL_INFO(dev_priv
[PATCH v3 0/7] drm/i915: Finish conversion to GRAPHICS_VER
v3 is a resend from v2 (https://patchwork.freedesktop.org/series/90693/) now with dri-devel Cc'ed. Notice that this patch series can be applied splitting it up through the trees, it's not necessary to apply them together. The intention is to apply first 3 patches on drm-intel-gt-next and the remaining on drm-intel-next. I'm intentionally _not_ removing the INTEL_GEN/IS_GEN/IS_GEN_RANGE macros now. A few days/weeks after this is applied and when drm-intel-gt-next and drm-intel-next is back in sync, we can remove any leftovers that went in and remove the macros via a topic branch. Latest version of previous series "drm/i915: Extend GEN renames to the rest of the driver" (https://patchwork.freedesktop.org/series/88825/) dropped one patch converting all the instances of IS_GEN() and INTEL_GEN() to GRAPHICS_VER() due to the patches changing the meaning of the macros IS_GRAPHICS_VER/GRAPHICS_VER and removal of IS_GRAPHICS_RANGE(). I couldn't find a way to convince coccinelle to fix all places, so I just did it manually in separate commits the places that were not updated. Finish the conversion splitting the changes so it can go to the different branches (drm-intel-gt-next and drm-intel-next). I also split the gvt changes, but I think it would be easier to take this directly on drm-intel-next. v2: update commit messages with the proper semantic patch (Matt Roper) and regenerate the patches to also convert changes that got added in between. v3: resend with dri-devel Cc'ed since we are touching gt/gem/core. Also, let's get an ack on merge strategy Cc: intel-gvt-...@lists.freedesktop.org Cc: Zhenyu Wang Lucas De Marchi (7): drm/i915/gt: replace IS_GEN and friends with GRAPHICS_VER drm/i915/gt: Add remaining conversions to GRAPHICS_VER drm/i915/gem: replace IS_GEN and friends with GRAPHICS_VER drm/i915/gvt: replace IS_GEN and friends with GRAPHICS_VER drm/i915: replace IS_GEN and friends with GRAPHICS_VER drm/i915: Add remaining conversions to GRAPHICS_VER drm/i915/display: replace IS_GEN() in commented code drivers/gpu/drm/i915/display/intel_tv.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_context.c | 6 +- .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 10 +-- drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +- .../gpu/drm/i915/gem/i915_gem_object_blt.c| 8 +- drivers/gpu/drm/i915/gem/i915_gem_stolen.c| 16 ++-- drivers/gpu/drm/i915/gem/i915_gem_tiling.c| 12 +-- .../i915/gem/selftests/i915_gem_client_blt.c | 10 +-- .../i915/gem/selftests/i915_gem_coherency.c | 4 +- .../drm/i915/gem/selftests/i915_gem_context.c | 16 ++-- .../drm/i915/gem/selftests/i915_gem_mman.c| 14 ++-- .../drm/i915/gem/selftests/igt_gem_utils.c| 10 +-- drivers/gpu/drm/i915/gt/debugfs_gt_pm.c | 40 +- drivers/gpu/drm/i915/gt/gen2_engine_cs.c | 2 +- drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 2 +- drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 2 +- drivers/gpu/drm/i915/gt/intel_context_sseu.c | 2 +- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 54 ++--- drivers/gpu/drm/i915/gt/intel_engine_types.h | 4 +- .../drm/i915/gt/intel_execlists_submission.c | 18 ++--- drivers/gpu/drm/i915/gt/intel_ggtt.c | 18 ++--- drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 34 drivers/gpu/drm/i915/gt/intel_gt.c| 27 --- .../gpu/drm/i915/gt/intel_gt_clock_utils.c| 12 +-- drivers/gpu/drm/i915/gt/intel_gt_irq.c| 6 +- drivers/gpu/drm/i915/gt/intel_gt_pm_irq.c | 10 +-- drivers/gpu/drm/i915/gt/intel_gtt.c | 14 ++-- drivers/gpu/drm/i915/gt/intel_llc.c | 6 +- drivers/gpu/drm/i915/gt/intel_lrc.c | 46 +-- drivers/gpu/drm/i915/gt/intel_mocs.c | 8 +- drivers/gpu/drm/i915/gt/intel_ppgtt.c | 6 +- drivers/gpu/drm/i915/gt/intel_rc6.c | 16 ++-- drivers/gpu/drm/i915/gt/intel_renderstate.c | 2 +- drivers/gpu/drm/i915/gt/intel_reset.c | 14 ++-- .../gpu/drm/i915/gt/intel_ring_submission.c | 64 +++ drivers/gpu/drm/i915/gt/intel_rps.c | 60 +++--- drivers/gpu/drm/i915/gt/intel_sseu.c | 14 ++-- drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c | 6 +- drivers/gpu/drm/i915/gt/intel_workarounds.c | 66 +++ drivers/gpu/drm/i915/gt/selftest_engine_cs.c | 6 +- drivers/gpu/drm/i915/gt/selftest_engine_pm.c | 2 +- drivers/gpu/drm/i915/gt/selftest_execlists.c | 4 +- drivers/gpu/drm/i915/gt/selftest_gt_pm.c | 8 +- drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 8 +- drivers/gpu/drm/i915/gt/selftest_llc.c| 4 +- drivers/gpu/drm/i915/gt/selftest_lrc.c| 8 +- drivers/gpu/drm/i915/gt/selftest_mocs.c | 2 +- drivers/gpu/drm/i915/gt/selftest_rc6.c| 4 +- .../drm/i915/gt/selftest_ring_submission.c| 6 +- drivers/gpu/drm/i915/gt/selftest_rps.c| 16 ++-- drivers/gpu/drm/i915/gt/selftest_timeline.c | 6 +- .../gpu/drm/i915/gt/selftest_wo
[PATCH v3 5/7] drm/i915: replace IS_GEN and friends with GRAPHICS_VER
This was done by the following semantic patch:
@@ expression i915; @@
- INTEL_GEN(i915)
+ GRAPHICS_VER(i915)
@@ expression i915; expression E; @@
- INTEL_GEN(i915) >= E
+ GRAPHICS_VER(i915) >= E
@@ expression dev_priv; expression E; @@
- !IS_GEN(dev_priv, E)
+ GRAPHICS_VER(dev_priv) != E
@@ expression dev_priv; expression E; @@
- IS_GEN(dev_priv, E)
+ GRAPHICS_VER(dev_priv) == E
@@
expression dev_priv;
expression from, until;
@@
- IS_GEN_RANGE(dev_priv, from, until)
+ IS_GRAPHICS_VER(dev_priv, from, until)
@def@
expression E;
identifier id =~ "^gen$";
@@
- id = GRAPHICS_VER(E)
+ ver = GRAPHICS_VER(E)
@@
identifier def.id;
@@
- id
+ ver
It also takes care of renaming the variable we assign to GRAPHICS_VER()
so to use "ver" rather than "gen".
Signed-off-by: Lucas De Marchi
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/i915_cmd_parser.c| 10 +--
drivers/gpu/drm/i915/i915_debugfs.c | 32
drivers/gpu/drm/i915/i915_drv.c | 20 ++---
drivers/gpu/drm/i915/i915_gem.c | 4 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 80 +--
drivers/gpu/drm/i915/i915_irq.c | 34
drivers/gpu/drm/i915/i915_perf.c | 44 +-
drivers/gpu/drm/i915/i915_pmu.c | 8 +-
drivers/gpu/drm/i915/i915_request.c | 4 +-
drivers/gpu/drm/i915/i915_suspend.c | 16 ++--
drivers/gpu/drm/i915/i915_sysfs.c | 2 +-
drivers/gpu/drm/i915/i915_vgpu.c | 2 +-
drivers/gpu/drm/i915/intel_device_info.c | 22 ++---
drivers/gpu/drm/i915/intel_dram.c | 14 ++--
drivers/gpu/drm/i915/intel_pch.c | 10 +--
drivers/gpu/drm/i915/intel_pm.c | 14 ++--
drivers/gpu/drm/i915/intel_sideband.c | 2 +-
drivers/gpu/drm/i915/intel_uncore.c | 26 +++---
drivers/gpu/drm/i915/intel_wopcm.c| 10 +--
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 4 +-
drivers/gpu/drm/i915/selftests/i915_perf.c| 6 +-
drivers/gpu/drm/i915/selftests/i915_request.c | 8 +-
drivers/gpu/drm/i915/selftests/igt_spinner.c | 12 +--
drivers/gpu/drm/i915/selftests/intel_uncore.c | 2 +-
24 files changed, 193 insertions(+), 193 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index 5b4b2bd46e7c..3992c25a191d 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -946,8 +946,8 @@ int intel_engine_init_cmd_parser(struct intel_engine_cs
*engine)
int cmd_table_count;
int ret;
- if (!IS_GEN(engine->i915, 7) && !(IS_GEN(engine->i915, 9) &&
- engine->class == COPY_ENGINE_CLASS))
+ if (GRAPHICS_VER(engine->i915) != 7 && !(GRAPHICS_VER(engine->i915) ==
9 &&
+engine->class ==
COPY_ENGINE_CLASS))
return 0;
switch (engine->class) {
@@ -977,7 +977,7 @@ int intel_engine_init_cmd_parser(struct intel_engine_cs
*engine)
break;
case COPY_ENGINE_CLASS:
engine->get_cmd_length_mask = gen7_blt_get_cmd_length_mask;
- if (IS_GEN(engine->i915, 9)) {
+ if (GRAPHICS_VER(engine->i915) == 9) {
cmd_tables = gen9_blt_cmd_table;
cmd_table_count = ARRAY_SIZE(gen9_blt_cmd_table);
engine->get_cmd_length_mask =
@@ -993,7 +993,7 @@ int intel_engine_init_cmd_parser(struct intel_engine_cs
*engine)
cmd_table_count = ARRAY_SIZE(gen7_blt_cmd_table);
}
- if (IS_GEN(engine->i915, 9)) {
+ if (GRAPHICS_VER(engine->i915) == 9) {
engine->reg_tables = gen9_blt_reg_tables;
engine->reg_table_count =
ARRAY_SIZE(gen9_blt_reg_tables);
@@ -1537,7 +1537,7 @@ int intel_engine_cmd_parser(struct intel_engine_cs
*engine,
if (IS_HASWELL(engine->i915))
flags = MI_BATCH_NON_SECURE_HSW;
- GEM_BUG_ON(!IS_GEN_RANGE(engine->i915, 6, 7));
+ GEM_BUG_ON(!IS_GRAPHICS_VER(engine->i915, 6,
7));
__gen6_emit_bb_start(batch_end,
batch_addr,
flags);
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index a4d8a836bd57..0529576f069c 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -361,7 +361,7 @@ sta
[PATCH v3 3/7] drm/i915/gem: replace IS_GEN and friends with GRAPHICS_VER
This was done by the following semantic patch:
@@ expression i915; @@
- INTEL_GEN(i915)
+ GRAPHICS_VER(i915)
@@ expression i915; expression E; @@
- INTEL_GEN(i915) >= E
+ GRAPHICS_VER(i915) >= E
@@ expression dev_priv; expression E; @@
- !IS_GEN(dev_priv, E)
+ GRAPHICS_VER(dev_priv) != E
@@ expression dev_priv; expression E; @@
- IS_GEN(dev_priv, E)
+ GRAPHICS_VER(dev_priv) == E
@@
expression dev_priv;
expression from, until;
@@
- IS_GEN_RANGE(dev_priv, from, until)
+ IS_GRAPHICS_VER(dev_priv, from, until)
@def@
expression E;
identifier id =~ "^gen$";
@@
- id = GRAPHICS_VER(E)
+ ver = GRAPHICS_VER(E)
@@
identifier def.id;
@@
- id
+ ver
It also takes care of renaming the variable we assign to GRAPHICS_VER()
so to use "ver" rather than "gen".
Signed-off-by: Lucas De Marchi
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 6 +++---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 10 +-
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_object_blt.c | 8
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 16
drivers/gpu/drm/i915/gem/i915_gem_tiling.c | 12 ++--
.../drm/i915/gem/selftests/i915_gem_client_blt.c | 10 +-
.../drm/i915/gem/selftests/i915_gem_coherency.c | 4 ++--
.../drm/i915/gem/selftests/i915_gem_context.c| 16
.../gpu/drm/i915/gem/selftests/i915_gem_mman.c | 14 +++---
.../gpu/drm/i915/gem/selftests/igt_gem_utils.c | 10 +-
11 files changed, 54 insertions(+), 54 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 188dee13e017..7720b8c22c81 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1190,7 +1190,7 @@ static void set_ppgtt_barrier(void *data)
{
struct i915_address_space *old = data;
- if (INTEL_GEN(old->i915) < 8)
+ if (GRAPHICS_VER(old->i915) < 8)
gen6_ppgtt_unpin_all(i915_vm_to_ppgtt(old));
i915_vm_close(old);
@@ -1436,7 +1436,7 @@ i915_gem_user_to_context_sseu(struct intel_gt *gt,
context->max_eus_per_subslice = user->max_eus_per_subslice;
/* Part specific restrictions. */
- if (IS_GEN(i915, 11)) {
+ if (GRAPHICS_VER(i915) == 11) {
unsigned int hw_s = hweight8(device->slice_mask);
unsigned int hw_ss_per_s = hweight8(device->subslice_mask[0]);
unsigned int req_s = hweight8(context->slice_mask);
@@ -1503,7 +1503,7 @@ static int set_sseu(struct i915_gem_context *ctx,
if (args->size < sizeof(user_sseu))
return -EINVAL;
- if (!IS_GEN(i915, 11))
+ if (GRAPHICS_VER(i915) != 11)
return -ENODEV;
if (copy_from_user(&user_sseu, u64_to_user_ptr(args->value),
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 297143511f99..24c0582e46fb 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -500,7 +500,7 @@ eb_validate_vma(struct i915_execbuffer *eb,
* also covers all platforms with local memory.
*/
if (entry->relocation_count &&
- INTEL_GEN(eb->i915) >= 12 && !IS_TIGERLAKE(eb->i915))
+ GRAPHICS_VER(eb->i915) >= 12 && !IS_TIGERLAKE(eb->i915))
return -EINVAL;
if (unlikely(entry->flags & eb->invalid_flags))
@@ -1439,7 +1439,7 @@ static int __reloc_gpu_alloc(struct i915_execbuffer *eb,
static bool reloc_can_use_engine(const struct intel_engine_cs *engine)
{
- return engine->class != VIDEO_DECODE_CLASS || !IS_GEN(engine->i915, 6);
+ return engine->class != VIDEO_DECODE_CLASS ||
GRAPHICS_VER(engine->i915) != 6;
}
static u32 *reloc_gpu(struct i915_execbuffer *eb,
@@ -1671,7 +1671,7 @@ eb_relocate_entry(struct i915_execbuffer *eb,
* batchbuffers.
*/
if (reloc->write_domain == I915_GEM_DOMAIN_INSTRUCTION &&
- IS_GEN(eb->i915, 6)) {
+ GRAPHICS_VER(eb->i915) == 6) {
err = i915_vma_bind(target->vma,
target->vma->obj->cache_level,
PIN_GLOBAL, NULL);
@@ -2332,7 +2332,7 @@ static int i915_reset_gen7_sol_offsets(struct
i915_request *rq)
u32 *cs;
int i;
- if (!IS_GEN(rq->engine->i915, 7) || rq->engine->id != RCS0) {
+ if (GRAPHICS_VER(rq->engine->i915) != 7 || rq->engine->id != RCS0) {
drm_dbg(&rq->engine->i915->drm, "sol reset is
[PATCH v3 2/7] drm/i915/gt: Add remaining conversions to GRAPHICS_VER
For some reason coccinelle misses a few cases in gt with calls to
INTEL_GEN()/IS_GEN(). Do a manual conversion for those.
Signed-off-by: Lucas De Marchi
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/gt/debugfs_gt_pm.c | 2 +-
drivers/gpu/drm/i915/gt/intel_engine_types.h | 4 ++--
drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c | 6 +++---
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/debugfs_gt_pm.c
b/drivers/gpu/drm/i915/gt/debugfs_gt_pm.c
index 0389bceebd06..4270b5a34a83 100644
--- a/drivers/gpu/drm/i915/gt/debugfs_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/debugfs_gt_pm.c
@@ -230,7 +230,7 @@ static int drpc_show(struct seq_file *m, void *unused)
with_intel_runtime_pm(gt->uncore->rpm, wakeref) {
if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915))
err = vlv_drpc(m);
- else if (INTEL_GEN(i915) >= 6)
+ else if (GRAPHICS_VER(i915) >= 6)
err = gen6_drpc(m);
else
err = ilk_drpc(m);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 9ef349cd5cea..e113f93b3274 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -606,10 +606,10 @@ intel_engine_has_relative_mmio(const struct
intel_engine_cs * const engine)
}
#define instdone_has_slice(dev_priv___, sseu___, slice___) \
- ((IS_GEN(dev_priv___, 7) ? 1 : ((sseu___)->slice_mask)) & BIT(slice___))
+ ((GRAPHICS_VER(dev_priv___) == 7 ? 1 : ((sseu___)->slice_mask)) &
BIT(slice___))
#define instdone_has_subslice(dev_priv__, sseu__, slice__, subslice__) \
- (IS_GEN(dev_priv__, 7) ? (1 & BIT(subslice__)) : \
+ (GRAPHICS_VER(dev_priv__) == 7 ? (1 & BIT(subslice__)) : \
intel_sseu_has_subslice(sseu__, 0, subslice__))
#define for_each_instdone_slice_subslice(dev_priv_, sseu_, slice_, subslice_) \
diff --git a/drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c
b/drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c
index 51780282d872..714fe8495775 100644
--- a/drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c
+++ b/drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c
@@ -248,7 +248,7 @@ int intel_sseu_status(struct seq_file *m, struct intel_gt
*gt)
struct sseu_dev_info sseu;
intel_wakeref_t wakeref;
- if (INTEL_GEN(i915) < 8)
+ if (GRAPHICS_VER(i915) < 8)
return -ENODEV;
seq_puts(m, "SSEU Device Info\n");
@@ -265,9 +265,9 @@ int intel_sseu_status(struct seq_file *m, struct intel_gt
*gt)
cherryview_sseu_device_status(gt, &sseu);
else if (IS_BROADWELL(i915))
bdw_sseu_device_status(gt, &sseu);
- else if (IS_GEN(i915, 9))
+ else if (GRAPHICS_VER(i915) == 9)
gen9_sseu_device_status(gt, &sseu);
- else if (INTEL_GEN(i915) >= 10)
+ else if (GRAPHICS_VER(i915) >= 10)
gen10_sseu_device_status(gt, &sseu);
}
--
2.31.1
[PATCH v3 4/4] drm/vgem: use shmem helpers
Aside from deleting lots of code the real motivation here is to switch
the mmap over to VM_PFNMAP, to be more consistent with what real gpu
drivers do. They're all VM_PFNMP, which means get_user_pages doesn't
work, and even if you try and there's a struct page behind that,
touching it and mucking around with its refcount can upset drivers
real bad.
v2: Review from Thomas:
- sort #include
- drop more dead code that I didn't spot somehow
v3: select DRM_GEM_SHMEM_HELPER to make it build (intel-gfx-ci)
v4: I got tricked by 0cf2ef46c6c0 ("drm/shmem-helper: Use cached
mappings by default"), and we need WC in vgem because vgem doesn't
have explicit begin/end cpu access ioctls.
Also add a comment why exactly vgem has to use wc.
v5: Don't set obj->base.funcs, it will default to drm_gem_shmem_funcs
(Thomas)
Cc: Thomas Zimmermann
Acked-by: Thomas Zimmermann
Cc: John Stultz
Cc: Sumit Semwal
Cc: "Christian König"
Signed-off-by: Daniel Vetter
Cc: Melissa Wen
Cc: Chris Wilson
---
drivers/gpu/drm/Kconfig | 1 +
drivers/gpu/drm/vgem/vgem_drv.c | 342 ++--
2 files changed, 14 insertions(+), 329 deletions(-)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 9c21527b791f..fb38ef7b3206 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -268,6 +268,7 @@ source "drivers/gpu/drm/kmb/Kconfig"
config DRM_VGEM
tristate "Virtual GEM provider"
depends on DRM
+ select DRM_GEM_SHMEM_HELPER
help
Choose this option to get a virtual graphics memory manager,
as used by Mesa's software renderer for enhanced performance.
diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index bf38a7e319d1..a87eafa89e9f 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -38,6 +38,7 @@
#include
#include
+#include
#include
#include
#include
@@ -50,87 +51,11 @@
#define DRIVER_MAJOR 1
#define DRIVER_MINOR 0
-static const struct drm_gem_object_funcs vgem_gem_object_funcs;
-
static struct vgem_device {
struct drm_device drm;
struct platform_device *platform;
} *vgem_device;
-static void vgem_gem_free_object(struct drm_gem_object *obj)
-{
- struct drm_vgem_gem_object *vgem_obj = to_vgem_bo(obj);
-
- kvfree(vgem_obj->pages);
- mutex_destroy(&vgem_obj->pages_lock);
-
- if (obj->import_attach)
- drm_prime_gem_destroy(obj, vgem_obj->table);
-
- drm_gem_object_release(obj);
- kfree(vgem_obj);
-}
-
-static vm_fault_t vgem_gem_fault(struct vm_fault *vmf)
-{
- struct vm_area_struct *vma = vmf->vma;
- struct drm_vgem_gem_object *obj = vma->vm_private_data;
- /* We don't use vmf->pgoff since that has the fake offset */
- unsigned long vaddr = vmf->address;
- vm_fault_t ret = VM_FAULT_SIGBUS;
- loff_t num_pages;
- pgoff_t page_offset;
- page_offset = (vaddr - vma->vm_start) >> PAGE_SHIFT;
-
- num_pages = DIV_ROUND_UP(obj->base.size, PAGE_SIZE);
-
- if (page_offset >= num_pages)
- return VM_FAULT_SIGBUS;
-
- mutex_lock(&obj->pages_lock);
- if (obj->pages) {
- get_page(obj->pages[page_offset]);
- vmf->page = obj->pages[page_offset];
- ret = 0;
- }
- mutex_unlock(&obj->pages_lock);
- if (ret) {
- struct page *page;
-
- page = shmem_read_mapping_page(
- file_inode(obj->base.filp)->i_mapping,
- page_offset);
- if (!IS_ERR(page)) {
- vmf->page = page;
- ret = 0;
- } else switch (PTR_ERR(page)) {
- case -ENOSPC:
- case -ENOMEM:
- ret = VM_FAULT_OOM;
- break;
- case -EBUSY:
- ret = VM_FAULT_RETRY;
- break;
- case -EFAULT:
- case -EINVAL:
- ret = VM_FAULT_SIGBUS;
- break;
- default:
- WARN_ON(PTR_ERR(page));
- ret = VM_FAULT_SIGBUS;
- break;
- }
-
- }
- return ret;
-}
-
-static const struct vm_operations_struct vgem_gem_vm_ops = {
- .fault = vgem_gem_fault,
- .open = drm_gem_vm_open,
- .close = drm_gem_vm_close,
-};
-
static int vgem_open(struct drm_device *dev, struct drm_file *file)
{
struct vgem_file *vfile;
@@ -159,266 +84,30 @@ static void vgem_postclose(struct drm_device *dev, struct
drm_file *file)
kfree(vfile);
}
-static struct drm_vgem_gem_object *__vgem_gem_create(struct drm_device *dev,
-
[PATCH v3 3/4] drm/shmem-helper: Align to page size in dumb_create
shmem helpers seem a bit sloppy here by automatically rounding up when
actually creating the buffer, which results in under-reporting of what
we actually have. Caught by igt/vgem_basic tests.
Acked-by: Thomas Zimmermann
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index 11edd54f0580..296ab1b7c07f 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -505,13 +505,13 @@ int drm_gem_shmem_dumb_create(struct drm_file *file,
struct drm_device *dev,
if (!args->pitch || !args->size) {
args->pitch = min_pitch;
- args->size = args->pitch * args->height;
+ args->size = PAGE_ALIGN(args->pitch * args->height);
} else {
/* ensure sane minimum values */
if (args->pitch < min_pitch)
args->pitch = min_pitch;
if (args->size < args->pitch * args->height)
- args->size = args->pitch * args->height;
+ args->size = PAGE_ALIGN(args->pitch * args->height);
}
shmem = drm_gem_shmem_create_with_handle(file, dev, args->size,
&args->handle);
--
2.31.0
[PATCH v3 1/4] dma-buf: Require VM_PFNMAP vma for mmap
tldr; DMA buffers aren't normal memory, expecting that you can use
them like that (like calling get_user_pages works, or that they're
accounting like any other normal memory) cannot be guaranteed.
Since some userspace only runs on integrated devices, where all
buffers are actually all resident system memory, there's a huge
temptation to assume that a struct page is always present and useable
like for any more pagecache backed mmap. This has the potential to
result in a uapi nightmare.
To stop this gap require that DMA buffer mmaps are VM_PFNMAP, which
blocks get_user_pages and all the other struct page based
infrastructure for everyone. In spirit this is the uapi counterpart to
the kernel-internal CONFIG_DMABUF_DEBUG.
Motivated by a recent patch which wanted to swich the system dma-buf
heap to vm_insert_page instead of vm_insert_pfn.
v2:
Jason brought up that we also want to guarantee that all ptes have the
pte_special flag set, to catch fast get_user_pages (on architectures
that support this). Allowing VM_MIXEDMAP (like VM_SPECIAL does) would
still allow vm_insert_page, but limiting to VM_PFNMAP will catch that.
>From auditing the various functions to insert pfn pte entires
(vm_insert_pfn_prot, remap_pfn_range and all it's callers like
dma_mmap_wc) it looks like VM_PFNMAP is already required anyway, so
this should be the correct flag to check for.
References:
https://lore.kernel.org/lkml/cakmk7uhi+mg0z0humnt13qccvuturvjpcr0njrl12k-wbwz...@mail.gmail.com/
Acked-by: Christian König
Cc: Jason Gunthorpe
Cc: Suren Baghdasaryan
Cc: Matthew Wilcox
Cc: John Stultz
Signed-off-by: Daniel Vetter
Cc: Sumit Semwal
Cc: "Christian König"
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
--
Resending this so I can test the next two patches for vgem/shmem in
intel-gfx-ci. Last round failed somehow, but I can't repro that at all
locally here.
No immediate plans to merge this patch here since ttm isn't addressed
yet (and there we have the hugepte issue, for which I don't think we
have a clear consensus yet).
-Daniel
---
drivers/dma-buf/dma-buf.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index eadd1eaa2fb5..dda583fb1f03 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -127,6 +127,7 @@ static struct file_system_type dma_buf_fs_type = {
static int dma_buf_mmap_internal(struct file *file, struct vm_area_struct *vma)
{
struct dma_buf *dmabuf;
+ int ret;
if (!is_dma_buf_file(file))
return -EINVAL;
@@ -142,7 +143,11 @@ static int dma_buf_mmap_internal(struct file *file, struct
vm_area_struct *vma)
dmabuf->size >> PAGE_SHIFT)
return -EINVAL;
- return dmabuf->ops->mmap(dmabuf, vma);
+ ret = dmabuf->ops->mmap(dmabuf, vma);
+
+ WARN_ON(!(vma->vm_flags & VM_PFNMAP));
+
+ return ret;
}
static loff_t dma_buf_llseek(struct file *file, loff_t offset, int whence)
@@ -1244,6 +1249,8 @@ EXPORT_SYMBOL_GPL(dma_buf_end_cpu_access);
int dma_buf_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma,
unsigned long pgoff)
{
+ int ret;
+
if (WARN_ON(!dmabuf || !vma))
return -EINVAL;
@@ -1264,7 +1271,11 @@ int dma_buf_mmap(struct dma_buf *dmabuf, struct
vm_area_struct *vma,
vma_set_file(vma, dmabuf->file);
vma->vm_pgoff = pgoff;
- return dmabuf->ops->mmap(dmabuf, vma);
+ ret = dmabuf->ops->mmap(dmabuf, vma);
+
+ WARN_ON(!(vma->vm_flags & VM_PFNMAP));
+
+ return ret;
}
EXPORT_SYMBOL_GPL(dma_buf_mmap);
--
2.31.0
