Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751150AbdCOBHQ (ORCPT ); Tue, 14 Mar 2017 21:07:16 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:33034 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750973AbdCOBHN (ORCPT ); Tue, 14 Mar 2017 21:07:13 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 6842660848 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=sboyd@codeaurora.org Date: Tue, 14 Mar 2017 18:07:10 -0700 From: Stephen Boyd To: Markus Mayer Cc: Michael Turquette , Rob Herring , Mark Rutland , Mike Turquette , Linux Clock Mailing List , Device Tree Mailing List , Linux Kernel Mailing List , Markus Mayer Subject: Re: [RFC 1/2] clk: dt: binding for basic divider clock Message-ID: <20170315010710.GJ10239@codeaurora.org> References: <20170314202236.39910-1-code@mmayer.net> <20170314202236.39910-2-code@mmayer.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170314202236.39910-2-code@mmayer.net> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1462 Lines: 34 On 03/14, Markus Mayer wrote: > From: Mike Turquette > > Devicetree binding for the basic clock divider, plus the setup function > to register the clock. Based on the existing fixed-clock binding. > > Tero Kristo contributed helpful bug fixes to this patch. > > Signed-off-by: Mike Turquette > Tested-by: Heiko Stuebner > Reviewed-by: Heiko Stuebner > Signed-off-by: Markus Mayer These sorts of details should go into C code. Is there any difficulty in writing a driver to do so? So far we've avoided adding the generic divider, multiplier, mux, bindings because those usually need some register level details that we've been reluctant to add to DT. That's because if something is wrong with these register level details or we need to make some policy updates, e.g. favor this divider over another, we can't really do that with a DT update. So we really want to see DT nodes have some hardware specific compatible string, and also put the logic for the driver into the code so that it can be easily fixed and updated after the fact. The DTS file is there to tell us "I have a divider from company X here and it's connected to this and that" and the driver is there to do the work of driving that piece of hardware so it works properly. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project