From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Hilman Subject: Re: [PATCH 04/13] OMAP: Introduce dependent voltage domain support Date: Thu, 10 Feb 2011 08:36:45 -0800 Message-ID: <87sjvvx2w2.fsf@ti.com> References: <1295618465-15234-1-git-send-email-vishwanath.bs@ti.com> <1295618465-15234-5-git-send-email-vishwanath.bs@ti.com> <87wrlfvmj0.fsf@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from na3sys009aog109.obsmtp.com ([74.125.149.201]:49424 "EHLO na3sys009aog109.obsmtp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750820Ab1BJQgt (ORCPT ); Thu, 10 Feb 2011 11:36:49 -0500 Received: by mail-gy0-f172.google.com with SMTP id 12so700302gyd.17 for ; Thu, 10 Feb 2011 08:36:48 -0800 (PST) In-Reply-To: (Vishwanath Sripathy's message of "Mon, 7 Feb 2011 20:04:55 +0530") Sender: linux-omap-owner@vger.kernel.org List-Id: linux-omap@vger.kernel.org To: Vishwanath Sripathy Cc: linux-omap@vger.kernel.org, patches@linaro.org, Thara Gopinath Vishwanath Sripathy writes: [...] >> > diff --git a/arch/arm/mach-omap2/dvfs.c b/arch/arm/mach- >> omap2/dvfs.c >> > index cefc2be..c9d3894 100755 >> > --- a/arch/arm/mach-omap2/dvfs.c >> > +++ b/arch/arm/mach-omap2/dvfs.c >> > @@ -85,6 +85,7 @@ struct omap_vdd_dvfs_info { >> > struct mutex scaling_mutex; /* dvfs mutex */ >> > struct voltagedomain *voltdm; >> > struct list_head dev_list; >> > + struct device vdd_device; >> >> It's not clear what the usage of this device is for. >> >> It is never initialized, but seems to be used as a dummy device when >> calcluating dependencies. Needs clarification. > > This device is used for placing voltage request (omap_dvfs_add_vdd_user) > when dealing with dependent vdds. Eg: while scaling MPU VDD, we also scale > CORE VDD. So while placing voltage request for CORE VDD, this vdd_device > of MPU is used as the requesting device so that this request is stored as > a separate user. I was able to follow how it was used, and why. But it is still not clear to the reader. First, the device is never initialized, so it's essentially a dummy device that remains initialized by default to all zeros. So, any attempt to use any device APIs (e.g. dev_name, etc.) on this will not behave as expected. Second, the reason for this device and the need for the request to be stored as a separate user are not clear in the code and don't exist in the comments. Kevin