public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: YiPing Xu <xuyiping@hisilicon.com>
To: Arnd Bergmann <arnd@arndb.de>, <linux-arm-kernel@lists.infradead.org>
Cc: Bintian <bintian.wang@huawei.com>, <mark.rutland@arm.com>,
	<dan.zhao@hisilicon.com>, <btw@mail.itp.ac.cn>,
	<catalin.marinas@arm.com>, <wangbinghui@hisilicon.com>,
	<will.deacon@arm.com>, <huxinwei@huawei.com>,
	<haojian.zhuang@linaro.org>, <yanhaifeng@gmail.com>,
	<rob.herring@linaro.org>, <mturquette@linaro.org>,
	<victor.lixin@hisilicon.com>, <xuwei5@hisilicon.com>,
	<jh80.chung@samsung.com>, <sledge.yanwei@huawei.com>,
	<kong.kongxinwei@hisilicon.com>, <heyunlei@huawei.com>,
	<puck.chen@hisilicon.com>, <zhangfei.gao@linaro.org>,
	<z.liuxinliang@huawei.com>, <devicetree@vger.kernel.org>,
	<khilman@linaro.org>, <pawel.moll@arm.com>,
	<ijc+devicetree@hellion.org.uk>, <tyler.baker@linaro.org>,
	<olof@lixom.net>, <robh+dt@kernel.org>, <linux@arm.linux.org.uk>,
	<zhenwei.wang@hisilicon.com>, <w.f@huawei.com>,
	<guodong.xu@linaro.org>, <tomeu.vizoso@collabora.com>,
	<sboyd@codeaurora.org>, <linux-kernel@vger.kernel.org>,
	<galak@codeaurora.org>, <xuejiancheng@huawei.com>,
	<jorge.ramirez-ortiz@linaro.org>, <liguozhu@hisilicon.com>
Subject: Re: [PATCH v2 4/6] clk: hi6220: Clock driver support for Hisilicon hi6220 SoC
Date: Tue, 14 Apr 2015 16:53:45 +0800	[thread overview]
Message-ID: <552CD599.4010705@hisilicon.com> (raw)
In-Reply-To: <3183355.UnoLoN8dF8@wuerfel>

在 2015/4/13 23:34, Arnd Bergmann 写道:
> On Monday 13 April 2015 21:57:46 Bintian wrote:
>> Hello Arnd,
>>
>> Thanks for your code review.
>>
>> On 2015/4/13 21:30, Arnd Bergmann wrote:
>>> On Monday 13 April 2015 17:17:38 Bintian Wang wrote:
>>>> +#define HI6220_CFG_CSI2PHY     8
>>>> +#define HI6220_ISP_SCLK_GATE   9
>>>> +#define HI6220_ISP_SCLK_GATE1  10
>>>> +#define HI6220_ADE_CORE_GATE   11
>>>> +#define HI6220_CODEC_VPU_GATE  12
>>>> +#define HI6220_MED_SYSPLL      13
>>>> +
>>>> +/* mux clocks */
>>>> +#define HI6220_1440_1200       20
>>>> +#define HI6220_1000_1200       21
>>>> +#define HI6220_1000_1440       22
>>>> +
>>>> +/* divider clocks */
>>>> +#define HI6220_CODEC_JPEG      30
>>>> +#define HI6220_ISP_SCLK_SRC    31
>>>> +#define HI6220_ISP_SCLK1       32
>>>>
>>>
>>> The numbers seem rather arbitrary, and you have both holes as well as duplicate
>>> numbers here. I would suggest you do one of two things instead:
>
>> I just worry about some special clocks may be added later so keep some
>> holes for them;
>>
>> The duplicate numbers means clocks belong to different system control
>> domains.
>
> I don't understand. How would there be additional clocks added later?
> Wouldn't that be a new chip?

   There are some clocks not used in linux system. e.g, some clocks are 
used in base band processor. So, some numbers are not defined here.

