Regression: v4.0-rc1: iMX6: Hummingboard fails due to drivers/clk changes
Russell King - ARM Linux
linux at arm.linux.org.uk
Mon Feb 23 15:53:50 PST 2015
On Mon, Feb 23, 2015 at 08:42:55PM -0300, Fabio Estevam wrote:
> Hi Russell,
> On Mon, Feb 23, 2015 at 7:32 PM, Russell King - ARM Linux
> <linux at arm.linux.org.uk> wrote:
> > All,
> > I just tried my SolidRun patch set on top of v4.0-rc1, and it fails to
> > boot. The kernel itself finishes booting, but it is unable to DHCP (for
> > root-NFS) - nothing appears on the network.
> > At first, I thought this would be a network driver bug, but reverting
> > the mainline changes there didn't fix the regression. Then I wondered
> > if it was something in arch/arm/mach-imx, but no.
> > When reverting all drivers/clk changes (and corresponding include/linux/*.h)
> > between v3.19 and v4.0-rc1, I find that the regression is fixed.
> > It seems that some CCF change is causing a regression somewhere in the
> > clock tree on iMX6 CPUs.
> > Unfortunately, without networking running, I can't dump the clock tree
> > to find out what's different, and bisecting will be a major pain (needing
> > each bisect point to be merged with my patch set, built and tested.)
> > Has anyone else seen this?
> Just tried it and I confirm that NFS fails to mount on a imx6q-hummingboard:
> [ 1.882023] fec 2188000.ethernet eth0: Freescale FEC PHY driver
> [Atheros 8035 ethernet] (mii_bus:phy_addr=2188000.ethernet:00, irq)
> [ 1.894409] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
> [ 1.954662] hub 2-1:1.0: USB hub found
> [ 1.958864] hub 2-1:1.0: 4 ports detected
> [ 3.882249] fec 2188000.ethernet eth0: Link is Up - 100Mbps/Full -
> flow control rx/tx
> [ 3.890900] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> [ 3.912131] Sending DHCP requests ...
> (Gets stuck here)
> I haven't seen this problem on other imx6 boards though running the
> same kernel.
The reason appears to be a lack of packets coming out of the ethernet.
Why that is, I'm not sure (maybe a gated GPIO16 clock to the phy?)
Given that the phy state seems frozen - it doesn't detect the cable
being disconnected - this seems highly likely.
Looking at imx6q_1588_init(), this could be a problem:
ptp_clk = of_clk_get(np, 2);
enet_ref = clk_get_sys(NULL, "enet_ref");
clksel = ptp_clk == enet_ref ? IMX6Q_GPR1_ENET_CLK_SEL_ANATOP :
since ptp_clk and enet_ref will _never_ be the same pointer. Forcing
that test to be always true fixes the problem.
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
More information about the linux-arm-kernel