* Re: [PATCH v4 09/13] net: ethernet: ti: cpts: rework initialization/deinitialization
From: Richard Cochran @ 2016-12-06 18:04 UTC (permalink / raw)
To: Grygorii Strashko
Cc: David S. Miller, netdev, Mugunthan V N, Sekhar Nori, linux-kernel,
linux-omap, devicetree, Murali Karicheri, Wingman Kwok,
Thomas Gleixner
In-Reply-To: <c0d6d670-cf44-c113-3443-3b5209e68ee2@ti.com>
On Tue, Dec 06, 2016 at 11:49:14AM -0600, Grygorii Strashko wrote:
> But we do reset whole cpsw :( and that's required to support PM use cases as
> suspend/resume.
The code is resetting the clock unconditionally on ifup/down. That
sucks. If you reset the clock *only* after resume, that would be ok.
> There are also PM requirement to shutdown cpsw in case all interfaces are down.
Well, those requirements are not too smart. As an end user, I expect
that ifdown/up does not change the time. There isn't any reason to
reset the clock in this case.
> More over, there are requirement to minimize cpsw power consumption in case all links are
> disconnected (and cpts is special case here).
>
> So, at least resetting of the timecounter still required.
Only if you follow that poorly conceived PM plan. Anyhow, I agree
that it isn't the task of your present series to fix that.
> Ok. I'll try to optimize it following your directions.
What I would like to see is: initialize the cyclecounter fields
exactly once.
Thanks,
Richard
^ permalink raw reply
* Re: [PATCH 4/6] net: ethernet: ti: cpts: add ptp pps support
From: Richard Cochran @ 2016-12-06 18:08 UTC (permalink / raw)
To: Grygorii Strashko
Cc: David S. Miller, netdev-u79uwXL29TY76Z2rM5mHXA, Mugunthan V N,
Sekhar Nori, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA, Murali Karicheri, Wingman Kwok
In-Reply-To: <20161130100519.GD28680-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
On Wed, Nov 30, 2016 at 11:05:19AM +0100, Richard Cochran wrote:
> Can you adjust the frequency of the keystone devices in hardware? If
> so, then please implement it, and just disable PPS for the CPSW.
>
> The only reason I used the timecounter for frequency adjustment was
> because the am335x HW is broken. But this shouldn't hold back other
> newer HW without the same silicon flaws.
I am talking here about the ADPLLLJ units. Are they usable on the
keystone?
If so, please implement the frequency adjustment with them.
Thanks,
Richard
--
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 3/5] arm64: dts: exynos5433: Add PPMU dt node
From: Krzysztof Kozlowski @ 2016-12-06 19:07 UTC (permalink / raw)
To: Chanwoo Choi
Cc: krzk-DgEjT+Ai2ygdnm+yROfE0A, javier-JPH+aEBZ4P+UEJcrhfAQsw,
kgene-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
s.nawrocki-Sze3O3UU22JBDgjK7y7TUQ,
tomasz.figa-Re5JQEeQqe8AvxtiuMwx3w,
myungjoo.ham-Sze3O3UU22JBDgjK7y7TUQ,
kyungmin.park-Sze3O3UU22JBDgjK7y7TUQ,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1480663087-4590-4-git-send-email-cw00.choi-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
On Fri, Dec 02, 2016 at 04:18:05PM +0900, Chanwoo Choi wrote:
> This patch adds PPMU (Platform Performance Monitoring Unit) Device-tree node
> to measure the utilization of each IP in Exynos SoC.
>
> - PPMU_D{0|1}_CPU are used to measure the utilization of MIF (Memory Interface)
> block with VDD_MIF power source.
> - PPMU_D{0|1}_GENERAL are used to measure the utilization of INT(Internal)
> block with VDD_INT power source.
>
> Signed-off-by: Chanwoo Choi <cw00.choi-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> ---
> arch/arm64/boot/dts/exynos/exynos5433.dtsi | 24 ++++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> index 64226d5ae471..8c4ee84d5232 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> @@ -599,6 +599,30 @@
> clock-names = "fin_pll", "mct";
> };
>
> + ppmu_d0_cpu: ppmu@10480000 {
> + compatible = "samsung,exynos-ppmu-v2";
> + reg = <0x10480000 0x2000>;
> + status = "disabled";
Why these are disabled? They have some external dependencies?
Best regards,
Krzysztof
> + };
> +
> + ppmu_d0_general: ppmu@10490000 {
> + compatible = "samsung,exynos-ppmu-v2";
> + reg = <0x10490000 0x2000>;
> + status = "disabled";
> + };
> +
> + ppmu_d1_cpu: ppmu@104b0000 {
> + compatible = "samsung,exynos-ppmu-v2";
> + reg = <0x104b0000 0x2000>;
> + status = "disabled";
> + };
> +
> + ppmu_d1_general: ppmu@104c0000 {
> + compatible = "samsung,exynos-ppmu-v2";
> + reg = <0x104c0000 0x2000>;
> + status = "disabled";
> + };
> +
> pinctrl_alive: pinctrl@10580000 {
> compatible = "samsung,exynos5433-pinctrl";
> reg = <0x10580000 0x1a20>, <0x11090000 0x100>;
> --
> 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 4/5] arm64: dts: exynos5433: Add bus dt node using VDD_INT for Exynos5433
From: Krzysztof Kozlowski @ 2016-12-06 19:21 UTC (permalink / raw)
To: Chanwoo Choi
Cc: krzk-DgEjT+Ai2ygdnm+yROfE0A, javier-JPH+aEBZ4P+UEJcrhfAQsw,
kgene-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
s.nawrocki-Sze3O3UU22JBDgjK7y7TUQ,
tomasz.figa-Re5JQEeQqe8AvxtiuMwx3w,
myungjoo.ham-Sze3O3UU22JBDgjK7y7TUQ,
kyungmin.park-Sze3O3UU22JBDgjK7y7TUQ,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1480663087-4590-5-git-send-email-cw00.choi-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
On Fri, Dec 02, 2016 at 04:18:06PM +0900, Chanwoo Choi wrote:
> This patch adds the bus nodes using VDD_INT for Exynos5433 SoC.
> Exynos5433 has the following AMBA AXI buses to translate data
> between DRAM and sub-blocks.
>
> Following list specify the detailed correlation between sub-block and clock:
> - CLK_ACLK_G2D_{400|266} : Bus clock for G2D
> - CLK_ACLK_MSCL_400 : Bus clock for MSCL (Mobile Scaler)
> - CLK_ACLK_GSCL_333 : Bus clock for GSCL (General Scaler)
> - CLK_SCLK_JPEG_MSCL : Bus clock for JPEG
> - CLK_ACLK_MFC_400 : Bus clock for MFC (Multi Format Codec)
> - CLK_ACLK_HEVC_400 : Bus clock for HEVC (High Effective Video Codec)
> - CLK_ACLK_BUS0_400 : NoC(Network On Chip)'s bus clock for PERIC/PERIS/FSYS/MSCL
> - CLK_ACLK_BUS1_400 : NoC's bus clock for MFC/HEVC/G3D
> - CLK_ACLK_BUS2_400 : NoC's bus clock for GSCL/DISP/G2D/CAM0/CAM1/ISP
>
> Signed-off-by: Chanwoo Choi <cw00.choi-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> ---
> arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi | 208 +++++++++++++++++++++++++
> arch/arm64/boot/dts/exynos/exynos5433.dtsi | 1 +
> 2 files changed, 209 insertions(+)
> create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi b/arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi
> new file mode 100644
> index 000000000000..b1e1d9c622e1
> --- /dev/null
> +++ b/arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi
> @@ -0,0 +1,208 @@
> +/*
> + * Samsung's Exynos5433 SoC Memory interface and AMBA bus device tree source
> + *
> + * Copyright (c) 2016 Samsung Electronics Co., Ltd.
> + * Chanwoo Choi <cw00.choi-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> + *
> + * Samsung's Exynos5433 SoC Memory interface and AMBA buses are listed
> + * as device tree nodes are listed in this file.
This duplicates the introduction line and does not make sense.
> + *
> + * 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.
> + */
> +
> +/ {
Shouldn't these be under soc node? It looks like property of SoC itself.
> + /* INT (Internal) block using VDD_INT */
> + bus_g2d_400: bus_g2d_400 {
In node name, the dash '-' is preferred. The name should describe
general class of device so probably this should be just "bus"... but I
don't see a way how to do it reasonable anyway.
> + compatible = "samsung,exynos-bus";
> + clocks = <&cmu_top CLK_ACLK_G2D_400>;
> + clock-names = "bus";
> + operating-points-v2 = <&bus_g2d_400_opp_table>;
> + status ="disable";
Hm?
> + };
> +
> + bus_mscl: bus_mscl {
> + compatible = "samsung,exynos-bus";
> + clocks = <&cmu_top CLK_ACLK_MSCL_400>;
> + clock-names = "bus";
> + operating-points-v2 = <&bus_g2d_400_opp_table>;
> + status ="disable";
> + };
> +
> + bus_jpeg: bus_jpeg {
> + compatible = "samsung,exynos-bus";
> + clocks = <&cmu_top CLK_SCLK_JPEG_MSCL>;
> + clock-names = "bus";
> + operating-points-v2 = <&bus_g2d_400_opp_table>;
> + status ="disable";
> + };
> +
> + bus_mfc: bus_mfc {
> + compatible = "samsung,exynos-bus";
> + clocks = <&cmu_top CLK_ACLK_MFC_400>;
> +
> + clock-names = "bus";
> + operating-points-v2 = <&bus_g2d_400_opp_table>;
> + status ="disable";
> + };
> +
> + bus_g2d_266: bus_g2d_266 {
> + compatible = "samsung,exynos-bus";
> + clocks = <&cmu_top CLK_ACLK_G2D_266>;
> + clock-names = "bus";
> + operating-points-v2 = <&bus_g2d_266_opp_table>;
> + status ="disable";
> + };
> +
> + bus_gscl: bus_gscl {
> + compatible = "samsung,exynos-bus";
> + clocks = <&cmu_top CLK_ACLK_GSCL_333>;
> + clock-names = "bus";
> + operating-points-v2 = <&bus_gscl_opp_table>;
> + status ="disable";
> + };
> +
> + bus_hevc: bus_hevc {
> + compatible = "samsung,exynos-bus";
> + clocks = <&cmu_top CLK_ACLK_HEVC_400>;
> + clock-names = "bus";
> + operating-points-v2 = <&bus_hevc_opp_table>;
> + status ="disable";
> + };
> +
> + bus_bus0: bus_bus0 {
bus, bus, bus, bus, jackpot! Let's try to find better name and label for
these. :)
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2 0/2] register atmel-ssc as sound DAI w/o platform driver
From: Peter Rosin @ 2016-12-06 19:22 UTC (permalink / raw)
To: linux-kernel
Cc: Peter Rosin, Rob Herring, Mark Rutland, Liam Girdwood, Mark Brown,
Nicolas Ferre, Arnd Bergmann, Greg Kroah-Hartman, Jaroslav Kysela,
Takashi Iwai, devicetree, alsa-devel, linux-arm-kernel
Hi!
v1 -> v2 changes
- add ack from Rob Herring on patch 1/2.
- add reasons why breaking compatibility is ok for patch 2/2 (requested
by Rob).
- add #sound-dai-cells to the ssc0 node in the devcietree example.
The Atmel SSC is currently not usable as an audio DAI unless someone
registers it with ASoC. This is currently delegated to a platform
driver for every possible audio use, and prevents the SSC from being
used as a cpu DAI with the simple-audio-card driver.
The first patch fixes this.
The second patch simplifies one of these platform drivers, since it
can now rely on the SSC to register itself with ASoC. However, this
may not be a possible simplification for other, older, drivers since
it also requires device tree changes.
Cheers,
Peter
Peter Rosin (2):
misc: atmel-ssc: register as sound DAI if #sound-dai-cells is present
ASoC: atmel: tse850: rely on the ssc to register as a cpu dai by
itself
.../devicetree/bindings/misc/atmel-ssc.txt | 2 +
.../bindings/sound/axentia,tse850-pcm5142.txt | 11 +++--
drivers/misc/atmel-ssc.c | 50 ++++++++++++++++++++++
include/linux/atmel-ssc.h | 1 +
sound/soc/atmel/tse850-pcm5142.c | 23 ++--------
5 files changed, 64 insertions(+), 23 deletions(-)
--
2.1.4
^ permalink raw reply
* [PATCH v2 1/2] misc: atmel-ssc: register as sound DAI if #sound-dai-cells is present
From: Peter Rosin @ 2016-12-06 19:22 UTC (permalink / raw)
To: linux-kernel
Cc: Mark Rutland, devicetree, alsa-devel, Arnd Bergmann,
Greg Kroah-Hartman, Takashi Iwai, Nicolas Ferre, Liam Girdwood,
Rob Herring, Jaroslav Kysela, Mark Brown, Peter Rosin,
linux-arm-kernel
In-Reply-To: <1481052157-23400-1-git-send-email-peda@axentia.se>
The SSC is currently not usable with the ASoC simple-audio-card, as
every SSC audio user has to build a platform driver that may do as
little as calling atmel_ssc_set_audio/atmel_ssc_put_audio (which
allocates the SSC and registers a DAI with the ASoC subsystem).
So, have that happen automatically, if the #sound-dai-cells property
is present in devicetree, which it has to be anyway for simple audio
card to work.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Peter Rosin <peda@axentia.se>
---
.../devicetree/bindings/misc/atmel-ssc.txt | 2 +
drivers/misc/atmel-ssc.c | 50 ++++++++++++++++++++++
include/linux/atmel-ssc.h | 1 +
3 files changed, 53 insertions(+)
diff --git a/Documentation/devicetree/bindings/misc/atmel-ssc.txt b/Documentation/devicetree/bindings/misc/atmel-ssc.txt
index efc98ea1f23d..f8629bb73945 100644
--- a/Documentation/devicetree/bindings/misc/atmel-ssc.txt
+++ b/Documentation/devicetree/bindings/misc/atmel-ssc.txt
@@ -24,6 +24,8 @@ Optional properties:
this parameter to choose where the clock from.
- By default the clock is from TK pin, if the clock from RK pin, this
property is needed.
+ - #sound-dai-cells: Should contain <0>.
+ - This property makes the SSC into an automatically registered DAI.
Examples:
- PDC transfer:
diff --git a/drivers/misc/atmel-ssc.c b/drivers/misc/atmel-ssc.c
index 0516ecda54d3..b2a0340f277e 100644
--- a/drivers/misc/atmel-ssc.c
+++ b/drivers/misc/atmel-ssc.c
@@ -20,6 +20,8 @@
#include <linux/of.h>
+#include "../../sound/soc/atmel/atmel_ssc_dai.h"
+
/* Serialize access to ssc_list and user count */
static DEFINE_SPINLOCK(user_lock);
static LIST_HEAD(ssc_list);
@@ -145,6 +147,49 @@ static inline const struct atmel_ssc_platform_data * __init
platform_get_device_id(pdev)->driver_data;
}
+#ifdef CONFIG_SND_ATMEL_SOC_SSC
+static int ssc_sound_dai_probe(struct ssc_device *ssc)
+{
+ struct device_node *np = ssc->pdev->dev.of_node;
+ int ret;
+ int id;
+
+ ssc->sound_dai = false;
+
+ if (!of_property_read_bool(np, "#sound-dai-cells"))
+ return 0;
+
+ id = of_alias_get_id(np, "ssc");
+ if (id < 0)
+ return id;
+
+ ret = atmel_ssc_set_audio(id);
+ ssc->sound_dai = !ret;
+
+ return ret;
+}
+
+static void ssc_sound_dai_remove(struct ssc_device *ssc)
+{
+ if (!ssc->sound_dai)
+ return;
+
+ atmel_ssc_put_audio(of_alias_get_id(ssc->pdev->dev.of_node, "ssc"));
+}
+#else
+static inline int ssc_sound_dai_probe(struct ssc_device *ssc)
+{
+ if (of_property_read_bool(ssc->pdev->dev.of_node, "#sound-dai-cells"))
+ return -ENOTSUPP;
+
+ return 0;
+}
+
+static inline void ssc_sound_dai_remove(struct ssc_device *ssc)
+{
+}
+#endif
+
static int ssc_probe(struct platform_device *pdev)
{
struct resource *regs;
@@ -204,6 +249,9 @@ static int ssc_probe(struct platform_device *pdev)
dev_info(&pdev->dev, "Atmel SSC device at 0x%p (irq %d)\n",
ssc->regs, ssc->irq);
+ if (ssc_sound_dai_probe(ssc))
+ dev_err(&pdev->dev, "failed to auto-setup ssc for audio\n");
+
return 0;
}
@@ -211,6 +259,8 @@ static int ssc_remove(struct platform_device *pdev)
{
struct ssc_device *ssc = platform_get_drvdata(pdev);
+ ssc_sound_dai_remove(ssc);
+
spin_lock(&user_lock);
list_del(&ssc->list);
spin_unlock(&user_lock);
diff --git a/include/linux/atmel-ssc.h b/include/linux/atmel-ssc.h
index 7c0f6549898b..fdb545101ede 100644
--- a/include/linux/atmel-ssc.h
+++ b/include/linux/atmel-ssc.h
@@ -20,6 +20,7 @@ struct ssc_device {
int user;
int irq;
bool clk_from_rk_pin;
+ bool sound_dai;
};
struct ssc_device * __must_check ssc_request(unsigned int ssc_num);
--
2.1.4
^ permalink raw reply related
* [PATCH v2 2/2] ASoC: atmel: tse850: rely on the ssc to register as a cpu dai by itself
From: Peter Rosin @ 2016-12-06 19:22 UTC (permalink / raw)
To: linux-kernel
Cc: Mark Rutland, devicetree, alsa-devel, Arnd Bergmann,
Greg Kroah-Hartman, Takashi Iwai, Nicolas Ferre, Liam Girdwood,
Rob Herring, Jaroslav Kysela, Mark Brown, Peter Rosin,
linux-arm-kernel
In-Reply-To: <1481052157-23400-1-git-send-email-peda@axentia.se>
This breaks devicetree compatibility, but in this case that is ok. All
affected units are either on my desk, or running an even older version
of the driver that is not compatible with the upstreamed version anyway
(and when these other units are eventually updated, they will get a
fresh dtb as well, so that is not a significant problem either).
All of that is of course assuming that noone else has managed to build
something that can use this driver, but that seems extremely improbable.
Signed-off-by: Peter Rosin <peda@axentia.se>
---
.../bindings/sound/axentia,tse850-pcm5142.txt | 11 ++++++++---
sound/soc/atmel/tse850-pcm5142.c | 23 +++-------------------
2 files changed, 11 insertions(+), 23 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/axentia,tse850-pcm5142.txt b/Documentation/devicetree/bindings/sound/axentia,tse850-pcm5142.txt
index 5b9b38f578bb..fdb25b492514 100644
--- a/Documentation/devicetree/bindings/sound/axentia,tse850-pcm5142.txt
+++ b/Documentation/devicetree/bindings/sound/axentia,tse850-pcm5142.txt
@@ -2,8 +2,7 @@ Devicetree bindings for the Axentia TSE-850 audio complex
Required properties:
- compatible: "axentia,tse850-pcm5142"
- - axentia,ssc-controller: The phandle of the atmel SSC controller used as
- cpu dai.
+ - axentia,cpu-dai: The phandle of the cpu dai.
- axentia,audio-codec: The phandle of the PCM5142 codec.
- axentia,add-gpios: gpio specifier that controls the mixer.
- axentia,loop1-gpios: gpio specifier that controls loop relays on channel 1.
@@ -43,6 +42,12 @@ the PCM5142 codec.
Example:
+ &ssc0 {
+ #sound-dai-cells = <0>;
+
+ status = "okay";
+ };
+
&i2c {
codec: pcm5142@4c {
compatible = "ti,pcm5142";
@@ -77,7 +82,7 @@ Example:
sound {
compatible = "axentia,tse850-pcm5142";
- axentia,ssc-controller = <&ssc0>;
+ axentia,cpu-dai = <&ssc0>;
axentia,audio-codec = <&codec>;
axentia,add-gpios = <&pioA 8 GPIO_ACTIVE_LOW>;
diff --git a/sound/soc/atmel/tse850-pcm5142.c b/sound/soc/atmel/tse850-pcm5142.c
index ac6a814c8ecf..a72c7d642026 100644
--- a/sound/soc/atmel/tse850-pcm5142.c
+++ b/sound/soc/atmel/tse850-pcm5142.c
@@ -51,11 +51,7 @@
#include <sound/soc.h>
#include <sound/pcm_params.h>
-#include "atmel_ssc_dai.h"
-
struct tse850_priv {
- int ssc_id;
-
struct gpio_desc *add;
struct gpio_desc *loop1;
struct gpio_desc *loop2;
@@ -329,23 +325,20 @@ static int tse850_dt_init(struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node;
struct device_node *codec_np, *cpu_np;
- struct snd_soc_card *card = &tse850_card;
struct snd_soc_dai_link *dailink = &tse850_dailink;
- struct tse850_priv *tse850 = snd_soc_card_get_drvdata(card);
if (!np) {
dev_err(&pdev->dev, "only device tree supported\n");
return -EINVAL;
}
- cpu_np = of_parse_phandle(np, "axentia,ssc-controller", 0);
+ cpu_np = of_parse_phandle(np, "axentia,cpu-dai", 0);
if (!cpu_np) {
- dev_err(&pdev->dev, "failed to get dai and pcm info\n");
+ dev_err(&pdev->dev, "failed to get cpu dai\n");
return -EINVAL;
}
dailink->cpu_of_node = cpu_np;
dailink->platform_of_node = cpu_np;
- tse850->ssc_id = of_alias_get_id(cpu_np, "ssc");
of_node_put(cpu_np);
codec_np = of_parse_phandle(np, "axentia,audio-codec", 0);
@@ -415,23 +408,14 @@ static int tse850_probe(struct platform_device *pdev)
return ret;
}
- ret = atmel_ssc_set_audio(tse850->ssc_id);
- if (ret != 0) {
- dev_err(dev,
- "failed to set SSC %d for audio\n", tse850->ssc_id);
- goto err_disable_ana;
- }
-
ret = snd_soc_register_card(card);
if (ret) {
dev_err(dev, "snd_soc_register_card failed\n");
- goto err_put_audio;
+ goto err_disable_ana;
}
return 0;
-err_put_audio:
- atmel_ssc_put_audio(tse850->ssc_id);
err_disable_ana:
regulator_disable(tse850->ana);
return ret;
@@ -443,7 +427,6 @@ static int tse850_remove(struct platform_device *pdev)
struct tse850_priv *tse850 = snd_soc_card_get_drvdata(card);
snd_soc_unregister_card(card);
- atmel_ssc_put_audio(tse850->ssc_id);
regulator_disable(tse850->ana);
return 0;
--
2.1.4
^ permalink raw reply related
* Re: [PATCH 5/5] arm64: dts: exynos5433: Add support of bus frequency using VDD_INT on TM2
From: Krzysztof Kozlowski @ 2016-12-06 19:24 UTC (permalink / raw)
To: Chanwoo Choi
Cc: krzk-DgEjT+Ai2ygdnm+yROfE0A, javier-JPH+aEBZ4P+UEJcrhfAQsw,
kgene-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
s.nawrocki-Sze3O3UU22JBDgjK7y7TUQ,
tomasz.figa-Re5JQEeQqe8AvxtiuMwx3w,
myungjoo.ham-Sze3O3UU22JBDgjK7y7TUQ,
kyungmin.park-Sze3O3UU22JBDgjK7y7TUQ,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1480663087-4590-6-git-send-email-cw00.choi-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
On Fri, Dec 02, 2016 at 04:18:07PM +0900, Chanwoo Choi wrote:
> This patch adds the bus Device-tree nodes for INT (Internal) block
> to enable the bus frequency scaling.
>
> Signed-off-by: Chanwoo Choi <cw00.choi-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> ---
> arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 72 +++++++++++++++++++++++++++
> 1 file changed, 72 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> index c08589970134..7b37aae336b1 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> @@ -170,6 +170,58 @@
> };
> };
>
> +&bus_g2d_400 {
> + devfreq-events = <&ppmu_event0_d0_general>, <&ppmu_event0_d1_general>;
> + vdd-supply = <&buck4_reg>;
> + exynos,saturation-ratio = <10>;
> + status = "okay";
> +};
> +
> +&bus_mscl {
> + devfreq = <&bus_g2d_400>;
> + status = "okay";
> +};
> +
> +&bus_jpeg {
Except the first entry (which is a parent), are there any objections to
order these nodes alphabetically? This also applies to the previously
patch.
Beside that nit, looks good. I will have to wait anyway to next merge
window, so for the reference:
Reviewed-by: Krzysztof Kozlowski <krzk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Best regards,
Krzysztof
> + devfreq = <&bus_g2d_400>;
> + status = "okay";
> +};
> +
> +&bus_mfc {
> + devfreq = <&bus_g2d_400>;
> + status = "okay";
> +};
> +
> +&bus_g2d_266 {
> + devfreq = <&bus_g2d_400>;
> + status = "okay";
> +};
> +
> +&bus_gscl {
> + devfreq = <&bus_g2d_400>;
> + status = "okay";
> +};
> +
> +&bus_hevc {
> + devfreq = <&bus_g2d_400>;
> + status = "okay";
> +};
> +
> +&bus_bus0 {
> + devfreq = <&bus_g2d_400>;
> + status = "okay";
> +};
> +
> +&bus_bus1 {
> + devfreq = <&bus_g2d_400>;
> + status = "okay";
> +};
> +
> +&bus_bus2 {
> + devfreq = <&bus_g2d_400>;
> + status = "okay";
> +};
> +
> &cmu_aud {
> assigned-clocks = <&cmu_aud CLK_MOUT_AUD_PLL_USER>;
> assigned-clock-parents = <&cmu_top CLK_FOUT_AUD_PLL>;
> @@ -794,6 +846,26 @@
> bus-width = <4>;
> };
>
> +&ppmu_d0_general {
> + status = "okay";
> +
> + events {
> + ppmu_event0_d0_general: ppmu-event0-d0-general {
> + event-name = "ppmu-event0-d0-general";
> + };
> + };
> +};
> +
> +&ppmu_d1_general {
> + status = "okay";
> +
> + events {
> + ppmu_event0_d1_general: ppmu-event0-d1-general {
> + event-name = "ppmu-event0-d1-general";
> + };
> + };
> +};
> +
> &pinctrl_alive {
> pinctrl-names = "default";
> pinctrl-0 = <&initial_alive>;
> --
> 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 2/2] arm64: dts: NS2: add support for XMC form factor
From: Jon Mason @ 2016-12-06 19:35 UTC (permalink / raw)
To: kbuild test robot
Cc: kbuild-all, Rob Herring, Mark Rutland, Florian Fainelli,
devicetree, bcm-kernel-feedback-list, linux-arm-kernel,
linux-kernel
In-Reply-To: <201612061647.t3qcDWHR%fengguang.wu@intel.com>
On Tue, Dec 06, 2016 at 04:37:48PM +0800, kbuild test robot wrote:
> Hi Jon,
>
> [auto build test ERROR on robh/for-next]
> [also build test ERROR on v4.9-rc8]
> [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/Jon-Mason/arm64-dts-NS2-reserve-memory-for-Nitro-firmware/20161206-125631
> base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
> config: arm64-allmodconfig (attached as .config)
> compiler: aarch64-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=arm64
>
> All errors (new ones prefixed by >>):
>
> >> Error: arch/arm64/boot/dts/broadcom/ns2-xmc.dts:56.1-6 Label or path enet not found
> >> Error: arch/arm64/boot/dts/broadcom/ns2-xmc.dts:132.1-7 Label or path pcie8 not found
> >> Error: arch/arm64/boot/dts/broadcom/ns2-xmc.dts:148.1-6 Label or path qspi not found
> >> FATAL ERROR: Syntax error parsing input tree
This patch series is based on top of others queued in Florian's tree.
The errors referenced above are not present when based on this tree,
as those labels are already in the NS2 DT files there.
Thanks,
Jon
>
> ---
> 0-DAY kernel test infrastructure Open Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* Re: [PATCH 2/6] net: ethernet: ti: cpts: add support for ext rftclk selection
From: Grygorii Strashko @ 2016-12-06 19:39 UTC (permalink / raw)
To: Richard Cochran, Murali Karicheri
Cc: David S. Miller, netdev, Mugunthan V N, Sekhar Nori, linux-kernel,
linux-omap, Rob Herring, devicetree, Wingman Kwok, linux-clk
In-Reply-To: <bf207ac4-0f9f-d4a7-14ac-704d93fb7764@ti.com>
On 11/30/2016 11:35 AM, Grygorii Strashko wrote:
>
>
> On 11/30/2016 03:56 AM, Richard Cochran wrote:
>> On Mon, Nov 28, 2016 at 05:04:24PM -0600, Grygorii Strashko wrote:
>>> Some CPTS instances, which can be found on KeyStone 2 1/10G Ethernet
>>> Switch Subsystems, can control an external multiplexer that selects
>>> one of up to 32 clocks for time sync reference (RFTCLK). This feature
>>> can be configured through CPTS_RFTCLK_SEL register (offset: x08).
>>>
>>> Hence, introduce optional DT cpts_rftclk_sel poperty wich, if present,
>>> will specify CPTS reference clock. The cpts_rftclk_sel should be
>>> omitted in DT if HW doesn't support this feature. The external fixed
>>> rate clocks can be defined in board files as "fixed-clock".
>>
>> Can't you implement this using the clock tree, rather than an ad-hoc
>> DT property?
>>
>
> I've thought about this, but decided to move forward with this impl
> which is pretty simple. I will try.
>
>
I come with below RFC patch. if no objection I'll move forward with it.
According to Keystone 2 66AK2e DM there are 7 possible ref clocks:
0000 = SYSCLK2
0001 = SYSCLK3
0010 = TIMI0
0011 = TIMI1
0100 = TSIPCLKA
1000 = TSREFCLK
1100 = TSIPCLKB
Others = Reserved
2 from above clocks are internal SYSCLK2 and SYSCLK3 - other external
(board specific). So default definition of cpts_mux will have only two parents.
If ext clock is going to be use as cpts rftclk then it should be
defined in board file and cpts_refclk_mux definition updated to support
this ext clock:
timi1clk: timi1clk {
#clock-cells = <0>;
compatible = "fixed-clock";
clock-frequency = <xxxxxxxxxx>;
clock-output-names = "timi1";
};
&cpts_mux {
clocks = <&chipclk12>, <&chipclk13>, <timi1clk>;
cpts-mux-tbl = <0>, <1>, <3>;
assigned-clocks = <&cpts_mux>;
assigned-clock-parents = <&timi1clk>;
};
>From ec5c7bed0e021c2ca7e9392173bf67bb9a45d0f4 Mon Sep 17 00:00:00 2001
From: Grygorii Strashko <grygorii.strashko@ti.com>
Date: Mon, 5 Dec 2016 12:34:45 -0600
Subject: [PATCH] cpts refclk sel
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
---
arch/arm/boot/dts/keystone-k2e-netcp.dtsi | 10 +++++-
drivers/net/ethernet/ti/cpts.c | 52 ++++++++++++++++++++++++++++++-
2 files changed, 60 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/keystone-k2e-netcp.dtsi b/arch/arm/boot/dts/keystone-k2e-netcp.dtsi
index 919e655..b27aa22 100644
--- a/arch/arm/boot/dts/keystone-k2e-netcp.dtsi
+++ b/arch/arm/boot/dts/keystone-k2e-netcp.dtsi
@@ -138,7 +138,7 @@ netcp: netcp@24000000 {
/* NetCP address range */
ranges = <0 0x24000000 0x1000000>;
- clocks = <&clkpa>, <&clkcpgmac>, <&chipclk12>;
+ clocks = <&clkpa>, <&clkcpgmac>, <&cpts_mux>;
clock-names = "pa_clk", "ethss_clk", "cpts";
dma-coherent;
@@ -162,6 +162,14 @@ netcp: netcp@24000000 {
cpts-ext-ts-inputs = <6>;
cpts-ts-comp-length;
+ cpts_mux: cpts_refclk_mux {
+ #clock-cells = <0>;
+ clocks = <&chipclk12>, <&chipclk13>;
+ cpts-mux-tbl = <0>, <1>;
+ assigned-clocks = <&cpts_mux>;
+ assigned-clock-parents = <&chipclk12>;
+ };
+
interfaces {
gbe0: interface-0 {
slave-port = <0>;
diff --git a/drivers/net/ethernet/ti/cpts.c b/drivers/net/ethernet/ti/cpts.c
index 938de22..ef94316 100644
--- a/drivers/net/ethernet/ti/cpts.c
+++ b/drivers/net/ethernet/ti/cpts.c
@@ -17,6 +17,7 @@
* along with this program; if not, write to the Free Software
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
*/
+#include <linux/clk-provider.h>
#include <linux/err.h>
#include <linux/if.h>
#include <linux/hrtimer.h>
@@ -672,6 +673,7 @@ int cpts_register(struct cpts *cpts)
cpts->phc_index = ptp_clock_index(cpts->clock);
schedule_delayed_work(&cpts->overflow_work, cpts->ov_check_period);
+
return 0;
err_ptp:
@@ -741,6 +743,54 @@ static void cpts_calc_mult_shift(struct cpts *cpts)
freq, cpts->cc_mult, cpts->cc.shift, (ns - NSEC_PER_SEC));
}
+static int cpts_of_mux_clk_setup(struct cpts *cpts, struct device_node *node)
+{
+ unsigned int num_parents;
+ const char **parent_names;
+ struct device_node *refclk_np;
+ void __iomem *reg;
+ struct clk *clk;
+ u32 *mux_table;
+ int ret;
+
+ refclk_np = of_get_child_by_name(node, "cpts_refclk_mux");
+ if (!refclk_np)
+ return -EINVAL;
+
+ num_parents = of_clk_get_parent_count(refclk_np);
+ if (num_parents < 1) {
+ dev_err(cpts->dev, "mux-clock %s must have parents\n",
+ refclk_np->name);
+ return -EINVAL;
+ }
+ parent_names = devm_kzalloc(cpts->dev, (sizeof(char *) * num_parents),
+ GFP_KERNEL);
+ if (!parent_names)
+ return -ENOMEM;
+
+ of_clk_parent_fill(refclk_np, parent_names, num_parents);
+
+ mux_table = devm_kzalloc(cpts->dev, sizeof(*mux_table) * (32 + 1),
+ GFP_KERNEL);
+ if (!mux_table)
+ return -ENOMEM;
+
+ ret = of_property_read_variable_u32_array(refclk_np, "cpts-mux-tbl",
+ mux_table, 1, 32);
+ if (ret < 0)
+ return ret;
+
+ reg = &cpts->reg->rftclk_sel;
+
+ clk = clk_register_mux_table(cpts->dev, refclk_np->name,
+ parent_names, num_parents,
+ 0, reg, 0, 0x1F, 0, mux_table, NULL);
+ if (IS_ERR(clk))
+ return PTR_ERR(clk);
+
+ return of_clk_add_provider(refclk_np, of_clk_src_simple_get, clk);
+}
+
static int cpts_of_parse(struct cpts *cpts, struct device_node *node)
{
int ret = -EINVAL;
@@ -787,7 +837,7 @@ static int cpts_of_parse(struct cpts *cpts, struct device_node *node)
if (!of_property_read_u32(node, "cpts-ext-ts-inputs", &prop))
cpts->ext_ts_inputs = prop;
- return 0;
+ return cpts_of_mux_clk_setup(cpts, node);
of_error:
dev_err(cpts->dev, "CPTS: Missing property in the DT.\n");
--
2.10.1
--
regards,
-grygorii
^ permalink raw reply related
* Re: [PATCH v9 1/2] usb: dwc2: assert phy reset when waking up in rk3288 platform
From: John Youn @ 2016-12-06 19:43 UTC (permalink / raw)
To: Ayaka, John Youn
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
kishon-l0cyMroinI0@public.gmane.org,
felipe.balbi-VuQAYsv1563Yd54FQh9/CA@public.gmane.org,
mark.rutland-5wv7dgnIgG8@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
randy.li-TNX95d0MmH7DzftRWevZcw@public.gmane.org
In-Reply-To: <AAC04FF8-1049-4153-AC77-90A423B69181-xPW3/0Ywev/iB9QmIjCX8w@public.gmane.org>
On 12/6/2016 4:00 AM, Ayaka wrote:
> Hello John
> I still waiting them be merged, but I still can't find it at next-20161206.
>
Can you resubmit this fixing the checkpatch issues?
You can add my ack:
Acked-by: John Youn <johnyoun-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
Regards,
John
> 從我的 iPad 傳送
>
>> John Youn <John.Youn-HKixBCOQz3hWk0Htik3J/w@public.gmane.org> 於 2016年10月25日 上午9:30 寫道：
>>
>>> On 10/23/2016 2:33 AM, ayaka wrote:
>>>
>>>
>>>> On 10/22/2016 03:27 AM, John Youn wrote:
>>>>> On 10/20/2016 11:38 AM, Randy Li wrote:
>>>>> On the rk3288 USB host-only port (the one that's not the OTG-enabled
>>>>> port) the PHY can get into a bad state when a wakeup is asserted (not
>>>>> just a wakeup from full system suspend but also a wakeup from
>>>>> autosuspend).
>>>>>
>>>>> We can get the PHY out of its bad state by asserting its "port reset",
>>>>> but unfortunately that seems to assert a reset onto the USB bus so it
>>>>> could confuse things if we don't actually deenumerate / reenumerate the
>>>>> device.
>>>>>
>>>>> We can also get the PHY out of its bad state by fully resetting it using
>>>>> the reset from the CRU (clock reset unit) in chip, which does a more full
>>>>> reset. The CRU-based reset appears to actually cause devices on the bus
>>>>> to be removed and reinserted, which fixes the problem (albeit in a hacky
>>>>> way).
>>>>>
>>>>> It's unfortunate that we need to do a full re-enumeration of devices at
>>>>> wakeup time, but this is better than alternative of letting the bus get
>>>>> wedged.
>>>>>
>>>>> Signed-off-by: Randy Li <ayaka-xPW3/0Ywev/iB9QmIjCX8w@public.gmane.org>
>>>>> ---
>>>>> drivers/usb/dwc2/core.h | 1 +
>>>>> drivers/usb/dwc2/core_intr.c | 11 +++++++++++
>>>>> drivers/usb/dwc2/platform.c | 9 +++++++++
>>>>> 3 files changed, 21 insertions(+)
>>>>>
>>>>> diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
>>>>> index 2a21a04..e91ddbc 100644
>>>>> --- a/drivers/usb/dwc2/core.h
>>>>> +++ b/drivers/usb/dwc2/core.h
>>>>> @@ -859,6 +859,7 @@ struct dwc2_hsotg {
>>>>> unsigned int ll_hw_enabled:1;
>>>>>
>>>>> struct phy *phy;
>>>>> + struct work_struct phy_rst_work;
>>>>> struct usb_phy *uphy;
>>>>> struct dwc2_hsotg_plat *plat;
>>>>> struct regulator_bulk_data supplies[ARRAY_SIZE(dwc2_hsotg_supply_names)];
>>>>> diff --git a/drivers/usb/dwc2/core_intr.c b/drivers/usb/dwc2/core_intr.c
>>>>> index d85c5c9..c3d2168 100644
>>>>> --- a/drivers/usb/dwc2/core_intr.c
>>>>> +++ b/drivers/usb/dwc2/core_intr.c
>>>>> @@ -345,6 +345,7 @@ static void dwc2_handle_session_req_intr(struct dwc2_hsotg *hsotg)
>>>>> static void dwc2_handle_wakeup_detected_intr(struct dwc2_hsotg *hsotg)
>>>>> {
>>>>> int ret;
>>>>> + struct device_node *np = hsotg->dev->of_node;
>>>>>
>>>>> /* Clear interrupt */
>>>>> dwc2_writel(GINTSTS_WKUPINT, hsotg->regs + GINTSTS);
>>>>> @@ -379,6 +380,16 @@ static void dwc2_handle_wakeup_detected_intr(struct dwc2_hsotg *hsotg)
>>>>> /* Restart the Phy Clock */
>>>>> pcgcctl &= ~PCGCTL_STOPPCLK;
>>>>> dwc2_writel(pcgcctl, hsotg->regs + PCGCTL);
>>>>> +
>>>>> + /*
>>>>> + * It is a quirk in Rockchip RK3288, causing by
>>>>> + * a hardware bug. This will propagate out and
>>>>> + * eventually we'll re-enumerate the device.
>>>>> + * Not great but the best we can do
>>>>> + */
>>>>> + if (of_device_is_compatible(np, "rockchip,rk3288-usb"))
>>>>> + schedule_work(&hsotg->phy_rst_work);
>>>>> +
>>>>> mod_timer(&hsotg->wkp_timer,
>>>>> jiffies + msecs_to_jiffies(71));
>>>>> } else {
>>>>> diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
>>>>> index 8e1728b..65953cf 100644
>>>>> --- a/drivers/usb/dwc2/platform.c
>>>>> +++ b/drivers/usb/dwc2/platform.c
>>>>> @@ -366,6 +366,14 @@ int dwc2_lowlevel_hw_disable(struct dwc2_hsotg *hsotg)
>>>>> return ret;
>>>>> }
>>>>>
>>>>> +/* Only used to reset usb phy at interrupter runtime */
>>>>> +static void dwc2_reset_phy_work(struct work_struct *data)
>>>>> +{
>>>>> + struct dwc2_hsotg *hsotg = container_of(data, struct dwc2_hsotg,
>>>>> + phy_rst_work);
>>>>> + phy_reset(hsotg->phy);
>>>>> +}
>>>>> +
>>>>> static int dwc2_lowlevel_hw_init(struct dwc2_hsotg *hsotg)
>>>>> {
>>>>> int i, ret;
>>>>> @@ -410,6 +418,7 @@ static int dwc2_lowlevel_hw_init(struct dwc2_hsotg *hsotg)
>>>>> return ret;
>>>>> }
>>>>> }
>>>>> + INIT_WORK(&hsotg->phy_rst_work, dwc2_reset_phy_work);
>>>>>
>>>>> if (!hsotg->phy) {
>>>>> hsotg->uphy = devm_usb_get_phy(hsotg->dev, USB_PHY_TYPE_USB2);
>>>>>
>>>> Hi Randy,
>>>>
>>>> This fails compile if CONFIG_GENERIC_PHY is disabled. I think you need
>>>> to make a fix to your phy_reset patch first.
>>> In the last time, cac18ecb6f44b11bc303d7afbae3887b27938fa4 have not been
>>> merged, I though the
>>> [PATCH v8 1/3] phy: Add reset callback for not generic phy have been
>>> merged before that. when the rebase abandon it.
>>> Should re-send that patch? As the mainline have not been affected, could
>>> you arrange a squash for it?
>>
>> Hi Randy,
>>
>> Can you resend the fix to Kishon?
>>
>> The phy_reset patch landed in 4.9-rc so I think he should take the fix
>> for the next -rc. After that we can send the dwc2 change through
>> Felipe.
>>
>> Regards,
>> John
>
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 3/4] [media] davinci: vpif_capture: get subdevs from DT
From: Kevin Hilman @ 2016-12-06 19:50 UTC (permalink / raw)
To: Hans Verkuil
Cc: Laurent Pinchart, Sakari Ailus,
linux-media-u79uwXL29TY76Z2rM5mHXA, devicetree, Sekhar Nori,
Axel Haslam, Bartosz Gołaszewski, Alexandre Bailon,
David Lechner
In-Reply-To: <m2mvg9ez2h.fsf-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
On Tue, Dec 6, 2016 at 9:40 AM, Kevin Hilman <khilman-rdvid1DuHRBWk0Htik3J/w@public.gmane.org> wrote:
> Hans Verkuil <hverkuil-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org> writes:
>
>> On 12/01/2016 10:16 AM, Laurent Pinchart wrote:
>>> Hello,
>>>
>>> On Thursday 01 Dec 2016 09:57:31 Sakari Ailus wrote:
>>>> On Wed, Nov 30, 2016 at 04:14:11PM -0800, Kevin Hilman wrote:
>>>>> Sakari Ailus <sakari.ailus-X3B1VOXEql0@public.gmane.org> writes:
>>>>>> On Wed, Nov 23, 2016 at 03:25:32PM -0800, Kevin Hilman wrote:
>>>>>>> Sakari Ailus <sakari.ailus-X3B1VOXEql0@public.gmane.org> writes:
>>>>>>>> On Tue, Nov 22, 2016 at 07:52:43AM -0800, Kevin Hilman wrote:
>>>>>>>>> Allow getting of subdevs from DT ports and endpoints.
>>>>>>>>>
>>>>>>>>> The _get_pdata() function was larely inspired by (i.e. stolen from)
>>>>>>>>> am437x-vpfe.c
>>>>>>>>>
>>>>>>>>> Signed-off-by: Kevin Hilman <khilman-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
>>>>>>>>> ---
>>>>>>>>>
>>>>>>>>> drivers/media/platform/davinci/vpif_capture.c | 130 +++++++++++++++-
>>>>>>>>> include/media/davinci/vpif_types.h
>>>>>>>>> | 9 +-
>>>>>>>>> 2 files changed, 133 insertions(+), 6 deletions(-)
>>>>>>>>>
>>>>>>>>> diff --git a/drivers/media/platform/davinci/vpif_capture.c
>>>>>>>>> b/drivers/media/platform/davinci/vpif_capture.c index
>>>>>>>>> 94ee6cf03f02..47a4699157e7 100644
>>>>>>>>> --- a/drivers/media/platform/davinci/vpif_capture.c
>>>>>>>>> +++ b/drivers/media/platform/davinci/vpif_capture.c
>>>>>>>>> @@ -26,6 +26,8 @@
>>>>>>>>> #include <linux/slab.h>
>>>>>>>>>
>>>>>>>>> #include <media/v4l2-ioctl.h>
>>>>>>>>> +#include <media/v4l2-of.h>
>>>>>>>>> +#include <media/i2c/tvp514x.h>
>>>>>>>>
>>>>>>>> Do you need this header?
>>>>>>>
>>>>>>> Yes, based on discussion with Hans, since there is no DT binding for
>>>>>>> selecting the input pins of the TVP514x, I have to select it in the
>>>>>>> driver, so I need the defines from this header. More on this below...
>>>
>>> That's really ugly :-( The problem should be fixed properly instead of adding
>>> one more offender.
>>
>> Do you have time for that, Laurent? I don't. Until that time we just need to
>> make do with this workaround.
>>
>>>
>>>>>>>>> #include "vpif.h"
>>>>>>>>> #include "vpif_capture.h"
>>>>>>>>> @@ -650,6 +652,10 @@ static int vpif_input_to_subdev(
>>>>>>>>>
>>>>>>>>> vpif_dbg(2, debug, "vpif_input_to_subdev\n");
>>>>>>>>>
>>>>>>>>> + if (!chan_cfg)
>>>>>>>>> + return -1;
>>>>>>>>> + if (input_index >= chan_cfg->input_count)
>>>>>>>>> + return -1;
>>>>>>>>> subdev_name = chan_cfg->inputs[input_index].subdev_name;
>>>>>>>>> if (subdev_name == NULL)
>>>>>>>>> return -1;
>>>>>>>>> @@ -657,7 +663,7 @@ static int vpif_input_to_subdev(
>>>>>>>>> /* loop through the sub device list to get the sub device info
>>>>>>>>> */
>>>>>>>>> for (i = 0; i < vpif_cfg->subdev_count; i++) {
>>>>>>>>> subdev_info = &vpif_cfg->subdev_info[i];
>>>>>>>>> - if (!strcmp(subdev_info->name, subdev_name))
>>>>>>>>> + if (subdev_info && !strcmp(subdev_info->name,
>>>>>>>>> subdev_name))
>>>>>>>>> return i;
>>>>>>>>> }
>>>>>>>>> return -1;
>>>>>>>>> @@ -1327,6 +1333,21 @@ static int vpif_async_bound(struct
>>>>>>>>> v4l2_async_notifier *notifier,> >> >>
>>>>>>>>> {
>>>>>>>>> int i;
>>>>>>>>>
>>>>>>>>> + for (i = 0; i < vpif_obj.config->asd_sizes[0]; i++) {
>>>>>>>>> + struct v4l2_async_subdev *_asd = vpif_obj.config
>>>>>>>>> ->asd[i];
>>>>>>>>> + const struct device_node *node = _asd->match.of.node;
>>>>>>>>> +
>>>>>>>>> + if (node == subdev->of_node) {
>>>>>>>>> + vpif_obj.sd[i] = subdev;
>>>>>>>>> + vpif_obj.config->chan_config
>>>>>>>>> ->inputs[i].subdev_name =
>>>>>>>>> + (char *)subdev->of_node->full_name;
>>>
>>> Can subdev_name be made const instead of blindly casting the full_name pointer
>>> ? If not this is probably unsafe, and if yes it should be done :-)
>>>
>>>>>>>>> + vpif_dbg(2, debug,
>>>>>>>>> + "%s: setting input %d subdev_name =
>>>>>>>>> %s\n",
>>>>>>>>> + __func__, i, subdev->of_node
>>>>>>>>> ->full_name);
>>>>>>>>> + return 0;
>>>>>>>>> + }
>>>>>>>>> + }
>>>>>>>>> +
>>>>>>>>> for (i = 0; i < vpif_obj.config->subdev_count; i++)
>>>>>>>>> if (!strcmp(vpif_obj.config->subdev_info[i].name,
>>>>>>>>> subdev->name)) {
>>>>>>>>> @@ -1422,6 +1443,110 @@ static int vpif_async_complete(struct
>>>>>>>>> v4l2_async_notifier *notifier)
>>>>>>>>> return vpif_probe_complete();
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> +static struct vpif_capture_config *
>>>>>>>>> +vpif_capture_get_pdata(struct platform_device *pdev)
>>>>>>>>> +{
>>>>>>>>> + struct device_node *endpoint = NULL;
>>>>>>>>> + struct v4l2_of_endpoint bus_cfg;
>>>>>>>>> + struct vpif_capture_config *pdata;
>>>>>>>>> + struct vpif_subdev_info *sdinfo;
>>>>>>>>> + struct vpif_capture_chan_config *chan;
>>>>>>>>> + unsigned int i;
>>>>>>>>> +
>>>>>>>>> + dev_dbg(&pdev->dev, "vpif_get_pdata\n");
>>>>>>>>> +
>>>>>>>>> + if (!IS_ENABLED(CONFIG_OF) || !pdev->dev.of_node)
>>>>>>>>> + return pdev->dev.platform_data;
>>>>>>>>> +
>>>>>>>>> + pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
>>>>>>>>> + if (!pdata)
>>>>>>>>> + return NULL;
>>>>>>>>> + pdata->subdev_info =
>>>>>>>>> + devm_kzalloc(&pdev->dev, sizeof(*pdata->subdev_info) *
>>>>>>>>> + VPIF_CAPTURE_MAX_CHANNELS, GFP_KERNEL);
>>>>>>>>> +
>>>>>>>>> + if (!pdata->subdev_info)
>>>>>>>>> + return NULL;
>>>>>>>>> + dev_dbg(&pdev->dev, "%s\n", __func__);
>>>>>>>>> +
>>>>>>>>> + for (i = 0; ; i++) {
>>>>>>>>> + struct device_node *rem;
>>>>>>>>> + unsigned int flags;
>>>>>>>>> + int err;
>>>>>>>>> +
>>>>>>>>> + endpoint = of_graph_get_next_endpoint(pdev
>>>>>>>>> ->dev.of_node,
>>>>>>>>> + endpoint);
>>>>>>>>> + if (!endpoint)
>>>>>>>>> + break;
>>>>>>>>> +
>>>>>>>>> + sdinfo = &pdata->subdev_info[i];
>>>>>>>>
>>>>>>>> subdev_info[] has got VPIF_CAPTURE_MAX_CHANNELS entries only.
>>>>>>>
>>>>>>> Right, I need to make the loop only go for a max of
>>>>>>> VPIF_CAPTURE_MAX_CHANNELS iterations.
>>>>>>>
>>>>>>>>> + chan = &pdata->chan_config[i];
>>>>>>>>> + chan->inputs = devm_kzalloc(&pdev->dev,
>>>>>>>>> + sizeof(*chan->inputs) *
>>>>>>>>> + VPIF_DISPLAY_MAX_CHANNELS,
>>>>>>>>> + GFP_KERNEL);
>>>>>>>>> +
>>>>>>>>> + chan->input_count++;
>>>>>>>>> + chan->inputs[i].input.type = V4L2_INPUT_TYPE_CAMERA;
>>>>>>>>
>>>>>>>> I wonder what's the purpose of using index i on this array as well.
>>>>>>>
>>>>>>> The number of endpoints in DT is the number of input channels
>>>>>>> configured (up to a max of VPIF_CAPTURE_MAX_CHANNELS.)
>>>>>>>
>>>>>>>> If you use that to access a corresponding entry in a different array,
>>>>>>>> I'd just create a struct that contains the port configuration and the
>>>>>>>> async sub-device. The omap3isp driver does that, for instance; see
>>>>>>>> isp_of_parse_nodes() in drivers/media/platform/omap3isp/isp.c if
>>>>>>>> you're interested. Up to you.
>>>>>>>
>>>>>>> OK, I'll have a look at that driver. The goal here with this series is
>>>>>>> just to get this working with DT, but also not break the existing
>>>>>>> legacy platform_device support, so I'm trying not to mess with the
>>>>>>> driver-interal data structures too much.
>>>>>>
>>>>>> Ack.
>>>>>>
>>>>>>>>> + chan->inputs[i].input.std = V4L2_STD_ALL;
>>>>>>>>> + chan->inputs[i].input.capabilities = V4L2_IN_CAP_STD;
>>>>>>>>> +
>>>>>>>>> + /* FIXME: need a new property? ch0:composite ch1:
>>>>>>>>> s-video */
>>>>>>>>> + if (i == 0)
>>>>>>>>
>>>>>>>> Can you assume that the first endopoint has got a particular kind of
>>>>>>>> input? What if it's not connected?
>>>>>>>
>>>>>>> On all the boards I know of (there aren't many using this SoC), it's a
>>>>>>> safe assumption.
>>>>>>>
>>>>>>>> If this is a different physical port (not in the meaning another) in
>>>>>>>> the device, I'd use the reg property for this. Please see
>>>>>>>> Documentation/devicetree/bindings/media/video-interfaces.txt .
>>>>>>>
>>>>>>> My understanding (which is admittedly somewhat fuzzy) of the TVP514x is
>>>>>>> that it's not physically a different port. Instead, it's just telling
>>>>>>> the TVP514x which pin(s) will be active inputs (and what kind of signal
>>>>>>> will be present.)
>>>>>>>
>>>>>>> I'm open to a better way to describe this input select from DT, but
>>>>>>> based on what I heard from Hans, there isn't currently a good way to do
>>>>>>> that except for in the driver:
>>>>>>> (c.f. https://marc.info/?l=linux-arm-kernel&m=147887871615788)
>>>>>>>
>>>>>>> Based on further discussion in that thread, it sounds like there may be
>>>>>>> a way forward coming soon, and I'll be glad to switch to that when it
>>>>>>> arrives.
>>>
>>> I'm afraid I have to disappoint Hans here, I don't have code for that yet.
>>>
>>>>>> I'm not sure that properly supporting connectors will provide any help
>>>>>> here.
>>>>>>
>>>>>> Looking at the s_routing() API, it's the calling driver that has to be
>>>>>> aware of sub-device specific function parameters. As such it's not a
>>>>>> very good idea to require that a driver is aware of the value range of
>>>>>> another driver's parameter. I wonder if a simple enumeration interface
>>>>>> would help here --- if I understand correctly, the purpose is just to
>>>>>> provide a way to choose the input using VIDIOC_S_INPUT.
>>>>>>
>>>>>> I guess that's somehow ok as long as you have no other combinations of
>>>>>> these devices but this is hardly future-proof. (And certainly not a
>>>>>> problem created by this patch.)
>>>>>
>>>>> Yeah, this is far from future proof.
>>>>>
>>>>>> It'd be still nice to fix that as presumably we don't have the option of
>>>>>> reworking how we expect the device tree to look like.
>>>>>
>>>>> Agreed.
>>>>>
>>>>> I'm just hoping someone can shed som light on "how we expect the device
>>>>> tree to look". ;)
>>>>
>>>> :-)
>>>>
>>>> For the tvp514x, do you need more than a single endpoint on the receiver
>>>> side? Does the input that's selected affect the bus parameters?
>>>>
>>>> If it doesn't, you could create a custom endpoint property for the possible
>>>> input values. The s_routing() really should be fixed though, but that could
>>>> be postponed I guess. There are quite a few drivers using it.
>>>
>>> There's two ways to look at s_routing() in my opinion, as the calling driver
>>> should really not hardcode any knowledge specific to a particular subdev. We
>>> can either have the calling driver discover the possible routing options at
>>> runtime through the subdev API, or modify the s_routing() API.
>>>
>>
>> Some historical perspective: s_routing was added well before the device tree
>> was ever used for ARM. And at that time the vast majority of drivers were PCI
>> or USB drivers, very few platform drivers existed (and those typically used
>> sensors, not video receivers).
>>
>> Before s_routing existed the situation was even worse.
>>
>> Basically what s_routing does is a poor-man's device tree entry, telling the
>> subdev how to route video or audio from connector to the output of the chip.
>> Typically the card tables in PCI or USB drivers contain the correct arguments
>> for s_routing. Of course, today we'd do that with the DT, but that was not an
>> option years ago.
>
> So I'm still confused on the path forward here.
>
> I do not have the time (or the V4L2 knowledge/experience) to rework the
> V4L2 internals to make this work, but I'm happy to test if someone else
> is working on it.
>
> In the meantime, what do we do with this series? I have a couple minor
> things to fixup based on review comments, but other than that, the
> s_routing decision is blocking this from getting an update for use on DT
> platforms.
>
> The alternative is to go the OMAP route for legacy drivers like this and
> just use pdata quirks for passing the legacy pdata (which has the input
> and output routes hard-coded in platform_data).
Also, FYI, I have the same issue with the output/display side of this
controller. It's using an I2C-connected adv7343, where the input and
output routes are configured by the driver using s_routing, and the
current code passes the routes in using platform_data.
Kevin
--
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 3/5] ARM: BCM5301X: Set GPIO enabling USB power on Netgear R7000
From: Jon Mason @ 2016-12-06 19:59 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Florian Fainelli, Arnd Bergmann, Rob Herring, Mark Rutland,
Russell King, Hauke Mehrtens,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rafał Miłecki
In-Reply-To: <20161206171714.22738-3-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Tue, Dec 06, 2016 at 06:17:12PM +0100, Rafał Miłecki wrote:
> There is one GPIO controlling power for both USB ports.
>
> Signed-off-by: Rafał Miłecki <zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
Was the double Signed-off-by intentional?
> ---
> arch/arm/boot/dts/bcm4709-netgear-r7000.dts | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm/boot/dts/bcm4709-netgear-r7000.dts b/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
> index 0225d82..7ab1176 100644
> --- a/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
> +++ b/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
> @@ -100,3 +100,11 @@
> };
> };
> };
> +
> +&usb2 {
> + vcc-gpio = <&chipcommon 0 GPIO_ACTIVE_HIGH>;
> +};
> +
> +&usb3 {
> + vcc-gpio = <&chipcommon 0 GPIO_ACTIVE_HIGH>;
> +};
> --
> 2.10.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 4/5] ARM: BCM5301X: Specify all RAM by including extra block
From: Jon Mason @ 2016-12-06 20:06 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Florian Fainelli, Arnd Bergmann, Rob Herring, Mark Rutland,
Russell King, Hauke Mehrtens,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rafał Miłecki
In-Reply-To: <20161206171714.22738-4-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Tue, Dec 06, 2016 at 06:17:13PM +0100, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
>
> So far we were specifying only the first block which is always limited
> up to 128 MiB. There are many devices with 256 MiB and few with 512 MiB.
Assuming that NS is like NSP (and I'm pretty sure it is), there are 2
ways to access the first 128M of RAM, a proxy starting at address 0
and the real address. I think you are splitting RAM by accessing it
both ways, when you really should just be accessing it at the real
address.
Thanks,
Jon
>
> Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
> ---
> arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dts | 3 ++-
> arch/arm/boot/dts/bcm4708-asus-rt-ac68u.dts | 3 ++-
> arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts | 3 ++-
> arch/arm/boot/dts/bcm4708-netgear-r6250.dts | 3 ++-
> arch/arm/boot/dts/bcm4708-netgear-r6300-v2.dts | 3 ++-
> arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts | 3 ++-
> arch/arm/boot/dts/bcm47081-asus-rt-n18u.dts | 3 ++-
> arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts | 3 ++-
> arch/arm/boot/dts/bcm47081-buffalo-wzr-900dhp.dts | 3 ++-
> arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts | 3 ++-
> arch/arm/boot/dts/bcm4709-buffalo-wxr-1900dhp.dts | 3 ++-
> arch/arm/boot/dts/bcm4709-netgear-r7000.dts | 3 ++-
> arch/arm/boot/dts/bcm4709-netgear-r8000.dts | 3 ++-
> arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts | 3 ++-
> arch/arm/boot/dts/bcm47094-netgear-r8500.dts | 3 ++-
> 15 files changed, 30 insertions(+), 15 deletions(-)
>
> diff --git a/arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dts b/arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dts
> index 112a5a8..d241cee 100644
> --- a/arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dts
> +++ b/arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dts
> @@ -21,7 +21,8 @@
> };
>
> memory {
> - reg = <0x00000000 0x08000000>;
> + reg = <0x00000000 0x08000000
> + 0x88000000 0x08000000>;
> };
>
> leds {
> diff --git a/arch/arm/boot/dts/bcm4708-asus-rt-ac68u.dts b/arch/arm/boot/dts/bcm4708-asus-rt-ac68u.dts
> index 3600f56..b0e6204 100644
> --- a/arch/arm/boot/dts/bcm4708-asus-rt-ac68u.dts
> +++ b/arch/arm/boot/dts/bcm4708-asus-rt-ac68u.dts
> @@ -21,7 +21,8 @@
> };
>
> memory {
> - reg = <0x00000000 0x08000000>;
> + reg = <0x00000000 0x08000000
> + 0x88000000 0x08000000>;
> };
>
> leds {
> diff --git a/arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts b/arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts
> index d49afec0..c9ba6b9 100644
> --- a/arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts
> +++ b/arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dts
> @@ -21,7 +21,8 @@
> };
>
> memory {
> - reg = <0x00000000 0x08000000>;
> + reg = <0x00000000 0x08000000
> + 0x88000000 0x18000000>;
> };
>
> spi {
> diff --git a/arch/arm/boot/dts/bcm4708-netgear-r6250.dts b/arch/arm/boot/dts/bcm4708-netgear-r6250.dts
> index 8519548..b9f66c0 100644
> --- a/arch/arm/boot/dts/bcm4708-netgear-r6250.dts
> +++ b/arch/arm/boot/dts/bcm4708-netgear-r6250.dts
> @@ -21,7 +21,8 @@
> };
>
> memory {
> - reg = <0x00000000 0x08000000>;
> + reg = <0x00000000 0x08000000
> + 0x88000000 0x08000000>;
> };
>
> leds {
> diff --git a/arch/arm/boot/dts/bcm4708-netgear-r6300-v2.dts b/arch/arm/boot/dts/bcm4708-netgear-r6300-v2.dts
> index 6229ef2..ae0199f 100644
> --- a/arch/arm/boot/dts/bcm4708-netgear-r6300-v2.dts
> +++ b/arch/arm/boot/dts/bcm4708-netgear-r6300-v2.dts
> @@ -21,7 +21,8 @@
> };
>
> memory {
> - reg = <0x00000000 0x08000000>;
> + reg = <0x00000000 0x08000000
> + 0x88000000 0x08000000>;
> };
>
> leds {
> diff --git a/arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts b/arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts
> index 74cfcd3..36b628b1 100644
> --- a/arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts
> +++ b/arch/arm/boot/dts/bcm4708-smartrg-sr400ac.dts
> @@ -21,7 +21,8 @@
> };
>
> memory {
> - reg = <0x00000000 0x08000000>;
> + reg = <0x00000000 0x08000000
> + 0x88000000 0x08000000>;
> };
>
> leds {
> diff --git a/arch/arm/boot/dts/bcm47081-asus-rt-n18u.dts b/arch/arm/boot/dts/bcm47081-asus-rt-n18u.dts
> index 71b98cf..db8608b 100644
> --- a/arch/arm/boot/dts/bcm47081-asus-rt-n18u.dts
> +++ b/arch/arm/boot/dts/bcm47081-asus-rt-n18u.dts
> @@ -21,7 +21,8 @@
> };
>
> memory {
> - reg = <0x00000000 0x08000000>;
> + reg = <0x00000000 0x08000000
> + 0x88000000 0x08000000>;
> };
>
> leds {
> diff --git a/arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts b/arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts
> index 2922536..d51586d 100644
> --- a/arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts
> +++ b/arch/arm/boot/dts/bcm47081-buffalo-wzr-600dhp2.dts
> @@ -21,7 +21,8 @@
> };
>
> memory {
> - reg = <0x00000000 0x08000000>;
> + reg = <0x00000000 0x08000000
> + 0x88000000 0x08000000>;
> };
>
> spi {
> diff --git a/arch/arm/boot/dts/bcm47081-buffalo-wzr-900dhp.dts b/arch/arm/boot/dts/bcm47081-buffalo-wzr-900dhp.dts
> index 184fd92..de041b8 100644
> --- a/arch/arm/boot/dts/bcm47081-buffalo-wzr-900dhp.dts
> +++ b/arch/arm/boot/dts/bcm47081-buffalo-wzr-900dhp.dts
> @@ -21,7 +21,8 @@
> };
>
> memory {
> - reg = <0x00000000 0x08000000>;
> + reg = <0x00000000 0x08000000
> + 0x88000000 0x08000000>;
> };
>
> gpio-keys {
> diff --git a/arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts b/arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts
> index eac0f52..eaca687 100644
> --- a/arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts
> +++ b/arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dts
> @@ -21,7 +21,8 @@
> };
>
> memory {
> - reg = <0x00000000 0x08000000>;
> + reg = <0x00000000 0x08000000
> + 0x88000000 0x08000000>;
> };
>
> leds {
> diff --git a/arch/arm/boot/dts/bcm4709-buffalo-wxr-1900dhp.dts b/arch/arm/boot/dts/bcm4709-buffalo-wxr-1900dhp.dts
> index aab39c9..b32957c 100644
> --- a/arch/arm/boot/dts/bcm4709-buffalo-wxr-1900dhp.dts
> +++ b/arch/arm/boot/dts/bcm4709-buffalo-wxr-1900dhp.dts
> @@ -21,7 +21,8 @@
> };
>
> memory {
> - reg = <0x00000000 0x08000000>;
> + reg = <0x00000000 0x08000000
> + 0x88000000 0x18000000>;
> };
>
> leds {
> diff --git a/arch/arm/boot/dts/bcm4709-netgear-r7000.dts b/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
> index 7ab1176..f459a98 100644
> --- a/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
> +++ b/arch/arm/boot/dts/bcm4709-netgear-r7000.dts
> @@ -21,7 +21,8 @@
> };
>
> memory {
> - reg = <0x00000000 0x08000000>;
> + reg = <0x00000000 0x08000000
> + 0x88000000 0x08000000>;
> };
>
> leds {
> diff --git a/arch/arm/boot/dts/bcm4709-netgear-r8000.dts b/arch/arm/boot/dts/bcm4709-netgear-r8000.dts
> index 56d38a3..cd13534 100644
> --- a/arch/arm/boot/dts/bcm4709-netgear-r8000.dts
> +++ b/arch/arm/boot/dts/bcm4709-netgear-r8000.dts
> @@ -21,7 +21,8 @@
> };
>
> memory {
> - reg = <0x00000000 0x08000000>;
> + reg = <0x00000000 0x08000000
> + 0x88000000 0x08000000>;
> };
>
> leds {
> diff --git a/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts b/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts
> index 7fb9270..64ded76 100644
> --- a/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts
> +++ b/arch/arm/boot/dts/bcm47094-dlink-dir-885l.dts
> @@ -21,7 +21,8 @@
> };
>
> memory {
> - reg = <0x00000000 0x08000000>;
> + reg = <0x00000000 0x08000000
> + 0x88000000 0x08000000>;
> };
>
> nand: nand@18028000 {
> diff --git a/arch/arm/boot/dts/bcm47094-netgear-r8500.dts b/arch/arm/boot/dts/bcm47094-netgear-r8500.dts
> index 7ecd57c..600795e 100644
> --- a/arch/arm/boot/dts/bcm47094-netgear-r8500.dts
> +++ b/arch/arm/boot/dts/bcm47094-netgear-r8500.dts
> @@ -18,7 +18,8 @@
> };
>
> memory {
> - reg = <0x00000000 0x08000000>;
> + reg = <0x00000000 0x08000000
> + 0x88000000 0x18000000>;
> };
>
> leds {
> --
> 2.10.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 2/6] net: ethernet: ti: cpts: add support for ext rftclk selection
From: Richard Cochran @ 2016-12-06 20:25 UTC (permalink / raw)
To: Grygorii Strashko
Cc: Murali Karicheri, David S. Miller, netdev, Mugunthan V N,
Sekhar Nori, linux-kernel, linux-omap, Rob Herring, devicetree,
Wingman Kwok, linux-clk
In-Reply-To: <11994fbc-3713-6ef7-8a44-8a2442106dfc@ti.com>
On Tue, Dec 06, 2016 at 01:39:40PM -0600, Grygorii Strashko wrote:
> I come with below RFC patch. if no objection I'll move forward with it.
Thanks for following through with this!
The am335x will also need the MUX in its clock tree, won't it?
Thanks,
Richard
^ permalink raw reply
* Re: [PATCH 2/6] net: ethernet: ti: cpts: add support for ext rftclk selection
From: Grygorii Strashko @ 2016-12-06 20:40 UTC (permalink / raw)
To: Richard Cochran
Cc: Murali Karicheri, David S. Miller, netdev-u79uwXL29TY76Z2rM5mHXA,
Mugunthan V N, Sekhar Nori, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA, Wingman Kwok,
linux-clk-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161206202558.GB23605-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
On 12/06/2016 02:25 PM, Richard Cochran wrote:
> On Tue, Dec 06, 2016 at 01:39:40PM -0600, Grygorii Strashko wrote:
>> I come with below RFC patch. if no objection I'll move forward with it.
>
> Thanks for following through with this!
>
> The am335x will also need the MUX in its clock tree, won't it?
>
Not exactly. I do not see CPTS_RFTCLK_SEL register in trm, but looks like
it's already implemented in am335 clock tree:
cpsw_cpts_rft_clk: cpsw_cpts_rft_clk@520 {
#clock-cells = <0>;
compatible = "ti,mux-clock";
clocks = <&dpll_core_m5_ck>, <&dpll_core_m4_ck>;
reg = <0x0520>;
};
and ssigned-clock-xx can be used to change parent in board file:
&cpsw_cpts_rft_clk {
assigned-clocks = <&cpsw_cpts_rft_clk>;
assigned-clock-parents = <&dpll_core_m4_ck>;
};
--
regards,
-grygorii
--
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 4/6] net: ethernet: ti: cpts: add ptp pps support
From: Grygorii Strashko @ 2016-12-06 20:43 UTC (permalink / raw)
To: Richard Cochran
Cc: David S. Miller, netdev, Mugunthan V N, Sekhar Nori, linux-kernel,
linux-omap, Rob Herring, devicetree, Murali Karicheri,
Wingman Kwok
In-Reply-To: <20161206180857.GA20680@localhost.localdomain>
On 12/06/2016 12:08 PM, Richard Cochran wrote:
> On Wed, Nov 30, 2016 at 11:05:19AM +0100, Richard Cochran wrote:
>> Can you adjust the frequency of the keystone devices in hardware? If
>> so, then please implement it, and just disable PPS for the CPSW.
>>
>> The only reason I used the timecounter for frequency adjustment was
>> because the am335x HW is broken. But this shouldn't hold back other
>> newer HW without the same silicon flaws.
>
> I am talking here about the ADPLLLJ units. Are they usable on the
> keystone?
>
> If so, please implement the frequency adjustment with them.
>
No, I think it's not impossible (at least as I know now).
i'll drop this patch for now.
By the way, I've tested am335 (BBB)+ HW_TS_PUSH + PWM.
Seems works.
--
regards,
-grygorii
^ permalink raw reply
* Re: [PATCH 4/5] ARM: BCM5301X: Specify all RAM by including extra block
From: Rafał Miłecki @ 2016-12-06 20:57 UTC (permalink / raw)
To: Jon Mason
Cc: Mark Rutland, devicetree@vger.kernel.org, Florian Fainelli,
Arnd Bergmann, Hauke Mehrtens, Russell King,
Linux Kernel Mailing List, Rob Herring, bcm-kernel-feedback-list,
Rafał Miłecki, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20161206200621.GB2768@broadcom.com>
On 6 December 2016 at 21:06, Jon Mason <jon.mason@broadcom.com> wrote:
> On Tue, Dec 06, 2016 at 06:17:13PM +0100, Rafał Miłecki wrote:
>> From: Rafał Miłecki <rafal@milecki.pl>
>>
>> So far we were specifying only the first block which is always limited
>> up to 128 MiB. There are many devices with 256 MiB and few with 512 MiB.
>
> Assuming that NS is like NSP (and I'm pretty sure it is), there are 2
> ways to access the first 128M of RAM, a proxy starting at address 0
> and the real address. I think you are splitting RAM by accessing it
> both ways, when you really should just be accessing it at the real
> address.
I need some more help, please.
This patch (quite well tested) confirms that 0x88000000 can be used to
access RAM at offset 128 MiB. If this is a real address and whole
space is contiguous, it means the base real address should be
0x80000000. So using 0x0 and 0x80000000 should allow accessing
beginning of the RAM. I took a device that was working just fine with:
reg = <0x00000000 0x08000000>;
and I replaced it with:
reg = <0x80000000 0x08000000>;
but it broke things, kernel didn't boot with the last message being:
[ 0.000000] Memory policy: Data cache writealloc
I can see that bcm958525er.dts, bcm958525xmc.dts, bcm958623hr.dts,
bcm958625k.dts bcm988312hr.dts are using 0x60000000 as base address.
It seems to be different from Northstar but I tried following entry
anyway:
reg = <0x60000000 0x08000000>;
and I got kernel hang just like in the previous try.
Did I miss something? Or does Northstar seem to be actually different than NSP?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 14/22] dt-bindings: display: dw-hdmi: Clean up DT bindings documentation
From: Rob Herring @ 2016-12-06 21:15 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Fabio Estevam, Jose Abreu, Ulrich Hecht, devicetree,
Kieran Bingham, dri-devel, linux-renesas-soc, Russell King,
Andy Yan, Vladimir Zapolskiy
In-Reply-To: <1480635817-1258-15-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
On Fri, Dec 02, 2016 at 01:43:29AM +0200, Laurent Pinchart wrote:
> Make it clear that the core bridge/dw_hdmi.txt document isn't a device
> tree binding by itself but is meant to be referenced by platform device
> tree bindings, and update the Rockchip and Freescale DWC HDMI TX
> bindings to reference it.
>
> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> ---
> .../devicetree/bindings/display/bridge/dw_hdmi.txt | 85 +++++++++-------------
> .../devicetree/bindings/display/imx/hdmi.txt | 51 +++++++------
> .../bindings/display/rockchip/dw_hdmi-rockchip.txt | 43 +++++++----
> 3 files changed, 91 insertions(+), 88 deletions(-)
Acked-by: Rob Herring <robh@kernel.org>
Really, the ddc-i2c-bus prop needs to move to a connector node, but
that's a separate problem. We might also want to drop the 'ddc-' part
and have a generic way to refer to an i2c bus. There's a couple of other
cases.
Rob
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 15/22] dt-bindings: display: renesas: Add R-Car Gen3 HDMI TX DT bindings
From: Rob Herring @ 2016-12-06 21:18 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Fabio Estevam, Jose Abreu, Ulrich Hecht, devicetree,
Kieran Bingham, dri-devel, linux-renesas-soc, Russell King,
Andy Yan, Vladimir Zapolskiy
In-Reply-To: <1480635817-1258-16-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
On Fri, Dec 02, 2016 at 01:43:30AM +0200, Laurent Pinchart wrote:
> The Renesas R-Car Gen3 SoCs use a Synopsys DWC HDMI TX encoder IP. Add
> corresponding device tree bindings based on the DWC HDMI TX bindings
> model.
>
> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> ---
> .../bindings/display/bridge/renesas,dw-hdmi.txt | 75 ++++++++++++++++++++++
> MAINTAINERS | 1 +
> 2 files changed, 76 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
Acked-by: Rob Herring <robh@kernel.org>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v3 -next 2/2] ARM: dts: sunxi: add support for Orange Pi Zero board
From: Alexey Kardashevskiy @ 2016-12-06 21:52 UTC (permalink / raw)
To: Icenowy Zheng
Cc: devicetree, Vishnu Patekar, Arnd Bergmann, linux-doc,
Andre Przywara, linux-kernel, Russell King, Hans de Goede,
linux-sunxi, Rob Herring, Maxime Ripard, Chen-Yu Tsai,
linux-arm-kernel
In-Reply-To: <20161206104343.hb8GsYcB@smtp2j.mail.yandex.net>
On 06/12/16 18:43, Icenowy Zheng wrote:
>
> 2016年12月6日 09:51于 Alexey Kardashevskiy <aik@ozlabs.ru>写道：
>>
>> On 03/12/16 02:05, Icenowy Zheng wrote:
>>> Orange Pi Zero is a board that came with the new Allwinner H2+ SoC and a
>>> SDIO Wi-Fi chip by Allwinner (XR819).
>>>
>>> Add a device tree file for it.
>>>
>>> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
>>> ---
>>> Changes since v2:
>>> - Merged SDIO Wi-Fi patch into it.
>>> - SDIO Wi-Fi: add a ethernet1 alias to it, as it has no internal NVRAM.
>>> - SDIO Wi-Fi: changed pinctrl binding to generic pinconf
>>> - removed all gpio pinctrl nodes
>>> - changed h2plus to h2-plus
>>> Changes since v1:
>>> - Convert to generic pinconf bindings.
>>> - SDIO Wi-Fi: add patch.
>>>
>>> Some notes:
>>> - The uart1 and uart2 is available on the unsoldered gpio header.
>>> - The onboard USB connector has its Vbus directly connected to DCIN-5V (the
>>> power jack)
>>>
>>> arch/arm/boot/dts/Makefile | 1 +
>>> arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts | 159 ++++++++++++++++++++++
>>> 2 files changed, 160 insertions(+)
>>> create mode 100644 arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
>>>
>>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>>> index 6447abc..59f6e86 100644
>>> --- a/arch/arm/boot/dts/Makefile
>>> +++ b/arch/arm/boot/dts/Makefile
>>> @@ -844,6 +844,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
>>> sun8i-a33-sinlinx-sina33.dtb \
>>> sun8i-a83t-allwinner-h8homlet-v2.dtb \
>>> sun8i-a83t-cubietruck-plus.dtb \
>>> + sun8i-h2-plus-orangepi-zero.dtb \
>>> sun8i-h3-bananapi-m2-plus.dtb \
>>> sun8i-h3-nanopi-neo.dtb \
>>> sun8i-h3-orangepi-2.dtb \
>>> diff --git a/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
>>> new file mode 100644
>>> index 0000000..d18807f
>>> --- /dev/null
>>> +++ b/arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts
>>> @@ -0,0 +1,159 @@
>>> +/*
>>> + * Copyright (C) 2016 Icenowy Zheng <icenowy@aosc.xyz>
>>> + *
>>> + * Based on sun8i-h3-orangepi-one.dts, which is:
>>> + * Copyright (C) 2016 Hans de Goede <hdegoede@redhat.com>
>>> + *
>>> + * This file is dual-licensed: you can use it either under the terms
>>> + * of the GPL or the X11 license, at your option. Note that this dual
>>> + * licensing only applies to this file, and not this project as a
>>> + * whole.
>>> + *
>>> + * a) This file is free software; you can redistribute it and/or
>>> + * modify it under the terms of the GNU General Public License as
>>> + * published by the Free Software Foundation; either version 2 of the
>>> + * License, or (at your option) any later version.
>>> + *
>>> + * This file 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.
>>> + *
>>> + * Or, alternatively,
>>> + *
>>> + * b) Permission is hereby granted, free of charge, to any person
>>> + * obtaining a copy of this software and associated documentation
>>> + * files (the "Software"), to deal in the Software without
>>> + * restriction, including without limitation the rights to use,
>>> + * copy, modify, merge, publish, distribute, sublicense, and/or
>>> + * sell copies of the Software, and to permit persons to whom the
>>> + * Software is furnished to do so, subject to the following
>>> + * conditions:
>>> + *
>>> + * The above copyright notice and this permission notice shall be
>>> + * included in all copies or substantial portions of the Software.
>>> + *
>>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>>> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
>>> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
>>> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
>>> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
>>> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>>> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
>>> + * OTHER DEALINGS IN THE SOFTWARE.
>>> + */
>>> +
>>> +/dts-v1/;
>>> +#include "sun8i-h3.dtsi"
>>> +#include "sunxi-common-regulators.dtsi"
>>> +
>>> +#include <dt-bindings/gpio/gpio.h>
>>> +#include <dt-bindings/input/input.h>
>>> +#include <dt-bindings/pinctrl/sun4i-a10.h>
>>> +
>>> +/ {
>>> + model = "Xunlong Orange Pi Zero";
>>> + compatible = "xunlong,orangepi-zero", "allwinner,sun8i-h2-plus";
>>> +
>>> + aliases {
>>> + serial0 = &uart0;
>>> + /* ethernet0 is the H3 emac, defined in sun8i-h3.dtsi */
>>
>>
>> It is not defined there as for:
>>
>> cef87e9 (tag: next-20161205) 20 hours ago Stephen Rothwell Add linux-next
>> specific files for 20161205
>
> The driver of H3's obfuscated DesignWare MAC is not yet mainlined, so there won't be one ethernet0 now.
>
> But it's reserved for the onboard Ethernet.
Could you please elaborate how you tested this patch (ideally some tree
somewhere on github)? This patch added RX819, it assumes EMAC support is
there, neither is there nor there is a way to test this... Thanks.
>
>>
>>
>>
>>
>>
>>> + ethernet1 = &xr819;
>>> + };
>>> +
>>> + chosen {
>>> + stdout-path = "serial0:115200n8";
>>> + };
>>> +
>>> + leds {
>>> + compatible = "gpio-leds";
>>> +
>>> + pwr_led {
>>> + label = "orangepi:green:pwr";
>>> + gpios = <&r_pio 0 10 GPIO_ACTIVE_HIGH>;
>>> + default-state = "on";
>>> + };
>>> +
>>> + status_led {
>>> + label = "orangepi:red:status";
>>> + gpios = <&pio 0 17 GPIO_ACTIVE_HIGH>;
>>> + };
>>> + };
>>> +
>>> + reg_vcc_wifi: reg_vcc_wifi {
>>> + compatible = "regulator-fixed";
>>> + regulator-min-microvolt = <3300000>;
>>> + regulator-max-microvolt = <3300000>;
>>> + regulator-name = "vcc-wifi";
>>> + enable-active-high;
>>> + gpio = <&pio 0 20 GPIO_ACTIVE_HIGH>;
>>> + };
>>> +
>>> + wifi_pwrseq: wifi_pwrseq {
>>> + compatible = "mmc-pwrseq-simple";
>>> + reset-gpios = <&r_pio 0 7 GPIO_ACTIVE_LOW>;
>>> + };
>>> +};
>>> +
>>> +&ehci1 {
>>> + status = "okay";
>>> +};
>>> +
>>> +&mmc0 {
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&mmc0_pins_a>;
>>> + vmmc-supply = <®_vcc3v3>;
>>> + bus-width = <4>;
>>> + cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
>>> + cd-inverted;
>>> + status = "okay";
>>> +};
>>> +
>>> +&mmc1 {
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&mmc1_pins_a>;
>>> + vmmc-supply = <®_vcc_wifi>;
>>> + mmc-pwrseq = <&wifi_pwrseq>;
>>> + bus-width = <4>;
>>> + non-removable;
>>> + status = "okay";
>>> +
>>> + /*
>>> + * Explicitly define the sdio device, so that we can add an ethernet
>>> + * alias for it (which e.g. makes u-boot set a mac-address).
>>> + */
>>> + xr819: sdio_wifi@1 {
>>> + reg = <1>;
>>> + };
>>> +};
>>> +
>>> +&mmc1_pins_a {
>>> + bias-pull-up;
>>> +};
>>> +
>>> +&ohci1 {
>>> + status = "okay";
>>> +};
>>> +
>>> +&uart0 {
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&uart0_pins_a>;
>>> + status = "okay";
>>> +};
>>> +
>>> +&uart1 {
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&uart1_pins>;
>>> + status = "disabled";
>>> +};
>>> +
>>> +&uart2 {
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&uart2_pins>;
>>> + status = "disabled";
>>> +};
>>> +
>>> +&usbphy {
>>> + /* USB VBUS is always on */
>>> + status = "okay";
>>> +};
>>>
>>
>>
>> --
>> Alexey
--
Alexey
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 4/5] ARM: BCM5301X: Specify all RAM by including extra block
From: Jon Mason @ 2016-12-06 22:26 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Florian Fainelli, Arnd Bergmann, Rob Herring, Mark Rutland,
Russell King, Hauke Mehrtens, bcm-kernel-feedback-list,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Linux Kernel Mailing List, Rafał Miłecki
In-Reply-To: <CACna6rwdKHtgp+g58B3HrDnkYZoGGZUdSqVFAGXZbf8tNTBZPg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, Dec 06, 2016 at 09:57:31PM +0100, Rafał Miłecki wrote:
> On 6 December 2016 at 21:06, Jon Mason <jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> wrote:
> > On Tue, Dec 06, 2016 at 06:17:13PM +0100, Rafał Miłecki wrote:
> >> From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
> >>
> >> So far we were specifying only the first block which is always limited
> >> up to 128 MiB. There are many devices with 256 MiB and few with 512 MiB.
> >
> > Assuming that NS is like NSP (and I'm pretty sure it is), there are 2
> > ways to access the first 128M of RAM, a proxy starting at address 0
> > and the real address. I think you are splitting RAM by accessing it
> > both ways, when you really should just be accessing it at the real
> > address.
>
> I need some more help, please.
>
> This patch (quite well tested) confirms that 0x88000000 can be used to
> access RAM at offset 128 MiB. If this is a real address and whole
> space is contiguous, it means the base real address should be
> 0x80000000. So using 0x0 and 0x80000000 should allow accessing
> beginning of the RAM. I took a device that was working just fine with:
> reg = <0x00000000 0x08000000>;
> and I replaced it with:
> reg = <0x80000000 0x08000000>;
> but it broke things, kernel didn't boot with the last message being:
> [ 0.000000] Memory policy: Data cache writealloc
>
> I can see that bcm958525er.dts, bcm958525xmc.dts, bcm958623hr.dts,
> bcm958625k.dts bcm988312hr.dts are using 0x60000000 as base address.
> It seems to be different from Northstar but I tried following entry
> anyway:
> reg = <0x60000000 0x08000000>;
> and I got kernel hang just like in the previous try.
>
> Did I miss something? Or does Northstar seem to be actually different than NSP?
Per the BCM5301X Preliminary Programmer's Register Reference guide
(page 394), under the second titled "System Address Mapping".
There is a table listing the System Address Mapping. The parts that
are of interest in this converstation are (and forgive my
approxmiation, but I cannot cut'n'paste from it):
Address Range Size Description
---------------------------------------------------
0x0000_0000-0x07FF_FFFF 128 MB DDR2/3 SDRAM Memory Region*
0x8000_0000-0xBFFF_FFFF 1 G DDR2/3 SDRAM Large Region
* The DDR2/3 SDRAM Memory Region (128MB) is a subset of the DDR2/3
SDRAM Large Region (1GB). Additionally, 0x0000_0000-0x07FF_FFFF is
aliased to 0x8000_0000-0x87FF_FFFF
However, since you say it isn't working for you, then there must be
some other missing peice. I'll retract my comment for now, and
hopefully we can double back and get it working in the future.
Thanks,
Jon
--
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 1/2] dt-bindings: mmc: add DT binding for S3C24XX MMC/SD/SDIO controller
From: Rob Herring @ 2016-12-06 23:13 UTC (permalink / raw)
To: Jaehoon Chung
Cc: Sergio Prado, ulf.hansson, mark.rutland, linux-mmc, devicetree,
linux-kernel, ben-linux, linux-arm-kernel
In-Reply-To: <054a65d8-8606-eeb0-e028-1b85dbf1c8ba@samsung.com>
On Fri, Dec 02, 2016 at 09:48:45AM +0900, Jaehoon Chung wrote:
> On 12/02/2016 09:14 AM, Sergio Prado wrote:
> > Adds the device tree bindings description for Samsung S3C24XX
> > MMC/SD/SDIO controller, used as a connectivity interface with external
> > MMC, SD and SDIO storage mediums.
> >
> > Signed-off-by: Sergio Prado <sergio.prado@e-labworks.com>
> > ---
> > .../devicetree/bindings/mmc/samsung,s3cmci.txt | 38 ++++++++++++++++++++++
> > 1 file changed, 38 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/mmc/samsung,s3cmci.txt
> >
> > diff --git a/Documentation/devicetree/bindings/mmc/samsung,s3cmci.txt b/Documentation/devicetree/bindings/mmc/samsung,s3cmci.txt
> > new file mode 100644
> > index 000000000000..3f044076e69a
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mmc/samsung,s3cmci.txt
> > @@ -0,0 +1,38 @@
> > +* Samsung's S3C24XX MMC/SD/SDIO controller device tree bindings
> > +
> > +Samsung's S3C24XX MMC/SD/SDIO controller is used as a connectivity interface
> > +with external MMC, SD and SDIO storage mediums.
> > +
> > +This file documents differences between the core mmc properties described by
> > +mmc.txt and the properties used by the Samsung S3C24XX MMC/SD/SDIO controller
> > +implementation.
> > +
> > +Required SoC Specific Properties:
> > +- compatible: should be one of the following
> > + - "samsung,s3c2410-sdi": for controllers compatible with s3c2410
> > + - "samsung,s3c2412-sdi": for controllers compatible with s3c2412
> > + - "samsung,s3c2440-sdi": for controllers compatible with s3c2440
> > +- clocks: Should reference the controller clock
> > +- clock-names: Should contain "sdi"
> > +
> > +Required Board Specific Properties:
> > +- pinctrl-0: Should specify pin control groups used for this controller.
> > +- pinctrl-names: Should contain only one value - "default".
>
> I'm not sure but i think this description doesn't need at here.
>
> > +
> > +Example:
> > + sdi: sdi@5a000000 {
>
> I think it needs to use "mmc0: sdi@5a000000" instead of "sdi: sdi@5a000000"
> Because mmc is more clear than sdi.
The label doesn't matter much as it is not part of the dtb. The unit
name should be 'mmc' though.
With that,
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v5 00/13] net: ethernet: ti: cpts: update and fixes
From: Grygorii Strashko @ 2016-12-07 0:00 UTC (permalink / raw)
To: David S. Miller, netdev, Mugunthan V N, Richard Cochran
Cc: Sekhar Nori, linux-kernel, linux-omap, devicetree,
Murali Karicheri, Wingman Kwok, Thomas Gleixner,
Grygorii Strashko
It is preparation series intended to clean up and optimize TI CPTS driver to
facilitate further integration with other TI's SoCs like Keystone 2.
Changes in v5:
- fixed copy paste error in cpts_release
- reworked cc.mult/shift and cc_mult initialization
Changes in v4:
- fixed build error in patch
"net: ethernet: ti: cpts: clean up event list if event pool is empty"
- rebased on top of net-next
Changes in v3:
- patches reordered: fixes and small updates moved first
- added comments in code about cpts->cc_mult
- conversation range (maxsec) limited to 10sec
Changes in v2:
- patch "net: ethernet: ti: cpts: rework initialization/deinitialization"
was split on 4 patches
- applied comments from Richard Cochran
- dropped patch
"net: ethernet: ti: cpts: add return value to tx and rx timestamp funcitons"
- new patches added:
"net: ethernet: ti: cpts: drop excessive writes to CTRL and INT_EN regs"
and "clocksource: export the clocks_calc_mult_shift to use by timestamp code"
Links on prev versions:
v4: https://lkml.org/lkml/2016/12/6/496
v3: https://www.spinics.net/lists/devicetree/msg153474.html
v2: http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1282034.html
v1: http://www.spinics.net/lists/linux-omap/msg131925.html
Grygorii Strashko (11):
net: ethernet: ti: cpts: switch to readl/writel_relaxed()
net: ethernet: ti: allow cpts to be built separately
net: ethernet: ti: cpsw: minimize direct access to struct cpts
net: ethernet: ti: cpts: fix unbalanced clk api usage in cpts_register/unregister
net: ethernet: ti: cpts: fix registration order
net: ethernet: ti: cpts: disable cpts when unregistered
net: ethernet: ti: cpts: drop excessive writes to CTRL and INT_EN regs
net: ethernet: ti: cpts: rework initialization/deinitialization
net: ethernet: ti: cpts: move dt props parsing to cpts driver
net: ethernet: ti: cpts: calc mult and shift from refclk freq
net: ethernet: ti: cpts: fix overflow check period
Murali Karicheri (1):
clocksource: export the clocks_calc_mult_shift to use by timestamp code
WingMan Kwok (1):
net: ethernet: ti: cpts: clean up event list if event pool is empty
Documentation/devicetree/bindings/net/cpsw.txt | 8 +-
drivers/net/ethernet/ti/Kconfig | 2 +-
drivers/net/ethernet/ti/Makefile | 3 +-
drivers/net/ethernet/ti/cpsw.c | 84 ++++-----
drivers/net/ethernet/ti/cpsw.h | 2 -
drivers/net/ethernet/ti/cpts.c | 233 ++++++++++++++++++-------
drivers/net/ethernet/ti/cpts.h | 80 ++++++++-
kernel/time/clocksource.c | 1 +
8 files changed, 297 insertions(+), 116 deletions(-)
--
2.10.1
^ permalink raw reply
* [PATCH v5 01/13] net: ethernet: ti: cpts: switch to readl/writel_relaxed()
From: Grygorii Strashko @ 2016-12-07 0:00 UTC (permalink / raw)
To: David S. Miller, netdev, Mugunthan V N, Richard Cochran
Cc: Sekhar Nori, linux-kernel, linux-omap, devicetree,
Murali Karicheri, Wingman Kwok, Thomas Gleixner,
Grygorii Strashko
In-Reply-To: <20161207000045.28333-1-grygorii.strashko@ti.com>
Switch to readl/writel_relaxed() APIs, because this is recommended
API and the CPTS IP is reused on Keystone 2 SoCs
where LE/BE modes are supported.
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Acked-by: Richard Cochran <richardcochran@gmail.com>
---
drivers/net/ethernet/ti/cpts.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpts.c b/drivers/net/ethernet/ti/cpts.c
index 85a55b4..a42c449 100644
--- a/drivers/net/ethernet/ti/cpts.c
+++ b/drivers/net/ethernet/ti/cpts.c
@@ -33,8 +33,8 @@
#ifdef CONFIG_TI_CPTS
-#define cpts_read32(c, r) __raw_readl(&c->reg->r)
-#define cpts_write32(c, v, r) __raw_writel(v, &c->reg->r)
+#define cpts_read32(c, r) readl_relaxed(&c->reg->r)
+#define cpts_write32(c, v, r) writel_relaxed(v, &c->reg->r)
static int event_expired(struct cpts_event *event)
{
--
2.10.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox