linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: CK Hu <ck.hu@mediatek.com>
To: Stu Hsieh <stu.hsieh@mediatek.com>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	"Matthias Brugger" <matthias.bgg@gmail.com>,
	<linux-media@vger.kernel.org>, <devicetree@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-mediatek@lists.infradead.org>,
	<srv_heupstream@mediatek.com>
Subject: Re: [PATCH v3 09/13] [media] mtk-mipicsi: add ISR for writing the data to buffer
Date: Fri, 17 May 2019 17:05:34 +0800	[thread overview]
Message-ID: <1558083934.29098.6.camel@mtksdaap41> (raw)
In-Reply-To: <1557814430-9675-10-git-send-email-stu.hsieh@mediatek.com>

Hi, Stu:

On Tue, 2019-05-14 at 14:13 +0800, Stu Hsieh wrote:
> This patch add ISR for writing the data to buffer
> 
> When mipicsi HW complete to write the data in buffer,
> the interrupt woulb be trigger.
> So, the ISR need to clear interrupt status for next interrupt.
> 
> Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
> ---
>  .../media/platform/mtk-mipicsi/mtk_mipicsi.c  | 110 ++++++++++++++++++
>  1 file changed, 110 insertions(+)
> 
> diff --git a/drivers/media/platform/mtk-mipicsi/mtk_mipicsi.c b/drivers/media/platform/mtk-mipicsi/mtk_mipicsi.c
> index 44c01c8d566b..af5655345754 100644
> --- a/drivers/media/platform/mtk-mipicsi/mtk_mipicsi.c
> +++ b/drivers/media/platform/mtk-mipicsi/mtk_mipicsi.c
> @@ -36,6 +36,7 @@
>  #include <linux/pm_runtime.h>
>  #include <linux/iommu.h>
>  #include <linux/of.h>
> +#include <linux/of_irq.h>
>  #include <linux/of_platform.h>
>  #include <media/v4l2-common.h>
>  #include <media/v4l2-dev.h>
> @@ -93,6 +94,8 @@
>  #define CAMSV_MODULE_EN					0x10
>  #define CAMSV_FMT_SEL					0x14
>  #define CAMSV_INT_EN					0x18
> +#define CAMSV_INT_STATUS				0x1C
> +#define PASS1_DONE_STATUS				10
>  #define CAMSV_SW_CTL					0x20
>  #define CAMSV_CLK_EN					0x30
>  
> @@ -122,6 +125,8 @@ struct mtk_mipicsi_dev {
>  	struct platform_device *pdev;
>  	unsigned int camsv_num;
>  	struct device *larb_pdev;
> +	unsigned int		irq[MTK_CAMDMA_MAX_NUM];
> +	bool irq_status[MTK_CAMDMA_MAX_NUM];
>  	void __iomem		*ana;
>  	void __iomem		*seninf_ctrl;
>  	void __iomem		*seninf;
> @@ -132,6 +137,7 @@ struct mtk_mipicsi_dev {
>  	spinlock_t		lock;
>  	spinlock_t		queue_lock;
>  	struct mtk_mipicsi_buf	cam_buf[MAX_BUFFER_NUM];
> +	bool			is_enable_irq[MTK_CAMDMA_MAX_NUM];

Useless, so remove it.

>  	bool streamon;
>  	unsigned int link;
>  	u8 link_reg_val;
> @@ -911,9 +917,96 @@ static const struct dev_pm_ops mtk_mipicsi_pm = {
>  		mtk_mipicsi_pm_resume, NULL)
>  };
>  
> +static int get_irq_channel(struct mtk_mipicsi_dev *mipicsi)
> +{
> +	int ch;
> +	u32 int_reg_val;
> +
> +	for (ch = 0; ch < mipicsi->camsv_num; ++ch) {
> +		int_reg_val = readl(mipicsi->camsv[ch] + CAMSV_INT_STATUS);
> +		if ((int_reg_val & (1UL << PASS1_DONE_STATUS)) != 0UL)
> +			return ch;
> +	}
> +
> +	return -1;
> +}
> +
> +static void mtk_mipicsi_irq_buf_process(struct mtk_mipicsi_dev *mipicsi)
> +{
> +	unsigned int i = 0U;
> +	struct mtk_mipicsi_buf *new_cam_buf = NULL;
> +	struct mtk_mipicsi_buf *tmp = NULL;
> +	unsigned int index = 0U;
> +	unsigned int next = 0U;
> +
> +	for (i = 0U; i < MTK_CAMDMA_MAX_NUM; ++i)
> +		mipicsi->irq_status[i] = false;
> +
> +	i = 0;
> +
> +	/* only one buffer left */
> +	if ((&(mipicsi->fb_list))->next->next == &(mipicsi->fb_list))
> +		return;
> +
> +	/*for each fb_lst 2 times to get the top 2 buffer.*/
> +	list_for_each_entry_safe(new_cam_buf, tmp,
> +		&(mipicsi->fb_list), queue) {
> +		if (i == 0U) {
> +			index = new_cam_buf->vb->index;
> +		} else {
> +			next = new_cam_buf->vb->index;
> +			break;
> +		}
> +		++i;
> +	}
> +
> +	/*
> +	 * fb_list has one more buffer. Free the first buffer to user
> +	 * and fill the second buffer to HW.
> +	 */
> +	vb2_buffer_done(mipicsi->cam_buf[index].vb,
> +		VB2_BUF_STATE_DONE);
> +
> +	list_del_init(&(mipicsi->cam_buf[index].queue));
> +}
> +
> +static irqreturn_t mtk_mipicsi_isr(int irq, void *data)
> +{
> +
> +	struct mtk_mipicsi_dev *mipicsi = data;
> +	unsigned long flags = 0;
> +	int isr_ch;
> +	u8 irq_cnt = 0, i = 0;
> +
> +	spin_lock_irqsave(&mipicsi->lock, flags);
> +
> +	isr_ch = get_irq_channel(mipicsi);

I think you should pass data as camsv instance, so you need not to
search the camsv instance, and each camsv instance could pointer to the
same misicsi instance.

> +	if (isr_ch < 0) {
> +		spin_unlock_irqrestore(&mipicsi->lock, flags);
> +		return IRQ_HANDLED;
> +	}
> +
> +	/* clear interrupt */
> +	writel(1UL << PASS1_DONE_STATUS,
> +		mipicsi->camsv[isr_ch] + CAMSV_INT_STATUS);
> +	mipicsi->irq_status[isr_ch] = true;
> +	for (i = 0U; i < MTK_CAMDMA_MAX_NUM; ++i) {
> +		if (mipicsi->irq_status[i])
> +			++irq_cnt;
> +	}
> +
> +	if (irq_cnt == mipicsi->link)
> +		mtk_mipicsi_irq_buf_process(mipicsi);

I think mtk_mipicsi_irq_buf_process() should not be processed in irq
handler. In irq handler, do as few things as possible.

Regards,
CK

> +	spin_unlock_irqrestore(&mipicsi->lock, flags);
> +
> +	return IRQ_HANDLED;
> +}
> +
>  static int seninf_mux_camsv_node_parse(struct mtk_mipicsi_dev *mipicsi,
>  		int index)
>  {
> +	int ret;
> +	int irq;
>  	struct clk *clk = NULL;
>  	struct device *dev = NULL;
>  	struct resource *res = NULL;
> @@ -951,6 +1044,23 @@ static int seninf_mux_camsv_node_parse(struct mtk_mipicsi_dev *mipicsi,
>  	}
>  	mipicsi->clk[index] = clk;
>  
> +	irq = of_irq_get(np, 0);
> +	if (irq <= 0) {
> +		dev_err(dev, "get irq fail in %s node\n", np->full_name);
> +		return -ENODEV;
> +	}
> +	mipicsi->irq[index] = irq;
> +
> +	ret = devm_request_irq(dev, irq,
> +			mtk_mipicsi_isr, 0,
> +			mipicsi->drv_name, mipicsi);
> +	if (ret != 0) {
> +		dev_err(dev, "%s irq register failed\n", np->full_name);
> +		return -ENODEV;
> +	}
> +	disable_irq(mipicsi->irq[index]);
> +	mipicsi->irq_status[index] = false;
> +
>  	res = platform_get_resource(camdma_pdev, IORESOURCE_MEM, 0);
>  	if (res == NULL) {
>  		dev_err(dev, "get seninf_mux memory failed in %s node\n",



  reply	other threads:[~2019-05-17  9:05 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-14  6:13 [PATCH v3 00/13] Add mediatek mipicsi driver for Mediatek SOC MT2712 Stu Hsieh
2019-05-14  6:13 ` [PATCH v3 01/13] dt-bindings: media: Add binding for MT2712 MIPI-CSI2 Stu Hsieh
2019-05-14 19:28   ` Rob Herring
2019-05-14  6:13 ` [PATCH v3 02/13] [media] mtk-mipicsi: add mediatek mipicsi driver for mt2712 Stu Hsieh
2019-05-17  7:37   ` CK Hu
2019-05-14  6:13 ` [PATCH v3 03/13] [media] mtk-mipicsi: register the soc_camera host Stu Hsieh
2019-05-14  6:13 ` [PATCH v3 04/13] [media] mtk-mipicsi: add the check for non-supported color format Stu Hsieh
2019-05-14  6:13 ` [PATCH v3 05/13] [media] mtk-mipicsi: get the w/h/bytepwerline for mtk_mipicsi Stu Hsieh
2019-05-14  6:13 ` [PATCH v3 06/13] [media] mtk-mipicsi: add function to support SerDes for link number Stu Hsieh
2019-05-14  6:13 ` [PATCH v3 07/13] [media] mtk-mipicsi: enable/disable ana clk Stu Hsieh
2019-05-14  6:13 ` [PATCH v3 08/13] [media] mtk-mipicsi: enable/disable cmos for mt2712 Stu Hsieh
2019-05-14  6:13 ` [PATCH v3 09/13] [media] mtk-mipicsi: add ISR for writing the data to buffer Stu Hsieh
2019-05-17  9:05   ` CK Hu [this message]
2019-05-14  6:13 ` [PATCH v3 10/13] [media] mtk-mipicsi: set the output address in HW reg Stu Hsieh
2019-05-14  6:13 ` [PATCH v3 11/13] [media] mtk-mipicsi: add function to get the format Stu Hsieh
2019-05-14  6:13 ` [PATCH v3 12/13] [media] mtk-mipicsi: add debug message for mipicsi driver Stu Hsieh
2019-05-14  6:13 ` [PATCH v3 13/13] [media] mtk-mipicsi: add debugfs " Stu Hsieh

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=1558083934.29098.6.camel@mtksdaap41 \
    --to=ck.hu@mediatek.com \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=mark.rutland@arm.com \
    --cc=matthias.bgg@gmail.com \
    --cc=mchehab@kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=srv_heupstream@mediatek.com \
    --cc=stu.hsieh@mediatek.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;
as well as URLs for NNTP newsgroup(s).