Re: [Doubt] Can a PCI device communicate with another PCI or other device?
I think a PCI device can communicate with another PCI device directly without the intervention of the CPU. Excerpt from PCI Express System Architecture ... PCI Transaction Model - Peer-to-Peer A Peer-to-peer transaction shown as Transaction 3 in Figure 1-5 on page 20 is the direct transfer of data between two PCI devices. A master that wishes to initiate a transaction, arbitrates, wins ownership of the bus and starts a transaction. A target PCI device that recognizes the address claims the bus cycle. For a write bus cycle, data is moved from master to target. For a read bus cycle, data is moved from target to master. --S On Wed, Oct 15, 2008 at 9:35 PM, Eduardo Morras [EMAIL PROTECTED] wrote: At 20:32 14/10/2008, you wrote: Hello, I have a small doubt. Suppose I have a PCI card with a general purpose CPU on it. Could it be able to communicate with another PCI device or ISA device(lets say IDE hard disk)? You can't do it directly. You must pass through the OS driver that controls your card. You pass to your driver the data and it send data to other driver, hard disk, etc.. Note that in some OSs your driver can't pass that info from one driver to another and need an app that binds your driver with the other driver. Thanks, Srinivas ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [Doubt] Can a PCI device communicate with another PCI or other
In [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I think a PCI device can communicate with another PCI device directly without the intervention of the CPU. Absolutely. Happens a fair amount in embedded networking systems (among others). The host is responsible for enumeration and resource assignment, but once that's complete, any device on the bus can see all others. Whether that's useful depends rather heavily on the devices on the bus, obviously. TANSTAAFL applies, though, in that multiple initiators must be careful not to step on each others' accesses. -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.5 / 37N 20' 15.3 Internet: steve @ Watt.COM Whois: SW32-ARIN Free time? There's no such thing. It just comes in varying prices... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
[Doubt] Can a PCI device communicate with another PCI or other device?
Hello, I have a small doubt. Suppose I have a PCI card with a general purpose CPU on it. Could it be able to communicate with another PCI device or ISA device(lets say IDE hard disk)? Thanks, Srinivas ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [Doubt] Can a PCI device communicate with another PCI or other device?
On Tuesday 14 October 2008 19:32:47 Srinivas wrote: Hello, I have a small doubt. Suppose I have a PCI card with a general purpose CPU on it. Could it be able to communicate with another PCI device or ISA device(lets say IDE hard disk)? Hi Srinivas, Others may have a different opinion on this, and I am curious to see there input to this question as well. I tried doing something like this years ago with the Blackfin processor, but I found it to be not a good idea. While I could DMA transfer memory from the DSP into the physical memory of another device (In my case, the HD controller) I couldn't take control of IRQ´s. Other potential problems arose that turned me off to the whole idea (Data concurrency between the DSP-HD and the host-HD). Even if you got past these problems you would still face having to deal with any number of filing systems formats. I found it much easier to make a device driver and service/daemon on the host machine that proxi-requested things for the DSP board and burped it into ram that the DSP could then grab and process (or dump to disk from, in the other direction). While the speed may not be brilliant, it made things a lot easier for me to manage on a software level. In later revisions, I re-spun the PCB so it had an IDE controller local to the DSP and stuck an PLX-Tech PCI to PCI bridge between the host and the DSP so I could manage 2 small memory windows between the two (One for API commands, and the other data) with a single IRQ back to the host. This allowed me to have a high-speed IDE port local to the DSP where it was needed, and a slower link back to the host CPU for pulling video files, etc. Hope this helps, Peg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
