Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
cnxsoft has quit [Ping timeout: 480 seconds]
junari has joined #linux-sunxi
<junari>
apritzel: about pinctrl, how I should bind reset-gpios for gmac?
<junari>
[ 10.068412] sun55i-a523-pinctrl 2000000.pinctrl: pin PH19 already requested by 4500000.ethernet; cannot claim for 2000000.pinctrl:243
<apritzel>
junari: do you mean for the PHY? I wouldn't know that the GMAC takes a reset *GPIO*?
<junari>
I mean snps,reset-gpio for mac or reset-gpios for phy
<apritzel>
isn't that the same? snps,reset-gpio is deprecated, and having that in the EMAC node sounds wrong indeed
<apritzel>
so drop snps,reset-gpio and just use reset-gpios in the PHY node?
<junari>
Is it necessary to configure the pin as gpio-out in the pio section in these cases?
<apritzel>
ah, no, this is taken care of automatically by any kind of *-gpios properties in the DT
<apritzel>
I mean by the generic kernel code dealing with those properties: the drivers or subsystems request those GPIOs, which will automatically configure them correctly
<junari>
I understand. In that case PH19 should not be part of emac-pins bindings, ight?
<junari>
*right
<apritzel>
exactly
<apritzel>
just mention it once in this reset-gpios property
<apritzel>
actually most of the PHY resets I found are somewhat optional, since they are typically pulled up, so if you just leave this pin alone it should work anyway
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
<junari>
I've had different experiences. In some cases it didn't work at all, and in some cases it worked 50% of the time
<junari>
I think jernej has encountered this too if he has been working with the myir t507 board
<apritzel>
yeah, could well be, but I have also seen boards where we don't describe them at all
<jernej>
phy resets are mixed bag, so upstream DTs are too in this regard
<junari>
No problems with reset-gpios now, it's all because I additionally described gpio in the pio section
<junari>
But the ethernet didn't work, but I had a little hope
<apritzel>
junari: on the X96QPro+? This would be expected, as this is the *second* EMAC, IIRC, which is definitely different from what sun8i-emac supports
<apritzel>
I think wens once mentioned that the different descriptor format might be supported by the other dwmac drivers or the stmmac-generic code, but we would need to at least wire this into sun8i-emac
<junari>
It feels like both ethernet are declared in the device tree. I didn't pay attention to that at all
<apritzel>
I don't remember how I found this exactly, but I think the running BSP kernel somewhat gave it away
<junari>
yep, I will check it too
<junari>
And we don't have any datasheets for this second ethernet?
<junari>
Yeah, you were right. In the device tree, 4500000 is disabled. And in the boot log I see [ 19.043517] dwmac-sunxi 4510000.ethernet eth0: configuring for phy/rgmii link mode
<apritzel>
it's all documented in the T527 manual (but not in the A523 one!), it's the GMAC200 there. The actual registers look familiar, but definitely the DMA descriptors are completely different
psydroid|2 has quit []
<apritzel>
as mentioned, wens seemed to recognise them, so it might not be too complicated to wire them in, but surely the devil is in the details there
psydroid has joined #linux-sunxi
<montjoie>
hello I seek a way to test crust works on my boards
junari has quit [Ping timeout: 480 seconds]
vagrantc has joined #linux-sunxi
<diego71>
montjoie: I had compiled and installed crust on a A64 board in the past
<diego71>
there is a guide in debian documentation about u-boot-sunxi