Re: [PATCHv3 1/3] firmware_class: move NO_CACHE from private to driver_data_req_params
From: Alan Tull
Date: Thu Jul 13 2017 - 17:09:41 EST
On Mon, Jun 26, 2017 at 10:28 AM, Li, Yi <yi1.li@xxxxxxxxxxxxxxx> wrote:
> hi Greg
> On 6/23/2017 10:41 AM, Greg KH wrote:
>> On Fri, Jun 16, 2017 at 05:58:29PM -0500, yi1.li@xxxxxxxxxxxxxxx wrote:
>>> From: Yi Li <yi1.li@xxxxxxxxxxxxxxx>
>>> This adds DRIVER_DATA_REQ_NO_CACHE flag with .req flag under struct
>>> driver_data_req_params. When this flag is set, the driver_data driver
>>> will not cache the firmware during PM cycle, which is expensive.
>> Why is it "expensive"? What do you mean by this? Caching was added to
>> help things out, why would you not want it?
> Say we have couple drivers (GPU, wifi, FPGA, etc) loading firmwares during
> init, with firmware cache feature on, each time the system going to PM
> suspend, the firmware framework will cache all the firmware files (which
> have been loaded before) from fs to RAM, just in case during PM resume the
> drivers need to re-program firmware. If say FPGA driver does not need to
> re-program firmware to hardware for suspend/resume, it's "expensive/wasted"
> to load those in suspend phase and do not use them. Or I am missing
>>> It will be used by streaming case and other drivers which implement
>>> their own cache thing.
>> Why would a driver implement their own cache? And what do you mean by
>> "streaming case"?
> When the firmware file size is too big to fit into the RAM, we try to
> streaming it (load a page and program the page to the hardware and repeat
> till the end of file). For this case, the firmware was not loaded to RAM as
> a whole piece, there is no point/way to cache it.
Streaming for FPGA programming would mean a FPGA driver could load the
firmware a page at a time and write each page to the FPGA. In most
cases there is no need to keep the FPGA image in memory after
programming is done or even keep the whole image in memory while
As we're starting to look at larger devices with 100Meg FPGA images,
we want to avoid contiguous buffers. An alternative would be firmware
files loaded to scatter gather tables since Jason Gunthorpe added sg
support to fpga-mgr.