From: Ohad Ben-Cohen <ohad@wizery.com>
To: "Roedel, Joerg" <Joerg.Roedel@amd.com>
Cc: "linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Tony Lindgren <tony@atomide.com>,
Hiroshi DOYU <Hiroshi.DOYU@nokia.com>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Arnd Bergmann <arnd@arndb.de>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>
Subject: Re: [PATCH 1/7] omap: iommu: migrate to the generic IOMMU API
Date: Wed, 24 Aug 2011 17:46:37 +0300 [thread overview]
Message-ID: <CAK=WgbYtTvCi4yLBJphvni4XiZLwm_Rj9aZFXaTwg44J1BDGsw@mail.gmail.com> (raw)
In-Reply-To: <20110824131527.GI2079@amd.com>
On Wed, Aug 24, 2011 at 4:15 PM, Roedel, Joerg <Joerg.Roedel@amd.com> wrote:
> Yes, it should be safe in your context. But the iommu-api is generic and
> I would prefer that all functions it provides can be called from any
> context.
Not a problem.
I thought you only cared about map/unmap, but if you prefer
attach/deattach to be atomic too, I'll migrate the driver to use a
spin lock.
> Or is the time required for attaching/detaching too long so that it
> makes sense to put secondary threads to sleep?
It doesn't look like it. I think a mutex was originally chosen at that
point because those functions were used in a process context.
Thanks,
Ohad.
WARNING: multiple messages have this Message-ID (diff)
From: ohad@wizery.com (Ohad Ben-Cohen)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/7] omap: iommu: migrate to the generic IOMMU API
Date: Wed, 24 Aug 2011 17:46:37 +0300 [thread overview]
Message-ID: <CAK=WgbYtTvCi4yLBJphvni4XiZLwm_Rj9aZFXaTwg44J1BDGsw@mail.gmail.com> (raw)
In-Reply-To: <20110824131527.GI2079@amd.com>
On Wed, Aug 24, 2011 at 4:15 PM, Roedel, Joerg <Joerg.Roedel@amd.com> wrote:
> Yes, it should be safe in your context. But the iommu-api is generic and
> I would prefer that all functions it provides can be called from any
> context.
Not a problem.
I thought you only cared about map/unmap, but if you prefer
attach/deattach to be atomic too, I'll migrate the driver to use a
spin lock.
> Or is the time required for attaching/detaching too long so that it
> makes sense to put secondary threads to sleep?
It doesn't look like it. I think a mutex was originally chosen at that
point because those functions were used in a process context.
Thanks,
Ohad.
next prev parent reply other threads:[~2011-08-24 14:46 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-17 23:10 [PATCH 0/7] omap: iommu migration, relocation and cleanups Ohad Ben-Cohen
2011-08-17 23:10 ` Ohad Ben-Cohen
2011-08-17 23:10 ` [PATCH 1/7] omap: iommu: migrate to the generic IOMMU API Ohad Ben-Cohen
2011-08-17 23:10 ` Ohad Ben-Cohen
2011-08-18 9:01 ` Laurent Pinchart
2011-08-18 9:01 ` Laurent Pinchart
2011-08-18 9:05 ` Ohad Ben-Cohen
2011-08-18 9:05 ` Ohad Ben-Cohen
2011-08-18 13:35 ` Arnd Bergmann
2011-08-18 13:35 ` Arnd Bergmann
2011-08-23 14:07 ` Roedel, Joerg
2011-08-23 14:07 ` Roedel, Joerg
2011-08-23 14:59 ` Ohad Ben-Cohen
2011-08-23 14:59 ` Ohad Ben-Cohen
2011-08-24 12:46 ` Ohad Ben-Cohen
2011-08-24 12:46 ` Ohad Ben-Cohen
2011-08-24 13:15 ` Roedel, Joerg
2011-08-24 13:15 ` Roedel, Joerg
2011-08-24 14:46 ` Ohad Ben-Cohen [this message]
2011-08-24 14:46 ` Ohad Ben-Cohen
2011-08-17 23:10 ` [PATCH 2/7] omap: iommu/iovmm: move to dedicated iommu folder Ohad Ben-Cohen
2011-08-17 23:10 ` Ohad Ben-Cohen
2011-08-18 13:38 ` Arnd Bergmann
2011-08-18 13:38 ` Arnd Bergmann
2011-08-18 13:53 ` Ohad Ben-Cohen
2011-08-18 13:53 ` Ohad Ben-Cohen
2011-08-17 23:10 ` [PATCH 3/7] omap: iommu: stop exporting local functions Ohad Ben-Cohen
2011-08-17 23:10 ` Ohad Ben-Cohen
2011-08-17 23:10 ` [PATCH 4/7] omap: iommu: PREFETCH_IOTLB cleanup Ohad Ben-Cohen
2011-08-17 23:10 ` Ohad Ben-Cohen
2011-08-18 5:27 ` Hiroshi DOYU
2011-08-18 5:27 ` Hiroshi DOYU
2011-08-18 6:33 ` Ohad Ben-Cohen
2011-08-18 6:33 ` Ohad Ben-Cohen
2011-08-17 23:10 ` [PATCH 5/7] omap: iovmm: remove unused functionality Ohad Ben-Cohen
2011-08-17 23:10 ` Ohad Ben-Cohen
2011-08-18 10:19 ` Hiroshi DOYU
2011-08-18 10:19 ` Hiroshi DOYU
2011-08-18 10:23 ` Ohad Ben-Cohen
2011-08-18 10:23 ` Ohad Ben-Cohen
2011-08-18 12:45 ` Hiroshi DOYU
2011-08-18 12:45 ` Hiroshi DOYU
2011-08-17 23:10 ` [PATCH 6/7] omap: iommu: remove unused exported API Ohad Ben-Cohen
2011-08-17 23:10 ` Ohad Ben-Cohen
2011-08-18 10:49 ` Hiroshi DOYU
2011-08-18 10:49 ` Hiroshi DOYU
2011-08-18 11:01 ` Ohad Ben-Cohen
2011-08-18 11:01 ` Ohad Ben-Cohen
2011-08-18 13:40 ` David Cohen
2011-08-18 13:40 ` David Cohen
2011-08-18 13:45 ` Ohad Ben-Cohen
2011-08-18 13:45 ` Ohad Ben-Cohen
2011-08-17 23:10 ` [PATCH 7/7] omap: iommu: omapify 'struct iommu' and exposed API Ohad Ben-Cohen
2011-08-17 23:10 ` Ohad Ben-Cohen
2011-08-18 9:12 ` [PATCH 0/7] omap: iommu migration, relocation and cleanups Laurent Pinchart
2011-08-18 9:12 ` Laurent Pinchart
2011-08-18 10:50 ` Hiroshi DOYU
2011-08-18 10:50 ` Hiroshi DOYU
2011-08-23 14:26 ` Roedel, Joerg
2011-08-23 14:26 ` Roedel, Joerg
2011-08-23 15:15 ` Ohad Ben-Cohen
2011-08-23 15:15 ` Ohad Ben-Cohen
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='CAK=WgbYtTvCi4yLBJphvni4XiZLwm_Rj9aZFXaTwg44J1BDGsw@mail.gmail.com' \
--to=ohad@wizery.com \
--cc=Hiroshi.DOYU@nokia.com \
--cc=Joerg.Roedel@amd.com \
--cc=arnd@arndb.de \
--cc=iommu@lists.linux-foundation.org \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=tony@atomide.com \
/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.