public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Grant Edwards <grante@visi.com>
To: Gary Thomas <gthomas@cambridge.redhat.com>
Cc: ecos-discuss@sources.redhat.com
Subject: Re: [ECOS] RedBoot serial rx interrupts
Date: Sat, 13 Jan 2001 15:32:00 -0000	[thread overview]
Message-ID: <20010113173656.A1333@visi.com> (raw)
In-Reply-To: <XFMail.20010113161347.gthomas@cambridge.redhat.com>

On Sat, Jan 13, 2001 at 04:13:47PM -0700, Gary Thomas wrote:

> > My Ethernet driver initialization routine ends up calling
> > cyg_drv_isr_lock() and cyg_drv_isr_unlock().  The latter
> > enables interrupts.
> 
> Maybe we should improve this interface to return an indication
> of whether the interrupts _were_ on when "isr_lock()" was
> called to avoid this in the future.  I'll think about it.

I doubt it's worth the extra overhead.

I hacked my way around the lock/unlock-during-init issue in
another kernel by statically initializing the lock counter to
its max value and then setting it to 0 just before the
scheduler first enables interrupts.  You'd still get interrupts
enabled during init if you called ulock() a lot of times
without calling lock(), but it behaved properly for balanced
lock/unlock calls.

> > I can add #defines to my driver code to turn those into noops
> > unless CYGPKG_NET is defined.
> > 
> > This raises the question: is it OK to call those two routines
> > during network device initialization?
> 
> It's not necessary.  Interrupts are always off during any
> system initialization, so you could just leave this out [and
> feel safe].

Right.  The situation arose because the init code called a
function that was also called by DSR and user-level code.  As
it turned out there just happened to be two versions of the
called function, one for use inside ISRs and one for "other".
Changing the init code to use the "ISR" version of the function
solved the problem.

But, to avoid future problems, I #defined a bunch of
cyg_drv_XXXX stuff to be noops when used for RedBoot.

It looks like things are working properly now (DHCP is working,
and I suspect that once I set up a TFTP server, that will
work).

I still have to use --ignore-errors so that I can have
CYGSEM_HAL_ROM_MONITOR==1 and CYG_HAL_STARTUP=="RAM".  I can
live with that, since my customers are going to be building
eCos apps but not RedBoot.

Thanks for the help (especially on a Saturday!)

-- 
Grant Edwards
grante@visi.com

  reply	other threads:[~2001-01-13 15:32 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-01-12 15:09 Grant Edwards
2001-01-13  7:17 ` Gary Thomas
2001-01-13 12:37   ` Grant Edwards
2001-01-13 12:52     ` Gary Thomas
2001-01-13 12:57       ` Grant Edwards
2001-01-13 13:45       ` Grant Edwards
2001-01-13 14:11         ` Gary Thomas
2001-01-13 14:31           ` Grant Edwards
2001-01-13 15:13             ` Gary Thomas
2001-01-13 15:32               ` Grant Edwards [this message]
2001-01-15  4:02                 ` Nick Garnett

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20010113173656.A1333@visi.com \
    --to=grante@visi.com \
    --cc=ecos-discuss@sources.redhat.com \
    --cc=gthomas@cambridge.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).