[RFC 0/5] OMAP groundwork for IOMMU-based DMA API

[RFC 0/5] OMAP groundwork for IOMMU-based DMA API

[Ohad Ben-Cohen]

Another step towards generic IOMMU support on OMAP: eliminating
the public omap-specific find_iommu_device API.

Instead, we now bind iommu clients with their respective iommu device
using a private iommu member which is added to ARM's dev_archdata.

With this in hand, generic IOMMU API users will now work on OMAP without
utilizing any omap-specific API.

The changes are tested on OMAP3 (with omap3isp) and OMAP4 (with
remoteproc/rpmsg).

This is still RFC (2nd patch is probably the least elegant).

Ohad Ben-Cohen (5):
  ARM: dev_archdata: add private iommu extension
  ARM: OMAP: omap_device: add a method to set iommu private archdata
  ARM: OMAP: iommu: declare a private iommu binding struct
  ARM: OMAP3: bind omap3isp_device to its iommu device
  iommu/omap: eliminate the public omap_find_iommu_device() method

 arch/arm/include/asm/device.h                 |    3 +
 arch/arm/mach-omap2/devices.c                 |    7 +++
 arch/arm/plat-omap/include/plat/iommu.h       |   31 ++++++++++++-
 arch/arm/plat-omap/include/plat/iovmm.h       |   12 +++---
 arch/arm/plat-omap/include/plat/omap_device.h |    6 +++
 arch/arm/plat-omap/omap_device.c              |   39 +++++++++++++++-
 drivers/iommu/omap-iommu.c                    |   58 +++++++++++--------------
 drivers/iommu/omap-iovmm.c                    |   31 +++++++++-----
 drivers/media/video/omap3isp/isp.c            |   30 ++-----------
 drivers/media/video/omap3isp/isp.h            |    2 -
 drivers/media/video/omap3isp/ispccdc.c        |   18 ++++----
 drivers/media/video/omap3isp/ispstat.c        |    8 ++--
 drivers/media/video/omap3isp/ispvideo.c       |    4 +-
 13 files changed, 152 insertions(+), 97 deletions(-)

-- 
1.7.4.1

[RFC 0/5] OMAP groundwork for IOMMU-based DMA API

[Ohad Ben-Cohen]

Another step towards generic IOMMU support on OMAP: eliminating
the public omap-specific find_iommu_device API.

Instead, we now bind iommu clients with their respective iommu device
using a private iommu member which is added to ARM's dev_archdata.

With this in hand, generic IOMMU API users will now work on OMAP without
utilizing any omap-specific API.

The changes are tested on OMAP3 (with omap3isp) and OMAP4 (with
remoteproc/rpmsg).

This is still RFC (2nd patch is probably the least elegant).

Ohad Ben-Cohen (5):
  ARM: dev_archdata: add private iommu extension
  ARM: OMAP: omap_device: add a method to set iommu private archdata
  ARM: OMAP: iommu: declare a private iommu binding struct
  ARM: OMAP3: bind omap3isp_device to its iommu device
  iommu/omap: eliminate the public omap_find_iommu_device() method

 arch/arm/include/asm/device.h                 |    3 +
 arch/arm/mach-omap2/devices.c                 |    7 +++
 arch/arm/plat-omap/include/plat/iommu.h       |   31 ++++++++++++-
 arch/arm/plat-omap/include/plat/iovmm.h       |   12 +++---
 arch/arm/plat-omap/include/plat/omap_device.h |    6 +++
 arch/arm/plat-omap/omap_device.c              |   39 +++++++++++++++-
 drivers/iommu/omap-iommu.c                    |   58 +++++++++++--------------
 drivers/iommu/omap-iovmm.c                    |   31 +++++++++-----
 drivers/media/video/omap3isp/isp.c            |   30 ++-----------
 drivers/media/video/omap3isp/isp.h            |    2 -
 drivers/media/video/omap3isp/ispccdc.c        |   18 ++++----
 drivers/media/video/omap3isp/ispstat.c        |    8 ++--
 drivers/media/video/omap3isp/ispvideo.c       |    4 +-
 13 files changed, 152 insertions(+), 97 deletions(-)

-- 
1.7.4.1

[RFC 0/5] OMAP groundwork for IOMMU-based DMA API

[Ohad Ben-Cohen]

Another step towards generic IOMMU support on OMAP: eliminating
the public omap-specific find_iommu_device API.

Instead, we now bind iommu clients with their respective iommu device
using a private iommu member which is added to ARM's dev_archdata.

With this in hand, generic IOMMU API users will now work on OMAP without
utilizing any omap-specific API.

The changes are tested on OMAP3 (with omap3isp) and OMAP4 (with
remoteproc/rpmsg).

This is still RFC (2nd patch is probably the least elegant).

Ohad Ben-Cohen (5):
  ARM: dev_archdata: add private iommu extension
  ARM: OMAP: omap_device: add a method to set iommu private archdata
  ARM: OMAP: iommu: declare a private iommu binding struct
  ARM: OMAP3: bind omap3isp_device to its iommu device
  iommu/omap: eliminate the public omap_find_iommu_device() method

 arch/arm/include/asm/device.h                 |    3 +
 arch/arm/mach-omap2/devices.c                 |    7 +++
 arch/arm/plat-omap/include/plat/iommu.h       |   31 ++++++++++++-
 arch/arm/plat-omap/include/plat/iovmm.h       |   12 +++---
 arch/arm/plat-omap/include/plat/omap_device.h |    6 +++
 arch/arm/plat-omap/omap_device.c              |   39 +++++++++++++++-
 drivers/iommu/omap-iommu.c                    |   58 +++++++++++--------------
 drivers/iommu/omap-iovmm.c                    |   31 +++++++++-----
 drivers/media/video/omap3isp/isp.c            |   30 ++-----------
 drivers/media/video/omap3isp/isp.h            |    2 -
 drivers/media/video/omap3isp/ispccdc.c        |   18 ++++----
 drivers/media/video/omap3isp/ispstat.c        |    8 ++--
 drivers/media/video/omap3isp/ispvideo.c       |    4 +-
 13 files changed, 152 insertions(+), 97 deletions(-)

-- 
1.7.4.1

[RFC 1/5] ARM: dev_archdata: add private iommu extension

[Ohad Ben-Cohen]

Add a private iommu pointer to the ARM-specific arch data in the
device struct, which will be used to attach iommu-specific data
to devices which require iommu support.

Different iommu implementations (on different platforms) will attach
different types of data to this pointer, so 'void *' is currently used
(the downside is reduced typesafety).

Note: ia64, x86 and sparc have this exact iommu extension as well, and
if others are likely to adopt it too, we might want to consider
adding this to the device struct itself directly.

Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Grant Likely <grant.likely@secretlab.ca>
---
 arch/arm/include/asm/device.h |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/arm/include/asm/device.h b/arch/arm/include/asm/device.h
