mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jordan Crouse <jcrouse@codeaurora.org>
To: Shubhashree Dhar <dhar@codeaurora.org>
Cc: dri-devel@lists.freedesktop.org, linux-arm-msm@vger.kernel.org,
	freedreno@lists.freedesktop.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, abhinavk@codeaurora.org,
	robdclark@gmail.com, nganji@codeaurora.org,
	seanpaul@chromium.org, hoegsberg@chromium.org,
	jsanka@codeaurora.org, chandanu@codeaurora.org
Subject: Re: [Freedreno] [v1] msm: disp: dpu1: add support to access hw irqs regs depending on revision
Date: Thu, 14 Nov 2019 10:39:09 -0700	[thread overview]
Message-ID: <20191114173909.GA19503@jcrouse1-lnx.qualcomm.com> (raw)
In-Reply-To: <1573710536-26889-1-git-send-email-dhar@codeaurora.org>

On Thu, Nov 14, 2019 at 11:18:56AM +0530, Shubhashree Dhar wrote:
> Current code assumes that all the irqs registers offsets can be
> accessed in all the hw revisions; this is not the case for some
> targets that should not access some of the irq registers.
> This change adds the support to selectively remove the irqs that
> are not supported in some of the hw revisions.
> 
> Change-Id: I6052b8237b703a1a9edd53893e04f7bd72223da1
> Signed-off-by: Shubhashree Dhar <dhar@codeaurora.org>
> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c    |   1 +
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h    |   3 +
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c |  22 +-
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h |   1 +
>  drivers/gpu/drm/panel/panel-visionox-rm69299.c    | 478 ++++++++++++++++++++++
>  5 files changed, 500 insertions(+), 5 deletions(-)
>  create mode 100644 drivers/gpu/drm/panel/panel-visionox-rm69299.c
> 
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> index 04c8c44..357e15b 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> @@ -421,6 +421,7 @@ static void sdm845_cfg_init(struct dpu_mdss_cfg *dpu_cfg)
>  		.reg_dma_count = 1,
>  		.dma_cfg = sdm845_regdma,
>  		.perf = sdm845_perf_data,
> +		.mdss_irqs[0] = 0x3ff,
>  	};
>  }
>  
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> index ec76b868..def8a3f 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
> @@ -646,6 +646,7 @@ struct dpu_perf_cfg {
>   * @dma_formats        Supported formats for dma pipe
>   * @cursor_formats     Supported formats for cursor pipe
>   * @vig_formats        Supported formats for vig pipe
> + * @mdss_irqs          Bitmap with the irqs supported by the target
>   */
>  struct dpu_mdss_cfg {
>  	u32 hwversion;
> @@ -684,6 +685,8 @@ struct dpu_mdss_cfg {
>  	struct dpu_format_extended *dma_formats;
>  	struct dpu_format_extended *cursor_formats;
>  	struct dpu_format_extended *vig_formats;
> +
> +	DECLARE_BITMAP(mdss_irqs, BITS_PER_BYTE * sizeof(long));

This is a very round about way of declaring an unsigned long. Do you ever
expect to have more than a long's worth of interrupt bits? If not, then just an
unsigned long mdss_irqs would be the preferred less macro-y way of doing this.

>  };
>  
>  struct dpu_mdss_hw_cfg_handler {
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
> index 8bfa7d0..2a3634c 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
> @@ -800,7 +800,8 @@ static void dpu_hw_intr_dispatch_irq(struct dpu_hw_intr *intr,
>  		start_idx = reg_idx * 32;
>  		end_idx = start_idx + 32;
>  
> -		if (start_idx >= ARRAY_SIZE(dpu_irq_map) ||
> +		if (!test_bit(reg_idx, &intr->irq_mask) ||
> +			start_idx >= ARRAY_SIZE(dpu_irq_map) ||
>  				end_idx > ARRAY_SIZE(dpu_irq_map)) 

This last one will always be true since end_idx is always 32 bigger than
start_idx. If you add the start_idx check you no longer need the end_idx check.

>  			continue;
>  
> @@ -955,8 +956,11 @@ static int dpu_hw_intr_clear_irqs(struct dpu_hw_intr *intr)
>  	if (!intr)
>  		return -EINVAL;
>  
> -	for (i = 0; i < ARRAY_SIZE(dpu_intr_set); i++)
> -		DPU_REG_WRITE(&intr->hw, dpu_intr_set[i].clr_off, 0xffffffff);
> +	for (i = 0; i < ARRAY_SIZE(dpu_intr_set); i++) {
> +		if(test_bit(i, &intr->irq_mask))
> +			DPU_REG_WRITE(&intr->hw,
> +					dpu_intr_set[i].clr_off, 0xffffffff);
> +	}
>  
>  	/* ensure register writes go through */
>  	wmb();
> @@ -971,8 +975,11 @@ static int dpu_hw_intr_disable_irqs(struct dpu_hw_intr *intr)
>  	if (!intr)
>  		return -EINVAL;
>  
> -	for (i = 0; i < ARRAY_SIZE(dpu_intr_set); i++)
> -		DPU_REG_WRITE(&intr->hw, dpu_intr_set[i].en_off, 0x00000000);
> +	for (i = 0; i < ARRAY_SIZE(dpu_intr_set); i++) {
> +		if(test_bit(i, &intr->irq_mask))
> +			DPU_REG_WRITE(&intr->hw,
> +					dpu_intr_set[i].en_off, 0x00000000);
> +	}
>  
>  	/* ensure register writes go through */
>  	wmb();
> @@ -991,6 +998,10 @@ static void dpu_hw_intr_get_interrupt_statuses(struct dpu_hw_intr *intr)
>  
>  	spin_lock_irqsave(&intr->irq_lock, irq_flags);
>  	for (i = 0; i < ARRAY_SIZE(dpu_intr_set); i++) {
> +

This extra blank line isn't strictly needed if you don't want it.

> +		if(!test_bit(i, &intr->irq_mask))
> +			continue;
> +
>  		/* Read interrupt status */
>  		intr->save_irq_status[i] = DPU_REG_READ(&intr->hw,
>  				dpu_intr_set[i].status_off);
> @@ -1115,6 +1126,7 @@ struct dpu_hw_intr *dpu_hw_intr_init(void __iomem *addr,
>  		return ERR_PTR(-ENOMEM);
>  	}
>  
> +	intr->irq_mask = m->mdss_irqs[0];
>  
>  	return intr;
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h
> index 4edcf40..fc9c986 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h
> @@ -187,6 +187,7 @@ struct dpu_hw_intr {
>  	u32 *save_irq_status;
>  	u32 irq_idx_tbl_size;
>  	spinlock_t irq_lock;
> +	unsigned long irq_mask;

This plus the chunk above would imply that, no, you never expect more than a
long's worth of interrupt bits.

>  	spin_lock_init(&intr->irq_lock);
>  };
>  
>  /**
> diff --git a/drivers/gpu/drm/panel/panel-visionox-rm69299.c b/drivers/gpu/drm/panel/panel-visionox-rm69299.c
> new file mode 100644
> index 00000000..1bbd40d
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-visionox-rm69299.c

Do you mean this file to be in this patch? The commit log doesn't make mention
of it and it doesn't seem to be related.

<snip>

Jordan

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

      reply	other threads:[~2019-11-14 17:39 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-14  5:48 Shubhashree Dhar
2019-11-14 17:39 ` Jordan Crouse [this message]

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=20191114173909.GA19503@jcrouse1-lnx.qualcomm.com \
    --to=jcrouse@codeaurora.org \
    --cc=abhinavk@codeaurora.org \
    --cc=chandanu@codeaurora.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dhar@codeaurora.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=freedreno@lists.freedesktop.org \
    --cc=hoegsberg@chromium.org \
    --cc=jsanka@codeaurora.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nganji@codeaurora.org \
    --cc=robdclark@gmail.com \
    --cc=seanpaul@chromium.org \
    /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®