From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965440AbbKDMUf (ORCPT ); Wed, 4 Nov 2015 07:20:35 -0500 Received: from mout.kundenserver.de ([212.227.17.24]:62884 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965273AbbKDMUd (ORCPT ); Wed, 4 Nov 2015 07:20:33 -0500 From: Arnd Bergmann To: Daniel Lezcano Cc: Jisheng Zhang , tglx@linutronix.de, linux@arm.linux.org.uk, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 0/3] let Marvell Berlin SoCs make use of the best delay timer Date: Wed, 04 Nov 2015 13:19:53 +0100 Message-ID: <3751534.M13UnSz6gv@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <5639E9DD.1080309@linaro.org> References: <1446560917-6318-1-git-send-email-jszhang@marvell.com> <4359736.Q4L68M2aRW@wuerfel> <5639E9DD.1080309@linaro.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:tLhn215Lvbogx+97abSNqd+5jIgG+tNz4bohR92ueXJcjeXmRbD 9eBCbK4sB8LhDopHZe9nrJk5V8HzAR1Z9oxoTpZSfRQv64h3PykckI2m0ISBOYuPFl+fnVF miJDdVejnyGOSoj6EMuRk4yqBgI6h2HcyNvrnlR6P0W146tXeusvSG8H8H2+NcNgckLjcv7 l+G/nBlpfAw2QYnisgJbg== X-UI-Out-Filterresults: notjunk:1;V01:K0:ivyhf9GL488=:BYROkMybezXnwBmIJw6T7j vy8EU+0AMt39B4WNCzF1paZjodfW9QBKk5CajCtEnqBHnvLeDew4khzIFMC69sQp4oC8RW/6M QrjT4L2t/CWyd6PWdsXjessOLPJBvyDk12d8NLU8ekpUP5M4tUmSRHQLws1yCRLuRid1jrXsr ZcuHgn7dCx+I/g6S0+RRFfvFTjiDNTQMrufi8/X1AWWlc+lT+XSIwgtgCrxortTLre4/AS19w CwKXnRj3P8KBUUcx68GS7pOXTuF3DVyZYz9n48n9Fa5QW0TluHBjOYTyhxMaAllwANVQSxDPN aVNPJKNUd79UiF330W2ReomK7ceQP0k42sAEqa5D189C5jhH5xJ/Xl7RX033JM0E6oFRMYloh iaBmigfGl4ea7iA+poy+I1YtgDG9j6MyQwgd71QcW9kxZz7RSYZysjTEwr7yaLGNmxIjASBtm yQUg0YId7EyWb20CRWtoLEEqT+T/aDsNqEB5HUXBqq8TcrSnq7vBRoqluT7JMndQBbStcRpE5 ZsTktInAGo4oBW3kQYM0URytS+QVL1hmMwsXULfICaYOb3I+LiNBFxbUKLc/li3W+1xrxsiEi /55v/1wk/zmbN36xPp2demSm5vH5PxS3o7G/ZiJlnw/mlCM32Iq71igfezu3YvFJ1NosCVist ncSEK+vQxMuKxgJkJ8X9V7G8lRMO8WHiK6SRx7dUyAomw8LOeaO6jYuTwIPyockl9eunQI2AL fcT2osjwNo9O73uX Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wednesday 04 November 2015 12:19:57 Daniel Lezcano wrote: > On 11/04/2015 11:30 AM, Arnd Bergmann wrote: > > On Wednesday 04 November 2015 10:46:49 Daniel Lezcano wrote: > >> On 11/03/2015 03:28 PM, Jisheng Zhang wrote: > >>> In case there are several possible delay timers, we purely base the > >>> selection on the frequency, which is suboptimal in some cases. Take > >>> one Marvell Berlin platform for example: we have arch timer and dw-apb > >>> timer. The arch timer freq is 25MHZ while the dw-apb timer freq is > >>> 100MHZ, current selection would choose the dw-apb timer. But the dw > >>> apb timer is on the APB bus while arch timer sits in CPU, the cost > >>> of accessing the apb timer is higher than the arch timer. > >>> > >>> This series firstly modifies register_current_timer_delay() to choose > >>> the highest rating delay timer: use the rating as a primary indication > >>> and fall back to comparing the frequency if the rating is not set or > >>> the same. Then we set the arch_delay_timer rating as 400, finally > >>> Implement ARM delay timer for the dw_apb_timer and set its rating as 300. > >> > >> Hi Jisheng, Arnd, > >> > >> I don't feel comfortable with the rating / freq think. I am afraid this > >> approach based on heuristic will bring a lot of complexity and > >> workarounds in the code for a small benefit. > >> > >> Why don't we define a DT entry for the delay timer ? So we delegate the > >> choice to the platform DT definition. > > > > That would be wrong, because the fact that Linux uses a timer to > > optimize its udelay() function is not a feature of the hardware. > > True. > > Any ideas / suggestions for an alternative ? How about simply hardcoding the fact that we prefer the arch timer over any other one for delay as I suggested earlier? Another idea I just had is to do nothing: According to Jisheng's description for this series, the reason for preferring the arch timer is that it is faster to access. However, we could argue that this actually doesn't matter at all, because the entire point of the ndelay()/udelay()/mdelay() functions is to waste CPU cycles doing not much at all, so we can just as well waste them reading the timer register than spinning on the CPU reading the arch timer more often. Arnd