[ubuntu-x] Final Maverick i830, i845g, i855 support

[Bryce Harrington]

On Sun, Sep 19, 2010 at 07:39:19PM -0600, Gordon Schumacher wrote:
> On 09/19/2010 02:01 AM, Bryce Harrington wrote:
> > Actually, I think we've had sufficient testers now to know the available
> > options at this point are not adequate to solve the problem.
> >
> > I guess what is needed next is for someone with this hardware on hand to
> > experiment in the driver code.
> >   
> 
> Well, I've got the hardware and am not a stranger to the test-and-debug
> process, but I'm no driver developer.  The closest I've come, I think,
> was narrowing down a regression with a particular non-compliant USB
> device by basically doing a manual binary search through kernel changes,
> and forwarding my results on to the maintainer.  (The change was fairly
> isolated, so I could get it down to a sub-file level.)

I'm no driver developer myself, other than poking around here and there.
However I can give a few pointers in the codebase.

Driver development isn't really that hard from a programming
perspective, in that you don't need to know much about data structures
or advanced algorithms or whatnot.  The code itself is pretty basic C,
and there isn't really that much of it.  Mostly the hard part is about
learning about the hardware and its functions, and figuring out what
values need to be poked into what registers.


If you look in the -intel driver source tree, the hardware-specific code
files are prefixed by the hardware family.  So for instance:

  i830_3d.c   i830_render.c   i915_video.c   i965_video.c  ...

The i830* cover the newer 8xx cards, which (IIRC) includes 845, 855,
865.  (For older 810, 815 see the src/legacy/)

At a basic level, the drivers poke values into registers on the graphics
cards.  i830_reg.h establishes #defines to translate the values into
something more human readable.  For instance:

  #define ENABLE_TRI_STRIP_PROVOKE_VRTX   (1<<2)

1<<2 is a bitwise operator.  If you're not familiar with it, it's worth
brushing up on since it's used a lot in driver code.

The files i830_render.c and i830_3d.c has the code that maps the
register values and the more generalized X.org graphics data and
operations.

One thing I'm not sure of is if the registers are the same for all the
different 8xx models, or if they vary from chip to chip.  I suspect the
latter, since that's a really common condition.  (Unfortunately Intel
didn't publish the hardware documentation, which would have made it
easier to doublecheck the register mappings for the particular hw.)

So, the way you debug this kind of problem generally involves getting
register dumps in a known-good condition, trigger the bug, and then get
another register dump and see what registers changed.  You look for
inconsistencies in how the driver code is using the registers and what
actually gets changed in the hardware.


Anyway, if the above doesn't sound like complete technojibberish, maybe
you have the chops to do driver bug fixing!

If it does sound like technojibberish, well at least maybe it gives some
better insights into why 8xx has been hard to get working right:

  * The registers can vary from model to model, but Intel didn't publish
    the driver documentation for the chips (AFAIK)

  * There can sometimes be hardware bugs.  So something that works on
    all the other models might fail on a particular model.

  * When a register gets poked with an incorrect value, it doesn't print
    out a nice useful error message, it just freezes up.  This makes it
    really hard to debug it remotely.

  * To "really" test the code you need to have the hardware and the code
    so you can tweak/recompile/reboot until it works.

Bryce