| Message ID | 20240124213640.7582-1-ansuelsmth@gmail.com |
|---|---|
| Headers | show |
| Series | net: mdio-ipq4019: fix wrong default MDC rate | expand |
On Thu, Jan 25, 2024 at 01:57:20PM +0800, Jie Luo wrote: > > > On 1/25/2024 5:36 AM, Christian Marangi wrote: > > This was a long journey to arrive and discover this problem. > > > > To not waste too much char, there is a race problem with PHY and driver > > probe. This was observed with Aquantia PHY firmware loading. > > > > With some hacks the race problem was workarounded but an interesting > > thing was notice. It took more than a minute for the firmware to load > > via MDIO. > > > > This was strange as the same operation was done by UBoot in at max 5 > > second and the same data was loaded. > > > > A similar problem was observed on a mtk board that also had an > > Aquantia PHY where the load was very slow. It was notice that the cause > > was the MDIO bus running at a very low speed and the firmware > > was missing a property (present in mtk sdk) that set the right frequency > > to the MDIO bus. > > > > It was fun to find that THE VERY SAME PROBLEM is present on IPQ in a > > different form. The MDIO apply internally a division to the feed clock > > resulting in the bus running at 390KHz instead of 6.25Mhz. > > > > Searching around the web for some documentation and some include and > > analyzing the uboot codeflow resulted in the divider being set wrongly > > at /256 instead of /16 as the value was actually never set. > > Applying the value restore the original load time for the Aquantia PHY. > > > > This series mainly handle this by adding support for the "clock-frequency" > > property. > > > > Christian Marangi (3): > > dt-bindings: net: ipq4019-mdio: document now supported clock-frequency > > net: mdio: ipq4019: add support for clock-frequency property > > arm64: dts: qcom: ipq8074: add clock-frequency to MDIO node > > > > .../bindings/net/qcom,ipq4019-mdio.yaml | 10 +++ > > arch/arm64/boot/dts/qcom/ipq8074.dtsi | 2 + > > drivers/net/mdio/mdio-ipq4019.c | 68 +++++++++++++++++-- > > 3 files changed, 75 insertions(+), 5 deletions(-) > > > > Hi Christian, > Just a gentle reminder. > Hi Jie, hope you can understand my reason. > The MDIO frequency config is already added by the following patch series. > https://lore.kernel.org/netdev/28c8b31c-8dcb-4a19-9084-22c77a74b9a1@linaro.org/T/#m840cb8d269dca133c3ad3da3d112c63382ec2058 > Wasn't aware of this, as I said in the cover letter this all comes by a problem we notice in the Aquantia firmware load that was slow as hell and we just notice the misconfiguration of the divisor. The feature in this series is really a simple one and almost ready (I already have v2 ready for the request from Andrew to follow 802.3 spec) and we really need it ASAP as we are trying to move our ipq807x targets to upstream driver and finally start using the integrated firmware loading for Aquantia PHY. Also I can see some fundamental difference between the 2 patch, mainly in how the value is applied and setting a sane divisor by default instead of using 0xff. (probably Andrew would have pointed out the same thing in some later revision to your series) Looking at the linked series I notice there are still some thing to polish and to clarify with DT and driver and I think it's only beneficial if this feature is worked separately as it's not only needed for ipq50xx but affects every user of this (ipq40xx, ipq807x, ipq60xx) and it would be a pitty to wait the entire ipq50xx series to be handled just to fix a long lasting misconfiguration on various SoC family. Hope you can understand these reasons, it's all for the sake of making this driver more mature quicker. > This MDIO patch series will be updated to just keep the MDIO frequency > patch and DT document for this MDIO frequency property added. > > For CMN PLL config will be moved to the CMN PLL clock driver and the UNIPHY > clock config will be moved the uniphy driver as suggested by > Sergey's suggestions. > > Thanks. > >
On 1/26/2024 1:18 AM, Andrew Lunn wrote: >> Hi Christian, >> Just a gentle reminder. >> >> The MDIO frequency config is already added by the following patch series. >> https://lore.kernel.org/netdev/28c8b31c-8dcb-4a19-9084-22c77a74b9a1@linaro.org/T/#m840cb8d269dca133c3ad3da3d112c63382ec2058 > > I admit this version was posted first. However, its embedded in a > patch series which is not making much progress, and i doubt will make > progress any time soon. > > If you really want your version to be used, please split it out into a > standalone patch series adding just MDIO clock-frequency support, with > its binding, and nothing else. > > Andrew Hi Andrew, We will rework the patch series to include only MDIO frequency related function and frequency dt binding, and post the updated patch series on the Monday/Tuesday of next week. We will work with Christian to ensure he can re-use this patch as well. Thanks
On Fri, 26 Jan 2024 at 18:03, Jie Luo <quic_luoj@quicinc.com> wrote: > > > > On 1/26/2024 1:18 AM, Andrew Lunn wrote: > >> Hi Christian, > >> Just a gentle reminder. > >> > >> The MDIO frequency config is already added by the following patch series. > >> https://lore.kernel.org/netdev/28c8b31c-8dcb-4a19-9084-22c77a74b9a1@linaro.org/T/#m840cb8d269dca133c3ad3da3d112c63382ec2058 > > > > I admit this version was posted first. However, its embedded in a > > patch series which is not making much progress, and i doubt will make > > progress any time soon. > > > > If you really want your version to be used, please split it out into a > > standalone patch series adding just MDIO clock-frequency support, with > > its binding, and nothing else. > > > > Andrew > > Hi Andrew, > We will rework the patch series to include only MDIO frequency related > function and frequency dt binding, and post the updated patch series > on the Monday/Tuesday of next week. We will work with Christian to > ensure he can re-use this patch as well. Can you do the other way around: rebase your patches on top of Chritian's work?
On Fri, Jan 26, 2024 at 07:20:03PM +0200, Dmitry Baryshkov wrote: > On Fri, 26 Jan 2024 at 18:03, Jie Luo <quic_luoj@quicinc.com> wrote: > > > > > > > > On 1/26/2024 1:18 AM, Andrew Lunn wrote: > > >> Hi Christian, > > >> Just a gentle reminder. > > >> > > >> The MDIO frequency config is already added by the following patch series. > > >> https://lore.kernel.org/netdev/28c8b31c-8dcb-4a19-9084-22c77a74b9a1@linaro.org/T/#m840cb8d269dca133c3ad3da3d112c63382ec2058 > > > > > > I admit this version was posted first. However, its embedded in a > > > patch series which is not making much progress, and i doubt will make > > > progress any time soon. > > > > > > If you really want your version to be used, please split it out into a > > > standalone patch series adding just MDIO clock-frequency support, with > > > its binding, and nothing else. > > > > > > Andrew > > > > Hi Andrew, > > We will rework the patch series to include only MDIO frequency related > > function and frequency dt binding, and post the updated patch series > > on the Monday/Tuesday of next week. We will work with Christian to > > ensure he can re-use this patch as well. > > Can you do the other way around: rebase your patches on top of Chritian's work? > Would be ideal, also I have to send v2 that handle the 802.3 suggested MDC rate (ready I just need to send after this has been handled). Also I can see some problem with Lui patch where the divisor value is not reapplied after MDIO reset effectively reverting to the default value. If it's a credits problem I can totally change the from or add Co-devloped, I just need the feature since the thing is broken from a looong time on ipq40xx and ipq807x.
On 1/27/2024 1:33 AM, Christian Marangi wrote: > On Fri, Jan 26, 2024 at 07:20:03PM +0200, Dmitry Baryshkov wrote: >> On Fri, 26 Jan 2024 at 18:03, Jie Luo <quic_luoj@quicinc.com> wrote: >>> >>> >>> >>> On 1/26/2024 1:18 AM, Andrew Lunn wrote: >>>>> Hi Christian, >>>>> Just a gentle reminder. >>>>> >>>>> The MDIO frequency config is already added by the following patch series. >>>>> https://lore.kernel.org/netdev/28c8b31c-8dcb-4a19-9084-22c77a74b9a1@linaro.org/T/#m840cb8d269dca133c3ad3da3d112c63382ec2058 >>>> >>>> I admit this version was posted first. However, its embedded in a >>>> patch series which is not making much progress, and i doubt will make >>>> progress any time soon. >>>> >>>> If you really want your version to be used, please split it out into a >>>> standalone patch series adding just MDIO clock-frequency support, with >>>> its binding, and nothing else. >>>> >>>> Andrew >>> >>> Hi Andrew, >>> We will rework the patch series to include only MDIO frequency related >>> function and frequency dt binding, and post the updated patch series >>> on th/Tuesdae Mondayy of next week. We will work with Christian to >>> ensure he can re-use this patch as well. >> >> Can you do the other way around: rebase your patches on top of Chritian's work? Hi Dmitry, Sure, we can take this approach if fine by Andrew as well. >> > > Would be ideal, also I have to send v2 that handle the 802.3 suggested > MDC rate (ready I just need to send after this has been handled). > > Also I can see some problem with Lui patch where thse divior > value is not reapplied after MDIO reset effectively reverting to the > default value. Hi Christian, In my version, the divisor is programmed in every MDIO operation and hence I did not add the code to revert to configured value in reset function. But sure. we can program it once during the probe/reset and avoid doing it during read/write ops. In addition, the MDIO divisor 1, 2 and 4 are not supported by the MDIO hardware block, maybe we can remove these macros to avoid confusion, or add a comment mentioning that these are not supported. > > If it's a credits problem I can totally change the from or add > Co-devloped, I just need the feature since the thing is broken from a > looong time on ipq40xx and ipq807x. >
On Mon, Jan 29, 2024 at 09:59:03PM +0800, Jie Luo wrote: > > > On 1/27/2024 1:33 AM, Christian Marangi wrote: > > On Fri, Jan 26, 2024 at 07:20:03PM +0200, Dmitry Baryshkov wrote: > > > On Fri, 26 Jan 2024 at 18:03, Jie Luo <quic_luoj@quicinc.com> wrote: > > > > > > > > > > > > > > > > On 1/26/2024 1:18 AM, Andrew Lunn wrote: > > > > > > Hi Christian, > > > > > > Just a gentle reminder. > > > > > > > > > > > > The MDIO frequency config is already added by the following patch series. > > > > > > https://lore.kernel.org/netdev/28c8b31c-8dcb-4a19-9084-22c77a74b9a1@linaro.org/T/#m840cb8d269dca133c3ad3da3d112c63382ec2058 > > > > > > > > > > I admit this version was posted first. However, its embedded in a > > > > > patch series which is not making much progress, and i doubt will make > > > > > progress any time soon. > > > > > > > > > > If you really want your version to be used, please split it out into a > > > > > standalone patch series adding just MDIO clock-frequency support, with > > > > > its binding, and nothing else. > > > > > > > > > > Andrew > > > > > > > > Hi Andrew, > > > > We will rework the patch series to include only MDIO frequency related > > > > function and frequency dt binding, and post the updated patch series > > > > on th/Tuesdae Mondayy of next week. We will work with Christian to > > > > ensure he can re-use this patch as well. > > > > > > Can you do the other way around: rebase your patches on top of Chritian's work? > > Hi Dmitry, > Sure, we can take this approach if fine by Andrew as well. > > > > > > > > Would be ideal, also I have to send v2 that handle the 802.3 suggested > > MDC rate (ready I just need to send after this has been handled). > > > > Also I can see some problem with Lui patch where thse divior > > value is not reapplied after MDIO reset effectively reverting to the > > default value. > > Hi Christian, > In my version, the divisor is programmed in every MDIO operation and hence I > did not add the code to revert to configured value in reset function. But > sure. we can program it once during the probe/reset and avoid doing it > during read/write ops. > > In addition, the MDIO divisor 1, 2 and 4 are not supported by the MDIO > hardware block, maybe we can remove these macros to avoid confusion, or add > a comment mentioning that these are not supported. > Hi, thanks for confirming it! In v2 I already changed the logic to start looping from divisor 8 and added comments in DT and driver about not assuring correct funcionality with those divisor. > > > > If it's a credits problem I can totally change the from or add > > Co-devloped, I just need the feature since the thing is broken from a > > looong time on ipq40xx and ipq807x. > >