Re: [PATCH v4 4/4] OMAP3/4: iommu: adapt to runtime pm

2012-01-05 Thread Ramirez Luna, Omar 
On Tue, Dec 27, 2011 at 3:41 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
 On Sun, Dec 25, 2011 at 2:03 AM, Ramirez Luna, Omar omar.rami...@ti.com 
 wrote:
 On Fri, Dec 23, 2011 at 11:04 AM, Felipe Contreras
 felipe.contre...@gmail.com wrote:
 Which omap-iommu? The platform driver, or the device stuff? The device
 stuff is always built-in, but not the platform driver
 (drivers/iommu/omap-iommu.c), that can be a module.

 Both, I can't recall exactly when it changed (prior to being moved to
 drivers/iommu it could be built as a module), but now
 CONFIG_OMAP_IOMMU is boolean type.

 I see. Still, it looks like the proper way to use the API is to call
 _enable() on the platform driver.

I'm sorry, I don't seem to follow... you want _enable in platform
driver, and you call drivers/iommu/omap-iommu.c the platform driver...

And that is precisely where pm_runtime_enable() is, no?

Regards,

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

Re: [PATCH v4 4/4] OMAP3/4: iommu: adapt to runtime pm

2011-12-27 Thread Felipe Contreras 
On Sun, Dec 25, 2011 at 2:03 AM, Ramirez Luna, Omar omar.rami...@ti.com wrote:
 On Fri, Dec 23, 2011 at 11:04 AM, Felipe Contreras
 felipe.contre...@gmail.com wrote:
 Which omap-iommu? The platform driver, or the device stuff? The device
 stuff is always built-in, but not the platform driver
 (drivers/iommu/omap-iommu.c), that can be a module.

 Both, I can't recall exactly when it changed (prior to being moved to
 drivers/iommu it could be built as a module), but now
 CONFIG_OMAP_IOMMU is boolean type.

I see. Still, it looks like the proper way to use the API is to call
_enable() on the platform driver.

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 4/4] OMAP3/4: iommu: adapt to runtime pm

2011-12-24 Thread Ramirez Luna, Omar 
On Fri, Dec 23, 2011 at 11:04 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
 Which omap-iommu? The platform driver, or the device stuff? The device
 stuff is always built-in, but not the platform driver
 (drivers/iommu/omap-iommu.c), that can be a module.

Both, I can't recall exactly when it changed (prior to being moved to
drivers/iommu it could be built as a module), but now
CONFIG_OMAP_IOMMU is boolean type.

Regards,

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

Re: [PATCH v4 4/4] OMAP3/4: iommu: adapt to runtime pm

2011-12-23 Thread Ramirez Luna, Omar 
On Mon, Dec 19, 2011 at 10:27 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
 On Fri, Dec 16, 2011 at 5:18 AM, Ramirez Luna, Omar omar.rami...@ti.com 
 wrote:
 On Thu, Dec 15, 2011 at 6:53 PM, Felipe Contreras
 felipe.contre...@gmail.com wrote:
 On Thu, Dec 15, 2011 at 6:18 AM, Omar Ramirez Luna omar.rami...@ti.com 
 wrote:
 Use runtime PM functionality interfaced with hwmod enable/idle
 functions, to replace direct clock operations, reset and sysconfig
 handling.

 Removed clk handling during interrupt, given that in order to receive one,
 the device should be powered on in advance. Now doing pm_runtime_get/put
 on iommu_enable/disable so it doesn't rely on others to keep the clocks on.

 Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
 ---
  arch/arm/mach-omap2/iommu2.c             |   17 ---
  arch/arm/mach-omap2/omap-iommu.c         |    1 -
  arch/arm/plat-omap/include/plat/iommu.h  |    2 -
  arch/arm/plat-omap/include/plat/iommu2.h |    2 -
  drivers/iommu/omap-iommu.c               |   44 
 -
  5 files changed, 18 insertions(+), 48 deletions(-)

 Shouldn't pm_runtime_enable() be called in omap_iommu_init(), and
 omap_iommu_probe() call pm_runtime_get_sync()/put() on the sections
 where the device should be active?

 omap_iommu_init is called on module init however omap_iommu_probe is
 called by driver instance (isp, iva), on probe pm_runtime_enable
 activates runtime for both isp and iva devices, one at a time.

 Yes, but omap_iommu_init() will *always* be called at boot time and
 will register the data for all the devices.

