Am 03.05.2012 13:09, schrieb Javier Martinez Canillas: > On Wed, May 2, 2012 at 1:42 PM, Thomas Klute > <thomas2.klute@xxxxxxxxxxxxxxx> wrote: >> Am 01.04.2012 21:20, schrieb Javier Martinez Canillas: >>> On Fri, Mar 30, 2012 at 5:28 PM, Thomas Klute >>> <thomas2.klute@xxxxxxxxxxxxxxx> 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.klute@xxxxxxxxxxxxxxx> wrote: >>>>>> Am 19.03.2012 23:51, schrieb Tony Lindgren: >>>>>>> * Thomas Klute <thomas2.klute@xxxxxxxxxxxxxxx> [120319 09:26]: >>>>>>>> Am 16.03.2012 20:33, schrieb Tony Lindgren: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> * Thomas Klute <thomas2.klute@xxxxxxxxxxxxxxx> [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 <javier@xxxxxxxxxxxx> >>>>> 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. Same here. :-( Anyways, thanks a lot for your help! Best regards, Thomas > 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, > -- 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
