Re: smsc911x on Gumstix Overo/Tobi doesn't work

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux