Please merge to Linus' tree. Russell, if you include the PXA UDC code in your upcoming -test5-rmk1 patch, you should also include this.
Applied, thanks.
I provided some feedback to David today, so it might be an idea to hold back on integrating it until David has had a chance to respond to this.
No, don't bother holding back the Kconfig stuff. (And in fact the new test2-rmk1-pxa1 and test5-bkpxa patches should get it too ... I see they just came out!) It's right for all 2.6 systems.
I saw the feedback you sent, hadn't had a chance to get to it yet.
Briefly, other than a build issue (which I hadn't seen with my pxa build environment, not entirely because I hadn't enabled pxa udc DMA support on 2.6), there's nothing to worry about until the DMA support gets enabled.
- - - Submitted by Russell King on 16 Sep 2003 17:06:20 (UTC) - - - Well, asm/proc/cache.h is gone in 2.6, so this doesn't compile. I've also been wondering why you want to include this file - nothing should include asm/proc/*.h directly unless they have an extremely good reason. Then I found this:
+ clean_dcache_range(start, start + _req->length);
which is an abuse of the macro:
/* * Perform necessary cache operations to ensure that the TLB will * see data written in the specified area. */ #define clean_dcache_area(start,size) cpu_dcache_clean_area(start, size)
since you're not using it to ensure we have TLB consistency. It looks like you really want to be using the DMA API here.
That seemed to be the relevant API in 2.4; I got that usage from some other driver. Of course, maybe it was wrong ... please advise :)
That'll need revisiting in 2.6. The idea is that since the PXA DMA engine ignores the cache, it needs flushing (IN data gets to memory, so DMA sees the current data) or invalidating (so cache flushes can't overwrite OUT data with old data).
If the (somewhat) generic DMA API is the answer here, then one issue will be that this driver doesn't yet hook up to sysfs ... it needs to be some kind of system/platform/... device.
FWIW the status of the DMA code is that it worked for IN transfers on 2.4 just fine -- so long as the buffers were properly aligned. OUT transfers need descriptor chaining, and unaligned buffers will likely be best with a bounce buffer scheme. (I'm assuming the PXA docs are right that the UDC has a particular alignment restriction here, the other integrated devices didn't seem to have any...)
I'm also slightly concerned about the got_irq ... req_config bitfields - req_* seem to be interrupt context stuff (can they be process context as well?), where as the others seem to be process context - and I don't see any locking.
Should be ok. The got_* stuff is just set during initialization, and makes sure that a partial init gets cleaned up right; readonly at all other times (and not even used till cleanup).
The req_* stuff should only be changed in the IRQ handler, or when IRQs are blocked. If it's changed at other times, that needs fixing. (Since this isn't SMP, I'm assuming that "IRQs are blocked" suffices for such locking.) I think the only possible trouble scenarios will involve deferred responses, as with "gadgetfs".
- Dave
------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