There are 2 omap_iommu_init :/ Thought you were talking about the one
in drivers/iommu/omap-iommu.c.

 If the 'iommu' module is
 never loaded, then the devices will remain active the whole time.

oma-iommu is meant to be built-in as part of the kernel, there is no
option for module anymore.

Regards,

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

Re: [PATCH v4 4/4] OMAP3/4: iommu: adapt to runtime pm

2011-12-23 Thread Felipe Contreras 
On Fri, Dec 23, 2011 at 6:30 PM, Ramirez Luna, Omar omar.rami...@ti.com wrote:
 On Mon, Dec 19, 2011 at 10:27 AM, Felipe Contreras
 felipe.contre...@gmail.com wrote:
 On Fri, Dec 16, 2011 at 5:18 AM, Ramirez Luna, Omar omar.rami...@ti.com 
 wrote:
 On Thu, Dec 15, 2011 at 6:53 PM, Felipe Contreras
 felipe.contre...@gmail.com wrote:
 On Thu, Dec 15, 2011 at 6:18 AM, Omar Ramirez Luna omar.rami...@ti.com 
 wrote:
 Use runtime PM functionality interfaced with hwmod enable/idle
 functions, to replace direct clock operations, reset and sysconfig
 handling.

 Removed clk handling during interrupt, given that in order to receive one,
 the device should be powered on in advance. Now doing pm_runtime_get/put
 on iommu_enable/disable so it doesn't rely on others to keep the clocks 
 on.

 Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
 ---
  arch/arm/mach-omap2/iommu2.c             |   17 ---
  arch/arm/mach-omap2/omap-iommu.c         |    1 -
  arch/arm/plat-omap/include/plat/iommu.h  |    2 -
  arch/arm/plat-omap/include/plat/iommu2.h |    2 -
  drivers/iommu/omap-iommu.c               |   44 
 -
  5 files changed, 18 insertions(+), 48 deletions(-)

 Shouldn't pm_runtime_enable() be called in omap_iommu_init(), and
 omap_iommu_probe() call pm_runtime_get_sync()/put() on the sections
 where the device should be active?

 omap_iommu_init is called on module init however omap_iommu_probe is
 called by driver instance (isp, iva), on probe pm_runtime_enable
 activates runtime for both isp and iva devices, one at a time.

 Yes, but omap_iommu_init() will *always* be called at boot time and
 will register the data for all the devices.

 There are 2 omap_iommu_init :/ Thought you were talking about the one
 in drivers/iommu/omap-iommu.c.

 If the 'iommu' module is
 never loaded, then the devices will remain active the whole time.

 oma-iommu is meant to be built-in as part of the kernel, there is no
 option for module anymore.

Which omap-iommu? The platform driver, or the device stuff? The device
stuff is always built-in, but not the platform driver
(drivers/iommu/omap-iommu.c), that can be a module.

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 4/4] OMAP3/4: iommu: adapt to runtime pm

2011-12-19 Thread Felipe Contreras 
On Fri, Dec 16, 2011 at 5:18 AM, Ramirez Luna, Omar omar.rami...@ti.com wrote:
 On Thu, Dec 15, 2011 at 6:53 PM, Felipe Contreras
 felipe.contre...@gmail.com wrote:
 On Thu, Dec 15, 2011 at 6:18 AM, Omar Ramirez Luna omar.rami...@ti.com 
 wrote:
 Use runtime PM functionality interfaced with hwmod enable/idle
 functions, to replace direct clock operations, reset and sysconfig
 handling.

 Removed clk handling during interrupt, given that in order to receive one,
 the device should be powered on in advance. Now doing pm_runtime_get/put
 on iommu_enable/disable so it doesn't rely on others to keep the clocks on.

 Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
 ---
  arch/arm/mach-omap2/iommu2.c             |   17 ---
  arch/arm/mach-omap2/omap-iommu.c         |    1 -
  arch/arm/plat-omap/include/plat/iommu.h  |    2 -
  arch/arm/plat-omap/include/plat/iommu2.h |    2 -
  drivers/iommu/omap-iommu.c               |   44 
 -
  5 files changed, 18 insertions(+), 48 deletions(-)

 Shouldn't pm_runtime_enable() be called in omap_iommu_init(), and
 omap_iommu_probe() call pm_runtime_get_sync()/put() on the sections
 where the device should be active?

 omap_iommu_init is called on module init however omap_iommu_probe is
 called by driver instance (isp, iva), on probe pm_runtime_enable
 activates runtime for both isp and iva devices, one at a time.

