From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 9EB1ACE7AF9 for ; Thu, 28 Sep 2023 04:55:33 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 6795710E5CD; Thu, 28 Sep 2023 04:55:33 +0000 (UTC) Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.100]) by gabe.freedesktop.org (Postfix) with ESMTPS id 8E71010E5CD for ; Thu, 28 Sep 2023 04:55:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1695876931; x=1727412931; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version; bh=4PEJ3IQ0nFkePalt+zJFQBHdhchda9Q3XEy1ehcU0h4=; b=EP+sEZQxvFux7qVM7f4XduTP8GxonZgJy9LZfUq0OogrTwtGlGZEQ95H YgUwzeTKNid7XjzNqJ8ed8cEnRx4sbbJtJbRFiS03VriTM5ncs5ghwQJT KeSZbDL+CCEJ0Mufwxi1dQJDomFDjaauGwmtn9Zih/0hY7XATY50W1w2t QmDHk3togMQgUpuZFN/Jy/KA8HUR/WxyQtKwXx+7OQUC1juapWzqSQQFM worVdKjgvlSLASiEU7yStFaF+WZfZKNXqyg+wd32/7aNnFgv0BjpdJxqs qfwhK4Ld84N9rL/Qa3vOEXUZkysO9vZkT9Tyspwyehd6tgWyNVXxJme0Y A==; X-IronPort-AV: E=McAfee;i="6600,9927,10846"; a="448477154" X-IronPort-AV: E=Sophos;i="6.03,183,1694761200"; d="scan'208";a="448477154" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Sep 2023 21:55:31 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10846"; a="923073931" X-IronPort-AV: E=Sophos;i="6.03,183,1694761200"; d="scan'208";a="923073931" Received: from adixit-mobl.amr.corp.intel.com (HELO adixit-arch.intel.com) ([10.212.219.102]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Sep 2023 21:55:30 -0700 Date: Wed, 27 Sep 2023 21:55:15 -0700 Message-ID: <87ttreucb0.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: "Nilawar, Badal" In-Reply-To: <84b5dc30-6b27-caf0-6535-c08f6b7e8cd0@intel.com> References: <20230925081842.3566834-1-badal.nilawar@intel.com> <20230925081842.3566834-2-badal.nilawar@intel.com> <874jjg1ak6.wl-ashutosh.dixit@intel.com> <84b5dc30-6b27-caf0-6535-c08f6b7e8cd0@intel.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/29.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Subject: Re: [Intel-xe] [PATCH v6 1/5] drm/xe/hwmon: Expose power attributes X-BeenThere: intel-xe@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel Xe graphics driver List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-hwmon@vger.kernel.org, linux@roeck-us.net, rodrigo.vivi@intel.com, intel-xe@lists.freedesktop.org Errors-To: intel-xe-bounces@lists.freedesktop.org Sender: "Intel-xe" On Wed, 27 Sep 2023 01:39:46 -0700, Nilawar, Badal wrote: > Hi Badal, > On 27-09-2023 10:23, Dixit, Ashutosh wrote: > > On Mon, 25 Sep 2023 01:18:38 -0700, Badal Nilawar wrote: > >> > >> +static umode_t > >> +xe_hwmon_is_visible(const void *drvdata, enum hwmon_sensor_types type, > >> + u32 attr, int channel) > >> +{ > >> + struct xe_hwmon *hwmon = (struct xe_hwmon *)drvdata; > >> + int ret; > >> + > >> + xe_device_mem_access_get(gt_to_xe(hwmon->gt)); > > > > Maybe we do xe_device_mem_access_get/put in xe_hwmon_process_reg where it > > is needed? E.g. xe_hwmon_is_visible doesn't need to do this because it > > doesn't read/write registers. > Agreed, but visible function is called only once while registering hwmon > interface, which happen during driver probe. During driver probe device > will be in resumed state. So no harm in keeping > xe_device_mem_access_get/put in visible function. To me it doesn't make any sense to keep xe_device_mem_access_get/put anywhere except in xe_hwmon_process_reg where the HW access actually happens. We can eliminate xe_device_mem_access_get/put's all over the place if we do it. Isn't it? The only restriction I have heard of (though not sure why) is that xe_device_mem_access_get/put should not be called under lock. Though I am not sure it is for spinlock or also mutex. So as we were saying the locking will also need to move to xe_hwmon_process_reg. So: xe_hwmon_process_reg() { xe_device_mem_access_get mutex_lock ... mutex_unlock xe_device_mem_access_put } So once again if this is not possible for some reason let's figure out why. > > > > Also do we need to take forcewake? i915 had forcewake table so it would > > take forcewake automatically but XE doesn't do that. > Hwmon regs doesn't fall under GT domain so doesn't need forcewake. OK, great. Thanks. -- Ashutosh