Re: [PATCH 1/2] regmap: only call custom reg_update_bits() if reg is marked volatile

> On Oct 6, 2015, at 6:13 AM, Mark Brown wrote: > >> On Mon, Oct 05, 2015 at 11:29:56PM -0700, David Miller wrote: >> From: Mark Brown > >>> Dave, to be clear please do *not* apply this patch at least for the time >>> being - I've not reviewed it or the one from Thursday that you applied >>>

Re: [PATCH 1/2] regmap: only call custom reg_update_bits() if reg is marked volatile

> On Oct 6, 2015, at 6:13 AM, Mark Brown wrote: > >> On Mon, Oct 05, 2015 at 11:29:56PM -0700, David Miller wrote: >> From: Mark Brown > >>> Dave, to be clear please do *not* apply this patch at least for the time >>> being - I've not reviewed it or the

Re: [PATCH net-next v2 1/2] regmap: Allow installing custom reg_update_bits function

On Mon, 5 Oct 2015, David Miller wrote: > From: j...@ringle.org > Date: Thu, 1 Oct 2015 07:43:20 -0400 > > > From: Jon Ringle > > > > This commit allows installing a custom reg_update_bits function for cases > > where > > the hardware provides a

Re: [PATCH net-next v2 1/2] regmap: Allow installing custom reg_update_bits function

On Mon, 5 Oct 2015, David Miller wrote: > From: j...@ringle.org > Date: Thu, 1 Oct 2015 07:43:20 -0400 > > > From: Jon Ringle <jrin...@gridpoint.com> > > > > This commit allows installing a custom reg_update_bits function for cases > > where >

Re: [PATCH 1/2] regmap: Allow installing custom reg_update_bits function

