From: William Breathitt Gray <william.gray@linaro.org>
To: Mark Brown <broonie@kernel.org>
Cc: linus.walleij@linaro.org, brgl@bgdev.pl,
andriy.shevchenko@linux.intel.com, linux-gpio@vger.kernel.org,
linux-kernel@vger.kernel.org, michael@walle.cc
Subject: Re: [PATCH v2 2/4] regmap-irq: Add handle_mask_sync() callback
Date: Mon, 21 Nov 2022 20:00:02 -0500 [thread overview]
Message-ID: <Y3wfEgejAVCsUNcI@fedora> (raw)
In-Reply-To: <Y3ZMga3nphqmAtka@fedora>
[-- Attachment #1: Type: text/plain, Size: 3427 bytes --]
On Thu, Nov 17, 2022 at 10:00:17AM -0500, William Breathitt Gray wrote:
> On Tue, Nov 15, 2022 at 05:14:14PM +0000, Mark Brown wrote:
> > On Thu, Nov 10, 2022 at 08:55:51PM -0500, William Breathitt Gray wrote:
> >
> > > Provide a public callback handle_mask_sync() that drivers can use when
> > > they have more complex IRQ masking logic. The default implementation is
> > > regmap_irq_handle_mask_sync(), used if the chip doesn't provide its own
> > > callback.
> >
> > Can you provide examples of something that would make sense to
> > open code in a driver rather than factoring out? It looks like
> > this has been added due to one of the devices you're looking at
> > for some reason disabling it's upstream interrupt when all of the
> > downstream interrupts are masked, while weird that doesn't seem
> > especally device specific.
>
> Sure, I actually intend to use this callback for the 104-idi-48 module
> as well in the v3 submission so I'll describe that situations well.
>
> For the 104-dio-48e we have the following:
>
> Base Address +B (Write): Enable Interrupt
> Base Address +B (Read): Disable Interrupt
> Base Address +F (Read/Write): Clear Interrupt
>
> So for 104-dio-48e, any write to 0xB will enable interrupts, while any
> read will disable interrupts; interrupts are with either a read or any
> write to 0xF. There's no status register either so software just has to
> assume that if an interrupt is raised then it was for the
> 104-dio-48e device.
>
> For the 104-idi-48, we do get a status register and some basic masking
> but it's broken down by banks rather than individual GPIO; there are six
> 8-bit banks (Port 0 Low Byte, Port 0 Mid Byte, Port 0 High Byte, Port 1
> Low Byte, Port 1 Mid Byte, Port 1 High Byte):
>
> Base Address + 0 (Read/Write): Port 0 Low Byte
> Base Address + 1 (Read/Write): Port 0 Mid Byte
> Base Address + 2 (Read/Write): Port 0 High Byte
> Base Address + 3: N/A
> Base Address + 4 (Read/Write): Port 1 Low Byte
> Base Address + 5 (Read/Write): Port 1 Mid Byte
> Base Address + 6 (Read/Write): Port 1 High Byte
> Base Address + 7 (Read): IRQ Status Register/IRQ Clear
> Bit 0-5: Respective Bank IRQ Statuses
> Bit 6: IRQ Status (Active Low)
> Bit 7: IRQ Enable Status
> Base Address + 7 (Write): IRQ Enable/Disable
> Bit 0-5: Respective Bank IRQ Enable/Disable
>
> In this case, masking a bank will mask all 8 GPIO within that bank;
> so ideally I want a way to only mask a bank when all GPIO are masked,
> and unmasking when at least one is unmasked.
>
> Are there existing ways to support these kinds of configuration in
> regmap_irq?
>
> William Breathitt Gray
After trying to implement a handle_mask_sync() callback for the
104-idi-48 I discovered that it's not so straight-forward a task. The
mask_buf parameter is unsigned int so I can only represent 32 GPIO at a
time.
I could set the struct regmap_irq_chip num_regs member to '2' to
increase the number of mask_buf elements, but that creates side effects
because the regmap-irq API believes there there are more registers than
the device actually has.
For now with the 104-idi-48 module utilizing the regmap-irq API, we'll
have to leave it where masking one GPIO line masks the entire bank, and
vice versa for unmasking.
William Breathitt Gray
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2022-11-22 17:07 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-11 1:55 [PATCH v2 0/4] Migrate i8255 GPIO drivers to regmap API William Breathitt Gray
2022-11-11 1:55 ` [PATCH v2 1/4] gpio: regmap: Always set gpio_chip get_direction William Breathitt Gray
2022-11-13 12:40 ` Andy Shevchenko
2022-11-13 13:21 ` William Breathitt Gray
2022-11-16 11:34 ` Robert Marko
2022-11-16 15:41 ` Michael Walle
2022-11-16 15:54 ` Andy Shevchenko
2022-11-17 14:22 ` William Breathitt Gray
2022-11-17 14:36 ` Michael Walle
2022-11-11 1:55 ` [PATCH v2 2/4] regmap-irq: Add handle_mask_sync() callback William Breathitt Gray
2022-11-13 12:42 ` Andy Shevchenko
2022-11-13 13:08 ` William Breathitt Gray
2022-11-13 13:11 ` Andy Shevchenko
2022-11-15 17:14 ` Mark Brown
2022-11-17 15:00 ` William Breathitt Gray
2022-11-22 1:00 ` William Breathitt Gray [this message]
2022-11-11 1:55 ` [PATCH v2 3/4] gpio: 104-idi-48: Migrate to regmap API William Breathitt Gray
2022-11-11 1:55 ` [PATCH v2 4/4] gpio: i8255: " William Breathitt Gray
2022-11-13 12:52 ` Andy Shevchenko
2022-11-13 14:07 ` William Breathitt Gray
2022-11-13 14:13 ` William Breathitt Gray
2022-11-14 13:14 ` Andy Shevchenko
2022-11-17 16:18 ` Michael Walle
2022-11-17 16:21 ` Mark Brown
2022-11-17 16:30 ` Michael Walle
2022-11-18 11:51 ` Mark Brown
2022-11-20 16:57 ` William Breathitt Gray
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=Y3wfEgejAVCsUNcI@fedora \
--to=william.gray@linaro.org \
--cc=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 \
/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.