All of lore.kernel.org
 help / color / mirror / Atom feed
From: Xu Yilun <yilun.xu@intel.com>
To: Ivan Bornyakov <i.bornyakov@metrotek.ru>
Cc: mdf@kernel.org, hao.wu@intel.com, trix@redhat.com,
	Conor.Dooley@microchip.com, robh+dt@kernel.org,
	krzysztof.kozlowski+dt@linaro.org, linux-fpga@vger.kernel.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	system@metrotek.ru
Subject: Re: [PATCH v12 1/3] fpga: fpga-mgr: support bitstream offset in image buffer
Date: Sun, 22 May 2022 22:13:01 +0800	[thread overview]
Message-ID: <20220522141301.GA90764@yilunxu-OptiPlex-7050> (raw)
In-Reply-To: <20220522130145.GA89204@yilunxu-OptiPlex-7050>

On Sun, May 22, 2022 at 09:01:45PM +0800, Xu Yilun wrote:
> On Fri, May 13, 2022 at 07:27:53PM +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, than it will
> > be called again with greater part of image buffer on the input.
> > 
> > Signed-off-by: Ivan Bornyakov <i.bornyakov@metrotek.ru>
> > ---
> >  drivers/fpga/fpga-mgr.c       | 150 ++++++++++++++++++++++++++--------
> >  include/linux/fpga/fpga-mgr.h |  13 ++-
> >  2 files changed, 127 insertions(+), 36 deletions(-)
> > 
> > diff --git a/drivers/fpga/fpga-mgr.c b/drivers/fpga/fpga-mgr.c
> > index a3595ecc3f79..c6ca395909a0 100644
> > --- a/drivers/fpga/fpga-mgr.c
> > +++ b/drivers/fpga/fpga-mgr.c
> > @@ -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 (buf && 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,32 +145,61 @@ 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
> > - * device-specific things to get the FPGA into the state where it is ready to
> > - * receive an FPGA image. The low level driver only gets to see the first
> > - * initial_header_size bytes in the buffer.
> > + * Call the low level driver's parse_header then write_init functions.
> > + * This will do the device-specific things to get the FPGA into the state
> > + * where it is ready to receive an FPGA image. If parse_header sets
> > + * info->header_size, the low level driver's write_init only gets to see the
> > + * first info->header_size bytes in the buffer, mgr->mops->initial_header_size
> > + * otherwise. If neither initial_header_size nor header_size are not set,
> > + * write_init will not get any bytes of image buffer.
> 
> Could we always initialize the info->header_size = initial_header_size
> at early stage, maybe in fpga_mgr_load(), and only query
> info->header_size afterward. This is to make the logic for header size
> simpler.

Sorry I remember some existing drivers are using initial_header_size but
still deal with no buffer offset in write(), so we cannot force
info->header_size be filled. Forget about the previous comment.

Thanks,
Yilun

  reply	other threads:[~2022-05-22 14:20 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-13 16:27 [PATCH v12 0/3] Microchip Polarfire FPGA manager Ivan Bornyakov
2022-05-13 16:27 ` [PATCH v12 1/3] fpga: fpga-mgr: support bitstream offset in image buffer Ivan Bornyakov
2022-05-22 13:01   ` Xu Yilun
2022-05-22 14:13     ` Xu Yilun [this message]
2022-05-13 16:27 ` [PATCH v12 2/3] fpga: microchip-spi: add Microchip MPF FPGA manager Ivan Bornyakov
2022-05-22 16:52   ` Xu Yilun
2022-05-22 20:22     ` Ivan Bornyakov
2022-05-22 21:30       ` Conor.Dooley
2022-05-13 16:27 ` [PATCH v12 3/3] dt-bindings: fpga: add binding doc for microchip-spi fpga mgr Ivan Bornyakov
2022-05-20  4:15 ` [PATCH v12 0/3] Microchip Polarfire FPGA manager Ivan Bornyakov

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=20220522141301.GA90764@yilunxu-OptiPlex-7050 \
    --to=yilun.xu@intel.com \
    --cc=Conor.Dooley@microchip.com \
    --cc=devicetree@vger.kernel.org \
    --cc=hao.wu@intel.com \
    --cc=i.bornyakov@metrotek.ru \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-fpga@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mdf@kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=system@metrotek.ru \
    --cc=trix@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.