[ECOS] serial.c, dsr_lock for read or write

[ECOS] serial.c, dsr_lock for read or write

[Phung Te Ha]

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.

Thanks for your ideas.
Phungte

__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/

RE: [ECOS] serial.c, dsr_lock for read or write

[Gary Thomas]

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.

Re: [ECOS] serial.c, dsr_lock for read or write

[Jonathan Larmour]

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