This is the mail archive of the
mailing list for the eCos project.
RE: Chaining DSRs in Different Drivers
- From: "Douglas Bush" <dbush at extremeeng dot com>
- To: "'Jonathan Larmour'" <jlarmour at redhat dot com>
- Cc: "'eCos Discussion List'" <ecos-discuss at sources dot redhat dot com>
- Date: Fri, 1 Feb 2002 11:02:23 -0700
- Subject: RE: [ECOS] Chaining DSRs in Different Drivers
There is a call back function to clear interrupts in the PCMCIA driver.
So, my only concern is configuration for faster operation.
[mailto:email@example.com] On Behalf Of Jonathan
Sent: Friday, February 01, 2002 10:28 AM
To: Douglas Bush
Cc: eCos Discussion List
Subject: Re: [ECOS] Chaining DSRs in Different Drivers
Douglas Bush wrote:
> Is there a good mechanism for chaining device driver DSRs?
> Currently, I have a PCMCIA driver for the CL-PS6700 which receives all
> the interrupts coming through the PCMCIA interface. (In this case a
> Wavelan 802.11 card.)
> The CL-PS6700 DSR calls the (I believe) appropriate handler, then
> re-enables interrupts. (The code is abbreviated below.)
> // This DSR handles the card interrupt
> static void cf_irq_dsr(cyg_vector_t vector, cyg_ucount32 count,
> cyg_addrword_t data)
> struct cf_slot *slot = (struct cf_slot *)data;
> // Process interrupt
> (slot->irq_handler.handler)(vector, count,
> clear all interrupts that occured in the controller
> except for CD1 and CD2
> *(unsigned volatile*)PCICR = ~EDB7XXX_CF_DETECT_MASK;
> // Clear interrupt
> // Allow interrupts to happen again
> The (slot->irq_handler.handler)(xxx) call actually calls eth_drv_dsr
> (bottom of the eth_drv.c file) which schedules a timer but doesn't
> actually call the Wavelan driver DSR until sometime later.
> The PCMCIA DSR then re-enables interrupts to the PCMCIA port BEFORE
> Wavelan DSR has run, the PCMCIA driver therefore goes into near
> continuous interrupt.
> Is there a better mechanism for chaining DSRs from one driver (PCMCIA)
> to another (Ethernet)? Preferably from the context of the original
Well as you can see, not at present :-). Perhaps the responsibility for
clearing and re-enabling interrupts should be passed down to the next
(i.e. slot->irq_handler.handler, which could then also be passed the IRQ
clear..... or perhaps instead passed a little callback function so that
lower layers can call back into the cf level code to clear the
I wonder what Gary thinks?
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223)
Maybe this world is another planet's Hell -Aldous Huxley ||