Yes, but omap_iommu_init() will *always* be called at boot time and
will register the data for all the devices. If the 'iommu' module is
never loaded, then the devices will remain active the whole time.

Maybe Paul or somebody with better knowledge of the pm runtime
framework can clarify this.

Cheers.

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 4/4] OMAP3/4: iommu: adapt to runtime pm

2011-12-16 Thread Tony Lindgren 
* Omar Ramirez Luna omar.rami...@ti.com [111214 19:47]:
 Use runtime PM functionality interfaced with hwmod enable/idle
 functions, to replace direct clock operations, reset and sysconfig
 handling.
 
 Removed clk handling during interrupt, given that in order to receive one,
 the device should be powered on in advance. Now doing pm_runtime_get/put
 on iommu_enable/disable so it doesn't rely on others to keep the clocks on.
 
 Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com

The omap parts look OK to me for Ohad to queue:

Acked-by: Tony Lindgren t...@atomide.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 4/4] OMAP3/4: iommu: adapt to runtime pm

2011-12-15 Thread Felipe Contreras 
On Thu, Dec 15, 2011 at 6:18 AM, Omar Ramirez Luna omar.rami...@ti.com wrote:
 @@ -123,11 +123,10 @@ static int iommu_enable(struct omap_iommu *obj)
        if (!arch_iommu)
                return -ENODEV;

 -       clk_enable(obj-clk);
 +       pm_runtime_get_sync(obj-dev);

        err = arch_iommu-enable(obj);

 -       clk_disable(obj-clk);
        return err;
  }

Hmm, this is called on omap_iommu_attach, and iommu_disable is not
called until omap_iommu_detach, so this means the device will never
sleep. Why don't you call pm_runtime_put() instead of clk_disable()?

All the rest of the calls to pm_runtime_get/put after this are
basically no-ops, because the count will never go below 1.

