[PATCH v2 3/4] gpio: realtek: Add driver for Realtek DHC RTD1625 SoC
Michael Walle
mwalle at kernel.org
Thu Apr 30 04:20:16 PDT 2026
Hi,
On Thu Apr 30, 2026 at 11:58 AM CEST, Yu-Chun Lin [林祐君] wrote:
>> >> 3. Hardware Debounce: We also need to support hardware debounce settings per pin,
>> >> which requires custom configuration via set_config mapped to these specific per-pin
>> >> registers.
>> >
>> > Just add a version of an optional .set_config() call to gpio-regmap.c
>> > to handle this using .reg_mask_xlate() per above and add a new
>> > GPIO_REGMAP_CONFIG_OP to the above enum, problem solved.
>> >
>> > If it seems too hard I can write patch 1 & 2 adding this infrastructure
>> > but I bet you can easily see what can be done with gpio-regmap.c
>> > here provided Michael W approves the idea.
>> >
>
> Our .set_config requires mapping specific debounce time values to
> hardware-specific enums and applying a Write-Enable bit.
>
> Would it be better to allow drivers to assign a custom '.set_config' callback
> directly within 'struct gpio_regmap_config'?
Yeah, I don't think there will be much code sharing of
code/functionality for the .set_config callback. A custom
.set_config was proposed many times in the past.
> Additionally, I didn't mention this in my previous email. we also need to
> implement GPIO interrupts. Our hardware design does not fit well with
> 'regmap_irq_chip'. Therefore, I am planning to create our own 'irqdomain' and
> 'irqchip' ops to handle our cascaded interrupts.
>
> Because of this custom IRQ implementation, I would need to use 'readl()/writel()'
> for the IRQ callbacks in the rtd1625 GPIO driver instead of the regmap APIs.
> Do you have any suggestions on how to handle this gracefully while keeping it
> aligned with the regmap infrastructure?
Why can't the MMIO regmap be used for that?
-michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 297 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20260430/7f452d70/attachment.sig>
More information about the linux-arm-kernel
mailing list