From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Gordon Subject: Re: [PATCH v3] drm/i915: resize the GuC WOPCM for rc6 Date: Thu, 5 May 2016 16:04:57 +0100 Message-ID: <572B6119.8010105@intel.com> References: <1461661901-8448-1-git-send-email-peter.antoine@intel.com> <572B4D76.9040708@intel.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1713401291==" Return-path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by gabe.freedesktop.org (Postfix) with ESMTP id BF2BC6E9C8 for ; Thu, 5 May 2016 15:05:39 +0000 (UTC) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: "Antoine, Peter" , "intel-gfx@lists.freedesktop.org" Cc: "Vivi, Rodrigo" List-Id: intel-gfx@lists.freedesktop.org This is a multi-part message in MIME format. --===============1713401291== Content-Type: multipart/alternative; boundary="------------040208060700060706070801" This is a multi-part message in MIME format. --------------040208060700060706070801 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 05/05/2016 15:02, Antoine, Peter wrote: > The attached version still does not explain that the WOPCM_TOP is to tell the GuC not to use that space. That's NOT what WOPCM_TOP means. The GuC is allowed to use the space up to the value stored in the GUC_WOPCM_SIZE register (as the comment above the #define says). Architecturally, this is allowed to be any value greater than (16K+sizeof internal SRAM (64, 128, or 256K)) and less than or equal to GUC_WOPCM_TOP (which is a platform-independent constant), so we normally choose the maximm allowed. Howver on BXT, we need to leave some space at the top for the RC6 image, hence the logic (and comments!) in guc_wopcm_size(). > The extra information does not aid anybody as the information is used internally within the GuC. It may help the next person who has to figure out what's gone wrong on some future chip that needs more than 64K for RC6! .Dave. > > But, I have not actual objection to the patch. > > Peter. > --------------040208060700060706070801 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit
On 05/05/2016 15:02, Antoine, Peter wrote:
The attached version still does not explain that the WOPCM_TOP is to tell the GuC not to use that space.

That's NOT what WOPCM_TOP means. The GuC is allowed to use the space up to the value stored in the GUC_WOPCM_SIZE register (as the comment above the #define says). Architecturally, this is allowed to be any value greater than (16K+sizeof internal SRAM (64, 128, or 256K)) and less than or equal to GUC_WOPCM_TOP (which is a platform-independent constant), so we normally choose the maximm allowed. Howver on BXT, we need to leave some space at the top for the RC6 image, hence the logic (and comments!) in guc_wopcm_size().

 
The extra information does not aid anybody as the information is used internally within the GuC.
It may help the next person who has to figure out what's gone wrong on some future chip that needs more than 64K for RC6!

.Dave.

But, I have not actual objection to the patch.

Peter.

--------------040208060700060706070801-- --===============1713401291== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSW50ZWwtZ2Z4 IG1haWxpbmcgbGlzdApJbnRlbC1nZnhAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vaW50ZWwtZ2Z4Cg== --===============1713401291==--