[PATCH] drm/msm: log iommu init failure

[Rob Clark]

On Thu, May 30, 2024 at 2:48 AM Marc Gonzalez <mgonzalez at freebox.fr> wrote:
>
> On 16/05/2024 10:43, Marijn Suijten wrote:
>
> > On 2024-05-15 17:09:02, Marc Gonzalez wrote:
> >
> >> When create_address_space() fails (e.g. when smmu node is disabled)

Note that smmu support is going to become a hard dependency with the
drm_gpuvm/VM_BIND conversion.. which I think means we should never get
far enough to hit this error path..

BR,
-R

> >> msm_gpu_init() silently fails:
> >>
> >> msm_dpu c901000.display-controller: failed to load adreno gpu
> >> msm_dpu c901000.display-controller: failed to bind 5000000.gpu (ops a3xx_ops): -19
> >>
> >> Log create_address_space() failure.
> >>
> >> Signed-off-by: Marc Gonzalez <mgonzalez at freebox.fr>
> >
> > Thanks!
> >
> > Suggested-by: Marijn Suijten <marijn.suijten at somainline.org>
> >
> > And, after checking the below:
> >
> > Reviewed-by: Marijn Suijten <marijn.suijten at somainline.org>
> >
> >> ---
> >>  drivers/gpu/drm/msm/msm_gpu.c | 1 +
> >>  1 file changed, 1 insertion(+)
> >>
> >> diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
> >> index 655002b21b0d5..f1e692866cc38 100644
> >> --- a/drivers/gpu/drm/msm/msm_gpu.c
> >> +++ b/drivers/gpu/drm/msm/msm_gpu.c
> >> @@ -941,6 +941,7 @@ int msm_gpu_init(struct drm_device *drm, struct platform_device *pdev,
> >>              DRM_DEV_INFO(drm->dev, "%s: no IOMMU, fallback to VRAM carveout!\n", name);
> >>      else if (IS_ERR(gpu->aspace)) {
> >>              ret = PTR_ERR(gpu->aspace);
> >> +            DRM_DEV_ERROR(drm->dev, "could not create address space: %d\n", ret);
> >
> > Maybe this wasn't done before because this also includes `-EPROBE_DEFER`, so you
> > might want to wrap this in
> >
> >       if (ret != -EPROBE_DEFER)
> >               DRM_DEV_ERROR...
> >
> > But then dev_err_probe() was built specifically to be less verbose about this
> > (and track defer reasons).  While this is an init and not probe function, it's
> > called from struct component_ops->bind where it should be okay to call that,
> > as long as you have access to the component `struct device*` and not its master
> > (IIRC).
>
>
> Hello Marijn,
>
> I have moved on to HDMI.
>
> Feel free to take full ownership of this submission,
> as I won't have the energy to get it accepted.
>
> Regards,
>
> Marc
>