All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Buesch <mb@bu3sch.de>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: John Linville <linville@tuxdriver.com>,
	bcm43xx-dev@lists.berlios.de, linux-wireless@vger.kernel.org,
	Stefano Brivio <stefano.brivio@polimi.it>
Subject: Re: [PATCH] b43: Fix MAC control and microcode init
Date: Thu, 24 Jan 2008 23:03:36 +0100	[thread overview]
Message-ID: <200801242303.36694.mb@bu3sch.de> (raw)
In-Reply-To: <1201165981.3454.49.camel@johannes.berg>

On Thursday 24 January 2008 10:13:01 Johannes Berg wrote:
> 
> > This also adds a longer delay for waiting for the microcode
> > to initialize itself. It seems that the current timeout is sufficient
> > on all available devices, but there's no real reason why we shouldn't
> > wait for up to one second. Slow embedded devices might exist.
> 
> Your decision, but I very much doubt you can make the MAC any slower
> than on the old devices, in fact, on new chips it runs considerably
> faster I think.

Ok, well. But the host machine does get faster. In theory we only
gave the microcode 500 microseconds of time to initialize. I think
that is is a pretty tiny timeframe. In practice the time was higher,
because we had a loop that checked MMIO and delayed for 10usec.
Of course this all has overhead. But as machines get faster and faster
I think we can't assume to have more than 500 microseconds of time.

So, increasing the delay to one second doesn't hurt anyone. In
all common cases it will continue after a few milliseconds. That's fine.
Even if there is something going wrong (wrong firmware) you can
interrupt the one second delay by hitting ^C.

I think the specs originally sayed to use a much longer delay than
we were using. But we did use a shorter delay, because in some old
bcm43xx code this ran unter spinlock as far as I remember. So we didn't
want to spin several milliseconds and lockup the system, if something
goes wrong in firmware. These times are gone and now we can sleep
in this part of the code.

-- 
Greetings Michael.

      reply	other threads:[~2008-01-24 22:05 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-22 19:23 [PATCH] b43: Fix MAC control and microcode init Michael Buesch
2008-01-24  9:13 ` Johannes Berg
2008-01-24 22:03   ` Michael Buesch [this message]

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=200801242303.36694.mb@bu3sch.de \
    --to=mb@bu3sch.de \
    --cc=bcm43xx-dev@lists.berlios.de \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    --cc=stefano.brivio@polimi.it \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.