lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b170af451002210750i33221b3egc0bb940eac7191f5@mail.gmail.com>
Date:	Sun, 21 Feb 2010 16:50:36 +0100
From:	Rafał Miłecki <zajec5@...il.com>
To:	Thomas Hellstrom <thomas@...pmail.org>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	dri-devel@...ts.sourceforge.net
Subject: Re: [PATCH][RFC] time: add wait_interruptible_timeout macro to sleep 
	(w. timeout) until wake_up

W dniu 21 lutego 2010 16:01 użytkownik Thomas Hellstrom
<thomas@...pmail.org> napisał:
> Rafał Miłecki wrote:
>>
>> Signed-off-by: Rafał Miłecki <zajec5@...il.com>
>> ---
>> We try to implement some PM in radeon KMS and we need to sync with VLBANK
>> for
>> reclocking engine/memory. The easiest and cleanest way seems to be
>> sleeping in
>> timer handler just before reclocking. Then our IRQ handler calls wake_up
>> and we
>> continue reclocking.
>>
>> As you see our sleeping is condition-less, we just wait for waking up
>> queue.
>>
>> We hope this waking will happen from IRQ handler, but for less-happy case
>> we
>> also use some timeout (this will probably cause some single corruption,
>> but
>> we can live with it).
>>
>> Following macro is soemthing that seems to work fine for us, but instead
>> introducing this to radeon KMS only, I'd like to propose adding this to
>> whole
>> wait.h. Do you this it's something we should place there? Can someone take
>> this
>> patch for me? Or maybe you find this rather useless and we should keep
>> this
>> marco locally?
>
> What about msleep_interruptible in <linux/delay.h> ?

I guess this will wake up on every signal pending to driver's process.
I need to wake up using my own (VBLANK related) workqueue.

Is that right? Or maybe there is some hack/sth that will let me
achieve what I need?

-- 
Rafał
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