Re: [PATCH v1 0/4] ARM: STi fixes and ethernet support
Hi Arnd, On 09/07/13 22:15, Arnd Bergmann wrote: >> For DT case, At the moment I think callbacks at MACH level is one >> > possible solution. But am open for any discussions. > Ok, so a PHY driver might not be the best place to put this, but it's > one option, since the PHY driver already has to know about the > interface speed you are setting. > > Having a global "*_setup_ethernet" callback is definitely not the > right way to go. Please describe what the function actually does > so we can come up with the right subsystem to move that functionality > to. If you are setting clocks, you should use the clock subsystem, > for taking the device out of reset, you should use the reset controller > subsystem and for setting up the phy, you should use the phy subsystem, > etc. The purpose of this callback is to do three things. 1> Configuring the MAC signals to select particular PHY interface mode. MAC signals(wires) are wired up to this Ethernet Configuration register. 2> Select synchronisation clock for data lines retiming. On High speed interfaces track length/layouts on the boards can directly influence the signal quality and introduce bit shifts or other errors. So SoC has additional logic to retime these signals and improve the data reliability. As there is possibility of multiple clock sources (MAC, PHY) a correct choice of synchronization clock is made in Ethernet configuration register. For 125 Mhz clock in Gbit mode, reference clock is provided by the PHY in other case like 100bit and 10bit, 50MHz, 25MHz clocks is provide by the MAC. So this bits depend/driven based on the PHYMODEs and Link Speed. 3> Ethernet Soft reset in Ethernet control register. Which can probably go into via reset controller driver. For point 1 and 2, there is no subsystem in the kernel which can accommodate these kind of SOC specific bits setup. Am not sure if other platforms have similar SoC setup use cases? For point 3, I can go for reset controller API. Just for your reference (Sorry and Please ignore if Its too detailed), Ethernet configuration register looks like: Bit to configure signals connected to MAC. [5] ENMII1: when 1, MII mode when 0, Reverse MII mode [4:2] MII1_PHY_SEL: 000: GMII/MII (default) 001: RGMII 010: SGMII 100: RMII Bit to configure retiming clock for retiming data lines: [8] ETH1_SEL_TX_RETIMING_CLK: Selection of the clock used to retime TX data 0: clock selected by ETH1_SEL_TXCLK_NOT_CLK125 bit 1: clock fed to or provided by MII_PHYCLK depending on eth1_sel_internal_notext_phyclk setting [7] ETH1_SEL_INTERNAL_NOTEXT_PHYCLK: Selection of internal clock or external clock from MII_PHYCLK for retiming in RMII mode 0: external clock (Beware that eth1_sel_tx_retiming_clk bit must also be programmed). 1: internal clock (from clockgenA) [6] ETH1_SEL_TXCLK_NOT_CLK125: Selection of the clock used to retime TX data 0: MII1_CLK_125 (beware that eth1_sel_tx_retiming_clk bit must also be programmed) 1: MII1_TXCLK Thanks, srini -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 0/4] ARM: STi fixes and ethernet support
Hi Arnd, On 09/07/13 22:15, Arnd Bergmann wrote: For DT case, At the moment I think callbacks at MACH level is one possible solution. But am open for any discussions. Ok, so a PHY driver might not be the best place to put this, but it's one option, since the PHY driver already has to know about the interface speed you are setting. Having a global *_setup_ethernet callback is definitely not the right way to go. Please describe what the function actually does so we can come up with the right subsystem to move that functionality to. If you are setting clocks, you should use the clock subsystem, for taking the device out of reset, you should use the reset controller subsystem and for setting up the phy, you should use the phy subsystem, etc. The purpose of this callback is to do three things. 1 Configuring the MAC signals to select particular PHY interface mode. MAC signals(wires) are wired up to this Ethernet Configuration register. 2 Select synchronisation clock for data lines retiming. On High speed interfaces track length/layouts on the boards can directly influence the signal quality and introduce bit shifts or other errors. So SoC has additional logic to retime these signals and improve the data reliability. As there is possibility of multiple clock sources (MAC, PHY) a correct choice of synchronization clock is made in Ethernet configuration register. For 125 Mhz clock in Gbit mode, reference clock is provided by the PHY in other case like 100bit and 10bit, 50MHz, 25MHz clocks is provide by the MAC. So this bits depend/driven based on the PHYMODEs and Link Speed. 3 Ethernet Soft reset in Ethernet control register. Which can probably go into via reset controller driver. For point 1 and 2, there is no subsystem in the kernel which can accommodate these kind of SOC specific bits setup. Am not sure if other platforms have similar SoC setup use cases? For point 3, I can go for reset controller API. Just for your reference (Sorry and Please ignore if Its too detailed), Ethernet configuration register looks like: Bit to configure signals connected to MAC. [5] ENMII1: when 1, MII mode when 0, Reverse MII mode [4:2] MII1_PHY_SEL: 000: GMII/MII (default) 001: RGMII 010: SGMII 100: RMII Bit to configure retiming clock for retiming data lines: [8] ETH1_SEL_TX_RETIMING_CLK: Selection of the clock used to retime TX data 0: clock selected by ETH1_SEL_TXCLK_NOT_CLK125 bit 1: clock fed to or provided by MII_PHYCLK depending on eth1_sel_internal_notext_phyclk setting [7] ETH1_SEL_INTERNAL_NOTEXT_PHYCLK: Selection of internal clock or external clock from MII_PHYCLK for retiming in RMII mode 0: external clock (Beware that eth1_sel_tx_retiming_clk bit must also be programmed). 1: internal clock (from clockgenA) [6] ETH1_SEL_TXCLK_NOT_CLK125: Selection of the clock used to retime TX data 0: MII1_CLK_125 (beware that eth1_sel_tx_retiming_clk bit must also be programmed) 1: MII1_TXCLK Thanks, srini -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 0/4] ARM: STi fixes and ethernet support
On Tuesday 09 July 2013, Srinivas KANDAGATLA wrote: > On 09/07/13 08:56, Arnd Bergmann wrote: > > No, you should be using generic interfaces to do the things you need. > > > > I believe what you are missing is an ethernet phy driver that is specific > > to your SoC. > It looks interesting way to solve the issue. > > Did you mean "Ethernet PHY"? > > Ethernet PHY is not integrated in the STiH41x SoC, We use an external > ICPLUS phy ( drivers/net/phy/icplus.c) for both B2000 and B2020 boards. > As we can't have two Ethernet phy drivers at the same time, I think the > suggestion might not work in this case. > > The callbacks in the mach level are setting up two SOC specific System > Configuration registers which configures the MAC (like PHY interface > selection, which is sampled during MAC reset assertion). Ah, right. > MAC used in STiH41x supports multiple PHY interfaces, so the PHY > interface selection is driven by external signals wired up to System > Configuration registers. The MAC driver is not aware of these System > Configuration registers. So for non-DT case, stmmac driver provided > callbacks to do things like this. > > For DT case, At the moment I think callbacks at MACH level is one > possible solution. But am open for any discussions. Ok, so a PHY driver might not be the best place to put this, but it's one option, since the PHY driver already has to know about the interface speed you are setting. Having a global "*_setup_ethernet" callback is definitely not the right way to go. Please describe what the function actually does so we can come up with the right subsystem to move that functionality to. If you are setting clocks, you should use the clock subsystem, for taking the device out of reset, you should use the reset controller subsystem and for setting up the phy, you should use the phy subsystem, etc. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 0/4] ARM: STi fixes and ethernet support
On 09/07/13 08:56, Arnd Bergmann wrote: > No, you should be using generic interfaces to do the things you need. > > I believe what you are missing is an ethernet phy driver that is specific > to your SoC. It looks interesting way to solve the issue. Did you mean "Ethernet PHY"? Ethernet PHY is not integrated in the STiH41x SoC, We use an external ICPLUS phy ( drivers/net/phy/icplus.c) for both B2000 and B2020 boards. As we can't have two Ethernet phy drivers at the same time, I think the suggestion might not work in this case. The callbacks in the mach level are setting up two SOC specific System Configuration registers which configures the MAC (like PHY interface selection, which is sampled during MAC reset assertion). MAC used in STiH41x supports multiple PHY interfaces, so the PHY interface selection is driven by external signals wired up to System Configuration registers. The MAC driver is not aware of these System Configuration registers. So for non-DT case, stmmac driver provided callbacks to do things like this. For DT case, At the moment I think callbacks at MACH level is one possible solution. But am open for any discussions. Thanks, srini > > Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 0/4] ARM: STi fixes and ethernet support
On Tuesday 09 July 2013, Srinivas KANDAGATLA wrote: > stmmac (aka "dwmac" a synopsis IP) driver is integrated in to kernel > sometime in 2.6 series I think :-), and Is used by more than 4 platforms > in 3.10 kernel. The driver is more generic than it sounds. > So adding properties/hooks specific to STiH41x SOCs in driver seemed to > incorrect. Instead doing platform specific bits in the mach via > callbacks was the only choice I had. No, you should be using generic interfaces to do the things you need. I believe what you are missing is an ethernet phy driver that is specific to your SoC. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 0/4] ARM: STi fixes and ethernet support
Thanks Arnd, On 09/07/13 00:18, Arnd Bergmann wrote: > On Monday 08 July 2013, Srinivas KANDAGATLA wrote: >> From: Srinivas Kandagatla >> >> This patch series fixes 2 configuration issues and adds ethernet support to >> STiH415, STiH416 based B2000, B2020 boards. > > Hi Srini, > > You really have to send those things separately, as the bug fixes should > probably go into 3.11, while the rest is new features and needs to be > reviewed for merging into 3.12. Yes, I will resend the fixes separately. > > I'm also puzzled by the fact that you add auxdata and callback > functions for the ether part in the platform code. Those should > probably all be properties added to the stmmac binding. stmmac (aka "dwmac" a synopsis IP) driver is integrated in to kernel sometime in 2.6 series I think :-), and Is used by more than 4 platforms in 3.10 kernel. The driver is more generic than it sounds. So adding properties/hooks specific to STiH41x SOCs in driver seemed to incorrect. Instead doing platform specific bits in the mach via callbacks was the only choice I had. Thanks, srini > > Arnd > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 0/4] ARM: STi fixes and ethernet support
On Tuesday 09 July 2013, Srinivas KANDAGATLA wrote: On 09/07/13 08:56, Arnd Bergmann wrote: No, you should be using generic interfaces to do the things you need. I believe what you are missing is an ethernet phy driver that is specific to your SoC. It looks interesting way to solve the issue. Did you mean Ethernet PHY? Ethernet PHY is not integrated in the STiH41x SoC, We use an external ICPLUS phy ( drivers/net/phy/icplus.c) for both B2000 and B2020 boards. As we can't have two Ethernet phy drivers at the same time, I think the suggestion might not work in this case. The callbacks in the mach level are setting up two SOC specific System Configuration registers which configures the MAC (like PHY interface selection, which is sampled during MAC reset assertion). Ah, right. MAC used in STiH41x supports multiple PHY interfaces, so the PHY interface selection is driven by external signals wired up to System Configuration registers. The MAC driver is not aware of these System Configuration registers. So for non-DT case, stmmac driver provided callbacks to do things like this. For DT case, At the moment I think callbacks at MACH level is one possible solution. But am open for any discussions. Ok, so a PHY driver might not be the best place to put this, but it's one option, since the PHY driver already has to know about the interface speed you are setting. Having a global *_setup_ethernet callback is definitely not the right way to go. Please describe what the function actually does so we can come up with the right subsystem to move that functionality to. If you are setting clocks, you should use the clock subsystem, for taking the device out of reset, you should use the reset controller subsystem and for setting up the phy, you should use the phy subsystem, etc. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 0/4] ARM: STi fixes and ethernet support
Thanks Arnd, On 09/07/13 00:18, Arnd Bergmann wrote: On Monday 08 July 2013, Srinivas KANDAGATLA wrote: From: Srinivas Kandagatla srinivas.kandaga...@st.com This patch series fixes 2 configuration issues and adds ethernet support to STiH415, STiH416 based B2000, B2020 boards. Hi Srini, You really have to send those things separately, as the bug fixes should probably go into 3.11, while the rest is new features and needs to be reviewed for merging into 3.12. Yes, I will resend the fixes separately. I'm also puzzled by the fact that you add auxdata and callback functions for the ether part in the platform code. Those should probably all be properties added to the stmmac binding. stmmac (aka dwmac a synopsis IP) driver is integrated in to kernel sometime in 2.6 series I think :-), and Is used by more than 4 platforms in 3.10 kernel. The driver is more generic than it sounds. So adding properties/hooks specific to STiH41x SOCs in driver seemed to incorrect. Instead doing platform specific bits in the mach via callbacks was the only choice I had. Thanks, srini Arnd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 0/4] ARM: STi fixes and ethernet support
On Tuesday 09 July 2013, Srinivas KANDAGATLA wrote: stmmac (aka dwmac a synopsis IP) driver is integrated in to kernel sometime in 2.6 series I think :-), and Is used by more than 4 platforms in 3.10 kernel. The driver is more generic than it sounds. So adding properties/hooks specific to STiH41x SOCs in driver seemed to incorrect. Instead doing platform specific bits in the mach via callbacks was the only choice I had. No, you should be using generic interfaces to do the things you need. I believe what you are missing is an ethernet phy driver that is specific to your SoC. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 0/4] ARM: STi fixes and ethernet support
On 09/07/13 08:56, Arnd Bergmann wrote: No, you should be using generic interfaces to do the things you need. I believe what you are missing is an ethernet phy driver that is specific to your SoC. It looks interesting way to solve the issue. Did you mean Ethernet PHY? Ethernet PHY is not integrated in the STiH41x SoC, We use an external ICPLUS phy ( drivers/net/phy/icplus.c) for both B2000 and B2020 boards. As we can't have two Ethernet phy drivers at the same time, I think the suggestion might not work in this case. The callbacks in the mach level are setting up two SOC specific System Configuration registers which configures the MAC (like PHY interface selection, which is sampled during MAC reset assertion). MAC used in STiH41x supports multiple PHY interfaces, so the PHY interface selection is driven by external signals wired up to System Configuration registers. The MAC driver is not aware of these System Configuration registers. So for non-DT case, stmmac driver provided callbacks to do things like this. For DT case, At the moment I think callbacks at MACH level is one possible solution. But am open for any discussions. Thanks, srini Arnd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 0/4] ARM: STi fixes and ethernet support
On Monday 08 July 2013, Srinivas KANDAGATLA wrote: > From: Srinivas Kandagatla > > This patch series fixes 2 configuration issues and adds ethernet support to > STiH415, STiH416 based B2000, B2020 boards. > With this patchset B2000 and B2020 can have basic ethernet support in > MII and RGMII modes. > > Thanks, > srini > > Srinivas Kandagatla (4): > ARM: dts: STi: Fix pinconf setup for STiH416 serial2 > ARM: STi: Set correct ARM ERRATAs. > ARM: STi: Add STiH415 ethernet support. > ARM: STi: Add STiH416 ethernet support. Hi Srini, You really have to send those things separately, as the bug fixes should probably go into 3.11, while the rest is new features and needs to be reviewed for merging into 3.12. I'm also puzzled by the fact that you add auxdata and callback functions for the ether part in the platform code. Those should probably all be properties added to the stmmac binding. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 0/4] ARM: STi fixes and ethernet support
On Monday 08 July 2013, Srinivas KANDAGATLA wrote: From: Srinivas Kandagatla srinivas.kandaga...@st.com This patch series fixes 2 configuration issues and adds ethernet support to STiH415, STiH416 based B2000, B2020 boards. With this patchset B2000 and B2020 can have basic ethernet support in MII and RGMII modes. Thanks, srini Srinivas Kandagatla (4): ARM: dts: STi: Fix pinconf setup for STiH416 serial2 ARM: STi: Set correct ARM ERRATAs. ARM: STi: Add STiH415 ethernet support. ARM: STi: Add STiH416 ethernet support. Hi Srini, You really have to send those things separately, as the bug fixes should probably go into 3.11, while the rest is new features and needs to be reviewed for merging into 3.12. I'm also puzzled by the fact that you add auxdata and callback functions for the ether part in the platform code. Those should probably all be properties added to the stmmac binding. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
