Re: [PATCHv2 0/3] Enable no_cache flag to driver_data

2017-06-07 Thread Luis R. Rodriguez
On Wed, Jun 07, 2017 at 04:00:42PM -0500, Li, Yi wrote: > On 6/7/2017 12:59 PM, Luis R. Rodriguez wrote: > > Ah, consider adding PM to driver_data_test_device ? > > That's what I am looking now. But per my understanding, the misc_device does > not have the hook to add PM support like those platfor

Re: [PATCHv2 0/3] Enable no_cache flag to driver_data

2017-06-07 Thread Li, Yi
On 6/7/2017 12:59 PM, Luis R. Rodriguez wrote: On Tue, Jun 06, 2017 at 02:31:54PM -0500, Li, Yi wrote: We use the cache upon suspend to cache the firmware so that upon resume a request will use that cache, to avoid the file lookup on disk. Doing a test with qemu suspend + resume is possible but

Re: [PATCHv2 0/3] Enable no_cache flag to driver_data

2017-06-07 Thread Luis R. Rodriguez
On Tue, Jun 06, 2017 at 02:31:54PM -0500, Li, Yi wrote: > > We use the cache upon suspend to cache the firmware so that upon resume a > > request will use that cache, to avoid the file lookup on disk. Doing a test > > with qemu suspend + resume is possible but that requires having access to > > the

Re: [PATCHv2 0/3] Enable no_cache flag to driver_data

2017-06-06 Thread Li, Yi
Hi Luis, On 5/24/2017 2:03 PM, Luis R. Rodriguez wrote: On Sat, May 20, 2017 at 01:46:56AM -0500, yi1...@linux.intel.com wrote: From: Yi Li Changes in v2: - Rebase to Luis R. Rodriguez's 20170501-driver-data-try2 branch - Expose DRIVER_DATA_REQ_NO_CACHE flag to public driver

Re: [PATCHv2 0/3] Enable no_cache flag to driver_data

2017-05-26 Thread Li, Yi
hi Luis On 5/25/2017 5:43 PM, Luis R. Rodriguez wrote: On Thu, May 25, 2017 at 3:30 PM, Li, Yi wrote: This patch is for "disabling the cache" for streaming and iwlwifi case, adding the test to verify the cache function should be a separate patch, right? I can look more into the cache part. H

Re: [PATCHv2 0/3] Enable no_cache flag to driver_data

2017-05-26 Thread Luis R. Rodriguez
On Fri, May 26, 2017 at 04:05:43PM -0500, Li, Yi wrote: > hi Luis > > > On 5/25/2017 5:43 PM, Luis R. Rodriguez wrote: > > On Thu, May 25, 2017 at 3:30 PM, Li, Yi wrote: > > > This patch is for "disabling the cache" for streaming and iwlwifi case, > > > adding the test to verify the cache functi

Re: [PATCHv2 0/3] Enable no_cache flag to driver_data

2017-05-25 Thread Luis R. Rodriguez
On Thu, May 25, 2017 at 3:30 PM, Li, Yi wrote: > This patch is for "disabling the cache" for streaming and iwlwifi case, > adding the test to verify the cache function should be a separate patch, > right? I can look more into the cache part. How can we know cache was disabled without first testin

Re: [PATCHv2 0/3] Enable no_cache flag to driver_data

2017-05-25 Thread Li, Yi
hi Luis On 5/24/2017 2:03 PM, Luis R. Rodriguez wrote: On Sat, May 20, 2017 at 01:46:56AM -0500, yi1...@linux.intel.com wrote: From: Yi Li Changes in v2: - Rebase to Luis R. Rodriguez's 20170501-driver-data-try2 branch - Expose DRIVER_DATA_REQ_NO_CACHE flag to public driver_

Re: [PATCHv2 0/3] Enable no_cache flag to driver_data

2017-05-24 Thread Luis R. Rodriguez
On Wed, May 24, 2017 at 09:03:57PM +0200, Luis R. Rodriguez wrote: > __fw_lookup_buf() really should be > renamed to something that reflects this is a cache lookup. Actually I take this back, other than the cache, note that when we fw_lookup_and_allocate_buf() we first __fw_lookup_buf() but if the

Re: [PATCHv2 0/3] Enable no_cache flag to driver_data

2017-05-24 Thread Luis R. Rodriguez
On Sat, May 20, 2017 at 01:46:56AM -0500, yi1...@linux.intel.com wrote: > From: Yi Li > > Changes in v2: > > - Rebase to Luis R. Rodriguez's 20170501-driver-data-try2 > branch > - Expose DRIVER_DATA_REQ_NO_CACHE flag to public > driver_data_req_params structure, so upper drivers ca

[PATCHv2 0/3] Enable no_cache flag to driver_data

2017-05-19 Thread yi1 . li
From: Yi Li Changes in v2: - Rebase to Luis R. Rodriguez's 20170501-driver-data-try2 branch - Expose DRIVER_DATA_REQ_NO_CACHE flag to public driver_data_req_params structure, so upper drivers can ask driver_data driver to bypass the internal caching mechanism. This will be