From patchwork Thu Apr 6 13:15:46 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ard Biesheuvel X-Patchwork-Id: 96956 Delivered-To: patch@linaro.org Received: by 10.140.89.233 with SMTP id v96csp726332qgd; Thu, 6 Apr 2017 06:16:10 -0700 (PDT) X-Received: by 10.99.147.16 with SMTP id b16mr36649693pge.126.1491484570171; Thu, 06 Apr 2017 06:16:10 -0700 (PDT) Return-Path: Received: from ml01.01.org (ml01.01.org. [2001:19d0:306:5::1]) by mx.google.com with ESMTPS id g3si1850107pgf.153.2017.04.06.06.16.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Apr 2017 06:16:10 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of edk2-devel-bounces@lists.01.org designates 2001:19d0:306:5::1 as permitted sender) client-ip=2001:19d0:306:5::1; Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) header.i=@linaro.org; spf=pass (google.com: best guess record for domain of edk2-devel-bounces@lists.01.org designates 2001:19d0:306:5::1 as permitted sender) smtp.mailfrom=edk2-devel-bounces@lists.01.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: from [127.0.0.1] (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id 70C1E2194235E; Thu, 6 Apr 2017 06:16:09 -0700 (PDT) X-Original-To: edk2-devel@lists.01.org Delivered-To: edk2-devel@lists.01.org Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (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 775E321A6F108 for ; Thu, 6 Apr 2017 06:16:07 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id t189so8824734wmt.1 for ; Thu, 06 Apr 2017 06:16:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id; bh=B83vNOj+4dYTah1Vz/5vzW04T1tTyHdJFwjzXrsuJpQ=; b=hSDaien+mnrjMQHfxff/VE+j5dXI7ukH0sRqXeMSNwTwafceIiDA/kCxxjjbHEd4aW dOMw6YhUyMXacF9Wjofb71vg2yHKObrISHiEmYSgyu2Wo/AhNT/UR5bg4BMhPnXNdFwD guFmoU3VzKZXPDzKUm4DOpeKYfg7spKYOQ9tE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=B83vNOj+4dYTah1Vz/5vzW04T1tTyHdJFwjzXrsuJpQ=; b=N/3nEUjHLhhjygCWhWAutOP1t5Uhd3CrpvBz1Zr5Tzj1K1yAaTCPKubHmJCOaxULvx DE+VUTmIF9jopWzNLTZhBf4EbQptOzT8RfRndJjifxQGo8X/vnFpm8bJJlpox10klFow Yknkyue0iXYVOa7J8uT1G9WL4hS14d4IEZTG818Ea5/LNFJvJkj7ZClNUD6CY2BBmDsZ amOze3uGbCdQG7MykB1K3XO3v14UlSHhBnDv4pY5sHaOpHtyVEi6a9Uu/gxwm2cWdMo9 cWQVqHfa7qiq8RkkJiKM6G7y6U7f29u/8gtUgPkTOSiesvwSpdsqm4S/5+shoxsNDr+4 Anhw== X-Gm-Message-State: AFeK/H2COtH7scD9pfpq5khGOIotXELMsj0Eh7pP/1F/huZxLNC9w3WWOBgXbnxyiaez+APX X-Received: by 10.28.167.216 with SMTP id q207mr20456347wme.134.1491484565830; Thu, 06 Apr 2017 06:16:05 -0700 (PDT) Received: from localhost.localdomain ([160.163.145.113]) by smtp.gmail.com with ESMTPSA id c8sm2087660wrd.57.2017.04.06.06.16.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Apr 2017 06:16:04 -0700 (PDT) From: Ard Biesheuvel To: edk2-devel@lists.01.org, leif.lindholm@linaro.org, ryan.harkin@linaro.org, evan.lloyd@arm.com, jeremy.linton@arm.com Date: Thu, 6 Apr 2017 14:15:46 +0100 Message-Id: <20170406131551.3322-1-ard.biesheuvel@linaro.org> X-Mailer: git-send-email 2.9.3 Subject: [edk2] [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: , Cc: Ard Biesheuvel MIME-Version: 1.0 Errors-To: edk2-devel-bounces@lists.01.org Sender: "edk2-devel" 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) Ard Biesheuvel (5): ArmPlatformPkg/FVP: map motherboard VRAM as uncached memory ArmPlatformPkg/HdLcdArmVExpressLib: fix incorrect FreePool () call ArmPlatformPkg/PL111LcdArmVExpressLib: fix incorrect FreePool () call ArmPlatformPkg/HdLcdArmVExpressLib: use write-combine mapping for VRAM ArmPlatformPkg/PL111LcdArmVExpressLib: use write-combine mapping for VRAM ArmPlatformPkg/ArmVExpressPkg/Include/Platform/RTSM/ArmPlatform.h | 10 ++++++---- ArmPlatformPkg/ArmVExpressPkg/Library/ArmVExpressLibRTSM/RTSMMem.c | 8 +++++++- ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c | 14 +++++--------- ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpressLib.inf | 3 ++- ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c | 14 +++++--------- ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpressLib.inf | 3 ++- 6 files changed, 27 insertions(+), 25 deletions(-) -- 2.9.3 _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel Reviewed-by: Jeremy Linton Tested-by: Ryan Harkin Reviewed-by: Leif Lindholm