From: Takashi Iwai <tiwai@suse.de>
To: Christoph Hellwig <hch@lst.de>
Cc: linux-xtensa@linux-xtensa.org, Michal Simek <monstr@monstr.eu>,
linux-parisc@vger.kernel.org, linux-sh@vger.kernel.org,
linux-m68k@lists.linux-m68k.org,
Robin Murphy <robin.murphy@arm.com>,
x86@kernel.org, linux-kernel@vger.kernel.org,
iommu@lists.linux-foundation.org, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 5/5] dma-mapping: remove ARCH_NO_COHERENT_DMA_MMAP
Date: Sat, 03 Aug 2019 13:22:09 +0200 [thread overview]
Message-ID: <s5himreqyse.wl-tiwai@suse.de> (raw)
In-Reply-To: <20190803103024.GA32624@lst.de>
On Sat, 03 Aug 2019 12:30:24 +0200,
Christoph Hellwig wrote:
>
> On Fri, Aug 02, 2019 at 10:24:02AM +0200, Takashi Iwai wrote:
> > I wasn't careful enough to look at that change, sorry.
> >
> > The code there tries to check whether dma_mmap_coherent() would always
> > fail on some platforms. Then the driver clears the mmap capability
> > flag at the device open time and notifies user-space to fall back to
> > the dumb read/write mode.
> >
> > So I'm afraid that simply dropping the check would cause the behavior
> > regression, e.g. on PARISC.
> >
> > Is there any simple way to test whether dma_mmap_coherent() would work
> > or not in general on the target platform? It's not necessarily in an
> > ifdef at all.
>
> This isn't really a platform, but a per-device question. I can add a
> "bool dma_can_mmap(struct device *dev)" helper to check that.
Yes, this would fit perfect.
> But how
> do I get at a suitable struct device in hw_support_mmap()?
substream->dma_buffer.dev.dev can be that, which is used in the mmap
helper side, snd_pcm_lib_default_mmap().
Thanks!
Takashi
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
WARNING: multiple messages have this Message-ID (diff)
From: Takashi Iwai <tiwai@suse.de>
To: Christoph Hellwig <hch@lst.de>
Cc: iommu@lists.linux-foundation.org,
Marek Szyprowski <m.szyprowski@samsung.com>,
linux-xtensa@linux-xtensa.org, Michal Simek <monstr@monstr.eu>,
linux-parisc@vger.kernel.org, linux-sh@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, x86@kernel.org,
linux-kernel@vger.kernel.org, linux-m68k@lists.linux-m68k.org,
Robin Murphy <robin.murphy@arm.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 5/5] dma-mapping: remove ARCH_NO_COHERENT_DMA_MMAP
Date: Sat, 03 Aug 2019 13:22:09 +0200 [thread overview]
Message-ID: <s5himreqyse.wl-tiwai@suse.de> (raw)
In-Reply-To: <20190803103024.GA32624@lst.de>
On Sat, 03 Aug 2019 12:30:24 +0200,
Christoph Hellwig wrote:
>
> On Fri, Aug 02, 2019 at 10:24:02AM +0200, Takashi Iwai wrote:
> > I wasn't careful enough to look at that change, sorry.
> >
> > The code there tries to check whether dma_mmap_coherent() would always
> > fail on some platforms. Then the driver clears the mmap capability
> > flag at the device open time and notifies user-space to fall back to
> > the dumb read/write mode.
> >
> > So I'm afraid that simply dropping the check would cause the behavior
> > regression, e.g. on PARISC.
> >
> > Is there any simple way to test whether dma_mmap_coherent() would work
> > or not in general on the target platform? It's not necessarily in an
> > ifdef at all.
>
> This isn't really a platform, but a per-device question. I can add a
> "bool dma_can_mmap(struct device *dev)" helper to check that.
Yes, this would fit perfect.
> But how
> do I get at a suitable struct device in hw_support_mmap()?
substream->dma_buffer.dev.dev can be that, which is used in the mmap
helper side, snd_pcm_lib_default_mmap().
Thanks!
Takashi
WARNING: multiple messages have this Message-ID (diff)
From: Takashi Iwai <tiwai@suse.de>
To: Christoph Hellwig <hch@lst.de>
Cc: linux-xtensa@linux-xtensa.org, Michal Simek <monstr@monstr.eu>,
linux-parisc@vger.kernel.org, linux-sh@vger.kernel.org,
linux-m68k@lists.linux-m68k.org,
Robin Murphy <robin.murphy@arm.com>,
x86@kernel.org, linux-kernel@vger.kernel.org,
iommu@lists.linux-foundation.org, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org,
Marek Szyprowski <m.szyprowski@samsung.com>
Subject: Re: [PATCH 5/5] dma-mapping: remove ARCH_NO_COHERENT_DMA_MMAP
Date: Sat, 03 Aug 2019 11:22:09 +0000 [thread overview]
Message-ID: <s5himreqyse.wl-tiwai@suse.de> (raw)
In-Reply-To: <20190803103024.GA32624@lst.de>
On Sat, 03 Aug 2019 12:30:24 +0200,
Christoph Hellwig wrote:
>
> On Fri, Aug 02, 2019 at 10:24:02AM +0200, Takashi Iwai wrote:
> > I wasn't careful enough to look at that change, sorry.
> >
> > The code there tries to check whether dma_mmap_coherent() would always
> > fail on some platforms. Then the driver clears the mmap capability
> > flag at the device open time and notifies user-space to fall back to
> > the dumb read/write mode.
> >
> > So I'm afraid that simply dropping the check would cause the behavior
> > regression, e.g. on PARISC.
> >
> > Is there any simple way to test whether dma_mmap_coherent() would work
> > or not in general on the target platform? It's not necessarily in an
> > ifdef at all.
>
> This isn't really a platform, but a per-device question. I can add a
> "bool dma_can_mmap(struct device *dev)" helper to check that.
Yes, this would fit perfect.
> But how
> do I get at a suitable struct device in hw_support_mmap()?
substream->dma_buffer.dev.dev can be that, which is used in the mmap
helper side, snd_pcm_lib_default_mmap().
Thanks!
Takashi
WARNING: multiple messages have this Message-ID (diff)
From: Takashi Iwai <tiwai@suse.de>
To: Christoph Hellwig <hch@lst.de>
Cc: linux-xtensa@linux-xtensa.org, Michal Simek <monstr@monstr.eu>,
linux-parisc@vger.kernel.org, linux-sh@vger.kernel.org,
linux-m68k@lists.linux-m68k.org,
Robin Murphy <robin.murphy@arm.com>,
x86@kernel.org, linux-kernel@vger.kernel.org,
iommu@lists.linux-foundation.org, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org,
Marek Szyprowski <m.szyprowski@samsung.com>
Subject: Re: [PATCH 5/5] dma-mapping: remove ARCH_NO_COHERENT_DMA_MMAP
Date: Sat, 03 Aug 2019 13:22:09 +0200 [thread overview]
Message-ID: <s5himreqyse.wl-tiwai@suse.de> (raw)
In-Reply-To: <20190803103024.GA32624@lst.de>
On Sat, 03 Aug 2019 12:30:24 +0200,
Christoph Hellwig wrote:
>
> On Fri, Aug 02, 2019 at 10:24:02AM +0200, Takashi Iwai wrote:
> > I wasn't careful enough to look at that change, sorry.
> >
> > The code there tries to check whether dma_mmap_coherent() would always
> > fail on some platforms. Then the driver clears the mmap capability
> > flag at the device open time and notifies user-space to fall back to
> > the dumb read/write mode.
> >
> > So I'm afraid that simply dropping the check would cause the behavior
> > regression, e.g. on PARISC.
> >
> > Is there any simple way to test whether dma_mmap_coherent() would work
> > or not in general on the target platform? It's not necessarily in an
> > ifdef at all.
>
> This isn't really a platform, but a per-device question. I can add a
> "bool dma_can_mmap(struct device *dev)" helper to check that.
Yes, this would fit perfect.
> But how
> do I get at a suitable struct device in hw_support_mmap()?
substream->dma_buffer.dev.dev can be that, which is used in the mmap
helper side, snd_pcm_lib_default_mmap().
Thanks!
Takashi
WARNING: multiple messages have this Message-ID (diff)
From: Takashi Iwai <tiwai@suse.de>
To: Christoph Hellwig <hch@lst.de>
Cc: linux-xtensa@linux-xtensa.org, Michal Simek <monstr@monstr.eu>,
linux-parisc@vger.kernel.org, linux-sh@vger.kernel.org,
linux-m68k@lists.linux-m68k.org,
Robin Murphy <robin.murphy@arm.com>,
x86@kernel.org, linux-kernel@vger.kernel.org,
iommu@lists.linux-foundation.org, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org,
Marek Szyprowski <m.szyprowski@samsung.com>
Subject: Re: [PATCH 5/5] dma-mapping: remove ARCH_NO_COHERENT_DMA_MMAP
Date: Sat, 03 Aug 2019 13:22:09 +0200 [thread overview]
Message-ID: <s5himreqyse.wl-tiwai@suse.de> (raw)
In-Reply-To: <20190803103024.GA32624@lst.de>
On Sat, 03 Aug 2019 12:30:24 +0200,
Christoph Hellwig wrote:
>
> On Fri, Aug 02, 2019 at 10:24:02AM +0200, Takashi Iwai wrote:
> > I wasn't careful enough to look at that change, sorry.
> >
> > The code there tries to check whether dma_mmap_coherent() would always
> > fail on some platforms. Then the driver clears the mmap capability
> > flag at the device open time and notifies user-space to fall back to
> > the dumb read/write mode.
> >
> > So I'm afraid that simply dropping the check would cause the behavior
> > regression, e.g. on PARISC.
> >
> > Is there any simple way to test whether dma_mmap_coherent() would work
> > or not in general on the target platform? It's not necessarily in an
> > ifdef at all.
>
> This isn't really a platform, but a per-device question. I can add a
> "bool dma_can_mmap(struct device *dev)" helper to check that.
Yes, this would fit perfect.
> But how
> do I get at a suitable struct device in hw_support_mmap()?
substream->dma_buffer.dev.dev can be that, which is used in the mmap
helper side, snd_pcm_lib_default_mmap().
Thanks!
Takashi
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-08-03 11:24 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-25 6:33 remove default fallbacks in dma_map_ops Christoph Hellwig
2019-07-25 6:33 ` Christoph Hellwig
2019-07-25 6:33 ` Christoph Hellwig
2019-07-25 6:33 ` Christoph Hellwig
2019-07-25 6:33 ` Christoph Hellwig
2019-07-25 6:33 ` [PATCH 1/5] m68knommu: add a pgprot_noncached stub Christoph Hellwig
2019-07-25 6:33 ` Christoph Hellwig
2019-07-25 6:33 ` Christoph Hellwig
2019-07-25 6:33 ` Christoph Hellwig
2019-07-25 6:33 ` Christoph Hellwig
2019-07-25 6:33 ` [PATCH 2/5] dma-mapping: move the dma_get_sgtable API comments from arm to common code Christoph Hellwig
2019-07-25 6:33 ` Christoph Hellwig
2019-07-25 6:33 ` Christoph Hellwig
2019-07-25 6:33 ` Christoph Hellwig
2019-07-25 6:33 ` Christoph Hellwig
2019-07-25 6:33 ` [PATCH 3/5] dma-mapping: explicitly wire up ->mmap and ->get_sgtable Christoph Hellwig
2019-07-25 6:33 ` Christoph Hellwig
2019-07-25 6:33 ` Christoph Hellwig
2019-07-25 6:33 ` Christoph Hellwig
2019-07-25 6:33 ` Christoph Hellwig
2019-07-25 6:34 ` [PATCH 4/5] dma-mapping: provide a better default ->get_required_mask Christoph Hellwig
2019-07-25 6:34 ` Christoph Hellwig
2019-07-25 6:34 ` Christoph Hellwig
2019-07-25 6:34 ` Christoph Hellwig
2019-07-25 6:34 ` Christoph Hellwig
2019-07-29 9:57 ` Geert Uytterhoeven
2019-07-29 9:57 ` Geert Uytterhoeven
2019-07-29 9:57 ` Geert Uytterhoeven
2019-07-29 9:57 ` Geert Uytterhoeven
2019-07-29 9:57 ` Geert Uytterhoeven
2019-07-30 6:26 ` Christoph Hellwig
2019-07-30 6:26 ` Christoph Hellwig
2019-07-30 6:26 ` Christoph Hellwig
2019-07-30 6:26 ` Christoph Hellwig
2019-07-30 6:26 ` Christoph Hellwig
2019-07-25 6:34 ` [PATCH 5/5] dma-mapping: remove ARCH_NO_COHERENT_DMA_MMAP Christoph Hellwig
2019-07-25 6:34 ` Christoph Hellwig
2019-07-25 6:34 ` Christoph Hellwig
2019-07-25 6:34 ` Christoph Hellwig
2019-07-25 6:34 ` Christoph Hellwig
2019-08-02 7:03 ` Christoph Hellwig
2019-08-02 7:03 ` Christoph Hellwig
2019-08-02 7:03 ` Christoph Hellwig
2019-08-02 7:03 ` Christoph Hellwig
2019-08-02 7:03 ` Christoph Hellwig
2019-08-02 8:24 ` Takashi Iwai
2019-08-02 8:24 ` Takashi Iwai
2019-08-02 8:24 ` Takashi Iwai
2019-08-02 8:24 ` Takashi Iwai
2019-08-02 8:24 ` Takashi Iwai
2019-08-03 10:30 ` Christoph Hellwig
2019-08-03 10:30 ` Christoph Hellwig
2019-08-03 10:30 ` Christoph Hellwig
2019-08-03 10:30 ` Christoph Hellwig
2019-08-03 10:30 ` Christoph Hellwig
2019-08-03 11:22 ` Takashi Iwai [this message]
2019-08-03 11:22 ` Takashi Iwai
2019-08-03 11:22 ` Takashi Iwai
2019-08-03 11:22 ` Takashi Iwai
2019-08-03 11:22 ` Takashi Iwai
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=s5himreqyse.wl-tiwai@suse.de \
--to=tiwai@suse.de \
--cc=hch@lst.de \
--cc=iommu@lists.linux-foundation.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-m68k@lists.linux-m68k.org \
--cc=linux-parisc@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=linux-xtensa@linux-xtensa.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=monstr@monstr.eu \
--cc=robin.murphy@arm.com \
--cc=x86@kernel.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.