From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bjorn Andersson Subject: Re: [PATCH v11 2/6] mailbox: qcom: Create APCS child device for clock controller Date: Sat, 23 Dec 2017 21:06:26 -0800 Message-ID: <20171224050625.GH12655@minitux> References: <20171205154701.27730-1-georgi.djakov@linaro.org> <20171205154701.27730-3-georgi.djakov@linaro.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Jassi Brar Cc: Georgi Djakov , Stephen Boyd , Michael Turquette , Rob Herring , linux-clk-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux Kernel Mailing List , linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Devicetree List List-Id: linux-arm-msm@vger.kernel.org On Fri 22 Dec 20:57 PST 2017, Jassi Brar wrote: > On Tue, Dec 5, 2017 at 9:16 PM, Georgi Djakov wrote: > > There is a clock controller functionality provided by the APCS hardware > > block of msm8916 devices. The device-tree would represent an APCS node > > with both mailbox and clock provider properties. > > > The spec might depict a 'clock' box and 'mailbox' box inside the > bigger APCS box. However, from the code I see in this patchset, they > are orthogonal and can & should be represented as independent DT > nodes. The APCS consists of a number of different hardware blocks, one of them being the "APCS global" block, which is what this node and drivers relate to. On 8916 this contains both the IPC register and clock control. But it's still just one block according to the hardware specification. As such DT should describe the one hardware block by one node IMHO. The fact that we in Linux split this into two different drivers is an unrelated implementation detail. Regards, Bjorn -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751610AbdLXFGc (ORCPT ); Sun, 24 Dec 2017 00:06:32 -0500 Received: from mail-pl0-f65.google.com ([209.85.160.65]:41251 "EHLO mail-pl0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750860AbdLXFG3 (ORCPT ); Sun, 24 Dec 2017 00:06:29 -0500 X-Google-Smtp-Source: ACJfBosUlcKVdICPbukCqHPATzekOPCoPpGMwBqyKKVHihFHP9stx5uuZX+8970rMpVRtPWZbST15A== Date: Sat, 23 Dec 2017 21:06:26 -0800 From: Bjorn Andersson To: Jassi Brar Cc: Georgi Djakov , Stephen Boyd , Michael Turquette , Rob Herring , linux-clk@vger.kernel.org, Linux Kernel Mailing List , linux-arm-msm@vger.kernel.org, Devicetree List Subject: Re: [PATCH v11 2/6] mailbox: qcom: Create APCS child device for clock controller Message-ID: <20171224050625.GH12655@minitux> References: <20171205154701.27730-1-georgi.djakov@linaro.org> <20171205154701.27730-3-georgi.djakov@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri 22 Dec 20:57 PST 2017, Jassi Brar wrote: > On Tue, Dec 5, 2017 at 9:16 PM, Georgi Djakov wrote: > > There is a clock controller functionality provided by the APCS hardware > > block of msm8916 devices. The device-tree would represent an APCS node > > with both mailbox and clock provider properties. > > > The spec might depict a 'clock' box and 'mailbox' box inside the > bigger APCS box. However, from the code I see in this patchset, they > are orthogonal and can & should be represented as independent DT > nodes. The APCS consists of a number of different hardware blocks, one of them being the "APCS global" block, which is what this node and drivers relate to. On 8916 this contains both the IPC register and clock control. But it's still just one block according to the hardware specification. As such DT should describe the one hardware block by one node IMHO. The fact that we in Linux split this into two different drivers is an unrelated implementation detail. Regards, Bjorn