You mention some irq issues, but could it be due to some bad clocks in
the hwmod data?

 @@ -136,11 +135,9 @@ static void iommu_disable(struct omap_iommu *obj)
        if (!obj)
                return;

 -       clk_enable(obj-clk);
 -
        arch_iommu-disable(obj);

 -       clk_disable(obj-clk);
 +       pm_runtime_put(obj-dev);
  }

  /*
 @@ -263,7 +260,7 @@ static int load_iotlb_entry(struct omap_iommu *obj, 
 struct iotlb_entry *e)
        if (!obj || !obj-nr_tlb_entries || !e)
                return -EINVAL;

 -       clk_enable(obj-clk);
 +       pm_runtime_get_sync(obj-dev);

        iotlb_lock_get(obj, l);
        if (l.base == obj-nr_tlb_entries) {
 @@ -293,7 +290,7 @@ static int load_iotlb_entry(struct omap_iommu *obj, 
 struct iotlb_entry *e)

        cr = iotlb_alloc_cr(obj, e);
        if (IS_ERR(cr)) {
 -               clk_disable(obj-clk);
 +               pm_runtime_put(obj-dev);
                return PTR_ERR(cr);
        }

 @@ -307,7 +304,7 @@ static int load_iotlb_entry(struct omap_iommu *obj, 
 struct iotlb_entry *e)
                l.vict = l.base;
        iotlb_lock_set(obj, l);
  out:
 -       clk_disable(obj-clk);
 +       pm_runtime_put(obj-dev);
        return err;
  }

 @@ -337,7 +334,7 @@ static void flush_iotlb_page(struct omap_iommu *obj, u32 
 da)
        int i;
        struct cr_regs cr;

 -       clk_enable(obj-clk);
 +       pm_runtime_get_sync(obj-dev);

        for_each_iotlb_cr(obj, obj-nr_tlb_entries, i, cr) {
                u32 start;
 @@ -356,7 +353,7 @@ static void flush_iotlb_page(struct omap_iommu *obj, u32 
 da)
                        iommu_write_reg(obj, 1, MMU_FLUSH_ENTRY);
                }
        }
 -       clk_disable(obj-clk);
 +       pm_runtime_put(obj-dev);

        if (i == obj-nr_tlb_entries)
                dev_dbg(obj-dev, %s: no page for %08x\n, __func__, da);
 @@ -370,7 +367,7 @@ static void flush_iotlb_all(struct omap_iommu *obj)
  {
        struct iotlb_lock l;

 -       clk_enable(obj-clk);
 +       pm_runtime_get_sync(obj-dev);

        l.base = 0;
        l.vict = 0;
 @@ -378,7 +375,7 @@ static void flush_iotlb_all(struct omap_iommu *obj)

        iommu_write_reg(obj, 1, MMU_GFLUSH);

 -       clk_disable(obj-clk);
 +       pm_runtime_put(obj-dev);
  }

  #if defined(CONFIG_OMAP_IOMMU_DEBUG) || 
 defined(CONFIG_OMAP_IOMMU_DEBUG_MODULE)
 @@ -388,11 +385,11 @@ ssize_t omap_iommu_dump_ctx(struct omap_iommu *obj, 
 char *buf, ssize_t bytes)
        if (!obj || !buf)
                return -EINVAL;

 -       clk_enable(obj-clk);
 +       pm_runtime_get_sync(obj-dev);

        bytes = arch_iommu-dump_ctx(obj, buf, bytes);

 -       clk_disable(obj-clk);
 +       pm_runtime_put(obj-dev);

        return bytes;
  }
 @@ -406,7 +403,7 @@ __dump_tlb_entries(struct omap_iommu *obj, struct cr_regs 
 *crs, int num)
        struct cr_regs tmp;
        struct cr_regs *p = crs;

 -       clk_enable(obj-clk);
 +       pm_runtime_get_sync(obj-dev);
        iotlb_lock_get(obj, saved);

        for_each_iotlb_cr(obj, num, i, tmp) {
 @@ -416,7 +413,7 @@ __dump_tlb_entries(struct omap_iommu *obj, struct cr_regs 
 *crs, int num)
        }

        iotlb_lock_set(obj, saved);
 -       clk_disable(obj-clk);
 +       pm_runtime_put(obj-dev);

        return  p - crs;
  }
 @@ -780,9 +777,7 @@ static irqreturn_t iommu_fault_handler(int irq, void 
 *data)
        if (!obj-refcount)
                return IRQ_NONE;

 -       clk_enable(obj-clk);
        errs = iommu_report_fault(obj, da);
 -       clk_disable(obj-clk);

Why?

        if (errs == 0)
                return IRQ_HANDLED;

 @@ -920,10 +915,6 @@ static int __devinit omap_iommu_probe(struct 
 platform_device *pdev)
        if (!obj)
                return -ENOMEM;

 -       obj-clk = clk_get(pdev-dev, pdata-clk_name);
 -       if (IS_ERR(obj-clk))
 -               goto err_clk;
 -
        obj-nr_tlb_entries = pdata-nr_tlb_entries;
        obj-name = pdata-name;
        obj-dev = pdev-dev;
 @@ -966,6 +957,8 @@ static int __devinit omap_iommu_probe(struct 
 platform_device *pdev)
                goto err_irq;
        platform_set_drvdata(pdev, obj);

 +       pm_runtime_enable(obj-dev);
 +
        dev_info(pdev-dev, %s registered\n, obj-name);
        return 0;

 @@ -974,8 +967,6 @@ err_irq:
  err_ioremap:
        

Re: [PATCH v4 4/4] OMAP3/4: iommu: adapt to runtime pm

2011-12-15 Thread Felipe Contreras 
On Thu, Dec 15, 2011 at 6:18 AM, Omar Ramirez Luna omar.rami...@ti.com wrote:
 Use runtime PM functionality interfaced with hwmod enable/idle
 functions, to replace direct clock operations, reset and sysconfig
 handling.

 Removed clk handling during interrupt, given that in order to receive one,
 the device should be powered on in advance. Now doing pm_runtime_get/put
 on iommu_enable/disable so it doesn't rely on others to keep the clocks on.

 Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
 ---
  arch/arm/mach-omap2/iommu2.c             |   17 ---
  arch/arm/mach-omap2/omap-iommu.c         |    1 -
  arch/arm/plat-omap/include/plat/iommu.h  |    2 -
  arch/arm/plat-omap/include/plat/iommu2.h |    2 -
  drivers/iommu/omap-iommu.c               |   44 -
  5 files changed, 18 insertions(+), 48 deletions(-)

Shouldn't pm_runtime_enable() be called in omap_iommu_init(), and
omap_iommu_probe() call pm_runtime_get_sync()/put() on the sections
where the device should be active?

Cheers.

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 4/4] OMAP3/4: iommu: adapt to runtime pm

2011-12-15 Thread Ramirez Luna, Omar 
On Thu, Dec 15, 2011 at 6:33 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
 On Thu, Dec 15, 2011 at 6:18 AM, Omar Ramirez Luna omar.rami...@ti.com 
 wrote:
 @@ -123,11 +123,10 @@ static int iommu_enable(struct omap_iommu *obj)
        if (!arch_iommu)
                return -ENODEV;

 -       clk_enable(obj-clk);
 +       pm_runtime_get_sync(obj-dev);

        err = arch_iommu-enable(obj);

 -       clk_disable(obj-clk);
        return err;
  }

 Hmm, this is called on omap_iommu_attach, and iommu_disable is not
 called until omap_iommu_detach, so this means the device will never
 sleep. Why don't you call pm_runtime_put() instead of clk_disable()?

Here once you call pm_runtime_put, the hwmod should turn off iva2_ck
leaving device unpowered, not usable if it is part of an independent
module and that module is still awake, but since the module clock
feeds both the dsp and the mmu this doesn't occur. However might be
possible if there is a specific clock to feed the mmu and another for
the mmu user.

In theory iommu should be independent on handling its clock resources,
take tidspbridge, it powers iva2_clk which indirectly powers iva_mmu,
so as long as the dsp is powered and using the mmu (omap_iommu_attach)
the iommu should be ON, once you omap_iommu_detach means that the
device is no longer using the iommu and can be put to sleep.

This could be helpful if your main processor can go to sleep
independently of other processors, say you attach the iommu and leave
the dsp doing calculations and memory accesses through mmu while the
main processor decides to enter sleep.

 All the rest of the calls to pm_runtime_get/put after this are
 basically no-ops, because the count will never go below 1.

I didn't try but without calling iommu_attach the other functions that
use pm_runtime_get/put can still be called as they are exported
symbols. I believe omap-iommu-debug.c does something like this to dump
stuff. This should be cleaned up/audited, IMHO, but it doesn't seem to
belong to this conversion series.

 You mention some irq issues, but could it be due to some bad clocks in
 the hwmod data?

There are no issues with irqs, just a weird case, see below...

...
 @@ -780,9 +777,7 @@ static irqreturn_t iommu_fault_handler(int irq, void 
 *data)
        if (!obj-refcount)
                return IRQ_NONE;

 -       clk_enable(obj-clk);
        errs = iommu_report_fault(obj, da);
 -       clk_disable(obj-clk);

 Why?

In order to get an irq from the mmu, the mmu should be functional and
have a clock, but iommu_enable used to enable and disable the clock.

In the end you are able to get an irq because someone else
(tidspbridge) has the mmu indirectly powered (since they share the
same clock), I felt this shouldn't be and the iommu should handle its
own clocks even if they are shared with other modules.

Hence iommu_enable does pm_runtime_get for the life time of the user of the mmu.

...
 @@ -996,7 +987,8 @@ static int __devexit omap_iommu_remove(struct 
 platform_device *pdev)
        release_mem_region(res-start, resource_size(res));
        iounmap(obj-regbase);

 -       clk_put(obj-clk);
 +       pm_runtime_disable(obj-dev);

 I'm not sure if this is needed; you want to resume the driver? AFAICS
 kfree will take care of that _without_ resuming.

No, the driver should resume only if there are outstanding wake up
requests, right? I don't seem to get this question.

Thanks,

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

Re: [PATCH v4 4/4] OMAP3/4: iommu: adapt to runtime pm

2011-12-15 Thread Ramirez Luna, Omar 
On Thu, Dec 15, 2011 at 6:53 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
 On Thu, Dec 15, 2011 at 6:18 AM, Omar Ramirez Luna omar.rami...@ti.com 
 wrote:
 Use runtime PM functionality interfaced with hwmod enable/idle
 functions, to replace direct clock operations, reset and sysconfig
 handling.

 Removed clk handling during interrupt, given that in order to receive one,
 the device should be powered on in advance. Now doing pm_runtime_get/put
 on iommu_enable/disable so it doesn't rely on others to keep the clocks on.

 Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
 ---
  arch/arm/mach-omap2/iommu2.c             |   17 ---
  arch/arm/mach-omap2/omap-iommu.c         |    1 -
  arch/arm/plat-omap/include/plat/iommu.h  |    2 -
  arch/arm/plat-omap/include/plat/iommu2.h |    2 -
  drivers/iommu/omap-iommu.c               |   44 
 -
  5 files changed, 18 insertions(+), 48 deletions(-)

 Shouldn't pm_runtime_enable() be called in omap_iommu_init(), and
 omap_iommu_probe() call pm_runtime_get_sync()/put() on the sections
 where the device should be active?

omap_iommu_init is called on module init however omap_iommu_probe is
called by driver instance (isp, iva), on probe pm_runtime_enable
activates runtime for both isp and iva devices, one at a time.

Regards,

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

[PATCH v4 4/4] OMAP3/4: iommu: adapt to runtime pm

2011-12-14 Thread Omar Ramirez Luna 
Use runtime PM functionality interfaced with hwmod enable/idle
functions, to replace direct clock operations, reset and sysconfig
handling.

Removed clk handling during interrupt, given that in order to receive one,
the device should be powered on in advance. Now doing pm_runtime_get/put
on iommu_enable/disable so it doesn't rely on others to keep the clocks on.

Signed-off-by: Omar Ramirez Luna omar.rami...@ti.com
---
 arch/arm/mach-omap2/iommu2.c |   17 ---
 arch/arm/mach-omap2/omap-iommu.c |1 -
 arch/arm/plat-omap/include/plat/iommu.h  |2 -
 arch/arm/plat-omap/include/plat/iommu2.h |2 -
 drivers/iommu/omap-iommu.c   |   44 -
 5 files changed, 18 insertions(+), 48 deletions(-)

diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
index 35cab47..3e47786 100644
--- a/arch/arm/mach-omap2/iommu2.c
+++ b/arch/arm/mach-omap2/iommu2.c
@@ -25,15 +25,6 @@
  */
 #define IOMMU_ARCH_VERSION 0x0011
 
