[PATCH v12 13/13] arm64: dts: ls1088ardb: Add serdes descriptions

Sean Anderson sean.anderson at seco.com
Tue Mar 28 07:40:41 PDT 2023


On 3/28/23 05:25, Ioana Ciornei wrote:
> On Mon, Mar 27, 2023 at 02:15:47PM -0400, Sean Anderson wrote:
>> On 3/24/23 09:17, Ioana Ciornei wrote:
>> > On Tue, Mar 21, 2023 at 04:13:12PM -0400, Sean Anderson wrote:
>> >> This adds serdes support to the LS1088ARDB. I have tested the QSGMII
>> >> ports as well as the two 10G ports. The SFP slot is now fully supported,
>> >> instead of being modeled as a fixed-link.
>> >> 
>> >> Linux hangs around when the serdes is initialized if the si5341 is
>> >> enabled with the in-tree driver, so I have modeled it as a two fixed
>> >> clocks instead. There are a few registers in the QIXIS FPGA which
>> >> control the SFP GPIOs; I have modeled them as discrete GPIO controllers
>> >> for now. I never saw the AQR105 interrupt fire; not sure what was going
>> >> on, but I have removed it to force polling.
>> > 
>> > So you didn't see the interrupt fire even without these patches?
>> 
>> Not sure. I went to check this, and discovered I could no longer get the
>> link to come up in Linux, even on v6.0 (before the rate adaptation
>> tuff). I see the LEDs blinking in U-Boot, so presumably it's some
>> configuration problem. I'm going to look into this further when I have
>> more time.
>> 
>> > I just tested this on a LS1088ARDB and it works.
>> > 
>> > 	root at localhost:~# cat /proc/interrupts | grep extirq
>> > 	 99:          5  ls-extirq   2 Level     0x0000000008b97000:00
>> > 	root at localhost:~# ip link set dev endpmac2 up
>> > 	root at localhost:~# cat /proc/interrupts | grep extirq
>> > 	 99:          6  ls-extirq   2 Level     0x0000000008b97000:00
>> > 	root at localhost:~# ip link set dev endpmac2 down
>> > 	root at localhost:~# cat /proc/interrupts | grep extirq
>> > 	 99:          7  ls-extirq   2 Level     0x0000000008b97000:00
>> > 
>> > Please don't just remove things.
>> 
>> Well, polling isn't the worst thing for a single interface... I do
>> remember having a problem with the interrupt. If this series works
>> with interrupts enabled, I can leave it in.
>> 
>> Did you have a chance to look at the core (patches 7 and 8) of this
>> series? Does it make sense to you? Am I missing something which would
>> allow switching from 1G->10G?
>> 
> 
> For a bit of context, I also attempted dynamic switching from 1G to 10G
> on my own even before this patch set but I did not get a link up on the
> PCS (CDR lock was there through). Pretty much the same state as you.
> 
> What I propose is to take this whole endeavor step by step.
> I am also interrested in getting this feature to actually work but I
> just didn't have the time to investigate in depth was is missing.
> And without the dynamic switching I cannot say that I find the addition
> of the SerDes PHY driver useful.

Well, it's still useful for supporting 1G and 10G. I touched on this in
the cover letter, but there are conflicting PLL defaults on the LS1046A.
If you use SRDS_PRCTL 1133, the PLL mapping is 2211. But for 3333 it's
2222. This means PLL2 is used for both 1G and 10G, but no reference
frequency can work for both. This will cause the PBL to enter a reset
loop, since it wants the PLLs to lock before booting, and this happens
before any user configuration. To get around this, we disconnected
RESET_REQ_B on our board, and we use this driver to configure the PLLs
correctly for whatever SRDS_PRCTL we boot up with.  This way we can have
two RCWs for 1G and 10G configuration.

> I have the Lynx 10G on my TODO list but I still have some other tasks
> on the Lynx 28G for the next 2-3 weeks. Once I get those done, I will
> look closer at the patches.

OK, thanks.

> In the meantime, some small thigs from this patch set can be submitted
> separately. For example, describing the SFP cage on the LS1088ARDB.

I'll have a look at this. I suppose I will also split off the IRQ thing.

> I still have some small questions on the DTS implementation for the gpio
> controllers but I would be able to submit this myself if you do not find
> the time (with your authorship of course).

I am going to do another revision to address the GPIO binding problem,
so please ask away.

--Sean



More information about the linux-arm-kernel mailing list