Re: [PATCH v3] DT: Add documentation for the mfd Maxim max77693

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

 




Hi Mark and Jacek,

On Mon, Mar 30, 2015 at 02:20:03PM +0100, Mark Rutland wrote:
> Hi,
> 
> > >> +Optional properties:
> > >> +- maxim,trigger-type : Flash trigger type.
> > >> +	Possible trigger types:
> > >> +		LEDS_TRIG_TYPE_EDGE (0) - Rising edge of the signal triggers
> > >> +			the flash,
> > >> +		LEDS_TRIG_TYPE_LEVEL (1) - Strobe pulse length controls duration
> > >> +			of the flash.
> > >
> > > Surely this is required? What should be assumed if this property isn't
> > > present?
> > 
> > LEDS_TRIG_TYPE_LEVEL allows for an ISP to do e.g. short flash blink
> > before the actual strobe - it is used for eliminating photographs with
> > closed eyes, or can serve for probing ambient light conditions.
> > 
> > With LEDS_TRIG_TYPE_EDGE flash strobe is triggered on rising edge
> > and lasts until programmed timeout expires.
> > 
> > This setting is tightly related to a camera sensor, which generates
> > the strobe signal. Effectively it depends on board configuration.
> 
> My comment wasn't to do with the semantics of eitehr option but rather
> the optionality of the property.
> 
> Surely it's vital to know what this should be, and hence this property
> should be required rather than optional?
> 
> If it isn't required, what would the assumed default be?

I wonder if there's a use case for edge triggering. In level trigger mode,
whichever component generates the trigger signal, determines also the strobe
time (up to the timeout). The sensor or (in the case of lack of the signal
from the sensor) the ISP has the most information on the sensor timing.

The existing as3654a driver only supports level triggering while the chip
can do edge, too.

I'd make level default and perhaps add a V4L2 control / sysfs file to change
this if needed.

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ailus@xxxxxx	XMPP: sailus@xxxxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux