Re: [Letux-kernel] [PATCH 8/8] drm/ingenic: Attach bridge chain to encoders
Hi Paul, Le mar., août 10 2021 at 01:17:20 +0200, Paul Boddie a écrit : On Monday, 9 August 2021 18:22:12 CEST Paul Cercueil wrote: Le lun., août 9 2021 at 13:14:03 +0200, H. Nikolaus Schaller a écrit : > > quick feedback: our HDMI on top compiles fine after fixing 2 merge > conflicts, but dos not yet work. > Will need some spare time with access to the CI20 board to research > the issue, i.e. can not give feedback immediately. Alright, no problem. I'll be back home in about 2 weeks and then I can test on my CI20 as well. Just for reference, I looked into this initialisation failure. The HDMI peripheral driver gets initialised satisfactorily... dw-hdmi-ingenic 1018.hdmi: Detected HDMI TX controller v1.31a with HDCP (DWC HDMI 3D TX PHY) dw-hdmi-ingenic 1018.hdmi: registered DesignWare HDMI I2C bus driver But then the reported error occurs in the DRM driver: ingenic-drm 1305.lcdc0: Unable to init connector ingenic-drm: probe of 1305.lcdc0 failed with error -22 This originates in a call to drm_bridge_connector_init from ingenic_drm_bind: connector = drm_bridge_connector_init(drm, encoder); The invoked function iterates over the registered bridges, one of which seems to be the HDMI peripheral (it has bridge operations defined identically to those specified in the Synopsys driver), but the type member of the drm_bridge structure is set to 0 (DRM_MODE_CONNECTOR_Unknown). I might expect the bridge to expose a type acquired from its connector, but I don't see this propagation occurring in the Synopsys driver: dw_hdmi_probe sets the bridge operations and other members of the drm_bridge structure, but it doesn't set the type. Also, it might be possible that dw_hdmi_connector_detect (exposed as the detect operation) is not getting called, and this would explain why the bridge's connector member does not have the connector_type set, either (since it is also set to 0). From what I understand the last bridge in the chained list is supposed to set the connector type. The HDMI driver's probe function should get a pointer to the next bridge in the queue and attach it (see how ite-it66121.c does it). The last bridge in the queue should be "hdmi-connector" (display-connector.c) which will effectively set the connector type. Cheers, -Paul
RE: [RFC v1 0/4] drm: Add support for DRM_CAP_DEFERRED_OUT_FENCE capability
Hi Daniel, > On Fri, Aug 06, 2021 at 07:27:13AM +, Kasireddy, Vivek wrote: > > Hi Daniel, > > > > > > > > >>> The solution: > > > > > > >>> - To ensure full framerate, the Guest compositor has to start > > > > > > >>> it's repaint > cycle > > > > > (including > > > > > > >>> the 9 ms wait) when the Host compositor sends the frame > > > > > > >>> callback event to > its > > > > > clients. > > > > > > >>> In order for this to happen, the dma-fence that the Guest KMS > > > > > > >>> waits on -- > before > > > > > sending > > > > > > >>> pageflip completion -- cannot be tied to a wl_buffer.release > > > > > > >>> event. This > means > > > that, > > > > > the > > > > > > >>> Guest compositor has to be forced to use a new buffer for its > > > > > > >>> next repaint > cycle > > > > > when it > > > > > > >>> gets a pageflip completion. > > > > > > >> > > > > > > >> Is that really the only solution? > > > > > > > [Kasireddy, Vivek] There are a few others I mentioned here: > > > > > > > https://gitlab.freedesktop.org/wayland/weston/-/issues/514#note_986572 > > > > > > > But I think none of them are as compelling as this one. > > > > > > > > > > > > > >> > > > > > > >> If we fix the event timestamps so that both guest and host use > > > > > > >> the same > > > > > > >> timestamp, but then the guest starts 5ms (or something like > > > > > > >> that) earlier, > > > > > > >> then things should work too? I.e. > > > > > > >> - host compositor starts at (previous_frametime + 9ms) > > > > > > >> - guest compositor starts at (previous_frametime + 4ms) > > > > > > >> > > > > > > >> Ofc this only works if the frametimes we hand out to both match > > > > > > >> _exactly_ > > > > > > >> and are as high-precision as the ones on the host side. Which > > > > > > >> for many gpu > > > > > > >> drivers at least is the case, and all the ones you care about > > > > > > >> for sure :-) > > > > > > >> > > > > > > >> But if the frametimes the guest receives are the no_vblank fake > > > > > > >> ones, then > > > > > > >> they'll be all over the place and this carefully tuned > > > > > > >> low-latency redraw > > > > > > >> loop falls apart. Aside fromm the fact that without tuning the > > > > > > >> guests to > > > > > > >> be earlier than the hosts, you're guaranteed to miss every frame > > > > > > >> (except > > > > > > >> when the timing wobbliness in the guest is big enough by chance > > > > > > >> to make > > > > > > >> the deadline on the oddball frame). > > > > > > > [Kasireddy, Vivek] The Guest and Host use different event > > > > > > > timestamps as we > don't > > > > > > > share these between the Guest and the Host. It does not seem to > > > > > > > be causing any > > > other > > > > > > > problems so far but we did try the experiment you mentioned > > > > > > > (i.e., adjusting > the > > > > > delays) > > > > > > > and it works. However, this patch series is meant to fix the > > > > > > > issue without > having to > > > > > tweak > > > > > > > anything (delays) because we can't do this for every compositor > > > > > > > out there. > > > > > > > > > > > > Maybe there could be a mechanism which allows the compositor in the > > > > > > guest to > > > > > automatically adjust its repaint cycle as needed. > > > > > > > > > > > > This might even be possible without requiring changes in each > > > > > > compositor, by > > > adjusting > > > > > the vertical blank periods in the guest to be aligned with the host > > > > > compositor > repaint > > > > > cycles. Not sure about that though. > > > > > > > > > > > > Even if not, both this series or making it possible to queue > > > > > > multiple flips require > > > > > corresponding changes in each compositor as well to have any effect. > > > > > > > > > > Yeah from all the discussions and tests done it sounds even with a > > > > > deeper queue we have big coordination issues between the guest and > > > > > host compositor (like the example that the guest is now rendering at > > > > > 90fps instead of 60fps like the host). > > > > [Kasireddy, Vivek] Oh, I think you are referring to my reply to Gerd. > > > > That 90 FPS vs > > > > 60 FPS problem is a completely different issue that is associated with > > > > Qemu GTK UI > > > > backend. With the GTK backend -- and also with SDL backend -- we Blit > > > > the Guest > > > > scanout FB onto one of the backbuffers managed by EGL. > > > > > > > > I am trying to add a new Qemu Wayland UI backend so that we can > > > > eliminate that > Blit > > > > and thereby have a truly zero-copy solution. And, this is there I am > > > > running into the > > > > halved frame-rate issue -- the current problem. > > > > > > Yes, that's what I referenced. But I disagree that it's a different > > > problem. The underlying problem in both cases is that the guest and host > > > compositor free-wheel instead of rendering in sync. It's just that > > > depending upon how exactly the flip completion event on the gues side > > > plays out yo
Re: [PATCH] dma-buf: heaps: Set allocation limit for system heap
Hi Hridya, Apologies for the delay in responding. On Wed, 4 Aug 2021 at 03:09, Hridya Valsaraju wrote: > On Mon, Aug 2, 2021 at 7:18 PM John Stultz wrote: > > > > On Thu, Jul 22, 2021 at 12:07 PM Hridya Valsaraju > wrote: > > > This patch limits the size of total memory that can be requested in a > > > single allocation from the system heap. This would prevent a > > > buggy/malicious client from depleting system memory by requesting for > an > > > extremely large allocation which might destabilize the system. > > > > > > The limit is set to half the size of the device's total RAM which is > the > > > same as what was set by the deprecated ION system heap. > > > > > > Signed-off-by: Hridya Valsaraju > > > > Seems sane to me, unless folks have better suggestions for allocation > limits. > > > > Reviewed-by: John Stultz > > Thank you for taking a look John! > Looks good to me; I will apply it to drm-misc today. > > Regards, > Hridya > > > > > thanks > > -john > Best, Sumit. -- Thanks and regards, Sumit Semwal (he / him) Tech Lead - LCG, Vertical Technologies Linaro.org │ Open source software for ARM SoCs
Re: [PATCH] dma-buf: heaps: Set allocation limit for system heap
Hi Hridya, Apologies for the delay in responding; On Wed, 4 Aug 2021 at 03:09, Hridya Valsaraju wrote: > > On Mon, Aug 2, 2021 at 7:18 PM John Stultz wrote: > > > > On Thu, Jul 22, 2021 at 12:07 PM Hridya Valsaraju wrote: > > > This patch limits the size of total memory that can be requested in a > > > single allocation from the system heap. This would prevent a > > > buggy/malicious client from depleting system memory by requesting for an > > > extremely large allocation which might destabilize the system. > > > > > > The limit is set to half the size of the device's total RAM which is the > > > same as what was set by the deprecated ION system heap. > > > > > > Signed-off-by: Hridya Valsaraju > > > > Seems sane to me, unless folks have better suggestions for allocation > > limits. > > > > Reviewed-by: John Stultz > > Thank you for taking a look John! Looks good to me; I will apply it to drm-misc today. > > Regards, > Hridya > > > > > thanks > > -john Best, Sumit. -- Thanks and regards, Sumit Semwal (he / him) Tech Lead - LCG, Vertical Technologies Linaro.org │ Open source software for ARM SoCs
Re: [RFC v1 0/4] drm: Add support for DRM_CAP_DEFERRED_OUT_FENCE capability
On Tue, Aug 10, 2021 at 08:21:09AM +, Kasireddy, Vivek wrote: > Hi Daniel, > > > On Fri, Aug 06, 2021 at 07:27:13AM +, Kasireddy, Vivek wrote: > > > Hi Daniel, > > > > > > > > > > >>> The solution: > > > > > > > >>> - To ensure full framerate, the Guest compositor has to start > > > > > > > >>> it's repaint > > cycle > > > > > > (including > > > > > > > >>> the 9 ms wait) when the Host compositor sends the frame > > > > > > > >>> callback event to > > its > > > > > > clients. > > > > > > > >>> In order for this to happen, the dma-fence that the Guest KMS > > > > > > > >>> waits on -- > > before > > > > > > sending > > > > > > > >>> pageflip completion -- cannot be tied to a wl_buffer.release > > > > > > > >>> event. This > > means > > > > that, > > > > > > the > > > > > > > >>> Guest compositor has to be forced to use a new buffer for its > > > > > > > >>> next repaint > > cycle > > > > > > when it > > > > > > > >>> gets a pageflip completion. > > > > > > > >> > > > > > > > >> Is that really the only solution? > > > > > > > > [Kasireddy, Vivek] There are a few others I mentioned here: > > > > > > > > https://gitlab.freedesktop.org/wayland/weston/-/issues/514#note_986572 > > > > > > > > But I think none of them are as compelling as this one. > > > > > > > > > > > > > > > >> > > > > > > > >> If we fix the event timestamps so that both guest and host use > > > > > > > >> the same > > > > > > > >> timestamp, but then the guest starts 5ms (or something like > > > > > > > >> that) earlier, > > > > > > > >> then things should work too? I.e. > > > > > > > >> - host compositor starts at (previous_frametime + 9ms) > > > > > > > >> - guest compositor starts at (previous_frametime + 4ms) > > > > > > > >> > > > > > > > >> Ofc this only works if the frametimes we hand out to both > > > > > > > >> match _exactly_ > > > > > > > >> and are as high-precision as the ones on the host side. Which > > > > > > > >> for many gpu > > > > > > > >> drivers at least is the case, and all the ones you care about > > > > > > > >> for sure :-) > > > > > > > >> > > > > > > > >> But if the frametimes the guest receives are the no_vblank > > > > > > > >> fake ones, then > > > > > > > >> they'll be all over the place and this carefully tuned > > > > > > > >> low-latency redraw > > > > > > > >> loop falls apart. Aside fromm the fact that without tuning the > > > > > > > >> guests to > > > > > > > >> be earlier than the hosts, you're guaranteed to miss every > > > > > > > >> frame (except > > > > > > > >> when the timing wobbliness in the guest is big enough by > > > > > > > >> chance to make > > > > > > > >> the deadline on the oddball frame). > > > > > > > > [Kasireddy, Vivek] The Guest and Host use different event > > > > > > > > timestamps as we > > don't > > > > > > > > share these between the Guest and the Host. It does not seem to > > > > > > > > be causing any > > > > other > > > > > > > > problems so far but we did try the experiment you mentioned > > > > > > > > (i.e., adjusting > > the > > > > > > delays) > > > > > > > > and it works. However, this patch series is meant to fix the > > > > > > > > issue without > > having to > > > > > > tweak > > > > > > > > anything (delays) because we can't do this for every compositor > > > > > > > > out there. > > > > > > > > > > > > > > Maybe there could be a mechanism which allows the compositor in > > > > > > > the guest to > > > > > > automatically adjust its repaint cycle as needed. > > > > > > > > > > > > > > This might even be possible without requiring changes in each > > > > > > > compositor, by > > > > adjusting > > > > > > the vertical blank periods in the guest to be aligned with the host > > > > > > compositor > > repaint > > > > > > cycles. Not sure about that though. > > > > > > > > > > > > > > Even if not, both this series or making it possible to queue > > > > > > > multiple flips require > > > > > > corresponding changes in each compositor as well to have any effect. > > > > > > > > > > > > Yeah from all the discussions and tests done it sounds even with a > > > > > > deeper queue we have big coordination issues between the guest and > > > > > > host compositor (like the example that the guest is now rendering at > > > > > > 90fps instead of 60fps like the host). > > > > > [Kasireddy, Vivek] Oh, I think you are referring to my reply to Gerd. > > > > > That 90 FPS vs > > > > > 60 FPS problem is a completely different issue that is associated > > > > > with Qemu GTK UI > > > > > backend. With the GTK backend -- and also with SDL backend -- we Blit > > > > > the Guest > > > > > scanout FB onto one of the backbuffers managed by EGL. > > > > > > > > > > I am trying to add a new Qemu Wayland UI backend so that we can > > > > > eliminate that > > Blit > > > > > and thereby have a truly zero-copy solution. And, this is there I am > > > > > running into the > > > > > halved frame-rate issue -- the current problem. > > > > > > > > Yes, that's what I r
Re: [PATCH v2 5/5] drm/mediatek: Add support for main DDP path on MT8167
On 27/10/2020 17:08, Fabien Parent wrote:
> Hi Chun-Kuang,
>
> On Fri, Oct 23, 2020 at 5:52 PM Chun-Kuang Hu wrote:
>>
>> Hi, Fabien:
>>
>> Fabien Parent 於 2020年10月23日 週五 下午9:31寫道：
>>>
>>> Add the main (DSI) drm display path for MT8167.
>>>
>>> Signed-off-by: Fabien Parent
>>> ---
>>>
>>> Changelog:
>>>
>>> V2: No change
>>>
>>> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 38 ++
>>> 1 file changed, 38 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
>>> b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
>>> index 59c85c63b7cc..3952435093fe 100644
>>> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
>>> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
>>> @@ -112,6 +112,17 @@ static const enum mtk_ddp_comp_id
>>> mt2712_mtk_ddp_third[] = {
>>> DDP_COMPONENT_PWM2,
>>> };
>>>
>>> +static enum mtk_ddp_comp_id mt8167_mtk_ddp_main[] = {
>>> + DDP_COMPONENT_OVL0,
>>> + DDP_COMPONENT_COLOR0,
>>> + DDP_COMPONENT_CCORR,
>>> + DDP_COMPONENT_AAL0,
>>> + DDP_COMPONENT_GAMMA,
>>> + DDP_COMPONENT_DITHER,
>>> + DDP_COMPONENT_RDMA0,
>>> + DDP_COMPONENT_DSI0,
>>> +};
>>> +
>>> static const enum mtk_ddp_comp_id mt8173_mtk_ddp_main[] = {
>>> DDP_COMPONENT_OVL0,
>>> DDP_COMPONENT_COLOR0,
>>> @@ -163,6 +174,11 @@ static const struct mtk_mmsys_driver_data
>>> mt8173_mmsys_driver_data = {
>>> .ext_len = ARRAY_SIZE(mt8173_mtk_ddp_ext),
>>> };
>>>
>>> +static const struct mtk_mmsys_driver_data mt8167_mmsys_driver_data = {
>>> + .main_path = mt8167_mtk_ddp_main,
>>> + .main_len = ARRAY_SIZE(mt8167_mtk_ddp_main),
>>> +};
>>> +
>>> static int mtk_drm_kms_init(struct drm_device *drm)
>>> {
>>> struct mtk_drm_private *private = drm->dev_private;
>>> @@ -401,26 +417,42 @@ static const struct component_master_ops mtk_drm_ops
>>> = {
>>> static const struct of_device_id mtk_ddp_comp_dt_ids[] = {
>>> { .compatible = "mediatek,mt2701-disp-ovl",
>>> .data = (void *)MTK_DISP_OVL },
>>> + { .compatible = "mediatek,mt8167-disp-ovl",
>>> + .data = (void *)MTK_DISP_OVL },
>>> { .compatible = "mediatek,mt8173-disp-ovl",
>>> .data = (void *)MTK_DISP_OVL },
>>> { .compatible = "mediatek,mt2701-disp-rdma",
>>> .data = (void *)MTK_DISP_RDMA },
>>> + { .compatible = "mediatek,mt8167-disp-rdma",
>>> + .data = (void *)MTK_DISP_RDMA },
>>> { .compatible = "mediatek,mt8173-disp-rdma",
>>> .data = (void *)MTK_DISP_RDMA },
>>> { .compatible = "mediatek,mt8173-disp-wdma",
>>> .data = (void *)MTK_DISP_WDMA },
>>> + { .compatible = "mediatek,mt8167-disp-ccorr",
>>> + .data = (void *)MTK_DISP_CCORR },
>>> { .compatible = "mediatek,mt2701-disp-color",
>>> .data = (void *)MTK_DISP_COLOR },
>>> + { .compatible = "mediatek,mt8167-disp-color",
>>> + .data = (void *)MTK_DISP_COLOR },
>>> { .compatible = "mediatek,mt8173-disp-color",
>>> .data = (void *)MTK_DISP_COLOR },
>>> + { .compatible = "mediatek,mt8167-disp-aal",
>>> + .data = (void *)MTK_DISP_AAL},
>>> { .compatible = "mediatek,mt8173-disp-aal",
>>> .data = (void *)MTK_DISP_AAL},
>>> + { .compatible = "mediatek,mt8167-disp-gamma",
>>> + .data = (void *)MTK_DISP_GAMMA, },
>>> { .compatible = "mediatek,mt8173-disp-gamma",
>>> .data = (void *)MTK_DISP_GAMMA, },
>>> + { .compatible = "mediatek,mt8167-disp-dither",
>>> + .data = (void *)MTK_DISP_DITHER },
>>> { .compatible = "mediatek,mt8173-disp-ufoe",
>>> .data = (void *)MTK_DISP_UFOE },
>>> { .compatible = "mediatek,mt2701-dsi",
>>> .data = (void *)MTK_DSI },
>>> + { .compatible = "mediatek,mt8167-dsi",
>>> + .data = (void *)MTK_DSI },
>>> { .compatible = "mediatek,mt8173-dsi",
>>> .data = (void *)MTK_DSI },
>>> { .compatible = "mediatek,mt2701-dpi",
>>> @@ -431,10 +463,14 @@ static const struct of_device_id
>>> mtk_ddp_comp_dt_ids[] = {
>>> .data = (void *)MTK_DISP_MUTEX },
>>> { .compatible = "mediatek,mt2712-disp-mutex",
>>> .data = (void *)MTK_DISP_MUTEX },
>>> + { .compatible = "mediatek,mt8167-disp-mutex",
>>> + .data = (void *)MTK_DISP_MUTEX },
>>> { .compatible = "mediatek,mt8173-disp-mutex",
>>> .data = (void *)MTK_DISP_MUTEX },
>>> { .compatible = "mediatek,mt2701-disp-pwm",
>>> .data = (void *)MTK_DISP_BLS },
>>> + { .compatible = "mediatek,mt8167-disp-pwm",
>>> + .data = (void *)MTK_DISP_PWM },
>>> { .compatible = "mediatek,mt8173-disp-pwm",
>>> .data = (void *)MTK_DISP_PWM },
>>> { .compatible = "mediatek,mt8173-disp-od",
>>> @@ -449,6 +485,8 @@ static const struct of_device_id mtk_drm_of_ids[] = {
>>> .data = &mt7623_mmsys_driver_data},
>>> {
Re: [Intel-gfx] [PATCH v2] fbdev/efifb: Release PCI device's runtime PM ref during FB destroy
Hi Kai-Heng, Alex,
could you add your ack if the fix looks ok and you're ok if I push it to
the i915 tree?
Thanks,
Imre
On Mon, Aug 09, 2021 at 04:31:46PM +0300, Imre Deak wrote:
> Atm the EFI FB platform driver gets a runtime PM reference for the
> associated GFX PCI device during probing the EFI FB platform device and
> releases it only when the platform device gets unbound.
>
> When fbcon switches to the FB provided by the PCI device's driver (for
> instance i915/drmfb), the EFI FB will get only unregistered without the
> EFI FB platform device getting unbound, keeping the runtime PM reference
> acquired during the platform device probing. This reference will prevent
> the PCI driver from runtime suspending the device.
>
> Fix this by releasing the RPM reference from the EFI FB's destroy hook,
> called when the FB gets unregistered.
>
> While at it assert that pm_runtime_get_sync() didn't fail.
>
> v2:
> - Move pm_runtime_get_sync() before register_framebuffer() to avoid its
> race wrt. efifb_destroy()->pm_runtime_put(). (Daniel)
> - Assert that pm_runtime_get_sync() didn't fail.
> - Clarify commit message wrt. platform/PCI device/driver and driver
> removal vs. device unbinding.
>
> Fixes: a6c0fd3d5a8b ("efifb: Ensure graphics device for efifb stays at PCI
> D0")
> Cc: Kai-Heng Feng
> Cc: Daniel Vetter
> Reviewed-by: Daniel Vetter (v1)
> Signed-off-by: Imre Deak
> ---
> drivers/video/fbdev/efifb.c | 21 ++---
> 1 file changed, 14 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
> index 8ea8f079cde26..edca3703b9640 100644
> --- a/drivers/video/fbdev/efifb.c
> +++ b/drivers/video/fbdev/efifb.c
> @@ -47,6 +47,8 @@ static bool use_bgrt = true;
> static bool request_mem_succeeded = false;
> static u64 mem_flags = EFI_MEMORY_WC | EFI_MEMORY_UC;
>
> +static struct pci_dev *efifb_pci_dev;/* dev with BAR covering the
> efifb */
> +
> static struct fb_var_screeninfo efifb_defined = {
> .activate = FB_ACTIVATE_NOW,
> .height = -1,
> @@ -243,6 +245,9 @@ static inline void efifb_show_boot_graphics(struct
> fb_info *info) {}
>
> static void efifb_destroy(struct fb_info *info)
> {
> + if (efifb_pci_dev)
> + pm_runtime_put(&efifb_pci_dev->dev);
> +
> if (info->screen_base) {
> if (mem_flags & (EFI_MEMORY_UC | EFI_MEMORY_WC))
> iounmap(info->screen_base);
> @@ -333,7 +338,6 @@ ATTRIBUTE_GROUPS(efifb);
>
> static bool pci_dev_disabled;/* FB base matches BAR of a disabled
> device */
>
> -static struct pci_dev *efifb_pci_dev;/* dev with BAR covering the
> efifb */
> static struct resource *bar_resource;
> static u64 bar_offset;
>
> @@ -569,17 +573,22 @@ static int efifb_probe(struct platform_device *dev)
> pr_err("efifb: cannot allocate colormap\n");
> goto err_groups;
> }
> +
> + if (efifb_pci_dev)
> + WARN_ON(pm_runtime_get_sync(&efifb_pci_dev->dev) < 0);
> +
> err = register_framebuffer(info);
> if (err < 0) {
> pr_err("efifb: cannot register framebuffer\n");
> - goto err_fb_dealoc;
> + goto err_put_rpm_ref;
> }
> fb_info(info, "%s frame buffer device\n", info->fix.id);
> - if (efifb_pci_dev)
> - pm_runtime_get_sync(&efifb_pci_dev->dev);
> return 0;
>
> -err_fb_dealoc:
> +err_put_rpm_ref:
> + if (efifb_pci_dev)
> + pm_runtime_put(&efifb_pci_dev->dev);
> +
> fb_dealloc_cmap(&info->cmap);
> err_groups:
> sysfs_remove_groups(&dev->dev.kobj, efifb_groups);
> @@ -603,8 +612,6 @@ static int efifb_remove(struct platform_device *pdev)
> unregister_framebuffer(info);
> sysfs_remove_groups(&pdev->dev.kobj, efifb_groups);
> framebuffer_release(info);
> - if (efifb_pci_dev)
> - pm_runtime_put(&efifb_pci_dev->dev);
>
> return 0;
> }
> --
> 2.27.0
>
Re: [PATCH] dma-buf: heaps: Set allocation limit for system heap
On Tue, Aug 10, 2021 at 01:54:41PM +0530, Sumit Semwal wrote: > Hi Hridya, > > Apologies for the delay in responding. > > On Wed, 4 Aug 2021 at 03:09, Hridya Valsaraju wrote: > > > On Mon, Aug 2, 2021 at 7:18 PM John Stultz wrote: > > > > > > On Thu, Jul 22, 2021 at 12:07 PM Hridya Valsaraju > > wrote: > > > > This patch limits the size of total memory that can be requested in a > > > > single allocation from the system heap. This would prevent a > > > > buggy/malicious client from depleting system memory by requesting for > > an > > > > extremely large allocation which might destabilize the system. > > > > > > > > The limit is set to half the size of the device's total RAM which is > > the > > > > same as what was set by the deprecated ION system heap. > > > > > > > > Signed-off-by: Hridya Valsaraju > > > > > > Seems sane to me, unless folks have better suggestions for allocation > > limits. > > > > > > Reviewed-by: John Stultz > > > > Thank you for taking a look John! > > > Looks good to me; I will apply it to drm-misc today. Please don't, this doesn't really solve anything: - it's easy to bypass, just allocate more buffers to get over the limit - resource limit plan is cgroups, not hand-rolled limits in every allocator - the ttm "max half of system memory" is for pinned memory, to work around locking inversion issues between dma_resv_lock and core mm shrinkers. It does not actually impose an overall allocation limit, you can allocate ttm bo until your entire memory (and swap) are full. Christian König has merged a patch set to lift this by reworking the shrinker interaction, but it had to be reverted again because of some fallout I can't remember offhand. dma_resv_lock vs shrinkers is very tricky. So if you want resource limits then you really want cgroups here. Cheers, Daniel > > > > > > Regards, > > Hridya > > > > > > > > thanks > > > -john > > > Best, > Sumit. > > -- > Thanks and regards, > > Sumit Semwal (he / him) > Tech Lead - LCG, Vertical Technologies > Linaro.org │ Open source software for ARM SoCs -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH] drm/i915/gem/ttm: prefer kernel types
Avoid uintXX_t types in the driver.
Fixes: 213d50927763 ("drm/i915/ttm: Introduce a TTM i915 gem object backend")
Cc: Thomas Hellström
Cc: Matthew Auld
Cc: Maarten Lankhorst
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 771eb2963123..ffda88156e32 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -168,7 +168,7 @@ i915_ttm_placement_from_obj(const struct
drm_i915_gem_object *obj,
}
static struct ttm_tt *i915_ttm_tt_create(struct ttm_buffer_object *bo,
-uint32_t page_flags)
+u32 page_flags)
{
struct ttm_resource_manager *man =
ttm_manager_type(bo->bdev, bo->resource->mem_type);
--
2.20.1
Re: [Intel-gfx] [PATCH 15/46] drm/i915/guc: Introduce context parent-child relationship
On Mon, Aug 09, 2021 at 06:44:16PM +, Matthew Brost wrote:
> On Mon, Aug 09, 2021 at 04:37:55PM +0200, Daniel Vetter wrote:
> > On Tue, Aug 03, 2021 at 03:29:12PM -0700, Matthew Brost wrote:
> > > Introduce context parent-child relationship. Once this relationship is
> > > created all pinning / unpinning operations are directed to the parent
> > > context. The parent context is responsible for pinning all of its'
> > > children and itself.
> > >
> > > This is a precursor to the full GuC multi-lrc implementation but aligns
> > > to how GuC mutli-lrc interface is defined - a single H2G is used
> > > register / deregister all of the contexts simultaneously.
> > >
> > > Subsequent patches in the series will implement the pinning / unpinning
> > > operations for parent / child contexts.
> > >
> > > Signed-off-by: Matthew Brost
> > > ---
> > > drivers/gpu/drm/i915/gt/intel_context.c | 29 +++
> > > drivers/gpu/drm/i915/gt/intel_context.h | 18
> > > drivers/gpu/drm/i915/gt/intel_context_types.h | 12
> > > 3 files changed, 59 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
> > > b/drivers/gpu/drm/i915/gt/intel_context.c
> > > index 745e84c72c90..8cb92b10b547 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_context.c
> > > +++ b/drivers/gpu/drm/i915/gt/intel_context.c
> > > @@ -395,6 +395,8 @@ intel_context_init(struct intel_context *ce, struct
> > > intel_engine_cs *engine)
> > > spin_lock_init(&ce->guc_state.lock);
> > > INIT_LIST_HEAD(&ce->guc_state.fences);
> > >
> > > + INIT_LIST_HEAD(&ce->guc_child_list);
> > > +
> > > spin_lock_init(&ce->guc_active.lock);
> > > INIT_LIST_HEAD(&ce->guc_active.requests);
> > >
> > > @@ -414,10 +416,17 @@ intel_context_init(struct intel_context *ce, struct
> > > intel_engine_cs *engine)
> > >
> > > void intel_context_fini(struct intel_context *ce)
> > > {
> > > + struct intel_context *child, *next;
> > > +
> > > if (ce->timeline)
> > > intel_timeline_put(ce->timeline);
> > > i915_vm_put(ce->vm);
> > >
> > > + /* Need to put the creation ref for the children */
> > > + if (intel_context_is_parent(ce))
> > > + for_each_child_safe(ce, child, next)
> > > + intel_context_put(child);
> > > +
> > > mutex_destroy(&ce->pin_mutex);
> > > i915_active_fini(&ce->active);
> > > }
> > > @@ -533,6 +542,26 @@ struct i915_request
> > > *intel_context_find_active_request(struct intel_context *ce)
> > > return active;
> > > }
> > >
> > > +void intel_context_bind_parent_child(struct intel_context *parent,
> > > + struct intel_context *child)
> > > +{
> > > + /*
> > > + * Callers responsibility to validate that this function is used
> > > + * correctly but we use GEM_BUG_ON here ensure that they do.
> > > + */
> > > + GEM_BUG_ON(!intel_engine_uses_guc(parent->engine));
> > > + GEM_BUG_ON(intel_context_is_pinned(parent));
> > > + GEM_BUG_ON(intel_context_is_child(parent));
> > > + GEM_BUG_ON(intel_context_is_pinned(child));
> > > + GEM_BUG_ON(intel_context_is_child(child));
> > > + GEM_BUG_ON(intel_context_is_parent(child));
> > > +
> > > + parent->guc_number_children++;
> > > + list_add_tail(&child->guc_child_link,
> > > + &parent->guc_child_list);
> > > + child->parent = parent;
> > > +}
> > > +
> > > #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
> > > #include "selftest_context.c"
> > > #endif
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
> > > b/drivers/gpu/drm/i915/gt/intel_context.h
> > > index c41098950746..ad6ce5ac4824 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_context.h
> > > +++ b/drivers/gpu/drm/i915/gt/intel_context.h
> > > @@ -44,6 +44,24 @@ void intel_context_free(struct intel_context *ce);
> > > int intel_context_reconfigure_sseu(struct intel_context *ce,
> > > const struct intel_sseu sseu);
> > >
> > > +static inline bool intel_context_is_child(struct intel_context *ce)
> > > +{
> > > + return !!ce->parent;
> > > +}
> > > +
> > > +static inline bool intel_context_is_parent(struct intel_context *ce)
> > > +{
> > > + return !!ce->guc_number_children;
> > > +}
> > > +
> > > +void intel_context_bind_parent_child(struct intel_context *parent,
> > > + struct intel_context *child);
> > > +
> > > +#define for_each_child(parent, ce)\
> > > + list_for_each_entry(ce, &(parent)->guc_child_list, guc_child_link)
> > > +#define for_each_child_safe(parent, ce, cn)\
> > > + list_for_each_entry_safe(ce, cn, &(parent)->guc_child_list,
> > > guc_child_link)
> > > +
> > > /**
> > > * intel_context_lock_pinned - Stablises the 'pinned' status of the HW
> > > context
> > > * @ce - the context
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
> > > b/drivers/gpu/drm/i915/gt/intel_context_types.h
> > > index 2df79ba39867..66b22b370a72 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_context_types.h
> > >
Re: [PATCH v8, 0/2] soc: mediatek: mmsys: add mt8192 mmsys support
On 02/08/2021 10:59, Yongqiang Niu wrote: > base v5.14-rc1 > > Yongqiang Niu (2): > soc: mediatek: mmsys: add comp OVL_2L2/POSTMASK/RDMA4 > soc: mediatek: mmsys: Add mt8192 mmsys routing table > Series queued in v5.15-tmp/soc Thanks > drivers/soc/mediatek/mt8192-mmsys.h| 67 > ++ > drivers/soc/mediatek/mtk-mmsys.c | 11 ++ > include/linux/soc/mediatek/mtk-mmsys.h | 3 ++ > 3 files changed, 81 insertions(+) > create mode 100644 drivers/soc/mediatek/mt8192-mmsys.h >
Re: [Intel-gfx] [PATCH 16/46] drm/i915/guc: Implement GuC parent-child context pin / unpin functions
On Mon, Aug 09, 2021 at 06:58:23PM +, Matthew Brost wrote:
> On Mon, Aug 09, 2021 at 05:17:34PM +0200, Daniel Vetter wrote:
> > On Tue, Aug 03, 2021 at 03:29:13PM -0700, Matthew Brost wrote:
> > > Implement GuC parent-child context pin / unpin functions in which in any
> > > contexts in the relationship are pinned all the contexts are pinned. The
> > > parent owns most of the pinning / unpinning process and the children
> > > direct any pins / unpins to the parent.
> > >
> > > Patch implements a number of unused functions that will be connected
> > > later in the series.
> > >
> > > Signed-off-by: Matthew Brost
> > > ---
> > > drivers/gpu/drm/i915/gt/intel_context.c | 187 --
> > > drivers/gpu/drm/i915/gt/intel_context.h | 43 +---
> > > drivers/gpu/drm/i915/gt/intel_context_types.h | 4 +-
> > > .../drm/i915/gt/intel_execlists_submission.c | 25 ++-
> > > drivers/gpu/drm/i915/gt/intel_lrc.c | 26 +--
> > > drivers/gpu/drm/i915/gt/intel_lrc.h | 6 +-
> > > .../gpu/drm/i915/gt/intel_ring_submission.c | 5 +-
> > > drivers/gpu/drm/i915/gt/mock_engine.c | 4 +-
> > > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 183 +++--
> > > 9 files changed, 371 insertions(+), 112 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
> > > b/drivers/gpu/drm/i915/gt/intel_context.c
> > > index 8cb92b10b547..bb4c14656067 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_context.c
> > > +++ b/drivers/gpu/drm/i915/gt/intel_context.c
> > > @@ -158,8 +158,8 @@ static void __ring_retire(struct intel_ring *ring)
> > > intel_ring_unpin(ring);
> > > }
> > >
> > > -static int intel_context_pre_pin(struct intel_context *ce,
> > > - struct i915_gem_ww_ctx *ww)
> > > +static int __intel_context_pre_pin(struct intel_context *ce,
> > > +struct i915_gem_ww_ctx *ww)
> > > {
> > > int err;
> > >
> > > @@ -190,7 +190,7 @@ static int intel_context_pre_pin(struct intel_context
> > > *ce,
> > > return err;
> > > }
> > >
> > > -static void intel_context_post_unpin(struct intel_context *ce)
> > > +static void __intel_context_post_unpin(struct intel_context *ce)
> > > {
> > > if (ce->state)
> > > __context_unpin_state(ce->state);
> > > @@ -199,13 +199,85 @@ static void intel_context_post_unpin(struct
> > > intel_context *ce)
> > > __ring_retire(ce->ring);
> > > }
> > >
> > > -int __intel_context_do_pin_ww(struct intel_context *ce,
> > > - struct i915_gem_ww_ctx *ww)
> > > +static int intel_context_pre_pin(struct intel_context *ce,
> > > + struct i915_gem_ww_ctx *ww)
> > > {
> > > - bool handoff = false;
> > > - void *vaddr;
> > > + struct intel_context *child;
> > > + int err, i = 0;
> > > +
> > > + GEM_BUG_ON(intel_context_is_child(ce));
> > > +
> > > + for_each_child(ce, child) {
> > > + err = __intel_context_pre_pin(child, ww);
> > > + if (unlikely(err))
> > > + goto unwind;
> > > + ++i;
> > > + }
> > > +
> > > + err = __intel_context_pre_pin(ce, ww);
> > > + if (unlikely(err))
> > > + goto unwind;
> > > +
> > > + return 0;
> > > +
> > > +unwind:
> > > + for_each_child(ce, child) {
> > > + if (!i--)
> > > + break;
> > > + __intel_context_post_unpin(ce);
> > > + }
> > > +
> > > + return err;
> > > +}
> > > +
> > > +static void intel_context_post_unpin(struct intel_context *ce)
> > > +{
> > > + struct intel_context *child;
> > > +
> > > + GEM_BUG_ON(intel_context_is_child(ce));
> > > +
> > > + for_each_child(ce, child)
> > > + __intel_context_post_unpin(child);
> > > +
> > > + __intel_context_post_unpin(ce);
> > > +}
> > > +
> > > +static int __do_ww_lock(struct intel_context *ce,
> > > + struct i915_gem_ww_ctx *ww)
> > > +{
> > > + int err = i915_gem_object_lock(ce->timeline->hwsp_ggtt->obj, ww);
> > > +
> > > + if (!err && ce->ring->vma->obj)
> > > + err = i915_gem_object_lock(ce->ring->vma->obj, ww);
> > > + if (!err && ce->state)
> > > + err = i915_gem_object_lock(ce->state->obj, ww);
> > > +
> > > + return err;
> > > +}
> > > +
> > > +static int do_ww_lock(struct intel_context *ce,
> > > + struct i915_gem_ww_ctx *ww)
> > > +{
> > > + struct intel_context *child;
> > > int err = 0;
> > >
> > > + GEM_BUG_ON(intel_context_is_child(ce));
> > > +
> > > + for_each_child(ce, child) {
> > > + err = __do_ww_lock(child, ww);
> > > + if (unlikely(err))
> > > + return err;
> > > + }
> > > +
> > > + return __do_ww_lock(ce, ww);
> > > +}
> > > +
> > > +static int __intel_context_do_pin_ww(struct intel_context *ce,
> > > + struct i915_gem_ww_ctx *ww)
> > > +{
> > > + bool handoff = false;
> > > + int err;
> > > +
> > > if (unlikely(!test_bit(CONTEXT_ALLOC_BIT, &ce->flags))) {
> > > err = intel_context
Re: Aw: [PATCH v8, 2/2] soc: mediatek: mmsys: Add mt8192 mmsys routing table
On 04/08/2021 09:30, Frank Wunderlich wrote: > Hi > > can you please test if your device still work after applying this > > https://patchwork.kernel.org/project/linux-mediatek/patch/20210729070549.5514-1-li...@fw-web.de/ > > and > > duplicate value constants in your routes? > > e.g. changing > > + DDP_COMPONENT_OVL_2L0, DDP_COMPONENT_RDMA0, > + MT8192_DISP_OVL0_2L_MOUT_EN, MT8192_OVL0_MOUT_EN_DISP_RDMA0, > > to > > + DDP_COMPONENT_OVL_2L0, DDP_COMPONENT_RDMA0, > + MT8192_DISP_OVL0_2L_MOUT_EN, MT8192_OVL0_MOUT_EN_DISP_RDMA0, > + MT8192_OVL0_MOUT_EN_DISP_RDMA0 > > regards Frank > I did a fixup for that in v5.15-tmp/soc Yongqiang, please test if this is working on the SoC. Regards, Matthias
Re: [Intel-gfx] [PATCH 16/46] drm/i915/guc: Implement GuC parent-child context pin / unpin functions
On Tue, Aug 10, 2021 at 10:53:37AM +0200, Daniel Vetter wrote:
> On Mon, Aug 09, 2021 at 06:58:23PM +, Matthew Brost wrote:
> > On Mon, Aug 09, 2021 at 05:17:34PM +0200, Daniel Vetter wrote:
> > > On Tue, Aug 03, 2021 at 03:29:13PM -0700, Matthew Brost wrote:
> > > > Implement GuC parent-child context pin / unpin functions in which in any
> > > > contexts in the relationship are pinned all the contexts are pinned. The
> > > > parent owns most of the pinning / unpinning process and the children
> > > > direct any pins / unpins to the parent.
> > > >
> > > > Patch implements a number of unused functions that will be connected
> > > > later in the series.
> > > >
> > > > Signed-off-by: Matthew Brost
> > > > ---
> > > > drivers/gpu/drm/i915/gt/intel_context.c | 187 --
> > > > drivers/gpu/drm/i915/gt/intel_context.h | 43 +---
> > > > drivers/gpu/drm/i915/gt/intel_context_types.h | 4 +-
> > > > .../drm/i915/gt/intel_execlists_submission.c | 25 ++-
> > > > drivers/gpu/drm/i915/gt/intel_lrc.c | 26 +--
> > > > drivers/gpu/drm/i915/gt/intel_lrc.h | 6 +-
> > > > .../gpu/drm/i915/gt/intel_ring_submission.c | 5 +-
> > > > drivers/gpu/drm/i915/gt/mock_engine.c | 4 +-
> > > > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 183 +++--
> > > > 9 files changed, 371 insertions(+), 112 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
> > > > b/drivers/gpu/drm/i915/gt/intel_context.c
> > > > index 8cb92b10b547..bb4c14656067 100644
> > > > --- a/drivers/gpu/drm/i915/gt/intel_context.c
> > > > +++ b/drivers/gpu/drm/i915/gt/intel_context.c
> > > > @@ -158,8 +158,8 @@ static void __ring_retire(struct intel_ring *ring)
> > > > intel_ring_unpin(ring);
> > > > }
> > > >
> > > > -static int intel_context_pre_pin(struct intel_context *ce,
> > > > -struct i915_gem_ww_ctx *ww)
> > > > +static int __intel_context_pre_pin(struct intel_context *ce,
> > > > + struct i915_gem_ww_ctx *ww)
> > > > {
> > > > int err;
> > > >
> > > > @@ -190,7 +190,7 @@ static int intel_context_pre_pin(struct
> > > > intel_context *ce,
> > > > return err;
> > > > }
> > > >
> > > > -static void intel_context_post_unpin(struct intel_context *ce)
> > > > +static void __intel_context_post_unpin(struct intel_context *ce)
> > > > {
> > > > if (ce->state)
> > > > __context_unpin_state(ce->state);
> > > > @@ -199,13 +199,85 @@ static void intel_context_post_unpin(struct
> > > > intel_context *ce)
> > > > __ring_retire(ce->ring);
> > > > }
> > > >
> > > > -int __intel_context_do_pin_ww(struct intel_context *ce,
> > > > - struct i915_gem_ww_ctx *ww)
> > > > +static int intel_context_pre_pin(struct intel_context *ce,
> > > > +struct i915_gem_ww_ctx *ww)
> > > > {
> > > > - bool handoff = false;
> > > > - void *vaddr;
> > > > + struct intel_context *child;
> > > > + int err, i = 0;
> > > > +
> > > > + GEM_BUG_ON(intel_context_is_child(ce));
> > > > +
> > > > + for_each_child(ce, child) {
> > > > + err = __intel_context_pre_pin(child, ww);
> > > > + if (unlikely(err))
> > > > + goto unwind;
> > > > + ++i;
> > > > + }
> > > > +
> > > > + err = __intel_context_pre_pin(ce, ww);
> > > > + if (unlikely(err))
> > > > + goto unwind;
> > > > +
> > > > + return 0;
> > > > +
> > > > +unwind:
> > > > + for_each_child(ce, child) {
> > > > + if (!i--)
> > > > + break;
> > > > + __intel_context_post_unpin(ce);
> > > > + }
> > > > +
> > > > + return err;
> > > > +}
> > > > +
> > > > +static void intel_context_post_unpin(struct intel_context *ce)
> > > > +{
> > > > + struct intel_context *child;
> > > > +
> > > > + GEM_BUG_ON(intel_context_is_child(ce));
> > > > +
> > > > + for_each_child(ce, child)
> > > > + __intel_context_post_unpin(child);
> > > > +
> > > > + __intel_context_post_unpin(ce);
> > > > +}
> > > > +
> > > > +static int __do_ww_lock(struct intel_context *ce,
> > > > + struct i915_gem_ww_ctx *ww)
> > > > +{
> > > > + int err = i915_gem_object_lock(ce->timeline->hwsp_ggtt->obj,
> > > > ww);
> > > > +
> > > > + if (!err && ce->ring->vma->obj)
> > > > + err = i915_gem_object_lock(ce->ring->vma->obj, ww);
> > > > + if (!err && ce->state)
> > > > + err = i915_gem_object_lock(ce->state->obj, ww);
> > > > +
> > > > + return err;
> > > > +}
> > > > +
> > > > +static int do_ww_lock(struct intel_context *ce,
> > > > + struct i915_gem_ww_ctx *ww)
> > > > +{
> > > > + struct intel_context *child;
> > > > int err = 0;
>
Re: [PATCH 19/46] drm/i915/guc: Assign contexts in parent-child relationship consecutive guc_ids
On Mon, Aug 09, 2021 at 07:03:12PM +, Matthew Brost wrote:
> On Mon, Aug 09, 2021 at 05:31:38PM +0200, Daniel Vetter wrote:
> > On Tue, Aug 03, 2021 at 03:29:16PM -0700, Matthew Brost wrote:
> > > Assign contexts in parent-child relationship consecutive guc_ids. This
> > > is accomplished by partitioning guc_id space between ones that need to
> > > be consecutive (1/16 available guc_ids) and ones that do not (15/16 of
> > > available guc_ids). The consecutive search is implemented via the bitmap
> > > API.
> > >
> > > This is a precursor to the full GuC multi-lrc implementation but aligns
> > > to how GuC mutli-lrc interface is defined - guc_ids must be consecutive
> > > when using the GuC multi-lrc interface.
> > >
> > > Signed-off-by: Matthew Brost
> > > ---
> > > drivers/gpu/drm/i915/gt/intel_context.h | 6 +
> > > drivers/gpu/drm/i915/gt/intel_reset.c | 3 +-
> > > drivers/gpu/drm/i915/gt/uc/intel_guc.h| 7 +-
> > > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 222 --
> > > .../i915/gt/uc/intel_guc_submission_types.h | 10 +
> > > 5 files changed, 179 insertions(+), 69 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
> > > b/drivers/gpu/drm/i915/gt/intel_context.h
> > > index c208691fc87d..7ce3b3d2edb7 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_context.h
> > > +++ b/drivers/gpu/drm/i915/gt/intel_context.h
> > > @@ -54,6 +54,12 @@ static inline bool intel_context_is_parent(struct
> > > intel_context *ce)
> > > return !!ce->guc_number_children;
> > > }
> > >
> > > +static inline struct intel_context *
> > > +intel_context_to_parent(struct intel_context *ce)
> > > +{
> > > + return intel_context_is_child(ce) ? ce->parent : ce;
> > > +}
> > > +
> > > void intel_context_bind_parent_child(struct intel_context *parent,
> > >struct intel_context *child);
> > >
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c
> > > b/drivers/gpu/drm/i915/gt/intel_reset.c
> > > index ea763138197f..c3d4baa1b2b8 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_reset.c
> > > +++ b/drivers/gpu/drm/i915/gt/intel_reset.c
> > > @@ -849,6 +849,7 @@ static void reset_finish(struct intel_gt *gt,
> > > intel_engine_mask_t awake)
> > >
> > > static void nop_submit_request(struct i915_request *request)
> > > {
> > > + struct intel_context *ce = intel_context_to_parent(request->context);
> > > RQ_TRACE(request, "-EIO\n");
> > >
> > > /*
> > > @@ -857,7 +858,7 @@ static void nop_submit_request(struct i915_request
> > > *request)
> > >* this for now.
> > >*/
> > > if (intel_engine_uses_guc(request->engine))
> > > - intel_guc_decr_num_rq_not_ready(request->context);
> > > + intel_guc_decr_num_rq_not_ready(ce);
> > >
> > > request = i915_request_mark_eio(request);
> > > if (request) {
> > > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > > b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > > index c0c60ccabfa4..30a0f364db8f 100644
> > > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > > @@ -24,6 +24,7 @@ struct __guc_ads_blob;
> > >
> > > enum {
> > > GUC_SUBMIT_ENGINE_SINGLE_LRC,
> > > + GUC_SUBMIT_ENGINE_MULTI_LRC,
> > > GUC_SUBMIT_ENGINE_MAX
> > > };
> > >
> > > @@ -59,8 +60,10 @@ struct intel_guc {
> > > struct ida guc_ids;
> > > u32 num_guc_ids;
> > > u32 max_guc_ids;
> > > - struct list_head guc_id_list_no_ref;
> > > - struct list_head guc_id_list_unpinned;
> > > + unsigned long *guc_ids_bitmap;
> > > +#define MAX_GUC_ID_ORDER (order_base_2(MAX_ENGINE_INSTANCE + 1))
> > > + struct list_head guc_id_list_no_ref[MAX_GUC_ID_ORDER + 1];
> > > + struct list_head guc_id_list_unpinned[MAX_GUC_ID_ORDER + 1];
> >
> > Random new global lists definitely need kerneldoc about what is on them,
> > how they're linked, what their lifetime rules are and what locks we're
> > holding.
> >
> > Leaving this all to reviews to figure out, and worse, future readers of
> > your code, is not kind.
> >
>
> Got it.
I forgot the usual disclaimer: I know that the current code isn't
following this at all. But wee have to start somewhere :-/
> > > spinlock_t destroy_lock;/* protects list / worker */
> > > struct list_head destroyed_contexts;
> > > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > index f23dd716723f..afb9b4bb8971 100644
> > > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > @@ -169,6 +169,15 @@ static void clr_guc_ids_exhausted(struct
> > > guc_submit_engine *gse)
> > > clear_bit(GSE_STATE_GUC_IDS_EXHAUSTED, &gse->flags);
> > > }
> > >
> > > +/*
> > > + * We reserve 1/16 of the guc_ids for multi-lrc as these need to be
> > > contiguous
> >
> > I think it'd be good to put down the reason here for why. Is this a
> > requirement of
Re: [Freedreno] [PATCH 0/3] iommu/drm/msm: Allow non-coherent masters to use system cache
On Mon, Aug 09, 2021 at 11:17:40PM +0530, Sai Prakash Ranjan wrote: > On 2021-08-09 23:10, Will Deacon wrote: > > On Mon, Aug 09, 2021 at 10:18:21AM -0700, Rob Clark wrote: > > > On Mon, Aug 9, 2021 at 10:05 AM Will Deacon wrote: > > > > On Mon, Aug 09, 2021 at 09:57:08AM -0700, Rob Clark wrote: > > > > > But I suppose we could call it instead IOMMU_QCOM_LLC or something > > > > > like that to make it more clear that it is not necessarily something > > > > > that would work with a different outer level cache implementation? > > > > > > > > ... or we could just deal with the problem so that other people can > > > > reuse > > > > the code. I haven't really understood the reluctance to solve this > > > > properly. > > > > > > > > Am I missing some reason this isn't solvable? > > > > > > Oh, was there another way to solve it (other than foregoing setting > > > INC_OCACHE in the pgtables)? Maybe I misunderstood, is there a > > > corresponding setting on the MMU pgtables side of things? > > > > Right -- we just need to program the CPU's MMU with the matching memory > > attributes! It's a bit more fiddly if you're just using ioremap_wc() > > though, as it's usually the DMA API which handles the attributes under > > the > > hood. > > > > Anyway, sorry, I should've said that explicitly earlier on. We've done > > this > > sort of thing in the Android tree so I assumed Sai knew what needed to > > be > > done and then I didn't think to explain to you :( > > > > Right I was aware of that but even in the android tree there is no user :) I'm assuming there are vendor modules using it there, otherwise we wouldn't have been asked to put it in. Since you work at Qualcomm, maybe you could talk to your colleagues (Isaac and Patrick) directly? > I think we can't have a new memory type without any user right in upstream > like android tree? Correct. But I don't think we should be adding IOMMU_* anything upstream if we don't have a user. Will
Re: [PATCH 20/46] drm/i915/guc: Add hang check to GuC submit engine
On Mon, Aug 09, 2021 at 07:05:58PM +, Matthew Brost wrote:
> On Mon, Aug 09, 2021 at 05:35:25PM +0200, Daniel Vetter wrote:
> > On Tue, Aug 03, 2021 at 03:29:17PM -0700, Matthew Brost wrote:
> > > The heartbeat uses a single instance of a GuC submit engine (GSE) to do
> > > the hang check. As such if a different GSE's state machine hangs, the
> > > heartbeat cannot detect this hang. Add timer to each GSE which in turn
> > > can disable all submissions if it is hung.
> > >
> > > Cc: John Harrison
> > > Signed-off-by: Matthew Brost
> > > ---
> > > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 36 +++
> > > .../i915/gt/uc/intel_guc_submission_types.h | 3 ++
> > > 2 files changed, 39 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > index afb9b4bb8971..2d8296bcc583 100644
> > > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > @@ -105,15 +105,21 @@ static bool tasklet_blocked(struct
> > > guc_submit_engine *gse)
> > > return test_bit(GSE_STATE_TASKLET_BLOCKED, &gse->flags);
> > > }
> > >
> > > +/* 2 seconds seems like a reasonable timeout waiting for a G2H */
> > > +#define MAX_TASKLET_BLOCKED_NS 20
> > > static void set_tasklet_blocked(struct guc_submit_engine *gse)
> > > {
> > > lockdep_assert_held(&gse->sched_engine.lock);
> > > + hrtimer_start_range_ns(&gse->hang_timer,
> > > +ns_to_ktime(MAX_TASKLET_BLOCKED_NS), 0,
> > > +HRTIMER_MODE_REL_PINNED);
> > > set_bit(GSE_STATE_TASKLET_BLOCKED, &gse->flags);
> >
> > So with drm/scheduler the reset handling is assumed to be
> > single-threaded, and there's quite complex rules around that. I've
> > recently worked with Boris Brezillion to clarify all this a bit and
> > improve docs. Does this all still work in that glorious future? Might be
> > good to at least sprinkle some comments/thoughts around in the commit
> > message about the envisaged future direction for all this stuff, to keep
> > people in the loop. Especially future people.
> >
> > Ofc plan is still to just largely land all this.
> >
> > Also: set_bit is an unordered atomic, which means you need barriers, which
> > meanes ... *insert the full rant about justifying/documenting lockless
> > algorithms from earlier *
> >
>
> lockdep_assert_held(&gse->sched_engine.lock);
>
> Not lockless. Also spin locks act as barriers, right?
Well if that spinlock is protecting that bit then that's good, but then it
shouldn't be an atomic set_bit. In that case:
- either make the entire bitfield non-atomic so it's clear there's boring
dumb locking going on
- or split out your new bit into a separate field so that there's no false
sharing with the existing bitfield state machinery, and add a kernel doc
to that field explaining the locking
set_bit itself is atomic and unordered, so means you need barriers and all
that. If you don't have a lockless algorithm, don't use atomic bitops to
avoid confusing readers because set_bit/test_bit sets of all the warning
bells.
And yes it's annoying that for bitops the atomic ones don't have an
atomic_ prefix. The non-atomic ones have a __ prefix. This is honestly why
I don't think we should use bitfields as much as we do, because the main
use-case for them is when you have bitfields which are longer than 64bits.
They come from the cpumask world, and linux supports a lot of cpus.
Open-coding non-atomic simple bitfields with the usual C operators is
perfectly fine and legible imo. But that part is maybe more a bikeshed.
> > But I think this all falls out with the removal of the guc-id allocation
> > scheme?
>
> Yes, this patch is getting deleted.
That works too :-)
-Daniel
>
> Matt
>
> > -Daniel
> >
> > > }
> > >
> > > static void __clr_tasklet_blocked(struct guc_submit_engine *gse)
> > > {
> > > lockdep_assert_held(&gse->sched_engine.lock);
> > > + hrtimer_cancel(&gse->hang_timer);
> > > clear_bit(GSE_STATE_TASKLET_BLOCKED, &gse->flags);
> > > }
> > >
> > > @@ -1028,6 +1034,7 @@ static void disable_submission(struct intel_guc
> > > *guc)
> > > if (__tasklet_is_enabled(&sched_engine->tasklet)) {
> > > GEM_BUG_ON(!guc->ct.enabled);
> > > __tasklet_disable_sync_once(&sched_engine->tasklet);
> > > + hrtimer_try_to_cancel(&guc->gse[i]->hang_timer);
> > > sched_engine->tasklet.callback = NULL;
> > > }
> > > }
> > > @@ -3750,6 +3757,33 @@ static void guc_sched_engine_destroy(struct kref
> > > *kref)
> > > kfree(gse);
> > > }
> > >
> > > +static enum hrtimer_restart gse_hang(struct hrtimer *hrtimer)
> > > +{
> > > + struct guc_submit_engine *gse =
> > > + container_of(hrtimer, struct guc_submit_engine, hang_timer);
> > > + struct intel_guc *guc = gse->sched_engine.private_data;
> >
[PATCH] drm/display: fix possible null-pointer dereference in dcn10_set_clock()
The variable dc->clk_mgr is checked in: if (dc->clk_mgr && dc->clk_mgr->funcs->get_clock) This indicates dc->clk_mgr can be NULL. However, it is dereferenced in: if (!dc->clk_mgr->funcs->get_clock) To fix this possible null-pointer dereference, check dc->clk_mgr before dereferencing it. Reported-by: TOTE Robot Signed-off-by: Tuo Li --- drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c index c545eddabdcc..3a7c7c7efa68 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c +++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c @@ -3635,7 +3635,7 @@ enum dc_status dcn10_set_clock(struct dc *dc, dc->clk_mgr->funcs->get_clock(dc->clk_mgr, context, clock_type, &clock_cfg); - if (!dc->clk_mgr->funcs->get_clock) + if (dc->clk_mgr && !dc->clk_mgr->funcs->get_clock) return DC_FAIL_UNSUPPORTED_1; if (clk_khz > clock_cfg.max_clock_khz) -- 2.25.1
Re: [PATCH 25/46] drm/i915/guc: Update debugfs for GuC multi-lrc
On Mon, Aug 09, 2021 at 07:13:11PM +, Matthew Brost wrote:
> On Mon, Aug 09, 2021 at 06:36:44PM +0200, Daniel Vetter wrote:
> > On Tue, Aug 03, 2021 at 03:29:22PM -0700, Matthew Brost wrote:
> > > Display the workqueue status in debugfs for GuC contexts that are in
> > > parent-child relationship.
> > >
> > > Signed-off-by: Matthew Brost
> > > ---
> > > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 56 +--
> > > 1 file changed, 39 insertions(+), 17 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > index 30df1c8db491..44a7582c9aed 100644
> > > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > @@ -4527,31 +4527,53 @@ void intel_guc_submission_print_info(struct
> > > intel_guc *guc,
> > > gse_log_submission_info(guc->gse[i], p, i);
> > > }
> > >
> > > +static inline void guc_log_context(struct drm_printer *p,
> > > +struct intel_context *ce)
> > > +{
> > > + drm_printf(p, "GuC lrc descriptor %u:\n", ce->guc_id);
> > > + drm_printf(p, "\tHW Context Desc: 0x%08x\n", ce->lrc.lrca);
> > > + drm_printf(p, "\t\tLRC Head: Internal %u, Memory %u\n",
> > > +ce->ring->head,
> > > +ce->lrc_reg_state[CTX_RING_HEAD]);
> > > + drm_printf(p, "\t\tLRC Tail: Internal %u, Memory %u\n",
> > > +ce->ring->tail,
> > > +ce->lrc_reg_state[CTX_RING_TAIL]);
> > > + drm_printf(p, "\t\tContext Pin Count: %u\n",
> > > +atomic_read(&ce->pin_count));
> > > + drm_printf(p, "\t\tGuC ID Ref Count: %u\n",
> > > +atomic_read(&ce->guc_id_ref));
> > > + drm_printf(p, "\t\tNumber Requests Not Ready: %u\n",
> > > +atomic_read(&ce->guc_num_rq_not_ready));
> > > + drm_printf(p, "\t\tSchedule State: 0x%x, 0x%x\n\n",
> > > +ce->guc_state.sched_state,
> > > +atomic_read(&ce->guc_sched_state_no_lock));
> >
> > It's all debugfs, but I think proper locking even there is good. It at
> > least reduces the confusion when the locking scheme is largely
> > undocumented. Also given how much we have rcu for everything would be good
> > to double-check all pointer dererences are properly protected.
> >
>
> Not sure if I 100% follow this but I don't think any of the pointers
> dref here are RCU protected. Certainly none of the GuC ones are.
>
> Will double before the next respin though.
>
> > > +}
> > > +
> > > void intel_guc_submission_print_context_info(struct intel_guc *guc,
> > >struct drm_printer *p)
> > > {
> > > struct intel_context *ce;
> > > unsigned long index;
> > > xa_for_each(&guc->context_lookup, index, ce) {
> >
> > xa_for_each doesn't provide any guarantees, so doesn't protect against
> > concurrent removeal or anything like that. We need to do better than that.
>
> https://elixir.bootlin.com/linux/latest/source/include/linux/xarray.h#L498
> 'It is safe to modify the array during the iteration.'
The xarray. Not the thing you're dereferencing, because the xarray only
stores pointers, not your data structure. So yeah correct statement is
that it doesn't provide you any guarantees beyond "the iterator wont be
confused if the xarray itself is modified during iteration". Which isn't
what you need here, you need a lot more.
-Daniel
>
> Matt
>
> > -Daniel
> >
> > > - drm_printf(p, "GuC lrc descriptor %u:\n", ce->guc_id);
> > > - drm_printf(p, "\tHW Context Desc: 0x%08x\n", ce->lrc.lrca);
> > > - drm_printf(p, "\t\tLRC Head: Internal %u, Memory %u\n",
> > > -ce->ring->head,
> > > -ce->lrc_reg_state[CTX_RING_HEAD]);
> > > - drm_printf(p, "\t\tLRC Tail: Internal %u, Memory %u\n",
> > > -ce->ring->tail,
> > > -ce->lrc_reg_state[CTX_RING_TAIL]);
> > > - drm_printf(p, "\t\tContext Pin Count: %u\n",
> > > -atomic_read(&ce->pin_count));
> > > - drm_printf(p, "\t\tGuC ID Ref Count: %u\n",
> > > -atomic_read(&ce->guc_id_ref));
> > > - drm_printf(p, "\t\tNumber Requests Not Ready: %u\n",
> > > -atomic_read(&ce->guc_num_rq_not_ready));
> > > - drm_printf(p, "\t\tSchedule State: 0x%x, 0x%x\n\n",
> > > -ce->guc_state.sched_state,
> > > -atomic_read(&ce->guc_sched_state_no_lock));
> > > + GEM_BUG_ON(intel_context_is_child(ce));
> > >
> > > + guc_log_context(p, ce);
> > > guc_log_context_priority(p, ce);
> > > +
> > > + if (intel_context_is_parent(ce)) {
> > > + struct guc_process_desc *desc = __get_process_desc(ce);
> > > + struct intel_context *child;
> > > +
> > > + drm_printf(p, "\t\tWQI Head: %u\n",
> > > +READ_ON
Re: linux-next: build warnings after merge of the drm tree
Hi all,
On Thu, 8 Jul 2021 12:20:48 +1000 Stephen Rothwell
wrote:
>
> On Thu, 3 Jun 2021 19:32:42 +1000 Stephen Rothwell
> wrote:
> >
> > After merging the drm tree, today's linux-next build (htmldocs) produced
> > these warnings:
> >
> > Documentation/gpu/driver-uapi.rst:2412: WARNING: Duplicate C declaration,
> > also defined at gpu/rfc/i915_gem_lmem:1393.
> > Declaration is '.. c:enum:: drm_i915_gem_memory_class'.
> > Documentation/gpu/driver-uapi.rst:2484: WARNING: Duplicate C declaration,
> > also defined at gpu/rfc/i915_gem_lmem:2484.
> > Declaration is '.. c:struct:: drm_i915_gem_memory_class_instance'.
> > Documentation/gpu/driver-uapi.rst:7: WARNING: Duplicate C declaration, also
> > defined at gpu/rfc/i915_gem_lmem:7.
> > Declaration is '.. c:struct:: drm_i915_memory_region_info'.
> > Documentation/gpu/driver-uapi.rst:2531: WARNING: Duplicate C declaration,
> > also defined at gpu/rfc/i915_gem_lmem:2531.
> > Declaration is '.. c:struct:: drm_i915_query_memory_regions'.
> > Documentation/gpu/driver-uapi.rst:2595: WARNING: Duplicate C declaration,
> > also defined at gpu/rfc/i915_gem_lmem:1393.
> > Declaration is '.. c:struct:: drm_i915_gem_create_ext'.
> > Documentation/gpu/driver-uapi.rst:2615: WARNING: Duplicate C declaration,
> > also defined at gpu/rfc/i915_gem_lmem:1393.
> > Declaration is '.. c:struct:: drm_i915_gem_create_ext_memory_regions'.
> >
> > Introduced by (one or more of) commits
> >
> > 0c1a77cbdafb ("drm/doc: add section for driver uAPI")
> > 2bc9c04ea702 ("drm/doc/rfc: i915 DG1 uAPI")
> > 727ecd99a4c9 ("drm/doc/rfc: drop the i915_gem_lmem.h header")
>
> I am still getting these warning.
Still getting them ...
--
Cheers,
Stephen Rothwell
pgpmMfLIHj6f7.pgp
Description: OpenPGP digital signature
Re: [PATCH 25/46] drm/i915/guc: Update debugfs for GuC multi-lrc
On Tue, Aug 10, 2021 at 11:23:39AM +0200, Daniel Vetter wrote:
> On Mon, Aug 09, 2021 at 07:13:11PM +, Matthew Brost wrote:
> > On Mon, Aug 09, 2021 at 06:36:44PM +0200, Daniel Vetter wrote:
> > > On Tue, Aug 03, 2021 at 03:29:22PM -0700, Matthew Brost wrote:
> > > > Display the workqueue status in debugfs for GuC contexts that are in
> > > > parent-child relationship.
> > > >
> > > > Signed-off-by: Matthew Brost
> > > > ---
> > > > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 56 +--
> > > > 1 file changed, 39 insertions(+), 17 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > > b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > > index 30df1c8db491..44a7582c9aed 100644
> > > > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > > @@ -4527,31 +4527,53 @@ void intel_guc_submission_print_info(struct
> > > > intel_guc *guc,
> > > > gse_log_submission_info(guc->gse[i], p, i);
> > > > }
> > > >
> > > > +static inline void guc_log_context(struct drm_printer *p,
> > > > + struct intel_context *ce)
> > > > +{
> > > > + drm_printf(p, "GuC lrc descriptor %u:\n", ce->guc_id);
> > > > + drm_printf(p, "\tHW Context Desc: 0x%08x\n", ce->lrc.lrca);
> > > > + drm_printf(p, "\t\tLRC Head: Internal %u, Memory %u\n",
> > > > + ce->ring->head,
> > > > + ce->lrc_reg_state[CTX_RING_HEAD]);
> > > > + drm_printf(p, "\t\tLRC Tail: Internal %u, Memory %u\n",
> > > > + ce->ring->tail,
> > > > + ce->lrc_reg_state[CTX_RING_TAIL]);
> > > > + drm_printf(p, "\t\tContext Pin Count: %u\n",
> > > > + atomic_read(&ce->pin_count));
> > > > + drm_printf(p, "\t\tGuC ID Ref Count: %u\n",
> > > > + atomic_read(&ce->guc_id_ref));
> > > > + drm_printf(p, "\t\tNumber Requests Not Ready: %u\n",
> > > > + atomic_read(&ce->guc_num_rq_not_ready));
> > > > + drm_printf(p, "\t\tSchedule State: 0x%x, 0x%x\n\n",
> > > > + ce->guc_state.sched_state,
> > > > + atomic_read(&ce->guc_sched_state_no_lock));
> > >
> > > It's all debugfs, but I think proper locking even there is good. It at
> > > least reduces the confusion when the locking scheme is largely
> > > undocumented. Also given how much we have rcu for everything would be good
> > > to double-check all pointer dererences are properly protected.
> > >
> >
> > Not sure if I 100% follow this but I don't think any of the pointers
> > dref here are RCU protected. Certainly none of the GuC ones are.
> >
> > Will double before the next respin though.
> >
> > > > +}
> > > > +
> > > > void intel_guc_submission_print_context_info(struct intel_guc *guc,
> > > > struct drm_printer *p)
> > > > {
> > > > struct intel_context *ce;
> > > > unsigned long index;
> > > > xa_for_each(&guc->context_lookup, index, ce) {
> > >
> > > xa_for_each doesn't provide any guarantees, so doesn't protect against
> > > concurrent removeal or anything like that. We need to do better than that.
> >
> > https://elixir.bootlin.com/linux/latest/source/include/linux/xarray.h#L498
> > 'It is safe to modify the array during the iteration.'
>
> The xarray. Not the thing you're dereferencing, because the xarray only
> stores pointers, not your data structure. So yeah correct statement is
> that it doesn't provide you any guarantees beyond "the iterator wont be
> confused if the xarray itself is modified during iteration". Which isn't
> what you need here, you need a lot more.
Or spelled out: The pointer you get could become immediately meaningless,
before you can look at it, due to a concurrent removal/release. All the
xa_for_each guarantees you is that on the next round you get the next
pointer, until you got them all (plus/minus concurrent changes). But that
next pointer could have become meaningless right away too.
So you need your own locking to make use of these pointers you got and
make sure they're not immediately meaningless before your loop body even
started.
One of the reasons why I think this is so important is that debugfs files
nest a lot of loops fairly often, so are good cheat-sheet for the locking
if it happens to be undocumented (which also shouldn't be the case). Ofc
if there's no locking in debugfs, no cheat-sheet :-)
Cheers, Daniel
> -Daniel
>
> >
> > Matt
> >
> > > -Daniel
> > >
> > > > - drm_printf(p, "GuC lrc descriptor %u:\n", ce->guc_id);
> > > > - drm_printf(p, "\tHW Context Desc: 0x%08x\n",
> > > > ce->lrc.lrca);
> > > > - drm_printf(p, "\t\tLRC Head: Internal %u, Memory %u\n",
> > > > - ce->ring->head,
> > > > - ce->lrc_reg_state[CTX_RING_
[BUG] drm/amdgpu: possible null-pointer dereference in dce_vXX_0_afmt_setmode()
Hello, Our static analysis tool finds some possible null-pointer dereferences in the amdgpu driver in Linux 5.14.0-rc3: In dce_v10_0.c: The variable encoder->crtc is checked in: 1591: if (encoder->crtc) This indicates that encoder->crtc can be NULL. Then the function dce_v10_0_audio_set_dto() is called with the argument encoder: 1600: ce_v10_0_audio_set_dto(encoder, mode->clock); However, encoder->crtc is dereferenced in this function: 1545: struct amdgpu_crtc *amdgpu_crtc = to_amdgpu_crtc(encoder->crtc); 1559: tmp = REG_SET_FIELD(tmp, DCCG_AUDIO_DTO_SOURCE, DCCG_AUDIO_DTO0_SOURCE_SEL, amdgpu_crtc->crtc_id); In dce_v11_0.c and dce_v8_0.c, situations are the same. I am not quite sure whether these possible null-pointer dereferences are real and how to fix them if they are real. Any feedback would be appreciated, thanks! Reported-by: TOTE Robot Best wishes, Tuo Li
Re: [PATCH v2 8/8] [RFC] drm/ingenic: convert to component framework for jz4780 hdmi
On Thu, Aug 05, 2021 at 06:17:32PM +0200, Paul Cercueil wrote: > Hi Nikolaus and Laurent, > > Le jeu., août 5 2021 at 18:07:20 +0200, H. Nikolaus Schaller > a écrit : > > Hi Laurent, > > > > > Am 05.08.2021 um 17:04 schrieb Laurent Pinchart > > > : > > > > > > Hi Nikolaus, > > > > > > Thank you for the patch. > > > > > > On Thu, Aug 05, 2021 at 04:07:57PM +0200, H. Nikolaus Schaller > > > wrote: > > > > This patch attempts to convert the ingenic-dw-hdmi driver > > > > into a version that uses the component framework. > > > > > > Why ? What problem would this solve ? > > > > Well, it was suggested in a v1 we did post several months ago. I have > > not > > looked up by whom and do not exactly remember the reasons. > > > > We now simply thought that it is common style since dome dw-hdmi drivers > > make use of it but some others don't. And we got it working without. > > > > If it is not needed/requested by anyone, we can drop it from v3 (or add > > later). > > I don't remember exactly TBH - the only reason to use a component is to have > access to the main driver's "drm_device" structure. The IPU needs it for > instance, to register planes; but I don't think this HDMI driver needs it as > it registers a bridge. Imo for bridges/panels we really should move _away_ from component, not towards it. If there's a gap in the bridge/panel api (I think there's some patches floating around exactly to make this more a multi-step process for reasons like the above) then we need to fix that. Unfortunately the dw-hdmi and also dw-dsi drivers are very much built on top of component.c and side-step the bridge stuff quite a lot. That results in quite bad integration pains all around as we add more users of these. The other unfortunate thing is that there's not many people working in this area, so fundamental improvements to the core design take a long time to make and then even longer to roll out. It's a bit a tough spot, but also, help very much welcome :-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH 2/2] gpu/drm: ingenic: Add workaround for disabled drivers
On Fri, Aug 06, 2021 at 01:01:33PM +0200, Paul Cercueil wrote:
> Hi Greg,
>
> Le ven., août 6 2021 at 12:17:55 +0200, Greg Kroah-Hartman
> a écrit :
> > On Thu, Aug 05, 2021 at 10:05:27PM +0200, Paul Cercueil wrote:
> > > Hi Greg,
> > >
> > > Le jeu., août 5 2021 at 21:35:34 +0200, Greg Kroah-Hartman
> > > a écrit :
> > > > On Thu, Aug 05, 2021 at 09:21:09PM +0200, Paul Cercueil wrote:
> > > > > When the drivers of remote devices (e.g. HDMI chip) are
> > > disabled in
> > > > > the
> > > > > config, we want the ingenic-drm driver to be able to probe
> > > > > nonetheless
> > > > > with the other devices (e.g. internal LCD panel) that are
> > > enabled.
> > > > >
> > > > > Signed-off-by: Paul Cercueil
> > > > > ---
> > > > > drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 12
> > > > > 1 file changed, 12 insertions(+)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> > > > > b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> > > > > index d261f7a03b18..5e1fdbb0ba6b 100644
> > > > > --- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> > > > > +++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> > > > > @@ -1058,6 +1058,18 @@ static int ingenic_drm_bind(struct
> > > device
> > > > > *dev, bool has_components)
> > > > > for (i = 0; ; i++) {
> > > > > ret = drm_of_find_panel_or_bridge(dev->of_node, 0, i,
> > > &panel,
> > > > > &bridge);
> > > > > if (ret) {
> > > > > + /*
> > > > > +* Workaround for the case where the drivers
> > > for the
> > > > > +* remote devices are not enabled. When that
> > > happens,
> > > > > +* drm_of_find_panel_or_bridge() returns
> > > -EPROBE_DEFER
> > > > > +* endlessly, which prevents the ingenic-drm
> > > driver from
> > > > > +* working at all.
> > > > > +*/
> > > > > + if (ret == -EPROBE_DEFER) {
> > > > > + ret =
> > > driver_deferred_probe_check_state(dev);
> > > > > + if (ret == -ENODEV || ret == -ETIMEDOUT)
> > > > > + continue;
> > > > > + }
> > > >
> > > > So you are mucking around with devices on other busses within this
> > > > driver? What could go wrong? :(
> > >
> > > I'm doing the same thing as everybody else. This is the DRM driver,
> > > and
> > > there is a driver for the external HDMI chip which gives us a DRM
> > > bridge
> > > that we can obtain from the device tree.
> >
> > But then why do you need to call this function that is there for a bus,
> > not for a driver.
>
> The documentation disagrees with you :)
>
> And, if that has any weight, this solution was proposed by Rob.
>
> > > > Please use the existing driver core functionality for this type of
> > > > thing, it is not unique, no need for this function to be called.
> > >
> > > I'm not sure you understand what I'm doing here. This driver calls
> > > drm_of_find_panel_or_bridge(), without guarantee that the driver
> > > for the
> > > remote device (connected via DT graph) has been enabled in the
> > > kernel
> > > config. In that case it will always return -EPROBE_DEFER and the
> > > ingenic-drm
> > > driver will never probe.
> > >
> > > This patch makes sure that the driver can probe if the HDMI driver
> > > has been
> > > disabled in the kernel config, nothing more.
> >
> > That should not be an issue as you do not care if the config is enabled,
> > you just want to do something in the future if the driver shows up,
> > right?
>
> Well, the DRM subsystem doesn't really seem to handle hotplug of hardware.
> Right now all the drivers for the connected hardware need to probe before
> the main DRM driver. So I need to know that a remote device (connected via
> DT graph) will never probe.
>
> Give me a of_graph_remote_device_driver_will_never_probe() and I'll use
> that.
>
> > Much like the device link code, have you looked at that?
>
> I don't see how that would help in any way. The device link code would allow
> me to set a dependency between the remote hardware (HDMI chip, provider) and
> the LCD controller (consumer), but I already have that dependency though the
> DT graph. What I need is a way for the consumer to continue probing if the
> provider is not going to probe.
Is this actually a legit use-case?
Like you have hw with a bunch of sub-devices linked, and you decided to
disable some of them, which makes the driver not load.
Why should we care? Is that hdmi driver really that big that we have to
support this use-case?
I know it's possible to do this, that doesn't mean it's a good idea.
There's inifinitely more randconfigs that don't boot on my machine here
for various reasons than the ones that do boot. We don't have "fixes" for
all of these to make things still work, despite user
Re: [PATCH 2/2] gpu/drm: ingenic: Add workaround for disabled drivers
On Fri, Aug 06, 2021 at 01:01:33PM +0200, Paul Cercueil wrote:
> Hi Greg,
>
> Le ven., août 6 2021 at 12:17:55 +0200, Greg Kroah-Hartman
> a écrit :
> > On Thu, Aug 05, 2021 at 10:05:27PM +0200, Paul Cercueil wrote:
> > > Hi Greg,
> > >
> > > Le jeu., août 5 2021 at 21:35:34 +0200, Greg Kroah-Hartman
> > > a écrit :
> > > > On Thu, Aug 05, 2021 at 09:21:09PM +0200, Paul Cercueil wrote:
> > > > > When the drivers of remote devices (e.g. HDMI chip) are
> > > disabled in
> > > > > the
> > > > > config, we want the ingenic-drm driver to be able to probe
> > > > > nonetheless
> > > > > with the other devices (e.g. internal LCD panel) that are
> > > enabled.
> > > > >
> > > > > Signed-off-by: Paul Cercueil
> > > > > ---
> > > > > drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 12
> > > > > 1 file changed, 12 insertions(+)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> > > > > b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> > > > > index d261f7a03b18..5e1fdbb0ba6b 100644
> > > > > --- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> > > > > +++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> > > > > @@ -1058,6 +1058,18 @@ static int ingenic_drm_bind(struct
> > > device
> > > > > *dev, bool has_components)
> > > > > for (i = 0; ; i++) {
> > > > > ret = drm_of_find_panel_or_bridge(dev->of_node, 0, i,
> > > &panel,
> > > > > &bridge);
> > > > > if (ret) {
> > > > > + /*
> > > > > +* Workaround for the case where the drivers
> > > for the
> > > > > +* remote devices are not enabled. When that
> > > happens,
> > > > > +* drm_of_find_panel_or_bridge() returns
> > > -EPROBE_DEFER
> > > > > +* endlessly, which prevents the ingenic-drm
> > > driver from
> > > > > +* working at all.
> > > > > +*/
> > > > > + if (ret == -EPROBE_DEFER) {
> > > > > + ret =
> > > driver_deferred_probe_check_state(dev);
> > > > > + if (ret == -ENODEV || ret == -ETIMEDOUT)
> > > > > + continue;
> > > > > + }
> > > >
> > > > So you are mucking around with devices on other busses within this
> > > > driver? What could go wrong? :(
> > >
> > > I'm doing the same thing as everybody else. This is the DRM driver,
> > > and
> > > there is a driver for the external HDMI chip which gives us a DRM
> > > bridge
> > > that we can obtain from the device tree.
> >
> > But then why do you need to call this function that is there for a bus,
> > not for a driver.
>
> The documentation disagrees with you :)
>
> And, if that has any weight, this solution was proposed by Rob.
>
> > > > Please use the existing driver core functionality for this type of
> > > > thing, it is not unique, no need for this function to be called.
> > >
> > > I'm not sure you understand what I'm doing here. This driver calls
> > > drm_of_find_panel_or_bridge(), without guarantee that the driver
> > > for the
> > > remote device (connected via DT graph) has been enabled in the
> > > kernel
> > > config. In that case it will always return -EPROBE_DEFER and the
> > > ingenic-drm
> > > driver will never probe.
> > >
> > > This patch makes sure that the driver can probe if the HDMI driver
> > > has been
> > > disabled in the kernel config, nothing more.
> >
> > That should not be an issue as you do not care if the config is enabled,
> > you just want to do something in the future if the driver shows up,
> > right?
>
> Well, the DRM subsystem doesn't really seem to handle hotplug of hardware.
> Right now all the drivers for the connected hardware need to probe before
> the main DRM driver. So I need to know that a remote device (connected via
> DT graph) will never probe.
But you never really know that. That is what the recent driver core
changes were all about, to handle this very issue. Only when the child
device shows up will you need to care about it.
> Give me a of_graph_remote_device_driver_will_never_probe() and I'll use
> that.
>
> > Much like the device link code, have you looked at that?
>
> I don't see how that would help in any way. The device link code would allow
> me to set a dependency between the remote hardware (HDMI chip, provider) and
> the LCD controller (consumer), but I already have that dependency though the
> DT graph. What I need is a way for the consumer to continue probing if the
> provider is not going to probe.
But again, you never know that, probing is async, and could happen in a
few milliseconds, or a few hours, your driver should never care about
this at all.
Just knowing if the kernel configuration is something is not the
solution here, please fix this properly like all other driver
interactions are in the kernel tree.
thanks,
greg k-h
Re: [Freedreno] [PATCH 0/3] iommu/drm/msm: Allow non-coherent masters to use system cache
On 2021-08-10 14:46, Will Deacon wrote: On Mon, Aug 09, 2021 at 11:17:40PM +0530, Sai Prakash Ranjan wrote: On 2021-08-09 23:10, Will Deacon wrote: > On Mon, Aug 09, 2021 at 10:18:21AM -0700, Rob Clark wrote: > > On Mon, Aug 9, 2021 at 10:05 AM Will Deacon wrote: > > > On Mon, Aug 09, 2021 at 09:57:08AM -0700, Rob Clark wrote: > > > > But I suppose we could call it instead IOMMU_QCOM_LLC or something > > > > like that to make it more clear that it is not necessarily something > > > > that would work with a different outer level cache implementation? > > > > > > ... or we could just deal with the problem so that other people can reuse > > > the code. I haven't really understood the reluctance to solve this properly. > > > > > > Am I missing some reason this isn't solvable? > > > > Oh, was there another way to solve it (other than foregoing setting > > INC_OCACHE in the pgtables)? Maybe I misunderstood, is there a > > corresponding setting on the MMU pgtables side of things? > > Right -- we just need to program the CPU's MMU with the matching memory > attributes! It's a bit more fiddly if you're just using ioremap_wc() > though, as it's usually the DMA API which handles the attributes under > the > hood. > > Anyway, sorry, I should've said that explicitly earlier on. We've done > this > sort of thing in the Android tree so I assumed Sai knew what needed to > be > done and then I didn't think to explain to you :( > Right I was aware of that but even in the android tree there is no user :) I'm assuming there are vendor modules using it there, otherwise we wouldn't have been asked to put it in. Since you work at Qualcomm, maybe you could talk to your colleagues (Isaac and Patrick) directly? Right I will check with them regarding the vendor modules in android. I think we can't have a new memory type without any user right in upstream like android tree? Correct. But I don't think we should be adding IOMMU_* anything upstream if we don't have a user. Agreed, once we have the fix for GPU crash I can continue further on using this properly. Thanks, Sai -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH v2] drm/drv: Remove initialization of static variables
On Fri, Aug 06, 2021 at 10:30:47AM +0800, zhaoxiao wrote:
> Address the following checkpatch errors:
> ERROR: do not initialise statics to false
>
> FILE: :drivers/gpu/drm/msm/msm_drv.c:21:
> -static bool reglog = false;
>
> FILE: :drivers/gpu/drm/msm/msm_drv.c:31:
> -bool dumpstate = false;
>
> Signed-off-by: zhaoxiao
Subject should start out with drm/msm, not drm/drv - that would indicate a
patch touching the drm_drv.c core files, or things related to that.
-Daniel
> ---
> v2: change the patch description
> drivers/gpu/drm/msm/msm_drv.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> index 9b8fa2ad0d84..d9ca4bc9620b 100644
> --- a/drivers/gpu/drm/msm/msm_drv.c
> +++ b/drivers/gpu/drm/msm/msm_drv.c
> @@ -59,7 +59,7 @@ static const struct drm_mode_config_helper_funcs
> mode_config_helper_funcs = {
> };
>
> #ifdef CONFIG_DRM_MSM_REGISTER_LOGGING
> -static bool reglog = false;
> +static bool reglog;
> MODULE_PARM_DESC(reglog, "Enable register read/write logging");
> module_param(reglog, bool, 0600);
> #else
> @@ -76,7 +76,7 @@ static char *vram = "16m";
> MODULE_PARM_DESC(vram, "Configure VRAM size (for devices without
> IOMMU/GPUMMU)");
> module_param(vram, charp, 0);
>
> -bool dumpstate = false;
> +bool dumpstate;
> MODULE_PARM_DESC(dumpstate, "Dump KMS state on errors");
> module_param(dumpstate, bool, 0600);
>
> --
> 2.20.1
>
>
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: Proposal for allowing more Nouveau contributors to merge patches
On Fri, Aug 06, 2021 at 06:53:06PM +0200, Karol Herbst wrote: > Hey everybody, > > so, here is a proposal of what we could change in order to allow > patches to land faster, more reliably and to increase the overall bus > factor in terms of nouveau kernel maintenance. Yay! > But let's start with the current situation: > > At the moment contributors have to send patches to the nouveau mailing > list in order to submit them for inclusion into Bens nouveau tree. > Then Ben has to look at them and either respond with a comment on what > needs to change or merge it. At some point Ben submits all new changes > to nouveau for inclusion into the drm-next tree. > > Practically there are a few problems here: > 1. Not all patch submissions get a response > 2. Patch submitters usually don't get to know if their patches are > accepted unless they appear in drm-next or linus' tree. > 3. A lot of trivial patches never make it into the tree. > 4. Depending on how overloaded Ben is, even bigger patch series adding > new features never get any responses at all. > 5. Patch series might get stale for any other reason and there is no > good tool to track open patch submissions (no, patchwork isn't good > and it sucks and not even in the mood to explain this to people > thinking otherwise as this should just be obvious) > > This usually ends up discouraging new contributors from making more > contributions to nouveau as they see that some or all of their patches > never get any reaction and it's even annoying to current contributors > if they see their patches being stuck as well. > > And here I want to stress that none of this is Ben's fault and has his > own things to work on and none of this should just depend on one > person finding enough time. So the solution shouldn't be a simple > "let's find a different tool and everything should be perfect" but the > solution should be "how can we change the process so it's less time > consuming for Ben to accept patches". And while working on this, I'd > also want to tackle the problem that contributing to nouveau shouldn't > be frustrating for new contributors and the process should be more > lively overall. > > So for this I want to propose a new workflow, which would also spread > some responsibilities around active members of the nouveau community: > > 1. We should have a public nouveau tree (which could be > https://gitlab.freedesktop.org/drm/nouveau or something else) with a > nouveau-next branch collecting all patches for the next kernel major > kernel release. > At the moment the "official" nouveau tree is kind of > https://github.com/skeggsb/nouveau but there is > https://github.com/skeggsb/linux as well. The main problem is, it's a > repository tight to a person. We already have > https://gitlab.freedesktop.org/drm/nouveau as a bug tracker, but it > also contains a full linux git tree which is updated automatically > through a CI job. > > 2. A chosen group of people should have push rights to this repository > in order to accept patches sent in via emails to the nouveau Mailing > List or fancy UIs (like gitlabs MRs) or other ways. > Trusted contributors should be allowed to review and accept submitted > patches in order to reduce the workload on Ben. Those patches will be > collected on the nouveau-next branch. Patches from a mailing list > could e.g. be submitted through a MR on gitlab or just pushed to the > branch directly. > > 3. We should ensure through CI that submitted patches are at least > passing basic quality control (checkpatch, compile testing, sparse, > etc...) > I already worked on this and one example can be seen here: > https://gitlab.freedesktop.org/drm/nouveau/-/merge_requests/3 > There are more things we could add to it, like checking if sparse is > happy or add additional checks. Adding tests against hw is something > we want to target for the future as well. > > 4. patches from nouveau-next should be included into a "higher" git > tree (drm-next or drm-misc-next) by authorized people after getting a > final review by Ben or somebody else. > The idea is to post all collected patches for final review to the > mailing list as Ben wanted to have a final possibility to nack it in > case something stands out. We could then depend on Ben including those > patches, but we could also use commit rights to drm-next or > drm-misc-next from other people as well. I have commit access to the > drm-misc repository, and I would assume that Lyude would be able to > get it as well or already has it. Hm I'm not sure that double-indirect makes a lot of sense. There's imo two reasonable models here: - commit rights on drm/nouveau, Ben sends out the pull requests to drm-next for those, which gives him a good point to check over and do any last touches - directly push to drm-misc-next, defacto having a group commit right thing going on there directly Doing first commit rights and then resending the entire pile is way too much beaurocracy and wont solve m
Re: [PATCH] drm/i915: Release ctx->syncobj on final put, not on ctx close
On Mon, Aug 09, 2021 at 08:47:14PM +0200, Daniel Vetter wrote:
> On Sun, Aug 8, 2021 at 2:56 AM Jason Ekstrand wrote:
> >
> > On August 6, 2021 15:18:59 Daniel Vetter wrote:
> >
> >> gem context refcounting is another exercise in least locking design it
> >> seems, where most things get destroyed upon context closure (which can
> >> race with anything really). Only the actual memory allocation and the
> >> locks survive while holding a reference.
> >>
> >> This tripped up Jason when reimplementing the single timeline feature
> >> in
> >>
> >> commit 00dae4d3d35d4f526929633b76e00b0ab4d3970d
> >> Author: Jason Ekstrand
> >> Date: Thu Jul 8 10:48:12 2021 -0500
> >>
> >> drm/i915: Implement SINGLE_TIMELINE with a syncobj (v4)
> >>
> >> We could fix the bug by holding ctx->mutex, but it's cleaner to just
> >
> >
> > What bug is this fixing, exactly?
>
> Oh lol I was all busy ranting and not explaining :-) I found it while
> auditing other context stuff, so that other patch has the longer
> commit message with more history, but that patch is also now tied into
> the vm-dercuify, so short summary: You put the syncobj in context
> close (i.e. CTX_DESTRY ioctl or close(drmfd)), not in the final
> kref_put. Which means you're open to a use-after-free if you race
> against an execbuf. ctx->vm is equally broken (but for other ioctl),
> once this fix here is merged I send out the ctx->vm fix because that's
> tied into the vm-dercuify now due to conflicts.
CI caught more, so just explaining what I'm fixing here isn't going to be
enough.
The troubel is that drm_syncobj_put is now called from very awkward
places, and I need to see whether we can fix that. Or whether we need more
work_struct (like we have already for i915_address_space) for the final
release.
-Daniel
> -Daniel
>
> >
> > --Jason
> >
> >>
> >> make the context object actually invariant over its _entire_ lifetime.
> >>
> >> Signed-off-by: Daniel Vetter
> >> Fixes: 00dae4d3d35d ("drm/i915: Implement SINGLE_TIMELINE with a syncobj
> >> (v4)")
> >> Cc: Jason Ekstrand
> >> Cc: Chris Wilson
> >> Cc: Tvrtko Ursulin
> >> Cc: Joonas Lahtinen
> >> Cc: Matthew Brost
> >> Cc: Matthew Auld
> >> Cc: Maarten Lankhorst
> >> Cc: "Thomas Hellström"
> >> Cc: Lionel Landwerlin
> >> Cc: Dave Airlie
> >> ---
> >> drivers/gpu/drm/i915/gem/i915_gem_context.c | 6 +++---
> >> 1 file changed, 3 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> >> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> >> index 754b9b8d4981..93ba0197d70a 100644
> >> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> >> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> >> @@ -940,6 +940,9 @@ void i915_gem_context_release(struct kref *ref)
> >> trace_i915_context_free(ctx);
> >> GEM_BUG_ON(!i915_gem_context_is_closed(ctx));
> >>
> >> + if (ctx->syncobj)
> >> + drm_syncobj_put(ctx->syncobj);
> >> +
> >> mutex_destroy(&ctx->engines_mutex);
> >> mutex_destroy(&ctx->lut_mutex);
> >>
> >> @@ -1159,9 +1162,6 @@ static void context_close(struct i915_gem_context
> >> *ctx)
> >> if (vm)
> >> i915_vm_close(vm);
> >>
> >> - if (ctx->syncobj)
> >> - drm_syncobj_put(ctx->syncobj);
> >> -
> >> ctx->file_priv = ERR_PTR(-EBADF);
> >>
> >> /*
> >> --
> >> 2.32.0
> >
> >
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: linux-next: build warnings after merge of the drm tree
On Tue, Aug 10, 2021 at 07:26:36PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> On Thu, 8 Jul 2021 12:20:48 +1000 Stephen Rothwell
> wrote:
> >
> > On Thu, 3 Jun 2021 19:32:42 +1000 Stephen Rothwell
> > wrote:
> > >
> > > After merging the drm tree, today's linux-next build (htmldocs) produced
> > > these warnings:
> > >
> > > Documentation/gpu/driver-uapi.rst:2412: WARNING: Duplicate C declaration,
> > > also defined at gpu/rfc/i915_gem_lmem:1393.
> > > Declaration is '.. c:enum:: drm_i915_gem_memory_class'.
> > > Documentation/gpu/driver-uapi.rst:2484: WARNING: Duplicate C declaration,
> > > also defined at gpu/rfc/i915_gem_lmem:2484.
> > > Declaration is '.. c:struct:: drm_i915_gem_memory_class_instance'.
> > > Documentation/gpu/driver-uapi.rst:7: WARNING: Duplicate C declaration,
> > > also defined at gpu/rfc/i915_gem_lmem:7.
> > > Declaration is '.. c:struct:: drm_i915_memory_region_info'.
> > > Documentation/gpu/driver-uapi.rst:2531: WARNING: Duplicate C declaration,
> > > also defined at gpu/rfc/i915_gem_lmem:2531.
> > > Declaration is '.. c:struct:: drm_i915_query_memory_regions'.
> > > Documentation/gpu/driver-uapi.rst:2595: WARNING: Duplicate C declaration,
> > > also defined at gpu/rfc/i915_gem_lmem:1393.
> > > Declaration is '.. c:struct:: drm_i915_gem_create_ext'.
> > > Documentation/gpu/driver-uapi.rst:2615: WARNING: Duplicate C declaration,
> > > also defined at gpu/rfc/i915_gem_lmem:1393.
> > > Declaration is '.. c:struct:: drm_i915_gem_create_ext_memory_regions'.
> > >
> > > Introduced by (one or more of) commits
> > >
> > > 0c1a77cbdafb ("drm/doc: add section for driver uAPI")
> > > 2bc9c04ea702 ("drm/doc/rfc: i915 DG1 uAPI")
> > > 727ecd99a4c9 ("drm/doc/rfc: drop the i915_gem_lmem.h header")
> >
> > I am still getting these warning.
>
> Still getting them ...
Matt Auld is on vacation, and the other issue is that the tree where this
is from isn't in linux-next. So will take a bit to get sorted in
linux-next.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH v2 1/3] drm/panel: seperate panel power control from panel prepare/unprepare
On Sun, Aug 08, 2021 at 08:52:16PM +0800, Jitao Shi wrote:
> Some dsi panels require the dsi lanes keeping low before panel power
> on. So seperate the panel power control and the communication with panel.
>
> And put the power control in drm_panel_prepare_power and
> drm_panel_unprepare_power. Put the communication with panel in
> drm_panel_prepare and drm_panel_unprepare.
>
> Signed-off-by: Jitao Shi
This solves your problem, but it breaks the panel standard for everyone
else since you're not converting them over.
There needs to be more thought here in how to make this all compatible.
Also I think we need very precise spec for how this is supposed to work
with DSI panels, and then making sure existing drivers mostly follow this.
Hacking up a shared interface that's used by lots of drivers just to then
fix a bug in one user and one implementation is not good.
-Daniel
> ---
> drivers/gpu/drm/bridge/panel.c | 17 +++
> drivers/gpu/drm/drm_panel.c| 38 ++
> include/drm/drm_bridge.h | 2 ++
> include/drm/drm_panel.h| 17 +++
> 4 files changed, 74 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
> index c916f4b8907e..3a846ac8e24c 100644
> --- a/drivers/gpu/drm/bridge/panel.c
> +++ b/drivers/gpu/drm/bridge/panel.c
> @@ -137,6 +137,23 @@ static int panel_bridge_get_modes(struct drm_bridge
> *bridge,
> return drm_panel_get_modes(panel_bridge->panel, connector);
> }
>
> +int panel_bridge_prepare_power(struct drm_bridge *bridge)
> +{
> + struct panel_bridge *panel_bridge = drm_bridge_to_panel_bridge(bridge);
> +
> + return drm_panel_prepare_power(panel_bridge->panel);
> +}
> +EXPORT_SYMBOL(panel_bridge_prepare_power);
> +
> +int panel_bridge_unprepare_power(struct drm_bridge *bridge)
> +{
> +struct panel_bridge *panel_bridge =
> drm_bridge_to_panel_bridge(bridge);
> +
> +return drm_panel_unprepare_power(panel_bridge->panel);
> +}
> +EXPORT_SYMBOL(panel_bridge_unprepare_power);
> +
> +
> static const struct drm_bridge_funcs panel_bridge_bridge_funcs = {
> .attach = panel_bridge_attach,
> .detach = panel_bridge_detach,
> diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
> index f634371c717a..7bb5185db17d 100644
> --- a/drivers/gpu/drm/drm_panel.c
> +++ b/drivers/gpu/drm/drm_panel.c
> @@ -115,6 +115,24 @@ int drm_panel_prepare(struct drm_panel *panel)
> }
> EXPORT_SYMBOL(drm_panel_prepare);
>
> +/**
> + * drm_panel_prepare_power - power on a panel's power
> + * @panel: DRM panel
> + *
> + * Calling this function will enable power and deassert any reset signals to
> + * the panel.
> + *
> + * Return: 0 on success or a negative error code on failure.
> + */
> +int drm_panel_prepare_power(struct drm_panel *panel)
> +{
> + if (panel && panel->funcs && panel->funcs->prepare_power)
> + return panel->funcs->prepare_power(panel);
> +
> + return panel ? -ENOSYS : -EINVAL;
> +}
> +EXPORT_SYMBOL(drm_panel_prepare_power);
> +
> /**
> * drm_panel_unprepare - power off a panel
> * @panel: DRM panel
> @@ -138,6 +156,26 @@ int drm_panel_unprepare(struct drm_panel *panel)
> }
> EXPORT_SYMBOL(drm_panel_unprepare);
>
> +/**
> + * drm_panel_unprepare_power - power off a panel
> + * @panel: DRM panel
> + *
> + * Calling this function will completely power off a panel (assert the
> panel's
> + * reset, turn off power supplies, ...). After this function has completed,
> it
> + * is usually no longer possible to communicate with the panel until another
> + * call to drm_panel_prepare_power and drm_panel_prepare().
> + *
> + * Return: 0 on success or a negative error code on failure.
> + */
> +int drm_panel_unprepare_power(struct drm_panel *panel)
> +{
> + if (panel && panel->funcs && panel->funcs->unprepare_power)
> + return panel->funcs->unprepare_power(panel);
> +
> + return panel ? -ENOSYS : -EINVAL;
> +}
> +EXPORT_SYMBOL(drm_panel_unprepare_power);
> +
> /**
> * drm_panel_enable - enable a panel
> * @panel: DRM panel
> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> index 2195daa289d2..cc94c9da47d8 100644
> --- a/include/drm/drm_bridge.h
> +++ b/include/drm/drm_bridge.h
> @@ -892,6 +892,8 @@ struct drm_bridge *devm_drm_panel_bridge_add_typed(struct
> device *dev,
> struct drm_panel *panel,
> u32 connector_type);
> struct drm_connector *drm_panel_bridge_connector(struct drm_bridge *bridge);
> +int panel_bridge_prepare_power(struct drm_bridge *bridge);
> +int panel_bridge_unprepare_power(struct drm_bridge *bridge);
> #endif
>
> #endif
> diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
> index 33605c3f0eba..48e83712ad44 100644
> --- a/include/drm/drm_panel.h
> +++ b/include/drm/drm_panel.h
> @@ -68,6 +68,13 @@ enum drm_panel_orientation;
> * functio
Re: [PATCH 3/8] drm/ingenic: Use standard drm_atomic_helper_commit_tail
On Sun, Aug 08, 2021 at 03:45:21PM +0200, Paul Cercueil wrote:
> By making the CRTC's .vblank_enable() function return an error when it
> is known that the hardware won't deliver a VBLANK, we can drop the
> ingenic_drm_atomic_helper_commit_tail() function and use the standard
> drm_atomic_helper_commit_tail() function instead.
>
> Signed-off-by: Paul Cercueil
> ---
> drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 28 ---
> 1 file changed, 4 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> index bc71ba44ccf4..3ed7c27a8dde 100644
> --- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> +++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> @@ -706,29 +706,6 @@ static int ingenic_drm_encoder_atomic_check(struct
> drm_encoder *encoder,
> }
> }
>
> -static void ingenic_drm_atomic_helper_commit_tail(struct drm_atomic_state
> *old_state)
> -{
> - /*
> - * Just your regular drm_atomic_helper_commit_tail(), but only calls
> - * drm_atomic_helper_wait_for_vblanks() if priv->no_vblank.
> - */
> - struct drm_device *dev = old_state->dev;
> - struct ingenic_drm *priv = drm_device_get_priv(dev);
> -
> - drm_atomic_helper_commit_modeset_disables(dev, old_state);
> -
> - drm_atomic_helper_commit_planes(dev, old_state, 0);
> -
> - drm_atomic_helper_commit_modeset_enables(dev, old_state);
> -
> - drm_atomic_helper_commit_hw_done(old_state);
> -
> - if (!priv->no_vblank)
> - drm_atomic_helper_wait_for_vblanks(dev, old_state);
> -
> - drm_atomic_helper_cleanup_planes(dev, old_state);
> -}
> -
> static irqreturn_t ingenic_drm_irq_handler(int irq, void *arg)
> {
> struct ingenic_drm *priv = drm_device_get_priv(arg);
> @@ -749,6 +726,9 @@ static int ingenic_drm_enable_vblank(struct drm_crtc
> *crtc)
> {
> struct ingenic_drm *priv = drm_crtc_get_priv(crtc);
>
> + if (priv->no_vblank)
> + return -EWOULDBLOCK;
I think other drivers return EINVAL here. I'm not sure exactly this is
specified, but the errno here is visible to userspace.
Maybe would be good to update the kerneldoc for this hook?
Anyway this is great, with the errno fixed:
Reviewed-by: Daniel Vetter
> +
> regmap_update_bits(priv->map, JZ_REG_LCD_CTRL,
> JZ_LCD_CTRL_EOF_IRQ, JZ_LCD_CTRL_EOF_IRQ);
>
> @@ -856,7 +836,7 @@ static const struct drm_mode_config_funcs
> ingenic_drm_mode_config_funcs = {
> };
>
> static struct drm_mode_config_helper_funcs ingenic_drm_mode_config_helpers =
> {
> - .atomic_commit_tail = ingenic_drm_atomic_helper_commit_tail,
> + .atomic_commit_tail = drm_atomic_helper_commit_tail,
> };
>
> static void ingenic_drm_unbind_all(void *d)
> --
> 2.30.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH] dma-buf: Fix a few typos in dma-buf documentation
On Mon, Aug 09, 2021 at 08:49:16AM -0700, Randy Dunlap wrote:
> On 8/9/21 5:22 AM, Gal Pressman wrote:
> > Fix a few typos in the documentation:
> > - Remove an extraneous 'or'
> > - 'unpins' -> 'unpin'
> > - 'braket' -> 'bracket'
> > - 'mappinsg' -> 'mappings'
> > - 'fullfills' -> 'fulfills'
> >
> > Signed-off-by: Gal Pressman
>
> Reviewed-by: Randy Dunlap
Applied to drm-misc-next, thanks for patch&review.
-Daniel
>
> Thanks.
>
> > ---
> > include/linux/dma-buf.h | 10 +-
> > 1 file changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> > index efdc56b9d95f..772403352767 100644
> > --- a/include/linux/dma-buf.h
> > +++ b/include/linux/dma-buf.h
> > @@ -54,7 +54,7 @@ struct dma_buf_ops {
> > * device), and otherwise need to fail the attach operation.
> > *
> > * The exporter should also in general check whether the current
> > -* allocation fullfills the DMA constraints of the new device. If this
> > +* allocation fulfills the DMA constraints of the new device. If this
> > * is not the case, and the allocation cannot be moved, it should also
> > * fail the attach operation.
> > *
> > @@ -146,7 +146,7 @@ struct dma_buf_ops {
> > *
> > * Returns:
> > *
> > -* A &sg_table scatter list of or the backing storage of the DMA buffer,
> > +* A &sg_table scatter list of the backing storage of the DMA buffer,
> > * already mapped into the device address space of the &device attached
> > * with the provided &dma_buf_attachment. The addresses and lengths in
> > * the scatter list are PAGE_SIZE aligned.
> > @@ -168,7 +168,7 @@ struct dma_buf_ops {
> > *
> > * This is called by dma_buf_unmap_attachment() and should unmap and
> > * release the &sg_table allocated in @map_dma_buf, and it is mandatory.
> > -* For static dma_buf handling this might also unpins the backing
> > +* For static dma_buf handling this might also unpin the backing
> > * storage if this is the last mapping of the DMA buffer.
> > */
> > void (*unmap_dma_buf)(struct dma_buf_attachment *,
> > @@ -237,7 +237,7 @@ struct dma_buf_ops {
> > * This callback is used by the dma_buf_mmap() function
> > *
> > * Note that the mapping needs to be incoherent, userspace is expected
> > -* to braket CPU access using the DMA_BUF_IOCTL_SYNC interface.
> > +* to bracket CPU access using the DMA_BUF_IOCTL_SYNC interface.
> > *
> > * Because dma-buf buffers have invariant size over their lifetime, the
> > * dma-buf core checks whether a vma is too large and rejects such
> > @@ -464,7 +464,7 @@ static inline bool dma_buf_is_dynamic(struct dma_buf
> > *dmabuf)
> > /**
> >* dma_buf_attachment_is_dynamic - check if a DMA-buf attachment uses
> > dynamic
> > - * mappinsg
> > + * mappings
> >* @attach: the DMA-buf attachment to check
> >*
> >* Returns true if a DMA-buf importer wants to call the map/unmap
> > functions with
> >
>
>
> --
> ~Randy
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [Intel-gfx] [PATCH] drm/i915/gem/ttm: prefer kernel types
On Tue, Aug 10, 2021 at 11:41:28AM +0300, Jani Nikula wrote:
> Avoid uintXX_t types in the driver.
>
> Fixes: 213d50927763 ("drm/i915/ttm: Introduce a TTM i915 gem object backend")
> Cc: Thomas Hellström
> Cc: Matthew Auld
> Cc: Maarten Lankhorst
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> index 771eb2963123..ffda88156e32 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> @@ -168,7 +168,7 @@ i915_ttm_placement_from_obj(const struct
> drm_i915_gem_object *obj,
> }
>
> static struct ttm_tt *i915_ttm_tt_create(struct ttm_buffer_object *bo,
> - uint32_t page_flags)
> + u32 page_flags)
It's for the ttm_device_funcs ops table, I thinhk we should fix it there
and across the board?
Otherwise a bit ocd mismatch :-)
-Daniel
> {
> struct ttm_resource_manager *man =
> ttm_manager_type(bo->bdev, bo->resource->mem_type);
> --
> 2.20.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH 1/3] drm/i915/guc: Fix several issues related to resets / request cancelation
On Mon, Aug 09, 2021 at 07:35:22PM +, Matthew Brost wrote:
> On Mon, Aug 09, 2021 at 03:35:26PM +0200, Daniel Vetter wrote:
> > On Sun, Aug 08, 2021 at 11:07:55AM -0700, Matthew Brost wrote:
> > > Resets are notoriously hard to get fully working and notoriously racey,
> > > especially with selftests / IGTs that do all sorts of wild things that
> > > would be near impossible to hit during normal use cases. Even though
> > > likely impossible to hit, anything selftests / IGTs uncover needs to be
> > > fixed. This patch addresses 7 such issues.
> > >
> > > 1. A small race that could result in incorrect accounting of the number
> > > of outstanding G2H. Basically prior to this patch we did not increment
> > > the number of outstanding G2H if we encoutered a GT reset while sending
> > > a H2G. This was incorrect as the context state had already been updated
> > > to anticipate a G2H response thus the counter should be incremented.
> > >
> > > 2. When unwinding requests on a reset context, if other requests in the
> > > context are in the priority list the requests could be resubmitted out
> > > of seqno order. Traverse the list of active requests in reserve and
> > > append to the head of the priority list to fix this.
> > >
> > > 3. Don't drop ce->guc_active.lock when unwinding a context after reset.
> > > At one point we had to drop this because of a lock inversion but that is
> > > no longer the case. It is much safer to hold the lock so let's do that.
> > >
> > > 4. Prior to this patch the blocked context counter was cleared on
> > > init_sched_state (used during registering a context & resets) which is
> > > incorrect. This state needs to be persistent or the counter can read the
> > > incorrect value.
> > >
> > > 5. Flush the work queue for GuC generated G2H messages during a GT reset.
> > >
> > > 6. Do not clear enable during a context reset if a schedule enable is in
> > > flight.
> > >
> > > 7. When unblocking a context, do not enable scheduling if the context is
> > > banned.
> >
> > I think each of the above should be a separate patch. I think it would
> > also be good if each fix references the commits that introduced/changed
> > something.
> >
>
> Sure, just was trying to cheat and make our lives easier with less
> patches to backport into DII.
>
> > Most of this stuff is extremely hard to get right, and unfortunately our
> > current code is way too fond of lockless trickery (which really isn't a
> > great idea in the reset code). We need to apply as much care as possible
> > here.
> >
>
> Yep, resets are hard. It is hard because like ten other async things
> (e.g. a new submission, registering a context, banning a context,
> canceling a request, processing a G2H, trying to idle the GPU, unpinning
> a context) can all be happening at the same time. Hopefully when we move
> the DRM scheduler we can remove some of these async operations,
> perma-pinned contexts would also help too. Have a story for that + a
> story to simplify the locking.
A bit an aside, but drm/sched has a pretty solid story around resets,
including what to do if your reset domain escalates (probably more useful
for the execlist backend than GuC) and how it's all synchronized.
I do need to review the barriers for when you permanently wedge an engine,
and the support for that isn't well encapsulated nor documented. But it's
there (amdgpu uses that when the reset fails, kinda like we do), and
that's about the only gap I've found thus far around drm/sched reset
support.
So should all be substantially clarified once we get there.
-Daniel
>
> > Also expect me to ask a lot of annoying questions about all the atomic_t
> > you touch :-)
>
> Looking forward to it.
>
> Matt
>
> > -Daniel
> >
> >
> > >
> > > Fixes: f4eb1f3fe946 ("drm/i915/guc: Ensure G2H response has space in
> > > buffer")
> > > Fixes: 62eaf0ae217d ("drm/i915/guc: Support request cancellation")
> > > Fixes: eb5e7da736f3 ("drm/i915/guc: Reset implementation for new GuC
> > > interface")
> > > Signed-off-by: Matthew Brost
> > > Cc:
> > > ---
> > > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 43 ---
> > > 1 file changed, 27 insertions(+), 16 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > index 87d8dc8f51b9..cd8df078ca87 100644
> > > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > @@ -152,7 +152,7 @@ static inline void init_sched_state(struct
> > > intel_context *ce)
> > > {
> > > /* Only should be called from guc_lrc_desc_pin() */
> > > atomic_set(&ce->guc_sched_state_no_lock, 0);
> > > - ce->guc_state.sched_state = 0;
> > > + ce->guc_state.sched_state &= SCHED_STATE_BLOCKED_MASK;
> > > }
> > >
> > > static inline bool
> > > @@ -360,11 +360,13 @@ static int guc_submission_send_busy_loop(struct
> > > intel_guc *guc,
> > > {
> > > int
Re: [PATCH 2/2] gpu/drm: ingenic: Add workaround for disabled drivers
Hi Daniel,
Le mar., août 10 2021 at 11:35:43 +0200, Daniel Vetter
a écrit :
On Fri, Aug 06, 2021 at 01:01:33PM +0200, Paul Cercueil wrote:
Hi Greg,
Le ven., août 6 2021 at 12:17:55 +0200, Greg Kroah-Hartman
a écrit :
> On Thu, Aug 05, 2021 at 10:05:27PM +0200, Paul Cercueil wrote:
> > Hi Greg,
> >
> > Le jeu., août 5 2021 at 21:35:34 +0200, Greg Kroah-Hartman
> > a écrit :
> > > On Thu, Aug 05, 2021 at 09:21:09PM +0200, Paul Cercueil
wrote:
> > > > When the drivers of remote devices (e.g. HDMI chip) are
> > disabled in
> > > > the
> > > > config, we want the ingenic-drm driver to be able to probe
> > > > nonetheless
> > > > with the other devices (e.g. internal LCD panel) that are
> > enabled.
> > > >
> > > > Signed-off-by: Paul Cercueil
> > > > ---
> > > > drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 12
> > > > 1 file changed, 12 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> > > > b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> > > > index d261f7a03b18..5e1fdbb0ba6b 100644
> > > > --- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> > > > +++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> > > > @@ -1058,6 +1058,18 @@ static int ingenic_drm_bind(struct
> > device
> > > > *dev, bool has_components)
> > > > for (i = 0; ; i++) {
> > > > ret = drm_of_find_panel_or_bridge(dev->of_node, 0,
i,
> > &panel,
> > > > &bridge);
> > > > if (ret) {
> > > > +/*
> > > > + * Workaround for the case where the
drivers for the
> > > > + * remote devices are not enabled. When
that happens,
> > > > + * drm_of_find_panel_or_bridge() returns
-EPROBE_DEFER
> > > > + * endlessly, which prevents the ingenic-drm driver
from
> > > > + * working at all.
> > > > + */
> > > > +if (ret == -EPROBE_DEFER) {
> > > > +ret =
driver_deferred_probe_check_state(dev);
> > > > +if (ret == -ENODEV || ret ==
-ETIMEDOUT)
> > > > +continue;
> > > > +}
> > >
> > > So you are mucking around with devices on other busses
within this
> > > driver? What could go wrong? :(
> >
> > I'm doing the same thing as everybody else. This is the DRM
driver,
> > and
> > there is a driver for the external HDMI chip which gives us a
DRM
> > bridge
> > that we can obtain from the device tree.
>
> But then why do you need to call this function that is there for
a bus,
> not for a driver.
The documentation disagrees with you :)
And, if that has any weight, this solution was proposed by Rob.
> > > Please use the existing driver core functionality for this
type of
> > > thing, it is not unique, no need for this function to be
called.
> >
> > I'm not sure you understand what I'm doing here. This driver
calls
> > drm_of_find_panel_or_bridge(), without guarantee that the
driver
> > for the
> > remote device (connected via DT graph) has been enabled in the
> > kernel
> > config. In that case it will always return -EPROBE_DEFER and
the
> > ingenic-drm
> > driver will never probe.
> >
> > This patch makes sure that the driver can probe if the HDMI
driver
> > has been
> > disabled in the kernel config, nothing more.
>
> That should not be an issue as you do not care if the config is
enabled,
> you just want to do something in the future if the driver shows
up,
> right?
Well, the DRM subsystem doesn't really seem to handle hotplug of
hardware.
Right now all the drivers for the connected hardware need to probe
before
the main DRM driver. So I need to know that a remote device
(connected via
DT graph) will never probe.
Give me a of_graph_remote_device_driver_will_never_probe() and I'll
use
that.
> Much like the device link code, have you looked at that?
I don't see how that would help in any way. The device link code
would allow
me to set a dependency between the remote hardware (HDMI chip,
provider) and
the LCD controller (consumer), but I already have that dependency
though the
DT graph. What I need is a way for the consumer to continue probing
if the
provider is not going to probe.
Is this actually a legit use-case?
Like you have hw with a bunch of sub-devices linked, and you decided
to
disable some of them, which makes the driver not load.
Yes. I'm facing that issue with a board that has a LCD panel and a HDMI
controller (IT66121). I have a "flasher" program for all the Ingenic
boards, that's basically just a Linux kernel + initramfs booted over
USB (device). I can't realistically enable every single driver for all
the hardware that's on these boards while s
Re: [Intel-gfx] [PATCH 2/3] drm/i915/selftests: Fix memory corruption in live_lrc_isolation
On Mon, Aug 09, 2021 at 07:37:39PM +, Matthew Brost wrote:
> On Mon, Aug 09, 2021 at 03:38:38PM +0200, Daniel Vetter wrote:
> > On Sun, Aug 08, 2021 at 11:07:56AM -0700, Matthew Brost wrote:
> > > GuC submission has exposed an existing memory corruption in
> > > live_lrc_isolation. We believe that some writes to the watchdog offsets
> > > in the LRC (0x178 & 0x17c) can result in trashing of portions of the
> > > address space. With GuC submission there are additional objects which
> > > can move the context redzone into the space that is trashed. To
> > > workaround this avoid poisoning the watchdog.
> >
> > A Bspec reference here would be good (we can quote anything that's marked
> > for public release, so doesn't have one of the IP markers).
> >
>
> Let me see what I dig up in the bspec.
>
> BTW - Hopefully we can root cause this soon with a proper fix.
Well if it's work-in-progress duct-tape without reference that's fine
too, then perhaps sprinkle a JIRA number here (just not the full link,
intel IT doesn't like those leaking). Just something that in a few months
when someone reads that code they can stitch together the story again.
-Daniel
>
> > Also I think the above should be replicated in condensed form instead of
> > the XXX comment.
> >
>
> Sure.
>
> Matt
>
> > With those: Acked-by: Daniel Vetter since I
> > definitely have enough clue here for a detailed review.
> > -Daniel
> >
> > >
> > > Signed-off-by: Matthew Brost
> > > ---
> > > drivers/gpu/drm/i915/gt/selftest_lrc.c | 29 +-
> > > 1 file changed, 28 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
> > > b/drivers/gpu/drm/i915/gt/selftest_lrc.c
> > > index b0977a3b699b..6500e9fce8a0 100644
> > > --- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
> > > +++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
> > > @@ -1074,6 +1074,32 @@ record_registers(struct intel_context *ce,
> > > goto err_after;
> > > }
> > >
> > > +static u32 safe_offset(u32 offset, u32 reg)
> > > +{
> > > + /* XXX skip testing of watchdog */
> > > + if (offset == 0x178 || offset == 0x17c)
> > > + reg = 0;
> > > +
> > > + return reg;
> > > +}
> > > +
> > > +static int get_offset_mask(struct intel_engine_cs *engine)
> > > +{
> > > + if (GRAPHICS_VER(engine->i915) < 12)
> > > + return 0xfff;
> > > +
> > > + switch (engine->class) {
> > > + default:
> > > + case RENDER_CLASS:
> > > + return 0x07ff;
> > > + case COPY_ENGINE_CLASS:
> > > + return 0x0fff;
> > > + case VIDEO_DECODE_CLASS:
> > > + case VIDEO_ENHANCEMENT_CLASS:
> > > + return 0x3fff;
> > > + }
> > > +}
> > > +
> > > static struct i915_vma *load_context(struct intel_context *ce, u32
> > > poison)
> > > {
> > > struct i915_vma *batch;
> > > @@ -1117,7 +1143,8 @@ static struct i915_vma *load_context(struct
> > > intel_context *ce, u32 poison)
> > > len = (len + 1) / 2;
> > > *cs++ = MI_LOAD_REGISTER_IMM(len);
> > > while (len--) {
> > > - *cs++ = hw[dw];
> > > + *cs++ = safe_offset(hw[dw] &
> > > get_offset_mask(ce->engine),
> > > + hw[dw]);
> > > *cs++ = poison;
> > > dw += 2;
> > > }
> > > --
> > > 2.28.0
> > >
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [Intel-gfx] [PATCH 3/3] drm/i915/selftests: Add initial GuC selftest for scrubbing lost G2H
On Mon, Aug 09, 2021 at 07:41:29PM +, Matthew Brost wrote:
> On Mon, Aug 09, 2021 at 04:03:28PM +0200, Daniel Vetter wrote:
> > On Sun, Aug 08, 2021 at 11:07:57AM -0700, Matthew Brost wrote:
> > > While debugging an issue with full GT resets I went down a rabbit hole
> > > thinking the scrubbing of lost G2H wasn't working correctly. This proved
> > > to be incorrect as this was working just fine but this chase inspired me
> > > to write a selftest to prove that this works. This simple selftest
> > > injects errors dropping various G2H and then issues a full GT reset
> > > proving that the scrubbing of these G2H doesn't blow up.
> > >
> > > Signed-off-by: Matthew Brost
> > > ---
> > > drivers/gpu/drm/i915/gt/intel_context_types.h | 4 +
> > > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 18 +++
> > > drivers/gpu/drm/i915/gt/uc/selftest_guc.c | 126 ++
> > > .../drm/i915/selftests/i915_live_selftests.h | 1 +
> > > .../i915/selftests/intel_scheduler_helpers.c | 12 ++
> > > .../i915/selftests/intel_scheduler_helpers.h | 2 +
> > > 6 files changed, 163 insertions(+)
> > > create mode 100644 drivers/gpu/drm/i915/gt/uc/selftest_guc.c
> > >
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
> > > b/drivers/gpu/drm/i915/gt/intel_context_types.h
> > > index e54351a170e2..fec5ff7ef168 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_context_types.h
> > > +++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
> > > @@ -198,6 +198,10 @@ struct intel_context {
> > >*/
> > > u8 guc_prio;
> > > u32 guc_prio_count[GUC_CLIENT_PRIORITY_NUM];
> > > +
> >
> > I know the existing stuff isn't following this at all, but for anything
> > new we really should put some kerneldoc into structures. This probably
> > means you need to open-code the #ifdef here, since this macro will likely
> > upset kerneldoc parsing.
> >
>
> Ok, got it.
>
> > > + I915_SELFTEST_DECLARE(bool drop_schedule_enable);
> > > + I915_SELFTEST_DECLARE(bool drop_schedule_disable);
> > > + I915_SELFTEST_DECLARE(bool drop_deregister);
> > > };
> > >
> > > #endif /* __INTEL_CONTEXT_TYPES__ */
> > > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > index cd8df078ca87..d13dc56bae43 100644
> > > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > @@ -2618,6 +2618,11 @@ int intel_guc_deregister_done_process_msg(struct
> > > intel_guc *guc,
> > >
> > > trace_intel_context_deregister_done(ce);
> > >
> > > + if (I915_SELFTEST_ONLY(ce->drop_deregister)) {
> > > + I915_SELFTEST_DECLARE(ce->drop_deregister = false;)
> >
> > This macro wrapping is quite nasty, can't we just #ifdef this? Especially
> > the _DECLARE name really doesn't expect a statement.
> >
>
> Had it like that originally then remember these marcos and in the past
> people have complained when I didn't use them, so yes pretty much a
> bikeshed. I personally like the ifdef myself.
I think the plain #ifdef is much clearer in the code. The
I915_SELFTEST_ONLY macro makes some sense to compile stuff out in some
cases and make sure it's wrapped in unlikely when enabled, and often
that's good enough. But not here.
Also because it breaks kerneldoc I don't like the macro really in structs
either. Anything that discourages people from writing solid comments is
Not Good at All :-) So another reason to not like I915_SELFTEST_DECLARE()
macro.
-Daniel
>
> Matt
>
> > Aside from these bikesheds I don't have a much to say on the test logic
> > itself, since I'm far from knowledgable on guc stuff ...
> > -Daniel
> >
> >
> > > + return 0;
> > > + }
> > > +
> > > if (context_wait_for_deregister_to_register(ce)) {
> > > struct intel_runtime_pm *runtime_pm =
> > > &ce->engine->gt->i915->runtime_pm;
> > > @@ -2672,10 +2677,19 @@ int intel_guc_sched_done_process_msg(struct
> > > intel_guc *guc,
> > > trace_intel_context_sched_done(ce);
> > >
> > > if (context_pending_enable(ce)) {
> > > + if (I915_SELFTEST_ONLY(ce->drop_schedule_enable)) {
> > > + I915_SELFTEST_DECLARE(ce->drop_schedule_enable = false;)
> > > + return 0;
> > > + }
> > > clr_context_pending_enable(ce);
> > > } else if (context_pending_disable(ce)) {
> > > bool banned;
> > >
> > > + if (I915_SELFTEST_ONLY(ce->drop_schedule_disable)) {
> > > + I915_SELFTEST_DECLARE(ce->drop_schedule_disable =
> > > false;)
> > > + return 0;
> > > + }
> > > +
> > > /*
> > >* Unpin must be done before __guc_signal_context_fence,
> > >* otherwise a race exists between the requests getting
> > > @@ -3047,3 +3061,7 @@ bool intel_guc_virtual_engine_has_heartbeat(const
> > > struct intel_engine_cs *ve)
> > >
> > > return false;
> > > }
> > > +
> >
Re: linux-next: build warnings after merge of the drm tree
Hi Daniel, On Tue, 10 Aug 2021 12:14:38 +0200 Daniel Vetter wrote: > > Matt Auld is on vacation, and the other issue is that the tree where this > is from isn't in linux-next. So will take a bit to get sorted in > linux-next. Those warnings are now coming from Linus' tree (some time before v5.14-rc1). I first mentioned them on June 3. -- Cheers, Stephen Rothwell pgpzLaO456J40.pgp Description: OpenPGP digital signature
Re: [PATCH 2/2] gpu/drm: ingenic: Add workaround for disabled drivers
Hi Greg,
Le mar., août 10 2021 at 11:47:32 +0200, Greg Kroah-Hartman
a écrit :
On Fri, Aug 06, 2021 at 01:01:33PM +0200, Paul Cercueil wrote:
Hi Greg,
Le ven., août 6 2021 at 12:17:55 +0200, Greg Kroah-Hartman
a écrit :
> On Thu, Aug 05, 2021 at 10:05:27PM +0200, Paul Cercueil wrote:
> > Hi Greg,
> >
> > Le jeu., août 5 2021 at 21:35:34 +0200, Greg Kroah-Hartman
> > a écrit :
> > > On Thu, Aug 05, 2021 at 09:21:09PM +0200, Paul Cercueil
wrote:
> > > > When the drivers of remote devices (e.g. HDMI chip) are
> > disabled in
> > > > the
> > > > config, we want the ingenic-drm driver to be able to probe
> > > > nonetheless
> > > > with the other devices (e.g. internal LCD panel) that are
> > enabled.
> > > >
> > > > Signed-off-by: Paul Cercueil
> > > > ---
> > > > drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 12
> > > > 1 file changed, 12 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> > > > b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> > > > index d261f7a03b18..5e1fdbb0ba6b 100644
> > > > --- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> > > > +++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> > > > @@ -1058,6 +1058,18 @@ static int ingenic_drm_bind(struct
> > device
> > > > *dev, bool has_components)
> > > > for (i = 0; ; i++) {
> > > > ret = drm_of_find_panel_or_bridge(dev->of_node, 0,
i,
> > &panel,
> > > > &bridge);
> > > > if (ret) {
> > > > +/*
> > > > + * Workaround for the case where the
drivers for the
> > > > + * remote devices are not enabled. When
that happens,
> > > > + * drm_of_find_panel_or_bridge() returns
-EPROBE_DEFER
> > > > + * endlessly, which prevents the ingenic-drm driver
from
> > > > + * working at all.
> > > > + */
> > > > +if (ret == -EPROBE_DEFER) {
> > > > +ret =
driver_deferred_probe_check_state(dev);
> > > > +if (ret == -ENODEV || ret ==
-ETIMEDOUT)
> > > > +continue;
> > > > +}
> > >
> > > So you are mucking around with devices on other busses
within this
> > > driver? What could go wrong? :(
> >
> > I'm doing the same thing as everybody else. This is the DRM
driver,
> > and
> > there is a driver for the external HDMI chip which gives us a
DRM
> > bridge
> > that we can obtain from the device tree.
>
> But then why do you need to call this function that is there for
a bus,
> not for a driver.
The documentation disagrees with you :)
And, if that has any weight, this solution was proposed by Rob.
> > > Please use the existing driver core functionality for this
type of
> > > thing, it is not unique, no need for this function to be
called.
> >
> > I'm not sure you understand what I'm doing here. This driver
calls
> > drm_of_find_panel_or_bridge(), without guarantee that the
driver
> > for the
> > remote device (connected via DT graph) has been enabled in the
> > kernel
> > config. In that case it will always return -EPROBE_DEFER and
the
> > ingenic-drm
> > driver will never probe.
> >
> > This patch makes sure that the driver can probe if the HDMI
driver
> > has been
> > disabled in the kernel config, nothing more.
>
> That should not be an issue as you do not care if the config is
enabled,
> you just want to do something in the future if the driver shows
up,
> right?
Well, the DRM subsystem doesn't really seem to handle hotplug of
hardware.
Right now all the drivers for the connected hardware need to probe
before
the main DRM driver. So I need to know that a remote device
(connected via
DT graph) will never probe.
But you never really know that. That is what the recent driver core
changes were all about, to handle this very issue. Only when the
child
device shows up will you need to care about it.
Give me a of_graph_remote_device_driver_will_never_probe() and I'll
use
that.
> Much like the device link code, have you looked at that?
I don't see how that would help in any way. The device link code
would allow
me to set a dependency between the remote hardware (HDMI chip,
provider) and
the LCD controller (consumer), but I already have that dependency
though the
DT graph. What I need is a way for the consumer to continue probing
if the
provider is not going to probe.
But again, you never know that, probing is async, and could happen in
a
few milliseconds, or a few hours, your driver should never care about
this at all.
Just knowing if the kernel configuration is something is not the
solution here, please fix this properly like all other driver
interactions a
Re: [PATCH 3/8] drm/ingenic: Use standard drm_atomic_helper_commit_tail
Hi Daniel,
Le mar., août 10 2021 at 12:20:38 +0200, Daniel Vetter
a écrit :
On Sun, Aug 08, 2021 at 03:45:21PM +0200, Paul Cercueil wrote:
By making the CRTC's .vblank_enable() function return an error when
it
is known that the hardware won't deliver a VBLANK, we can drop the
ingenic_drm_atomic_helper_commit_tail() function and use the
standard
drm_atomic_helper_commit_tail() function instead.
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 28
---
1 file changed, 4 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index bc71ba44ccf4..3ed7c27a8dde 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -706,29 +706,6 @@ static int
ingenic_drm_encoder_atomic_check(struct drm_encoder *encoder,
}
}
-static void ingenic_drm_atomic_helper_commit_tail(struct
drm_atomic_state *old_state)
-{
- /*
- * Just your regular drm_atomic_helper_commit_tail(), but only
calls
- * drm_atomic_helper_wait_for_vblanks() if priv->no_vblank.
- */
- struct drm_device *dev = old_state->dev;
- struct ingenic_drm *priv = drm_device_get_priv(dev);
-
- drm_atomic_helper_commit_modeset_disables(dev, old_state);
-
- drm_atomic_helper_commit_planes(dev, old_state, 0);
-
- drm_atomic_helper_commit_modeset_enables(dev, old_state);
-
- drm_atomic_helper_commit_hw_done(old_state);
-
- if (!priv->no_vblank)
- drm_atomic_helper_wait_for_vblanks(dev, old_state);
-
- drm_atomic_helper_cleanup_planes(dev, old_state);
-}
-
static irqreturn_t ingenic_drm_irq_handler(int irq, void *arg)
{
struct ingenic_drm *priv = drm_device_get_priv(arg);
@@ -749,6 +726,9 @@ static int ingenic_drm_enable_vblank(struct
drm_crtc *crtc)
{
struct ingenic_drm *priv = drm_crtc_get_priv(crtc);
+ if (priv->no_vblank)
+ return -EWOULDBLOCK;
I think other drivers return EINVAL here. I'm not sure exactly this is
specified, but the errno here is visible to userspace.
Maybe would be good to update the kerneldoc for this hook?
Anyway this is great, with the errno fixed:
Reviewed-by: Daniel Vetter
I thought about it afterwards, that my error code wasn't great. In my
mind it was "the driver will hang while waiting for vblank" hence
-EWOULDBLOCK ;)
I'll need to v2 anyway so I'll change it to -EINVAL then.
Cheers,
-Paul
+
regmap_update_bits(priv->map, JZ_REG_LCD_CTRL,
JZ_LCD_CTRL_EOF_IRQ, JZ_LCD_CTRL_EOF_IRQ);
@@ -856,7 +836,7 @@ static const struct drm_mode_config_funcs
ingenic_drm_mode_config_funcs = {
};
static struct drm_mode_config_helper_funcs
ingenic_drm_mode_config_helpers = {
- .atomic_commit_tail = ingenic_drm_atomic_helper_commit_tail,
+ .atomic_commit_tail = drm_atomic_helper_commit_tail,
};
static void ingenic_drm_unbind_all(void *d)
--
2.30.2
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH v3] drm/msm: Remove initialization of static variables
Address the following checkpatch errors:
ERROR: do not initialise statics to false
FILE: :drivers/gpu/drm/msm/msm_drv.c:21:
-static bool reglog = false;
FILE: :drivers/gpu/drm/msm/msm_drv.c:31:
-bool dumpstate = false;
Signed-off-by: zhaoxiao
---
v3: Subject should start out with drm/msm, not drm/drv
drivers/gpu/drm/msm/msm_drv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 9b8fa2ad0d84..d9ca4bc9620b 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -59,7 +59,7 @@ static const struct drm_mode_config_helper_funcs
mode_config_helper_funcs = {
};
#ifdef CONFIG_DRM_MSM_REGISTER_LOGGING
-static bool reglog = false;
+static bool reglog;
MODULE_PARM_DESC(reglog, "Enable register read/write logging");
module_param(reglog, bool, 0600);
#else
@@ -76,7 +76,7 @@ static char *vram = "16m";
MODULE_PARM_DESC(vram, "Configure VRAM size (for devices without
IOMMU/GPUMMU)");
module_param(vram, charp, 0);
-bool dumpstate = false;
+bool dumpstate;
MODULE_PARM_DESC(dumpstate, "Dump KMS state on errors");
module_param(dumpstate, bool, 0600);
--
2.20.1
Re: linux-next: build warnings after merge of the drm tree
On Tue, Aug 10, 2021 at 08:38:59PM +1000, Stephen Rothwell wrote: > Hi Daniel, > > On Tue, 10 Aug 2021 12:14:38 +0200 Daniel Vetter wrote: > > > > Matt Auld is on vacation, and the other issue is that the tree where this > > is from isn't in linux-next. So will take a bit to get sorted in > > linux-next. > > Those warnings are now coming from Linus' tree (some time before > v5.14-rc1). I first mentioned them on June 3. Uh that's not good, I missed that. I'll look into it. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH 2/2] gpu/drm: ingenic: Add workaround for disabled drivers
On Tue, Aug 10, 2021 at 12:40:39PM +0200, Paul Cercueil wrote:
> Hi Greg,
>
> Le mar., août 10 2021 at 11:47:32 +0200, Greg Kroah-Hartman
> a écrit :
> > On Fri, Aug 06, 2021 at 01:01:33PM +0200, Paul Cercueil wrote:
> > > Hi Greg,
> > >
> > > Le ven., août 6 2021 at 12:17:55 +0200, Greg Kroah-Hartman
> > > a écrit :
> > > > On Thu, Aug 05, 2021 at 10:05:27PM +0200, Paul Cercueil wrote:
> > > > > Hi Greg,
> > > > >
> > > > > Le jeu., août 5 2021 at 21:35:34 +0200, Greg Kroah-Hartman
> > > > > a écrit :
> > > > > > On Thu, Aug 05, 2021 at 09:21:09PM +0200, Paul Cercueil
> > > wrote:
> > > > > > > When the drivers of remote devices (e.g. HDMI chip) are
> > > > > disabled in
> > > > > > > the
> > > > > > > config, we want the ingenic-drm driver to be able to probe
> > > > > > > nonetheless
> > > > > > > with the other devices (e.g. internal LCD panel) that are
> > > > > enabled.
> > > > > > >
> > > > > > > Signed-off-by: Paul Cercueil
> > > > > > > ---
> > > > > > > drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 12
> > >
> > > > > > > 1 file changed, 12 insertions(+)
> > > > > > >
> > > > > > > diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> > > > > > > b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> > > > > > > index d261f7a03b18..5e1fdbb0ba6b 100644
> > > > > > > --- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> > > > > > > +++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> > > > > > > @@ -1058,6 +1058,18 @@ static int ingenic_drm_bind(struct
> > > > > device
> > > > > > > *dev, bool has_components)
> > > > > > > for (i = 0; ; i++) {
> > > > > > > ret = drm_of_find_panel_or_bridge(dev->of_node,
> > > 0, i,
> > > > > &panel,
> > > > > > > &bridge);
> > > > > > > if (ret) {
> > > > > > > + /*
> > > > > > > + * Workaround for the case where the
> > > drivers for the
> > > > > > > + * remote devices are not enabled. When
> > > that happens,
> > > > > > > + * drm_of_find_panel_or_bridge()
> > > returns -EPROBE_DEFER
> > > > > > > + * endlessly, which prevents the
> > > ingenic-drm driver
> > > from
> > > > > > > + * working at all.
> > > > > > > + */
> > > > > > > + if (ret == -EPROBE_DEFER) {
> > > > > > > + ret =
> > > driver_deferred_probe_check_state(dev);
> > > > > > > + if (ret == -ENODEV || ret ==
> > > -ETIMEDOUT)
> > > > > > > + continue;
> > > > > > > + }
> > > > > >
> > > > > > So you are mucking around with devices on other busses
> > > within this
> > > > > > driver? What could go wrong? :(
> > > > >
> > > > > I'm doing the same thing as everybody else. This is the DRM
> > > driver,
> > > > > and
> > > > > there is a driver for the external HDMI chip which gives us a
> > > DRM
> > > > > bridge
> > > > > that we can obtain from the device tree.
> > > >
> > > > But then why do you need to call this function that is there for
> > > a bus,
> > > > not for a driver.
> > >
> > > The documentation disagrees with you :)
> > >
> > > And, if that has any weight, this solution was proposed by Rob.
> > >
> > > > > > Please use the existing driver core functionality for this
> > > type of
> > > > > > thing, it is not unique, no need for this function to be
> > > called.
> > > > >
> > > > > I'm not sure you understand what I'm doing here. This driver
> > > calls
> > > > > drm_of_find_panel_or_bridge(), without guarantee that the
> > > driver
> > > > > for the
> > > > > remote device (connected via DT graph) has been enabled in the
> > > > > kernel
> > > > > config. In that case it will always return -EPROBE_DEFER and
> > > the
> > > > > ingenic-drm
> > > > > driver will never probe.
> > > > >
> > > > > This patch makes sure that the driver can probe if the HDMI
> > > driver
> > > > > has been
> > > > > disabled in the kernel config, nothing more.
> > > >
> > > > That should not be an issue as you do not care if the config is
> > > enabled,
> > > > you just want to do something in the future if the driver shows
> > > up,
> > > > right?
> > >
> > > Well, the DRM subsystem doesn't really seem to handle hotplug of
> > > hardware.
> > > Right now all the drivers for the connected hardware need to probe
> > > before
> > > the main DRM driver. So I need to know that a remote device
> > > (connected via
> > > DT graph) will never probe.
> >
> > But you never really know that. That is what the recent driver core
> > changes were all about, to handle this very issue. Only when the child
> > device shows up will you need to care about it.
> >
> > > Give me a of_graph_remote_device_driver_will_never_pr
Re: [RFC v1 0/4] drm: Add support for DRM_CAP_DEFERRED_OUT_FENCE capability
On 2021-08-10 10:30 a.m., Daniel Vetter wrote: > On Tue, Aug 10, 2021 at 08:21:09AM +, Kasireddy, Vivek wrote: >>> On Fri, Aug 06, 2021 at 07:27:13AM +, Kasireddy, Vivek wrote: >>> >>> Hence my gut feeling reaction that first we need to get these two >>> compositors aligned in their timings, which propobably needs >>> consistent vblank periods/timestamps across them (plus/minux >>> guest/host clocksource fun ofc). Without this any of the next steps >>> will simply not work because there's too much jitter by the time the >>> guest compositor gets the flip completion events. >> [Kasireddy, Vivek] Timings are not a problem and do not significantly >> affect the repaint cycles from what I have seen so far. >> >>> >>> Once we have solid events I think we should look into statically >>> tuning guest/host compositor deadlines (like you've suggested in a >>> bunch of places) to consisently make that deadline and hit 60 fps. >>> With that we can then look into tuning this automatically and what to >>> do when e.g. switching between copying and zero-copy on the host side >>> (which might be needed in some cases) and how to handle all that. >> [Kasireddy, Vivek] As I confirm here: >>> https://gitlab.freedesktop.org/wayland/weston/- > /issues/514#note_984065 >> tweaking the deadlines works (i.e., we get 60 FPS) as we expect. However, >> I feel that this zero-copy solution I am trying to create should be >> independent >> of compositors' deadlines, delays or other scheduling parameters. > > That's not how compositors work nowadays. Your problem is that you don't > have the guest/host compositor in sync. zero-copy only changes the timing, > so it changes things from "rendering way too many frames" to "rendering > way too few frames". > > We need to fix the timing/sync issue here first, not paper over it with > hacks. [Kasireddy, Vivek] What I really meant is that the zero-copy solution should be independent of the scheduling policies to ensure that it works with all compositors. IIUC, Weston for example uses the vblank/pageflip completion timestamp, the configurable repaint-window value, refresh-rate, etc to determine when to start its next repaint -- if there is any damage: timespec_add_nsec(&output->next_repaint, stamp, refresh_nsec); timespec_add_msec(&output->next_repaint, &output->next_repaint, -compositor- repaint_msec); And, in the case of VKMS, since there is no real hardware, the timestamp is always: now = ktime_get(); send_vblank_event(dev, e, seq, now); >>> >>> vkms has been fixed since a while to fake high-precision timestamps like >>> from a real display. >> [Kasireddy, Vivek] IIUC, that might be one of the reasons why the Guest does >> not need >> to have the same timestamp as that of the Host -- to work as expected. >> >>> When you say that the Guest/Host compositor need to stay in sync, are you suggesting that we need to ensure that the vblank timestamp on the Host needs to be shared and be the same on the Guest and a vblank/pageflip completion for the Guest needs to be sent at exactly the same time it is sent on the Host? If yes, I'd say that we do send the pageflip completion to Guest around the same time a vblank is generated on the Host but it does not help because the Guest compositor would only have 9 ms to submit a new frame and if the Host is running Mutter, the Guest would only have 2 ms. (https://gitlab.freedesktop.org/wayland/weston/-/issues/514#note_984341) >>> >>> Not at the same time, but the same timestamp. And yes there is some fun >>> there, which is I think the fundamental issue. Or at least some of the >>> compositor experts seem to think so, and it makes sense to me. >> [Kasireddy, Vivek] It is definitely possible that if the timestamp is messed >> up, then >> the Guest repaint cycle would be affected. However, I do not believe that is >> the case >> here given the debug and instrumentation data we collected and scrutinized. >> Hopefully, >> compositor experts could chime in to shed some light on this matter. >> >>> > > Only, and I really mean only, when that shows that it's simply impossible > to hit 60fps with zero-copy and the guest/host fully aligned should we > look into making the overall pipeline deeper. [Kasireddy, Vivek] From all the experiments conducted so far and given the discussion associated with https://gitlab.freedesktop.org/wayland/weston/-/issues/514 I think we have already established that in order for a zero-copy solution to work reliably, the Guest compositor needs to start its repaint cycle when the Host compositor sends a frame callback event to its clients. > >>> Only when that all shows that we just ca
Re: [PATCH 2/2] gpu/drm: ingenic: Add workaround for disabled drivers
On Tue, Aug 10, 2021 at 12:33:04PM +0200, Paul Cercueil wrote:
> Hi Daniel,
>
> Le mar., août 10 2021 at 11:35:43 +0200, Daniel Vetter a
> écrit :
> > On Fri, Aug 06, 2021 at 01:01:33PM +0200, Paul Cercueil wrote:
> > > Hi Greg,
> > >
> > > Le ven., août 6 2021 at 12:17:55 +0200, Greg Kroah-Hartman
> > > a écrit :
> > > > On Thu, Aug 05, 2021 at 10:05:27PM +0200, Paul Cercueil wrote:
> > > > > Hi Greg,
> > > > >
> > > > > Le jeu., août 5 2021 at 21:35:34 +0200, Greg Kroah-Hartman
> > > > > a écrit :
> > > > > > On Thu, Aug 05, 2021 at 09:21:09PM +0200, Paul Cercueil
> > > wrote:
> > > > > > > When the drivers of remote devices (e.g. HDMI chip) are
> > > > > disabled in
> > > > > > > the
> > > > > > > config, we want the ingenic-drm driver to be able to probe
> > > > > > > nonetheless
> > > > > > > with the other devices (e.g. internal LCD panel) that are
> > > > > enabled.
> > > > > > >
> > > > > > > Signed-off-by: Paul Cercueil
> > > > > > > ---
> > > > > > > drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 12
> > >
> > > > > > > 1 file changed, 12 insertions(+)
> > > > > > >
> > > > > > > diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> > > > > > > b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> > > > > > > index d261f7a03b18..5e1fdbb0ba6b 100644
> > > > > > > --- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> > > > > > > +++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> > > > > > > @@ -1058,6 +1058,18 @@ static int ingenic_drm_bind(struct
> > > > > device
> > > > > > > *dev, bool has_components)
> > > > > > > for (i = 0; ; i++) {
> > > > > > > ret = drm_of_find_panel_or_bridge(dev->of_node,
> > > 0, i,
> > > > > &panel,
> > > > > > > &bridge);
> > > > > > > if (ret) {
> > > > > > > + /*
> > > > > > > + * Workaround for the case where the
> > > drivers for the
> > > > > > > + * remote devices are not enabled. When
> > > that happens,
> > > > > > > + * drm_of_find_panel_or_bridge()
> > > returns -EPROBE_DEFER
> > > > > > > + * endlessly, which prevents the
> > > ingenic-drm driver
> > > from
> > > > > > > + * working at all.
> > > > > > > + */
> > > > > > > + if (ret == -EPROBE_DEFER) {
> > > > > > > + ret =
> > > driver_deferred_probe_check_state(dev);
> > > > > > > + if (ret == -ENODEV || ret ==
> > > -ETIMEDOUT)
> > > > > > > + continue;
> > > > > > > + }
> > > > > >
> > > > > > So you are mucking around with devices on other busses
> > > within this
> > > > > > driver? What could go wrong? :(
> > > > >
> > > > > I'm doing the same thing as everybody else. This is the DRM
> > > driver,
> > > > > and
> > > > > there is a driver for the external HDMI chip which gives us a
> > > DRM
> > > > > bridge
> > > > > that we can obtain from the device tree.
> > > >
> > > > But then why do you need to call this function that is there for
> > > a bus,
> > > > not for a driver.
> > >
> > > The documentation disagrees with you :)
> > >
> > > And, if that has any weight, this solution was proposed by Rob.
> > >
> > > > > > Please use the existing driver core functionality for this
> > > type of
> > > > > > thing, it is not unique, no need for this function to be
> > > called.
> > > > >
> > > > > I'm not sure you understand what I'm doing here. This driver
> > > calls
> > > > > drm_of_find_panel_or_bridge(), without guarantee that the
> > > driver
> > > > > for the
> > > > > remote device (connected via DT graph) has been enabled in the
> > > > > kernel
> > > > > config. In that case it will always return -EPROBE_DEFER and
> > > the
> > > > > ingenic-drm
> > > > > driver will never probe.
> > > > >
> > > > > This patch makes sure that the driver can probe if the HDMI
> > > driver
> > > > > has been
> > > > > disabled in the kernel config, nothing more.
> > > >
> > > > That should not be an issue as you do not care if the config is
> > > enabled,
> > > > you just want to do something in the future if the driver shows
> > > up,
> > > > right?
> > >
> > > Well, the DRM subsystem doesn't really seem to handle hotplug of
> > > hardware.
> > > Right now all the drivers for the connected hardware need to probe
> > > before
> > > the main DRM driver. So I need to know that a remote device
> > > (connected via
> > > DT graph) will never probe.
> > >
> > > Give me a of_graph_remote_device_driver_will_never_probe() and I'll
> > > use
> > > that.
> > >
> > > > Much like the device link code, have you looked at that?
> > >
> > > I don't see how that would help in any way. The device link code
> > > would allow
Re: linux-next: build warnings after merge of the drm tree
Hi Daniel, On Tue, 10 Aug 2021 12:50:55 +0200 Daniel Vetter wrote: > > Uh that's not good, I missed that. I'll look into it. Thanks. -- Cheers, Stephen Rothwell pgpp4QKBUEKCV.pgp Description: OpenPGP digital signature
Re: [PATCH v2] drm/drv: Remove initialization of static variables
Thanks for you advice, and I modify the patch according to your suggestions.
在 2021/8/10 下午5:59, Daniel Vetter 写道:
On Fri, Aug 06, 2021 at 10:30:47AM +0800, zhaoxiao wrote:
Address the following checkpatch errors:
ERROR: do not initialise statics to false
FILE: :drivers/gpu/drm/msm/msm_drv.c:21:
-static bool reglog = false;
FILE: :drivers/gpu/drm/msm/msm_drv.c:31:
-bool dumpstate = false;
Signed-off-by: zhaoxiao
Subject should start out with drm/msm, not drm/drv - that would indicate a
patch touching the drm_drv.c core files, or things related to that.
-Daniel
---
v2: change the patch description
drivers/gpu/drm/msm/msm_drv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 9b8fa2ad0d84..d9ca4bc9620b 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -59,7 +59,7 @@ static const struct drm_mode_config_helper_funcs
mode_config_helper_funcs = {
};
#ifdef CONFIG_DRM_MSM_REGISTER_LOGGING
-static bool reglog = false;
+static bool reglog;
MODULE_PARM_DESC(reglog, "Enable register read/write logging");
module_param(reglog, bool, 0600);
#else
@@ -76,7 +76,7 @@ static char *vram = "16m";
MODULE_PARM_DESC(vram, "Configure VRAM size (for devices without
IOMMU/GPUMMU)");
module_param(vram, charp, 0);
-bool dumpstate = false;
+bool dumpstate;
MODULE_PARM_DESC(dumpstate, "Dump KMS state on errors");
module_param(dumpstate, bool, 0600);
--
2.20.1
Re: Proposal for allowing more Nouveau contributors to merge patches
On Tue, Aug 10, 2021 at 12:11 PM Daniel Vetter wrote: > > On Fri, Aug 06, 2021 at 06:53:06PM +0200, Karol Herbst wrote: > > Hey everybody, > > > > so, here is a proposal of what we could change in order to allow > > patches to land faster, more reliably and to increase the overall bus > > factor in terms of nouveau kernel maintenance. > > Yay! > > > But let's start with the current situation: > > > > At the moment contributors have to send patches to the nouveau mailing > > list in order to submit them for inclusion into Bens nouveau tree. > > Then Ben has to look at them and either respond with a comment on what > > needs to change or merge it. At some point Ben submits all new changes > > to nouveau for inclusion into the drm-next tree. > > > > Practically there are a few problems here: > > 1. Not all patch submissions get a response > > 2. Patch submitters usually don't get to know if their patches are > > accepted unless they appear in drm-next or linus' tree. > > 3. A lot of trivial patches never make it into the tree. > > 4. Depending on how overloaded Ben is, even bigger patch series adding > > new features never get any responses at all. > > 5. Patch series might get stale for any other reason and there is no > > good tool to track open patch submissions (no, patchwork isn't good > > and it sucks and not even in the mood to explain this to people > > thinking otherwise as this should just be obvious) > > > > This usually ends up discouraging new contributors from making more > > contributions to nouveau as they see that some or all of their patches > > never get any reaction and it's even annoying to current contributors > > if they see their patches being stuck as well. > > > > And here I want to stress that none of this is Ben's fault and has his > > own things to work on and none of this should just depend on one > > person finding enough time. So the solution shouldn't be a simple > > "let's find a different tool and everything should be perfect" but the > > solution should be "how can we change the process so it's less time > > consuming for Ben to accept patches". And while working on this, I'd > > also want to tackle the problem that contributing to nouveau shouldn't > > be frustrating for new contributors and the process should be more > > lively overall. > > > > So for this I want to propose a new workflow, which would also spread > > some responsibilities around active members of the nouveau community: > > > > 1. We should have a public nouveau tree (which could be > > https://gitlab.freedesktop.org/drm/nouveau or something else) with a > > nouveau-next branch collecting all patches for the next kernel major > > kernel release. > > At the moment the "official" nouveau tree is kind of > > https://github.com/skeggsb/nouveau but there is > > https://github.com/skeggsb/linux as well. The main problem is, it's a > > repository tight to a person. We already have > > https://gitlab.freedesktop.org/drm/nouveau as a bug tracker, but it > > also contains a full linux git tree which is updated automatically > > through a CI job. > > > > 2. A chosen group of people should have push rights to this repository > > in order to accept patches sent in via emails to the nouveau Mailing > > List or fancy UIs (like gitlabs MRs) or other ways. > > Trusted contributors should be allowed to review and accept submitted > > patches in order to reduce the workload on Ben. Those patches will be > > collected on the nouveau-next branch. Patches from a mailing list > > could e.g. be submitted through a MR on gitlab or just pushed to the > > branch directly. > > > > 3. We should ensure through CI that submitted patches are at least > > passing basic quality control (checkpatch, compile testing, sparse, > > etc...) > > I already worked on this and one example can be seen here: > > https://gitlab.freedesktop.org/drm/nouveau/-/merge_requests/3 > > There are more things we could add to it, like checking if sparse is > > happy or add additional checks. Adding tests against hw is something > > we want to target for the future as well. > > > > 4. patches from nouveau-next should be included into a "higher" git > > tree (drm-next or drm-misc-next) by authorized people after getting a > > final review by Ben or somebody else. > > The idea is to post all collected patches for final review to the > > mailing list as Ben wanted to have a final possibility to nack it in > > case something stands out. We could then depend on Ben including those > > patches, but we could also use commit rights to drm-next or > > drm-misc-next from other people as well. I have commit access to the > > drm-misc repository, and I would assume that Lyude would be able to > > get it as well or already has it. > > Hm I'm not sure that double-indirect makes a lot of sense. There's imo two > reasonable models here: > > - commit rights on drm/nouveau, Ben sends out the pull requests to > drm-next for those, which gives him a good point to check over and do
Re: [PATCH v8] drm/bridge: add it6505 driver
On Tue, Aug 10, 2021 at 7:31 PM allen wrote:
>
> This adds support for the iTE IT6505.
> This device can convert DPI signal to DP output.
>
> From: Allen Chen
> Tested-by: Hsin-yi Wang
> Signed-off-by: Hermes Wu
> Signed-off-by: Allen Chen
>
--- <-- Add this line next time.
Add the change logs below this line so that they're not mixed with
commit messages.
> v7->v8:
> fixed "checkpatch --strict" error
> remove unused variable *edid
> remove mode_set() callback
> Documenting the individual bits of the interrupt mask values
> change it6505_dpcd_write parameter from unsigned long to u8
>
> This patch depends on
> https://patchwork.kernel.org/project/linux-mediatek/patch/20210722062246.2512666-4-...@ravnborg.org/
> ---
> drivers/gpu/drm/bridge/Kconfig |8 +
> drivers/gpu/drm/bridge/Makefile |1 +
> drivers/gpu/drm/bridge/ite-it6505.c | +++
> 3 files changed, 3342 insertions(+)
> create mode 100644 drivers/gpu/drm/bridge/ite-it6505.c
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 431b6e12a81fe..e1afe171075f5 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -74,6 +74,14 @@ config DRM_DISPLAY_CONNECTOR
> on ARM-based platforms. Saying Y here when this driver is not needed
> will not cause any issue.
>
> +
> + /* Register aux channel */
> + it6505->aux.name = "DP-AUX";
> + it6505->aux.dev = dev;
> + it6505->aux.transfer = it6505_aux_transfer;
> +
> + err = drm_dp_aux_register(&it6505->aux);
drm_dp_aux_register() checks if aux->drm_dev is null. Assign this
otherwise you'll see warnings.
> + if (err < 0) {
> + dev_err(dev, "Failed to register aux: %d", err);
> + return err;
> + }
Re: [Intel-gfx] [PATCH] drm/i915/gem/ttm: prefer kernel types
On Tue, 10 Aug 2021, Daniel Vetter wrote:
> On Tue, Aug 10, 2021 at 11:41:28AM +0300, Jani Nikula wrote:
>> Avoid uintXX_t types in the driver.
>>
>> Fixes: 213d50927763 ("drm/i915/ttm: Introduce a TTM i915 gem object backend")
>> Cc: Thomas Hellström
>> Cc: Matthew Auld
>> Cc: Maarten Lankhorst
>> Signed-off-by: Jani Nikula
>> ---
>> drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
>> b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
>> index 771eb2963123..ffda88156e32 100644
>> --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
>> @@ -168,7 +168,7 @@ i915_ttm_placement_from_obj(const struct
>> drm_i915_gem_object *obj,
>> }
>>
>> static struct ttm_tt *i915_ttm_tt_create(struct ttm_buffer_object *bo,
>> - uint32_t page_flags)
>> + u32 page_flags)
>
> It's for the ttm_device_funcs ops table, I thinhk we should fix it there
> and across the board?
>
> Otherwise a bit ocd mismatch :-)
Well, the above is the only uintXX_t reference in i915.
BR,
Jani.
> -Daniel
>
>> {
>> struct ttm_resource_manager *man =
>> ttm_manager_type(bo->bdev, bo->resource->mem_type);
>> --
>> 2.20.1
>>
--
Jani Nikula, Intel Open Source Graphics Center
Re: linux-next: manual merge of the drm tree with the drm-fixes tree
Hi Mark, Stephen,
On Fri, Aug 6, 2021 at 6:11 PM Mark Brown wrote:
> Today's linux-next merge of the drm tree got a conflict in:
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
>
> between commit:
>
> e00f543d3596 ("drm/amdgpu: add DID for beige goby")
>
> from the drm-fixes tree and commit:
>
> a8f706966b92 ("drm/amdgpu: add pci device id for cyan_skillfish")
>
> from the drm tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
>
> diff --cc drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> index 5ed8381ae0f5,d637b0536f84..
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> @@@ -1213,13 -1212,9 +1212,16 @@@ static const struct pci_device_id pciid
> {0x1002, 0x740F, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
> CHIP_ALDEBARAN|AMD_EXP_HW_SUPPORT},
> {0x1002, 0x7410, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
> CHIP_ALDEBARAN|AMD_EXP_HW_SUPPORT},
>
> + /* BEIGE_GOBY */
> + {0x1002, 0x7420, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_BEIGE_GOBY},
> + {0x1002, 0x7421, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_BEIGE_GOBY},
> + {0x1002, 0x7422, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_BEIGE_GOBY},
> + {0x1002, 0x7423, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_BEIGE_GOBY},
> + {0x1002, 0x743F, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_BEIGE_GOBY},
> +
> + /* CYAN_SKILLFISH */
> + {0x1002, 0x13FE, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
> CHIP_CYAN_SKILLFISH|AMD_IS_APU},
> +
> {0, 0, 0}
> };
next-20210806 and later have a different resolution, duplicating the
BEIGE_GOBY entries before and after the CYAN_SKILLFISH entry.
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 2/2] gpu/drm: ingenic: Add workaround for disabled drivers
Hi Daniel,
Le mar., août 10 2021 at 12:59:53 +0200, Daniel Vetter
a écrit :
On Tue, Aug 10, 2021 at 12:33:04PM +0200, Paul Cercueil wrote:
Hi Daniel,
Le mar., août 10 2021 at 11:35:43 +0200, Daniel Vetter
a
écrit :
> On Fri, Aug 06, 2021 at 01:01:33PM +0200, Paul Cercueil wrote:
> > Hi Greg,
> >
> > Le ven., août 6 2021 at 12:17:55 +0200, Greg Kroah-Hartman
> > a écrit :
> > > On Thu, Aug 05, 2021 at 10:05:27PM +0200, Paul Cercueil
wrote:
> > > > Hi Greg,
> > > >
> > > > Le jeu., août 5 2021 at 21:35:34 +0200, Greg
Kroah-Hartman
> > > > a écrit :
> > > > > On Thu, Aug 05, 2021 at 09:21:09PM +0200, Paul Cercueil
> > wrote:
> > > > > > When the drivers of remote devices (e.g. HDMI chip)
are
> > > > disabled in
> > > > > > the
> > > > > > config, we want the ingenic-drm driver to be able to
probe
> > > > > > nonetheless
> > > > > > with the other devices (e.g. internal LCD panel)
that are
> > > > enabled.
> > > > > >
> > > > > > Signed-off-by: Paul Cercueil
> > > > > > ---
> > > > > > drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 12
> >
> > > > > > 1 file changed, 12 insertions(+)
> > > > > >
> > > > > > diff --git
a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> > > > > > b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> > > > > > index d261f7a03b18..5e1fdbb0ba6b 100644
> > > > > > --- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> > > > > > +++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> > > > > > @@ -1058,6 +1058,18 @@ static int
ingenic_drm_bind(struct
> > > > device
> > > > > > *dev, bool has_components)
> > > > > >for (i = 0; ; i++) {
> > > > > > ret = drm_of_find_panel_or_bridge(dev->of_node,
0, i,
> > > > &panel,
> > > > > > &bridge);
> > > > > >if (ret) {
> > > > > > + /*
> > > > > > + * Workaround for the case where the drivers for
the
> > > > > > + * remote devices are not enabled. When that
happens,
> > > > > > + * drm_of_find_panel_or_bridge() returns
-EPROBE_DEFER
> > > > > > + * endlessly, which prevents the ingenic-drm
driver
> > from
> > > > > > + * working at all.
> > > > > > + */
> > > > > > + if (ret == -EPROBE_DEFER) {
> > > > > > + ret =
driver_deferred_probe_check_state(dev);
> > > > > > + if (ret == -ENODEV || ret ==
-ETIMEDOUT)
> > > > > > + continue;
> > > > > > + }
> > > > >
> > > > > So you are mucking around with devices on other busses
> > within this
> > > > > driver? What could go wrong? :(
> > > >
> > > > I'm doing the same thing as everybody else. This is the
DRM
> > driver,
> > > > and
> > > > there is a driver for the external HDMI chip which gives
us a
> > DRM
> > > > bridge
> > > > that we can obtain from the device tree.
> > >
> > > But then why do you need to call this function that is there
for
> > a bus,
> > > not for a driver.
> >
> > The documentation disagrees with you :)
> >
> > And, if that has any weight, this solution was proposed by Rob.
> >
> > > > > Please use the existing driver core functionality for
this
> > type of
> > > > > thing, it is not unique, no need for this function to be
> > called.
> > > >
> > > > I'm not sure you understand what I'm doing here. This
driver
> > calls
> > > > drm_of_find_panel_or_bridge(), without guarantee that the
> > driver
> > > > for the
> > > > remote device (connected via DT graph) has been enabled
in the
> > > > kernel
> > > > config. In that case it will always return -EPROBE_DEFER
and
> > the
> > > > ingenic-drm
> > > > driver will never probe.
> > > >
> > > > This patch makes sure that the driver can probe if the
HDMI
> > driver
> > > > has been
> > > > disabled in the kernel config, nothing more.
> > >
> > > That should not be an issue as you do not care if the config
is
> > enabled,
> > > you just want to do something in the future if the driver
shows
> > up,
> > > right?
> >
> > Well, the DRM subsystem doesn't really seem to handle hotplug
of
> > hardware.
> > Right now all the drivers for the connected hardware need to
probe
> > before
> > the main DRM driver. So I need to know that a remote device
> > (connected via
> > DT graph) will never probe.
> >
> > Give me a of_graph_remote_device_driver_will_never_probe() and
I'll
> > use
> > that.
> >
> > > Much like the device link code, have you looked at that?
> >
> > I don't see how that would help in any way. The device link
code
> > would allow
> > me to set a dependency between the remote hardware (HDMI chip,
> > provider) and
> > the LCD controller (consumer), but I already ha
Re: linux-next: build failure after merge of the driver-core tree
On Fri, Jul 23, 2021 at 7:35 AM Uwe Kleine-König
wrote:
> On Fri, Jul 23, 2021 at 03:09:44PM +1000, Stephen Rothwell wrote:
> > After merging the driver-core tree, today's linux-next build (arm
> > multi_v7_defconfig) failed like this:
> >
> > drivers/gpu/drm/drm_dp_aux_bus.c:106:13: error: initialization of 'void
> > (*)(struct device *)' from incompatible pointer type 'int (*)(struct device
> > *)' [-Werror=incompatible-pointer-types]
> > 106 | .remove = dp_aux_ep_remove,
> > | ^~~~
> > drivers/gpu/drm/drm_dp_aux_bus.c:106:13: note: (near initialization for
> > 'dp_aux_bus_type.remove')
> >
> > Caused by commit
> >
> > aeb33699fc2c ("drm: Introduce the DP AUX bus")
> >
> > from the drm tree interacting with commit
> >
> > fc7a6209d571 ("bus: Make remove callback return void")
> >
> > from the driver-core tree.
> >
> > I applied the following merge fix patch.
> >
> > From: Stephen Rothwell
> > Date: Fri, 23 Jul 2021 14:58:25 +1000
> > Subject: [PATCH] fix for "drm: Introduce the DP AUX bus"
> >
> > interaction with "bus: Make remove callback return void"
> >
> > Signed-off-by: Stephen Rothwell
> > ---
> > drivers/gpu/drm/drm_dp_aux_bus.c | 5 +
> > 1 file changed, 1 insertion(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_aux_bus.c
> > b/drivers/gpu/drm/drm_dp_aux_bus.c
> > index e49a70f3691b..298ea7a49591 100644
> > --- a/drivers/gpu/drm/drm_dp_aux_bus.c
> > +++ b/drivers/gpu/drm/drm_dp_aux_bus.c
> > @@ -67,9 +67,8 @@ static int dp_aux_ep_probe(struct device *dev)
> > *
> > * Calls through to the endpoint driver remove.
> > *
> > - * Return: 0 if no error or negative error code.
> > */
> > -static int dp_aux_ep_remove(struct device *dev)
> > +static void dp_aux_ep_remove(struct device *dev)
> > {
> > struct dp_aux_ep_driver *aux_ep_drv = to_dp_aux_ep_drv(dev->driver);
> > struct dp_aux_ep_device *aux_ep = to_dp_aux_ep_dev(dev);
> > @@ -77,8 +76,6 @@ static int dp_aux_ep_remove(struct device *dev)
> > if (aux_ep_drv->remove)
> > aux_ep_drv->remove(aux_ep);
> > dev_pm_domain_detach(dev, true);
> > -
> > - return 0;
> > }
>
> This looks right.
>
> Greg provided a tag containing fc7a6209d571 ("bus: Make remove callback
> return void") at
>
> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
> tags/bus_remove_return_void-5.15
>
> (see https://lore.kernel.org/lkml/ypkwqwf0dukng...@kroah.com).
>
> It would be great if this could be merged into the drm tree with the
> above diff squashed into the merge commit.
+1.
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: Proposal for allowing more Nouveau contributors to merge patches
On Tue, Aug 10, 2021 at 01:38:27PM +0200, Karol Herbst wrote: > On Tue, Aug 10, 2021 at 12:11 PM Daniel Vetter wrote: > > > > On Fri, Aug 06, 2021 at 06:53:06PM +0200, Karol Herbst wrote: > > > Hey everybody, > > > > > > so, here is a proposal of what we could change in order to allow > > > patches to land faster, more reliably and to increase the overall bus > > > factor in terms of nouveau kernel maintenance. > > > > Yay! > > > > > But let's start with the current situation: > > > > > > At the moment contributors have to send patches to the nouveau mailing > > > list in order to submit them for inclusion into Bens nouveau tree. > > > Then Ben has to look at them and either respond with a comment on what > > > needs to change or merge it. At some point Ben submits all new changes > > > to nouveau for inclusion into the drm-next tree. > > > > > > Practically there are a few problems here: > > > 1. Not all patch submissions get a response > > > 2. Patch submitters usually don't get to know if their patches are > > > accepted unless they appear in drm-next or linus' tree. > > > 3. A lot of trivial patches never make it into the tree. > > > 4. Depending on how overloaded Ben is, even bigger patch series adding > > > new features never get any responses at all. > > > 5. Patch series might get stale for any other reason and there is no > > > good tool to track open patch submissions (no, patchwork isn't good > > > and it sucks and not even in the mood to explain this to people > > > thinking otherwise as this should just be obvious) > > > > > > This usually ends up discouraging new contributors from making more > > > contributions to nouveau as they see that some or all of their patches > > > never get any reaction and it's even annoying to current contributors > > > if they see their patches being stuck as well. > > > > > > And here I want to stress that none of this is Ben's fault and has his > > > own things to work on and none of this should just depend on one > > > person finding enough time. So the solution shouldn't be a simple > > > "let's find a different tool and everything should be perfect" but the > > > solution should be "how can we change the process so it's less time > > > consuming for Ben to accept patches". And while working on this, I'd > > > also want to tackle the problem that contributing to nouveau shouldn't > > > be frustrating for new contributors and the process should be more > > > lively overall. > > > > > > So for this I want to propose a new workflow, which would also spread > > > some responsibilities around active members of the nouveau community: > > > > > > 1. We should have a public nouveau tree (which could be > > > https://gitlab.freedesktop.org/drm/nouveau or something else) with a > > > nouveau-next branch collecting all patches for the next kernel major > > > kernel release. > > > At the moment the "official" nouveau tree is kind of > > > https://github.com/skeggsb/nouveau but there is > > > https://github.com/skeggsb/linux as well. The main problem is, it's a > > > repository tight to a person. We already have > > > https://gitlab.freedesktop.org/drm/nouveau as a bug tracker, but it > > > also contains a full linux git tree which is updated automatically > > > through a CI job. > > > > > > 2. A chosen group of people should have push rights to this repository > > > in order to accept patches sent in via emails to the nouveau Mailing > > > List or fancy UIs (like gitlabs MRs) or other ways. > > > Trusted contributors should be allowed to review and accept submitted > > > patches in order to reduce the workload on Ben. Those patches will be > > > collected on the nouveau-next branch. Patches from a mailing list > > > could e.g. be submitted through a MR on gitlab or just pushed to the > > > branch directly. > > > > > > 3. We should ensure through CI that submitted patches are at least > > > passing basic quality control (checkpatch, compile testing, sparse, > > > etc...) > > > I already worked on this and one example can be seen here: > > > https://gitlab.freedesktop.org/drm/nouveau/-/merge_requests/3 > > > There are more things we could add to it, like checking if sparse is > > > happy or add additional checks. Adding tests against hw is something > > > we want to target for the future as well. > > > > > > 4. patches from nouveau-next should be included into a "higher" git > > > tree (drm-next or drm-misc-next) by authorized people after getting a > > > final review by Ben or somebody else. > > > The idea is to post all collected patches for final review to the > > > mailing list as Ben wanted to have a final possibility to nack it in > > > case something stands out. We could then depend on Ben including those > > > patches, but we could also use commit rights to drm-next or > > > drm-misc-next from other people as well. I have commit access to the > > > drm-misc repository, and I would assume that Lyude would be able to > > > get it as well or already has it. > > > > H
[PATCH] drm/doc/rfc: drop lmem uapi section
We still have quite a bit more work to do with overall reworking of
the ttm-based dg1 code, but the uapi stuff is now finalized with the
latest pull. So remove that.
This also fixes kerneldoc build warnings because we've included the
same headers in two places, resulting in sphinx complaining about
duplicated symbols. This regression has been created when we moved the
uapi definitions to the real include/uapi/ folder in 727ecd99a4c9
("drm/doc/rfc: drop the i915_gem_lmem.h header")
Reported-by: Stephen Rothwell
Cc: Stephen Rothwell
Fixes: 727ecd99a4c9 ("drm/doc/rfc: drop the i915_gem_lmem.h header")
Cc: Matthew Auld
Signed-off-by: Daniel Vetter
---
Documentation/gpu/rfc/i915_gem_lmem.rst | 107
1 file changed, 107 deletions(-)
diff --git a/Documentation/gpu/rfc/i915_gem_lmem.rst
b/Documentation/gpu/rfc/i915_gem_lmem.rst
index 675ba8620d66..91be041e68cc 100644
--- a/Documentation/gpu/rfc/i915_gem_lmem.rst
+++ b/Documentation/gpu/rfc/i915_gem_lmem.rst
@@ -22,110 +22,3 @@ real, with all the uAPI bits is:
* SET/GET ioctl caching(see `I915 SET/GET CACHING`_)
* Send RFC(with mesa-dev on cc) for final sign off on the uAPI
* Add pciid for DG1 and turn on uAPI for real
-
-New object placement and region query uAPI
-==
-Starting from DG1 we need to give userspace the ability to allocate buffers
from
-device local-memory. Currently the driver supports gem_create, which can place
-buffers in system memory via shmem, and the usual assortment of other
-interfaces, like dumb buffers and userptr.
-
-To support this new capability, while also providing a uAPI which will work
-beyond just DG1, we propose to offer three new bits of uAPI:
-
-DRM_I915_QUERY_MEMORY_REGIONS
--
-New query ID which allows userspace to discover the list of supported memory
-regions(like system-memory and local-memory) for a given device. We identify
-each region with a class and instance pair, which should be unique. The class
-here would be DEVICE or SYSTEM, and the instance would be zero, on platforms
-like DG1.
-
-Side note: The class/instance design is borrowed from our existing engine uAPI,
-where we describe every physical engine in terms of its class, and the
-particular instance, since we can have more than one per class.
-
-In the future we also want to expose more information which can further
-describe the capabilities of a region.
-
-.. kernel-doc:: include/uapi/drm/i915_drm.h
-:functions: drm_i915_gem_memory_class
drm_i915_gem_memory_class_instance drm_i915_memory_region_info
drm_i915_query_memory_regions
-
-GEM_CREATE_EXT
---
-New ioctl which is basically just gem_create but now allows userspace to
provide
-a chain of possible extensions. Note that if we don't provide any extensions
and
-set flags=0 then we get the exact same behaviour as gem_create.
-
-Side note: We also need to support PXP[1] in the near future, which is also
-applicable to integrated platforms, and adds its own gem_create_ext extension,
-which basically lets userspace mark a buffer as "protected".
-
-.. kernel-doc:: include/uapi/drm/i915_drm.h
-:functions: drm_i915_gem_create_ext
-
-I915_GEM_CREATE_EXT_MEMORY_REGIONS
---
-Implemented as an extension for gem_create_ext, we would now allow userspace to
-optionally provide an immutable list of preferred placements at creation time,
-in priority order, for a given buffer object. For the placements we expect
-them each to use the class/instance encoding, as per the output of the regions
-query. Having the list in priority order will be useful in the future when
-placing an object, say during eviction.
-
-.. kernel-doc:: include/uapi/drm/i915_drm.h
-:functions: drm_i915_gem_create_ext_memory_regions
-
-One fair criticism here is that this seems a little over-engineered[2]. If we
-just consider DG1 then yes, a simple gem_create.flags or something is totally
-all that's needed to tell the kernel to allocate the buffer in local-memory or
-whatever. However looking to the future we need uAPI which can also support
-upcoming Xe HP multi-tile architecture in a sane way, where there can be
-multiple local-memory instances for a given device, and so using both class and
-instance in our uAPI to describe regions is desirable, although specifically
-for DG1 it's uninteresting, since we only have a single local-memory instance.
-
-Existing uAPI issues
-
-Some potential issues we still need to resolve.
-
-I915 MMAP
--
-In i915 there are multiple ways to MMAP GEM object, including mapping the same
-object using different mapping types(WC vs WB), i.e multiple active mmaps per
-object. TTM expects one MMAP at most for the lifetime of the object. If it
-turns out that we have to backpedal here, there might be some potential
-userspace fallout.
-
-I915 SET/GET CACHING
-
-In i915 we have set/get_caching ioctl
[PATCH v8] drm/bridge: add it6505 driver
This adds support for the iTE IT6505. This device can convert DPI signal to DP output. From: Allen Chen Tested-by: Hsin-yi Wang Signed-off-by: Hermes Wu Signed-off-by: Allen Chen v7->v8: fixed "checkpatch --strict" error remove unused variable *edid remove mode_set() callback Documenting the individual bits of the interrupt mask values change it6505_dpcd_write parameter from unsigned long to u8 This patch depends on https://patchwork.kernel.org/project/linux-mediatek/patch/20210722062246.2512666-4-...@ravnborg.org/ --- drivers/gpu/drm/bridge/Kconfig |8 + drivers/gpu/drm/bridge/Makefile |1 + drivers/gpu/drm/bridge/ite-it6505.c | +++ 3 files changed, 3342 insertions(+) create mode 100644 drivers/gpu/drm/bridge/ite-it6505.c diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index 431b6e12a81fe..e1afe171075f5 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -74,6 +74,14 @@ config DRM_DISPLAY_CONNECTOR on ARM-based platforms. Saying Y here when this driver is not needed will not cause any issue. +config DRM_ITE_IT6505 +tristate "ITE IT6505 DisplayPort bridge" +depends on OF +select DRM_KMS_HELPER +select EXTCON +help + ITE IT6505 DisplayPort bridge chip driver. + config DRM_LONTIUM_LT8912B tristate "Lontium LT8912B DSI/HDMI bridge" depends on OF diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile index f2c73683cfcb7..425844c304953 100644 --- a/drivers/gpu/drm/bridge/Makefile +++ b/drivers/gpu/drm/bridge/Makefile @@ -4,6 +4,7 @@ obj-$(CONFIG_DRM_CHIPONE_ICN6211) += chipone-icn6211.o obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o obj-$(CONFIG_DRM_CROS_EC_ANX7688) += cros-ec-anx7688.o obj-$(CONFIG_DRM_DISPLAY_CONNECTOR) += display-connector.o +obj-$(CONFIG_DRM_ITE_IT6505) += ite-it6505.o obj-$(CONFIG_DRM_LONTIUM_LT8912B) += lontium-lt8912b.o obj-$(CONFIG_DRM_LONTIUM_LT9611) += lontium-lt9611.o obj-$(CONFIG_DRM_LONTIUM_LT9611UXC) += lontium-lt9611uxc.o diff --git a/drivers/gpu/drm/bridge/ite-it6505.c b/drivers/gpu/drm/bridge/ite-it6505.c new file mode 100644 index 0..27586c3fd5f28 --- /dev/null +++ b/drivers/gpu/drm/bridge/ite-it6505.c @@ -0,0 +1, @@ +// SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +/* + * Copyright (c) 2020, The Linux Foundation. All rights reserved. + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +#define REG_IC_VER 0x04 + +#define REG_RESET_CTRL 0x05 +#define VIDEO_RESET BIT(0) +#define AUDIO_RESET BIT(1) +#define ALL_LOGIC_RESET BIT(2) +#define AUX_RESET BIT(3) +#define HDCP_RESET BIT(4) + +#define INT_STATUS_01 0x06 +#define INT_MASK_01 0x09 +#define INT_HPD_CHANGE 0 +#define INT_RECEIVE_HPD_IRQ 1 +#define INT_SCDT_CHANGE 2 +#define INT_HDCP_FAIL 3 +#define INT_HDCP_DONE 4 +#define BIT_OFFSET(x) (((x) - INT_STATUS_01) * BITS_PER_BYTE) +#define BIT_INT_HPD INT_HPD_CHANGE +#define BIT_INT_HPD_IRQ INT_RECEIVE_HPD_IRQ +#define BIT_INT_SCDT INT_SCDT_CHANGE +#define BIT_INT_HDCP_FAIL INT_HDCP_FAIL +#define BIT_INT_HDCP_DONE INT_HDCP_DONE + +#define INT_STATUS_02 0x07 +#define INT_MASK_02 0x0A +#define INT_AUX_CMD_FAIL 0 +#define INT_HDCP_KSV_CHECK 1 +#define INT_AUDIO_FIFO_ERROR 2 +#define BIT_INT_AUX_CMD_FAIL (BIT_OFFSET(0x07) + INT_AUX_CMD_FAIL) +#define BIT_INT_HDCP_KSV_CHECK (BIT_OFFSET(0x07) + INT_HDCP_KSV_CHECK) +#define BIT_INT_AUDIO_FIFO_ERROR (BIT_OFFSET(0x07) + INT_AUDIO_FIFO_ERROR) + +#define INT_STATUS_03 0x08 +#define INT_MASK_03 0x0B +#define INT_LINK_TRAIN_FAIL 4 +#define INT_VID_FIFO_ERROR 5 +#define INT_IO_LATCH_FIFO_OVERFLOW 7 +#define BIT_INT_LINK_TRAIN_FAIL (BIT_OFFSET(0x08) + INT_LINK_TRAIN_FAIL) +#define BIT_INT_VID_FIFO_ERROR (BIT_OFFSET(0x08) + INT_VID_FIFO_ERROR) +#define BIT_INT_IO_FIFO_OVERFLOW (BIT_OFFSET(0x08) + INT_IO_LATCH_FIFO_OVERFLOW) + +#define REG_SYSTEM_STS 0x0D +#define INT_STS BIT(0) +#define HPD_STS BIT(1) +#define VIDEO_STB BIT(2) + +#define REG_LINK_TRAIN_STS 0x0E +#define LINK_STATE_CR BIT(2) +#define LINK_STATE_EQ BIT(3) +#define LINK_STATE_NORP BIT(4) + +#define REG_BANK_SEL 0x0F +#define REG_CLK_CTRL0 0x10 +#define M_PCLK_DELAY 0x03 + +#define REG_AUX_OPT 0x11 +#define AUX_AUTO_RST BIT(0) +#define AUX_FIX_FREQ BIT(3) + +#define REG_DATA_CTRL0 0x12 +#define VIDEO_LATCH_EDGE BIT(4) +#define ENABLE_PCLK_COUNTER BIT(7) + +#define REG_PCLK_COUNTER_VALUE 0x13 + +#define REG_501_FIFO_CTRL 0x15 +#define RST_501_FIFO BIT(1) + +#define REG_TRAIN_CTRL0 0x16 +#define FORCE_LBR BIT(0) +#define LANE_COUNT_MASK 0x06 +#define LANE_SWAP BIT(3) +#define SPREAD_AMP_5 BIT(4) +#define FORCE_CR_DONE BIT(5) +#define FORCE_EQ_DONE BIT(6) + +#defin
Re: linux-next: build warnings after merge of the drm tree
On Tue, Aug 10, 2021 at 1:01 PM Stephen Rothwell wrote: > Hi Daniel, > > On Tue, 10 Aug 2021 12:50:55 +0200 Daniel Vetter wrote: > > > > Uh that's not good, I missed that. I'll look into it. > > Thanks. Doc build is taking absolutely forever here, but I think I have the right patch for you. t-b/ack would be great if you can give it a spin, I cc'ed you. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH] drivers/firmware: fix sysfb depends to prevent build failures
On Thu, Jul 22, 2021 at 6:42 AM Javier Martinez Canillas wrote: > The Generic System Framebuffers support is built when the COMPILE_TEST > option is enabled. But this wrongly assumes that all the architectures > declare a struct screen_info. > > This is true for most architectures, but at least the following do not: > arc, m68k, microblaze, openrisc, parisc and s390. > > By attempting to make this compile testeable on all architectures, it > leads to linking errors as reported by the kernel test robot for parisc: > > All errors (new ones prefixed by >>): > > hppa-linux-ld: drivers/firmware/sysfb.o: in function `sysfb_init': > (.init.text+0x24): undefined reference to `screen_info' > >> hppa-linux-ld: (.init.text+0x28): undefined reference to `screen_info' > > To prevent these errors only allow sysfb to be built on systems that are > going to need it, which are x86 BIOS and EFI. > > The EFI Kconfig symbol is used instead of (ARM || ARM64 || RISC) because > some of these architectures only declare a struct screen_info if EFI is > enabled. And also, because the sysfb code is only used for EFI on these > architectures. For !EFI the "simple-framebuffer" device is registered by > OF when parsing the Device Tree Blob (if a DT node for this is defined). > > Reported-by: kernel test robot > Signed-off-by: Javier Martinez Canillas Reviewed-by: Linus Walleij I don't know who picks up firmware patches though, I would send them to s...@kernel.org if nothing else works. Yours, Linus Walleij
Re: linux-next: manual merge of the drm tree with the drm-fixes tree
Hi Geert,
On Tue, 10 Aug 2021 13:56:12 +0200 Geert Uytterhoeven
wrote:
>
> On Fri, Aug 6, 2021 at 6:11 PM Mark Brown wrote:
> > Today's linux-next merge of the drm tree got a conflict in:
> >
> > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> >
> > between commit:
> >
> > e00f543d3596 ("drm/amdgpu: add DID for beige goby")
> >
> > from the drm-fixes tree and commit:
> >
> > a8f706966b92 ("drm/amdgpu: add pci device id for cyan_skillfish")
> >
> > from the drm tree.
> >
> >
> > diff --cc drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > index 5ed8381ae0f5,d637b0536f84..
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > @@@ -1213,13 -1212,9 +1212,16 @@@ static const struct pci_device_id pciid
> > {0x1002, 0x740F, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
> > CHIP_ALDEBARAN|AMD_EXP_HW_SUPPORT},
> > {0x1002, 0x7410, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
> > CHIP_ALDEBARAN|AMD_EXP_HW_SUPPORT},
> >
> > + /* BEIGE_GOBY */
> > + {0x1002, 0x7420, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_BEIGE_GOBY},
> > + {0x1002, 0x7421, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_BEIGE_GOBY},
> > + {0x1002, 0x7422, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_BEIGE_GOBY},
> > + {0x1002, 0x7423, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_BEIGE_GOBY},
> > + {0x1002, 0x743F, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_BEIGE_GOBY},
> > +
> > + /* CYAN_SKILLFISH */
> > + {0x1002, 0x13FE, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
> > CHIP_CYAN_SKILLFISH|AMD_IS_APU},
> > +
> > {0, 0, 0}
> > };
>
> next-20210806 and later have a different resolution, duplicating the
> BEIGE_GOBY entries before and after the CYAN_SKILLFISH entry.
That's because commit e00f543d3596 (which is now in Linus' tree) has
been copied (as a separate commit) into the amdgpu tree (where the
CYAN_SKILLFISH change is present, with the BEIGE_GOBY change after
that).
I have dropped the current rerere resolution and will redo the
resolution tomorrow.
--
Cheers,
Stephen Rothwell
pgpANy2A4I1xi.pgp
Description: OpenPGP digital signature
[PATCH] drm/i915: Use locked access to ctx->engines in set_priority
This essentially reverts
commit 89ff76bf9b3b0b86e6bbe344bd6378d8661303fc
Author: Chris Wilson
Date: Thu Apr 2 13:42:18 2020 +0100
drm/i915/gem: Utilize rcu iteration of context engines
Note that the other use of __context_engines_await have disappeard in
the following commits:
ccbc1b97948a ("drm/i915/gem: Don't allow changing the VM on running contexts
(v4)")
c7a71fc8ee04 ("drm/i915: Drop getparam support for I915_CONTEXT_PARAM_ENGINES")
4a766ae40ec8 ("drm/i915: Drop the CONTEXT_CLONE API (v2)")
None of these have any business to optimize their engine lookup with
rcu, unless extremely convincing benchmark data and a solid analysis
why we can't make that workload (whatever it is that does) faster with
a proper design fix.
Also since there's only one caller of context_apply_all left and it's
really just a loop, inline it and then inline the lopp body too. This
is how all other callers that take the engine lock loop over engines,
it's much simpler.
Signed-off-by: Daniel Vetter
Cc: Chris Wilson
Cc: Mika Kuoppala
Cc: Daniel Vetter
Cc: Jason Ekstrand
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
Cc: Matthew Brost
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 72 -
1 file changed, 14 insertions(+), 58 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index dbaeb924a437..fd169cf2f75a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1284,49 +1284,6 @@ static int __context_set_persistence(struct
i915_gem_context *ctx, bool state)
return 0;
}
-static inline struct i915_gem_engines *
-__context_engines_await(const struct i915_gem_context *ctx,
- bool *user_engines)
-{
- struct i915_gem_engines *engines;
-
- rcu_read_lock();
- do {
- engines = rcu_dereference(ctx->engines);
- GEM_BUG_ON(!engines);
-
- if (user_engines)
- *user_engines = i915_gem_context_user_engines(ctx);
-
- /* successful await => strong mb */
- if (unlikely(!i915_sw_fence_await(&engines->fence)))
- continue;
-
- if (likely(engines == rcu_access_pointer(ctx->engines)))
- break;
-
- i915_sw_fence_complete(&engines->fence);
- } while (1);
- rcu_read_unlock();
-
- return engines;
-}
-
-static void
-context_apply_all(struct i915_gem_context *ctx,
- void (*fn)(struct intel_context *ce, void *data),
- void *data)
-{
- struct i915_gem_engines_iter it;
- struct i915_gem_engines *e;
- struct intel_context *ce;
-
- e = __context_engines_await(ctx, NULL);
- for_each_gem_engine(ce, e, it)
- fn(ce, data);
- i915_sw_fence_complete(&e->fence);
-}
-
static struct i915_gem_context *
i915_gem_create_context(struct drm_i915_private *i915,
const struct i915_gem_proto_context *pc)
@@ -1776,23 +1733,11 @@ set_persistence(struct i915_gem_context *ctx,
return __context_set_persistence(ctx, args->value);
}
-static void __apply_priority(struct intel_context *ce, void *arg)
-{
- struct i915_gem_context *ctx = arg;
-
- if (!intel_engine_has_timeslices(ce->engine))
- return;
-
- if (ctx->sched.priority >= I915_PRIORITY_NORMAL &&
- intel_engine_has_semaphores(ce->engine))
- intel_context_set_use_semaphores(ce);
- else
- intel_context_clear_use_semaphores(ce);
-}
-
static int set_priority(struct i915_gem_context *ctx,
const struct drm_i915_gem_context_param *args)
{
+ struct i915_gem_engines_iter it;
+ struct intel_context *ce;
int err;
err = validate_priority(ctx->i915, args);
@@ -1800,7 +1745,18 @@ static int set_priority(struct i915_gem_context *ctx,
return err;
ctx->sched.priority = args->value;
- context_apply_all(ctx, __apply_priority, ctx);
+
+ for_each_gem_engine(ce, i915_gem_context_lock_engines(ctx), it) {
+ if (!intel_engine_has_timeslices(ce->engine))
+ continue;
+
+ if (ctx->sched.priority >= I915_PRIORITY_NORMAL &&
+ intel_engine_has_semaphores(ce->engine))
+ intel_context_set_use_semaphores(ce);
+ else
+ intel_context_clear_use_semaphores(ce);
+ }
+ i915_gem_context_unlock_engines(ctx);
return 0;
}
--
2.32.0
Re: linux-next: build warnings after merge of the drm tree
Hi Daniel, On Tue, 10 Aug 2021 14:39:17 +0200 Daniel Vetter wrote: > > On Tue, Aug 10, 2021 at 1:01 PM Stephen Rothwell > wrote: > > Hi Daniel, > > > > On Tue, 10 Aug 2021 12:50:55 +0200 Daniel Vetter wrote: > > > > > > Uh that's not good, I missed that. I'll look into it. > > > > Thanks. > > Doc build is taking absolutely forever here, but I think I have the > right patch for you. t-b/ack would be great if you can give it a spin, > I cc'ed you. Tested-by Stephen Rothwell Thanks. And, yes, the doc build takes quite some time :-( -- Cheers, Stephen Rothwell pgp3OXjmyA4wJ.pgp Description: OpenPGP digital signature
RE: [PATCH] drm/display: fix possible null-pointer dereference in dcn10_set_clock()
[Public] Thanks for your patch. I suggest moving the check of function pointer dc->clk_mgr->funcs->get_clock earlier, and return early if it's NULL, as if it's NULL, it's meaningless to continue the clock setting. if (!dc->clk_mgr || !dc->clk_mgr->funcs->get_clock) return DC_FAIL_UNSUPPORTED_1; dc->clk_mgr->funcs->get_clock(dc->clk_mgr, context, clock_type, &clock_cfg); Regards, Guchun -Original Message- From: amd-gfx On Behalf Of Tuo Li Sent: Tuesday, August 10, 2021 5:20 PM To: Wentland, Harry ; Li, Sun peng (Leo) ; Deucher, Alexander ; Koenig, Christian ; Pan, Xinhui ; airl...@linux.ie; dan...@ffwll.ch; Cyr, Aric ; Lei, Jun ; Zhuo, Qingqing ; Siqueira, Rodrigo ; Lee, Alvin ; Stempen, Vladimir ; isabel.zh...@amd.com; Lee, Sung ; Po-Yu Hsieh Paul ; Wood, Wyatt Cc: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org; baijiaju1...@gmail.com; Tuo Li ; TOTE Robot Subject: [PATCH] drm/display: fix possible null-pointer dereference in dcn10_set_clock() The variable dc->clk_mgr is checked in: if (dc->clk_mgr && dc->clk_mgr->funcs->get_clock) This indicates dc->clk_mgr can be NULL. However, it is dereferenced in: if (!dc->clk_mgr->funcs->get_clock) To fix this possible null-pointer dereference, check dc->clk_mgr before dereferencing it. Reported-by: TOTE Robot Signed-off-by: Tuo Li --- drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c index c545eddabdcc..3a7c7c7efa68 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c +++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c @@ -3635,7 +3635,7 @@ enum dc_status dcn10_set_clock(struct dc *dc, dc->clk_mgr->funcs->get_clock(dc->clk_mgr, context, clock_type, &clock_cfg); - if (!dc->clk_mgr->funcs->get_clock) + if (dc->clk_mgr && !dc->clk_mgr->funcs->get_clock) return DC_FAIL_UNSUPPORTED_1; if (clk_khz > clock_cfg.max_clock_khz) -- 2.25.1
[PULL] drm-intel-next
Hi Dave & Daniel - drm-intel-next-2021-08-10-1: drm/i915 changes for v5.15: Features: - Basic DG2 platform enabling (Matt, Animesh, Gwan-gyeong, José) - Add PSF GV point support for display bandwidth calculation (Stan) - Add platform release id version support (Lucas) - Add support for forcing DSC BPP for testing (Vandita, Patnana) Refactoring and cleanups: - Remove CNL support completely (Lucas) - Revid/stepping cleanup (Matt, Anusha) - Make display stepping check upper bounds exclusive (Matt) - Remove old GEN macros (Lucas) - Refactor DG1 interrupt handler (Paulo) - Refactor DMC stepping info (Anusha) Fixes: - Fix XELPD color capability reporting; it's not yet enabled (Uma) - Fix DG1 memory bandwidth computation (Clint) - Fix mux on certain HP laptops (Kai-Heng) - Various display workarounds (José, Matt, Imre) - Fix error state dumps wrt SFC_DONE (Matt) - Fix DG1 and XEPLD audio power domains (Anshuman) - Fix ADL-P and ADL-S ddi buf translation tables (Matt) - Fix DP/HDMI modeset sequences causing issues on ADL-P (José) - PSR2 fixes (José) - Fix DP MST modeset with FEC on TGL+ - Fix MBUS DBOX A credits on ADL-P (José) - Fix DP PHY test training set programming (Khaled) - Fix dgfx pcode uncore init done wait (Badal) - Fix DSC disable fuse check on GLK (Lucas) - Fix shared dpll mismatch for bigjoiner secondary pipe (Manasi) - Fix ADL-P underrun recovery (Matt) - Fix permissions on FEC support debugfs file (Vandita) Misc: - Backmerge drm-next (Rodrigo) - Bump RKL and TGL DMC firmware version (Anusha) BR, Jani. The following changes since commit e73f0f0ee7541171d89f2e2491130c7771ba58d3: Linux 5.14-rc1 (2021-07-11 15:07:40 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2021-08-10-1 for you to fetch changes up to 3bfa7d40ce736ffbbfe07127061f54b359ee2b12: drm/i915/dg2: Add support for new DG2-G11 revid 0x5 (2021-08-06 09:03:10 -0700) drm/i915 changes for v5.15: Features: - Basic DG2 platform enabling (Matt, Animesh, Gwan-gyeong, José) - Add PSF GV point support for display bandwidth calculation (Stan) - Add platform release id version support (Lucas) - Add support for forcing DSC BPP for testing (Vandita, Patnana) Refactoring and cleanups: - Remove CNL support completely (Lucas) - Revid/stepping cleanup (Matt, Anusha) - Make display stepping check upper bounds exclusive (Matt) - Remove old GEN macros (Lucas) - Refactor DG1 interrupt handler (Paulo) - Refactor DMC stepping info (Anusha) Fixes: - Fix XELPD color capability reporting; it's not yet enabled (Uma) - Fix DG1 memory bandwidth computation (Clint) - Fix mux on certain HP laptops (Kai-Heng) - Various display workarounds (José, Matt, Imre) - Fix error state dumps wrt SFC_DONE (Matt) - Fix DG1 and XEPLD audio power domains (Anshuman) - Fix ADL-P and ADL-S ddi buf translation tables (Matt) - Fix DP/HDMI modeset sequences causing issues on ADL-P (José) - PSR2 fixes (José) - Fix DP MST modeset with FEC on TGL+ - Fix MBUS DBOX A credits on ADL-P (José) - Fix DP PHY test training set programming (Khaled) - Fix dgfx pcode uncore init done wait (Badal) - Fix DSC disable fuse check on GLK (Lucas) - Fix shared dpll mismatch for bigjoiner secondary pipe (Manasi) - Fix ADL-P underrun recovery (Matt) - Fix permissions on FEC support debugfs file (Vandita) Misc: - Backmerge drm-next (Rodrigo) - Bump RKL and TGL DMC firmware version (Anusha) Animesh Manna (1): drm/i915/dg2: Update to bigjoiner path Anshuman Gupta (2): drm/i915/debugfs: DISPLAY_VER 13 lpsp capability drm/i915/dg1: Adjust the AUDIO power domain Anusha Srivatsa (5): drm/i915/step: s/_revid_tbl/_revids drm/i915/step: Add macro magic for handling steps drm/i915/dmc: Change intel_get_stepping_info() drm/i915/firmware: Update to DMC v2.12 on TGL drm/i915/firmware: Update to DMC v2.03 on RKL Badal Nilawar (1): drm/i915: dgfx cards need to wait on pcode's uncore init done Clint Taylor (1): drm/i915/dg1: Compute MEM Bandwidth using MCHBAR Gwan-gyeong Mun (1): drm/i915/dg2: Update lane disable power state during PSR Imre Deak (2): drm/i915/adlp: Add workaround to disable CMTG clock gating drm/i915: Apply CMTG clock disabling WA while DPLL0 is enabled Jani Nikula (1): drm/i915/plane: add intel_plane_helper_add() helper José Roberto de Souza (10): drm/i915/display: Settle on "adl-x" in WA comments drm/i915: Limit Wa_22010178259 to affected platforms drm/i915/display/xelpd: Extend Wa_14011508470 drm/i915/display/adl_p: Implement PSR changes drm/i915/display: Disable FBC when PSR2 is enabled display 12 and newer drm/i915/dg2: Add DG2 to the PSR2 defeature list drm/i915/display/psr2: Mark as updated all planes that intersect with pipe_clip drm/i915/display/psr2: Fi
Re: [PATCH] drm/display: fix possible null-pointer dereference in dcn10_set_clock()
Thanks for your feedback. We will prepare a V2 patch according to your advice. Best wishes, Tuo Li On 2021/8/10 21:38, Chen, Guchun wrote: [Public] Thanks for your patch. I suggest moving the check of function pointer dc->clk_mgr->funcs->get_clock earlier, and return early if it's NULL, as if it's NULL, it's meaningless to continue the clock setting. if (!dc->clk_mgr || !dc->clk_mgr->funcs->get_clock) return DC_FAIL_UNSUPPORTED_1; dc->clk_mgr->funcs->get_clock(dc->clk_mgr, context, clock_type, &clock_cfg); Regards, Guchun -Original Message- From: amd-gfx On Behalf Of Tuo Li Sent: Tuesday, August 10, 2021 5:20 PM To: Wentland, Harry ; Li, Sun peng (Leo) ; Deucher, Alexander ; Koenig, Christian ; Pan, Xinhui ; airl...@linux.ie; dan...@ffwll.ch; Cyr, Aric ; Lei, Jun ; Zhuo, Qingqing ; Siqueira, Rodrigo ; Lee, Alvin ; Stempen, Vladimir ; isabel.zh...@amd.com; Lee, Sung ; Po-Yu Hsieh Paul ; Wood, Wyatt Cc: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org; baijiaju1...@gmail.com; Tuo Li ; TOTE Robot Subject: [PATCH] drm/display: fix possible null-pointer dereference in dcn10_set_clock() The variable dc->clk_mgr is checked in: if (dc->clk_mgr && dc->clk_mgr->funcs->get_clock) This indicates dc->clk_mgr can be NULL. However, it is dereferenced in: if (!dc->clk_mgr->funcs->get_clock) To fix this possible null-pointer dereference, check dc->clk_mgr before dereferencing it. Reported-by: TOTE Robot Signed-off-by: Tuo Li --- drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c index c545eddabdcc..3a7c7c7efa68 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c +++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c @@ -3635,7 +3635,7 @@ enum dc_status dcn10_set_clock(struct dc *dc, dc->clk_mgr->funcs->get_clock(dc->clk_mgr, context, clock_type, &clock_cfg); - if (!dc->clk_mgr->funcs->get_clock) + if (dc->clk_mgr && !dc->clk_mgr->funcs->get_clock) return DC_FAIL_UNSUPPORTED_1; if (clk_khz > clock_cfg.max_clock_khz) -- 2.25.1
Re: [syzbot] general protection fault in udmabuf_create
On 8/10/21 4:47 PM, syzbot wrote:
Hello,
syzbot found the following issue on:
HEAD commit:7999516e20bd Add linux-next specific files for 20210806
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=10f15f8e30
kernel config: https://syzkaller.appspot.com/x/.config?x=2f518e910b029c31
dashboard link: https://syzkaller.appspot.com/bug?extid=e9cd3122a37c5d6c51e8
compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for
Debian) 2.35.1
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1181099a30
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=11b6fce930
The issue was bisected to:
commit 16c243e99d335e1ef3059871897119affc98b493
Author: Vivek Kasireddy
Date: Wed Jun 9 18:29:15 2021 +
udmabuf: Add support for mapping hugepages (v4)
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=12f73dc930
final oops: https://syzkaller.appspot.com/x/report.txt?x=11f73dc930
console output: https://syzkaller.appspot.com/x/log.txt?x=16f73dc930
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+e9cd3122a37c5d6c5...@syzkaller.appspotmail.com
Fixes: 16c243e99d33 ("udmabuf: Add support for mapping hugepages (v4)")
general protection fault, probably for non-canonical address
0xdc01: [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0008-0x000f]
CPU: 0 PID: 6603 Comm: syz-executor127 Not tainted
5.14.0-rc4-next-20210806-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
01/01/2011
RIP: 0010:_compound_head include/linux/page-flags.h:187 [inline]
RIP: 0010:get_page include/linux/mm.h:1203 [inline]
RIP: 0010:udmabuf_create+0x664/0x16f0 drivers/dma-buf/udmabuf.c:236
Code: 03 48 89 84 24 90 00 00 00 e9 38 01 00 00 e8 23 7a f7 fc 4d 89 f4 49 c1 e4 06
4c 03 24 24 49 8d 7c 24 08 48 89 f8 48 c1 e8 03 <42> 80 3c 38 00 0f 85 d3 0d 00
00 4d 8b 6c 24 08 31 ff 4c 89 eb 83
RSP: 0018:c90002d7fc70 EFLAGS: 00010202
RAX: 0001 RBX: RCX:
RDX: 888023f69c80 RSI: 847e4f3d RDI: 0008
RBP: R08: f000 R09:
R10: 847e50f5 R11: R12:
R13: R14: R15: dc00
FS: 00935300() GS:8880b9c0() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 220c CR3: 18d16000 CR4: 001506f0
DR0: DR1: DR2:
DR3: DR6: fffe0ff0 DR7: 0400
Call Trace:
udmabuf_ioctl_create drivers/dma-buf/udmabuf.c:305 [inline]
The problem is wrong error handling:
hpage = find_get_page_flags(mapping, pgoff, FGP_ACCESSED);
if (IS_ERR(hpage)) {
ret = PTR_ERR(hpage);
goto err;
}
find_get_page_flags() return NULL on failure, so this patch should work:
diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
index 8df761a10251..c57a609db75b 100644
--- a/drivers/dma-buf/udmabuf.c
+++ b/drivers/dma-buf/udmabuf.c
@@ -227,8 +227,8 @@ static long udmabuf_create(struct miscdevice *device,
if (!hpage) {
hpage = find_get_page_flags(mapping,
pgoff,
FGP_ACCESSED);
- if (IS_ERR(hpage)) {
- ret = PTR_ERR(hpage);
+ if (!hpage) {
+ ret = -EINVAL;
goto err;
}
}
I am not sure about ret value in case of failure, so I am looking for
any reviews :)
udmabuf_ioctl+0x152/0x2c0 drivers/dma-buf/udmabuf.c:336
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:874 [inline]
__se_sys_ioctl fs/ioctl.c:860 [inline]
__x64_sys_ioctl+0x193/0x200 fs/ioctl.c:860
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae
With regards,
Pavel Skripkin
Re: [PATCH] drm/amd/display: remove variable backlight
On Mon, Aug 9, 2021 at 9:24 PM zhaoxiao wrote:
>
> The variable backlight is being initialized with a value that
> is never read, it is being re-assigned immediately afterwards.
I don't think this comment really matches the code. I think you can drop it.
Alex
> Clean up the code by removing the need for variable backlight.
>
> Signed-off-by: zhaoxiao
> ---
> drivers/gpu/drm/amd/display/dc/dce/dce_abm.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_abm.c
> b/drivers/gpu/drm/amd/display/dc/dce/dce_abm.c
> index 874b132fe1d7..0808433185f8 100644
> --- a/drivers/gpu/drm/amd/display/dc/dce/dce_abm.c
> +++ b/drivers/gpu/drm/amd/display/dc/dce/dce_abm.c
> @@ -177,23 +177,21 @@ static void dce_abm_init(struct abm *abm, uint32_t
> backlight)
> static unsigned int dce_abm_get_current_backlight(struct abm *abm)
> {
> struct dce_abm *abm_dce = TO_DCE_ABM(abm);
> - unsigned int backlight = REG_READ(BL1_PWM_CURRENT_ABM_LEVEL);
>
> /* return backlight in hardware format which is unsigned 17 bits, with
> * 1 bit integer and 16 bit fractional
> */
> - return backlight;
> + return REG_READ(BL1_PWM_CURRENT_ABM_LEVEL);
> }
>
> static unsigned int dce_abm_get_target_backlight(struct abm *abm)
> {
> struct dce_abm *abm_dce = TO_DCE_ABM(abm);
> - unsigned int backlight = REG_READ(BL1_PWM_TARGET_ABM_LEVEL);
>
> /* return backlight in hardware format which is unsigned 17 bits, with
> * 1 bit integer and 16 bit fractional
> */
> - return backlight;
> + return REG_READ(BL1_PWM_TARGET_ABM_LEVEL);
> }
>
> static bool dce_abm_set_level(struct abm *abm, uint32_t level)
> --
> 2.20.1
>
>
>
[PATCH AUTOSEL 5.13 12/24] drm/amdgpu: fix the doorbell missing when in CGPG issue for renoir.
From: Yifan Zhang
[ Upstream commit 1c0539a6fc8a4a4b77278e35d763073890de96b9 ]
If GC has entered CGPG, ringing doorbell > first page doesn't wakeup GC.
Enlarge CP_MEC_DOORBELL_RANGE_UPPER to workaround this issue.
Signed-off-by: Yifan Zhang
Reviewed-by: Alex Deucher
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
index 516467e962b7..3a476b86485e 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
@@ -1293,6 +1293,16 @@ static bool is_raven_kicker(struct amdgpu_device *adev)
return false;
}
+static bool check_if_enlarge_doorbell_range(struct amdgpu_device *adev)
+{
+ if ((adev->asic_type == CHIP_RENOIR) &&
+ (adev->gfx.me_fw_version >= 0x00a5) &&
+ (adev->gfx.me_feature_version >= 52))
+ return true;
+ else
+ return false;
+}
+
static void gfx_v9_0_check_if_need_gfxoff(struct amdgpu_device *adev)
{
if (gfx_v9_0_should_disable_gfxoff(adev->pdev))
@@ -3673,7 +3683,16 @@ static int gfx_v9_0_kiq_init_register(struct amdgpu_ring
*ring)
if (ring->use_doorbell) {
WREG32_SOC15(GC, 0, mmCP_MEC_DOORBELL_RANGE_LOWER,
(adev->doorbell_index.kiq * 2) << 2);
- WREG32_SOC15(GC, 0, mmCP_MEC_DOORBELL_RANGE_UPPER,
+ /* If GC has entered CGPG, ringing doorbell > first page
+* doesn't wakeup GC. Enlarge CP_MEC_DOORBELL_RANGE_UPPER to
+* workaround this issue. And this change has to align with
firmware
+* update.
+*/
+ if (check_if_enlarge_doorbell_range(adev))
+ WREG32_SOC15(GC, 0, mmCP_MEC_DOORBELL_RANGE_UPPER,
+ (adev->doorbell.size - 4));
+ else
+ WREG32_SOC15(GC, 0, mmCP_MEC_DOORBELL_RANGE_UPPER,
(adev->doorbell_index.userqueue_end *
2) << 2);
}
--
2.30.2
[PATCH AUTOSEL 5.13 22/24] drm/amd/display: Fix Dynamic bpp issue with 8K30 with Navi 1X
From: Bing Guo [ Upstream commit 06050a0f01dbac2ca33145ef19a72041206ea983 ] Why: In DCN2x, HW doesn't automatically divide MASTER_UPDATE_LOCK_DB_X by the number of pipes ODM Combined. How: Set MASTER_UPDATE_LOCK_DB_X to the value that is adjusted by the number of pipes ODM Combined. Reviewed-by: Martin Leung Acked-by: Aurabindo Pillai Signed-off-by: Bing Guo Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/dc/dcn20/dcn20_optc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_optc.c b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_optc.c index 3139d90017ee..23f830986f78 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_optc.c +++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_optc.c @@ -464,7 +464,7 @@ void optc2_lock_doublebuffer_enable(struct timing_generator *optc) REG_UPDATE_2(OTG_GLOBAL_CONTROL1, MASTER_UPDATE_LOCK_DB_X, - h_blank_start - 200 - 1, + (h_blank_start - 200 - 1) / optc1->opp_count, MASTER_UPDATE_LOCK_DB_Y, v_blank_start - 1); } -- 2.30.2
[PATCH AUTOSEL 5.13 23/24] drm/amd/display: workaround for hard hang on HPD on native DP
From: Qingqing Zhuo
[ Upstream commit c4152b297d56d3696ad0a9003169bc5b98ad7b72 ]
[Why]
HPD disable and enable sequences are not mutually exclusive
on Linux. For HPDs that spans over 1s (i.e. HPD low = 1s),
part of the disable sequence (specifically, a request to SMU
to lower refclk) could come right before the call to PHY
enable, causing DMUB to access an unresponsive PHY
and thus a hard hang on the system.
[How]
Disable 48mhz refclk off on native DP.
Reviewed-by: Hersen Wu
Acked-by: Aurabindo Pillai
Signed-off-by: Qingqing Zhuo
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c
b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c
index 75ba86f951f8..7bbedb6b4a9e 100644
--- a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c
+++ b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c
@@ -66,9 +66,11 @@ int rn_get_active_display_cnt_wa(
for (i = 0; i < context->stream_count; i++) {
const struct dc_stream_state *stream = context->streams[i];
+ /* Extend the WA to DP for Linux*/
if (stream->signal == SIGNAL_TYPE_HDMI_TYPE_A ||
stream->signal == SIGNAL_TYPE_DVI_SINGLE_LINK ||
- stream->signal == SIGNAL_TYPE_DVI_DUAL_LINK)
+ stream->signal == SIGNAL_TYPE_DVI_DUAL_LINK ||
+ stream->signal == SIGNAL_TYPE_DISPLAY_PORT)
tmds_present = true;
}
--
2.30.2
[PATCH AUTOSEL 5.10 12/20] drm/amdgpu: fix the doorbell missing when in CGPG issue for renoir.
From: Yifan Zhang
[ Upstream commit 1c0539a6fc8a4a4b77278e35d763073890de96b9 ]
If GC has entered CGPG, ringing doorbell > first page doesn't wakeup GC.
Enlarge CP_MEC_DOORBELL_RANGE_UPPER to workaround this issue.
Signed-off-by: Yifan Zhang
Reviewed-by: Alex Deucher
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
index fb15e8b5af32..ac3a88197b2f 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
@@ -1271,6 +1271,16 @@ static bool is_raven_kicker(struct amdgpu_device *adev)
return false;
}
+static bool check_if_enlarge_doorbell_range(struct amdgpu_device *adev)
+{
+ if ((adev->asic_type == CHIP_RENOIR) &&
+ (adev->gfx.me_fw_version >= 0x00a5) &&
+ (adev->gfx.me_feature_version >= 52))
+ return true;
+ else
+ return false;
+}
+
static void gfx_v9_0_check_if_need_gfxoff(struct amdgpu_device *adev)
{
if (gfx_v9_0_should_disable_gfxoff(adev->pdev))
@@ -3619,7 +3629,16 @@ static int gfx_v9_0_kiq_init_register(struct amdgpu_ring
*ring)
if (ring->use_doorbell) {
WREG32_SOC15(GC, 0, mmCP_MEC_DOORBELL_RANGE_LOWER,
(adev->doorbell_index.kiq * 2) << 2);
- WREG32_SOC15(GC, 0, mmCP_MEC_DOORBELL_RANGE_UPPER,
+ /* If GC has entered CGPG, ringing doorbell > first page
+* doesn't wakeup GC. Enlarge CP_MEC_DOORBELL_RANGE_UPPER to
+* workaround this issue. And this change has to align with
firmware
+* update.
+*/
+ if (check_if_enlarge_doorbell_range(adev))
+ WREG32_SOC15(GC, 0, mmCP_MEC_DOORBELL_RANGE_UPPER,
+ (adev->doorbell.size - 4));
+ else
+ WREG32_SOC15(GC, 0, mmCP_MEC_DOORBELL_RANGE_UPPER,
(adev->doorbell_index.userqueue_end *
2) << 2);
}
--
2.30.2
[PATCH AUTOSEL 5.10 19/20] drm/amd/display: Fix Dynamic bpp issue with 8K30 with Navi 1X
From: Bing Guo [ Upstream commit 06050a0f01dbac2ca33145ef19a72041206ea983 ] Why: In DCN2x, HW doesn't automatically divide MASTER_UPDATE_LOCK_DB_X by the number of pipes ODM Combined. How: Set MASTER_UPDATE_LOCK_DB_X to the value that is adjusted by the number of pipes ODM Combined. Reviewed-by: Martin Leung Acked-by: Aurabindo Pillai Signed-off-by: Bing Guo Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/dc/dcn20/dcn20_optc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_optc.c b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_optc.c index d8b18c515d06..e3cfb442a062 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_optc.c +++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_optc.c @@ -357,7 +357,7 @@ void optc2_lock_doublebuffer_enable(struct timing_generator *optc) REG_UPDATE_2(OTG_GLOBAL_CONTROL1, MASTER_UPDATE_LOCK_DB_X, - h_blank_start - 200 - 1, + (h_blank_start - 200 - 1) / optc1->opp_count, MASTER_UPDATE_LOCK_DB_Y, v_blank_start - 1); } -- 2.30.2
[PATCH AUTOSEL 5.10 20/20] drm/amd/display: workaround for hard hang on HPD on native DP
From: Qingqing Zhuo
[ Upstream commit c4152b297d56d3696ad0a9003169bc5b98ad7b72 ]
[Why]
HPD disable and enable sequences are not mutually exclusive
on Linux. For HPDs that spans over 1s (i.e. HPD low = 1s),
part of the disable sequence (specifically, a request to SMU
to lower refclk) could come right before the call to PHY
enable, causing DMUB to access an unresponsive PHY
and thus a hard hang on the system.
[How]
Disable 48mhz refclk off on native DP.
Reviewed-by: Hersen Wu
Acked-by: Aurabindo Pillai
Signed-off-by: Qingqing Zhuo
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c
b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c
index 1c6e401dd4cc..0eba391e597f 100644
--- a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c
+++ b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c
@@ -66,9 +66,11 @@ int rn_get_active_display_cnt_wa(
for (i = 0; i < context->stream_count; i++) {
const struct dc_stream_state *stream = context->streams[i];
+ /* Extend the WA to DP for Linux*/
if (stream->signal == SIGNAL_TYPE_HDMI_TYPE_A ||
stream->signal == SIGNAL_TYPE_DVI_SINGLE_LINK ||
- stream->signal == SIGNAL_TYPE_DVI_DUAL_LINK)
+ stream->signal == SIGNAL_TYPE_DVI_DUAL_LINK ||
+ stream->signal == SIGNAL_TYPE_DISPLAY_PORT)
tmds_present = true;
}
--
2.30.2
[PATCH AUTOSEL 5.4 13/13] drm/amd/display: Fix Dynamic bpp issue with 8K30 with Navi 1X
From: Bing Guo [ Upstream commit 06050a0f01dbac2ca33145ef19a72041206ea983 ] Why: In DCN2x, HW doesn't automatically divide MASTER_UPDATE_LOCK_DB_X by the number of pipes ODM Combined. How: Set MASTER_UPDATE_LOCK_DB_X to the value that is adjusted by the number of pipes ODM Combined. Reviewed-by: Martin Leung Acked-by: Aurabindo Pillai Signed-off-by: Bing Guo Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/dc/dcn20/dcn20_optc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_optc.c b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_optc.c index 8d5cfd5357c7..03e207333953 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_optc.c +++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_optc.c @@ -362,7 +362,7 @@ void optc2_lock_doublebuffer_enable(struct timing_generator *optc) REG_UPDATE_2(OTG_GLOBAL_CONTROL1, MASTER_UPDATE_LOCK_DB_X, - h_blank_start - 200 - 1, + (h_blank_start - 200 - 1) / optc1->opp_count, MASTER_UPDATE_LOCK_DB_Y, v_blank_start - 1); } -- 2.30.2
Re: [PATCH] drm/doc/rfc: drop lmem uapi section
Acked-by: Jason Ekstrand
On Tue, Aug 10, 2021 at 7:34 AM Daniel Vetter wrote:
>
> We still have quite a bit more work to do with overall reworking of
> the ttm-based dg1 code, but the uapi stuff is now finalized with the
> latest pull. So remove that.
>
> This also fixes kerneldoc build warnings because we've included the
> same headers in two places, resulting in sphinx complaining about
> duplicated symbols. This regression has been created when we moved the
> uapi definitions to the real include/uapi/ folder in 727ecd99a4c9
> ("drm/doc/rfc: drop the i915_gem_lmem.h header")
>
> Reported-by: Stephen Rothwell
> Cc: Stephen Rothwell
> Fixes: 727ecd99a4c9 ("drm/doc/rfc: drop the i915_gem_lmem.h header")
> Cc: Matthew Auld
> Signed-off-by: Daniel Vetter
> ---
> Documentation/gpu/rfc/i915_gem_lmem.rst | 107
> 1 file changed, 107 deletions(-)
>
> diff --git a/Documentation/gpu/rfc/i915_gem_lmem.rst
> b/Documentation/gpu/rfc/i915_gem_lmem.rst
> index 675ba8620d66..91be041e68cc 100644
> --- a/Documentation/gpu/rfc/i915_gem_lmem.rst
> +++ b/Documentation/gpu/rfc/i915_gem_lmem.rst
> @@ -22,110 +22,3 @@ real, with all the uAPI bits is:
> * SET/GET ioctl caching(see `I915 SET/GET CACHING`_)
> * Send RFC(with mesa-dev on cc) for final sign off on the uAPI
> * Add pciid for DG1 and turn on uAPI for real
> -
> -New object placement and region query uAPI
> -==
> -Starting from DG1 we need to give userspace the ability to allocate buffers
> from
> -device local-memory. Currently the driver supports gem_create, which can
> place
> -buffers in system memory via shmem, and the usual assortment of other
> -interfaces, like dumb buffers and userptr.
> -
> -To support this new capability, while also providing a uAPI which will work
> -beyond just DG1, we propose to offer three new bits of uAPI:
> -
> -DRM_I915_QUERY_MEMORY_REGIONS
> --
> -New query ID which allows userspace to discover the list of supported memory
> -regions(like system-memory and local-memory) for a given device. We identify
> -each region with a class and instance pair, which should be unique. The class
> -here would be DEVICE or SYSTEM, and the instance would be zero, on platforms
> -like DG1.
> -
> -Side note: The class/instance design is borrowed from our existing engine
> uAPI,
> -where we describe every physical engine in terms of its class, and the
> -particular instance, since we can have more than one per class.
> -
> -In the future we also want to expose more information which can further
> -describe the capabilities of a region.
> -
> -.. kernel-doc:: include/uapi/drm/i915_drm.h
> -:functions: drm_i915_gem_memory_class
> drm_i915_gem_memory_class_instance drm_i915_memory_region_info
> drm_i915_query_memory_regions
> -
> -GEM_CREATE_EXT
> ---
> -New ioctl which is basically just gem_create but now allows userspace to
> provide
> -a chain of possible extensions. Note that if we don't provide any extensions
> and
> -set flags=0 then we get the exact same behaviour as gem_create.
> -
> -Side note: We also need to support PXP[1] in the near future, which is also
> -applicable to integrated platforms, and adds its own gem_create_ext
> extension,
> -which basically lets userspace mark a buffer as "protected".
> -
> -.. kernel-doc:: include/uapi/drm/i915_drm.h
> -:functions: drm_i915_gem_create_ext
> -
> -I915_GEM_CREATE_EXT_MEMORY_REGIONS
> ---
> -Implemented as an extension for gem_create_ext, we would now allow userspace
> to
> -optionally provide an immutable list of preferred placements at creation
> time,
> -in priority order, for a given buffer object. For the placements we expect
> -them each to use the class/instance encoding, as per the output of the
> regions
> -query. Having the list in priority order will be useful in the future when
> -placing an object, say during eviction.
> -
> -.. kernel-doc:: include/uapi/drm/i915_drm.h
> -:functions: drm_i915_gem_create_ext_memory_regions
> -
> -One fair criticism here is that this seems a little over-engineered[2]. If we
> -just consider DG1 then yes, a simple gem_create.flags or something is totally
> -all that's needed to tell the kernel to allocate the buffer in local-memory
> or
> -whatever. However looking to the future we need uAPI which can also support
> -upcoming Xe HP multi-tile architecture in a sane way, where there can be
> -multiple local-memory instances for a given device, and so using both class
> and
> -instance in our uAPI to describe regions is desirable, although specifically
> -for DG1 it's uninteresting, since we only have a single local-memory
> instance.
> -
> -Existing uAPI issues
> -
> -Some potential issues we still need to resolve.
> -
> -I915 MMAP
> --
> -In i915 there are multiple ways to MMAP GEM object, including mapping the
> same
> -object using
Re: [Intel-gfx] [PATCH v2] fbdev/efifb: Release PCI device's runtime PM ref during FB destroy
On Tue, Aug 10, 2021 at 4:36 AM Imre Deak wrote:
>
> Hi Kai-Heng, Alex,
>
> could you add your ack if the fix looks ok and you're ok if I push it to
> the i915 tree?
>
Acked-by: Alex Deucher
> Thanks,
> Imre
>
> On Mon, Aug 09, 2021 at 04:31:46PM +0300, Imre Deak wrote:
> > Atm the EFI FB platform driver gets a runtime PM reference for the
> > associated GFX PCI device during probing the EFI FB platform device and
> > releases it only when the platform device gets unbound.
> >
> > When fbcon switches to the FB provided by the PCI device's driver (for
> > instance i915/drmfb), the EFI FB will get only unregistered without the
> > EFI FB platform device getting unbound, keeping the runtime PM reference
> > acquired during the platform device probing. This reference will prevent
> > the PCI driver from runtime suspending the device.
> >
> > Fix this by releasing the RPM reference from the EFI FB's destroy hook,
> > called when the FB gets unregistered.
> >
> > While at it assert that pm_runtime_get_sync() didn't fail.
> >
> > v2:
> > - Move pm_runtime_get_sync() before register_framebuffer() to avoid its
> > race wrt. efifb_destroy()->pm_runtime_put(). (Daniel)
> > - Assert that pm_runtime_get_sync() didn't fail.
> > - Clarify commit message wrt. platform/PCI device/driver and driver
> > removal vs. device unbinding.
> >
> > Fixes: a6c0fd3d5a8b ("efifb: Ensure graphics device for efifb stays at PCI
> > D0")
> > Cc: Kai-Heng Feng
> > Cc: Daniel Vetter
> > Reviewed-by: Daniel Vetter (v1)
> > Signed-off-by: Imre Deak
> > ---
> > drivers/video/fbdev/efifb.c | 21 ++---
> > 1 file changed, 14 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
> > index 8ea8f079cde26..edca3703b9640 100644
> > --- a/drivers/video/fbdev/efifb.c
> > +++ b/drivers/video/fbdev/efifb.c
> > @@ -47,6 +47,8 @@ static bool use_bgrt = true;
> > static bool request_mem_succeeded = false;
> > static u64 mem_flags = EFI_MEMORY_WC | EFI_MEMORY_UC;
> >
> > +static struct pci_dev *efifb_pci_dev;/* dev with BAR covering the
> > efifb */
> > +
> > static struct fb_var_screeninfo efifb_defined = {
> > .activate = FB_ACTIVATE_NOW,
> > .height = -1,
> > @@ -243,6 +245,9 @@ static inline void efifb_show_boot_graphics(struct
> > fb_info *info) {}
> >
> > static void efifb_destroy(struct fb_info *info)
> > {
> > + if (efifb_pci_dev)
> > + pm_runtime_put(&efifb_pci_dev->dev);
> > +
> > if (info->screen_base) {
> > if (mem_flags & (EFI_MEMORY_UC | EFI_MEMORY_WC))
> > iounmap(info->screen_base);
> > @@ -333,7 +338,6 @@ ATTRIBUTE_GROUPS(efifb);
> >
> > static bool pci_dev_disabled;/* FB base matches BAR of a disabled
> > device */
> >
> > -static struct pci_dev *efifb_pci_dev;/* dev with BAR covering the
> > efifb */
> > static struct resource *bar_resource;
> > static u64 bar_offset;
> >
> > @@ -569,17 +573,22 @@ static int efifb_probe(struct platform_device *dev)
> > pr_err("efifb: cannot allocate colormap\n");
> > goto err_groups;
> > }
> > +
> > + if (efifb_pci_dev)
> > + WARN_ON(pm_runtime_get_sync(&efifb_pci_dev->dev) < 0);
> > +
> > err = register_framebuffer(info);
> > if (err < 0) {
> > pr_err("efifb: cannot register framebuffer\n");
> > - goto err_fb_dealoc;
> > + goto err_put_rpm_ref;
> > }
> > fb_info(info, "%s frame buffer device\n", info->fix.id);
> > - if (efifb_pci_dev)
> > - pm_runtime_get_sync(&efifb_pci_dev->dev);
> > return 0;
> >
> > -err_fb_dealoc:
> > +err_put_rpm_ref:
> > + if (efifb_pci_dev)
> > + pm_runtime_put(&efifb_pci_dev->dev);
> > +
> > fb_dealloc_cmap(&info->cmap);
> > err_groups:
> > sysfs_remove_groups(&dev->dev.kobj, efifb_groups);
> > @@ -603,8 +612,6 @@ static int efifb_remove(struct platform_device *pdev)
> > unregister_framebuffer(info);
> > sysfs_remove_groups(&pdev->dev.kobj, efifb_groups);
> > framebuffer_release(info);
> > - if (efifb_pci_dev)
> > - pm_runtime_put(&efifb_pci_dev->dev);
> >
> > return 0;
> > }
> > --
> > 2.27.0
> >
Re: [syzbot] general protection fault in udmabuf_create
On Tue, Aug 10, 2021 at 05:10:56PM +0300, Pavel Skripkin wrote:
> On 8/10/21 4:47 PM, syzbot wrote:
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit:7999516e20bd Add linux-next specific files for 20210806
> > git tree: linux-next
> > console output: https://syzkaller.appspot.com/x/log.txt?x=10f15f8e30
> > kernel config: https://syzkaller.appspot.com/x/.config?x=2f518e910b029c31
> > dashboard link: https://syzkaller.appspot.com/bug?extid=e9cd3122a37c5d6c51e8
> > compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils
> > for Debian) 2.35.1
> > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1181099a30
> > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=11b6fce930
> >
> > The issue was bisected to:
> >
> > commit 16c243e99d335e1ef3059871897119affc98b493
> > Author: Vivek Kasireddy
> > Date: Wed Jun 9 18:29:15 2021 +
> >
> > udmabuf: Add support for mapping hugepages (v4)
> >
> > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=12f73dc930
> > final oops: https://syzkaller.appspot.com/x/report.txt?x=11f73dc930
> > console output: https://syzkaller.appspot.com/x/log.txt?x=16f73dc930
> >
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: syzbot+e9cd3122a37c5d6c5...@syzkaller.appspotmail.com
> > Fixes: 16c243e99d33 ("udmabuf: Add support for mapping hugepages (v4)")
> >
> > general protection fault, probably for non-canonical address
> > 0xdc01: [#1] PREEMPT SMP KASAN
> > KASAN: null-ptr-deref in range [0x0008-0x000f]
> > CPU: 0 PID: 6603 Comm: syz-executor127 Not tainted
> > 5.14.0-rc4-next-20210806-syzkaller #0
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > Google 01/01/2011
> > RIP: 0010:_compound_head include/linux/page-flags.h:187 [inline]
> > RIP: 0010:get_page include/linux/mm.h:1203 [inline]
> > RIP: 0010:udmabuf_create+0x664/0x16f0 drivers/dma-buf/udmabuf.c:236
> > Code: 03 48 89 84 24 90 00 00 00 e9 38 01 00 00 e8 23 7a f7 fc 4d 89 f4 49
> > c1 e4 06 4c 03 24 24 49 8d 7c 24 08 48 89 f8 48 c1 e8 03 <42> 80 3c 38 00
> > 0f 85 d3 0d 00 00 4d 8b 6c 24 08 31 ff 4c 89 eb 83
> > RSP: 0018:c90002d7fc70 EFLAGS: 00010202
> > RAX: 0001 RBX: RCX:
> > RDX: 888023f69c80 RSI: 847e4f3d RDI: 0008
> > RBP: R08: f000 R09:
> > R10: 847e50f5 R11: R12:
> > R13: R14: R15: dc00
> > FS: 00935300() GS:8880b9c0() knlGS:
> > CS: 0010 DS: ES: CR0: 80050033
> > CR2: 220c CR3: 18d16000 CR4: 001506f0
> > DR0: DR1: DR2:
> > DR3: DR6: fffe0ff0 DR7: 0400
> > Call Trace:
> > udmabuf_ioctl_create drivers/dma-buf/udmabuf.c:305 [inline]
>
> The problem is wrong error handling:
>
> hpage = find_get_page_flags(mapping, pgoff, FGP_ACCESSED);
> if (IS_ERR(hpage)) {
> ret = PTR_ERR(hpage);
> goto err;
> }
>
> find_get_page_flags() return NULL on failure, so this patch should work:
>
> diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
> index 8df761a10251..c57a609db75b 100644
> --- a/drivers/dma-buf/udmabuf.c
> +++ b/drivers/dma-buf/udmabuf.c
> @@ -227,8 +227,8 @@ static long udmabuf_create(struct miscdevice *device,
> if (!hpage) {
> hpage = find_get_page_flags(mapping,
> pgoff,
>
> FGP_ACCESSED);
> - if (IS_ERR(hpage)) {
> - ret = PTR_ERR(hpage);
> + if (!hpage) {
> + ret = -EINVAL;
> goto err;
> }
> }
>
> I am not sure about ret value in case of failure, so I am looking for any
> reviews :)
You're right. Smatch is sort of supposed to warn about this but
pagecache_get_page() is too complicated.
regards,
dan carpenter
[PATCH] drm/doc/rfc: drop lmem uapi section
We still have quite a bit more work to do with overall reworking of
the ttm-based dg1 code, but the uapi stuff is now finalized with the
latest pull. So remove that.
This also fixes kerneldoc build warnings because we've included the
same headers in two places, resulting in sphinx complaining about
duplicated symbols. This regression has been created when we moved the
uapi definitions to the real include/uapi/ folder in 727ecd99a4c9
("drm/doc/rfc: drop the i915_gem_lmem.h header")
v2: Fix a few references that I missed, the htmldocs build took
forever.
Acked-by: Jason Ekstrand
Tested-by Stephen Rothwell (v1)
References:
https://lore.kernel.org/dri-devel/20210603193242.1ce99...@canb.auug.org.au/
Reported-by: Stephen Rothwell
Cc: Stephen Rothwell
Fixes: 727ecd99a4c9 ("drm/doc/rfc: drop the i915_gem_lmem.h header")
Cc: Matthew Auld
Signed-off-by: Daniel Vetter
---
Documentation/gpu/rfc/i915_gem_lmem.rst | 109
1 file changed, 109 deletions(-)
diff --git a/Documentation/gpu/rfc/i915_gem_lmem.rst
b/Documentation/gpu/rfc/i915_gem_lmem.rst
index 675ba8620d66..b421a3c1806e 100644
--- a/Documentation/gpu/rfc/i915_gem_lmem.rst
+++ b/Documentation/gpu/rfc/i915_gem_lmem.rst
@@ -18,114 +18,5 @@ real, with all the uAPI bits is:
* Route shmem backend over to TTM SYSTEM for discrete
* TTM purgeable object support
* Move i915 buddy allocator over to TTM
-* MMAP ioctl mode(see `I915 MMAP`_)
-* SET/GET ioctl caching(see `I915 SET/GET CACHING`_)
* Send RFC(with mesa-dev on cc) for final sign off on the uAPI
* Add pciid for DG1 and turn on uAPI for real
-
-New object placement and region query uAPI
-==
-Starting from DG1 we need to give userspace the ability to allocate buffers
from
-device local-memory. Currently the driver supports gem_create, which can place
-buffers in system memory via shmem, and the usual assortment of other
-interfaces, like dumb buffers and userptr.
-
-To support this new capability, while also providing a uAPI which will work
-beyond just DG1, we propose to offer three new bits of uAPI:
-
-DRM_I915_QUERY_MEMORY_REGIONS
--
-New query ID which allows userspace to discover the list of supported memory
-regions(like system-memory and local-memory) for a given device. We identify
-each region with a class and instance pair, which should be unique. The class
-here would be DEVICE or SYSTEM, and the instance would be zero, on platforms
-like DG1.
-
-Side note: The class/instance design is borrowed from our existing engine uAPI,
-where we describe every physical engine in terms of its class, and the
-particular instance, since we can have more than one per class.
-
-In the future we also want to expose more information which can further
-describe the capabilities of a region.
-
-.. kernel-doc:: include/uapi/drm/i915_drm.h
-:functions: drm_i915_gem_memory_class
drm_i915_gem_memory_class_instance drm_i915_memory_region_info
drm_i915_query_memory_regions
-
-GEM_CREATE_EXT
---
-New ioctl which is basically just gem_create but now allows userspace to
provide
-a chain of possible extensions. Note that if we don't provide any extensions
and
-set flags=0 then we get the exact same behaviour as gem_create.
-
-Side note: We also need to support PXP[1] in the near future, which is also
-applicable to integrated platforms, and adds its own gem_create_ext extension,
-which basically lets userspace mark a buffer as "protected".
-
-.. kernel-doc:: include/uapi/drm/i915_drm.h
-:functions: drm_i915_gem_create_ext
-
-I915_GEM_CREATE_EXT_MEMORY_REGIONS
---
-Implemented as an extension for gem_create_ext, we would now allow userspace to
-optionally provide an immutable list of preferred placements at creation time,
-in priority order, for a given buffer object. For the placements we expect
-them each to use the class/instance encoding, as per the output of the regions
-query. Having the list in priority order will be useful in the future when
-placing an object, say during eviction.
-
-.. kernel-doc:: include/uapi/drm/i915_drm.h
-:functions: drm_i915_gem_create_ext_memory_regions
-
-One fair criticism here is that this seems a little over-engineered[2]. If we
-just consider DG1 then yes, a simple gem_create.flags or something is totally
-all that's needed to tell the kernel to allocate the buffer in local-memory or
-whatever. However looking to the future we need uAPI which can also support
-upcoming Xe HP multi-tile architecture in a sane way, where there can be
-multiple local-memory instances for a given device, and so using both class and
-instance in our uAPI to describe regions is desirable, although specifically
-for DG1 it's uninteresting, since we only have a single local-memory instance.
-
-Existing uAPI issues
-
-Some potential issues we still need to resolve.
-
-I915 MMAP
Re: [Intel-gfx] [PATCH v2] fbdev/efifb: Release PCI device's runtime PM ref during FB destroy
On Tue, Aug 10, 2021 at 10:49 PM Alex Deucher wrote:
>
> On Tue, Aug 10, 2021 at 4:36 AM Imre Deak wrote:
> >
> > Hi Kai-Heng, Alex,
> >
> > could you add your ack if the fix looks ok and you're ok if I push it to
> > the i915 tree?
> >
>
> Acked-by: Alex Deucher
Acked-by: Kai-Heng Feng
>
> > Thanks,
> > Imre
> >
> > On Mon, Aug 09, 2021 at 04:31:46PM +0300, Imre Deak wrote:
> > > Atm the EFI FB platform driver gets a runtime PM reference for the
> > > associated GFX PCI device during probing the EFI FB platform device and
> > > releases it only when the platform device gets unbound.
> > >
> > > When fbcon switches to the FB provided by the PCI device's driver (for
> > > instance i915/drmfb), the EFI FB will get only unregistered without the
> > > EFI FB platform device getting unbound, keeping the runtime PM reference
> > > acquired during the platform device probing. This reference will prevent
> > > the PCI driver from runtime suspending the device.
> > >
> > > Fix this by releasing the RPM reference from the EFI FB's destroy hook,
> > > called when the FB gets unregistered.
> > >
> > > While at it assert that pm_runtime_get_sync() didn't fail.
> > >
> > > v2:
> > > - Move pm_runtime_get_sync() before register_framebuffer() to avoid its
> > > race wrt. efifb_destroy()->pm_runtime_put(). (Daniel)
> > > - Assert that pm_runtime_get_sync() didn't fail.
> > > - Clarify commit message wrt. platform/PCI device/driver and driver
> > > removal vs. device unbinding.
> > >
> > > Fixes: a6c0fd3d5a8b ("efifb: Ensure graphics device for efifb stays at
> > > PCI D0")
> > > Cc: Kai-Heng Feng
> > > Cc: Daniel Vetter
> > > Reviewed-by: Daniel Vetter (v1)
> > > Signed-off-by: Imre Deak
> > > ---
> > > drivers/video/fbdev/efifb.c | 21 ++---
> > > 1 file changed, 14 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
> > > index 8ea8f079cde26..edca3703b9640 100644
> > > --- a/drivers/video/fbdev/efifb.c
> > > +++ b/drivers/video/fbdev/efifb.c
> > > @@ -47,6 +47,8 @@ static bool use_bgrt = true;
> > > static bool request_mem_succeeded = false;
> > > static u64 mem_flags = EFI_MEMORY_WC | EFI_MEMORY_UC;
> > >
> > > +static struct pci_dev *efifb_pci_dev;/* dev with BAR covering
> > > the efifb */
> > > +
> > > static struct fb_var_screeninfo efifb_defined = {
> > > .activate = FB_ACTIVATE_NOW,
> > > .height = -1,
> > > @@ -243,6 +245,9 @@ static inline void efifb_show_boot_graphics(struct
> > > fb_info *info) {}
> > >
> > > static void efifb_destroy(struct fb_info *info)
> > > {
> > > + if (efifb_pci_dev)
> > > + pm_runtime_put(&efifb_pci_dev->dev);
> > > +
> > > if (info->screen_base) {
> > > if (mem_flags & (EFI_MEMORY_UC | EFI_MEMORY_WC))
> > > iounmap(info->screen_base);
> > > @@ -333,7 +338,6 @@ ATTRIBUTE_GROUPS(efifb);
> > >
> > > static bool pci_dev_disabled;/* FB base matches BAR of a
> > > disabled device */
> > >
> > > -static struct pci_dev *efifb_pci_dev;/* dev with BAR covering
> > > the efifb */
> > > static struct resource *bar_resource;
> > > static u64 bar_offset;
> > >
> > > @@ -569,17 +573,22 @@ static int efifb_probe(struct platform_device *dev)
> > > pr_err("efifb: cannot allocate colormap\n");
> > > goto err_groups;
> > > }
> > > +
> > > + if (efifb_pci_dev)
> > > + WARN_ON(pm_runtime_get_sync(&efifb_pci_dev->dev) < 0);
> > > +
> > > err = register_framebuffer(info);
> > > if (err < 0) {
> > > pr_err("efifb: cannot register framebuffer\n");
> > > - goto err_fb_dealoc;
> > > + goto err_put_rpm_ref;
> > > }
> > > fb_info(info, "%s frame buffer device\n", info->fix.id);
> > > - if (efifb_pci_dev)
> > > - pm_runtime_get_sync(&efifb_pci_dev->dev);
> > > return 0;
> > >
> > > -err_fb_dealoc:
> > > +err_put_rpm_ref:
> > > + if (efifb_pci_dev)
> > > + pm_runtime_put(&efifb_pci_dev->dev);
> > > +
> > > fb_dealloc_cmap(&info->cmap);
> > > err_groups:
> > > sysfs_remove_groups(&dev->dev.kobj, efifb_groups);
> > > @@ -603,8 +612,6 @@ static int efifb_remove(struct platform_device *pdev)
> > > unregister_framebuffer(info);
> > > sysfs_remove_groups(&pdev->dev.kobj, efifb_groups);
> > > framebuffer_release(info);
> > > - if (efifb_pci_dev)
> > > - pm_runtime_put(&efifb_pci_dev->dev);
> > >
> > > return 0;
> > > }
> > > --
> > > 2.27.0
> > >
[PATCH v2] drm/msm/dp: add drm debug logs to dp_pm_resume/suspend
Changes in V2:
-- correct Fixes text
-- drop commit text
Fixes: 601f0479c583 ("drm/msm/dp: add logs across DP driver for ease of
debugging")
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_display.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 8a85613..870b926 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -1284,6 +1284,9 @@ static int dp_pm_resume(struct device *dev)
mutex_lock(&dp->event_mutex);
+ DRM_DEBUG_DP("Before, core_inited=%d power_on=%d\n",
+ dp->core_initialized, dp_display->power_on);
+
/* start from disconnected state */
dp->hpd_state = ST_DISCONNECTED;
@@ -1315,6 +1318,10 @@ static int dp_pm_resume(struct device *dev)
else
dp->dp_display.is_connected = false;
+ DRM_DEBUG_DP("After, sink_count=%d is_connected=%d core_inited=%d
power_on=%d\n",
+ dp->link->sink_count, dp->dp_display.is_connected,
+ dp->core_initialized, dp_display->power_on);
+
mutex_unlock(&dp->event_mutex);
return 0;
@@ -1330,6 +1337,9 @@ static int dp_pm_suspend(struct device *dev)
mutex_lock(&dp->event_mutex);
+ DRM_DEBUG_DP("Before, core_inited=%d power_on=%d\n",
+ dp->core_initialized, dp_display->power_on);
+
if (dp->core_initialized == true) {
/* mainlink enabled */
if (dp_power_clk_status(dp->power, DP_CTRL_PM))
@@ -1343,6 +1353,9 @@ static int dp_pm_suspend(struct device *dev)
/* host_init will be called at pm_resume */
dp->core_initialized = false;
+ DRM_DEBUG_DP("After, core_inited=%d power_on=%d\n",
+ dp->core_initialized, dp_display->power_on);
+
mutex_unlock(&dp->event_mutex);
return 0;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH v2 1/3] dt-bindings: Add YAML bindings for Host1x and NVDEC
On Fri, Aug 06, 2021 at 03:34:48PM +0300, Mikko Perttunen wrote: > Convert the original Host1x bindings to YAML and add new bindings for > NVDEC, now in a more appropriate location. The old text bindings > for Host1x and engines are still kept at display/tegra/ since they > encompass a lot more engines that haven't been converted over yet. > > Signed-off-by: Mikko Perttunen > --- > v2: > * Fix issues pointed out in v1 > * Add T194 nvidia,instance property > --- > .../gpu/host1x/nvidia,tegra20-host1x.yaml | 131 ++ > .../gpu/host1x/nvidia,tegra210-nvdec.yaml | 109 +++ > MAINTAINERS | 1 + > 3 files changed, 241 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra20-host1x.yaml > create mode 100644 > Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvdec.yaml Can we split off the NVDEC bindings addition into a separate patch? I've been working on converting the existing host1x bindings in full to json- schema and this partial conversion would conflict with that effort. I assume that NVDEC itself validates properly even if host1x hasn't been converted yet? > diff --git > a/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvdec.yaml > b/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvdec.yaml > new file mode 100644 > index ..fc535bb7aee0 > --- /dev/null > +++ b/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvdec.yaml > @@ -0,0 +1,109 @@ > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: "http://devicetree.org/schemas/gpu/host1x/nvidia,tegra210-nvdec.yaml#"; > +$schema: "http://devicetree.org/meta-schemas/core.yaml#"; > + > +title: Device tree binding for NVIDIA Tegra NVDEC > + > +description: | > + NVDEC is the hardware video decoder present on NVIDIA Tegra210 > + and newer chips. It is located on the Host1x bus and typically > + programmed through Host1x channels. > + > +maintainers: > + - Thierry Reding > + - Mikko Perttunen > + > +properties: > + $nodename: > +pattern: "^nvdec@[0-9a-f]*$" > + > + compatible: > +enum: > + - nvidia,tegra210-nvdec > + - nvidia,tegra186-nvdec > + - nvidia,tegra194-nvdec > + > + reg: > +maxItems: 1 > + > + clocks: > +maxItems: 1 > + > + clock-names: > +items: > + - const: nvdec > + > + resets: > +maxItems: 1 > + > + reset-names: > +items: > + - const: nvdec > + > + power-domains: > +maxItems: 1 > + > + iommus: > +maxItems: 1 > + > + interconnects: > +items: > + - description: DMA read memory client > + - description: DMA read 2 memory client > + - description: DMA write memory client > + > + interconnect-names: > +items: > + - const: dma-mem > + - const: read2 The convention that we've used so far has been to start numbering these at 0 and use a dash, so this would be "read-1". > + - const: write > + > +required: > + - compatible > + - reg > + - clocks > + - clock-names > + - resets > + - reset-names > + - power-domains > + > +if: > + properties: > +compatible: > + contains: > +const: nvidia,tegra194-host1x > +then: > + properties: > +nvidia,instance: > + items: > +- description: 0 for NVDEC0, or 1 for NVDEC1 I know we had discussed this before, but looking at the driver patch, I don't actually see this being used now, so I wonder if we still need it. > +additionalProperties: true Maybe this should have a comment noting that this should really be unevaluatedProperties: false, but we can't use that because the tooling doesn't support it yet? Rob, what's the current best practice for that? I see that there are quite a few bindings that use unevaluatedProperties, so I wonder if we just ignore errors from that for now? Or do we have some development branch of the tooling somewhere that supports this now? I vaguely recall reading about work in progress patches for this, but I can't find the link now to see if there's been an update since I last looked. Thierry signature.asc Description: PGP signature
[syzbot] general protection fault in udmabuf_create
Hello,
syzbot found the following issue on:
HEAD commit:7999516e20bd Add linux-next specific files for 20210806
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=10f15f8e30
kernel config: https://syzkaller.appspot.com/x/.config?x=2f518e910b029c31
dashboard link: https://syzkaller.appspot.com/bug?extid=e9cd3122a37c5d6c51e8
compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for
Debian) 2.35.1
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1181099a30
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=11b6fce930
The issue was bisected to:
commit 16c243e99d335e1ef3059871897119affc98b493
Author: Vivek Kasireddy
Date: Wed Jun 9 18:29:15 2021 +
udmabuf: Add support for mapping hugepages (v4)
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=12f73dc930
final oops: https://syzkaller.appspot.com/x/report.txt?x=11f73dc930
console output: https://syzkaller.appspot.com/x/log.txt?x=16f73dc930
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+e9cd3122a37c5d6c5...@syzkaller.appspotmail.com
Fixes: 16c243e99d33 ("udmabuf: Add support for mapping hugepages (v4)")
general protection fault, probably for non-canonical address
0xdc01: [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0008-0x000f]
CPU: 0 PID: 6603 Comm: syz-executor127 Not tainted
5.14.0-rc4-next-20210806-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
01/01/2011
RIP: 0010:_compound_head include/linux/page-flags.h:187 [inline]
RIP: 0010:get_page include/linux/mm.h:1203 [inline]
RIP: 0010:udmabuf_create+0x664/0x16f0 drivers/dma-buf/udmabuf.c:236
Code: 03 48 89 84 24 90 00 00 00 e9 38 01 00 00 e8 23 7a f7 fc 4d 89 f4 49 c1
e4 06 4c 03 24 24 49 8d 7c 24 08 48 89 f8 48 c1 e8 03 <42> 80 3c 38 00 0f 85 d3
0d 00 00 4d 8b 6c 24 08 31 ff 4c 89 eb 83
RSP: 0018:c90002d7fc70 EFLAGS: 00010202
RAX: 0001 RBX: RCX:
RDX: 888023f69c80 RSI: 847e4f3d RDI: 0008
RBP: R08: f000 R09:
R10: 847e50f5 R11: R12:
R13: R14: R15: dc00
FS: 00935300() GS:8880b9c0() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 220c CR3: 18d16000 CR4: 001506f0
DR0: DR1: DR2:
DR3: DR6: fffe0ff0 DR7: 0400
Call Trace:
udmabuf_ioctl_create drivers/dma-buf/udmabuf.c:305 [inline]
udmabuf_ioctl+0x152/0x2c0 drivers/dma-buf/udmabuf.c:336
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:874 [inline]
__se_sys_ioctl fs/ioctl.c:860 [inline]
__x64_sys_ioctl+0x193/0x200 fs/ioctl.c:860
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x43eed9
Code: 28 c3 e8 2a 14 00 00 66 2e 0f 1f 84 00 00 00 00 00 48 89 f8 48 89 f7 48
89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01
c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:7fff10c6b558 EFLAGS: 0246 ORIG_RAX: 0010
RAX: ffda RBX: 00400488 RCX: 0043eed9
RDX: 2180 RSI: 40187542 RDI: 0003
RBP: 00402ec0 R08: 00400488 R09: 00400488
R10: 00400488 R11: 0246 R12: 00402f50
R13: R14: 004ac018 R15: 00400488
Modules linked in:
---[ end trace e38355abd6102561 ]---
RIP: 0010:_compound_head include/linux/page-flags.h:187 [inline]
RIP: 0010:get_page include/linux/mm.h:1203 [inline]
RIP: 0010:udmabuf_create+0x664/0x16f0 drivers/dma-buf/udmabuf.c:236
Code: 03 48 89 84 24 90 00 00 00 e9 38 01 00 00 e8 23 7a f7 fc 4d 89 f4 49 c1
e4 06 4c 03 24 24 49 8d 7c 24 08 48 89 f8 48 c1 e8 03 <42> 80 3c 38 00 0f 85 d3
0d 00 00 4d 8b 6c 24 08 31 ff 4c 89 eb 83
RSP: 0018:c90002d7fc70 EFLAGS: 00010202
RAX: 0001 RBX: RCX:
RDX: 888023f69c80 RSI: 847e4f3d RDI: 0008
RBP: R08: f000 R09:
R10: 847e50f5 R11: R12:
R13: R14: R15: dc00
FS: 00935300() GS:8880b9d0() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 7fff86ca0778 CR3: 18d16000 CR4: 001506e0
DR0: DR1: DR2:
DR3: DR6: fffe0ff0 DR7: 0400
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more inf
Re: [PATCH v2 1/3] dt-bindings: Add YAML bindings for Host1x and NVDEC
On Tue, Aug 10, 2021 at 05:43:26PM +0200, Thierry Reding wrote: > On Fri, Aug 06, 2021 at 03:34:48PM +0300, Mikko Perttunen wrote: [...] > > diff --git > > a/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvdec.yaml > > b/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvdec.yaml [...] > > +if: > > + properties: > > +compatible: > > + contains: > > +const: nvidia,tegra194-host1x > > +then: > > + properties: > > +nvidia,instance: > > + items: > > +- description: 0 for NVDEC0, or 1 for NVDEC1 > > I know we had discussed this before, but looking at the driver patch, I > don't actually see this being used now, so I wonder if we still need it. Oh, nevermind, upon closer inspection, I do see it used in the driver. Thierry signature.asc Description: PGP signature
Re: [PATCH v3 2/4] drm: rcar-du: lvds: Convert to DRM panel bridge helper
Hi Laurent,
On Thu, May 20, 2021 at 8:51 AM Laurent Pinchart
wrote:
> Replace the manual panel handling with usage of the DRM panel bridge
> helper. This simplifies the driver, and brings support for
> DRM_BRIDGE_ATTACH_NO_CONNECTOR as an added bonus.
>
> Signed-off-by: Laurent Pinchart
Thanks for your patch, which is now commit e9e056949c927e5b ("drm:
rcar-du: lvds: Convert to DRM panel bridge helper") in drm-next.
This causes the following scary messages in the kernel log on Ebisu-4D:
[drm:drm_bridge_attach] *ERROR* failed to attach bridge
/soc/lvds-encoder@feb90100 to encoder None-66: -22
renesas_sdhi_internal_dmac ee10.mmc: mmc1 base at
0xee10, max clock rate 200 MHz
rcar-du feb0.display: failed to initialize encoder
/soc/lvds-encoder@feb90100 on output 3 (-22), skipping
renesas_sdhi_internal_dmac ee12.mmc: mmc2 base at
0xee12, max clock rate 200 MHz
[ cut here ]
renesas_sdhi_internal_dmac ee16.mmc: mmc0 base at
0xee16, max clock rate 200 MHz
possible_clones mismatch: [ENCODER:62:None-62] mask=0x1
possible_clones=0x3 vs. [ENCODER:66:None-66] mask=0x4
possible_clones=0x3
WARNING: CPU: 1 PID: 68 at drivers/gpu/drm/drm_mode_config.c:583
drm_mode_config_validate+0x3cc/0x4c8
CPU: 1 PID: 68 Comm: kworker/u4:2 Not tainted
5.14.0-rc3-arm64-renesas-00324-ge9e056949c92 #1277
Hardware name: Renesas Ebisu-4D board based on r8a77990 (DT)
Workqueue: events_unbound deferred_probe_work_func
pstate: 6005 (nZCv daif -PAN -UAO -TCO BTYPE=--)
pc : drm_mode_config_validate+0x3cc/0x4c8
lr : drm_mode_config_validate+0x3cc/0x4c8
sp : 80001239ba80
x29: 80001239ba90 x28: 0801c005 x27: 0001
x26: 09de8868 x25: 001f x24: 0a490f80
mmc0: new HS400 MMC card at address 0001
x23: 09de8868 x22: 800011029ea0 x21: 800011029e20
x20: 09de8018 x19: 0a490b80 x18: 0020
x17: 7364766c2f636f73 x16: 4a12 x15: 0892df38
x14: x13: 0003 x12: 8000113e3a80
x11: 0001 x10: 0078
mmcblk0: mmc0:0001 BGSD3R 29.1 GiB
x9 : 800011172994
x8 : x7 : 0001 x6 : 0001
x5 : x4 : 0003 x3 :
x2 : 8000113e38d8 x1 : x0 :
Call trace:
drm_mode_config_validate+0x3cc/0x4c8
drm_dev_register+0x174/0x208
rcar_du_probe+0xc4/0x110
platform_probe+0x64/0xd0
really_probe+0x134/0x2e8
__driver_probe_device+0x74/0xd8
driver_probe_device+0x3c/0xe0
__device_attach_driver+0xa8/0xf0
bus_for_each_drv+0x74/0xc8
__device_attach+0xec/0x148
device_initial_probe+0x10/0x18
bus_probe_device+0x98/0xa0
mmcblk0boot0: mmc0:0001 BGSD3R 16.0 MiB
deferred_probe_work_func+0x88/0xc0
process_one_work+0x284/0x6d0
worker_thread+0x48/0x418
kthread+0x14c/0x158
ret_from_fork+0x10/0x18
irq event stamp: 27688
hardirqs last enabled at (27687): [] vprintk_emit+0x2f4/0x2f8
hardirqs last disabled at (27688): [] el1_dbg+0x24/0x88
mmcblk0boot1: mmc0:0001 BGSD3R 16.0 MiB
softirqs last enabled at (27616): [] _stext+0x4ac/0x620
softirqs last disabled at (27607): [] irq_exit+0x1b4/0x1c0
---[ end trace 6e42cb0428a6481b ]---
[ cut here ]
mmcblk0rpmb: mmc0:0001 BGSD3R 4.00 MiB, chardev (243:0)
possible_clones mismatch: [ENCODER:64:None-64] mask=0x2
possible_clones=0x3 vs. [ENCODER:66:None-66] mask=0x4
possible_clones=0x3
WARNING: CPU: 1 PID: 68 at drivers/gpu/drm/drm_mode_config.c:583
drm_mode_config_validate+0x3cc/0x4c8
CPU: 1 PID: 68 Comm: kworker/u4:2 Tainted: GW
5.14.0-rc3-arm64-renesas-00324-ge9e056949c92 #1277
Hardware name: Renesas Ebisu-4D board based on r8a77990 (DT)
Workqueue: events_unbound deferred_probe_work_func
pstate: 6005 (nZCv daif -PAN -UAO -TCO BTYPE=--)
pc : drm_mode_config_validate+0x3cc/0x4c8
lr : drm_mode_config_validate+0x3cc/0x4c8
sp : 80001239ba80
x29: 80001239ba90 x28: 0801c005 x27: 0001
x26: 09de8868 x25: 001f x24: 0a490f80
x23: 09de8868 x22: 800011029ea0 x21: 800011029e20
x20: 09de8018 x19: 0a490d80 x18: 0010
x17: 746978655f717269 x16: 205d3e636438 x15: 076c0763075f0765
x14: 014d x13: 0892df38 x12: ffea
x11: 800011453b70 x10: 80001143bb30 x9 : 80001143bb88
x8 : x7 : 0001 x6 : 0001
x5 : x4 : 0003 x3 :
x2 : 8000113e38d8 x1 : x0 :
Call trace:
drm_mode_config_validate+0x3cc/0x4c8
drm_dev_register+0x174/0x208
rcar_du_probe+0xc4/0x110
platform_probe+0x64/0xd0
really_probe+0x134/0x2e8
__driver_probe_device+0x74/0xd8
driver_probe_device+0x3c/0xe0
__device_attach_driver+0xa8/0xf0
bus_for_each_drv+0x74/0xc8
__device_attach+0xec/0x148
device_initial_probe+0x10/0x18
bus_probe_device+0x98/0xa0
Re: [PATCH v2 1/3] dt-bindings: Add YAML bindings for Host1x and NVDEC
On 10.8.2021 18.43, Thierry Reding wrote: On Fri, Aug 06, 2021 at 03:34:48PM +0300, Mikko Perttunen wrote: Convert the original Host1x bindings to YAML and add new bindings for NVDEC, now in a more appropriate location. The old text bindings for Host1x and engines are still kept at display/tegra/ since they encompass a lot more engines that haven't been converted over yet. Signed-off-by: Mikko Perttunen --- v2: * Fix issues pointed out in v1 * Add T194 nvidia,instance property --- .../gpu/host1x/nvidia,tegra20-host1x.yaml | 131 ++ .../gpu/host1x/nvidia,tegra210-nvdec.yaml | 109 +++ MAINTAINERS | 1 + 3 files changed, 241 insertions(+) create mode 100644 Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra20-host1x.yaml create mode 100644 Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvdec.yaml Can we split off the NVDEC bindings addition into a separate patch? I've been working on converting the existing host1x bindings in full to json- schema and this partial conversion would conflict with that effort. I assume that NVDEC itself validates properly even if host1x hasn't been converted yet? Sure. I thought I had some problems with this before but can't see any now. diff --git a/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvdec.yaml b/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvdec.yaml new file mode 100644 index ..fc535bb7aee0 --- /dev/null +++ b/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvdec.yaml @@ -0,0 +1,109 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/gpu/host1x/nvidia,tegra210-nvdec.yaml#"; +$schema: "http://devicetree.org/meta-schemas/core.yaml#"; + +title: Device tree binding for NVIDIA Tegra NVDEC + +description: | + NVDEC is the hardware video decoder present on NVIDIA Tegra210 + and newer chips. It is located on the Host1x bus and typically + programmed through Host1x channels. + +maintainers: + - Thierry Reding + - Mikko Perttunen + +properties: + $nodename: +pattern: "^nvdec@[0-9a-f]*$" + + compatible: +enum: + - nvidia,tegra210-nvdec + - nvidia,tegra186-nvdec + - nvidia,tegra194-nvdec + + reg: +maxItems: 1 + + clocks: +maxItems: 1 + + clock-names: +items: + - const: nvdec + + resets: +maxItems: 1 + + reset-names: +items: + - const: nvdec + + power-domains: +maxItems: 1 + + iommus: +maxItems: 1 + + interconnects: +items: + - description: DMA read memory client + - description: DMA read 2 memory client + - description: DMA write memory client + + interconnect-names: +items: + - const: dma-mem + - const: read2 The convention that we've used so far has been to start numbering these at 0 and use a dash, so this would be "read-1". Will fix. + - const: write + +required: + - compatible + - reg + - clocks + - clock-names + - resets + - reset-names + - power-domains + +if: + properties: +compatible: + contains: +const: nvidia,tegra194-host1x +then: + properties: +nvidia,instance: + items: +- description: 0 for NVDEC0, or 1 for NVDEC1 I know we had discussed this before, but looking at the driver patch, I don't actually see this being used now, so I wonder if we still need it. +additionalProperties: true Maybe this should have a comment noting that this should really be unevaluatedProperties: false, but we can't use that because the tooling doesn't support it yet? I can add such a comment if desired. Honestly, I don't really know what 'unevaluatedProperties' means or does -- the explanation in example-schema.yaml doesn't seem like it's relevant here and I cannot find any other documentation. Thanks, Mikko Rob, what's the current best practice for that? I see that there are quite a few bindings that use unevaluatedProperties, so I wonder if we just ignore errors from that for now? Or do we have some development branch of the tooling somewhere that supports this now? I vaguely recall reading about work in progress patches for this, but I can't find the link now to see if there's been an update since I last looked. Thierry
Re: [PATCH v3 2/4] drm: rcar-du: lvds: Convert to DRM panel bridge helper
Hi Laurent,
On Tue, Aug 10, 2021 at 5:47 PM Geert Uytterhoeven wrote:
> On Thu, May 20, 2021 at 8:51 AM Laurent Pinchart
> wrote:
> > Replace the manual panel handling with usage of the DRM panel bridge
> > helper. This simplifies the driver, and brings support for
> > DRM_BRIDGE_ATTACH_NO_CONNECTOR as an added bonus.
> >
> > Signed-off-by: Laurent Pinchart
>
> Thanks for your patch, which is now commit e9e056949c927e5b ("drm:
> rcar-du: lvds: Convert to DRM panel bridge helper") in drm-next.
>
> This causes the following scary messages in the kernel log on Ebisu-4D:
>
> [drm:drm_bridge_attach] *ERROR* failed to attach bridge
> Reverting this commit fixes the issue.
Oops, that's not true (should not write tentative messages while booting
a test kernel, and press send without checking first ;-)
Reverting the commit doesn't seem to make a difference.
But the parent 5bcc48395b9f35da ("drm: bridge: dw-hdmi: Attach to
next bridge if available") of the bad commit is fine.
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 3/3] drm/tegra: Add NVDEC driver
On Fri, Aug 06, 2021 at 03:34:50PM +0300, Mikko Perttunen wrote:
> Add support for booting and using NVDEC on Tegra210, Tegra186
> and Tegra194 to the Host1x and TegraDRM drivers. Booting in
> secure mode is not currently supported.
>
> Signed-off-by: Mikko Perttunen
> ---
> v2:
> * Use devm_platform_get_and_ioremap_resource
> * Remove reset handling, done by power domain code
> * Assume runtime PM is enabled
> ---
> drivers/gpu/drm/tegra/Makefile | 3 +-
> drivers/gpu/drm/tegra/drm.c| 4 +
> drivers/gpu/drm/tegra/drm.h| 1 +
> drivers/gpu/drm/tegra/nvdec.c | 473 +
> drivers/gpu/host1x/dev.c | 18 ++
> include/linux/host1x.h | 2 +
> 6 files changed, 500 insertions(+), 1 deletion(-)
> create mode 100644 drivers/gpu/drm/tegra/nvdec.c
>
> diff --git a/drivers/gpu/drm/tegra/Makefile b/drivers/gpu/drm/tegra/Makefile
> index 5d2039f0c734..b248c631f790 100644
> --- a/drivers/gpu/drm/tegra/Makefile
> +++ b/drivers/gpu/drm/tegra/Makefile
> @@ -24,7 +24,8 @@ tegra-drm-y := \
> gr2d.o \
> gr3d.o \
> falcon.o \
> - vic.o
> + vic.o \
> + nvdec.o
>
> tegra-drm-y += trace.o
>
> diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
> index b20fd0833661..5f5afd7ba37e 100644
> --- a/drivers/gpu/drm/tegra/drm.c
> +++ b/drivers/gpu/drm/tegra/drm.c
> @@ -1337,15 +1337,18 @@ static const struct of_device_id host1x_drm_subdevs[]
> = {
> { .compatible = "nvidia,tegra210-sor", },
> { .compatible = "nvidia,tegra210-sor1", },
> { .compatible = "nvidia,tegra210-vic", },
> + { .compatible = "nvidia,tegra210-nvdec", },
> { .compatible = "nvidia,tegra186-display", },
> { .compatible = "nvidia,tegra186-dc", },
> { .compatible = "nvidia,tegra186-sor", },
> { .compatible = "nvidia,tegra186-sor1", },
> { .compatible = "nvidia,tegra186-vic", },
> + { .compatible = "nvidia,tegra186-nvdec", },
> { .compatible = "nvidia,tegra194-display", },
> { .compatible = "nvidia,tegra194-dc", },
> { .compatible = "nvidia,tegra194-sor", },
> { .compatible = "nvidia,tegra194-vic", },
> + { .compatible = "nvidia,tegra194-nvdec", },
> { /* sentinel */ }
> };
>
> @@ -1369,6 +1372,7 @@ static struct platform_driver * const drivers[] = {
> &tegra_gr2d_driver,
> &tegra_gr3d_driver,
> &tegra_vic_driver,
> + &tegra_nvdec_driver,
> };
>
> static int __init host1x_drm_init(void)
> diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
> index 8b28327c931c..fc0a19554eac 100644
> --- a/drivers/gpu/drm/tegra/drm.h
> +++ b/drivers/gpu/drm/tegra/drm.h
> @@ -202,5 +202,6 @@ extern struct platform_driver tegra_sor_driver;
> extern struct platform_driver tegra_gr2d_driver;
> extern struct platform_driver tegra_gr3d_driver;
> extern struct platform_driver tegra_vic_driver;
> +extern struct platform_driver tegra_nvdec_driver;
>
> #endif /* HOST1X_DRM_H */
> diff --git a/drivers/gpu/drm/tegra/nvdec.c b/drivers/gpu/drm/tegra/nvdec.c
> new file mode 100644
> index ..4a58b5357473
> --- /dev/null
> +++ b/drivers/gpu/drm/tegra/nvdec.c
> @@ -0,0 +1,473 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) 2015-2021, NVIDIA Corporation.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#include "drm.h"
> +#include "falcon.h"
> +#include "vic.h"
> +
> +struct nvdec_config {
> + const char *firmware;
> + unsigned int version;
> + bool supports_sid;
> + int num_instances;
This can be unsigned int.
> +};
> +
> +struct nvdec {
> + struct falcon falcon;
> +
> + void __iomem *regs;
> + struct tegra_drm_client client;
Traditionally this goes first to make the to_nvdec() cast helper a
no-op. But I see that we also got this wrong for VIC, and that's
probably where you copied this from. So nevermind, we can fix that
in a later patch.
> + struct host1x_channel *channel;
> + struct device *dev;
> + struct clk *clk;
> +
> + /* Platform configuration */
> + const struct nvdec_config *config;
> +};
> +
> +static inline struct nvdec *to_nvdec(struct tegra_drm_client *client)
> +{
> + return container_of(client, struct nvdec, client);
> +}
> +
> +static void nvdec_writel(struct nvdec *nvdec, u32 value, unsigned int offset)
> +{
> + writel(value, nvdec->regs + offset);
> +}
> +
> +static int nvdec_boot(struct nvdec *nvdec)
> +{
> +#ifdef CONFIG_IOMMU_API
> + struct iommu_fwspec *spec = dev_iommu_fwspec_get(nvdec->dev);
> +#endif
> + int err = 0;
Why does this need to be initialized?
> +
> +#ifdef CONFIG_IOMMU_API
> + if (nvdec->config->supports_sid && spec) {
> + u32 value;
> +
> + value = TRANSCFG_ATT(1, TRANSCFG_SID_FALCON) |
> + TRANSCFG_ATT(0, TRANSCFG_SID_HW);
This f
Re: [PATCH v2 1/3] dt-bindings: Add YAML bindings for Host1x and NVDEC
On Tue, Aug 10, 2021 at 06:50:26PM +0300, Mikko Perttunen wrote: > On 10.8.2021 18.43, Thierry Reding wrote: > > On Fri, Aug 06, 2021 at 03:34:48PM +0300, Mikko Perttunen wrote: > > > Convert the original Host1x bindings to YAML and add new bindings for > > > NVDEC, now in a more appropriate location. The old text bindings > > > for Host1x and engines are still kept at display/tegra/ since they > > > encompass a lot more engines that haven't been converted over yet. > > > > > > Signed-off-by: Mikko Perttunen > > > --- > > > v2: > > > * Fix issues pointed out in v1 > > > * Add T194 nvidia,instance property > > > --- > > > .../gpu/host1x/nvidia,tegra20-host1x.yaml | 131 ++ > > > .../gpu/host1x/nvidia,tegra210-nvdec.yaml | 109 +++ > > > MAINTAINERS | 1 + > > > 3 files changed, 241 insertions(+) > > > create mode 100644 > > > Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra20-host1x.yaml > > > create mode 100644 > > > Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvdec.yaml > > > > Can we split off the NVDEC bindings addition into a separate patch? I've > > been working on converting the existing host1x bindings in full to json- > > schema and this partial conversion would conflict with that effort. > > > > I assume that NVDEC itself validates properly even if host1x hasn't been > > converted yet? > > Sure. I thought I had some problems with this before but can't see any now. > > > > > > diff --git > > > a/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvdec.yaml > > > b/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvdec.yaml > > > new file mode 100644 > > > index ..fc535bb7aee0 > > > --- /dev/null > > > +++ > > > b/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvdec.yaml > > > @@ -0,0 +1,109 @@ > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > > > +%YAML 1.2 > > > +--- > > > +$id: > > > "http://devicetree.org/schemas/gpu/host1x/nvidia,tegra210-nvdec.yaml#"; > > > +$schema: "http://devicetree.org/meta-schemas/core.yaml#"; > > > + > > > +title: Device tree binding for NVIDIA Tegra NVDEC > > > + > > > +description: | > > > + NVDEC is the hardware video decoder present on NVIDIA Tegra210 > > > + and newer chips. It is located on the Host1x bus and typically > > > + programmed through Host1x channels. > > > + > > > +maintainers: > > > + - Thierry Reding > > > + - Mikko Perttunen > > > + > > > +properties: > > > + $nodename: > > > +pattern: "^nvdec@[0-9a-f]*$" > > > + > > > + compatible: > > > +enum: > > > + - nvidia,tegra210-nvdec > > > + - nvidia,tegra186-nvdec > > > + - nvidia,tegra194-nvdec > > > + > > > + reg: > > > +maxItems: 1 > > > + > > > + clocks: > > > +maxItems: 1 > > > + > > > + clock-names: > > > +items: > > > + - const: nvdec > > > + > > > + resets: > > > +maxItems: 1 > > > + > > > + reset-names: > > > +items: > > > + - const: nvdec > > > + > > > + power-domains: > > > +maxItems: 1 > > > + > > > + iommus: > > > +maxItems: 1 > > > + > > > + interconnects: > > > +items: > > > + - description: DMA read memory client > > > + - description: DMA read 2 memory client > > > + - description: DMA write memory client > > > + > > > + interconnect-names: > > > +items: > > > + - const: dma-mem > > > + - const: read2 > > > > The convention that we've used so far has been to start numbering these > > at 0 and use a dash, so this would be "read-1". > > Will fix. > > > > > > + - const: write > > > + > > > +required: > > > + - compatible > > > + - reg > > > + - clocks > > > + - clock-names > > > + - resets > > > + - reset-names > > > + - power-domains > > > + > > > +if: > > > + properties: > > > +compatible: > > > + contains: > > > +const: nvidia,tegra194-host1x > > > +then: > > > + properties: > > > +nvidia,instance: > > > + items: > > > +- description: 0 for NVDEC0, or 1 for NVDEC1 > > > > I know we had discussed this before, but looking at the driver patch, I > > don't actually see this being used now, so I wonder if we still need it. > > > > > +additionalProperties: true > > > > Maybe this should have a comment noting that this should really be > > unevaluatedProperties: false, but we can't use that because the tooling > > doesn't support it yet? > > I can add such a comment if desired. Honestly, I don't really know what > 'unevaluatedProperties' means or does -- the explanation in > example-schema.yaml doesn't seem like it's relevant here and I cannot find > any other documentation. It's basically like additionalProperties, except that it applies to properties evaluated via if: blocks. So with additionalProperties: false, the presence of the nvidia,instance property in a Tegra194 DTS file would cause a validation failure because it's a property that was not def
[PATCH] drm/panel: Add inx Himax8279d MIPI-DSI LCD panel driver
Hi, could you help to review this patch? This patch has been applied to our devices which use INX 2081101qfh032011-53g 1200x1920 video panel and it works well. thanks.
How to obtain a drm lease from X for overlay planes as well as a primary plane?
Hi all I am on a Raspberry Pi, I want to display fullscreen video and have a couple of overlay planes to display controls / subtitles etc. The h/w can certainly do this. I need to be able to do this from a starting point where X is running. I can successfully find X's output & crtc and grab that using xcb_randr_create_lease and use that handle to display video. So far so good. But I also want to have overlay planes for subtitles etc. The handle I've got from the lease only seems to have a PRIMARY & a CURSOR plane attached so I can't get anything there. How should I be going about getting some more planes to use for overlays? Pointers to documentation / examples gratefully received - so far my google-foo has failed to find anything that works. I'm sorry if this is the wrong place to ask, but if there is a better place please say and I'll go there. Many thanks John Cox
Re: [PATCH 25/46] drm/i915/guc: Update debugfs for GuC multi-lrc
On Tue, Aug 10, 2021 at 11:27:31AM +0200, Daniel Vetter wrote:
> On Tue, Aug 10, 2021 at 11:23:39AM +0200, Daniel Vetter wrote:
> > On Mon, Aug 09, 2021 at 07:13:11PM +, Matthew Brost wrote:
> > > On Mon, Aug 09, 2021 at 06:36:44PM +0200, Daniel Vetter wrote:
> > > > On Tue, Aug 03, 2021 at 03:29:22PM -0700, Matthew Brost wrote:
> > > > > Display the workqueue status in debugfs for GuC contexts that are in
> > > > > parent-child relationship.
> > > > >
> > > > > Signed-off-by: Matthew Brost
> > > > > ---
> > > > > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 56
> > > > > +--
> > > > > 1 file changed, 39 insertions(+), 17 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > > > b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > > > index 30df1c8db491..44a7582c9aed 100644
> > > > > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > > > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > > > @@ -4527,31 +4527,53 @@ void intel_guc_submission_print_info(struct
> > > > > intel_guc *guc,
> > > > > gse_log_submission_info(guc->gse[i], p, i);
> > > > > }
> > > > >
> > > > > +static inline void guc_log_context(struct drm_printer *p,
> > > > > +struct intel_context *ce)
> > > > > +{
> > > > > + drm_printf(p, "GuC lrc descriptor %u:\n", ce->guc_id);
> > > > > + drm_printf(p, "\tHW Context Desc: 0x%08x\n", ce->lrc.lrca);
> > > > > + drm_printf(p, "\t\tLRC Head: Internal %u, Memory %u\n",
> > > > > +ce->ring->head,
> > > > > +ce->lrc_reg_state[CTX_RING_HEAD]);
> > > > > + drm_printf(p, "\t\tLRC Tail: Internal %u, Memory %u\n",
> > > > > +ce->ring->tail,
> > > > > +ce->lrc_reg_state[CTX_RING_TAIL]);
> > > > > + drm_printf(p, "\t\tContext Pin Count: %u\n",
> > > > > +atomic_read(&ce->pin_count));
> > > > > + drm_printf(p, "\t\tGuC ID Ref Count: %u\n",
> > > > > +atomic_read(&ce->guc_id_ref));
> > > > > + drm_printf(p, "\t\tNumber Requests Not Ready: %u\n",
> > > > > +atomic_read(&ce->guc_num_rq_not_ready));
> > > > > + drm_printf(p, "\t\tSchedule State: 0x%x, 0x%x\n\n",
> > > > > +ce->guc_state.sched_state,
> > > > > +atomic_read(&ce->guc_sched_state_no_lock));
> > > >
> > > > It's all debugfs, but I think proper locking even there is good. It at
> > > > least reduces the confusion when the locking scheme is largely
> > > > undocumented. Also given how much we have rcu for everything would be
> > > > good
> > > > to double-check all pointer dererences are properly protected.
> > > >
> > >
> > > Not sure if I 100% follow this but I don't think any of the pointers
> > > dref here are RCU protected. Certainly none of the GuC ones are.
> > >
> > > Will double before the next respin though.
> > >
> > > > > +}
> > > > > +
> > > > > void intel_guc_submission_print_context_info(struct intel_guc *guc,
> > > > >struct drm_printer *p)
> > > > > {
> > > > > struct intel_context *ce;
> > > > > unsigned long index;
> > > > > xa_for_each(&guc->context_lookup, index, ce) {
> > > >
> > > > xa_for_each doesn't provide any guarantees, so doesn't protect against
> > > > concurrent removeal or anything like that. We need to do better than
> > > > that.
> > >
> > > https://elixir.bootlin.com/linux/latest/source/include/linux/xarray.h#L498
> > > 'It is safe to modify the array during the iteration.'
> >
> > The xarray. Not the thing you're dereferencing, because the xarray only
> > stores pointers, not your data structure. So yeah correct statement is
> > that it doesn't provide you any guarantees beyond "the iterator wont be
> > confused if the xarray itself is modified during iteration". Which isn't
> > what you need here, you need a lot more.
>
> Or spelled out: The pointer you get could become immediately meaningless,
> before you can look at it, due to a concurrent removal/release. All the
> xa_for_each guarantees you is that on the next round you get the next
> pointer, until you got them all (plus/minus concurrent changes). But that
> next pointer could have become meaningless right away too.
>
> So you need your own locking to make use of these pointers you got and
> make sure they're not immediately meaningless before your loop body even
> started.
>
Ok, I think I see your point. Likely whenever we do a xa_for_each over
&guc->context_lookup we should just grab its lock as if it is in the
xarray we have reference to object looked up. Also everytime we use
xa_for_each on &guc->context_lookup it is a corner case we it is ok to
block anyone else from using this (e.g. during a reset, checking
debugfs, etc...). Does that sound correct?
Matt
> One of the reasons why I think this is so important is that debugfs files
> nest a lot of loops
[PATCH 5.13 059/175] drm/i915: fix i915_globals_exit() section mismatch error
From: Randy Dunlap
[ Upstream commit a07296453bf2778952a09b6244a695bf7607babb ]
Fix modpost Section mismatch error in i915_globals_exit().
Since both an __init function and an __exit function can call
i915_globals_exit(), any function that i915_globals_exit() calls
should not be marked as __init or __exit. I.e., it needs to be
available for either of them.
WARNING: modpost: vmlinux.o(.text+0x8b796a): Section mismatch in reference from
the function i915_globals_exit() to the function
.exit.text:__i915_globals_flush()
The function i915_globals_exit() references a function in an exit section.
Often the function __i915_globals_flush() has valid usage outside the exit
section
and the fix is to remove the __exit annotation of __i915_globals_flush.
ERROR: modpost: Section mismatches detected.
Set CONFIG_SECTION_MISMATCH_WARN_ONLY=y to allow them.
Fixes: 1354d830cb8f ("drm/i915: Call i915_globals_exit() if
pci_register_device() fails")
Signed-off-by: Randy Dunlap
Cc: Jason Ekstrand
Cc: Daniel Vetter
Cc: Rodrigo Vivi
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: intel-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Dave Airlie
Link:
https://patchwork.freedesktop.org/patch/msgid/20210804204147.2070-1-rdun...@infradead.org
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/i915/i915_globals.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_globals.c
b/drivers/gpu/drm/i915/i915_globals.c
index e27739a50bee..57d2943884ab 100644
--- a/drivers/gpu/drm/i915/i915_globals.c
+++ b/drivers/gpu/drm/i915/i915_globals.c
@@ -139,7 +139,7 @@ void i915_globals_unpark(void)
atomic_inc(&active);
}
-static void __exit __i915_globals_flush(void)
+static void __i915_globals_flush(void)
{
atomic_inc(&active); /* skip shrinking */
--
2.30.2
[PATCH 5.13 081/175] drm/amdgpu: fix checking pmops when PM_SLEEP is not enabled
From: Randy Dunlap
commit 5706cb3c910cc8283f344bc37a889a8d523a2c6d upstream.
'pm_suspend_target_state' is only available when CONFIG_PM_SLEEP
is set/enabled. OTOH, when both SUSPEND and HIBERNATION are not set,
PM_SLEEP is not set, so this variable cannot be used.
../drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c: In function
‘amdgpu_acpi_is_s0ix_active’:
../drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:1046:11: error:
‘pm_suspend_target_state’ undeclared (first use in this function); did you mean
‘__KSYM_pm_suspend_target_state’?
return pm_suspend_target_state == PM_SUSPEND_TO_IDLE;
^~~
__KSYM_pm_suspend_target_state
Also use shorter IS_ENABLED(CONFIG_foo) notation for checking the
2 config symbols.
Fixes: 91e273712ab8dd ("drm/amdgpu: Check pmops for desired suspend state")
Signed-off-by: Randy Dunlap
Cc: Alex Deucher
Cc: Christian König
Cc: "Pan, Xinhui"
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-n...@vger.kernel.org
Signed-off-by: Alex Deucher
Cc: sta...@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
@@ -904,7 +904,7 @@ void amdgpu_acpi_fini(struct amdgpu_devi
*/
bool amdgpu_acpi_is_s0ix_supported(struct amdgpu_device *adev)
{
-#if defined(CONFIG_AMD_PMC) || defined(CONFIG_AMD_PMC_MODULE)
+#if IS_ENABLED(CONFIG_AMD_PMC) && IS_ENABLED(CONFIG_PM_SLEEP)
if (acpi_gbl_FADT.flags & ACPI_FADT_LOW_POWER_S0) {
if (adev->flags & AMD_IS_APU)
return pm_suspend_target_state == PM_SUSPEND_TO_IDLE;
Re: [PATCH v2] drm/msm/dp: add drm debug logs to dp_pm_resume/suspend
Quoting Kuogee Hsieh (2021-08-10 08:29:22)
> Changes in V2:
> -- correct Fixes text
> -- drop commit text
>
> Fixes: 601f0479c583 ("drm/msm/dp: add logs across DP driver for ease of
> debugging")
> Signed-off-by: Kuogee Hsieh
> ---
Reviewed-by: Stephen Boyd
Re: [PATCH v2] drm/msm/dp: add drm debug logs to dp_pm_resume/suspend
Quoting Kuogee Hsieh (2021-08-10 08:29:22)
> Changes in V2:
> -- correct Fixes text
> -- drop commit text
>
> Fixes: 601f0479c583 ("drm/msm/dp: add logs across DP driver for ease of
> debugging")
> Signed-off-by: Kuogee Hsieh
> ---
> drivers/gpu/drm/msm/dp/dp_display.c | 13 +
> 1 file changed, 13 insertions(+)
BTW, this conflicts with commit e8a767e04dbc7b201cb17ab99dca723a3488b6d4
in msm-next. The resolution is trivial but just wanted to mention it.
[Bug 214029] New: [NAVI] Several memory leaks in amdgpu and ttm
https://bugzilla.kernel.org/show_bug.cgi?id=214029 Bug ID: 214029 Summary: [NAVI] Several memory leaks in amdgpu and ttm Product: Drivers Version: 2.5 Kernel Version: 5.14-rc5 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: erhar...@mailbox.org CC: dan...@ffwll.ch Regression: No Created attachment 298265 --> https://bugzilla.kernel.org/attachment.cgi?id=298265&action=edit kernel dmesg (kernel 5.14-rc5, AMD FX-8370) Getting this on kernel 5.14-rc5 with my Radeon RX 5500. unreferenced object 0x888169af1b40 (size 216): comm "lightdm-gtk-gre", pid 662, jiffies 4294902381 (age 13444.937s) hex dump (first 32 bytes): d0 1b af 69 81 88 ff ff 60 cb b9 c0 ff ff ff ff ...i`... 80 73 48 e1 13 00 00 00 58 7d c1 0b 00 c9 ff ff .sH.X}.. backtrace: [] drm_sched_fence_create+0x1f/0x1d0 [gpu_sched] [] drm_sched_job_init+0x10e/0x240 [gpu_sched] [] amdgpu_job_submit+0x27/0x2d0 [amdgpu] [] amdgpu_copy_buffer+0x49e/0x700 [amdgpu] [] amdgpu_ttm_copy_mem_to_mem+0x5fa/0xf00 [amdgpu] [] amdgpu_bo_move+0x356/0x2180 [amdgpu] [] ttm_bo_handle_move_mem+0x1c7/0x620 [ttm] [] ttm_bo_validate+0x2c7/0x450 [ttm] [] amdgpu_bo_fault_reserve_notify+0x2a4/0x640 [amdgpu] [] amdgpu_gem_fault+0x123/0x2d0 [amdgpu] [] __do_fault+0xf3/0x3e0 [] __handle_mm_fault+0x1bcb/0x2ac0 [] handle_mm_fault+0x12a/0x490 [] do_user_addr_fault+0x259/0xb70 [] exc_page_fault+0x55/0xb0 [] asm_exc_page_fault+0x1b/0x20 unreferenced object 0x888263377700 (size 72): comm "sdma0", pid 345, jiffies 4294902381 (age 13444.937s) hex dump (first 32 bytes): f0 f3 5c 69 81 88 ff ff 80 8a cf c1 ff ff ff ff ..\i f2 a0 4c e1 13 00 00 00 58 28 9b c9 81 88 ff ff ..L.X(.. backtrace: [] amdgpu_fence_emit+0x91/0x790 [amdgpu] [] amdgpu_ib_schedule+0x8cb/0x12f0 [amdgpu] [] amdgpu_job_run+0x35e/0x790 [amdgpu] [] drm_sched_main+0x64e/0xc60 [gpu_sched] [] kthread+0x342/0x410 [] ret_from_fork+0x22/0x30 unreferenced object 0x88811314b9c0 (size 216): comm "mate-session-ch", pid 768, jiffies 4294905408 (age 13434.854s) hex dump (first 32 bytes): 50 ba 14 13 81 88 ff ff 60 cb b9 c0 ff ff ff ff P...`... dc 7a c1 3a 16 00 00 00 58 7d c1 0b 00 c9 ff ff .z.:X}.. backtrace: [] drm_sched_fence_create+0x1f/0x1d0 [gpu_sched] [] drm_sched_job_init+0x10e/0x240 [gpu_sched] [] amdgpu_job_submit+0x27/0x2d0 [amdgpu] [] amdgpu_copy_buffer+0x49e/0x700 [amdgpu] [] amdgpu_ttm_copy_mem_to_mem+0x5fa/0xf00 [amdgpu] [] amdgpu_bo_move+0x356/0x2180 [amdgpu] [] ttm_bo_handle_move_mem+0x1c7/0x620 [ttm] [] ttm_bo_validate+0x2c7/0x450 [ttm] [] amdgpu_bo_fault_reserve_notify+0x2a4/0x640 [amdgpu] [] amdgpu_gem_fault+0x123/0x2d0 [amdgpu] [] __do_fault+0xf3/0x3e0 [] __handle_mm_fault+0x1bcb/0x2ac0 [] handle_mm_fault+0x12a/0x490 [] do_user_addr_fault+0x259/0xb70 [] exc_page_fault+0x55/0xb0 [] asm_exc_page_fault+0x1b/0x20 unreferenced object 0x888167ffc340 (size 72): comm "sdma0", pid 345, jiffies 4294905408 (age 13434.854s) hex dump (first 32 bytes): f0 f3 5c 69 81 88 ff ff 80 8a cf c1 ff ff ff ff ..\i ac b5 c5 3a 16 00 00 00 58 e4 a7 01 81 88 ff ff ...:X... backtrace: [] amdgpu_fence_emit+0x91/0x790 [amdgpu] [] amdgpu_ib_schedule+0x8cb/0x12f0 [amdgpu] [] amdgpu_job_run+0x35e/0x790 [amdgpu] [] drm_sched_main+0x64e/0xc60 [gpu_sched] [] kthread+0x342/0x410 [] ret_from_fork+0x22/0x30 unreferenced object 0x888113b6d240 (size 216): comm "mate-screensave", pid 57770, jiffies 4295052030 (age 12946.214s) hex dump (first 32 bytes): d0 d2 b6 13 81 88 ff ff 60 cb b9 c0 ff ff ff ff `... a2 85 ff 05 88 00 00 00 58 7d c1 0b 00 c9 ff ff X}.. backtrace: [] drm_sched_fence_create+0x1f/0x1d0 [gpu_sched] [] drm_sched_job_init+0x10e/0x240 [gpu_sched] [] amdgpu_job_submit+0x27/0x2d0 [amdgpu] [] amdgpu_copy_buffer+0x49e/0x700 [amdgpu] [] amdgpu_ttm_copy_mem_to_mem+0x5fa/0xf00 [amdgpu] [] amdgpu_bo_move+0x356/0x2180 [amdgpu] [] ttm_bo_handle_move_mem+0x1c7/0x620 [ttm] [] ttm_bo_validate+0x2c7/0x450 [ttm] [] amdgpu_bo_fault_reserve_notify+0x2a4/0x640 [amdgpu] [] amdgpu_gem_fault+0x123/0x2d0 [amdgpu] [] __do_fault+0xf3/0x3e0 [] __handle_mm_fault+0x1bcb/0x2ac0 [] handle_mm_fault+0x12a/0x490 [] do_user_addr_fault+0x259/0xb70 [] exc_page_fault+0x55/0xb0 [] asm_exc_page_fault+0x1b/0x20 unreferenced object 0x8881c85d6e80 (size 72): comm "sdma0", pid 345, jiffies 4295052030 (age 12946.217s) hex dump (first 32 bytes): f0 f3
[Bug 214029] [NAVI] Several memory leaks in amdgpu and ttm
https://bugzilla.kernel.org/show_bug.cgi?id=214029 --- Comment #1 from Erhard F. (erhar...@mailbox.org) --- Created attachment 298267 --> https://bugzilla.kernel.org/attachment.cgi?id=298267&action=edit output of kmemleak (kernel 5.14-rc5, AMD FX-8370) -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 214029] [NAVI] Several memory leaks in amdgpu and ttm
https://bugzilla.kernel.org/show_bug.cgi?id=214029 --- Comment #2 from Erhard F. (erhar...@mailbox.org) --- Created attachment 298269 --> https://bugzilla.kernel.org/attachment.cgi?id=298269&action=edit kernel .config (kernel 5.14-rc5, AMD FX-8370) -- 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 07/11] treewide: Replace the use of mem_encrypt_active() with prot_guest_has()
On 7/27/21 3:26 PM, Tom Lendacky wrote:
diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index de01903c3735..cafed6456d45 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -19,7 +19,7 @@
#include
#include
#include
-#include
+#include
#include
#include
@@ -285,7 +285,7 @@ unsigned long __head __startup_64(unsigned long physaddr,
* there is no need to zero it after changing the memory encryption
* attribute.
*/
- if (mem_encrypt_active()) {
+ if (prot_guest_has(PATTR_MEM_ENCRYPT)) {
vaddr = (unsigned long)__start_bss_decrypted;
vaddr_end = (unsigned long)__end_bss_decrypted;
Since this change is specific to AMD, can you replace PATTR_MEM_ENCRYPT with
prot_guest_has(PATTR_SME) || prot_guest_has(PATTR_SEV). It is not used in
TDX.
--
Sathyanarayanan Kuppuswamy
Linux Kernel Developer
Re: [PATCH v2] drm/msm/dp: add drm debug logs to dp_pm_resume/suspend
On 2021-08-10 11:33, Stephen Boyd wrote:
Quoting Kuogee Hsieh (2021-08-10 08:29:22)
Changes in V2:
-- correct Fixes text
-- drop commit text
Fixes: 601f0479c583 ("drm/msm/dp: add logs across DP driver for ease
of debugging")
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_display.c | 13 +
1 file changed, 13 insertions(+)
BTW, this conflicts with commit
e8a767e04dbc7b201cb17ab99dca723a3488b6d4
in msm-next. The resolution is trivial but just wanted to mention it.
I Just fetched msm-next and cherry-pick this patch over, no conflict
seen.
Is this conflict need to be fixed?