On Thu, 1 Oct 2015, Mark Brown wrote: > On Thu, Oct 01, 2015 at 02:33:06AM -0400, j...@ringle.org wrote: > > > @@ -2509,6 +2510,10 @@ static int _regmap_update_bits(struct regmap *map, > > unsigned int reg, > > int ret; > > unsigned int tmp, orig; > > > > + if

Re: [PATCH 1/2] regmap: Allow installing custom reg_update_bits function

On Thu, 1 Oct 2015, Mark Brown wrote: > On Thu, Oct 01, 2015 at 02:33:06AM -0400, j...@ringle.org wrote: > > > @@ -2509,6 +2510,10 @@ static int _regmap_update_bits(struct regmap *map, > > unsigned int reg, > > int ret; > > unsigned int tmp, orig; > > > > + if

Re: USB_MUSB_DA8XX with g_multi.ko

On Thu, Jun 26, 2014 at 2:29 AM, Christian Riesch wrote: > Hi Jon, > > On Thu, Jun 26, 2014 at 4:46 AM, Jon Ringle wrote: >> The only thing I needed to do was to remove the >> BROKEN dependency on USB_MUSB_DA8XX. Is there anything else I would >> have to do besides

Re: USB_MUSB_DA8XX with g_multi.ko

On Thu, Jun 26, 2014 at 2:29 AM, Christian Riesch christian.rie...@omicron.at wrote: Hi Jon, On Thu, Jun 26, 2014 at 4:46 AM, Jon Ringle j...@ringle.org wrote: The only thing I needed to do was to remove the BROKEN dependency on USB_MUSB_DA8XX. Is there anything else I would have to do

Re: USB_MUSB_DA8XX with g_multi.ko

On Wed, Jun 25, 2014 at 11:52 AM, Jon Ringle wrote: > On Wed, Jun 25, 2014 at 11:35 AM, Andrzej Pietrasiewicz > wrote: >> W dniu 25.06.2014 17:13, Jon Ringle pisze: >> >>> In commit 787f5627bec80094db487bfcb401e9744f181aed >>> usb: musb: make davi

Re: USB_MUSB_DA8XX with g_multi.ko

On Wed, Jun 25, 2014 at 11:35 AM, Andrzej Pietrasiewicz wrote: > W dniu 25.06.2014 17:13, Jon Ringle pisze: > >> In commit 787f5627bec80094db487bfcb401e9744f181aed >> usb: musb: make davinci and da8xx glues depend on BROKEN >> >> USB_MUSB_DA8XX was marked as BRO

USB_MUSB_DA8XX with g_multi.ko

In commit 787f5627bec80094db487bfcb401e9744f181aed usb: musb: make davinci and da8xx glues depend on BROKEN USB_MUSB_DA8XX was marked as BROKEN A few months ago, we updated the linux kernel on our AM1808 SoC based embedded board from Linux 2.6.33 to the latest long term 3.12. I am interested in

USB_MUSB_DA8XX with g_multi.ko

In commit 787f5627bec80094db487bfcb401e9744f181aed usb: musb: make davinci and da8xx glues depend on BROKEN USB_MUSB_DA8XX was marked as BROKEN A few months ago, we updated the linux kernel on our AM1808 SoC based embedded board from Linux 2.6.33 to the latest long term 3.12. I am interested in

Re: USB_MUSB_DA8XX with g_multi.ko

On Wed, Jun 25, 2014 at 11:35 AM, Andrzej Pietrasiewicz andrze...@samsung.com wrote: W dniu 25.06.2014 17:13, Jon Ringle pisze: In commit 787f5627bec80094db487bfcb401e9744f181aed usb: musb: make davinci and da8xx glues depend on BROKEN USB_MUSB_DA8XX was marked as BROKEN A few months ago

Re: USB_MUSB_DA8XX with g_multi.ko

On Wed, Jun 25, 2014 at 11:52 AM, Jon Ringle j...@ringle.org wrote: On Wed, Jun 25, 2014 at 11:35 AM, Andrzej Pietrasiewicz andrze...@samsung.com wrote: W dniu 25.06.2014 17:13, Jon Ringle pisze: In commit 787f5627bec80094db487bfcb401e9744f181aed usb: musb: make davinci and da8xx glues

Re: [PATCH v7 1/2] serial: sc16is7xx

On Fri, Apr 25, 2014 at 1:40 PM, Alexander Shiyan wrote: > Fri, 25 Apr 2014 10:26:40 -0700 от Greg KH : >> On Thu, Apr 24, 2014 at 08:56:06PM -0400, j...@ringle.org wrote: >> > From: Jon Ringle >> > >> > The SC16IS7xx is a slave I2C-bus/SPI interface to a

Re: [PATCH v7 1/2] serial: sc16is7xx

On Fri, Apr 25, 2014 at 10:24 AM, Charles Coldwell wrote: > On Fri, 25 Apr 2014, Jon Ringle wrote: > >> On Fri, Apr 25, 2014 at 9:44 AM, Charles Coldwell wrote: >> > On Fri, 25 Apr 2014, Charles Coldwell wrote: >> > >> >> On Thu, 24 Apr 2014, j...@

Re: [PATCH v7 1/2] serial: sc16is7xx

On Fri, Apr 25, 2014 at 9:35 AM, Alexander Shiyan wrote: > And it would be nice to have a small changelog, > because it is unclear what has changed with version 6. v7 was created at Greg's request to refresh the patch. The only conflict that required code change was in serial_core.h changing

Re: [PATCH v7 1/2] serial: sc16is7xx

On Fri, Apr 25, 2014 at 9:44 AM, Charles Coldwell wrote: > On Fri, 25 Apr 2014, Charles Coldwell wrote: > >> On Thu, 24 Apr 2014, j...@ringle.org wrote: >> >> > diff --git a/drivers/tty/serial/sc16is7xx.c >> > b/drivers/tty/serial/sc16is7xx.c >> > new file mode 100644 >> > index 000..ed139f5

Re: [PATCH v7 1/2] serial: sc16is7xx

On Fri, Apr 25, 2014 at 9:44 AM, Charles Coldwell coldw...@gmail.com wrote: On Fri, 25 Apr 2014, Charles Coldwell wrote: On Thu, 24 Apr 2014, j...@ringle.org wrote: diff --git a/drivers/tty/serial/sc16is7xx.c b/drivers/tty/serial/sc16is7xx.c new file mode 100644 index 000..ed139f5

Re: [PATCH v7 1/2] serial: sc16is7xx

On Fri, Apr 25, 2014 at 9:35 AM, Alexander Shiyan shc_w...@mail.ru wrote: And it would be nice to have a small changelog, because it is unclear what has changed with version 6. v7 was created at Greg's request to refresh the patch. The only conflict that required code change was in

Re: [PATCH v7 1/2] serial: sc16is7xx

On Fri, Apr 25, 2014 at 10:24 AM, Charles Coldwell coldw...@gmail.com wrote: On Fri, 25 Apr 2014, Jon Ringle wrote: On Fri, Apr 25, 2014 at 9:44 AM, Charles Coldwell coldw...@gmail.com wrote: On Fri, 25 Apr 2014, Charles Coldwell wrote: On Thu, 24 Apr 2014, j...@ringle.org wrote

Re: [PATCH v7 1/2] serial: sc16is7xx

On Fri, Apr 25, 2014 at 1:40 PM, Alexander Shiyan shc_w...@mail.ru wrote: Fri, 25 Apr 2014 10:26:40 -0700 от Greg KH gre...@linuxfoundation.org: On Thu, Apr 24, 2014 at 08:56:06PM -0400, j...@ringle.org wrote: From: Jon Ringle jrin...@gridpoint.com The SC16IS7xx is a slave I2C-bus/SPI

Re: [PATCH v5 1/2] serial: sc16is7xx

On Thu, Apr 3, 2014 at 11:23 AM, wrote: > From: Jon Ringle > > The SC16IS7xx is a slave I2C-bus/SPI interface to a single-channel > high performance UART. The SC16IS7xx's internal register set is > backward-compatible with the widely used and widely popular 16C450. > &g

Re: [PATCH v5 1/2] serial: sc16is7xx

On Thu, Apr 3, 2014 at 11:23 AM, j...@ringle.org wrote: From: Jon Ringle jrin...@gridpoint.com The SC16IS7xx is a slave I2C-bus/SPI interface to a single-channel high performance UART. The SC16IS7xx's internal register set is backward-compatible with the widely used and widely popular 16C450

Re: [PATCH v2 1/2] video: da8xx-fb: Add support for Densitron 84-0023-001T

On Tue, Apr 1, 2014 at 8:33 AM, wrote: > From: Jon Ringle > > Signed-off-by: Jon Ringle > --- > drivers/video/da8xx-fb.c | 14 ++ > 1 file changed, 14 insertions(+) > > diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c > index e030e17..d04

Re: [PATCH v2 1/2] video: da8xx-fb: Add support for Densitron 84-0023-001T

On Tue, Apr 1, 2014 at 8:33 AM, j...@ringle.org wrote: From: Jon Ringle jrin...@gridpoint.com Signed-off-by: Jon Ringle jrin...@gridpoint.com --- drivers/video/da8xx-fb.c | 14 ++ 1 file changed, 14 insertions(+) diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx

Re: [PATCH] video: da8xx-fb: Fix casting of info->pseudo_palette

I've not heard anything regarding this patch. I just want to make sure it's not lost :) Jon On Wed, Mar 5, 2014 at 3:19 AM, wrote: > From: Jon Ringle > > (Resending without corporate disclaimer in email footer) > > The casting to (u16 *) on info->pseudo_palette i

Re: [PATCH] video: da8xx-fb: Add support for Densitron 84-0023-001T

I've not heard anything regarding this patch. I just want to make sure it's not lost :) Jon On Wed, Mar 5, 2014 at 1:05 PM, wrote: > From: Jon Ringle > > Signed-off-by: Jon Ringle > --- > drivers/video/da8xx-fb.c | 14 ++ > 1 file changed, 14 insertions

