* [PATCH V3] ACPI / GED: unregister interrupts during shutdown
From: Rafael J. Wysocki @ 2017-12-08 13:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512708033-28180-1-git-send-email-okaya@codeaurora.org>
On Fri, Dec 8, 2017 at 5:40 AM, Sinan Kaya <okaya@codeaurora.org> wrote:
> Some GED interrupts could be pending by the time we are doing a reboot.
>
> Even though GED driver uses devm_request_irq() to register the interrupt
> handler, the handler is not being freed on time during a shutdown since
> the driver is missing a shutdown callback.
>
> If the ACPI handler is no longer available, this causes an interrupt
> storm and delays shutdown.
>
> 1. Don't use devm family of functions for IRQ registration/free
> 2. Keep track of the events since free_irq() requires the dev_id parameter
> passed into the request_irq() function.
> 3. Call free_irq() on both remove and shutdown explicitly.
>
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> ---
> drivers/acpi/evged.c | 55 ++++++++++++++++++++++++++++++++++++++++++++++------
> 1 file changed, 49 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/acpi/evged.c b/drivers/acpi/evged.c
> index 46f0603..38cb00e 100644
> --- a/drivers/acpi/evged.c
> +++ b/drivers/acpi/evged.c
> @@ -49,6 +49,11 @@
>
> #define MODULE_NAME "acpi-ged"
>
> +struct acpi_ged_device {
> + struct device *dev;
> + struct list_head event_list;
> +};
> +
> struct acpi_ged_event {
> struct list_head node;
> struct device *dev;
> @@ -76,7 +81,8 @@ static acpi_status acpi_ged_request_interrupt(struct acpi_resource *ares,
> unsigned int irq;
> unsigned int gsi;
> unsigned int irqflags = IRQF_ONESHOT;
> - struct device *dev = context;
> + struct acpi_ged_device *geddev = context;
> + struct device *dev = geddev->dev;
> acpi_handle handle = ACPI_HANDLE(dev);
> acpi_handle evt_handle;
> struct resource r;
> @@ -102,8 +108,6 @@ static acpi_status acpi_ged_request_interrupt(struct acpi_resource *ares,
> return AE_ERROR;
> }
>
> - dev_info(dev, "GED listening GSI %u @ IRQ %u\n", gsi, irq);
> -
> event = devm_kzalloc(dev, sizeof(*event), GFP_KERNEL);
> if (!event)
> return AE_ERROR;
> @@ -116,26 +120,63 @@ static acpi_status acpi_ged_request_interrupt(struct acpi_resource *ares,
> if (r.flags & IORESOURCE_IRQ_SHAREABLE)
> irqflags |= IRQF_SHARED;
>
> - if (devm_request_threaded_irq(dev, irq, NULL, acpi_ged_irq_handler,
> - irqflags, "ACPI:Ged", event)) {
> + if (request_threaded_irq(irq, NULL, acpi_ged_irq_handler,
> + irqflags, "ACPI:Ged", event)) {
> dev_err(dev, "failed to setup event handler for irq %u\n", irq);
> return AE_ERROR;
> }
>
> + dev_dbg(dev, "GED listening GSI %u @ IRQ %u\n", gsi, irq);
> + list_add_tail(&event->node, &geddev->event_list);
> return AE_OK;
> }
>
> static int ged_probe(struct platform_device *pdev)
> {
> + struct acpi_ged_device *geddev;
> acpi_status acpi_ret;
>
> + geddev = devm_kzalloc(&pdev->dev, sizeof(*geddev), GFP_KERNEL);
> + if (!geddev)
> + return -ENOMEM;
> +
> + geddev->dev = &pdev->dev;
> + INIT_LIST_HEAD(&geddev->event_list);
> acpi_ret = acpi_walk_resources(ACPI_HANDLE(&pdev->dev), "_CRS",
> - acpi_ged_request_interrupt, &pdev->dev);
> + acpi_ged_request_interrupt, geddev);
> if (ACPI_FAILURE(acpi_ret)) {
> dev_err(&pdev->dev, "unable to parse the _CRS record\n");
> return -EINVAL;
> }
> + platform_set_drvdata(pdev, geddev);
> +
> + return 0;
> +}
> +
> +static void ged_cleanup_irq(struct acpi_ged_device *geddev)
> +{
> + struct acpi_ged_event *event, *next;
> +
> + list_for_each_entry_safe(event, next, &geddev->event_list, node) {
> + free_irq(event->irq, event);
> + list_del(&event->node);
> + dev_dbg(geddev->dev, "GED releasing GSI %u @ IRQ %u\n",
> + event->gsi, event->irq);
> + }
> +}
> +
> +static void ged_shutdown(struct platform_device *pdev)
> +{
> + struct acpi_ged_device *geddev = platform_get_drvdata(pdev);
> +
> + ged_cleanup_irq(geddev);
> +}
> +
> +static int ged_remove(struct platform_device *pdev)
> +{
> + struct acpi_ged_device *geddev = platform_get_drvdata(pdev);
>
> + ged_cleanup_irq(geddev);
Do you really need this duplication? You may as well call
ged_shutdown() from here.
And the local variable is redundant too.
I guess it would be better to just fold ged_cleanup_irq() into
ged_shutdown() and call that from ged_remove().
> return 0;
> }
>
> @@ -146,6 +187,8 @@ static int ged_probe(struct platform_device *pdev)
>
> static struct platform_driver ged_driver = {
> .probe = ged_probe,
> + .remove = ged_remove,
> + .shutdown = ged_shutdown,
> .driver = {
> .name = MODULE_NAME,
> .acpi_match_table = ACPI_PTR(ged_acpi_ids),
> --
^ permalink raw reply
* [PATCH V7 0/7] dmaengine: qcom_hidma: add support for bugfixed HW
From: Rafael J. Wysocki @ 2017-12-08 13:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512681031-11343-1-git-send-email-okaya@codeaurora.org>
On Thu, Dec 7, 2017 at 10:10 PM, Sinan Kaya <okaya@codeaurora.org> wrote:
> Introduce new ACPI and OF device ids for thw HW along with the helper
> functions.
>
> Changes from v6:
> * add const to the device callback parameter in fwnode.
> * reorganize the callbacks in the code
> * rename get_match_data() as device_get_match_data()
> * place pointer checks into acpi_get_match_data()
>
> Sinan Kaya (7):
> Documentation: DT: qcom_hidma: Bump HW revision for the bugfixed HW
> ACPI / bus: Introduce acpi_get_match_data() function
> device property: Introduce a common API to fetch device match data
> OF: properties: Implement get_match_data() callback
> ACPI: properties: Implement get_match_data() callback
> dmaengine: qcom_hidma: Add support for the new revision
> dmaengine: qcom_hidma: Add identity register support
>
> .../devicetree/bindings/dma/qcom_hidma_mgmt.txt | 4 +--
> drivers/acpi/bus.c | 18 ++++++++++
> drivers/acpi/property.c | 8 +++++
> drivers/base/property.c | 7 ++++
> drivers/dma/qcom/hidma.c | 41 ++++++++++------------
> drivers/of/property.c | 8 +++++
> include/linux/acpi.h | 6 ++++
> include/linux/fwnode.h | 4 +++
> include/linux/property.h | 2 ++
> 9 files changed, 74 insertions(+), 24 deletions(-)
>
> --
The series is fine by me, by how do you want to route it?
Thanks,
Rafael
^ permalink raw reply
* [PATCH v9 3/6] clocksource: stm32: only use 32 bits timers
From: Daniel Lezcano @ 2017-12-08 13:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+M3ks5CY79SHqcfhgySgsQuPVQyJWHQJ0=OT3Zvxvu2LfUOaA@mail.gmail.com>
On 08/12/2017 14:05, Benjamin Gaignard wrote:
> 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.
No, that is because you ripped out in this patch the prescaler which was
1024.
Are you the author of this series ?
--
<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
^ permalink raw reply
* [PATCH v9 4/6] clocksource: stm32: add clocksource support
From: Daniel Lezcano @ 2017-12-08 13:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171208113250.359-5-benjamin.gaignard@st.com>
On 08/12/2017 12:32, Benjamin Gaignard wrote:
> 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.
Split this patch in two:
- periodic support
- clocksource support
--
<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
^ permalink raw reply
* [PATCH v9 5/6] clocksource: stm32: Update license and copyright
From: Philippe Ombredanne @ 2017-12-08 13:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171208113250.359-6-benjamin.gaignard@st.com>
On Fri, Dec 8, 2017 at 12:32 PM, Benjamin Gaignard
<benjamin.gaignard@linaro.org> wrote:
> 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
>
Benjamin,
Thank you for this: every little bit of help counts towards making the
whole kernel licensing easily greppable!
FWIW:
Reviewed-by: Philippe Ombredanne <pombredanne@nexB.com>
--
Philippe
^ permalink raw reply
* [PATCH] i2c: imx: Include the right GPIO header
From: Fabio Estevam @ 2017-12-08 13:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171208133535.17562-1-linus.walleij@linaro.org>
On Fri, Dec 8, 2017 at 11:35 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
> <linux/of_gpio.h> is not used in this file, by
> <linux/gpio/consumer.h> is.
s/by/but
>
> Someone is just lucky with their implicit includes.
>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Sascha Hauer <kernel@pengutronix.de>
> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Other than this nit:
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
^ permalink raw reply
* [PATCH net-next v4 1/2] net: add support for Cavium PTP coprocessor
From: Philippe Ombredanne @ 2017-12-08 13:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171208103442.19354-2-aleksey.makarov@cavium.com>
Dear Aleksey, Dear Radoslaw,
On Fri, Dec 8, 2017 at 11:34 AM, Aleksey Makarov
<aleksey.makarov@cavium.com> wrote:
> From: Radoslaw Biernacki <rad@semihalf.com>
>
> This patch adds support for the Precision Time Protocol
> Clocks and Timestamping hardware found on Cavium ThunderX
> processors.
>
> Signed-off-by: Radoslaw Biernacki <rad@semihalf.com>
> Signed-off-by: Aleksey Makarov <aleksey.makarov@cavium.com>
[]
> --- /dev/null
> +++ b/drivers/net/ethernet/cavium/common/cavium_ptp.c
> @@ -0,0 +1,334 @@
> +/*
> + * cavium_ptp.c - PTP 1588 clock on Cavium hardware
> + *
> + * Copyright (c) 2003-2015, 2017 Cavium, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License.
Have you considered using the new SPDX ids instead of this fine legalese? e.g.:
// SPDX-License-Identifier: GPL-2.0
This is much shorter and neater (unless you are a legalese lover of
course!)... Check also Thomas doc patches and Linus comments on why he
prefers the C++ comment style for these.
And even better, what about this more compact form? I am a big fan of the
C++ style comments for these (and so is Linus):
// SPDX-License-Identifier: GPL-2.0
// Copyright (c) 2003-2015, 2017 Cavium, Inc.
// cavium_ptp.c - PTP 1588 clock on Cavium hardware
> + *
> + * This file may also be available under a different license from Cavium.
> + * Contact Cavium, Inc. for more information
> + */
I am not so sure that the kernel source tree is the right place for
commercial advertisement... I mean, this is a fine statement to put on
your company web site, but who reads this code: you and I.... do we
care seriously about this? Anyone who uses your hardware would likely
have some other kind of arrangements with your company anyway, making
this sentence moot in all cases. Therefore I tend to think this is
just a noisy distraction from your otherwise fine code contributions:
It does not come out to me as kernically-correct ;)
So can you consider removing this fine marketing statement from this
and other Cavium past, present and future contributions? That would be
much appreciated! (and while you are at it, using SPDX ids throughout
would give you good karma extra points)
PS: Now, if this "different license" of yours is a fine BSD or MIT,
you could use instead this SPDX shorthand to the same effect without
turning the kernel code into a billboard:
// SPDX-License-Identifier: (GPL-2.0 OR MIT)
--
Cordially
Philippe Ombredanne, your ad-sensitive licensing scruffy
^ permalink raw reply
* [PATCH v5 8/9] pinctrl: axp209: add support for AXP813 GPIOs
From: Quentin Schulz @ 2017-12-08 13:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171205144647.17594-9-quentin.schulz@free-electrons.com>
Hi all,
There is a bug below.
On 05/12/2017 15:46, Quentin Schulz wrote:
> The AXP813 has only two GPIOs. GPIO0 can either be used as a GPIO, an
> LDO regulator or an ADC. GPIO1 can be used either as a GPIO or an LDO
> regulator.
>
> Moreover, the status bit of the GPIOs when in input mode is not offset
> by 4 unlike the AXP209.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> Acked-by: Rob Herring <robh@kernel.org>
[...]
> static int axp20x_pctl_probe(struct platform_device *pdev)
> {
> struct axp20x_dev *axp20x = dev_get_drvdata(pdev->dev.parent);
> struct axp20x_pctl *pctl;
> + struct device *dev = &pdev->dev;
> struct pinctrl_desc *pctrl_desc;
> int ret;
>
> @@ -388,9 +413,9 @@ static int axp20x_pctl_probe(struct platform_device *pdev)
> pctl->chip.set = axp20x_gpio_set;
> pctl->chip.direction_input = axp20x_gpio_input;
> pctl->chip.direction_output = axp20x_gpio_output;
> - pctl->chip.ngpio = 3;
> + pctl->chip.ngpio = pctl->desc->npins;
>
> - pctl->desc = &axp20x_data;
> + pctl->desc = (struct axp20x_pctrl_desc *)of_device_get_match_data(dev);
> pctl->regmap = axp20x->regmap;
> pctl->dev = &pdev->dev;
>
I am using pctl->desc before retrieving it, thus dereferencing from a
null pointer.
We just have to move
pctl->chip.ngpio = pctl->desc->npins;
after
pctl->desc = (struct axp20x_pctrl_desc *)of_device_get_match_data(dev);
Linus, I guess that I should send a patch to fix this or is there an
other way not to have to apply such a small and dumb patch?
Quentin
--
Quentin Schulz, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH] i2c: Include GPIO consumer header in main include
From: Linus Walleij @ 2017-12-08 13:39 UTC (permalink / raw)
To: linux-arm-kernel
It seems most users of <linux/i2c.h> pick up their
dependency of <linux/gpio/consumer.h> from other paths but
that is not a universal law, so include the header
explicitly so we have struct gpio_desc available.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
include/linux/i2c.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index 5d7f3c1853ae..8b968c44ddfa 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -34,6 +34,7 @@
#include <linux/irqdomain.h> /* for Host Notify IRQ */
#include <linux/of.h> /* for struct device_node */
#include <linux/swab.h> /* for swab16 */
+#include <linux/gpio/consumer.h>
#include <uapi/linux/i2c.h>
extern struct bus_type i2c_bus_type;
--
2.14.3
^ permalink raw reply related
* [PATCH] i2c: imx: Include the right GPIO header
From: Linus Walleij @ 2017-12-08 13:35 UTC (permalink / raw)
To: linux-arm-kernel
<linux/of_gpio.h> is not used in this file, by
<linux/gpio/consumer.h> is.
Someone is just lucky with their implicit includes.
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/i2c/busses/i2c-imx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
index c4cf26571b66..e54a2516c036 100644
--- a/drivers/i2c/busses/i2c-imx.c
+++ b/drivers/i2c/busses/i2c-imx.c
@@ -37,6 +37,7 @@
#include <linux/dmapool.h>
#include <linux/err.h>
#include <linux/errno.h>
+#include <linux/gpio/consumer.h>
#include <linux/i2c.h>
#include <linux/init.h>
#include <linux/interrupt.h>
@@ -46,7 +47,6 @@
#include <linux/of.h>
#include <linux/of_device.h>
#include <linux/of_dma.h>
-#include <linux/of_gpio.h>
#include <linux/pinctrl/consumer.h>
#include <linux/platform_data/i2c-imx.h>
#include <linux/platform_device.h>
--
2.14.3
^ permalink raw reply related
* [PATCH] i2c/ARM: davinci: Deep refactoring of I2C recovery
From: Linus Walleij @ 2017-12-08 13:31 UTC (permalink / raw)
To: linux-arm-kernel
Alter the DaVinci GPIO recovery fetch to use descriptors
all the way down into the board files.
Cc: arm at kernel.org
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Kevin Hilman <khilman@kernel.org>
Cc: Keerthy <j-keerthy@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
It turns out someone else was busy doing the same thing I was
doing. Trying to carry over the useful part with this patch!
A Tested-by or ACK from a DaVinci maintainer would be
appreciated, also an ACK from and ARM SoC maintainer.
The patch can be easily tested by applying on top of
linux-next.
---
arch/arm/mach-davinci/board-dm355-evm.c | 15 +++++++++++++--
arch/arm/mach-davinci/board-dm644x-evm.c | 15 +++++++++++++--
drivers/i2c/busses/i2c-davinci.c | 21 +++++++++++----------
include/linux/platform_data/i2c-davinci.h | 5 ++---
4 files changed, 39 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm355-evm.c b/arch/arm/mach-davinci/board-dm355-evm.c
index 62e7bc3018f0..60aec5437276 100644
--- a/arch/arm/mach-davinci/board-dm355-evm.c
+++ b/arch/arm/mach-davinci/board-dm355-evm.c
@@ -17,6 +17,7 @@
#include <linux/mtd/rawnand.h>
#include <linux/i2c.h>
#include <linux/gpio.h>
+#include <linux/gpio/machine.h>
#include <linux/clk.h>
#include <linux/videodev2.h>
#include <media/i2c/tvp514x.h>
@@ -108,11 +109,20 @@ static struct platform_device davinci_nand_device = {
},
};
+static struct gpiod_lookup_table i2c_recovery_gpiod_table = {
+ .dev_id = "i2c_davinci",
+ .table = {
+ GPIO_LOOKUP("davinci_gpio.0", 15, "sda",
+ GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN),
+ GPIO_LOOKUP("davinci_gpio.0", 14, "scl",
+ GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN),
+ },
+};
+
static struct davinci_i2c_platform_data i2c_pdata = {
.bus_freq = 400 /* kHz */,
.bus_delay = 0 /* usec */,
- .sda_pin = 15,
- .scl_pin = 14,
+ .gpio_recovery = true,
};
static int dm355evm_mmc_gpios = -EINVAL;
@@ -141,6 +151,7 @@ static struct i2c_board_info dm355evm_i2c_info[] = {
static void __init evm_init_i2c(void)
{
+ gpiod_add_lookup_table(&i2c_recovery_gpiod_table);
davinci_init_i2c(&i2c_pdata);
gpio_request(5, "dm355evm_msp");
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c
index b07c9b18d427..2efc6dbc5ac0 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -13,6 +13,7 @@
#include <linux/dma-mapping.h>
#include <linux/platform_device.h>
#include <linux/gpio.h>
+#include <linux/gpio/machine.h>
#include <linux/i2c.h>
#include <linux/platform_data/pcf857x.h>
#include <linux/platform_data/at24.h>
@@ -595,18 +596,28 @@ static struct i2c_board_info __initdata i2c_info[] = {
},
};
+static struct gpiod_lookup_table i2c_recovery_gpiod_table = {
+ .dev_id = "i2c_davinci",
+ .table = {
+ GPIO_LOOKUP("davinci_gpio.0", 44, "sda",
+ GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN),
+ GPIO_LOOKUP("davinci_gpio.0", 43, "scl",
+ GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN),
+ },
+};
+
/* The msp430 uses a slow bitbanged I2C implementation (ergo 20 KHz),
* which requires 100 usec of idle bus after i2c writes sent to it.
*/
static struct davinci_i2c_platform_data i2c_pdata = {
.bus_freq = 20 /* kHz */,
.bus_delay = 100 /* usec */,
- .sda_pin = 44,
- .scl_pin = 43,
+ .gpio_recovery = true,
};
static void __init evm_init_i2c(void)
{
+ gpiod_add_lookup_table(&i2c_recovery_gpiod_table);
davinci_init_i2c(&i2c_pdata);
i2c_add_driver(&dm6446evm_msp_driver);
i2c_register_board_info(1, i2c_info, ARRAY_SIZE(i2c_info));
diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c
index 2afb12a89eb3..cb24a3ffdfa2 100644
--- a/drivers/i2c/busses/i2c-davinci.c
+++ b/drivers/i2c/busses/i2c-davinci.c
@@ -33,7 +33,7 @@
#include <linux/io.h>
#include <linux/slab.h>
#include <linux/cpufreq.h>
-#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
#include <linux/of_device.h>
#include <linux/platform_data/i2c-davinci.h>
#include <linux/pm_runtime.h>
@@ -869,19 +869,20 @@ static int davinci_i2c_probe(struct platform_device *pdev)
if (dev->pdata->has_pfunc)
adap->bus_recovery_info = &davinci_i2c_scl_recovery_info;
- else if (dev->pdata->scl_pin) {
+ else if (dev->pdata->gpio_recovery) {
rinfo = &davinci_i2c_gpio_recovery_info;
adap->bus_recovery_info = rinfo;
- r = gpio_request_one(dev->pdata->scl_pin, GPIOF_OPEN_DRAIN |
- GPIOF_OUT_INIT_HIGH, "i2c-scl");
- if (r)
+ rinfo->scl_gpiod = devm_gpiod_get(&pdev->dev, "scl",
+ GPIOD_OUT_HIGH_OPEN_DRAIN);
+ if (IS_ERR(rinfo->scl_gpiod)) {
+ r = PTR_ERR(rinfo->scl_gpiod);
goto err_unuse_clocks;
- rinfo->scl_gpiod = gpio_to_desc(dev->pdata->scl_pin);
-
- r = gpio_request_one(dev->pdata->sda_pin, GPIOF_IN, "i2c-sda");
- if (r)
+ }
+ rinfo->sda_gpiod = devm_gpiod_get(&pdev->dev, "sda", GPIOD_IN);
+ if (IS_ERR(rinfo->sda_gpiod)) {
+ r = PTR_ERR(rinfo->sda_gpiod);
goto err_unuse_clocks;
- rinfo->sda_gpiod = gpio_to_desc(dev->pdata->scl_pin);
+ }
}
adap->nr = pdev->id;
diff --git a/include/linux/platform_data/i2c-davinci.h b/include/linux/platform_data/i2c-davinci.h
index 89fd34727a24..98967df07468 100644
--- a/include/linux/platform_data/i2c-davinci.h
+++ b/include/linux/platform_data/i2c-davinci.h
@@ -16,9 +16,8 @@
struct davinci_i2c_platform_data {
unsigned int bus_freq; /* standard bus frequency (kHz) */
unsigned int bus_delay; /* post-transaction delay (usec) */
- unsigned int sda_pin; /* GPIO pin ID to use for SDA */
- unsigned int scl_pin; /* GPIO pin ID to use for SCL */
- bool has_pfunc; /*chip has a ICPFUNC register */
+ bool gpio_recovery; /* Use GPIO recovery method */
+ bool has_pfunc; /* Chip has a ICPFUNC register */
};
/* for board setup code */
--
2.14.3
^ permalink raw reply related
* next/master boot: 270 boots: 35 failed, 213 passed with 20 offline, 2 untried/unknown (next-20171207)
From: Marek Szyprowski @ 2017-12-08 13:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJKOXPcfgXTzacEYyPFV=UJYdKz9v86pEjbjaWJ_7BYhdNafqA@mail.gmail.com>
Hi Krzysztof,
On 2017-12-08 13:33, Krzysztof Kozlowski wrote:
> On Fri, Dec 8, 2017 at 1:27 PM, Mark Brown <broonie@kernel.org> wrote:
>> On Fri, Dec 08, 2017 at 12:20:07PM +0000, Mark Brown wrote:
>>> On Thu, Dec 07, 2017 at 03:54:47PM -0800, kernelci.org bot wrote:
>>>
>>> Today's -next failed to boot on peach-pi:
>>>
>>>> exynos_defconfig:
>>>> exynos5800-peach-pi:
>>>> lab-collabora: new failure (last pass: next-20171205)
>>> with details at https://kernelci.org/boot/id/5a2a2e7859b5141bc2afa17c/
>>> (including logs and comparisons with other boots, the last good boot was
>>> Wednesday). It looks like it hangs somewhere late on in boot, the last
>>> output on the console is:
>>>
>>> [ 4.827139] smsc95xx 3-1.1:1.0 eth0: register 'smsc95xx' at usb-xhci-hcd.3.auto-1.1, smsc95xx USB 2.0 Ethernet, 94:eb:2c:00:03:c0
>>> [ 5.781037] dma-pl330 3880000.adma: Loaded driver for PL330 DMAC-241330
>>> [ 5.786247] dma-pl330 3880000.adma: DBUFF-4x8bytes Num_Chans-6 Num_Peri-16 Num_Events-6
>>> [ 5.819200] dma-pl330 3880000.adma: PM domain MAU will not be powered off
>>> [ 64.529228] random: crng init done
>>>
>>> and there's failures earlier to instantiate the display.
>> I just noticed that further up the log there's a lockdep splat with a
>> conflict between the genpd and clock API locking - an ABBA issue with
>> genpd->mlock and the clock API prepare_lock.
> +Cc Marek Szyprowski,
>
> The lockdep issue and display failures (including regulator warning)
> were present for some time. They also appear in boot log for
> next-20171206 (https://storage.kernelci.org/next/master/next-20171206/arm/exynos_defconfig/lab-collabora/boot-exynos5800-peach-pi.html).
> The difference is that 20171208 hangs on "random: crng init done"
> which did not appear before at all.
"random: crng init done" happens about a minute after boot, so if board
boots correctly to system prompt before that time, there will be no such
message.
> The only recent changes in samsung-soc tree which could affect Exynos5800 is
> - ARM: dts: exynos: Add audio power domain support to Exynos542x SoCs
> https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git/commit/?h=next/dt&id=528832d4c01a2b400775df95fe8d363cf4c5230f
> - ARM: dts: exynos: Add CPU perf counters to Exynos54xx boards
> https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git/commit/?h=next/dt&id=c4f2fc00defc65950dfabce7a4c70cd2a289111d
>
> But both of them were present in next for few days so they should hit
> 20171206 as well.
>
> Maybe the issue comes from different subsystem?
The only change that has been recently merged and is related to the
hardware available on peach-pit is this patch:
https://www.spinics.net/lists/linux-samsung-soc/msg61232.html
It probably changed the order of driver initialization, but I have no
idea what causes the deadlock (from the "random:" message I see that
kernel is somehow still operational).
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* [Patch v6 02/12] [media] s5p-mfc: Adding initial support for MFC v10.10
From: Philippe Ombredanne @ 2017-12-08 13:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512724105-1778-3-git-send-email-smitha.t@samsung.com>
Smitha,
On Fri, Dec 8, 2017 at 10:08 AM, Smitha T Murthy <smitha.t@samsung.com> wrote:
> Adding the support for MFC v10.10, with new register file and
> necessary hw control, decoder, encoder and structural changes.
>
> CC: Rob Herring <robh+dt@kernel.org>
> CC: devicetree at vger.kernel.org
> Signed-off-by: Smitha T Murthy <smitha.t@samsung.com>
> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
> Acked-by: Rob Herring <robh@kernel.org>
[]
> --- /dev/null
> +++ b/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> @@ -0,0 +1,36 @@
> +/*
> + * Register definition file for Samsung MFC V10.x Interface (FIMV) driver
> + *
> + * Copyright (c) 2017 Samsung Electronics Co., Ltd.
> + * http://www.samsung.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.
> + */
Have you considered using the new SPDX ids instead of this fine legalese? e.g.:
// SPDX-License-Identifier: GPL-2.0
This is much shorter and neater (unless you are a legalese lover of
course!) Check also Thomas doc patches and Linus comments on why he
prefers the C++ comment style for these.
And even better could be this more compact form? I am a big fan of the
C++ style comments for these (and so is Linus)
// SPDX-License-Identifier: GPL-2.0
// Copyright (c) 2017 Samsung Electronics Co., Ltd.
// Register definition file for Samsung MFC V10.x Interface (FIMV) driver
You can also read this fine article from a fellow Samsung colleague
[1]. And if you ever consider doing this for all Samsung's past,
present and future contributions, you will have my deep gratitude
[1] https://blogs.s-osg.org/linux-kernel-license-practices-revisited-spdx/
--
Cordially
Philippe Ombredanne, your licensing helper elf
^ permalink raw reply
* [PATCH v8 2/2] media: i2c: Add the ov7740 image sensor driver
From: Philippe Ombredanne @ 2017-12-08 13:14 UTC (permalink / raw)
To: linux-arm-kernel
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 v4 09/12] clk: qcom: Add Krait clock controller driver
From: Philippe Ombredanne @ 2017-12-08 13:10 UTC (permalink / raw)
To: linux-arm-kernel
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
* [PATCH v9 3/6] clocksource: stm32: only use 32 bits timers
From: Benjamin Gaignard @ 2017-12-08 13:05 UTC (permalink / raw)
To: linux-arm-kernel
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
* [PATCH] i2c: core: Use GPIO descriptors for recovery
From: Linus Walleij @ 2017-12-08 13:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171208105010.xn6m4bl3hiaxhizq@ninjato>
On Fri, Dec 8, 2017 at 11:50 AM, Wolfram Sang <wsa@the-dreams.de> wrote:
> On Fri, Dec 08, 2017 at 11:20:02AM +0100, Linus Walleij wrote:
>> The I2C core contains code for handling a fallback recovery
>> using GPIO when a piece of I2C hardware fails in duty.
>>
>> This code passes GPIO numbers from the global GPIO
>> numberspace around and we want to get rid of this and use
>> GPIO descriptors associated with the devices.
>>
>> After some digging it turns out that there are two users
>> of the mechanism in the entire kernel:
>>
>> - i.MX that simply define "scl-gpios" and "sda-gpios" in
>> the device tree which is already creating descriptors
>> associated with the device, that we can pick up and use.
>>
>> - Two DaVinci boards that pass the SCL and SDA GPIOs using
>> custom platform data.
>>
>> Refactor the core to grab the SCL and SDA GPIO descriptors
>> on-demand when doing recovery, and release them when
>> recovery is done. Grab the named descriptors "scl" and
>> "sda" which will make the i.MX method work out of the
>> box.
>>
>> Augment the two DaVinci board files to pass descriptors
>> using static tables.
>>
>> Cc: Shawn Guo <shawnguo@kernel.org>
>> Cc: Sascha Hauer <kernel@pengutronix.de>
>> Cc: Fabio Estevam <fabio.estevam@nxp.com>
>> Cc: Sekhar Nori <nsekhar@ti.com>
>> Cc: Kevin Hilman <khilman@kernel.org>
>> Cc: Keerthy <j-keerthy@ti.com>
>> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>
> We have this in i2c/for-next:
>
> 3991c5c80beaf7 ("i2c: Switch to using gpiod interface for gpio bus recovery")
>
> Sorry, I just noticed you were not on CC. I wrongly remembered you took
> part in that discussion, too.
Haha OK no problem, I'll go review the other patch.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v9 3/6] clocksource: stm32: only use 32 bits timers
From: Daniel Lezcano @ 2017-12-08 12:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171208113250.359-4-benjamin.gaignard@st.com>
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 ?
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
^ permalink raw reply
* [PATCH] media: v4l: xilinx: Use SPDX-License-Identifier
From: Dhaval Shah @ 2017-12-08 12:35 UTC (permalink / raw)
To: linux-arm-kernel
SPDX-License-Identifier is used for the Xilinx Video IP and
related drivers.
Signed-off-by: Dhaval Shah <dhaval23031987@gmail.com>
---
drivers/media/platform/xilinx/xilinx-dma.c | 5 +----
drivers/media/platform/xilinx/xilinx-dma.h | 5 +----
drivers/media/platform/xilinx/xilinx-tpg.c | 5 +----
drivers/media/platform/xilinx/xilinx-vip.c | 5 +----
drivers/media/platform/xilinx/xilinx-vip.h | 5 +----
drivers/media/platform/xilinx/xilinx-vipp.c | 5 +----
drivers/media/platform/xilinx/xilinx-vipp.h | 5 +----
drivers/media/platform/xilinx/xilinx-vtc.c | 5 +----
drivers/media/platform/xilinx/xilinx-vtc.h | 5 +----
9 files changed, 9 insertions(+), 36 deletions(-)
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.
*/
#include <linux/dma/xilinx_dma.h>
diff --git a/drivers/media/platform/xilinx/xilinx-dma.h b/drivers/media/platform/xilinx/xilinx-dma.h
index e95d136c153a..5aec4d17eb21 100644
--- a/drivers/media/platform/xilinx/xilinx-dma.h
+++ b/drivers/media/platform/xilinx/xilinx-dma.h
@@ -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.
*/
#ifndef __XILINX_VIP_DMA_H__
diff --git a/drivers/media/platform/xilinx/xilinx-tpg.c b/drivers/media/platform/xilinx/xilinx-tpg.c
index 9c49d1d10bee..20a68a65602b 100644
--- a/drivers/media/platform/xilinx/xilinx-tpg.c
+++ b/drivers/media/platform/xilinx/xilinx-tpg.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* Xilinx Test Pattern Generator
*
@@ -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.
*/
#include <linux/device.h>
diff --git a/drivers/media/platform/xilinx/xilinx-vip.c b/drivers/media/platform/xilinx/xilinx-vip.c
index 311259129504..5f7efa9f093e 100644
--- a/drivers/media/platform/xilinx/xilinx-vip.c
+++ b/drivers/media/platform/xilinx/xilinx-vip.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* Xilinx Video IP Core
*
@@ -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.
*/
#include <linux/clk.h>
diff --git a/drivers/media/platform/xilinx/xilinx-vip.h b/drivers/media/platform/xilinx/xilinx-vip.h
index 42fee2026815..ba939dd52818 100644
--- a/drivers/media/platform/xilinx/xilinx-vip.h
+++ b/drivers/media/platform/xilinx/xilinx-vip.h
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* Xilinx Video IP Core
*
@@ -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.
*/
#ifndef __XILINX_VIP_H__
diff --git a/drivers/media/platform/xilinx/xilinx-vipp.c b/drivers/media/platform/xilinx/xilinx-vipp.c
index d881cf09876d..cb9ab2c15952 100644
--- a/drivers/media/platform/xilinx/xilinx-vipp.c
+++ b/drivers/media/platform/xilinx/xilinx-vipp.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* Xilinx Video IP Composite Device
*
@@ -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.
*/
#include <linux/list.h>
diff --git a/drivers/media/platform/xilinx/xilinx-vipp.h b/drivers/media/platform/xilinx/xilinx-vipp.h
index faf6b6e80b3b..39daa030679e 100644
--- a/drivers/media/platform/xilinx/xilinx-vipp.h
+++ b/drivers/media/platform/xilinx/xilinx-vipp.h
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* Xilinx Video IP Composite Device
*
@@ -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.
*/
#ifndef __XILINX_VIPP_H__
diff --git a/drivers/media/platform/xilinx/xilinx-vtc.c b/drivers/media/platform/xilinx/xilinx-vtc.c
index 01c750edcac5..0ae0208d7529 100644
--- a/drivers/media/platform/xilinx/xilinx-vtc.c
+++ b/drivers/media/platform/xilinx/xilinx-vtc.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* Xilinx Video Timing Controller
*
@@ -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.
*/
#include <linux/clk.h>
diff --git a/drivers/media/platform/xilinx/xilinx-vtc.h b/drivers/media/platform/xilinx/xilinx-vtc.h
index e1bb2cfcf428..90cf44245283 100644
--- a/drivers/media/platform/xilinx/xilinx-vtc.h
+++ b/drivers/media/platform/xilinx/xilinx-vtc.h
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* Xilinx Video Timing Controller
*
@@ -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.
*/
#ifndef __XILINX_VTC_H__
--
2.11.0
^ permalink raw reply related
* next/master boot: 270 boots: 35 failed, 213 passed with 20 offline, 2 untried/unknown (next-20171207)
From: Krzysztof Kozlowski @ 2017-12-08 12:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171208122703.GC7606@sirena.org.uk>
On Fri, Dec 8, 2017 at 1:27 PM, Mark Brown <broonie@kernel.org> wrote:
> On Fri, Dec 08, 2017 at 12:20:07PM +0000, Mark Brown wrote:
>> On Thu, Dec 07, 2017 at 03:54:47PM -0800, kernelci.org bot wrote:
>>
>> Today's -next failed to boot on peach-pi:
>>
>> > exynos_defconfig:
>> > exynos5800-peach-pi:
>> > lab-collabora: new failure (last pass: next-20171205)
>>
>> with details at https://kernelci.org/boot/id/5a2a2e7859b5141bc2afa17c/
>> (including logs and comparisons with other boots, the last good boot was
>> Wednesday). It looks like it hangs somewhere late on in boot, the last
>> output on the console is:
>>
>> [ 4.827139] smsc95xx 3-1.1:1.0 eth0: register 'smsc95xx' at usb-xhci-hcd.3.auto-1.1, smsc95xx USB 2.0 Ethernet, 94:eb:2c:00:03:c0
>> [ 5.781037] dma-pl330 3880000.adma: Loaded driver for PL330 DMAC-241330
>> [ 5.786247] dma-pl330 3880000.adma: DBUFF-4x8bytes Num_Chans-6 Num_Peri-16 Num_Events-6
>> [ 5.819200] dma-pl330 3880000.adma: PM domain MAU will not be powered off
>> [ 64.529228] random: crng init done
>>
>> and there's failures earlier to instantiate the display.
>
> I just noticed that further up the log there's a lockdep splat with a
> conflict between the genpd and clock API locking - an ABBA issue with
> genpd->mlock and the clock API prepare_lock.
+Cc Marek Szyprowski,
The lockdep issue and display failures (including regulator warning)
were present for some time. They also appear in boot log for
next-20171206 (https://storage.kernelci.org/next/master/next-20171206/arm/exynos_defconfig/lab-collabora/boot-exynos5800-peach-pi.html).
The difference is that 20171208 hangs on "random: crng init done"
which did not appear before at all.
The only recent changes in samsung-soc tree which could affect Exynos5800 is
- ARM: dts: exynos: Add audio power domain support to Exynos542x SoCs
https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git/commit/?h=next/dt&id=528832d4c01a2b400775df95fe8d363cf4c5230f
- ARM: dts: exynos: Add CPU perf counters to Exynos54xx boards
https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git/commit/?h=next/dt&id=c4f2fc00defc65950dfabce7a4c70cd2a289111d
But both of them were present in next for few days so they should hit
20171206 as well.
Maybe the issue comes from different subsystem?
Best regards,
Krzysztof
^ permalink raw reply
* [RFC PATCH 2/5] perf jevents: add support for arch recommended events
From: Jiri Olsa @ 2017-12-08 12:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f58001e9-86fa-c6e6-b9c7-fb748d340da1@huawei.com>
On Wed, Dec 06, 2017 at 02:40:10PM +0000, John Garry wrote:
> On 06/12/2017 13:37, Jiri Olsa wrote:
> > On Wed, Dec 06, 2017 at 12:13:16AM +0800, John Garry wrote:
> >
> > SNIP
> >
> > > ---
> > > tools/perf/pmu-events/jevents.c | 215 ++++++++++++++++++++++++++++++++++++----
> > > 1 file changed, 198 insertions(+), 17 deletions(-)
> > >
> > > diff --git a/tools/perf/pmu-events/jevents.c b/tools/perf/pmu-events/jevents.c
> > > index a0d489e..a820ed4 100644
> > > --- a/tools/perf/pmu-events/jevents.c
> > > +++ b/tools/perf/pmu-events/jevents.c
> > > @@ -42,6 +42,7 @@
> > > #include <dirent.h>
> > > #include <sys/time.h> /* getrlimit */
> > > #include <sys/resource.h> /* getrlimit */
> > > +#include <sys/queue.h>
> > > #include <ftw.h>
> > > #include <sys/stat.h>
> > > #include "jsmn.h"
> > > @@ -366,6 +367,94 @@ static int print_events_table_entry(void *data, char *name, char *event,
> > > return 0;
> > > }
> > >
> > > +struct event_struct {
> > > + char *name;
> > > + char *event;
> > > + char *desc;
> > > + char *long_desc;
> > > + char *pmu;
> > > + char *unit;
> > > + char *perpkg;
> > > + char *metric_expr;
> > > + char *metric_name;
> > > + char *metric_group;
> > > + LIST_ENTRY(event_struct) list;
> >
> > is there any reason you don't use the 'struct list_head' ?
> > I dont think we want another thingie involved for lists
>
> Hi jirka,
>
> The linux kernel headers are not used for jevents tool. I would rather use
> them if possible...
should be as easy as adding #include <linux/list.h> ;-)
it's heavily used within perf and I'm pretty sure we want
to keep around just one way of doing lists
thanks,
jirka
^ permalink raw reply
* [RFC PATCH 2/5] perf jevents: add support for arch recommended events
From: Jiri Olsa @ 2017-12-08 12:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c46d07bc-a6f0-1b01-0595-a615781f8cff@huawei.com>
On Wed, Dec 06, 2017 at 03:20:14PM +0000, John Garry wrote:
> On 06/12/2017 13:36, Jiri Olsa wrote:
> > On Wed, Dec 06, 2017 at 12:13:16AM +0800, John Garry wrote:
> > > For some architectures (like arm64), there are architecture-
> > > defined recommended events. Vendors may not be obliged to
> > > follow the recommendation and may implement their own pmu
> > > event for a specific event code.
> > >
> > > This patch adds support for parsing events from arch-defined
> > > recommended JSONs, and then fixing up vendor events when
> > > they have implemented these events as recommended.
> >
> > in the previous patch you added the vendor support, so
> > you have arch|vendor|platform key for the event list
> > and perf have the most current/local event list
> >
> > why would you need to fix it? if there's new event list,
> > the table gets updated, perf is rebuilt.. I'm clearly
> > missing something ;-)
>
> The 2 patches are quite separate. In the first patch, I just added support
> for the vendor subdirectory.
>
> So this patch is not related to rebuilding when adding a new event list or
> dependency checking.
>
> Here we are trying to allow the vendor to just specify that an event is
> supported as standard in their platform, without duplicating all the
> standard event fields in their JSON. When processing the vendor JSONs, the
> jevents tool can figure which events are standard and create the proper
> event entries in the pmu events table, referencing the architecture JSON.
I think we should keep this simple and mangle this with some pointer logic
now you have arch/vendor/platform directory structure.. why don't
you add events for every such directory? I understand there will
be duplications, but we already have them for other archs and it's
not big deal:
[jolsa at krava perf]$ grep -r L2_RQSTS.DEMAND_DATA_RD_MISS pmu-events/arch/*
pmu-events/arch/x86/broadwell/cache.json: "EventName": "L2_RQSTS.DEMAND_DATA_RD_MISS",
pmu-events/arch/x86/haswell/cache.json: "EventName": "L2_RQSTS.DEMAND_DATA_RD_MISS",
pmu-events/arch/x86/broadwellde/cache.json: "EventName": "L2_RQSTS.DEMAND_DATA_RD_MISS",
pmu-events/arch/x86/haswellx/cache.json: "EventName": "L2_RQSTS.DEMAND_DATA_RD_MISS",
pmu-events/arch/x86/skylake/cache.json: "EventName": "L2_RQSTS.DEMAND_DATA_RD_MISS",
pmu-events/arch/x86/skylakex/cache.json: "EventName": "L2_RQSTS.DEMAND_DATA_RD_MISS",
pmu-events/arch/x86/broadwellx/cache.json: "EventName": "L2_RQSTS.DEMAND_DATA_RD_MISS",
thanks,
jirka
^ permalink raw reply
* next/master boot: 270 boots: 35 failed, 213 passed with 20 offline, 2 untried/unknown (next-20171207)
From: Mark Brown @ 2017-12-08 12:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171208122007.GB7606@sirena.org.uk>
On Fri, Dec 08, 2017 at 12:20:07PM +0000, Mark Brown wrote:
> On Thu, Dec 07, 2017 at 03:54:47PM -0800, kernelci.org bot wrote:
>
> Today's -next failed to boot on peach-pi:
>
> > exynos_defconfig:
> > exynos5800-peach-pi:
> > lab-collabora: new failure (last pass: next-20171205)
>
> with details at https://kernelci.org/boot/id/5a2a2e7859b5141bc2afa17c/
> (including logs and comparisons with other boots, the last good boot was
> Wednesday). It looks like it hangs somewhere late on in boot, the last
> output on the console is:
>
> [ 4.827139] smsc95xx 3-1.1:1.0 eth0: register 'smsc95xx' at usb-xhci-hcd.3.auto-1.1, smsc95xx USB 2.0 Ethernet, 94:eb:2c:00:03:c0
> [ 5.781037] dma-pl330 3880000.adma: Loaded driver for PL330 DMAC-241330
> [ 5.786247] dma-pl330 3880000.adma: DBUFF-4x8bytes Num_Chans-6 Num_Peri-16 Num_Events-6
> [ 5.819200] dma-pl330 3880000.adma: PM domain MAU will not be powered off
> [ 64.529228] random: crng init done
>
> and there's failures earlier to instantiate the display.
I just noticed that further up the log there's a lockdep splat with a
conflict between the genpd and clock API locking - an ABBA issue with
genpd->mlock and the clock API prepare_lock.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171208/8ebfabce/attachment.sig>
^ permalink raw reply
* next/master boot: 270 boots: 35 failed, 213 passed with 20 offline, 2 untried/unknown (next-20171207)
From: Mark Brown @ 2017-12-08 12:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5a29d4c7.4fabdf0a.716d7.8485@mx.google.com>
On Thu, Dec 07, 2017 at 03:54:47PM -0800, kernelci.org bot wrote:
Today's -next failed to boot on peach-pi:
> exynos_defconfig:
> exynos5800-peach-pi:
> lab-collabora: new failure (last pass: next-20171205)
with details at https://kernelci.org/boot/id/5a2a2e7859b5141bc2afa17c/
(including logs and comparisons with other boots, the last good boot was
Wednesday). It looks like it hangs somewhere late on in boot, the last
output on the console is:
[ 4.827139] smsc95xx 3-1.1:1.0 eth0: register 'smsc95xx' at usb-xhci-hcd.3.auto-1.1, smsc95xx USB 2.0 Ethernet, 94:eb:2c:00:03:c0
[ 5.781037] dma-pl330 3880000.adma: Loaded driver for PL330 DMAC-241330
[ 5.786247] dma-pl330 3880000.adma: DBUFF-4x8bytes Num_Chans-6 Num_Peri-16 Num_Events-6
[ 5.819200] dma-pl330 3880000.adma: PM domain MAU will not be powered off
[ 64.529228] random: crng init done
and there's failures earlier to instantiate the display.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171208/f8b32c38/attachment.sig>
^ permalink raw reply
* [PATCH] clkc: zynq: Missing a blank line after declarations.
From: Dhaval Shah @ 2017-12-08 12:15 UTC (permalink / raw)
To: linux-arm-kernel
Resolved missing a blank line after declarations checkpatch
warnings. Issue found by checkpatch.
Signed-off-by: Dhaval Shah <dhaval23031987@gmail.com>
---
drivers/clk/zynq/clkc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/zynq/clkc.c b/drivers/clk/zynq/clkc.c
index 88a2cab37f62..1cd4705e405e 100644
--- a/drivers/clk/zynq/clkc.c
+++ b/drivers/clk/zynq/clkc.c
@@ -363,6 +363,7 @@ static void __init zynq_clk_setup(struct device_node *np)
/* Peripheral clocks */
for (i = fclk0; i <= fclk3; i++) {
int enable = !!(fclk_enable & BIT(i - fclk0));
+
zynq_clk_register_fclk(i, clk_output_name[i],
SLCR_FPGA0_CLK_CTRL + 0x10 * (i - fclk0),
periph_parents, enable);
--
2.11.0
^ permalink raw reply related
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