Received: by 2002:a05:6358:45e:b0:b5:b6eb:e1f9 with SMTP id 30csp1671930rwe; Fri, 2 Sep 2022 01:33:54 -0700 (PDT) X-Google-Smtp-Source: AA6agR5zSrXdoW312egkrZ+rFEunqgRAUT8cSYNe3h0ZhlOUlnYXcn9WLDLhMxmJQrHoAOS/vYL3 X-Received: by 2002:a17:906:c14f:b0:741:8829:6a97 with SMTP id dp15-20020a170906c14f00b0074188296a97mr16943074ejc.232.1662107634346; Fri, 02 Sep 2022 01:33:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1662107634; cv=none; d=google.com; s=arc-20160816; b=wYlsPCX7MnAQak/kWrKGMAd7Vmu2UACExQGv7UBzjiUG+aeXJyjMXrYN3Vmq0Obj8Z jHnx74VrFGexhPEPkbZwhrFTEwln9L+SACBTHGJPmYyL3NOb69JieTdaJcJSnRsIO6xz Ygksvgbm80QanwKYNGrZWzZURzbevnbFR4FLh8EfVJuy3jS0kIqmivRtNozRNCspNCHj 9orPINbFtO9j+5SPu5YcnZjKW3yxos3FFZ2OgsKoqPQPQC5kqgMZhvq3e0HF5ANmv2dF ZIpOMxTZ/xQ71TYfe1NCCWC1JqlTqT/Jn4Am+Xl9UL1hUbP7iFRiTSB45z0sKUd+m98z DxMg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=yZ7GI/H/npr8l+qVhno9QYWaE882wgaDO0sWPEtrVzI=; b=uEpCKsB4HQzFZrZhhQdO+CapKo9kjSQ1H9+1PfMlmiRlKSUMKrCK3yN7WvxGwbb6KE ijs+H+wmCz4vXqbVu7/A9986l4K+q/NVar+DBxn4SzZMtcgF6H0CXRvOv3YULO+lfId4 tc9i3oqZJ4ts2BELX/VYxdnxdCziI6SEjTuheP78AJm6zwXxiiuTdK/HsdcTaqmvJ4a/ 4BQ7S6+S89tRAxwk5NnZbDwomuoaX2Ri4z4DA65dyk7khrUBpPrFqEZNdkenXMGyAAdq BpYNNoWHrjXJYo65wcE+Fahcbq33zYrRmx70TVwav2OM6mgQsSKfm22LWdaTkz+J/62j L9+w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=gBY8OG2X; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id x21-20020a170906b09500b0074164fd241esi1190200ejy.230.2022.09.02.01.33.24; Fri, 02 Sep 2022 01:33:54 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=gBY8OG2X; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235690AbiIBI0G (ORCPT + 99 others); Fri, 2 Sep 2022 04:26:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51752 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234788AbiIBI0D (ORCPT ); Fri, 2 Sep 2022 04:26:03 -0400 Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 60B5B57201 for ; Fri, 2 Sep 2022 01:26:02 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id w19so1497242ljj.7 for ; Fri, 02 Sep 2022 01:26:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=yZ7GI/H/npr8l+qVhno9QYWaE882wgaDO0sWPEtrVzI=; b=gBY8OG2XpP3vttfs1RSHEWup1a1iLXJ18Xy6iShnIE/HNIwJph+Hjv9vUaXz/axDCA iVd1PNmFNZKCy8mr44bY9s780B3kBdRpDdSAJLWzZqHmPPNv0MmgLE8FgQmGk6MeCYim eQbCsVHw1nBiOsX3PwmKhBjTPYGZVbKvKvCNCB/j2NGcUvVfUG4QtfkZm/n90RiUuuse +6ym92aIJpO96LxYalFyXhF3gMayHDtAM6TI9mvOcTspQlr/goaxcGLOxLzkGjyKhYiq 8M4XEf/deUHsFxD1OItXh9OiVX+tlJIFa2OFbUvSmaoB/oipSXfs/TyVEQ1VFlQH8aM6 HOjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=yZ7GI/H/npr8l+qVhno9QYWaE882wgaDO0sWPEtrVzI=; b=3WFVq33qqjLlfq86ZjQeyk6EBwi+wtewx0g6i1MTUnB4aE9rdq7NrnfOieb2z21eWU trgbQ7pnjaoQV+q05d+JZcZ0RCFbWBKCVw3h8OTDK3ZbN8iFedqdg6q+vr9GC829jqcg SBw92MGw81GwFNmOHG7L1GmkqBZlQjtm1I0PQUN+Xr+q5rbKKT8xazzMmvy9suAa+9mN 8Wo07JaB41NzPGO6/3od7oMqXVpnQRGdLsW3OPt4GH/zx1XYAm3/DLjEgpNsr0jPRNwc iXqtsRcwjX7sy7fXOcZ2r4JenUa6v8ecCVLEJ1hM0+mD7D5MemtqInxcrQ7BJ4VKnhwf L4oA== X-Gm-Message-State: ACgBeo1wRgU2KZVbRHDmc6BgPU7KFAeo7W/ya573gnuqOqK8EJOeMfrF 3X7N4SBS9IXe7RzOfOq9hvcslihRFAJ17HbdZVQ= X-Received: by 2002:a2e:9e48:0:b0:261:c713:37dd with SMTP id g8-20020a2e9e48000000b00261c71337ddmr10154143ljk.385.1662107160591; Fri, 02 Sep 2022 01:26:00 -0700 (PDT) MIME-Version: 1.0 References: <20220806122636.43068-1-tomas.winkler@intel.com> <20220806122636.43068-15-tomas.winkler@intel.com> In-Reply-To: <20220806122636.43068-15-tomas.winkler@intel.com> From: Matthew Auld Date: Fri, 2 Sep 2022 09:25:33 +0100 Message-ID: Subject: Re: [Intel-gfx] [PATCH v7 14/15] drm/i915/gsc: allocate extended operational memory in LMEM To: Tomas Winkler Cc: Greg Kroah-Hartman , David Airlie , Daniel Vetter , Alan Previn , Intel Graphics Development , Alexander Usyskin , kernel list , Rodrigo Vivi , Vitaly Lubart Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 6 Aug 2022 at 13:34, Tomas Winkler wrote: > > GSC requires more operational memory than available on chip. > Reserve 4M of LMEM for GSC operation. The memory is provided to the > GSC as struct resource to the auxiliary data of the child device. > > Cc: Alan Previn > Signed-off-by: Tomas Winkler > Signed-off-by: Daniele Ceraolo Spurio > Signed-off-by: Alexander Usyskin > --- > drivers/gpu/drm/i915/gt/intel_gsc.c | 91 ++++++++++++++++++++++++++--- > drivers/gpu/drm/i915/gt/intel_gsc.h | 3 + > 2 files changed, 87 insertions(+), 7 deletions(-) > > diff --git a/drivers/gpu/drm/i915/gt/intel_gsc.c b/drivers/gpu/drm/i915/gt/intel_gsc.c > index e1040c8f2fd3..162bea57fbb5 100644 > --- a/drivers/gpu/drm/i915/gt/intel_gsc.c > +++ b/drivers/gpu/drm/i915/gt/intel_gsc.c > @@ -7,6 +7,7 @@ > #include > #include "i915_drv.h" > #include "i915_reg.h" > +#include "gem/i915_gem_region.h" > #include "gt/intel_gsc.h" > #include "gt/intel_gt.h" > > @@ -36,12 +37,68 @@ static int gsc_irq_init(int irq) > return irq_set_chip_data(irq, NULL); > } > > +static int > +gsc_ext_om_alloc(struct intel_gsc *gsc, struct intel_gsc_intf *intf, size_t size) > +{ > + struct intel_gt *gt = gsc_to_gt(gsc); > + struct drm_i915_gem_object *obj; > + void *vaddr; > + int err; > + > + obj = i915_gem_object_create_lmem(gt->i915, size, I915_BO_ALLOC_CONTIGUOUS); > + if (IS_ERR(obj)) { > + drm_err(>->i915->drm, "Failed to allocate gsc memory\n"); > + return PTR_ERR(obj); > + } > + > + err = i915_gem_object_pin_pages_unlocked(obj); > + if (err) { > + drm_err(>->i915->drm, "Failed to pin pages for gsc memory\n"); > + goto out_put; > + } > + > + vaddr = i915_gem_object_pin_map_unlocked(obj, i915_coherent_map_type(gt->i915, obj, true)); > + if (IS_ERR(vaddr)) { > + err = PTR_ERR(vaddr); > + drm_err(>->i915->drm, "Failed to map gsc memory\n"); > + goto out_unpin; > + } > + > + memset(vaddr, 0, obj->base.size); > + > + i915_gem_object_unpin_map(obj); I think this was mentioned before, here we should rather use: create_lmem(gt->i915, size, I915_BO_ALLOC_CONTIGUOUS | I915_BO_ALLOC_CPU_CLEAR); That way we don't need to manually map and clear it here. Instead when first allocating the pages (like with pin_pages), the clear will be done for you.