On Fri, 11 Jan 2008 05:44:56 +0100 Peter Stuge <[EMAIL PROTECTED]> wrote:
> On Fri, Jan 11, 2008 at 01:20:58AM -0800, Kristoffer Ericson wrote: > > > > 2) Best way to reserve pccard irq interrupt? And does the > > > > handler get replaced by the proper driver handler? > > > > > > Again, do you mean cardbus or pcmcia? And what exactly is the > > > hd64461 - card host or card? > > > > pcmcia (16bit). hd64461 is a companion chip that provides features > > like pcmcia, lcd,... > > Ok. Is it actually a PCI device? If not, the driver for it should > probably be a platform driver, like ISA hardware drivers. > > I had to do some digging to find an example of this in the kernel, > there aren't that many simple ISA drivers left. > Hmmm, I've never actually considerd that. I assumed all PCMCIA systems were PCI similiar. > > > > > From what I can tell the socket interrupt is working fine > > > > (detecting changes properly) but everytime it pushes IRQ_NONE > > > > (interrupt ment for pccard interrupt) it oopses with "nobody > > > > cared..". > > > > > > Because there is no driver that requested the irq I guess? > > > > Haven't thought about it like that, but you are correct. I always > > suspected the driver simply had issues getting the irq, but it > > could also mean that no driver is loaded (and thus no irq request). > > So then you should be taking care of the interrupt, right? I install a handler to take care of both interrupts (pccard & slot) but it then looks where the interrupt came from and if its generated by the pccard it returns IRQ_NONE to let the driver interrupt handler take care of it. > > Also in this case you would already have identified the source as > being the socket rather than a card - which is actually a stronger > indication that your driver needs to take action. All slot interrupts (card status changed.../../) is detected properly and forwarded through the pcmcia subsystem. However when a pccard interrupt is generated I get a kernel oops "nobody cared". >From what I can see the slot is working as it should but no handler for the >pccard interrupt is available. > > > > This driver is based on an old one which used port-translations, > > you know the crappy PORT 0xblablabla = (real adress) 0xblobloblo, > > Hm - no? > This existed in LinuxSH tree until 2.6.19, in essence everything was considerd a port number. The number was then translated into the real adress whenever access was needed. No idea why it was implemented. >From what I gatherd from Paul (linuxsh maintainer) it was to fix some problems >on other archs rather than SuperH specific. Anyhow this has been removed so now we are working with real adresses. It created alot of issues for me though since I needed to remake the driver, theres always a chance that I translated a port adress wrong. > > > so I might have gotten an adress wrong and in there > > caused the driver to fail its probing. Thoughts? > > I guess you'll have to add gobs of printk() to find out what is > actually happening. I was thinking to add printk's to the orinoco driver since I have such a card here. It has worked in the past and could perhaps give me some info during the probing. If it fails to probe the device properly I must have some configuration/memadress wrong. > > > //Peter > > _______________________________________________ > Linux PCMCIA reimplementation list > http://lists.infradead.org/mailman/listinfo/linux-pcmcia -- Kristoffer Ericson <[EMAIL PROTECTED]> _______________________________________________ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
