[tip:timers/urgent] clocksource/exynos_mct: Clear interrupt when cpu is shut down

[tip-bot for Joonyoung Shim]

Commit-ID:  bc7c36eedb0c7004aa06c2afc3c5385adada8fa3
Gitweb: http://git.kernel.org/tip/bc7c36eedb0c7004aa06c2afc3c5385adada8fa3
Author: Joonyoung Shim <jy0922.s...@samsung.com>
AuthorDate: Tue, 17 Jan 2017 13:54:36 +0900
Committer:  Thomas Gleixner <t...@linutronix.de>
CommitDate: Tue, 17 Jan 2017 10:08:38 +0100

clocksource/exynos_mct: Clear interrupt when cpu is shut down

When a CPU goes offline a potentially pending timer interrupt is not
cleared. When the CPU comes online again then the pending interrupt is
delivered before the per cpu clockevent device is initialized. As a
consequence the tick interrupt handler dereferences a NULL pointer.

[   51.251378] Unable to handle kernel NULL pointer dereference at virtual 
address 0040
[   51.289348] task: ee942d00 task.stack: ee96
[   51.293861] PC is at tick_periodic+0x38/0xb0
[   51.298102] LR is at tick_handle_periodic+0x1c/0x90

Clear the pending interrupt in the cpu dying path.

