From: Tobias Waldekranz <tobias@waldekranz.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: davem@davemloft.net, kuba@kernel.org, netdev@vger.kernel.org,
Vivien Didelot <vivien.didelot@gmail.com>,
Florian Fainelli <f.fainelli@gmail.com>,
Vladimir Oltean <olteanv@gmail.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next 1/2] net: dsa: mv88e6xxx: Improve performance of busy bit polling
Date: Thu, 27 Jan 2022 13:58:12 +0100 [thread overview]
Message-ID: <87o83xbajf.fsf@waldekranz.com> (raw)
In-Reply-To: <YfHdCDIUvpaYpDSF@lunn.ch>
On Thu, Jan 27, 2022 at 00:45, Andrew Lunn <andrew@lunn.ch> wrote:
> There are a few bit-banging systems out there. For those, i wonder if
> 50ms is too short? With the old code, they had 16 chances, no matter
> how slow they were. With the new code, if they take 50ms for one
> transaction, they don't get a second chance.
>
> But if they have taken 50ms, around 37ms has been spent with the
> preamble, start, op, phy address, and register address. I assume at
> that point the switch actually looks at the register, and given your
> timings, it really should be ready, so a second loop is probably not
> required?
>
> O.K, so this seems safe.
I think you raise a good point though. Say that you then have this
series of events:
1. Bang out ST
2. Bang out OP
3. Bang out PHYADR
4. Bang out REGADR
5. Clock out TA
6. schedule()
7. A SCHED_FIFO/P99 task runs
8. Clock in DATA
- Steps 1 through 5 could plausibly be completed before the bit clears
if you are running over some memory mapped GPIO lines
- Step 7 could execute for more than 50ms
- After step 8, you would see the busy bit set, but your time is up
All of this is of course _very_ unlikely, but not impossible. Should we
ensure that you always get at least two bites at the apple?
next prev parent reply other threads:[~2022-01-27 12:58 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-26 23:12 [PATCH net-next 0/2] net: dsa: mv88e6xxx: Improve indirect addressing performance Tobias Waldekranz
2022-01-26 23:12 ` [PATCH net-next 1/2] net: dsa: mv88e6xxx: Improve performance of busy bit polling Tobias Waldekranz
2022-01-26 23:45 ` Andrew Lunn
2022-01-27 12:58 ` Tobias Waldekranz [this message]
2022-01-27 13:06 ` Andrew Lunn
2022-01-26 23:54 ` Andrew Lunn
2022-01-26 23:12 ` [PATCH net-next 2/2] net: dsa: mv88e6xxx: Improve indirect addressing performance Tobias Waldekranz
2022-01-26 23:53 ` Andrew Lunn
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=87o83xbajf.fsf@waldekranz.com \
--to=tobias@waldekranz.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=vivien.didelot@gmail.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 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.