ARM: shmobile: BOCK-W: add Ether support
PATCH v2 1/1 ARM: shmobile: BOCK-W: add Ether support
Register Ether device from bockw_init(), passing the platform data to it, adding only the RMII pin group to bockw_pinctrl_map[]. Although the LINK signal exists on the board, it's connected to the link/activity LED output of the PHY, thus the link disappears and reappears after each packet. We'd be better off ignoring such signal and getting the link state from the PHY indirectly.
Also, Ether has pin conflict with VIN1, so the latter is not registered when the 'sh_eth' driver is enabled now.
---
The patch is atop of Simon's 'renesas.git' repo, 'renesas-next-20130515v2' tag and my recent yet unapplied patches.
Note that it's compile and run time dependent on the current Linus' tree.
Changes from the original posting:
- refreshed the patch.
arch/arm/mach-shmobile/board-bockw.c | 22 +++++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-)
arch/arm/mach-shmobile/board-bockw.c +21 -1
@@ -67,6 +67,20 @@ static struct sh_mobile_sdhi_info sdhi0_static struct rcar_phy_platform_data usb_phy_platform_data__initdata ; +static struct sh_eth_plat_data ether_platform_data__initdata = { + .phy =0x01 , + .edmac_endian =EDMAC_LITTLE_ENDIAN , + .register_type =SH_ETH_REG_FAST_RCAR , + .phy_interface =PHY_INTERFACE_MODE_RMII , +/* +* Although the LINK signal is available on the board, it's connected to +* the link/activity LED output of the PHY, thus the link disappears and +* reappears after each packet. We'd be better off ignoring such signal +* and getting the link state from the PHY indirectly. +*/ + .no_ether_link =1 , +}; +static struct rcar_vin_platform_data vin_platform_data__initdata = { .flags =RCAR_VIN_BT656 , };
@@ -87,6 +101,9 @@ BOCKW_CAMERA(0);BOCKW_CAMERA (1 );static const struct pinctrl_map bockw_pinctrl_map[] = { +/* Ether */ +PIN_MAP_MUX_GROUP_DEFAULT ("sh-eth" ,"pfc-r8a7778" , +"ether_rmii" ,"ether" ),/* SCIF0 */ PIN_MAP_MUX_GROUP_DEFAULT ("sh-sci.0" ,"pfc-r8a7778" ,"scif0_data_a" ,"scif0" ),
@@ -129,8 +146,11 @@ static void __init bockw_init(void)r8a7778_init_irq_extpin (1 );r8a7778_add_standard_devices ();r8a7778_add_usb_phy_device (&usb_phy_platform_data); +r8a7778_add_ether_device (ðer_platform_data);r8a7778_add_vin_device (0 , &vin_platform_data); -r8a7778_add_vin_device (1 , &vin_platform_data); +/* VIN1 has a pin conflict with Ether */ +if (!IS_ENABLED (CONFIG_SH_ETH )) +r8a7778_add_vin_device (1 , &vin_platform_data);platform_device_register_data (&platform_bus,"soc-camera-pdrv" ,0 , &iclink0_ml86v7667,sizeof (iclink0_ml86v7667));
PATCH v2 1/1 ARM: shmobile: BOCK-W: add Ether support
Quoted 11 lines · Sergei Shtylyov
Register Ether device from
bockw_init(), passing the platform data to it, adding only the RMII pin group to bockw_pinctrl_map[]. Although the LINK signal exists on the board, it's connected to the link/activity LED output of the PHY, thus the link disappears and reappears after each packet. We'd be better off ignoring such signal and getting the link state from the PHY indirectly.Also, Ether has pin conflict with VIN1, so the latter is not registered when the '
sh_eth' driver is enabled now.Signed-off-by Sergei Shtylyov <[email protected]>
Quoted 8 lines
---
The patch is atop of Simon's 'renesas.git' repo, 'renesas-next-20130515v2' tag and my recent yet unapplied patches.Note that it's compile and run time dependent on the current Linus' tree.
Changes from the original posting:
- refreshed the patch.
Thanks, would it be possible for you to rebase it on top of renesas-next-20130523.
renesas-next-20130523 is based on v3.10-rc2, so I think it should have whatever dependencies that were in Linus's tree at the time that you posted this patch.
PATCH v2 1/1 ARM: shmobile: BOCK-W: add Ether support
Hello.
Quoted 15 lines · Simon Horman
Quoted 14 lines
Register Ether device from
bockw_init(), passing the platform data to it, adding only the RMII pin group to bockw_pinctrl_map[]. Although the LINK signal exists on the board, it's connected to the link/activity LED output of the PHY, thus the link disappears and reappears after each packet. We'd be better off ignoring such signal and getting the link state from the PHY indirectly.Also, Ether has pin conflict with VIN1, so the latter is not registered when the '
sh_eth' driver is enabled now.Signed-off-by Sergei Shtylyov <[email protected]>---
The patch is atop of Simon's 'renesas.git' repo, 'renesas-next-20130515v2' tag and my recent yet unapplied patches.
Quoted 7 lines
Quoted 4 lines
Note that it's compile and run time dependent on the current Linus' tree.
Changes from the original posting:
- refreshed the patch.Thanks, would it be possible for you to rebase it on top of renesas-next-20130523.
You mean to base it on this tag without any intervening patches (it
is now on top of my patch series)? Anyway, I'll rebase my whole series on this tag as I have time (I'm now working with the SATA driver to try to add to it NCQ support and fixing errors I encounter on the way).
Quoted 3 lines
renesas-next-20130523 is based on v3.10-rc2, so I think it should have whatever dependencies that were in Linus's tree at the time that you posted this patch.
Yes, correct.
WBR, Sergei
PATCH v2 1/1 ARM: shmobile: BOCK-W: add Ether support
Quoted 24 lines · Sergei Shtylyov
Hello.
Quoted 19 lines · Simon Horman
Quoted 19 lines
Register Ether device from
bockw_init(), passing the platform data to it, adding only the RMII pin group to bockw_pinctrl_map[]. Although the LINK signal exists on the board, it's connected to the link/activity LED output of the PHY, thus the link disappears and reappears after each packet. We'd be better off ignoring such signal and getting the link state from the PHY indirectly.Also, Ether has pin conflict with VIN1, so the latter is not registered when the '
sh_eth' driver is enabled now.Signed-off-by Sergei Shtylyov <[email protected]>---
The patch is atop of Simon's 'renesas.git' repo, 'renesas-next-20130515v2' tag and my recent yet unapplied patches.Note that it's compile and run time dependent on the current Linus' tree.
Changes from the original posting:
- refreshed the patch.
Quoted 8 lines
Quoted 2 lines
Thanks, would it be possible for you to rebase it on top of renesas-next-20130523.
You mean to base it on this tag without any intervening patches
(it is now on top of my patch series)? Anyway, I'll rebase my whole series on this tag as I have time (I'm now working with the SATA driver to try to add to it NCQ support and fixing errors I encounter on the way).
In general I would prefer for you to post patches that are based on my tree without any intervening patches as it makes it significantly easier for me to apply them.
Quoted 8 lines
Quoted 3 lines
renesas-next-20130523 is based on v3.10-rc2, so I think it should have whatever dependencies that were in Linus's tree at the time that you posted this patch.
Yes, correct.
WBR, Sergei
PATCH v2 1/1 ARM: shmobile: BOCK-W: add Ether support
Hello.
Quoted 17 lines · Simon Horman
Quoted 17 lines
Quoted 17 lines
Quoted 7 lines
Register Ether device from
bockw_init(), passing the platform data to it, adding only the RMII pin group to bockw_pinctrl_map[]. Although the LINK signal exists on the board, it's connected to the link/activity LED output of the PHY, thus the link disappears and reappears after each packet. We'd be better off ignoring such signal and getting the link state from the PHY indirectly. Also, Ether has pin conflict with VIN1, so the latter is not registered when the 'sh_eth' driver is enabled now.Quoted 8 lines
Signed-off-by Sergei Shtylyov <[email protected]>---
The patch is atop of Simon's 'renesas.git' repo, 'renesas-next-20130515v2' tag and my recent yet unapplied patches.
Note that it's compile and run time dependent on the current Linus' tree. Changes from the original posting:
- refreshed the patch.Thanks, would it be possible for you to rebase it on top of renesas-next-20130523.
Quoted 8 lines
Quoted 5 lines
You mean to base it on this tag without any intervening patches
(it is now on top of my patch series)? Anyway, I'll rebase my whole series on this tag as I have time (I'm now working with the SATA driver to try to add to it NCQ support and fixing errors I encounter on the way).In general I would prefer for you to post patches that are based on my tree without any intervening patches as it makes it significantly easier for me to apply them.
It's just that I've accumulated a significant queue of patches pending
merge to you tree. I'll reshuffle the series, if you consider this patch more urgent than USB/VIN stuff.
WBR, Sergei
PATCH v2 1/1 ARM: shmobile: BOCK-W: add Ether support
Quoted 26 lines · Sergei Shtylyov
Hello.
Quoted 22 lines · Simon Horman
Quoted 22 lines
Quoted 9 lines
Quoted 9 lines
Register Ether device from
bockw_init(), passing the platform data to it, adding only the RMII pin group to bockw_pinctrl_map[]. Although the LINK signal exists on the board, it's connected to the link/activity LED output of the PHY, thus the link disappears and reappears after each packet. We'd be better off ignoring such signal and getting the link state from the PHY indirectly. Also, Ether has pin conflict with VIN1, so the latter is not registered when the 'sh_eth' driver is enabled now.Signed-off-by Sergei Shtylyov <[email protected]>Quoted 8 lines
Quoted 6 lines
---
The patch is atop of Simon's 'renesas.git' repo, 'renesas-next-20130515v2' tag and my recent yet unapplied patches.
Note that it's compile and run time dependent on the current Linus' tree. Changes from the original posting:
- refreshed the patch.Thanks, would it be possible for you to rebase it on top of renesas-next-20130523.
You mean to base it on this tag without any intervening patches
(it is now on top of my patch series)? Anyway, I'll rebase my whole series on this tag as I have time (I'm now working with the SATA driver to try to add to it NCQ support and fixing errors I encounter on the way).
Quoted 7 lines
Quoted 3 lines
In general I would prefer for you to post patches that are based on my tree without any intervening patches as it makes it significantly easier for me to apply them.
It's just that I've accumulated a significant queue of patches pending
merge to you tree. I'll reshuffle the series, if you consider this patch more urgent than USB/VIN stuff.
I'm happy for you to set the priorities for your patches as you see fit.