Fixes: 56a94f13919c ("clocksource: exynos_mct: Avoid blocking calls in the cpu 
hotplug notifier")
Reported-by: Seung-Woo Kim <sw0312@samsung.com>
Signed-off-by: Joonyoung Shim <jy0922.s...@samsung.com>
Cc: linux-samsung-...@vger.kernel.org
Cc: cw00.c...@samsung.com
Cc: daniel.lezc...@linaro.org
Cc: sta...@vger.kernel.org
Cc: jav...@osg.samsung.com
Cc: kg...@kernel.org
Cc: k...@kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Link: 
http://lkml.kernel.org/r/1484628876-22065-1-git-send-email-jy0922.s...@samsung.com
Signed-off-by: Thomas Gleixner <t...@linutronix.de>

---
 drivers/clocksource/exynos_mct.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clocksource/exynos_mct.c b/drivers/clocksource/exynos_mct.c
index 4da1dc2..670ff0f 100644
--- a/drivers/clocksource/exynos_mct.c
+++ b/drivers/clocksource/exynos_mct.c
@@ -495,6 +495,7 @@ static int exynos4_mct_dying_cpu(unsigned int cpu)
if (mct_int_type == MCT_INT_SPI) {
if (evt->irq != -1)
disable_irq_nosync(evt->irq);
+   exynos4_mct_write(0x1, mevt->base + MCT_L_INT_CSTAT_OFFSET);
} else {
disable_percpu_irq(mct_irqs[MCT_L0_IRQ]);
}

[tip:timers/urgent] clocksource/exynos_mct: Clear interrupt when cpu is shut down

[tip-bot for Joonyoung Shim]

Commit-ID:  bc7c36eedb0c7004aa06c2afc3c5385adada8fa3
Gitweb: http://git.kernel.org/tip/bc7c36eedb0c7004aa06c2afc3c5385adada8fa3
Author: Joonyoung Shim 
AuthorDate: Tue, 17 Jan 2017 13:54:36 +0900
Committer:  Thomas Gleixner 
CommitDate: Tue, 17 Jan 2017 10:08:38 +0100

clocksource/exynos_mct: Clear interrupt when cpu is shut down

When a CPU goes offline a potentially pending timer interrupt is not
cleared. When the CPU comes online again then the pending interrupt is
delivered before the per cpu clockevent device is initialized. As a
consequence the tick interrupt handler dereferences a NULL pointer.

[   51.251378] Unable to handle kernel NULL pointer dereference at virtual 
address 0040
[   51.289348] task: ee942d00 task.stack: ee96
[   51.293861] PC is at tick_periodic+0x38/0xb0
[   51.298102] LR is at tick_handle_periodic+0x1c/0x90

Clear the pending interrupt in the cpu dying path.

Fixes: 56a94f13919c ("clocksource: exynos_mct: Avoid blocking calls in the cpu 
hotplug notifier")
Reported-by: Seung-Woo Kim 
Signed-off-by: Joonyoung Shim 
Cc: linux-samsung-...@vger.kernel.org
Cc: cw00.c...@samsung.com
Cc: daniel.lezc...@linaro.org
Cc: sta...@vger.kernel.org
Cc: jav...@osg.samsung.com
Cc: kg...@kernel.org
Cc: k...@kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Link: 
http://lkml.kernel.org/r/1484628876-22065-1-git-send-email-jy0922.s...@samsung.com
Signed-off-by: Thomas Gleixner 

---
 drivers/clocksource/exynos_mct.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clocksource/exynos_mct.c b/drivers/clocksource/exynos_mct.c
index 4da1dc2..670ff0f 100644
--- a/drivers/clocksource/exynos_mct.c
+++ b/drivers/clocksource/exynos_mct.c
@@ -495,6 +495,7 @@ static int exynos4_mct_dying_cpu(unsigned int cpu)
if (mct_int_type == MCT_INT_SPI) {
if (evt->irq != -1)
disable_irq_nosync(evt->irq);
+   exynos4_mct_write(0x1, mevt->base + MCT_L_INT_CSTAT_OFFSET);
} else {
disable_percpu_irq(mct_irqs[MCT_L0_IRQ]);
}

[PATCH] clocksource: exynos_mct: clear irq at stop local mct to fix suspend

[Joonyoung Shim]

This patch adds clear interrupt to exynos4_mct_dying_cpu(). Without
clearing, after turning on non boot cpu at wakeup from suspend to
ram, not cleared tick interrupt occurs and it causes following null
deference for MCT_INT_SPI type mct.

[   51.251378] Unable to handle kernel NULL pointer dereference at virtual 
address 0040
[   51.257980] pgd = c0004000
[   51.260666] [0040] *pgd=
[   51.264222] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
[   51.269503] Modules linked in:
[   51.272541] CPU: 7 PID: 53 Comm: ksoftirqd/7 Tainted: GW 
4.9.0-rc7-next-20161201-7-g74076859ec44 #140
[   51.283282] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[   51.289348] task: ee942d00 task.stack: ee96
[   51.293861] PC is at tick_periodic+0x38/0xb0
[   51.298102] LR is at tick_handle_periodic+0x1c/0x90
[   51.302956] pc : []lr : []psr: 2093
[   51.302956] sp : ee961e18  ip : f0806000  fp : 0100
[   51.314391] r10: c0c0ef6a  r9 : 000b  r8 : eebcf080
[   51.319591] r7 : ee961e7c  r6 :   r5 : 0007  r4 : ef013ec0
[   51.326090] r3 :   r2 : 2e4ac000  r1 : c09ae9a8  r0 : 0007
[   51.332591] Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM Segment none
[   51.339781] Control: 10c5387d  Table: 4000406a  DAC: 0051
[   51.345501] Process ksoftirqd/7 (pid: 53, stack limit = 0xee960210)
[   51.351740] Stack: (0xee961e18 to 0xee962000)
[   51.356073] 1e00: ef014db0 c0c03dac
[   51.364222] 1e20:  ef013ec0 ee854100  ee961e7c 0039 
ee854100 c0c0ef6a
[   51.372367] 1e40: 0100 c055bd44 ee852840 c0164a18  0001 
ee854100 ee854100
[   51.380512] 1e60: c0c03f24 c0b6324c c0c02080 c0c02080 4006 c0164ac4 
 
[   51.388658] 1e80: 0100 ee854100 ee854160 c0164b38 ee854100 ee854160 
c0c03f24 c0167e9c
[   51.396804] 1ea0: 0039 c0c0cbac c0c0cbac c0b6324c c0c02080 c01675e0 
c0c0cc5c c0c0cc60
[   51.404949] 1ec0:  c011fd3c  0006 c0c02098 ee96 
c0c02080 c011ff6c
[   51.413095] 1ee0: ee961f0c c06fb4a4 ee961ee0 c0c47f80 000a 9ed5 
c0c03900 04208040
[   51.421240] 1f00: c0c0a174 ee96 ee867b00 0007 0001 c0c0a174 
0002 
[   51.429385] 1f20:  c01200b8 ee96 c013a50c  ee867b80 
ee867b00 c013a3b0
[   51.437530] 1f40:    c0136cbc  0001 
0007 ee867b00
[   51.445676] 1f60:  00270027 dead4ead   ee961f74 
ee961f74 
[   51.453822] 1f80:  dead4ead   ee961f90 ee961f90 
ee961fac ee867b80
[   51.461967] 1fa0: c0136be0   c0107a78   
 
[   51.470112] 1fc0:       
 
[   51.478258] 1fe0:     0013  
 
[   51.486409] [] (tick_periodic) from [] (0xef013ec0)
[   51.492990] Code: ee1d2f90 e34c30b6 e8bd4070 e7923003 (e5933040)
[   51.499057] ---[ end trace 995703fe1bede0b4 ]---

Fixes: 56a94f13919c ("clocksource: exynos_mct: Avoid blocking calls in the cpu 
hotplug notifier")
Cc: sta...@vger.kernel.org #v4.2+ #v4.1.4+ #3.18.18+ #v3.16.18+ #v3.12.46+
Reported-by: Seung-Woo Kim <sw0312@samsung.com>
Signed-off-by: Joonyoung Shim <jy0922.s...@samsung.com>
Signed-off-by: Seung-Woo Kim <sw0312@samsung.com>
---
 drivers/clocksource/exynos_mct.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clocksource/exynos_mct.c b/drivers/clocksource/exynos_mct.c
index 4da1dc2..670ff0f 100644
--- a/drivers/clocksource/exynos_mct.c
+++ b/drivers/clocksource/exynos_mct.c
@@ -495,6 +495,7 @@ static int exynos4_mct_dying_cpu(unsigned int cpu)
if (mct_int_type == MCT_INT_SPI) {
if (evt->irq != -1)
disable_irq_nosync(evt->irq);
+   exynos4_mct_write(0x1, mevt->base + MCT_L_INT_CSTAT_OFFSET);
} else {
disable_percpu_irq(mct_irqs[MCT_L0_IRQ]);
}
-- 
1.9.1

[PATCH] clocksource: exynos_mct: clear irq at stop local mct to fix suspend

[Joonyoung Shim]

This patch adds clear interrupt to exynos4_mct_dying_cpu(). Without
clearing, after turning on non boot cpu at wakeup from suspend to
ram, not cleared tick interrupt occurs and it causes following null
deference for MCT_INT_SPI type mct.

[   51.251378] Unable to handle kernel NULL pointer dereference at virtual 
address 0040
[   51.257980] pgd = c0004000
[   51.260666] [0040] *pgd=
[   51.264222] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
[   51.269503] Modules linked in:
[   51.272541] CPU: 7 PID: 53 Comm: ksoftirqd/7 Tainted: GW 
4.9.0-rc7-next-20161201-7-g74076859ec44 #140
[   51.283282] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[   51.289348] task: ee942d00 task.stack: ee96
[   51.293861] PC is at tick_periodic+0x38/0xb0
[   51.298102] LR is at tick_handle_periodic+0x1c/0x90
[   51.302956] pc : []lr : []psr: 2093
[   51.302956] sp : ee961e18  ip : f0806000  fp : 0100
[   51.314391] r10: c0c0ef6a  r9 : 000b  r8 : eebcf080
[   51.319591] r7 : ee961e7c  r6 :   r5 : 0007  r4 : ef013ec0
[   51.326090] r3 :   r2 : 2e4ac000  r1 : c09ae9a8  r0 : 0007
[   51.332591] Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM Segment none
[   51.339781] Control: 10c5387d  Table: 4000406a  DAC: 0051
[   51.345501] Process ksoftirqd/7 (pid: 53, stack limit = 0xee960210)
[   51.351740] Stack: (0xee961e18 to 0xee962000)
[   51.356073] 1e00: ef014db0 c0c03dac
[   51.364222] 1e20:  ef013ec0 ee854100  ee961e7c 0039 
ee854100 c0c0ef6a
[   51.372367] 1e40: 0100 c055bd44 ee852840 c0164a18  0001 
ee854100 ee854100
[   51.380512] 1e60: c0c03f24 c0b6324c c0c02080 c0c02080 4006 c0164ac4 
 
[   51.388658] 1e80: 0100 ee854100 ee854160 c0164b38 ee854100 ee854160 
c0c03f24 c0167e9c
[   51.396804] 1ea0: 0039 c0c0cbac c0c0cbac c0b6324c c0c02080 c01675e0 
c0c0cc5c c0c0cc60
[   51.404949] 1ec0:  c011fd3c  0006 c0c02098 ee96 
c0c02080 c011ff6c
[   51.413095] 1ee0: ee961f0c c06fb4a4 ee961ee0 c0c47f80 000a 9ed5 
c0c03900 04208040
[   51.421240] 1f00: c0c0a174 ee96 ee867b00 0007 0001 c0c0a174 
0002 
[   51.429385] 1f20:  c01200b8 ee96 c013a50c  ee867b80 
ee867b00 c013a3b0
[   51.437530] 1f40:    c0136cbc  0001 
0007 ee867b00
[   51.445676] 1f60:  00270027 dead4ead   ee961f74 
ee961f74 
[   51.453822] 1f80:  dead4ead   ee961f90 ee961f90 
ee961fac ee867b80
[   51.461967] 1fa0: c0136be0   c0107a78   
 
[   51.470112] 1fc0:       
 
[   51.478258] 1fe0:     0013  
 
[   51.486409] [] (tick_periodic) from [] (0xef013ec0)
[   51.492990] Code: ee1d2f90 e34c30b6 e8bd4070 e7923003 (e5933040)
[   51.499057] ---[ end trace 995703fe1bede0b4 ]---

Fixes: 56a94f13919c ("clocksource: exynos_mct: Avoid blocking calls in the cpu 
hotplug notifier")
Cc: sta...@vger.kernel.org #v4.2+ #v4.1.4+ #3.18.18+ #v3.16.18+ #v3.12.46+
Reported-by: Seung-Woo Kim 
Signed-off-by: Joonyoung Shim 
Signed-off-by: Seung-Woo Kim 
---
 drivers/clocksource/exynos_mct.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clocksource/exynos_mct.c b/drivers/clocksource/exynos_mct.c
index 4da1dc2..670ff0f 100644
--- a/drivers/clocksource/exynos_mct.c
+++ b/drivers/clocksource/exynos_mct.c
@@ -495,6 +495,7 @@ static int exynos4_mct_dying_cpu(unsigned int cpu)
if (mct_int_type == MCT_INT_SPI) {
if (evt->irq != -1)
disable_irq_nosync(evt->irq);
+   exynos4_mct_write(0x1, mevt->base + MCT_L_INT_CSTAT_OFFSET);
} else {
disable_percpu_irq(mct_irqs[MCT_L0_IRQ]);
}
-- 
1.9.1

Re: [PATCH V4] PM / OPP: Pass opp_table to dev_pm_opp_put_regulator()

[Joonyoung Shim]

On 11/30/2016 05:05 PM, Viresh Kumar wrote:
> On 30-11-16, 15:19, Joonyoung Shim wrote:
>> Hi Viresh,
>>
>> On 11/30/2016 12:59 PM, Viresh Kumar wrote:
>>> From: Stephen Boyd <sb...@codeaurora.org>
>>>
>>> Joonyoung Shim reported an interesting problem on his ARM octa-core
>>> Odoroid-XU3 platform. During system suspend, dev_pm_opp_put_regulator()
>>> was failing for a struct device for which dev_pm_opp_set_regulator() is
>>> called earlier.
>>>
>>> This happened because an earlier call to
>>> dev_pm_opp_of_cpumask_remove_table() function (from cpufreq-dt.c file)
>>> removed all the entries from opp_table->dev_list apart from the last CPU
>>> device in the cpumask of CPUs sharing the OPP.
>>>
>>> But both dev_pm_opp_set_regulator() and dev_pm_opp_put_regulator()
>>> routines get CPU device for the first CPU in the cpumask. And so the OPP
>>> core failed to find the OPP table for the struct device.
>>>
>>> In order to fix that up properly, we need to revisit APIs like
>>> dev_pm_opp_set_regulator() and make them talk in terms of cookies
>>> provided by the OPP core. But such a solution will be hard to backport
>>> to stable kernels.
>>>
>>> This patch attempts to fix this problem by returning a pointer to the
>>> opp_table from dev_pm_opp_set_regulator() and using that as the
>>> parameter to dev_pm_opp_put_regulator(). This ensures that the
>>> dev_pm_opp_put_regulator() doesn't fail to find the opp table.
>>>
>>> Note that similar design problem also exists with other
>>> dev_pm_opp_put_*() APIs, but those aren't used currently by anyone and
>>> so we don't need to update them for now.
>>>
>>> [Viresh]: Written commit log, minor improvements in the patch and tested
>>> on exynos 5250.
>>>
>>> Cc: # v4.4+ <sta...@vger.kernel.org>
>>> Reported-by: Joonyoung Shim <jy0922.s...@samsung.com>
>>> Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
>>> Signed-off-by: Viresh Kumar <viresh.ku...@linaro.org>
>>> ---
>>> V3->V4:
>>> - Completely different approach, suggested earlier by Stephen.
>>> - Can be merged safely now as both /me and Stephen agree to this one.
>>>
>>> @Joonyoung: Can you please test this last patch please ?
>>>
>>
>> Just system suspend/resume is working
> 
> Should I consider that as a Tested-by from you for the problem you
> reported at least ?
> 

My Tested-by is ok about the original problem reported by me.

>> but i was missing below test case
>> that you inform when i test for prior patches on my Odroid-XU3 board.
>>
>> - offline CPU 4
>> - suspend the system
>>
>> With this test case, now all patches posted have the problem that is
>> failed to get clk: -2.
> 
> That probably happens because your DT isn't good enough. Following DT
> change may fix it for you:
> 

Already i tried and the error was gone but sometimes system resume is
halt. I'm not sure that it has any effect so i need to more dig.

Thanks.

Re: [PATCH V4] PM / OPP: Pass opp_table to dev_pm_opp_put_regulator()

[Joonyoung Shim]

On 11/30/2016 05:05 PM, Viresh Kumar wrote:
> On 30-11-16, 15:19, Joonyoung Shim wrote:
>> Hi Viresh,
>>
>> On 11/30/2016 12:59 PM, Viresh Kumar wrote:
>>> From: Stephen Boyd 
>>>
>>> Joonyoung Shim reported an interesting problem on his ARM octa-core
>>> Odoroid-XU3 platform. During system suspend, dev_pm_opp_put_regulator()
>>> was failing for a struct device for which dev_pm_opp_set_regulator() is
>>> called earlier.
>>>
>>> This happened because an earlier call to
>>> dev_pm_opp_of_cpumask_remove_table() function (from cpufreq-dt.c file)
>>> removed all the entries from opp_table->dev_list apart from the last CPU
>>> device in the cpumask of CPUs sharing the OPP.
>>>
>>> But both dev_pm_opp_set_regulator() and dev_pm_opp_put_regulator()
>>> routines get CPU device for the first CPU in the cpumask. And so the OPP
>>> core failed to find the OPP table for the struct device.
>>>
>>> In order to fix that up properly, we need to revisit APIs like
>>> dev_pm_opp_set_regulator() and make them talk in terms of cookies
>>> provided by the OPP core. But such a solution will be hard to backport
>>> to stable kernels.
>>>
>>> This patch attempts to fix this problem by returning a pointer to the
>>> opp_table from dev_pm_opp_set_regulator() and using that as the
>>> parameter to dev_pm_opp_put_regulator(). This ensures that the
>>> dev_pm_opp_put_regulator() doesn't fail to find the opp table.
>>>
>>> Note that similar design problem also exists with other
>>> dev_pm_opp_put_*() APIs, but those aren't used currently by anyone and
>>> so we don't need to update them for now.
>>>
>>> [Viresh]: Written commit log, minor improvements in the patch and tested
>>> on exynos 5250.
>>>
>>> Cc: # v4.4+ 
>>> Reported-by: Joonyoung Shim 
>>> Signed-off-by: Stephen Boyd 
>>> Signed-off-by: Viresh Kumar 
>>> ---
>>> V3->V4:
>>> - Completely different approach, suggested earlier by Stephen.
>>> - Can be merged safely now as both /me and Stephen agree to this one.
>>>
>>> @Joonyoung: Can you please test this last patch please ?
>>>
>>
>> Just system suspend/resume is working
> 
> Should I consider that as a Tested-by from you for the problem you
> reported at least ?
> 

My Tested-by is ok about the original problem reported by me.

>> but i was missing below test case
>> that you inform when i test for prior patches on my Odroid-XU3 board.
>>
>> - offline CPU 4
>> - suspend the system
>>
>> With this test case, now all patches posted have the problem that is
>> failed to get clk: -2.
> 
> That probably happens because your DT isn't good enough. Following DT
> change may fix it for you:
> 

Already i tried and the error was gone but sometimes system resume is
halt. I'm not sure that it has any effect so i need to more dig.

Thanks.

Re: [PATCH V4] PM / OPP: Pass opp_table to dev_pm_opp_put_regulator()

[Joonyoung Shim]

Hi Viresh,

On 11/30/2016 12:59 PM, Viresh Kumar wrote:
> From: Stephen Boyd <sb...@codeaurora.org>
> 
> Joonyoung Shim reported an interesting problem on his ARM octa-core
> Odoroid-XU3 platform. During system suspend, dev_pm_opp_put_regulator()
> was failing for a struct device for which dev_pm_opp_set_regulator() is
> called earlier.
> 
> This happened because an earlier call to
> dev_pm_opp_of_cpumask_remove_table() function (from cpufreq-dt.c file)
> removed all the entries from opp_table->dev_list apart from the last CPU
> device in the cpumask of CPUs sharing the OPP.
> 
> But both dev_pm_opp_set_regulator() and dev_pm_opp_put_regulator()
> routines get CPU device for the first CPU in the cpumask. And so the OPP
> core failed to find the OPP table for the struct device.
> 
> In order to fix that up properly, we need to revisit APIs like
> dev_pm_opp_set_regulator() and make them talk in terms of cookies
> provided by the OPP core. But such a solution will be hard to backport
> to stable kernels.
> 
> This patch attempts to fix this problem by returning a pointer to the
> opp_table from dev_pm_opp_set_regulator() and using that as the
> parameter to dev_pm_opp_put_regulator(). This ensures that the
> dev_pm_opp_put_regulator() doesn't fail to find the opp table.
> 
> Note that similar design problem also exists with other
> dev_pm_opp_put_*() APIs, but those aren't used currently by anyone and
> so we don't need to update them for now.
> 
> [Viresh]: Written commit log, minor improvements in the patch and tested
> on exynos 5250.
> 
> Cc: # v4.4+ <sta...@vger.kernel.org>
> Reported-by: Joonyoung Shim <jy0922.s...@samsung.com>
> Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
> Signed-off-by: Viresh Kumar <viresh.ku...@linaro.org>
> ---
> V3->V4:
> - Completely different approach, suggested earlier by Stephen.
> - Can be merged safely now as both /me and Stephen agree to this one.
> 
> @Joonyoung: Can you please test this last patch please ?
> 

Just system suspend/resume is working but i was missing below test case
that you inform when i test for prior patches on my Odroid-XU3 board.

- offline CPU 4
- suspend the system

With this test case, now all patches posted have the problem that is
failed to get clk: -2.

If all CPUs are online, cpufreq_driver->init(policy) is called by
cpufreq_online() only for CPU0 and CPU4 during system resume but it is
called for CPU5, CPU6 and CPU7 during system resume after CPU4 is
offline, and causes error.

Please refer below logs.

# echo 0 > /sys/devices/system/cpu/cpu4/online 
[  145.438931] IRQ54 no longer affine to CPU4
[  145.439931] CPU4: shutdown
#
#
# rtcwake -m mem -s 3
wakeup from "mem" at Mon Apr  9 11:04:19 2001
[  148.708773] PM: Syncing filesystems ... done.
[  148.718591] Freezing user space processes ... (elapsed 0.005 seconds) done.
[  148.727749] Freezing remaining freezable tasks ... (elapsed 0.002 seconds) 
done.
[  148.753406] wake enabled for irq 135
[  148.754006] smsc95xx 1-1.1:1.0 eth0: entering SUSPEND2 mode
[  148.844402] PM: suspend of devices complete after 100.196 msecs
[  148.869158] PM: late suspend of devices complete after 19.793 msecs
[  148.891948] PM: noirq suspend of devices complete after 17.803 msecs
[  148.897067] Disabling non-boot CPUs ...
[  148.920201] IRQ51 no longer affine to CPU1
[  148.921414] CPU1: shutdown
[  148.990114] IRQ52 no longer affine to CPU2
[  148.991158] CPU2: shutdown
[  149.049416] IRQ53 no longer affine to CPU3
[  149.050477] CPU3: shutdown
[  149.114297] IRQ55 no longer affine to CPU5
[  149.115318] CPU5: shutdown
[  149.184539] IRQ56 no longer affine to CPU6
[  149.185421] CPU6: shutdown
[  149.257561] IRQ57 no longer affine to CPU7
[  149.258458] CPU7: shutdown
exynos_suspend_enter: suspending the system...
exynos_suspend_enter: wakeup masks: fffd,ffef
UART[f702]: ULCON=0003, UCON=f3c5, UFCON=0131, UBRDIV=001b
[  149.295339] Enabling non-boot CPUs ...
[  149.314454] CPU1 is up
[  149.329717] CPU2 is up
[  149.350140] CPU3 is up
[  149.370365] cpu cpu5: cpufreq_init: failed to get clk: -2
[  149.374803] IRQ55 no longer affine to CPU5
[  149.375126] CPU5: shutdown
[  149.399737] Error taking CPU5 up: -2
[  149.425424] cpu cpu6: cpufreq_init: failed to get clk: -2
[  149.429886] IRQ56 no longer affine to CPU6
[  149.430242] CPU6: shutdown
[  149.454745] Error taking CPU6 up: -2
[  149.480397] cpu cpu7: cpufreq_init: failed to get clk: -2
[  149.484869] IRQ57 no longer affine to CPU7
[  149.485186] CPU7: shutdown
[  149.509718] Error taking CPU7 up: -2
[  149.512392] s3c-i2c 12c6.i2c: slave address 0x00
[  149.516787] s3c-i2c 12c6.i2c: bus frequency set to 65 KHz
[  149.522554] s3c-i2c 12c8.i2c: slave address 0x00
[  149.527461] s3c-i2c 12c8.i2c: bus frequency set to 65 KHz
[  149.5358

Re: [PATCH V4] PM / OPP: Pass opp_table to dev_pm_opp_put_regulator()

[Joonyoung Shim]

Hi Viresh,

On 11/30/2016 12:59 PM, Viresh Kumar wrote:
> From: Stephen Boyd 
> 
> Joonyoung Shim reported an interesting problem on his ARM octa-core
> Odoroid-XU3 platform. During system suspend, dev_pm_opp_put_regulator()
> was failing for a struct device for which dev_pm_opp_set_regulator() is
> called earlier.
> 
> This happened because an earlier call to
> dev_pm_opp_of_cpumask_remove_table() function (from cpufreq-dt.c file)
> removed all the entries from opp_table->dev_list apart from the last CPU
> device in the cpumask of CPUs sharing the OPP.
> 
> But both dev_pm_opp_set_regulator() and dev_pm_opp_put_regulator()
> routines get CPU device for the first CPU in the cpumask. And so the OPP
> core failed to find the OPP table for the struct device.
> 
> In order to fix that up properly, we need to revisit APIs like
> dev_pm_opp_set_regulator() and make them talk in terms of cookies
> provided by the OPP core. But such a solution will be hard to backport
> to stable kernels.
> 
> This patch attempts to fix this problem by returning a pointer to the
> opp_table from dev_pm_opp_set_regulator() and using that as the
> parameter to dev_pm_opp_put_regulator(). This ensures that the
> dev_pm_opp_put_regulator() doesn't fail to find the opp table.
> 
> Note that similar design problem also exists with other
> dev_pm_opp_put_*() APIs, but those aren't used currently by anyone and
> so we don't need to update them for now.
> 
> [Viresh]: Written commit log, minor improvements in the patch and tested
> on exynos 5250.
> 
> Cc: # v4.4+ 
> Reported-by: Joonyoung Shim 
> Signed-off-by: Stephen Boyd 
> Signed-off-by: Viresh Kumar 
> ---
> V3->V4:
> - Completely different approach, suggested earlier by Stephen.
> - Can be merged safely now as both /me and Stephen agree to this one.
> 
> @Joonyoung: Can you please test this last patch please ?
> 

Just system suspend/resume is working but i was missing below test case
that you inform when i test for prior patches on my Odroid-XU3 board.

- offline CPU 4
- suspend the system

With this test case, now all patches posted have the problem that is
failed to get clk: -2.

If all CPUs are online, cpufreq_driver->init(policy) is called by
cpufreq_online() only for CPU0 and CPU4 during system resume but it is
called for CPU5, CPU6 and CPU7 during system resume after CPU4 is
offline, and causes error.

Please refer below logs.

# echo 0 > /sys/devices/system/cpu/cpu4/online 
[  145.438931] IRQ54 no longer affine to CPU4
[  145.439931] CPU4: shutdown
#
#
# rtcwake -m mem -s 3
wakeup from "mem" at Mon Apr  9 11:04:19 2001
[  148.708773] PM: Syncing filesystems ... done.
[  148.718591] Freezing user space processes ... (elapsed 0.005 seconds) done.
[  148.727749] Freezing remaining freezable tasks ... (elapsed 0.002 seconds) 
done.
[  148.753406] wake enabled for irq 135
[  148.754006] smsc95xx 1-1.1:1.0 eth0: entering SUSPEND2 mode
[  148.844402] PM: suspend of devices complete after 100.196 msecs
[  148.869158] PM: late suspend of devices complete after 19.793 msecs
[  148.891948] PM: noirq suspend of devices complete after 17.803 msecs
[  148.897067] Disabling non-boot CPUs ...
[  148.920201] IRQ51 no longer affine to CPU1
[  148.921414] CPU1: shutdown
[  148.990114] IRQ52 no longer affine to CPU2
[  148.991158] CPU2: shutdown
[  149.049416] IRQ53 no longer affine to CPU3
[  149.050477] CPU3: shutdown
[  149.114297] IRQ55 no longer affine to CPU5
[  149.115318] CPU5: shutdown
[  149.184539] IRQ56 no longer affine to CPU6
[  149.185421] CPU6: shutdown
[  149.257561] IRQ57 no longer affine to CPU7
[  149.258458] CPU7: shutdown
exynos_suspend_enter: suspending the system...
exynos_suspend_enter: wakeup masks: fffd,ffef
UART[f702]: ULCON=0003, UCON=f3c5, UFCON=0131, UBRDIV=001b
[  149.295339] Enabling non-boot CPUs ...
[  149.314454] CPU1 is up
[  149.329717] CPU2 is up
[  149.350140] CPU3 is up
[  149.370365] cpu cpu5: cpufreq_init: failed to get clk: -2
[  149.374803] IRQ55 no longer affine to CPU5
[  149.375126] CPU5: shutdown
[  149.399737] Error taking CPU5 up: -2
[  149.425424] cpu cpu6: cpufreq_init: failed to get clk: -2
[  149.429886] IRQ56 no longer affine to CPU6
[  149.430242] CPU6: shutdown
[  149.454745] Error taking CPU6 up: -2
[  149.480397] cpu cpu7: cpufreq_init: failed to get clk: -2
[  149.484869] IRQ57 no longer affine to CPU7
[  149.485186] CPU7: shutdown
[  149.509718] Error taking CPU7 up: -2
[  149.512392] s3c-i2c 12c6.i2c: slave address 0x00
[  149.516787] s3c-i2c 12c6.i2c: bus frequency set to 65 KHz
[  149.522554] s3c-i2c 12c8.i2c: slave address 0x00
[  149.527461] s3c-i2c 12c8.i2c: bus frequency set to 65 KHz
[  149.535818] PM: noirq resume of devices complete after 23.970 msecs
[  149.543853] PM: early resume of devices complete after 3.020 msecs
[  149.57135

Re: [PATCH] PM / OPP: fix CPU device to be removed from OPP table in wrong order

[Joonyoung Shim]

Hi Viresh,

On 11/25/2016 03:57 PM, Viresh Kumar wrote:
> On 25-11-16, 10:54, Joonyoung Shim wrote:
>> I found this problem during system suspend/resume of Odroid-XU3 board.
>>
>> # rtcwake -m mem -s 3
>> wakeup from "mem" at Wed Apr  4 05:54:44 2001
>> [   15.965996] PM: Syncing filesystems ... done.
>> [   15.976333] Freezing user space processes ... (elapsed 0.002 seconds) 
>> done.
>> [   15.983287] Freezing remaining freezable tasks ... (elapsed 0.002 
>> seconds) done.
>> [   16.006951] wake enabled for irq 135
>> [   16.008782] smsc95xx 1-1.1:1.0 eth0: entering SUSPEND2 mode
>> [   16.094110] PM: suspend of devices complete after 95.038 msecs
>> [   16.105648] PM: late suspend of devices complete after 6.903 msecs
>> [   16.116356] PM: noirq suspend of devices complete after 5.912 msecs
>> [   16.121213] Disabling non-boot CPUs ...
>> [   16.154140] IRQ51 no longer affine to CPU1
>> [   16.154709] CPU1: shutdown
>> [   16.214148] IRQ52 no longer affine to CPU2
>> [   16.214646] CPU2: shutdown
>> [   16.273980] IRQ53 no longer affine to CPU3
>> [   16.274458] CPU3: shutdown
>> [   16.335093] IRQ54 no longer affine to CPU4
>> [   16.336033] CPU4: shutdown
>> [   16.389979] IRQ55 no longer affine to CPU5
>> [   16.390823] CPU5: shutdown
>> [   16.444829] IRQ56 no longer affine to CPU6
>> [   16.445621] CPU6: shutdown
>> [   16.509229] cpu cpu4: Failed to find opp_table: -19
>> [   16.514008] IRQ57 no longer affine to CPU7
>> [   16.514824] CPU7: shutdown
> 
> Hi,
> 
> Yes you have found a real bug it seems. I think that can be reproduced
> by a simple rmmmod of cpufreq-dt.ko module as well.
> 
> Though the solution you provided isn't good enough.
> 
> Consider for example a case where you do this:
> - offline CPU 4
> - suspend the system
> 
> You are going to get stuck in the exact same problem again.
> 
> I have sent a separate patch and cc'd you. Can you please verify that
> it works for you ?
> 

Thanks for the patch, i tested it and it is working well.

Thanks.

Re: [PATCH] PM / OPP: fix CPU device to be removed from OPP table in wrong order

[Joonyoung Shim]

Hi Viresh,

On 11/25/2016 03:57 PM, Viresh Kumar wrote:
> On 25-11-16, 10:54, Joonyoung Shim wrote:
>> I found this problem during system suspend/resume of Odroid-XU3 board.
>>
>> # rtcwake -m mem -s 3
>> wakeup from "mem" at Wed Apr  4 05:54:44 2001
>> [   15.965996] PM: Syncing filesystems ... done.
>> [   15.976333] Freezing user space processes ... (elapsed 0.002 seconds) 
>> done.
>> [   15.983287] Freezing remaining freezable tasks ... (elapsed 0.002 
>> seconds) done.
>> [   16.006951] wake enabled for irq 135
>> [   16.008782] smsc95xx 1-1.1:1.0 eth0: entering SUSPEND2 mode
>> [   16.094110] PM: suspend of devices complete after 95.038 msecs
>> [   16.105648] PM: late suspend of devices complete after 6.903 msecs
>> [   16.116356] PM: noirq suspend of devices complete after 5.912 msecs
>> [   16.121213] Disabling non-boot CPUs ...
>> [   16.154140] IRQ51 no longer affine to CPU1
>> [   16.154709] CPU1: shutdown
>> [   16.214148] IRQ52 no longer affine to CPU2
>> [   16.214646] CPU2: shutdown
>> [   16.273980] IRQ53 no longer affine to CPU3
>> [   16.274458] CPU3: shutdown
>> [   16.335093] IRQ54 no longer affine to CPU4
>> [   16.336033] CPU4: shutdown
>> [   16.389979] IRQ55 no longer affine to CPU5
>> [   16.390823] CPU5: shutdown
>> [   16.444829] IRQ56 no longer affine to CPU6
>> [   16.445621] CPU6: shutdown
>> [   16.509229] cpu cpu4: Failed to find opp_table: -19
>> [   16.514008] IRQ57 no longer affine to CPU7
>> [   16.514824] CPU7: shutdown
> 
> Hi,
> 
> Yes you have found a real bug it seems. I think that can be reproduced
> by a simple rmmmod of cpufreq-dt.ko module as well.
> 
> Though the solution you provided isn't good enough.
> 
> Consider for example a case where you do this:
> - offline CPU 4
> - suspend the system
> 
> You are going to get stuck in the exact same problem again.
> 
> I have sent a separate patch and cc'd you. Can you please verify that
> it works for you ?
> 

Thanks for the patch, i tested it and it is working well.

Thanks.

Re: [PATCH] PM / OPP: Allow inactive opp_device to be present in dev list

[Joonyoung Shim]

On 11/25/2016 03:53 PM, Viresh Kumar wrote:
> Joonyoung Shim reported an interesting problem on his ARM octa-core
> Odoroid-XU3 platform. During system suspend, dev_pm_opp_put_regulator()
> was failing for a struct device for which dev_pm_opp_set_regulator() is
> called earlier.
> 
> This happened because an earlier call to
> dev_pm_opp_of_cpumask_remove_table() function (from cpufreq-dt.c file)
> removed all the entries from opp_table->dev_list apart from the last CPU
> device in the cpumask of CPUs sharing the OPP.
> 
> But both dev_pm_opp_set_regulator() and dev_pm_opp_put_regulator()
> routines get CPU device for the first CPU in the cpumask. And so the OPP
> core failed to find the OPP table for the struct device.
> 
> This patch attempts to fix this problem by adding another field in the
> struct opp_device: inactive.
> 
> Instead of removing the entries from the list during
> dev_pm_opp_of_cpumask_remove_table() function call, we mark them as
> inactive. Such inactive devices will not be used by the core in most of
> the cases, like before, but will be used only at special places which
> need to take inactive devices into account.
> 
> All the devices are removed from the list together now and that happens
> only when the opp_table gets destroyed.
> 
> This patch is tested on Dual A15, Exynos5250 platform by compiling the
> cpufreq-dt driver as a module. The module is inserted/removed multiple
> times with combinations of CPU offline/online steps.
> 
> Signed-off-by: Viresh Kumar <viresh.ku...@linaro.org>

It's working well during system suspend/resume on my Odroid-XU3 board.

Tested-by: Joonyoung Shim <jy0922.s...@samsung.com>

Thanks.

Re: [PATCH] PM / OPP: Allow inactive opp_device to be present in dev list

[Joonyoung Shim]

On 11/25/2016 03:53 PM, Viresh Kumar wrote:
> Joonyoung Shim reported an interesting problem on his ARM octa-core
> Odoroid-XU3 platform. During system suspend, dev_pm_opp_put_regulator()
> was failing for a struct device for which dev_pm_opp_set_regulator() is
> called earlier.
> 
> This happened because an earlier call to
> dev_pm_opp_of_cpumask_remove_table() function (from cpufreq-dt.c file)
> removed all the entries from opp_table->dev_list apart from the last CPU
> device in the cpumask of CPUs sharing the OPP.
> 
> But both dev_pm_opp_set_regulator() and dev_pm_opp_put_regulator()
> routines get CPU device for the first CPU in the cpumask. And so the OPP
> core failed to find the OPP table for the struct device.
> 
> This patch attempts to fix this problem by adding another field in the
> struct opp_device: inactive.
> 
> Instead of removing the entries from the list during
> dev_pm_opp_of_cpumask_remove_table() function call, we mark them as
> inactive. Such inactive devices will not be used by the core in most of
> the cases, like before, but will be used only at special places which
> need to take inactive devices into account.
> 
> All the devices are removed from the list together now and that happens
> only when the opp_table gets destroyed.
> 
> This patch is tested on Dual A15, Exynos5250 platform by compiling the
> cpufreq-dt driver as a module. The module is inserted/removed multiple
> times with combinations of CPU offline/online steps.
> 
> Signed-off-by: Viresh Kumar 

It's working well during system suspend/resume on my Odroid-XU3 board.

Tested-by: Joonyoung Shim 

Thanks.

Re: [PATCH] PM / OPP: fix CPU device to be removed from OPP table in wrong order

[Joonyoung Shim]

Hi Viresh.

On 11/24/2016 05:34 PM, Viresh Kumar wrote:
> Ho Joonyoung,
> 
> On 24-11-16, 16:49, Joonyoung Shim wrote:
>> The device that creates OPP table first should be removed from dev_list
>> of OPP table in last because it can be used by other resources
>> (supported_hw, prop_name, regulator), but not now.
> 
> I am not sure what you are trying to do here? Why can't the CPU which
> added the OPP should be removed last.
> 
> Can you give a real example where you see a problem ?
> 
>> If OPP table is
>> shared by several CPUs, the CPU device that creates OPP table can be
>> removed earlier than other CPU devices.
> 
> I don't think that's a problem, though I can be wrong for sure.
> 

I found this problem during system suspend/resume of Odroid-XU3 board.

# rtcwake -m mem -s 3
wakeup from "mem" at Wed Apr  4 05:54:44 2001
[   15.965996] PM: Syncing filesystems ... done.
[   15.976333] Freezing user space processes ... (elapsed 0.002 seconds) done.
[   15.983287] Freezing remaining freezable tasks ... (elapsed 0.002 seconds) 
done.
[   16.006951] wake enabled for irq 135
[   16.008782] smsc95xx 1-1.1:1.0 eth0: entering SUSPEND2 mode
[   16.094110] PM: suspend of devices complete after 95.038 msecs
[   16.105648] PM: late suspend of devices complete after 6.903 msecs
[   16.116356] PM: noirq suspend of devices complete after 5.912 msecs
[   16.121213] Disabling non-boot CPUs ...
[   16.154140] IRQ51 no longer affine to CPU1
[   16.154709] CPU1: shutdown
[   16.214148] IRQ52 no longer affine to CPU2
[   16.214646] CPU2: shutdown
[   16.273980] IRQ53 no longer affine to CPU3
[   16.274458] CPU3: shutdown
[   16.335093] IRQ54 no longer affine to CPU4
[   16.336033] CPU4: shutdown
[   16.389979] IRQ55 no longer affine to CPU5
[   16.390823] CPU5: shutdown
[   16.444829] IRQ56 no longer affine to CPU6
[   16.445621] CPU6: shutdown
[   16.509229] cpu cpu4: Failed to find opp_table: -19
[   16.514008] IRQ57 no longer affine to CPU7
[   16.514824] CPU7: shutdown

CPU4-7 are offline on after system resume.

Above -19 error occurs because cannot find OPP table for CPU4 from
dev_pm_opp_put_regulator() when regulator resource for CPU4 is put.

Odroid-XU3 board uses exynos5422 SoCs having 8 CPUs (4 little cores / 
4 bit cores). CPU0-3 (little core) shares a OPP table and CPU4-7
(bit core) shares a OPP table (operating-points-v2 binding). CPU0 and
CPU4 have each regulators. You can find them from below dts files,

arch/arm/boot/dts/exynos5420.dtsi
arch/arm/boot/dts/exynos5422-cpus.dtsi
arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi

Let's see CPU4-7 case. A OPP tables are created by device of CPU4 from
cpufreq_init() of drivers/cpufreq/cpufreq-dt.c. Each OPP devices of
CPU4-7 are registered at dev_list of OPP table created by CPU4 device
as CPU4 - CPU5 - CPU6 - CPU7 order. And regulator resource for CPU4 uses
OPP device of CPU4. 

The cpufreq_exit() tries to free OPP table for CPU4-7 during system
suspend. It will remove OPP devices as CPU4 - CPU5 - CPU6 - CPU7 order,
then only OPP device for CPU7 remains before regulator resource of CPU4
is put, but it needs CPU4 OPP device that creates OPP table to put
regulator resource of CPU4, not CPU7 OPP device.

This patch will make to remove OPP devices as CPU5 - CPU6 - CPU7 - CPU4
order.

As another way, we can consider reference count for OPP device. Above
problem occurs because CPU4 and regulator of CPU4 use same OPP device.

Any ideas?

Thanks.

Re: [PATCH] PM / OPP: fix CPU device to be removed from OPP table in wrong order

[Joonyoung Shim]

Hi Viresh.

On 11/24/2016 05:34 PM, Viresh Kumar wrote:
> Ho Joonyoung,
> 
> On 24-11-16, 16:49, Joonyoung Shim wrote:
>> The device that creates OPP table first should be removed from dev_list
>> of OPP table in last because it can be used by other resources
>> (supported_hw, prop_name, regulator), but not now.
> 
> I am not sure what you are trying to do here? Why can't the CPU which
> added the OPP should be removed last.
> 
> Can you give a real example where you see a problem ?
> 
>> If OPP table is
>> shared by several CPUs, the CPU device that creates OPP table can be
>> removed earlier than other CPU devices.
> 
> I don't think that's a problem, though I can be wrong for sure.
> 

I found this problem during system suspend/resume of Odroid-XU3 board.

# rtcwake -m mem -s 3
wakeup from "mem" at Wed Apr  4 05:54:44 2001
[   15.965996] PM: Syncing filesystems ... done.
[   15.976333] Freezing user space processes ... (elapsed 0.002 seconds) done.
[   15.983287] Freezing remaining freezable tasks ... (elapsed 0.002 seconds) 
done.
[   16.006951] wake enabled for irq 135
[   16.008782] smsc95xx 1-1.1:1.0 eth0: entering SUSPEND2 mode
[   16.094110] PM: suspend of devices complete after 95.038 msecs
[   16.105648] PM: late suspend of devices complete after 6.903 msecs
[   16.116356] PM: noirq suspend of devices complete after 5.912 msecs
[   16.121213] Disabling non-boot CPUs ...
[   16.154140] IRQ51 no longer affine to CPU1
[   16.154709] CPU1: shutdown
[   16.214148] IRQ52 no longer affine to CPU2
[   16.214646] CPU2: shutdown
[   16.273980] IRQ53 no longer affine to CPU3
[   16.274458] CPU3: shutdown
[   16.335093] IRQ54 no longer affine to CPU4
[   16.336033] CPU4: shutdown
[   16.389979] IRQ55 no longer affine to CPU5
[   16.390823] CPU5: shutdown
[   16.444829] IRQ56 no longer affine to CPU6
[   16.445621] CPU6: shutdown
[   16.509229] cpu cpu4: Failed to find opp_table: -19
[   16.514008] IRQ57 no longer affine to CPU7
[   16.514824] CPU7: shutdown

CPU4-7 are offline on after system resume.

Above -19 error occurs because cannot find OPP table for CPU4 from
dev_pm_opp_put_regulator() when regulator resource for CPU4 is put.

Odroid-XU3 board uses exynos5422 SoCs having 8 CPUs (4 little cores / 
4 bit cores). CPU0-3 (little core) shares a OPP table and CPU4-7
(bit core) shares a OPP table (operating-points-v2 binding). CPU0 and
CPU4 have each regulators. You can find them from below dts files,

arch/arm/boot/dts/exynos5420.dtsi
arch/arm/boot/dts/exynos5422-cpus.dtsi
arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi

Let's see CPU4-7 case. A OPP tables are created by device of CPU4 from
cpufreq_init() of drivers/cpufreq/cpufreq-dt.c. Each OPP devices of
CPU4-7 are registered at dev_list of OPP table created by CPU4 device
as CPU4 - CPU5 - CPU6 - CPU7 order. And regulator resource for CPU4 uses
OPP device of CPU4. 

The cpufreq_exit() tries to free OPP table for CPU4-7 during system
suspend. It will remove OPP devices as CPU4 - CPU5 - CPU6 - CPU7 order,
then only OPP device for CPU7 remains before regulator resource of CPU4
is put, but it needs CPU4 OPP device that creates OPP table to put
regulator resource of CPU4, not CPU7 OPP device.

This patch will make to remove OPP devices as CPU5 - CPU6 - CPU7 - CPU4
order.

As another way, we can consider reference count for OPP device. Above
problem occurs because CPU4 and regulator of CPU4 use same OPP device.

Any ideas?

Thanks.

[PATCH] PM / OPP: fix CPU device to be removed from OPP table in wrong order

[Joonyoung Shim]

The device that creates OPP table first should be removed from dev_list
of OPP table in last because it can be used by other resources
(supported_hw, prop_name, regulator), but not now. If OPP table is
shared by several CPUs, the CPU device that creates OPP table can be
removed earlier than other CPU devices.

This patch makes that the CPU device that creates OPP table is removed
last.

Signed-off-by: Joonyoung Shim <jy0922.s...@samsung.com>
---
 drivers/base/power/opp/cpu.c | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/drivers/base/power/opp/cpu.c b/drivers/base/power/opp/cpu.c
index 8c3434bdb26d..9d0773a237f8 100644
--- a/drivers/base/power/opp/cpu.c
+++ b/drivers/base/power/opp/cpu.c
@@ -118,9 +118,36 @@ void dev_pm_opp_free_cpufreq_table(struct device *dev,
 EXPORT_SYMBOL_GPL(dev_pm_opp_free_cpufreq_table);
 #endif /* CONFIG_CPU_FREQ */
 
+static bool dev_pm_opp_is_removed_last(struct device *dev)
+{
+   struct opp_device *opp_dev;
+   struct opp_table *opp_table;
+   bool ret = false;
+
+   mutex_lock(_table_lock);
+
+   opp_table = _find_opp_table(dev);
+   if (IS_ERR(opp_table))
+   goto unlock;
+
+   if (list_is_singular(_table->dev_list))
+   goto unlock;
+
+   opp_dev = list_last_entry(_table->dev_list, struct opp_device,
+ node);
+   if (opp_dev->dev == dev)
+   ret = true;
+
+unlock:
+   mutex_unlock(_table_lock);
+
+   return ret;
+}
+
 void _dev_pm_opp_cpumask_remove_table(const struct cpumask *cpumask, bool of)
 {
struct device *cpu_dev;
+   struct device *last = NULL;
int cpu;
 
WARN_ON(cpumask_empty(cpumask));
@@ -133,11 +160,23 @@ void _dev_pm_opp_cpumask_remove_table(const struct 
cpumask *cpumask, bool of)
continue;
}
 
+   if (!last && dev_pm_opp_is_removed_last(cpu_dev)) {
+   last = cpu_dev;
+   continue;
+   }
+
if (of)
dev_pm_opp_of_remove_table(cpu_dev);
else
dev_pm_opp_remove_table(cpu_dev);
}
+
+   if (last) {
+   if (of)
+   dev_pm_opp_of_remove_table(last);
+   else
+   dev_pm_opp_remove_table(last);
+   }
 }
 
 /**
-- 
1.9.1

[PATCH] PM / OPP: fix CPU device to be removed from OPP table in wrong order

[Joonyoung Shim]

The device that creates OPP table first should be removed from dev_list
of OPP table in last because it can be used by other resources
(supported_hw, prop_name, regulator), but not now. If OPP table is
shared by several CPUs, the CPU device that creates OPP table can be
removed earlier than other CPU devices.

This patch makes that the CPU device that creates OPP table is removed
last.

Signed-off-by: Joonyoung Shim 
---
 drivers/base/power/opp/cpu.c | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/drivers/base/power/opp/cpu.c b/drivers/base/power/opp/cpu.c
index 8c3434bdb26d..9d0773a237f8 100644
--- a/drivers/base/power/opp/cpu.c
+++ b/drivers/base/power/opp/cpu.c
@@ -118,9 +118,36 @@ void dev_pm_opp_free_cpufreq_table(struct device *dev,
 EXPORT_SYMBOL_GPL(dev_pm_opp_free_cpufreq_table);
 #endif /* CONFIG_CPU_FREQ */
 
+static bool dev_pm_opp_is_removed_last(struct device *dev)
+{
+   struct opp_device *opp_dev;
+   struct opp_table *opp_table;
+   bool ret = false;
+
+   mutex_lock(_table_lock);
+
+   opp_table = _find_opp_table(dev);
+   if (IS_ERR(opp_table))
+   goto unlock;
+
+   if (list_is_singular(_table->dev_list))
+   goto unlock;
+
+   opp_dev = list_last_entry(_table->dev_list, struct opp_device,
+ node);
+   if (opp_dev->dev == dev)
+   ret = true;
+
+unlock:
+   mutex_unlock(_table_lock);
+
+   return ret;
+}
+
 void _dev_pm_opp_cpumask_remove_table(const struct cpumask *cpumask, bool of)
 {
struct device *cpu_dev;
+   struct device *last = NULL;
int cpu;
 
WARN_ON(cpumask_empty(cpumask));
@@ -133,11 +160,23 @@ void _dev_pm_opp_cpumask_remove_table(const struct 
cpumask *cpumask, bool of)
continue;
}
 
+   if (!last && dev_pm_opp_is_removed_last(cpu_dev)) {
+   last = cpu_dev;
+   continue;
+   }
+
if (of)
dev_pm_opp_of_remove_table(cpu_dev);
else
dev_pm_opp_remove_table(cpu_dev);
}
+
+   if (last) {
+   if (of)
+   dev_pm_opp_of_remove_table(last);
+   else
+   dev_pm_opp_remove_table(last);
+   }
 }
 
 /**
-- 
1.9.1

Re: [PATCH] pwm: samsung: fix to use lowest div for large enough modulation bits

[Joonyoung Shim]

Hi,

On 08/02/2016 07:16 PM, Seung-Woo Kim wrote:
>>From pwm_samsung_calc_tin(), there is routine to find the lowest
> divider possible to generate lower frequency than requested one.
> But it is always possible to generate requested frequency with
> large enough modulation bits, so this patch fixes to use lowest
> div for the case. This patch removes following UBSAN warning:
> 
>UBSAN: Undefined behaviour in drivers/pwm/pwm-samsung.c:197:13
>shift exponent 32 is too large for 32-bit type 'long unsigned int'
>[...]
>[] (ubsan_epilogue) from [] 
> (__ubsan_handle_shift_out_of_bounds+0xd8/0x120)
>[] (__ubsan_handle_shift_out_of_bounds) from [] 
> (pwm_samsung_config+0x508/0x6a4)
>[] (pwm_samsung_config) from [] 
> (pwm_apply_state+0x174/0x40c)
>[] (pwm_apply_state) from [] (pwm_fan_probe+0xc8/0x488)
>[] (pwm_fan_probe) from [] 
> (platform_drv_probe+0x70/0x150)
>[...]
> 
> Signed-off-by: Seung-Woo Kim <sw0312@samsung.com>
> ---
> The UBSAN warning from ARM is reported with the patch in following link:
> https://patchwork.kernel.org/patch/9189575/
> ---
>  drivers/pwm/pwm-samsung.c |   10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/pwm/pwm-samsung.c b/drivers/pwm/pwm-samsung.c
> index ada2d32..ff0def6 100644
> --- a/drivers/pwm/pwm-samsung.c
> +++ b/drivers/pwm/pwm-samsung.c
> @@ -193,9 +193,13 @@ static unsigned long pwm_samsung_calc_tin(struct 
> samsung_pwm_chip *chip,
>* divider settings and choose the lowest divisor that can generate
>* frequencies lower than requested.
>*/
> - for (div = variant->div_base; div < 4; ++div)
> - if ((rate >> (variant->bits + div)) < freq)
> - break;
> + if (fls(rate) <= variant->bits) {
> + div = variant->div_base;

It's reasonable to me not to check to decide div at above case.

> + } else {
> + for (div = variant->div_base; div < 4; ++div)
> + if ((rate >> (variant->bits + div)) < freq)
> + break;
> + }
>  

Reviewed-by: Joonyoung Shim <jy0922.s...@samsung.com>

Thanks.

Re: [PATCH] pwm: samsung: fix to use lowest div for large enough modulation bits

[Joonyoung Shim]

Hi,

On 08/02/2016 07:16 PM, Seung-Woo Kim wrote:
>>From pwm_samsung_calc_tin(), there is routine to find the lowest
> divider possible to generate lower frequency than requested one.
> But it is always possible to generate requested frequency with
> large enough modulation bits, so this patch fixes to use lowest
> div for the case. This patch removes following UBSAN warning:
> 
>UBSAN: Undefined behaviour in drivers/pwm/pwm-samsung.c:197:13
>shift exponent 32 is too large for 32-bit type 'long unsigned int'
>[...]
>[] (ubsan_epilogue) from [] 
> (__ubsan_handle_shift_out_of_bounds+0xd8/0x120)
>[] (__ubsan_handle_shift_out_of_bounds) from [] 
> (pwm_samsung_config+0x508/0x6a4)
>[] (pwm_samsung_config) from [] 
> (pwm_apply_state+0x174/0x40c)
>[] (pwm_apply_state) from [] (pwm_fan_probe+0xc8/0x488)
>[] (pwm_fan_probe) from [] 
> (platform_drv_probe+0x70/0x150)
>[...]
> 
> Signed-off-by: Seung-Woo Kim 
> ---
> The UBSAN warning from ARM is reported with the patch in following link:
> https://patchwork.kernel.org/patch/9189575/
> ---
>  drivers/pwm/pwm-samsung.c |   10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/pwm/pwm-samsung.c b/drivers/pwm/pwm-samsung.c
> index ada2d32..ff0def6 100644
> --- a/drivers/pwm/pwm-samsung.c
> +++ b/drivers/pwm/pwm-samsung.c
> @@ -193,9 +193,13 @@ static unsigned long pwm_samsung_calc_tin(struct 
> samsung_pwm_chip *chip,
>* divider settings and choose the lowest divisor that can generate
>* frequencies lower than requested.
>*/
> - for (div = variant->div_base; div < 4; ++div)
> - if ((rate >> (variant->bits + div)) < freq)
> - break;
> + if (fls(rate) <= variant->bits) {
> + div = variant->div_base;

It's reasonable to me not to check to decide div at above case.

> + } else {
> + for (div = variant->div_base; div < 4; ++div)
> + if ((rate >> (variant->bits + div)) < freq)
> + break;
> + }
>  

Reviewed-by: Joonyoung Shim 

Thanks.

[PATCH v2] rtc: s5m: fix to update ctrl register

[Joonyoung Shim]

According to datasheet, the S2MPS13X and S2MPS14X should update write
buffer via setting WUDR bit to high after ctrl register is written.

If not, ALARM interrupt of rtc-s5m doesn't happen first time when i use
tools/testing/selftests/timers/rtctest.c test program and hour format is
used to 12 hour mode in Odroid-XU3 board.

One more issue is the RTC doesn't keep time on Odroid-XU3 board when i
turn on board after power off even if RTC battery is connected. It can
be solved as setting WUDR & RUDR bits to high at the same time after
RTC_CTRL register is written. It's same with condition of only writing
ALARM registers, so this is for only S2MPS14 and we should set WUDR &
A_UDR bits to high on S2MPS13.

I can't find any reasonable description about this like fix from
datasheet, but can find similar codes from rtc driver source of
hardkernel kernel and vender kernel.

Signed-off-by: Joonyoung Shim 
Cc:  # v3.16
---
Changelog for v2:
- update commit description and code to fix time keeping problem
- update the stable tag with the kernel version

 drivers/rtc/rtc-s5m.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/rtc/rtc-s5m.c b/drivers/rtc/rtc-s5m.c
index 8c70d78..646bf45 100644
--- a/drivers/rtc/rtc-s5m.c
+++ b/drivers/rtc/rtc-s5m.c
@@ -635,6 +635,16 @@ static int s5m8767_rtc_init_reg(struct s5m_rtc_info *info)
case S2MPS13X:
data[0] = (0 << BCD_EN_SHIFT) | (1 << MODEL24_SHIFT);
ret = regmap_write(info->regmap, info->regs->ctrl, data[0]);
+   if (ret < 0)
+   break;
+
+   /*
+* Should set WUDR & (RUDR or AUDR) bits to high after writing
+* RTC_CTRL register like writing Alarm registers. We can't find
+* the description from datasheet but vender code does that
+* really.
+*/
+   ret = s5m8767_rtc_set_alarm_reg(info);
break;
 
default:
-- 
1.9.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/

Re: [PATCH] rtc: s5m: fix to update ctrl register

[Joonyoung Shim]

On 08/21/2015 04:25 PM, Krzysztof Kozlowski wrote:
> On 21.08.2015 15:58, Joonyoung Shim wrote:
>> On 08/21/2015 10:21 AM, Krzysztof Kozlowski wrote:
>>> On 21.08.2015 10:00, Joonyoung Shim wrote:
>>>> On 08/21/2015 09:44 AM, Krzysztof Kozlowski wrote:
>>>>> On 21.08.2015 08:15, Alexandre Belloni wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 13/08/2015 at 17:49:24 +0900, Joonyoung Shim wrote :
>>>>>>> According to datasheet, the S2MPS13X and S2MPS14X should update write
>>>>>>> buffer via setting WUDR bit to high after ctrl register is updated.
>>>>>>>
>>>>>>> If not, ALARM interrupt of rtc-s5m doesn't happen first time when i use
>>>>>>> tools/testing/selftests/timers/rtctest.c test program and hour format is
>>>>>>> used to 12 hour mode in Odroid-XU3 board.
>>>>>>>
>>>>>>
>>>>>> >From what I understood, I should expect a v2 of tihat patch also setting
>>>>>> RUDR, is that right? OR would you prefer that I apply that one and then
>>>>>> fix RUDR in a following patch?
>>>>>
>>>>> Right, I would expect that as well... or a comment if this is not needed.
>>>>>
>>>>
>>>> Hmm, the driver only writes control register now, so i don't feel the
>>>> need of patch setting RUDR for control register.
>>>
>>> Yes, you're right. There is only regmap_write() (not
>>> remap_update_bits()) so your patch is completely fine. Thanks for
>>> explanation.
>>>
>>> Reviewed-by: Krzysztof Kozlowski 
>>>
>>
>> Thanks for review.
>>
>> I found one more issue, the RTC doesn't keep time on Odroid-XU3 board
>> when i turn on board after power off even if RTC battery is connected.
>>
>> A difference with RTC driver of hardkernel kernel is that it sets
>> not only WUDR bit but also RUDR bit to high at the same time after
>> RTC_CTRL register is written. It's same with condition of only writing
>> ALARM registers like below description.
> 
> It seems that setting RUDR to high is needed...  but it shouldn't. For
> example in SM-G900H with S2MPS11 it is set before reading RTC_CTRL
> register. Mainline driver does not perform read.
> 
> Maybe RUDR is not set high properly before some next time read and your
> code is a coincidence, a work-around?

As you know, the driver sets RUDR bit to high always before reads time.
I'm not sure whether any delay time needs to guarantee that RUDR bit is
set properly, but it fails keeping time.

I tried setting RUDR bit to high after or before setting WUDR bit to
high for writing of RTC_CTRL register but it also fails keeping time.
If achieve keeping time, i should set WUDR & RUDR bits to high at the
same time.

I'm referring also rtc-sec driver source of SM-N910U_SEA(Samsung Note4)
from SM-N910U_SEA_KK_Opensource.zip file[1]. It also does the same
operation setting WUDR & RUDR bits to high for writing of RTC_CTRL
register.

[1] 
http://opensource.samsung.com/reception/receptionSub.do?method=sub=F=N910U

> 
> Best regards,
> Krzysztof
> 
>>
>> from S2MPS14 datasheet:
>> "3.  For write only Alarm 0&1 Registers (0x0B~0x18), set WUDR & RUDR
>> bits to high."
>>
>> So i tried it and it works well with keeping time. I'm not sure RTC of
>> S2MPS13 type also has a similar issue because it differs a little bit.
>>
>> from S2MPS13 datasheet:
>> "3.  For write only Alarm 0&1 Registers (0x0B~0x18), set WUDR & A_UDR
>> bits to high."
>>
>> If S2MPS13 also has same issue, we can fix the problem via just below
>> patch.
>>
>> diff --git a/drivers/rtc/rtc-s5m.c b/drivers/rtc/rtc-s5m.c
>> index 8c70d78..bb8e888 100644
>> --- a/drivers/rtc/rtc-s5m.c
>> +++ b/drivers/rtc/rtc-s5m.c
>> @@ -635,6 +635,10 @@ static int s5m8767_rtc_init_reg(struct s5m_rtc_info 
>> *info)
>>  case S2MPS13X:
>>  data[0] = (0 << BCD_EN_SHIFT) | (1 << MODEL24_SHIFT);
>>  ret = regmap_write(info->regmap, info->regs->ctrl, data[0]);
>> +if (ret < 0)
>> +break;
>> +
>> +ret = s5m8767_rtc_set_alarm_reg(info);
>>  break;
>>  
>>  default:
>>
>> But i can't find any reasonable reason about this fix from datasheet,
>>
>> Thanks.
>>
>>> Best regards,
>>> Krzysztof
>>>
>>>>
>>>>> Best regards,
>&g

Re: [PATCH] rtc: s5m: fix to update ctrl register

[Joonyoung Shim]

On 08/21/2015 10:21 AM, Krzysztof Kozlowski wrote:
> On 21.08.2015 10:00, Joonyoung Shim wrote:
>> On 08/21/2015 09:44 AM, Krzysztof Kozlowski wrote:
>>> On 21.08.2015 08:15, Alexandre Belloni wrote:
>>>> Hi,
>>>>
>>>> On 13/08/2015 at 17:49:24 +0900, Joonyoung Shim wrote :
>>>>> According to datasheet, the S2MPS13X and S2MPS14X should update write
>>>>> buffer via setting WUDR bit to high after ctrl register is updated.
>>>>>
>>>>> If not, ALARM interrupt of rtc-s5m doesn't happen first time when i use
>>>>> tools/testing/selftests/timers/rtctest.c test program and hour format is
>>>>> used to 12 hour mode in Odroid-XU3 board.
>>>>>
>>>>
>>>> >From what I understood, I should expect a v2 of tihat patch also setting
>>>> RUDR, is that right? OR would you prefer that I apply that one and then
>>>> fix RUDR in a following patch?
>>>
>>> Right, I would expect that as well... or a comment if this is not needed.
>>>
>>
>> Hmm, the driver only writes control register now, so i don't feel the
>> need of patch setting RUDR for control register.
> 
> Yes, you're right. There is only regmap_write() (not
> remap_update_bits()) so your patch is completely fine. Thanks for
> explanation.
> 
> Reviewed-by: Krzysztof Kozlowski 
> 

Thanks for review.

I found one more issue, the RTC doesn't keep time on Odroid-XU3 board
when i turn on board after power off even if RTC battery is connected.

A difference with RTC driver of hardkernel kernel is that it sets
not only WUDR bit but also RUDR bit to high at the same time after
RTC_CTRL register is written. It's same with condition of only writing
ALARM registers like below description.

from S2MPS14 datasheet:
"3.  For write only Alarm 0&1 Registers (0x0B~0x18), set WUDR & RUDR
bits to high."

So i tried it and it works well with keeping time. I'm not sure RTC of
S2MPS13 type also has a similar issue because it differs a little bit.

from S2MPS13 datasheet:
"3.  For write only Alarm 0&1 Registers (0x0B~0x18), set WUDR & A_UDR
bits to high."

If S2MPS13 also has same issue, we can fix the problem via just below
patch.

diff --git a/drivers/rtc/rtc-s5m.c b/drivers/rtc/rtc-s5m.c
index 8c70d78..bb8e888 100644
--- a/drivers/rtc/rtc-s5m.c
+++ b/drivers/rtc/rtc-s5m.c
@@ -635,6 +635,10 @@ static int s5m8767_rtc_init_reg(struct s5m_rtc_info *info)
case S2MPS13X:
data[0] = (0 << BCD_EN_SHIFT) | (1 << MODEL24_SHIFT);
ret = regmap_write(info->regmap, info->regs->ctrl, data[0]);
+   if (ret < 0)
+   break;
+
+   ret = s5m8767_rtc_set_alarm_reg(info);
break;
 
default:

But i can't find any reasonable reason about this fix from datasheet,

Thanks.

> Best regards,
> Krzysztof
> 
>>
>>> Best regards,
>>> Krzysztof
>>>
>>>
>>>>
>>>>> Signed-off-by: Joonyoung Shim 
>>>>> Cc: 
>>>>
>>>> can you update the stable tag with the kernel version introducing the
>>>> issue?
>>
>> Sure, i think it should be v3.16.
>>
>>>>
>>>>> ---
>>>>>  drivers/rtc/rtc-s5m.c | 12 
>>>>>  1 file changed, 12 insertions(+)
>>>>
>>>>> diff --git a/drivers/rtc/rtc-s5m.c b/drivers/rtc/rtc-s5m.c
>>>>> index 8c70d78..03828bb 100644
>>>>> --- a/drivers/rtc/rtc-s5m.c
>>>>> +++ b/drivers/rtc/rtc-s5m.c
>>>>> @@ -635,6 +635,18 @@ static int s5m8767_rtc_init_reg(struct s5m_rtc_info 
>>>>> *info)
>>>>>   case S2MPS13X:
>>>>>   data[0] = (0 << BCD_EN_SHIFT) | (1 << MODEL24_SHIFT);
>>>>>   ret = regmap_write(info->regmap, info->regs->ctrl, data[0]);
>>>>> + if (ret < 0)
>>>>> + break;
>>>>> +
>>>>> + ret = regmap_update_bits(info->regmap,
>>>>> + info->regs->rtc_udr_update,
>>>>> + info->regs->rtc_udr_mask,
>>>>> + info->regs->rtc_udr_mask);
>>>>
>>>> Very small indentation issue here, it should be aligned with the open
>>>> parenthesis.
>>
>> OK, i will.
>>
>> Thanks.
>>
> 
> 

--
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] rtc: s5m: fix to update ctrl register

[Joonyoung Shim]

On 08/21/2015 10:21 AM, Krzysztof Kozlowski wrote:
 On 21.08.2015 10:00, Joonyoung Shim wrote:
 On 08/21/2015 09:44 AM, Krzysztof Kozlowski wrote:
 On 21.08.2015 08:15, Alexandre Belloni wrote:
 Hi,

 On 13/08/2015 at 17:49:24 +0900, Joonyoung Shim wrote :
 According to datasheet, the S2MPS13X and S2MPS14X should update write
 buffer via setting WUDR bit to high after ctrl register is updated.

 If not, ALARM interrupt of rtc-s5m doesn't happen first time when i use
 tools/testing/selftests/timers/rtctest.c test program and hour format is
 used to 12 hour mode in Odroid-XU3 board.


 From what I understood, I should expect a v2 of tihat patch also setting
 RUDR, is that right? OR would you prefer that I apply that one and then
 fix RUDR in a following patch?

 Right, I would expect that as well... or a comment if this is not needed.


 Hmm, the driver only writes control register now, so i don't feel the
 need of patch setting RUDR for control register.
 
 Yes, you're right. There is only regmap_write() (not
 remap_update_bits()) so your patch is completely fine. Thanks for
 explanation.
 
 Reviewed-by: Krzysztof Kozlowski k.kozlow...@samsung.com
 

