[PATCH 1/1] UBUNTU: SAUCE: S3 early resume debug via keyboard LEDs

Stefan Bader stefan.bader at canonical.com
Wed May 25 13:53:52 UTC 2011


On 25.05.2011 15:38, Colin Ian King wrote:
> On Tue, 2011-05-24 at 10:19 +0200, Stefan Bader wrote:
>> On 23.05.2011 16:06, Colin King wrote:
>>> From: Colin Ian King<colin.king at canonical.com>
>>>
>>> Add support to debug S3 early resume by flashing the keyboard
>>> LEDs three times in the realmode path.   This is useful to allow
>>> one to determine if S3 hangs occur in the BIOS or during the early
>>> resume phase.
>>>
>>> Add kernel parameter acpi_sleep=s3_leds to enable the s3 debugging
>>> option.  This can also be enabled by writing 8 to
>>> /proc/sys/kernel/acpi_video_flags.
>>>
>>> Signed-off-by: Colin Ian King<colin.king at canonical.com>
>>> ---
>>>    Documentation/kernel-parameters.txt      |    5 ++++-
>>>    arch/x86/kernel/acpi/realmode/wakemain.c |   27 +++++++++++++++++++++++++++
>>>    arch/x86/kernel/acpi/sleep.c             |    2 ++
>>>    3 files changed, 33 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
>>> index cc85a92..9f36ff4 100644
>>> --- a/Documentation/kernel-parameters.txt
>>> +++ b/Documentation/kernel-parameters.txt
>>> @@ -244,12 +244,15 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
>>>    			For broken nForce2 BIOS resulting in XT-PIC timer.
>>>
>>>    	acpi_sleep=	[HW,ACPI] Sleep options
>>> -			Format: { s3_bios, s3_mode, s3_beep, s4_nohwsig,
>>> +			Format: { s3_bios, s3_mode, s3_beep, s3_leds, s4_nohwsig,
>>>    				  old_ordering, s4_nonvs, sci_force_enable }
>>>    			See Documentation/power/video.txt for information on
>>>    			s3_bios and s3_mode.
>>>    			s3_beep is for debugging; it makes the PC's speaker beep
>>>    			as soon as the kernel's real-mode entry point is called.
>>> +			s3_leds is for debugging; it flashes the keyboard LEDs
>>> +			3 times as soon as the kernel's real-mode entry point is
>>> +			called.
>>>    			s4_nohwsig prevents ACPI hardware signature from being
>>>    			used during resume from hibernation.
>>>    			old_ordering causes the ACPI 1.0 ordering of the _PTS
>>> diff --git a/arch/x86/kernel/acpi/realmode/wakemain.c b/arch/x86/kernel/acpi/realmode/wakemain.c
>>> index 883962d..1d108be 100644
>>> --- a/arch/x86/kernel/acpi/realmode/wakemain.c
>>> +++ b/arch/x86/kernel/acpi/realmode/wakemain.c
>>> @@ -61,6 +61,30 @@ static void send_morse(const char *pattern)
>>>    	}
>>>    }
>>>
>>> +#define I8042_STATUS_REG	0x64
>>> +#define I8042_DATA_REG		0x60
>>> +#define I8042_SET_LED_BITS	0xed
>>> +#define I8042_STR_IBF		0x02
>>> +
>>> +static void flash_keyboard_leds(void)
>>> +{
>>> +	int i;
>>> +	unsigned char leds = 7;
>>> +
>>> +	/* Flash keyboard LEDs 3 times */
>>> +	for (i = 0; i<   6; i++) {
>>> +		while (inb(I8042_STATUS_REG)&   I8042_STR_IBF)
>>> +			;
>>> +		outb(I8042_SET_LED_BITS, I8042_DATA_REG);
>>> +		while (inb(I8042_STATUS_REG)&   I8042_STR_IBF)
>>> +			;
>>> +		outb(leds, I8042_DATA_REG);
>>> +		leds ^= 7;
>>> +		udelay(500000);
>>> +	}
>>> +}
>>> +
>>> +
>>>    void main(void)
>>>    {
>>>    	/* Kill machine if structures are wrong */
>>> @@ -78,4 +102,7 @@ void main(void)
>>>    		probe_cards(0);
>>>    		set_mode(wakeup_header.video_mode);
>>>    	}
>>> +
>>> +	if (wakeup_header.realmode_flags&   8)
>>> +		flash_keyboard_leds();
>>>    }
>>> diff --git a/arch/x86/kernel/acpi/sleep.c b/arch/x86/kernel/acpi/sleep.c
>>> index ff93bc1..182617c 100644
>>> --- a/arch/x86/kernel/acpi/sleep.c
>>> +++ b/arch/x86/kernel/acpi/sleep.c
>>> @@ -109,6 +109,8 @@ static int __init acpi_sleep_setup(char *str)
>>>    			acpi_realmode_flags |= 2;
>>>    		if (strncmp(str, "s3_beep", 7) == 0)
>>>    			acpi_realmode_flags |= 4;
>>> +		if (strncmp(str, "s3_leds", 7) == 0)
>>> +			acpi_realmode_flags |= 8;
>>>    #ifdef CONFIG_HIBERNATION
>>>    		if (strncmp(str, "s4_nohwsig", 10) == 0)
>>>    			acpi_no_s4_hw_signature();
>> Agree with John. Probably there are some definitions for the previous three bits
>> and adding the bit there would help to detect when upstream starts to use it.
>
> I'm being dull here, and not understanding what you are saying.  Do you
> mind explaining this a little more?
>
No. Well, _if_ they had used defines (which you told us they have not), you 
could have used the next bit. And _if_ someone else does use the same patches 
collide (which they will not because there is no nice code to base on)

>> But otherwise nice and good to have. :)
>>
>> Acked (though there is not really one needed for O yet)
>>
>> -Stefan
>>
>
>





More information about the kernel-team mailing list