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

[Andreas Färber]

Am 11.11.2010 um 20:07 schrieb Alexander Graf:

> On 11.11.2010, at 19:33, Blue Swirl <blauwirbel at gmail.com> wrote:
>
>> 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.

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