From: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
To: Michal Simek <monstr@monstr.eu>
Cc: Jason Cooper <jason@lakedaemon.net>,
Michal Simek <michal.simek@xilinx.com>,
linux-kernel@vger.kernel.org, Alan Tull <atull@altera.com>,
Pavel Machek <pavel@ucw.cz>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Dinh Nguyen <dinguyen@altera.com>,
Philip Balister <philip@balister.org>,
Alessandro Rubini <rubini@gnudd.com>,
Mauro Carvalho Chehab <m.chehab@samsung.com>,
Andrew Morton <akpm@linux-foundation.org>,
Cesar Eduardo Barros <cesarb@cesarb.net>,
Joe Perches <joe@perches.com>,
"David S. Miller" <davem@davemloft.net>,
Stephen Warren <swarren@nvidia.com>,
Arnd Bergmann <arnd@arndb.de>,
David Brown <davidb@codeaurora.org>,
Dom Cobley <popcornmix@gmail.com>
Subject: Re: [RFC PATCH] fpga: Introduce new fpga subsystem
Date: Mon, 30 Sep 2013 11:12:56 -0600 [thread overview]
Message-ID: <20130930171256.GA28898@obsidianresearch.com> (raw)
In-Reply-To: <524588C9.1090600@monstr.eu>
On Fri, Sep 27, 2013 at 03:31:53PM +0200, Michal Simek wrote:
> I expect that you are detecting/specifying in the driver which
> fpga is connected and you also need to know size of this device.
> Then your driver allocate buffer with this size in the kernel
> and streming data to this buffer. When this is done you are
> using another sysfs files to control device programming.
No, it just streams:
static ssize_t fpga_config_write(struct file *filp,struct kobject *kobj,
struct bin_attribute *attr,
char *buf, loff_t off, size_t len)
{
struct device *dev = container_of(kobj, struct device, kobj);
struct platform_device *pdev = to_platform_device(dev);
struct fpga_priv *priv = platform_get_drvdata(pdev);
uint8_t *cur = buf;
size_t total = len;
unsigned int bit;
for (; len != 0; len--, cur++) {
gpio_set_value(priv->gpio[GPIO_CCLK],0);
for (bit = 0; bit != 8; bit++)
gpio_set_value(priv->data_gpio[bit],
(*cur & (1<<bit)) != 0);
gpio_set_value(priv->gpio[GPIO_CCLK],1);
if (gpio_get_value(priv->gpio[GPIO_INIT_B]) == 0)
return -EIO;
}
return total;
}
static struct bin_attribute dev_attr_config_data = {
.attr = {
.name = "config_data",
.mode = 0600,
},
.size = 0,
.write = fpga_config_write,
};
User space does as many writes as necessary to send the entire
bitstream, the sysfs layer chunks things into PAGE_SIZE blocks, so it
acts much like a socket with O_NONBLOCK set.
We are controlling the other related GPIOs from userspace, but for
your purposes I would pair the data sysfs file with a control sysfs
file much like request firwmare does.
Here is a suggestion.
- Two files fpga_config_state, fpga_config_data
- fpga_config_state is a one value text string values are like
initializing, clearing, programming, operating, error_clear_failed,
error_bistream_crc
- Userspace writes to fpga_config_state which causes the kernel FSM
to move to that state. The normal progression would be initializing,
clearing, programming and finally operating
- The kernel can move to an error_* state if it detects a problem
- The programming state data from fpga_config_data to the
configuration bus and userspace writes 'operating' once the stream
is done to perform the post-configuration actions.
Jason
next prev parent reply other threads:[~2013-09-30 17:13 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-18 15:56 [RFC PATCH 0/1] FPGA subsystem core Michal Simek
2013-09-18 15:56 ` [RFC PATCH] fpga: Introduce new fpga subsystem Michal Simek
2013-09-18 16:11 ` Joe Perches
2013-09-19 10:01 ` Michal Simek
2013-09-19 16:26 ` Alan Tull
2013-09-18 19:02 ` Dinh Nguyen
2013-09-19 11:53 ` Michal Simek
2013-09-18 19:15 ` Jason Cooper
2013-09-18 20:32 ` Jason Gunthorpe
2013-09-18 21:17 ` Alan Tull
2013-09-19 10:08 ` Pavel Machek
2013-09-19 11:02 ` Michal Simek
2013-09-20 20:55 ` Alan Tull
2013-09-24 15:55 ` Alan Tull
2013-09-24 15:58 ` Michal Simek
2013-09-24 16:22 ` Alan Tull
2013-09-24 22:18 ` Greg Kroah-Hartman
2013-09-25 13:55 ` Yves Vandervennet
2013-09-25 14:51 ` Michal Simek
2013-09-25 18:50 ` Alan Tull
2013-09-24 22:54 ` H. Peter Anvin
2013-09-25 10:41 ` Michal Simek
2013-09-25 12:00 ` Pavel Machek
2013-09-25 14:27 ` Philip Balister
2013-09-25 14:43 ` Michal Simek
2013-09-25 19:21 ` Alan Tull
2013-09-19 10:55 ` Michal Simek
2013-09-19 11:17 ` Pavel Machek
2013-09-19 11:22 ` Michal Simek
2013-09-19 12:52 ` /sys rules " Pavel Machek
2013-09-19 14:06 ` Greg KH
2013-09-19 14:10 ` Michal Simek
2013-09-19 14:18 ` Greg KH
2013-09-19 15:14 ` Alan Tull
2013-09-19 14:20 ` Jason Cooper
2013-09-19 14:37 ` Greg KH
2013-09-19 22:48 ` Pavel Machek
[not found] ` <CADuitaA3PLaOgmqXzfMdMDaXg7G6bT-DufjcuhtWfvaoWRj__Q@mail.gmail.com>
2013-09-19 15:14 ` Michal Simek
2013-09-19 15:18 ` Yves Vandervennet
2013-09-19 17:28 ` Jason Gunthorpe
2013-09-23 13:10 ` Michal Simek
2013-09-23 17:10 ` Jason Gunthorpe
2013-09-25 10:48 ` Michal Simek
2013-09-23 13:02 ` Michal Simek
2013-09-19 10:03 ` Pavel Machek
2013-09-19 10:45 ` Michal Simek
2013-09-27 13:31 ` Michal Simek
2013-09-30 17:12 ` Jason Gunthorpe [this message]
2013-10-01 15:59 ` Michal Simek
2013-09-18 23:45 ` Ryan Mallon
2013-09-19 11:37 ` Michal Simek
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=20130930171256.GA28898@obsidianresearch.com \
--to=jgunthorpe@obsidianresearch.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=atull@altera.com \
--cc=cesarb@cesarb.net \
--cc=davem@davemloft.net \
--cc=davidb@codeaurora.org \
--cc=dinguyen@altera.com \
--cc=gregkh@linuxfoundation.org \
--cc=jason@lakedaemon.net \
--cc=joe@perches.com \
--cc=linux-kernel@vger.kernel.org \
--cc=m.chehab@samsung.com \
--cc=michal.simek@xilinx.com \
--cc=monstr@monstr.eu \
--cc=pavel@ucw.cz \
--cc=philip@balister.org \
--cc=popcornmix@gmail.com \
--cc=rubini@gnudd.com \
--cc=swarren@nvidia.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;
as well as URLs for NNTP newsgroup(s).