linux-tegra.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Jon Hunter <jonathanh@nvidia.com>
Cc: David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>,
	dri-devel@lists.freedesktop.org, linux-tegra@vger.kernel.org,
	Mikko Perttunen <mperttunen@nvidia.com>,
	Thierry Reding <thierry.reding@gmail.com>,
	Diogo Ivo <diogo.ivo@tecnico.ulisboa.pt>,
	patches@lists.linux.dev
Subject: Re: [PATCH] drm/tegra: Remove of_dma_configure() from host1x_device_add()
Date: Wed, 31 Jan 2024 11:33:12 -0400	[thread overview]
Message-ID: <20240131153312.GM1455070@nvidia.com> (raw)
In-Reply-To: <583b9145-cbbe-4a03-8120-e2a66a6093c7@nvidia.com>

On Tue, Jan 30, 2024 at 09:55:18PM +0000, Jon Hunter wrote:
> 
> On 30/01/2024 16:15, Jason Gunthorpe wrote:
> > This was added in commit c95469aa5a18 ("gpu: host1x: Set DMA ops on device
> > creation") with the note:
> > 
> >      Currently host1x-instanciated devices have their dma_ops left to NULL,
> >      which makes any DMA operation (like buffer import) on ARM64 fallback
> >      to the dummy_dma_ops and fail with an error.
> > 
> > Since commit 14891af3799e ("iommu: Move the iommu driver sysfs setup into
> > iommu_init/deinit_device()") this call now fails because the struct device
> > is not fully configured enough to setup the sysfs and we now catch that
> > error.
> > 
> > This failure means the DMA ops are no longer set during this failing call.

Looking at it more it seems the arch dma ops are setup still, we
ignore the failure on multiple levels :(

> > It seems this is no longer a problem because
> > commit 07397df29e57 ("dma-mapping: move dma configuration to bus
> > infrastructure") added another call to of_dma_configure() inside the
> > bus_type->dma_configure() callback.
> > 
> > So long as a driver is probed the to the device it will have DMA properly
> > setup in the ordinary way.
> > 
> > Remove the unnecessary call which also removes the new long print:
> > 
> > [    1.200004] host1x drm: iommu configuration for device failed with -ENOENT
> > 
> > Reported-by: Diogo Ivo <diogo.ivo@tecnico.ulisboa.pt>
> > Closes: https://lore.kernel.org/all/bbmhcoghrprmbdibnjum6lefix2eoquxrde7wyqeulm4xabmlm@b6jy32saugqh/
> > Reported-by: Jon Hunter <jonathanh@nvidia.com>
> > Closes: https://lore.kernel.org/all/b0334c5e-3a6c-4b58-b525-e72bed8899b3@nvidia.com/
> > Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
> > ---
> >   drivers/gpu/host1x/bus.c | 2 --
> >   1 file changed, 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/host1x/bus.c b/drivers/gpu/host1x/bus.c
> > index 84d042796d2e66..61214d35cadc34 100644
> > --- a/drivers/gpu/host1x/bus.c
> > +++ b/drivers/gpu/host1x/bus.c
> > @@ -458,8 +458,6 @@ static int host1x_device_add(struct host1x *host1x,
> >   	device->dev.bus = &host1x_bus_type;
> >   	device->dev.parent = host1x->dev;
> > -	of_dma_configure(&device->dev, host1x->dev->of_node, true);
> > -
> >   	device->dev.dma_parms = &device->dma_parms;
> >   	dma_set_max_seg_size(&device->dev, UINT_MAX);
> 
> 
> In my case the warning is coming from the of_dma_configure_id() in
> drivers/gpu/host1x/context.c. So with the above change I am still seeing the
> warning.

You mean this sequence?

		err = device_add(&ctx->dev);
		if (err) {
			dev_err(host1x->dev, "could not add context device %d: %d\n", i, err);
			put_device(&ctx->dev);
			goto unreg_devices;
		}

		err = of_dma_configure_id(&ctx->dev, node, true, &i);
		if (err) {
			dev_err(host1x->dev, "IOMMU configuration failed for context device %d: %d\n",
				i, err);
			device_unregister(&ctx->dev);
			goto unreg_devices;
		}

I didn't seem an obvious place that this would get fixed up later?

device_add() was done before so the iommu_device_link() shouldn't be
failing? Are you hitting a duplicate link (ie remove the nowarn from
iommu_device_link())

Jason

  reply	other threads:[~2024-01-31 15:33 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-30 16:15 [PATCH] drm/tegra: Remove of_dma_configure() from host1x_device_add() Jason Gunthorpe
2024-01-30 21:55 ` Jon Hunter
2024-01-31 15:33   ` Jason Gunthorpe [this message]
2024-02-01 19:35     ` Jon Hunter
2024-02-01 20:02       ` Jason Gunthorpe
2024-02-02 10:40         ` Jon Hunter
2024-02-02 14:35           ` Jason Gunthorpe
2024-02-02 15:56             ` Jon Hunter
2024-02-02 16:15               ` Jason Gunthorpe
2024-02-07 13:05                 ` Jason Gunthorpe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240131153312.GM1455070@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=airlied@gmail.com \
    --cc=daniel@ffwll.ch \
    --cc=diogo.ivo@tecnico.ulisboa.pt \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jonathanh@nvidia.com \
    --cc=linux-tegra@vger.kernel.org \
    --cc=mperttunen@nvidia.com \
    --cc=patches@lists.linux.dev \
    --cc=thierry.reding@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).