Thanks for review.

I found one more issue, the RTC doesn't keep time on Odroid-XU3 board
when i turn on board after power off even if RTC battery is connected.

A difference with RTC driver of hardkernel kernel is that it sets
not only WUDR bit but also RUDR bit to high at the same time after
RTC_CTRL register is written. It's same with condition of only writing
ALARM registers like below description.

from S2MPS14 datasheet:
3.  For write only Alarm 01 Registers (0x0B~0x18), set WUDR  RUDR
bits to high.

So i tried it and it works well with keeping time. I'm not sure RTC of
S2MPS13 type also has a similar issue because it differs a little bit.

from S2MPS13 datasheet:
3.  For write only Alarm 01 Registers (0x0B~0x18), set WUDR  A_UDR
bits to high.

If S2MPS13 also has same issue, we can fix the problem via just below
patch.

diff --git a/drivers/rtc/rtc-s5m.c b/drivers/rtc/rtc-s5m.c
index 8c70d78..bb8e888 100644
--- a/drivers/rtc/rtc-s5m.c
+++ b/drivers/rtc/rtc-s5m.c
@@ -635,6 +635,10 @@ static int s5m8767_rtc_init_reg(struct s5m_rtc_info *info)
case S2MPS13X:
data[0] = (0  BCD_EN_SHIFT) | (1  MODEL24_SHIFT);
ret = regmap_write(info-regmap, info-regs-ctrl, data[0]);
+   if (ret  0)
+   break;
+
+   ret = s5m8767_rtc_set_alarm_reg(info);
break;
 
default:

But i can't find any reasonable reason about this fix from datasheet,

Thanks.

 Best regards,
 Krzysztof
 

 Best regards,
 Krzysztof



 Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
 Cc: sta...@vger.kernel.org

 can you update the stable tag with the kernel version introducing the
 issue?

 Sure, i think it should be v3.16.


 ---
  drivers/rtc/rtc-s5m.c | 12 
  1 file changed, 12 insertions(+)

 diff --git a/drivers/rtc/rtc-s5m.c b/drivers/rtc/rtc-s5m.c
 index 8c70d78..03828bb 100644
 --- a/drivers/rtc/rtc-s5m.c
 +++ b/drivers/rtc/rtc-s5m.c
 @@ -635,6 +635,18 @@ static int s5m8767_rtc_init_reg(struct s5m_rtc_info 
 *info)
   case S2MPS13X:
   data[0] = (0  BCD_EN_SHIFT) | (1  MODEL24_SHIFT);
   ret = regmap_write(info-regmap, info-regs-ctrl, data[0]);
 + if (ret  0)
 + break;
 +
 + ret = regmap_update_bits(info-regmap,
 + info-regs-rtc_udr_update,
 + info-regs-rtc_udr_mask,
 + info-regs-rtc_udr_mask);

 Very small indentation issue here, it should be aligned with the open
 parenthesis.

 OK, i will.

 Thanks.

 
 

--
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] rtc: s5m: fix to update ctrl register

[Joonyoung Shim]

According to datasheet, the S2MPS13X and S2MPS14X should update write
buffer via setting WUDR bit to high after ctrl register is written.

If not, ALARM interrupt of rtc-s5m doesn't happen first time when i use
tools/testing/selftests/timers/rtctest.c test program and hour format is
used to 12 hour mode in Odroid-XU3 board.

One more issue is the RTC doesn't keep time on Odroid-XU3 board when i
turn on board after power off even if RTC battery is connected. It can
be solved as setting WUDR  RUDR bits to high at the same time after
RTC_CTRL register is written. It's same with condition of only writing
ALARM registers, so this is for only S2MPS14 and we should set WUDR 
A_UDR bits to high on S2MPS13.

I can't find any reasonable description about this like fix from
datasheet, but can find similar codes from rtc driver source of
hardkernel kernel and vender kernel.

Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
Cc: sta...@vger.kernel.org # v3.16
---
Changelog for v2:
- update commit description and code to fix time keeping problem
- update the stable tag with the kernel version

 drivers/rtc/rtc-s5m.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/rtc/rtc-s5m.c b/drivers/rtc/rtc-s5m.c
index 8c70d78..646bf45 100644
--- a/drivers/rtc/rtc-s5m.c
+++ b/drivers/rtc/rtc-s5m.c
@@ -635,6 +635,16 @@ static int s5m8767_rtc_init_reg(struct s5m_rtc_info *info)
case S2MPS13X:
data[0] = (0  BCD_EN_SHIFT) | (1  MODEL24_SHIFT);
ret = regmap_write(info-regmap, info-regs-ctrl, data[0]);
+   if (ret  0)
+   break;
+
+   /*
+* Should set WUDR  (RUDR or AUDR) bits to high after writing
+* RTC_CTRL register like writing Alarm registers. We can't find
+* the description from datasheet but vender code does that
+* really.
+*/
+   ret = s5m8767_rtc_set_alarm_reg(info);
break;
 
default:
-- 
1.9.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/

Re: [PATCH] rtc: s5m: fix to update ctrl register

[Joonyoung Shim]

On 08/21/2015 04:25 PM, Krzysztof Kozlowski wrote:
 On 21.08.2015 15:58, Joonyoung Shim wrote:
 On 08/21/2015 10:21 AM, Krzysztof Kozlowski wrote:
 On 21.08.2015 10:00, Joonyoung Shim wrote:
 On 08/21/2015 09:44 AM, Krzysztof Kozlowski wrote:
 On 21.08.2015 08:15, Alexandre Belloni wrote:
 Hi,

 On 13/08/2015 at 17:49:24 +0900, Joonyoung Shim wrote :
 According to datasheet, the S2MPS13X and S2MPS14X should update write
 buffer via setting WUDR bit to high after ctrl register is updated.

 If not, ALARM interrupt of rtc-s5m doesn't happen first time when i use
 tools/testing/selftests/timers/rtctest.c test program and hour format is
 used to 12 hour mode in Odroid-XU3 board.


 From what I understood, I should expect a v2 of tihat patch also setting
 RUDR, is that right? OR would you prefer that I apply that one and then
 fix RUDR in a following patch?

 Right, I would expect that as well... or a comment if this is not needed.


 Hmm, the driver only writes control register now, so i don't feel the
 need of patch setting RUDR for control register.

 Yes, you're right. There is only regmap_write() (not
 remap_update_bits()) so your patch is completely fine. Thanks for
 explanation.

 Reviewed-by: Krzysztof Kozlowski k.kozlow...@samsung.com


 Thanks for review.

 I found one more issue, the RTC doesn't keep time on Odroid-XU3 board
 when i turn on board after power off even if RTC battery is connected.

 A difference with RTC driver of hardkernel kernel is that it sets
 not only WUDR bit but also RUDR bit to high at the same time after
 RTC_CTRL register is written. It's same with condition of only writing
 ALARM registers like below description.
 
 It seems that setting RUDR to high is needed...  but it shouldn't. For
 example in SM-G900H with S2MPS11 it is set before reading RTC_CTRL
 register. Mainline driver does not perform read.
 
 Maybe RUDR is not set high properly before some next time read and your
 code is a coincidence, a work-around?

As you know, the driver sets RUDR bit to high always before reads time.
I'm not sure whether any delay time needs to guarantee that RUDR bit is
set properly, but it fails keeping time.

I tried setting RUDR bit to high after or before setting WUDR bit to
high for writing of RTC_CTRL register but it also fails keeping time.
If achieve keeping time, i should set WUDR  RUDR bits to high at the
same time.

I'm referring also rtc-sec driver source of SM-N910U_SEA(Samsung Note4)
from SM-N910U_SEA_KK_Opensource.zip file[1]. It also does the same
operation setting WUDR  RUDR bits to high for writing of RTC_CTRL
register.

[1] 
http://opensource.samsung.com/reception/receptionSub.do?method=subsub=FsearchValue=N910U

 
 Best regards,
 Krzysztof
 

 from S2MPS14 datasheet:
 3.  For write only Alarm 01 Registers (0x0B~0x18), set WUDR  RUDR
 bits to high.

 So i tried it and it works well with keeping time. I'm not sure RTC of
 S2MPS13 type also has a similar issue because it differs a little bit.

 from S2MPS13 datasheet:
 3.  For write only Alarm 01 Registers (0x0B~0x18), set WUDR  A_UDR
 bits to high.

 If S2MPS13 also has same issue, we can fix the problem via just below
 patch.

 diff --git a/drivers/rtc/rtc-s5m.c b/drivers/rtc/rtc-s5m.c
 index 8c70d78..bb8e888 100644
 --- a/drivers/rtc/rtc-s5m.c
 +++ b/drivers/rtc/rtc-s5m.c
 @@ -635,6 +635,10 @@ static int s5m8767_rtc_init_reg(struct s5m_rtc_info 
 *info)
  case S2MPS13X:
  data[0] = (0  BCD_EN_SHIFT) | (1  MODEL24_SHIFT);
  ret = regmap_write(info-regmap, info-regs-ctrl, data[0]);
 +if (ret  0)
 +break;
 +
 +ret = s5m8767_rtc_set_alarm_reg(info);
  break;
  
  default:

 But i can't find any reasonable reason about this fix from datasheet,

 Thanks.

 Best regards,
 Krzysztof


 Best regards,
 Krzysztof



 Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
 Cc: sta...@vger.kernel.org

 can you update the stable tag with the kernel version introducing the
 issue?

 Sure, i think it should be v3.16.


 ---
  drivers/rtc/rtc-s5m.c | 12 
  1 file changed, 12 insertions(+)

 diff --git a/drivers/rtc/rtc-s5m.c b/drivers/rtc/rtc-s5m.c
 index 8c70d78..03828bb 100644
 --- a/drivers/rtc/rtc-s5m.c
 +++ b/drivers/rtc/rtc-s5m.c
 @@ -635,6 +635,18 @@ static int s5m8767_rtc_init_reg(struct 
 s5m_rtc_info *info)
 case S2MPS13X:
 data[0] = (0  BCD_EN_SHIFT) | (1  MODEL24_SHIFT);
 ret = regmap_write(info-regmap, info-regs-ctrl, 
 data[0]);
 +   if (ret  0)
 +   break;
 +
 +   ret = regmap_update_bits(info-regmap,
 +   info-regs-rtc_udr_update,
 +   info-regs-rtc_udr_mask,
 +   info-regs-rtc_udr_mask);

 Very small indentation issue here, it should be aligned with the open
 parenthesis.

 OK, i will.

 Thanks.





 
 --
 To unsubscribe from this list: send the line

Re: [PATCH] rtc: s5m: fix to update ctrl register

[Joonyoung Shim]

On 08/21/2015 09:44 AM, Krzysztof Kozlowski wrote:
> On 21.08.2015 08:15, Alexandre Belloni wrote:
>> Hi,
>>
>> On 13/08/2015 at 17:49:24 +0900, Joonyoung Shim wrote :
>>> According to datasheet, the S2MPS13X and S2MPS14X should update write
>>> buffer via setting WUDR bit to high after ctrl register is updated.
>>>
>>> If not, ALARM interrupt of rtc-s5m doesn't happen first time when i use
>>> tools/testing/selftests/timers/rtctest.c test program and hour format is
>>> used to 12 hour mode in Odroid-XU3 board.
>>>
>>
>> >From what I understood, I should expect a v2 of tihat patch also setting
>> RUDR, is that right? OR would you prefer that I apply that one and then
>> fix RUDR in a following patch?
> 
> Right, I would expect that as well... or a comment if this is not needed.
> 

Hmm, the driver only writes control register now, so i don't feel the
need of patch setting RUDR for control register.

> Best regards,
> Krzysztof
> 
> 
>>
>>> Signed-off-by: Joonyoung Shim 
>>> Cc: 
>>
>> can you update the stable tag with the kernel version introducing the
>> issue?

Sure, i think it should be v3.16.

>>
>>> ---
>>>  drivers/rtc/rtc-s5m.c | 12 
>>>  1 file changed, 12 insertions(+)
>>
>>> diff --git a/drivers/rtc/rtc-s5m.c b/drivers/rtc/rtc-s5m.c
>>> index 8c70d78..03828bb 100644
>>> --- a/drivers/rtc/rtc-s5m.c
>>> +++ b/drivers/rtc/rtc-s5m.c
>>> @@ -635,6 +635,18 @@ static int s5m8767_rtc_init_reg(struct s5m_rtc_info 
>>> *info)
>>> case S2MPS13X:
>>> data[0] = (0 << BCD_EN_SHIFT) | (1 << MODEL24_SHIFT);
>>> ret = regmap_write(info->regmap, info->regs->ctrl, data[0]);
>>> +   if (ret < 0)
>>> +   break;
>>> +
>>> +   ret = regmap_update_bits(info->regmap,
>>> +   info->regs->rtc_udr_update,
>>> +   info->regs->rtc_udr_mask,
>>> +   info->regs->rtc_udr_mask);
>>
>> Very small indentation issue here, it should be aligned with the open
>> parenthesis.

OK, i will.

Thanks.
--
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] rtc: s5m: fix to update ctrl register

[Joonyoung Shim]

On 08/21/2015 09:44 AM, Krzysztof Kozlowski wrote:
 On 21.08.2015 08:15, Alexandre Belloni wrote:
 Hi,

 On 13/08/2015 at 17:49:24 +0900, Joonyoung Shim wrote :
 According to datasheet, the S2MPS13X and S2MPS14X should update write
 buffer via setting WUDR bit to high after ctrl register is updated.

 If not, ALARM interrupt of rtc-s5m doesn't happen first time when i use
 tools/testing/selftests/timers/rtctest.c test program and hour format is
 used to 12 hour mode in Odroid-XU3 board.


 From what I understood, I should expect a v2 of tihat patch also setting
 RUDR, is that right? OR would you prefer that I apply that one and then
 fix RUDR in a following patch?
 
 Right, I would expect that as well... or a comment if this is not needed.
 

Hmm, the driver only writes control register now, so i don't feel the
need of patch setting RUDR for control register.

 Best regards,
 Krzysztof
 
 

 Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
 Cc: sta...@vger.kernel.org

 can you update the stable tag with the kernel version introducing the
 issue?

Sure, i think it should be v3.16.


 ---
  drivers/rtc/rtc-s5m.c | 12 
  1 file changed, 12 insertions(+)

 diff --git a/drivers/rtc/rtc-s5m.c b/drivers/rtc/rtc-s5m.c
 index 8c70d78..03828bb 100644
 --- a/drivers/rtc/rtc-s5m.c
 +++ b/drivers/rtc/rtc-s5m.c
 @@ -635,6 +635,18 @@ static int s5m8767_rtc_init_reg(struct s5m_rtc_info 
 *info)
 case S2MPS13X:
 data[0] = (0  BCD_EN_SHIFT) | (1  MODEL24_SHIFT);
 ret = regmap_write(info-regmap, info-regs-ctrl, data[0]);
 +   if (ret  0)
 +   break;
 +
 +   ret = regmap_update_bits(info-regmap,
 +   info-regs-rtc_udr_update,
 +   info-regs-rtc_udr_mask,
 +   info-regs-rtc_udr_mask);

 Very small indentation issue here, it should be aligned with the open
 parenthesis.

OK, i will.

Thanks.
--
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: [rtc-linux] [PATCH] rtc: s5m: fix to update ctrl register

[Joonyoung Shim]

On 08/17/2015 11:00 AM, Krzysztof Kozlowski wrote:
> On 17.08.2015 10:47, Joonyoung Shim wrote:
>> Hi,
>>
>> On 08/13/2015 07:02 PM, Krzysztof Kozlowski wrote:
>>> W dniu 13.08.2015 o 17:49, Joonyoung Shim pisze:
>>>> According to datasheet, the S2MPS13X and S2MPS14X should update write
>>>> buffer via setting WUDR bit to high after ctrl register is updated.
>>>
>>> Hi,
>>>
>>> I cannot find this information in S2MPS14 datasheet. On which page is it?
>>>
>>
>> I got below information from S2MPS14_Data Sheet_REV0.1 document.
>>
>> 5.2.2.3 RTC_UPDATE
>> ...
>>
>> NOTE: 
>> 1.  For write Time Registers (0x00, 0x04~0x0A) & Alarm 0&1 Registers 
>> (0x0B~0x18), set WUDR bit to high.
> 
> Right, I have too but it does not say anything about control register.
> It mentions only time, alarm 0 and alarm 1 registers, not control.
> 

Address 0x00 is RTC_CTRL, so i don't know what you say.

>>
>>>
>>>>
>>>> If not, ALARM interrupt of rtc-s5m doesn't happen first time when i use
>>>> tools/testing/selftests/timers/rtctest.c test program and hour format is
>>>> used to 12 hour mode in Odroid-XU3 board.
>>>
>>> Two questions here:
>>> 1. Earlier you mentioned S2MPS1[34], now Odroid XU3 which has S2MPS11.
>>> Are you sure that this applies to all of them (S2MPS11, S2MPS13 and
>>> S2MP14)? There are some minor differences between them so I would not be
>>> surprised if only some of them required this action.
>>>
>>
>> I'm not sure about that because i don't have S2MPS11 datasheet. I just
>> got the information that S2MPS11 also use S2MPS14 rtc from sec-core mfd
>> driver,
> 
> Yeah, I added it. But these RTC modules are slightly different,
> especially S2MPS14, so you cannot assume that they are the same after
> looking at mainline code.
> 

OK, could you check this issue from different things?

Thanks.

>>
>> static const struct mfd_cell s2mps11_devs[] = {  
>>  
>> {
>>  
>> .name = "s2mps11-pmic",  
>>  
>> }, { 
>>  
>> .name = "s2mps14-rtc",   
>>  
>> }, { 
>>  
>> .name = "s2mps11-clk",   
>>  
>> .of_compatible = "samsung,s2mps11-clk",  
>>  
>> }
>>      
>> };
>>
>>> 2. The driver operates in 24-hour omode. Actually it sets the 24-hour
>>> mode just before your new regmap_update_bits() call. What do you mean by
>>> 12-hour mode?
>>>
>>
>> RTC_CTRL register value is 0 until write buffer is updated, so it is
>> used to 12-hour mode.
> 
> I mean what do you have in mind by saying:
> "... and hour format is used to 12 hour mode in Odroid-XU3 board."
> The hour format is set by driver to 24h mode.
> 
> 
>>
>>>> Signed-off-by: Joonyoung Shim 
>>>> Cc: 
>>>
>>> Thanks for putting a cc-stable tag. How far this should be ported? If
>>> this is needed only for S2MPS11 then v4.1. If all of them then probably
>>> for earlier version?
>>>
>>
>> If find exact version, i think it will be a version after below commit
>> was applied.
>>
>> The commit 0c5deb1ea92f("rtc: s5m: add support for S2MPS14 RTC")
>>
>> $ git name-rev 0c5deb1ea92f
>> 0c5deb1ea92f tags/v3.16-rc1~53^2~1
> 
> Hmmm... I am not against the patch (especially that it matches source
> code of SM-G900H with S2MPS11) but I have doubts about affected
> chipsets. My Odroid (probably because of bootloader), S2MPS13 and
> S2MPS14 do not need it. This confuses me...
> 
> Best regards,
> Krzysztof
> 
>>
>> Thanks.
>>
>>> Best regards,
>>

Re: [rtc-linux] [PATCH] rtc: s5m: fix to update ctrl register

[Joonyoung Shim]

Hi,

On 08/13/2015 07:02 PM, Krzysztof Kozlowski wrote:
> W dniu 13.08.2015 o 17:49, Joonyoung Shim pisze:
>> According to datasheet, the S2MPS13X and S2MPS14X should update write
>> buffer via setting WUDR bit to high after ctrl register is updated.
> 
> Hi,
> 
> I cannot find this information in S2MPS14 datasheet. On which page is it?
> 

I got below information from S2MPS14_Data Sheet_REV0.1 document.

5.2.2.3 RTC_UPDATE
...

NOTE: 
1.  For write Time Registers (0x00, 0x04~0x0A) & Alarm 0&1 Registers 
(0x0B~0x18), set WUDR bit to high.

> 
>>
>> If not, ALARM interrupt of rtc-s5m doesn't happen first time when i use
>> tools/testing/selftests/timers/rtctest.c test program and hour format is
>> used to 12 hour mode in Odroid-XU3 board.
> 
> Two questions here:
> 1. Earlier you mentioned S2MPS1[34], now Odroid XU3 which has S2MPS11.
> Are you sure that this applies to all of them (S2MPS11, S2MPS13 and
> S2MP14)? There are some minor differences between them so I would not be
> surprised if only some of them required this action.
> 

I'm not sure about that because i don't have S2MPS11 datasheet. I just
got the information that S2MPS11 also use S2MPS14 rtc from sec-core mfd
driver,

static const struct mfd_cell s2mps11_devs[] = { 
  
{   
  
.name = "s2mps11-pmic", 
  
}, {
  
.name = "s2mps14-rtc",  
  
}, {
  
.name = "s2mps11-clk",  
  
.of_compatible = "samsung,s2mps11-clk", 
  
}   
  
};

> 2. The driver operates in 24-hour omode. Actually it sets the 24-hour
> mode just before your new regmap_update_bits() call. What do you mean by
> 12-hour mode?
> 

RTC_CTRL register value is 0 until write buffer is updated, so it is
used to 12-hour mode.

>> Signed-off-by: Joonyoung Shim 
>> Cc: 
> 
> Thanks for putting a cc-stable tag. How far this should be ported? If
> this is needed only for S2MPS11 then v4.1. If all of them then probably
> for earlier version?
> 

If find exact version, i think it will be a version after below commit
was applied.

The commit 0c5deb1ea92f("rtc: s5m: add support for S2MPS14 RTC")

$ git name-rev 0c5deb1ea92f
0c5deb1ea92f tags/v3.16-rc1~53^2~1

Thanks.

> Best regards,
> Krzysztof
> 
>> ---
>>  drivers/rtc/rtc-s5m.c | 12 
>>  1 file changed, 12 insertions(+)
>>
>> diff --git a/drivers/rtc/rtc-s5m.c b/drivers/rtc/rtc-s5m.c
>> index 8c70d78..03828bb 100644
>> --- a/drivers/rtc/rtc-s5m.c
>> +++ b/drivers/rtc/rtc-s5m.c
>> @@ -635,6 +635,18 @@ static int s5m8767_rtc_init_reg(struct s5m_rtc_info 
>> *info)
>>  case S2MPS13X:
>>  data[0] = (0 << BCD_EN_SHIFT) | (1 << MODEL24_SHIFT);
>>  ret = regmap_write(info->regmap, info->regs->ctrl, data[0]);
>> +if (ret < 0)
>> +break;
>> +
>> +ret = regmap_update_bits(info->regmap,
>> +info->regs->rtc_udr_update,
>> +info->regs->rtc_udr_mask,
>> +info->regs->rtc_udr_mask);
>> +if (ret < 0)
>> +break;
>> +
>> +ret = s5m8767_wait_for_udr_update(info);
>> +
>>  break;
>>  
>>  default:
>>
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

--
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: [rtc-linux] [PATCH] rtc: s5m: fix to update ctrl register

[Joonyoung Shim]

On 08/13/2015 07:42 PM, Krzysztof Kozlowski wrote:
> W dniu 13.08.2015 o 19:02, Krzysztof Kozlowski pisze:
>> W dniu 13.08.2015 o 17:49, Joonyoung Shim pisze:
>>> According to datasheet, the S2MPS13X and S2MPS14X should update write
>>> buffer via setting WUDR bit to high after ctrl register is updated.
>>
>> Hi,
>>
>> I cannot find this information in S2MPS14 datasheet. On which page is it?
>>
>>
>>>
>>> If not, ALARM interrupt of rtc-s5m doesn't happen first time when i use
>>> tools/testing/selftests/timers/rtctest.c test program and hour format is
>>> used to 12 hour mode in Odroid-XU3 board.
>>
>> Two questions here:
>> 1. Earlier you mentioned S2MPS1[34], now Odroid XU3 which has S2MPS11.
>> Are you sure that this applies to all of them (S2MPS11, S2MPS13 and
>> S2MP14)? There are some minor differences between them so I would not be
>> surprised if only some of them required this action.
>>
>> 2. The driver operates in 24-hour omode. Actually it sets the 24-hour
>> mode just before your new regmap_update_bits() call. What do you mean by
>> 12-hour mode?
>>
>>> Signed-off-by: Joonyoung Shim 
>>> Cc: 
>>
>> Thanks for putting a cc-stable tag. How far this should be ported? If
>> this is needed only for S2MPS11 then v4.1. If all of them then probably
>> for earlier version?
>>
>> Best regards,
>> Krzysztof
> 
> One more doubt. On my Odroid XU3 first and consecutive executions
> (including first) of rtctest run fine. They pass. Can you describe
> exactly observable issue and how to reproduce it? This is also important
> as a reason for stable backport.

I just tested it on next-20150810 with Odroid-XU3 board. First rtctest
execution is blocked,

# ./rtctest 

RTC Driver Test Example.

Counting 5 update (1/sec) interrupts from reading /dev/rtc0:

Any no progress.

> 
> I tested it on next-20150729 on board with Hardkernel bootloader. Maybe
> the bootloader sets 12-hour mode which cannot be switched to 24-hour?
> 

My bootloader doesn't touch any registers of s5m-rtc.

Thanks.
--
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: [rtc-linux] [PATCH] rtc: s5m: fix to update ctrl register

[Joonyoung Shim]

Hi,

On 08/13/2015 07:02 PM, Krzysztof Kozlowski wrote:
 W dniu 13.08.2015 o 17:49, Joonyoung Shim pisze:
 According to datasheet, the S2MPS13X and S2MPS14X should update write
 buffer via setting WUDR bit to high after ctrl register is updated.
 
 Hi,
 
 I cannot find this information in S2MPS14 datasheet. On which page is it?
 

I got below information from S2MPS14_Data Sheet_REV0.1 document.

5.2.2.3 RTC_UPDATE
...

NOTE: 
1.  For write Time Registers (0x00, 0x04~0x0A)  Alarm 01 Registers 
(0x0B~0x18), set WUDR bit to high.

 

 If not, ALARM interrupt of rtc-s5m doesn't happen first time when i use
 tools/testing/selftests/timers/rtctest.c test program and hour format is
 used to 12 hour mode in Odroid-XU3 board.
 
 Two questions here:
 1. Earlier you mentioned S2MPS1[34], now Odroid XU3 which has S2MPS11.
 Are you sure that this applies to all of them (S2MPS11, S2MPS13 and
 S2MP14)? There are some minor differences between them so I would not be
 surprised if only some of them required this action.
 

I'm not sure about that because i don't have S2MPS11 datasheet. I just
got the information that S2MPS11 also use S2MPS14 rtc from sec-core mfd
driver,

static const struct mfd_cell s2mps11_devs[] = { 
  
{   
  
.name = s2mps11-pmic, 
  
}, {
  
.name = s2mps14-rtc,  
  
}, {
  
.name = s2mps11-clk,  
  
.of_compatible = samsung,s2mps11-clk, 
  
}   
  
};

 2. The driver operates in 24-hour omode. Actually it sets the 24-hour
 mode just before your new regmap_update_bits() call. What do you mean by
 12-hour mode?
 

RTC_CTRL register value is 0 until write buffer is updated, so it is
used to 12-hour mode.

 Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
 Cc: sta...@vger.kernel.org
 
 Thanks for putting a cc-stable tag. How far this should be ported? If
 this is needed only for S2MPS11 then v4.1. If all of them then probably
 for earlier version?
 

If find exact version, i think it will be a version after below commit
was applied.

The commit 0c5deb1ea92f(rtc: s5m: add support for S2MPS14 RTC)

$ git name-rev 0c5deb1ea92f
0c5deb1ea92f tags/v3.16-rc1~53^2~1

Thanks.

 Best regards,
 Krzysztof
 
 ---
  drivers/rtc/rtc-s5m.c | 12 
  1 file changed, 12 insertions(+)

 diff --git a/drivers/rtc/rtc-s5m.c b/drivers/rtc/rtc-s5m.c
 index 8c70d78..03828bb 100644
 --- a/drivers/rtc/rtc-s5m.c
 +++ b/drivers/rtc/rtc-s5m.c
 @@ -635,6 +635,18 @@ static int s5m8767_rtc_init_reg(struct s5m_rtc_info 
 *info)
  case S2MPS13X:
  data[0] = (0  BCD_EN_SHIFT) | (1  MODEL24_SHIFT);
  ret = regmap_write(info-regmap, info-regs-ctrl, data[0]);
 +if (ret  0)
 +break;
 +
 +ret = regmap_update_bits(info-regmap,
 +info-regs-rtc_udr_update,
 +info-regs-rtc_udr_mask,
 +info-regs-rtc_udr_mask);
 +if (ret  0)
 +break;
 +
 +ret = s5m8767_wait_for_udr_update(info);
 +
  break;
  
  default:

 
 --
 To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 
 in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 

--
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: [rtc-linux] [PATCH] rtc: s5m: fix to update ctrl register

[Joonyoung Shim]

On 08/13/2015 07:42 PM, Krzysztof Kozlowski wrote:
 W dniu 13.08.2015 o 19:02, Krzysztof Kozlowski pisze:
 W dniu 13.08.2015 o 17:49, Joonyoung Shim pisze:
 According to datasheet, the S2MPS13X and S2MPS14X should update write
 buffer via setting WUDR bit to high after ctrl register is updated.

 Hi,

 I cannot find this information in S2MPS14 datasheet. On which page is it?



 If not, ALARM interrupt of rtc-s5m doesn't happen first time when i use
 tools/testing/selftests/timers/rtctest.c test program and hour format is
 used to 12 hour mode in Odroid-XU3 board.

 Two questions here:
 1. Earlier you mentioned S2MPS1[34], now Odroid XU3 which has S2MPS11.
 Are you sure that this applies to all of them (S2MPS11, S2MPS13 and
 S2MP14)? There are some minor differences between them so I would not be
 surprised if only some of them required this action.

 2. The driver operates in 24-hour omode. Actually it sets the 24-hour
 mode just before your new regmap_update_bits() call. What do you mean by
 12-hour mode?

 Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
 Cc: sta...@vger.kernel.org

 Thanks for putting a cc-stable tag. How far this should be ported? If
 this is needed only for S2MPS11 then v4.1. If all of them then probably
 for earlier version?

 Best regards,
 Krzysztof
 
 One more doubt. On my Odroid XU3 first and consecutive executions
 (including first) of rtctest run fine. They pass. Can you describe
 exactly observable issue and how to reproduce it? This is also important
 as a reason for stable backport.

I just tested it on next-20150810 with Odroid-XU3 board. First rtctest
execution is blocked,

# ./rtctest 

RTC Driver Test Example.

Counting 5 update (1/sec) interrupts from reading /dev/rtc0:

Any no progress.

 
 I tested it on next-20150729 on board with Hardkernel bootloader. Maybe
 the bootloader sets 12-hour mode which cannot be switched to 24-hour?
 

My bootloader doesn't touch any registers of s5m-rtc.

Thanks.
--
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: [rtc-linux] [PATCH] rtc: s5m: fix to update ctrl register

[Joonyoung Shim]

On 08/17/2015 11:00 AM, Krzysztof Kozlowski wrote:
 On 17.08.2015 10:47, Joonyoung Shim wrote:
 Hi,

 On 08/13/2015 07:02 PM, Krzysztof Kozlowski wrote:
 W dniu 13.08.2015 o 17:49, Joonyoung Shim pisze:
 According to datasheet, the S2MPS13X and S2MPS14X should update write
 buffer via setting WUDR bit to high after ctrl register is updated.

 Hi,

 I cannot find this information in S2MPS14 datasheet. On which page is it?


 I got below information from S2MPS14_Data Sheet_REV0.1 document.

 5.2.2.3 RTC_UPDATE
 ...

 NOTE: 
 1.  For write Time Registers (0x00, 0x04~0x0A)  Alarm 01 Registers 
 (0x0B~0x18), set WUDR bit to high.
 
 Right, I have too but it does not say anything about control register.
 It mentions only time, alarm 0 and alarm 1 registers, not control.
 

Address 0x00 is RTC_CTRL, so i don't know what you say.




 If not, ALARM interrupt of rtc-s5m doesn't happen first time when i use
 tools/testing/selftests/timers/rtctest.c test program and hour format is
 used to 12 hour mode in Odroid-XU3 board.

 Two questions here:
 1. Earlier you mentioned S2MPS1[34], now Odroid XU3 which has S2MPS11.
 Are you sure that this applies to all of them (S2MPS11, S2MPS13 and
 S2MP14)? There are some minor differences between them so I would not be
 surprised if only some of them required this action.


 I'm not sure about that because i don't have S2MPS11 datasheet. I just
 got the information that S2MPS11 also use S2MPS14 rtc from sec-core mfd
 driver,
 
 Yeah, I added it. But these RTC modules are slightly different,
 especially S2MPS14, so you cannot assume that they are the same after
 looking at mainline code.
 

OK, could you check this issue from different things?

Thanks.


 static const struct mfd_cell s2mps11_devs[] = {  
  
 {
  
 .name = s2mps11-pmic,  
  
 }, { 
  
 .name = s2mps14-rtc,   
  
 }, { 
  
 .name = s2mps11-clk,   
  
 .of_compatible = samsung,s2mps11-clk,  
  
 }
  
 };

 2. The driver operates in 24-hour omode. Actually it sets the 24-hour
 mode just before your new regmap_update_bits() call. What do you mean by
 12-hour mode?


 RTC_CTRL register value is 0 until write buffer is updated, so it is
 used to 12-hour mode.
 
 I mean what do you have in mind by saying:
 ... and hour format is used to 12 hour mode in Odroid-XU3 board.
 The hour format is set by driver to 24h mode.
 
 

 Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
 Cc: sta...@vger.kernel.org

 Thanks for putting a cc-stable tag. How far this should be ported? If
 this is needed only for S2MPS11 then v4.1. If all of them then probably
 for earlier version?


 If find exact version, i think it will be a version after below commit
 was applied.

 The commit 0c5deb1ea92f(rtc: s5m: add support for S2MPS14 RTC)

 $ git name-rev 0c5deb1ea92f
 0c5deb1ea92f tags/v3.16-rc1~53^2~1
 
 Hmmm... I am not against the patch (especially that it matches source
 code of SM-G900H with S2MPS11) but I have doubts about affected
 chipsets. My Odroid (probably because of bootloader), S2MPS13 and
 S2MPS14 do not need it. This confuses me...
 
 Best regards,
 Krzysztof
 

 Thanks.

 Best regards,
 Krzysztof

 ---
  drivers/rtc/rtc-s5m.c | 12 
  1 file changed, 12 insertions(+)

 diff --git a/drivers/rtc/rtc-s5m.c b/drivers/rtc/rtc-s5m.c
 index 8c70d78..03828bb 100644
 --- a/drivers/rtc/rtc-s5m.c
 +++ b/drivers/rtc/rtc-s5m.c
 @@ -635,6 +635,18 @@ static int s5m8767_rtc_init_reg(struct s5m_rtc_info 
 *info)
case S2MPS13X:
data[0] = (0  BCD_EN_SHIFT) | (1  MODEL24_SHIFT);
ret = regmap_write(info-regmap, info-regs-ctrl, data[0]);
 +  if (ret  0)
 +  break;
 +
 +  ret = regmap_update_bits(info-regmap,
 +  info-regs-rtc_udr_update,
 +  info-regs-rtc_udr_mask,
 +  info-regs-rtc_udr_mask);
 +  if (ret  0)
 +  break;
 +
 +  ret = s5m8767_wait_for_udr_update(info);
 +
