Hi,
On 05-01-15 13:24, B.R. Oake wrote:
On 05/01/15 10:51, Hans de Goede wrote:
Ah, ok, thanks for figuring that out, so this only happens to people following my sunxi-wip branch, because that commit is not upstream yet.
So I guess I will need to fix this somehow without using 64 bit math, any suggestions?
EDID_DETAILED_TIMING_PIXEL_CLOCK() always returns a uint32 that is 10,000 times a uint16, so one way of avoiding 64-bit arithmetic would be to cancel out the 10,000 before the division:
--- a/drivers/video/videomodes.c 2015-01-05 10:18:58.745985034 +0000 +++ b/drivers/video/videomodes.c 2015-01-05 12:15:27.484150964 +0000 @@ -411,7 +411,8 @@ mode->refresh = EDID_DETAILED_TIMING_PIXEL_CLOCK(*t) / (h_total * v_total);
- mode->pixclock = 1000000000000LL / EDID_DETAILED_TIMING_PIXEL_CLOCK(*t);
- mode->pixclock = 100000000L /
(EDID_DETAILED_TIMING_PIXEL_CLOCK(*t) / 10000);I still wonder though whether a nicer way would be for the configs to be refactored so that -msoft-float was not set on platforms where it wasn't appropriate.
Ah I did not realize that the EDID_DETAILED_TIMING_PIXEL_CLOCK did * 10000, that indeed makes things easier, I've done this instead (somewhat cleaner) :
- mode->pixclock = 1000000000000LL / EDID_DETAILED_TIMING_PIXEL_CLOCK(*t); - mode->pixclock_khz = (EDID_DETAILED_TIMING_PIXEL_CLOCK(*t) + 500) / - 1000; + mode->pixclock_khz = EDID_DETAILED_TIMING_PIXEL_CLOCK(*t) / 1000; + mode->pixclock = 1000000000L / mode->pixclock_khz;
I've squashed this fix into my personal tree, sunxi-wip branch, so people building from there should not longer see those compile errors, and I'll preserve the fix when the patches move to u-boot-sunxi/next :)
Regards,
Hans