Hi Laurent, Andy, On Fri, Feb 10, 2023 at 06:39:11PM +0200, Laurent Pinchart wrote: > On Fri, Feb 10, 2023 at 05:42:25PM +0200, Andy Shevchenko wrote: > > On Fri, Feb 10, 2023 at 02:26:31PM +0200, Sakari Ailus wrote: > > > On Fri, Feb 10, 2023 at 01:45:10PM +0200, Laurent Pinchart wrote: > > > > Regarding the width-specific versions of the helpers, I really think > > > > encoding the size in the register macros is the best option. It makes > > > > life easier for driver authors (only one function to call, no need to > > > > think about the register width to pick the appropriate function in each > > > > call) and reviewers (same reason), without any drawback in my opinion. > > > > > > As I noted previously, this works well for drivers that need to access > > > registers with multiple widths, which indeed applies to the vast majority > > > of camera sensor drivers, but not to e.g. flash or lens VCM drivers. Fixed > > > width registers are better served with a width-specific function. But these > > > can be always added later on. > > > > Again, we can extend regmap to have something like > > > > int (*reg_width)(regmap *, offset) > > > > callback added that will tell the regmap bus underneath what size to use. > > > > In the driver one will define the respective method to return these widths. > > I don't think that's worth it, it would make drivers quite complex > compared to encoding the register width in the register address macros. > We're dealing with devices that have hundreds of registers of various > widths interleaved, a big switch/case for every write isn't great. I'd really prefer the register width information kept as close as possible to the register address, and most probably the best way is to be part of the same macro. -- Kind regards, Sakari Ailus
