Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp1709412pxb; Mon, 23 Aug 2021 02:43:16 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzIy74nLbGhjOtmBYcuAp4qV8pw+g/fpGiwac/b6f4F87zKLSfkxqP6GuAr3Yt95omVPj3l X-Received: by 2002:a02:c61a:: with SMTP id i26mr29390490jan.108.1629711796155; Mon, 23 Aug 2021 02:43:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1629711796; cv=none; d=google.com; s=arc-20160816; b=C2KpXhvTwUfs1eTXXLMmU7rrOtJvBTM9ajFejjfkalcY50VDLLoTQQYmEAVDmFJG/0 A1vdg6DF+szz3xZcLRIupmSjiREPwUYnxILwSbmirEnZzbq+JcAfJZ02YRe0GnHhV3z+ xlinuQ03mnn7aTUrHgzTahqgwOYOBLkP9HiK9sFQnHWySAaJbIWmANw4KUH+r/PJjQ6G 4MsoLVl11p7ZCFFvE2G0BpKSYM9gUwcL+zDPLp5z7qd09iPCJndRw15t/DGcvEeII47F 6MrmqvQKK1wMZ8/k7xjL4hEJfyrnThurNJRzAeS2CKyJK4hbUKhl0Y2/jlsAW0AKwQ43 2+xA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=EDre6iTqwwiNwmJnGnYfxeLGnnpijruwQh/g0kMYHA0=; b=tq/n7c00CrtVwR6f9HT2YULrwrMUwQEn7hxpIAsv0IidzMcaUWU/r6VxDHAPmE6P5U DK9EYahwrb0/NSdaQ0cpSn8dMHRRgn2nevok5ALZHmDb/bNk3Sj8gKYrKGqbJiJd0LEf UEBxc+7Ja3N6N9P5G+OWBlTPCts98k64HmbH5U6xKVa7WKHrFP8ECX3Ph1hnuV4YTtZS i/Ka7fHi8FvrVYg4JO1HbFZVoqfTAIdobxlWOh9iTGYUWUSYKBpD086eyvSxdKdI35mi 1YORbHKtjFhz92gBtA9+VxtGW/NGGPUtmrzkINpdW6HqW5Oydz8eJLf6AiGaImPtWRGh 3wJA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m12si3153047ioj.96.2021.08.23.02.43.05; Mon, 23 Aug 2021 02:43:16 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235913AbhHWJlt (ORCPT + 99 others); Mon, 23 Aug 2021 05:41:49 -0400 Received: from foss.arm.com ([217.140.110.172]:50576 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235872AbhHWJlo (ORCPT ); Mon, 23 Aug 2021 05:41:44 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 4D0A06D; Mon, 23 Aug 2021 02:41:02 -0700 (PDT) Received: from [192.168.1.179] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 06D0E3F66F; Mon, 23 Aug 2021 02:41:00 -0700 (PDT) Subject: Re: [PATCH 3/3] drm/panfrost: Clamp lock region to Bifrost minimum To: Alyssa Rosenzweig , dri-devel@lists.freedesktop.org Cc: Rob Herring , Tomeu Vizoso , David Airlie , Daniel Vetter , linux-kernel@vger.kernel.org, Chris Morgan , stable@vger.kernel.org References: <20210820213117.13050-1-alyssa.rosenzweig@collabora.com> <20210820213117.13050-4-alyssa.rosenzweig@collabora.com> From: Steven Price Message-ID: <818b1a15-ddf4-461b-1d6a-cea539deaf76@arm.com> Date: Mon, 23 Aug 2021 10:40:59 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <20210820213117.13050-4-alyssa.rosenzweig@collabora.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 20/08/2021 22:31, Alyssa Rosenzweig wrote: > When locking a region, we currently clamp to a PAGE_SIZE as the minimum > lock region. While this is valid for Midgard, it is invalid for Bifrost, While the spec does seem to state it's invalid for Bifrost - kbase didn't bother with a lower clamp for a long time. I actually think this is in many ways more of a spec bug: i.e. implementation details of the round-up that the hardware does. But it's much safer following the spec ;) And it seems like kbase eventually caught up too. > where the minimum locking size is 8x larger than the 4k page size. Add a > hardware definition for the minimum lock region size (corresponding to > KBASE_LOCK_REGION_MIN_SIZE_LOG2 in kbase) and respect it. > > Signed-off-by: Alyssa Rosenzweig > Tested-by: Chris Morgan > Cc: Reviewed-by: Steven Price > --- > drivers/gpu/drm/panfrost/panfrost_mmu.c | 2 +- > drivers/gpu/drm/panfrost/panfrost_regs.h | 2 ++ > 2 files changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c b/drivers/gpu/drm/panfrost/panfrost_mmu.c > index 3a795273e505..dfe5f1d29763 100644 > --- a/drivers/gpu/drm/panfrost/panfrost_mmu.c > +++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c > @@ -66,7 +66,7 @@ static void lock_region(struct panfrost_device *pfdev, u32 as_nr, > /* The size is encoded as ceil(log2) minus(1), which may be calculated > * with fls. The size must be clamped to hardware bounds. > */ > - size = max_t(u64, size, PAGE_SIZE); > + size = max_t(u64, size, AS_LOCK_REGION_MIN_SIZE); > region_width = fls64(size - 1) - 1; > region |= region_width; > > diff --git a/drivers/gpu/drm/panfrost/panfrost_regs.h b/drivers/gpu/drm/panfrost/panfrost_regs.h > index 1940ff86e49a..6c5a11ef1ee8 100644 > --- a/drivers/gpu/drm/panfrost/panfrost_regs.h > +++ b/drivers/gpu/drm/panfrost/panfrost_regs.h > @@ -316,6 +316,8 @@ > #define AS_FAULTSTATUS_ACCESS_TYPE_READ (0x2 << 8) > #define AS_FAULTSTATUS_ACCESS_TYPE_WRITE (0x3 << 8) > > +#define AS_LOCK_REGION_MIN_SIZE (1ULL << 15) > + > #define gpu_write(dev, reg, data) writel(data, dev->iomem + reg) > #define gpu_read(dev, reg) readl(dev->iomem + reg) > >