On Fri, Sep 28, 2007 at 01:26:56AM -0700, Andrew Morton wrote:
> On Fri, 28 Sep 2007 10:17:30 +0200 Thomas Gleixner <[EMAIL PROTECTED]> wrote:
>
> > can we please add this to checkpatch.pl ?
> >
> > > -spinlock_t bpci_lock = SPIN_LOCK_UNLOCKED;
> > > +DEFINE_SPINLOCK(bpci_lock);
>
> That check
On Fri, Sep 28, 2007 at 03:41:13PM +0900, Paul Mundt wrote:
> On Thu, Sep 27, 2007 at 11:25:01PM -0700, Andrew Morton wrote:
> > On Wed, 26 Sep 2007 15:40:26 -0700 Mark Gross <[EMAIL PROTECTED]> wrote:
> > > +int qos_add_requirement(int qos, char *name
On Thu, Sep 27, 2007 at 11:25:01PM -0700, Andrew Morton wrote:
> On Wed, 26 Sep 2007 15:40:26 -0700 Mark Gross <[EMAIL PROTECTED]> wrote:
>
> > +#define QOS_RESERVED 0
> > +#define QOS_CPU_DMA_LATENCY 1
> > +#define QOS_NETWORK_LATENCY 2
> > +#define QOS_NET
On Thu, Sep 27, 2007 at 11:25:01PM -0700, Andrew Morton wrote:
On Wed, 26 Sep 2007 15:40:26 -0700 Mark Gross [EMAIL PROTECTED] wrote:
+#define QOS_RESERVED 0
+#define QOS_CPU_DMA_LATENCY 1
+#define QOS_NETWORK_LATENCY 2
+#define QOS_NETWORK_THROUGHPUT 3
+
+#define QOS_NUM_CLASSES 4
On Fri, Sep 28, 2007 at 03:41:13PM +0900, Paul Mundt wrote:
On Thu, Sep 27, 2007 at 11:25:01PM -0700, Andrew Morton wrote:
On Wed, 26 Sep 2007 15:40:26 -0700 Mark Gross [EMAIL PROTECTED] wrote:
+int qos_add_requirement(int qos, char *name, s32 value);
+int qos_update_requirement(int qos
On Fri, Sep 28, 2007 at 01:26:56AM -0700, Andrew Morton wrote:
On Fri, 28 Sep 2007 10:17:30 +0200 Thomas Gleixner [EMAIL PROTECTED] wrote:
can we please add this to checkpatch.pl ?
-spinlock_t bpci_lock = SPIN_LOCK_UNLOCKED;
+DEFINE_SPINLOCK(bpci_lock);
That check is already in
i)
> > > +{
> > 'target' might be a more meaningful variable name.
>
> Anything but 'i'.
>
> ---
Updated qos PM parameter patch:
Note: the replacing of latency.c with this is a separate patch.
this patch attempts to address the issues raised so far.
--mgross
S
On Thu, Sep 27, 2007 at 11:24:40AM +0900, Paul Mundt wrote:
> On Wed, Sep 26, 2007 at 03:40:26PM -0700, Mark Gross wrote:
> > + struct list_head list;
> > + union {
> > + s32 value;
> > + s32 usec;
> > + s32 kbps;
> > +
On Wed, Sep 26, 2007 at 09:05:15PM -0700, Randy Dunlap wrote:
> On Thu, 27 Sep 2007 11:24:40 +0900 Paul Mundt wrote:
>
> > > +/* static helper functions */
> > > +static s32 max_compare(s32 v1, s32 v2)
> > > +{
> > > + if (v1 < v2)
> > > + return v2;
> > > + else
> > > + return
On Wed, Sep 26, 2007 at 10:53:03PM -0400, [EMAIL PROTECTED] wrote:
> On Wed, 26 Sep 2007 17:40:20 PDT, Mark Gross said:
> (others here are probably better at spotting leaks and races than I am,
> so I'm skipping those and picking other nits. ;)
>
> > --- linux-2.6.23-r
On Thu, Sep 27, 2007 at 12:18:21PM +0900, Paul Mundt wrote:
> On Wed, Sep 26, 2007 at 10:53:03PM -0400, [EMAIL PROTECTED] wrote:
> > On Wed, 26 Sep 2007 17:40:20 PDT, Mark Gross said:
> > > --- linux-2.6.23-rc8/kernel/Makefile 2007-09-26 13:54:54.0
> > > -
On Thu, Sep 27, 2007 at 12:18:21PM +0900, Paul Mundt wrote:
On Wed, Sep 26, 2007 at 10:53:03PM -0400, [EMAIL PROTECTED] wrote:
On Wed, 26 Sep 2007 17:40:20 PDT, Mark Gross said:
--- linux-2.6.23-rc8/kernel/Makefile 2007-09-26 13:54:54.0
-0700
+++ linux-2.6.23-rc8-qos
On Wed, Sep 26, 2007 at 10:53:03PM -0400, [EMAIL PROTECTED] wrote:
On Wed, 26 Sep 2007 17:40:20 PDT, Mark Gross said:
(others here are probably better at spotting leaks and races than I am,
so I'm skipping those and picking other nits. ;)
--- linux-2.6.23-rc8/kernel/Makefile2007-09
On Wed, Sep 26, 2007 at 09:05:15PM -0700, Randy Dunlap wrote:
On Thu, 27 Sep 2007 11:24:40 +0900 Paul Mundt wrote:
+/* static helper functions */
+static s32 max_compare(s32 v1, s32 v2)
+{
+ if (v1 v2)
+ return v2;
+ else
+ return v1;
+}
+
+static
On Thu, Sep 27, 2007 at 11:24:40AM +0900, Paul Mundt wrote:
On Wed, Sep 26, 2007 at 03:40:26PM -0700, Mark Gross wrote:
+ struct list_head list;
+ union {
+ s32 value;
+ s32 usec;
+ s32 kbps;
+ };
+ char *name;
Your } is in a strange
2007-09-27
08:42:54.0 -0700
@@ -0,0 +1,35 @@
+/* interface for the qos_power infrastructure of the linux kernel.
+ *
+ * Mark Gross
+ */
+#include linux/list.h
+#include linux/notifier.h
+#include linux/miscdevice.h
+
+struct requirement_list {
+ struct list_head list;
+ union
On Wed, Sep 26, 2007 at 04:41:59PM -0700, Randy Dunlap wrote:
> On Wed, 26 Sep 2007 15:40:26 -0700 Mark Gross wrote:
>
> > The following is the qos_param patch that implements a genralization of
> > latency.c.
> >
>
> Just some general comments (as on irc):
The following patch is a bit of a hack to illustrate how the qos
parameter infrastructure can communication information to the e1000
driver to use to set interrupt consolidation policy as a function of
acceptable network latency.
Its just an example.
Signed-off-by: Mark Gross <[EM
The following patch replaces latency.c with qos_params.c and fixes up
users of latency to use qos_params
Signed-off-by: Mark Gross <[EMAIL PROTECTED]>
diff -urN -X linux-2.6.23-rc8/Documentation/dontdiff
linux-2.6.23-rc8-qos/drivers/acpi/processor_idle.c
linux-2.6.23-rc8-qos-nolat
The following is the qos_param patch that implements a genralization of
latency.c.
Signed-off-by: Mark Gross <[EMAIL PROTECTED]>
diff -urN -X linux-2.6.23-rc8/Documentation/dontdiff
linux-2.6.23-rc8/include/linux/qos_params.h
linux-2.6.23-rc8-qos/include/linux/qos_params.h
--- linux-
The following patches implement a more generalized infrastructure (than
latency.c) for connecting drivers and subsystem's that could implement
power performance optimizations with the data needed to implement such
policies.
These patches are following up on the discussions and presentations at
The following patches implement a more generalized infrastructure (than
latency.c) for connecting drivers and subsystem's that could implement
power performance optimizations with the data needed to implement such
policies.
These patches are following up on the discussions and presentations at
The following is the qos_param patch that implements a genralization of
latency.c.
Signed-off-by: Mark Gross [EMAIL PROTECTED]
diff -urN -X linux-2.6.23-rc8/Documentation/dontdiff
linux-2.6.23-rc8/include/linux/qos_params.h
linux-2.6.23-rc8-qos/include/linux/qos_params.h
--- linux-2.6.23-rc8
The following patch replaces latency.c with qos_params.c and fixes up
users of latency to use qos_params
Signed-off-by: Mark Gross [EMAIL PROTECTED]
diff -urN -X linux-2.6.23-rc8/Documentation/dontdiff
linux-2.6.23-rc8-qos/drivers/acpi/processor_idle.c
linux-2.6.23-rc8-qos-nolatency.c/drivers
The following patch is a bit of a hack to illustrate how the qos
parameter infrastructure can communication information to the e1000
driver to use to set interrupt consolidation policy as a function of
acceptable network latency.
Its just an example.
Signed-off-by: Mark Gross [EMAIL PROTECTED
On Wed, Sep 26, 2007 at 04:41:59PM -0700, Randy Dunlap wrote:
On Wed, 26 Sep 2007 15:40:26 -0700 Mark Gross wrote:
The following is the qos_param patch that implements a genralization of
latency.c.
Just some general comments (as on irc):
- use 'diffstat -p1 -w70' to summarize each
forgot to CC greg ...
On Mon, Sep 24, 2007 at 09:18:22AM -0700, Mark Gross wrote:
> This weekend I was hacking around with a trivial USB driver for talking
> to the boot load firmware of a USB Bit Whacker. It's running the
> MicroChip Pic18 boot loader firmware and I'm putting togethe
and forget to release it.
The following patch fixes the problem for me.
--mgross
Signed-off-by: Mark Gross <[EMAIL PROTECTED]>
diff -urN -X linux-2.6.23-rc7/Documentation/dontdiff
linux-2.6.23-rc7/drivers/usb/usb-skeleton.c
linux-2.6.23-rc7-bugfix/drivers/usb/usb-skeleton.c
--- linux-2.6.
and forget to release it.
The following patch fixes the problem for me.
--mgross
Signed-off-by: Mark Gross [EMAIL PROTECTED]
diff -urN -X linux-2.6.23-rc7/Documentation/dontdiff
linux-2.6.23-rc7/drivers/usb/usb-skeleton.c
linux-2.6.23-rc7-bugfix/drivers/usb/usb-skeleton.c
--- linux-2.6.23-rc7
forgot to CC greg ...
On Mon, Sep 24, 2007 at 09:18:22AM -0700, Mark Gross wrote:
This weekend I was hacking around with a trivial USB driver for talking
to the boot load firmware of a USB Bit Whacker. It's running the
MicroChip Pic18 boot loader firmware and I'm putting together a flash
On Tue, Sep 11, 2007 at 03:48:53PM +0200, Dag-Erling Smørgrav wrote:
> The STMicroelectronics M41T11 is an RTC chip which is similar in most
> ways to the Dallas/Maxim DS1307 or DS1337, except that it supports
> software calibration:
>
> http://www.st.com/stonline/books/pdf/docs/6103.pdf
>
> I
On Tue, Sep 11, 2007 at 03:48:53PM +0200, Dag-Erling Smørgrav wrote:
The STMicroelectronics M41T11 is an RTC chip which is similar in most
ways to the Dallas/Maxim DS1307 or DS1337, except that it supports
software calibration:
http://www.st.com/stonline/books/pdf/docs/6103.pdf
I want to
The tlclk driver is going on the MPCBL005 so I need to make the Kconfig
more more generic. Just some text changes.
--mgross
Signed-off-by: Mark Gross <[EMAIL PROTECTED]>
diff -urN -X linux-2.6.21-rc2/Documentation/dontdiff
linux-2.6.21-rc2/drivers/char/Kconfig
linux-2.6.21-rc2-tlclk/d
The tlclk driver is going on the MPCBL005 so I need to make the Kconfig
more more generic. Just some text changes.
--mgross
Signed-off-by: Mark Gross [EMAIL PROTECTED]
diff -urN -X linux-2.6.21-rc2/Documentation/dontdiff
linux-2.6.21-rc2/drivers/char/Kconfig
linux-2.6.21-rc2-tlclk/drivers
On Fri, Mar 02, 2007 at 10:02:57AM -0800, Andrew Morton wrote:
> On Fri, 2 Mar 2007 09:35:27 -0800
> Mark Gross <[EMAIL PROTECTED]> wrote:
>
> > >
> > > Will it be possible to just power the DIMMs off? I don't see much point
> > > in
> > > som
On Fri, Mar 02, 2007 at 09:16:17AM -0800, Linus Torvalds wrote:
>
>
> On Fri, 2 Mar 2007, Mark Gross wrote:
> > >
> > > Yes, the same issues exist for other DRAM forms too, but to a *much*
> > > smaller degree.
> >
> > DDR3-1333 may be bette
On Fri, Mar 02, 2007 at 09:07:53AM -0800, Andrew Morton wrote:
> On Fri, 2 Mar 2007 08:20:23 -0800 Mark Gross <[EMAIL PROTECTED]> wrote:
>
> > > The whole DRAM power story is a bedtime story for gullible children.
> > > Don't
> > > fall for it. I
On Thu, Mar 01, 2007 at 09:11:58PM -0800, Linus Torvalds wrote:
>
> On Thu, 1 Mar 2007, Andrew Morton wrote:
> >
> > On Thu, 1 Mar 2007 19:44:27 -0800 (PST) Linus Torvalds <[EMAIL PROTECTED]>
> > wrote:
> >
> > > In other words, I really don't see a huge upside. I see *lots* of
> > >
On Thu, Mar 01, 2007 at 09:11:58PM -0800, Linus Torvalds wrote:
On Thu, 1 Mar 2007, Andrew Morton wrote:
On Thu, 1 Mar 2007 19:44:27 -0800 (PST) Linus Torvalds [EMAIL PROTECTED]
wrote:
In other words, I really don't see a huge upside. I see *lots* of
downsides, but upsides? Not
On Fri, Mar 02, 2007 at 09:07:53AM -0800, Andrew Morton wrote:
On Fri, 2 Mar 2007 08:20:23 -0800 Mark Gross [EMAIL PROTECTED] wrote:
The whole DRAM power story is a bedtime story for gullible children.
Don't
fall for it. It's not realistic. The hardware support for it DOES
On Fri, Mar 02, 2007 at 09:16:17AM -0800, Linus Torvalds wrote:
On Fri, 2 Mar 2007, Mark Gross wrote:
Yes, the same issues exist for other DRAM forms too, but to a *much*
smaller degree.
DDR3-1333 may be better than FBDIMM's but don't count on it being much
better.
Hey
On Fri, Mar 02, 2007 at 10:02:57AM -0800, Andrew Morton wrote:
On Fri, 2 Mar 2007 09:35:27 -0800
Mark Gross [EMAIL PROTECTED] wrote:
Will it be possible to just power the DIMMs off? I don't see much point
in
some half-power non-destructive mode.
I think so, but need
The following patch fixes a few problems with the tlclk driver.
* bug in the select_amcb1_transmit_clock
* racy read sys call
* racy open sys call
* use of add_timer where mod_timer would be better
* change to the timer data parameter use
Signed-off-by: Mark Gross <[EMAIL PROTECTED]>
The following patch fixes a few problems with the tlclk driver.
* bug in the select_amcb1_transmit_clock
* racy read sys call
* racy open sys call
* use of add_timer where mod_timer would be better
* change to the timer data parameter use
Signed-off-by: Mark Gross [EMAIL PROTECTED]
thanks
On Tue, Dec 05, 2006 at 10:25:43AM -0800, Mark Gross wrote:
> On Sat, Dec 02, 2006 at 01:03:32PM +0900, Akinobu Mita wrote:
> > On Wed, Nov 29, 2006 at 01:17:57PM -0800, Mark Gross wrote:
> > > > We expect platform_device_register_simple() returns proper errno as
> &g
On Tue, Dec 05, 2006 at 10:25:43AM -0800, Mark Gross wrote:
On Sat, Dec 02, 2006 at 01:03:32PM +0900, Akinobu Mita wrote:
On Wed, Nov 29, 2006 at 01:17:57PM -0800, Mark Gross wrote:
We expect platform_device_register_simple() returns proper errno as
pointer
when it fails
On Sat, Dec 02, 2006 at 01:03:32PM +0900, Akinobu Mita wrote:
> On Wed, Nov 29, 2006 at 01:17:57PM -0800, Mark Gross wrote:
> > > We expect platform_device_register_simple() returns proper errno as
> > > pointer
> > > when it fails.
> >
> > What's wrong
On Sat, Dec 02, 2006 at 01:03:32PM +0900, Akinobu Mita wrote:
On Wed, Nov 29, 2006 at 01:17:57PM -0800, Mark Gross wrote:
We expect platform_device_register_simple() returns proper errno as
pointer
when it fails.
What's wrong with EBUSY?
-ENOMEM or -EINVAL could be returned
On Tue, Nov 28, 2006 at 03:08:30PM +0900, Akinobu Mita wrote:
> On Mon, Nov 27, 2006 at 12:34:52PM -0800, Mark Gross wrote:
> > >
> > > tlclk_device = platform_device_register_simple("telco_clock",
> > > -1, NULL, 0);
> &g
On Tue, Nov 28, 2006 at 03:08:30PM +0900, Akinobu Mita wrote:
On Mon, Nov 27, 2006 at 12:34:52PM -0800, Mark Gross wrote:
tlclk_device = platform_device_register_simple(telco_clock,
-1, NULL, 0);
- if (!tlclk_device) {
+ if (IS_ERR(tlclk_device
On Mon, Nov 27, 2006 at 12:34:52PM -0800, Mark Gross wrote:
> On Thu, Nov 23, 2006 at 03:41:11AM +0900, Akinobu Mita wrote:
> > The return value of platform_device_register_simple() should be
> > checked by IS_ERR().
> >
> > This patch also fix misc_register() error
On Thu, Nov 23, 2006 at 03:41:11AM +0900, Akinobu Mita wrote:
> The return value of platform_device_register_simple() should be
> checked by IS_ERR().
>
> This patch also fix misc_register() error case. Because misc_register()
> returns error code.
>
> Cc: Sebastien Bouchard <[EMAIL PROTECTED]>
On Thu, Nov 23, 2006 at 03:41:11AM +0900, Akinobu Mita wrote:
The return value of platform_device_register_simple() should be
checked by IS_ERR().
This patch also fix misc_register() error case. Because misc_register()
returns error code.
Cc: Sebastien Bouchard [EMAIL PROTECTED]
On Mon, Nov 27, 2006 at 12:34:52PM -0800, Mark Gross wrote:
On Thu, Nov 23, 2006 at 03:41:11AM +0900, Akinobu Mita wrote:
The return value of platform_device_register_simple() should be
checked by IS_ERR().
This patch also fix misc_register() error case. Because misc_register()
returns
On Wednesday 31 August 2005 12:11, Pavel Machek wrote:
> Hi!
>
> > The following is a driver I would like to see included in the base kernel.
> >
> > It allows OS controll of a device that synchronizes signaling hardware
across a ATCA chassis.
> >
> > The telecom clock hardware doesn't
On Wednesday 31 August 2005 12:11, Pavel Machek wrote:
Hi!
The following is a driver I would like to see included in the base kernel.
It allows OS controll of a device that synchronizes signaling hardware
across a ATCA chassis.
The telecom clock hardware doesn't interact much with
On Tuesday 30 August 2005 15:31, Jesper Juhl wrote:
> On 8/31/05, Mark Gross <[EMAIL PROTECTED]> wrote:
> > On Tuesday 30 August 2005 14:19, Jesper Juhl wrote:
> > > On 8/30/05, Mark Gross <[EMAIL PROTECTED]> wrote:
> > > > On Tuesday 30 August 2005 13:31,
On Tuesday 30 August 2005 15:31, Jesper Juhl wrote:
On 8/31/05, Mark Gross [EMAIL PROTECTED] wrote:
On Tuesday 30 August 2005 14:19, Jesper Juhl wrote:
On 8/30/05, Mark Gross [EMAIL PROTECTED] wrote:
On Tuesday 30 August 2005 13:31, Mark Gross wrote:
On Tuesday 30 August 2005 12:16
On Tuesday 30 August 2005 14:19, Jesper Juhl wrote:
> On 8/30/05, Mark Gross <[EMAIL PROTECTED]> wrote:
> > On Tuesday 30 August 2005 13:31, Mark Gross wrote:
> > > On Tuesday 30 August 2005 12:16, Marcelo Tosatti wrote:
> > > >
> > > > Mark,
&
On Tuesday 30 August 2005 12:16, Marcelo Tosatti wrote:
>
> Mark,
>
> Please fix identation accordingly to CodingStyle and repost, it
> looks quite ugly at the moment.
>
Sorry about that.
> On Tue, Aug 30, 2005 at 11:59:33AM -0700, Mark Gross wrote:
> > The fo
The following is a driver I would like to see included in the base kernel.
It allows OS controll of a device that synchronizes signaling hardware across a
ATCA chassis.
The telecom clock hardware doesn't interact much with the operating system, and
is controlled
via registers in the FPGA on
The following is a driver I would like to see included in the base kernel.
It allows OS controll of a device that synchronizes signaling hardware across a
ATCA chassis.
The telecom clock hardware doesn't interact much with the operating system, and
is controlled
via registers in the FPGA on
On Tuesday 30 August 2005 12:16, Marcelo Tosatti wrote:
Mark,
Please fix identation accordingly to CodingStyle and repost, it
looks quite ugly at the moment.
Sorry about that.
On Tue, Aug 30, 2005 at 11:59:33AM -0700, Mark Gross wrote:
The following is a driver I would like to see
On Tuesday 30 August 2005 14:19, Jesper Juhl wrote:
On 8/30/05, Mark Gross [EMAIL PROTECTED] wrote:
On Tuesday 30 August 2005 13:31, Mark Gross wrote:
On Tuesday 30 August 2005 12:16, Marcelo Tosatti wrote:
Mark,
Please fix identation accordingly to CodingStyle and repost
On Monday 08 August 2005 08:35, Mark Gross wrote:
> On Wednesday 06 July 2005 14:14, Mark Gross wrote:
> > On Wednesday 22 June 2005 08:12, Bouchard, Sebastien wrote:
> > > Hi,
> > >
> > > Here is a driver (only for 2.4.x) I've done to provide support of a
>
On Monday 08 August 2005 08:35, Mark Gross wrote:
On Wednesday 06 July 2005 14:14, Mark Gross wrote:
On Wednesday 22 June 2005 08:12, Bouchard, Sebastien wrote:
Hi,
Here is a driver (only for 2.4.x) I've done to provide support of a
hardware module (available on some ATCA board
On Wednesday 06 July 2005 14:14, Mark Gross wrote:
> On Wednesday 22 June 2005 08:12, Bouchard, Sebastien wrote:
> > Hi,
> >
> > Here is a driver (only for 2.4.x) I've done to provide support of a
> > hardware module (available on some ATCA board) used with telecom ex
On Wednesday 06 July 2005 14:14, Mark Gross wrote:
On Wednesday 22 June 2005 08:12, Bouchard, Sebastien wrote:
Hi,
Here is a driver (only for 2.4.x) I've done to provide support of a
hardware module (available on some ATCA board) used with telecom expension
card on the new ATCA platform
On Friday 15 July 2005 16:14, Rik van Riel wrote:
> On Fri, 15 Jul 2005, Mark Gross wrote:
> > What would be wrong in expecting the folks making the driver changes
> > have some story on how they are validating there changes don't break
> > existing working hard
On Friday 15 July 2005 16:14, Rik van Riel wrote:
On Fri, 15 Jul 2005, Mark Gross wrote:
What would be wrong in expecting the folks making the driver changes
have some story on how they are validating there changes don't break
existing working hardware? I could probly be accomplished
On Thursday 14 July 2005 19:09, Dave Jones wrote:
> On Fri, Jul 15, 2005 at 03:45:28AM +0200, Jesper Juhl wrote:
> > > > The problem is the process, not than the code.
> > > > * The issues are too much ad-hock code flux without enough
> > > > disciplined/formal regression testing and review.
>
On Thursday 14 July 2005 19:16, Dave Airlie wrote:
> > That, of course, you cannot do. But, you can regression test a lot of
> > other things, and having a default test suite that is constantly being
> > added to and always being run before releases (that test hardware
> > agnostic stuff) could
On Thursday 14 July 2005 19:09, Andi Kleen wrote:
> > You can't test everything this way, nor should you, but you can test
> > many things, and adding a bit of formal testing to the release
> > procedure wouldn't be a bad thing IMO.
>
> In the linux model that's left to the distributions. In fact
On Thursday 14 July 2005 19:09, Andi Kleen wrote:
You can't test everything this way, nor should you, but you can test
many things, and adding a bit of formal testing to the release
procedure wouldn't be a bad thing IMO.
In the linux model that's left to the distributions. In fact doing it
On Thursday 14 July 2005 19:16, Dave Airlie wrote:
That, of course, you cannot do. But, you can regression test a lot of
other things, and having a default test suite that is constantly being
added to and always being run before releases (that test hardware
agnostic stuff) could help cut
On Thursday 14 July 2005 19:09, Dave Jones wrote:
On Fri, Jul 15, 2005 at 03:45:28AM +0200, Jesper Juhl wrote:
The problem is the process, not than the code.
* The issues are too much ad-hock code flux without enough
disciplined/formal regression testing and review.
It's
I know this is a broken record, but the development process within the LKML
isn't resulting in more stable and better code. Some process change could be
a good thing.
Why does my alps mouse pad have to stop working every time I test a new
"STABLE" kernel?
Why does swsup have to start
I know this is a broken record, but the development process within the LKML
isn't resulting in more stable and better code. Some process change could be
a good thing.
Why does my alps mouse pad have to stop working every time I test a new
STABLE kernel?
Why does swsup have to start hanging
On Wednesday 22 June 2005 08:12, Bouchard, Sebastien wrote:
> Hi,
>
> Here is a driver (only for 2.4.x) I've done to provide support of a
> hardware module (available on some ATCA board) used with telecom expension
> card on the new ATCA platform. This module provide redundant reference
> clock
On Wednesday 22 June 2005 21:49, Willy Tarreau wrote:
> Hi Pekka,
>
> On Thu, Jun 23, 2005 at 07:16:17AM +0300, Pekka J Enberg wrote:
> > Hi Willy,
> >
> > Willy Tarreau writes:
> > >I dont agree with you here : enums are good to simply specify an
> > >ordering.
> > >But they must not be used to
On Wednesday 22 June 2005 21:49, Willy Tarreau wrote:
Hi Pekka,
On Thu, Jun 23, 2005 at 07:16:17AM +0300, Pekka J Enberg wrote:
Hi Willy,
Willy Tarreau writes:
I dont agree with you here : enums are good to simply specify an
ordering.
But they must not be used to specify static
On Wednesday 22 June 2005 08:12, Bouchard, Sebastien wrote:
Hi,
Here is a driver (only for 2.4.x) I've done to provide support of a
hardware module (available on some ATCA board) used with telecom expension
card on the new ATCA platform. This module provide redundant reference
clock for
On Tuesday 29 March 2005 07:20, Bouchard, Sebastien wrote:
> Hi,
>
> I'm in the process of writing a linux driver and I have a question in
> regards to tasklet :
>
> Is it ok to have large delay "udelay(1000);" in the tasklet?
>
> If not, what should I do?
>
If the hardware can tolerate longer a
On Tuesday 29 March 2005 00:57, Ingo Molnar wrote:
> * Mark Gross <[EMAIL PROTECTED]> wrote:
> > > As I mentioned earlier, what would it take to be able to group
> > > softirq threads that should not preempt each other, but still keep
> > > preemption available
On Tuesday 29 March 2005 00:57, Ingo Molnar wrote:
* Mark Gross [EMAIL PROTECTED] wrote:
As I mentioned earlier, what would it take to be able to group
softirq threads that should not preempt each other, but still keep
preemption available for other threads?
It would only take
On Tuesday 29 March 2005 07:20, Bouchard, Sebastien wrote:
Hi,
I'm in the process of writing a linux driver and I have a question in
regards to tasklet :
Is it ok to have large delay udelay(1000); in the tasklet?
If not, what should I do?
If the hardware can tolerate longer a longer or
On Wednesday 02 March 2005 14:21, Linus Torvalds wrote:
> This is an idea that has been brewing for some time: Andrew has mentioned
> it a couple of times, I've talked to some people about it, and today Davem
> sent a suggestion along similar lines to me for 2.6.12.
>
> Namely that we could adopt
On Wednesday 02 March 2005 14:21, Linus Torvalds wrote:
This is an idea that has been brewing for some time: Andrew has mentioned
it a couple of times, I've talked to some people about it, and today Davem
sent a suggestion along similar lines to me for 2.6.12.
Namely that we could adopt the
On Thursday 17 February 2005 06:57, Steven Rostedt wrote:
> On Thu, 17 Feb 2005, Ingo Molnar wrote:
> > as long as it stays on a single CPU, could we allow softirq contexts to
> > preempt each other? I.e. we'd keep the per-CPU assumption (that is fair
> > and needed for performance anyway), but
On Thursday 17 February 2005 06:57, Steven Rostedt wrote:
On Thu, 17 Feb 2005, Ingo Molnar wrote:
as long as it stays on a single CPU, could we allow softirq contexts to
preempt each other? I.e. we'd keep the per-CPU assumption (that is fair
and needed for performance anyway), but we'd
On Wednesday 16 February 2005 09:59, George Anzinger wrote:
> David S. Miller wrote:
> > On Wed, 16 Feb 2005 06:16:45 +0100
> >
> > Ingo Molnar <[EMAIL PROTECTED]> wrote:
> >>Maybe the networking
> >>stack would break if we allowed the TIMER softirq (thread) to preempt
> >>the NET softirq
On Wednesday 16 February 2005 09:59, George Anzinger wrote:
David S. Miller wrote:
On Wed, 16 Feb 2005 06:16:45 +0100
Ingo Molnar [EMAIL PROTECTED] wrote:
Maybe the networking
stack would break if we allowed the TIMER softirq (thread) to preempt
the NET softirq (threads) (and vice
On Tuesday 15 February 2005 02:41, Ingo Molnar wrote:
> * Mark Gross <[EMAIL PROTECTED]> wrote:
> > On Monday 14 February 2005 13:24, Steven Rostedt wrote:
> > > On Mon, 2005-02-14 at 12:40 -0800, Mark Gross wrote:
> > > > I'm working on a tweak to th
On Tuesday 15 February 2005 02:41, Ingo Molnar wrote:
* Mark Gross [EMAIL PROTECTED] wrote:
On Monday 14 February 2005 13:24, Steven Rostedt wrote:
On Mon, 2005-02-14 at 12:40 -0800, Mark Gross wrote:
I'm working on a tweak to the preepmtive soft IRQ implementation
using work queues
On Monday 14 February 2005 13:24, Steven Rostedt wrote:
> On Mon, 2005-02-14 at 12:40 -0800, Mark Gross wrote:
> > I'm working on a tweak to the preepmtive soft IRQ implementation using
> > work queues and I'm having problems with a BUG assert when trying to
> > queue_wor
I'm working on a tweak to the preepmtive soft IRQ implementation using work
queues and I'm having problems with a BUG assert when trying to queue_work.
Souldn't I be able to call queue_work form ISR context?
--mgross
---
| preempt count: 0001 ]
| 1-level deep
I'm working on a tweak to the preepmtive soft IRQ implementation using work
queues and I'm having problems with a BUG assert when trying to queue_work.
Souldn't I be able to call queue_work form ISR context?
--mgross
---
| preempt count: 0001 ]
| 1-level deep
On Monday 14 February 2005 13:24, Steven Rostedt wrote:
On Mon, 2005-02-14 at 12:40 -0800, Mark Gross wrote:
I'm working on a tweak to the preepmtive soft IRQ implementation using
work queues and I'm having problems with a BUG assert when trying to
queue_work.
Souldn't I be able to call
201 - 298 of 298 matches
Mail list logo
