* Re: [PATCH v8 2/2] media: i2c: Add the ov7740 image sensor driver
From: Philippe Ombredanne @ 2017-12-08 13:14 UTC (permalink / raw)
To: Wenyou Yang
Cc: Mauro Carvalho Chehab, Rob Herring, Mark Rutland, LKML,
Nicolas Ferre,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Sakari Ailus, Jonathan Corbet, Hans Verkuil,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Linux Media Mailing List, Songjun Wu
In-Reply-To: <20171208015542.15444-3-wenyou.yang@microchip.com>
Wenyou,
On Fri, Dec 8, 2017 at 2:55 AM, Wenyou Yang <wenyou.yang@microchip.com> wrote:
> The ov7740 (color) image sensor is a high performance VGA CMOS
> image snesor, which supports for output formats: RAW RGB and YUV
> and image sizes: VGA, and QVGA, CIF and any size smaller.
>
> Signed-off-by: Songjun Wu <songjun.wu@microchip.com>
> Signed-off-by: Wenyou Yang <wenyou.yang@microchip.com>
[]
> --- /dev/null
> +++ b/drivers/media/i2c/ov7740.c
> @@ -0,0 +1,1226 @@
> +/*
> + * Copyright (c) 2017 Microchip Corporation.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License version
> + * 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + */
Have you considered using the new SPDX ids instead of this fine legalese?
e.g.:
// SPDX-License-Identifier: GPL-2.0
// Copyright (c) 2017 Microchip Corporation.
Short and neat! Check also Thomas doc patches and Linus comments on
why he prefers the C++ comment style for these.
--
Cordially
Philippe Ombredanne
^ permalink raw reply
* [PATCH 2/2] of: overlay: Make node skipping in init_overlay_changeset() clearer
From: Geert Uytterhoeven @ 2017-12-08 13:13 UTC (permalink / raw)
To: Pantelis Antoniou, Rob Herring, Frank Rowand
Cc: devicetree, linux-renesas-soc, linux-kernel, Geert Uytterhoeven
In-Reply-To: <1512738783-17452-1-git-send-email-geert+renesas@glider.be>
Make it more clear that nodes without "__overlay__" subnodes are
skipped, by reverting the logic and using continue.
This also reduces indentation level.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
This applies to Rob's for-next branch only.
---
drivers/of/overlay.c | 21 +++++++++++----------
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c
index 49b8939af6b201ca..54a73bd771fe27b7 100644
--- a/drivers/of/overlay.c
+++ b/drivers/of/overlay.c
@@ -573,18 +573,19 @@ static int init_overlay_changeset(struct overlay_changeset *ovcs,
cnt = 0;
for_each_child_of_node(tree, node) {
overlay_node = of_get_child_by_name(node, "__overlay__");
- if (overlay_node) {
- fragment = &fragments[cnt];
- fragment->overlay = overlay_node;
- fragment->target = find_target_node(node);
- if (!fragment->target) {
- of_node_put(fragment->overlay);
- ret = -EINVAL;
- goto err_free_fragments;
- }
+ if (!overlay_node)
+ continue;
- cnt++;
+ fragment = &fragments[cnt];
+ fragment->overlay = overlay_node;
+ fragment->target = find_target_node(node);
+ if (!fragment->target) {
+ of_node_put(fragment->overlay);
+ ret = -EINVAL;
+ goto err_free_fragments;
}
+
+ cnt++;
}
/*
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] of: overlay: Fix out-of-bounds write in init_overlay_changeset()
From: Geert Uytterhoeven @ 2017-12-08 13:13 UTC (permalink / raw)
To: Pantelis Antoniou, Rob Herring, Frank Rowand
Cc: devicetree, linux-renesas-soc, linux-kernel, Geert Uytterhoeven
In-Reply-To: <1512738783-17452-1-git-send-email-geert+renesas@glider.be>
If an overlay has no "__symbols__" node, but it has nodes without
"__overlay__" subnodes at the end (e.g. a "__fixups__" node), after
filling in all fragments for nodes with "__overlay__" subnodes,
"fragment = &fragments[cnt]" will point beyond the end of the allocated
array.
Hence writing to "fragment->overlay" will overwrite unallocated memory,
which may lead to a crash later.
Fix this by deferring both the assignment to "fragment" and the
offending write afterwards until we know for sure the node has an
"__overlay__" subnode, and thus a valid entry in "fragments[]".
Fixes: 61b4de4e0b384f4a ("of: overlay: minor restructuring")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
--
This applies to both v4.15-rc2 and Rob's for-next branch.
---
drivers/of/overlay.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c
index b8918e92d5a5268f..49b8939af6b201ca 100644
--- a/drivers/of/overlay.c
+++ b/drivers/of/overlay.c
@@ -572,9 +572,10 @@ static int init_overlay_changeset(struct overlay_changeset *ovcs,
cnt = 0;
for_each_child_of_node(tree, node) {
- fragment = &fragments[cnt];
- fragment->overlay = of_get_child_by_name(node, "__overlay__");
- if (fragment->overlay) {
+ overlay_node = of_get_child_by_name(node, "__overlay__");
+ if (overlay_node) {
+ fragment = &fragments[cnt];
+ fragment->overlay = overlay_node;
fragment->target = find_target_node(node);
if (!fragment->target) {
of_node_put(fragment->overlay);
--
2.7.4
^ permalink raw reply related
* [PATCH 0/2] of: overlay: Crash fix and improvement
From: Geert Uytterhoeven @ 2017-12-08 13:13 UTC (permalink / raw)
To: Pantelis Antoniou, Rob Herring, Frank Rowand
Cc: devicetree, linux-renesas-soc, linux-kernel, Geert Uytterhoeven
Hi Pantelis, Rob, Frank,
This patch series fixes memory corruption when applying overlays.
I first noticed this when using OF configfs. After lots of failed
debugging attempts, I bisected it to "of: overlay: add per overlay sysfs
attributes", which is not upstream. But that was a red herring: that
commit enlarged struct fragment to exactly 64-bytes, which just made it
more likely to cause random corruption when writing beyond the end of an
array of fragment structures. With the smaller structure size before,
such writes usually ended up in the unused holes between allocated
blocks, causing no harm.
The first patch is the real fix, and applies to both v4.15-rc2 and Rob's
for-next branch.
The second patch is a small improvement, and applies to Rob's for-next
branch only.
I've updated my topic/overlays and topic/renesas-overlays branches at
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
accordingly.
Thanks!
Geert Uytterhoeven (2):
of: overlay: Fix out-of-bounds write in init_overlay_changeset()
of: overlay: Make node skipping in init_overlay_changeset() clearer
drivers/of/overlay.c | 22 ++++++++++++----------
1 file changed, 12 insertions(+), 10 deletions(-)
--
2.7.4
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] dt-bindings: at24/eeprom: add an undocumented compatible string
From: Bartosz Golaszewski @ 2017-12-08 13:10 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: Rob Herring, Mark Rutland, Wolfram Sang, Divagar Mohandass,
David Lechner, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Linux Kernel
In-Reply-To: <CABxcv=mRfYTs0YPvFg5_T+PVdjnK2BgXe-_b6MVQ=UkSWrV6xw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-12-08 1:03 GMT+01:00 Javier Martinez Canillas <javier-0uQlZySMnqxg9hUCZPvPmw@public.gmane.org>:
> Hello Rob and Bartosz,
>
> On Thu, Dec 7, 2017 at 11:50 PM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>> On Wed, Dec 06, 2017 at 11:12:19AM +0100, Bartosz Golaszewski wrote:
>>> The "atmel,sdp" compatible is reported by checkpatch as undocumented.
>>>
>>> Add it to the device tree bindings document for at24.
>>>
>>> Signed-off-by: Bartosz Golaszewski <brgl-ARrdPY/1zhM@public.gmane.org>
>>> ---
>>> Documentation/devicetree/bindings/eeprom/eeprom.txt | 2 ++
>>> 1 file changed, 2 insertions(+)
>>
>> Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>
> My understanding is that DT bindings not necessarily have to list all
> the possible compatible strings but can also document a set
> comprehension of the possible values. If that's the case, then I
> disagree with this patch and I think that this is caused by a
> checkpatch limitation.
>
> In the case of the Atmel EEPROM DT binding, it was quite lax at
> describing the possible compatible strings. It just used to say:
>
> - compatible : should be "<manufacturer>,<type>", like these:
>
> Followed by a list of _possible_ compatible strings. So these were
> just examples, it was by no means a comprehensive list.
>
I couldn't find any info on that policy, but I would prefer as the
maintainer that this change and that we list all the compatibles in
the bindings explicitly.
> And then it used to say:
>
> If there is no specific driver for <manufacturer>, a generic driver
> based on <type> is selected. Possible types are:
> "24c00", "24c01", "24c02", "24c04", "24c08", "24c16", "24c32",
> "24c64", "24c128", "24c256", "24c512", "24c1024", "spd"
>
> Which basically said that it was valid to only match using the device
> model but not the vendor part of the compatible string. This is
> obviously incorrect and only worked due a implementation detail in the
> I2C core.
>
Indeed.
> After some discussions, the DT binding was changed to say the following:
>
> If there is no specific driver for <manufacturer>, a generic device
> with <type> and manufacturer "atmel" should be used. Possible types
> are:
> "24c00", "24c01", "24c02", "24c04", "24c08", "24c16", "24c32",
> "24c64", "24c128", "24c256", "24c512", "24c1024", "spd"
>
This basically says the same as the first part of the list of compatibles above.
> And the driver changed accordingly to honor these. Old DTBs just using
> "24c08" or "microchip,24c08" should still work, but the correct thing
> to do now is to use "atmel,24c08".
>
Maybe we could start converting all the incorrect compatibles? I only
found 19 occurrences in the tree.
> The "spd" <type> is in the list mentioned above, so the "atmel,spd"
> isn't documented as the $SUBJECT commit message says. In any case,
> what could be done is to instead reword the DT binding to list all the
> valid "atmel,<type>" combinations.
>
Yes, I believe this is correct. I'd like to just list all the accepted
compatibles and possibly mention the fact that old, incorrect
compatible strings still work, but will not be accepted anymore in the
tree.
> I didn't do that in my patch since it originally said "Possibles types
> are", not "all the possible types are" so it wasn't clear to me if
> there were other undocumented <types> that were still valid.
>
I'll send a new patch.
Thanks,
Bartosz
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 09/12] clk: qcom: Add Krait clock controller driver
From: Philippe Ombredanne @ 2017-12-08 13:10 UTC (permalink / raw)
To: Sricharan R
Cc: Stephen Boyd, mturquette,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-pm, linux-arm-msm, LKML, viresh.kumar,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <797300f7-d655-8df3-8597-099e44bd209c@codeaurora.org>
Sricharan,
On Fri, Dec 8, 2017 at 12:00 PM, Sricharan R <sricharan@codeaurora.org> wrote:
> Hi Philippe,
>
>
> On 12/8/2017 3:53 PM, Philippe Ombredanne wrote:
>> Sricharan, Stephen,
>>
>> On Fri, Dec 8, 2017 at 10:29 AM, Sricharan R <sricharan@codeaurora.org> wrote:
>>> From: Stephen Boyd <sboyd@codeaurora.org>
>>>
>>> The Krait CPU clocks are made up of a primary mux and secondary
>>> mux for each CPU and the L2, controlled via cp15 accessors. For
>>> Kraits within KPSSv1 each secondary mux accepts a different aux
>>> source, but on KPSSv2 each secondary mux accepts the same aux
>>> source.
>>>
>>> Cc: <devicetree@vger.kernel.org>
>>> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
>> []
>>> --- /dev/null
>>> +++ b/drivers/clk/qcom/krait-cc.c
>>> @@ -0,0 +1,350 @@
>>> +/* Copyright (c) 2013-2015, The Linux Foundation. All rights reserved.
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify
>>> + * it under the terms of the GNU General Public License version 2 and
>>> + * only version 2 as published by the Free Software Foundation.
>>> + *
>>> + * This program is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>>> + * GNU General Public License for more details.
>>> + */
>>
>> Have you considered using the new SPDX ids? Something like this:
>>
>> // SPDX-License-Identifier: GPL-2.0
>> // Copyright (c) 2013-2015, The Linux Foundation. All rights reserved.
>>
>> Beside being simpler and increasing the code to comment ratio by
>> deleting 9 lines of boilerplate, this will also save a few trees over
>> the long term each time that I print the source code of the kernel ;)
>> (do not worry, I am NOT as insane as to really print the kernel
>> sources, but someone more insane than me may well do it)
>>
>> You may wonder about the C++ // comment style I used here... Please
>> see Linus posts on the topic as well as Thomas doc patches overall for
>> instructions on using the SPDX ids.
>>
>> And if you were to do this for your past, present and future
>> contributions (eventually these of your group), I would be quite
>> grateful.
>>
>> Thank you for your kind consideration
>>
>
> Ha ok. will change it to use this one. Infact saw this feedback on other
> patches, but missed updating to it while sending.
Thanks!
--
Cordially
Philippe Ombredanne
^ permalink raw reply
* Re: [PATCH v9 3/6] clocksource: stm32: only use 32 bits timers
From: Benjamin Gaignard @ 2017-12-08 13:05 UTC (permalink / raw)
To: Daniel Lezcano
Cc: Rob Herring, Mark Rutland, Russell King - ARM Linux,
Maxime Coquelin, Alexandre Torgue, Thomas Gleixner, Arnd Bergmann,
devicetree, Linux ARM, Linux Kernel Mailing List
In-Reply-To: <56efa18e-481b-bd1b-7a54-db4a21073313@linaro.org>
2017-12-08 13:51 GMT+01:00 Daniel Lezcano <daniel.lezcano@linaro.org>:
> On 08/12/2017 12:32, Benjamin Gaignard wrote:
>> From: Benjamin Gaignard <benjamin.gaignard@linaro.org>
>>
>> The clock driving counters is at 90MHz so the maximum period
>> for 16 bis counters is around 728us (2^16 / 90.000.000).
>> For 32 bits counters this period is close 47 secondes which is
>> more acceptable.
>>
>> When using 16 bits counters the kernel may not be able to boot
>> because it has a too high overhead compare to the clockevent period.
>> Downgrading the rating of 16bits counter won't change anything
>> to this problem so this patch remove 16 bits counters support
>> and makes sure that they won't be probed anymore.
>
> Benjamin,
>
> there is an inconsistency in this description and the patchset. This is
> why it is so confusing to review and understand the purpose.
>
> Why are you preventing the clockevents to work with 16bits while the
> issue is related to the clocksource you introduce in the next patch ?
No the issue is existing also for clockevent because the max period is
around 728us so the interrupt will fire each 728us which is really too much.
>
> Also, why are you removing the DT nodes ?
>
> Accept to register the clocksource only if it is a 32bits timer. Let the
> clockevents to register themselves and have the rating to sort out the
> this. I do believe that is what Thomas asked you the first time.
>
> You can keep the hardware description in the DT and boot gracefully with
> the first 32bits timer succeeding the init.
>
> Take the time to think about it, comment and let's reach an agreement
> before you send another version, I'm tired to review again and again
> these stm32 timers.
>
> 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
>
--
Benjamin Gaignard
Graphic Study Group
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH v2 2/2] uio: Introduce UIO driver dt-binding documentation
From: Andrey Zhizhikin @ 2017-12-08 12:52 UTC (permalink / raw)
To: Rob Herring
Cc: Greg KH, mark.rutland-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171207234230.k62qpsgabqueewwd@rob-hp-laptop>
Hello Rob,
Thanks for your reply here!
>
> No. See prior discussions:
>
> https://lkml.org/lkml/2016/5/18/457
> https://lkml.org/lkml/2017/10/8/238
Just for my clarify; to understand how to move on with the patch:
Since UIO is not considered as a real HW and rather a aggregate, which
could be used for to wrap virtually any HW block - does that mean no
new dt-bindings would be accepted to it?
I agree it is really hard (and practically impossible) to create
compatible strings for all HW units potentially using UIO as a
container, therefore I can see clearly arguments here.
But if considered from a driver perspective: there is already DT
awareness in the UIO driver (specifically the pdrv-genirq), and we
have a "HW-like" functionality (irq handler, iomem and ioreg regions)
which could be covered by the DT bindings. What if those "generic"
properties that covers only those pieces of the UIO driver code could
be assigned corresponding dt-bindings? I believe it is not the best
and rather contradictory approach to not have any "compatible" string,
but as long as those driver parameters are covered by DT properties,
isn't it OK to have them?
I can assume a lot of people are using UIO in exactly this way:
defining a node in their DTS, assigning "compatible" via kernel
command line and having devnode instantiated. Why can't a possibility
be provided to them to have a generic description of how they can
configure, tweak and use their UIO drivers in the correct and
efficient way? This is especially true for people that are using FPGAs
and enveloping their Soft-IPs with UIO to have a generic
status/control capabilities. I cannot imagine how this tremendous
amount of variations could be easily accommodated inside UIO
compatible names...
Or am I completely missing a point here?
--
Regards,
Andrey.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v9 3/6] clocksource: stm32: only use 32 bits timers
From: Daniel Lezcano @ 2017-12-08 12:51 UTC (permalink / raw)
To: Benjamin Gaignard, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
mcoquelin.stm32-Re5JQEeQqe8AvxtiuMwx3w,
alexandre.torgue-qxv4g6HH51o, tglx-hfZtesqFncYOwBW4kG4KsQ,
arnd-r2nGTMty4D4
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171208113250.359-4-benjamin.gaignard-qxv4g6HH51o@public.gmane.org>
On 08/12/2017 12:32, Benjamin Gaignard wrote:
> From: Benjamin Gaignard <benjamin.gaignard-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>
> The clock driving counters is at 90MHz so the maximum period
> for 16 bis counters is around 728us (2^16 / 90.000.000).
> For 32 bits counters this period is close 47 secondes which is
> more acceptable.
>
> When using 16 bits counters the kernel may not be able to boot
> because it has a too high overhead compare to the clockevent period.
> Downgrading the rating of 16bits counter won't change anything
> to this problem so this patch remove 16 bits counters support
> and makes sure that they won't be probed anymore.
Benjamin,
there is an inconsistency in this description and the patchset. This is
why it is so confusing to review and understand the purpose.
Why are you preventing the clockevents to work with 16bits while the
issue is related to the clocksource you introduce in the next patch ?
Also, why are you removing the DT nodes ?
Accept to register the clocksource only if it is a 32bits timer. Let the
clockevents to register themselves and have the rating to sort out the
this. I do believe that is what Thomas asked you the first time.
You can keep the hardware description in the DT and boot gracefully with
the first 32bits timer succeeding the init.
Take the time to think about it, comment and let's reach an agreement
before you send another version, I'm tired to review again and again
these stm32 timers.
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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 17/33] nds32: VDSO support
From: Greentime Hu @ 2017-12-08 12:46 UTC (permalink / raw)
To: Marc Zyngier
Cc: Mark Rutland, Greentime, Linux Kernel Mailing List, Arnd Bergmann,
linux-arch, Thomas Gleixner, Jason Cooper, Rob Herring, netdev,
Vincent Chen, DTML, Al Viro, David Howells, Will Deacon,
Daniel Lezcano, linux-serial-u79uwXL29TY76Z2rM5mHXA,
Geert Uytterhoeven, Linus Walleij, Greg KH, Vincent Chen
In-Reply-To: <f58c7052-c2fe-5704-a03b-41bf2e3b20b9-5wv7dgnIgG8@public.gmane.org>
Hi, Marc:
2017-12-08 20:29 GMT+08:00 Marc Zyngier <marc.zyngier-5wv7dgnIgG8@public.gmane.org>:
> On 08/12/17 11:54, Greentime Hu wrote:
>> Hi, Mark:
>>
>> 2017-12-08 18:21 GMT+08:00 Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>:
>>> On Fri, Dec 08, 2017 at 05:12:00PM +0800, Greentime Hu wrote:
>>>> From: Greentime Hu <greentime-MUIXKm3Oiri1Z/+hSey0Gg@public.gmane.org>
>>>>
>>>> This patch adds VDSO support. The VDSO code is currently used for
>>>> sys_rt_sigreturn() and optimised gettimeofday() (using the SoC timer counter).
>>>
>>> [...]
>>>
>>>> +static int grab_timer_node_info(void)
>>>> +{
>>>> + struct device_node *timer_node;
>>>> +
>>>> + timer_node = of_find_node_by_name(NULL, "timer");
>>>
>>> Please use a compatible string, rather than matching the timer by name.
>>>
>>> It's plausible that you have multiple nodes called "timer" in the DT,
>>> under different parent nodes, and this might not be the device you
>>> think it is. I see your dt in patch 24 has two timer nodes.
>>>
>>> It would be best if your clocksource driver exposed some stuct that you
>>> looked at here, so that you're guaranteed to user the same device.
>>
>> We'd like to use "timer" here because there are 2 different timer IPs
>> and we are sure that they won't be in the same SoC.
>> We think this implementation in VDSO should be platform independent to
>> get cycle-count register.
>> Our customer or other SoC provider who can use "timer" and define
>> cycle-count-offset or cycle-count-down then we can get the correct
>> cycle-count.
>>
>> We sent atcpit100 patch last time along with our arch, however we'd
>> like to send it to its sub system this time and my colleague is still
>> working on it.
>> He may send the timer patch next week.
>>
>>
>>>> + of_property_read_u32(timer_node, "cycle-count-offset",
>>>> + &vdso_data->cycle_count_offset);
>>>> + vdso_data->cycle_count_down =
>>>> + of_property_read_bool(timer_node, "cycle-count-down");
>>>
>>> ... and then you'd only need to parse these in one place, too.
>>>
>>> IIUC these are proeprties for the atcpit device, which has no
>>> documentation or driver in this series.
>>>
>>> So I'm rather confused as to what's going on here.
>>>
>>
>> These properties are defined in dts which can provide the cycle count
>> register offset address of that timer, so that we can get cycle-count.
>>
>>>> + return of_address_to_resource(timer_node, 0, &timer_res);
>>>> +}
>>>
>>>> +int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
>>>> +{
>>>
>>>> + /*Map timer to user space */
>>>> + vdso_base += PAGE_SIZE;
>>>> + prot = __pgprot(_PAGE_V | _PAGE_M_UR_KR | _PAGE_D |
>>>> + _PAGE_G | _PAGE_C_DEV);
>>>> + ret = io_remap_pfn_range(vma, vdso_base, timer_res.start >> PAGE_SHIFT,
>>>> + PAGE_SIZE, prot);
>>>> + if (ret)
>>>> + goto up_fail;
>>>
>>> Maybe this is fine, but it looks a bit suspicious.
>>>
>>> Is it safe to map IO memory to a userspace process like this?
>>>
>>> In general that isn't safe, since userspace could access other registers
>>> (if those exist), perform accesses that change the state of hardware, or
>>> make unsupported access types (e.g. unaligned, atomic) that result in
>>> errors the kernel can't handle.
>>>
>>> Does none of that apply here?
>>
>> We only provide read permission to this page so hareware state won't
>> be chagned. It will trigger exception if we try to write.
>> We will check about the alignment/atomic issue of this region.
>
> It still feels a bit odd. A hostile userspace could potentially find out
> about what the kernel is doing. For example, if the deadline of the next
> timer is accessible by reading that page, userspace could infer a lot of
> things that we'd normally want to keep hidden. Not knowing this HW, I
> cannot answer that question, but maybe you can.
>
> Another question: MMIO accesses can be quite slow. How much do you gain
> by having a vdso compared to executing a system call?
>
I think the rest of the timer registers should be fine to be read.
Anyway we will discuss about the security issue.
Based on our previous experiments.
Decrease 4,519,021 (47%) cycle count for executing gettimeofday()
with: without vDSO(using syscall) = 5,091,342 : 9,610,363
The cycle count was get by CPU performance monitor.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 17/33] nds32: VDSO support
From: Marc Zyngier @ 2017-12-08 12:29 UTC (permalink / raw)
To: Greentime Hu, Mark Rutland
Cc: Greentime, Linux Kernel Mailing List, Arnd Bergmann, linux-arch,
Thomas Gleixner, Jason Cooper, Rob Herring, netdev, Vincent Chen,
DTML, Al Viro, David Howells, Will Deacon, Daniel Lezcano,
linux-serial, Geert Uytterhoeven, Linus Walleij, Greg KH,
Vincent Chen
In-Reply-To: <CAEbi=3e9Ep4_DL4SSwp15as1t7ALvw-s2gqv+NsuRZiebNGFAQ@mail.gmail.com>
On 08/12/17 11:54, Greentime Hu wrote:
> Hi, Mark:
>
> 2017-12-08 18:21 GMT+08:00 Mark Rutland <mark.rutland@arm.com>:
>> On Fri, Dec 08, 2017 at 05:12:00PM +0800, Greentime Hu wrote:
>>> From: Greentime Hu <greentime@andestech.com>
>>>
>>> This patch adds VDSO support. The VDSO code is currently used for
>>> sys_rt_sigreturn() and optimised gettimeofday() (using the SoC timer counter).
>>
>> [...]
>>
>>> +static int grab_timer_node_info(void)
>>> +{
>>> + struct device_node *timer_node;
>>> +
>>> + timer_node = of_find_node_by_name(NULL, "timer");
>>
>> Please use a compatible string, rather than matching the timer by name.
>>
>> It's plausible that you have multiple nodes called "timer" in the DT,
>> under different parent nodes, and this might not be the device you
>> think it is. I see your dt in patch 24 has two timer nodes.
>>
>> It would be best if your clocksource driver exposed some stuct that you
>> looked at here, so that you're guaranteed to user the same device.
>
> We'd like to use "timer" here because there are 2 different timer IPs
> and we are sure that they won't be in the same SoC.
> We think this implementation in VDSO should be platform independent to
> get cycle-count register.
> Our customer or other SoC provider who can use "timer" and define
> cycle-count-offset or cycle-count-down then we can get the correct
> cycle-count.
>
> We sent atcpit100 patch last time along with our arch, however we'd
> like to send it to its sub system this time and my colleague is still
> working on it.
> He may send the timer patch next week.
>
>
>>> + of_property_read_u32(timer_node, "cycle-count-offset",
>>> + &vdso_data->cycle_count_offset);
>>> + vdso_data->cycle_count_down =
>>> + of_property_read_bool(timer_node, "cycle-count-down");
>>
>> ... and then you'd only need to parse these in one place, too.
>>
>> IIUC these are proeprties for the atcpit device, which has no
>> documentation or driver in this series.
>>
>> So I'm rather confused as to what's going on here.
>>
>
> These properties are defined in dts which can provide the cycle count
> register offset address of that timer, so that we can get cycle-count.
>
>>> + return of_address_to_resource(timer_node, 0, &timer_res);
>>> +}
>>
>>> +int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
>>> +{
>>
>>> + /*Map timer to user space */
>>> + vdso_base += PAGE_SIZE;
>>> + prot = __pgprot(_PAGE_V | _PAGE_M_UR_KR | _PAGE_D |
>>> + _PAGE_G | _PAGE_C_DEV);
>>> + ret = io_remap_pfn_range(vma, vdso_base, timer_res.start >> PAGE_SHIFT,
>>> + PAGE_SIZE, prot);
>>> + if (ret)
>>> + goto up_fail;
>>
>> Maybe this is fine, but it looks a bit suspicious.
>>
>> Is it safe to map IO memory to a userspace process like this?
>>
>> In general that isn't safe, since userspace could access other registers
>> (if those exist), perform accesses that change the state of hardware, or
>> make unsupported access types (e.g. unaligned, atomic) that result in
>> errors the kernel can't handle.
>>
>> Does none of that apply here?
>
> We only provide read permission to this page so hareware state won't
> be chagned. It will trigger exception if we try to write.
> We will check about the alignment/atomic issue of this region.
It still feels a bit odd. A hostile userspace could potentially find out
about what the kernel is doing. For example, if the deadline of the next
timer is accessible by reading that page, userspace could infer a lot of
things that we'd normally want to keep hidden. Not knowing this HW, I
cannot answer that question, but maybe you can.
Another question: MMIO accesses can be quite slow. How much do you gain
by having a vdso compared to executing a system call?
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* Re: [PATCH v3 17/33] nds32: VDSO support
From: Mark Rutland @ 2017-12-08 12:14 UTC (permalink / raw)
To: Greentime Hu
Cc: Greentime, Linux Kernel Mailing List, Arnd Bergmann, linux-arch,
Thomas Gleixner, Jason Cooper, Marc Zyngier, Rob Herring, netdev,
Vincent Chen, DTML, Al Viro, David Howells, Will Deacon,
Daniel Lezcano, linux-serial, Geert Uytterhoeven, Linus Walleij,
Greg KH, Vincent Chen
In-Reply-To: <CAEbi=3e9Ep4_DL4SSwp15as1t7ALvw-s2gqv+NsuRZiebNGFAQ@mail.gmail.com>
On Fri, Dec 08, 2017 at 07:54:42PM +0800, Greentime Hu wrote:
> 2017-12-08 18:21 GMT+08:00 Mark Rutland <mark.rutland@arm.com>:
> > On Fri, Dec 08, 2017 at 05:12:00PM +0800, Greentime Hu wrote:
> >> +static int grab_timer_node_info(void)
> >> +{
> >> + struct device_node *timer_node;
> >> +
> >> + timer_node = of_find_node_by_name(NULL, "timer");
> >
> > Please use a compatible string, rather than matching the timer by name.
> >
> > It's plausible that you have multiple nodes called "timer" in the DT,
> > under different parent nodes, and this might not be the device you
> > think it is. I see your dt in patch 24 has two timer nodes.
> >
> > It would be best if your clocksource driver exposed some stuct that you
> > looked at here, so that you're guaranteed to user the same device.
>
> We'd like to use "timer" here because there are 2 different timer IPs
> and we are sure that they won't be in the same SoC.
> We think this implementation in VDSO should be platform independent to
> get cycle-count register.
> Our customer or other SoC provider who can use "timer" and define
> cycle-count-offset or cycle-count-down then we can get the correct
> cycle-count.
This is not the right way to do things.
So from a DT perspective, NAK.
You should not add properties to arbitrary DT bindings to handle a Linux
implementation detail.
Please remove this DT code, and have the drivers for those timer blocks
export this information to your vdso code somehow.
> We sent atcpit100 patch last time along with our arch, however we'd
> like to send it to its sub system this time and my colleague is still
> working on it.
> He may send the timer patch next week.
I think that it would make sense for that patch to be part of the arch
port, especially given that (AFAICT) there is no dirver for the other
timer IP that you mention.
[...]
> >> +int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
> >> +{
> >
> >> + /*Map timer to user space */
> >> + vdso_base += PAGE_SIZE;
> >> + prot = __pgprot(_PAGE_V | _PAGE_M_UR_KR | _PAGE_D |
> >> + _PAGE_G | _PAGE_C_DEV);
> >> + ret = io_remap_pfn_range(vma, vdso_base, timer_res.start >> PAGE_SHIFT,
> >> + PAGE_SIZE, prot);
> >> + if (ret)
> >> + goto up_fail;
> >
> > Maybe this is fine, but it looks a bit suspicious.
> >
> > Is it safe to map IO memory to a userspace process like this?
> >
> > In general that isn't safe, since userspace could access other registers
> > (if those exist), perform accesses that change the state of hardware, or
> > make unsupported access types (e.g. unaligned, atomic) that result in
> > errors the kernel can't handle.
> >
> > Does none of that apply here?
>
> We only provide read permission to this page so hareware state won't
> be chagned. It will trigger exception if we try to write.
> We will check about the alignment/atomic issue of this region.
Ok, thanks.
This is another reason to only do this for devices/drivers that we have
drivers for, since we can't know that this is safe in general.
Thanks,
Mark.
^ permalink raw reply
* Re: [PATCH v3 17/33] nds32: VDSO support
From: Greentime Hu @ 2017-12-08 11:54 UTC (permalink / raw)
To: Mark Rutland
Cc: Greentime, Linux Kernel Mailing List, Arnd Bergmann, linux-arch,
Thomas Gleixner, Jason Cooper, Marc Zyngier, Rob Herring, netdev,
Vincent Chen, DTML, Al Viro, David Howells, Will Deacon,
Daniel Lezcano, linux-serial, Geert Uytterhoeven, Linus Walleij,
Greg KH, Vincent Chen
In-Reply-To: <20171208102149.iqiieszktwzorkuw@lakrids.cambridge.arm.com>
Hi, Mark:
2017-12-08 18:21 GMT+08:00 Mark Rutland <mark.rutland@arm.com>:
> On Fri, Dec 08, 2017 at 05:12:00PM +0800, Greentime Hu wrote:
>> From: Greentime Hu <greentime@andestech.com>
>>
>> This patch adds VDSO support. The VDSO code is currently used for
>> sys_rt_sigreturn() and optimised gettimeofday() (using the SoC timer counter).
>
> [...]
>
>> +static int grab_timer_node_info(void)
>> +{
>> + struct device_node *timer_node;
>> +
>> + timer_node = of_find_node_by_name(NULL, "timer");
>
> Please use a compatible string, rather than matching the timer by name.
>
> It's plausible that you have multiple nodes called "timer" in the DT,
> under different parent nodes, and this might not be the device you
> think it is. I see your dt in patch 24 has two timer nodes.
>
> It would be best if your clocksource driver exposed some stuct that you
> looked at here, so that you're guaranteed to user the same device.
We'd like to use "timer" here because there are 2 different timer IPs
and we are sure that they won't be in the same SoC.
We think this implementation in VDSO should be platform independent to
get cycle-count register.
Our customer or other SoC provider who can use "timer" and define
cycle-count-offset or cycle-count-down then we can get the correct
cycle-count.
We sent atcpit100 patch last time along with our arch, however we'd
like to send it to its sub system this time and my colleague is still
working on it.
He may send the timer patch next week.
>> + of_property_read_u32(timer_node, "cycle-count-offset",
>> + &vdso_data->cycle_count_offset);
>> + vdso_data->cycle_count_down =
>> + of_property_read_bool(timer_node, "cycle-count-down");
>
> ... and then you'd only need to parse these in one place, too.
>
> IIUC these are proeprties for the atcpit device, which has no
> documentation or driver in this series.
>
> So I'm rather confused as to what's going on here.
>
These properties are defined in dts which can provide the cycle count
register offset address of that timer, so that we can get cycle-count.
>> + return of_address_to_resource(timer_node, 0, &timer_res);
>> +}
>
>> +int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
>> +{
>
>> + /*Map timer to user space */
>> + vdso_base += PAGE_SIZE;
>> + prot = __pgprot(_PAGE_V | _PAGE_M_UR_KR | _PAGE_D |
>> + _PAGE_G | _PAGE_C_DEV);
>> + ret = io_remap_pfn_range(vma, vdso_base, timer_res.start >> PAGE_SHIFT,
>> + PAGE_SIZE, prot);
>> + if (ret)
>> + goto up_fail;
>
> Maybe this is fine, but it looks a bit suspicious.
>
> Is it safe to map IO memory to a userspace process like this?
>
> In general that isn't safe, since userspace could access other registers
> (if those exist), perform accesses that change the state of hardware, or
> make unsupported access types (e.g. unaligned, atomic) that result in
> errors the kernel can't handle.
>
> Does none of that apply here?
We only provide read permission to this page so hareware state won't
be chagned. It will trigger exception if we try to write.
We will check about the alignment/atomic issue of this region.
Thanks.
^ permalink raw reply
* [PATCH v9 6/6] arm: dts: stm32: remove useless clocksource nodes
From: Benjamin Gaignard @ 2017-12-08 11:32 UTC (permalink / raw)
To: robh+dt, mark.rutland, linux, mcoquelin.stm32, alexandre.torgue,
daniel.lezcano, tglx, arnd
Cc: devicetree, linux-arm-kernel, linux-kernel, Benjamin Gaignard
In-Reply-To: <20171208113250.359-1-benjamin.gaignard@st.com>
From: Benjamin Gaignard <benjamin.gaignard@linaro.org>
16 bits timers aren't accurate enough to be used as
clocksource, remove them from stm32f4 and stm32f7 devicetree.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
---
arch/arm/boot/dts/stm32f429.dtsi | 32 --------------------------------
arch/arm/boot/dts/stm32f746.dtsi | 32 --------------------------------
2 files changed, 64 deletions(-)
diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
index 10099df8b73e..b507e04a52c6 100644
--- a/arch/arm/boot/dts/stm32f429.dtsi
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -107,14 +107,6 @@
};
};
- timer3: timer@40000400 {
- compatible = "st,stm32-timer";
- reg = <0x40000400 0x400>;
- interrupts = <29>;
- clocks = <&rcc 0 STM32F4_APB1_CLOCK(TIM3)>;
- status = "disabled";
- };
-
timers3: timers@40000400 {
#address-cells = <1>;
#size-cells = <0>;
@@ -136,14 +128,6 @@
};
};
- timer4: timer@40000800 {
- compatible = "st,stm32-timer";
- reg = <0x40000800 0x400>;
- interrupts = <30>;
- clocks = <&rcc 0 STM32F4_APB1_CLOCK(TIM4)>;
- status = "disabled";
- };
-
timers4: timers@40000800 {
#address-cells = <1>;
#size-cells = <0>;
@@ -193,14 +177,6 @@
};
};
- timer6: timer@40001000 {
- compatible = "st,stm32-timer";
- reg = <0x40001000 0x400>;
- interrupts = <54>;
- clocks = <&rcc 0 STM32F4_APB1_CLOCK(TIM6)>;
- status = "disabled";
- };
-
timers6: timers@40001000 {
#address-cells = <1>;
#size-cells = <0>;
@@ -217,14 +193,6 @@
};
};
- timer7: timer@40001400 {
- compatible = "st,stm32-timer";
- reg = <0x40001400 0x400>;
- interrupts = <55>;
- clocks = <&rcc 0 STM32F4_APB1_CLOCK(TIM7)>;
- status = "disabled";
- };
-
timers7: timers@40001400 {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/arch/arm/boot/dts/stm32f746.dtsi b/arch/arm/boot/dts/stm32f746.dtsi
index 5f66d151eedb..bb3e262bd456 100644
--- a/arch/arm/boot/dts/stm32f746.dtsi
+++ b/arch/arm/boot/dts/stm32f746.dtsi
@@ -103,14 +103,6 @@
};
};
- timer3: timer@40000400 {
- compatible = "st,stm32-timer";
- reg = <0x40000400 0x400>;
- interrupts = <29>;
- clocks = <&rcc 0 STM32F7_APB1_CLOCK(TIM3)>;
- status = "disabled";
- };
-
timers3: timers@40000400 {
#address-cells = <1>;
#size-cells = <0>;
@@ -132,14 +124,6 @@
};
};
- timer4: timer@40000800 {
- compatible = "st,stm32-timer";
- reg = <0x40000800 0x400>;
- interrupts = <30>;
- clocks = <&rcc 0 STM32F7_APB1_CLOCK(TIM4)>;
- status = "disabled";
- };
-
timers4: timers@40000800 {
#address-cells = <1>;
#size-cells = <0>;
@@ -189,14 +173,6 @@
};
};
- timer6: timer@40001000 {
- compatible = "st,stm32-timer";
- reg = <0x40001000 0x400>;
- interrupts = <54>;
- clocks = <&rcc 0 STM32F7_APB1_CLOCK(TIM6)>;
- status = "disabled";
- };
-
timers6: timers@40001000 {
#address-cells = <1>;
#size-cells = <0>;
@@ -213,14 +189,6 @@
};
};
- timer7: timer@40001400 {
- compatible = "st,stm32-timer";
- reg = <0x40001400 0x400>;
- interrupts = <55>;
- clocks = <&rcc 0 STM32F7_APB1_CLOCK(TIM7)>;
- status = "disabled";
- };
-
timers7: timers@40001400 {
#address-cells = <1>;
#size-cells = <0>;
--
2.15.0
^ permalink raw reply related
* [PATCH v9 5/6] clocksource: stm32: Update license and copyright
From: Benjamin Gaignard @ 2017-12-08 11:32 UTC (permalink / raw)
To: robh+dt, mark.rutland, linux, mcoquelin.stm32, alexandre.torgue,
daniel.lezcano, tglx, arnd
Cc: devicetree, linux-arm-kernel, linux-kernel, Benjamin Gaignard
In-Reply-To: <20171208113250.359-1-benjamin.gaignard@st.com>
Adopt SPDX License Identifier and add STMicroelectronics
copyright
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
---
drivers/clocksource/timer-stm32.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/clocksource/timer-stm32.c b/drivers/clocksource/timer-stm32.c
index c9aed2314194..21479c3cfcb9 100644
--- a/drivers/clocksource/timer-stm32.c
+++ b/drivers/clocksource/timer-stm32.c
@@ -1,7 +1,9 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* Copyright (C) Maxime Coquelin 2015
+ * Copyright (C) STMicroelectronics 2017 - All Rights Reserved
* Author: Maxime Coquelin <mcoquelin.stm32@gmail.com>
- * License terms: GNU General Public License (GPL), version 2
+ * Author: Benjamin Gaignard <benjamin.gaignard@st.com> for STMicroelectronics.
*
* Inspired by time-efm32.c from Uwe Kleine-Koenig
*/
--
2.15.0
^ permalink raw reply related
* [PATCH v9 4/6] clocksource: stm32: add clocksource support
From: Benjamin Gaignard @ 2017-12-08 11:32 UTC (permalink / raw)
To: robh+dt, mark.rutland, linux, mcoquelin.stm32, alexandre.torgue,
daniel.lezcano, tglx, arnd
Cc: devicetree, linux-arm-kernel, linux-kernel, Benjamin Gaignard,
Benjamin Gaignard
In-Reply-To: <20171208113250.359-1-benjamin.gaignard@st.com>
The stm32 timer hardware is currently only used as a clock event device,
but it can be utilized as a clocksource as well.
Implement this by enabling the free running counter in the hardware block
and converting the clock event part from a count down event timer to a
comparator based timer.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
---
drivers/clocksource/timer-stm32.c | 116 +++++++++++++++++++++++++++++---------
1 file changed, 88 insertions(+), 28 deletions(-)
diff --git a/drivers/clocksource/timer-stm32.c b/drivers/clocksource/timer-stm32.c
index 707808d91bf0..c9aed2314194 100644
--- a/drivers/clocksource/timer-stm32.c
+++ b/drivers/clocksource/timer-stm32.c
@@ -16,6 +16,8 @@
#include <linux/of_irq.h>
#include <linux/clk.h>
#include <linux/reset.h>
+#include <linux/sched_clock.h>
+#include <linux/slab.h>
#include "timer-of.h"
@@ -23,16 +25,16 @@
#define TIM_DIER 0x0c
#define TIM_SR 0x10
#define TIM_EGR 0x14
+#define TIM_CNT 0x24
#define TIM_PSC 0x28
#define TIM_ARR 0x2c
+#define TIM_CCR1 0x34
#define TIM_CR1_CEN BIT(0)
-#define TIM_CR1_OPM BIT(3)
+#define TIM_CR1_UDIS BIT(1)
#define TIM_CR1_ARPE BIT(7)
-#define TIM_DIER_UIE BIT(0)
-
-#define TIM_SR_UIF BIT(0)
+#define TIM_DIER_CC1IE BIT(1)
#define TIM_EGR_UG BIT(0)
@@ -46,28 +48,44 @@ static int stm32_clock_event_shutdown(struct clock_event_device *evt)
{
struct timer_of *to = to_timer_of(evt);
- writel_relaxed(0, timer_of_base(to) + TIM_CR1);
+ writel_relaxed(0, timer_of_base(to) + TIM_DIER);
+
return 0;
}
-static int stm32_clock_event_set_periodic(struct clock_event_device *evt)
+static int stm32_clock_event_set_next_event(unsigned long evt,
+ struct clock_event_device *clkevt)
{
- struct timer_of *to = to_timer_of(evt);
+ struct timer_of *to = to_timer_of(clkevt);
+ unsigned long now, next;
- writel_relaxed(timer_of_period(to), timer_of_base(to) + TIM_ARR);
- writel_relaxed(TIM_CR1_ARPE | TIM_CR1_CEN, timer_of_base(to) + TIM_CR1);
+ next = readl_relaxed(timer_of_base(to) + TIM_CNT) + evt;
+ writel_relaxed(next, timer_of_base(to) + TIM_CCR1);
+ now = readl_relaxed(timer_of_base(to) + TIM_CNT);
+
+ if ((next - now) > evt)
+ return -ETIME;
+
+ writel_relaxed(TIM_DIER_CC1IE, timer_of_base(to) + TIM_DIER);
return 0;
}
-static int stm32_clock_event_set_next_event(unsigned long evt,
- struct clock_event_device *clkevt)
+static int stm32_clock_event_set_periodic(struct clock_event_device *evt)
{
- struct timer_of *to = to_timer_of(clkevt);
+ struct timer_of *to = to_timer_of(evt);
- writel_relaxed(evt, timer_of_base(to) + TIM_ARR);
- writel_relaxed(TIM_CR1_ARPE | TIM_CR1_OPM | TIM_CR1_CEN,
- timer_of_base(to) + TIM_CR1);
+ return stm32_clock_event_set_next_event(timer_of_period(to), evt);
+}
+
+static int stm32_clock_event_set_oneshot(struct clock_event_device *evt)
+{
+ struct timer_of *to = to_timer_of(evt);
+ unsigned long val;
+
+ val = readl_relaxed(timer_of_base(to) + TIM_CNT);
+ writel_relaxed(val, timer_of_base(to) + TIM_CCR1);
+ writel_relaxed(TIM_DIER_CC1IE, timer_of_base(to) + TIM_DIER);
return 0;
}
@@ -79,6 +97,11 @@ static irqreturn_t stm32_clock_event_handler(int irq, void *dev_id)
writel_relaxed(0, timer_of_base(to) + TIM_SR);
+ if (clockevent_state_periodic(evt))
+ stm32_clock_event_set_periodic(evt);
+ else
+ stm32_clock_event_shutdown(evt);
+
evt->event_handler(evt);
return IRQ_HANDLED;
@@ -89,7 +112,48 @@ static bool stm32_timer_is_32bits(struct timer_of *to)
return readl_relaxed(timer_of_base(to) + TIM_ARR) == ~0UL;
}
-static int __init stm32_clockevent_init(struct device_node *node)
+static void __init stm32_clockevent_init(struct timer_of *to)
+{
+ writel_relaxed(0, timer_of_base(to) + TIM_DIER);
+ writel_relaxed(0, timer_of_base(to) + TIM_SR);
+
+ clockevents_config_and_register(&to->clkevt,
+ timer_of_rate(to), MIN_DELTA, ~0U);
+}
+
+static void __iomem *stm32_timer_cnt __read_mostly;
+
+static u64 notrace stm32_read_sched_clock(void)
+{
+ return readl_relaxed(stm32_timer_cnt);
+}
+
+static int __init stm32_clocksource_init(struct timer_of *to)
+{
+ writel_relaxed(~0U, timer_of_base(to) + TIM_ARR);
+ writel_relaxed(0, timer_of_base(to) + TIM_PSC);
+ writel_relaxed(0, timer_of_base(to) + TIM_SR);
+ writel_relaxed(0, timer_of_base(to) + TIM_DIER);
+ writel_relaxed(0, timer_of_base(to) + TIM_SR);
+ writel_relaxed(TIM_CR1_ARPE | TIM_CR1_UDIS,
+ timer_of_base(to) + TIM_CR1);
+
+ /* Make sure that registers are updated */
+ writel_relaxed(TIM_EGR_UG, timer_of_base(to) + TIM_EGR);
+
+ /* Enable controller */
+ writel_relaxed(TIM_CR1_ARPE | TIM_CR1_UDIS | TIM_CR1_CEN,
+ timer_of_base(to) + TIM_CR1);
+
+ stm32_timer_cnt = timer_of_base(to) + TIM_CNT;
+ sched_clock_register(stm32_read_sched_clock, 32, timer_of_rate(to));
+
+ return clocksource_mmio_init(stm32_timer_cnt, "stm32_timer",
+ timer_of_rate(to), 250, 32,
+ clocksource_mmio_readl_up);
+}
+
+static int __init stm32_timer_init(struct device_node *node)
{
struct reset_control *rstc;
struct timer_of *to;
@@ -100,12 +164,13 @@ static int __init stm32_clockevent_init(struct device_node *node)
return -ENOMEM;
to->flags = TIMER_OF_IRQ | TIMER_OF_CLOCK | TIMER_OF_BASE;
+
to->clkevt.name = "stm32_clockevent";
to->clkevt.rating = 200;
- to->clkevt.features = CLOCK_EVT_FEAT_PERIODIC;
+ to->clkevt.features = CLOCK_EVT_FEAT_ONESHOT | CLOCK_EVT_FEAT_PERIODIC;
to->clkevt.set_state_shutdown = stm32_clock_event_shutdown;
to->clkevt.set_state_periodic = stm32_clock_event_set_periodic;
- to->clkevt.set_state_oneshot = stm32_clock_event_shutdown;
+ to->clkevt.set_state_oneshot = stm32_clock_event_set_oneshot;
to->clkevt.tick_resume = stm32_clock_event_shutdown;
to->clkevt.set_next_event = stm32_clock_event_set_next_event;
@@ -128,16 +193,11 @@ static int __init stm32_clockevent_init(struct device_node *node)
goto deinit;
}
- writel_relaxed(0, timer_of_base(to) + TIM_ARR);
-
- writel_relaxed(0, timer_of_base(to) + TIM_PSC);
- writel_relaxed(TIM_EGR_UG, timer_of_base(to) + TIM_EGR);
- writel_relaxed(TIM_DIER_UIE, timer_of_base(to) + TIM_DIER);
- writel_relaxed(0, timer_of_base(to) + TIM_SR);
+ ret = stm32_clocksource_init(to);
+ if (ret)
+ goto deinit;
- clockevents_config_and_register(&to->clkevt,
- timer_of_period(to),
- MIN_DELTA, ~0U);
+ stm32_clockevent_init(to);
return 0;
@@ -148,4 +208,4 @@ static int __init stm32_clockevent_init(struct device_node *node)
return ret;
}
-TIMER_OF_DECLARE(stm32, "st,stm32-timer", stm32_clockevent_init);
+TIMER_OF_DECLARE(stm32, "st,stm32-timer", stm32_timer_init);
--
2.15.0
^ permalink raw reply related
* [PATCH v9 3/6] clocksource: stm32: only use 32 bits timers
From: Benjamin Gaignard @ 2017-12-08 11:32 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-I+IVW8TIWO2tmTQ+vhA3Yw,
mcoquelin.stm32-Re5JQEeQqe8AvxtiuMwx3w,
alexandre.torgue-qxv4g6HH51o,
daniel.lezcano-QSEj5FYQhm4dnm+yROfE0A,
tglx-hfZtesqFncYOwBW4kG4KsQ, arnd-r2nGTMty4D4
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Benjamin Gaignard
In-Reply-To: <20171208113250.359-1-benjamin.gaignard-qxv4g6HH51o@public.gmane.org>
From: Benjamin Gaignard <benjamin.gaignard-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
The clock driving counters is at 90MHz so the maximum period
for 16 bis counters is around 728us (2^16 / 90.000.000).
For 32 bits counters this period is close 47 secondes which is
more acceptable.
When using 16 bits counters the kernel may not be able to boot
because it has a too high overhead compare to the clockevent period.
Downgrading the rating of 16bits counter won't change anything
to this problem so this patch remove 16 bits counters support
and makes sure that they won't be probed anymore.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
drivers/clocksource/timer-stm32.c | 30 +++++++++++++++---------------
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/clocksource/timer-stm32.c b/drivers/clocksource/timer-stm32.c
index a45f1f1cd040..707808d91bf0 100644
--- a/drivers/clocksource/timer-stm32.c
+++ b/drivers/clocksource/timer-stm32.c
@@ -84,12 +84,16 @@ static irqreturn_t stm32_clock_event_handler(int irq, void *dev_id)
return IRQ_HANDLED;
}
+static bool stm32_timer_is_32bits(struct timer_of *to)
+{
+ return readl_relaxed(timer_of_base(to) + TIM_ARR) == ~0UL;
+}
+
static int __init stm32_clockevent_init(struct device_node *node)
{
struct reset_control *rstc;
- unsigned long max_delta;
- int ret, bits, prescaler = 1;
struct timer_of *to;
+ int ret;
to = kzalloc(sizeof(*to), GFP_KERNEL);
if (!to)
@@ -118,31 +122,27 @@ static int __init stm32_clockevent_init(struct device_node *node)
}
/* Detect whether the timer is 16 or 32 bits */
- writel_relaxed(~0U, timer_of_base(to) + TIM_ARR);
- max_delta = readl_relaxed(timer_of_base(to) + TIM_ARR);
- if (max_delta == ~0U) {
- prescaler = 1;
- bits = 32;
- } else {
- prescaler = 1024;
- bits = 16;
+ if (!stm32_timer_is_32bits(to)) {
+ pr_warn("Timer %pOF is a 16 bits timer\n", node);
+ ret = -EINVAL;
+ goto deinit;
}
+
writel_relaxed(0, timer_of_base(to) + TIM_ARR);
- writel_relaxed(prescaler - 1, timer_of_base(to) + TIM_PSC);
+ writel_relaxed(0, timer_of_base(to) + TIM_PSC);
writel_relaxed(TIM_EGR_UG, timer_of_base(to) + TIM_EGR);
writel_relaxed(TIM_DIER_UIE, timer_of_base(to) + TIM_DIER);
writel_relaxed(0, timer_of_base(to) + TIM_SR);
clockevents_config_and_register(&to->clkevt,
timer_of_period(to),
- MIN_DELTA, max_delta);
-
- pr_info("%pOF: STM32 clockevent driver initialized (%d bits)\n",
- node, bits);
+ MIN_DELTA, ~0U);
return 0;
+deinit:
+ timer_of_cleanup(to);
err:
kfree(to);
return ret;
--
2.15.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v9 2/6] clocksource: stm32: increase min delta value
From: Benjamin Gaignard @ 2017-12-08 11:32 UTC (permalink / raw)
To: robh+dt, mark.rutland, linux, mcoquelin.stm32, alexandre.torgue,
daniel.lezcano, tglx, arnd
Cc: devicetree, Benjamin Gaignard, linux-kernel, linux-arm-kernel
In-Reply-To: <20171208113250.359-1-benjamin.gaignard@st.com>
From: Benjamin Gaignard <benjamin.gaignard@linaro.org>
The CPU is a CortexM4 @ 200MHZ and the clocks driving
the timers are at 90MHZ with a min delta at 1 you could
have an interrupt each 0.01 ms which is really to much.
By increase it to 0x60 it give more time (around 1 ms)
to CPU to handle the interrupt.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
---
drivers/clocksource/timer-stm32.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/clocksource/timer-stm32.c b/drivers/clocksource/timer-stm32.c
index fc61fd18a182..a45f1f1cd040 100644
--- a/drivers/clocksource/timer-stm32.c
+++ b/drivers/clocksource/timer-stm32.c
@@ -36,6 +36,12 @@
#define TIM_EGR_UG BIT(0)
+/*
+ * The clock driving the hardware is at 90MHZ with a MIN_DELTA
+ * at 0x60 it gives around 1 ms to the CPU to handle the interrupt
+ */
+#define MIN_DELTA 0x60
+
static int stm32_clock_event_shutdown(struct clock_event_device *evt)
{
struct timer_of *to = to_timer_of(evt);
@@ -129,7 +135,8 @@ static int __init stm32_clockevent_init(struct device_node *node)
writel_relaxed(0, timer_of_base(to) + TIM_SR);
clockevents_config_and_register(&to->clkevt,
- timer_of_period(to), 0x1, max_delta);
+ timer_of_period(to),
+ MIN_DELTA, max_delta);
pr_info("%pOF: STM32 clockevent driver initialized (%d bits)\n",
node, bits);
--
2.15.0
^ permalink raw reply related
* [PATCH v9 1/6] clocksource: stm32: convert driver to timer_of
From: Benjamin Gaignard @ 2017-12-08 11:32 UTC (permalink / raw)
To: robh+dt, mark.rutland, linux, mcoquelin.stm32, alexandre.torgue,
daniel.lezcano, tglx, arnd
Cc: devicetree, linux-arm-kernel, linux-kernel, Benjamin Gaignard
In-Reply-To: <20171208113250.359-1-benjamin.gaignard@st.com>
From: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Convert driver to use timer_of helpers. This allow to remove
custom proprietary structure.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
---
drivers/clocksource/Kconfig | 1 +
drivers/clocksource/timer-stm32.c | 160 ++++++++++++++------------------------
2 files changed, 58 insertions(+), 103 deletions(-)
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index c729a88007d0..28bc55951512 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -269,6 +269,7 @@ config CLKSRC_STM32
bool "Clocksource for STM32 SoCs" if !ARCH_STM32
depends on OF && ARM && (ARCH_STM32 || COMPILE_TEST)
select CLKSRC_MMIO
+ select TIMER_OF
config CLKSRC_MPS2
bool "Clocksource for MPS2 SoCs" if COMPILE_TEST
diff --git a/drivers/clocksource/timer-stm32.c b/drivers/clocksource/timer-stm32.c
index 8f2423789ba9..fc61fd18a182 100644
--- a/drivers/clocksource/timer-stm32.c
+++ b/drivers/clocksource/timer-stm32.c
@@ -17,6 +17,8 @@
#include <linux/clk.h>
#include <linux/reset.h>
+#include "timer-of.h"
+
#define TIM_CR1 0x00
#define TIM_DIER 0x0c
#define TIM_SR 0x10
@@ -34,117 +36,84 @@
#define TIM_EGR_UG BIT(0)
-struct stm32_clock_event_ddata {
- struct clock_event_device evtdev;
- unsigned periodic_top;
- void __iomem *base;
-};
-
-static int stm32_clock_event_shutdown(struct clock_event_device *evtdev)
+static int stm32_clock_event_shutdown(struct clock_event_device *evt)
{
- struct stm32_clock_event_ddata *data =
- container_of(evtdev, struct stm32_clock_event_ddata, evtdev);
- void *base = data->base;
+ struct timer_of *to = to_timer_of(evt);
- writel_relaxed(0, base + TIM_CR1);
+ writel_relaxed(0, timer_of_base(to) + TIM_CR1);
return 0;
}
-static int stm32_clock_event_set_periodic(struct clock_event_device *evtdev)
+static int stm32_clock_event_set_periodic(struct clock_event_device *evt)
{
- struct stm32_clock_event_ddata *data =
- container_of(evtdev, struct stm32_clock_event_ddata, evtdev);
- void *base = data->base;
+ struct timer_of *to = to_timer_of(evt);
+
+ writel_relaxed(timer_of_period(to), timer_of_base(to) + TIM_ARR);
+ writel_relaxed(TIM_CR1_ARPE | TIM_CR1_CEN, timer_of_base(to) + TIM_CR1);
- writel_relaxed(data->periodic_top, base + TIM_ARR);
- writel_relaxed(TIM_CR1_ARPE | TIM_CR1_CEN, base + TIM_CR1);
return 0;
}
static int stm32_clock_event_set_next_event(unsigned long evt,
- struct clock_event_device *evtdev)
+ struct clock_event_device *clkevt)
{
- struct stm32_clock_event_ddata *data =
- container_of(evtdev, struct stm32_clock_event_ddata, evtdev);
+ struct timer_of *to = to_timer_of(clkevt);
- writel_relaxed(evt, data->base + TIM_ARR);
+ writel_relaxed(evt, timer_of_base(to) + TIM_ARR);
writel_relaxed(TIM_CR1_ARPE | TIM_CR1_OPM | TIM_CR1_CEN,
- data->base + TIM_CR1);
+ timer_of_base(to) + TIM_CR1);
return 0;
}
static irqreturn_t stm32_clock_event_handler(int irq, void *dev_id)
{
- struct stm32_clock_event_ddata *data = dev_id;
+ struct clock_event_device *evt = (struct clock_event_device *)dev_id;
+ struct timer_of *to = to_timer_of(evt);
- writel_relaxed(0, data->base + TIM_SR);
+ writel_relaxed(0, timer_of_base(to) + TIM_SR);
- data->evtdev.event_handler(&data->evtdev);
+ evt->event_handler(evt);
return IRQ_HANDLED;
}
-static struct stm32_clock_event_ddata clock_event_ddata = {
- .evtdev = {
- .name = "stm32 clockevent",
- .features = CLOCK_EVT_FEAT_ONESHOT | CLOCK_EVT_FEAT_PERIODIC,
- .set_state_shutdown = stm32_clock_event_shutdown,
- .set_state_periodic = stm32_clock_event_set_periodic,
- .set_state_oneshot = stm32_clock_event_shutdown,
- .tick_resume = stm32_clock_event_shutdown,
- .set_next_event = stm32_clock_event_set_next_event,
- .rating = 200,
- },
-};
-
-static int __init stm32_clockevent_init(struct device_node *np)
+static int __init stm32_clockevent_init(struct device_node *node)
{
- struct stm32_clock_event_ddata *data = &clock_event_ddata;
- struct clk *clk;
struct reset_control *rstc;
- unsigned long rate, max_delta;
- int irq, ret, bits, prescaler = 1;
-
- clk = of_clk_get(np, 0);
- if (IS_ERR(clk)) {
- ret = PTR_ERR(clk);
- pr_err("failed to get clock for clockevent (%d)\n", ret);
- goto err_clk_get;
- }
-
- ret = clk_prepare_enable(clk);
- if (ret) {
- pr_err("failed to enable timer clock for clockevent (%d)\n",
- ret);
- goto err_clk_enable;
- }
-
- rate = clk_get_rate(clk);
-
- rstc = of_reset_control_get(np, NULL);
+ unsigned long max_delta;
+ int ret, bits, prescaler = 1;
+ struct timer_of *to;
+
+ to = kzalloc(sizeof(*to), GFP_KERNEL);
+ if (!to)
+ return -ENOMEM;
+
+ to->flags = TIMER_OF_IRQ | TIMER_OF_CLOCK | TIMER_OF_BASE;
+ to->clkevt.name = "stm32_clockevent";
+ to->clkevt.rating = 200;
+ to->clkevt.features = CLOCK_EVT_FEAT_PERIODIC;
+ to->clkevt.set_state_shutdown = stm32_clock_event_shutdown;
+ to->clkevt.set_state_periodic = stm32_clock_event_set_periodic;
+ to->clkevt.set_state_oneshot = stm32_clock_event_shutdown;
+ to->clkevt.tick_resume = stm32_clock_event_shutdown;
+ to->clkevt.set_next_event = stm32_clock_event_set_next_event;
+
+ to->of_irq.handler = stm32_clock_event_handler;
+
+ ret = timer_of_init(node, to);
+ if (ret)
+ goto err;
+
+ rstc = of_reset_control_get(node, NULL);
if (!IS_ERR(rstc)) {
reset_control_assert(rstc);
reset_control_deassert(rstc);
}
- data->base = of_iomap(np, 0);
- if (!data->base) {
- ret = -ENXIO;
- pr_err("failed to map registers for clockevent\n");
- goto err_iomap;
- }
-
- irq = irq_of_parse_and_map(np, 0);
- if (!irq) {
- ret = -EINVAL;
- pr_err("%pOF: failed to get irq.\n", np);
- goto err_get_irq;
- }
-
/* Detect whether the timer is 16 or 32 bits */
- writel_relaxed(~0U, data->base + TIM_ARR);
- max_delta = readl_relaxed(data->base + TIM_ARR);
+ writel_relaxed(~0U, timer_of_base(to) + TIM_ARR);
+ max_delta = readl_relaxed(timer_of_base(to) + TIM_ARR);
if (max_delta == ~0U) {
prescaler = 1;
bits = 32;
@@ -152,38 +121,23 @@ static int __init stm32_clockevent_init(struct device_node *np)
prescaler = 1024;
bits = 16;
}
- writel_relaxed(0, data->base + TIM_ARR);
-
- writel_relaxed(prescaler - 1, data->base + TIM_PSC);
- writel_relaxed(TIM_EGR_UG, data->base + TIM_EGR);
- writel_relaxed(TIM_DIER_UIE, data->base + TIM_DIER);
- writel_relaxed(0, data->base + TIM_SR);
+ writel_relaxed(0, timer_of_base(to) + TIM_ARR);
- data->periodic_top = DIV_ROUND_CLOSEST(rate, prescaler * HZ);
+ writel_relaxed(prescaler - 1, timer_of_base(to) + TIM_PSC);
+ writel_relaxed(TIM_EGR_UG, timer_of_base(to) + TIM_EGR);
+ writel_relaxed(TIM_DIER_UIE, timer_of_base(to) + TIM_DIER);
+ writel_relaxed(0, timer_of_base(to) + TIM_SR);
- clockevents_config_and_register(&data->evtdev,
- DIV_ROUND_CLOSEST(rate, prescaler),
- 0x1, max_delta);
-
- ret = request_irq(irq, stm32_clock_event_handler, IRQF_TIMER,
- "stm32 clockevent", data);
- if (ret) {
- pr_err("%pOF: failed to request irq.\n", np);
- goto err_get_irq;
- }
+ clockevents_config_and_register(&to->clkevt,
+ timer_of_period(to), 0x1, max_delta);
pr_info("%pOF: STM32 clockevent driver initialized (%d bits)\n",
- np, bits);
+ node, bits);
- return ret;
+ return 0;
-err_get_irq:
- iounmap(data->base);
-err_iomap:
- clk_disable_unprepare(clk);
-err_clk_enable:
- clk_put(clk);
-err_clk_get:
+err:
+ kfree(to);
return ret;
}
--
2.15.0
^ permalink raw reply related
* [PATCH v9 0/6] stm32 clocksource driver rework
From: Benjamin Gaignard @ 2017-12-08 11:32 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-I+IVW8TIWO2tmTQ+vhA3Yw,
mcoquelin.stm32-Re5JQEeQqe8AvxtiuMwx3w,
alexandre.torgue-qxv4g6HH51o,
daniel.lezcano-QSEj5FYQhm4dnm+yROfE0A,
tglx-hfZtesqFncYOwBW4kG4KsQ, arnd-r2nGTMty4D4
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Benjamin Gaignard
version 9:
- rebased on timer/master where timer_of_cleanup() exist
- fix the comments done by Daniel on v8
- reword commits message to be more explicit about 16 bits counter issue
- add one patch about copyrights and licences
version 8:
- rebased on timers/core
- change timer_of_exit() name to timer_of_cleanup()
- update stm32 clocksource driver to use this function
version 7:
- reword "clocksource: stm32: only use 32 bits timers" commit message
to give more details about why 16 bits are problematics.
version 6:
- add dedicated patch min delta change
- rework commit messages, I hope it will be better now
- change new function name from timer_of_deinit to timer_of_exit
- make stm32_clock_event_set_next_event() safer like done in other
drivers
version 6:
- add timer_of_deinit function in core
- rework failure cases in probe function
version 5:
- rebase on top of timer/core branch
- rework commit message of the first patch
version 4:
- split patch in 3 parts
- convert code to timer_of
- only use 32 bits timers
- add clocksource support
version 3:
- fix comments done by Daniel
- use timer_of helper functions
version 2:
- fix uninitialized variable
Benjamin Gaignard (6):
clocksource: stm32: convert driver to timer_of
clocksource: stm32: increase min delta value
clocksource: stm32: only use 32 bits timers
clocksource: stm32: add clocksource support
clocksource: stm32: Update license and copyright
arm: dts: stm32: remove useless clocksource nodes
arch/arm/boot/dts/stm32f429.dtsi | 32 -----
arch/arm/boot/dts/stm32f746.dtsi | 32 -----
drivers/clocksource/Kconfig | 1 +
drivers/clocksource/timer-stm32.c | 253 +++++++++++++++++++++-----------------
4 files changed, 139 insertions(+), 179 deletions(-)
--
2.15.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 09/12] clk: qcom: Add Krait clock controller driver
From: Sricharan R @ 2017-12-08 11:00 UTC (permalink / raw)
To: Philippe Ombredanne, Stephen Boyd
Cc: mturquette-QSEj5FYQhm4dnm+yROfE0A,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA, LKML,
viresh.kumar-QSEj5FYQhm4dnm+yROfE0A,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <CAOFm3uHdFn_GxJuQ-HfQpGAM5rWOT7=DyKUGtDz6dadoxdkBcw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Philippe,
On 12/8/2017 3:53 PM, Philippe Ombredanne wrote:
> Sricharan, Stephen,
>
> On Fri, Dec 8, 2017 at 10:29 AM, Sricharan R <sricharan-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> wrote:
>> From: Stephen Boyd <sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>>
>> The Krait CPU clocks are made up of a primary mux and secondary
>> mux for each CPU and the L2, controlled via cp15 accessors. For
>> Kraits within KPSSv1 each secondary mux accepts a different aux
>> source, but on KPSSv2 each secondary mux accepts the same aux
>> source.
>>
>> Cc: <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
>> Signed-off-by: Stephen Boyd <sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> []
>> --- /dev/null
>> +++ b/drivers/clk/qcom/krait-cc.c
>> @@ -0,0 +1,350 @@
>> +/* Copyright (c) 2013-2015, The Linux Foundation. All rights reserved.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 and
>> + * only version 2 as published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + */
>
> Have you considered using the new SPDX ids? Something like this:
>
> // SPDX-License-Identifier: GPL-2.0
> // Copyright (c) 2013-2015, The Linux Foundation. All rights reserved.
>
> Beside being simpler and increasing the code to comment ratio by
> deleting 9 lines of boilerplate, this will also save a few trees over
> the long term each time that I print the source code of the kernel ;)
> (do not worry, I am NOT as insane as to really print the kernel
> sources, but someone more insane than me may well do it)
>
> You may wonder about the C++ // comment style I used here... Please
> see Linus posts on the topic as well as Thomas doc patches overall for
> instructions on using the SPDX ids.
>
> And if you were to do this for your past, present and future
> contributions (eventually these of your group), I would be quite
> grateful.
>
> Thank you for your kind consideration
>
Ha ok. will change it to use this one. Infact saw this feedback on other
patches, but missed updating to it while sending.
Regards,
Sricharan
--
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2 2/2] ath10k: search DT for qcom,ath10k-calibration-variant
From: Sven Eckelmann @ 2017-12-08 10:37 UTC (permalink / raw)
To: ath10k-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8,
ext.waldemar.rymarkiewicz-++hxYGjEMp0AvxtiuMwx3w,
kvalo-sgV2jX0FEOL9JmXXK+q4OQ, Sven Eckelmann
In-Reply-To: <20171208103742.3181-1-sven.eckelmann-lv6y7wLVQPlWk0Htik3J/w@public.gmane.org>
Board Data File (BDF) is loaded upon driver boot-up procedure. The right
board data file is identified on QCA4019 using bus, bmi-chip-id and
bmi-board-id.
The problem, however, can occur when the (default) board data file cannot
fulfill with the vendor requirements and it is necessary to use a different
board data file.
This problem was solved for SMBIOS by adding a special SMBIOS type 0xF8.
Something similar has to be provided for systems without SMBIOS but with
device trees. No solution was specified by QCA and therefore a new one has
to be found for ath10k.
The device tree requires addition strings to define the variant name
wifi@a000000 {
status = "okay";
qcom,ath10k-calibration-variant = "RT-AC58U";
};
wifi@a800000 {
status = "okay";
qcom,ath10k-calibration-variant = "RT-AC58U";
};
This would create the boarddata identifiers for the board-2.bin search
* bus=ahb,bmi-chip-id=0,bmi-board-id=16,variant=RT-AC58U
* bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=RT-AC58U
Signed-off-by: Sven Eckelmann <sven.eckelmann-lv6y7wLVQPlWk0Htik3J/w@public.gmane.org>
---
drivers/net/wireless/ath/ath10k/core.c | 40 ++++++++++++++++++++++++++++------
1 file changed, 33 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index b29fdbd21ead..6264e2cc4c0d 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -860,6 +860,28 @@ static int ath10k_core_check_smbios(struct ath10k *ar)
return 0;
}
+static int ath10k_core_check_dt(struct ath10k *ar)
+{
+ struct device_node *node;
+ const char *variant = NULL;
+
+ node = ar->dev->of_node;
+ if (!node)
+ return -ENOENT;
+
+ of_property_read_string(node, "qcom,ath10k-calibration-variant",
+ &variant);
+ if (!variant)
+ return -ENODATA;
+
+ if (strscpy(ar->id.bdf_ext, variant, sizeof(ar->id.bdf_ext)) < 0)
+ ath10k_dbg(ar, ATH10K_DBG_BOOT,
+ "bdf variant string is longer than the buffer can accommodate (variant: %s)\n",
+ variant);
+
+ return 0;
+}
+
static int ath10k_download_and_run_otp(struct ath10k *ar)
{
u32 result, address = ar->hw_params.patch_load_addr;
@@ -1231,19 +1253,19 @@ static int ath10k_core_create_board_name(struct ath10k *ar, char *name,
/* strlen(',variant=') + strlen(ar->id.bdf_ext) */
char variant[9 + ATH10K_SMBIOS_BDF_EXT_STR_LENGTH] = { 0 };
+ if (ar->id.bdf_ext[0] != '\0')
+ scnprintf(variant, sizeof(variant), ",variant=%s",
+ ar->id.bdf_ext);
+
if (ar->id.bmi_ids_valid) {
scnprintf(name, name_len,
- "bus=%s,bmi-chip-id=%d,bmi-board-id=%d",
+ "bus=%s,bmi-chip-id=%d,bmi-board-id=%d%s",
ath10k_bus_str(ar->hif.bus),
ar->id.bmi_chip_id,
- ar->id.bmi_board_id);
+ ar->id.bmi_board_id, variant);
goto out;
}
- if (ar->id.bdf_ext[0] != '\0')
- scnprintf(variant, sizeof(variant), ",variant=%s",
- ar->id.bdf_ext);
^ permalink raw reply related
* [PATCH v2 1/2] dt: bindings: add new dt entry for ath10k calibration variant
From: Sven Eckelmann @ 2017-12-08 10:37 UTC (permalink / raw)
To: ath10k-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8,
ext.waldemar.rymarkiewicz-++hxYGjEMp0AvxtiuMwx3w,
kvalo-sgV2jX0FEOL9JmXXK+q4OQ, Sven Eckelmann
In-Reply-To: <20171208103742.3181-1-sven.eckelmann-lv6y7wLVQPlWk0Htik3J/w@public.gmane.org>
The bus + bmi-chip-id + bmi-board-id is not enough to identify the correct
board data file on QCA4019 based devices. Multiple different boards share
the same values. Only the original reference designs can currently be
identified and loaded from the board-2.bin. But these will not result in
the correct calibration data when combined with the pre-calibration data
from the device.
An additional "variant" information has to be provided (via SMBIOS or DT)
to select the correct board data for a design which was modified by an ODM.
Signed-off-by: Sven Eckelmann <sven.eckelmann-lv6y7wLVQPlWk0Htik3J/w@public.gmane.org>
---
Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
index 74d7f0af209c..3d2a031217da 100644
--- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
+++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
@@ -41,6 +41,9 @@ Optional properties:
- qcom,msi_addr: MSI interrupt address.
- qcom,msi_base: Base value to add before writing MSI data into
MSI address register.
+- qcom,ath10k-calibration-variant: string to search for in the board-2.bin
+ variant list with the same bus and device
+ specific ids
- qcom,ath10k-calibration-data : calibration data + board specific data
as an array, the length can vary between
hw versions.
--
2.11.0
^ permalink raw reply related
* [PATCH v2 0/2] ath10k: DT support for ath10k calibration variant
From: Sven Eckelmann @ 2017-12-08 10:37 UTC (permalink / raw)
To: ath10k-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8,
ext.waldemar.rymarkiewicz-++hxYGjEMp0AvxtiuMwx3w,
kvalo-sgV2jX0FEOL9JmXXK+q4OQ, Sven Eckelmann
From: Sven Eckelmann <sven-KaDOiPu9UxWEi8DpZVb4nw@public.gmane.org>
Hi,
here is the second version of the qcom,ath10k-calibration-variant support
patchset. I think the ath10k patch describes these changes the best:
Board Data File (BDF) is loaded upon driver boot-up procedure. The right
board data file is identified on QCA4019 using bus, bmi-chip-id and
bmi-board-id.
The problem, however, can occur when the (default) board data file cannot
fulfill with the vendor requirements and it is necessary to use a different
board data file.
This problem was solved for SMBIOS by adding a special SMBIOS type 0xF8.
Something similar has to be provided for systems without SMBIOS but with
device trees. No solution was specified by QCA and therefore a new one has
to be found for ath10k.
The device tree requires addition strings to define the variant name
wifi@a000000 {
status = "okay";
qcom,ath10k-calibration-variant = "RT-AC58U";
};
wifi@a800000 {
status = "okay";
qcom,ath10k-calibration-variant = "RT-AC58U";
};
This would create the boarddata identifiers for the board-2.bin search
* bus=ahb,bmi-chip-id=0,bmi-board-id=16,variant=RT-AC58U
* bus=ahb,bmi-chip-id=0,bmi-board-id=17,variant=RT-AC58U
The discussions to the old submissions can be found in:
RFC:
====
* https://patchwork.kernel.org/patch/9613615/
v1:
===
* https://patchwork.kernel.org/patch/9615183/
* https://patchwork.kernel.org/patch/9615185/
Changes since v1:
=================
* check the return value of strscpy and print debug message when buffer
was not big enough (I would have preferred ath10k_warn but
ath10k_core_check_bdfext disagreed)
Changes since RFC:
==================
* Split patch in DT doc and ath10k part (thanks Christian Lamparter)
* Remove the words "bmi-chip-id" and "bmi-board-id" and replace them with
more generic "device specific ids"
Kind regards,
Sven
Sven Eckelmann (2):
dt: bindings: add new dt entry for ath10k calibration variant
ath10k: search DT for qcom,ath10k-calibration-variant
.../bindings/net/wireless/qcom,ath10k.txt | 3 ++
drivers/net/wireless/ath/ath10k/core.c | 40 ++++++++++++++++++----
2 files changed, 36 insertions(+), 7 deletions(-)
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 24/33] nds32: Device tree support
From: Mark Rutland @ 2017-12-08 10:27 UTC (permalink / raw)
To: Greentime Hu
Cc: greentime, linux-kernel, arnd, linux-arch, tglx, jason,
marc.zyngier, robh+dt, netdev, deanbo422, devicetree, viro,
dhowells, will.deacon, daniel.lezcano, linux-serial,
geert.uytterhoeven, linus.walleij, greg, Vincent Chen
In-Reply-To: <c1083b6f603aeeb13c72c501214e82549404fa5c.1512723245.git.green.hu@gmail.com>
On Fri, Dec 08, 2017 at 05:12:07PM +0800, Greentime Hu wrote:
> + timer0: timer@98400000 {
> + compatible = "andestech,atftmr010";
> + reg = <0x98400000 0x1000>;
> + interrupts = <19>;
> + clocks = <&clk_pll>;
> + clock-names = "apb_pclk";
> + cycle-count-offset = <0x20>;
> + };
Looking through the series, I can't find a binding or driver for this
timer, either.
Does timekeeping work with this series, or are additional patches
necessary?
Thanks,
Mark.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox