From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Cousson, Benoit" Subject: Re: [PATCH 0/9] ARM: OMAP: DMTIMER clean-up in preparation for device-tree Date: Thu, 17 May 2012 12:29:42 +0200 Message-ID: <4FB4D316.608@ti.com> References: <1337124914-19921-1-git-send-email-jon-hunter@ti.com> <4FB37356.9040001@ti.com> <4FB3ACCE.1050103@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from comal.ext.ti.com ([198.47.26.152]:43099 "EHLO comal.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965400Ab2EQK3p (ORCPT ); Thu, 17 May 2012 06:29:45 -0400 In-Reply-To: <4FB3ACCE.1050103@ti.com> Sender: linux-omap-owner@vger.kernel.org List-Id: linux-omap@vger.kernel.org To: Jon Hunter Cc: linux-omap , Tony Lindgren On 5/16/2012 3:34 PM, Jon Hunter wrote: > Hi Benoit, > > On 05/16/2012 04:28 AM, Cousson, Benoit wrote: >> Hi Jon, >> >> On 5/16/2012 1:35 AM, Jon Hunter wrote: >>> From: Jon Hunter >>> >>> In order to migrate the dmtimer driver to support device-tree I found >>> that it >>> was first necessary to clean-up the timer platform data. The goal of this >>> series is to simplify the timer platform data structure from ... >>> >>> struct dmtimer_platform_data { >>> int (*set_timer_src)(struct platform_device *pdev, int source); >>> int timer_ip_version; >>> u32 needs_manual_reset:1; >>> bool reserved; >>> bool loses_context; >>> int (*get_context_loss_count)(struct device *dev); >>> }; >>> >>> to ... >>> >>> struct dmtimer_platform_data { >>> int (*set_timer_src)(struct platform_device *pdev, int source); >> >> I guess that custom set_timer_src should not be there at all anymore. >> Well at least for OMAP2+. >> We should just use the regular clock API to change the parent. I do not >> see why we should add that wrapper on top of the clock API and thus >> store some internal clock name inside the timer device init code. > > Yes I really wanted to eliminate that function pointer too, but it was a > little trickier. The OMAP2+ code does use the clock framework to switch > the parent already, but the problem is that the OMAP1 code does not. So > we cannot have a common function for OMAP1 and OMAP2+. > > One option would be to move the OMAP2+ function into the dmtimer because > it already uses the clock framework and then only populate the function > pointer for OMAP1. However, I admit this is ugly. > > Let me look at this some more to see what I can do. I can at least test > on my old omap1 board now for prototyping :-) > > Did you look at the rest of the series? Let me know if you are ok with > the approach and have any concerns on my hwmod changes/fix-ups ;-) No, I'll keep that for next week, after my vacation :-) Regards, Benoit