break;
  
default:


 --
 To unsubscribe from this list: send the line unsubscribe 
 linux-samsung-soc in
 the body of a message

[PATCH] rtc: s5m: fix to update ctrl register

[Joonyoung Shim]

According to datasheet, the S2MPS13X and S2MPS14X should update write
buffer via setting WUDR bit to high after ctrl register is updated.

If not, ALARM interrupt of rtc-s5m doesn't happen first time when i use
tools/testing/selftests/timers/rtctest.c test program and hour format is
used to 12 hour mode in Odroid-XU3 board.

Signed-off-by: Joonyoung Shim 
Cc: 
---
 drivers/rtc/rtc-s5m.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/rtc/rtc-s5m.c b/drivers/rtc/rtc-s5m.c
index 8c70d78..03828bb 100644
--- a/drivers/rtc/rtc-s5m.c
+++ b/drivers/rtc/rtc-s5m.c
@@ -635,6 +635,18 @@ static int s5m8767_rtc_init_reg(struct s5m_rtc_info *info)
case S2MPS13X:
data[0] = (0 << BCD_EN_SHIFT) | (1 << MODEL24_SHIFT);
ret = regmap_write(info->regmap, info->regs->ctrl, data[0]);
+   if (ret < 0)
+   break;
+
+   ret = regmap_update_bits(info->regmap,
+   info->regs->rtc_udr_update,
+   info->regs->rtc_udr_mask,
+   info->regs->rtc_udr_mask);
+   if (ret < 0)
+   break;
+
+   ret = s5m8767_wait_for_udr_update(info);
+
break;
 
default:
-- 
1.9.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/

[PATCH] rtc: s5m: fix to update ctrl register

[Joonyoung Shim]

According to datasheet, the S2MPS13X and S2MPS14X should update write
buffer via setting WUDR bit to high after ctrl register is updated.

If not, ALARM interrupt of rtc-s5m doesn't happen first time when i use
tools/testing/selftests/timers/rtctest.c test program and hour format is
used to 12 hour mode in Odroid-XU3 board.

Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
Cc: sta...@vger.kernel.org
---
 drivers/rtc/rtc-s5m.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/rtc/rtc-s5m.c b/drivers/rtc/rtc-s5m.c
index 8c70d78..03828bb 100644
--- a/drivers/rtc/rtc-s5m.c
+++ b/drivers/rtc/rtc-s5m.c
@@ -635,6 +635,18 @@ static int s5m8767_rtc_init_reg(struct s5m_rtc_info *info)
case S2MPS13X:
data[0] = (0  BCD_EN_SHIFT) | (1  MODEL24_SHIFT);
ret = regmap_write(info-regmap, info-regs-ctrl, data[0]);
+   if (ret  0)
+   break;
+
+   ret = regmap_update_bits(info-regmap,
+   info-regs-rtc_udr_update,
+   info-regs-rtc_udr_mask,
+   info-regs-rtc_udr_mask);
+   if (ret  0)
+   break;
+
+   ret = s5m8767_wait_for_udr_update(info);
+
break;
 
default:
-- 
1.9.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/

Re: [PATCH 3/4] rtc: s3c: use unified functions for enable/disable of clk

[Joonyoung Shim]

On 08/12/2015 09:10 AM, Krzysztof Kozlowski wrote:
> On 11.08.2015 20:28, Joonyoung Shim wrote:
>> The driver uses clk_prepare_enable()/clk_disable_unprepare() only in
>> probe only, elsewhere, use the unified functions for enable/disable of
>> clk, e.g. s3c_rtc_enable_clk() / s3c_rtc_disable_clk(), so it's better
>> to use them for consistency of code.
>>
>> Signed-off-by: Joonyoung Shim 
>> ---
>>  drivers/rtc/rtc-s3c.c | 14 +-
>>  1 file changed, 9 insertions(+), 5 deletions(-)
> 
> First of all - the code is larger (9 insertions, 5 deletion) so I have
> doubts if this is better.
> 
> Second - this is not equivalent change. The s3c_rtc_enable_clk/disable
> calls grab spin lock which is not necessary in probe.
> 

I made this patch because of patch 4/4, but patch 4/4 should be removed
dependency from previous patches, so i will drop this patch.

Thanks.

--
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] rtc: s3c: fix disabled clocks for alarm

[Joonyoung Shim]

The clock enable/disable codes for alarm have been removed from
commit 24e1455493da ("drivers/rtc/rtc-s3c.c: delete duplicate clock
control") and the clocks are disabled even if alarm is set, so alarm
interrupt can't happen.

The s3c_rtc_setaie function can be called several times with 'enabled'
argument having same value, so it needs to check whether clocks are
enabled or not.

Signed-off-by: Joonyoung Shim 
Cc:  # v4.1
---
This is v2 of prior patch "[PATCH 4/4] rtc: s3c: enable/disable clocks
for alarm".

Changelog for v2:
- commit messages is modified by Krzysztof suggestion
- make to backportable patch
- add Cc-stable

 drivers/rtc/rtc-s3c.c | 24 ++--
 1 file changed, 18 insertions(+), 6 deletions(-)

diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c
index 44b2921..7cc8f73 100644
--- a/drivers/rtc/rtc-s3c.c
+++ b/drivers/rtc/rtc-s3c.c
@@ -39,6 +39,7 @@ struct s3c_rtc {
void __iomem *base;
struct clk *rtc_clk;
struct clk *rtc_src_clk;
+   bool clk_disabled;
 
struct s3c_rtc_data *data;
 
@@ -71,9 +72,12 @@ static void s3c_rtc_enable_clk(struct s3c_rtc *info)
unsigned long irq_flags;
 
spin_lock_irqsave(>alarm_clk_lock, irq_flags);
-   clk_enable(info->rtc_clk);
-   if (info->data->needs_src_clk)
-   clk_enable(info->rtc_src_clk);
+   if (info->clk_disabled) {
+   clk_enable(info->rtc_clk);
+   if (info->data->needs_src_clk)
+   clk_enable(info->rtc_src_clk);
+   info->clk_disabled = false;
+   }
spin_unlock_irqrestore(>alarm_clk_lock, irq_flags);
 }
 
@@ -82,9 +86,12 @@ static void s3c_rtc_disable_clk(struct s3c_rtc *info)
unsigned long irq_flags;
 
spin_lock_irqsave(>alarm_clk_lock, irq_flags);
-   if (info->data->needs_src_clk)
-   clk_disable(info->rtc_src_clk);
-   clk_disable(info->rtc_clk);
+   if (!info->clk_disabled) {
+   if (info->data->needs_src_clk)
+   clk_disable(info->rtc_src_clk);
+   clk_disable(info->rtc_clk);
+   info->clk_disabled = true;
+   }
spin_unlock_irqrestore(>alarm_clk_lock, irq_flags);
 }
 
@@ -128,6 +135,11 @@ static int s3c_rtc_setaie(struct device *dev, unsigned int 
enabled)
 
s3c_rtc_disable_clk(info);
 
+   if (enabled)
+   s3c_rtc_enable_clk(info);
+   else
+   s3c_rtc_disable_clk(info);
+
return 0;
 }
 
-- 
1.9.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/

Re: [PATCH 3/4] rtc: s3c: use unified functions for enable/disable of clk

[Joonyoung Shim]

On 08/12/2015 09:10 AM, Krzysztof Kozlowski wrote:
 On 11.08.2015 20:28, Joonyoung Shim wrote:
 The driver uses clk_prepare_enable()/clk_disable_unprepare() only in
 probe only, elsewhere, use the unified functions for enable/disable of
 clk, e.g. s3c_rtc_enable_clk() / s3c_rtc_disable_clk(), so it's better
 to use them for consistency of code.

 Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
 ---
  drivers/rtc/rtc-s3c.c | 14 +-
  1 file changed, 9 insertions(+), 5 deletions(-)
 
 First of all - the code is larger (9 insertions, 5 deletion) so I have
 doubts if this is better.
 
 Second - this is not equivalent change. The s3c_rtc_enable_clk/disable
 calls grab spin lock which is not necessary in probe.
 

I made this patch because of patch 4/4, but patch 4/4 should be removed
dependency from previous patches, so i will drop this patch.

Thanks.

--
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] rtc: s3c: fix disabled clocks for alarm

[Joonyoung Shim]

The clock enable/disable codes for alarm have been removed from
commit 24e1455493da (drivers/rtc/rtc-s3c.c: delete duplicate clock
control) and the clocks are disabled even if alarm is set, so alarm
interrupt can't happen.

The s3c_rtc_setaie function can be called several times with 'enabled'
argument having same value, so it needs to check whether clocks are
enabled or not.

Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
Cc: sta...@vger.kernel.org # v4.1
---
This is v2 of prior patch [PATCH 4/4] rtc: s3c: enable/disable clocks
for alarm.

Changelog for v2:
- commit messages is modified by Krzysztof suggestion
- make to backportable patch
- add Cc-stable

 drivers/rtc/rtc-s3c.c | 24 ++--
 1 file changed, 18 insertions(+), 6 deletions(-)

diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c
index 44b2921..7cc8f73 100644
--- a/drivers/rtc/rtc-s3c.c
+++ b/drivers/rtc/rtc-s3c.c
@@ -39,6 +39,7 @@ struct s3c_rtc {
void __iomem *base;
struct clk *rtc_clk;
struct clk *rtc_src_clk;
+   bool clk_disabled;
 
struct s3c_rtc_data *data;
 
@@ -71,9 +72,12 @@ static void s3c_rtc_enable_clk(struct s3c_rtc *info)
unsigned long irq_flags;
 
spin_lock_irqsave(info-alarm_clk_lock, irq_flags);
-   clk_enable(info-rtc_clk);
-   if (info-data-needs_src_clk)
-   clk_enable(info-rtc_src_clk);
+   if (info-clk_disabled) {
+   clk_enable(info-rtc_clk);
+   if (info-data-needs_src_clk)
+   clk_enable(info-rtc_src_clk);
+   info-clk_disabled = false;
+   }
spin_unlock_irqrestore(info-alarm_clk_lock, irq_flags);
 }
 
@@ -82,9 +86,12 @@ static void s3c_rtc_disable_clk(struct s3c_rtc *info)
unsigned long irq_flags;
 
spin_lock_irqsave(info-alarm_clk_lock, irq_flags);
-   if (info-data-needs_src_clk)
-   clk_disable(info-rtc_src_clk);
-   clk_disable(info-rtc_clk);
+   if (!info-clk_disabled) {
+   if (info-data-needs_src_clk)
+   clk_disable(info-rtc_src_clk);
+   clk_disable(info-rtc_clk);
+   info-clk_disabled = true;
+   }
spin_unlock_irqrestore(info-alarm_clk_lock, irq_flags);
 }
 
@@ -128,6 +135,11 @@ static int s3c_rtc_setaie(struct device *dev, unsigned int 
enabled)
 
s3c_rtc_disable_clk(info);
 
+   if (enabled)
+   s3c_rtc_enable_clk(info);
+   else
+   s3c_rtc_disable_clk(info);
+
return 0;
 }
 
-- 
1.9.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/

Re: [PATCH 4/4] rtc: s3c: enable/disable clocks for alarm

[Joonyoung Shim]

On 08/12/2015 09:28 AM, Krzysztof Kozlowski wrote:
> On 11.08.2015 20:28, Joonyoung Shim wrote:
>> The clock enable/disable codes for alarm have removed from
> 
> What do you mean in this paragraph? The clock code was removing something?
> 
>> 'commit 24e1455493da ("drivers/rtc/rtc-s3c.c: delete duplicate clock
> 
> Remove the 'apostrophe.
> 
>> control")' and the clocks keep disabling even if alarm is set, so alarm
>> interrupt can't happen.
> ...and the clocks are disabled even...
> 
> 
>>
>> The s3c_rtc_setaie function can be called several times with that
>> enabled argument has same value,
> ...several times with 'enabled' argument having same value
> 
>> so it needs to check whether clocks is
>> enabled or not.
> s/is/are/
> 
>>
>> Signed-off-by: Joonyoung Shim 
> 
> Please add Cc-stable and fixes tag. To backport the patch probably
> you'll have to remove the dependency on previous patches.

Thanks for the point, i didn't think it.
--
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 4/4] rtc: s3c: enable/disable clocks for alarm

[Joonyoung Shim]

The clock enable/disable codes for alarm have removed from
'commit 24e1455493da ("drivers/rtc/rtc-s3c.c: delete duplicate clock
control")' and the clocks keep disabling even if alarm is set, so alarm
interrupt can't happen.

The s3c_rtc_setaie function can be called several times with that
enabled argument has same value, so it needs to check whether clocks is
enabled or not.

Signed-off-by: Joonyoung Shim 
---
 drivers/rtc/rtc-s3c.c | 24 ++--
 1 file changed, 18 insertions(+), 6 deletions(-)

diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c
index abe2a6d..fce078c 100644
--- a/drivers/rtc/rtc-s3c.c
+++ b/drivers/rtc/rtc-s3c.c
@@ -39,6 +39,7 @@ struct s3c_rtc {
void __iomem *base;
struct clk *rtc_clk;
struct clk *rtc_src_clk;
+   bool clk_enabled;
 
struct s3c_rtc_data *data;
 
@@ -71,9 +72,12 @@ static void s3c_rtc_enable_clk(struct s3c_rtc *info)
unsigned long irq_flags;
 
spin_lock_irqsave(>alarm_clk_lock, irq_flags);
-   clk_enable(info->rtc_clk);
-   if (info->data->needs_src_clk)
-   clk_enable(info->rtc_src_clk);
+   if (!info->clk_enabled) {
+   clk_enable(info->rtc_clk);
+   if (info->data->needs_src_clk)
+   clk_enable(info->rtc_src_clk);
+   info->clk_enabled = true;
+   }
spin_unlock_irqrestore(>alarm_clk_lock, irq_flags);
 }
 
@@ -82,9 +86,12 @@ static void s3c_rtc_disable_clk(struct s3c_rtc *info)
unsigned long irq_flags;
 
spin_lock_irqsave(>alarm_clk_lock, irq_flags);
-   if (info->data->needs_src_clk)
-   clk_disable(info->rtc_src_clk);
-   clk_disable(info->rtc_clk);
+   if (info->clk_enabled) {
+   if (info->data->needs_src_clk)
+   clk_disable(info->rtc_src_clk);
+   clk_disable(info->rtc_clk);
+   info->clk_enabled = false;
+   }
spin_unlock_irqrestore(>alarm_clk_lock, irq_flags);
 }
 
@@ -128,6 +135,11 @@ static int s3c_rtc_setaie(struct device *dev, unsigned int 
enabled)
 
s3c_rtc_disable_clk(info);
 
+   if (enabled)
+   s3c_rtc_enable_clk(info);
+   else
+   s3c_rtc_disable_clk(info);
+
return 0;
 }
 
-- 
1.9.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/

[PATCH 1/4] rtc: s3c: add missing clk control

[Joonyoung Shim]

It's missed to call clk_unprepare() about info->rtc_src_clk in
s3c_rtc_remove and to call clk_disable_unprepare about info->rtc_clk in
error routine of s3c_rtc_probe.

Signed-off-by: Joonyoung Shim 
---
 drivers/rtc/rtc-s3c.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c
index a0f8323..d1866a4 100644
--- a/drivers/rtc/rtc-s3c.c
+++ b/drivers/rtc/rtc-s3c.c
@@ -410,6 +410,8 @@ static int s3c_rtc_remove(struct platform_device *pdev)
 
s3c_rtc_setaie(info->dev, 0);
 
+   if (info->data->needs_src_clk)
+   clk_unprepare(info->rtc_src_clk);
clk_unprepare(info->rtc_clk);
info->rtc_clk = NULL;
 
@@ -482,6 +484,7 @@ static int s3c_rtc_probe(struct platform_device *pdev)
if (IS_ERR(info->rtc_src_clk)) {
dev_err(>dev,
"failed to find rtc source clock\n");
+   clk_disable_unprepare(info->rtc_clk);
return PTR_ERR(info->rtc_src_clk);
}
clk_prepare_enable(info->rtc_src_clk);
-- 
1.9.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/

[PATCH 2/4] rtc: s3c: remove unnecessary NULL assignment

[Joonyoung Shim]

It's unnecessary the code that assigns info->rtc_clk to NULL in
s3c_rtc_remove.

Signed-off-by: Joonyoung Shim 
---
 drivers/rtc/rtc-s3c.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c
index d1866a4..44b2921 100644
--- a/drivers/rtc/rtc-s3c.c
+++ b/drivers/rtc/rtc-s3c.c
@@ -413,7 +413,6 @@ static int s3c_rtc_remove(struct platform_device *pdev)
if (info->data->needs_src_clk)
clk_unprepare(info->rtc_src_clk);
clk_unprepare(info->rtc_clk);
-   info->rtc_clk = NULL;
 
return 0;
 }
-- 
1.9.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/

[PATCH 0/4] modify clock codes of rtc-s3c driver

[Joonyoung Shim]

Hi,

This patchset modifies clock codes of rtc-s3c driver. Main change is to
fix the problem that alarm interrupt can't happen. Also there are some
fixes incluing cleanup.

Thanks.


Joonyoung Shim (4):
  rtc: s3c: add missing clk control
  rtc: s3c: remove unnecessary NULL assignment
  rtc: s3c: use unified functions for enable/disable of clk
  rtc: s3c: enable/disable clocks for alarm

 drivers/rtc/rtc-s3c.c | 40 +---
 1 file changed, 29 insertions(+), 11 deletions(-)
--
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 3/4] rtc: s3c: use unified functions for enable/disable of clk

[Joonyoung Shim]

The driver uses clk_prepare_enable()/clk_disable_unprepare() only in
probe only, elsewhere, use the unified functions for enable/disable of
clk, e.g. s3c_rtc_enable_clk() / s3c_rtc_disable_clk(), so it's better
to use them for consistency of code.

Signed-off-by: Joonyoung Shim 
---
 drivers/rtc/rtc-s3c.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c
index 44b2921..abe2a6d 100644
--- a/drivers/rtc/rtc-s3c.c
+++ b/drivers/rtc/rtc-s3c.c
@@ -476,19 +476,21 @@ static int s3c_rtc_probe(struct platform_device *pdev)
dev_err(>dev, "failed to find rtc clock\n");
return PTR_ERR(info->rtc_clk);
}
-   clk_prepare_enable(info->rtc_clk);
+   clk_prepare(info->rtc_clk);
 
if (info->data->needs_src_clk) {
info->rtc_src_clk = devm_clk_get(>dev, "rtc_src");
if (IS_ERR(info->rtc_src_clk)) {
dev_err(>dev,
"failed to find rtc source clock\n");
-   clk_disable_unprepare(info->rtc_clk);
+   clk_unprepare(info->rtc_clk);
return PTR_ERR(info->rtc_src_clk);
}
-   clk_prepare_enable(info->rtc_src_clk);
+   clk_prepare(info->rtc_src_clk);
}
 
+   s3c_rtc_enable_clk(info);
+
/* check to see if everything is setup correctly */
if (info->data->enable)
info->data->enable(info);
@@ -548,9 +550,11 @@ static int s3c_rtc_probe(struct platform_device *pdev)
if (info->data->disable)
info->data->disable(info);
 
+   s3c_rtc_disable_clk(info);
+
if (info->data->needs_src_clk)
-   clk_disable_unprepare(info->rtc_src_clk);
-   clk_disable_unprepare(info->rtc_clk);
+   clk_unprepare(info->rtc_src_clk);
+   clk_unprepare(info->rtc_clk);
 
return ret;
 }
-- 
1.9.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/

[PATCH 1/4] rtc: s3c: add missing clk control

[Joonyoung Shim]

It's missed to call clk_unprepare() about info-rtc_src_clk in
s3c_rtc_remove and to call clk_disable_unprepare about info-rtc_clk in
error routine of s3c_rtc_probe.

Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
---
 drivers/rtc/rtc-s3c.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c
index a0f8323..d1866a4 100644
--- a/drivers/rtc/rtc-s3c.c
+++ b/drivers/rtc/rtc-s3c.c
@@ -410,6 +410,8 @@ static int s3c_rtc_remove(struct platform_device *pdev)
 
s3c_rtc_setaie(info-dev, 0);
 
+   if (info-data-needs_src_clk)
+   clk_unprepare(info-rtc_src_clk);
clk_unprepare(info-rtc_clk);
info-rtc_clk = NULL;
 
@@ -482,6 +484,7 @@ static int s3c_rtc_probe(struct platform_device *pdev)
if (IS_ERR(info-rtc_src_clk)) {
dev_err(pdev-dev,
failed to find rtc source clock\n);
+   clk_disable_unprepare(info-rtc_clk);
return PTR_ERR(info-rtc_src_clk);
}
clk_prepare_enable(info-rtc_src_clk);
-- 
1.9.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/

[PATCH 4/4] rtc: s3c: enable/disable clocks for alarm

[Joonyoung Shim]

The clock enable/disable codes for alarm have removed from
'commit 24e1455493da (drivers/rtc/rtc-s3c.c: delete duplicate clock
control)' and the clocks keep disabling even if alarm is set, so alarm
interrupt can't happen.

The s3c_rtc_setaie function can be called several times with that
enabled argument has same value, so it needs to check whether clocks is
enabled or not.

Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
---
 drivers/rtc/rtc-s3c.c | 24 ++--
 1 file changed, 18 insertions(+), 6 deletions(-)

diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c
index abe2a6d..fce078c 100644
--- a/drivers/rtc/rtc-s3c.c
+++ b/drivers/rtc/rtc-s3c.c
@@ -39,6 +39,7 @@ struct s3c_rtc {
void __iomem *base;
struct clk *rtc_clk;
struct clk *rtc_src_clk;
+   bool clk_enabled;
 
struct s3c_rtc_data *data;
 
@@ -71,9 +72,12 @@ static void s3c_rtc_enable_clk(struct s3c_rtc *info)
unsigned long irq_flags;
 
spin_lock_irqsave(info-alarm_clk_lock, irq_flags);
-   clk_enable(info-rtc_clk);
-   if (info-data-needs_src_clk)
-   clk_enable(info-rtc_src_clk);
+   if (!info-clk_enabled) {
+   clk_enable(info-rtc_clk);
+   if (info-data-needs_src_clk)
+   clk_enable(info-rtc_src_clk);
+   info-clk_enabled = true;
+   }
spin_unlock_irqrestore(info-alarm_clk_lock, irq_flags);
 }
 
@@ -82,9 +86,12 @@ static void s3c_rtc_disable_clk(struct s3c_rtc *info)
unsigned long irq_flags;
 
spin_lock_irqsave(info-alarm_clk_lock, irq_flags);
-   if (info-data-needs_src_clk)
-   clk_disable(info-rtc_src_clk);
-   clk_disable(info-rtc_clk);
+   if (info-clk_enabled) {
+   if (info-data-needs_src_clk)
+   clk_disable(info-rtc_src_clk);
+   clk_disable(info-rtc_clk);
+   info-clk_enabled = false;
+   }
spin_unlock_irqrestore(info-alarm_clk_lock, irq_flags);
 }
 
@@ -128,6 +135,11 @@ static int s3c_rtc_setaie(struct device *dev, unsigned int 
enabled)
 
s3c_rtc_disable_clk(info);
 
+   if (enabled)
+   s3c_rtc_enable_clk(info);
+   else
+   s3c_rtc_disable_clk(info);
+
return 0;
 }
 
-- 
1.9.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/

[PATCH 2/4] rtc: s3c: remove unnecessary NULL assignment

[Joonyoung Shim]

It's unnecessary the code that assigns info-rtc_clk to NULL in
s3c_rtc_remove.

Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
---
 drivers/rtc/rtc-s3c.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c
index d1866a4..44b2921 100644
--- a/drivers/rtc/rtc-s3c.c
+++ b/drivers/rtc/rtc-s3c.c
@@ -413,7 +413,6 @@ static int s3c_rtc_remove(struct platform_device *pdev)
if (info-data-needs_src_clk)
clk_unprepare(info-rtc_src_clk);
clk_unprepare(info-rtc_clk);
-   info-rtc_clk = NULL;
 
return 0;
 }
-- 
1.9.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/

[PATCH 0/4] modify clock codes of rtc-s3c driver

[Joonyoung Shim]

Hi,

This patchset modifies clock codes of rtc-s3c driver. Main change is to
fix the problem that alarm interrupt can't happen. Also there are some
fixes incluing cleanup.

Thanks.


Joonyoung Shim (4):
  rtc: s3c: add missing clk control
  rtc: s3c: remove unnecessary NULL assignment
  rtc: s3c: use unified functions for enable/disable of clk
  rtc: s3c: enable/disable clocks for alarm

 drivers/rtc/rtc-s3c.c | 40 +---
 1 file changed, 29 insertions(+), 11 deletions(-)
--
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 3/4] rtc: s3c: use unified functions for enable/disable of clk

[Joonyoung Shim]

The driver uses clk_prepare_enable()/clk_disable_unprepare() only in
probe only, elsewhere, use the unified functions for enable/disable of
clk, e.g. s3c_rtc_enable_clk() / s3c_rtc_disable_clk(), so it's better
to use them for consistency of code.

Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
---
 drivers/rtc/rtc-s3c.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c
index 44b2921..abe2a6d 100644
--- a/drivers/rtc/rtc-s3c.c
+++ b/drivers/rtc/rtc-s3c.c
@@ -476,19 +476,21 @@ static int s3c_rtc_probe(struct platform_device *pdev)
dev_err(pdev-dev, failed to find rtc clock\n);
return PTR_ERR(info-rtc_clk);
}
-   clk_prepare_enable(info-rtc_clk);
+   clk_prepare(info-rtc_clk);
 
if (info-data-needs_src_clk) {
info-rtc_src_clk = devm_clk_get(pdev-dev, rtc_src);
if (IS_ERR(info-rtc_src_clk)) {
dev_err(pdev-dev,
failed to find rtc source clock\n);
-   clk_disable_unprepare(info-rtc_clk);
+   clk_unprepare(info-rtc_clk);
return PTR_ERR(info-rtc_src_clk);
}
-   clk_prepare_enable(info-rtc_src_clk);
+   clk_prepare(info-rtc_src_clk);
}
 
+   s3c_rtc_enable_clk(info);
+
/* check to see if everything is setup correctly */
if (info-data-enable)
info-data-enable(info);
@@ -548,9 +550,11 @@ static int s3c_rtc_probe(struct platform_device *pdev)
if (info-data-disable)
info-data-disable(info);
 
+   s3c_rtc_disable_clk(info);
+
if (info-data-needs_src_clk)
-   clk_disable_unprepare(info-rtc_src_clk);
-   clk_disable_unprepare(info-rtc_clk);
+   clk_unprepare(info-rtc_src_clk);
+   clk_unprepare(info-rtc_clk);
 
return ret;
 }
-- 
1.9.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/

Re: [PATCH 4/4] rtc: s3c: enable/disable clocks for alarm

[Joonyoung Shim]

On 08/12/2015 09:28 AM, Krzysztof Kozlowski wrote:
 On 11.08.2015 20:28, Joonyoung Shim wrote:
 The clock enable/disable codes for alarm have removed from
 
 What do you mean in this paragraph? The clock code was removing something?
 
 'commit 24e1455493da (drivers/rtc/rtc-s3c.c: delete duplicate clock
 
 Remove the 'apostrophe.
 
 control)' and the clocks keep disabling even if alarm is set, so alarm
 interrupt can't happen.
 ...and the clocks are disabled even...
 
 

 The s3c_rtc_setaie function can be called several times with that
 enabled argument has same value,
 ...several times with 'enabled' argument having same value
 
 so it needs to check whether clocks is
 enabled or not.
 s/is/are/
 

 Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
 
 Please add Cc-stable and fixes tag. To backport the patch probably
 you'll have to remove the dependency on previous patches.

Thanks for the point, i didn't think it.
--
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: Linux-next, Exynos Octa boot fail, bisected to: "drm/exynos: remove drm_iommu_attach_device_if_possible"

[Joonyoung Shim]

On 07/22/2015 05:22 PM, Inki Dae wrote:
> On 2015년 07월 22일 17:12, Joonyoung Shim wrote:
>> On 07/22/2015 01:55 PM, Inki Dae wrote:
>>> On 2015년 07월 22일 11:02, Joonyoung Shim wrote:
>>>> On 07/21/2015 10:19 PM, Krzysztof Kozlowski wrote:
>>>>> Hi,
>>>>>
>>>>> Today's linux-next (next-20150721) encounters boot failures on Exynos
>>>>> Octa (Exynos5422) based boards. The boards hangs. I bisected it to:
>>>>>
>>>>> d80167b85024982c5f18d0481a5c248100360118 is the first bad commit
>>>>> commit d80167b85024982c5f18d0481a5c248100360118
>>>>> Author: Joonyoung Shim 
>>>>> Date:   Thu Jul 2 21:49:39 2015 +0900
>>>>>
>>>>> drm/exynos: remove drm_iommu_attach_device_if_possible
>>>>>
>>>>> Already drm_iommu_attach_device checks whether support iommu 
>>>>> internally.
>>>>> It should clear channels always regardless iommu support. We didn't 
>>>>> know
>>>>> because we can detect the problem when iommu is enabled, so we don't
>>>>> have to use drm_iommu_attach_device_if_possible and then we can remove
>>>>> drm_iommu_attach_device_if_possible and clear_channels function 
>>>>> pointer.
>>>>>
>>>>> Signed-off-by: Joonyoung Shim 
>>>>> Tested-by: Marek Szyprowski 
>>>>> Signed-off-by: Inki Dae 
>>>>>
>>>>> :04 04 83379efbf4960f58d680371628ec04387935bd53
>>>>> da03c338b88e7cb6bda895b3dd52d78d9b6eba30 M drivers
>>>>>
>>>>>
>>>>> Config: exynos
>>>>> Boot log from Odroid XU3-Lite attached.
>>>>>
>>>>> Any hints or ideas?
>>>>
>>>> The point that hangs is when accesses fimd register in
>>>> fimd_clear_channels function, so i doubt clock setting for fimd.
>>>>
>>>> It's gone something that hangs after i enable gating for ACLK_200_DISP1
>>>> clock.
>>>>
>>>> If ACLK_200_DISP1 clock needs for fimd really, i'm thinking how can it
>>>> support. Any ideas?
>>>
>>> I think bootloader should have enabled ACLK_200_DISP1 clock and also
>>> device driver should enable all relevant clocks before the device
>>> accesses its own registers.
>>>
>>> Best way would be that the clock is enabled by common clock framework
>>> but it seems there is no anything that the clock framework can do it. So
>>> I think what we have to do is to add the clock support to device tree.
>>
>> It's not easy problem to me. Should we add which clock? I think we
>> cannot control ACLK_200_DISP1 or CLKDIV2_DISP1_BLK directly by below
>> hierarchy, right? Then we should control gate clocks, but we have not
>> controlled any gate clocks using BTS_ prefix.
>>
>> The clock hierarchy from Exynos5422 user manual,
>> ACLK_200_DISP1 -- CLKDIV2_DISP1_BLK -- HDMI LINK
>>HDMI PHY
>>MIC1
>>DSIM1
>>DPTX LINK
>>MDNIE1
>>SYSMMU_MIXER
>>SYSMMU_FIMD1_M0
>>SYSMMU_FIMD1_M1
>>BTS_TVM0
>>BTS_TVM1
>>BTS_FIMD1_M0
>>BTS_FIMD1_M1
>>
>> Other way, IMHO, fimd driver doesn't have to enable ACLK_200_DISP1 clock,
>> just it should be controlled by connector drivers, e.g. dsi, dp because
>> fimd only cannot operate, so dsi or dp must need (Actually i'm not sure
>> about this, just i thought that Exynos5 SoCs don't have any gpios for
>> dpi, so they cannot use dpi, right?).
>>
>> It needs to probe connector driver like dsi or dp earlier than fimd and
>> fimd_bind function should return error if connector driver like dsi or
>> dp was not probed. This is also not easy to me.
> 
> In this case, if one of above gate clocks is enabled, the ACLK_200_DISP1
> should be enabled. So I guess the problem would be due to below line of
> clk-exynos5420.c,
> 
> GATE(CLK_FIMD1, "fimd1", "aclk300_disp1", GATE_IP_DISP1, 0, 0, 0),
> 
> Can you check it again after modifying it like below?,
> GATE(CLK_FIMD1, "fimd1", "aclk200_disp1", GATE_IP_DISP1, 0, 0, 0),

No, parent clock of fimd1 gate clock is ACLK_300_DISP1.
--
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: Linux-next, Exynos Octa boot fail, bisected to: "drm/exynos: remove drm_iommu_attach_device_if_possible"

[Joonyoung Shim]

On 07/22/2015 01:55 PM, Inki Dae wrote:
> On 2015년 07월 22일 11:02, Joonyoung Shim wrote:
>> On 07/21/2015 10:19 PM, Krzysztof Kozlowski wrote:
>>> Hi,
>>>
>>> Today's linux-next (next-20150721) encounters boot failures on Exynos
>>> Octa (Exynos5422) based boards. The boards hangs. I bisected it to:
>>>
>>> d80167b85024982c5f18d0481a5c248100360118 is the first bad commit
>>> commit d80167b85024982c5f18d0481a5c248100360118
>>> Author: Joonyoung Shim 
>>> Date:   Thu Jul 2 21:49:39 2015 +0900
>>>
>>> drm/exynos: remove drm_iommu_attach_device_if_possible
>>>
>>> Already drm_iommu_attach_device checks whether support iommu internally.
>>> It should clear channels always regardless iommu support. We didn't know
>>> because we can detect the problem when iommu is enabled, so we don't
>>> have to use drm_iommu_attach_device_if_possible and then we can remove
>>> drm_iommu_attach_device_if_possible and clear_channels function pointer.
>>>
>>> Signed-off-by: Joonyoung Shim 
>>> Tested-by: Marek Szyprowski 
>>> Signed-off-by: Inki Dae 
>>>
>>> :04 04 83379efbf4960f58d680371628ec04387935bd53
>>> da03c338b88e7cb6bda895b3dd52d78d9b6eba30 M drivers
>>>
>>>
>>> Config: exynos
>>> Boot log from Odroid XU3-Lite attached.
>>>
>>> Any hints or ideas?
>>
>> The point that hangs is when accesses fimd register in
>> fimd_clear_channels function, so i doubt clock setting for fimd.
>>
>> It's gone something that hangs after i enable gating for ACLK_200_DISP1
>> clock.
>>
>> If ACLK_200_DISP1 clock needs for fimd really, i'm thinking how can it
>> support. Any ideas?
> 
> I think bootloader should have enabled ACLK_200_DISP1 clock and also
> device driver should enable all relevant clocks before the device
> accesses its own registers.
> 
> Best way would be that the clock is enabled by common clock framework
> but it seems there is no anything that the clock framework can do it. So
> I think what we have to do is to add the clock support to device tree.

It's not easy problem to me. Should we add which clock? I think we
cannot control ACLK_200_DISP1 or CLKDIV2_DISP1_BLK directly by below
hierarchy, right? Then we should control gate clocks, but we have not
controlled any gate clocks using BTS_ prefix.

The clock hierarchy from Exynos5422 user manual,
ACLK_200_DISP1 -- CLKDIV2_DISP1_BLK -- HDMI LINK
   HDMI PHY
   MIC1
   DSIM1
   DPTX LINK
   MDNIE1
   SYSMMU_MIXER
   SYSMMU_FIMD1_M0
   SYSMMU_FIMD1_M1
   BTS_TVM0
   BTS_TVM1
   BTS_FIMD1_M0
   BTS_FIMD1_M1