Re: [PATCH v3] touchscreen: tps6507x-ts: only poll while touch event is occurring

I've not heard anything regarding this patch. I just want to make sure it doesn't get lost :) Jon On Wed, Mar 5, 2014 at 3:09 AM, wrote: > From: Jon Ringle > > (Resending without corporate dislaimer in email footer) > > We only need to poll for touch events after an inter

Re: [PATCH v2 2/2] serial: sc16is7xx: Add bindings documentation for the SC16IS7XX UARTs

On Wed, Mar 26, 2014 at 5:08 AM, Mark Rutland wrote: > On Tue, Mar 25, 2014 at 06:19:24PM +, j...@ringle.org wrote: >> +- interrupt-parent: The phandle for the interrupt controller that >> + services interrupts for this IC. >> +- interrupts: Specifies the interrupt source of the parent

Re: [PATCH v2 2/2] serial: sc16is7xx: Add bindings documentation for the SC16IS7XX UARTs

On Wed, Mar 26, 2014 at 5:08 AM, Mark Rutland mark.rutl...@arm.com wrote: On Tue, Mar 25, 2014 at 06:19:24PM +, j...@ringle.org wrote: +- interrupt-parent: The phandle for the interrupt controller that + services interrupts for this IC. +- interrupts: Specifies the interrupt source of the

