This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Chaining DSRs in Different Drivers
- From: "Douglas Bush" <dbush at extremeeng dot com>
- To: "eCos Discussion List" <ecos-discuss at sources dot redhat dot com>
- Date: Thu, 31 Jan 2002 17:59:12 -0700
- Subject: [ECOS] Chaining DSRs in Different Drivers
Folks,
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, slot->irq_handler.param);
/*
clear all interrupts that occured in the controller
except for CD1 and CD2
*/
*(unsigned volatile*)PCICR = ~EDB7XXX_CF_DETECT_MASK;
// Clear interrupt
cyg_drv_interrupt_acknowledge(EDB7XXX_CF_IRQ);
// Allow interrupts to happen again
cyg_drv_interrupt_unmask(EDB7XXX_CF_IRQ);
}
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 the
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 DSR?
Regards,
Douglas Bush
Extreme Engineering
#17, 6025 - 12 St. SE
Calgary, Alberta, Canada
T2H 2K1
Phone: 403 640 9494 ext-208
Fax: 403 640 9599
http://www.extremeeng.com