linux-kernel - Re: [PATCH v3 4/4] OMAP3/4: iommu: adapt to runtime pm

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 2 Nov 2011 19:16:50 +0900
From:	MyungJoo Ham <myungjoo.ham@...il.com>
To:	Omar Ramirez Luna <omar.ramirez@...com>
Cc:	Tony Lindgren <tony@...mide.com>,
	Benoit Cousson <b-cousson@...com>,
	Ohad Ben-Cohen <ohad@...ery.com>,
	Russell King <linux@....linux.org.uk>,
	lkml <linux-kernel@...r.kernel.org>,
	Laurent Pinchart <laurent.pinchart@...asonboard.com>,
	lo <linux-omap@...r.kernel.org>,
	lak <linux-arm-kernel@...ts.infradead.org>,
	lm <linux-media@...r.kernel.org>
Subject: Re: [PATCH v3 4/4] OMAP3/4: iommu: adapt to runtime pm

On Wed, Nov 2, 2011 at 7:15 AM, Omar Ramirez Luna <omar.ramirez@...com> wrote:
> Use runtime PM functionality interfaced with hwmod enable/idle
> functions, to replace direct clock operations, reset and sysconfig
> handling.
>
> Tidspbridge uses a macro removed with this patch, for now the value
> is hardcoded to avoid breaking compilation.
>
> Signed-off-by: Omar Ramirez Luna <omar.ramirez@...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                        |   46 ++++++++-------------
>  drivers/staging/tidspbridge/core/tiomap3430_pwr.c |    2 +-
>  6 files changed, 19 insertions(+), 51 deletions(-)
>
> diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
> index bbbf747..3c55be0 100644
> --- a/drivers/iommu/omap-iommu.c
> +++ b/drivers/iommu/omap-iommu.c
> @@ -123,11 +123,11 @@ static int iommu_enable(struct omap_iommu *obj)
>        if (!arch_iommu)
>                return -ENODEV;
>
> -       clk_enable(obj->clk);
> +       pm_runtime_enable(obj->dev);
> +       pm_runtime_get_sync(obj->dev);
>
>        err = arch_iommu->enable(obj);
>
> -       clk_disable(obj->clk);
>        return err;
>  }
>
> @@ -136,11 +136,10 @@ 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_sync(obj->dev);
> +       pm_runtime_disable(obj->dev);
>  }

Hello Omar,


I'm just curious here... Is there any reason to do
pm_runtime_enable/disable at iommu_enable/iommu_disable which are
called by iommu_attach/detach?
I thought that normally, ideal locations of pm_runtime_enable/disable
for such devices are in probe/remove() because it assures that the
device is suspended after the probe.
It seems that the device might be kept on after probe and before the
first iommu_attach if it is default-on.


Thanks,
MyungJoo


-- 
MyungJoo Ham, Ph.D.
Mobile Software Platform Lab, DMC Business, Samsung Electronics
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/