Hi Rob, On Tue, Sep 19, 2017 at 03:00:11PM -0500, Rob Herring wrote: > On Mon, Sep 18, 2017 at 4:56 PM, Sakari Ailus > <sakari.ailus@xxxxxxxxxxxxxxx> wrote: > > Hi Rob, > > > > > > Rob Herring wrote: > >> > >> On Mon, Sep 11, 2017 at 11:00:04AM +0300, Sakari Ailus wrote: > >>> > >>> Document optional lens-focus and flash properties for the smiapp driver. > >>> > >>> Signed-off-by: Sakari Ailus <sakari.ailus@xxxxxxxxxxxxxxx> > >>> --- > >>> Documentation/devicetree/bindings/media/i2c/nokia,smia.txt | 2 ++ > >>> 1 file changed, 2 insertions(+) > >> > >> > >> Acked-by: Rob Herring <robh@xxxxxxxxxx> > > > > > > Thanks for the ack. There have been since a few iterations of the set, and > > the corresponding patch in v13 has minor changes to this: > > My review script can't deal with subject changes... > > > <URL:http://www.spinics.net/lists/linux-media/msg121929.html> > > > > Essentially "flash" was renamed to "flash-leds" as the current flash devices > > we have are all LEDs and the referencing assumes LED framework's ways to > > describe LEDs. The same change is present in the patch adding the property > > So we're kind of creating a binding that mirrors the gpio bindings > (*-gpios) which is a bit of an oddball as all other bindings have gone > with a fixed property name and then a *-names property to name them. It could be that "flash-leds" will remain the only one. Depending on whether anyone would ever want to support a Xenon flash in which case we could add a property for "flash-xenon" or such. Quite possibly not; LEDs have improved in luminosity a lot over the recent years and aren't that far from tiny Xenon flash devices. I don't remember seeing a mobile phone less than five years or so with a Xenon flash. > The main downside to this form is a prefixed property name is harder > to parse and validate. So perhaps we should follow the more common > pattern, but we're not really describing a h/w connection just an > association. And now we also have the trigger source binding to > associate LEDs with device nodes, so perhaps that should be used here. > We shouldn't really have 2 ways to associate things in DT even if how > that gets handled in the kernel is different. trigger-sources is not really the same thing: it's present in the LED node, not in the sensor to start with. The LED driver has no knowledge of the Media device --- the sensor driver gains this information through the endpoints. The sensor driver would need to find the node which contains a phandle back to the sensor node. Having this property in the sensor gives the association information between the sensor and the LED. It could be present elsewhere, e.g. the master device with DMA engines if there's no association with a sensor. Some sensors do support strobing the flash, too. The flash type (Xenon or LED) needs to be known to the strobe source (sensor). The strobe wiring may not be there: the module vendors often omit that. Or it could be omitted on the board. That's the case with LED flashes; they can mostly be triggered using I²C as well albeit less precisely. -- Kind regards, Sakari Ailus sakari.ailus@xxxxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
