On Tuesday, February 22, 2011 17:27:47 Guennadi Liakhovetski wrote:
> On Tue, 22 Feb 2011, Stan wrote:
>
> > In principle I agree with this bus negotiation.
> >
> > - So. let's start thinking how this could be fit to the subdev sensor
> > operations.
>
> Well, I'm afraid not everyone is convinced yet, so, it is a bit early to
> start designing interfaces;)
>
> > - howto isolate your current work into some common place and reuse it,
> > even on platform part.
> > - and is it possible.
> >
> > The discussion becomes very emotional and this is not a good adviser :)
>
> No, no emotions at least on this side:) But it's also not technical,
> unfortunately. I'm prepared to discuss technical benefits or drawbacks of
> each of these approaches, but these arguments - can we trust programmers
> or can we not? or will anyone at some time in the future break it or not?
> Sorry, I am not a psychologist:) Personally, I would _exclusively_
> consider technical arguments. Of course, things like "clean and simple
> APIs," "proper separation / layering" etc. are also important, but even
> they already can become difficult to discuss and are already on the border
> between technical issues and personal preferences... So, don't know, in
> the end, I think, it will just come down to who is making decisions and
> who is implementing them:) I just expressed my opinion, we don't have to
> agree, eventually, the maintainer will decide whether to apply patches or
> not:)
In my view at least it *is* a technical argument. It makes perfect sense to
me from a technical point of view to put static, board-specific configuration
in platform_data. I don't think there would have been much, if any, discussion
about this if it wasn't for the fact that soc-camera doesn't do this but instead
negotiates it. Obviously, it isn't a pleasant prospect having to change all
that.
Normally this would be enough of an argument for me to just negotiate it. The
reason that I don't want this in this particular case is that I know from
personal experience that incorrect settings can be extremely hard to find.
I also think that there is a reasonable chance that such bugs can happen. Take
a scenario like this: someone writes a new host driver. Initially there is only
support for positive polarity and detection on the rising edge, because that's
what the current board on which the driver was developed supports. This is quite
typical for an initial version of a driver.
Later someone adds support for negative polarity and falling edge. Suddenly the
polarity negotiation on the previous board results in negative instead of
positive
which was never tested. Now that board starts producing pixel errors every so
often. And yes, this type of hardware problems do happen as I know from painful
experience.
Problems like this are next to impossible to debug without the aid of an
oscilloscope, so this isn't like most other bugs that are relatively easy to
debug.
It is so much easier just to avoid this by putting it in platform data. It's
simple, unambiguous and above all, unchanging.
Regards,
Hans
>
> 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 majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Hans Verkuil - video4linux developer - sponsored by Cisco
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
