possible progress on XO-1 camera issues
dsd at laptop.org
Wed Dec 23 13:09:45 EST 2009
On Wed, 2009-12-23 at 14:28 -0300, César D. Rodas wrote:
> Hello Everybody,
> After hard debugging with Raul, we've realized that the problem was in
> the Geode driver.
> I've changed a line within the memory buffer, and it seems to work now.
> Looking forward to get feedback (please don't be evil, it's my first
> patch :-)
Can you add an explanation?
It doesn't look correct to me. Here's my understanding:
The task of this function is to create a new offscreen memory allocation
of a certain size.
The function goes through the list of existing allocations, looking at
each entry. It calculates how much free space there is inbetween one
entry in the list, and the next one. If there is enough free space, the
new allocation can be inserted at this point. Otherwise, we have to
carry on iterating through the list.
In that specific section of code, "gap" is computed, in 2 stages, to be
the amount of bytes inbetween the list entry currently being examined
and the next one.
if (ptr->next == NULL)
gap = pGeode->offscreenSize + pGeode->offscreenStart;
gap = ptr->next->offset;
This is the first step. It is setting the "gap" variable to the absolute
address where the next allocation starts. In the first branch, we have
reached the end of the list, therefore our upper bound is the top of the
In the 2nd branch, there is a following member in the list, so our upper
bound is the address of where that memory allocation starts. And the
"offset" variable is always absolute, so this is the correct calculation
for the upper bound.
As the 2nd stage of the calclation, the lower bound is considered (the
end of the allocation currently being examined) to produce a final value
of "gap" that represents the number of bytes inbetween the 2 consecutive
gap = gap - (ptr->offset + ptr->size);
To me, everything looks correct before your patch. What am I missing?
More information about the Devel