From: "Heiko Stübner" <heiko@sntech.de>
To: Caesar Wang <caesar.upstream@gmail.com>
Cc: Elaine Zhang <zhangqing@rock-chips.com>,
wxt@rock-chips.com, khilman@baylibre.com,
huangtao@rock-chips.com, xxx@rock-chips.com,
linux-kernel@vger.kernel.org, linux-rockchip@lists.infradead.org,
zyw@rock-chips.com, jay.xu@rock-chips.com,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v5 4/6] dt/bindings: power: add RK3399 SoCs header for power-domain
Date: Wed, 09 Mar 2016 11:57:30 +0100 [thread overview]
Message-ID: <1757559.IpfTQRFBYT@diego> (raw)
In-Reply-To: <56DFFCAA.2030401@gmail.com>
Hi Caesar,
Am Mittwoch, 9. März 2016, 18:36:26 schrieb Caesar Wang:
> 在 2016年03月09日 17:55, Heiko Stübner 写道:
> > Hi Caesar,
> >
> > Am Dienstag, 8. März 2016, 18:45:06 schrieb Caesar Wang:
> >> 在 2016年03月03日 16:03, Elaine Zhang 写道:
> >>> According to a description from TRM, add all the power domains
> >>>
> >>> Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
> >>> ---
> >>>
> >>> include/dt-bindings/power/rk3399-power.h | 53
> >>> ++++++++++++++++++++++++++++++++ 1 file changed, 53 insertions(+)
> >>> create mode 100644 include/dt-bindings/power/rk3399-power.h
> >>>
> >>> diff --git a/include/dt-bindings/power/rk3399-power.h
> >>> b/include/dt-bindings/power/rk3399-power.h new file mode 100644
> >>> index 0000000..69fbd67
> >>> --- /dev/null
> >>> +++ b/include/dt-bindings/power/rk3399-power.h
> >>> @@ -0,0 +1,53 @@
> >>> +#ifndef __DT_BINDINGS_POWER_RK3399_POWER_H__
> >>> +#define __DT_BINDINGS_POWER_RK3399_POWER_H__
> >>> +
> >>> +/* VD_CORE_L */
> >>> +#define RK3399_PD_A53_L0 0
> >>> +#define RK3399_PD_A53_L1 1
> >>> +#define RK3399_PD_A53_L2 2
> >>> +#define RK3399_PD_A53_L3 3
> >>> +#define RK3399_PD_SCU_L 4
> >>> +
> >>> +/* VD_CORE_B */
> >>> +#define RK3399_PD_A72_B0 5
> >>> +#define RK3399_PD_A72_B1 6
> >>> +#define RK3399_PD_SCU_B 7
> >>> +
> >>> +/* VD_CENTER */
> >>> +#define RK3399_PD_CENTER 8
> >>> +#define RK3399_PD_VCODEC 9
> >>> +#define RK3399_PD_RGA 10
> >>> +#define RK3399_PD_IEP 11
> >>> +#define RK3399_PD_VDU 12
> >>> +
> >>> +/* VD_LOGIC */
> >>> +#define RK3399_PD_PERILP 13
> >>> +#define RK3399_PD_PERIHP 14
> >>> +#define RK3399_PD_VIO 15
> >>> +#define RK3399_PD_VO 16
> >>
> >> ...
> >> ISP?
> >>
> >>> +#define RK3399_PD_VOPB 17
> >>> +#define RK3399_PD_VOPL 18
> >>> +#define RK3399_PD_ISP0 19
> >>> +#define RK3399_PD_ISP1 20
> >>> +#define RK3399_PD_HDCP 21
> >>> +#define RK3399_PD_TCPD0 22
> >>> +#define RK3399_PD_TCPD1 23
> >>> +#define RK3399_PD_GIC 24
> >>> +#define RK3399_PD_ALIVE 25
> >>> +#define RK3399_PD_USB3 26
> >>> +#define RK3399_PD_SD 27
> >>> +#define RK3399_PD_CCI 28
> >>> +#define RK3399_PD_CCI0 29
> >>> +#define RK3399_PD_CCI1 30
> >>> +#define RK3399_PD_GMAC 31
> >>> +#define RK3399_PD_EMMC 32
> >>> +#define RK3399_PD_EDP 33
> >>> +#define RK3399_PD_SDIOAUDIO 34
> >>> +
> >>> +/* VD_GPU */
> >>> +#define RK3399_PD_GPU 35
> >>> +
> >>> +/* VD_PMU */
> >>> +#define RK3399_PD_PMU 36
> >>> +
> >>
> >> Would you please follow the TRM?
> >
> > could you elaborate a bit on what you mean?
> >
> > Looking at the "Table 11-1 RK3399 Power Domain and Voltage Domain Summary"
> > in the TRM, Elaine's list seems to match that table quite nicely, so
> > looks ok to me at first glance.
>
> That's also trivial...
>
> The comments from the first time I saw this file and TRM.:-)
>
> Can we define the lists according to order the TRM?
>
> For example:
>
> +/* VD_CORE_L */
> +#define RK3399_PD_A53_L0 0
> +#define RK3399_PD_A53_L1 1
> +#define RK3399_PD_A53_L2 2
> +#define RK3399_PD_A53_L3 3
> +#define RK3399_PD_SCU_L 4
> +
> +/* VD_CORE_B */
> +#define RK3399_PD_A72_B0 5
> +#define RK3399_PD_A72_B1 6
> +#define RK3399_PD_SCU_B 7
> +
> +/* VD_LOGIC */
> +#define RK3399_PD_PERILP 13
> +#define RK3399_PD_PERIHP 14
> +#define RK3399_PD_VIO 15
> +#define RK3399_PD_ISP0 16
> +#define RK3399_PD_ISP1 17
> +#define RK3399_PD_VO 18
> +#define RK3399_PD_HDCP 19
> +#define RK3399_PD_TCPD0 20
> +#define RK3399_PD_TCPD1 21
> .....
>
> +/* VD_CENTER */
> ....
>
> +/* VD_GPU */
> ....
>
> +/* VD_PMU */
>
>
> Please ignore it and sorry the noise if that's the wrong ideas.:-)
I may be simply be blind, but I don't see the difference .... ah no, now I see
it, some voltage domains are swapped in the original (VD_CENTER before
VD_LOGIC, while in the TRM it's the other way around).
So while it doesn't matter much, I would slightly prefer the ordering being
according to the TRM table. Reason is the same as for ordering the clock-tree
according to the diagrams - it makes future reading easier ;-)
Heiko
WARNING: multiple messages have this Message-ID (diff)
From: heiko@sntech.de (Heiko Stübner)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v5 4/6] dt/bindings: power: add RK3399 SoCs header for power-domain
Date: Wed, 09 Mar 2016 11:57:30 +0100 [thread overview]
Message-ID: <1757559.IpfTQRFBYT@diego> (raw)
In-Reply-To: <56DFFCAA.2030401@gmail.com>
Hi Caesar,
Am Mittwoch, 9. M?rz 2016, 18:36:26 schrieb Caesar Wang:
> ? 2016?03?09? 17:55, Heiko St?bner ??:
> > Hi Caesar,
> >
> > Am Dienstag, 8. M?rz 2016, 18:45:06 schrieb Caesar Wang:
> >> ? 2016?03?03? 16:03, Elaine Zhang ??:
> >>> According to a description from TRM, add all the power domains
> >>>
> >>> Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
> >>> ---
> >>>
> >>> include/dt-bindings/power/rk3399-power.h | 53
> >>> ++++++++++++++++++++++++++++++++ 1 file changed, 53 insertions(+)
> >>> create mode 100644 include/dt-bindings/power/rk3399-power.h
> >>>
> >>> diff --git a/include/dt-bindings/power/rk3399-power.h
> >>> b/include/dt-bindings/power/rk3399-power.h new file mode 100644
> >>> index 0000000..69fbd67
> >>> --- /dev/null
> >>> +++ b/include/dt-bindings/power/rk3399-power.h
> >>> @@ -0,0 +1,53 @@
> >>> +#ifndef __DT_BINDINGS_POWER_RK3399_POWER_H__
> >>> +#define __DT_BINDINGS_POWER_RK3399_POWER_H__
> >>> +
> >>> +/* VD_CORE_L */
> >>> +#define RK3399_PD_A53_L0 0
> >>> +#define RK3399_PD_A53_L1 1
> >>> +#define RK3399_PD_A53_L2 2
> >>> +#define RK3399_PD_A53_L3 3
> >>> +#define RK3399_PD_SCU_L 4
> >>> +
> >>> +/* VD_CORE_B */
> >>> +#define RK3399_PD_A72_B0 5
> >>> +#define RK3399_PD_A72_B1 6
> >>> +#define RK3399_PD_SCU_B 7
> >>> +
> >>> +/* VD_CENTER */
> >>> +#define RK3399_PD_CENTER 8
> >>> +#define RK3399_PD_VCODEC 9
> >>> +#define RK3399_PD_RGA 10
> >>> +#define RK3399_PD_IEP 11
> >>> +#define RK3399_PD_VDU 12
> >>> +
> >>> +/* VD_LOGIC */
> >>> +#define RK3399_PD_PERILP 13
> >>> +#define RK3399_PD_PERIHP 14
> >>> +#define RK3399_PD_VIO 15
> >>> +#define RK3399_PD_VO 16
> >>
> >> ...
> >> ISP?
> >>
> >>> +#define RK3399_PD_VOPB 17
> >>> +#define RK3399_PD_VOPL 18
> >>> +#define RK3399_PD_ISP0 19
> >>> +#define RK3399_PD_ISP1 20
> >>> +#define RK3399_PD_HDCP 21
> >>> +#define RK3399_PD_TCPD0 22
> >>> +#define RK3399_PD_TCPD1 23
> >>> +#define RK3399_PD_GIC 24
> >>> +#define RK3399_PD_ALIVE 25
> >>> +#define RK3399_PD_USB3 26
> >>> +#define RK3399_PD_SD 27
> >>> +#define RK3399_PD_CCI 28
> >>> +#define RK3399_PD_CCI0 29
> >>> +#define RK3399_PD_CCI1 30
> >>> +#define RK3399_PD_GMAC 31
> >>> +#define RK3399_PD_EMMC 32
> >>> +#define RK3399_PD_EDP 33
> >>> +#define RK3399_PD_SDIOAUDIO 34
> >>> +
> >>> +/* VD_GPU */
> >>> +#define RK3399_PD_GPU 35
> >>> +
> >>> +/* VD_PMU */
> >>> +#define RK3399_PD_PMU 36
> >>> +
> >>
> >> Would you please follow the TRM?
> >
> > could you elaborate a bit on what you mean?
> >
> > Looking at the "Table 11-1 RK3399 Power Domain and Voltage Domain Summary"
> > in the TRM, Elaine's list seems to match that table quite nicely, so
> > looks ok to me at first glance.
>
> That's also trivial...
>
> The comments from the first time I saw this file and TRM.:-)
>
> Can we define the lists according to order the TRM?
>
> For example:
>
> +/* VD_CORE_L */
> +#define RK3399_PD_A53_L0 0
> +#define RK3399_PD_A53_L1 1
> +#define RK3399_PD_A53_L2 2
> +#define RK3399_PD_A53_L3 3
> +#define RK3399_PD_SCU_L 4
> +
> +/* VD_CORE_B */
> +#define RK3399_PD_A72_B0 5
> +#define RK3399_PD_A72_B1 6
> +#define RK3399_PD_SCU_B 7
> +
> +/* VD_LOGIC */
> +#define RK3399_PD_PERILP 13
> +#define RK3399_PD_PERIHP 14
> +#define RK3399_PD_VIO 15
> +#define RK3399_PD_ISP0 16
> +#define RK3399_PD_ISP1 17
> +#define RK3399_PD_VO 18
> +#define RK3399_PD_HDCP 19
> +#define RK3399_PD_TCPD0 20
> +#define RK3399_PD_TCPD1 21
> .....
>
> +/* VD_CENTER */
> ....
>
> +/* VD_GPU */
> ....
>
> +/* VD_PMU */
>
>
> Please ignore it and sorry the noise if that's the wrong ideas.:-)
I may be simply be blind, but I don't see the difference .... ah no, now I see
it, some voltage domains are swapped in the original (VD_CENTER before
VD_LOGIC, while in the TRM it's the other way around).
So while it doesn't matter much, I would slightly prefer the ordering being
according to the TRM table. Reason is the same as for ordering the clock-tree
according to the diagrams - it makes future reading easier ;-)
Heiko
next prev parent reply other threads:[~2016-03-09 10:57 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-03 8:03 [PATCH v5 0/6] rockchip: power-domain: fix pm domain for support RK3399 SoC Elaine Zhang
2016-03-03 8:03 ` Elaine Zhang
2016-03-03 8:03 ` [PATCH v5 1/6] rockchip: power-domain: make idle handling optional Elaine Zhang
2016-03-03 8:03 ` Elaine Zhang
2016-03-03 8:03 ` [PATCH v5 2/6] power-domain: allow domains only handling idle requests Elaine Zhang
2016-03-03 8:03 ` Elaine Zhang
2016-03-03 8:03 ` [PATCH v5 3/6] rockchip: power-domain: add support for sub-power domains Elaine Zhang
2016-03-03 8:03 ` Elaine Zhang
2016-03-08 10:41 ` Caesar Wang
2016-03-08 10:41 ` Caesar Wang
2016-03-03 8:03 ` [PATCH v5 4/6] dt/bindings: power: add RK3399 SoCs header for power-domain Elaine Zhang
2016-03-03 8:03 ` Elaine Zhang
2016-03-08 10:45 ` Caesar Wang
2016-03-08 10:45 ` Caesar Wang
2016-03-09 8:43 ` Elaine Zhang
2016-03-09 8:43 ` Elaine Zhang
2016-03-09 9:55 ` Heiko Stübner
2016-03-09 9:55 ` Heiko Stübner
2016-03-09 10:36 ` Caesar Wang
2016-03-09 10:36 ` Caesar Wang
2016-03-09 10:57 ` Heiko Stübner [this message]
2016-03-09 10:57 ` Heiko Stübner
2016-03-03 8:09 ` [PATCH v5 5/6] dt/bindings: rockchip: modify document of Rockchip power domains Elaine Zhang
2016-03-03 8:09 ` Elaine Zhang
2016-03-08 11:09 ` Caesar Wang
2016-03-08 11:09 ` Caesar Wang
[not found] ` <56DEB2E1.6060808-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-03-09 8:48 ` Elaine Zhang
2016-03-09 8:48 ` Elaine Zhang
2016-03-09 8:48 ` Elaine Zhang
2016-03-03 8:09 ` [PATCH v5 6/6] rockchip: power-domain: Modify power domain driver for rk3399 Elaine Zhang
2016-03-03 8:09 ` Elaine Zhang
2016-03-08 10:59 ` Caesar Wang
2016-03-08 10:59 ` Caesar Wang
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=1757559.IpfTQRFBYT@diego \
--to=heiko@sntech.de \
--cc=caesar.upstream@gmail.com \
--cc=huangtao@rock-chips.com \
--cc=jay.xu@rock-chips.com \
--cc=khilman@baylibre.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=wxt@rock-chips.com \
--cc=xxx@rock-chips.com \
--cc=zhangqing@rock-chips.com \
--cc=zyw@rock-chips.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.