[lkml]   [2019]   [Jun]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 2/5] clocksource/drivers/timer-microchip-pit64b: add Microchip PIT64B support

Hi Claudiu,

sorry for the late reply.

On 13/06/2019 16:12, wrote:
> Hi Daniel,
> On 31.05.2019 13:41, Daniel Lezcano wrote:
>> Hi Claudiu,
>> On 30/05/2019 09:46, wrote:
>>> Hi Daniel,
>>> Taking into account the discussion on this tread and the fact that we have
>>> no answer from Rob on this topic (I'm talking about [1]), what do you think
>>> it would be best for this driver to be accepted the soonest? Would it be OK
>>> for you to mimic the approach done by:
>>> drivers/clocksource/timer-integrator-ap.c
>>> with the following bindings in DT:
>>> aliases {
>>> arm,timer-primary = &timer2;
>>> arm,timer-secondary = &timer1;
>>> };
>>> also in PIT64B driver?
>>> Or do you think re-spinning the Alexandre's patches at [2] (which seems to
>>> me like the generic way to do it) would be better?
>> This hardware / OS connection problem is getting really annoying for
>> everyone and this pattern is repeating itself since several years. It is
>> time we fix it properly.
>> The first solution looks hackish from my POV. The second approach looks
>> nicer and generic as you say. So I would vote for [2]
>> flagging approach proposed by Mark [3].
> With this flagging approach this would mean a kind unification of
> clocksource and clockevent functionalities under a single one, right? So
> that the driver would register to the above layers only one device w/ 2
> functionalities (clocksource and clockevent)? Please correct me if I'm
> wrong? If so, from my point of view this would require major re-working of
> clocksource and clockevent subsystems. Correctly if I wrongly understood,
> please.

Well, actually I was not expecting to change all the framework but just
pass a flag to the probe function telling if the node is for a
clocksource, a clockevent or both.

> At the moment we register different functionalities (clocksource and
> clockevent) to the above layers for hardware blocks (e.g. with
> clocksource_register_hz() or clockevents_config_and_register()). If
> hardware can support clocksource and clockevent we register both these
> functionalities, if only one is supported we register only one of these.
> The above layers would choose the best clocksource/clockevent device from
> the available ones based on rating field for each clocksource/clockevent we
> register. In all this current behavior I don't see how these flags would
> interact with clocksource/clockevent subsystem. Could you please let me
> know how do you see these and the way these new flags would interact with
> the layers above the drivers?
>> I added Arnd in Cc in order to have its opinion.
>> [3]
>>> [1]
>>> [2]

<> │ Open source software for ARM SoCs

Follow Linaro: <> Facebook |
<!/linaroorg> Twitter |
<> Blog

 \ /
  Last update: 2019-06-20 10:54    [W:0.077 / U:7.700 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site