From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.manjaro.org (mail.manjaro.org [116.203.91.91]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 35DA6178CCF; Wed, 3 Jul 2024 12:42:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=116.203.91.91 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1720010566; cv=none; b=ZcZG7PIMc/dCwB4Ofu+beCt5BmLC2V3O3J1P1/NHuqknzLqxAR+ScJ/WAeB9k92xTYfoKKFbZV6Wkd7VBUh0bXDPCul75aCMaPOvszGt/mQjbEavzvUKF+BNLgDPtWevn4b6fxCcj6J2kg9QGLUpqcUWIT4Z3MP7PU0sr+6HvwE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1720010566; c=relaxed/simple; bh=fgF5tJ5DEDXTYIiL7qd21XjNbHYxNUXjyhHSksjF43M=; h=MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:References: Message-ID:Content-Type; b=NrgQUhEXV6H51mfWpTGhaZ2So1UK6pGi4wwx8lpvOE+SYUxp7d4pTnT8E3masPlxgeXvvl5A8UaSO7S1VqpuorRgHk1N4CZ6Vm3vAdyTJVMf5m3rzTT2vLa7A/pZ7pSede2LyTkxeZ5bZRfr5dKJiatT5/mLmjfRkeWdvlFtnPM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=manjaro.org; spf=pass smtp.mailfrom=manjaro.org; dkim=pass (2048-bit key) header.d=manjaro.org header.i=@manjaro.org header.b=joYWoJIL; arc=none smtp.client-ip=116.203.91.91 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=manjaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=manjaro.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=manjaro.org header.i=@manjaro.org header.b="joYWoJIL" Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manjaro.org; s=2021; t=1720010560; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=3oNe79QFYy0BsgqHNRdTuV4KBXJ2XwhFBof2yObhRJQ=; b=joYWoJILWQcLuVUoMWuHU+2kafxCfq51hIeDwC3CDaRgCIKFzfbT1x+DK57xH+WsoxMc9H 03PQ57rwOw+1z8zxII+rk7yeL/Ev2uhX0X3rMQjwmDECu4tXf5xYGScIrmPaoaeSzapSkL 8O8vWZBJ+qqv5cKZvs7UxZ1L47D1FuzcQO9GEt0abtVAgY/0lLYS6xORI7GcoI3lBNTBp6 KBKXTU2ctDnpGRCp+Kc1pTegYcKzO0+DPWdbVv+v3uvoT6iGddIw+aAcRCNH48TzNxRABP fu6H2NSCFY5hwHV5lyzo6BjLLoTONDf/NG4/CgD9GYGYuDL3O30/2fEUyORAXA== Date: Wed, 03 Jul 2024 14:42:37 +0200 From: Dragan Simic To: dri-devel@lists.freedesktop.org Cc: boris.brezillon@collabora.com, robh@kernel.org, steven.price@arm.com, maarten.lankhorst@linux.intel.com, mripard@kernel.org, tzimmermann@suse.de, airlied@gmail.com, daniel@ffwll.ch, linux-kernel@vger.kernel.org, Diederik de Haas , Furkan Kardame , stable@vger.kernel.org Subject: Re: [PATCH] drm/panfrost: Mark simple_ondemand governor as softdep In-Reply-To: <4e1e00422a14db4e2a80870afb704405da16fd1b.1718655077.git.dsimic@manjaro.org> References: <4e1e00422a14db4e2a80870afb704405da16fd1b.1718655077.git.dsimic@manjaro.org> Message-ID: X-Sender: dsimic@manjaro.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Authentication-Results: ORIGINATING; auth=pass smtp.auth=dsimic@manjaro.org smtp.mailfrom=dsimic@manjaro.org Hello everyone, On 2024-06-17 22:17, Dragan Simic wrote: > Panfrost DRM driver uses devfreq to perform DVFS, while using > simple_ondemand > devfreq governor by default. This causes driver initialization to fail > on > boot when simple_ondemand governor isn't built into the kernel > statically, > as a result of the missing module dependency and, consequently, the > required > governor module not being included in the initial ramdisk. Thus, let's > mark > simple_ondemand governor as a softdep for Panfrost, to have its kernel > module > included in the initial ramdisk. > > This is a rather longstanding issue that has forced distributions to > build > devfreq governors statically into their kernels, [1][2] or has forced > users > to introduce some unnecessary workarounds. [3] > > For future reference, not having support for the simple_ondemand > governor in > the initial ramdisk produces errors in the kernel log similar to these > below, > which were taken from a Pine64 RockPro64: > > panfrost ff9a0000.gpu: [drm:panfrost_devfreq_init [panfrost]] > *ERROR* Couldn't initialize GPU devfreq > panfrost ff9a0000.gpu: Fatal error during GPU init > panfrost: probe of ff9a0000.gpu failed with error -22 > > Having simple_ondemand marked as a softdep for Panfrost may not resolve > this > issue for all Linux distributions. In particular, it will remain > unresolved > for the distributions whose utilities for the initial ramdisk > generation do > not handle the available softdep information [4] properly yet. > However, some > Linux distributions already handle softdeps properly while generating > their > initial ramdisks, [5] and this is a prerequisite step in the right > direction > for the distributions that don't handle them properly yet. > > [1] > https://gitlab.manjaro.org/manjaro-arm/packages/core/linux/-/blob/linux61/config?ref_type=heads#L8180 > [2] https://salsa.debian.org/kernel-team/linux/-/merge_requests/1066 > [3] https://forum.pine64.org/showthread.php?tid=15458 > [4] > https://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git/commit/?id=49d8e0b59052999de577ab732b719cfbeb89504d > [5] > https://github.com/archlinux/mkinitcpio/commit/97ac4d37aae084a050be512f6d8f4489054668ad > > Cc: Diederik de Haas > Cc: Furkan Kardame > Cc: stable@vger.kernel.org > Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver") > Signed-off-by: Dragan Simic Just checking, could this patch be accepted, please? The Lima counterpart has already been accepted. [6] The approach in this patch is far from perfect, but it's still fine until there's a better solution, such as harddeps. I'll continue my research about the possibility for introducing harddeps, which would hopefully replace quite a few instances of the softdep (ab)use that already extend rather far. For example, have a look at the commit d5178578bcd4 (btrfs: directly call into crypto framework for checksumming) [7] and the lines containing MODULE_SOFTDEP() at the very end of fs/btrfs/super.c. [8] If a filesystem driver can rely on the (ab)use of softdeps, which may be fragile or seen as a bit wrong, I think we can follow the same approach, at least until a better solution is available. [6] https://cgit.freedesktop.org/drm/drm-misc/commit/?id=0c94f58cef319ad054fd909b3bf4b7d09c03e11c [7] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d5178578bcd4 [8] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/btrfs/super.c#n2593 > --- > drivers/gpu/drm/panfrost/panfrost_drv.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c > b/drivers/gpu/drm/panfrost/panfrost_drv.c > index ef9f6c0716d5..149737d7a07e 100644 > --- a/drivers/gpu/drm/panfrost/panfrost_drv.c > +++ b/drivers/gpu/drm/panfrost/panfrost_drv.c > @@ -828,3 +828,4 @@ module_platform_driver(panfrost_driver); > MODULE_AUTHOR("Panfrost Project Developers"); > MODULE_DESCRIPTION("Panfrost DRM Driver"); > MODULE_LICENSE("GPL v2"); > +MODULE_SOFTDEP("pre: governor_simpleondemand");