linux-kernel - Re: [PATCH/RFC v4 00/21] LED / flash API integration

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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/