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

[zl020895]

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" <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote:
>On Mon, Sep 07, 2026 at 12:20:03PM +0800, zl020895 wrote:
>
>> > 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).
>
>> 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...
>
>> > 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
>