| Message ID | 201305170141.59791.sergei.shtylyov@cogentembedded.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Fri, May 17, 2013 at 01:41:59AM +0400, Sergei Shtylyov wrote: > 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 <sergei.shtylyov@cogentembedded.com> > > --- > 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.
Hello. On 25-05-2013 9:30, Simon Horman wrote: >> 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 <sergei.shtylyov@cogentembedded.com> >> >> --- >> 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). > 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
On Sat, May 25, 2013 at 10:08:35PM +0400, Sergei Shtylyov wrote: > Hello. > > On 25-05-2013 9:30, Simon Horman wrote: > > >>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 <sergei.shtylyov@cogentembedded.com> > >> > >>--- > >>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). 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. > >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 >
Hello. On 05/26/2013 03:22 AM, Simon Horman wrote: >>>> 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 <sergei.shtylyov@cogentembedded.com> >>>> >>>> --- >>>> 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). > 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
On Sun, May 26, 2013 at 03:40:17AM +0400, Sergei Shtylyov wrote: > Hello. > > On 05/26/2013 03:22 AM, Simon Horman wrote: > > >>>>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 <sergei.shtylyov@cogentembedded.com> > >>>> > >>>>--- > >>>>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). > >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.
Index: renesas/arch/arm/mach-shmobile/board-bockw.c =================================================================== --- renesas.orig/arch/arm/mach-shmobile/board-bockw.c +++ renesas/arch/arm/mach-shmobile/board-bockw.c @@ -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));
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 <sergei.shtylyov@cogentembedded.com> --- 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(-)