Re: [PATCH v2 4/4] drm/format-helper: Add drm_fb_build_fourcc_list() helper
Hi Sam
Am 16.08.22 um 19:22 schrieb Sam Ravnborg:
Hi Thomas,
On Tue, Aug 16, 2022 at 03:48:53PM +0200, Thomas Zimmermann wrote:
Add drm_fb_build_fourcc_list() function that builds a list of supported
formats from native and emulated ones. Helpful for all drivers that do
format conversion as part of their plane updates. Update current caller.
v2:
* use u32 instead of uint32_t (Sam)
* print a warning if output array is too small (Sam)
* comment fixes (Sam)
Signed-off-by: Thomas Zimmermann
Reviewed-by: Sam Ravnborg
---
drivers/gpu/drm/drm_format_helper.c | 103
drivers/gpu/drm/tiny/simpledrm.c| 47 ++---
include/drm/drm_format_helper.h | 11 ++-
3 files changed, 118 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm/drm_format_helper.c
b/drivers/gpu/drm/drm_format_helper.c
index 56642816fdff..fe1db7dbda3f 100644
--- a/drivers/gpu/drm/drm_format_helper.c
+++ b/drivers/gpu/drm/drm_format_helper.c
@@ -793,3 +793,106 @@ void drm_fb_xrgb_to_mono(struct iosys_map *dst, const
unsigned int *dst_pitc
kfree(src32);
}
EXPORT_SYMBOL(drm_fb_xrgb_to_mono);
+
+static bool is_listed_fourcc(const uint32_t *fourccs, size_t nfourccs,
uint32_t fourcc)
+{
+ const uint32_t *fourccs_end = fourccs + nfourccs;
+
+ while (fourccs < fourccs_end) {
+ if (*fourccs == fourcc)
+ return true;
+ ++fourccs;
+ }
+ return false;
+}
+
+/**
+ * drm_fb_build_fourcc_list - Filters a list of supported color formats against
+ *the device's native formats
+ * @dev: DRM device
+ * @native_fourccs: 4CC codes of natively supported color formats
+ * @native_nfourccs: The number of entries in @native_fourccs
+ * @extra_fourccs: 4CC codes of additionally supported color formats
+ * @extra_nfourccs: The number of entries in @extra_fourccs
+ * @fourccs_out: Returns 4CC codes of supported color formats
+ * @nfourccs_out: The number of available entries in @fourccs_out
+ *
+ * This function create a list of supported color format from natively
+ * supported formats and the emulated formats.
+ * At a minimum, most userspace programs expect at least support for
+ * XRGB on the primary plane. Devices that have to emulate the
+ * format, and possibly others, can use drm_fb_build_fourcc_list() to
+ * create a list of supported color formats. The returned list can
+ * be handed over to drm_universal_plane_init() et al. Native formats
+ * will go before emulated formats. Other heuristics might be applied
+ * to optimize the order. Formats near the beginning of the list are
+ * usually preferred over formats near the end of the list.
+ *
+ * Returns:
+ * The number of color-formats 4CC codes returned in @fourccs_out.
+ */
+size_t drm_fb_build_fourcc_list(struct drm_device *dev,
+ const u32 *native_fourccs, size_t
native_nfourccs,
+ const u32 *extra_fourccs, size_t extra_nfourccs,
+ u32 *fourccs_out, size_t nfourccs_out)
+{
+ u32 *fourccs = fourccs_out;
+ const u32 *fourccs_end = fourccs_out + nfourccs_out;
+ bool found_native = false;
+ size_t nfourccs, i;
+
+ /*
+* The device's native formats go first.
+*/
+
+ nfourccs = min_t(size_t, native_nfourccs, nfourccs_out);
If nfourccs < nfourccs_out then there is not enough room for the
formats. I know this is unlikely, but anyway.. Maybe warn here too?
We need to take all filtering into account before warning. See my
comment below.
I would use min() here, as the types are all compatible, so no need to
cast to size_t.
+
+ for (i = 0; i < nfourccs; ++i) {
+ u32 fourcc = native_fourccs[i];
+
+ drm_dbg_kms(dev, "adding native format %p4cc\n", &fourcc);
+
+ if (!found_native)
+ found_native = is_listed_fourcc(extra_fourccs,
extra_nfourccs, fourcc);
+ *fourccs = fourcc;
+ ++fourccs;
+ }
+
+ /*
+* The plane's atomic_update helper converts the framebuffer's color
format
+* to a native format when copying to device memory.
+*
+* If there is not a single format supported by both, device and
+* driver, the native formats are likely not supported by the conversion
+* helpers. Therefore *only* support the native formats and add a
+* conversion helper ASAP.
+*/
+ if (!found_native) {
+ drm_warn(dev, "Format conversion helpers required to add extra
formats.\n");
+ goto out;
+ }
+
+ /*
+* The extra formats, emulated by the driver, go second.
+*/
+
+ nfourccs = min_t(size_t, extra_nfourccs, fourccs_end - fourccs);
fourccs_end is a pointer which is subtracted with fourccs * sizeof(fourccs_end)
So the result is a pointer. I do not
Re: drm warning with mainline due to 467e30171b5b ("drm/vc4: hdmi: Move HDMI reset to pm_resume")
Hi,
On Tue, Aug 16, 2022 at 05:34:51PM +0100, Sudip Mukherjee (Codethink) wrote:
> Not sure if it has been reported but the mainline kernel shows a drm warning
> on RPI4B.
>
> [ 14.821276] WARNING: CPU: 3 PID: 187 at
> drivers/gpu/drm/vc4/vc4_hdmi_regs.h:487 vc5_hdmi_reset+0x1f8/0x240 [vc4]
> [ 14.837288] Modules linked in: hci_uart btqca btrtl btbcm btintel
> btsdio(+) bluetooth bcm2835_v4l2(C) bcm2835_mmal_vchiq(C) videobuf2_vmalloc
> videobuf2_memops videobuf2_v4l2 videobuf2_common brcmfmac videodev brcmutil
> vc4(+) ecdh_generic ecc drm_display_helper mc raspberrypi_hwmon cec
> crct10dif_ce drm_cma_helper cfg80211 dwc2 udc_core i2c_brcmstb roles
> snd_bcm2835(C) drm_kms_helper pwm_bcm2835 drm xhci_pci xhci_pci_renesas
> snd_soc_core phy_generic ac97_bus snd_pcm_dmaengine snd_pcm snd_timer snd
> fb_sys_fops syscopyarea sysfillrect sysimgblt uio_pdrv_genirq uio aes_neon_bs
> aes_neon_blk
> [ 14.889917] CPU: 3 PID: 187 Comm: systemd-udevd Tainted: G C
> 6.0.0-rc1-568035b01cfb #1
> [ 14.899355] Hardware name: Raspberry Pi 4 Model B (DT)
> [ 14.904561] pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> [ 14.911620] pc : vc5_hdmi_reset+0x1f8/0x240 [vc4]
> [ 14.916433] lr : vc5_hdmi_reset+0x38/0x240 [vc4]
> [ 14.921151] sp : 8a85b640
> [ 14.923079] uart-pl011 fe201000.serial: no DMA platform data
> [ 14.924504] x29: 8a85b640 x28: x27:
> 56626080
> [ 14.937472] x26: 8128e2d8 x25: 8128e988 x24:
>
> [ 14.944708] x23: 40a58000 x22: fb832978 x21:
> 56626c90
> [ 14.951944] x20: x19: 56626080 x18:
> 0014
> [ 14.959180] x17: e6b317d8 x16: c03e2fab x15:
> 002ffc4a
> [ 14.966416] x14: x13: 0010 x12:
> 0101010101010101
> [ 14.973650] x11: ff7f7f7f7f7f7f7f x10: 840003584d5b x9 :
> 81276518
> [ 14.980886] x8 : 0101010101010101 x7 : x6 :
> 40e5d140
> [ 14.988120] x5 : x4 : 8a85b580 x3 :
>
> [ 14.995355] x2 : 0001 x1 : 0002 x0 :
> 812901c0
> [ 15.002591] Call trace:
> [ 15.005063] vc5_hdmi_reset+0x1f8/0x240 [vc4]
> [ 15.009514] vc4_hdmi_runtime_resume+0x74/0x2dc [vc4]
> [ 15.014671] vc4_hdmi_bind+0x22c/0xa40 [vc4]
> [ 15.019038] component_bind_all+0x114/0x264
> [ 15.023293] vc4_drm_bind+0x160/0x2a4 [vc4]
> [ 15.027565] try_to_bring_up_aggregate_device+0x1e4/0x2d0
> [ 15.033044] component_master_add_with_match+0xcc/0x110
> [ 15.038340] vc4_platform_drm_probe+0xc4/0xfc [vc4]
> [ 15.043327] platform_probe+0x74/0xd0
> [ 15.047037] really_probe+0xc8/0x3ec
> [ 15.050662] __driver_probe_device+0x84/0x190
> [ 15.055079] driver_probe_device+0x44/0x100
> [ 15.059318] __driver_attach+0xd8/0x1d0
> [ 15.063206] bus_for_each_dev+0x7c/0xe0
> [ 15.067090] driver_attach+0x30/0x3c
> [ 15.070711] bus_add_driver+0x188/0x244
> [ 15.074595] driver_register+0x84/0x140
> [ 15.078482] __platform_driver_register+0x34/0x40
> [ 15.083247] vc4_drm_register+0x5c/0x1000 [vc4]
> [ 15.087881] do_one_initcall+0x50/0x2bc
> [ 15.091770] do_init_module+0x50/0x1f0
> [ 15.095569] load_module+0x1a28/0x1fa0
> [ 15.099366] __do_sys_finit_module+0xac/0x12c
> [ 15.103779] __arm64_sys_finit_module+0x2c/0x40
> [ 15.108368] invoke_syscall+0x50/0x120
> [ 15.112166] el0_svc_common.constprop.0+0x6c/0x1b4
> [ 15.117021] do_el0_svc+0x38/0xcc
> [ 15.120378] el0_svc+0x30/0xd0
> [ 15.123472] el0t_64_sync_handler+0x11c/0x150
> [ 15.127886] el0t_64_sync+0x1a0/0x1a4
> [ 15.131595] ---[ end trace ]---
>
> git bisect pointed to 467e30171b5b ("drm/vc4: hdmi: Move HDMI reset to
> pm_resume")
> and reverting this commit has fixed the warning.
>
> I will be happy to test any patch or provide any extra log if needed.
We have fixes for this in drm-misc-next that have missed the cut for the
merge window:
https://lore.kernel.org/all/20220629123510.1915022-38-max...@cerno.tech/
https://lore.kernel.org/all/20220629123510.1915022-39-max...@cerno.tech/
If it fixes it for you, I'll apply it to drm-misc-fixes
Maxime
signature.asc
Description: PGP signature
Re: (subset) [PATCH v2 0/7] Devm helpers for regulator get and enable
On 8/16/22 13:36, Mark Brown wrote: > On Tue, Aug 16, 2022 at 07:56:06AM +0300, Matti Vaittinen wrote: >> On 8/16/22 01:55, Mark Brown wrote: >>> On Tue, Aug 16, 2022 at 12:17:17AM +0300, Laurent Pinchart wrote: > These devres helpers give a false sense of security to driver authors and they will end up introducing problems, the same way that devm_kzalloc() makes it outrageously easy to crash the kernel by disconnecting a device that is in use. > >> I think this is going a bit "off-topic" but I'd like to understand what is >> behind this statement? From device-writer's perspective - I don't know much >> better alternatives to free up the memory. I don't see how freeing stuff at >> .remove would be any better? As far as I understand - if someone is using >> driver's resources after the device has gone and the driver is detached, >> then there is not much the driver could do to free-up the stuff be it devm >> or not? This sounds like fundamentally different problem (to me). > > If a driver has done something like create a file that's accessible to > userspace then that file may be held open by userspace even after the > device goes away, the driver that created the file needs to ensure that > any storage that's used by the file remains allocated until the file is > also freed (typically this is data specific to the file rather than the > full device data). Similar situations can exist elsewhere, that's just > the common case. There'll be a deletion callback on whatever other > object causes the problem, the allocation needs to be reference counted > against both the the device and whatever other users there might be. Oh right. Thanks. So we're discussing (a corner?) case where the freeing is done by a callback that was registered by a driver. Callback being called for example when the refcount for a resource gets down, potentially long after the driver was gone. I see the problem of releasing something with devm in such case. Still, I don't think it is something we should avoid by banning the use of devm - which is useful in many other cases. It'd be equally wrong release the resource in .remove() or doing any other "double freeing". To me this boils down to educating people about the life-times. I wonder if writing such 'release callbacks' is compulsory? I mean, if I was writing a driver to some new (to me) subsystem and was required to write an explicit release-callback for a resource - then it'd surely rang a bell about potentially double freeing stuff with devm. Especially if the doc stated the callback can be called after the driver has been detached. > >>> That's a different conversation, and a totally >>> valid one especially when you start looking at things like implementing >>> userspace APIs which need to cope with hardware going away while still >>> visible to userspace. > >> This is interesting. It's not easy for me to spot how devm changes things >> here? If we consider some removable device - then I guess also the .remove() >> is ran only after HW has already gone? Yes, devm might make the time window >> when userspace can see hardware that has gone longer but does it bring any >> new problem there? It seems to me devm can make hitting the spot more likely >> - but I don't think it brings completely new issues? (Well, I may be wrong >> here - wouldn't be the first time :]) > > See above, something can still know the device was there even after it's > gone. Yes. Thanks for the education. I'm still not sure I understand how devm changes the picture. I'd guess in the case you described above, the user-space would still see the device until it closes the file and the call-back cleans-up. I guess freeing the stuff (that is used until user-space drops the handle) anywhere except the clean-up call-back is wrong - be the mechanism devm or driver's .remove() or any other. To me the key is still teaching people to know what bits may be used after the driver has been detached. Thanks for the explanation guys - this has been insightful to me :) Best Regards -- Matti -- The Linux Kernel guy at ROHM Semiconductors Matti Vaittinen, Linux device drivers ROHM Semiconductors, Finland SWDC Kiviharjunlenkki 1E 90220 OULU FINLAND ~~ this year is the year of a signature writers block ~~
[PATCH] video/fbdev: fix repeated words in comments
Delete the redundant word 'set'.
Signed-off-by: Jilin Yuan
---
drivers/video/fbdev/ssd1307fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
index 5c765655d000..52e4ed9da78c 100644
--- a/drivers/video/fbdev/ssd1307fb.c
+++ b/drivers/video/fbdev/ssd1307fb.c
@@ -450,7 +450,7 @@ static int ssd1307fb_init(struct ssd1307fb_par *par)
if (ret < 0)
return ret;
- /* Set Set Area Color Mode ON/OFF & Low Power Display Mode */
+ /* Set Area Color Mode ON/OFF & Low Power Display Mode */
if (par->area_color_enable || par->low_power) {
u32 mode;
--
2.36.1
[PATCH] video/fbdev: fix repeated words in comments
Delete the redundant word 'its'.
Signed-off-by: Jilin Yuan
---
drivers/video/fbdev/skeletonfb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/skeletonfb.c b/drivers/video/fbdev/skeletonfb.c
index 818b3a5003e1..f316ea320d29 100644
--- a/drivers/video/fbdev/skeletonfb.c
+++ b/drivers/video/fbdev/skeletonfb.c
@@ -97,7 +97,7 @@ static const struct fb_fix_screeninfo xxxfb_fix = {
/*
* Modern graphical hardware not only supports pipelines but some
* also support multiple monitors where each display can have its
- * own unique data. In this case each display could be
+ * own unique data. In this case each display could be
* represented by a separate framebuffer device thus a separate
* struct fb_info. Now the struct xxx_par represents the graphics
* hardware state thus only one exist per card. In this case the
--
2.36.1
Re: (subset) [PATCH 1/3] MAINTAINERS: Drop Bartlomiej Zolnierkiewicz
On Mon, 8 Aug 2022 13:15:24 +0300, Krzysztof Kozlowski wrote: > Bartlomiej's Samsung email address is not working since around last > year and there was no follow up patch take over of the drivers, so drop > the email from maintainers. > > Applied, thanks! [1/3] MAINTAINERS: Drop Bartlomiej Zolnierkiewicz https://git.kernel.org/krzk/linux/c/20b02590a3f76ee4895a917da28897736b20eda9 Best regards, -- Krzysztof Kozlowski
Re: [PATCH] drm/radeon: add a force flush to delay work when radeon
在 2022/8/15 21:12, Christian König 写道:
Am 15.08.22 um 09:34 schrieb 李真能:
在 2022/8/12 18:55, Christian König 写道:
Am 11.08.22 um 09:25 schrieb Zhenneng Li:
Although radeon card fence and wait for gpu to finish processing
current batch rings,
there is still a corner case that radeon lockup work queue may not
be fully flushed,
and meanwhile the radeon_suspend_kms() function has called
pci_set_power_state() to
put device in D3hot state.
If I'm not completely mistaken the reset worker uses the
suspend/resume functionality as well to get the hardware into a
working state again.
So if I'm not completely mistaken this here would lead to a
deadlock, please double check that.
We have tested many times, there are no deadlock.
Testing doesn't tells you anything, you need to audit the call paths.
In which situation, there would lead to a deadlock?
GPU resets.
Although flush_delayed_work(&rdev->fence_drv[i].lockup_work) will wait
for a lockup_work to finish executing the last queueing, but this
kernel func haven't get any lock, and lockup_work will run in another
kernel thread, so I think flush_delayed_work could not lead to a deadlock.
Therefor if radeon_gpu_reset is called in another thread when
radeon_suspend_kms is blocked on flush_delayed_work, there could not
lead to a deadlock.
Regards,
Christian.
Regards,
Christian.
Per PCI spec rev 4.0 on 5.3.1.4.1 D3hot State.
Configuration and Message requests are the only TLPs accepted by a
Function in
the D3hot state. All other received Requests must be handled as
Unsupported Requests,
and all received Completions may optionally be handled as
Unexpected Completions.
This issue will happen in following logs:
Unable to handle kernel paging request at virtual address
8800e0008010
CPU 0 kworker/0:3(131): Oops 0
pc = [] ra = [] ps =
Tainted: G W
pc is at si_gpu_check_soft_reset+0x3c/0x240
ra is at si_dma_is_lockup+0x34/0xd0
v0 = t0 = fff08800e0008010 t1 = 0001
t2 = 8010 t3 = fff7e3c0 t4 = fff7e3c00258
t5 = t6 = 0001 t7 = fff7ef078000
s0 = fff7e3c016e8 s1 = fff7e3c0 s2 = fff7e3c00018
s3 = fff7e3c0 s4 = fff7fff59d80 s5 =
s6 = fff7ef07bd98
a0 = fff7e3c0 a1 = fff7e3c016e8 a2 = 0008
a3 = 0001 a4 = 8f5c28f5c28f5c29 a5 = 810f4338
t8 = 0275 t9 = 809b66f8 t10 = ff6769c5d964b800
t11= b886 pv = 811bea20 at =
gp = 81d89690 sp = aa814126
Disabling lock debugging due to kernel taint
Trace:
[] si_dma_is_lockup+0x34/0xd0
[] radeon_fence_check_lockup+0xd0/0x290
[] process_one_work+0x280/0x550
[] worker_thread+0x70/0x7c0
[] worker_thread+0x130/0x7c0
[] kthread+0x200/0x210
[] worker_thread+0x0/0x7c0
[] kthread+0x14c/0x210
[] ret_from_kernel_thread+0x18/0x20
[] kthread+0x0/0x210
Code: ad3e0008 43f0074a ad7e0018 ad9e0020 8c3001e8 40230101
<8821> 4821ed21
So force lockup work queue flush to fix this problem.
Signed-off-by: Zhenneng Li
---
drivers/gpu/drm/radeon/radeon_device.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/radeon/radeon_device.c
index 15692cb241fc..e608ca26780a 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1604,6 +1604,9 @@ int radeon_suspend_kms(struct drm_device
*dev, bool suspend,
if (r) {
/* delay GPU reset to resume */
radeon_fence_driver_force_completion(rdev, i);
+ } else {
+ /* finish executing delayed work */
+ flush_delayed_work(&rdev->fence_drv[i].lockup_work);
}
}
Re: [PATCH v1 05/35] drm/connector: Add TV standard property
On Wed, Aug 17, 2022 at 9:31 AM Geert Uytterhoeven wrote:
> On Tue, Aug 16, 2022 at 5:50 PM Maxime Ripard wrote:
> > On Tue, Aug 16, 2022 at 04:43:44PM +0200, Geert Uytterhoeven wrote:
> > > > > > > Either you have to add them here (e.g. "hd720p50" and
> > > > > > > "hd720p60"), or
> > > > > > > handle them through "@". The latter would impact
> > > > > > > "[PATCH v1
> > > > > > > 09/35] drm/modes: Move named modes parsing to a separate
> > > > > > > function", as
> > > > > > > currently a named mode and a refresh rate can't be specified both.
> > > > > >
> > > > > > I think the former would make more sense. It simplifies a bit the
> > > > > > parser, and we're going to use a named mode anyway.
> > > > > >
> > > > > > > As "[PATCH v1 34/35] drm/modes: Introduce the tv_mode property as
> > > > > > > a
> > > > > > > command-line option" uses a separate "tv_mode" option, and not
> > > > > > > the main
> > > > > > > mode name, I think you want to add them here.
> > > > > >
> > > > > > It's a separate story I think, we could have a named mode hd720p50,
> > > > > > which would be equivalent to 1280x720,tv_mode=hd720p
> > > > >
> > > > > So where's the field rate in "1280x720,tv_mode=hd720p"?
> > > >
> > > > Yeah, sorry I meant 1280x720@50,tv_mode=hd720p
> > >
> > > Above you said "I think the former would make more sense", so that
> > > should be "1280x720,tv_mode=hd720p50"?
> >
> > No, 720p at 50Hz would be either hd720p50 or 1280x720@50,tv_mode=hd720p
> > and 60Hz would be hd720p60 or 1280x720@60,tv_mode=hd720p
>
> I disagree: hd720p50 and hd720p60 are different TV modes.
> Treating them the same would be similar to treating unmodulated (e.g.
> component) PAL-N (25 frames/s) and PAL-M (30 frames/s) the same.
IIRC from my PS3 -Linux days, not all HD(-Ready) TVs supported both
hd720p50 and hd720p60.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] drm/i915: Fix random -ENOSPC eviction errors due to locked vma objects
On Wed, 2022-08-17 at 09:55 +0300, Sviatoslav Peleshko wrote:
> The i915_gem_object_trylock we had in the grab_vma() makes it return
> false
> when the vma->obj is already locked. In this case we'll skip this vma
> during eviction, and eventually might be forced to return -ENOSPC
> even
> though we could've evicted this vma if we waited for the lock a bit.
>
> To fix this, replace the i915_gem_object_trylock with
> i915_gem_object_lock.
> And because we have to worry about the potential deadlock now,
> bubble-up
> the error code, so it will be correctly handled by the WW mechanism.
>
> This fixes the issue
> https://gitlab.freedesktop.org/drm/intel/-/issues/6564
>
> Fixes: 7e00897be8bf ("drm/i915: Add object locking to
> i915_gem_evict_for_node and i915_gem_evict_something, v2.")
> Signed-off-by: Sviatoslav Peleshko
>
> ---
> drivers/gpu/drm/i915/i915_gem_evict.c | 69 ++---
> --
> 1 file changed, 46 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c
> b/drivers/gpu/drm/i915/i915_gem_evict.c
> index f025ee4fa526..9d43f213f68f 100644
> --- a/drivers/gpu/drm/i915/i915_gem_evict.c
> +++ b/drivers/gpu/drm/i915/i915_gem_evict.c
> @@ -55,49 +55,58 @@ static int ggtt_flush(struct intel_gt *gt)
> return intel_gt_wait_for_idle(gt, MAX_SCHEDULE_TIMEOUT);
> }
>
> -static bool grab_vma(struct i915_vma *vma, struct i915_gem_ww_ctx
> *ww)
> +static int grab_vma(struct i915_vma *vma, struct i915_gem_ww_ctx
> *ww)
> {
> + int ret = 0;
> +
> /*
> * We add the extra refcount so the object doesn't drop to
> zero until
> * after ungrab_vma(), this way trylock is always paired with
> unlock.
> */
> if (i915_gem_object_get_rcu(vma->obj)) {
> - if (!i915_gem_object_trylock(vma->obj, ww)) {
> + ret = i915_gem_object_lock(vma->obj, ww);
Isn't the vm->mutex held here? If so, then this would be a lockdep
violation.
/Thomas
> + if (ret)
> i915_gem_object_put(vma->obj);
> - return false;
> - }
> } else {
> /* Dead objects don't need pins */
> atomic_and(~I915_VMA_PIN_MASK, &vma->flags);
> }
>
> - return true;
> + return ret;
> }
>
> -static void ungrab_vma(struct i915_vma *vma)
> +static void ungrab_vma(struct i915_vma *vma, struct i915_gem_ww_ctx
> *ww)
> {
> if (dying_vma(vma))
> return;
>
> - i915_gem_object_unlock(vma->obj);
> + if (!ww)
> + i915_gem_object_unlock(vma->obj);
> +
> i915_gem_object_put(vma->obj);
> }
>
> -static bool
> +static int
> mark_free(struct drm_mm_scan *scan,
> struct i915_gem_ww_ctx *ww,
> struct i915_vma *vma,
> unsigned int flags,
> struct list_head *unwind)
> {
> + int err;
> +
> if (i915_vma_is_pinned(vma))
> - return false;
> + return -ENOSPC;
>
> - if (!grab_vma(vma, ww))
> - return false;
> + err = grab_vma(vma, ww);
> + if (err)
> + return err;
>
> list_add(&vma->evict_link, unwind);
> - return drm_mm_scan_add_block(scan, &vma->node);
> + if (!drm_mm_scan_add_block(scan, &vma->node))
> + return -ENOSPC;
> +
> + return 0;
> }
>
> static bool defer_evict(struct i915_vma *vma)
> @@ -150,6 +159,7 @@ i915_gem_evict_something(struct
> i915_address_space *vm,
> enum drm_mm_insert_mode mode;
> struct i915_vma *active;
> int ret;
> + int err = 0;
>
> lockdep_assert_held(&vm->mutex);
> trace_i915_gem_evict(vm, min_size, alignment, flags);
> @@ -210,17 +220,23 @@ i915_gem_evict_something(struct
> i915_address_space *vm,
> continue;
> }
>
> - if (mark_free(&scan, ww, vma, flags, &eviction_list))
> + err = mark_free(&scan, ww, vma, flags,
> &eviction_list);
> + if (!err)
> goto found;
> + if (err == -EDEADLK)
> + break;
> }
>
> /* Nothing found, clean up and bail out! */
> list_for_each_entry_safe(vma, next, &eviction_list,
> evict_link) {
> ret = drm_mm_scan_remove_block(&scan, &vma->node);
> BUG_ON(ret);
> - ungrab_vma(vma);
> + ungrab_vma(vma, ww);
> }
>
> + if (err == -EDEADLK)
> + return err;
> +
> /*
> * Can we unpin some objects such as idle hw contents,
> * or pending flips? But since only the GGTT has global
> entries
> @@ -267,7 +283,7 @@ i915_gem_evict_something(struct
> i915_address_space *vm,
> __i915_vma_pin(vma);
> } else {
> list_del(&vma->evict_link);
> -
Re: [PATCH v1 05/35] drm/connector: Add TV standard property
Hi Maxime,
On Tue, Aug 16, 2022 at 5:50 PM Maxime Ripard wrote:
> On Tue, Aug 16, 2022 at 04:43:44PM +0200, Geert Uytterhoeven wrote:
> > > > > > Either you have to add them here (e.g. "hd720p50" and "hd720p60"),
> > > > > > or
> > > > > > handle them through "@". The latter would impact "[PATCH
> > > > > > v1
> > > > > > 09/35] drm/modes: Move named modes parsing to a separate function",
> > > > > > as
> > > > > > currently a named mode and a refresh rate can't be specified both.
> > > > >
> > > > > I think the former would make more sense. It simplifies a bit the
> > > > > parser, and we're going to use a named mode anyway.
> > > > >
> > > > > > As "[PATCH v1 34/35] drm/modes: Introduce the tv_mode property as a
> > > > > > command-line option" uses a separate "tv_mode" option, and not the
> > > > > > main
> > > > > > mode name, I think you want to add them here.
> > > > >
> > > > > It's a separate story I think, we could have a named mode hd720p50,
> > > > > which would be equivalent to 1280x720,tv_mode=hd720p
> > > >
> > > > So where's the field rate in "1280x720,tv_mode=hd720p"?
> > >
> > > Yeah, sorry I meant 1280x720@50,tv_mode=hd720p
> >
> > Above you said "I think the former would make more sense", so that
> > should be "1280x720,tv_mode=hd720p50"?
>
> No, 720p at 50Hz would be either hd720p50 or 1280x720@50,tv_mode=hd720p
> and 60Hz would be hd720p60 or 1280x720@60,tv_mode=hd720p
I disagree: hd720p50 and hd720p60 are different TV modes.
Treating them the same would be similar to treating unmodulated (e.g.
component) PAL-N (25 frames/s) and PAL-M (30 frames/s) the same.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v1 05/35] drm/connector: Add TV standard property
On Wed, Aug 17, 2022 at 09:31:18AM +0200, Geert Uytterhoeven wrote: > Hi Maxime, > > On Tue, Aug 16, 2022 at 5:50 PM Maxime Ripard wrote: > > On Tue, Aug 16, 2022 at 04:43:44PM +0200, Geert Uytterhoeven wrote: > > > > > > > Either you have to add them here (e.g. "hd720p50" and > > > > > > > "hd720p60"), or > > > > > > > handle them through "@". The latter would impact > > > > > > > "[PATCH v1 > > > > > > > 09/35] drm/modes: Move named modes parsing to a separate > > > > > > > function", as > > > > > > > currently a named mode and a refresh rate can't be specified both. > > > > > > > > > > > > I think the former would make more sense. It simplifies a bit the > > > > > > parser, and we're going to use a named mode anyway. > > > > > > > > > > > > > As "[PATCH v1 34/35] drm/modes: Introduce the tv_mode property as > > > > > > > a > > > > > > > command-line option" uses a separate "tv_mode" option, and not > > > > > > > the main > > > > > > > mode name, I think you want to add them here. > > > > > > > > > > > > It's a separate story I think, we could have a named mode hd720p50, > > > > > > which would be equivalent to 1280x720,tv_mode=hd720p > > > > > > > > > > So where's the field rate in "1280x720,tv_mode=hd720p"? > > > > > > > > Yeah, sorry I meant 1280x720@50,tv_mode=hd720p > > > > > > Above you said "I think the former would make more sense", so that > > > should be "1280x720,tv_mode=hd720p50"? > > > > No, 720p at 50Hz would be either hd720p50 or 1280x720@50,tv_mode=hd720p > > and 60Hz would be hd720p60 or 1280x720@60,tv_mode=hd720p > > I disagree: hd720p50 and hd720p60 are different TV modes. I agree, and I don't see how that command-line doesn't express that? Maxime signature.asc Description: PGP signature
Re: [PATCH v1 04/35] drm/modes: Introduce 480i and 576i modes
On Tue, Aug 16, 2022 at 05:00:38PM +0200, Geert Uytterhoeven wrote: > Hi Maxime, > > On Tue, Aug 16, 2022 at 3:26 PM Maxime Ripard wrote: > > On Fri, Aug 12, 2022 at 03:18:58PM +0200, Geert Uytterhoeven wrote: > > > On Fri, Jul 29, 2022 at 6:35 PM Maxime Ripard wrote: > > > > Multiple drivers (meson, vc4) define the analog TV 525-lines and > > > > 625-lines > > > > modes in the drivers. > > > > > > Nit: strictly speaking these are not analog modes, but the digital > > > variants (ITU-R BT.656 and DVD-Video D1) of NTSC and PAL, using a > > > 13.5 MHz sampling frequency for pixels. > > > > > > In analog modes, the only discrete values are the number of lines, and > > > the frame/field rate (fixing the horizontal sync rate when combined). > > > > > > The number of (in)visible pixels per line depends on the available > > > bandwidth. In a digital variant (which is anything generated by a > > > digital computer system), the latter depends on the pixel clock, which > > > can wildly differ from the 13.5 MHz used in the BT.656 standard. (e.g. > > > Amiga uses 7.09/14.19/28.38 MHz (PAL) or 7.16/14.32/28.64 MHz (NTSC)). > > > > > > So I think we probably need some way to generate a PAL/NTSC-compatible > > > mode based not only on resolution, but also on pixel clock. > > > > This would also fix the comments made by Jani and Thomas, so I quite > > like the idea of it. > > > > I'm struggling a bit to find how would could implement this though. > > > > From what you were saying, I guess the prototype would be something like > > > > struct drm_display_mode *drm_create_analog_mode(unsigned int pixel_clock, > > unsigned int lines, > > unsigned int frame_rate) > > > > But I have zero idea on what the implementation would be. Do you have > > some resources for this you could point me to? > > Horizontally, I think you should calculate left/right margins and > hsync length to yield timings that match those for the BT.656 PAL/NTSC > modes. I.e. when a 640x512 mode with a pixel clock of 14 MHz is > requested, you want to calculate left', right', and hslen' for > > | < left' ---> | <- 640 pixels -> | < right' ---> | <--- hslen' --> | > @ 14 MHz > > so they match the timings for left, right, and hslen for > > | <--- left ---> | <--- 720 pixels ---> | <--- right ---> | <--- hslen ---> | > @ 13.5 MHz > > As 640 pixels @ 14 MHz are less wide than 720 pixels @ 13.5 MHz, > you want to make sure to align the center of the visible part. So I guess in that example if we want to center it, left == right and left' == right'? What about the sync length? > Vertically, it's simpler, as the number of lines is discrete. > You do have to take into account interlace and doublescan, and > progressive modes with 262/312 lines. So we only have to deal with 525 and 625 lines total (without taking interlace and doublescan into account), right? I guess we still have the same question, we probably want to center it, so top == bottom, but what about the vsync length? Maxime signature.asc Description: PGP signature
Re: [PATCH v1 05/35] drm/connector: Add TV standard property
Hi Maxime,
On Wed, Aug 17, 2022 at 9:47 AM Maxime Ripard wrote:
> On Wed, Aug 17, 2022 at 09:31:18AM +0200, Geert Uytterhoeven wrote:
> > On Tue, Aug 16, 2022 at 5:50 PM Maxime Ripard wrote:
> > > On Tue, Aug 16, 2022 at 04:43:44PM +0200, Geert Uytterhoeven wrote:
> > > > > > > > Either you have to add them here (e.g. "hd720p50" and
> > > > > > > > "hd720p60"), or
> > > > > > > > handle them through "@". The latter would impact
> > > > > > > > "[PATCH v1
> > > > > > > > 09/35] drm/modes: Move named modes parsing to a separate
> > > > > > > > function", as
> > > > > > > > currently a named mode and a refresh rate can't be specified
> > > > > > > > both.
> > > > > > >
> > > > > > > I think the former would make more sense. It simplifies a bit the
> > > > > > > parser, and we're going to use a named mode anyway.
> > > > > > >
> > > > > > > > As "[PATCH v1 34/35] drm/modes: Introduce the tv_mode property
> > > > > > > > as a
> > > > > > > > command-line option" uses a separate "tv_mode" option, and not
> > > > > > > > the main
> > > > > > > > mode name, I think you want to add them here.
> > > > > > >
> > > > > > > It's a separate story I think, we could have a named mode
> > > > > > > hd720p50,
> > > > > > > which would be equivalent to 1280x720,tv_mode=hd720p
> > > > > >
> > > > > > So where's the field rate in "1280x720,tv_mode=hd720p"?
> > > > >
> > > > > Yeah, sorry I meant 1280x720@50,tv_mode=hd720p
> > > >
> > > > Above you said "I think the former would make more sense", so that
> > > > should be "1280x720,tv_mode=hd720p50"?
> > >
> > > No, 720p at 50Hz would be either hd720p50 or 1280x720@50,tv_mode=hd720p
> > > and 60Hz would be hd720p60 or 1280x720@60,tv_mode=hd720p
> >
> > I disagree: hd720p50 and hd720p60 are different TV modes.
>
> I agree, and I don't see how that command-line doesn't express that?
Oh, I see what you mean: yes, it expresses that.
But it is inconsistent with the NTSC/PAL/SECAM/hd{480,576}[ip] modes,
where the TV mode specifies both number of lines and frame rate.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v2 1/3] dma-buf: Add ioctl to query mmap coherency/cache info
Am 16.08.22 um 19:29 schrieb Rob Clark:
On Tue, Aug 16, 2022 at 9:51 AM Christian König
wrote:
Am 16.08.22 um 16:26 schrieb Rob Clark:
On Tue, Aug 16, 2022 at 1:27 AM Christian König
wrote:
Am 15.08.22 um 23:15 schrieb Rob Clark:
From: Rob Clark
This is a fairly narrowly focused interface, providing a way for a VMM
in userspace to tell the guest kernel what pgprot settings to use when
mapping a buffer to guest userspace.
For buffers that get mapped into guest userspace, virglrenderer returns
a dma-buf fd to the VMM (crosvm or qemu). In addition to mapping the
pages into the guest VM, it needs to report to drm/virtio in the guest
the cache settings to use for guest userspace. In particular, on some
architectures, creating aliased mappings with different cache attributes
is frowned upon, so it is important that the guest mappings have the
same cache attributes as any potential host mappings.
Signed-off-by: Rob Clark
---
v2: Combine with coherency, as that is a related concept.. and it is
relevant to the VMM whether coherent access without the SYNC ioctl
is possible; set map_info at export time to make it more clear
that it applies for the lifetime of the dma-buf (for any mmap
created via the dma-buf)
Well, exactly that's a conceptual NAK from my side.
The caching information can change at any time. For CPU mappings even
without further notice from the exporter.
You should look before you criticize, as I left you a way out.. the
idea was that DMA_BUF_MAP_INCOHERENT should indicate that the buffer
cannot be mapped to the guest. We could ofc add more DMA_BUF_MAP_*
values if something else would suit you better. But the goal is to
give the VMM enough information to dtrt, or return an error if mapping
to guest is not possible. That seems better than assuming mapping to
guest will work and guessing about cache attrs
Well I'm not rejecting the implementation, I'm rejecting this from the
conceptual point of view.
We intentional gave the exporter full control over the CPU mappings.
This approach here breaks that now.
I haven't seen the full detailed reason why we should do that and to be
honest KVM seems to mess with things it is not supposed to touch.
For example the page reference count of mappings marked with VM_IO is a
complete no-go. This is a very strong evidence that this was based on
rather dangerous halve knowledge about the background of the handling here.
So as long as I don't see a full explanation why KVM is grabbing
reference to pages while faulting them and why we manually need to
forward the caching while the hardware documentation indicates otherwise
I will be rejecting this whole approach.
Didn't we cover this on the previous iteration already. From a host
kernel PoV these are just normal host userspace mappings. The
userspace VMM mapping becomes the "physical address" in the guest and
the stage 2 translation tables map it to the guest userspace.
The resulting cache attrs from combination of S1 and S2 translation
can differ. So ideally we setup the S2 pgtables in guest aligned with
host userspace mappings
Well exactly that is not very convincing.
What you want to do is to use one channel for the address and a
different one for the cache attrs, that's not something I would
recommend doing in general.
Instead the client pgtables should be setup in a way so that host can
overwrite them.
Regards,
Christian.
BR,
-R
Regards,
Christian.
BR,
-R
If the hardware can't use the caching information from the host CPU page
tables directly then that pretty much completely breaks the concept that
the exporter is responsible for setting up those page tables.
Regards,
Christian.
drivers/dma-buf/dma-buf.c| 63 +++--
include/linux/dma-buf.h | 11 ++
include/uapi/linux/dma-buf.h | 68
3 files changed, 132 insertions(+), 10 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 32f55640890c..262c4706f721 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -125,6 +125,32 @@ static struct file_system_type dma_buf_fs_type = {
.kill_sb = kill_anon_super,
};
+static int __dma_buf_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma)
+{
+ int ret;
+
+ /* check if buffer supports mmap */
+ if (!dmabuf->ops->mmap)
+ return -EINVAL;
+
+ ret = dmabuf->ops->mmap(dmabuf, vma);
+
+ /*
+ * If the exporter claims to support coherent access, ensure the
+ * pgprot flags match the claim.
+ */
+ if ((dmabuf->map_info != DMA_BUF_MAP_INCOHERENT) && !ret) {
+ pgprot_t wc_prot = pgprot_writecombine(vma->vm_page_prot);
+ if (dmabuf->map_info == DMA_BUF_COHERENT_WC) {
+ WARN_ON_ONCE(pgprot_val(vma->vm_page_prot) !=
pgprot_val(wc_prot));
+ } else {
+ WARN_ON_ONCE(pgprot_val(vma->vm
Re: [PATCH] drm/i915: Fix all occurences of the "the the" typo
On Tue, 16 Aug 2022, Bo Liu wrote: > There is an unexpected word "the" in the file i915_irq.c, > fix it. > > Signed-off-by: Bo Liu Thanks for the patch, pushed to drm-intel-next. BR, Jani. > --- > drivers/gpu/drm/i915/i915_irq.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c > index 73cebc6aa650..783a6ca41a61 100644 > --- a/drivers/gpu/drm/i915/i915_irq.c > +++ b/drivers/gpu/drm/i915/i915_irq.c > @@ -65,7 +65,7 @@ > > /* > * Interrupt statistic for PMU. Increments the counter only if the > - * interrupt originated from the the GPU so interrupts from a device which > + * interrupt originated from the GPU so interrupts from a device which > * shares the interrupt line are not accounted. > */ > static inline void pmu_irq_stats(struct drm_i915_private *i915, -- Jani Nikula, Intel Open Source Graphics Center
Re: [PATCH v1 05/35] drm/connector: Add TV standard property
On Wed, Aug 17, 2022 at 10:35:07AM +0200, Geert Uytterhoeven wrote:
> Hi Maxime,
>
> On Wed, Aug 17, 2022 at 9:47 AM Maxime Ripard wrote:
> > On Wed, Aug 17, 2022 at 09:31:18AM +0200, Geert Uytterhoeven wrote:
> > > On Tue, Aug 16, 2022 at 5:50 PM Maxime Ripard wrote:
> > > > On Tue, Aug 16, 2022 at 04:43:44PM +0200, Geert Uytterhoeven wrote:
> > > > > > > > > Either you have to add them here (e.g. "hd720p50" and
> > > > > > > > > "hd720p60"), or
> > > > > > > > > handle them through "@". The latter would impact
> > > > > > > > > "[PATCH v1
> > > > > > > > > 09/35] drm/modes: Move named modes parsing to a separate
> > > > > > > > > function", as
> > > > > > > > > currently a named mode and a refresh rate can't be specified
> > > > > > > > > both.
> > > > > > > >
> > > > > > > > I think the former would make more sense. It simplifies a bit
> > > > > > > > the
> > > > > > > > parser, and we're going to use a named mode anyway.
> > > > > > > >
> > > > > > > > > As "[PATCH v1 34/35] drm/modes: Introduce the tv_mode
> > > > > > > > > property as a
> > > > > > > > > command-line option" uses a separate "tv_mode" option, and
> > > > > > > > > not the main
> > > > > > > > > mode name, I think you want to add them here.
> > > > > > > >
> > > > > > > > It's a separate story I think, we could have a named mode
> > > > > > > > hd720p50,
> > > > > > > > which would be equivalent to 1280x720,tv_mode=hd720p
> > > > > > >
> > > > > > > So where's the field rate in "1280x720,tv_mode=hd720p"?
> > > > > >
> > > > > > Yeah, sorry I meant 1280x720@50,tv_mode=hd720p
> > > > >
> > > > > Above you said "I think the former would make more sense", so that
> > > > > should be "1280x720,tv_mode=hd720p50"?
> > > >
> > > > No, 720p at 50Hz would be either hd720p50 or 1280x720@50,tv_mode=hd720p
> > > > and 60Hz would be hd720p60 or 1280x720@60,tv_mode=hd720p
> > >
> > > I disagree: hd720p50 and hd720p60 are different TV modes.
> >
> > I agree, and I don't see how that command-line doesn't express that?
>
> Oh, I see what you mean: yes, it expresses that.
> But it is inconsistent with the NTSC/PAL/SECAM/hd{480,576}[ip] modes,
> where the TV mode specifies both number of lines and frame rate.
Only if we're using a named mode, and naming is hard :)
Honestly, I'd be inclined to drop the hd* for now from this series. I
don't have a hardware to test it with, for some we don't even have
drivers that could implement these modes, we don't have a spec to work
from, it looks like a recipe for failure :)
Maxime
signature.asc
Description: PGP signature
Re: [PATCH] drm/radeon: add a force flush to delay work when radeon
Am 17.08.22 um 09:31 schrieb 李真能:
在 2022/8/15 21:12, Christian König 写道:
Am 15.08.22 um 09:34 schrieb 李真能:
在 2022/8/12 18:55, Christian König 写道:
Am 11.08.22 um 09:25 schrieb Zhenneng Li:
Although radeon card fence and wait for gpu to finish processing
current batch rings,
there is still a corner case that radeon lockup work queue may not
be fully flushed,
and meanwhile the radeon_suspend_kms() function has called
pci_set_power_state() to
put device in D3hot state.
If I'm not completely mistaken the reset worker uses the
suspend/resume functionality as well to get the hardware into a
working state again.
So if I'm not completely mistaken this here would lead to a
deadlock, please double check that.
We have tested many times, there are no deadlock.
Testing doesn't tells you anything, you need to audit the call paths.
In which situation, there would lead to a deadlock?
GPU resets.
Although flush_delayed_work(&rdev->fence_drv[i].lockup_work) will wait
for a lockup_work to finish executing the last queueing, but this
kernel func haven't get any lock, and lockup_work will run in another
kernel thread, so I think flush_delayed_work could not lead to a
deadlock.
Therefor if radeon_gpu_reset is called in another thread when
radeon_suspend_kms is blocked on flush_delayed_work, there could not
lead to a deadlock.
Ok sounds like you didn't go what I wanted to say.
The key problem is that radeon_gpu_reset() calls radeon_suspend() which
in turn calls rdev->asic->suspend().
And this function in turn could end up in radeon_suspend_kms() again,
but I'm not 100% sure about that.
Just double check the order of function called here (e.g. if
radeon_suspend_kms() call radeon_suspend() or the other way around).
Apart from that your patch looks correct to me as well.
Regards,
Christian.
Regards,
Christian.
Regards,
Christian.
Per PCI spec rev 4.0 on 5.3.1.4.1 D3hot State.
Configuration and Message requests are the only TLPs accepted by
a Function in
the D3hot state. All other received Requests must be handled as
Unsupported Requests,
and all received Completions may optionally be handled as
Unexpected Completions.
This issue will happen in following logs:
Unable to handle kernel paging request at virtual address
8800e0008010
CPU 0 kworker/0:3(131): Oops 0
pc = [] ra = [] ps =
Tainted: G W
pc is at si_gpu_check_soft_reset+0x3c/0x240
ra is at si_dma_is_lockup+0x34/0xd0
v0 = t0 = fff08800e0008010 t1 = 0001
t2 = 8010 t3 = fff7e3c0 t4 = fff7e3c00258
t5 = t6 = 0001 t7 = fff7ef078000
s0 = fff7e3c016e8 s1 = fff7e3c0 s2 = fff7e3c00018
s3 = fff7e3c0 s4 = fff7fff59d80 s5 =
s6 = fff7ef07bd98
a0 = fff7e3c0 a1 = fff7e3c016e8 a2 = 0008
a3 = 0001 a4 = 8f5c28f5c28f5c29 a5 = 810f4338
t8 = 0275 t9 = 809b66f8 t10 = ff6769c5d964b800
t11= b886 pv = 811bea20 at =
gp = 81d89690 sp = aa814126
Disabling lock debugging due to kernel taint
Trace:
[] si_dma_is_lockup+0x34/0xd0
[] radeon_fence_check_lockup+0xd0/0x290
[] process_one_work+0x280/0x550
[] worker_thread+0x70/0x7c0
[] worker_thread+0x130/0x7c0
[] kthread+0x200/0x210
[] worker_thread+0x0/0x7c0
[] kthread+0x14c/0x210
[] ret_from_kernel_thread+0x18/0x20
[] kthread+0x0/0x210
Code: ad3e0008 43f0074a ad7e0018 ad9e0020 8c3001e8 40230101
<8821> 4821ed21
So force lockup work queue flush to fix this problem.
Signed-off-by: Zhenneng Li
---
drivers/gpu/drm/radeon/radeon_device.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/radeon/radeon_device.c
index 15692cb241fc..e608ca26780a 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1604,6 +1604,9 @@ int radeon_suspend_kms(struct drm_device
*dev, bool suspend,
if (r) {
/* delay GPU reset to resume */
radeon_fence_driver_force_completion(rdev, i);
+ } else {
+ /* finish executing delayed work */
+ flush_delayed_work(&rdev->fence_drv[i].lockup_work);
}
}
Re: [Intel-gfx] [PATCH] drm/i915: Switch TGL-H DP-IN to dGFX when it's supported
On Wed, Aug 17, 2022 at 7:59 PM Ville Syrjälä wrote: [snipped] > I had a quick trawl through some Windows stuff for this and > it does seem to do a few extra checks: > - platform must be TGL-H (nothing else has the DPin stuff I guess) > - OpRegion header must indicate dGPU presence Is the dGPU presence denoted by the return bitmask of INTEL_DSM_FN_GET_BIOS_DATA_FUNCS_SUPPORTED? IIUC the mask 20 won't be set when dGPU is not present. > > Otherwise it does call this DSM uncoditionally on boot/S4 resume > so seems like that is the only really validated configuration. > Although it does seem to explicitly turn off displays prior to > the DSM so that does perhaps indicate that those ports might have > also been enabled via the iGPU by the BIOS. Not sure if disabling > the ports would work correctly after the DSM or not. If not then > the DSM call would need to happen after state readout/sanitization > so that we can shut things down gracefully. > > Additionally after the DSM call it scans the FIA TC live state > bits to check for DPin usage. Looks like its trying to make sure > the driver stops poking at the relevant power wells once in DPin > mode. i915 doesn't check that stuff atm so we might end up > mangling something while the dGPU is driving the port. Thanks for investigating this. I am not really familiar with other stuffs you mentioned, but I am happy to test any follow-up patch. Kai-Heng > > -- > Ville Syrjälä > Intel
Re: [PATCH 2/3] iommu/dma: Move public interfaces to linux/iommu.h
On Tue, 16 Aug 2022 18:28:04 +0100, Robin Murphy wrote: > > The iommu-dma layer is now mostly encapsulated by iommu_dma_ops, with > only a couple more public interfaces left pertaining to MSI integration. > Since these depend on the main IOMMU API header anyway, move their > declarations there, taking the opportunity to update the half-baked > comments to proper kerneldoc along the way. > > Signed-off-by: Robin Murphy > --- > > Note that iommu_setup_dma_ops() should also become internal in a future > phase of the great IOMMU API upheaval - for now as the last bit of true > arch code glue I consider it more "necessarily exposed" than "public". > > arch/arm64/mm/dma-mapping.c | 2 +- > drivers/iommu/dma-iommu.c | 15 ++-- > drivers/irqchip/irq-gic-v2m.c | 2 +- > drivers/irqchip/irq-gic-v3-its.c | 2 +- > drivers/irqchip/irq-gic-v3-mbi.c | 2 +- > drivers/irqchip/irq-ls-scfg-msi.c | 2 +- > drivers/vfio/vfio_iommu_type1.c | 1 - > include/linux/dma-iommu.h | 40 --- > include/linux/iommu.h | 36 > 9 files changed, 54 insertions(+), 48 deletions(-) For the irqchip side: Acked-by: Marc Zyngier M. -- Without deviation from the norm, progress is not possible.
Re: [Intel-gfx] [PATCH] drm/i915: Switch TGL-H DP-IN to dGFX when it's supported
On Wed, Aug 17, 2022 at 08:15:58PM +0800, Kai-Heng Feng wrote: > On Wed, Aug 17, 2022 at 7:59 PM Ville Syrjälä > wrote: > > [snipped] > > > I had a quick trawl through some Windows stuff for this and > > it does seem to do a few extra checks: > > - platform must be TGL-H (nothing else has the DPin stuff I guess) > > - OpRegion header must indicate dGPU presence > > Is the dGPU presence denoted by the return bitmask of > INTEL_DSM_FN_GET_BIOS_DATA_FUNCS_SUPPORTED No, there are apparently some extra bits in the OpRegion header which we're not currently even decoding. > > IIUC the mask 20 won't be set when dGPU is not present. Not sure whether that bit would change depending on the dGPU presence or not. Windows doesn't seem trust it alone, so either it won't change or someone was just extra paranoid. > > > > > Otherwise it does call this DSM uncoditionally on boot/S4 resume > > so seems like that is the only really validated configuration. > > Although it does seem to explicitly turn off displays prior to > > the DSM so that does perhaps indicate that those ports might have > > also been enabled via the iGPU by the BIOS. Not sure if disabling > > the ports would work correctly after the DSM or not. If not then > > the DSM call would need to happen after state readout/sanitization > > so that we can shut things down gracefully. > > > > Additionally after the DSM call it scans the FIA TC live state > > bits to check for DPin usage. Looks like its trying to make sure > > the driver stops poking at the relevant power wells once in DPin > > mode. i915 doesn't check that stuff atm so we might end up > > mangling something while the dGPU is driving the port. > > Thanks for investigating this. I am not really familiar with other > stuffs you mentioned, but I am happy to test any follow-up patch. > > Kai-Heng > > > > > -- > > Ville Syrjälä > > Intel -- Ville Syrjälä Intel
Re: [PATCH v2 03/29] drm/amdgpu: Don't register backlight when another backlight should be used
Hi,
On 7/20/22 18:46, Alex Deucher wrote:
> On Wed, Jul 20, 2022 at 12:44 PM Alex Deucher wrote:
>>
>> On Tue, Jul 12, 2022 at 3:39 PM Hans de Goede wrote:
>>>
>>> Before this commit when we want userspace to use the acpi_video backlight
>>> device we register both the GPU's native backlight device and acpi_video's
>>> firmware acpi_video# backlight device. This relies on userspace preferring
>>> firmware type backlight devices over native ones.
>>>
>>> Registering 2 backlight devices for a single display really is
>>> undesirable, don't register the GPU's native backlight device when
>>> another backlight device should be used.
>>>
>>> Changes in v2:
>>> - To avoid linker errors when amdgpu is builtin and video_detect.c is in
>>> a module, select ACPI_VIDEO and its deps if ACPI && X86 are enabled.
>>> When these are not set, ACPI_VIDEO is disabled, ensuring the stubs
>>> from acpi/video.h will be used.
>>>
>>> Signed-off-by: Hans de Goede
>>
>> Acked-by: Alex Deucher
>
> Actually, can you use dev_info for the messages below rather than
> DRM_INFO? That makes it easier to tell which GPU is affected in a
> multi-GPU system. With that changed,
> Acked-by: Alex Deucher
Thank you for the ack. I've changed the DRM_INFO(...) calls with
drm_info(drm_dev, ...) calls for the version 3 of this series
which I'm preparing.
Regards,
Hans
>
>>
>>> ---
>>> drivers/gpu/drm/Kconfig | 6 ++
>>> drivers/gpu/drm/amd/amdgpu/atombios_encoders.c| 7 +++
>>> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 +++
>>> 3 files changed, 20 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
>>> index aaa7ad1f0614..d65119860760 100644
>>> --- a/drivers/gpu/drm/Kconfig
>>> +++ b/drivers/gpu/drm/Kconfig
>>> @@ -258,6 +258,12 @@ config DRM_AMDGPU
>>> select HWMON
>>> select BACKLIGHT_CLASS_DEVICE
>>> select INTERVAL_TREE
>>> + # amdgpu depends on ACPI_VIDEO when X86 and ACPI are both enabled
>>> + # for select to work, ACPI_VIDEO's dependencies must also be
>>> selected
>>> + select INPUT if ACPI && X86
>>> + select X86_PLATFORM_DEVICES if ACPI && X86
>>> + select ACPI_WMI if ACPI && X86
>>> + select ACPI_VIDEO if ACPI && X86
>>> help
>>> Choose this option if you have a recent AMD Radeon graphics card.
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
>>> b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
>>> index fa7421afb9a6..abf209e36fca 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
>>> @@ -26,6 +26,8 @@
>>>
>>> #include
>>>
>>> +#include
>>> +
>>> #include
>>> #include
>>> #include "amdgpu.h"
>>> @@ -184,6 +186,11 @@ void amdgpu_atombios_encoder_init_backlight(struct
>>> amdgpu_encoder *amdgpu_encode
>>> if (!(adev->mode_info.firmware_flags &
>>> ATOM_BIOS_INFO_BL_CONTROLLED_BY_GPU))
>>> return;
>>>
>>> + if (!acpi_video_backlight_use_native()) {
>>> + DRM_INFO("Skipping amdgpu atom DIG backlight
>>> registration\n");
>>> + return;
>>> + }
>>> +
>>> pdata = kmalloc(sizeof(struct amdgpu_backlight_privdata),
>>> GFP_KERNEL);
>>> if (!pdata) {
>>> DRM_ERROR("Memory allocation failed\n");
>>> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>>> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>>> index 5eb111d35793..3b03a95e59a8 100644
>>> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>>> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>>> @@ -86,6 +86,8 @@
>>> #include
>>> #include
>>>
>>> +#include
>>> +
>>> #include "ivsrcid/dcn/irqsrcs_dcn_1_0.h"
>>>
>>> #include "dcn/dcn_1_0_offset.h"
>>> @@ -4050,6 +4052,11 @@ amdgpu_dm_register_backlight_device(struct
>>> amdgpu_display_manager *dm)
>>> amdgpu_dm_update_backlight_caps(dm, dm->num_of_edps);
>>> dm->brightness[dm->num_of_edps] = AMDGPU_MAX_BL_LEVEL;
>>>
>>> + if (!acpi_video_backlight_use_native()) {
>>> + DRM_INFO("Skipping amdgpu DM backlight registration\n");
>>> + return;
>>> + }
>>> +
>>> props.max_brightness = AMDGPU_MAX_BL_LEVEL;
>>> props.brightness = AMDGPU_MAX_BL_LEVEL;
>>> props.type = BACKLIGHT_RAW;
>>> --
>>> 2.36.0
>>>
>
Re: [PATCH v1 05/35] drm/connector: Add TV standard property
Hi Maxime,
On Wed, Aug 17, 2022 at 1:15 PM Maxime Ripard wrote:
> On Wed, Aug 17, 2022 at 10:35:07AM +0200, Geert Uytterhoeven wrote:
> > On Wed, Aug 17, 2022 at 9:47 AM Maxime Ripard wrote:
> > > On Wed, Aug 17, 2022 at 09:31:18AM +0200, Geert Uytterhoeven wrote:
> > > > On Tue, Aug 16, 2022 at 5:50 PM Maxime Ripard wrote:
> > > > > On Tue, Aug 16, 2022 at 04:43:44PM +0200, Geert Uytterhoeven wrote:
> > > > > > > > > > Either you have to add them here (e.g. "hd720p50" and
> > > > > > > > > > "hd720p60"), or
> > > > > > > > > > handle them through "@". The latter would impact
> > > > > > > > > > "[PATCH v1
> > > > > > > > > > 09/35] drm/modes: Move named modes parsing to a separate
> > > > > > > > > > function", as
> > > > > > > > > > currently a named mode and a refresh rate can't be
> > > > > > > > > > specified both.
> > > > > > > > >
> > > > > > > > > I think the former would make more sense. It simplifies a bit
> > > > > > > > > the
> > > > > > > > > parser, and we're going to use a named mode anyway.
> > > > > > > > >
> > > > > > > > > > As "[PATCH v1 34/35] drm/modes: Introduce the tv_mode
> > > > > > > > > > property as a
> > > > > > > > > > command-line option" uses a separate "tv_mode" option, and
> > > > > > > > > > not the main
> > > > > > > > > > mode name, I think you want to add them here.
> > > > > > > > >
> > > > > > > > > It's a separate story I think, we could have a named mode
> > > > > > > > > hd720p50,
> > > > > > > > > which would be equivalent to 1280x720,tv_mode=hd720p
> > > > > > > >
> > > > > > > > So where's the field rate in "1280x720,tv_mode=hd720p"?
> > > > > > >
> > > > > > > Yeah, sorry I meant 1280x720@50,tv_mode=hd720p
> > > > > >
> > > > > > Above you said "I think the former would make more sense", so that
> > > > > > should be "1280x720,tv_mode=hd720p50"?
> > > > >
> > > > > No, 720p at 50Hz would be either hd720p50 or
> > > > > 1280x720@50,tv_mode=hd720p
> > > > > and 60Hz would be hd720p60 or 1280x720@60,tv_mode=hd720p
> > > >
> > > > I disagree: hd720p50 and hd720p60 are different TV modes.
> > >
> > > I agree, and I don't see how that command-line doesn't express that?
> >
> > Oh, I see what you mean: yes, it expresses that.
> > But it is inconsistent with the NTSC/PAL/SECAM/hd{480,576}[ip] modes,
> > where the TV mode specifies both number of lines and frame rate.
>
> Only if we're using a named mode, and naming is hard :)
That's not true: "640x480,tv_mode=PAL-N" would give me a mode with
625 lines and 25 frames/s, "640x480,tv_mode=PAL-M" would give me a
mode with 525 lines and 30 frames/s.
> Honestly, I'd be inclined to drop the hd* for now from this series. I
> don't have a hardware to test it with, for some we don't even have
> drivers that could implement these modes, we don't have a spec to work
> from, it looks like a recipe for failure :)
OK.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v1 05/35] drm/connector: Add TV standard property
Den 17.08.2022 13.46, skrev Maxime Ripard: > On Tue, Aug 16, 2022 at 09:35:24PM +0200, Noralf Trønnes wrote: >> Den 16.08.2022 11.49, skrev Maxime Ripard: >>> On Tue, Aug 16, 2022 at 11:42:20AM +0200, Noralf Trønnes wrote: Den 16.08.2022 10.26, skrev Maxime Ripard: > Hi, > > On Mon, Aug 08, 2022 at 02:44:56PM +0200, Noralf Trønnes wrote: >> Den 29.07.2022 18.34, skrev Maxime Ripard: >>> The TV mode property has been around for a while now to select and get >>> the >>> current TV mode output on an analog TV connector. >>> >>> Despite that property name being generic, its content isn't and has been >>> driver-specific which makes it hard to build any generic behaviour on >>> top >>> of it, both in kernel and user-space. >>> >>> Let's create a new bitmask tv norm property, that can contain any of the >>> analog TV standards currently supported by kernel drivers. Each driver >>> can >>> then pass in a bitmask of the modes it supports. >>> >>> We'll then be able to phase out the older tv mode property. >>> >>> Signed-off-by: Maxime Ripard >>> >> >> Please also update Documentation/gpu/kms-properties.csv >> >> Requirements for adding a new property is found in >> Documentation/gpu/drm-kms.rst > > I knew this was going to be raised at some point, so I'm glad it's that > early :) > > I really don't know what to do there. If we stick by our usual rules, > then we can't have any of that work merged. > > However, I think the status quo is not really satisfactory either. > Indeed, we have a property, that doesn't follow those requirements > either, with a driver-specific content, and that stands in the way of > fixes and further improvements at both the core framework and driver > levels. > > So having that new property still seems like a net improvement at the > driver, framework and uAPI levels, even if it's not entirely following > the requirements we have in place. > > Even more so since, realistically, those kind of interfaces will never > get any new development on the user-space side of things, it's > considered by everyone as legacy. > > This also is something we need to support at some point if we want to > completely deprecate the fbdev drivers and provide decent alternatives > in KMS. > > So yeah, strictly speaking, we would not qualify for our requirements > there. I still think we have a strong case for an exception though. Which requirements would that be? The only one I can see is the documentation and maybe an IGT test. >>> >>> This is the one I had in mind >>> https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements >>> >> >> Oh right, I had forgotten about that one. >> >> One benefit of having a userspace implementation is that it increases >> the chance of widespread adoption having a working implementation to >> look at. I don't think the reason tv.mode is not used anywhere (that I >> know of) is because the driver picks the enum values resulting in no >> standard names. > > It probably doesn't help, but it's not what I was implying. > >> It's a niche thing and way down on the todo list. nouveau and ch7006 >> has a tv_norm module parameter which certainly doesn't help in moving >> people/projects over to the DRM property (downstream rpi also has it >> now). > > Yeah, the RPi version is part of the reason I started working on this. > We should also consider the named modes used by vc4 and sun4i. All these > ad-hoc solutions are limited and (I think) come from the fact that we > don't have a solution easy enough to use for drivers (and to discover). > > nouveau, ch7006, i915 and vc4 are using the tv.mode property for > example, but sun4i and meson don't. > > sun4i relies on named modes to reimplement TV modes, but meson doesn't > at all. > > And then nouveau has that extra command line parameter to set it up at > boot time. > > It doesn't really make much sense to me, when all drivers have very > similar needs, that none of them behave in the same way. And I think the > non-standard property is partly to blame for this, since without some > generic content we can't share code. > > This is what this series is about: every driver having similar > capabilities and as trivially as possible. > >> mpv[1] is a commandline media player that after a quick look might be a >> candidate for implementing the property without too much effort. > > Kodi might be another one. I can try to hack something around, but I'm > really skeptical about whether a PR would be merged or not. > You can ask first before wasting time ofc. But this baffles me, if you don't think projects like Kodi which is TV centered want this, what kind of projects do you think want to use this property? >> How do you test the property? I've used modetest but I c
Re: [PATCH v1 04/35] drm/modes: Introduce 480i and 576i modes
On Wed, Aug 17, 2022 at 10:51:55AM +0200, Geert Uytterhoeven wrote: > On Wed, Aug 17, 2022 at 9:54 AM Maxime Ripard wrote: > > On Tue, Aug 16, 2022 at 05:00:38PM +0200, Geert Uytterhoeven wrote: > > > On Tue, Aug 16, 2022 at 3:26 PM Maxime Ripard wrote: > > > > On Fri, Aug 12, 2022 at 03:18:58PM +0200, Geert Uytterhoeven wrote: > > > > > On Fri, Jul 29, 2022 at 6:35 PM Maxime Ripard > > > > > wrote: > > > > > > Multiple drivers (meson, vc4) define the analog TV 525-lines and > > > > > > 625-lines > > > > > > modes in the drivers. > > > > > > > > > > Nit: strictly speaking these are not analog modes, but the digital > > > > > variants (ITU-R BT.656 and DVD-Video D1) of NTSC and PAL, using a > > > > > 13.5 MHz sampling frequency for pixels. > > > > > > > > > > In analog modes, the only discrete values are the number of lines, and > > > > > the frame/field rate (fixing the horizontal sync rate when combined). > > > > > > > > > > The number of (in)visible pixels per line depends on the available > > > > > bandwidth. In a digital variant (which is anything generated by a > > > > > digital computer system), the latter depends on the pixel clock, which > > > > > can wildly differ from the 13.5 MHz used in the BT.656 standard. (e.g. > > > > > Amiga uses 7.09/14.19/28.38 MHz (PAL) or 7.16/14.32/28.64 MHz (NTSC)). > > > > > > > > > > So I think we probably need some way to generate a PAL/NTSC-compatible > > > > > mode based not only on resolution, but also on pixel clock. > > > > > > > > This would also fix the comments made by Jani and Thomas, so I quite > > > > like the idea of it. > > > > > > > > I'm struggling a bit to find how would could implement this though. > > > > > > > > From what you were saying, I guess the prototype would be something like > > > > > > > > struct drm_display_mode *drm_create_analog_mode(unsigned int > > > > pixel_clock, > > > > unsigned int lines, > > > > unsigned int frame_rate) > > > > > > > > But I have zero idea on what the implementation would be. Do you have > > > > some resources for this you could point me to? > > > > > > Horizontally, I think you should calculate left/right margins and > > > hsync length to yield timings that match those for the BT.656 PAL/NTSC > > > modes. I.e. when a 640x512 mode with a pixel clock of 14 MHz is > > > requested, you want to calculate left', right', and hslen' for > > > > > > | < left' ---> | <- 640 pixels -> | < right' ---> | <--- hslen' > > > --> | > > > @ 14 MHz > > > > > > so they match the timings for left, right, and hslen for > > > > > > | <--- left ---> | <--- 720 pixels ---> | <--- right ---> | <--- hslen > > > ---> | > > > @ 13.5 MHz > > > > > > As 640 pixels @ 14 MHz are less wide than 720 pixels @ 13.5 MHz, > > > you want to make sure to align the center of the visible part. > > > > So I guess in that example if we want to center it, left == right and > > left' == right'? What about the sync length? > > No, left and right are asymmetrical, cfr. front and back porch in > https://en.wikipedia.org/wiki/PAL#PAL_signal_details > I.e. if the pixel part is reduced, both the left and right margins > should be increased by the same amount. > > From the table linked above, hslen should be ca. 4.7µs (fixed). each pixel taking 1 / pixel_clock seconds (assuming pixel_clock is in Hz), and thus hslen (in pixels) = 4.7 * 10 ^ -6 * pixel_clk, right? > > > Vertically, it's simpler, as the number of lines is discrete. > > > You do have to take into account interlace and doublescan, and > > > progressive modes with 262/312 lines. > > > > So we only have to deal with 525 and 625 lines total (without taking > > interlace and doublescan into account), right? > > Yes. > > > I guess we still have the same question, we probably want to center it, > > so top == bottom, but what about the vsync length? > > Unfortunately that table does not mention top and bottom margins. > But according to drivers/video/fbdev/amifb.c (see the "Broadcast > video timings" comment block and the definitions of the "ntsc-lace" > and "pal-lace" video modes), they are asymmetrical, too. > > Vsync length is 0.576ms, so that's 9 scan lines (I guess I didn't > have that info when I wrote amifb, as I used 4 lines there). Thanks, that's some great info already. It's mentioned though that the settings for NTSC are "straightforward", but it's definitely not for me :) I've looked around and it looks like the entire blanking area is supposed to be 40 pixels in interlaced, but I couldn't find anywhere how it's supposed to be split between the upper and lower margins and the sync period. Thanks! Maxime signature.asc Description: PGP signature
Re: [PATCH v1 05/35] drm/connector: Add TV standard property
On Wed, Aug 17, 2022 at 03:05:52PM +0200, Geert Uytterhoeven wrote:
> Hi Maxime,
>
> On Wed, Aug 17, 2022 at 1:15 PM Maxime Ripard wrote:
> > On Wed, Aug 17, 2022 at 10:35:07AM +0200, Geert Uytterhoeven wrote:
> > > On Wed, Aug 17, 2022 at 9:47 AM Maxime Ripard wrote:
> > > > On Wed, Aug 17, 2022 at 09:31:18AM +0200, Geert Uytterhoeven wrote:
> > > > > On Tue, Aug 16, 2022 at 5:50 PM Maxime Ripard
> > > > > wrote:
> > > > > > On Tue, Aug 16, 2022 at 04:43:44PM +0200, Geert Uytterhoeven wrote:
> > > > > > > > > > > Either you have to add them here (e.g. "hd720p50" and
> > > > > > > > > > > "hd720p60"), or
> > > > > > > > > > > handle them through "@". The latter would
> > > > > > > > > > > impact "[PATCH v1
> > > > > > > > > > > 09/35] drm/modes: Move named modes parsing to a separate
> > > > > > > > > > > function", as
> > > > > > > > > > > currently a named mode and a refresh rate can't be
> > > > > > > > > > > specified both.
> > > > > > > > > >
> > > > > > > > > > I think the former would make more sense. It simplifies a
> > > > > > > > > > bit the
> > > > > > > > > > parser, and we're going to use a named mode anyway.
> > > > > > > > > >
> > > > > > > > > > > As "[PATCH v1 34/35] drm/modes: Introduce the tv_mode
> > > > > > > > > > > property as a
> > > > > > > > > > > command-line option" uses a separate "tv_mode" option,
> > > > > > > > > > > and not the main
> > > > > > > > > > > mode name, I think you want to add them here.
> > > > > > > > > >
> > > > > > > > > > It's a separate story I think, we could have a named mode
> > > > > > > > > > hd720p50,
> > > > > > > > > > which would be equivalent to 1280x720,tv_mode=hd720p
> > > > > > > > >
> > > > > > > > > So where's the field rate in "1280x720,tv_mode=hd720p"?
> > > > > > > >
> > > > > > > > Yeah, sorry I meant 1280x720@50,tv_mode=hd720p
> > > > > > >
> > > > > > > Above you said "I think the former would make more sense", so that
> > > > > > > should be "1280x720,tv_mode=hd720p50"?
> > > > > >
> > > > > > No, 720p at 50Hz would be either hd720p50 or
> > > > > > 1280x720@50,tv_mode=hd720p
> > > > > > and 60Hz would be hd720p60 or 1280x720@60,tv_mode=hd720p
> > > > >
> > > > > I disagree: hd720p50 and hd720p60 are different TV modes.
> > > >
> > > > I agree, and I don't see how that command-line doesn't express that?
> > >
> > > Oh, I see what you mean: yes, it expresses that.
> > > But it is inconsistent with the NTSC/PAL/SECAM/hd{480,576}[ip] modes,
> > > where the TV mode specifies both number of lines and frame rate.
> >
> > Only if we're using a named mode, and naming is hard :)
>
> That's not true: "640x480,tv_mode=PAL-N" would give me a mode with
> 625 lines and 25 frames/s, "640x480,tv_mode=PAL-M" would give me a
> mode with 525 lines and 30 frames/s.
In that series, "640x480,tv_mode=PAL-N" would be rejected as invalid:
https://lore.kernel.org/dri-devel/20220728-rpi-analog-tv-properties-v1-14-3d53ae722...@cerno.tech/
Maxime
signature.asc
Description: PGP signature
[PATCH 1/3] drm: rcar-du: remove unnecessary include
From: Tomi Valkeinen rcar_du_regs.h is not needed by rcar_du_drv.c so drop the include. Signed-off-by: Tomi Valkeinen --- drivers/gpu/drm/rcar-du/rcar_du_drv.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c b/drivers/gpu/drm/rcar-du/rcar_du_drv.c index 00ac233a115e..541c202c993a 100644 --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c @@ -27,7 +27,6 @@ #include "rcar_du_drv.h" #include "rcar_du_kms.h" -#include "rcar_du_regs.h" /* - * Device Information -- 2.34.1
[PATCH 2/3] drm: rcar-du: Fix r8a779a0 color issue.
From: Tomi Valkeinen
The rcar DU driver on r8a779a0 has a bug causing some specific colors
getting converted to transparent colors, which then (usually) show as
black pixels on the screen.
The reason seems to be that the driver sets PnMR_SPIM_ALP bit in
PnMR.SPIM field, which is an illegal setting on r8a779a0. The
PnMR_SPIM_EOR bit also illegal.
Add a new feature flag for this (lack of a) feature and make sure the
bits are zero on r8a779a0.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 3 ++-
drivers/gpu/drm/rcar-du/rcar_du_drv.h | 1 +
drivers/gpu/drm/rcar-du/rcar_du_plane.c | 16 +---
3 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index 541c202c993a..a2776f1d6f2c 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -506,7 +506,8 @@ static const struct rcar_du_device_info
rcar_du_r8a7799x_info = {
static const struct rcar_du_device_info rcar_du_r8a779a0_info = {
.gen = 3,
.features = RCAR_DU_FEATURE_CRTC_IRQ
- | RCAR_DU_FEATURE_VSP1_SOURCE,
+ | RCAR_DU_FEATURE_VSP1_SOURCE
+ | RCAR_DU_FEATURE_NO_BLENDING,
.channels_mask = BIT(1) | BIT(0),
.routes = {
/* R8A779A0 has two MIPI DSI outputs. */
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
index bfad7775d9a1..712389c7b3d0 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
@@ -31,6 +31,7 @@ struct rcar_du_device;
#define RCAR_DU_FEATURE_VSP1_SOURCEBIT(2) /* Has inputs from VSP1 */
#define RCAR_DU_FEATURE_INTERLACED BIT(3) /* HW supports interlaced */
#define RCAR_DU_FEATURE_TVM_SYNC BIT(4) /* Has TV switch/sync modes */
+#define RCAR_DU_FEATURE_NO_BLENDINGBIT(5) /* PnMR.SPIM does not have ALP
nor EOR bits */
#define RCAR_DU_QUIRK_ALIGN_128B BIT(0) /* Align pitches to 128 bytes */
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
index 9e1f0cbbf642..2103816807cc 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
@@ -506,8 +506,19 @@ static void rcar_du_plane_setup_format_gen3(struct
rcar_du_group *rgrp,
unsigned int index,
const struct rcar_du_plane_state
*state)
{
- rcar_du_plane_write(rgrp, index, PnMR,
- PnMR_SPIM_TP_OFF | state->format->pnmr);
+ struct rcar_du_device *rcdu = rgrp->dev;
+ u32 pnmr;
+
+ pnmr = state->format->pnmr;
+
+ if (rcdu->info->features & RCAR_DU_FEATURE_NO_BLENDING) {
+ /* No blending. ALP and EOR are not supported */
+ pnmr &= ~(PnMR_SPIM_ALP | PnMR_SPIM_EOR);
+ }
+
+ pnmr |= PnMR_SPIM_TP_OFF;
+
+ rcar_du_plane_write(rgrp, index, PnMR, pnmr);
rcar_du_plane_write(rgrp, index, PnDDCR4,
state->format->edf | PnDDCR4_CODE);
@@ -521,7 +532,6 @@ static void rcar_du_plane_setup_format_gen3(struct
rcar_du_group *rgrp,
* register to 0 to avoid this.
*/
- /* TODO: Check if alpha-blending should be disabled in PnMR. */
rcar_du_plane_write(rgrp, index, PnALPHAR, 0);
}
--
2.34.1
Re: [PATCH v2 1/3] dma-buf: Add ioctl to query mmap coherency/cache info
On Wed, Aug 17, 2022 at 2:57 AM Christian König wrote: > > > > Am 16.08.22 um 19:29 schrieb Rob Clark: > > On Tue, Aug 16, 2022 at 9:51 AM Christian König > > wrote: > >> Am 16.08.22 um 16:26 schrieb Rob Clark: > >>> On Tue, Aug 16, 2022 at 1:27 AM Christian König > >>> wrote: > Am 15.08.22 um 23:15 schrieb Rob Clark: > > From: Rob Clark > > > > This is a fairly narrowly focused interface, providing a way for a VMM > > in userspace to tell the guest kernel what pgprot settings to use when > > mapping a buffer to guest userspace. > > > > For buffers that get mapped into guest userspace, virglrenderer returns > > a dma-buf fd to the VMM (crosvm or qemu). In addition to mapping the > > pages into the guest VM, it needs to report to drm/virtio in the guest > > the cache settings to use for guest userspace. In particular, on some > > architectures, creating aliased mappings with different cache attributes > > is frowned upon, so it is important that the guest mappings have the > > same cache attributes as any potential host mappings. > > > > Signed-off-by: Rob Clark > > --- > > v2: Combine with coherency, as that is a related concept.. and it is > >relevant to the VMM whether coherent access without the SYNC > > ioctl > >is possible; set map_info at export time to make it more clear > >that it applies for the lifetime of the dma-buf (for any mmap > >created via the dma-buf) > Well, exactly that's a conceptual NAK from my side. > > The caching information can change at any time. For CPU mappings even > without further notice from the exporter. > >>> You should look before you criticize, as I left you a way out.. the > >>> idea was that DMA_BUF_MAP_INCOHERENT should indicate that the buffer > >>> cannot be mapped to the guest. We could ofc add more DMA_BUF_MAP_* > >>> values if something else would suit you better. But the goal is to > >>> give the VMM enough information to dtrt, or return an error if mapping > >>> to guest is not possible. That seems better than assuming mapping to > >>> guest will work and guessing about cache attrs > >> Well I'm not rejecting the implementation, I'm rejecting this from the > >> conceptual point of view. > >> > >> We intentional gave the exporter full control over the CPU mappings. > >> This approach here breaks that now. > >> > >> I haven't seen the full detailed reason why we should do that and to be > >> honest KVM seems to mess with things it is not supposed to touch. > >> > >> For example the page reference count of mappings marked with VM_IO is a > >> complete no-go. This is a very strong evidence that this was based on > >> rather dangerous halve knowledge about the background of the handling here. > >> > >> So as long as I don't see a full explanation why KVM is grabbing > >> reference to pages while faulting them and why we manually need to > >> forward the caching while the hardware documentation indicates otherwise > >> I will be rejecting this whole approach. > > Didn't we cover this on the previous iteration already. From a host > > kernel PoV these are just normal host userspace mappings. The > > userspace VMM mapping becomes the "physical address" in the guest and > > the stage 2 translation tables map it to the guest userspace. > > > > The resulting cache attrs from combination of S1 and S2 translation > > can differ. So ideally we setup the S2 pgtables in guest aligned with > > host userspace mappings > > Well exactly that is not very convincing. > > What you want to do is to use one channel for the address and a > different one for the cache attrs, that's not something I would > recommend doing in general. How would that work.. mmap() is the channel for the address, we'd need to introduce a new syscall that returned additional information? > Instead the client pgtables should be setup in a way so that host can > overwrite them. How? That is completely not how VMs work. Even if the host knew where the pgtables were and somehow magically knew the various guest userspace VAs, it would be racey. BR, -R > Regards, > Christian. > > > > > BR, > > -R > > > >> Regards, > >> Christian. > >> > >>> BR, > >>> -R > >>> > If the hardware can't use the caching information from the host CPU page > tables directly then that pretty much completely breaks the concept that > the exporter is responsible for setting up those page tables. > > Regards, > Christian. > > > drivers/dma-buf/dma-buf.c| 63 +++-- > > include/linux/dma-buf.h | 11 ++ > > include/uapi/linux/dma-buf.h | 68 > > > > 3 files changed, 132 insertions(+), 10 deletions(-) > > > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > > index 32f55640890c..262c4706f721 100644 > >
Re: [EXT] Re: [PATCH 1/3] dma-buf: heaps: add Linaro secure dmabuf heap support
On Tue, Aug 16, 2022 at 11:20:50AM +, Olivier Masse wrote:
> On ven., 2022-08-12 at 17:39 +0100, Brian Starkey wrote:
> > On Mon, Aug 08, 2022 at 02:39:53PM +, Olivier Masse wrote:
> > > On ven., 2022-08-05 at 16:41 +0100, Brian Starkey wrote:
> > > > On Fri, Aug 05, 2022 at 03:53:28PM +0200, Olivier Masse wrote:
.. snip
> > > > > +
> > > > > +static struct sg_table *secure_heap_map_dma_buf(struct
> > > > > dma_buf_attachment *attachment,
> > > > > + enum
> > > > > dma_data_direction direction)
> > > > > +{
> > > > > + struct secure_heap_attachment *a = attachment->priv;
> > > > > +
> > > > > + return a->table;
> > > >
> > > > I think you still need to implement mapping and unmapping using
> > > > the
> > > > DMA APIs. For example devices might be behind IOMMUs and the
> > > > buffer
> > > > will need mapping into the IOMMU.
> > >
> > > Devices that will need access to the buffer must be in secure.
> > > The tee driver will only need the scatter-list table to get dma
> > > address
> > > and len. Mapping will be done in the TEE.
> > > Please find tee_shm_register_fd in the following commit
> > >
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flinaro-swg%2Flinux%2Fcommit%2F41e21e5c405530590dc2dd10b2a8dbe64589840f&data=05%7C01%7Colivier.masse%40nxp.com%7C6b3d47f1e15c41a8cf7108da7c813ef6%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637959191795668899%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=OKZhaNevD5dj7Wjm6zbZlij0mPA9XYyio1NAN3VjTVM%3D&reserved=0
> > >
> > > This patch need to be up-streamed as well.
> > >
> >
> > Interesting, that's not how the devices I've worked on operated.
> >
> > Are you saying that you have to have a display controller driver
> > running in the TEE to display one of these buffers?
>
> In fact the display controller is managing 3 plans : UI, PiP and
> video. The video plan is protected in secure as you can see on slide
> 11:
> https://static.linaro.org/connect/san19/presentations/san19-107.pdf
>
> The DCSS (display controller) is able to read from the protected secure
> heap and composition result is send directly to the HDMI/HDCP port.
But it sounds like the DCSS driver is running in non-trusted Linux?
>
>
> > If everything
> > needs to be in the TEE, then why even have these buffers allocated
> > by non-secure Linux at all?
>
> The TEE is only doing decryption using the HW Crypto Accelerator
> (CAAM).
> The CAAM will read from a non protected encrypted buffer to write clear
> content to a secure buffer allocated with DMABUF and mapped in secure
> by OPTEE OS.
>
> >
> > I would have expected there to be HW enforcement of buffer access,
> > but for the display driver to be in non-secure Linux. That's how
> > TZMP1 works:
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstatic.linaro.org%2Fconnect%2Fhkg18%2Fpresentations%2Fhkg18-408.pdf&data=05%7C01%7Colivier.masse%40nxp.com%7C6b3d47f1e15c41a8cf7108da7c813ef6%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637959191795668899%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=XVpI93dXYu%2BGswLE8dcYboq%2FAWzSJn9j9LMlngpr238%3D&reserved=0
> >
> > Looking at this SDP presentation, that also seems to be the case
> > there:
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstatic.linaro.org%2Fconnect%2Fsan19%2Fpresentations%2Fsan19-107.pdf&data=05%7C01%7Colivier.masse%40nxp.com%7C6b3d47f1e15c41a8cf7108da7c813ef6%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637959191795668899%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=5Ec61NC1f0UQU%2F3BEURZQhEBrZ%2FuvJ1vaoSN4ChMn%2Bw%3D&reserved=0
> >
>
> Indeed, TZMP1 is similar to our implementation.
>
> > Based on those presentations, I think this heap should be
> > implementing
> > map_dma_buf in the "normal" way, using the DMA API to map the buffer
> > to the device. It's up to the TEE and HW firewall to prevent access
> > to those mappings from non-secure devices.
>
> In fact, our devices (VPU and DCSS) do not need any mapping, but only
> the physical address of buffers which need to be contiguous.
That's not how dma-buf or the DMA APIs work though - you should use
dma_map_sgtable and let the DMA API take care of whether a mapping
is needed or not.
> The VPU decoder, run by the CPU, read video meta data from a non
> protected buffer and send physical memory address of encoded buffer to
> the VPU HW.
> As well, the DCSS get physical address of contiguous decoded video
> buffer to do the composition.
>
Can you share the DCSS side of this? Maybe that will help to clear it
up.
Thanks,
-Brian
> >
> > My understanding is:
> >
> > * The memory region should never be mapped or accessed from the host
> > CPU. This is not a security requirement - the
Re: [PATCH v1 05/35] drm/connector: Add TV standard property
Hi Maxime,
On Wed, Aug 17, 2022 at 3:19 PM Maxime Ripard wrote:
> On Wed, Aug 17, 2022 at 03:05:52PM +0200, Geert Uytterhoeven wrote:
> > On Wed, Aug 17, 2022 at 1:15 PM Maxime Ripard wrote:
> > > On Wed, Aug 17, 2022 at 10:35:07AM +0200, Geert Uytterhoeven wrote:
> > > > On Wed, Aug 17, 2022 at 9:47 AM Maxime Ripard wrote:
> > > > > On Wed, Aug 17, 2022 at 09:31:18AM +0200, Geert Uytterhoeven wrote:
> > > > > > On Tue, Aug 16, 2022 at 5:50 PM Maxime Ripard
> > > > > > wrote:
> > > > > > > On Tue, Aug 16, 2022 at 04:43:44PM +0200, Geert Uytterhoeven
> > > > > > > wrote:
> > > > > > > > > > > > Either you have to add them here (e.g. "hd720p50" and
> > > > > > > > > > > > "hd720p60"), or
> > > > > > > > > > > > handle them through "@". The latter would
> > > > > > > > > > > > impact "[PATCH v1
> > > > > > > > > > > > 09/35] drm/modes: Move named modes parsing to a
> > > > > > > > > > > > separate function", as
> > > > > > > > > > > > currently a named mode and a refresh rate can't be
> > > > > > > > > > > > specified both.
> > > > > > > > > > >
> > > > > > > > > > > I think the former would make more sense. It simplifies a
> > > > > > > > > > > bit the
> > > > > > > > > > > parser, and we're going to use a named mode anyway.
> > > > > > > > > > >
> > > > > > > > > > > > As "[PATCH v1 34/35] drm/modes: Introduce the tv_mode
> > > > > > > > > > > > property as a
> > > > > > > > > > > > command-line option" uses a separate "tv_mode" option,
> > > > > > > > > > > > and not the main
> > > > > > > > > > > > mode name, I think you want to add them here.
> > > > > > > > > > >
> > > > > > > > > > > It's a separate story I think, we could have a named mode
> > > > > > > > > > > hd720p50,
> > > > > > > > > > > which would be equivalent to 1280x720,tv_mode=hd720p
> > > > > > > > > >
> > > > > > > > > > So where's the field rate in "1280x720,tv_mode=hd720p"?
> > > > > > > > >
> > > > > > > > > Yeah, sorry I meant 1280x720@50,tv_mode=hd720p
> > > > > > > >
> > > > > > > > Above you said "I think the former would make more sense", so
> > > > > > > > that
> > > > > > > > should be "1280x720,tv_mode=hd720p50"?
> > > > > > >
> > > > > > > No, 720p at 50Hz would be either hd720p50 or
> > > > > > > 1280x720@50,tv_mode=hd720p
> > > > > > > and 60Hz would be hd720p60 or 1280x720@60,tv_mode=hd720p
> > > > > >
> > > > > > I disagree: hd720p50 and hd720p60 are different TV modes.
> > > > >
> > > > > I agree, and I don't see how that command-line doesn't express that?
> > > >
> > > > Oh, I see what you mean: yes, it expresses that.
> > > > But it is inconsistent with the NTSC/PAL/SECAM/hd{480,576}[ip] modes,
> > > > where the TV mode specifies both number of lines and frame rate.
> > >
> > > Only if we're using a named mode, and naming is hard :)
> >
> > That's not true: "640x480,tv_mode=PAL-N" would give me a mode with
> > 625 lines and 25 frames/s, "640x480,tv_mode=PAL-M" would give me a
> > mode with 525 lines and 30 frames/s.
>
> In that series, "640x480,tv_mode=PAL-N" would be rejected as invalid:
>
> https://lore.kernel.org/dri-devel/20220728-rpi-analog-tv-properties-v1-14-3d53ae722...@cerno.tech/
It would become supported once the ideas from thread "[PATCH v1 04/35]
drm/modes: Introduce 480i and 576i modes" are implemented...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v1 04/35] drm/modes: Introduce 480i and 576i modes
Hi Maxime, On Wed, Aug 17, 2022 at 3:15 PM Maxime Ripard wrote: > On Wed, Aug 17, 2022 at 10:51:55AM +0200, Geert Uytterhoeven wrote: > > On Wed, Aug 17, 2022 at 9:54 AM Maxime Ripard wrote: > > > On Tue, Aug 16, 2022 at 05:00:38PM +0200, Geert Uytterhoeven wrote: > > > > On Tue, Aug 16, 2022 at 3:26 PM Maxime Ripard wrote: > > > > > On Fri, Aug 12, 2022 at 03:18:58PM +0200, Geert Uytterhoeven wrote: > > > > > > On Fri, Jul 29, 2022 at 6:35 PM Maxime Ripard > > > > > > wrote: > > > > > > > Multiple drivers (meson, vc4) define the analog TV 525-lines and > > > > > > > 625-lines > > > > > > > modes in the drivers. > > > > > > > > > > > > Nit: strictly speaking these are not analog modes, but the digital > > > > > > variants (ITU-R BT.656 and DVD-Video D1) of NTSC and PAL, using a > > > > > > 13.5 MHz sampling frequency for pixels. > > > > > > > > > > > > In analog modes, the only discrete values are the number of lines, > > > > > > and > > > > > > the frame/field rate (fixing the horizontal sync rate when > > > > > > combined). > > > > > > > > > > > > The number of (in)visible pixels per line depends on the available > > > > > > bandwidth. In a digital variant (which is anything generated by a > > > > > > digital computer system), the latter depends on the pixel clock, > > > > > > which > > > > > > can wildly differ from the 13.5 MHz used in the BT.656 standard. > > > > > > (e.g. > > > > > > Amiga uses 7.09/14.19/28.38 MHz (PAL) or 7.16/14.32/28.64 MHz > > > > > > (NTSC)). > > > > > > > > > > > > So I think we probably need some way to generate a > > > > > > PAL/NTSC-compatible > > > > > > mode based not only on resolution, but also on pixel clock. > > > > > > > > > > This would also fix the comments made by Jani and Thomas, so I quite > > > > > like the idea of it. > > > > > > > > > > I'm struggling a bit to find how would could implement this though. > > > > > > > > > > From what you were saying, I guess the prototype would be something > > > > > like > > > > > > > > > > struct drm_display_mode *drm_create_analog_mode(unsigned int > > > > > pixel_clock, > > > > > unsigned int lines, > > > > > unsigned int > > > > > frame_rate) > > > > > > > > > > But I have zero idea on what the implementation would be. Do you have > > > > > some resources for this you could point me to? > > > > > > > > Horizontally, I think you should calculate left/right margins and > > > > hsync length to yield timings that match those for the BT.656 PAL/NTSC > > > > modes. I.e. when a 640x512 mode with a pixel clock of 14 MHz is > > > > requested, you want to calculate left', right', and hslen' for > > > > > > > > | < left' ---> | <- 640 pixels -> | < right' ---> | <--- hslen' > > > > --> | > > > > @ 14 MHz > > > > > > > > so they match the timings for left, right, and hslen for > > > > > > > > | <--- left ---> | <--- 720 pixels ---> | <--- right ---> | <--- hslen > > > > ---> | > > > > @ 13.5 MHz > > > > > > > > As 640 pixels @ 14 MHz are less wide than 720 pixels @ 13.5 MHz, > > > > you want to make sure to align the center of the visible part. > > > > > > So I guess in that example if we want to center it, left == right and > > > left' == right'? What about the sync length? > > > > No, left and right are asymmetrical, cfr. front and back porch in > > https://en.wikipedia.org/wiki/PAL#PAL_signal_details > > I.e. if the pixel part is reduced, both the left and right margins > > should be increased by the same amount. > > > > From the table linked above, hslen should be ca. 4.7µs (fixed). > > each pixel taking 1 / pixel_clock seconds (assuming pixel_clock is in > Hz), and thus hslen (in pixels) = 4.7 * 10 ^ -6 * pixel_clk, right? Exactly. > > > > Vertically, it's simpler, as the number of lines is discrete. > > > > You do have to take into account interlace and doublescan, and > > > > progressive modes with 262/312 lines. > > > > > > So we only have to deal with 525 and 625 lines total (without taking > > > interlace and doublescan into account), right? > > > > Yes. > > > > > I guess we still have the same question, we probably want to center it, > > > so top == bottom, but what about the vsync length? > > > > Unfortunately that table does not mention top and bottom margins. > > But according to drivers/video/fbdev/amifb.c (see the "Broadcast > > video timings" comment block and the definitions of the "ntsc-lace" > > and "pal-lace" video modes), they are asymmetrical, too. > > > > Vsync length is 0.576ms, so that's 9 scan lines (I guess I didn't > > have that info when I wrote amifb, as I used 4 lines there). > > Thanks, that's some great info already. > > It's mentioned though that the settings for NTSC are "straightforward", > but it's definitely not for me :) As in NTSC just uses different pixel clock and horizontal/vertical sync rate values... > I've looked a
Re: [PATCH v2 4/7] regulator: core: Allow specifying an initial load w/ the bulk API
Hi,
On Tue, Aug 16, 2022 at 5:58 AM Yongqin Liu wrote:
>
> HI, Douglas
>
> With this change, I get one kernel panic with my hikey960
> android-mainline based Android build,
> if it's reverted, then the build could boot to the home screen successfully.
> From the log information I shared here, not sure if you have any idea
> what I could do to have the hikey960
> build work with this change,
>
> The kernel panic is something like this, for details, please check the
> log here: http://ix.io/47Lq
>
> [ 10.738042][ T193] adv7511 1-0039: error : Failed
> to get supply 'v1p2'
> [ 10.748457][ T194] apexd: Found pre-installed APEX
> /system/apex/com.android.os.statsd.apex
> [ 10.752908][ T67] Unable to handle kernel read from unreadable
> memory at virtual address 004c
> [ 10.753116][T8] Unable to handle kernel read from unreadable
> memory at virtual address 0078
> [ 10.753130][T8] Mem abort info:
> [ 10.753135][T8] ESR = 0x9605
> [ 10.753142][T8] EC = 0x25: DABT (current EL), IL = 32 bits
> [ 10.753152][T8] SET = 0, FnV = 0
> [ 10.753159][T8] EA = 0, S1PTW = 0
> [ 10.753166][T8] FSC = 0x05: level 1 translation fault
> [ 10.753174][T8] Data abort info:
> [ 10.753179][T8] ISV = 0, ISS = 0x0005
> [ 10.753184][T8] CM = 0, WnR = 0
> [ 10.753192][T8] user pgtable: 4k pages, 39-bit VAs,
> pgdp=03098000
> [ 10.753204][T8] [0078] pgd=,
> p4d=, pud=
> [ 10.753232][T8] Internal error: Oops: 9605 [#1] PREEMPT SMP
> [ 10.753245][T8] Modules linked in: adv7511(E+) tcpci_rt1711h(E)
> hci_uart(E) btqca(E) btbcm(E) cpufreq_dt(E) hi3660_i2s(E)
> hisi_hikey_usb(E) hi6421_pmic_core(E) syscon_reboot_mode(E)
> reboot_mode(E) hi3660_mailbox(E) dw_mmc_k3(E) hisi_thermal(E)
> dw_mmc_pltfm(E) dw_mmc(E) kirin_drm(E) snd_soc_simple_card(E)
> snd_soc_simple_card_utils(E) spi_pl022(E) kirin_dsi(E)
> phy_hi3660_usb3(E) i2c_designware_platform(E) drm_cma_helper(E)
> i2c_designware_core(E) mali_kbase(OE) k3dma(E) cma_heap(E)
> system_heap(E)
> [ 10.753436][T8] CPU: 2 PID: 8 Comm: kworker/u16:0 Tainted: G
>OE 5.19.0-mainline-03487-g86d047950300-dirty #1
> [ 10.753454][T8] Hardware name: HiKey960 (DT)
> [ 10.753463][T8] Workqueue: events_unbound async_run_entry_fn
> [ 10.753497][T8] pstate: 6045 (nZCv daif +PAN -UAO -TCO -DIT
> -SSBS BTYPE=--)
> [ 10.753516][T8] pc : regulator_bulk_enable_async+0x3c/0x98
> [ 10.753540][T8] lr : async_run_entry_fn+0x30/0xf8
> [ 10.753559][T8] sp : ffc009ed3d20
> [ 10.753567][T8] x29: ffc009ed3d40 x28: 0402
> x27: ff801ad99828
> [ 10.753592][T8] x26: ff803217b010 x25: 0002
> x24: ff8003385da8
> [ 10.753617][T8] x23: ff8003385da0 x22: ff801ad94805
> x21: ff8003385da0
> [ 10.753642][T8] x20: x19: ff8003143d20
> x18: ffc008075028
> [ 10.753667][T8] x17: 00040044 x16: 0001
> x15: 0010
> [ 10.753691][T8] x14: x13: 0f58
> x12: 8235
> [ 10.753715][T8] x11: 6acfbfa2f400 x10: 0016 x9
> : 00ff
> [ 10.753740][T8] x8 : da9ecda1b63b0500 x7 : 8080 x6
> :
> [ 10.753764][T8] x5 : 0001 x4 : 646e756f626e x3
> : ff801ad99828
> [ 10.753788][T8] x2 : ff8003385da8 x1 : ffc009ed3d20 x0
> : ff8003143d20
> [ 10.753812][T8] Call trace:
> [ 10.753818][T8] regulator_bulk_enable_async+0x3c/0x98
> [ 10.753839][T8] async_run_entry_fn+0x30/0xf8
> [ 10.753859][T8] process_one_work+0x1d0/0x404
> [ 10.753879][T8] worker_thread+0x25c/0x43c
> [ 10.753897][T8] kthread+0xf0/0x2c0
> [ 10.753912][T8] ret_from_fork+0x10/0x20
> [ 10.753940][T8] Code: f81f83a8 f9400814 a900 f90003ff (f9403e95)
> [ 10.753950][T8] ---[ end trace ]---
> [ 10.760621][ T194] apexd: Found pre-installed APEX
> /system/apex/com.android.permission.capex
> [ 10.767672][ T67] Mem abort info:
> [ 10.779658][ T194] apexd: Found pre-installed APEX
> /system/apex/com.android.art.capex
> [ 10.783690][ T67] ESR = 0x9605
> [ 10.792424][ T194] apexd: Found pre-installed APEX
> /system/apex/com.android.scheduling.capex
> [ 10.794713][T8] Kernel panic - not syncing: Oops: Fatal exception
> [ 10.794723][T8] SMP: stopping secondary CPUs
> [ 10.798141][T8] Kernel Offset: 0x7 from 0xffc00800
> [ 10.798150][T8] PHYS_OFFSET: 0x0
> [ 10.798156][T8] CPU features: 0x,00649020,1086
> [ 10.798167][T8] Memory Limit: none
Are you fixed by the patch ("regulator: core: Fix missing error return
from regulator_bulk_get()") [1]
[1]
https://lore.kernel.org/
Re: [EXT] Re: [PATCH 1/3] dma-buf: heaps: add Linaro secure dmabuf heap support
Hi Folks, Le mardi 16 août 2022 à 11:20 +, Olivier Masse a écrit : > Hi Brian, > > > On ven., 2022-08-12 at 17:39 +0100, Brian Starkey wrote: > > Caution: EXT Ema > > [...] > > > > Interesting, that's not how the devices I've worked on operated. > > > > Are you saying that you have to have a display controller driver > > running in the TEE to display one of these buffers? > > In fact the display controller is managing 3 plans : UI, PiP and > video. The video plan is protected in secure as you can see on slide > 11: > https://static.linaro.org/connect/san19/presentations/san19-107.pdf just wanted to highlight that all the WPE/GStreamer bit in this presentation is based on NXP Vendor Media CODEC design, which rely on their own i.MX VPU API. I don't see any effort to extend this to a wider audience. It is not explaining how this can work with a mainline kernel with v4l2 stateful or stateless drivers and generic GStreamer/FFMPEG/Chromium support. I'm raising this, since I'm worried that no one cares of solving that high level problem from a generic point of view. In that context, any additions to the mainline Linux kernel can only be flawed and will only serves specific vendors and not the larger audience. Another aspect, is that this design might be bound to a specific (NXP ?) security design. I've learn recently that newer HW is going to use multiple level of MMU (like virtual machines do) to protect the memory rather then marking pages. Will all this work for that too ? regards, Nicolas
Re: [EXT] Re: [PATCH 1/3] dma-buf: heaps: add Linaro secure dmabuf heap support
+Cyrille Hi Nicolas, On mer., 2022-08-17 at 10:29 -0400, Nicolas Dufresne wrote: > Caution: EXT Email > > Hi Folks, > > Le mardi 16 août 2022 à 11:20 +, Olivier Masse a écrit : > > Hi Brian, > > > > > > On ven., 2022-08-12 at 17:39 +0100, Brian Starkey wrote: > > > Caution: EXT Ema > > > > > [...] > > > > > > > Interesting, that's not how the devices I've worked on operated. > > > > > > Are you saying that you have to have a display controller driver > > > running in the TEE to display one of these buffers? > > > > In fact the display controller is managing 3 plans : UI, PiP and > > video. The video plan is protected in secure as you can see on > > slide > > 11: > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstatic.linaro.org%2Fconnect%2Fsan19%2Fpresentations%2Fsan19-107.pdf&data=05%7C01%7Colivier.masse%40nxp.com%7Ce0e00be789a54dff8e5208da805ce2f6%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637963433695707516%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=GHjEfbgqRkfHK16oyNaYJob4LRVqvoffRElKR%2F7Rtes%3D&reserved=0 > > > > just wanted to highlight that all the WPE/GStreamer bit in this > presentation is > based on NXP Vendor Media CODEC design, which rely on their own i.MX > VPU API. I > don't see any effort to extend this to a wider audience. It is not > explaining > how this can work with a mainline kernel with v4l2 stateful or > stateless drivers > and generic GStreamer/FFMPEG/Chromium support. Maybe Cyrille can explain what it is currently done at NXP level regarding the integration of v4l2 with NXP VPU. > > I'm raising this, since I'm worried that no one cares of solving that > high level > problem from a generic point of view. In that context, any additions > to the > mainline Linux kernel can only be flawed and will only serves > specific vendors > and not the larger audience. > > Another aspect, is that this design might be bound to a specific (NXP > ?) > security design. I've learn recently that newer HW is going to use > multiple > level of MMU (like virtual machines do) to protect the memory rather > then > marking pages. Will all this work for that too ? our fire-walling hardware is protecting memory behind the MMU and so rely on physical memory layout. this work is only relying on a reserved physical memory. Regards, Olivier > > regards, > Nicolas
Re: [PATCH v2 01/29] ACPI: video: Add acpi_video_backlight_use_native() helper
Hi Daniel,
On 8/2/22 18:49, Daniel Dadap wrote:
> On 8/2/22 06:31, Hans de Goede wrote:
>> Hi Daniel,
>>
>> On 7/21/22 23:30, Daniel Dadap wrote:
>>> On 7/21/22 16:24, Daniel Dadap wrote:
On 7/12/22 14:38, Hans de Goede wrote:
> ATM on x86 laptops where we want userspace to use the acpi_video backlight
> device we often register both the GPU's native backlight device and
> acpi_video's firmware acpi_video# backlight device. This relies on
> userspace preferring firmware type backlight devices over native ones, but
> registering 2 backlight devices for a single display really is
> undesirable.
>
> On x86 laptops where the native GPU backlight device should be used,
> the registering of other backlight devices is avoided by their drivers
> using acpi_video_get_backlight_type() and only registering their backlight
> if the return value matches their type.
>
> acpi_video_get_backlight_type() uses
> backlight_device_get_by_type(BACKLIGHT_RAW) to determine if a native
> driver is available and will never return native if this returns
> false. This means that the GPU's native backlight registering code
> cannot just call acpi_video_get_backlight_type() to determine if it
> should register its backlight, since acpi_video_get_backlight_type() will
> never return native until the native backlight has already registered.
>
> To fix this add a new internal native function parameter to
> acpi_video_get_backlight_type(), which when set to true will make
> acpi_video_get_backlight_type() behave as if a native backlight has
> already been registered.
>
> And add a new acpi_video_backlight_use_native() helper, which sets this
> to true, for use in native GPU backlight code.
>
> Changes in v2:
> - Replace adding a native parameter to acpi_video_get_backlight_type()
> with
> adding a new acpi_video_backlight_use_native() helper.
>
> Signed-off-by: Hans de Goede
> ---
> drivers/acpi/video_detect.c | 24
> include/acpi/video.h | 5 +
> 2 files changed, 25 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
> index becc198e4c22..4346c990022d 100644
> --- a/drivers/acpi/video_detect.c
> +++ b/drivers/acpi/video_detect.c
> @@ -17,8 +17,9 @@
> * Otherwise vendor specific drivers like thinkpad_acpi, asus-laptop,
> * sony_acpi,... can take care about backlight brightness.
> *
> - * Backlight drivers can use acpi_video_get_backlight_type() to determine
> - * which driver should handle the backlight.
> + * Backlight drivers can use acpi_video_get_backlight_type() to
> determine which
> + * driver should handle the backlight. RAW/GPU-driver backlight drivers
> must
> + * use the acpi_video_backlight_use_native() helper for this.
> *
> * If CONFIG_ACPI_VIDEO is neither set as "compiled in" (y) nor as a
> module (m)
> * this file will not be compiled and acpi_video_get_backlight_type()
> will
> @@ -548,9 +549,10 @@ static int acpi_video_backlight_notify(struct
> notifier_block *nb,
> * Arguably the native on win8 check should be done first, but that
> would
> * be a behavior change, which may causes issues.
> */
> -enum acpi_backlight_type acpi_video_get_backlight_type(void)
> +static enum acpi_backlight_type __acpi_video_get_backlight_type(bool
> native)
> {
> static DEFINE_MUTEX(init_mutex);
> + static bool native_available;
> static bool init_done;
> static long video_caps;
> @@ -570,6 +572,8 @@ enum acpi_backlight_type
> acpi_video_get_backlight_type(void)
> backlight_notifier_registered = true;
> init_done = true;
> }
> + if (native)
> + native_available = true;
> mutex_unlock(&init_mutex);
> if (acpi_backlight_cmdline != acpi_backlight_undef)
> @@ -581,13 +585,25 @@ enum acpi_backlight_type
> acpi_video_get_backlight_type(void)
> if (!(video_caps & ACPI_VIDEO_BACKLIGHT))
> return acpi_backlight_vendor;
> - if (acpi_osi_is_win8() &&
> backlight_device_get_by_type(BACKLIGHT_RAW))
> + if (acpi_osi_is_win8() &&
> + (native_available ||
> backlight_device_get_by_type(BACKLIGHT_RAW)))
> return acpi_backlight_native;
> return acpi_backlight_video;
So I ran into a minor problem when testing the NVIDIA proprietary driver
against this change set, after checking acpi_video_backlight_use_native()
before registering the NVIDIA proprietary driver's backlight handler.
Namely, for the case where a user installs the NVIDIA proprietary driver
after the vide
Re: [BUG][5.20] refcount_t: underflow; use-after-free
On 08/17, Mikhail Gavrilov wrote: > On Mon, Aug 15, 2022 at 3:37 PM Mikhail Gavrilov > wrote: > > > > Thanks, I tested this patch. > > But with this patch use-after-free problem happening in another place: > > Does anyone have an idea why the second use-after-free happened? > From the trace I don't understand which code is related. > I don't quite understand what the "Workqueue" entry in the trace means. Hi Mikhail, IIUC, you got this second user-after-free by applying the first version of Maíra's patch, right? So, that version was adding another unbalanced unlock to the cs ioctl flow, but it was solved in the latest version, that you can find here: https://patchwork.freedesktop.org/patch/497680/ If this is the situation, can you check this last version? Thanks, Melissa > > [ 408.358737] [ cut here ] > [ 408.358743] refcount_t: underflow; use-after-free. > [ 408.358760] WARNING: CPU: 9 PID: 62 at lib/refcount.c:28 > refcount_warn_saturate+0xba/0x110 > [ 408.358769] Modules linked in: uinput snd_seq_dummy rfcomm > snd_hrtimer nft_objref nf_conntrack_netbios_ns nf_conntrack_broadcast > nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet > nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat > nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables nfnetlink > qrtr bnep sunrpc binfmt_misc snd_seq_midi snd_seq_midi_event mt76x2u > mt76x2_common snd_hda_codec_realtek mt76x02_usb snd_hda_codec_generic > iwlmvm snd_hda_codec_hdmi mt76_usb intel_rapl_msr snd_hda_intel > mt76x02_lib intel_rapl_common snd_intel_dspcfg snd_intel_sdw_acpi mt76 > snd_hda_codec vfat fat snd_usb_audio snd_hda_core edac_mce_amd > mac80211 snd_usbmidi_lib snd_hwdep snd_rawmidi mc snd_seq btusb > kvm_amd iwlwifi snd_seq_device btrtl btbcm libarc4 btintel eeepc_wmi > snd_pcm iwlmei kvm btmtk asus_wmi ledtrig_audio irqbypass joydev > snd_timer sparse_keymap bluetooth platform_profile rapl cfg80211 snd > video wmi_bmof soundcore i2c_piix4 k10temp rfkill mei > [ 408.358853] asus_ec_sensors acpi_cpufreq zram hid_logitech_hidpp > amdgpu igb dca drm_ttm_helper ttm iommu_v2 crct10dif_pclmul gpu_sched > crc32_pclmul ucsi_ccg crc32c_intel drm_buddy nvme typec_ucsi > drm_display_helper ghash_clmulni_intel ccp typec nvme_core sp5100_tco > cec wmi ip6_tables ip_tables fuse > [ 408.358880] Unloaded tainted modules: amd64_edac():1 amd64_edac():1 > amd64_edac():1 amd64_edac():1 amd64_edac():1 amd64_edac():1 > amd64_edac():1 amd64_edac():1 amd64_edac():1 amd64_edac():1 > pcc_cpufreq():1 amd64_edac():1 pcc_cpufreq():1 pcc_cpufreq():1 > amd64_edac():1 amd64_edac():1 pcc_cpufreq():1 amd64_edac():1 > pcc_cpufreq():1 amd64_edac():1 pcc_cpufreq():1 amd64_edac():1 > pcc_cpufreq():1 pcc_cpufreq():1 amd64_edac():1 pcc_cpufreq():1 > amd64_edac():1 pcc_cpufreq():1 amd64_edac():1 pcc_cpufreq():1 > pcc_cpufreq():1 amd64_edac():1 amd64_edac():1 pcc_cpufreq():1 > pcc_cpufreq():1 amd64_edac():1 pcc_cpufreq():1 amd64_edac():1 > pcc_cpufreq():1 amd64_edac():1 pcc_cpufreq():1 pcc_cpufreq():1 > amd64_edac():1 pcc_cpufreq():1 amd64_edac():1 pcc_cpufreq():1 > amd64_edac():1 pcc_cpufreq():1 pcc_cpufreq():1 amd64_edac():1 > pcc_cpufreq():1 amd64_edac():1 amd64_edac():1 pcc_cpufreq():1 > amd64_edac():1 pcc_cpufreq():1 amd64_edac():1 pcc_cpufreq():1 > pcc_cpufreq():1 pcc_cpufreq():1 fjes():1 pcc_cpufreq():1 fjes():1 > [ 408.358953] pcc_cpufreq():1 pcc_cpufreq():1 fjes():1 pcc_cpufreq():1 > fjes():1 fjes():1 fjes():1 fjes():1 fjes():1 > [ 408.358967] CPU: 9 PID: 62 Comm: kworker/9:0 Tainted: G W L --- > --- 6.0.0-0.rc1.13.fc38.x86_64+debug #1 > [ 408.358971] Hardware name: System manufacturer System Product > Name/ROG STRIX X570-I GAMING, BIOS 4403 04/27/2022 > [ 408.358974] Workqueue: events drm_sched_entity_kill_jobs_work [gpu_sched] > [ 408.358982] RIP: 0010:refcount_warn_saturate+0xba/0x110 > [ 408.358987] Code: 01 01 e8 d9 59 6f 00 0f 0b e9 a2 46 a5 00 80 3d 3e > 7e be 01 00 75 85 48 c7 c7 70 99 8e 92 c6 05 2e 7e be 01 01 e8 b6 59 > 6f 00 <0f> 0b e9 7f 46 a5 00 80 3d 19 7e be 01 00 0f 85 5e ff ff ff 48 > c7 > [ 408.358990] RSP: 0018:b124003efe60 EFLAGS: 00010286 > [ 408.358994] RAX: 0026 RBX: 9987a025d428 RCX: > > [ 408.358997] RDX: 0001 RSI: 928d0754 RDI: > > [ 408.358999] RBP: 9994e4ff5600 R08: R09: > b124003efd10 > [ 408.359001] R10: 0003 R11: 99952e2fffe8 R12: > 9994e4ffc800 > [ 408.359004] R13: 998600228cc0 R14: 9994e4ffc805 R15: > 9987a025d430 > [ 408.359006] FS: () GS:9994e4e0() > knlGS: > [ 408.359009] CS: 0010 DS: ES: CR0: 80050033 > [ 408.359012] CR2: 27ac39e78000 CR3: 0001a66d8000 CR4: > 00350ee0 > [ 408.359015] Call Trace: > [ 408.359017] > [ 408.359020] process_one_work+0x2a0/0x600 > [ 408.359032] worker_thread+0x4f/0x3a0 > [ 408.359036] ? process_one_work+0x600/0x600 > [ 408.359039]
[PATCH 1/4] dma-buf: Add dma_buf_try_get()
Used to increment the refcount of the dma buf's struct file, only if the
refcount is not zero. Useful to allow the struct file's lifetime to
control the lifetime of the dmabuf while still letting the driver to keep
track of created dmabufs.
Signed-off-by: Jason Gunthorpe
---
include/linux/dma-buf.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index 71731796c8c3a8..a35f1554f2fb36 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -618,6 +618,19 @@ int dma_buf_fd(struct dma_buf *dmabuf, int flags);
struct dma_buf *dma_buf_get(int fd);
void dma_buf_put(struct dma_buf *dmabuf);
+/**
+ * dma_buf_try_get - try to get a reference on a dmabuf
+ * @dmabuf - the dmabuf to get
+ *
+ * Returns true if a reference was successfully obtained. The caller must
+ * interlock with the dmabuf's release function in some way, such as RCU, to
+ * ensure that this is not called on freed memory.
+ */
+static inline bool dma_buf_try_get(struct dma_buf *dmabuf)
+{
+ return get_file_rcu(dmabuf->file);
+}
+
struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *,
enum dma_data_direction);
void dma_buf_unmap_attachment(struct dma_buf_attachment *, struct sg_table *,
--
2.37.2
[PATCH 0/4] Allow MMIO regions to be exported through dma-buf
dma-buf has become a way to safely acquire a handle to non-struct page memory that can still have lifetime controlled by the exporter. Notably RDMA can now import dma-buf FDs and build them into MRs which allows for PCI P2P operations. Extend this to allow vfio-pci to export MMIO memory from PCI device BARs. This series supports a use case for SPDK where a NVMe device will be owned by SPDK through VFIO but interacting with a RDMA device. The RDMA device may directly access the NVMe CMB or directly manipulate the NVMe device's doorbell using PCI P2P. However, as a general mechanism, it can support many other scenarios with VFIO. I imagine this dmabuf approach to be usable by iommufd as well for generic and safe P2P mappings. This series goes after the "Break up ioctl dispatch functions to one function per ioctl" series. This is on github: https://github.com/jgunthorpe/linux/commits/vfio_dma_buf Jason Gunthorpe (4): dma-buf: Add dma_buf_try_get() vfio: Add vfio_device_get() vfio_pci: Do not open code pci_try_reset_function() vfio/pci: Allow MMIO regions to be exported through dma-buf drivers/vfio/pci/Makefile | 1 + drivers/vfio/pci/vfio_pci_config.c | 22 ++- drivers/vfio/pci/vfio_pci_core.c| 33 +++- drivers/vfio/pci/vfio_pci_dma_buf.c | 265 drivers/vfio/pci/vfio_pci_priv.h| 24 +++ drivers/vfio/vfio_main.c| 3 +- include/linux/dma-buf.h | 13 ++ include/linux/vfio.h| 6 + include/linux/vfio_pci_core.h | 1 + include/uapi/linux/vfio.h | 18 ++ 10 files changed, 364 insertions(+), 22 deletions(-) create mode 100644 drivers/vfio/pci/vfio_pci_dma_buf.c base-commit: 385f0411fcd2780b5273992832cdc8edcd5b8ea9 -- 2.37.2
[PATCH 2/4] vfio: Add vfio_device_get()
To increment a reference the caller already holds. Export
vfio_device_put() to pair with it.
Signed-off-by: Jason Gunthorpe
---
drivers/vfio/vfio_main.c | 3 ++-
include/linux/vfio.h | 6 ++
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
index 6f96e6d07a5e98..5ad50aec7dc94c 100644
--- a/drivers/vfio/vfio_main.c
+++ b/drivers/vfio/vfio_main.c
@@ -451,11 +451,12 @@ static void vfio_group_get(struct vfio_group *group)
* Device objects - create, release, get, put, search
*/
/* Device reference always implies a group reference */
-static void vfio_device_put(struct vfio_device *device)
+void vfio_device_put(struct vfio_device *device)
{
if (refcount_dec_and_test(&device->refcount))
complete(&device->comp);
}
+EXPORT_SYMBOL_GPL(vfio_device_put);
static bool vfio_device_try_get(struct vfio_device *device)
{
diff --git a/include/linux/vfio.h b/include/linux/vfio.h
index e05ddc6fe6a556..25850b1e08cba9 100644
--- a/include/linux/vfio.h
+++ b/include/linux/vfio.h
@@ -143,6 +143,12 @@ void vfio_uninit_group_dev(struct vfio_device *device);
int vfio_register_group_dev(struct vfio_device *device);
int vfio_register_emulated_iommu_dev(struct vfio_device *device);
void vfio_unregister_group_dev(struct vfio_device *device);
+void vfio_device_put(struct vfio_device *device);
+
+static inline void vfio_device_get(struct vfio_device *device)
+{
+ refcount_inc(&device->refcount);
+}
int vfio_assign_device_set(struct vfio_device *device, void *set_id);
--
2.37.2
[PATCH 4/4] vfio/pci: Allow MMIO regions to be exported through dma-buf
dma-buf has become a way to safely acquire a handle to non-struct page
memory that can still have lifetime controlled by the exporter. Notably
RDMA can now import dma-buf FDs and build them into MRs which allows for
PCI P2P operations. Extend this to allow vfio-pci to export MMIO memory
from PCI device BARs.
The patch design loosely follows the pattern in commit
db1a8dd916aa ("habanalabs: add support for dma-buf exporter") except this
does not support pinning.
Instead, this implements what, in the past, we've called a revocable
attachment using move. In normal situations the attachment is pinned, as a
BAR does not change physical address. However when the VFIO device is
closed, or a PCI reset is issued, access to the MMIO memory is revoked.
Revoked means that move occurs, but an attempt to immediately re-map the
memory will fail. In the reset case a future move will be triggered when
MMIO access returns. As both close and reset are under userspace control
it is expected that userspace will suspend use of the dma-buf before doing
these operations, the revoke is purely for kernel self-defense against a
hostile userspace.
Signed-off-by: Jason Gunthorpe
---
drivers/vfio/pci/Makefile | 1 +
drivers/vfio/pci/vfio_pci_config.c | 8 +-
drivers/vfio/pci/vfio_pci_core.c| 28 ++-
drivers/vfio/pci/vfio_pci_dma_buf.c | 265
drivers/vfio/pci/vfio_pci_priv.h| 23 +++
include/linux/vfio_pci_core.h | 1 +
include/uapi/linux/vfio.h | 18 ++
7 files changed, 336 insertions(+), 8 deletions(-)
create mode 100644 drivers/vfio/pci/vfio_pci_dma_buf.c
diff --git a/drivers/vfio/pci/Makefile b/drivers/vfio/pci/Makefile
index 24c524224da5a3..81006a157cde14 100644
--- a/drivers/vfio/pci/Makefile
+++ b/drivers/vfio/pci/Makefile
@@ -2,6 +2,7 @@
vfio-pci-core-y := vfio_pci_core.o vfio_pci_intrs.o vfio_pci_rdwr.o
vfio_pci_config.o
vfio-pci-core-$(CONFIG_VFIO_PCI_ZDEV_KVM) += vfio_pci_zdev.o
+vfio-pci-core-$(CONFIG_DMA_SHARED_BUFFER) += vfio_pci_dma_buf.o
obj-$(CONFIG_VFIO_PCI_CORE) += vfio-pci-core.o
vfio-pci-y := vfio_pci.o
diff --git a/drivers/vfio/pci/vfio_pci_config.c
b/drivers/vfio/pci/vfio_pci_config.c
index d22921efa25987..f8a9c24d04aeb7 100644
--- a/drivers/vfio/pci/vfio_pci_config.c
+++ b/drivers/vfio/pci/vfio_pci_config.c
@@ -584,10 +584,12 @@ static int vfio_basic_config_write(struct
vfio_pci_core_device *vdev, int pos,
virt_mem = !!(le16_to_cpu(*virt_cmd) & PCI_COMMAND_MEMORY);
new_mem = !!(new_cmd & PCI_COMMAND_MEMORY);
- if (!new_mem)
+ if (!new_mem) {
vfio_pci_zap_and_down_write_memory_lock(vdev);
- else
+ vfio_pci_dma_buf_move(vdev, true);
+ } else {
down_write(&vdev->memory_lock);
+ }
/*
* If the user is writing mem/io enable (new_mem/io) and we
@@ -622,6 +624,8 @@ static int vfio_basic_config_write(struct
vfio_pci_core_device *vdev, int pos,
*virt_cmd &= cpu_to_le16(~mask);
*virt_cmd |= cpu_to_le16(new_cmd & mask);
+ if (__vfio_pci_memory_enabled(vdev))
+ vfio_pci_dma_buf_move(vdev, false);
up_write(&vdev->memory_lock);
}
diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c
index d13e22021860cc..206f159c480e42 100644
--- a/drivers/vfio/pci/vfio_pci_core.c
+++ b/drivers/vfio/pci/vfio_pci_core.c
@@ -504,6 +504,8 @@ void vfio_pci_core_close_device(struct vfio_device
*core_vdev)
vfio_spapr_pci_eeh_release(vdev->pdev);
vfio_pci_core_disable(vdev);
+ vfio_pci_dma_buf_cleanup(vdev);
+
mutex_lock(&vdev->igate);
if (vdev->err_trigger) {
eventfd_ctx_put(vdev->err_trigger);
@@ -980,7 +982,10 @@ int vfio_pci_try_reset_function(struct
vfio_pci_core_device *vdev)
*/
vfio_pci_set_power_state(vdev, PCI_D0);
+ vfio_pci_dma_buf_move(vdev, true);
ret = pci_try_reset_function(vdev->pdev);
+ if (__vfio_pci_memory_enabled(vdev))
+ vfio_pci_dma_buf_move(vdev, false);
up_write(&vdev->memory_lock);
return ret;
@@ -1210,11 +1215,10 @@ long vfio_pci_core_ioctl(struct vfio_device *core_vdev,
unsigned int cmd,
}
EXPORT_SYMBOL_GPL(vfio_pci_core_ioctl);
-static int vfio_pci_core_feature_token(struct vfio_device *device, u32 flags,
- uuid_t __user *arg, size_t argsz)
+static int vfio_pci_core_feature_token(struct vfio_pci_core_device *vdev,
+ u32 flags, uuid_t __user *arg,
+ size_t argsz)
{
- struct vfio_pci_core_device *vdev =
- container_of(device, struct vfio_pci_core_device, vdev);
uuid_t uuid;
int ret;
@@ -1241,9 +1245,14 @@ static int vfio_pci_core_f
[PATCH 3/4] vfio_pci: Do not open code pci_try_reset_function()
FLR triggered by an emulated config space write should not behave
differently from a FLR triggered by VFIO_DEVICE_RESET, currently the
config space path misses the power management.
Consolidate all the call sites to invoke a single function.
Signed-off-by: Jason Gunthorpe
---
drivers/vfio/pci/vfio_pci_config.c | 14 --
drivers/vfio/pci/vfio_pci_core.c | 5 ++---
drivers/vfio/pci/vfio_pci_priv.h | 1 +
3 files changed, 7 insertions(+), 13 deletions(-)
diff --git a/drivers/vfio/pci/vfio_pci_config.c
b/drivers/vfio/pci/vfio_pci_config.c
index 4a350421c5f62a..d22921efa25987 100644
--- a/drivers/vfio/pci/vfio_pci_config.c
+++ b/drivers/vfio/pci/vfio_pci_config.c
@@ -893,11 +893,8 @@ static int vfio_exp_config_write(struct
vfio_pci_core_device *vdev, int pos,
pos - offset + PCI_EXP_DEVCAP,
&cap);
- if (!ret && (cap & PCI_EXP_DEVCAP_FLR)) {
- vfio_pci_zap_and_down_write_memory_lock(vdev);
- pci_try_reset_function(vdev->pdev);
- up_write(&vdev->memory_lock);
- }
+ if (!ret && (cap & PCI_EXP_DEVCAP_FLR))
+ vfio_pci_try_reset_function(vdev);
}
/*
@@ -975,11 +972,8 @@ static int vfio_af_config_write(struct
vfio_pci_core_device *vdev, int pos,
pos - offset + PCI_AF_CAP,
&cap);
- if (!ret && (cap & PCI_AF_CAP_FLR) && (cap & PCI_AF_CAP_TP)) {
- vfio_pci_zap_and_down_write_memory_lock(vdev);
- pci_try_reset_function(vdev->pdev);
- up_write(&vdev->memory_lock);
- }
+ if (!ret && (cap & PCI_AF_CAP_FLR) && (cap & PCI_AF_CAP_TP))
+ vfio_pci_try_reset_function(vdev);
}
return count;
diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c
index 050b9d4b8c290c..d13e22021860cc 100644
--- a/drivers/vfio/pci/vfio_pci_core.c
+++ b/drivers/vfio/pci/vfio_pci_core.c
@@ -960,8 +960,7 @@ static int vfio_pci_ioctl_set_irqs(struct
vfio_pci_core_device *vdev,
return ret;
}
-static int vfio_pci_ioctl_reset(struct vfio_pci_core_device *vdev,
- void __user *arg)
+int vfio_pci_try_reset_function(struct vfio_pci_core_device *vdev)
{
int ret;
@@ -1202,7 +1201,7 @@ long vfio_pci_core_ioctl(struct vfio_device *core_vdev,
unsigned int cmd,
case VFIO_DEVICE_PCI_HOT_RESET:
return vfio_pci_ioctl_pci_hot_reset(vdev, uarg);
case VFIO_DEVICE_RESET:
- return vfio_pci_ioctl_reset(vdev, uarg);
+ return vfio_pci_try_reset_function(vdev);
case VFIO_DEVICE_SET_IRQS:
return vfio_pci_ioctl_set_irqs(vdev, uarg);
default:
diff --git a/drivers/vfio/pci/vfio_pci_priv.h b/drivers/vfio/pci/vfio_pci_priv.h
index 58b8d34c162cd6..5b1cb9a9838442 100644
--- a/drivers/vfio/pci/vfio_pci_priv.h
+++ b/drivers/vfio/pci/vfio_pci_priv.h
@@ -60,6 +60,7 @@ void vfio_config_free(struct vfio_pci_core_device *vdev);
int vfio_pci_set_power_state(struct vfio_pci_core_device *vdev,
pci_power_t state);
+int vfio_pci_try_reset_function(struct vfio_pci_core_device *vdev);
bool __vfio_pci_memory_enabled(struct vfio_pci_core_device *vdev);
void vfio_pci_zap_and_down_write_memory_lock(struct vfio_pci_core_device
*vdev);
u16 vfio_pci_memory_lock_and_enable(struct vfio_pci_core_device *vdev);
--
2.37.2
Re: [EXT] Re: [PATCH 1/3] dma-buf: heaps: add Linaro secure dmabuf heap support
Am Mittwoch, dem 17.08.2022 um 10:29 -0400 schrieb Nicolas Dufresne: > Hi Folks, > > Le mardi 16 août 2022 à 11:20 +, Olivier Masse a écrit : > > Hi Brian, > > > > > > On ven., 2022-08-12 at 17:39 +0100, Brian Starkey wrote: > > > Caution: EXT Ema > > > > > [...] > > > > > > > Interesting, that's not how the devices I've worked on operated. > > > > > > Are you saying that you have to have a display controller driver > > > running in the TEE to display one of these buffers? > > > > In fact the display controller is managing 3 plans : UI, PiP and > > video. The video plan is protected in secure as you can see on slide > > 11: > > https://static.linaro.org/connect/san19/presentations/san19-107.pdf > > > > just wanted to highlight that all the WPE/GStreamer bit in this presentation > is > based on NXP Vendor Media CODEC design, which rely on their own i.MX VPU API. > I > don't see any effort to extend this to a wider audience. It is not explaining > how this can work with a mainline kernel with v4l2 stateful or stateless > drivers > and generic GStreamer/FFMPEG/Chromium support. > > I'm raising this, since I'm worried that no one cares of solving that high > level > problem from a generic point of view. In that context, any additions to the > mainline Linux kernel can only be flawed and will only serves specific vendors > and not the larger audience. > > Another aspect, is that this design might be bound to a specific (NXP ?) > security design. I've learn recently that newer HW is going to use multiple > level of MMU (like virtual machines do) to protect the memory rather then > marking pages. Will all this work for that too ? > I have not looked in any of this for quite a while, but IIRC the plan was something like that: The NXP RDC hardware is able to segment the DDR memory into sections and define access policies for all masters in the system. So for example for the secure VPU to display controller path you would define such a section, where only the VPU is able to write and DCSS is able to read from. CPU or other masters are not allowed to use this section. This then gets exposed to Linux as a DMA heap. The VPU driver could then allocate capture buffers from this heap and share them via dma-buf to the DCSS driver. Both drivers can live in non-trusted userspace and even the address allocation for the DMA heap can be done from Linux. Non-trusted Linux kernel/userspace just has no way to access the buffers directly. The more interesting question is on the VPU side: how do you make sure that the capture buffer is located in secure memory when the output buffer containing the secret bitstream is also in a secure heap? I guess you need some kind of TEE application to validate those settings, which means you can't give the non-trusted driver direct MMIO access to the VPU. Regards, Lucas
[linux-next:master] BUILD SUCCESS WITH WARNING 95d10484d66e54d5c01e36389e9318221fb8f60b
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master branch HEAD: 95d10484d66e54d5c01e36389e9318221fb8f60b Add linux-next specific files for 20220817 Warning reports: https://lore.kernel.org/linux-doc/202208162058.7appivkl-...@intel.com https://lore.kernel.org/llvm/202207251313.gkhpeleq-...@intel.com Warning: (recently discovered and may have been fixed) Warning: MAINTAINERS references a file that doesn't exist: Documentation/devicetree/bindings/gpio/gpio-xilinx.txt drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_plane.c:1046:5: warning: no previous prototype for 'fill_dc_scaling_info' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_plane.c:1222:6: warning: no previous prototype for 'handle_cursor_update' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_plane.c:152:6: warning: no previous prototype for 'modifier_has_dcc' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_plane.c:1576:5: warning: no previous prototype for 'amdgpu_dm_plane_init' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_plane.c:157:10: warning: no previous prototype for 'modifier_gfx9_swizzle_mode' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_plane.c:752:5: warning: no previous prototype for 'fill_plane_buffer_attributes' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_plane.c:83:31: warning: no previous prototype for 'amd_get_format_info' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_plane.c:88:6: warning: no previous prototype for 'fill_blending_from_plane_state' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_plane.c:992:5: warning: no previous prototype for 'dm_plane_helper_check_state' [-Wmissing-prototypes] drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c:905:28: warning: variable 'top' set but not used [-Wunused-but-set-variable] drivers/iio/accel/bma400_core.c:1091 bma400_activity_event_en() error: uninitialized symbol 'field_value'. drivers/iio/cdc/ad7746.c:336:14: warning: use of uninitialized value '' [CWE-457] [-Wanalyzer-use-of-uninitialized-value] drivers/platform/mellanox/mlxreg-lc.c:866 mlxreg_lc_probe() warn: passing zero to 'PTR_ERR' mm/memory_hotplug.c:343 __add_pages() error: uninitialized symbol 'err'. Warning ids grouped by kconfigs: gcc_recent_errors |-- alpha-allyesconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm_plane.c:warning:no-previous-prototype-for-amd_get_format_info | |-- drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm_plane.c:warning:no-previous-prototype-for-amdgpu_dm_plane_init | |-- drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm_plane.c:warning:no-previous-prototype-for-dm_plane_helper_check_state | |-- drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm_plane.c:warning:no-previous-prototype-for-fill_blending_from_plane_state | |-- drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm_plane.c:warning:no-previous-prototype-for-fill_dc_scaling_info | |-- drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm_plane.c:warning:no-previous-prototype-for-fill_plane_buffer_attributes | |-- drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm_plane.c:warning:no-previous-prototype-for-handle_cursor_update | |-- drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm_plane.c:warning:no-previous-prototype-for-modifier_gfx9_swizzle_mode | |-- drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm_plane.c:warning:no-previous-prototype-for-modifier_has_dcc | `-- drivers-gpu-drm-msm-disp-dpu1-dpu_kms.c:warning:variable-top-set-but-not-used |-- alpha-randconfig-c023-20220815 | |-- drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm_plane.c:warning:no-previous-prototype-for-amd_get_format_info | |-- drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm_plane.c:warning:no-previous-prototype-for-amdgpu_dm_plane_init | |-- drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm_plane.c:warning:no-previous-prototype-for-dm_plane_helper_check_state | |-- drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm_plane.c:warning:no-previous-prototype-for-fill_blending_from_plane_state | |-- drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm_plane.c:warning:no-previous-prototype-for-fill_dc_scaling_info | |-- drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm_plane.c:warning:no-previous-prototype-for-fill_plane_buffer_attributes | |-- drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm_plane.c:warning:no-previous-prototype-for-handle_cursor_update | |-- drivers-gpu-drm-amd-amdgpu-..-display-
Re: [PATCH v2 4/7] regulator: core: Allow specifying an initial load w/ the bulk API
Hi, Douglas On Wed, 17 Aug 2022 at 22:26, Doug Anderson wrote: > > Hi, > > On Tue, Aug 16, 2022 at 5:58 AM Yongqin Liu wrote: > > > > HI, Douglas > > > > With this change, I get one kernel panic with my hikey960 > > android-mainline based Android build, > > if it's reverted, then the build could boot to the home screen successfully. > > From the log information I shared here, not sure if you have any idea > > what I could do to have the hikey960 > > build work with this change, > > > > The kernel panic is something like this, for details, please check the > > log here: http://ix.io/47Lq > > > > [ 10.738042][ T193] adv7511 1-0039: error : Failed > > to get supply 'v1p2' > > [ 10.748457][ T194] apexd: Found pre-installed APEX > > /system/apex/com.android.os.statsd.apex > > [ 10.752908][ T67] Unable to handle kernel read from unreadable > > memory at virtual address 004c > > [ 10.753116][T8] Unable to handle kernel read from unreadable > > memory at virtual address 0078 > > [ 10.753130][T8] Mem abort info: > > [ 10.753135][T8] ESR = 0x9605 > > [ 10.753142][T8] EC = 0x25: DABT (current EL), IL = 32 bits > > [ 10.753152][T8] SET = 0, FnV = 0 > > [ 10.753159][T8] EA = 0, S1PTW = 0 > > [ 10.753166][T8] FSC = 0x05: level 1 translation fault > > [ 10.753174][T8] Data abort info: > > [ 10.753179][T8] ISV = 0, ISS = 0x0005 > > [ 10.753184][T8] CM = 0, WnR = 0 > > [ 10.753192][T8] user pgtable: 4k pages, 39-bit VAs, > > pgdp=03098000 > > [ 10.753204][T8] [0078] pgd=, > > p4d=, pud= > > [ 10.753232][T8] Internal error: Oops: 9605 [#1] PREEMPT SMP > > [ 10.753245][T8] Modules linked in: adv7511(E+) tcpci_rt1711h(E) > > hci_uart(E) btqca(E) btbcm(E) cpufreq_dt(E) hi3660_i2s(E) > > hisi_hikey_usb(E) hi6421_pmic_core(E) syscon_reboot_mode(E) > > reboot_mode(E) hi3660_mailbox(E) dw_mmc_k3(E) hisi_thermal(E) > > dw_mmc_pltfm(E) dw_mmc(E) kirin_drm(E) snd_soc_simple_card(E) > > snd_soc_simple_card_utils(E) spi_pl022(E) kirin_dsi(E) > > phy_hi3660_usb3(E) i2c_designware_platform(E) drm_cma_helper(E) > > i2c_designware_core(E) mali_kbase(OE) k3dma(E) cma_heap(E) > > system_heap(E) > > [ 10.753436][T8] CPU: 2 PID: 8 Comm: kworker/u16:0 Tainted: G > >OE 5.19.0-mainline-03487-g86d047950300-dirty #1 > > [ 10.753454][T8] Hardware name: HiKey960 (DT) > > [ 10.753463][T8] Workqueue: events_unbound async_run_entry_fn > > [ 10.753497][T8] pstate: 6045 (nZCv daif +PAN -UAO -TCO -DIT > > -SSBS BTYPE=--) > > [ 10.753516][T8] pc : regulator_bulk_enable_async+0x3c/0x98 > > [ 10.753540][T8] lr : async_run_entry_fn+0x30/0xf8 > > [ 10.753559][T8] sp : ffc009ed3d20 > > [ 10.753567][T8] x29: ffc009ed3d40 x28: 0402 > > x27: ff801ad99828 > > [ 10.753592][T8] x26: ff803217b010 x25: 0002 > > x24: ff8003385da8 > > [ 10.753617][T8] x23: ff8003385da0 x22: ff801ad94805 > > x21: ff8003385da0 > > [ 10.753642][T8] x20: x19: ff8003143d20 > > x18: ffc008075028 > > [ 10.753667][T8] x17: 00040044 x16: 0001 > > x15: 0010 > > [ 10.753691][T8] x14: x13: 0f58 > > x12: 8235 > > [ 10.753715][T8] x11: 6acfbfa2f400 x10: 0016 x9 > > : 00ff > > [ 10.753740][T8] x8 : da9ecda1b63b0500 x7 : 8080 x6 > > : > > [ 10.753764][T8] x5 : 0001 x4 : 646e756f626e x3 > > : ff801ad99828 > > [ 10.753788][T8] x2 : ff8003385da8 x1 : ffc009ed3d20 x0 > > : ff8003143d20 > > [ 10.753812][T8] Call trace: > > [ 10.753818][T8] regulator_bulk_enable_async+0x3c/0x98 > > [ 10.753839][T8] async_run_entry_fn+0x30/0xf8 > > [ 10.753859][T8] process_one_work+0x1d0/0x404 > > [ 10.753879][T8] worker_thread+0x25c/0x43c > > [ 10.753897][T8] kthread+0xf0/0x2c0 > > [ 10.753912][T8] ret_from_fork+0x10/0x20 > > [ 10.753940][T8] Code: f81f83a8 f9400814 a900 f90003ff (f9403e95) > > [ 10.753950][T8] ---[ end trace ]--- > > [ 10.760621][ T194] apexd: Found pre-installed APEX > > /system/apex/com.android.permission.capex > > [ 10.767672][ T67] Mem abort info: > > [ 10.779658][ T194] apexd: Found pre-installed APEX > > /system/apex/com.android.art.capex > > [ 10.783690][ T67] ESR = 0x9605 > > [ 10.792424][ T194] apexd: Found pre-installed APEX > > /system/apex/com.android.scheduling.capex > > [ 10.794713][T8] Kernel panic - not syncing: Oops: Fatal exception > > [ 10.794723][T8] SMP: stopping secondary CPUs > > [ 10.798141][T8] Kernel Offset: 0x7 from 0xffc00800 > > [ 10.798150][T8]
Re: [PATCH v2 16/29] ACPI: video: Add Nvidia WMI EC brightness control detection
On 8/17/22 7:22 AM, Hans de Goede wrote:
Hi Daniel,
On 7/15/22 13:59, Hans de Goede wrote:
Hi Daniel,
On 7/12/22 22:13, Daniel Dadap wrote:
Thanks, Hans:
On 7/12/22 14:38, Hans de Goede wrote:
On some new laptop designs a new Nvidia specific WMI interface is present
which gives info about panel brightness control and may allow controlling
the brightness through this interface when the embedded controller is used
for brightness control.
When this WMI interface is present and indicates that the EC is used,
then this interface should be used for brightness control.
Signed-off-by: Hans de Goede
---
drivers/acpi/Kconfig | 1 +
drivers/acpi/video_detect.c | 35 ++
drivers/gpu/drm/gma500/Kconfig | 2 ++
drivers/gpu/drm/i915/Kconfig | 2 ++
include/acpi/video.h | 1 +
5 files changed, 41 insertions(+)
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 1e34f846508f..c372385cfc3f 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -212,6 +212,7 @@ config ACPI_VIDEO
tristate "Video"
depends on X86 && BACKLIGHT_CLASS_DEVICE
depends on INPUT
+ depends on ACPI_WMI
select THERMAL
help
This driver implements the ACPI Extensions For Display Adapters
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 8c2863403040..7b89dc9a04a2 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -75,6 +75,35 @@ find_video(acpi_handle handle, u32 lvl, void *context, void
**rv)
return AE_OK;
}
+#define WMI_BRIGHTNESS_METHOD_SOURCE 2
+#define WMI_BRIGHTNESS_MODE_GET 0
+#define WMI_BRIGHTNESS_SOURCE_EC 2
+
+struct wmi_brightness_args {
+ u32 mode;
+ u32 val;
+ u32 ret;
+ u32 ignored[3];
+};
+
+static bool nvidia_wmi_ec_supported(void)
+{
+ struct wmi_brightness_args args = {
+ .mode = WMI_BRIGHTNESS_MODE_GET,
+ .val = 0,
+ .ret = 0,
+ };
+ struct acpi_buffer buf = { (acpi_size)sizeof(args), &args };
+ acpi_status status;
+
+ status = wmi_evaluate_method("603E9613-EF25-4338-A3D0-C46177516DB7", 0,
+ WMI_BRIGHTNESS_METHOD_SOURCE, &buf, &buf);
+ if (ACPI_FAILURE(status))
+ return false;
+
+ return args.ret == WMI_BRIGHTNESS_SOURCE_EC;
+}
+
The code duplication here with nvidia-wmi-ec-backlight.c is a little
unfortunate. Can we move the constants, struct definition, and WMI GUID from
that file to a header file that's used both by the EC backlight driver and the
ACPI video driver?
Yes that is a good idea. I suggest using
include/linux/platform_data/x86/nvidia-wmi-ec-backlight.h
to move the shared definitions there.
If you can submit 2 patches on top of this series:
1. Moving the definitions from drivers/platform/x86/nvidia-wmi-ec-backlight.c to
include/linux/platform_data/x86/nvidia-wmi-ec-backlight.h
2. Switching the code from this patch over to using the new
nvidia-wmi-ec-backlight.h
Then for the next version I'll add patch 1. to the series and squash patch 2.
into this one.
Note: I'm preparing a v3 of the series and I've made these changes myself now.
Okay, thanks. Sorry, I had started on this but then got distracted by
other work.
I was thinking it might be nice to add a wrapper around wmi_brightness_notify()
in nvidia-wmi-ec-backlight.c that does this source == WMI_BRIGHTNESS_SOURCE_EC
test, and then export it so that it can be called both here and in the EC
backlight driver's probe routine, but then I guess that would make video.ko
depend on nvidia-wmi-ec-backlight.ko, which seems wrong. It also seems wrong to
implement the WMI plumbing in the ACPI video driver, and export it so that the
EC backlight driver can use it, so I guess I can live with the duplication of
the relatively simple WMI stuff here, it would just be nice to not have to
define all of the API constants, structure, and GUID twice.
Agreed.
/* Force to use vendor driver when the ACPI device is known to be
* buggy */
static int video_detect_force_vendor(const struct dmi_system_id *d)
@@ -518,6 +547,7 @@ static const struct dmi_system_id video_detect_dmi_table[]
= {
static enum acpi_backlight_type __acpi_video_get_backlight_type(bool native)
{
static DEFINE_MUTEX(init_mutex);
+ static bool nvidia_wmi_ec_present;
static bool native_available;
static bool init_done;
static long video_caps;
@@ -530,6 +560,7 @@ static enum acpi_backlight_type
__acpi_video_get_backlight_type(bool native)
acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT,
ACPI_UINT32_MAX, find_video, NULL,
&video_caps, NULL);
+ nvidia_wmi_ec_present = nvidia_wmi_ec_supported();
init_done = true;
}
if (native)
@@ -547,6 +578,10 @@ static enum acpi_backlight_type
__acpi_video_get_backlight_type(bool native)
Re: [BUG][5.20] refcount_t: underflow; use-after-free
On Wed, Aug 17, 2022 at 9:08 PM Melissa Wen wrote: > > Hi Mikhail, > > IIUC, you got this second user-after-free by applying the first version > of Maíra's patch, right? So, that version was adding another unbalanced > unlock to the cs ioctl flow, but it was solved in the latest version, > that you can find here: https://patchwork.freedesktop.org/patch/497680/ > If this is the situation, can you check this last version? > > Thanks, > > Melissa With the last version warning "bad unlock balance detected!" was gone, but the user-after-free issue remains. And again "Workqueue: events drm_sched_entity_kill_jobs_work [gpu_sched]". [ 297.834779] [ cut here ] [ 297.834818] refcount_t: underflow; use-after-free. [ 297.834831] WARNING: CPU: 30 PID: 2377 at lib/refcount.c:28 refcount_warn_saturate+0xba/0x110 [ 297.834838] Modules linked in: uinput rfcomm snd_seq_dummy snd_hrtimer nft_objref nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables nfnetlink qrtr bnep sunrpc binfmt_misc snd_seq_midi snd_seq_midi_event mt76x2u mt76x2_common mt76x02_usb mt76_usb mt76x02_lib snd_hda_codec_realtek iwlmvm intel_rapl_msr snd_hda_codec_generic snd_hda_codec_hdmi mt76 vfat fat snd_hda_intel intel_rapl_common mac80211 snd_intel_dspcfg snd_intel_sdw_acpi snd_usb_audio snd_hda_codec snd_usbmidi_lib btusb edac_mce_amd iwlwifi libarc4 uvcvideo snd_hda_core btrtl snd_rawmidi snd_hwdep videobuf2_vmalloc btbcm kvm_amd videobuf2_memops snd_seq iwlmei btintel videobuf2_v4l2 eeepc_wmi snd_seq_device videobuf2_common btmtk kvm xpad videodev joydev irqbypass snd_pcm asus_wmi hid_logitech_hidpp ff_memless cfg80211 bluetooth rapl mc [ 297.834932] ledtrig_audio snd_timer sparse_keymap platform_profile wmi_bmof snd video pcspkr k10temp i2c_piix4 rfkill soundcore mei asus_ec_sensors acpi_cpufreq zram amdgpu drm_ttm_helper ttm crct10dif_pclmul crc32_pclmul crc32c_intel iommu_v2 ucsi_ccg gpu_sched typec_ucsi drm_buddy ghash_clmulni_intel drm_display_helper ccp igb typec sp5100_tco nvme cec nvme_core dca wmi ip6_tables ip_tables fuse [ 297.834978] Unloaded tainted modules: amd64_edac():1 amd64_edac():1 amd64_edac():1 amd64_edac():1 amd64_edac():1 amd64_edac():1 amd64_edac():1 amd64_edac():1 pcc_cpufreq():1 amd64_edac():1 pcc_cpufreq():1 amd64_edac():1 pcc_cpufreq():1 pcc_cpufreq():1 amd64_edac():1 amd64_edac():1 pcc_cpufreq():1 amd64_edac():1 pcc_cpufreq():1 amd64_edac():1 pcc_cpufreq():1 amd64_edac():1 pcc_cpufreq():1 pcc_cpufreq():1 amd64_edac():1 amd64_edac():1 pcc_cpufreq():1 pcc_cpufreq():1 amd64_edac():1 pcc_cpufreq():1 pcc_cpufreq():1 amd64_edac():1 pcc_cpufreq():1 amd64_edac():1 pcc_cpufreq():1 pcc_cpufreq():1 amd64_edac():1 pcc_cpufreq():1 amd64_edac():1 amd64_edac():1 pcc_cpufreq():1 amd64_edac():1 pcc_cpufreq():1 amd64_edac():1 pcc_cpufreq():1 pcc_cpufreq():1 amd64_edac():1 amd64_edac():1 pcc_cpufreq():1 pcc_cpufreq():1 amd64_edac():1 pcc_cpufreq():1 amd64_edac():1 amd64_edac():1 pcc_cpufreq():1 amd64_edac():1 pcc_cpufreq():1 amd64_edac():1 pcc_cpufreq():1 pcc_cpufreq():1 pcc_cpufreq():1 fjes():1 [ 297.835055] pcc_cpufreq():1 fjes():1 pcc_cpufreq():1 fjes():1 pcc_cpufreq():1 fjes():1 fjes():1 fjes():1 fjes():1 fjes():1 [ 297.835071] CPU: 30 PID: 2377 Comm: kworker/30:6 Tainted: G WL--- --- 6.0.0-0.rc1.20220817git3cc40a443a04.14.fc38.x86_64 #1 [ 297.835075] Hardware name: System manufacturer System Product Name/ROG STRIX X570-I GAMING, BIOS 4403 04/27/2022 [ 297.835078] Workqueue: events drm_sched_entity_kill_jobs_work [gpu_sched] [ 297.835085] RIP: 0010:refcount_warn_saturate+0xba/0x110 [ 297.835088] Code: 01 01 e8 59 59 6f 00 0f 0b e9 22 46 a5 00 80 3d be 7d be 01 00 75 85 48 c7 c7 c0 99 8e aa c6 05 ae 7d be 01 01 e8 36 59 6f 00 <0f> 0b e9 ff 45 a5 00 80 3d 99 7d be 01 00 0f 85 5e ff ff ff 48 c7 [ 297.835091] RSP: 0018:bd3506df7e60 EFLAGS: 00010286 [ 297.835095] RAX: 0026 RBX: 961b250cbc28 RCX: [ 297.835097] RDX: 0001 RSI: aa8d07a4 RDI: [ 297.835100] RBP: 96276a3f5600 R08: R09: bd3506df7d10 [ 297.835102] R10: 0003 R11: 9627ae2fffe8 R12: 96276a3fc800 [ 297.835105] R13: 9618c03e6600 R14: 96276a3fc805 R15: 961b250cbc30 [ 297.835108] FS: () GS:96276a20() knlGS: [ 297.835110] CS: 0010 DS: ES: CR0: 80050033 [ 297.835113] CR2: 621001e4a000 CR3: 00018d958000 CR4: 00350ee0 [ 297.835116] Call Trace: [ 297.835118] [ 297.835121] process_one_work+0x2a0/0x600 [ 297.835133] worker_thread+0x4f/0x3a0 [ 297.835139] ? process_one_work+0x600/0x600 [ 297.835142] kthread+0xf5/0x120 [ 297.835145] ? kthread_complete_and_exit+0x20/0x20 [ 297.835151] ret_from_fork+0x22/0x30 [ 297.835166] [
Re: [PATCH] drm/i915: Switch TGL-H DP-IN to dGFX when it's supported
Adding Mark Pearson from Lenovo to this, Mark for reference the original patch is here: https://patchwork.freedesktop.org/patch/497807/?series=107312&rev=1 Comments from me down below On Wed, 2022-08-17 at 09:02 +0800, Kai-Heng Feng wrote: > On Wed, Aug 17, 2022 at 2:24 AM Lyude Paul wrote: > > > > On Tue, 2022-08-16 at 19:29 +0800, Kai-Heng Feng wrote: > > > On Tue, Aug 16, 2022 at 4:06 PM Jani Nikula > > > wrote: > > > > > > > > On Tue, 16 Aug 2022, Kai-Heng Feng wrote: > > > > > On mobile workstations like HP ZBook Fury G8, iGFX's DP-IN can switch > > > > > to > > > > > dGFX so external monitors are routed to dGFX, and more monitors can be > > > > > supported as result. > > > > > > > > > > To switch the DP-IN to dGFX, the driver needs to invoke _DSM function > > > > > 20 > > > > > on intel_dsm_guid2. This method is described in Intel document 632107. > > > > Is this documentation released anywhere? We've been wondering about these > > interfaces for quite a long time, and it would be good to know if there's > > docs > > for this we haven't really been seeing. > > > > > > > > > > Is this the policy decision that we want to unconditionally make, > > > > though? > > > > > > I believes so, so more external monitors can be supported at the same > > > time. > > > > > > Kai-Heng > > > > Is this for systems with dual Intel GPUs? I ask because if this affects > > Intel/Nvidia hybrid systems then this is a huge no from me. Nouveau is able > > to > > support these systems, but at a limited capacity. This would imply that we > > are > > making external displays work for users of the nvidia proprietary driver, at > > the expense making external display support for mainline kernel users > > substantially worse for people who are using the mainline kernel. Which > > isn't > > a choice we should be making, because nvidia's OOT driver is not a mainline > > kernel driver. > > Yes it's for Intel/NVIDIA hybrid systems. > > The problem is that hardware vendor design the systems to use NVIDIA > for external displays, so using external displays on Intel are never > tested by the vendors. > I don't think that's any good either. > Sigh, the constant forcing of nvidia hardware into laptops from vendors is seriously something I wish they would knock it off with considering they're basically the most difficult hardware vendor to work with. Anyway, if we -need- to route displays through the external GPU then we can. But I'd like to at least get convinced first that this is an actual necessity we should expect for multiple vendors, or the exception to the rule. Because if these laptops are capable of driving displays through Intel, at the moment not doing that is a huge downgrade in terms of functionality. -Especially- if these machines were already working in the field as-is. Probably worth noting I don't think I have yet to actually hear of any complaints about this being the case, and I'd like to also make sure this isn't a change being done for one or two vendors when most vendors aren't actually doing something like this. Note that for a lot of systems it won't -technically- be a big difference since the current situation in the market right now is that a lot of laptops will have all their external displays routed through the nvidia GPU and nowhere else. It's not great compared to just being able to use the well supported Intel GPU for everything though. And if we're controlling display routing through ACPI, that implies things aren't directly hooked up and someone went through the hassle of adding a display mux - which kind of seems like a waste of engineering effort and money if it can't actually be used for muxing between the two GPUs. Especially considering that up until very recently muxes had more or less been dropped from the majority of laptop vendors (I think Dell was an exception for this fwiw). Mark, since you're from Lenovo can you help to confirm this as well? Also re: external displays not even working: so then how exactly does the BIOS handle this? Is the BIOS changing the routing to the nvidia GPU then switching it back right before the OS load? I assume something must have been done to make it so that external displays aren't just suddenly broken there. And re: gsp work being done soon: it's going to be a while unfortunately, there's a lot for us to catch up on so it's hard for me to give a precise date. > Kai-Heng > > > > > If this is just for Intel/Intel systems though that's probably fine, and it > > might also be fine for AMD systems. > > > > > > > > > > > > > BR, > > > > Jani. > > > > > > > > > > > > > > Signed-off-by: Kai-Heng Feng > > > > > --- > > > > > drivers/gpu/drm/i915/display/intel_acpi.c | 18 +- > > > > > 1 file changed, 17 insertions(+), 1 deletion(-) > > > > > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_acpi.c > > > > > b/drivers/gpu/drm/i915/display/intel_acpi.c > > > > > index e78430001f077..3bd5930e2769b 100644 > > >
Re: [BUG][5.20] refcount_t: underflow; use-after-free
On 8/17/22 14:44, Mikhail Gavrilov wrote:
On Wed, Aug 17, 2022 at 9:08 PM Melissa Wen wrote:
Hi Mikhail,
IIUC, you got this second user-after-free by applying the first version
of Maíra's patch, right? So, that version was adding another unbalanced
unlock to the cs ioctl flow, but it was solved in the latest version,
that you can find here: https://patchwork.freedesktop.org/patch/497680/
If this is the situation, can you check this last version?
Thanks,
Melissa
With the last version warning "bad unlock balance detected!" was gone,
but the user-after-free issue remains.
And again "Workqueue: events drm_sched_entity_kill_jobs_work [gpu_sched]".
Hi Mikhail,
Looks like 45ecaea738830b9d521c93520c8f201359dcbd95 ("drm/sched: Partial
revert of 'drm/sched: Keep s_fence->parent pointer'") introduced the
error. Try reverting it and check if the use-after-free still happens.
Best Regards,
- Maíra Canal
[ 297.834779] [ cut here ]
[ 297.834818] refcount_t: underflow; use-after-free.
[ 297.834831] WARNING: CPU: 30 PID: 2377 at lib/refcount.c:28
refcount_warn_saturate+0xba/0x110
[ 297.834838] Modules linked in: uinput rfcomm snd_seq_dummy
snd_hrtimer nft_objref nf_conntrack_netbios_ns nf_conntrack_broadcast
nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet
nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat
nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables nfnetlink
qrtr bnep sunrpc binfmt_misc snd_seq_midi snd_seq_midi_event mt76x2u
mt76x2_common mt76x02_usb mt76_usb mt76x02_lib snd_hda_codec_realtek
iwlmvm intel_rapl_msr snd_hda_codec_generic snd_hda_codec_hdmi mt76
vfat fat snd_hda_intel intel_rapl_common mac80211 snd_intel_dspcfg
snd_intel_sdw_acpi snd_usb_audio snd_hda_codec snd_usbmidi_lib btusb
edac_mce_amd iwlwifi libarc4 uvcvideo snd_hda_core btrtl snd_rawmidi
snd_hwdep videobuf2_vmalloc btbcm kvm_amd videobuf2_memops snd_seq
iwlmei btintel videobuf2_v4l2 eeepc_wmi snd_seq_device
videobuf2_common btmtk kvm xpad videodev joydev irqbypass snd_pcm
asus_wmi hid_logitech_hidpp ff_memless cfg80211 bluetooth rapl mc
[ 297.834932] ledtrig_audio snd_timer sparse_keymap platform_profile
wmi_bmof snd video pcspkr k10temp i2c_piix4 rfkill soundcore mei
asus_ec_sensors acpi_cpufreq zram amdgpu drm_ttm_helper ttm
crct10dif_pclmul crc32_pclmul crc32c_intel iommu_v2 ucsi_ccg gpu_sched
typec_ucsi drm_buddy ghash_clmulni_intel drm_display_helper ccp igb
typec sp5100_tco nvme cec nvme_core dca wmi ip6_tables ip_tables fuse
[ 297.834978] Unloaded tainted modules: amd64_edac():1 amd64_edac():1
amd64_edac():1 amd64_edac():1 amd64_edac():1 amd64_edac():1
amd64_edac():1 amd64_edac():1 pcc_cpufreq():1 amd64_edac():1
pcc_cpufreq():1 amd64_edac():1 pcc_cpufreq():1 pcc_cpufreq():1
amd64_edac():1 amd64_edac():1 pcc_cpufreq():1 amd64_edac():1
pcc_cpufreq():1 amd64_edac():1 pcc_cpufreq():1 amd64_edac():1
pcc_cpufreq():1 pcc_cpufreq():1 amd64_edac():1 amd64_edac():1
pcc_cpufreq():1 pcc_cpufreq():1 amd64_edac():1 pcc_cpufreq():1
pcc_cpufreq():1 amd64_edac():1 pcc_cpufreq():1 amd64_edac():1
pcc_cpufreq():1 pcc_cpufreq():1 amd64_edac():1 pcc_cpufreq():1
amd64_edac():1 amd64_edac():1 pcc_cpufreq():1 amd64_edac():1
pcc_cpufreq():1 amd64_edac():1 pcc_cpufreq():1 pcc_cpufreq():1
amd64_edac():1 amd64_edac():1 pcc_cpufreq():1 pcc_cpufreq():1
amd64_edac():1 pcc_cpufreq():1 amd64_edac():1 amd64_edac():1
pcc_cpufreq():1 amd64_edac():1 pcc_cpufreq():1 amd64_edac():1
pcc_cpufreq():1 pcc_cpufreq():1 pcc_cpufreq():1 fjes():1
[ 297.835055] pcc_cpufreq():1 fjes():1 pcc_cpufreq():1 fjes():1
pcc_cpufreq():1 fjes():1 fjes():1 fjes():1 fjes():1 fjes():1
[ 297.835071] CPU: 30 PID: 2377 Comm: kworker/30:6 Tainted: G
WL--- ---
6.0.0-0.rc1.20220817git3cc40a443a04.14.fc38.x86_64 #1
[ 297.835075] Hardware name: System manufacturer System Product
Name/ROG STRIX X570-I GAMING, BIOS 4403 04/27/2022
[ 297.835078] Workqueue: events drm_sched_entity_kill_jobs_work [gpu_sched]
[ 297.835085] RIP: 0010:refcount_warn_saturate+0xba/0x110
[ 297.835088] Code: 01 01 e8 59 59 6f 00 0f 0b e9 22 46 a5 00 80 3d
be 7d be 01 00 75 85 48 c7 c7 c0 99 8e aa c6 05 ae 7d be 01 01 e8 36
59 6f 00 <0f> 0b e9 ff 45 a5 00 80 3d 99 7d be 01 00 0f 85 5e ff ff ff
48 c7
[ 297.835091] RSP: 0018:bd3506df7e60 EFLAGS: 00010286
[ 297.835095] RAX: 0026 RBX: 961b250cbc28 RCX:
[ 297.835097] RDX: 0001 RSI: aa8d07a4 RDI:
[ 297.835100] RBP: 96276a3f5600 R08: R09: bd3506df7d10
[ 297.835102] R10: 0003 R11: 9627ae2fffe8 R12: 96276a3fc800
[ 297.835105] R13: 9618c03e6600 R14: 96276a3fc805 R15: 961b250cbc30
[ 297.835108] FS: () GS:96276a20()
knlGS:
[ 297.835110] CS: 0010 DS: ES: CR0: 80050033
[ 297.835113] CR2: 621001e4a000 CR3: 00018d958000 CR4: 00350ee0
[ 297.835116] Call Trace:
[ 297.8
[RFC v4 00/17] drm/display/dp_mst: Drop Radeon MST support, make MST atomic-only
For quite a while we've been carrying around a lot of legacy modesetting code in the MST helpers that has been rather annoying to keep around, and very often gets in the way of trying to implement additional functionality in MST such as fallback link rate retraining, dynamic BPC management and DSC support, etc. because of the fact that we can't rely on atomic for everything. Luckily, we only actually have one user of the legacy MST code in the kernel - radeon. Originally I was thinking of trying to maintain this code and keep it around in some form, but I'm pretty unconvinced anyone is actually using this. My reasoning for that is because I've seen nearly no issues regarding MST on radeon for quite a while now - despite the fact my local testing seems to indicate it's quite broken. This isn't too surprising either, as MST support in radeon.ko is gated behind a module parameter that isn't enabled by default. This isn't to say I wouldn't be open to alternative suggestions, but I'd rather not be the one to have to spend time on that if at all possible! Plus, I already floated the idea of dropping this code by AMD folks a few times and didn't get much resistance. As well, this series has some basic refactoring that I did along the way and some bugs I had to fix in order to get my atomic-only MST code working. Most of this is pretty straight forward and simply renaming things to more closely match the DisplayPort specification, as I think this will also make maintaining this code a lot easier in the long run (I've gotten myself confused way too many times because of this). So far I've tested this on all three MST drivers: amdgpu, i915 and nouveau, along with making sure that removing the radeon MST code doesn't break anything else. The one thing I very much could use help with regarding testing though is making sure that this works with amdgpu's DSC support on MST. So, with this we should be using the atomic state as much as possible with MST modesetting, hooray! V4: * Get rid of fix that Wayne pointed out isn't needed Cc: Wayne Lin Cc: Ville Syrjälä Cc: Fangzhi Zuo Cc: Jani Nikula Cc: Imre Deak Cc: Daniel Vetter Cc: Sean Paul Lyude Paul (17): drm/amdgpu/dc/mst: Rename dp_mst_stream_allocation(_table) drm/amdgpu/dm/mst: Rename get_payload_table() drm/display/dp_mst: Rename drm_dp_mst_vcpi_allocation drm/display/dp_mst: Call them time slots, not VCPI slots drm/display/dp_mst: Fix confusing docs for drm_dp_atomic_release_time_slots() drm/display/dp_mst: Add some missing kdocs for atomic MST structs drm/display/dp_mst: Add helper for finding payloads in atomic MST state drm/display/dp_mst: Add nonblocking helpers for DP MST drm/display/dp_mst: Don't open code modeset checks for releasing time slots drm/display/dp_mst: Fix modeset tracking in drm_dp_atomic_release_vcpi_slots() drm/nouveau/kms: Cache DP encoders in nouveau_connector drm/nouveau/kms: Pull mst state in for all modesets drm/display/dp_mst: Add helpers for serializing SST <-> MST transitions drm/display/dp_mst: Drop all ports from topology on CSNs before queueing link address work drm/display/dp_mst: Maintain time slot allocations when deleting payloads drm/radeon: Drop legacy MST support drm/display/dp_mst: Move all payload info into the atomic state .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 68 +- .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 108 +- .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 125 +- drivers/gpu/drm/amd/display/dc/core/dc_link.c | 10 +- drivers/gpu/drm/amd/display/dc/dm_helpers.h |4 +- .../amd/display/include/link_service_types.h | 14 +- drivers/gpu/drm/display/drm_dp_mst_topology.c | 1137 - drivers/gpu/drm/i915/display/intel_display.c |6 + drivers/gpu/drm/i915/display/intel_dp.c |9 + drivers/gpu/drm/i915/display/intel_dp_mst.c | 91 +- drivers/gpu/drm/i915/display/intel_hdcp.c | 24 +- drivers/gpu/drm/nouveau/dispnv50/disp.c | 197 ++- drivers/gpu/drm/nouveau/dispnv50/disp.h |2 + drivers/gpu/drm/nouveau/nouveau_connector.c | 18 +- drivers/gpu/drm/nouveau/nouveau_connector.h |3 + drivers/gpu/drm/radeon/Makefile |2 +- drivers/gpu/drm/radeon/atombios_crtc.c| 11 +- drivers/gpu/drm/radeon/atombios_encoders.c| 59 - drivers/gpu/drm/radeon/radeon_atombios.c |2 - drivers/gpu/drm/radeon/radeon_connectors.c| 61 +- drivers/gpu/drm/radeon/radeon_device.c|1 - drivers/gpu/drm/radeon/radeon_dp_mst.c| 778 --- drivers/gpu/drm/radeon/radeon_drv.c |4 - drivers/gpu/drm/radeon/radeon_encoders.c | 14 +- drivers/gpu/drm/radeon/radeon_irq_kms.c | 10 +- drivers/gpu/drm/radeon/radeon_mode.h | 40 - include/drm/display/drm_dp_mst_helper.h | 234 ++-- 27 files changed, 955 insertions(+), 2077 deletions(-) delete mode 100644 drivers/gpu/drm/radeon/ra
[RFC v4 02/17] drm/amdgpu/dm/mst: Rename get_payload_table()
This function isn't too confusing if you see the comment around the
call-site for it, but if you don't then it's not at all obvious this is
meant to copy DRM's payload table over to DC's internal state structs.
Seeing this function before finding that comment definitely threw me into a
loop a few times.
So, let's rename this to make it's purpose more obvious regardless of where
in the code you are.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Fangzhi Zuo
Acked-by: Jani Nikula
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index 3aa385860eea..77c545e670d5 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -153,8 +153,9 @@ enum dc_edid_status dm_helpers_parse_edid_caps(
return result;
}
-static void get_payload_table(struct amdgpu_dm_connector *aconnector,
- struct dc_dp_mst_stream_allocation_table
*proposed_table)
+static void
+fill_dc_mst_payload_table_from_drm(struct amdgpu_dm_connector *aconnector,
+ struct dc_dp_mst_stream_allocation_table
*proposed_table)
{
int i;
struct drm_dp_mst_topology_mgr *mst_mgr =
@@ -252,7 +253,7 @@ bool dm_helpers_dp_mst_write_payload_allocation_table(
* stream. AMD ASIC stream slot allocation should follow the same
* sequence. copy DRM MST allocation to dc */
- get_payload_table(aconnector, proposed_table);
+ fill_dc_mst_payload_table_from_drm(aconnector, proposed_table);
return true;
}
--
2.37.1
[RFC v4 01/17] drm/amdgpu/dc/mst: Rename dp_mst_stream_allocation(_table)
Just to make this more clear to outside contributors that these are
DC-specific structs, as this also threw me into a loop a number of times
before I figured out the purpose of this.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Fangzhi Zuo
Acked-by: Jani Nikula
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 9 -
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 10 +-
drivers/gpu/drm/amd/display/dc/dm_helpers.h | 4 ++--
.../gpu/drm/amd/display/include/link_service_types.h | 11 ---
4 files changed, 19 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index a0154a5f7183..3aa385860eea 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -153,9 +153,8 @@ enum dc_edid_status dm_helpers_parse_edid_caps(
return result;
}
-static void get_payload_table(
- struct amdgpu_dm_connector *aconnector,
- struct dp_mst_stream_allocation_table *proposed_table)
+static void get_payload_table(struct amdgpu_dm_connector *aconnector,
+ struct dc_dp_mst_stream_allocation_table
*proposed_table)
{
int i;
struct drm_dp_mst_topology_mgr *mst_mgr =
@@ -177,7 +176,7 @@ static void get_payload_table(
mst_mgr->payloads[i].payload_state ==
DP_PAYLOAD_REMOTE) {
- struct dp_mst_stream_allocation *sa =
+ struct dc_dp_mst_stream_allocation *sa =
&proposed_table->stream_allocations[
proposed_table->stream_count];
@@ -201,7 +200,7 @@ void dm_helpers_dp_update_branch_info(
bool dm_helpers_dp_mst_write_payload_allocation_table(
struct dc_context *ctx,
const struct dc_stream_state *stream,
- struct dp_mst_stream_allocation_table *proposed_table,
+ struct dc_dp_mst_stream_allocation_table *proposed_table,
bool enable)
{
struct amdgpu_dm_connector *aconnector;
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
index 9e51338441d0..e01424fb02ba 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -3516,7 +3516,7 @@ static void update_mst_stream_alloc_table(
struct dc_link *link,
struct stream_encoder *stream_enc,
struct hpo_dp_stream_encoder *hpo_dp_stream_enc, // TODO: Rename
stream_enc to dio_stream_enc?
- const struct dp_mst_stream_allocation_table *proposed_table)
+ const struct dc_dp_mst_stream_allocation_table *proposed_table)
{
struct link_mst_stream_allocation work_table[MAX_CONTROLLER_NUM] = { 0
};
struct link_mst_stream_allocation *dc_alloc;
@@ -3679,7 +3679,7 @@ enum dc_status dc_link_allocate_mst_payload(struct
pipe_ctx *pipe_ctx)
{
struct dc_stream_state *stream = pipe_ctx->stream;
struct dc_link *link = stream->link;
- struct dp_mst_stream_allocation_table proposed_table = {0};
+ struct dc_dp_mst_stream_allocation_table proposed_table = {0};
struct fixed31_32 avg_time_slots_per_mtp;
struct fixed31_32 pbn;
struct fixed31_32 pbn_per_slot;
@@ -3784,7 +3784,7 @@ enum dc_status dc_link_reduce_mst_payload(struct pipe_ctx
*pipe_ctx, uint32_t bw
struct fixed31_32 avg_time_slots_per_mtp;
struct fixed31_32 pbn;
struct fixed31_32 pbn_per_slot;
- struct dp_mst_stream_allocation_table proposed_table = {0};
+ struct dc_dp_mst_stream_allocation_table proposed_table = {0};
uint8_t i;
const struct link_hwss *link_hwss = get_link_hwss(link,
&pipe_ctx->link_res);
DC_LOGGER_INIT(link->ctx->logger);
@@ -3873,7 +3873,7 @@ enum dc_status dc_link_increase_mst_payload(struct
pipe_ctx *pipe_ctx, uint32_t
struct fixed31_32 avg_time_slots_per_mtp;
struct fixed31_32 pbn;
struct fixed31_32 pbn_per_slot;
- struct dp_mst_stream_allocation_table proposed_table = {0};
+ struct dc_dp_mst_stream_allocation_table proposed_table = {0};
uint8_t i;
enum act_return_status ret;
const struct link_hwss *link_hwss = get_link_hwss(link,
&pipe_ctx->link_res);
@@ -3957,7 +3957,7 @@ static enum dc_status deallocate_mst_payload(struct
pipe_ctx *pipe_ctx)
{
struct dc_stream_state *stream = pipe_ctx->stream;
struct dc_link *link = stream->link;
- struct dp_mst_stream_allocation_table proposed_table = {0};
+ struct dc_dp_mst_stream_allocation_table proposed_table = {0};
struct fixed31_32 avg_time_slots_per_mtp = dc_fixpt_from_int(0);
int i;
bool mst_mode = (link->type ==
[RFC v4 03/17] drm/display/dp_mst: Rename drm_dp_mst_vcpi_allocation
In retrospect, the name I chose for this originally is confusing, as
there's a lot more info in here then just the VCPI. This really should be
called a payload. Let's make it more obvious that this is meant to be
related to the atomic state and is about payloads by renaming it to
drm_dp_mst_atomic_payload. Also, rename various variables throughout the
code that use atomic payloads.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
Cc: Jani Nikula
Cc: Imre Deak
Cc: Daniel Vetter
Cc: Sean Paul
Acked-by: Jani Nikula
---
drivers/gpu/drm/display/drm_dp_mst_topology.c | 96 +--
include/drm/display/drm_dp_mst_helper.h | 4 +-
2 files changed, 50 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index 7a94a5288e8d..f448e3e5ec6e 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -4370,7 +4370,7 @@ int drm_dp_atomic_find_vcpi_slots(struct drm_atomic_state
*state,
int pbn_div)
{
struct drm_dp_mst_topology_state *topology_state;
- struct drm_dp_vcpi_allocation *pos, *vcpi = NULL;
+ struct drm_dp_mst_atomic_payload *pos, *payload = NULL;
int prev_slots, prev_bw, req_slots;
topology_state = drm_atomic_get_mst_topology_state(state, mgr);
@@ -4378,11 +4378,11 @@ int drm_dp_atomic_find_vcpi_slots(struct
drm_atomic_state *state,
return PTR_ERR(topology_state);
/* Find the current allocation for this port, if any */
- list_for_each_entry(pos, &topology_state->vcpis, next) {
+ list_for_each_entry(pos, &topology_state->payloads, next) {
if (pos->port == port) {
- vcpi = pos;
- prev_slots = vcpi->vcpi;
- prev_bw = vcpi->pbn;
+ payload = pos;
+ prev_slots = payload->vcpi;
+ prev_bw = payload->pbn;
/*
* This should never happen, unless the driver tries
@@ -4399,7 +4399,7 @@ int drm_dp_atomic_find_vcpi_slots(struct drm_atomic_state
*state,
break;
}
}
- if (!vcpi) {
+ if (!payload) {
prev_slots = 0;
prev_bw = 0;
}
@@ -4417,17 +4417,17 @@ int drm_dp_atomic_find_vcpi_slots(struct
drm_atomic_state *state,
port, prev_bw, pbn);
/* Add the new allocation to the state */
- if (!vcpi) {
- vcpi = kzalloc(sizeof(*vcpi), GFP_KERNEL);
- if (!vcpi)
+ if (!payload) {
+ payload = kzalloc(sizeof(*payload), GFP_KERNEL);
+ if (!payload)
return -ENOMEM;
drm_dp_mst_get_port_malloc(port);
- vcpi->port = port;
- list_add(&vcpi->next, &topology_state->vcpis);
+ payload->port = port;
+ list_add(&payload->next, &topology_state->payloads);
}
- vcpi->vcpi = req_slots;
- vcpi->pbn = pbn;
+ payload->vcpi = req_slots;
+ payload->pbn = pbn;
return req_slots;
}
@@ -4464,21 +4464,21 @@ int drm_dp_atomic_release_vcpi_slots(struct
drm_atomic_state *state,
struct drm_dp_mst_port *port)
{
struct drm_dp_mst_topology_state *topology_state;
- struct drm_dp_vcpi_allocation *pos;
+ struct drm_dp_mst_atomic_payload *pos;
bool found = false;
topology_state = drm_atomic_get_mst_topology_state(state, mgr);
if (IS_ERR(topology_state))
return PTR_ERR(topology_state);
- list_for_each_entry(pos, &topology_state->vcpis, next) {
+ list_for_each_entry(pos, &topology_state->payloads, next) {
if (pos->port == port) {
found = true;
break;
}
}
if (WARN_ON(!found)) {
- drm_err(mgr->dev, "no VCPI for [MST PORT:%p] found in mst state
%p\n",
+ drm_err(mgr->dev, "No payload for [MST PORT:%p] found in mst
state %p\n",
port, &topology_state->base);
return -EINVAL;
}
@@ -5060,7 +5060,7 @@ drm_dp_mst_duplicate_state(struct drm_private_obj *obj)
{
struct drm_dp_mst_topology_state *state, *old_state =
to_dp_mst_topology_state(obj->state);
- struct drm_dp_vcpi_allocation *pos, *vcpi;
+ struct drm_dp_mst_atomic_payload *pos, *payload;
state = kmemdup(old_state, sizeof(*state), GFP_KERNEL);
if (!state)
@@ -5068,25 +5068,25 @@ drm_dp_mst_duplicate_state(struct drm_private_obj *obj)
__drm_atomic_helper_private_obj_duplicate_state(obj, &state->base);
- INIT_LIST_HEAD(&state->vcpis);
+ INIT_LIS
[RFC v4 04/17] drm/display/dp_mst: Call them time slots, not VCPI slots
VCPI is only sort of the correct term here, originally the majority of this
code simply referred to timeslots vaguely as "slots" - and since I started
working on it and adding atomic functionality, the name "VCPI slots" has
been used to represent time slots.
Now that we actually have consistent access to the DisplayPort spec thanks
to VESA, I now know this isn't actually the proper term - as the
specification refers to these as time slots.
Since we're trying to make this code as easy to figure out as possible,
let's take this opportunity to correct this nomenclature and call them by
their proper name - timeslots. Likewise, we rename various functions
appropriately, along with replacing references in the kernel documentation
and various debugging messages.
It's important to note that this patch series leaves the legacy MST code
untouched for the most part, which is fine since we'll be removing it soon
anyhow. There should be no functional changes in this series.
v2:
* Add note that Wayne Lin from AMD suggested regarding slots being between
the source DP Tx and the immediate downstream DP Rx
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
Cc: Jani Nikula
Cc: Imre Deak
Cc: Daniel Vetter
Cc: Sean Paul
Acked-by: Jani Nikula
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 28 ++---
drivers/gpu/drm/display/drm_dp_mst_topology.c | 106 +-
drivers/gpu/drm/i915/display/intel_dp_mst.c | 5 +-
drivers/gpu/drm/nouveau/dispnv50/disp.c | 4 +-
include/drm/display/drm_dp_mst_helper.h | 12 +-
6 files changed, 81 insertions(+), 76 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 85fdd6baf803..cd30b02af8ee 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6401,7 +6401,7 @@ static int dm_encoder_helper_atomic_check(struct
drm_encoder *encoder,
clock = adjusted_mode->clock;
dm_new_connector_state->pbn = drm_dp_calc_pbn_mode(clock, bpp,
false);
}
- dm_new_connector_state->vcpi_slots =
drm_dp_atomic_find_vcpi_slots(state,
+ dm_new_connector_state->vcpi_slots =
drm_dp_atomic_find_time_slots(state,
mst_mgr,
mst_port,
dm_new_connector_state->pbn,
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 2e74ccf7df5b..655d63b20b33 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -472,7 +472,7 @@ static int dm_dp_mst_atomic_check(struct drm_connector
*connector,
return 0;
}
- return drm_dp_atomic_release_vcpi_slots(state,
+ return drm_dp_atomic_release_time_slots(state,
mst_mgr,
mst_port);
}
@@ -785,7 +785,7 @@ static bool increase_dsc_bpp(struct drm_atomic_state *state,
if (initial_slack[next_index] > fair_pbn_alloc) {
vars[next_index].pbn += fair_pbn_alloc;
- if (drm_dp_atomic_find_vcpi_slots(state,
+ if (drm_dp_atomic_find_time_slots(state,
params[next_index].port->mgr,
params[next_index].port,
vars[next_index].pbn,
@@ -795,7 +795,7 @@ static bool increase_dsc_bpp(struct drm_atomic_state *state,
vars[next_index].bpp_x16 =
bpp_x16_from_pbn(params[next_index], vars[next_index].pbn);
} else {
vars[next_index].pbn -= fair_pbn_alloc;
- if (drm_dp_atomic_find_vcpi_slots(state,
+ if (drm_dp_atomic_find_time_slots(state,
params[next_index].port->mgr,
params[next_index].port,
vars[next_index].pbn,
@@ -804,7 +804,7 @@ static bool increase_dsc_bpp(struct drm_atomic_state *state,
}
} else {
vars[next_index].pbn += initial_slack[next_index];
- if (drm_dp_atomic_find_vcpi_slots(state,
+ if (drm_dp_atomic_find_time_slots(state,
[RFC v4 05/17] drm/display/dp_mst: Fix confusing docs for drm_dp_atomic_release_time_slots()
For some reason we mention returning 0 if "slots have been added back to drm_dp_mst_topology_state->avail_slots". This is totally misleading, avail_slots is simply for figuring out the total number of slots available in total on the topology and has no relation to the current payload allocations. So, let's get rid of that comment. Signed-off-by: Lyude Paul Cc: Wayne Lin Cc: Ville Syrjälä Cc: Fangzhi Zuo Cc: Jani Nikula Cc: Imre Deak Cc: Daniel Vetter Cc: Sean Paul Acked-by: Jani Nikula --- drivers/gpu/drm/display/drm_dp_mst_topology.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c b/drivers/gpu/drm/display/drm_dp_mst_topology.c index fad80ab2b9db..8a2ddfde594a 100644 --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c @@ -4456,8 +4456,7 @@ EXPORT_SYMBOL(drm_dp_atomic_find_time_slots); * drm_dp_mst_atomic_check() * * Returns: - * 0 if all slots for this port were added back to - * &drm_dp_mst_topology_state.avail_slots or negative error code + * 0 on success, negative error code otherwise */ int drm_dp_atomic_release_time_slots(struct drm_atomic_state *state, struct drm_dp_mst_topology_mgr *mgr, -- 2.37.1
[RFC v4 07/17] drm/display/dp_mst: Add helper for finding payloads in atomic MST state
We already open-code this quite often, and will be iterating through
payloads even more once we've moved all of the payload tracking into the
atomic state. So, let's add a helper for doing this.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
Cc: Jani Nikula
Cc: Imre Deak
Cc: Daniel Vetter
Cc: Sean Paul
Acked-by: Jani Nikula
---
drivers/gpu/drm/display/drm_dp_mst_topology.c | 109 --
1 file changed, 45 insertions(+), 64 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index 8a2ddfde594a..1c054a5e2e77 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -1738,6 +1738,19 @@ drm_dp_mst_dump_port_topology_history(struct
drm_dp_mst_port *port) {}
#define save_port_topology_ref(port, type)
#endif
+static struct drm_dp_mst_atomic_payload *
+drm_atomic_get_mst_payload_state(struct drm_dp_mst_topology_state *state,
+struct drm_dp_mst_port *port)
+{
+ struct drm_dp_mst_atomic_payload *payload;
+
+ list_for_each_entry(payload, &state->payloads, next)
+ if (payload->port == port)
+ return payload;
+
+ return NULL;
+}
+
static void drm_dp_destroy_mst_branch_device(struct kref *kref)
{
struct drm_dp_mst_branch *mstb =
@@ -4370,39 +4383,31 @@ int drm_dp_atomic_find_time_slots(struct
drm_atomic_state *state,
int pbn_div)
{
struct drm_dp_mst_topology_state *topology_state;
- struct drm_dp_mst_atomic_payload *pos, *payload = NULL;
- int prev_slots, prev_bw, req_slots;
+ struct drm_dp_mst_atomic_payload *payload = NULL;
+ int prev_slots = 0, prev_bw = 0, req_slots;
topology_state = drm_atomic_get_mst_topology_state(state, mgr);
if (IS_ERR(topology_state))
return PTR_ERR(topology_state);
/* Find the current allocation for this port, if any */
- list_for_each_entry(pos, &topology_state->payloads, next) {
- if (pos->port == port) {
- payload = pos;
- prev_slots = payload->time_slots;
- prev_bw = payload->pbn;
-
- /*
-* This should never happen, unless the driver tries
-* releasing and allocating the same timeslot
allocation,
-* which is an error
-*/
- if (WARN_ON(!prev_slots)) {
- drm_err(mgr->dev,
- "cannot allocate and release time slots
on [MST PORT:%p] in the same state\n",
- port);
- return -EINVAL;
- }
+ payload = drm_atomic_get_mst_payload_state(topology_state, port);
+ if (payload) {
+ prev_slots = payload->time_slots;
+ prev_bw = payload->pbn;
- break;
+ /*
+* This should never happen, unless the driver tries
+* releasing and allocating the same timeslot allocation,
+* which is an error
+*/
+ if (WARN_ON(!prev_slots)) {
+ drm_err(mgr->dev,
+ "cannot allocate and release time slots on [MST
PORT:%p] in the same state\n",
+ port);
+ return -EINVAL;
}
}
- if (!payload) {
- prev_slots = 0;
- prev_bw = 0;
- }
if (pbn_div <= 0)
pbn_div = mgr->pbn_div;
@@ -4463,30 +4468,24 @@ int drm_dp_atomic_release_time_slots(struct
drm_atomic_state *state,
struct drm_dp_mst_port *port)
{
struct drm_dp_mst_topology_state *topology_state;
- struct drm_dp_mst_atomic_payload *pos;
- bool found = false;
+ struct drm_dp_mst_atomic_payload *payload;
topology_state = drm_atomic_get_mst_topology_state(state, mgr);
if (IS_ERR(topology_state))
return PTR_ERR(topology_state);
- list_for_each_entry(pos, &topology_state->payloads, next) {
- if (pos->port == port) {
- found = true;
- break;
- }
- }
- if (WARN_ON(!found)) {
+ payload = drm_atomic_get_mst_payload_state(topology_state, port);
+ if (WARN_ON(!payload)) {
drm_err(mgr->dev, "No payload for [MST PORT:%p] found in mst
state %p\n",
port, &topology_state->base);
return -EINVAL;
}
- drm_dbg_atomic(mgr->dev, "[MST PORT:%p] TU %d -> 0\n", port,
pos->time_slots);
- if (pos->time_slots) {
+ drm_dbg_atomic
[RFC v4 08/17] drm/display/dp_mst: Add nonblocking helpers for DP MST
As Daniel Vetter pointed out, if we only use the atomic modesetting locks
with MST it's technically possible for a driver with non-blocking modesets
to race when it comes to MST displays - as we make the mistake of not doing
our own CRTC commit tracking in the topology_state object.
This could potentially cause problems if something like this happens:
* User starts non-blocking commit to disable CRTC-1 on MST topology 1
* User starts non-blocking commit to enable CRTC-2 on MST topology 1
There's no guarantee here that the commit for disabling CRTC-2 will only
occur after CRTC-1 has finished, since neither commit shares a CRTC - only
the private modesetting object for MST. Keep in mind this likely isn't a
problem for blocking modesets, only non-blocking.
So, begin fixing this by keeping track of which CRTCs on a topology have
changed by keeping track of which CRTCs we release or allocate timeslots
on. As well, add some helpers for:
* Setting up the drm_crtc_commit structs in the ->commit_setup hook
* Waiting for any CRTC dependencies from the previous topology state
v2:
* Use drm_dp_mst_atomic_setup_commit() directly - Jani
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
Cc: Jani Nikula
Cc: Imre Deak
Cc: Daniel Vetter
Cc: Sean Paul
Acked-by: Jani Nikula
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 +-
drivers/gpu/drm/display/drm_dp_mst_topology.c | 93 +++
drivers/gpu/drm/i915/display/intel_display.c | 6 ++
drivers/gpu/drm/nouveau/dispnv50/disp.c | 7 ++
include/drm/display/drm_dp_mst_helper.h | 15 +++
5 files changed, 124 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index cd30b02af8ee..c97a4d759b94 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -2808,7 +2808,8 @@ static const struct drm_mode_config_funcs
amdgpu_dm_mode_funcs = {
};
static struct drm_mode_config_helper_funcs amdgpu_dm_mode_config_helperfuncs =
{
- .atomic_commit_tail = amdgpu_dm_atomic_commit_tail
+ .atomic_commit_tail = amdgpu_dm_atomic_commit_tail,
+ .atomic_commit_setup = drm_dp_mst_atomic_setup_commit,
};
static void update_connector_ext_caps(struct amdgpu_dm_connector *aconnector)
@@ -7959,6 +7960,7 @@ static void amdgpu_dm_atomic_commit_tail(struct
drm_atomic_state *state)
DRM_ERROR("Waiting for fences timed out!");
drm_atomic_helper_update_legacy_modeset_state(dev, state);
+ drm_dp_mst_atomic_wait_for_dependencies(state);
dm_state = dm_atomic_get_new_state(state);
if (dm_state && dm_state->context) {
@@ -8357,7 +8359,6 @@ static void amdgpu_dm_atomic_commit_tail(struct
drm_atomic_state *state)
dc_release_state(dc_state_temp);
}
-
static int dm_force_atomic_commit(struct drm_connector *connector)
{
int ret = 0;
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index 1c054a5e2e77..d701e5b819b8 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -4384,12 +4384,16 @@ int drm_dp_atomic_find_time_slots(struct
drm_atomic_state *state,
{
struct drm_dp_mst_topology_state *topology_state;
struct drm_dp_mst_atomic_payload *payload = NULL;
+ struct drm_connector_state *conn_state;
int prev_slots = 0, prev_bw = 0, req_slots;
topology_state = drm_atomic_get_mst_topology_state(state, mgr);
if (IS_ERR(topology_state))
return PTR_ERR(topology_state);
+ conn_state = drm_atomic_get_new_connector_state(state, port->connector);
+ topology_state->pending_crtc_mask |= drm_crtc_mask(conn_state->crtc);
+
/* Find the current allocation for this port, if any */
payload = drm_atomic_get_mst_payload_state(topology_state, port);
if (payload) {
@@ -4469,11 +4473,15 @@ int drm_dp_atomic_release_time_slots(struct
drm_atomic_state *state,
{
struct drm_dp_mst_topology_state *topology_state;
struct drm_dp_mst_atomic_payload *payload;
+ struct drm_connector_state *conn_state;
topology_state = drm_atomic_get_mst_topology_state(state, mgr);
if (IS_ERR(topology_state))
return PTR_ERR(topology_state);
+ conn_state = drm_atomic_get_old_connector_state(state, port->connector);
+ topology_state->pending_crtc_mask |= drm_crtc_mask(conn_state->crtc);
+
payload = drm_atomic_get_mst_payload_state(topology_state, port);
if (WARN_ON(!payload)) {
drm_err(mgr->dev, "No payload for [MST PORT:%p] found in mst
state %p\n",
@@ -4492,6 +4500,83 @@ int drm_dp_atomic_release_time_slots(struct
drm_atomic_state *state,
}
EXPORT_SYMBOL(drm_dp_atomic_release_time_slots);
+/**
+ * drm_dp_mst_atomic_setup
[RFC v4 12/17] drm/nouveau/kms: Pull mst state in for all modesets
Since we're going to be relying on atomic locking for payloads now (and the MST mgr needs to track CRTCs), pull in the topology state for all modesets in nv50_msto_atomic_check(). Signed-off-by: Lyude Paul Acked-by: Jani Nikula --- drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c b/drivers/gpu/drm/nouveau/dispnv50/disp.c index 5669c8d747d7..24807aa9da5f 100644 --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c @@ -1049,7 +1049,7 @@ nv50_msto_atomic_check(struct drm_encoder *encoder, if (ret) return ret; - if (!crtc_state->mode_changed && !crtc_state->connectors_changed) + if (!drm_atomic_crtc_needs_modeset(crtc_state)) return 0; /* -- 2.37.1
[RFC v4 06/17] drm/display/dp_mst: Add some missing kdocs for atomic MST structs
Since we're about to start adding some stuff here, we may as well fill in
any missing documentation that we forgot to write.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
Cc: Jani Nikula
Cc: Imre Deak
Cc: Daniel Vetter
Cc: Sean Paul
Acked-by: Jani Nikula
---
include/drm/display/drm_dp_mst_helper.h | 23 +++
1 file changed, 23 insertions(+)
diff --git a/include/drm/display/drm_dp_mst_helper.h
b/include/drm/display/drm_dp_mst_helper.h
index 9cdd2def56a1..3b155ad3eee4 100644
--- a/include/drm/display/drm_dp_mst_helper.h
+++ b/include/drm/display/drm_dp_mst_helper.h
@@ -542,7 +542,14 @@ struct drm_dp_payload {
#define to_dp_mst_topology_state(x) container_of(x, struct
drm_dp_mst_topology_state, base)
+/**
+ * struct drm_dp_mst_atomic_payload - Atomic state struct for an MST payload
+ *
+ * The primary atomic state structure for a given MST payload. Stores
information like current
+ * bandwidth allocation, intended action for this payload, etc.
+ */
struct drm_dp_mst_atomic_payload {
+ /** @port: The MST port assigned to this payload */
struct drm_dp_mst_port *port;
/**
@@ -551,16 +558,32 @@ struct drm_dp_mst_atomic_payload {
* the immediate downstream DP Rx
*/
int time_slots;
+ /** @pbn: The payload bandwidth for this payload */
int pbn;
+ /** @dsc_enabled: Whether or not this payload has DSC enabled */
bool dsc_enabled;
+
+ /** @next: The list node for this payload */
struct list_head next;
};
+/**
+ * struct drm_dp_mst_topology_state - DisplayPort MST topology atomic state
+ *
+ * This struct represents the atomic state of the toplevel DisplayPort MST
manager
+ */
struct drm_dp_mst_topology_state {
+ /** @base: Base private state for atomic */
struct drm_private_state base;
+
+ /** @payloads: The list of payloads being created/destroyed in this
state */
struct list_head payloads;
+ /** @mgr: The topology manager */
struct drm_dp_mst_topology_mgr *mgr;
+
+ /** @total_avail_slots: The total number of slots this topology can
handle (63 or 64) */
u8 total_avail_slots;
+ /** @start_slot: The first usable time slot in this topology (1 or 0) */
u8 start_slot;
};
--
2.37.1
[RFC v4 10/17] drm/display/dp_mst: Fix modeset tracking in drm_dp_atomic_release_vcpi_slots()
Currently with the MST helpers we avoid releasing payloads _and_ avoid
pulling in the MST state if there aren't any actual payload changes. While
we want to keep the first step, we need to now make sure that we're always
pulling in the MST state on all modesets that can modify payloads - even if
the resulting payloads in the atomic state are identical to the previous
ones.
This is mainly to make it so that if a CRTC is still assigned to a
connector but is set to DPMS off, the CRTC still holds it's payload
allocation in the atomic state and still appropriately pulls in the MST
state for commit tracking. Otherwise, we'll occasionally forget to update
MST payloads from changes caused by non-atomic DPMS changes. Doing this
also allows us to track bandwidth limitations in a state correctly even
between DPMS changes, so that there's no chance of a simple ->active change
being rejected by the atomic check.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
Cc: Jani Nikula
Cc: Imre Deak
Cc: Daniel Vetter
Cc: Sean Paul
Acked-by: Jani Nikula
---
drivers/gpu/drm/display/drm_dp_mst_topology.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index aa6dcd9ff6a5..2f7c43f88d74 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -4474,6 +4474,7 @@ int drm_dp_atomic_release_time_slots(struct
drm_atomic_state *state,
struct drm_dp_mst_topology_state *topology_state;
struct drm_dp_mst_atomic_payload *payload;
struct drm_connector_state *old_conn_state, *new_conn_state;
+ bool update_payload = true;
old_conn_state = drm_atomic_get_old_connector_state(state,
port->connector);
if (!old_conn_state->crtc)
@@ -4485,10 +4486,12 @@ int drm_dp_atomic_release_time_slots(struct
drm_atomic_state *state,
struct drm_crtc_state *crtc_state =
drm_atomic_get_new_crtc_state(state,
new_conn_state->crtc);
- if (!crtc_state ||
- !drm_atomic_crtc_needs_modeset(crtc_state) ||
- crtc_state->enable)
+ /* No modeset means no payload changes, so it's safe to not
pull in the MST state */
+ if (!crtc_state || !drm_atomic_crtc_needs_modeset(crtc_state))
return 0;
+
+ if (!crtc_state->mode_changed &&
!crtc_state->connectors_changed)
+ update_payload = false;
}
topology_state = drm_atomic_get_mst_topology_state(state, mgr);
@@ -4496,6 +4499,8 @@ int drm_dp_atomic_release_time_slots(struct
drm_atomic_state *state,
return PTR_ERR(topology_state);
topology_state->pending_crtc_mask |=
drm_crtc_mask(old_conn_state->crtc);
+ if (!update_payload)
+ return 0;
payload = drm_atomic_get_mst_payload_state(topology_state, port);
if (WARN_ON(!payload)) {
--
2.37.1
[RFC v4 11/17] drm/nouveau/kms: Cache DP encoders in nouveau_connector
Post-NV50, the only kind of encoder you'll find for DP connectors on Nvidia
GPUs are SORs (serial output resources). Because SORs have fixed
associations with their connectors, we can correctly assume that any DP
connector on a nvidia GPU will have exactly one SOR encoder routed to it
for DisplayPort.
Since we're going to need to be able to retrieve this fixed SOR DP encoder
much more often as a result of hooking up MST helpers for tracking
SST<->MST transitions in atomic states, let's simply cache this encoder in
nouveau_connector for any DP connectors on the system to avoid looking it
up each time. This isn't safe for NV50 since PIORs then come into play,
however there's no code pre-NV50 that would need to look this up anyhow -
so it's not really an issue.
Signed-off-by: Lyude Paul
Acked-by: Jani Nikula
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 4 +++-
drivers/gpu/drm/nouveau/nouveau_connector.h | 3 +++
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 8100c75ee731..b8ee2173ca8f 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -1368,7 +1368,7 @@ nouveau_connector_create(struct drm_device *dev,
return ERR_PTR(-ENOMEM);
}
drm_dp_aux_init(&nv_connector->aux);
- fallthrough;
+ break;
default:
funcs = &nouveau_connector_funcs;
break;
@@ -1431,6 +1431,8 @@ nouveau_connector_create(struct drm_device *dev,
switch (type) {
case DRM_MODE_CONNECTOR_DisplayPort:
+ nv_connector->dp_encoder = find_encoder(&nv_connector->base,
DCB_OUTPUT_DP);
+ fallthrough;
case DRM_MODE_CONNECTOR_eDP:
drm_dp_cec_register_connector(&nv_connector->aux, connector);
break;
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.h
b/drivers/gpu/drm/nouveau/nouveau_connector.h
index 4bf0c703eee7..f4e17ff68bf9 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.h
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.h
@@ -128,6 +128,9 @@ struct nouveau_connector {
struct drm_dp_aux aux;
+ /* The fixed DP encoder for this connector, if there is one */
+ struct nouveau_encoder *dp_encoder;
+
int dithering_mode;
int scaling_mode;
--
2.37.1
[RFC v4 13/17] drm/display/dp_mst: Add helpers for serializing SST <-> MST transitions
There's another kind of situation where we could potentially race with
nonblocking modesets and MST, especially if we were to only use the locking
provided by atomic modesetting:
* Display 1 begins as enabled on DP-1 in SST mode
* Display 1 switches to MST mode, exposes one sink in MST mode
* Userspace does non-blocking modeset to disable the SST display
* Userspace does non-blocking modeset to enable the MST display with a
different CRTC, but the SST display hasn't been fully taken down yet
* Execution order between the last two commits isn't guaranteed since they
share no drm resources
We can fix this however, by ensuring that we always pull in the atomic
topology state whenever a connector capable of driving an MST display
performs its atomic check - and then tracking CRTC commits happening on the
SST connector in the MST topology state. So, let's add some simple helpers
for doing that and hook them up in various drivers.
v2:
* Use intel_dp_mst_source_support() to check for MST support in i915, fixes
CI failures
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
Cc: Jani Nikula
Cc: Imre Deak
Cc: Daniel Vetter
Cc: Sean Paul
Acked-by: Jani Nikula
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 +++
drivers/gpu/drm/display/drm_dp_mst_topology.c | 59 +++
drivers/gpu/drm/i915/display/intel_dp.c | 9 +++
drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +-
drivers/gpu/drm/nouveau/dispnv50/disp.h | 2 +
drivers/gpu/drm/nouveau/nouveau_connector.c | 14 +
include/drm/display/drm_dp_mst_helper.h | 2 +
7 files changed, 94 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index c97a4d759b94..789748739d79 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6291,10 +6291,17 @@ amdgpu_dm_connector_atomic_check(struct drm_connector
*conn,
drm_atomic_get_old_connector_state(state, conn);
struct drm_crtc *crtc = new_con_state->crtc;
struct drm_crtc_state *new_crtc_state;
+ struct amdgpu_dm_connector *aconn = to_amdgpu_dm_connector(conn);
int ret;
trace_amdgpu_dm_connector_atomic_check(new_con_state);
+ if (conn->connector_type == DRM_MODE_CONNECTOR_DisplayPort) {
+ ret = drm_dp_mst_root_conn_atomic_check(new_con_state,
&aconn->mst_mgr);
+ if (ret < 0)
+ return ret;
+ }
+
if (!crtc)
return 0;
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index 2f7c43f88d74..97e8f8a83ed4 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -4597,6 +4597,65 @@ void drm_dp_mst_atomic_wait_for_dependencies(struct
drm_atomic_state *state)
}
EXPORT_SYMBOL(drm_dp_mst_atomic_wait_for_dependencies);
+/**
+ * drm_dp_mst_root_conn_atomic_check() - Serialize CRTC commits on MST-capable
connectors operating
+ * in SST mode
+ * @new_conn_state: The new connector state of the &drm_connector
+ * @mgr: The MST topology manager for the &drm_connector
+ *
+ * Since MST uses fake &drm_encoder structs, the generic atomic modesetting
code isn't able to
+ * serialize non-blocking commits happening on the real DP connector of an MST
topology switching
+ * into/away from MST mode - as the CRTC on the real DP connector and the
CRTCs on the connector's
+ * MST topology will never share the same &drm_encoder.
+ *
+ * This function takes care of this serialization issue, by checking a root
MST connector's atomic
+ * state to determine if it is about to have a modeset - and then pulling in
the MST topology state
+ * if so, along with adding any relevant CRTCs to
&drm_dp_mst_topology_state.pending_crtc_mask.
+ *
+ * Drivers implementing MST must call this function from the
+ * &drm_connector_helper_funcs.atomic_check hook of any physical DP
&drm_connector capable of
+ * driving MST sinks.
+ *
+ * Returns:
+ * 0 on success, negative error code otherwise
+ */
+int drm_dp_mst_root_conn_atomic_check(struct drm_connector_state
*new_conn_state,
+ struct drm_dp_mst_topology_mgr *mgr)
+{
+ struct drm_atomic_state *state = new_conn_state->state;
+ struct drm_connector_state *old_conn_state =
+ drm_atomic_get_old_connector_state(state,
new_conn_state->connector);
+ struct drm_crtc_state *crtc_state;
+ struct drm_dp_mst_topology_state *mst_state = NULL;
+
+ if (new_conn_state->crtc) {
+ crtc_state = drm_atomic_get_new_crtc_state(state,
new_conn_state->crtc);
+ if (crtc_state && drm_atomic_crtc_needs_modeset(crtc_state)) {
+ mst_state = drm_atomic_get_mst_topology_state(state,
mgr);
+ if (
[RFC v4 14/17] drm/display/dp_mst: Drop all ports from topology on CSNs before queueing link address work
We want to start cutting down on all of the places that we use port
validation, so that ports may be removed from the topology as quickly as
possible to minimize the number of errors we run into as a result of being
out of sync with the current topology status. This isn't a very typical
scenario and I don't think I've ever even run into it - but since the next
commit is going to make some changes to payload updates depending on their
hotplug status I think it's a probably good idea to take precautions.
Let's do this with CSNs by moving some code around so that we only queue
link address probing work at the end of handling all CSNs - allowing us to
make sure we drop as many topology references as we can beforehand.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
Cc: Jani Nikula
Cc: Imre Deak
Cc: Daniel Vetter
Cc: Sean Paul
Acked-by: Jani Nikula
---
drivers/gpu/drm/display/drm_dp_mst_topology.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index 97e8f8a83ed4..a5460cadf2c8 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -2509,7 +2509,7 @@ drm_dp_mst_handle_link_address_port(struct
drm_dp_mst_branch *mstb,
return ret;
}
-static void
+static int
drm_dp_mst_handle_conn_stat(struct drm_dp_mst_branch *mstb,
struct drm_dp_connection_status_notify *conn_stat)
{
@@ -2522,7 +2522,7 @@ drm_dp_mst_handle_conn_stat(struct drm_dp_mst_branch
*mstb,
port = drm_dp_get_port(mstb, conn_stat->port_number);
if (!port)
- return;
+ return 0;
if (port->connector) {
if (!port->input && conn_stat->input_port) {
@@ -2575,8 +2575,7 @@ drm_dp_mst_handle_conn_stat(struct drm_dp_mst_branch
*mstb,
out:
drm_dp_mst_topology_put_port(port);
- if (dowork)
- queue_work(system_long_wq, &mstb->mgr->work);
+ return dowork;
}
static struct drm_dp_mst_branch *drm_dp_get_mst_branch_device(struct
drm_dp_mst_topology_mgr *mgr,
@@ -4060,7 +4059,7 @@ drm_dp_mst_process_up_req(struct drm_dp_mst_topology_mgr
*mgr,
struct drm_dp_mst_branch *mstb = NULL;
struct drm_dp_sideband_msg_req_body *msg = &up_req->msg;
struct drm_dp_sideband_msg_hdr *hdr = &up_req->hdr;
- bool hotplug = false;
+ bool hotplug = false, dowork = false;
if (hdr->broadcast) {
const u8 *guid = NULL;
@@ -4083,11 +4082,14 @@ drm_dp_mst_process_up_req(struct
drm_dp_mst_topology_mgr *mgr,
/* TODO: Add missing handler for DP_RESOURCE_STATUS_NOTIFY events */
if (msg->req_type == DP_CONNECTION_STATUS_NOTIFY) {
- drm_dp_mst_handle_conn_stat(mstb, &msg->u.conn_stat);
+ dowork = drm_dp_mst_handle_conn_stat(mstb, &msg->u.conn_stat);
hotplug = true;
}
drm_dp_mst_topology_put_mstb(mstb);
+
+ if (dowork)
+ queue_work(system_long_wq, &mgr->work);
return hotplug;
}
--
2.37.1
[RFC v4 15/17] drm/display/dp_mst: Maintain time slot allocations when deleting payloads
Currently, we set drm_dp_atomic_payload->time_slots to 0 in order to
indicate that we're about to delete a payload in the current atomic state.
Since we're going to be dropping all of the legacy code for handling the
payload table however, we need to be able to ensure that we still keep
track of the current time slot allocations for each payload so we can reuse
this info when asking the root MST hub to delete payloads. We'll also be
using it to recalculate the start slots of each VC.
So, let's keep track of the intent of a payload in drm_dp_atomic_payload by
adding ->delete, which we set whenever we're planning on deleting a payload
during the current atomic commit.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
Cc: Jani Nikula
Cc: Imre Deak
Cc: Daniel Vetter
Cc: Sean Paul
Acked-by: Jani Nikula
---
drivers/gpu/drm/display/drm_dp_mst_topology.c | 14 +++---
include/drm/display/drm_dp_mst_helper.h | 5 -
2 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index a5460cadf2c8..c4073d733c59 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -4407,7 +4407,7 @@ int drm_dp_atomic_find_time_slots(struct drm_atomic_state
*state,
* releasing and allocating the same timeslot allocation,
* which is an error
*/
- if (WARN_ON(!prev_slots)) {
+ if (drm_WARN_ON(mgr->dev, payload->delete)) {
drm_err(mgr->dev,
"cannot allocate and release time slots on [MST
PORT:%p] in the same state\n",
port);
@@ -4512,10 +4512,10 @@ int drm_dp_atomic_release_time_slots(struct
drm_atomic_state *state,
}
drm_dbg_atomic(mgr->dev, "[MST PORT:%p] TU %d -> 0\n", port,
payload->time_slots);
- if (payload->time_slots) {
+ if (!payload->delete) {
drm_dp_mst_put_port_malloc(port);
- payload->time_slots = 0;
payload->pbn = 0;
+ payload->delete = true;
}
return 0;
@@ -5239,7 +5239,7 @@ drm_dp_mst_duplicate_state(struct drm_private_obj *obj)
list_for_each_entry(pos, &old_state->payloads, next) {
/* Prune leftover freed timeslot allocations */
- if (!pos->time_slots)
+ if (pos->delete)
continue;
payload = kmemdup(pos, sizeof(*payload), GFP_KERNEL);
@@ -5271,8 +5271,8 @@ static void drm_dp_mst_destroy_state(struct
drm_private_obj *obj,
int i;
list_for_each_entry_safe(pos, tmp, &mst_state->payloads, next) {
- /* We only keep references to ports with non-zero VCPIs */
- if (pos->time_slots)
+ /* We only keep references to ports with active payloads */
+ if (!pos->delete)
drm_dp_mst_put_port_malloc(pos->port);
kfree(pos);
}
@@ -5400,7 +5400,7 @@ drm_dp_mst_atomic_check_payload_alloc_limits(struct
drm_dp_mst_topology_mgr *mgr
list_for_each_entry(payload, &mst_state->payloads, next) {
/* Releasing payloads is always OK-even if the port is gone */
- if (!payload->time_slots) {
+ if (payload->delete) {
drm_dbg_atomic(mgr->dev, "[MST PORT:%p] releases all
time slots\n",
payload->port);
continue;
diff --git a/include/drm/display/drm_dp_mst_helper.h
b/include/drm/display/drm_dp_mst_helper.h
index b9c361b242ea..8b847836a0b4 100644
--- a/include/drm/display/drm_dp_mst_helper.h
+++ b/include/drm/display/drm_dp_mst_helper.h
@@ -560,8 +560,11 @@ struct drm_dp_mst_atomic_payload {
int time_slots;
/** @pbn: The payload bandwidth for this payload */
int pbn;
+
+ /** @delete: Whether or not we intend to delete this payload during
this atomic commit */
+ bool delete : 1;
/** @dsc_enabled: Whether or not this payload has DSC enabled */
- bool dsc_enabled;
+ bool dsc_enabled : 1;
/** @next: The list node for this payload */
struct list_head next;
--
2.37.1
[RFC v4 09/17] drm/display/dp_mst: Don't open code modeset checks for releasing time slots
I'm not sure why, but at the time I originally wrote the find/release time
slot helpers I thought we should avoid keeping modeset tracking out of the
MST helpers. In retrospect though there's no actual good reason to do
this, and the logic has ended up being identical across all the drivers
using the helpers. Also, it needs to be fixed anyway so we don't break
things when going atomic-only with MST.
So, let's just move this code into drm_dp_atomic_release_time_slots() and
stop open coding it.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
Cc: Jani Nikula
Cc: Imre Deak
Cc: Daniel Vetter
Cc: Sean Paul
Acked-by: Jani Nikula
---
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 29 +++
drivers/gpu/drm/display/drm_dp_mst_topology.c | 21 --
drivers/gpu/drm/i915/display/intel_dp_mst.c | 24 +--
drivers/gpu/drm/nouveau/dispnv50/disp.c | 21 --
4 files changed, 23 insertions(+), 72 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 655d63b20b33..7a0d6cfa77f5 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -447,34 +447,13 @@ dm_dp_mst_detect(struct drm_connector *connector,
}
static int dm_dp_mst_atomic_check(struct drm_connector *connector,
- struct drm_atomic_state *state)
+ struct drm_atomic_state *state)
{
- struct drm_connector_state *new_conn_state =
- drm_atomic_get_new_connector_state(state, connector);
- struct drm_connector_state *old_conn_state =
- drm_atomic_get_old_connector_state(state, connector);
struct amdgpu_dm_connector *aconnector =
to_amdgpu_dm_connector(connector);
- struct drm_crtc_state *new_crtc_state;
- struct drm_dp_mst_topology_mgr *mst_mgr;
- struct drm_dp_mst_port *mst_port;
+ struct drm_dp_mst_topology_mgr *mst_mgr =
&aconnector->mst_port->mst_mgr;
+ struct drm_dp_mst_port *mst_port = aconnector->port;
- mst_port = aconnector->port;
- mst_mgr = &aconnector->mst_port->mst_mgr;
-
- if (!old_conn_state->crtc)
- return 0;
-
- if (new_conn_state->crtc) {
- new_crtc_state = drm_atomic_get_new_crtc_state(state,
new_conn_state->crtc);
- if (!new_crtc_state ||
- !drm_atomic_crtc_needs_modeset(new_crtc_state) ||
- new_crtc_state->enable)
- return 0;
- }
-
- return drm_dp_atomic_release_time_slots(state,
- mst_mgr,
- mst_port);
+ return drm_dp_atomic_release_time_slots(state, mst_mgr, mst_port);
}
static const struct drm_connector_helper_funcs
dm_dp_mst_connector_helper_funcs = {
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index d701e5b819b8..aa6dcd9ff6a5 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -4473,14 +4473,29 @@ int drm_dp_atomic_release_time_slots(struct
drm_atomic_state *state,
{
struct drm_dp_mst_topology_state *topology_state;
struct drm_dp_mst_atomic_payload *payload;
- struct drm_connector_state *conn_state;
+ struct drm_connector_state *old_conn_state, *new_conn_state;
+
+ old_conn_state = drm_atomic_get_old_connector_state(state,
port->connector);
+ if (!old_conn_state->crtc)
+ return 0;
+
+ /* If the CRTC isn't disabled by this state, don't release it's payload
*/
+ new_conn_state = drm_atomic_get_new_connector_state(state,
port->connector);
+ if (new_conn_state->crtc) {
+ struct drm_crtc_state *crtc_state =
+ drm_atomic_get_new_crtc_state(state,
new_conn_state->crtc);
+
+ if (!crtc_state ||
+ !drm_atomic_crtc_needs_modeset(crtc_state) ||
+ crtc_state->enable)
+ return 0;
+ }
topology_state = drm_atomic_get_mst_topology_state(state, mgr);
if (IS_ERR(topology_state))
return PTR_ERR(topology_state);
- conn_state = drm_atomic_get_old_connector_state(state, port->connector);
- topology_state->pending_crtc_mask |= drm_crtc_mask(conn_state->crtc);
+ topology_state->pending_crtc_mask |=
drm_crtc_mask(old_conn_state->crtc);
payload = drm_atomic_get_mst_payload_state(topology_state, port);
if (WARN_ON(!payload)) {
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 1cebbc51d8fa..1b067cd73261 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst
[RFC v4 16/17] drm/radeon: Drop legacy MST support
Right now, radeon is technically the only non-atomic driver still making
use of the MST helpers - and thus the final user of all of the legacy MST
helpers. Originally I was going to look into seeing if we could move legacy
MST into the radeon driver itself, however:
* SI and CIK both can use amdgpu, which still supports MST
* It currently doesn't work according to my own testing. I'm sure with some
troubleshooting we could likely fix it, but that brings me to point #2:
* It was never actually enabled by default, and is still marked as
experimental in the module parameter description
* If people were using it, someone probably would have probably seen a bug
report about how it is currently not functional by now. That certainly
doesn't appear to be the case, since before getting access to my own
hardware I had to go out of my way to try finding someone to help test
whether this legacy MST code even works - even amongst AMD employees.
* Getting rid of this code and only having atomic versions of the MST
helpers to maintain is likely going to be a lot easier in the long run,
and will make it a lot easier for others contributing to this code to
follow along with what's happening.
FWIW - if anyone still wants this code to be in the tree and has a good
idea of how to support this without needing to maintain the legacy MST
helpers (trying to move them would probably be acceptable), I'm happy to
suggestions. But my hope is that we can just drop this code and forget
about it. I've already run this idea by Harry Wentland and Alex Deucher a
few times as well.
Signed-off-by: Lyude Paul
Cc: Wayne Lin
Cc: Ville Syrjälä
Cc: Fangzhi Zuo
Cc: Jani Nikula
Cc: Imre Deak
Cc: Daniel Vetter
Cc: Sean Paul
Acked-by: Alex Deucher
Acked-by: Jani Nikula
---
drivers/gpu/drm/radeon/Makefile| 2 +-
drivers/gpu/drm/radeon/atombios_crtc.c | 11 +-
drivers/gpu/drm/radeon/atombios_encoders.c | 59 --
drivers/gpu/drm/radeon/radeon_atombios.c | 2 -
drivers/gpu/drm/radeon/radeon_connectors.c | 61 +-
drivers/gpu/drm/radeon/radeon_device.c | 1 -
drivers/gpu/drm/radeon/radeon_dp_mst.c | 778 -
drivers/gpu/drm/radeon/radeon_drv.c| 4 -
drivers/gpu/drm/radeon/radeon_encoders.c | 14 +-
drivers/gpu/drm/radeon/radeon_irq_kms.c| 10 +-
drivers/gpu/drm/radeon/radeon_mode.h | 40 --
11 files changed, 7 insertions(+), 975 deletions(-)
delete mode 100644 drivers/gpu/drm/radeon/radeon_dp_mst.c
diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile
index e3ab3aca1396..bb4e56f2f170 100644
--- a/drivers/gpu/drm/radeon/Makefile
+++ b/drivers/gpu/drm/radeon/Makefile
@@ -49,7 +49,7 @@ radeon-y += radeon_device.o radeon_asic.o radeon_kms.o \
rv770_smc.o cypress_dpm.o btc_dpm.o sumo_dpm.o sumo_smc.o trinity_dpm.o
\
trinity_smc.o ni_dpm.o si_smc.o si_dpm.o kv_smc.o kv_dpm.o ci_smc.o \
ci_dpm.o dce6_afmt.o radeon_vm.o radeon_ucode.o radeon_ib.o \
- radeon_sync.o radeon_audio.o radeon_dp_auxch.o radeon_dp_mst.o
+ radeon_sync.o radeon_audio.o radeon_dp_auxch.o
radeon-$(CONFIG_MMU_NOTIFIER) += radeon_mn.o
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
b/drivers/gpu/drm/radeon/atombios_crtc.c
index 69f1bc073902..d28d3acb3ba1 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -617,13 +617,6 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
}
}
- if (radeon_encoder->is_mst_encoder) {
- struct radeon_encoder_mst *mst_enc = radeon_encoder->enc_priv;
- struct radeon_connector_atom_dig *dig_connector =
mst_enc->connector->con_priv;
-
- dp_clock = dig_connector->dp_clock;
- }
-
/* use recommended ref_div for ss */
if (radeon_encoder->devices & (ATOM_DEVICE_LCD_SUPPORT)) {
if (radeon_crtc->ss_enabled) {
@@ -972,9 +965,7 @@ static bool atombios_crtc_prepare_pll(struct drm_crtc
*crtc, struct drm_display_
radeon_crtc->bpc = 8;
radeon_crtc->ss_enabled = false;
- if (radeon_encoder->is_mst_encoder) {
- radeon_dp_mst_prepare_pll(crtc, mode);
- } else if ((radeon_encoder->active_device & (ATOM_DEVICE_LCD_SUPPORT |
ATOM_DEVICE_DFP_SUPPORT)) ||
+ if ((radeon_encoder->active_device & (ATOM_DEVICE_LCD_SUPPORT |
ATOM_DEVICE_DFP_SUPPORT)) ||
(radeon_encoder_get_dp_bridge_encoder_id(radeon_crtc->encoder) !=
ENCODER_OBJECT_ID_NONE)) {
struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
struct drm_connector *connector =
diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c
b/drivers/gpu/drm/radeon/atombios_encoders.c
index c93040e60d04..0eae05dfb385 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -667,15 +667,7 @@ atombios_get_encoder_mode(struct drm_encoder *encoder)
[RFC v4 17/17] drm/display/dp_mst: Move all payload info into the atomic state
Now that we've finally gotten rid of the non-atomic MST users leftover in the kernel, we can finally get rid of all of the legacy payload code we have and move as much as possible into the MST atomic state structs. The main purpose of this is to make the MST code a lot less confusing to work on, as there's a lot of duplicated logic that doesn't really need to be here. As well, this should make introducing features like fallback link retraining and DSC support far easier. Since the old payload code was pretty gnarly and there's a Lot of changes here, I expect this might be a bit difficult to review. So to make things as easy as possible for reviewers, I'll sum up how both the old and new code worked here (it took me a while to figure this out too!). The old MST code basically worked by maintaining two different payload tables - proposed_vcpis, and payloads. proposed_vcpis would hold the modified payload we wanted to push to the topology, while payloads held the payload table that was currently programmed in hardware. Modifications to proposed_vcpis would be handled through drm_dp_allocate_vcpi(), drm_dp_mst_deallocate_vcpi(), and drm_dp_mst_reset_vcpi_slots(). Then, they would be pushed via drm_dp_mst_update_payload_step1() and drm_dp_mst_update_payload_step2(). Furthermore, it's important to note how adding and removing VC payloads actually worked with drm_dp_mst_update_payload_step1(). When a VC payload is removed from the VC table, all VC payloads which come after the removed VC payload's slots must have their time slots shifted towards the start of the table. The old code handles this by looping through the entire payload table and recomputing the start slot for every payload in the topology from scratch. While very much overkill, this ends up doing the right thing because we always order the VCPIs for payloads from first to last starting timeslot. It's important to also note that drm_dp_mst_update_payload_step2() isn't actually limited to updating a single payload - the driver can use it to queue up multiple payload changes so that as many of them can be sent as possible before waiting for the ACT. This is -technically- not against spec, but as Wayne Lin has pointed out it's not consistently implemented correctly in hubs - so it might as well be. drm_dp_mst_update_payload_step2() is pretty self explanatory and basically the same between the old and new code, save for the fact we don't have a second step for deleting payloads anymore -and thus rename it to drm_dp_mst_add_payload_step2(). The new payload code stores all of the current payload info within the MST atomic state and computes as much of the state as possible ahead of time. This has the one exception of the starting timeslots for payloads, which can't be determined at atomic check time since the starting time slots will vary depending on what order CRTCs are enabled in the atomic state - which varies from driver to driver. These are still stored in the atomic MST state, but are only copied from the old MST state during atomic commit time. Likewise, this is when new start slots are determined. Adding/removing payloads now works much more closely to how things are described in the spec. When we delete a payload, we loop through the current list of payloads and update the start slots for any payloads whose time slots came after the payload we just deleted. Determining the starting time slots for new payloads being added is done by simply keeping track of where the end of the VC table is in drm_dp_mst_topology_mgr->next_start_slot. Additionally, it's worth noting that we no longer have a single update_payload() function. Instead, we now have drm_dp_mst_add_payload_step1|2() and drm_dp_mst_remove_payload(). As such, it's now left it up to the driver to figure out when to add or remove payloads. The driver already knows when it's disabling/enabling CRTCs, so it also already knows when payloads should be added or removed. Changes since v1: * Refactor around all of the completely dead code changes that are happening in amdgpu for some reason when they really shouldn't even be there in the first place… :\ * Remove mention of sending one ACT per series of payload updates. As Wayne Lin pointed out, there are apparently hubs on the market that don't work correctly with this scheme and require a separate ACT per payload update. * Fix accidental drop of mst_mgr.lock - Wayne Lin * Remove mentions of allowing multiple ACT updates per payload change, mention that this is a result of vendors not consistently supporting this part of the spec and requiring a unique ACT for each payload change. * Get rid of reference to drm_dp_mst_port in DC - turns out I just got myself confused by DC and we don't actually need this. Changes since v2: * Get rid of fix for not sending payload deallocations if ddps=0 and just go back to wayne's fix Signed-off-by: Lyude Paul Cc: Wayne Lin Cc: Ville Syrjälä Cc: Fangzhi Zuo Cc: Jani Nikula Cc: Imre Deak
Re: [PATCH v2 01/29] ACPI: video: Add acpi_video_backlight_use_native() helper
On 8/17/22 10:05 AM, Hans de Goede wrote:
Hi Daniel,
On 8/2/22 18:49, Daniel Dadap wrote:
On 8/2/22 06:31, Hans de Goede wrote:
Hi Daniel,
On 7/21/22 23:30, Daniel Dadap wrote:
On 7/21/22 16:24, Daniel Dadap wrote:
On 7/12/22 14:38, Hans de Goede wrote:
ATM on x86 laptops where we want userspace to use the acpi_video backlight
device we often register both the GPU's native backlight device and
acpi_video's firmware acpi_video# backlight device. This relies on
userspace preferring firmware type backlight devices over native ones, but
registering 2 backlight devices for a single display really is undesirable.
On x86 laptops where the native GPU backlight device should be used,
the registering of other backlight devices is avoided by their drivers
using acpi_video_get_backlight_type() and only registering their backlight
if the return value matches their type.
acpi_video_get_backlight_type() uses
backlight_device_get_by_type(BACKLIGHT_RAW) to determine if a native
driver is available and will never return native if this returns
false. This means that the GPU's native backlight registering code
cannot just call acpi_video_get_backlight_type() to determine if it
should register its backlight, since acpi_video_get_backlight_type() will
never return native until the native backlight has already registered.
To fix this add a new internal native function parameter to
acpi_video_get_backlight_type(), which when set to true will make
acpi_video_get_backlight_type() behave as if a native backlight has
already been registered.
And add a new acpi_video_backlight_use_native() helper, which sets this
to true, for use in native GPU backlight code.
Changes in v2:
- Replace adding a native parameter to acpi_video_get_backlight_type() with
adding a new acpi_video_backlight_use_native() helper.
Signed-off-by: Hans de Goede
---
drivers/acpi/video_detect.c | 24
include/acpi/video.h | 5 +
2 files changed, 25 insertions(+), 4 deletions(-)
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index becc198e4c22..4346c990022d 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -17,8 +17,9 @@
* Otherwise vendor specific drivers like thinkpad_acpi, asus-laptop,
* sony_acpi,... can take care about backlight brightness.
*
- * Backlight drivers can use acpi_video_get_backlight_type() to determine
- * which driver should handle the backlight.
+ * Backlight drivers can use acpi_video_get_backlight_type() to determine which
+ * driver should handle the backlight. RAW/GPU-driver backlight drivers must
+ * use the acpi_video_backlight_use_native() helper for this.
*
* If CONFIG_ACPI_VIDEO is neither set as "compiled in" (y) nor as a module
(m)
* this file will not be compiled and acpi_video_get_backlight_type() will
@@ -548,9 +549,10 @@ static int acpi_video_backlight_notify(struct
notifier_block *nb,
* Arguably the native on win8 check should be done first, but that would
* be a behavior change, which may causes issues.
*/
-enum acpi_backlight_type acpi_video_get_backlight_type(void)
+static enum acpi_backlight_type __acpi_video_get_backlight_type(bool native)
{
static DEFINE_MUTEX(init_mutex);
+ static bool native_available;
static bool init_done;
static long video_caps;
@@ -570,6 +572,8 @@ enum acpi_backlight_type
acpi_video_get_backlight_type(void)
backlight_notifier_registered = true;
init_done = true;
}
+ if (native)
+ native_available = true;
mutex_unlock(&init_mutex);
if (acpi_backlight_cmdline != acpi_backlight_undef)
@@ -581,13 +585,25 @@ enum acpi_backlight_type
acpi_video_get_backlight_type(void)
if (!(video_caps & ACPI_VIDEO_BACKLIGHT))
return acpi_backlight_vendor;
- if (acpi_osi_is_win8() && backlight_device_get_by_type(BACKLIGHT_RAW))
+ if (acpi_osi_is_win8() &&
+ (native_available || backlight_device_get_by_type(BACKLIGHT_RAW)))
return acpi_backlight_native;
return acpi_backlight_video;
So I ran into a minor problem when testing the NVIDIA proprietary driver
against this change set, after checking acpi_video_backlight_use_native()
before registering the NVIDIA proprietary driver's backlight handler. Namely,
for the case where a user installs the NVIDIA proprietary driver after the
video.ko has already registered its backlight handler, we end up with both the
firmware and native handlers registered simultaneously, since the ACPI video
driver no longer unregisters its backlight handler. In this state, desktop
environments end up preferring the registered but non-functional firmware
handler from video.ko. (Manually twiddling the sysfs interface for the native
NVIDIA handler works fine.) When rebooting the system after installing the
NVIDIA proprietary driver, it is able to register its native handler be
Re: build failure of next-20220811 due to b1a63a0b48ad ("drm/amd/display: consider DSC pass-through during mode validation")
On Wed, Aug 17, 2022 at 12:43 AM Stephen Rothwell wrote:
>
> Hi all,
>
> On Fri, 12 Aug 2022 09:07:31 +1000 Stephen Rothwell
> wrote:
> >
> > On Thu, 11 Aug 2022 18:10:48 +0100 "Sudip Mukherjee (Codethink)"
> > wrote:
> > >
> > > Not sure if it has been reported, builds of riscv, alpha, s390, arm,
> > > arm64, xtensa, mips, csky allmodconfig have failed to build next-20220811
> > > with the error:
> > >
> > > ERROR: modpost: "dc_dsc_compute_bandwidth_range"
> > > [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
> > > ERROR: modpost: "dc_dsc_get_policy_for_timing"
> > > [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
> > >
> > > git bisect pointed to b1a63a0b48ad ("drm/amd/display: consider DSC
> > > pass-through during mode validation")
> > > And, reverting that commit has fixed the build failure.
> > >
> > > I will be happy to test any patch or provide any extra log if needed.
> >
> > I have reverted that commit in today's linux-next.
>
> I have removed that revert. Sudip, can you recheck when linux-next is
> released, please?
The build failure is not seen with next-20220817.
--
Regards
Sudip
Re: [PATCH] drm/msm/dsi: Set panel orientation when directly connected
Hi,
On Wed, Jul 20, 2022 at 3:42 PM Doug Anderson wrote:
>
> Hi,
>
> On Wed, Jul 20, 2022 at 1:46 PM Rob Clark wrote:
> >
> > On Fri, Jul 8, 2022 at 8:25 AM Doug Anderson wrote:
> > >
> > > Hi,
> > >
> > > On Wed, Jul 6, 2022 at 12:14 PM Stephen Boyd wrote:
> > > >
> > > > Set the panel orientation in drm when the panel is directly connected,
> > > > i.e. we're not using an external bridge. The external bridge case is
> > > > already handled by the panel bridge code, so we only update the path we
> > > > take when the panel is directly connected/internal. This silences a
> > > > warning splat coming from __drm_mode_object_add() on Wormdingler boards.
> > > >
> > > > Cc: Hsin-Yi Wang
> > > > Cc: Douglas Anderson
> > > > Signed-off-by: Stephen Boyd
> > > > ---
> > > >
> > > > This relies on commit 5e41b01a7808 ("drm/panel: Add an API to allow drm
> > > > to set orientation from panel") which is in drm-misc
> > > >
> > > > drivers/gpu/drm/msm/dsi/dsi_manager.c | 2 ++
> > > > 1 file changed, 2 insertions(+)
> > >
> > > I don't personally have objections to this, but (to my understanding)
> > > "the future" is that everyone should use panel_bridge. If we made the
> > > move to panel_bridge today then we wouldn't need to do this. In
> > > general I think panel_bridge would end up letting us delete a bunch of
> > > code...
> > >
> > > See commit 4e5763f03e10 ("drm/bridge: ti-sn65dsi86: Wrap panel with
> > > panel-bridge") for when this was done by ti-sn65dsi86.
> > >
> > > Then again, I spent a small amount of time looking into this and it's
> > > definitely non-trivial. Still likely worthwhile, but not worth
> > > blocking a tiny fix like this. It also should be fairly obvious that
> > > we should delete this when we switch to panel_bridge.
> > >
> > > Thus:
> > >
> > > Reviewed-by: Douglas Anderson
> > >
> > > I'll assume that we'll just snooze this commit until drm-misc-next
> > > merges into a tree that msm-next is based on, which will probably be
> > > the next -rc1. If desired and Acked I could land this in
> > > drm-misc-next, but it's probably not worth it?
> >
> > if you want to land this patch via drm-misc, which might be the
> > easier/faster route, then:
> >
> > Acked-by: Rob Clark
>
> As per discussion on IRC, I'm not going to apply this to drm-misc-next.
>
> Given where we are in the cycle landing in drm-misc-next means it
> won't be in mainline for a couple versions and I suspect that'll cause
> merge conflicts with Dmitry's series [1]. ...and, of course, if
> Dmitry's series lands then we don't even need ${SUBJECT} patch...
>
> So I think the plan is:
>
> 1. Snooze waiting for the next -rc1 since
> drm_connector_set_orientation_from_panel() won't be in mainline until
> then.
>
> 2. If Dmitry's series looks like a long way off, we could land
> ${SUBJECT} patch in msm-next as a stopgap fix.
>
>
> [1]
> https://lore.kernel.org/r/20220711094320.368062-5-dmitry.barysh...@linaro.org/
Just checking up. What's the latest thinking here? Do we want to land
Stephen's change as a stopgap?
drm_connector_set_orientation_from_panel() is available in v6.0-rc1.
-Doug
Re: [BUG][5.20] refcount_t: underflow; use-after-free
On Wed, Aug 17, 2022 at 11:43 PM Maíra Canal wrote:
>
> Hi Mikhail,
>
> Looks like 45ecaea738830b9d521c93520c8f201359dcbd95 ("drm/sched: Partial
> revert of 'drm/sched: Keep s_fence->parent pointer'") introduced the
> error. Try reverting it and check if the use-after-free still happens.
Thanks, but unfortunately, this did not lead to the expected result.
Again happens use-after-free in an incomprehensible context.
>From the new: added warning "suspicious RCU usage" but it looks like
it is completely not related to the use-after-free issue.
[ 215.434115] [ cut here ]
[ 215.434184] refcount_t: underflow; use-after-free.
[ 215.434204] WARNING: CPU: 7 PID: 1258 at lib/refcount.c:28
refcount_warn_saturate+0xba/0x110
[ 215.434214] Modules linked in: uinput rfcomm snd_seq_dummy
snd_hrtimer nft_objref nf_conntrack_netbios_ns nf_conntrack_broadcast
nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet
nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat
nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables nfnetlink
qrtr bnep sunrpc binfmt_misc snd_seq_midi snd_seq_midi_event
intel_rapl_msr intel_rapl_common snd_hda_codec_realtek vfat
snd_hda_codec_generic snd_hda_codec_hdmi mt76x2u fat mt76x2_common
snd_hda_intel mt76x02_usb snd_intel_dspcfg snd_intel_sdw_acpi mt76_usb
iwlmvm edac_mce_amd snd_usb_audio snd_hda_codec mt76x02_lib
snd_hda_core snd_usbmidi_lib snd_hwdep snd_rawmidi uvcvideo mt76
kvm_amd snd_seq videobuf2_vmalloc videobuf2_memops snd_seq_device
mac80211 videobuf2_v4l2 videobuf2_common kvm btusb iwlwifi snd_pcm
btrtl videodev libarc4 eeepc_wmi btbcm asus_wmi iwlmei btintel
ledtrig_audio xpad irqbypass sparse_keymap btmtk platform_profile
joydev
[ 215.434436] hid_logitech_hidpp rapl ff_memless mc snd_timer
bluetooth cfg80211 video pcspkr wmi_bmof snd soundcore k10temp
i2c_piix4 rfkill mei asus_ec_sensors acpi_cpufreq zram amdgpu
drm_ttm_helper ttm iommu_v2 ucsi_ccg gpu_sched crct10dif_pclmul
crc32_pclmul typec_ucsi drm_buddy crc32c_intel ghash_clmulni_intel ccp
igb sp5100_tco typec drm_display_helper nvme dca nvme_core cec wmi
ip6_tables ip_tables fuse
[ 215.434528] Unloaded tainted modules: amd64_edac():1 amd64_edac():1
amd64_edac():1 amd64_edac():1 amd64_edac():1 amd64_edac():1
amd64_edac():1 amd64_edac():1 amd64_edac():1 amd64_edac():1
amd64_edac():1 pcc_cpufreq():1 amd64_edac():1 pcc_cpufreq():1
pcc_cpufreq():1 amd64_edac():1 amd64_edac():1 pcc_cpufreq():1
pcc_cpufreq():1 amd64_edac():1 amd64_edac():1 pcc_cpufreq():1
amd64_edac():1 pcc_cpufreq():1 amd64_edac():1 pcc_cpufreq():1
amd64_edac():1 pcc_cpufreq():1 amd64_edac():1 pcc_cpufreq():1
amd64_edac():1 pcc_cpufreq():1 amd64_edac():1 pcc_cpufreq():1
amd64_edac():1 pcc_cpufreq():1 amd64_edac():1 pcc_cpufreq():1
amd64_edac():1 pcc_cpufreq():1 pcc_cpufreq():1 amd64_edac():1
amd64_edac():1 pcc_cpufreq():1 pcc_cpufreq():1 amd64_edac():1
pcc_cpufreq():1 amd64_edac():1 pcc_cpufreq():1 pcc_cpufreq():1
amd64_edac():1 pcc_cpufreq():1 pcc_cpufreq():1 amd64_edac():1
pcc_cpufreq():1 amd64_edac():1 pcc_cpufreq():1 pcc_cpufreq():1
pcc_cpufreq():1 pcc_cpufreq():1 pcc_cpufreq():1 fjes():1
[ 215.434672] pcc_cpufreq():1 fjes():1 pcc_cpufreq():1 fjes():1
pcc_cpufreq():1 fjes():1 fjes():1 fjes():1 fjes():1 fjes():1
[ 215.434702] CPU: 7 PID: 1258 Comm: kworker/7:3 Tainted: G W L
--- --- 6.0.0-0.rc1.20220817git3cc40a443a04.14.fc38.x86_64 #1
[ 215.434709] Hardware name: System manufacturer System Product
Name/ROG STRIX X570-I GAMING, BIOS 4403 04/27/2022
[ 215.434715] Workqueue: events drm_sched_entity_kill_jobs_work [gpu_sched]
[ 215.434728] RIP: 0010:refcount_warn_saturate+0xba/0x110
[ 215.434734] Code: 01 01 e8 59 59 6f 00 0f 0b e9 22 46 a5 00 80 3d be
7d be 01 00 75 85 48 c7 c7 c0 99 8e 92 c6 05 ae 7d be 01 01 e8 36 59
6f 00 <0f> 0b e9 ff 45 a5 00 80 3d 99 7d be 01 00 0f 85 5e ff ff ff 48
c7
[ 215.434740] RSP: 0018:9ccb0237fe60 EFLAGS: 00010286
[ 215.434747] RAX: 0026 RBX: 8d531f6f2828 RCX:
[ 215.434753] RDX: 0001 RSI: 928d07a4 RDI:
[ 215.434757] RBP: 8d61e47f5600 R08: R09: 9ccb0237fd10
[ 215.434762] R10: 0003 R11: 8d622e2fffe8 R12: 8d61e47fc800
[ 215.434767] R13: 8d5313e95500 R14: 8d61e47fc805 R15: 8d531f6f2830
[ 215.434772] FS: () GS:8d61e460()
knlGS:
[ 215.434777] CS: 0010 DS: ES: CR0: 80050033
[ 215.434782] CR2: 7f0c8b815048 CR3: 0001ab0e8000 CR4: 00350ee0
[ 215.434788] Call Trace:
[ 215.434792]
[ 215.434797] process_one_work+0x2a0/0x600
[ 215.434819] worker_thread+0x4f/0x3a0
[ 215.434830] ? process_one_work+0x600/0x600
[ 215.434836] kthread+0xf5/0x120
[ 215.434842] ? kthread_complete_and_exit+0x20/0x20
[ 215.434854] ret_from_fork+0x22/0x30
[ 215.434881]
[ 215.434885] irq event stamp: 134873
[ 215.434890] hardirqs last enabled at (134881): []
__up_console_sem+0x5e/0x70
[ 215.434897] hardirqs l
[PATCH v2 1/2] drm/cmdline-parser: Merge negative tests
Negative tests can be expressed as a single parameterized test case,
which highlights that we're following the same test logic (passing
invalid cmdline and expecting drm_mode_parse_command_line_for_connector
to fail), which improves readability.
v2: s/negative/invalid to be consistent with other testcases in DRM
Signed-off-by: Michał Winiarski
Tested-by: Maíra Canal
---
.../gpu/drm/tests/drm_cmdline_parser_test.c | 293 ++
1 file changed, 103 insertions(+), 190 deletions(-)
diff --git a/drivers/gpu/drm/tests/drm_cmdline_parser_test.c
b/drivers/gpu/drm/tests/drm_cmdline_parser_test.c
index 59b29cdfdd35..3a46c7d6f2aa 100644
--- a/drivers/gpu/drm/tests/drm_cmdline_parser_test.c
+++ b/drivers/gpu/drm/tests/drm_cmdline_parser_test.c
@@ -109,24 +109,6 @@ static void drm_cmdline_test_force_d_only(struct kunit
*test)
KUNIT_EXPECT_EQ(test, mode.force, DRM_FORCE_OFF);
}
-static void drm_cmdline_test_margin_only(struct kunit *test)
-{
- struct drm_cmdline_mode mode = { };
- const char *cmdline = "m";
-
- KUNIT_EXPECT_FALSE(test,
drm_mode_parse_command_line_for_connector(cmdline,
-
&no_connector, &mode));
-}
-
-static void drm_cmdline_test_interlace_only(struct kunit *test)
-{
- struct drm_cmdline_mode mode = { };
- const char *cmdline = "i";
-
- KUNIT_EXPECT_FALSE(test,
drm_mode_parse_command_line_for_connector(cmdline,
-
&no_connector, &mode));
-}
-
static void drm_cmdline_test_res(struct kunit *test)
{
struct drm_cmdline_mode mode = { };
@@ -149,42 +131,6 @@ static void drm_cmdline_test_res(struct kunit *test)
KUNIT_EXPECT_EQ(test, mode.force, DRM_FORCE_UNSPECIFIED);
}
-static void drm_cmdline_test_res_missing_x(struct kunit *test)
-{
- struct drm_cmdline_mode mode = { };
- const char *cmdline = "x480";
-
- KUNIT_EXPECT_FALSE(test,
drm_mode_parse_command_line_for_connector(cmdline,
-
&no_connector, &mode));
-}
-
-static void drm_cmdline_test_res_missing_y(struct kunit *test)
-{
- struct drm_cmdline_mode mode = { };
- const char *cmdline = "1024x";
-
- KUNIT_EXPECT_FALSE(test,
drm_mode_parse_command_line_for_connector(cmdline,
-
&no_connector, &mode));
-}
-
-static void drm_cmdline_test_res_bad_y(struct kunit *test)
-{
- struct drm_cmdline_mode mode = { };
- const char *cmdline = "1024xtest";
-
- KUNIT_EXPECT_FALSE(test,
drm_mode_parse_command_line_for_connector(cmdline,
-
&no_connector, &mode));
-}
-
-static void drm_cmdline_test_res_missing_y_bpp(struct kunit *test)
-{
- struct drm_cmdline_mode mode = { };
- const char *cmdline = "1024x-24";
-
- KUNIT_EXPECT_FALSE(test,
drm_mode_parse_command_line_for_connector(cmdline,
-
&no_connector, &mode));
-}
-
static void drm_cmdline_test_res_vesa(struct kunit *test)
{
struct drm_cmdline_mode mode = { };
@@ -274,15 +220,6 @@ static void drm_cmdline_test_res_bpp(struct kunit *test)
KUNIT_EXPECT_EQ(test, mode.force, DRM_FORCE_UNSPECIFIED);
}
-static void drm_cmdline_test_res_bad_bpp(struct kunit *test)
-{
- struct drm_cmdline_mode mode = { };
- const char *cmdline = "720x480-test";
-
- KUNIT_EXPECT_FALSE(test,
drm_mode_parse_command_line_for_connector(cmdline,
-
&no_connector, &mode));
-}
-
static void drm_cmdline_test_res_refresh(struct kunit *test)
{
struct drm_cmdline_mode mode = { };
@@ -306,15 +243,6 @@ static void drm_cmdline_test_res_refresh(struct kunit
*test)
KUNIT_EXPECT_EQ(test, mode.force, DRM_FORCE_UNSPECIFIED);
}
-static void drm_cmdline_test_res_bad_refresh(struct kunit *test)
-{
- struct drm_cmdline_mode mode = { };
- const char *cmdline = "720x480@refresh";
-
- KUNIT_EXPECT_FALSE(test,
drm_mode_parse_command_line_for_connector(cmdline,
-
&no_connector, &mode));
-}
-
static void drm_cmdline_test_res_bpp_refresh(struct kunit *test)
{
struct drm_cmdline_mode mode = { };
@@ -411,15 +339,6 @@ static void
drm_cmdline_test_res_bpp_refresh_force_off(struct kunit *test)
KUNIT_EXPECT_EQ(test, mode.force, DRM_FORCE_OFF);
}
-static void drm_cmdline_test_res_bpp_refresh_force_on_off(struct kunit *test)
-{
- struct drm_cmdline_mode mode = { };
- const char *cmdline = "720x480-24@60de";
-
- KUNIT_EXPECT_FALSE(test,
drm_mode_parse_command_line_for_connector(cmdline,
-
[PATCH v2 2/2] drm/cmdline-parser: Use assert when needed
Expecting to observe a specific value, when the function responsible for
setting the value has failed will lead to extra noise in test output.
Use assert when the situation calls for it.
Also - very small tidying up around the changed areas (whitespace).
v2: Leave out the locals (drm_connector is huge) (lkp)
Signed-off-by: Michał Winiarski
---
.../gpu/drm/tests/drm_cmdline_parser_test.c | 80 +--
1 file changed, 40 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/tests/drm_cmdline_parser_test.c
b/drivers/gpu/drm/tests/drm_cmdline_parser_test.c
index 3a46c7d6f2aa..09b806e27506 100644
--- a/drivers/gpu/drm/tests/drm_cmdline_parser_test.c
+++ b/drivers/gpu/drm/tests/drm_cmdline_parser_test.c
@@ -16,7 +16,7 @@ static void drm_cmdline_test_force_e_only(struct kunit *test)
struct drm_cmdline_mode mode = { };
const char *cmdline = "e";
- KUNIT_EXPECT_TRUE(test,
drm_mode_parse_command_line_for_connector(cmdline,
+ KUNIT_ASSERT_TRUE(test,
drm_mode_parse_command_line_for_connector(cmdline,
&no_connector, &mode));
KUNIT_EXPECT_FALSE(test, mode.specified);
KUNIT_EXPECT_FALSE(test, mode.refresh_specified);
@@ -34,7 +34,7 @@ static void drm_cmdline_test_force_D_only_not_digital(struct
kunit *test)
struct drm_cmdline_mode mode = { };
const char *cmdline = "D";
- KUNIT_EXPECT_TRUE(test,
drm_mode_parse_command_line_for_connector(cmdline,
+ KUNIT_ASSERT_TRUE(test,
drm_mode_parse_command_line_for_connector(cmdline,
&no_connector, &mode));
KUNIT_EXPECT_FALSE(test, mode.specified);
KUNIT_EXPECT_FALSE(test, mode.refresh_specified);
@@ -56,7 +56,7 @@ static void drm_cmdline_test_force_D_only_hdmi(struct kunit
*test)
struct drm_cmdline_mode mode = { };
const char *cmdline = "D";
- KUNIT_EXPECT_TRUE(test,
drm_mode_parse_command_line_for_connector(cmdline,
+ KUNIT_ASSERT_TRUE(test,
drm_mode_parse_command_line_for_connector(cmdline,
&connector_hdmi, &mode));
KUNIT_EXPECT_FALSE(test, mode.specified);
KUNIT_EXPECT_FALSE(test, mode.refresh_specified);
@@ -78,7 +78,7 @@ static void drm_cmdline_test_force_D_only_dvi(struct kunit
*test)
struct drm_cmdline_mode mode = { };
const char *cmdline = "D";
- KUNIT_EXPECT_TRUE(test,
drm_mode_parse_command_line_for_connector(cmdline,
+ KUNIT_ASSERT_TRUE(test,
drm_mode_parse_command_line_for_connector(cmdline,
&connector_dvi, &mode));
KUNIT_EXPECT_FALSE(test, mode.specified);
KUNIT_EXPECT_FALSE(test, mode.refresh_specified);
@@ -96,7 +96,7 @@ static void drm_cmdline_test_force_d_only(struct kunit *test)
struct drm_cmdline_mode mode = { };
const char *cmdline = "d";
- KUNIT_EXPECT_TRUE(test,
drm_mode_parse_command_line_for_connector(cmdline,
+ KUNIT_ASSERT_TRUE(test,
drm_mode_parse_command_line_for_connector(cmdline,
&no_connector, &mode));
KUNIT_EXPECT_FALSE(test, mode.specified);
KUNIT_EXPECT_FALSE(test, mode.refresh_specified);
@@ -114,7 +114,7 @@ static void drm_cmdline_test_res(struct kunit *test)
struct drm_cmdline_mode mode = { };
const char *cmdline = "720x480";
- KUNIT_EXPECT_TRUE(test,
drm_mode_parse_command_line_for_connector(cmdline,
+ KUNIT_ASSERT_TRUE(test,
drm_mode_parse_command_line_for_connector(cmdline,
&no_connector, &mode));
KUNIT_EXPECT_TRUE(test, mode.specified);
KUNIT_EXPECT_EQ(test, mode.xres, 720);
@@ -136,7 +136,7 @@ static void drm_cmdline_test_res_vesa(struct kunit *test)
struct drm_cmdline_mode mode = { };
const char *cmdline = "720x480M";
- KUNIT_EXPECT_TRUE(test,
drm_mode_parse_command_line_for_connector(cmdline,
+ KUNIT_ASSERT_TRUE(test,
drm_mode_parse_command_line_for_connector(cmdline,
&no_connector, &mode));
KUNIT_EXPECT_TRUE(test, mode.specified);
KUNIT_EXPECT_EQ(test, mode.xres, 720);
@@ -158,7 +158,7 @@ static void drm_cmdline_test_res_vesa_rblank(struct kunit
*test)
struct drm_cmdline_mode mode = { };
const char *cmdline = "720x480MR";
- KUNIT_EXPECT_TRUE(test,
drm_mode_parse_command_line_for_connector(cmdline,
+ KUNIT_ASSERT_TRUE(test,
drm_mode_parse_command_line_for_connector(cmdline,
&no_connector, &mode));
KUNIT_EXPECT_TRUE(test, mode.specified);
KUNIT_EX
build failure of next-20220817 for amdgpu
Hi All, Not sure if it has been reported, build of next-20220817 fails with the error: ERROR: modpost: "cpu_smallcore_map" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! Trying to do a git bisect to find out the offending commit. I will be happy to test any patch or provide any extra log if needed. -- Regards Sudip
Re: [PATCH 1/6] drm/ttm: Add usage to ttm_validate_buffer.
Am 2022-08-12 um 21:27 schrieb Bas Nieuwenhuizen:
This way callsites can choose between READ/BOOKKEEP reservations.
Signed-off-by: Bas Nieuwenhuizen
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 5 +
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 9 +++--
drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 8 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 1 +
drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 1 +
drivers/gpu/drm/qxl/qxl_release.c| 1 +
drivers/gpu/drm/radeon/radeon_cs.c | 2 ++
drivers/gpu/drm/radeon/radeon_gem.c | 1 +
drivers/gpu/drm/radeon/radeon_vm.c | 2 ++
drivers/gpu/drm/ttm/ttm_execbuf_util.c | 3 +--
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 7 ++-
drivers/gpu/drm/vmwgfx/vmwgfx_validation.c | 1 +
include/drm/ttm/ttm_execbuf_util.h | 2 ++
15 files changed, 38 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 4608599ba6bb..a6eb7697c936 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -775,6 +775,7 @@ static void add_kgd_mem_to_kfd_bo_list(struct kgd_mem *mem,
INIT_LIST_HEAD(&entry->head);
entry->num_shared = 1;
+ entry->usage = DMA_RESV_USAGE_READ;
KFD code never calls ttm_eu_fence_buffer_objects. Does it make sense to
set this field at all in this case?
Furthermore, I remember reviewing an RFC patch series by Christian that
replaced all the execbuf_util functions with an iterator API. Is
Christian's work abandoned or still in progress? How will that interact
with your patch series?
Regards,
Felix
entry->bo = &bo->tbo;
mutex_lock(&process_info->lock);
if (userptr)
@@ -919,6 +920,7 @@ static int reserve_bo_and_vm(struct kgd_mem *mem,
ctx->kfd_bo.priority = 0;
ctx->kfd_bo.tv.bo = &bo->tbo;
ctx->kfd_bo.tv.num_shared = 1;
+ ctx->kfd_bo.tv.usage = DMA_RESV_USAGE_READ;
list_add(&ctx->kfd_bo.tv.head, &ctx->list);
amdgpu_vm_get_pd_bo(vm, &ctx->list, &ctx->vm_pd[0]);
@@ -982,6 +984,7 @@ static int reserve_bo_and_cond_vms(struct kgd_mem *mem,
ctx->kfd_bo.priority = 0;
ctx->kfd_bo.tv.bo = &bo->tbo;
ctx->kfd_bo.tv.num_shared = 1;
+ ctx->kfd_bo.tv.usage = DMA_RESV_USAGE_READ;
list_add(&ctx->kfd_bo.tv.head, &ctx->list);
i = 0;
@@ -2207,6 +2210,7 @@ static int validate_invalid_user_pages(struct
amdkfd_process_info *process_info)
list_add_tail(&mem->resv_list.head, &resv_list);
mem->resv_list.bo = mem->validate_list.bo;
mem->resv_list.num_shared = mem->validate_list.num_shared;
+ mem->resv_list.usage = mem->validate_list.usage;
}
/* Reserve all BOs and page tables for validation */
@@ -2406,6 +2410,7 @@ int amdgpu_amdkfd_gpuvm_restore_process_bos(void *info,
struct dma_fence **ef)
list_add_tail(&mem->resv_list.head, &ctx.list);
mem->resv_list.bo = mem->validate_list.bo;
mem->resv_list.num_shared = mem->validate_list.num_shared;
+ mem->resv_list.usage = mem->validate_list.usage;
}
ret = ttm_eu_reserve_buffers(&ctx.ticket, &ctx.list,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index d8f1335bc68f..f1ceb25d1b84 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -57,6 +57,7 @@ static int amdgpu_cs_user_fence_chunk(struct amdgpu_cs_parser
*p,
p->uf_entry.tv.bo = &bo->tbo;
/* One for TTM and two for the CS job */
p->uf_entry.tv.num_shared = 3;
+ p->uf_entry.tv.usage = DMA_RESV_USAGE_READ;
drm_gem_object_put(gobj);
@@ -522,8 +523,10 @@ static int amdgpu_cs_parser_bos(struct amdgpu_cs_parser *p,
mutex_lock(&p->bo_list->bo_list_mutex);
/* One for TTM and one for the CS job */
- amdgpu_bo_list_for_each_entry(e, p->bo_list)
+ amdgpu_bo_list_for_each_entry(e, p->bo_list) {
e->tv.num_shared = 2;
+ e->tv.usage = DMA_RESV_USAGE_READ;
+ }
amdgpu_bo_list_get_list(p->bo_list, &p->validated);
@@ -1282,8 +1285,10 @@ static int amdgpu_cs_submit(struct amdgpu_cs_parser *p,
amdgpu_vm_move_to_lru_tail(p->adev, &fpriv->vm);
/* Make sure all BOs are remembered as writers */
- amdgpu_bo_list_for_each_entry(e, p->bo_list)
+ amdgpu_bo_list_for_each_entry(e, p->bo_list) {
e->tv.num_shared = 0;
+ e->tv.usage = DMA_RESV_USAGE_WRITE;
+ }
ttm_eu_fence_buffer_objects(&p->ticket, &p->validated, p->fence);
mutex_unlo
Re: build failure of next-20220811 due to b1a63a0b48ad ("drm/amd/display: consider DSC pass-through during mode validation")
Hi Sudip,
On Wed, 17 Aug 2022 21:39:17 +0100 Sudip Mukherjee
wrote:
>
> On Wed, Aug 17, 2022 at 12:43 AM Stephen Rothwell
> wrote:
> >
> > On Fri, 12 Aug 2022 09:07:31 +1000 Stephen Rothwell
> > wrote:
> > >
> > > On Thu, 11 Aug 2022 18:10:48 +0100 "Sudip Mukherjee (Codethink)"
> > > wrote:
> > > >
> > > > Not sure if it has been reported, builds of riscv, alpha, s390, arm,
> > > > arm64, xtensa, mips, csky allmodconfig have failed to build
> > > > next-20220811
> > > > with the error:
> > > >
> > > > ERROR: modpost: "dc_dsc_compute_bandwidth_range"
> > > > [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
> > > > ERROR: modpost: "dc_dsc_get_policy_for_timing"
> > > > [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
> > > >
> > > > git bisect pointed to b1a63a0b48ad ("drm/amd/display: consider DSC
> > > > pass-through during mode validation")
> > > > And, reverting that commit has fixed the build failure.
> > > >
> > > > I will be happy to test any patch or provide any extra log if needed.
> > >
> > > I have reverted that commit in today's linux-next.
> >
> > I have removed that revert. Sudip, can you recheck when linux-next is
> > released, please?
>
> The build failure is not seen with next-20220817.
Excellent, thanks.
--
Cheers,
Stephen Rothwell
pgpQG482fU9Uv.pgp
Description: OpenPGP digital signature
Re: [PATCH] drm/ttm: prevent grabbing page references
On 8/15/22 16:08, Christian König wrote:
> TTM owns the pages it uses for backing buffer objects with system
> memory. Because of this it is absolutely illegal to mess around with
> the reference count of those pages.
>
> So make sure that nobody ever tries to grab an extra reference on
> pages allocated through the page pool.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/ttm/ttm_pool.c | 14 +-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
> index 1bba0a0ed3f9..cbca84dbd83f 100644
> --- a/drivers/gpu/drm/ttm/ttm_pool.c
> +++ b/drivers/gpu/drm/ttm/ttm_pool.c
> @@ -93,8 +93,17 @@ static struct page *ttm_pool_alloc_page(struct ttm_pool
> *pool, gfp_t gfp_flags,
>
> if (!pool->use_dma_alloc) {
> p = alloc_pages(gfp_flags, order);
> - if (p)
> + if (p) {
> p->private = order;
> +
> + /* The pages are fully owned by TTM and because of this
> + * it's illegal to grab extra references to it or
> + * otherwise we corrupt TTMs internal state. Make sure
> + * nobody tries to ever increase the reference count of
> + * those pages.
> + */
> + set_page_count(p, 0);
> + }
> return p;
> }
>
> @@ -144,6 +153,9 @@ static void ttm_pool_free_page(struct ttm_pool *pool,
> enum ttm_caching caching,
> #endif
>
> if (!pool || !pool->use_dma_alloc) {
> + /* See alloc why references to TTMs pages are illegal */
> + WARN_ON(page_count(p));
> + set_page_count(p, 1);
> __free_pages(p, order);
> return;
> }
Could you please explain why you're skipping the DMA pages?
--
Best regards,
Dmitry
Re: [PATCH v1 1/1] kfd: fixed memleak about release topology
Am 2022-07-15 um 04:07 schrieb ZhiJie.zhang: memleak will happend that reload module due to ignore kfree when release topology Signed-off-by: ZhiJie.zhang --- drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c index 8d50d207cf66..8b86f56bd50c 100644 --- a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c @@ -872,6 +872,7 @@ static void kfd_topology_release_sysfs(void) } kobject_del(sys_props.kobj_topology); kobject_put(sys_props.kobj_topology); + kfree(sys_props.kobj_topology); Sorry for the late response. This looks incorrect. kobjects are reference counted. The underlying memory should be freed by a callback when the reference count reaches 0 in kobject_put. Freeing the object here explicitly would lead to a double-free. The callback in this case is kfd_topology_kobj_release, which calls kfree. Am I missing anything? Regards, Felix sys_props.kobj_topology = NULL; } }
Re: [PATCH] drm/bridge: ps8640: Add double reset T4 and T5 to power-on sequence
Hi, On Mon, Aug 15, 2022 at 2:39 AM Hsin-Yi Wang wrote: > > The double reset power-on sequence is a workaround for the hardware > flaw in some chip that SPI Clock output glitch and cause internal MPU > unable to read firmware correctly. The sequence is suggested in ps8640 > application note. > > Signed-off-by: Hsin-Yi Wang > --- > drivers/gpu/drm/bridge/parade-ps8640.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c > b/drivers/gpu/drm/bridge/parade-ps8640.c > index 49107a6cdac18..d7483c13c569b 100644 > --- a/drivers/gpu/drm/bridge/parade-ps8640.c > +++ b/drivers/gpu/drm/bridge/parade-ps8640.c > @@ -375,6 +375,11 @@ static int __maybe_unused ps8640_resume(struct device > *dev) > gpiod_set_value(ps_bridge->gpio_reset, 1); > usleep_range(2000, 2500); > gpiod_set_value(ps_bridge->gpio_reset, 0); > + /* Double reset for T4 and T5 */ > + msleep(50); > + gpiod_set_value(ps_bridge->gpio_reset, 1); > + msleep(50); > + gpiod_set_value(ps_bridge->gpio_reset, 0); We really need another 100 ms here? ps8640 is already quite slow at powering itself up and that has a real user impact. Why was it only 2.5 ms for the first reset and 50 ms for the second? -Doug
Re: [PATCH v1] drm/ttm: Refcount allocated tail pages
On 8/15/22 18:54, Dmitry Osipenko wrote: > On 8/15/22 17:57, Dmitry Osipenko wrote: >> On 8/15/22 16:53, Christian König wrote: >>> Am 15.08.22 um 15:45 schrieb Dmitry Osipenko: [SNIP] > Well that comment sounds like KVM is doing the right thing, so I'm > wondering what exactly is going on here. KVM actually doesn't hold the page reference, it takes the temporal reference during page fault and then drops the reference once page is mapped, IIUC. Is it still illegal for TTM? Or there is a possibility for a race condition here? >>> >>> Well the question is why does KVM grab the page reference in the first >>> place? >>> >>> If that is to prevent the mapping from changing then yes that's illegal >>> and won't work. It can always happen that you grab the address, solve >>> the fault and then immediately fault again because the address you just >>> grabbed is invalidated. >>> >>> If it's for some other reason than we should probably investigate if we >>> shouldn't stop doing this. >> >> CC: +Paolo Bonzini who introduced this code >> >> commit add6a0cd1c5ba51b201e1361b05a5df817083618 >> Author: Paolo Bonzini >> Date: Tue Jun 7 17:51:18 2016 +0200 >> >> KVM: MMU: try to fix up page faults before giving up >> >> The vGPU folks would like to trap the first access to a BAR by setting >> vm_ops on the VMAs produced by mmap-ing a VFIO device. The fault >> handler >> then can use remap_pfn_range to place some non-reserved pages in the >> VMA. >> >> This kind of VM_PFNMAP mapping is not handled by KVM, but follow_pfn >> and fixup_user_fault together help supporting it. The patch also >> supports >> VM_MIXEDMAP vmas where the pfns are not reserved and thus subject to >> reference counting. >> >> @Paolo, >> https://lore.kernel.org/dri-devel/73e5ed8d-0d25-7d44-8fa2-e1d61b1f5...@amd.com/T/#m7647ce5f8c4749599d2c6bc15a2b45f8d8cf8154 >> > > If we need to bump the refcount only for VM_MIXEDMAP and not for > VM_PFNMAP, then perhaps we could add a flag for that to the kvm_main > code that will denote to kvm_release_page_clean whether it needs to put > the page? The other variant that kind of works is to mark TTM pages reserved using SetPageReserved/ClearPageReserved, telling KVM not to mess with the page struct. But the potential consequences of doing this are unclear to me. Christian, do you think we can do it? -- Best regards, Dmitry
Re: [PATCH v7 1/8] overflow: Move and add few utility macros into overflow
Hi Kees,
would you mind taking a look at this patch?
Thanks,
Andi
On Tue, Aug 16, 2022 at 06:35:18PM +0900, Gwan-gyeong Mun wrote:
> It moves overflows_type utility macro into overflow header from i915_utils
> header. The overflows_type can be used to catch the truncation between data
> types. And it adds safe_conversion() macro which performs a type conversion
> (cast) of an source value into a new variable, checking that the
> destination is large enough to hold the source value. And the functionality
> of overflows_type has been improved to handle the signbit.
> The is_unsigned_type macro has been added to check the sign bit of the
> built-in type.
>
> v3: Add is_type_unsigned() macro (Mauro)
> Modify overflows_type() macro to consider signed data types (Mauro)
> Fix the problem that safe_conversion() macro always returns true
> v4: Fix kernel-doc markups
> v6: Move macro addition location so that it can be used by other than drm
> subsystem (Jani, Mauro, Andi)
> Change is_type_unsigned to is_unsigned_type to have the same name form
> as is_signed_type macro
>
> Signed-off-by: Gwan-gyeong Mun
> Cc: Thomas Hellström
> Cc: Matthew Auld
> Cc: Nirmoy Das
> Cc: Jani Nikula
> Cc: Andi Shyti
> Reviewed-by: Mauro Carvalho Chehab (v5)
> ---
> drivers/gpu/drm/i915/i915_utils.h | 5 +--
> include/linux/overflow.h | 54 +++
> 2 files changed, 55 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_utils.h
> b/drivers/gpu/drm/i915/i915_utils.h
> index c10d68cdc3ca..eb0ded23fa9c 100644
> --- a/drivers/gpu/drm/i915/i915_utils.h
> +++ b/drivers/gpu/drm/i915/i915_utils.h
> @@ -32,6 +32,7 @@
> #include
> #include
> #include
> +#include
>
> #ifdef CONFIG_X86
> #include
> @@ -111,10 +112,6 @@ bool i915_error_injected(void);
> #define range_overflows_end_t(type, start, size, max) \
> range_overflows_end((type)(start), (type)(size), (type)(max))
>
> -/* Note we don't consider signbits :| */
> -#define overflows_type(x, T) \
> - (sizeof(x) > sizeof(T) && (x) >> BITS_PER_TYPE(T))
> -
> #define ptr_mask_bits(ptr, n) ({ \
> unsigned long __v = (unsigned long)(ptr); \
> (typeof(ptr))(__v & -BIT(n)); \
> diff --git a/include/linux/overflow.h b/include/linux/overflow.h
> index f1221d11f8e5..462a03454377 100644
> --- a/include/linux/overflow.h
> +++ b/include/linux/overflow.h
> @@ -35,6 +35,60 @@
> #define type_max(T) ((T)((__type_half_max(T) - 1) + __type_half_max(T)))
> #define type_min(T) ((T)((T)-type_max(T)-(T)1))
>
> +/**
> + * is_unsigned_type - helper for checking data type which is an unsigned data
> + * type or not
> + * @x: The data type to check
> + *
> + * Returns:
> + * True if the data type is an unsigned data type, false otherwise.
> + */
> +#define is_unsigned_type(x) ((typeof(x))-1 >= (typeof(x))0)
> +
> +/**
> + * overflows_type - helper for checking the truncation between data types
> + * @x: Source for overflow type comparison
> + * @T: Destination for overflow type comparison
> + *
> + * It compares the values and size of each data type between the first and
> + * second argument to check whether truncation can occur when assigning the
> + * first argument to the variable of the second argument.
> + * Source and Destination can be used with or without sign bit.
> + * Composite data structures such as union and structure are not considered.
> + * Enum data types are not considered.
> + * Floating point data types are not considered.
> + *
> + * Returns:
> + * True if truncation can occur, false otherwise.
> + */
> +#define overflows_type(x, T) \
> + (is_unsigned_type(x) ? \
> + is_unsigned_type(T) ? \
> + (sizeof(x) > sizeof(T) && (x) >> BITS_PER_TYPE(T)) ? 1
> : 0 \
> + : (sizeof(x) >= sizeof(T) && (x) >> (BITS_PER_TYPE(T) -
> 1)) ? 1 : 0 \
> + : is_unsigned_type(T) ? \
> + ((x) < 0) ? 1 : (sizeof(x) > sizeof(T) && (x) >>
> BITS_PER_TYPE(T)) ? 1 : 0 \
> + : (sizeof(x) > sizeof(T)) ? \
> + ((x) < 0) ? (((x) * -1) >> BITS_PER_TYPE(T)) ? 1 : 0 \
> + : ((x) >> BITS_PER_TYPE(T)) ? 1 : 0 \
> + : 0)
> +
> +/**
> + * safe_conversion - perform a type conversion (cast) of an source value into
> + * a new variable, checking that the destination is large enough to hold the
> + * source value.
> + * @ptr: Destination pointer address
> + * @value: Source value
> + *
> + * Returns:
> + * If the value would overflow the destination, it returns false.
> + */
> +#define safe_conversion(ptr, value) ({ \
> + typeof(value) __v = (value); \
> + typeof(ptr) __ptr = (ptr); \
> + overflows_type(__v, *__ptr) ? 0 : ((*__ptr = (typeof(*__ptr))__v), 1); \
> +})
> +
> /*
> * Avoids triggering -Wtype-limits compilation warning,
> * while using unsign
[PATCH 0/3] drm: Use full allocated minor range for DRM
64 DRM device nodes is not enough for everyone. Upgrade it to 512K (which definitely is more than enough). Additionally - one minor tweak around minor IDR locking. Michał Winiarski (3): drm: Don't reserve minors for control nodes drm: Expand max DRM device number to full MINORBITS drm: Use mutex for minors drivers/gpu/drm/drm_drv.c | 45 ++- include/drm/drm_file.h| 1 - 2 files changed, 21 insertions(+), 25 deletions(-) -- 2.37.2
[PATCH 3/3] drm: Use mutex for minors
Operating on drm minor is not done in IRQ context, which means that we
could safely downgrade to regular non-irq spinlock.
But we can also go further and drop the idr_preload tricks by just using
a mutex.
Signed-off-by: Michał Winiarski
---
drivers/gpu/drm/drm_drv.c | 31 ---
1 file changed, 12 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 0dab1ef8a98d..b31497e28e6a 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -53,7 +53,7 @@ MODULE_AUTHOR("Gareth Hughes, Leif Delgass, José Fonseca, Jon
Smirl");
MODULE_DESCRIPTION("DRM shared core routines");
MODULE_LICENSE("GPL and additional rights");
-static DEFINE_SPINLOCK(drm_minor_lock);
+static DEFINE_MUTEX(drm_minor_lock);
static struct idr drm_minors_idr;
/*
@@ -98,21 +98,19 @@ static struct drm_minor **drm_minor_get_slot(struct
drm_device *dev,
static void drm_minor_alloc_release(struct drm_device *dev, void *data)
{
struct drm_minor *minor = data;
- unsigned long flags;
WARN_ON(dev != minor->dev);
put_device(minor->kdev);
- spin_lock_irqsave(&drm_minor_lock, flags);
+ mutex_lock(&drm_minor_lock);
idr_remove(&drm_minors_idr, minor->index);
- spin_unlock_irqrestore(&drm_minor_lock, flags);
+ mutex_unlock(&drm_minor_lock);
}
static int drm_minor_alloc(struct drm_device *dev, unsigned int type)
{
struct drm_minor *minor;
- unsigned long flags;
int r, start, end;
minor = drmm_kzalloc(dev, sizeof(*minor), GFP_KERNEL);
@@ -126,11 +124,9 @@ static int drm_minor_alloc(struct drm_device *dev,
unsigned int type)
end = 128 * (type + 1);
do {
- idr_preload(GFP_KERNEL);
- spin_lock_irqsave(&drm_minor_lock, flags);
- r = idr_alloc(&drm_minors_idr, NULL, start, end, GFP_NOWAIT);
- spin_unlock_irqrestore(&drm_minor_lock, flags);
- idr_preload_end();
+ mutex_lock(&drm_minor_lock);
+ r = idr_alloc(&drm_minors_idr, NULL, start, end, GFP_KERNEL);
+ mutex_unlock(&drm_minor_lock);
start += 256;
end += 256;
@@ -156,7 +152,6 @@ static int drm_minor_alloc(struct drm_device *dev, unsigned
int type)
static int drm_minor_register(struct drm_device *dev, unsigned int type)
{
struct drm_minor *minor;
- unsigned long flags;
int ret;
DRM_DEBUG("\n");
@@ -176,9 +171,9 @@ static int drm_minor_register(struct drm_device *dev,
unsigned int type)
goto err_debugfs;
/* replace NULL with @minor so lookups will succeed from now on */
- spin_lock_irqsave(&drm_minor_lock, flags);
+ mutex_lock(&drm_minor_lock);
idr_replace(&drm_minors_idr, minor, minor->index);
- spin_unlock_irqrestore(&drm_minor_lock, flags);
+ mutex_unlock(&drm_minor_lock);
DRM_DEBUG("new minor registered %d\n", minor->index);
return 0;
@@ -191,16 +186,15 @@ static int drm_minor_register(struct drm_device *dev,
unsigned int type)
static void drm_minor_unregister(struct drm_device *dev, unsigned int type)
{
struct drm_minor *minor;
- unsigned long flags;
minor = *drm_minor_get_slot(dev, type);
if (!minor || !device_is_registered(minor->kdev))
return;
/* replace @minor with NULL so lookups will fail from now on */
- spin_lock_irqsave(&drm_minor_lock, flags);
+ mutex_lock(&drm_minor_lock);
idr_replace(&drm_minors_idr, NULL, minor->index);
- spin_unlock_irqrestore(&drm_minor_lock, flags);
+ mutex_unlock(&drm_minor_lock);
device_del(minor->kdev);
dev_set_drvdata(minor->kdev, NULL); /* safety belt */
@@ -219,13 +213,12 @@ static void drm_minor_unregister(struct drm_device *dev,
unsigned int type)
struct drm_minor *drm_minor_acquire(unsigned int minor_id)
{
struct drm_minor *minor;
- unsigned long flags;
- spin_lock_irqsave(&drm_minor_lock, flags);
+ mutex_lock(&drm_minor_lock);
minor = idr_find(&drm_minors_idr, minor_id);
if (minor)
drm_dev_get(minor->dev);
- spin_unlock_irqrestore(&drm_minor_lock, flags);
+ mutex_unlock(&drm_minor_lock);
if (!minor) {
return ERR_PTR(-ENODEV);
--
2.37.2
[PATCH 1/3] drm: Don't reserve minors for control nodes
Control nodes are no longer with us.
While we still need to preserve render nodes numbering, there's no need
to reserve the range formerly used for control. Let's repurpose it to be
used by primary and remove control remains from the code entirely.
References: commit 0d49f303e8a7 ("drm: remove all control node code")
References: commit c9ac371d4b59 ("drm: Fix render node numbering regression
from control node removal.")
Signed-off-by: Michał Winiarski
---
drivers/gpu/drm/drm_drv.c | 4 ++--
include/drm/drm_file.h| 1 -
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 8214a0b1ab7f..d81783f43452 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -126,8 +126,8 @@ static int drm_minor_alloc(struct drm_device *dev, unsigned
int type)
spin_lock_irqsave(&drm_minor_lock, flags);
r = idr_alloc(&drm_minors_idr,
NULL,
- 64 * type,
- 64 * (type + 1),
+ 128 * type,
+ 128 * (type + 1),
GFP_NOWAIT);
spin_unlock_irqrestore(&drm_minor_lock, flags);
idr_preload_end();
diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
index d780fd151789..a3be533e99e0 100644
--- a/include/drm/drm_file.h
+++ b/include/drm/drm_file.h
@@ -54,7 +54,6 @@ struct file;
*/
enum drm_minor_type {
DRM_MINOR_PRIMARY,
- DRM_MINOR_CONTROL,
DRM_MINOR_RENDER,
};
--
2.37.2
Re: [PATCH v1] drm/ttm: Refcount allocated tail pages
On 8/18/22 01:57, Dmitry Osipenko wrote: > On 8/15/22 18:54, Dmitry Osipenko wrote: >> On 8/15/22 17:57, Dmitry Osipenko wrote: >>> On 8/15/22 16:53, Christian König wrote: Am 15.08.22 um 15:45 schrieb Dmitry Osipenko: > [SNIP] >> Well that comment sounds like KVM is doing the right thing, so I'm >> wondering what exactly is going on here. > KVM actually doesn't hold the page reference, it takes the temporal > reference during page fault and then drops the reference once page is > mapped, IIUC. Is it still illegal for TTM? Or there is a possibility for > a race condition here? > Well the question is why does KVM grab the page reference in the first place? If that is to prevent the mapping from changing then yes that's illegal and won't work. It can always happen that you grab the address, solve the fault and then immediately fault again because the address you just grabbed is invalidated. If it's for some other reason than we should probably investigate if we shouldn't stop doing this. >>> >>> CC: +Paolo Bonzini who introduced this code >>> >>> commit add6a0cd1c5ba51b201e1361b05a5df817083618 >>> Author: Paolo Bonzini >>> Date: Tue Jun 7 17:51:18 2016 +0200 >>> >>> KVM: MMU: try to fix up page faults before giving up >>> >>> The vGPU folks would like to trap the first access to a BAR by setting >>> vm_ops on the VMAs produced by mmap-ing a VFIO device. The fault >>> handler >>> then can use remap_pfn_range to place some non-reserved pages in the >>> VMA. >>> >>> This kind of VM_PFNMAP mapping is not handled by KVM, but follow_pfn >>> and fixup_user_fault together help supporting it. The patch also >>> supports >>> VM_MIXEDMAP vmas where the pfns are not reserved and thus subject to >>> reference counting. >>> >>> @Paolo, >>> https://lore.kernel.org/dri-devel/73e5ed8d-0d25-7d44-8fa2-e1d61b1f5...@amd.com/T/#m7647ce5f8c4749599d2c6bc15a2b45f8d8cf8154 >>> >> >> If we need to bump the refcount only for VM_MIXEDMAP and not for >> VM_PFNMAP, then perhaps we could add a flag for that to the kvm_main >> code that will denote to kvm_release_page_clean whether it needs to put >> the page? > > The other variant that kind of works is to mark TTM pages reserved using > SetPageReserved/ClearPageReserved, telling KVM not to mess with the page > struct. But the potential consequences of doing this are unclear to me. > > Christian, do you think we can do it? Although, no. It also doesn't work with KVM without additional changes to KVM. -- Best regards, Dmitry
Re: [PATCH v1 05/35] drm/connector: Add TV standard property
Den 17.08.2022 15.11, skrev Noralf Trønnes: > > > Den 17.08.2022 13.46, skrev Maxime Ripard: >> On Tue, Aug 16, 2022 at 09:35:24PM +0200, Noralf Trønnes wrote: >>> Den 16.08.2022 11.49, skrev Maxime Ripard: On Tue, Aug 16, 2022 at 11:42:20AM +0200, Noralf Trønnes wrote: > Den 16.08.2022 10.26, skrev Maxime Ripard: >> Hi, >> >> On Mon, Aug 08, 2022 at 02:44:56PM +0200, Noralf Trønnes wrote: >>> Den 29.07.2022 18.34, skrev Maxime Ripard: The TV mode property has been around for a while now to select and get the current TV mode output on an analog TV connector. Despite that property name being generic, its content isn't and has been driver-specific which makes it hard to build any generic behaviour on top of it, both in kernel and user-space. Let's create a new bitmask tv norm property, that can contain any of the analog TV standards currently supported by kernel drivers. Each driver can then pass in a bitmask of the modes it supports. We'll then be able to phase out the older tv mode property. Signed-off-by: Maxime Ripard >>> How do you test the property? I've used modetest but I can only change >>> to a tv.mode that matches the current display mode. I can't switch from >>> ntsc to pal for instance. >> >> Yep, if you want to change from PAL to NTSC, it will require a new mode. >> > > So userspace has to check tv.mode first and then create a display mode > the driver will accept if switching to a different display mode is > necessary? In other words, userspace can't discover from the kernel > which display modes a certain tv.mode/norm provides before it is > selected? If so, maybe libdrm should have some function(s) to deal with > switching between modes that require a different display mode since > knowledge about which display modes a tv.mode supports is needed before > hand. > I haven't used vc4 on Pi4 in mainline before and have finally gotten it to work. I see that the connector reports 2 modes that together fit all tv.norms so userspace doesn't have to contruct a display mode, but it does need to know which display mode belongs to a certain tv.norm. When I try to use modetest I'm unable to set a mode: pi@pi4t:~ $ modetest -M vc4 -s 45:720x480i setting mode 720x480i-29.97Hz on connectors 45, crtc 68 failed to set mode: Function not implemented The errno is misleading, modetest does a drmModeDirtyFB before checking the error returned by drmModeSetCrtc. Setting the property succeeds, but the modeset still fails: pi@pi4t:~ $ modetest -M vc4 -s 45:720x480i -w 45:"tv norm":2 setting mode 720x480i-29.97Hz on connectors 45, crtc 68 failed to set mode: Function not implemented pi@pi4t:~ $ modetest -M vc4 -c 37 tv norm: flags: bitmask values: NTSC-443=0x1 NTSC-J=0x2 NTSC-M=0x4 PAL-B=0x10 PAL-M=0x200 PAL-N=0x400 SECAM-B=0x2000 value: 2 Here's the log, can you see if there's anything obvious in there: https://gist.github.com/notro/a079498bf6b64327105752b2bafa8858 Noralf.
Re: [RFC PATCH] drm/edid: Make 144 Hz not preferred on Sharp LQ140M1JW46
Hi, On Sun, Aug 14, 2022 at 11:46 PM Maxime Ripard wrote: > > On Fri, Jul 29, 2022 at 12:57:40PM -0700, Doug Anderson wrote: > > Hi, > > > > On Fri, Jul 29, 2022 at 9:41 AM Maxime Ripard wrote: > > > > > > On Fri, Jul 29, 2022 at 07:50:20AM -0700, Doug Anderson wrote: > > > > On Fri, Jul 29, 2022 at 12:51 AM Maxime Ripard > > > > wrote: > > > > > > > > > > On Thu, Jul 28, 2022 at 02:18:38PM -0700, Doug Anderson wrote: > > > > > > Hi, > > > > > > > > > > > > On Thu, Jul 28, 2022 at 10:34 AM Abhinav Kumar > > > > > > wrote: > > > > > > > > > > > > > > Hi Rob and Doug > > > > > > > > > > > > > > On 7/22/2022 10:36 AM, Rob Clark wrote: > > > > > > > > On Fri, Jul 22, 2022 at 9:48 AM Doug Anderson > > > > > > > > wrote: > > > > > > > >> > > > > > > > >> Hi, > > > > > > > >> > > > > > > > >> On Fri, Jul 22, 2022 at 9:37 AM Abhinav Kumar > > > > > > > >> wrote: > > > > > > > >>> > > > > > > > >>> + sankeerth > > > > > > > >>> > > > > > > > >>> Hi Doug > > > > > > > >>> > > > > > > > >>> On 7/21/2022 3:23 PM, Douglas Anderson wrote: > > > > > > > The Sharp LQ140M1JW46 panel is on the Qualcomm sc7280 CRD > > > > > > > reference > > > > > > > board. This panel supports 144 Hz and 60 Hz. In the EDID, > > > > > > > the 144 Hz > > > > > > > mode is listed first and thus is marked preferred. The EDID > > > > > > > decode I > > > > > > > ran says: > > > > > > > > > > > > > > First detailed timing includes the native pixel format > > > > > > > and preferred > > > > > > > refresh rate. > > > > > > > > > > > > > > ... > > > > > > > > > > > > > > Detailed Timing Descriptors: > > > > > > > DTD 1: 1920x1080 143.981 Hz 16:9 166.587 kHz > > > > > > > 346.500 MHz > > > > > > > Hfront 48 Hsync 32 Hback 80 Hpol N > > > > > > > Vfront3 Vsync 5 Vback 69 Vpol N > > > > > > > DTD 2: 1920x1080 59.990 Hz 16:969.409 kHz > > > > > > > 144.370 MHz > > > > > > > Hfront 48 Hsync 32 Hback 80 Hpol N > > > > > > > Vfront3 Vsync 5 Vback 69 Vpol N > > > > > > > > > > > > > > I'm proposing here that the above is actually a bug and that > > > > > > > the 60 Hz > > > > > > > mode really should be considered preferred by Linux. > > > > > > > > > > > > > > Its a bit tricky to say that this is a bug but I think we can > > > > > > > certainly > > > > > > > add here that for an internal display we would have ideally had > > > > > > > the > > > > > > > lower resolution first to indicate it as default. > > > > > > > > > > > > Yeah, it gets into the vagueness of the EDID spec in general. As far > > > > > > as I can find it's really up to the monitor to decide by what means > > > > > > it > > > > > > chooses the "preferred" refresh rate if the monitor can support > > > > > > many. > > > > > > Some displays may decide that the normal rate is "preferred" and > > > > > > some > > > > > > may decide that the high refresh rate is "preferred". Neither > > > > > > display > > > > > > is "wrong" per say, but it's nice to have some consistency here and > > > > > > to > > > > > > make it so that otherwise "dumb" userspace will get something > > > > > > reasonable by default. I'll change it to say: > > > > > > > > > > > > While the EDID spec appears to allow a display to use any criteria > > > > > > for > > > > > > picking which refresh mode is "preferred" or "optimal", that > > > > > > vagueness > > > > > > is a bit annoying. From Linux's point of view let's choose the 60 Hz > > > > > > one as the default. > > > > > > > > > > And if we start making that decision, it should be for all panels > > > > > with a > > > > > similar constraint, so most likely handled by the core, and the new > > > > > policy properly documented. > > > > > > > > > > Doing that just for a single panel is weird. > > > > > > > > Yeah, though having a "general policy" in the core can be problematic. > > > > > > > > In general I think panel EDIDs are only trustworthy as far as you can > > > > throw them. They are notorious for having wrong and incorrect > > > > information, which is why the EDID quirk list exists to begin with. > > > > Trying to change how we're going to interpret all EDIDs, even all > > > > EDIDs for eDP panels, seems like it will break someone somewhere. > > > > Maybe there are EDIDs out there that were only ever validated at the > > > > higher refresh rate and they don't work / flicker / cause digitizer > > > > noise at the lower refresh rate. Heck, we've seen eDP panel vendors > > > > that can't even get their checksum correct, so I'm not sure I want to > > > > make a global assertion that all panels validated their "secondary" > > > > display mode. > > > > > > > > In this particular case, we have validated that this particular Sharp > > > > panel works fine at the lower refresh ra
Re: [PATCH -next] drm/bridge: Add missing clk_disable_unprepare() in analogix_dp_resume()
On Wed, Aug 17, 2022 at 01:34:13PM -0700, Brian Norris wrote:
> On Mon, Aug 15, 2022 at 11:46 PM Zhang Zekun wrote:
> >
> > Add the missing clk_disable_unprepare() before return from
> > analogix_dp_resume() in the error handling case.
> >
> > Fixes: 211f276ed3d9 ("drm: bridge: analogix/dp: add panel prepare/unprepare
> > in suspend/resume time")
> > Signed-off-by: Zhang Zekun
>
> Reviewed-by: Brian Norris
Hmm, actually I'm going to have to retract that now that I've given it
some more testing locally. I happen to have a system where I commonly
hit this error case, and I'm thinking commit 211f276ed3d9 is actually
wrong, and so we shouldn't be "fixing" its error handling -- we should
be reverting it.
In particular, drm_panel_prepare()/drm_panel_unprepare() are *not*
reference-counted APIs, and this is already managed by
analogix_dp_bridge_disable(), which is called by the core DRM helpers
during suspend. Thus, analogix_dp_suspend()/analogix_dp_resume() is
serving to be an unwanted *second* client trying to {un,}prepare the
panel.
The panel drivers tend to handle this OK to some extent, as they (e.g.,
panel-edp.c) guard against redundant operations, but *we* don't --
notice that analogix_dp_suspend() ignores drm_panel_unprepare() errors
for one.
Also, I don't believe device management really handles resume() failures
quite right; in the end, this patch ends up un-balancing the clk count
on the RK3399 Gru-Bob systems I'm testing.
(Side note: every other bridge driver seems to ignore
drm_panel_prepare() failures.)
It's possible this was correct (or at least, not terribly broken) back
when it was written, but then, the DRM core frameworks have evolved
since then. Today, I think we do not need to manage the panel state
directly in suspend()/resume().
All in all:
Nacked-by: Brian Norris
Tested-and-failed-by: Brian Norris
Now separately, I have to figure out why I'm hitting this error case in
the first place...
Re: [PATCH v7 1/8] overflow: Move and add few utility macros into overflow
On Thu, Aug 18, 2022 at 01:07:29AM +0200, Andi Shyti wrote:
> Hi Kees,
>
> would you mind taking a look at this patch?
Hi! Thanks for the heads-up!
>
> Thanks,
> Andi
>
> On Tue, Aug 16, 2022 at 06:35:18PM +0900, Gwan-gyeong Mun wrote:
> > It moves overflows_type utility macro into overflow header from i915_utils
> > header. The overflows_type can be used to catch the truncation between data
> > types. And it adds safe_conversion() macro which performs a type conversion
> > (cast) of an source value into a new variable, checking that the
> > destination is large enough to hold the source value. And the functionality
> > of overflows_type has been improved to handle the signbit.
> > The is_unsigned_type macro has been added to check the sign bit of the
> > built-in type.
> >
> > v3: Add is_type_unsigned() macro (Mauro)
> > Modify overflows_type() macro to consider signed data types (Mauro)
> > Fix the problem that safe_conversion() macro always returns true
> > v4: Fix kernel-doc markups
> > v6: Move macro addition location so that it can be used by other than drm
> > subsystem (Jani, Mauro, Andi)
> > Change is_type_unsigned to is_unsigned_type to have the same name form
> > as is_signed_type macro
> >
> > Signed-off-by: Gwan-gyeong Mun
> > Cc: Thomas Hellström
> > Cc: Matthew Auld
> > Cc: Nirmoy Das
> > Cc: Jani Nikula
> > Cc: Andi Shyti
> > Reviewed-by: Mauro Carvalho Chehab (v5)
> > ---
> > drivers/gpu/drm/i915/i915_utils.h | 5 +--
> > include/linux/overflow.h | 54 +++
> > 2 files changed, 55 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_utils.h
> > b/drivers/gpu/drm/i915/i915_utils.h
> > index c10d68cdc3ca..eb0ded23fa9c 100644
> > --- a/drivers/gpu/drm/i915/i915_utils.h
> > +++ b/drivers/gpu/drm/i915/i915_utils.h
> > @@ -32,6 +32,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #ifdef CONFIG_X86
> > #include
> > @@ -111,10 +112,6 @@ bool i915_error_injected(void);
> > #define range_overflows_end_t(type, start, size, max) \
> > range_overflows_end((type)(start), (type)(size), (type)(max))
> >
> > -/* Note we don't consider signbits :| */
> > -#define overflows_type(x, T) \
> > - (sizeof(x) > sizeof(T) && (x) >> BITS_PER_TYPE(T))
> > -
> > #define ptr_mask_bits(ptr, n) ({ \
> > unsigned long __v = (unsigned long)(ptr); \
> > (typeof(ptr))(__v & -BIT(n)); \
> > diff --git a/include/linux/overflow.h b/include/linux/overflow.h
> > index f1221d11f8e5..462a03454377 100644
> > --- a/include/linux/overflow.h
> > +++ b/include/linux/overflow.h
> > @@ -35,6 +35,60 @@
> > #define type_max(T) ((T)((__type_half_max(T) - 1) + __type_half_max(T)))
> > #define type_min(T) ((T)((T)-type_max(T)-(T)1))
> >
> > +/**
> > + * is_unsigned_type - helper for checking data type which is an unsigned
> > data
> > + * type or not
> > + * @x: The data type to check
> > + *
> > + * Returns:
> > + * True if the data type is an unsigned data type, false otherwise.
> > + */
> > +#define is_unsigned_type(x) ((typeof(x))-1 >= (typeof(x))0)
I'd rather not have separate logic for this. Instead, I'd like it to be:
#define is_unsigned_type(x) (!is_signed_type(x))
> > +
> > +/**
> > + * overflows_type - helper for checking the truncation between data types
> > + * @x: Source for overflow type comparison
> > + * @T: Destination for overflow type comparison
> > + *
> > + * It compares the values and size of each data type between the first and
> > + * second argument to check whether truncation can occur when assigning the
> > + * first argument to the variable of the second argument.
> > + * Source and Destination can be used with or without sign bit.
> > + * Composite data structures such as union and structure are not
> > considered.
> > + * Enum data types are not considered.
> > + * Floating point data types are not considered.
> > + *
> > + * Returns:
> > + * True if truncation can occur, false otherwise.
> > + */
> > +#define overflows_type(x, T) \
> > + (is_unsigned_type(x) ? \
> > + is_unsigned_type(T) ? \
> > + (sizeof(x) > sizeof(T) && (x) >> BITS_PER_TYPE(T)) ? 1
> > : 0 \
> > + : (sizeof(x) >= sizeof(T) && (x) >> (BITS_PER_TYPE(T) -
> > 1)) ? 1 : 0 \
> > + : is_unsigned_type(T) ? \
> > + ((x) < 0) ? 1 : (sizeof(x) > sizeof(T) && (x) >>
> > BITS_PER_TYPE(T)) ? 1 : 0 \
> > + : (sizeof(x) > sizeof(T)) ? \
> > + ((x) < 0) ? (((x) * -1) >> BITS_PER_TYPE(T)) ? 1 : 0 \
> > + : ((x) >> BITS_PER_TYPE(T)) ? 1 : 0 \
> > + : 0)
Like the other, I'd much rather this was rephrased in terms of the
existing macros (e.g. type_min()/type_max().)
> > +
> > +/**
> > + * safe_conversion - perform a type conversion (cast) of an source value
> > into
> > + * a new variable
Re: build failure of next-20220817 for amdgpu
On 8/17/22 19:01, Alex Deucher wrote: > On Wed, Aug 17, 2022 at 6:03 PM Sudip Mukherjee (Codethink) > wrote: >> >> Hi All, >> >> Not sure if it has been reported, build of next-20220817 fails with the >> error: >> >> ERROR: modpost: "cpu_smallcore_map" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] >> undefined! >> >> Trying to do a git bisect to find out the offending commit. >> > > Thanks. I don't see that symbol in the driver at all. Not sure where > it is coming from. > It's powerpc only. Sudip, is it non-CONFIG_SMP by any chance? > > >> I will be happy to test any patch or provide any extra log if needed. >> >> >> -- >> Regards >> Sudip -- ~Randy
Re: [PATCH] drm/bridge: ps8640: Add double reset T4 and T5 to power-on sequence
On Thu, Aug 18, 2022 at 6:54 AM Doug Anderson wrote: > > Hi, > > On Mon, Aug 15, 2022 at 2:39 AM Hsin-Yi Wang wrote: > > > > The double reset power-on sequence is a workaround for the hardware > > flaw in some chip that SPI Clock output glitch and cause internal MPU > > unable to read firmware correctly. The sequence is suggested in ps8640 > > application note. > > > > Signed-off-by: Hsin-Yi Wang > > --- > > drivers/gpu/drm/bridge/parade-ps8640.c | 5 + > > 1 file changed, 5 insertions(+) > > > > diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c > > b/drivers/gpu/drm/bridge/parade-ps8640.c > > index 49107a6cdac18..d7483c13c569b 100644 > > --- a/drivers/gpu/drm/bridge/parade-ps8640.c > > +++ b/drivers/gpu/drm/bridge/parade-ps8640.c > > @@ -375,6 +375,11 @@ static int __maybe_unused ps8640_resume(struct device > > *dev) > > gpiod_set_value(ps_bridge->gpio_reset, 1); > > usleep_range(2000, 2500); > > gpiod_set_value(ps_bridge->gpio_reset, 0); > > + /* Double reset for T4 and T5 */ > > + msleep(50); > > + gpiod_set_value(ps_bridge->gpio_reset, 1); > > + msleep(50); > > + gpiod_set_value(ps_bridge->gpio_reset, 0); > > We really need another 100 ms here? ps8640 is already quite slow at > powering itself up and that has a real user impact. Why was it only > 2.5 ms for the first reset and 50 ms for the second? > The T4 and T5 are required by Parade. I'm wondering if they can shorten the 200ms below: /* * Mystery 200 ms delay for the "MCU to be ready". It's unclear if * this is truly necessary since the MCU will already signal that * things are "good to go" by signaling HPD on "gpio 9". See * _ps8640_wait_hpd_asserted(). For now we'll keep this mystery delay * just in case. */ msleep(200); Does this have to wait 200ms? Can it shorten to 100 due to the additional 100ms from T4 and T5? > -Doug
[pull] amdgpu, amdkfd drm-fixes-6.0
Hi Dave, Daniel, A bit bigger than normal, but this is several weeks of fixes since I was out of the office and then digging out once I got back. Mainly fixes for new IPs that were added in 6.0. The following changes since commit 5493ee1919eae4f49d62276cf5986b7f7c7aa8f6: Merge tag 'amd-drm-next-5.20-2022-07-29' of https://gitlab.freedesktop.org/agd5f/linux into drm-next (2022-08-03 14:00:19 +1000) are available in the Git repository at: https://gitlab.freedesktop.org/agd5f/linux.git tags/amd-drm-fixes-6.0-2022-08-17 for you to fetch changes up to 085292c3d78015412b752ee1ca4c7725fd2bf2fc: Revert "drm/amd/amdgpu: add pipe1 hardware support" (2022-08-16 18:14:31 -0400) amd-drm-fixes-6.0-2022-08-17: amdgpu: - Revert some DML stack changes - Rounding fixes in KFD allocations - atombios vram info table parsing fix - DCN 3.1.4 fixes - Clockgating fixes for various new IPs - SMU 13.0.4 fixes - DCN 3.1.4 FP fixes - TMDS fixes for YCbCr420 4k modes - DCN 3.2.x fixes - USB 4 fixes - SMU 13.0 fixes - SMU driver unload memory leak fixes - Display orientation fix - Regression fix for generic fbdev conversion - SDMA 6.x fixes - SR-IOV fixes - IH 6.x fixes - Use after free fix in bo list handling - Revert pipe1 support - XGMI hive reset fix amdkfd: - Fix potential crach in kfd_create_indirect_link_prop() Alex Deucher (1): drm/amdgpu: Only disable prefer_shadow on hawaii Alvin Lee (8): drm/amd/display: Add a variable to update FCLK latency drm/amd/display: Revert "attempt to fix the logic in commit_planes_for_stream()" drm/amd/display: For stereo keep "FLIP_ANY_FRAME" drm/amd/display: Don't try to enter MALL SS if stereo3d drm/amd/display: Add 16 lines margin for SubVP drm/amd/display: Don't set DSC for phantom pipes drm/amd/display: Use pitch when calculating size to cache in MALL drm/amd/display: Include scaling factor for SubVP command Andrey Strachuk (1): drm/amdgpu: remove useless condition in amdgpu_job_stop_all_jobs_on_sched() Aric Cyr (2): drm/amd/display: 3.2.197 drm/amd/display: 3.2.198 Aurabindo Pillai (4): drm/amd/display: Add a missing register field for HPO DP stream encoder drm/amd/display: fix CAB allocation for multiple displays drm/amd/display: Check correct bounds for stream encoder instances for DCN303 drm/amd/display: Enable SubVP by default on DCN32 & DCN321 Chaitanya Dhere (1): drm/amd/display: Modify header inclusion pattern Charlene Liu (1): drm/amd/display: avoid doing vm_init multiple time Chiawen Huang (1): drm/amd/display: Device flash garbage before get in OS Dan Carpenter (1): drm/amdkfd: potential crash in kfd_create_indirect_link_prop() Daniel Miess (3): drm/amd/display: Use pixels per container logic for DCN314 DCCG dividers drm/amd/display: Fix TMDS 4K@60Hz YCbCr420 corruption issue drm/amd/display: Add debug parameter to retain default clock table Daniel Phillips (2): drm/amdgpu: Remove rounding from vram allocation path drm/amdgpu: Pessimistic availability based on rounded up allocations David Galiffi (2): drm/amd/display: Allow alternate prefetch modes in DML for DCN32 drm/amd/display: Fix Compile-time Warning Duncan Ma (2): drm/amd/display: Fix VPG instancing for dcn314 HPO drm/amd/display: Correct DTBCLK for dcn314 Dusica Milinkovic (1): drm/amdgpu: Increase tlb flush timeout for sriov Ethan Wellenreiter (1): drm/amd/display: reverted limiting vscsdp_for_colorimetry and ARGB16161616 pixel format addition Evan Quan (4): drm/amd/pm: add 3715 softpptable support for SMU13.0.0 drm/amdgpu: disable 3DCGCG/CGLS temporarily due to stability issue drm/amd/pm: add missing ->fini_microcode interface for Sienna Cichlid drm/amd/pm: add missing ->fini_ interfaces for some SMU13 asics Felix Kuehling (2): drm/amdkfd: Handle restart of kfd_ioctl_wait_events drm/amdkfd: Fix mm reference in SVM eviction worker Fudong Wang (1): drm/amd/display: clear optc underflow before turn off odm clock Harish Kasiviswanathan (1): drm/amdgpu: Add decode_iv_ts helper for ih_v6 block Ian Chen (1): drm/amd/display: Add reserved dc_log_type. Ilya Bakoulin (1): drm/amd/display: Fix pixel clock programming Joseph Greathouse (1): drm/amdgpu: Enable translate_further to extend UTCL2 reach Josip Pavic (2): drm/amd/display: Avoid MPC infinite loop drm/amd/display: do not compare integers of different widths Kenneth Feng (3): drm/amd/pm: skip pptable override for smu_v13_0_7 drm/amd/amdgpu: add ih cg and hdp sd on smu_v13_0_7 drm/amd/pm: add mode1 support on smu_v13_0_7 Khalid Masum (1): drm/amdgpu/vcn: Return void from the stop_dbg_mode Leo Ma (1): drm/amd
[PATCH -next] drm/amd/display: remove unneeded semicolon
Semicolon is not required after curly braces.
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=1918
Reported-by: Abaci Robot
Signed-off-by: Yang Li
---
drivers/gpu/drm/amd/display/dc/clk_mgr/dcn314/dcn314_clk_mgr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn314/dcn314_clk_mgr.c
b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn314/dcn314_clk_mgr.c
index beb025cd3dc2..1995e1d708d9 100644
--- a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn314/dcn314_clk_mgr.c
+++ b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn314/dcn314_clk_mgr.c
@@ -614,7 +614,7 @@ static void dcn314_clk_mgr_helper_populate_bw_params(struct
clk_mgr_internal *cl
bw_params->clk_table.entries[i].dppclk_mhz = max_dppclk;
bw_params->clk_table.entries[i].wck_ratio = convert_wck_ratio(
clock_table->DfPstateTable[min_pstate].WckRatio);
- };
+ }
/* Make sure to include at least one entry at highest pstate */
if (max_pstate != min_pstate || i == 0) {
--
2.20.1.7.g153144c
Re: [PATCH] drm/bridge: ps8640: Add double reset T4 and T5 to power-on sequence
On Thu, Aug 18, 2022 at 11:19 AM Rock Chiu wrote: > > How does T4/T5 impact the real case? We talked previously the T4/T5 > shouldn't cause user impact. > Do we have testing data from ODM? > Please leave comments below the previous comment's headline. I'm confused. The reason I upstreamed this patch is because this is in your application note and you asked us to help upstream it. Now do you mean that we don't need T4 and T5? > Rock Chiu > > Hsin-Yi Wang 於 2022年8月18日 週四 上午10:43寫道： > > > > On Thu, Aug 18, 2022 at 6:54 AM Doug Anderson wrote: > > > > > > Hi, > > > > > > On Mon, Aug 15, 2022 at 2:39 AM Hsin-Yi Wang wrote: > > > > > > > > The double reset power-on sequence is a workaround for the hardware > > > > flaw in some chip that SPI Clock output glitch and cause internal MPU > > > > unable to read firmware correctly. The sequence is suggested in ps8640 > > > > application note. > > > > > > > > Signed-off-by: Hsin-Yi Wang > > > > --- > > > > drivers/gpu/drm/bridge/parade-ps8640.c | 5 + > > > > 1 file changed, 5 insertions(+) > > > > > > > > diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c > > > > b/drivers/gpu/drm/bridge/parade-ps8640.c > > > > index 49107a6cdac18..d7483c13c569b 100644 > > > > --- a/drivers/gpu/drm/bridge/parade-ps8640.c > > > > +++ b/drivers/gpu/drm/bridge/parade-ps8640.c > > > > @@ -375,6 +375,11 @@ static int __maybe_unused ps8640_resume(struct > > > > device *dev) > > > > gpiod_set_value(ps_bridge->gpio_reset, 1); > > > > usleep_range(2000, 2500); > > > > gpiod_set_value(ps_bridge->gpio_reset, 0); > > > > + /* Double reset for T4 and T5 */ > > > > + msleep(50); > > > > + gpiod_set_value(ps_bridge->gpio_reset, 1); > > > > + msleep(50); > > > > + gpiod_set_value(ps_bridge->gpio_reset, 0); > > > > > > We really need another 100 ms here? ps8640 is already quite slow at > > > powering itself up and that has a real user impact. Why was it only > > > 2.5 ms for the first reset and 50 ms for the second? > > > > > > > The T4 and T5 are required by Parade. I'm wondering if they can > > shorten the 200ms below: > > > > /* > > * Mystery 200 ms delay for the "MCU to be ready". It's unclear if > > * this is truly necessary since the MCU will already signal that > > * things are "good to go" by signaling HPD on "gpio 9". See > > * _ps8640_wait_hpd_asserted(). For now we'll keep this mystery delay > > * just in case. > > */ > > msleep(200); > > > > Does this have to wait 200ms? Can it shorten to 100 due to the > > additional 100ms from T4 and T5? > > > > > -Doug
[PATCH v2 3/5] clk: qcom: gdsc: Add a reset op to poll gdsc collapse
Add a reset op compatible function to poll for gdsc collapse.
Signed-off-by: Akhil P Oommen
---
Changes in v2:
- Minor update to function prototype
drivers/clk/qcom/gdsc.c | 23 +++
drivers/clk/qcom/gdsc.h | 7 +++
2 files changed, 26 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/qcom/gdsc.c b/drivers/clk/qcom/gdsc.c
index 44520ef..2d0f1d1 100644
--- a/drivers/clk/qcom/gdsc.c
+++ b/drivers/clk/qcom/gdsc.c
@@ -17,6 +17,7 @@
#include
#include
#include "gdsc.h"
+#include "reset.h"
#define PWR_ON_MASKBIT(31)
#define EN_REST_WAIT_MASK GENMASK_ULL(23, 20)
@@ -116,7 +117,8 @@ static int gdsc_hwctrl(struct gdsc *sc, bool en)
return regmap_update_bits(sc->regmap, sc->gdscr, HW_CONTROL_MASK, val);
}
-static int gdsc_poll_status(struct gdsc *sc, enum gdsc_status status)
+static int gdsc_poll_status(struct gdsc *sc, enum gdsc_status status,
+ s64 timeout_us, unsigned int interval_ms)
{
ktime_t start;
@@ -124,7 +126,9 @@ static int gdsc_poll_status(struct gdsc *sc, enum
gdsc_status status)
do {
if (gdsc_check_status(sc, status))
return 0;
- } while (ktime_us_delta(ktime_get(), start) < TIMEOUT_US);
+ if (interval_ms)
+ msleep(interval_ms);
+ } while (ktime_us_delta(ktime_get(), start) < timeout_us);
if (gdsc_check_status(sc, status))
return 0;
@@ -172,7 +176,7 @@ static int gdsc_toggle_logic(struct gdsc *sc, enum
gdsc_status status)
udelay(1);
}
- ret = gdsc_poll_status(sc, status);
+ ret = gdsc_poll_status(sc, status, TIMEOUT_US, 0);
WARN(ret, "%s status stuck at 'o%s'", sc->pd.name, status ? "ff" : "n");
if (!ret && status == GDSC_OFF && sc->rsupply) {
@@ -343,7 +347,7 @@ static int _gdsc_disable(struct gdsc *sc)
*/
udelay(1);
- ret = gdsc_poll_status(sc, GDSC_ON);
+ ret = gdsc_poll_status(sc, GDSC_ON, TIMEOUT_US, 0);
if (ret)
return ret;
}
@@ -565,3 +569,14 @@ int gdsc_gx_do_nothing_enable(struct generic_pm_domain
*domain)
return 0;
}
EXPORT_SYMBOL_GPL(gdsc_gx_do_nothing_enable);
+
+int gdsc_wait_for_collapse(void *priv)
+{
+ struct gdsc *sc = priv;
+ int ret;
+
+ ret = gdsc_poll_status(sc, GDSC_OFF, 50, 5);
+ WARN(ret, "%s status stuck at 'on'", sc->pd.name);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(gdsc_wait_for_collapse);
diff --git a/drivers/clk/qcom/gdsc.h b/drivers/clk/qcom/gdsc.h
index ad313d7..d484bdb 100644
--- a/drivers/clk/qcom/gdsc.h
+++ b/drivers/clk/qcom/gdsc.h
@@ -12,6 +12,7 @@
struct regmap;
struct regulator;
struct reset_controller_dev;
+struct qcom_reset_map;
/**
* struct gdsc - Globally Distributed Switch Controller
@@ -79,6 +80,7 @@ int gdsc_register(struct gdsc_desc *desc, struct
reset_controller_dev *,
struct regmap *);
void gdsc_unregister(struct gdsc_desc *desc);
int gdsc_gx_do_nothing_enable(struct generic_pm_domain *domain);
+int gdsc_wait_for_collapse(void *priv);
#else
static inline int gdsc_register(struct gdsc_desc *desc,
struct reset_controller_dev *rcdev,
@@ -88,5 +90,10 @@ static inline int gdsc_register(struct gdsc_desc *desc,
}
static inline void gdsc_unregister(struct gdsc_desc *desc) {};
+
+static int gdsc_wait_for_collapse(void *priv)
+{
+ return -ENOSYS;
+}
#endif /* CONFIG_QCOM_GDSC */
#endif /* __QCOM_GDSC_H__ */
--
2.7.4
[PATCH v4 2/7] drm/msm: Take single rpm refcount on behalf of all submits
Instead of separate refcount for each submit, take single rpm refcount
on behalf of all the submits. This makes it easier to drop the rpm
refcount during recovery in an upcoming patch.
Signed-off-by: Akhil P Oommen
---
(no changes since v3)
Changes in v3:
- New patch
drivers/gpu/drm/msm/msm_gpu.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index c8cd9bf..e1dd3cc 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -663,11 +663,12 @@ static void retire_submit(struct msm_gpu *gpu, struct
msm_ringbuffer *ring,
mutex_lock(&gpu->active_lock);
gpu->active_submits--;
WARN_ON(gpu->active_submits < 0);
- if (!gpu->active_submits)
+ if (!gpu->active_submits) {
msm_devfreq_idle(gpu);
- mutex_unlock(&gpu->active_lock);
+ pm_runtime_put_autosuspend(&gpu->pdev->dev);
+ }
- pm_runtime_put_autosuspend(&gpu->pdev->dev);
+ mutex_unlock(&gpu->active_lock);
msm_gem_submit_put(submit);
}
@@ -756,14 +757,17 @@ void msm_gpu_submit(struct msm_gpu *gpu, struct
msm_gem_submit *submit)
/* Update devfreq on transition from idle->active: */
mutex_lock(&gpu->active_lock);
- if (!gpu->active_submits)
+ if (!gpu->active_submits) {
+ pm_runtime_get(&gpu->pdev->dev);
msm_devfreq_active(gpu);
+ }
gpu->active_submits++;
mutex_unlock(&gpu->active_lock);
gpu->funcs->submit(gpu, submit);
gpu->cur_ctx_seqno = submit->queue->ctx->seqno;
+ pm_runtime_put(&gpu->pdev->dev);
hangcheck_timer_reset(gpu);
}
--
2.7.4
[PATCH v2 4/5] clk: qcom: gpucc-sc7280: Add cx collapse reset support
Allow a consumer driver to poll for cx gdsc collapse through Reset
framework.
Signed-off-by: Akhil P Oommen
---
Changes in v2:
- Minor update to use the updated custom reset ops implementation
drivers/clk/qcom/gpucc-sc7280.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/clk/qcom/gpucc-sc7280.c b/drivers/clk/qcom/gpucc-sc7280.c
index 9a832f2..d4bc791 100644
--- a/drivers/clk/qcom/gpucc-sc7280.c
+++ b/drivers/clk/qcom/gpucc-sc7280.c
@@ -433,12 +433,22 @@ static const struct regmap_config
gpu_cc_sc7280_regmap_config = {
.fast_io = true,
};
+struct qcom_reset_ops cx_gdsc_reset = {
+ .reset = gdsc_wait_for_collapse,
+};
+
+static const struct qcom_reset_map gpucc_sc7280_resets[] = {
+ [GPU_CX_COLLAPSE] = { .ops = &cx_gdsc_reset, .priv = &cx_gdsc },
+};
+
static const struct qcom_cc_desc gpu_cc_sc7280_desc = {
.config = &gpu_cc_sc7280_regmap_config,
.clks = gpu_cc_sc7280_clocks,
.num_clks = ARRAY_SIZE(gpu_cc_sc7280_clocks),
.gdscs = gpu_cc_sc7180_gdscs,
.num_gdscs = ARRAY_SIZE(gpu_cc_sc7180_gdscs),
+ .resets = gpucc_sc7280_resets,
+ .num_resets = ARRAY_SIZE(gpucc_sc7280_resets),
};
static const struct of_device_id gpu_cc_sc7280_match_table[] = {
--
2.7.4
[PATCH v2 1/5] dt-bindings: clk: qcom: Support gpu cx gdsc reset
Add necessary definitions in gpucc bindings to ensure gpu cx gdsc collapse through 'reset' framework for SC7280. Signed-off-by: Akhil P Oommen Acked-by: Krzysztof Kozlowski --- (no changes since v1) include/dt-bindings/clock/qcom,gpucc-sc7280.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/dt-bindings/clock/qcom,gpucc-sc7280.h b/include/dt-bindings/clock/qcom,gpucc-sc7280.h index 669b23b..843a31b 100644 --- a/include/dt-bindings/clock/qcom,gpucc-sc7280.h +++ b/include/dt-bindings/clock/qcom,gpucc-sc7280.h @@ -32,4 +32,7 @@ #define GPU_CC_CX_GDSC 0 #define GPU_CC_GX_GDSC 1 +/* GPU_CC reset IDs */ +#define GPU_CX_COLLAPSE0 + #endif -- 2.7.4
[PATCH v4 0/7] Improve GPU Recovery
Recently, I debugged a few device crashes which occured during recovery after a hangcheck timeout. It looks like there are a few things we can do to improve our chance at a successful gpu recovery. First one is to ensure that CX GDSC collapses which clears the internal states in gpu's CX domain. First 5 patches tries to handle this. Rest of the patches are to ensure that few internal blocks like CP, GMU and GBIF are halted properly before proceeding for a snapshot followed by recovery. Also, handle 'prepare slumber' hfi failure correctly. These are A6x specific improvements. This series is rebased on top of v2 version of [1] which is based on linus's master branch. [1] https://patchwork.freedesktop.org/series/106860/ Changes in v4: - Keep active_submit lock across the suspend & resume (Rob) - Clear gpu->active_submits to silence a WARN() during runpm suspend (Rob) Changes in v3: - Use reset interface from gpucc driver to poll for cx gdsc collapse https://patchwork.freedesktop.org/series/106860/ - Use single pm refcount for all active submits Changes in v2: - Rebased on msm-next tip Akhil P Oommen (7): drm/msm: Remove unnecessary pm_runtime_get/put drm/msm: Take single rpm refcount on behalf of all submits drm/msm: Correct pm_runtime votes in recover worker drm/msm: Fix cx collapse issue during recovery drm/msm/a6xx: Ensure CX collapse during gpu recovery drm/msm/a6xx: Improve gpu recovery sequence drm/msm/a6xx: Handle GMU prepare-slumber hfi failure drivers/gpu/drm/msm/adreno/a6xx.xml.h | 4 ++ drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 83 ++- drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 43 -- drivers/gpu/drm/msm/msm_gpu.c | 21 ++--- drivers/gpu/drm/msm/msm_gpu.h | 4 ++ drivers/gpu/drm/msm/msm_ringbuffer.c | 4 -- 6 files changed, 114 insertions(+), 45 deletions(-) -- 2.7.4
[PATCH v4 6/7] drm/msm/a6xx: Improve gpu recovery sequence
We can do a few more things to improve our chance at a successful gpu
recovery, especially during a hangcheck timeout:
1. Halt CP and GMU core
2. Do RBBM GBIF HALT sequence
3. Do a soft reset of GPU core
Signed-off-by: Akhil P Oommen
---
(no changes since v1)
drivers/gpu/drm/msm/adreno/a6xx.xml.h | 4 ++
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 77 +--
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 7
3 files changed, 58 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx.xml.h
b/drivers/gpu/drm/msm/adreno/a6xx.xml.h
index b03e2c4..beea4a7 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx.xml.h
+++ b/drivers/gpu/drm/msm/adreno/a6xx.xml.h
@@ -1413,6 +1413,10 @@ static inline uint32_t
REG_A6XX_RBBM_PERFCTR_RBBM_SEL(uint32_t i0) { return 0x00
#define REG_A6XX_RBBM_GBIF_CLIENT_QOS_CNTL 0x0011
+#define REG_A6XX_RBBM_GBIF_HALT
0x0016
+
+#define REG_A6XX_RBBM_GBIF_HALT_ACK0x0017
+
#define REG_A6XX_RBBM_WAIT_FOR_GPU_IDLE_CMD0x001c
#define A6XX_RBBM_WAIT_FOR_GPU_IDLE_CMD_WAIT_GPU_IDLE 0x0001
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 9f76f5b..db05942 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -869,9 +869,47 @@ static void a6xx_gmu_rpmh_off(struct a6xx_gmu *gmu)
(val & 1), 100, 1000);
}
+#define GBIF_CLIENT_HALT_MASK BIT(0)
+#define GBIF_ARB_HALT_MASKBIT(1)
+
+static void a6xx_bus_clear_pending_transactions(struct adreno_gpu *adreno_gpu)
+{
+ struct msm_gpu *gpu = &adreno_gpu->base;
+
+ if (!a6xx_has_gbif(adreno_gpu)) {
+ gpu_write(gpu, REG_A6XX_VBIF_XIN_HALT_CTRL0, 0xf);
+ spin_until((gpu_read(gpu, REG_A6XX_VBIF_XIN_HALT_CTRL1) &
+ 0xf) == 0xf);
+ gpu_write(gpu, REG_A6XX_VBIF_XIN_HALT_CTRL0, 0);
+
+ return;
+ }
+
+ /* Halt the gx side of GBIF */
+ gpu_write(gpu, REG_A6XX_RBBM_GBIF_HALT, 1);
+ spin_until(gpu_read(gpu, REG_A6XX_RBBM_GBIF_HALT_ACK) & 1);
+
+ /* Halt new client requests on GBIF */
+ gpu_write(gpu, REG_A6XX_GBIF_HALT, GBIF_CLIENT_HALT_MASK);
+ spin_until((gpu_read(gpu, REG_A6XX_GBIF_HALT_ACK) &
+ (GBIF_CLIENT_HALT_MASK)) == GBIF_CLIENT_HALT_MASK);
+
+ /* Halt all AXI requests on GBIF */
+ gpu_write(gpu, REG_A6XX_GBIF_HALT, GBIF_ARB_HALT_MASK);
+ spin_until((gpu_read(gpu, REG_A6XX_GBIF_HALT_ACK) &
+ (GBIF_ARB_HALT_MASK)) == GBIF_ARB_HALT_MASK);
+
+ /* The GBIF halt needs to be explicitly cleared */
+ gpu_write(gpu, REG_A6XX_GBIF_HALT, 0x0);
+}
+
/* Force the GMU off in case it isn't responsive */
static void a6xx_gmu_force_off(struct a6xx_gmu *gmu)
{
+ struct a6xx_gpu *a6xx_gpu = container_of(gmu, struct a6xx_gpu, gmu);
+ struct adreno_gpu *adreno_gpu = &a6xx_gpu->base;
+ struct msm_gpu *gpu = &adreno_gpu->base;
+
/* Flush all the queues */
a6xx_hfi_stop(gmu);
@@ -883,6 +921,15 @@ static void a6xx_gmu_force_off(struct a6xx_gmu *gmu)
/* Make sure there are no outstanding RPMh votes */
a6xx_gmu_rpmh_off(gmu);
+
+ /* Halt the gmu cm3 core */
+ gmu_write(gmu, REG_A6XX_GMU_CM3_SYSRESET, 1);
+
+ a6xx_bus_clear_pending_transactions(adreno_gpu);
+
+ /* Reset GPU core blocks */
+ gpu_write(gpu, REG_A6XX_RBBM_SW_RESET_CMD, 1);
+ udelay(100);
}
static void a6xx_gmu_set_initial_freq(struct msm_gpu *gpu, struct a6xx_gmu
*gmu)
@@ -1010,36 +1057,6 @@ bool a6xx_gmu_isidle(struct a6xx_gmu *gmu)
return true;
}
-#define GBIF_CLIENT_HALT_MASK BIT(0)
-#define GBIF_ARB_HALT_MASKBIT(1)
-
-static void a6xx_bus_clear_pending_transactions(struct adreno_gpu *adreno_gpu)
-{
- struct msm_gpu *gpu = &adreno_gpu->base;
-
- if (!a6xx_has_gbif(adreno_gpu)) {
- gpu_write(gpu, REG_A6XX_VBIF_XIN_HALT_CTRL0, 0xf);
- spin_until((gpu_read(gpu, REG_A6XX_VBIF_XIN_HALT_CTRL1) &
- 0xf) == 0xf);
- gpu_write(gpu, REG_A6XX_VBIF_XIN_HALT_CTRL0, 0);
-
- return;
- }
-
- /* Halt new client requests on GBIF */
- gpu_write(gpu, REG_A6XX_GBIF_HALT, GBIF_CLIENT_HALT_MASK);
- spin_until((gpu_read(gpu, REG_A6XX_GBIF_HALT_ACK) &
- (GBIF_CLIENT_HALT_MASK)) == GBIF_CLIENT_HALT_MASK);
-
- /* Halt all AXI requests on GBIF */
- gpu_write(gpu, REG_A6XX_GBIF_HALT, GBIF_ARB_HALT_MASK);
- spin_until((gpu_read(gpu, REG_A6XX_GBIF_HALT_ACK) &
- (GBIF_ARB_HALT_MASK)) == GBIF_ARB_HALT_MASK);
-
- /* The GBIF halt needs to be
[PATCH v4 5/7] drm/msm/a6xx: Ensure CX collapse during gpu recovery
Because there could be transient votes from other drivers/tz/hyp which
may keep the cx gdsc enabled, we should poll until cx gdsc collapses.
We can use the reset framework to poll for cx gdsc collapse from gpucc
clk driver.
This feature requires support from the platform's gpucc driver.
Signed-off-by: Akhil P Oommen
Reviewed-by: Dmitry Baryshkov
---
(no changes since v3)
Changes in v3:
- Use reset interface from gpucc driver to poll for cx gdsc collapse
https://patchwork.freedesktop.org/series/106860/
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 4
drivers/gpu/drm/msm/msm_gpu.c | 4
drivers/gpu/drm/msm/msm_gpu.h | 4
3 files changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 0c8f19e..0ec4fcd 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -10,6 +10,7 @@
#include
#include
+#include
#include
#define GPU_PAS_ID 13
@@ -1229,6 +1230,9 @@ static void a6xx_recover(struct msm_gpu *gpu)
/* And the final one from recover worker */
pm_runtime_put_sync(&gpu->pdev->dev);
+ /* Call into gpucc driver to poll for cx gdsc collapse */
+ reset_control_reset(gpu->cx_collapse);
+
pm_runtime_use_autosuspend(&gpu->pdev->dev);
if (active_submits)
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index 07e55a6..4a57627 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
/*
@@ -903,6 +904,9 @@ int msm_gpu_init(struct drm_device *drm, struct
platform_device *pdev,
if (IS_ERR(gpu->gpu_cx))
gpu->gpu_cx = NULL;
+ gpu->cx_collapse = devm_reset_control_get_optional(&pdev->dev,
+ "cx_collapse");
+
gpu->pdev = pdev;
platform_set_drvdata(pdev, &gpu->adreno_smmu);
diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
index 6def008..ab59fd2 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include "msm_drv.h"
#include "msm_fence.h"
@@ -268,6 +269,9 @@ struct msm_gpu {
bool hw_apriv;
struct thermal_cooling_device *cooling;
+
+ /* To poll for cx gdsc collapse during gpu recovery */
+ struct reset_control *cx_collapse;
};
static inline struct msm_gpu *dev_to_gpu(struct device *dev)
--
2.7.4
