From: Joerg Roedel <joro@8bytes.org>
To: Hideki EIRAKU <hdk@igel.co.jp>
Cc: lethal@linux-sh.org, magnus.damm@gmail.com,
linux@arm.linux.org.uk, horms@verge.net.au,
laurent.pinchart@ideasonboard.com, matsu@igel.co.jp,
linux-sh@vger.kernel.org, linux-kernel@vger.kernel.org,
iommu@lists.linux-foundation.org, dhobsong@igel.co.jp,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v6 1/4] iommu/shmobile: Add iommu driver for Renesas IPMMU modules
Date: Wed, 6 Feb 2013 11:23:50 +0100 [thread overview]
Message-ID: <20130206102348.GA2634@8bytes.org> (raw)
In-Reply-To: <20130205.194209.52400155.hdk@igel.co.jp>
On Tue, Feb 05, 2013 at 07:42:09PM +0900, Hideki EIRAKU wrote:
> From: Joerg Roedel <joro@8bytes.org>
> > Why is it necessary to call dma_map_single() for IOMMU page-tables?
> > usually the dma_* functions call into IOMMU drivers, so why are they
> > used inside an IOMMU driver?
>
> I use dma_map_single() for flushing the page table to the IOMMU
> device. The dma_map_ops set by arch/arm/mm/dma-mapping.c are
> per-device (unlike the intel-iommu). The dma_* functions call into
> IOMMU drivers if the device is attached by arm_iommu_attach_device(),
> but I am using a NULL device here, so that shouldn't happen.
Okay, I applied the patches to a new arm/shmobile branch. Will push them
out soon. The use of the dma_* functions is dangerous anyway (but it
works for now). Please send a follow-on patch to replace the use of the
dma_* functions in the driver with explicit flushing routines. This
protects the code from any future changes in the dma-api implementation.
Joerg
WARNING: multiple messages have this Message-ID (diff)
From: Joerg Roedel <joro@8bytes.org>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v6 1/4] iommu/shmobile: Add iommu driver for Renesas IPMMU modules
Date: Wed, 06 Feb 2013 10:23:50 +0000 [thread overview]
Message-ID: <20130206102348.GA2634@8bytes.org> (raw)
In-Reply-To: <20130205.194209.52400155.hdk@igel.co.jp>
On Tue, Feb 05, 2013 at 07:42:09PM +0900, Hideki EIRAKU wrote:
> From: Joerg Roedel <joro@8bytes.org>
> > Why is it necessary to call dma_map_single() for IOMMU page-tables?
> > usually the dma_* functions call into IOMMU drivers, so why are they
> > used inside an IOMMU driver?
>
> I use dma_map_single() for flushing the page table to the IOMMU
> device. The dma_map_ops set by arch/arm/mm/dma-mapping.c are
> per-device (unlike the intel-iommu). The dma_* functions call into
> IOMMU drivers if the device is attached by arm_iommu_attach_device(),
> but I am using a NULL device here, so that shouldn't happen.
Okay, I applied the patches to a new arm/shmobile branch. Will push them
out soon. The use of the dma_* functions is dangerous anyway (but it
works for now). Please send a follow-on patch to replace the use of the
dma_* functions in the driver with explicit flushing routines. This
protects the code from any future changes in the dma-api implementation.
Joerg
WARNING: multiple messages have this Message-ID (diff)
From: joro@8bytes.org (Joerg Roedel)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v6 1/4] iommu/shmobile: Add iommu driver for Renesas IPMMU modules
Date: Wed, 6 Feb 2013 11:23:50 +0100 [thread overview]
Message-ID: <20130206102348.GA2634@8bytes.org> (raw)
In-Reply-To: <20130205.194209.52400155.hdk@igel.co.jp>
On Tue, Feb 05, 2013 at 07:42:09PM +0900, Hideki EIRAKU wrote:
> From: Joerg Roedel <joro@8bytes.org>
> > Why is it necessary to call dma_map_single() for IOMMU page-tables?
> > usually the dma_* functions call into IOMMU drivers, so why are they
> > used inside an IOMMU driver?
>
> I use dma_map_single() for flushing the page table to the IOMMU
> device. The dma_map_ops set by arch/arm/mm/dma-mapping.c are
> per-device (unlike the intel-iommu). The dma_* functions call into
> IOMMU drivers if the device is attached by arm_iommu_attach_device(),
> but I am using a NULL device here, so that shouldn't happen.
Okay, I applied the patches to a new arm/shmobile branch. Will push them
out soon. The use of the dma_* functions is dangerous anyway (but it
works for now). Please send a follow-on patch to replace the use of the
dma_* functions in the driver with explicit flushing routines. This
protects the code from any future changes in the dma-api implementation.
Joerg
next prev parent reply other threads:[~2013-02-06 10:23 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-21 10:54 [PATCH v6 0/4] Renesas IPMMU driver for sh7372, sh73a0 and r8a7740 Hideki EIRAKU
2013-01-21 10:54 ` Hideki EIRAKU
2013-01-21 10:54 ` Hideki EIRAKU
2013-01-21 10:54 ` [PATCH v6 1/4] iommu/shmobile: Add iommu driver for Renesas IPMMU modules Hideki EIRAKU
2013-01-21 10:54 ` Hideki EIRAKU
2013-01-21 10:54 ` Hideki EIRAKU
[not found] ` <1358765669-14567-2-git-send-email-hdk-AlSX/UN32fvPDbFq/vQRIQ@public.gmane.org>
2013-02-01 13:54 ` Joerg Roedel
2013-02-01 13:54 ` Joerg Roedel
2013-02-01 13:54 ` Joerg Roedel
2013-02-01 13:54 ` Joerg Roedel
2013-02-05 10:42 ` Hideki EIRAKU
2013-02-05 10:42 ` Hideki EIRAKU
2013-02-05 10:42 ` Hideki EIRAKU
2013-02-06 10:23 ` Joerg Roedel [this message]
2013-02-06 10:23 ` Joerg Roedel
2013-02-06 10:23 ` Joerg Roedel
2013-01-21 10:54 ` [PATCH v6 2/4] ARM: mach-shmobile: sh7372: Add IPMMU device Hideki EIRAKU
2013-01-21 10:54 ` Hideki EIRAKU
2013-01-21 10:54 ` Hideki EIRAKU
2013-01-21 10:54 ` [PATCH v6 3/4] ARM: mach-shmobile: sh73a0: " Hideki EIRAKU
2013-01-21 10:54 ` Hideki EIRAKU
2013-01-21 10:54 ` Hideki EIRAKU
2013-01-21 10:54 ` [PATCH v6 4/4] ARM: mach-shmobile: r8a7740: " Hideki EIRAKU
2013-01-21 10:54 ` Hideki EIRAKU
2013-01-21 10:54 ` Hideki EIRAKU
[not found] ` <1358765669-14567-1-git-send-email-hdk-AlSX/UN32fvPDbFq/vQRIQ@public.gmane.org>
2013-02-01 13:56 ` [PATCH v6 0/4] Renesas IPMMU driver for sh7372, sh73a0 and r8a7740 Joerg Roedel
2013-02-01 13:56 ` Joerg Roedel
2013-02-01 13:56 ` Joerg Roedel
2013-02-01 13:56 ` Joerg Roedel
2013-02-01 14:09 ` Paul Mundt
2013-02-01 14:09 ` Paul Mundt
2013-02-01 14:09 ` Paul Mundt
2013-02-06 0:38 ` Simon Horman
2013-02-06 0:38 ` Simon Horman
2013-02-06 0:38 ` Simon Horman
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=20130206102348.GA2634@8bytes.org \
--to=joro@8bytes.org \
--cc=dhobsong@igel.co.jp \
--cc=hdk@igel.co.jp \
--cc=horms@verge.net.au \
--cc=iommu@lists.linux-foundation.org \
--cc=laurent.pinchart@ideasonboard.com \
--cc=lethal@linux-sh.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=magnus.damm@gmail.com \
--cc=matsu@igel.co.jp \
/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.