RE: [PATCH 00/11] OMAP3 CPUidle patches

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

 



I am still trying to find my way thru the codebase in GIT; but here is what I can suggest based on similar problem diagnosed (still under test) on the OMAP3EVM:

1) Save/restore the GPIO_IRQENABLE1, GPIO_IRQENABLE2
2) Save/restore the GPIO_IRQSTATUS1, GPIO_IRQSTATUS2

This needs to be done before entering (or leaving) deeper C-states.

Hope this helps.

Best regards,
Sanjeev

-----Original Message-----
From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap-owner@xxxxxxxxxxxxxxx] On Behalf Of Högander Jouni
Sent: Monday, July 07, 2008 3:27 PM
To: Kalle Jokiniemi
Cc: Nayak, Rajendra; 'Peter 'p2' De Schrijver'; linux-omap@xxxxxxxxxxxxxxx
Subject: Re: [PATCH 00/11] OMAP3 CPUidle patches

Kalle Jokiniemi <ext-kalle.jokiniemi@xxxxxxxxx> writes:

> On pe, 2008-07-04 at 15:15 +0530, ext Rajendra Nayak wrote:
> ...
>> > ext Högander Jouni <jouni.hogander@xxxxxxxxx> writes:
>
> ...
>
>> >
>> > So Rajendra sent his uImage and it works quite ok what comes to off
>> > mode on my sdp board. I still see problems with serial console
>> > (slow) and on boot I need to generate manually interrupts to get it
>> > to boot. Otherwise board hangs at this point:
>>
>> Yes, I noticed this as well. It takes quite long to bootup if you
>> don't generate UART interrupts.
>> After bootup once RET/OFF is hit, it takes a few hits to come out of
>> it as IO wakeup is missing.
>
> Jouni had a theory that the ethernet device could cause this slowness
> trouble in the startup, so I investigated the matter a little further.
> By enabling the debug prints in the ethernet chip driver,
>
> diff --git a/drivers/net/smc91x.c b/drivers/net/smc91x.c index
> 776c81d..7d1eead 100644
> --- a/drivers/net/smc91x.c
> +++ b/drivers/net/smc91x.c
> @@ -62,7 +62,7 @@ static const char version[] =
>
>  /* Debugging level */
>  #ifndef SMC_DEBUG
> -#define SMC_DEBUG              0
> +#define SMC_DEBUG              1
>  #endif
>
>
> I was able to see, that we get lots of RX overrun interrupts with
> cpu_idle, meaning that incoming stuff is not getting processed. By
> generating UART interrupts, I we probably can also catch more network
> RX interrupts and this helps the bootup go faster. With cpu_idle
> disabled, there were no RX overruns.

Your investigation supports this theory. Interrupt line from eth chip doesn't wake up mpu. I assume it is gpio line. Those are added to mpu wake-up events group, gpio wake-ups are enabled and mpu peripherals group wake-up event interrupt is enabled.

I'm suspecting that this problem happens if state where mpu is in sleep state and core+per are awake is used.

Any comments from TI people what might be wrong?

>
> I'll try to see if this can be fixed somehow.
>
>>
>> >
>> > eth0: link up
>> > Sending DHCP requests ., OK
>> > IP-Config: Got DHCP answer from 0.0.0.0, my address is
>> > 192.168.2.101
>> > IP-Config: Complete:
>> >      device=eth0, addr=192.168.2.101, mask=255.255.255.0,
>> > gw=192.168.2.1,
>> >      host=192.168.2.101, domain=ntc.nokia.com, nis-domain=(none),
>> >      bootserver=0.0.0.0, rootserver=172.22.146.197, rootpath=
>> > Looking up port of RPC 100003/2 on 172.22.146.197 Looking up port
>> > of RPC 100005/1 on 172.22.146.197
>> > VFS: Mounted root (nfs filesystem).
>> > Freeing init memory: 108K
>> >
>> > Rajendra, are you still using .config file you sent to me? Are all
>> > the changes in your tree available in l-o list.
>>
>> Yes, all the changes are part of the 11 patch set + 1 rework fixes patch I sent.
>> To debug further, can you put a few prints in omap3_enter_idle and
>> omap3_enter_idle_bm to see what states are selected by the menu gov.
>> We will then know if CORE RET/OFF is attempted but not achieved due
>> to some reason, or never attempted altogether.
>
> My setup does not seem to go beyond C2 state, btw. So I'll need to
> debug that also a bit. The above-mentioned patches are applied.
>
> Br, Kalle
>
>
> ...
>
>
>

--
Jouni Högander

--
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
��.n��������+%������w��{.n�����{�������ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f


[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