On 11/28/23 18:09, Emil Renner Berthing wrote:
> Cristian Ciocaltea wrote:
>> On 11/28/23 14:08, Emil Renner Berthing wrote:
>>> Cristian Ciocaltea wrote:
>>>> On 11/26/23 23:10, Emil Renner Berthing wrote:
>>>>> Cristian Ciocaltea wrote:
>>>>>> The BeagleV Starlight SBC uses a Microchip KSZ9031RNXCA PHY supporting
>>>>>> RGMII-ID.
>>>>>>
>>>>>> TODO: Verify if manual adjustment of the RX internal delay is needed. If
>>>>>> yes, add the mdio & phy sub-nodes.
>>>>>
>>>>> Sorry for being late here. I've tested that removing the mdio and phy nodes on
>>>>> the the Starlight board works fine, but the rx-internal-delay-ps = <900>
>>>>> property not needed on any of my VisionFive V1 boards either.
>>>>
>>>> No problem, thanks a lot for taking the time to help with the testing!
>>>>
>>>>> So I wonder why you need that on your board
>>>>
>>>> I noticed you have a patch 70ca054e82b5 ("net: phy: motorcomm: Disable
>>>> rgmii rx delay") in your tree, hence I you please confirm the tests were
>>>> done with that commit reverted?
>>>>
>>>>> Also in the driver patch you add support for phy-mode = "rgmii-txid", but here
>>>>> you still set it to "rgmii-id", so which is it?
>>>>
>>>> Please try with "rgmii-id" first. I added "rgmii-txid" to have a
>>>> fallback solution in case the former cannot be used.
>>>
>>> Ah, I see. Sorry I should have read up on the whole thread. Yes, the Starlight
>>> board with the Microchip phy works with "rgmii-id" as is. And you're right,
>>> with "rgmii-id" my VF1 needs the rx-internal-delay-ps = <900> property too.
>>
>> That's great, we have now a pretty clear indication that this uncommon behavior
>> stems from the Motorcomm PHY, and *not* from GMAC.
>>
>>>>
>>>>> You've alse removed the phy reset gpio on the Starlight board:
>>>>>
>>>>> snps,reset-gpios = <&gpio 63 GPIO_ACTIVE_LOW>
>>>>>
>>>>> Why?
>>>>
>>>> I missed this in v1 as the gmac handling was done exclusively in
>>>> jh7100-common. Thanks for noticing!
>>>>
>>>>>>
>>>>>> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@xxxxxxxxxxxxx>
>>>>>> ---
>>>>>> arch/riscv/boot/dts/starfive/jh7100-beaglev-starlight.dts | 5 +++++
>>>>>> 1 file changed, 5 insertions(+)
>>>>>>
>>>>>> diff --git a/arch/riscv/boot/dts/starfive/jh7100-beaglev-starlight.dts b/arch/riscv/boot/dts/starfive/jh7100-beaglev-starlight.dts
>>>>>> index 7cda3a89020a..d3f4c99d98da 100644
>>>>>> --- a/arch/riscv/boot/dts/starfive/jh7100-beaglev-starlight.dts
>>>>>> +++ b/arch/riscv/boot/dts/starfive/jh7100-beaglev-starlight.dts
>>>>>> @@ -11,3 +11,8 @@ / {
>>>>>> model = "BeagleV Starlight Beta";
>>>>>> compatible = "beagle,beaglev-starlight-jh7100-r0", "starfive,jh7100";
>>>>>> };
>>>>>> +
>>>>>> +&gmac {
>>>>>> + phy-mode = "rgmii-id";
>>>>>> + status = "okay";
>>>>>> +};
>>>>>
>>>>> Lastly the phy-mode and status are the same for the VF1 and Starlight boards,
>>>>> so why can't these be set in the jh7100-common.dtsi?
>>>>
>>>> I wasn't sure "rgmii-id" can be used for both boards and I didn't want
>>>> to unconditionally enable gmac on Starlight before getting a
>>>> confirmation that this actually works.
>>>>
>>>> If there is no way to make it working with "rgmii-id" (w/ or w/o
>>>> adjusting rx-internal-delay-ps), than we should switch to "rgmii-txid".
>>>
>>> Yeah, I don't exactly know the difference, but both boards seem to work fine
>>> with "rgmii-id", so if that is somehow better and/or more correct let's just go
>>> with that.
>>
>> As Andrew already pointed out, going with "rgmii-id" would be the recommended
>> approach, as this passes the responsibility of adding both TX and RX delays to
>> the PHY. "rgmii-txid" requires the MAC to handle the RX delay, which might
>> break the boards having a conformant (aka well-behaving) PHY. For some reason
>> the Microchip PHY seems to work fine in both cases, but that's most likely an
>> exception, as other PHYs might expose a totally different and undesired
>> behavior.
>>
>> I will prepare a v3 soon, and will drop the patches you have already submitted
>> as part of [1].
>
> Sounds good. Then what's missing for ethernet to work is just the clock patches:
> https://github.com/esmil/linux/commit/b5abe1cb3815765739aff7949deed6f65b952c4a
> https://github.com/esmil/linux/commit/3a7a423b15a9f796586cbbdc37010d2b83ff2367
>
> You can either include those as part of your patch series enabling ethernet, or
> they can be submitted separately with the audio clocks. Either way is
> fine by me.
I can cherry-pick them, but so far I couldn't identify any networking
related issues if those patches are not applied. Could it be something
specific to Starlight board only?
> /Emil
>
>>
>> Thanks again for your support,
>> Cristian
>>
>> [1]: https://lore.kernel.org/all/20231126232746.264302-1-emil.renner.berthing@xxxxxxxxxxxxx/
