From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yx1-f54.google.com (mail-yx1-f54.google.com [74.125.224.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C0C9D3B777B for ; Wed, 13 May 2026 19:31:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=74.125.224.54 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778700706; cv=pass; b=BS7InecDHWSYaP/sU2aLrQ4DJWu+VQE7LwIwRYtGjPkZoa3GhE187QfEkJYwugsrYaMRb+IsUq1Lh8O9Gv37qgqpE+ccX4z7PqmfzQeU2hojtISWqbT1fnAkfpf/gyY0haNny+6+yXcF02k8TaPZSc3cWy8F9G6rjwByHY6PupU= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778700706; c=relaxed/simple; bh=Fk0M2dahXXkA0FzmVrTU+eVu8F5ePwC5MGTDU99/VtQ=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=CkCdDTUOe4AwbAUOxOOYLzx1nSyXOJr9TYHvzUzWG8MWBhgHNPpOKNWY7CMhnEtLBOJgDf3chuN5rBXVyxw+qfWNFRfr5X4owXSGMKalbEJcPIrIm6cIlYLQ2nmPAz/ykFep4km65/fBlp8cjOYe5Cnb6gtBPMhRsPJuRbbnamo= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=cbAGDnbc; arc=pass smtp.client-ip=74.125.224.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="cbAGDnbc" Received: by mail-yx1-f54.google.com with SMTP id 956f58d0204a3-6579254f996so4690038d50.1 for ; Wed, 13 May 2026 12:31:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1778700704; cv=none; d=google.com; s=arc-20240605; b=aX6N09vVBbl7sYSZBvGHYv4E4XC3GV4w2QwEAQb0ivPAcbsJ6jaQp1nu80x+iFUnHn XR3cxOC/KNr4r4lRydIrBtSIkpvukAxtt/O4VRYLRVx2KjslZlh7SBmZIoPqMRBn2oEz oB/3c+8fYfLbSSt5nZWuEtkyxLTIohqkXBLricjRunZip2y7Ll7iiALuW9czpVWfObqH h43NV+8GZkA0lF0Qw08eXKLHRyvqAY5/gM1XV7bRIoo2Bl1DG6Jfv5NnCnPoNI5Zmkwp 1zANy/GXMPCgZiZXi7+FMeA1qxUKqqZs0vy/Xz8yM2Z7gRoXWKc2GRYsLnMhQwmTYets 7D6A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=g4Y3i2VzEUpUrHnVXfd2puXKp9894xeLrJot7HkksF4=; fh=tCMrXe8xTyZDhyGx4ELl3S1HdI59J4mzKNcaMMK59Zc=; b=DzfCknaK9BAmJ2vRper1t5/ULRkcvxpwt0Qq8sUA+r9Zx2FgfYnatztg9m7F1qACrZ 4f3WuHuzKsMxkK40hb9iAoC2Pabhi5oo0q0PFB8HasyGt868VsOB+3I7yIrwaPS3N9/y Acj24LQRkVxYctFt8tUCOaF+NGJN5ww5kofVfQMUNz1zm/1eU8NuJhcfEgXyDZxyWs5o z73i3LE/JNipHRXMRYvTm6LmuMoIOirqetYo/fkp3gkRSPVwq8jiPazGfD9/4QtF+j4S m5ZfQ39d4pY3Dsk29KxyYKownsyL5g48JfW7qTcgu8SIHZ0g835hJiY7bn5lEF3+QJzT GCLw==; darn=vger.kernel.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1778700704; x=1779305504; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=g4Y3i2VzEUpUrHnVXfd2puXKp9894xeLrJot7HkksF4=; b=cbAGDnbc9zpvmC2GS6AwSjpegkTu7dCD1Kaql9tb5ryHVu9YliSoFrd8aC1nXCxeQz P+Y37Dyv6wAO9evtjgWBCofjkwxOhzTGbMfCD0q9zsCea3MCZhayzAzreECavBu0Sto0 PXaJJhgSvX10X5//H0gNMaDApwvcIEr4GzFHBzjC4t5KrtX7TFZ4Z4zu7La2Bbf3jNRP n8bpwFGQFMY6r/ZjTpP58SQYx3zXQ2rVeXVRbi0JQkl5F18MSXXxNychInBtg1C4i2qD O+DrwttVupz8Usp2FmZPl6sKpRdZCusInItRuUcTsIWtQlCVf5/3I7AkK9QhdPBUukYl CCPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778700704; x=1779305504; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=g4Y3i2VzEUpUrHnVXfd2puXKp9894xeLrJot7HkksF4=; b=PG5Vbt2Lu4Cl+G+/U0Y5vdnn8h5Q58lkuGDD1ZGKCTNB8xNKUVRnR+Wn+zkTrQk8ck tYq+iC0V1a2r+5ETnCv40tkABmb+tynULXviOM0PJwE5cGmiXjjs3D46f86U9Yxd7oz0 EBOV6QvB4a/Zc8VQA4EwS/0rhv0srta48ryy+Ctsy46pAa7ltmPpB8J4DRraMqXdCES8 EMbua+AnOn8Y4ew7d3bPmXS7aKoPBfGQ2HxVsQeva8j5Lf+WUX/JkwJCJQazc5IMwuyf 7BVW97PhBZ61opGOwzZy8UN2m3ne8Nd9Eh4pFH2BNc2rtoywFKB6jibJEFlve1+E3B8q zQRw== X-Forwarded-Encrypted: i=1; AFNElJ/oejo2bO6d/KNuZWu8n7Xd1qgUAYS7fT84YI6iLckYECGMdtKdRVBjL+AvkB71IMazIOVTUFllvThQ19A=@vger.kernel.org X-Gm-Message-State: AOJu0YzQUFIuD1H5T8JtMeKgXiVYzciydmbshlQi7t/16bksp7jSQ/rt ILzSfEeGl7oP2Ee2rrNU0EAG5fgvg0eLhW47NNPDIbGEnZXsWhQnRcAnr3eszG3XhhlOj5ZuFfw avrp1cL0dXZ+evNjEetixVhzRf3ABmI8= X-Gm-Gg: Acq92OFOiSxZ/Y+TpgSkK1RQTlhgEBrE5L1SYsrzeNV5dHeHQfN9jfWtPDILoDex6vP R9YqtDPruJkhPohfZWW2NXYZx5S5+8rXOAZioc7DVRa/m9m1x8xZyaF1K+8tyDRfXM3m1IekgOP BHHmqtUjQ0hOIrKUb3RC9Fx4OpGVrvrfqAjBa79U/umyfpQ6Ih8o52/6RKNP+2I0EHl+Byq7jCH a1vE04X/6l7skjt0mHBfBSu/9C6PqNzY4RW6sMt+qDnN+U9H51yb9XInlHoqh9W8ZpeYhgCXfD3 7C51GPTZCrO1yxHD1lB3/XWzQPmqXxdKfHgCCUcwemNKXA6FfH14VhsZV7uEQuFwVlMjEGPd1A= = X-Received: by 2002:a05:690c:38b:b0:7bd:a50c:454c with SMTP id 00721157ae682-7c6da2152a8mr42579647b3.19.1778700703738; Wed, 13 May 2026 12:31:43 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20260505140516.1372388-1-ketil.johnsen@arm.com> <20260505140516.1372388-5-ketil.johnsen@arm.com> <20260505181523.49a3d85c@fedora> <20260507135356.5428d50d@fedora> <20260512161111.0cb7000e@fedora> In-Reply-To: From: Chia-I Wu Date: Wed, 13 May 2026 12:31:32 -0700 X-Gm-Features: AVHnY4JH8Ip_tVhSu6utyw5cZH7Mreif1YmCt2t2xjBKPcGuoTWdGxm_i0T-RLg Message-ID: Subject: Re: [PATCH 4/8] drm/panthor: Add support for protected memory allocation in panthor To: Liviu Dudau Cc: Boris Brezillon , =?UTF-8?Q?Marcin_=C5=9Alusarz?= , Ketil Johnsen , David Airlie , Simona Vetter , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , Jonathan Corbet , Shuah Khan , Sumit Semwal , Benjamin Gaignard , Brian Starkey , John Stultz , "T.J. Mercier" , =?UTF-8?Q?Christian_K=C3=B6nig?= , Steven Price , Daniel Almeida , Alice Ryhl , Matthias Brugger , AngeloGioacchino Del Regno , dri-devel@lists.freedesktop.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, linaro-mm-sig@lists.linaro.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, Florent Tomasin , nd@arm.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, May 12, 2026 at 8:39=E2=80=AFAM Liviu Dudau w= rote: > > On Tue, May 12, 2026 at 04:11:11PM +0200, Boris Brezillon wrote: > > On Tue, 12 May 2026 14:47:27 +0100 > > Liviu Dudau wrote: > > > > > On Thu, May 07, 2026 at 01:53:56PM +0200, Boris Brezillon wrote: > > > > On Thu, 7 May 2026 11:02:26 +0200 > > > > Marcin =C5=9Alusarz wrote: > > > > > > > > > On Tue, May 05, 2026 at 06:15:23PM +0200, Boris Brezillon wrote: > > > > > > > @@ -277,9 +286,21 @@ int panthor_device_init(struct panthor_d= evice *ptdev) > > > > > > > return ret; > > > > > > > } > > > > > > > > > > > > > > + /* If a protected heap name is specified but not found, d= efer the probe until created */ > > > > > > > + if (protected_heap_name && strlen(protected_heap_name)) { > > > > > > > > > > > > Do we really need this strlen() > 0? Won't dma_heap_find() fail= is the > > > > > > name is "" already? > > > > > > > > > > If dma_heap_find() will fail, then the whole probe with fail too. > > > > > This check prevents that. > > > > > > > > Yeah, that's also a questionable design choice. I mean, we can > > > > currently probe and boot the FW even though we never setup the > > > > protected FW sections, so why should we defer the probe here? Can't= we > > > > just retry the next time a group with the protected bit is created = and > > > > fail if we can find a protected heap? > > > > > > The problem we have with the current firmware is that it does a numbe= r of setup steps at "boot" > > > time only. One of the steps is preparing its internal structures for = when it enters protected > > > mode and it stores them in the buffer passed in at firmware loading. = We cannot later run the > > > process when we have a group with protected mode set. > > > > No, but we can force a full/slow reset and have that thing > > re-initialized, can't we? I mean, that's basically what we do when a > > fast reset fails: we re-initialize all the sections and reset again, at > > which point the FW should start from a fresh state, and be able to > > properly initialize the protected-related stuff if protected sections > > are populated. Am I missing something? > > Right, we can do that. For some reason I keep associating the reset with = the > error handling and not with "normal" operations. I kind of hope we end up with either - panthor knows the exact heap to use and fails with EPROBE_DEFER if the heap is missing, or - panthor gets a dma-buf from userspace and does the full reset - userspace also needs to provide a dma-buf for each protected group for the suspend buffer than something in-between. The latter is more ad-hoc and basically kicks the issue to the userspace. For the former, expressing the relation in DT seems to be the best, but only if possible :-). Otherwise, a kconfig option (instead of module param) should be easier to work with. Looking at the userspace implementation, can we also have an panthor ioctl to return the heap to userspace? A dma-heap ioctl to query the heap size is also lacking. > > Best regards, > Liviu > > > -- > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > | I would like to | > | fix the world, | > | but they're not | > | giving me the | > \ source code! / > --------------- > =C2=AF\_(=E3=83=84)_/=C2=AF >