Re: Regarding device cycles

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Oct 12, 2010 at 10:04 PM, Dave Hylands <dhylands@xxxxxxxxx> wrote:
> Hi Sri,
>
> On Tue, Oct 12, 2010 at 6:29 PM, Sri Ram Vemulpali
> <sri.ram.gmu06@xxxxxxxxx> wrote:
>> Hi Dave,
>>
>>  Thanks for explanation.
>>
>>   So in your explanation you mentioned bus arbiter. So, bus does have
>> controller, which arbitrates between various devices. But CPU is given
>> higher priority than any other device.
>>
>> DMA uses bus only when CPU is not using it, in other words DMA is not
>> given access to bus. UART's are worked through CPU. So they no need to
>> wait for I/O operations.
>>
>> In other words bus is contended for among various devices. Can you
>> please provide more distinct explanation, between UARTs and DMA
>> contention for bus. Thanks in advance.
>
> UARTs don't access the memory bus. Your driver accesses the UART
> registers and puts characters in the FIFO. The UART takes the data
> from the FIFO and puts them on the serial lines. No memory access
> required (by the UART). Of course the CPU had to read the characters
> from memory and put them into the UART, but that was the CPU accessing
> the memory bus, not the UART.
>
> If you're DMA'ing from a peripheral into memory, then the DMA engine
> needs to access the memory bus. The CPU also accesses the memory bus
> whenever a cache miss occurs, or uncached accesses occur to memory. If
> the DMA and CPU both try to access the memory bus at the same time,
> then the bus arbiter decides who gets to go first.
>
> If you DMA from one peripheral to another peripheral, then no memory
> accesses are required by DMA.
>
> On the other hand, if you DMA from one memory region to another memory
> region, then 2 memory accesses are required by the DMA engine for each
> word transferred.
>
> You can think of DMA as a very specialized type of CPU that can read
> and write blocks of memory, and it executes at the same time as the
> real CPU.
>
> As a more concrete example, let's consider the TI OMAP 3530. Here's a datasheet.
> <http://focus.ti.com/lit/ds/symlink/omap3530.pdf>
>
> Take a look at the diagram on page 7 (Figure 1-1).
>
> You can see the processor on the top (labelled MPU Subsystem ARM
> Cortex A8) and you can also see the "External and Stacked Memories" on
> the bottom.
>
> Basically each block on the diagram that has an arrow going from the
> block to the bus can access the memory directly. DMA and the CPU are
> just a couple of the many components which can access memory. In this
> particular chip the UART actually sits on a sub-bus, and can't get
> access to main memory.
>
> Generally speaking, each block on the diagram will have a clock, and
> will execute in parallel with the CPU (which is just one of many
> blocks).
>
> --
> Dave Hylands
> Shuswap, BC, Canada
> http://www.DaveHylands.com/

In a standard PC design, don't you have 2 arbitrators?

The Northbridge which typically just arbitrates memory access between
the ultra highspeed devices (CPU, Video, PCIexpress, South Bridge and
sometimes highspeed sata interfaces).

And the South Bridge which arbitrates between all the slower devices / buses?

I _assume_ that even a relatively fast device like a sata controller
sitting on a traditional PCI bus is too slow to directly talk to the
memory bus, so the south bridge acts as a high-speed buffer for dma
requests going to and from memory via the northbridge.

Greg

-- 
Greg Freemyer
Head of EDD Tape Extraction and Processing team
Litigation Triage Solutions Specialist
http://www.linkedin.com/in/gregfreemyer
CNN/TruTV Aired Forensic Imaging Demo -
   http://insession.blogs.cnn.com/2010/03/23/how-computer-evidence-gets-retrieved/

The Norcross Group
The Intersection of Evidence & Technology
http://www.norcrossgroup.com

--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ




[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux