[ECOS] Documentation for new Ethernet driver interface?

[ECOS] Documentation for new Ethernet driver interface?

[Grant Edwards]

I'm trying to get my Ethernet driver that works with 1.3.1 to
work with CVS code, but I can't seem to find any documentation
on the new Ethernet driver interface.  Can somebody lend me a
clue?

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] Documentation for new Ethernet driver interface?

[Grant Edwards]

> I'm trying to get my Ethernet driver that works with 1.3.1 to
> work with CVS code, but I can't seem to find any documentation
> on the new Ethernet driver interface.  Can somebody lend me a
> clue?

A few specific questions (based on my perusal of the edb7xxx
driver):

1) The DSR that is called now seems to be a generic Ethernet
   DSR which then arranges for a future call to the "deliver"
   callback pointing to what used to be the driver DSR.

   The "deliver" callback is called from a thread context
   rather than a DSR context.
   
   Right?

2) What is the "poll" callback in ETH_DRV_SC for?  It seems to
   do almost the exact same thing that the deliver callback
   does.

3) What is done with the return value from the int_vector
   callback?  My driver uses three different interrupts, and
   I'm not sure which one to put here.  I'm guessing it's the
   interrupt number for the interrupt that calls the DSR that
   does mostly the same thing as the "deliver" callback?

4) The poll() and int_vector() callbacks seem not to be unused
   in "net/eth_drv.c" and are used only in stand_alone/eth_drv.c.
   Can I just put in stubs that do nothing for those two?

-- 
Grant Edwards
grante@visi.com

Re: [ECOS] Documentation for new Ethernet driver interface?

[Gary Thomas]

On 11-Dec-2000 Grant Edwards wrote:
> 
>> I'm trying to get my Ethernet driver that works with 1.3.1 to
>> work with CVS code, but I can't seem to find any documentation
>> on the new Ethernet driver interface.  Can somebody lend me a
>> clue?
> 
> A few specific questions (based on my perusal of the edb7xxx
> driver):
> 
> 1) The DSR that is called now seems to be a generic Ethernet
>    DSR which then arranges for a future call to the "deliver"
>    callback pointing to what used to be the driver DSR.
> 
>    The "deliver" callback is called from a thread context
>    rather than a DSR context.
>    
>    Right?
> 

Yes.  You can pretty much take your old 'dsr' function and rename 
it to be 'deliver' (possibly with different signature).

> 2) What is the "poll" callback in ETH_DRV_SC for?  It seems to
>    do almost the exact same thing that the deliver callback
>    does.
> 

It's pretty much the same, but it needs to be resilient to the
fact that it's called just to see if there is work for the driver.
That is, the 'isr' has not been called.  One way to think about this
is that poll() is the same as isr() and then dsr() (or deliver()).

> 3) What is done with the return value from the int_vector
>    callback?  My driver uses three different interrupts, and
>    I'm not sure which one to put here.  I'm guessing it's the
>    interrupt number for the interrupt that calls the DSR that
>    does mostly the same thing as the "deliver" callback?
> 

It's used to help decide if a network interrupt could possibly be
associated with typing ^C while using the network for debug I/O.
If you've got multiple interrupts, use the receive interrupt (assuming
that's the way they are stratified).

> 4) The poll() and int_vector() callbacks seem not to be unused
>    in "net/eth_drv.c" and are used only in stand_alone/eth_drv.c.
>    Can I just put in stubs that do nothing for those two?

Yes, unless you want to build RedBoot with networking support!

That's what all these changes were for, BTW.  RedBoot now supports
complete networking based debugging - including downloading your
applications over the network and sending the "console" output
over the network as well.

Re: [ECOS] Documentation for new Ethernet driver interface?

[Grant Edwards]

> > 1) The DSR that is called now seems to be a generic Ethernet
> >    DSR which then arranges for a future call to the "deliver"
> >    callback pointing to what used to be the driver DSR.
> > 
> >    The "deliver" callback is called from a thread context
> >    rather than a DSR context.
[...]
> Yes.  You can pretty much take your old 'dsr' function and
> rename it to be 'deliver' (possibly with different signature).

That's more or less what I thought.  I'll have to watch out for
synchronization issues.  My DSRs all used to run atomically
(with respect to each other) and after moving one of them to
the user thread level, that's no longer true.  In my previous
posting I has said my driver uses 3 interrupts -- I forgot
about a couple, it actually uses 5 -- but most of them don't do
much. :)

If I put dsr_lock/unlock calls in my deliver routine, it should
behave pretty much like it used to.

> > 2) What is the "poll" callback in ETH_DRV_SC for?
[...]
> It's pretty much the same, but it needs to be resilient to the
> fact that it's called just to see if there is work for the
> driver. That is, the 'isr' has not been called.  One way to
> think about this is that poll() is the same as isr() and then
> dsr() (or deliver()).

OK, thanks.

> > 3) What is done with the return value from the int_vector
> >    callback?
[...]
> It's used to help decide if a network interrupt could possibly
> be associated with typing ^C while using the network for debug
> I/O. If you've got multiple interrupts, use the receive
> interrupt (assuming that's the way they are stratified).

More or less.  I've got a PHY layer interrupt, MAC layer Rx/Tx
interrupts and DMA layer Rx/Tx interrupts.  The DMA Rx
interrupt is the one that tells us a packet is ready to be
handled, so that's the one.

I'm assuming that the eth_drv_dsr() only needs to be hooked to
the DMA Rx "frame ready" interrupt, and not any of the others?

> > 4) The poll() and int_vector() callbacks seem not to be unused
> >    in "net/eth_drv.c" and are used only in stand_alone/eth_drv.c.
> >    Can I just put in stubs that do nothing for those two?

> Yes, unless you want to build RedBoot with networking support!
>
> That's what all these changes were for, BTW.  RedBoot now
> supports complete networking based debugging - including
> downloading your applications over the network and sending the
> "console" output over the network as well.

That might be too useful to pass up.  One of these days I'm
going to need some sort of DHCP/BOOTP/TFTP boot loader, so I'll
keep it in mind.

-- 
Grant Edwards
grante@visi.com