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 <[email protected]>
---
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
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<[email protected]>
> ---
> 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
Kukjin,
On Mon, Apr 8, 2013 at 11:23 AM, Kukjin Kim <[email protected]> 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
On 04/09/13 03:25, Doug Anderson wrote:
> Kukjin,
>
> On Mon, Apr 8, 2013 at 11:23 AM, Kukjin Kim<[email protected]> 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
Kukjin,
On Mon, Apr 8, 2013 at 11:29 AM, Kukjin Kim <[email protected]> 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
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 <[email protected]> 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
Tomasz,
On Mon, Apr 8, 2013 at 12:27 PM, Tomasz Figa <[email protected]> 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