[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2498365.kqzATN1cjf@diego>
Date: Wed, 31 Aug 2016 23:29:37 +0200
From: Heiko Stübner <heiko@...ech.de>
To: Doug Anderson <dianders@...omium.org>
Cc: Caesar Wang <wxt@...k-chips.com>, netdev@...r.kernel.org,
"open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>,
Brian Norris <briannorris@...omium.org>,
Derek Basehore <dbasehore@...omium.org>,
Roger Chen <roger.chen@...k-chips.com>,
Rob Herring <robh+dt@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will.deacon@....com>,
Xing Zheng <zhengxing@...k-chips.com>,
Masahiro Yamada <yamada.masahiro@...ionext.com>,
Jianqun Xu <jay.xu@...k-chips.com>,
Elaine Zhang <zhangqing@...k-chips.com>,
David Wu <david.wu@...k-chips.com>,
Shunqian Zheng <zhengsq@...k-chips.com>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RESEND PATCH 3/4] arm64: dts: rockchip: support gmac for rk3399
Am Mittwoch, 31. August 2016, 13:42:17 schrieb Doug Anderson:
> Caesar,
>
> On Tue, Aug 30, 2016 at 11:13 PM, Caesar Wang <wxt@...k-chips.com> wrote:
> > This patch adds needed gamc information for rk3399,
> > also support the gmac pd.
> >
> > Signed-off-by: Roger Chen <roger.chen@...k-chips.com>
> > Signed-off-by: Caesar Wang <wxt@...k-chips.com>
> > ---
> >
> > arch/arm64/boot/dts/rockchip/rk3399.dtsi | 90
> > ++++++++++++++++++++++++++++++++ 1 file changed, 90 insertions(+)
>
> I noticed that your subject for this patch contains "RESEND" and not
> "v2" event though there are changes between this version and the last
> one. That's really confusing. This should have been "v2" and the
> next version should be "v3".
>
> > diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> > b/arch/arm64/boot/dts/rockchip/rk3399.dtsi index 32aebc8..abf27a4 100644
> > --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> > +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> > @@ -200,6 +200,26 @@
> >
> > };
> >
> > };
> >
> > + gmac: eth@...00000 {
>
> nit: on rk3288 the node was "ethernet@" instead of "eth@". Presumably
> "ethernet" is more correct?
>
> > + compatible = "rockchip,rk3399-gmac";
> > + reg = <0x0 0xfe300000 0x0 0x10000>;
> > + interrupts = <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>;
> > + interrupt-names = "macirq";
> > + clocks = <&cru SCLK_MAC>, <&cru SCLK_MAC_RX>,
> > + <&cru SCLK_MAC_TX>, <&cru SCLK_MACREF>,
> > + <&cru SCLK_MACREF_OUT>, <&cru ACLK_GMAC>,
> > + <&cru PCLK_GMAC>;
> > + clock-names = "stmmaceth", "mac_clk_rx",
> > + "mac_clk_tx", "clk_mac_ref",
> > + "clk_mac_refout", "aclk_mac",
> > + "pclk_mac";
> > + power-domains = <&power RK3399_PD_GMAC>;
> > + resets = <&cru SRST_A_GMAC>;
> > + reset-names = "stmmaceth";
> > + rockchip,grf = <&grf>;
> > + status = "disabled";
> > + };
> > +
> >
> > sdio0: dwmmc@...10000 {
> >
> > compatible = "rockchip,rk3399-dw-mshc",
> >
> > "rockchip,rk3288-dw-mshc";
> >
> > @@ -611,6 +631,11 @@
> >
> > status = "disabled";
> >
> > };
> >
> > + qos_gmac: qos@...5c000 {
> > + compatible = "syscon";
> > + reg = <0x0 0xffa5c000 0x0 0x20>;
> > + };
> > +
> >
> > qos_hdcp: qos@...90000 {
> >
> > compatible = "syscon";
> > reg = <0x0 0xffa90000 0x0 0x20>;
> >
> > @@ -704,6 +729,11 @@
> >
> > #size-cells = <0>;
> >
> > /* These power domains are grouped by VD_CENTER */
> >
> > + pd_gmac@...399_PD_GMAC {
>
> RK3399_PD_GMAC is not in VD_CENTER but in VD_LOGIC, right? ...so this
> should move.
>
> > + reg = <RK3399_PD_GMAC>;
> > + clocks = <&cru ACLK_GMAC>;
> > + pm_qos = <&qos_gmac>;
> > + };
>
> IMHO it would be nice if this were broken into two patches.
>
> 1. First patch would be the power domain patch and that could land any
> time. You wouldn't actually be able to use the gmac but at least
> you'd be able to turn off its power. This would be a handy patch to
> be able to backport if you happened to not need Ethernet support but
> wanted to save power.
>
> 2. Second patch would actually add the gmac.
according to my talk with Caesar in the real v1, the gmac even with power-
domains should work just nicely even without the dts patches, as the driver
core takes care of powering up the pd before probe.
But I may miss some peculiarity of the dwmac?
Heiko
Powered by blists - more mailing lists