Hi Linus,
just a quick fix that a few people have reported, be nice to have in asap.
Dave.
The following changes since commit 72a67a94bcba71a5fddd6b3596a20604d2b5dcd6:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2013-08-03 15:00:23 -0700)
are available in the git repository at:
git://people.freedesktop.org/~airlied/linux drm-fixes
for you to fetch changes up to adfb8e51332153016857194b85309150ac560286:
drm/radeon: fix 64 bit divide in SI spm code (2013-08-04 11:03:14 +1000)
---------------------------------------------------------------- Alex Deucher (1): drm/radeon: fix 64 bit divide in SI spm code
drivers/gpu/drm/radeon/si_dpm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
On Sat, Aug 3, 2013 at 6:08 PM, Dave Airlie airlied@linux.ie wrote:
Alex Deucher (1): drm/radeon: fix 64 bit divide in SI spm code
That code is stupid. You're asking for a 64-by-64 divide, when the divisor is clearly an "int" (100 and 1000 respectively).
Why is it doing "div64_s64()" instead of the simpler and faster "div_s64()"?
A full 64-by-64 divide is _expensive_ on 32-bit architecture (up to four divide instructions, each potentially expensive in its own right), which is the whole reason why we have that "math64.h" to begin with - to make people aware of it.
Now, our lib/div64.c routines do notice that the upper bits of the divisor are zero and end up using the simpler 64-by-32 divide functions, but why explicitly ask for those more complex functions to begin with?
So the code is likely not performance critical, and hey, our library routines do the simple optimizations to avoid the trivially excessive divide instructions, so this "doesn't matter". Except for the annoyance factor of you using a more complicated function for no reason.
Linus
dri-devel@lists.freedesktop.org