On 3/27/06, Sergei Shtylylov <sshtylyov@xxxxxxxxxxxxx> wrote: > Hello. > > Bartlomiej Zolnierkiewicz wrote: > > >>>On 3/27/06, Sergei Shtylylov <sshtylyov@xxxxxxxxxxxxx> wrote: > > [skipped] > > >>>>>>- release the same number of DMA I/O ports that was requested by a driver > > >>>>>please fix trm290.c to use ->mmio == 2 instead > > >>>> It's a _really_ old chipset (pre SFF-8038i) and has _no_ memory mapped > >>>>regs AFAIK... > > >>>->mmio == 2 means _only_ that host driver is responsible > >>>for reserving/releasing resources - it doesn't mean that host driver > >>>is using MMIO (a bit confusing but this is what the current code does) > > >> So, your point is that ide_setup_dma() should _never_ do anything for the > >>(mmio == 2) case? Maybe it shouldn't even be called? I guess we surely need > > > No, my point is that for ->mmio == 2 core code may not try to manage > > IO or MMIO resources, only that. > > Note that I didn't try to. :-) > Your 1st NAK was because I moved ide_release_dma_engine() above that Yes. > (mmio == 2) check in ide_release_dma() -- which as we've now concluded is > perfectly correct, isn't it? Hmm, yes... Stupid me, sorry for that. > > ide_setup_dma() call is still needed for calling ide_allocate_dma_engine() > > Er, looking at sgiioc4.c, I somewhat doubt it -- since that driver > allocates DMA engine of the _different_ size all by itself... > However, the driver cleanup function might be called just before releasing > the engine in ide-dma.c, so this approach sounds reasonable. :-) > > > and setting up ->dma_* / ->ide_dma_* fields. > > Yeah, it seems I've forgotten about them a bit... :-) > > [skipped] > > Another question: ide_setup_dma() is not supposed to be called by non-PCI > driver, yes? Yes, this was discussed some time ago on linux-ide. > It's just I know one (not in the community yet) that does... :-/ AFAIR there was one mips specific driver, but not in the tree => not mine problem... 8) Bartlomiej - : send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
