Anwar
Tue Jul 10 07:03:19 CDT 2007
Thanks Andrew
On Jul 10, 1:29 pm, "Andrew at Plextek (www.plextek.co.uk)"
<a...@plextek.com> wrote:
> Anwar,
>
> The calls we have added to the CEDDK are not standard calls - in fact
> they were already implemented in the reference BSP that we ported. You
> will need to add your own functions as appropriate for your hardware,
> if you choose to implement DMA in the same way.
>
> I would anticipate that you would not need to change
> HalTranslateSystemAddress if the DMA controller is part of the CPU.
>
> Regards,
> Andrew.
>
> On Jul 10, 5:57 am, Anwar <sm.anwa...@gmail.com> wrote:
>
>
>
> > Hi Andrew,
> > Thanks for the prompt reply.
> > As you said you have custom calls for interacting with the DMA
> > controller like HalAllocateDmaChan(), HalFreeDmaChan().... etc,
> > Are these calls part of the standard DDK or is it some implmentation
> > of your own which you have plugged into CEDDK, coz I have not been
> > able to find any documentation on these
> > Again if my DMA controller is part of the CPU then do I really need to
> > change the default implementation of HalTranslateSystemAddress, etc
> > since htey all use system physical address right?
>
> > Thanks and Regards
> > Mohammed Anwar
>
> > On Jul 9, 7:20 pm, "Andrew at Plextek (www.plextek.co.uk)"
>
> > <a...@plextek.com> wrote:
> > > Anwar,
>
> > > Firstly, Q4. The "Driver" is the software, the "Adaptor" refers to
> > > hardware.
>
> > > Q3. How you implement DMA on your device should be in line with the
> > > CEDDK support for DMA. This is where HalTranslateSystemAddress, etc.
> > > come in. Generally DMA controllers work using physical addresses, but
> > > what physical address region they use will depend on where they are in
> > > the hardware. For example if the DMA controller is part of the CPU
> > > device then it will use system physical addresses, if it is part of a
> > > PCI bus device, it may well use the physical PCI bus addresses. You
> > > need to support conversions between the various physical addresses
> > > that your DMA controller uses in CEDDK.
>
> > > Q2. We don't have a stream driver interface to the DMA controller in
> > > our target. CEDDK has been extended to include custom calls such as
> > > HalAllocateDmaChan(), HalFreeDmaChan().... etc. Other drivers call
> > > these directly to impliment DMA transfers.
>
> > > Q1. Burst size is what a memory/bus support in burst mode. Burst mode
> > > is where the address is sent at the start of a transaction, and then
> > > data is sent on consecutive bus transactions without the address being
> > > resent. So a burst size of 4 would be a bus cycle of
> > > <Addr><Data[0]><Data[1]><Data[2]><Data[3]>. This type of access is
> > > typical of DRAM, SDRAM and PCI bus.
>
> > > Regards,
> > > Andrew.
>
> > > On Jul 9, 9:59 am, Anwar <sm.anwa...@gmail.com> wrote:
>
> > > > Hi,
> > > > I am sort of a newbie to DMA.
> > > > But now i am supposes to make a DMA driver, basically a driver which
> > > > will talking to the DMA controler on my board.
> > > > For this I have few questions
> > > > 1) What is burst size and how is it related to DMA
> > > > 2) Would making the DMA driver similiar to a stream interface driver
> > > > be a correct design?
> > > > 3) Do I need to modify the API's HalTranslateSystemAddress or
> > > > HalAllocateCommonBuffer etc for the same
> > > > 4) What is the difference between a DMA driver and a DMA adapter?
>
> > > > Thanks
> > > > Anwar- Hide quoted text -
>
> > > - Show quoted text -- Hide quoted text -
>
> > - Show quoted text -- Hide quoted text -
>
> - Show quoted text -