Re: [PATCHv2 1/1] mmc: core: export emmc revision via sysfs
On Thu, Mar 23, 2017 at 6:03 PM, Ulf Hansson <ulf.hans...@linaro.org> wrote:
> On 23 March 2017 at 01:18, Jin Qian <jinq...@android.com> wrote:
>> Extend sysfs to access ext_csd revision information.
it can be used secure erase feature for each revision. so it's helpful
to support at sysfs node.
Acked-by: Kyungmin Park <kyungmin.p...@samsung.com>
>>
>> Signed-off-by: Jin Qian <jinq...@android.com>
>> ---
>> drivers/mmc/core/mmc.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
>> index 7fd722868875..08c62c9bec48 100644
>> --- a/drivers/mmc/core/mmc.c
>> +++ b/drivers/mmc/core/mmc.c
>> @@ -779,6 +779,7 @@ MMC_DEV_ATTR(manfid, "0x%06x\n", card->cid.manfid);
>> MMC_DEV_ATTR(name, "%s\n", card->cid.prod_name);
>> MMC_DEV_ATTR(oemid, "0x%04x\n", card->cid.oemid);
>> MMC_DEV_ATTR(prv, "0x%x\n", card->cid.prv);
>> +MMC_DEV_ATTR(rev, "0x%x\n", card->ext_csd.rev);
>
> We have "product revision" in CID, we have "CSD structure/spec
> version" in CSD and some other related in EXT_CSD.
>
> To make it clear what "rev" is about, I suggest we follow Jaehoon
> suggestions. Let's name it "ext_csd_rev".
>
>> MMC_DEV_ATTR(pre_eol_info, "%02x\n", card->ext_csd.pre_eol_info);
>> MMC_DEV_ATTR(life_time, "0x%02x 0x%02x\n",
>> card->ext_csd.device_life_time_est_typ_a,
>> @@ -836,6 +837,7 @@ static struct attribute *mmc_std_attrs[] = {
>> _attr_name.attr,
>> _attr_oemid.attr,
>> _attr_prv.attr,
>> + _attr_rev.attr,
>> _attr_pre_eol_info.attr,
>> _attr_life_time.attr,
>> _attr_serial.attr,
>> --
>> 2.12.1.500.gab5fba24ee-goog
>>
>
> Kind regards
> Uffe
Re: [PATCHv2 1/1] mmc: core: export emmc revision via sysfs
On Thu, Mar 23, 2017 at 6:03 PM, Ulf Hansson wrote:
> On 23 March 2017 at 01:18, Jin Qian wrote:
>> Extend sysfs to access ext_csd revision information.
it can be used secure erase feature for each revision. so it's helpful
to support at sysfs node.
Acked-by: Kyungmin Park
>>
>> Signed-off-by: Jin Qian
>> ---
>> drivers/mmc/core/mmc.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
>> index 7fd722868875..08c62c9bec48 100644
>> --- a/drivers/mmc/core/mmc.c
>> +++ b/drivers/mmc/core/mmc.c
>> @@ -779,6 +779,7 @@ MMC_DEV_ATTR(manfid, "0x%06x\n", card->cid.manfid);
>> MMC_DEV_ATTR(name, "%s\n", card->cid.prod_name);
>> MMC_DEV_ATTR(oemid, "0x%04x\n", card->cid.oemid);
>> MMC_DEV_ATTR(prv, "0x%x\n", card->cid.prv);
>> +MMC_DEV_ATTR(rev, "0x%x\n", card->ext_csd.rev);
>
> We have "product revision" in CID, we have "CSD structure/spec
> version" in CSD and some other related in EXT_CSD.
>
> To make it clear what "rev" is about, I suggest we follow Jaehoon
> suggestions. Let's name it "ext_csd_rev".
>
>> MMC_DEV_ATTR(pre_eol_info, "%02x\n", card->ext_csd.pre_eol_info);
>> MMC_DEV_ATTR(life_time, "0x%02x 0x%02x\n",
>> card->ext_csd.device_life_time_est_typ_a,
>> @@ -836,6 +837,7 @@ static struct attribute *mmc_std_attrs[] = {
>> _attr_name.attr,
>> _attr_oemid.attr,
>> _attr_prv.attr,
>> + _attr_rev.attr,
>> _attr_pre_eol_info.attr,
>> _attr_life_time.attr,
>> _attr_serial.attr,
>> --
>> 2.12.1.500.gab5fba24ee-goog
>>
>
> Kind regards
> Uffe
Re: [RFC 0/1] add support for reclaiming priorities per mem cgroup
On Sat, Mar 18, 2017 at 8:16 AM, Tim Murray <timmur...@google.com> wrote: > Hi all, > > I've been working to improve Android's memory management and drop > lowmemorykiller from the kernel, and I'd like to get some feedback on a small > patch with a lot of side effects. > > Currently, when an Android device is under memory pressure, one of three > things will happen from kswapd: > > 1. Compress an anonymous page to ZRAM. > 2. Evict a file page. > 3. Kill a process via lowmemorykiller. > > The first two are cheap and per-page, the third is relatively cheap in the > short term, frees many pages, and may cause power and performance penalties > later on when the process has to be started again. For lots of reasons, I'd > like a better balance between reclamation and killing on Android. > > One of the nice things about Android from an optimization POV is that the > execution model is more constrained than a generic Linux machine. There are > only a limited number of processes that need to execute quickly for the > device to appear to have good performance, and a userspace daemon (called > ActivityManagerService) knows exactly what those processes are at any given > time. We've made use of that in the past via cpusets and schedtune to limit > the CPU resources available to background processes, and I think we can apply > the same concept to memory. > > This patch adds a new tunable to mem cgroups, memory.priority. A mem cgroup > with a non-zero priority will not be eligible for scanning until the > scan_control's priority is greater than zero. Once the mem cgroup is eligible > for scanning, the priority acts as a bias to reduce the number of pages that > should be scanned. Here's old discussion to support app-per-memcg reclaim "[PATCH] memcg: Add force_reclaim to reclaim tasks' memory in memcg." http://www.spinics.net/lists/cgroups/msg07874.html unlike existing interface, it can reclaim the memory while process is still in memcg. In our case, it's used for reclaim and swap out pages for that app. Thank you, Kyungmin Park > > We've seen cases on Android where the global LRU isn't sufficient. For > example, notifications in Android are rendered as part of a separate process > that runs infrequently. However, when a notification appears and the user > slides down the notification tray, we'll often see dropped frames due to page > faults if there has been severe memory pressure. There are similar issues > with other persistent processes. > > The goal on an Android device is to aggressively evict from very low-priority > background tasks that are likely to be killed anyway, since this will reduce > the likelihood of lowmemorykiller running in the first place. It will still > evict some from foreground and persistent processes, but it should help > ensure that background processes are effectively reduced to the size of their > heaps before evicting from more critical tasks. This should mean fewer > background processes end up killed, which should improve performance and > power on Android across the board (since it costs significantly less to page > things back in than to replay the entirety of application startup). > > The follow-on that I'm also experimenting with is how to improve vmpressure > such that userspace can have some idea when low-priority memory cgroups are > about as small as they can get. The correct time for Android to kill a > background process under memory pressure is when there is evidence that a > process has to be killed in order to alleviate memory pressure. If the device > is below the low memory watermark and we know that there's probably no way to > reclaim any more from background processes, then a userspace daemon should > kill one or more background processes to fix that. Per-cgroup priority could > be the first step toward that information. > > I've tested a version of this patch on a Pixel running 3.18 along with an > overhauled version of lmkd (the Android userspace lowmemorykiller daemon), > and it does seem to work fine. I've ported it forward but have not yet > rigorously tested it at TOT, since I don't have an Android test setup running > TOT. While I'm getting my tests ported over, I would like some feedback on > adding another tunable as well as what the tunable's interface should be--I > really don't like the 0-10 priority scheme I have in the patch but I don't > have a better idea. > > Thanks, > Tim > > Tim Murray (1): > mm, memcg: add prioritized reclaim > > include/linux/memcontrol.h | 20 +++- > mm/memcontrol.c| 33 + > mm/vmscan.c| 3 ++- > 3 files changed, 54 insertions(+), 2 deletions(-) > > -- > 2.12.0.367.g23dc2f6d3c-goog > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majord...@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: mailto:"d...@kvack.org;> em...@kvack.org
Re: [RFC 0/1] add support for reclaiming priorities per mem cgroup
On Sat, Mar 18, 2017 at 8:16 AM, Tim Murray wrote: > Hi all, > > I've been working to improve Android's memory management and drop > lowmemorykiller from the kernel, and I'd like to get some feedback on a small > patch with a lot of side effects. > > Currently, when an Android device is under memory pressure, one of three > things will happen from kswapd: > > 1. Compress an anonymous page to ZRAM. > 2. Evict a file page. > 3. Kill a process via lowmemorykiller. > > The first two are cheap and per-page, the third is relatively cheap in the > short term, frees many pages, and may cause power and performance penalties > later on when the process has to be started again. For lots of reasons, I'd > like a better balance between reclamation and killing on Android. > > One of the nice things about Android from an optimization POV is that the > execution model is more constrained than a generic Linux machine. There are > only a limited number of processes that need to execute quickly for the > device to appear to have good performance, and a userspace daemon (called > ActivityManagerService) knows exactly what those processes are at any given > time. We've made use of that in the past via cpusets and schedtune to limit > the CPU resources available to background processes, and I think we can apply > the same concept to memory. > > This patch adds a new tunable to mem cgroups, memory.priority. A mem cgroup > with a non-zero priority will not be eligible for scanning until the > scan_control's priority is greater than zero. Once the mem cgroup is eligible > for scanning, the priority acts as a bias to reduce the number of pages that > should be scanned. Here's old discussion to support app-per-memcg reclaim "[PATCH] memcg: Add force_reclaim to reclaim tasks' memory in memcg." http://www.spinics.net/lists/cgroups/msg07874.html unlike existing interface, it can reclaim the memory while process is still in memcg. In our case, it's used for reclaim and swap out pages for that app. Thank you, Kyungmin Park > > We've seen cases on Android where the global LRU isn't sufficient. For > example, notifications in Android are rendered as part of a separate process > that runs infrequently. However, when a notification appears and the user > slides down the notification tray, we'll often see dropped frames due to page > faults if there has been severe memory pressure. There are similar issues > with other persistent processes. > > The goal on an Android device is to aggressively evict from very low-priority > background tasks that are likely to be killed anyway, since this will reduce > the likelihood of lowmemorykiller running in the first place. It will still > evict some from foreground and persistent processes, but it should help > ensure that background processes are effectively reduced to the size of their > heaps before evicting from more critical tasks. This should mean fewer > background processes end up killed, which should improve performance and > power on Android across the board (since it costs significantly less to page > things back in than to replay the entirety of application startup). > > The follow-on that I'm also experimenting with is how to improve vmpressure > such that userspace can have some idea when low-priority memory cgroups are > about as small as they can get. The correct time for Android to kill a > background process under memory pressure is when there is evidence that a > process has to be killed in order to alleviate memory pressure. If the device > is below the low memory watermark and we know that there's probably no way to > reclaim any more from background processes, then a userspace daemon should > kill one or more background processes to fix that. Per-cgroup priority could > be the first step toward that information. > > I've tested a version of this patch on a Pixel running 3.18 along with an > overhauled version of lmkd (the Android userspace lowmemorykiller daemon), > and it does seem to work fine. I've ported it forward but have not yet > rigorously tested it at TOT, since I don't have an Android test setup running > TOT. While I'm getting my tests ported over, I would like some feedback on > adding another tunable as well as what the tunable's interface should be--I > really don't like the 0-10 priority scheme I have in the patch but I don't > have a better idea. > > Thanks, > Tim > > Tim Murray (1): > mm, memcg: add prioritized reclaim > > include/linux/memcontrol.h | 20 +++- > mm/memcontrol.c| 33 + > mm/vmscan.c| 3 ++- > 3 files changed, 54 insertions(+), 2 deletions(-) > > -- > 2.12.0.367.g23dc2f6d3c-goog > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majord...@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: mailto:"d...@kvack.org;> em...@kvack.org
Re: [RFC PATCH] PM, freezer: Don't thaw when it's intended frozen processes
On Tue, May 12, 2015 at 11:43 PM, Tejun Heo wrote: > Hello, > > On Mon, May 11, 2015 at 04:47:14PM +0900, Kyungmin Park wrote: >> > The kernel 3.10 is not working as expected, but right the latest >> > kernel is working correctly. >> >> Please ignore it. test is wrong and it's not working, see Krzysztof Mail. > > So, I just tested and it does work as expected. What Krzysztof said > is the same thing that I said in the first reply. The tasks will be > woken up but won't leave freezer. Please re-test. Right, it's still in freezer, just one time scheduling is happened. and enter freeze state again. do you think can we avoid it or it's sub-optimal to do as patch? Thank you, Kyungmin Park -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] PM, freezer: Don't thaw when it's intended frozen processes
On Tue, May 12, 2015 at 11:43 PM, Tejun Heo t...@kernel.org wrote: Hello, On Mon, May 11, 2015 at 04:47:14PM +0900, Kyungmin Park wrote: The kernel 3.10 is not working as expected, but right the latest kernel is working correctly. Please ignore it. test is wrong and it's not working, see Krzysztof Mail. So, I just tested and it does work as expected. What Krzysztof said is the same thing that I said in the first reply. The tasks will be woken up but won't leave freezer. Please re-test. Right, it's still in freezer, just one time scheduling is happened. and enter freeze state again. do you think can we avoid it or it's sub-optimal to do as patch? Thank you, Kyungmin Park -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] PM, freezer: Don't thaw when it's intended frozen processes
On Mon, May 11, 2015 at 1:28 PM, Kyungmin Park wrote: > On Sat, May 9, 2015 at 12:25 AM, Tejun Heo wrote: >> Hello, Kyungmin. >> >> On Fri, May 08, 2015 at 09:04:26AM +0900, Kyungmin Park wrote: >>> > I need to think more about it but as an *optimization* we can add >>> > freezing() test before actually waking tasks up during resume, but can >>> > you please clarify what you're seeing? >>> >>> The mobile application has life cycle and one of them is 'suspend' >>> state. it's different from 'pause' or 'background'. >>> if there are some application and enter go 'suspend' state. all >>> behaviors are stopped and can't do anything. right it's suspended. but >>> after system suspend & resume, these application is thawed and >>> running. even though system know it's suspended. >>> >>> We made some test application, print out some message within infinite >>> loop. when it goes 'suspend' state. nothing is print out. but after >>> system suspend & resume, it prints out again. that's not desired >>> behavior. and want to address it. >>> >>> frozen user processes should be remained as frozen while system >>> suspend & resume. >> >> Yes, they should and I'm not sure why what you're saying is happening >> because freezing() test done from the frozen tasks themselves should >> keep them in the freezer. Which kernel version did you test? Can you >> please verify it against a recent kernel? > > The kernel 3.10 is not working as expected, but right the latest > kernel is working correctly. Please ignore it. test is wrong and it's not working, see Krzysztof Mail. > > I see I'll check what's different and which are modified. > > Thank you, > Kyungmin Park -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] PM, freezer: Don't thaw when it's intended frozen processes
On Mon, May 11, 2015 at 1:28 PM, Kyungmin Park kmp...@infradead.org wrote: On Sat, May 9, 2015 at 12:25 AM, Tejun Heo t...@kernel.org wrote: Hello, Kyungmin. On Fri, May 08, 2015 at 09:04:26AM +0900, Kyungmin Park wrote: I need to think more about it but as an *optimization* we can add freezing() test before actually waking tasks up during resume, but can you please clarify what you're seeing? The mobile application has life cycle and one of them is 'suspend' state. it's different from 'pause' or 'background'. if there are some application and enter go 'suspend' state. all behaviors are stopped and can't do anything. right it's suspended. but after system suspend resume, these application is thawed and running. even though system know it's suspended. We made some test application, print out some message within infinite loop. when it goes 'suspend' state. nothing is print out. but after system suspend resume, it prints out again. that's not desired behavior. and want to address it. frozen user processes should be remained as frozen while system suspend resume. Yes, they should and I'm not sure why what you're saying is happening because freezing() test done from the frozen tasks themselves should keep them in the freezer. Which kernel version did you test? Can you please verify it against a recent kernel? The kernel 3.10 is not working as expected, but right the latest kernel is working correctly. Please ignore it. test is wrong and it's not working, see Krzysztof Mail. I see I'll check what's different and which are modified. Thank you, Kyungmin Park -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] PM, freezer: Don't thaw when it's intended frozen processes
On Sat, May 9, 2015 at 12:25 AM, Tejun Heo wrote: > Hello, Kyungmin. > > On Fri, May 08, 2015 at 09:04:26AM +0900, Kyungmin Park wrote: >> > I need to think more about it but as an *optimization* we can add >> > freezing() test before actually waking tasks up during resume, but can >> > you please clarify what you're seeing? >> >> The mobile application has life cycle and one of them is 'suspend' >> state. it's different from 'pause' or 'background'. >> if there are some application and enter go 'suspend' state. all >> behaviors are stopped and can't do anything. right it's suspended. but >> after system suspend & resume, these application is thawed and >> running. even though system know it's suspended. >> >> We made some test application, print out some message within infinite >> loop. when it goes 'suspend' state. nothing is print out. but after >> system suspend & resume, it prints out again. that's not desired >> behavior. and want to address it. >> >> frozen user processes should be remained as frozen while system >> suspend & resume. > > Yes, they should and I'm not sure why what you're saying is happening > because freezing() test done from the frozen tasks themselves should > keep them in the freezer. Which kernel version did you test? Can you > please verify it against a recent kernel? The kernel 3.10 is not working as expected, but right the latest kernel is working correctly. I see I'll check what's different and which are modified. Thank you, Kyungmin Park -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] PM, freezer: Don't thaw when it's intended frozen processes
On Sat, May 9, 2015 at 12:25 AM, Tejun Heo t...@kernel.org wrote: Hello, Kyungmin. On Fri, May 08, 2015 at 09:04:26AM +0900, Kyungmin Park wrote: I need to think more about it but as an *optimization* we can add freezing() test before actually waking tasks up during resume, but can you please clarify what you're seeing? The mobile application has life cycle and one of them is 'suspend' state. it's different from 'pause' or 'background'. if there are some application and enter go 'suspend' state. all behaviors are stopped and can't do anything. right it's suspended. but after system suspend resume, these application is thawed and running. even though system know it's suspended. We made some test application, print out some message within infinite loop. when it goes 'suspend' state. nothing is print out. but after system suspend resume, it prints out again. that's not desired behavior. and want to address it. frozen user processes should be remained as frozen while system suspend resume. Yes, they should and I'm not sure why what you're saying is happening because freezing() test done from the frozen tasks themselves should keep them in the freezer. Which kernel version did you test? Can you please verify it against a recent kernel? The kernel 3.10 is not working as expected, but right the latest kernel is working correctly. I see I'll check what's different and which are modified. Thank you, Kyungmin Park -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] PM, freezer: Don't thaw when it's intended frozen processes
On Fri, May 8, 2015 at 12:42 AM, Tejun Heo wrote: > Hello, > > On Thu, May 07, 2015 at 03:45:57PM +0900, Kyungmin Park wrote: >> From: Kyungmin Park >> >> Some platform uses freezer cgroup for speicial purpose to schedule out some >> applications. but after suspend & resume, these processes are thawed and >> running. > > They shouldn't be able to leave the freezer tho. Resuming does wake > up all tasks but freezing() test would still evaulate to true for the > ones frozen by cgroup freezer and they will stay inside the freezer. > >> but it's inteneded and don't need to thaw it. >> >> To avoid it, does it possible to modify resume code and don't thaw it when >> resume? does it resonable? > > I need to think more about it but as an *optimization* we can add > freezing() test before actually waking tasks up during resume, but can > you please clarify what you're seeing? The mobile application has life cycle and one of them is 'suspend' state. it's different from 'pause' or 'background'. if there are some application and enter go 'suspend' state. all behaviors are stopped and can't do anything. right it's suspended. but after system suspend & resume, these application is thawed and running. even though system know it's suspended. We made some test application, print out some message within infinite loop. when it goes 'suspend' state. nothing is print out. but after system suspend & resume, it prints out again. that's not desired behavior. and want to address it. frozen user processes should be remained as frozen while system suspend & resume. Thank you, Kyungmin Park -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH] PM, freezer: Don't thaw when it's intended frozen processes
From: Kyungmin Park
Some platform uses freezer cgroup for speicial purpose to schedule out some
applications. but after suspend & resume, these processes are thawed and
running.
but it's inteneded and don't need to thaw it.
To avoid it, does it possible to modify resume code and don't thaw it when
resume? does it resonable?
Signed-off-by: Kyungmin Park
---
diff --git a/kernel/power/process.c b/kernel/power/process.c
index 564f786..6eed7df 100644
--- a/kernel/power/process.c
+++ b/kernel/power/process.c
@@ -202,7 +202,9 @@ void thaw_processes(void)
for_each_process_thread(g, p) {
/* No other threads should have PF_SUSPEND_TASK set */
WARN_ON((p != curr) && (p->flags & PF_SUSPEND_TASK));
- __thaw_task(p);
+ /* Don't need to thaw when it's already frozen by userspace */
+ if (!cgroup_freezing(p))
+ __thaw_task(p);
}
read_unlock(_lock);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH] PM, freezer: Don't thaw when it's intended frozen processes
From: Kyungmin Park kyungmin.p...@samsung.com
Some platform uses freezer cgroup for speicial purpose to schedule out some
applications. but after suspend resume, these processes are thawed and
running.
but it's inteneded and don't need to thaw it.
To avoid it, does it possible to modify resume code and don't thaw it when
resume? does it resonable?
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
diff --git a/kernel/power/process.c b/kernel/power/process.c
index 564f786..6eed7df 100644
--- a/kernel/power/process.c
+++ b/kernel/power/process.c
@@ -202,7 +202,9 @@ void thaw_processes(void)
for_each_process_thread(g, p) {
/* No other threads should have PF_SUSPEND_TASK set */
WARN_ON((p != curr) (p-flags PF_SUSPEND_TASK));
- __thaw_task(p);
+ /* Don't need to thaw when it's already frozen by userspace */
+ if (!cgroup_freezing(p))
+ __thaw_task(p);
}
read_unlock(tasklist_lock);
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] PM, freezer: Don't thaw when it's intended frozen processes
On Fri, May 8, 2015 at 12:42 AM, Tejun Heo t...@kernel.org wrote: Hello, On Thu, May 07, 2015 at 03:45:57PM +0900, Kyungmin Park wrote: From: Kyungmin Park kyungmin.p...@samsung.com Some platform uses freezer cgroup for speicial purpose to schedule out some applications. but after suspend resume, these processes are thawed and running. They shouldn't be able to leave the freezer tho. Resuming does wake up all tasks but freezing() test would still evaulate to true for the ones frozen by cgroup freezer and they will stay inside the freezer. but it's inteneded and don't need to thaw it. To avoid it, does it possible to modify resume code and don't thaw it when resume? does it resonable? I need to think more about it but as an *optimization* we can add freezing() test before actually waking tasks up during resume, but can you please clarify what you're seeing? The mobile application has life cycle and one of them is 'suspend' state. it's different from 'pause' or 'background'. if there are some application and enter go 'suspend' state. all behaviors are stopped and can't do anything. right it's suspended. but after system suspend resume, these application is thawed and running. even though system know it's suspended. We made some test application, print out some message within infinite loop. when it goes 'suspend' state. nothing is print out. but after system suspend resume, it prints out again. that's not desired behavior. and want to address it. frozen user processes should be remained as frozen while system suspend resume. Thank you, Kyungmin Park -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] shmem: Add eventfd notification on utlilization level
On Tue, Mar 10, 2015 at 11:22 PM, Jan Kara wrote: > On Tue 10-03-15 06:03:23, Christoph Hellwig wrote: >> On Tue, Mar 10, 2015 at 10:51:41AM +0900, Kyungmin Park wrote: >> > Any updates? >> >> Please just add disk quota support to tmpfs so thast the standard quota >> netlink notifications can be used. > If I understand the problem at hand, they are really interested in > notification when running out of free space. Using quota for that doesn't > seem ideal since that tracks used space per user, not free space on fs as a > whole. > > But if I remember right there were discussions about ENOSPC notification > from filesystem for thin provisioning usecases. It would be good to make > this consistent with those but I'm not sure if it went anywhere. In mobile case, it provides two warning messages when it remains 5% and 0.1% respectively. to achieve it, some daemon call statfs periodically. right it's inefficient. that's reason we need some notification method from filesystem. tmpfs is different story. some malicious app fills tmpfs then system goes slow. so it has to check it periodically. to avoid it, this patch is developed and want to get feedback. we considered quota but it's not desired one. other can't write tmpfs even though it has 20% remaining. Thank you, Kyungmin Park -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] shmem: Add eventfd notification on utlilization level
On Tue, Mar 10, 2015 at 11:22 PM, Jan Kara j...@suse.cz wrote: On Tue 10-03-15 06:03:23, Christoph Hellwig wrote: On Tue, Mar 10, 2015 at 10:51:41AM +0900, Kyungmin Park wrote: Any updates? Please just add disk quota support to tmpfs so thast the standard quota netlink notifications can be used. If I understand the problem at hand, they are really interested in notification when running out of free space. Using quota for that doesn't seem ideal since that tracks used space per user, not free space on fs as a whole. But if I remember right there were discussions about ENOSPC notification from filesystem for thin provisioning usecases. It would be good to make this consistent with those but I'm not sure if it went anywhere. In mobile case, it provides two warning messages when it remains 5% and 0.1% respectively. to achieve it, some daemon call statfs periodically. right it's inefficient. that's reason we need some notification method from filesystem. tmpfs is different story. some malicious app fills tmpfs then system goes slow. so it has to check it periodically. to avoid it, this patch is developed and want to get feedback. we considered quota but it's not desired one. other can't write tmpfs even though it has 20% remaining. Thank you, Kyungmin Park -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] shmem: Add eventfd notification on utlilization level
Any updates?
Thank you,
Kyungmin Park
On Wed, Feb 11, 2015 at 11:50 PM, Krzysztof Kozlowski
wrote:
> Allow notifying user space when used space of tmpfs exceeds specified
> level.
>
> The utilization level is passed as mount option 'warn_used'. The kernel
> will notify user-space through eventfd after exceeding this number of
> used blocks.
>
> The eventfd descriptor has to be passed through sysfs file:
> /sys/fs/tmpfs/tmpfs-[0-9]+/warn_used_blocks_efd
>
> Signed-off-by: Krzysztof Kozlowski
> ---
> include/linux/shmem_fs.h | 4 ++
> mm/shmem.c | 138
> ++-
> 2 files changed, 140 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/shmem_fs.h b/include/linux/shmem_fs.h
> index 50777b5b1e4c..c2ec9909da95 100644
> --- a/include/linux/shmem_fs.h
> +++ b/include/linux/shmem_fs.h
> @@ -35,6 +35,10 @@ struct shmem_sb_info {
> kgid_t gid; /* Mount gid for root directory */
> umode_t mode; /* Mount mode for root directory */
> struct mempolicy *mpol; /* default memory policy for mappings */
> + unsigned long warn_used;/* Warn on reaching used blocks */
> + struct kobject s_kobj; /* kobj for sysfs attributes */
> + struct completion s_kobj_unregister; /* synchronization for put_super
> */
> + struct eventfd_ctx *warn_used_efd; /* user-space passed eventfd */
> };
>
> static inline struct shmem_inode_info *SHMEM_I(struct inode *inode)
> diff --git a/mm/shmem.c b/mm/shmem.c
> index f69d296bd0a3..b559adcef3b3 100644
> --- a/mm/shmem.c
> +++ b/mm/shmem.c
> @@ -34,6 +34,7 @@
> #include
>
> static struct vfsmount *shm_mnt;
> +static struct kset *shmem_kset;
>
> #ifdef CONFIG_SHMEM
> /*
> @@ -69,6 +70,7 @@ static struct vfsmount *shm_mnt;
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -199,6 +201,106 @@ static struct backing_dev_info shmem_backing_dev_info
> __read_mostly = {
> static LIST_HEAD(shmem_swaplist);
> static DEFINE_MUTEX(shmem_swaplist_mutex);
>
> +
> +struct shmem_attr {
> + struct attribute attr;
> + ssize_t (*show)(struct shmem_attr *, struct shmem_sb_info *, char *);
> + ssize_t (*store)(struct shmem_attr *, struct shmem_sb_info *,
> +const char *, size_t);
> +};
> +
> +static int shmem_setup_warn_used_blocks_eventfd(struct shmem_sb_info *sbinfo,
> + unsigned int efd)
> +{
> + int ret = 0;
> +
> + if (sbinfo->warn_used_efd) {
> + eventfd_ctx_put(sbinfo->warn_used_efd);
> + sbinfo->warn_used_efd = NULL;
> + }
> +
> + sbinfo->warn_used_efd = eventfd_ctx_fdget(efd);
> + if (IS_ERR(sbinfo->warn_used_efd)) {
> + ret = PTR_ERR(sbinfo->warn_used_efd);
> + sbinfo->warn_used_efd = NULL;
> + }
> +
> + return ret;
> +}
> +
> +static int parse_strtouint(const char *buf,
> + unsigned long long max, unsigned int *value)
> +{
> + int ret;
> +
> + ret = kstrtouint(skip_spaces(buf), 0, value);
> + if (!ret && *value > max)
> + ret = -EINVAL;
> + return ret;
> +}
> +
> +static ssize_t warn_used_blocks_efd_store(struct shmem_attr *a,
> + struct shmem_sb_info *sbinfo,
> + const char *buf, size_t count)
> +{
> + unsigned int val;
> + int ret;
> +
> + if (parse_strtouint(buf, -1ULL, ))
> + return -EINVAL;
> +
> + ret = shmem_setup_warn_used_blocks_eventfd(sbinfo, val);
> +
> + return ret ? ret : count;
> +}
> +
> +static struct shmem_attr
> +shmem_attr_warn_used_blocks_efd = __ATTR_WO(warn_used_blocks_efd);
> +
> +static struct attribute *shmem_attrs[] = {
> + _attr_warn_used_blocks_efd.attr,
> + NULL,
> +};
> +
> +static ssize_t shmem_attr_show(struct kobject *kobj,
> + struct attribute *attr, char *buf)
> +{
> + struct shmem_sb_info *sbinfo = container_of(kobj, struct
> shmem_sb_info,
> + s_kobj);
> + struct shmem_attr *a = container_of(attr, struct shmem_attr, attr);
> +
> + return a->show ? a->show(a, sbinfo, buf) : 0;
> +}
> +
> +static ssize_t shmem_attr_store(struct kobject *kobj,
> + struct attribute *attr,
> + const char *buf, size_t len)
> +{
Re: [RFC] shmem: Add eventfd notification on utlilization level
Any updates?
Thank you,
Kyungmin Park
On Wed, Feb 11, 2015 at 11:50 PM, Krzysztof Kozlowski
k.kozlow...@samsung.com wrote:
Allow notifying user space when used space of tmpfs exceeds specified
level.
The utilization level is passed as mount option 'warn_used'. The kernel
will notify user-space through eventfd after exceeding this number of
used blocks.
The eventfd descriptor has to be passed through sysfs file:
/sys/fs/tmpfs/tmpfs-[0-9]+/warn_used_blocks_efd
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
include/linux/shmem_fs.h | 4 ++
mm/shmem.c | 138
++-
2 files changed, 140 insertions(+), 2 deletions(-)
diff --git a/include/linux/shmem_fs.h b/include/linux/shmem_fs.h
index 50777b5b1e4c..c2ec9909da95 100644
--- a/include/linux/shmem_fs.h
+++ b/include/linux/shmem_fs.h
@@ -35,6 +35,10 @@ struct shmem_sb_info {
kgid_t gid; /* Mount gid for root directory */
umode_t mode; /* Mount mode for root directory */
struct mempolicy *mpol; /* default memory policy for mappings */
+ unsigned long warn_used;/* Warn on reaching used blocks */
+ struct kobject s_kobj; /* kobj for sysfs attributes */
+ struct completion s_kobj_unregister; /* synchronization for put_super
*/
+ struct eventfd_ctx *warn_used_efd; /* user-space passed eventfd */
};
static inline struct shmem_inode_info *SHMEM_I(struct inode *inode)
diff --git a/mm/shmem.c b/mm/shmem.c
index f69d296bd0a3..b559adcef3b3 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -34,6 +34,7 @@
#include linux/aio.h
static struct vfsmount *shm_mnt;
+static struct kset *shmem_kset;
#ifdef CONFIG_SHMEM
/*
@@ -69,6 +70,7 @@ static struct vfsmount *shm_mnt;
#include linux/syscalls.h
#include linux/fcntl.h
#include uapi/linux/memfd.h
+#include linux/eventfd.h
#include asm/uaccess.h
#include asm/pgtable.h
@@ -199,6 +201,106 @@ static struct backing_dev_info shmem_backing_dev_info
__read_mostly = {
static LIST_HEAD(shmem_swaplist);
static DEFINE_MUTEX(shmem_swaplist_mutex);
+
+struct shmem_attr {
+ struct attribute attr;
+ ssize_t (*show)(struct shmem_attr *, struct shmem_sb_info *, char *);
+ ssize_t (*store)(struct shmem_attr *, struct shmem_sb_info *,
+const char *, size_t);
+};
+
+static int shmem_setup_warn_used_blocks_eventfd(struct shmem_sb_info *sbinfo,
+ unsigned int efd)
+{
+ int ret = 0;
+
+ if (sbinfo-warn_used_efd) {
+ eventfd_ctx_put(sbinfo-warn_used_efd);
+ sbinfo-warn_used_efd = NULL;
+ }
+
+ sbinfo-warn_used_efd = eventfd_ctx_fdget(efd);
+ if (IS_ERR(sbinfo-warn_used_efd)) {
+ ret = PTR_ERR(sbinfo-warn_used_efd);
+ sbinfo-warn_used_efd = NULL;
+ }
+
+ return ret;
+}
+
+static int parse_strtouint(const char *buf,
+ unsigned long long max, unsigned int *value)
+{
+ int ret;
+
+ ret = kstrtouint(skip_spaces(buf), 0, value);
+ if (!ret *value max)
+ ret = -EINVAL;
+ return ret;
+}
+
+static ssize_t warn_used_blocks_efd_store(struct shmem_attr *a,
+ struct shmem_sb_info *sbinfo,
+ const char *buf, size_t count)
+{
+ unsigned int val;
+ int ret;
+
+ if (parse_strtouint(buf, -1ULL, val))
+ return -EINVAL;
+
+ ret = shmem_setup_warn_used_blocks_eventfd(sbinfo, val);
+
+ return ret ? ret : count;
+}
+
+static struct shmem_attr
+shmem_attr_warn_used_blocks_efd = __ATTR_WO(warn_used_blocks_efd);
+
+static struct attribute *shmem_attrs[] = {
+ shmem_attr_warn_used_blocks_efd.attr,
+ NULL,
+};
+
+static ssize_t shmem_attr_show(struct kobject *kobj,
+ struct attribute *attr, char *buf)
+{
+ struct shmem_sb_info *sbinfo = container_of(kobj, struct
shmem_sb_info,
+ s_kobj);
+ struct shmem_attr *a = container_of(attr, struct shmem_attr, attr);
+
+ return a-show ? a-show(a, sbinfo, buf) : 0;
+}
+
+static ssize_t shmem_attr_store(struct kobject *kobj,
+ struct attribute *attr,
+ const char *buf, size_t len)
+{
+ struct shmem_sb_info *sbinfo = container_of(kobj, struct
shmem_sb_info,
+ s_kobj);
+ struct shmem_attr *a = container_of(attr, struct shmem_attr, attr);
+
+ return a-store ? a-store(a, sbinfo, buf, len) : 0;
+}
+
+static void shmem_sb_release(struct kobject *kobj)
+{
+ struct shmem_sb_info *sbinfo = container_of(kobj, struct
shmem_sb_info
Re: [Patch] freezer: check OOM kill signal while being frozen
On Sat, Aug 9, 2014 at 9:46 AM, Cong Wang wrote: > There is a race condition between OOM killer and freezer when > they try to operate on the same process, something like below: > > Process A Process B Process C > trigger oom > B=oom_scan_process_thread() > cgroup_freezer_freeze(B) > ... > try_to_freeze() > stay in D state > oom_kill_process(B) > > In this case, process A triggers OOM and kernel selects process B > as the victim, right before being killed process B was frozen by > process C therefore went to D state, then kernel sent SIGKILL but > it is already too late as process B will never care about pending > signals any more. Fix this straightly by checking fatal pending signal > from OOM killer, so that the frozen process will recover itself > and then be killed finally. Similar patch is posted and discussed but no conclusion. http://marc.info/?t=13769976944=1=1 Adding Bart, Thank you, Kyungmin Park > > Cc: David Rientjes > Cc: Michal Hocko > Cc: "Rafael J. Wysocki" > Cc: Tejun Heo > Cc: Andrew Morton > Signed-off-by: Cong Wang > --- > diff --git a/kernel/freezer.c b/kernel/freezer.c > index aa6a8aa..c6d189d 100644 > --- a/kernel/freezer.c > +++ b/kernel/freezer.c > @@ -68,7 +68,9 @@ bool __refrigerator(bool check_kthr_stop) > spin_lock_irq(_lock); > current->flags |= PF_FROZEN; > if (!freezing(current) || > - (check_kthr_stop && kthread_should_stop())) > + (check_kthr_stop && kthread_should_stop()) || > + (test_tsk_thread_flag(current, TIF_MEMDIE) && > +fatal_signal_pending(current))) > current->flags &= ~PF_FROZEN; > spin_unlock_irq(_lock); > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch] freezer: check OOM kill signal while being frozen
On Sat, Aug 9, 2014 at 9:46 AM, Cong Wang xiyou.wangc...@gmail.com wrote: There is a race condition between OOM killer and freezer when they try to operate on the same process, something like below: Process A Process B Process C trigger oom B=oom_scan_process_thread() cgroup_freezer_freeze(B) ... try_to_freeze() stay in D state oom_kill_process(B) In this case, process A triggers OOM and kernel selects process B as the victim, right before being killed process B was frozen by process C therefore went to D state, then kernel sent SIGKILL but it is already too late as process B will never care about pending signals any more. Fix this straightly by checking fatal pending signal from OOM killer, so that the frozen process will recover itself and then be killed finally. Similar patch is posted and discussed but no conclusion. http://marc.info/?t=13769976944r=1w=1 Adding Bart, Thank you, Kyungmin Park Cc: David Rientjes rient...@google.com Cc: Michal Hocko mho...@suse.cz Cc: Rafael J. Wysocki r...@rjwysocki.net Cc: Tejun Heo t...@kernel.org Cc: Andrew Morton a...@linux-foundation.org Signed-off-by: Cong Wang xiyou.wangc...@gmail.com --- diff --git a/kernel/freezer.c b/kernel/freezer.c index aa6a8aa..c6d189d 100644 --- a/kernel/freezer.c +++ b/kernel/freezer.c @@ -68,7 +68,9 @@ bool __refrigerator(bool check_kthr_stop) spin_lock_irq(freezer_lock); current-flags |= PF_FROZEN; if (!freezing(current) || - (check_kthr_stop kthread_should_stop())) + (check_kthr_stop kthread_should_stop()) || + (test_tsk_thread_flag(current, TIF_MEMDIE) +fatal_signal_pending(current))) current-flags = ~PF_FROZEN; spin_unlock_irq(freezer_lock); -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] new API to allocate buffer-cache for superblock in non-movable area
Adding Marek & Tomasz, On Wed, Jul 30, 2014 at 4:44 PM, Gioh Kim wrote: > > > 2014-07-22 오후 6:38, Jan Kara 쓴 글: > >> On Tue 22-07-14 09:30:05, Peter Zijlstra wrote: >>> >>> On Tue, Jul 22, 2014 at 02:18:47PM +0900, Gioh Kim wrote: >>>> >>>> Hello, >>>> >>>> This patch try to solve problem that a long-lasting page cache of >>>> ext4 superblock disturbs page migration. >>>> >>>> I've been testing CMA feature on my ARM-based platform >>>> and found some pages for page caches cannot be migrated. >>>> Some of them are page caches of superblock of ext4 filesystem. >>>> >>>> Current ext4 reads superblock with sb_bread(). sb_bread() allocates page >>>> from movable area. But the problem is that ext4 hold the page until >>>> it is unmounted. If root filesystem is ext4 the page cannot be migrated >>>> forever. >>>> >>>> I introduce a new API for allocating page from non-movable area. >>>> It is useful for ext4 and others that want to hold page cache for a long >>>> time. >>> >>> >>> There's no word on why you can't teach ext4 to still migrate that page. >>> For all I know it might be impossible, but at least mention why. > > > I am very sorry for lacking of details. > > In ext4_fill_super() the buffer-head of superblock is stored in sbi->s_sbh. > The page belongs to the buffer-head is allocated from movable area. > To migrate the page the buffer-head should be released via brelse(). > But brelse() is not called until unmount. > > For example, fat_fill_super() reads superblock via sb_bread() > and release it via brelse() immediately. Therefore the page that stores > superblock can be migrated. > > > > >>It doesn't seem to be worth the effort to make that page movable to me >> (it's reasonably doable since superblock buffer isn't accessed in *that* >> many places but single movable page doesn't seem like a good tradeoff for >> the complexity). >> >> But this made me look into the migration code and it isn't completely >> clear >> to me what makes the migration code decide that sb buffer isn't movable? >> We >> seem to be locking the buffers before moving the underlying page but we >> don't do any reference or state checks on the buffers... That seems to be >> assuming that noone looks at bh->b_data without holding buffer lock. That >> is likely true for ordinary data but definitely not true for metadata >> buffers (i.e., buffers for pages from block device mappings). > we got similar issues and add similar work-around codes. Thank you, Kyungmin Park > > The sb buffer is not movable because it is not released. > sb_bread increase the reference counter of buffer-head so that > the page of the buffer-head cannot be movable. > > sb_bread allocates page from movable area but it is not movable until the > reference counter of the buffer-head becomes zero. > There is no lock for the buffer but the reference counter acts like lock. > > Actually it is strange that ext4 keeps buffer-head in superblock structure > until unmount (it can be long time) > I thinks the buffer-head should be released immediately like > fat_fill_super() did. > I believe there is a reason to keep buffer-head so that I suggest this > patch. > > > > >> >> Added linux-mm to CC to enlighten me a bit ;) >> >> Honza >> > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majord...@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: mailto:"d...@kvack.org;> em...@kvack.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] new API to allocate buffer-cache for superblock in non-movable area
Adding Marek Tomasz, On Wed, Jul 30, 2014 at 4:44 PM, Gioh Kim gioh@lge.com wrote: 2014-07-22 오후 6:38, Jan Kara 쓴 글: On Tue 22-07-14 09:30:05, Peter Zijlstra wrote: On Tue, Jul 22, 2014 at 02:18:47PM +0900, Gioh Kim wrote: Hello, This patch try to solve problem that a long-lasting page cache of ext4 superblock disturbs page migration. I've been testing CMA feature on my ARM-based platform and found some pages for page caches cannot be migrated. Some of them are page caches of superblock of ext4 filesystem. Current ext4 reads superblock with sb_bread(). sb_bread() allocates page from movable area. But the problem is that ext4 hold the page until it is unmounted. If root filesystem is ext4 the page cannot be migrated forever. I introduce a new API for allocating page from non-movable area. It is useful for ext4 and others that want to hold page cache for a long time. There's no word on why you can't teach ext4 to still migrate that page. For all I know it might be impossible, but at least mention why. I am very sorry for lacking of details. In ext4_fill_super() the buffer-head of superblock is stored in sbi-s_sbh. The page belongs to the buffer-head is allocated from movable area. To migrate the page the buffer-head should be released via brelse(). But brelse() is not called until unmount. For example, fat_fill_super() reads superblock via sb_bread() and release it via brelse() immediately. Therefore the page that stores superblock can be migrated. It doesn't seem to be worth the effort to make that page movable to me (it's reasonably doable since superblock buffer isn't accessed in *that* many places but single movable page doesn't seem like a good tradeoff for the complexity). But this made me look into the migration code and it isn't completely clear to me what makes the migration code decide that sb buffer isn't movable? We seem to be locking the buffers before moving the underlying page but we don't do any reference or state checks on the buffers... That seems to be assuming that noone looks at bh-b_data without holding buffer lock. That is likely true for ordinary data but definitely not true for metadata buffers (i.e., buffers for pages from block device mappings). we got similar issues and add similar work-around codes. Thank you, Kyungmin Park The sb buffer is not movable because it is not released. sb_bread increase the reference counter of buffer-head so that the page of the buffer-head cannot be movable. sb_bread allocates page from movable area but it is not movable until the reference counter of the buffer-head becomes zero. There is no lock for the buffer but the reference counter acts like lock. Actually it is strange that ext4 keeps buffer-head in superblock structure until unmount (it can be long time) I thinks the buffer-head should be released immediately like fat_fill_super() did. I believe there is a reason to keep buffer-head so that I suggest this patch. Added linux-mm to CC to enlighten me a bit ;) Honza -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majord...@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: a href=mailto:d...@kvack.org; em...@kvack.org /a -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2 8/8] devfreq: exynos4: Add busfreq driver for exynos4210/exynos4x12
On Sat, Mar 15, 2014 at 2:35 AM, Tomasz Figa wrote: > Hi Chanwoo, Mark, > > > On 14.03.2014 11:56, Chanwoo Choi wrote: >> >> Hi Mark, >> >> On 03/14/2014 07:35 PM, Mark Rutland wrote: >>> >>> On Fri, Mar 14, 2014 at 07:14:37AM +, Chanwoo Choi wrote: Hi Mark, On 03/14/2014 02:53 AM, Mark Rutland wrote: > > On Thu, Mar 13, 2014 at 08:17:29AM +, Chanwoo Choi wrote: >> >> This patch add busfreq driver for Exynos4210/Exynos4x12 memory >> interface >> and bus to support DVFS(Dynamic Voltage Frequency Scaling) according >> to PPMU >> counters. PPMU (Performance Profiling Monitorings Units) of Exynos4 >> SoC provides >> PPMU counters for DMC(Dynamic Memory Controller) to check memory bus >> utilization >> and then busfreq driver adjusts dynamically the operating >> frequency/voltage >> by using DEVFREQ Subsystem. >> >> Signed-off-by: Chanwoo Choi >> --- >> .../devicetree/bindings/devfreq/exynos4_bus.txt| 49 >> ++ >> 1 file changed, 49 insertions(+) >> create mode 100644 >> Documentation/devicetree/bindings/devfreq/exynos4_bus.txt >> >> diff --git a/Documentation/devicetree/bindings/devfreq/exynos4_bus.txt >> b/Documentation/devicetree/bindings/devfreq/exynos4_bus.txt >> new file mode 100644 >> index 000..2a83fcc >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/devfreq/exynos4_bus.txt >> @@ -0,0 +1,49 @@ >> + >> +Exynos4210/4x12 busfreq driver >> +- >> + >> +Exynos4210/4x12 Soc busfreq driver with devfreq for Memory bus >> frequency/voltage >> +scaling according to PPMU counters of memory controllers >> + >> +Required properties: >> +- compatible : should contain Exynos4 SoC type as follwoing: >> + - "samsung,exynos4x12-busfreq" for Exynos4x12 >> + - "samsung,exynos4210-busfreq" for Exynos4210 > > > Is there a device called "busfreq"? What device does this binding > describe? I'll add detailed description of busfreq as following: "busfreq(bus frequendcy)" driver means that busfreq driver control dynamically memory bus frequency/voltage by checking memory bus utilization to optimize power-consumption. When checking memeory bus utilization, exynos4_busfreq driver would use PPMU(Performance Profiling Monitoring Units). >>> >>> >>> This still sounds like a description of the _driver_, not the _device_. >>> The binding should describe the hardware, now the high level abstraction >>> that software is going to build atop of it. >>> >>> It sounds like this is a binding for the DMC PPMU? >>> >>> Is the PPMU a component of the DMC, or is it bolted on the side? >> >> >> PPMU(Performance Profiling Monitoring Unit) is to profile performance >> event of >> various IP on Exynos4. Each PPMU provide perforamnce event for each IP. >> We can check various PPMU as following: >> >> PPMU_3D >> PPMU_ACP >> PPMU_CAMIF >> PPMU_CPU >> PPMU_DMC0 >> PPMU_DMC1 >> PPMU_FSYS >> PPMU_IMAGE >> PPMU_LCD0 >> PPMU_LCD1 >> PPMU_MFC_L >> PPMU_MFC_R >> PPMU_TV >> PPMU_LEFT_BUS >> PPMU_RIGHT_BUS >> >> DMC (Dynamic Memory Controller) control the operation of DRAM in Exynos4 >> SoC. >> If we need to get memory bust utilization of DMC, we can get memory bus >> utilization >> from PPMU_DMC0/PPMU_DMC1. >> >> So, Exynos4's busfreq used two(PPMU_DMC0/PPMU_DMC1) among upper various >> PPMU list. > > > Well, PPMUs and DMCs are separate hardware blocks found inside Exynos SoCs. > Busfreq/devfreq is just a Linux-specific abstraction responsible for > collecting data using PPMUs and controlling frequencies and voltages of > appropriate power planes, vdd_int responsible for powering DMC0 and DMC1 > blocks in this case. > > I'm afraid that the binding you're proposing is unfortunately incorrect, > because it represents the software abstraction, not the real hardware. > > Instead, this should be separated into several independent bindings: > > - PPMU bindings to list all the PPMU instances present in the SoC and > resources they need, > > - power plane bindings, which define a power plane in which multiple IP > blocks might reside, can be monitored by one or more PPMU units and > frequency and voltage of which can be configured according to determined > performance level. Needed resources will be clocks and regulators to scale > and probably also operating points. > > Then, exynos-busfreq driver should bind to such power planes, parse > necessary data from DT (list of PPMUs and IP blocks, clocks, regulators and > operating points) and register a devfreq entity. How about to use component DT like DRM? > > Best regards, > Tomasz > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at
Re: [PATCHv2 8/8] devfreq: exynos4: Add busfreq driver for exynos4210/exynos4x12
On Sat, Mar 15, 2014 at 2:35 AM, Tomasz Figa t.f...@samsung.com wrote: Hi Chanwoo, Mark, On 14.03.2014 11:56, Chanwoo Choi wrote: Hi Mark, On 03/14/2014 07:35 PM, Mark Rutland wrote: On Fri, Mar 14, 2014 at 07:14:37AM +, Chanwoo Choi wrote: Hi Mark, On 03/14/2014 02:53 AM, Mark Rutland wrote: On Thu, Mar 13, 2014 at 08:17:29AM +, Chanwoo Choi wrote: This patch add busfreq driver for Exynos4210/Exynos4x12 memory interface and bus to support DVFS(Dynamic Voltage Frequency Scaling) according to PPMU counters. PPMU (Performance Profiling Monitorings Units) of Exynos4 SoC provides PPMU counters for DMC(Dynamic Memory Controller) to check memory bus utilization and then busfreq driver adjusts dynamically the operating frequency/voltage by using DEVFREQ Subsystem. Signed-off-by: Chanwoo Choi cw00.c...@samsung.com --- .../devicetree/bindings/devfreq/exynos4_bus.txt| 49 ++ 1 file changed, 49 insertions(+) create mode 100644 Documentation/devicetree/bindings/devfreq/exynos4_bus.txt diff --git a/Documentation/devicetree/bindings/devfreq/exynos4_bus.txt b/Documentation/devicetree/bindings/devfreq/exynos4_bus.txt new file mode 100644 index 000..2a83fcc --- /dev/null +++ b/Documentation/devicetree/bindings/devfreq/exynos4_bus.txt @@ -0,0 +1,49 @@ + +Exynos4210/4x12 busfreq driver +- + +Exynos4210/4x12 Soc busfreq driver with devfreq for Memory bus frequency/voltage +scaling according to PPMU counters of memory controllers + +Required properties: +- compatible : should contain Exynos4 SoC type as follwoing: + - samsung,exynos4x12-busfreq for Exynos4x12 + - samsung,exynos4210-busfreq for Exynos4210 Is there a device called busfreq? What device does this binding describe? I'll add detailed description of busfreq as following: busfreq(bus frequendcy) driver means that busfreq driver control dynamically memory bus frequency/voltage by checking memory bus utilization to optimize power-consumption. When checking memeory bus utilization, exynos4_busfreq driver would use PPMU(Performance Profiling Monitoring Units). This still sounds like a description of the _driver_, not the _device_. The binding should describe the hardware, now the high level abstraction that software is going to build atop of it. It sounds like this is a binding for the DMC PPMU? Is the PPMU a component of the DMC, or is it bolted on the side? PPMU(Performance Profiling Monitoring Unit) is to profile performance event of various IP on Exynos4. Each PPMU provide perforamnce event for each IP. We can check various PPMU as following: PPMU_3D PPMU_ACP PPMU_CAMIF PPMU_CPU PPMU_DMC0 PPMU_DMC1 PPMU_FSYS PPMU_IMAGE PPMU_LCD0 PPMU_LCD1 PPMU_MFC_L PPMU_MFC_R PPMU_TV PPMU_LEFT_BUS PPMU_RIGHT_BUS DMC (Dynamic Memory Controller) control the operation of DRAM in Exynos4 SoC. If we need to get memory bust utilization of DMC, we can get memory bus utilization from PPMU_DMC0/PPMU_DMC1. So, Exynos4's busfreq used two(PPMU_DMC0/PPMU_DMC1) among upper various PPMU list. Well, PPMUs and DMCs are separate hardware blocks found inside Exynos SoCs. Busfreq/devfreq is just a Linux-specific abstraction responsible for collecting data using PPMUs and controlling frequencies and voltages of appropriate power planes, vdd_int responsible for powering DMC0 and DMC1 blocks in this case. I'm afraid that the binding you're proposing is unfortunately incorrect, because it represents the software abstraction, not the real hardware. Instead, this should be separated into several independent bindings: - PPMU bindings to list all the PPMU instances present in the SoC and resources they need, - power plane bindings, which define a power plane in which multiple IP blocks might reside, can be monitored by one or more PPMU units and frequency and voltage of which can be configured according to determined performance level. Needed resources will be clocks and regulators to scale and probably also operating points. Then, exynos-busfreq driver should bind to such power planes, parse necessary data from DT (list of PPMUs and IP blocks, clocks, regulators and operating points) and register a devfreq entity. How about to use component DT like DRM? Best regards, Tomasz -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] dt: Document ModelGauge gauge bindings
On Fri, Jan 10, 2014 at 1:49 AM, Vladimir Barinov
wrote:
> These bindings can be used to register Maxim ModelGauge ICs fuel gauge
> (MAX17040/41/43/44/48/49/58/59)
>
> Signed-off-by: Vladimir Barinov
>
> ---
> Documentation/devicetree/bindings/power_supply/modelgauge_battery.txt | 82
> ++
> 1 file changed, 82 insertions(+)
>
> Index:
> battery-2.6/Documentation/devicetree/bindings/power_supply/modelgauge_battery.txt
> ===
> --- /dev/null 1970-01-01 00:00:00.0 +
> +++
> battery-2.6/Documentation/devicetree/bindings/power_supply/modelgauge_battery.txt
>2014-01-09 15:09:38.035138887 +0400
> @@ -0,0 +1,82 @@
> +modelgauge_battery
> +~~
> +
> +Required properties:
> + - compatible : should contain one of the following:
> + - "maxim,max17040" for MAX17040
> + - "maxim,max17041" for MAX17041
> + - "maxim,max17043" for MAX17043
> + - "maxim,max17044" for MAX17044
> + - "maxim,max17048" for MAX17048
> + - "maxim,max17049" for MAX17049
> + - "maxim,max17058" for MAX17058
> + - "maxim,max17059" for MAX17059
> +
> +Optional properties:
> + - maxim,empty_alert_threshold : Capacity threshold where an interrupt is
> + generated on the ALRT pin;
> +
> + - soc_change_alert: /* alert for 1% soc change */
> + - hibernate_threshold : Hibernate threshold (crate), where IC
> + enters hibernate mode
> + - active_threshold: Active threshold (mV), where IC exits
> + hibernate mode
> + - undervoltage: Voltage (mV), when IC alerts while
> battery
> + voltage less then undervoltage
> + - overvoltage : Voltage (mV), when IC alerts while battery
> + voltage greater then overvoltage
> + - maxim,resetvoltage : Voltage threshold (mV) below which the IC
> + resets itself. Used to detect battery
> removal
> + and reinsertion;
> + - maxim,empty_adjustment : Capacity charge empty design value;
> + - maxim,full_adjustment : Capacity charge full design value;
> + - maxim,rcomp0: ModelGauge RCOMP parameter, used for
> + temperature compensation;
> + - maxim,temp_co_up: ModelGauge TempCoUp parameter, used for
> + temperature compensation;
> + - maxim,temp_co_down : ModelGauge TempCoDown parameter, used for
> + temperature compensation;
> + - maxim,ocvtest : ModelGauge OCVTest parameter, used for
> + verification of Custom Model calibration
> data
> + loaded into IC RAM;
> + - maxim,soc_check_a : ModelGauge SOCCheckA parameter, used for
> + verification of Custom Model calibration
> data
> + loaded into IC RAM;
> + - maxim,soc_check_b : ModelGauge SOCCheckB parameter, used for
> + verification of Custom Model calibration
> data
> + loaded into IC RAM;
> + - maxim,bits : ModelGauge Bits parameter, used as
> + scaling parameter in Custom Model algorithm;
> + - maxim,model_data: ModelGauge ModelData data,
> + Custom Model calibration data.
Dose it open to vendor? we're using this chip. we don't need to setup
it at all. most of property except "rcomp" doesn't used.
Thank you,
Kyungmin Park
> +
> +Example:
> +
> +modelgauge@36 {
> + compatible = "maxim,max17058";
> + reg = <0x36>;
> + interrupt-parent = <>;
> + interrupts = <107 0x2>;
> +
> + maxim,empty_alert_threshold = /bits/ 8 <15>;
> + maxim,resetvoltage = /bits/ 16 <0>;
> + maxim,empty_adjustment = /bits/ 8 <0>;
> + maxim,full_adjustment = /bits/ 8 <100>;
> + maxim,rcomp0 = /bits/ 8 <175>;
> + maxim,temp_co_up = <(-1100)>;
> + maxim,temp_co_down = <(-4000)>;
> + maxim,ocvtest = /bits/ 16 <56144>;
> + maxim,
Re: [PATCH 2/3] dt: Document ModelGauge gauge bindings
On Fri, Jan 10, 2014 at 1:49 AM, Vladimir Barinov
vladimir.bari...@cogentembedded.com wrote:
These bindings can be used to register Maxim ModelGauge ICs fuel gauge
(MAX17040/41/43/44/48/49/58/59)
Signed-off-by: Vladimir Barinov vladimir.bari...@cogentembedded.com
---
Documentation/devicetree/bindings/power_supply/modelgauge_battery.txt | 82
++
1 file changed, 82 insertions(+)
Index:
battery-2.6/Documentation/devicetree/bindings/power_supply/modelgauge_battery.txt
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++
battery-2.6/Documentation/devicetree/bindings/power_supply/modelgauge_battery.txt
2014-01-09 15:09:38.035138887 +0400
@@ -0,0 +1,82 @@
+modelgauge_battery
+~~
+
+Required properties:
+ - compatible : should contain one of the following:
+ - maxim,max17040 for MAX17040
+ - maxim,max17041 for MAX17041
+ - maxim,max17043 for MAX17043
+ - maxim,max17044 for MAX17044
+ - maxim,max17048 for MAX17048
+ - maxim,max17049 for MAX17049
+ - maxim,max17058 for MAX17058
+ - maxim,max17059 for MAX17059
+
+Optional properties:
+ - maxim,empty_alert_threshold : Capacity threshold where an interrupt is
+ generated on the ALRT pin;
+
+ - soc_change_alert: /* alert for 1% soc change */
+ - hibernate_threshold : Hibernate threshold (crate), where IC
+ enters hibernate mode
+ - active_threshold: Active threshold (mV), where IC exits
+ hibernate mode
+ - undervoltage: Voltage (mV), when IC alerts while
battery
+ voltage less then undervoltage
+ - overvoltage : Voltage (mV), when IC alerts while battery
+ voltage greater then overvoltage
+ - maxim,resetvoltage : Voltage threshold (mV) below which the IC
+ resets itself. Used to detect battery
removal
+ and reinsertion;
+ - maxim,empty_adjustment : Capacity charge empty design value;
+ - maxim,full_adjustment : Capacity charge full design value;
+ - maxim,rcomp0: ModelGauge RCOMP parameter, used for
+ temperature compensation;
+ - maxim,temp_co_up: ModelGauge TempCoUp parameter, used for
+ temperature compensation;
+ - maxim,temp_co_down : ModelGauge TempCoDown parameter, used for
+ temperature compensation;
+ - maxim,ocvtest : ModelGauge OCVTest parameter, used for
+ verification of Custom Model calibration
data
+ loaded into IC RAM;
+ - maxim,soc_check_a : ModelGauge SOCCheckA parameter, used for
+ verification of Custom Model calibration
data
+ loaded into IC RAM;
+ - maxim,soc_check_b : ModelGauge SOCCheckB parameter, used for
+ verification of Custom Model calibration
data
+ loaded into IC RAM;
+ - maxim,bits : ModelGauge Bits parameter, used as
+ scaling parameter in Custom Model algorithm;
+ - maxim,model_data: ModelGauge ModelData data,
+ Custom Model calibration data.
Dose it open to vendor? we're using this chip. we don't need to setup
it at all. most of property except rcomp doesn't used.
Thank you,
Kyungmin Park
+
+Example:
+
+modelgauge@36 {
+ compatible = maxim,max17058;
+ reg = 0x36;
+ interrupt-parent = msmgpio;
+ interrupts = 107 0x2;
+
+ maxim,empty_alert_threshold = /bits/ 8 15;
+ maxim,resetvoltage = /bits/ 16 0;
+ maxim,empty_adjustment = /bits/ 8 0;
+ maxim,full_adjustment = /bits/ 8 100;
+ maxim,rcomp0 = /bits/ 8 175;
+ maxim,temp_co_up = (-1100);
+ maxim,temp_co_down = (-4000);
+ maxim,ocvtest = /bits/ 16 56144;
+ maxim,soc_check_a = /bits/ 8 241;
+ maxim,soc_check_b = /bits/ 8 243;
+ maxim,bits = /bits/ 8 19;
+
+ maxim,model_data = /bits/ 8
+ 0x9B 0x70 0xAB 0x30 0xB5 0xA0 0xB9 0xD0
+ 0xBB 0xA0 0xBC 0x00 0xBC 0xB0 0xBD 0x00
+ 0xBD 0x60 0xBE 0x40 0xBF 0x40 0xC1 0xF0
+ 0xC5 0x60 0xC8 0xA0 0xCD 0x00 0xD1 0x50
+ 0x00 0xE0 0x01 0x80 0x18 0x60 0x1C 0x20
+ 0x54 0x00 0x6A 0xC0 0x79 0x20 0x65 0xC0
Re: [PATCH v7 3/3] mfd: max14577: Add device tree bindings document
On Mon, Jan 6, 2014 at 7:46 PM, Lee Jones wrote: >> Add document describing device tree bindings for MAX14577 MFD driver. >> >> Signed-off-by: Krzysztof Kozlowski >> Signed-off-by: Kyungmin Park >> --- >> Documentation/devicetree/bindings/mfd/max14577.txt | 65 >> >> 1 file changed, 65 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/mfd/max14577.txt > > You still need a DT Ack before I can apply this. Tomasz, can you ack it? Thank you, Kyungmin Park -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 3/3] mfd: max14577: Add device tree bindings document
On Mon, Jan 6, 2014 at 7:46 PM, Lee Jones lee.jo...@linaro.org wrote: Add document describing device tree bindings for MAX14577 MFD driver. Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- Documentation/devicetree/bindings/mfd/max14577.txt | 65 1 file changed, 65 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/max14577.txt You still need a DT Ack before I can apply this. Tomasz, can you ack it? Thank you, Kyungmin Park -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v2] kernel/locking: mutex: simplify access to the first entry in the wait-list
> -Original Message- > From: Peter Zijlstra [mailto:pet...@infradead.org] > Sent: Thursday, December 12, 2013 8:35 PM > To: Andrzej Pietrasiewicz > Cc: linux-kernel@vger.kernel.org; Kyungmin Park; Marek Szyprowski; Ingo > Molnar > Subject: Re: [PATCH v2] kernel/locking: mutex: simplify access to the > first entry in the wait-list > > On Thu, Dec 12, 2013 at 12:29:32PM +0100, Andrzej Pietrasiewicz wrote: > > Use list_first_entry instead of explicitly accessing the first entry > > with "head".next. The comment one line above becomes obsolete. > > > > Signed-off-by: Andrzej Pietrasiewicz > > Signed-off-by: Kyungmin Park > > --- > > > > v1..v2: > > > > - corrected the email address in the second Signed-off-by line > > Still invalid; the problem is that you appear to have written the patch > (you send it and you have first sob). > So what is Kyungmin doing in the line? He did not send me your patch. Internal review process, and it represents this patch comes from. Thank you, Kyungmin Park -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v2] kernel/locking: mutex: simplify access to the first entry in the wait-list
-Original Message- From: Peter Zijlstra [mailto:pet...@infradead.org] Sent: Thursday, December 12, 2013 8:35 PM To: Andrzej Pietrasiewicz Cc: linux-kernel@vger.kernel.org; Kyungmin Park; Marek Szyprowski; Ingo Molnar Subject: Re: [PATCH v2] kernel/locking: mutex: simplify access to the first entry in the wait-list On Thu, Dec 12, 2013 at 12:29:32PM +0100, Andrzej Pietrasiewicz wrote: Use list_first_entry instead of explicitly accessing the first entry with head.next. The comment one line above becomes obsolete. Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- v1..v2: - corrected the email address in the second Signed-off-by line Still invalid; the problem is that you appear to have written the patch (you send it and you have first sob). So what is Kyungmin doing in the line? He did not send me your patch. Internal review process, and it represents this patch comes from. Thank you, Kyungmin Park -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: samsung: Allow pin value to be initialized using pinfunc.
On Wed, Nov 20, 2013 at 4:16 AM, Stephen Warren wrote: > On 11/19/2013 11:59 AM, Doug Anderson wrote: >> On Tue, Nov 19, 2013 at 10:46 AM, Stephen Warren >> wrote: >>> On 11/19/2013 10:15 AM, Tomasz Figa wrote: >>>> This patch extends the range of settings configurable via pinfunc API >>>> to cover pin value as well. This allows configuration of default values >>>> of pins. >>> >>> Shouldn't there be a driver that acquires the GPIO that's output to the >>> pin, and configures the output value? IIRC there have been previous >>> discussions re: having a list of e.g. initial GPIO output values in DT, >>> and that was rejected, and this patch seems to be doing almost the exact >>> same thing, just at the pinctrl level rather than GPIO level. >>> >>> That all said, I admit this could be a useful feature... >> >> I haven't followed all of the previous discussions, but I know I've >> run into scenarios where something like this would be useful. The one >> that comes to mind is: >> >> * We've got GPIOs that default at bootup to a pulled up input since >> the default state of the pin should be "high". >> >> * These pins are really intended to be outputs, like an "enable", >> "reset", or "power down" line for a peripheral. The pullup is strong >> enough to give us a good default state but we really want outputs. >> >> * We'd like to provide this GPIO to a peripheral through device tree. >> ...and we'd like all the pinmux to be setup automatically so we use >> pinctrl-names = "default". >> >> * If we set the pinmux up as "output" then there's a chance that the >> line will glitch at bootup since the pinmux happens (changing the pin >> to output) before the driver has a chance to run. > > I think that last point should be addressed by having a driver that owns > the GPIO set it to the desired output level, and the implementation of Some pins are not connected (NC). At that cases, there's no drivers to handle it. To reduce power leakage, it sets proper configuration with values instead of reset values. Thank you, Kyungmin Park > the SoC's GPIO driver communicate with the pinctrl driver (which might > be the same driver; not sure here) so that gpio_direction_output() > causes the pinctrl HW to be programmed as output only after the GPIO HW > is programmed as output and with the correct output value. In this > scenario, the pinctrl default state wouldn't touch the pin's > input/output setting; that operation would be deferred until the driver > set up the GPIO as an output. > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: samsung: Allow pin value to be initialized using pinfunc.
On Wed, Nov 20, 2013 at 4:16 AM, Stephen Warren swar...@wwwdotorg.org wrote: On 11/19/2013 11:59 AM, Doug Anderson wrote: On Tue, Nov 19, 2013 at 10:46 AM, Stephen Warren swar...@wwwdotorg.org wrote: On 11/19/2013 10:15 AM, Tomasz Figa wrote: This patch extends the range of settings configurable via pinfunc API to cover pin value as well. This allows configuration of default values of pins. Shouldn't there be a driver that acquires the GPIO that's output to the pin, and configures the output value? IIRC there have been previous discussions re: having a list of e.g. initial GPIO output values in DT, and that was rejected, and this patch seems to be doing almost the exact same thing, just at the pinctrl level rather than GPIO level. That all said, I admit this could be a useful feature... I haven't followed all of the previous discussions, but I know I've run into scenarios where something like this would be useful. The one that comes to mind is: * We've got GPIOs that default at bootup to a pulled up input since the default state of the pin should be high. * These pins are really intended to be outputs, like an enable, reset, or power down line for a peripheral. The pullup is strong enough to give us a good default state but we really want outputs. * We'd like to provide this GPIO to a peripheral through device tree. ...and we'd like all the pinmux to be setup automatically so we use pinctrl-names = default. * If we set the pinmux up as output then there's a chance that the line will glitch at bootup since the pinmux happens (changing the pin to output) before the driver has a chance to run. I think that last point should be addressed by having a driver that owns the GPIO set it to the desired output level, and the implementation of Some pins are not connected (NC). At that cases, there's no drivers to handle it. To reduce power leakage, it sets proper configuration with values instead of reset values. Thank you, Kyungmin Park the SoC's GPIO driver communicate with the pinctrl driver (which might be the same driver; not sure here) so that gpio_direction_output() causes the pinctrl HW to be programmed as output only after the GPIO HW is programmed as output and with the correct output value. In this scenario, the pinctrl default state wouldn't touch the pin's input/output setting; that operation would be deferred until the driver set up the GPIO as an output. ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] mfd: max14577: Add max14577 MFD driver core
On Wed, Nov 13, 2013 at 10:13 PM, Mark Brown wrote:
> On Wed, Nov 13, 2013 at 08:40:54AM +0100, Krzysztof Kozlowski wrote:
>
>> +/**
>> + * After resuming from suspend it may happen that IRQ is signalled but
>> + * IRQ GPIO is not high. Also the interrupt registers won't have any data
>> + * (all of them equal to 0x00).
>> + *
>> + * In such case retry few times reading the interrupt registers.
>> + */
>> +#define IRQ_READ_REG_RETRY_CNT 5
>
> What is the cause here? This smells like an unreliable workaround for
> some other behaviour. In general this all looks very like standard
> regmap code.
>
>> + for (i = 0; i < MAX14577_IRQ_REGS_NUM; i++) {
>> + u8 mask_reg = max14577_mask_reg[i];
>> +
>> + if (mask_reg == MAX14577_REG_INVALID ||
>> + IS_ERR_OR_NULL(max14577->regmap))
>> + continue;
>
> Why would this code even be running if you don't have a register map?
>
>> + dev_info(max14577->dev, "Got interrupts [1:0x%02x, 2:0x%02x,
>> 3:0x%02x]\n",
>> + irq_reg[MAX14577_IRQ_INT1], irq_reg[MAX14577_IRQ_INT2],
>> + irq_reg[MAX14577_IRQ_INT3]);
>
> This is far too noisy, dev_dbg() at most.
>
>> + gpio_val = gpio_get_value(pdata->irq_gpio);
>> +
>> + if (gpio_get_value(pdata->irq_gpio) == 0)
>> + dev_warn(max14577->dev, "IRQ GPIO is not high, retry
>> reading interrupt registers\n");
>> + } while (gpio_val == 0 && --retry > 0);
>
> This looks very strange...
>
>> + max14577->irq = gpio_to_irq(pdata->irq_gpio);
>> + ret = gpio_request(pdata->irq_gpio, "max14577_irq");
>> + if (ret) {
>> + dev_err(max14577->dev, "Failed requesting GPIO %d: %d\n",
>> + pdata->irq_gpio, ret);
>> + goto err;
>> + }
>> + gpio_direction_input(pdata->irq_gpio);
>> + gpio_free(pdata->irq_gpio);
>
> This means the GPIO handling code that was present in the handling is
> broken, it's trying to use the GPIO after it was freed.
>
>> + ret = request_threaded_irq(max14577->irq, NULL, max14577_irq_thread,
>> +IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
>> +"max14577-irq", max14577);
>
> Are you *positive* this is a falling triggered IRQ? All the code to do
> with spinning reading the GPIO state during handling makes it look like
> this is in fact an active low interrupt and a lot of the code in here is
> working around trying to handle that as the wrong kind of IRQ.
It's not work with level triggering. as wm8994, it requires edge
triggering. previous time I send RFC patch to handle edge triggering
at regmap.
>
>> +int max14577_bulk_write(struct regmap *map, u8 reg, u8 *buf, int count)
>> +{
>> + return regmap_bulk_write(map, reg, buf, count);
>> +}
>> +EXPORT_SYMBOL_GPL(max14577_bulk_write);
>
> Given that these are basically all trivial wrappers around regmap they
> probably ought to be static inlines in the header.
>
>> +static struct max14577_platform_data *max14577_i2c_parse_dt(struct device
>> *dev)
>> +{
>
> There's no DT binding document?
>
>> +const struct dev_pm_ops max14577_pm = {
>> + .suspend = max14577_suspend,
>> + .resume = max14577_resume,
>> +};
>
> SET_SYSTEM_SLEEP_PM_OPS().
>
>> +static int __init max14577_i2c_init(void)
>> +{
>> + return i2c_add_driver(_i2c_driver);
>> +}
>> +subsys_initcall(max14577_i2c_init);
>
> Why not module_i2c_driver?
there's ordering issue, it should provide regulator which is used
others before USB probe. if not, it failed to use USB.
Other PMICs use also subsys_initcall for this reason.
Thank you,
Kyungmin Park
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] regulator: s5m8767: Disable OVCB in probe
On Wed, Nov 13, 2013 at 10:50 PM, Mark Brown wrote: > On Tue, Nov 12, 2013 at 02:41:55PM +0100, Krzysztof Kozlowski wrote: >> According to SW Guide the Over-Voltage Clamp may malfunction at VBatt >> 5.25V and 110'C temperature. This may result in overshooting or >> undershooting LDO's voltage outputs. >> Disable the Over-Voltage Clamp in probe by updating proper bit in all >> LDO registers. > > Is there no way to detect these conditions at runtime? The temperature > condition in particular seems very high and hence relatively unlikely to > hold most of the time, disabling the overvoltage protection all the time > seems like an uncertain tradeoff. It's hard to do at runtime. right it's rare case. but some condition (as above) is meet, and no code as workaround. it's mal-function. that's the guide to avoid this mal-functions. Thank you, Kyungmin Park -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] regulator: s5m8767: Disable OVCB in probe
On Wed, Nov 13, 2013 at 10:50 PM, Mark Brown broo...@kernel.org wrote: On Tue, Nov 12, 2013 at 02:41:55PM +0100, Krzysztof Kozlowski wrote: According to SW Guide the Over-Voltage Clamp may malfunction at VBatt 5.25V and 110'C temperature. This may result in overshooting or undershooting LDO's voltage outputs. Disable the Over-Voltage Clamp in probe by updating proper bit in all LDO registers. Is there no way to detect these conditions at runtime? The temperature condition in particular seems very high and hence relatively unlikely to hold most of the time, disabling the overvoltage protection all the time seems like an uncertain tradeoff. It's hard to do at runtime. right it's rare case. but some condition (as above) is meet, and no code as workaround. it's mal-function. that's the guide to avoid this mal-functions. Thank you, Kyungmin Park -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] mfd: max14577: Add max14577 MFD driver core
On Wed, Nov 13, 2013 at 10:13 PM, Mark Brown broo...@kernel.org wrote:
On Wed, Nov 13, 2013 at 08:40:54AM +0100, Krzysztof Kozlowski wrote:
+/**
+ * After resuming from suspend it may happen that IRQ is signalled but
+ * IRQ GPIO is not high. Also the interrupt registers won't have any data
+ * (all of them equal to 0x00).
+ *
+ * In such case retry few times reading the interrupt registers.
+ */
+#define IRQ_READ_REG_RETRY_CNT 5
What is the cause here? This smells like an unreliable workaround for
some other behaviour. In general this all looks very like standard
regmap code.
+ for (i = 0; i MAX14577_IRQ_REGS_NUM; i++) {
+ u8 mask_reg = max14577_mask_reg[i];
+
+ if (mask_reg == MAX14577_REG_INVALID ||
+ IS_ERR_OR_NULL(max14577-regmap))
+ continue;
Why would this code even be running if you don't have a register map?
+ dev_info(max14577-dev, Got interrupts [1:0x%02x, 2:0x%02x,
3:0x%02x]\n,
+ irq_reg[MAX14577_IRQ_INT1], irq_reg[MAX14577_IRQ_INT2],
+ irq_reg[MAX14577_IRQ_INT3]);
This is far too noisy, dev_dbg() at most.
+ gpio_val = gpio_get_value(pdata-irq_gpio);
+
+ if (gpio_get_value(pdata-irq_gpio) == 0)
+ dev_warn(max14577-dev, IRQ GPIO is not high, retry
reading interrupt registers\n);
+ } while (gpio_val == 0 --retry 0);
This looks very strange...
+ max14577-irq = gpio_to_irq(pdata-irq_gpio);
+ ret = gpio_request(pdata-irq_gpio, max14577_irq);
+ if (ret) {
+ dev_err(max14577-dev, Failed requesting GPIO %d: %d\n,
+ pdata-irq_gpio, ret);
+ goto err;
+ }
+ gpio_direction_input(pdata-irq_gpio);
+ gpio_free(pdata-irq_gpio);
This means the GPIO handling code that was present in the handling is
broken, it's trying to use the GPIO after it was freed.
+ ret = request_threaded_irq(max14577-irq, NULL, max14577_irq_thread,
+IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
+max14577-irq, max14577);
Are you *positive* this is a falling triggered IRQ? All the code to do
with spinning reading the GPIO state during handling makes it look like
this is in fact an active low interrupt and a lot of the code in here is
working around trying to handle that as the wrong kind of IRQ.
It's not work with level triggering. as wm8994, it requires edge
triggering. previous time I send RFC patch to handle edge triggering
at regmap.
+int max14577_bulk_write(struct regmap *map, u8 reg, u8 *buf, int count)
+{
+ return regmap_bulk_write(map, reg, buf, count);
+}
+EXPORT_SYMBOL_GPL(max14577_bulk_write);
Given that these are basically all trivial wrappers around regmap they
probably ought to be static inlines in the header.
+static struct max14577_platform_data *max14577_i2c_parse_dt(struct device
*dev)
+{
There's no DT binding document?
+const struct dev_pm_ops max14577_pm = {
+ .suspend = max14577_suspend,
+ .resume = max14577_resume,
+};
SET_SYSTEM_SLEEP_PM_OPS().
+static int __init max14577_i2c_init(void)
+{
+ return i2c_add_driver(max14577_i2c_driver);
+}
+subsys_initcall(max14577_i2c_init);
Why not module_i2c_driver?
there's ordering issue, it should provide regulator which is used
others before USB probe. if not, it failed to use USB.
Other PMICs use also subsys_initcall for this reason.
Thank you,
Kyungmin Park
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] video: backlight: Remove backlight sysfs uevent
From: Kyungmin Park The most mobile phones have Ambient Light Sensors and it changes brightness according lux. It means it changes backlight brightness frequently by just writing sysfs node, so it generates uevent. Usually there's no user to use this backlight changes. But it forks udev worker threads and it takes about 5ms. The main problem is that it hurts other process activities. so remove it. Kay said "Uevents are for the major, low-frequent, global device state-changes, not for carrying-out any sort of measurement data. Subsystems which need that should use other facilities like poll()-able sysfs file or any other subscription-based, client-tracking interface which does not cause overhead if it isn't used. Uevents are not the right thing to use here, and upstream udev should not paper-over broken kernel subsystems." Signed-off-by: Kyungmin Park --- v1: there's still user to use BACKLIGHT_UPDATE_SYSFS. so just remove store sysfs node uevent --- diff --git a/drivers/video/backlight/backlight.c b/drivers/video/backlight/backlight.c index 94a403a..292cf99 100644 --- a/drivers/video/backlight/backlight.c +++ b/drivers/video/backlight/backlight.c @@ -172,8 +172,6 @@ static ssize_t brightness_store(struct device *dev, } mutex_unlock(>ops_lock); - backlight_generate_event(bd, BACKLIGHT_UPDATE_SYSFS); - return rc; } static DEVICE_ATTR_RW(brightness); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] video: backlight: Remove backlight sysfs uevent
On Tue, Nov 12, 2013 at 10:19 AM, Kay Sievers wrote: > On Tue, Nov 12, 2013 at 1:56 AM, Henrique de Moraes Holschuh > wrote: >> On Tue, 12 Nov 2013, Jingoo Han wrote: >>> On Tuesday, November 12, 2013 8:57 AM, Kyungmin Park wrote: >>> > From: Kyungmin Park >>> > >>> > The most mobile phones have Ambient Light Sensors and it changes >>> > brightness according lux. >>> > It means it changes backlight brightness frequently by just writing sysfs >>> > node, so it generates uevent. >>> > >>> > Usually there's no user to use this backlight changes. But it forks udev >>> > worker threads and it takes >>> > about 5ms. The main problem is that it hurts other process activities. so >>> > remove it. >>> > >>> > Kay said >>> > "Uevents are for the major, low-frequent, global device state-changes, >>> > not for carrying-out any sort of measurement data. Subsystems which >>> > need that should use other facilities like poll()-able sysfs file or >>> > any other subscription-based, client-tracking interface which does not >>> > cause overhead if it isn't used. Uevents are not the right thing to >>> > use here, and upstream udev should not paper-over broken kernel >>> > subsystems." >> >> True. >> >> Now, let's take a look at reality: should you poll()/select() on a sysfs >> node that doesn't suport it, it will wait until the poll/select timeout >> happens (or EINTR happens), and userspace has absolutely NO way to detect >> whether a sysfs node has poll/select support. >> >> What happens if the sysfs interface did not provide poll/select support >> since day one, but rather added it later? Nobody will use it for a *long* >> time, if ever... unless you actually took pains to version the sysfs >> interface, and people actually care. > > If that's an issue, we can add a new "event" file, just for that. > >>> 'thinkpad_acpi.c' uses the 'BACKLIGHT_UPDATE_SYSFS'. >>> Henrique, can we remove it? >> >> Can't you fix this by rate-limiting, or otherwise adding an attribute that >> backlight devices should set when they need to supress change events? > > Yeah, great idea, fix a bad hack with another bad one on top. :) > Passing measurement data through uevents is just an utterly broken > idea which cannot be fixed. > >> Is there a proper on-screen-display support path for the backlight class >> nowadays? Otherwise, you'd be removing the only way userspace ever had to >> do proper OSD of backlight changes... > > OSD drawing and event sounds usually happen as a fedback for > keypresses of brightness control, it would be weird to show up when > something else, like a light-sensor, adjusts the brightness in the > background. > > Anyway, there might be the need for coordination and a new interface, > but uevents for measurement data need to die entirely; they make no > sense, never made any; and the sooner they are gone the better. Now power_supply, especially battery uses this scheme. it passes battery data using uevent. do you have any idea to kill it? Thank you, Kyungmin Park -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] video: backlight: Remove backlight sysfs uevent
On Tue, Nov 12, 2013 at 9:56 AM, Henrique de Moraes Holschuh wrote: > On Tue, 12 Nov 2013, Jingoo Han wrote: >> On Tuesday, November 12, 2013 8:57 AM, Kyungmin Park wrote: >> > From: Kyungmin Park >> > >> > The most mobile phones have Ambient Light Sensors and it changes >> > brightness according lux. >> > It means it changes backlight brightness frequently by just writing sysfs >> > node, so it generates uevent. >> > >> > Usually there's no user to use this backlight changes. But it forks udev >> > worker threads and it takes >> > about 5ms. The main problem is that it hurts other process activities. so >> > remove it. >> > >> > Kay said >> > "Uevents are for the major, low-frequent, global device state-changes, >> > not for carrying-out any sort of measurement data. Subsystems which >> > need that should use other facilities like poll()-able sysfs file or >> > any other subscription-based, client-tracking interface which does not >> > cause overhead if it isn't used. Uevents are not the right thing to >> > use here, and upstream udev should not paper-over broken kernel >> > subsystems." > > True. > > Now, let's take a look at reality: should you poll()/select() on a sysfs > node that doesn't suport it, it will wait until the poll/select timeout > happens (or EINTR happens), and userspace has absolutely NO way to detect > whether a sysfs node has poll/select support. > > What happens if the sysfs interface did not provide poll/select support > since day one, but rather added it later? Nobody will use it for a *long* > time, if ever... unless you actually took pains to version the sysfs > interface, and people actually care. > >> 'thinkpad_acpi.c' uses the 'BACKLIGHT_UPDATE_SYSFS'. >> Henrique, can we remove it? > > Can't you fix this by rate-limiting, or otherwise adding an attribute that > backlight devices should set when they need to supress change events? other way is that just remove sysfs node store update then you can use current API, force_update as is. are there any other good ideas? Thank you, Kyungmin Park > > Is there a proper on-screen-display support path for the backlight class > nowadays? Otherwise, you'd be removing the only way userspace ever had to > do proper OSD of backlight changes... > > -- > "One disk to rule them all, One disk to find them. One disk to bring > them all and in the darkness grind them. In the Land of Redmond > where the shadows lie." -- The Silicon Valley Tarot > Henrique Holschuh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] video: backlight: Remove backlight sysfs uevent
Please ignore it. strange mail system.
After feedback from previous mail, I'll re-send it.
Thank you,
Kyungmin Park
On Tue, Nov 12, 2013 at 9:44 AM, Kyungmin Park wrote:
> From: Kyungmin Park
>
> The most mobile phones have Ambient Light Sensors and it changes brightness
> according lux.
> It means it changes backlight brightness frequently by just writing sysfs
> node, so it generates uevent.
>
> Usually there's no user to use this backlight changes. But it forks udev
> worker threads and it takes about 5ms. The main problem is that it hurts
> other process activities. so remove it.
>
> Kay said
> "Uevents are for the major, low-frequent, global device state-changes,
> not for carrying-out any sort of measurement data. Subsystems which
> need that should use other facilities like poll()-able sysfs file or
> any other subscription-based, client-tracking interface which does not
> cause overhead if it isn't used. Uevents are not the right thing to
> use here, and upstream udev should not paper-over broken kernel
> subsystems."
>
> Signed-off-by: Kyungmin Park
> ---
> diff --git a/drivers/video/backlight/backlight.c
> b/drivers/video/backlight/backlight.c
> index 94a403a..441272d 100644
> --- a/drivers/video/backlight/backlight.c
> +++ b/drivers/video/backlight/backlight.c
> @@ -88,9 +88,6 @@ static void backlight_generate_event(struct
> backlight_device *bd,
> char *envp[2];
>
> switch (reason) {
> - case BACKLIGHT_UPDATE_SYSFS:
> - envp[0] = "SOURCE=sysfs";
> - break;
> case BACKLIGHT_UPDATE_HOTKEY:
> envp[0] = "SOURCE=hotkey";
> break;
> @@ -172,8 +169,6 @@ static ssize_t brightness_store(struct device *dev,
> }
> mutex_unlock(>ops_lock);
>
> - backlight_generate_event(bd, BACKLIGHT_UPDATE_SYSFS);
> -
> return rc;
> }
> static DEVICE_ATTR_RW(brightness);
> diff --git a/include/linux/backlight.h b/include/linux/backlight.h
> index 53b7794..d2a27dd 100644
> --- a/include/linux/backlight.h
> +++ b/include/linux/backlight.h
> @@ -29,7 +29,6 @@
>
> enum backlight_update_reason {
> BACKLIGHT_UPDATE_HOTKEY,
> - BACKLIGHT_UPDATE_SYSFS,
> };
>
> enum backlight_type {
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] video: backlight: Remove backlight sysfs uevent
From: Kyungmin Park
The most mobile phones have Ambient Light Sensors and it changes brightness
according lux.
It means it changes backlight brightness frequently by just writing sysfs node,
so it generates uevent.
Usually there's no user to use this backlight changes. But it forks udev worker
threads and it takes about 5ms. The main problem is that it hurts other process
activities. so remove it.
Kay said
"Uevents are for the major, low-frequent, global device state-changes,
not for carrying-out any sort of measurement data. Subsystems which
need that should use other facilities like poll()-able sysfs file or
any other subscription-based, client-tracking interface which does not
cause overhead if it isn't used. Uevents are not the right thing to
use here, and upstream udev should not paper-over broken kernel
subsystems."
Signed-off-by: Kyungmin Park
---
diff --git a/drivers/video/backlight/backlight.c
b/drivers/video/backlight/backlight.c
index 94a403a..441272d 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -88,9 +88,6 @@ static void backlight_generate_event(struct backlight_device
*bd,
char *envp[2];
switch (reason) {
- case BACKLIGHT_UPDATE_SYSFS:
- envp[0] = "SOURCE=sysfs";
- break;
case BACKLIGHT_UPDATE_HOTKEY:
envp[0] = "SOURCE=hotkey";
break;
@@ -172,8 +169,6 @@ static ssize_t brightness_store(struct device *dev,
}
mutex_unlock(>ops_lock);
- backlight_generate_event(bd, BACKLIGHT_UPDATE_SYSFS);
-
return rc;
}
static DEVICE_ATTR_RW(brightness);
diff --git a/include/linux/backlight.h b/include/linux/backlight.h
index 53b7794..d2a27dd 100644
--- a/include/linux/backlight.h
+++ b/include/linux/backlight.h
@@ -29,7 +29,6 @@
enum backlight_update_reason {
BACKLIGHT_UPDATE_HOTKEY,
- BACKLIGHT_UPDATE_SYSFS,
};
enum backlight_type {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] video: backlight: Remove backlight sysfs uevent
From: Kyungmin Park
The most mobile phones have Ambient Light Sensors and it changes brightness
according lux.
It means it changes backlight brightness frequently by just writing sysfs node,
so it generates uevent.
Usually there's no user to use this backlight changes. But it forks udev worker
threads and it takes about 5ms. The main problem is that it hurts other process
activities. so remove it.
Kay said
"Uevents are for the major, low-frequent, global device state-changes,
not for carrying-out any sort of measurement data. Subsystems which
need that should use other facilities like poll()-able sysfs file or
any other subscription-based, client-tracking interface which does not
cause overhead if it isn't used. Uevents are not the right thing to
use here, and upstream udev should not paper-over broken kernel
subsystems."
Signed-off-by: Kyungmin Park
---
diff --git a/drivers/video/backlight/backlight.c
b/drivers/video/backlight/backlight.c
index 94a403a..441272d 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -88,9 +88,6 @@ static void backlight_generate_event(struct backlight_device
*bd,
char *envp[2];
switch (reason) {
- case BACKLIGHT_UPDATE_SYSFS:
- envp[0] = "SOURCE=sysfs";
- break;
case BACKLIGHT_UPDATE_HOTKEY:
envp[0] = "SOURCE=hotkey";
break;
@@ -172,8 +169,6 @@ static ssize_t brightness_store(struct device *dev,
}
mutex_unlock(>ops_lock);
- backlight_generate_event(bd, BACKLIGHT_UPDATE_SYSFS);
-
return rc;
}
static DEVICE_ATTR_RW(brightness);
diff --git a/include/linux/backlight.h b/include/linux/backlight.h
index 53b7794..d2a27dd 100644
--- a/include/linux/backlight.h
+++ b/include/linux/backlight.h
@@ -29,7 +29,6 @@
enum backlight_update_reason {
BACKLIGHT_UPDATE_HOTKEY,
- BACKLIGHT_UPDATE_SYSFS,
};
enum backlight_type {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] video: backlight: Remove backlight sysfs uevent
From: Kyungmin Park kyungmin.p...@samsung.com
The most mobile phones have Ambient Light Sensors and it changes brightness
according lux.
It means it changes backlight brightness frequently by just writing sysfs node,
so it generates uevent.
Usually there's no user to use this backlight changes. But it forks udev worker
threads and it takes about 5ms. The main problem is that it hurts other process
activities. so remove it.
Kay said
Uevents are for the major, low-frequent, global device state-changes,
not for carrying-out any sort of measurement data. Subsystems which
need that should use other facilities like poll()-able sysfs file or
any other subscription-based, client-tracking interface which does not
cause overhead if it isn't used. Uevents are not the right thing to
use here, and upstream udev should not paper-over broken kernel
subsystems.
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
diff --git a/drivers/video/backlight/backlight.c
b/drivers/video/backlight/backlight.c
index 94a403a..441272d 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -88,9 +88,6 @@ static void backlight_generate_event(struct backlight_device
*bd,
char *envp[2];
switch (reason) {
- case BACKLIGHT_UPDATE_SYSFS:
- envp[0] = SOURCE=sysfs;
- break;
case BACKLIGHT_UPDATE_HOTKEY:
envp[0] = SOURCE=hotkey;
break;
@@ -172,8 +169,6 @@ static ssize_t brightness_store(struct device *dev,
}
mutex_unlock(bd-ops_lock);
- backlight_generate_event(bd, BACKLIGHT_UPDATE_SYSFS);
-
return rc;
}
static DEVICE_ATTR_RW(brightness);
diff --git a/include/linux/backlight.h b/include/linux/backlight.h
index 53b7794..d2a27dd 100644
--- a/include/linux/backlight.h
+++ b/include/linux/backlight.h
@@ -29,7 +29,6 @@
enum backlight_update_reason {
BACKLIGHT_UPDATE_HOTKEY,
- BACKLIGHT_UPDATE_SYSFS,
};
enum backlight_type {
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] video: backlight: Remove backlight sysfs uevent
From: Kyungmin Park kyungmin.p...@samsung.com
The most mobile phones have Ambient Light Sensors and it changes brightness
according lux.
It means it changes backlight brightness frequently by just writing sysfs node,
so it generates uevent.
Usually there's no user to use this backlight changes. But it forks udev worker
threads and it takes about 5ms. The main problem is that it hurts other process
activities. so remove it.
Kay said
Uevents are for the major, low-frequent, global device state-changes,
not for carrying-out any sort of measurement data. Subsystems which
need that should use other facilities like poll()-able sysfs file or
any other subscription-based, client-tracking interface which does not
cause overhead if it isn't used. Uevents are not the right thing to
use here, and upstream udev should not paper-over broken kernel
subsystems.
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
diff --git a/drivers/video/backlight/backlight.c
b/drivers/video/backlight/backlight.c
index 94a403a..441272d 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -88,9 +88,6 @@ static void backlight_generate_event(struct backlight_device
*bd,
char *envp[2];
switch (reason) {
- case BACKLIGHT_UPDATE_SYSFS:
- envp[0] = SOURCE=sysfs;
- break;
case BACKLIGHT_UPDATE_HOTKEY:
envp[0] = SOURCE=hotkey;
break;
@@ -172,8 +169,6 @@ static ssize_t brightness_store(struct device *dev,
}
mutex_unlock(bd-ops_lock);
- backlight_generate_event(bd, BACKLIGHT_UPDATE_SYSFS);
-
return rc;
}
static DEVICE_ATTR_RW(brightness);
diff --git a/include/linux/backlight.h b/include/linux/backlight.h
index 53b7794..d2a27dd 100644
--- a/include/linux/backlight.h
+++ b/include/linux/backlight.h
@@ -29,7 +29,6 @@
enum backlight_update_reason {
BACKLIGHT_UPDATE_HOTKEY,
- BACKLIGHT_UPDATE_SYSFS,
};
enum backlight_type {
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] video: backlight: Remove backlight sysfs uevent
Please ignore it. strange mail system.
After feedback from previous mail, I'll re-send it.
Thank you,
Kyungmin Park
On Tue, Nov 12, 2013 at 9:44 AM, Kyungmin Park kmp...@infradead.org wrote:
From: Kyungmin Park kyungmin.p...@samsung.com
The most mobile phones have Ambient Light Sensors and it changes brightness
according lux.
It means it changes backlight brightness frequently by just writing sysfs
node, so it generates uevent.
Usually there's no user to use this backlight changes. But it forks udev
worker threads and it takes about 5ms. The main problem is that it hurts
other process activities. so remove it.
Kay said
Uevents are for the major, low-frequent, global device state-changes,
not for carrying-out any sort of measurement data. Subsystems which
need that should use other facilities like poll()-able sysfs file or
any other subscription-based, client-tracking interface which does not
cause overhead if it isn't used. Uevents are not the right thing to
use here, and upstream udev should not paper-over broken kernel
subsystems.
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
diff --git a/drivers/video/backlight/backlight.c
b/drivers/video/backlight/backlight.c
index 94a403a..441272d 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -88,9 +88,6 @@ static void backlight_generate_event(struct
backlight_device *bd,
char *envp[2];
switch (reason) {
- case BACKLIGHT_UPDATE_SYSFS:
- envp[0] = SOURCE=sysfs;
- break;
case BACKLIGHT_UPDATE_HOTKEY:
envp[0] = SOURCE=hotkey;
break;
@@ -172,8 +169,6 @@ static ssize_t brightness_store(struct device *dev,
}
mutex_unlock(bd-ops_lock);
- backlight_generate_event(bd, BACKLIGHT_UPDATE_SYSFS);
-
return rc;
}
static DEVICE_ATTR_RW(brightness);
diff --git a/include/linux/backlight.h b/include/linux/backlight.h
index 53b7794..d2a27dd 100644
--- a/include/linux/backlight.h
+++ b/include/linux/backlight.h
@@ -29,7 +29,6 @@
enum backlight_update_reason {
BACKLIGHT_UPDATE_HOTKEY,
- BACKLIGHT_UPDATE_SYSFS,
};
enum backlight_type {
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] video: backlight: Remove backlight sysfs uevent
On Tue, Nov 12, 2013 at 9:56 AM, Henrique de Moraes Holschuh h...@hmh.eng.br wrote: On Tue, 12 Nov 2013, Jingoo Han wrote: On Tuesday, November 12, 2013 8:57 AM, Kyungmin Park wrote: From: Kyungmin Park kyungmin.p...@samsung.com The most mobile phones have Ambient Light Sensors and it changes brightness according lux. It means it changes backlight brightness frequently by just writing sysfs node, so it generates uevent. Usually there's no user to use this backlight changes. But it forks udev worker threads and it takes about 5ms. The main problem is that it hurts other process activities. so remove it. Kay said Uevents are for the major, low-frequent, global device state-changes, not for carrying-out any sort of measurement data. Subsystems which need that should use other facilities like poll()-able sysfs file or any other subscription-based, client-tracking interface which does not cause overhead if it isn't used. Uevents are not the right thing to use here, and upstream udev should not paper-over broken kernel subsystems. True. Now, let's take a look at reality: should you poll()/select() on a sysfs node that doesn't suport it, it will wait until the poll/select timeout happens (or EINTR happens), and userspace has absolutely NO way to detect whether a sysfs node has poll/select support. What happens if the sysfs interface did not provide poll/select support since day one, but rather added it later? Nobody will use it for a *long* time, if ever... unless you actually took pains to version the sysfs interface, and people actually care. 'thinkpad_acpi.c' uses the 'BACKLIGHT_UPDATE_SYSFS'. Henrique, can we remove it? Can't you fix this by rate-limiting, or otherwise adding an attribute that backlight devices should set when they need to supress change events? other way is that just remove sysfs node store update then you can use current API, force_update as is. are there any other good ideas? Thank you, Kyungmin Park Is there a proper on-screen-display support path for the backlight class nowadays? Otherwise, you'd be removing the only way userspace ever had to do proper OSD of backlight changes... -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] video: backlight: Remove backlight sysfs uevent
On Tue, Nov 12, 2013 at 10:19 AM, Kay Sievers k...@vrfy.org wrote: On Tue, Nov 12, 2013 at 1:56 AM, Henrique de Moraes Holschuh h...@hmh.eng.br wrote: On Tue, 12 Nov 2013, Jingoo Han wrote: On Tuesday, November 12, 2013 8:57 AM, Kyungmin Park wrote: From: Kyungmin Park kyungmin.p...@samsung.com The most mobile phones have Ambient Light Sensors and it changes brightness according lux. It means it changes backlight brightness frequently by just writing sysfs node, so it generates uevent. Usually there's no user to use this backlight changes. But it forks udev worker threads and it takes about 5ms. The main problem is that it hurts other process activities. so remove it. Kay said Uevents are for the major, low-frequent, global device state-changes, not for carrying-out any sort of measurement data. Subsystems which need that should use other facilities like poll()-able sysfs file or any other subscription-based, client-tracking interface which does not cause overhead if it isn't used. Uevents are not the right thing to use here, and upstream udev should not paper-over broken kernel subsystems. True. Now, let's take a look at reality: should you poll()/select() on a sysfs node that doesn't suport it, it will wait until the poll/select timeout happens (or EINTR happens), and userspace has absolutely NO way to detect whether a sysfs node has poll/select support. What happens if the sysfs interface did not provide poll/select support since day one, but rather added it later? Nobody will use it for a *long* time, if ever... unless you actually took pains to version the sysfs interface, and people actually care. If that's an issue, we can add a new event file, just for that. 'thinkpad_acpi.c' uses the 'BACKLIGHT_UPDATE_SYSFS'. Henrique, can we remove it? Can't you fix this by rate-limiting, or otherwise adding an attribute that backlight devices should set when they need to supress change events? Yeah, great idea, fix a bad hack with another bad one on top. :) Passing measurement data through uevents is just an utterly broken idea which cannot be fixed. Is there a proper on-screen-display support path for the backlight class nowadays? Otherwise, you'd be removing the only way userspace ever had to do proper OSD of backlight changes... OSD drawing and event sounds usually happen as a fedback for keypresses of brightness control, it would be weird to show up when something else, like a light-sensor, adjusts the brightness in the background. Anyway, there might be the need for coordination and a new interface, but uevents for measurement data need to die entirely; they make no sense, never made any; and the sooner they are gone the better. Now power_supply, especially battery uses this scheme. it passes battery data using uevent. do you have any idea to kill it? Thank you, Kyungmin Park -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] video: backlight: Remove backlight sysfs uevent
From: Kyungmin Park kyungmin.p...@samsung.com The most mobile phones have Ambient Light Sensors and it changes brightness according lux. It means it changes backlight brightness frequently by just writing sysfs node, so it generates uevent. Usually there's no user to use this backlight changes. But it forks udev worker threads and it takes about 5ms. The main problem is that it hurts other process activities. so remove it. Kay said Uevents are for the major, low-frequent, global device state-changes, not for carrying-out any sort of measurement data. Subsystems which need that should use other facilities like poll()-able sysfs file or any other subscription-based, client-tracking interface which does not cause overhead if it isn't used. Uevents are not the right thing to use here, and upstream udev should not paper-over broken kernel subsystems. Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- v1: there's still user to use BACKLIGHT_UPDATE_SYSFS. so just remove store sysfs node uevent --- diff --git a/drivers/video/backlight/backlight.c b/drivers/video/backlight/backlight.c index 94a403a..292cf99 100644 --- a/drivers/video/backlight/backlight.c +++ b/drivers/video/backlight/backlight.c @@ -172,8 +172,6 @@ static ssize_t brightness_store(struct device *dev, } mutex_unlock(bd-ops_lock); - backlight_generate_event(bd, BACKLIGHT_UPDATE_SYSFS); - return rc; } static DEVICE_ATTR_RW(brightness); -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] mfd: sec-core: Add cells for S5M8767-clocks
On Tue, Nov 5, 2013 at 5:04 PM, Tushar Behera wrote:
> On 5 November 2013 13:27, Kyungmin Park wrote:
>> On Tue, Nov 5, 2013 at 3:29 PM, Tushar Behera
>> wrote:
>>> On 31 October 2013 21:46, Lee Jones wrote:
>>>> On Thu, 31 Oct 2013, Tushar Behera wrote:
>>>>
>>>>> S5M8767 chip has 3 crystal oscillators running at 32KHz. These are
>>>>> supported by s2mps11-clk driver.
>>>>>
>>>>> Signed-off-by: Tushar Behera
>>>>> CC: Lee Jones
>>>>> ---
>>>>> drivers/mfd/sec-core.c |4 +++-
>>>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/mfd/sec-core.c b/drivers/mfd/sec-core.c
>>>>> index 34c18fb..020b86b 100644
>>>>> --- a/drivers/mfd/sec-core.c
>>>>> +++ b/drivers/mfd/sec-core.c
>>>>> @@ -56,7 +56,9 @@ static struct mfd_cell s5m8767_devs[] = {
>>>>> .name = "s5m8767-pmic",
>>>>> }, {
>>>>> .name = "s5m-rtc",
>>>>> - },
>>>>> + }, {
>>>>> + .name = "s5m8767-clk",
>>
>> Do you want to handle these as "clock"? previous time, it's
>> implemented at regulator. please see drivers/regulator/max* series.
>>
>> Thank you,
>> Kyungmin Park
>
> There is already a clock-implementation available for this kind of
> device (through clk-s2mps11). I would like to extend that support.
> Also for MAX77686, it is implemented through clock subsystem.
>
Yes it's possible, but losts of MAX chips are implemented already with
regulator.
but in case of maxim chip. it's voltage instead of clock. doesn't
better to use regulaor?
Ah I confused between 32KHz and Safeout. okay it's 32KHz clock. okay
it's better to use clock.
Ignore previous comments.
Thank you,
Kyungmin Park
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] mfd: sec-core: Add cells for S5M8767-clocks
On Tue, Nov 5, 2013 at 5:04 PM, Tushar Behera tushar.beh...@linaro.org wrote:
On 5 November 2013 13:27, Kyungmin Park kmp...@infradead.org wrote:
On Tue, Nov 5, 2013 at 3:29 PM, Tushar Behera tushar.beh...@linaro.org
wrote:
On 31 October 2013 21:46, Lee Jones lee.jo...@linaro.org wrote:
On Thu, 31 Oct 2013, Tushar Behera wrote:
S5M8767 chip has 3 crystal oscillators running at 32KHz. These are
supported by s2mps11-clk driver.
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
CC: Lee Jones lee.jo...@linaro.org
---
drivers/mfd/sec-core.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/mfd/sec-core.c b/drivers/mfd/sec-core.c
index 34c18fb..020b86b 100644
--- a/drivers/mfd/sec-core.c
+++ b/drivers/mfd/sec-core.c
@@ -56,7 +56,9 @@ static struct mfd_cell s5m8767_devs[] = {
.name = s5m8767-pmic,
}, {
.name = s5m-rtc,
- },
+ }, {
+ .name = s5m8767-clk,
Do you want to handle these as clock? previous time, it's
implemented at regulator. please see drivers/regulator/max* series.
Thank you,
Kyungmin Park
There is already a clock-implementation available for this kind of
device (through clk-s2mps11). I would like to extend that support.
Also for MAX77686, it is implemented through clock subsystem.
Yes it's possible, but losts of MAX chips are implemented already with
regulator.
but in case of maxim chip. it's voltage instead of clock. doesn't
better to use regulaor?
Ah I confused between 32KHz and Safeout. okay it's 32KHz clock. okay
it's better to use clock.
Ignore previous comments.
Thank you,
Kyungmin Park
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] mfd: sec-core: Add cells for S5M8767-clocks
On Tue, Nov 5, 2013 at 3:29 PM, Tushar Behera wrote:
> On 31 October 2013 21:46, Lee Jones wrote:
>> On Thu, 31 Oct 2013, Tushar Behera wrote:
>>
>>> S5M8767 chip has 3 crystal oscillators running at 32KHz. These are
>>> supported by s2mps11-clk driver.
>>>
>>> Signed-off-by: Tushar Behera
>>> CC: Lee Jones
>>> ---
>>> drivers/mfd/sec-core.c |4 +++-
>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/mfd/sec-core.c b/drivers/mfd/sec-core.c
>>> index 34c18fb..020b86b 100644
>>> --- a/drivers/mfd/sec-core.c
>>> +++ b/drivers/mfd/sec-core.c
>>> @@ -56,7 +56,9 @@ static struct mfd_cell s5m8767_devs[] = {
>>> .name = "s5m8767-pmic",
>>> }, {
>>> .name = "s5m-rtc",
>>> - },
>>> + }, {
>>> + .name = "s5m8767-clk",
Do you want to handle these as "clock"? previous time, it's
implemented at regulator. please see drivers/regulator/max* series.
Thank you,
Kyungmin Park
>>> + }
>>> };
>>>
>>> static struct mfd_cell s2mps11_devs[] = {
>>
>> Acked-by: Lee Jones
>>
>
> Thanks.
>
>> I'd prefer to take this patch in via the MFD tree once you have
>> support from the other maintainers for the set.
>>
>
> Ok. I will let you know once I get the clock patches through.
>
> --
> Tushar Behera
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] mfd: sec-core: Add cells for S5M8767-clocks
On Tue, Nov 5, 2013 at 3:29 PM, Tushar Behera tushar.beh...@linaro.org wrote:
On 31 October 2013 21:46, Lee Jones lee.jo...@linaro.org wrote:
On Thu, 31 Oct 2013, Tushar Behera wrote:
S5M8767 chip has 3 crystal oscillators running at 32KHz. These are
supported by s2mps11-clk driver.
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
CC: Lee Jones lee.jo...@linaro.org
---
drivers/mfd/sec-core.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/mfd/sec-core.c b/drivers/mfd/sec-core.c
index 34c18fb..020b86b 100644
--- a/drivers/mfd/sec-core.c
+++ b/drivers/mfd/sec-core.c
@@ -56,7 +56,9 @@ static struct mfd_cell s5m8767_devs[] = {
.name = s5m8767-pmic,
}, {
.name = s5m-rtc,
- },
+ }, {
+ .name = s5m8767-clk,
Do you want to handle these as clock? previous time, it's
implemented at regulator. please see drivers/regulator/max* series.
Thank you,
Kyungmin Park
+ }
};
static struct mfd_cell s2mps11_devs[] = {
Acked-by: Lee Jones lee.jo...@linaro.org
Thanks.
I'd prefer to take this patch in via the MFD tree once you have
support from the other maintainers for the set.
Ok. I will let you know once I get the clock patches through.
--
Tushar Behera
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] i2c: s3c2410: dont need CPU_FREQ transitions for exynos series
On Tue, Oct 15, 2013 at 3:23 PM, Naveen Krishna Chatradhi
wrote:
> For Exynos4 and Exynos5 SoCs from Samsung the i2c clock is based
> on a fixed 66 MHz peripheral clock, and therefore is completely
> independent of the cpu frequency.
> Thus, registering for a CPU freq notifier is very wasteful.
>
> This patch modifes the code such that, i2c bus registers to
> cpu_freq_transition only if CONFIG_CPU_FREQ_S3C24XX is enabled.
>
> This change should save a bunch of cpufreq transitions calls
> which does not apply to exynos SoCs.
>
> Signed-off-by: Naveen Krishna Chatradhi
Acked-by: Kyungmin Park
> ---
> Changes since v1:
> Use CONFIG_CPU_FREQ_S3C24XX instead of (CONFIG_CPU_FREQ & !CONFIG_EXYNOS)
> As commented by Tomasz
>
> drivers/i2c/busses/i2c-s3c2410.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-s3c2410.c
> b/drivers/i2c/busses/i2c-s3c2410.c
> index cab1c91..97f14f7 100644
> --- a/drivers/i2c/busses/i2c-s3c2410.c
> +++ b/drivers/i2c/busses/i2c-s3c2410.c
> @@ -123,7 +123,7 @@ struct s3c24xx_i2c {
> struct s3c2410_platform_i2c *pdata;
> int gpios[2];
> struct pinctrl *pctrl;
> -#ifdef CONFIG_CPU_FREQ
> +#if defined(CONFIG_CPU_FREQ_S3C24XX)
> struct notifier_block freq_transition;
> #endif
> };
> @@ -843,7 +843,7 @@ static int s3c24xx_i2c_clockrate(struct s3c24xx_i2c *i2c,
> unsigned int *got)
> return 0;
> }
>
> -#ifdef CONFIG_CPU_FREQ
> +#if defined(CONFIG_CPU_FREQ_S3C24XX)
>
> #define freq_to_i2c(_n) container_of(_n, struct s3c24xx_i2c, freq_transition)
>
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] i2c: s3c2410: dont need CPU_FREQ transitions for exynos series
On Tue, Oct 15, 2013 at 3:23 PM, Naveen Krishna Chatradhi
ch.nav...@samsung.com wrote:
For Exynos4 and Exynos5 SoCs from Samsung the i2c clock is based
on a fixed 66 MHz peripheral clock, and therefore is completely
independent of the cpu frequency.
Thus, registering for a CPU freq notifier is very wasteful.
This patch modifes the code such that, i2c bus registers to
cpu_freq_transition only if CONFIG_CPU_FREQ_S3C24XX is enabled.
This change should save a bunch of cpufreq transitions calls
which does not apply to exynos SoCs.
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
Changes since v1:
Use CONFIG_CPU_FREQ_S3C24XX instead of (CONFIG_CPU_FREQ !CONFIG_EXYNOS)
As commented by Tomasz
drivers/i2c/busses/i2c-s3c2410.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-s3c2410.c
b/drivers/i2c/busses/i2c-s3c2410.c
index cab1c91..97f14f7 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
@@ -123,7 +123,7 @@ struct s3c24xx_i2c {
struct s3c2410_platform_i2c *pdata;
int gpios[2];
struct pinctrl *pctrl;
-#ifdef CONFIG_CPU_FREQ
+#if defined(CONFIG_CPU_FREQ_S3C24XX)
struct notifier_block freq_transition;
#endif
};
@@ -843,7 +843,7 @@ static int s3c24xx_i2c_clockrate(struct s3c24xx_i2c *i2c,
unsigned int *got)
return 0;
}
-#ifdef CONFIG_CPU_FREQ
+#if defined(CONFIG_CPU_FREQ_S3C24XX)
#define freq_to_i2c(_n) container_of(_n, struct s3c24xx_i2c, freq_transition)
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] freezer: allow killing of frozen tasks
On Tue, Aug 20, 2013 at 9:41 PM, Rafael J. Wysocki wrote: > On Tuesday, August 20, 2013 08:27:27 AM Tejun Heo wrote: >> On Tue, Aug 20, 2013 at 02:34:14PM +0200, Rafael J. Wysocki wrote: >> > On Tuesday, August 20, 2013 08:22:00 AM Tejun Heo wrote: >> > > On Tue, Aug 20, 2013 at 02:30:18PM +0200, Rafael J. Wysocki wrote: >> > > > > So, I don't think we can simply turn TASK_UNITERRUPTIBLE to >> > > > > TASK_KILLABLE at this point. We really need to strictly define where >> > > > > a task can freeze before being able to do anything like this. >> > > > >> > > > But we could do that for user space tasks I suppose? >> > > >> > > Even for userland tasks, we don't know where the task is stuck at. I >> > > think there are enough freeze points in the kernel which are in the >> > > middle of something which can be used by userland tasks excuting some >> > > syscall. We need to collect all those sites into well defined trap >> > > points before doing this. >> > >> > OK, thanks! >> >> I scanned through try_to_freeze() users and it seems like we don't >> have that many which can be hit by userland tasks. I think it should >> be doable to audit all the users, remove the ones which can be invoked >> by userland and make try_to_freeze() whine loudly if it's running off >> a userland task except from well-defined spots. > > Which might be worth doing anyway to be sure we know what's going on. > >> Anyways, we need to ensure that userland task doesn't get stuck deep in the >> kernel before allowing this. > > Agreed. Are there any update? we need this feature to kill frozen app easily. Don't need to thaw app to kill. Thank you, Kyungmin Park -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] freezer: allow killing of frozen tasks
On Tue, Aug 20, 2013 at 9:41 PM, Rafael J. Wysocki r...@sisk.pl wrote: On Tuesday, August 20, 2013 08:27:27 AM Tejun Heo wrote: On Tue, Aug 20, 2013 at 02:34:14PM +0200, Rafael J. Wysocki wrote: On Tuesday, August 20, 2013 08:22:00 AM Tejun Heo wrote: On Tue, Aug 20, 2013 at 02:30:18PM +0200, Rafael J. Wysocki wrote: So, I don't think we can simply turn TASK_UNITERRUPTIBLE to TASK_KILLABLE at this point. We really need to strictly define where a task can freeze before being able to do anything like this. But we could do that for user space tasks I suppose? Even for userland tasks, we don't know where the task is stuck at. I think there are enough freeze points in the kernel which are in the middle of something which can be used by userland tasks excuting some syscall. We need to collect all those sites into well defined trap points before doing this. OK, thanks! I scanned through try_to_freeze() users and it seems like we don't have that many which can be hit by userland tasks. I think it should be doable to audit all the users, remove the ones which can be invoked by userland and make try_to_freeze() whine loudly if it's running off a userland task except from well-defined spots. Which might be worth doing anyway to be sure we know what's going on. Anyways, we need to ensure that userland task doesn't get stuck deep in the kernel before allowing this. Agreed. Are there any update? we need this feature to kill frozen app easily. Don't need to thaw app to kill. Thank you, Kyungmin Park -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Smack: IPv6 casting error fix
On Thu, Jul 25, 2013 at 9:49 AM, Casey Schaufler wrote:
> Subject: [PATCH] Smack: IPv6 casting error fix
>
> The original implementation of the Smack IPv6 port based
> local controls works most of the time using a sockaddr as
> a temporary variable, but not always as it overflows in
> some circumstances. The correct data is a sockaddr_in6.
> A struct sockaddr isn't as large as a struct sockaddr_in6.
> There would need to be casting one way or the other. This
> patch gets it the right way.
>
> This problem required some effort to make occur in development
> with 3.10, but hits every time in 3.11. This patch should go
> into 3.11.
>
> Signed-off-by: Casey Schaufler
>
> ---
> security/smack/smack_lsm.c | 24 +++-
> 1 files changed, 11 insertions(+), 13 deletions(-)
>
> diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
> index 3f7682a..eefbd10 100644
> --- a/security/smack/smack_lsm.c
> +++ b/security/smack/smack_lsm.c
> @@ -1998,12 +1998,11 @@ static void smk_ipv6_port_label(struct socket *sock,
> struct sockaddr *address)
> *
> * Create or update the port list entry
> */
> -static int smk_ipv6_port_check(struct sock *sk, struct sockaddr *address,
> +static int smk_ipv6_port_check(struct sock *sk, struct sockaddr_in6 *address,
> int act)
> {
> __be16 *bep;
> __be32 *be32p;
> - struct sockaddr_in6 *addr6;
> struct smk_port_label *spp;
> struct socket_smack *ssp = sk->sk_security;
> struct smack_known *skp;
> @@ -2025,10 +2024,9 @@ static int smk_ipv6_port_check(struct sock *sk, struct
> sockaddr *address,
> /*
> * Get the IP address and port from the address.
> */
> - addr6 = (struct sockaddr_in6 *)address;
> - port = ntohs(addr6->sin6_port);
> - bep = (__be16 *)(>sin6_addr);
> - be32p = (__be32 *)(>sin6_addr);
> + port = ntohs(address->sin6_port);
> + bep = (__be16 *)(>sin6_addr);
> + be32p = (__be32 *)(>sin6_addr);
>
> /*
> * It's remote, so port lookup does no good.
> @@ -2060,9 +2058,9 @@ auditout:
> ad.a.u.net->family = sk->sk_family;
> ad.a.u.net->dport = port;
> if (act == SMK_RECEIVING)
> - ad.a.u.net->v6info.saddr = addr6->sin6_addr;
> + ad.a.u.net->v6info.saddr = address->sin6_addr;
> else
> - ad.a.u.net->v6info.daddr = addr6->sin6_addr;
> + ad.a.u.net->v6info.daddr = address->sin6_addr;
> #endif
> return smk_access(skp, object, MAY_WRITE, );
> }
> @@ -2201,7 +2199,8 @@ static int smack_socket_connect(struct socket *sock,
> struct sockaddr *sap,
> case PF_INET6:
> if (addrlen < sizeof(struct sockaddr_in6))
> return -EINVAL;
> - rc = smk_ipv6_port_check(sock->sk, sap, SMK_CONNECTING);
> + rc = smk_ipv6_port_check(sock->sk, (struct sockaddr_in6 *)sap,
I reviewed ipv4 and ipv6 codes at smack. the variable 'sap' is used
for both 'struct sockaddr' and 'struct sockaddr_in6'.
It's very confusing to know what's the exact usage. so I suggest to
use separate variable for each cases.
as you know, the sizeof(struct sockaddr_in6) is bigger than
sizeof(struct sockaddr). now it valid cast it as above.
but other case it corrupts the stack.
> + SMK_CONNECTING);
> break;
> }
> return rc;
> @@ -3034,7 +3033,7 @@ static int smack_socket_sendmsg(struct socket *sock,
> struct msghdr *msg,
> int size)
> {
> struct sockaddr_in *sip = (struct sockaddr_in *) msg->msg_name;
> - struct sockaddr *sap = (struct sockaddr *) msg->msg_name;
> + struct sockaddr_in6 *sap = (struct sockaddr_in6 *) msg->msg_name;
sap is used for struct sockaddr_in6.
> int rc = 0;
>
> /*
> @@ -3121,9 +3120,8 @@ static struct smack_known *smack_from_secattr(struct
> netlbl_lsm_secattr *sap,
> return smack_net_ambient;
> }
>
> -static int smk_skb_to_addr_ipv6(struct sk_buff *skb, struct sockaddr *sap)
> +static int smk_skb_to_addr_ipv6(struct sk_buff *skb, struct sockaddr_in6
> *sip)
'sip' is used for struct sockaddr_in6.
> {
> - struct sockaddr_in6 *sip = (struct sockaddr_in6 *)sap;
> u8 nexthdr;
> int offset;
> int proto = -EINVAL;
> @@ -3181,7 +3179,7 @@ static int smack_socket_sock_rcv_skb(struct sock *sk,
> struct sk_buff *skb)
> struct netlbl_lsm_secattr secattr;
> struc
Re: [PATCH] Smack: IPv6 casting error fix
On Thu, Jul 25, 2013 at 9:49 AM, Casey Schaufler ca...@schaufler-ca.com wrote:
Subject: [PATCH] Smack: IPv6 casting error fix
The original implementation of the Smack IPv6 port based
local controls works most of the time using a sockaddr as
a temporary variable, but not always as it overflows in
some circumstances. The correct data is a sockaddr_in6.
A struct sockaddr isn't as large as a struct sockaddr_in6.
There would need to be casting one way or the other. This
patch gets it the right way.
This problem required some effort to make occur in development
with 3.10, but hits every time in 3.11. This patch should go
into 3.11.
Signed-off-by: Casey Schaufler ca...@schaufler-ca.com
---
security/smack/smack_lsm.c | 24 +++-
1 files changed, 11 insertions(+), 13 deletions(-)
diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
index 3f7682a..eefbd10 100644
--- a/security/smack/smack_lsm.c
+++ b/security/smack/smack_lsm.c
@@ -1998,12 +1998,11 @@ static void smk_ipv6_port_label(struct socket *sock,
struct sockaddr *address)
*
* Create or update the port list entry
*/
-static int smk_ipv6_port_check(struct sock *sk, struct sockaddr *address,
+static int smk_ipv6_port_check(struct sock *sk, struct sockaddr_in6 *address,
int act)
{
__be16 *bep;
__be32 *be32p;
- struct sockaddr_in6 *addr6;
struct smk_port_label *spp;
struct socket_smack *ssp = sk-sk_security;
struct smack_known *skp;
@@ -2025,10 +2024,9 @@ static int smk_ipv6_port_check(struct sock *sk, struct
sockaddr *address,
/*
* Get the IP address and port from the address.
*/
- addr6 = (struct sockaddr_in6 *)address;
- port = ntohs(addr6-sin6_port);
- bep = (__be16 *)(addr6-sin6_addr);
- be32p = (__be32 *)(addr6-sin6_addr);
+ port = ntohs(address-sin6_port);
+ bep = (__be16 *)(address-sin6_addr);
+ be32p = (__be32 *)(address-sin6_addr);
/*
* It's remote, so port lookup does no good.
@@ -2060,9 +2058,9 @@ auditout:
ad.a.u.net-family = sk-sk_family;
ad.a.u.net-dport = port;
if (act == SMK_RECEIVING)
- ad.a.u.net-v6info.saddr = addr6-sin6_addr;
+ ad.a.u.net-v6info.saddr = address-sin6_addr;
else
- ad.a.u.net-v6info.daddr = addr6-sin6_addr;
+ ad.a.u.net-v6info.daddr = address-sin6_addr;
#endif
return smk_access(skp, object, MAY_WRITE, ad);
}
@@ -2201,7 +2199,8 @@ static int smack_socket_connect(struct socket *sock,
struct sockaddr *sap,
case PF_INET6:
if (addrlen sizeof(struct sockaddr_in6))
return -EINVAL;
- rc = smk_ipv6_port_check(sock-sk, sap, SMK_CONNECTING);
+ rc = smk_ipv6_port_check(sock-sk, (struct sockaddr_in6 *)sap,
I reviewed ipv4 and ipv6 codes at smack. the variable 'sap' is used
for both 'struct sockaddr' and 'struct sockaddr_in6'.
It's very confusing to know what's the exact usage. so I suggest to
use separate variable for each cases.
as you know, the sizeof(struct sockaddr_in6) is bigger than
sizeof(struct sockaddr). now it valid cast it as above.
but other case it corrupts the stack.
+ SMK_CONNECTING);
break;
}
return rc;
@@ -3034,7 +3033,7 @@ static int smack_socket_sendmsg(struct socket *sock,
struct msghdr *msg,
int size)
{
struct sockaddr_in *sip = (struct sockaddr_in *) msg-msg_name;
- struct sockaddr *sap = (struct sockaddr *) msg-msg_name;
+ struct sockaddr_in6 *sap = (struct sockaddr_in6 *) msg-msg_name;
sap is used for struct sockaddr_in6.
int rc = 0;
/*
@@ -3121,9 +3120,8 @@ static struct smack_known *smack_from_secattr(struct
netlbl_lsm_secattr *sap,
return smack_net_ambient;
}
-static int smk_skb_to_addr_ipv6(struct sk_buff *skb, struct sockaddr *sap)
+static int smk_skb_to_addr_ipv6(struct sk_buff *skb, struct sockaddr_in6
*sip)
'sip' is used for struct sockaddr_in6.
{
- struct sockaddr_in6 *sip = (struct sockaddr_in6 *)sap;
u8 nexthdr;
int offset;
int proto = -EINVAL;
@@ -3181,7 +3179,7 @@ static int smack_socket_sock_rcv_skb(struct sock *sk,
struct sk_buff *skb)
struct netlbl_lsm_secattr secattr;
struct socket_smack *ssp = sk-sk_security;
struct smack_known *skp;
- struct sockaddr sadd;
+ struct sockaddr_in6 sadd;
'sadd' is used for struct sockaddr_in6.
Thank you,
Kyungmin Park
int rc = 0;
struct smk_audit_info ad;
#ifdef CONFIG_AUDIT
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
Re: [PATCH 01/18] MAINTAINERS: EXYNOS - Remove board files
On Mon, Jul 22, 2013 at 9:15 AM, Joe Perches wrote:
> ommit ca9143501c30 ("ARM: EXYNOS: Remove unused board files")
> removed the files, remove the patterns too.
>
> Signed-off-by: Joe Perches
> cc: Tomasz Figa
> cc: Kyungmin Park
Acked-by: Kyungmin Park
> cc: Kukjin Kim
> ---
> MAINTAINERS | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index bf61e04..2124104 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1154,8 +1154,6 @@ L:linux-arm-ker...@lists.infradead.org
> (moderated for non-subscribers)
> S: Maintained
> F: arch/arm/mach-s5pv210/mach-aquila.c
> F: arch/arm/mach-s5pv210/mach-goni.c
> -F: arch/arm/mach-exynos/mach-universal_c210.c
> -F: arch/arm/mach-exynos/mach-nuri.c
>
> ARM/SAMSUNG S5P SERIES 2D GRAPHICS ACCELERATION (G2D) SUPPORT
> M: Kyungmin Park
> --
> 1.8.1.2.459.gbcd45b4.dirty
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/18] MAINTAINERS: EXYNOS - Remove board files
On Mon, Jul 22, 2013 at 9:15 AM, Joe Perches j...@perches.com wrote: ommit ca9143501c30 (ARM: EXYNOS: Remove unused board files) removed the files, remove the patterns too. Signed-off-by: Joe Perches j...@perches.com cc: Tomasz Figa t.f...@samsung.com cc: Kyungmin Park kyungmin.p...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com cc: Kukjin Kim kgene@samsung.com --- MAINTAINERS | 2 -- 1 file changed, 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index bf61e04..2124104 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1154,8 +1154,6 @@ L:linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) S: Maintained F: arch/arm/mach-s5pv210/mach-aquila.c F: arch/arm/mach-s5pv210/mach-goni.c -F: arch/arm/mach-exynos/mach-universal_c210.c -F: arch/arm/mach-exynos/mach-nuri.c ARM/SAMSUNG S5P SERIES 2D GRAPHICS ACCELERATION (G2D) SUPPORT M: Kyungmin Park kyungmin.p...@samsung.com -- 1.8.1.2.459.gbcd45b4.dirty -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 3/3] Update current cpu power when cpu freq change for exynos.
+ cpufreq maintainers
On Fri, Jul 5, 2013 at 12:17 AM, Konstantin Krivyakin
wrote:
> Signed-off-by: Konstantin Krivyakin
> ---
> drivers/cpufreq/exynos-cpufreq.c |2 ++
> drivers/cpufreq/exynos-cpufreq.h |1 +
> drivers/cpufreq/exynos4x12-cpufreq.c | 19 ++-
> 3 files changed, 21 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/cpufreq/exynos-cpufreq.c
> b/drivers/cpufreq/exynos-cpufreq.c
> index 0d32f02..02f17bc 100644
> --- a/drivers/cpufreq/exynos-cpufreq.c
> +++ b/drivers/cpufreq/exynos-cpufreq.c
> @@ -178,6 +178,8 @@ static int exynos_target(struct cpufreq_policy *policy,
> }
>
> new_freq = freq_table[index].frequency;
> + if (exynos_info->power_table)
> + policy->current_power = exynos_info->power_table[index];
>
> ret = exynos_cpufreq_scale(new_freq);
>
> diff --git a/drivers/cpufreq/exynos-cpufreq.h
> b/drivers/cpufreq/exynos-cpufreq.h
> index 92b852e..64f964f 100644
> --- a/drivers/cpufreq/exynos-cpufreq.h
> +++ b/drivers/cpufreq/exynos-cpufreq.h
> @@ -38,6 +38,7 @@ struct exynos_dvfs_info {
> unsigned intpll_safe_idx;
> struct clk *cpu_clk;
> unsigned int*volt_table;
> + u64 *power_table;
> struct cpufreq_frequency_table *freq_table;
> void (*set_freq)(unsigned int, unsigned int);
> bool (*need_apll_change)(unsigned int, unsigned int);
> diff --git a/drivers/cpufreq/exynos4x12-cpufreq.c
> b/drivers/cpufreq/exynos4x12-cpufreq.c
> index 08b7477..8905f9b 100644
> --- a/drivers/cpufreq/exynos4x12-cpufreq.c
> +++ b/drivers/cpufreq/exynos4x12-cpufreq.c
> @@ -219,6 +219,7 @@ static void exynos4x12_set_frequency(unsigned int
> old_index,
> int exynos4x12_cpufreq_init(struct exynos_dvfs_info *info)
> {
> unsigned long rate;
> + int freq_count;
>
> cpu_clk = clk_get(NULL, "armclk");
> if (IS_ERR(cpu_clk))
> @@ -252,8 +253,24 @@ int exynos4x12_cpufreq_init(struct exynos_dvfs_info
> *info)
> info->set_freq = exynos4x12_set_frequency;
> info->need_apll_change = exynos4x12_pms_change;
>
> - return 0;
> + freq_count = sizeof(exynos4x12_freq_table) /
> + sizeof(struct cpufreq_frequency_table);
> + info->power_table = kzalloc(sizeof(u64) * freq_count, GFP_KERNEL);
> + if (!info->power_table)
> + goto err_power_table;
> +
> + for (i = 0; i <= freq_count; ++i) {
> + u64 freq = info->freq_table[i].frequency;
> + u64 volt = info->volt_table[i];
>
> + do_div(freq, 1000);
> + do_div(volt, 1000);
> + info->power_table[i] = freq * volt * volt;
> + }
> +
> + return 0;
> +err_power_table:
> + clk_put(mout_appl);
> err_mout_apll:
> clk_put(mout_mpll);
> err_mout_mpll:
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 2/3] Add power consumption counter in task_struct.
+ scheduler maintainers
On Fri, Jul 5, 2013 at 12:17 AM, Konstantin Krivyakin
wrote:
> Signed-off-by: Konstantin Krivyakin
> ---
> include/linux/sched.h |2 ++
> include/uapi/linux/taskstats.h |2 ++
> kernel/fork.c |1 +
> kernel/sched/core.c|8
> kernel/sched/cputime.c | 11 +++
> kernel/tsacct.c|3 +++
> 6 files changed, 27 insertions(+)
>
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index cdd5407..f074718 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -1157,6 +1157,8 @@ struct task_struct {
> int __user *clear_child_tid;/* CLONE_CHILD_CLEARTID */
>
> cputime_t utime, stime, utimescaled, stimescaled;
> + u64 utime_power_cons;
> + u64 stime_power_cons;
> cputime_t gtime;
> #ifndef CONFIG_VIRT_CPU_ACCOUNTING_NATIVE
> struct cputime prev_cputime;
> diff --git a/include/uapi/linux/taskstats.h b/include/uapi/linux/taskstats.h
> index 2466e55..02ac708 100644
> --- a/include/uapi/linux/taskstats.h
> +++ b/include/uapi/linux/taskstats.h
> @@ -116,6 +116,8 @@ struct taskstats {
> /* Elapsed time [usec] */
> __u64 ac_utime; /* User CPU time [usec] */
> __u64 ac_stime; /* SYstem CPU time [usec] */
> + __u64 ac_utime_power_cons;/* User CPU time power consumption */
> + __u64 ac_stime_power_cons;/* System CPU time power consumption
> */
> __u64 ac_minflt; /* Minor Page Fault Count */
> __u64 ac_majflt; /* Major Page Fault Count */
> /* Basic Accounting Fields end */
> diff --git a/kernel/fork.c b/kernel/fork.c
> index 6e6a1c1..a021d5b 100644
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -1240,6 +1240,7 @@ static struct task_struct *copy_process(unsigned long
> clone_flags,
>
> p->utime = p->stime = p->gtime = 0;
> p->utimescaled = p->stimescaled = 0;
> + p->utime_power_cons = p->stime_power_cons = 0;
> #ifndef CONFIG_VIRT_CPU_ACCOUNTING_NATIVE
> p->prev_cputime.utime = p->prev_cputime.stime = 0;
> #endif
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 9b1f2e5..cac73d7 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -73,6 +73,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -297,6 +298,13 @@ __read_mostly int scheduler_running;
> int sysctl_sched_rt_runtime = 95;
>
>
> +static u64 cpu_power_cons(cputime_t cputime)
> +{
> + struct thread_info *ti = current_thread_info();
> +
> + return cpu_power_get(ti->cpu) * cputime;
> +}
> +
>
> /*
> * __task_rq_lock - lock the rq @p resides on.
> diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c
> index a7959e0..512727d 100644
> --- a/kernel/sched/cputime.c
> +++ b/kernel/sched/cputime.c
> @@ -4,6 +4,7 @@
> #include
> #include
> #include
> +#include
> #include "sched.h"
>
>
> @@ -126,6 +127,13 @@ static inline void task_group_account_field(struct
> task_struct *p, int index,
> cpuacct_account_field(p, index, tmp);
> }
>
> +static u64 cpu_power_cons(cputime_t cputime)
> +{
> + struct thread_info *ti = current_thread_info();
> +
> + return cpu_power_get(ti->cpu) * cputime;
> +}
> +
> /*
> * Account user cpu time to a process.
> * @p: the process that the cpu time gets accounted to
> @@ -138,6 +146,7 @@ void account_user_time(struct task_struct *p, cputime_t
> cputime,
> int index;
>
> /* Add user time to process. */
> + p->utime_power_cons += cpu_power_cons(cputime);
> p->utime += cputime;
> p->utimescaled += cputime_scaled;
> account_group_user_time(p, cputime);
> @@ -163,6 +172,7 @@ static void account_guest_time(struct task_struct *p,
> cputime_t cputime,
> u64 *cpustat = kcpustat_this_cpu->cpustat;
>
> /* Add guest time to process. */
> + p->utime_power_cons += cpu_power_cons(cputime);
> p->utime += cputime;
> p->utimescaled += cputime_scaled;
> account_group_user_time(p, cputime);
> @@ -190,6 +200,7 @@ void __account_system_time(struct task_struct *p,
> cputime_t cputime,
> cputime_t cputime_scaled, int index)
> {
> /* Add system time to process. */
> + p->stime_power_cons += cpu_power_cons(cputime);
> p->stime += cputime;
> p->stimescaled += cputime_scaled;
> account_group_system_time(p, cputime);
> diff --git a/kernel/tsacct.c b/kernel/tsacct.c
> index a1dd9a1..cea4a9c 100644
> --- a/kernel/tsacct.c
> +++ b/kernel/tsacct.c
> @@ -75,6 +75,9 @@ void bacct_add_tsk(struct user_namespace *user_ns,
> stats->ac_utimescaled = cputime_to_usecs(utimescaled);
> stats->ac_stimescaled = cputime_to_usecs(stimescaled);
>
> + stats->ac_utime_power_cons =
Re: [PATCH RFC 1/3] Add interface to receive current cpu power
+ cpufreq maintainers
On Fri, Jul 5, 2013 at 12:17 AM, Konstantin Krivyakin
wrote:
> Signed-off-by: Konstantin Krivyakin
> ---
> drivers/cpufreq/cpufreq.c | 17 +
> include/linux/cpufreq.h |6 ++
> 2 files changed, 23 insertions(+)
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 6a015ad..4180e89 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -1538,6 +1538,23 @@ int cpufreq_unregister_notifier(struct notifier_block
> *nb, unsigned int list)
> }
> EXPORT_SYMBOL(cpufreq_unregister_notifier);
>
> +/**
> + * cpu_power_get - get current CPU power
> + * @cpu: CPU number
> + */
> +u64 cpu_power_get(int cpu)
> +{
> + struct cpufreq_policy *policy = cpufreq_cpu_get(cpu);
> + u64 ret_power = 0;
> +
> + if (policy) {
> + ret_power = policy->current_power;
> + cpufreq_cpu_put(policy);
> + }
> +
> + return ret_power;
> +}
> +EXPORT_SYMBOL(cpu_power_get);
>
> /*
> * GOVERNORS*
> diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
> index 4d7390b..67323af 100644
> --- a/include/linux/cpufreq.h
> +++ b/include/linux/cpufreq.h
> @@ -107,6 +107,7 @@ struct cpufreq_policy {
> unsigned intmax;/* in kHz */
> unsigned intcur;/* in kHz, only needed if cpufreq
> * governors are used */
> + u64 current_power;
> unsigned intpolicy; /* see above */
> struct cpufreq_governor *governor; /* see below */
> void*governor_data;
> @@ -365,6 +366,7 @@ static inline unsigned int cpufreq_get(unsigned int cpu)
> #ifdef CONFIG_CPU_FREQ
> unsigned int cpufreq_quick_get(unsigned int cpu);
> unsigned int cpufreq_quick_get_max(unsigned int cpu);
> +u64 cpu_power_get(int cpu);
> #else
> static inline unsigned int cpufreq_quick_get(unsigned int cpu)
> {
> @@ -374,6 +376,10 @@ static inline unsigned int
> cpufreq_quick_get_max(unsigned int cpu)
> {
> return 0;
> }
> +static inline u64 cpu_power_get(unsigned int cpu)
> +{
> + return 0;
> +}
> #endif
>
> /*
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 0/3] Per-process power consumption measurement facility
Hi Krivyakin, Please use "./scripts/get_maintainer.pl" and send proper maintainers. I added them. Thank you, Kyungmin Park On Fri, Jul 5, 2013 at 12:17 AM, Konstantin Krivyakin wrote: > This patchset adds per-process power consumption measurement facility. > Power consumption is very important on mobile platforms. This code > allows to measure consumed power in Watts*Hours. The consumed power > for process is updated on scheduler switch and depends on current > CPU voltage and frequency. > > The formula for computation is: P = C * V^2 * f, where C is a constant > that reflects capacity of the system, V is the current voltage and > f is the current frequency. > (Taken from: http://en.wikipedia.org/wiki/CPU_power_dissipation). > > In this patchset was added implementation for Exynos platform > to demonstrate how it works. > > To minimize scheduler impact for each CPU P-state the value of (V^2 *f) > was precomputed at the time of platform initialization. > > And to reduce performance impact furthermore, the C constant is multiplied > in userspace. > > Konstantin Krivyakin (3): > Add interface to receive current cpu power > Add power consumption counter in task_struct. > Update current cpu power when cpu freq change for exynos. > > drivers/cpufreq/cpufreq.c| 17 + > drivers/cpufreq/exynos-cpufreq.c |2 ++ > drivers/cpufreq/exynos-cpufreq.h |1 + > drivers/cpufreq/exynos4x12-cpufreq.c | 19 ++- > include/linux/cpufreq.h |6 ++ > include/linux/sched.h|2 ++ > include/uapi/linux/taskstats.h |2 ++ > kernel/fork.c|1 + > kernel/sched/core.c |8 > kernel/sched/cputime.c | 11 +++ > kernel/tsacct.c |3 +++ > 11 files changed, 71 insertions(+), 1 deletion(-) > > -- > 1.7.9.5 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 0/3] Per-process power consumption measurement facility
Hi Krivyakin, Please use ./scripts/get_maintainer.pl and send proper maintainers. I added them. Thank you, Kyungmin Park On Fri, Jul 5, 2013 at 12:17 AM, Konstantin Krivyakin k.krivya...@samsung.com wrote: This patchset adds per-process power consumption measurement facility. Power consumption is very important on mobile platforms. This code allows to measure consumed power in Watts*Hours. The consumed power for process is updated on scheduler switch and depends on current CPU voltage and frequency. The formula for computation is: P = C * V^2 * f, where C is a constant that reflects capacity of the system, V is the current voltage and f is the current frequency. (Taken from: http://en.wikipedia.org/wiki/CPU_power_dissipation). In this patchset was added implementation for Exynos platform to demonstrate how it works. To minimize scheduler impact for each CPU P-state the value of (V^2 *f) was precomputed at the time of platform initialization. And to reduce performance impact furthermore, the C constant is multiplied in userspace. Konstantin Krivyakin (3): Add interface to receive current cpu power Add power consumption counter in task_struct. Update current cpu power when cpu freq change for exynos. drivers/cpufreq/cpufreq.c| 17 + drivers/cpufreq/exynos-cpufreq.c |2 ++ drivers/cpufreq/exynos-cpufreq.h |1 + drivers/cpufreq/exynos4x12-cpufreq.c | 19 ++- include/linux/cpufreq.h |6 ++ include/linux/sched.h|2 ++ include/uapi/linux/taskstats.h |2 ++ kernel/fork.c|1 + kernel/sched/core.c |8 kernel/sched/cputime.c | 11 +++ kernel/tsacct.c |3 +++ 11 files changed, 71 insertions(+), 1 deletion(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 1/3] Add interface to receive current cpu power
+ cpufreq maintainers
On Fri, Jul 5, 2013 at 12:17 AM, Konstantin Krivyakin
k.krivya...@samsung.com wrote:
Signed-off-by: Konstantin Krivyakin k.krivya...@samsung.com
---
drivers/cpufreq/cpufreq.c | 17 +
include/linux/cpufreq.h |6 ++
2 files changed, 23 insertions(+)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 6a015ad..4180e89 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1538,6 +1538,23 @@ int cpufreq_unregister_notifier(struct notifier_block
*nb, unsigned int list)
}
EXPORT_SYMBOL(cpufreq_unregister_notifier);
+/**
+ * cpu_power_get - get current CPU power
+ * @cpu: CPU number
+ */
+u64 cpu_power_get(int cpu)
+{
+ struct cpufreq_policy *policy = cpufreq_cpu_get(cpu);
+ u64 ret_power = 0;
+
+ if (policy) {
+ ret_power = policy-current_power;
+ cpufreq_cpu_put(policy);
+ }
+
+ return ret_power;
+}
+EXPORT_SYMBOL(cpu_power_get);
/*
* GOVERNORS*
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index 4d7390b..67323af 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -107,6 +107,7 @@ struct cpufreq_policy {
unsigned intmax;/* in kHz */
unsigned intcur;/* in kHz, only needed if cpufreq
* governors are used */
+ u64 current_power;
unsigned intpolicy; /* see above */
struct cpufreq_governor *governor; /* see below */
void*governor_data;
@@ -365,6 +366,7 @@ static inline unsigned int cpufreq_get(unsigned int cpu)
#ifdef CONFIG_CPU_FREQ
unsigned int cpufreq_quick_get(unsigned int cpu);
unsigned int cpufreq_quick_get_max(unsigned int cpu);
+u64 cpu_power_get(int cpu);
#else
static inline unsigned int cpufreq_quick_get(unsigned int cpu)
{
@@ -374,6 +376,10 @@ static inline unsigned int
cpufreq_quick_get_max(unsigned int cpu)
{
return 0;
}
+static inline u64 cpu_power_get(unsigned int cpu)
+{
+ return 0;
+}
#endif
/*
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 2/3] Add power consumption counter in task_struct.
+ scheduler maintainers
On Fri, Jul 5, 2013 at 12:17 AM, Konstantin Krivyakin
k.krivya...@samsung.com wrote:
Signed-off-by: Konstantin Krivyakin k.krivya...@samsung.com
---
include/linux/sched.h |2 ++
include/uapi/linux/taskstats.h |2 ++
kernel/fork.c |1 +
kernel/sched/core.c|8
kernel/sched/cputime.c | 11 +++
kernel/tsacct.c|3 +++
6 files changed, 27 insertions(+)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index cdd5407..f074718 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1157,6 +1157,8 @@ struct task_struct {
int __user *clear_child_tid;/* CLONE_CHILD_CLEARTID */
cputime_t utime, stime, utimescaled, stimescaled;
+ u64 utime_power_cons;
+ u64 stime_power_cons;
cputime_t gtime;
#ifndef CONFIG_VIRT_CPU_ACCOUNTING_NATIVE
struct cputime prev_cputime;
diff --git a/include/uapi/linux/taskstats.h b/include/uapi/linux/taskstats.h
index 2466e55..02ac708 100644
--- a/include/uapi/linux/taskstats.h
+++ b/include/uapi/linux/taskstats.h
@@ -116,6 +116,8 @@ struct taskstats {
/* Elapsed time [usec] */
__u64 ac_utime; /* User CPU time [usec] */
__u64 ac_stime; /* SYstem CPU time [usec] */
+ __u64 ac_utime_power_cons;/* User CPU time power consumption */
+ __u64 ac_stime_power_cons;/* System CPU time power consumption
*/
__u64 ac_minflt; /* Minor Page Fault Count */
__u64 ac_majflt; /* Major Page Fault Count */
/* Basic Accounting Fields end */
diff --git a/kernel/fork.c b/kernel/fork.c
index 6e6a1c1..a021d5b 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1240,6 +1240,7 @@ static struct task_struct *copy_process(unsigned long
clone_flags,
p-utime = p-stime = p-gtime = 0;
p-utimescaled = p-stimescaled = 0;
+ p-utime_power_cons = p-stime_power_cons = 0;
#ifndef CONFIG_VIRT_CPU_ACCOUNTING_NATIVE
p-prev_cputime.utime = p-prev_cputime.stime = 0;
#endif
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 9b1f2e5..cac73d7 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -73,6 +73,7 @@
#include linux/init_task.h
#include linux/binfmts.h
#include linux/context_tracking.h
+#include linux/cpufreq.h
#include asm/switch_to.h
#include asm/tlb.h
@@ -297,6 +298,13 @@ __read_mostly int scheduler_running;
int sysctl_sched_rt_runtime = 95;
+static u64 cpu_power_cons(cputime_t cputime)
+{
+ struct thread_info *ti = current_thread_info();
+
+ return cpu_power_get(ti-cpu) * cputime;
+}
+
/*
* __task_rq_lock - lock the rq @p resides on.
diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c
index a7959e0..512727d 100644
--- a/kernel/sched/cputime.c
+++ b/kernel/sched/cputime.c
@@ -4,6 +4,7 @@
#include linux/kernel_stat.h
#include linux/static_key.h
#include linux/context_tracking.h
+#include linux/cpufreq.h
#include sched.h
@@ -126,6 +127,13 @@ static inline void task_group_account_field(struct
task_struct *p, int index,
cpuacct_account_field(p, index, tmp);
}
+static u64 cpu_power_cons(cputime_t cputime)
+{
+ struct thread_info *ti = current_thread_info();
+
+ return cpu_power_get(ti-cpu) * cputime;
+}
+
/*
* Account user cpu time to a process.
* @p: the process that the cpu time gets accounted to
@@ -138,6 +146,7 @@ void account_user_time(struct task_struct *p, cputime_t
cputime,
int index;
/* Add user time to process. */
+ p-utime_power_cons += cpu_power_cons(cputime);
p-utime += cputime;
p-utimescaled += cputime_scaled;
account_group_user_time(p, cputime);
@@ -163,6 +172,7 @@ static void account_guest_time(struct task_struct *p,
cputime_t cputime,
u64 *cpustat = kcpustat_this_cpu-cpustat;
/* Add guest time to process. */
+ p-utime_power_cons += cpu_power_cons(cputime);
p-utime += cputime;
p-utimescaled += cputime_scaled;
account_group_user_time(p, cputime);
@@ -190,6 +200,7 @@ void __account_system_time(struct task_struct *p,
cputime_t cputime,
cputime_t cputime_scaled, int index)
{
/* Add system time to process. */
+ p-stime_power_cons += cpu_power_cons(cputime);
p-stime += cputime;
p-stimescaled += cputime_scaled;
account_group_system_time(p, cputime);
diff --git a/kernel/tsacct.c b/kernel/tsacct.c
index a1dd9a1..cea4a9c 100644
--- a/kernel/tsacct.c
+++ b/kernel/tsacct.c
@@ -75,6 +75,9 @@ void bacct_add_tsk(struct user_namespace *user_ns,
stats-ac_utimescaled = cputime_to_usecs(utimescaled);
stats-ac_stimescaled = cputime_to_usecs(stimescaled);
+
Re: [PATCH RFC 3/3] Update current cpu power when cpu freq change for exynos.
+ cpufreq maintainers
On Fri, Jul 5, 2013 at 12:17 AM, Konstantin Krivyakin
k.krivya...@samsung.com wrote:
Signed-off-by: Konstantin Krivyakin k.krivya...@samsung.com
---
drivers/cpufreq/exynos-cpufreq.c |2 ++
drivers/cpufreq/exynos-cpufreq.h |1 +
drivers/cpufreq/exynos4x12-cpufreq.c | 19 ++-
3 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/cpufreq/exynos-cpufreq.c
b/drivers/cpufreq/exynos-cpufreq.c
index 0d32f02..02f17bc 100644
--- a/drivers/cpufreq/exynos-cpufreq.c
+++ b/drivers/cpufreq/exynos-cpufreq.c
@@ -178,6 +178,8 @@ static int exynos_target(struct cpufreq_policy *policy,
}
new_freq = freq_table[index].frequency;
+ if (exynos_info-power_table)
+ policy-current_power = exynos_info-power_table[index];
ret = exynos_cpufreq_scale(new_freq);
diff --git a/drivers/cpufreq/exynos-cpufreq.h
b/drivers/cpufreq/exynos-cpufreq.h
index 92b852e..64f964f 100644
--- a/drivers/cpufreq/exynos-cpufreq.h
+++ b/drivers/cpufreq/exynos-cpufreq.h
@@ -38,6 +38,7 @@ struct exynos_dvfs_info {
unsigned intpll_safe_idx;
struct clk *cpu_clk;
unsigned int*volt_table;
+ u64 *power_table;
struct cpufreq_frequency_table *freq_table;
void (*set_freq)(unsigned int, unsigned int);
bool (*need_apll_change)(unsigned int, unsigned int);
diff --git a/drivers/cpufreq/exynos4x12-cpufreq.c
b/drivers/cpufreq/exynos4x12-cpufreq.c
index 08b7477..8905f9b 100644
--- a/drivers/cpufreq/exynos4x12-cpufreq.c
+++ b/drivers/cpufreq/exynos4x12-cpufreq.c
@@ -219,6 +219,7 @@ static void exynos4x12_set_frequency(unsigned int
old_index,
int exynos4x12_cpufreq_init(struct exynos_dvfs_info *info)
{
unsigned long rate;
+ int freq_count;
cpu_clk = clk_get(NULL, armclk);
if (IS_ERR(cpu_clk))
@@ -252,8 +253,24 @@ int exynos4x12_cpufreq_init(struct exynos_dvfs_info
*info)
info-set_freq = exynos4x12_set_frequency;
info-need_apll_change = exynos4x12_pms_change;
- return 0;
+ freq_count = sizeof(exynos4x12_freq_table) /
+ sizeof(struct cpufreq_frequency_table);
+ info-power_table = kzalloc(sizeof(u64) * freq_count, GFP_KERNEL);
+ if (!info-power_table)
+ goto err_power_table;
+
+ for (i = 0; i = freq_count; ++i) {
+ u64 freq = info-freq_table[i].frequency;
+ u64 volt = info-volt_table[i];
+ do_div(freq, 1000);
+ do_div(volt, 1000);
+ info-power_table[i] = freq * volt * volt;
+ }
+
+ return 0;
+err_power_table:
+ clk_put(mout_appl);
err_mout_apll:
clk_put(mout_mpll);
err_mout_mpll:
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] vmpressure: implement strict mode
+ Ms. Kim,
she already raised this issue at another mail thread.
Thank you,
Kyungmin Park
On Wed, Jun 26, 2013 at 6:51 AM, Luiz Capitulino wrote:
> Currently, applications are notified for the level they registered for
> _plus_ higher levels.
>
> This is a problem if the application wants to implement different
> actions for different levels. For example, an application might want
> to release 10% of its cache on level low, 50% on medium and 100% on
> critical. To do this, the application has to register a different fd
> for each event. However, fd low is always going to be notified and
> and all fds are going to be notified on level critical.
>
> Strict mode solves this problem by strictly notifiying the event
> an fd has registered for. It's optional. By default we still notify
> on higher levels.
>
> Signed-off-by: Luiz Capitulino
> ---
>
> PS: I'm following the discussion on the event storm problem, but I believe
> strict mode is orthogonal to what has been suggested (although the
> patches conflict)
>
> Documentation/cgroups/memory.txt | 10 ++
> mm/vmpressure.c | 19 +--
> 2 files changed, 23 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/cgroups/memory.txt
> b/Documentation/cgroups/memory.txt
> index ddf4f93..3c589cf 100644
> --- a/Documentation/cgroups/memory.txt
> +++ b/Documentation/cgroups/memory.txt
> @@ -807,12 +807,14 @@ register a notification, an application must:
>
> - create an eventfd using eventfd(2);
> - open memory.pressure_level;
> -- write string like " "
> +- write string like "
> [strict]"
>to cgroup.event_control.
>
> -Application will be notified through eventfd when memory pressure is at
> -the specific level (or higher). Read/write operations to
> -memory.pressure_level are no implemented.
> +Applications will be notified through eventfd when memory pressure is at
> +the specific level or higher. If strict is passed, then applications
> +will only be notified when memory pressure reaches the specified level.
> +
> +Read/write operations to memory.pressure_level are no implemented.
>
> Test:
>
> diff --git a/mm/vmpressure.c b/mm/vmpressure.c
> index 736a601..6289ede 100644
> --- a/mm/vmpressure.c
> +++ b/mm/vmpressure.c
> @@ -137,6 +137,7 @@ static enum vmpressure_levels
> vmpressure_calc_level(unsigned long scanned,
> struct vmpressure_event {
> struct eventfd_ctx *efd;
> enum vmpressure_levels level;
> + bool strict_mode;
> struct list_head node;
> };
>
> @@ -153,6 +154,9 @@ static bool vmpressure_event(struct vmpressure *vmpr,
>
> list_for_each_entry(ev, >events, node) {
> if (level >= ev->level) {
> + /* strict mode ensures level == ev->level */
> + if (ev->strict_mode && level != ev->level)
> + continue;
> eventfd_signal(ev->efd, 1);
> signalled = true;
> }
> @@ -292,7 +296,7 @@ void vmpressure_prio(gfp_t gfp, struct mem_cgroup *memcg,
> int prio)
> * infrastructure, so that the notifications will be delivered to the
> * @eventfd. The @args parameter is a string that denotes pressure level
> * threshold (one of vmpressure_str_levels, i.e. "low", "medium", or
> - * "critical").
> + * "critical") and optionally a different operating mode (i.e. "strict")
> *
> * This function should not be used directly, just pass it to (struct
> * cftype).register_event, and then cgroup core will handle everything by
> @@ -303,22 +307,33 @@ int vmpressure_register_event(struct cgroup *cg, struct
> cftype *cft,
> {
> struct vmpressure *vmpr = cg_to_vmpressure(cg);
> struct vmpressure_event *ev;
> + bool smode = false;
> + const char *p;
> int level;
>
> for (level = 0; level < VMPRESSURE_NUM_LEVELS; level++) {
> - if (!strcmp(vmpressure_str_levels[level], args))
> + p = vmpressure_str_levels[level];
> + if (!strncmp(p, args, strlen(p)))
> break;
> }
>
> if (level >= VMPRESSURE_NUM_LEVELS)
> return -EINVAL;
>
> + p = strchr(args, ' ');
> + if (p) {
> + if (strncmp(++p, "strict", 6))
> + return -EINVAL;
> + smode = true;
> + }
> +
> ev = kzalloc(sizeof(*ev), GFP_KERNEL);
> if (!ev)
> return -ENOMEM;
>
> ev->
Re: [PATCH] vmpressure: implement strict mode
+ Ms. Kim,
she already raised this issue at another mail thread.
Thank you,
Kyungmin Park
On Wed, Jun 26, 2013 at 6:51 AM, Luiz Capitulino lcapitul...@redhat.com wrote:
Currently, applications are notified for the level they registered for
_plus_ higher levels.
This is a problem if the application wants to implement different
actions for different levels. For example, an application might want
to release 10% of its cache on level low, 50% on medium and 100% on
critical. To do this, the application has to register a different fd
for each event. However, fd low is always going to be notified and
and all fds are going to be notified on level critical.
Strict mode solves this problem by strictly notifiying the event
an fd has registered for. It's optional. By default we still notify
on higher levels.
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
---
PS: I'm following the discussion on the event storm problem, but I believe
strict mode is orthogonal to what has been suggested (although the
patches conflict)
Documentation/cgroups/memory.txt | 10 ++
mm/vmpressure.c | 19 +--
2 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/Documentation/cgroups/memory.txt
b/Documentation/cgroups/memory.txt
index ddf4f93..3c589cf 100644
--- a/Documentation/cgroups/memory.txt
+++ b/Documentation/cgroups/memory.txt
@@ -807,12 +807,14 @@ register a notification, an application must:
- create an eventfd using eventfd(2);
- open memory.pressure_level;
-- write string like event_fd fd of memory.pressure_level level
+- write string like event_fd fd of memory.pressure_level level
[strict]
to cgroup.event_control.
-Application will be notified through eventfd when memory pressure is at
-the specific level (or higher). Read/write operations to
-memory.pressure_level are no implemented.
+Applications will be notified through eventfd when memory pressure is at
+the specific level or higher. If strict is passed, then applications
+will only be notified when memory pressure reaches the specified level.
+
+Read/write operations to memory.pressure_level are no implemented.
Test:
diff --git a/mm/vmpressure.c b/mm/vmpressure.c
index 736a601..6289ede 100644
--- a/mm/vmpressure.c
+++ b/mm/vmpressure.c
@@ -137,6 +137,7 @@ static enum vmpressure_levels
vmpressure_calc_level(unsigned long scanned,
struct vmpressure_event {
struct eventfd_ctx *efd;
enum vmpressure_levels level;
+ bool strict_mode;
struct list_head node;
};
@@ -153,6 +154,9 @@ static bool vmpressure_event(struct vmpressure *vmpr,
list_for_each_entry(ev, vmpr-events, node) {
if (level = ev-level) {
+ /* strict mode ensures level == ev-level */
+ if (ev-strict_mode level != ev-level)
+ continue;
eventfd_signal(ev-efd, 1);
signalled = true;
}
@@ -292,7 +296,7 @@ void vmpressure_prio(gfp_t gfp, struct mem_cgroup *memcg,
int prio)
* infrastructure, so that the notifications will be delivered to the
* @eventfd. The @args parameter is a string that denotes pressure level
* threshold (one of vmpressure_str_levels, i.e. low, medium, or
- * critical).
+ * critical) and optionally a different operating mode (i.e. strict)
*
* This function should not be used directly, just pass it to (struct
* cftype).register_event, and then cgroup core will handle everything by
@@ -303,22 +307,33 @@ int vmpressure_register_event(struct cgroup *cg, struct
cftype *cft,
{
struct vmpressure *vmpr = cg_to_vmpressure(cg);
struct vmpressure_event *ev;
+ bool smode = false;
+ const char *p;
int level;
for (level = 0; level VMPRESSURE_NUM_LEVELS; level++) {
- if (!strcmp(vmpressure_str_levels[level], args))
+ p = vmpressure_str_levels[level];
+ if (!strncmp(p, args, strlen(p)))
break;
}
if (level = VMPRESSURE_NUM_LEVELS)
return -EINVAL;
+ p = strchr(args, ' ');
+ if (p) {
+ if (strncmp(++p, strict, 6))
+ return -EINVAL;
+ smode = true;
+ }
+
ev = kzalloc(sizeof(*ev), GFP_KERNEL);
if (!ev)
return -ENOMEM;
ev-efd = eventfd;
ev-level = level;
+ ev-strict_mode = smode;
mutex_lock(vmpr-events_lock);
list_add(ev-node, vmpr-events);
--
1.8.1.4
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majord...@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: a href=mailto:d...@kvack.org; em...@kvack.org /a
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
Re: RFC: named anonymous vmas
On Sat, Jun 22, 2013 at 8:42 AM, Colin Cross wrote: > One of the features of ashmem (drivers/staging/android/ashmem.c) that > hasn't gotten much discussion about moving out of staging is named > anonymous memory. > > In Android, ashmem is used for three different features, and most > users of it only care about one feature at a time. One is volatile > ranges, which John Stultz has been implementing. The second is > anonymous shareable memory without having a world-writable tmpfs that > untrusted apps could fill with files. The third and most heavily used > feature within the Android codebase is named anonymous memory, where a > region of anonymous memory can have a name associated with it that > will show up in /proc/pid/maps. The Dalvik VM likes to use this Good to know it. I didn't know ashmem provides these features. we are also discussing these requirement internally. and study how to show who request these anon memory and which callback is used for it. > feature extensively, even for memory that will never be shared and > could easily be allocated using an anonymous mmap, and even malloc has > used it in the past. It provides an easy way to collate memory used > for different purposes across multiple processes, which Android uses > for its "dumpsys meminfo" and "librank" tools to determine how much > memory is used for java heaps, JIT caches, native mallocs, etc. Same requirement for app developers. they want to know what's the meaning these anon memory is allocated and how to find out these anon memory is allocated at their codes. > > I'd like to add this feature for anonymous mmap memory. I propose > adding an madvise2(unsigned long start, size_t len_in, int behavior, > void *ptr, size_t size) syscall and a new MADV_NAME behavior, which > treats ptr as a string of length size. The string would be copied > somewhere reusable in the kernel, or reused if it already exists, and > the kernel address of the string would get stashed in a new field in > struct vm_area_struct. Adjacent vmas would only get merged if the > name pointer matched, and naming part of a mapping would split the > mapping. show_map_vma would print the name only if none of the other > existing names rules match. Do you want to create new syscall? can it use current madvise and only allow this feature at linux only? As you know it's just hint and it doesn't break existing memory behaviors. > > Any comments as I start implementing it? Is there any reason to allow > naming a file-backed mapping and showing it alongside the file name in > /proc/pid/maps? > Thank you, Kyungmin Park -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: named anonymous vmas
On Sat, Jun 22, 2013 at 8:42 AM, Colin Cross ccr...@google.com wrote: One of the features of ashmem (drivers/staging/android/ashmem.c) that hasn't gotten much discussion about moving out of staging is named anonymous memory. In Android, ashmem is used for three different features, and most users of it only care about one feature at a time. One is volatile ranges, which John Stultz has been implementing. The second is anonymous shareable memory without having a world-writable tmpfs that untrusted apps could fill with files. The third and most heavily used feature within the Android codebase is named anonymous memory, where a region of anonymous memory can have a name associated with it that will show up in /proc/pid/maps. The Dalvik VM likes to use this Good to know it. I didn't know ashmem provides these features. we are also discussing these requirement internally. and study how to show who request these anon memory and which callback is used for it. feature extensively, even for memory that will never be shared and could easily be allocated using an anonymous mmap, and even malloc has used it in the past. It provides an easy way to collate memory used for different purposes across multiple processes, which Android uses for its dumpsys meminfo and librank tools to determine how much memory is used for java heaps, JIT caches, native mallocs, etc. Same requirement for app developers. they want to know what's the meaning these anon memory is allocated and how to find out these anon memory is allocated at their codes. I'd like to add this feature for anonymous mmap memory. I propose adding an madvise2(unsigned long start, size_t len_in, int behavior, void *ptr, size_t size) syscall and a new MADV_NAME behavior, which treats ptr as a string of length size. The string would be copied somewhere reusable in the kernel, or reused if it already exists, and the kernel address of the string would get stashed in a new field in struct vm_area_struct. Adjacent vmas would only get merged if the name pointer matched, and naming part of a mapping would split the mapping. show_map_vma would print the name only if none of the other existing names rules match. Do you want to create new syscall? can it use current madvise and only allow this feature at linux only? As you know it's just hint and it doesn't break existing memory behaviors. Any comments as I start implementing it? Is there any reason to allow naming a file-backed mapping and showing it alongside the file name in /proc/pid/maps? Thank you, Kyungmin Park -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] MAINTAINERS: Add Samsung pinctrl entries
On Mon, Jun 17, 2013 at 7:17 AM, Doug Anderson wrote: > It's convenient if get_maintainer suggests sending samsung/exynos > pinctrl changes to linux-samsung-soc and to Tomasz and Thomas. > > Signed-off-by: Doug Anderson Acked-by: Kyungmin Park > --- > Changes in v2: > - Updated with Thomas and Tomasz; removed Linus since he's already > there as part of the general pinctrl match. > > MAINTAINERS | 10 ++ > 1 file changed, 10 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 8d97b3e..f55e3c7 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -6284,6 +6284,16 @@ L: linux-arm-ker...@lists.infradead.org > (moderated for non-subscribers) > S: Maintained > F: drivers/pinctrl/pinctrl-at91.c > > +PIN CONTROLLER - SAMSUNG > +M: Tomasz Figa > +M: Thomas Abraham > +L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) > +L: linux-samsung-...@vger.kernel.org (moderated for non-subscribers) > +S: Maintained > +F: drivers/pinctrl/pinctrl-exynos.* > +F: drivers/pinctrl/pinctrl-s3c* > +F: drivers/pinctrl/pinctrl-samsung.* > + > PIN CONTROLLER - ST SPEAR > M: Viresh Kumar > L: spear-de...@list.st.com > -- > 1.8.3 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] MAINTAINERS: Add Samsung pinctrl entries
On Mon, Jun 17, 2013 at 7:17 AM, Doug Anderson diand...@chromium.org wrote: It's convenient if get_maintainer suggests sending samsung/exynos pinctrl changes to linux-samsung-soc and to Tomasz and Thomas. Signed-off-by: Doug Anderson diand...@chromium.org Acked-by: Kyungmin Park kyungmin.p...@samsung.com --- Changes in v2: - Updated with Thomas and Tomasz; removed Linus since he's already there as part of the general pinctrl match. MAINTAINERS | 10 ++ 1 file changed, 10 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 8d97b3e..f55e3c7 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6284,6 +6284,16 @@ L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) S: Maintained F: drivers/pinctrl/pinctrl-at91.c +PIN CONTROLLER - SAMSUNG +M: Tomasz Figa t.f...@samsung.com +M: Thomas Abraham thomas.abra...@linaro.org +L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) +L: linux-samsung-...@vger.kernel.org (moderated for non-subscribers) +S: Maintained +F: drivers/pinctrl/pinctrl-exynos.* +F: drivers/pinctrl/pinctrl-s3c* +F: drivers/pinctrl/pinctrl-samsung.* + PIN CONTROLLER - ST SPEAR M: Viresh Kumar viresh.li...@gmail.com L: spear-de...@list.st.com -- 1.8.3 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: vmscan: remove redundant querying to shrinker
On Sat, Jun 15, 2013 at 8:04 AM, Andrew Morton
wrote:
>
> On Sat, 15 Jun 2013 03:13:26 +0900 HeeSub Shin wrote:
>
> > Hello,
> >
> > On Fri, Jun 14, 2013 at 8:10 PM, Minchan Kim wrote:
> >
> > >
> > > Hello,
> > >
> > > On Fri, Jun 14, 2013 at 07:07:51PM +0900, Heesub Shin wrote:
> > > > shrink_slab() queries each slab cache to get the number of
> > > > elements in it. In most cases such queries are cheap but,
> > > > on some caches. For example, Android low-memory-killer,
> > > > which is operates as a slab shrinker, does relatively
> > > > long calculation once invoked and it is quite expensive.
> > >
> > > LMK as shrinker is really bad, which everybody didn't want
> > > when we reviewed it a few years ago so that's a one of reason
> > > LMK couldn't be promoted to mainline yet. So your motivation is
> > > already not atrractive. ;-)
> > >
> > > >
> > > > This patch removes redundant queries to shrinker function
> > > > in the loop of shrink batch.
> > >
> > > I didn't review the patch and others don't want it, I guess.
> > > Because slab shrink is under construction and many patches were
> > > already merged into mmtom. Please look at latest mmotm tree.
> > >
> > > git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
> >
> >
> > >
> > > If you concern is still in there and it's really big concern of MM
> > > we should take care, NOT LMK, plese, resend it.
> > >
> > >
> > I've noticed that there are huge changes there in the recent mmotm and
> > you
> > guys already settled the issue of my concern. I usually keep track
> > changes
> > in recent mm-tree, but this time I didn't. My bad :-)
> >
>
> I'm not averse to merging an improvement like this even if it gets
> rubbed out by forthcoming changes. The big changes may never get
> merged or may be reverted. And by merging this patch, others are more
> likely to grab it, backport it into earlier kernels and benefit from
> it.
>
> Also, the problem which this simple patch fixes might be present in a
> different form after the large patchset has been merged. That does not
> appear to be the case this time.
>
> So I'd actually like to merge Heesub's patch. Problem is, I don't have
> a way to redistribute it for testing - I'd need to effectively revert
> the whole thing when integrating Glauber's stuff on top, so nobody who
> is using linux-next would test Heesub's change. Drat.
>
>
>
>
> However I'm a bit sceptical about the description here. The shrinker
> is supposed to special-case the "nr_to_scan == 0" case and AFAICT
> drivers/staging/android/lowmemorykiller.c:lowmem_shrink() does do this,
> and it looks like the function will be pretty quick in this case.
>
> In other words, the behaviour of lowmem_shrink(nr_to_scan == 0) does
> not match Heesub's description. What's up with that?
>
Right, but real use case is differnet at mainline kernel. and he found it.
there are two approaches,
1. Reduce do_shinker_slab call by this patch
2. Optimize shinker function itself as like this.
Thank you,
Kyungmin Park
>
>
> Also, there is an obvious optimisation which we could make to
> lowmem_shrink(). All this stuff:
>
> if (lowmem_adj_size < array_size)
> array_size = lowmem_adj_size;
> if (lowmem_minfree_size < array_size)
> array_size = lowmem_minfree_size;
> for (i = 0; i < array_size; i++) {
> if (other_free < lowmem_minfree[i] &&
> other_file < lowmem_minfree[i]) {
> min_score_adj = lowmem_adj[i];
> break;
> }
> }
>
> does nothing useful in the nr_to_scan==0 case and should be omitted for
> this special case. But this problem was fixed in the large shrinker
> rework in -mm.
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: vmscan: remove redundant querying to shrinker
On Sat, Jun 15, 2013 at 8:04 AM, Andrew Morton
a...@linux-foundation.org wrote:
On Sat, 15 Jun 2013 03:13:26 +0900 HeeSub Shin hee...@gmail.com wrote:
Hello,
On Fri, Jun 14, 2013 at 8:10 PM, Minchan Kim minc...@kernel.org wrote:
Hello,
On Fri, Jun 14, 2013 at 07:07:51PM +0900, Heesub Shin wrote:
shrink_slab() queries each slab cache to get the number of
elements in it. In most cases such queries are cheap but,
on some caches. For example, Android low-memory-killer,
which is operates as a slab shrinker, does relatively
long calculation once invoked and it is quite expensive.
LMK as shrinker is really bad, which everybody didn't want
when we reviewed it a few years ago so that's a one of reason
LMK couldn't be promoted to mainline yet. So your motivation is
already not atrractive. ;-)
This patch removes redundant queries to shrinker function
in the loop of shrink batch.
I didn't review the patch and others don't want it, I guess.
Because slab shrink is under construction and many patches were
already merged into mmtom. Please look at latest mmotm tree.
git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
If you concern is still in there and it's really big concern of MM
we should take care, NOT LMK, plese, resend it.
I've noticed that there are huge changes there in the recent mmotm and
you
guys already settled the issue of my concern. I usually keep track
changes
in recent mm-tree, but this time I didn't. My bad :-)
I'm not averse to merging an improvement like this even if it gets
rubbed out by forthcoming changes. The big changes may never get
merged or may be reverted. And by merging this patch, others are more
likely to grab it, backport it into earlier kernels and benefit from
it.
Also, the problem which this simple patch fixes might be present in a
different form after the large patchset has been merged. That does not
appear to be the case this time.
So I'd actually like to merge Heesub's patch. Problem is, I don't have
a way to redistribute it for testing - I'd need to effectively revert
the whole thing when integrating Glauber's stuff on top, so nobody who
is using linux-next would test Heesub's change. Drat.
However I'm a bit sceptical about the description here. The shrinker
is supposed to special-case the nr_to_scan == 0 case and AFAICT
drivers/staging/android/lowmemorykiller.c:lowmem_shrink() does do this,
and it looks like the function will be pretty quick in this case.
In other words, the behaviour of lowmem_shrink(nr_to_scan == 0) does
not match Heesub's description. What's up with that?
Right, but real use case is differnet at mainline kernel. and he found it.
there are two approaches,
1. Reduce do_shinker_slab call by this patch
2. Optimize shinker function itself as like this.
Thank you,
Kyungmin Park
Also, there is an obvious optimisation which we could make to
lowmem_shrink(). All this stuff:
if (lowmem_adj_size array_size)
array_size = lowmem_adj_size;
if (lowmem_minfree_size array_size)
array_size = lowmem_minfree_size;
for (i = 0; i array_size; i++) {
if (other_free lowmem_minfree[i]
other_file lowmem_minfree[i]) {
min_score_adj = lowmem_adj[i];
break;
}
}
does nothing useful in the nr_to_scan==0 case and should be omitted for
this special case. But this problem was fixed in the large shrinker
rework in -mm.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majord...@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: a href=mailto:d...@kvack.org; em...@kvack.org /a
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 15/30] mtd: onenand/samsung: make regs-onenand.h file local
Thanks Arnd.
On Thu, Apr 11, 2013 at 9:04 AM, Arnd Bergmann wrote:
> Nothing uses the NAND register definitions other than the
> actual driver, so we can move the header file into the
> same local directory, which lets us build it in a multiplatform
> configuration.
>
> Signed-off-by: Arnd Bergmann
> Cc: linux-...@lists.infradead.org
> Cc: Kyungmin Park
Acked-by: Kyungmin Park
> Cc: David Woodhouse
> ---
> drivers/mtd/onenand/samsung.c | 4
> ++--
> .../include/plat/regs-onenand.h => drivers/mtd/onenand/samsung.h | 2 --
> 2 files changed, 2 insertions(+), 4 deletions(-)
> rename arch/arm/plat-samsung/include/plat/regs-onenand.h =>
> drivers/mtd/onenand/samsung.h (98%)
>
> diff --git a/drivers/mtd/onenand/samsung.c b/drivers/mtd/onenand/samsung.c
> index 33f2a8f..2cf7408 100644
> --- a/drivers/mtd/onenand/samsung.c
> +++ b/drivers/mtd/onenand/samsung.c
> @@ -23,11 +23,11 @@
> #include
> #include
> #include
> +#include
>
> #include
> -#include
>
> -#include
> +#include "samsung.h"
>
> enum soc_type {
> TYPE_S3C6400,
> diff --git a/arch/arm/plat-samsung/include/plat/regs-onenand.h
> b/drivers/mtd/onenand/samsung.h
> similarity index 98%
> rename from arch/arm/plat-samsung/include/plat/regs-onenand.h
> rename to drivers/mtd/onenand/samsung.h
> index 930ea8b..c4a80e6 100644
> --- a/arch/arm/plat-samsung/include/plat/regs-onenand.h
> +++ b/drivers/mtd/onenand/samsung.h
> @@ -11,8 +11,6 @@
> #ifndef __SAMSUNG_ONENAND_H__
> #define __SAMSUNG_ONENAND_H__
>
> -#include
> -
> /*
> * OneNAND Controller
> */
> --
> 1.8.1.2
>
>
> __
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 02/30] ARM: exynos: prepare for sparse IRQ
On Thu, Apr 11, 2013 at 9:04 AM, Arnd Bergmann wrote: > When we enable CONFIG_SPARSE_IRQ, we have to set the value of NR_IRQS in > the machine_desc for legacy IRQ domains, and any file referring to the > number of interrupts or a specific number must include the mach/irqs.h > header file explicitly. It's really wanted feature. > > Signed-off-by: Arnd Bergmann Acked-by: Kyungmin Park > --- > arch/arm/mach-exynos/dev-uart.c | 1 + > arch/arm/mach-exynos/include/mach/irqs.h | 5 - > arch/arm/mach-exynos/mach-armlex4210.c | 2 ++ > arch/arm/mach-exynos/mach-exynos4-dt.c | 3 +++ > arch/arm/mach-exynos/mach-exynos5-dt.c | 2 ++ > arch/arm/mach-exynos/mach-nuri.c | 2 ++ > arch/arm/mach-exynos/mach-origen.c | 2 ++ > arch/arm/mach-exynos/mach-smdk4x12.c | 2 ++ > arch/arm/mach-exynos/mach-smdkv310.c | 3 +++ > arch/arm/plat-samsung/irq-vic-timer.c| 1 + > arch/arm/plat-samsung/pm.c | 1 + > arch/arm/plat-samsung/s5p-irq.c | 1 + > 12 files changed, 24 insertions(+), 1 deletion(-) > > diff --git a/arch/arm/mach-exynos/dev-uart.c b/arch/arm/mach-exynos/dev-uart.c > index 7c42f4b..c48aff0 100644 > --- a/arch/arm/mach-exynos/dev-uart.c > +++ b/arch/arm/mach-exynos/dev-uart.c > @@ -20,6 +20,7 @@ > #include > #include > #include > +#include > > #include > > diff --git a/arch/arm/mach-exynos/include/mach/irqs.h > b/arch/arm/mach-exynos/include/mach/irqs.h > index 35fe6d5..c72f59d 100644 > --- a/arch/arm/mach-exynos/include/mach/irqs.h > +++ b/arch/arm/mach-exynos/include/mach/irqs.h > @@ -467,7 +467,10 @@ > #define IRQ_TIMER_BASE (IRQ_GPIO_END + 64) > > /* Set the default NR_IRQS */ > +#define EXYNOS_NR_IRQS (IRQ_TIMER_BASE + IRQ_TIMER_COUNT) > > -#define NR_IRQS(IRQ_TIMER_BASE + > IRQ_TIMER_COUNT) > +#ifndef CONFIG_SPARSE_IRQ > +#define NR_IRQSEXYNOS_NR_IRQS > +#endif > > #endif /* __ASM_ARCH_IRQS_H */ > diff --git a/arch/arm/mach-exynos/mach-armlex4210.c > b/arch/arm/mach-exynos/mach-armlex4210.c > index 2c23b65..a503e02 100644 > --- a/arch/arm/mach-exynos/mach-armlex4210.c > +++ b/arch/arm/mach-exynos/mach-armlex4210.c > @@ -25,6 +25,7 @@ > #include > #include > > +#include > #include > > #include "common.h" > @@ -196,6 +197,7 @@ static void __init armlex4210_machine_init(void) > MACHINE_START(ARMLEX4210, "ARMLEX4210") > /* Maintainer: Alim Akhtar */ > .atag_offset= 0x100, > + .nr_irqs= EXYNOS_NR_IRQS, > .smp= smp_ops(exynos_smp_ops), > .init_irq = exynos4_init_irq, > .map_io = armlex4210_map_io, > diff --git a/arch/arm/mach-exynos/mach-exynos4-dt.c > b/arch/arm/mach-exynos/mach-exynos4-dt.c > index b9ed834..5f23682 100644 > --- a/arch/arm/mach-exynos/mach-exynos4-dt.c > +++ b/arch/arm/mach-exynos/mach-exynos4-dt.c > @@ -20,6 +20,8 @@ > > #include > #include > +#include > + > > #include "common.h" > > @@ -54,6 +56,7 @@ static void __init exynos4_reserve(void) > } > DT_MACHINE_START(EXYNOS4210_DT, "Samsung Exynos4 (Flattened Device Tree)") > /* Maintainer: Thomas Abraham */ > + .nr_irqs= EXYNOS_NR_IRQS, > .smp= smp_ops(exynos_smp_ops), > .init_irq = exynos4_init_irq, > .map_io = exynos4_dt_map_io, > diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c > b/arch/arm/mach-exynos/mach-exynos5-dt.c > index 753b94f..8b7456a 100644 > --- a/arch/arm/mach-exynos/mach-exynos5-dt.c > +++ b/arch/arm/mach-exynos/mach-exynos5-dt.c > @@ -16,6 +16,7 @@ > #include > > #include > +#include > #include > > #include > @@ -76,6 +77,7 @@ static void __init exynos5_reserve(void) > > DT_MACHINE_START(EXYNOS5_DT, "SAMSUNG EXYNOS5 (Flattened Device Tree)") > /* Maintainer: Kukjin Kim */ > + .nr_irqs= EXYNOS_NR_IRQS, > .init_irq = exynos5_init_irq, > .smp= smp_ops(exynos_smp_ops), > .map_io = exynos5_dt_map_io, > diff --git a/arch/arm/mach-exynos/mach-nuri.c > b/arch/arm/mach-exynos/mach-nuri.c > index 0c10852..fbae331 100644 > --- a/arch/arm/mach-exynos/mach-nuri.c > +++ b/arch/arm/mach-exynos/mach-nuri.c > @@ -53,6 +53,7 @@ > #include > #include > > +#include > #include > > #include "common.h" > @@ -1376,6 +1377,7 @@ static void __init nuri_machine_init(void) > MACHINE_START(NURI, "NURI") > /* Maintainer: Kyungmin Park */ >
Re: [PATCH 02/30] ARM: exynos: prepare for sparse IRQ
On Thu, Apr 11, 2013 at 9:04 AM, Arnd Bergmann a...@arndb.de wrote: When we enable CONFIG_SPARSE_IRQ, we have to set the value of NR_IRQS in the machine_desc for legacy IRQ domains, and any file referring to the number of interrupts or a specific number must include the mach/irqs.h header file explicitly. It's really wanted feature. Signed-off-by: Arnd Bergmann a...@arndb.de Acked-by: Kyungmin Park kyungmin.p...@samsung.com --- arch/arm/mach-exynos/dev-uart.c | 1 + arch/arm/mach-exynos/include/mach/irqs.h | 5 - arch/arm/mach-exynos/mach-armlex4210.c | 2 ++ arch/arm/mach-exynos/mach-exynos4-dt.c | 3 +++ arch/arm/mach-exynos/mach-exynos5-dt.c | 2 ++ arch/arm/mach-exynos/mach-nuri.c | 2 ++ arch/arm/mach-exynos/mach-origen.c | 2 ++ arch/arm/mach-exynos/mach-smdk4x12.c | 2 ++ arch/arm/mach-exynos/mach-smdkv310.c | 3 +++ arch/arm/plat-samsung/irq-vic-timer.c| 1 + arch/arm/plat-samsung/pm.c | 1 + arch/arm/plat-samsung/s5p-irq.c | 1 + 12 files changed, 24 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-exynos/dev-uart.c b/arch/arm/mach-exynos/dev-uart.c index 7c42f4b..c48aff0 100644 --- a/arch/arm/mach-exynos/dev-uart.c +++ b/arch/arm/mach-exynos/dev-uart.c @@ -20,6 +20,7 @@ #include asm/mach/irq.h #include mach/hardware.h #include mach/map.h +#include mach/irqs.h #include plat/devs.h diff --git a/arch/arm/mach-exynos/include/mach/irqs.h b/arch/arm/mach-exynos/include/mach/irqs.h index 35fe6d5..c72f59d 100644 --- a/arch/arm/mach-exynos/include/mach/irqs.h +++ b/arch/arm/mach-exynos/include/mach/irqs.h @@ -467,7 +467,10 @@ #define IRQ_TIMER_BASE (IRQ_GPIO_END + 64) /* Set the default NR_IRQS */ +#define EXYNOS_NR_IRQS (IRQ_TIMER_BASE + IRQ_TIMER_COUNT) -#define NR_IRQS(IRQ_TIMER_BASE + IRQ_TIMER_COUNT) +#ifndef CONFIG_SPARSE_IRQ +#define NR_IRQSEXYNOS_NR_IRQS +#endif #endif /* __ASM_ARCH_IRQS_H */ diff --git a/arch/arm/mach-exynos/mach-armlex4210.c b/arch/arm/mach-exynos/mach-armlex4210.c index 2c23b65..a503e02 100644 --- a/arch/arm/mach-exynos/mach-armlex4210.c +++ b/arch/arm/mach-exynos/mach-armlex4210.c @@ -25,6 +25,7 @@ #include plat/regs-srom.h #include plat/sdhci.h +#include mach/irqs.h #include mach/map.h #include common.h @@ -196,6 +197,7 @@ static void __init armlex4210_machine_init(void) MACHINE_START(ARMLEX4210, ARMLEX4210) /* Maintainer: Alim Akhtar alim.akh...@samsung.com */ .atag_offset= 0x100, + .nr_irqs= EXYNOS_NR_IRQS, .smp= smp_ops(exynos_smp_ops), .init_irq = exynos4_init_irq, .map_io = armlex4210_map_io, diff --git a/arch/arm/mach-exynos/mach-exynos4-dt.c b/arch/arm/mach-exynos/mach-exynos4-dt.c index b9ed834..5f23682 100644 --- a/arch/arm/mach-exynos/mach-exynos4-dt.c +++ b/arch/arm/mach-exynos/mach-exynos4-dt.c @@ -20,6 +20,8 @@ #include asm/mach/arch.h #include plat/mfc.h +#include mach/irqs.h + #include common.h @@ -54,6 +56,7 @@ static void __init exynos4_reserve(void) } DT_MACHINE_START(EXYNOS4210_DT, Samsung Exynos4 (Flattened Device Tree)) /* Maintainer: Thomas Abraham thomas.abra...@linaro.org */ + .nr_irqs= EXYNOS_NR_IRQS, .smp= smp_ops(exynos_smp_ops), .init_irq = exynos4_init_irq, .map_io = exynos4_dt_map_io, diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c b/arch/arm/mach-exynos/mach-exynos5-dt.c index 753b94f..8b7456a 100644 --- a/arch/arm/mach-exynos/mach-exynos5-dt.c +++ b/arch/arm/mach-exynos/mach-exynos5-dt.c @@ -16,6 +16,7 @@ #include linux/clocksource.h #include asm/mach/arch.h +#include mach/irqs.h #include mach/regs-pmu.h #include plat/cpu.h @@ -76,6 +77,7 @@ static void __init exynos5_reserve(void) DT_MACHINE_START(EXYNOS5_DT, SAMSUNG EXYNOS5 (Flattened Device Tree)) /* Maintainer: Kukjin Kim kgene@samsung.com */ + .nr_irqs= EXYNOS_NR_IRQS, .init_irq = exynos5_init_irq, .smp= smp_ops(exynos_smp_ops), .map_io = exynos5_dt_map_io, diff --git a/arch/arm/mach-exynos/mach-nuri.c b/arch/arm/mach-exynos/mach-nuri.c index 0c10852..fbae331 100644 --- a/arch/arm/mach-exynos/mach-nuri.c +++ b/arch/arm/mach-exynos/mach-nuri.c @@ -53,6 +53,7 @@ #include plat/fimc-core.h #include plat/camport.h +#include mach/irqs.h #include mach/map.h #include common.h @@ -1376,6 +1377,7 @@ static void __init nuri_machine_init(void) MACHINE_START(NURI, NURI) /* Maintainer: Kyungmin Park kyungmin.p...@samsung.com */ .atag_offset= 0x100, + .nr_irqs= EXYNOS_NR_IRQS, .smp= smp_ops(exynos_smp_ops), .init_irq = exynos4_init_irq, .map_io
Re: [PATCH 15/30] mtd: onenand/samsung: make regs-onenand.h file local
Thanks Arnd.
On Thu, Apr 11, 2013 at 9:04 AM, Arnd Bergmann a...@arndb.de wrote:
Nothing uses the NAND register definitions other than the
actual driver, so we can move the header file into the
same local directory, which lets us build it in a multiplatform
configuration.
Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: linux-...@lists.infradead.org
Cc: Kyungmin Park kyungmin.p...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: David Woodhouse dw...@infradead.org
---
drivers/mtd/onenand/samsung.c | 4
++--
.../include/plat/regs-onenand.h = drivers/mtd/onenand/samsung.h | 2 --
2 files changed, 2 insertions(+), 4 deletions(-)
rename arch/arm/plat-samsung/include/plat/regs-onenand.h =
drivers/mtd/onenand/samsung.h (98%)
diff --git a/drivers/mtd/onenand/samsung.c b/drivers/mtd/onenand/samsung.c
index 33f2a8f..2cf7408 100644
--- a/drivers/mtd/onenand/samsung.c
+++ b/drivers/mtd/onenand/samsung.c
@@ -23,11 +23,11 @@
#include linux/mtd/partitions.h
#include linux/dma-mapping.h
#include linux/interrupt.h
+#include linux/io.h
#include asm/mach/flash.h
-#include plat/regs-onenand.h
-#include linux/io.h
+#include samsung.h
enum soc_type {
TYPE_S3C6400,
diff --git a/arch/arm/plat-samsung/include/plat/regs-onenand.h
b/drivers/mtd/onenand/samsung.h
similarity index 98%
rename from arch/arm/plat-samsung/include/plat/regs-onenand.h
rename to drivers/mtd/onenand/samsung.h
index 930ea8b..c4a80e6 100644
--- a/arch/arm/plat-samsung/include/plat/regs-onenand.h
+++ b/drivers/mtd/onenand/samsung.h
@@ -11,8 +11,6 @@
#ifndef __SAMSUNG_ONENAND_H__
#define __SAMSUNG_ONENAND_H__
-#include mach/hardware.h
-
/*
* OneNAND Controller
*/
--
1.8.1.2
__
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] mm: remove swapcache page early
Hi,
On Wed, Mar 27, 2013 at 11:22 AM, Minchan Kim wrote:
> Swap subsystem does lazy swap slot free with expecting the page
> would be swapped out again so we can't avoid unnecessary write.
>
> But the problem in in-memory swap is that it consumes memory space
> until vm_swap_full(ie, used half of all of swap device) condition
> meet. It could be bad if we use multiple swap device, small in-memory swap
> and big storage swap or in-memory swap alone.
>
> This patch changes vm_swap_full logic slightly so it could free
> swap slot early if the backed device is really fast.
> For it, I used SWP_SOLIDSTATE but It might be controversial.
> So let's add Ccing Shaohua and Hugh.
> If it's a problem for SSD, I'd like to create new type SWP_INMEMORY
> or something for z* family.
I perfer to add new SWP_INMEMORY for z* family. as you know SSD and
memory is different characteristics.
and if new type is added, it doesn't need to modify lots of codes.
Do you have any data for it? do you get meaningful performance gain or
efficiency of z* family? If yes, please share it.
Thank you,
Kyungmin Park
>
> Other problem is zram is block device so that it can set SWP_INMEMORY
> or SWP_SOLIDSTATE easily(ie, actually, zram is already done) but
> I have no idea to use it for frontswap.
>
> Any idea?
>
> Other optimize point is we remove it unconditionally when we
> found it's exclusive when swap in happen.
> It could help frontswap family, too.
> What do you think about it?
>
> Cc: Hugh Dickins
> Cc: Dan Magenheimer
> Cc: Seth Jennings
> Cc: Nitin Gupta
> Cc: Konrad Rzeszutek Wilk
> Cc: Shaohua Li
> Signed-off-by: Minchan Kim
> ---
> include/linux/swap.h | 11 ---
> mm/memory.c | 3 ++-
> mm/swapfile.c| 11 +++
> mm/vmscan.c | 2 +-
> 4 files changed, 18 insertions(+), 9 deletions(-)
>
> diff --git a/include/linux/swap.h b/include/linux/swap.h
> index 2818a12..1f4df66 100644
> --- a/include/linux/swap.h
> +++ b/include/linux/swap.h
> @@ -359,9 +359,14 @@ extern struct page *swapin_readahead(swp_entry_t, gfp_t,
> extern atomic_long_t nr_swap_pages;
> extern long total_swap_pages;
>
> -/* Swap 50% full? Release swapcache more aggressively.. */
> -static inline bool vm_swap_full(void)
> +/*
> + * Swap 50% full or fast backed device?
> + * Release swapcache more aggressively.
> + */
> +static inline bool vm_swap_full(struct swap_info_struct *si)
> {
> + if (si->flags & SWP_SOLIDSTATE)
> + return true;
> return atomic_long_read(_swap_pages) * 2 < total_swap_pages;
> }
>
> @@ -405,7 +410,7 @@ mem_cgroup_uncharge_swapcache(struct page *page,
> swp_entry_t ent, bool swapout)
> #define get_nr_swap_pages()0L
> #define total_swap_pages 0L
> #define total_swapcache_pages()0UL
> -#define vm_swap_full() 0
> +#define vm_swap_full(si) 0
>
> #define si_swapinfo(val) \
> do { (val)->freeswap = (val)->totalswap = 0; } while (0)
> diff --git a/mm/memory.c b/mm/memory.c
> index 705473a..1ca21a9 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -3084,7 +3084,8 @@ static int do_swap_page(struct mm_struct *mm, struct
> vm_area_struct *vma,
> mem_cgroup_commit_charge_swapin(page, ptr);
>
> swap_free(entry);
> - if (vm_swap_full() || (vma->vm_flags & VM_LOCKED) ||
> PageMlocked(page))
> + if (likely(PageSwapCache(page)) && (vm_swap_full(page_swap_info(page))
> + || (vma->vm_flags & VM_LOCKED) || PageMlocked(page)))
> try_to_free_swap(page);
> unlock_page(page);
> if (page != swapcache) {
> diff --git a/mm/swapfile.c b/mm/swapfile.c
> index 1bee6fa..f9cc701 100644
> --- a/mm/swapfile.c
> +++ b/mm/swapfile.c
> @@ -293,7 +293,7 @@ checks:
> scan_base = offset = si->lowest_bit;
>
> /* reuse swap entry of cache-only swap if not busy. */
> - if (vm_swap_full() && si->swap_map[offset] == SWAP_HAS_CACHE) {
> + if (vm_swap_full(si) && si->swap_map[offset] == SWAP_HAS_CACHE) {
> int swap_was_freed;
> spin_unlock(>lock);
> swap_was_freed = __try_to_reclaim_swap(si, offset);
> @@ -382,7 +382,8 @@ scan:
> spin_lock(>lock);
> goto checks;
> }
> - if (vm_swap_full() && si->swap_map[offset] == SWAP_HAS_CACHE)
> {
> + if (vm_swap_full(si) &&
> + si->swap_map[offset] == SWAP_HAS_
Re: [RFC] mm: remove swapcache page early
Hi,
On Wed, Mar 27, 2013 at 11:22 AM, Minchan Kim minc...@kernel.org wrote:
Swap subsystem does lazy swap slot free with expecting the page
would be swapped out again so we can't avoid unnecessary write.
But the problem in in-memory swap is that it consumes memory space
until vm_swap_full(ie, used half of all of swap device) condition
meet. It could be bad if we use multiple swap device, small in-memory swap
and big storage swap or in-memory swap alone.
This patch changes vm_swap_full logic slightly so it could free
swap slot early if the backed device is really fast.
For it, I used SWP_SOLIDSTATE but It might be controversial.
So let's add Ccing Shaohua and Hugh.
If it's a problem for SSD, I'd like to create new type SWP_INMEMORY
or something for z* family.
I perfer to add new SWP_INMEMORY for z* family. as you know SSD and
memory is different characteristics.
and if new type is added, it doesn't need to modify lots of codes.
Do you have any data for it? do you get meaningful performance gain or
efficiency of z* family? If yes, please share it.
Thank you,
Kyungmin Park
Other problem is zram is block device so that it can set SWP_INMEMORY
or SWP_SOLIDSTATE easily(ie, actually, zram is already done) but
I have no idea to use it for frontswap.
Any idea?
Other optimize point is we remove it unconditionally when we
found it's exclusive when swap in happen.
It could help frontswap family, too.
What do you think about it?
Cc: Hugh Dickins hu...@google.com
Cc: Dan Magenheimer dan.magenhei...@oracle.com
Cc: Seth Jennings sjenn...@linux.vnet.ibm.com
Cc: Nitin Gupta ngu...@vflare.org
Cc: Konrad Rzeszutek Wilk kon...@darnok.org
Cc: Shaohua Li s...@kernel.org
Signed-off-by: Minchan Kim minc...@kernel.org
---
include/linux/swap.h | 11 ---
mm/memory.c | 3 ++-
mm/swapfile.c| 11 +++
mm/vmscan.c | 2 +-
4 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/include/linux/swap.h b/include/linux/swap.h
index 2818a12..1f4df66 100644
--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -359,9 +359,14 @@ extern struct page *swapin_readahead(swp_entry_t, gfp_t,
extern atomic_long_t nr_swap_pages;
extern long total_swap_pages;
-/* Swap 50% full? Release swapcache more aggressively.. */
-static inline bool vm_swap_full(void)
+/*
+ * Swap 50% full or fast backed device?
+ * Release swapcache more aggressively.
+ */
+static inline bool vm_swap_full(struct swap_info_struct *si)
{
+ if (si-flags SWP_SOLIDSTATE)
+ return true;
return atomic_long_read(nr_swap_pages) * 2 total_swap_pages;
}
@@ -405,7 +410,7 @@ mem_cgroup_uncharge_swapcache(struct page *page,
swp_entry_t ent, bool swapout)
#define get_nr_swap_pages()0L
#define total_swap_pages 0L
#define total_swapcache_pages()0UL
-#define vm_swap_full() 0
+#define vm_swap_full(si) 0
#define si_swapinfo(val) \
do { (val)-freeswap = (val)-totalswap = 0; } while (0)
diff --git a/mm/memory.c b/mm/memory.c
index 705473a..1ca21a9 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -3084,7 +3084,8 @@ static int do_swap_page(struct mm_struct *mm, struct
vm_area_struct *vma,
mem_cgroup_commit_charge_swapin(page, ptr);
swap_free(entry);
- if (vm_swap_full() || (vma-vm_flags VM_LOCKED) ||
PageMlocked(page))
+ if (likely(PageSwapCache(page)) (vm_swap_full(page_swap_info(page))
+ || (vma-vm_flags VM_LOCKED) || PageMlocked(page)))
try_to_free_swap(page);
unlock_page(page);
if (page != swapcache) {
diff --git a/mm/swapfile.c b/mm/swapfile.c
index 1bee6fa..f9cc701 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -293,7 +293,7 @@ checks:
scan_base = offset = si-lowest_bit;
/* reuse swap entry of cache-only swap if not busy. */
- if (vm_swap_full() si-swap_map[offset] == SWAP_HAS_CACHE) {
+ if (vm_swap_full(si) si-swap_map[offset] == SWAP_HAS_CACHE) {
int swap_was_freed;
spin_unlock(si-lock);
swap_was_freed = __try_to_reclaim_swap(si, offset);
@@ -382,7 +382,8 @@ scan:
spin_lock(si-lock);
goto checks;
}
- if (vm_swap_full() si-swap_map[offset] == SWAP_HAS_CACHE)
{
+ if (vm_swap_full(si)
+ si-swap_map[offset] == SWAP_HAS_CACHE) {
spin_lock(si-lock);
goto checks;
}
@@ -397,7 +398,8 @@ scan:
spin_lock(si-lock);
goto checks;
}
- if (vm_swap_full() si-swap_map[offset] == SWAP_HAS_CACHE)
{
+ if (vm_swap_full(si)
+ si
Re: [PATCH] ARM: EXYNOS: Keep USB related LDOs always active on Origen
Hi,
On Fri, Feb 22, 2013 at 3:48 PM, Tushar Behera wrote:
> LDO3 and LDO8 are used for powering both device and host phy controllers.
> These regulators are not handled in USB host driver. Hence we get
> unexpected behaviour when the regulators are disabled elsewhere.
>
> It would be best to keep these regulators always on.
No, it's just workaround patch.
It should be handled at USB drivers.
we usually used this scheme enable USB power always. but it consumes
lots of power.
There's no need to enable usb power when there's no usb connection.
So I suggest to enable power when usb is connected only.
In our case, micro IC detects the usb connection and enable usb power
at that time.
Thank you,
Kyungmin Park
>
> Signed-off-by: Tushar Behera
> ---
>
> Based on v3.8.
>
> arch/arm/mach-exynos/mach-origen.c |2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/mach-origen.c
> b/arch/arm/mach-exynos/mach-origen.c
> index 5e34b9c..7351063 100644
> --- a/arch/arm/mach-exynos/mach-origen.c
> +++ b/arch/arm/mach-exynos/mach-origen.c
> @@ -169,6 +169,7 @@ static struct regulator_init_data __initdata
> max8997_ldo3_data = {
> .min_uV = 110,
> .max_uV = 110,
> .apply_uV = 1,
> + .always_on = 1,
> .valid_ops_mask = REGULATOR_CHANGE_STATUS,
> .state_mem = {
> .disabled = 1,
> @@ -227,6 +228,7 @@ static struct regulator_init_data __initdata
> max8997_ldo8_data = {
> .min_uV = 330,
> .max_uV = 330,
> .apply_uV = 1,
> + .always_on = 1,
> .valid_ops_mask = REGULATOR_CHANGE_STATUS,
> .state_mem = {
> .disabled = 1,
> --
> 1.7.4.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: EXYNOS: Keep USB related LDOs always active on Origen
Hi,
On Fri, Feb 22, 2013 at 3:48 PM, Tushar Behera tushar.beh...@linaro.org wrote:
LDO3 and LDO8 are used for powering both device and host phy controllers.
These regulators are not handled in USB host driver. Hence we get
unexpected behaviour when the regulators are disabled elsewhere.
It would be best to keep these regulators always on.
No, it's just workaround patch.
It should be handled at USB drivers.
we usually used this scheme enable USB power always. but it consumes
lots of power.
There's no need to enable usb power when there's no usb connection.
So I suggest to enable power when usb is connected only.
In our case, micro IC detects the usb connection and enable usb power
at that time.
Thank you,
Kyungmin Park
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
Based on v3.8.
arch/arm/mach-exynos/mach-origen.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-exynos/mach-origen.c
b/arch/arm/mach-exynos/mach-origen.c
index 5e34b9c..7351063 100644
--- a/arch/arm/mach-exynos/mach-origen.c
+++ b/arch/arm/mach-exynos/mach-origen.c
@@ -169,6 +169,7 @@ static struct regulator_init_data __initdata
max8997_ldo3_data = {
.min_uV = 110,
.max_uV = 110,
.apply_uV = 1,
+ .always_on = 1,
.valid_ops_mask = REGULATOR_CHANGE_STATUS,
.state_mem = {
.disabled = 1,
@@ -227,6 +228,7 @@ static struct regulator_init_data __initdata
max8997_ldo8_data = {
.min_uV = 330,
.max_uV = 330,
.apply_uV = 1,
+ .always_on = 1,
.valid_ops_mask = REGULATOR_CHANGE_STATUS,
.state_mem = {
.disabled = 1,
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: cma: fix accounting of CMA pages placed in high memory
On Tue, Feb 19, 2013 at 10:27 PM, Simon Jeons wrote: > On 02/05/2013 03:10 PM, Marek Szyprowski wrote: >> >> Hello, >> >> On 2/5/2013 12:34 AM, Minchan Kim wrote: >>> >>> On Mon, Feb 04, 2013 at 11:27:05AM +0100, Marek Szyprowski wrote: >>> > The total number of low memory pages is determined as >>> > totalram_pages - totalhigh_pages, so without this patch all CMA >>> > pageblocks placed in highmem were accounted to low memory. >>> >>> So what's the end user effect? With the effect, we have to decide >>> routing it on stable. >>> >>> > >>> > Signed-off-by: Marek Szyprowski >>> > --- >>> > mm/page_alloc.c |4 >>> > 1 file changed, 4 insertions(+) >>> > >>> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c >>> > index f5bab0a..6415d93 100644 >>> > --- a/mm/page_alloc.c >>> > +++ b/mm/page_alloc.c >>> > @@ -773,6 +773,10 @@ void __init init_cma_reserved_pageblock(struct >>> > page *page) >>> > set_pageblock_migratetype(page, MIGRATE_CMA); >>> > __free_pages(page, pageblock_order); >>> > totalram_pages += pageblock_nr_pages; >>> > +#ifdef CONFIG_HIGHMEM >>> >>> We don't need #ifdef/#endif. >> >> >> #ifdef is required to let this code compile when highmem is not enabled, >> becuase totalhigh_pages is defined as 0, see include/linux/highmem.h >> > > Hi Marek, > > 1) Why can support CMA regions placed in highmem? Some vendors use reserved memory at highmem, and it's hard to modify to use lowmem, so just CMA can support highmem and no need to adjust address used at reserved memory. > CMA is for dma buffer, correct? Then how can old dma device access highmem? What's the "old dma device"? To support it, we also modify arch/arm/mm/dma-mapping.c for handling highmem address. > 2) Why there is no totalhigh_pages variable define in the case of config > highmem? I don't know. it's just defined in case of highmem. that's reason to use #ifdef/endif. we don't know hisotrical reason. Thank you, Kyungmin Park > > >>> > +if (PageHighMem(page)) >>> > +totalhigh_pages += pageblock_nr_pages; >>> > +#endif >>> > } >>> > #endif >>> > >> >> >> Best regards > > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majord...@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: mailto:"d...@kvack.org;> em...@kvack.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: cma: fix accounting of CMA pages placed in high memory
On Tue, Feb 19, 2013 at 10:27 PM, Simon Jeons simon.je...@gmail.com wrote: On 02/05/2013 03:10 PM, Marek Szyprowski wrote: Hello, On 2/5/2013 12:34 AM, Minchan Kim wrote: On Mon, Feb 04, 2013 at 11:27:05AM +0100, Marek Szyprowski wrote: The total number of low memory pages is determined as totalram_pages - totalhigh_pages, so without this patch all CMA pageblocks placed in highmem were accounted to low memory. So what's the end user effect? With the effect, we have to decide routing it on stable. Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com --- mm/page_alloc.c |4 1 file changed, 4 insertions(+) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index f5bab0a..6415d93 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -773,6 +773,10 @@ void __init init_cma_reserved_pageblock(struct page *page) set_pageblock_migratetype(page, MIGRATE_CMA); __free_pages(page, pageblock_order); totalram_pages += pageblock_nr_pages; +#ifdef CONFIG_HIGHMEM We don't need #ifdef/#endif. #ifdef is required to let this code compile when highmem is not enabled, becuase totalhigh_pages is defined as 0, see include/linux/highmem.h Hi Marek, 1) Why can support CMA regions placed in highmem? Some vendors use reserved memory at highmem, and it's hard to modify to use lowmem, so just CMA can support highmem and no need to adjust address used at reserved memory. CMA is for dma buffer, correct? Then how can old dma device access highmem? What's the old dma device? To support it, we also modify arch/arm/mm/dma-mapping.c for handling highmem address. 2) Why there is no totalhigh_pages variable define in the case of config highmem? I don't know. it's just defined in case of highmem. that's reason to use #ifdef/endif. we don't know hisotrical reason. Thank you, Kyungmin Park +if (PageHighMem(page)) +totalhigh_pages += pageblock_nr_pages; +#endif } #endif Best regards -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majord...@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: a href=mailto:d...@kvack.org; em...@kvack.org /a -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/3] drm/exynos: Get HDMI version from device tree
On Wed, Feb 6, 2013 at 9:42 AM, Stephen Warren wrote:
> On 02/05/2013 05:37 PM, Sean Paul wrote:
>> On Tue, Feb 5, 2013 at 4:22 PM, Stephen Warren wrote:
>>> n 02/05/2013 04:42 PM, Sean Paul wrote:
>>>> Use the compatible string in the device tree to determine which
>>>> registers/functions to use in the HDMI driver. Also changes the
>>>> references from v13 to 4210 and v14 to 4212 to reflect the IP
>>>> block version instead of the HDMI version.
>>>
>>>> diff --git a/Documentation/devicetree/bindings/drm/exynos/hdmi.txt
>>>> b/Documentation/devicetree/bindings/drm/exynos/hdmi.txt
>>>
>>> Binding looks sane to me.
>>>
>>>> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
>>>> b/drivers/gpu/drm/exynos/exynos_hdmi.c
>>>
>>>> #ifdef CONFIG_OF
>>>> static struct of_device_id hdmi_match_types[] = {
>>>> {
>>>> - .compatible = "samsung,exynos5-hdmi",
>>>> - .data = (void *)HDMI_TYPE14,
>>>> + .compatible = "samsung,exynos4-hdmi",
>>>> }, {
>>>> /* end node */
>>>> }
>>>
>>> Why not fill in all the "base" compatible values there (I think you need
>>> this anyway so that DTs don't all have to be compatible with
>>> samsung,exynos4-hdmi), with .data containing the HDMI_VER_EXYNOS*
>>> values, then ...
>>>
>>
>> At the moment, all DTs have to be compatible with exynos4-hdmi since
>> it provides the base for the current driver. The driver uses 4210 and
>> 4212 to differentiate between different register addresses and
>> features, but most things are just exynos4-hdmi compatible.
I would like to distinguish between 4210 and 4x12. since it has
different features. e.g., HDMI v1.3 and v1.4.
and I also want to use 4412 instead of 4212. there's no board to use
4212 at mainline until this time.
Thank you,
Kyungmin Park
>
> The DT nodes should include only the compatible values that the HW is
> actually compatible with. If the HW isn't compatible with exynos4-hdmi,
> that value shouldn't be in the compatible property, but instead whatever
> the "base" value that the HW really is compatible with. The driver can
> support multiple "base" compatible values from this table.
>
>>>> @@ -2218,17 +2217,18 @@ static int hdmi_probe(struct platform_device *pdev)
>>>
>>>> +
>>>> + if (of_device_is_compatible(dev->of_node, "samsung,exynos4210-hdmi"))
>>>> + hdata->version |= HDMI_VER_EXYNOS4210;
>>>> + if (of_device_is_compatible(dev->of_node, "samsung,exynos4212-hdmi"))
>>>> + hdata->version |= HDMI_VER_EXYNOS4212;
>>>> + if (of_device_is_compatible(dev->of_node, "samsung,exynos5250-hdmi"))
>>>> + hdata->version |= HDMI_VER_EXYNOS5250;
>>>
>>> Instead of that, do roughly:
>>>
>>> match = of_match_device(hdmi_match_types, >dev);
>>> if (match)
>>> hdata->version |= (int)match->data;
>>>
>>> That way, it's all table-based. Any future additions to
>>> hdmi_match_types[] won't require another if statement to be added to
>>> probe().
>>
>> I don't think it's that easy. of_match_device returns the first match
>> from the device table, so I'd still need to iterate through the
>> matches. I could still break this out into a table, but I don't think
>> of_match_device is the right way to probe it.
>
> You shouldn't have to iterate over multiple matches. of_match_device()
> is supposed to return the match for the first entry in the compatible
> property, then if there was no match, move on to looking at the next
> entry in the compatible property, etc. In practice, I think it's still
> not implemented quite correctly for this, but you can make it work by
> putting the newest compatible value first in the match table.
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/3] drm/exynos: Get HDMI version from device tree
On Wed, Feb 6, 2013 at 9:42 AM, Stephen Warren swar...@wwwdotorg.org wrote:
On 02/05/2013 05:37 PM, Sean Paul wrote:
On Tue, Feb 5, 2013 at 4:22 PM, Stephen Warren swar...@wwwdotorg.org wrote:
n 02/05/2013 04:42 PM, Sean Paul wrote:
Use the compatible string in the device tree to determine which
registers/functions to use in the HDMI driver. Also changes the
references from v13 to 4210 and v14 to 4212 to reflect the IP
block version instead of the HDMI version.
diff --git a/Documentation/devicetree/bindings/drm/exynos/hdmi.txt
b/Documentation/devicetree/bindings/drm/exynos/hdmi.txt
Binding looks sane to me.
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
#ifdef CONFIG_OF
static struct of_device_id hdmi_match_types[] = {
{
- .compatible = samsung,exynos5-hdmi,
- .data = (void *)HDMI_TYPE14,
+ .compatible = samsung,exynos4-hdmi,
}, {
/* end node */
}
Why not fill in all the base compatible values there (I think you need
this anyway so that DTs don't all have to be compatible with
samsung,exynos4-hdmi), with .data containing the HDMI_VER_EXYNOS*
values, then ...
At the moment, all DTs have to be compatible with exynos4-hdmi since
it provides the base for the current driver. The driver uses 4210 and
4212 to differentiate between different register addresses and
features, but most things are just exynos4-hdmi compatible.
I would like to distinguish between 4210 and 4x12. since it has
different features. e.g., HDMI v1.3 and v1.4.
and I also want to use 4412 instead of 4212. there's no board to use
4212 at mainline until this time.
Thank you,
Kyungmin Park
The DT nodes should include only the compatible values that the HW is
actually compatible with. If the HW isn't compatible with exynos4-hdmi,
that value shouldn't be in the compatible property, but instead whatever
the base value that the HW really is compatible with. The driver can
support multiple base compatible values from this table.
@@ -2218,17 +2217,18 @@ static int hdmi_probe(struct platform_device *pdev)
+
+ if (of_device_is_compatible(dev-of_node, samsung,exynos4210-hdmi))
+ hdata-version |= HDMI_VER_EXYNOS4210;
+ if (of_device_is_compatible(dev-of_node, samsung,exynos4212-hdmi))
+ hdata-version |= HDMI_VER_EXYNOS4212;
+ if (of_device_is_compatible(dev-of_node, samsung,exynos5250-hdmi))
+ hdata-version |= HDMI_VER_EXYNOS5250;
Instead of that, do roughly:
match = of_match_device(hdmi_match_types, pdev-dev);
if (match)
hdata-version |= (int)match-data;
That way, it's all table-based. Any future additions to
hdmi_match_types[] won't require another if statement to be added to
probe().
I don't think it's that easy. of_match_device returns the first match
from the device table, so I'd still need to iterate through the
matches. I could still break this out into a table, but I don't think
of_match_device is the right way to probe it.
You shouldn't have to iterate over multiple matches. of_match_device()
is supposed to return the match for the first entry in the compatible
property, then if there was no match, move on to looking at the next
entry in the compatible property, etc. In practice, I think it's still
not implemented quite correctly for this, but you can make it work by
putting the newest compatible value first in the match table.
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: phy: Add USB host phy support on Exyno4412
Hi,
Can split patch into two parts?
One for USB tree, another for samsung tree.
Thank you,
Kyungmin Park
On Tue, Feb 5, 2013 at 9:37 AM, Dongjin Kim wrote:
> This patch adds host phy support for Samsung's Exynos4412 SoC to
> samsung-usbphy driver and its device node.
>
> Cc: Praveen Paneri
> Signed-off-by: Dongjin Kim
> ---
> arch/arm/boot/dts/exynos4412.dtsi | 13
> drivers/usb/phy/samsung-usbphy.c | 156
> -
> 2 files changed, 167 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos4412.dtsi
> b/arch/arm/boot/dts/exynos4412.dtsi
> index 387aa27..c01d841 100644
> --- a/arch/arm/boot/dts/exynos4412.dtsi
> +++ b/arch/arm/boot/dts/exynos4412.dtsi
> @@ -33,4 +33,17 @@
> #address-cells = <1>;
> #size-cells = <0>;
> };
> +
> + usbphy@125B {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "samsung,exynos4412-usbphy";
> + reg = <0x125B 0x100>;
> + status = "disabled";
> + ranges;
> +
> + usbphy-sys {
> + reg = <0x10020704 0xc>;
> + };
> + };
> };
> diff --git a/drivers/usb/phy/samsung-usbphy.c
> b/drivers/usb/phy/samsung-usbphy.c
> index 6ea5537..c800fa4 100644
> --- a/drivers/usb/phy/samsung-usbphy.c
> +++ b/drivers/usb/phy/samsung-usbphy.c
> @@ -47,7 +47,7 @@
>
> #define PHYCLK_MODE_USB11 (0x1 << 6)
> #define PHYCLK_EXT_OSC (0x1 << 5)
> -#define PHYCLK_COMMON_ON_N (0x1 << 4)
> +#define PHYCLK_COMMON_ON_N_PHY0(0x1 << 4)
> #define PHYCLK_ID_PULL (0x1 << 2)
> #define PHYCLK_CLKSEL_MASK (0x3 << 0)
> #define PHYCLK_CLKSEL_48M (0x0 << 0)
> @@ -60,6 +60,22 @@
> #define RSTCON_HLINK_SWRST (0x1 << 1)
> #define RSTCON_SWRST (0x1 << 0)
>
> +/* For Exynos4412 */
> +#define PHYCLK_COMMON_ON_N_PHY1(0x1 << 7)
> +
> +#define PHYPWR_NORMAL_MASK_HSIC1 (0x7 << 12)
> +#define PHYPWR_NORMAL_MASK_HSIC0 (0x7 << 9)
> +#define PHYPWR_NORMAL_MASK_PHY1(0x7 << 6)
> +
> +#define PHYPWR_ANALOG_POWERDOWN_PHY1 (0x1 << 7)
> +
> +#define RSTCON_HLINK_SWRST_MASK(0xf << 7)
> +#define RSTCON_PHY1_SWRST_MASK (0xf << 3)
> +#define RSTCON_PHY0_SWRST_MASK (0x7 << 0)
> +
> +#define EXYNOS4_PHY_HSIC_CTRL0 (0x04)
> +#define EXYNOS4_PHY_HSIC_CTRL1 (0x08)
> +
> /* EXYNOS5 */
> #define EXYNOS5_PHY_HOST_CTRL0 (0x00)
>
> @@ -174,6 +190,7 @@
> enum samsung_cpu_type {
> TYPE_S3C64XX,
> TYPE_EXYNOS4210,
> + TYPE_EXYNOS4412,
> TYPE_EXYNOS5250,
> };
>
> @@ -322,6 +339,17 @@ static void samsung_usbphy_set_isolation(struct
> samsung_usbphy *sphy, bool on)
> en_mask = sphy->drv_data->hostphy_en_mask;
> }
> break;
> + case TYPE_EXYNOS4412:
> + if (sphy->phy_type == USB_PHY_TYPE_DEVICE) {
> + reg = sphy->pmuregs +
> + sphy->drv_data->devphy_reg_offset;
> + en_mask = sphy->drv_data->devphy_en_mask;
> + } else if (sphy->phy_type == USB_PHY_TYPE_HOST) {
> + reg = sphy->pmuregs +
> + sphy->drv_data->hostphy_reg_offset;
> + en_mask = sphy->drv_data->hostphy_en_mask;
> + }
> + break;
> default:
> dev_err(sphy->dev, "Invalid SoC type\n");
> return;
> @@ -422,6 +450,29 @@ static int samsung_usbphy_get_refclk_freq(struct
> samsung_usbphy *sphy)
> refclk_freq = FSEL_CLKSEL_24M;
> break;
> }
> + } else if (sphy->drv_data->cpu_type == TYPE_EXYNOS4412) {
> + switch (clk_get_rate(ref_clk)) {
> + case 9600 * KHZ:
> + refclk_freq = FSEL_CLKSEL_9600K;
> + break;
> + case 10 * MHZ:
> + refclk_freq = FSEL_CLKSEL_10M;
> + b
Re: [PATCH] mm: cma: fix accounting of CMA pages placed in high memory
Hi,
On Tue, Feb 5, 2013 at 8:43 AM, Minchan Kim wrote:
> Hello,
>
> On Tue, Feb 05, 2013 at 08:29:26AM +0900, Kyungmin Park wrote:
>> On Tue, Feb 5, 2013 at 8:06 AM, Andrew Morton
>> wrote:
>> > On Mon, 04 Feb 2013 11:27:05 +0100
>> > Marek Szyprowski wrote:
>> >
>> >> The total number of low memory pages is determined as
>> >> totalram_pages - totalhigh_pages, so without this patch all CMA
>> >> pageblocks placed in highmem were accounted to low memory.
>> >
>> > What are the end-user-visible effects of this bug?
>>
>> Even though CMA is located at highmem. LowTotal has more than lowmem
>> address spaces.
>>
>> e.g.,
>> lowmem : 0xc000 - 0xdf00 ( 496 MB)
>> LowTotal: 555788 kB
>>
>> >
>> > (This information is needed so that others can make patch-scheduling
>> > decisions and should be included in all bugfix changelogs unless it is
>> > obvious).
>>
>> CMA Highmem support is new feature. so don't need to go stable tree.
>
> I would like to clarify it because I remembered alloc_migrate_target have
> considered
> CMA pages could be highmem. Is it really new feature? If so, could you point
> out
> enabling patches for the new feature?
>
Here's related patch.
http://www.spinics.net/lists/arm-kernel/msg222369.html
Previous time, it's not fully tested and now we checked it with
highmem support patches.
Thank you,
Kyungmin Park
> struct page *alloc_migrate_target(struct page *page, unsigned long private,
> int **resultp)
> {
> gfp_t gfp_mask = GFP_USER | __GFP_MOVABLE;
>
> if (PageHighMem(page))
> gfp_mask |= __GFP_HIGHMEM;
>
> return alloc_page(gfp_mask);
> }
>
> Thanks.
>
>>
>> Thank you,
>> Kyungmin Park
>> >
>> > --
>> > To unsubscribe, send a message with 'unsubscribe linux-mm' in
>> > the body to majord...@kvack.org. For more info on Linux MM,
>> > see: http://www.linux-mm.org/ .
>> > Don't email: mailto:"d...@kvack.org;> em...@kvack.org
>>
>> --
>> To unsubscribe, send a message with 'unsubscribe linux-mm' in
>> the body to majord...@kvack.org. For more info on Linux MM,
>> see: http://www.linux-mm.org/ .
>> Don't email: mailto:"d...@kvack.org;> em...@kvack.org
>
> --
> Kind regards,
> Minchan Kim
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i2c: busses/i2c-pxa.c: fix potential null pointer dereference error
Hi, On Tue, Feb 5, 2013 at 7:11 AM, Cong Ding wrote: > If it goes to eclk through line 1107, the variable res would be NULL. It will > cause a null pointer dereference error if we call release_mem_region. > > Signed-off-by: Cong Ding > --- > drivers/i2c/busses/i2c-pxa.c |3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c > index 1034d93..eadf1a4 100644 > --- a/drivers/i2c/busses/i2c-pxa.c > +++ b/drivers/i2c/busses/i2c-pxa.c > @@ -1211,7 +1211,8 @@ eremap: > eclk: > kfree(i2c); > emalloc: > - release_mem_region(res->start, resource_size(res)); > + if (!res) if (res)? It's not match with description. and it seems wrong. Thank you, Kyungmin Park > + release_mem_region(res->start, resource_size(res)); > return ret; > } > > -- > 1.7.9.5 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: cma: fix accounting of CMA pages placed in high memory
On Tue, Feb 5, 2013 at 8:06 AM, Andrew Morton wrote: > On Mon, 04 Feb 2013 11:27:05 +0100 > Marek Szyprowski wrote: > >> The total number of low memory pages is determined as >> totalram_pages - totalhigh_pages, so without this patch all CMA >> pageblocks placed in highmem were accounted to low memory. > > What are the end-user-visible effects of this bug? Even though CMA is located at highmem. LowTotal has more than lowmem address spaces. e.g., lowmem : 0xc000 - 0xdf00 ( 496 MB) LowTotal: 555788 kB > > (This information is needed so that others can make patch-scheduling > decisions and should be included in all bugfix changelogs unless it is > obvious). CMA Highmem support is new feature. so don't need to go stable tree. Thank you, Kyungmin Park > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majord...@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: mailto:"d...@kvack.org;> em...@kvack.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: cma: fix accounting of CMA pages placed in high memory
On Tue, Feb 5, 2013 at 8:06 AM, Andrew Morton a...@linux-foundation.org wrote: On Mon, 04 Feb 2013 11:27:05 +0100 Marek Szyprowski m.szyprow...@samsung.com wrote: The total number of low memory pages is determined as totalram_pages - totalhigh_pages, so without this patch all CMA pageblocks placed in highmem were accounted to low memory. What are the end-user-visible effects of this bug? Even though CMA is located at highmem. LowTotal has more than lowmem address spaces. e.g., lowmem : 0xc000 - 0xdf00 ( 496 MB) LowTotal: 555788 kB (This information is needed so that others can make patch-scheduling decisions and should be included in all bugfix changelogs unless it is obvious). CMA Highmem support is new feature. so don't need to go stable tree. Thank you, Kyungmin Park -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majord...@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: a href=mailto:d...@kvack.org; em...@kvack.org /a -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i2c: busses/i2c-pxa.c: fix potential null pointer dereference error
Hi, On Tue, Feb 5, 2013 at 7:11 AM, Cong Ding ding...@gmail.com wrote: If it goes to eclk through line 1107, the variable res would be NULL. It will cause a null pointer dereference error if we call release_mem_region. Signed-off-by: Cong Ding ding...@gmail.com --- drivers/i2c/busses/i2c-pxa.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c index 1034d93..eadf1a4 100644 --- a/drivers/i2c/busses/i2c-pxa.c +++ b/drivers/i2c/busses/i2c-pxa.c @@ -1211,7 +1211,8 @@ eremap: eclk: kfree(i2c); emalloc: - release_mem_region(res-start, resource_size(res)); + if (!res) if (res)? It's not match with description. and it seems wrong. Thank you, Kyungmin Park + release_mem_region(res-start, resource_size(res)); return ret; } -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: cma: fix accounting of CMA pages placed in high memory
Hi,
On Tue, Feb 5, 2013 at 8:43 AM, Minchan Kim minc...@kernel.org wrote:
Hello,
On Tue, Feb 05, 2013 at 08:29:26AM +0900, Kyungmin Park wrote:
On Tue, Feb 5, 2013 at 8:06 AM, Andrew Morton a...@linux-foundation.org
wrote:
On Mon, 04 Feb 2013 11:27:05 +0100
Marek Szyprowski m.szyprow...@samsung.com wrote:
The total number of low memory pages is determined as
totalram_pages - totalhigh_pages, so without this patch all CMA
pageblocks placed in highmem were accounted to low memory.
What are the end-user-visible effects of this bug?
Even though CMA is located at highmem. LowTotal has more than lowmem
address spaces.
e.g.,
lowmem : 0xc000 - 0xdf00 ( 496 MB)
LowTotal: 555788 kB
(This information is needed so that others can make patch-scheduling
decisions and should be included in all bugfix changelogs unless it is
obvious).
CMA Highmem support is new feature. so don't need to go stable tree.
I would like to clarify it because I remembered alloc_migrate_target have
considered
CMA pages could be highmem. Is it really new feature? If so, could you point
out
enabling patches for the new feature?
Here's related patch.
http://www.spinics.net/lists/arm-kernel/msg222369.html
Previous time, it's not fully tested and now we checked it with
highmem support patches.
Thank you,
Kyungmin Park
struct page *alloc_migrate_target(struct page *page, unsigned long private,
int **resultp)
{
gfp_t gfp_mask = GFP_USER | __GFP_MOVABLE;
if (PageHighMem(page))
gfp_mask |= __GFP_HIGHMEM;
return alloc_page(gfp_mask);
}
Thanks.
Thank you,
Kyungmin Park
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majord...@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: a href=mailto:d...@kvack.org; em...@kvack.org /a
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majord...@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: a href=mailto:d...@kvack.org; em...@kvack.org /a
--
Kind regards,
Minchan Kim
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majord...@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: a href=mailto:d...@kvack.org; em...@kvack.org /a
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: phy: Add USB host phy support on Exyno4412
Hi,
Can split patch into two parts?
One for USB tree, another for samsung tree.
Thank you,
Kyungmin Park
On Tue, Feb 5, 2013 at 9:37 AM, Dongjin Kim tobet...@gmail.com wrote:
This patch adds host phy support for Samsung's Exynos4412 SoC to
samsung-usbphy driver and its device node.
Cc: Praveen Paneri p.pan...@samsung.com
Signed-off-by: Dongjin Kim tobet...@gmail.com
---
arch/arm/boot/dts/exynos4412.dtsi | 13
drivers/usb/phy/samsung-usbphy.c | 156
-
2 files changed, 167 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4412.dtsi
b/arch/arm/boot/dts/exynos4412.dtsi
index 387aa27..c01d841 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -33,4 +33,17 @@
#address-cells = 1;
#size-cells = 0;
};
+
+ usbphy@125B {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = samsung,exynos4412-usbphy;
+ reg = 0x125B 0x100;
+ status = disabled;
+ ranges;
+
+ usbphy-sys {
+ reg = 0x10020704 0xc;
+ };
+ };
};
diff --git a/drivers/usb/phy/samsung-usbphy.c
b/drivers/usb/phy/samsung-usbphy.c
index 6ea5537..c800fa4 100644
--- a/drivers/usb/phy/samsung-usbphy.c
+++ b/drivers/usb/phy/samsung-usbphy.c
@@ -47,7 +47,7 @@
#define PHYCLK_MODE_USB11 (0x1 6)
#define PHYCLK_EXT_OSC (0x1 5)
-#define PHYCLK_COMMON_ON_N (0x1 4)
+#define PHYCLK_COMMON_ON_N_PHY0(0x1 4)
#define PHYCLK_ID_PULL (0x1 2)
#define PHYCLK_CLKSEL_MASK (0x3 0)
#define PHYCLK_CLKSEL_48M (0x0 0)
@@ -60,6 +60,22 @@
#define RSTCON_HLINK_SWRST (0x1 1)
#define RSTCON_SWRST (0x1 0)
+/* For Exynos4412 */
+#define PHYCLK_COMMON_ON_N_PHY1(0x1 7)
+
+#define PHYPWR_NORMAL_MASK_HSIC1 (0x7 12)
+#define PHYPWR_NORMAL_MASK_HSIC0 (0x7 9)
+#define PHYPWR_NORMAL_MASK_PHY1(0x7 6)
+
+#define PHYPWR_ANALOG_POWERDOWN_PHY1 (0x1 7)
+
+#define RSTCON_HLINK_SWRST_MASK(0xf 7)
+#define RSTCON_PHY1_SWRST_MASK (0xf 3)
+#define RSTCON_PHY0_SWRST_MASK (0x7 0)
+
+#define EXYNOS4_PHY_HSIC_CTRL0 (0x04)
+#define EXYNOS4_PHY_HSIC_CTRL1 (0x08)
+
/* EXYNOS5 */
#define EXYNOS5_PHY_HOST_CTRL0 (0x00)
@@ -174,6 +190,7 @@
enum samsung_cpu_type {
TYPE_S3C64XX,
TYPE_EXYNOS4210,
+ TYPE_EXYNOS4412,
TYPE_EXYNOS5250,
};
@@ -322,6 +339,17 @@ static void samsung_usbphy_set_isolation(struct
samsung_usbphy *sphy, bool on)
en_mask = sphy-drv_data-hostphy_en_mask;
}
break;
+ case TYPE_EXYNOS4412:
+ if (sphy-phy_type == USB_PHY_TYPE_DEVICE) {
+ reg = sphy-pmuregs +
+ sphy-drv_data-devphy_reg_offset;
+ en_mask = sphy-drv_data-devphy_en_mask;
+ } else if (sphy-phy_type == USB_PHY_TYPE_HOST) {
+ reg = sphy-pmuregs +
+ sphy-drv_data-hostphy_reg_offset;
+ en_mask = sphy-drv_data-hostphy_en_mask;
+ }
+ break;
default:
dev_err(sphy-dev, Invalid SoC type\n);
return;
@@ -422,6 +450,29 @@ static int samsung_usbphy_get_refclk_freq(struct
samsung_usbphy *sphy)
refclk_freq = FSEL_CLKSEL_24M;
break;
}
+ } else if (sphy-drv_data-cpu_type == TYPE_EXYNOS4412) {
+ switch (clk_get_rate(ref_clk)) {
+ case 9600 * KHZ:
+ refclk_freq = FSEL_CLKSEL_9600K;
+ break;
+ case 10 * MHZ:
+ refclk_freq = FSEL_CLKSEL_10M;
+ break;
+ case 12 * MHZ:
+ refclk_freq = FSEL_CLKSEL_12M;
+ break;
+ case 19200 * KHZ:
+ refclk_freq = FSEL_CLKSEL_19200K;
+ break;
+ case 20 * MHZ:
+ refclk_freq = FSEL_CLKSEL_20M;
+ break;
+ case 24 * MHZ:
+ default:
+ /* default reference clock */
+ refclk_freq = FSEL_CLKSEL_24M;
+ break;
+ }
} else {
switch (clk_get_rate(ref_clk)) {
case 12 * MHZ
Re: [PATCH] I2C: EXYNOS: Add slave support to i2c
Hi,
On Mon, Dec 3, 2012 at 9:16 PM, Giridhar Maruthy
wrote:
> This patch adds slave support to i2c. The dt entry i2c-mode
> decides at probe time if the controller needs to work in
> slave mode and the controller is accordingly programmed.
>
> Signed-off-by: Giridhar Maruthy
> ---
> drivers/i2c/busses/i2c-s3c2410.c | 100
> ++
> 1 file changed, 68 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-s3c2410.c
> b/drivers/i2c/busses/i2c-s3c2410.c
> index e93e7d6..d83a6d7 100644
> --- a/drivers/i2c/busses/i2c-s3c2410.c
> +++ b/drivers/i2c/busses/i2c-s3c2410.c
> @@ -53,6 +53,9 @@
> /* Max time to wait for bus to become idle after a xfer (in us) */
> #define S3C2410_IDLE_TIMEOUT 5000
>
> +/* To find the master/slave mode of current controller */
> +#define is_master(i2c) (!i2c->i2c_mode)
> +
> /* i2c controller state */
> enum s3c24xx_i2c_state {
> STATE_IDLE,
> @@ -89,6 +92,8 @@ struct s3c24xx_i2c {
> #ifdef CONFIG_CPU_FREQ
> struct notifier_block freq_transition;
> #endif
> + /* i2c_mode: 0 is for master; and 1 is for slave */
> + unsigned inti2c_mode;
If it's used for master or not, doesn't better to use 'is_master' or
'is_slave'? what's the meaning of 'i2c_mode'?
and
#define is_master(i2c) (i2c->is_master)
Thank you,
Kyungmin Park
> };
>
> static struct platform_device_id s3c24xx_driver_ids[] = {
> @@ -202,11 +207,21 @@ static void s3c24xx_i2c_message_start(struct
> s3c24xx_i2c *i2c,
> stat = 0;
> stat |= S3C2410_IICSTAT_TXRXEN;
>
> - if (msg->flags & I2C_M_RD) {
> - stat |= S3C2410_IICSTAT_MASTER_RX;
> - addr |= 1;
> - } else
> - stat |= S3C2410_IICSTAT_MASTER_TX;
> + if (is_master(i2c)) {
> + /* Master mode */
> + if (msg->flags & I2C_M_RD) {
> + stat |= S3C2410_IICSTAT_MASTER_RX;
> + addr |= 1;
> + } else
> + stat |= S3C2410_IICSTAT_MASTER_TX;
> + } else {
> + /* Slave mode */
> + if (msg->flags & I2C_M_RD) {
> + stat |= S3C2410_IICSTAT_SLAVE_RX;
> + addr |= 1;
> + } else
> + stat |= S3C2410_IICSTAT_SLAVE_TX;
> + }
>
> if (msg->flags & I2C_M_REV_DIR_ADDR)
> addr ^= 1;
> @@ -228,8 +243,10 @@ static void s3c24xx_i2c_message_start(struct
> s3c24xx_i2c *i2c,
> dev_dbg(i2c->dev, "iiccon, %08lx\n", iiccon);
> writel(iiccon, i2c->regs + S3C2410_IICCON);
>
> - stat |= S3C2410_IICSTAT_START;
> - writel(stat, i2c->regs + S3C2410_IICSTAT);
> + if (is_master(i2c)) {
> + stat |= S3C2410_IICSTAT_START;
> + writel(stat, i2c->regs + S3C2410_IICSTAT);
> + }
> }
>
> static inline void s3c24xx_i2c_stop(struct s3c24xx_i2c *i2c, int ret)
> @@ -272,14 +289,19 @@ static inline void s3c24xx_i2c_stop(struct s3c24xx_i2c
> *i2c, int ret)
> * devices, the host as Master and the HDMIPHY device as the slave.
> * Skipping the STOP condition has been tested on this bus and
> works.
> */
> - if (i2c->quirks & QUIRK_HDMIPHY) {
> - /* Stop driving the I2C pins */
> - iicstat &= ~S3C2410_IICSTAT_TXRXEN;
> - } else {
> - /* stop the transfer */
> - iicstat &= ~S3C2410_IICSTAT_START;
> + if (is_master(i2c)) {
> + if (i2c->quirks & QUIRK_HDMIPHY) {
> + /* Stop driving the I2C pins */
> + iicstat &= ~S3C2410_IICSTAT_TXRXEN;
> + } else {
> + /* stop the transfer */
> + if (is_master(i2c)) {
> + /* Start/Stop required only for master */
> + iicstat &= ~S3C2410_IICSTAT_START;
> + }
> + }
> + writel(iicstat, i2c->regs + S3C2410_IICSTAT);
> }
> - writel(iicstat, i2c->regs + S3C2410_IICSTAT);
>
> i2c->state = STATE_STOP;
>
> @@ -348,7 +370,8 @@ static int i2c_s3c_irq_nextbyte(struct s3c24xx_i2c *i2c,
> unsigned long iicstat)
> */
>
> if (iicstat & S3C2410_IICSTAT_LASTBIT &&
> - !(i2c->msg->flags & I2C_M_IGNORE_NAK)) {
> + !(i2c->msg->flags & I2C_M_IGNORE_NAK) &&
Re: [PATCH] I2C: EXYNOS: Add slave support to i2c
Hi,
On Mon, Dec 3, 2012 at 9:16 PM, Giridhar Maruthy
giridhar.maru...@linaro.org wrote:
This patch adds slave support to i2c. The dt entry i2c-mode
decides at probe time if the controller needs to work in
slave mode and the controller is accordingly programmed.
Signed-off-by: Giridhar Maruthy giridhar.maru...@linaro.org
---
drivers/i2c/busses/i2c-s3c2410.c | 100
++
1 file changed, 68 insertions(+), 32 deletions(-)
diff --git a/drivers/i2c/busses/i2c-s3c2410.c
b/drivers/i2c/busses/i2c-s3c2410.c
index e93e7d6..d83a6d7 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
@@ -53,6 +53,9 @@
/* Max time to wait for bus to become idle after a xfer (in us) */
#define S3C2410_IDLE_TIMEOUT 5000
+/* To find the master/slave mode of current controller */
+#define is_master(i2c) (!i2c-i2c_mode)
+
/* i2c controller state */
enum s3c24xx_i2c_state {
STATE_IDLE,
@@ -89,6 +92,8 @@ struct s3c24xx_i2c {
#ifdef CONFIG_CPU_FREQ
struct notifier_block freq_transition;
#endif
+ /* i2c_mode: 0 is for master; and 1 is for slave */
+ unsigned inti2c_mode;
If it's used for master or not, doesn't better to use 'is_master' or
'is_slave'? what's the meaning of 'i2c_mode'?
and
#define is_master(i2c) (i2c-is_master)
Thank you,
Kyungmin Park
};
static struct platform_device_id s3c24xx_driver_ids[] = {
@@ -202,11 +207,21 @@ static void s3c24xx_i2c_message_start(struct
s3c24xx_i2c *i2c,
stat = 0;
stat |= S3C2410_IICSTAT_TXRXEN;
- if (msg-flags I2C_M_RD) {
- stat |= S3C2410_IICSTAT_MASTER_RX;
- addr |= 1;
- } else
- stat |= S3C2410_IICSTAT_MASTER_TX;
+ if (is_master(i2c)) {
+ /* Master mode */
+ if (msg-flags I2C_M_RD) {
+ stat |= S3C2410_IICSTAT_MASTER_RX;
+ addr |= 1;
+ } else
+ stat |= S3C2410_IICSTAT_MASTER_TX;
+ } else {
+ /* Slave mode */
+ if (msg-flags I2C_M_RD) {
+ stat |= S3C2410_IICSTAT_SLAVE_RX;
+ addr |= 1;
+ } else
+ stat |= S3C2410_IICSTAT_SLAVE_TX;
+ }
if (msg-flags I2C_M_REV_DIR_ADDR)
addr ^= 1;
@@ -228,8 +243,10 @@ static void s3c24xx_i2c_message_start(struct
s3c24xx_i2c *i2c,
dev_dbg(i2c-dev, iiccon, %08lx\n, iiccon);
writel(iiccon, i2c-regs + S3C2410_IICCON);
- stat |= S3C2410_IICSTAT_START;
- writel(stat, i2c-regs + S3C2410_IICSTAT);
+ if (is_master(i2c)) {
+ stat |= S3C2410_IICSTAT_START;
+ writel(stat, i2c-regs + S3C2410_IICSTAT);
+ }
}
static inline void s3c24xx_i2c_stop(struct s3c24xx_i2c *i2c, int ret)
@@ -272,14 +289,19 @@ static inline void s3c24xx_i2c_stop(struct s3c24xx_i2c
*i2c, int ret)
* devices, the host as Master and the HDMIPHY device as the slave.
* Skipping the STOP condition has been tested on this bus and
works.
*/
- if (i2c-quirks QUIRK_HDMIPHY) {
- /* Stop driving the I2C pins */
- iicstat = ~S3C2410_IICSTAT_TXRXEN;
- } else {
- /* stop the transfer */
- iicstat = ~S3C2410_IICSTAT_START;
+ if (is_master(i2c)) {
+ if (i2c-quirks QUIRK_HDMIPHY) {
+ /* Stop driving the I2C pins */
+ iicstat = ~S3C2410_IICSTAT_TXRXEN;
+ } else {
+ /* stop the transfer */
+ if (is_master(i2c)) {
+ /* Start/Stop required only for master */
+ iicstat = ~S3C2410_IICSTAT_START;
+ }
+ }
+ writel(iicstat, i2c-regs + S3C2410_IICSTAT);
}
- writel(iicstat, i2c-regs + S3C2410_IICSTAT);
i2c-state = STATE_STOP;
@@ -348,7 +370,8 @@ static int i2c_s3c_irq_nextbyte(struct s3c24xx_i2c *i2c,
unsigned long iicstat)
*/
if (iicstat S3C2410_IICSTAT_LASTBIT
- !(i2c-msg-flags I2C_M_IGNORE_NAK)) {
+ !(i2c-msg-flags I2C_M_IGNORE_NAK)
+ is_master(i2c)) {
/* ack was not received... */
dev_dbg(i2c-dev, ack was not received\n);
@@ -380,7 +403,7 @@ static int i2c_s3c_irq_nextbyte(struct s3c24xx_i2c *i2c,
unsigned long iicstat)
* end of the message, and if so, work out what to do
*/
- if (!(i2c-msg-flags I2C_M_IGNORE_NAK)) {
+ if (!(i2c-msg-flags I2C_M_IGNORE_NAK) is_master(i2c))
{
if (iicstat S3C2410_IICSTAT_LASTBIT
Re: [PATCH 1/2] i2c-s3c2410: Leave the bus disabled unless it is in use
Acked-by: Kyungmin Park
On Thu, Nov 29, 2012 at 2:05 PM, Naveen Krishna Chatradhi
wrote:
> From: Simon Glass
>
> There is a rather odd feature of the exynos i2c controller that if it
> is left enabled, it can lock itself up with the clk line held low.
> This makes the bus unusable.
>
> Unfortunately, the s3c24xx_i2c_set_master() function does not notice
> this, and reports a timeout. From then on the bus cannot be used until
> the AP is rebooted.
>
> The problem happens when any sort of interrupt occurs (e.g. due to a
> bus transition) when we are not in the middle of a transaction. We
> have seen many instances of this when U-Boot leaves the bus apparently
> happy, but Linux cannot access it.
>
> The current code is therefore pretty fragile.
>
> This fixes things by leaving the bus disabled unless we are actually
> in a transaction. We enable the bus at the start of the transaction and
> disable it at the end. That way we won't get interrupts and will not
> lock up the bus.
>
> It might be possible to clear pending interrupts on start-up, but this
> seems to be a more robust solution. We can't service interrupts when
> we are not in a transaction, and anyway would rather not lock up the
> bus while we try.
>
> Signed-off-by: Simon Glass
> Cc: Grant Grundler
> Signed-off-by: Naveen Krishna Chatradhi
> ---
> drivers/i2c/busses/i2c-s3c2410.c | 37 +
> 1 file changed, 33 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-s3c2410.c
> b/drivers/i2c/busses/i2c-s3c2410.c
> index e93e7d6..2fd346d 100644
> --- a/drivers/i2c/busses/i2c-s3c2410.c
> +++ b/drivers/i2c/busses/i2c-s3c2410.c
> @@ -186,6 +186,31 @@ static inline void s3c24xx_i2c_enable_irq(struct
> s3c24xx_i2c *i2c)
> writel(tmp | S3C2410_IICCON_IRQEN, i2c->regs + S3C2410_IICCON);
> }
>
> +/*
> + * Disable the bus so that we won't get any interrupts from now on, or try
> + * to drive any lines. This is the default state when we don't have
> + * anything to send/receive.
> + *
> + * If there is an event on the bus, or we have a pre-existing event at
> + * kernel boot time, we may not notice the event and the I2C controller
> + * will lock the bus with the I2C clock line low indefinitely.
> + */
> +static inline void s3c24xx_i2c_disable_bus(struct s3c24xx_i2c *i2c)
> +{
> + unsigned long tmp;
> +
> + /* Stop driving the I2C pins */
> + tmp = readl(i2c->regs + S3C2410_IICSTAT);
> + tmp &= ~S3C2410_IICSTAT_TXRXEN;
> + writel(tmp, i2c->regs + S3C2410_IICSTAT);
> +
> + /* We don't expect any interrupts now, and don't want send acks */
> + tmp = readl(i2c->regs + S3C2410_IICCON);
> + tmp &= ~(S3C2410_IICCON_IRQEN | S3C2410_IICCON_IRQPEND |
> + S3C2410_IICCON_ACKEN);
> + writel(tmp, i2c->regs + S3C2410_IICCON);
> +}
> +
>
> /* s3c24xx_i2c_message_start
> *
> @@ -646,7 +671,11 @@ static int s3c24xx_i2c_doxfer(struct s3c24xx_i2c *i2c,
>
> s3c24xx_i2c_wait_idle(i2c);
>
> + s3c24xx_i2c_disable_bus(i2c);
> +
> out:
> + i2c->state = STATE_IDLE;
> +
> return ret;
> }
>
> @@ -912,7 +941,6 @@ static void s3c24xx_i2c_dt_gpio_free(struct s3c24xx_i2c
> *i2c)
>
> static int s3c24xx_i2c_init(struct s3c24xx_i2c *i2c)
> {
> - unsigned long iicon = S3C2410_IICCON_IRQEN | S3C2410_IICCON_ACKEN;
> struct s3c2410_platform_i2c *pdata;
> unsigned int freq;
>
> @@ -926,12 +954,12 @@ static int s3c24xx_i2c_init(struct s3c24xx_i2c *i2c)
>
> dev_info(i2c->dev, "slave address 0x%02x\n", pdata->slave_addr);
>
> - writel(iicon, i2c->regs + S3C2410_IICCON);
> + writel(0, i2c->regs + S3C2410_IICCON);
> + writel(0, i2c->regs + S3C2410_IICSTAT);
>
> /* we need to work out the divisors for the clock... */
>
> if (s3c24xx_i2c_clockrate(i2c, ) != 0) {
> - writel(0, i2c->regs + S3C2410_IICCON);
> dev_err(i2c->dev, "cannot meet bus frequency required\n");
> return -EINVAL;
> }
> @@ -939,7 +967,8 @@ static int s3c24xx_i2c_init(struct s3c24xx_i2c *i2c)
> /* todo - check that the i2c lines aren't being dragged anywhere */
>
> dev_info(i2c->dev, "bus frequency set to %d KHz\n", freq);
> - dev_dbg(i2c->dev, "S3C2410_IICCON=0x%02lx\n", iicon);
> + dev_dbg(i2c->dev, "S3C2410_IICCON=0x%02x\n",
> + readl(i2c->regs + S3C2410_IICCON));
>
> return 0;
> }
> --
> 1.7.9.5
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] i2c-s3c2410: Leave the bus disabled unless it is in use
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
On Thu, Nov 29, 2012 at 2:05 PM, Naveen Krishna Chatradhi
ch.nav...@samsung.com wrote:
From: Simon Glass s...@chromium.org
There is a rather odd feature of the exynos i2c controller that if it
is left enabled, it can lock itself up with the clk line held low.
This makes the bus unusable.
Unfortunately, the s3c24xx_i2c_set_master() function does not notice
this, and reports a timeout. From then on the bus cannot be used until
the AP is rebooted.
The problem happens when any sort of interrupt occurs (e.g. due to a
bus transition) when we are not in the middle of a transaction. We
have seen many instances of this when U-Boot leaves the bus apparently
happy, but Linux cannot access it.
The current code is therefore pretty fragile.
This fixes things by leaving the bus disabled unless we are actually
in a transaction. We enable the bus at the start of the transaction and
disable it at the end. That way we won't get interrupts and will not
lock up the bus.
It might be possible to clear pending interrupts on start-up, but this
seems to be a more robust solution. We can't service interrupts when
we are not in a transaction, and anyway would rather not lock up the
bus while we try.
Signed-off-by: Simon Glass s...@chromium.org
Cc: Grant Grundler grund...@chromium.org
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
---
drivers/i2c/busses/i2c-s3c2410.c | 37 +
1 file changed, 33 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-s3c2410.c
b/drivers/i2c/busses/i2c-s3c2410.c
index e93e7d6..2fd346d 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
@@ -186,6 +186,31 @@ static inline void s3c24xx_i2c_enable_irq(struct
s3c24xx_i2c *i2c)
writel(tmp | S3C2410_IICCON_IRQEN, i2c-regs + S3C2410_IICCON);
}
+/*
+ * Disable the bus so that we won't get any interrupts from now on, or try
+ * to drive any lines. This is the default state when we don't have
+ * anything to send/receive.
+ *
+ * If there is an event on the bus, or we have a pre-existing event at
+ * kernel boot time, we may not notice the event and the I2C controller
+ * will lock the bus with the I2C clock line low indefinitely.
+ */
+static inline void s3c24xx_i2c_disable_bus(struct s3c24xx_i2c *i2c)
+{
+ unsigned long tmp;
+
+ /* Stop driving the I2C pins */
+ tmp = readl(i2c-regs + S3C2410_IICSTAT);
+ tmp = ~S3C2410_IICSTAT_TXRXEN;
+ writel(tmp, i2c-regs + S3C2410_IICSTAT);
+
+ /* We don't expect any interrupts now, and don't want send acks */
+ tmp = readl(i2c-regs + S3C2410_IICCON);
+ tmp = ~(S3C2410_IICCON_IRQEN | S3C2410_IICCON_IRQPEND |
+ S3C2410_IICCON_ACKEN);
+ writel(tmp, i2c-regs + S3C2410_IICCON);
+}
+
/* s3c24xx_i2c_message_start
*
@@ -646,7 +671,11 @@ static int s3c24xx_i2c_doxfer(struct s3c24xx_i2c *i2c,
s3c24xx_i2c_wait_idle(i2c);
+ s3c24xx_i2c_disable_bus(i2c);
+
out:
+ i2c-state = STATE_IDLE;
+
return ret;
}
@@ -912,7 +941,6 @@ static void s3c24xx_i2c_dt_gpio_free(struct s3c24xx_i2c
*i2c)
static int s3c24xx_i2c_init(struct s3c24xx_i2c *i2c)
{
- unsigned long iicon = S3C2410_IICCON_IRQEN | S3C2410_IICCON_ACKEN;
struct s3c2410_platform_i2c *pdata;
unsigned int freq;
@@ -926,12 +954,12 @@ static int s3c24xx_i2c_init(struct s3c24xx_i2c *i2c)
dev_info(i2c-dev, slave address 0x%02x\n, pdata-slave_addr);
- writel(iicon, i2c-regs + S3C2410_IICCON);
+ writel(0, i2c-regs + S3C2410_IICCON);
+ writel(0, i2c-regs + S3C2410_IICSTAT);
/* we need to work out the divisors for the clock... */
if (s3c24xx_i2c_clockrate(i2c, freq) != 0) {
- writel(0, i2c-regs + S3C2410_IICCON);
dev_err(i2c-dev, cannot meet bus frequency required\n);
return -EINVAL;
}
@@ -939,7 +967,8 @@ static int s3c24xx_i2c_init(struct s3c24xx_i2c *i2c)
/* todo - check that the i2c lines aren't being dragged anywhere */
dev_info(i2c-dev, bus frequency set to %d KHz\n, freq);
- dev_dbg(i2c-dev, S3C2410_IICCON=0x%02lx\n, iicon);
+ dev_dbg(i2c-dev, S3C2410_IICCON=0x%02x\n,
+ readl(i2c-regs + S3C2410_IICCON));
return 0;
}
--
1.7.9.5
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
