selects COMMON_CLK_MT2701_IMGSYS which has unmet direct
dependencies (COMMON_CLK && COMMON_CLK_MT2701)
warning: (MTK_IOMMU_V1) selects COMMON_CLK_MT2701_MMSYS which has unmet direct
dependencies (COMMON_CLK && COMMON_CLK_MT2701)
This removes the select statements.
Signed-off-by: Arnd Berg
erent'; did you mean 'debug_dma_free_coherent'?
[-Werror=implicit-function-declaration]
This adds an explicit #include to make it build again.
Signed-off-by: Arnd Bergmann
---
drivers/iommu/mtk_iommu_v1.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/iommu/mtk_iommu_v1.c b/d
On Tue, May 16, 2017 at 7:22 AM, Oza Pawandeep wrote:
> current device framework and OF framework integration assumes
> dma-ranges in a way where memory-mapped devices define their
> dma-ranges. (child-bus-address, parent-bus-address, length).
>
> of_dma_configure is specifically written to take c
On Sat, Jun 24, 2017 at 9:35 AM, Christoph Hellwig wrote:
> I always assumed that our streaming mappings are relaxed order for
> TLP anyway. And at very least Documentation/DMA-attributes.txt seems
> to imply something different:
>
>
> DMA_ATTR_WEAK_ORDERING
> --
>
> DMA
On Thu, Jul 6, 2017 at 3:44 AM, Tomasz Figa wrote:
> On Thu, Jul 6, 2017 at 2:20 AM, Christoph Hellwig 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 th
On Thu, Jul 6, 2017 at 10:36 AM, Tomasz Figa wrote:
> On Thu, Jul 6, 2017 at 5:34 PM, Tomasz Figa wrote:
>> On Thu, Jul 6, 2017 at 5:26 PM, Arnd Bergmann wrote:
>>> On Thu, Jul 6, 2017 at 3:44 AM, Tomasz Figa wrote:
>>
>> I'd say that this is something tha
On Thu, Jul 6, 2017 at 3:31 PM, Tomasz Figa wrote:
> On Thu, Jul 6, 2017 at 9:23 PM, Arnd Bergmann wrote:
>> On Thu, Jul 6, 2017 at 10:36 AM, Tomasz Figa wrote:
>>> On Thu, Jul 6, 2017 at 5:34 PM, Tomasz Figa wrote:
>>>
>>> Sorry, I intended to mean:
&
On Thu, Jul 6, 2017 at 3:49 PM, Tomasz Figa wrote:
> On Thu, Jul 6, 2017 at 10:31 PM, Tomasz Figa wrote:
>> On the other hand, if it's strictly about base/dma-mapping, we might
>> not need it indeed. The driver could call iommu-dma helpers directly,
>> without the need to provide its own DMA ops
On Thu, Jul 6, 2017 at 4:06 PM, Tomasz Figa wrote:
> On Thu, Jul 6, 2017 at 11:02 PM, Arnd Bergmann wrote:
>> On Thu, Jul 6, 2017 at 3:49 PM, Tomasz Figa wrote:
>>> On Thu, Jul 6, 2017 at 10:31 PM, Tomasz Figa wrote:
>>
>>>> On the other hand, if it's
On Thu, Jul 6, 2017 at 4:24 PM, Tomasz Figa wrote:
> On Thu, Jul 6, 2017 at 11:17 PM, Tomasz Figa wrote:
>> On Thu, Jul 6, 2017 at 11:10 PM, Christoph Hellwig wrote:
>>> On Thu, Jul 06, 2017 at 12:09:45PM +0100, Robin Murphy wrote:
I suppose another option is to just make the IOMMU and DMA
On Tue, Jul 11, 2017 at 6:58 AM, Brian Gerst wrote:
> On Mon, Jul 10, 2017 at 3:50 PM, Tom Lendacky wrote:
>> On 7/8/2017 7:57 AM, Brian Gerst wrote:
>>> On Fri, Jul 7, 2017 at 9:39 AM, Tom Lendacky
>>
>> I originally had a check for SME here in a previous version of the
>> patch. Thomas Gleixn
On Wed, Jul 19, 2017 at 5:12 AM, Yong Zhi wrote:
> From: Tomasz Figa
>
> This patch adds support for the IPU3 DMA mapping API.
>
> Signed-off-by: Tomasz Figa
> Signed-off-by: Yong Zhi
This needs some explanation on why you decided to go down the
route of adding your own dma_map_ops. It's not o
The OMAP IOMMU driver intentionally fails to build on OMAP1
platforms, so we should not allow enabling it there.
Signed-off-by: Arnd Bergmann
Cc: Joerg Roedel
Cc: iommu@lists.linux-foundation.org
Cc: Ohad Ben-Cohen
Cc: Tony Lindgren
Cc: Omar Ramirez Luna
---
drivers/iommu/Kconfig | 2 +-
1
directly
to the arm-soc tree with an Ack or do a round-trip through
the platform maintainer tree. I think Tony already has some of
the OMAP1 fixes, so we should try not to duplicate them.
Arnd
Arnd Bergmann (9):
clk: vt8500: Fix "fix device clock divisor calculations"
Revert parts
On Thursday 27 February 2014, Ritesh Harjani wrote:
> Hi Everyone,
>
> I was going through some iommu code in arch/arm and of some other
> archs code. I have some doubts on this for refactoring and may need
> some suggestions from you guys.
>
> 1. So, looking at other arch code, looks like they h
On Monday 10 March 2014, Ritesh Harjani wrote:
>
> Hi Everyone,
>
> Please find the following patch as refactoring of the common code out
> from arch/arm/mm/dma-mapping.c to lib/iommu-helper.c
>
> This is just an initial version of patch to get more details and to
> know if this is how we want t
On Friday 14 March 2014, Santosh Shilimkar wrote:
> I remember NAKing this approach in past and my stand remains same.
> The cache APIs which you are trying to use here are not suppose
> to be used outside.
>
> I think the right way to fix this is to make use of streaming APIs.
> If needed, IOMMU
On Sunday 27 April 2014 13:07:47 Shaik Ameer Basha wrote:
> @@ -542,14 +592,41 @@ static int __init exynos_sysmmu_probe(struct
> platform_device *pdev)
> }
> }
>
> + /* Relation between master and System MMU is 1:1. */
> + node = of_parse_phandle(dev->of_node, "mmu-ma
On Sunday 27 April 2014 13:07:43 Shaik Ameer Basha wrote:
> +- mmu-masters: A phandle to device nodes representing the master for which
> + the System MMU can provide a translation. Any additional
> values
> + after the phandle will be ignored because a System MMU never
On Sunday 27 April 2014 13:07:32 Shaik Ameer Basha wrote:
> The current exynos-iommu(System MMU) driver does not work autonomously
> since it is lack of support for power management of peripheral blocks.
> For example, MFC device driver must ensure that its System MMU is disabled
> before MFC block
On Monday 28 April 2014 12:39:20 Thierry Reding wrote:
> On Sun, Apr 27, 2014 at 08:23:06PM +0200, Arnd Bergmann wrote:
> > On Sunday 27 April 2014 13:07:43 Shaik Ameer Basha wrote:
> > > +- mmu-masters: A phandle to device nodes representing the master for
> > > whic
On Monday 28 April 2014 13:18:03 Thierry Reding wrote:
> On Mon, Apr 28, 2014 at 12:56:03PM +0200, Arnd Bergmann wrote:
> > On Monday 28 April 2014 12:39:20 Thierry Reding wrote:
> > > And possibly with a iommu-names property to go along with that. The idea
> > > b
On Monday 28 April 2014 20:30:56 Will Deacon wrote:
> Hi Arnd,
>
> [and thanks Thierry for CCing me -- I have been tangled up with this before
> :)]
>
> On Mon, Apr 28, 2014 at 01:05:30PM +0100, Arnd Bergmann wrote:
> > On Monday 28 April 2014 13:18:03 Thierry Reding wrot
On Tuesday 29 April 2014 19:16:02 Dave Martin wrote:
> On Mon, Apr 28, 2014 at 09:55:00PM +0200, Arnd Bergmann wrote:
> > On Monday 28 April 2014 20:30:56 Will Deacon wrote:
> >
> > > > device@4 {
> > > > compatible = "so
On Tuesday 29 April 2014 13:07:54 Grant Grundler wrote:
> On Tue, Apr 29, 2014 at 11:16 AM, Dave Martin wrote:
> ...
> > An IOMMU is really a specialised bridge
>
> Is a GART a bridge?
>
> IOMMUs can provide three basic functions:
> 1) remap address space to reach phys mem ranges that the device
On Thursday 01 May 2014 12:15:35 Dave Martin wrote:
> On Tue, Apr 29, 2014 at 10:46:18PM +0200, Arnd Bergmann wrote:
> > On Tuesday 29 April 2014 19:16:02 Dave Martin wrote:
>
> [...]
>
> > > For example, suppose devices can post MSIs to an interrupt controller
&
On Thursday 01 May 2014 23:02:14 Cho KyongHo wrote:
> >
> > - device can only do DMA to a limited address range
> > - DMA is noncoherent and needs manual cache management
> > - DMA address is at an offset from physical address
> > - some devices have an IOMMU
> > - some IOMMUs are shared between d
On Thursday 01 May 2014 15:36:54 Dave Martin wrote:
> On Thu, May 01, 2014 at 02:29:50PM +0100, Arnd Bergmann wrote:
> > On Thursday 01 May 2014 12:15:35 Dave Martin wrote:
> > > > > I'm not sure whether there is actually a SoC today that is MSI-capable
> > >
On Thursday 01 May 2014 16:11:48 Marc Zyngier wrote:
> On 01/05/14 15:36, Dave Martin wrote:
> > On Thu, May 01, 2014 at 02:29:50PM +0100, Arnd Bergmann wrote:
> >> On Thursday 01 May 2014 12:15:35 Dave Martin wrote:
> >>> On Tue, Apr 29, 2014 at 10:46:18PM +0200,
On Tuesday 06 May 2014 19:59:05 Joerg Roedel wrote:
> On Wed, Apr 30, 2014 at 04:27:10PM +0530, Shaik Ameer Basha wrote:
> > This series is going on for quite a long time and most of the patches here
> > doesn't depend on dt bindings. As Exynos IOMMU h/w is introducing new
> > versions
> > very fr
On Monday 12 May 2014 11:44:45 Shaik Ameer Basha wrote:
> This is the subset of previous v12 series and includes only the fixes and
> enhancements, leaving out the private DT bindings as discussed in the below
> thread.
> -- http://www.gossamer-threads.com/lists/linux/kernel/1918178
>
> This
igned-off-by: Shaik Ameer Basha
>
Acked-by: Arnd Bergmann
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Friday 16 May 2014 14:23:18 Thierry Reding wrote:
> From: Thierry Reding
>
> This commit introduces a generic device tree binding for IOMMU devices.
> Only a very minimal subset is described here, but it is enough to cover
> the requirements of both the Exynos System MMU and Tegra SMMU as
> di
On Monday 19 May 2014 14:53:37 Thierry Reding wrote:
> On Mon, May 19, 2014 at 12:26:35PM +0200, Arnd Bergmann wrote:
> > On Friday 16 May 2014 14:23:18 Thierry Reding wrote:
> > > From: Thierry Reding
> > >
> > > This commit introduces a generic device tree b
On Monday 19 May 2014 22:59:46 Thierry Reding wrote:
> On Mon, May 19, 2014 at 08:34:07PM +0200, Arnd Bergmann wrote:
> > On Monday 19 May 2014 14:53:37 Thierry Reding wrote:
> > > On Mon, May 19, 2014 at 12:26:35PM +0200, Arnd Bergmann wrote:
> > > > On Friday 16 Ma
On Monday 19 May 2014 22:32:33 Thierry Reding wrote:
> On Mon, May 19, 2014 at 06:22:31PM +0100, Dave Martin wrote:
> > On Mon, May 19, 2014 at 01:53:37PM +0100, Thierry Reding wrote:
> [...]
> > > My understanding here is mostly based on the OpenFirmware working group
> > > proposal for the dma-ra
On Tuesday 20 May 2014 13:05:37 Thierry Reding wrote:
> On Tue, May 20, 2014 at 12:04:54PM +0200, Arnd Bergmann wrote:
> > On Monday 19 May 2014 22:59:46 Thierry Reding wrote:
> > > On Mon, May 19, 2014 at 08:34:07PM +0200, Arnd Bergmann wrote:
> > > > On Monday 19 Ma
On Tuesday 20 May 2014 14:02:43 Thierry Reding wrote:
> On Tue, May 20, 2014 at 01:15:48PM +0200, Arnd Bergmann wrote:
> > On Tuesday 20 May 2014 13:05:37 Thierry Reding wrote:
> > > On Tue, May 20, 2014 at 12:04:54PM +0200, Arnd Bergmann wrote:
> > > > On Monda
On Tuesday 20 May 2014 14:07:09 Dave Martin wrote:
> On Tue, May 20, 2014 at 12:08:44PM +0200, Arnd Bergmann wrote:
> > On Monday 19 May 2014 22:32:33 Thierry Reding wrote:
> > > On Mon, May 19, 2014 at 06:22:31PM +0100, Dave Martin wrote:
> > > > On Mon, May 19, 201
On Tuesday 20 May 2014 15:17:43 Thierry Reding wrote:
> On Tue, May 20, 2014 at 02:41:18PM +0200, Arnd Bergmann wrote:
> > On Tuesday 20 May 2014 14:02:43 Thierry Reding wrote:
> [...]
> > > Couldn't a single-master IOMMU be windowed?
> >
> > Ah, yes. That
On Tuesday 20 May 2014 16:24:59 Dave Martin wrote:
> On Tue, May 20, 2014 at 02:41:18PM +0200, Arnd Bergmann wrote:
> > On Tuesday 20 May 2014 14:02:43 Thierry Reding wrote:
> > > On Tue, May 20, 2014 at 01:15:48PM +0200, Arnd Bergmann wrote:
> > > Typical v
On Tuesday 20 May 2014 16:00:02 Thierry Reding wrote:
> On Tue, May 20, 2014 at 03:34:46PM +0200, Arnd Bergmann wrote:
> > On Tuesday 20 May 2014 15:17:43 Thierry Reding wrote:
> > > On Tue, May 20, 2014 at 02:41:18PM +0200, Arnd Bergmann wrote:
> > > > On Tuesda
On Tuesday 20 May 2014 17:39:12 Dave Martin wrote:
> On Tue, May 20, 2014 at 04:26:59PM +0100, Will Deacon wrote:
> > On Tue, May 20, 2014 at 02:23:47PM +0100, Arnd Bergmann wrote:
> > > Bit# 3322 1100
> > > 10987654 32109876 5432
On Wednesday 21 May 2014 10:26:11 Thierry Reding wrote:
> On Tue, May 20, 2014 at 10:26:12PM +0200, Arnd Bergmann wrote:
> > On Tuesday 20 May 2014 16:24:59 Dave Martin wrote:
> > > On Tue, May 20, 2014 at 02:41:18PM +0200, Arnd Bergmann wrote:
> > > > On Tuesda
On Wednesday 21 May 2014 10:16:09 Thierry Reding wrote:
> On Tue, May 20, 2014 at 10:31:29PM +0200, Arnd Bergmann wrote:
> > On Tuesday 20 May 2014 16:00:02 Thierry Reding wrote:
> > > On Tue, May 20, 2014 at 03:34:46PM +0200, Arnd Bergmann wrote:
> > > > On Tuesda
On Wednesday 21 May 2014 11:02:45 Thierry Reding wrote:
> On Wed, May 21, 2014 at 10:54:42AM +0200, Arnd Bergmann wrote:
>
> > Right. As long as we always unmap the buffers from the IOMMU after they
> > have stopped being in use, it's very unlikely that even a broken device
On Wednesday 21 May 2014 11:00:38 Thierry Reding wrote:
> On Wed, May 21, 2014 at 10:50:38AM +0200, Arnd Bergmann wrote:
> > On Wednesday 21 May 2014 10:26:11 Thierry Reding wrote:
> > > > > For determining dma masks, it is the output address that it
> > > &
On Wednesday 21 May 2014 12:50:38 Thierry Reding wrote:
> On Wed, May 21, 2014 at 11:36:32AM +0200, Arnd Bergmann wrote:
> > On Wednesday 21 May 2014 11:00:38 Thierry Reding wrote:
> > > On Wed, May 21, 2014 at 10:50:38AM +0200, Arnd Bergmann wrote:
> > > > On
On Wednesday 21 May 2014 08:44:42 Grant Grundler wrote:
> On Wed, May 21, 2014 at 2:32 AM, Arnd Bergmann wrote:
> > On Wednesday 21 May 2014 11:02:45 Thierry Reding wrote:
> >> On Wed, May 21, 2014 at 10:54:42AM +0200, Arnd Bergmann wrote:
> >>
> >> > Right.
On Wednesday 21 May 2014 18:09:54 Dave Martin wrote:
> On Wed, May 21, 2014 at 11:00:38AM +0200, Thierry Reding wrote:
> > On Wed, May 21, 2014 at 10:50:38AM +0200, Arnd Bergmann wrote:
> > > On Wednesday 21 May 2014 10:26:11 Thierry Reding wrote:
> > > >
> >
On Friday 30 May 2014 12:22:32 Dave Martin wrote:
> > +
> > +Examples:
> > +=
> > +
> > +Single-master IOMMU:
> > +
> > +
> > + iommu {
> > + #address-cells = <0>;
> > + #size-cells = <0>;
> > + };
> > +
> > + master {
> > + iommus = <
On Friday 30 May 2014 08:16:05 Rob Herring wrote:
> On Fri, May 23, 2014 at 3:33 PM, Thierry Reding
> wrote:
> > From: Thierry Reding
> > +IOMMU master node:
> > +==
> > +
> > +Devices that access memory through an IOMMU are called masters. A device
> > can
> > +have multiple mas
On Friday 30 May 2014 12:27:28 Dave Martin wrote:
> On Fri, May 30, 2014 at 08:30:08AM +0100, Thierry Reding wrote:
> > On Thu, May 29, 2014 at 09:52:22AM -0600, Stephen Warren wrote:
> > > On 05/23/2014 02:36 PM, Thierry Reding wrote:
> > > I think this is a mistake. address-cells/size-cells are f
On Friday 30 May 2014 14:31:55 Rob Herring wrote:
> On Fri, May 30, 2014 at 2:06 PM, Arnd Bergmann wrote:
> > On Friday 30 May 2014 08:16:05 Rob Herring wrote:
> >> On Fri, May 23, 2014 at 3:33 PM, Thierry Reding
> >> wrote:
> >> > From: Th
On Friday 30 May 2014 22:29:13 Hiroshi Doyu wrote:
>
> IIUC the original problem, "a master with 8 streamIDs" means something
> like below, where some devices have multiple IDs but some have a
> single. A sinle #address-cells cannot afford those 2 masters at once.
>
>iommu {
>
On Wednesday 04 June 2014 15:44:03 Thierry Reding wrote:
> > Well, the iommu specific binding could allow a variable #address-cells.
> > That way, you just need to know the number of stream IDs for that instance
> > of the iommu.
>
> That sounds fairly complicated to me. I don't see what that buys
On Wednesday 04 June 2014 14:56:01 Will Deacon wrote:
> On Wed, Jun 04, 2014 at 02:44:03PM +0100, Thierry Reding wrote:
> > On Fri, May 30, 2014 at 09:54:37PM +0200, Arnd Bergmann wrote:
> > > On Friday 30 May 2014 22:29:13 Hiroshi Doyu wrote:
> > > > The disadvanta
On Wednesday 04 June 2014 23:32:00 Thierry Reding wrote:
> On Fri, May 30, 2014 at 09:01:19PM +0200, Arnd Bergmann wrote:
> > On Friday 30 May 2014 12:22:32 Dave Martin wrote:
> > > > +
> > > > +Examples:
> > > > +===
On Saturday 07 June 2014 00:45:45 Thierry Reding wrote:
> This is somewhat off-topic, but given the various concepts discussed in
> this thread I'm beginning to wonder how they will be implemented.
I think it's good you raised the question.
> The
> current implementation hooks the IOMMU API into
On Monday 16 June 2014 18:04:16 Will Deacon wrote:
>
> On Mon, Jun 16, 2014 at 05:56:32PM +0100, Stuart Yoder wrote:
> > > Do you have use-cases where you really need to change these mappings
> > > dynamically?
> >
> > Yes. In the case of a PCI bus-- you may not know in advance how many
> > PCI
On Wednesday 18 June 2014 11:14:39 Will Deacon wrote:
> On Wed, Jun 18, 2014 at 12:37:16AM +0100, Thierry Reding wrote:
> - Each master has a set of fixed StreamIDs
> - StreamIDs can be remastered by adding a constant offset (this could also
> be used to describe RequesterID -> StreamID map
On Friday 20 June 2014 18:50:51 Will Deacon wrote:
> On Fri, Jun 20, 2014 at 04:53:08PM +0100, Arnd Bergmann wrote:
> > On Wednesday 18 June 2014 11:14:39 Will Deacon wrote:
> > > On Wed, Jun 18, 2014 at 12:37:16AM +0100, Thierry Reding wrote:
> > > - Each master h
On Tuesday 24 June 2014 19:11:50 Will Deacon wrote:
> On Tue, Jun 24, 2014 at 06:57:44PM +0100, Olav Haugan wrote:
> > On 6/24/2014 2:18 AM, Will Deacon wrote:
> > > On Sat, Jun 21, 2014 at 12:16:25AM +0100, Olav Haugan wrote:
> > >> We have multiple-master SMMUs and each master emits a variable nu
On Wednesday 25 June 2014 10:17:02 Will Deacon wrote:
> On Tue, Jun 24, 2014 at 07:20:56PM +0100, Arnd Bergmann wrote:
> > On Tuesday 24 June 2014 19:11:50 Will Deacon wrote:
> > > On Tue, Jun 24, 2014 at 06:57:44PM +0100, Olav Haugan wrote:
> > > > We do describe th
On Wednesday 25 June 2014 10:38:25 Will Deacon wrote:
> On Wed, Jun 25, 2014 at 10:27:50AM +0100, Arnd Bergmann wrote:
> > On Wednesday 25 June 2014 10:17:02 Will Deacon wrote:
> > > On Tue, Jun 24, 2014 at 07:20:56PM +0100, Arnd Bergmann wrote:
> > > > On Tuesday 24
On Wednesday 25 June 2014 10:57:36 Will Deacon wrote:
> So far, I've been avoiding the hardcoding. However, you could potentially
> build a system with a small number of SMRs (compared to the number of
> StreamIDs) and allocate the StreamIDs in such a way that I think the dynamic
> configuration wo
On Friday 27 June 2014 12:46:14 Hiroshi DOyu wrote:
>
> Thierry Reding writes:
>
> > From: Thierry Reding
> >
> > When an IOMMU device is available on the platform bus, allocate an IOMMU
> > domain and attach the display controllers to it. The display controllers
> > can then scan out non-conti
On Thursday 26 June 2014 22:49:44 Thierry Reding wrote:
> +static const struct tegra_mc_client tegra124_mc_clients[] = {
> + {
> + .id = 0x01,
> + .name = "display0a",
> + .swgroup = TEGRA_SWGROUP_DC,
> + .smmu = {
> +
On Friday 04 July 2014 06:42:48 Varun Sethi wrote:
> Master node corresponds to the device node, right? Master ID would correspond
> to Stream ID? We are already using "iommu-parent" property to link a device
> to its corresponding IOMMU. We can use the same property instead of using
> "iommus".
On Friday 04 July 2014, Will Deacon wrote:
> On Fri, Jul 04, 2014 at 02:47:10PM +0100, Thierry Reding wrote:
> > On Fri, Jul 04, 2014 at 01:05:30PM +0200, Joerg Roedel wrote:
> > > On Thu, Jun 26, 2014 at 10:49:41PM +0200, Thierry Reding wrote:
> > > > Add an IOMMU device registry for drivers to re
On Saturday 12 July 2014, Rob Clark wrote:
> >> Was there actually a good reason for having the device link to the
> >> iommu rather than the other way around? How much would people hate it
> >> if I just ignore the generic bindings and use something that works for
> >> me instead. I mean, it isn
were waiting for an ACK from the device tree
> bindings maintainers?
>
> Will, perhaps you can get Pawel or Mark to look at this?
>
> Arnd, I'm sure if we had your Acked-by that would go a long way too.
Sorry for missing this before my vacation.
Reviewed-by: Arnd Bergman
On Mon, Jan 14, 2019 at 11:27 AM Ulf Hansson wrote:
>
> +Linus Walleij (recently made a cleanup of the mmc bounce buffering code).
>
> On Mon, 14 Jan 2019 at 10:58, Christoph Hellwig wrote:
> >
> > Hi everyone,
> >
> > this series converts the remaining MMC host drivers to properly kmap the
> > s
On Wed, Jan 16, 2019 at 2:51 PM Linus Walleij wrote:
>
> On Wed, Jan 16, 2019 at 11:25 AM Arnd Bergmann wrote:
> > On Mon, Jan 14, 2019 at 11:27 AM Ulf Hansson wrote:
> > >
> > > +Linus Walleij (recently made a cleanup of the mmc bounce buffering code).
>
bled hardware platforms, while the physical
address space depends on the type of MMU chosen (classic vs LPAE).
I tried a couple of alternative approaches, but the previous version
seems as good as any other, so I went back to that.
Fixes: b907e20508d0 ("swiotlb: remove SWIOTLB_MAP_ERROR&q
On Tue, Mar 5, 2019 at 12:56 AM Robin Murphy wrote:
> On 2019-03-04 7:59 pm, Arnd Bergmann wrote:
> > This reverts commit b907e20508d0 ("swiotlb: remove SWIOTLB_MAP_ERROR"),
> > which
> > introduced an overflow warning in configurations that have a larger
org/show_bug.cgi?id=38789
Signed-off-by: Arnd Bergmann
---
include/linux/dma-mapping.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 75e60be91e5f..380d3a95d02e 100644
--- a/include/linux/dma-mapping.h
+++ b/incl
On Thu, Mar 7, 2019 at 9:28 AM Geert Uytterhoeven wrote:
> On Thu, Mar 7, 2019 at 9:01 AM Arnd Bergmann wrote:
> > Clang has a rather annoying behavior of checking for integer
> > arithmetic problems in code paths that are discarded by gcc
> > before that perfoms the sam
org/show_bug.cgi?id=38789
Signed-off-by: Arnd Bergmann
---
v2: fix off-by-one error
---
include/linux/dma-mapping.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 75e60be91e5f..9e438fe6b130 100644
--- a/include/li
On Thu, Mar 7, 2019 at 10:17 AM Robin Murphy wrote:
> On 2019-03-07 8:52 am, Arnd Bergmann wrote:
> >
> > -#define DMA_BIT_MASK(n) (((n) == 64) ? ~0ULL : ((1ULL<<(n))-1))
> > +/* double shift to work around https://bugs.llvm.org/show_bug.cgi?id=38789
> &g
org/show_bug.cgi?id=38789
Reviewed-by: Geert Uytterhoeven
Reviewed-by: Robin Murphy
Signed-off-by: Arnd Bergmann
---
v3: use (2ull << n-1) instead of ((1ull << n-1) << 1)
special-case 0 instead of 64
v2: fix off-by-one error
---
include/linux/dma-mapping.h | 6 +-
1 file
On Wed, Mar 13, 2019 at 7:33 PM Christoph Hellwig wrote:
> On Fri, Mar 08, 2019 at 05:25:57PM +, Julien Grall wrote:
> > In the common case, Dom0 also contains the PV backend drivers. Those
> > drivers may directly use the guest buffer in the DMA request (so a copy is
> > avoided). To avoid us
onvert to probe/release_device()
call-backs")
Signed-off-by: Arnd Bergmann
---
drivers/iommu/ipmmu-vmsa.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index fb7e702dee23..4c2972f3153b 100644
--- a/drivers/iomm
On Wed, May 27, 2020 at 11:00 AM Greg Kroah-Hartman
wrote:
>
> On Tue, May 26, 2020 at 07:49:07PM +0800, Zhangfei Gao wrote:
> > Some platform devices appear as PCI but are actually on the AMBA bus,
>
> Why would these devices not just show up on the AMBA bus and use all of
> that logic instead of
On Tue, Jun 9, 2020 at 6:02 AM Zhangfei Gao wrote:
> On 2020/6/9 上午12:41, Bjorn Helgaas wrote:
> > On Mon, Jun 08, 2020 at 10:54:15AM +0800, Zhangfei Gao wrote:
> >> On 2020/6/6 上午7:19, Bjorn Helgaas wrote:
> +++ b/drivers/iommu/iommu.c
> @@ -2418,6 +2418,10 @@ int iommu_fwspec_init(stru
On Friday 24 February 2012, Marek Szyprowski wrote:
> > > +static struct page **__iommu_alloc_buffer(struct device *dev, size_t
> > > +size, gfp_t gfp) {
> > > + struct page **pages;
> > > + int count = size >> PAGE_SHIFT;
> > > + int i=0;
> > > +
> > > + pages = kzalloc(count * siz
On Friday 24 February 2012, Marek Szyprowski wrote:
> I want to use some kind of chained arrays, each of at most of PAGE_SIZE. This
> code
> doesn't really need to keep these page pointers in contiguous virtual memory
> area, so
> it will not be a problem here.
>
Sounds like sg_alloc_table(), c
On Tuesday 10 April 2012, Marek Szyprowski wrote:
> Replace all uses of ~0 with ARM_DMA_ERROR, what should make the code
> easier to read.
>
> Signed-off-by: Marek Szyprowski
> Acked-by: Kyungmin Park
I like the idea, but why not name this DMA_ERROR_CODE like the other
architectures do? I think
On Tuesday 10 April 2012, Marek Szyprowski wrote:
>
> Replace all calls to printk with pr_* functions family.
>
> Signed-off-by: Marek Szyprowski
> Acked-by: Kyungmin Park
Acked-by: Arnd Bergmann
___
iommu mailing list
io
On Tuesday 10 April 2012, Marek Szyprowski wrote:
> This patch removes the need for offset parameter in dma bounce
> functions. This is required to let dma-mapping framework on ARM
> architecture use common, generic dma-mapping helpers.
>
> Signed-off-by: Marek Szyprowski
> Acked-by: Kyungmin Par
On Tuesday 10 April 2012, Marek Szyprowski wrote:
> This patch modifies dma-mapping implementation on ARM architecture to
> use common dma_map_ops structure and asm-generic/dma-mapping-common.h
> helpers.
>
> Signed-off-by: Marek Szyprowski
> Acked-by: Kyungmin Park
> ---
> arch/arm/Kconfig
On Tuesday 10 April 2012, Marek Szyprowski wrote:
> +/**
> + * arm_iommu_create_mapping
> + * @bus: pointer to the bus holding the client device (for IOMMU calls)
> + * @base: start address of the valid IO address space
> + * @size: size of the valid IO address space
> + * @order: accuracy of the I
bine methods.
>
> Signed-off-by: Marek Szyprowski
> Acked-by: Kyungmin Park
Acked-by: Arnd Bergmann
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
: Marek Szyprowski
> Acked-by: Kyungmin Park
Acked-by: Arnd Bergmann
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Tuesday 10 April 2012, Marek Szyprowski wrote:
> This patch removes dma bounce hooks from the common dma mapping
> implementation on ARM architecture and creates a separate set of
> dma_map_ops for dma bounce devices.
>
> Signed-off-by: Marek Szyprowski
> Acked-by: Kyungmin Park
I could be m
On Tuesday 10 April 2012, Marek Szyprowski wrote:
> Before patch no 6, there were custom methods for all scatter/gather
> related operations. They iterated over the whole scatter list and called
> cache related operations directly (which in turn checked if we use dma
> bounce code or not and called
On Wednesday 11 April 2012, Marek Szyprowski wrote:
> Well, range sync functions are available from the early days of the dma
> mapping api (at least that's what I've found reading the change log and
> old patches). They are the correct way of doing a partial syncs on the
> buffer (usually used b
On Wednesday 11 April 2012, Thierry Reding wrote:
> * Daniel Vetter wrote:
> > On Wed, Apr 11, 2012 at 03:23:26PM +0200, Thierry Reding wrote:
> > > * Daniel Vetter wrote:
> > > > On Wed, Apr 11, 2012 at 02:10:30PM +0200, Thierry Reding wrote:
> > > > > This commit adds a very basic DRM driver fo
On Thursday 12 April 2012, Marek Szyprowski wrote:
> +
> > > +/*
> > > + * s5p_sysmmu_late_init
> > > + * Create DMA-mapping IOMMU context for specified devices. This function
> > > must
> > > + * be called later, once SYSMMU driver gets registered and probed.
> > > + */
> > > +static int __init s
On Thursday 12 April 2012, Marek Szyprowski wrote:
> Scatter lists were initially designed for the disk based block io operations,
> hence the presence of the in-page offsets and lengths for each chunk. For
> multimedia use cases providing an array of struct pages and asking
> dma-mapping
> to
1 - 100 of 345 matches
Mail list logo