Other way, IMHO, fimd driver doesn't have to enable ACLK_200_DISP1 clock,
just it should be controlled by connector drivers, e.g. dsi, dp because
fimd only cannot operate, so dsi or dp must need (Actually i'm not sure
about this, just i thought that Exynos5 SoCs don't have any gpios for
dpi, so they cannot use dpi, right?).

It needs to probe connector driver like dsi or dp earlier than fimd and
fimd_bind function should return error if connector driver like dsi or
dp was not probed. This is also not easy to me.
--
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: Linux-next, Exynos Octa boot fail, bisected to: drm/exynos: remove drm_iommu_attach_device_if_possible

[Joonyoung Shim]

On 07/22/2015 01:55 PM, Inki Dae wrote:
 On 2015년 07월 22일 11:02, Joonyoung Shim wrote:
 On 07/21/2015 10:19 PM, Krzysztof Kozlowski wrote:
 Hi,

 Today's linux-next (next-20150721) encounters boot failures on Exynos
 Octa (Exynos5422) based boards. The boards hangs. I bisected it to:

 d80167b85024982c5f18d0481a5c248100360118 is the first bad commit
 commit d80167b85024982c5f18d0481a5c248100360118
 Author: Joonyoung Shim jy0922.s...@samsung.com
 Date:   Thu Jul 2 21:49:39 2015 +0900

 drm/exynos: remove drm_iommu_attach_device_if_possible

 Already drm_iommu_attach_device checks whether support iommu internally.
 It should clear channels always regardless iommu support. We didn't know
 because we can detect the problem when iommu is enabled, so we don't
 have to use drm_iommu_attach_device_if_possible and then we can remove
 drm_iommu_attach_device_if_possible and clear_channels function pointer.

 Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
 Tested-by: Marek Szyprowski m.szyprow...@samsung.com
 Signed-off-by: Inki Dae inki@samsung.com

 :04 04 83379efbf4960f58d680371628ec04387935bd53
 da03c338b88e7cb6bda895b3dd52d78d9b6eba30 M drivers


 Config: exynos
 Boot log from Odroid XU3-Lite attached.

 Any hints or ideas?

 The point that hangs is when accesses fimd register in
 fimd_clear_channels function, so i doubt clock setting for fimd.

 It's gone something that hangs after i enable gating for ACLK_200_DISP1
 clock.

 If ACLK_200_DISP1 clock needs for fimd really, i'm thinking how can it
 support. Any ideas?
 
 I think bootloader should have enabled ACLK_200_DISP1 clock and also
 device driver should enable all relevant clocks before the device
 accesses its own registers.
 
 Best way would be that the clock is enabled by common clock framework
 but it seems there is no anything that the clock framework can do it. So
 I think what we have to do is to add the clock support to device tree.

It's not easy problem to me. Should we add which clock? I think we
cannot control ACLK_200_DISP1 or CLKDIV2_DISP1_BLK directly by below
hierarchy, right? Then we should control gate clocks, but we have not
controlled any gate clocks using BTS_ prefix.

The clock hierarchy from Exynos5422 user manual,
ACLK_200_DISP1 -- CLKDIV2_DISP1_BLK -- HDMI LINK
   HDMI PHY
   MIC1
   DSIM1
   DPTX LINK
   MDNIE1
   SYSMMU_MIXER
   SYSMMU_FIMD1_M0
   SYSMMU_FIMD1_M1
   BTS_TVM0
   BTS_TVM1
   BTS_FIMD1_M0
   BTS_FIMD1_M1

Other way, IMHO, fimd driver doesn't have to enable ACLK_200_DISP1 clock,
just it should be controlled by connector drivers, e.g. dsi, dp because
fimd only cannot operate, so dsi or dp must need (Actually i'm not sure
about this, just i thought that Exynos5 SoCs don't have any gpios for
dpi, so they cannot use dpi, right?).

It needs to probe connector driver like dsi or dp earlier than fimd and
fimd_bind function should return error if connector driver like dsi or
dp was not probed. This is also not easy to me.
--
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: Linux-next, Exynos Octa boot fail, bisected to: drm/exynos: remove drm_iommu_attach_device_if_possible

[Joonyoung Shim]

On 07/22/2015 05:22 PM, Inki Dae wrote:
 On 2015년 07월 22일 17:12, Joonyoung Shim wrote:
 On 07/22/2015 01:55 PM, Inki Dae wrote:
 On 2015년 07월 22일 11:02, Joonyoung Shim wrote:
 On 07/21/2015 10:19 PM, Krzysztof Kozlowski wrote:
 Hi,

 Today's linux-next (next-20150721) encounters boot failures on Exynos
 Octa (Exynos5422) based boards. The boards hangs. I bisected it to:

 d80167b85024982c5f18d0481a5c248100360118 is the first bad commit
 commit d80167b85024982c5f18d0481a5c248100360118
 Author: Joonyoung Shim jy0922.s...@samsung.com
 Date:   Thu Jul 2 21:49:39 2015 +0900

 drm/exynos: remove drm_iommu_attach_device_if_possible

 Already drm_iommu_attach_device checks whether support iommu 
 internally.
 It should clear channels always regardless iommu support. We didn't 
 know
 because we can detect the problem when iommu is enabled, so we don't
 have to use drm_iommu_attach_device_if_possible and then we can remove
 drm_iommu_attach_device_if_possible and clear_channels function 
 pointer.

 Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
 Tested-by: Marek Szyprowski m.szyprow...@samsung.com
 Signed-off-by: Inki Dae inki@samsung.com

 :04 04 83379efbf4960f58d680371628ec04387935bd53
 da03c338b88e7cb6bda895b3dd52d78d9b6eba30 M drivers


 Config: exynos
 Boot log from Odroid XU3-Lite attached.

 Any hints or ideas?

 The point that hangs is when accesses fimd register in
 fimd_clear_channels function, so i doubt clock setting for fimd.

 It's gone something that hangs after i enable gating for ACLK_200_DISP1
 clock.

 If ACLK_200_DISP1 clock needs for fimd really, i'm thinking how can it
 support. Any ideas?

 I think bootloader should have enabled ACLK_200_DISP1 clock and also
 device driver should enable all relevant clocks before the device
 accesses its own registers.

 Best way would be that the clock is enabled by common clock framework
 but it seems there is no anything that the clock framework can do it. So
 I think what we have to do is to add the clock support to device tree.

 It's not easy problem to me. Should we add which clock? I think we
 cannot control ACLK_200_DISP1 or CLKDIV2_DISP1_BLK directly by below
 hierarchy, right? Then we should control gate clocks, but we have not
 controlled any gate clocks using BTS_ prefix.

 The clock hierarchy from Exynos5422 user manual,
 ACLK_200_DISP1 -- CLKDIV2_DISP1_BLK -- HDMI LINK
HDMI PHY
MIC1
DSIM1
DPTX LINK
MDNIE1
SYSMMU_MIXER
SYSMMU_FIMD1_M0
SYSMMU_FIMD1_M1
BTS_TVM0
BTS_TVM1
BTS_FIMD1_M0
BTS_FIMD1_M1

 Other way, IMHO, fimd driver doesn't have to enable ACLK_200_DISP1 clock,
 just it should be controlled by connector drivers, e.g. dsi, dp because
 fimd only cannot operate, so dsi or dp must need (Actually i'm not sure
 about this, just i thought that Exynos5 SoCs don't have any gpios for
 dpi, so they cannot use dpi, right?).

 It needs to probe connector driver like dsi or dp earlier than fimd and
 fimd_bind function should return error if connector driver like dsi or
 dp was not probed. This is also not easy to me.
 
 In this case, if one of above gate clocks is enabled, the ACLK_200_DISP1
 should be enabled. So I guess the problem would be due to below line of
 clk-exynos5420.c,
 
 GATE(CLK_FIMD1, fimd1, aclk300_disp1, GATE_IP_DISP1, 0, 0, 0),
 
 Can you check it again after modifying it like below?,
 GATE(CLK_FIMD1, fimd1, aclk200_disp1, GATE_IP_DISP1, 0, 0, 0),

No, parent clock of fimd1 gate clock is ACLK_300_DISP1.
--
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: Linux-next, Exynos Octa boot fail, bisected to: "drm/exynos: remove drm_iommu_attach_device_if_possible"

[Joonyoung Shim]

On 07/21/2015 10:19 PM, Krzysztof Kozlowski wrote:
> Hi,
> 
> Today's linux-next (next-20150721) encounters boot failures on Exynos
> Octa (Exynos5422) based boards. The boards hangs. I bisected it to:
> 
> d80167b85024982c5f18d0481a5c248100360118 is the first bad commit
> commit d80167b85024982c5f18d0481a5c248100360118
> Author: Joonyoung Shim 
> Date:   Thu Jul 2 21:49:39 2015 +0900
> 
> drm/exynos: remove drm_iommu_attach_device_if_possible
> 
> Already drm_iommu_attach_device checks whether support iommu internally.
> It should clear channels always regardless iommu support. We didn't know
> because we can detect the problem when iommu is enabled, so we don't
> have to use drm_iommu_attach_device_if_possible and then we can remove
> drm_iommu_attach_device_if_possible and clear_channels function pointer.
> 
> Signed-off-by: Joonyoung Shim 
> Tested-by: Marek Szyprowski 
> Signed-off-by: Inki Dae 
> 
> :04 04 83379efbf4960f58d680371628ec04387935bd53
> da03c338b88e7cb6bda895b3dd52d78d9b6eba30 M drivers
> 
> 
> Config: exynos
> Boot log from Odroid XU3-Lite attached.
> 
> Any hints or ideas?

The point that hangs is when accesses fimd register in
fimd_clear_channels function, so i doubt clock setting for fimd.

It's gone something that hangs after i enable gating for ACLK_200_DISP1
clock.

If ACLK_200_DISP1 clock needs for fimd really, i'm thinking how can it
support. Any ideas?

Thanks.
--
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: Linux-next, Exynos Octa boot fail, bisected to: drm/exynos: remove drm_iommu_attach_device_if_possible

[Joonyoung Shim]

On 07/21/2015 10:19 PM, Krzysztof Kozlowski wrote:
 Hi,
 
 Today's linux-next (next-20150721) encounters boot failures on Exynos
 Octa (Exynos5422) based boards. The boards hangs. I bisected it to:
 
 d80167b85024982c5f18d0481a5c248100360118 is the first bad commit
 commit d80167b85024982c5f18d0481a5c248100360118
 Author: Joonyoung Shim jy0922.s...@samsung.com
 Date:   Thu Jul 2 21:49:39 2015 +0900
 
 drm/exynos: remove drm_iommu_attach_device_if_possible
 
 Already drm_iommu_attach_device checks whether support iommu internally.
 It should clear channels always regardless iommu support. We didn't know
 because we can detect the problem when iommu is enabled, so we don't
 have to use drm_iommu_attach_device_if_possible and then we can remove
 drm_iommu_attach_device_if_possible and clear_channels function pointer.
 
 Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
 Tested-by: Marek Szyprowski m.szyprow...@samsung.com
 Signed-off-by: Inki Dae inki@samsung.com
 
 :04 04 83379efbf4960f58d680371628ec04387935bd53
 da03c338b88e7cb6bda895b3dd52d78d9b6eba30 M drivers
 
 
 Config: exynos
 Boot log from Odroid XU3-Lite attached.
 
 Any hints or ideas?

The point that hangs is when accesses fimd register in
fimd_clear_channels function, so i doubt clock setting for fimd.

It's gone something that hangs after i enable gating for ACLK_200_DISP1
clock.

If ACLK_200_DISP1 clock needs for fimd really, i'm thinking how can it
support. Any ideas?

Thanks.
--
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 RESEND v2 2/6] drm/exynos/mixer: fix interrupt clearing

[Joonyoung Shim]

On 07/09/2015 05:07 PM, Andrzej Hajda wrote:
> The driver used incorrect flags to clear interrupt status.
> The patch fixes it.
> 
> Signed-off-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/exynos/exynos_mixer.c | 9 -
>  1 file changed, 4 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index cae98db..25f0aac 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -718,6 +718,10 @@ static irqreturn_t mixer_irq_handler(int irq, void *arg)
>  
>   /* handling VSYNC */
>   if (val & MXR_INT_STATUS_VSYNC) {
> + /* vsync interrupt use different bit for read and clear */
> + val |= MXR_INT_CLEAR_VSYNC;
> + val &= ~MXR_INT_STATUS_VSYNC;
> +
>   /* interlace scan need to check shadow register */
>   if (ctx->interlace) {
>   base = mixer_reg_read(res, MXR_GRAPHIC_BASE(0));
> @@ -743,11 +747,6 @@ static irqreturn_t mixer_irq_handler(int irq, void *arg)
>  
>  out:
>   /* clear interrupts */
> - if (~val & MXR_INT_EN_VSYNC) {
> - /* vsync interrupt use different bit for read and clear */
> - val &= ~MXR_INT_EN_VSYNC;
> - val |= MXR_INT_CLEAR_VSYNC;
> -     }
>   mixer_reg_write(res, MXR_INT_STATUS, val);
>  
>   spin_unlock(>reg_slock);
> 

Reviewed-by: Joonyoung Shim 

Thanks.
--
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 RESEND 0/6] drm/exynos: HDMI related fixes

[Joonyoung Shim]

Hi Andrzej,

On 07/09/2015 03:25 PM, Andrzej Hajda wrote:
> 
> 
> Andrzej Hajda (6):
>   drm/exynos/hdmi: fix edid memory leak
>   drm/exynos/mixer: fix interrupt clearing
>   drm/exynos/mixer: correct vsync configuration sequence
>   drm/exynos/mixer: always update INT_EN cache
>   drm/exynos/mixer: simplify poweron flag
>   drm/exynos/mixer: replace MXR_INT_EN register cache with flag
> 
>  drivers/gpu/drm/exynos/exynos_hdmi.c  |  7 ++-
>  drivers/gpu/drm/exynos/exynos_mixer.c | 80 
> +--
>  2 files changed, 36 insertions(+), 51 deletions(-)
> 

Looks good to me except one comment of "drm/exynos/mixer: fix interrupt
clearing" patch. Also below my patch can be dropped by this patchset.

http://www.spinics.net/lists/dri-devel/msg85322.html

Reviewed-by: Joonyoung Shim 
--
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 RESEND 2/6] drm/exynos/mixer: fix interrupt clearing

[Joonyoung Shim]

On 07/09/2015 03:25 PM, Andrzej Hajda wrote:
> The driver used incorrect flags to clear interrupt status.
> The patch fixes it.
> 
> Signed-off-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/exynos/exynos_mixer.c | 8 +++-
>  1 file changed, 3 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index cae98db..0686484 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -718,6 +718,9 @@ static irqreturn_t mixer_irq_handler(int irq, void *arg)
>  
>   /* handling VSYNC */
>   if (val & MXR_INT_STATUS_VSYNC) {
> + /* vsync interrupt use different bit for read and clear */
> + val |= MXR_INT_CLEAR_VSYNC;

MXR_INT_STATUS_VSYNC bit of MXR_INT_STATUS register is read-only, so it
needs to be clear MXR_INT_STATUS_VSYNC bit of val.

> +
>   /* interlace scan need to check shadow register */
>   if (ctx->interlace) {
>   base = mixer_reg_read(res, MXR_GRAPHIC_BASE(0));
> @@ -743,11 +746,6 @@ static irqreturn_t mixer_irq_handler(int irq, void *arg)
>  
>  out:
>   /* clear interrupts */
> - if (~val & MXR_INT_EN_VSYNC) {
> - /* vsync interrupt use different bit for read and clear */
> - val &= ~MXR_INT_EN_VSYNC;
> - val |= MXR_INT_CLEAR_VSYNC;
> - }
>   mixer_reg_write(res, MXR_INT_STATUS, val);
>  
>   spin_unlock(>reg_slock);
> 

--
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 RESEND 0/6] drm/exynos: HDMI related fixes

[Joonyoung Shim]

Hi Andrzej,

On 07/09/2015 03:25 PM, Andrzej Hajda wrote:
 
 
 Andrzej Hajda (6):
   drm/exynos/hdmi: fix edid memory leak
   drm/exynos/mixer: fix interrupt clearing
   drm/exynos/mixer: correct vsync configuration sequence
   drm/exynos/mixer: always update INT_EN cache
   drm/exynos/mixer: simplify poweron flag
   drm/exynos/mixer: replace MXR_INT_EN register cache with flag
 
  drivers/gpu/drm/exynos/exynos_hdmi.c  |  7 ++-
  drivers/gpu/drm/exynos/exynos_mixer.c | 80 
 +--
  2 files changed, 36 insertions(+), 51 deletions(-)
 

Looks good to me except one comment of drm/exynos/mixer: fix interrupt
clearing patch. Also below my patch can be dropped by this patchset.

http://www.spinics.net/lists/dri-devel/msg85322.html

Reviewed-by: Joonyoung Shim jy0922.s...@samsung.com
--
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 RESEND v2 2/6] drm/exynos/mixer: fix interrupt clearing

[Joonyoung Shim]

On 07/09/2015 05:07 PM, Andrzej Hajda wrote:
 The driver used incorrect flags to clear interrupt status.
 The patch fixes it.
 
 Signed-off-by: Andrzej Hajda a.ha...@samsung.com
 ---
  drivers/gpu/drm/exynos/exynos_mixer.c | 9 -
  1 file changed, 4 insertions(+), 5 deletions(-)
 
 diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
 b/drivers/gpu/drm/exynos/exynos_mixer.c
 index cae98db..25f0aac 100644
 --- a/drivers/gpu/drm/exynos/exynos_mixer.c
 +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
 @@ -718,6 +718,10 @@ static irqreturn_t mixer_irq_handler(int irq, void *arg)
  
   /* handling VSYNC */
   if (val  MXR_INT_STATUS_VSYNC) {
 + /* vsync interrupt use different bit for read and clear */
 + val |= MXR_INT_CLEAR_VSYNC;
 + val = ~MXR_INT_STATUS_VSYNC;
 +
   /* interlace scan need to check shadow register */
   if (ctx-interlace) {
   base = mixer_reg_read(res, MXR_GRAPHIC_BASE(0));
 @@ -743,11 +747,6 @@ static irqreturn_t mixer_irq_handler(int irq, void *arg)
  
  out:
   /* clear interrupts */
 - if (~val  MXR_INT_EN_VSYNC) {
 - /* vsync interrupt use different bit for read and clear */
 - val = ~MXR_INT_EN_VSYNC;
 - val |= MXR_INT_CLEAR_VSYNC;
 - }
   mixer_reg_write(res, MXR_INT_STATUS, val);
  
   spin_unlock(res-reg_slock);
 

Reviewed-by: Joonyoung Shim jy0922.s...@samsung.com

Thanks.
--
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 RESEND 2/6] drm/exynos/mixer: fix interrupt clearing

[Joonyoung Shim]

On 07/09/2015 03:25 PM, Andrzej Hajda wrote:
 The driver used incorrect flags to clear interrupt status.
 The patch fixes it.
 
 Signed-off-by: Andrzej Hajda a.ha...@samsung.com
 ---
  drivers/gpu/drm/exynos/exynos_mixer.c | 8 +++-
  1 file changed, 3 insertions(+), 5 deletions(-)
 
 diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
 b/drivers/gpu/drm/exynos/exynos_mixer.c
 index cae98db..0686484 100644
 --- a/drivers/gpu/drm/exynos/exynos_mixer.c
 +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
 @@ -718,6 +718,9 @@ static irqreturn_t mixer_irq_handler(int irq, void *arg)
  
   /* handling VSYNC */
   if (val  MXR_INT_STATUS_VSYNC) {
 + /* vsync interrupt use different bit for read and clear */
 + val |= MXR_INT_CLEAR_VSYNC;

MXR_INT_STATUS_VSYNC bit of MXR_INT_STATUS register is read-only, so it
needs to be clear MXR_INT_STATUS_VSYNC bit of val.

 +
   /* interlace scan need to check shadow register */
   if (ctx-interlace) {
   base = mixer_reg_read(res, MXR_GRAPHIC_BASE(0));
 @@ -743,11 +746,6 @@ static irqreturn_t mixer_irq_handler(int irq, void *arg)
  
  out:
   /* clear interrupts */
 - if (~val  MXR_INT_EN_VSYNC) {
 - /* vsync interrupt use different bit for read and clear */
 - val = ~MXR_INT_EN_VSYNC;
 - val |= MXR_INT_CLEAR_VSYNC;
 - }
   mixer_reg_write(res, MXR_INT_STATUS, val);
  
   spin_unlock(res-reg_slock);
 

--
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/2] clk: divider: fix to set parent rate from CLK_DIVIDER_READ_ONLY flag

[Joonyoung Shim]

Hi Michael,

On 05/13/2015 08:57 AM, Stephen Boyd wrote:
> On 05/12, Michael Turquette wrote:
>> Quoting Joonyoung Shim (2015-04-07 00:46:46)
>>> The round_rate callback function will returns alway same parent clk rate
>>> of divider with CLK_DIVIDER_READ_ONLY flag. If be used
>>> CLK_SET_RATE_PARENT flag with CLK_DIVIDER_READ_ONLY flag, then never
>>> change parent clk rate anymore.
>>>
>>> From this case, this patch allows to change parent clk rate.
>>>
>>> Signed-off-by: Joonyoung Shim 
>>> ---
>>>  drivers/clk/clk-divider.c | 5 +
>>>  1 file changed, 5 insertions(+)
>>>
>>> diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
>>> index ce34d29a..37e285e 100644
>>> --- a/drivers/clk/clk-divider.c
>>> +++ b/drivers/clk/clk-divider.c
>>> @@ -352,6 +352,11 @@ static long clk_divider_round_rate(struct clk_hw *hw, 
>>> unsigned long rate,
>>> bestdiv = readl(divider->reg) >> divider->shift;
>>> bestdiv &= div_mask(divider->width);
>>> bestdiv = _get_div(divider->table, bestdiv, divider->flags);
>>> +
>>> +   if ((__clk_get_flags(hw->clk) & CLK_SET_RATE_PARENT))
>>> +       *prate = __clk_round_rate(__clk_get_parent(hw->clk),
>>> + rate);
>>> +
>>> return DIV_ROUND_UP(*prate, bestdiv);
>>> }
>>>  
>>> -- 
>>> 1.9.1
>>>
>>
>> Hello Joonyoung Shim,
>>
>> Thanks for reporting the bug and providing a fix!
>>
>> I've come up with an alternative solution to this. This patch should
>> replace both of your patches. Can you test this and see if it fixes the
>> problem for you?
>>

Yes, it works.

>> Thanks,
>> Mike
>>
>>
>>
>> From 655dddad2700a30aaa397cd804422e0d9195efad Mon Sep 17 00:00:00 2001
>> From: Michael Turquette 
>> Date: Tue, 12 May 2015 16:13:46 -0700
>> Subject: [PATCH] clk: divider: support read-only dividers
>>
>> An arbitrary clock rate divider may be set out of reset, or perhaps by
>> the bootloader or something other than Linux. In these cases we may want
>> to know the frequency of the clock signal, but we do not want to allow
>> Linux to change it.
>>
>> The CLK_DIVIDER_READ_ONLY flag was intended to express this, but the
>> functionality was missing in the code. Add read-only clk_ops for divider
>> clocks to handle this case.
>>
>> For hardware with fixed dividers it is still best to use the
>> fixed-factor clock type.
>>
>> Reported-by: Joonyoung Shim 
>> Signed-off-by: Michael Turquette 
>> ---
>>  drivers/clk/clk-divider.c | 10 +-
>>  1 file changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
>> index 25006a8..5d2de26 100644
>> --- a/drivers/clk/clk-divider.c
>> +++ b/drivers/clk/clk-divider.c
>> @@ -412,6 +412,11 @@ const struct clk_ops clk_divider_ops = {
>>  };
>>  EXPORT_SYMBOL_GPL(clk_divider_ops);
>>  
>> +const struct clk_ops clk_divider_ro_ops = {
>> +.recalc_rate = clk_divider_recalc_rate,
>> +};
>> +EXPORT_SYMBOL_GPL(clk_divider_ro_ops);
>> +
>>  static struct clk *_register_divider(struct device *dev, const char *name,
>>  const char *parent_name, unsigned long flags,
>>  void __iomem *reg, u8 shift, u8 width,
>> @@ -437,7 +442,10 @@ static struct clk *_register_divider(struct device 
>> *dev, const char *name,
>>  }
>>  
>>  init.name = name;
>> -init.ops = _divider_ops;
>> +if (clk_divider_flags & CLK_DIVIDER_READ_ONLY)
>> +init.ops = _divider_ro_ops;
>> +else
>> +init.ops = _divider_ops;
>>  init.flags = flags | CLK_IS_BASIC;
>>  init.parent_names = (parent_name ? _name: NULL);
>>  init.num_parents = (parent_name ? 1 : 0);
>> -- 
> 
> Isn't this sort of reverting commit e6d5e7d90be9 (clk-divider:
> Fix READ_ONLY when divider > 1, 2014-11-14)? 
> 

So i had abandoned to retry commit e6d5e7d90be9.

Thanks.
--
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] clk: divider: don't set_rate with CLK_DIVIDER_READ_ONLY flag

[Joonyoung Shim]

Hi Stephen,

On 05/13/2015 08:59 AM, Stephen Boyd wrote:
> On 04/07, Joonyoung Shim wrote:
>> Even if use CLK_DIVIDER_READ_ONLY flag, divider setting can be changed
>> by set_rate callback. Don't change divider setting from set_rate
>> callback of divider with CLK_DIVIDER_READ_ONLY flag.
>>
>> Signed-off-by: Joonyoung Shim 
>> ---
> 
> Is the rate actually changing? Or is it just a problem that we
> may be writing the register to the same value it already is?
> 

If rate and parant_rate are different, it can write the register to
different value. Even if the value is same but i think it's unnecessary
to re-write the register.

Thanks.
--
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] clk: divider: don't set_rate with CLK_DIVIDER_READ_ONLY flag

[Joonyoung Shim]

Hi Stephen,

On 05/13/2015 08:59 AM, Stephen Boyd wrote:
 On 04/07, Joonyoung Shim wrote:
 Even if use CLK_DIVIDER_READ_ONLY flag, divider setting can be changed
 by set_rate callback. Don't change divider setting from set_rate
 callback of divider with CLK_DIVIDER_READ_ONLY flag.

 Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
 ---
 
 Is the rate actually changing? Or is it just a problem that we
 may be writing the register to the same value it already is?
 

If rate and parant_rate are different, it can write the register to
different value. Even if the value is same but i think it's unnecessary
to re-write the register.

Thanks.
--
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/2] clk: divider: fix to set parent rate from CLK_DIVIDER_READ_ONLY flag

[Joonyoung Shim]

Hi Michael,

On 05/13/2015 08:57 AM, Stephen Boyd wrote:
 On 05/12, Michael Turquette wrote:
 Quoting Joonyoung Shim (2015-04-07 00:46:46)
 The round_rate callback function will returns alway same parent clk rate
 of divider with CLK_DIVIDER_READ_ONLY flag. If be used
 CLK_SET_RATE_PARENT flag with CLK_DIVIDER_READ_ONLY flag, then never
 change parent clk rate anymore.

 From this case, this patch allows to change parent clk rate.

 Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
 ---
  drivers/clk/clk-divider.c | 5 +
  1 file changed, 5 insertions(+)

 diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
 index ce34d29a..37e285e 100644
 --- a/drivers/clk/clk-divider.c
 +++ b/drivers/clk/clk-divider.c
 @@ -352,6 +352,11 @@ static long clk_divider_round_rate(struct clk_hw *hw, 
 unsigned long rate,
 bestdiv = readl(divider-reg)  divider-shift;
 bestdiv = div_mask(divider-width);
 bestdiv = _get_div(divider-table, bestdiv, divider-flags);
 +
 +   if ((__clk_get_flags(hw-clk)  CLK_SET_RATE_PARENT))
 +   *prate = __clk_round_rate(__clk_get_parent(hw-clk),
 + rate);
 +
 return DIV_ROUND_UP(*prate, bestdiv);
 }
  
 -- 
 1.9.1


 Hello Joonyoung Shim,

 Thanks for reporting the bug and providing a fix!

 I've come up with an alternative solution to this. This patch should
 replace both of your patches. Can you test this and see if it fixes the
 problem for you?


Yes, it works.

 Thanks,
 Mike



 From 655dddad2700a30aaa397cd804422e0d9195efad Mon Sep 17 00:00:00 2001
 From: Michael Turquette mturque...@linaro.org
 Date: Tue, 12 May 2015 16:13:46 -0700
 Subject: [PATCH] clk: divider: support read-only dividers

 An arbitrary clock rate divider may be set out of reset, or perhaps by
 the bootloader or something other than Linux. In these cases we may want
 to know the frequency of the clock signal, but we do not want to allow
 Linux to change it.

 The CLK_DIVIDER_READ_ONLY flag was intended to express this, but the
 functionality was missing in the code. Add read-only clk_ops for divider
 clocks to handle this case.

 For hardware with fixed dividers it is still best to use the
 fixed-factor clock type.

 Reported-by: Joonyoung Shim jy0922.s...@samsung.com
 Signed-off-by: Michael Turquette mturque...@linaro.org
 ---
  drivers/clk/clk-divider.c | 10 +-
  1 file changed, 9 insertions(+), 1 deletion(-)

 diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
 index 25006a8..5d2de26 100644
 --- a/drivers/clk/clk-divider.c
 +++ b/drivers/clk/clk-divider.c
 @@ -412,6 +412,11 @@ const struct clk_ops clk_divider_ops = {
  };
  EXPORT_SYMBOL_GPL(clk_divider_ops);
  
 +const struct clk_ops clk_divider_ro_ops = {
 +.recalc_rate = clk_divider_recalc_rate,
 +};
 +EXPORT_SYMBOL_GPL(clk_divider_ro_ops);
 +
  static struct clk *_register_divider(struct device *dev, const char *name,
  const char *parent_name, unsigned long flags,
  void __iomem *reg, u8 shift, u8 width,
 @@ -437,7 +442,10 @@ static struct clk *_register_divider(struct device 
 *dev, const char *name,
  }
  
  init.name = name;
 -init.ops = clk_divider_ops;
 +if (clk_divider_flags  CLK_DIVIDER_READ_ONLY)
 +init.ops = clk_divider_ro_ops;
 +else
 +init.ops = clk_divider_ops;
  init.flags = flags | CLK_IS_BASIC;
  init.parent_names = (parent_name ? parent_name: NULL);
  init.num_parents = (parent_name ? 1 : 0);
 -- 
 
 Isn't this sort of reverting commit e6d5e7d90be9 (clk-divider:
 Fix READ_ONLY when divider  1, 2014-11-14)? 
 

So i had abandoned to retry commit e6d5e7d90be9.

Thanks.
--
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 2/2] clk: divider: fix to set parent rate from CLK_DIVIDER_READ_ONLY flag

[Joonyoung Shim]

The round_rate callback function will returns alway same parent clk rate
of divider with CLK_DIVIDER_READ_ONLY flag. If be used
CLK_SET_RATE_PARENT flag with CLK_DIVIDER_READ_ONLY flag, then never
change parent clk rate anymore.

>From this case, this patch allows to change parent clk rate.

Signed-off-by: Joonyoung Shim 
---
 drivers/clk/clk-divider.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index ce34d29a..37e285e 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -352,6 +352,11 @@ static long clk_divider_round_rate(struct clk_hw *hw, 
unsigned long rate,
bestdiv = readl(divider->reg) >> divider->shift;
bestdiv &= div_mask(divider->width);
bestdiv = _get_div(divider->table, bestdiv, divider->flags);
+
+   if ((__clk_get_flags(hw->clk) & CLK_SET_RATE_PARENT))
+   *prate = __clk_round_rate(__clk_get_parent(hw->clk),
+ rate);
+
return DIV_ROUND_UP(*prate, bestdiv);
}
 
-- 
1.9.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/

[PATCH 1/2] clk: divider: don't set_rate with CLK_DIVIDER_READ_ONLY flag

[Joonyoung Shim]

Even if use CLK_DIVIDER_READ_ONLY flag, divider setting can be changed
by set_rate callback. Don't change divider setting from set_rate
callback of divider with CLK_DIVIDER_READ_ONLY flag.

