[RESEND PATCH v1 0/4] Add support emac for the RK3036 SoC platform

[RESEND PATCH v1 0/4] Add support emac for the RK3036 SoC platform

[Xing Zheng]

Hi,
  We have supported the emac for RK3066/RK3188, but the RK3036 have some
configuration different with them. We should let the driver of emac_rockchip
compatible with other Rockchip SoCs.



Xing Zheng (4):
  net: ethernet: arc: Probe emac after set RMII clock
  net: ethernet: arc: Keep emac compatibility for more Rockchip SoCs
  net: ethernet: arc: Add support emac for RK3036
  ARM: dts: rockchip: Add support emac for RK3036

 arch/arm/boot/dts/rk3036-evb.dts         |   25 +++++++++
 arch/arm/boot/dts/rk3036-kylin.dts       |   23 ++++++++
 arch/arm/boot/dts/rk3036.dtsi            |   32 +++++++++++
 drivers/net/ethernet/arc/Kconfig         |    4 +-
 drivers/net/ethernet/arc/emac_rockchip.c |   86 ++++++++++++++++++++----------
 5 files changed, 140 insertions(+), 30 deletions(-)

-- 
1.7.9.5

[RESEND PATCH v1 4/4] ARM: dts: rockchip: Add support emac for RK3036

[Xing Zheng]

This patch describe the emac, and we need to let mac clock under
the APLL which is able to provide the accurate 50MHz what mac_ref
need.

Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
---

 arch/arm/boot/dts/rk3036-evb.dts   |   25 +++++++++++++++++++++++++
 arch/arm/boot/dts/rk3036-kylin.dts |   23 +++++++++++++++++++++++
 arch/arm/boot/dts/rk3036.dtsi      |   32 ++++++++++++++++++++++++++++++++
 3 files changed, 80 insertions(+)

diff --git a/arch/arm/boot/dts/rk3036-evb.dts b/arch/arm/boot/dts/rk3036-evb.dts
index 28a0336..69b96e6 100644
--- a/arch/arm/boot/dts/rk3036-evb.dts
+++ b/arch/arm/boot/dts/rk3036-evb.dts
@@ -62,3 +62,28 @@
 &uart2 {
 	status = "okay";
 };
+
+&emac {
+	assigned-clocks = <&cru SCLK_MACPLL>;
+	assigned-clock-parents = <&cru PLL_APLL>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&emac_xfer>, <&emac_mdio>, <&rmii_rst>;
+	phy = <&phy0>;
+	status = "okay";
+
+	phy0: ethernet-phy@0 {
+		reg = <0>;
+	};
+};
+
+&pinctrl {
+	pcfg_output_high: pcfg-output-high {
+		output-high;
+	};
+
+	emac {
+		rmii_rst: rmii-rst {
+			rockchip,pins = <2 22 RK_FUNC_GPIO &pcfg_output_high>;
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/rk3036-kylin.dts b/arch/arm/boot/dts/rk3036-kylin.dts
index 992f9ca..3fb1cfe 100644
--- a/arch/arm/boot/dts/rk3036-kylin.dts
+++ b/arch/arm/boot/dts/rk3036-kylin.dts
@@ -285,7 +285,24 @@
 	status = "okay";
 };
 
+&emac {
+	assigned-clocks = <&cru SCLK_MACPLL>;
+	assigned-clock-parents = <&cru PLL_APLL>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&emac_xfer>, <&emac_mdio>, <&rmii_rst>;
+	phy = <&phy0>;
+	status = "okay";
+
+	phy0: ethernet-phy@0 {
+		reg = <0>;
+	};
+};
+
 &pinctrl {
+	pcfg_output_high: pcfg-output-high {
+		output-high;
+	};
+
 	pmic {
 		pmic_int: pmic-int {
 			rockchip,pins = <2 2 RK_FUNC_GPIO &pcfg_pull_default>;
@@ -297,4 +314,10 @@
 			rockchip,pins = <2 7 RK_FUNC_1 &pcfg_pull_none>;
 		};
 	};
+
+	emac {
+		rmii_rst: rmii-rst {
+			rockchip,pins = <2 22 RK_FUNC_GPIO &pcfg_output_high>;
+		};
+	};
 };
diff --git a/arch/arm/boot/dts/rk3036.dtsi b/arch/arm/boot/dts/rk3036.dtsi
index b9567c1..0c09fb3 100644
--- a/arch/arm/boot/dts/rk3036.dtsi
+++ b/arch/arm/boot/dts/rk3036.dtsi
@@ -186,6 +186,20 @@
 		status = "disabled";
 	};
 
+	emac: ethernet@10200000 {
+		compatible = "rockchip,rk3036-emac", "snps,arc-emac";
+		reg = <0x10200000 0x4000>;
+		interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		rockchip,grf = <&grf>;
+		clocks = <&cru HCLK_MAC>, <&cru SCLK_MACREF>, <&cru SCLK_MAC>;
+		clock-names = "hclk", "macref", "macclk";
+		max-speed = <100>;
+		phy-mode = "rmii";
+		status = "disabled";
+	};
+
 	sdmmc: dwmmc@10214000 {
 		compatible = "rockchip,rk3036-dw-mshc", "rockchip,rk3288-dw-mshc";
 		reg = <0x10214000 0x4000>;
@@ -556,6 +570,24 @@
 			};
 		};
 
