From: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
To: kholk11@gmail.com, Robert Foss <robert.foss@linaro.org>,
Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Cc: agross@kernel.org, bjorn.andersson@linaro.org,
mchehab@kernel.org, robh+dt@kernel.org, marijns95@gmail.com,
konradybcio@gmail.com, martin.botka1@gmail.com,
linux-arm-msm@vger.kernel.org, linux-media@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
todor.too@gmail.com
Subject: Re: [PATCH v2 1/7] media: camss: ispif: Correctly reset based on the VFE ID
Date: Wed, 25 May 2022 12:03:26 +0300 [thread overview]
Message-ID: <899412f2-5ee4-cd32-393f-688fc6351437@linaro.org> (raw)
In-Reply-To: <20201022174706.8813-2-kholk11@gmail.com>
On 10/22/20 20:47, kholk11@gmail.com wrote:
> From: AngeloGioacchino Del Regno <kholk11@gmail.com>
>
> Resetting the ISPIF VFE0 context is wrong if we are using the VFE1
> for dual-camera or simply because a secondary camera is connected
> to it: in this case the reset will always happen on the VFE0 ctx
> of the ISPIF, which is .. useless.
>
> Fix this usecase by adding the ISPIF_RST_CMD_1 address and choose
> where to do the (or what to) reset based on the VFE line id.
>
> Signed-off-by: AngeloGioacchino Del Regno <kholk11@gmail.com>
> Reviewed-by: Robert Foss <robert.foss@linaro.org>
> ---
> .../media/platform/qcom/camss/camss-ispif.c | 85 ++++++++++++-------
> .../media/platform/qcom/camss/camss-ispif.h | 2 +-
> 2 files changed, 56 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/media/platform/qcom/camss/camss-ispif.c b/drivers/media/platform/qcom/camss/camss-ispif.c
> index db94cfd6c508..754f0d044c38 100644
> --- a/drivers/media/platform/qcom/camss/camss-ispif.c
> +++ b/drivers/media/platform/qcom/camss/camss-ispif.c
> @@ -26,6 +26,7 @@
> #define MSM_ISPIF_NAME "msm_ispif"
>
> #define ISPIF_RST_CMD_0 0x008
> +#define ISPIF_RST_CMD_1 0x00c
> #define ISPIF_RST_CMD_0_STROBED_RST_EN (1 << 0)
> #define ISPIF_RST_CMD_0_MISC_LOGIC_RST (1 << 1)
> #define ISPIF_RST_CMD_0_SW_REG_RST (1 << 2)
> @@ -179,7 +180,10 @@ static irqreturn_t ispif_isr_8x96(int irq, void *dev)
> writel(0x1, ispif->base + ISPIF_IRQ_GLOBAL_CLEAR_CMD);
>
> if ((value0 >> 27) & 0x1)
> - complete(&ispif->reset_complete);
> + complete(&ispif->reset_complete[0]);
> +
> + if ((value3 >> 27) & 0x1)
> + complete(&ispif->reset_complete[1]);
>
> if (unlikely(value0 & ISPIF_VFE_m_IRQ_STATUS_0_PIX0_OVERFLOW))
> dev_err_ratelimited(to_device(ispif), "VFE0 pix0 overflow\n");
> @@ -237,7 +241,7 @@ static irqreturn_t ispif_isr_8x16(int irq, void *dev)
> writel(0x1, ispif->base + ISPIF_IRQ_GLOBAL_CLEAR_CMD);
>
> if ((value0 >> 27) & 0x1)
> - complete(&ispif->reset_complete);
> + complete(&ispif->reset_complete[0]);
>
> if (unlikely(value0 & ISPIF_VFE_m_IRQ_STATUS_0_PIX0_OVERFLOW))
> dev_err_ratelimited(to_device(ispif), "VFE0 pix0 overflow\n");
> @@ -257,33 +261,18 @@ static irqreturn_t ispif_isr_8x16(int irq, void *dev)
> return IRQ_HANDLED;
> }
>
> -/*
> - * ispif_reset - Trigger reset on ISPIF module and wait to complete
> - * @ispif: ISPIF device
> - *
> - * Return 0 on success or a negative error code otherwise
> - */
> -static int ispif_reset(struct ispif_device *ispif)
> +static int ispif_vfe_reset(struct ispif_device *ispif, u8 vfe_id)
> {
> unsigned long time;
> u32 val;
> - int ret;
> -
> - ret = camss_pm_domain_on(to_camss(ispif), PM_DOMAIN_VFE0);
> - if (ret < 0)
> - return ret;
>
> - ret = camss_pm_domain_on(to_camss(ispif), PM_DOMAIN_VFE1);
> - if (ret < 0)
> - return ret;
> -
> - ret = camss_enable_clocks(ispif->nclocks_for_reset,
> - ispif->clock_for_reset,
> - to_device(ispif));
> - if (ret < 0)
> - return ret;
> + if (vfe_id > (to_camss(ispif)->vfe_num - 1)) {
> + dev_err(to_device(ispif),
> + "Error: asked reset for invalid VFE%d\n", vfe_id);
> + return -ENOENT;
> + }
I was stumbled upon this "vfe_num" usage, which seems unnecessary...
>
> - reinit_completion(&ispif->reset_complete);
> + reinit_completion(&ispif->reset_complete[vfe_id]);
>
> val = ISPIF_RST_CMD_0_STROBED_RST_EN |
> ISPIF_RST_CMD_0_MISC_LOGIC_RST |
> @@ -303,15 +292,50 @@ static int ispif_reset(struct ispif_device *ispif)
> ISPIF_RST_CMD_0_RDI_OUTPUT_1_MISR_RST |
> ISPIF_RST_CMD_0_RDI_OUTPUT_2_MISR_RST;
>
> - writel_relaxed(val, ispif->base + ISPIF_RST_CMD_0);
> + if (vfe_id == 1)
> + writel_relaxed(val, ispif->base + ISPIF_RST_CMD_1);
> + else
> + writel_relaxed(val, ispif->base + ISPIF_RST_CMD_0);
>
> - time = wait_for_completion_timeout(&ispif->reset_complete,
> + time = wait_for_completion_timeout(&ispif->reset_complete[vfe_id],
> msecs_to_jiffies(ISPIF_RESET_TIMEOUT_MS));
> if (!time) {
> - dev_err(to_device(ispif), "ISPIF reset timeout\n");
> - ret = -EIO;
> + dev_err(to_device(ispif),
> + "ISPIF for VFE%d reset timeout\n", vfe_id);
> + return -EIO;
> }
>
> + return 0;
> +}
> +
> +/*
> + * ispif_reset - Trigger reset on ISPIF module and wait to complete
> + * @ispif: ISPIF device
> + *
> + * Return 0 on success or a negative error code otherwise
> + */
> +static int ispif_reset(struct ispif_device *ispif, u8 vfe_id)
> +{
> + int ret;
> +
> + ret = camss_pm_domain_on(to_camss(ispif), PM_DOMAIN_VFE0);
> + if (ret < 0)
> + return ret;
> +
> + ret = camss_pm_domain_on(to_camss(ispif), PM_DOMAIN_VFE1);
> + if (ret < 0)
> + return ret;
> +
> + ret = camss_enable_clocks(ispif->nclocks_for_reset,
> + ispif->clock_for_reset,
> + to_device(ispif));
> + if (ret < 0)
> + return ret;
> +
> + ret = ispif_vfe_reset(ispif, vfe_id);
> + if (ret)
> + dev_dbg(to_device(ispif), "ISPIF Reset failed\n");
> +
> camss_disable_clocks(ispif->nclocks_for_reset, ispif->clock_for_reset);
>
> camss_pm_domain_off(to_camss(ispif), PM_DOMAIN_VFE0);
> @@ -355,7 +379,7 @@ static int ispif_set_power(struct v4l2_subdev *sd, int on)
> goto exit;
> }
>
> - ret = ispif_reset(ispif);
> + ret = ispif_reset(ispif, line->vfe_id);
But in fact here is an error.
line->vfe_id is never set.
I'm unable to test any fix, since I don't have a correspondent hardware,
but I can write a fix for someone's testing.
--
Best wishes,
Vladimir
next prev parent reply other threads:[~2022-05-25 9:07 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-22 17:46 [PATCH v2 0/7] Add support for SDM630/660 Camera Subsystem kholk11
2020-10-22 17:47 ` [PATCH v2 1/7] media: camss: ispif: Correctly reset based on the VFE ID kholk11
2022-05-25 9:03 ` Vladimir Zapolskiy [this message]
2022-05-25 11:33 ` Dmitry Baryshkov
2020-10-22 17:47 ` [PATCH v2 2/7] media: camss: vfe-4-7: Rename get_ub_size, set_qos, set_ds, wm_enable kholk11
2020-10-22 17:47 ` [PATCH v2 3/7] media: camss: vfe: Add support for VFE 4.8 kholk11
2020-10-22 17:47 ` [PATCH v2 4/7] media: camss: Add support for SDM630/636/660 camera subsystem kholk11
2020-10-22 17:47 ` [PATCH v2 5/7] media: camss: csiphy-3ph: Add support for SDM630/660 kholk11
2020-10-22 17:47 ` [PATCH v2 6/7] media: dt-bindings: media: qcom,camss: Add bindings for SDM660 camss kholk11
2020-10-30 15:43 ` Rob Herring
2020-10-22 17:47 ` [PATCH v2 7/7] media: camss: csiphy: Set rate on csiX_phy clock on SDM630/660 kholk11
2020-10-26 19:50 ` [PATCH v2 0/7] Add support for SDM630/660 Camera Subsystem Robert Foss
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=899412f2-5ee4-cd32-393f-688fc6351437@linaro.org \
--to=vladimir.zapolskiy@linaro.org \
--cc=agross@kernel.org \
--cc=bjorn.andersson@linaro.org \
--cc=bryan.odonoghue@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=kholk11@gmail.com \
--cc=konradybcio@gmail.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=marijns95@gmail.com \
--cc=martin.botka1@gmail.com \
--cc=mchehab@kernel.org \
--cc=robert.foss@linaro.org \
--cc=robh+dt@kernel.org \
--cc=todor.too@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®