On 18/09/2020 18:14, Petko Manolov wrote:

On 20-09-17 21:29:41, David Bilsby wrote:

quoted

On 17/09/2020 07:42, Petko Manolov wrote:

quoted

On 20-09-16 22:32:03, David Bilsby wrote:

quoted

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... ;)

quoted

quoted

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