On 18/09/2020 18:14, Petko Manolov wrote:
On 20-09-17 21:29:41, David Bilsby wrote:
On 17/09/2020 07:42, Petko Manolov wrote:
On 20-09-16 22:32:03, David Bilsby wrote:
Hi
Would you consider making the PhyLink modifications to the Altera TSE
driver public as this would be very useful for a board we have which uses
an SFP PHY connected to the TSE core via I2C. Currently we are using a
fibre SFP and fixing the speed to 1G but would really like to be able to
use a copper SFP which needs to do negotiation.
Well, definitely yes.
The driver isn't 100% finished, but it mostly works. One significant
downside is the kernel version i had to port it to: 4.19. IIRC there is API
change so my current patches can't be applied to 5.x kernels. Also, i could
not finish the upstreaming as the customer device i worked on had to be
returned.
Interesting about kernel versions as we have just moved to the latest 5.4.44
lts kernel as suggested on Rocketboard for Arria 10s. We had been having
issues with 4.19 kernel which seem to have been resolved in the 5.4.44.
Always use mainline (and new) kernels. If possible... ;)
However, given access to Altera TSE capable device (which i don't have atm),
running a recent kernel, i'll gladly finish the upstreaming.
I would be happy to take what you have at the moment, pre-upstreaming, and see
if I can get it going on the latter kernel, and hopefully provide some testing
feedback. Obviously pass any changes back for you to review and include as
part of your original work.
There you go.
Petko
Hi Petko
I've made some progress in integrating your TSE patches, in between
doing my main work. I've managed to get the code into the later 5.4.44
kernel and compile without errors, however my initial attempts failed to
configure the driver. In case it was due to the kernel port I backed out
to my 4.19 kernel build and used your patches as is. This also failed
but after a bit of debug I realised it was just the device tree set up.
I'm using the device tree as created by the sopc2dts tool, however this
does not seem to create a "pcs" memory region in the TSEs iomem "reg"
section. Did you add this section manually or was it created
automatically from your sopcinfo file?
If you added this manually was it because the "pcs" regions location
depends on the cores configuration, i.e. MAC and PCS or just PCS, and
therefore it was easier to pass this into the driver through the device
tree? The firmware manual suggests that for a MAC with PCS core
configuration the MAC registers appears at offset 0x0 for 0x80 and then
the PCS registers from 0x80 for 0x20. I manually edited my device tree
to shrink the default "control_port" region, which seems to map in the
driver to the MAC config registers and then added the "pcs" region above
this. Once I'd done that the driver loaded successfully. I suspect if I
make this change to the 5.4.44 kernel version it will also initialise
the driver.
I now seem to be tantalisingly close to getting it working. I can see
network packets arriving if I do a "tcpdump -i eth0" using a copper
10/100/1000Base-T SFP, but no packets seem to be transmitted. I'm
guessing I've maybe messed up on the device tree entries for either the
SFP config or maybe how it links back to the TSE. In the TSE device tree
section I added the following as suggested by your original post:
sfp = <&sfp_eth_b>;
managed = “in-band-status”;
Should I have added anything for the "phy-handle", thinks it's "<0>" at
the moment?
For the SFP device tree section I added the following at the top level
which broadly followed the "sff,sfp" document:
/ {
sfp_eth_b: sfp-eth-b {
compatible = “sff,sfp”;
i2c-bus = <sfp_b_i2c>;
los-gpios = <&pca9506 10 GPIO_ACTIVE_HIGH>;
…
};
};
The SFP cage is connected to the "sfp_b_i2c" I2C bus, this is actually
off an I2C mux but that I'm hoping will be handled by Linux as it has a
driver for the MUX chip. I assume the default SFP I2C address (0x50) is
used by the PhyLink layer so there is no need to specify that? The LED
indicators for my set up are off another I2C GPIO expander (PCA9506), so
I used those references for the LOS, etc "gpios" entries. This section
also has the "tx-disable-gpios" property, again I referenced the
appropriate pin off the PCA9506, so I guess if I got that wrong then
that could explain the failure on the Tx side. That said none of the LED
GPIOs I hooked up seemed to light so maybe there is something up there.
Any hints would be most welcome.
Cheers
David
