[OpenBIOS] [PATCH] ppc: Convert IO macros to inline functions

[Blue Swirl]

On Thu, Nov 11, 2010 at 6:21 PM, Andreas Färber <andreas.faerber at 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 at 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.

If an area is mapped it can be accessed with pointer dereference, then
a pointer type or uintptr_t would be correct.