Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v1] watchdog: imx2: fix hang-up on boot for i.MX21, i.MX27 and i.MX31 SoCs
From: Guenter Roeck @ 2016-12-23  1:55 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <2fc2558d-fe05-14a7-745e-f71d2178bad6@mleia.com>

On 12/11/2016 03:21 AM, Vladimir Zapolskiy wrote:
> On 12/11/2016 12:26 PM, Uwe Kleine-K?nig wrote:
>> Hello Vladimir,
>>
>> On Sun, Dec 11, 2016 at 12:01:08PM +0200, Vladimir Zapolskiy wrote:
>>> On 12/11/2016 11:35 AM, Uwe Kleine-K?nig wrote:
>>>> On Sun, Dec 11, 2016 at 03:06:48AM +0200, Vladimir Zapolskiy wrote:
>>>>> Power down counter enable/disable bit switch is located in WMCR
>>>>> register, but watchdog controllers found on legacy i.MX21, i.MX27 and
>>>>> i.MX31 SoCs don't have this register. As a result of writing data to
>>>>> the non-existing register on driver probe the SoC hangs up, to fix the
>>>>> problem add more OF compatible strings and on this basis get
>>>>> information about availability of the WMCR register.
>>>>>
>>>>> Fixes: 5fe65ce7ccbb ("watchdog: imx2_wdt: Disable power down counter on boot")
>>>>> Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
>>>>> ---
>>>


What is the ultimate conclusion of this exchange ?

Are we going to get another version of the patch, or did everyone agree that
the patch is good as it is and does not require further changes ?

Guenter

