Question regarding IRQF_SHARED and pcmcia driver
kristoffer.ericson at gmail.com
Fri Jan 11 18:25:23 EST 2008
On Fri, 11 Jan 2008 05:44:56 +0100
Peter Stuge <stuge-linux-pcmcia at cdy.org> 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
> > > > 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
> Linux PCMCIA reimplementation list
Kristoffer Ericson <Kristoffer.Ericson at Gmail.com>
More information about the linux-pcmcia