From: "Filipau, Ihar" <ifilipau@sussdd.de>
To: "'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>
Subject: inw/outw performance
Date: Fri, 28 Mar 2003 09:00:54 +0100 [thread overview]
Message-ID: <7A5D4FEED80CD61192F2001083FC1CF9065148@CHARLY> (raw)
Hello All!
[ please CC me - I'm not subscribed ]
[ do not know where else to send - so it goes here,
I hope some-one more qualified can advice something ]
I have a little question which comes down to two little
CPU instructions - inw/outw.
I have a proprietary PCI board (PMD MC2140 motion controller with PLX).
I have wrote device driver for it (heap of ioctl()s - not more).
Now my company investigates possibilities to go to high-performance
market - and I have hit the problem with performance.
Communication with controller (sending of the command and reading back
response) looks like this:
outw(cmd_port, command);
while( !(inw(status_port)&READY) );
outw(data_port, param1);
while( !(inw(status_port)&READY) );
outw(data_port, param2);
while( !(inw(status_port)&READY) );
...
outw(data_port, paramN);
while( !(inw(status_port)&COMMAND_DONE) );
resp_data1 = inw(data_port);
while( !(inw(status_port)&READY) );
...
resp_dataM = inw(data_port);
while( !(inw(status_port)&READY) );
And actually what I have found that on my development P3/1GHz system
every inw() takes more that 3us. I wasn't measuring outw() yet - but
I do not expect its timing to be better.
Whole communication sequence on average takes ~55us. I need to execute
tens of commands for every user request - and time goes to some hefty
3millis just to program motion controller. And on deployment (embedded)
platform this is going to be even worse.
Okay. Our motion controller has 20MHz clock inside. So for every 50
cycles of CPU I have only 1 cycle of motion controller. 3us ~ 1k
commands of CPU, and at top 20MHz/3us == 6,(6) commands of motion
controller.
Am I right in my calculations? I have hit the limit of our device
bandwidth?
Is there any other way to communicate over PCI bus with controller?
- I can ask our hw enginers to implement something, if there is something
possible to implement to improve performance.
I'm using interrupt-driven IO to communicate with user space. I have
to execute several commands with motion controller: and it takes 200-400us
just to clear interrupt state of motion controller - Is it okay timing for
interrupt handler? Or should I try move stuff to BH or something like
this?
Thanks in advance.
--- Regards&Wishes! With respect Ihar "Philips" Filipau, Phil for friends
- - - - - - - - - - - - - - - - - - - - - - - - -
MCS/Mathematician - System Programmer
Ihar Filipau
Software entwickler @ SUSS MicroTec Test Systems GmbH,
Suss-Strasse 1, D-01561 Sacka (bei Dresden)
e-mail: ifilipau@sussdd.de tel: +49-(0)-352-4073-327
fax: +49-(0)-352-4073-700 web: http://www.suss.com/
next reply other threads:[~2003-03-28 7:51 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-03-28 8:00 Filipau, Ihar [this message]
2003-03-30 17:23 ` Pavel Machek
2003-03-30 20:32 ` Jonathan Lundell
2003-03-31 8:41 Filipau, Ihar
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=7A5D4FEED80CD61192F2001083FC1CF9065148@CHARLY \
--to=ifilipau@sussdd.de \
--cc=linux-kernel@vger.kernel.org \
/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
all inboxes | Powered by JetHome®