index 9f390ce..6615f03 100644
--- a/arch/arm/include/asm/device.h
+++ b/arch/arm/include/asm/device.h
@@ -10,6 +10,9 @@ struct dev_archdata {
 #ifdef CONFIG_DMABOUNCE
 	struct dmabounce_device_info *dmabounce;
 #endif
+#ifdef CONFIG_IOMMU_API
+	void *iommu; /* private IOMMU data */
+#endif
 };
 
 struct pdev_archdata {
-- 
1.7.4.1

[RFC 1/5] ARM: dev_archdata: add private iommu extension

[Ohad Ben-Cohen]

Add a private iommu pointer to the ARM-specific arch data in the
device struct, which will be used to attach iommu-specific data
to devices which require iommu support.

Different iommu implementations (on different platforms) will attach
different types of data to this pointer, so 'void *' is currently used
(the downside is reduced typesafety).

Note: ia64, x86 and sparc have this exact iommu extension as well, and
if others are likely to adopt it too, we might want to consider
adding this to the device struct itself directly.

Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Grant Likely <grant.likely@secretlab.ca>
---
 arch/arm/include/asm/device.h |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/arm/include/asm/device.h b/arch/arm/include/asm/device.h
index 9f390ce..6615f03 100644
--- a/arch/arm/include/asm/device.h
+++ b/arch/arm/include/asm/device.h
@@ -10,6 +10,9 @@ struct dev_archdata {
 #ifdef CONFIG_DMABOUNCE
 	struct dmabounce_device_info *dmabounce;
 #endif
+#ifdef CONFIG_IOMMU_API
+	void *iommu; /* private IOMMU data */
+#endif
 };
 
 struct pdev_archdata {
-- 
1.7.4.1

Re: [RFC 1/5] ARM: dev_archdata: add private iommu extension

[Grant Likely]

On Sun, Sep 25, 2011 at 01:58:53PM +0300, Ohad Ben-Cohen wrote:
> Add a private iommu pointer to the ARM-specific arch data in the
> device struct, which will be used to attach iommu-specific data
> to devices which require iommu support.
> 
> Different iommu implementations (on different platforms) will attach
> different types of data to this pointer, so 'void *' is currently used
> (the downside is reduced typesafety).
> 
> Note: ia64, x86 and sparc have this exact iommu extension as well, and
> if others are likely to adopt it too, we might want to consider
> adding this to the device struct itself directly.
> 
> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> ---
>  arch/arm/include/asm/device.h |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/include/asm/device.h b/arch/arm/include/asm/device.h
> index 9f390ce..6615f03 100644
> --- a/arch/arm/include/asm/device.h
> +++ b/arch/arm/include/asm/device.h
> @@ -10,6 +10,9 @@ struct dev_archdata {
>  #ifdef CONFIG_DMABOUNCE
>  	struct dmabounce_device_info *dmabounce;
>  #endif
> +#ifdef CONFIG_IOMMU_API
> +	void *iommu; /* private IOMMU data */
> +#endif

Blech.  Oh well.  Not much point in doing something different if x86
uses a void*.

g.

[RFC 1/5] ARM: dev_archdata: add private iommu extension

[Grant Likely]

On Sun, Sep 25, 2011 at 01:58:53PM +0300, Ohad Ben-Cohen wrote:
> Add a private iommu pointer to the ARM-specific arch data in the
> device struct, which will be used to attach iommu-specific data
> to devices which require iommu support.
> 
> Different iommu implementations (on different platforms) will attach
> different types of data to this pointer, so 'void *' is currently used
> (the downside is reduced typesafety).
> 
> Note: ia64, x86 and sparc have this exact iommu extension as well, and
> if others are likely to adopt it too, we might want to consider
> adding this to the device struct itself directly.
> 
> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> ---
>  arch/arm/include/asm/device.h |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/include/asm/device.h b/arch/arm/include/asm/device.h
> index 9f390ce..6615f03 100644
> --- a/arch/arm/include/asm/device.h
> +++ b/arch/arm/include/asm/device.h
> @@ -10,6 +10,9 @@ struct dev_archdata {
>  #ifdef CONFIG_DMABOUNCE
>  	struct dmabounce_device_info *dmabounce;
>  #endif
> +#ifdef CONFIG_IOMMU_API
> +	void *iommu; /* private IOMMU data */
> +#endif

Blech.  Oh well.  Not much point in doing something different if x86
uses a void*.

g.

Re: [RFC 1/5] ARM: dev_archdata: add private iommu extension

[Ohad Ben-Cohen]

On Tue, Sep 27, 2011 at 4:30 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
> Blech.  Oh well.  Not much point in doing something different if x86
> uses a void*.

x86 probably does this because two different implementations needs to
plug their private data there: intel-iommu plugs there a 'struct
device_domain_info *' and amd_iommu uses it with a 'struct
iommu_dev_data *'.

On ARM we'd eventually end up with even a bigger variety, and I guess
that even if we'd use a type-safe member here, it would itself end up
having 'void *'.

If it looks reasonable to you, can I please have your Ack ?

Russell, can you please take a look too and ack/nack ?

Thanks,
Ohad.

[RFC 1/5] ARM: dev_archdata: add private iommu extension

[Ohad Ben-Cohen]

On Tue, Sep 27, 2011 at 4:30 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
> Blech. ?Oh well. ?Not much point in doing something different if x86
> uses a void*.

x86 probably does this because two different implementations needs to
plug their private data there: intel-iommu plugs there a 'struct
device_domain_info *' and amd_iommu uses it with a 'struct
iommu_dev_data *'.

On ARM we'd eventually end up with even a bigger variety, and I guess
that even if we'd use a type-safe member here, it would itself end up
having 'void *'.

If it looks reasonable to you, can I please have your Ack ?

Russell, can you please take a look too and ack/nack ?

Thanks,
Ohad.

Re: [RFC 1/5] ARM: dev_archdata: add private iommu extension

[Ohad Ben-Cohen]

On Tue, Sep 27, 2011 at 4:30 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
> Blech.  Oh well.  Not much point in doing something different if x86
> uses a void*.

x86 probably does this because two different implementations needs to
plug their private data there: intel-iommu plugs there a 'struct
device_domain_info *' and amd_iommu uses it with a 'struct
iommu_dev_data *'.

On ARM we'd eventually end up with even a bigger variety, and I guess
that even if we'd use a type-safe member here, it would itself end up
having 'void *'.

If it looks reasonable to you, can I please have your Ack ?

Russell, can you please take a look too and ack/nack ?

Thanks,
Ohad.

Re: [RFC 1/5] ARM: dev_archdata: add private iommu extension

[Ohad Ben-Cohen]

Hi Russell,

On Sun, Sep 25, 2011 at 1:58 PM, Ohad Ben-Cohen <ohad@wizery.com> wrote:
> Add a private iommu pointer to the ARM-specific arch data in the
> device struct, which will be used to attach iommu-specific data
> to devices which require iommu support.

Can you please take a look and ack/nack ?

With this change in hand, generic code will now be able to control
OMAP's iommu devices too, without having to use any OMAP-specific API
(this is demonstrated in this patch set).

This will allow us to further clean the existing mainline OMAP iommu
users, and focus on generic IOMMU code for future users
(rpmsg/remoteproc and Marek's upcoming generic DMA API).

The change is only effective when an iommu driver, which supports the
generic IOMMU API, is built (all of them must select
CONFIG_IOMMU_API), and otherwise is a nop.

Obviously the change itself is not OMAP-specific, and it will be
useful for other platforms too.

Thanks!
Ohad.

> Different iommu implementations (on different platforms) will attach
> different types of data to this pointer, so 'void *' is currently used
> (the downside is reduced typesafety).
>
> Note: ia64, x86 and sparc have this exact iommu extension as well, and
> if others are likely to adopt it too, we might want to consider
> adding this to the device struct itself directly.
>
> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> ---
>  arch/arm/include/asm/device.h |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/include/asm/device.h b/arch/arm/include/asm/device.h
> index 9f390ce..6615f03 100644
> --- a/arch/arm/include/asm/device.h
> +++ b/arch/arm/include/asm/device.h
> @@ -10,6 +10,9 @@ struct dev_archdata {
>  #ifdef CONFIG_DMABOUNCE
>        struct dmabounce_device_info *dmabounce;
>  #endif
> +#ifdef CONFIG_IOMMU_API
> +       void *iommu; /* private IOMMU data */
> +#endif
>  };
>
>  struct pdev_archdata {
> --
> 1.7.4.1
>
>

[RFC 1/5] ARM: dev_archdata: add private iommu extension

[Ohad Ben-Cohen]

Hi Russell,

On Sun, Sep 25, 2011 at 1:58 PM, Ohad Ben-Cohen <ohad@wizery.com> wrote:
> Add a private iommu pointer to the ARM-specific arch data in the
> device struct, which will be used to attach iommu-specific data
> to devices which require iommu support.

Can you please take a look and ack/nack ?

With this change in hand, generic code will now be able to control
OMAP's iommu devices too, without having to use any OMAP-specific API
(this is demonstrated in this patch set).

This will allow us to further clean the existing mainline OMAP iommu
users, and focus on generic IOMMU code for future users
(rpmsg/remoteproc and Marek's upcoming generic DMA API).

The change is only effective when an iommu driver, which supports the
generic IOMMU API, is built (all of them must select
CONFIG_IOMMU_API), and otherwise is a nop.

Obviously the change itself is not OMAP-specific, and it will be
useful for other platforms too.

Thanks!
Ohad.

> Different iommu implementations (on different platforms) will attach
> different types of data to this pointer, so 'void *' is currently used
> (the downside is reduced typesafety).
>
> Note: ia64, x86 and sparc have this exact iommu extension as well, and
> if others are likely to adopt it too, we might want to consider
> adding this to the device struct itself directly.
>
> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> ---
> ?arch/arm/include/asm/device.h | ? ?3 +++
> ?1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/include/asm/device.h b/arch/arm/include/asm/device.h
> index 9f390ce..6615f03 100644
> --- a/arch/arm/include/asm/device.h
> +++ b/arch/arm/include/asm/device.h
> @@ -10,6 +10,9 @@ struct dev_archdata {
> ?#ifdef CONFIG_DMABOUNCE
> ? ? ? ?struct dmabounce_device_info *dmabounce;
> ?#endif
> +#ifdef CONFIG_IOMMU_API
> + ? ? ? void *iommu; /* private IOMMU data */
> +#endif
> ?};
>
> ?struct pdev_archdata {
> --
> 1.7.4.1
>
>

Re: [RFC 1/5] ARM: dev_archdata: add private iommu extension

[Ohad Ben-Cohen]

On Wed, Oct 5, 2011 at 11:26 AM, Ohad Ben-Cohen <ohad@wizery.com> wrote:
> Hi Russell,
>
> On Sun, Sep 25, 2011 at 1:58 PM, Ohad Ben-Cohen <ohad@wizery.com> wrote:
>> Add a private iommu pointer to the ARM-specific arch data in the
>> device struct, which will be used to attach iommu-specific data
>> to devices which require iommu support.
>
> Can you please take a look and ack/nack ?

gentle reminder

[RFC 1/5] ARM: dev_archdata: add private iommu extension

[Ohad Ben-Cohen]

On Wed, Oct 5, 2011 at 11:26 AM, Ohad Ben-Cohen <ohad@wizery.com> wrote:
> Hi Russell,
>
> On Sun, Sep 25, 2011 at 1:58 PM, Ohad Ben-Cohen <ohad@wizery.com> wrote:
>> Add a private iommu pointer to the ARM-specific arch data in the
>> device struct, which will be used to attach iommu-specific data
>> to devices which require iommu support.
>
> Can you please take a look and ack/nack ?

gentle reminder

Re: [RFC 1/5] ARM: dev_archdata: add private iommu extension

[Russell King - ARM Linux]

On Thu, Oct 13, 2011 at 11:15:39AM +0200, Ohad Ben-Cohen wrote:
> On Wed, Oct 5, 2011 at 11:26 AM, Ohad Ben-Cohen <ohad@wizery.com> wrote:
> > Hi Russell,
> >
> > On Sun, Sep 25, 2011 at 1:58 PM, Ohad Ben-Cohen <ohad@wizery.com> wrote:
> >> Add a private iommu pointer to the ARM-specific arch data in the
> >> device struct, which will be used to attach iommu-specific data
> >> to devices which require iommu support.
> >
> > Can you please take a look and ack/nack ?
> 
> gentle reminder

Ok, I'll take it if you put it in the patch system.

Thanks.

[RFC 1/5] ARM: dev_archdata: add private iommu extension

[Russell King - ARM Linux]

On Thu, Oct 13, 2011 at 11:15:39AM +0200, Ohad Ben-Cohen wrote:
> On Wed, Oct 5, 2011 at 11:26 AM, Ohad Ben-Cohen <ohad@wizery.com> wrote:
> > Hi Russell,
> >
> > On Sun, Sep 25, 2011 at 1:58 PM, Ohad Ben-Cohen <ohad@wizery.com> wrote:
> >> Add a private iommu pointer to the ARM-specific arch data in the
> >> device struct, which will be used to attach iommu-specific data
> >> to devices which require iommu support.
> >
> > Can you please take a look and ack/nack ?
> 
> gentle reminder

Ok, I'll take it if you put it in the patch system.

Thanks.

Re: [RFC 1/5] ARM: dev_archdata: add private iommu extension

[Ohad Ben-Cohen]

On Thu, Oct 13, 2011 at 12:42 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> Ok, I'll take it if you put it in the patch system.

Done, thanks.

[RFC 1/5] ARM: dev_archdata: add private iommu extension

[Ohad Ben-Cohen]

On Thu, Oct 13, 2011 at 12:42 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> Ok, I'll take it if you put it in the patch system.

Done, thanks.

Re: [RFC 1/5] ARM: dev_archdata: add private iommu extension

[Ohad Ben-Cohen]

On Thu, Oct 13, 2011 at 12:42 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> Ok, I'll take it if you put it in the patch system.

Done, thanks.

[RFC 2/5] ARM: OMAP: omap_device: add a method to set iommu private archdata

[Ohad Ben-Cohen]

Make it possible to set an iommu private archdata before a newly-created
omap device is registered.

Binding iommu client devices with their respective iommu data this way
is needed so the generic IOMMU API can later be used without employing
any omap-specific IOMMU plumbing.

This patch just crudely adds an omap_device_build_ss_ext() method which
accepts an iommu private data, but we may actually want to do something
more generic here: e.g., split the omap_device_build API to alloc+add
methods, so users can just manipulate the device as needed before it is
registered (very much like we can do with plain devices).

Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
---
This is obviously not yet based on Benoit's recent changes; I'll do so after
we'll settle on the approach we want to take here.

 arch/arm/plat-omap/include/plat/omap_device.h |    6 ++++
 arch/arm/plat-omap/omap_device.c              |   39 +++++++++++++++++++++++--
 2 files changed, 42 insertions(+), 3 deletions(-)

diff --git a/arch/arm/plat-omap/include/plat/omap_device.h b/arch/arm/plat-omap/include/plat/omap_device.h
index ee405b36..a3f672c 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -102,6 +102,12 @@ struct omap_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
 					 void *pdata, int pdata_len,
 					 struct omap_device_pm_latency *pm_lats,
 					 int pm_lats_cnt, int is_early_device);
+struct omap_device *omap_device_build_ss_ext(const char *pdev_name, int pdev_id,
+					 struct omap_hwmod **ohs, int oh_cnt,
+					 void *pdata, int pdata_len,
+					 struct omap_device_pm_latency *pm_lats,
+					 int pm_lats_cnt, int is_early_device,
+					 void *iommu);
 
 int omap_device_register(struct omap_device *od);
 int omap_early_device_register(struct omap_device *od);
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index 02609ee..38bc753 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -422,7 +422,8 @@ struct omap_device *omap_device_build(const char *pdev_name, int pdev_id,
 }
 
 /**
- * omap_device_build_ss - build and register an omap_device with multiple hwmods
+ * omap_device_build_ss_ext - build and register an omap_device with multiple
+ *				hwmods and an optional private iommu data
  * @pdev_name: name of the platform_device driver to use
  * @pdev_id: this platform_device's connection ID
  * @oh: ptr to the single omap_hwmod that backs this omap_device
@@ -431,6 +432,7 @@ struct omap_device *omap_device_build(const char *pdev_name, int pdev_id,
  * @pm_lats: pointer to a omap_device_pm_latency array for this device
  * @pm_lats_cnt: ARRAY_SIZE() of @pm_lats
  * @is_early_device: should the device be registered as an early device or not
+ * @iommu: private iommu data to be placed in dev_archdata
  *
  * Convenience function for building and registering an omap_device
  * subsystem record.  Subsystem records consist of multiple
@@ -438,11 +440,12 @@ struct omap_device *omap_device_build(const char *pdev_name, int pdev_id,
  * platform_device record.  Returns an ERR_PTR() on error, or passes
  * along the return value of omap_device_register().
  */
-struct omap_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
+struct omap_device *omap_device_build_ss_ext(const char *pdev_name, int pdev_id,
 					 struct omap_hwmod **ohs, int oh_cnt,
 					 void *pdata, int pdata_len,
 					 struct omap_device_pm_latency *pm_lats,
-					 int pm_lats_cnt, int is_early_device)
+					 int pm_lats_cnt, int is_early_device,
+					 void *iommu)
 {
 	int ret = -ENOMEM;
 	struct omap_device *od;
@@ -500,6 +503,8 @@ struct omap_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
 	od->pm_lats = pm_lats;
 	od->pm_lats_cnt = pm_lats_cnt;
 
+	od->pdev.dev.archdata.iommu = iommu;
+
 	if (is_early_device)
 		ret = omap_early_device_register(od);
 	else
@@ -530,6 +535,34 @@ odbs_exit1:
 }
 
 /**
+ * omap_device_build_ss - build and register an omap_device with multiple hwmods
+ * @pdev_name: name of the platform_device driver to use
+ * @pdev_id: this platform_device's connection ID
+ * @oh: ptr to the single omap_hwmod that backs this omap_device
+ * @pdata: platform_data ptr to associate with the platform_device
+ * @pdata_len: amount of memory pointed to by @pdata
+ * @pm_lats: pointer to a omap_device_pm_latency array for this device
+ * @pm_lats_cnt: ARRAY_SIZE() of @pm_lats
+ * @is_early_device: should the device be registered as an early device or not
+ *
+ * Convenience function for building and registering an omap_device
+ * subsystem record.  Subsystem records consist of multiple
+ * omap_hwmods.  This function in turn builds and registers a
+ * platform_device record.  Returns an ERR_PTR() on error, or passes
+ * along the return value of omap_device_register().
+ */
+struct omap_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
+					 struct omap_hwmod **ohs, int oh_cnt,
+					 void *pdata, int pdata_len,
+					 struct omap_device_pm_latency *pm_lats,
+					 int pm_lats_cnt, int is_early_device)
+{
+	return omap_device_build_ss_ext(pdev_name, pdev_id, ohs, oh_cnt,
+			pdata, pdata_len, pm_lats, pm_lats_cnt,
+			is_early_device, NULL);
+}
+
+/**
  * omap_early_device_register - register an omap_device as an early platform
  * device.
  * @od: struct omap_device * to register
-- 
1.7.4.1

[RFC 2/5] ARM: OMAP: omap_device: add a method to set iommu private archdata

[Ohad Ben-Cohen]

Make it possible to set an iommu private archdata before a newly-created
omap device is registered.

Binding iommu client devices with their respective iommu data this way
is needed so the generic IOMMU API can later be used without employing
any omap-specific IOMMU plumbing.

This patch just crudely adds an omap_device_build_ss_ext() method which
accepts an iommu private data, but we may actually want to do something
more generic here: e.g., split the omap_device_build API to alloc+add
methods, so users can just manipulate the device as needed before it is
registered (very much like we can do with plain devices).

Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
---
This is obviously not yet based on Benoit's recent changes; I'll do so after
we'll settle on the approach we want to take here.

 arch/arm/plat-omap/include/plat/omap_device.h |    6 ++++
 arch/arm/plat-omap/omap_device.c              |   39 +++++++++++++++++++++++--
 2 files changed, 42 insertions(+), 3 deletions(-)

diff --git a/arch/arm/plat-omap/include/plat/omap_device.h b/arch/arm/plat-omap/include/plat/omap_device.h
index ee405b36..a3f672c 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -102,6 +102,12 @@ struct omap_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
 					 void *pdata, int pdata_len,
 					 struct omap_device_pm_latency *pm_lats,
 					 int pm_lats_cnt, int is_early_device);
+struct omap_device *omap_device_build_ss_ext(const char *pdev_name, int pdev_id,
+					 struct omap_hwmod **ohs, int oh_cnt,
+					 void *pdata, int pdata_len,
+					 struct omap_device_pm_latency *pm_lats,
+					 int pm_lats_cnt, int is_early_device,
+					 void *iommu);
 
 int omap_device_register(struct omap_device *od);
 int omap_early_device_register(struct omap_device *od);
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index 02609ee..38bc753 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -422,7 +422,8 @@ struct omap_device *omap_device_build(const char *pdev_name, int pdev_id,
 }
 
 /**
- * omap_device_build_ss - build and register an omap_device with multiple hwmods
+ * omap_device_build_ss_ext - build and register an omap_device with multiple
+ *				hwmods and an optional private iommu data
  * @pdev_name: name of the platform_device driver to use
  * @pdev_id: this platform_device's connection ID
  * @oh: ptr to the single omap_hwmod that backs this omap_device
@@ -431,6 +432,7 @@ struct omap_device *omap_device_build(const char *pdev_name, int pdev_id,
  * @pm_lats: pointer to a omap_device_pm_latency array for this device
  * @pm_lats_cnt: ARRAY_SIZE() of @pm_lats
  * @is_early_device: should the device be registered as an early device or not
+ * @iommu: private iommu data to be placed in dev_archdata
  *
  * Convenience function for building and registering an omap_device
  * subsystem record.  Subsystem records consist of multiple
@@ -438,11 +440,12 @@ struct omap_device *omap_device_build(const char *pdev_name, int pdev_id,
  * platform_device record.  Returns an ERR_PTR() on error, or passes
  * along the return value of omap_device_register().
  */
-struct omap_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
+struct omap_device *omap_device_build_ss_ext(const char *pdev_name, int pdev_id,
 					 struct omap_hwmod **ohs, int oh_cnt,
 					 void *pdata, int pdata_len,
 					 struct omap_device_pm_latency *pm_lats,
-					 int pm_lats_cnt, int is_early_device)
+					 int pm_lats_cnt, int is_early_device,
+					 void *iommu)
 {
 	int ret = -ENOMEM;
 	struct omap_device *od;
@@ -500,6 +503,8 @@ struct omap_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
 	od->pm_lats = pm_lats;
 	od->pm_lats_cnt = pm_lats_cnt;
 
+	od->pdev.dev.archdata.iommu = iommu;
+
 	if (is_early_device)
 		ret = omap_early_device_register(od);
 	else
@@ -530,6 +535,34 @@ odbs_exit1:
 }
 
 /**
+ * omap_device_build_ss - build and register an omap_device with multiple hwmods
+ * @pdev_name: name of the platform_device driver to use
+ * @pdev_id: this platform_device's connection ID
+ * @oh: ptr to the single omap_hwmod that backs this omap_device
+ * @pdata: platform_data ptr to associate with the platform_device
+ * @pdata_len: amount of memory pointed to by @pdata
+ * @pm_lats: pointer to a omap_device_pm_latency array for this device
+ * @pm_lats_cnt: ARRAY_SIZE() of @pm_lats
+ * @is_early_device: should the device be registered as an early device or not
+ *
+ * Convenience function for building and registering an omap_device
+ * subsystem record.  Subsystem records consist of multiple
+ * omap_hwmods.  This function in turn builds and registers a
+ * platform_device record.  Returns an ERR_PTR() on error, or passes
+ * along the return value of omap_device_register().
+ */
+struct omap_device *omap_device_build_ss(const char *pdev_name, int pdev_id,
+					 struct omap_hwmod **ohs, int oh_cnt,
+					 void *pdata, int pdata_len,
+					 struct omap_device_pm_latency *pm_lats,
+					 int pm_lats_cnt, int is_early_device)
+{
+	return omap_device_build_ss_ext(pdev_name, pdev_id, ohs, oh_cnt,
+			pdata, pdata_len, pm_lats, pm_lats_cnt,
+			is_early_device, NULL);
+}
+
+/**
  * omap_early_device_register - register an omap_device as an early platform
  * device.
  * @od: struct omap_device * to register
-- 
1.7.4.1

Re: [RFC 2/5] ARM: OMAP: omap_device: add a method to set iommu private archdata

[Kevin Hilman]

Hi Ohad,

Ohad Ben-Cohen <ohad@wizery.com> writes:

> Make it possible to set an iommu private archdata before a newly-created
> omap device is registered.
>
> Binding iommu client devices with their respective iommu data this way
> is needed so the generic IOMMU API can later be used without employing
> any omap-specific IOMMU plumbing.
>
> This patch just crudely adds an omap_device_build_ss_ext() method which
> accepts an iommu private data, but we may actually want to do something
> more generic here: e.g., split the omap_device_build API to alloc+add
> methods, so users can just manipulate the device as needed before it is
> registered (very much like we can do with plain devices).

Yes indeed.  

Benoit did just this in preparation for DT. 

       http://marc.info/?l=linux-omap&m=131672480111927&w=2

Will that meet your needs?

Kevin

[RFC 2/5] ARM: OMAP: omap_device: add a method to set iommu private archdata

[Kevin Hilman]

Hi Ohad,

Ohad Ben-Cohen <ohad@wizery.com> writes:

> Make it possible to set an iommu private archdata before a newly-created
> omap device is registered.
>
> Binding iommu client devices with their respective iommu data this way
> is needed so the generic IOMMU API can later be used without employing
> any omap-specific IOMMU plumbing.
>
> This patch just crudely adds an omap_device_build_ss_ext() method which
> accepts an iommu private data, but we may actually want to do something
> more generic here: e.g., split the omap_device_build API to alloc+add
> methods, so users can just manipulate the device as needed before it is
> registered (very much like we can do with plain devices).

Yes indeed.  

Benoit did just this in preparation for DT. 

       http://marc.info/?l=linux-omap&m=131672480111927&w=2

Will that meet your needs?

Kevin

Re: [RFC 2/5] ARM: OMAP: omap_device: add a method to set iommu private archdata

[Kevin Hilman]

Hi Ohad,

Ohad Ben-Cohen <ohad@wizery.com> writes:

> Make it possible to set an iommu private archdata before a newly-created
> omap device is registered.
>
> Binding iommu client devices with their respective iommu data this way
> is needed so the generic IOMMU API can later be used without employing
> any omap-specific IOMMU plumbing.
>
> This patch just crudely adds an omap_device_build_ss_ext() method which
> accepts an iommu private data, but we may actually want to do something
> more generic here: e.g., split the omap_device_build API to alloc+add
> methods, so users can just manipulate the device as needed before it is
> registered (very much like we can do with plain devices).

Yes indeed.  

Benoit did just this in preparation for DT. 

       http://marc.info/?l=linux-omap&m=131672480111927&w=2

Will that meet your needs?

Kevin

Re: [RFC 2/5] ARM: OMAP: omap_device: add a method to set iommu private archdata

[Ohad Ben-Cohen]

Hi Kevin,

On Tue, Sep 27, 2011 at 1:53 AM, Kevin Hilman <khilman@ti.com> wrote:
> Benoit did just this in preparation for DT.
>
>       http://marc.info/?l=linux-omap&m=131672480111927&w=2
>
> Will that meet your needs?

It's almost there, but not entirely.

Benoit's alloc/delete functions focus on the omap_device part, leaving
the handling of the platform device (allocation and pdata setting) to
omap_device_build_ss(), which at the same time registers the pdev.

I'd need to split omap_device_build_ss() into two: an alloc() part
which does everything but registering the pdev, and a register() part.
Users will first call alloc(), manually set archdata members, and then
call the register() part.

Something like this (compile-tested only, based on Benoit's
for_3.2/4_omap4_dt_early_devices branch):

diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index 0ae9e7f..9b8008c 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -671,7 +671,7 @@ struct platform_device *omap_device_build(const
char *pdev_name, int pdev_id,
 }

 /**
- * omap_device_build_ss - build and register an omap_device with
multiple hwmods
+ * omap_device_alloc_ss - build an omap_device with multiple hwmods
  * @pdev_name: name of the platform_device driver to use
  * @pdev_id: this platform_device's connection ID
  * @oh: ptr to the single omap_hwmod that backs this omap_device
@@ -679,19 +679,19 @@ struct platform_device *omap_device_build(const
char *pdev_name, int pdev_id,
  * @pdata_len: amount of memory pointed to by @pdata
  * @pm_lats: pointer to a omap_device_pm_latency array for this device
  * @pm_lats_cnt: ARRAY_SIZE() of @pm_lats
- * @is_early_device: should the device be registered as an early device or not
  *
- * Convenience function for building and registering an omap_device
+ * Convenience function for building (only) an omap_device
  * subsystem record.  Subsystem records consist of multiple
- * omap_hwmods.  This function in turn builds and registers a
- * platform_device record.  Returns an ERR_PTR() on error, or passes
- * along the return value of omap_device_register().
+ * omap_hwmods.  This function in turn builds (but doesn't register) a
+ * platform_device record, so callers can manipulate it (typically by
+ * setting one or more archdata members) before it's registered.
+ * Returns an ERR_PTR() on error, or the allocated pdev on success.
  */
-struct platform_device *omap_device_build_ss(const char *pdev_name,
int pdev_id,
+struct platform_device *omap_device_alloc_ss(const char *pdev_name,
int pdev_id,
 					 struct omap_hwmod **ohs, int oh_cnt,
 					 void *pdata, int pdata_len,
 					 struct omap_device_pm_latency *pm_lats,
-					 int pm_lats_cnt, int is_early_device)
+					 int pm_lats_cnt)
 {
 	int ret = -ENOMEM;
 	struct platform_device *pdev;
@@ -723,13 +723,6 @@ struct platform_device
*omap_device_build_ss(const char *pdev_name, int pdev_id,
 	if (ret)
 		goto odbs_exit2;

-	if (is_early_device)
-		ret = omap_early_device_register(pdev);
-	else
-		ret = omap_device_register(pdev);
-	if (ret)
-		goto odbs_exit2;
-
 	return pdev;

 odbs_exit2:
@@ -744,6 +737,93 @@ odbs_exit:
 }

 /**
+ * omap_device_delete_ss - free an omap_device-based platform device
+ * @pdev: platform_device that represents this omap_device
+ *
+ * Convenience function for freeing a platform_device record, which
+ * is based on an omap_device subsystem record.
+ *
+ * Use this function only if @pdev was created using omap_device_alloc_ss(),
+ * most commonly because a subsequent call to omap_device_register_ss() failed.
+ */
+void omap_device_delete_ss(struct platform_device *pdev)
+{
+	struct omap_device *od = to_omap_device(pdev);
+
+	omap_device_delete(od);
+	platform_device_put(pdev);
+}
+
+/**
+ * omap_device_register_ss - register an omap_device-based platform device
+ * @pdev: platform_device that represents this omap_device
+ * @is_early_device: should the device be registered as an early device or not
+ *
+ * Convenience function for registering a platform_device record, which
+ * is based on an omap_device subsystem record, which was created using
+ * omap_device_alloc_ss().
+ *
+ * Returns 0 on success, or an appropriate error value otherwise (essentially
+ * by returning the value of platform_device_register())
+ */
+int omap_device_register_ss(struct platform_device *pdev, int is_early_device)
+{
+	int ret;
+
+	if (is_early_device)
+		ret = omap_early_device_register(pdev);
+	else
+		ret = omap_device_register(pdev);
+
+	return ret;
+}
+
+/**
+ * omap_device_build_ss - build and register an omap_device with
multiple hwmods
+ * @pdev_name: name of the platform_device driver to use
+ * @pdev_id: this platform_device's connection ID
+ * @oh: ptr to the single omap_hwmod that backs this omap_device
+ * @pdata: platform_data ptr to associate with the platform_device
+ * @pdata_len: amount of memory pointed to by @pdata
+ * @pm_lats: pointer to a omap_device_pm_latency array for this device
+ * @pm_lats_cnt: ARRAY_SIZE() of @pm_lats
+ * @is_early_device: should the device be registered as an early device or not
+ *
+ * Convenience function for building and registering an omap_device
+ * subsystem record.  Subsystem records consist of multiple
+ * omap_hwmods.  This function in turn builds and registers a
+ * platform_device record.  Returns an ERR_PTR() on error, or passes
+ * along the built pdev on success.
+ */
+struct platform_device *omap_device_build_ss(const char *pdev_name,
int pdev_id,
+					 struct omap_hwmod **ohs, int oh_cnt,
+					 void *pdata, int pdata_len,
+					 struct omap_device_pm_latency *pm_lats,
+					 int pm_lats_cnt, int is_early_device)
+{
+	struct platform_device *pdev;
+	int ret;
+
+	pdev = omap_device_alloc_ss(pdev_name, pdev_id, ohs, oh_cnt, pdata,
+			pdata_len, pm_lats, pm_lats_cnt);
+
+	if (IS_ERR(pdev))
+		goto out;
+
+	ret = omap_device_register_ss(pdev, is_early_device);
+	if (ret) {
+		pdev = ERR_PTR(ret);
+		goto delete_od;
+	}
+
+	return pdev;
+delete_od:
+	omap_device_delete_ss(pdev);
+out:
+	return pdev;
+}
+
+/**
  * omap_early_device_register - register an omap_device as an early platform
  * device.
  * @od: struct omap_device * to register


That's the idea; please tell me how you'd like to see this go forward
(there are at least several personal-taste issues here, e.g., naming:
now we have two sets of alloc/delete functions which have different
semantics) and which branch would you like me to base this work off of
(not sure if Benoit's patches already went into your
for_3.2/omap_device branch) and I'll respin this patch properly.

Thanks a lot!
Ohad.

[RFC 2/5] ARM: OMAP: omap_device: add a method to set iommu private archdata

[Ohad Ben-Cohen]

Hi Kevin,

On Tue, Sep 27, 2011 at 1:53 AM, Kevin Hilman <khilman@ti.com> wrote:
> Benoit did just this in preparation for DT.
>
> ? ? ? http://marc.info/?l=linux-omap&m=131672480111927&w=2
>
> Will that meet your needs?

It's almost there, but not entirely.

Benoit's alloc/delete functions focus on the omap_device part, leaving
the handling of the platform device (allocation and pdata setting) to
omap_device_build_ss(), which at the same time registers the pdev.

I'd need to split omap_device_build_ss() into two: an alloc() part
which does everything but registering the pdev, and a register() part.
Users will first call alloc(), manually set archdata members, and then
call the register() part.

Something like this (compile-tested only, based on Benoit's
for_3.2/4_omap4_dt_early_devices branch):

diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index 0ae9e7f..9b8008c 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -671,7 +671,7 @@ struct platform_device *omap_device_build(const
char *pdev_name, int pdev_id,
 }

 /**
- * omap_device_build_ss - build and register an omap_device with
multiple hwmods
+ * omap_device_alloc_ss - build an omap_device with multiple hwmods
  * @pdev_name: name of the platform_device driver to use
  * @pdev_id: this platform_device's connection ID
  * @oh: ptr to the single omap_hwmod that backs this omap_device
@@ -679,19 +679,19 @@ struct platform_device *omap_device_build(const
char *pdev_name, int pdev_id,
  * @pdata_len: amount of memory pointed to by @pdata
  * @pm_lats: pointer to a omap_device_pm_latency array for this device
  * @pm_lats_cnt: ARRAY_SIZE() of @pm_lats
- * @is_early_device: should the device be registered as an early device or not
  *
- * Convenience function for building and registering an omap_device
+ * Convenience function for building (only) an omap_device
  * subsystem record.  Subsystem records consist of multiple
- * omap_hwmods.  This function in turn builds and registers a
- * platform_device record.  Returns an ERR_PTR() on error, or passes
- * along the return value of omap_device_register().
+ * omap_hwmods.  This function in turn builds (but doesn't register) a
+ * platform_device record, so callers can manipulate it (typically by
+ * setting one or more archdata members) before it's registered.
+ * Returns an ERR_PTR() on error, or the allocated pdev on success.
  */
-struct platform_device *omap_device_build_ss(const char *pdev_name,
int pdev_id,
+struct platform_device *omap_device_alloc_ss(const char *pdev_name,
int pdev_id,
 					 struct omap_hwmod **ohs, int oh_cnt,
 					 void *pdata, int pdata_len,
 					 struct omap_device_pm_latency *pm_lats,
-					 int pm_lats_cnt, int is_early_device)
+					 int pm_lats_cnt)
 {
 	int ret = -ENOMEM;
 	struct platform_device *pdev;
@@ -723,13 +723,6 @@ struct platform_device
*omap_device_build_ss(const char *pdev_name, int pdev_id,
 	if (ret)
 		goto odbs_exit2;

-	if (is_early_device)
-		ret = omap_early_device_register(pdev);
-	else
-		ret = omap_device_register(pdev);
-	if (ret)
-		goto odbs_exit2;
-
 	return pdev;

 odbs_exit2:
@@ -744,6 +737,93 @@ odbs_exit:
 }

 /**
+ * omap_device_delete_ss - free an omap_device-based platform device
+ * @pdev: platform_device that represents this omap_device
+ *
+ * Convenience function for freeing a platform_device record, which
+ * is based on an omap_device subsystem record.
+ *
+ * Use this function only if @pdev was created using omap_device_alloc_ss(),
+ * most commonly because a subsequent call to omap_device_register_ss() failed.
+ */
+void omap_device_delete_ss(struct platform_device *pdev)
+{
+	struct omap_device *od = to_omap_device(pdev);
+
+	omap_device_delete(od);
+	platform_device_put(pdev);
+}
+
+/**
+ * omap_device_register_ss - register an omap_device-based platform device
+ * @pdev: platform_device that represents this omap_device
+ * @is_early_device: should the device be registered as an early device or not
+ *
+ * Convenience function for registering a platform_device record, which
+ * is based on an omap_device subsystem record, which was created using
+ * omap_device_alloc_ss().
+ *
+ * Returns 0 on success, or an appropriate error value otherwise (essentially
+ * by returning the value of platform_device_register())
+ */
+int omap_device_register_ss(struct platform_device *pdev, int is_early_device)
+{
+	int ret;
+
+	if (is_early_device)
+		ret = omap_early_device_register(pdev);
+	else
+		ret = omap_device_register(pdev);
+
+	return ret;
+}
+
+/**
+ * omap_device_build_ss - build and register an omap_device with
multiple hwmods
+ * @pdev_name: name of the platform_device driver to use
+ * @pdev_id: this platform_device's connection ID
+ * @oh: ptr to the single omap_hwmod that backs this omap_device
+ * @pdata: platform_data ptr to associate with the platform_device
+ * @pdata_len: amount of memory pointed to by @pdata
+ * @pm_lats: pointer to a omap_device_pm_latency array for this device
+ * @pm_lats_cnt: ARRAY_SIZE() of @pm_lats
+ * @is_early_device: should the device be registered as an early device or not
+ *
+ * Convenience function for building and registering an omap_device
+ * subsystem record.  Subsystem records consist of multiple
+ * omap_hwmods.  This function in turn builds and registers a
+ * platform_device record.  Returns an ERR_PTR() on error, or passes
+ * along the built pdev on success.
+ */
+struct platform_device *omap_device_build_ss(const char *pdev_name,
int pdev_id,
+					 struct omap_hwmod **ohs, int oh_cnt,
+					 void *pdata, int pdata_len,
+					 struct omap_device_pm_latency *pm_lats,
+					 int pm_lats_cnt, int is_early_device)
+{
+	struct platform_device *pdev;
+	int ret;
+
+	pdev = omap_device_alloc_ss(pdev_name, pdev_id, ohs, oh_cnt, pdata,
+			pdata_len, pm_lats, pm_lats_cnt);
+
+	if (IS_ERR(pdev))
+		goto out;
+
+	ret = omap_device_register_ss(pdev, is_early_device);
+	if (ret) {
+		pdev = ERR_PTR(ret);
+		goto delete_od;
+	}
+
+	return pdev;
+delete_od:
+	omap_device_delete_ss(pdev);
+out:
+	return pdev;
+}
+
+/**
  * omap_early_device_register - register an omap_device as an early platform
  * device.
  * @od: struct omap_device * to register


That's the idea; please tell me how you'd like to see this go forward
(there are at least several personal-taste issues here, e.g., naming:
now we have two sets of alloc/delete functions which have different
semantics) and which branch would you like me to base this work off of
(not sure if Benoit's patches already went into your
for_3.2/omap_device branch) and I'll respin this patch properly.

Thanks a lot!
Ohad.

Re: [RFC 2/5] ARM: OMAP: omap_device: add a method to set iommu private archdata

[Ohad Ben-Cohen]

Hi Kevin,

On Tue, Sep 27, 2011 at 1:53 AM, Kevin Hilman <khilman@ti.com> wrote:
> Benoit did just this in preparation for DT.
>
>       http://marc.info/?l=linux-omap&m=131672480111927&w=2
>
> Will that meet your needs?

It's almost there, but not entirely.

Benoit's alloc/delete functions focus on the omap_device part, leaving
the handling of the platform device (allocation and pdata setting) to
omap_device_build_ss(), which at the same time registers the pdev.

I'd need to split omap_device_build_ss() into two: an alloc() part
which does everything but registering the pdev, and a register() part.
Users will first call alloc(), manually set archdata members, and then
call the register() part.

Something like this (compile-tested only, based on Benoit's
for_3.2/4_omap4_dt_early_devices branch):

diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index 0ae9e7f..9b8008c 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -671,7 +671,7 @@ struct platform_device *omap_device_build(const
char *pdev_name, int pdev_id,
 }

 /**
- * omap_device_build_ss - build and register an omap_device with
multiple hwmods
+ * omap_device_alloc_ss - build an omap_device with multiple hwmods
  * @pdev_name: name of the platform_device driver to use
  * @pdev_id: this platform_device's connection ID
  * @oh: ptr to the single omap_hwmod that backs this omap_device
@@ -679,19 +679,19 @@ struct platform_device *omap_device_build(const
char *pdev_name, int pdev_id,
  * @pdata_len: amount of memory pointed to by @pdata
  * @pm_lats: pointer to a omap_device_pm_latency array for this device
  * @pm_lats_cnt: ARRAY_SIZE() of @pm_lats
- * @is_early_device: should the device be registered as an early device or not
  *
- * Convenience function for building and registering an omap_device
+ * Convenience function for building (only) an omap_device
  * subsystem record.  Subsystem records consist of multiple
- * omap_hwmods.  This function in turn builds and registers a
- * platform_device record.  Returns an ERR_PTR() on error, or passes
- * along the return value of omap_device_register().
+ * omap_hwmods.  This function in turn builds (but doesn't register) a
+ * platform_device record, so callers can manipulate it (typically by
+ * setting one or more archdata members) before it's registered.
+ * Returns an ERR_PTR() on error, or the allocated pdev on success.
  */
-struct platform_device *omap_device_build_ss(const char *pdev_name,
int pdev_id,
+struct platform_device *omap_device_alloc_ss(const char *pdev_name,
int pdev_id,
 					 struct omap_hwmod **ohs, int oh_cnt,
 					 void *pdata, int pdata_len,
 					 struct omap_device_pm_latency *pm_lats,
-					 int pm_lats_cnt, int is_early_device)
+					 int pm_lats_cnt)
 {
 	int ret = -ENOMEM;
 	struct platform_device *pdev;
@@ -723,13 +723,6 @@ struct platform_device
*omap_device_build_ss(const char *pdev_name, int pdev_id,
 	if (ret)
 		goto odbs_exit2;

-	if (is_early_device)
-		ret = omap_early_device_register(pdev);
-	else
-		ret = omap_device_register(pdev);
-	if (ret)
-		goto odbs_exit2;
-
 	return pdev;

 odbs_exit2:
@@ -744,6 +737,93 @@ odbs_exit:
 }

 /**
+ * omap_device_delete_ss - free an omap_device-based platform device
+ * @pdev: platform_device that represents this omap_device
+ *
+ * Convenience function for freeing a platform_device record, which
+ * is based on an omap_device subsystem record.
+ *
+ * Use this function only if @pdev was created using omap_device_alloc_ss(),
+ * most commonly because a subsequent call to omap_device_register_ss() failed.
+ */
+void omap_device_delete_ss(struct platform_device *pdev)
+{
+	struct omap_device *od = to_omap_device(pdev);
+
+	omap_device_delete(od);
+	platform_device_put(pdev);
+}
+
+/**
+ * omap_device_register_ss - register an omap_device-based platform device
+ * @pdev: platform_device that represents this omap_device
+ * @is_early_device: should the device be registered as an early device or not
+ *
+ * Convenience function for registering a platform_device record, which
+ * is based on an omap_device subsystem record, which was created using
+ * omap_device_alloc_ss().
+ *
+ * Returns 0 on success, or an appropriate error value otherwise (essentially
+ * by returning the value of platform_device_register())
+ */
+int omap_device_register_ss(struct platform_device *pdev, int is_early_device)
+{
+	int ret;
+
+	if (is_early_device)
+		ret = omap_early_device_register(pdev);
+	else
+		ret = omap_device_register(pdev);
+
+	return ret;
+}
+
+/**
+ * omap_device_build_ss - build and register an omap_device with
multiple hwmods
+ * @pdev_name: name of the platform_device driver to use
+ * @pdev_id: this platform_device's connection ID
+ * @oh: ptr to the single omap_hwmod that backs this omap_device
+ * @pdata: platform_data ptr to associate with the platform_device
+ * @pdata_len: amount of memory pointed to by @pdata
+ * @pm_lats: pointer to a omap_device_pm_latency array for this device
+ * @pm_lats_cnt: ARRAY_SIZE() of @pm_lats
+ * @is_early_device: should the device be registered as an early device or not
+ *
+ * Convenience function for building and registering an omap_device
+ * subsystem record.  Subsystem records consist of multiple
+ * omap_hwmods.  This function in turn builds and registers a
+ * platform_device record.  Returns an ERR_PTR() on error, or passes
+ * along the built pdev on success.
+ */
+struct platform_device *omap_device_build_ss(const char *pdev_name,
int pdev_id,
+					 struct omap_hwmod **ohs, int oh_cnt,
+					 void *pdata, int pdata_len,
+					 struct omap_device_pm_latency *pm_lats,
+					 int pm_lats_cnt, int is_early_device)
+{
+	struct platform_device *pdev;
+	int ret;
+
+	pdev = omap_device_alloc_ss(pdev_name, pdev_id, ohs, oh_cnt, pdata,
+			pdata_len, pm_lats, pm_lats_cnt);
+
+	if (IS_ERR(pdev))
+		goto out;
+
+	ret = omap_device_register_ss(pdev, is_early_device);
+	if (ret) {
+		pdev = ERR_PTR(ret);
+		goto delete_od;
+	}
+
+	return pdev;
+delete_od:
+	omap_device_delete_ss(pdev);
+out:
+	return pdev;
+}
+
+/**
  * omap_early_device_register - register an omap_device as an early platform
  * device.
  * @od: struct omap_device * to register


That's the idea; please tell me how you'd like to see this go forward
(there are at least several personal-taste issues here, e.g., naming:
now we have two sets of alloc/delete functions which have different
semantics) and which branch would you like me to base this work off of
(not sure if Benoit's patches already went into your
for_3.2/omap_device branch) and I'll respin this patch properly.

Thanks a lot!
Ohad.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 2/5] ARM: OMAP: omap_device: add a method to set iommu private archdata

[Kevin Hilman]

Ohad Ben-Cohen <ohad@wizery.com> writes:

> Hi Kevin,
>
> On Tue, Sep 27, 2011 at 1:53 AM, Kevin Hilman <khilman@ti.com> wrote:
>> Benoit did just this in preparation for DT.
>>
>>       http://marc.info/?l=linux-omap&m=131672480111927&w=2
>>
>> Will that meet your needs?
>
> It's almost there, but not entirely.
>
> Benoit's alloc/delete functions focus on the omap_device part, leaving
> the handling of the platform device (allocation and pdata setting) to
> omap_device_build_ss(), which at the same time registers the pdev.
>
> I'd need to split omap_device_build_ss() into two: an alloc() part
> which does everything but registering the pdev, and a register() part.
> Users will first call alloc(), manually set archdata members, and then
> call the register() part.
>
> Something like this (compile-tested only, based on Benoit's
> for_3.2/4_omap4_dt_early_devices branch):

[...]

> That's the idea; please tell me how you'd like to see this go forward
> (there are at least several personal-taste issues here, e.g., naming:
> now we have two sets of alloc/delete functions which have different
> semantics) 

The approach is OK with me, but I'm a bit torn about whether or not to
merge this since the need for this should go away when converting to DT.
Is anyone working on IOMMU DT description?

I guess if I do merge this, we can also clean this up significantly
after all devices are converted to DT.

> and which branch would you like me to base this work off of
> (not sure if Benoit's patches already went into your
> for_3.2/omap_device branch) and I'll respin this patch properly.

Unless it has other dependencies on Benoit's further DT patches, you can
base this on my for_3.2/omap_device-2 branch which includes Benoit's
alloc changes.

Kevin

[RFC 2/5] ARM: OMAP: omap_device: add a method to set iommu private archdata

[Kevin Hilman]

Ohad Ben-Cohen <ohad@wizery.com> writes:

> Hi Kevin,
>
> On Tue, Sep 27, 2011 at 1:53 AM, Kevin Hilman <khilman@ti.com> wrote:
>> Benoit did just this in preparation for DT.
>>
>> ? ? ? http://marc.info/?l=linux-omap&m=131672480111927&w=2
>>
>> Will that meet your needs?
>
> It's almost there, but not entirely.
>
> Benoit's alloc/delete functions focus on the omap_device part, leaving
> the handling of the platform device (allocation and pdata setting) to
> omap_device_build_ss(), which at the same time registers the pdev.
>
> I'd need to split omap_device_build_ss() into two: an alloc() part
> which does everything but registering the pdev, and a register() part.
> Users will first call alloc(), manually set archdata members, and then
> call the register() part.
>
> Something like this (compile-tested only, based on Benoit's
> for_3.2/4_omap4_dt_early_devices branch):

[...]

> That's the idea; please tell me how you'd like to see this go forward
> (there are at least several personal-taste issues here, e.g., naming:
> now we have two sets of alloc/delete functions which have different
> semantics) 

The approach is OK with me, but I'm a bit torn about whether or not to
merge this since the need for this should go away when converting to DT.
Is anyone working on IOMMU DT description?

I guess if I do merge this, we can also clean this up significantly
after all devices are converted to DT.

> and which branch would you like me to base this work off of
> (not sure if Benoit's patches already went into your
> for_3.2/omap_device branch) and I'll respin this patch properly.

Unless it has other dependencies on Benoit's further DT patches, you can
base this on my for_3.2/omap_device-2 branch which includes Benoit's
alloc changes.

Kevin

Re: [RFC 2/5] ARM: OMAP: omap_device: add a method to set iommu private archdata

[Ohad Ben-Cohen]

On Tue, Oct 4, 2011 at 8:15 PM, Kevin Hilman <khilman@ti.com> wrote:
> The approach is OK with me, but I'm a bit torn about whether or not to
> merge this since the need for this should go away when converting to DT.

I guess it will still take some time until our boards are fully
functional with DT, so I think we should regard this as an interim
solution. Without this patch, a huge deal of code consolidation and
generalization is gated (namely - generic iommu and dma api, and
everything that depends on it, e.g. rpmsg/remoteproc).

> Is anyone working on IOMMU DT description?

Unless Benoit is, I'll happily pick this up.

> I guess if I do merge this, we can also clean this up significantly
> after all devices are converted to DT.

Sure.

> Unless it has other dependencies on Benoit's further DT patches, you can
> base this on my for_3.2/omap_device-2 branch which includes Benoit's
> alloc changes.

Ok, thanks a lot !
Ohad.

[RFC 2/5] ARM: OMAP: omap_device: add a method to set iommu private archdata

[Ohad Ben-Cohen]

On Tue, Oct 4, 2011 at 8:15 PM, Kevin Hilman <khilman@ti.com> wrote:
> The approach is OK with me, but I'm a bit torn about whether or not to
> merge this since the need for this should go away when converting to DT.

I guess it will still take some time until our boards are fully
functional with DT, so I think we should regard this as an interim
solution. Without this patch, a huge deal of code consolidation and
generalization is gated (namely - generic iommu and dma api, and
everything that depends on it, e.g. rpmsg/remoteproc).

> Is anyone working on IOMMU DT description?

Unless Benoit is, I'll happily pick this up.

> I guess if I do merge this, we can also clean this up significantly
> after all devices are converted to DT.

Sure.

> Unless it has other dependencies on Benoit's further DT patches, you can
> base this on my for_3.2/omap_device-2 branch which includes Benoit's
> alloc changes.

Ok, thanks a lot !
Ohad.

Re: [RFC 2/5] ARM: OMAP: omap_device: add a method to set iommu private archdata

[Kevin Hilman]

Ohad Ben-Cohen <ohad@wizery.com> writes:

> On Tue, Oct 4, 2011 at 8:15 PM, Kevin Hilman <khilman@ti.com> wrote:
>> The approach is OK with me, but I'm a bit torn about whether or not to
>> merge this since the need for this should go away when converting to DT.
>
> I guess it will still take some time until our boards are fully
> functional with DT, so I think we should regard this as an interim
> solution. Without this patch, a huge deal of code consolidation and
> generalization is gated (namely - generic iommu and dma api, and
> everything that depends on it, e.g. rpmsg/remoteproc).
>
>> Is anyone working on IOMMU DT description?
>
> Unless Benoit is, I'll happily pick this up.

tag.  you're it.

>> I guess if I do merge this, we can also clean this up significantly
>> after all devices are converted to DT.
>
> Sure.

OK, as long as I have some confidence that this is going in the right
direction (and having you on the job is a good sign!)  I'm willing to
merge something like this as an interim solution.

Kevin

>> Unless it has other dependencies on Benoit's further DT patches, you can
>> base this on my for_3.2/omap_device-2 branch which includes Benoit's
>> alloc changes.
>
> Ok, thanks a lot !
> Ohad.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

[RFC 2/5] ARM: OMAP: omap_device: add a method to set iommu private archdata

[Kevin Hilman]

Ohad Ben-Cohen <ohad@wizery.com> writes:

> On Tue, Oct 4, 2011 at 8:15 PM, Kevin Hilman <khilman@ti.com> wrote:
>> The approach is OK with me, but I'm a bit torn about whether or not to
>> merge this since the need for this should go away when converting to DT.
>
> I guess it will still take some time until our boards are fully
> functional with DT, so I think we should regard this as an interim
> solution. Without this patch, a huge deal of code consolidation and
> generalization is gated (namely - generic iommu and dma api, and
> everything that depends on it, e.g. rpmsg/remoteproc).
>
>> Is anyone working on IOMMU DT description?
>
> Unless Benoit is, I'll happily pick this up.

tag.  you're it.

>> I guess if I do merge this, we can also clean this up significantly
>> after all devices are converted to DT.
>
> Sure.

OK, as long as I have some confidence that this is going in the right
direction (and having you on the job is a good sign!)  I'm willing to
merge something like this as an interim solution.

Kevin

>> Unless it has other dependencies on Benoit's further DT patches, you can
>> base this on my for_3.2/omap_device-2 branch which includes Benoit's
>> alloc changes.
>
> Ok, thanks a lot !
> Ohad.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC 2/5] ARM: OMAP: omap_device: add a method to set iommu private archdata

[Ohad Ben-Cohen]

On Tue, Oct 4, 2011 at 10:29 PM, Kevin Hilman <khilman@ti.com> wrote:
> tag.  you're it.

Consider it done :)

> OK, as long as I have some confidence that this is going in the right
> direction (and having you on the job is a good sign!)  I'm willing to
> merge something like this as an interim solution.

Thanks a lot!
Ohad.

[RFC 2/5] ARM: OMAP: omap_device: add a method to set iommu private archdata

[Ohad Ben-Cohen]

On Tue, Oct 4, 2011 at 10:29 PM, Kevin Hilman <khilman@ti.com> wrote:
> tag. ?you're it.

Consider it done :)

> OK, as long as I have some confidence that this is going in the right
> direction (and having you on the job is a good sign!) ?I'm willing to
> merge something like this as an interim solution.

Thanks a lot!
Ohad.

Re: [RFC 2/5] ARM: OMAP: omap_device: add a method to set iommu private archdata

[Cousson, Benoit]

On 10/4/2011 9:54 PM, Ohad Ben-Cohen wrote:
> On Tue, Oct 4, 2011 at 8:15 PM, Kevin Hilman<khilman@ti.com>  wrote:
>> The approach is OK with me, but I'm a bit torn about whether or not to
>> merge this since the need for this should go away when converting to DT.
>
> I guess it will still take some time until our boards are fully
> functional with DT, so I think we should regard this as an interim
> solution. Without this patch, a huge deal of code consolidation and
> generalization is gated (namely - generic iommu and dma api, and
> everything that depends on it, e.g. rpmsg/remoteproc).
>
>> Is anyone working on IOMMU DT description?
>
> Unless Benoit is, I'll happily pick this up.

Cool, a volunteer... You're in.

Thanks,
Benoit

[RFC 2/5] ARM: OMAP: omap_device: add a method to set iommu private archdata

[Cousson, Benoit]

On 10/4/2011 9:54 PM, Ohad Ben-Cohen wrote:
> On Tue, Oct 4, 2011 at 8:15 PM, Kevin Hilman<khilman@ti.com>  wrote:
>> The approach is OK with me, but I'm a bit torn about whether or not to
>> merge this since the need for this should go away when converting to DT.
>
> I guess it will still take some time until our boards are fully
> functional with DT, so I think we should regard this as an interim
> solution. Without this patch, a huge deal of code consolidation and
> generalization is gated (namely - generic iommu and dma api, and
> everything that depends on it, e.g. rpmsg/remoteproc).
>
>> Is anyone working on IOMMU DT description?
>
> Unless Benoit is, I'll happily pick this up.

Cool, a volunteer... You're in.

Thanks,
Benoit

Re: [RFC 2/5] ARM: OMAP: omap_device: add a method to set iommu private archdata

[Cousson, Benoit]

On 10/4/2011 9:54 PM, Ohad Ben-Cohen wrote:
> On Tue, Oct 4, 2011 at 8:15 PM, Kevin Hilman<khilman@ti.com>  wrote:
>> The approach is OK with me, but I'm a bit torn about whether or not to
>> merge this since the need for this should go away when converting to DT.
>
> I guess it will still take some time until our boards are fully
> functional with DT, so I think we should regard this as an interim
> solution. Without this patch, a huge deal of code consolidation and
> generalization is gated (namely - generic iommu and dma api, and
> everything that depends on it, e.g. rpmsg/remoteproc).
>
>> Is anyone working on IOMMU DT description?
>
> Unless Benoit is, I'll happily pick this up.

Cool, a volunteer... You're in.

Thanks,
Benoit

[RFC 3/5] ARM: OMAP: iommu: declare a private iommu binding struct

[Ohad Ben-Cohen]

Declare an omap iommu private struct, which binds an iommu user
to its iommu device. This struct should be placed at the iommu user's
dev_archdata so generic IOMMU API can be used without having to
utilize omap-specific plumbing anymore.

While at it, provide an accessor method to ease the retrieval of the
omap_iommu handle from a user device.

Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Hiroshi DOYU <Hiroshi.DOYU@nokia.com>
---
 arch/arm/plat-omap/include/plat/iommu.h |   26 ++++++++++++++++++++++++++
 1 files changed, 26 insertions(+), 0 deletions(-)

diff --git a/arch/arm/plat-omap/include/plat/iommu.h b/arch/arm/plat-omap/include/plat/iommu.h
index a1d79ee..fa11ee2 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -111,6 +111,32 @@ struct iommu_platform_data {
 	u32 da_end;
 };
 
+/**
+ * struct iommu_arch_data - omap iommu private data
+ * @name: name of the iommu device
+ * @iommu_dev: handle of the iommu device
+ *
+ * This is an omap iommu private data object, which binds an iommu user
+ * to its iommu device. This object should be placed at the iommu user's
+ * dev_archdata so generic IOMMU API can be used without having to
+ * utilize omap-specific plumbing anymore.
+ */
+struct omap_iommu_arch_data {
+	const char *name;
+	struct omap_iommu *iommu_dev;
+};
+
+/**
+ * dev_to_omap_iommu() - retrieves an omap iommu object from a user device
+ * @dev: iommu client device
+ */
+static inline struct omap_iommu *dev_to_omap_iommu(struct device *dev)
+{
+	struct omap_iommu_arch_data *arch_data = dev->archdata.iommu;
+
+	return arch_data->iommu_dev;
+}
+
 /* IOMMU errors */
 #define OMAP_IOMMU_ERR_TLB_MISS		(1 << 0)
 #define OMAP_IOMMU_ERR_TRANS_FAULT	(1 << 1)
-- 
1.7.4.1

[RFC 3/5] ARM: OMAP: iommu: declare a private iommu binding struct

[Ohad Ben-Cohen]

Declare an omap iommu private struct, which binds an iommu user
to its iommu device. This struct should be placed at the iommu user's
dev_archdata so generic IOMMU API can be used without having to
utilize omap-specific plumbing anymore.

While at it, provide an accessor method to ease the retrieval of the
omap_iommu handle from a user device.

Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Hiroshi DOYU <Hiroshi.DOYU@nokia.com>
---
 arch/arm/plat-omap/include/plat/iommu.h |   26 ++++++++++++++++++++++++++
 1 files changed, 26 insertions(+), 0 deletions(-)

diff --git a/arch/arm/plat-omap/include/plat/iommu.h b/arch/arm/plat-omap/include/plat/iommu.h
index a1d79ee..fa11ee2 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -111,6 +111,32 @@ struct iommu_platform_data {
 	u32 da_end;
 };
 
+/**
+ * struct iommu_arch_data - omap iommu private data
+ * @name: name of the iommu device
+ * @iommu_dev: handle of the iommu device
+ *
+ * This is an omap iommu private data object, which binds an iommu user
+ * to its iommu device. This object should be placed at the iommu user's
+ * dev_archdata so generic IOMMU API can be used without having to
+ * utilize omap-specific plumbing anymore.
+ */
+struct omap_iommu_arch_data {
+	const char *name;
+	struct omap_iommu *iommu_dev;
+};
+
+/**
+ * dev_to_omap_iommu() - retrieves an omap iommu object from a user device
+ * @dev: iommu client device
+ */
+static inline struct omap_iommu *dev_to_omap_iommu(struct device *dev)
+{
+	struct omap_iommu_arch_data *arch_data = dev->archdata.iommu;
+
+	return arch_data->iommu_dev;
+}
+
 /* IOMMU errors */
 #define OMAP_IOMMU_ERR_TLB_MISS		(1 << 0)
 #define OMAP_IOMMU_ERR_TRANS_FAULT	(1 << 1)
-- 
1.7.4.1

Re: [RFC 3/5] ARM: OMAP: iommu: declare a private iommu binding struct

[Tony Lindgren]

* Ohad Ben-Cohen <ohad@wizery.com> [110925 03:27]:
> Declare an omap iommu private struct, which binds an iommu user
> to its iommu device. This struct should be placed at the iommu user's
> dev_archdata so generic IOMMU API can be used without having to
> utilize omap-specific plumbing anymore.
> 
> While at it, provide an accessor method to ease the retrieval of the
> omap_iommu handle from a user device.
> 
> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Hiroshi DOYU <Hiroshi.DOYU@nokia.com>

Acked-by: Tony Lindgren <tony@atomide.com>


> ---
>  arch/arm/plat-omap/include/plat/iommu.h |   26 ++++++++++++++++++++++++++
>  1 files changed, 26 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/plat-omap/include/plat/iommu.h b/arch/arm/plat-omap/include/plat/iommu.h
> index a1d79ee..fa11ee2 100644
> --- a/arch/arm/plat-omap/include/plat/iommu.h
> +++ b/arch/arm/plat-omap/include/plat/iommu.h
> @@ -111,6 +111,32 @@ struct iommu_platform_data {
>  	u32 da_end;
>  };
>  
> +/**
> + * struct iommu_arch_data - omap iommu private data
> + * @name: name of the iommu device
> + * @iommu_dev: handle of the iommu device
> + *
> + * This is an omap iommu private data object, which binds an iommu user
> + * to its iommu device. This object should be placed at the iommu user's
> + * dev_archdata so generic IOMMU API can be used without having to
> + * utilize omap-specific plumbing anymore.
> + */
> +struct omap_iommu_arch_data {
> +	const char *name;
> +	struct omap_iommu *iommu_dev;
> +};
> +
> +/**
> + * dev_to_omap_iommu() - retrieves an omap iommu object from a user device
> + * @dev: iommu client device
> + */
> +static inline struct omap_iommu *dev_to_omap_iommu(struct device *dev)
> +{
> +	struct omap_iommu_arch_data *arch_data = dev->archdata.iommu;
> +
> +	return arch_data->iommu_dev;
> +}
> +
>  /* IOMMU errors */
>  #define OMAP_IOMMU_ERR_TLB_MISS		(1 << 0)
>  #define OMAP_IOMMU_ERR_TRANS_FAULT	(1 << 1)
> -- 
> 1.7.4.1
> 

[RFC 3/5] ARM: OMAP: iommu: declare a private iommu binding struct

[Tony Lindgren]

* Ohad Ben-Cohen <ohad@wizery.com> [110925 03:27]:
> Declare an omap iommu private struct, which binds an iommu user
> to its iommu device. This struct should be placed at the iommu user's
> dev_archdata so generic IOMMU API can be used without having to
> utilize omap-specific plumbing anymore.
> 
> While at it, provide an accessor method to ease the retrieval of the
> omap_iommu handle from a user device.
> 
> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Hiroshi DOYU <Hiroshi.DOYU@nokia.com>

Acked-by: Tony Lindgren <tony@atomide.com>


> ---
>  arch/arm/plat-omap/include/plat/iommu.h |   26 ++++++++++++++++++++++++++
>  1 files changed, 26 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/plat-omap/include/plat/iommu.h b/arch/arm/plat-omap/include/plat/iommu.h
> index a1d79ee..fa11ee2 100644
> --- a/arch/arm/plat-omap/include/plat/iommu.h
> +++ b/arch/arm/plat-omap/include/plat/iommu.h
> @@ -111,6 +111,32 @@ struct iommu_platform_data {
>  	u32 da_end;
>  };
>  
> +/**
> + * struct iommu_arch_data - omap iommu private data
> + * @name: name of the iommu device
> + * @iommu_dev: handle of the iommu device
> + *
> + * This is an omap iommu private data object, which binds an iommu user
> + * to its iommu device. This object should be placed at the iommu user's
> + * dev_archdata so generic IOMMU API can be used without having to
> + * utilize omap-specific plumbing anymore.
> + */
> +struct omap_iommu_arch_data {
> +	const char *name;
> +	struct omap_iommu *iommu_dev;
> +};
> +
> +/**
> + * dev_to_omap_iommu() - retrieves an omap iommu object from a user device
> + * @dev: iommu client device
> + */
> +static inline struct omap_iommu *dev_to_omap_iommu(struct device *dev)
> +{
> +	struct omap_iommu_arch_data *arch_data = dev->archdata.iommu;
> +
> +	return arch_data->iommu_dev;
> +}
> +
>  /* IOMMU errors */
>  #define OMAP_IOMMU_ERR_TLB_MISS		(1 << 0)
>  #define OMAP_IOMMU_ERR_TRANS_FAULT	(1 << 1)
> -- 
> 1.7.4.1
> 

[RFC 4/5] ARM: OMAP3: bind omap3isp_device to its iommu device

[Ohad Ben-Cohen]

Bind OMAP3's isp device to the isp's dedicated iommu, by setting
the device's archdata iommu member.

This way omap3isp will be able to use the generic IOMMU API without
having to call any omap-specific binding method.

Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
 arch/arm/mach-omap2/devices.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 1077ad6..44122f7 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -28,6 +28,7 @@
 #include <plat/mcbsp.h>
 #include <mach/gpio.h>
 #include <plat/mmc.h>
+#include <plat/iommu.h>
 #include <plat/dma.h>
 #include <plat/omap_hwmod.h>
 #include <plat/omap_device.h>
@@ -207,9 +208,15 @@ static struct platform_device omap3isp_device = {
 	.resource	= omap3isp_resources,
 };
 
+static struct omap_iommu_arch_data omap3_isp_iommu = {
+	.name = "isp",
+};
+
 int omap3_init_camera(struct isp_platform_data *pdata)
 {
 	omap3isp_device.dev.platform_data = pdata;
+	omap3isp_device.dev.archdata.iommu = &omap3_isp_iommu;
+
 	return platform_device_register(&omap3isp_device);
 }
 
-- 
1.7.4.1

[RFC 4/5] ARM: OMAP3: bind omap3isp_device to its iommu device

[Ohad Ben-Cohen]

Bind OMAP3's isp device to the isp's dedicated iommu, by setting
the device's archdata iommu member.

This way omap3isp will be able to use the generic IOMMU API without
having to call any omap-specific binding method.

Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
 arch/arm/mach-omap2/devices.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 1077ad6..44122f7 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -28,6 +28,7 @@
 #include <plat/mcbsp.h>
 #include <mach/gpio.h>
 #include <plat/mmc.h>
+#include <plat/iommu.h>
 #include <plat/dma.h>
 #include <plat/omap_hwmod.h>
 #include <plat/omap_device.h>
@@ -207,9 +208,15 @@ static struct platform_device omap3isp_device = {
 	.resource	= omap3isp_resources,
 };
 
+static struct omap_iommu_arch_data omap3_isp_iommu = {
+	.name = "isp",
+};
+
 int omap3_init_camera(struct isp_platform_data *pdata)
 {
 	omap3isp_device.dev.platform_data = pdata;
+	omap3isp_device.dev.archdata.iommu = &omap3_isp_iommu;
+
 	return platform_device_register(&omap3isp_device);
 }
 
-- 
1.7.4.1

Re: [RFC 4/5] ARM: OMAP3: bind omap3isp_device to its iommu device

[Laurent Pinchart]

Hi Ohad,

On Sunday 25 September 2011 12:58:56 Ohad Ben-Cohen wrote:
> Bind OMAP3's isp device to the isp's dedicated iommu, by setting
> the device's archdata iommu member.
> 
> This way omap3isp will be able to use the generic IOMMU API without
> having to call any omap-specific binding method.
> 
> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

> ---
>  arch/arm/mach-omap2/devices.c |    7 +++++++
>  1 files changed, 7 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
> index 1077ad6..44122f7 100644
> --- a/arch/arm/mach-omap2/devices.c
> +++ b/arch/arm/mach-omap2/devices.c
> @@ -28,6 +28,7 @@
>  #include <plat/mcbsp.h>
>  #include <mach/gpio.h>
>  #include <plat/mmc.h>
> +#include <plat/iommu.h>
>  #include <plat/dma.h>
>  #include <plat/omap_hwmod.h>
>  #include <plat/omap_device.h>
> @@ -207,9 +208,15 @@ static struct platform_device omap3isp_device = {
>  	.resource	= omap3isp_resources,
>  };
> 
> +static struct omap_iommu_arch_data omap3_isp_iommu = {
> +	.name = "isp",
> +};
> +
>  int omap3_init_camera(struct isp_platform_data *pdata)
>  {
>  	omap3isp_device.dev.platform_data = pdata;
> +	omap3isp_device.dev.archdata.iommu = &omap3_isp_iommu;
> +
>  	return platform_device_register(&omap3isp_device);
>  }

-- 
Regards,

Laurent Pinchart

[RFC 4/5] ARM: OMAP3: bind omap3isp_device to its iommu device

[Laurent Pinchart]

Hi Ohad,

On Sunday 25 September 2011 12:58:56 Ohad Ben-Cohen wrote:
> Bind OMAP3's isp device to the isp's dedicated iommu, by setting
> the device's archdata iommu member.
> 
> This way omap3isp will be able to use the generic IOMMU API without
> having to call any omap-specific binding method.
> 
> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

> ---
>  arch/arm/mach-omap2/devices.c |    7 +++++++
>  1 files changed, 7 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
> index 1077ad6..44122f7 100644
> --- a/arch/arm/mach-omap2/devices.c
> +++ b/arch/arm/mach-omap2/devices.c
> @@ -28,6 +28,7 @@
>  #include <plat/mcbsp.h>
>  #include <mach/gpio.h>
>  #include <plat/mmc.h>
> +#include <plat/iommu.h>
>  #include <plat/dma.h>
>  #include <plat/omap_hwmod.h>
>  #include <plat/omap_device.h>
> @@ -207,9 +208,15 @@ static struct platform_device omap3isp_device = {
>  	.resource	= omap3isp_resources,
>  };
> 
> +static struct omap_iommu_arch_data omap3_isp_iommu = {
> +	.name = "isp",
> +};
> +
>  int omap3_init_camera(struct isp_platform_data *pdata)
>  {
>  	omap3isp_device.dev.platform_data = pdata;
> +	omap3isp_device.dev.archdata.iommu = &omap3_isp_iommu;
> +
>  	return platform_device_register(&omap3isp_device);
>  }

-- 
Regards,

Laurent Pinchart

Re: [RFC 4/5] ARM: OMAP3: bind omap3isp_device to its iommu device

[Ohad Ben-Cohen]

On Wed, Nov 9, 2011 at 11:17 AM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> Hi Ohad,
>
> On Sunday 25 September 2011 12:58:56 Ohad Ben-Cohen wrote:
>> Bind OMAP3's isp device to the isp's dedicated iommu, by setting
>> the device's archdata iommu member.
>>
>> This way omap3isp will be able to use the generic IOMMU API without
>> having to call any omap-specific binding method.
>>
>> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
>> Cc: Tony Lindgren <tony@atomide.com>
>> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>
> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

Thanks, Laurent!

Tony, can you please Ack the OMAP parts of this patch set:

https://lkml.org/lkml/2011/9/25/44 (patch 3/5)
https://lkml.org/lkml/2011/9/25/46 (patch 4/5)
https://lkml.org/lkml/2011/9/25/45 (patch 5/5)

With this in hand, generic iommu users will now work on OMAP platforms
too (without calling any omap-specific API).

Thanks,
Ohad.

[RFC 4/5] ARM: OMAP3: bind omap3isp_device to its iommu device

[Ohad Ben-Cohen]

On Wed, Nov 9, 2011 at 11:17 AM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> Hi Ohad,
>
> On Sunday 25 September 2011 12:58:56 Ohad Ben-Cohen wrote:
>> Bind OMAP3's isp device to the isp's dedicated iommu, by setting
>> the device's archdata iommu member.
>>
>> This way omap3isp will be able to use the generic IOMMU API without
>> having to call any omap-specific binding method.
>>
>> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
>> Cc: Tony Lindgren <tony@atomide.com>
>> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>
> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

Thanks, Laurent!

Tony, can you please Ack the OMAP parts of this patch set:

https://lkml.org/lkml/2011/9/25/44 (patch 3/5)
https://lkml.org/lkml/2011/9/25/46 (patch 4/5)
https://lkml.org/lkml/2011/9/25/45 (patch 5/5)

With this in hand, generic iommu users will now work on OMAP platforms
too (without calling any omap-specific API).

Thanks,
Ohad.

Re: [RFC 4/5] ARM: OMAP3: bind omap3isp_device to its iommu device

[Tony Lindgren]

* Laurent Pinchart <laurent.pinchart@ideasonboard.com> [111109 00:42]:
> Hi Ohad,
> 
> On Sunday 25 September 2011 12:58:56 Ohad Ben-Cohen wrote:
> > Bind OMAP3's isp device to the isp's dedicated iommu, by setting
> > the device's archdata iommu member.
> > 
> > This way omap3isp will be able to use the generic IOMMU API without
> > having to call any omap-specific binding method.
> > 
> > Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
> > Cc: Tony Lindgren <tony@atomide.com>
> > Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> 
> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

Acked-by: Tony Lindgren <tony@atomide.com>
 
> > ---
> >  arch/arm/mach-omap2/devices.c |    7 +++++++
> >  1 files changed, 7 insertions(+), 0 deletions(-)
> > 
> > diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
> > index 1077ad6..44122f7 100644
> > --- a/arch/arm/mach-omap2/devices.c
> > +++ b/arch/arm/mach-omap2/devices.c
> > @@ -28,6 +28,7 @@
> >  #include <plat/mcbsp.h>
> >  #include <mach/gpio.h>
> >  #include <plat/mmc.h>
> > +#include <plat/iommu.h>
> >  #include <plat/dma.h>
> >  #include <plat/omap_hwmod.h>
> >  #include <plat/omap_device.h>
> > @@ -207,9 +208,15 @@ static struct platform_device omap3isp_device = {
> >  	.resource	= omap3isp_resources,
> >  };
> > 
> > +static struct omap_iommu_arch_data omap3_isp_iommu = {
> > +	.name = "isp",
> > +};
> > +
> >  int omap3_init_camera(struct isp_platform_data *pdata)
> >  {
> >  	omap3isp_device.dev.platform_data = pdata;
> > +	omap3isp_device.dev.archdata.iommu = &omap3_isp_iommu;
> > +
> >  	return platform_device_register(&omap3isp_device);
> >  }
> 
> -- 
> Regards,
> 
> Laurent Pinchart

[RFC 4/5] ARM: OMAP3: bind omap3isp_device to its iommu device

[Tony Lindgren]

* Laurent Pinchart <laurent.pinchart@ideasonboard.com> [111109 00:42]:
> Hi Ohad,
> 
> On Sunday 25 September 2011 12:58:56 Ohad Ben-Cohen wrote:
> > Bind OMAP3's isp device to the isp's dedicated iommu, by setting
> > the device's archdata iommu member.
> > 
> > This way omap3isp will be able to use the generic IOMMU API without
> > having to call any omap-specific binding method.
> > 
> > Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
> > Cc: Tony Lindgren <tony@atomide.com>
> > Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> 
> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

Acked-by: Tony Lindgren <tony@atomide.com>
 
> > ---
> >  arch/arm/mach-omap2/devices.c |    7 +++++++
> >  1 files changed, 7 insertions(+), 0 deletions(-)
> > 
> > diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
> > index 1077ad6..44122f7 100644
> > --- a/arch/arm/mach-omap2/devices.c
> > +++ b/arch/arm/mach-omap2/devices.c
> > @@ -28,6 +28,7 @@
> >  #include <plat/mcbsp.h>
> >  #include <mach/gpio.h>
> >  #include <plat/mmc.h>
> > +#include <plat/iommu.h>
> >  #include <plat/dma.h>
> >  #include <plat/omap_hwmod.h>
> >  #include <plat/omap_device.h>
> > @@ -207,9 +208,15 @@ static struct platform_device omap3isp_device = {
> >  	.resource	= omap3isp_resources,
> >  };
> > 
> > +static struct omap_iommu_arch_data omap3_isp_iommu = {
> > +	.name = "isp",
> > +};
> > +
> >  int omap3_init_camera(struct isp_platform_data *pdata)
> >  {
> >  	omap3isp_device.dev.platform_data = pdata;
> > +	omap3isp_device.dev.archdata.iommu = &omap3_isp_iommu;
> > +
> >  	return platform_device_register(&omap3isp_device);
> >  }
> 
> -- 
> Regards,
> 
> Laurent Pinchart

[RFC 5/5] iommu/omap: eliminate the public omap_find_iommu_device() method

[Ohad Ben-Cohen]

Eliminate the public omap_find_iommu_device() method, and don't
expect clients to provide the omap_iommu handle anymore.

Instead, OMAP's iommu driver should now utilize dev_archdata's private iommu
extension to be able to access the required iommu information.

Update omap3isp appropriately.

Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Cc: Hiroshi DOYU <Hiroshi.DOYU@nokia.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Tony Lindgren <tony@atomide.com>
---
 arch/arm/plat-omap/include/plat/iommu.h |    5 +--
 arch/arm/plat-omap/include/plat/iovmm.h |   12 +++---
 drivers/iommu/omap-iommu.c              |   58 ++++++++++++++-----------------
 drivers/iommu/omap-iovmm.c              |   31 +++++++++++------
 drivers/media/video/omap3isp/isp.c      |   30 +++-------------
 drivers/media/video/omap3isp/isp.h      |    2 -
 drivers/media/video/omap3isp/ispccdc.c  |   18 +++++-----
 drivers/media/video/omap3isp/ispstat.c  |    8 ++--
 drivers/media/video/omap3isp/ispvideo.c |    4 +-
 9 files changed, 74 insertions(+), 94 deletions(-)

diff --git a/arch/arm/plat-omap/include/plat/iommu.h b/arch/arm/plat-omap/include/plat/iommu.h
index fa11ee2..88be3e6 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -189,8 +189,8 @@ extern int omap_iommu_set_isr(const char *name,
 				    void *priv),
 			 void *isr_priv);
 
-extern void omap_iommu_save_ctx(struct omap_iommu *obj);
-extern void omap_iommu_restore_ctx(struct omap_iommu *obj);
+extern void omap_iommu_save_ctx(struct device *dev);
+extern void omap_iommu_restore_ctx(struct device *dev);
 
 extern int omap_install_iommu_arch(const struct iommu_functions *ops);
 extern void omap_uninstall_iommu_arch(const struct iommu_functions *ops);
@@ -202,6 +202,5 @@ extern ssize_t
 omap_iommu_dump_ctx(struct omap_iommu *obj, char *buf, ssize_t len);
 extern size_t
 omap_dump_tlb_entries(struct omap_iommu *obj, char *buf, ssize_t len);
-struct device *omap_find_iommu_device(const char *name);
 
 #endif /* __MACH_IOMMU_H */
diff --git a/arch/arm/plat-omap/include/plat/iovmm.h b/arch/arm/plat-omap/include/plat/iovmm.h
index 6af1a91..498e57c 100644
--- a/arch/arm/plat-omap/include/plat/iovmm.h
+++ b/arch/arm/plat-omap/include/plat/iovmm.h
@@ -72,18 +72,18 @@ struct iovm_struct {
 #define IOVMF_DA_FIXED		(1 << (4 + IOVMF_SW_SHIFT))
 
 
-extern struct iovm_struct *omap_find_iovm_area(struct omap_iommu *obj, u32 da);
+extern struct iovm_struct *omap_find_iovm_area(struct device *dev, u32 da);
 extern u32
-omap_iommu_vmap(struct iommu_domain *domain, struct omap_iommu *obj, u32 da,
+omap_iommu_vmap(struct iommu_domain *domain, struct device *dev, u32 da,
 			const struct sg_table *sgt, u32 flags);
 extern struct sg_table *omap_iommu_vunmap(struct iommu_domain *domain,
-				struct omap_iommu *obj, u32 da);
+				struct device *dev, u32 da);
 extern u32
-omap_iommu_vmalloc(struct iommu_domain *domain, struct omap_iommu *obj,
+omap_iommu_vmalloc(struct iommu_domain *domain, struct device *dev,
 				u32 da, size_t bytes, u32 flags);
 extern void
-omap_iommu_vfree(struct iommu_domain *domain, struct omap_iommu *obj,
+omap_iommu_vfree(struct iommu_domain *domain, struct device *dev,
 				const u32 da);
-extern void *omap_da_to_va(struct omap_iommu *obj, u32 da);
+extern void *omap_da_to_va(struct device *dev, u32 da);
 
 #endif /* __IOMMU_MMAP_H */
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 849a39e..eea3ee2 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -86,20 +86,24 @@ EXPORT_SYMBOL_GPL(omap_uninstall_iommu_arch);
 
 /**
  * omap_iommu_save_ctx - Save registers for pm off-mode support
- * @obj:	target iommu
+ * @dev:	client device
  **/
-void omap_iommu_save_ctx(struct omap_iommu *obj)
+void omap_iommu_save_ctx(struct device *dev)
 {
+	struct omap_iommu *obj = dev_to_omap_iommu(dev);
+
 	arch_iommu->save_ctx(obj);
 }
 EXPORT_SYMBOL_GPL(omap_iommu_save_ctx);
 
 /**
  * omap_iommu_restore_ctx - Restore registers for pm off-mode support
- * @obj:	target iommu
+ * @dev:	client device
  **/
-void omap_iommu_restore_ctx(struct omap_iommu *obj)
+void omap_iommu_restore_ctx(struct device *dev)
 {
+	struct omap_iommu *obj = dev_to_omap_iommu(dev);
+
 	arch_iommu->restore_ctx(obj);
 }
 EXPORT_SYMBOL_GPL(omap_iommu_restore_ctx);
@@ -815,35 +819,23 @@ static int device_match_by_alias(struct device *dev, void *data)
 }
 
 /**
- * omap_find_iommu_device() - find an omap iommu device by name
- * @name:	name of the iommu device
- *
- * The generic iommu API requires the caller to provide the device
- * he wishes to attach to a certain iommu domain.
- *
- * Drivers generally should not bother with this as it should just
- * be taken care of by the DMA-API using dev_archdata.
- *
- * This function is provided as an interim solution until the latter
- * materializes, and omap3isp is fully migrated to the DMA-API.
- */
-struct device *omap_find_iommu_device(const char *name)
-{
-	return driver_find_device(&omap_iommu_driver.driver, NULL,
-				(void *)name,
-				device_match_by_alias);
-}
-EXPORT_SYMBOL_GPL(omap_find_iommu_device);
-
-/**
  * omap_iommu_attach() - attach iommu device to an iommu domain
- * @dev:	target omap iommu device
+ * @name:	name of target omap iommu device
  * @iopgd:	page table
  **/
-static struct omap_iommu *omap_iommu_attach(struct device *dev, u32 *iopgd)
+static struct omap_iommu *omap_iommu_attach(const char *name, u32 *iopgd)
 {
 	int err = -ENOMEM;
-	struct omap_iommu *obj = to_iommu(dev);
+	struct device *dev;
+	struct omap_iommu *obj;
+
+	dev = driver_find_device(&omap_iommu_driver.driver, NULL,
+				(void *)name,
+				device_match_by_alias);
+	if (!dev)
+		return NULL;
+
+	obj = to_iommu(dev);
 
 	spin_lock(&obj->iommu_lock);
 
@@ -1064,6 +1056,7 @@ omap_iommu_attach_dev(struct iommu_domain *domain, struct device *dev)
 {
 	struct omap_iommu_domain *omap_domain = domain->priv;
 	struct omap_iommu *oiommu;
+	struct omap_iommu_arch_data *arch_data = dev->archdata.iommu;
 	int ret = 0;
 
 	spin_lock(&omap_domain->lock);
@@ -1076,14 +1069,14 @@ omap_iommu_attach_dev(struct iommu_domain *domain, struct device *dev)
 	}
 
 	/* get a handle to and enable the omap iommu */
-	oiommu = omap_iommu_attach(dev, omap_domain->pgtable);
+	oiommu = omap_iommu_attach(arch_data->name, omap_domain->pgtable);
 	if (IS_ERR(oiommu)) {
 		ret = PTR_ERR(oiommu);
 		dev_err(dev, "can't get omap iommu: %d\n", ret);
 		goto out;
 	}
 
-	omap_domain->iommu_dev = oiommu;
+	omap_domain->iommu_dev = arch_data->iommu_dev = oiommu;
 	oiommu->domain = domain;
 
 	/* temporary workaround */
@@ -1098,7 +1091,8 @@ static void omap_iommu_detach_dev(struct iommu_domain *domain,
 				 struct device *dev)
 {
 	struct omap_iommu_domain *omap_domain = domain->priv;
-	struct omap_iommu *oiommu = to_iommu(dev);
+	struct omap_iommu_arch_data *arch_data = dev->archdata.iommu;
+	struct omap_iommu *oiommu = dev_to_omap_iommu(dev);
 
 	spin_lock(&omap_domain->lock);
 
@@ -1112,7 +1106,7 @@ static void omap_iommu_detach_dev(struct iommu_domain *domain,
 
 	omap_iommu_detach(oiommu);
 
-	omap_domain->iommu_dev = NULL;
+	omap_domain->iommu_dev = arch_data->iommu_dev = NULL;
 
 	/* temporary workaround */
 	clk_disable(oiommu->clk);
diff --git a/drivers/iommu/omap-iovmm.c b/drivers/iommu/omap-iovmm.c
index f4dea5a..28ff3da 100644
--- a/drivers/iommu/omap-iovmm.c
+++ b/drivers/iommu/omap-iovmm.c
@@ -230,12 +230,14 @@ static struct iovm_struct *__find_iovm_area(struct omap_iommu *obj,
 
 /**
  * omap_find_iovm_area  -  find iovma which includes @da
+ * @dev:	client device
  * @da:		iommu device virtual address
  *
  * Find the existing iovma starting at @da
  */
-struct iovm_struct *omap_find_iovm_area(struct omap_iommu *obj, u32 da)
+struct iovm_struct *omap_find_iovm_area(struct device *dev, u32 da)
 {
+	struct omap_iommu *obj = dev_to_omap_iommu(dev);
 	struct iovm_struct *area;
 
 	mutex_lock(&obj->mmap_lock);
@@ -342,14 +344,15 @@ static void free_iovm_area(struct omap_iommu *obj, struct iovm_struct *area)
 
 /**
  * omap_da_to_va - convert (d) to (v)
- * @obj:	objective iommu
+ * @dev:	client device
  * @da:		iommu device virtual address
  * @va:		mpu virtual address
  *
  * Returns mpu virtual addr which corresponds to a given device virtual addr
  */
-void *omap_da_to_va(struct omap_iommu *obj, u32 da)
+void *omap_da_to_va(struct device *dev, u32 da)
 {
+	struct omap_iommu *obj = dev_to_omap_iommu(dev);
 	void *va = NULL;
 	struct iovm_struct *area;
 
@@ -575,16 +578,18 @@ __iommu_vmap(struct iommu_domain *domain, struct omap_iommu *obj,
 
 /**
  * omap_iommu_vmap  -  (d)-(p)-(v) address mapper
- * @obj:	objective iommu
+ * @domain:	iommu domain
+ * @dev:	client device
  * @sgt:	address of scatter gather table
  * @flags:	iovma and page property
  *
  * Creates 1-n-1 mapping with given @sgt and returns @da.
  * All @sgt element must be io page size aligned.
  */
-u32 omap_iommu_vmap(struct iommu_domain *domain, struct omap_iommu *obj, u32 da,
+u32 omap_iommu_vmap(struct iommu_domain *domain, struct device *dev, u32 da,
 		const struct sg_table *sgt, u32 flags)
 {
+	struct omap_iommu *obj = dev_to_omap_iommu(dev);
 	size_t bytes;
 	void *va = NULL;
 
@@ -615,15 +620,17 @@ EXPORT_SYMBOL_GPL(omap_iommu_vmap);
 
 /**
  * omap_iommu_vunmap  -  release virtual mapping obtained by 'omap_iommu_vmap()'
- * @obj:	objective iommu
+ * @domain:	iommu domain
+ * @dev:	client device
  * @da:		iommu device virtual address
  *
  * Free the iommu virtually contiguous memory area starting at
  * @da, which was returned by 'omap_iommu_vmap()'.
  */
 struct sg_table *
-omap_iommu_vunmap(struct iommu_domain *domain, struct omap_iommu *obj, u32 da)
+omap_iommu_vunmap(struct iommu_domain *domain, struct device *dev, u32 da)
 {
+	struct omap_iommu *obj = dev_to_omap_iommu(dev);
 	struct sg_table *sgt;
 	/*
 	 * 'sgt' is allocated before 'omap_iommu_vmalloc()' is called.
@@ -640,7 +647,7 @@ EXPORT_SYMBOL_GPL(omap_iommu_vunmap);
 
 /**
  * omap_iommu_vmalloc  -  (d)-(p)-(v) address allocator and mapper
- * @obj:	objective iommu
+ * @dev:	client device
  * @da:		contiguous iommu virtual memory
  * @bytes:	allocation size
  * @flags:	iovma and page property
@@ -649,9 +656,10 @@ EXPORT_SYMBOL_GPL(omap_iommu_vunmap);
  * @da again, which might be adjusted if 'IOVMF_DA_FIXED' is not set.
  */
 u32
-omap_iommu_vmalloc(struct iommu_domain *domain, struct omap_iommu *obj, u32 da,
+omap_iommu_vmalloc(struct iommu_domain *domain, struct device *dev, u32 da,
 						size_t bytes, u32 flags)
 {
+	struct omap_iommu *obj = dev_to_omap_iommu(dev);
 	void *va;
 	struct sg_table *sgt;
 
@@ -691,15 +699,16 @@ EXPORT_SYMBOL_GPL(omap_iommu_vmalloc);
 
 /**
  * omap_iommu_vfree  -  release memory allocated by 'omap_iommu_vmalloc()'
- * @obj:	objective iommu
+ * @dev:	client device
  * @da:		iommu device virtual address
  *
  * Frees the iommu virtually continuous memory area starting at
  * @da, as obtained from 'omap_iommu_vmalloc()'.
  */
-void omap_iommu_vfree(struct iommu_domain *domain, struct omap_iommu *obj,
+void omap_iommu_vfree(struct iommu_domain *domain, struct device *dev,
 								const u32 da)
 {
+	struct omap_iommu *obj = dev_to_omap_iommu(dev);
 	struct sg_table *sgt;
 
 	sgt = unmap_vm_area(domain, obj, da, vfree,
diff --git a/drivers/media/video/omap3isp/isp.c b/drivers/media/video/omap3isp/isp.c
index a4baa61..1cb3a68 100644
--- a/drivers/media/video/omap3isp/isp.c
+++ b/drivers/media/video/omap3isp/isp.c
@@ -80,13 +80,6 @@
 #include "isph3a.h"
 #include "isphist.h"
 
-/*
- * this is provided as an interim solution until omap3isp doesn't need
- * any omap-specific iommu API
- */
-#define to_iommu(dev)							\
-	(struct omap_iommu *)platform_get_drvdata(to_platform_device(dev))
-
 static unsigned int autoidle;
 module_param(autoidle, int, 0444);
 MODULE_PARM_DESC(autoidle, "Enable OMAP3ISP AUTOIDLE support");
@@ -1114,8 +1107,7 @@ isp_restore_context(struct isp_device *isp, struct isp_reg *reg_list)
 static void isp_save_ctx(struct isp_device *isp)
 {
 	isp_save_context(isp, isp_reg_list);
-	if (isp->iommu)
-		omap_iommu_save_ctx(isp->iommu);
+	omap_iommu_save_ctx(isp->dev);
 }
 
 /*
@@ -1128,8 +1120,7 @@ static void isp_save_ctx(struct isp_device *isp)
 static void isp_restore_ctx(struct isp_device *isp)
 {
 	isp_restore_context(isp, isp_reg_list);
-	if (isp->iommu)
-		omap_iommu_restore_ctx(isp->iommu);
+	omap_iommu_restore_ctx(isp->dev);
 	omap3isp_ccdc_restore_context(isp);
 	omap3isp_preview_restore_context(isp);
 }
@@ -1982,7 +1973,7 @@ static int isp_remove(struct platform_device *pdev)
 	isp_cleanup_modules(isp);
 
 	omap3isp_get(isp);
-	iommu_detach_device(isp->domain, isp->iommu_dev);
+	iommu_detach_device(isp->domain, &pdev->dev);
 	iommu_domain_free(isp->domain);
 	omap3isp_put(isp);
 
@@ -2130,17 +2121,6 @@ static int isp_probe(struct platform_device *pdev)
 		}
 	}
 
-	/* IOMMU */
-	isp->iommu_dev = omap_find_iommu_device("isp");
-	if (!isp->iommu_dev) {
-		dev_err(isp->dev, "omap_find_iommu_device failed\n");
-		ret = -ENODEV;
-		goto error_isp;
-	}
-
-	/* to be removed once iommu migration is complete */
-	isp->iommu = to_iommu(isp->iommu_dev);
-
 	isp->domain = iommu_domain_alloc();
 	if (!isp->domain) {
 		dev_err(isp->dev, "can't alloc iommu domain\n");
@@ -2148,7 +2128,7 @@ static int isp_probe(struct platform_device *pdev)
 		goto error_isp;
 	}
 
-	ret = iommu_attach_device(isp->domain, isp->iommu_dev);
+	ret = iommu_attach_device(isp->domain, &pdev->dev);
 	if (ret) {
 		dev_err(&pdev->dev, "can't attach iommu device: %d\n", ret);
 		goto free_domain;
@@ -2187,7 +2167,7 @@ error_modules:
 error_irq:
 	free_irq(isp->irq_num, isp);
 detach_dev:
-	iommu_detach_device(isp->domain, isp->iommu_dev);
+	iommu_detach_device(isp->domain, &pdev->dev);
 free_domain:
 	iommu_domain_free(isp->domain);
 error_isp:
diff --git a/drivers/media/video/omap3isp/isp.h b/drivers/media/video/omap3isp/isp.h
index 81fdd85..60e0e29 100644
--- a/drivers/media/video/omap3isp/isp.h
+++ b/drivers/media/video/omap3isp/isp.h
@@ -295,9 +295,7 @@ struct isp_device {
 	unsigned int sbl_resources;
 	unsigned int subclk_resources;
 
-	struct omap_iommu *iommu;
 	struct iommu_domain *domain;
-	struct device *iommu_dev;
 
 	struct isp_platform_callback platform_cb;
 };
diff --git a/drivers/media/video/omap3isp/ispccdc.c b/drivers/media/video/omap3isp/ispccdc.c
index 9891dde..6b4c11e 100644
--- a/drivers/media/video/omap3isp/ispccdc.c
+++ b/drivers/media/video/omap3isp/ispccdc.c
@@ -365,7 +365,7 @@ static void ccdc_lsc_free_request(struct isp_ccdc_device *ccdc,
 		dma_unmap_sg(isp->dev, req->iovm->sgt->sgl,
 			     req->iovm->sgt->nents, DMA_TO_DEVICE);
 	if (req->table)
-		omap_iommu_vfree(isp->domain, isp->iommu, req->table);
+		omap_iommu_vfree(isp->domain, isp->dev, req->table);
 	kfree(req);
 }
 
@@ -437,7 +437,7 @@ static int ccdc_lsc_config(struct isp_ccdc_device *ccdc,
 
 		req->enable = 1;
 
-		req->table = omap_iommu_vmalloc(isp->domain, isp->iommu, 0,
+		req->table = omap_iommu_vmalloc(isp->domain, isp->dev, 0,
 					req->config.size, IOMMU_FLAG);
 		if (IS_ERR_VALUE(req->table)) {
 			req->table = 0;
@@ -445,7 +445,7 @@ static int ccdc_lsc_config(struct isp_ccdc_device *ccdc,
 			goto done;
 		}
 
-		req->iovm = omap_find_iovm_area(isp->iommu, req->table);
+		req->iovm = omap_find_iovm_area(isp->dev, req->table);
 		if (req->iovm == NULL) {
 			ret = -ENOMEM;
 			goto done;
@@ -461,7 +461,7 @@ static int ccdc_lsc_config(struct isp_ccdc_device *ccdc,
 		dma_sync_sg_for_cpu(isp->dev, req->iovm->sgt->sgl,
 				    req->iovm->sgt->nents, DMA_TO_DEVICE);
 
-		table = omap_da_to_va(isp->iommu, req->table);
+		table = omap_da_to_va(isp->dev, req->table);
 		if (copy_from_user(table, config->lsc, req->config.size)) {
 			ret = -EFAULT;
 			goto done;
@@ -733,15 +733,15 @@ static int ccdc_config(struct isp_ccdc_device *ccdc,
 			 * already done by omap_iommu_vmalloc().
 			 */
 			size = ccdc->fpc.fpnum * 4;
-			table_new = omap_iommu_vmalloc(isp->domain, isp->iommu,
+			table_new = omap_iommu_vmalloc(isp->domain, isp->dev,
 							0, size, IOMMU_FLAG);
 			if (IS_ERR_VALUE(table_new))
 				return -ENOMEM;
 
-			if (copy_from_user(omap_da_to_va(isp->iommu, table_new),
+			if (copy_from_user(omap_da_to_va(isp->dev, table_new),
 					   (__force void __user *)
 					   ccdc->fpc.fpcaddr, size)) {
-				omap_iommu_vfree(isp->domain, isp->iommu,
+				omap_iommu_vfree(isp->domain, isp->dev,
 								table_new);
 				return -EFAULT;
 			}
@@ -752,7 +752,7 @@ static int ccdc_config(struct isp_ccdc_device *ccdc,
 
 		ccdc_configure_fpc(ccdc);
 		if (table_old != 0)
-			omap_iommu_vfree(isp->domain, isp->iommu, table_old);
+			omap_iommu_vfree(isp->domain, isp->dev, table_old);
 	}
 
 	return ccdc_lsc_config(ccdc, ccdc_struct);
@@ -2287,5 +2287,5 @@ void omap3isp_ccdc_cleanup(struct isp_device *isp)
 	ccdc_lsc_free_queue(ccdc, &ccdc->lsc.free_queue);
 
 	if (ccdc->fpc.fpcaddr != 0)
-		omap_iommu_vfree(isp->domain, isp->iommu, ccdc->fpc.fpcaddr);
+		omap_iommu_vfree(isp->domain, isp->dev, ccdc->fpc.fpcaddr);
 }
diff --git a/drivers/media/video/omap3isp/ispstat.c b/drivers/media/video/omap3isp/ispstat.c
index 7329055..036fc93 100644
--- a/drivers/media/video/omap3isp/ispstat.c
+++ b/drivers/media/video/omap3isp/ispstat.c
@@ -366,7 +366,7 @@ static void isp_stat_bufs_free(struct ispstat *stat)
 				dma_unmap_sg(isp->dev, buf->iovm->sgt->sgl,
 					     buf->iovm->sgt->nents,
 					     DMA_FROM_DEVICE);
-			omap_iommu_vfree(isp->domain, isp->iommu,
+			omap_iommu_vfree(isp->domain, isp->dev,
 							buf->iommu_addr);
 		} else {
 			if (!buf->virt_addr)
@@ -400,7 +400,7 @@ static int isp_stat_bufs_alloc_iommu(struct ispstat *stat, unsigned int size)
 		struct iovm_struct *iovm;
 
 		WARN_ON(buf->dma_addr);
-		buf->iommu_addr = omap_iommu_vmalloc(isp->domain, isp->iommu, 0,
+		buf->iommu_addr = omap_iommu_vmalloc(isp->domain, isp->dev, 0,
 							size, IOMMU_FLAG);
 		if (IS_ERR((void *)buf->iommu_addr)) {
 			dev_err(stat->isp->dev,
@@ -410,7 +410,7 @@ static int isp_stat_bufs_alloc_iommu(struct ispstat *stat, unsigned int size)
 			return -ENOMEM;
 		}
 
-		iovm = omap_find_iovm_area(isp->iommu, buf->iommu_addr);
+		iovm = omap_find_iovm_area(isp->dev, buf->iommu_addr);
 		if (!iovm ||
 		    !dma_map_sg(isp->dev, iovm->sgt->sgl, iovm->sgt->nents,
 				DMA_FROM_DEVICE)) {
@@ -419,7 +419,7 @@ static int isp_stat_bufs_alloc_iommu(struct ispstat *stat, unsigned int size)
 		}
 		buf->iovm = iovm;
 
-		buf->virt_addr = omap_da_to_va(stat->isp->iommu,
+		buf->virt_addr = omap_da_to_va(stat->isp->dev,
 					  (u32)buf->iommu_addr);
 		buf->empty = 1;
 		dev_dbg(stat->isp->dev, "%s: buffer[%d] allocated."
diff --git a/drivers/media/video/omap3isp/ispvideo.c b/drivers/media/video/omap3isp/ispvideo.c
index 912ac07..6d1d55b 100644
--- a/drivers/media/video/omap3isp/ispvideo.c
+++ b/drivers/media/video/omap3isp/ispvideo.c
@@ -446,7 +446,7 @@ ispmmu_vmap(struct isp_device *isp, const struct scatterlist *sglist, int sglen)
 	sgt->nents = sglen;
 	sgt->orig_nents = sglen;
 
-	da = omap_iommu_vmap(isp->domain, isp->iommu, 0, sgt, IOMMU_FLAG);
+	da = omap_iommu_vmap(isp->domain, isp->dev, 0, sgt, IOMMU_FLAG);
 	if (IS_ERR_VALUE(da))
 		kfree(sgt);
 
@@ -462,7 +462,7 @@ static void ispmmu_vunmap(struct isp_device *isp, dma_addr_t da)
 {
 	struct sg_table *sgt;
 
-	sgt = omap_iommu_vunmap(isp->domain, isp->iommu, (u32)da);
+	sgt = omap_iommu_vunmap(isp->domain, isp->dev, (u32)da);
 	kfree(sgt);
 }
 
-- 
1.7.4.1

[RFC 5/5] iommu/omap: eliminate the public omap_find_iommu_device() method

[Ohad Ben-Cohen]

Eliminate the public omap_find_iommu_device() method, and don't
expect clients to provide the omap_iommu handle anymore.

Instead, OMAP's iommu driver should now utilize dev_archdata's private iommu
extension to be able to access the required iommu information.

Update omap3isp appropriately.

Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Cc: Hiroshi DOYU <Hiroshi.DOYU@nokia.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Tony Lindgren <tony@atomide.com>
---
 arch/arm/plat-omap/include/plat/iommu.h |    5 +--
 arch/arm/plat-omap/include/plat/iovmm.h |   12 +++---
 drivers/iommu/omap-iommu.c              |   58 ++++++++++++++-----------------
 drivers/iommu/omap-iovmm.c              |   31 +++++++++++------
 drivers/media/video/omap3isp/isp.c      |   30 +++-------------
 drivers/media/video/omap3isp/isp.h      |    2 -
 drivers/media/video/omap3isp/ispccdc.c  |   18 +++++-----
 drivers/media/video/omap3isp/ispstat.c  |    8 ++--
 drivers/media/video/omap3isp/ispvideo.c |    4 +-
 9 files changed, 74 insertions(+), 94 deletions(-)

diff --git a/arch/arm/plat-omap/include/plat/iommu.h b/arch/arm/plat-omap/include/plat/iommu.h
index fa11ee2..88be3e6 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -189,8 +189,8 @@ extern int omap_iommu_set_isr(const char *name,
 				    void *priv),
 			 void *isr_priv);
 
-extern void omap_iommu_save_ctx(struct omap_iommu *obj);
-extern void omap_iommu_restore_ctx(struct omap_iommu *obj);
+extern void omap_iommu_save_ctx(struct device *dev);
+extern void omap_iommu_restore_ctx(struct device *dev);
 
 extern int omap_install_iommu_arch(const struct iommu_functions *ops);
 extern void omap_uninstall_iommu_arch(const struct iommu_functions *ops);
@@ -202,6 +202,5 @@ extern ssize_t
 omap_iommu_dump_ctx(struct omap_iommu *obj, char *buf, ssize_t len);
 extern size_t
 omap_dump_tlb_entries(struct omap_iommu *obj, char *buf, ssize_t len);
-struct device *omap_find_iommu_device(const char *name);
 
 #endif /* __MACH_IOMMU_H */
diff --git a/arch/arm/plat-omap/include/plat/iovmm.h b/arch/arm/plat-omap/include/plat/iovmm.h
index 6af1a91..498e57c 100644
--- a/arch/arm/plat-omap/include/plat/iovmm.h
+++ b/arch/arm/plat-omap/include/plat/iovmm.h
@@ -72,18 +72,18 @@ struct iovm_struct {
 #define IOVMF_DA_FIXED		(1 << (4 + IOVMF_SW_SHIFT))
 
 
-extern struct iovm_struct *omap_find_iovm_area(struct omap_iommu *obj, u32 da);
+extern struct iovm_struct *omap_find_iovm_area(struct device *dev, u32 da);
 extern u32
-omap_iommu_vmap(struct iommu_domain *domain, struct omap_iommu *obj, u32 da,
+omap_iommu_vmap(struct iommu_domain *domain, struct device *dev, u32 da,
 			const struct sg_table *sgt, u32 flags);
 extern struct sg_table *omap_iommu_vunmap(struct iommu_domain *domain,
-				struct omap_iommu *obj, u32 da);
+				struct device *dev, u32 da);
 extern u32
-omap_iommu_vmalloc(struct iommu_domain *domain, struct omap_iommu *obj,
+omap_iommu_vmalloc(struct iommu_domain *domain, struct device *dev,
 				u32 da, size_t bytes, u32 flags);
 extern void
-omap_iommu_vfree(struct iommu_domain *domain, struct omap_iommu *obj,
+omap_iommu_vfree(struct iommu_domain *domain, struct device *dev,
 				const u32 da);
-extern void *omap_da_to_va(struct omap_iommu *obj, u32 da);
+extern void *omap_da_to_va(struct device *dev, u32 da);
 
 #endif /* __IOMMU_MMAP_H */
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 849a39e..eea3ee2 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -86,20 +86,24 @@ EXPORT_SYMBOL_GPL(omap_uninstall_iommu_arch);
 
 /**
  * omap_iommu_save_ctx - Save registers for pm off-mode support
- * @obj:	target iommu
+ * @dev:	client device
  **/
-void omap_iommu_save_ctx(struct omap_iommu *obj)
+void omap_iommu_save_ctx(struct device *dev)
 {
+	struct omap_iommu *obj = dev_to_omap_iommu(dev);
+
 	arch_iommu->save_ctx(obj);
 }
 EXPORT_SYMBOL_GPL(omap_iommu_save_ctx);
 
 /**
  * omap_iommu_restore_ctx - Restore registers for pm off-mode support
- * @obj:	target iommu
+ * @dev:	client device
  **/
-void omap_iommu_restore_ctx(struct omap_iommu *obj)
+void omap_iommu_restore_ctx(struct device *dev)
 {
+	struct omap_iommu *obj = dev_to_omap_iommu(dev);
+
 	arch_iommu->restore_ctx(obj);
 }
 EXPORT_SYMBOL_GPL(omap_iommu_restore_ctx);
@@ -815,35 +819,23 @@ static int device_match_by_alias(struct device *dev, void *data)
 }
 
 /**
- * omap_find_iommu_device() - find an omap iommu device by name
- * @name:	name of the iommu device
- *
- * The generic iommu API requires the caller to provide the device
- * he wishes to attach to a certain iommu domain.
- *
- * Drivers generally should not bother with this as it should just
- * be taken care of by the DMA-API using dev_archdata.
- *
- * This function is provided as an interim solution until the latter
- * materializes, and omap3isp is fully migrated to the DMA-API.
- */
-struct device *omap_find_iommu_device(const char *name)
-{
-	return driver_find_device(&omap_iommu_driver.driver, NULL,
-				(void *)name,
-				device_match_by_alias);
-}
-EXPORT_SYMBOL_GPL(omap_find_iommu_device);
-
-/**
  * omap_iommu_attach() - attach iommu device to an iommu domain
- * @dev:	target omap iommu device
+ * @name:	name of target omap iommu device
  * @iopgd:	page table
  **/
-static struct omap_iommu *omap_iommu_attach(struct device *dev, u32 *iopgd)
+static struct omap_iommu *omap_iommu_attach(const char *name, u32 *iopgd)
 {
 	int err = -ENOMEM;
-	struct omap_iommu *obj = to_iommu(dev);
+	struct device *dev;
+	struct omap_iommu *obj;
+
+	dev = driver_find_device(&omap_iommu_driver.driver, NULL,
+				(void *)name,
+				device_match_by_alias);
+	if (!dev)
+		return NULL;
+
+	obj = to_iommu(dev);
 
 	spin_lock(&obj->iommu_lock);
 
@@ -1064,6 +1056,7 @@ omap_iommu_attach_dev(struct iommu_domain *domain, struct device *dev)
 {
 	struct omap_iommu_domain *omap_domain = domain->priv;
 	struct omap_iommu *oiommu;
+	struct omap_iommu_arch_data *arch_data = dev->archdata.iommu;
 	int ret = 0;
 
 	spin_lock(&omap_domain->lock);
@@ -1076,14 +1069,14 @@ omap_iommu_attach_dev(struct iommu_domain *domain, struct device *dev)
 	}
 
 	/* get a handle to and enable the omap iommu */
-	oiommu = omap_iommu_attach(dev, omap_domain->pgtable);
+	oiommu = omap_iommu_attach(arch_data->name, omap_domain->pgtable);
 	if (IS_ERR(oiommu)) {
 		ret = PTR_ERR(oiommu);
 		dev_err(dev, "can't get omap iommu: %d\n", ret);
 		goto out;
 	}
 
-	omap_domain->iommu_dev = oiommu;
+	omap_domain->iommu_dev = arch_data->iommu_dev = oiommu;
 	oiommu->domain = domain;
 
 	/* temporary workaround */
@@ -1098,7 +1091,8 @@ static void omap_iommu_detach_dev(struct iommu_domain *domain,
 				 struct device *dev)
 {
 	struct omap_iommu_domain *omap_domain = domain->priv;
-	struct omap_iommu *oiommu = to_iommu(dev);
+	struct omap_iommu_arch_data *arch_data = dev->archdata.iommu;
+	struct omap_iommu *oiommu = dev_to_omap_iommu(dev);
 
 	spin_lock(&omap_domain->lock);
 
@@ -1112,7 +1106,7 @@ static void omap_iommu_detach_dev(struct iommu_domain *domain,
 
 	omap_iommu_detach(oiommu);
 
-	omap_domain->iommu_dev = NULL;
+	omap_domain->iommu_dev = arch_data->iommu_dev = NULL;
 
 	/* temporary workaround */
 	clk_disable(oiommu->clk);
diff --git a/drivers/iommu/omap-iovmm.c b/drivers/iommu/omap-iovmm.c
index f4dea5a..28ff3da 100644
--- a/drivers/iommu/omap-iovmm.c
+++ b/drivers/iommu/omap-iovmm.c
@@ -230,12 +230,14 @@ static struct iovm_struct *__find_iovm_area(struct omap_iommu *obj,
 
 /**
  * omap_find_iovm_area  -  find iovma which includes @da
+ * @dev:	client device
  * @da:		iommu device virtual address
  *
  * Find the existing iovma starting at @da
  */
-struct iovm_struct *omap_find_iovm_area(struct omap_iommu *obj, u32 da)
+struct iovm_struct *omap_find_iovm_area(struct device *dev, u32 da)
 {
+	struct omap_iommu *obj = dev_to_omap_iommu(dev);
 	struct iovm_struct *area;
 
 	mutex_lock(&obj->mmap_lock);
@@ -342,14 +344,15 @@ static void free_iovm_area(struct omap_iommu *obj, struct iovm_struct *area)
 
 /**
  * omap_da_to_va - convert (d) to (v)
- * @obj:	objective iommu
+ * @dev:	client device
  * @da:		iommu device virtual address
  * @va:		mpu virtual address
  *
  * Returns mpu virtual addr which corresponds to a given device virtual addr
  */
-void *omap_da_to_va(struct omap_iommu *obj, u32 da)
+void *omap_da_to_va(struct device *dev, u32 da)
 {
+	struct omap_iommu *obj = dev_to_omap_iommu(dev);
 	void *va = NULL;
 	struct iovm_struct *area;
 
@@ -575,16 +578,18 @@ __iommu_vmap(struct iommu_domain *domain, struct omap_iommu *obj,
 
 /**
  * omap_iommu_vmap  -  (d)-(p)-(v) address mapper
- * @obj:	objective iommu
+ * @domain:	iommu domain
+ * @dev:	client device
  * @sgt:	address of scatter gather table
  * @flags:	iovma and page property
  *
  * Creates 1-n-1 mapping with given @sgt and returns @da.
  * All @sgt element must be io page size aligned.
  */
-u32 omap_iommu_vmap(struct iommu_domain *domain, struct omap_iommu *obj, u32 da,
+u32 omap_iommu_vmap(struct iommu_domain *domain, struct device *dev, u32 da,
 		const struct sg_table *sgt, u32 flags)
 {
+	struct omap_iommu *obj = dev_to_omap_iommu(dev);
 	size_t bytes;
 	void *va = NULL;
 
@@ -615,15 +620,17 @@ EXPORT_SYMBOL_GPL(omap_iommu_vmap);
 
 /**
  * omap_iommu_vunmap  -  release virtual mapping obtained by 'omap_iommu_vmap()'
- * @obj:	objective iommu
+ * @domain:	iommu domain
+ * @dev:	client device
  * @da:		iommu device virtual address
  *
  * Free the iommu virtually contiguous memory area starting at
  * @da, which was returned by 'omap_iommu_vmap()'.
  */
 struct sg_table *
-omap_iommu_vunmap(struct iommu_domain *domain, struct omap_iommu *obj, u32 da)
+omap_iommu_vunmap(struct iommu_domain *domain, struct device *dev, u32 da)
 {
+	struct omap_iommu *obj = dev_to_omap_iommu(dev);
 	struct sg_table *sgt;
 	/*
 	 * 'sgt' is allocated before 'omap_iommu_vmalloc()' is called.
@@ -640,7 +647,7 @@ EXPORT_SYMBOL_GPL(omap_iommu_vunmap);
 
 /**
  * omap_iommu_vmalloc  -  (d)-(p)-(v) address allocator and mapper
- * @obj:	objective iommu
+ * @dev:	client device
  * @da:		contiguous iommu virtual memory
  * @bytes:	allocation size
  * @flags:	iovma and page property
@@ -649,9 +656,10 @@ EXPORT_SYMBOL_GPL(omap_iommu_vunmap);
  * @da again, which might be adjusted if 'IOVMF_DA_FIXED' is not set.
  */
 u32
-omap_iommu_vmalloc(struct iommu_domain *domain, struct omap_iommu *obj, u32 da,
+omap_iommu_vmalloc(struct iommu_domain *domain, struct device *dev, u32 da,
 						size_t bytes, u32 flags)
 {
+	struct omap_iommu *obj = dev_to_omap_iommu(dev);
 	void *va;
 	struct sg_table *sgt;
 
@@ -691,15 +699,16 @@ EXPORT_SYMBOL_GPL(omap_iommu_vmalloc);
 
 /**
  * omap_iommu_vfree  -  release memory allocated by 'omap_iommu_vmalloc()'
- * @obj:	objective iommu
+ * @dev:	client device
  * @da:		iommu device virtual address
  *
  * Frees the iommu virtually continuous memory area starting at
  * @da, as obtained from 'omap_iommu_vmalloc()'.
  */
-void omap_iommu_vfree(struct iommu_domain *domain, struct omap_iommu *obj,
+void omap_iommu_vfree(struct iommu_domain *domain, struct device *dev,
 								const u32 da)
 {
+	struct omap_iommu *obj = dev_to_omap_iommu(dev);
 	struct sg_table *sgt;
 
 	sgt = unmap_vm_area(domain, obj, da, vfree,
diff --git a/drivers/media/video/omap3isp/isp.c b/drivers/media/video/omap3isp/isp.c
index a4baa61..1cb3a68 100644
--- a/drivers/media/video/omap3isp/isp.c
+++ b/drivers/media/video/omap3isp/isp.c
@@ -80,13 +80,6 @@
 #include "isph3a.h"
 #include "isphist.h"
 
-/*
- * this is provided as an interim solution until omap3isp doesn't need
- * any omap-specific iommu API
- */
-#define to_iommu(dev)							\
-	(struct omap_iommu *)platform_get_drvdata(to_platform_device(dev))
-
 static unsigned int autoidle;
 module_param(autoidle, int, 0444);
 MODULE_PARM_DESC(autoidle, "Enable OMAP3ISP AUTOIDLE support");
@@ -1114,8 +1107,7 @@ isp_restore_context(struct isp_device *isp, struct isp_reg *reg_list)
 static void isp_save_ctx(struct isp_device *isp)
 {
 	isp_save_context(isp, isp_reg_list);
-	if (isp->iommu)
-		omap_iommu_save_ctx(isp->iommu);
+	omap_iommu_save_ctx(isp->dev);
 }
 
 /*
@@ -1128,8 +1120,7 @@ static void isp_save_ctx(struct isp_device *isp)
 static void isp_restore_ctx(struct isp_device *isp)
 {
 	isp_restore_context(isp, isp_reg_list);
-	if (isp->iommu)
-		omap_iommu_restore_ctx(isp->iommu);
+	omap_iommu_restore_ctx(isp->dev);
 	omap3isp_ccdc_restore_context(isp);
 	omap3isp_preview_restore_context(isp);
 }
@@ -1982,7 +1973,7 @@ static int isp_remove(struct platform_device *pdev)
 	isp_cleanup_modules(isp);
 
 	omap3isp_get(isp);
-	iommu_detach_device(isp->domain, isp->iommu_dev);
+	iommu_detach_device(isp->domain, &pdev->dev);
 	iommu_domain_free(isp->domain);
 	omap3isp_put(isp);
 
@@ -2130,17 +2121,6 @@ static int isp_probe(struct platform_device *pdev)
 		}
 	}
 
-	/* IOMMU */
-	isp->iommu_dev = omap_find_iommu_device("isp");
-	if (!isp->iommu_dev) {
-		dev_err(isp->dev, "omap_find_iommu_device failed\n");
-		ret = -ENODEV;
-		goto error_isp;
-	}
-
-	/* to be removed once iommu migration is complete */
-	isp->iommu = to_iommu(isp->iommu_dev);
-
 	isp->domain = iommu_domain_alloc();
 	if (!isp->domain) {
 		dev_err(isp->dev, "can't alloc iommu domain\n");
@@ -2148,7 +2128,7 @@ static int isp_probe(struct platform_device *pdev)
 		goto error_isp;
 	}
 
-	ret = iommu_attach_device(isp->domain, isp->iommu_dev);
+	ret = iommu_attach_device(isp->domain, &pdev->dev);
 	if (ret) {
 		dev_err(&pdev->dev, "can't attach iommu device: %d\n", ret);
 		goto free_domain;
@@ -2187,7 +2167,7 @@ error_modules:
 error_irq:
 	free_irq(isp->irq_num, isp);
 detach_dev:
-	iommu_detach_device(isp->domain, isp->iommu_dev);
+	iommu_detach_device(isp->domain, &pdev->dev);
 free_domain:
 	iommu_domain_free(isp->domain);
 error_isp:
diff --git a/drivers/media/video/omap3isp/isp.h b/drivers/media/video/omap3isp/isp.h
index 81fdd85..60e0e29 100644
--- a/drivers/media/video/omap3isp/isp.h
+++ b/drivers/media/video/omap3isp/isp.h
@@ -295,9 +295,7 @@ struct isp_device {
 	unsigned int sbl_resources;
 	unsigned int subclk_resources;
 
-	struct omap_iommu *iommu;
 	struct iommu_domain *domain;
-	struct device *iommu_dev;
 
 	struct isp_platform_callback platform_cb;
 };
diff --git a/drivers/media/video/omap3isp/ispccdc.c b/drivers/media/video/omap3isp/ispccdc.c
index 9891dde..6b4c11e 100644
--- a/drivers/media/video/omap3isp/ispccdc.c
+++ b/drivers/media/video/omap3isp/ispccdc.c
@@ -365,7 +365,7 @@ static void ccdc_lsc_free_request(struct isp_ccdc_device *ccdc,
 		dma_unmap_sg(isp->dev, req->iovm->sgt->sgl,
 			     req->iovm->sgt->nents, DMA_TO_DEVICE);
 	if (req->table)
-		omap_iommu_vfree(isp->domain, isp->iommu, req->table);
+		omap_iommu_vfree(isp->domain, isp->dev, req->table);
 	kfree(req);
 }
 
@@ -437,7 +437,7 @@ static int ccdc_lsc_config(struct isp_ccdc_device *ccdc,
 
 		req->enable = 1;
 
-		req->table = omap_iommu_vmalloc(isp->domain, isp->iommu, 0,
+		req->table = omap_iommu_vmalloc(isp->domain, isp->dev, 0,
 					req->config.size, IOMMU_FLAG);
 		if (IS_ERR_VALUE(req->table)) {
 			req->table = 0;
@@ -445,7 +445,7 @@ static int ccdc_lsc_config(struct isp_ccdc_device *ccdc,
 			goto done;
 		}
 
-		req->iovm = omap_find_iovm_area(isp->iommu, req->table);
+		req->iovm = omap_find_iovm_area(isp->dev, req->table);
 		if (req->iovm == NULL) {
 			ret = -ENOMEM;
 			goto done;
@@ -461,7 +461,7 @@ static int ccdc_lsc_config(struct isp_ccdc_device *ccdc,
 		dma_sync_sg_for_cpu(isp->dev, req->iovm->sgt->sgl,
 				    req->iovm->sgt->nents, DMA_TO_DEVICE);
 
-		table = omap_da_to_va(isp->iommu, req->table);
+		table = omap_da_to_va(isp->dev, req->table);
 		if (copy_from_user(table, config->lsc, req->config.size)) {
 			ret = -EFAULT;
 			goto done;
@@ -733,15 +733,15 @@ static int ccdc_config(struct isp_ccdc_device *ccdc,
 			 * already done by omap_iommu_vmalloc().
 			 */
 			size = ccdc->fpc.fpnum * 4;
-			table_new = omap_iommu_vmalloc(isp->domain, isp->iommu,
+			table_new = omap_iommu_vmalloc(isp->domain, isp->dev,
 							0, size, IOMMU_FLAG);
 			if (IS_ERR_VALUE(table_new))
 				return -ENOMEM;
 
-			if (copy_from_user(omap_da_to_va(isp->iommu, table_new),
+			if (copy_from_user(omap_da_to_va(isp->dev, table_new),
 					   (__force void __user *)
 					   ccdc->fpc.fpcaddr, size)) {
-				omap_iommu_vfree(isp->domain, isp->iommu,
+				omap_iommu_vfree(isp->domain, isp->dev,
 								table_new);
 				return -EFAULT;
 			}
@@ -752,7 +752,7 @@ static int ccdc_config(struct isp_ccdc_device *ccdc,
 
 		ccdc_configure_fpc(ccdc);
 		if (table_old != 0)
-			omap_iommu_vfree(isp->domain, isp->iommu, table_old);
+			omap_iommu_vfree(isp->domain, isp->dev, table_old);
 	}
 
 	return ccdc_lsc_config(ccdc, ccdc_struct);
@@ -2287,5 +2287,5 @@ void omap3isp_ccdc_cleanup(struct isp_device *isp)
 	ccdc_lsc_free_queue(ccdc, &ccdc->lsc.free_queue);
 
 	if (ccdc->fpc.fpcaddr != 0)
-		omap_iommu_vfree(isp->domain, isp->iommu, ccdc->fpc.fpcaddr);
+		omap_iommu_vfree(isp->domain, isp->dev, ccdc->fpc.fpcaddr);
 }
diff --git a/drivers/media/video/omap3isp/ispstat.c b/drivers/media/video/omap3isp/ispstat.c
index 7329055..036fc93 100644
--- a/drivers/media/video/omap3isp/ispstat.c
+++ b/drivers/media/video/omap3isp/ispstat.c
@@ -366,7 +366,7 @@ static void isp_stat_bufs_free(struct ispstat *stat)
 				dma_unmap_sg(isp->dev, buf->iovm->sgt->sgl,
 					     buf->iovm->sgt->nents,
 					     DMA_FROM_DEVICE);
-			omap_iommu_vfree(isp->domain, isp->iommu,
+			omap_iommu_vfree(isp->domain, isp->dev,
 							buf->iommu_addr);
 		} else {
 			if (!buf->virt_addr)
@@ -400,7 +400,7 @@ static int isp_stat_bufs_alloc_iommu(struct ispstat *stat, unsigned int size)
 		struct iovm_struct *iovm;
 
 		WARN_ON(buf->dma_addr);
-		buf->iommu_addr = omap_iommu_vmalloc(isp->domain, isp->iommu, 0,
+		buf->iommu_addr = omap_iommu_vmalloc(isp->domain, isp->dev, 0,
 							size, IOMMU_FLAG);
 		if (IS_ERR((void *)buf->iommu_addr)) {
 			dev_err(stat->isp->dev,
@@ -410,7 +410,7 @@ static int isp_stat_bufs_alloc_iommu(struct ispstat *stat, unsigned int size)
 			return -ENOMEM;
 		}
 
-		iovm = omap_find_iovm_area(isp->iommu, buf->iommu_addr);
+		iovm = omap_find_iovm_area(isp->dev, buf->iommu_addr);
 		if (!iovm ||
 		    !dma_map_sg(isp->dev, iovm->sgt->sgl, iovm->sgt->nents,
 				DMA_FROM_DEVICE)) {
@@ -419,7 +419,7 @@ static int isp_stat_bufs_alloc_iommu(struct ispstat *stat, unsigned int size)
 		}
 		buf->iovm = iovm;
 
-		buf->virt_addr = omap_da_to_va(stat->isp->iommu,
+		buf->virt_addr = omap_da_to_va(stat->isp->dev,
 					  (u32)buf->iommu_addr);
 		buf->empty = 1;
 		dev_dbg(stat->isp->dev, "%s: buffer[%d] allocated."
diff --git a/drivers/media/video/omap3isp/ispvideo.c b/drivers/media/video/omap3isp/ispvideo.c
index 912ac07..6d1d55b 100644
--- a/drivers/media/video/omap3isp/ispvideo.c
+++ b/drivers/media/video/omap3isp/ispvideo.c
@@ -446,7 +446,7 @@ ispmmu_vmap(struct isp_device *isp, const struct scatterlist *sglist, int sglen)
 	sgt->nents = sglen;
 	sgt->orig_nents = sglen;
 
-	da = omap_iommu_vmap(isp->domain, isp->iommu, 0, sgt, IOMMU_FLAG);
+	da = omap_iommu_vmap(isp->domain, isp->dev, 0, sgt, IOMMU_FLAG);
 	if (IS_ERR_VALUE(da))
 		kfree(sgt);
 
@@ -462,7 +462,7 @@ static void ispmmu_vunmap(struct isp_device *isp, dma_addr_t da)
 {
 	struct sg_table *sgt;
 
-	sgt = omap_iommu_vunmap(isp->domain, isp->iommu, (u32)da);
+	sgt = omap_iommu_vunmap(isp->domain, isp->dev, (u32)da);
 	kfree(sgt);
 }
 
-- 
1.7.4.1

Re: [RFC 5/5] iommu/omap: eliminate the public omap_find_iommu_device() method

[Laurent Pinchart]

Hi Ohad,

Thanks for the patch.

On Sunday 25 September 2011 12:58:57 Ohad Ben-Cohen wrote:
> Eliminate the public omap_find_iommu_device() method, and don't
> expect clients to provide the omap_iommu handle anymore.
> 
> Instead, OMAP's iommu driver should now utilize dev_archdata's private
> iommu extension to be able to access the required iommu information.
> 
> Update omap3isp appropriately.
> 
> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
> Cc: Hiroshi DOYU <Hiroshi.DOYU@nokia.com>
> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Cc: Tony Lindgren <tony@atomide.com>

For the OMAP3 ISP driver,

Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

-- 
Regards,

Laurent Pinchart

[RFC 5/5] iommu/omap: eliminate the public omap_find_iommu_device() method

[Laurent Pinchart]

Hi Ohad,

Thanks for the patch.

On Sunday 25 September 2011 12:58:57 Ohad Ben-Cohen wrote:
> Eliminate the public omap_find_iommu_device() method, and don't
> expect clients to provide the omap_iommu handle anymore.
> 
> Instead, OMAP's iommu driver should now utilize dev_archdata's private
> iommu extension to be able to access the required iommu information.
> 
> Update omap3isp appropriately.
> 
> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
> Cc: Hiroshi DOYU <Hiroshi.DOYU@nokia.com>
> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Cc: Tony Lindgren <tony@atomide.com>

For the OMAP3 ISP driver,

Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

-- 
Regards,

Laurent Pinchart

Re: [RFC 5/5] iommu/omap: eliminate the public omap_find_iommu_device() method

[Ohad Ben-Cohen]

Hi Laurent,

On Tue, Sep 27, 2011 at 2:46 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Sunday 25 September 2011 12:58:57 Ohad Ben-Cohen wrote:
>> Eliminate the public omap_find_iommu_device() method, and don't
>> expect clients to provide the omap_iommu handle anymore.
>>
>> Instead, OMAP's iommu driver should now utilize dev_archdata's private
>> iommu extension to be able to access the required iommu information.
>>
>> Update omap3isp appropriately.
>>
>> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
>> Cc: Hiroshi DOYU <Hiroshi.DOYU@nokia.com>
>> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>> Cc: Tony Lindgren <tony@atomide.com>
>
> For the OMAP3 ISP driver,
>
> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

Thanks !

Can you please also ack the 4th patch in this series (that's the part
the makes this fifth patch possible):

https://lkml.org/lkml/2011/9/25/46

I could then ask Tony to Ack it so we could merge this via the iommu tree.

Thanks,
Ohad.

[RFC 5/5] iommu/omap: eliminate the public omap_find_iommu_device() method

[Ohad Ben-Cohen]

Hi Laurent,

On Tue, Sep 27, 2011 at 2:46 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Sunday 25 September 2011 12:58:57 Ohad Ben-Cohen wrote:
>> Eliminate the public omap_find_iommu_device() method, and don't
>> expect clients to provide the omap_iommu handle anymore.
>>
>> Instead, OMAP's iommu driver should now utilize dev_archdata's private
>> iommu extension to be able to access the required iommu information.
>>
>> Update omap3isp appropriately.
>>
>> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
>> Cc: Hiroshi DOYU <Hiroshi.DOYU@nokia.com>
>> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>> Cc: Tony Lindgren <tony@atomide.com>
>
> For the OMAP3 ISP driver,
>
> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

Thanks !

Can you please also ack the 4th patch in this series (that's the part
the makes this fifth patch possible):

https://lkml.org/lkml/2011/9/25/46

I could then ask Tony to Ack it so we could merge this via the iommu tree.

Thanks,
Ohad.

Re: [RFC 5/5] iommu/omap: eliminate the public omap_find_iommu_device() method

[Laurent Pinchart]

Hi Ohad,

On Wednesday 09 November 2011 09:50:30 Ohad Ben-Cohen wrote:
> On Tue, Sep 27, 2011 at 2:46 PM, Laurent Pinchart wrote:
> > On Sunday 25 September 2011 12:58:57 Ohad Ben-Cohen wrote:
> >> Eliminate the public omap_find_iommu_device() method, and don't
> >> expect clients to provide the omap_iommu handle anymore.
> >> 
> >> Instead, OMAP's iommu driver should now utilize dev_archdata's private
> >> iommu extension to be able to access the required iommu information.
> >> 
> >> Update omap3isp appropriately.
> >> 
> >> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
> >> Cc: Hiroshi DOYU <Hiroshi.DOYU@nokia.com>
> >> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> >> Cc: Tony Lindgren <tony@atomide.com>
> > 
> > For the OMAP3 ISP driver,
> > 
> > Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> 
> Thanks !
> 
> Can you please also ack the 4th patch in this series (that's the part
> the makes this fifth patch possible):
> 
> https://lkml.org/lkml/2011/9/25/46

Sure. Done.

> I could then ask Tony to Ack it so we could merge this via the iommu tree.

-- 
Regards,

Laurent Pinchart

[RFC 5/5] iommu/omap: eliminate the public omap_find_iommu_device() method

[Laurent Pinchart]

Hi Ohad,

On Wednesday 09 November 2011 09:50:30 Ohad Ben-Cohen wrote:
> On Tue, Sep 27, 2011 at 2:46 PM, Laurent Pinchart wrote:
> > On Sunday 25 September 2011 12:58:57 Ohad Ben-Cohen wrote:
> >> Eliminate the public omap_find_iommu_device() method, and don't
> >> expect clients to provide the omap_iommu handle anymore.
> >> 
> >> Instead, OMAP's iommu driver should now utilize dev_archdata's private
> >> iommu extension to be able to access the required iommu information.
> >> 
> >> Update omap3isp appropriately.
> >> 
> >> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
> >> Cc: Hiroshi DOYU <Hiroshi.DOYU@nokia.com>
> >> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> >> Cc: Tony Lindgren <tony@atomide.com>
> > 
> > For the OMAP3 ISP driver,
> > 
> > Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> 
> Thanks !
> 
> Can you please also ack the 4th patch in this series (that's the part
> the makes this fifth patch possible):
> 
> https://lkml.org/lkml/2011/9/25/46

Sure. Done.

> I could then ask Tony to Ack it so we could merge this via the iommu tree.

-- 
Regards,

Laurent Pinchart

Re: [RFC 5/5] iommu/omap: eliminate the public omap_find_iommu_device() method

[Tony Lindgren]

* Laurent Pinchart <laurent.pinchart@ideasonboard.com> [111109 00:42]:
> Hi Ohad,
> 
> On Wednesday 09 November 2011 09:50:30 Ohad Ben-Cohen wrote:
> > On Tue, Sep 27, 2011 at 2:46 PM, Laurent Pinchart wrote:
> > > On Sunday 25 September 2011 12:58:57 Ohad Ben-Cohen wrote:
> > >> Eliminate the public omap_find_iommu_device() method, and don't
> > >> expect clients to provide the omap_iommu handle anymore.
> > >> 
> > >> Instead, OMAP's iommu driver should now utilize dev_archdata's private
> > >> iommu extension to be able to access the required iommu information.
> > >> 
> > >> Update omap3isp appropriately.
> > >> 
> > >> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
> > >> Cc: Hiroshi DOYU <Hiroshi.DOYU@nokia.com>
> > >> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > >> Cc: Tony Lindgren <tony@atomide.com>
> > > 
> > > For the OMAP3 ISP driver,
> > > 
> > > Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > 
> > Thanks !
> > 
> > Can you please also ack the 4th patch in this series (that's the part
> > the makes this fifth patch possible):
> > 
> > https://lkml.org/lkml/2011/9/25/46
> 
> Sure. Done.
> 
> > I could then ask Tony to Ack it so we could merge this via the iommu tree.

This too:

Acked-by: Tony Lindgren <tony@atomide.com>

[RFC 5/5] iommu/omap: eliminate the public omap_find_iommu_device() method

[Tony Lindgren]

* Laurent Pinchart <laurent.pinchart@ideasonboard.com> [111109 00:42]:
> Hi Ohad,
> 
> On Wednesday 09 November 2011 09:50:30 Ohad Ben-Cohen wrote:
> > On Tue, Sep 27, 2011 at 2:46 PM, Laurent Pinchart wrote:
> > > On Sunday 25 September 2011 12:58:57 Ohad Ben-Cohen wrote:
> > >> Eliminate the public omap_find_iommu_device() method, and don't
> > >> expect clients to provide the omap_iommu handle anymore.
> > >> 
> > >> Instead, OMAP's iommu driver should now utilize dev_archdata's private
> > >> iommu extension to be able to access the required iommu information.
> > >> 
> > >> Update omap3isp appropriately.
> > >> 
> > >> Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
> > >> Cc: Hiroshi DOYU <Hiroshi.DOYU@nokia.com>
> > >> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > >> Cc: Tony Lindgren <tony@atomide.com>
> > > 
> > > For the OMAP3 ISP driver,
> > > 
> > > Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > 
> > Thanks !
> > 
> > Can you please also ack the 4th patch in this series (that's the part
> > the makes this fifth patch possible):
> > 
> > https://lkml.org/lkml/2011/9/25/46
> 
> Sure. Done.
> 
> > I could then ask Tony to Ack it so we could merge this via the iommu tree.

This too:

Acked-by: Tony Lindgren <tony@atomide.com>

Re: [RFC 0/5] OMAP groundwork for IOMMU-based DMA API

[Roedel, Joerg]

Hi Ohad,

On Sun, Sep 25, 2011 at 06:58:52AM -0400, Ohad Ben-Cohen wrote:
> Ohad Ben-Cohen (5):
>   ARM: dev_archdata: add private iommu extension
>   ARM: OMAP: omap_device: add a method to set iommu private archdata
>   ARM: OMAP: iommu: declare a private iommu binding struct
>   ARM: OMAP3: bind omap3isp_device to its iommu device
>   iommu/omap: eliminate the public omap_find_iommu_device() method

It doesn't apply cleanly, can you please rebase the code, collect the
Acked-by's and resend?

Thanks,

	Joerg

-- 
AMD Operating System Research Center

Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632

[RFC 0/5] OMAP groundwork for IOMMU-based DMA API

[Roedel, Joerg]

Hi Ohad,

On Sun, Sep 25, 2011 at 06:58:52AM -0400, Ohad Ben-Cohen wrote:
> Ohad Ben-Cohen (5):
>   ARM: dev_archdata: add private iommu extension
>   ARM: OMAP: omap_device: add a method to set iommu private archdata
>   ARM: OMAP: iommu: declare a private iommu binding struct
>   ARM: OMAP3: bind omap3isp_device to its iommu device
>   iommu/omap: eliminate the public omap_find_iommu_device() method

It doesn't apply cleanly, can you please rebase the code, collect the
Acked-by's and resend?

Thanks,

	Joerg

-- 
AMD Operating System Research Center

Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632

Re: [RFC 0/5] OMAP groundwork for IOMMU-based DMA API

[Roedel, Joerg]

Hi Ohad,

On Sun, Sep 25, 2011 at 06:58:52AM -0400, Ohad Ben-Cohen wrote:
> Ohad Ben-Cohen (5):
>   ARM: dev_archdata: add private iommu extension
>   ARM: OMAP: omap_device: add a method to set iommu private archdata
>   ARM: OMAP: iommu: declare a private iommu binding struct
>   ARM: OMAP3: bind omap3isp_device to its iommu device
>   iommu/omap: eliminate the public omap_find_iommu_device() method

It doesn't apply cleanly, can you please rebase the code, collect the
Acked-by's and resend?

Thanks,

	Joerg

-- 
AMD Operating System Research Center

Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632

Re: [RFC 0/5] OMAP groundwork for IOMMU-based DMA API

[Ohad Ben-Cohen]

Hi Joerg,

On Tue, Nov 15, 2011 at 12:39 PM, Roedel, Joerg <Joerg.Roedel@amd.com> wrote:
> It doesn't apply cleanly, can you please rebase the code, collect the
> Acked-by's and resend?

Sure. I planned on resending after the "hardware pgsize" patches are
merged, but please tell me if you prefer it the other way around.

Thanks,
Ohad.

[RFC 0/5] OMAP groundwork for IOMMU-based DMA API

[Ohad Ben-Cohen]

Hi Joerg,

On Tue, Nov 15, 2011 at 12:39 PM, Roedel, Joerg <Joerg.Roedel@amd.com> wrote:
> It doesn't apply cleanly, can you please rebase the code, collect the
> Acked-by's and resend?

Sure. I planned on resending after the "hardware pgsize" patches are
merged, but please tell me if you prefer it the other way around.

Thanks,
Ohad.

Re: [RFC 0/5] OMAP groundwork for IOMMU-based DMA API

[Ohad Ben-Cohen]

Hi Joerg,

On Tue, Nov 15, 2011 at 12:39 PM, Roedel, Joerg <Joerg.Roedel@amd.com> wrote:
> It doesn't apply cleanly, can you please rebase the code, collect the
> Acked-by's and resend?

Sure. I planned on resending after the "hardware pgsize" patches are
merged, but please tell me if you prefer it the other way around.

Thanks,
Ohad.

Re: [RFC 0/5] OMAP groundwork for IOMMU-based DMA API

[Roedel, Joerg]

On Tue, Nov 15, 2011 at 12:45:33PM +0200, Ohad Ben-Cohen wrote:
> Hi Joerg,
> 
> On Tue, Nov 15, 2011 at 12:39 PM, Roedel, Joerg <Joerg.Roedel@amd.com> wrote:
> > It doesn't apply cleanly, can you please rebase the code, collect the
> > Acked-by's and resend?
> 
> Sure. I planned on resending after the "hardware pgsize" patches are
> merged, but please tell me if you prefer it the other way around.

It is almost merged :) I just had to struggle with some compile errors
from upstream in my tests. But I think I will finish testing today and
push everything out.

Thanks,

	Joerg

-- 
AMD Operating System Research Center

Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632

[RFC 0/5] OMAP groundwork for IOMMU-based DMA API

[Roedel, Joerg]

On Tue, Nov 15, 2011 at 12:45:33PM +0200, Ohad Ben-Cohen wrote:
> Hi Joerg,
> 
> On Tue, Nov 15, 2011 at 12:39 PM, Roedel, Joerg <Joerg.Roedel@amd.com> wrote:
> > It doesn't apply cleanly, can you please rebase the code, collect the
> > Acked-by's and resend?
> 
> Sure. I planned on resending after the "hardware pgsize" patches are
> merged, but please tell me if you prefer it the other way around.

It is almost merged :) I just had to struggle with some compile errors
from upstream in my tests. But I think I will finish testing today and
push everything out.

Thanks,

	Joerg

-- 
AMD Operating System Research Center

Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632

Re: [RFC 0/5] OMAP groundwork for IOMMU-based DMA API

[Roedel, Joerg]

On Tue, Nov 15, 2011 at 12:45:33PM +0200, Ohad Ben-Cohen wrote:
> Hi Joerg,
> 
> On Tue, Nov 15, 2011 at 12:39 PM, Roedel, Joerg <Joerg.Roedel@amd.com> wrote:
> > It doesn't apply cleanly, can you please rebase the code, collect the
> > Acked-by's and resend?
> 
> Sure. I planned on resending after the "hardware pgsize" patches are
> merged, but please tell me if you prefer it the other way around.

It is almost merged :) I just had to struggle with some compile errors
from upstream in my tests. But I think I will finish testing today and
push everything out.

Thanks,

	Joerg

-- 
AMD Operating System Research Center

Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632

Re: [RFC 0/5] OMAP groundwork for IOMMU-based DMA API

[Ohad Ben-Cohen]

On Tue, Nov 15, 2011 at 1:10 PM, Roedel, Joerg <Joerg.Roedel@amd.com> wrote:
> It is almost merged :) I just had to struggle with some compile errors
> from upstream in my tests. But I think I will finish testing today and
> push everything out.
>

ok great thanks :)

[RFC 0/5] OMAP groundwork for IOMMU-based DMA API

[Ohad Ben-Cohen]

On Tue, Nov 15, 2011 at 1:10 PM, Roedel, Joerg <Joerg.Roedel@amd.com> wrote:
> It is almost merged :) I just had to struggle with some compile errors
> from upstream in my tests. But I think I will finish testing today and
> push everything out.
>

ok great thanks :)

Re: [RFC 0/5] OMAP groundwork for IOMMU-based DMA API

[Ohad Ben-Cohen]

On Tue, Nov 15, 2011 at 1:10 PM, Roedel, Joerg <Joerg.Roedel@amd.com> wrote:
> It is almost merged :) I just had to struggle with some compile errors
> from upstream in my tests. But I think I will finish testing today and
> push everything out.
>

ok great thanks :)

Re: [RFC 0/5] OMAP groundwork for IOMMU-based DMA API

[Ohad Ben-Cohen]

Hi Joerg,

On Tue, Nov 15, 2011 at 12:39 PM, Roedel, Joerg <Joerg.Roedel@amd.com> wrote:
> On Sun, Sep 25, 2011 at 06:58:52AM -0400, Ohad Ben-Cohen wrote:
>> Ohad Ben-Cohen (5):
>>   ARM: dev_archdata: add private iommu extension
>>   ARM: OMAP: omap_device: add a method to set iommu private archdata
>>   ARM: OMAP: iommu: declare a private iommu binding struct
>>   ARM: OMAP3: bind omap3isp_device to its iommu device
>>   iommu/omap: eliminate the public omap_find_iommu_device() method
>
> It doesn't apply cleanly, can you please rebase the code, collect the
> Acked-by's and resend?

I have collected Tony's and Laurent's Acked-by's and amended them to
the commit logs.

I have also made sure it applies cleanly to a recent 3.2, and tested
it with OMAP4/remoteproc. I couldn't test it with omap3isp though,
because I'm gated by (what looks like a) 3.2 omap3isp regression (see
http://www.spinics.net/lists/linux-omap/msg60510.html). I did test it
of course with omap3isp and 3.1, so I don't expect any omap3isp/iommu
issues with these patches. Anyway, when the omap3isp issue will be
resolved I'll make sure there isn't any iommu regression.

Please pull, thanks a lot!

The following changes since commit cfcfc9eca2bcbd26a8e206baeb005b055dbf8e37:

  Linux 3.2-rc2 (2011-11-15 15:02:59 -0200)

are available in the git repository at:
  git://git.kernel.org/pub/scm/linux/kernel/git/ohad/linux.git for-joerg

Ohad Ben-Cohen (3):
      ARM: OMAP: iommu: declare a private iommu binding struct
      ARM: OMAP3: bind omap3isp_device to its iommu device
      iommu/omap: eliminate the public omap_find_iommu_device() method

 arch/arm/mach-omap2/devices.c           |    7 ++++
 arch/arm/plat-omap/include/plat/iommu.h |   31 +++++++++++++++--
 arch/arm/plat-omap/include/plat/iovmm.h |   12 +++---
 drivers/iommu/omap-iommu.c              |   58 ++++++++++++++-----------------
 drivers/iommu/omap-iovmm.c              |   31 +++++++++++------
 drivers/media/video/omap3isp/isp.c      |   30 +++-------------
 drivers/media/video/omap3isp/isp.h      |    2 -
 drivers/media/video/omap3isp/ispccdc.c  |   18 +++++-----
 drivers/media/video/omap3isp/ispstat.c  |    8 ++--
 drivers/media/video/omap3isp/ispvideo.c |    4 +-
 10 files changed, 107 insertions(+), 94 deletions(-)

[RFC 0/5] OMAP groundwork for IOMMU-based DMA API

[Ohad Ben-Cohen]

Hi Joerg,

On Tue, Nov 15, 2011 at 12:39 PM, Roedel, Joerg <Joerg.Roedel@amd.com> wrote:
> On Sun, Sep 25, 2011 at 06:58:52AM -0400, Ohad Ben-Cohen wrote:
>> Ohad Ben-Cohen (5):
>> ? ARM: dev_archdata: add private iommu extension
>> ? ARM: OMAP: omap_device: add a method to set iommu private archdata
>> ? ARM: OMAP: iommu: declare a private iommu binding struct
>> ? ARM: OMAP3: bind omap3isp_device to its iommu device
>> ? iommu/omap: eliminate the public omap_find_iommu_device() method
>
> It doesn't apply cleanly, can you please rebase the code, collect the
> Acked-by's and resend?

I have collected Tony's and Laurent's Acked-by's and amended them to
the commit logs.

I have also made sure it applies cleanly to a recent 3.2, and tested
it with OMAP4/remoteproc. I couldn't test it with omap3isp though,
because I'm gated by (what looks like a) 3.2 omap3isp regression (see
http://www.spinics.net/lists/linux-omap/msg60510.html). I did test it
of course with omap3isp and 3.1, so I don't expect any omap3isp/iommu
issues with these patches. Anyway, when the omap3isp issue will be
resolved I'll make sure there isn't any iommu regression.

Please pull, thanks a lot!

The following changes since commit cfcfc9eca2bcbd26a8e206baeb005b055dbf8e37:

  Linux 3.2-rc2 (2011-11-15 15:02:59 -0200)

are available in the git repository at:
  git://git.kernel.org/pub/scm/linux/kernel/git/ohad/linux.git for-joerg

Ohad Ben-Cohen (3):
      ARM: OMAP: iommu: declare a private iommu binding struct
      ARM: OMAP3: bind omap3isp_device to its iommu device
      iommu/omap: eliminate the public omap_find_iommu_device() method

 arch/arm/mach-omap2/devices.c           |    7 ++++
 arch/arm/plat-omap/include/plat/iommu.h |   31 +++++++++++++++--
 arch/arm/plat-omap/include/plat/iovmm.h |   12 +++---
 drivers/iommu/omap-iommu.c              |   58 ++++++++++++++-----------------
 drivers/iommu/omap-iovmm.c              |   31 +++++++++++------
 drivers/media/video/omap3isp/isp.c      |   30 +++-------------
 drivers/media/video/omap3isp/isp.h      |    2 -
 drivers/media/video/omap3isp/ispccdc.c  |   18 +++++-----
 drivers/media/video/omap3isp/ispstat.c  |    8 ++--
 drivers/media/video/omap3isp/ispvideo.c |    4 +-
 10 files changed, 107 insertions(+), 94 deletions(-)

Re: [RFC 0/5] OMAP groundwork for IOMMU-based DMA API

[Ohad Ben-Cohen]

Hi Joerg,

On Tue, Nov 15, 2011 at 12:39 PM, Roedel, Joerg <Joerg.Roedel@amd.com> wrote:
> On Sun, Sep 25, 2011 at 06:58:52AM -0400, Ohad Ben-Cohen wrote:
>> Ohad Ben-Cohen (5):
>>   ARM: dev_archdata: add private iommu extension
>>   ARM: OMAP: omap_device: add a method to set iommu private archdata
>>   ARM: OMAP: iommu: declare a private iommu binding struct
>>   ARM: OMAP3: bind omap3isp_device to its iommu device
>>   iommu/omap: eliminate the public omap_find_iommu_device() method
>
> It doesn't apply cleanly, can you please rebase the code, collect the
> Acked-by's and resend?

I have collected Tony's and Laurent's Acked-by's and amended them to
the commit logs.

I have also made sure it applies cleanly to a recent 3.2, and tested
it with OMAP4/remoteproc. I couldn't test it with omap3isp though,
because I'm gated by (what looks like a) 3.2 omap3isp regression (see
http://www.spinics.net/lists/linux-omap/msg60510.html). I did test it
of course with omap3isp and 3.1, so I don't expect any omap3isp/iommu
issues with these patches. Anyway, when the omap3isp issue will be
resolved I'll make sure there isn't any iommu regression.

Please pull, thanks a lot!

The following changes since commit cfcfc9eca2bcbd26a8e206baeb005b055dbf8e37:

  Linux 3.2-rc2 (2011-11-15 15:02:59 -0200)

are available in the git repository at:
  git://git.kernel.org/pub/scm/linux/kernel/git/ohad/linux.git for-joerg

Ohad Ben-Cohen (3):
      ARM: OMAP: iommu: declare a private iommu binding struct
      ARM: OMAP3: bind omap3isp_device to its iommu device
      iommu/omap: eliminate the public omap_find_iommu_device() method

 arch/arm/mach-omap2/devices.c           |    7 ++++
 arch/arm/plat-omap/include/plat/iommu.h |   31 +++++++++++++++--
 arch/arm/plat-omap/include/plat/iovmm.h |   12 +++---
 drivers/iommu/omap-iommu.c              |   58 ++++++++++++++-----------------
 drivers/iommu/omap-iovmm.c              |   31 +++++++++++------
 drivers/media/video/omap3isp/isp.c      |   30 +++-------------
 drivers/media/video/omap3isp/isp.h      |    2 -
 drivers/media/video/omap3isp/ispccdc.c  |   18 +++++-----
 drivers/media/video/omap3isp/ispstat.c  |    8 ++--
 drivers/media/video/omap3isp/ispvideo.c |    4 +-
 10 files changed, 107 insertions(+), 94 deletions(-)

Re: [RFC 0/5] OMAP groundwork for IOMMU-based DMA API

[Roedel, Joerg]

On Mon, Dec 05, 2011 at 04:21:21PM +0200, Ohad Ben-Cohen wrote:
> Hi Joerg,
> 
> On Tue, Nov 15, 2011 at 12:39 PM, Roedel, Joerg <Joerg.Roedel@amd.com> wrote:
> > On Sun, Sep 25, 2011 at 06:58:52AM -0400, Ohad Ben-Cohen wrote:
> >> Ohad Ben-Cohen (5):
> >>   ARM: dev_archdata: add private iommu extension
> >>   ARM: OMAP: omap_device: add a method to set iommu private archdata
> >>   ARM: OMAP: iommu: declare a private iommu binding struct
> >>   ARM: OMAP3: bind omap3isp_device to its iommu device
> >>   iommu/omap: eliminate the public omap_find_iommu_device() method
> >
> > It doesn't apply cleanly, can you please rebase the code, collect the
> > Acked-by's and resend?
> 
> I have collected Tony's and Laurent's Acked-by's and amended them to
> the commit logs.
> 
> I have also made sure it applies cleanly to a recent 3.2, and tested
> it with OMAP4/remoteproc. I couldn't test it with omap3isp though,
> because I'm gated by (what looks like a) 3.2 omap3isp regression (see
> http://www.spinics.net/lists/linux-omap/msg60510.html). I did test it
> of course with omap3isp and 3.1, so I don't expect any omap3isp/iommu
> issues with these patches. Anyway, when the omap3isp issue will be
> resolved I'll make sure there isn't any iommu regression.
> 
> Please pull, thanks a lot!
> 
> The following changes since commit cfcfc9eca2bcbd26a8e206baeb005b055dbf8e37:
> 
>   Linux 3.2-rc2 (2011-11-15 15:02:59 -0200)
> 
> are available in the git repository at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/ohad/linux.git for-joerg
> 
> Ohad Ben-Cohen (3):
>       ARM: OMAP: iommu: declare a private iommu binding struct
>       ARM: OMAP3: bind omap3isp_device to its iommu device
>       iommu/omap: eliminate the public omap_find_iommu_device() method
> 
>  arch/arm/mach-omap2/devices.c           |    7 ++++
>  arch/arm/plat-omap/include/plat/iommu.h |   31 +++++++++++++++--
>  arch/arm/plat-omap/include/plat/iovmm.h |   12 +++---
>  drivers/iommu/omap-iommu.c              |   58 ++++++++++++++-----------------
>  drivers/iommu/omap-iovmm.c              |   31 +++++++++++------
>  drivers/media/video/omap3isp/isp.c      |   30 +++-------------
>  drivers/media/video/omap3isp/isp.h      |    2 -
>  drivers/media/video/omap3isp/ispccdc.c  |   18 +++++-----
>  drivers/media/video/omap3isp/ispstat.c  |    8 ++--
>  drivers/media/video/omap3isp/ispvideo.c |    4 +-
>  10 files changed, 107 insertions(+), 94 deletions(-)

Pulled into arm/omap, thanks Ohad.

-- 
AMD Operating System Research Center

Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632

[RFC 0/5] OMAP groundwork for IOMMU-based DMA API

[Roedel, Joerg]

On Mon, Dec 05, 2011 at 04:21:21PM +0200, Ohad Ben-Cohen wrote:
> Hi Joerg,
> 
> On Tue, Nov 15, 2011 at 12:39 PM, Roedel, Joerg <Joerg.Roedel@amd.com> wrote:
> > On Sun, Sep 25, 2011 at 06:58:52AM -0400, Ohad Ben-Cohen wrote:
> >> Ohad Ben-Cohen (5):
> >> ? ARM: dev_archdata: add private iommu extension
> >> ? ARM: OMAP: omap_device: add a method to set iommu private archdata
> >> ? ARM: OMAP: iommu: declare a private iommu binding struct
> >> ? ARM: OMAP3: bind omap3isp_device to its iommu device
> >> ? iommu/omap: eliminate the public omap_find_iommu_device() method
> >
> > It doesn't apply cleanly, can you please rebase the code, collect the
> > Acked-by's and resend?
> 
> I have collected Tony's and Laurent's Acked-by's and amended them to
> the commit logs.
> 
> I have also made sure it applies cleanly to a recent 3.2, and tested
> it with OMAP4/remoteproc. I couldn't test it with omap3isp though,
> because I'm gated by (what looks like a) 3.2 omap3isp regression (see
> http://www.spinics.net/lists/linux-omap/msg60510.html). I did test it
> of course with omap3isp and 3.1, so I don't expect any omap3isp/iommu
> issues with these patches. Anyway, when the omap3isp issue will be
> resolved I'll make sure there isn't any iommu regression.
> 
> Please pull, thanks a lot!
> 
> The following changes since commit cfcfc9eca2bcbd26a8e206baeb005b055dbf8e37:
> 
>   Linux 3.2-rc2 (2011-11-15 15:02:59 -0200)
> 
> are available in the git repository at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/ohad/linux.git for-joerg
> 
> Ohad Ben-Cohen (3):
>       ARM: OMAP: iommu: declare a private iommu binding struct
>       ARM: OMAP3: bind omap3isp_device to its iommu device
>       iommu/omap: eliminate the public omap_find_iommu_device() method
> 
>  arch/arm/mach-omap2/devices.c           |    7 ++++
>  arch/arm/plat-omap/include/plat/iommu.h |   31 +++++++++++++++--
>  arch/arm/plat-omap/include/plat/iovmm.h |   12 +++---
>  drivers/iommu/omap-iommu.c              |   58 ++++++++++++++-----------------
>  drivers/iommu/omap-iovmm.c              |   31 +++++++++++------
>  drivers/media/video/omap3isp/isp.c      |   30 +++-------------
>  drivers/media/video/omap3isp/isp.h      |    2 -
>  drivers/media/video/omap3isp/ispccdc.c  |   18 +++++-----
>  drivers/media/video/omap3isp/ispstat.c  |    8 ++--
>  drivers/media/video/omap3isp/ispvideo.c |    4 +-
>  10 files changed, 107 insertions(+), 94 deletions(-)

Pulled into arm/omap, thanks Ohad.

-- 
AMD Operating System Research Center

Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632

Re: [RFC 0/5] OMAP groundwork for IOMMU-based DMA API

[Roedel, Joerg]

On Mon, Dec 05, 2011 at 04:21:21PM +0200, Ohad Ben-Cohen wrote:
> Hi Joerg,
> 
> On Tue, Nov 15, 2011 at 12:39 PM, Roedel, Joerg <Joerg.Roedel@amd.com> wrote:
> > On Sun, Sep 25, 2011 at 06:58:52AM -0400, Ohad Ben-Cohen wrote:
> >> Ohad Ben-Cohen (5):
> >>   ARM: dev_archdata: add private iommu extension
> >>   ARM: OMAP: omap_device: add a method to set iommu private archdata
> >>   ARM: OMAP: iommu: declare a private iommu binding struct
> >>   ARM: OMAP3: bind omap3isp_device to its iommu device
> >>   iommu/omap: eliminate the public omap_find_iommu_device() method
> >
> > It doesn't apply cleanly, can you please rebase the code, collect the
> > Acked-by's and resend?
> 
> I have collected Tony's and Laurent's Acked-by's and amended them to
> the commit logs.
> 
> I have also made sure it applies cleanly to a recent 3.2, and tested
> it with OMAP4/remoteproc. I couldn't test it with omap3isp though,
> because I'm gated by (what looks like a) 3.2 omap3isp regression (see
> http://www.spinics.net/lists/linux-omap/msg60510.html). I did test it
> of course with omap3isp and 3.1, so I don't expect any omap3isp/iommu
> issues with these patches. Anyway, when the omap3isp issue will be
> resolved I'll make sure there isn't any iommu regression.
> 
> Please pull, thanks a lot!
> 
> The following changes since commit cfcfc9eca2bcbd26a8e206baeb005b055dbf8e37:
> 
>   Linux 3.2-rc2 (2011-11-15 15:02:59 -0200)
> 
> are available in the git repository at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/ohad/linux.git for-joerg
> 
> Ohad Ben-Cohen (3):
>       ARM: OMAP: iommu: declare a private iommu binding struct
>       ARM: OMAP3: bind omap3isp_device to its iommu device
>       iommu/omap: eliminate the public omap_find_iommu_device() method
> 
>  arch/arm/mach-omap2/devices.c           |    7 ++++
>  arch/arm/plat-omap/include/plat/iommu.h |   31 +++++++++++++++--
>  arch/arm/plat-omap/include/plat/iovmm.h |   12 +++---
>  drivers/iommu/omap-iommu.c              |   58 ++++++++++++++-----------------
>  drivers/iommu/omap-iovmm.c              |   31 +++++++++++------
>  drivers/media/video/omap3isp/isp.c      |   30 +++-------------
>  drivers/media/video/omap3isp/isp.h      |    2 -
>  drivers/media/video/omap3isp/ispccdc.c  |   18 +++++-----
>  drivers/media/video/omap3isp/ispstat.c  |    8 ++--
>  drivers/media/video/omap3isp/ispvideo.c |    4 +-
>  10 files changed, 107 insertions(+), 94 deletions(-)

Pulled into arm/omap, thanks Ohad.

-- 
AMD Operating System Research Center

Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632