Re: [GIT PATCHES FOR 3.1] s5p-fimc and noon010pc30 drivers conversion? to media controller API

[Sylwester Nawrocki <snjw23@gmail.com>]

Hi Sakari,

thanks for your comments.





Sakari Ailus <sakari.ailus@iki.fi> wrote:

T>On Thu, Jul 14, 2011 at 10:07:03PM +0300, Sylwester Nawrocki wrote:
>> Hi Mauro,
>
>Hi Sylwester and Mauro,
T>
>> On Thu, 14 Jul 2011 13:27:17 -0300, Mauro Carvalho Chehab
>> <mchehab@redhat.com> wrote:
T>> >Em 08-07-2011 12:25, Sylwester Nawrocki escreveu:
>...
>> >>       s5p-fimc: Remove sclk_cam clock handling
>> >>       s5p-fimc: Limit number of available inputs to one
>> 
>> 
>> >Camera sensors at FIMC input are no longer selected with S_INPUT
>> ioctl.
>> >They will be attached to required FIMC entity through pipeline
>> >re-configuration at the media device level.
>> 
>> 
>> >Why? The proper way to select an input is via S_INPUT. The driver
>> may also
>> >optionally allow changing it via the media device, but it should
>> not be
>> >a mandatory requirement, as the media device API is optional.
>> 
>> The problem I'm trying to solve here is sharing the sensors and
>> mipi-csi receivers between multiple FIMC H/W instances. Previously
>> the driver supported attaching a sensor to only one selected FIMC at
>> compile time. You could, for instance, specify all sensors as the
>> selected FIMC's platform data and then use S_INPUT to choose between
>> them. The sensor could not be used together with any other FIMC. But
>> this is desired due to different capabilities of the FIMC IP
>> instances. And now, instead of hardcoding a sensor assigment to
>> particular video node, the sensors are bound to the media device.
>> The media device driver takes the list of sensors and attaches them
>> one by one to subsequent FIMC instances when it is initializing.
>> Each sensor has a link to each FIMC but only one of them is active
T>> by default. That said an user application can use selected camera by
>> opening corresponding video node. Which camera is at which node can
>> be queried with G_INPUT.
>> 
Tr>> I could try to implement the previous S_INPUT behaviour, but IMHO
>> this would lead to considerable and unnecessary driver code
>> complication due to supporting overlapping APIs.
>
>This sounds quite familiar and similar to OMAP 3 ISP. There's more to
>configure than an S_INPUT ioctl can do. Selecting sensor using S_INPUT
>involves a number of other decisions as well if I'm not mistaken.

Yes, in particular the number of subdevs in the data path may need to be changed which really belongs to the media device driver.
And sensors arbitration between FIMC instances is best done at the media device layer. Same applies to the 2 external clocks for the sensors which are shared between all FIMC IP instances and the sensors.
Thus switching between sensors with S_INPUT would possibly involve pipeline reconfiguration which doesn't sound like a good design.

>
>Sylwester: could you provide an MC graph of the device with possibly a
>few
>sensors attached? AFAIR media-ctl -p and dotfile.

I would be happy to provide this information but I'm in the middle of vacations and cannot really do that at the moment;)
I recall pasting some links to the graph images to v4l irc channel. Here is the working one that most closely depicts current state: 
http://wstaw.org/m/2011/05/26/fimc_graph__.png
(yellow FIMC.n subdevs should not be there and s5p-mipi-csis.1 subdev should have links to all green FIMC.n subdevs).

-- 
Thanks,
Sylwester