Signed-off-by: Joonyoung Shim 
---
 drivers/clk/clk-divider.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index 25006a8..ce34d29a 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -384,6 +384,9 @@ static int clk_divider_set_rate(struct clk_hw *hw, unsigned 
long rate,
unsigned long flags = 0;
u32 val;
 
+   if (divider->flags & CLK_DIVIDER_READ_ONLY)
+   return 0;
+
value = divider_get_val(rate, parent_rate, divider->table,
divider->width, divider->flags);
 
-- 
1.9.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/

[PATCH 2/2] clk: divider: fix to set parent rate from CLK_DIVIDER_READ_ONLY flag

[Joonyoung Shim]

The round_rate callback function will returns alway same parent clk rate
of divider with CLK_DIVIDER_READ_ONLY flag. If be used
CLK_SET_RATE_PARENT flag with CLK_DIVIDER_READ_ONLY flag, then never
change parent clk rate anymore.

From this case, this patch allows to change parent clk rate.

Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
---
 drivers/clk/clk-divider.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index ce34d29a..37e285e 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -352,6 +352,11 @@ static long clk_divider_round_rate(struct clk_hw *hw, 
unsigned long rate,
bestdiv = readl(divider-reg)  divider-shift;
bestdiv = div_mask(divider-width);
bestdiv = _get_div(divider-table, bestdiv, divider-flags);
+
+   if ((__clk_get_flags(hw-clk)  CLK_SET_RATE_PARENT))
+   *prate = __clk_round_rate(__clk_get_parent(hw-clk),
+ rate);
+
return DIV_ROUND_UP(*prate, bestdiv);
}
 
-- 
1.9.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/

[PATCH 1/2] clk: divider: don't set_rate with CLK_DIVIDER_READ_ONLY flag

[Joonyoung Shim]

Even if use CLK_DIVIDER_READ_ONLY flag, divider setting can be changed
by set_rate callback. Don't change divider setting from set_rate
callback of divider with CLK_DIVIDER_READ_ONLY flag.

Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
---
 drivers/clk/clk-divider.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index 25006a8..ce34d29a 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -384,6 +384,9 @@ static int clk_divider_set_rate(struct clk_hw *hw, unsigned 
long rate,
unsigned long flags = 0;
u32 val;
 
+   if (divider-flags  CLK_DIVIDER_READ_ONLY)
+   return 0;
+
value = divider_get_val(rate, parent_rate, divider-table,
divider-width, divider-flags);
 
-- 
1.9.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/

Re: [RFC PATCH 0/3] Fix power domains handling on exynos542x

[Joonyoung Shim]

Hi,

On 02/05/2015 11:45 PM, Javier Martinez Canillas wrote:
> Hello Andrzej,
> 
> Thanks a lot for finally finding what was causing the HDMI issue.
> 
> On 02/05/2015 01:35 PM, Andrzej Hajda wrote:
>> Hi,
>>
>> Exynos chipsets since 542x have asynchronous bridges connecting different 
>> IPs.
>> These bridges should be operational during power domain switching, ie 
>> associated
>> clocks cannot be gated.
>> This patchset adds binding to provide such clocks per power domain and adds 
>> code
>> which enables them during domain on/off operation.
>>
>> This patchset fixes power domain issues with disp1 domain and HDMI (some of 
>> them)
>> on Odroid XU3:
>> - disp1 power domain can be turned off,
>> - no more "imprecise external abort" faults.
>>
>> The patchset is based on '[PATCH v5 0/9] Enable HDMI support on Exynos 
>> platforms' [1].
>>
> 
> It also depends on '[PATCH 0/2] Add HDMI support for Exynos5420 platform' [2].
> 
>> It was successfully tested on OdroidXU3.
>>
>> [1]: http://permalink.gmane.org/gmane.linux.kernel.samsung-soc/42743
> 
> Your patches looks good to me so please feel free to add:
> 
> Reviewed-by: Javier Martinez Canillas 
> 
> I also tested on an Exynos5420 Peach Pit Chromebook and both the "Power
> domain power-domain disable failed" message and the system crash are gone.
> 

Really gone out "Power domain power-domain disable failed" message?

Still i get the message from second try,

# modetest -M exynos -s 23@21:1920x1080
setting mode 1920x1080@XR24 on connectors 23, crtc 21

# modetest -M exynos -s 23@21:1920x1080
setting mode 1920x1080@XR24 on connectors 23, crtc 21

[   39.608881] Power domain power-domain disable failed
# modetest -M exynos -s 23@21:1920x1080
setting mode 1920x1080@XR24 on connectors 23, crtc 21

[   42.827637] Power domain power-domain disable failed
...

Thanks.

> Tested-by: Javier Martinez Canillas 
> 
> Best regards,
> Javier
> 
> [2]: https://lkml.org/lkml/2015/1/20/235
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

--
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] GPU-DRM-Exynos: Delete unnecessary checks before two function calls

[Joonyoung Shim]

Hi,

On 02/05/2015 06:00 AM, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Wed, 4 Feb 2015 21:54:45 +0100
> 
> The functions phy_power_on() and vunmap() perform also input
> parameter validation. Thus the test around their calls is not needed.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 
> ---
>  drivers/gpu/drm/exynos/exynos_dp_core.c   | 6 ++
>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 2 +-
>  2 files changed, 3 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
> b/drivers/gpu/drm/exynos/exynos_dp_core.c
> index 34d46aa..306cf1d 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
> @@ -1057,14 +1057,12 @@ static int exynos_dp_create_connector(struct 
> exynos_drm_display *display,
>  
>  static void exynos_dp_phy_init(struct exynos_dp_device *dp)
>  {
> - if (dp->phy)
> - phy_power_on(dp->phy);
> + phy_power_on(dp->phy);
>  }
>  
>  static void exynos_dp_phy_exit(struct exynos_dp_device *dp)
>  {
> - if (dp->phy)
> - phy_power_off(dp->phy);
> + phy_power_off(dp->phy);
>  }
>  
>  static void exynos_dp_poweron(struct exynos_drm_display *display)
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> index e12ea90..0dd448a 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> @@ -313,7 +313,7 @@ static void exynos_drm_fbdev_destroy(struct drm_device 
> *dev,
>   struct exynos_drm_gem_obj *exynos_gem_obj = exynos_fbd->exynos_gem_obj;
>   struct drm_framebuffer *fb;
>  
> - if (is_drm_iommu_supported(dev) && exynos_gem_obj->buffer->kvaddr)
> + if (is_drm_iommu_supported(dev))
>   vunmap(exynos_gem_obj->buffer->kvaddr);
>  
>   /* release drm framebuffer and real buffer */
> 

Acked-by: Joonyoung Shim 

Thanks.
--
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] GPU-DRM-Exynos: Delete unnecessary checks before two function calls

[Joonyoung Shim]

Hi,

On 02/05/2015 06:00 AM, SF Markus Elfring wrote:
 From: Markus Elfring elfr...@users.sourceforge.net
 Date: Wed, 4 Feb 2015 21:54:45 +0100
 
 The functions phy_power_on() and vunmap() perform also input
 parameter validation. Thus the test around their calls is not needed.
 
 This issue was detected by using the Coccinelle software.
 
 Signed-off-by: Markus Elfring elfr...@users.sourceforge.net
 ---
  drivers/gpu/drm/exynos/exynos_dp_core.c   | 6 ++
  drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 2 +-
  2 files changed, 3 insertions(+), 5 deletions(-)
 
 diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
 b/drivers/gpu/drm/exynos/exynos_dp_core.c
 index 34d46aa..306cf1d 100644
 --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
 +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
 @@ -1057,14 +1057,12 @@ static int exynos_dp_create_connector(struct 
 exynos_drm_display *display,
  
  static void exynos_dp_phy_init(struct exynos_dp_device *dp)
  {
 - if (dp-phy)
 - phy_power_on(dp-phy);
 + phy_power_on(dp-phy);
  }
  
  static void exynos_dp_phy_exit(struct exynos_dp_device *dp)
  {
 - if (dp-phy)
 - phy_power_off(dp-phy);
 + phy_power_off(dp-phy);
  }
  
  static void exynos_dp_poweron(struct exynos_drm_display *display)
 diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
 b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
 index e12ea90..0dd448a 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
 @@ -313,7 +313,7 @@ static void exynos_drm_fbdev_destroy(struct drm_device 
 *dev,
   struct exynos_drm_gem_obj *exynos_gem_obj = exynos_fbd-exynos_gem_obj;
   struct drm_framebuffer *fb;
  
 - if (is_drm_iommu_supported(dev)  exynos_gem_obj-buffer-kvaddr)
 + if (is_drm_iommu_supported(dev))
   vunmap(exynos_gem_obj-buffer-kvaddr);
  
   /* release drm framebuffer and real buffer */
 

Acked-by: Joonyoung Shim jy0922.s...@samsung.com

Thanks.
--
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 0/3] Fix power domains handling on exynos542x

[Joonyoung Shim]

Hi,

On 02/05/2015 11:45 PM, Javier Martinez Canillas wrote:
 Hello Andrzej,
 
 Thanks a lot for finally finding what was causing the HDMI issue.
 
 On 02/05/2015 01:35 PM, Andrzej Hajda wrote:
 Hi,

 Exynos chipsets since 542x have asynchronous bridges connecting different 
 IPs.
 These bridges should be operational during power domain switching, ie 
 associated
 clocks cannot be gated.
 This patchset adds binding to provide such clocks per power domain and adds 
 code
 which enables them during domain on/off operation.

 This patchset fixes power domain issues with disp1 domain and HDMI (some of 
 them)
 on Odroid XU3:
 - disp1 power domain can be turned off,
 - no more imprecise external abort faults.

 The patchset is based on '[PATCH v5 0/9] Enable HDMI support on Exynos 
 platforms' [1].

 
 It also depends on '[PATCH 0/2] Add HDMI support for Exynos5420 platform' [2].
 
 It was successfully tested on OdroidXU3.

 [1]: http://permalink.gmane.org/gmane.linux.kernel.samsung-soc/42743
 
 Your patches looks good to me so please feel free to add:
 
 Reviewed-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 
 I also tested on an Exynos5420 Peach Pit Chromebook and both the Power
 domain power-domain disable failed message and the system crash are gone.
 

Really gone out Power domain power-domain disable failed message?

Still i get the message from second try,

# modetest -M exynos -s 23@21:1920x1080
setting mode 1920x1080@XR24 on connectors 23, crtc 21

# modetest -M exynos -s 23@21:1920x1080
setting mode 1920x1080@XR24 on connectors 23, crtc 21

[   39.608881] Power domain power-domain disable failed
# modetest -M exynos -s 23@21:1920x1080
setting mode 1920x1080@XR24 on connectors 23, crtc 21

[   42.827637] Power domain power-domain disable failed
...

Thanks.

 Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 
 Best regards,
 Javier
 
 [2]: https://lkml.org/lkml/2015/1/20/235
 --
 To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 
 in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 

--
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] ARM: dts: exynos5422-odroidxu3: add on-board INA231 sensors

[Joonyoung Shim]

Hi Kevin,

On 01/15/2015 10:08 AM, Kevin Hilman wrote:
> From: Kevin Hilman 
> 
> The odroid-xu3 has 4 INA231 current sensors on board which can be
> accessed from the Linux via the hwmon interface.
> 
> There is one sensor for each of these power rails:
> 
> - A15 cluster: VDD_ARM
> - A7 cluster: VDD_KFC
> - GPU: VDD_G3D
> - memory: VDD_MEM
> 
> In addition to adding the sensors, LDO26 from the PMIC needs to be
> enabled because it's powering these sensor.
> 
> Cc: Javier Martinez Canillas 
> Cc: Sjoerd Simons 
> Signed-off-by: Kevin Hilman 
> ---
> v2: use "ti,ina231" as compatible string.
> 
> Applies on top of "ARM: dts: Add dts file for odroid XU3 board" from Sjoerd 
> Simons.
> 
>  arch/arm/boot/dts/exynos5422-odroidxu3.dts | 39 
> ++
>  1 file changed, 39 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts 
> b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> index c29123c0734d..50353d023225 100644
> --- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> @@ -174,6 +174,13 @@
>   regulator-always-on;
>   };
>  
> + ldo26_reg: LDO26 {
> + regulator-name = "vdd_ldo26";
> + regulator-min-microvolt = <300>;
> + regulator-max-microvolt = <300>;
> + regulator-always-on;
> + };
> +
>   buck1_reg: BUCK1 {
>   regulator-name = "vdd_mif";
>   regulator-min-microvolt = <80>;
> @@ -257,6 +264,38 @@
>   };
>   };
>  
> + i2c_0: i2c@12C6 {

It's ok but IMHO it can split using label reference, e.g. 

_0 {
...
};

Thanks.

> + status = "okay";
> +
> + /* A15 cluster: VDD_ARM */
> + ina231@40 {
> + compatible = "ti,ina231";
> + reg = <0x40>;
> + shunt-resistor = <1>;
> + };
> +
> + /* memory: VDD_MEM */
> + ina231@41 {
> + compatible = "ti,ina231";
> + reg = <0x41>;
> + shunt-resistor = <1>;
> + };
> +
> + /* GPU: VDD_G3D */
> + ina231@44 {
> + compatible = "ti,ina231";
> + reg = <0x44>;
> + shunt-resistor = <1>;
> + };
> +
> + /* A7 cluster: VDD_KFC */
> + ina231@45 {
> + compatible = "ti,ina231";
> + reg = <0x45>;
> + shunt-resistor = <1>;
> + };
> + };
> +
>   i2c_2: i2c@12C8 {
>   samsung,i2c-sda-delay = <100>;
>   samsung,i2c-max-bus-freq = <66000>;
> 

--
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] ARM: dts: exynos5422-odroidxu3: add on-board INA231 sensors

[Joonyoung Shim]

Hi Kevin,

On 01/15/2015 10:08 AM, Kevin Hilman wrote:
 From: Kevin Hilman khil...@linaro.org
 
 The odroid-xu3 has 4 INA231 current sensors on board which can be
 accessed from the Linux via the hwmon interface.
 
 There is one sensor for each of these power rails:
 
 - A15 cluster: VDD_ARM
 - A7 cluster: VDD_KFC
 - GPU: VDD_G3D
 - memory: VDD_MEM
 
 In addition to adding the sensors, LDO26 from the PMIC needs to be
 enabled because it's powering these sensor.
 
 Cc: Javier Martinez Canillas javier.marti...@collabora.co.uk
 Cc: Sjoerd Simons sjoerd.sim...@collabora.co.uk
 Signed-off-by: Kevin Hilman khil...@linaro.org
 ---
 v2: use ti,ina231 as compatible string.
 
 Applies on top of ARM: dts: Add dts file for odroid XU3 board from Sjoerd 
 Simons.
 
  arch/arm/boot/dts/exynos5422-odroidxu3.dts | 39 
 ++
  1 file changed, 39 insertions(+)
 
 diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts 
 b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
 index c29123c0734d..50353d023225 100644
 --- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
 +++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
 @@ -174,6 +174,13 @@
   regulator-always-on;
   };
  
 + ldo26_reg: LDO26 {
 + regulator-name = vdd_ldo26;
 + regulator-min-microvolt = 300;
 + regulator-max-microvolt = 300;
 + regulator-always-on;
 + };
 +
   buck1_reg: BUCK1 {
   regulator-name = vdd_mif;
   regulator-min-microvolt = 80;
 @@ -257,6 +264,38 @@
   };
   };
  
 + i2c_0: i2c@12C6 {

It's ok but IMHO it can split using label reference, e.g. 

i2c_0 {
...
};

Thanks.

 + status = okay;
 +
 + /* A15 cluster: VDD_ARM */
 + ina231@40 {
 + compatible = ti,ina231;
 + reg = 0x40;
 + shunt-resistor = 1;
 + };
 +
 + /* memory: VDD_MEM */
 + ina231@41 {
 + compatible = ti,ina231;
 + reg = 0x41;
 + shunt-resistor = 1;
 + };
 +
 + /* GPU: VDD_G3D */
 + ina231@44 {
 + compatible = ti,ina231;
 + reg = 0x44;
 + shunt-resistor = 1;
 + };
 +
 + /* A7 cluster: VDD_KFC */
 + ina231@45 {
 + compatible = ti,ina231;
 + reg = 0x45;
 + shunt-resistor = 1;
 + };
 + };
 +
   i2c_2: i2c@12C8 {
   samsung,i2c-sda-delay = 100;
   samsung,i2c-max-bus-freq = 66000;
 

--
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] drm/exynos: fix vblank handling during dpms off

[Joonyoung Shim]

Hi Andrzej,

On 10/01/2014 05:14 PM, Andrzej Hajda wrote:
> The patch disables vblanks during dpms off only if pagefilp has
> not been finished. It also replaces drm_vblank_off with drm_crtc_vblank_put.
> It fixes issue with page_flip ioctl not being able to acquire vblank counter.

This problem isn't related with pageflip, it just causes from
7ffd7a68511c710b84db3548a1997fd2625f580a commit (drm: Always reject
drm_vblank_get() after drm_vblank_off()).

We need to use drm_vblank_on() as a counterpart to drm_vblank_off()
after the commit .

How about below patch?

>From 6de01473746af225c688ee430123001d57d9af2a Mon Sep 17 00:00:00 2001
From: Joonyoung Shim 
Date: Thu, 2 Oct 2014 17:48:27 +0900
Subject: [PATCH] drm/exynos: use drm_vblank_on()

We need to use drm_vblank_on() as a counterpart to drm_vblank_off()
after the commit 7ffd7a68511c ("drm: Always reject drm_vblank_get()
after drm_vblank_off()"). If not, drm_vblank_get() will be failed
always after drm_vblank_off().

Signed-off-by: Joonyoung Shim 
---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 8e38e9f..dfa209a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -71,7 +71,6 @@ static void exynos_drm_crtc_dpms(struct drm_crtc *crtc, int 
mode)
!atomic_read(_crtc->pending_flip),
HZ/20))
atomic_set(_crtc->pending_flip, 0);
-   drm_vblank_off(crtc->dev, exynos_crtc->pipe);
}
 
if (manager->ops->dpms)
@@ -90,6 +89,7 @@ static void exynos_drm_crtc_commit(struct drm_crtc *crtc)
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
struct exynos_drm_manager *manager = exynos_crtc->manager;
 
+   drm_vblank_on(crtc->dev, exynos_crtc->pipe);
exynos_drm_crtc_dpms(crtc, DRM_MODE_DPMS_ON);
 
exynos_plane_commit(crtc->primary);
@@ -177,10 +177,12 @@ static int exynos_drm_crtc_mode_set_base(struct drm_crtc 
*crtc, int x, int y,
 
 static void exynos_drm_crtc_disable(struct drm_crtc *crtc)
 {
+   struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
struct drm_plane *plane;
int ret;
 
exynos_drm_crtc_dpms(crtc, DRM_MODE_DPMS_OFF);
+   drm_vblank_off(crtc->dev, exynos_crtc->pipe);
 
drm_for_each_legacy_plane(plane, >dev->mode_config.plane_list) {
if (plane->crtc != crtc)
-- 
1.9.1

Thanks.

> 
> Signed-off-by: Andrzej Hajda 
> ---
> Hi Inki,
> 
> This is fix (or just workaround) of the problem you have reported.
> Please carefully verify it, as I am not familiar with pageflip code.
> 
> Regards
> Andrzej
> ---
>  drivers/gpu/drm/exynos/exynos_drm_crtc.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
> b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> index 8e38e9f..57fa94d 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> @@ -69,9 +69,10 @@ static void exynos_drm_crtc_dpms(struct drm_crtc *crtc, 
> int mode)
>   /* wait for the completion of page flip. */
>   if (!wait_event_timeout(exynos_crtc->pending_flip_queue,
>   !atomic_read(_crtc->pending_flip),
> - HZ/20))
> + HZ/20)) {
>   atomic_set(_crtc->pending_flip, 0);
> - drm_vblank_off(crtc->dev, exynos_crtc->pipe);
> + drm_crtc_vblank_put(crtc);
> + }
>   }
>  
>   if (manager->ops->dpms)
> 

--
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] drm/exynos: fix vblank handling during dpms off

[Joonyoung Shim]

Hi Andrzej,

On 10/01/2014 05:14 PM, Andrzej Hajda wrote:
 The patch disables vblanks during dpms off only if pagefilp has
 not been finished. It also replaces drm_vblank_off with drm_crtc_vblank_put.
 It fixes issue with page_flip ioctl not being able to acquire vblank counter.

This problem isn't related with pageflip, it just causes from
7ffd7a68511c710b84db3548a1997fd2625f580a commit (drm: Always reject
drm_vblank_get() after drm_vblank_off()).

We need to use drm_vblank_on() as a counterpart to drm_vblank_off()
after the commit .

How about below patch?

From 6de01473746af225c688ee430123001d57d9af2a Mon Sep 17 00:00:00 2001
From: Joonyoung Shim jy0922.s...@samsung.com
Date: Thu, 2 Oct 2014 17:48:27 +0900
Subject: [PATCH] drm/exynos: use drm_vblank_on()

We need to use drm_vblank_on() as a counterpart to drm_vblank_off()
after the commit 7ffd7a68511c (drm: Always reject drm_vblank_get()
after drm_vblank_off()). If not, drm_vblank_get() will be failed
always after drm_vblank_off().

Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 8e38e9f..dfa209a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -71,7 +71,6 @@ static void exynos_drm_crtc_dpms(struct drm_crtc *crtc, int 
mode)
!atomic_read(exynos_crtc-pending_flip),
HZ/20))
atomic_set(exynos_crtc-pending_flip, 0);
-   drm_vblank_off(crtc-dev, exynos_crtc-pipe);
}
 
if (manager-ops-dpms)
@@ -90,6 +89,7 @@ static void exynos_drm_crtc_commit(struct drm_crtc *crtc)
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
struct exynos_drm_manager *manager = exynos_crtc-manager;
 
+   drm_vblank_on(crtc-dev, exynos_crtc-pipe);
exynos_drm_crtc_dpms(crtc, DRM_MODE_DPMS_ON);
 
exynos_plane_commit(crtc-primary);
@@ -177,10 +177,12 @@ static int exynos_drm_crtc_mode_set_base(struct drm_crtc 
*crtc, int x, int y,
 
 static void exynos_drm_crtc_disable(struct drm_crtc *crtc)
 {
+   struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
struct drm_plane *plane;
int ret;
 
exynos_drm_crtc_dpms(crtc, DRM_MODE_DPMS_OFF);
+   drm_vblank_off(crtc-dev, exynos_crtc-pipe);
 
drm_for_each_legacy_plane(plane, crtc-dev-mode_config.plane_list) {
if (plane-crtc != crtc)
-- 
1.9.1

Thanks.

 
 Signed-off-by: Andrzej Hajda a.ha...@samsung.com
 ---
 Hi Inki,
 
 This is fix (or just workaround) of the problem you have reported.
 Please carefully verify it, as I am not familiar with pageflip code.
 
 Regards
 Andrzej
 ---
  drivers/gpu/drm/exynos/exynos_drm_crtc.c | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
 b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
 index 8e38e9f..57fa94d 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
 @@ -69,9 +69,10 @@ static void exynos_drm_crtc_dpms(struct drm_crtc *crtc, 
 int mode)
   /* wait for the completion of page flip. */
   if (!wait_event_timeout(exynos_crtc-pending_flip_queue,
   !atomic_read(exynos_crtc-pending_flip),
 - HZ/20))
 + HZ/20)) {
   atomic_set(exynos_crtc-pending_flip, 0);
 - drm_vblank_off(crtc-dev, exynos_crtc-pipe);
 + drm_crtc_vblank_put(crtc);
 + }
   }
  
   if (manager-ops-dpms)
 

--
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] drm/exynos: switch to universal plane API

[Joonyoung Shim]

Hi,