Re: [PATCH v3] touchscreen: tps6507x-ts: only poll while touch event is occurring

I've not heard anything regarding this patch. I just want to make sure it doesn't get lost :) Jon On Wed, Mar 5, 2014 at 3:09 AM, j...@ringle.org wrote: From: Jon Ringle jrin...@gridpoint.com (Resending without corporate dislaimer in email footer) We only need to poll for touch events

Re: [PATCH] video: da8xx-fb: Add support for Densitron 84-0023-001T

I've not heard anything regarding this patch. I just want to make sure it's not lost :) Jon On Wed, Mar 5, 2014 at 1:05 PM, j...@ringle.org wrote: From: Jon Ringle jrin...@gridpoint.com Signed-off-by: Jon Ringle jrin...@gridpoint.com --- drivers/video/da8xx-fb.c | 14 ++ 1

Re: [PATCH] video: da8xx-fb: Fix casting of info-pseudo_palette

I've not heard anything regarding this patch. I just want to make sure it's not lost :) Jon On Wed, Mar 5, 2014 at 3:19 AM, j...@ringle.org wrote: From: Jon Ringle jrin...@gridpoint.com (Resending without corporate disclaimer in email footer) The casting to (u16 *) on info-pseudo_palette

Re: [PATCH v2] tty: serial: sc16is7xx

On Fri, Mar 21, 2014 at 4:26 AM, Heikki Krogerus wrote: > Hi, > > On Thu, Mar 20, 2014 at 10:05:33AM -0400, j...@ringle.org wrote: >> From: Jon Ringle >> >> The SC16IS7xx is a slave I2C-bus/SPI interface to a single-channel >> high performance UART. The

Re: [PATCH v2] tty: serial: sc16is7xx

On Fri, Mar 21, 2014 at 4:26 AM, Heikki Krogerus heikki.kroge...@linux.intel.com wrote: Hi, On Thu, Mar 20, 2014 at 10:05:33AM -0400, j...@ringle.org wrote: From: Jon Ringle jrin...@gridpoint.com The SC16IS7xx is a slave I2C-bus/SPI interface to a single-channel high performance UART

Re: [PATCH] RFC: WIP: sc16is7xx [v0.4]

I left out some relevant functions (sc16is7xx_port_read(), sc16is7xx_port_write(), sc16is7xx_port_update()) in my previous email... On Mon, 10 Mar 2014, Alexander Shiyan wrote: > Понедельник, 10 марта 2014, 7:50 -04:00 от Jon Ringle : > > > > On Mon, 10 Mar 2014, Alexander Sh

Re: [PATCH] RFC: WIP: sc16is7xx [v0.4]

On Mon, 10 Mar 2014, Alexander Shiyan wrote: > Понедельник, 10 марта 2014, 7:50 -04:00 от Jon Ringle : > > > > On Mon, 10 Mar 2014, Alexander Shiyan wrote: > > > > > Понедельник, 10 марта 2014, 2:26 -04:00 от j...@ringle.org: > > > > F

Re: [PATCH] RFC: WIP: sc16is7xx [v0.4]

On Mon, 10 Mar 2014, Alexander Shiyan wrote: Понедельник, 10 марта 2014, 7:50 -04:00 от Jon Ringle j...@ringle.org: On Mon, 10 Mar 2014, Alexander Shiyan wrote: Понедельник, 10 марта 2014, 2:26 -04:00 от j...@ringle.org: From: Jon Ringle jrin...@gridpoint.com ... +config

Re: [PATCH] RFC: WIP: sc16is7xx [v0.4]