+		emac {
+			emac_xfer: emac-xfer {
+				rockchip,pins = <2 10 RK_FUNC_1 &pcfg_pull_none>, /* crs_dvalid */
+						<2 13 RK_FUNC_1 &pcfg_pull_none>, /* tx_en */
+						<2 14 RK_FUNC_1 &pcfg_pull_none>, /* mac_clk */
+						<2 15 RK_FUNC_1 &pcfg_pull_none>, /* rx_err */
+						<2 16 RK_FUNC_1 &pcfg_pull_none>, /* rxd1 */
+						<2 17 RK_FUNC_1 &pcfg_pull_none>, /* rxd0 */
+						<2 18 RK_FUNC_1 &pcfg_pull_none>, /* txd1 */
+						<2 19 RK_FUNC_1 &pcfg_pull_none>; /* txd0 */
+			};
+
+			emac_mdio: emac-mdio {
+				rockchip,pins = <2 12 RK_FUNC_1 &pcfg_pull_none>, /* mac_md */
+						<2 25 RK_FUNC_1 &pcfg_pull_none>; /* mac_mdclk */
+			};
+		};
+
 		i2c0 {
 			i2c0_xfer: i2c0-xfer {
 				rockchip,pins = <0 0 RK_FUNC_1 &pcfg_pull_none>,
-- 
1.7.9.5

Re: [RESEND PATCH v1 0/4] Add support emac for the RK3036 SoC platform

[David Miller]

You have to submit this series properly, the same problem happend twice
now.

When you submit a series you should:

1) Make it clear which tree you expect these changes to be applied
   to.  Here it is completely ambiguous, do you want it to go into
   my networking tree or some other subsystem tree?

2) You MUST keep all parties informed about all patches for a series
   like this.  That means you cannot drop netdev from patch #4 as
   you did both times.  Doing this aggravates the situation for
   #1 even more, because if a patch is not CC:'d to netdev it does
   not enter patchwork.  And if it doesn't go into patchwork, I'm
   not looking at it.

Thanks.

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

Re: [RESEND PATCH v1 0/4] Add support emac for the RK3036 SoC platform

[Heiko Stübner]

Hi Dave,

Am Dienstag, 29. Dezember 2015, 15:53:14 schrieb David Miller:
> You have to submit this series properly, the same problem happend twice
> now.
> 
> When you submit a series you should:
> 
> 1) Make it clear which tree you expect these changes to be applied
>    to.  Here it is completely ambiguous, do you want it to go into
>    my networking tree or some other subsystem tree?
> 
> 2) You MUST keep all parties informed about all patches for a series
>    like this.  That means you cannot drop netdev from patch #4 as
>    you did both times.  Doing this aggravates the situation for
>    #1 even more, because if a patch is not CC:'d to netdev it does
>    not enter patchwork.  And if it doesn't go into patchwork, I'm
>    not looking at it.