On 09/19/2014 08:11 PM, Joonyoung Shim wrote:
> Hi,
> 
> On 09/19/2014 07:54 PM, Andrzej Hajda wrote:
>> On 09/19/2014 03:02 AM, Joonyoung Shim wrote:
>>> Hi Andrzej,
>>>
>>> On 09/18/2014 10:17 PM, Andrzej Hajda wrote:
>>>> The patch replaces legacy functions
>>>> drm_plane_init() / drm_crtc_init() with
>>>> drm_universal_plane_init() and drm_crtc_init_with_planes().
>>>> It allows to replace fake primary plane with the real one.
>>>>
>>>> Signed-off-by: Andrzej Hajda 
>>>> ---
>>>> Hi Inki,
>>>>
>>>> I have tested this patch with trats board, it looks OK.
>>>> As a side effect it should solve fb refcounting issues
>>>> reported by me and Daniel Drake.
>>>>
>>>> Regards
>>>> Andrzej
>>>> ---
>>>>  drivers/gpu/drm/exynos/exynos_drm_crtc.c  | 63 
>>>> ---
>>>>  drivers/gpu/drm/exynos/exynos_drm_drv.c   |  5 ++-
>>>>  drivers/gpu/drm/exynos/exynos_drm_plane.c | 17 +
>>>>  drivers/gpu/drm/exynos/exynos_drm_plane.h |  3 +-
>>>>  4 files changed, 47 insertions(+), 41 deletions(-)
>>>>
>>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
>>>> b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>>>> index b68e58f..d2f713e 100644
>>>> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>>>> @@ -32,7 +32,6 @@ enum exynos_crtc_mode {
>>>>   * Exynos specific crtc structure.
>>>>   *
>>>>   * @drm_crtc: crtc object.
>>>> - * @drm_plane: pointer of private plane object for this crtc
>>>>   * @manager: the manager associated with this crtc
>>>>   * @pipe: a crtc index created at load() with a new crtc object creation
>>>>   *and the crtc object would be set to private->crtc array
>>>> @@ -46,7 +45,6 @@ enum exynos_crtc_mode {
>>>>   */
>>>>  struct exynos_drm_crtc {
>>>>struct drm_crtc drm_crtc;
>>>> -  struct drm_plane*plane;
>>>>struct exynos_drm_manager   *manager;
>>>>unsigned intpipe;
>>>>unsigned intdpms;
>>>> @@ -94,12 +92,12 @@ static void exynos_drm_crtc_commit(struct drm_crtc 
>>>> *crtc)
>>>>  
>>>>exynos_drm_crtc_dpms(crtc, DRM_MODE_DPMS_ON);
>>>>  
>>>> -  exynos_plane_commit(exynos_crtc->plane);
>>>> +  exynos_plane_commit(crtc->primary);
>>>>  
>>>>if (manager->ops->commit)
>>>>manager->ops->commit(manager);
>>>>  
>>>> -  exynos_plane_dpms(exynos_crtc->plane, DRM_MODE_DPMS_ON);
>>>> +  exynos_plane_dpms(crtc->primary, DRM_MODE_DPMS_ON);
>>>>  }
>>>>  
>>>>  static bool
>>>> @@ -123,10 +121,9 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, 
>>>> struct drm_display_mode *mode,
>>>>  {
>>>>struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
>>>>struct exynos_drm_manager *manager = exynos_crtc->manager;
>>>> -  struct drm_plane *plane = exynos_crtc->plane;
>>>> +  struct drm_framebuffer *fb = crtc->primary->fb;
>>>>unsigned int crtc_w;
>>>>unsigned int crtc_h;
>>>> -  int ret;
>>>>  
>>>>/*
>>>> * copy the mode data adjusted by mode_fixup() into crtc->mode
>>>> @@ -134,29 +131,21 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, 
>>>> struct drm_display_mode *mode,
>>>> */
>>>>memcpy(>mode, adjusted_mode, sizeof(*adjusted_mode));
>>>>  
>>>> -  crtc_w = crtc->primary->fb->width - x;
>>>> -  crtc_h = crtc->primary->fb->height - y;
>>>> +  crtc_w = fb->width - x;
>>>> +  crtc_h = fb->height - y;
>>>>  
>>>>if (manager->ops->mode_set)
>>>>manager->ops->mode_set(manager, >mode);
>>>>  
>>>> -  ret = exynos_plane_mode_set(plane, crtc, crtc->primary->fb, 0, 0, 
>>>> crtc_w, crtc_h,
>>>> -  x, y, crtc_w, crtc_h);
>>>> -  if (ret)
>>>> -  return ret;
>>>> -
>>>> -  plane->crtc =

Re: [PATCH] drm/exynos: switch to universal plane API

[Joonyoung Shim]

Hi,

On 09/19/2014 07:54 PM, Andrzej Hajda wrote:
> On 09/19/2014 03:02 AM, Joonyoung Shim wrote:
>> Hi Andrzej,
>>
>> On 09/18/2014 10:17 PM, Andrzej Hajda wrote:
>>> The patch replaces legacy functions
>>> drm_plane_init() / drm_crtc_init() with
>>> drm_universal_plane_init() and drm_crtc_init_with_planes().
>>> It allows to replace fake primary plane with the real one.
>>>
>>> Signed-off-by: Andrzej Hajda 
>>> ---
>>> Hi Inki,
>>>
>>> I have tested this patch with trats board, it looks OK.
>>> As a side effect it should solve fb refcounting issues
>>> reported by me and Daniel Drake.
>>>
>>> Regards
>>> Andrzej
>>> ---
>>>  drivers/gpu/drm/exynos/exynos_drm_crtc.c  | 63 
>>> ---
>>>  drivers/gpu/drm/exynos/exynos_drm_drv.c   |  5 ++-
>>>  drivers/gpu/drm/exynos/exynos_drm_plane.c | 17 +
>>>  drivers/gpu/drm/exynos/exynos_drm_plane.h |  3 +-
>>>  4 files changed, 47 insertions(+), 41 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
>>> b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>>> index b68e58f..d2f713e 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
>>> @@ -32,7 +32,6 @@ enum exynos_crtc_mode {
>>>   * Exynos specific crtc structure.
>>>   *
>>>   * @drm_crtc: crtc object.
>>> - * @drm_plane: pointer of private plane object for this crtc
>>>   * @manager: the manager associated with this crtc
>>>   * @pipe: a crtc index created at load() with a new crtc object creation
>>>   * and the crtc object would be set to private->crtc array
>>> @@ -46,7 +45,6 @@ enum exynos_crtc_mode {
>>>   */
>>>  struct exynos_drm_crtc {
>>> struct drm_crtc drm_crtc;
>>> -   struct drm_plane*plane;
>>> struct exynos_drm_manager   *manager;
>>> unsigned intpipe;
>>> unsigned intdpms;
>>> @@ -94,12 +92,12 @@ static void exynos_drm_crtc_commit(struct drm_crtc 
>>> *crtc)
>>>  
>>> exynos_drm_crtc_dpms(crtc, DRM_MODE_DPMS_ON);
>>>  
>>> -   exynos_plane_commit(exynos_crtc->plane);
>>> +   exynos_plane_commit(crtc->primary);
>>>  
>>> if (manager->ops->commit)
>>> manager->ops->commit(manager);
>>>  
>>> -   exynos_plane_dpms(exynos_crtc->plane, DRM_MODE_DPMS_ON);
>>> +   exynos_plane_dpms(crtc->primary, DRM_MODE_DPMS_ON);
>>>  }
>>>  
>>>  static bool
>>> @@ -123,10 +121,9 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, struct 
>>> drm_display_mode *mode,
>>>  {
>>> struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
>>> struct exynos_drm_manager *manager = exynos_crtc->manager;
>>> -   struct drm_plane *plane = exynos_crtc->plane;
>>> +   struct drm_framebuffer *fb = crtc->primary->fb;
>>> unsigned int crtc_w;
>>> unsigned int crtc_h;
>>> -   int ret;
>>>  
>>> /*
>>>  * copy the mode data adjusted by mode_fixup() into crtc->mode
>>> @@ -134,29 +131,21 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, 
>>> struct drm_display_mode *mode,
>>>  */
>>> memcpy(>mode, adjusted_mode, sizeof(*adjusted_mode));
>>>  
>>> -   crtc_w = crtc->primary->fb->width - x;
>>> -   crtc_h = crtc->primary->fb->height - y;
>>> +   crtc_w = fb->width - x;
>>> +   crtc_h = fb->height - y;
>>>  
>>> if (manager->ops->mode_set)
>>> manager->ops->mode_set(manager, >mode);
>>>  
>>> -   ret = exynos_plane_mode_set(plane, crtc, crtc->primary->fb, 0, 0, 
>>> crtc_w, crtc_h,
>>> -   x, y, crtc_w, crtc_h);
>>> -   if (ret)
>>> -   return ret;
>>> -
>>> -   plane->crtc = crtc;
>>> -   plane->fb = crtc->primary->fb;
>>> -   drm_framebuffer_reference(plane->fb);
>>> -
>>> -   return 0;
>>> +   return exynos_plane_mode_set(crtc->primary, crtc, fb, 0, 0,
>>> +crtc_w, crtc_h, x, y, crtc_w, crtc_h);
>>>  }
>>>  
>>>  static int exynos_drm_crtc_mode_set_commit(struct drm_crtc *crt

Re: [PATCH] drm/exynos: switch to universal plane API

[Joonyoung Shim]

Hi,

On 09/19/2014 07:54 PM, Andrzej Hajda wrote:
 On 09/19/2014 03:02 AM, Joonyoung Shim wrote:
 Hi Andrzej,

 On 09/18/2014 10:17 PM, Andrzej Hajda wrote:
 The patch replaces legacy functions
 drm_plane_init() / drm_crtc_init() with
 drm_universal_plane_init() and drm_crtc_init_with_planes().
 It allows to replace fake primary plane with the real one.

 Signed-off-by: Andrzej Hajda a.ha...@samsung.com
 ---
 Hi Inki,

 I have tested this patch with trats board, it looks OK.
 As a side effect it should solve fb refcounting issues
 reported by me and Daniel Drake.

 Regards
 Andrzej
 ---
  drivers/gpu/drm/exynos/exynos_drm_crtc.c  | 63 
 ---
  drivers/gpu/drm/exynos/exynos_drm_drv.c   |  5 ++-
  drivers/gpu/drm/exynos/exynos_drm_plane.c | 17 +
  drivers/gpu/drm/exynos/exynos_drm_plane.h |  3 +-
  4 files changed, 47 insertions(+), 41 deletions(-)

 diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
 b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
 index b68e58f..d2f713e 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
 @@ -32,7 +32,6 @@ enum exynos_crtc_mode {
   * Exynos specific crtc structure.
   *
   * @drm_crtc: crtc object.
 - * @drm_plane: pointer of private plane object for this crtc
   * @manager: the manager associated with this crtc
   * @pipe: a crtc index created at load() with a new crtc object creation
   * and the crtc object would be set to private-crtc array
 @@ -46,7 +45,6 @@ enum exynos_crtc_mode {
   */
  struct exynos_drm_crtc {
 struct drm_crtc drm_crtc;
 -   struct drm_plane*plane;
 struct exynos_drm_manager   *manager;
 unsigned intpipe;
 unsigned intdpms;
 @@ -94,12 +92,12 @@ static void exynos_drm_crtc_commit(struct drm_crtc 
 *crtc)
  
 exynos_drm_crtc_dpms(crtc, DRM_MODE_DPMS_ON);
  
 -   exynos_plane_commit(exynos_crtc-plane);
 +   exynos_plane_commit(crtc-primary);
  
 if (manager-ops-commit)
 manager-ops-commit(manager);
  
 -   exynos_plane_dpms(exynos_crtc-plane, DRM_MODE_DPMS_ON);
 +   exynos_plane_dpms(crtc-primary, DRM_MODE_DPMS_ON);
  }
  
  static bool
 @@ -123,10 +121,9 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, struct 
 drm_display_mode *mode,
  {
 struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
 struct exynos_drm_manager *manager = exynos_crtc-manager;
 -   struct drm_plane *plane = exynos_crtc-plane;
 +   struct drm_framebuffer *fb = crtc-primary-fb;
 unsigned int crtc_w;
 unsigned int crtc_h;
 -   int ret;
  
 /*
  * copy the mode data adjusted by mode_fixup() into crtc-mode
 @@ -134,29 +131,21 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, 
 struct drm_display_mode *mode,
  */
 memcpy(crtc-mode, adjusted_mode, sizeof(*adjusted_mode));
  
 -   crtc_w = crtc-primary-fb-width - x;
 -   crtc_h = crtc-primary-fb-height - y;
 +   crtc_w = fb-width - x;
 +   crtc_h = fb-height - y;
  
 if (manager-ops-mode_set)
 manager-ops-mode_set(manager, crtc-mode);
  
 -   ret = exynos_plane_mode_set(plane, crtc, crtc-primary-fb, 0, 0, 
 crtc_w, crtc_h,
 -   x, y, crtc_w, crtc_h);
 -   if (ret)
 -   return ret;
 -
 -   plane-crtc = crtc;
 -   plane-fb = crtc-primary-fb;
 -   drm_framebuffer_reference(plane-fb);
 -
 -   return 0;
 +   return exynos_plane_mode_set(crtc-primary, crtc, fb, 0, 0,
 +crtc_w, crtc_h, x, y, crtc_w, crtc_h);
  }
  
  static int exynos_drm_crtc_mode_set_commit(struct drm_crtc *crtc, int x, 
 int y,
   struct drm_framebuffer *old_fb)
  {
 struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
 -   struct drm_plane *plane = exynos_crtc-plane;
 +   struct drm_framebuffer *fb = crtc-primary-fb;
 unsigned int crtc_w;
 unsigned int crtc_h;
 int ret;
 @@ -167,11 +156,11 @@ static int exynos_drm_crtc_mode_set_commit(struct 
 drm_crtc *crtc, int x, int y,
 return -EPERM;
 }
  
 -   crtc_w = crtc-primary-fb-width - x;
 -   crtc_h = crtc-primary-fb-height - y;
 +   crtc_w = fb-width - x;
 +   crtc_h = fb-height - y;
  
 -   ret = exynos_plane_mode_set(plane, crtc, crtc-primary-fb, 0, 0, 
 crtc_w, crtc_h,
 -   x, y, crtc_w, crtc_h);
 +   ret = exynos_plane_mode_set(crtc-primary, crtc, fb, 0, 0,
 +   crtc_w, crtc_h, x, y, crtc_w, crtc_h);
 if (ret)
 return ret;
  
 @@ -279,6 +268,7 @@ static void exynos_drm_crtc_destroy(struct drm_crtc 
 *crtc)
  
 private-crtc[exynos_crtc-pipe] = NULL;
  
 +   crtc-primary-funcs-destroy(crtc-primary);
 This is unnecessary.
 
 The question is how these object should be destroyed. In current code
 crtc is destroyed in fimd_unbind and it is called before
 drm_mode_config_cleanup
 which destroys all planes.
 In such case primary plane will stay with .crtc

Re: [PATCH] drm/exynos: switch to universal plane API

[Joonyoung Shim]

Hi,

On 09/19/2014 08:11 PM, Joonyoung Shim wrote:
 Hi,
 
 On 09/19/2014 07:54 PM, Andrzej Hajda wrote:
 On 09/19/2014 03:02 AM, Joonyoung Shim wrote:
 Hi Andrzej,

 On 09/18/2014 10:17 PM, Andrzej Hajda wrote:
 The patch replaces legacy functions
 drm_plane_init() / drm_crtc_init() with
 drm_universal_plane_init() and drm_crtc_init_with_planes().
 It allows to replace fake primary plane with the real one.

 Signed-off-by: Andrzej Hajda a.ha...@samsung.com
 ---
 Hi Inki,

 I have tested this patch with trats board, it looks OK.
 As a side effect it should solve fb refcounting issues
 reported by me and Daniel Drake.

 Regards
 Andrzej
 ---
  drivers/gpu/drm/exynos/exynos_drm_crtc.c  | 63 
 ---
  drivers/gpu/drm/exynos/exynos_drm_drv.c   |  5 ++-
  drivers/gpu/drm/exynos/exynos_drm_plane.c | 17 +
  drivers/gpu/drm/exynos/exynos_drm_plane.h |  3 +-
  4 files changed, 47 insertions(+), 41 deletions(-)

 diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
 b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
 index b68e58f..d2f713e 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
 @@ -32,7 +32,6 @@ enum exynos_crtc_mode {
   * Exynos specific crtc structure.
   *
   * @drm_crtc: crtc object.
 - * @drm_plane: pointer of private plane object for this crtc
   * @manager: the manager associated with this crtc
   * @pipe: a crtc index created at load() with a new crtc object creation
   *and the crtc object would be set to private-crtc array
 @@ -46,7 +45,6 @@ enum exynos_crtc_mode {
   */
  struct exynos_drm_crtc {
struct drm_crtc drm_crtc;
 -  struct drm_plane*plane;
struct exynos_drm_manager   *manager;
unsigned intpipe;
unsigned intdpms;
 @@ -94,12 +92,12 @@ static void exynos_drm_crtc_commit(struct drm_crtc 
 *crtc)
  
exynos_drm_crtc_dpms(crtc, DRM_MODE_DPMS_ON);
  
 -  exynos_plane_commit(exynos_crtc-plane);
 +  exynos_plane_commit(crtc-primary);
  
if (manager-ops-commit)
manager-ops-commit(manager);
  
 -  exynos_plane_dpms(exynos_crtc-plane, DRM_MODE_DPMS_ON);
 +  exynos_plane_dpms(crtc-primary, DRM_MODE_DPMS_ON);
  }
  
  static bool
 @@ -123,10 +121,9 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, 
 struct drm_display_mode *mode,
  {
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
struct exynos_drm_manager *manager = exynos_crtc-manager;
 -  struct drm_plane *plane = exynos_crtc-plane;
 +  struct drm_framebuffer *fb = crtc-primary-fb;
unsigned int crtc_w;
unsigned int crtc_h;
 -  int ret;
  
/*
 * copy the mode data adjusted by mode_fixup() into crtc-mode
 @@ -134,29 +131,21 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, 
 struct drm_display_mode *mode,
 */
memcpy(crtc-mode, adjusted_mode, sizeof(*adjusted_mode));
  
 -  crtc_w = crtc-primary-fb-width - x;
 -  crtc_h = crtc-primary-fb-height - y;
 +  crtc_w = fb-width - x;
 +  crtc_h = fb-height - y;
  
if (manager-ops-mode_set)
manager-ops-mode_set(manager, crtc-mode);
  
 -  ret = exynos_plane_mode_set(plane, crtc, crtc-primary-fb, 0, 0, 
 crtc_w, crtc_h,
 -  x, y, crtc_w, crtc_h);
 -  if (ret)
 -  return ret;
 -
 -  plane-crtc = crtc;
 -  plane-fb = crtc-primary-fb;
 -  drm_framebuffer_reference(plane-fb);
 -
 -  return 0;
 +  return exynos_plane_mode_set(crtc-primary, crtc, fb, 0, 0,
 +   crtc_w, crtc_h, x, y, crtc_w, crtc_h);
  }
  
  static int exynos_drm_crtc_mode_set_commit(struct drm_crtc *crtc, int x, 
 int y,
  struct drm_framebuffer *old_fb)
  {
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
 -  struct drm_plane *plane = exynos_crtc-plane;
 +  struct drm_framebuffer *fb = crtc-primary-fb;
unsigned int crtc_w;
unsigned int crtc_h;
int ret;
 @@ -167,11 +156,11 @@ static int exynos_drm_crtc_mode_set_commit(struct 
 drm_crtc *crtc, int x, int y,
return -EPERM;
}
  
 -  crtc_w = crtc-primary-fb-width - x;
 -  crtc_h = crtc-primary-fb-height - y;
 +  crtc_w = fb-width - x;
 +  crtc_h = fb-height - y;
  
 -  ret = exynos_plane_mode_set(plane, crtc, crtc-primary-fb, 0, 0, 
 crtc_w, crtc_h,
 -  x, y, crtc_w, crtc_h);
 +  ret = exynos_plane_mode_set(crtc-primary, crtc, fb, 0, 0,
 +  crtc_w, crtc_h, x, y, crtc_w, crtc_h);
if (ret)
return ret;
  
 @@ -279,6 +268,7 @@ static void exynos_drm_crtc_destroy(struct drm_crtc 
 *crtc)
  
private-crtc[exynos_crtc-pipe] = NULL;
  
 +  crtc-primary-funcs-destroy(crtc-primary);
 This is unnecessary.

 The question is how these object should be destroyed. In current code
 crtc is destroyed in fimd_unbind and it is called before
 drm_mode_config_cleanup
 which destroys all planes.
 In such case primary plane will stay with .crtc

Re: [PATCH] drm/exynos: switch to universal plane API

[Joonyoung Shim]

Hi Andrzej,

On 09/18/2014 10:17 PM, Andrzej Hajda wrote:
> The patch replaces legacy functions
> drm_plane_init() / drm_crtc_init() with
> drm_universal_plane_init() and drm_crtc_init_with_planes().
> It allows to replace fake primary plane with the real one.
> 
> Signed-off-by: Andrzej Hajda 
> ---
> Hi Inki,
> 
> I have tested this patch with trats board, it looks OK.
> As a side effect it should solve fb refcounting issues
> reported by me and Daniel Drake.
> 
> Regards
> Andrzej
> ---
>  drivers/gpu/drm/exynos/exynos_drm_crtc.c  | 63 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_drv.c   |  5 ++-
>  drivers/gpu/drm/exynos/exynos_drm_plane.c | 17 +
>  drivers/gpu/drm/exynos/exynos_drm_plane.h |  3 +-
>  4 files changed, 47 insertions(+), 41 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
> b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> index b68e58f..d2f713e 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> @@ -32,7 +32,6 @@ enum exynos_crtc_mode {
>   * Exynos specific crtc structure.
>   *
>   * @drm_crtc: crtc object.
> - * @drm_plane: pointer of private plane object for this crtc
>   * @manager: the manager associated with this crtc
>   * @pipe: a crtc index created at load() with a new crtc object creation
>   *   and the crtc object would be set to private->crtc array
> @@ -46,7 +45,6 @@ enum exynos_crtc_mode {
>   */
>  struct exynos_drm_crtc {
>   struct drm_crtc drm_crtc;
> - struct drm_plane*plane;
>   struct exynos_drm_manager   *manager;
>   unsigned intpipe;
>   unsigned intdpms;
> @@ -94,12 +92,12 @@ static void exynos_drm_crtc_commit(struct drm_crtc *crtc)
>  
>   exynos_drm_crtc_dpms(crtc, DRM_MODE_DPMS_ON);
>  
> - exynos_plane_commit(exynos_crtc->plane);
> + exynos_plane_commit(crtc->primary);
>  
>   if (manager->ops->commit)
>   manager->ops->commit(manager);
>  
> - exynos_plane_dpms(exynos_crtc->plane, DRM_MODE_DPMS_ON);
> + exynos_plane_dpms(crtc->primary, DRM_MODE_DPMS_ON);
>  }
>  
>  static bool
> @@ -123,10 +121,9 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, struct 
> drm_display_mode *mode,
>  {
>   struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
>   struct exynos_drm_manager *manager = exynos_crtc->manager;
> - struct drm_plane *plane = exynos_crtc->plane;
> + struct drm_framebuffer *fb = crtc->primary->fb;
>   unsigned int crtc_w;
>   unsigned int crtc_h;
> - int ret;
>  
>   /*
>* copy the mode data adjusted by mode_fixup() into crtc->mode
> @@ -134,29 +131,21 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, struct 
> drm_display_mode *mode,
>*/
>   memcpy(>mode, adjusted_mode, sizeof(*adjusted_mode));
>  
> - crtc_w = crtc->primary->fb->width - x;
> - crtc_h = crtc->primary->fb->height - y;
> + crtc_w = fb->width - x;
> + crtc_h = fb->height - y;
>  
>   if (manager->ops->mode_set)
>   manager->ops->mode_set(manager, >mode);
>  
> - ret = exynos_plane_mode_set(plane, crtc, crtc->primary->fb, 0, 0, 
> crtc_w, crtc_h,
> - x, y, crtc_w, crtc_h);
> - if (ret)
> - return ret;
> -
> - plane->crtc = crtc;
> - plane->fb = crtc->primary->fb;
> - drm_framebuffer_reference(plane->fb);
> -
> - return 0;
> + return exynos_plane_mode_set(crtc->primary, crtc, fb, 0, 0,
> +  crtc_w, crtc_h, x, y, crtc_w, crtc_h);
>  }
>  
>  static int exynos_drm_crtc_mode_set_commit(struct drm_crtc *crtc, int x, int 
> y,
> struct drm_framebuffer *old_fb)
>  {
>   struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
> - struct drm_plane *plane = exynos_crtc->plane;
> + struct drm_framebuffer *fb = crtc->primary->fb;
>   unsigned int crtc_w;
>   unsigned int crtc_h;
>   int ret;
> @@ -167,11 +156,11 @@ static int exynos_drm_crtc_mode_set_commit(struct 
> drm_crtc *crtc, int x, int y,
>   return -EPERM;
>   }
>  
> - crtc_w = crtc->primary->fb->width - x;
> - crtc_h = crtc->primary->fb->height - y;
> + crtc_w = fb->width - x;
> + crtc_h = fb->height - y;
>  
> - ret = exynos_plane_mode_set(plane, crtc, crtc->primary->fb, 0, 0, 
> crtc_w, crtc_h,
> - x, y, crtc_w, crtc_h);
> + ret = exynos_plane_mode_set(crtc->primary, crtc, fb, 0, 0,
> + crtc_w, crtc_h, x, y, crtc_w, crtc_h);
>   if (ret)
>   return ret;
>  
> @@ -279,6 +268,7 @@ static void exynos_drm_crtc_destroy(struct drm_crtc *crtc)
>  
>   private->crtc[exynos_crtc->pipe] = NULL;
>  
> + crtc->primary->funcs->destroy(crtc->primary);

This is unnecessary.

>   drm_crtc_cleanup(crtc);
>   

Re: [PATCH] drm/exynos: switch to universal plane API

[Joonyoung Shim]

Hi Andrzej,

On 09/18/2014 10:17 PM, Andrzej Hajda wrote:
 The patch replaces legacy functions
 drm_plane_init() / drm_crtc_init() with
 drm_universal_plane_init() and drm_crtc_init_with_planes().
 It allows to replace fake primary plane with the real one.
 
 Signed-off-by: Andrzej Hajda a.ha...@samsung.com
 ---
 Hi Inki,
 
 I have tested this patch with trats board, it looks OK.
 As a side effect it should solve fb refcounting issues
 reported by me and Daniel Drake.
 
 Regards
 Andrzej
 ---
  drivers/gpu/drm/exynos/exynos_drm_crtc.c  | 63 
 ---
  drivers/gpu/drm/exynos/exynos_drm_drv.c   |  5 ++-
  drivers/gpu/drm/exynos/exynos_drm_plane.c | 17 +
  drivers/gpu/drm/exynos/exynos_drm_plane.h |  3 +-
  4 files changed, 47 insertions(+), 41 deletions(-)
 
 diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
 b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
 index b68e58f..d2f713e 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
 @@ -32,7 +32,6 @@ enum exynos_crtc_mode {
   * Exynos specific crtc structure.
   *
   * @drm_crtc: crtc object.
 - * @drm_plane: pointer of private plane object for this crtc
   * @manager: the manager associated with this crtc
   * @pipe: a crtc index created at load() with a new crtc object creation
   *   and the crtc object would be set to private-crtc array
 @@ -46,7 +45,6 @@ enum exynos_crtc_mode {
   */
  struct exynos_drm_crtc {
   struct drm_crtc drm_crtc;
 - struct drm_plane*plane;
   struct exynos_drm_manager   *manager;
   unsigned intpipe;
   unsigned intdpms;
 @@ -94,12 +92,12 @@ static void exynos_drm_crtc_commit(struct drm_crtc *crtc)
  
   exynos_drm_crtc_dpms(crtc, DRM_MODE_DPMS_ON);
  
 - exynos_plane_commit(exynos_crtc-plane);
 + exynos_plane_commit(crtc-primary);
  
   if (manager-ops-commit)
   manager-ops-commit(manager);
  
 - exynos_plane_dpms(exynos_crtc-plane, DRM_MODE_DPMS_ON);
 + exynos_plane_dpms(crtc-primary, DRM_MODE_DPMS_ON);
  }
  
  static bool
 @@ -123,10 +121,9 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, struct 
 drm_display_mode *mode,
  {
   struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
   struct exynos_drm_manager *manager = exynos_crtc-manager;
 - struct drm_plane *plane = exynos_crtc-plane;
 + struct drm_framebuffer *fb = crtc-primary-fb;
   unsigned int crtc_w;
   unsigned int crtc_h;
 - int ret;
  
   /*
* copy the mode data adjusted by mode_fixup() into crtc-mode
 @@ -134,29 +131,21 @@ exynos_drm_crtc_mode_set(struct drm_crtc *crtc, struct 
 drm_display_mode *mode,
*/
   memcpy(crtc-mode, adjusted_mode, sizeof(*adjusted_mode));
  
 - crtc_w = crtc-primary-fb-width - x;
 - crtc_h = crtc-primary-fb-height - y;
 + crtc_w = fb-width - x;
 + crtc_h = fb-height - y;
  
   if (manager-ops-mode_set)
   manager-ops-mode_set(manager, crtc-mode);
  
 - ret = exynos_plane_mode_set(plane, crtc, crtc-primary-fb, 0, 0, 
 crtc_w, crtc_h,
 - x, y, crtc_w, crtc_h);
 - if (ret)
 - return ret;
 -
 - plane-crtc = crtc;
 - plane-fb = crtc-primary-fb;
 - drm_framebuffer_reference(plane-fb);
 -
 - return 0;
 + return exynos_plane_mode_set(crtc-primary, crtc, fb, 0, 0,
 +  crtc_w, crtc_h, x, y, crtc_w, crtc_h);
  }
  
  static int exynos_drm_crtc_mode_set_commit(struct drm_crtc *crtc, int x, int 
 y,
 struct drm_framebuffer *old_fb)
  {
   struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
 - struct drm_plane *plane = exynos_crtc-plane;
 + struct drm_framebuffer *fb = crtc-primary-fb;
   unsigned int crtc_w;
   unsigned int crtc_h;
   int ret;
 @@ -167,11 +156,11 @@ static int exynos_drm_crtc_mode_set_commit(struct 
 drm_crtc *crtc, int x, int y,
   return -EPERM;
   }
  
 - crtc_w = crtc-primary-fb-width - x;
 - crtc_h = crtc-primary-fb-height - y;
 + crtc_w = fb-width - x;
 + crtc_h = fb-height - y;
  
 - ret = exynos_plane_mode_set(plane, crtc, crtc-primary-fb, 0, 0, 
 crtc_w, crtc_h,
 - x, y, crtc_w, crtc_h);
 + ret = exynos_plane_mode_set(crtc-primary, crtc, fb, 0, 0,
 + crtc_w, crtc_h, x, y, crtc_w, crtc_h);
   if (ret)
   return ret;
  
 @@ -279,6 +268,7 @@ static void exynos_drm_crtc_destroy(struct drm_crtc *crtc)
  
   private-crtc[exynos_crtc-pipe] = NULL;
  
 + crtc-primary-funcs-destroy(crtc-primary);

This is unnecessary.

   drm_crtc_cleanup(crtc);
   kfree(exynos_crtc);
  }
 @@ -304,8 +294,7 @@ static int exynos_drm_crtc_set_property(struct drm_crtc 
 *crtc,
   exynos_drm_crtc_commit(crtc);
 

Re: [PATCH v3 16/17] drm/exynos/ipp: remove file argument from node related functions

[Joonyoung Shim]

On 09/02/2014 09:55 PM, Andrzej Hajda wrote:
> Since file pointer is preserved in c_node passing it
> as argument in node functions is redundant.
> 
> Signed-off-by: Andrzej Hajda 
> ---
> v3:
> - file check moved to next patch
> ---
>  drivers/gpu/drm/exynos/exynos_drm_ipp.c | 12 +---
>  1 file changed, 5 insertions(+), 7 deletions(-)
> 

About both patch 16 and 17

Reviewed-by: Joonyoung Shim 

Thanks.

> diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
> b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
> index 05f0f4e..9e9714a 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
> @@ -529,7 +529,6 @@ static int ipp_put_mem_node(struct drm_device *drm_dev,
>  
>  static struct drm_exynos_ipp_mem_node
>   *ipp_get_mem_node(struct drm_device *drm_dev,
> - struct drm_file *file,
>   struct drm_exynos_ipp_cmd_node *c_node,
>   struct drm_exynos_ipp_queue_buf *qbuf)
>  {
> @@ -560,7 +559,7 @@ static struct drm_exynos_ipp_mem_node
>   dma_addr_t *addr;
>  
>   addr = exynos_drm_gem_get_dma_addr(drm_dev,
> - qbuf->handle[i], file);
> + qbuf->handle[i], c_node->filp);
>   if (IS_ERR(addr)) {
>   DRM_ERROR("failed to get addr.\n");
>   ipp_put_mem_node(drm_dev, c_node, m_node);
> @@ -606,7 +605,6 @@ static void ipp_free_event(struct drm_pending_event 
> *event)
>  }
>  
>  static int ipp_get_event(struct drm_device *drm_dev,
> - struct drm_file *file,
>   struct drm_exynos_ipp_cmd_node *c_node,
>   struct drm_exynos_ipp_queue_buf *qbuf)
>  {
> @@ -618,7 +616,7 @@ static int ipp_get_event(struct drm_device *drm_dev,
>   e = kzalloc(sizeof(*e), GFP_KERNEL);
>   if (!e) {
>   spin_lock_irqsave(_dev->event_lock, flags);
> - file->event_space += sizeof(e->event);
> + c_node->filp->event_space += sizeof(e->event);
>   spin_unlock_irqrestore(_dev->event_lock, flags);
>   return -ENOMEM;
>   }
> @@ -630,7 +628,7 @@ static int ipp_get_event(struct drm_device *drm_dev,
>   e->event.prop_id = qbuf->prop_id;
>   e->event.buf_id[EXYNOS_DRM_OPS_DST] = qbuf->buf_id;
>   e->base.event = >event.base;
> - e->base.file_priv = file;
> + e->base.file_priv = c_node->filp;
>   e->base.destroy = ipp_free_event;
>   mutex_lock(_node->event_lock);
>   list_add_tail(>base.link, _node->event_list);
> @@ -908,7 +906,7 @@ int exynos_drm_ipp_queue_buf(struct drm_device *drm_dev, 
> void *data,
>   switch (qbuf->buf_type) {
>   case IPP_BUF_ENQUEUE:
>   /* get memory node */
> - m_node = ipp_get_mem_node(drm_dev, file, c_node, qbuf);
> + m_node = ipp_get_mem_node(drm_dev, c_node, qbuf);
>   if (IS_ERR(m_node)) {
>   DRM_ERROR("failed to get m_node.\n");
>   return PTR_ERR(m_node);
> @@ -921,7 +919,7 @@ int exynos_drm_ipp_queue_buf(struct drm_device *drm_dev, 
> void *data,
>*/
>   if (qbuf->ops_id == EXYNOS_DRM_OPS_DST) {
>   /* get event for destination buffer */
> - ret = ipp_get_event(drm_dev, file, c_node, qbuf);
> + ret = ipp_get_event(drm_dev, c_node, qbuf);
>   if (ret) {
>   DRM_ERROR("failed to get event.\n");
>   goto err_clean_node;
> 

--
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 16/17] drm/exynos/ipp: remove file argument from node related functions

[Joonyoung Shim]

On 09/02/2014 09:55 PM, Andrzej Hajda wrote:
 Since file pointer is preserved in c_node passing it
 as argument in node functions is redundant.
 
 Signed-off-by: Andrzej Hajda a.ha...@samsung.com
 ---
 v3:
 - file check moved to next patch
 ---
  drivers/gpu/drm/exynos/exynos_drm_ipp.c | 12 +---
  1 file changed, 5 insertions(+), 7 deletions(-)
 

About both patch 16 and 17

Reviewed-by: Joonyoung Shim jy0922.s...@samsung.com

Thanks.

 diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
 b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
 index 05f0f4e..9e9714a 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
 @@ -529,7 +529,6 @@ static int ipp_put_mem_node(struct drm_device *drm_dev,
  
  static struct drm_exynos_ipp_mem_node
   *ipp_get_mem_node(struct drm_device *drm_dev,
 - struct drm_file *file,
   struct drm_exynos_ipp_cmd_node *c_node,
   struct drm_exynos_ipp_queue_buf *qbuf)
  {
 @@ -560,7 +559,7 @@ static struct drm_exynos_ipp_mem_node
   dma_addr_t *addr;
  
   addr = exynos_drm_gem_get_dma_addr(drm_dev,
 - qbuf-handle[i], file);
 + qbuf-handle[i], c_node-filp);
   if (IS_ERR(addr)) {
   DRM_ERROR(failed to get addr.\n);
   ipp_put_mem_node(drm_dev, c_node, m_node);
 @@ -606,7 +605,6 @@ static void ipp_free_event(struct drm_pending_event 
 *event)
  }
  
  static int ipp_get_event(struct drm_device *drm_dev,
 - struct drm_file *file,
   struct drm_exynos_ipp_cmd_node *c_node,
   struct drm_exynos_ipp_queue_buf *qbuf)
  {
 @@ -618,7 +616,7 @@ static int ipp_get_event(struct drm_device *drm_dev,
   e = kzalloc(sizeof(*e), GFP_KERNEL);
   if (!e) {
   spin_lock_irqsave(drm_dev-event_lock, flags);
 - file-event_space += sizeof(e-event);
 + c_node-filp-event_space += sizeof(e-event);
   spin_unlock_irqrestore(drm_dev-event_lock, flags);
   return -ENOMEM;
   }
 @@ -630,7 +628,7 @@ static int ipp_get_event(struct drm_device *drm_dev,
   e-event.prop_id = qbuf-prop_id;
   e-event.buf_id[EXYNOS_DRM_OPS_DST] = qbuf-buf_id;
   e-base.event = e-event.base;
 - e-base.file_priv = file;
 + e-base.file_priv = c_node-filp;
   e-base.destroy = ipp_free_event;
   mutex_lock(c_node-event_lock);
   list_add_tail(e-base.link, c_node-event_list);
 @@ -908,7 +906,7 @@ int exynos_drm_ipp_queue_buf(struct drm_device *drm_dev, 
 void *data,
   switch (qbuf-buf_type) {
   case IPP_BUF_ENQUEUE:
   /* get memory node */
 - m_node = ipp_get_mem_node(drm_dev, file, c_node, qbuf);
 + m_node = ipp_get_mem_node(drm_dev, c_node, qbuf);
   if (IS_ERR(m_node)) {
   DRM_ERROR(failed to get m_node.\n);
   return PTR_ERR(m_node);
 @@ -921,7 +919,7 @@ int exynos_drm_ipp_queue_buf(struct drm_device *drm_dev, 
 void *data,
*/
   if (qbuf-ops_id == EXYNOS_DRM_OPS_DST) {
   /* get event for destination buffer */
 - ret = ipp_get_event(drm_dev, file, c_node, qbuf);
 + ret = ipp_get_event(drm_dev, c_node, qbuf);
   if (ret) {
   DRM_ERROR(failed to get event.\n);
   goto err_clean_node;
 

--
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 17/17] drm/exynos/ipp: add file checks for ioctls

[Joonyoung Shim]

Hi Andrzej,

On 08/28/2014 06:07 PM, Andrzej Hajda wrote:
> Process should not have access to ipp nodes created by another
> process. The patch adds necessary checks.
> 
> Signed-off-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_ipp.c | 15 ++-
>  1 file changed, 10 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
> b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
> index fc8bb67..d233cfc 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
> @@ -318,7 +318,8 @@ static void ipp_print_property(struct 
> drm_exynos_ipp_property *property,
>   sz->hsize, sz->vsize, config->flip, config->degree);
>  }
>  
> -static int ipp_find_and_set_property(struct drm_exynos_ipp_property 
> *property)
> +static int ipp_find_and_set_property(struct drm_exynos_ipp_property 
> *property,
> + struct drm_file *file)

This is ok, but i think ipp_find_and_set_property function is some
duplicated. If we add function to get c_node from struct
exynos_drm_ippdrv, it's easy to remove ipp_find_and_set_property.

Thanks.

>  {
>   struct exynos_drm_ippdrv *ippdrv;
>   struct drm_exynos_ipp_cmd_node *c_node;
> @@ -339,8 +340,12 @@ static int ipp_find_and_set_property(struct 
> drm_exynos_ipp_property *property)
>*/
>   mutex_lock(>cmd_lock);
>   list_for_each_entry(c_node, >cmd_list, list) {
> - if ((c_node->property.prop_id == prop_id) &&
> - (c_node->state == IPP_STATE_STOP)) {
> + if (c_node->property.prop_id == prop_id) {
> + if (c_node->filp != file)
> + break;
> + if (c_node->state != IPP_STATE_STOP)
> + break;
> +
>   mutex_unlock(>cmd_lock);
>   DRM_DEBUG_KMS("found cmd[%d]ippdrv[0x%x]\n",
>   property->cmd, (int)ippdrv);
> @@ -418,7 +423,7 @@ int exynos_drm_ipp_set_property(struct drm_device 
> *drm_dev, void *data,
>*/
>   if (property->prop_id) {
>   DRM_DEBUG_KMS("prop_id[%d]\n", property->prop_id);
> - return ipp_find_and_set_property(property);
> + return ipp_find_and_set_property(property, file);
>   }
>  
>   /* find ipp driver using ipp id */
> @@ -1032,7 +1037,7 @@ int exynos_drm_ipp_cmd_ctrl(struct drm_device *drm_dev, 
> void *data,
>  
>   c_node = ipp_find_obj(>prop_idr, >prop_lock,
>   cmd_ctrl->prop_id);
> - if (!c_node) {
> + if (!c_node || c_node->filp != file) {
>   DRM_ERROR("invalid command node list.\n");
>   return -ENODEV;
>   }
> 

--
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 16/17] drm/exynos/ipp: remove file argument from node related functions

[Joonyoung Shim]

Hi Andrzej,

On 08/28/2014 06:07 PM, Andrzej Hajda wrote:
> Since file pointer is preserved in c_node passing it
> as argument in node functions is redundant.
> 
> Signed-off-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_ipp.c | 14 ++
>  1 file changed, 6 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
> b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
> index 05f0f4e..fc8bb67 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
> @@ -529,7 +529,6 @@ static int ipp_put_mem_node(struct drm_device *drm_dev,
>  
>  static struct drm_exynos_ipp_mem_node
>   *ipp_get_mem_node(struct drm_device *drm_dev,
> - struct drm_file *file,
>   struct drm_exynos_ipp_cmd_node *c_node,
>   struct drm_exynos_ipp_queue_buf *qbuf)
>  {
> @@ -560,7 +559,7 @@ static struct drm_exynos_ipp_mem_node
>   dma_addr_t *addr;
>  
>   addr = exynos_drm_gem_get_dma_addr(drm_dev,
> - qbuf->handle[i], file);
> + qbuf->handle[i], c_node->filp);
>   if (IS_ERR(addr)) {
>   DRM_ERROR("failed to get addr.\n");
>   ipp_put_mem_node(drm_dev, c_node, m_node);
> @@ -606,7 +605,6 @@ static void ipp_free_event(struct drm_pending_event 
> *event)
>  }
>  
>  static int ipp_get_event(struct drm_device *drm_dev,
> - struct drm_file *file,
>   struct drm_exynos_ipp_cmd_node *c_node,
>   struct drm_exynos_ipp_queue_buf *qbuf)
>  {
> @@ -618,7 +616,7 @@ static int ipp_get_event(struct drm_device *drm_dev,
>   e = kzalloc(sizeof(*e), GFP_KERNEL);
>   if (!e) {
>   spin_lock_irqsave(_dev->event_lock, flags);
> - file->event_space += sizeof(e->event);
> + c_node->filp->event_space += sizeof(e->event);
>   spin_unlock_irqrestore(_dev->event_lock, flags);
>   return -ENOMEM;
>   }
> @@ -630,7 +628,7 @@ static int ipp_get_event(struct drm_device *drm_dev,
>   e->event.prop_id = qbuf->prop_id;
>   e->event.buf_id[EXYNOS_DRM_OPS_DST] = qbuf->buf_id;
>   e->base.event = >event.base;
> - e->base.file_priv = file;
> + e->base.file_priv = c_node->filp;
>   e->base.destroy = ipp_free_event;
>   mutex_lock(_node->event_lock);
>   list_add_tail(>base.link, _node->event_list);
> @@ -899,7 +897,7 @@ int exynos_drm_ipp_queue_buf(struct drm_device *drm_dev, 
> void *data,
>   /* find command node */
>   c_node = ipp_find_obj(>prop_idr, >prop_lock,
>   qbuf->prop_id);
> - if (!c_node) {
> + if (!c_node || c_node->filp != file) {

I think this should go to patch 17.

Thanks.

>   DRM_ERROR("failed to get command node.\n");
>   return -ENODEV;
>   }
> @@ -908,7 +906,7 @@ int exynos_drm_ipp_queue_buf(struct drm_device *drm_dev, 
> void *data,
>   switch (qbuf->buf_type) {
>   case IPP_BUF_ENQUEUE:
>   /* get memory node */
> - m_node = ipp_get_mem_node(drm_dev, file, c_node, qbuf);
> + m_node = ipp_get_mem_node(drm_dev, c_node, qbuf);
>   if (IS_ERR(m_node)) {
>   DRM_ERROR("failed to get m_node.\n");
>   return PTR_ERR(m_node);
> @@ -921,7 +919,7 @@ int exynos_drm_ipp_queue_buf(struct drm_device *drm_dev, 
> void *data,
>*/
>   if (qbuf->ops_id == EXYNOS_DRM_OPS_DST) {
>   /* get event for destination buffer */
> - ret = ipp_get_event(drm_dev, file, c_node, qbuf);
> + ret = ipp_get_event(drm_dev, c_node, qbuf);
>   if (ret) {
>   DRM_ERROR("failed to get event.\n");
>   goto err_clean_node;
> 

--
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 16/17] drm/exynos/ipp: remove file argument from node related functions

[Joonyoung Shim]

Hi Andrzej,

On 08/28/2014 06:07 PM, Andrzej Hajda wrote:
 Since file pointer is preserved in c_node passing it
 as argument in node functions is redundant.
 
 Signed-off-by: Andrzej Hajda a.ha...@samsung.com
 ---
  drivers/gpu/drm/exynos/exynos_drm_ipp.c | 14 ++
  1 file changed, 6 insertions(+), 8 deletions(-)
 
 diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
 b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
 index 05f0f4e..fc8bb67 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
 @@ -529,7 +529,6 @@ static int ipp_put_mem_node(struct drm_device *drm_dev,
  
  static struct drm_exynos_ipp_mem_node
   *ipp_get_mem_node(struct drm_device *drm_dev,
 - struct drm_file *file,
   struct drm_exynos_ipp_cmd_node *c_node,
   struct drm_exynos_ipp_queue_buf *qbuf)
  {
 @@ -560,7 +559,7 @@ static struct drm_exynos_ipp_mem_node
   dma_addr_t *addr;
  
   addr = exynos_drm_gem_get_dma_addr(drm_dev,
 - qbuf-handle[i], file);
 + qbuf-handle[i], c_node-filp);
   if (IS_ERR(addr)) {
   DRM_ERROR(failed to get addr.\n);
   ipp_put_mem_node(drm_dev, c_node, m_node);
 @@ -606,7 +605,6 @@ static void ipp_free_event(struct drm_pending_event 
 *event)
  }
  
  static int ipp_get_event(struct drm_device *drm_dev,
 - struct drm_file *file,
   struct drm_exynos_ipp_cmd_node *c_node,
   struct drm_exynos_ipp_queue_buf *qbuf)
  {
 @@ -618,7 +616,7 @@ static int ipp_get_event(struct drm_device *drm_dev,
   e = kzalloc(sizeof(*e), GFP_KERNEL);
   if (!e) {
   spin_lock_irqsave(drm_dev-event_lock, flags);
 - file-event_space += sizeof(e-event);
 + c_node-filp-event_space += sizeof(e-event);
   spin_unlock_irqrestore(drm_dev-event_lock, flags);
   return -ENOMEM;
   }
 @@ -630,7 +628,7 @@ static int ipp_get_event(struct drm_device *drm_dev,
   e-event.prop_id = qbuf-prop_id;
   e-event.buf_id[EXYNOS_DRM_OPS_DST] = qbuf-buf_id;
   e-base.event = e-event.base;
 - e-base.file_priv = file;
 + e-base.file_priv = c_node-filp;
   e-base.destroy = ipp_free_event;
   mutex_lock(c_node-event_lock);
   list_add_tail(e-base.link, c_node-event_list);
 @@ -899,7 +897,7 @@ int exynos_drm_ipp_queue_buf(struct drm_device *drm_dev, 
 void *data,
   /* find command node */
   c_node = ipp_find_obj(ctx-prop_idr, ctx-prop_lock,
   qbuf-prop_id);
 - if (!c_node) {
 + if (!c_node || c_node-filp != file) {

I think this should go to patch 17.

Thanks.

   DRM_ERROR(failed to get command node.\n);
   return -ENODEV;
   }
 @@ -908,7 +906,7 @@ int exynos_drm_ipp_queue_buf(struct drm_device *drm_dev, 
 void *data,
   switch (qbuf-buf_type) {
   case IPP_BUF_ENQUEUE:
   /* get memory node */
 - m_node = ipp_get_mem_node(drm_dev, file, c_node, qbuf);
 + m_node = ipp_get_mem_node(drm_dev, c_node, qbuf);
   if (IS_ERR(m_node)) {
   DRM_ERROR(failed to get m_node.\n);
   return PTR_ERR(m_node);
 @@ -921,7 +919,7 @@ int exynos_drm_ipp_queue_buf(struct drm_device *drm_dev, 
 void *data,
*/
   if (qbuf-ops_id == EXYNOS_DRM_OPS_DST) {
   /* get event for destination buffer */
 - ret = ipp_get_event(drm_dev, file, c_node, qbuf);
 + ret = ipp_get_event(drm_dev, c_node, qbuf);
   if (ret) {
   DRM_ERROR(failed to get event.\n);
   goto err_clean_node;
 

--
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 17/17] drm/exynos/ipp: add file checks for ioctls

[Joonyoung Shim]

Hi Andrzej,

On 08/28/2014 06:07 PM, Andrzej Hajda wrote:
 Process should not have access to ipp nodes created by another
 process. The patch adds necessary checks.
 
 Signed-off-by: Andrzej Hajda a.ha...@samsung.com
 ---
  drivers/gpu/drm/exynos/exynos_drm_ipp.c | 15 ++-
  1 file changed, 10 insertions(+), 5 deletions(-)
 
 diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
 b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
 index fc8bb67..d233cfc 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
 @@ -318,7 +318,8 @@ static void ipp_print_property(struct 
 drm_exynos_ipp_property *property,
   sz-hsize, sz-vsize, config-flip, config-degree);
  }
  
 -static int ipp_find_and_set_property(struct drm_exynos_ipp_property 
 *property)
 +static int ipp_find_and_set_property(struct drm_exynos_ipp_property 
 *property,
 + struct drm_file *file)

This is ok, but i think ipp_find_and_set_property function is some
duplicated. If we add function to get c_node from struct
exynos_drm_ippdrv, it's easy to remove ipp_find_and_set_property.

Thanks.

  {
   struct exynos_drm_ippdrv *ippdrv;
   struct drm_exynos_ipp_cmd_node *c_node;
 @@ -339,8 +340,12 @@ static int ipp_find_and_set_property(struct 
 drm_exynos_ipp_property *property)
*/
   mutex_lock(ippdrv-cmd_lock);
   list_for_each_entry(c_node, ippdrv-cmd_list, list) {
 - if ((c_node-property.prop_id == prop_id) 
 - (c_node-state == IPP_STATE_STOP)) {
 + if (c_node-property.prop_id == prop_id) {
 + if (c_node-filp != file)
 + break;
 + if (c_node-state != IPP_STATE_STOP)
 + break;
 +
   mutex_unlock(ippdrv-cmd_lock);
   DRM_DEBUG_KMS(found cmd[%d]ippdrv[0x%x]\n,
   property-cmd, (int)ippdrv);
 @@ -418,7 +423,7 @@ int exynos_drm_ipp_set_property(struct drm_device 
 *drm_dev, void *data,
*/
   if (property-prop_id) {
   DRM_DEBUG_KMS(prop_id[%d]\n, property-prop_id);
 - return ipp_find_and_set_property(property);
 + return ipp_find_and_set_property(property, file);
   }
  
   /* find ipp driver using ipp id */
 @@ -1032,7 +1037,7 @@ int exynos_drm_ipp_cmd_ctrl(struct drm_device *drm_dev, 
 void *data,
  
   c_node = ipp_find_obj(ctx-prop_idr, ctx-prop_lock,
   cmd_ctrl-prop_id);
 - if (!c_node) {
 + if (!c_node || c_node-filp != file) {
   DRM_ERROR(invalid command node list.\n);
   return -ENODEV;
   }
 

--
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 06/15] drm/exynos/ipp: free partially allocated resources on error

[Joonyoung Shim]

Hi,

On 08/27/2014 07:27 PM, Andrzej Hajda wrote:
> On 08/26/2014 07:00 AM, Joonyoung Shim wrote:
>> Hi Andrzej,
>>
>> On 08/22/2014 04:52 PM, Andrzej Hajda wrote:
>>> In case of allocation errors some already allocated buffers
>>> were not freed. The patch fixes it.
>>>
>>> Signed-off-by: Andrzej Hajda 
>>> ---
>>>  drivers/gpu/drm/exynos/exynos_drm_ipp.c | 68 
>>> -
>>>  1 file changed, 33 insertions(+), 35 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
>>> b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
>>> index 060a198..728f3b9 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
>>> @@ -599,6 +599,37 @@ static int ipp_set_mem_node(struct exynos_drm_ippdrv 
>>> *ippdrv,
>>> return ret;
>>>  }
>>>  
>>> +static int ipp_put_mem_node(struct drm_device *drm_dev,
>>> +   struct drm_exynos_ipp_cmd_node *c_node,
>>> +   struct drm_exynos_ipp_mem_node *m_node)
>>> +{
>>> +   int i;
>>> +
>>> +   DRM_DEBUG_KMS("node[0x%x]\n", (int)m_node);
>>> +
>>> +   if (!m_node) {
>>> +   DRM_ERROR("invalid dequeue node.\n");
>>> +   return -EFAULT;
>>> +   }
>>> +
>>> +   DRM_DEBUG_KMS("ops_id[%d]\n", m_node->ops_id);
>>> +
>>> +   /* put gem buffer */
>>> +   for_each_ipp_planar(i) {
>>> +   unsigned long handle = m_node->buf_info.handles[i];
>>> +   if (handle)
>>> +   exynos_drm_gem_put_dma_addr(drm_dev, handle,
>>> +   c_node->filp);
>>> +   }
>>> +
>>> +   /* conditionally remove from queue */
>>> +   if (m_node->list.next)
>> How about do INIT_LIST_HEAD for list in ipp_get_mem_node()?
> 
> I am not sure if it is better. For sure it adds unnecessary
> initialization sequence.

In other words, this NULL checking is unnecessary if you initialize the
list_head by INIT_LIST_HEAD.

> Maybe adding list_is_initialized inline function to list.h would be the
> best solution.

There is just list_empty and we can't know whether list is initialized
or not. I recommend to use initialized list_head.

Thanks.

> 
> Regards
> Andrzej
> 
>>
>>> +   list_del(_node->list);
>>> +   kfree(m_node);
>>> +
>>> +   return 0;
>>> +}
>>> +
>>>  static struct drm_exynos_ipp_mem_node
>>> *ipp_get_mem_node(struct drm_device *drm_dev,
>>> struct drm_file *file,
>>> @@ -634,7 +665,8 @@ static struct drm_exynos_ipp_mem_node
>>> qbuf->handle[i], file);
>>> if (IS_ERR(addr)) {
>>> DRM_ERROR("failed to get addr.\n");
>>> -   goto err_clear;
>>> +   ipp_put_mem_node(drm_dev, c_node, m_node);
>>> +   return ERR_PTR(-EFAULT);
>>> }
>>>  
>>> buf_info->handles[i] = qbuf->handle[i];
>>> @@ -649,40 +681,6 @@ static struct drm_exynos_ipp_mem_node
>>> mutex_unlock(_node->mem_lock);
>>>  
>>> return m_node;
>>> -
>>> -err_clear:
>>> -   kfree(m_node);
>>> -   return ERR_PTR(-EFAULT);
>>> -}
>>> -
>>> -static int ipp_put_mem_node(struct drm_device *drm_dev,
>>> -   struct drm_exynos_ipp_cmd_node *c_node,
>>> -   struct drm_exynos_ipp_mem_node *m_node)
>>> -{
>>> -   int i;
>>> -
>>> -   DRM_DEBUG_KMS("node[0x%x]\n", (int)m_node);
>>> -
>>> -   if (!m_node) {
>>> -   DRM_ERROR("invalid dequeue node.\n");
>>> -   return -EFAULT;
>>> -   }
>>> -
>>> -   DRM_DEBUG_KMS("ops_id[%d]\n", m_node->ops_id);
>>> -
>>> -   /* put gem buffer */
>>> -   for_each_ipp_planar(i) {
>>> -   unsigned long handle = m_node->buf_info.handles[i];
>>> -   if (handle)
>>> -   exynos_drm_gem_put_dma_addr(drm_dev, handle,
>>> -   c_node->filp);
>>> -   }
>>> -
>>> -   /* delete list in queue */
>>> -   list_del(_node->list);
>>> -   kfree(m_node);
>>> -
>>> -   return 0;
>>>  }
>>>  
>>>  static void ipp_free_event(struct drm_pending_event *event)
>>>
>>
> 
> 

--
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 06/15] drm/exynos/ipp: free partially allocated resources on error

[Joonyoung Shim]

Hi,

On 08/27/2014 07:27 PM, Andrzej Hajda wrote:
 On 08/26/2014 07:00 AM, Joonyoung Shim wrote:
 Hi Andrzej,

 On 08/22/2014 04:52 PM, Andrzej Hajda wrote:
 In case of allocation errors some already allocated buffers
 were not freed. The patch fixes it.

 Signed-off-by: Andrzej Hajda a.ha...@samsung.com
 ---
  drivers/gpu/drm/exynos/exynos_drm_ipp.c | 68 
 -
  1 file changed, 33 insertions(+), 35 deletions(-)

 diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
 b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
 index 060a198..728f3b9 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
 @@ -599,6 +599,37 @@ static int ipp_set_mem_node(struct exynos_drm_ippdrv 
 *ippdrv,
 return ret;
  }
  
 +static int ipp_put_mem_node(struct drm_device *drm_dev,
 +   struct drm_exynos_ipp_cmd_node *c_node,
 +   struct drm_exynos_ipp_mem_node *m_node)
 +{
 +   int i;
 +
 +   DRM_DEBUG_KMS(node[0x%x]\n, (int)m_node);
 +
 +   if (!m_node) {
 +   DRM_ERROR(invalid dequeue node.\n);
 +   return -EFAULT;
 +   }
 +
 +   DRM_DEBUG_KMS(ops_id[%d]\n, m_node-ops_id);
 +
 +   /* put gem buffer */
 +   for_each_ipp_planar(i) {
 +   unsigned long handle = m_node-buf_info.handles[i];
 +   if (handle)
 +   exynos_drm_gem_put_dma_addr(drm_dev, handle,
 +   c_node-filp);
 +   }
 +
 +   /* conditionally remove from queue */
 +   if (m_node-list.next)
 How about do INIT_LIST_HEAD for list in ipp_get_mem_node()?
 
 I am not sure if it is better. For sure it adds unnecessary
 initialization sequence.

In other words, this NULL checking is unnecessary if you initialize the
list_head by INIT_LIST_HEAD.

 Maybe adding list_is_initialized inline function to list.h would be the
 best solution.

There is just list_empty and we can't know whether list is initialized
or not. I recommend to use initialized list_head.

Thanks.

 
 Regards
 Andrzej
 

 +   list_del(m_node-list);
 +   kfree(m_node);
 +
 +   return 0;
 +}
 +
  static struct drm_exynos_ipp_mem_node
 *ipp_get_mem_node(struct drm_device *drm_dev,
 struct drm_file *file,
 @@ -634,7 +665,8 @@ static struct drm_exynos_ipp_mem_node
 qbuf-handle[i], file);
 if (IS_ERR(addr)) {
 DRM_ERROR(failed to get addr.\n);
 -   goto err_clear;
 +   ipp_put_mem_node(drm_dev, c_node, m_node);
 +   return ERR_PTR(-EFAULT);
 }
  
 buf_info-handles[i] = qbuf-handle[i];
 @@ -649,40 +681,6 @@ static struct drm_exynos_ipp_mem_node
 mutex_unlock(c_node-mem_lock);
  
 return m_node;
 -
 -err_clear:
 -   kfree(m_node);
 -   return ERR_PTR(-EFAULT);
 -}
 -
 -static int ipp_put_mem_node(struct drm_device *drm_dev,
 -   struct drm_exynos_ipp_cmd_node *c_node,
 -   struct drm_exynos_ipp_mem_node *m_node)
 -{
 -   int i;
 -
 -   DRM_DEBUG_KMS(node[0x%x]\n, (int)m_node);
 -
 -   if (!m_node) {
 -   DRM_ERROR(invalid dequeue node.\n);
 -   return -EFAULT;
 -   }
 -
 -   DRM_DEBUG_KMS(ops_id[%d]\n, m_node-ops_id);
 -
 -   /* put gem buffer */
 -   for_each_ipp_planar(i) {
 -   unsigned long handle = m_node-buf_info.handles[i];
 -   if (handle)
 -   exynos_drm_gem_put_dma_addr(drm_dev, handle,
 -   c_node-filp);
 -   }
 -
 -   /* delete list in queue */
 -   list_del(m_node-list);
 -   kfree(m_node);
 -
 -   return 0;
  }
  
  static void ipp_free_event(struct drm_pending_event *event)


 
 

--
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 00/15] drm/exynos/ipp: image post processing fixes and improvements, part four

[Joonyoung Shim]

On 08/22/2014 04:52 PM, Andrzej Hajda wrote:
> This set of patches contains various improvement and fixes
> for exynos_drm ipp framework.
> The patchset is based on exynos-drm-next branch.
> 
> IPP framework was tested for regressions on exynos4210-trats target.
> 
> Regards
> Andrzej
> 
> 
> Andrzej Hajda (15):
>   drm/exynos/ipp: remove fake pm callbacks
>   drm/exynos/ipp: cancel works before command node clean
>   drm/exynos/ipp: move file reference from memory to command node
>   drm/exynos/ipp: remove only related commands on file close
>   drm/exynos/ipp: remove unused field in command node
>   drm/exynos/ipp: free partially allocated resources on error
>   drm/exynos/ipp: move nodes cleaning to separate function
>   drm/exynos/ipp: clean memory nodes on command node cleaning
>   drm/exynos/ipp: replace work_struct casting with better constructs
>   drm/exynos/ipp: stop hardware before freeing memory
>   drm/exynos/ipp: remove events during command cleaning
>   drm/exynos/fimc: avoid clearing overflow bits
>   drm/exynos/fimc: do not enable fimc twice
>   drm/exynos/fimc: simplify buffer queuing
>   drm/exynos/fimc: fix source buffer registers

With some minor comments,

Reviewed-by: Joonyoung Shim 

Thanks.

> 
>  drivers/gpu/drm/exynos/exynos_drm_fimc.c|  90 ++-
>  drivers/gpu/drm/exynos/exynos_drm_gsc.c |   3 +-
>  drivers/gpu/drm/exynos/exynos_drm_ipp.c | 369 
> 
>  drivers/gpu/drm/exynos/exynos_drm_ipp.h |   4 +-
>  drivers/gpu/drm/exynos/exynos_drm_rotator.c |   3 +-
>  5 files changed, 180 insertions(+), 289 deletions(-)
> 

--
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/15] drm/exynos/fimc: fix source buffer registers

[Joonyoung Shim]

On 08/26/2014 03:35 PM, Andrzej Hajda wrote:
> On 08/26/2014 07:57 AM, Joonyoung Shim wrote:
>> Hi Andrzej,
>>
>> On 08/22/2014 04:52 PM, Andrzej Hajda wrote:
>>> FIMC in default mode of operation uses only one input buffer,
>>> but the driver used also second buffer, as a result only the
>>> first frame was processed correctly. The patch fixes it.
>> I can't understand well, then we don't need to distinguish buf_id in
>> fimc_src_set_addr()?
> Yes. FIMC in default operation mode uses only one input buffer pointer
> which should
> be updated when processing of the previous buffer has been finished.
> 
> There exists also ping-pong mode which uses two buffer pointers, as I
> have spotted in
> specs. However I have not seen it was implemented neither in drm,
> neither in camera drivers.
> I will try to implement it later.

OK if operation is no problem, and i think it's better to add comments
about this.

> 
> Regards
> Andrzej
> 
>>
>>> Signed-off-by: Andrzej Hajda 
>>> ---
>>>  drivers/gpu/drm/exynos/exynos_drm_fimc.c | 16 
>>>  1 file changed, 8 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
>>> b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
>>> index b20078e..e985253 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
>>> @@ -720,24 +720,24 @@ static int fimc_src_set_addr(struct device *dev,
>>> case IPP_BUF_ENQUEUE:
>>> config = >config[EXYNOS_DRM_OPS_SRC];
>>> fimc_write(ctx, buf_info->base[EXYNOS_DRM_PLANAR_Y],
>>> -   EXYNOS_CIIYSA(buf_id));
>>> +   EXYNOS_CIIYSA0);
>>>  
>>> if (config->fmt == DRM_FORMAT_YVU420) {
>>> fimc_write(ctx, buf_info->base[EXYNOS_DRM_PLANAR_CR],
>>> -   EXYNOS_CIICBSA(buf_id));
>>> +   EXYNOS_CIICBSA0);
>>> fimc_write(ctx, buf_info->base[EXYNOS_DRM_PLANAR_CB],
>>> -   EXYNOS_CIICRSA(buf_id));
>>> +   EXYNOS_CIICRSA0);
>>> } else {
>>> fimc_write(ctx, buf_info->base[EXYNOS_DRM_PLANAR_CB],
>>> -   EXYNOS_CIICBSA(buf_id));
>>> +   EXYNOS_CIICBSA0);
>>> fimc_write(ctx, buf_info->base[EXYNOS_DRM_PLANAR_CR],
>>> -   EXYNOS_CIICRSA(buf_id));
>>> +   EXYNOS_CIICRSA0);
>>> }
>>> break;
>>> case IPP_BUF_DEQUEUE:
>>> -   fimc_write(ctx, 0x0, EXYNOS_CIIYSA(buf_id));
>>> -   fimc_write(ctx, 0x0, EXYNOS_CIICBSA(buf_id));
>>> -   fimc_write(ctx, 0x0, EXYNOS_CIICRSA(buf_id));
>>> +   fimc_write(ctx, 0x0, EXYNOS_CIIYSA0);
>>> +   fimc_write(ctx, 0x0, EXYNOS_CIICBSA0);
>>> +   fimc_write(ctx, 0x0, EXYNOS_CIICRSA0);
>>> break;
>>> default:
>>> /* bypass */
>>>
>>
> 
> 

--
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/15] drm/exynos/fimc: fix source buffer registers

[Joonyoung Shim]

On 08/26/2014 03:35 PM, Andrzej Hajda wrote:
 On 08/26/2014 07:57 AM, Joonyoung Shim wrote:
 Hi Andrzej,

 On 08/22/2014 04:52 PM, Andrzej Hajda wrote:
 FIMC in default mode of operation uses only one input buffer,
 but the driver used also second buffer, as a result only the
 first frame was processed correctly. The patch fixes it.
 I can't understand well, then we don't need to distinguish buf_id in
 fimc_src_set_addr()?
 Yes. FIMC in default operation mode uses only one input buffer pointer
 which should
 be updated when processing of the previous buffer has been finished.
 
 There exists also ping-pong mode which uses two buffer pointers, as I
 have spotted in
 specs. However I have not seen it was implemented neither in drm,
 neither in camera drivers.
 I will try to implement it later.

OK if operation is no problem, and i think it's better to add comments
about this.

 
 Regards
 Andrzej
 

 Signed-off-by: Andrzej Hajda a.ha...@samsung.com
 ---
  drivers/gpu/drm/exynos/exynos_drm_fimc.c | 16 
  1 file changed, 8 insertions(+), 8 deletions(-)

 diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
 b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
 index b20078e..e985253 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
 @@ -720,24 +720,24 @@ static int fimc_src_set_addr(struct device *dev,
 case IPP_BUF_ENQUEUE:
 config = property-config[EXYNOS_DRM_OPS_SRC];
 fimc_write(ctx, buf_info-base[EXYNOS_DRM_PLANAR_Y],
 -   EXYNOS_CIIYSA(buf_id));
 +   EXYNOS_CIIYSA0);
  
 if (config-fmt == DRM_FORMAT_YVU420) {
 fimc_write(ctx, buf_info-base[EXYNOS_DRM_PLANAR_CR],
 -   EXYNOS_CIICBSA(buf_id));
 +   EXYNOS_CIICBSA0);
 fimc_write(ctx, buf_info-base[EXYNOS_DRM_PLANAR_CB],
 -   EXYNOS_CIICRSA(buf_id));
 +   EXYNOS_CIICRSA0);
 } else {
 fimc_write(ctx, buf_info-base[EXYNOS_DRM_PLANAR_CB],
 -   EXYNOS_CIICBSA(buf_id));
 +   EXYNOS_CIICBSA0);
 fimc_write(ctx, buf_info-base[EXYNOS_DRM_PLANAR_CR],
 -   EXYNOS_CIICRSA(buf_id));
 +   EXYNOS_CIICRSA0);
 }
 break;
 case IPP_BUF_DEQUEUE:
 -   fimc_write(ctx, 0x0, EXYNOS_CIIYSA(buf_id));
 -   fimc_write(ctx, 0x0, EXYNOS_CIICBSA(buf_id));
 -   fimc_write(ctx, 0x0, EXYNOS_CIICRSA(buf_id));
 +   fimc_write(ctx, 0x0, EXYNOS_CIIYSA0);
 +   fimc_write(ctx, 0x0, EXYNOS_CIICBSA0);
 +   fimc_write(ctx, 0x0, EXYNOS_CIICRSA0);
 break;
 default:
 /* bypass */


 
 

--
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 00/15] drm/exynos/ipp: image post processing fixes and improvements, part four

[Joonyoung Shim]

On 08/22/2014 04:52 PM, Andrzej Hajda wrote:
 This set of patches contains various improvement and fixes
 for exynos_drm ipp framework.
 The patchset is based on exynos-drm-next branch.
 
 IPP framework was tested for regressions on exynos4210-trats target.
 
 Regards
 Andrzej
 
 
 Andrzej Hajda (15):
   drm/exynos/ipp: remove fake pm callbacks
   drm/exynos/ipp: cancel works before command node clean
   drm/exynos/ipp: move file reference from memory to command node
   drm/exynos/ipp: remove only related commands on file close
   drm/exynos/ipp: remove unused field in command node
   drm/exynos/ipp: free partially allocated resources on error
   drm/exynos/ipp: move nodes cleaning to separate function
   drm/exynos/ipp: clean memory nodes on command node cleaning
   drm/exynos/ipp: replace work_struct casting with better constructs
   drm/exynos/ipp: stop hardware before freeing memory
   drm/exynos/ipp: remove events during command cleaning
   drm/exynos/fimc: avoid clearing overflow bits
   drm/exynos/fimc: do not enable fimc twice
   drm/exynos/fimc: simplify buffer queuing
   drm/exynos/fimc: fix source buffer registers

With some minor comments,

Reviewed-by: Joonyoung Shim jy0922.s...@samsung.com

Thanks.

 
  drivers/gpu/drm/exynos/exynos_drm_fimc.c|  90 ++-
  drivers/gpu/drm/exynos/exynos_drm_gsc.c |   3 +-
  drivers/gpu/drm/exynos/exynos_drm_ipp.c | 369 
 
  drivers/gpu/drm/exynos/exynos_drm_ipp.h |   4 +-
  drivers/gpu/drm/exynos/exynos_drm_rotator.c |   3 +-
  5 files changed, 180 insertions(+), 289 deletions(-)
 

--
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/15] drm/exynos/fimc: fix source buffer registers

[Joonyoung Shim]

Hi Andrzej,

On 08/22/2014 04:52 PM, Andrzej Hajda wrote:
> FIMC in default mode of operation uses only one input buffer,
> but the driver used also second buffer, as a result only the
> first frame was processed correctly. The patch fixes it.

I can't understand well, then we don't need to distinguish buf_id in
fimc_src_set_addr()?

> 
> Signed-off-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_fimc.c | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> index b20078e..e985253 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> @@ -720,24 +720,24 @@ static int fimc_src_set_addr(struct device *dev,
>   case IPP_BUF_ENQUEUE:
>   config = >config[EXYNOS_DRM_OPS_SRC];
>   fimc_write(ctx, buf_info->base[EXYNOS_DRM_PLANAR_Y],
> - EXYNOS_CIIYSA(buf_id));
> + EXYNOS_CIIYSA0);
>  
>   if (config->fmt == DRM_FORMAT_YVU420) {
>   fimc_write(ctx, buf_info->base[EXYNOS_DRM_PLANAR_CR],
> - EXYNOS_CIICBSA(buf_id));
> + EXYNOS_CIICBSA0);
>   fimc_write(ctx, buf_info->base[EXYNOS_DRM_PLANAR_CB],
> - EXYNOS_CIICRSA(buf_id));
> + EXYNOS_CIICRSA0);
>   } else {
>   fimc_write(ctx, buf_info->base[EXYNOS_DRM_PLANAR_CB],
> - EXYNOS_CIICBSA(buf_id));
> + EXYNOS_CIICBSA0);
>   fimc_write(ctx, buf_info->base[EXYNOS_DRM_PLANAR_CR],
> - EXYNOS_CIICRSA(buf_id));
> + EXYNOS_CIICRSA0);
>   }
>   break;
>   case IPP_BUF_DEQUEUE:
> - fimc_write(ctx, 0x0, EXYNOS_CIIYSA(buf_id));
> - fimc_write(ctx, 0x0, EXYNOS_CIICBSA(buf_id));
> - fimc_write(ctx, 0x0, EXYNOS_CIICRSA(buf_id));
> + fimc_write(ctx, 0x0, EXYNOS_CIIYSA0);
> + fimc_write(ctx, 0x0, EXYNOS_CIICBSA0);
> + fimc_write(ctx, 0x0, EXYNOS_CIICRSA0);
>   break;
>   default:
>   /* bypass */
> 

--
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 14/15] drm/exynos/fimc: simplify buffer queuing

[Joonyoung Shim]

Hi Andrzej,

On 08/22/2014 04:52 PM, Andrzej Hajda wrote:
> The patch removes redundant checks, redundant HW reads
> and simplifies code.
> 
> Signed-off-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_fimc.c | 64 
> 
>  1 file changed, 15 insertions(+), 49 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> index bd6628d..b20078e 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> @@ -1124,67 +1124,34 @@ static int fimc_dst_set_size(struct device *dev, int 
> swap,
>   return 0;
>  }
>  
> -static int fimc_dst_get_buf_count(struct fimc_context *ctx)
> -{
> - u32 cfg, buf_num;
> -
> - cfg = fimc_read(ctx, EXYNOS_CIFCNTSEQ);
> -
> - buf_num = hweight32(cfg);
> -
> - DRM_DEBUG_KMS("buf_num[%d]\n", buf_num);
> -
> - return buf_num;
> -}
> -
> -static int fimc_dst_set_buf_seq(struct fimc_context *ctx, u32 buf_id,
> +static void fimc_dst_set_buf_seq(struct fimc_context *ctx, u32 buf_id,
>   enum drm_exynos_ipp_buf_type buf_type)
>  {
> - struct exynos_drm_ippdrv *ippdrv = >ippdrv;
> - bool enable;
> - u32 cfg;
> - u32 mask = 0x0001 << buf_id;
> - int ret = 0;
>   unsigned long flags;
> + u32 buf_num;
> + u32 cfg;
>  
>   DRM_DEBUG_KMS("buf_id[%d]buf_type[%d]\n", buf_id, buf_type);
>  
>   spin_lock_irqsave(>lock, flags);
>  
> - /* mask register set */
>   cfg = fimc_read(ctx, EXYNOS_CIFCNTSEQ);
>  
> - switch (buf_type) {
> - case IPP_BUF_ENQUEUE:
> - enable = true;
> - break;
> - case IPP_BUF_DEQUEUE:
> - enable = false;
> - break;
> - default:
> - dev_err(ippdrv->dev, "invalid buf ctrl parameter.\n");
> - ret =  -EINVAL;
> - goto err_unlock;
> - }
> + if (buf_type == IPP_BUF_ENQUEUE)
> + cfg |= (1 << buf_id);
> + else
> + cfg &= (1 << buf_id);

~ Missing?

>  
> - /* sequence id */
> - cfg &= ~mask;
> - cfg |= (enable << buf_id);
>   fimc_write(ctx, cfg, EXYNOS_CIFCNTSEQ);
>  
> - /* interrupt enable */
> - if (buf_type == IPP_BUF_ENQUEUE &&
> - fimc_dst_get_buf_count(ctx) >= FIMC_BUF_START)
> - fimc_mask_irq(ctx, true);
> + buf_num = hweight32(cfg);
>  
> - /* interrupt disable */
> - if (buf_type == IPP_BUF_DEQUEUE &&
> - fimc_dst_get_buf_count(ctx) <= FIMC_BUF_STOP)
> + if (buf_type == IPP_BUF_ENQUEUE && buf_num >= FIMC_BUF_START)
> + fimc_mask_irq(ctx, true);
> + else if (buf_type == IPP_BUF_DEQUEUE && buf_num <= FIMC_BUF_STOP)
>   fimc_mask_irq(ctx, false);
>  
> -err_unlock:
>   spin_unlock_irqrestore(>lock, flags);
> - return ret;
>  }
>  
>  static int fimc_dst_set_addr(struct device *dev,
> @@ -1242,7 +1209,9 @@ static int fimc_dst_set_addr(struct device *dev,
>   break;
>   }
>  
> - return fimc_dst_set_buf_seq(ctx, buf_id, buf_type);
> + fimc_dst_set_buf_seq(ctx, buf_id, buf_type);
> +
> + return 0;
>  }
>  
>  static struct exynos_drm_ipp_ops fimc_dst_ops = {
> @@ -1297,10 +1266,7 @@ static irqreturn_t fimc_irq_handler(int irq, void 
> *dev_id)
>  
>   DRM_DEBUG_KMS("buf_id[%d]\n", buf_id);
>  
> - if (fimc_dst_set_buf_seq(ctx, buf_id, IPP_BUF_DEQUEUE) < 0) {
> - DRM_ERROR("failed to dequeue.\n");
> - return IRQ_HANDLED;
> - }
> + fimc_dst_set_buf_seq(ctx, buf_id, IPP_BUF_DEQUEUE);
>  
>   event_work->ippdrv = ippdrv;
>   event_work->buf_id[EXYNOS_DRM_OPS_DST] = buf_id;
> 

--
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 06/15] drm/exynos/ipp: free partially allocated resources on error

[Joonyoung Shim]

Hi Andrzej,

On 08/22/2014 04:52 PM, Andrzej Hajda wrote:
> In case of allocation errors some already allocated buffers
> were not freed. The patch fixes it.
> 
> Signed-off-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_ipp.c | 68 
> -
>  1 file changed, 33 insertions(+), 35 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
> b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
> index 060a198..728f3b9 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
> @@ -599,6 +599,37 @@ static int ipp_set_mem_node(struct exynos_drm_ippdrv 
> *ippdrv,
>   return ret;
>  }
>  
> +static int ipp_put_mem_node(struct drm_device *drm_dev,
> + struct drm_exynos_ipp_cmd_node *c_node,
> + struct drm_exynos_ipp_mem_node *m_node)
> +{
> + int i;
> +
> + DRM_DEBUG_KMS("node[0x%x]\n", (int)m_node);
> +
> + if (!m_node) {
> + DRM_ERROR("invalid dequeue node.\n");
> + return -EFAULT;
> + }
> +
> + DRM_DEBUG_KMS("ops_id[%d]\n", m_node->ops_id);
> +
> + /* put gem buffer */
> + for_each_ipp_planar(i) {
> + unsigned long handle = m_node->buf_info.handles[i];
> + if (handle)
> + exynos_drm_gem_put_dma_addr(drm_dev, handle,
> + c_node->filp);
> + }
> +
> + /* conditionally remove from queue */
> + if (m_node->list.next)

How about do INIT_LIST_HEAD for list in ipp_get_mem_node()?

> + list_del(_node->list);
> + kfree(m_node);
> +
> + return 0;
> +}
> +
>  static struct drm_exynos_ipp_mem_node
>   *ipp_get_mem_node(struct drm_device *drm_dev,
>   struct drm_file *file,
> @@ -634,7 +665,8 @@ static struct drm_exynos_ipp_mem_node
>   qbuf->handle[i], file);
>   if (IS_ERR(addr)) {
>   DRM_ERROR("failed to get addr.\n");
> - goto err_clear;
> + ipp_put_mem_node(drm_dev, c_node, m_node);
> + return ERR_PTR(-EFAULT);
>   }
>  
>   buf_info->handles[i] = qbuf->handle[i];
> @@ -649,40 +681,6 @@ static struct drm_exynos_ipp_mem_node
>   mutex_unlock(_node->mem_lock);
>  
>   return m_node;
> -
> -err_clear:
> - kfree(m_node);
> - return ERR_PTR(-EFAULT);
> -}
> -
> -static int ipp_put_mem_node(struct drm_device *drm_dev,
> - struct drm_exynos_ipp_cmd_node *c_node,
> - struct drm_exynos_ipp_mem_node *m_node)
> -{
> - int i;
> -
> - DRM_DEBUG_KMS("node[0x%x]\n", (int)m_node);
> -
> - if (!m_node) {
> - DRM_ERROR("invalid dequeue node.\n");
> - return -EFAULT;
> - }
> -
> - DRM_DEBUG_KMS("ops_id[%d]\n", m_node->ops_id);
> -
> - /* put gem buffer */
> - for_each_ipp_planar(i) {
> - unsigned long handle = m_node->buf_info.handles[i];
> - if (handle)
> - exynos_drm_gem_put_dma_addr(drm_dev, handle,
> - c_node->filp);
> - }
> -
> - /* delete list in queue */
> - list_del(_node->list);
> - kfree(m_node);
> -
> - return 0;
>  }
>  
>  static void ipp_free_event(struct drm_pending_event *event)
> 

--
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 03/15] drm/exynos/ipp: move file reference from memory to command node

[Joonyoung Shim]

On 08/26/2014 11:55 AM, Joonyoung Shim wrote:
> Hi Andrzej,
> 
> On 08/22/2014 04:52 PM, Andrzej Hajda wrote:
>> Command node should contain file reference to distinguish commands
>> created by different processes.
>>
>> Signed-off-by: Andrzej Hajda 
>> ---
>>  drivers/gpu/drm/exynos/exynos_drm_ipp.c | 5 ++---
>>  drivers/gpu/drm/exynos/exynos_drm_ipp.h | 2 ++
>>  2 files changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
>> index 9770966..bbe9968 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
>> @@ -75,7 +75,6 @@ struct drm_exynos_ipp_mem_node {
>>  u32 prop_id;
>>  u32 buf_id;
>>  struct drm_exynos_ipp_buf_info  buf_info;
>> -struct drm_file *filp;
>>  };
>>  
>>  /*
>> @@ -448,6 +447,7 @@ int exynos_drm_ipp_set_property(struct drm_device 
>> *drm_dev, void *data,
>>  c_node->dev = dev;
>>  c_node->property = *property;
>>  c_node->state = IPP_STATE_IDLE;
>> +c_node->filp = file;
>>  
>>  c_node->start_work = ipp_create_cmd_work();
>>  if (IS_ERR(c_node->start_work)) {
>> @@ -645,7 +645,6 @@ static struct drm_exynos_ipp_mem_node
>>  }
>>  }
>>  
>> -m_node->filp = file;
>>  mutex_lock(_node->mem_lock);
>>  list_add_tail(_node->list, _node->mem_list[qbuf->ops_id]);
>>  mutex_unlock(_node->mem_lock);
>> @@ -677,7 +676,7 @@ static int ipp_put_mem_node(struct drm_device *drm_dev,
> 
> Then, could you remove file argument from exynos_drm_ipp_queue_buf() and
> ipp_get_event()?

sorry, i mean ipp_put_mem_node() instead of exynos_drm_ipp_queue_buf().

> 
>>  unsigned long handle = m_node->buf_info.handles[i];
>>  if (handle)
>>  exynos_drm_gem_put_dma_addr(drm_dev, handle,
>> -m_node->filp);
>> +c_node->filp);
>>  }
>>  
>>  /* delete list in queue */
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.h 
>> b/drivers/gpu/drm/exynos/exynos_drm_ipp.h
>> index 6f48d62..0311035 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_ipp.h
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.h
>> @@ -62,6 +62,7 @@ struct drm_exynos_ipp_cmd_work {
>>   * @stop_work: stop command work structure.
>>   * @event_work: event work structure.
>>   * @state: state of command node.
>> + * @filp: associated file pointer.
>>   */
>>  struct drm_exynos_ipp_cmd_node {
>>  struct device   *dev;
>> @@ -78,6 +79,7 @@ struct drm_exynos_ipp_cmd_node {
>>  struct drm_exynos_ipp_cmd_work *stop_work;
>>  struct drm_exynos_ipp_event_work *event_work;
>>  enum drm_exynos_ipp_state   state;
>> +struct drm_file *filp;
>>  };
>>  
>>  /*
>>
> 
> 

--
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/