From: Linus Walleij <linus.walleij@linaro.org>
To: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
Cc: Mark Brown <broonie@kernel.org>,
"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
konrad.dybcio@somainline.org, marijn.suijten@somainline.org,
martin.botka@somainline.org, phone-devel@vger.kernel.org,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@vger.kernel.org>, Rob Herring <robh+dt@kernel.org>
Subject: Re: [PATCH 1/2] pinctrl: Add driver for Awinic AW9523/B I2C GPIO Expander
Date: Sun, 10 Jan 2021 20:35:00 +0100 [thread overview]
Message-ID: <CACRpkdYmVpEZMruu3UcqiGr2q7xSdTQKmwnu7eq2-MPJte8ATA@mail.gmail.com> (raw)
In-Reply-To: <744125a7-ffb6-a3f5-70cb-2ab48fcf31b8@somainline.org>
On Sun, Jan 10, 2021 at 3:32 PM AngeloGioacchino Del Regno
<angelogioacchino.delregno@somainline.org> wrote:
> So, I've retried some basic usage of the regcache, relevant snippets here:
> static bool aw9523_volatile_reg(struct device *dev, unsigned int reg)
> {
>
> return reg == AW9523_REG_IN_STATE(0) ||
> reg == AW9523_REG_IN_STATE(AW9523_PINS_PER_PORT) ||
> reg == AW9523_REG_CHIPID;
> }
(...)
> Since REG_IN_STATE is used to read the GPIO input level, it's not
> cacheable,
Fair enough.
> then CHIPID was set as not cacheable for safety: that may be
> avoided, but that may make no sense.. since it's a one-time readout for
> init putposes, it'd be useless to keep it cached.
I guess.
> Then, the set_bit/clear_bit in aw9523_irq_mask(), aw9523_irq_unmask were
> replaced with calls to regmap_update_bits_async, example:
>
> regmap_update_bits_async(awi->regmap,
> AW9523_REG_INTR_DIS(d->hwirq),
> BIT(n), BIT(n));
>
> Where of course the value is either BIT(n) or 0 for mask and unmask
> respectively.
> Also, the bus_sync_unlock callback was changed as follows:
>
> static void aw9523_irq_bus_sync_unlock(struct irq_data *d)
>
> {
> struct aw9523 *awi = gpiochip_get_data(irq_data_get_irq_chip_data(d));
> regcache_mark_dirty(awi->regmap);
> regcache_sync_region(awi->regmap, AW9523_REG_INTR_DIS(0),
> AW9523_REG_INTR_DIS(AW9523_PINS_PER_PORT));
> mutex_unlock(&awi->irq->lock);
(...)
> One of the biggest / oddest issues that I get when trying to use
> regcache is that I'm getting badbadbad scheduling while atomic warnings
> all over and I don't get why, since regcache_default_sync is just
> calling _regmap_write, which is exactly what (non _prefix) regmap_write
> also calls...
OK that is the real problem to solve then.
> As a reference, this is one out of "many" (as you can imagine) stacktraces:
>
> <3>[ 1.061428] BUG: scheduling while atomic: kworker/3:1/119/0x00000000
(...)
> <4>[ 1.063134] wait_for_completion_timeout+0x8c/0x110
> <4>[ 1.063257] qup_i2c_wait_for_complete.isra.18+0x1c/0x80
> <4>[ 1.063429] qup_i2c_xfer_v2_msg+0x2d4/0x3f0
> <4>[ 1.063543] qup_i2c_xfer_v2+0x290/0xa28
> <4>[ 1.063652] __i2c_transfer+0x16c/0x380
> <4>[ 1.063798] i2c_transfer+0x5c/0x138
> <4>[ 1.063903] i2c_transfer_buffer_flags+0x58/0x80
> <4>[ 1.064060] regmap_i2c_write+0x1c/0x50
> <4>[ 1.064168] _regmap_raw_write_impl+0x35c/0x688
> <4>[ 1.064285] _regmap_bus_raw_write+0x64/0x80
> <4>[ 1.064440] _regmap_write+0x58/0xa8
> <4>[ 1.064545] regcache_default_sync+0xcc/0x1a0
> <4>[ 1.064660] regcache_sync_region+0xdc/0xe8
> <4>[ 1.064811] aw9523_irq_bus_sync_unlock+0x30/0x48
> <4>[ 1.064931] __setup_irq+0x798/0x890
> <4>[ 1.065034] request_threaded_irq+0xe0/0x198
> <4>[ 1.065188] devm_request_threaded_irq+0x78/0xf8
> <4>[ 1.065311] gpio_keyboard_probe+0x2a8/0x468
scheduling while atomic happens when this trace gets called with interrupts
disabled, usually because someone has taken a spinlock.
Looking in __setup_irq() it looks safe.
I would turn on lock debugging (lockdep) and see if I can find it that way.
Yours,
Linus Walleij
next prev parent reply other threads:[~2021-01-10 19:35 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-09 14:02 [PATCH 0/2] Add Awinic AW9523(B) I2C GPIO Expander driver AngeloGioacchino Del Regno
2021-01-09 14:02 ` [PATCH 1/2] pinctrl: Add driver for Awinic AW9523/B I2C GPIO Expander AngeloGioacchino Del Regno
2021-01-09 17:24 ` kernel test robot
2021-01-09 22:12 ` Linus Walleij
2021-01-09 23:12 ` AngeloGioacchino Del Regno
2021-01-09 22:11 ` Linus Walleij
2021-01-09 23:11 ` AngeloGioacchino Del Regno
2021-01-10 0:24 ` Linus Walleij
2021-01-10 14:32 ` AngeloGioacchino Del Regno
2021-01-10 14:56 ` AngeloGioacchino Del Regno
2021-01-10 19:35 ` Linus Walleij [this message]
2021-01-11 17:54 ` AngeloGioacchino Del Regno
2021-01-11 13:10 ` Mark Brown
2021-01-09 14:02 ` [PATCH 2/2] dt-bindings: pinctrl: Add bindings for Awinic AW9523/AW9523B AngeloGioacchino Del Regno
2021-01-09 22:14 ` Linus Walleij
2021-01-09 23:13 ` AngeloGioacchino Del Regno
2021-01-10 17:18 ` Rob Herring
2021-01-25 18:21 [PATCH 1/2] pinctrl: Add driver for Awinic AW9523/B I2C GPIO Expander AngeloGioacchino Del Regno
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=CACRpkdYmVpEZMruu3UcqiGr2q7xSdTQKmwnu7eq2-MPJte8ATA@mail.gmail.com \
--to=linus.walleij@linaro.org \
--cc=angelogioacchino.delregno@somainline.org \
--cc=broonie@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=konrad.dybcio@somainline.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marijn.suijten@somainline.org \
--cc=martin.botka@somainline.org \
--cc=phone-devel@vger.kernel.org \
--cc=robh+dt@kernel.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).