Question regarding IRQF_SHARED and pcmcia driver

[Peter Stuge]

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