Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1352876 > unrolled thread

Re: [RFC PATCH] ARM: clocksource: make ARM_GLOBAL_TIMER selectable

Started byGrygorii Strashko <grygorii.strashko@ti.com>
First post2016-03-08 12:00 +0100
Last post2016-03-17 14:50 +0100
Articles 2 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [RFC PATCH] ARM: clocksource: make ARM_GLOBAL_TIMER selectable Grygorii Strashko <grygorii.strashko@ti.com> - 2016-03-08 12:00 +0100
    Re: [RFC PATCH] ARM: clocksource: make ARM_GLOBAL_TIMER selectable Daniel Lezcano <daniel.lezcano@linaro.org> - 2016-03-17 14:50 +0100

#1352876 — Re: [RFC PATCH] ARM: clocksource: make ARM_GLOBAL_TIMER selectable

FromGrygorii Strashko <grygorii.strashko@ti.com>
Date2016-03-08 12:00 +0100
SubjectRe: [RFC PATCH] ARM: clocksource: make ARM_GLOBAL_TIMER selectable
Message-ID<ranwR-8b7-1@gated-at.bofh.it>
On 02/26/2016 10:27 PM, Sören Brinkmann wrote:
> On Fri, 2016-02-26 at 15:03:19 +0200, Grygorii Strashko wrote:
>> On 02/05/2016 01:39 AM, Sören Brinkmann wrote:
>>> On Thu, 2016-02-04 at 15:14:47 -0800, Moritz Fischer wrote:
>>>> Hi Soeren,
>>>>
>>>> On Thu, Feb 4, 2016 at 2:41 PM, Sören Brinkmann
>>>> <soren.brinkmann@xilinx.com> wrote:
>>>>
>>>>> But with this change the 'if !CPU_FREQ' becomes obsolete.
>>>> I'm confused, could you explain that statement? You don't want people
>>>> accidentally running with GT when CPU_FREQ is on, right?
>>>
>>> Correct. But with this Kconfig rework you can just deselect it in
>>> Kconfig. The generic HAVE_GT could always be selected.
>>>
>>
>>
>> Don't know whom should i ask - but what will be the final conclusion here?
>> Can it be merged?
> 
> I think we don't break anything either way. Would just be some
> additional clean up to get rid of that mentioned constraint (which
> doesn't really work well anyway in the multi-arch kernel). So, no real
> objections to merging it from my side.
> 

Yeah. Thanks

I'll re-send it after 4.6-rc.
But What I'm not fully understand is how to get it merged taking into account that
it touches few maches & clocksource :( 

-- 
regards,
-grygorii

[toc] | [next] | [standalone]


#1359862

FromDaniel Lezcano <daniel.lezcano@linaro.org>
Date2016-03-17 14:50 +0100
Message-ID<rdGtj-844-3@gated-at.bofh.it>
In reply to#1352876
On 03/08/2016 11:55 AM, Grygorii Strashko wrote:
> Yeah. Thanks
>
> I'll re-send it after 4.6-rc.
> But What I'm not fully understand is how to get it merged taking into account that
> it touches few maches & clocksource :(

This is not a problem. Send it based on timers/core from the tip tree 
and Cc the maintainers for the maches dir. As soon as they ack the 
patches, I will merge it through my tree.

Thanks

   -- Daniel



-- 
  <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web