From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 5F9EF21942330 for ; Thu, 6 Apr 2017 11:02:21 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id y18so380876itc.1 for ; Thu, 06 Apr 2017 11:02:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=H3V80MkjfO0UCQw8L12WJSPxlQHSptt10oSbpEu/aSc=; b=RZd+atJwCKkeLEcj9UGJSBBCQJp3kgZA51kkCU4hfPjn1EhlyJxQoPVVZ358Ja/qOX 8ncZNn+QOHZ97xKHUCfOX9HVyAGkGN5zp5OF68YSjPLWycU1LcobAyDScvugOV6bA3lC 12ihA+1dUZmY3HVZSfntEcVxXk3uMO6i2750c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=H3V80MkjfO0UCQw8L12WJSPxlQHSptt10oSbpEu/aSc=; b=WR+B5dXjcHN/V/YE390kpWhwIVzc1pbnDYnpR5m5miv0yFV5jLDiD8KNcUI3boXGmf ETn6z48N1O/1Wo2XkLh6/+sAQaIkrkChcx6GlRDCl/0uyORixoFu/1CYvh6fELNU/uOz oIM66assMkohgF0lNYsepqwQki2xR4DFj8KqS6x226DSbeSMov643uxys6C3vGmHYYVk /3/xQcOrhwjmFUaQoAavE4d3Zv60zkB4gXnIIcIWEDPrZQxU4QGONegiTyfa/HZxQTzz xqDOcx/dckCdp3xcmknJcLuo/S/vCBUS6hAXGB0u84ICGxdsDpz7e7j8VLCd80wJMprS IHPQ== X-Gm-Message-State: AFeK/H3IESSs5iyZt/+czXjV3eWYvYpKnL60fU09izJzm7yJYKNwslaJ+nZxJSIYzccUOwOCLyTQ/PixFol2zo1W X-Received: by 10.36.27.196 with SMTP id 187mr11521606its.37.1491501740686; Thu, 06 Apr 2017 11:02:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.10.27 with HTTP; Thu, 6 Apr 2017 11:02:20 -0700 (PDT) In-Reply-To: <48c48135-3cb6-75ad-c13d-7f5df83e9c36@arm.com> References: <20170406131551.3322-1-ard.biesheuvel@linaro.org> <48c48135-3cb6-75ad-c13d-7f5df83e9c36@arm.com> From: Ard Biesheuvel Date: Thu, 6 Apr 2017 19:02:20 +0100 Message-ID: To: Jeremy Linton Cc: "edk2-devel@lists.01.org" , Leif Lindholm , Ryan Harkin , Evan Lloyd Subject: Re: [PATCH v2 0/5] ArmPlatformPkg: map VRAM using memory semantics X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 18:02:21 -0000 Content-Type: text/plain; charset=UTF-8 On 6 April 2017 at 17:29, Jeremy Linton wrote: > Hi, > > On 04/06/2017 08:15 AM, Ard Biesheuvel wrote: >> >> As reported by Jeremy, the recently introduced accelerated memcpy/memset >> routines are causing problems when used on framebuffer memory. While >> framebuffers are arguably right on the blurry line between MMIO (with >> side effects that are sensitive to ordering) and memory, mapping VRAM >> as device memory is unnecessary to begin with, and so we can improve >> our situation by using memory semantics for the VRAM mappings. (Whether >> we end up reverting to the unaccelerated memcpy/memset routines is a >> separate matter) >> >> So fix both the FVP case, which has a separate VRAM region, and TC2, which >> allocates VRAM from normal memory and changes the mapping attributes. >> >> Note to Ryan: this fixes FVP Base model for me, but not the Foundation >> model >> (whose PL111 support I never saw working to begin with, so I am not sure >> what >> is going on there) > > > So, I applied a similar set of patches against the juno, and everything > continues to work. The change also looks good. > > So, > > Reviewed-by: Jeremy Linton > Thanks! > > But I'm still concerned in general, since the HDLCD frame buffer is odd in > that its just system memory rather than being attached to an IO bus of some > form. AKA its not actually a "VRAM" (cue discussion about GDDR not having > multiple ports/etc)... >