accessibilities first tests - many questions

[Jordan Crouse]

On 24/08/07 15:47 +0200, Guylhem Aznar wrote:
> Hello
> 
> On 8/20/07, Jordan Crouse <jordan.crouse at amd.com> wrote:
> > > It'd be great if this could be included. Better yet would be
> > > to allow specifying the raw register value, of course with
> > > an -EINVAL if bits unrelated to swizzle and backlight are set.
> >
> > Again - can I ask why?  The sysfs/ interface exists to provide the
> > right interface to the applications and the user to accomplish what
> > they want to do.  If you have a good reason for exposing this
> > functionality, then I'm all ears, but I think that "just for giggles"
> > doesn't quite cut it.
> 
> What about because it has not been tested?

Don't make the assumption that this hasn't been tested.  This hardware
goes through extensive testing before we even get to see it.  From Linux
even.

> Removing a feature that people want to test, doing someway instead of
> the other way, just because you are guessing it won't be helpful, is
> just wrong to me.

I told you how you could test it easily, and I stick by that.  Adding the
sysfs entry costs time, code size, and further confuses the interface 
(which is already pretty darn confusing).  If the only viable usage is
"I want to see how it works" then i2dump is two doors down and to the
right.  It comes for free with the bus.

> > If you want to write directly on the device for testing purposes, then
> > the i2c-tools work great - you can bang on the registers all day.
> 
> But you are making that unreasonably complex. What about other
> features? Will everyone will have to do i2c? What about switching
> GPIOs? (I haven't checked that yet) An echo 0/echo 1 in /sys really
> saves testing time.

Not really, when you have the i2c tools, then its just a single command
as well - and the interface comes for free.  Its not always easy being
a low end developer.

But here's an alternative - use OFW to change the values instead - that
absolutely comes for free - the functionality is already built in.  Ask
Mitch, and he'll give you a recipe.

> How clever users are - they think in ways we don't. So we shouldn't be
> arrogant and try to dictate them what's best for them, but see what
> they do with the possibilities we provide.

Its not about dictating whats best for them, its about providing the
knobs that make sense to turn.  There are hundreds of interesting looking
registers in the chips on this platform, and I'm sure that we could go
through and toss them all into syfs or some other interface, but the odds
are that every single one of them will go untouched, except for the 
occasional guy who reads the datasheet and thinks he has found something
"creative" that the rest of us missed.   So we don't provide the interfaces
that aren't useful in production.

Thats not to say that you still can't twiddle the registers - there are
several great ways to play with the internals of the chipsets from the
privacy of your own userspace.  We're not in the business of making it
impossible for people to tinker, but we are in the business of optimizing
the experience for the end user.  

> Therefore, I think we should not currently be removing possibilities
> but adding them instead, test them, and remove what has been *proved*
> to be useless. Wild guessing is not a good strategy. And anyway,
> what's the cost ? That's won't make your kernel bigger. That won't
> make it run slower or eat more power.

Actually, it will.  It will make the kernel larger, and it will eat more
memory due to the additional infrastructure.   We know exactly the cost - my
question is, whats the benefit?  Nobody really knows (or I suspect, cares),
they just read the spec and say "wow, I want to try that because its a knob
I can twiddle".

But hey, this is open source.  I'm sure Andres will take a patch against
olpc-dcon if you really care that much.

-- 
Jordan Crouse
Systems Software Development Engineer 
Advanced Micro Devices, Inc.