linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
To: Guru Das Srinagesh <gurus@codeaurora.org>,
	Mark Brown <broonie@kernel.org>,
	Markus Elfring <Markus.Elfring@web.de>,
	Lee Jones <lee.jones@linaro.org>,
	Rob Herring <robh+dt@kernel.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>,
	Greg KH <gregkh@linuxfoundation.org>,
	Guenter Roeck <linux@roeck-us.net>, Joe Perches <joe@perches.com>,
	Subbaraman Narayanamurthy <subbaram@codeaurora.org>,
	David Collins <collinsd@codeaurora.org>,
	Anirudh Ghayal <aghayal@codeaurora.org>,
	linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
	devicetree@vger.kernel.org
Subject: Re: [RFC PATCH v3 1/3] regmap-irq: Extend sub-irq to support non-fixed reg strides
Date: Mon, 12 Apr 2021 09:05:39 +0300	[thread overview]
Message-ID: <4abddb76d87a2e6e0d2ad98da0b8349251456158.camel@fi.rohmeurope.com> (raw)
In-Reply-To: <526562423eaa58b4075362083f561841f1d6956c.1615423027.git.gurus@codeaurora.org>

Hi All,

On Wed, 2021-03-10 at 16:39 -0800, Guru Das Srinagesh wrote:
> Qualcomm's MFD chips have a top level interrupt status register and
> sub-irqs (peripherals).  When a bit in the main status register goes
> high, it means that the peripheral corresponding to that bit has an
> unserviced interrupt. If the bit is not set, this means that the
> corresponding peripheral does not.
> 
> Commit a2d21848d9211d ("regmap: regmap-irq: Add main status register
> support") introduced the sub-irq logic that is currently applied only
> when reading status registers, but not for any other functions like
> acking
> or masking. Extend the use of sub-irq to all other functions, with
> two
> caveats regarding the specification of offsets:
> 
> - Each member of the sub_reg_offsets array should be of length 1
> - The specified offsets should be the unequal strides for each sub-
> irq
>   device.
> 
> In QCOM's case, all the *_base registers are to be configured to the
> base addresses of the first sub-irq group, with offsets of each
> subsequent group calculated as a difference from these addresses.
> 
> Continuing from the example mentioned in the cover letter:
> 
> 	/*
> 	 * Address of MISC_INT_MASK		= 0x1011
> 	 * Address of TEMP_ALARM_INT_MASK	= 0x2011
> 	 * Address of GPIO01_INT_MASK		= 0x3011
> 	 *
> 	 * Calculate offsets as:
> 	 * offset_0 = 0x1011 - 0x1011 = 0       (to access MISC's
> 	 * 					 registers)
> 	 * offset_1 = 0x2011 - 0x1011 = 0x1000
> 	 * offset_2 = 0x3011 - 0x1011 = 0x2000
> 	 */
> 
> 	static unsigned int sub_unit0_offsets[] = {0};
> 	static unsigned int sub_unit1_offsets[] = {0x1000};
> 	static unsigned int sub_unit2_offsets[] = {0x2000};
> 
> 	static struct regmap_irq_sub_irq_map chip_sub_irq_offsets[] = {
> 		REGMAP_IRQ_MAIN_REG_OFFSET(sub_unit0_offsets),
> 		REGMAP_IRQ_MAIN_REG_OFFSET(sub_unit0_offsets),
> 		REGMAP_IRQ_MAIN_REG_OFFSET(sub_unit0_offsets),
> 	};
> 
> 	static struct regmap_irq_chip chip_irq_chip = {
> 	--------8<--------
> 	.not_fixed_stride = true,
> 	.mask_base	  = MISC_INT_MASK,
> 	.type_base	  = MISC_INT_TYPE,
> 	.ack_base	  = MISC_INT_ACK,
> 	.sub_reg_offsets  = chip_sub_irq_offsets,
> 	--------8<--------
> 	};
> 
> Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
> ---
>  drivers/base/regmap/regmap-irq.c | 81 ++++++++++++++++++++++++++--
> ------------
>  include/linux/regmap.h           |  7 ++++
>  2 files changed, 60 insertions(+), 28 deletions(-)
> 
> diff --git a/drivers/base/regmap/regmap-irq.c
> b/drivers/base/regmap/regmap-irq.c
> index 19db764..e1d8fc9e 100644
> --- a/drivers/base/regmap/regmap-irq.c
> +++ b/drivers/base/regmap/regmap-irq.c
> @@ -45,6 +45,27 @@ struct regmap_irq_chip_data {
>  	bool clear_status:1;
>  };
> 

Sorry that I am late with the "review" but I only now noticed this
change when I was following the references from PM8008 PMIC patch mail.


>  
> +static int sub_irq_reg(struct regmap_irq_chip_data *data,
> +		       unsigned int base_reg, int i)

Do I read this correctly - this function should map the main status bit
(given in i) to the (sub)IRQ register, right? How does this work for
cases where one bit corresponds to more than one sub-register? Or do I
misunderstand the purpose of this function? (This is the case with both
the BD70528 and BD71828).

> +{
> +	const struct regmap_irq_chip *chip = data->chip;
> +	struct regmap *map = data->map;
> +	struct regmap_irq_sub_irq_map *subreg;
> +	unsigned int offset;
> +	int reg = 0;
> +
> +	if (!chip->sub_reg_offsets || !chip->not_fixed_stride) {
> +		/* Assume linear mapping */
> +		reg = base_reg + (i * map->reg_stride * data-
> >irq_reg_stride);
> +	} else {
> +		subreg = &chip->sub_reg_offsets[i];
> +		offset = subreg->offset[0];
> +		reg = base_reg + offset;
> +	}
> +
> +	return reg;
> +}
> +
>  static inline const
>  struct regmap_irq *irq_to_regmap_irq(struct regmap_irq_chip_data
> *data,
>  				     int irq)
> @@ -87,8 +108,7 @@ static void regmap_irq_sync_unlock(struct irq_data
> *data)
>  
>  	if (d->clear_status) {
>  		for (i = 0; i < d->chip->num_regs; i++) {
> -			reg = d->chip->status_base +
> -				(i * map->reg_stride * d-
> >irq_reg_stride);
> +			reg = sub_irq_reg(d, d->chip->status_base, i);

How does this work with the case where we have many subregs pointed by
single main-status register bit? If I read this correctly, then the
chip->num_regs can be greater than amount of meaningful main-status
bits and thus greater than amount of map entries.

I don't have BD71828 or BD70528 at home so I haven't tested this. So
hopefully I misunderstand something - but if I don't, then this change
will break the existing main-IRQ functionality. I will visit the office
later this week and I'll see if I have a chance to test this - but I
hope you can check your change still supports the case where one main
status IRQ bit signals more than one sub-register with active IRQs.

Best Regards
	Matti Vaittinen


--
Matti Vaittinen, Linux device drivers
ROHM Semiconductors, Finland SWDC
K
iviharjunlenkki 1E
90220 OULU
FINLAND

~~~ "I don't think so," said Rene Descartes. Just then he vanished ~~~

Simon says - in Latin please.
"non cogito me" dixit Rene Descarte, deinde evanescavit

(Thanks for the translation Simon)



  reply	other threads:[~2021-04-12  6:06 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-11  0:39 [RFC PATCH v3 0/3] Add support for Qualcomm MFD PMIC register layout Guru Das Srinagesh
2021-03-11  0:39 ` [RFC PATCH v3 1/3] regmap-irq: Extend sub-irq to support non-fixed reg strides Guru Das Srinagesh
2021-04-12  6:05   ` Matti Vaittinen [this message]
2021-04-12 11:08     ` Vaittinen, Matti
2021-04-12 18:08       ` Guru Das Srinagesh
2021-03-11  0:39 ` [RFC PATCH v3 2/3] regmap-irq: Add support for POLARITY_HI and POLARITY_LO config regs Guru Das Srinagesh
2021-03-12 12:19   ` Mark Brown
2021-03-15 20:33     ` Guru Das Srinagesh
2021-03-15 20:36       ` Guru Das Srinagesh
2021-03-17 20:42       ` Mark Brown
2021-03-20  2:37         ` Guru Das Srinagesh
2021-03-11  0:39 ` [RFC PATCH v3 3/3] regmap-irq: Modify type_buf handling for IRQ_TYPE_LEVEL_* Guru Das Srinagesh
2021-03-18 18:33 ` (subset) [RFC PATCH v3 0/3] Add support for Qualcomm MFD PMIC register layout Mark Brown
2021-03-18 18:36   ` Mark Brown

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=4abddb76d87a2e6e0d2ad98da0b8349251456158.camel@fi.rohmeurope.com \
    --to=matti.vaittinen@fi.rohmeurope.com \
    --cc=Markus.Elfring@web.de \
    --cc=aghayal@codeaurora.org \
    --cc=bjorn.andersson@linaro.org \
    --cc=broonie@kernel.org \
    --cc=collinsd@codeaurora.org \
    --cc=devicetree@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=gurus@codeaurora.org \
    --cc=joe@perches.com \
    --cc=lee.jones@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=robh+dt@kernel.org \
    --cc=subbaram@codeaurora.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;
as well as URLs for NNTP newsgroup(s).