From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 14 19:39:43 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 474DC1065687 for ; Tue, 14 Oct 2008 19:39:43 +0000 (UTC) (envelope-from ken@mthelicon.com) Received: from hercules.mthelicon.com (hercules.mthelicon.com [IPv6:2001:49f0:2023::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0E74C8FC1B for ; Tue, 14 Oct 2008 19:39:42 +0000 (UTC) (envelope-from ken@mthelicon.com) Received: from feathers.peganest.com ([IPv6:2001:4d48:ad51:32:21b:21ff:fe1c:3ce]) (authenticated bits=0) by hercules.mthelicon.com (8.14.3/8.14.2) with ESMTP id m9EJdeDm039846 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO) for ; Tue, 14 Oct 2008 19:39:41 GMT (envelope-from ken@mthelicon.com) From: Pegasus Mc Cleaft Organization: Feathers To: freebsd-hackers@freebsd.org Date: Tue, 14 Oct 2008 20:39:39 +0100 User-Agent: KMail/1.10.1 (FreeBSD/7.1-PRERELEASE; KDE/4.1.1; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200810142039.39287.ken@mthelicon.com> Subject: Re: [Doubt] Can a PCI device communicate with another PCI or other device? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2008 19:39:43 -0000 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 ha= rd > disk)? Hi Srinivas,=20 Others may have a different opinion on this, and I am curious to see there= =20 input to this question as well. I tried doing something like this years ago= =20 with the Blackfin processor, but I found it to be not a good idea. While I= =20 could DMA transfer memory from the DSP into the physical memory of another= =20 device (In my case, the HD controller) I couldn't take control of IRQ=B4s. = Other=20 potential problems arose that turned me off to the whole idea (Data=20 concurrency between the DSP->HD and the host->HD). Even if you got past the= se=20 problems you would still face having to deal with any number of filing syst= ems=20 formats.=20 I found it much easier to make a device driver and service/daemon on the h= ost=20 machine that proxi-requested things for the DSP board and burped it into ra= m=20 that the DSP could then grab and process (or dump to disk from, in the othe= r=20 direction). While the speed may not be brilliant, it made things a lot easi= er=20 for me to manage on a software level.=20 In later revisions, I re-spun the PCB so it had an IDE controller local to= =20 the DSP and stuck an PLX-Tech PCI to PCI bridge between the host and the DS= P=20 so I could manage 2 small memory windows between the two (One for API=20 commands, and the other data) with a single IRQ back to the host. This allo= wed=20 me to have a high-speed IDE port local to the DSP where it was needed, and = a=20 slower link back to the host CPU for pulling video files, etc.=20 Hope this helps, Peg