Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend
Hello Tomasz, On 04/07/2015 11:28 PM, Tomasz Figa wrote: > > Looks good to me. You can consider this Acked-by, as long as Sylwester > is not opposed to this approach. > Thanks a lot, I've posted it as a proper patch now. > Best regards, > Tomasz > Best regards, Javier -- 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
[PATCH 1/1] clk: exynos5420: Restore GATE_BUS_TOP on suspend
Commit ae43b3289186 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power
Management support v12") added pm support for the pl330 dma driver but
it makes the clock for the Exynos5420 MDMA0 DMA controller to be gated
during suspend and this in turn makes its parent clock aclk266_g2d to
be gated. But the clock needs to be ungated prior suspend to allow the
system to be suspend and resumed correctly.
Add GATE_BUS_TOP register to the list of registers to be restored when
the system enters into a suspend state so aclk266_g2d will be ungated.
Thanks to Abhilash Kesavan for figuring out that this was the issue.
Fixes: ae43b32 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power Management
support v12")
Signed-off-by: Javier Martinez Canillas
Tested-by: Kevin Hilman
Tested-by: Abhilash Kesavan
Acked-by: Tomasz Figa
---
drivers/clk/samsung/clk-exynos5420.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index 07d666cc6a29..bea4a173eef5 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -271,6 +271,7 @@ static const struct samsung_clk_reg_dump
exynos5420_set_clksrc[] = {
{ .offset = SRC_MASK_PERIC0,.value = 0x1110, },
{ .offset = SRC_MASK_PERIC1,.value = 0x1100, },
{ .offset = SRC_MASK_ISP, .value = 0x1000, },
+ { .offset = GATE_BUS_TOP, .value = 0x, },
{ .offset = GATE_BUS_DISP1, .value = 0x, },
{ .offset = GATE_IP_PERIC, .value = 0x, },
};
--
2.1.4
--
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
Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend
Hi Javier,
On Tue, Apr 7, 2015 at 8:30 PM, Javier Martinez Canillas
wrote:
> Hello Abhilash,
>
> On 04/07/2015 04:38 PM, Abhilash Kesavan wrote:
>>>
>>> [0]
>>> From 78aa551ebcb9a4a7ae9d5581c33e0c0f19fe5ad6 Mon Sep 17 00:00:00 2001
>>> From: Javier Martinez Canillas
>>> Date: Tue, 7 Apr 2015 15:53:27 +0200
>>> Subject: [RFC PATCH] clk: exynos5420: Restore GATE_BUS_TOP on suspend
>>>
>>> Commit ae43b3289186 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power
>>> Management support v12") added pm support for the pl330 dma driver but
>>> it makes the clock for the Exynos5420 MDMA0 DMA controller to be gated
>>> during suspend and this in turn makes its parent clock aclk266_g2d to
>>> be gated. But the clock needs to be ungated prior suspend to allow the
>>> system to be suspend and resumed correctly.
>>>
>>> Add GATE_BUS_TOP register to the list of registers to be restored when
>>> the system enters into a suspend state so aclk266_g2d will be ungated.
>>>
>>> Thanks to Abhilash Kesavan for figuring out that this was the issue.
>>>
>>> Fixes: ae43b32 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power
>>> Management support v12")
>>> Signed-off-by: Javier Martinez Canillas
>>> ---
>>> drivers/clk/samsung/clk-exynos5420.c | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/clk/samsung/clk-exynos5420.c
>>> b/drivers/clk/samsung/clk-exynos5420.c
>>> index 07d666cc6a29..bea4a173eef5 100644
>>> --- a/drivers/clk/samsung/clk-exynos5420.c
>>> +++ b/drivers/clk/samsung/clk-exynos5420.c
>>> @@ -271,6 +271,7 @@ static const struct samsung_clk_reg_dump
>>> exynos5420_set_clksrc[] = {
>>> { .offset = SRC_MASK_PERIC0,.value = 0x1110, },
>>> { .offset = SRC_MASK_PERIC1,.value = 0x1100, },
>>> { .offset = SRC_MASK_ISP, .value = 0x1000, },
>>> + { .offset = GATE_BUS_TOP, .value = 0x, },
>>> { .offset = GATE_BUS_DISP1, .value = 0x, },
>>> { .offset = GATE_IP_PERIC, .value = 0x, },
>>> };
>>
>> While there could be a concern that we are ungating all the clocks in
>
> Yes, I mentioned that but OTOH it will be even more dangerous to gate
> clocks that should remain enabled so I used the register default values.
>
>> BUS_TOP, this looks like the least intrusive fix for the issue. Tested
>> this on Peach Pi, S2R works fine.
>>
>
> Thanks a lot for testing, does it mean I can add your Tested-by then when
> posting it as a proper patch? I'll wait for Tomasz to comment before though.
Tested-by: Abhilash Kesavan .
Abhilash
--
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
Re: [PATCH 1/1] ARM: dts: Add HS400 support for exynos5422-odroidxu3
Hi, Markus.
I have also tested on Odroid-xu3 board.
Acked-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
On 04/08/2015 12:33 AM, Markus Reichl wrote:
> Hi,
>
> the base patch in [0] has been applied now.
>
> My patch was meanwhile
>
> Tested-by: Anand Moon
>
>
> Am 31.03.2015 um 14:27 schrieb Markus Reichl:
>> Am 30.03.2015 um 17:51 schrieb Markus Reichl:
>>> HS400 timing values are added for exynos5422-odroidxu3 board.
>>> ---
>>> This patch is analog to [0].
>>> This patch needs [0] for the pin-ctrl definition of sd0_rclk.
>>>
>>> [0]:
>>> https://www.mail-archive.com/linux-samsung-soc%40vger.kernel.org/msg42902.html
>>>
>>> Signed-off-by: Markus Reichl
>>> ---
>>> arch/arm/boot/dts/exynos5422-odroidxu3.dts | 7 ++-
>>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
>>> b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
>>> index a519c86..0408ec0 100644
>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
>>> @@ -298,15 +298,20 @@
>>>
>>> &mmc_0 {
>>> status = "okay";
>>> + num-slots = <1>;
>>> broken-cd;
>>> card-detect-delay = <200>;
>>> samsung,dw-mshc-ciu-div = <3>;
>>> samsung,dw-mshc-sdr-timing = <0 4>;
>>> samsung,dw-mshc-ddr-timing = <0 2>;
>>> + samsung,dw-mshc-hs400-timing = <0 2>;
>>> + samsung,read-strobe-delay = <90>;
>>> pinctrl-names = "default";
>>> - pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus4 &sd0_bus8>;
>>> + pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus1 &sd0_bus4 &sd0_bus8 &sd0_rclk>;
>>> bus-width = <8>;
>>> cap-mmc-highspeed;
>>> + mmc-hs200-1_8v;
>>> + mmc-hs400-1_8v;
>>> };
>>>
>>> &mmc_2 {
>>>
>>
>> hdparm -t /dev/mmcblk0
>>
>> without this patch:
>> /dev/mmcblk0:
>> Timing buffered disk reads: 230 MB in 3.01 seconds = 76.30 MB/sec
>>
>> with this patch:
>> /dev/mmcblk0:
>> Timing buffered disk reads: 588 MB in 3.00 seconds = 195.92 MB/sec
>>
>> cat /sys/kernel/debug/mmc0/ios
>>
>> without patch:
>> clock: 5200 Hz
>> vdd:7 (1.65 - 1.95 V)
>> bus mode: 2 (push-pull)
>> chip select:0 (don't care)
>> power mode: 2 (on)
>> bus width: 3 (8 bits)
>> timing spec:8 (mmc DDR52)
>> signal voltage: 0 (1.80 V)
>>
>> with patch:
>> clock: 2 Hz
>> vdd:7 (1.65 - 1.95 V)
>> bus mode: 2 (push-pull)
>> chip select:0 (don't care)
>> power mode: 2 (on)
>> bus width: 3 (8 bits)
>> timing spec:10 (mmc HS400)
>> signal voltage: 0 (1.80 V)
>>
>> Best Regards
>>
>
>
--
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
Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend
2015-04-07 16:11 GMT+02:00 Javier Martinez Canillas
:
> From 78aa551ebcb9a4a7ae9d5581c33e0c0f19fe5ad6 Mon Sep 17 00:00:00 2001
> From: Javier Martinez Canillas
> Date: Tue, 7 Apr 2015 15:53:27 +0200
> Subject: [RFC PATCH] clk: exynos5420: Restore GATE_BUS_TOP on suspend
>
> Commit ae43b3289186 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power
> Management support v12") added pm support for the pl330 dma driver but
> it makes the clock for the Exynos5420 MDMA0 DMA controller to be gated
> during suspend and this in turn makes its parent clock aclk266_g2d to
> be gated. But the clock needs to be ungated prior suspend to allow the
> system to be suspend and resumed correctly.
>
> Add GATE_BUS_TOP register to the list of registers to be restored when
> the system enters into a suspend state so aclk266_g2d will be ungated.
>
> Thanks to Abhilash Kesavan for figuring out that this was the issue.
>
> Fixes: ae43b32 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power Management
> support v12")
> Signed-off-by: Javier Martinez Canillas
> ---
> drivers/clk/samsung/clk-exynos5420.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/clk/samsung/clk-exynos5420.c
> b/drivers/clk/samsung/clk-exynos5420.c
> index 07d666cc6a29..bea4a173eef5 100644
> --- a/drivers/clk/samsung/clk-exynos5420.c
> +++ b/drivers/clk/samsung/clk-exynos5420.c
> @@ -271,6 +271,7 @@ static const struct samsung_clk_reg_dump
> exynos5420_set_clksrc[] = {
> { .offset = SRC_MASK_PERIC0,.value = 0x1110, },
> { .offset = SRC_MASK_PERIC1,.value = 0x1100, },
> { .offset = SRC_MASK_ISP, .value = 0x1000, },
> + { .offset = GATE_BUS_TOP, .value = 0x, },
> { .offset = GATE_BUS_DISP1, .value = 0x, },
> { .offset = GATE_IP_PERIC, .value = 0x, },
> };
> --
> 2.1.4
Looks good to me. You can consider this Acked-by, as long as Sylwester
is not opposed to this approach.
Best regards,
Tomasz
--
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
[PATCH v4] drm/exynos: atomic dpms support
From: Gustavo Padovan
Run dpms operations through the atomic intefaces. This basically removes
the .dpms() callback from econders and crtcs and use .disable() and
.enable() to turn the crtc on and off.
v2: Address comments by Joonyoung:
- make hdmi code call ->disable() instead of ->dpms()
- do not use WARN_ON on crtc enable/disable
v3: - Fix build failure after the hdmi change in v2
- Change dpms helper of ptn3460 bridge
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/bridge/ptn3460.c| 2 +-
drivers/gpu/drm/exynos/exynos_dp_core.c | 2 +-
drivers/gpu/drm/exynos/exynos_drm_crtc.c| 99 -
drivers/gpu/drm/exynos/exynos_drm_dpi.c | 2 +-
drivers/gpu/drm/exynos/exynos_drm_drv.h | 4 +-
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 2 +-
drivers/gpu/drm/exynos/exynos_drm_encoder.c | 27 ++--
drivers/gpu/drm/exynos/exynos_drm_vidi.c| 2 +-
drivers/gpu/drm/exynos/exynos_hdmi.c| 6 +-
9 files changed, 70 insertions(+), 76 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ptn3460.c b/drivers/gpu/drm/bridge/ptn3460.c
index 30da10c..4d49454 100644
--- a/drivers/gpu/drm/bridge/ptn3460.c
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -260,7 +260,7 @@ static void ptn3460_connector_destroy(struct drm_connector
*connector)
}
static struct drm_connector_funcs ptn3460_connector_funcs = {
- .dpms = drm_helper_connector_dpms,
+ .dpms = drm_atomic_helper_connector_dpms,
.fill_modes = drm_helper_probe_single_connector_modes,
.detect = ptn3460_detect,
.destroy = ptn3460_connector_destroy,
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 59f2ca5..d468637 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -955,7 +955,7 @@ static void exynos_dp_connector_destroy(struct
drm_connector *connector)
}
static struct drm_connector_funcs exynos_dp_connector_funcs = {
- .dpms = drm_helper_connector_dpms,
+ .dpms = drm_atomic_helper_connector_dpms,
.fill_modes = drm_helper_probe_single_connector_modes,
.detect = exynos_dp_detect,
.destroy = exynos_dp_connector_destroy,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 0db7b91..519c569 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -22,51 +22,57 @@
#include "exynos_drm_encoder.h"
#include "exynos_drm_plane.h"
-static void exynos_drm_crtc_dpms(struct drm_crtc *crtc, int mode)
+static void exynos_drm_crtc_enable(struct drm_crtc *crtc)
{
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
+ struct exynos_drm_plane *exynos_plane = to_exynos_plane(crtc->primary);
- DRM_DEBUG_KMS("crtc[%d] mode[%d]\n", crtc->base.id, mode);
-
- if (exynos_crtc->dpms == mode) {
- DRM_DEBUG_KMS("desired dpms mode is same as previous one.\n");
+ if (exynos_crtc->enabled)
return;
- }
-
- if (mode > DRM_MODE_DPMS_ON) {
- /* wait for the completion of page flip. */
- if (!wait_event_timeout(exynos_crtc->pending_flip_queue,
- (exynos_crtc->event == NULL), HZ/20))
- exynos_crtc->event = NULL;
- drm_crtc_vblank_off(crtc);
- }
if (exynos_crtc->ops->dpms)
- exynos_crtc->ops->dpms(exynos_crtc, mode);
+ exynos_crtc->ops->dpms(exynos_crtc, DRM_MODE_DPMS_ON);
- exynos_crtc->dpms = mode;
+ exynos_crtc->enabled = true;
- if (mode == DRM_MODE_DPMS_ON)
- drm_crtc_vblank_on(crtc);
-}
+ drm_crtc_vblank_on(crtc);
-static void exynos_drm_crtc_prepare(struct drm_crtc *crtc)
-{
- /* drm framework doesn't check NULL. */
+ if (exynos_crtc->ops->win_commit)
+ exynos_crtc->ops->win_commit(exynos_crtc, exynos_plane->zpos);
+
+ if (exynos_crtc->ops->commit)
+ exynos_crtc->ops->commit(exynos_crtc);
}
-static void exynos_drm_crtc_commit(struct drm_crtc *crtc)
+static void exynos_drm_crtc_disable(struct drm_crtc *crtc)
{
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
- struct exynos_drm_plane *exynos_plane = to_exynos_plane(crtc->primary);
+ struct drm_plane *plane;
+ int ret;
+
+ if (!exynos_crtc->enabled)
+ return;
- exynos_drm_crtc_dpms(crtc, DRM_MODE_DPMS_ON);
+ /* wait for the completion of page flip. */
+ if (!wait_event_timeout(exynos_crtc->pending_flip_queue,
+ (exynos_crtc->event == NULL), HZ/20))
+ exynos_crtc->event = NULL;
- if (exynos_crtc->ops->win_commit)
- exynos_crtc->ops->win_commit(exynos_crtc, exynos_plane->zpos);
+ drm_crtc_vblank_off(crtc);
- if (exynos_crtc->ops-
Re: [PATCH -v3 00/11] drm/exynos: Add atomic modesetting support
I don't know if I can really help with this, but I'm going to try to reproduce this on my board tomorrow. With best wishes, Tobias Gustavo Padovan wrote: > Hi Inki, > > 2015-04-07 Inki Dae : > >> On 2015년 04월 07일 00:44, Inki Dae wrote: >>> 2015-04-06 19:46 GMT+09:00 Inki Dae : On 2015년 04월 04일 03:09, Gustavo Padovan wrote: > From: Gustavo Padovan > > Hi, > > Here goes the full support for atomic modesetting on exynos. I've > split the patches in the various phases of atomic support. > > These patches sits on top of the clean up patches I've sent yesterday > to this mailing list[1]. > > v2: fixes comments by Joonyoung > - remove unused var in patch 09 > - use ->disable instead of outdated ->dpms in hdmi code > - remove WARN_ON from crtc enable/disable > > v3: fixes comment by Joonyoung > - move the removal of drm_helper_disable_unused_functions() to > separated patch With this patch series, Kernel booting is halted at end of kernel booting. I tested this patch series on Trats2 board based on Exynos4412 SoC. Below is a part of full booting logs, which was halted, [1.992015] exynos-drm-ipp exynos-drm-ipp: drm ipp registered successfully. [1.993009] exynos-drm exynos-drm: bound exynos-drm-vidi (ops vidi_component_ops) [1.993036] exynos-drm exynos-drm: bound 11c0.fimd (ops fimd_component_ops) [1.993385] exynos-drm exynos-drm: bound 11c8.dsi (ops exynos_dsi_component_ops) [1.993390] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [1.993393] [drm] No driver support for vblank timestamp query. [1.993442] [drm] Initialized exynos 1.0.0 20110530 on minor 0 [2.043358] WARNING: CPU: 2 PID: 1209 at drivers/clk/clk.c:898 clk_unprepare+0x24/0x2c() [2.051412] Modules linked in: [2.054422] CPU: 2 PID: 1209 Comm: kworker/2:1 Tainted: GW 4.0.0-rc6-00526-gc49d7de-dirty #1278 [2.064337] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [2.070428] Workqueue: pm pm_runtime_work> After that, I tested it again without FIMD and the booting is ok. So I guess that this atomic feature has a bug to FIMD driver. >>> >>> More information, >>> >>> The reason the booting is halted is that a deadlock occurs at fbcon >>> module when register_framebuffer() is called. >>> >>> Below are our test results, >>> - with only cleanup series, FIMD and HDMI work well. >>> - with cleanup and atomic series, HDMI works well but FIMD doesn't >>> work - a deadlock occurs. >>> >>> Could anyone test it with the atomic series on trats2 board? You can >>> test it on top of exynos-drm-next-todo branch which contains all >>> relevant patches, >>> https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/log/?h=ynos-drm-next-todo >>> >>> Anyway, we will continue to take a look at the this issue why the >>> deadlock occurs. >> >> In addition, >> >> I added some codes temporarily to fbmem module which mitigates the >> deadlock issue. After that, I see below panic log, >> >> [3.254840] Unable to handle kernel NULL pointer dereference at >> virtual address 00a4 >> [3.262870] pgd =0004000 >> [3.265539] [00a4] *pgd[3.269102] Internal error: Oops: 5 [#1] >> PREEMPT SMP ARM >> [3.274392] Modules linked in: >> [3.277435] CPU: 2 PID: 1 Comm: swapper/0 Tainted: GW >> 4.0.0-rc6-00526-gc49d7de-dirty #1308 >> [3.286892] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) >> [3.292970] task: ee878000 ti: ee88 task.ti: ee88 >> [3.298356] PC is at exynos_plane_atomic_update+0x24/0x1d4 >> [3.303824] LR is at drm_atomic_helper_commit_planes+0xa4/0x18c >> [3.309723] pc : []lr : []psr: 6113 >> [3.309723] sp : ee881b38 ip : 0020 fp : >> [3.321179] r10: c04cfc00 r9 : 0008 r8 : eebfb9c0 >> [3.326387] r7 : 0002 r6 : r5 : r4 : ee925308 >> [3.332897] r3 : ee329fc0 r2 : r1 : r0 : ee925308 >> [3.339409] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM >> Segment kernel >> [3.346699] Control: 10c5387d Table: 4000404a DAC: 0015 >> [3.352427] Process swapper/0 (pid: 1, stack limit =xee880210) >> [3.358416] Stack: (0xee881b38 to 0xee882000) >> [3.362757] 1b20: >>c0726794 0008 >> [3.370919] 1b40: 0002 ee925308 ee329e00 0002 >> eebfb9c0 0008 c04cfc00 >> [3.379078] 1b60: c0265308 0008 ee329e00 >> ee0a8000 0008 >> [3.387237] 1b80: c0267304 ee329e00 ee8efe00 ee914c00 >> 0002 0002 >> [3.395396] 1ba0: c026609c c0265ef0 ee914c00 >> 0028 ee8eff00 0001 >> [3.403555] 1bc0: c06c8380 c02770d0 ee8efe00 >> 00
Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend
Javier Martinez Canillas writes:
[...]
> Yes, the following patch [0] is enough to make S2R working. If you think
> that is correct then I'll post it as a proper patch then.
[...]
> [0]
> From 78aa551ebcb9a4a7ae9d5581c33e0c0f19fe5ad6 Mon Sep 17 00:00:00 2001
> From: Javier Martinez Canillas
> Date: Tue, 7 Apr 2015 15:53:27 +0200
> Subject: [RFC PATCH] clk: exynos5420: Restore GATE_BUS_TOP on suspend
>
> Commit ae43b3289186 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power
> Management support v12") added pm support for the pl330 dma driver but
> it makes the clock for the Exynos5420 MDMA0 DMA controller to be gated
> during suspend and this in turn makes its parent clock aclk266_g2d to
> be gated. But the clock needs to be ungated prior suspend to allow the
> system to be suspend and resumed correctly.
>
> Add GATE_BUS_TOP register to the list of registers to be restored when
> the system enters into a suspend state so aclk266_g2d will be ungated.
>
> Thanks to Abhilash Kesavan for figuring out that this was the issue.
>
> Fixes: ae43b32 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power Management
> support v12")
> Signed-off-by: Javier Martinez Canillas
Tested-by: Kevin Hilman
on exynos5800-peach-pi
Kevin
--
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
Re: [PATCH -v3 00/11] drm/exynos: Add atomic modesetting support
Hi Inki, 2015-04-07 Inki Dae : > On 2015년 04월 07일 00:44, Inki Dae wrote: > > 2015-04-06 19:46 GMT+09:00 Inki Dae : > >> On 2015년 04월 04일 03:09, Gustavo Padovan wrote: > >>> From: Gustavo Padovan > >>> > >>> Hi, > >>> > >>> Here goes the full support for atomic modesetting on exynos. I've > >>> split the patches in the various phases of atomic support. > >>> > >>> These patches sits on top of the clean up patches I've sent yesterday > >>> to this mailing list[1]. > >>> > >>> v2: fixes comments by Joonyoung > >>> - remove unused var in patch 09 > >>> - use ->disable instead of outdated ->dpms in hdmi code > >>> - remove WARN_ON from crtc enable/disable > >>> > >>> v3: fixes comment by Joonyoung > >>> - move the removal of drm_helper_disable_unused_functions() to > >>> separated patch > >> > >> With this patch series, Kernel booting is halted at end of kernel > >> booting. I tested this patch series on Trats2 board based on Exynos4412 > >> SoC. > >> > >> Below is a part of full booting logs, which was halted, > >> [1.992015] exynos-drm-ipp exynos-drm-ipp: drm ipp registered > >> successfully. > >> [1.993009] exynos-drm exynos-drm: bound exynos-drm-vidi (ops > >> vidi_component_ops) > >> [1.993036] exynos-drm exynos-drm: bound 11c0.fimd (ops > >> fimd_component_ops) > >> [1.993385] exynos-drm exynos-drm: bound 11c8.dsi (ops > >> exynos_dsi_component_ops) > >> [1.993390] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > >> [1.993393] [drm] No driver support for vblank timestamp query. > >> [1.993442] [drm] Initialized exynos 1.0.0 20110530 on minor 0 > >> [2.043358] WARNING: CPU: 2 PID: 1209 at drivers/clk/clk.c:898 > >> clk_unprepare+0x24/0x2c() > >> [2.051412] Modules linked in: > >> [2.054422] CPU: 2 PID: 1209 Comm: kworker/2:1 Tainted: GW > >> 4.0.0-rc6-00526-gc49d7de-dirty #1278 > >> [2.064337] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) > >> [2.070428] Workqueue: pm pm_runtime_work> > >> > >> After that, I tested it again without FIMD and the booting is ok. So I > >> guess that this atomic feature has a bug to FIMD driver. > >> > > > > More information, > > > > The reason the booting is halted is that a deadlock occurs at fbcon > > module when register_framebuffer() is called. > > > > Below are our test results, > > - with only cleanup series, FIMD and HDMI work well. > > - with cleanup and atomic series, HDMI works well but FIMD doesn't > > work - a deadlock occurs. > > > > Could anyone test it with the atomic series on trats2 board? You can > > test it on top of exynos-drm-next-todo branch which contains all > > relevant patches, > > https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/log/?h=exynos-drm-next-todo > > > > Anyway, we will continue to take a look at the this issue why the > > deadlock occurs. > > In addition, > > I added some codes temporarily to fbmem module which mitigates the > deadlock issue. After that, I see below panic log, > > [3.254840] Unable to handle kernel NULL pointer dereference at > virtual address 00a4 > [3.262870] pgd = c0004000 > [3.265539] [00a4] *pgd= > [3.269102] Internal error: Oops: 5 [#1] PREEMPT SMP ARM > [3.274392] Modules linked in: > [3.277435] CPU: 2 PID: 1 Comm: swapper/0 Tainted: GW > 4.0.0-rc6-00526-gc49d7de-dirty #1308 > [3.286892] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) > [3.292970] task: ee878000 ti: ee88 task.ti: ee88 > [3.298356] PC is at exynos_plane_atomic_update+0x24/0x1d4 > [3.303824] LR is at drm_atomic_helper_commit_planes+0xa4/0x18c > [3.309723] pc : []lr : []psr: 6113 > [3.309723] sp : ee881b38 ip : 0020 fp : > [3.321179] r10: c04cfc00 r9 : 0008 r8 : eebfb9c0 > [3.326387] r7 : 0002 r6 : r5 : r4 : ee925308 > [3.332897] r3 : ee329fc0 r2 : r1 : r0 : ee925308 > [3.339409] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM > Segment kernel > [3.346699] Control: 10c5387d Table: 4000404a DAC: 0015 > [3.352427] Process swapper/0 (pid: 1, stack limit = 0xee880210) > [3.358416] Stack: (0xee881b38 to 0xee882000) > [3.362757] 1b20: >c0726794 0008 > [3.370919] 1b40: 0002 ee925308 ee329e00 0002 > eebfb9c0 0008 c04cfc00 > [3.379078] 1b60: c0265308 0008 ee329e00 > ee0a8000 0008 > [3.387237] 1b80: c0267304 ee329e00 ee8efe00 ee914c00 > 0002 0002 > [3.395396] 1ba0: c026609c c0265ef0 ee914c00 > 0028 ee8eff00 0001 > [3.403555] 1bc0: c06c8380 c02770d0 ee8efe00 > 0028 ee8eff00 > [3.411714] 1be0: 0001 c0267a2c ee0a8000 c0286214 ee8eff00 > ee8eff00 ee0a8000 > [3.419874] 1c00: c0722ad4 ee35e000 c0269900 > ee91
Re: [PATCH -v3 00/11] drm/exynos: Add atomic modesetting support
Hi Inki, 2015-04-07 Inki Dae : > On 2015년 04월 07일 16:06, Inki Dae wrote: > > On 2015년 04월 07일 00:44, Inki Dae wrote: > >> 2015-04-06 19:46 GMT+09:00 Inki Dae : > >>> On 2015년 04월 04일 03:09, Gustavo Padovan wrote: > From: Gustavo Padovan > > Hi, > > Here goes the full support for atomic modesetting on exynos. I've > split the patches in the various phases of atomic support. > > These patches sits on top of the clean up patches I've sent yesterday > to this mailing list[1]. > > v2: fixes comments by Joonyoung > - remove unused var in patch 09 > - use ->disable instead of outdated ->dpms in hdmi code > - remove WARN_ON from crtc enable/disable > > v3: fixes comment by Joonyoung > - move the removal of drm_helper_disable_unused_functions() to > separated patch > >>> > >>> With this patch series, Kernel booting is halted at end of kernel > >>> booting. I tested this patch series on Trats2 board based on Exynos4412 > >>> SoC. > >>> > >>> Below is a part of full booting logs, which was halted, > >>> [1.992015] exynos-drm-ipp exynos-drm-ipp: drm ipp registered > >>> successfully. > >>> [1.993009] exynos-drm exynos-drm: bound exynos-drm-vidi (ops > >>> vidi_component_ops) > >>> [1.993036] exynos-drm exynos-drm: bound 11c0.fimd (ops > >>> fimd_component_ops) > >>> [1.993385] exynos-drm exynos-drm: bound 11c8.dsi (ops > >>> exynos_dsi_component_ops) > >>> [1.993390] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > >>> [1.993393] [drm] No driver support for vblank timestamp query. > >>> [1.993442] [drm] Initialized exynos 1.0.0 20110530 on minor 0 > >>> [2.043358] WARNING: CPU: 2 PID: 1209 at drivers/clk/clk.c:898 > >>> clk_unprepare+0x24/0x2c() > >>> [2.051412] Modules linked in: > >>> [2.054422] CPU: 2 PID: 1209 Comm: kworker/2:1 Tainted: GW > >>> 4.0.0-rc6-00526-gc49d7de-dirty #1278 > >>> [2.064337] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) > >>> [2.070428] Workqueue: pm pm_runtime_work> > >>> > >>> After that, I tested it again without FIMD and the booting is ok. So I > >>> guess that this atomic feature has a bug to FIMD driver. > >>> > >> > >> More information, > >> > >> The reason the booting is halted is that a deadlock occurs at fbcon > >> module when register_framebuffer() is called. > >> > >> Below are our test results, > >> - with only cleanup series, FIMD and HDMI work well. > >> - with cleanup and atomic series, HDMI works well but FIMD doesn't > >> work - a deadlock occurs. > >> > >> Could anyone test it with the atomic series on trats2 board? You can > >> test it on top of exynos-drm-next-todo branch which contains all > >> relevant patches, > >> https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/log/?h=exynos-drm-next-todo > >> > >> Anyway, we will continue to take a look at the this issue why the > >> deadlock occurs. > > > > In addition, > > > > I added some codes temporarily to fbmem module which mitigates the > > deadlock issue. After that, I see below panic log, > > > > [3.254840] Unable to handle kernel NULL pointer dereference at > > virtual address 00a4 > > [3.262870] pgd = c0004000 > > [3.265539] [00a4] *pgd= > > [3.269102] Internal error: Oops: 5 [#1] PREEMPT SMP ARM > > [3.274392] Modules linked in: > > [3.277435] CPU: 2 PID: 1 Comm: swapper/0 Tainted: GW > > 4.0.0-rc6-00526-gc49d7de-dirty #1308 > > [3.286892] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) > > [3.292970] task: ee878000 ti: ee88 task.ti: ee88 > > [3.298356] PC is at exynos_plane_atomic_update+0x24/0x1d4 > > [3.303824] LR is at drm_atomic_helper_commit_planes+0xa4/0x18c > > [3.309723] pc : []lr : []psr: 6113 > > [3.309723] sp : ee881b38 ip : 0020 fp : > > [3.321179] r10: c04cfc00 r9 : 0008 r8 : eebfb9c0 > > [3.326387] r7 : 0002 r6 : r5 : r4 : ee925308 > > [3.332897] r3 : ee329fc0 r2 : r1 : r0 : ee925308 > > [3.339409] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM > > Segment kernel > > [3.346699] Control: 10c5387d Table: 4000404a DAC: 0015 > > [3.352427] Process swapper/0 (pid: 1, stack limit = 0xee880210) > > [3.358416] Stack: (0xee881b38 to 0xee882000) > > [3.362757] 1b20: > >c0726794 0008 > > [3.370919] 1b40: 0002 ee925308 ee329e00 0002 > > eebfb9c0 0008 c04cfc00 > > [3.379078] 1b60: c0265308 0008 ee329e00 > > ee0a8000 0008 > > [3.387237] 1b80: c0267304 ee329e00 ee8efe00 ee914c00 > > 0002 0002 > > [3.395396] 1ba0: c026609c c0265ef0 ee914c00 > > 0028 ee8eff00 0001 > > [3.403555] 1bc0: c06c8380 c02770d0 ee8efe00 > > 002
Re: [PATCH 1/1] ARM: dts: Add HS400 support for exynos5422-odroidxu3
Hi,
the base patch in [0] has been applied now.
My patch was meanwhile
Tested-by: Anand Moon
Am 31.03.2015 um 14:27 schrieb Markus Reichl:
> Am 30.03.2015 um 17:51 schrieb Markus Reichl:
>> HS400 timing values are added for exynos5422-odroidxu3 board.
>> ---
>> This patch is analog to [0].
>> This patch needs [0] for the pin-ctrl definition of sd0_rclk.
>>
>> [0]:
>> https://www.mail-archive.com/linux-samsung-soc%40vger.kernel.org/msg42902.html
>>
>> Signed-off-by: Markus Reichl
>> ---
>> arch/arm/boot/dts/exynos5422-odroidxu3.dts | 7 ++-
>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
>> b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
>> index a519c86..0408ec0 100644
>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
>> @@ -298,15 +298,20 @@
>>
>> &mmc_0 {
>> status = "okay";
>> +num-slots = <1>;
>> broken-cd;
>> card-detect-delay = <200>;
>> samsung,dw-mshc-ciu-div = <3>;
>> samsung,dw-mshc-sdr-timing = <0 4>;
>> samsung,dw-mshc-ddr-timing = <0 2>;
>> +samsung,dw-mshc-hs400-timing = <0 2>;
>> +samsung,read-strobe-delay = <90>;
>> pinctrl-names = "default";
>> -pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus4 &sd0_bus8>;
>> +pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus1 &sd0_bus4 &sd0_bus8 &sd0_rclk>;
>> bus-width = <8>;
>> cap-mmc-highspeed;
>> +mmc-hs200-1_8v;
>> +mmc-hs400-1_8v;
>> };
>>
>> &mmc_2 {
>>
>
> hdparm -t /dev/mmcblk0
>
> without this patch:
> /dev/mmcblk0:
> Timing buffered disk reads: 230 MB in 3.01 seconds = 76.30 MB/sec
>
> with this patch:
> /dev/mmcblk0:
> Timing buffered disk reads: 588 MB in 3.00 seconds = 195.92 MB/sec
>
> cat /sys/kernel/debug/mmc0/ios
>
> without patch:
> clock: 5200 Hz
> vdd:7 (1.65 - 1.95 V)
> bus mode: 2 (push-pull)
> chip select:0 (don't care)
> power mode: 2 (on)
> bus width: 3 (8 bits)
> timing spec:8 (mmc DDR52)
> signal voltage: 0 (1.80 V)
>
> with patch:
> clock: 2 Hz
> vdd:7 (1.65 - 1.95 V)
> bus mode: 2 (push-pull)
> chip select:0 (don't care)
> power mode: 2 (on)
> bus width: 3 (8 bits)
> timing spec:10 (mmc HS400)
> signal voltage: 0 (1.80 V)
>
> Best Regards
>
--
Markus Reichl
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 1/1] ARM: dts: Add keep-power-in-suspend to WiFi SDIO node for Peach Boards
Javier, On Tue, Apr 7, 2015 at 6:03 AM, Javier Martinez Canillas wrote: > The Marvell mwifiex driver prevents the system to enter into a suspend > state if the card power is not preserved during a suspend/resume cycle. > > So Suspend-to-RAM and Suspend-to-idle is failing on Exynos5800 Peach Pi > and Exynos5420 Peach Pit Chromebooks. > > Add the keep-power-in-suspend Power Management property to the SDIO/MMC > node so the mwifiex suspend handler doesn't fail and the system is able > to enter into a suspend state. > > Signed-off-by: Javier Martinez Canillas > --- > arch/arm/boot/dts/exynos5420-peach-pit.dts | 1 + > arch/arm/boot/dts/exynos5800-peach-pi.dts | 1 + > 2 files changed, 2 insertions(+) Reviewed-by: Doug Anderson -- 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
Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend
Hello Abhilash,
On 04/07/2015 04:38 PM, Abhilash Kesavan wrote:
>>
>> [0]
>> From 78aa551ebcb9a4a7ae9d5581c33e0c0f19fe5ad6 Mon Sep 17 00:00:00 2001
>> From: Javier Martinez Canillas
>> Date: Tue, 7 Apr 2015 15:53:27 +0200
>> Subject: [RFC PATCH] clk: exynos5420: Restore GATE_BUS_TOP on suspend
>>
>> Commit ae43b3289186 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power
>> Management support v12") added pm support for the pl330 dma driver but
>> it makes the clock for the Exynos5420 MDMA0 DMA controller to be gated
>> during suspend and this in turn makes its parent clock aclk266_g2d to
>> be gated. But the clock needs to be ungated prior suspend to allow the
>> system to be suspend and resumed correctly.
>>
>> Add GATE_BUS_TOP register to the list of registers to be restored when
>> the system enters into a suspend state so aclk266_g2d will be ungated.
>>
>> Thanks to Abhilash Kesavan for figuring out that this was the issue.
>>
>> Fixes: ae43b32 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power Management
>> support v12")
>> Signed-off-by: Javier Martinez Canillas
>> ---
>> drivers/clk/samsung/clk-exynos5420.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/clk/samsung/clk-exynos5420.c
>> b/drivers/clk/samsung/clk-exynos5420.c
>> index 07d666cc6a29..bea4a173eef5 100644
>> --- a/drivers/clk/samsung/clk-exynos5420.c
>> +++ b/drivers/clk/samsung/clk-exynos5420.c
>> @@ -271,6 +271,7 @@ static const struct samsung_clk_reg_dump
>> exynos5420_set_clksrc[] = {
>> { .offset = SRC_MASK_PERIC0,.value = 0x1110, },
>> { .offset = SRC_MASK_PERIC1,.value = 0x1100, },
>> { .offset = SRC_MASK_ISP, .value = 0x1000, },
>> + { .offset = GATE_BUS_TOP, .value = 0x, },
>> { .offset = GATE_BUS_DISP1, .value = 0x, },
>> { .offset = GATE_IP_PERIC, .value = 0x, },
>> };
>
> While there could be a concern that we are ungating all the clocks in
Yes, I mentioned that but OTOH it will be even more dangerous to gate
clocks that should remain enabled so I used the register default values.
> BUS_TOP, this looks like the least intrusive fix for the issue. Tested
> this on Peach Pi, S2R works fine.
>
Thanks a lot for testing, does it mean I can add your Tested-by then when
posting it as a proper patch? I'll wait for Tomasz to comment before though.
> Thanks,
> Abhilash
>
Best regards,
Javier
--
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
Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend
Hi Javier,
On Tue, Apr 7, 2015 at 7:41 PM, Javier Martinez Canillas
wrote:
> Hello Tomasz,
>
> On 04/07/2015 02:46 PM, Tomasz Figa wrote:
>> 2015-04-07 13:56 GMT+02:00 Javier Martinez Canillas
>> :
>>> So I disabled the sss clock before trying a S2R:
>>>
>>> # devmem 0x10018800 32 0xFFFB
>>> (CLK_SSS in CLK_GATE_IP_G2D is gated)
>>>
>>> and S2R worked anyways but I see that CLK_GATE_IP_G2D is reset to
>>> its default value on S2R so maybe that is why it works anyways?
>>
>> Does the driver restore its value on resume (i.e. has it in the
>> save/restore array)? Remember that suspend causes all clock registers
>> to be reset. Then some of them will be configured by the lowest
>
> No, GATE_IP_G2D is not in the exynos5x_gate_clks array so it looses
> the kernel after a suspend/resume cycle.
>
>> bootloader stage after wake-up reset, but the kernel needs to restore
>> all of them.
>>
>
> I see, thanks for the clarification. Then I think that is a bug and
> GATE_IP_G2D needs to be added to the list of clocks to be saved and
> restored right? That's a separate issue from our current S2R problem
> though so it can be done later as a separate patch.
>
>>>
>>> # devmem 0x10018800
>>> 0x (all CLK_GATE_IP_G2D clocks enabled including CLK_SSS)
>>>
>>> Does this shed any more light? Could the problem be that the sss
>>> clock parent (aclk266_g2d) is gated during S2R? Is the SSS module
>>> required for S2R or is just that CLK_SSS prevents the parent to
>>> be gated and so it is another red herring?
>>
>> Does the board use secure firmware? If yes, it might require to do
>> some encryption on suspend, so if the firmware is broken and doesn't
>> control the clock itself, it might need the SSS clock to be running,
>> when the SLEEP SMC operation is called.
>>
>
> No, the Chromebooks don't use secure firmware AFAIK.
>
>> Anyway, I just realized that Exynos4 also need several clocks to be
>> ungated on suspend and this is handled by code [1] based on arrays
>> [2].
>>
>> [1]
>> http://lxr.free-electrons.com/source/drivers/clk/samsung/clk-exynos4.c#L309
>> [2]
>> http://lxr.free-electrons.com/source/drivers/clk/samsung/clk-exynos4.c#L276
>>
>
> Yes I noticed that the Exynos5420 driver also does the same but did not
> want to do it there because I didn't know what value should had been used
> for all the other clocks in the CLK_GATE_BUS_TOP register. But if I get
> your explanation right, it is safe to do so since the register is going to
> be reset to its default values anyways.
>
>> Could this method work for your case as well? There would be no need
>> to call any clock API at all, just low level register writes, which is
>> okay, since this is a low level driver anyway.
>>
>
> Yes, the following patch [0] is enough to make S2R working. If you think
> that is correct then I'll post it as a proper patch then.
>
>> Best regards,
>> Tomasz
>>
>
> Best regards,
> Javier
>
> [0]
> From 78aa551ebcb9a4a7ae9d5581c33e0c0f19fe5ad6 Mon Sep 17 00:00:00 2001
> From: Javier Martinez Canillas
> Date: Tue, 7 Apr 2015 15:53:27 +0200
> Subject: [RFC PATCH] clk: exynos5420: Restore GATE_BUS_TOP on suspend
>
> Commit ae43b3289186 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power
> Management support v12") added pm support for the pl330 dma driver but
> it makes the clock for the Exynos5420 MDMA0 DMA controller to be gated
> during suspend and this in turn makes its parent clock aclk266_g2d to
> be gated. But the clock needs to be ungated prior suspend to allow the
> system to be suspend and resumed correctly.
>
> Add GATE_BUS_TOP register to the list of registers to be restored when
> the system enters into a suspend state so aclk266_g2d will be ungated.
>
> Thanks to Abhilash Kesavan for figuring out that this was the issue.
>
> Fixes: ae43b32 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power Management
> support v12")
> Signed-off-by: Javier Martinez Canillas
> ---
> drivers/clk/samsung/clk-exynos5420.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/clk/samsung/clk-exynos5420.c
> b/drivers/clk/samsung/clk-exynos5420.c
> index 07d666cc6a29..bea4a173eef5 100644
> --- a/drivers/clk/samsung/clk-exynos5420.c
> +++ b/drivers/clk/samsung/clk-exynos5420.c
> @@ -271,6 +271,7 @@ static const struct samsung_clk_reg_dump
> exynos5420_set_clksrc[] = {
> { .offset = SRC_MASK_PERIC0,.value = 0x1110, },
> { .offset = SRC_MASK_PERIC1,.value = 0x1100, },
> { .offset = SRC_MASK_ISP, .value = 0x1000, },
> + { .offset = GATE_BUS_TOP, .value = 0x, },
> { .offset = GATE_BUS_DISP1, .value = 0x, },
> { .offset = GATE_IP_PERIC, .value = 0x, },
> };
While there could be a concern that we are ungating all the clocks in
BUS_TOP, this looks like the least intrusive fix for the issue. Tested
this on Peach Pi, S2R works fine.
Thanks,
Abhilash
--
To unsubscribe from this lis
Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend
Hello Abhilash, On 04/07/2015 04:11 PM, Abhilash Kesavan wrote: > > Yes, though it increasingly looks like aclk266_g2d needs to stay ON > and we should use your patch that keeps it enabled prior to suspend. > Indeed, could you please give me some feedback on the latest RFC patch I shared [0] on this thread according to Tomasz comments? > Regards, > Abhilash >> Thanks a lot and best regards, Javier [0]: https://lkml.org/lkml/2015/4/7/537 -- 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
Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend
Hello Tomasz,
On 04/07/2015 02:46 PM, Tomasz Figa wrote:
> 2015-04-07 13:56 GMT+02:00 Javier Martinez Canillas
> :
>> So I disabled the sss clock before trying a S2R:
>>
>> # devmem 0x10018800 32 0xFFFB
>> (CLK_SSS in CLK_GATE_IP_G2D is gated)
>>
>> and S2R worked anyways but I see that CLK_GATE_IP_G2D is reset to
>> its default value on S2R so maybe that is why it works anyways?
>
> Does the driver restore its value on resume (i.e. has it in the
> save/restore array)? Remember that suspend causes all clock registers
> to be reset. Then some of them will be configured by the lowest
No, GATE_IP_G2D is not in the exynos5x_gate_clks array so it looses
the kernel after a suspend/resume cycle.
> bootloader stage after wake-up reset, but the kernel needs to restore
> all of them.
>
I see, thanks for the clarification. Then I think that is a bug and
GATE_IP_G2D needs to be added to the list of clocks to be saved and
restored right? That's a separate issue from our current S2R problem
though so it can be done later as a separate patch.
>>
>> # devmem 0x10018800
>> 0x (all CLK_GATE_IP_G2D clocks enabled including CLK_SSS)
>>
>> Does this shed any more light? Could the problem be that the sss
>> clock parent (aclk266_g2d) is gated during S2R? Is the SSS module
>> required for S2R or is just that CLK_SSS prevents the parent to
>> be gated and so it is another red herring?
>
> Does the board use secure firmware? If yes, it might require to do
> some encryption on suspend, so if the firmware is broken and doesn't
> control the clock itself, it might need the SSS clock to be running,
> when the SLEEP SMC operation is called.
>
No, the Chromebooks don't use secure firmware AFAIK.
> Anyway, I just realized that Exynos4 also need several clocks to be
> ungated on suspend and this is handled by code [1] based on arrays
> [2].
>
> [1]
> http://lxr.free-electrons.com/source/drivers/clk/samsung/clk-exynos4.c#L309
> [2]
> http://lxr.free-electrons.com/source/drivers/clk/samsung/clk-exynos4.c#L276
>
Yes I noticed that the Exynos5420 driver also does the same but did not
want to do it there because I didn't know what value should had been used
for all the other clocks in the CLK_GATE_BUS_TOP register. But if I get
your explanation right, it is safe to do so since the register is going to
be reset to its default values anyways.
> Could this method work for your case as well? There would be no need
> to call any clock API at all, just low level register writes, which is
> okay, since this is a low level driver anyway.
>
Yes, the following patch [0] is enough to make S2R working. If you think
that is correct then I'll post it as a proper patch then.
> Best regards,
> Tomasz
>
Best regards,
Javier
[0]
>From 78aa551ebcb9a4a7ae9d5581c33e0c0f19fe5ad6 Mon Sep 17 00:00:00 2001
From: Javier Martinez Canillas
Date: Tue, 7 Apr 2015 15:53:27 +0200
Subject: [RFC PATCH] clk: exynos5420: Restore GATE_BUS_TOP on suspend
Commit ae43b3289186 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power
Management support v12") added pm support for the pl330 dma driver but
it makes the clock for the Exynos5420 MDMA0 DMA controller to be gated
during suspend and this in turn makes its parent clock aclk266_g2d to
be gated. But the clock needs to be ungated prior suspend to allow the
system to be suspend and resumed correctly.
Add GATE_BUS_TOP register to the list of registers to be restored when
the system enters into a suspend state so aclk266_g2d will be ungated.
Thanks to Abhilash Kesavan for figuring out that this was the issue.
Fixes: ae43b32 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power Management
support v12")
Signed-off-by: Javier Martinez Canillas
---
drivers/clk/samsung/clk-exynos5420.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index 07d666cc6a29..bea4a173eef5 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -271,6 +271,7 @@ static const struct samsung_clk_reg_dump
exynos5420_set_clksrc[] = {
{ .offset = SRC_MASK_PERIC0,.value = 0x1110, },
{ .offset = SRC_MASK_PERIC1,.value = 0x1100, },
{ .offset = SRC_MASK_ISP, .value = 0x1000, },
+ { .offset = GATE_BUS_TOP, .value = 0x, },
{ .offset = GATE_BUS_DISP1, .value = 0x, },
{ .offset = GATE_IP_PERIC, .value = 0x, },
};
--
2.1.4
--
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
Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend
Hi Javier, On Tue, Apr 7, 2015 at 4:29 PM, Javier Martinez Canillas wrote: > Hello Abhilash, > > On 04/02/2015 02:22 PM, Abhilash Kesavan wrote: >> Hi, >> >> On Thu, Apr 2, 2015 at 4:01 AM, Javier Martinez Canillas >> wrote: >>> Hello Sylwester, >>> >>> On 04/01/2015 07:31 PM, Sylwester Nawrocki wrote: On 01/04/15 13:44, Javier Martinez Canillas wrote: > On 04/01/2015 01:03 PM, Sylwester Nawrocki wrote: >> It's not clear what subsystems affect state of the CG_STATUSx registers, >> it >> would be good if we could get more information on that. They are in the >> PMU >> block and are related to LPI (Low Power Interface handshaking), but what >> subsystems/peripheral blocks exactly are associated with them it's not >> clear >> from the documentation. > > Yes, I've been looking at the docs again and found out a couple of things: > > * Each GC_STATUSx register bit is associated with an IP hw block > * Some LPI_MASKx registers maps exactly with the GC_STATUSx (i.e: 0 and 1) > and others maps only partially (i.e: LPI_MASK2 and GC_STATUS2) The CG_STATUSx and LPI_MASKx bits meaning is not matching according to documentation I have. I guess you've got something newer than REV0.00? >>> >>> My Exynos5420 UM is Revision 1.00 dated February 2014 and GC_STATUS0 bits >>> maps LPI_MASK0 with the exception of bit 16 (NR3D) that is not mentioned >>> in GC_STATUS0, there is a hole between 15 (DIS) and 17 (FIMC_SCALERP). >>> >>> GC_STATUS1 maps exactly with LPI_MASK1 and GC_STATUS2 and LPI_MASK2 have >>> the same bits from 0 to 5 and then differ from there. >>> > So it is related to LPI as you said and both LPI_MASKx and GC_STATUSx are > part of the PMU register address space. > > In the particular case of aclk266_g2d, the doc says that the clock can > only > be gated when CG_STATUS0[20] and CG_STATUS0[21] are 0. These are > associated > with the SSS and SSS_SLIM respectively which AFAIU are crypto h/w modules. In my Exynos5420 UM ACLK_266_G2D is associated with CG_STATUS0 register bits 22, 21, which in turn correspond to NR3D and DIS IP blocks, i.e. the camera subsystem. Such a dependency would be rather surprising. >>> >>> Sorry, it was a typo error and I actually meant CG_STATUS0 21 and 22 but >>> these correspond in the documentation I've to 21 (SSS) and 22 (SSS_SLIM). >>> >>> As I mentioned before, DIS correspond to CG_STATUS0 15 and NR3D doesn't >>> have a corresponding bit in CG_STATUS0. But I don't know if that is an >>> error in the doc I've since is suspicious that is the only difference >>> between LPI_MASK0 and CG_STATUS0. >>> >> I think it's essential to understand what triggers changes in CG_STATUSx >> registers, before we start checking their value in the clock driver. >> > > Indeed, we should really understand what the status on these registers > means. Also is not clear from the docs how much time should be waited, > how long until giving up, etc. Exactly, I checked some kernels from http://opensource.samsung.com (e.g. SM-N900_JB_Opensource.zip) for CG_STATUSx, but I didn't find anything related to these registers yet, except the address macro definitions and debug traces in the power domains driver. >>> >>> Yes, I also looked in the ChromiumOS v3.8 kernel but didn't find anything. >>> >> Also it might be that there are indeed some clocks which must stay >> enabled >> over suspend/resume cycle, then the approach with enabling/disabling >> clocks >> in the clock driver might not be such a hack as it looks at first sight. >> > > Having a clock driver to both a provider and consumer feels hacky to me as > well but I didn't find a better way to solve this issue... another option > is to have this workaround to solve the S2R issue while we figure out what > the the state in the CG_STATUSx really mean. Let's try to diagnose the issue best we can, then we would choose the most accurate bug fix. >>> >>> Sounds good to me. >> >> Based on the earlier comments I was trying to isolate if: >> 1) s2r fails because we gate aclk266_g2d (but it is one of those >> clocks that needs to be always on prior to suspend). >> 2) s2r fails because we gate aclk266_g2d when CG_STATUS0[21:20] bits >> are not 0 (thus not following the spec). >> > > Thanks a lot for continue looking at this. I didn't have time to dig > deeper on this since last week. > >> As I did not have access to the hardware guys who could possibly >> confirm 1), I decided to >> a) find a configuration where CG_STATUS0 allows gating of the >> aclk266_g2d clock (i.e. CG_STATUS0[22:21] are 0). >> b) disable the aclk266_g2d clock using such a configuration. >> c) check s2r. >> >> I found a configuration [1] which gave the following after boot-up: > > I think you forgot the reference for [1] right? Since
Re: [PATCH v2 1/3] drm/exynos: fix typos in hdmi and mixer
On 2015년 04월 07일 08:14, Tobias Jakobi wrote:
> Use the correct spelling for 'progressive'.
1 through 3, Applied.
Thanks,
Inki Dae
>
> Reviewed-by: Gustavo Padovan
> Signed-off-by: Tobias Jakobi
> ---
> drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +-
> drivers/gpu/drm/exynos/exynos_mixer.c | 2 +-
> drivers/gpu/drm/exynos/regs-mixer.h | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index 3511fcc..20e2ce7 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -2022,7 +2022,7 @@ static void hdmi_mode_set(struct exynos_drm_display
> *display,
> DRM_DEBUG_KMS("xres=%d, yres=%d, refresh=%d, intl=%s\n",
> m->hdisplay, m->vdisplay,
> m->vrefresh, (m->flags & DRM_MODE_FLAG_INTERLACE) ?
> - "INTERLACED" : "PROGERESSIVE");
> + "INTERLACED" : "PROGRESSIVE");
>
> /* preserve mode information for later use. */
> drm_mode_copy(&hdata->current_mode, mode);
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index aa5b6e1..5ab0e32 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -267,7 +267,7 @@ static void mixer_cfg_scan(struct mixer_context *ctx,
> unsigned int height)
>
> /* choosing between interlace and progressive mode */
> val = (ctx->interlace ? MXR_CFG_SCAN_INTERLACE :
> - MXR_CFG_SCAN_PROGRASSIVE);
> + MXR_CFG_SCAN_PROGRESSIVE);
>
> if (ctx->mxr_ver != MXR_VER_128_0_0_184) {
> /* choosing between proper HD and SD mode */
> diff --git a/drivers/gpu/drm/exynos/regs-mixer.h
> b/drivers/gpu/drm/exynos/regs-mixer.h
> index 5f32e1a..ac60260 100644
> --- a/drivers/gpu/drm/exynos/regs-mixer.h
> +++ b/drivers/gpu/drm/exynos/regs-mixer.h
> @@ -101,7 +101,7 @@
> #define MXR_CFG_GRP0_ENABLE (1 << 4)
> #define MXR_CFG_VP_ENABLE(1 << 3)
> #define MXR_CFG_SCAN_INTERLACE (0 << 2)
> -#define MXR_CFG_SCAN_PROGRASSIVE (1 << 2)
> +#define MXR_CFG_SCAN_PROGRESSIVE (1 << 2)
> #define MXR_CFG_SCAN_NTSC(0 << 1)
> #define MXR_CFG_SCAN_PAL (1 << 1)
> #define MXR_CFG_SCAN_SD (0 << 0)
>
--
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
Re: [RFT PATCHv2] drm/exynos: Enable DP clock to fix display on Exynos5250 and other
On 2015년 03월 28일 01:08, Krzysztof Kozlowski wrote:
> After adding display power domain for Exynos5250 in commit
> 2d2c9a8d0a4f ("ARM: dts: add display power domain for exynos5250") the
> display on Chromebook Snow and others stopped working after boot.
>
> The reason for this suggested Andrzej Hajda: the DP clock was disabled.
> This clock is required by Display Port and is enabled by bootloader.
> However when FIMD driver probing was deferred, the display power domain
> was turned off. This effectively reset the value of DP clock enable
> register.
Applied.
Thanks,
Inki Dae
>
> When exynos-dp is later probed, the clock is not enabled and display is
> not properly configured:
>
> exynos-dp 145b.dp-controller: Timeout of video streamclk ok
> exynos-dp 145b.dp-controller: unable to config video
>
> Signed-off-by: Krzysztof Kozlowski
> Reported-by: Javier Martinez Canillas
> Fixes: 2d2c9a8d0a4f ("ARM: dts: add display power domain for exynos5250")
> Cc:
>
> ---
>
> This should fix issue reported by Javier [1][2].
>
> Tested on Chromebook Snow (Exynos 5250). More testing would be great,
> especially on other Exynos 5xxx products.
>
> [1] http://thread.gmane.org/gmane.linux.kernel.samsung-soc/43889
> [2] http://thread.gmane.org/gmane.linux.ports.arm.kernel/400290
>
> Changes since v1:
> 1. Added missing exynos_drm_fimd.h.
> ---
> drivers/gpu/drm/exynos/exynos_dp_core.c | 10 ++
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 19 +++
> drivers/gpu/drm/exynos/exynos_drm_fimd.h | 15 +++
> include/video/samsung_fimd.h | 6 ++
> 4 files changed, 50 insertions(+)
> create mode 100644 drivers/gpu/drm/exynos/exynos_drm_fimd.h
>
> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
> b/drivers/gpu/drm/exynos/exynos_dp_core.c
> index bf17a60b40ed..1dbfba58f909 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
> @@ -32,10 +32,16 @@
> #include
>
> #include "exynos_dp_core.h"
> +#include "exynos_drm_fimd.h"
>
> #define ctx_from_connector(c)container_of(c, struct
> exynos_dp_device, \
> connector)
>
> +static inline struct exynos_drm_crtc *dp_to_crtc(struct exynos_dp_device *dp)
> +{
> + return to_exynos_crtc(dp->encoder->crtc);
> +}
> +
> static inline struct exynos_dp_device *
> display_to_dp(struct exynos_drm_display *d)
> {
> @@ -1070,6 +1076,8 @@ static void exynos_dp_poweron(struct exynos_dp_device
> *dp)
> }
> }
>
> + fimd_dp_clock_enable(dp_to_crtc(dp), true);
> +
> clk_prepare_enable(dp->clock);
> exynos_dp_phy_init(dp);
> exynos_dp_init_dp(dp);
> @@ -1094,6 +1102,8 @@ static void exynos_dp_poweroff(struct exynos_dp_device
> *dp)
> exynos_dp_phy_exit(dp);
> clk_disable_unprepare(dp->clock);
>
> + fimd_dp_clock_enable(dp_to_crtc(dp), false);
> +
> if (dp->panel) {
> if (drm_panel_unprepare(dp->panel))
> DRM_ERROR("failed to turnoff the panel\n");
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index c300e22da8ac..bdf0818dc8f5 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -32,6 +32,7 @@
> #include "exynos_drm_fbdev.h"
> #include "exynos_drm_crtc.h"
> #include "exynos_drm_iommu.h"
> +#include "exynos_drm_fimd.h"
>
> /*
> * FIMD stands for Fully Interactive Mobile Display and
> @@ -1231,6 +1232,24 @@ static int fimd_remove(struct platform_device *pdev)
> return 0;
> }
>
> +void fimd_dp_clock_enable(struct exynos_drm_crtc *crtc, bool enable)
> +{
> + struct fimd_context *ctx = crtc->ctx;
> + u32 val;
> +
> + /*
> + * Only Exynos 5250, 5260, 5410 and 542x requires enabling DP/MIE
> + * clock. On these SoCs the bootloader may enable it but any
> + * power domain off/on will reset it to disable state.
> + */
> + if (ctx->driver_data != &exynos5_fimd_driver_data)
> + return;
> +
> + val = enable ? DP_MIE_CLK_DP_ENABLE : DP_MIE_CLK_DISABLE;
> + writel(DP_MIE_CLK_DP_ENABLE, ctx->regs + DP_MIE_CLKCON);
> +}
> +EXPORT_SYMBOL_GPL(fimd_dp_clock_enable);
> +
> struct platform_driver fimd_driver = {
> .probe = fimd_probe,
> .remove = fimd_remove,
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.h
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.h
> new file mode 100644
> index ..b4fcaa568456
> --- /dev/null
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.h
> @@ -0,0 +1,15 @@
> +/*
> + * Copyright (c) 2015 Samsung Electronics Co., Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the License, or (at your
> + * option) any later version.
[PATCH 1/1] ARM: dts: Add keep-power-in-suspend to WiFi SDIO node for Peach Boards
The Marvell mwifiex driver prevents the system to enter into a suspend state if the card power is not preserved during a suspend/resume cycle. So Suspend-to-RAM and Suspend-to-idle is failing on Exynos5800 Peach Pi and Exynos5420 Peach Pit Chromebooks. Add the keep-power-in-suspend Power Management property to the SDIO/MMC node so the mwifiex suspend handler doesn't fail and the system is able to enter into a suspend state. Signed-off-by: Javier Martinez Canillas --- arch/arm/boot/dts/exynos5420-peach-pit.dts | 1 + arch/arm/boot/dts/exynos5800-peach-pi.dts | 1 + 2 files changed, 2 insertions(+) diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts b/arch/arm/boot/dts/exynos5420-peach-pit.dts index 0788d08fb43e..146e71118a72 100644 --- a/arch/arm/boot/dts/exynos5420-peach-pit.dts +++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts @@ -711,6 +711,7 @@ num-slots = <1>; broken-cd; cap-sdio-irq; + keep-power-in-suspend; card-detect-delay = <200>; clock-frequency = <4>; samsung,dw-mshc-ciu-div = <1>; diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts b/arch/arm/boot/dts/exynos5800-peach-pi.dts index 412f41d62686..02eb8b15374f 100644 --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts @@ -674,6 +674,7 @@ num-slots = <1>; broken-cd; cap-sdio-irq; + keep-power-in-suspend; card-detect-delay = <200>; clock-frequency = <4>; samsung,dw-mshc-ciu-div = <1>; -- 2.1.4 -- 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
Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend
2015-04-07 13:56 GMT+02:00 Javier Martinez Canillas : > So I disabled the sss clock before trying a S2R: > > # devmem 0x10018800 32 0xFFFB > (CLK_SSS in CLK_GATE_IP_G2D is gated) > > and S2R worked anyways but I see that CLK_GATE_IP_G2D is reset to > its default value on S2R so maybe that is why it works anyways? Does the driver restore its value on resume (i.e. has it in the save/restore array)? Remember that suspend causes all clock registers to be reset. Then some of them will be configured by the lowest bootloader stage after wake-up reset, but the kernel needs to restore all of them. > > # devmem 0x10018800 > 0x (all CLK_GATE_IP_G2D clocks enabled including CLK_SSS) > > Does this shed any more light? Could the problem be that the sss > clock parent (aclk266_g2d) is gated during S2R? Is the SSS module > required for S2R or is just that CLK_SSS prevents the parent to > be gated and so it is another red herring? Does the board use secure firmware? If yes, it might require to do some encryption on suspend, so if the firmware is broken and doesn't control the clock itself, it might need the SSS clock to be running, when the SLEEP SMC operation is called. Anyway, I just realized that Exynos4 also need several clocks to be ungated on suspend and this is handled by code [1] based on arrays [2]. [1] http://lxr.free-electrons.com/source/drivers/clk/samsung/clk-exynos4.c#L309 [2] http://lxr.free-electrons.com/source/drivers/clk/samsung/clk-exynos4.c#L276 Could this method work for your case as well? There would be no need to call any clock API at all, just low level register writes, which is okay, since this is a low level driver anyway. Best regards, Tomasz -- 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
Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend
On 04/07/2015 12:59 PM, Javier Martinez Canillas wrote: > > So IIUC the CG_STATUS0 bits were a red herring and the real problem > is that the aclk266_g2d needs to be enabled during suspend (although > we still don't know why). > > It seems were are at a dead end now. Without being able to ask the HW > Samsung folks we would never know what's going on here... > Ok, I found another interesting data point. ACLK_266_G2D has as constraints that CG_STATUS0[21:22] needs to be 0 before gating the clock and as I mentioned before those are associated with the SSS and SSS_SLIM HW crypto modules according the docs I've. So I looked at the clock used by the SSS module and found that CLK_SSS parent is ACLK_266_G2D but CLK_SSS is never requested since drivers/crypto/s5p-sss.c isn't built for exynos_defconfig. Enabling CONFIG_CRYPTO_DEV_S5P makes the system to resume without any patches since the sss clock prevents aclk266_g2d to be gated. But I wanted to know if it was really aclk266_g2d that was needed or the actual sss clock since the kernel didn't manage that clock without the driver enabled. So I disabled the sss clock before trying a S2R: # devmem 0x10018800 32 0xFFFB (CLK_SSS in CLK_GATE_IP_G2D is gated) and S2R worked anyways but I see that CLK_GATE_IP_G2D is reset to its default value on S2R so maybe that is why it works anyways? # devmem 0x10018800 0x (all CLK_GATE_IP_G2D clocks enabled including CLK_SSS) Does this shed any more light? Could the problem be that the sss clock parent (aclk266_g2d) is gated during S2R? Is the SSS module required for S2R or is just that CLK_SSS prevents the parent to be gated and so it is another red herring? Best regards, Javier -- 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
Re: [PATCH] drm/exynos/ipp: Validate buffer enqueue requests
On 2015년 03월 04일 23:02, Marek Szyprowski wrote:
> From: Beata Michalska
>
> As for now there is no validation of incoming buffer
> enqueue request as far as the gem buffers are being
> concerned. This might lead to some undesired cases
> when the driver tries to operate on invalid buffers
> (wiht no valid gem object handle i.e.).
> Add some basic checks to rule out those potential issues.
Applied.
Thanks,
Inki Dae
>
> Signed-off-by: Beata Michalska
> [mszyprow: rebased onto v4.0-rc1 and adapted to recent ipp changes]
> Signed-off-by: Marek Szyprowski
> ---
> drivers/gpu/drm/exynos/exynos_drm_ipp.c | 44
> +
> 1 file changed, 44 insertions(+)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
> b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
> index 12ae9c4..ac35625 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
> @@ -476,6 +476,45 @@ err_clear:
> return ret;
> }
>
> +static int ipp_validate_mem_node(struct drm_device *drm_dev,
> + struct drm_exynos_ipp_mem_node *m_node,
> + struct drm_exynos_ipp_cmd_node *c_node)
> +{
> + struct drm_exynos_ipp_config *ipp_cfg;
> + unsigned int num_plane;
> + unsigned long min_size, size;
> + unsigned int bpp;
> + int i;
> +
> + /* The property id should already be varified */
> + ipp_cfg = &c_node->property.config[m_node->prop_id];
> + num_plane = drm_format_num_planes(ipp_cfg->fmt);
> +
> + /**
> + * This is a rather simplified validation of a memory node.
> + * It basically verifies provided gem object handles
> + * and the buffer sizes with respect to current configuration.
> + * This is not the best that can be done
> + * but it seems more than enough
> + */
> + for (i = 0; i < num_plane; ++i) {
> + if (!m_node->buf_info.handles[i]) {
> + DRM_ERROR("invalid handle for plane %d\n", i);
> + return -EINVAL;
> + }
> + bpp = drm_format_plane_cpp(ipp_cfg->fmt, i);
> + min_size = (ipp_cfg->sz.hsize * ipp_cfg->sz.vsize * bpp) >> 3;
> + size = exynos_drm_gem_get_size(drm_dev,
> +m_node->buf_info.handles[i],
> +c_node->filp);
> + if (min_size > size) {
> + DRM_ERROR("invalid size for plane %d\n", i);
> + return -EINVAL;
> + }
> + }
> + return 0;
> +}
> +
> 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)
> @@ -552,6 +591,11 @@ static struct drm_exynos_ipp_mem_node
> }
>
> mutex_lock(&c_node->mem_lock);
> + if (ipp_validate_mem_node(drm_dev, m_node, c_node)) {
> + ipp_put_mem_node(drm_dev, c_node, m_node);
> + mutex_unlock(&c_node->mem_lock);
> + return ERR_PTR(-EFAULT);
> + }
> list_add_tail(&m_node->list, &c_node->mem_list[qbuf->ops_id]);
> mutex_unlock(&c_node->mem_lock);
>
>
--
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
Re: [PATCH -v3 00/11] drm/exynos: Add atomic modesetting support
On 2015년 04월 07일 16:06, Inki Dae wrote: > On 2015년 04월 07일 00:44, Inki Dae wrote: >> 2015-04-06 19:46 GMT+09:00 Inki Dae : >>> On 2015년 04월 04일 03:09, Gustavo Padovan wrote: From: Gustavo Padovan Hi, Here goes the full support for atomic modesetting on exynos. I've split the patches in the various phases of atomic support. These patches sits on top of the clean up patches I've sent yesterday to this mailing list[1]. v2: fixes comments by Joonyoung - remove unused var in patch 09 - use ->disable instead of outdated ->dpms in hdmi code - remove WARN_ON from crtc enable/disable v3: fixes comment by Joonyoung - move the removal of drm_helper_disable_unused_functions() to separated patch >>> >>> With this patch series, Kernel booting is halted at end of kernel >>> booting. I tested this patch series on Trats2 board based on Exynos4412 SoC. >>> >>> Below is a part of full booting logs, which was halted, >>> [1.992015] exynos-drm-ipp exynos-drm-ipp: drm ipp registered >>> successfully. >>> [1.993009] exynos-drm exynos-drm: bound exynos-drm-vidi (ops >>> vidi_component_ops) >>> [1.993036] exynos-drm exynos-drm: bound 11c0.fimd (ops >>> fimd_component_ops) >>> [1.993385] exynos-drm exynos-drm: bound 11c8.dsi (ops >>> exynos_dsi_component_ops) >>> [1.993390] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). >>> [1.993393] [drm] No driver support for vblank timestamp query. >>> [1.993442] [drm] Initialized exynos 1.0.0 20110530 on minor 0 >>> [2.043358] WARNING: CPU: 2 PID: 1209 at drivers/clk/clk.c:898 >>> clk_unprepare+0x24/0x2c() >>> [2.051412] Modules linked in: >>> [2.054422] CPU: 2 PID: 1209 Comm: kworker/2:1 Tainted: GW >>> 4.0.0-rc6-00526-gc49d7de-dirty #1278 >>> [2.064337] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) >>> [2.070428] Workqueue: pm pm_runtime_work> >>> >>> After that, I tested it again without FIMD and the booting is ok. So I >>> guess that this atomic feature has a bug to FIMD driver. >>> >> >> More information, >> >> The reason the booting is halted is that a deadlock occurs at fbcon >> module when register_framebuffer() is called. >> >> Below are our test results, >> - with only cleanup series, FIMD and HDMI work well. >> - with cleanup and atomic series, HDMI works well but FIMD doesn't >> work - a deadlock occurs. >> >> Could anyone test it with the atomic series on trats2 board? You can >> test it on top of exynos-drm-next-todo branch which contains all >> relevant patches, >> https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/log/?h=exynos-drm-next-todo >> >> Anyway, we will continue to take a look at the this issue why the >> deadlock occurs. > > In addition, > > I added some codes temporarily to fbmem module which mitigates the > deadlock issue. After that, I see below panic log, > > [3.254840] Unable to handle kernel NULL pointer dereference at > virtual address 00a4 > [3.262870] pgd = c0004000 > [3.265539] [00a4] *pgd= > [3.269102] Internal error: Oops: 5 [#1] PREEMPT SMP ARM > [3.274392] Modules linked in: > [3.277435] CPU: 2 PID: 1 Comm: swapper/0 Tainted: GW > 4.0.0-rc6-00526-gc49d7de-dirty #1308 > [3.286892] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) > [3.292970] task: ee878000 ti: ee88 task.ti: ee88 > [3.298356] PC is at exynos_plane_atomic_update+0x24/0x1d4 > [3.303824] LR is at drm_atomic_helper_commit_planes+0xa4/0x18c > [3.309723] pc : []lr : []psr: 6113 > [3.309723] sp : ee881b38 ip : 0020 fp : > [3.321179] r10: c04cfc00 r9 : 0008 r8 : eebfb9c0 > [3.326387] r7 : 0002 r6 : r5 : r4 : ee925308 > [3.332897] r3 : ee329fc0 r2 : r1 : r0 : ee925308 > [3.339409] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM > Segment kernel > [3.346699] Control: 10c5387d Table: 4000404a DAC: 0015 > [3.352427] Process swapper/0 (pid: 1, stack limit = 0xee880210) > [3.358416] Stack: (0xee881b38 to 0xee882000) > [3.362757] 1b20: >c0726794 0008 > [3.370919] 1b40: 0002 ee925308 ee329e00 0002 > eebfb9c0 0008 c04cfc00 > [3.379078] 1b60: c0265308 0008 ee329e00 > ee0a8000 0008 > [3.387237] 1b80: c0267304 ee329e00 ee8efe00 ee914c00 > 0002 0002 > [3.395396] 1ba0: c026609c c0265ef0 ee914c00 > 0028 ee8eff00 0001 > [3.403555] 1bc0: c06c8380 c02770d0 ee8efe00 > 0028 ee8eff00 > [3.411714] 1be0: 0001 c0267a2c ee0a8000 c0286214 ee8eff00 > ee8eff00 ee0a8000 > [3.419874] 1c00: c0722ad4 ee35e000 c0269900 > ee915400 c0269958 > [3.428033] 1c20: ee808c00 c020cc8c c0248
Re: [RFC PATCH v3 2/2] clk: exynos5420: Make sure MDMA0 clock is enabled during suspend
Hello Abhilash, On 04/02/2015 02:22 PM, Abhilash Kesavan wrote: > Hi, > > On Thu, Apr 2, 2015 at 4:01 AM, Javier Martinez Canillas > wrote: >> Hello Sylwester, >> >> On 04/01/2015 07:31 PM, Sylwester Nawrocki wrote: >>> On 01/04/15 13:44, Javier Martinez Canillas wrote: On 04/01/2015 01:03 PM, Sylwester Nawrocki wrote: > It's not clear what subsystems affect state of the CG_STATUSx registers, > it > would be good if we could get more information on that. They are in the > PMU > block and are related to LPI (Low Power Interface handshaking), but what > subsystems/peripheral blocks exactly are associated with them it's not > clear > from the documentation. Yes, I've been looking at the docs again and found out a couple of things: * Each GC_STATUSx register bit is associated with an IP hw block * Some LPI_MASKx registers maps exactly with the GC_STATUSx (i.e: 0 and 1) and others maps only partially (i.e: LPI_MASK2 and GC_STATUS2) >>> >>> The CG_STATUSx and LPI_MASKx bits meaning is not matching according to >>> documentation I have. I guess you've got something newer than REV0.00? >>> >> >> My Exynos5420 UM is Revision 1.00 dated February 2014 and GC_STATUS0 bits >> maps LPI_MASK0 with the exception of bit 16 (NR3D) that is not mentioned >> in GC_STATUS0, there is a hole between 15 (DIS) and 17 (FIMC_SCALERP). >> >> GC_STATUS1 maps exactly with LPI_MASK1 and GC_STATUS2 and LPI_MASK2 have >> the same bits from 0 to 5 and then differ from there. >> So it is related to LPI as you said and both LPI_MASKx and GC_STATUSx are part of the PMU register address space. In the particular case of aclk266_g2d, the doc says that the clock can only be gated when CG_STATUS0[20] and CG_STATUS0[21] are 0. These are associated with the SSS and SSS_SLIM respectively which AFAIU are crypto h/w modules. >>> >>> In my Exynos5420 UM ACLK_266_G2D is associated with CG_STATUS0 register >>> bits 22, 21, which in turn correspond to NR3D and DIS IP blocks, i.e. >>> the camera subsystem. Such a dependency would be rather surprising. >>> >> >> Sorry, it was a typo error and I actually meant CG_STATUS0 21 and 22 but >> these correspond in the documentation I've to 21 (SSS) and 22 (SSS_SLIM). >> >> As I mentioned before, DIS correspond to CG_STATUS0 15 and NR3D doesn't >> have a corresponding bit in CG_STATUS0. But I don't know if that is an >> error in the doc I've since is suspicious that is the only difference >> between LPI_MASK0 and CG_STATUS0. >> > I think it's essential to understand what triggers changes in CG_STATUSx > registers, before we start checking their value in the clock driver. > Indeed, we should really understand what the status on these registers means. Also is not clear from the docs how much time should be waited, how long until giving up, etc. >>> >>> Exactly, I checked some kernels from http://opensource.samsung.com >>> (e.g. SM-N900_JB_Opensource.zip) for CG_STATUSx, but I didn't find anything >>> related to these registers yet, except the address macro definitions >>> and debug traces in the power domains driver. >>> >> >> Yes, I also looked in the ChromiumOS v3.8 kernel but didn't find anything. >> > Also it might be that there are indeed some clocks which must stay enabled > over suspend/resume cycle, then the approach with enabling/disabling > clocks > in the clock driver might not be such a hack as it looks at first sight. > Having a clock driver to both a provider and consumer feels hacky to me as well but I didn't find a better way to solve this issue... another option is to have this workaround to solve the S2R issue while we figure out what the the state in the CG_STATUSx really mean. >>> >>> Let's try to diagnose the issue best we can, then we would choose the most >>> accurate bug fix. >>> >> >> Sounds good to me. > > Based on the earlier comments I was trying to isolate if: > 1) s2r fails because we gate aclk266_g2d (but it is one of those > clocks that needs to be always on prior to suspend). > 2) s2r fails because we gate aclk266_g2d when CG_STATUS0[21:20] bits > are not 0 (thus not following the spec). > Thanks a lot for continue looking at this. I didn't have time to dig deeper on this since last week. > As I did not have access to the hardware guys who could possibly > confirm 1), I decided to > a) find a configuration where CG_STATUS0 allows gating of the > aclk266_g2d clock (i.e. CG_STATUS0[22:21] are 0). > b) disable the aclk266_g2d clock using such a configuration. > c) check s2r. > > I found a configuration [1] which gave the following after boot-up: I think you forgot the reference for [1] right? Since with latest linux-next (20150402) I got: > # devmem 0x10040914 > 0xFD800014 (CG_STATUS0[22:21] is 0) # devmem 0x10040914 0xFFE0 (CG_STATUS0[22:21] is 1) > # devmem 0x10020700 > 0xC6F8DE9F (aclk266_g2d is
Re: [PATCH v7 1/9] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
> >>> I'm very worried about adding a DT that's known broken, especially when
> >>> we have no idea as to if/when the FW will be fixed judging from prior
> >>> replies.
> >>
> >> As I replied, I can not fix the FW because I don't have any code of FW.
> >
> > Surely you are able to contact those who do?
> >
> >> I don't have any solution to fix it on Linux kernel level.
> >>
> >> So, If you agree, I can add the comment of CPU0 hotplug issue on DT file.
> >
> > I disagree. I do not want to add a DT that is known to be broken;
> > especially when we have no idea how to fix it. It creates long-term
> > maintenance pain for everyone, and marginal gain for few. A comment does
> > nothing to aid the end-user.
> >
> > So NAK to the PSCI node and PSCI enable method in this dts until we
> > either have a working firmware, or a reasonable mechanism to handle the
> > deficiency.
>
> There is only CPU0 hotplug issue. Excpet CPU{1-7} are well working.
I understand that, but the issue with CPU0 is still a blocker from my
PoV.
> To fix this issue, we must need the help of firmware developer.
> But, We never get the any help.
Previously you said that you did not have access to the source code
rather than not having help from the relevant firmware engineers. I take
it you have informed them of the issue with CPU0?
> Also, as I mentioned on previous mail, all Exynos SoCs can not turn
> off the CPU0. I've never seen Exynos SoC that CP0 hotplug is possible.
While that may be the case, PSCI is a more generic standard, and it is
used on systems where CPU0 can be hot unplugged. So Exynos-specific
details cannot dictate how the kernel PSCI driver should behave.
Is there a particular reason that CPU0 cannot be hotplugged?
In PSCI 0.2 and later it's possible to determine whether a trusted OS
prohibits a core from being hotplugged, but this mechanism doesn't exist
in earlier versions. I am not averse to adding a property to PSCI 0.1
to mark a CPU as not being hotpluggable if there is a fundamental reason
(i.e. not simply a bug) for this being the case.
Thanks,
Mark.
--
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
Re: [PATCH v2 1/2] ARM: EXYNOS: Get current parent clock for power domain on/off
Hello Krzysztof, On 04/03/2015 11:33 AM, Krzysztof Kozlowski wrote: > Using a fixed (by DTS) parent for clocks when turning on the power domain > may introduce issues in other drivers. For example when such driver > changes the parent during runtime and expects that he is the only place > of such change. > > Do not rely on DTS providing the fixed parent for such clocks. Instead > before switching domain off, grab a current parent of a clock with > clk_get_parent(). > > Signed-off-by: Krzysztof Kozlowski > > --- > > Changes since v1: > 1. Drop "pclk" bindings entirely as suggested by Andrzej Hajda. >This was significant change so I did not add Javier's >reviewed/tested tags. Reviewed-by: Javier Martinez Canillas on an Exynos5420 Peach Pit Chromebook: Tested-by: Javier Martinez Canillas Best regards, Javier -- 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
Re: [PATCH 1/2] mfd: sec: Fix RTC alarm interrupt number on S2MPS11
On Thu, 02 Apr 2015, Krzysztof Kozlowski wrote:
> The RTC on S2MPS11 is the same as S2MPS14. However interrupt numbers of
> RTC alarms 0 and 1 were inversed between these two devices. So when
> rtc-s5m driver requested S2MPS14_IRQ_RTCA0 interrupt, it matched to
> S2MPS11_IRQ_RTCA1, not RTCA0.
>
> Fix this by using consistent RTC alarm interrupt numbers and adding a
> BUILD_BUG_ON for future generations.
>
> Signed-off-by: Krzysztof Kozlowski
> ---
> drivers/mfd/sec-irq.c | 14 ++
> include/linux/mfd/samsung/irq.h | 2 +-
> 2 files changed, 11 insertions(+), 5 deletions(-)
Applied, thanks.
> diff --git a/drivers/mfd/sec-irq.c b/drivers/mfd/sec-irq.c
> index ba86a918c2da..806fa8dbb22d 100644
> --- a/drivers/mfd/sec-irq.c
> +++ b/drivers/mfd/sec-irq.c
> @@ -61,14 +61,14 @@ static const struct regmap_irq s2mps11_irqs[] = {
> .reg_offset = 1,
> .mask = S2MPS11_IRQ_RTC60S_MASK,
> },
> - [S2MPS11_IRQ_RTCA0] = {
> - .reg_offset = 1,
> - .mask = S2MPS11_IRQ_RTCA0_MASK,
> - },
> [S2MPS11_IRQ_RTCA1] = {
> .reg_offset = 1,
> .mask = S2MPS11_IRQ_RTCA1_MASK,
> },
> + [S2MPS11_IRQ_RTCA0] = {
> + .reg_offset = 1,
> + .mask = S2MPS11_IRQ_RTCA0_MASK,
> + },
> [S2MPS11_IRQ_SMPL] = {
> .reg_offset = 1,
> .mask = S2MPS11_IRQ_SMPL_MASK,
> @@ -484,6 +484,12 @@ int sec_irq_init(struct sec_pmic_dev *sec_pmic)
> return ret;
> }
>
> + /*
> + * The rtc-s5m driver requests S2MPS14_IRQ_RTCA0 also for S2MPS11
> + * so the interrupt number must be consistent.
> + */
> + BUILD_BUG_ON(((enum s2mps14_irq)S2MPS11_IRQ_RTCA0) !=
> S2MPS14_IRQ_RTCA0);
> +
> return 0;
> }
>
> diff --git a/include/linux/mfd/samsung/irq.h b/include/linux/mfd/samsung/irq.h
> index f35af7361b60..667aa40486dd 100644
> --- a/include/linux/mfd/samsung/irq.h
> +++ b/include/linux/mfd/samsung/irq.h
> @@ -74,8 +74,8 @@ enum s2mps11_irq {
> S2MPS11_IRQ_MRB,
>
> S2MPS11_IRQ_RTC60S,
> - S2MPS11_IRQ_RTCA0,
> S2MPS11_IRQ_RTCA1,
> + S2MPS11_IRQ_RTCA0,
> S2MPS11_IRQ_SMPL,
> S2MPS11_IRQ_RTC1S,
> S2MPS11_IRQ_WTSR,
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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
Re: [PATCH -v3 11/11] drm/exynos: atomic dpms support
Hi,
On 04/07/2015 03:26 AM, Gustavo Padovan wrote:
> Hi Inki,
>
> 2015-04-05 Inki Dae :
>
>> Hi,
>>
>> 2015-04-04 3:09 GMT+09:00 Gustavo Padovan :
>>> From: Gustavo Padovan
>>>
>>> Run dpms operations through the atomic intefaces. This basically removes
>>> the .dpms() callback from econders and crtcs and use .disable() and
>>> .enable() to turn the crtc on and off.
>>>
>>> v2: Address comments by Joonyoung:
>>> - make hdmi code call ->disable() instead of ->dpms()
>>> - do not use WARN_ON on crtc enable/disable
>>>
>>> Signed-off-by: Gustavo Padovan
>>> ---
>>> drivers/gpu/drm/exynos/exynos_dp_core.c | 2 +-
>>> drivers/gpu/drm/exynos/exynos_drm_connector.c | 2 +-
>>> drivers/gpu/drm/exynos/exynos_drm_crtc.c | 99
>>> +++
>>> drivers/gpu/drm/exynos/exynos_drm_dpi.c | 2 +-
>>> drivers/gpu/drm/exynos/exynos_drm_drv.h | 4 +-
>>> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 2 +-
>>> drivers/gpu/drm/exynos/exynos_drm_encoder.c | 27 ++--
>>> drivers/gpu/drm/exynos/exynos_drm_vidi.c | 2 +-
>>> drivers/gpu/drm/exynos/exynos_hdmi.c | 6 +-
>>> 9 files changed, 70 insertions(+), 76 deletions(-)
>>>
>>
>> ...snip...
>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
>>> b/drivers/gpu/drm/exynos/exynos_hdmi.c
>>> index 5b597bc..2ea7d01 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
>>> @@ -1051,7 +1051,7 @@ static void hdmi_connector_destroy(struct
>>> drm_connector *connector)
>>> }
>>>
>>> static struct drm_connector_funcs hdmi_connector_funcs = {
>>> - .dpms = drm_helper_connector_dpms,
>>> + .dpms = drm_atomic_helper_connector_dpms,
>>> .fill_modes = drm_helper_probe_single_connector_modes,
>>> .detect = hdmi_detect,
>>> .destroy = hdmi_connector_destroy,
>>> @@ -2127,8 +2127,8 @@ static void hdmi_dpms(struct exynos_drm_display
>>> *display, int mode)
>>> */
>>> if (crtc)
>>> funcs = crtc->helper_private;
>>> - if (funcs && funcs->dpms)
>>> - (*funcs->dpms)(crtc, mode);
>>> + if (funcs && funcs->disable)
>>> + (*funcs->disable)(crtc, mode);
>>
>> This patch makes funcs->disable callback to be called instead of
>> funcs->dpms callback. However, funcs->disable callback isn't required
>> for second argument so the build is failed like below,
>>
>> drivers/gpu/drm/exynos/exynos_hdmi.c: In function 'hdmi_dpms':
>> drivers/gpu/drm/exynos/exynos_hdmi.c:2131:4: error: too many arguments
>> to function 'funcs->disable'
>>
You needs to rebase patchset from latest repository of Inki Dae with
this fix because i got some conflict to apply this patchset.
Anyway, i just tested it from hdmi output part on odroid-xu3 board.
Tested-by: Joonyoung Shim
Thanks.
>> Please, keep in mind that you should build it and at least have a
>> basic test before posting.
>
> Sure, I think this happened because I've been using exynos_defconfig to test
> my kernels and HDMI is not there. Maybe should we add the EXYNOS_DRM_HDMI to
> defconfig? What do you think?
>
> Gustavo
> --
> 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-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/3] drm/exynos: mixer: add 2x scaling to mixer_graph_buffer
Hi,
On 04/07/2015 08:14 AM, Tobias Jakobi wrote:
> While the VP (video processor) supports arbitrary scaling
> of its input, the mixer just supports a simple 2x (line
> doubling) scaling. Expose this functionality and exit
> early when an unsupported scaling configuration is
> encountered.
>
> This was tested with modetest's DRM plane test (from
> the libdrm test suite) on an Odroid-X2 (Exynos4412).
>
> v2: Put if- and return-statement on different lines.
>
> Reviewed-by: Gustavo Padovan
> Signed-off-by: Tobias Jakobi
> ---
> drivers/gpu/drm/exynos/exynos_mixer.c | 36
> +--
> 1 file changed, 30 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index 5ab0e32..f51011e 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -499,12 +499,36 @@ static void mixer_layer_update(struct mixer_context
> *ctx)
> mixer_reg_writemask(res, MXR_CFG, ~0, MXR_CFG_LAYER_UPDATE);
> }
>
> +static int mixer_setup_scale(const struct exynos_drm_plane *plane,
> + unsigned int *x_ratio, unsigned int *y_ratio)
> +{
> + if (plane->crtc_width != plane->src_width) {
> + if (plane->crtc_width == 2 * plane->src_width)
> + *x_ratio = 1;
> + else
> + goto fail;
> + }
> +
> + if (plane->crtc_height != plane->src_height) {
> + if (plane->crtc_height == 2 * plane->src_height)
> + *y_ratio = 1;
> + else
> + goto fail;
> + }
> +
> + return 0;
> +
> +fail:
> + DRM_DEBUG_KMS("only 2x width/height scaling of plane supported\n");
> + return -ENOTSUPP;
> +}
> +
> static void mixer_graph_buffer(struct mixer_context *ctx, int win)
> {
> struct mixer_resources *res = &ctx->mixer_res;
> unsigned long flags;
> struct exynos_drm_plane *plane;
> - unsigned int x_ratio, y_ratio;
> + unsigned int x_ratio = 0, y_ratio = 0;
> unsigned int src_x_offset, src_y_offset, dst_x_offset, dst_y_offset;
> dma_addr_t dma_addr;
> unsigned int fmt;
> @@ -528,9 +552,9 @@ static void mixer_graph_buffer(struct mixer_context *ctx,
> int win)
> fmt = ARGB;
> }
>
> - /* 2x scaling feature */
> - x_ratio = 0;
> - y_ratio = 0;
> + /* check if mixer supports requested scaling setup */
> + if (mixer_setup_scale(plane, &x_ratio, &y_ratio))
> + return;
>
> dst_x_offset = plane->crtc_x;
> dst_y_offset = plane->crtc_y;
> @@ -566,8 +590,8 @@ static void mixer_graph_buffer(struct mixer_context *ctx,
> int win)
> mixer_reg_write(res, MXR_RESOLUTION, val);
> }
>
> - val = MXR_GRP_WH_WIDTH(plane->crtc_width);
> - val |= MXR_GRP_WH_HEIGHT(plane->crtc_height);
> + val = MXR_GRP_WH_WIDTH(plane->src_width);
> + val |= MXR_GRP_WH_HEIGHT(plane->src_height);
With this changes, i got errors when crtc gets out bound of actual
screen area. I sent patch to fix it and to calculate ratio from
exynos_drm plane codes.
Acked-by: Joonyoung Shim
Thanks.
--
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
Re: [PATCH -v3 00/11] drm/exynos: Add atomic modesetting support
On 2015년 04월 07일 00:44, Inki Dae wrote: > 2015-04-06 19:46 GMT+09:00 Inki Dae : >> On 2015년 04월 04일 03:09, Gustavo Padovan wrote: >>> From: Gustavo Padovan >>> >>> Hi, >>> >>> Here goes the full support for atomic modesetting on exynos. I've >>> split the patches in the various phases of atomic support. >>> >>> These patches sits on top of the clean up patches I've sent yesterday >>> to this mailing list[1]. >>> >>> v2: fixes comments by Joonyoung >>> - remove unused var in patch 09 >>> - use ->disable instead of outdated ->dpms in hdmi code >>> - remove WARN_ON from crtc enable/disable >>> >>> v3: fixes comment by Joonyoung >>> - move the removal of drm_helper_disable_unused_functions() to >>> separated patch >> >> With this patch series, Kernel booting is halted at end of kernel >> booting. I tested this patch series on Trats2 board based on Exynos4412 SoC. >> >> Below is a part of full booting logs, which was halted, >> [1.992015] exynos-drm-ipp exynos-drm-ipp: drm ipp registered >> successfully. >> [1.993009] exynos-drm exynos-drm: bound exynos-drm-vidi (ops >> vidi_component_ops) >> [1.993036] exynos-drm exynos-drm: bound 11c0.fimd (ops >> fimd_component_ops) >> [1.993385] exynos-drm exynos-drm: bound 11c8.dsi (ops >> exynos_dsi_component_ops) >> [1.993390] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). >> [1.993393] [drm] No driver support for vblank timestamp query. >> [1.993442] [drm] Initialized exynos 1.0.0 20110530 on minor 0 >> [2.043358] WARNING: CPU: 2 PID: 1209 at drivers/clk/clk.c:898 >> clk_unprepare+0x24/0x2c() >> [2.051412] Modules linked in: >> [2.054422] CPU: 2 PID: 1209 Comm: kworker/2:1 Tainted: GW >> 4.0.0-rc6-00526-gc49d7de-dirty #1278 >> [2.064337] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) >> [2.070428] Workqueue: pm pm_runtime_work> >> >> After that, I tested it again without FIMD and the booting is ok. So I >> guess that this atomic feature has a bug to FIMD driver. >> > > More information, > > The reason the booting is halted is that a deadlock occurs at fbcon > module when register_framebuffer() is called. > > Below are our test results, > - with only cleanup series, FIMD and HDMI work well. > - with cleanup and atomic series, HDMI works well but FIMD doesn't > work - a deadlock occurs. > > Could anyone test it with the atomic series on trats2 board? You can > test it on top of exynos-drm-next-todo branch which contains all > relevant patches, > https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/log/?h=exynos-drm-next-todo > > Anyway, we will continue to take a look at the this issue why the > deadlock occurs. In addition, I added some codes temporarily to fbmem module which mitigates the deadlock issue. After that, I see below panic log, [3.254840] Unable to handle kernel NULL pointer dereference at virtual address 00a4 [3.262870] pgd = c0004000 [3.265539] [00a4] *pgd= [3.269102] Internal error: Oops: 5 [#1] PREEMPT SMP ARM [3.274392] Modules linked in: [3.277435] CPU: 2 PID: 1 Comm: swapper/0 Tainted: GW 4.0.0-rc6-00526-gc49d7de-dirty #1308 [3.286892] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [3.292970] task: ee878000 ti: ee88 task.ti: ee88 [3.298356] PC is at exynos_plane_atomic_update+0x24/0x1d4 [3.303824] LR is at drm_atomic_helper_commit_planes+0xa4/0x18c [3.309723] pc : []lr : []psr: 6113 [3.309723] sp : ee881b38 ip : 0020 fp : [3.321179] r10: c04cfc00 r9 : 0008 r8 : eebfb9c0 [3.326387] r7 : 0002 r6 : r5 : r4 : ee925308 [3.332897] r3 : ee329fc0 r2 : r1 : r0 : ee925308 [3.339409] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [3.346699] Control: 10c5387d Table: 4000404a DAC: 0015 [3.352427] Process swapper/0 (pid: 1, stack limit = 0xee880210) [3.358416] Stack: (0xee881b38 to 0xee882000) [3.362757] 1b20: c0726794 0008 [3.370919] 1b40: 0002 ee925308 ee329e00 0002 eebfb9c0 0008 c04cfc00 [3.379078] 1b60: c0265308 0008 ee329e00 ee0a8000 0008 [3.387237] 1b80: c0267304 ee329e00 ee8efe00 ee914c00 0002 0002 [3.395396] 1ba0: c026609c c0265ef0 ee914c00 0028 ee8eff00 0001 [3.403555] 1bc0: c06c8380 c02770d0 ee8efe00 0028 ee8eff00 [3.411714] 1be0: 0001 c0267a2c ee0a8000 c0286214 ee8eff00 ee8eff00 ee0a8000 [3.419874] 1c00: c0722ad4 ee35e000 c0269900 ee915400 c0269958 [3.428033] 1c20: ee808c00 c020cc8c c0248620 c05d5448 ee808c00 ee808c00 ee808d34 [3.436192] 1c40: 0001 0066 c0724acc c0724fd4 005b 0066 005b [3.444351] 1c60: c05b28cc ee808c00 ee808d74 00
Re: [PATCH v2 2/3] drm/exynos: remove superfluous error messages
Hi,
On 04/07/2015 08:14 AM, Tobias Jakobi wrote:
> The messages are redundant since 'check_fb_gem_memory_type'
> already prints out exactly the same string when it fails.
>
> Reviewed-by: Gustavo Padovan
> Signed-off-by: Tobias Jakobi
> ---
> drivers/gpu/drm/exynos/exynos_drm_fb.c | 10 +++---
> 1 file changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c
> b/drivers/gpu/drm/exynos/exynos_drm_fb.c
> index d346d1e..929cb03 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
> @@ -151,10 +151,8 @@ exynos_drm_framebuffer_init(struct drm_device *dev,
> exynos_gem_obj = to_exynos_gem_obj(obj);
>
> ret = check_fb_gem_memory_type(dev, exynos_gem_obj);
> - if (ret < 0) {
> - DRM_ERROR("cannot use this gem memory type for fb.\n");
> - return ERR_PTR(-EINVAL);
> - }
> + if (ret < 0)
> + return ERR_PTR(ret);
>
> exynos_fb = kzalloc(sizeof(*exynos_fb), GFP_KERNEL);
> if (!exynos_fb)
> @@ -250,10 +248,8 @@ exynos_user_fb_create(struct drm_device *dev, struct
> drm_file *file_priv,
> exynos_fb->exynos_gem_obj[i] = exynos_gem_obj;
>
> ret = check_fb_gem_memory_type(dev, exynos_gem_obj);
> - if (ret < 0) {
> - DRM_ERROR("cannot use this gem memory type for fb.\n");
> + if (ret < 0)
> goto err_unreference;
> - }
> }
>
> ret = drm_framebuffer_init(dev, &exynos_fb->fb, &exynos_drm_fb_funcs);
>
Acked-by: Joonyoung Shim
Thanks.
--
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
Re: [PATCH v2 1/3] drm/exynos: fix typos in hdmi and mixer
Hi,
On 04/07/2015 08:14 AM, Tobias Jakobi wrote:
> Use the correct spelling for 'progressive'.
>
> Reviewed-by: Gustavo Padovan
> Signed-off-by: Tobias Jakobi
> ---
> drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +-
> drivers/gpu/drm/exynos/exynos_mixer.c | 2 +-
> drivers/gpu/drm/exynos/regs-mixer.h | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index 3511fcc..20e2ce7 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -2022,7 +2022,7 @@ static void hdmi_mode_set(struct exynos_drm_display
> *display,
> DRM_DEBUG_KMS("xres=%d, yres=%d, refresh=%d, intl=%s\n",
> m->hdisplay, m->vdisplay,
> m->vrefresh, (m->flags & DRM_MODE_FLAG_INTERLACE) ?
> - "INTERLACED" : "PROGERESSIVE");
> + "INTERLACED" : "PROGRESSIVE");
>
> /* preserve mode information for later use. */
> drm_mode_copy(&hdata->current_mode, mode);
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index aa5b6e1..5ab0e32 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -267,7 +267,7 @@ static void mixer_cfg_scan(struct mixer_context *ctx,
> unsigned int height)
>
> /* choosing between interlace and progressive mode */
> val = (ctx->interlace ? MXR_CFG_SCAN_INTERLACE :
> - MXR_CFG_SCAN_PROGRASSIVE);
> + MXR_CFG_SCAN_PROGRESSIVE);
>
> if (ctx->mxr_ver != MXR_VER_128_0_0_184) {
> /* choosing between proper HD and SD mode */
> diff --git a/drivers/gpu/drm/exynos/regs-mixer.h
> b/drivers/gpu/drm/exynos/regs-mixer.h
> index 5f32e1a..ac60260 100644
> --- a/drivers/gpu/drm/exynos/regs-mixer.h
> +++ b/drivers/gpu/drm/exynos/regs-mixer.h
> @@ -101,7 +101,7 @@
> #define MXR_CFG_GRP0_ENABLE (1 << 4)
> #define MXR_CFG_VP_ENABLE(1 << 3)
> #define MXR_CFG_SCAN_INTERLACE (0 << 2)
> -#define MXR_CFG_SCAN_PROGRASSIVE (1 << 2)
> +#define MXR_CFG_SCAN_PROGRESSIVE (1 << 2)
> #define MXR_CFG_SCAN_NTSC(0 << 1)
> #define MXR_CFG_SCAN_PAL (1 << 1)
> #define MXR_CFG_SCAN_SD (0 << 0)
>
Acked-by: Joonyoung Shim
Thanks.
--
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
