This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: serial.c, dsr_lock for read or write


Gary Thomas wrote:
> 
> On 22-May-2001 Phung Te Ha wrote:
> > Hi everyone,
> >
> > I'm using eCos on a custom board. The CPU is an ARM7.
> > I use serial.c to buffer my USB device driver and
> > realize that there's a call to
> > cyg_drv_dsr_lock()/unlock() around the serial_read()
> > and serial_write core. This blocks the other DSRs if I
> > have a blocking read waiting for data for instance.
> >
> > Am I seeing it right? It seems too strong for me
> > blocking all the DSRs, and possibly quite long time
> > this way.
> 
> DSRs are only locked out while shared data structures are being
> examined.  Once it is determined that the driver needs to wait
> for data to move (in or out), the lock will be dropped.
> 
> Note: this mechanism really only works for interrupt-driven devices.

I think Phung is concerned that we lock _all_ DSRs, not just the serial
DSRs. Unfortunately we can't be selective about which DSRs to run once we
get an interrupt - we can't restart the serial DSR later if we get a serial
interrupt.

The only scope for improvement in that respect is if we masked all the
serial interrupt(s) in the interrupt controller (if one exists!) or on the
device. Trying to do all this portably would take some care given the
presence or absence of an interrupt controller, the presence or absence of
disabling it at the device, and/or the selection of interrupts that need to
be masked.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]