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