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

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

 



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?

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