new dma API questions

new dma API questions

[Pantelis Antoniou]

Hi there.

I have a few questions regarding the new DMA API.

1. dma_map_single finally calls virt_to_bus, which is simplified
   to:
      return (unsigned long)address - KERNELBASE + PCI_DRAM_OFFSET;

   PCI_DRAM_OFFSET is defined to be pci_dram_offset.
   Typically it is set be 0 for most arches without pci.
   How could we overide it with a constant 0 so that we avoid the
   memory access?

2. How soon in the init sequence could we call dma_alloc_consistent?
   For example when setting up a serial console on 8xx I need memory
   for the fifos, and I have to revert in using m8xx_hostalloc which
   IMO should be already dead.

   If we could arrange for consistent_alloc to be able to operate with
   a fixed memory area until the memory initialization is complete
   it would make my life much easier and we could finally kill
   m8xx_hostalloc & friends.

3. The first argument is dma_* function is a struct device.
   When working with network devices I must set this to NULL.
   Granted this is no problem right now, but could this be
   a problem in the future?

Regards

Pantelis


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

Re: new dma API questions

[Dan Malek]

On Jun 3, 2004, at 5:06 AM, Pantelis Antoniou wrote:


> 1. dma_map_single finally calls virt_to_bus, which is simplified
>   to:
>      return (unsigned long)address - KERNELBASE + PCI_DRAM_OFFSET;
>
>   PCI_DRAM_OFFSET is defined to be pci_dram_offset.
>   Typically it is set be 0 for most arches without pci.

It's typically set to zero for all architectures.

>   How could we overide it with a constant 0 so that we avoid the
>   memory access?

What memory access?

> 2. How soon in the init sequence could we call dma_alloc_consistent?

Not soon enough.

>   For example when setting up a serial console on 8xx I need memory
>   for the fifos, and I have to revert in using m8xx_hostalloc which
>   IMO should be already dead.

As you pointed out, that is going to have to stay for a while.  The
CPM and peripherals must do DMA long before the generic
supporting functions are ready.

>   If we could arrange for consistent_alloc to be able to operate with
>   a fixed memory area until the memory initialization is complete
>   it would make my life much easier and we could finally kill
>   m8xx_hostalloc & friends.

I don't think it is worth the complication.


	-- Dan


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

Re: new dma API questions

[Pantelis Antoniou]

Dan Malek wrote:

>
> On Jun 3, 2004, at 5:06 AM, Pantelis Antoniou wrote:
>
>
>> 1. dma_map_single finally calls virt_to_bus, which is simplified
>>   to:
>>      return (unsigned long)address - KERNELBASE + PCI_DRAM_OFFSET;
>>
>>   PCI_DRAM_OFFSET is defined to be pci_dram_offset.
>>   Typically it is set be 0 for most arches without pci.
>
>
> It's typically set to zero for all architectures.
>
>>   How could we overide it with a constant 0 so that we avoid the
>>   memory access?
>
>
> What memory access?
>
Oops, correct :)

>> 2. How soon in the init sequence could we call dma_alloc_consistent?
>
>
> Not soon enough.
>
>>   For example when setting up a serial console on 8xx I need memory
>>   for the fifos, and I have to revert in using m8xx_hostalloc which
>>   IMO should be already dead.
>
>
> As you pointed out, that is going to have to stay for a while.  The
> CPM and peripherals must do DMA long before the generic
> supporting functions are ready.
>
>>   If we could arrange for consistent_alloc to be able to operate with
>>   a fixed memory area until the memory initialization is complete
>>   it would make my life much easier and we could finally kill
>>   m8xx_hostalloc & friends.
>
>
> I don't think it is worth the complication.
>
Let me work on it a bit...

>
>     -- Dan
>
>
>
Regards

Pantelis


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

Re: new dma API questions

[Tom Rini]

On Thu, Jun 03, 2004 at 12:06:29PM +0300, Pantelis Antoniou wrote:

> Hi there.
>
> I have a few questions regarding the new DMA API.
[snip]
> 3. The first argument is dma_* function is a struct device.
>   When working with network devices I must set this to NULL.
>   Granted this is no problem right now, but could this be
>   a problem in the future?

It could be a problem in the future, but probably not until cpm1/cpm2
stuff uses OCP bits, which would have a dev entry to pass in (AFAIK,
there aren't plans to make use of dev yet, so...).

--
Tom Rini
http://gate.crashing.org/~trini/

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

Re: new dma API questions

[Matt Porter]

On Thu, Jun 03, 2004 at 08:46:24AM -0700, Tom Rini wrote:
> On Thu, Jun 03, 2004 at 12:06:29PM +0300, Pantelis Antoniou wrote:
>
> > Hi there.
> >
> > I have a few questions regarding the new DMA API.
> [snip]
> > 3. The first argument is dma_* function is a struct device.
> >   When working with network devices I must set this to NULL.
> >   Granted this is no problem right now, but could this be
> >   a problem in the future?
>
> It could be a problem in the future, but probably not until cpm1/cpm2
> stuff uses OCP bits, which would have a dev entry to pass in (AFAIK,
> there aren't plans to make use of dev yet, so...).

To further clarify, it just happens that DMA API has to allow for that
parameter since several architectures need to be able to perform
operations based on the "bus type" which can be derived from the
struct device argument.  It just happens that we don't need to do
that on ppc32.  However!...I've been enlightened to a case on
Marvell 64x60 where it would be desirable to use the "non-coherent"
implementation on the on-chip peripherals that don't have snooping
and then use the "coherent" implementation on the PCI bus. That
would require additional reorg work and it's not clear yet how the
64x60 folks want to handle the situation.

-Matt

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