Hi,

<snip>

quoted

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.

quoted

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?

quoted

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

quoted

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