Re: [PATCH 00/72] media: i2c: Reduce cargo-cult

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

On Thu, Jul 24, 2025 at 02:20:10PM +0000, Tarang Raval wrote:
> > > > > 2. In the regulator code, you can reduce boilerplate by using
> > > > >    devm_regulator_bulk_get_enable().
> > > >
> > > > devm_regulator_bulk_get_enable() doesn't seem to be a good idea. You
> > > > generally don't want to enable power everywhere unconditionally, and
> > > > sensors very often need a guaranteed power up sequence.
> > >
> > > The regulators are optional, we supply power to the camera sensor directly
> > > through dedicated power rails and there is no strict enable sequence
> > > required in this case.
> > 
> > What exactly do you mean by "this case" ? Are you talking about one
> > particular sensor ? One particular camera module ?
> 
> Laurent, by “this case” I meant the common scenario where power to the 
> camera sensor is supplied by a PMIC regulator that is always-on. In such 
> setups, the regulator is fixed and cannot be enabled or disabled from the 
> driver, the sensor is always powered.
> 
> This is what I’ve seen in most platforms, where the CSI input connector 
> provides fixed 3.3V/1.8V power rails directly to the camera module.
> 
> Of course, if the camera supply comes from a dedicated regulator controlled 
> via a GPIO, then the driver would need to handle enable/disable sequencing 
> explicitly. But I’m specifically referring to the first case, where the power rails 
> are always-on.

How does the sensor driver know which of those two cases it is dealing
with ?

> Mark, depending on the hardware, the power rails could come either from a 
> PMIC or from a regulator controlled by GPIO, but I’m talking about the always-on 
> PMIC case here.

-- 
Regards,

Laurent Pinchart