All of lore.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
>
> .
>



WARNING: multiple messages have this Message-ID (diff)
From: YiPing Xu <xuyiping-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org>
To: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Cc: Bintian <bintian.wang-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>,
	mark.rutland-5wv7dgnIgG8@public.gmane.org,
	dan.zhao-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org,
	btw-aAikPa0K0u50tdys+9eLAQ@public.gmane.org,
	catalin.marinas-5wv7dgnIgG8@public.gmane.org,
	wangbinghui-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org,
	will.deacon-5wv7dgnIgG8@public.gmane.org,
	huxinwei-hv44wF8Li93QT0dZR+AlfA@public.gmane.org,
	haojian.zhuang-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
	yanhaifeng-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
	rob.herring-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
	mturquette-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
	victor.lixin-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org,
	xuwei5-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org,
	jh80.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org,
	sledge.yanwei-hv44wF8Li93QT0dZR+AlfA@public.gmane.org,
	kong.kongxinwei-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org,
	heyunlei-hv44wF8Li93QT0dZR+AlfA@public.gmane.org,
	puck.chen-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org,
	zhangfei.gao-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
	z.liuxinliang-hv44wF8Li93QT0dZR+AlfA@public.gmane.org,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	khilman-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
	pawel.moll-5wv7dgnIgG8@public.gmane.org,
	ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org,
	tyler.baker-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
	olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org,
	robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
	linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org,
	zhenwei.wang-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org,
	w.f-hv44wF8Li93QT0dZR+AlfA@public.gmane.org,
	guodong.xu-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
	tomeu.vizoso-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org,
	sboyd@codeaurora.o
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
>
> .
>


--
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

WARNING: multiple messages have this Message-ID (diff)
From: xuyiping@hisilicon.com (YiPing Xu)
To: linux-arm-kernel@lists.infradead.org
Subject: [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: 69+ 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 ` Bintian Wang
2015-04-13  9:17 ` 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-13  9:17   ` Bintian Wang
2015-04-13  9:17   ` Bintian Wang
2015-04-20 21:10   ` Kevin Hilman
2015-04-20 21:10     ` Kevin Hilman
2015-04-20 21:10     ` Kevin Hilman
2015-04-21  0:39     ` Bintian
2015-04-21  0:39       ` Bintian
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   ` Bintian Wang
2015-04-13  9:17   ` Bintian Wang
2015-04-13  9:17 ` [PATCH v2 3/6] clk: hi6220: Document devicetree bindings for hi6220 clock Bintian Wang
2015-04-13  9:17   ` Bintian Wang
2015-04-13  9:17   ` Bintian Wang
2015-04-13 15:32   ` Arnd Bergmann
2015-04-13 15:32     ` Arnd Bergmann
2015-04-13 15:32     ` Arnd Bergmann
2015-04-14  3:35     ` Bintian
2015-04-14  3:35       ` Bintian
2015-04-14  3:35       ` Bintian
2015-04-14 10:19       ` Arnd Bergmann
2015-04-14 10:19         ` Arnd Bergmann
2015-04-14 10:19         ` Arnd Bergmann
2015-04-14 12:37         ` Bintian
2015-04-14 12:37           ` Bintian
2015-04-14 12:37           ` Bintian
2015-04-14 13:20           ` Arnd Bergmann
2015-04-14 13:20             ` Arnd Bergmann
2015-04-14 13:20             ` Arnd Bergmann
2015-04-14 14:37             ` Brent Wang
2015-04-14 14:37               ` Brent Wang
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  9:17   ` Bintian Wang
2015-04-13  9:17   ` Bintian Wang
2015-04-13 11:56   ` Paul Bolle
2015-04-13 11:56     ` Paul Bolle
2015-04-13 11:56     ` Paul Bolle
2015-04-13 13:17     ` Bintian
2015-04-13 13:17       ` Bintian
2015-04-13 13:17       ` Bintian
2015-04-13 14:15       ` Paul Bolle
2015-04-13 14:15         ` Paul Bolle
2015-04-13 14:15         ` Paul Bolle
2015-04-13 13:30   ` Arnd Bergmann
2015-04-13 13:30     ` Arnd Bergmann
2015-04-13 13:30     ` Arnd Bergmann
2015-04-13 13:57     ` Bintian
2015-04-13 13:57       ` Bintian
2015-04-13 13:57       ` Bintian
2015-04-13 15:34       ` Arnd Bergmann
2015-04-13 15:34         ` Arnd Bergmann
2015-04-13 15:34         ` Arnd Bergmann
2015-04-14  8:53         ` YiPing Xu [this message]
2015-04-14  8:53           ` YiPing Xu
2015-04-14  8:53           ` YiPing Xu
2015-04-13  9:17 ` [PATCH v2 5/6] arm64: Kconfig: Add clock support to ARCH_HISI Bintian Wang
2015-04-13  9:17   ` Bintian Wang
2015-04-13  9:17   ` Bintian Wang
2015-04-13  9:17 ` [PATCH v2 6/6] arm64: dts: Add dts files for Hisilicon Hi6220 SoC Bintian Wang
2015-04-13  9:17   ` Bintian Wang
2015-04-13  9:17   ` Bintian Wang
2015-04-14 14:44   ` Arnd Bergmann
2015-04-14 14:44     ` Arnd Bergmann
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.