On Thu, 19 Feb 2015, Michal Simek wrote:
> On 02/17/2015 08:17 PM, Pavel Machek wrote:
> > On Tue 2015-02-17 11:07:53, Rob Landley wrote:
> >>
> >>
> >> On 02/15/2015 04:40 PM, Pavel Machek wrote:
> >>> On Wed 2015-01-21 13:27:00, Jason Gunthorpe wrote:
> >>>> On Wed, Jan 21, 2015 at 06:33:12PM +0200, Pantelis Antoniou wrote:
> >>>> My point is that the current firmware layer is overly cautious and
> >>>> FPGAs are very big. My current project on small Xilinx device has a
> >>>> 10MB programming file. The biggest Xilinx device today has a max
> >>>> bitfile size around 122MB.
> >>>>
> >>>> So keeping that much memory pinned in the kernel when I can prove it
> >>>> is uncessary for my system (either because there is no suspend/resume
> >>>> possibility, or because I know the CPU can always access the
> >>>> filesytem) is very undesirable.
> >>>
> >>> Well, your current device aalso has 1GB RAM, no?
> >>
> >> Unnecessarily pinning 10% of your ram is a good solution?
> >
> > Never said that. But I'd rather have _some_ API proposed, then try to
> > design in everthing including kitchen sink and do nothing.
>
I propose an extension to the firmware class:
int request_firmware_streamed(const struct firmware **firmware_p,
const char *name,
struct device *device,
int (*consumer)(char *buf,
size_t size,
void *priv))
This is a new function that streams the firmware file in 4k chunks to
a callback function. So firmware is not limited to the allocation
size of vmalloc.
This new function would have the same parameters as request_firmware except
adding a pointer to a consumer function. In the case of fpga's, the
consumer function is writing the 4k chunks to the fpga.
The new function will:
* open the file
* read 4k
* hand that buffer to the consumer
* sleep until the consumer returns
* give up if consumer has a nonzero exit, continue reading otherwise
Admittedly this is really different from the current firmeware class's
structures.
The real problem this is trying to solve is that bitstreams can be huge,
especially as fpga's can be daisychained. And the CPU doing the loading
could be embedded (limited resources). IFAIK fpga's don't need to have
the whole image in a ram buffer.
This gives us the convenience of request_firmware() and gives the kernel an
extension of the firmware class that others might useful instead of solving
this problem that we keep hovering around for fpga's only.
Alan Tull
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
