From: Miquel Raynal <miquel.raynal@bootlin.com>
To: "Timothy Krantz" <tkrantz@stahurabrenner.com>
Cc: linux-arm-kernel@lists.infradead.org
Subject: Re: espressobin device tree with kernel 5.1 RC
Date: Tue, 18 Jun 2019 19:26:35 +0200 [thread overview]
Message-ID: <20190618192635.5118d594@xps13> (raw)
In-Reply-To: <!&!AAAAAAAAAAAuAAAAAAAAAOBWTR25SONAuESb5loyl/sBAMO2jhD3dRHOtM0AqgC7tuYAAAAAAA4AABAAAADpLpjRTgFBSZBSAreF/AshAQAAAAA=@stahurabrenner.com>
Hi Timothy,
"Timothy Krantz" <tkrantz@stahurabrenner.com> wrote on Tue, 18 Jun 2019
13:08:39 -0400:
> Miquel,
>
>
> > -----Original Message-----
> > From: Miquel Raynal [mailto:miquel.raynal@bootlin.com]
> > Sent: Tuesday, June 18, 2019 11:36 AM
> > To: Timothy Krantz <tkrantz@stahurabrenner.com>
> > Cc: linux-arm-kernel@lists.infradead.org
> > Subject: Re: espressobin device tree with kernel 5.1 RC
> >
> > Hi Timothy,
> >
> > > > > [ 4.203692] cacheinfo: Unable to detect cache hierarchy for CPU 0
> > > > > [ 4.210192] in mvebu probe
> > > > > [ 4.212924] check device match
> > > > > [ 4.216026] device did match
> > > > > [ 4.219058] check resources
> > > > > [ 4.221858] resources ok
> > > > > [ 4.224458] enable resources
> > > > > [ 4.227405] past enable resources
> > > > > [ 4.230817] disenable resources
> > > > > [ 4.234042] past disable resources
> > > > > [ 4.237536] init host
> > > > > [ 4.239931] ahci-mvebu d00e0000.sata: AHCI 0001.0300 32 slots 1 ports
> > 6
> > > > Gbps 0x1 impl platform mode
> > > > > [ 4.249196] ahci-mvebu d00e0000.sata: flags: ncq sntf led only pmp fbs
> > pio
> > > > slum part sxs
> > > > > [ 4.258647] scsi host0: ahci-mvebu
> > > > > [ 4.262491] ata1: SATA max UDMA/133 mmio [mem 0xd00e0000-
> > > > 0xd00e1fff] port 0x100 irq 21
> > > > > [ 4.270609] past init host
> > > > > [ 4.273353] past rc check
> > > > > [ 4.276455] Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
> > > > > [ 4.284408] MACsec IEEE 802.1AE
> > > > > [ 4.287965] libphy: Fixed MDIO Bus: probed
> > > > > [snip]
> > > > >
> > > > > Unfortunately that does not tell me much. Does it say anything to you?
> > > > > I mean I guess rc = ahci_platform_enable_resources(hpriv); Is
> > failing,
> > > > should I put some traces in that?
> > > >
> > > > Yes, in particular around the PHY initialization, until you found
> > > > where it fails exactly.
> > > >
> > > >
> > > > Thanks,
> > > > Miquèl
> > >
> > > I have traced it down to phy_init in phy-core.c and have put in the following
> > traces:
> > >
> > > int phy_init(struct phy *phy)
> > > {
> > > int ret;
> > >
> > > if (!phy)
> > > return 0;
> > >
> > > ret = phy_pm_runtime_get_sync(phy);
> > > if (ret < 0 && ret != -ENOTSUPP)
> > > return ret;
> > > ret = 0; /* Override possible ret == -ENOTSUPP */
> > >
> > > mutex_lock(&phy->mutex);
> > > printk(KERN_INFO "in phy init before check\n"); printk(KERN_INFO
> > > "phy->init_count %d\n", phy->init_count); printk(KERN_INFO
> > > "phy->ops->init %pr\n", phy->ops->init);
> > > if (phy->init_count == 0 && phy->ops->init) { printk(KERN_INFO
> > > "in phy init past check\n");
> > > ret = phy->ops->init(phy);
> > > if (ret < 0) {
> > > printk(KERN_INFO "in phy init phy->ops->init(phy) failed\n");
> > > dev_err(&phy->dev, "phy init failed --> %d\n", ret);
> > > goto out;
> > > }
> > > }
> > > ++phy->init_count;
> > >
> > > out:
> > > mutex_unlock(&phy->mutex);
> > > phy_pm_runtime_put(phy);
> > > return ret;
> > > }
> > >
> > > Which produces the following dmesg :
> > > [ 4.194835] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled
> > > [ 4.205270] cacheinfo: Unable to detect cache hierarchy for CPU 0
> > > [ 4.211777] in mvebu probe
> > > [ 4.214508] check device match
> > > [ 4.217609] device did match
> > > [ 4.220662] check resources
> > > [ 4.223455] resources ok
> > > [ 4.226061] in phy init before check
> > > [ 4.229718] phy->init_count 0
> > > [ 4.232774] phy->ops->init (null)
> > > [ 4.236188] phy phy-d0018300.phy.2: phy poweron failed --> -1
> > > [ 4.242095] enable resources
> > > [ 4.245072] ahci-mvebu: probe of d00e0000.sata failed with error -1
> > > [ 4.251831] Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
> > > [ 4.259753] MACsec IEEE 802.1AE
> > > [ 4.263371] libphy: Fixed MDIO Bus: probed
> > > [ 4.267777] tun: Universal TUN/TAP device driver, 1.6
> > > [ 4.273375] libphy: orion_mdio_bus: probed
> > >
> > > I believe the significant line is [ 4.232774] phy->ops->init (null)
> > >
> > > I'm not sure where that was supposed to have been initialized but it
> > apparently was not.
> >
> > Something looks wrong in your logs: you have init_count to 0 and
> > ops->init() to NULL, how can "(phy->init_count == 0 && phy->ops->init)"
> > be evaluated to true?
> >
> > Miquèl
>
> My prior assertion that the if did not evaluate true is based on not seeing the :
>
> printk(KERN_INFO "in phy init past check\n");
>
> inside of the if statement.
>
> That being said. I have 3 espressobins, one from the original kickstart, one bought on amazon and purported to be a v5 board and one v7 board bought from globalscale directly.
>
> All of the testing I have done has been on the v5 board. Is there any chance that there might be some differences in the various revisions? Want revision board are you testing on? If I have one that matches I will test on that one as well.
I don't think it's a hw problem, v5 is fine. Have you updated your
firmware recently? You will need a recent firmware (ATF) in order to
have the SMC calls to work. You can trace the _power_on() function
which probably fails at its end in
drivers/phy/marvell/phy-mvebu-a3700-comphy.c.
Good luck!
Miquèl
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-06-18 17:26 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <!&!AAAAAAAAAAAuAAAAAAAAAOBWTR25SONAuESb5loyl/sBAMO2jhD3dRHOtM0AqgC7tuYAAAAAAA4AABAAAABB6J1kxOR7T73eMrM92Eq+AQAAAAA=@stahurabrenner.com>
2019-04-29 7:57 ` espressobin device tree with kernel 5.1 RC Miquel Raynal
2019-04-29 15:03 ` Timothy Krantz
2019-04-29 15:25 ` Uwe Kleine-König
2019-04-29 16:07 ` Marc Gonzalez
2019-04-29 18:10 ` Miquel Raynal
[not found] ` <!&!AAAAAAAAAAAuAAAAAAAAAOBWTR25SONAuESb5loyl/sBAMO2jhD3dRHOtM0AqgC7tuYAAAAAAA4AABAAAAABdzCVMdZ+R6253dvJGHcXAQAAAAA=@stahurabrenner.com>
2019-06-17 9:38 ` Miquel Raynal
2019-06-17 9:40 ` Miquel Raynal
2019-06-17 17:19 ` Timothy Krantz
2019-06-18 7:58 ` Miquel Raynal
2019-06-18 14:15 ` Timothy Krantz
2019-06-18 14:24 ` Miquel Raynal
2019-06-18 15:28 ` Timothy Krantz
2019-06-18 15:36 ` Miquel Raynal
2019-06-18 15:42 ` Timothy Krantz
2019-06-18 17:08 ` Timothy Krantz
2019-06-18 17:26 ` Miquel Raynal [this message]
2019-06-18 20:07 ` Timothy Krantz
2019-06-19 10:29 ` Miquel Raynal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190618192635.5118d594@xps13 \
--to=miquel.raynal@bootlin.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=tkrantz@stahurabrenner.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).