Igor,
THANKS SO MUCH FOR YOUR HELP! Your help has allowed us to fix the issue satisfactorally for now.
-----------
For those interested, under our version of Linux (linux-omap-3.2-rc6), the two ports were essentially fighting for MDIO address id 0, and it also appeared the EMAC was trying to bind the SMSC's PHY. As we suspected, the "fix" was to force one of ports to stop trying to use address 0 and to tell the EMAC explicitly which PHY to use.
We tried moving our kernel forward into the 3.3-rcX realm to make patching easier, but met a bunch of resistance from broken drivers we had working in the previous version. So, we went back. The changes we made were to move the EMAC to id '2', as shown below in the snip of our board file below.
{{{SNIP}}}
static struct platform_device b3517_mdio_device = {
.name = "davinci_mdio",
.id = 2,
.num_resources = ARRAY_SIZE(b3517_mdio_resources),
.resource = b3517_mdio_resources,
.dev.platform_data = &b3517_mdio_pdata,
};
static struct emac_platform_data b3517_emac_pdata = {
.phy_id = "2:00",
.rmii_en = 1,
};
{{{SNIP}}}
The operative argument here was the ".phy_id" directive Igor passed along. This forces the EMAC to grab a specific PHY, not just the first one sees, which for us always seemed to be the SMSC's.
I'm not sure if it was necessary, but to keep all this in sync, I also altered the clock3xxx_data.c patch to setup "mdio.2" instead fo "mdio.0".
+ CLK("davinci_emac", NULL, &emac_ick, CK_AM35XX),
+ CLK("davinci_mdio.2", NULL, &emac_fck, CK_AM35XX),
Anyway, things are working fine now as best we can tell.
[ 1.052795] smsc911x: Driver version 2008-10-21
[ 1.059539] smsc911x-mdio: probed
[ 1.063110] smsc911x smsc911x: eth0: attached PHY driver [Generic PHY] (mii_bus:phy_addr=ffffffff:01, irq=-1)
[ 1.073852] smsc911x smsc911x: eth0: MAC Address: ??:??:??:??:??:??
[ 1.120544] davinci_mdio davinci_mdio.2: davinci mdio revision 1.5
[ 1.127014] davinci_mdio davinci_mdio.2: detected phy mask fffffffe
[ 1.134124] davinci_mdio.2: probed
[ 1.137786] davinci_mdio davinci_mdio.2: phy[0]: device 2:00, driver unknown
We are anxious to move our kernel forward as soon as we reasonably can, as we've noted both the EMAC and SMSC have newer drivers similar boards are using. However, for us at the moment, the brokenness these changes bring to our effort isn't worth the time to correct it at the moment.
THANKS AGAIN FOR ALL YOUR HELP!
----------------------------
Hi,
On 03/05/12 19:32, CF Adad wrote:
> Hi Igor,
>
>
> Thanks for your reply! So are both ports working on the CM-T3517 simultaneously now?
Well, you need to apply all the patches I've sent you.
> Looking at the latest board file for the CM-T3517 (arch/arm/mach-omap2/board-cm-t3517.c), I don't see either the SMSC or the EMAC ports being initialized. Has that initialization code been moved somewhere else in the kernel?
>
Again, you need to apply the patches I've sent you.
> Regarding the patches: I had actually seen those (in the previous "version #2" I believe), and applied them to our kernel.
v3 is slightly different and you need the patch for the board file.
You need also the patches I've sent you privately.
> If you take a look at my board file below, you'll notice I defined a "USE_ALT__EMAC_ETH" definition that causes the separate EMAC file (created by those patches) to be used. I've tried both the old and the new (separate file) way of doing this. Our EMAC does work fine, as does our SMSC, except our SMSC does not store a MAC address. They just do not work together. One or the other must be disabled (commented out of the code) or neither work.
The patch I've sent you solves exactly that...
>
> It appears to me that the problem with running both is the mdio id setting. Perhaps they're both demanding the same slot or something?
Yes, there were several changes made to MDIO framework and how the whole thing is handled.
--
Regards,
Igor.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