I left out some relevant functions (sc16is7xx_port_read(), sc16is7xx_port_write(), sc16is7xx_port_update()) in my previous email... On Mon, 10 Mar 2014, Alexander Shiyan wrote: Понедельник, 10 марта 2014, 7:50 -04:00 от Jon Ringle j...@ringle.org: On Mon, 10 Mar 2014, Alexander Shiyan

Re: [PATCH] RFC: WIP: sc16is7xx [v0.4]

On Mon, 10 Mar 2014, Alexander Shiyan wrote: > Понедельник, 10 марта 2014, 2:26 -04:00 от j...@ringle.org: > > From: Jon Ringle > ... > > +config SERIAL_SC16IS7XX > > + tristate "SC16IS7xx RS485 serial support" > > + select SERIAL

Re: [PATCH] RFC: WIP: sc16is7xx [v0.4]

On Mon, 10 Mar 2014, Alexander Shiyan wrote: Понедельник, 10 марта 2014, 2:26 -04:00 от j...@ringle.org: From: Jon Ringle jrin...@gridpoint.com ... +config SERIAL_SC16IS7XX + tristate SC16IS7xx RS485 serial support + select SERIAL_CORE + default n + help

Re: [PATCH] Add option to build with -O3

On Wed, 5 Mar 2014, Greg KH wrote: > On Tue, Mar 04, 2014 at 07:01:49PM -0500, Jon Ringle wrote: > > +config CC_OPTIMIZE_FOR_SPEED > > +bool "Optimze for speed (-O3)" > > +help > > + Enabling this option will pass "-O3" to gcc > &

Re: [PATCH] Add option to build with -O3

On Wed, 5 Mar 2014, Greg KH wrote: > On Wed, Mar 05, 2014 at 12:37:56AM -0500, Jon Ringle wrote: > > The information contained in this transmission may contain confidential > > information. If the reader of this message is not the intended recipient, > > you are her

Re: [PATCH] Add option to build with -O3

On Wed, 5 Mar 2014, Greg KH wrote: > On Tue, Mar 04, 2014 at 07:01:49PM -0500, Jon Ringle wrote: > > +config CC_OPTIMIZE_FOR_SPEED > > +bool "Optimze for speed (-O3)" > > +help > > + Enabling this option will pass "-O3" to gcc > &

[PATCH] Add option to build with -O3

Signed-off-by: Jon Ringle --- Makefile | 2 ++ init/Kconfig | 19 --- 2 files changed, 18 insertions(+), 3 deletions(-) diff --git a/Makefile b/Makefile index 78209ee..e7f0b3c 100644 --- a/Makefile +++ b/Makefile @@ -581,6 +581,8 @@ all: vmlinux ifdef

[PATCH v2] touchscreen: tps6507x-ts: only poll while touch event is occurring

We only need to poll for touch events after an interrupt occurs due to the user touching the screen. We continue to poll until the user stops touching the screen Signed-off-by: Jon Ringle --- drivers/input/touchscreen/tps6507x-ts.c | 188 +--- include/linux/input

[PATCH] touchscreen: tps6507x-ts: only poll while touch event is occurring

We only need to poll for touch events after an interrupt occurs due to the user touching the screen. We continue to poll until the user stops touching the screen Signed-off-by: Jon Ringle --- drivers/input/touchscreen/tps6507x-ts.c | 191 +--- include/linux/mfd

Re: Fwd: Ethernet controller not starting

