On Saturday 14 May 2005 3:33 pm, Botond Botyanszki wrote: > On Sat, 14 May 2005 13:22:11 -0700 > David Brownell <[EMAIL PROTECTED]> wrote: > > > It really ought to be > > possible to have PCMCIA be an even thinner wrapper around that > > platform device, and not need PCMCIA-specific stuff in the main > > body of the driver. > > I guess you mean the pcmcia_driver registration can be omitted and the > pcmcia code only registers the platform_device without claiming the > resources which should be done by the hcd driver as was done > originally. This would be possible,
Yes, that's what I meant. > but the IO address returned by > the pcmcia config code cannot be ioremap()-ed, so an #ifdef was necessary. > Not sure if this is an ARM or PCMCIA issue. It's a "board-specific" issue ... the chip can be wired to use memory mapped I/O (ARM, and most modern CPUs, do that for all I/O) or as the old school "i/o space" addressing. The RATOC "board" wires it for I/O, which means that the sl811-hcd should be prepared to work with either kind of I/O structure ... even with CPUs that don't have "i/o space". (The PCMCIA API forces them to emulate i/o space, for one thing.) The patch I'll post in a bit does this cleanly enough to behave on ARM, which for the moment seems to have all the users for this chip. Some day the driver should probably start using <asm-generic/iomap.h> stuff to resolve this issue. > Another need for an #ifdef was with the rising IRQ, the RATOC card > doesn't need this. Not so. The IRQ handling is a different issue; the chip itself issues level triggered IRQs, but most ARM CPUs don't support level triggers on the IRQs that are used for chip interfacing. So that needs to stay, to ensure that if it can't use (high) level triggering, it can at least get a rising edge trigger. (Getting only falling edge trigger would be real trouble ... rising edge is almost as good as triggering on high level, in most cases.) PXA for example supports only edge triggers: falling, rising, both. The original work on that driver was on a PXA. The AT91rm9200 supports only "both edge" triggers ... which could be a bit of a problem. Sometimes hardware gets unhappy when software notices an IRQ that hasn't yet been fully raised; such hardware can start acting freakey when that IRQ gets handled/acknowledged earlier than "expected". It can happen more easily on "wrong edge" triggers. > > OK, that's good. There's another patch I received recently, affecting > I have read up on the linux-usb-devel archives and after making the > suggesteg changes in > http://sourceforge.net/mailarchive/message.php?msg_id=11065662 > the endpoint_disable() bug seems to be solved. There were a few other posts too. I'm following up this thread with two patches, which I'd like to see tested on your Zaurus. - Dave ------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
