On Fri, Jan 11, 2008 at 03:25:23PM -0800, Kristoffer Ericson wrote: > > > 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.
CardBus is much like PCI. PCMCIA not so much. > > 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. For this to work there must obviously be a card driver loaded when the interrupt comes, yes. Are you testing this with a card yet? I guess so, otherwise you wouldn't be getting card interrupts. Until the card driver succeeds in (also) requesting the interrupt you'll for sure continue to see the oops. > > 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". Ok, so then your controller driver is pretty much done and you're looking at writing a card driver, right? > >From what I can see the slot is working as it should but no > >handler for the pccard interrupt is available. "pccard" can be ambiguous, let's try to reserve that term for the Linux subsystem so I don't get confused. :) Indeed the slot seems to be working properly, and you have an issue with a card driver. But then we're not talking about the hd64461 anymore, right? > > > 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. I have never ran or even seen a SuperH platform I think, and have not been hacking around all that much in pcmcia land either, so I don't think I've come across this. Anyway, I understand the problem, may be a good idea to double check those translations. > > 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. Sounds like a good plan! //Peter _______________________________________________ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia