Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751494AbbBKBt3 (ORCPT ); Tue, 10 Feb 2015 20:49:29 -0500 Received: from mail-ig0-f179.google.com ([209.85.213.179]:62983 "EHLO mail-ig0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751075AbbBKBt1 (ORCPT ); Tue, 10 Feb 2015 20:49:27 -0500 MIME-Version: 1.0 In-Reply-To: <20150210152718.GE9432@leverpostej> References: <1423128277-10297-1-git-send-email-bintian.wang@huawei.com> <1423128277-10297-4-git-send-email-bintian.wang@huawei.com> <20150205193017.GF20735@leverpostej> <20150206104420.GB9921@leverpostej> <20150210133734.GC9432@leverpostej> <20150210152718.GE9432@leverpostej> Date: Wed, 11 Feb 2015 09:49:26 +0800 Message-ID: Subject: Re: [PATCH 3/3] arm64: dts: Add dts files for Hisilicon Hi6220 SoC From: Brent Wang To: Mark Rutland Cc: Bintian Wang , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , Catalin Marinas , Will Deacon , "devicetree@vger.kernel.org" , "robh+dt@kernel.org" , Pawel Moll , "ijc+devicetree@hellion.org.uk" , "galak@codeaurora.org" , "khilman@linaro.org" , "mturquette@linaro.org" , "rob.herring@linaro.org" , "zhangfei.gao@linaro.org" , "haojian.zhuang@linaro.org" , "xuwei5@hisilicon.com" , "jh80.chung@samsung.com" , "olof@lixom.net" , "yanhaifeng@gmail.com" , "sboyd@codeaurora.org" , "xuejiancheng@huawei.com" , "sledge.yanwei@huawei.com" , "tomeu.vizoso@collabora.com" , "linux@arm.linux.org.uk" , "guodong.xu@linaro.org" , "xuyiping@hisilicon.com" , "wangbinghui@hisilicon.com" , "zhenwei.wang@hisilicon.com" , "victor.lixin@hisilicon.com" , "puck.chen@hisilicon.com" , "dan.zhao@hisilicon.com" , "huxinwei@huawei.com" , "z.liuxinliang@huawei.com" , "heyunlei@huawei.com" , "kong.kongxinwei@hisilicon.com" , "btw@mail.itp.ac.cn" , "w.f@huawei.com" , "liguozhu@hisilicon.com" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2971 Lines: 75 Hello Mark, 2015-02-10 23:27 GMT+08:00 Mark Rutland : [...] >> > >> >> >> >> + pm_ctrl: pm_ctrl { >> >> >> >> + compatible = "hisilicon,pmctrl", "syscon"; >> >> >> >> + #address-cells = <1>; >> >> >> >> + #size-cells = <1>; >> >> >> >> + reg = <0x0 0xf7032000 0x0 0x1000>; >> >> >> >> + ranges = <0 0x0 0xf7032000 0x1000>; >> >> >> >> + >> >> >> >> + clock_power: clock3@0 { >> >> >> >> + compatible = "hisilicon,hi6220-clock-power"; >> >> >> >> + reg = <0 0x1000>; >> >> >> >> + #clock-cells = <1>; >> >> >> >> + }; >> >> >> >> + }; >> >> >> > >> >> >> > I really doesn't see the point in having a sub-device that covers the >> >> >> > entirely of the register space of the containing node, and that being >> >> >> > the case I am extremely concerned that the containers are marked as >> >> >> > syscon compatible. >> >> >> The SoC clocks are designed and placed under different system controllers, >> >> >> so I define corresponding nodes under different controllers for clock operation. >> >> > >> >> > What I'm concerned wit hhere is that the pm_ctrl node and the clock3@0 >> >> > sub-node have the _exact_ same register space. >> >> > >> >> > Given this should mean that the clock3@0 node owns that register space, >> >> > having the container node export this as syscon does not make sense. And >> >> > the split between pm_ctrl and clock3@) doesn't seem to make sense given >> >> > they cover the same space. >> >> I understand your worry and will find the max offset of those clocks >> >> under this controller. >> >> >> >> > >> >> > As I asked before, why is pm_ctrl marked as a syscon, and what's the >> >> > point of the separate sub-node? >> >> There is no big difference between pm_ctrl and other controller, they >> >> are all designed as >> >> the base address to control some functions of other modules (certainly >> >> include some clock gates). >> > >> > Are they just different instances of the same IP block, or are there >> > fundamental differences between them? >> You can understand it as a different instance of the same IP block, >> there is no fundamental >> differences between them. > > Ok. If that's the case each should have the same compatible string. Although they have same function, they control different domain, I should use different compatible string to distinguish different domains. Thanks, Bintian > > Thanks, > Mark. -- Best Regards, Bintian =========================== Don't be nervous, just be happy! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/