On Sat, Sep 11, 2021 at 12:27:37PM +0300, Laurent Pinchart wrote:
> On Sat, Sep 11, 2021 at 02:38:11AM +0200, Mauro Carvalho Chehab wrote:

> > > which we
> > > could consider as an alternative to the open userspace implementation
> > > (a topic worth discussing I believe).

> > Yeah, a public datasheet sounds an interesting requirement. It offers
> > a problem, though: maybe some details could be missed on it, which
> > would prevent any real open source userspace development.

> Absolutely, and I don't think we can come up with any process and
> technical measure that would prevent a vendor from cheating if they
> really want to. It will always be possible to hide some features behind
> reserved registers that wouldn't need to be programmed for basic
> operation but that would be crucial to optimize the quality or
> performances. This is regardless of whether we want to enforce openness
> of documentation in the form of datasheets or source code.

This is already very standard in some parts of the industry, even
between vendors and customers.  Sometimes it's done intentionally but
it's also often just that the actual practical configuration process
relies on some non-trivial test system and perhaps has as much art as
science involved.  It can also be a decision about managing support
costs which works for everyone involved on the business side - sometimes
the product being delivered includes the vendor doing a good deal of the
tuning for some combination of cost and complexity reasons.

> I'm not too concerned about this though. If we can address most of this
> issue with a clear process and message I think it would be a very good
> step forward already.

Yeah, I'm personally not so concerned about the callibration and tuning
side - ideally that would be fully open but like you say even without
that we've achieved something and there may not actually be anything
extant to open.