On Wed, May 2, 2012 at 1:42 PM, Thomas Klute <thomas2.kl...@uni-dortmund.de> wrote: > Am 01.04.2012 21:20, schrieb Javier Martinez Canillas: >> On Fri, Mar 30, 2012 at 5:28 PM, Thomas Klute >> <thomas2.kl...@uni-dortmund.de> wrote: >>> Hi, >>> >>> I finally had some time to do more tests on this problem. Findings below. >>> >> >> Great, I guess we are close to find the issue :) >> >>> Am 20.03.2012 20:47, schrieb Javier Martinez Canillas: >>>> On Tue, Mar 20, 2012 at 3:27 PM, Thomas Klute >>>> <thomas2.kl...@uni-dortmund.de> wrote: >>>>> Am 19.03.2012 23:51, schrieb Tony Lindgren: >>>>>> * Thomas Klute <thomas2.kl...@uni-dortmund.de> [120319 09:26]: >>>>>>> Am 16.03.2012 20:33, schrieb Tony Lindgren: >>>>>>>> Hi, >>>>>>>> >>>>>>>> * Thomas Klute <thomas2.kl...@uni-dortmund.de> [120316 05:08]: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I have trouble getting the Ethernet port on a Gumstix Overo with Tobi >>>>>>>>> expansion board to work with current kernel versions. With the latest >>>>>>>>> commit from linux-omap git (b8fe1781ec8bed5e086691a827a6ee11facec2aa), >>>>>>>>> the output from loading the smsc911x driver is as follows: >>>>>>>>> >>>>>>>>> du14:~# modprobe smsc911x >>>>>>>>> [ 254.843811] smsc911x: Driver version 2008-10-21 >>>>>>>>> [ 254.854553] smsc911x: Driver version 2008-10-21 >>>>>>>>> [ 254.859588] _regulator_get: smsc911x.1 supply vdd33a not found, >>>>>>>>> using >>>>>>>>> dummy regulator >>>>>>>>> [ 254.868377] _regulator_get: smsc911x.1 supply vddvario not found, >>>>>>>>> using dummy regulator >>>>>>>>> >>>>>>>>> "ip link show" does not show any available Ethernet port. >>>>>>>> >>>>>>>> The first instance one should work the same way as earlier using >>>>>>>> fixed regulator in gpmc-smsc911x.c. Is it not working for you >>>>>>>> somehow? At least it works for me on zoom3. >>>>>>> >>>>>>> The Tobi board has only one Ethernet port. >>>>>>> >>>>>>>>> I know there has been some trouble with changes around smsc911x >>>>>>>>> regulator support and Gumstix Overo in particular. Am I just missing >>>>>>>>> the >>>>>>>>> right regulator in my kernel config or is this a bug? I can test >>>>>>>>> patches >>>>>>>>> in the latter case. >>>>>>>> >>>>>>>> The second smsc911x now needs a regulator. For multiple smsc911x >>>>>>>> instances, >>>>>>>> we should change things around so no regulator is created if one >>>>>>>> is passed. >>>>>>>> >>>>>>>> Care to test the following patch by passing a fixed regulator >>>>>>>> from board-overo.c? >>>>>>> >>>>>>> After applying the patch the Ethernet port works consistently once I had >>>>>>> done a cold boot (reboot from the unpatched kernel did not work). >>>>>>> Thank you! >>>>>> >>>>>> Hmm but this patch should not change the behaviour for the first smsc911x >>>>>> instance unless you specify a custom regulator.. Did you patch in a >>>>>> custom regulator, or do we have a bug somewhere? Or do you just need to >>>>>> do a cold reset without the patch I posted? >>>>> >>>>> You're right, during further tests I found that the problem lies >>>>> elsewhere: If the Ethernet cable is attached on modprobe, the device >>>>> works as expected, if not, it's not found (with or without the patch). >>>>> This means if I boot with the cable disconnected, the device won't show >>>>> up, but after >>>>> >>>>> # modprobe -r smsc911x >>>>> [attach cable] >>>>> # modprobe smsc911x >>>>> >>>>> it will work. I'd still consider this a bug, but it doesn't seem to be a >>>>> regulator problem. >>>>> >>>> >>>> Hi Thomas, >>>> >>>> I had the same behavior with the smsc911x chip but on an IGEPv2 board. >>>> The problem was when CONFIG_SMSC_PHY=y since the driver for the chip >>>> internal PHY enables an energy detect power-down mode. >>>> >>>> The smsc911x driver probe function tries to software reset the chip >>>> but if the cable is unplugged the energy detect puts the chip in a low >>>> power mode. Since the chip is not in an operational state the reset >>>> fails and hence the driver probe function. If the cable is plugged >>>> then then energy is detected, the chip is in an operational state and >>>> the reset is successful. >>>> >>>> I sent a patch a few months ago to fix this issue. The patch disables >>>> the energy detect power-down mode before reseting the chip and then it >>>> enables again after reset. >>>> >>>> The commit is: >>>> >>>> commit 6386994e03ebbe60338ded3d586308a41e81c0dc >>>> Author: Javier Martinez Canillas <jav...@dowhile0.org> >>>> Date: Tue Jan 3 13:36:19 2012 +0000 >>>> >>>> net/smsc911x: Check if PHY is in operational mode before software reset >>>> >>>> When I fix the issue I only guarded against generation 4 chips (i.e: >>>> pdata->generation == 4), but maybe this problem also exists in other >>>> SMSC chips (I didn't know since I only had access to specific >>>> data-sheets). >>>> >>>> Also you can try enabling debug in the driver by setting USE_DEBUG to >>>> 1 in drivers/net/ethernet/smsc/smsc911x.h and also trying disabling >>>> CONFIG_SMSC_PHY, this will use a generic PHY driver that doesn't put >>>> the chip in auto power mode. >>> >>> After looking at the code I set USE_DEBUG to 3 to get as much >>> information as possible and tested with and without the SMSC PHY driver. >>> Results: >>> >>> With the Ethernet cable attached, the device is properly initialized >>> with and without the PHY driver (as before). >>> >>> Without the cable, the smsc911x driver can initialize the card only if >>> the smsc PHY driver had not been loaded previously. Unloading the PHY >>> driver is not enough, even a reboot doesn't help. I have to do a cold >>> boot (or attach the cable). >>> >> >> This makes sense since is the PHY driver who enables the auto energy >> detect mode. >> >>> I guess this confirms Javier's guess, but there's one catch: If you take >>> a look at the attached logs (both without cable attached), you'll see >>> that the device is recognized a generation 4, so the Javier's workaround >>> should actually be used. I added a log output in the if >>> (pdata->generation == 4) block to be sure, and indeed it is used. >>> >>> Any hints why the reset still fails? >>> >>> Regards, >>> Thomas >> >> My guess is that the PHY chip is still in a low power down and not >> being woken up before the MAC chip is tried to be software reseted. I >> didn't find in the SMSC LAN8700 data-sheet how long it takes to wake >> up the chip and probably it depends of the PHY chip (I only tried with >> the 8700) so if I were you I would try increasing the delay time after >> sending the MII command to disable the auto energy detect mode. >> >> Can you try this patch? > > The longer delay did not help, even with mdelay(1000) the reset still > failed. There's one exception: After a cold boot, the device is > discovered correctly without cable and with the smsc PHY driver loaded. >
Hi Thomas, I'm out of ideas then, sorry. Without the hardware to test I can not think now why that could happen. > (Sorry about the delay, this problem isn't really an issue for our > project now that we have a reliable workaround...) > Don't worry, is the same for me. With the workaround my platform (IGEPv2 board) works well so I don't have time to dig more on this. Best regards, >> diff --git a/drivers/net/ethernet/smsc/smsc911x.c >> b/drivers/net/ethernet/smsc/smsc911x.c >> index 24d2df0..d08709a 100644 >> --- a/drivers/net/ethernet/smsc/smsc911x.c >> +++ b/drivers/net/ethernet/smsc/smsc911x.c >> @@ -1349,7 +1349,7 @@ static int >> smsc911x_phy_disable_energy_detect(struct smsc911x_data * >> return rc; >> } >> >> - mdelay(1); >> + mdelay(100); >> } >> >> return 0; >> >> >> Best regards, -- Javier Martínez Canillas (+34) 682 39 81 69 Barcelona, Spain -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
