consistent_alloc() on PPC

consistent_alloc() on PPC

[Sachin P]

Hi , 
I am facing some problems porting my drivers to the PPC platform . Am
currently using consistent_alloc() and consistent_free() to
allocate/free (non-cached) DMA ble memory.
Is there any function/patch/macro, equivalent to
phy_to_virt()/virt_to_phy() for memory returned by consistent_alloc()?

Regards
sachin

Re: consistent_alloc() on PPC

[Jörn Engel]

On Wed, 19 January 2005 17:23:42 +0530, Sachin P wrote:
> 
> I am facing some problems porting my drivers to the PPC platform . Am
> currently using consistent_alloc() and consistent_free() to
> allocate/free (non-cached) DMA ble memory.
> Is there any function/patch/macro, equivalent to
> phy_to_virt()/virt_to_phy() for memory returned by consistent_alloc()?

Imo not.  I ended up writing a private version of it, along these
lines:

static inline unsigned long private_io_to_bus(void *addr)
{
        return iopa((unsigned long)addr) + offset;
}

Wouldn't hurt if you could generalize it somehow.

Jörn

-- 
Everything should be made as simple as possible, but not simpler.
-- Albert Einstein

consistent_alloc() on PPC

[Sachin P]

Hi , 
I am facing some problems porting my drivers to the PPC platform . Am
currently using consistent_alloc() and consistent_free() to
allocate/free (non-cached) DMA ble memory.
Is there any function/patch/macro, equivalent to
phy_to_virt()/virt_to_phy() for memory returned by consistent_alloc()?

Regards
sachin

Re: consistent_alloc() on PPC

[Matt Porter]

On Wed, Jan 19, 2005 at 05:23:17PM +0530, Sachin P wrote:
> Hi , 
> I am facing some problems porting my drivers to the PPC platform . Am
> currently using consistent_alloc() and consistent_free() to
> allocate/free (non-cached) DMA ble memory.
> Is there any function/patch/macro, equivalent to
> phy_to_virt()/virt_to_phy() for memory returned by consistent_alloc()?

iopa()

-Matt

Re: consistent_alloc() on PPC

[Christoph Hellwig]

On Wed, Jan 19, 2005 at 05:23:17PM +0530, Sachin P wrote:
> Hi , 
> I am facing some problems porting my drivers to the PPC platform . Am
> currently using consistent_alloc() and consistent_free() to
> allocate/free (non-cached) DMA ble memory.
> Is there any function/patch/macro, equivalent to
> phy_to_virt()/virt_to_phy() for memory returned by consistent_alloc()?

Don't ever use concistant_alloc directly.  Always use
dma_alloc_coherent() which will give you both virtual and bus address.

Re: consistent_alloc() on PPC

[Matt Porter]

On Wed, Jan 19, 2005 at 03:10:48PM +0100, Christoph Hellwig wrote:
> On Wed, Jan 19, 2005 at 05:23:17PM +0530, Sachin P wrote:
> > Hi , 
> > I am facing some problems porting my drivers to the PPC platform . Am
> > currently using consistent_alloc() and consistent_free() to
> > allocate/free (non-cached) DMA ble memory.
> > Is there any function/patch/macro, equivalent to
> > phy_to_virt()/virt_to_phy() for memory returned by consistent_alloc()?
> 
> Don't ever use concistant_alloc directly.  Always use
> dma_alloc_coherent() which will give you both virtual and bus address.

He's obviously not talking about 2.6 since he's mentioning
consistent_alloc().  I removed those PPC-specific APIs when I
updated our DMA API implementation in 2.6.

-Matt

Re: consistent_alloc() on PPC

[Sachin P]

Hi,
Thanks a lot to all of you for the help . 
The following is a more clearer version of the problem I am facing :

1.I am porting drivers from X86 (running Linux 2.4-20) to 
  PPC platform running (Montevista Linux-2.4.20).
2.In  wrapper function for DMA allocation, I am using 
  consistent_alloc() to allocate the memory. This function gives me
  both the virtual-address as well as the dma-address.
  I pass both these values to the upper-level drivers.
3. However , once the upper-level drivers are done with the memory
   they call the wrapper function for free dma and pass only the dma
   address and not the virtual-address. However consistent_free() 
   accepts only virtual-address. 
   Hence I need a way to convert the dma address to the
   virtual-address.  

Regards
sachin


On Wed, 19 Jan 2005 07:56:03 -0700, Matt Porter
<mporter@kernel.crashing.org> wrote:
> On Wed, Jan 19, 2005 at 03:10:48PM +0100, Christoph Hellwig wrote:
> > On Wed, Jan 19, 2005 at 05:23:17PM +0530, Sachin P wrote:
> > > Hi ,
> > > I am facing some problems porting my drivers to the PPC platform . Am
> > > currently using consistent_alloc() and consistent_free() to
> > > allocate/free (non-cached) DMA ble memory.
> > > Is there any function/patch/macro, equivalent to
> > > phy_to_virt()/virt_to_phy() for memory returned by consistent_alloc()?
> >
> > Don't ever use concistant_alloc directly.  Always use
> > dma_alloc_coherent() which will give you both virtual and bus address.
> 
> He's obviously not talking about 2.6 since he's mentioning
> consistent_alloc().  I removed those PPC-specific APIs when I
> updated our DMA API implementation in 2.6.
> 
> -Matt
>

Re: consistent_alloc() on PPC

[Matt Porter]

On Thu, Jan 20, 2005 at 10:00:47PM +0530, Sachin P wrote:
> Hi,
> Thanks a lot to all of you for the help . 
> The following is a more clearer version of the problem I am facing :
> 
> 1.I am porting drivers from X86 (running Linux 2.4-20) to 
>   PPC platform running (Montevista Linux-2.4.20).
> 2.In  wrapper function for DMA allocation, I am using 
>   consistent_alloc() to allocate the memory. This function gives me
>   both the virtual-address as well as the dma-address.
>   I pass both these values to the upper-level drivers.
> 3. However , once the upper-level drivers are done with the memory
>    they call the wrapper function for free dma and pass only the dma
>    address and not the virtual-address. However consistent_free() 
>    accepts only virtual-address. 
>    Hence I need a way to convert the dma address to the
>    virtual-address.  

All you need to do is cache the virtual address and the dma/phys
address for later use when calling consistent_free(). converting
random DMA/phys to virtual is a bad idea since you are going to
find multiple mappings. Cache the results in your driver...it's
trivial.

-Matt