Re: [RFC/PATCH 0/1] New subdev sensor operation g_interface_parms

[Stanimir Varbanov <svarbanov@mm-sol.com>]

Hi,

<snip>
>> Sorry, I accept different opinions, and in the end only one of the two
>> possibilities will be implemented, and either way it'll all work in the
>> end, but, I don't buy either of these arguments.
> 
>> Complexity - the code is
>> already there, it is working, it is simple, it has not broken since it has
>> been implemented. I had it hard-coded in the beginning and I went over to
>> negotiation and never regretted it.
> 
> First of all, it seems that this discussion is heavily parallel i/f
> oriented, and soc_camera focused, and it's just not like that.
> 

yes, it seems that is correct. My patch just get back on host side some
sensor dynamic parameters and it doesn't pretending for any negotiation.

> Now, _just_ for soc_camera framework, yeah... it works and it's there, but
> still not providing a solution for other v4l2_subdev users (like Media
> Controller).
> 

I already start looking into soc_camera code, but I'm so confused. :(

> Complexity comes only when trying to make this truly generic, and avoid
> fragmentation of solutions (1 for soc, 1 for MC), plus adding support for
> serial (MIPI) interfaces
> 
> Now, also, the patch originally proposed by Stan doesn't actually deal with
> putting polarities as part of the interface parameters, which is something
> you're currently negotiating in soc_camera framework, again, just for
> parallel interfaces.
> 
> Now, just for the sake of clarifying my understanding, I guess what you're
> saying is to make sensor driver expose all possible polarities and physical
> details configurable, and make the platform data limit the actual options due to the physical layout.
> 
> For example, if in my board A, I have:
> 
> 	- OV5640 sensor driver, which supports both Parallel and CSI2
>         Interfaces (with up to 2 datalanes)
> 	- Rx subdev (or host) driver(s) which support Parallel, CSI2-A and
>         CSI2-B interfaces (with 2 and 1 datalanes respectively).
> 

If the sensor is physically connected as parallel and serial the board
code should dictates the preferred interface, IMO. Or ...

> I should specify in my boardfile integration details, such as the
> sensor is actually wired to the CSI2-B I/f, so make the sensor
> negotiate with the other side of the bus and enable CSI2 i/f with
> given details, like just use 1 datalane, and match datalane
> position/polarity.
> 
> Am I understanding right?
> 
>> Hardware damage - if this were the case, I'd probably be surrounded only
>> by bricks. How configuring a wrong hsync polarity can damage your
>> hardware?
> 
> Ok, I'll regret my statement on this one. I guess I was a bit too dramatic
> to point out consequences of HW mismatches. Nevermind this.
> 

:)

> Regards,
> Sergio
> 
>> Thanks
>> Guennadi
>> ---
>> Guennadi Liakhovetski, Ph.D.
>> Freelance Open-Source Software Developer
>> http://www.open-technology.de/
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


-- 
Best regards,
Stan