From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755097AbbJHJPv (ORCPT ); Thu, 8 Oct 2015 05:15:51 -0400 Received: from unicorn.mansr.com ([81.2.72.234]:34702 "EHLO unicorn.mansr.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753631AbbJHJPr convert rfc822-to-8bit (ORCPT ); Thu, 8 Oct 2015 05:15:47 -0400 From: =?iso-8859-1?Q?M=E5ns_Rullg=E5rd?= To: Mark Rutland Cc: Rob Herring , Pawel Moll , Ian Campbell , Kumar Gala , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 1/2] devicetree: add binding for generic mmio clocksource References: <1444232234-2133-1-git-send-email-mans@mansr.com> <20151007154727.GC28981@leverpostej> <20151007170358.GA32702@leverpostej> Date: Thu, 08 Oct 2015 10:15:39 +0100 In-Reply-To: <20151007170358.GA32702@leverpostej> (Mark Rutland's message of "Wed, 7 Oct 2015 18:03:58 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Mark Rutland writes: >> >> +- clocks: phandle to the source clock >> > >> > Is the frequency expected to be exactly the source clock frequency? I >> > imagine it's possible for there to be a divisor. >> >> There could of course be, though there isn't in the hardware I'm dealing >> with. Is specifying it here preferable using a fixed-factor-clock? > > I'm not actually sure; I guess it would be ok to do so. > > For now we should just explicitly state that the clocksource is assumed > to tick at the rate of the clock. OK, I'll come up with a clearer wording. >> > We can add properties for that later, but we should be explcit as to >> > what we currently expect the relationship between the clock and the >> > clocksource to be. >> > >> >> +- clocksource-bits: number of valid bits >> >> +- clocksource-rating: rating of the clocksource >> > >> > NAK. This has no meaning w.r.t. the hardware. This should not be in the >> > DT. If there are criteria that bias this (e.g. frequency, latency), they >> > should either be described in the DT or determined dynamically. >> >> I had a bad feeling about this. How would you suggest determining a >> suitable value from actual hardware parameters? > > I don't have a good answer to that given the rating is semi-arbitrary, > but that's also the reason I don't want to see it in the DT. > > Can we not just choose a fixed number in the driver for now? Likely > something lower than the architected timers (400 currently). Fine with me. >> >> +- linux,sched-clock: boolean, register clocksource as sched_clock >> > >> > Likewise, this property doesn't belong in the DT for the same reasons as >> > clocksource-rating. >> >> What would be a proper way to select a sched_clock source? I realise >> it's a Linux-specific thing and DT is supposed to be generic, but the >> information must be provided somehow. > > I think that any source above a certain rate and below a certain > latency, which does not lose state, should be registered (and the best > gets chosen dynamically). > > Come to think of it, what's the expected behaviour of this source w.r.t. > power management? I expect that the kernel needs to leave the clock > enabled at all times for this to possibly work. The platform I'm dealing with has a 32-bit register counting cycles of the external clock input which never stops. It also has a few counters with a configurable clock source, and those might indeed stop so should probably not be used for this. -- Måns Rullgård mans@mansr.com