From: Andrey Smirnov <andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
yurovsky-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
linux-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: [RFC, PATCH] Add support for long SPI transfers
Date: Mon, 24 Nov 2014 09:50:22 -0800 [thread overview]
Message-ID: <1416851423-1902-1-git-send-email-andrew.smirnov@gmail.com> (raw)
Hi,
This patch is a very first, very preliminary version of the feature I
am implementing for niche usecase of SPI in a system I am working
on. It by no means contains production code and is purely RFC to "test
the water" and see if there would be any interest in including this in
mainline tree.
The system I am working with implements a lion's share of its
functionality in an extrenal FPGA connected to an ARM SoC via SPI
bus. In my use-case SPI bus used both for initial bitfile programming
of the FPGA and sending/fetching data to/from FPGA as well. Both use
cases, can benefit greatly from ability to send very long bit streams
over SPI as a single transaction during which CS line stays low the
whole time. The use-case of programming the FPGA is the most important
for me, since it is mandatory to program the FPGA before the rest of
the system can proceed to a functioning state and therefore my
"Applied power -> Functional State" time is greatly influenced by that
operation.
As things are right now both SPI subsystem and SPIDEV driver are
limited by their APIs to SPI transactions that are no longer than 255
bits and that problem is exacerbated by the fact that transction
length validity verification code does not have provisions for
anything bigger than 32 bits.
The code in this RFC deals only with the first problem, as I am not
sure what would best way to tackle the second one.
So I guess my two maing questions for this RFC are the following:
- Is this work seem like a good fit to be included in the mainline
kernel, or should I just keep doing it as my system specifica hack
and not bother with upsteaming?
- If the idea is good for upstreaming what would be a good way to
improve length checking code? I was thinking of ditching the
bitmask in favour of driver provided function that would take
transfer length as an argument, are there any better options?
Thank you.
Andrey Smirnov
Andrey Smirnov (1):
spi, spidev: Add support for long SPI transfers
drivers/spi/spidev.c | 7 ++++++-
include/linux/spi/spi.h | 4 ++--
include/uapi/linux/spi/spidev.h | 2 +-
3 files changed, 9 insertions(+), 4 deletions(-)
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next reply other threads:[~2014-11-24 17:50 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-24 17:50 Andrey Smirnov [this message]
[not found] ` <1416851423-1902-1-git-send-email-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-11-24 17:50 ` [RFC, PATCH] spi, spidev: Add support for long SPI transfers Andrey Smirnov
2014-11-24 17:57 ` [RFC, PATCH] " Mark Brown
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=1416851423-1902-1-git-send-email-andrew.smirnov@gmail.com \
--to=andrew.smirnov-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
--cc=broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=yurovsky-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.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;
as well as URLs for NNTP newsgroup(s).