[Nook Color Android Development] steven676:
https://github.com/CyanogenMod/lge-kernel-sniper/tree/android-omap3-3.0 is the P970 kernel tree. It's probably easiest to download and diff the two trees locally (I'd use the encore-omap3-3 branch instead of the current encore-omap3-3.0.y branch to minimize noise introduced by the big stable-3.0 merge). (There are a *lot* of differences, but if you confine your examination to drivers/video/omap2 things should be more manageable.) Once you find some, there are a few approaches you can take:

Try to figure out what effect each change might have, to see if any of them could be relevant to the problem. (Git history could potentially be your friend here -- you can use "git blame" to see which commit introduced a particular change, then look at the commit message to see if there's anything interesting there.)

Apply them blindly to our tree and see whether the result works.

Put the differences up and try to rope someone else into sorting through them :)

In this case, the thing we're splitting in half (repeatedly) is the commit history, not the code itself. To be precise: suppose we have a sequence of commits to some repository c_1, c_2, ..., c_n, for which we know c_n has a particular bug that c_1 does not. We assume (quite reasonably, I think) that one of the commits between c_1 (exclusive) and c_n (inclusive) introduced this bug, and so conduct a binary search over the commits that proceeds something like this:

Check out commit c_{n/2}. Compile and install it, and see whether it's buggy.

If it's buggy: assume the commit introducing the bug is in the range c_1, ..., c_{n/2}. Repeat process over that window in place of c_1, ..., c_n.

If it's not buggy: assume the commit introducing the bug is in the range c_{n/2}, ..., c_n. Repeat process over that window in place of c_1, ..., c_n.

Basically, the idea is to repeatedly subdivide the commit history into "known-good" and "known-bad" intervals until we finger one commit that introduces the bug.

The "git bisect" command automates the process of dividing up the commit history, but it's up to you to tell it at each step whether the selected commit is buggy or not. A typical session goes like this:

$ git bisect start
$ git bisect good [good-commit]
$ git bisect bad [bad-commit]
[git automatically checks out the commit in the middle of the range between good-commit and bad-commit]
[you build software, run it and see that this commit is buggy]
$ git bisect bad # marks the current commit as buggy
[git now checks out a commit in between good-commit and the one you just marked bad]
[you build software, run it and see that this commit is not buggy]
$ git bisect good
[...]
[eventually, you've marked c_k as good, c_{k+1} as bad; git tells you c_{k+1} is the first bad commit]

Git's own documentation has more details on git-bisect and how to use it.

As moocow1452 says, it's relative and depends on your patience. That said, if you're going to bisect an issue, you're probably going to be building the software in question half a dozen times at the very least (frequently more) -- if each compile-install-test cycle takes an hour, it's going to take you at least six hours (and probably more) to track down the bug, whereas if you can get each cycle down to 15 minutes, you might be able to do it in under two hours.