36 bit DMA address on IBM 440 PPC

[Matt Porter]

On Mon, Mar 10, 2003 at 07:58:51PM -0500, Jeff Boyd wrote:
> Is it to be 64 bit, or will the ref be more abstract and come from an
> /asm/ architecture specific include? It seems to me that in general it
> would be better to make things that hold or return or take a physical
> address reference it as such (e.g. phys_addr_t) rather than declare it
> to be some data size (e.g. unsigned long [long]), since data bus and
> address bus sizes are not necessarily in sync for size. Thus my vote for
> a separate architecture specific data type for physical address.

The discussion on lkml suggested that Linus wants resources on all
platforms to be 64 bits, period.  Of course, the driving factor is
to handle some ia32 PAE management in a better manner.  One thing
to keep in mind is that resources are not necessarily a CPU physical
address (although most platforms define them as such), they are defined
as an 'ioremapable token'.  In the same manner, ioremap produces a
token which can be passed to read*/write*, in most implementations
that token is a virtual address which dereference directly (though
that is cheating the API).  One thing that makes a u64 resource
convenient is that there is no abstraction necessary to printk
info/warnings involving resource values.

Regards,
--
Matt Porter
porter at cox.net
This is Linux Country. On a quiet night, you can hear Windows reboot.

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