Re: [PATCH v4 08/13] iommu/rockchip: Control clocks needed to access the IOMMU

[JeffyChen]

Hi guys,

On 01/25/2018 06:24 PM, JeffyChen wrote:

On 01/25/2018 05:42 PM, Randy Li wrote:




confirmed with Simon, there might be some iommus don't have a pd, and

We use the pd to control the NIU node(not on upstream), without a pd or
fake pd, none of the platform would work.

after talked offline, it's possible to have iommu without pd in upstream
kernel(and chromeos kernel), but on our internal kernel, the drivers
would require pd(or fake pd) to reset modules when error happens.

anyway, i think that means we do need clock control here.


found another reason to not depend on pd to control clocks.

currently we are using pd's pm_clk to keep clocks enabled during power 
on. but in our pd binding doc, that is not needed:
- clocks (optional): phandles to clocks which need to be enabled while 
power domain

switches state.

confirmed with Caesar, the pm_clk only required for some old 
chips(rk3288 for example) due to hardware issue.


and i tested my chromebook kevin(rk3399), it works well after remove the 
pm_clk:


+++ b/drivers/soc/rockchip/pm_domains.c
@@ -478,7 +478,6 @@ static int rockchip_pm_add_one_domain(struct 
rockchip_pmu *pmu,

pd->genpd.power_on = rockchip_pd_power_on;
pd->genpd.attach_dev = rockchip_pd_attach_dev;
pd->genpd.detach_dev = rockchip_pd_detach_dev;
-   pd->genpd.flags = GENPD_FLAG_PM_CLK;

will do more tests and send patch tomorrow.




the CONFIG_PM could be disabled.I am hard to believe a modern platform
can work without that.

so it might be better to control clocks in iommu driver itself.

I won't
insist how the version of the iommu patch on the upstream, I
just post an idea here.
The version for kernel 4.4 is under internal review, the implementation
has been modified many times.

I would suggest the managing clocks in pd is a more easy way and don't
need to spare those thing in two places.

Re: [PATCH v4 08/13] iommu/rockchip: Control clocks needed to access the IOMMU

[JeffyChen]

Hi guys,

On 01/25/2018 06:24 PM, JeffyChen wrote:

On 01/25/2018 05:42 PM, Randy Li wrote:




confirmed with Simon, there might be some iommus don't have a pd, and

We use the pd to control the NIU node(not on upstream), without a pd or
fake pd, none of the platform would work.

after talked offline, it's possible to have iommu without pd in upstream
kernel(and chromeos kernel), but on our internal kernel, the drivers
would require pd(or fake pd) to reset modules when error happens.

anyway, i think that means we do need clock control here.


found another reason to not depend on pd to control clocks.

currently we are using pd's pm_clk to keep clocks enabled during power 
on. but in our pd binding doc, that is not needed:
- clocks (optional): phandles to clocks which need to be enabled while 
power domain

switches state.

confirmed with Caesar, the pm_clk only required for some old 
chips(rk3288 for example) due to hardware issue.


and i tested my chromebook kevin(rk3399), it works well after remove the 
pm_clk:


+++ b/drivers/soc/rockchip/pm_domains.c
@@ -478,7 +478,6 @@ static int rockchip_pm_add_one_domain(struct 
rockchip_pmu *pmu,

pd->genpd.power_on = rockchip_pd_power_on;
pd->genpd.attach_dev = rockchip_pd_attach_dev;
pd->genpd.detach_dev = rockchip_pd_detach_dev;
-   pd->genpd.flags = GENPD_FLAG_PM_CLK;

will do more tests and send patch tomorrow.




the CONFIG_PM could be disabled.I am hard to believe a modern platform
can work without that.

so it might be better to control clocks in iommu driver itself.

I won't
insist how the version of the iommu patch on the upstream, I
just post an idea here.
The version for kernel 4.4 is under internal review, the implementation
has been modified many times.

I would suggest the managing clocks in pd is a more easy way and don't
need to spare those thing in two places.

Re: [PATCH v4 08/13] iommu/rockchip: Control clocks needed to access the IOMMU

[JeffyChen]

On 01/25/2018 05:42 PM, Randy Li wrote:




confirmed with Simon, there might be some iommus don't have a pd, and

We use the pd to control the NIU node(not on upstream), without a pd or
fake pd, none of the platform would work.
after talked offline, it's possible to have iommu without pd in upstream 
kernel(and chromeos kernel), but on our internal kernel, the drivers 
would require pd(or fake pd) to reset modules when error happens.


anyway, i think that means we do need clock control here.


the CONFIG_PM could be disabled.I am hard to believe a modern platform
can work without that.

so it might be better to control clocks in iommu driver itself.

I won't
insist how the version of the iommu patch on the upstream, I
just post an idea here.
The version for kernel 4.4 is under internal review, the implementation
has been modified many times.

I would suggest the managing clocks in pd is a more easy way and don't
need to spare those thing in two places.

Re: [PATCH v4 08/13] iommu/rockchip: Control clocks needed to access the IOMMU

[JeffyChen]

On 01/25/2018 05:42 PM, Randy Li wrote:




confirmed with Simon, there might be some iommus don't have a pd, and

We use the pd to control the NIU node(not on upstream), without a pd or
fake pd, none of the platform would work.
after talked offline, it's possible to have iommu without pd in upstream 
kernel(and chromeos kernel), but on our internal kernel, the drivers 
would require pd(or fake pd) to reset modules when error happens.


anyway, i think that means we do need clock control here.


the CONFIG_PM could be disabled.I am hard to believe a modern platform
can work without that.

so it might be better to control clocks in iommu driver itself.

I won't
insist how the version of the iommu patch on the upstream, I
just post an idea here.
The version for kernel 4.4 is under internal review, the implementation
has been modified many times.

I would suggest the managing clocks in pd is a more easy way and don't
need to spare those thing in two places.

Re: [PATCH v4 08/13] iommu/rockchip: Control clocks needed to access the IOMMU

[Randy Li]

On 01/22/2018 12:09 PM, JeffyChen wrote:

Hi Randy,

On 01/22/2018 10:15 AM, JeffyChen wrote:

Hi Randy,

On 01/22/2018 09:18 AM, Randy Li wrote:



Also the power domain driver could manage the clocks as well, I would
suggest to use pm_runtime_*.


actually the clocks required by pm domain may not be the same as what we
want to control here, there might be some clocks only be needed when
accessing mmu registers.

but i'm not very sure about that, will confirm it with Simon Xue.


confirmed with Simon, there might be some iommus don't have a pd, and 
We use the pd to control the NIU node(not on upstream), without a pd or 
fake pd, none of the platform would work.

the CONFIG_PM could be disabled.I am hard to believe a modern platform can work 
without that.

so it might be better to control clocks in iommu driver itself.I won't insist how the version of the iommu patch on the upstream, I 

just post an idea here.
The version for kernel 4.4 is under internal review, the implementation 
has been modified many times.


I would suggest the managing clocks in pd is a more easy way and don't 
need to spare those thing in two places.



___
Linux-rockchip mailing list
linux-rockc...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip



--
Randy Li

Re: [PATCH v4 08/13] iommu/rockchip: Control clocks needed to access the IOMMU

[Randy Li]

On 01/22/2018 12:09 PM, JeffyChen wrote:

Hi Randy,

On 01/22/2018 10:15 AM, JeffyChen wrote:

Hi Randy,

On 01/22/2018 09:18 AM, Randy Li wrote:



Also the power domain driver could manage the clocks as well, I would
suggest to use pm_runtime_*.


actually the clocks required by pm domain may not be the same as what we
want to control here, there might be some clocks only be needed when
accessing mmu registers.

but i'm not very sure about that, will confirm it with Simon Xue.


confirmed with Simon, there might be some iommus don't have a pd, and 
We use the pd to control the NIU node(not on upstream), without a pd or 
fake pd, none of the platform would work.

the CONFIG_PM could be disabled.I am hard to believe a modern platform can work 
without that.

so it might be better to control clocks in iommu driver itself.I won't insist how the version of the iommu patch on the upstream, I 

just post an idea here.
The version for kernel 4.4 is under internal review, the implementation 
has been modified many times.


I would suggest the managing clocks in pd is a more easy way and don't 
need to spare those thing in two places.



___
Linux-rockchip mailing list
linux-rockc...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip



--
Randy Li

Re: [PATCH v4 08/13] iommu/rockchip: Control clocks needed to access the IOMMU

[Tomasz Figa]

On Mon, Jan 22, 2018 at 1:09 PM, JeffyChen  wrote:
> Hi Randy,
>
>
> On 01/22/2018 10:15 AM, JeffyChen wrote:
>>
>> Hi Randy,
>>
>> On 01/22/2018 09:18 AM, Randy Li wrote:


>>> Also the power domain driver could manage the clocks as well, I would
>>> suggest to use pm_runtime_*.
>>
>>
>> actually the clocks required by pm domain may not be the same as what we
>> want to control here, there might be some clocks only be needed when
>> accessing mmu registers.
>>
>> but i'm not very sure about that, will confirm it with Simon Xue.
>
>
> confirmed with Simon, there might be some iommus don't have a pd, and the
> CONFIG_PM could be disabled.
>
> so it might be better to control clocks in iommu driver itself.
>

Agreed with Jeffy.

I'd give Reviewed-by, but this is my own patch reposted by Jeffy
(thanks!), so it wouldn't have any value. :)

Best regards,
Tomasz

Re: [PATCH v4 08/13] iommu/rockchip: Control clocks needed to access the IOMMU

[Tomasz Figa]

On Mon, Jan 22, 2018 at 1:09 PM, JeffyChen  wrote:
> Hi Randy,
>
>
> On 01/22/2018 10:15 AM, JeffyChen wrote:
>>
>> Hi Randy,
>>
>> On 01/22/2018 09:18 AM, Randy Li wrote:


>>> Also the power domain driver could manage the clocks as well, I would
>>> suggest to use pm_runtime_*.
>>
>>
>> actually the clocks required by pm domain may not be the same as what we
>> want to control here, there might be some clocks only be needed when
>> accessing mmu registers.
>>
>> but i'm not very sure about that, will confirm it with Simon Xue.
>
>
> confirmed with Simon, there might be some iommus don't have a pd, and the
> CONFIG_PM could be disabled.
>
> so it might be better to control clocks in iommu driver itself.
>

Agreed with Jeffy.

I'd give Reviewed-by, but this is my own patch reposted by Jeffy
(thanks!), so it wouldn't have any value. :)

Best regards,
Tomasz

Re: [PATCH v4 08/13] iommu/rockchip: Control clocks needed to access the IOMMU

[JeffyChen]

Hi Randy,

On 01/22/2018 10:15 AM, JeffyChen wrote:

Hi Randy,

On 01/22/2018 09:18 AM, Randy Li wrote:



Also the power domain driver could manage the clocks as well, I would
suggest to use pm_runtime_*.


actually the clocks required by pm domain may not be the same as what we
want to control here, there might be some clocks only be needed when
accessing mmu registers.

but i'm not very sure about that, will confirm it with Simon Xue.


confirmed with Simon, there might be some iommus don't have a pd, and 
the CONFIG_PM could be disabled.


so it might be better to control clocks in iommu driver itself.

Re: [PATCH v4 08/13] iommu/rockchip: Control clocks needed to access the IOMMU

[JeffyChen]

Hi Randy,

On 01/22/2018 10:15 AM, JeffyChen wrote:

Hi Randy,

On 01/22/2018 09:18 AM, Randy Li wrote:



Also the power domain driver could manage the clocks as well, I would
suggest to use pm_runtime_*.


actually the clocks required by pm domain may not be the same as what we
want to control here, there might be some clocks only be needed when
accessing mmu registers.

but i'm not very sure about that, will confirm it with Simon Xue.


confirmed with Simon, there might be some iommus don't have a pd, and 
the CONFIG_PM could be disabled.


so it might be better to control clocks in iommu driver itself.

Re: [PATCH v4 08/13] iommu/rockchip: Control clocks needed to access the IOMMU

[JeffyChen]

Hi Randy,

On 01/22/2018 09:18 AM, Randy Li wrote:



Also the power domain driver could manage the clocks as well, I would
suggest to use pm_runtime_*.


actually the clocks required by pm domain may not be the same as what we 
want to control here, there might be some clocks only be needed when 
accessing mmu registers.


but i'm not very sure about that, will confirm it with Simon Xue.

Re: [PATCH v4 08/13] iommu/rockchip: Control clocks needed to access the IOMMU

[JeffyChen]

Hi Randy,

On 01/22/2018 09:18 AM, Randy Li wrote:



Also the power domain driver could manage the clocks as well, I would
suggest to use pm_runtime_*.


actually the clocks required by pm domain may not be the same as what we 
want to control here, there might be some clocks only be needed when 
accessing mmu registers.


but i'm not very sure about that, will confirm it with Simon Xue.

Re: [PATCH v4 08/13] iommu/rockchip: Control clocks needed to access the IOMMU

[Randy Li]

On 01/18/2018 10:25 PM, JeffyChen wrote:

Hi Robin,

On 01/18/2018 08:27 PM, Robin Murphy wrote:




Is it worth using the clk_bulk_*() APIs for this? At a glance, most of
the code being added here appears to duplicate what those functions
already do (but I'm no clk API expert, for sure).
right, i think it's doable, the clk_bulk APIs are very helpful. i think 
we didn't use that is because this patch were wrote for the chromeos 4.4 
kernel, which doesn't have clk_bulk yet:)


will do it in the next version, thanks.
Also the power domain driver could manage the clocks as well, I would 
suggest to use pm_runtime_*.


Robin.




___
Linux-rockchip mailing list
linux-rockc...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip



--
Randy Li

Re: [PATCH v4 08/13] iommu/rockchip: Control clocks needed to access the IOMMU

[Randy Li]

On 01/18/2018 10:25 PM, JeffyChen wrote:

Hi Robin,

On 01/18/2018 08:27 PM, Robin Murphy wrote:




Is it worth using the clk_bulk_*() APIs for this? At a glance, most of
the code being added here appears to duplicate what those functions
already do (but I'm no clk API expert, for sure).
right, i think it's doable, the clk_bulk APIs are very helpful. i think 
we didn't use that is because this patch were wrote for the chromeos 4.4 
kernel, which doesn't have clk_bulk yet:)


will do it in the next version, thanks.
Also the power domain driver could manage the clocks as well, I would 
suggest to use pm_runtime_*.


Robin.




___
Linux-rockchip mailing list
linux-rockc...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip



--
Randy Li

Re: [PATCH v4 08/13] iommu/rockchip: Control clocks needed to access the IOMMU

[JeffyChen]

Hi Robin,

On 01/18/2018 08:27 PM, Robin Murphy wrote:




Is it worth using the clk_bulk_*() APIs for this? At a glance, most of
the code being added here appears to duplicate what those functions
already do (but I'm no clk API expert, for sure).
right, i think it's doable, the clk_bulk APIs are very helpful. i think 
we didn't use that is because this patch were wrote for the chromeos 4.4 
kernel, which doesn't have clk_bulk yet:)


will do it in the next version, thanks.


Robin.

Re: [PATCH v4 08/13] iommu/rockchip: Control clocks needed to access the IOMMU

[JeffyChen]

Hi Robin,

On 01/18/2018 08:27 PM, Robin Murphy wrote:




Is it worth using the clk_bulk_*() APIs for this? At a glance, most of
the code being added here appears to duplicate what those functions
already do (but I'm no clk API expert, for sure).
right, i think it's doable, the clk_bulk APIs are very helpful. i think 
we didn't use that is because this patch were wrote for the chromeos 4.4 
kernel, which doesn't have clk_bulk yet:)


will do it in the next version, thanks.


Robin.

Re: [PATCH v4 08/13] iommu/rockchip: Control clocks needed to access the IOMMU

[Robin Murphy]

On 18/01/18 11:52, Jeffy Chen wrote:

From: Tomasz Figa 

Current code relies on master driver enabling necessary clocks before
IOMMU is accessed, however there are cases when the IOMMU should be
accessed while the master is not running yet, for example allocating
V4L2 videobuf2 buffers, which is done by the VB2 framework using DMA
mapping API and doesn't engage the master driver at all.

This patch fixes the problem by letting clocks needed for IOMMU
operation to be listed in Device Tree and making the driver enable them
for the time of accessing the hardware.


Is it worth using the clk_bulk_*() APIs for this? At a glance, most of 
the code being added here appears to duplicate what those functions 
already do (but I'm no clk API expert, for sure).


Robin.


Signed-off-by: Jeffy Chen 
Signed-off-by: Tomasz Figa 
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

  .../devicetree/bindings/iommu/rockchip,iommu.txt   |   8 ++
  drivers/iommu/rockchip-iommu.c | 114 +++--
  2 files changed, 116 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt 
b/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt
index 2098f7732264..33dd853359fa 100644
--- a/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt
+++ b/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt
@@ -14,6 +14,13 @@ Required properties:
  "single-master" device, and needs no additional 
information
  to associate with its master device.  See:
  Documentation/devicetree/bindings/iommu/iommu.txt
+Optional properties:
+- clocks : A list of master clocks requires for the IOMMU to be accessible
+   by the host CPU. The number of clocks depends on the master
+   block and might as well be zero. See [1] for generic clock
+   bindings description.
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
  
  Optional properties:

  - rockchip,disable-mmu-reset : Don't use the mmu reset operation.
@@ -27,5 +34,6 @@ Example:
reg = <0xff940300 0x100>;
interrupts = ;
interrupt-names = "vopl_mmu";
+   clocks = < ACLK_VOP1>, < DCLK_VOP1>, < HCLK_VOP1>;
#iommu-cells = <0>;
};
diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c
index 1914ac52042c..9b85a3050449 100644
--- a/drivers/iommu/rockchip-iommu.c
+++ b/drivers/iommu/rockchip-iommu.c
@@ -4,6 +4,7 @@
   * published by the Free Software Foundation.
   */
  
+#include 

  #include 
  #include 
  #include 
@@ -89,6 +90,8 @@ struct rk_iommu {
struct device *dev;
void __iomem **bases;
int num_mmu;
+   struct clk **clocks;
+   int num_clocks;
bool reset_disabled;
struct iommu_device iommu;
struct list_head node; /* entry in rk_iommu_domain.iommus */
@@ -443,6 +446,83 @@ static int rk_iommu_force_reset(struct rk_iommu *iommu)
return 0;
  }
  
+static void rk_iommu_put_clocks(struct rk_iommu *iommu)

+{
+   int i;
+
+   for (i = 0; i < iommu->num_clocks; ++i) {
+   clk_unprepare(iommu->clocks[i]);
+   clk_put(iommu->clocks[i]);
+   }
+}
+
+static int rk_iommu_get_clocks(struct rk_iommu *iommu)
+{
+   struct device_node *np = iommu->dev->of_node;
+   int ret;
+   int i;
+
+   ret = of_count_phandle_with_args(np, "clocks", "#clock-cells");
+   if (ret == -ENOENT)
+   return 0;
+   else if (ret < 0)
+   return ret;
+
+   iommu->num_clocks = ret;
+   iommu->clocks = devm_kcalloc(iommu->dev, iommu->num_clocks,
+sizeof(*iommu->clocks), GFP_KERNEL);
+   if (!iommu->clocks)
+   return -ENOMEM;
+
+   for (i = 0; i < iommu->num_clocks; ++i) {
+   iommu->clocks[i] = of_clk_get(np, i);
+   if (IS_ERR(iommu->clocks[i])) {
+   iommu->num_clocks = i;
+   goto err_clk_put;
+   }
+   ret = clk_prepare(iommu->clocks[i]);
+   if (ret) {
+   clk_put(iommu->clocks[i]);
+   iommu->num_clocks = i;
+   goto err_clk_put;
+   }
+   }
+
+   return 0;
+
+err_clk_put:
+   rk_iommu_put_clocks(iommu);
+
+   return ret;
+}
+
+static int rk_iommu_enable_clocks(struct rk_iommu *iommu)
+{
+   int i, ret;
+
+   for (i = 0; i < iommu->num_clocks; ++i) {
+   ret = clk_enable(iommu->clocks[i]);
+   if (ret)
+   goto err_disable;
+   }
+
+   return 0;
+
+err_disable:
+   for (--i; i >= 0; --i)
+   clk_disable(iommu->clocks[i]);
+
+   return ret;
+}
+
+static void rk_iommu_disable_clocks(struct rk_iommu 

Re: [PATCH v4 08/13] iommu/rockchip: Control clocks needed to access the IOMMU

[Robin Murphy]

On 18/01/18 11:52, Jeffy Chen wrote:

From: Tomasz Figa 

Current code relies on master driver enabling necessary clocks before
IOMMU is accessed, however there are cases when the IOMMU should be
accessed while the master is not running yet, for example allocating
V4L2 videobuf2 buffers, which is done by the VB2 framework using DMA
mapping API and doesn't engage the master driver at all.

This patch fixes the problem by letting clocks needed for IOMMU
operation to be listed in Device Tree and making the driver enable them
for the time of accessing the hardware.


Is it worth using the clk_bulk_*() APIs for this? At a glance, most of 
the code being added here appears to duplicate what those functions 
already do (but I'm no clk API expert, for sure).


Robin.


Signed-off-by: Jeffy Chen 
Signed-off-by: Tomasz Figa 
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

  .../devicetree/bindings/iommu/rockchip,iommu.txt   |   8 ++
  drivers/iommu/rockchip-iommu.c | 114 +++--
  2 files changed, 116 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt 
b/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt
index 2098f7732264..33dd853359fa 100644
--- a/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt
+++ b/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt
@@ -14,6 +14,13 @@ Required properties:
  "single-master" device, and needs no additional 
information
  to associate with its master device.  See:
  Documentation/devicetree/bindings/iommu/iommu.txt
+Optional properties:
+- clocks : A list of master clocks requires for the IOMMU to be accessible
+   by the host CPU. The number of clocks depends on the master
+   block and might as well be zero. See [1] for generic clock
+   bindings description.
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
  
  Optional properties:

  - rockchip,disable-mmu-reset : Don't use the mmu reset operation.
@@ -27,5 +34,6 @@ Example:
reg = <0xff940300 0x100>;
interrupts = ;
interrupt-names = "vopl_mmu";
+   clocks = < ACLK_VOP1>, < DCLK_VOP1>, < HCLK_VOP1>;
#iommu-cells = <0>;
};
diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c
index 1914ac52042c..9b85a3050449 100644
--- a/drivers/iommu/rockchip-iommu.c
+++ b/drivers/iommu/rockchip-iommu.c
@@ -4,6 +4,7 @@
   * published by the Free Software Foundation.
   */
  
+#include 

  #include 
  #include 
  #include 
@@ -89,6 +90,8 @@ struct rk_iommu {
struct device *dev;
void __iomem **bases;
int num_mmu;
+   struct clk **clocks;
+   int num_clocks;
bool reset_disabled;
struct iommu_device iommu;
struct list_head node; /* entry in rk_iommu_domain.iommus */
@@ -443,6 +446,83 @@ static int rk_iommu_force_reset(struct rk_iommu *iommu)
return 0;
  }
  
+static void rk_iommu_put_clocks(struct rk_iommu *iommu)

+{
+   int i;
+
+   for (i = 0; i < iommu->num_clocks; ++i) {
+   clk_unprepare(iommu->clocks[i]);
+   clk_put(iommu->clocks[i]);
+   }
+}
+
+static int rk_iommu_get_clocks(struct rk_iommu *iommu)
+{
+   struct device_node *np = iommu->dev->of_node;
+   int ret;
+   int i;
+
+   ret = of_count_phandle_with_args(np, "clocks", "#clock-cells");
+   if (ret == -ENOENT)
+   return 0;
+   else if (ret < 0)
+   return ret;
+
+   iommu->num_clocks = ret;
+   iommu->clocks = devm_kcalloc(iommu->dev, iommu->num_clocks,
+sizeof(*iommu->clocks), GFP_KERNEL);
+   if (!iommu->clocks)
+   return -ENOMEM;
+
+   for (i = 0; i < iommu->num_clocks; ++i) {
+   iommu->clocks[i] = of_clk_get(np, i);
+   if (IS_ERR(iommu->clocks[i])) {
+   iommu->num_clocks = i;
+   goto err_clk_put;
+   }
+   ret = clk_prepare(iommu->clocks[i]);
+   if (ret) {
+   clk_put(iommu->clocks[i]);
+   iommu->num_clocks = i;
+   goto err_clk_put;
+   }
+   }
+
+   return 0;
+
+err_clk_put:
+   rk_iommu_put_clocks(iommu);
+
+   return ret;
+}
+
+static int rk_iommu_enable_clocks(struct rk_iommu *iommu)
+{
+   int i, ret;
+
+   for (i = 0; i < iommu->num_clocks; ++i) {
+   ret = clk_enable(iommu->clocks[i]);
+   if (ret)
+   goto err_disable;
+   }
+
+   return 0;
+
+err_disable:
+   for (--i; i >= 0; --i)
+   clk_disable(iommu->clocks[i]);
+
+   return ret;
+}
+
+static void rk_iommu_disable_clocks(struct rk_iommu *iommu)
+{
+   int i;
+
+   for (i = 0; i <