[PATCH] ARM: dts: fix bad merge of display timing node to exynos5250-smdk5250.dts

[PATCH] ARM: dts: fix bad merge of display timing node to exynos5250-smdk5250.dts

[Doug Anderson]

The display timing node was added:
  7ed2077 ARM: dts: Add display timing node to exynos5250-smdk5250.dts
...and looks OK there.  ...but it looks like we lost a "};" in the
merge and it no longer compiles.  Fix it.

Signed-off-by: Doug Anderson <dianders@chromium.org>
---
 arch/arm/boot/dts/exynos5250-smdk5250.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 4be14df..26d856b 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -239,6 +239,7 @@
 			vback-porch = <4>;
 			vfront-porch = <4>;
 			vsync-len = <4>;
+		};
 	};
 
 	fixed-rate-clocks {
-- 
1.8.1.3

[PATCH] ARM: dts: fix bad merge of display timing node to exynos5250-smdk5250.dts

[Kukjin Kim]

On 04/09/13 01:51, Doug Anderson wrote:
> The display timing node was added:
>    7ed2077 ARM: dts: Add display timing node to exynos5250-smdk5250.dts
> ...and looks OK there.  ...but it looks like we lost a "};" in the
> merge and it no longer compiles.  Fix it.
>
> Signed-off-by: Doug Anderson<dianders@chromium.org>
> ---
>   arch/arm/boot/dts/exynos5250-smdk5250.dts | 1 +
>   1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts b/arch/arm/boot/dts/exynos5250-smdk5250.dts
> index 4be14df..26d856b 100644
> --- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
> +++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
> @@ -239,6 +239,7 @@
>   			vback-porch =<4>;
>   			vfront-porch =<4>;
>   			vsync-len =<4>;
> +		};
>   	};
>
>   	fixed-rate-clocks {

Thanks for your pointing out. But it should be fixed with re-sorting out 
the branch.

If any problems, please let me know.

- Kukjin

[PATCH] ARM: dts: fix bad merge of display timing node to exynos5250-smdk5250.dts

[Doug Anderson]

Kukjin,

On Mon, Apr 8, 2013 at 11:23 AM, Kukjin Kim <kgene.kim@samsung.com> wrote:
> Thanks for your pointing out. But it should be fixed with re-sorting out the
> branch.

No problem with however you want to solve it.  ;)  Seemed that the
patch was the easiest way to report the problem in any case...

-Doug

[PATCH] ARM: dts: fix bad merge of display timing node to exynos5250-smdk5250.dts

[Kukjin Kim]

On 04/09/13 03:25, Doug Anderson wrote:
> Kukjin,
>
> On Mon, Apr 8, 2013 at 11:23 AM, Kukjin Kim<kgene.kim@samsung.com>  wrote:
>> Thanks for your pointing out. But it should be fixed with re-sorting out the
>> branch.
>
> No problem with however you want to solve it.  ;)  Seemed that the
> patch was the easiest way to report the problem in any case...
>
Makes sense :-)

BTW, if any problems on current for-next, please kindly let me know.

Thanks.

- Kukjin

[PATCH] ARM: dts: fix bad merge of display timing node to exynos5250-smdk5250.dts

[Doug Anderson]

Kukjin,

On Mon, Apr 8, 2013 at 11:29 AM, Kukjin Kim <kgene.kim@gmail.com> wrote:
> BTW, if any problems on current for-next, please kindly let me know.

I usually try to check linux-next at least once a week, but sometimes
it's more or less often.  At the moment I'm trying to track something
weird down but it seems like it has some userspace component to it.
I'll post a separate thread if I find a kernel problem there.

Aside from the RTC, my biggest problem right now is that reboot
stopped working at the same time as the common clock.  The
exynos5_restart() function is essentially behaving as a no-op since
the clock to the IP block that handles reset has been gated.  :(  The
bit "CLK_PMU_APBIF" is gated in "CLK_GATE_IP_PERIS". This used to be
ungated in exynos5_clk_ip_peris_ctrl().

I'm happy to test a patch that fixes this but I haven't yet had time
to try to fix it cleanly myself.


-Doug

[PATCH] ARM: dts: fix bad merge of display timing node to exynos5250-smdk5250.dts

[Tomasz Figa]

Hi Doug,

On Monday 08 of April 2013 12:21:32 Doug Anderson wrote:
> Kukjin,
> 
> On Mon, Apr 8, 2013 at 11:29 AM, Kukjin Kim <kgene.kim@gmail.com> wrote:
> > BTW, if any problems on current for-next, please kindly let me know.
> 
> I usually try to check linux-next at least once a week, but sometimes
> it's more or less often.  At the moment I'm trying to track something
> weird down but it seems like it has some userspace component to it.
> I'll post a separate thread if I find a kernel problem there.
> 
> Aside from the RTC, my biggest problem right now is that reboot
> stopped working at the same time as the common clock.  The
> exynos5_restart() function is essentially behaving as a no-op since
> the clock to the IP block that handles reset has been gated.  :(  The
> bit "CLK_PMU_APBIF" is gated in "CLK_GATE_IP_PERIS". This used to be
> ungated in exynos5_clk_ip_peris_ctrl().
> 
> I'm happy to test a patch that fixes this but I haven't yet had time
> to try to fix it cleanly myself.

Common Clock Framework by default automatically gates unused clocks, just 
like regulator core does with unused regulators. Maybe this is the cause?

There is a CLK_IGNORE_UNUSED flag which disables this behavior for all 
clocks which have it set. Maybe it should be set for the problematic 
clock?

Best regards,
Tomasz

[PATCH] ARM: dts: fix bad merge of display timing node to exynos5250-smdk5250.dts

[Doug Anderson]

Tomasz,

On Mon, Apr 8, 2013 at 12:27 PM, Tomasz Figa <tomasz.figa@gmail.com> wrote:
> Common Clock Framework by default automatically gates unused clocks, just
> like regulator core does with unused regulators. Maybe this is the cause?

Yes, I'm nearly certain that's the case here.  The reset code doesn't
belong to any driver (it's in mach-exynos/common.c) it certainly
doesn't grab any clock.

I tried quickly to see if there was an easy clock to grab but got a
bit stuck.  In the old way of doing things clocks could be global and
grabbed without a dev node.  That may still be possible now, but in
the 15 minutes I spent I couldn't figure it out and so it went to the
back burner.  ...or we could make a real reset device, but that might
be overkill?

> There is a CLK_IGNORE_UNUSED flag which disables this behavior for all
> clocks which have it set. Maybe it should be set for the problematic
> clock?

Didn't know about that one, thanks!  It seems like a bit annoying that
we'd have to keep this clock all the time just to get reset working,
though.  I guess in 3.4 that's what we did, though I don't know if it
was intentional...

-Doug