linux-kernel - Re: [PATCH v5 04/21] dt-bindings: Add doc for the Ingenic TCU drivers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <7c448bfb-b4a6-8a09-db3d-32c829d5ec78@linaro.org>
Date:   Wed, 3 Oct 2018 14:47:21 +0200
From:   Daniel Lezcano <daniel.lezcano@...aro.org>
To:     Paul Cercueil <paul@...pouillou.net>, robh@...nel.org
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Guenter Roeck <linux@...ck-us.net>, linux-doc@...r.kernel.org,
        linux-watchdog@...r.kernel.org, Jonathan Corbet <corbet@....net>,
        linux-mips@...ux-mips.org, Stephen Boyd <sboyd@...nel.org>,
        Wim Van Sebroeck <wim@...ux-watchdog.org>,
        Mark Rutland <mark.rutland@....com>,
        Paul Burton <paul.burton@...s.com>,
        Michael Turquette <mturquette@...libre.com>,
        linux-clk@...r.kernel.org, linux-kernel@...r.kernel.org,
        devicetree@...r.kernel.org, Ralf Baechle <ralf@...ux-mips.org>,
        Lee Jones <lee.jones@...aro.org>,
        Thierry Reding <thierry.reding@...il.com>,
        linux-pwm@...r.kernel.org
Subject: Re: [PATCH v5 04/21] dt-bindings: Add doc for the Ingenic TCU drivers

On 03/10/2018 12:32, Paul Cercueil wrote:
> 
> Le 1 oct. 2018 10:48, Daniel Lezcano <daniel.lezcano@...aro.org> a
> écrit :
>> 
>> On 31/07/2018 00:01, Paul Cercueil wrote:
>> 
>> [ ... ]
>> 
>>>>> +- ingenic,timer-channel: Specifies the TCU channel that
>>>>> should be used as +  system timer. If not provided, the TCU
>>>>> channel 0 is used for the system timer. + +-
>>>>> ingenic,clocksource-channel: Specifies the TCU channel that 
>>>>> should be used +  as clocksource and sched_clock. It must be
>>>>> a different channel than the one +  used as system timer. If
>>>>> not provided, neither a clocksource nor a +  sched_clock is
>>>>> instantiated.
>>>> 
>>>> clocksource and sched_clock are Linux specific and don't belong
>>>> in DT. You should define properties of the hardware or use
>>>> existing properties like interrupts or clocks to figure out
>>>> which channel to use. For example, if some channels don't have
>>>> an interrupt, then use them for clocksource and not a
>>>> clockevent. Or you could have timers that run in low-power
>>>> modes or not. If all the channels are identical, then it 
>>>> shouldn't matter which ones the OS picks.
>> 
>> It can't work in this case because the pmw and the timer driver are
>> not communicating and the first one can stole a channel to the last
>> one.
> 
> In that particular case the timer driver will always request its
> channels first; with no timer set the system hangs before
> subsys_initcall, and the PWM driver is a subnode of the timer node,
> so is probed only after the timer probed.
> 
>>> We already talked about that. All the TCU channels can be used
>>> for PWM. The problem is I cannot know from the driver's scope
>>> which channels will be free and which channels will be requested
>>> for PWM. You suggested that I parse the devicetree for clients,
>>> and I did that in the V3/V4 patchset. But it only works for
>>> clients requesting through devicetree, not from platform code or
>>> even sysfs.
>>> 
>>> One thing I can try is to dynamically change the channels the
>>> system timer and clocksource are using when the current ones are
>>> requested for PWM. But that sounds hardcore...
>> 
>> Yes, it is :/
>> 
>> Sorry for letting you wasting time and effort to write an overkill
>> code not suitable for upstream.
>> 
>> A very gross thought, wouldn't be possible to "register" a channel
>> from the timer driver code in a shared data area (but well
>> self-encapsulated) and the pwm code will check such channel isn't
>> in use ?
> 
> Probably, but it's the contrary I need to do. The timer driver code
> can use any channel, and probes first. The PWM driver code must use
> specific channels, and probes last. So either the timer driver knows
> what channels it can't use, thanks to a device property, or it adapts
> itself when a channel in use is requested for PWM, which is what I
> tried in v7.

When you say "must use specific channels", where is coming this
information ?

> I think we could find a way to use a devicetree property that doesn't
> trigger Rob. That would still be the easiest and cleanest solution.
> 
> Maybe "ingenic,reserved-channels-mask", which would contain a mask of
> channels that can only be used by the timer driver. And what the
> timer driver does with these channels, would be specific to the
> implementation and would not appear in the bindings. I hope Rob can
> work with that.
> 
> -Paul
> 


-- 
 <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