All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: William Breathitt Gray <william.gray@linaro.org>
Cc: Linus Walleij <linus.walleij@linaro.org>,
	Bartosz Golaszewski <brgl@bgdev.pl>,
	linux-kernel@vger.kernel.org, linux-gpio@vger.kernel.org,
	Mark Brown <broonie@kernel.org>,
	techsupport@winsystems.com,
	Paul Demetrotion <pdemetrotion@winsystems.com>,
	Michael Walle <michael@walle.cc>
Subject: Re: [PATCH v5 3/3] gpio: ws16c48: Migrate to the regmap API
Date: Mon, 27 Mar 2023 14:26:37 +0300	[thread overview]
Message-ID: <ZCF9bdyefA/oDmdG@smile.fi.intel.com> (raw)
In-Reply-To: <58531b1b2428e4d5d2ea79e721f7ef6450665280.1679845842.git.william.gray@linaro.org>

On Sun, Mar 26, 2023 at 12:25:59PM -0400, William Breathitt Gray wrote:
> The regmap API supports IO port accessors so we can take advantage of
> regmap abstractions rather than handling access to the device registers
> directly in the driver.
> 
> The WinSystems WS16C48 provides the following registers:
> 
>     Offset 0x0-0x5: Port 0-5 I/O
>     Offset 0x6: Int_Pending
>     Offset 0x7: Page/Lock
>     Offset 0x8-0xA (Page 1): Pol_0-Pol_2
>     Offset 0x8-0xA (Page 2): Enab_0-Enab_2
>     Offset 0x8-0xA (Page 3): Int_ID0-Int_ID2
> 
> Port 0-5 I/O provides access to 48 lines of digital I/O across six
> registers, each bit position corresponding to the respective line.
> Writing a 1 to a respective bit position causes that output pin to sink
> current, while writing a 0 to the same bit position causes that output
> pin to go to a high-impedance state and allows it to be used an input.
> Reads on a port report the inverted state (0 = high, 1 = low) of an I/O
> pin when used in input mode. Interrupts are supported on Port 0-2.
> 
> Int_Pending is a read-only register that reports the combined state of
> the INT_ID0 through INT_ID2 registers; an interrupt pending is indicated
> when any of the low three bits are set.
> 
> The Page/Lock register provides the following bits:
> 
>     Bit 0-5: Port 0-5 I/O Lock
>     Bit 6-7: Page 0-3 Selection
> 
> For Bits 0-5, writing a 1 to a respective bit position locks the output
> state of the corresponding I/O port. Writing the page number to Bits 6-7
> selects that respective register page for use.
> 
> Pol_0-Pol_2 are accessible when Page 1 is selected. Writing a 1 to a
> respective bit position selects the rising edge detection interrupts for
> that input line, while writing a 0 to the same bit position selects the
> falling edge detection interrupts.
> 
> Enab_0-Enab_2 are accessible when Page 2 is selected. Writing a 1 to a
> respective bit position enables interrupts for that input line, while
> writing a 0 to that same bit position clears and disables interrupts for
> that input line.
> 
> Int_ID0-Int_ID2 are accessible when Page 3 is selected. A respective bit
> when read as a 1 indicates that an edge of the polarity set in the
> corresponding polarity register was detected for the corresponding input
> line. Writing any value to this register clears all pending interrupts
> for the register.

...

> +static const struct regmap_config ws16c48_regmap_config = {
> +	.reg_bits = 8,
> +	.reg_stride = 1,
> +	.val_bits = 8,
> +	.io_port = true,
> +	.max_register = 0xA,
> +	.wr_table = &ws16c48_wr_table,
> +	.rd_table = &ws16c48_rd_table,
> +	.volatile_table = &ws16c48_volatile_table,
> +	.cache_type = REGCACHE_FLAT,
> +};

Do we need regmap lock?

...