On Tue, Mar 4, 2014 at 9:06 AM, Christian Riesch wrote: > Hi Jon, > > [Now also cc'ed Prabhakar Lad] > > > --On March 04, 2014 07:34 -0500 Jon Ringle wrote: > >> On Tue, Mar 4, 2014 at 4:06 AM, Christian Riesch >> wrote: >>> >&

Fwd: Ethernet controller not starting

On Tue, Mar 4, 2014 at 4:06 AM, Christian Riesch wrote: > [cc'ed netdev and davinci-linux-open-source] > > > --On March 03, 2014 19:39 -0500 Jon Ringle wrote: > >> On Mon, Mar 3, 2014 at 6:43 PM, Rafael J. Wysocki >> wrote: >>> >>> On Monday

Fwd: Ethernet controller not starting

On Tue, Mar 4, 2014 at 4:06 AM, Christian Riesch christian.rie...@omicron.at wrote: [cc'ed netdev and davinci-linux-open-source] --On March 03, 2014 19:39 -0500 Jon Ringle j...@ringle.org wrote: On Mon, Mar 3, 2014 at 6:43 PM, Rafael J. Wysocki r...@rjwysocki.net wrote: On Monday, March

Re: Fwd: Ethernet controller not starting

On Tue, Mar 4, 2014 at 9:06 AM, Christian Riesch christian.rie...@omicron.at wrote: Hi Jon, [Now also cc'ed Prabhakar Lad] --On March 04, 2014 07:34 -0500 Jon Ringle j...@ringle.org wrote: On Tue, Mar 4, 2014 at 4:06 AM, Christian Riesch christian.rie...@omicron.at wrote: [cc'ed netdev

[PATCH] touchscreen: tps6507x-ts: only poll while touch event is occurring

We only need to poll for touch events after an interrupt occurs due to the user touching the screen. We continue to poll until the user stops touching the screen Signed-off-by: Jon Ringle jrin...@gridpoint.com --- drivers/input/touchscreen/tps6507x-ts.c | 191

[PATCH v2] touchscreen: tps6507x-ts: only poll while touch event is occurring

We only need to poll for touch events after an interrupt occurs due to the user touching the screen. We continue to poll until the user stops touching the screen Signed-off-by: Jon Ringle jrin...@gridpoint.com --- drivers/input/touchscreen/tps6507x-ts.c | 188

[PATCH] Add option to build with -O3

Signed-off-by: Jon Ringle jrin...@gridpoint.com --- Makefile | 2 ++ init/Kconfig | 19 --- 2 files changed, 18 insertions(+), 3 deletions(-) diff --git a/Makefile b/Makefile index 78209ee..e7f0b3c 100644 --- a/Makefile +++ b/Makefile @@ -581,6 +581,8 @@ all: vmlinux ifdef

Re: [PATCH] Add option to build with -O3

On Wed, 5 Mar 2014, Greg KH wrote: On Tue, Mar 04, 2014 at 07:01:49PM -0500, Jon Ringle wrote: +config CC_OPTIMIZE_FOR_SPEED +bool Optimze for speed (-O3) +help + Enabling this option will pass -O3 to gcc + resulting in a larger kernel (but possibly faster

Re: [PATCH] Add option to build with -O3

On Wed, 5 Mar 2014, Greg KH wrote: On Wed, Mar 05, 2014 at 12:37:56AM -0500, Jon Ringle wrote: The information contained in this transmission may contain confidential information. If the reader of this message is not the intended recipient, you are hereby notified that any review

Re: [PATCH] Add option to build with -O3

On Wed, 5 Mar 2014, Greg KH wrote: On Tue, Mar 04, 2014 at 07:01:49PM -0500, Jon Ringle wrote: +config CC_OPTIMIZE_FOR_SPEED +bool Optimze for speed (-O3) +help + Enabling this option will pass -O3 to gcc + resulting in a larger kernel (but possibly faster) Are you

Re: Ethernet controller not starting

On Mon, Mar 3, 2014 at 6:43 PM, Rafael J. Wysocki wrote: > On Monday, March 03, 2014 02:41:01 PM Jon Ringle wrote: >> I'm working on porting an ARM board from linux-3.10 to linux-3.12 (now >> the latest LTS kernel). >> I found that Ethernet controller on the board no longer

Ethernet controller not starting

I'm working on porting an ARM board from linux-3.10 to linux-3.12 (now the latest LTS kernel). I found that Ethernet controller on the board no longer comes up on linux-3.12. I was able to bisect the issue I'm having to the following commit: > 45f0a85c8258741d11bda25c0a5669c06267204a is the

Ethernet controller not starting

I'm working on porting an ARM board from linux-3.10 to linux-3.12 (now the latest LTS kernel). I found that Ethernet controller on the board no longer comes up on linux-3.12. I was able to bisect the issue I'm having to the following commit: 45f0a85c8258741d11bda25c0a5669c06267204a is the

Re: Ethernet controller not starting

On Mon, Mar 3, 2014 at 6:43 PM, Rafael J. Wysocki r...@rjwysocki.net wrote: On Monday, March 03, 2014 02:41:01 PM Jon Ringle wrote: I'm working on porting an ARM board from linux-3.10 to linux-3.12 (now the latest LTS kernel). I found that Ethernet controller on the board no longer comes up

Re: scheduling while atomic and DEBUG_SPINLOCK_SLEEP

Arjan van de Ven wrote: On Tue, 2007-06-26 at 22:55 -0400, Jon Ringle wrote: Hello, Out of these two, the first one that is showing "in_atomic():1" seems more likely to me to be a potential cause of the "scheduling while atomic" dump. Does this logic seem reasona

Re: scheduling while atomic and DEBUG_SPINLOCK_SLEEP

Arjan van de Ven wrote: On Tue, 2007-06-26 at 22:55 -0400, Jon Ringle wrote: Hello, Out of these two, the first one that is showing in_atomic():1 seems more likely to me to be a potential cause of the scheduling while atomic dump. Does this logic seem reasonable? Are there other debugging

scheduling while atomic and DEBUG_SPINLOCK_SLEEP

Hello, I am sometimes getting the following "scheduling while atomic" dump: [42949427.37] scheduling while atomic: sh/0x0002/144 [42949427.38] [] (dump_stack+0x0/0x14) from [] (schedule+0x628/0x6c8) [42949427.39] [] (schedule+0x0/0x6c8) from [] (__down_read+0xc4/0x128)

scheduling while atomic and DEBUG_SPINLOCK_SLEEP

Hello, I am sometimes getting the following scheduling while atomic dump: [42949427.37] scheduling while atomic: sh/0x0002/144 [42949427.38] [c0030370] (dump_stack+0x0/0x14) from [c029a868] (schedule+0x628/0x6c8) [42949427.39] [c029a240] (schedule+0x0/0x6c8) from [c029c92c]

scheduling while atomic on arm board.

Hello, I'm running Linux 2.6.16.29 on an ixp455 based board (arm). On rare occasions, I am seeing the following stack dump, which gets resolved only when a power cycle is done. Does anyone have any suggestions on what to look for? Thanks, Jon [42949427.37] scheduling while atomic:

scheduling while atomic on arm board.

Hello, I'm running Linux 2.6.16.29 on an ixp455 based board (arm). On rare occasions, I am seeing the following stack dump, which gets resolved only when a power cycle is done. Does anyone have any suggestions on what to look for? Thanks, Jon [42949427.37] scheduling while atomic:

tiny tty driver sample

Hello, I'm trying to write a tty driver and I'm using http://lwn.net/images/pdf/LDD3/ch18.pdf as a guide. The sample tiny tty driver includes the following code: for (i = 0; i < data_size; ++i) { if (tty->flip.count >= TTY_FLIPBUF_SIZE)

tiny tty driver sample

Hello, I'm trying to write a tty driver and I'm using http://lwn.net/images/pdf/LDD3/ch18.pdf as a guide. The sample tiny tty driver includes the following code: for (i = 0; i data_size; ++i) { if (tty-flip.count = TTY_FLIPBUF_SIZE)

RE: Reserving a fixed physical address page of RAM.

Fawad Lateef wrote: > reserving_bootmem in devicemaps_init will work but I think it > will be better if you do this in mem_init function (here: > http://sosdg.org/~coywolf/lxr/source/arch/arm/mm/init.c?v=2.6. > 16;a=arm#L620), > so that all the paging and other map related stuff completes.

RE: Reserving a fixed physical address page of RAM.

Jon Ringle wrote: > Fawad Lateef wrote: > > On 11/30/06, Jon Ringle <[EMAIL PROTECTED]> wrote: > > > Do you think that the following would work to properly > reserve the > > > memory. If it does, then I think I can just do a > ioremap(0x0000, &g

Re: Reserving a fixed physical address page of RAM.

Fawad Lateef wrote: > On 11/30/06, Jon Ringle <[EMAIL PROTECTED]> wrote: > > Fawad Lateef wrote: > > > Yes, this can be used if required physical-memory exists > in the last > > > part of RAM as if you use mem= then kernel will only use > > > memory

Re: Reserving a fixed physical address page of RAM.

Fawad Lateef wrote: On 11/30/06, Jon Ringle [EMAIL PROTECTED] wrote: Fawad Lateef wrote: Yes, this can be used if required physical-memory exists in the last part of RAM as if you use mem=xxxM then kernel will only use memory less than or equal-to xxxM and above can be used

RE: Reserving a fixed physical address page of RAM.

Jon Ringle wrote: Fawad Lateef wrote: On 11/30/06, Jon Ringle [EMAIL PROTECTED] wrote: Do you think that the following would work to properly reserve the memory. If it does, then I think I can just do a ioremap(0x0000, 0x1000) to obtain a virtual address. (Ofcourse I would

RE: Reserving a fixed physical address page of RAM.

Fawad Lateef wrote: reserving_bootmem in devicemaps_init will work but I think it will be better if you do this in mem_init function (here: http://sosdg.org/~coywolf/lxr/source/arch/arm/mm/init.c?v=2.6. 16;a=arm#L620), so that all the paging and other map related stuff completes. (CMIIW)

RE: Reserving a fixed physical address page of RAM.

linux-os (Dick Johnson) wrote: > On Mon, 27 Nov 2006, Jon Ringle wrote: > > > Robert Hancock wrote: > >> Jon Ringle wrote: > >>> Hi, > >>> > >>> I need to reserve a page of memory at a specific area of RAM that > >>>

RE: Reserving a fixed physical address page of RAM.

Jesper Juhl wrote: > On 28/11/06, Fawad Lateef <[EMAIL PROTECTED]> wrote: > > On 11/28/06, Dave Airlie <[EMAIL PROTECTED]> wrote: > > > On 11/28/06, Jon Ringle <[EMAIL PROTECTED]> wrote: > > > > > > It looks promising, however, I need to re

RE: Reserving a fixed physical address page of RAM.

Robert Hancock wrote: > Jon Ringle wrote: > > Robert Hancock wrote: > >> Jon Ringle wrote: > >>> Hi, > >>> > >>> I need to reserve a page of memory at a specific area of RAM that > >>> will be used as a "shared memory" wi

RE: Reserving a fixed physical address page of RAM.

Robert Hancock wrote: Jon Ringle wrote: Robert Hancock wrote: Jon Ringle wrote: Hi, I need to reserve a page of memory at a specific area of RAM that will be used as a shared memory with another processor over PCI. How can I ensure that the this area of RAM gets reseved so

RE: Reserving a fixed physical address page of RAM.

Jesper Juhl wrote: On 28/11/06, Fawad Lateef [EMAIL PROTECTED] wrote: On 11/28/06, Dave Airlie [EMAIL PROTECTED] wrote: On 11/28/06, Jon Ringle [EMAIL PROTECTED] wrote: snip It looks promising, however, I need to reserve a physical address area that is well known (so

RE: Reserving a fixed physical address page of RAM.

linux-os (Dick Johnson) wrote: On Mon, 27 Nov 2006, Jon Ringle wrote: Robert Hancock wrote: Jon Ringle wrote: Hi, I need to reserve a page of memory at a specific area of RAM that will be used as a shared memory with another processor over PCI. How can I ensure

Re: Reserving a fixed physical address page of RAM.

Robert Hancock wrote: Jon Ringle wrote: Hi, I need to reserve a page of memory at a specific area of RAM that will be used as a "shared memory" with another processor over PCI. How can I ensure that the this area of RAM gets reseved so that the Linux's memory management (kmalloc() a

Reserving a fixed physical address page of RAM.

Hi, I need to reserve a page of memory at a specific area of RAM that will be used as a "shared memory" with another processor over PCI. How can I ensure that the this area of RAM gets reseved so that the Linux's memory management (kmalloc() and friends) don't use it? Some things that I've

Reserving a fixed physical address page of RAM.

Hi, I need to reserve a page of memory at a specific area of RAM that will be used as a shared memory with another processor over PCI. How can I ensure that the this area of RAM gets reseved so that the Linux's memory management (kmalloc() and friends) don't use it? Some things that I've

Re: Reserving a fixed physical address page of RAM.

Robert Hancock wrote: Jon Ringle wrote: Hi, I need to reserve a page of memory at a specific area of RAM that will be used as a shared memory with another processor over PCI. How can I ensure that the this area of RAM gets reseved so that the Linux's memory management (kmalloc() and friends