All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rene Herman <rene.herman@gmail.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: LKML <linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@elte.hu>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Jeff Garzik <jeff@garzik.org>,
	Pekka Enberg <penberg@cs.helsinki.fi>
Subject: Re: [PATCH] CDROM: replace jiffies busyloop with msleep
Date: Wed, 23 May 2007 20:41:31 +0200	[thread overview]
Message-ID: <46548ADB.60207@gmail.com> (raw)
In-Reply-To: <1179829525.12708.118.camel@chaos>

On 05/22/2007 12:25 PM, Thomas Gleixner wrote:

> From: Ingo Molnar <mingo@elte.hu>
> 
> The SJCD driver uses a jiffies busy loop. Replace it with msleep.
> 
> Signed-off-by: Ingo Molnar <mingo@elte.hu>
> Acked-by: Thomas Gleixner <tglx@linutronix.de>

Okay, that's just waiting for a reset to complete, which seems perfectly 
fine with a sleeping loop like that, but...

I re-started working on a rewrite of the mitsumi legacy cdrom driver that 
Pekka Enberg and I have been doing this afternoon again and I ran into not 
being able to use sleeping loops there an hour ago!

The trouble there is that unless you poll the bloody thing like mad too much 
of the Q subchannels passes below you and you need a huge number of retries 
to get anything out of it. I noticed when I started adding audio bits that 
the driver took full seconds to complete some audio requests while the old 
driver was snappy in that regard. When I replaced our sleeping loop with a 
busy-wait same as the original the snappyness returned and moreover, reading 
the TOC from the CD went from something close to a minute to approximately a 
second. Thought that minute was just because I was dealing with an old junk 
1-speed drive...

Now, as said, this looks to be fine since it's just waiting for a reset to 
complete, but unless you have the hardware to actually test, be careful in 
there.

Or in fact, maybe even decide there's not much point. The current plan is to 
do mitsumi, sony and panasonic and then throw the rest away (that trio is 
special in so far that controllers for them are still available on a lot of 
old ISA soundcards). Or do you actually have the hardware?

Rene.

  parent reply	other threads:[~2007-05-23 18:44 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-22 10:25 [PATCH] CDROM: replace jiffies busyloop with msleep Thomas Gleixner
2007-05-22 10:30 ` Jeff Garzik
2007-05-22 11:21   ` Ingo Molnar
2007-05-22 11:20     ` Jens Axboe
2007-05-23 18:41 ` Rene Herman [this message]
2007-05-23 19:28   ` Ingo Molnar
2007-05-23 19:37     ` Rene Herman
2007-05-23 19:34   ` Alan Cox
2007-05-23 19:38     ` Rene Herman

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=46548ADB.60207@gmail.com \
    --to=rene.herman@gmail.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=jeff@garzik.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=penberg@cs.helsinki.fi \
    --cc=tglx@linutronix.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.