From patchwork Fri Nov 28 13:37:14 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hans de Goede X-Patchwork-Id: 5403561 Return-Path: X-Original-To: patchwork-linux-media@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 0A896BEEA8 for ; Fri, 28 Nov 2014 13:37:56 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 31B1A20115 for ; Fri, 28 Nov 2014 13:37:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E870B201C0 for ; Fri, 28 Nov 2014 13:37:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751892AbaK1Nhv (ORCPT ); Fri, 28 Nov 2014 08:37:51 -0500 Received: from mx1.redhat.com ([209.132.183.28]:37700 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751434AbaK1Nhu (ORCPT ); Fri, 28 Nov 2014 08:37:50 -0500 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sASDbHo7016216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 28 Nov 2014 08:37:17 -0500 Received: from shalem.localdomain (vpn1-4-80.ams2.redhat.com [10.36.4.80]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sASDbE6d013743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 28 Nov 2014 08:37:15 -0500 Message-ID: <54787A8A.6040209@redhat.com> Date: Fri, 28 Nov 2014 14:37:14 +0100 From: Hans de Goede User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Maxime Ripard CC: Chen-Yu Tsai , Boris Brezillon , Mike Turquette , Emilio Lopez , Linux Media Mailing List , linux-arm-kernel , devicetree , linux-sunxi Subject: Re: [PATCH 3/9] clk: sunxi: Add prcm mod0 clock driver References: <20141126211318.GN25249@lukather> <5476E3A5.4000708@redhat.com> <5476F8AB.2000601@redhat.com> <20141127190509.GR25249@lukather> In-Reply-To: <20141127190509.GR25249@lukather> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, T_RP_MATCHES_RCVD, T_TVD_MIME_EPI, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Hi, On 11/27/2014 08:05 PM, Maxime Ripard wrote: > Hi, > > On Thu, Nov 27, 2014 at 11:10:51AM +0100, Hans de Goede wrote: >> Hi, >> >> On 11/27/2014 10:28 AM, Chen-Yu Tsai wrote: >>> Hi, >>> >>> On Thu, Nov 27, 2014 at 4:41 PM, Hans de Goede wrote: >> >> >> >>>> I notice that you've not responded to my proposal to simple make the clock >>>> node a child node of the clocks node in the dt, that should work nicely, and >>>> avoid the need for any kernel level changes to support it, I'm beginning to >>>> think that that is probably the best solution. >>> >>> Would that not cause an overlap of the io regions, and cause one of them >>> to fail? AFAIK the OF subsystem doesn't like overlapping resources. >> >> No the overlap check is done by the platform dev resource code, and of_clk_declare >> does not use that. So the overlap would be there, but not an issue (in theory >> I did not test this). > > An overlap is always an issue. > >> Thinking more about this, I believe that using the MFD framework for the prcm seems >> like a mistake to me. It gains us nothing, since we have no irq to de-multiplex or >> some such. We're not using MFD for the CMU, why use it for CMU2 (which the prcm >> effectively is) ? > > Because the PRCM is much more than that. It also handles the power > domains for example. Ok, so thinking more about this, I'm still convinced that the MFD framework is only getting in the way here. But I can see having things represented in devicetree properly, with the clocks, etc. as child nodes of the prcm being something which we want. So since all we are using the MFD for is to instantiate platform devices under the prcm nodes, and assign an io resource for the regs to them, why not simply make the prcm node itself a simple-bus. This does everything the MFD prcm driver currently does, without actually needing a specific kernel driver, and as added bonus this will move the definition of the mfd function reg offsets out of the kernel and into the devicetree where they belong in the first place. Please see the attached patches, I've tested this on sun6i, if we go this route we should make the same change on sun8i (I can make the change, but not test it). Regards, Hans From a152b0405d446c748fef146915736e4a8fc548b1 Mon Sep 17 00:00:00 2001 From: Hans de Goede Date: Fri, 28 Nov 2014 13:54:14 +0100 Subject: [PATCH v2 2/2] ARM: dts: sun6i: Add ir_clk node Add an ir_clk sub-node to the prcm node. Signed-off-by: Hans de Goede --- arch/arm/boot/dts/sun6i-a31.dtsi | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi index 4b8541f..92a1c95 100644 --- a/arch/arm/boot/dts/sun6i-a31.dtsi +++ b/arch/arm/boot/dts/sun6i-a31.dtsi @@ -888,6 +888,14 @@ "apb0_i2c"; }; + ir_clk: ir_clk { + reg = <0x01f01454 0x4>; + #clock-cells = <0>; + compatible = "allwinner,sun4i-a10-mod0-clk"; + clocks = <&osc32k>, <&osc24M>; + clock-output-names = "ir"; + }; + apb0_rst: apb0_rst { compatible = "allwinner,sun6i-a31-clock-reset"; reg = <0x01f014b0 0x4>; -- 2.1.0