>>> [snip]
>>>
>>>>>
>>>>>  static const struct of_device_id imx2_wdt_dt_ids[] = {
>>>>> -	{ .compatible = "fsl,imx21-wdt", },
>>>>> +	{ .compatible = "fsl,imx21-wdt", .data = IMX2_WDT_NO_WMCR },
>>>>> +	{ .compatible = "fsl,imx25-wdt",  },
>>>>> +	{ .compatible = "fsl,imx27-wdt", .data = IMX2_WDT_NO_WMCR },
>>>>> +	{ .compatible = "fsl,imx31-wdt", .data = IMX2_WDT_NO_WMCR },
>>>>> +	{ .compatible = "fsl,imx35-wdt",  },
>>>>> +	{ .compatible = "fsl,imx50-wdt",  },
>>>>> +	{ .compatible = "fsl,imx51-wdt",  },
>>>>> +	{ .compatible = "fsl,imx53-wdt",  },
>>>>> +	{ .compatible = "fsl,imx6q-wdt",  },
>>>>> +	{ .compatible = "fsl,imx6sl-wdt", },
>>>>> +	{ .compatible = "fsl,imx6sx-wdt", },
>>>>> +	{ .compatible = "fsl,imx6ul-wdt", },
>>>>> +	{ .compatible = "fsl,imx7d-wdt",  },
>>>>> +	{ .compatible = "fsl,vf610-wdt",  },
>>>>
>>>> Up to now we only had fsl,imx21-wdt, now it seems that iMX31, i.MX27 and
>>>> i.MX21 form a group of equal watchdog IPs and the others form another
>>>> group, right?
>>>>
>>>> So conceptually we should differenciate between
>>>>
>>>> 	fsl,imx21-wdt (which is used on i.MX21, i.MX27 and i.MX31)
>>>> 	fsl,imx35-wdt (which is used on all others)
>>>>
>>>
>>> The problem is that "fsl,imx35-wdt" is not used on all others in the
>>> existing DTS, i.e. in the old firmware, which shall be compatible with
>>> new changes.
>>
>> So old i.MX53 has
>>
>> 	compatible = "fsl,imx53-wdt", "fsl,imx21-wdt";
>>
>> . With the change to the driver it's like using the watchdog driver in
>> it's pre-5fe65ce7ccbb4-state on it. If this is bad, we must indeed make
>> fsl,imx53-wdt known to the driver. If not, just adding a single new
>> compatible to the driver is just fine.
>
> The change under discussion preserves the current runtime behaviour for
> i.MX53 and its friends, the watchdog power down counter in WMCR is
> disabled on boot (you may want to confirm it by testing though), another
> question is if it is wanted for e.g. i.MX53 right from the beginning.
>
> To keep the runtime compatibility of a newer kernel with old DTBs such
> a long list of device compatibles has to be inserted.
>
>>
>> If you want to call it imx25 or imx35 doesn't matter much. The reason I
>> picked imx35 is that this one was already picked before for cspi. This
>> suggests that i.MX35 is older than i.MX25 and so this is the canonical
>> choice.
>
> Accepted, from the Wikipedia both i.MX25 and i.MX35 are released in 2009,
> which one is the first I don't know for sure, I supposed it could be
> i.MX25 as a SoC with a weaker core.
>
>>
>>> $ grep -H 'fsl,imx.*-wdt' arch/arm/boot/dts/*.dtsi
>>> arch/arm/boot/dts/imx25.dtsi:				compatible = "fsl,imx25-wdt", "fsl,imx21-wdt";
>>> arch/arm/boot/dts/imx27.dtsi:				compatible = "fsl,imx27-wdt", "fsl,imx21-wdt";
>>> arch/arm/boot/dts/imx35.dtsi:				compatible = "fsl,imx35-wdt", "fsl,imx21-wdt";
>>> arch/arm/boot/dts/imx50.dtsi:				compatible = "fsl,imx50-wdt", "fsl,imx21-wdt";
>>> arch/arm/boot/dts/imx51.dtsi:				compatible = "fsl,imx51-wdt", "fsl,imx21-wdt";
>>> arch/arm/boot/dts/imx51.dtsi:				compatible = "fsl,imx51-wdt", "fsl,imx21-wdt";
>>> arch/arm/boot/dts/imx53.dtsi:				compatible = "fsl,imx53-wdt", "fsl,imx21-wdt";
>>> arch/arm/boot/dts/imx53.dtsi:				compatible = "fsl,imx53-wdt", "fsl,imx21-wdt";
>>> arch/arm/boot/dts/imx6qdl.dtsi:				compatible = "fsl,imx6q-wdt", "fsl,imx21-wdt";
>>> arch/arm/boot/dts/imx6qdl.dtsi:				compatible = "fsl,imx6q-wdt", "fsl,imx21-wdt";
>>> arch/arm/boot/dts/imx6sl.dtsi:				compatible = "fsl,imx6sl-wdt", "fsl,imx21-wdt";
>>> arch/arm/boot/dts/imx6sl.dtsi:				compatible = "fsl,imx6sl-wdt", "fsl,imx21-wdt";
>>> arch/arm/boot/dts/imx6sx.dtsi:				compatible = "fsl,imx6sx-wdt", "fsl,imx21-wdt";
>>> arch/arm/boot/dts/imx6sx.dtsi:				compatible = "fsl,imx6sx-wdt", "fsl,imx21-wdt";
>>> arch/arm/boot/dts/imx6sx.dtsi:				compatible = "fsl,imx6sx-wdt", "fsl,imx21-wdt";
>>> arch/arm/boot/dts/imx6ul.dtsi:				compatible = "fsl,imx6ul-wdt", "fsl,imx21-wdt";
>>> arch/arm/boot/dts/imx6ul.dtsi:				compatible = "fsl,imx6ul-wdt", "fsl,imx21-wdt";
>>> arch/arm/boot/dts/imx7s.dtsi:				compatible = "fsl,imx7d-wdt", "fsl,imx21-wdt";
>>> arch/arm/boot/dts/imx7s.dtsi:				compatible = "fsl,imx7d-wdt", "fsl,imx21-wdt";
>>> arch/arm/boot/dts/imx7s.dtsi:				compatible = "fsl,imx7d-wdt", "fsl,imx21-wdt";
>>> arch/arm/boot/dts/imx7s.dtsi:				compatible = "fsl,imx7d-wdt", "fsl,imx21-wdt";
>>> arch/arm/boot/dts/ls1021a.dtsi:			compatible = "fsl,imx21-wdt";
>>> arch/arm/boot/dts/vfxxx.dtsi:				compatible = "fsl,vf610-wdt", "fsl,imx21-wdt";
>>>
>>> I don't see a confirmation of the fact that "fsl,imx35-wdt" is the best
>>> selection, hence definitely "fsl,imx25-wdt" overscores it.
>>
>> I stated my reason to pick imx35 over imx25 above. Why do yo prefer
>> imx25?
>
> As you said right now and until it is added into DTS files "fsl,imx25-wdt" and
> "fsl,imx35-wdt" are equal as a compatible representation of WMCR-aware watchdogs.
>
> I may be wrong, if I assume that i.MX25 is released before i.MX35 (looks like
> they are released in parallel), but "imx25" precedes in alphanumerically sorted
> list of SoC names.
>
>>>> A reason to add e.g. fsl,imx6sl-wdt is that dtbs in the wild use
>>>>
>>>> 	"fsl,imx6sl-wdt", "fsl,imx21-wdt"
>>>>
>>>> . But then I wonder if
>>>>
>>>> 	5fe65ce7ccbb ("watchdog: imx2_wdt: Disable power down counter on boot")
>>>>
>>>> is that important to justify to add these all.
>>>
>>> About this comment I don't know, you may have better insight about the original
>>> change. By the way, in barebox you may want to fix the same hang-up, because
>>> you touch WMCR unconditionally.
>>
>> Sure.
>>
>>>> Independant of this I'd like to have all dtsi for the newer SoCs changed
>>>> to get
>>>>
>>>> 	"fsl,imx6sl-wdt", "fsl,imx35-wdt"
>>>>
>>>> and if you really want to add all these compatibles, add a comment that
>>>> these are really fsl,imx35-wdt and were added to work around broken
>>>> dtbs.
>>>
>>> No objections, but
>>>
>>> 1) I'd like to see "fsl,imx25-wdt" as a new common compatible, and that's
>>> what have been proposed and shared in RFC 2/2.
>>
>> Yeah, I missed that other patch (which was not part of this series).
>>
>>> 2) Please remind me, why do you ask to drop "fsl,imx21-wdt" from the list?
>>>
>>>      compatible = "fsl,imx6sx-wdt", "fsl,imx25-wdt", "fsl,imx21-wdt";
>>>
>>> The list of compatibles above is valid (from the most specific on the left
>>> to the most generic on the right), and that compatible property is rightly
>>> handled in the driver with this change applied. I don't see a need to
>>> drop "fsl,imx21-wdt".
>>
>> If the wdt in the i.MX6SX can be operated by the watchdog driver in it's
>> imx21 mode, you should keep the imx21 entry. If not, you shouldn't.
>
> The DTS description shall be rather independent from any particular software
> implementation, someone may want to reuse the same DTB in bootloaders and OS
> kernels of different versions. Assuming that I have a bootloader/kernel
> with a pure i.MX21 watchdog driver and run it on i.MX6SX, I'd prefer to match
> "fsl,imx21-wdt" compatible.
>
> --
> With best wishes,
> Vladimir
> --
> To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

^ permalink raw reply

* [PATCH 6/6] watchdog: ts4600: add driver for TS-4600 watchdog
From: Guenter Roeck @ 2016-12-23  1:53 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161214231237.17496-7-sebastien.bourdelin@savoirfairelinux.com>

On 12/14/2016 03:12 PM, Sebastien Bourdelin wrote:
> This watchdog is instantiated in a FPGA and can only be access using a
> GPIOs bit-banged bus, called the NBUS by Technologic Systems.
> The watchdog is made of only one register, called the feed register.
> Writing to this register will re-arm the watchdog for a given time (and
> enable it if it was disable). It can be disabled by writing a special
> value into it.
>
> Signed-off-by: Sebastien Bourdelin <sebastien.bourdelin@savoirfairelinux.com>
> ---
>  .../devicetree/bindings/watchdog/ts4600-wdt.txt    |  16 ++
>  arch/arm/boot/dts/imx28-ts4600-common.dtsi         |   5 +
>  drivers/watchdog/Kconfig                           |  10 +
>  drivers/watchdog/Makefile                          |   1 +
>  drivers/watchdog/ts4600_wdt.c                      | 213 +++++++++++++++++++++
>  5 files changed, 245 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/watchdog/ts4600-wdt.txt
>  create mode 100644 drivers/watchdog/ts4600_wdt.c
>
> diff --git a/Documentation/devicetree/bindings/watchdog/ts4600-wdt.txt b/Documentation/devicetree/bindings/watchdog/ts4600-wdt.txt
> new file mode 100644
> index 0000000..61d620e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/watchdog/ts4600-wdt.txt
> @@ -0,0 +1,16 @@
> +TS-4600 Technologic Systems Watchdog
> +
> +Required properties:
> +- compatible: must be "technologic,ts4600-wdt"
> +- reg: offset to the FPGA's watchdog register
> +
> +Optional property:
> +- timeout-sec: contains the watchdog timeout in seconds.
> +
> +Example:
> +
> +wdt {
> +	compatible = "technologic,ts4600-wdt";
> +	reg = <0x2a>;
> +	timeout-sec = <10>;
> +};
> diff --git a/arch/arm/boot/dts/imx28-ts4600-common.dtsi b/arch/arm/boot/dts/imx28-ts4600-common.dtsi
> index b668933..dd7318c 100644
> --- a/arch/arm/boot/dts/imx28-ts4600-common.dtsi
> +++ b/arch/arm/boot/dts/imx28-ts4600-common.dtsi
> @@ -116,6 +116,11 @@
>  		strobe-gpios = <&gpio0 25 GPIO_ACTIVE_HIGH>;
>  		ale-gpios    = <&gpio0 26 GPIO_ACTIVE_HIGH>;
>  		rdy-gpios    = <&gpio0 21 GPIO_ACTIVE_HIGH>;
> +
> +		wdt at 2a {
> +			compatible = "technologic,ts4600-wdt";
> +			reg = <0x2a>;
> +		};
>  	};
>
>  };
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index 3eb58cb..7a8e176 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -500,6 +500,16 @@ config NUC900_WATCHDOG
>  	  To compile this driver as a module, choose M here: the
>  	  module will be called nuc900_wdt.
>
> +config TS4600_WATCHDOG
> +	tristate "TS-4600 Watchdog"
> +	depends on HAS_IOMEM && OF
> +	depends on SOC_IMX28 || COMPILE_TEST

Asd 0day reports, this does not work.

> +	select WATCHDOG_CORE
> +	help
> +	  Technologic Systems TS-4600 has watchdog timer implemented in
> +	  an external FPGA. Say Y here if you want to support for the
> +	  watchdog timer on TS-4600 board.
> +
>  config TS4800_WATCHDOG
>  	tristate "TS-4800 Watchdog"
>  	depends on HAS_IOMEM && OF
> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> index caa9f4a..d4b4bd2 100644
> --- a/drivers/watchdog/Makefile
> +++ b/drivers/watchdog/Makefile
> @@ -61,6 +61,7 @@ obj-$(CONFIG_RN5T618_WATCHDOG) += rn5t618_wdt.o
>  obj-$(CONFIG_COH901327_WATCHDOG) += coh901327_wdt.o
>  obj-$(CONFIG_STMP3XXX_RTC_WATCHDOG) += stmp3xxx_rtc_wdt.o
>  obj-$(CONFIG_NUC900_WATCHDOG) += nuc900_wdt.o
> +obj-$(CONFIG_TS4600_WATCHDOG) += ts4600_wdt.o
>  obj-$(CONFIG_TS4800_WATCHDOG) += ts4800_wdt.o
>  obj-$(CONFIG_TS72XX_WATCHDOG) += ts72xx_wdt.o
>  obj-$(CONFIG_IMX2_WDT) += imx2_wdt.o
> diff --git a/drivers/watchdog/ts4600_wdt.c b/drivers/watchdog/ts4600_wdt.c
> new file mode 100644
> index 0000000..db91b40
> --- /dev/null
> +++ b/drivers/watchdog/ts4600_wdt.c
> @@ -0,0 +1,213 @@
> +/*
> + * Watchdog driver for TS-4600 based boards
> + *
> + * Copyright (c) 2016 - Savoir-faire Linux
> + * Author: Sebastien Bourdelin <sebastien.bourdelin@savoirfairelinux.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + *
> + * The watchdog on the TS-4600 based boards is in an FPGA and can only be
> + * accessed using a GPIO bit-banged bus called the NBUS by Technologic Systems.
> + * The logic for the watchdog is the same then for the TS-4800 SoM, only the way
> + * to access it change, therefore this driver is heavely based on the ts4800_wdt
> + * driver from Damien Riegel <damien.riegel@savoirfairelinux.com>.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/ts-nbus.h>
> +#include <linux/watchdog.h>
> +
> +static bool nowayout = WATCHDOG_NOWAYOUT;
> +module_param(nowayout, bool, 0);
> +MODULE_PARM_DESC(nowayout,
> +	"Watchdog cannot be stopped once started (default="
> +	__MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
> +
> +/* possible feed values */
> +#define TS4600_WDT_FEED_2S       0x1
> +#define TS4600_WDT_FEED_10S      0x2
> +#define TS4600_WDT_DISABLE       0x3
> +
> +struct ts4600_wdt {
> +	struct watchdog_device  wdd;
> +	u32                     feed_offset;
> +	u32                     feed_val;
> +};
> +
> +/*
> + * TS-4600 supports the following timeout values:
> + *
> + *   value desc
> + *   ---------------------
> + *     0    feed for 338ms
> + *     1    feed for 2.706s
> + *     2    feed for 10.824s
> + *     3    disable watchdog
> + *
> + * Keep the regmap/timeout map ordered by timeout
> + */
> +static const struct {
> +	const int timeout;
> +	const int regval;
> +} ts4600_wdt_map[] = {
> +	{ 2,  TS4600_WDT_FEED_2S },
> +	{ 10, TS4600_WDT_FEED_10S },
> +};
> +
> +#define MAX_TIMEOUT_INDEX       (ARRAY_SIZE(ts4600_wdt_map) - 1)
> +
> +static void ts4600_write_feed(struct ts4600_wdt *wdt, u32 val)
> +{
> +	ts_nbus_write(wdt->feed_offset, val);
> +}
> +
> +static int ts4600_wdt_start(struct watchdog_device *wdd)
> +{
> +	struct ts4600_wdt *wdt = watchdog_get_drvdata(wdd);
> +
> +	ts4600_write_feed(wdt, wdt->feed_val);
> +
> +	return 0;
> +}
> +
> +static int ts4600_wdt_stop(struct watchdog_device *wdd)
> +{
> +	struct ts4600_wdt *wdt = watchdog_get_drvdata(wdd);
> +
> +	ts4600_write_feed(wdt, TS4600_WDT_DISABLE);
> +	return 0;
> +}
> +
> +static int ts4600_wdt_set_timeout(struct watchdog_device *wdd,
> +				  unsigned int timeout)
> +{
> +	struct ts4600_wdt *wdt = watchdog_get_drvdata(wdd);
> +	int i;
> +
> +	for (i = 0; i < MAX_TIMEOUT_INDEX; i++) {
> +		if (ts4600_wdt_map[i].timeout >= timeout)
> +			break;
> +	}

An if/else would be much simpler here.

> +
> +	wdd->timeout = ts4600_wdt_map[i].timeout;
> +	wdt->feed_val = ts4600_wdt_map[i].regval;
> +
> +	return 0;
> +}
> +
> +static const struct watchdog_ops ts4600_wdt_ops = {
> +	.owner = THIS_MODULE,
> +	.start = ts4600_wdt_start,
> +	.stop = ts4600_wdt_stop,
> +	.set_timeout = ts4600_wdt_set_timeout,
> +};
> +
> +static const struct watchdog_info ts4600_wdt_info = {
> +	.options = WDIOF_SETTIMEOUT | WDIOF_MAGICCLOSE | WDIOF_KEEPALIVEPING,
> +	.identity = "TS-4600 Watchdog",
> +};
> +
> +static int ts4600_wdt_probe(struct platform_device *pdev)
> +{
> +	struct device_node *np = pdev->dev.of_node;
> +	struct watchdog_device *wdd;
> +	struct ts4600_wdt *wdt;
> +	u32 reg;
> +	int ret;
> +
> +	ret = of_property_read_u32(np, "reg", &reg);
> +	if (ret < 0) {
> +		dev_err(&pdev->dev, "missing reg property\n");
> +		return ret;
> +	}
> +
> +	/* check for the NBUS state and defer the probing if it is not ready */
> +	if (!ts_nbus_is_ready())
> +		return -EPROBE_DEFER;
> +
> +	/* allocate memory for watchdog struct */
> +	wdt = devm_kzalloc(&pdev->dev, sizeof(*wdt), GFP_KERNEL);
> +	if (!wdt)
> +		return -ENOMEM;
> +
> +	/* set offset to know where to write */
> +	wdt->feed_offset = reg;
> +
> +	/* Initialize struct watchdog_device */
> +	wdd = &wdt->wdd;
> +	wdd->parent = &pdev->dev;
> +	wdd->info = &ts4600_wdt_info;
> +	wdd->ops = &ts4600_wdt_ops;
> +	wdd->min_timeout = ts4600_wdt_map[0].timeout;
> +	wdd->max_timeout = ts4600_wdt_map[MAX_TIMEOUT_INDEX].timeout;
> +

Your call, but it might be better and more flexible to just use a single
hardware timeout (such as the 2.x second one), provide it here as
max_hw_heartbeat_ms, and let the kernel handle the actual (and larger)
timeouts.

> +	watchdog_set_drvdata(wdd, wdt);
> +	watchdog_set_nowayout(wdd, nowayout);
> +	watchdog_init_timeout(wdd, 0, &pdev->dev);
> +
> +	/*
> +	 * As this watchdog supports only a few values, ts4600_wdt_set_timeout
> +	 * must be called to initialize timeout and feed_val with valid values.
> +	 * Default to maximum timeout if none, or an invalid one, is provided in
> +	 * device tree.
> +	 */
> +	if (!wdd->timeout)
> +		wdd->timeout = wdd->max_timeout;
> +	ts4600_wdt_set_timeout(wdd, wdd->timeout);
> +
> +	/*
> +	 * The feed register is write-only, so it is not possible to determine
> +	 * watchdog's state. Disable it to be in a known state.
> +	 */
> +	ts4600_wdt_stop(wdd);
> +
> +	ret = watchdog_register_device(wdd);
> +	if (ret) {
> +		dev_err(&pdev->dev,
> +			"failed to register watchdog device\n");
> +		return ret;
> +	}
> +
> +	platform_set_drvdata(pdev, wdt);
> +
> +	dev_info(&pdev->dev,
> +		 "initialized (timeout = %d sec, nowayout = %d)\n",
> +		 wdd->timeout, nowayout);
> +
> +	return 0;
> +}
> +
> +static int ts4600_wdt_remove(struct platform_device *pdev)
> +{
> +	struct ts4600_wdt *wdt = platform_get_drvdata(pdev);
> +
> +	watchdog_unregister_device(&wdt->wdd);
> +
> +	return 0;
> +}
> +
> +static const struct of_device_id ts4600_wdt_of_match[] = {
> +	{ .compatible = "technologic,ts4600-wdt", },
> +	{ },
> +};
> +MODULE_DEVICE_TABLE(of, ts4600_wdt_of_match);
> +
> +static struct platform_driver ts4600_wdt_driver = {
> +	.probe		= ts4600_wdt_probe,
> +	.remove		= ts4600_wdt_remove,
> +	.driver		= {
> +		.name	= "ts4600_wdt",
> +		.of_match_table = ts4600_wdt_of_match,
> +	},
> +};
> +
> +module_platform_driver(ts4600_wdt_driver);
> +
> +MODULE_AUTHOR("Sebastien Bourdelin <sebastien.bourdelin@savoirfairelinux.com>");
> +MODULE_LICENSE("GPL v2");
> +MODULE_ALIAS("platform:ts4600_wdt");
>

^ permalink raw reply

* [PATCH V5 1/3] ARM64 LPC: Indirect ISA port IO introduced
From: zhichang.yuan @ 2016-12-23  1:43 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CACVXFVNS9n9_ty8y3CyqfRaLitqDKdk1mMOrQHM-enOgJtUBeQ@mail.gmail.com>

Hi?Ming,


On 2016/12/22 16:15, Ming Lei wrote:
> Hi Guys,
> 
> On Tue, Nov 8, 2016 at 11:47 AM, zhichang.yuan
> <yuanzhichang@hisilicon.com> wrote:
>> For arm64, there is no I/O space as other architectural platforms, such as
>> X86. Most I/O accesses are achieved based on MMIO. But for some arm64 SoCs,
>> such as Hip06, when accessing some legacy ISA devices connected to LPC, those
>> known port addresses are used to control the corresponding target devices, for
>> example, 0x2f8 is for UART, 0xe4 is for ipmi-bt. It is different from the
>> normal MMIO mode in using.
>>
>> To drive these devices, this patch introduces a method named indirect-IO.
>> In this method the in/out pair in arch/arm64/include/asm/io.h will be
>> redefined. When upper layer drivers call in/out with those known legacy port
>> addresses to access the peripherals, the hooking functions corrresponding to
>> those target peripherals will be called. Through this way, those upper layer
>> drivers which depend on in/out can run on Hip06 without any changes.
>>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Will Deacon <will.deacon@arm.com>
>> Signed-off-by: zhichang.yuan <yuanzhichang@hisilicon.com>
>> Signed-off-by: Gabriele Paoloni <gabriele.paoloni@huawei.com>
>> ---
>>  arch/arm64/Kconfig             |  6 +++
>>  arch/arm64/include/asm/extio.h | 94 ++++++++++++++++++++++++++++++++++++++++++
>>  arch/arm64/include/asm/io.h    | 29 +++++++++++++
>>  arch/arm64/kernel/Makefile     |  1 +
>>  arch/arm64/kernel/extio.c      | 27 ++++++++++++
>>  5 files changed, 157 insertions(+)
> 
> When I applied these three patches against current linus tree and
> enable CONFIG_HISILICON_LPC, the following build failure[1] is
> triggered when running 'make modules'.
> 

Thanks for your report!

This patch has compilation issue on some architectures, sorry for the inconvenience caused by this!
The ongoing v6 will solve these issues.
I will trace this failure and provide a fix if you can not wait for the next version.

Could you send me your .config in private? I don't want to bother all the hacker in the mail-list.


Thanks,
Zhichang

> 
> Thanks,
> Ming
> 
> [1] 'make modules' failure log
> 
>   Building modules, stage 2.
>   MODPOST 2260 modules
> ERROR: "inb" [drivers/watchdog/wdt_pci.ko] undefined!
> ERROR: "outb" [drivers/watchdog/wdt_pci.ko] undefined!
> ERROR: "outb" [drivers/watchdog/pcwd_pci.ko] undefined!
> ERROR: "inb" [drivers/watchdog/pcwd_pci.ko] undefined!
> ERROR: "outw" [drivers/video/vgastate.ko] undefined!
> ERROR: "outb" [drivers/video/vgastate.ko] undefined!
> ERROR: "inb" [drivers/video/vgastate.ko] undefined!
> ERROR: "outw" [drivers/video/fbdev/vt8623fb.ko] undefined!
> ERROR: "inb" [drivers/video/fbdev/vt8623fb.ko] undefined!
> ERROR: "outb" [drivers/video/fbdev/vt8623fb.ko] undefined!
> ERROR: "outw" [drivers/video/fbdev/tridentfb.ko] undefined!
> ERROR: "inb" [drivers/video/fbdev/tridentfb.ko] undefined!
> ERROR: "outb" [drivers/video/fbdev/tridentfb.ko] undefined!
> ERROR: "inb" [drivers/video/fbdev/tdfxfb.ko] undefined!
> .....
> ERROR: "inb" [drivers/ata/pata_cmd64x.ko] undefined!
> ERROR: "inb" [drivers/ata/pata_artop.ko] undefined!
> scripts/Makefile.modpost:91: recipe for target '__modpost' failed
> make[1]: *** [__modpost] Error 1
> Makefile:1196: recipe for target 'modules' failed
> make: *** [modules] Error 2
> 
> 
>>  create mode 100644 arch/arm64/include/asm/extio.h
>>  create mode 100644 arch/arm64/kernel/extio.c
>>
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index 969ef88..b44070b 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -163,6 +163,12 @@ config ARCH_MMAP_RND_COMPAT_BITS_MIN
>>  config ARCH_MMAP_RND_COMPAT_BITS_MAX
>>         default 16
>>
>> +config ARM64_INDIRECT_PIO
>> +       bool "access peripherals with legacy I/O port"
>> +       help
>> +         Support special accessors for ISA I/O devices. This is needed for
>> +         SoCs that do not support standard read/write for the ISA range.
>> +
>>  config NO_IOPORT_MAP
>>         def_bool y if !PCI
>>
>> diff --git a/arch/arm64/include/asm/extio.h b/arch/arm64/include/asm/extio.h
>> new file mode 100644
>> index 0000000..6ae0787
>> --- /dev/null
>> +++ b/arch/arm64/include/asm/extio.h
>> @@ -0,0 +1,94 @@
>> +/*
>> + * Copyright (C) 2016 Hisilicon Limited, All Rights Reserved.
>> + * Author: Zhichang Yuan <yuanzhichang@hisilicon.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.
>> + *
>> + * 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.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>> + */
>> +
>> +#ifndef __LINUX_EXTIO_H
>> +#define __LINUX_EXTIO_H
>> +
>> +struct extio_ops {
>> +       unsigned long start;/* inclusive, sys io addr */
>> +       unsigned long end;/* inclusive, sys io addr */
>> +
>> +       u64 (*pfin)(void *devobj, unsigned long ptaddr, size_t dlen);
>> +       void (*pfout)(void *devobj, unsigned long ptaddr, u32 outval,
>> +                                       size_t dlen);
>> +       u64 (*pfins)(void *devobj, unsigned long ptaddr, void *inbuf,
>> +                               size_t dlen, unsigned int count);
>> +       void (*pfouts)(void *devobj, unsigned long ptaddr,
>> +                               const void *outbuf, size_t dlen,
>> +                               unsigned int count);
>> +       void *devpara;
>> +};
>> +
>> +extern struct extio_ops *arm64_extio_ops;
>> +
>> +#define DECLARE_EXTIO(bw, type)                                                \
>> +extern type in##bw(unsigned long addr);                                        \
>> +extern void out##bw(type value, unsigned long addr);                   \
>> +extern void ins##bw(unsigned long addr, void *buffer, unsigned int count);\
>> +extern void outs##bw(unsigned long addr, const void *buffer, unsigned int count);
>> +
>> +#define BUILD_EXTIO(bw, type)                                          \
>> +type in##bw(unsigned long addr)                                                \
>> +{                                                                      \
>> +       if (!arm64_extio_ops || arm64_extio_ops->start > addr ||        \
>> +                       arm64_extio_ops->end < addr)                    \
>> +               return read##bw(PCI_IOBASE + addr);                     \
>> +       return arm64_extio_ops->pfin ?                                  \
>> +               arm64_extio_ops->pfin(arm64_extio_ops->devpara,         \
>> +                       addr, sizeof(type)) : -1;                       \
>> +}                                                                      \
>> +                                                                       \
>> +void out##bw(type value, unsigned long addr)                           \
>> +{                                                                      \
>> +       if (!arm64_extio_ops || arm64_extio_ops->start > addr ||        \
>> +                       arm64_extio_ops->end < addr)                    \
>> +               write##bw(value, PCI_IOBASE + addr);                    \
>> +       else                                                            \
>> +               if (arm64_extio_ops->pfout)                             \
>> +                       arm64_extio_ops->pfout(arm64_extio_ops->devpara,\
>> +                               addr, value, sizeof(type));             \
>> +}                                                                      \
>> +                                                                       \
>> +void ins##bw(unsigned long addr, void *buffer, unsigned int count)     \
>> +{                                                                      \
>> +       if (!arm64_extio_ops || arm64_extio_ops->start > addr ||        \
>> +                       arm64_extio_ops->end < addr)                    \
>> +               reads##bw(PCI_IOBASE + addr, buffer, count);            \
>> +       else                                                            \
>> +               if (arm64_extio_ops->pfins)                             \
>> +                       arm64_extio_ops->pfins(arm64_extio_ops->devpara,\
>> +                               addr, buffer, sizeof(type), count);     \
>> +}                                                                      \
>> +                                                                       \
>> +void outs##bw(unsigned long addr, const void *buffer, unsigned int count)      \
>> +{                                                                      \
>> +       if (!arm64_extio_ops || arm64_extio_ops->start > addr ||        \
>> +                       arm64_extio_ops->end < addr)                    \
>> +               writes##bw(PCI_IOBASE + addr, buffer, count);           \
>> +       else                                                            \
>> +               if (arm64_extio_ops->pfouts)                            \
>> +                       arm64_extio_ops->pfouts(arm64_extio_ops->devpara,\
>> +                               addr, buffer, sizeof(type), count);     \
>> +}
>> +
>> +static inline void arm64_set_extops(struct extio_ops *ops)
>> +{
>> +       if (ops)
>> +               WRITE_ONCE(arm64_extio_ops, ops);
>> +}
>> +
>> +#endif /* __LINUX_EXTIO_H*/
>> diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
>> index 0bba427..136735d 100644
>> --- a/arch/arm64/include/asm/io.h
>> +++ b/arch/arm64/include/asm/io.h
>> @@ -31,6 +31,7 @@
>>  #include <asm/early_ioremap.h>
>>  #include <asm/alternative.h>
>>  #include <asm/cpufeature.h>
>> +#include <asm/extio.h>
>>
>>  #include <xen/xen.h>
>>
>> @@ -149,6 +150,34 @@ static inline u64 __raw_readq(const volatile void __iomem *addr)
>>  #define IO_SPACE_LIMIT         (PCI_IO_SIZE - 1)
>>  #define PCI_IOBASE             ((void __iomem *)PCI_IO_START)
>>
>> +
>> +/*
>> + * redefine the in(s)b/out(s)b for indirect-IO.
>> + */
>> +#ifdef CONFIG_ARM64_INDIRECT_PIO
>> +#define inb inb
>> +#define outb outb
>> +#define insb insb
>> +#define outsb outsb
>> +/* external declaration */
>> +DECLARE_EXTIO(b, u8)
>> +
>> +#define inw inw
>> +#define outw outw
>> +#define insw insw
>> +#define outsw outsw
>> +
>> +DECLARE_EXTIO(w, u16)
>> +
>> +#define inl inl
>> +#define outl outl
>> +#define insl insl
>> +#define outsl outsl
>> +
>> +DECLARE_EXTIO(l, u32)
>> +#endif
>> +
>> +
>>  /*
>>   * String version of I/O memory access operations.
>>   */
>> diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
>> index 7d66bba..60e0482 100644
>> --- a/arch/arm64/kernel/Makefile
>> +++ b/arch/arm64/kernel/Makefile
>> @@ -31,6 +31,7 @@ arm64-obj-$(CONFIG_COMPAT)            += sys32.o kuser32.o signal32.o         \
>>                                            sys_compat.o entry32.o
>>  arm64-obj-$(CONFIG_FUNCTION_TRACER)    += ftrace.o entry-ftrace.o
>>  arm64-obj-$(CONFIG_MODULES)            += arm64ksyms.o module.o
>> +arm64-obj-$(CONFIG_ARM64_INDIRECT_PIO) += extio.o
>>  arm64-obj-$(CONFIG_ARM64_MODULE_PLTS)  += module-plts.o
>>  arm64-obj-$(CONFIG_PERF_EVENTS)                += perf_regs.o perf_callchain.o
>>  arm64-obj-$(CONFIG_HW_PERF_EVENTS)     += perf_event.o
>> diff --git a/arch/arm64/kernel/extio.c b/arch/arm64/kernel/extio.c
>> new file mode 100644
>> index 0000000..647b3fa
>> --- /dev/null
>> +++ b/arch/arm64/kernel/extio.c
>> @@ -0,0 +1,27 @@
>> +/*
>> + * Copyright (C) 2016 Hisilicon Limited, All Rights Reserved.
>> + * Author: Zhichang Yuan <yuanzhichang@hisilicon.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.
>> + *
>> + * 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.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>> + */
>> +
>> +#include <linux/io.h>
>> +
>> +struct extio_ops *arm64_extio_ops;
>> +
>> +
>> +BUILD_EXTIO(b, u8)
>> +
>> +BUILD_EXTIO(w, u16)
>> +
>> +BUILD_EXTIO(l, u32)
>> --
>> 1.9.1
>>
> 
> 
> 

^ permalink raw reply

* [PATCH] pinctrl: single: fix spelling mistakes on "Ivalid"
From: Colin King @ 2016-12-23  0:47 UTC (permalink / raw)
  To: linux-arm-kernel

From: Colin Ian King <colin.king@canonical.com>

Trivial fixe to spelling mistake "Ivalid" to "Invalid" in
dev_err  error message.

Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
 drivers/pinctrl/pinctrl-single.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
index a5a0392..25edadf 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -1134,7 +1134,7 @@ static int pcs_parse_one_pinctrl_entry(struct pcs_device *pcs,
 
 	rows = pinctrl_count_index_with_args(np, name);
 	if (rows <= 0) {
-		dev_err(pcs->dev, "Ivalid number of rows: %d\n", rows);
+		dev_err(pcs->dev, "Invalid number of rows: %d\n", rows);
 		return -EINVAL;
 	}
 
-- 
2.10.2

^ permalink raw reply related

* [PATCH 1/2] soc: ti: Use remoteproc auto_boot feature
From: Sarangdhar Joshi @ 2016-12-23  0:07 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161222130246.GA8359@builder>

On 12/22/2016 5:02 AM, Bjorn Andersson wrote:
> On Wed 21 Dec 19:16 PST 2016, Suman Anna wrote:
>
>> Hi Sarang,
>>
>> On 12/15/2016 06:03 PM, Sarangdhar Joshi wrote:
>>> The function wkup_m3_rproc_boot_thread waits for asynchronous
>>> firmware loading to complete successfully before calling
>>> rproc_boot(). The same can be achieved by just setting
>>> rproc->auto_boot flag. Change this. As a result this change
>>> removes wkup_m3_rproc_boot_thread and moves m3_ipc->sync_complete
>>> initialization to the wkup_m3_ipc_probe().
>>>
>>> Other than the current usage, the firmware_loading_complete is
>>> only used in rproc_del() where it's no longer needed.  This
>>> change is in preparation for removing firmware_loading_complete
>>> completely.
>>
>> Based on the comments so far, I am assuming that you are dropping this
>> series.
>>
>
> Following up on those comments only revealed that we have several other
> similar race conditions, so I'm hoping that Sarangdhar will continue to
> work on fixing those - and in this process get rid of this completion.
>
>> In any case, this series did break our PM stack. We definitely don't
>> want to auto-boot the wkup_m3_rproc device, that responsibility will
>> need to stay with the wkup_m3_ipc driver.
>>
>
> Reviewing the wkup_m3 situation again I see that as we have moved the
> resource table parsing to the rproc_boot() path there's no longer any
> need for the wkup_m3_ipc driver to wait for the remoteproc-core-internal
> completion.
>
> If rproc_get_by_phandle() returns non-NULL it is initialized. We still
> don't want to call rproc_boot() from wkup_m3_ipc_probe(), so let's keep
> the wkup_m3_rproc_boot_thread().

Did you mean it's okay to call rproc_boot() from wkup_m3_ipc_probe()? 
rproc_boot() calls request_firmware() anyways and so there is no need to 
wait for completion of asynchronous firmware loading.

>
> Sarangdhar, could you update the wkup_m3_ipc patch to just drop the
> wait_for_completion() call?

Sure, assuming we should still keep the rproc_boot() call in the kthread.

Regards,
Sarang

>
> Regards,
> Bjorn
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-remoteproc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

^ permalink raw reply

* [PATCH 1/2] soc: ti: Use remoteproc auto_boot feature
From: Sarangdhar Joshi @ 2016-12-23  0:01 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1f5b2631-f744-a5c1-55c1-82eb27d5cbd7@ti.com>

Hi Suman,

On 12/21/2016 7:16 PM, Suman Anna wrote:
> Hi Sarang,
>
> On 12/15/2016 06:03 PM, Sarangdhar Joshi wrote:
>> The function wkup_m3_rproc_boot_thread waits for asynchronous
>> firmware loading to complete successfully before calling
>> rproc_boot(). The same can be achieved by just setting
>> rproc->auto_boot flag. Change this. As a result this change
>> removes wkup_m3_rproc_boot_thread and moves m3_ipc->sync_complete
>> initialization to the wkup_m3_ipc_probe().
>>
>> Other than the current usage, the firmware_loading_complete is
>> only used in rproc_del() where it's no longer needed.  This
>> change is in preparation for removing firmware_loading_complete
>> completely.
>
> Based on the comments so far, I am assuming that you are dropping this
> series.

No, may not be dropping this. Will try to handle it differently in 
rproc_del() (probably by making use of some state flag).

>
> In any case, this series did break our PM stack. We definitely don't
> want to auto-boot the wkup_m3_rproc device, that responsibility will
> need to stay with the wkup_m3_ipc driver.

Which scenario did it break? Booting up rproc device before 
wkup_m3_ipc_probe() causes issues?

Nevertheless, I think Bjorn's suggestion of just dropping the call to 
wait_for_completion() and keeping kthread looks good, also because of 
the fact that rproc_boot() anyways calls request_firmware() and no 
longer needed to wait on asynchronous loading of firmware.

Regards,
Sarang

>
> regards
> Suman
>
>>
>> CC: Dave Gerlach <d-gerlach@ti.com>
>> CC: Suman Anna <s-anna@ti.com>
>> CC: Bjorn Andersson <bjorn.andersson@linaro.org>
>> Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org>
>> ---
>>
>> Hi Suman,
>>
>> Unfortunately, I don't have a TI device and couldn't test this
>> change. Is it possible for you to test this change on TI device?
>>
>> Thanks in advance.
>>
>> Regards,
>> Sarang
>>
>>  drivers/remoteproc/wkup_m3_rproc.c |  2 +-
>>  drivers/soc/ti/wkup_m3_ipc.c       | 35 ++---------------------------------
>>  2 files changed, 3 insertions(+), 34 deletions(-)
>>
>> diff --git a/drivers/remoteproc/wkup_m3_rproc.c b/drivers/remoteproc/wkup_m3_rproc.c
>> index 18175d0..79ea022 100644
>> --- a/drivers/remoteproc/wkup_m3_rproc.c
>> +++ b/drivers/remoteproc/wkup_m3_rproc.c
>> @@ -167,7 +167,7 @@ static int wkup_m3_rproc_probe(struct platform_device *pdev)
>>  		goto err;
>>  	}
>>
>> -	rproc->auto_boot = false;
>> +	rproc->auto_boot = true;
>>
>>  	wkupm3 = rproc->priv;
>>  	wkupm3->rproc = rproc;
>> diff --git a/drivers/soc/ti/wkup_m3_ipc.c b/drivers/soc/ti/wkup_m3_ipc.c
>> index 8823cc8..31090d70 100644
>> --- a/drivers/soc/ti/wkup_m3_ipc.c
>> +++ b/drivers/soc/ti/wkup_m3_ipc.c
>> @@ -17,7 +17,6 @@
>>
>>  #include <linux/err.h>
>>  #include <linux/kernel.h>
>> -#include <linux/kthread.h>
>>  #include <linux/interrupt.h>
>>  #include <linux/irq.h>
>>  #include <linux/module.h>
>> @@ -365,22 +364,6 @@ void wkup_m3_ipc_put(struct wkup_m3_ipc *m3_ipc)
>>  }
>>  EXPORT_SYMBOL_GPL(wkup_m3_ipc_put);
>>
>> -static void wkup_m3_rproc_boot_thread(struct wkup_m3_ipc *m3_ipc)
>> -{
>> -	struct device *dev = m3_ipc->dev;
>> -	int ret;
>> -
>> -	wait_for_completion(&m3_ipc->rproc->firmware_loading_complete);
>> -
>> -	init_completion(&m3_ipc->sync_complete);
>> -
>> -	ret = rproc_boot(m3_ipc->rproc);
>> -	if (ret)
>> -		dev_err(dev, "rproc_boot failed\n");
>> -
>> -	do_exit(0);
>> -}
>> -
>>  static int wkup_m3_ipc_probe(struct platform_device *pdev)
>>  {
>>  	struct device *dev = &pdev->dev;
>> @@ -388,7 +371,6 @@ static int wkup_m3_ipc_probe(struct platform_device *pdev)
>>  	phandle rproc_phandle;
>>  	struct rproc *m3_rproc;
>>  	struct resource *res;
>> -	struct task_struct *task;
>>  	struct wkup_m3_ipc *m3_ipc;
>>
>>  	m3_ipc = devm_kzalloc(dev, sizeof(*m3_ipc), GFP_KERNEL);
>> @@ -402,6 +384,8 @@ static int wkup_m3_ipc_probe(struct platform_device *pdev)
>>  		return PTR_ERR(m3_ipc->ipc_mem_base);
>>  	}
>>
>> +	init_completion(&m3_ipc->sync_complete);
>> +
>>  	irq = platform_get_irq(pdev, 0);
>>  	if (!irq) {
>>  		dev_err(&pdev->dev, "no irq resource\n");
>> @@ -449,25 +433,10 @@ static int wkup_m3_ipc_probe(struct platform_device *pdev)
>>
>>  	m3_ipc->ops = &ipc_ops;
>>
>> -	/*
>> -	 * Wait for firmware loading completion in a thread so we
>> -	 * can boot the wkup_m3 as soon as it's ready without holding
>> -	 * up kernel boot
>> -	 */
>> -	task = kthread_run((void *)wkup_m3_rproc_boot_thread, m3_ipc,
>> -			   "wkup_m3_rproc_loader");
>> -
>> -	if (IS_ERR(task)) {
>> -		dev_err(dev, "can't create rproc_boot thread\n");
>> -		goto err_put_rproc;
>> -	}
>> -
>>  	m3_ipc_state = m3_ipc;
>>
>>  	return 0;
>>
>> -err_put_rproc:
>> -	rproc_put(m3_rproc);
>>  err_free_mbox:
>>  	mbox_free_channel(m3_ipc->mbox);
>>  	return ret;
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

^ permalink raw reply

* [RFC] arm64/acpi: make ACPI boot preference configurable
From: Mark Rutland @ 2016-12-22 23:06 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <7eba0601099f75f19021c4259eca75ada06f4511.1482341997.git.jtoppins@redhat.com>

Hi,

On Wed, Dec 21, 2016 at 12:54:05PM -0500, Jonathan Toppins wrote:
> This patch allows a user to configure ACPI to be preferred over
> device-tree.
> 
> Currently for ACPI to be used a user either has to set acpi=on on the
> kernel command line or make sure any device tree passed to the kernel
> is empty. If the dtb passed to the kernel is non-empty then device-tree
> will be chosen as the boot method of choice even if it is not correct.
> To prevent this situation where a system is only intended to be booted
> via ACPI a user can set this kernel configuration so it ignores
> device-tree settings unless ACPI table checks fail.

I'm a little confused here. Judging by the comment inside acpi_boot_table_init,
and the code immediately below it, in the absence of a "real" DTB, ACPI will be
used.

Could you elaborate on the situation where "a system is only intended to be
booted via ACPI"? e.g. whose preference or requirement is this? The HW vendor,
distro, or user? Why/when would the current behaviour not be correct?

Thanks,
Mark.

> 
> Signed-off-by: Jonathan Toppins <jtoppins@redhat.com>
> ---
>  arch/arm64/Kconfig       | 13 +++++++++++++
>  arch/arm64/kernel/acpi.c |  2 +-
>  2 files changed, 14 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 111742126897..e432e84245b9 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -954,6 +954,19 @@ config ARM64_ACPI_PARKING_PROTOCOL
>  	  protocol even if the corresponding data is present in the ACPI
>  	  MADT table.
>  
> +config ARM64_PREFER_ACPI
> +	bool "Prefer usage of ACPI boot tables over device-tree"
> +	depends on ACPI
> +	help
> +	  Normally device-tree is preferred over ACPI on arm64 unless
> +	  explicitly preferred via kernel command line, something like: acpi=on
> +	  This configuration changes this default behaviour by pretending
> +	  the user set acpi=on on the command line. This configuration still
> +	  allows the user to turn acpi table parsing off via acpi=off. If
> +	  for some reason the table checks fail the system will still fall
> +	  back to using device-tree unless the user explicitly sets acpi=force
> +	  on the command line.
> +
>  config CMDLINE
>  	string "Default kernel command string"
>  	default ""
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index 252a6d9c1da5..b5dfa5752ff7 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -43,7 +43,7 @@ int acpi_pci_disabled = 1;	/* skip ACPI PCI scan and IRQ initialization */
>  EXPORT_SYMBOL(acpi_pci_disabled);
>  
>  static bool param_acpi_off __initdata;
> -static bool param_acpi_on __initdata;
> +static bool param_acpi_on __initdata = IS_ENABLED(CONFIG_ARM64_PREFER_ACPI);
>  static bool param_acpi_force __initdata;
>  
>  static int __init parse_acpi(char *arg)
> -- 
> 2.10.2
> 

^ permalink raw reply

* [PATCH 4/5] arm: mvebu: Add device tree for 98DX3236 SoCs
From: Rob Herring @ 2016-12-22 22:53 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161222041328.3303-5-chris.packham@alliedtelesis.co.nz>

On Thu, Dec 22, 2016 at 05:13:27PM +1300, Chris Packham wrote:
> The Marvell 98DX3236, 98DX3336, 98DX4521 and variants are switch ASICs
> with integrated CPUs. They are similar to the Armada XP SoCs but have
> different I/O interfaces.
> 
> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
> ---
>  .../devicetree/bindings/arm/marvell/98dx3236.txt   |  10 +
>  arch/arm/boot/dts/armada-xp-98dx3236.dtsi          | 231 +++++++++++++++++++++
>  arch/arm/boot/dts/armada-xp-98dx3336.dtsi          |  78 +++++++
>  arch/arm/boot/dts/armada-xp-98dx4251.dtsi          |  78 +++++++
>  4 files changed, 397 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/marvell/98dx3236.txt
>  create mode 100644 arch/arm/boot/dts/armada-xp-98dx3236.dtsi
>  create mode 100644 arch/arm/boot/dts/armada-xp-98dx3336.dtsi
>  create mode 100644 arch/arm/boot/dts/armada-xp-98dx4251.dtsi
> 
> diff --git a/Documentation/devicetree/bindings/arm/marvell/98dx3236.txt b/Documentation/devicetree/bindings/arm/marvell/98dx3236.txt
> new file mode 100644
> index 000000000000..e7dc9b2dd90b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/marvell/98dx3236.txt
> @@ -0,0 +1,10 @@
> +Marvell 98DX3236, 98DX3336 and 98DX4251 Platforms Device Tree Bindings
> +----------------------------------------------------------------------
> +
> +Boards with a SoC of the Marvell 98DX3236, 98DX3336 and 98DX4251 families
> +shall have the following property:
> +
> +Required root node property:
> +
> +compatible: one of "marvell,armadaxp-98dx3236", "marvell,armadaxp-98dx3336"
> +            or "marvell,armadaxp-98dx4251"

The 3336 and 4251 are compatible with 3236 according to the dts files. 
That needs to be expressed here.

Rob

^ permalink raw reply

* [PATCH 3/5] pinctrl: mvebu: pinctrl driver for 98DX3236 SoC
From: Rob Herring @ 2016-12-22 22:48 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161222041328.3303-4-chris.packham@alliedtelesis.co.nz>

On Thu, Dec 22, 2016 at 05:13:26PM +1300, Chris Packham wrote:
> From: Kalyan Kinthada <kalyan.kinthada@alliedtelesis.co.nz>
> 
> This pinctrl driver supports the 98DX3236, 98DX3336 and 98DX4251 SoCs
> from Marvell.
> 
> Signed-off-by: Kalyan Kinthada <kalyan.kinthada@alliedtelesis.co.nz>
> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
> ---
>  .../pinctrl/marvell,armada-98dx3236-pinctrl.txt    |  46 +++++++

Acked-by: Rob Herring <robh@kernel.org>

>  drivers/pinctrl/mvebu/pinctrl-armada-xp.c          | 145 +++++++++++++++++++++
>  2 files changed, 191 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pinctrl/marvell,armada-98dx3236-pinctrl.txt

^ permalink raw reply

* [PATCH v2 2/2] arm: perf: Mark as non-removable
From: Mark Rutland @ 2016-12-22 22:48 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161221150340.25657-3-alexander.stein@systec-electronic.com>

Hi,

On Wed, Dec 21, 2016 at 04:03:40PM +0100, Alexander Stein wrote:
> This driver can only built into the kernel. So disallow driver bind/unbind
> and also prevent a kernel error in case DEBUG_TEST_DRIVER_REMOVE is
> enabled.
> 
> Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
> ---
>  arch/arm/kernel/perf_event_v7.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/kernel/perf_event_v7.c b/arch/arm/kernel/perf_event_v7.c
> index b942349..795e373 100644
> --- a/arch/arm/kernel/perf_event_v7.c
> +++ b/arch/arm/kernel/perf_event_v7.c
> @@ -2029,6 +2029,7 @@ static int armv7_pmu_device_probe(struct platform_device *pdev)
>  static struct platform_driver armv7_pmu_driver = {
>  	.driver		= {
>  		.name	= "armv7-pmu",
> +		.suppress_bind_attrs = true,
>  		.of_match_table = armv7_pmu_of_device_ids,
>  	},

While this patch looks correct, the other perf_event_* drivers (e.g. those
under arch/arm/) will need similar treatment.

More generally, updating each and every driver in this manner seems like a
scattergun approach that is tiresome and error prone.

IMO, it would be vastly better for a higher layer to enforce that we don't
attempt to unbind drivers where the driver does not have a remove callback, as
is the case here (and I suspect most over cases where DEBUG_TEST_DRIVER_REMOVE
is blowing up).

Is there any reason that can't be enforced at the bus layer, say?

Thanks,
Mark.

^ permalink raw reply

* [PATCH 2/5] arm: mvebu: support for SMP on 98DX3336 SoC
From: Rob Herring @ 2016-12-22 22:47 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161222041328.3303-3-chris.packham@alliedtelesis.co.nz>

On Thu, Dec 22, 2016 at 05:13:25PM +1300, Chris Packham wrote:
> Compared to the armada-xp the 98DX3336 uses different registers to set
> the boot address for the secondary CPU so a new enable-method is needed.
> This will only work if the machine definition doesn't define an overall
> smp_ops because there is not currently a way of overriding this from the
> device tree if it is set in the machine definition.

Doesn't look like you documented the enable-method value.

> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
> ---
>  .../bindings/arm/marvell/98dx3236-resume-ctrl.txt  | 18 ++++++
>  arch/arm/mach-mvebu/Makefile                       |  1 +
>  arch/arm/mach-mvebu/common.h                       |  1 +
>  arch/arm/mach-mvebu/platsmp.c                      | 43 ++++++++++++++
>  arch/arm/mach-mvebu/pmsu-98dx3236.c                | 69 ++++++++++++++++++++++
>  5 files changed, 132 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/marvell/98dx3236-resume-ctrl.txt
>  create mode 100644 arch/arm/mach-mvebu/pmsu-98dx3236.c

^ permalink raw reply

* [PATCH] mm: pmd dirty emulation in page fault handler
From: Andreas Schwab @ 2016-12-22 22:12 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161222145203.GA18970@bbox>

On Dez 22 2016, Minchan Kim <minchan@kernel.org> wrote:

> From b3ec95c0df91ad113525968a4a6b53030fd0b48d Mon Sep 17 00:00:00 2001
> From: Minchan Kim <minchan@kernel.org>
> Date: Thu, 22 Dec 2016 23:43:49 +0900
> Subject: [PATCH v2] mm: pmd dirty emulation in page fault handler
>
> Andreas reported [1] made a test in jemalloc hang in THP mode in arm64.
> http://lkml.kernel.org/r/mvmmvfy37g1.fsf at hawking.suse.de
>
> The problem is page fault handler supports only accessed flag emulation
> for THP page of SW-dirty/accessed architecture.
>
> This patch enables dirty-bit emulation for those architectures.
> Without it, MADV_FREE makes application hang by repeated fault forever.
>
> [1] b8d3c4c3009d, mm/huge_memory.c: don't split THP page when MADV_FREE syscall is called

Successfully tested a backport to 4.9.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab at suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

^ permalink raw reply

* [PATCH v4 0/5] mfd: dt: Add bindings for the Aspeed MFDs
From: Corey Minyard @ 2016-12-22 21:47 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161220071535.27542-1-andrew@aj.id.au>

It looks like this is ready.  Should I take this in the IPMI tree, or is 
there a better tree for it?

-corey

On 12/20/2016 01:15 AM, Andrew Jeffery wrote:
> Hi Lee,
>
> Here's v4 of the Aspeed LPC MFD devicetree bindings series. v3 can be found at:
>
>    https://lkml.org/lkml/2016/12/5/835
>
> Changes since v3:
>
> * Based on Arnd's argument[1], drop the addition of the mfd/syscon bindings
>    directory as well as the the last patch in v3, which moved a number of
>    existing bindings. Eventually the Aspeed display controller will have a
>    device-specific driver so it doesn't belong there either.
>
> * Add a compatible string for the AST2400 in the LPC Host Controller bindings
>    as requested by Joel and slightly tweak the reg description for Rob.
>
> [1] https://lkml.org/lkml/2016/12/13/202
>
> Andrew Jeffery (5):
>    mfd: dt: Fix "indicates" typo in mfd bindings document
>    mfd: dt: ranges, #address-cells and #size-cells as optional properties
>    mfd: dt: Add Aspeed Low Pin Count Controller bindings
>    mfd: dt: Add bindings for the Aspeed LPC Host Controller (LHC)
>    mfd: dt: Add bindings for the Aspeed SoC Display Controller (GFX)
>
>   .../devicetree/bindings/mfd/aspeed-gfx.txt         |  17 +++
>   .../devicetree/bindings/mfd/aspeed-lpc.txt         | 137 +++++++++++++++++++++
>   Documentation/devicetree/bindings/mfd/mfd.txt      |  12 +-
>   3 files changed, 165 insertions(+), 1 deletion(-)
>   create mode 100644 Documentation/devicetree/bindings/mfd/aspeed-gfx.txt
>   create mode 100644 Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
>

^ permalink raw reply

* [PATCH] drivers: remoteproc: constify rproc_ops structures
From: Suman Anna @ 2016-12-22 21:22 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1481974176-19912-1-git-send-email-bhumirks@gmail.com>

On 12/17/2016 05:29 AM, Bhumika Goyal wrote:
> Declare rproc_ops structures as const as they are only passed as an
> argument to the function rproc_alloc. This argument is of type const, so
> rproc_ops structures having this property can be declared const too.
> Done using Coccinelle:
> 
> @r1 disable optional_qualifier @
> identifier i;
> position p;
> @@
> static struct rproc_ops i at p = {...};
> 
> @ok1@
> identifier r1.i;
> position p;
> @@
> rproc_alloc(...,&i at p,...)
> 
> @bad@
> position p!={r1.p,ok1.p};
> identifier r1.i;
> @@
> i at p
> 
> @depends on !bad disable optional_qualifier@
> identifier r1.i;
> @@
> +const
> struct rproc_ops i;
> 
> File sizes before:
>    text	   data	    bss	    dec	    hex	filename
>    1258	    416	      0	   1674	    68a remoteproc/omap_remoteproc.o
>    2402	    240	      0	   2642	    a52 remoteproc/st_remoteproc.o
>    2064	    272	      0	   2336	    920 remoteproc/st_slim_rproc.o
>    2160	    240	      0	   2400	    960 remoteproc/wkup_m3_rproc.o
> 
> File sizes after:
>    text	   data	    bss	    dec	    hex	filename
>    1297	    368	      0	   1665	    681 remoteproc/omap_remoteproc.o
>    2434	    192	      0	   2626	    a42 remoteproc/st_remoteproc.o
>    2112	    240	      0	   2352	    930 remoteproc/st_slim_rproc.o
>    2200	    192	      0	   2392	    958 remoteproc/wkup_m3_rproc.o
> 
> Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>

Thanks for the cleanup. The da8xx_remoteproc.c file could also use the
same fix.

regards
Suman

> ---
>  drivers/remoteproc/omap_remoteproc.c | 2 +-
>  drivers/remoteproc/st_remoteproc.c   | 2 +-
>  drivers/remoteproc/st_slim_rproc.c   | 2 +-
>  drivers/remoteproc/wkup_m3_rproc.c   | 2 +-
>  4 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/remoteproc/omap_remoteproc.c b/drivers/remoteproc/omap_remoteproc.c
> index fa63bf2..a96ce90 100644
> --- a/drivers/remoteproc/omap_remoteproc.c
> +++ b/drivers/remoteproc/omap_remoteproc.c
> @@ -177,7 +177,7 @@ static int omap_rproc_stop(struct rproc *rproc)
>  	return 0;
>  }
>  
> -static struct rproc_ops omap_rproc_ops = {
> +static const struct rproc_ops omap_rproc_ops = {
>  	.start		= omap_rproc_start,
>  	.stop		= omap_rproc_stop,
>  	.kick		= omap_rproc_kick,
> diff --git a/drivers/remoteproc/st_remoteproc.c b/drivers/remoteproc/st_remoteproc.c
> index da4e152..f21787b 100644
> --- a/drivers/remoteproc/st_remoteproc.c
> +++ b/drivers/remoteproc/st_remoteproc.c
> @@ -107,7 +107,7 @@ static int st_rproc_stop(struct rproc *rproc)
>  	return sw_err ?: pwr_err;
>  }
>  
> -static struct rproc_ops st_rproc_ops = {
> +static const struct rproc_ops st_rproc_ops = {
>  	.start		= st_rproc_start,
>  	.stop		= st_rproc_stop,
>  };
> diff --git a/drivers/remoteproc/st_slim_rproc.c b/drivers/remoteproc/st_slim_rproc.c
> index 507716c..6cfd862 100644
> --- a/drivers/remoteproc/st_slim_rproc.c
> +++ b/drivers/remoteproc/st_slim_rproc.c
> @@ -200,7 +200,7 @@ static void *slim_rproc_da_to_va(struct rproc *rproc, u64 da, int len)
>  	return va;
>  }
>  
> -static struct rproc_ops slim_rproc_ops = {
> +static const struct rproc_ops slim_rproc_ops = {
>  	.start		= slim_rproc_start,
>  	.stop		= slim_rproc_stop,
>  	.da_to_va       = slim_rproc_da_to_va,
> diff --git a/drivers/remoteproc/wkup_m3_rproc.c b/drivers/remoteproc/wkup_m3_rproc.c
> index 18175d0..1ada0e5 100644
> --- a/drivers/remoteproc/wkup_m3_rproc.c
> +++ b/drivers/remoteproc/wkup_m3_rproc.c
> @@ -111,7 +111,7 @@ static void *wkup_m3_rproc_da_to_va(struct rproc *rproc, u64 da, int len)
>  	return va;
>  }
>  
> -static struct rproc_ops wkup_m3_rproc_ops = {
> +static const struct rproc_ops wkup_m3_rproc_ops = {
>  	.start		= wkup_m3_rproc_start,
>  	.stop		= wkup_m3_rproc_stop,
>  	.da_to_va	= wkup_m3_rproc_da_to_va,
> 

^ permalink raw reply

* [PATCH] devicetree: bindings: clk: mvebu: fix description for sata1 on Armada XP
From: Rob Herring @ 2016-12-22 21:20 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161220212005.26139-1-uwe@kleine-koenig.org>

On Tue, Dec 20, 2016 at 10:20:05PM +0100, Uwe Kleine-K?nig wrote:
> SATA Host 0 clock is (as correctly documented) id 15/sata0.
> 
> Signed-off-by: Uwe Kleine-K?nig <uwe@kleine-koenig.org>
> ---
>  Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied, thanks.

Rob

> 
> diff --git a/Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt b/Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt
> index cb8542d910b3..5142efc8099d 100644
> --- a/Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt
> +++ b/Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt
> @@ -117,7 +117,7 @@ ID	Clock	Peripheral
>  25	tdm	Time Division Mplx
>  28	xor1	XOR DMA 1
>  29	sata1lnk
> -30	sata1	SATA Host 0
> +30	sata1	SATA Host 1
>  
>  The following is a list of provided IDs for Dove:
>  ID	Clock	Peripheral
> -- 
> 2.10.2
> 

^ permalink raw reply

* [PATCH 1/3] doc: DT: Add ti,da830-uart to serial/8250 bindings
From: Rob Herring @ 2016-12-22 21:18 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1482265384-715-2-git-send-email-david@lechnology.com>

On Tue, Dec 20, 2016 at 02:23:02PM -0600, David Lechner wrote:
> This adds the ti,da830-uart compatible string to serial 8250 UART bindings.
> 
> Signed-off-by: David Lechner <david@lechnology.com>
> ---
>  Documentation/devicetree/bindings/serial/8250.txt | 1 +
>  1 file changed, 1 insertion(+)

Acked-by: Rob Herring <robh@kernel.org>

^ permalink raw reply

* [PATCH v2 11/12] crypto: atmel-authenc: add support to authenc(hmac(shaX),Y(aes)) modes
From: kbuild test robot @ 2016-12-22 21:10 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <2a6cc4637621d2ef0d84754817128c43795cb022.1482424395.git.cyrille.pitchen@atmel.com>

Hi Cyrille,

[auto build test WARNING on cryptodev/master]
[also build test WARNING on next-20161222]
[cannot apply to v4.9]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

url:    https://github.com/0day-ci/linux/commits/Cyrille-Pitchen/crypto-atmel-authenc-add-support-to-authenc-hmac-shaX-Y-aes-modes/20161223-015820
base:   https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
config: alpha-allyesconfig (attached as .config)
compiler: alpha-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
        wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        make.cross ARCH=alpha 

All warnings (new ones prefixed by >>):

   In file included from include/linux/printk.h:305:0,
                    from include/linux/kernel.h:13,
                    from drivers/crypto/atmel-sha.c:17:
   drivers/crypto/atmel-sha.c: In function 'atmel_sha_xmit_cpu':
>> drivers/crypto/atmel-sha.c:465:19: warning: format '%d' expects argument of type 'int', but argument 6 has type 'size_t {aka long unsigned int}' [-Wformat=]
     dev_dbg(dd->dev, "xmit_cpu: digcnt: 0x%llx 0x%llx, length: %d, final: %d\n",
                      ^
   include/linux/dynamic_debug.h:134:39: note: in definition of macro 'dynamic_dev_dbg'
      __dynamic_dev_dbg(&descriptor, dev, fmt, \
                                          ^~~
>> drivers/crypto/atmel-sha.c:465:2: note: in expansion of macro 'dev_dbg'
     dev_dbg(dd->dev, "xmit_cpu: digcnt: 0x%llx 0x%llx, length: %d, final: %d\n",
     ^~~~~~~
   drivers/crypto/atmel-sha.c: In function 'atmel_sha_xmit_pdc':
   drivers/crypto/atmel-sha.c:494:19: warning: format '%d' expects argument of type 'int', but argument 6 has type 'size_t {aka long unsigned int}' [-Wformat=]
     dev_dbg(dd->dev, "xmit_pdc: digcnt: 0x%llx 0x%llx, length: %d, final: %d\n",
                      ^
   include/linux/dynamic_debug.h:134:39: note: in definition of macro 'dynamic_dev_dbg'
      __dynamic_dev_dbg(&descriptor, dev, fmt, \
                                          ^~~
   drivers/crypto/atmel-sha.c:494:2: note: in expansion of macro 'dev_dbg'
     dev_dbg(dd->dev, "xmit_pdc: digcnt: 0x%llx 0x%llx, length: %d, final: %d\n",
     ^~~~~~~
   drivers/crypto/atmel-sha.c: In function 'atmel_sha_xmit_dma':
   drivers/crypto/atmel-sha.c:541:19: warning: format '%d' expects argument of type 'int', but argument 6 has type 'size_t {aka long unsigned int}' [-Wformat=]
     dev_dbg(dd->dev, "xmit_dma: digcnt: 0x%llx 0x%llx, length: %d, final: %d\n",
                      ^
   include/linux/dynamic_debug.h:134:39: note: in definition of macro 'dynamic_dev_dbg'
      __dynamic_dev_dbg(&descriptor, dev, fmt, \
                                          ^~~
   drivers/crypto/atmel-sha.c:541:2: note: in expansion of macro 'dev_dbg'
     dev_dbg(dd->dev, "xmit_dma: digcnt: 0x%llx 0x%llx, length: %d, final: %d\n",
     ^~~~~~~
   drivers/crypto/atmel-sha.c: In function 'atmel_sha_xmit_dma_map':
>> drivers/crypto/atmel-sha.c:620:26: warning: format '%u' expects argument of type 'unsigned int', but argument 3 has type 'size_t {aka long unsigned int}' [-Wformat=]
      dev_err(dd->dev, "dma %u bytes error\n", ctx->buflen +
                             ^
   In file included from include/linux/printk.h:305:0,
                    from include/linux/kernel.h:13,
                    from drivers/crypto/atmel-sha.c:17:
   drivers/crypto/atmel-sha.c: In function 'atmel_sha_update_dma_slow':
   drivers/crypto/atmel-sha.c:641:19: warning: format '%u' expects argument of type 'unsigned int', but argument 4 has type 'size_t {aka long unsigned int}' [-Wformat=]
     dev_dbg(dd->dev, "slow: bufcnt: %u, digcnt: 0x%llx 0x%llx, final: %d\n",
                      ^
   include/linux/dynamic_debug.h:134:39: note: in definition of macro 'dynamic_dev_dbg'
      __dynamic_dev_dbg(&descriptor, dev, fmt, \
                                          ^~~
   drivers/crypto/atmel-sha.c:641:2: note: in expansion of macro 'dev_dbg'
     dev_dbg(dd->dev, "slow: bufcnt: %u, digcnt: 0x%llx 0x%llx, final: %d\n",
     ^~~~~~~
   drivers/crypto/atmel-sha.c: In function 'atmel_sha_update_dma_start':
   drivers/crypto/atmel-sha.c:669:19: warning: format '%u' expects argument of type 'unsigned int', but argument 6 has type 'size_t {aka long unsigned int}' [-Wformat=]
     dev_dbg(dd->dev, "fast: digcnt: 0x%llx 0x%llx, bufcnt: %u, total: %u\n",
                      ^
   include/linux/dynamic_debug.h:134:39: note: in definition of macro 'dynamic_dev_dbg'
      __dynamic_dev_dbg(&descriptor, dev, fmt, \
                                          ^~~
   drivers/crypto/atmel-sha.c:669:2: note: in expansion of macro 'dev_dbg'
     dev_dbg(dd->dev, "fast: digcnt: 0x%llx 0x%llx, bufcnt: %u, total: %u\n",
     ^~~~~~~
   drivers/crypto/atmel-sha.c:711:27: warning: format '%u' expects argument of type 'unsigned int', but argument 3 has type 'size_t {aka long unsigned int}' [-Wformat=]
       dev_err(dd->dev, "dma %u bytes error\n",
                              ^
   In file included from include/linux/printk.h:305:0,
                    from include/linux/kernel.h:13,
                    from drivers/crypto/atmel-sha.c:17:
   drivers/crypto/atmel-sha.c: In function 'atmel_sha_finish':
   drivers/crypto/atmel-sha.c:891:19: warning: format '%d' expects argument of type 'int', but argument 6 has type 'size_t {aka long unsigned int}' [-Wformat=]
     dev_dbg(dd->dev, "digcnt: 0x%llx 0x%llx, bufcnt: %d\n", ctx->digcnt[1],
                      ^
   include/linux/dynamic_debug.h:134:39: note: in definition of macro 'dynamic_dev_dbg'
      __dynamic_dev_dbg(&descriptor, dev, fmt, \
                                          ^~~
   drivers/crypto/atmel-sha.c:891:2: note: in expansion of macro 'dev_dbg'
     dev_dbg(dd->dev, "digcnt: 0x%llx 0x%llx, bufcnt: %d\n", ctx->digcnt[1],
     ^~~~~~~

vim +465 drivers/crypto/atmel-sha.c

ebc82efa Nicolas Royer   2012-07-01  459  			      size_t length, int final)
ebc82efa Nicolas Royer   2012-07-01  460  {
ebc82efa Nicolas Royer   2012-07-01  461  	struct atmel_sha_reqctx *ctx = ahash_request_ctx(dd->req);
ebc82efa Nicolas Royer   2012-07-01  462  	int count, len32;
ebc82efa Nicolas Royer   2012-07-01  463  	const u32 *buffer = (const u32 *)buf;
ebc82efa Nicolas Royer   2012-07-01  464  
d4905b38 Nicolas Royer   2013-02-20 @465  	dev_dbg(dd->dev, "xmit_cpu: digcnt: 0x%llx 0x%llx, length: %d, final: %d\n",
d4905b38 Nicolas Royer   2013-02-20  466  		ctx->digcnt[1], ctx->digcnt[0], length, final);
ebc82efa Nicolas Royer   2012-07-01  467  
ebc82efa Nicolas Royer   2012-07-01  468  	atmel_sha_write_ctrl(dd, 0);
ebc82efa Nicolas Royer   2012-07-01  469  
ebc82efa Nicolas Royer   2012-07-01  470  	/* should be non-zero before next lines to disable clocks later */
d4905b38 Nicolas Royer   2013-02-20  471  	ctx->digcnt[0] += length;
d4905b38 Nicolas Royer   2013-02-20  472  	if (ctx->digcnt[0] < length)
d4905b38 Nicolas Royer   2013-02-20  473  		ctx->digcnt[1]++;
ebc82efa Nicolas Royer   2012-07-01  474  
ebc82efa Nicolas Royer   2012-07-01  475  	if (final)
ebc82efa Nicolas Royer   2012-07-01  476  		dd->flags |= SHA_FLAGS_FINAL; /* catch last interrupt */
ebc82efa Nicolas Royer   2012-07-01  477  
ebc82efa Nicolas Royer   2012-07-01  478  	len32 = DIV_ROUND_UP(length, sizeof(u32));
ebc82efa Nicolas Royer   2012-07-01  479  
ebc82efa Nicolas Royer   2012-07-01  480  	dd->flags |= SHA_FLAGS_CPU;
ebc82efa Nicolas Royer   2012-07-01  481  
ebc82efa Nicolas Royer   2012-07-01  482  	for (count = 0; count < len32; count++)
ebc82efa Nicolas Royer   2012-07-01  483  		atmel_sha_write(dd, SHA_REG_DIN(count), buffer[count]);
ebc82efa Nicolas Royer   2012-07-01  484  
ebc82efa Nicolas Royer   2012-07-01  485  	return -EINPROGRESS;
ebc82efa Nicolas Royer   2012-07-01  486  }
ebc82efa Nicolas Royer   2012-07-01  487  
ebc82efa Nicolas Royer   2012-07-01  488  static int atmel_sha_xmit_pdc(struct atmel_sha_dev *dd, dma_addr_t dma_addr1,
ebc82efa Nicolas Royer   2012-07-01  489  		size_t length1, dma_addr_t dma_addr2, size_t length2, int final)
ebc82efa Nicolas Royer   2012-07-01  490  {
ebc82efa Nicolas Royer   2012-07-01  491  	struct atmel_sha_reqctx *ctx = ahash_request_ctx(dd->req);
ebc82efa Nicolas Royer   2012-07-01  492  	int len32;
ebc82efa Nicolas Royer   2012-07-01  493  
d4905b38 Nicolas Royer   2013-02-20  494  	dev_dbg(dd->dev, "xmit_pdc: digcnt: 0x%llx 0x%llx, length: %d, final: %d\n",
d4905b38 Nicolas Royer   2013-02-20  495  		ctx->digcnt[1], ctx->digcnt[0], length1, final);
ebc82efa Nicolas Royer   2012-07-01  496  
ebc82efa Nicolas Royer   2012-07-01  497  	len32 = DIV_ROUND_UP(length1, sizeof(u32));
ebc82efa Nicolas Royer   2012-07-01  498  	atmel_sha_write(dd, SHA_PTCR, SHA_PTCR_TXTDIS);
ebc82efa Nicolas Royer   2012-07-01  499  	atmel_sha_write(dd, SHA_TPR, dma_addr1);
ebc82efa Nicolas Royer   2012-07-01  500  	atmel_sha_write(dd, SHA_TCR, len32);
ebc82efa Nicolas Royer   2012-07-01  501  
ebc82efa Nicolas Royer   2012-07-01  502  	len32 = DIV_ROUND_UP(length2, sizeof(u32));
ebc82efa Nicolas Royer   2012-07-01  503  	atmel_sha_write(dd, SHA_TNPR, dma_addr2);
ebc82efa Nicolas Royer   2012-07-01  504  	atmel_sha_write(dd, SHA_TNCR, len32);
ebc82efa Nicolas Royer   2012-07-01  505  
ebc82efa Nicolas Royer   2012-07-01  506  	atmel_sha_write_ctrl(dd, 1);
ebc82efa Nicolas Royer   2012-07-01  507  
ebc82efa Nicolas Royer   2012-07-01  508  	/* should be non-zero before next lines to disable clocks later */
d4905b38 Nicolas Royer   2013-02-20  509  	ctx->digcnt[0] += length1;
d4905b38 Nicolas Royer   2013-02-20  510  	if (ctx->digcnt[0] < length1)
d4905b38 Nicolas Royer   2013-02-20  511  		ctx->digcnt[1]++;
ebc82efa Nicolas Royer   2012-07-01  512  
ebc82efa Nicolas Royer   2012-07-01  513  	if (final)
ebc82efa Nicolas Royer   2012-07-01  514  		dd->flags |= SHA_FLAGS_FINAL; /* catch last interrupt */
ebc82efa Nicolas Royer   2012-07-01  515  
ebc82efa Nicolas Royer   2012-07-01  516  	dd->flags |=  SHA_FLAGS_DMA_ACTIVE;
ebc82efa Nicolas Royer   2012-07-01  517  
ebc82efa Nicolas Royer   2012-07-01  518  	/* Start DMA transfer */
ebc82efa Nicolas Royer   2012-07-01  519  	atmel_sha_write(dd, SHA_PTCR, SHA_PTCR_TXTEN);
ebc82efa Nicolas Royer   2012-07-01  520  
ebc82efa Nicolas Royer   2012-07-01  521  	return -EINPROGRESS;
ebc82efa Nicolas Royer   2012-07-01  522  }
ebc82efa Nicolas Royer   2012-07-01  523  
d4905b38 Nicolas Royer   2013-02-20  524  static void atmel_sha_dma_callback(void *data)
d4905b38 Nicolas Royer   2013-02-20  525  {
d4905b38 Nicolas Royer   2013-02-20  526  	struct atmel_sha_dev *dd = data;
d4905b38 Nicolas Royer   2013-02-20  527  
b48b114c Cyrille Pitchen 2016-12-22  528  	dd->is_async = true;
b48b114c Cyrille Pitchen 2016-12-22  529  
d4905b38 Nicolas Royer   2013-02-20  530  	/* dma_lch_in - completed - wait DATRDY */
d4905b38 Nicolas Royer   2013-02-20  531  	atmel_sha_write(dd, SHA_IER, SHA_INT_DATARDY);
d4905b38 Nicolas Royer   2013-02-20  532  }
d4905b38 Nicolas Royer   2013-02-20  533  
d4905b38 Nicolas Royer   2013-02-20  534  static int atmel_sha_xmit_dma(struct atmel_sha_dev *dd, dma_addr_t dma_addr1,
d4905b38 Nicolas Royer   2013-02-20  535  		size_t length1, dma_addr_t dma_addr2, size_t length2, int final)
d4905b38 Nicolas Royer   2013-02-20  536  {
d4905b38 Nicolas Royer   2013-02-20  537  	struct atmel_sha_reqctx *ctx = ahash_request_ctx(dd->req);
d4905b38 Nicolas Royer   2013-02-20  538  	struct dma_async_tx_descriptor	*in_desc;
d4905b38 Nicolas Royer   2013-02-20  539  	struct scatterlist sg[2];
d4905b38 Nicolas Royer   2013-02-20  540  
d4905b38 Nicolas Royer   2013-02-20 @541  	dev_dbg(dd->dev, "xmit_dma: digcnt: 0x%llx 0x%llx, length: %d, final: %d\n",
d4905b38 Nicolas Royer   2013-02-20  542  		ctx->digcnt[1], ctx->digcnt[0], length1, final);
d4905b38 Nicolas Royer   2013-02-20  543  
d4905b38 Nicolas Royer   2013-02-20  544  	dd->dma_lch_in.dma_conf.src_maxburst = 16;
d4905b38 Nicolas Royer   2013-02-20  545  	dd->dma_lch_in.dma_conf.dst_maxburst = 16;
d4905b38 Nicolas Royer   2013-02-20  546  
d4905b38 Nicolas Royer   2013-02-20  547  	dmaengine_slave_config(dd->dma_lch_in.chan, &dd->dma_lch_in.dma_conf);
d4905b38 Nicolas Royer   2013-02-20  548  
d4905b38 Nicolas Royer   2013-02-20  549  	if (length2) {
d4905b38 Nicolas Royer   2013-02-20  550  		sg_init_table(sg, 2);
d4905b38 Nicolas Royer   2013-02-20  551  		sg_dma_address(&sg[0]) = dma_addr1;
d4905b38 Nicolas Royer   2013-02-20  552  		sg_dma_len(&sg[0]) = length1;
d4905b38 Nicolas Royer   2013-02-20  553  		sg_dma_address(&sg[1]) = dma_addr2;
d4905b38 Nicolas Royer   2013-02-20  554  		sg_dma_len(&sg[1]) = length2;
d4905b38 Nicolas Royer   2013-02-20  555  		in_desc = dmaengine_prep_slave_sg(dd->dma_lch_in.chan, sg, 2,
d4905b38 Nicolas Royer   2013-02-20  556  			DMA_MEM_TO_DEV, DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
d4905b38 Nicolas Royer   2013-02-20  557  	} else {
d4905b38 Nicolas Royer   2013-02-20  558  		sg_init_table(sg, 1);
d4905b38 Nicolas Royer   2013-02-20  559  		sg_dma_address(&sg[0]) = dma_addr1;
d4905b38 Nicolas Royer   2013-02-20  560  		sg_dma_len(&sg[0]) = length1;
d4905b38 Nicolas Royer   2013-02-20  561  		in_desc = dmaengine_prep_slave_sg(dd->dma_lch_in.chan, sg, 1,
d4905b38 Nicolas Royer   2013-02-20  562  			DMA_MEM_TO_DEV, DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
d4905b38 Nicolas Royer   2013-02-20  563  	}
d4905b38 Nicolas Royer   2013-02-20  564  	if (!in_desc)
b48b114c Cyrille Pitchen 2016-12-22  565  		atmel_sha_complete(dd, -EINVAL);
d4905b38 Nicolas Royer   2013-02-20  566  
d4905b38 Nicolas Royer   2013-02-20  567  	in_desc->callback = atmel_sha_dma_callback;
d4905b38 Nicolas Royer   2013-02-20  568  	in_desc->callback_param = dd;
d4905b38 Nicolas Royer   2013-02-20  569  
d4905b38 Nicolas Royer   2013-02-20  570  	atmel_sha_write_ctrl(dd, 1);
d4905b38 Nicolas Royer   2013-02-20  571  
d4905b38 Nicolas Royer   2013-02-20  572  	/* should be non-zero before next lines to disable clocks later */
d4905b38 Nicolas Royer   2013-02-20  573  	ctx->digcnt[0] += length1;
d4905b38 Nicolas Royer   2013-02-20  574  	if (ctx->digcnt[0] < length1)
d4905b38 Nicolas Royer   2013-02-20  575  		ctx->digcnt[1]++;
d4905b38 Nicolas Royer   2013-02-20  576  
d4905b38 Nicolas Royer   2013-02-20  577  	if (final)
d4905b38 Nicolas Royer   2013-02-20  578  		dd->flags |= SHA_FLAGS_FINAL; /* catch last interrupt */
d4905b38 Nicolas Royer   2013-02-20  579  
d4905b38 Nicolas Royer   2013-02-20  580  	dd->flags |=  SHA_FLAGS_DMA_ACTIVE;
d4905b38 Nicolas Royer   2013-02-20  581  
d4905b38 Nicolas Royer   2013-02-20  582  	/* Start DMA transfer */
d4905b38 Nicolas Royer   2013-02-20  583  	dmaengine_submit(in_desc);
d4905b38 Nicolas Royer   2013-02-20  584  	dma_async_issue_pending(dd->dma_lch_in.chan);
d4905b38 Nicolas Royer   2013-02-20  585  
d4905b38 Nicolas Royer   2013-02-20  586  	return -EINPROGRESS;
d4905b38 Nicolas Royer   2013-02-20  587  }
d4905b38 Nicolas Royer   2013-02-20  588  
d4905b38 Nicolas Royer   2013-02-20  589  static int atmel_sha_xmit_start(struct atmel_sha_dev *dd, dma_addr_t dma_addr1,
d4905b38 Nicolas Royer   2013-02-20  590  		size_t length1, dma_addr_t dma_addr2, size_t length2, int final)
d4905b38 Nicolas Royer   2013-02-20  591  {
d4905b38 Nicolas Royer   2013-02-20  592  	if (dd->caps.has_dma)
d4905b38 Nicolas Royer   2013-02-20  593  		return atmel_sha_xmit_dma(dd, dma_addr1, length1,
d4905b38 Nicolas Royer   2013-02-20  594  				dma_addr2, length2, final);
d4905b38 Nicolas Royer   2013-02-20  595  	else
d4905b38 Nicolas Royer   2013-02-20  596  		return atmel_sha_xmit_pdc(dd, dma_addr1, length1,
d4905b38 Nicolas Royer   2013-02-20  597  				dma_addr2, length2, final);
d4905b38 Nicolas Royer   2013-02-20  598  }
d4905b38 Nicolas Royer   2013-02-20  599  
ebc82efa Nicolas Royer   2012-07-01  600  static int atmel_sha_update_cpu(struct atmel_sha_dev *dd)
ebc82efa Nicolas Royer   2012-07-01  601  {
ebc82efa Nicolas Royer   2012-07-01  602  	struct atmel_sha_reqctx *ctx = ahash_request_ctx(dd->req);
ebc82efa Nicolas Royer   2012-07-01  603  	int bufcnt;
ebc82efa Nicolas Royer   2012-07-01  604  
ebc82efa Nicolas Royer   2012-07-01  605  	atmel_sha_append_sg(ctx);
ebc82efa Nicolas Royer   2012-07-01  606  	atmel_sha_fill_padding(ctx, 0);
ebc82efa Nicolas Royer   2012-07-01  607  	bufcnt = ctx->bufcnt;
ebc82efa Nicolas Royer   2012-07-01  608  	ctx->bufcnt = 0;
ebc82efa Nicolas Royer   2012-07-01  609  
ebc82efa Nicolas Royer   2012-07-01  610  	return atmel_sha_xmit_cpu(dd, ctx->buffer, bufcnt, 1);
ebc82efa Nicolas Royer   2012-07-01  611  }
ebc82efa Nicolas Royer   2012-07-01  612  
ebc82efa Nicolas Royer   2012-07-01  613  static int atmel_sha_xmit_dma_map(struct atmel_sha_dev *dd,
ebc82efa Nicolas Royer   2012-07-01  614  					struct atmel_sha_reqctx *ctx,
ebc82efa Nicolas Royer   2012-07-01  615  					size_t length, int final)
ebc82efa Nicolas Royer   2012-07-01  616  {
ebc82efa Nicolas Royer   2012-07-01  617  	ctx->dma_addr = dma_map_single(dd->dev, ctx->buffer,
d4905b38 Nicolas Royer   2013-02-20  618  				ctx->buflen + ctx->block_size, DMA_TO_DEVICE);
ebc82efa Nicolas Royer   2012-07-01  619  	if (dma_mapping_error(dd->dev, ctx->dma_addr)) {
ebc82efa Nicolas Royer   2012-07-01 @620  		dev_err(dd->dev, "dma %u bytes error\n", ctx->buflen +
d4905b38 Nicolas Royer   2013-02-20  621  				ctx->block_size);
b48b114c Cyrille Pitchen 2016-12-22  622  		atmel_sha_complete(dd, -EINVAL);
ebc82efa Nicolas Royer   2012-07-01  623  	}

:::::: The code at line 465 was first introduced by commit
:::::: d4905b38d1f6b60761a6fd16f45ebd1fac8b6e1f crypto: atmel-sha - add support for latest release of the IP (0x410)

:::::: TO: Nicolas Royer <nicolas@eukrea.com>
:::::: CC: Herbert Xu <herbert@gondor.apana.org.au>

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 47848 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161223/43b808a1/attachment-0001.gz>

^ permalink raw reply

* [PATCH v4 4/5] mfd: dt: Add bindings for the Aspeed LPC Host Controller (LHC)
From: Rob Herring @ 2016-12-22 21:00 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161220071535.27542-5-andrew@aj.id.au>

On Tue, Dec 20, 2016 at 05:45:34PM +1030, Andrew Jeffery wrote:
> The LPC bus pinmux configuration on fifth generation Aspeed SoCs depends
> on bits in both the System Control Unit and the LPC Host Controller.
> 
> The Aspeed LPC Host Controller is described as a child node of the
> LPC host-range syscon device for arbitration of access by the host
> controller and pinmux drivers.
> 
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> 
> Linus: I've retained your r-b tag I don't think the addition of the ast2400
> compatible string will fuss you. Please let me know if you feel this is
> inappropriate.
> 
>  .../devicetree/bindings/mfd/aspeed-lpc.txt         | 26 ++++++++++++++++++++++
>  1 file changed, 26 insertions(+)

Acked-by: Rob Herring <robh@kernel.org>

^ permalink raw reply

* [BISECTED] v4.9: OMAP MMC regression
From: Aaro Koskinen @ 2016-12-22 20:58 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161217220120.xgyzq2hwxn3lsmm2@raspberrypi-2.musicnaut.iki.fi>

Hi,

On Sun, Dec 18, 2016 at 12:01:21AM +0200, Aaro Koskinen wrote:
> OMAP MMC is silently missing when booting v4.9 on Nokia 770 (OMAP1).
> 
> Bisected to:
> 
> commit 2d1a9a946faebfedd660a1f1c2b90984fff41f91
> Author: Peter Ujfalusi <peter.ujfalusi@ti.com>
> Date:   Wed Jul 20 11:50:29 2016 +0300
> 
>     dmaengine: omap-dma: Dynamically allocate memory for lch_map
> 
> Reveting the commit makes MMC to appear and work again...

This commit basically reduces dma_requests count to 17 (from 127)
on OMAP1.

This cannot be correct, since OMAP1 MMC is using requests (from
omap1_init_mmc):

                        rx_req = 22;
                        tx_req = 21;
[...]
                        rx_req = 55;
                        tx_req = 54;

MMC probe will fail because omap_dma_filter_fn() will fail during
dma_request_chan().

I think 2d1a9a946faebfedd660a1f1c2b90984fff41f91 should be reverted.
I cannot anymore boot my 770 with >= 4.9 kernel.

A.

^ permalink raw reply

* [PATCH 2/2] clk: hi3660: Clock driver support for Hisilicon hi3660 SoC
From: Stephen Boyd @ 2016-12-22 20:51 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <fc7bebd2-ad03-6479-d6e7-42f5d724216c@linaro.org>

On 12/22, zhangfei wrote:
> On 2016?12?22? 07:25, Stephen Boyd wrote:
> >On 12/15, Zhangfei Gao wrote:
> >>Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
> >
> >>+
> >>+	switch (type) {
> >>+	case HI3660_CRGCTRL:
> >>+		hi3660_clk_crgctrl_init(np);
> >>+		break;
> >>+	case HI3660_PCTRL:
> >>+		hi3660_clk_pctrl_init(np);
> >>+		break;
> >>+	case HI3660_PMUCTRL:
> >>+		hi3660_clk_pmuctrl_init(np);
> >>+		break;
> >>+	case HI3660_SCTRL:
> >>+		hi3660_clk_sctrl_init(np);
> >>+		break;
> >>+	case HI3660_IOMCU:
> >>+		hi3660_clk_iomcu_init(np);
> >>+		break;
> >This "multi-device" driver design is sort of odd. Why not have
> >different files and struct drivers for the different devices in
> >the system that are clock controllers? I don't really understand
> >why we're controlling the devices with one struct driver
> >instance. Is something shared between the devices?
> Do you mean put in different .c / drivers?

Yes.

> They have to be put in the same file, since the parent / child
> relate to each other.

We handle clk parent/child relationships through strings. So why
does that mean we need to put these in the same file with the
same struct driver?

> They are for the same chip, but some put in different region for
> privilege control.

Ok.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

^ permalink raw reply

* [PATCH 2/2] mfd: mc13xxx: Pass the IRQF_TRIGGER_HIGH flag.
From: Magnus Lilja @ 2016-12-22 20:16 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <9a7ab387-a3e5-913a-2204-2b337ba0f8aa@mleia.com>

Hi,

On 22 December 2016 at 02:08, Vladimir Zapolskiy <vz@mleia.com> wrote:
> On 12/21/2016 10:28 PM, Fabio Estevam wrote:
>> On Wed, Dec 21, 2016 at 6:24 PM, Vladimir Zapolskiy <vz@mleia.com> wrote:
>>
>>> Correct, I would recommend to postpone adding any extensions to the driver
>>> platform data, which by the way is found in include/linux/mfd/mc13xxx.h
>>>
>>> The extension can be added only when it becomes needed.
>>
>> Yes, I agree.
>>
>
> So, for reference here is a snippet from the i.MX31 Lite board DTS:
>
> &spi2 {
>         pinctrl-names = "default";
>         pinctrl-0 = <&pinctrl_cspi2>;
>
>         /*
>          * Note that intentionally there is no GPIO CS, i.MX31 CSPI
>          * controller does not support GPIO CS and this must be specially
>          * accounted in the driver, which currently fails to register
>          * without a provided "cs-gpios" property.
>          */
>         fsl,spi-num-chipselects = <1>;
>         status = "okay";
>
>         pmic: mc13783 at 0 {
>                 compatible = "fsl,mc13783";
>                 reg = <0>;
>                 spi-cs-high;
>                 spi-max-frequency = <1000000>;
>                 interrupt-parent = <&gpio1>;
>                 interrupts = <3 IRQ_TYPE_EDGE_RISING>;
>
>                 fsl,mc13xxx-uses-rtc;
>         };
> };
>
> I'm running the current pre-rc1 v4.10. The MFD device is registered and
> MC13783 primary interrupt connected to GPIO1_3 is fired as expected
> independently if the fixup under discussion is applied or not:
>
> root at mx31lite:~# dmesg | grep spi
> [    2.017217] mc13xxx spi32766.0: mc13783: rev: 3.3, fin: 0, fab: 0, icid: 2/0
> [    2.072029] spi_imx 50010000.cspi: probed
>
> root at mx31lite:~# dmesg | grep rtc0
> [    2.682459] mc13xxx-rtc mc13783-rtc: rtc core: registered mc13783-rtc as rtc0
>
> root at mx31lite:~# cat /proc/interrupts | grep mc13xxx-rtc
> 176:          0  spi32766.0  31 Edge      mc13xxx-rtc
> 177:          0  spi32766.0  25 Edge      mc13xxx-rtc
>
> root at mx31lite:~# echo +5 > /sys/class/rtc/rtc0/wakealarm ; sleep 5
>
> root at mx31lite:~# cat /proc/interrupts | grep mc13xxx-rtc
> 176:          0  spi32766.0  31 Edge      mc13xxx-rtc
> 177:          1  spi32766.0  25 Edge      mc13xxx-rtc
>
> So the change at least does not break i.MX31 Lite board with DTS support,
> however I'm not sure if the change is still valid for any board with DTS
> if the type of the interrupt is specified as IRQ_TYPE_EDGE_FALLING.

So, have we reached a conclusion that a solution based on the code
below is good enough for now? Further device tree development would
make it possible to support other triggers on i.MX31 boards. And any
board that already has dt support can override TRIGGER_HIGH since
irqd_get_trigger_type() will return something else than IRQ_TYPE_NONE.

> unsigned flags = irqd_get_trigger_type(irq_get_irq_data(irq));
> flags = (flags == IRQ_TYPE_NONE) ? IRQF_TRIGGER_HIGH : flags;
> ret = regmap_add_irq_chip(..., IRQF_ONESHOT | flags, ...);

The above code works on both 3.18.x and 4.9.

Regards, Magnus

^ permalink raw reply

* [RFC PATCH 4/4] dt-bindings: wp8548: Add on-board NAND flash
From: Zoran Markovic @ 2016-12-22 20:05 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1482437139-29329-1-git-send-email-zmarkovic@sierrawireless.com>

Add description of NAND flash on Sierra Wireless WP8548 module
(and MangOH board).

Cc: Andy Gross <andy.gross@linaro.org>
Cc: David Brown <david.brown@linaro.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: linux-arm-msm at vger.kernel.org
Cc: linux-soc at vger.kernel.org
Cc: devicetree at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Zoran Markovic <zmarkovic@sierrawireless.com>
---
 arch/arm/boot/dts/qcom-mdm9615-wp8548.dtsi |   50 ++++++++++++++++++++++++++++
 1 file changed, 50 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-mdm9615-wp8548.dtsi b/arch/arm/boot/dts/qcom-mdm9615-wp8548.dtsi
index 7869898..a4d1158 100644
--- a/arch/arm/boot/dts/qcom-mdm9615-wp8548.dtsi
+++ b/arch/arm/boot/dts/qcom-mdm9615-wp8548.dtsi
@@ -54,6 +54,56 @@
 	};
 };
 
+&nand0 {
+	nandcs at 0 {
+		compatible = "qcom,nandcs";
+		reg = <0>;
+
+		linux,mtd-name = "micron,mt29f4g08";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		nand-ecc-strength = <4>;
+		nand-ecc-step-size = <512>;
+
+		partitions {
+			compatible = "fixed-partitions";
+			#address-cells = <1>;
+			#size-cells = <1>;
+
+			bootloader at 0x051c0000 {
+				reg = <0x51c0000 0x100000>;
+				read-only;
+			};
+
+			kernel at 0x052c0000 {
+				reg = <0x52c0000 0x1400000>;
+				read-only;
+			};
+
+			rootfs at 0x066c0000 {
+				reg = <0x66c0000 0x3140000>;
+				read-only;
+			};
+
+			user0 at 0x09800000 {
+				reg = <0x9800000 0x2780000>;
+			};
+
+			user1 at 0x0bf80000 {
+				reg = <0xbf80000 0x8B80000>;
+			};
+
+			user2 at 0x14b00000 {
+				reg = <0x14b00000 0x500000>;
+			};
+
+			user3 at 0x15000000 {
+				reg = <0x15000000 0x200000>;
+			};
+		};
+	};
+};
+
 &msmgpio {
 	pinctrl-0 = <&reset_out_pins>;
 	pinctrl-names = "default";
-- 
1.7.9.5

^ permalink raw reply related

* [RFC PATCH 3/4] dt-bindings: mdm9615: Add NAND controller
From: Zoran Markovic @ 2016-12-22 20:05 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1482437139-29329-1-git-send-email-zmarkovic@sierrawireless.com>

Add dt description of NAND controller on MDM9615.

Cc: Andy Gross <andy.gross@linaro.org>
Cc: David Brown <david.brown@linaro.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: linux-arm-msm at vger.kernel.org
Cc: linux-soc at vger.kernel.org
Cc: devicetree at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Zoran Markovic <zmarkovic@sierrawireless.com>
---
 arch/arm/boot/dts/qcom-mdm9615.dtsi |   16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-mdm9615.dtsi b/arch/arm/boot/dts/qcom-mdm9615.dtsi
index fbc7d68..6d42ff3 100644
--- a/arch/arm/boot/dts/qcom-mdm9615.dtsi
+++ b/arch/arm/boot/dts/qcom-mdm9615.dtsi
@@ -373,6 +373,22 @@
 			qcom,ee = <0>;
 		};
 
+		nand0: nand at 1b400000 {
+			compatible = "qcom,ipq806x-nand";
+			reg = <0x1b400000 0x800>;
+			clocks = <&gcc EBI2_CLK>,
+				 <&gcc EBI2_AON_CLK>;
+			clock-names = "core", "aon";
+
+			dmas = <&adm_dma 3>;
+			dma-names = "rxtx";
+			qcom,cmd-crci = <15>;
+			qcom,data-crci = <3>;
+
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
 		amba {
 			compatible = "arm,amba-bus";
 			#address-cells = <1>;
-- 
1.7.9.5

^ permalink raw reply related

* [RFC PATCH 1/4] dt-bindings: mdm9615: Add ADM DMA engine
From: Zoran Markovic @ 2016-12-22 20:05 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1482437139-29329-1-git-send-email-zmarkovic@sierrawireless.com>

Add configuration for ADM DMA engine on MDM9615, used by the EBI2
NAND controller. This commit requires the ADM DMA patches from
Andy Gross:
https://lkml.org/lkml/2015/3/17/19

Cc: Andy Gross <andy.gross@linaro.org>
Cc: David Brown <david.brown@linaro.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: linux-arm-msm at vger.kernel.org
Cc: linux-soc at vger.kernel.org
Cc: devicetree at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Zoran Markovic <zmarkovic@sierrawireless.com>
---
 arch/arm/boot/dts/qcom-mdm9615.dtsi |   19 ++++++++++++++++++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/qcom-mdm9615.dtsi b/arch/arm/boot/dts/qcom-mdm9615.dtsi
index 5ae4ec5..fbc7d68 100644
--- a/arch/arm/boot/dts/qcom-mdm9615.dtsi
+++ b/arch/arm/boot/dts/qcom-mdm9615.dtsi
@@ -336,7 +336,24 @@
 			};
 		};
 
-		sdcc1bam: dma at 12182000{
+		adm_dma: dma at 18300000 {
+			compatible = "qcom,adm";
+			reg = <0x18300000 0x100000>;
+			interrupts = <0 170 0>;
+			#dma-cells = <1>;
+
+			clocks = <&gcc ADM0_CLK>, <&gcc ADM0_PBUS_CLK>;
+			clock-names = "core", "iface";
+
+			resets = <&gcc ADM0_RESET>,
+				 <&gcc ADM0_C0_RESET>,
+				 <&gcc ADM0_C1_RESET>,
+				 <&gcc ADM0_C2_RESET>;
+			reset-names = "clk", "c0", "c1", "c2";
+			qcom,ee = <0>;
+		};
+
+		sdcc1bam:dma at 12182000{
 			compatible = "qcom,bam-v1.3.0";
 			reg = <0x12182000 0x8000>;
 			interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>;
-- 
1.7.9.5

^ permalink raw reply related

* [PATCH v7 3/5] ARM: dts: stm32: Add I2C1 support for STM32F429 SoC
From: Uwe Kleine-König @ 2016-12-22 19:11 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1482413704-17531-4-git-send-email-cedric.madianga@gmail.com>

Hello,

On Thu, Dec 22, 2016 at 02:35:02PM +0100, M'boumba Cedric Madianga wrote:
> @@ -337,6 +350,16 @@
>  					slew-rate = <2>;
>  				};
>  			};
> +
> +			i2c1_pins_b: i2c1 at 0 {
> +				pins1 {
> +					pinmux = <STM32F429_PB9_FUNC_I2C1_SDA>;
> +					drive-open-drain;
> +				};
> +				pins2 {
> +					pinmux = <STM32F429_PB6_FUNC_I2C1_SCL>;
> +				};

the second doesn't need the open-drain property? Why?

> +			};
>  		};

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox