On 31.07.2014 21:25, Thomas Abraham wrote:

On Fri, Aug 1, 2014 at 12:24 AM, Tomasz Figa [off-list ref] wrote:

quoted

On 31.07.2014 20:40, Tomasz Figa wrote:

quoted

Kukjin,

On 31.07.2014 20:32, Kukjin Kim wrote:

quoted

On 07/30/14 17:07, Thomas Abraham wrote:

quoted

The new CPU clock type allows the use of generic CPUfreq drivers. So for
Exynos4210/5250, switch to using generic cpufreq driver. For Exynos5420,
which did not have CPUfreq driver support, enable the use of generic
CPUfreq driver.

Suggested-by: Tomasz Figa<redacted>
Cc: Kukjin Kim<redacted>

Looks good to me,

Acked-by: Kukjin Kim <redacted>

BTW, who will handle this series? I hope see this series in 3.17.

This series consists mostly of clock changes and it likely depends on
patches already in my for-next, so I would be inclined toward taking it
through samsung-clk tree. However, for this I would need Acks for patch
5/6 from Viresh and for patches [1] and [2] (which are dependencies of
this series) from you. I also need to make sure that the two mentioned
patches don't have any dependencies already in your tree.

[1] ARM: dts: add CPU nodes for Exynos4 SoCs
   - https://lkml.org/lkml/2014/7/21/315
[2] ARM: dts: smdk5250: Specify MAX77686 pmic interrupt
   - http://www.spinics.net/lists/arm-kernel/msg351134.html

Aha, I'm not quite sure we really want to hurry with this series for
3.17. I'd prefer it to be picked up early after 3.17-rc1 shows up to sit
in linux-next for a while an be thoroughly tested on a number of boards.

The v9 revision of this series has completed about 2 days of testing
now on 4210/5250/5420 boards. I will let it run for few more days. For
v8 and previous versions, the tests had completed 3 or more days. So I
really don't think there is anything fundamentally wrong with this
series. It would be nice to have this series merged and we start
migrating other Exynos based boards to use generic cpufreq drivers.

We have 22 Exynos-based boards currently supported in mainline. Is the
testing running on all of them? This is the purpose of linux-next and
for series that completely replace one driver with another I'd consider
this as the only reasonable choice, if not keeping the old driver for a
release.

Of course we have never had good testing traditions on Samsung SoC (see
OMAP and Tegra baseline tests), but does it mean that we shouldn't start
doing the right thing?

Best regards,
Tomasz