outb_p(0xc, 0x3f2) with _IO_BASE remapped!

outb_p(0xc, 0x3f2) with _IO_BASE remapped!

[Paolo Scaffardi]

I discovered that my kernel hangs into 'drivers/block/ll_rw_blk.c', in
function 'blk_dev_init', at the instruction outb_p(0xc, 0x3f2), if i remap
_IO_BASE to 0xfe0000000 (to use m8xx_pcmcia).

I think that this instruction simply wrote something to the memory (if
_IO_BASE was 0 and wasn't ioremapped), but now it shouldn't do nothing
(nothing is at that address).

But why is it needed? What is supposed to do that instruction? Why not
writing that value to the memory instead of using outb_p instruction?

This is really a problem to me... i need to remap _IO_BASE to use
m8xx_pcmcia!

- may the pinguin b with u -

Have a nice day,
Paolo Scaffardi.
AIRVENT SAM s.p.a. - RIMINI - ITALY


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: outb_p(0xc, 0x3f2) with _IO_BASE remapped!

[Dan Malek]

Paolo Scaffardi wrote:
>
> I discovered that my kernel hangs into 'drivers/block/ll_rw_blk.c', in
> function 'blk_dev_init', at the instruction outb_p(0xc, 0x3f2),

Hmmm...There should be an #ifdef around that to ensure it isn't done
on PowerPC platforms.  In later kernels, it is just #ifdef CONFIG_x86.
What kernel are you using?

> This is really a problem to me... i need to remap _IO_BASE to use
> m8xx_pcmcia!

Well, this is a specific example of a bunch of ranting I did recently
on the linuxppc-dev list about providing a much better I/O interface
(it was a PCI discussion, but would have fixed all of this too).
Unfortunately, for embedded systems it looks like we are just going
to have to hack code privately to get the configurations we need.
There are lots of mapping challenges because of implied address maps
that appear on workstations.  We will get there.....

> - may the pinguin b with u -

...and also with you...


	-- Dan

--

	I like MMUs because I don't have a real life.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/