All of lore.kernel.org
 help / color / mirror / Atom feed
From: 함명주 <myungjoo.ham@samsung.com>
To: Xiaoguang Chen <chenxg@marvell.com>,
	Xiaoguang Chen <chenxg.marvell@gmail.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	박경민 <kyungmin.park@samsung.com>,
	"linux-pm@lists.linux-foundation.org"
	<linux-pm@lists.linux-foundation.org>,
	"myungjoo.ham@gmail.com" <myungjoo.ham@gmail.com>
Subject: Re: RE: Re: [PATCH 1/2] PM: devfreq: add freq table and available_freqs
Date: Tue, 19 Jun 2012 05:04:45 +0000 (GMT)	[thread overview]
Message-ID: <9923093.588271340082284749.JavaMail.weblogic@epml24> (raw)

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=euc-kr, Size: 4633 bytes --]

> Hi, Myungjoo
> 
> the API is optional, but I think one frequency table is better to have.
> if user space want to see what is the supported frequencies for the specific devfreq driver, then where do you think we can see this interface?
> do we have to go to OPP framework to get it ? or we can just add it in our devfreq ? for example: sys/class/devfreq/xxx-devfreq/available_freqs
> I think it is best for us to see this in the same sysfs path.
> 
> Thanks
> Xiaoguang

Hi Xiaoguang,

First of all, both conceptually and practically, devfreq subsystem does not need to hold the list of available frequencies. Devfreq subsystem does not care whether a devfreq device has only two (or even one) frequencies available or several billions frequencies available, which is why OPP is dropped from devfreq subsystem and only helper functions are remaining.

The available frequencies information may be in OPP, clock subsystem, or the device driver itself. The listing of available frequencies should be provided by the one who has the information at first.

Anyway, except for the pure curiosity of users, why do we need to provide the list of available frequencies at the devfreq subsystem? If we are adding it in devfreq subsystem, we are adding an ABI and supporting data structure that are never used by the subsystem, but for printing out via ABI which only satisfies the curiosity of users that may already know what it would list up. There are even cases where the devfreq device driver itself also does not aware of avilable frequencies; when OPP is given outside.


Cheers!
MyungJoo.

> 
> 
> -----Original Message-----
> From: ÇÔ¸íÁÖ [mailto:myungjoo.ham@samsung.com] 
> Sent: 2012Ò´6êÅ14ìí 12:44
> To: Xiaoguang Chen
> Cc: Xiaoguang Chen; linux-kernel@vger.kernel.org; ¹Ú°æ¹Î; linux-pm@lists.linux-foundation.org
> Subject: Re: Re: [PATCH 1/2] PM: devfreq: add freq table and available_freqs
> 
> > Hi, Myungjoo
> > 
> > 
> > what's your opinion?
> 
> Hello Xiaoguang,
> 
> Still, I don't think we need additional API and ABI for a simple frequency table. Why a devfreq device driver would want to register a table in struct devfreq while it can hold one either with its dev-data, private data of devfreq, or even OPP.
> 
> 1. Devfreq is not "combined" with OPP. OPP is optional.
> 
> 2. I guess filling voltage column with some arbitrary values in OPP table won't hurt anything if the device does not care voltage values. (just a suggestion and speculation) Thus, you can still use OPP in your case as long as the frequency values are discrete and not too many.
> 
> 3. Devfreq and its governors recommends the base frequency to devfreq drivers. Frequency table is only needed to be visible to devfreq drivers, not to governors or devfreq itself. The frequency table you've suggested is not need to be visible to devfreq subsystem.
> 
> 
> I still object to adding a frequency table (which is already supported by OPP by not specifying voltage or specifying arbitrary voltage values). However, even if I don't, we won't need that API (devfreq_set_freq_table), which should've been added in device profile at devfreq_add_device() time.
> 
> 
> Cheers!
> MyungJoo.
> 
> > 
> > 
> > Thanks
> > Xiaoguang
> > 
> > 
> > > 2012/6/13 Xiaoguang Chen <chenxg.marvell@gmail.com>
> > > 
> > > I think Devfreq should not be combined with OPP, OPP framework does 
> > > contain one frequency table, but the frequency is combined with voltage. some platforms may don't want to use this but handling voltage seperately in their clock driver.
> > > 
> > > 
> > > and some platforms don't use OPP, and they want a frequency list.
> > > then this is necessary. also devfreq should contain a frequency list even without any other frameworks, don't you think so ?
> > > 
> > > 
> > > Thanks
> > > Xiaoguang
> > > 
> > > 
> > > 
> > > 2012/6/13 MyungJoo Ham <myungjoo.ham@samsung.com>
> > > > 
> > > > > Devfreq framework don't have a frequency table, add it for easy 
> > > > > use.
> > > > >
> > > > > Signed-off-by: Xiaoguang Chen <chenxg@marvell.com>
> > > > 
> > > > 
> > > > If you need a predefined data structure to support frequency 
> > > > table, you can simply use OPP, which has helper functions 
> > > > implemented in devfreq subsystem. Is there any reason not to use 
> > > > OPP and to implement another data structure to store a frequency table attached to a device?
> > > > 
> > > > 
> > > > Cheers!
> > > > MyungJoo.
> > > > 
> 
> 
> 
>        
>   
>          
> 
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

WARNING: multiple messages have this Message-ID (diff)
From: 함명주 <myungjoo.ham@samsung.com>
To: Xiaoguang Chen <chenxg@marvell.com>,
	Xiaoguang Chen <chenxg.marvell@gmail.com>