-/* SYSCONF */
-#define MMU_SYS_IDLE_SHIFT 3
-#define MMU_SYS_IDLE_FORCE (0  MMU_SYS_IDLE_SHIFT)
-#define MMU_SYS_IDLE_NONE  (1  MMU_SYS_IDLE_SHIFT)
-#define MMU_SYS_IDLE_SMART (2  MMU_SYS_IDLE_SHIFT)
-#define MMU_SYS_IDLE_MASK  (3  MMU_SYS_IDLE_SHIFT)
-
-#define MMU_SYS_AUTOIDLE   1
-
 /* IRQSTATUS  IRQENABLE */
 #define MMU_IRQ_MULTIHITFAULT  (1  4)
 #define MMU_IRQ_TABLEWALKFAULT (1  3)
@@ -96,11 +87,6 @@ static int omap2_iommu_enable(struct omap_iommu *obj)
dev_info(obj-dev, %s: version %d.%d\n, obj-name,
 (l  4)  0xf, l  0xf);
 
-   l = iommu_read_reg(obj, MMU_SYSCONFIG);
-   l = ~MMU_SYS_IDLE_MASK;
-   l |= (MMU_SYS_IDLE_SMART | MMU_SYS_AUTOIDLE);
-   iommu_write_reg(obj, l, MMU_SYSCONFIG);
-
iommu_write_reg(obj, pa, MMU_TTB);
 
