Sunday 01 February 2009 18:13:17 Bartlomiej Zolnierkiewicz napisał(a): > > I have some doubts about things pointed out by Alan - atomic access. > > Due to flipping 8/16 bit in this driver, all functions accessing task file > > and data register should do things atomically. If for example > > tp_ops->input_data() will be braked by interrupt and any other function > > accessing task file will be called very bad things can happen. > > All taskfile / data access is atomic, the only exception is [Alt]Status > register read if shared IRQs are used (which doesn't seem to be the case > with AT91) or if the hardware is flaky and unexpected IRQs can happen... > > If 8/16-bit flipping is really an issue then AT91 IRQ handler may need > to save info about current mode on entry, switch to 8-bit (if in 16-bit > mode), restore the saved mode on exit (if it was 16-bit mode). I think we don't need it because we don't use shared interrupts. Moreover hardware allow to Altarnate Status register be accessed in both 8 and 16 bit modes. > > If I use IDE_HFLAG_UNMASK_IRQS IDE layer will assure atomic > > access to ATA registers ? > > IDE_HFLAG_UNMASK_IRQS allows other IRQs to be serviced while IDE IRQ > is being serviced so really no problem here (unless some other drivers > also mess with 8/16-bit flipping but if so then the current code needs > fixing too). We have exclusive access to Static Memory Controller registers as long as there are no bug in board specific code. So no problem here either. Stanislaw Gruszka -- To unsubscribe from this list: 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