Cc: 박경민 <kyungmin.park@samsung.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-pm@lists.linux-foundation.org"
	<linux-pm@lists.linux-foundation.org>
Subject: Re: [PATCH 1/2] PM: devfreq: add freq table and available_freqs
Date: Tue, 19 Jun 2012 05:04:46 +0000 (GMT)	[thread overview]
Message-ID: <9923093.588271340082284749.JavaMail.weblogic@epml24> (raw)

> Hi, Myungjoo
> 
> the API is optional, but I think one frequency table is better to have.
> if user space want to see what is the supported frequencies for the specific devfreq driver, then where do you think we can see this interface?
> do we have to go to OPP framework to get it ? or we can just add it in our devfreq ? for example: sys/class/devfreq/xxx-devfreq/available_freqs
> I think it is best for us to see this in the same sysfs path.
> 
> Thanks
> Xiaoguang

Hi Xiaoguang,

First of all, both conceptually and practically, devfreq subsystem does not need to hold the list of available frequencies. Devfreq subsystem does not care whether a devfreq device has only two (or even one) frequencies available or several billions frequencies available, which is why OPP is dropped from devfreq subsystem and only helper functions are remaining.

The available frequencies information may be in OPP, clock subsystem, or the device driver itself. The listing of available frequencies should be provided by the one who has the information at first.

Anyway, except for the pure curiosity of users, why do we need to provide the list of available frequencies at the devfreq subsystem? If we are adding it in devfreq subsystem, we are adding an ABI and supporting data structure that are never used by the subsystem, but for printing out via ABI which only satisfies the curiosity of users that may already know what it would list up. There are even cases where the devfreq device driver itself also does not aware of avilable frequencies; when OPP is given outside.


Cheers!
MyungJoo.

> 
> 
> -----Original Message-----
> From: 함명주 [mailto:myungjoo.ham@samsung.com] 
> Sent: 2012年6月14日 12:44
> To: Xiaoguang Chen
> Cc: Xiaoguang Chen; linux-kernel@vger.kernel.org; 박경민; linux-pm@lists.linux-foundation.org
> Subject: Re: Re: [PATCH 1/2] PM: devfreq: add freq table and available_freqs
> 
> > Hi, Myungjoo
> > 
> > 
> > what's your opinion?
> 
> Hello Xiaoguang,
> 
> Still, I don't think we need additional API and ABI for a simple frequency table. Why a devfreq device driver would want to register a table in struct devfreq while it can hold one either with its dev-data, private data of devfreq, or even OPP.
> 
> 1. Devfreq is not "combined" with OPP. OPP is optional.
> 
> 2. I guess filling voltage column with some arbitrary values in OPP table won't hurt anything if the device does not care voltage values. (just a suggestion and speculation) Thus, you can still use OPP in your case as long as the frequency values are discrete and not too many.
> 
> 3. Devfreq and its governors recommends the base frequency to devfreq drivers. Frequency table is only needed to be visible to devfreq drivers, not to governors or devfreq itself. The frequency table you've suggested is not need to be visible to devfreq subsystem.
> 
> 
> I still object to adding a frequency table (which is already supported by OPP by not specifying voltage or specifying arbitrary voltage values). However, even if I don't, we won't need that API (devfreq_set_freq_table), which should've been added in device profile at devfreq_add_device() time.
> 
> 
> Cheers!
> MyungJoo.
> 
> > 
> > 
> > Thanks
> > Xiaoguang
> > 
> > 
> > > 2012/6/13 Xiaoguang Chen <chenxg.marvell@gmail.com>
> > > 
> > > I think Devfreq should not be combined with OPP, OPP framework does 
> > > contain one frequency table, but the frequency is combined with voltage. some platforms may don't want to use this but handling voltage seperately in their clock driver.
> > > 
> > > 
> > > and some platforms don't use OPP, and they want a frequency list.
> > > then this is necessary. also devfreq should contain a frequency list even without any other frameworks, don't you think so ?
> > > 
> > > 
> > > Thanks
> > > Xiaoguang
> > > 
> > > 
> > > 
> > > 2012/6/13 MyungJoo Ham <myungjoo.ham@samsung.com>
> > > > 
> > > > > Devfreq framework don't have a frequency table, add it for easy 
> > > > > use.
> > > > >
> > > > > Signed-off-by: Xiaoguang Chen <chenxg@marvell.com>
> > > > 
> > > > 
> > > > If you need a predefined data structure to support frequency 
> > > > table, you can simply use OPP, which has helper functions 
> > > > implemented in devfreq subsystem. Is there any reason not to use 
> > > > OPP and to implement another data structure to store a frequency table attached to a device?
> > > > 
> > > > 
> > > > Cheers!
> > > > MyungJoo.
> > > > 
> 
> 
> 
>        
>   
>          
> 

             reply	other threads:[~2012-06-19  5:04 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-19  5:04 함명주 [this message]
2012-06-19  5:04 ` [PATCH 1/2] PM: devfreq: add freq table and available_freqs 함명주
2012-06-19  5:30 ` RE: " Xiaoguang Chen
2012-06-19  5:30   ` Xiaoguang Chen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9923093.588271340082284749.JavaMail.weblogic@epml24 \
    --to=myungjoo.ham@samsung.com \
    --cc=chenxg.marvell@gmail.com \
    --cc=chenxg@marvell.com \
    --cc=kyungmin.park@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@lists.linux-foundation.org \
    --cc=myungjoo.ham@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.