Re: [PATCH] trm290: do hook dma_host_{on,off} methods (take 2)

2007-12-28 Thread Sergei Shtylyov
Hello. Bartlomiej Zolnierkiewicz wrote: Using default methods caused the chip's DMA PRD count registers, inadvertently starting DMA! While fixing it, also do: nasty, this could possibly explain the following trm290.c hack: Frankly speaking, I'm not sure it's that destructive: the

[PATCH] trm290: do hook dma_host_{on,off} methods (take 2)

2007-12-27 Thread Sergei Shtylyov
Using default methods caused the chip's DMA PRD count registers, inadvertently starting DMA! While fixing it, also do: - get rid of the 'ide_' prefixes in several functions for which the prefix in the method's name has been 'ide_' ectomized already; - align the code hooking the IDE DMA

Re: [PATCH] trm290: do hook dma_host_{on,off} methods (take 2)

2007-12-27 Thread Bartlomiej Zolnierkiewicz
On Thursday 27 December 2007, Sergei Shtylyov wrote: Using default methods caused the chip's DMA PRD count registers, inadvertently starting DMA! While fixing it, also do: nasty, this could possibly explain the following trm290.c hack: ... #if 0 /* play it safe for now */

[PATCH] trm290: do hook dma_host_{on,off} methods

2007-12-26 Thread Sergei Shtylyov
Those two methods were reading/writing TRM-290 config. register; luckily (?) the writes only tried to change undefined bits. While fixing this, also - get rid of the 'ide_' prefixes in several functions for which the prefix has been ectomized before; - align the code initializing methods in

Re: [PATCH] trm290: do hook dma_host_{on,off} methods

2007-12-26 Thread Sergei Shtylyov
Hello, I wrote: Those two methods were reading/writing TRM-290 config. register; luckily (?) the writes only tried to change undefined bits. Actually, the writes were falling at the PRD address register. Well, nobody noticed anyway... :-) MBR, Sergei - To unsubscribe from this list: