Skip to contentSkip to conversation

IN_BYTE and OUT_BYTE replacement

DISCUSSION Andrei Martynov 2 participants 2 messages Jul 9, 2009 libata

lore
Share & tools
lore
#0 lore raw

Hi,

there were specific i/o macros IN_BYTE and OUT_BYTE in 2.4 kernel to access IDE registers, but seems they are gone in 2.6 kernel and replaced by ioread8 / iowrite8 that are used everywhere and not in libata only. In my case original code for 2.4 kernel wrote specific value to undocumented chipset register on *every* r/w access to *any* IDE register.

#define OUT_BYTE(b,p) { outb(b,p); outb(255, JASPER_IDE_BASE + 0xe0); } static inline byte jasper_ide_in_byte(int p)

{
        byte b;
        b = (byte)inb(p);
        outb(255, JASPER_IDE_BASE + 0xe0);
        return b;
}

#define IN_BYTE(p) jasper_ide_in_byte(p)

Is there any way to reproduce this behavior in libata other than redefining ioread8/iowrite8?

Signature · 2 lines
Best regards,
 Andrei                          mailto:[email protected]
#1 lore raw
Quoted 2 lines

Is there any way to reproduce this behavior in libata other than redefining ioread8/iowrite8?

For the cases where hardware so far has needed this there are higher level abstractions. It depends what cases the jasper h/w needs it for.

If you are using the SFF taskfile style interface then

	->sff_dev_select
	->sff_tf_load
	->sff_tf_read
	->sff_exec_command
	->sff_check_status
	->sff_check_altstatus
	->sff_irq_clear
	->sff_data_xfer

And for DMA

	->bmdma_setup
	->bmdma_start
	->bmdma_stop
	->bmdma_status

which are mostly just I/O operations.

Abstracting at this higher level helps performance by avoiding huge numbers of indirect function calls through pointers.

However the reset logic isn't cleanly separated so might need a bit of work if that is a problem.

It's hard to tell without more info whether they do the write on every access because they can't just do it on the ones that need it or because they need to do it each time.