This is the mail archive of the
ecos-patches@sourceware.org
mailing list for the eCos project.
Re: [patch] Philips D12 USB Slave Driver
- From: Frank Pagliughi <fpagliughi at mindspring dot com>
- To: Andrew Lunn <andrew at lunn dot ch>
- Cc: eCos Patches <ecos-patches at ecos dot sourceware dot org>
- Date: Tue, 02 May 2006 12:06:24 -0400
- Subject: Re: [patch] Philips D12 USB Slave Driver
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=RjqHxbHWL6bSGxpqk5Zqkd7SOHHEDTLUueYy8eIULHRrB1zsihEVhTeoJ3wYI2Yx; h=Received:Message-ID:Date:From:User-Agent:X-Accept-Language:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP;
- References: <443BB0A0.5050701@mindspring.com> <20060411145827.GE6383@lunn.ch> <443C1E62.5080807@mindspring.com> <20060427153350.GF9862@lunn.ch>
Andrew Lunn wrote:
On Tue, Apr 11, 2006 at 05:23:46PM -0400, Frank Pagliughi wrote:
Andrew Lunn wrote:
Hi Frank
On Tue, Apr 11, 2006 at 09:35:28AM -0400, Frank Pagliughi wrote:
This is a driver for the Philips PDIUSBD12 (D12) USB Slave Controller
Chip. It was written for the D12 on a PC/104 (ISA) board. With some
minor adjustments and testing should go with any CPU. I (tried to)
removed all the board-specific stuff, which, unfortunately also meant
removing DMA support.
I just had a very quick look at the code. I does seem to have a few
x386ism's in it but they are all nicely abstracted. Do you think you
can split this into two packages. A generic D12 driver and an i386
specific part. It would contain the functions to actually access the
hardware. You could put these into an inline header file so there
would be no loss of performance.
Yeah, I thought of trying something like that at the last minute,
especially to get the DMA code back in there. But I'm leaving town for a
few weeks, so I thought I would throw it at you to get some suggestions.
I can have a look when I get back. Can you point me to any example that
does this sort of thing? The PC serial ports, maybe?
Hi Frank
Take a look at the attached code. It will need a few clean ups,
comments, ChangeLog etc, but it should give you the idea. I had to
guess how the DMA word work, so i might have it wrong.
Oops. I messed up the patch. Didn't clear out my directory very well
before creating it. The "target.c" is actually an emacs backup file of
the existing "usbtarget.c" that's in the USB tests directory
(packages/io/usb/slave/current/tests). Note the "~" in the file name.
Sorry about that. Ignore that file.
Yep, my silly error. I'm an emacs uses so should know better!
I will submit a few minor changes to that file, though, in the near
future. Probably as configuration options. There are a few things
hard-wired into the test program that need to be configured for the
specific chip - such as the size of control endpoint zero.
O.K. please let me have these patches when you are ready.
In the patch, there is, however a valid, minor, update to the host side
of the existing test program that runs on Linux, "usbhost.c" The host
didn't recognize the target when run on Fedora Core 4. The fix should
allow it to run on FC4, plus whatever system it was originnaly designed for.
Thanks. I've already committed this change, and the same in chmod
program.
How is the copyright assignment going?
Andrew
Andrew,
My apologies for the delay on this stuff. Two projects ending
simultaneously, with a third starting before the others are done. I'm
frazzled. I've been on the road, away from my office for a few weeks.
I'm hoping I can make it home and have a look at it within the next week.
Frank