Re: [RFC PATCH] fpga: Introduce new fpga subsystem

[Jason Gunthorpe]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/