Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752577AbdGMVJa (ORCPT ); Thu, 13 Jul 2017 17:09:30 -0400 Received: from mail.kernel.org ([198.145.29.99]:50326 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751153AbdGMVJ2 (ORCPT ); Thu, 13 Jul 2017 17:09:28 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EF92B235E2 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=atull@kernel.org MIME-Version: 1.0 In-Reply-To: <7c6f5288-8009-e70f-b132-35a51dd9964c@linux.intel.com> References: <1497653911-11944-1-git-send-email-yi1.li@linux.intel.com> <1497653911-11944-2-git-send-email-yi1.li@linux.intel.com> <20170623154116.GA3565@kroah.com> <7c6f5288-8009-e70f-b132-35a51dd9964c@linux.intel.com> From: Alan Tull Date: Thu, 13 Jul 2017 16:08:46 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCHv3 1/3] firmware_class: move NO_CACHE from private to driver_data_req_params To: "Li, Yi" Cc: Greg KH , mcgrof@kernel.org, wagi@monom.org, David Woodhouse , rafal@milecki.pl, arend.vanspriel@broadcom.com, rjw@rjwysocki.net, Moritz Fischer , pmladek@suse.com, johannes.berg@intel.com, emmanuel.grumbach@intel.com, Luca Coelho , kvalo@codeaurora.org, luto@kernel.org, Takahiro Akashi , dhowells@redhat.com, pjones@redhat.com, linux-kernel , linux-fpga@vger.kernel.org, Yves Vandervennet , Jason Gunthorpe Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2151 Lines: 54 On Mon, Jun 26, 2017 at 10:28 AM, Li, Yi wrote: Hi Greg, > hi Greg > > On 6/23/2017 10:41 AM, Greg KH wrote: >> >> On Fri, Jun 16, 2017 at 05:58:29PM -0500, yi1.li@linux.intel.com wrote: >>> >>> From: Yi Li >>> >>> 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 > something? > >>> 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 programming. 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. Alan Tull