Re: [PATCH 28/57] media: Add ovxxxx_16bit_addr_reg_helpers.h

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Driver Development]     [Linux Driver Backports]     [DMA Engine]     [Linux GPIO]     [Linux SPI]     [Video for Linux]     [Linux USB Devel]     [Linux Coverity]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux