* [PATCH 1/2] soc: imx: gpc: Add i.MX6SX PCI power domain
From: Lucas Stach @ 2017-12-15 9:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513304698-15169-1-git-send-email-festevam@gmail.com>
Am Freitag, den 15.12.2017, 00:24 -0200 schrieb Fabio Estevam:
> > From: Fabio Estevam <fabio.estevam@nxp.com>
>
> i.MX6SX has a PCI power domain in PGC. Add support for it.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Seems like the GPC rework did turn out to work as expected by making it
easy to add additional power domains. :)
I didn't validate the register offsets, so this is:
Acked-by: Lucas Stach <l.stach@pengutronix.de>
> ---
> ?Documentation/devicetree/bindings/power/fsl,imx-gpc.txt |??3 +++
> ?drivers/soc/imx/gpc.c???????????????????????????????????| 16 +++++++++++++++-
> ?2 files changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/power/fsl,imx-gpc.txt b/Documentation/devicetree/bindings/power/fsl,imx-gpc.txt
> index e371b26..441f71e 100644
> --- a/Documentation/devicetree/bindings/power/fsl,imx-gpc.txt
> +++ b/Documentation/devicetree/bindings/power/fsl,imx-gpc.txt
> @@ -9,6 +9,7 @@ Required properties:
> ???- fsl,imx6q-gpc
> ???- fsl,imx6qp-gpc
> ???- fsl,imx6sl-gpc
> +??- fsl,imx6sx-gpc
> ?- reg: should be register base and length as documented in the
> ???datasheet
> ?- interrupts: Should contain one interrupt specifier for the GPC interrupt
> @@ -29,6 +30,8 @@ Required properties:
> ???PU_DOMAIN??????1
> ???The following additional DOMAIN_INDEX value is valid for i.MX6SL:
> ???DISPLAY_DOMAIN 2
> +??The following additional DOMAIN_INDEX value is valid for i.MX6SX:
> +??PCI_DOMAIN?????3
> ?
> ?- #power-domain-cells: Should be 0
> ?
> diff --git a/drivers/soc/imx/gpc.c b/drivers/soc/imx/gpc.c
> index 47e7aa9..53f7275 100644
> --- a/drivers/soc/imx/gpc.c
> +++ b/drivers/soc/imx/gpc.c
> @@ -273,7 +273,15 @@ static struct imx_pm_domain imx_gpc_domains[] = {
> > ? },
> > ? .reg_offs = 0x240,
> > ? .cntr_pdn_bit = 4,
> > - }
> > + }, {
> > + .base = {
> > + .name = "PCI",
> > + .power_off = imx6_pm_domain_power_off,
> > + .power_on = imx6_pm_domain_power_on,
> > + },
> > + .reg_offs = 0x200,
> > + .cntr_pdn_bit = 6,
> > + },
> ?};
> ?
> ?struct imx_gpc_dt_data {
> @@ -296,10 +304,16 @@ static const struct imx_gpc_dt_data imx6sl_dt_data = {
> > ? .err009619_present = false,
> ?};
> ?
> +static const struct imx_gpc_dt_data imx6sx_dt_data = {
> > + .num_domains = 4,
> > + .err009619_present = false,
> +};
> +
> ?static const struct of_device_id imx_gpc_dt_ids[] = {
> > ? { .compatible = "fsl,imx6q-gpc", .data = &imx6q_dt_data },
> > ? { .compatible = "fsl,imx6qp-gpc", .data = &imx6qp_dt_data },
> > ? { .compatible = "fsl,imx6sl-gpc", .data = &imx6sl_dt_data },
> > + { .compatible = "fsl,imx6sx-gpc", .data = &imx6sx_dt_data },
> > ? { }
> ?};
> ?
^ permalink raw reply
* [PATCH] media: v4l: xilinx: Use SPDX-License-Identifier
From: Mauro Carvalho Chehab @ 2017-12-15 9:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7952229.SXlKMv2tvC@avalon>
Em Fri, 15 Dec 2017 00:02:21 +0200
Laurent Pinchart <laurent.pinchart@ideasonboard.com> escreveu:
> Hi Mauro,
>
> On Thursday, 14 December 2017 23:50:03 EET Mauro Carvalho Chehab wrote:
> > Em Thu, 14 Dec 2017 21:57:06 +0100 Greg KH escreveu:
> > > On Thu, Dec 14, 2017 at 10:44:16PM +0200, Laurent Pinchart wrote:
> > >> On Thursday, 14 December 2017 22:08:51 EET Greg KH wrote:
> > >>> On Thu, Dec 14, 2017 at 09:05:27PM +0200, Laurent Pinchart wrote:
> > >>>> On Thursday, 14 December 2017 20:54:39 EET Joe Perches wrote:
> > >>>>> On Thu, 2017-12-14 at 20:37 +0200, Laurent Pinchart wrote:
> > >>>>>> On Thursday, 14 December 2017 20:32:20 EET Joe Perches wrote:
> > >>>>>>> On Thu, 2017-12-14 at 20:28 +0200, Laurent Pinchart wrote:
> > >>>>>>>> On Thursday, 14 December 2017 19:05:27 EET Mauro Carvalho Chehab
> > >>>>>>>> wrote:
> > >>>>>>>>> Em Fri, 8 Dec 2017 18:05:37 +0530 Dhaval Shah escreveu:
> > >>>>>>>>>> SPDX-License-Identifier is used for the Xilinx Video IP and
> > >>>>>>>>>> related drivers.
> > >>>>>>>>>>
> > >>>>>>>>>> Signed-off-by: Dhaval Shah <dhaval23031987@gmail.com>
> > >>>>>>>>>
> > >>>>>>>>> Hi Dhaval,
> > >>>>>>>>>
> > >>>>>>>>> You're not listed as one of the Xilinx driver maintainers. I'm
> > >>>>>>>>> afraid that, without their explicit acks, sent to the ML, I
> > >>>>>>>>> can't accept a patch touching at the driver's license tags.
> > >>>>>>>>
> > >>>>>>>> The patch doesn't change the license, I don't see why it would
> > >>>>>>>> cause any issue. Greg isn't listed as the maintainer or copyright
> > >>>>>>>> holder of any of the 10k+ files to which he added an SPDX license
> > >>>>>>>> header in the last kernel release.
> > >>>>>>>
> > >>>>>>> Adding a comment line that describes an implicit or
> > >>>>>>> explicit license is different than removing the license
> > >>>>>>> text itself.
> > >>>>>>
> > >>>>>> The SPDX license header is meant to be equivalent to the license
> > >>>>>> text.
> > >>>>>
> > >>>>> I understand that.
> > >>>>> At a minimum, removing BSD license text is undesirable
> > >>>>>
> > >>>>> as that license states:
> > >>>>> * * Redistributions of source code must retain the above copyright
> > >>>>> * notice, this list of conditions and the following disclaimer.
> > >>>>>
> > >>>>> etc...
> > >>>>
> > >>>> But this patch only removes the following text:
> > >>>>
> > >>>> - * 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.
> > >>>>
> > >>>> and replaces it by the corresponding SPDX header.
> > >>>>
> > >>>>>> The only reason why the large SPDX patch didn't touch the whole
> > >>>>>> kernel in one go was that it was easier to split in in multiple
> > >>>>>> chunks.
> > >>>>>
> > >>>>> Not really, it was scripted.
> > >>>>
> > >>>> But still manually reviewed as far as I know.
> > >>>>
> > >>>>>> This is no different than not including the full GPL license in
> > >>>>>> every header file but only pointing to it through its name and
> > >>>>>> reference, as every kernel source file does.
> > >>>>>
> > >>>>> Not every kernel source file had a license text
> > >>>>> or a reference to another license file.
> > >>>>
> > >>>> Correct, but the files touched by this patch do.
> > >>>>
> > >>>> This issue is in no way specific to linux-media and should be
> > >>>> decided upon at the top level, not on a per-subsystem basis. Greg,
> > >>>> could you comment on this ?
> > >>>
> > >>> Comment on what exactly? I don't understand the problem here, care to
> > >>> summarize it?
> > >>
> > >> In a nutshell (if I understand it correctly), Dhaval Shah submitted
> > >> https:// patchwork.kernel.org/patch/10102451/ which replaces
> > >>
> > >> +// SPDX-License-Identifier: GPL-2.0
> > >> [...]
> > >> - *
> > >> - * 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.
> > >>
> > >> in all .c and .h files of the Xilinx V4L2 driver
> > >> (drivers/media/platform/
> > >> xilinx). I have reviewed the patch and acked it. Mauro then rejected it,
> > >> stating that he can't accept a change to license text without an
> > >> explicit ack from the official driver's maintainers. My position is
> > >> that such a change doesn't change the license and thus doesn't need to
> > >> track all copyright holders, and can be merged without an explicit ack
> > >> from the respective maintainers.
> > >
> > > Yes, I agree with you, no license is being changed here, and no
> > > copyright is either.
> > >
> > > BUT, I know that most major companies are reviewing this process right
> > > now. We have gotten approval from almost all of the major kernel
> > > developer companies to do this, which is great, and supports this work
> > > as being acceptable.
> > >
> > > So it's nice to ask Xilinx if they object to this happening, which I
> > > guess Mauro is trying to say here (in not so many words...) To at least
> > > give them the heads-up that this is what is going to be going on
> > > throughout the kernel tree soon, and if they object, it would be good to
> > > speak up as to why (and if they do, I can put their lawyers in contact
> > > with some lawyers to explain it all to them.)
> >
> > Yes, that's basically what I'm saying.
> >
> > I don't feel comfortable on signing a patch changing the license text
> > without giving the copyright owners an opportunity and enough time
> > to review it and approve, or otherwise comment about such changes.
>
> If I understand you and Greg correctly, you would like to get a general
> approval from Xilinx for SPDX-related changes, but that would be a blanket
> approval that would cover this and all subsequent similar patches. Is that
> correct ? That is reasonable for me.
I doubt any Company's legal department would give a blanket approval for
others to touch on their licensing text.
>
> In that case, could the fact that commit
>
> commit 5fd54ace4721fc5ce2bb5aef6318fcf17f421460
> Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Date: Fri Nov 3 11:28:30 2017 +0100
>
> USB: add SPDX identifiers to all remaining files in drivers/usb/
>
> add SPDX headers to several Xilinx-authored source files constitute such a
> blanket approval ?
If you look at this patch's summary:
651 files changed, 651 insertions(+)
And on the patch contents itself, it is just adding a SPDX header.
It doesn't remove any text from the license.
On Dhaval's patch, it is not only adding SPDX header. It is also removing
the legal text from it:
diff --git a/drivers/media/platform/xilinx/xilinx-dma.c b/drivers/media/platform/xilinx/xilinx-dma.c
index 522cdfdd3345..2e5daf7dba1a 100644
--- a/drivers/media/platform/xilinx/xilinx-dma.c
+++ b/drivers/media/platform/xilinx/xilinx-dma.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* Xilinx Video DMA
*
@@ -6,10 +7,6 @@
*
* Contacts: Hyun Kwon <hyun.kwon@xilinx.com>
* Laurent Pinchart <laurent.pinchart@ideasonboard.com>
- *
- * 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.
*/
And that's the part I'm more concerned about: we should give Xilinx
enough time to review and approve such change.
Thanks,
Mauro
^ permalink raw reply related
* [PATCH 6/6 v3] mmc: sunxi-mmc: Handle return value of platform_get_irq
From: Ulf Hansson @ 2017-12-15 9:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6ad5c6077b96353a77ea30d1b64651c77d5622f6.1511066652.git.arvind.yadav.cs@gmail.com>
On 19 November 2017 at 05:52, Arvind Yadav <arvind.yadav.cs@gmail.com> wrote:
> platform_get_irq() can fail here and we must check its return value.
>
> Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Thanks, applied for next!
Kind regards
Uffe
> ---
> changes in v2 :
> Add failure case '<= 0' instead of '< 0'. IRQ0 is not valid.
> changes in v3 :
> return -EINVAL instead of host->irq.
>
> drivers/mmc/host/sunxi-mmc.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
> index cc98355d..c926ac8 100644
> --- a/drivers/mmc/host/sunxi-mmc.c
> +++ b/drivers/mmc/host/sunxi-mmc.c
> @@ -1255,6 +1255,11 @@ static int sunxi_mmc_resource_request(struct sunxi_mmc_host *host,
> goto error_assert_reset;
>
> host->irq = platform_get_irq(pdev, 0);
> + if (host->irq <= 0) {
> + ret = -EINVAL;
> + goto error_assert_reset;
> + }
> +
> return devm_request_threaded_irq(&pdev->dev, host->irq, sunxi_mmc_irq,
> sunxi_mmc_handle_manual_stop, 0, "sunxi-mmc", host);
>
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH 4/6 v3] mmc: sdhci-spear: Handle return value of platform_get_irq
From: Ulf Hansson @ 2017-12-15 9:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <23382b551ade00543aadc588aa74b0648958b907.1511066652.git.arvind.yadav.cs@gmail.com>
On 19 November 2017 at 05:52, Arvind Yadav <arvind.yadav.cs@gmail.com> wrote:
> platform_get_irq() can fail here and we must check its return value.
>
> Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Thanks, applied for next!
Kind regards
Uffe
> ---
> changes in v2 :
> Add failure case '<= 0' instead of '< 0'. IRQ0 is not valid.
> changes in v3 :
> return -EINVAL instead of host->irq.
>
> drivers/mmc/host/sdhci-spear.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci-spear.c b/drivers/mmc/host/sdhci-spear.c
> index 8c0f884..e04485e 100644
> --- a/drivers/mmc/host/sdhci-spear.c
> +++ b/drivers/mmc/host/sdhci-spear.c
> @@ -82,6 +82,10 @@ static int sdhci_probe(struct platform_device *pdev)
> host->hw_name = "sdhci";
> host->ops = &sdhci_pltfm_ops;
> host->irq = platform_get_irq(pdev, 0);
> + if (host->irq <= 0) {
> + ret = -EINVAL;
> + goto err_host;
> + }
> host->quirks = SDHCI_QUIRK_BROKEN_ADMA;
>
> sdhci = sdhci_priv(host);
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH 3/6 v3] mmc: sdhci-acpi: Handle return value of platform_get_irq
From: Ulf Hansson @ 2017-12-15 9:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ecd11732b6a29aee23a1be94616755e575b0d438.1511066652.git.arvind.yadav.cs@gmail.com>
On 19 November 2017 at 05:52, Arvind Yadav <arvind.yadav.cs@gmail.com> wrote:
> platform_get_irq() can fail here and we must check its return value.
>
> Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Thanks, applied for next!
Kind regards
Uffe
> ---
> changes in v2 :
> Add failure case '<= 0' instead of '< 0'. IRQ0 is not valid.
> changes in v3 :
> return -EINVAL instead of host->irq.
>
> drivers/mmc/host/sdhci-acpi.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci-acpi.c b/drivers/mmc/host/sdhci-acpi.c
> index b988997..0d9965b 100644
> --- a/drivers/mmc/host/sdhci-acpi.c
> +++ b/drivers/mmc/host/sdhci-acpi.c
> @@ -566,6 +566,10 @@ static int sdhci_acpi_probe(struct platform_device *pdev)
> host->hw_name = "ACPI";
> host->ops = &sdhci_acpi_ops_dflt;
> host->irq = platform_get_irq(pdev, 0);
> + if (host->irq <= 0) {
> + err = -EINVAL;
> + goto err_free;
> + }
>
> host->ioaddr = devm_ioremap_nocache(dev, iomem->start,
> resource_size(iomem));
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH 2/6 v3] mmc: s3cmci: Fix platform_get_irq's error checking
From: Ulf Hansson @ 2017-12-15 9:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <870b1a28108a8c0f3885bd345f3d27dda67621d5.1511066652.git.arvind.yadav.cs@gmail.com>
On 19 November 2017 at 05:52, Arvind Yadav <arvind.yadav.cs@gmail.com> wrote:
> The platform_get_irq() function returns negative if an error occurs.
> zero or positive number on success. platform_get_irq() error checking
> for zero is not correct.
>
> Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Thanks, applied for next!
Kind regards
Uffe
> ---
> changes in v2 :
> Add failure case '<= 0' instead of '< 0'. IRQ0 is not valid.
> changes in v3 :
> return -EINVAL instead of host->irq.
>
> drivers/mmc/host/s3cmci.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/s3cmci.c b/drivers/mmc/host/s3cmci.c
> index f7f157a..36daee1 100644
> --- a/drivers/mmc/host/s3cmci.c
> +++ b/drivers/mmc/host/s3cmci.c
> @@ -1658,7 +1658,7 @@ static int s3cmci_probe(struct platform_device *pdev)
> }
>
> host->irq = platform_get_irq(pdev, 0);
> - if (host->irq == 0) {
> + if (host->irq <= 0) {
> dev_err(&pdev->dev, "failed to get interrupt resource.\n");
> ret = -EINVAL;
> goto probe_iounmap;
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH 1/6 v3] mmc: meson-gx-mmc: Fix platform_get_irq's error checking
From: Ulf Hansson @ 2017-12-15 9:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c1c27676e9f141ace1254b40807bf2dc03f072c6.1511066652.git.arvind.yadav.cs@gmail.com>
On 19 November 2017 at 05:52, Arvind Yadav <arvind.yadav.cs@gmail.com> wrote:
> The platform_get_irq() function returns negative if an error occurs.
> zero or positive number on success. platform_get_irq() error checking
> for zero is not correct.
>
> Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Thanks, applied for next!
Kind regards
Uffe
> ---
> changes in v2 :
> Add failure case '<= 0' instead of '< 0'. IRQ0 is not valid.
> changes in v3 :
> return -EINVAL instead of irq.
>
> drivers/mmc/host/meson-gx-mmc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/meson-gx-mmc.c b/drivers/mmc/host/meson-gx-mmc.c
> index e0862d3..32a6a22 100644
> --- a/drivers/mmc/host/meson-gx-mmc.c
> +++ b/drivers/mmc/host/meson-gx-mmc.c
> @@ -1208,7 +1208,7 @@ static int meson_mmc_probe(struct platform_device *pdev)
> }
>
> irq = platform_get_irq(pdev, 0);
> - if (!irq) {
> + if (irq <= 0) {
> dev_err(&pdev->dev, "failed to get interrupt resource.\n");
> ret = -EINVAL;
> goto free_host;
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH] KVM: arm/arm64: don't set vtimer->cnt_ctl in kvm_arch_timer_handler
From: Marc Zyngier @ 2017-12-15 9:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e5ccbf1c-6078-4c43-8aa3-fc226ed358f7@gmail.com>
On 15/12/17 02:27, Jia He wrote:
>
>
[...]
>> @@ -367,6 +368,7 @@ static void vtimer_save_state(struct kvm_vcpu *vcpu)
>>
>> /* Disable the virtual timer */
>> write_sysreg_el0(0, cntv_ctl);
>> + isb();
> My only concern is whether this isb() is required here?
> Sorryif this is a stupid question.I understand little about arm arch
> memory barrier. But seems isb will flush all the instruction prefetch.Do
> you think if an timer interrupt irq arrives, arm will use the previous
> instruction prefetch?
This barrier has little to do with prefetch. It just guarantees that the
code after the isb() is now running with a disabled virtual timer.
Otherwise, a CPU can freely reorder the write_sysreg() until the next
context synchronization event.
An interrupt coming between the write and the barrier will also act as a
context synchronization event. For more details, see the ARMv8 ARM (the
glossary has a section on the concept).
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH] arm: dts: Remove leading 0x and 0s from bindings notation
From: Krzysztof Kozlowski @ 2017-12-15 8:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214165350.27850-1-malat@debian.org>
On Thu, Dec 14, 2017 at 5:53 PM, Mathieu Malaterre <malat@debian.org> wrote:
> Improve the DTS files by removing all the leading "0x" and zeros to fix the
> following dtc warnings:
>
> Warning (unit_address_format): Node /XXX unit name should not have leading "0x"
>
> and
>
> Warning (unit_address_format): Node /XXX unit name should not have leading 0s
>
> Converted using the following command:
>
> find . -type f \( -iname *.dts -o -iname *.dtsi \) -exec sed -E -i -e "s/@0x([0-9a-fA-F\.]+)\s?\{/@\L\1 \{/g" -e "s/@0+([0-9a-fA-F\.]+)\s?\{/@\L\1 \{/g" {} +
>
> For simplicity, two sed expressions were used to solve each warnings separately.
>
> To make the regex expression more robust a few other issues were resolved,
> namely setting unit-address to lower case, and adding a whitespace before the
> the opening curly brace:
>
> https://elinux.org/Device_Tree_Linux#Linux_conventions
>
> This is a follow up to commit 4c9847b7375a ("dt-bindings: Remove leading 0x from bindings notation")
>
> Reported-by: David Daney <ddaney@caviumnetworks.com>
> Suggested-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Mathieu Malaterre <malat@debian.org>
> ---
> arch/arm/boot/dts/am3517.dtsi | 4 +--
> arch/arm/boot/dts/arm-realview-eb.dtsi | 18 +++++++-------
> arch/arm/boot/dts/arm-realview-pb1176.dts | 18 +++++++-------
> arch/arm/boot/dts/arm-realview-pb11mp.dts | 18 +++++++-------
> arch/arm/boot/dts/arm-realview-pbx.dtsi | 18 +++++++-------
> arch/arm/boot/dts/artpec6.dtsi | 2 +-
> arch/arm/boot/dts/at91sam9261.dtsi | 2 +-
> arch/arm/boot/dts/at91sam9261ek.dts | 2 +-
> arch/arm/boot/dts/at91sam9263.dtsi | 2 +-
> arch/arm/boot/dts/at91sam9263ek.dts | 2 +-
> arch/arm/boot/dts/at91sam9g25ek.dts | 2 +-
> arch/arm/boot/dts/at91sam9g45.dtsi | 2 +-
> arch/arm/boot/dts/at91sam9m10g45ek.dts | 2 +-
> arch/arm/boot/dts/atlas7.dtsi | 12 ++++-----
> arch/arm/boot/dts/bcm11351.dtsi | 2 +-
> arch/arm/boot/dts/bcm21664.dtsi | 2 +-
> arch/arm/boot/dts/bcm283x.dtsi | 2 +-
> arch/arm/boot/dts/da850-lcdk.dts | 4 +--
> arch/arm/boot/dts/dm8148-evm.dts | 8 +++---
> arch/arm/boot/dts/dm8168-evm.dts | 8 +++---
> arch/arm/boot/dts/dra62x-j5eco-evm.dts | 8 +++---
> arch/arm/boot/dts/exynos5420.dtsi | 36 +++++++++++++--------------
> arch/arm/boot/dts/exynos5422-odroid-core.dtsi | 2 +-
> arch/arm/boot/dts/imx7d.dtsi | 2 +-
> arch/arm/boot/dts/keystone-k2e-netcp.dtsi | 2 +-
> arch/arm/boot/dts/keystone-k2hk-netcp.dtsi | 2 +-
> arch/arm/boot/dts/keystone-k2l-netcp.dtsi | 2 +-
> arch/arm/boot/dts/omap3-cm-t3x.dtsi | 8 +++---
> arch/arm/boot/dts/omap3-evm-37xx.dts | 8 +++---
> arch/arm/boot/dts/omap3-lilly-a83x.dtsi | 8 +++---
> arch/arm/boot/dts/s3c2416.dtsi | 2 +-
For Exynos and S3C:
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
^ permalink raw reply
* arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
From: AKASHI Takahiro @ 2017-12-15 8:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu_G8kBEAdAznVauZVAdJOFkr1vmu0Gf6tOwJfH2CgdufA@mail.gmail.com>
On Wed, Dec 13, 2017 at 12:17:22PM +0000, Ard Biesheuvel wrote:
> On 13 December 2017 at 12:16, AKASHI Takahiro
> <takahiro.akashi@linaro.org> wrote:
> > On Wed, Dec 13, 2017 at 10:49:27AM +0000, Ard Biesheuvel wrote:
> >> On 13 December 2017 at 10:26, AKASHI Takahiro
> >> <takahiro.akashi@linaro.org> wrote:
> >> > Bhupesh, Ard,
> >> >
> >> > On Wed, Dec 13, 2017 at 03:21:59AM +0530, Bhupesh Sharma wrote:
> >> >> Hi Ard, Akashi
> >> >>
> >> > (snip)
> >> >
> >> >> Looking deeper into the issue, since the arm64 kexec-tools uses the
> >> >> 'linux,usable-memory-range' dt property to allow crash dump kernel to
> >> >> identify its own usable memory and exclude, at its boot time, any
> >> >> other memory areas that are part of the panicked kernel's memory.
> >> >> (see https://www.kernel.org/doc/Documentation/devicetree/bindings/chosen.txt
> >> >> , for details)
> >> >
> >> > Right.
> >> >
> >> >> 1). Now when 'kexec -p' is executed, this node is patched up only
> >> >> with the crashkernel memory range:
> >> >>
> >> >> /* add linux,usable-memory-range */
> >> >> nodeoffset = fdt_path_offset(new_buf, "/chosen");
> >> >> result = fdt_setprop_range(new_buf, nodeoffset,
> >> >> PROP_USABLE_MEM_RANGE, &crash_reserved_mem,
> >> >> address_cells, size_cells);
> >> >>
> >> >> (see https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/tree/kexec/arch/arm64/kexec-arm64.c#n465
> >> >> , for details)
> >> >>
> >> >> 2). This excludes the ACPI reclaim regions irrespective of whether
> >> >> they are marked as System RAM or as RESERVED. As,
> >> >> 'linux,usable-memory-range' dt node is patched up only with
> >> >> 'crash_reserved_mem' and not 'system_memory_ranges'
> >> >>
> >> >> 3). As a result when the crashkernel boots up it doesn't find this
> >> >> ACPI memory and crashes while trying to access the same:
> >> >>
> >> >> # kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname
> >> >> -r`.img --reuse-cmdline -d
> >> >>
> >> >> [snip..]
> >> >>
> >> >> Reserved memory range
> >> >> 000000000e800000-000000002e7fffff (0)
> >> >>
> >> >> Coredump memory ranges
> >> >> 0000000000000000-000000000e7fffff (0)
> >> >> 000000002e800000-000000003961ffff (0)
> >> >> 0000000039d40000-000000003ed2ffff (0)
> >> >> 000000003ed60000-000000003fbfffff (0)
> >> >> 0000001040000000-0000001ffbffffff (0)
> >> >> 0000002000000000-0000002ffbffffff (0)
> >> >> 0000009000000000-0000009ffbffffff (0)
> >> >> 000000a000000000-000000affbffffff (0)
> >> >>
> >> >> 4). So if we revert Ard's patch or just comment the fixing up of the
> >> >> memory cap'ing passed to the crash kernel inside
> >> >> 'arch/arm64/mm/init.c' (see below):
> >> >>
> >> >> static void __init fdt_enforce_memory_region(void)
> >> >> {
> >> >> struct memblock_region reg = {
> >> >> .size = 0,
> >> >> };
> >> >>
> >> >> of_scan_flat_dt(early_init_dt_scan_usablemem, ®);
> >> >>
> >> >> if (reg.size)
> >> >> //memblock_cap_memory_range(reg.base, reg.size); /*
> >> >> comment this out */
> >> >> }
> >> >
> >> > Please just don't do that. It can cause a fatal damage on
> >> > memory contents of the *crashed* kernel.
> >> >
> >> >> 5). Both the above temporary solutions fix the problem.
> >> >>
> >> >> 6). However exposing all System RAM regions to the crashkernel is not
> >> >> advisable and may cause the crashkernel or some crashkernel drivers to
> >> >> fail.
> >> >>
> >> >> 6a). I am trying an approach now, where the ACPI reclaim regions are
> >> >> added to '/proc/iomem' separately as ACPI reclaim regions by the
> >> >> kernel code and on the other hand the user-space 'kexec-tools' will
> >> >> pick up the ACPI reclaim regions from '/proc/iomem' and add it to the
> >> >> dt node 'linux,usable-memory-range'
> >> >
> >> > I still don't understand why we need to carry over the information
> >> > about "ACPI Reclaim memory" to crash dump kernel. In my understandings,
> >> > such regions are free to be reused by the kernel after some point of
> >> > initialization. Why does crash dump kernel need to know about them?
> >> >
> >>
> >> Not really. According to the UEFI spec, they can be reclaimed after
> >> the OS has initialized, i.e., when it has consumed the ACPI tables and
> >> no longer needs them. Of course, in order to be able to boot a kexec
> >> kernel, those regions needs to be preserved, which is why they are
> >> memblock_reserve()'d now.
> >
> > For my better understandings, who is actually accessing such regions
> > during boot time, uefi itself or efistub?
> >
>
> No, only the kernel. This is where the ACPI tables are stored. For
> instance, on QEMU we have
>
> ACPI: RSDP 0x0000000078980000 000024 (v02 BOCHS )
> ACPI: XSDT 0x0000000078970000 000054 (v01 BOCHS BXPCFACP 00000001
> 01000013)
> ACPI: FACP 0x0000000078930000 00010C (v05 BOCHS BXPCFACP 00000001
> BXPC 00000001)
> ACPI: DSDT 0x0000000078940000 0011DA (v02 BOCHS BXPCDSDT 00000001
> BXPC 00000001)
> ACPI: APIC 0x0000000078920000 000140 (v03 BOCHS BXPCAPIC 00000001
> BXPC 00000001)
> ACPI: GTDT 0x0000000078910000 000060 (v02 BOCHS BXPCGTDT 00000001
> BXPC 00000001)
> ACPI: MCFG 0x0000000078900000 00003C (v01 BOCHS BXPCMCFG 00000001
> BXPC 00000001)
> ACPI: SPCR 0x00000000788F0000 000050 (v02 BOCHS BXPCSPCR 00000001
> BXPC 00000001)
> ACPI: IORT 0x00000000788E0000 00007C (v00 BOCHS BXPCIORT 00000001
> BXPC 00000001)
>
> covered by
>
> efi: 0x0000788e0000-0x00007894ffff [ACPI Reclaim Memory ...]
> ...
> efi: 0x000078970000-0x00007898ffff [ACPI Reclaim Memory ...]
OK. I mistakenly understood those regions could be freed after exiting
UEFI boot services.
>
> >> So it seems that kexec does not honour the memblock_reserve() table
> >> when booting the next kernel.
> >
> > not really.
> >
> >> > (In other words, can or should we skip some part of ACPI-related init code
> >> > on crash dump kernel?)
> >> >
> >>
> >> I don't think so. And the change to the handling of ACPI reclaim
> >> regions only revealed the bug, not created it (given that other
> >> memblock_reserve regions may be affected as well)
> >
> > As whether we should honor such reserved regions over kexec'ing
> > depends on each one's specific nature, we will have to take care one-by-one.
> > As a matter of fact, no information about "reserved" memblocks is
> > exposed to user space (via proc/iomem).
> >
>
> That is why I suggested (somewhere in this thread?) to not expose them
> as 'System RAM'. Do you think that could solve this?
Memblock-reserv'ing them is necessary to prevent their corruption and
marking them under another name in /proc/iomem would also be good in order
not to allocate them as part of crash kernel's memory.
But I'm not still convinced that we should export them in useable-
memory-range to crash dump kernel. They will be accessed through
acpi_os_map_memory() and so won't be required to be part of system ram
(or memblocks), I guess.
-> Bhupesh?
Just FYI, on x86, ACPI tables seems to be exposed to crash dump kernel
via a kernel command line parameter, "memmap=".
Thanks,
-Takahiro AKASHI
> >
> >>
> >> >> 6b). The kernel code currently looks like the following:
> >> >>
> >> >> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> >> >> index 30ad2f085d1f..867bdec7c692 100644
> >> >> --- a/arch/arm64/kernel/setup.c
> >> >> +++ b/arch/arm64/kernel/setup.c
> >> >> @@ -206,6 +206,7 @@ static void __init request_standard_resources(void)
> >> >> {
> >> >> struct memblock_region *region;
> >> >> struct resource *res;
> >> >> + phys_addr_t addr_start, addr_end;
> >> >>
> >> >> kernel_code.start = __pa_symbol(_text);
> >> >> kernel_code.end = __pa_symbol(__init_begin - 1);
> >> >> @@ -218,9 +219,17 @@ static void __init request_standard_resources(void)
> >> >> res->name = "reserved";
> >> >> res->flags = IORESOURCE_MEM;
> >> >> } else {
> >> >> - res->name = "System RAM";
> >> >> - res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
> >> >> + addr_start =
> >> >> __pfn_to_phys(memblock_region_reserved_base_pfn(region));
> >> >> + addr_end =
> >> >> __pfn_to_phys(memblock_region_reserved_end_pfn(region)) - 1;
> >> >> + if ((efi_mem_type(addr_start) == EFI_ACPI_RECLAIM_MEMORY)
> >> >> || (efi_mem_type(addr_end) == EFI_ACPI_RECLAIM_MEMORY)) {
> >> >> + res->name = "ACPI reclaim region";
> >> >> + res->flags = IORESOURCE_MEM;
> >> >> + } else {
> >> >> + res->name = "System RAM";
> >> >> + res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
> >> >> + }
> >> >> }
> >> >> +
> >> >> res->start = __pfn_to_phys(memblock_region_memory_base_pfn(region));
> >> >> res->end = __pfn_to_phys(memblock_region_memory_end_pfn(region)) - 1;
> >> >>
> >> >> @@ -292,6 +301,7 @@ void __init setup_arch(char **cmdline_p)
> >> >>
> >> >> request_standard_resources();
> >> >>
> >> >> + efi_memmap_unmap();
> >> >> early_ioremap_reset();
> >> >>
> >> >> if (acpi_disabled)
> >> >> diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c
> >> >> index 80d1a885def5..a7c522eac640 100644
> >> >> --- a/drivers/firmware/efi/arm-init.c
> >> >> +++ b/drivers/firmware/efi/arm-init.c
> >> >> @@ -259,7 +259,6 @@ void __init efi_init(void)
> >> >>
> >> >> reserve_regions();
> >> >> efi_esrt_init();
> >> >> - efi_memmap_unmap();
> >> >>
> >> >> memblock_reserve(params.mmap & PAGE_MASK,
> >> >> PAGE_ALIGN(params.mmap_size +
> >> >>
> >> >>
> >> >> After this change the ACPI reclaim regions are properly recognized in
> >> >> '/proc/iomem':
> >> >>
> >> >> # cat /proc/iomem | grep -i ACPI
> >> >> 396c0000-3975ffff : ACPI reclaim region
> >> >> 39770000-397affff : ACPI reclaim region
> >> >> 398a0000-398bffff : ACPI reclaim region
> >> >>
> >> >> 6c). I am currently changing the 'kexec-tools' and will finish the
> >> >> testing over the next few days.
> >> >>
> >> >> I just wanted to know your opinion on this issue, so that I will be
> >> >> able to propose a fix on the above lines.
> >> >>
> >> >> Also Cc'ing kexec mailing list for more inputs on changes proposed to
> >> >> kexec-tools.
> >> >>
> >> >> Thanks,
> >> >> Bhupesh
^ permalink raw reply
* [PATCH v3 04/11] thermal: armada: Rationalize register accesses
From: Baruch Siach @ 2017-12-15 8:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214103011.24713-5-miquel.raynal@free-electrons.com>
Hi Miqu?l,
On Thu, Dec 14, 2017 at 11:30:04AM +0100, Miquel Raynal wrote:
> Bindings were incomplete for a long time by only exposing one of the two
> available control registers. To ease the migration to the full bindings
> (already in use for the Armada 375 SoC), rename the pointers for
> clarification. This way, it will only be needed to add another pointer
> to access the other control register when the time comes.
>
> This avoids dangerous situations where the offset 0 of the control
> area can be either one register or the other depending on the bindings
> used. After this change, device trees of other SoCs could be migrated to
> the "full" bindings if they may benefit from features from the
> unaccessible register, without any change in the driver.
>
> Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
> ---
> drivers/thermal/armada_thermal.c | 86 +++++++++++++++++++++++++---------------
> 1 file changed, 55 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
> index 26698f2d3ca7..e5b184cee79b 100644
> --- a/drivers/thermal/armada_thermal.c
> +++ b/drivers/thermal/armada_thermal.c
> @@ -39,12 +39,21 @@
> #define A375_HW_RESETn BIT(8)
> #define A380_HW_RESET BIT(8)
>
> +/* Legacy bindings */
> +#define LEGACY_CONTROL_MEM_LEN 0x4
> +
> +/* Current bindings with the 2 control registers under the same memory area */
> +#define LEGACY_CONTROL1_OFFSET 0x0
> +#define CONTROL0_OFFSET 0x0
> +#define CONTROL1_OFFSET 0x4
> +
> struct armada_thermal_data;
>
> /* Marvell EBU Thermal Sensor Dev Structure */
> struct armada_thermal_priv {
> - void __iomem *sensor;
> - void __iomem *control;
> + void __iomem *status;
> + void __iomem *control0;
> + void __iomem *control1;
The 'status' -> 'sensor' rename is not mentioned in the commit log. I'd say it
is a matter for a separate patch.
Otherwise, good cleanup.
baruch
> struct armada_thermal_data *data;
> };
>
> @@ -71,45 +80,45 @@ struct armada_thermal_data {
> static void armadaxp_init_sensor(struct platform_device *pdev,
> struct armada_thermal_priv *priv)
> {
> - unsigned long reg;
> + u32 reg;
>
> - reg = readl_relaxed(priv->control);
> + reg = readl_relaxed(priv->control1);
> reg |= PMU_TDC0_OTF_CAL_MASK;
> - writel(reg, priv->control);
> + writel(reg, priv->control1);
>
> /* Reference calibration value */
> reg &= ~PMU_TDC0_REF_CAL_CNT_MASK;
> reg |= (0xf1 << PMU_TDC0_REF_CAL_CNT_OFFS);
> - writel(reg, priv->control);
> + writel(reg, priv->control1);
>
> /* Reset the sensor */
> - reg = readl_relaxed(priv->control);
> - writel((reg | PMU_TDC0_SW_RST_MASK), priv->control);
> + reg = readl_relaxed(priv->control1);
> + writel((reg | PMU_TDC0_SW_RST_MASK), priv->control1);
>
> - writel(reg, priv->control);
> + writel(reg, priv->control1);
>
> /* Enable the sensor */
> - reg = readl_relaxed(priv->sensor);
> + reg = readl_relaxed(priv->status);
> reg &= ~PMU_TM_DISABLE_MASK;
> - writel(reg, priv->sensor);
> + writel(reg, priv->status);
> }
>
> static void armada370_init_sensor(struct platform_device *pdev,
> struct armada_thermal_priv *priv)
> {
> - unsigned long reg;
> + u32 reg;
>
> - reg = readl_relaxed(priv->control);
> + reg = readl_relaxed(priv->control1);
> reg |= PMU_TDC0_OTF_CAL_MASK;
> - writel(reg, priv->control);
> + writel(reg, priv->control1);
>
> /* Reference calibration value */
> reg &= ~PMU_TDC0_REF_CAL_CNT_MASK;
> reg |= (0xf1 << PMU_TDC0_REF_CAL_CNT_OFFS);
> - writel(reg, priv->control);
> + writel(reg, priv->control1);
>
> reg &= ~PMU_TDC0_START_CAL_MASK;
> - writel(reg, priv->control);
> + writel(reg, priv->control1);
>
> msleep(10);
> }
> @@ -117,37 +126,37 @@ static void armada370_init_sensor(struct platform_device *pdev,
> static void armada375_init_sensor(struct platform_device *pdev,
> struct armada_thermal_priv *priv)
> {
> - unsigned long reg;
> + u32 reg;
>
> - reg = readl(priv->control + 4);
> + reg = readl(priv->control1);
> reg &= ~(A375_UNIT_CONTROL_MASK << A375_UNIT_CONTROL_SHIFT);
> reg &= ~A375_READOUT_INVERT;
> reg &= ~A375_HW_RESETn;
>
> - writel(reg, priv->control + 4);
> + writel(reg, priv->control1);
> msleep(20);
>
> reg |= A375_HW_RESETn;
> - writel(reg, priv->control + 4);
> + writel(reg, priv->control1);
> msleep(50);
> }
>
> static void armada380_init_sensor(struct platform_device *pdev,
> struct armada_thermal_priv *priv)
> {
> - unsigned long reg = readl_relaxed(priv->control);
> + u32 reg = readl_relaxed(priv->control1);
>
> /* Reset hardware once */
> if (!(reg & A380_HW_RESET)) {
> reg |= A380_HW_RESET;
> - writel(reg, priv->control);
> + writel(reg, priv->control1);
> msleep(10);
> }
> }
>
> static bool armada_is_valid(struct armada_thermal_priv *priv)
> {
> - unsigned long reg = readl_relaxed(priv->sensor);
> + u32 reg = readl_relaxed(priv->status);
>
> return reg & priv->data->is_valid_bit;
> }
> @@ -156,7 +165,7 @@ static int armada_get_temp(struct thermal_zone_device *thermal,
> int *temp)
> {
> struct armada_thermal_priv *priv = thermal->devdata;
> - unsigned long reg;
> + u32 reg;
> unsigned long m, b, div;
>
> /* Valid check */
> @@ -166,7 +175,7 @@ static int armada_get_temp(struct thermal_zone_device *thermal,
> return -EIO;
> }
>
> - reg = readl_relaxed(priv->sensor);
> + reg = readl_relaxed(priv->status);
> reg = (reg >> priv->data->temp_shift) & priv->data->temp_mask;
>
> /* Get formula coeficients */
> @@ -253,6 +262,7 @@ MODULE_DEVICE_TABLE(of, armada_thermal_id_table);
>
> static int armada_thermal_probe(struct platform_device *pdev)
> {
> + void __iomem *control = NULL;
> struct thermal_zone_device *thermal;
> const struct of_device_id *match;
> struct armada_thermal_priv *priv;
> @@ -267,14 +277,28 @@ static int armada_thermal_probe(struct platform_device *pdev)
> return -ENOMEM;
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - priv->sensor = devm_ioremap_resource(&pdev->dev, res);
> - if (IS_ERR(priv->sensor))
> - return PTR_ERR(priv->sensor);
> + priv->status = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(priv->status))
> + return PTR_ERR(priv->status);
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> - priv->control = devm_ioremap_resource(&pdev->dev, res);
> - if (IS_ERR(priv->control))
> - return PTR_ERR(priv->control);
> + control = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(control))
> + return PTR_ERR(control);
> +
> + /*
> + * Legacy DT bindings only described "control1" register (also referred
> + * as "control MSB" on old documentation). New bindings cover
> + * "control0/control LSB" and "control1/control MSB" registers within
> + * the same resource, which is then of size 8 instead of 4.
> + */
> + if ((res->end - res->start) == LEGACY_CONTROL_MEM_LEN) {
> + /* ->control0 unavailable in this configuration */
> + priv->control1 = control + LEGACY_CONTROL1_OFFSET;
> + } else {
> + priv->control0 = control + CONTROL0_OFFSET;
> + priv->control1 = control + CONTROL1_OFFSET;
> + }
>
> priv->data = (struct armada_thermal_data *)match->data;
> priv->data->init_sensor(pdev, priv);
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
^ permalink raw reply
* [PATCH 1/6] ARM: shmobile: defconfig: Enable PWM
From: Geert Uytterhoeven @ 2017-12-15 8:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513248976-26700-2-git-send-email-fabrizio.castro@bp.renesas.com>
Hi Fabrizio,
On Thu, Dec 14, 2017 at 11:56 AM, Fabrizio Castro
<fabrizio.castro@bp.renesas.com> wrote:
> RZ/G1 and R-Car platforms have PWM timers. This patch enables PWM support
> by default.
>
> Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> Reviewed-by: Biju Das <biju.das@bp.renesas.com>
Thanks for your patch!
If I'm not mistaken, there are no current users of this PWM block in the
current R-Car Gen2 and RZ/G1 DTS files?
If that's correct, I don't think it makes much sense to enable it already.
Simon: what do you think?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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
* [PATCH 4/4] clocksource: stm32: Update license and copyright
From: Benjamin Gaignard @ 2017-12-15 8:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215085247.14946-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 38eb59bb7f8a..83603d4b5706 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 3/4] clocksource: stm32: add clocksource support
From: Benjamin Gaignard @ 2017-12-15 8:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215085247.14946-1-benjamin.gaignard@st.com>
The stm32 timer hardware is currently only used as a clock event device,
but it can be used 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@st.com>
---
drivers/clocksource/timer-stm32.c | 114 ++++++++++++++++++++++++++++----------
1 file changed, 86 insertions(+), 28 deletions(-)
diff --git a/drivers/clocksource/timer-stm32.c b/drivers/clocksource/timer-stm32.c
index de721d318065..38eb59bb7f8a 100644
--- a/drivers/clocksource/timer-stm32.c
+++ b/drivers/clocksource/timer-stm32.c
@@ -16,6 +16,7 @@
#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"
@@ -24,17 +25,15 @@
#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)
#define MAX_TIM_PSC 0xFFFF
@@ -46,29 +45,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;
+
+ 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(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(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;
}
@@ -80,6 +94,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;
@@ -88,22 +107,46 @@ static irqreturn_t stm32_clock_event_handler(int irq, void *dev_id)
static void __init stm32_clockevent_init(struct timer_of *to)
{
unsigned long max_delta;
- unsigned long prescaler;
to->clkevt.name = "stm32_clockevent";
- 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;
/* Detect whether the timer is 16 or 32 bits */
+ max_delta = readl_relaxed(timer_of_base(to) + TIM_ARR);
+
+ clockevents_config_and_register(&to->clkevt,
+ timer_of_rate(to), 0x1, max_delta);
+}
+
+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)
+{
+ unsigned long max_delta, prescaler;
+ int bits = 16;
+
writel_relaxed(~0U, timer_of_base(to) + TIM_ARR);
+ writel_relaxed(0, timer_of_base(to) + TIM_SR);
+ writel_relaxed(0, timer_of_base(to) + TIM_DIER);
+
+ /* Detect whether the timer is 16 or 32 bits */
max_delta = readl_relaxed(timer_of_base(to) + TIM_ARR);
+
to->clkevt.rating = 50;
- if (max_delta == ~0U)
+ if (max_delta == ~0U) {
+ bits = 32;
to->clkevt.rating = 250;
+ }
/*
* Get the highest possible prescaler value to be as close
@@ -113,18 +156,27 @@ static void __init stm32_clockevent_init(struct timer_of *to)
if (prescaler > MAX_TIM_PSC)
prescaler = MAX_TIM_PSC;
- writel_relaxed(0, timer_of_base(to) + TIM_ARR);
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);
- /* adjust rate and period given the prescaler value */
+ /* Adjust rate and period given the prescaler value */
to->of_clk.rate = DIV_ROUND_CLOSEST(to->of_clk.rate, prescaler);
to->of_clk.period = DIV_ROUND_UP(to->of_clk.rate, HZ);
- clockevents_config_and_register(&to->clkevt,
- timer_of_rate(to), 0x1, max_delta);
+ /* 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, bits, timer_of_rate(to));
+
+ return clocksource_mmio_init(stm32_timer_cnt, "stm32_timer",
+ timer_of_rate(to),
+ to->clkevt.rating,
+ bits,
+ clocksource_mmio_readl_up);
}
static int __init stm32_timer_init(struct device_node *node)
@@ -150,10 +202,16 @@ static int __init stm32_timer_init(struct device_node *node)
reset_control_deassert(rstc);
}
+ ret = stm32_clocksource_init(to);
+ if (ret)
+ goto deinit;
+
stm32_clockevent_init(to);
return 0;
+deinit:
+ timer_of_cleanup(to);
err:
kfree(to);
return ret;
--
2.15.0
^ permalink raw reply related
* [PATCH 2/4] clocksource: stm32: use prescaler to adjust the resolution
From: Benjamin Gaignard @ 2017-12-15 8:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215085247.14946-1-benjamin.gaignard@st.com>
Rather than use fixed prescaler values compute it to get a clock
as close as possible of 10KHz and a resolution of 0.1ms.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
---
drivers/clocksource/timer-stm32.c | 23 ++++++++++++++++-------
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/drivers/clocksource/timer-stm32.c b/drivers/clocksource/timer-stm32.c
index 23a321cca45b..de721d318065 100644
--- a/drivers/clocksource/timer-stm32.c
+++ b/drivers/clocksource/timer-stm32.c
@@ -37,6 +37,11 @@
#define TIM_EGR_UG BIT(0)
+#define MAX_TIM_PSC 0xFFFF
+
+/* Target a 10KHz clock to get a resolution of 0.1 ms */
+#define TARGETED_CLK_RATE 10000
+
static int stm32_clock_event_shutdown(struct clock_event_device *evt)
{
struct timer_of *to = to_timer_of(evt);
@@ -83,7 +88,7 @@ static irqreturn_t stm32_clock_event_handler(int irq, void *dev_id)
static void __init stm32_clockevent_init(struct timer_of *to)
{
unsigned long max_delta;
- int prescaler;
+ unsigned long prescaler;
to->clkevt.name = "stm32_clockevent";
to->clkevt.features = CLOCK_EVT_FEAT_PERIODIC;
@@ -96,13 +101,17 @@ static void __init stm32_clockevent_init(struct timer_of *to)
/* 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;
+ to->clkevt.rating = 50;
+ if (max_delta == ~0U)
to->clkevt.rating = 250;
- } else {
- prescaler = 1024;
- to->clkevt.rating = 50;
- }
+
+ /*
+ * Get the highest possible prescaler value to be as close
+ * as possible of TARGETED_CLK_RATE
+ */
+ prescaler = DIV_ROUND_CLOSEST(timer_of_rate(to), TARGETED_CLK_RATE);
+ if (prescaler > MAX_TIM_PSC)
+ prescaler = MAX_TIM_PSC;
writel_relaxed(0, timer_of_base(to) + TIM_ARR);
writel_relaxed(prescaler - 1, timer_of_base(to) + TIM_PSC);
--
2.15.0
^ permalink raw reply related
* [PATCH 1/4] clocksource: stm32: convert driver to timer_of
From: Benjamin Gaignard @ 2017-12-15 8:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215085247.14946-1-benjamin.gaignard@st.com>
Convert driver to use timer_of helpers. This allow to remove
custom proprietary structure.
Given counter number of bits (16 or 32) set a different
prescaler value and adjust timer_of rate, period and rating.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
---
drivers/clocksource/Kconfig | 1 +
drivers/clocksource/timer-stm32.c | 179 +++++++++++++++-----------------------
2 files changed, 72 insertions(+), 108 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..23a321cca45b 100644
--- a/drivers/clocksource/timer-stm32.c
+++ b/drivers/clocksource/timer-stm32.c
@@ -16,6 +16,9 @@
#include <linux/of_irq.h>
#include <linux/clk.h>
#include <linux/reset.h>
+#include <linux/slab.h>
+
+#include "timer-of.h"
#define TIM_CR1 0x00
#define TIM_DIER 0x0c
@@ -34,157 +37,117 @@
#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, timer_of_base(to) + TIM_CR1);
- writel_relaxed(0, base + 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 void __init stm32_clockevent_init(struct timer_of *to)
{
- 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;
- }
+ unsigned long max_delta;
+ int prescaler;
- rate = clk_get_rate(clk);
-
- rstc = of_reset_control_get(np, 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;
- }
+ to->clkevt.name = "stm32_clockevent";
+ 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;
/* 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;
+ to->clkevt.rating = 250;
} else {
prescaler = 1024;
- bits = 16;
+ to->clkevt.rating = 50;
}
- 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);
+ 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);
+
+ /* adjust rate and period given the prescaler value */
+ to->of_clk.rate = DIV_ROUND_CLOSEST(to->of_clk.rate, prescaler);
+ to->of_clk.period = DIV_ROUND_UP(to->of_clk.rate, HZ);
+
+ clockevents_config_and_register(&to->clkevt,
+ timer_of_rate(to), 0x1, max_delta);
+}
+
+static int __init stm32_timer_init(struct device_node *node)
+{
+ struct reset_control *rstc;
+ struct timer_of *to;
+ int ret;
+
+ to = kzalloc(sizeof(*to), GFP_KERNEL);
+ if (!to)
+ return -ENOMEM;
- data->periodic_top = DIV_ROUND_CLOSEST(rate, prescaler * HZ);
+ to->flags = TIMER_OF_IRQ | TIMER_OF_CLOCK | TIMER_OF_BASE;
+ to->of_irq.handler = stm32_clock_event_handler;
- clockevents_config_and_register(&data->evtdev,
- DIV_ROUND_CLOSEST(rate, prescaler),
- 0x1, max_delta);
+ ret = timer_of_init(node, to);
+ if (ret)
+ goto err;
- 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;
+ rstc = of_reset_control_get(node, NULL);
+ if (!IS_ERR(rstc)) {
+ reset_control_assert(rstc);
+ reset_control_deassert(rstc);
}
- pr_info("%pOF: STM32 clockevent driver initialized (%d bits)\n",
- np, bits);
+ stm32_clockevent_init(to);
- 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;
}
-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 0/4] stm32 clocksource driver rework
From: Benjamin Gaignard @ 2017-12-15 8:52 UTC (permalink / raw)
To: linux-arm-kernel
version 10:
- do not remove 16 bits timer support
- use prescaler to get a 10KHz clock
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 (4):
clocksource: stm32: convert driver to timer_of
clocksource: stm32: use prescaler to adjust the resolution
clocksource: stm32: add clocksource support
clocksource: stm32: Update license and copyright
drivers/clocksource/Kconfig | 1 +
drivers/clocksource/timer-stm32.c | 258 +++++++++++++++++++++-----------------
2 files changed, 146 insertions(+), 113 deletions(-)
--
2.15.0
^ permalink raw reply
* [PATCH] ARM: dts: sun7i: Enable HDMI on pcDuino3 Nano
From: Tuomas Tynkkynen @ 2017-12-15 8:52 UTC (permalink / raw)
To: linux-arm-kernel
The board has a regular-sized HDMI connector, so enable the display
the pipeline and HDMI output for it.
Signed-off-by: Tuomas Tynkkynen <tuomas@tuxera.com>
---
arch/arm/boot/dts/sun7i-a20-pcduino3-nano.dts | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20-pcduino3-nano.dts b/arch/arm/boot/dts/sun7i-a20-pcduino3-nano.dts
index 39bc73db72e5..fb591f32252c 100644
--- a/arch/arm/boot/dts/sun7i-a20-pcduino3-nano.dts
+++ b/arch/arm/boot/dts/sun7i-a20-pcduino3-nano.dts
@@ -58,6 +58,17 @@
stdout-path = "serial0:115200n8";
};
+ hdmi-connector {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con_in: endpoint {
+ remote-endpoint = <&hdmi_out_con>;
+ };
+ };
+ };
+
leds {
compatible = "gpio-leds";
pinctrl-names = "default";
@@ -90,6 +101,10 @@
cpu-supply = <®_dcdc2>;
};
+&de {
+ status = "okay";
+};
+
&ehci0 {
status = "okay";
};
@@ -110,6 +125,16 @@
};
};
+&hdmi {
+ status = "okay";
+};
+
+&hdmi_out {
+ hdmi_out_con: endpoint {
+ remote-endpoint = <&hdmi_con_in>;
+ };
+};
+
&i2c0 {
pinctrl-names = "default";
pinctrl-0 = <&i2c0_pins_a>;
--
2.15.0
^ permalink raw reply related
* [PATCH] arm: dts: Remove leading 0x and 0s from bindings notation
From: Jesper Nilsson @ 2017-12-15 8:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214165350.27850-1-malat@debian.org>
On Thu, Dec 14, 2017 at 05:53:48PM +0100, Mathieu Malaterre wrote:
> Improve the DTS files by removing all the leading "0x" and zeros to fix the
> following dtc warnings:
>
> Warning (unit_address_format): Node /XXX unit name should not have leading "0x"
>
> and
>
> Warning (unit_address_format): Node /XXX unit name should not have leading 0s
>
> Converted using the following command:
>
> find . -type f \( -iname *.dts -o -iname *.dtsi \) -exec sed -E -i -e "s/@0x([0-9a-fA-F\.]+)\s?\{/@\L\1 \{/g" -e "s/@0+([0-9a-fA-F\.]+)\s?\{/@\L\1 \{/g" {} +
>
> For simplicity, two sed expressions were used to solve each warnings separately.
>
> To make the regex expression more robust a few other issues were resolved,
> namely setting unit-address to lower case, and adding a whitespace before the
> the opening curly brace:
>
> https://elinux.org/Device_Tree_Linux#Linux_conventions
>
> This is a follow up to commit 4c9847b7375a ("dt-bindings: Remove leading 0x from bindings notation")
>
> Reported-by: David Daney <ddaney@caviumnetworks.com>
> Suggested-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Mathieu Malaterre <malat@debian.org>
> ---
> arch/arm/boot/dts/artpec6.dtsi | 2 +-
Acked-by: Jesper Nilsson <jesper.nilsson@axis.com>
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nilsson at axis.com
^ permalink raw reply
* [PATCH v3 01/11] dt-bindings: thermal: Describe Armada AP806 and CP110
From: Gregory CLEMENT @ 2017-12-15 8:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215093203.74b7a59c@xps13>
Hi Miquel,
On ven., d?c. 15 2017, Miquel RAYNAL <miquel.raynal@free-electrons.com> wrote:
> Hello Baruch,
>
> On Fri, 15 Dec 2017 10:27:59 +0200
> Baruch Siach <baruch@tkos.co.il> wrote:
>
>> Hi Miquel
>>
>> On Thu, Dec 14, 2017 at 11:30:01AM +0100, Miquel Raynal wrote:
>> > +- marvell,thermal-zone-name: The name to identify the thermal zone
>> > + within the sysfs, useful when multiple
>> > + thermal zones are registered (AP,
>> > CPx...).
>>
>> I don't think that would be acceptable. DT is about describing the
>> hardware. sysfs is a Linux implementation detail which is not tied to
>> any specific hardware. If this is accepted, the property should be
>> named 'linux,thermal-zone-name'.
>
> You are right the sysfs mention should not appear in the description.
>
> Otherwise for the naming I'm not sure "linux," is a valid prefix in
> that case.
Actually the choice between linux or marvell make me realize that there
is something wrong. Having a name associated to a device is something
pretty usual with the device tree, however it is as the class device
level, such as clock-names, line-name, or regulator-name. So in my
opinion if we want to support naming from device tree it would be done
for all the thermal device not just for the Marvell one.
However I don't think we need it. For example for the clocks we created
the name dynamically using of the base address of the register to keep
them unique.
Gregory
>
> Miqu?l
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH v3 01/11] dt-bindings: thermal: Describe Armada AP806 and CP110
From: Baruch Siach @ 2017-12-15 8:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215093203.74b7a59c@xps13>
HI Miqu?l
On Fri, Dec 15, 2017 at 09:32:03AM +0100, Miquel RAYNAL wrote:
> On Fri, 15 Dec 2017 10:27:59 +0200
> Baruch Siach <baruch@tkos.co.il> wrote:
> >
> > On Thu, Dec 14, 2017 at 11:30:01AM +0100, Miquel Raynal wrote:
> > > +- marvell,thermal-zone-name: The name to identify the thermal zone
> > > + within the sysfs, useful when multiple
> > > + thermal zones are registered (AP,
> > > CPx...).
> >
> > I don't think that would be acceptable. DT is about describing the
> > hardware. sysfs is a Linux implementation detail which is not tied to
> > any specific hardware. If this is accepted, the property should be
> > named 'linux,thermal-zone-name'.
>
> You are right the sysfs mention should not appear in the description.
My comment was not about the description language. I don't think that this
property is acceptable at all. But I'll let DT maintainers comment on that.
> Otherwise for the naming I'm not sure "linux," is a valid prefix in
> that case.
We use the 'linux' prefix for input key names and led triggers, for example.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
^ permalink raw reply
* [PATCH v2 1/5] extcon: usbc-cros-ec: add support to notify USB type cables.
From: Chanwoo Choi @ 2017-12-15 8:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5A3385D0.2050308@samsung.com>
On 2017? 12? 15? 17:20, Chanwoo Choi wrote:
> On 2017? 12? 15? 17:14, Lee Jones wrote:
>>> On 2017? 12? 13? 19:32, Enric Balletbo i Serra wrote:
>>>> From: Benson Leung <bleung@chromium.org>
>>>>
>>>> Extend the driver to notify host and device type cables and the presence
>>>> of power.
>>>>
>>>> Signed-off-by: Benson Leung <bleung@chromium.org>
>>>> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
>>>> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
>>>> ---
>>>> Changes since v1:
>>>> - Use the BIT macro. Requested by Lee Jones.
>>>> - Add the Reviewed-by: Chanwoo Choi.
>>>>
>>>> drivers/extcon/extcon-usbc-cros-ec.c | 142 ++++++++++++++++++++++++++++++++++-
>>>> include/linux/mfd/cros_ec_commands.h | 17 +++++
>>>> 2 files changed, 155 insertions(+), 4 deletions(-)
>>
>>> Looks good to me. After reviewing the Lee Jones,
>>> I'll take it on next branch.
>>
>> If you take it, you need to send me a pull-request to an immutable
>> branch.
>>
>> Acked-by: Lee Jones <lee.jones@linaro.org>
>>
>
> Sure. I'll send the immutable branch. Thanks.
>
Dear Lee,
I make the immutable branch (ib-extcon-mfd-4.16)
and send the following pull request.
The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git ib-extcon-mfd-4.16
for you to fetch changes up to c7eb47f9e45226571be31212f6efd4b307d3b59d:
extcon: usbc-cros-ec: add support to notify USB type cables. (2017-12-15 17:21:49 +0900)
----------------------------------------------------------------
Benson Leung (1):
extcon: usbc-cros-ec: add support to notify USB type cables.
drivers/extcon/extcon-usbc-cros-ec.c | 142 ++++++++++++++++++++++++++++++++++-
include/linux/mfd/cros_ec_commands.h | 17 +++++
2 files changed, 155 insertions(+), 4 deletions(-)
--
Best Regards,
Chanwoo Choi
Samsung Electronics
^ permalink raw reply
* [PATCH v3 03/11] thermal: armada: Simplify the check of the validity bit
From: Baruch Siach @ 2017-12-15 8:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214103011.24713-4-miquel.raynal@free-electrons.com>
Hi Miquel,
On Thu, Dec 14, 2017 at 11:30:03AM +0100, Miquel Raynal wrote:
> All Armada SoCs use one bit to declare if the sensor values are valid.
> This bit moves across the versions of the IP.
>
> The method until then was to do both a shift and compare with an useless
> flag of "0x1". It is clearer and quicker to directly save the value that
> must be ANDed instead of the bit position and do a single bitwise AND
> operation.
>
> Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
> ---
> drivers/thermal/armada_thermal.c | 12 +++++-------
> 1 file changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
> index 6c4af2622d4f..26698f2d3ca7 100644
> --- a/drivers/thermal/armada_thermal.c
> +++ b/drivers/thermal/armada_thermal.c
> @@ -24,8 +24,6 @@
> #include <linux/of_device.h>
> #include <linux/thermal.h>
>
> -#define THERMAL_VALID_MASK 0x1
> -
> /* Thermal Manager Control and Status Register */
> #define PMU_TDC0_SW_RST_MASK (0x1 << 1)
> #define PMU_TM_DISABLE_OFFS 0
> @@ -67,7 +65,7 @@ struct armada_thermal_data {
> /* Register shift and mask to access the sensor temperature */
> unsigned int temp_shift;
> unsigned int temp_mask;
> - unsigned int is_valid_shift;
> + unsigned int is_valid_bit;
Type should be u32 now, I think.
> };
>
> static void armadaxp_init_sensor(struct platform_device *pdev,
> @@ -151,7 +149,7 @@ static bool armada_is_valid(struct armada_thermal_priv *priv)
> {
> unsigned long reg = readl_relaxed(priv->sensor);
u32 here also, I think. But that's unrelated to this patch.
> - return (reg >> priv->data->is_valid_shift) & THERMAL_VALID_MASK;
> + return reg & priv->data->is_valid_bit;
> }
>
> static int armada_get_temp(struct thermal_zone_device *thermal,
> @@ -199,7 +197,7 @@ static const struct armada_thermal_data armadaxp_data = {
> static const struct armada_thermal_data armada370_data = {
> .is_valid = armada_is_valid,
> .init_sensor = armada370_init_sensor,
> - .is_valid_shift = 9,
> + .is_valid_bit = BIT(9),
> .temp_shift = 10,
> .temp_mask = 0x1ff,
> .coef_b = 3153000000UL,
> @@ -210,7 +208,7 @@ static const struct armada_thermal_data armada370_data = {
> static const struct armada_thermal_data armada375_data = {
> .is_valid = armada_is_valid,
> .init_sensor = armada375_init_sensor,
> - .is_valid_shift = 10,
> + .is_valid_bit = BIT(10),
> .temp_shift = 0,
> .temp_mask = 0x1ff,
> .coef_b = 3171900000UL,
> @@ -221,7 +219,7 @@ static const struct armada_thermal_data armada375_data = {
> static const struct armada_thermal_data armada380_data = {
> .is_valid = armada_is_valid,
> .init_sensor = armada380_init_sensor,
> - .is_valid_shift = 10,
> + .is_valid_bit = BIT(10),
> .temp_shift = 0,
> .temp_mask = 0x3ff,
> .coef_b = 1172499100UL,
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
^ permalink raw reply
* [PATCH v3 01/11] dt-bindings: thermal: Describe Armada AP806 and CP110
From: Miquel RAYNAL @ 2017-12-15 8:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215082759.7t24ka3lpkulcb7r@tarshish>
Hello Baruch,
On Fri, 15 Dec 2017 10:27:59 +0200
Baruch Siach <baruch@tkos.co.il> wrote:
> Hi Miquel
>
> On Thu, Dec 14, 2017 at 11:30:01AM +0100, Miquel Raynal wrote:
> > +- marvell,thermal-zone-name: The name to identify the thermal zone
> > + within the sysfs, useful when multiple
> > + thermal zones are registered (AP,
> > CPx...).
>
> I don't think that would be acceptable. DT is about describing the
> hardware. sysfs is a Linux implementation detail which is not tied to
> any specific hardware. If this is accepted, the property should be
> named 'linux,thermal-zone-name'.
You are right the sysfs mention should not appear in the description.
Otherwise for the naming I'm not sure "linux," is a valid prefix in
that case.
Miqu?l
^ permalink raw reply
* [PATCH v3 01/11] dt-bindings: thermal: Describe Armada AP806 and CP110
From: Baruch Siach @ 2017-12-15 8:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214103011.24713-2-miquel.raynal@free-electrons.com>
Hi Miquel
On Thu, Dec 14, 2017 at 11:30:01AM +0100, Miquel Raynal wrote:
> +- marvell,thermal-zone-name: The name to identify the thermal zone
> + within the sysfs, useful when multiple
> + thermal zones are registered (AP, CPx...).
I don't think that would be acceptable. DT is about describing the hardware.
sysfs is a Linux implementation detail which is not tied to any specific
hardware. If this is accepted, the property should be named
'linux,thermal-zone-name'.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
^ 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