* [PATCH v3 01/17] ASoC: soc-core: adjust for graph on snd_soc_of_parse_card_name
From: Kuninori Morimoto @ 2016-11-11 1:17 UTC (permalink / raw)
To: Rob Herring, Mark Brown
Cc: Linux-ALSA, Liam Girdwood, Simon, Laurent, Guennadi, Grant Likely,
Frank Rowand, Linux-DT, Linux-Kernel
In-Reply-To: <87vavurf4y.wl%kuninori.morimoto.gx@renesas.com>
From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
It is assuming that the card related information is located on
"card" node, but graph case doesn't have it.
This patch adds node parameter to adjust for graph support
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
v2 -> v3
- no change
include/sound/soc.h | 7 +++++--
sound/soc/soc-core.c | 11 ++++++-----
2 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/include/sound/soc.h b/include/sound/soc.h
index 91a8a03..7fff456 100644
--- a/include/sound/soc.h
+++ b/include/sound/soc.h
@@ -1642,8 +1642,11 @@ static inline struct snd_soc_platform *snd_soc_kcontrol_platform(
int snd_soc_util_init(void);
void snd_soc_util_exit(void);
-int snd_soc_of_parse_card_name(struct snd_soc_card *card,
- const char *propname);
+#define snd_soc_of_parse_card_name(card, propname) \
+ snd_soc_of_parse_card_name_from_node(card, NULL, propname)
+int snd_soc_of_parse_card_name_from_node(struct snd_soc_card *card,
+ struct device_node *np,
+ const char *propname);
int snd_soc_of_parse_audio_simple_widgets(struct snd_soc_card *card,
const char *propname);
int snd_soc_of_parse_tdm_slot(struct device_node *np,
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index c0bbcd9..088a158 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -3424,10 +3424,10 @@ void snd_soc_unregister_codec(struct device *dev)
EXPORT_SYMBOL_GPL(snd_soc_unregister_codec);
/* Retrieve a card's name from device tree */
-int snd_soc_of_parse_card_name(struct snd_soc_card *card,
- const char *propname)
+int snd_soc_of_parse_card_name_from_node(struct snd_soc_card *card,
+ struct device_node *np,
+ const char *propname)
{
- struct device_node *np;
int ret;
if (!card->dev) {
@@ -3435,7 +3435,8 @@ int snd_soc_of_parse_card_name(struct snd_soc_card *card,
return -EINVAL;
}
- np = card->dev->of_node;
+ if (!np)
+ np = card->dev->of_node;
ret = of_property_read_string_index(np, propname, 0, &card->name);
/*
@@ -3452,7 +3453,7 @@ int snd_soc_of_parse_card_name(struct snd_soc_card *card,
return 0;
}
-EXPORT_SYMBOL_GPL(snd_soc_of_parse_card_name);
+EXPORT_SYMBOL_GPL(snd_soc_of_parse_card_name_from_node);
static const struct snd_soc_dapm_widget simple_widgets[] = {
SND_SOC_DAPM_MIC("Microphone", NULL),
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v6 4/4] of/fdt: mark hotpluggable memory
From: Balbir Singh @ 2016-11-11 1:17 UTC (permalink / raw)
To: Reza Arbab, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras, Andrew Morton, Rob Herring, Frank Rowand,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin
Cc: linuxppc-dev, linux-mm, devicetree, Bharata B Rao,
Nathan Fontenot, Stewart Smith, Alistair Popple, Aneesh Kumar K.V,
linux-kernel
In-Reply-To: <1478562276-25539-5-git-send-email-arbab@linux.vnet.ibm.com>
On 08/11/16 10:44, Reza Arbab wrote:
> When movable nodes are enabled, any node containing only hotpluggable
> memory is made movable at boot time.
>
> On x86, hotpluggable memory is discovered by parsing the ACPI SRAT,
> making corresponding calls to memblock_mark_hotplug().
>
> If we introduce a dt property to describe memory as hotpluggable,
> configs supporting early fdt may then also do this marking and use
> movable nodes.
>
> Signed-off-by: Reza Arbab <arbab@linux.vnet.ibm.com>
> ---
Tested-by: Balbir Singh <bsingharora@gmail.com>
I tested this with a custom device tree and it worked quite well for me.
It also means that the guest and bare-metal have two different mechanisms
of marking something as hotpluggable. But given that your patch enables
all architectures using OF, it might be worth it.
Balbir Singh.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [PATCH v3 00/17] ASoC: add OF graph base simple-card
From: Kuninori Morimoto @ 2016-11-11 1:16 UTC (permalink / raw)
To: Rob Herring, Mark Brown
Cc: Linux-ALSA, Liam Girdwood, Simon, Laurent, Guennadi, Grant Likely,
Frank Rowand, Linux-DT, Linux-Kernel
Hi Rob, Mark
These are v3 of OF graph base simple-card patch-set.
1) - 5) : soc-core prepare for OF graph base simple-card
6) - 10) : OF graph new feature
11) - 17) : OF graph base simple-card (depends on above 2 patch-set)
>> Mark
I could success to apply 1) - 5) on your topic/core and topic/simple, both.
Please let me know if you can't do it.
*** BLURB HERE ***
Kuninori Morimoto (17):
1) ASoC: soc-core: adjust for graph on snd_soc_of_parse_card_name
2) ASoC: soc-core: adjust for graph on snd_soc_of_parse_audio_simple_widgets
3) ASoC: soc-core: adjust for graph on snd_soc_of_parse_audio_routing
4) ASoC: soc-core: adjust for graph on snd_soc_of_parse_audio_prefix
5) ASoC: soc-core: snd_soc_get_dai_name() become non static
6) of_graph: add of_graph_get_remote_endpoint()
7) of_graph: add of_graph_get_port_parent()
8) of_graph: add of_graph_get_top_port()
9) of_graph: add for_each_of_port() / for_each_of_endpoint_in_port()
10) of_graph: add of_graph_get_port/endpoint_count()
11) ASoC: simple-card-utils: add asoc_simple_card_parse_graph_dai()
12) ASoC: simple-card-utils: add asoc_simple_card_try_to_probe_graph_card()
13) ASoC: simple-card-utils: adjust for graph on asoc_simple_card_parse_card_name
14) ASoC: add simple-graph-card document
15) ASoC: add simple-graph-card support
16) ASoC: add simple-graph-scu-card document
17) ASoC: add simple-graph-scu-card support
.../bindings/sound/simple-graph-card.txt | 65 +++
.../bindings/sound/simple-graph-scu-card.txt | 65 +++
drivers/of/base.c | 160 ++++++-
include/linux/of_graph.h | 54 +++
include/sound/simple_card_utils.h | 19 +
include/sound/soc.h | 32 +-
sound/soc/generic/Kconfig | 15 +
sound/soc/generic/Makefile | 4 +
sound/soc/generic/simple-card-utils.c | 98 ++++-
sound/soc/generic/simple-card.c | 2 +-
sound/soc/generic/simple-graph-card.c | 462 +++++++++++++++++++++
sound/soc/generic/simple-graph-scu-card.c | 417 +++++++++++++++++++
sound/soc/generic/simple-scu-card.c | 2 +-
sound/soc/soc-core.c | 41 +-
14 files changed, 1401 insertions(+), 35 deletions(-)
create mode 100644 Documentation/devicetree/bindings/sound/simple-graph-card.txt
create mode 100644 Documentation/devicetree/bindings/sound/simple-graph-scu-card.txt
create mode 100644 sound/soc/generic/simple-graph-card.c
create mode 100644 sound/soc/generic/simple-graph-scu-card.c
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v9 2/8] power: add power sequence library
From: Rafael J. Wysocki @ 2016-11-11 1:05 UTC (permalink / raw)
To: Peter Chen
Cc: Greg Kroah-Hartman, Alan Stern, Ulf Hansson, Mark Brown,
Sebastian Reichel, Rob Herring, Shawn Guo, Rafael J. Wysocki,
Dmitry Eremin-Solenikov, Heiko Stuebner,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Pawel Moll,
Mark Rutland, open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
Arnd Bergmann, Sascha Hauer
In-Reply-To: <1478573472-29516-3-git-send-email-peter.chen-3arQi8VN3Tc@public.gmane.org>
On Tue, Nov 8, 2016 at 3:51 AM, Peter Chen <peter.chen-3arQi8VN3Tc@public.gmane.org> wrote:
> We have an well-known problem that the device needs to do some power
> sequence before it can be recognized by related host, the typical
> example like hard-wired mmc devices and usb devices.
>
> This power sequence is hard to be described at device tree and handled by
> related host driver, so we have created a common power sequence
> library to cover this requirement. The core code has supplied
> some common helpers for host driver, and individual power sequence
> libraries handle kinds of power sequence for devices. The pwrseq
> librares always need to allocate extra instance for compatible
> string match.
>
> pwrseq_generic is intended for general purpose of power sequence, which
> handles gpios and clocks currently, and can cover other controls in
> future. The host driver just needs to call of_pwrseq_on/of_pwrseq_off
> if only one power sequence is needed, else call of_pwrseq_on_list
> /of_pwrseq_off_list instead (eg, USB hub driver).
>
> For new power sequence library, it can add its compatible string
> to pwrseq_of_match_table, then the pwrseq core will match it with
> DT's, and choose this library at runtime.
In the first place, please document this stuff better than you have so
far. To a minimum, add kerneldoc comments to all new non-trivial new
functions to document what they are for and how they are expected to
be used (especially the ones exported to drivers).
Also, is there any guidance available for people who may want to use it?
> Signed-off-by: Peter Chen <peter.chen-3arQi8VN3Tc@public.gmane.org>
> Tested-by: Maciej S. Szmigiero <mail-APzI5cXaD1zVlRWJc41N0YvC60bnQu0Y@public.gmane.org>
> Tested-by Joshua Clayton <stillcompiling-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Reviewed-by: Matthias Kaehlcke <mka-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> Tested-by: Matthias Kaehlcke <mka-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> ---
> MAINTAINERS | 9 ++
> drivers/power/Kconfig | 1 +
> drivers/power/Makefile | 1 +
> drivers/power/pwrseq/Kconfig | 19 ++++
> drivers/power/pwrseq/Makefile | 2 +
> drivers/power/pwrseq/core.c | 191 ++++++++++++++++++++++++++++++++++
> drivers/power/pwrseq/pwrseq_generic.c | 183 ++++++++++++++++++++++++++++++++
> include/linux/power/pwrseq.h | 72 +++++++++++++
> 8 files changed, 478 insertions(+)
> create mode 100644 drivers/power/pwrseq/Kconfig
> create mode 100644 drivers/power/pwrseq/Makefile
> create mode 100644 drivers/power/pwrseq/core.c
> create mode 100644 drivers/power/pwrseq/pwrseq_generic.c
> create mode 100644 include/linux/power/pwrseq.h
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 1cd38a7..5dab975 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -9612,6 +9612,15 @@ F: include/linux/pm_*
> F: include/linux/powercap.h
> F: drivers/powercap/
>
> +POWER SEQUENCE LIBRARY
> +M: Peter Chen <Peter.Chen-3arQi8VN3Tc@public.gmane.org>
> +T: git git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb.git
> +L: linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> +S: Maintained
> +F: Documentation/devicetree/bindings/power/pwrseq/
> +F: drivers/power/pwrseq/
> +F: include/linux/power/pwrseq.h/
> +
> POWER SUPPLY CLASS/SUBSYSTEM and DRIVERS
> M: Sebastian Reichel <sre-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> L: linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
> index 63454b5..c1bb046 100644
> --- a/drivers/power/Kconfig
> +++ b/drivers/power/Kconfig
> @@ -1,3 +1,4 @@
> source "drivers/power/avs/Kconfig"
> source "drivers/power/reset/Kconfig"
> source "drivers/power/supply/Kconfig"
> +source "drivers/power/pwrseq/Kconfig"
> diff --git a/drivers/power/Makefile b/drivers/power/Makefile
> index ff35c71..7db8035 100644
> --- a/drivers/power/Makefile
> +++ b/drivers/power/Makefile
> @@ -1,3 +1,4 @@
> obj-$(CONFIG_POWER_AVS) += avs/
> obj-$(CONFIG_POWER_RESET) += reset/
> obj-$(CONFIG_POWER_SUPPLY) += supply/
> +obj-$(CONFIG_POWER_SEQUENCE) += pwrseq/
> diff --git a/drivers/power/pwrseq/Kconfig b/drivers/power/pwrseq/Kconfig
> new file mode 100644
> index 0000000..3859a67
> --- /dev/null
> +++ b/drivers/power/pwrseq/Kconfig
> @@ -0,0 +1,19 @@
> +#
> +# Power Sequence library
> +#
> +
> +config POWER_SEQUENCE
> + bool
> +
> +menu "Power Sequence Support"
> +
> +config PWRSEQ_GENERIC
> + bool "Generic power sequence control"
> + depends on OF
> + select POWER_SEQUENCE
> + help
> + It is used for drivers which needs to do power sequence
> + (eg, turn on clock, toggle reset gpio) before the related
> + devices can be found by hardware. This generic one can be
> + used for common power sequence control.
I wouldn't set it up this way.
There are two problems here.
First, say a distro is going to ship a multiplatform generic kernel.
How they are going to figure out whether or not to set the new symbol
in that kernel?
Second, how users are supposed to know whether or not they will need
it even if they build the kernel by themselves?
It would be better IMO to set things up to select the new symbol from
places making use of the code depending on it.
Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v9 1/3] clk: qcom: Add support for SMD-RPM Clocks
From: Stephen Boyd @ 2016-11-11 0:48 UTC (permalink / raw)
To: Georgi Djakov
Cc: mturquette, linux-clk, devicetree, robh+dt, mark.rutland,
linux-kernel, linux-arm-msm
In-Reply-To: <20161102155658.32203-2-georgi.djakov@linaro.org>
On 11/02, Georgi Djakov wrote:
> This adds initial support for clocks controlled by the Resource
> Power Manager (RPM) processor on some Qualcomm SoCs, which use
> the qcom_smd_rpm driver to communicate with RPM.
> Such platforms are msm8916, apq8084 and msm8974.
>
> The RPM is a dedicated hardware engine for managing the shared
> SoC resources in order to keep the lowest power profile. It
> communicates with other hardware subsystems via shared memory
> and accepts clock requests, aggregates the requests and turns
> the clocks on/off or scales them on demand.
>
> This driver is based on the codeaurora.org driver:
> https://www.codeaurora.org/cgit/quic/la/kernel/msm-3.10/tree/drivers/clk/qcom/clock-rpm.c
>
> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
> ---
Applied to clk-qcom-rpm and merged into clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v9 2/3] clk: qcom: Add support for RPM Clocks
From: Stephen Boyd @ 2016-11-11 0:48 UTC (permalink / raw)
To: Georgi Djakov
Cc: mturquette, linux-clk, devicetree, robh+dt, mark.rutland,
linux-kernel, linux-arm-msm
In-Reply-To: <20161102155658.32203-3-georgi.djakov@linaro.org>
On 11/02, Georgi Djakov wrote:
> This adds initial support for clocks controlled by the Resource
> Power Manager (RPM) processor on some Qualcomm SoCs, which use
> the qcom_rpm driver to communicate with RPM.
> Such platforms are apq8064 and msm8960.
>
> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
> ---
Applied to clk-qcom-rpm and merged into clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v9 3/3] clk: qcom: Always add factor clock for xo clocks
From: Stephen Boyd @ 2016-11-11 0:48 UTC (permalink / raw)
To: Georgi Djakov
Cc: mturquette-rdvid1DuHRBWk0Htik3J/w,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161102155658.32203-4-georgi.djakov-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On 11/02, Georgi Djakov wrote:
> Currently the RPM/RPM-SMD clock drivers do not register the xo clocks,
> so we should always add factor clock. When we later add xo clocks support
> into the drivers, we should update this function to skip registration.
> By doing so we avoid any DT dependencies.
>
> Signed-off-by: Georgi Djakov <georgi.djakov-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
Applied to clk-qcom-rpm and merged into clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCHv3 2/2] gpio: xilinx: Add clock support
From: Sören Brinkmann @ 2016-11-11 0:42 UTC (permalink / raw)
To: Shubhrajyoti Datta
Cc: linux-gpio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
michal.simek-gjFFaj9aHVfQT0dZR+AlfA,
shubhrajyoti.datta-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <1478757365-3311-2-git-send-email-shubhrajyoti.datta-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>
On Thu, 2016-11-10 at 11:26:05 +0530, Shubhrajyoti Datta wrote:
> Add basic clock support for xilinx gpio.
>
> Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>
> ---
> v2 :
> no change
> v3:
> Add clock name
> Remove some debug messages
>
> drivers/gpio/gpio-xilinx.c | 20 ++++++++++++++++++++
> 1 files changed, 20 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpio/gpio-xilinx.c b/drivers/gpio/gpio-xilinx.c
> index 14b2a62..3385a0a 100644
> --- a/drivers/gpio/gpio-xilinx.c
> +++ b/drivers/gpio/gpio-xilinx.c
> @@ -13,6 +13,7 @@
> */
>
> #include <linux/bitops.h>
> +#include <linux/clk.h>
> #include <linux/init.h>
> #include <linux/errno.h>
> #include <linux/module.h>
> @@ -45,6 +46,7 @@
> * @gpio_state: GPIO state shadow register
> * @gpio_dir: GPIO direction shadow register
> * @gpio_lock: Lock used for synchronization
> + * @clk: Clock resource for this controller
> */
> struct xgpio_instance {
> struct of_mm_gpio_chip mmchip;
> @@ -52,6 +54,7 @@ struct xgpio_instance {
> u32 gpio_state[2];
> u32 gpio_dir[2];
> spinlock_t gpio_lock[2];
> + struct clk *clk;
> };
>
> static inline int xgpio_index(struct xgpio_instance *chip, int gpio)
> @@ -282,6 +285,7 @@ static int xgpio_remove(struct platform_device *pdev)
> struct xgpio_instance *chip = platform_get_drvdata(pdev);
>
> of_mm_gpiochip_remove(&chip->mmchip);
> + clk_disable_unprepare(chip->clk);
>
> return 0;
> }
> @@ -307,6 +311,21 @@ static int xgpio_probe(struct platform_device *pdev)
>
> platform_set_drvdata(pdev, chip);
>
> + /* Retrieve GPIO clock */
> + chip->clk = devm_clk_get(&pdev->dev, "s_axi_aclk");
> + if (IS_ERR(chip->clk)) {
> + if (PTR_ERR(chip->clk) == -ENOENT)
> + chip->clk = NULL;
> + else
> + return PTR_ERR(chip->clk);
I personally would have kept the error message to give users a hint
why/what failed.
Acked-by: Sören Brinkmann <soren.brinkmann-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>
Sören
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCHv3 1/2] gpio: xilinx: dt-binding: Add clock node
From: Sören Brinkmann @ 2016-11-11 0:41 UTC (permalink / raw)
To: Shubhrajyoti Datta
Cc: linux-gpio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
michal.simek-gjFFaj9aHVfQT0dZR+AlfA,
shubhrajyoti.datta-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <1478757365-3311-1-git-send-email-shubhrajyoti.datta-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>
On Thu, 2016-11-10 at 11:26:04 +0530, Shubhrajyoti Datta wrote:
> Add the clock node to the dt binding.
>
> Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>
> ---
> v2:
> Make clocks optional
> Add clock name
> v3:
> No change
>
> .../devicetree/bindings/gpio/gpio-xilinx.txt | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/gpio/gpio-xilinx.txt b/Documentation/devicetree/bindings/gpio/gpio-xilinx.txt
> index 63bf4be..1372007 100644
> --- a/Documentation/devicetree/bindings/gpio/gpio-xilinx.txt
> +++ b/Documentation/devicetree/bindings/gpio/gpio-xilinx.txt
> @@ -25,12 +25,16 @@ Optional properties:
> - xlnx,dout-default-2 : as above but the second channel
> - xlnx,gpio2-width : as above but for the second channel
> - xlnx,tri-default-2 : as above but for the second channel
> +- clocks: Input clock specifier. Refer to common clock bindings.
> +- clock-names: Input clock name, should be s_axi_aclk.
I don't know if there is a good way to tell that 'clock-names' is
required when 'clocks' is specified. Probably just nice to have.
Acked-by: Sören Brinkmann <soren.brinkmann-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>
Sören
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] lm87: Allow LM87_REG_CHANNEL_MODE to be set via DT
From: Jason Gunthorpe @ 2016-11-11 0:31 UTC (permalink / raw)
To: Guenter Roeck, Mahoda Ratnayaka; +Cc: devicetree, linux-kernel, linux-hwmon
In-Reply-To: <20161110234707.GA14199@roeck-us.net>
On Thu, Nov 10, 2016 at 03:47:07PM -0800, Guenter Roeck wrote:
> On Thu, Nov 10, 2016 at 10:19:36AM -0700, Jason Gunthorpe wrote:
> > This compliments the existing scheme that lets it be set via
> > platform_data.
> >
> > Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
>
> I would prefer https://www.spinics.net/lists/devicetree/msg148819.html
> which appears to address the same problem and is less cryptic.
Is there a patch someplace that implements that proposed DT binding? I
couldn't find anything.
> NACK unless someone convinces me otherwise.
*shrug* both styles of definition seem to be used in various device
tree bindings.
The downside with Mahoda's proposal is that it only covers 3 of the 8
configuration bits, and will require alot of code for parsing. It
seems really clunky, and why is a regulator involved to set the A/D
sensitivity? Weird.
But I only need has-temp3, so if a patch appears please cc me and I'll
review it here..
Regards,
Jason
^ permalink raw reply
* Re: [PATCH] lm87: Allow LM87_REG_CHANNEL_MODE to be set via DT
From: Guenter Roeck @ 2016-11-10 23:47 UTC (permalink / raw)
To: Jason Gunthorpe; +Cc: devicetree, linux-kernel, linux-hwmon
In-Reply-To: <20161110171936.GA29537@obsidianresearch.com>
On Thu, Nov 10, 2016 at 10:19:36AM -0700, Jason Gunthorpe wrote:
> This compliments the existing scheme that lets it be set via
> platform_data.
>
> Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
I would prefer https://www.spinics.net/lists/devicetree/msg148819.html
which appears to address the same problem and is less cryptic.
NACK unless someone convinces me otherwise.
Guenter
> ---
> Documentation/devicetree/bindings/hwmon/lm87.txt | 27 ++++++++++++++++++++++++
> drivers/hwmon/lm87.c | 8 ++++++-
> 2 files changed, 34 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/devicetree/bindings/hwmon/lm87.txt
>
> diff --git a/Documentation/devicetree/bindings/hwmon/lm87.txt b/Documentation/devicetree/bindings/hwmon/lm87.txt
> new file mode 100644
> index 00000000000000..4ea2646ce8d2f0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/lm87.txt
> @@ -0,0 +1,27 @@
> +* LM87 I2C Temperature and Fan sensor
> +
> +Required properties:
> +- compatible: should contain one of
> + * "national,lm87"
> + * "ti,lm87"
> +
> +Optional properties:
> +- channel-mode: Write the specified value to register 0x16. If not specified
> + the driver will read the value from the chip at startup.
> +
> + The value controls how the driver operates certain multi-use
> + pins, eg bit 2 will select between temp_input3 or
> + in0&in5 operation.
> +
> +See Documentation/devicetree/bindings/i2c/i2c.txt for more required and
> +optional properties.
> +
> +Example:
> +
> +i2c_master {
> + temperature-sensor@0 {
> + compatible = "ti,lm87";
> + channel-mode = <0x4>;
> + reg = <0>;
> + };
> +};
> diff --git a/drivers/hwmon/lm87.c b/drivers/hwmon/lm87.c
> index 81cb898245a107..ccc0c913b4534e 100644
> --- a/drivers/hwmon/lm87.c
> +++ b/drivers/hwmon/lm87.c
> @@ -853,9 +853,15 @@ static void lm87_restore_config(void *arg)
> static int lm87_init_client(struct i2c_client *client)
> {
> struct lm87_data *data = i2c_get_clientdata(client);
> + u32 channel;
> int rc;
>
> - if (dev_get_platdata(&client->dev)) {
> + if (client->dev.of_node &&
> + !of_property_read_u32(client->dev.of_node, "channel-mode",
> + &channel)) {
> + data->channel = channel;
> + lm87_write_value(client, LM87_REG_CHANNEL_MODE, data->channel);
> + } else if (dev_get_platdata(&client->dev)) {
> data->channel = *(u8 *)dev_get_platdata(&client->dev);
> lm87_write_value(client,
> LM87_REG_CHANNEL_MODE, data->channel);
> --
> 2.7.4
^ permalink raw reply
* Re: [PATCH V6 2/6] dt-bindings: qcom: clocks: Add msm8994 clock bindings
From: Jeremy McNicoll @ 2016-11-10 22:51 UTC (permalink / raw)
To: Stephen Boyd, Jeremy McNicoll
Cc: linux-arm-msm, linux-soc, devicetree, robh, andy.gross, mail,
arnd, bjorn.andersson, mark.rutland, michael.scott
In-Reply-To: <20161110223133.GI16026@codeaurora.org>
On 2016-11-10 2:31 PM, Stephen Boyd wrote:
> On 11/04, Jeremy McNicoll wrote:
>> Signed-off-by: Jeremy McNicoll <jeremymc@redhat.com>
>> ---
>
> Applied to clk-qcom-8994 in clk tree.
>
>> +
>> +/* Indexes for GDSCs */
>> +#define BIMC_GDSC 0
>> +#define VENUS_GDSC 1
>> +#define MDSS_GDSC 2
>> +#define JPEG_GDSC 3
>> +#define VFE_GDSC 4
>> +#define OXILI_GDSC 5
>> +
>
> But I removed these because it's copy/paste from 8916 and that is
> a different family of chips than 8994 so these GDSCs aren't in
> GCC on 8994.
>
Thanks for taking care of this.
-jeremy
^ permalink raw reply
* Re: [PATCH V3 1/9] PM / OPP: Reword binding supporting multiple regulators per device
From: Stephen Boyd @ 2016-11-10 22:51 UTC (permalink / raw)
To: Viresh Kumar
Cc: Mark Brown, Rafael Wysocki, nm, Viresh Kumar, linaro-kernel,
linux-pm, linux-kernel, Vincent Guittot, robh, d-gerlach,
devicetree
In-Reply-To: <20161110180940.GD11670@vireshk-i7>
On 11/10, Viresh Kumar wrote:
> On 10-11-16, 16:36, Mark Brown wrote:
> > On Thu, Nov 10, 2016 at 09:34:40AM +0530, Viresh Kumar wrote:
> > > On 09-11-16, 14:58, Mark Brown wrote:
> > > > On Wed, Oct 26, 2016 at 12:02:56PM +0530, Viresh Kumar wrote:
> >
> > > > > + Entries for multiple regulators shall be provided in the same field separated
> > > > > + by angular brackets <>. The OPP binding doesn't provide any provisions to
> > > > > + relate the values to their power supplies or the order in which the supplies
> > > > > + need to be configured.
> >
> > > > I don't understand how this works. If we have an unordered list of
> > > > values to set for regulators how will we make sense of them?
> >
> > > The platform driver is responsible to identify the order and pass it on to the
> > > OPP core. And the platform driver needs to have that hard coded.
> >
> > That *really* should be in the binding.
>
> Okay, how do you suggest doing that? Will a property like supply-names
> in the OPP table be fine? Like this:
>
> @@ -369,13 +378,16 @@ Example 4: Handling multiple regulators
> compatible = "arm,cortex-a7";
> ...
>
> - cpu-supply = <&cpu_supply0>, <&cpu_supply1>, <&cpu_supply2>;
> + vcc0-supply = <&cpu_supply0>;
> + vcc1-supply = <&cpu_supply1>;
> + vcc2-supply = <&cpu_supply2>;
> operating-points-v2 = <&cpu0_opp_table>;
> };
> };
>
> cpu0_opp_table: opp_table0 {
> compatible = "operating-points-v2";
> + supply-names = "vcc0", "vcc1", "vcc2";
> opp-shared;
>
No. The supply names (and also clock names/index) should be left
up to the consumer of the OPP table. We don't want to encode any
sort of details like this between the OPP table and the consumer
of it in DT because then it seriously couples the OPP table to
the consumer device. "The binding" in this case that needs to be
updated is the consumer binding, to indicate that it correlated
foo-supply and bar-supply to index 0 and 1 of the OPP table
voltages.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH V6 5/6] msm8994 clocks: global clock support for msm8994 SOC.
From: Stephen Boyd @ 2016-11-10 22:31 UTC (permalink / raw)
To: Jeremy McNicoll
Cc: linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
linux-soc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, robh-DgEjT+Ai2ygdnm+yROfE0A,
andy.gross-QSEj5FYQhm4dnm+yROfE0A, mail-LJ92rlH3Dns,
arnd-r2nGTMty4D4, bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, michael.scott-QSEj5FYQhm4dnm+yROfE0A
In-Reply-To: <1478292996-29559-6-git-send-email-jeremymc-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On 11/04, Jeremy McNicoll wrote:
> From: Bastian Köcher <mail-LJ92rlH3Dns@public.gmane.org>
>
> The clock definition was ported from the Google 3.10 kernel tree to
> work with the latest kernel.
>
> Signed-off-by: Bastian Köcher <mail-LJ92rlH3Dns@public.gmane.org>
> [jeremymc-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org: created new commit of just dt-bindings]
> Signed-off-by: Jeremy McNicoll <jeremymc-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> ---
Applied to clk-qcom-8994 in clk tree
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V6 2/6] dt-bindings: qcom: clocks: Add msm8994 clock bindings
From: Stephen Boyd @ 2016-11-10 22:31 UTC (permalink / raw)
To: Jeremy McNicoll
Cc: linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
linux-soc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, robh-DgEjT+Ai2ygdnm+yROfE0A,
andy.gross-QSEj5FYQhm4dnm+yROfE0A, mail-LJ92rlH3Dns,
arnd-r2nGTMty4D4, bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, michael.scott-QSEj5FYQhm4dnm+yROfE0A
In-Reply-To: <1478292996-29559-3-git-send-email-jeremymc-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On 11/04, Jeremy McNicoll wrote:
> Signed-off-by: Jeremy McNicoll <jeremymc-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> ---
Applied to clk-qcom-8994 in clk tree.
> +
> +/* Indexes for GDSCs */
> +#define BIMC_GDSC 0
> +#define VENUS_GDSC 1
> +#define MDSS_GDSC 2
> +#define JPEG_GDSC 3
> +#define VFE_GDSC 4
> +#define OXILI_GDSC 5
> +
But I removed these because it's copy/paste from 8916 and that is
a different family of chips than 8994 so these GDSCs aren't in
GCC on 8994.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 2/2] mmc: sdhci-iproc: support standard byte register accesses
From: Ulf Hansson @ 2016-11-10 22:21 UTC (permalink / raw)
To: Scott Branden
Cc: Rob Herring, Mark Rutland, Ray Jui, Scott Branden, Adrian Hunter,
BCM Kernel Feedback, linux-mmc, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Srinath Mannam
In-Reply-To: <1478018277-10097-3-git-send-email-scott.branden@broadcom.com>
On 1 November 2016 at 17:37, Scott Branden <scott.branden@broadcom.com> wrote:
> Add bytewise register accesses support for newer versions of IPROC
> SDHCI controllers.
> Previous sdhci-iproc versions of SDIO controllers
> (such as Raspberry Pi and Cygnus) only allowed for 32-bit register
> accesses.
>
> Signed-off-by: Srinath Mannam <srinath.mannam@broadcom.com>
> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
Thanks, applied for next!
Kind regards
Uffe
> ---
> drivers/mmc/host/sdhci-iproc.c | 35 +++++++++++++++++++++++++++++++++--
> 1 file changed, 33 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-iproc.c b/drivers/mmc/host/sdhci-iproc.c
> index 7262466..d7046d6 100644
> --- a/drivers/mmc/host/sdhci-iproc.c
> +++ b/drivers/mmc/host/sdhci-iproc.c
> @@ -143,6 +143,14 @@ static void sdhci_iproc_writeb(struct sdhci_host *host, u8 val, int reg)
> }
>
> static const struct sdhci_ops sdhci_iproc_ops = {
> + .set_clock = sdhci_set_clock,
> + .get_max_clock = sdhci_pltfm_clk_get_max_clock,
> + .set_bus_width = sdhci_set_bus_width,
> + .reset = sdhci_reset,
> + .set_uhs_signaling = sdhci_set_uhs_signaling,
> +};
> +
> +static const struct sdhci_ops sdhci_iproc_32only_ops = {
> .read_l = sdhci_iproc_readl,
> .read_w = sdhci_iproc_readw,
> .read_b = sdhci_iproc_readb,
> @@ -156,6 +164,28 @@ static const struct sdhci_ops sdhci_iproc_ops = {
> .set_uhs_signaling = sdhci_set_uhs_signaling,
> };
>
> +static const struct sdhci_pltfm_data sdhci_iproc_cygnus_pltfm_data = {
> + .quirks = SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK,
> + .quirks2 = SDHCI_QUIRK2_ACMD23_BROKEN,
> + .ops = &sdhci_iproc_32only_ops,
> +};
> +
> +static const struct sdhci_iproc_data iproc_cygnus_data = {
> + .pdata = &sdhci_iproc_cygnus_pltfm_data,
> + .caps = ((0x1 << SDHCI_MAX_BLOCK_SHIFT)
> + & SDHCI_MAX_BLOCK_MASK) |
> + SDHCI_CAN_VDD_330 |
> + SDHCI_CAN_VDD_180 |
> + SDHCI_CAN_DO_SUSPEND |
> + SDHCI_CAN_DO_HISPD |
> + SDHCI_CAN_DO_ADMA2 |
> + SDHCI_CAN_DO_SDMA,
> + .caps1 = SDHCI_DRIVER_TYPE_C |
> + SDHCI_DRIVER_TYPE_D |
> + SDHCI_SUPPORT_DDR50,
> + .mmc_caps = MMC_CAP_1_8V_DDR,
> +};
> +
> static const struct sdhci_pltfm_data sdhci_iproc_pltfm_data = {
> .quirks = SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK,
> .quirks2 = SDHCI_QUIRK2_ACMD23_BROKEN,
> @@ -182,7 +212,7 @@ static const struct sdhci_pltfm_data sdhci_bcm2835_pltfm_data = {
> .quirks = SDHCI_QUIRK_BROKEN_CARD_DETECTION |
> SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK |
> SDHCI_QUIRK_MISSING_CAPS,
> - .ops = &sdhci_iproc_ops,
> + .ops = &sdhci_iproc_32only_ops,
> };
>
> static const struct sdhci_iproc_data bcm2835_data = {
> @@ -194,7 +224,8 @@ static const struct sdhci_iproc_data bcm2835_data = {
>
> static const struct of_device_id sdhci_iproc_of_match[] = {
> { .compatible = "brcm,bcm2835-sdhci", .data = &bcm2835_data },
> - { .compatible = "brcm,sdhci-iproc-cygnus", .data = &iproc_data },
> + { .compatible = "brcm,sdhci-iproc-cygnus", .data = &iproc_cygnus_data},
> + { .compatible = "brcm,sdhci-iproc", .data = &iproc_data },
> { }
> };
> MODULE_DEVICE_TABLE(of, sdhci_iproc_of_match);
> --
> 2.5.0
>
^ permalink raw reply
* Re: [PATCH v2 1/2] mmc: sdhci-iproc: Add brcm,sdhci-iproc compat string in bindings document
From: Ulf Hansson @ 2016-11-10 22:21 UTC (permalink / raw)
To: Scott Branden
Cc: Rob Herring, Mark Rutland, Ray Jui, Scott Branden, Adrian Hunter,
BCM Kernel Feedback, linux-mmc, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Anup Patel
In-Reply-To: <1478018277-10097-2-git-send-email-scott.branden@broadcom.com>
On 1 November 2016 at 17:37, Scott Branden <scott.branden@broadcom.com> wrote:
> Adds brcm,sdhci-iproc compat string to DT bindings document for
> the iProc SDHCI driver.
>
> Signed-off-by: Anup Patel <anup.patel@broadcom.com>
> Signed-off-by: Scott Branden <scott.branden@broadcom.com>
Thanks, applied for next!
Kind regards
Uffe
> ---
> Documentation/devicetree/bindings/mmc/brcm,sdhci-iproc.txt | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mmc/brcm,sdhci-iproc.txt b/Documentation/devicetree/bindings/mmc/brcm,sdhci-iproc.txt
> index be56d2b..954561d 100644
> --- a/Documentation/devicetree/bindings/mmc/brcm,sdhci-iproc.txt
> +++ b/Documentation/devicetree/bindings/mmc/brcm,sdhci-iproc.txt
> @@ -7,6 +7,15 @@ Required properties:
> - compatible : Should be one of the following
> "brcm,bcm2835-sdhci"
> "brcm,sdhci-iproc-cygnus"
> + "brcm,sdhci-iproc"
> +
> +Use brcm2835-sdhci for Rasperry PI.
> +
> +Use sdhci-iproc-cygnus for Broadcom SDHCI Controllers
> +restricted to 32bit host accesses to SDHCI registers.
> +
> +Use sdhci-iproc for Broadcom SDHCI Controllers that allow standard
> +8, 16, 32-bit host access to SDHCI register.
>
> - clocks : The clock feeding the SDHCI controller.
>
> --
> 2.5.0
>
^ permalink raw reply
* Re: [PATCH v5 02/23] of: device: Export of_device_{get_modalias, uvent_modalias} to modules
From: Rob Herring @ 2016-11-10 21:42 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Peter Chen, Stephen Boyd, Greg KH, Arnd Bergmann, Neil Armstrong,
linux-arm-msm, linux-usb, linux-kernel, Bjorn Andersson,
Peter Chen, linux-arm-kernel, Andy Gross, devicetree,
Felipe Balbi
In-Reply-To: <CAGb2v66C15fU1b2+xNDV8Fv2kmmKXyUknA8=9wXztUcs8CNKLg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Sun, Nov 6, 2016 at 7:56 PM, Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org> wrote:
> On Mon, Nov 7, 2016 at 9:29 AM, Peter Chen <hzpeterchen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> On Fri, Nov 04, 2016 at 01:51:34PM -0700, Stephen Boyd wrote:
>>> Quoting Peter Chen (2016-10-24 18:16:32)
>>> > On Mon, Oct 24, 2016 at 12:48:24PM -0700, Stephen Boyd wrote:
>>> > > Quoting Chen-Yu Tsai (2016-10-24 05:19:05)
>>> > > > Hi,
>>> > > >
>>> > > > On Tue, Oct 18, 2016 at 9:56 AM, Stephen Boyd <stephen.boyd-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>>> > > > > The ULPI bus can be built as a module, and it will soon be
>>> > > > > calling these functions when it supports probing devices from DT.
>>> > > > > Export them so they can be used by the ULPI module.
>>> > > > >
>>> > > > > Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>> > > > > Cc: <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
>>> > > > > Signed-off-by: Stephen Boyd <stephen.boyd-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>>> > > > > ---
>>> > > > > drivers/of/device.c | 2 ++
>>> > > > > 1 file changed, 2 insertions(+)
>>> > > > >
>>> > > > > diff --git a/drivers/of/device.c b/drivers/of/device.c
>>> > > > > index 8a22a253a830..6719ab35b62e 100644
>>> > > > > --- a/drivers/of/device.c
>>> > > > > +++ b/drivers/of/device.c
>>> > > > > @@ -225,6 +225,7 @@ ssize_t of_device_get_modalias(struct device *dev, char *str, ssize_t len)
>>> > > > >
>>> > > > > return tsize;
>>> > > > > }
>>> > > > > +EXPORT_SYMBOL_GPL(of_device_get_modalias);
>>> > > > >
>>> > > > > int of_device_request_module(struct device *dev)
>>> > > > > {
>>> > > > > @@ -290,6 +291,7 @@ void of_device_uevent(struct device *dev, struct kobj_uevent_env *env)
>>> > > > > }
>>> > > > > mutex_unlock(&of_mutex);
>>> > > > > }
>>> > > > > +EXPORT_SYMBOL_GPL(of_device_uevent_modalias);
>>> > > >
>>> > > > This is trailing the wrong function.
>>> > > >
>>> > >
>>> > > Good catch. Must have been some bad rebase.
>>> > >
>>> > > Peter, can you fix it while applying or should I resend this patch?
>>> > >
>>> >
>>> > But, this is device tree patch. I can only get chipidea part and other
>>> > USB patches if Greg agrees.
>>> >
>>>
>>> Were you expecting Rob to take the drivers/of/* patches? Sorry I thought
>>> Rob acked them so they could go through usb with the other changes.
>>
>> I am just worried about possible merge error when linus pulls both OF
>> and USB tree. Greg, is it ok the OF patches through USB tree with OF
>> maintainer's ack?
>
> May I suggest putting the OF patches on an immutable branch so other
> subsystems can pull them in without pulling in the USB patches? At
> least I want to use them in the I2C subsystem, and in the sunxi-rsb
> driver.
Do you have patches using this already. If not, it is starting to get
a bit late for v4.10.
I can apply this, but then you'll just be pulling in other DT patches.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] of/irq: improve error message on irq discovery process failure
From: Benjamin Herrenschmidt @ 2016-11-10 21:30 UTC (permalink / raw)
To: Mark Rutland, Guilherme G. Piccoli
Cc: devicetree, marc.zyngier, frowand.list, robh+dt, linux-pci,
linuxppc-dev
In-Reply-To: <20161109190457.GC837@leverpostej>
On Wed, 2016-11-09 at 19:04 +0000, Mark Rutland wrote:
>
>
> If we don't have an interrupt-map on a PCI controller, why don't we
> instead log a message regarding that being missing, and give up
> early?
Why ? It's legit to not support LSIs.
> That sounds like a more generically useful error message; it's also
> possible that a DT author simply forgot to add the map, and the
> platform has suitable interrupts wired up.
But it's not necessarily an error...
> > This patch introduces a different message for this specific case,
> > and it also reduces the level of the message from error to warning.
> > Before this patch, when an adapter was plugged in a slot without
> Level
> > interrupts capabilities, we saw generic error messages like this:
> >
> > [54.239] pci 002d:70:00.0: of_irq_parse_pci() failed with rc=-
> 22
> >
> > Now, with this applied, we see the following specific message:
> >
> > [19.947] pci 0014:60:00.0: of_irq_parse_pci() gave up. The slot
> of this
> > device has no Level-triggered Interrupts capability.
>
> Following my above example, this has gone from opaque to potentially
> misleading
I'm not sure. At least for some of our platforms this is the correct
message :-) Our Hypervisor doesn't allow LSIs on some slots.
I think it's not that misleading. It's obvious something is wrong with
LSIs, which you can easily figure out from there.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] of/irq: improve error message on irq discovery process failure
From: Benjamin Herrenschmidt @ 2016-11-10 21:28 UTC (permalink / raw)
To: Guilherme G. Piccoli, devicetree
Cc: linux-pci, robh+dt, linuxppc-dev, frowand.list
In-Reply-To: <1478700308-25481-1-git-send-email-gpiccoli@linux.vnet.ibm.com>
On Wed, 2016-11-09 at 12:05 -0200, Guilherme G. Piccoli wrote:
> diff --git a/drivers/of/irq.c b/drivers/of/irq.c
> index 393fea8..1ad6882 100644
> --- a/drivers/of/irq.c
> +++ b/drivers/of/irq.c
> @@ -275,7 +275,10 @@ int of_irq_parse_raw(const __be32 *addr, struct of_phandle_args *out_irq)
> of_node_put(ipar);
> of_node_put(newpar);
>
> - return -EINVAL;
> + /* Positive non-zero return means no Level-triggered Interrupts
> + * capability was found.
> + */
> + return ENOENT;
> }
> EXPORT_SYMBOL_GPL(of_irq_parse_raw);
I'm not fan. I'd rather it's -ENOENT and the callers can check for that
specific code rather than playing with the sign.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v2 2/6] mfd: stm32-adc: Add support for stm32 ADC
From: kbuild test robot @ 2016-11-10 21:23 UTC (permalink / raw)
Cc: kbuild-all-JC7UmRfGjtg, linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, jic23-DgEjT+Ai2ygdnm+yROfE0A,
lee.jones-QSEj5FYQhm4dnm+yROfE0A, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
mcoquelin.stm32-Re5JQEeQqe8AvxtiuMwx3w,
alexandre.torgue-qxv4g6HH51o, lars-Qo5EllUWu/uELgA04lAiVw,
knaack.h-Mmb7MZpHnFY, pmeerw-jW+XmwGofnusTnJN9+BGXg,
fabrice.gasnier-qxv4g6HH51o
In-Reply-To: <1478794738-28933-3-git-send-email-fabrice.gasnier-qxv4g6HH51o@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2170 bytes --]
Hi Fabrice,
[auto build test ERROR on ljones-mfd/for-mfd-next]
[also build test ERROR on v4.9-rc4 next-20161110]
[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/Fabrice-Gasnier/Add-support-for-STM32-ADC/20161111-011922
base: https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git for-mfd-next
config: s390-allmodconfig (attached as .config)
compiler: s390x-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=s390
All errors (new ones prefixed by >>):
drivers/mfd/stm32-adc-core: struct of_device_id is 200 bytes. The last of 1 is:
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x73 0x74 0x2c 0x73 0x74 0x6d 0x33 0x32 0x66 0x34 0x2d 0x61 0x64 0x63 0x2d 0x63 0x6f 0x72 0x65 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
>> FATAL: drivers/mfd/stm32-adc-core: struct of_device_id is not terminated with a NULL entry!
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 43228 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] of/platform: fix of_platform_device_destroy comment
From: Rob Herring @ 2016-11-10 20:56 UTC (permalink / raw)
To: Johan Hovold; +Cc: Frank Rowand, devicetree, linux-kernel
In-Reply-To: <1477997602-29652-1-git-send-email-johan@kernel.org>
On Tue, Nov 01, 2016 at 11:53:21AM +0100, Johan Hovold wrote:
> Update the comment to of_platform_device_destroy() to reflect that it no
> longer returns a status value.
>
> Fixes: 75f353b61342 ("of/platform: Fix of_platform_device_destroy...")
> Signed-off-by: Johan Hovold <johan@kernel.org>
> ---
> drivers/of/platform.c | 3 ---
> 1 file changed, 3 deletions(-)
Both patches applied.
Rob
^ permalink raw reply
* Re: [PATCH 00/12] of: Make drivers/of/resolver.c more readable
From: Rob Herring @ 2016-11-10 20:56 UTC (permalink / raw)
To: frowand.list
Cc: pantelis.antoniou, Pantelis Antoniou, devicetree, linux-kernel
In-Reply-To: <1477722392-32172-1-git-send-email-frowand.list@gmail.com>
On Fri, Oct 28, 2016 at 11:26:20PM -0700, frowand.list@gmail.com wrote:
> From: Frank Rowand <frank.rowand@am.sony.com>
>
> drivers/of/resolve.c is a bit difficult to read. Clean it up so
> that review of future overlay related patches will be easier.
>
> Most of the patches are intended to be reformatting, with no functional
> change. Patches that are expected to have a functional change are:
>
> Remove excessive printks to reduce clutter.
> Update structure of code to be clearer, also remove BUG_ON()
> Any functional change would reflect undefined behavior on bad overlay.
> Some error message text modified.
> BUG_ON() removed.
> Add back an error message, restructured
>
> The patches are grouped into sets of changes that are intended
> to be easy to verify correctness through simple inspection.
>
> Some of the individual patches have checkpatch warnings or errors.
> But after all patches are applied, the number of errors and
> warnings from running checkpatch against the entire file are
> reduced to two line size warnings.
>
> These patches are only tested via the unit tests. I do not have
> expansion boards to test with real hardware.
>
> changes from rfc to v1:
> - Remove fewer one line comments
> - Add more extensive header comment to of_resolve_phandles()
> to explain the how and why of resolving phandles
> - Update patch header comments
> - Incorporated patch "Remove braces around single line blocks"
> into the previous patch in the series
>
>
> Frank Rowand (12):
> of: Remove comments that state the obvious, to reduce clutter
> of: Remove excessive printks to reduce clutter.
> of: Convert comparisons to zero or NULL to logical expressions
> of: Rename functions to more accurately reflect what they do
> of: Remove prefix "__of_" from local function names
> of: Rename variables to better reflect purpose or follow convention
> of: Update structure of code to be clearer, also remove BUG_ON()
> of: Remove redundant size check
> of: Update comments to reflect changes and increase clarity
> of: Add back an error message, restructured
> of: Move setting of pointer to beside test for non-null
> of: Remove unused variable overlay_symbols
Series applied.
Rob
^ permalink raw reply
* Re: [PATCH v6 4/4] of/fdt: mark hotpluggable memory
From: Reza Arbab @ 2016-11-10 20:52 UTC (permalink / raw)
To: Balbir Singh
Cc: Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
Andrew Morton, Rob Herring, Frank Rowand, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg,
devicetree-u79uwXL29TY76Z2rM5mHXA, Bharata B Rao, Nathan Fontenot,
Stewart Smith, Alistair Popple, Aneesh Kumar K.V,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <aea94234-b3d8-1484-d3ab-39e562d7901d-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Thu, Nov 10, 2016 at 11:56:02AM +1100, Balbir Singh wrote:
>Have you tested this across all combinations of skiboot/kexec/SLOF
>boots?
I've tested it under qemu/grub, simics/skiboot, and via kexec.
--
Reza Arbab
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2] of, numa: Return NUMA_NO_NODE from disable of_node_to_nid() if nid not possible.
From: Rob Herring @ 2016-11-10 20:51 UTC (permalink / raw)
To: David Daney
Cc: David Daney, linux-kernel@vger.kernel.org, Frank Rowand,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Will Deacon, Catalin Marinas, Robert Richter, Hanjun Guo,
Ganapatrao Kulkarni, Gilbert Netzer, David Daney
In-Reply-To: <93b7769a-4907-176e-9f18-0bf6bd72d15d@caviumnetworks.com>
On Thu, Nov 3, 2016 at 10:11 AM, David Daney <ddaney@caviumnetworks.com> wrote:
> On 11/02/2016 08:37 PM, Rob Herring wrote:
>>
>> On Fri, Oct 28, 2016 at 4:15 PM, David Daney <ddaney.cavm@gmail.com>
>> wrote:
>>>
>>> From: David Daney <david.daney@cavium.com>
>>>
>>> On arm64 NUMA kernels we can pass "numa=off" on the command line to
>>> disable NUMA. A side effect of this is that kmalloc_node() calls to
>>> non-zero nodes will crash the system with an OOPS:
>>>
>>> [ 0.000000] ITS@0x0000901000020000: allocated 2097152 Devices
>>> @10002000000 (flat, esz 8, psz 64K, shr 1)
>>> [ 0.000000] Unable to handle kernel NULL pointer dereference at
>>> virtual address 00001680
>>> [ 0.000000] pgd = fffffc0009470000
>>> [ 0.000000] [00001680] *pgd=0000010ffff90003, *pud=0000010ffff90003,
>>> *pmd=0000010ffff90003, *pte=0000000000000000
>>> [ 0.000000] Internal error: Oops: 96000006 [#1] SMP
>>> .
>>> .
>>> .
>>> [ 0.000000] [<fffffc00081c8950>] __alloc_pages_nodemask+0xa4/0xe68
>>> [ 0.000000] [<fffffc000821fa70>] new_slab+0xd0/0x564
>>> [ 0.000000] [<fffffc0008221e24>] ___slab_alloc+0x2e4/0x514
>>> [ 0.000000] [<fffffc0008239498>] __slab_alloc+0x48/0x58
>>> [ 0.000000] [<fffffc0008222c20>] __kmalloc_node+0xd0/0x2dc
>>> [ 0.000000] [<fffffc0008115374>] __irq_domain_add+0x7c/0x164
>>> [ 0.000000] [<fffffc0008b461dc>] its_probe+0x784/0x81c
>>> [ 0.000000] [<fffffc0008b462bc>] its_init+0x48/0x1b0
>>> [ 0.000000] [<fffffc0008b4543c>] gic_init_bases+0x228/0x360
>>> [ 0.000000] [<fffffc0008b456bc>] gic_of_init+0x148/0x1cc
>>> [ 0.000000] [<fffffc0008b5aec8>] of_irq_init+0x184/0x298
>>> [ 0.000000] [<fffffc0008b43f9c>] irqchip_init+0x14/0x38
>>> [ 0.000000] [<fffffc0008b12d60>] init_IRQ+0xc/0x30
>>> [ 0.000000] [<fffffc0008b10a3c>] start_kernel+0x240/0x3b8
>>> [ 0.000000] [<fffffc0008b101c4>] __primary_switched+0x30/0x6c
>>> [ 0.000000] Code: 912ec2a0 b9403809 0a0902fb 37b007db (f9400300)
>>> .
>>> .
>>> .
>>>
>>> This is caused by code like this in kernel/irq/irqdomain.c
>>>
>>> domain = kzalloc_node(sizeof(*domain) + (sizeof(unsigned int) *
>>> size),
>>> GFP_KERNEL, of_node_to_nid(of_node));
>>>
>>> When NUMA is disabled, the concept of a node is really undefined, so
>>> of_node_to_nid() should unconditionally return NUMA_NO_NODE.
>>>
>>> Fix by returning NUMA_NO_NODE when the nid is not in the set of
>>> possible nodes.
>>>
>>> Reported-by: Gilbert Netzer <noname@pdc.kth.se>
>>> Signed-off-by: David Daney <david.daney@cavium.com>
>>
>>
>> Does this need to go in 4.9?
>
>
> That would be my preference.
Given how late this is now, my having nothing else for 4.9 and that
his has never worked, I've applied for 4.10, but I did tag for stable.
Rob
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox