On Mon, Jun 15, 2009 at 12:33 AM, Guennadi Liakhovetski<g.liakhovetski@xxxxxx> wrote: > On Fri, 12 Jun 2009, Hans Verkuil wrote: > >> On Friday 12 June 2009 14:59:03 Guennadi Liakhovetski wrote: >> > On Fri, 12 Jun 2009, Hans Verkuil wrote: >> > >> > > > 1. it is very unusual that the board designer has to mandate what signal >> > > > polarity has to be used - only when there's additional logic between the >> > > > capture device and the host. So, we shouldn't overload all boards with >> > > > this information. Board-code authors will be grateful to us! >> > > >> > > I talked to my colleague who actually designs boards like that about what >> > > he would prefer. His opinion is that he wants to set this himself, rather >> > > than leave it as the result of a software negotiation. It simplifies >> > > verification and debugging the hardware, and in addition there may be >> > > cases where subtle timing differences between e.g. sampling on a falling >> > > edge vs rising edge can actually become an important factor, particularly >> > > on high frequencies. Let me guess, your coworker is a hardware designer? Letting hardware people do hardware design is usually a good idea, but I'm yet to see good software written by hardware people. =) >> > I'd say this is different. You're talking about cases where you _want_ to >> > be able to configure it explicitly, I am saying you do not have to _force_ >> > all to do this. Now, this selection only makes sense if both are >> > configurable, right? In this case, e.g., pxa270 driver does support >> > platform-specified preference. So, if both the host and the client can >> > configure either polarity in the software you _can_ still specify the >> > preferred one in platform data and it will be used. >> > >> > I think, the ability to specify inverters and the preferred polarity >> > should cover all possible cases. >> >> In my opinion you should always want to set this explicitly. This is not >> something you want to leave to chance. Say you autoconfigure this. Now >> someone either changes the autoconf algorithm, or a previously undocumented >> register was discovered for the i2c device and it can suddenly configure the >> polarity of some signal that was previously thought to be fixed, or something >> else happens causing a different polarity to be negotiated. > > TBH, the argumentation like "someone changes the autoconf algorithm" or > "previously undocumented register is discovered" doesn't convince me. In > any case, I am adding authors, maintainers and major contributors to > various soc-camera host drivers to CC and asking them to express their > opinion on this matter. I will not add anything else here to avoid any > "unfair competition":-) they will have to go a couple emails back in this > thread to better understand what is being discussed here. I think automatic negotiation is a good thing if it is implemented correctly. Actually, i think modelling software after hardware is a good thing and from that perspective the soc_camera was (and still is) a very good fit for our on-chip SoC. Apart from host/sensor separation, the main benefits in my mind are autonegotiation and separate configuration for camera sensor, capture interface and board. I don't mind doing the same outside soc_camera, and I agree with Hans that in some cases it's nice to hard code and skip the "magic" negotiation. I'm however pretty sure the soc_camera allows hard coding though, so in that case you get the best of two worlds. Cheers, / magnus -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
