Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1682176

Re: [RFC PATCH 1/5] base: dma-mapping: Export commonly used symbols

Show all headers | View raw

On Thu, Jul 6, 2017 at 3:44 AM, Tomasz Figa <tfiga@chromium.org> wrote:
> On Thu, Jul 6, 2017 at 2:20 AM, Christoph Hellwig <hch@lst.de> wrote:
>> On Thu, Jul 06, 2017 at 12:22:35AM +0900, Tomasz Figa wrote:

>> In general I think moving dma
>> ops and iommu implementations into modules is a bad idea
>
> Could you elaborate on this? I'd be interested in seeing the reasoning
> behind this.
>
>> but I
>> don't want to reject the idea before seeing the code.  Or maybe
>> by looking at the user we can come up with an even better idea
>> to solve the original issue you're trying to solve, so please also
>> explain your rationale.

I had pretty much the same thoughts here.

> Basically we have an x86 platform with a camera subsystem that is a
> PCI device, has its own MMU and needs cache maintenance. Moreover, the
> V4L2 subsystem, which is the right place for camera drivers, heavily
> relies on DMA mapping as a way to abstract memory allocation, mapping
> and cache maintenance. So it feels natural to me to hide the hardware
> details (additional cache maintenance, mapping into the built-in
> IOMMU) in the DMA mapping ops for this camera subsystem and simply
> make V4L2 just work without knowing those details.

I can understand your reasoning here, but I'm also not convinced
that this is the best approach. There may be a middle ground somewhere
though.

Generally speaking I don't want to have to deal with the horrors of
deciding whether an IOMMU is going to be there eventually or not
at probe() time. At some point, we had decided that IOMMUs need to
be initialized (almost) as early as irqchips and clocksources so we can
rely on them to be there at device discovery time. That got pushed
back already, and now we may have to deal with -EPROBE_DEFER
when an IOMMU has not been fully initialized at device probe time,
but at least we can reliably see if one is there or not. Making IOMMUs
modular will add further uncertainty here. Obviously we cannot attach
an IOMMU to a device once we have started using DMA mapping
calls on it.

For your particular use case, I would instead leave the knowledge
about the IOMMU in the driver itself, like we do for the IOMMUs
that are integrated in desktop GPUs, and have the code use the
DMA mapping API with the system-provided dma_map_ops to
get dma_addr_t tokens which you then program into the device
IOMMU.

An open question however would be whether to use the IOMMU
API without the DMA mapping API here, or whether to completely
leave the knowledge of the IOMMU inside of the driver itself.
I don't have a strong opinion on that part, and I guess this mostly
depends on what the hardware looks like.

       Arnd

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

