Re: [PATCH v4 5/6] auxdisplay: TM16xx: Add support for I2C-based controllers

[Andy Shevchenko <andriy.shevchenko@intel.com>]

On Tue, Aug 26, 2025 at 12:01:57AM -0400, Jean-François Lessard wrote:
> Le 25 août 2025 11 h 18 min 27 s HAE, Andy Shevchenko <andriy.shevchenko@intel.com> a écrit :
> >On Sun, Aug 24, 2025 at 11:32:31PM -0400, Jean-François Lessard wrote:

...

> >Can we use regmap for all parts of the driver? Why not?
> 
> These controllers implement custom 2-wire/3-wire protocols that share
> sufficient commonalities with I2C/SPI to leverage those subsystems, but are not
> fully compliant with standard register-based access patterns.
> 
> Specific regmap incompatibilities:
> 
> I2C protocol:
> - Dynamic addressing: slave address embedded in command byte (data[0] >> 1)

Isn't this called paging? Or actually we have also non-standard
(non-power-of-2) regmap implementations, perhaps one of them
(7 + 9) if exists is what you need?

> - Custom message flags: requires I2C_M_NO_RD_ACK for reads

Hmm... If we have more than one device like this, we might implement the
support in regmap. Or, perhaps, the custom regmap IO accessors can solve this.

> SPI protocol:
> - Inter-transfer timing: mandatory TM16XX_SPI_TWAIT_US delay between
> command/data

One may implement custom regmap IO accessors.

> - CS control: requires cs_change = 0 to maintain assertion across phases
> 
> Regmap's I2C/SPI bus implementations use fixed addressing and standard transfer
> patterns without support for these protocol-specific requirements. A custom
> regmap bus would internally call these same helper functions without providing
> practical benefit.

regmap provides a few benefits on top of the raw implementations. First of all,
it takes care about synchronisation (and as a side effect enables
configurations of the multi-functional HW, if ever needed in this case). It also
gives a debugfs implementation, and paging support (if it's what we need).
And many more...

> The explicit transfer approach better reflects the actual hardware protocol
> requirements.

That said, please, try to look into it closer.

-- 
With Best Regards,
Andy Shevchenko