From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michal Simek Subject: Re: [PATCH 24/56] microblaze_v2: time support Date: Tue, 06 May 2008 11:56:51 +0200 Message-ID: <48202B63.2050101@seznam.cz> References: <1209901305-6404-1-git-send-email-monstr@seznam.cz> <625ef466cf121d655539eedc919dd39166087e0c.1209897266.git.monstr@monstr.eu> <378157891bac535dbc55e658d5f03fdd332e85cf.1209897266.git.monstr@monstr.eu> <4df4022e06b9056202cc2fdf0b99deb01563a0fa.1209897266.git.monstr@monstr.eu> <6b0c9864dc80776ae48d6488a6892e5d698751b7.1209897266.git.monstr@monstr.eu> <4f4d6ed3fce9b21cdd6dcacb2d72fff7e9830628.1209897266.git.monstr@monstr.eu> <35e662a81eb86c7ffb2aaa6141ca38a07789f382.120989726 6.git.monstr@monstr.eu> <1209953949.5798.66.camel@localhost> <481F1830.5090309@seznam.cz> <1210033811.5798.188.camel@localhost> Reply-To: monstr@seznam.cz Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 7bit Return-path: Received: from smtp1.wifiinternet.cz ([89.31.47.1]:58016 "EHLO bor.wifiinternet.cz" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753197AbYEFJzt (ORCPT ); Tue, 6 May 2008 05:55:49 -0400 In-Reply-To: <1210033811.5798.188.camel@localhost> Sender: linux-arch-owner@vger.kernel.org List-ID: To: John Williams Cc: monstr@seznam.cz, linux-kernel@vger.kernel.org, arnd@arndb.de, linux-arch@vger.kernel.org, stephen.neuendorffer@xilinx.com, John.Linn@xilinx.com, matthew@wil.cx, will.newton@gmail.com, drepper@redhat.com, microblaze-uclinux@itee.uq.edu.au, grant.likely@secretlab.ca Hi John, > Hi Michal, > > On Mon, 2008-05-05 at 16:22 +0200, Michal Simek wrote: >> Hi John, >> >> you wrote me you have smarter implementation that xilinx did. Can you find it >> and send me it? > > It's not much (any?) better? One less multiply I think? Attached > anyway - feel free to discard for now. > > We could do a nice asm implementation with the optional mulhi > instruction, but that can wait. > > Cheers, > > John +extern __inline__ void __udelay(unsigned int x) { - unsigned long long tmp = usec; - unsigned long loops = (tmp * 4295 * HZ * loops_per_jiffy) >> 32; + unsigned long long tmp=(unsigned long long)x*(unsigned long long)loops_per_jiffy*226LL; + unsigned loops=tmp>>32; + __delay(loops); } -#endif /* _ASM_MICROBLAZE_DELAY_H */ +extern __inline__ void __ndelay(unsigned int x) +{ + unsigned long long tmp=(unsigned long long)x*(unsigned long long)loops_per_jiffy*226LL; + unsigned loops=tmp>>32; + + __delay(loops); +} Why is __ndelay implementation the same with __udelay? This is weird for me. + +extern void __bad_udelay(void); /* deliberately undefined */ +extern void __bad_ndelay(void); /* deliberately undefined */ Are these function used anywhere? +#define udelay(n) (__builtin_constant_p(n)? \ + ((n) > __MAX_UDELAY? __bad_udelay(): __udelay((n) * (19 * HZ))) : \ + __udelay((n) * (19 * HZ))) + +#define ndelay(n) (__builtin_constant_p(n)? \ + ((n) > __MAX_NDELAY? __bad_ndelay(): __ndelay((n) * HZ)) : \ + __ndelay((n) * HZ)) +#define muldiv(a, b, c) (((a)*(b))/(c)) muldiv: Where is this use? Michal From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.wifiinternet.cz ([89.31.47.1]:58016 "EHLO bor.wifiinternet.cz" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753197AbYEFJzt (ORCPT ); Tue, 6 May 2008 05:55:49 -0400 Message-ID: <48202B63.2050101@seznam.cz> Date: Tue, 06 May 2008 11:56:51 +0200 From: Michal Simek Reply-To: monstr@seznam.cz MIME-Version: 1.0 Subject: Re: [PATCH 24/56] microblaze_v2: time support References: <1209901305-6404-1-git-send-email-monstr@seznam.cz> <625ef466cf121d655539eedc919dd39166087e0c.1209897266.git.monstr@monstr.eu> <378157891bac535dbc55e658d5f03fdd332e85cf.1209897266.git.monstr@monstr.eu> <4df4022e06b9056202cc2fdf0b99deb01563a0fa.1209897266.git.monstr@monstr.eu> <6b0c9864dc80776ae48d6488a6892e5d698751b7.1209897266.git.monstr@monstr.eu> <4f4d6ed3fce9b21cdd6dcacb2d72fff7e9830628.1209897266.git.monstr@monstr.eu> <35e662a81eb86c7ffb2aaa6141ca38a07789f382.1209897266.git.monstr@monstr.eu> <1209953949.5798.66.camel@localhost> <481F1830.5090309@seznam.cz> <1210033811.5798.188.camel@localhost> In-Reply-To: <1210033811.5798.188.camel@localhost> Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 7bit Sender: linux-arch-owner@vger.kernel.org List-ID: To: John Williams Cc: monstr@seznam.cz, linux-kernel@vger.kernel.org, arnd@arndb.de, linux-arch@vger.kernel.org, stephen.neuendorffer@xilinx.com, John.Linn@xilinx.com, matthew@wil.cx, will.newton@gmail.com, drepper@redhat.com, microblaze-uclinux@itee.uq.edu.au, grant.likely@secretlab.ca Message-ID: <20080506095651.ksx00Bn8Qgg9OyZzjPCwi81-zL9My1C3CLw6n2cNSmU@z> Hi John, > Hi Michal, > > On Mon, 2008-05-05 at 16:22 +0200, Michal Simek wrote: >> Hi John, >> >> you wrote me you have smarter implementation that xilinx did. Can you find it >> and send me it? > > It's not much (any?) better? One less multiply I think? Attached > anyway - feel free to discard for now. > > We could do a nice asm implementation with the optional mulhi > instruction, but that can wait. > > Cheers, > > John +extern __inline__ void __udelay(unsigned int x) { - unsigned long long tmp = usec; - unsigned long loops = (tmp * 4295 * HZ * loops_per_jiffy) >> 32; + unsigned long long tmp=(unsigned long long)x*(unsigned long long)loops_per_jiffy*226LL; + unsigned loops=tmp>>32; + __delay(loops); } -#endif /* _ASM_MICROBLAZE_DELAY_H */ +extern __inline__ void __ndelay(unsigned int x) +{ + unsigned long long tmp=(unsigned long long)x*(unsigned long long)loops_per_jiffy*226LL; + unsigned loops=tmp>>32; + + __delay(loops); +} Why is __ndelay implementation the same with __udelay? This is weird for me. + +extern void __bad_udelay(void); /* deliberately undefined */ +extern void __bad_ndelay(void); /* deliberately undefined */ Are these function used anywhere? +#define udelay(n) (__builtin_constant_p(n)? \ + ((n) > __MAX_UDELAY? __bad_udelay(): __udelay((n) * (19 * HZ))) : \ + __udelay((n) * (19 * HZ))) + +#define ndelay(n) (__builtin_constant_p(n)? \ + ((n) > __MAX_NDELAY? __bad_ndelay(): __ndelay((n) * HZ)) : \ + __ndelay((n) * HZ)) +#define muldiv(a, b, c) (((a)*(b))/(c)) muldiv: Where is this use? Michal