> If you have separate system control domains, doesn't that mean that you
> also have separate DT bindings?
>
>>> a) have a separate header file per clock driver and make all the
>>>      numbers unique and consecutive within that header
>>>
>>> b) use the same numbers as the hardware registers so you can put the
>>>      numbers directly into the dts and don't need a header to create
>>>      an artificial ABI between the clock driver and the boot loader.
>> This header file will be used by device tree (I like using the clock
>> name instead "magic number" in dts :) )
>
> That's not how it works though: The dts file is the place to define
> the hardware numbers, we do that for all sorts of numbers: interrupts,
> gpios, register ranges etc are all defined in dts to avoid putting
> magic numbers in external header files.
>
> There are some cases where it gets too ugly for clock controllers
> that are highly irregular, but yours doesn't seem to be that kind.
>
> E.g. all the fixed rate clocks should just be separate device nodes,
> which lets you remove the binding for that node.
>
>> so how about keep them in one header file and let dts just include
>> one header file (not four files), but remove the holes?
>
> The header files constantly cause problems with merge dependencies,
> and we have some other companies that keep releasing new chips
> that each time require a new header file. If hisilicon plans to make
> more chips like this one, please consider coming up with more
> generic bindings to avoid this.
>
> 	Arnd
>
> .
>



  reply	other threads:[~2015-04-14  8:54 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-13  9:17 [PATCH v2 0/6] arm64,hi6220: Enable Hisilicon Hi6220 SoC Bintian Wang
2015-04-13  9:17 ` [PATCH v2 1/6] arm64: Enable Hisilicon ARMv8 SoC family in Kconfig and defconfig Bintian Wang
2015-04-20 21:10   ` Kevin Hilman
2015-04-21  0:39     ` Bintian
2015-04-13  9:17 ` [PATCH v2 2/6] arm64: hi6220: Document devicetree bindings for Hisilicon hi6220 SoC Bintian Wang
2015-04-13  9:17 ` [PATCH v2 3/6] clk: hi6220: Document devicetree bindings for hi6220 clock Bintian Wang
2015-04-13 15:32   ` Arnd Bergmann
2015-04-14  3:35     ` Bintian
2015-04-14 10:19       ` Arnd Bergmann
2015-04-14 12:37         ` Bintian
2015-04-14 13:20           ` Arnd Bergmann
2015-04-14 14:37             ` Brent Wang
2015-04-13  9:17 ` [PATCH v2 4/6] clk: hi6220: Clock driver support for Hisilicon hi6220 SoC Bintian Wang
2015-04-13 11:56   ` Paul Bolle
2015-04-13 13:17     ` Bintian
2015-04-13 14:15       ` Paul Bolle
2015-04-13 13:30   ` Arnd Bergmann
2015-04-13 13:57     ` Bintian
2015-04-13 15:34       ` Arnd Bergmann
2015-04-14  8:53         ` YiPing Xu [this message]
2015-04-13  9:17 ` [PATCH v2 5/6] arm64: Kconfig: Add clock support to ARCH_HISI Bintian Wang
2015-04-13  9:17 ` [PATCH v2 6/6] arm64: dts: Add dts files for Hisilicon Hi6220 SoC Bintian Wang
2015-04-14 14:44   ` Arnd Bergmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=552CD599.4010705@hisilicon.com \
    --to=xuyiping@hisilicon.com \
    --cc=arnd@arndb.de \
    --cc=bintian.wang@huawei.com \
    --cc=btw@mail.itp.ac.cn \
    --cc=catalin.marinas@arm.com \
    --cc=dan.zhao@hisilicon.com \
    --cc=devicetree@vger.kernel.org \
    --cc=galak@codeaurora.org \
    --cc=guodong.xu@linaro.org \
    --cc=haojian.zhuang@linaro.org \
    --cc=heyunlei@huawei.com \
    --cc=huxinwei@huawei.com \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=jh80.chung@samsung.com \
    --cc=jorge.ramirez-ortiz@linaro.org \
    --cc=khilman@linaro.org \
    --cc=kong.kongxinwei@hisilicon.com \
    --cc=liguozhu@hisilicon.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=mark.rutland@arm.com \
    --cc=mturquette@linaro.org \
    --cc=olof@lixom.net \
    --cc=pawel.moll@arm.com \
    --cc=puck.chen@hisilicon.com \
    --cc=rob.herring@linaro.org \
    --cc=robh+dt@kernel.org \
    --cc=sboyd@codeaurora.org \
    --cc=sledge.yanwei@huawei.com \
    --cc=tomeu.vizoso@collabora.com \
    --cc=tyler.baker@linaro.org \
    --cc=victor.lixin@hisilicon.com \
    --cc=w.f@huawei.com \
    --cc=wangbinghui@hisilicon.com \
    --cc=will.deacon@arm.com \
    --cc=xuejiancheng@huawei.com \
    --cc=xuwei5@hisilicon.com \
    --cc=yanhaifeng@gmail.com \
    --cc=z.liuxinliang@huawei.com \
    --cc=zhangfei.gao@linaro.org \
    --cc=zhenwei.wang@hisilicon.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox