From: Heiko Stuebner <heiko@sntech.de>
To: Marc Zyngier <marc.zyngier@arm.com>
Cc: iommu@lists.linux-foundation.org, Joerg Roedel <joro@8bytes.org>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] iommu/rockchip: Handle errors returned from PM framework
Date: Mon, 06 Aug 2018 14:09:38 +0200 [thread overview]
Message-ID: <2071881.EAoDzUiQGL@phil> (raw)
In-Reply-To: <20180805124616.18020-1-marc.zyngier@arm.com>
Hi Marc,
Am Sonntag, 5. August 2018, 14:46:16 CEST schrieb Marc Zyngier:
> pm_runtime_get_if_in_use can fail: either PM has been disabled
> altogether (-EINVAL), or the device hasn't been enabled yet (0).
> Sadly, we ignore the first case at the moment, and end up treating
> it as if we had received a valid interrupt.
>
> The first case could happen because the interrupt line is shared
> (with the VOP for example), and although that device hasn't been
> programmed yet, an interrupt may be pending (think kexec/kdump).
>
> The second case means that we've enabled the IOMMU, but it is
> not powered-on just yet. This could be another instance of the
> above, but as it deserves investigation, let's output a single
> warning (instead of flodding the console).
>
> In both cases, bail with an IRQ_NONE.
>
> Fixes: 0f181d3cf7d98 ("iommu/rockchip: Add runtime PM support")
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Hmm, maybe my thinking is flawed, but to me it looks a bit different.
I.e. the iommu, as well as the vop have the capability to check if the irq
is for them via their status registers (INT_STATUS and MMU_STATUS).
For this to happen the power-domain must be active and the device clocked.
Clock handling is done on both the vop and iommu and in the !CONFIG_PM
case all power-domains are left on.
Right now a !CONFIG_PM just passes through the driver unnoticed but with
this change, we would actually make it depend on PM?
What am I missing?
Also there are quite a bit more instances of pm_runtime_get_if_in_use
present in the iommu driver.
Heiko
> drivers/iommu/rockchip-iommu.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c
> index 054cd2c8e9c8..9d21495a8433 100644
> --- a/drivers/iommu/rockchip-iommu.c
> +++ b/drivers/iommu/rockchip-iommu.c
> @@ -521,10 +521,11 @@ static irqreturn_t rk_iommu_irq(int irq, void *dev_id)
> u32 int_status;
> dma_addr_t iova;
> irqreturn_t ret = IRQ_NONE;
> - int i;
> + int i, err;
>
> - if (WARN_ON(!pm_runtime_get_if_in_use(iommu->dev)))
> - return 0;
> + err = pm_runtime_get_if_in_use(iommu->dev);
> + if ((err < 0) || WARN_ON_ONCE(!err))
> + return ret;
>
> if (WARN_ON(clk_bulk_enable(iommu->num_clocks, iommu->clocks)))
> goto out;
>
WARNING: multiple messages have this Message-ID (diff)
From: heiko@sntech.de (Heiko Stuebner)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] iommu/rockchip: Handle errors returned from PM framework
Date: Mon, 06 Aug 2018 14:09:38 +0200 [thread overview]
Message-ID: <2071881.EAoDzUiQGL@phil> (raw)
In-Reply-To: <20180805124616.18020-1-marc.zyngier@arm.com>
Hi Marc,
Am Sonntag, 5. August 2018, 14:46:16 CEST schrieb Marc Zyngier:
> pm_runtime_get_if_in_use can fail: either PM has been disabled
> altogether (-EINVAL), or the device hasn't been enabled yet (0).
> Sadly, we ignore the first case at the moment, and end up treating
> it as if we had received a valid interrupt.
>
> The first case could happen because the interrupt line is shared
> (with the VOP for example), and although that device hasn't been
> programmed yet, an interrupt may be pending (think kexec/kdump).
>
> The second case means that we've enabled the IOMMU, but it is
> not powered-on just yet. This could be another instance of the
> above, but as it deserves investigation, let's output a single
> warning (instead of flodding the console).
>
> In both cases, bail with an IRQ_NONE.
>
> Fixes: 0f181d3cf7d98 ("iommu/rockchip: Add runtime PM support")
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Hmm, maybe my thinking is flawed, but to me it looks a bit different.
I.e. the iommu, as well as the vop have the capability to check if the irq
is for them via their status registers (INT_STATUS and MMU_STATUS).
For this to happen the power-domain must be active and the device clocked.
Clock handling is done on both the vop and iommu and in the !CONFIG_PM
case all power-domains are left on.
Right now a !CONFIG_PM just passes through the driver unnoticed but with
this change, we would actually make it depend on PM?
What am I missing?
Also there are quite a bit more instances of pm_runtime_get_if_in_use
present in the iommu driver.
Heiko
> drivers/iommu/rockchip-iommu.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c
> index 054cd2c8e9c8..9d21495a8433 100644
> --- a/drivers/iommu/rockchip-iommu.c
> +++ b/drivers/iommu/rockchip-iommu.c
> @@ -521,10 +521,11 @@ static irqreturn_t rk_iommu_irq(int irq, void *dev_id)
> u32 int_status;
> dma_addr_t iova;
> irqreturn_t ret = IRQ_NONE;
> - int i;
> + int i, err;
>
> - if (WARN_ON(!pm_runtime_get_if_in_use(iommu->dev)))
> - return 0;
> + err = pm_runtime_get_if_in_use(iommu->dev);
> + if ((err < 0) || WARN_ON_ONCE(!err))
> + return ret;
>
> if (WARN_ON(clk_bulk_enable(iommu->num_clocks, iommu->clocks)))
> goto out;
>
next prev parent reply other threads:[~2018-08-06 12:09 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-05 12:46 [PATCH] iommu/rockchip: Handle errors returned from PM framework Marc Zyngier
2018-08-05 12:46 ` Marc Zyngier
2018-08-06 12:09 ` Heiko Stuebner [this message]
2018-08-06 12:09 ` Heiko Stuebner
2018-08-06 12:32 ` Marc Zyngier
2018-08-06 12:32 ` Marc Zyngier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2071881.EAoDzUiQGL@phil \
--to=heiko@sntech.de \
--cc=iommu@lists.linux-foundation.org \
--cc=joro@8bytes.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=marc.zyngier@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.