I guess that is some unfortunate result of git send-email combined with 
get_maintainer.pl . In general I also prefer to see the whole series, but have 
gotten such partial series from other maintainers as well in the past, so it 
seems to be depending on preferences somewhat.

For the series at hand, the 4th patch is the devicetree addition, which the 
expected way is me picking it up, after you are comfortable with the code-
related changes.


Heiko

Re: [RESEND PATCH v1 0/4] Add support emac for the RK3036 SoC platform

[Florian Fainelli]

On December 29, 2015 2:27:55 PM PST, "Heiko Stübner" <heiko@sntech.de> wrote:
>Hi Dave,
>
>Am Dienstag, 29. Dezember 2015, 15:53:14 schrieb David Miller:
>> You have to submit this series properly, the same problem happend
>twice
>> now.
>> 
>> When you submit a series you should:
>> 
>> 1) Make it clear which tree you expect these changes to be applied
>>    to.  Here it is completely ambiguous, do you want it to go into
>>    my networking tree or some other subsystem tree?
>> 
>> 2) You MUST keep all parties informed about all patches for a series
>>    like this.  That means you cannot drop netdev from patch #4 as
>>    you did both times.  Doing this aggravates the situation for
>>    #1 even more, because if a patch is not CC:'d to netdev it does
>>    not enter patchwork.  And if it doesn't go into patchwork, I'm
>>    not looking at it.
>
>I guess that is some unfortunate result of git send-email combined with
>
>get_maintainer.pl . In general I also prefer to see the whole series,
>but have 
>gotten such partial series from other maintainers as well in the past,
>so it 
>seems to be depending on preferences somewhat.

You could run get_maintainer.pl against the individual patches in the series, merge the cc list somewhere in a file/variable and then do the actual mail submission with that full list for all patches. There could be a way to automate that with a bit of help from git send-email eventually.

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

Re: [RESEND PATCH v1 0/4] Add support emac for the RK3036 SoC platform

[David Miller]

From: Heiko Stübner <heiko@sntech.de>
Date: Tue, 29 Dec 2015 23:27:55 +0100

> Hi Dave,
> 
> Am Dienstag, 29. Dezember 2015, 15:53:14 schrieb David Miller:
>> You have to submit this series properly, the same problem happend twice
>> now.
>> 
>> When you submit a series you should:
>> 
>> 1) Make it clear which tree you expect these changes to be applied
>>    to.  Here it is completely ambiguous, do you want it to go into
>>    my networking tree or some other subsystem tree?
>> 
>> 2) You MUST keep all parties informed about all patches for a series
>>    like this.  That means you cannot drop netdev from patch #4 as
>>    you did both times.  Doing this aggravates the situation for
>>    #1 even more, because if a patch is not CC:'d to netdev it does
>>    not enter patchwork.  And if it doesn't go into patchwork, I'm
>>    not looking at it.
> 
> I guess that is some unfortunate result of git send-email combined with 
> get_maintainer.pl . In general I also prefer to see the whole series, but have 
> gotten such partial series from other maintainers as well in the past, so it 
> seems to be depending on preferences somewhat.
> 
> For the series at hand, the 4th patch is the devicetree addition, which the 
> expected way is me picking it up, after you are comfortable with the code-
> related changes.

Why would it not be appropriate for a DT file change to go into my tree
if it corresponds to functionality created by the rest of the patches
in the series?

It looks better to put it all together as a unit, via one series, with
a merge commit containing your "[PATCH 0/N]" description in the commit
message.

Re: [RESEND PATCH v1 0/4] Add support emac for the RK3036 SoC platform

[Geert Uytterhoeven]

Hi David,

