From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750804AbdAXGd2 (ORCPT ); Tue, 24 Jan 2017 01:33:28 -0500 Received: from mailout2.samsung.com ([203.254.224.25]:35664 "EHLO mailout2.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750703AbdAXGd0 (ORCPT ); Tue, 24 Jan 2017 01:33:26 -0500 MIME-version: 1.0 Content-type: text/plain; charset=utf-8 X-AuditID: b6c32a3b-f79dd6d000001b59-54-5886f2db1f99 Content-transfer-encoding: 8BIT Message-id: <5886F2DA.9000102@samsung.com> Date: Tue, 24 Jan 2017 15:23:22 +0900 From: Chanwoo Choi Organization: Samsung Electronics User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 To: myungjoo.ham@samsung.com, Kyungmin Park , "rjw@rjwysocki.net" Cc: "linux-pm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "stable@vger.kernel.org" Subject: Re: [PATCH 1/3] PM / devfreq: Fix available_governor sysfs In-reply-to: <20170124035158epcms1p3b2e59563cfb7fd2ec404102e0552ed78@epcms1p3> X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnleLIzCtJLcpLzFFi42LZdlhTV/fOp7YIgxsXGC3ONr1ht7i8aw6b xefeI4wWtxtXsFmcOX2J1WLBxkeMDmweW662s3j0bVnF6PF5k1wAcxSXTUpqTmZZapG+XQJX xpeOj0wF35QrXs96zN7AOEe2i5GDQ0LAROLhJqcuRk4gU0ziwr31bF2MXBxCAjsYJf6cmsAI 4bQzSXx6sJIJospEou/gHqiq5YwSR9oWs4EkeAUEJX5MvscCMpVZQF7iyKVskDCzgKbEiy+T WCDq7zFKPJy2iR2iXkvizZ1eRhCbRUBVYlvXDFYQmw0ovv/FDbCZ/AKKEld/PAarERWIkNg5 /xtYr4hAkcSyw9/BjmAWWM8oMeXOfrAiYQFniU8fXoDZnAJ+EnMvXGAGKZIQmMcu0XCziwXi Z1mJTQeYIb5xkZi3v4UdwhaWeHV8C5QtLbHq3y0miN5uRok1L5tYIZweRonGNUfZIKqMJe4/ uMcM8SefxLuvPawQC3glOtqEIEo8JJY+3MAGEXaUmPhZBRISdxkl9s29xzyBUWEWUuDNQgTe LKTAW8DIvIpRLLWgODc9tdiwwFyvODG3uDQvXS85P3cTIziZaFnvYFxzzucQowAHoxIPb4FU W4QQa2JZcWXuIUYJDmYlEV69j0Ah3pTEyqrUovz4otKc1OJDjNIcLErivIwMDAxCAumJJanZ qakFqUUwWSYOTqkGxsS6KNYzs1Oud61eeybj5oOZx5/O1zyhLl3q7nj4w6e5k30MZpzgEjb9 vfL48tjMY2s2/jLTY9JoszKKkz3ybO2mN7YsfM1SS2w87sxUfWb/7cf+npUvy079S7yx9V9Z XN/Wn+Yy0/YYfL6lyi+x4Ohc41Ucuq4Xn2bHSx/Iy4r8t179ZuK/mGwlluKMREMt5qLiRACQ LCGrIgMAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHIsWRmVeSWpSXmKPExsVy+t9jAd1bn9oiDK5u0bI42/SG3eLyrjls Fp97jzBa3G5cwWZx5vQlVosFGx8xOrB5bLnazuLRt2UVo8fnTXIBzFFuNhmpiSmpRQqpecn5 KZl56bZKoSFuuhZKCnmJuam2ShG6viFBSgpliTmlQJ6RARpwcA5wD1bSt0twy/jS8ZGp4Jty xetZj9kbGOfIdjFyckgImEj0HdzDBmGLSVy4tx7MFhJYyigxt8MDxOYVEJT4MfkeSxcjBwez gLzEkUvZEKa6xJQpuV2MXEDVDxglVq9azgRRriXx5k4vI4jNIqAqsa1rBiuIzQYU3//iBth4 fgFFias/HjOCzBEViJDoPlEJEhYRKJJ49OY5K8hMZoH1jBKPvr0D6xUWcJb49OEFI8Syu4wS c7ZNBUtwCvhJzL1wgXkCo+AsJKfOQjh1FsKpCxiZVzFKpBYkFxQnpeca5qWW6xUn5haX5qXr JefnbmIEx9UzqR2MB3e5H2IU4GBU4uF90dwWIcSaWFZcmXuIUYKDWUmEV+8jUIg3JbGyKrUo P76oNCe1+BCjKdCvE5mlRJPzgTGfVxJvaGJuYm5sYGFuaWlipCTO2zj7WbiQQHpiSWp2ampB ahFMHxMHp1QD4/6zqvMW1nN6HZj44vCr+EOJzL2GOxIZTDhTJDJvfTr+dOYixZe99tNUrrq2 c39VeKteuyFJs/KYxHHB/Xeb2pz3RE2YMsVhj5zAr8LJdd7G7B80WE+kOJ9aWX/zTk0Qk8yx hl/rOrnjVVbPvLvxsJaDgZZS0c1Hy58KWL+pspnWuiHToFzWTImlOCPRUIu5qDgRABJWYqDB AgAA X-MTR: 20000000000000000@CPGS X-CMS-MailID: 20170124062322epcas1p29f19b1fccabaac089c5c642919541c7d X-Msg-Generator: CA X-Sender-IP: 203.254.230.26 X-Local-Sender: =?UTF-8?B?7LWc7LCs7JqwG1RpemVuIFBsYXRmb3JtIExhYihTL1fshLw=?= =?UTF-8?B?7YSwKRvsgrzshLHsoITsnpAbUzUo7LGF7J6EKS/ssYXsnoQ=?= X-Global-Sender: =?UTF-8?B?Q2hhbndvbyBDaG9pG1RpemVuIFBsYXRmb3JtIExhYi4bU2Ft?= =?UTF-8?B?c3VuZyBFbGVjdHJvbmljcxtTNS9TZW5pb3IgRW5naW5lZXI=?= X-Sender-Code: =?UTF-8?B?QzEwG1NUQUYbQzEwVjgxMTE=?= CMS-TYPE: 101P X-HopCount: 7 X-CMS-RootMailID: 20170118065653epcas5p2b1b4a964772e300b56356a26ec5cb9e5 X-RootMTR: 20170118065653epcas5p2b1b4a964772e300b56356a26ec5cb9e5 References: <1484722611-10555-1-git-send-email-cw00.choi@samsung.com> <20170124035158epcms1p3b2e59563cfb7fd2ec404102e0552ed78@epcms1p3> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2017년 01월 24일 12:51, MyungJoo Ham wrote: >> The devfreq using passive governor is not able to change the governor. >> So, the user can not change the governor through 'available_governor' sysfs >> entry. Also, the devfreq which don't use the passive governor is not able to >> change to 'passive' governor on the fly. > > Another thoughts on the characteristics of 'passive' governor: > > 1. Should we prohibit moving from "others" to "passive"? The relation between parent devfreq and passive devfreq is fixed by h/w because they share the one power line. But, if you want to permit that some devfreq change their governor to passive governor. The current design of devfreq does not support it. We must need to rework the devfreq for the moving from 'others' to 'passive'. The devfreq should consider the multiple dependency on hierachry as CCF (Common Clock Framework). devfreq2 (passive) devfreq5 (passive) devfreq6 (passive) devfreq3 (passive) devfreq4 (passive) devfreq7 (passive) devfreq8 (passive) I add some examples as following: Example1, There is one parent devfreq which includes the four passive devfreqs as following: parent-dev1 (ondemand) passive-dev1 (passive) passive-dev2 (passive) passive-dev3 (passive) passive-dev4 (passive) new-parent-dev2 (ondemand) If changing the governor of 'parent-dev1' from ondemand to passive, the user have to inform the information of new parent devfreq(new-parent-dev2). Maybe, following command should be executed. echo [new-parent-dev2] > /sys/class/devfreq/[parent-dev1]/parent new-parent-dev2 echo passive > /sys/class/devfreq/[parent-dev1]/governor After that, the final hierarchy will be following: new-parent-dev2 (ondemand) parent-dev1 (passive) passive-dev1 (passive) passive-dev2 (passive) passive-dev3 (passive) passive-dev4 (passive) Example2, Before, parent-dev1 (ondemand) passive-dev1 (passive) passive-dev2 (passive) passive-dev3 (passive) passive-dev4 (passive) new-parent-dev2 (ondemand) After that, if new-parent-dev2 use the passive governor with parent-dev1 device. parent-dev1 (ondemand) - control voltage and freq passive-dev1 (passive) - control freq passive-dev2 (passive) - control freq passive-dev3 (passive) - control freq passive-dev4 (passive) - control freq new-parent-dev2 (passive) - control voltage and freq Example3, There is one parent devfreq which includes the four passive devfreqs as following: parent-dev2 (ondemand) new-parent-dev3 (passive) parent-dev1 (ondemand) passive-dev1 (passive) passive-dev2 (passive) passive-dev3 (passive) passive-dev4 (passive) After that, if parent-dev1 use the passive governor with new-parent-dev3 device. parent-dev2 (ondemand) new-parent-dev3 (passive) parent-dev1 (passive) passive-dev1 (passive) passive-dev2 (passive) passive-dev3 (passive) passive-dev4 (passive) > 2. Should we show "passive" in the available list if it's not passive now? Yes. I added the test result on cover letter about this. Even if the parent devfreq device doesn't support the passive governor, their 'available_governor' shows the 'passive' governor. > 3. Why don't we show anyway and reject it when actually tries to change? I think that the sysfs entry have to provide the correct information to user-space. If available_governor shows the name of unsupported governor, it is not reasonable and appropriate. - cat /sys/class/devfreq/[devfreq name]/available_governor So, the 'available_governor' should only show the supported governors. > 4. Or should we add a value in devfreq struct that is confired at devfreq > device add, which prohibits changing governors? (and passive will > return error if that flag is not set or it will set the value automatically) If we add some flags to devfreq for passive govenror, devfreq will prohibits the changing governors. And, avaiable_governor function will use the new flags to show the only supported governors. I tried to use the existing fields of struct devfreq without new field. But if you want to add new field, I'll do. > > Cheers, > MyungJoo > >> >> Fixes: 996133119f57 ("PM / devfreq: Add new passive governor") >> Cc: stable@vger.kernel.org >> Signed-off-by: Chanwoo Choi >> --- >> drivers/devfreq/devfreq.c | 34 +++++++++++++++++++++++++++++++++- >> 1 file changed, 33 insertions(+), 1 deletion(-) -- Best Regards, Chanwoo Choi Samsung Electronics