> On Wed, 17 Jun 2009, Hans Verkuil wrote:
>
>> It is my strong opinion that while autonegotiation is easy to use, it is
>> not a wise choice to make. Filling in a single struct with the bus
>> settings to use for each board-subdev combination (usually there is only
>> one) is simple, straight-forward and unambiguous. And I really don't see
>> why that should take much time at all. And I consider it a very good
>> point
>> that the programmer is forced to think about this for a bit.
>
> Ok, my opinion is, that we should keep autonegotiation, but if you like,
> we can print a BIG-FAT-WARNING if both polarities are supported and no
> platform preference is set.
I'd rather see a message stating which bus settings were chosen. That way
if something fails in the future you can compare which bus settings were
chosen in the past with the new bus settings and see if something changed
there.
> I think, we've heard all opinions, unless someone would like to add
> something? Would it be fair to ask Mauro to make a decision? Or we can
> just count votes (which I would obviously prefer),
Obviously :-) Since the only non-soc driver that needs this right now is
tvp514x I'm pretty sure you'll get the most votes :-)
But this is something that should be decided on technical merits, and not
on what is easier for converting soc-camera. I'm not saying that is your
only or main reason for wanting to keep autonegotiation, but it no doubt
plays a role (perfectly understandable, BTW).
Just note that it is exactly my experiences with dm646x and with closely
working with the hardware team that made me realize the dangers of
autonegotiation. A year ago I would have agreed with you, but now I feel
very strongly that it is the wrong approach. Usually I would accept this
code, even if I thought it was not the optimal solution, in the interest
of finishing the conversion quickly. But I fear that if this goes in, then
it will be next to impossible to change in the future.
It simply boils down to this for me: I want to see unambiguous and
explicit bus settings in the code so the reader can safely assume that the
hardware was verified and/or certified for those settings. Even if you
just picked some settings because you didn't have access to the preferred
bus settings that the hardware manufacturer did his verification or
certification with, then that will still show which settings you used to
do your own testing. That's very important information to have in the
code.
Assuming that any autonegotiation code will always return the same result
is in my opinion wishful thinking. Look at the problems we have in
removing autoprobing from i2c: I'm pretty sure someone at the time also
thought that autoprobing would never cause a problem.
> but I'll accept Mauro's
> decision too.
That's fine by me as well.
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG
--
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
