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 X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3E8DDC433DF for ; Wed, 3 Jun 2020 15:14:14 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 10F1B206E6 for ; Wed, 3 Jun 2020 15:14:14 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="rklwuOp+" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 10F1B206E6 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=ZjkpMdGMN3iLy1OVp2BBC3bHauXd6D0+LGC1RlFxf2k=; b=rklwuOp+0L/E6a L2bopJIB8ItY56eUGNv0Z2i6Fd9uv40TR6gKxEu3hqrbfZll0pf+jSjkIj+kyaFGQOCcWmC+JE5ib DgCUZqtX1PHPg6fM/n6wyKQD6LumN09RiwG1zB0Xue1d0185gN6RRnpSj1yqHmZF10nGFQ9ivT8TL zYTAES0tVlE7mVvUvJBp0Btmk/b9j5iuQke0GStEvYA6PDwMroyDU3vK1TaDu9PHWSccQoiQp6OMO M0v2uxiWgQKzzpLwkqrjk9PqasHFv3rm93GeMO4w1C/zS+PVqQ4bxSryXNx7A4+ozwPeBhw5O6UQ5 A/+6rLgbBF3rTOIqRVQA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jgV5e-0003FI-I5; Wed, 03 Jun 2020 15:14:02 +0000 Received: from mail-oi1-f194.google.com ([209.85.167.194]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jgV5K-0002rp-Q0; Wed, 03 Jun 2020 15:13:44 +0000 Received: by mail-oi1-f194.google.com with SMTP id 25so1185177oiy.13; Wed, 03 Jun 2020 08:13:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Cz2BiX6d4n6x62rcneWGjZMN7VkN9rwUibKP2R8rjL8=; b=jgylyYZWXHH7p8I4aGOxbD42l9DvJXfX7ARRo4vaAFgoicDX38Uq/y366QtAh4krSZ btTPX86EgXfPZuyn/hq9RjBzEObM/ZjVqqNiXj60U9NFaCmZF1+7wm9XFsffur5CV0ms xOSYgjTBbgYsCECCXfTNOpFQf80+xIvbaypsaPiVIWvusbikHpXF6QjJxOu1rlzxtVKp WzX1/RxRCkZxT2aKvw/P5+1AITnuKBPCpBePZ7DhAorB1LUzwXYGtlsfjloNnNOF0ceE 8N8BMTptfWF75PlGEGH6xeA0Aa7tH6Yx5eBRMkX+6aTUR2v+rwZhPt+bHJcnZykEPSVr 1tkA== X-Gm-Message-State: AOAM530/2DIBr5IEzCEGHTLopYvX4/hdd5GKlCWmKYq6NtqEwpguSUY4 9nUwiScGs3OFZSPFskh265lTl98j5GePbhFfPVQ= X-Google-Smtp-Source: ABdhPJwl2C6njoLHvec0+7Z+pvFglKeo2x6xe974h+nkdR52l4Zy34+b5UkPp73bI+Pl0F3UJP8s0n7smqKuM+QPGx4= X-Received: by 2002:aca:ad88:: with SMTP id w130mr122356oie.103.1591197220440; Wed, 03 Jun 2020 08:13:40 -0700 (PDT) MIME-Version: 1.0 References: <20200527095854.21714-1-lukasz.luba@arm.com> <20200527095854.21714-5-lukasz.luba@arm.com> <7201e161-6952-6e28-4036-bd0f0353ec30@arm.com> In-Reply-To: <7201e161-6952-6e28-4036-bd0f0353ec30@arm.com> From: "Rafael J. Wysocki" Date: Wed, 3 Jun 2020 17:13:29 +0200 Message-ID: Subject: Re: [PATCH v8 4/8] PM / EM: add support for other devices than CPUs in Energy Model To: Lukasz Luba X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200603_081342_939776_29051206 X-CRM114-Status: GOOD ( 19.75 ) X-BeenThere: linux-mediatek@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Nishanth Menon , Juri Lelli , Peter Zijlstra , Viresh Kumar , Liviu Dudau , dri-devel , Bjorn Andersson , Benjamin Segall , alyssa.rosenzweig@collabora.com, Fabio Estevam , Matthias Kaehlcke , Rob Herring , Amit Kucheria , Lorenzo Pieralisi , Vincent Guittot , Kevin Hilman , Andy Gross , Daniel Lezcano , steven.price@arm.com, Chanwoo Choi , Ingo Molnar , dl-linux-imx , "Zhang, Rui" , Mel Gorman , orjan.eide@arm.com, Daniel Vetter , Linux PM , linux-arm-msm , Sascha Hauer , Steven Rostedt , "moderated list:ARM/Mediatek SoC..." , Matthias Brugger , Linux OMAP Mailing List , Dietmar Eggemann , Linux ARM , David Airlie , Tomeu Vizoso , Quentin Perret , Stephen Boyd , Randy Dunlap , "Rafael J. Wysocki" , Linux Kernel Mailing List , Bartlomiej Zolnierkiewicz , Sascha Hauer , Sudeep Holla , patrick.bellasi@matbug.net, Shawn Guo Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "Linux-mediatek" Errors-To: linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org On Tue, Jun 2, 2020 at 1:31 PM Lukasz Luba wrote: > > Hi Daniel, > > On 6/1/20 10:44 PM, Daniel Lezcano wrote: > > On 27/05/2020 11:58, Lukasz Luba wrote: > >> Add support for other devices than CPUs. The registration function > >> does not require a valid cpumask pointer and is ready to handle new > >> devices. Some of the internal structures has been reorganized in order to > >> keep consistent view (like removing per_cpu pd pointers). > >> > >> Signed-off-by: Lukasz Luba > >> --- > > > > [ ... ] > > > >> } > >> EXPORT_SYMBOL_GPL(em_register_perf_domain); > >> + > >> +/** > >> + * em_dev_unregister_perf_domain() - Unregister Energy Model (EM) for a device > >> + * @dev : Device for which the EM is registered > >> + * > >> + * Try to unregister the EM for the specified device (but not a CPU). > >> + */ > >> +void em_dev_unregister_perf_domain(struct device *dev) > >> +{ > >> + if (IS_ERR_OR_NULL(dev) || !dev->em_pd) > >> + return; > >> + > >> + if (_is_cpu_device(dev)) > >> + return; > >> + > >> + mutex_lock(&em_pd_mutex); > > > > Is the mutex really needed? > > I just wanted to align this unregister code with register. Since there > is debugfs dir lookup and the device's EM existence checks I thought it > wouldn't harm just to lock for a while and make sure the registration > path is not used. These two paths shouldn't affect each other, but with > modules loading/unloading I wanted to play safe. > > I can change it maybe to just dmb() and the end of the function if it's > a big performance problem in this unloading path. What do you think? I would rather leave the mutex locking as is. However, the question to ask is what exactly may go wrong without that locking in place? Is there any specific race condition that you are concerned about? _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek 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 X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F1628C433E0 for ; Wed, 3 Jun 2020 15:13:52 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id C96EA20738 for ; Wed, 3 Jun 2020 15:13:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="AE9Z2hmS" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C96EA20738 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=2+nc2USaGkaro7SpQisTPwBlpPIaa/TXGv+l4S/JhrQ=; b=AE9Z2hmSdwHoNq 4vdSW6QElm7eXRSM5X9XltrOF2FtTsU90eNu7TSBMDLHL1xWIWdf99lIjj1SOmOlmKGdReSygcC5A ZylwdeHQ/IWpQKjNrY1jOJhzBzZ7XItltLAoJ5xyNDOciJIaz6JL2Y5SZr1CIOvXlw77cbViljQv5 RCK4mHKsGs3MYlG96VPMKxaKYBUgY//+6sCzYZ83hmMjdANAdPCVEDL8Aut2C9Pg0MCYEyofwPxK/ /OT2I5jd1HHUHGOh2t4jV624tJ2XlDRJmuHr0R9P41fWQRSCgPSsS5sDSw3Dj0PLeMAbNe+cxMdyn 7+yQBOb6/A/RlYRGSQAA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jgV5T-00031t-IV; Wed, 03 Jun 2020 15:13:51 +0000 Received: from mail-oi1-f194.google.com ([209.85.167.194]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jgV5K-0002rp-Q0; Wed, 03 Jun 2020 15:13:44 +0000 Received: by mail-oi1-f194.google.com with SMTP id 25so1185177oiy.13; Wed, 03 Jun 2020 08:13:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Cz2BiX6d4n6x62rcneWGjZMN7VkN9rwUibKP2R8rjL8=; b=jgylyYZWXHH7p8I4aGOxbD42l9DvJXfX7ARRo4vaAFgoicDX38Uq/y366QtAh4krSZ btTPX86EgXfPZuyn/hq9RjBzEObM/ZjVqqNiXj60U9NFaCmZF1+7wm9XFsffur5CV0ms xOSYgjTBbgYsCECCXfTNOpFQf80+xIvbaypsaPiVIWvusbikHpXF6QjJxOu1rlzxtVKp WzX1/RxRCkZxT2aKvw/P5+1AITnuKBPCpBePZ7DhAorB1LUzwXYGtlsfjloNnNOF0ceE 8N8BMTptfWF75PlGEGH6xeA0Aa7tH6Yx5eBRMkX+6aTUR2v+rwZhPt+bHJcnZykEPSVr 1tkA== X-Gm-Message-State: AOAM530/2DIBr5IEzCEGHTLopYvX4/hdd5GKlCWmKYq6NtqEwpguSUY4 9nUwiScGs3OFZSPFskh265lTl98j5GePbhFfPVQ= X-Google-Smtp-Source: ABdhPJwl2C6njoLHvec0+7Z+pvFglKeo2x6xe974h+nkdR52l4Zy34+b5UkPp73bI+Pl0F3UJP8s0n7smqKuM+QPGx4= X-Received: by 2002:aca:ad88:: with SMTP id w130mr122356oie.103.1591197220440; Wed, 03 Jun 2020 08:13:40 -0700 (PDT) MIME-Version: 1.0 References: <20200527095854.21714-1-lukasz.luba@arm.com> <20200527095854.21714-5-lukasz.luba@arm.com> <7201e161-6952-6e28-4036-bd0f0353ec30@arm.com> In-Reply-To: <7201e161-6952-6e28-4036-bd0f0353ec30@arm.com> From: "Rafael J. Wysocki" Date: Wed, 3 Jun 2020 17:13:29 +0200 Message-ID: Subject: Re: [PATCH v8 4/8] PM / EM: add support for other devices than CPUs in Energy Model To: Lukasz Luba X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200603_081342_939776_29051206 X-CRM114-Status: GOOD ( 19.75 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Nishanth Menon , Juri Lelli , Peter Zijlstra , Viresh Kumar , Liviu Dudau , dri-devel , Bjorn Andersson , Benjamin Segall , alyssa.rosenzweig@collabora.com, Fabio Estevam , Matthias Kaehlcke , Rob Herring , Amit Kucheria , Lorenzo Pieralisi , Kevin Hilman , Andy Gross , Daniel Lezcano , steven.price@arm.com, Chanwoo Choi , Ingo Molnar , dl-linux-imx , "Zhang, Rui" , Mel Gorman , orjan.eide@arm.com, Daniel Vetter , Linux PM , linux-arm-msm , Sascha Hauer , Steven Rostedt , "moderated list:ARM/Mediatek SoC..." , Matthias Brugger , Linux OMAP Mailing List , Dietmar Eggemann , Linux ARM , David Airlie , Tomeu Vizoso , Quentin Perret , Stephen Boyd , Randy Dunlap , "Rafael J. Wysocki" , Linux Kernel Mailing List , Bartlomiej Zolnierkiewicz , Sascha Hauer , Sudeep Holla , patrick.bellasi@matbug.net, Shawn Guo Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Jun 2, 2020 at 1:31 PM Lukasz Luba wrote: > > Hi Daniel, > > On 6/1/20 10:44 PM, Daniel Lezcano wrote: > > On 27/05/2020 11:58, Lukasz Luba wrote: > >> Add support for other devices than CPUs. The registration function > >> does not require a valid cpumask pointer and is ready to handle new > >> devices. Some of the internal structures has been reorganized in order to > >> keep consistent view (like removing per_cpu pd pointers). > >> > >> Signed-off-by: Lukasz Luba > >> --- > > > > [ ... ] > > > >> } > >> EXPORT_SYMBOL_GPL(em_register_perf_domain); > >> + > >> +/** > >> + * em_dev_unregister_perf_domain() - Unregister Energy Model (EM) for a device > >> + * @dev : Device for which the EM is registered > >> + * > >> + * Try to unregister the EM for the specified device (but not a CPU). > >> + */ > >> +void em_dev_unregister_perf_domain(struct device *dev) > >> +{ > >> + if (IS_ERR_OR_NULL(dev) || !dev->em_pd) > >> + return; > >> + > >> + if (_is_cpu_device(dev)) > >> + return; > >> + > >> + mutex_lock(&em_pd_mutex); > > > > Is the mutex really needed? > > I just wanted to align this unregister code with register. Since there > is debugfs dir lookup and the device's EM existence checks I thought it > wouldn't harm just to lock for a while and make sure the registration > path is not used. These two paths shouldn't affect each other, but with > modules loading/unloading I wanted to play safe. > > I can change it maybe to just dmb() and the end of the function if it's > a big performance problem in this unloading path. What do you think? I would rather leave the mutex locking as is. However, the question to ask is what exactly may go wrong without that locking in place? Is there any specific race condition that you are concerned about? _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 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 X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A6430C433DF for ; Wed, 3 Jun 2020 15:13:42 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 7DC74206E6 for ; Wed, 3 Jun 2020 15:13:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7DC74206E6 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id BAB5A89B99; Wed, 3 Jun 2020 15:13:41 +0000 (UTC) Received: from mail-oi1-f195.google.com (mail-oi1-f195.google.com [209.85.167.195]) by gabe.freedesktop.org (Postfix) with ESMTPS id 2CCCE89B99 for ; Wed, 3 Jun 2020 15:13:41 +0000 (UTC) Received: by mail-oi1-f195.google.com with SMTP id m67so2107712oif.4 for ; Wed, 03 Jun 2020 08:13:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Cz2BiX6d4n6x62rcneWGjZMN7VkN9rwUibKP2R8rjL8=; b=IKLKegpTBkFV8yuXBeBN5yUbsycJlcyhbP8d1h1nlw/On0KHFJPQPdG+C1fRokXthM iaJywtkLBVRoC+plZ2fEstmreFrjIUtaRmxSJ5kq0eK8+uK5qQ9S1h/+5a3FFoHQT3NZ lHVSP+H2fgTlhlZvMVDSBX20QGelkuTqHADl1UNRaGUOdCGDbnw+ofPLGqhIEtqoDeI0 8K2LVE+CTvgYcEAbBM52cwkP97iYo2TPx1btiB1YOiB5T5LnrpRxlXeTkHNWSaT8CFgP ahL3JHVVYuygBeUDDRp2SLrhCJ/NwOotiezRmUkYbLkl1yQunkG8mMH7qcl7/m5hrxOz /iqg== X-Gm-Message-State: AOAM532s8iV20YQDQ8ZhJRP5oSpXrrAxtHDPR+V44KSI7XV9THT0METn xbiSOe8FEyt2Vh2gYFUWfzd6Mj954JLeBHQ0bwo= X-Google-Smtp-Source: ABdhPJwl2C6njoLHvec0+7Z+pvFglKeo2x6xe974h+nkdR52l4Zy34+b5UkPp73bI+Pl0F3UJP8s0n7smqKuM+QPGx4= X-Received: by 2002:aca:ad88:: with SMTP id w130mr122356oie.103.1591197220440; Wed, 03 Jun 2020 08:13:40 -0700 (PDT) MIME-Version: 1.0 References: <20200527095854.21714-1-lukasz.luba@arm.com> <20200527095854.21714-5-lukasz.luba@arm.com> <7201e161-6952-6e28-4036-bd0f0353ec30@arm.com> In-Reply-To: <7201e161-6952-6e28-4036-bd0f0353ec30@arm.com> From: "Rafael J. Wysocki" Date: Wed, 3 Jun 2020 17:13:29 +0200 Message-ID: Subject: Re: [PATCH v8 4/8] PM / EM: add support for other devices than CPUs in Energy Model To: Lukasz Luba X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Nishanth Menon , Juri Lelli , Peter Zijlstra , Viresh Kumar , Liviu Dudau , dri-devel , Bjorn Andersson , Benjamin Segall , alyssa.rosenzweig@collabora.com, Matthias Kaehlcke , Amit Kucheria , Lorenzo Pieralisi , Vincent Guittot , Kevin Hilman , Andy Gross , Daniel Lezcano , steven.price@arm.com, Chanwoo Choi , Ingo Molnar , dl-linux-imx , "Zhang, Rui" , Mel Gorman , orjan.eide@arm.com, Linux PM , linux-arm-msm , Sascha Hauer , Steven Rostedt , "moderated list:ARM/Mediatek SoC..." , Matthias Brugger , Linux OMAP Mailing List , Dietmar Eggemann , Linux ARM , David Airlie , Tomeu Vizoso , Quentin Perret , Stephen Boyd , Randy Dunlap , "Rafael J. Wysocki" , Linux Kernel Mailing List , Bartlomiej Zolnierkiewicz , Sascha Hauer , Sudeep Holla , patrick.bellasi@matbug.net, Shawn Guo Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Tue, Jun 2, 2020 at 1:31 PM Lukasz Luba wrote: > > Hi Daniel, > > On 6/1/20 10:44 PM, Daniel Lezcano wrote: > > On 27/05/2020 11:58, Lukasz Luba wrote: > >> Add support for other devices than CPUs. The registration function > >> does not require a valid cpumask pointer and is ready to handle new > >> devices. Some of the internal structures has been reorganized in order to > >> keep consistent view (like removing per_cpu pd pointers). > >> > >> Signed-off-by: Lukasz Luba > >> --- > > > > [ ... ] > > > >> } > >> EXPORT_SYMBOL_GPL(em_register_perf_domain); > >> + > >> +/** > >> + * em_dev_unregister_perf_domain() - Unregister Energy Model (EM) for a device > >> + * @dev : Device for which the EM is registered > >> + * > >> + * Try to unregister the EM for the specified device (but not a CPU). > >> + */ > >> +void em_dev_unregister_perf_domain(struct device *dev) > >> +{ > >> + if (IS_ERR_OR_NULL(dev) || !dev->em_pd) > >> + return; > >> + > >> + if (_is_cpu_device(dev)) > >> + return; > >> + > >> + mutex_lock(&em_pd_mutex); > > > > Is the mutex really needed? > > I just wanted to align this unregister code with register. Since there > is debugfs dir lookup and the device's EM existence checks I thought it > wouldn't harm just to lock for a while and make sure the registration > path is not used. These two paths shouldn't affect each other, but with > modules loading/unloading I wanted to play safe. > > I can change it maybe to just dmb() and the end of the function if it's > a big performance problem in this unloading path. What do you think? I would rather leave the mutex locking as is. However, the question to ask is what exactly may go wrong without that locking in place? Is there any specific race condition that you are concerned about? _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel