lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-id: <53EC90D9.6080702@samsung.com> Date: Thu, 14 Aug 2014 12:35:05 +0200 From: Jacek Anaszewski <j.anaszewski@...sung.com> To: Sakari Ailus <sakari.ailus@....fi> Cc: linux-leds@...r.kernel.org, devicetree@...r.kernel.org, linux-media@...r.kernel.org, linux-kernel@...r.kernel.org, kyungmin.park@...sung.com, b.zolnierkie@...sung.com Subject: Re: [PATCH/RFC v4 00/21] LED / flash API integration On 08/14/2014 07:03 AM, Sakari Ailus wrote: > Hi Jacek, > > On Thu, Aug 07, 2014 at 10:21:14AM +0200, Jacek Anaszewski wrote: >> On 08/06/2014 08:53 AM, Sakari Ailus wrote: >>> Hi Jacek, >>> >>> On Fri, Jul 11, 2014 at 04:04:03PM +0200, Jacek Anaszewski wrote: >>> ... >>>> 1) Who should register V4L2 Flash sub-device? >>>> >>>> LED Flash Class devices, after introduction of the Flash Manager, >>>> are not tightly coupled with any media controller. They are maintained >>>> by the Flash Manager and made available for dynamic assignment to >>>> any media system they are connected to through multiplexing devices. >>>> >>>> In the proposed rough solution, when support for V4L2 Flash sub-devices >>>> is enabled, there is a v4l2_device created for them to register in. >>>> This however implies that V4L2 Flash device will not be available >>>> in any media controller, which calls its existence into question. >>>> >>>> Therefore I'd like to consult possible ways of solving this issue. >>>> The option I see is implementing a mechanism for moving V4L2 Flash >>>> sub-devices between media controllers. A V4L2 Flash sub-device >>>> would initially be assigned to one media system in the relevant >>>> device tree binding, but it could be dynamically reassigned to >>>> the other one. However I'm not sure if media controller design >>>> is prepared for dynamic modifications of its graph and how many >>>> modifications in the existing drivers this solution would require. >>> >>> Do you have a use case where you would need to strobe a flash from multiple >>> media devices at different times, or is this entirely theoretical? Typically >>> flash controllers are connected to a single source of hardware strobe (if >>> there's one) since the flash LEDs are in fact mounted next to a specific >>> camera sensor. >> >> I took into account such arrangements in response to your message >> [1], where you were considering configurations like "one flash but >> two >> cameras", "one camera and two flashes". And you also called for >> proposing generic solution. >> >> One flash and two (or more) cameras case is easily conceivable - >> You even mentioned stereo cameras. One camera and many flashes >> arrangement might be useful in case of some professional devices which >> might be designed so that they would be able to apply different scene >> lighting. I haven't heard about such devices, but as you said >> such a configuration isn't unthinkable. >> >>> If this is a real issue the way to solve it would be to have a single media >>> device instead of many. >> >> I was considering adding media device, that would be a representation >> of a flash manager, gathering all the registered flashes. Nonetheless, >> finally I came to conclusion that a v4l2-device alone should suffice, >> just to provide a Flash Manager representation allowing for >> v4l2-flash sub-devices to register in. >> All the features provided by the media device are useless in case >> of a set of V4L2 Flash sub-devices. They couldn't have any linkage >> in such a device. The only benefit from having media device gathering >> V4L2 Flash devices would be possibility of listing them. > > Not quite so. The flash is associated to the sensor (and lens) using the > group ID in the Media controller. The user space doesn't need to "know" this > association. > > More complex use cases such as the above may need extensions to the Media > controller API. I think that I have unnecessarily complicated the issue. Generally there will be always one media controller created for all camera sensors available in the system. If there is a single media controller then we can easily use async subdev registration API. A media-dev driver would have to parse list of flash device phandles from the ISP device's DT node and register them as async sub-devices. Best Regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists