On Friday 23 October 2015 08:16 PM, Russell King - ARM Linux wrote:
On Fri, Oct 23, 2015 at 11:17:06AM +0200, Arnd Bergmann wrote:
On Thursday 22 October 2015 15:27:05 Loc Ho wrote:
Let me comment on this APM X-Gene driver. This driver is dead and
won't be supported in near or foreseeable future. And someday, it will
be ripped out. Based on experience, this solution (having PHY driver
in Linux) can't be supported across boards and etc as it is just too
much maintenance. And therefore, we followed Arnd B guidance and move
all this into the boot loader. From Linux or OS perspective, it only
cares about the interface in which its interface with. This is just
your reference and may be this will help you as well.
This depends a lot on the use case. If the chip is only used on server
parts that have a real firmware and you can deliver bug fixes for the
firmware if necessary, it's always best to do as much of the setup as
possible there, and let Linux see a simplified view of the hardware.
However, for embedded systems that tend to ship with a minimal binary
bootloader and no way to update that as an end-user, we rely on Linux
to know about all the hardware that requires some form of setup, which
is why we have all sorts of drivers and frameworks in the kernel that
a server can easily ignore.
While keystone can show up in servers that won't use this driver, my
impression is that its main market is actually in embedded space.
That's an interesting point of view - especially as you can't make the
argument that Marvell Armada chips would ever be anything but the
embedded space, but we're so far getting away with having the serdes
setup in u-boot - and even Marvell's BSP doesn't have it in the kernel.
The real question here is:
Why would we want to statically setup serdes links in the kernel
according to the DTB, rather than having the boot loader set them up?
Lot of PHYs have HW configure the parameters with default values so the
driver really doesn't have to touch them (like programming the equalizer
and the various digital mode configuration and analog mode
configuration). Then the SW just has to take care of clock programming
and powering on/off the PHY.
Some platforms require the controller core be in reset before powering
on the PHY, so we can't have all the configurations done in bootloader
for all the platforms.
The problem w.r.t code size starts when the drivers starts to configure
the analog and digital components inside the PHY (like equalizer,
While performing all these configurations in bootloader will help reduce
the code size, as Arnd pointed out, it'll cause problems if the PHY
loses the contents after a suspend/resume cycle.
This is true for most of the serdes except 10G. 10G would require reconfiguration of the SerDes if it has to work in 1G mode. You wouldn't want to power cycle the board in case user wants to plug in a 1G link. We plan to add 10G support based on this serdes patch and also need to handle 1G mode on 10G as well in the future.For the most part, the choice between the serdes modes is fairly static,
depending on the board wiring. You wouldn't ever want to configure a
mini-PCIe socket for gigabit ethernet.
However, there are cases when you would want to change it, and I'm
aware of these cases:
* Serdes routed to a mini-PCIe socket, which is compatible with mSATA.
There's an argument here to allow the serdes link to be switched at
runtime between PCIe and mSATA. However, the card type can't be
detected at run time, so this would have to be a manual configuration
change by the user.
Since mini-PCIe is not hot-pluggable, this configuration isn't
something that could be changed without powering the system down.
* Serdes routed to a SFP cage, where the serdes link is configured
for gigabit (or faster for SFP+) ethernet. For gigabit only, serdes
is configured in either 1000base-X or Cisco SGMII mode (SGMII is a
non-802.3 modification to 1000base-X) depending on the type of
transceiver plugged in.
Arguably, there's a third option here, which is SATA as well - I'm
aware of one non-standard SFP module on the market which provides a
SATA connector, but this is highly non-standard, is not covered by
the SFP specifications, so such a switch to this mode would have to
be done manually.
The difference between 1000base-X vs SGMII is to do with the generation
and interpretation of a 16-bit configuration word passed across the
link. Otherwise, the two are identical - and so far I've seen the
configuration word mode is determined by the ethernet block rather than
the serdes block.
My argument would be that even in the case of the last paragraph,
normal use for serdes reconfiguration would be a power cycle, even in
the embedded environment.
Now, that all said, it looks to me like TI's serdes implementation can't
be switched between different modes - it's statically configured to
whatever the DTB says it should be.
So, this brings up the obvious question: why do we need to support
serdes configuration in the kernel rather than statically in the boot
loader according to the board setup?
Specifically on this patch series, I think that if we're going to have
code doing serdes configuration in the kernel, we need to come up with
a common set of DT properties for it, rather than having everyone doing
their own thing.
doesn't do anything beyond configuring the hardware for the settings
that DTB tells it to, so why it has to be 2.5k lines I've no idea.
There's some specific comments I have about it using readl/writel, and
its wrapping of those, which IMHO it shouldn't be doing,
for loops (what's wrong with the standard Linux way of defining a
for_each_xxx() operator and leaving the body at the callsite?)