Date:   Thu, 1 Oct 2020 09:39:59 +0300
From:   Petko Manolov <petkan@...leusys.com>
To:     David Bilsby <d.bilsby@...gin.net>
Cc:     Thor Thayer <thor.thayer@...ux.intel.com>, netdev@...r.kernel.org
Subject: Re: Altera TSE driver not working in 100mbps mode

On 20-09-30 21:43:04, David Bilsby wrote:
> 
> 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?

First off, it is recommended that you base your work on the latest kernel, 
unless the device you work on is stuck to an old one.  I can see that Altera TSE 
driver has received some attention recently so you should keep an eye on 
'netdev'.  Check the driver in v5.9 and, if possible, backport it to v5.4.

Second, PCS: in this particular design these registers were put at a specific 
location and that information went into the DT.  I had to add some glue code so 
the driver could receive these values and replace the defaults with.

> 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

Yup.

> 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

These are implementation specific.  Don't forget you're on FPGA device, which 
allows for a lot of flexibility - memory region address and size shifts, 32 vs 
16 bit wide memory, etc.  You have to take into account both, TSE's manual as 
well as the actual implementation docs.

> 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>;
> 
>         …
> 
>     };
> 
> };

I've attached the .dtsi i used to hack on.  It most certainly won't work for 
your device, but you may get some inspiration.



		Petko


> 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
> 
> 
> 
> 

View attachment "petunia.dtsi" of type "text/plain" (8281 bytes)

Powered by blists - more mailing lists