From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: Christoph Hellwig <hch@lst.de>
Cc: dri-devel@lists.freedesktop.org,
Karol Herbst <kherbst@redhat.com>,
nouveau@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
Ben Skeggs <bskeggs@redhat.com>
Subject: Re: [Intel-gfx] susetting the remaining swioltb couplin in DRM
Date: Mon, 11 Jul 2022 16:31:49 -0400 [thread overview]
Message-ID: <YsyItfiuccW7iQln@intel.com> (raw)
In-Reply-To: <20220711082614.GA29487@lst.de>
On Mon, Jul 11, 2022 at 10:26:14AM +0200, Christoph Hellwig wrote:
> Hi i915 and nouveau maintainers,
>
> any chance I could get some help to remove the remaining direct
> driver calls into swiotlb, namely swiotlb_max_segment and
> is_swiotlb_active. Either should not matter to a driver as they
> should be written to the DMA API.
Hi Christoph,
while we take a look here, could you please share the reasons
behind sunsetting this calls?
>
> In the i915 case it seems like the driver should use
> dma_alloc_noncontiguous and/or dma_alloc_noncoherent to allocate
> DMAable memory instead of using alloc_page and the streaming
> dma mapping helpers.
>
> For the latter it seems like it should just stop passing
> use_dma_alloc == true to ttm_device_init and/or that function
> should switch to use dma_alloc_noncoherent.
WARNING: multiple messages have this Message-ID (diff)
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
dri-devel@lists.freedesktop.org, nouveau@lists.freedesktop.org,
intel-gfx@lists.freedesktop.org,
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
Jani Nikula <jani.nikula@linux.intel.com>,
Ben Skeggs <bskeggs@redhat.com>
Subject: Re: [Nouveau] susetting the remaining swioltb couplin in DRM
Date: Mon, 11 Jul 2022 16:31:49 -0400 [thread overview]
Message-ID: <YsyItfiuccW7iQln@intel.com> (raw)
In-Reply-To: <20220711082614.GA29487@lst.de>
On Mon, Jul 11, 2022 at 10:26:14AM +0200, Christoph Hellwig wrote:
> Hi i915 and nouveau maintainers,
>
> any chance I could get some help to remove the remaining direct
> driver calls into swiotlb, namely swiotlb_max_segment and
> is_swiotlb_active. Either should not matter to a driver as they
> should be written to the DMA API.
Hi Christoph,
while we take a look here, could you please share the reasons
behind sunsetting this calls?
>
> In the i915 case it seems like the driver should use
> dma_alloc_noncontiguous and/or dma_alloc_noncoherent to allocate
> DMAable memory instead of using alloc_page and the streaming
> dma mapping helpers.
>
> For the latter it seems like it should just stop passing
> use_dma_alloc == true to ttm_device_init and/or that function
> should switch to use dma_alloc_noncoherent.
WARNING: multiple messages have this Message-ID (diff)
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
dri-devel@lists.freedesktop.org,
Karol Herbst <kherbst@redhat.com>,
nouveau@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
Ben Skeggs <bskeggs@redhat.com>
Subject: Re: susetting the remaining swioltb couplin in DRM
Date: Mon, 11 Jul 2022 16:31:49 -0400 [thread overview]
Message-ID: <YsyItfiuccW7iQln@intel.com> (raw)
In-Reply-To: <20220711082614.GA29487@lst.de>
On Mon, Jul 11, 2022 at 10:26:14AM +0200, Christoph Hellwig wrote:
> Hi i915 and nouveau maintainers,
>
> any chance I could get some help to remove the remaining direct
> driver calls into swiotlb, namely swiotlb_max_segment and
> is_swiotlb_active. Either should not matter to a driver as they
> should be written to the DMA API.
Hi Christoph,
while we take a look here, could you please share the reasons
behind sunsetting this calls?
>
> In the i915 case it seems like the driver should use
> dma_alloc_noncontiguous and/or dma_alloc_noncoherent to allocate
> DMAable memory instead of using alloc_page and the streaming
> dma mapping helpers.
>
> For the latter it seems like it should just stop passing
> use_dma_alloc == true to ttm_device_init and/or that function
> should switch to use dma_alloc_noncoherent.
next prev parent reply other threads:[~2022-07-11 20:32 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-11 8:26 [Intel-gfx] susetting the remaining swioltb couplin in DRM Christoph Hellwig
2022-07-11 8:26 ` [Nouveau] " Christoph Hellwig
2022-07-11 20:31 ` Rodrigo Vivi [this message]
2022-07-11 20:31 ` Rodrigo Vivi
2022-07-11 20:31 ` [Nouveau] " Rodrigo Vivi
2022-07-12 5:00 ` [Intel-gfx] " Christoph Hellwig
2022-07-12 5:00 ` [Nouveau] " Christoph Hellwig
2022-07-18 11:36 ` [Intel-gfx] " Tvrtko Ursulin
2022-07-18 11:36 ` Tvrtko Ursulin
2022-07-18 11:36 ` [Nouveau] " Tvrtko Ursulin
2022-07-21 14:28 ` [Intel-gfx] " Robert Beckett
2022-07-21 14:28 ` Robert Beckett
2022-07-28 21:17 ` [Intel-gfx] " Lyude Paul
2022-07-28 21:17 ` Lyude Paul
2022-07-28 21:17 ` [Nouveau] " Lyude Paul
2022-07-28 21:55 ` [Intel-gfx] " Lyude Paul
2022-07-28 21:55 ` Lyude Paul
2022-07-28 21:55 ` [Nouveau] " Lyude Paul
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=YsyItfiuccW7iQln@intel.com \
--to=rodrigo.vivi@intel.com \
--cc=bskeggs@redhat.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=hch@lst.de \
--cc=intel-gfx@lists.freedesktop.org \
--cc=kherbst@redhat.com \
--cc=nouveau@lists.freedesktop.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.