Please refer to my IDE freeze patch last week:
http://lkml.org/lkml/2005/8/25/140
It provides userspace with a method to freeze the queue and park the
head (through sysfs), along with a timeout to unfreeze, and works
quite well. It is in the process of being moved to the block layer
however so th
Hi
I think he doesn't need to export it at all and he should write code to
park and disable hard disk instead.
(in userspace it's unsolvable --- i.e. you can't enable hard disk when
detected stable condition if the daemon is swapped out on that hard disk)
man mlockall() :-).
You also must no
Hi!
> > > >>I think he doesn't need to export it at all and he should write code to
> > > >>park and disable hard disk instead.
> > > >>(in userspace it's unsolvable --- i.e. you can't enable hard disk when
> > > >>detected stable condition if the daemon is swapped out on that hard
> > > >>disk)
On Mon, 29 Aug 2005, Pavel Machek wrote:
> Hi!
>
> > >>I think he doesn't need to export it at all and he should write code to
> > >>park and disable hard disk instead.
> > >>(in userspace it's unsolvable --- i.e. you can't enable hard disk when
> > >>detected stable condition if the daemon is
Hi!
> >>I think he doesn't need to export it at all and he should write code to
> >>park and disable hard disk instead.
> >>(in userspace it's unsolvable --- i.e. you can't enable hard disk when
> >>detected stable condition if the daemon is swapped out on that hard disk)
> >
> >man mlockall() :-)
Of late I have been working on a driver for the IBM Hard Drive Active
Protection System (HDAPS), which provides a two-axis accelerometer and
some other misc. data. The hardware is found on recent IBM ThinkPad
laptops.
The following patch adds the driver to 2.6.13-rc6-mm2. It is
self-contained a
Oliver Neukum wrote:
If you need that, it belongs into the kernel.
Why? By that logic, any realtime app would have to be built into the
kernel. There is no need to put this kind of functionality into the
kernel itself. mlockall() and SCHED_FIFO scheduling priority should
ensure that the daem
On 8/26/05, Dmitry Torokhov <[EMAIL PROTECTED]> wrote:
> On 8/26/05, Robert Love <[EMAIL PROTECTED]> wrote:
> > On Fri, 2005-08-26 at 14:27 -0500, Dmitry Torokhov wrote:
> >
> > > What this completion is used for? I don't see any other references to it.
> >
> > It was the start of the release() rou
Am Sonntag, 28. August 2005 10:09 schrieb Pavel Machek:
>
> > >>Of late I have been working on a driver for the IBM Hard Drive Active
> > >>Protection System (HDAPS), which provides a two-axis accelerometer and
> > >>some other misc. data. The hardware is found on recent IBM ThinkPad
> > >>laptop
> >>Of late I have been working on a driver for the IBM Hard Drive Active
> >>Protection System (HDAPS), which provides a two-axis accelerometer and
> >>some other misc. data. The hardware is found on recent IBM ThinkPad
> >>laptops.
> >>
> >>The following patch adds the driver to 2.6.13-rc6-mm2.
Hi!
Of late I have been working on a driver for the IBM Hard Drive Active
Protection System (HDAPS), which provides a two-axis accelerometer and
some other misc. data. The hardware is found on recent IBM ThinkPad
laptops.
The following patch adds the driver to 2.6.13-rc6-mm2. It is
self-conta
Hi!
> Of late I have been working on a driver for the IBM Hard Drive Active
> Protection System (HDAPS), which provides a two-axis accelerometer and
> some other misc. data. The hardware is found on recent IBM ThinkPad
> laptops.
>
> The following patch adds the driver to 2.6.13-rc6-mm2. It is
On Saturday 27 August 2005 13:35, Alexey Dobriyan wrote:
> See? The difference is 64 vs 451 bytes.
Disabling unlikely() doesn't make much difference because the compiler
generates the probability internally then and reorders anyways
(that is why many unlikelys are completely useless
because the d
On Sad, 2005-08-27 at 02:29 -0300, Arnaldo Carvalho de Melo wrote:
> > unlikely() can result in better, smaller, faster code. and it acts as a
> > nice directive to programmers reading the code.
>
> Agreed, keep them :-)
If the unlikely() hints are being used correctly and the compiler is
doing
On Sat, Aug 27, 2005 at 01:12:50AM -0500, Dmitry Torokhov wrote:
> On Saturday 27 August 2005 00:34, Arnaldo Carvalho de Melo wrote:
> > Em Fri, Aug 26, 2005 at 09:06:22PM -0700, Mitchell Blank Jr escreveu:
> > > Andi Kleen wrote:
> > > > - it doesn't seem to help that much on modern CPUs with good
On Saturday 27 August 2005 00:34, Arnaldo Carvalho de Melo wrote:
> Em Fri, Aug 26, 2005 at 09:06:22PM -0700, Mitchell Blank Jr escreveu:
> > Andi Kleen wrote:
> > > - it doesn't seem to help that much on modern CPUs with good
> > > branch prediction and big icaches anyways.
> >
> > Really? I wou
Em Fri, Aug 26, 2005 at 09:06:22PM -0700, Mitchell Blank Jr escreveu:
> Andi Kleen wrote:
> > - it doesn't seem to help that much on modern CPUs with good
> > branch prediction and big icaches anyways.
>
> Really? I would think that as pipelines get deeper (although that trend
> seems to have sto
Em Fri, Aug 26, 2005 at 07:37:59PM -0400, Robert Love escreveu:
> On Fri, 2005-08-26 at 17:44 -0500, Dmitry Torokhov wrote:
>
> > Is this function used in a hot path to warrant using "unlikely"? There
> > are to many "unlikely" in the code for my taste.
>
> unlikely() can result in better, smalle
Andi Kleen wrote:
> - it doesn't seem to help that much on modern CPUs with good
> branch prediction and big icaches anyways.
Really? I would think that as pipelines get deeper (although that trend
seems to have stopped, thankfully) and Icache-miss penalties get relatively
larger we'd see unlikel
From: Andi Kleen <[EMAIL PROTECTED]>
Date: 27 Aug 2005 04:34:07 +0200
> "David S. Miller" <[EMAIL PROTECTED]> writes:
>
> > From: Alexey Dobriyan <[EMAIL PROTECTED]>
> > Date: Sat, 27 Aug 2005 02:58:48 +0400
> >
> > > What's the point of having unlikely() attached to every possible if ()?
> >
>
"David S. Miller" <[EMAIL PROTECTED]> writes:
> From: Alexey Dobriyan <[EMAIL PROTECTED]>
> Date: Sat, 27 Aug 2005 02:58:48 +0400
>
> > What's the point of having unlikely() attached to every possible if ()?
>
> If can result in smaller code, for one thing, even if it
> isn't a performance criti
On Fri, 2005-08-26 at 17:44 -0500, Dmitry Torokhov wrote:
> Is this function used in a hot path to warrant using "unlikely"? There
> are to many "unlikely" in the code for my taste.
unlikely() can result in better, smaller, faster code. and it acts as a
nice directive to programmers reading the
From: Alexey Dobriyan <[EMAIL PROTECTED]>
Date: Sat, 27 Aug 2005 02:58:48 +0400
> What's the point of having unlikely() attached to every possible if ()?
If can result in smaller code, for one thing, even if it
isn't a performance critical path.
-
To unsubscribe from this list: send the line "uns
On Fri, Aug 26, 2005 at 06:18:45PM -0400, Robert Love wrote:
> Attached patch provides a driver for the IBM Hard Drive Active
> Protection System (hdaps) on top of 2.6.13-rc6-mm2.
> --- linux-2.6.13-rc6-mm2/drivers/hwmon/hdaps.c
> +++ linux/drivers/hwmon/hdaps.c
> +static int hdaps_probe(struct d
On 8/26/05, Robert Love <[EMAIL PROTECTED]> wrote:
> +static void hdaps_calibrate(void)
> +{
> + int x, y, ret;
> +
> + ret = accelerometer_read_pair(HDAPS_PORT_XPOS, HDAPS_PORT_YPOS, &x,
> &y);
> + if (unlikely(ret))
> + return;
> +
> + rest_x = x;
> +
Robert Love <[EMAIL PROTECTED]> writes:
> On Fri, 2005-08-26 at 15:33 -0400, Jeff Garzik wrote:
>
> > Since such a check is possible, that's definitely a merge-stopper IMO
>
> First, I am not asking that Linus merge this. Everyone needs to relax.
>
> Second, we don't know a DMI-based solution
Andrew,
Attached patch provides a driver for the IBM Hard Drive Active
Protection System (hdaps) on top of 2.6.13-rc6-mm2.
Over the previous post, it contains several fixes and improvements,
including a dev->probe() routine and a DMI whitelist.
Robert Love
Driver for the IBM HDAPS
Sig
On Fri, Aug 26, 2005 at 03:29:15PM -0400, Robert Love wrote:
> On Fri, 2005-08-26 at 20:55 +0100, Alan Cox wrote:
>
> > I think that should be fixed before its merged.
>
> Let me be clear, it has an init routine that effectively probes for the
> device.
>
> It just lacks a simple quick n
On 8/26/05, Robert Love <[EMAIL PROTECTED]> wrote:
> On Fri, 2005-08-26 at 14:27 -0500, Dmitry Torokhov wrote:
>
> > What this completion is used for? I don't see any other references to it.
>
> It was the start of the release() routine, but I decided to move to
> platform_device_register_simple(
On 8/26/05, Robert Love <[EMAIL PROTECTED]> wrote:
> On Fri, 2005-08-26 at 15:39 -0400, Robert Love wrote:
>
> > > This is racy - 2 threads can try to do this simultaneously.
> >
> > Fixed. Thanks.
>
> Actually, doesn't sysfs and/or the vfs layer serialize the two
> simultaneous writes?
>
Not
On Gwe, 2005-08-26 at 15:37 -0400, Robert Love wrote:
> Second, we don't know a DMI-based solution will work. I'll check it out.
Another good sanity check would be tool for the right bridge chips with
device->subvendor == IBM ?
-
To unsubscribe from this list: send the line "unsubscribe linux-ker
On Fri, 2005-08-26 at 15:39 -0400, Robert Love wrote:
> > This is racy - 2 threads can try to do this simultaneously.
>
> Fixed. Thanks.
Actually, doesn't sysfs and/or the vfs layer serialize the two
simultaneous writes?
Robert Love
-
To unsubscribe from this list: send the line "uns
On Fri, 2005-08-26 at 15:33 -0400, Jeff Garzik wrote:
> Since such a check is possible, that's definitely a merge-stopper IMO
First, I am not asking that Linus merge this. Everyone needs to relax.
Second, we don't know a DMI-based solution will work. I'll check it out.
Robert Love
-
On Fri, 2005-08-26 at 14:27 -0500, Dmitry Torokhov wrote:
> What this completion is used for? I don't see any other references to it.
It was the start of the release() routine, but I decided to move to
platform_device_register_simple() and use its release, instead. So this
is gone now in my tree
Robert Love wrote:
On Fri, 2005-08-26 at 20:55 +0100, Alan Cox wrote:
I think that should be fixed before its merged.
Let me be clear, it has an init routine that effectively probes for the
device.
It just lacks a simple quick non-invasive check.
Since such a check is possible, that's de
On 8/26/05, Robert Love <[EMAIL PROTECTED]> wrote:
> +/* device class stuff */
> +
> +static DECLARE_COMPLETION(hdaps_obj_is_free);
> +static void hdaps_release_dev(struct device *dev)
> +{
> + complete(&hdaps_obj_is_free);
> +}
> +
What this completion is used for? I don't see any other ref
On Fri, 2005-08-26 at 20:55 +0100, Alan Cox wrote:
> I think that should be fixed before its merged.
Let me be clear, it has an init routine that effectively probes for the
device.
It just lacks a simple quick non-invasive check.
The driver will definitely fail to load on a laptop without the
r
On Gwe, 2005-08-26 at 13:33 -0400, Brian Gerst wrote:
> Is there any way to detect that this device is present (PCI, ACPI, etc.)
> without poking at ports?
DMI or probably IBM ssid values. Presumably IBM have somewhere they look
for this information ?
Making the driver only load on a DMI match o
On Gwe, 2005-08-26 at 14:03 -0400, Robert Love wrote:
> On Fri, 2005-08-26 at 20:01 +0200, Arjan van de Ven wrote:
>
> > > Not that we've been able to tell. It is a legacy platform device.
> > >
> > > So, unfortunately, no probe() routine.
> >
> > dmi surely
>
> Patches accepted.
I think
On Fri, 2005-08-26 at 14:45 -0400, Dave Jones wrote:
> A little difficult for people to submit dmi patches, unless they
> have hardware this driver runs on. Surely as you've tested this,
> you're in the best position to write such patches :-)
Surely one of the millions of people with a ThinkPad
On Fri, Aug 26, 2005 at 02:03:50PM -0400, Robert Love wrote:
> On Fri, 2005-08-26 at 20:01 +0200, Arjan van de Ven wrote:
>
> > > Not that we've been able to tell. It is a legacy platform device.
> > >
> > > So, unfortunately, no probe() routine.
> >
> > dmi surely
>
> Patches acc
On Fri, 2005-08-26 at 11:18 -0700, Andrew Morton wrote:
> > +config SENSORS_HDAPS
> > + tristate "IBM Hard Drive Active Protection System (hdaps)"
> > + depends on HWMON
> > + default n
> > + help
>
> How does this get along with CONFIG_INPUT=n, CONFIG_INPUT_MOUSEDEV=n, etc?
Probably a q
Robert Love <[EMAIL PROTECTED]> wrote:
>
> +config SENSORS_HDAPS
> +tristate "IBM Hard Drive Active Protection System (hdaps)"
> +depends on HWMON
> +default n
> +help
How does this get along with CONFIG_INPUT=n, CONFIG_INPUT_MOUSEDEV=n, etc?
-
To unsubscribe from this list: se
On Fri, 2005-08-26 at 20:01 +0200, Arjan van de Ven wrote:
> > Not that we've been able to tell. It is a legacy platform device.
> >
> > So, unfortunately, no probe() routine.
>
> dmi surely
Patches accepted.
Robert Love
-
To unsubscribe from this list: send the line "unsubscrib
On Fri, 2005-08-26 at 13:33 -0400, Robert Love wrote:
> On Fri, 2005-08-26 at 13:33 -0400, Brian Gerst wrote:
>
> > Is there any way to detect that this device is present (PCI, ACPI, etc.)
> > without poking at ports?
>
> Not that we've been able to tell. It is a legacy platform device.
>
> So
On Fri, 2005-08-26 at 13:33 -0400, Brian Gerst wrote:
> Is there any way to detect that this device is present (PCI, ACPI, etc.)
> without poking at ports?
Not that we've been able to tell. It is a legacy platform device.
So, unfortunately, no probe() routine.
Robert Love
-
To unsub
Robert Love wrote:
Andrew,
Of late I have been working on a driver for the IBM Hard Drive Active
Protection System (HDAPS), which provides a two-axis accelerometer and
some other misc. data. The hardware is found on recent IBM ThinkPad
laptops.
The following patch adds the driver to 2.6.13-rc6
On Fri, 2005-08-26 at 13:05 -0400, Bill Nottingham wrote:
> How does this relate to the hdaps driver hosted at sourceforge since
> June?
This driver is what is hosted there.
I thought it was time to push on.
Robert Love
-
To unsubscribe from this list: send the line "unsubscribe linux
Robert Love ([EMAIL PROTECTED]) said:
> Of late I have been working on a driver for the IBM Hard Drive Active
> Protection System (HDAPS), which provides a two-axis accelerometer and
> some other misc. data. The hardware is found on recent IBM ThinkPad
> laptops.
How does this relate to the hdap
Andrew,
Of late I have been working on a driver for the IBM Hard Drive Active
Protection System (HDAPS), which provides a two-axis accelerometer and
some other misc. data. The hardware is found on recent IBM ThinkPad
laptops.
The following patch adds the driver to 2.6.13-rc6-mm2. It is
self-con
50 matches
Mail list logo
