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

Alexander Graf agraf at suse.de
Thu Nov 11 22:15:30 CET 2010


On 11.11.2010, at 20:59, Andreas Färber <andreas.faerber at web.de> wrote:

> 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?)

Well I was talking about isa_io_base. Port would still be uint16_t.

Alex

> 



More information about the OpenBIOS mailing list