From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752345AbcAAUYB (ORCPT ); Fri, 1 Jan 2016 15:24:01 -0500 Received: from smtp05.smtpout.orange.fr ([80.12.242.127]:42679 "EHLO smtp.smtpout.orange.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752174AbcAAUX7 convert rfc822-to-8bit (ORCPT ); Fri, 1 Jan 2016 15:23:59 -0500 X-ME-Helo: belgarion X-ME-Auth: amFyem1pay5yb2JlcnRAb3JhbmdlLmZy X-ME-Date: Fri, 01 Jan 2016 21:23:53 +0100 X-ME-IP: 92.136.207.223 From: Robert Jarzmik To: Thomas Gleixner , Roman Volkov Cc: arm@kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Arnd Bergmann , Alexey Charkov , Roman Volkov , Tony Prisk , Daniel Lezcano , Bill Gatliff Subject: Re: [PATCH v2 RESEND 1/3] clocksource/vt8500: Use MIN_OSCR_DELTA from PXA References: <1451584927-4051-1-git-send-email-v1ron@mail.ru> <1451584927-4051-2-git-send-email-v1ron@mail.ru> <20160101023208.7721e085@v1ron-s7> X-URL: http://belgarath.falguerolles.org/ Date: Fri, 01 Jan 2016 21:23:48 +0100 In-Reply-To: <20160101023208.7721e085@v1ron-s7> (Roman Volkov's message of "Fri, 1 Jan 2016 02:32:08 +0300") Message-ID: <871ta1f3qj.fsf@belgarion.home> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Roman Volkov writes: > В Thu, 31 Dec 2015 23:33:45 +0100 (CET) > Thomas Gleixner пишет: > >> Roman, >> >> On Thu, 31 Dec 2015, Roman Volkov wrote: >> > Since vt8500 and PXA timers are identical, use MIN_OSCR_DELTA from >> > PXA, which is bigger than existing value. It is required to >> > determine the minimum delay which hardware can generate. >> >> Now that brings up the obvious question: >> >> If the vt8500 and PXA timers are identical why has vt8500 it's own >> slightly different implementation and does not use the PXA timer? > > Thomas, > > I occasionally noticed that the PXA can be reused, when working on the > bugfix for vt8500. Another good question would be how exactly this code > can be reused. We may rework PXA driver to make it working under > vt8500, or include the C code from the vt8500 and get two slightly > different modules. You may look at our previous discussion with Alexey: > > https://lkml.org/lkml/2015/12/21/437 > > Adding Robert and Bill to get more opinions. At this step, fixing the > vt8500 nanosleep bug is a priority. Personnaly I'm not very thrilled by combining pxa and vt8500 drivers into one. The rationale I have behind is that : - the new driver will have new ifs to switch form vt8500 to pxa For example, suspend/resume functions will be different. Moreover in order to not impact the pxa runtime some ifs will be necessary (will that be if (IS_ENABLED(CONFIG_ARCH_PXA) && ...) - the IPs do not look that similar to me They seems inter-operable, but that seems to me to be just because of the 3 common register placement : register at match (@0x00), counter (@0x10) and interrupt enabled (@0x1c). The register acces semantics are different (vt8500 needs a bit to access), the input clock seems different. For ~140 lines of code, I prefer the simplicity brought by drivers separation. The diffstat should be pretty equivalent between 2 drivers and 1 combined driver with many ifs. Cheers. -- Robert