Am 11.11.2010 um 20:07 schrieb Alexander Graf:
On 11.11.2010, at 19:33, Blue Swirl blauwirbel@gmail.com wrote:
On Thu, Nov 11, 2010 at 6:21 PM, Andreas Färber <andreas.faerber@web.de
wrote: Am 11.11.2010 um 08:39 schrieb Alexander Graf:
On 11.11.2010, at 00:01, Andreas Färber andreas.faerber@web.de wrote:
Am 30.10.2010 um 21:51 schrieb Andreas Färber:
diff --git a/include/arch/ppc/io.h b/include/arch/ppc/io.h index e5180f2..84198f2 100644 --- a/include/arch/ppc/io.h +++ b/include/arch/ppc/io.h
+static inline void insw(phys_addr_t port, void *buf, int ns) +{
- _insw((uint16_t *)(port + isa_io_base), buf, ns);
+}
I'm wondering whether the use of phys_addr_t is right here or whether it should be uintptr_t? Would like to get this out of my queue.
PIO only defines 16 bit number of ports anyways, no?
If you say so. :) I'll try uint16_t then. We'll either need to upcast isa_io_base from uint32_t then or change that variable in qemu/ init.c(?) to either phys_addr_t or uintptr_t...
Do we want to consider a phys_addr_t an address where devices are located, whether accessed through MMU or real mode, or is phys_addr_t just supposed to be the MMU counterpart to the effective address? If the latter, do we need a new addr_t type or something or is uintptr_t the type to use since we want to cast it to pointer ultimately?
I'm not sure about PPC terminology, but on Sparc the physical address space (if not mapped by MMU) can be accessed only with special alternate loads or stores. This is what Sparc64 IO macros do.
This seems different from ppc.
If an area is mapped it can be accessed with pointer dereference, then a pointer type or uintptr_t would be correct.
Any reason we can't just make it void*
The reason for address types elsewhere (e.g., Haiku) is that offsets are easier to calculate with non-pointer types (a + b vs. (sometype*)a + bdependingontype). I'd prefer uintptr_t then.
and map it for real where necessary?
We could use void* but please don't rely on MMU mappings. As mentioned before, we need to support real mode too and the weird ROM-into-RAM mapping via ISI/DSI is problematic enough already. (Any particular reason there's no real OF-visible MMU translation btw?)
Andreas