linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).