__iommu_set_twl(obj, true);
@@ -114,7 +100,6 @@ static void omap2_iommu_disable(struct omap_iommu *obj)
 
l = ~MMU_CNTL_MASK;
iommu_write_reg(obj, l, MMU_CNTL);
-   iommu_write_reg(obj, MMU_SYS_IDLE_FORCE, MMU_SYSCONFIG);
 
dev_dbg(obj-dev, %s is shutting down\n, obj-name);
 }
@@ -243,8 +228,6 @@ omap2_iommu_dump_ctx(struct omap_iommu *obj, char *buf, 
ssize_t len)
char *p = buf;
 
pr_reg(REVISION);
-   pr_reg(SYSCONFIG);
-   pr_reg(SYSSTATUS);
pr_reg(IRQSTATUS);
pr_reg(IRQENABLE);
pr_reg(WALKING_ST);
diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index 6da05e1..99ed583 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -27,7 +27,6 @@ static int __init omap_iommu_dev_init(struct omap_hwmod *oh, 
void *unused)
static int i;
 
pdata.name = oh-name;
-   pdata.clk_name = oh-main_clk;
pdata.nr_tlb_entries = a-nr_tlb_entries;
pdata.da_start = a-da_start;
pdata.da_end = a-da_end;
diff --git a/arch/arm/plat-omap/include/plat/iommu.h 
b/arch/arm/plat-omap/include/plat/iommu.h
index c5b23b8..46d2b9a 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -28,7 +28,6 @@ struct iotlb_entry {
 struct omap_iommu {
const char  *name;
struct module   *owner;
-   struct clk  *clk;
void __iomem*regbase;
struct device   *dev;
void*isr_priv;
@@ -118,7 +117,6 @@ struct omap_mmu_dev_attr {
 
 struct iommu_platform_data {
const char *name;
-   const char *clk_name;
int nr_tlb_entries;
u32 da_start;
u32 da_end;
diff --git a/arch/arm/plat-omap/include/plat/iommu2.h 
b/arch/arm/plat-omap/include/plat/iommu2.h
index d4116b5..1579694 100644
--- a/arch/arm/plat-omap/include/plat/iommu2.h
+++ b/arch/arm/plat-omap/include/plat/iommu2.h
@@ -19,8 +19,6 @@
  * MMU Register offsets
  */
 #define MMU_REVISION   0x00
-#define MMU_SYSCONFIG  0x10
-#define MMU_SYSSTATUS  0x14
 #define MMU_IRQSTATUS  0x18
 #define MMU_IRQENABLE  0x1c
 #define MMU_WALKING_ST 0x40
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 78e62b1..e8ae36c 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -16,11 +16,11 @@
 #include linux/slab.h
 #include linux/interrupt.h
 #include linux/ioport.h
-#include linux/clk.h
 #include linux/platform_device.h
 #include linux/iommu.h
 #include linux/mutex.h
 #include linux/spinlock.h
+#include linux/pm_runtime.h
 
 #include asm/cacheflush.h
 
@@ -123,11 +123,10 @@ static int iommu_enable(struct omap_iommu *obj)
if (!arch_iommu)
return -ENODEV;
 
-   clk_enable(obj-clk);
+   pm_runtime_get_sync(obj-dev);
 
err = arch_iommu-enable(obj);
 
-   clk_disable(obj-clk);
return err;
 }
 
@@ -136,11 +135,9 @@ static void iommu_disable(struct omap_iommu *obj)
if (!obj)
return;
 
-   clk_enable(obj-clk);
-