[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220610084259.GB693376@yilunxu-OptiPlex-7050>
Date: Fri, 10 Jun 2022 16:42:59 +0800
From: Xu Yilun <yilun.xu@...el.com>
To: Ivan Bornyakov <i.bornyakov@...rotek.ru>
Cc: mdf@...nel.org, hao.wu@...el.com, trix@...hat.com, corbet@....net,
Ivan Bornyakov <brnkv.i1@...il.com>,
Conor.Dooley@...rochip.com, robh+dt@...nel.org,
krzysztof.kozlowski+dt@...aro.org, linux-fpga@...r.kernel.org,
devicetree@...r.kernel.org, linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org, system@...rotek.ru
Subject: Re: [PATCH v17 1/4] fpga: fpga-mgr: support bitstream offset in
image buffer
On Fri, Jun 10, 2022 at 11:13:42AM +0300, Ivan Bornyakov wrote:
> On Fri, Jun 10, 2022 at 03:43:11PM +0800, Xu Yilun wrote:
> > On Thu, Jun 09, 2022 at 06:47:49PM +0300, Ivan Bornyakov wrote:
> > > At the moment FPGA manager core loads to the device entire image
> > > provided to fpga_mgr_load(). But it is not always whole FPGA image
> > > buffer meant to be written to the device. In particular, .dat formatted
> > > image for Microchip MPF contains meta info in the header that is not
> > > meant to be written to the device. This is issue for those low level
> > > drivers that loads data to the device with write() fpga_manager_ops
> > > callback, since write() can be called in iterator over scatter-gather
> > > table, not only linear image buffer. On the other hand, write_sg()
> > > callback is provided with whole image in scatter-gather form and can
> > > decide itself which part should be sent to the device.
> > >
> > > Add header_size and data_size to the fpga_image_info struct and adjust
> > > fpga_mgr_write() callers with respect to them.
> > >
> > > * info->header_size indicates part at the beginning of image buffer
> > > that is *not* meant to be written to the device. It is optional and
> > > can be 0.
> > >
> > > * info->data_size is the size of actual bitstream data that *is* meant
> > > to be written to the device, starting at info->header_size from the
> > > beginning of image buffer. It is also optional and can be 0, which
> > > means bitstream data is up to the end of image buffer.
> > >
> > > Also add parse_header() callback to fpga_manager_ops, which purpose is
> > > to set info->header_size and info->data_size. At least
> > > initial_header_size bytes of image buffer will be passed into
> > > parse_header() first time. If it is not enough, parse_header() should
> > > set desired size into info->header_size and return -EAGAIN, then it will
> > > be called again with greater part of image buffer on the input.
> > >
> > > Signed-off-by: Ivan Bornyakov <i.bornyakov@...rotek.ru>
> > > ---
> > > drivers/fpga/fpga-mgr.c | 243 +++++++++++++++++++++++++++++-----
> > > include/linux/fpga/fpga-mgr.h | 17 ++-
> > > 2 files changed, 229 insertions(+), 31 deletions(-)
> > >
> > > diff --git a/drivers/fpga/fpga-mgr.c b/drivers/fpga/fpga-mgr.c
> > > index 08dc85fcd511..0854fbc8f11e 100644
> > > --- a/drivers/fpga/fpga-mgr.c
> > > +++ b/drivers/fpga/fpga-mgr.c
> >
> > Should we check in fpga_mgr_create, that initial_header_size must not be
> > 0 if parse_header() is defined. If we pass no data to parse_header(),
> > does it make any sense?
> >
>
> If FPGA image is mapped, whole buffer will be passed to parse_header(),
> regardless of initial_header_size.
>
> If FPGA image is sg_table and initial_header_size is 0, first sg
> fragment will be passed to parse_header() in
> fpga_mgr_parse_header_sg_first().
>
> If low level driver's parse_header() is buggy and return -EAGAIN without
> setting desired size into info->header_size, we will fail in
> fpga_mgr_parse_header_sg() with -ENOMEM.
>
> static ssize_t fpga_mgr_parse_header_sg(...)
> {
> size_t header_size = mgr->mops->initial_header_size; /* header_size == 0 */
> ...
>
> do {
> if (info->header_size) /* header_size is still 0 */
> header_size = info->header_size;
>
> buf = krealloc(buf, header_size, GFP_KERNEL); /* returned buf will be NULL */
> if (!buf) {
> ret = -ENOMEM;
> break;
> }
>
> ...
>
> } while (ret == -EAGAIN);
>
> ...
> }
>
> So, I believe it is OK to define parse_header() without defining
> initial_header_size.
That's good to me.
>
> > > @@ -74,6 +74,15 @@ static inline int fpga_mgr_write_complete(struct fpga_manager *mgr,
> > > return 0;
> > > }
> > >
> > > +static inline int fpga_mgr_parse_header(struct fpga_manager *mgr,
> > > + struct fpga_image_info *info,
> > > + const char *buf, size_t count)
> > > +{
> > > + if (mgr->mops->parse_header)
> > > + return mgr->mops->parse_header(mgr, info, buf, count);
> > > + return 0;
> > > +}
> > > +
> > > static inline int fpga_mgr_write_init(struct fpga_manager *mgr,
> > > struct fpga_image_info *info,
> > > const char *buf, size_t count)
> > > @@ -136,24 +145,145 @@ void fpga_image_info_free(struct fpga_image_info *info)
> > > EXPORT_SYMBOL_GPL(fpga_image_info_free);
> > >
> > > /*
> > > - * Call the low level driver's write_init function. This will do the
> > > + * Call the low level driver's parse_header function with entire FPGA image
> > > + * buffer on the input. This will set info->header_size and info->data_size.
> > > + */
> > > +static int fpga_mgr_parse_header_mapped(struct fpga_manager *mgr,
> > > + struct fpga_image_info *info,
> > > + const char *buf, size_t count)
> > > +{
> > > + int ret;
> > > +
> > > + mgr->state = FPGA_MGR_STATE_PARSE_HEADER;
> > > + ret = fpga_mgr_parse_header(mgr, info, buf, count);
> > > +
> > > + if (info->header_size + info->data_size > count) {
> > > + dev_err(&mgr->dev, "Bitsream data outruns FPGA image\n");
> > > + ret = -EINVAL;
> > > + }
> > > +
> > > + if (ret) {
> > > + dev_err(&mgr->dev, "Error while parsing FPGA image header\n");
> > > + mgr->state = FPGA_MGR_STATE_PARSE_HEADER_ERR;
> > > + }
> > > +
> > > + return ret;
> > > +}
> > > +
> > > +/*
> > > + * Call the low level driver's parse_header function with first fragment of
> > > + * scattered FPGA image on the input. If header fits first fragment,
> > > + * parse_header will set info->header_size and info->data_size. If it is not,
> > > + * parse_header will set desired size to info->header_size and -EAGAIN will be
> > > + * returned.
> > > + */
> > > +static int fpga_mgr_parse_header_sg_first(struct fpga_manager *mgr,
> > > + struct fpga_image_info *info,
> > > + struct sg_table *sgt)
> > > +{
> > > + size_t header_size = mgr->mops->initial_header_size;
> > > + struct sg_mapping_iter miter;
> > > + int ret;
> > > +
> > > + mgr->state = FPGA_MGR_STATE_PARSE_HEADER;
> > > +
> > > + sg_miter_start(&miter, sgt->sgl, sgt->nents, SG_MITER_FROM_SG);
> > > + if (sg_miter_next(&miter) &&
> > > + miter.length >= header_size)
> > > + ret = fpga_mgr_parse_header(mgr, info, miter.addr, miter.length);
> > > + else
> > > + ret = -EAGAIN;
> > > + sg_miter_stop(&miter);
> > > +
> > > + if (ret && ret != -EAGAIN) {
> > > + dev_err(&mgr->dev, "Error while parsing FPGA image header\n");
> > > + mgr->state = FPGA_MGR_STATE_PARSE_HEADER_ERR;
> > > + }
> > > +
> > > + return ret;
> > > +}
> > > +
> > > +/*
> > > + * Copy scattered FPGA image fragments to temporary buffer and call the
> > > + * low level driver's parse_header function. This should be called after
> > > + * fpga_mgr_parse_header_sg_first() returned -EAGAIN. In case of success,
> > > + * pointer to the newly allocated image header copy will be set into *ret_buf
> > > + * and its size will be returned. *ret_buf needs to be freed by caller.
> > > + */
> > > +static ssize_t fpga_mgr_parse_header_sg(struct fpga_manager *mgr,
> > > + struct fpga_image_info *info,
> > > + struct sg_table *sgt, char **ret_buf)
> >
> > Since the function allocs buffer for the user, I suggest it still returns
> > the buffer pointer. The buffer size could be an output parameter.
> >
>
> OK, will do that.
>
> > > +{
> > > + size_t len, header_size = mgr->mops->initial_header_size;
> > > + char *buf = NULL;
> > > + int ret;
> > > +
> > > + do {
> > > + if (info->header_size)
> > > + header_size = info->header_size;
> > > +
> > > + buf = krealloc(buf, header_size, GFP_KERNEL);
> > > + if (!buf) {
> > > + ret = -ENOMEM;
> >
> > If you need to return ERROR value, ERR_PTR() could be used.
> >
> >
> > BTW: Have you tried to test your FPGA programming using sg buffers? I want
> > to ensure these changes are actually tested?
> >
>
> Of course, but not every single error path, to be honest. Yet, I'm
> trying my best.
That's fine. Thanks for your support.
Powered by blists - more mailing lists