Re:Re: [PATCH v7 00/15] Ambarella CV75 SoC minimal bring-up

[zl020895]

Thanks Bart, Linus, Andy.

ACK: GPIO bits through the GPIO tree, then an IB for the SoC tree.
I will keep a unified series for now.

regmap-irq cannot do PL061 type (IS/IBE/IEV, both-edge) plus the
AMBA chained demux.

Two options for v8 — Andy, which do you prefer?
  1) Convert PL061 MMIO to regmap only. Keep the existing gpio_chip
     and irqchip/girq (double-write stays in the driver). Ambarella
     layout can be a follow-up on that. No gpio-regmap yet.

  2) After (1), also move get/set/direction to gpio-regmap. IRQ
     would stay a custom PL061 irqchip (not regmap-irq). I am not
     sure we can avoid a way to get the gpio_chip for
     gpiochip_*_irq() / the chained handler.

I am leaning to (1) for v8.

Best regards,
Long Zhao

在 2026-09-16 18:23:45，"Andy Shevchenko" <andriy.shevchenko@xxxxxxxxxxxxxxx> 写道：
>On Wed, Sep 16, 2026 at 11:42:56AM +0200, Linus Walleij wrote:
>> On Wed, Sep 16, 2026 at 11:14 AM Bartosz Golaszewski <brgl@xxxxxxxxxx> wrote:
>> > On Tue, 15 Sep 2026 13:15:30 +0200, Long Zhao via B4 Relay
>> > <devnull+longzhao.ambarella.com@xxxxxxxxxx> said:
>> > > This series adds minimal Ambarella CV75 support for early bring-up with
>> > > a serial console: DT bindings, RCT clocks, pinctrl, PL061 GPIO via
>> > > gpio-regmap, 8250_dw UART quirks, ARCH_AMBARELLA, CV75 EVK DT, and
>> > > MAINTAINERS.
>> > >
>> > > This is a single unified series. Please apply via the SoC
>> > > tree; subsystem maintainers are Cc'd for their pieces.
>> >
>> > I would prefer to take the GPIO regmap bits through the GPIO tree and provide
>> > an immutable branch to the SoC tree as it has potential for conflicts that
>> > early into the cycle.
>> 
>> Queue them up and send us the IB if you think they are ready!
>> 
>> Long can probably send a PR based on that IB for the rest to the
>> SoC tree, a bit tricksy but it works.
>
>I'm still unsure why we can't use IRQ facility from gpio-regmap.
>Can you have a look there?
>
>With that being said, I'm not sure that the patch that exposing gpio_chip
>from gpio-regmap is justified.
>
>The whole GPIO rework needs a bit more routine work (resplitting, refactoring,
>et cetera), so later we may see clearer what's going on.
>
>-- 
>With Best Regards,
>Andy Shevchenko
>