[RFC PATCH 0/5] Fixes for loadable modules implementing DMA/IOMMU APIs Tomasz Figa <tfiga@chromium.org> - 2017-07-05 09:20 +0200
  [RFC PATCH 5/5] iommu/dma: Add iommu_dma_cleanup() Tomasz Figa <tfiga@chromium.org> - 2017-07-05 09:20 +0200
  [RFC PATCH 2/5] base: dma-mapping: Provide a function to look up remapped pages Tomasz Figa <tfiga@chromium.org> - 2017-07-05 09:20 +0200
  [RFC PATCH 3/5] iommu: Export non-static functions to use in modules Tomasz Figa <tfiga@chromium.org> - 2017-07-05 09:20 +0200
  [RFC PATCH 1/5] base: dma-mapping: Export commonly used symbols Tomasz Figa <tfiga@chromium.org> - 2017-07-05 09:20 +0200
    Re: [RFC PATCH 1/5] base: dma-mapping: Export commonly used symbols Christoph Hellwig <hch@lst.de> - 2017-07-05 17:20 +0200
      Re: [RFC PATCH 1/5] base: dma-mapping: Export commonly used symbols Tomasz Figa <tfiga@chromium.org> - 2017-07-05 17:30 +0200
        Re: [RFC PATCH 1/5] base: dma-mapping: Export commonly used symbols Christoph Hellwig <hch@lst.de> - 2017-07-05 19:30 +0200
          Re: [RFC PATCH 1/5] base: dma-mapping: Export commonly used symbols Tomasz Figa <tfiga@chromium.org> - 2017-07-06 03:50 +0200
            Re: [RFC PATCH 1/5] base: dma-mapping: Export commonly used symbols Arnd Bergmann <arnd@arndb.de> - 2017-07-06 10:30 +0200
              Re: [RFC PATCH 1/5] base: dma-mapping: Export commonly used symbols Tomasz Figa <tfiga@chromium.org> - 2017-07-06 10:40 +0200
                Re: [RFC PATCH 1/5] base: dma-mapping: Export commonly used symbols Tomasz Figa <tfiga@chromium.org> - 2017-07-06 10:50 +0200
                Re: [RFC PATCH 1/5] base: dma-mapping: Export commonly used symbols Arnd Bergmann <arnd@arndb.de> - 2017-07-06 14:30 +0200
                Re: [RFC PATCH 1/5] base: dma-mapping: Export commonly used symbols Tomasz Figa <tfiga@chromium.org> - 2017-07-06 15:40 +0200
                Re: [RFC PATCH 1/5] base: dma-mapping: Export commonly used symbols Tomasz Figa <tfiga@chromium.org> - 2017-07-06 15:50 +0200
                Re: [RFC PATCH 1/5] base: dma-mapping: Export commonly used symbols Tomasz Figa <tfiga@chromium.org> - 2017-07-06 16:10 +0200
                Re: [RFC PATCH 1/5] base: dma-mapping: Export commonly used symbols Arnd Bergmann <arnd@arndb.de> - 2017-07-06 16:30 +0200
                Re: [RFC PATCH 1/5] base: dma-mapping: Export commonly used symbols Tomasz Figa <tfiga@chromium.org> - 2017-07-06 16:40 +0200
                Re: [RFC PATCH 1/5] base: dma-mapping: Export commonly used symbols Arnd Bergmann <arnd@arndb.de> - 2017-07-06 16:10 +0200
                Re: [RFC PATCH 1/5] base: dma-mapping: Export commonly used symbols Arnd Bergmann <arnd@arndb.de> - 2017-07-06 16:00 +0200
  [RFC PATCH 4/5] iommu/dma: Export non-static functions to use in modules Tomasz Figa <tfiga@chromium.org> - 2017-07-05 09:20 +0200
    Re: [RFC PATCH 4/5] iommu/dma: Export non-static functions to use in  modules Robin Murphy <robin.murphy@arm.com> - 2017-07-05 18:30 +0200
      Re: [RFC PATCH 4/5] iommu/dma: Export non-static functions to use in modules Tomasz Figa <tfiga@chromium.org> - 2017-07-06 04:30 +0200
        Re: [RFC PATCH 4/5] iommu/dma: Export non-static functions to use in  modules Robin Murphy <robin.murphy@arm.com> - 2017-07-06 13:20 +0200
          Re: [RFC PATCH 4/5] iommu/dma: Export non-static functions to use         in modules Christoph Hellwig <hch@lst.de> - 2017-07-06 16:20 +0200
            Re: [RFC PATCH 4/5] iommu/dma: Export non-static functions to use in modules Tomasz Figa <tfiga@chromium.org> - 2017-07-06 16:20 +0200
              Re: [RFC PATCH 4/5] iommu/dma: Export non-static functions to use in modules Tomasz Figa <tfiga@chromium.org> - 2017-07-06 16:30 +0200
                Re: [RFC PATCH 4/5] iommu/dma: Export non-static functions to use in modules Arnd Bergmann <arnd@arndb.de> - 2017-07-06 16:40 +0200
                Re: [RFC PATCH 4/5] iommu/dma: Export non-static functions to use in modules Tomasz Figa <tfiga@chromium.org> - 2017-07-06 16:50 +0200

csiph-web