public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Nigel Cunningham <nigel@nigel.suspend2.net>
To: Pavel Machek <pavel@ucw.cz>
Cc: LKML <linux-kernel@vger.kernel.org>, Rafael Wysocki <rjw@sisk.pl>,
	Andrew Morton <akpm@osdl.org>
Subject: Re: [PATCH] Optional Beeping During Resume From Suspend To Ram.
Date: Fri, 29 Jun 2007 08:27:12 +1000	[thread overview]
Message-ID: <200706290827.13024.nigel@nigel.suspend2.net> (raw)
In-Reply-To: <20070628142532.GC5339@ucw.cz>

[-- Attachment #1: Type: text/plain, Size: 2911 bytes --]

Hi.

On Friday 29 June 2007 00:25:32 Pavel Machek wrote:
> Hi!
> 
> > Hi all
> > 
> > Here's what I have after today's work.
> > 
> > I haven't yet been able to test on x86, but can confirm that it works okay 
on x86_64. I'm currently working towards testing it on my old Omnibook. My P4 
desktop won't resume from suspend to ram at all, and hasn't produced any 
beeps.
> > 
> > I needed to move the BEEP invocation to after the data segment is 
reloaded, so that the test could access the variable. That was pretty tricky 
to find - no oops or anything bad prior, it just didn't beep when expected.
> > 
> > A couple of notes:
> > 
> > - I'd like to put the BEEP macro somewhere that can be shared by x86 32 
and 64. If that's a good idea, any suggestions on where? Nothing occurs to me 
straight off.
> > - I've just switched from Evo to Kmail. Please let me know if there's any 
mangling of the patch.
> > 
> > Regards,
> > 
> > Nigel
> > 
> >  arch/i386/kernel/acpi/wakeup.S   |   29 ++++++++++++++++++++++++++++-
> >  arch/x86_64/kernel/acpi/wakeup.S |   25 +++++++++++++++++++++++++
> >  include/linux/acpi.h             |    1 +
> >  kernel/power/main.c              |   23 +++++++++++++++++++++++
> >  4 files changed, 77 insertions(+), 1 deletion(-)
> > diff -ruNp 970-str-beep.patch-old/arch/i386/kernel/acpi/wakeup.S 
970-str-beep.patch-new/arch/i386/kernel/acpi/wakeup.S
> > --- 970-str-beep.patch-old/arch/i386/kernel/acpi/wakeup.S	2007-06-19 
12:15:25.000000000 +1000
> > +++ 970-str-beep.patch-new/arch/i386/kernel/acpi/wakeup.S	2007-06-19 
21:14:49.000000000 +1000
> > @@ -11,7 +11,22 @@
> >  #
> >  # If physical address of wakeup_code is 0x12345, BIOS should call us with
> >  # cs = 0x1234, eip = 0x05
> > -# 
> > +#
> > +
> > +#define BEEP \
> > +	inb	$97, %al; 	\
> > +	outb	%al, $0x80; 	\
> > +	movb	$3, %al; 	\
> > +	outb	%al, $97; 	\
> > +	outb	%al, $0x80; 	\
> > +	movb	$-74, %al; 	\
> > +	outb	%al, $67; 	\
> > +	outb	%al, $0x80; 	\
> > +	movb	$-119, %al; 	\
> > +	outb	%al, $66; 	\
> > +	outb	%al, $0x80; 	\
> > +	movb	$15, %al; 	\
> > +	outb	%al, $66;
> >  
> >  ALIGN
> >  	.align	4096
> > @@ -31,6 +46,11 @@ wakeup_code:
> >  	movw	%cs, %ax
> >  	movw	%ax, %ds					# Make ds:0 point to wakeup_start
> >  	movw	%ax, %ss
> > +
> > +	testl   $1, beep_flags - wakeup_code
> > +	jz      1f
> > +	BEEP
> > +1:
> 
> Can we rename/reuse existing flag variable?

Sorry, but I can't resist the opportunity to say "Send a patch!" :)

Seriously, though, I'd prefer not to. If we rename that acpi video flags 
variable (I assume this is what you're thinking of), we only create cause for 
confusion. A variable should for debugging or for controlling quirks, not for 
both at the same time.

Regards,

Nigel
-- 
Nigel, Michelle and Alisdair Cunningham
5 Mitchell Street
Cobden 3266
Victoria, Australia

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2007-06-28 23:29 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-19 11:18 [PATCH] Optional Beeping During Resume From Suspend To Ram Nigel Cunningham
2007-06-19 21:33 ` Rafael J. Wysocki
2007-06-20 22:09   ` Rafael J. Wysocki
2007-06-20 22:24     ` Nigel Cunningham
2007-06-21 21:20       ` Rafael J. Wysocki
2007-06-28 14:25 ` Pavel Machek
2007-06-28 22:27   ` Nigel Cunningham [this message]
2007-06-29 18:03     ` Stefan Seyfried
2007-06-29 22:35     ` Pavel Machek
2007-06-30 10:15       ` Rafael J. Wysocki
2007-06-30 10:11         ` Pavel Machek
2007-06-30 20:30           ` Rafael J. Wysocki
2007-07-04 21:29             ` Pavel Machek
2007-07-04 21:50               ` Rafael J. Wysocki
2007-07-04 22:46                 ` Pavel Machek
2007-07-05 19:03                   ` Rafael J. Wysocki
2007-07-05 22:32                     ` Pavel Machek
2007-07-04 22:34               ` Nigel Cunningham
2007-07-04 22:48                 ` Pavel Machek
2007-07-04 22:56                   ` Nigel Cunningham
2007-07-04 23:01                     ` Pavel Machek
2007-07-04 23:10                       ` Nigel Cunningham
2007-07-04 23:25                         ` Pavel Machek
2007-07-05 18:43                           ` Rafael J. Wysocki
2007-07-05 22:37                             ` Pavel Machek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200706290827.13024.nigel@nigel.suspend2.net \
    --to=nigel@nigel.suspend2.net \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=rjw@sisk.pl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox