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 BBAE3E728CA for ; Fri, 29 Sep 2023 17:01:35 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 5DCCC10E172; Fri, 29 Sep 2023 17:01:35 +0000 (UTC) Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.115]) by gabe.freedesktop.org (Postfix) with ESMTPS id AF81910E15E for ; Fri, 29 Sep 2023 17:01:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1696006892; x=1727542892; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version; bh=32uw7cJrMpiZ/tl2KJHh0FW/MCgAXdQXqGaUhxpd1Vk=; b=GX5joJlI4IQrd5XuKu1UA//ai7bA3SPrqh22nhVbEgUBMd/r42yjDF93 FCqa2EdSw0pIkD2yvjXQcmD1zusaiQa8R9JGwHnndjqSD+h4QaXaNugF8 Odh5ZtW5ktgD0b5iOoE0t8O/KGJ6Ec7Zbdy6WTvE6+NitjV5EOEAOsXqM QkoQBnWJt90/DJBT9/g1J9CAO46SLbhB91I8Ky6vIz1obHobEPcBgEY6U JQilI+A4pDFAFGuvFxEsoulY4e/g0M4mUn54KPc+QFJuIgPN2GGfqrvW+ w8typtOEfASePLcYepZKXPCk2jEYLK1N790OBVQWd0bGtZF8d+P6a6J+5 Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10848"; a="382253784" X-IronPort-AV: E=Sophos;i="6.03,188,1694761200"; d="scan'208";a="382253784" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Sep 2023 10:01:31 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10848"; a="749996521" X-IronPort-AV: E=Sophos;i="6.03,187,1694761200"; d="scan'208";a="749996521" Received: from adixit-mobl.amr.corp.intel.com (HELO adixit-arch.intel.com) ([10.209.57.213]) by orsmga002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Sep 2023 10:01:31 -0700 Date: Fri, 29 Sep 2023 09:48:36 -0700 Message-ID: <87r0mhncwr.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: "Nilawar, Badal" In-Reply-To: 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> <87ttreucb0.wl-ashutosh.dixit@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 Thu, 28 Sep 2023 23:37:35 -0700, Nilawar, Badal wrote: > Hi Badal, > On 28-09-2023 10:25, Dixit, Ashutosh wrote: > > On Wed, 27 Sep 2023 01:39:46 -0700, Nilawar, Badal wrote: > > > >> 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? > Agreed, thought process here suggest that take rpm wakeref at lowest > possible level. I already tried this in rfc series and in some extent in > rev2. There is problem with this approach. See my comments below. > > > > 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. > Yes from rev2 comments its dangerous to take mutex before > xe_device_mem_access_get/put. With code for "PL1 disable/restore during > resume" I saw deadlock. Scenario was power1_max write -> mutex lock -> rpm > resume -> disable pl1 -> mutex lock (dead lock here). But this is already the wrong order as mentioned below. If we follow the below order do we still see deadlock? > > > > 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. > There are two problems with this approach. > > Problem 1: If you see implementation of xe_hwmon_power_max_write, reg > access is happening 3 times, so there will be 3 rpm suspend/resume > cycles. I was observing the same with rfc implementation. So in subsequent > series xe_device_mem_access_put/get is moved to top level functions > i.e. hwmon hooks. This is not exactly correct because there is also a 1 second autosuspend delay which will prevent such rpm suspend/resume cycles: xe_pm_runtime_init: pm_runtime_set_autosuspend_delay(dev, 1000); > > Problem 2: If locking moved inside xe_hwmon_process_reg then between two > subsequent reg accesses it will open small window during which race can > happen. > As Anshuman suggested in other thread for read are sequential and protected > by sysfs layer. So lets apply locking only for RW attributes. But what is the locking trying to protect? As far as I understand it is just the registers which have to be atomically modified/read. So it seems sufficient to just protect the register accesses with the lock. So I am still not convinced. Thanks. -- Ashutosh > > +static int xe_hwmon_power_max_write(struct xe_hwmon *hwmon, long value) > +{ > + u32 reg_val; > + > + /* Disable PL1 limit and verify, as limit cannot be disabled on all > platforms */ > + if (value == PL1_DISABLE) { > + xe_hwmon_process_reg(hwmon, REG_PKG_RAPL_LIMIT, REG_RMW, ®_val, > + PKG_PWR_LIM_1_EN, 0); > + xe_hwmon_process_reg(hwmon, REG_PKG_RAPL_LIMIT, REG_READ, ®_val, > + PKG_PWR_LIM_1_EN, 0); > + > + if (reg_val & PKG_PWR_LIM_1_EN) > + return -EOPNOTSUPP; > + } > + > + /* Computation in 64-bits to avoid overflow. Round to nearest. */ > + reg_val = DIV_ROUND_CLOSEST_ULL((u64)value << > hwmon->scl_shift_power, SF_POWER); > + reg_val = PKG_PWR_LIM_1_EN | REG_FIELD_PREP(PKG_PWR_LIM_1, reg_val); > + > + xe_hwmon_process_reg(hwmon, REG_PKG_RAPL_LIMIT, REG_RMW, ®_val, > + PKG_PWR_LIM_1_EN | PKG_PWR_LIM_1, reg_val); > + > + return 0; > +} > > Regards, > Badal > > > >>> > >>> 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