On Fri, Feb 20, 2009 at 6:12 PM, Bartlomiej Zolnierkiewicz
<[email protected]> wrote:
> From: Bartlomiej Zolnierkiewicz <[email protected]>
> Subject: [PATCH] ide: destroy DMA mappings after ending DMA
>
> Move ide_destroy_dmatable() call out from ->dma_end method to
> {ide_pc,cdrom_newpc,ide_dma}_intr(), ide_dma_timeout_retry()
> and sgiioc4_resetproc().
...
> --- a/drivers/ide/ide-dma-sff.c
> +++ b/drivers/ide/ide-dma-sff.c
> @@ -310,8 +310,6 @@ int ide_dma_end(ide_drive_t *drive)
> /* clear INTR & ERROR bits */
> ide_dma_sff_write_status(hwif, dma_stat | ATA_DMA_ERR | ATA_DMA_INTR);
>
> - /* purge DMA mappings */
> - ide_destroy_dmatable(drive);
> wmb();
Bartlomiej,
I think the wmb() could removed as well. The outb/writeb functions are
required to be strongly ordered and I don't see anything else touching
DMA-able memory here.
BTW, care to remove "mask" usage from this function?
It's really not needed (can be replaced with #define).
I can create separate patches for both. Which git tree should I base
them against?
...
> --- a/drivers/ide/scc_pata.c
> +++ b/drivers/ide/scc_pata.c
> @@ -365,8 +365,6 @@ static int __scc_dma_end(ide_drive_t *dr
> dma_stat = scc_dma_sff_read_status(hwif);
> /* clear the INTR & ERROR bits */
> scc_ide_outb(dma_stat | 6, hwif->dma_base + 4);
> - /* purge DMA mappings */
> - ide_destroy_dmatable(drive);
> /* verify good DMA status */
> wmb();
I think this wmb() can be removed too.
....
> --- a/drivers/ide/tx4939ide.c
> +++ b/drivers/ide/tx4939ide.c
> @@ -335,11 +335,9 @@ static int tx4939ide_dma_end(ide_drive_t
> /* read and clear the INTR & ERROR bits */
> dma_stat = tx4939ide_clear_dma_status(base);
>
> - /* purge DMA mappings */
> - ide_destroy_dmatable(drive);
> - /* verify good DMA status */
> wmb();
and this one as well.
hth,
grant
Hi,
On Saturday 14 March 2009, Grant Grundler wrote:
> On Fri, Feb 20, 2009 at 6:12 PM, Bartlomiej Zolnierkiewicz
> <[email protected]> wrote:
> > From: Bartlomiej Zolnierkiewicz <[email protected]>
> > Subject: [PATCH] ide: destroy DMA mappings after ending DMA
> >
> > Move ide_destroy_dmatable() call out from ->dma_end method to
> > {ide_pc,cdrom_newpc,ide_dma}_intr(), ide_dma_timeout_retry()
> > and sgiioc4_resetproc().
> ...
> > --- a/drivers/ide/ide-dma-sff.c
> > +++ b/drivers/ide/ide-dma-sff.c
> > @@ -310,8 +310,6 @@ int ide_dma_end(ide_drive_t *drive)
> > /* clear INTR & ERROR bits */
> > ide_dma_sff_write_status(hwif, dma_stat | ATA_DMA_ERR | ATA_DMA_INTR);
> >
> > - /* purge DMA mappings */
> > - ide_destroy_dmatable(drive);
> > wmb();
>
> Bartlomiej,
> I think the wmb() could removed as well. The outb/writeb functions are
> required to be strongly ordered and I don't see anything else touching
> DMA-able memory here.
Indeed. IIRC this code precedes the requeirement for outb/writeb to be
strongly ordered.
Seems like wmb() in ide_dma_start() is also superfluous nowadays...
> BTW, care to remove "mask" usage from this function?
> It's really not needed (can be replaced with #define).
Feel free to remove it. :)
> I can create separate patches for both. Which git tree should I base
> them against?
linux-next git tree
(or pata-2.6 quilt tree)
> ...
> > --- a/drivers/ide/scc_pata.c
> > +++ b/drivers/ide/scc_pata.c
> > @@ -365,8 +365,6 @@ static int __scc_dma_end(ide_drive_t *dr
> > dma_stat = scc_dma_sff_read_status(hwif);
> > /* clear the INTR & ERROR bits */
> > scc_ide_outb(dma_stat | 6, hwif->dma_base + 4);
> > - /* purge DMA mappings */
> > - ide_destroy_dmatable(drive);
> > /* verify good DMA status */
> > wmb();
>
> I think this wmb() can be removed too.
>
> ....
> > --- a/drivers/ide/tx4939ide.c
> > +++ b/drivers/ide/tx4939ide.c
> > @@ -335,11 +335,9 @@ static int tx4939ide_dma_end(ide_drive_t
> > /* read and clear the INTR & ERROR bits */
> > dma_stat = tx4939ide_clear_dma_status(base);
> >
> > - /* purge DMA mappings */
> > - ide_destroy_dmatable(drive);
> > - /* verify good DMA status */
> > wmb();
>
> and this one as well.
Seems so but please cc: scc_pata & tx4939 maintainers on your patch.
Thanks,
Bart
On Sat, Mar 14, 2009 at 8:51 PM, Bartlomiej Zolnierkiewicz
<[email protected]> wrote:
...
>> I can create separate patches for both. Which git tree should I base
>> them against?
>
> linux-next git tree
> (or pata-2.6 quilt tree)
I've not used quilt yet and can only deal with git in a very crude way.
Thanks for the references!
....
> Seems so but please cc: scc_pata & tx4939 maintainers on your patch.
Yes, will do!
thanks,
grant
On Sat, 2009-03-14 at 21:45 +0100, Grant Grundler wrote:
> On Sat, Mar 14, 2009 at 8:51 PM, Bartlomiej Zolnierkiewicz
> <[email protected]> wrote:
> ...
> >> I can create separate patches for both. Which git tree should I base
> >> them against?
> >
> > linux-next git tree
> > (or pata-2.6 quilt tree)
>
> I've not used quilt yet and can only deal with git in a very crude way.
> Thanks for the references!
Have no fear ... you just rsync the quilt to a directory (~/pata_quilt
or something) on any server (use rsync so you only pick up the diffs
next time around) and then do
git quiltimport --patches ~/pata_quilt
and voila: a git tree ... of course it's a new one, and it's much harder
to handle incremental quilts (quilts that just have an extra few patches
added) since git rebuilds the entire tree with a different commitid for
each patch every time.
James