From mboxrd@z Thu Jan 1 00:00:00 1970 From: Albert ARIBAUD Date: Sat, 22 Jan 2011 13:22:24 +0100 Subject: [U-Boot] [RFC] U-boot In-Reply-To: <4D3AB8BC.8060805@emk-elektronik.de> References: <4D3AAF63.1030600@free.fr> <4D3AB8BC.8060805@emk-elektronik.de> Message-ID: <4D3ACC00.3040400@free.fr> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Reinhard, Le 22/01/2011 12:00, Reinhard Meyer a ?crit : > Dear Albert ARIBAUD, > > this is not an ARM local issue. Well, there *is* an ARM specific side of it (use of gd variables during relocation), and that is what prompted me to start the RFC, but generalization to U-boot is welcome if it leads to a satisfactory solution. If not, at least I'll adopt a solution for ARM. > The timeouts are used in generic drivers all around u-boot. > > Have a grep for get_timer, reset_timer... > > The most ugly use is with reset_timer involved, where the internal > pseudo-tick is reset to zero, so all calls to get_timer are > relative to that moment. > > We are looking at replacing all those occurrences of reset_timer > and get_timer with "better" methods. Seems to me this replacement is quite straightforward, as most uses of reset_timer() and subsequent get_timer are actually loops, functionally the same as our proposals, only instead of using a local to store the start or end time, they reset ticks to zero -- which, I concur, is a Bad Thing. But 'reset_timer()' calls just need to be replaced with your 'timeout = timeout_init(N)' or my 'then = now()' and 'get_timer() > N' or 'get_timer_masked() > N' by your 'time_out(timeout)' or my 'ms_elapsed(N)'. Seems to me like a tedious effort, possibly involving occasional time-out value conversions, but not a difficulty. What do I miss? > Best Regards, > Reinhard Amicalement, -- Albert.