>  /**
>   * struct ws16c48_gpio - GPIO device private data structure
> - * @chip:	instance of the gpio_chip
> - * @io_state:	bit I/O state (whether bit is set to input or output)
> - * @out_state:	output bits state
> + * @map:	regmap for the device
>   * @lock:	synchronization lock to prevent I/O race conditions
>   * @irq_mask:	I/O bits affected by interrupts
> - * @flow_mask:	IRQ flow type mask for the respective I/O bits
> - * @reg:	I/O address offset for the device registers
>   */
>  struct ws16c48_gpio {
> -	struct gpio_chip chip;
> -	unsigned char io_state[6];
> -	unsigned char out_state[6];
> +	struct regmap *map;
>  	raw_spinlock_t lock;
> -	unsigned long irq_mask;
> -	unsigned long flow_mask;
> -	struct ws16c48_reg __iomem *reg;
> +	u8 irq_mask[WS16C48_NUM_IRQS / WS16C48_NGPIO_PER_REG];

Looking at this (and also thinking about the previous patch) perhaps this
should be declared as

	DECLARE_BITMAP(...);

and corresponding bit ops to be used?

>  };

...

> +static int ws16c48_handle_pre_irq(void *const irq_drv_data)
>  {
> +	struct ws16c48_gpio *const ws16c48gpio = irq_drv_data;
>  
> +	/* Lock to prevent Page/Lock register change while we handle IRQ */
> +	raw_spin_lock(&ws16c48gpio->lock);
>  
>  	return 0;
>  }

Hmm... Don't we have irq bus lock and unlock callbacks for this?

...

> +static int ws16c48_handle_post_irq(void *const irq_drv_data)
>  {
> +	struct ws16c48_gpio *const ws16c48gpio = irq_drv_data;
>  
> +	raw_spin_unlock(&ws16c48gpio->lock);
>  
>  	return 0;
>  }

Ditto.

Also shouldn't you annotate them for sparse so it won't complain about
unbalanced locks?

...

> +exit_early:

exit_unlock() ?

>  	raw_spin_unlock_irqrestore(&ws16c48gpio->lock, flags);

> +	return ret;

...

> +	err = regmap_write(map, WS16C48_ENAB, 0x00);

				WS16C48_ENAB + 0

(for the sake of symmetry with the below)?

> +	if (err)
> +		return err;
> +	err = regmap_write(map, WS16C48_ENAB + 1, 0x00);
> +	if (err)
> +		return err;
> +	err = regmap_write(map, WS16C48_ENAB + 2, 0x00);
> +	if (err)
> +		return err;

-- 
With Best Regards,
Andy Shevchenko



  reply	other threads:[~2023-03-27 11:26 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-26 16:25 [PATCH v5 0/3] Migrate the PCIe-IDIO-24 and WS16C48 GPIO drivers to the regmap API William Breathitt Gray
2023-03-26 16:25 ` [PATCH v5 1/3] regmap: Pass irq_drv_data as a parameter for set_type_config() William Breathitt Gray
2023-04-03 21:07   ` Mark Brown
2023-03-26 16:25 ` [PATCH v5 2/3] gpio: pcie-idio-24: Migrate to the regmap API William Breathitt Gray
2023-03-27 10:59   ` Andy Shevchenko
2023-03-26 16:25 ` [PATCH v5 3/3] gpio: ws16c48: " William Breathitt Gray
2023-03-27 11:26   ` Andy Shevchenko [this message]
2023-04-02 14:39     ` William Breathitt Gray
2023-04-03 21:12       ` Mark Brown
2023-04-03 22:20         ` William Breathitt Gray
2023-04-03 22:25           ` 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=ZCF9bdyefA/oDmdG@smile.fi.intel.com \
    --to=andriy.shevchenko@linux.intel.com \
    --cc=brgl@bgdev.pl \
    --cc=broonie@kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michael@walle.cc \
    --cc=pdemetrotion@winsystems.com \
    --cc=techsupport@winsystems.com \
    --cc=william.gray@linaro.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 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.