Re: [PATCH v3 0/2] Don't use stolen memory or BAR mappings for ring buffers
On Fri, 2023-02-17 at 09:18 -0800, John Harrison wrote: > On 2/17/2023 00:39, Hogander, Jouni wrote: > > On Wed, 2023-02-15 at 17:10 -0800, john.c.harri...@intel.com wrote: > > > From: John Harrison > > > > > > Instruction from hardware arch is that stolen memory and BAR > > > mappings > > > are unsafe for use as ring buffers. There can be issues with > > > cache > > > aliasing due to the CPU access going to memory via the BAR. So, > > > don't > > > do it. > > Tested these patches for GPU Hang I was debugging. Seem to fix that > > one > > as well: > > > > Tested-by: Jouni Högander > Sweet! Out of interest, which platform was that? And how reproducible > was it? It would be interesting to know if an IGT was actually > regularly > showing the issue and we had just been ignoring it! It was Alderlake. It wasn't igt test. Opened several browser instances: https://webglsamples.org/aquarium/aquarium.html Took max. couple of minutes to reproduce. For some reason PSR2 DEEP_SLEEP entry/exit was some kind of trigger for this. Without PSR2 DEEP_SLEEP I couldn't reproduce the issue. BR, Jouni Högander > John. > > > > > > v2: Dont use BAR mappings either. > > > Make conditional on LLC so as not to change platforms that don't > > > need > > > to change (Daniele). > > > Add 'Fixes' tags (Tvrtko). > > > v3: Fix dumb typo. > > > > > > Signed-off-by: John Harrison > > > > > > > > > John Harrison (2): > > > drm/i915: Don't use stolen memory for ring buffers with LLC > > > drm/i915: Don't use BAR mappings for ring buffers with LLC > > > > > > drivers/gpu/drm/i915/gt/intel_ring.c | 6 +++--- > > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > >
Re: linux-6.2-rc4+ hangs on poweroff/reboot: Bisected
On Sun, 19 Feb 2023 at 04:55, Chris Clayton wrote: > > > > On 18/02/2023 15:19, Chris Clayton wrote: > > > > > > On 18/02/2023 12:25, Karol Herbst wrote: > >> On Sat, Feb 18, 2023 at 1:22 PM Chris Clayton > >> wrote: > >>> > >>> > >>> > >>> On 15/02/2023 11:09, Karol Herbst wrote: > On Wed, Feb 15, 2023 at 11:36 AM Linux regression tracking #update > (Thorsten Leemhuis) wrote: > > > > On 13.02.23 10:14, Chris Clayton wrote: > >> On 13/02/2023 02:57, Dave Airlie wrote: > >>> On Sun, 12 Feb 2023 at 00:43, Chris Clayton > >>> wrote: > > > > On 10/02/2023 19:33, Linux regression tracking (Thorsten Leemhuis) > wrote: > > On 10.02.23 20:01, Karol Herbst wrote: > >> On Fri, Feb 10, 2023 at 7:35 PM Linux regression tracking (Thorsten > >> Leemhuis) wrote: > >>> > >>> On 08.02.23 09:48, Chris Clayton wrote: > > I'm assuming that we are not going to see a fix for this > regression before 6.2 is released. > >>> > >>> Yeah, looks like it. That's unfortunate, but happens. But there > >>> is still > >>> time to fix it and there is one thing I wonder: > >>> > >>> Did any of the nouveau developers look at the netconsole captures > >>> Chris > >>> posted more than a week ago to check if they somehow help to > >>> track down > >>> the root of this problem? > >> > >> I did now and I can't spot anything. I think at this point it would > >> make sense to dump the active tasks/threads via sqsrq keys to see > >> if > >> any is in a weird state preventing the machine from shutting down. > > > > Many thx for looking into it! > > Yes, thanks Karol. > > Attached is the output from dmesg when this block of code: > > /bin/mount /dev/sda7 /mnt/sda7 > /bin/mountpoint /proc || /bin/mount /proc > /bin/dmesg -w > /mnt/sda7/sysrq.dmesg.log & > /bin/echo t > /proc/sysrq-trigger > /bin/sleep 1 > /bin/sync > /bin/sleep 1 > kill $(pidof dmesg) > /bin/umount /mnt/sda7 > > is executed immediately before /sbin/reboot is called as the final > step of rebooting my system. > > I hope this is what you were looking for, but if not, please let me > know what you need > >> > >> Thanks Dave. [...] > > FWIW, in case anyone strands here in the archives: the msg was > > truncated. The full post can be found in a new thread: > > > > https://lore.kernel.org/lkml/e0b80506-b3cf-315b-4327-1b988d860...@googlemail.com/ > > > > Sadly it seems the info "With runpm=0, both reboot and poweroff work on > > my laptop." didn't bring us much further to a solution. :-/ I don't > > really like it, but for regression tracking I'm now putting this on the > > back-burner, as a fix is not in sight. > > > > #regzbot monitor: > > https://lore.kernel.org/lkml/e0b80506-b3cf-315b-4327-1b988d860...@googlemail.com/ > > #regzbot backburner: hard to debug and apparently rare > > #regzbot ignore-activity > > > > yeah.. this bug looks a little annoying. Sadly the only Turing based > laptop I got doesn't work on Nouveau because of firmware related > issues and we probably need to get updated ones from Nvidia here :( > > But it's a bit weird that the kernel doesn't shutdown, because I don't > see anything in the logs which would prevent that from happening. > Unless it's waiting on one of the tasks to complete, but none of them > looked in any way nouveau related. > > If somebody else has any fancy kernel debugging tips here to figure > out why it hangs, that would be very helpful... > > >>> > >>> I think I've figured this out. It's to do with how my system is > >>> configured. I do have an initrd, but the only thing on > >>> it is the cpu microcode which, it is recommended, should be loaded early. > >>> The absence of the NVidia firmare from an > >>> initrd doesn't matter because the drivers for the hardware that need to > >>> load firmware are all built as modules, So, by > >>> the time the devices are configured via udev, the root partition is > >>> mounted and the drivers can get at the firmware. > >>> > >>> I've found, by turning on nouveau debug and taking a video of the screen > >>> as the system shuts down, that nouveau seems to > >>> be trying to run the scrubber very very late in the shutdown process. The > >>> problem is that by this time, I think the root > >>> partition, and thus the scrubber binary, have become inaccessible. > >>> > >>> I seem to have two choices - either make the firmware
[PATCH v2] drm/msm: DEVFREQ_GOV_SIMPLE_ONDEMAND is no longer needed
DRM_MSM no longer needs DEVFREQ_GOV_SIMPLE_ONDEMAND (since dbd7a2a941b8
in linux-next: PM / devfreq: Fix build issues with devfreq disabled),
so remove that select from the DRM_MSM Kconfig file.
Fixes: 6563f60f14cb ("drm/msm/gpu: Add devfreq tuning debugfs")
Signed-off-by: Randy Dunlap
Cc: Rob Clark
Cc: Abhinav Kumar
Cc: Dmitry Baryshkov
Cc: Sean Paul
Cc: David Airlie
Cc: Daniel Vetter
Cc: linux-arm-...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: freedr...@lists.freedesktop.org
---
v2: since has been patched, this select is no longer
needed (Rob Clark)
drivers/gpu/drm/msm/Kconfig |1 -
1 file changed, 1 deletion(-)
diff -- a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
--- a/drivers/gpu/drm/msm/Kconfig
+++ b/drivers/gpu/drm/msm/Kconfig
@@ -23,7 +23,6 @@ config DRM_MSM
select SHMEM
select TMPFS
select QCOM_SCM
- select DEVFREQ_GOV_SIMPLE_ONDEMAND
select WANT_DEV_COREDUMP
select SND_SOC_HDMI_CODEC if SND_SOC
select SYNC_FILE
Re: [PATCH] drm/msm: fix new Konfig dependency warning
On Sun, Feb 19, 2023 at 3:12 PM Randy Dunlap wrote:
>
>
>
> On 2/19/23 15:09, Rob Clark wrote:
> > On Sun, Feb 19, 2023 at 10:54 AM Randy Dunlap wrote:
> >>
> >> DEVFREQ_GOV_SIMPLE_ONDEMAND depends on PM_DEVFREQ, so in order to
> >> select the former safely, this symbol should also depend on
> >> PM_DEVFREQ to avoid a Kconfig dependency warning.
> >>
> >> WARNING: unmet direct dependencies detected for DEVFREQ_GOV_SIMPLE_ONDEMAND
> >> Depends on [n]: PM_DEVFREQ [=n]
> >> Selected by [m]:
> >> - DRM_MSM [=m] && HAS_IOMEM [=y] && DRM [=m] && (ARCH_QCOM || SOC_IMX5
> >> || COMPILE_TEST [=y]) && COMMON_CLK [=y] && IOMMU_SUPPORT [=y] &&
> >> (QCOM_OCMEM [=n] || QCOM_OCMEM [=n]=n) && (QCOM_LLCC [=y] || QCOM_LLCC
> >> [=y]=n) && (QCOM_COMMAND_DB [=n] || QCOM_COMMAND_DB [=n]=n)
> >>
> >
> > Actually, I fixed devfreq[1] so that we no longer depend on
> > DEVFREQ_GOV_SIMPLE_ONDEMAND .. probably we should just drop
> > DEVFREQ_GOV_SIMPLE_ONDEMAND from the kconfig instead, sorry I forgot
> > to do that already
>
> OK, I'll resend the patch with that change, unless you want to handle it...
Go for it, thx
BR,
-R
> Thanks.
>
> > BR,
> > -R
> >
> > [1] https://patchwork.freedesktop.org/series/113232/
> >
> >> Fixes: 6563f60f14cb ("drm/msm/gpu: Add devfreq tuning debugfs")
> >> Signed-off-by: Randy Dunlap
> >> Cc: Rob Clark
> >> Cc: Abhinav Kumar
> >> Cc: Dmitry Baryshkov
> >> Cc: Sean Paul
> >> Cc: David Airlie
> >> Cc: Daniel Vetter
> >> Cc: linux-arm-...@vger.kernel.org
> >> Cc: dri-devel@lists.freedesktop.org
> >> Cc: freedr...@lists.freedesktop.org
> >> ---
> >> drivers/gpu/drm/msm/Kconfig |1 +
> >> 1 file changed, 1 insertion(+)
> >>
> >> diff -- a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
> >> --- a/drivers/gpu/drm/msm/Kconfig
> >> +++ b/drivers/gpu/drm/msm/Kconfig
> >> @@ -9,6 +9,7 @@ config DRM_MSM
> >> depends on QCOM_OCMEM || QCOM_OCMEM=n
> >> depends on QCOM_LLCC || QCOM_LLCC=n
> >> depends on QCOM_COMMAND_DB || QCOM_COMMAND_DB=n
> >> + depends on PM_DEVFREQ
> >> select IOMMU_IO_PGTABLE
> >> select QCOM_MDT_LOADER if ARCH_QCOM
> >> select REGULATOR
>
> --
> ~Randy
Re: [PATCH] drm/msm: fix new Konfig dependency warning
On 2/19/23 15:09, Rob Clark wrote:
> On Sun, Feb 19, 2023 at 10:54 AM Randy Dunlap wrote:
>>
>> DEVFREQ_GOV_SIMPLE_ONDEMAND depends on PM_DEVFREQ, so in order to
>> select the former safely, this symbol should also depend on
>> PM_DEVFREQ to avoid a Kconfig dependency warning.
>>
>> WARNING: unmet direct dependencies detected for DEVFREQ_GOV_SIMPLE_ONDEMAND
>> Depends on [n]: PM_DEVFREQ [=n]
>> Selected by [m]:
>> - DRM_MSM [=m] && HAS_IOMEM [=y] && DRM [=m] && (ARCH_QCOM || SOC_IMX5 ||
>> COMPILE_TEST [=y]) && COMMON_CLK [=y] && IOMMU_SUPPORT [=y] && (QCOM_OCMEM
>> [=n] || QCOM_OCMEM [=n]=n) && (QCOM_LLCC [=y] || QCOM_LLCC [=y]=n) &&
>> (QCOM_COMMAND_DB [=n] || QCOM_COMMAND_DB [=n]=n)
>>
>
> Actually, I fixed devfreq[1] so that we no longer depend on
> DEVFREQ_GOV_SIMPLE_ONDEMAND .. probably we should just drop
> DEVFREQ_GOV_SIMPLE_ONDEMAND from the kconfig instead, sorry I forgot
> to do that already
OK, I'll resend the patch with that change, unless you want to handle it...
Thanks.
> BR,
> -R
>
> [1] https://patchwork.freedesktop.org/series/113232/
>
>> Fixes: 6563f60f14cb ("drm/msm/gpu: Add devfreq tuning debugfs")
>> Signed-off-by: Randy Dunlap
>> Cc: Rob Clark
>> Cc: Abhinav Kumar
>> Cc: Dmitry Baryshkov
>> Cc: Sean Paul
>> Cc: David Airlie
>> Cc: Daniel Vetter
>> Cc: linux-arm-...@vger.kernel.org
>> Cc: dri-devel@lists.freedesktop.org
>> Cc: freedr...@lists.freedesktop.org
>> ---
>> drivers/gpu/drm/msm/Kconfig |1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff -- a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
>> --- a/drivers/gpu/drm/msm/Kconfig
>> +++ b/drivers/gpu/drm/msm/Kconfig
>> @@ -9,6 +9,7 @@ config DRM_MSM
>> depends on QCOM_OCMEM || QCOM_OCMEM=n
>> depends on QCOM_LLCC || QCOM_LLCC=n
>> depends on QCOM_COMMAND_DB || QCOM_COMMAND_DB=n
>> + depends on PM_DEVFREQ
>> select IOMMU_IO_PGTABLE
>> select QCOM_MDT_LOADER if ARCH_QCOM
>> select REGULATOR
--
~Randy
Re: [PATCH] drm/msm: fix new Konfig dependency warning
On Sun, Feb 19, 2023 at 10:54 AM Randy Dunlap wrote:
>
> DEVFREQ_GOV_SIMPLE_ONDEMAND depends on PM_DEVFREQ, so in order to
> select the former safely, this symbol should also depend on
> PM_DEVFREQ to avoid a Kconfig dependency warning.
>
> WARNING: unmet direct dependencies detected for DEVFREQ_GOV_SIMPLE_ONDEMAND
> Depends on [n]: PM_DEVFREQ [=n]
> Selected by [m]:
> - DRM_MSM [=m] && HAS_IOMEM [=y] && DRM [=m] && (ARCH_QCOM || SOC_IMX5 ||
> COMPILE_TEST [=y]) && COMMON_CLK [=y] && IOMMU_SUPPORT [=y] && (QCOM_OCMEM
> [=n] || QCOM_OCMEM [=n]=n) && (QCOM_LLCC [=y] || QCOM_LLCC [=y]=n) &&
> (QCOM_COMMAND_DB [=n] || QCOM_COMMAND_DB [=n]=n)
>
Actually, I fixed devfreq[1] so that we no longer depend on
DEVFREQ_GOV_SIMPLE_ONDEMAND .. probably we should just drop
DEVFREQ_GOV_SIMPLE_ONDEMAND from the kconfig instead, sorry I forgot
to do that already
BR,
-R
[1] https://patchwork.freedesktop.org/series/113232/
> Fixes: 6563f60f14cb ("drm/msm/gpu: Add devfreq tuning debugfs")
> Signed-off-by: Randy Dunlap
> Cc: Rob Clark
> Cc: Abhinav Kumar
> Cc: Dmitry Baryshkov
> Cc: Sean Paul
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: linux-arm-...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: freedr...@lists.freedesktop.org
> ---
> drivers/gpu/drm/msm/Kconfig |1 +
> 1 file changed, 1 insertion(+)
>
> diff -- a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
> --- a/drivers/gpu/drm/msm/Kconfig
> +++ b/drivers/gpu/drm/msm/Kconfig
> @@ -9,6 +9,7 @@ config DRM_MSM
> depends on QCOM_OCMEM || QCOM_OCMEM=n
> depends on QCOM_LLCC || QCOM_LLCC=n
> depends on QCOM_COMMAND_DB || QCOM_COMMAND_DB=n
> + depends on PM_DEVFREQ
> select IOMMU_IO_PGTABLE
> select QCOM_MDT_LOADER if ARCH_QCOM
> select REGULATOR
[PATCH] drm/msm: fix new Konfig dependency warning
DEVFREQ_GOV_SIMPLE_ONDEMAND depends on PM_DEVFREQ, so in order to
select the former safely, this symbol should also depend on
PM_DEVFREQ to avoid a Kconfig dependency warning.
WARNING: unmet direct dependencies detected for DEVFREQ_GOV_SIMPLE_ONDEMAND
Depends on [n]: PM_DEVFREQ [=n]
Selected by [m]:
- DRM_MSM [=m] && HAS_IOMEM [=y] && DRM [=m] && (ARCH_QCOM || SOC_IMX5 ||
COMPILE_TEST [=y]) && COMMON_CLK [=y] && IOMMU_SUPPORT [=y] && (QCOM_OCMEM [=n]
|| QCOM_OCMEM [=n]=n) && (QCOM_LLCC [=y] || QCOM_LLCC [=y]=n) &&
(QCOM_COMMAND_DB [=n] || QCOM_COMMAND_DB [=n]=n)
Fixes: 6563f60f14cb ("drm/msm/gpu: Add devfreq tuning debugfs")
Signed-off-by: Randy Dunlap
Cc: Rob Clark
Cc: Abhinav Kumar
Cc: Dmitry Baryshkov
Cc: Sean Paul
Cc: David Airlie
Cc: Daniel Vetter
Cc: linux-arm-...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: freedr...@lists.freedesktop.org
---
drivers/gpu/drm/msm/Kconfig |1 +
1 file changed, 1 insertion(+)
diff -- a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
--- a/drivers/gpu/drm/msm/Kconfig
+++ b/drivers/gpu/drm/msm/Kconfig
@@ -9,6 +9,7 @@ config DRM_MSM
depends on QCOM_OCMEM || QCOM_OCMEM=n
depends on QCOM_LLCC || QCOM_LLCC=n
depends on QCOM_COMMAND_DB || QCOM_COMMAND_DB=n
+ depends on PM_DEVFREQ
select IOMMU_IO_PGTABLE
select QCOM_MDT_LOADER if ARCH_QCOM
select REGULATOR
Re: [PATCH v4 09/14] drm/syncobj: Add deadline support for syncobj waits
On Sat, Feb 18, 2023 at 1:16 PM Rob Clark wrote:
>
> From: Rob Clark
>
> Add a new flag to let userspace provide a deadline as a hint for syncobj
> and timeline waits. This gives a hint to the driver signaling the
> backing fences about how soon userspace needs it to compete work, so it
> can addjust GPU frequency accordingly. An immediate deadline can be
> given to provide something equivalent to i915 "wait boost".
>
> Signed-off-by: Rob Clark
> ---
>
> I'm a bit on the fence about the addition of the DRM_CAP, but it seems
> useful to give userspace a way to probe whether the kernel and driver
> supports the new wait flag, especially since we have vk-common code
> dealing with syncobjs. But open to suggestions.
I guess an alternative would be to allow count_handles as a way to
probe the supported flags
BR,
-R
> drivers/gpu/drm/drm_ioctl.c | 3 ++
> drivers/gpu/drm/drm_syncobj.c | 59 ---
> include/drm/drm_drv.h | 6
> include/uapi/drm/drm.h| 16 --
> 4 files changed, 71 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index 7c9d66ee917d..1c5c942cf0f9 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -254,6 +254,9 @@ static int drm_getcap(struct drm_device *dev, void *data,
> struct drm_file *file_
> case DRM_CAP_SYNCOBJ_TIMELINE:
> req->value = drm_core_check_feature(dev,
> DRIVER_SYNCOBJ_TIMELINE);
> return 0;
> + case DRM_CAP_SYNCOBJ_DEADLINE:
> + req->value = drm_core_check_feature(dev,
> DRIVER_SYNCOBJ_TIMELINE);
> + return 0;
> }
>
> /* Other caps only work with KMS drivers */
> diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
> index 0c2be8360525..61cf97972a60 100644
> --- a/drivers/gpu/drm/drm_syncobj.c
> +++ b/drivers/gpu/drm/drm_syncobj.c
> @@ -973,7 +973,8 @@ static signed long drm_syncobj_array_wait_timeout(struct
> drm_syncobj **syncobjs,
> uint32_t count,
> uint32_t flags,
> signed long timeout,
> - uint32_t *idx)
> + uint32_t *idx,
> + ktime_t *deadline)
> {
> struct syncobj_wait_entry *entries;
> struct dma_fence *fence;
> @@ -1053,6 +1054,15 @@ static signed long
> drm_syncobj_array_wait_timeout(struct drm_syncobj **syncobjs,
> drm_syncobj_fence_add_wait(syncobjs[i], [i]);
> }
>
> + if (deadline) {
> + for (i = 0; i < count; ++i) {
> + fence = entries[i].fence;
> + if (!fence)
> + continue;
> + dma_fence_set_deadline(fence, *deadline);
> + }
> + }
> +
> do {
> set_current_state(TASK_INTERRUPTIBLE);
>
> @@ -1151,7 +1161,8 @@ static int drm_syncobj_array_wait(struct drm_device
> *dev,
> struct drm_file *file_private,
> struct drm_syncobj_wait *wait,
> struct drm_syncobj_timeline_wait
> *timeline_wait,
> - struct drm_syncobj **syncobjs, bool
> timeline)
> + struct drm_syncobj **syncobjs, bool
> timeline,
> + ktime_t *deadline)
> {
> signed long timeout = 0;
> uint32_t first = ~0;
> @@ -1162,7 +1173,8 @@ static int drm_syncobj_array_wait(struct drm_device
> *dev,
> NULL,
> wait->count_handles,
> wait->flags,
> -timeout, );
> +timeout, ,
> +deadline);
> if (timeout < 0)
> return timeout;
> wait->first_signaled = first;
> @@ -1172,7 +1184,8 @@ static int drm_syncobj_array_wait(struct drm_device
> *dev,
>
> u64_to_user_ptr(timeline_wait->points),
>
> timeline_wait->count_handles,
> timeline_wait->flags,
> -timeout, );
> +timeout, ,
> +deadline);
> if (timeout < 0)
[Bug 217058] amdgpu resets
https://bugzilla.kernel.org/show_bug.cgi?id=217058 Artem S. Tashkinov (a...@gmx.com) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |ANSWERED --- Comment #1 from Artem S. Tashkinov (a...@gmx.com) --- Please report here instead https://gitlab.freedesktop.org/drm/amd/-/issues -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH] drm/i915: move a Kconfig symbol to unbreak the menu presentation
On 2023.02.16 22:32:33 -0800, Randy Dunlap wrote: > Hi, > > On 2/16/23 17:52, Zhenyu Wang wrote: > > On 2023.02.14 20:45:33 -0800, Randy Dunlap wrote: > >> Inserting a Kconfig symbol that does not have a dependency (DRM_I915_GVT) > >> into a list of other symbols that do have a dependency (on DRM_I915) > >> breaks the driver menu presentation in 'make *config'. > >> > > > > I'm not sure what's the actual failure in presentation, I'm not quite > > familiar > > with Kconfig, could you help to elaborate? > > > > thanks! > > For menuconfig and nconfig, it's a subtle difference. The following menu > items are indented more after the patch (i.e., they are not indented enough > before the patch): > > │Enable KVM host support Intel GVT-g graphics virtualization > │ > │ [*] Enable Intel PXP support > │ > │ drm/i915 Debugging ---> > │ > │ drm/i915 Profile Guided Optimisation ---> > > Same menu items for gconfig: they should all be subordinate (so indented) > to the main > Intel 8xx/9xx/G3x/G4x/HD Graphics > menu. > > For xconfig, it's worse. "drm/i915 Debugging" and "drm/i915 Profile Guided > Optimisation" > are shown on the left side window, while are of the other i915 options are > shown in the > right side window (before the patch). > After the patch, all subordinate options are listed in the right side window > under the > main "Intel 8xx/9xx/G3x/G4x/HD Graphics" menu item. > > See attached photos for comparisons. > I wasn't awared of the wrong indentation. Thanks a lot, Randy! Acked-by: Zhenyu Wang signature.asc Description: PGP signature
RE: [PATCH 19/27] habanalabs: capture interrupt timestamp in handler
On Thu, Feb 16, 2023 16:39 PM, Stanislaw Gruszka wrote: > On Sun, Feb 12, 2023 at 10:44:46PM +0200, Oded Gabbay wrote: > > From: Ofir Bitton > > > > In order for interrupt timestamp to be more accurate we should capture > > it during the interrupt handling rather than in threaded irq context. > > Why this is important to have this timestamp more accurate ? I agree that the time diff between taking the timestamp in the interrupt handler vs taking it in the threaded irq context is negligible. Having said that it is still important as we would like to have the same timestamp for events that finished together, rather than having different timestamps when we process the events in the threaded irq handler. > What actually 'more accurate' mean in this context ? > > Regards > Stanislaw By 'more accurate' we mean closest to the MSIX interrupt. Ofir.
Re: [PATCH 1/1] drm/panel: st7703: Fix vertical refresh rate of XBD599
On Sun, Feb 19, 2023 at 12:45:53PM +0100, Frank Oltmanns wrote:
> Fix the XBD599 panel's slight visual stutter by correcting the pixel
> clock speed so that the panel's 60Hz vertical refresh rate is met.
>
> Set the clock speed using the underlying formula instead of a magic
> number. To have a consistent procedure for both panels, set the JH057N
> panel's clock also as a formula.
>
> ---
> drivers/gpu/drm/panel/panel-sitronix-st7703.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> index 6747ca237ced..cd7d631f7573 100644
> --- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> +++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> @@ -139,7 +139,7 @@ static const struct drm_display_mode jh057n00900_mode = {
> .vsync_start = 1440 + 20,
> .vsync_end = 1440 + 20 + 4,
> .vtotal = 1440 + 20 + 4 + 12,
> - .clock = 75276,
> + .clock = (720 + 90 + 20 + 20) * (1440 + 20 + 4 + 12) * 60 / 1000,
> .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
> .width_mm= 65,
> .height_mm = 130,
> @@ -324,7 +324,7 @@ static const struct drm_display_mode xbd599_mode = {
> .vsync_start = 1440 + 18,
> .vsync_end = 1440 + 18 + 10,
> .vtotal = 1440 + 18 + 10 + 17,
> - .clock = 69000,
> + .clock = (720 + 40 + 40 + 40) * (1440 + 18 + 10 + 17) * 60 / 1000,
As for pinephone, A64 can't produce 74.844 MHz precisely, so this will not work.
Better fix is to alter the mode so that clock can be something the only SoC this
panel is used with can actually produce.
See eg.
https://github.com/megous/linux/commit/dd070679d717e7f34af7558563698240a43981a6
which is tested to actually produce 60Hz by measuring the vsync events against
the CPU timer.
Your patch will not produce the intended effect.
kind regards,
o.
> .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
> .width_mm= 68,
> .height_mm = 136,
> --
> 2.39.1
>
Re: [PATCH 1/1] drm/panel: st7703: Fix vertical refresh rate of XBD599
Hi,
On Sun, Feb 19, 2023 at 12:45:53PM +0100, Frank Oltmanns wrote:
> Fix the XBD599 panel's slight visual stutter by correcting the pixel
> clock speed so that the panel's 60Hz vertical refresh rate is met.
>
> Set the clock speed using the underlying formula instead of a magic
> number. To have a consistent procedure for both panels, set the JH057N
> panel's clock also as a formula.
> ---
> drivers/gpu/drm/panel/panel-sitronix-st7703.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> index 6747ca237ced..cd7d631f7573 100644
> --- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> +++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> @@ -139,7 +139,7 @@ static const struct drm_display_mode jh057n00900_mode = {
> .vsync_start = 1440 + 20,
> .vsync_end = 1440 + 20 + 4,
> .vtotal = 1440 + 20 + 4 + 12,
> - .clock = 75276,
> + .clock = (720 + 90 + 20 + 20) * (1440 + 20 + 4 + 12) * 60 / 1000,
> .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
> .width_mm= 65,
> .height_mm = 130,
> @@ -324,7 +324,7 @@ static const struct drm_display_mode xbd599_mode = {
> .vsync_start = 1440 + 18,
> .vsync_end = 1440 + 18 + 10,
> .vtotal = 1440 + 18 + 10 + 17,
> - .clock = 69000,
> + .clock = (720 + 40 + 40 + 40) * (1440 + 18 + 10 + 17) * 60 / 1000,
> .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
> .width_mm= 68,
> .height_mm = 136,
Reviewed-by: Guido Günther
(I've seen your other patches but it will be some days until I can test
the jh057n00900 panel).
Cheers,
-- Guido
> --
> 2.39.1
>
[PATCH 1/1] drm/panel: st7703: Fix vertical refresh rate of XBD599
Fix the XBD599 panel's slight visual stutter by correcting the pixel
clock speed so that the panel's 60Hz vertical refresh rate is met.
Set the clock speed using the underlying formula instead of a magic
number. To have a consistent procedure for both panels, set the JH057N
panel's clock also as a formula.
---
drivers/gpu/drm/panel/panel-sitronix-st7703.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
index 6747ca237ced..cd7d631f7573 100644
--- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
+++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
@@ -139,7 +139,7 @@ static const struct drm_display_mode jh057n00900_mode = {
.vsync_start = 1440 + 20,
.vsync_end = 1440 + 20 + 4,
.vtotal = 1440 + 20 + 4 + 12,
- .clock = 75276,
+ .clock = (720 + 90 + 20 + 20) * (1440 + 20 + 4 + 12) * 60 / 1000,
.flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
.width_mm= 65,
.height_mm = 130,
@@ -324,7 +324,7 @@ static const struct drm_display_mode xbd599_mode = {
.vsync_start = 1440 + 18,
.vsync_end = 1440 + 18 + 10,
.vtotal = 1440 + 18 + 10 + 17,
- .clock = 69000,
+ .clock = (720 + 40 + 40 + 40) * (1440 + 18 + 10 + 17) * 60 / 1000,
.flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
.width_mm= 68,
.height_mm = 136,
--
2.39.1
[PATCH 0/1] drm/panel: st7703: Fix vertical refresh rate of XBD599
Currently, the XBD599 panel has a pixel clock rate that results in a vertical refresh rate of ~55.3 Hz. This causes a slight visual stuttering, for example on the PinePhone. To address this, I adjusted the pixel clock rate to 74844 kHz. Instead of using this hard coded value, I inserted the formula. This approach is already in use by: panel-jdi-fhd-r63452.c panel-samsung-s6e88a0-ams452ef01.c panel-asus-z00t-tm5p5-n35596.c panel-ebbg-ft8719.c panel-visionox-vtdr6130.c panel-sony-tulip-truly-nt35521.c panel-sharp-ls060t1sx01.c panel-samsung-sofef00.c To have a consistent procedure within panel-sitronix-st7703.c, I also used the formula for the JH057N panel's clock. The value for JH057N was already correct, so this change is purely cosmetic. I do realize that I submitted three separate patches for the ST7703 within just a few days ([1], [2]). Should I re-submit all three patches as a single patch set? These are my first contributions to the Linux kernel, therefore, I kindly ask for forgiveness regarding any breach of etiquette. Thanks, Frank [1] https://lore.kernel.org/all/20230211171748.36692-1-fr...@oltmanns.dev/ [2] https://lore.kernel.org/all/20230213123238.76889-1-fr...@oltmanns.dev/ Frank Oltmanns (1): drm/panel: st7703: Fix vertical refresh rate of XBD599 drivers/gpu/drm/panel/panel-sitronix-st7703.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- 2.39.1
