From: Vitaly Wool <vwool@ru.mvista.com>
To: Mark Underwood <basicmark@yahoo.com>
Cc: linux-kernel@vger.kernel.org, david-b@pacbell.net,
dpervushin@gmail.com, akpm@osdl.org, greg@kroah.com,
komal_shah802003@yahoo.com, stephen@streetfiresound.com,
spi-devel-general@lists.sourceforge.net, Joachim_Jaeger@digi.com
Subject: Re: [PATCH 2.6-git] SPI core refresh
Date: Thu, 01 Dec 2005 10:17:29 +0300 [thread overview]
Message-ID: <438EA389.7030704@ru.mvista.com> (raw)
In-Reply-To: <20051130202930.67776.qmail@web36914.mail.mud.yahoo.com>
Mark Underwood wrote:
>>However, there also are some advantages of our core compared to David's I'd like to mention
>>
>>- it can be compiled as a module
>>
>>
>So can David's. You can use BIOS tables in which case you must compile the SPI core into the
>kernel but you can also use spi_new_device which allows the SPI core to be built as a module (and
>is how I am using it).
>
>
You limit the functionality, so it's not the case.
>
>
>>- it is DMA-safe
>>
>>
>To my understanding David's core is DMA-safe. Yes there is a question mark over one of the helper
>functions, but the _main_ functions _are_ DMA-safe.
>
>
Yeah, I can agree with this statement. However, as it turns out, the
latest David's core eliminates this issue.
>
>
>>- it is priority inversion-free
>>- it can gain more performance with multiple controllers
>>
>>
>Sorry I'm not sure what you mean here.
>
>
If there's more than one SPI controller onboard, spi_write_then_read
will serialize the transfers related to two different controllers what
will have significant negative impact on the transfer speed (so DMA
won't help increasing the speed in this case). Moreover, if, say, two
kernel threads with different priorities are working with two SPI
controllers respectively *priority inversion* will happen.
You might also want to learn more about real-time systems
characterictics such as priority inversion, BTW.
>
>
>>- it's more adapted for use in real-time environments
>>- it's not so lightweight, but it leaves less effort for the bus driver developer.
>>
>>
>
>But also less flexibility. A core layer shouldn't _force_ a policy
>
>
Nope, it's just a default policy.
>on a bus driver. I am currently developing an adapter driver for David's system and I wouldn't say
>that the core is making me do things I think the core should do. Please could you provide examples
>of where you think Davids SPI core requires 'effort'.
>
>
Main are
- the need to call 'complete' in controller driver
- the need to implement policy in controller driver
Vitaly
next prev parent reply other threads:[~2005-12-01 7:17 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-30 16:50 [PATCH 2.6-git] SPI core refresh Vitaly Wool
2005-11-30 19:17 ` Russell King
2005-11-30 19:54 ` Greg KH
2005-11-30 20:29 ` Mark Underwood
2005-12-01 7:17 ` Vitaly Wool [this message]
2005-12-01 18:31 ` David Brownell
2005-12-02 5:48 ` Vitaly Wool
2005-12-02 18:37 ` Mark Underwood
2005-11-30 21:26 ` David Brownell
2005-11-30 21:27 ` David Brownell
2005-12-12 16:57 ` Vitaly Wool
2005-12-13 22:16 ` David Brownell
2005-11-30 21:36 ` David Brownell
2005-11-30 21:59 ` Stephen Street
2005-12-01 7:31 ` Vitaly Wool
2005-12-01 7:24 ` Vitaly Wool
-- strict thread matches above, loose matches on Subject: below --
2005-12-01 16:11 Vitaly Wool
2005-12-01 16:21 ` Russell King
2005-12-01 16:30 ` Vitaly Wool
2005-12-01 18:04 ` Stephen Street
2005-12-01 18:22 ` Greg KH
2005-12-02 6:06 ` Vitaly Wool
2005-12-02 18:50 ` Mark Underwood
2005-12-02 20:13 ` Greg KH
2005-12-05 18:01 ` Vitaly Wool
2005-12-08 1:59 ` David Brownell
2005-12-08 6:33 ` Vitaly Wool
2005-12-09 22:55 ` David Brownell
2005-12-10 11:15 ` Vitaly Wool
2005-12-11 12:36 ` Vitaly Wool
2005-12-03 11:44 vitalhome
2005-12-03 11:49 vitalhome
2005-12-03 17:10 ` Mark Underwood
2005-12-03 23:50 ` David Brownell
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=438EA389.7030704@ru.mvista.com \
--to=vwool@ru.mvista.com \
--cc=Joachim_Jaeger@digi.com \
--cc=akpm@osdl.org \
--cc=basicmark@yahoo.com \
--cc=david-b@pacbell.net \
--cc=dpervushin@gmail.com \
--cc=greg@kroah.com \
--cc=komal_shah802003@yahoo.com \
--cc=linux-kernel@vger.kernel.org \
--cc=spi-devel-general@lists.sourceforge.net \
--cc=stephen@streetfiresound.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