On Wed, Dec 30, 2015 at 2:48 AM, David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> wrote:
> From: Heiko Stübner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>
> Date: Tue, 29 Dec 2015 23:27:55 +0100
>> Am Dienstag, 29. Dezember 2015, 15:53:14 schrieb David Miller:
>>> You have to submit this series properly, the same problem happend twice
>>> now.
>>>
>>> When you submit a series you should:
>>>
>>> 1) Make it clear which tree you expect these changes to be applied
>>>    to.  Here it is completely ambiguous, do you want it to go into
>>>    my networking tree or some other subsystem tree?
>>>
>>> 2) You MUST keep all parties informed about all patches for a series
>>>    like this.  That means you cannot drop netdev from patch #4 as
>>>    you did both times.  Doing this aggravates the situation for
>>>    #1 even more, because if a patch is not CC:'d to netdev it does
>>>    not enter patchwork.  And if it doesn't go into patchwork, I'm
>>>    not looking at it.
>>
>> I guess that is some unfortunate result of git send-email combined with
>> get_maintainer.pl . In general I also prefer to see the whole series, but have
>> gotten such partial series from other maintainers as well in the past, so it
>> seems to be depending on preferences somewhat.
>>
>> For the series at hand, the 4th patch is the devicetree addition, which the
>> expected way is me picking it up, after you are comfortable with the code-
>> related changes.
>
> Why would it not be appropriate for a DT file change to go into my tree
> if it corresponds to functionality created by the rest of the patches
> in the series?

Because the DT change is very likely to conflict with other DT changes.
That's why typically all DT changes go in through the platform/architecture
maintainer.

> It looks better to put it all together as a unit, via one series, with
> a merge commit containing your "[PATCH 0/N]" description in the commit
> message.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
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

Re: [RESEND PATCH v1 0/4] Add support emac for the RK3036 SoC platform

[Rob Herring]

On Wed, Dec 30, 2015 at 4:17 AM, Geert Uytterhoeven
<geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org> wrote:
> Hi David,
>
> On Wed, Dec 30, 2015 at 2:48 AM, David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> wrote:
>> From: Heiko Stübner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>
>> Date: Tue, 29 Dec 2015 23:27:55 +0100
>>> Am Dienstag, 29. Dezember 2015, 15:53:14 schrieb David Miller:
>>>> You have to submit this series properly, the same problem happend twice
>>>> now.
>>>>
>>>> When you submit a series you should:
>>>>
>>>> 1) Make it clear which tree you expect these changes to be applied
>>>>    to.  Here it is completely ambiguous, do you want it to go into
>>>>    my networking tree or some other subsystem tree?
>>>>
>>>> 2) You MUST keep all parties informed about all patches for a series
>>>>    like this.  That means you cannot drop netdev from patch #4 as
>>>>    you did both times.  Doing this aggravates the situation for
>>>>    #1 even more, because if a patch is not CC:'d to netdev it does
>>>>    not enter patchwork.  And if it doesn't go into patchwork, I'm
>>>>    not looking at it.
>>>
>>> I guess that is some unfortunate result of git send-email combined with
>>> get_maintainer.pl . In general I also prefer to see the whole series, but have
>>> gotten such partial series from other maintainers as well in the past, so it
>>> seems to be depending on preferences somewhat.
>>>
>>> For the series at hand, the 4th patch is the devicetree addition, which the
>>> expected way is me picking it up, after you are comfortable with the code-
>>> related changes.
>>
>> Why would it not be appropriate for a DT file change to go into my tree
>> if it corresponds to functionality created by the rest of the patches
>> in the series?
>
> Because the DT change is very likely to conflict with other DT changes.
> That's why typically all DT changes go in through the platform/architecture
> maintainer.

I assume you mean DTS changes only here. Send the DTS changes as a
separate series/patch as there is not inter-dependency (if there is,
there is a problem with the change) with DTS changes. I expect the
sub-arch maintainers to be the main reviewers of DTS files anyway. If
there is a binding doc change, then I'd prefer that to be merged with
the driver.

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