Re:Re: Re: [PATCH v6 08/13] gpio: regmap: support write_data_after_dir and girq

Hi Andy,

Thanks for the bxtwc pointer.

I looked at mapping PL061 onto regmap-irq. Status/mask/ack (MIS/IE/IC)
could fit, but PL061 still needs the chained demux plus IS/IBE/IEV type
programming (including EDGE_BOTH) and the existing gpiochip immutable
helpers. That looks like a poor fit versus idi-48/bxtwc-style chips, and
switching the long-standing ARM PL061 path from chained to threaded
regmap-irq seems risky.

What I plan for the next round (without extending gpio-regmap with girq):
keep the custom irqchip + chained handler, create the irq_domain in
gpio-pl061, and pass it via config.irq_domain to gpio-regmap.

Does that match what you had in mind, or do you still prefer a
regmap-irq-based approach?

Best regards,
Long Zhao

At 2026-09-07 12:45:53, "Andy Shevchenko" [off-list ref] wrote:

On Mon, Sep 07, 2026 at 12:20:03PM +0800, zl020895 wrote:

quoted

quoted

Are you going to fix this HW in the next version of the SoC?

No — Ambarella does not use write_data_after_dir. It only preserves the
existing ARM PL061 quirk already documented in gpio-pl061 (data writes
ignored while the pin is still an input). Only pl061_arm sets the flag.

Ah, this is a good news!

In any case when documenting that flag, please also mention that any new HW
should not use it as it's considered buggy (glitches during direction change
are guaranteed).

quoted

I will also make the first gpio_regmap_set() conditional so the quirk
path writes once after direction_output, not twice.

I see that original pl061 actually writes twice. TBH I don't know the best
effort here and if it's really required to do so. Probably others have
better ideas...

quoted

quoted

This needs to be in a separate update. Also we need to understand why
it is required.

OK, girq will be a separate patch. PL061 keeps a custom chained
irqchip (not regmap-irq); gpio_regmap today only takes irq_domain or
regmap_irq_chip, so we passed girq to keep the usual gpio_irq_chip +
gpiochip_add flow. Open to using a caller-created irq_domain instead if
you prefer.

If there is a chained IRQ, look how PMIC drivers usually do similar setups.
First what comes to my mind is drivers/mfd/intel_soc_pmic_bxtwc.c.

-- 
With Best Regards,
Andy Shevchenko