* Re: [PATCH] ASoC: rcar: tidyup simple-card example for CPU node
From: Geert Uytterhoeven @ 2017-12-22 8:02 UTC (permalink / raw)
To: Kuninori Morimoto
Cc: Mark Rutland, devicetree, Linux-ALSA, Geert Uytterhoeven,
Mark Brown, Rob Herring, Simon, Yokoyama
In-Reply-To: <873743nxuj.wl%kuninori.morimoto.gx@renesas.com>
CC DT
On Fri, Dec 22, 2017 at 6:29 AM, Kuninori Morimoto
<kuninori.morimoto.gx@renesas.com> wrote:
>
> From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
>
> commit a5702e1cb3c ("ASoC: rsnd: Drop unit-addresses without reg
> properties") modifies simple-card multi CPU nodes.
> But, naming of "cpu-x" breaks probing.
> Let's add reg = <x>; instead of renaming node.
>
> Reported-by: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx@renesas.com>
> CC: Geert Uytterhoeven <geert+renesas@glider.be>
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> ---
> Documentation/devicetree/bindings/sound/renesas,rsnd.txt | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt
> index 085bec3..51b7324 100644
> --- a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt
> +++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt
> @@ -197,12 +197,17 @@ Ex)
> [MEM] -> [SRC2] -> [CTU03] -+
>
> sound {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> compatible = "simple-scu-audio-card";
> ...
> - simple-audio-card,cpu-0 {
> + simple-audio-card,cpu@0 {
> + reg = <0>;
> sound-dai = <&rcar_sound 0>;
> };
> - simple-audio-card,cpu-1 {
> + simple-audio-card,cpu@1 {
> + reg = <1>;
> sound-dai = <&rcar_sound 1>;
> };
> simple-audio-card,codec {
> --
> 1.9.1
^ permalink raw reply
* Re: [PATCH v3 2/3] hwrng: exynos - add Samsung Exynos True RNG driver
From: Herbert Xu @ 2017-12-22 8:24 UTC (permalink / raw)
To: Łukasz Stelmach
Cc: Andrew F . Davis, PrasannaKumar Muralidharan, Rob Herring,
Matt Mackall, Krzysztof Kozlowski, Kukjin Kim,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-crypto-u79uwXL29TY76Z2rM5mHXA,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Marek Szyprowski,
Bartlomiej Zolnierkiewicz
In-Reply-To: <20171204125351.26805-3-l.stelmach-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
On Mon, Dec 04, 2017 at 01:53:50PM +0100, Łukasz Stelmach wrote:
> Add support for True Random Number Generator found in Samsung Exynos
> 5250+ SoCs.
>
> Signed-off-by: Łukasz Stelmach <l.stelmach-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
This doesn't build for me:
CC [M] drivers/char/hw_random/exynos-trng.o
../drivers/char/hw_random/exynos-trng.c:230:1: error: \u2018exynos_rng_dt_match\u2019 undeclared here (not in a function)
../drivers/char/hw_random/exynos-trng.c:230:1: error: \u2018__mod_of__exynos_rng_dt_match_device_table\u2019 aliased to undefined symbol \u2018exynos_rng_dt_match\u2019
make[2]: *** [drivers/char/hw_random/exynos-trng.o] Error 1
make[1]: *** [_module_drivers/char/hw_random] Error 2
Cheers,
--
Email: Herbert Xu <herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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] ARM: dts: r8a7745: Add missing clock for secondary CA7 CPU core
From: Simon Horman @ 2017-12-22 8:24 UTC (permalink / raw)
To: Chris Paterson, Geert Uytterhoeven
Cc: Biju Das, Rob Herring, Mark Rutland, Magnus Damm, Fabrizio Castro,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <TY1PR06MB070295E987FDDC0093043924B70D0-/PRLmSCtZ14u2TXDOttQZW0DtJ1/0DrXvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
On Thu, Dec 21, 2017 at 02:58:24PM +0000, Chris Paterson wrote:
>
> > From: Biju Das [mailto:biju.das-kTT6dE0pTRh9uiUsa/gSgQ@public.gmane.org]
> > Sent: 21 December 2017 14:52
> >
> > Add the missing clock to CA7 CPU1 node.
> >
> > Signed-off-by: Biju Das <biju.das-kTT6dE0pTRh9uiUsa/gSgQ@public.gmane.org>
>
> Reviewed-by: Chris Paterson <Chris.Paterson2-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
>
> Kind regards, Chris
>
On Thu, Dec 21, 2017 at 04:00:23PM +0100, Geert Uytterhoeven wrote:
> On Thu, Dec 21, 2017 at 3:52 PM, Biju Das <biju.das-kTT6dE0pTRh9uiUsa/gSgQ@public.gmane.org> wrote:
> > Add the missing clock to CA7 CPU1 node.
> >
> > Signed-off-by: Biju Das <biju.das-kTT6dE0pTRh9uiUsa/gSgQ@public.gmane.org>
>
> Reviewed-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
>
> Gr{oetje,eeting}s,
Thanks, applied.
--
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 0/2] arm64: dts: renesas: Remove renesas,no-ether-link property
From: Simon Horman @ 2017-12-22 8:28 UTC (permalink / raw)
To: Vladimir Zapolskiy
Cc: Sergei Shtylyov, Bogdan Mirea,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <39b80de4-84bd-916e-2ff9-580f7db720f2-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
On Thu, Dec 21, 2017 at 04:57:58PM +0200, Vladimir Zapolskiy wrote:
> Hi Simon,
>
> On 12/21/2017 01:28 PM, Simon Horman wrote:
> > On Wed, Dec 20, 2017 at 03:22:10PM +0200, Vladimir Zapolskiy wrote:
> >> The present change is a bug fix for AVB link iteratively up/down.
> >
> > If this is a bug please consider including Fixes tags in the patches.
> >
>
> would you prefer to get v2 with the Fixes tags added or short replies
> to v1 with the requested information?
Either way would be fine. I see you have gone ahead and posted v2,
lets roll with that.
--
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 2/3] hwrng: exynos - add Samsung Exynos True RNG driver
From: Marek Szyprowski @ 2017-12-22 8:29 UTC (permalink / raw)
To: Herbert Xu, Łukasz Stelmach
Cc: Andrew F . Davis, PrasannaKumar Muralidharan, Rob Herring,
Matt Mackall, Krzysztof Kozlowski, Kukjin Kim, devicetree,
linux-crypto, linux-samsung-soc, linux-kernel,
Bartlomiej Zolnierkiewicz
In-Reply-To: <20171222082412.GB29663@gondor.apana.org.au>
Hi,
On 2017-12-22 09:24, Herbert Xu wrote:
> On Mon, Dec 04, 2017 at 01:53:50PM +0100, Łukasz Stelmach wrote:
>> Add support for True Random Number Generator found in Samsung Exynos
>> 5250+ SoCs.
>>
>> Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com>
> This doesn't build for me:
>
> CC [M] drivers/char/hw_random/exynos-trng.o
> ../drivers/char/hw_random/exynos-trng.c:230:1: error: \u2018exynos_rng_dt_match\u2019 undeclared here (not in a function)
> ../drivers/char/hw_random/exynos-trng.c:230:1: error: \u2018__mod_of__exynos_rng_dt_match_device_table\u2019 aliased to undefined symbol \u2018exynos_rng_dt_match\u2019
> make[2]: *** [drivers/char/hw_random/exynos-trng.o] Error 1
> make[1]: *** [_module_drivers/char/hw_random] Error 2
This looks like a missing dependency on "OF" when "COMPILE_TEST" is
selected.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* Re: [PATCH v2 1/2] arm64: dts: renesas: salvator-x: Remove renesas,no-ether-link property
From: Simon Horman @ 2017-12-22 8:32 UTC (permalink / raw)
To: Vladimir Zapolskiy
Cc: Sergei Shtylyov, Bogdan Mirea, linux-renesas-soc, devicetree,
linux-arm-kernel
In-Reply-To: <1513869539-18803-2-git-send-email-vladimir_zapolskiy@mentor.com>
On Thu, Dec 21, 2017 at 05:18:58PM +0200, Vladimir Zapolskiy wrote:
> From: Bogdan Mirea <Bogdan-Stefan_Mirea@mentor.com>
>
> The present change is a bug fix for AVB link iteratively up/down.
>
> Steps to reproduce:
> - start AVB TX stream (Using aplay via MSE),
> - disconnect+reconnect the eth cable,
> - after a reconnection the eth connection goes iteratively up/down
> without user interaction,
> - this may heal after some seconds or even stay for minutes.
>
> As the documentation specifies, the "renesas,no-ether-link" option
> should be used when a board does not provide a proper AVB_LINK signal.
> There is no need for this option enabled on RCAR H3/M3 Salvator-X/XS
> and ULCB starter kits since the AVB_LINK is correctly handled by HW.
>
> Choosing to keep or remove the "renesas,no-ether-link" option will
> have impact on the code flow in the following ways:
> - keeping this option enabled may lead to unexpected behavior since
> the RX & TX are enabled/disabled directly from adjust_link function
> without any HW interrogation,
> - removing this option, the RX & TX will only be enabled/disabled after
> HW interrogation. The HW check is made through the LMON pin in PSR
> register which specifies AVB_LINK signal value (0 - at low level;
> 1 - at high level).
>
> In conclusion, the present change is also a safety improvement because
> it removes the "renesas,no-ether-link" option leading to a proper way
> of detecting the link state based on HW interrogation and not on
> software heuristic.
>
> Fixes: d25e8ff0d5aa ("arm64: dts: renesas: Extract common Salvator-X board support")
The above shuffles the code around but does not introduce the problem
as far as I can see. Instead I think we should use:
Fixes: dc36965a8905 ("arm64: dts: r8a7796: salvator-x: Enable EthernetAVB")
Fixes: 6fa501c549aa ("arm64: dts: r8a7795: enable EthernetAVB on Salvator-X")
> Signed-off-by: Bogdan Mirea <Bogdan-Stefan_Mirea@mentor.com>
> Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
> ---
> arch/arm64/boot/dts/renesas/salvator-common.dtsi | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/renesas/salvator-common.dtsi b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
> index 4e800e933944..c3095bd575d7 100644
> --- a/arch/arm64/boot/dts/renesas/salvator-common.dtsi
> +++ b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
> @@ -255,7 +255,6 @@
> &avb {
> pinctrl-0 = <&avb_pins>;
> pinctrl-names = "default";
> - renesas,no-ether-link;
> phy-handle = <&phy0>;
> status = "okay";
>
> --
> 2.8.1
>
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: renesas: ulcb: Remove renesas,no-ether-link property
From: Simon Horman @ 2017-12-22 8:32 UTC (permalink / raw)
To: Vladimir Zapolskiy
Cc: Sergei Shtylyov, Bogdan Mirea, linux-renesas-soc, devicetree,
linux-arm-kernel
In-Reply-To: <1513869539-18803-3-git-send-email-vladimir_zapolskiy@mentor.com>
On Thu, Dec 21, 2017 at 05:18:59PM +0200, Vladimir Zapolskiy wrote:
> From: Bogdan Mirea <Bogdan-Stefan_Mirea@mentor.com>
>
> The present change is a bug fix for AVB link iteratively up/down.
>
> Steps to reproduce:
> - start AVB TX stream (Using aplay via MSE),
> - disconnect+reconnect the eth cable,
> - after a reconnection the eth connection goes iteratively up/down
> without user interaction,
> - this may heal after some seconds or even stay for minutes.
>
> As the documentation specifies, the "renesas,no-ether-link" option
> should be used when a board does not provide a proper AVB_LINK signal.
> There is no need for this option enabled on RCAR H3/M3 Salvator-X/XS
> and ULCB starter kits since the AVB_LINK is correctly handled by HW.
>
> Choosing to keep or remove the "renesas,no-ether-link" option will
> have impact on the code flow in the following ways:
> - keeping this option enabled may lead to unexpected behavior since
> the RX & TX are enabled/disabled directly from adjust_link function
> without any HW interrogation,
> - removing this option, the RX & TX will only be enabled/disabled after
> HW interrogation. The HW check is made through the LMON pin in PSR
> register which specifies AVB_LINK signal value (0 - at low level;
> 1 - at high level).
>
> In conclusion, the present change is also a safety improvement because
> it removes the "renesas,no-ether-link" option leading to a proper way
> of detecting the link state based on HW interrogation and not on
> software heuristic.
>
> Fixes: 253ed045a34d ("arm64: dts: renesas: Extract common ULCB board support")
The above shuffles the code around but does not introduce the problem
as far as I can see. Instead I think we should use:
Fixes: 144bf6ccb13f ("arm64: dts: h3ulcb: enable EthernetAVB")
Fixes: 883fae315a6a ("arm64: dts: m3ulcb: enable EthernetAVB")
> Signed-off-by: Bogdan Mirea <Bogdan-Stefan_Mirea@mentor.com>
> Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
> ---
> arch/arm64/boot/dts/renesas/ulcb.dtsi | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/renesas/ulcb.dtsi b/arch/arm64/boot/dts/renesas/ulcb.dtsi
> index be91016e0b48..3e7a6b94e9f8 100644
> --- a/arch/arm64/boot/dts/renesas/ulcb.dtsi
> +++ b/arch/arm64/boot/dts/renesas/ulcb.dtsi
> @@ -145,7 +145,6 @@
> &avb {
> pinctrl-0 = <&avb_pins>;
> pinctrl-names = "default";
> - renesas,no-ether-link;
> phy-handle = <&phy0>;
> status = "okay";
>
> --
> 2.8.1
>
^ permalink raw reply
* Re: [PATCH v2] ARM: dts: sunxi: Add sid for a83t
From: Maxime Ripard @ 2017-12-22 8:35 UTC (permalink / raw)
To: Emmanuel Vadot
Cc: Kyle Evans, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Russell King,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Chen-Yu Tsai, Rob Herring,
Srinivas Kandagatla,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20171221190903.56ebae536acf51401c63802c-xXdDKFdH5B3kFDPD4ZthVA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1940 bytes --]
On Thu, Dec 21, 2017 at 07:09:03PM +0100, Emmanuel Vadot wrote:
>
> Hi Maxime,
>
> On Thu, 21 Dec 2017 16:26:30 +0100
> Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
>
> > Hi,
> >
> > On Thu, Dec 21, 2017 at 09:19:24AM -0600, Kyle Evans wrote:
> > > On Thu, Dec 21, 2017 at 8:55 AM, Maxime Ripard
> > > <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> > > > Hi Kyle,
> > > >
> > > > On Tue, Dec 19, 2017 at 03:05:23PM -0600, kevans91-OYTqUY/oFF8@public.gmane.org wrote:
> > > >> Allwinner a83t has a 1 KB sid block with efuse for security rootkey and
> > > >> thermal calibration data, add node to describe it.
> > > >>
> > > >> a83t-sid is not currently supported by nvmem/sunxi-sid, but it is
> > > >> supported in an external driver for FreeBSD.
> > > >>
> > > >> Signed-off-by: Kyle Evans <kevans91-OYTqUY/oFF8@public.gmane.org>
> > > >
> > > > The patch looks fine in itself, but we've had a number of issues with
> > > > the register layout (and access patterns) in the past, so I'd rather
> > > > have something that works in Linux too if possible.
> > >
> > > I have a patch that I think should make it work fine on Linux [1], but
> > > I'm afraid I have little to no capability to test it myself and so I
> > > did not add it as well.
> > >
> > > I do know that the rootkey is offset 0x200 into the given space [2],
> > > as is the case with the H3, and that the readout quirk is not needed.
> > > I wasn't 100% sure that the a83t has 2Kbit worth of efuse space as the
> > > H3, but I do know that thermal data can be found at 0x34 and 0x38 in
> > > this space.
> >
> > Then maybe we should leave it aside until someone takes some time on
> > the A83t.
>
> Take some time on the Linux driver and do not apply this patch for
> now you mean ?
Yep.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH v3 2/3] hwrng: exynos - add Samsung Exynos True RNG driver
From: Herbert Xu @ 2017-12-22 8:35 UTC (permalink / raw)
To: Marek Szyprowski
Cc: Łukasz Stelmach, Andrew F . Davis,
PrasannaKumar Muralidharan, Rob Herring, Matt Mackall,
Krzysztof Kozlowski, Kukjin Kim, devicetree, linux-crypto,
linux-samsung-soc, linux-kernel, Bartlomiej Zolnierkiewicz
In-Reply-To: <916163bb-594b-779d-700c-de9fa15239dd@samsung.com>
On Fri, Dec 22, 2017 at 09:29:38AM +0100, Marek Szyprowski wrote:
> Hi,
>
> On 2017-12-22 09:24, Herbert Xu wrote:
> >On Mon, Dec 04, 2017 at 01:53:50PM +0100, Łukasz Stelmach wrote:
> >>Add support for True Random Number Generator found in Samsung Exynos
> >>5250+ SoCs.
> >>
> >>Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com>
> >This doesn't build for me:
> >
> > CC [M] drivers/char/hw_random/exynos-trng.o
> >../drivers/char/hw_random/exynos-trng.c:230:1: error: \u2018exynos_rng_dt_match\u2019 undeclared here (not in a function)
> >../drivers/char/hw_random/exynos-trng.c:230:1: error: \u2018__mod_of__exynos_rng_dt_match_device_table\u2019 aliased to undefined symbol \u2018exynos_rng_dt_match\u2019
> >make[2]: *** [drivers/char/hw_random/exynos-trng.o] Error 1
> >make[1]: *** [_module_drivers/char/hw_random] Error 2
>
> This looks like a missing dependency on "OF" when "COMPILE_TEST" is
> selected.
Actually it looks like a typo. The variable is actually called
exynos_trng_dt_match as opposed to exynos_rng_dt_match.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH v5] arm64: dts: ls1088a: Add USB support
From: yinbo.zhu @ 2017-12-22 8:38 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Catalin Marinas ), Will Deacon ), Shawn Guo
Cc: Harninder Rai, Zhang Ying-22455, Yuantian Tang,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list, Hou Zhiqiang, Prabhakar Kushwaha, Alison Wang,
xiaobo.xie, Ashish Kumar, jerry.huang, Raghav Dogra, Nipun Gupta,
Yangbo Lu, Amrita Kumari, yinbo . zhu, ran.wang_1,
Bogdan Purcareata, linux-arm-kernel, Laurentiu Tudor
From: yinbo.zhu <yinbo.zhu@nxp.com>
Add USB support on ls1088ardb
Signed-off-by: yinbo zhu <yinbo.zhu@nxp.com>
Signed-off-by: Ran Wang <ran.wang_1@nxp.com>
---
Change in v5:
The usb node was sorted alphabetically in label name.
Remove the point in "yinbo.zhu".
arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts | 8 ++++++++
arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 20 ++++++++++++++++++++
2 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
index 0f6fcda..4f17601 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
@@ -125,3 +125,11 @@
&sata {
status = "okay";
};
+
+&usb0 {
+ status = "okay";
+};
+
+&usb1 {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
index bd80e9a..caf2bdd 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
@@ -394,6 +394,26 @@
status = "disabled";
};
+ usb0: usb3@3100000 {
+ compatible = "snps,dwc3";
+ reg = <0x0 0x3100000 0x0 0x10000>;
+ interrupts = <0 80 IRQ_TYPE_LEVEL_HIGH>;
+ dr_mode = "host";
+ snps,quirk-frame-length-adjustment = <0x20>;
+ snps,dis_rxdet_inp3_quirk;
+ status = "disabled";
+ };
+
+ usb1: usb3@3110000 {
+ compatible = "snps,dwc3";
+ reg = <0x0 0x3110000 0x0 0x10000>;
+ interrupts = <0 81 IRQ_TYPE_LEVEL_HIGH>;
+ dr_mode = "host";
+ snps,quirk-frame-length-adjustment = <0x20>;
+ snps,dis_rxdet_inp3_quirk;
+ status = "disabled";
+ };
+
sata: sata@3200000 {
compatible = "fsl,ls1088a-ahci";
reg = <0x0 0x3200000 0x0 0x10000>,
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] ASoC: max98373: Added Amplifier Driver
From: Philippe Ombredanne @ 2017-12-22 8:39 UTC (permalink / raw)
To: Ryan Lee
Cc: Liam Girdwood, Mark, Rob Herring, Mark Rutland, Jaroslav Kysela,
Takashi Iwai, Arnd Bergmann, afd-l0cyMroinI0,
robert.jarzmik-GANU6spQydw, supercraig0719-Re5JQEeQqe8AvxtiuMwx3w,
jbrunet-rdvid1DuHRBWk0Htik3J/w, dannenberg-l0cyMroinI0,
Romain Perier, bryce.ferguson-lFk7bPDcGtkY5TsXZYaR1UEOCMrvLtNR,
kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ,
m-stecklein-l0cyMroinI0, ALSA,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, LKML,
ryan.lee.maxim-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <1513907030-18441-1-git-send-email-ryans.lee-zxKO94PEStzToO697jQleEEOCMrvLtNR@public.gmane.org>
Ryan,
On Fri, Dec 22, 2017 at 2:43 AM, Ryan Lee <ryans.lee-zxKO94PEStzToO697jQleEEOCMrvLtNR@public.gmane.org> wrote:
> Signed-off-by: Ryan Lee <ryans.lee-zxKO94PEStzToO697jQleEEOCMrvLtNR@public.gmane.org>
> ---
>
> Created max98373 amplifier driver.
>
<snip>
> --- /dev/null
> +++ b/sound/soc/codecs/max98373.c
> @@ -0,0 +1,996 @@
> +/*
> + * max98373.c -- MAX98373 ALSA Soc Audio driver
> + *
> + * Copyright (C) 2017 Maxim Integrated Products
> + * Author: Ryan Lee <ryans.lee-zxKO94PEStzToO697jQleEEOCMrvLtNR@public.gmane.org>
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the License, or (at your
> + * option) any later version.
> + */
Have you considered using the new SPDX tags instead of this fine but
long legalese?
And if other contributors in your team could follow suit and you could
spread the word that would be even better!
See Thomas doc patches [1] for details.
Thanks!
[1] https://lkml.org/lkml/2017/12/4/934
--
Cordially
Philippe Ombredanne
--
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 1/2] arm64: dts: renesas: salvator-x: Remove renesas,no-ether-link property
From: Simon Horman @ 2017-12-22 8:40 UTC (permalink / raw)
To: Vladimir Zapolskiy
Cc: Sergei Shtylyov, Bogdan Mirea, linux-renesas-soc, devicetree,
linux-arm-kernel
In-Reply-To: <20171222083203.h5a65uitv7yok5fz@verge.net.au>
On Fri, Dec 22, 2017 at 09:32:03AM +0100, Simon Horman wrote:
> On Thu, Dec 21, 2017 at 05:18:58PM +0200, Vladimir Zapolskiy wrote:
> > From: Bogdan Mirea <Bogdan-Stefan_Mirea@mentor.com>
> >
> > The present change is a bug fix for AVB link iteratively up/down.
> >
> > Steps to reproduce:
> > - start AVB TX stream (Using aplay via MSE),
> > - disconnect+reconnect the eth cable,
> > - after a reconnection the eth connection goes iteratively up/down
> > without user interaction,
> > - this may heal after some seconds or even stay for minutes.
> >
> > As the documentation specifies, the "renesas,no-ether-link" option
> > should be used when a board does not provide a proper AVB_LINK signal.
> > There is no need for this option enabled on RCAR H3/M3 Salvator-X/XS
> > and ULCB starter kits since the AVB_LINK is correctly handled by HW.
> >
> > Choosing to keep or remove the "renesas,no-ether-link" option will
> > have impact on the code flow in the following ways:
> > - keeping this option enabled may lead to unexpected behavior since
> > the RX & TX are enabled/disabled directly from adjust_link function
> > without any HW interrogation,
> > - removing this option, the RX & TX will only be enabled/disabled after
> > HW interrogation. The HW check is made through the LMON pin in PSR
> > register which specifies AVB_LINK signal value (0 - at low level;
> > 1 - at high level).
> >
> > In conclusion, the present change is also a safety improvement because
> > it removes the "renesas,no-ether-link" option leading to a proper way
> > of detecting the link state based on HW interrogation and not on
> > software heuristic.
> >
> > Fixes: d25e8ff0d5aa ("arm64: dts: renesas: Extract common Salvator-X board support")
>
> The above shuffles the code around but does not introduce the problem
> as far as I can see. Instead I think we should use:
>
> Fixes: dc36965a8905 ("arm64: dts: r8a7796: salvator-x: Enable EthernetAVB")
> Fixes: 6fa501c549aa ("arm64: dts: r8a7795: enable EthernetAVB on Salvator-X")
>
> > Signed-off-by: Bogdan Mirea <Bogdan-Stefan_Mirea@mentor.com>
> > Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
I have applied this a fix for v4.15 with the updated Fixes tags above.
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: renesas: ulcb: Remove renesas,no-ether-link property
From: Simon Horman @ 2017-12-22 8:40 UTC (permalink / raw)
To: Vladimir Zapolskiy
Cc: Sergei Shtylyov, Bogdan Mirea,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20171222083256.2jgts6mdmssr7y76-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org>
On Fri, Dec 22, 2017 at 09:32:56AM +0100, Simon Horman wrote:
> On Thu, Dec 21, 2017 at 05:18:59PM +0200, Vladimir Zapolskiy wrote:
> > From: Bogdan Mirea <Bogdan-Stefan_Mirea-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
> >
> > The present change is a bug fix for AVB link iteratively up/down.
> >
> > Steps to reproduce:
> > - start AVB TX stream (Using aplay via MSE),
> > - disconnect+reconnect the eth cable,
> > - after a reconnection the eth connection goes iteratively up/down
> > without user interaction,
> > - this may heal after some seconds or even stay for minutes.
> >
> > As the documentation specifies, the "renesas,no-ether-link" option
> > should be used when a board does not provide a proper AVB_LINK signal.
> > There is no need for this option enabled on RCAR H3/M3 Salvator-X/XS
> > and ULCB starter kits since the AVB_LINK is correctly handled by HW.
> >
> > Choosing to keep or remove the "renesas,no-ether-link" option will
> > have impact on the code flow in the following ways:
> > - keeping this option enabled may lead to unexpected behavior since
> > the RX & TX are enabled/disabled directly from adjust_link function
> > without any HW interrogation,
> > - removing this option, the RX & TX will only be enabled/disabled after
> > HW interrogation. The HW check is made through the LMON pin in PSR
> > register which specifies AVB_LINK signal value (0 - at low level;
> > 1 - at high level).
> >
> > In conclusion, the present change is also a safety improvement because
> > it removes the "renesas,no-ether-link" option leading to a proper way
> > of detecting the link state based on HW interrogation and not on
> > software heuristic.
> >
> > Fixes: 253ed045a34d ("arm64: dts: renesas: Extract common ULCB board support")
>
> The above shuffles the code around but does not introduce the problem
> as far as I can see. Instead I think we should use:
>
> Fixes: 144bf6ccb13f ("arm64: dts: h3ulcb: enable EthernetAVB")
> Fixes: 883fae315a6a ("arm64: dts: m3ulcb: enable EthernetAVB")
>
> > Signed-off-by: Bogdan Mirea <Bogdan-Stefan_Mirea-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
> > Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
I have applied this a fix for v4.15 with the updated Fixes tags above.
--
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] ARM: dts: tango4: remove bogus interrupt-controller property
From: Marc Gonzalez @ 2017-12-22 8:41 UTC (permalink / raw)
To: Arnd Bergmann, Mans Rullgard
Cc: Rob Herring, Mark Rutland, Olof Johansson, Thomas Gleixner,
Greg Kroah-Hartman, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171221214831.3859194-1-arnd-r2nGTMty4D4@public.gmane.org>
On 21/12/2017 22:48, Arnd Bergmann wrote:
> dtc points out that the parent node of the interrupt controllers is not
> actually an interrupt controller itself, and lacks an #interrupt-cells
> property:
>
> arch/arm/boot/dts/tango4-vantage-1172.dtb: Warning (interrupts_property): Missing #interrupt-cells in interrupt-parent /soc/interrupt-controller@6e000
>
> This removes the annotation.
>
> Signed-off-by: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
> ---
> arch/arm/boot/dts/tango4-common.dtsi | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/tango4-common.dtsi b/arch/arm/boot/dts/tango4-common.dtsi
> index 0ec1b0a317b4..ff72a8efb73d 100644
> --- a/arch/arm/boot/dts/tango4-common.dtsi
> +++ b/arch/arm/boot/dts/tango4-common.dtsi
> @@ -156,7 +156,6 @@
> reg = <0x6e000 0x400>;
> ranges = <0 0x6e000 0x400>;
> interrupt-parent = <&gic>;
> - interrupt-controller;
> #address-cells = <1>;
> #size-cells = <1>;
>
Acked-by: Marc Gonzalez <marc_gonzalez-y1yR0Z3OICC7zZZRDBGcUA@public.gmane.org>
Thanks Arnd.
--
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] [media] Add Rockchip RK1608 driver
From: Philippe Ombredanne @ 2017-12-22 8:45 UTC (permalink / raw)
To: Leo Wen
Cc: Mauro Carvalho Chehab, Rob Herring, Mark Rutland, David S. Miller,
Greg Kroah-Hartman, rdunlap, Linux Media Mailing List,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, LKML,
open list:ARM/Rockchip SoC..., Eddie Cai, Jacob Chen
In-Reply-To: <CAFLEztTxXRQu-VJ2FzYbA_vkYZtkDur1nQ6goftdZdnbn63aQQ@mail.gmail.com>
Dear Leo,
On Fri, Dec 22, 2017 at 5:33 AM, Jacob Chen <jacobchen110@gmail.com> wrote:
> Hi leo,
>
>
> 2017-12-12 14:28 GMT+08:00 Leo Wen <leo.wen@rock-chips.com>:
>> Rk1608 is used as a PreISP to link on Soc, which mainly has two functions.
>> One is to download the firmware of RK1608, and the other is to match the
>> extra sensor such as camera and enable sensor by calling sensor's s_power.
>>
>> use below v4l2-ctl command to capture frames.
>>
>> v4l2-ctl --verbose -d /dev/video1 --stream-mmap=2
>> --stream-to=/tmp/stream.out --stream-count=60 --stream-poll
>>
>> use below command to playback the video on your PC.
>>
>> mplayer ./stream.out -loop 0 -demuxer rawvideo -rawvideo
>> w=640:h=480:size=$((640*480*3/2)):format=NV12
>>
>> Signed-off-by: Leo Wen <leo.wen@rock-chips.com>
<snip>
>> --- /dev/null
>> +++ b/drivers/media/spi/rk1608.c
>> @@ -0,0 +1,1165 @@
>> +/**
>> + * Rockchip rk1608 driver
>> + *
>> + * Copyright (C) 2017 Rockchip Electronics Co., Ltd.
>> + *
>> + * This software is available to you under a choice of one of two
>> + * licenses. You may choose to be licensed under the terms of the GNU
>> + * General Public License (GPL) Version 2, available from the file
>> + * COPYING in the main directory of this source tree, or the
>> + * OpenIB.org BSD license below:
>> + *
>> + * Redistribution and use in source and binary forms, with or
>> + * without modification, are permitted provided that the following
>> + * conditions are met:
>> + *
>> + * - Redistributions of source code must retain the above
>> + * copyright notice, this list of conditions and the following
>> + * disclaimer.
>> + *
>> + * - Redistributions in binary form must reproduce the above
>> + * copyright notice, this list of conditions and the following
>> + * disclaimer in the documentation and/or other materials
>> + * provided with the distribution.
>> + *
>> + * 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.
>> + */
Have you considered using the new SPDX tags instead of this fine but
long legalese?
I know what you are about to say: everyone loves legalese so much that
it is hard to let go of so much of it and replace all this only with a
single SPDX tag line ;)
But then everyone loves code much more than legalese too! so you would
be making the world a service anyway.
And if other contributors in your team could follow suit and you could
spread the word that would be even better!
See Thomas doc patches [1] for details.
[1] https://lkml.org/lkml/2017/12/4/934
--
Cordially
Philippe Ombredanne
^ permalink raw reply
* Re: [PATCH v5 3/3] PCI: mobiveil: Add MSI support for Mobiveil PCIe Host
From: Subrahmanya Lingappa @ 2017-12-22 8:52 UTC (permalink / raw)
To: Marc Zyngier
Cc: linux-pci, Bjorn Helgaas, Lorenzo Pieralisi, robh, devicetree,
Mingkai Hu, Peter W Newton, M.h. Lian, Raj Raina, Rajan Kapoor,
Prabhjot Singh
In-Reply-To: <23b886bf-b21e-8e8c-460c-42316469f989@arm.com>
[-- Attachment #1: Type: text/plain, Size: 15889 bytes --]
Marc,
On Fri, Dec 15, 2017 at 9:43 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:
> On 13/12/17 16:08, Subrahmanya Lingappa wrote:
> > Adds MSI support for Mobiveil PCIe Host Bridge IP driver
> >
> > Signed-off-by: Subrahmanya Lingappa <l.subrahmanya@mobiveil.co.in>
> > Cc: Bjorn Helgaas <bhelgaas@google.com>
> > Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > Cc: Marc Zyngier <marc.zyngier@arm.com>
> > Cc: linux-pci@vger.kernel.org
> > ---
> > drivers/pci/host/pcie-mobiveil.c | 222 ++++++++++++++++++++++++++++++
> ++++++++-
> > 1 file changed, 220 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/pci/host/pcie-mobiveil.c b/drivers/pci/host/pcie-
> mobiveil.c
> > index 8611aaa..39818d5 100644
> > --- a/drivers/pci/host/pcie-mobiveil.c
> > +++ b/drivers/pci/host/pcie-mobiveil.c
> > @@ -14,6 +14,7 @@
> > #include <linux/irqdomain.h>
> > #include <linux/kernel.h>
> > #include <linux/module.h>
> > +#include <linux/msi.h>
> > #include <linux/of_address.h>
> > #include <linux/of_irq.h>
> > #include <linux/of_platform.h>
> > @@ -55,6 +56,7 @@
> > #define PAB_INTP_AMBA_MISC_ENB 0x0b0c
> > #define PAB_INTP_AMBA_MISC_STAT 0x0b1c
> > #define PAB_INTP_INTX_MASK 0x1e0
> > +#define PAB_INTP_MSI_MASK 0x8
> >
> > #define PAB_AXI_AMAP_CTRL(win) PAB_REG_ADDR_16(0x0ba0, win)
> > #define WIN_ENABLE_SHIFT 0
> > @@ -85,8 +87,19 @@
> >
> > /* supported number of interrupts */
> > #define PCI_NUM_INTX 4
> > +#define PCI_NUM_MSI 16
> > #define PAB_INTA_POS 5
> >
> > +/* MSI registers */
> > +#define MSI_BASE_LO_OFFSET 0x04
> > +#define MSI_BASE_HI_OFFSET 0x08
> > +#define MSI_SIZE_OFFSET 0x0c
> > +#define MSI_ENABLE_OFFSET 0x14
> > +#define MSI_STATUS_OFFSET 0x18
> > +#define MSI_DATA_OFFSET 0x20
> > +#define MSI_ADDR_L_OFFSET 0x24
> > +#define MSI_ADDR_H_OFFSET 0x28
> > +
> > /* outbound and inbound window definitions */
> > #define WIN_NUM_0 0
> > #define WIN_NUM_1 1
> > @@ -105,11 +118,22 @@
> > #define UINT64_MAX (u64)(~((u64)0))
> > #endif
> >
> > +struct mobiveil_msi { /* MSI information */
> > + struct mutex lock; /* protect bitmap variable */
> > + struct irq_domain *msi_domain;
> > + struct irq_domain *dev_domain;
> > + phys_addr_t msi_pages_phys;
> > + int *msi_pages;
> > + int num_of_vectors;
> > + DECLARE_BITMAP(msi_irq_in_use, PCI_NUM_MSI);
> > +};
> > +
> > struct mobiveil_pcie {
> > struct platform_device *pdev;
> > struct list_head resources;
> > void __iomem *config_axi_slave_base; /* endpoint config base */
> > void __iomem *csr_axi_slave_base; /* root port config base */
> > + void __iomem *apb_csr_base; /* MSI register base */
> > struct irq_domain *intx_domain;
> > int irq;
> > int apio_wins;
> > @@ -118,6 +142,7 @@ struct mobiveil_pcie {
> > int ib_wins_configured; /* configured inbound windows */
> > struct resource *ob_io_res;
> > char root_bus_nr;
> > + struct mobiveil_msi msi;
> > };
> >
> > static inline void csr_writel(struct mobiveil_pcie *pcie, const u32
> value,
> > @@ -202,11 +227,18 @@ static void mobiveil_pcie_isr(struct irq_desc
> *desc)
> > struct irq_chip *chip = irq_desc_get_chip(desc);
> > struct mobiveil_pcie *pcie = irq_desc_get_handler_data(desc);
> > struct device *dev = &pcie->pdev->dev;
> > - u32 intr_status;
> > + struct mobiveil_msi *msi = &pcie->msi;
> > + u32 msi_data, msi_addr_lo, msi_addr_hi;
> > + u32 intr_status, msi_status;
> > unsigned long shifted_status;
> > u32 bit, virq;
> > u32 val, mask;
> >
> > + /*
> > + * The core provides a single interrupt for both INTx/MSI messages.
> > + * So we'll read both INTx and MSI status
> > + */
> > +
> > chained_irq_enter(chip, desc);
> >
> > /* read INTx status */
> > @@ -241,6 +273,41 @@ static void mobiveil_pcie_isr(struct irq_desc *desc)
> > } while ((shifted_status >> PAB_INTA_POS) != 0);
> > }
> >
> > + /* read extra MSI status register */
> > + msi_status = readl(pcie->apb_csr_base + MSI_STATUS_OFFSET);
>
> You are using the non-relaxed accessors here, while the rest of the
> driver used the _relaxed version. Why is that so?
>
> i
t was a slip, I will correct it to use relaxed order.
> > +
> > + /* handle MSI interrupts */
> > + if ((intr_status & PAB_INTP_MSI_MASK) || (msi_status & 1)) {
> > + do {
> > + msi_data = readl(pcie->apb_csr_base +
> MSI_DATA_OFFSET);
> > +
> > + /*
> > + * MSI_STATUS_OFFSET gets updated to zero once we
> have
> > + * popped not only the data but also address from
> MSI
> > + * hardware FIFO.so keeping these following two
> dummy
> > + * reads.
> > + */
> > + msi_addr_lo = readl(pcie->apb_csr_base +
> > + MSI_ADDR_L_OFFSET);
> > + msi_addr_hi = readl(pcie->apb_csr_base +
> > + MSI_ADDR_H_OFFSET);
>
> Is that really valid? Don't you have to issue a 64bit access?
>
Seems like its valid, because its just a pair of DWORD
accesses to config register space to read MSI data captured inside bridge
hardware FIFO.
is there any reason you think its invalid?
>
> > + dev_dbg(dev,
> > + "MSI registers, data: %08x, addr:
> %08x:%08x\n",
> > + msi_data, msi_addr_hi, msi_addr_lo);
> > +
> > + if (msi_data) {
> > + virq = irq_find_mapping(msi->dev_domain,
> > + msi_data);
> > + if (virq)
> > + generic_handle_irq(virq);
> > + } else
> > + dev_err_ratelimited(dev, "MSI data
> null\n");
>
> Braces on both sides of the else statement.
>
> Also, why is msi_data==0 not valid? You can definitely allocate it from
> your bitmap, and I'm expecting that there is a strong correlation
> between what you read from MSI_DATA_OFFSET and the payload that the
>
> endpoint writes.
>
> Agreed msi_data==0 should also be valid. will be fixed.
> +
> > + msi_status = readl(pcie->apb_csr_base +
> > + MSI_STATUS_OFFSET);
> > + } while (msi_status & 1);
> > + }
> > +
> > csr_writel(pcie, intr_status, PAB_INTP_AMBA_MISC_STAT);
> > chained_irq_exit(chip, desc);
> > }
> > @@ -274,6 +341,12 @@ static int mobiveil_pcie_parse_dt(struct
> mobiveil_pcie *pcie)
> > if (IS_ERR(pcie->csr_axi_slave_base))
> > return PTR_ERR(pcie->csr_axi_slave_base);
> >
> > + /* map MSI config resource */
> > + res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> "apb_csr");
> > + pcie->apb_csr_base = devm_pci_remap_cfg_resource(dev, res);
> > + if (IS_ERR(pcie->apb_csr_base))
> > + return PTR_ERR(pcie->apb_csr_base);
> > +
> > /* read the number of windows requested */
> > if (!pcie->apio_wins &&
> > of_property_read_u32(node, "apio-wins", &pcie->apio_wins))
> {
> > @@ -430,6 +503,27 @@ static int mobiveil_bringup_link(struct
> mobiveil_pcie *pcie)
> > return -ETIMEDOUT;
> > }
> >
> > +static void mobiveil_pcie_enable_msi(struct mobiveil_pcie *pcie)
> > +{
> > + phys_addr_t msg_addr;
> > + struct mobiveil_msi *msi = &pcie->msi;
> > +
> > +
> > + pcie->msi.num_of_vectors = PCI_NUM_MSI;
> > +
> > + msi->msi_pages = (void *)__get_free_pages(GFP_DMA, 0);
>
> That old trick again... Do you really need to carve out a RAM page for
> this? Can't you use just some dummy physical address instead? The base
> address of your PCIe RC, for example.
>
Due to the current hardware bug
we do need a real RAM location to write this MSI data into, as we cant use
any dummy address for now.
>
> > + msg_addr = virt_to_phys((void *)msi->msi_pages);
> > + msi->msi_pages_phys = (phys_addr_t)msg_addr;
> > +
> > + writel_relaxed(lower_32_bits(msg_addr),
> > + pcie->apb_csr_base + MSI_BASE_LO_OFFSET);
> > + writel_relaxed(upper_32_bits(msg_addr),
> > + pcie->apb_csr_base + MSI_BASE_HI_OFFSET);
> > + writel_relaxed(4096, pcie->apb_csr_base + MSI_SIZE_OFFSET);
> > + writel_relaxed(1,
> > + pcie->apb_csr_base + MSI_ENABLE_OFFSET);
>
> nit: No need to break all these writes, each of them can fit on a single
> line.
>
> > +}
> > +
> > static int mobiveil_host_init(struct mobiveil_pcie *pcie)
> > {
> > u32 value;
> > @@ -465,7 +559,8 @@ static int mobiveil_host_init(struct mobiveil_pcie
> *pcie)
> > (1 << PEX_PIO_ENABLE_SHIFT),
> > PAB_CTRL);
> >
> > - csr_writel(pcie, PAB_INTP_INTX_MASK, PAB_INTP_AMBA_MISC_ENB);
> > + csr_writel(pcie, (PAB_INTP_INTX_MASK | PAB_INTP_MSI_MASK),
> > + PAB_INTP_AMBA_MISC_ENB);
> >
> > /* program PIO Enable Bit to 1 and Config Window Enable Bit to 1 in
> > * PAB_AXI_PIO_CTRL Register
> > @@ -503,6 +598,10 @@ static int mobiveil_host_init(struct mobiveil_pcie
> *pcie)
> > }
> > }
> >
> > + /* setup MSI hardware registers */
> > + if (IS_ENABLED(CONFIG_PCI_MSI))
>
> Your driver already depends on
>
> PCI_MSI_IRQ_DOMAIN, which depends on
> PCI_MSI. So this IS_ENABLED() is pointless.
>
as Lorenzo pointed out on the other thread, I will take
out PCI_MSI_IRQ_DOMAIN dependency.
So looks like better to follow other tested drivers and continue to keep it
no ?
>
>
> > + mobiveil_pcie_enable_msi(pcie);
> > +
> > return err;
> > }
> >
> > @@ -520,6 +619,118 @@ static int mobiveil_pcie_intx_map(struct
> irq_domain *domain, unsigned int irq,
> > .map = mobiveil_pcie_intx_map,
> > };
> >
> > +static struct irq_chip mobiveil_msi_irq_chip = {
> > + .name = "Mobiveil PCIe MSI",
> > + .irq_mask = pci_msi_mask_irq,
> > + .irq_unmask = pci_msi_unmask_irq,
> > +};
> > +
> > +static struct msi_domain_info mobiveil_msi_domain_info = {
> > + .flags = (MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS |
> > + MSI_FLAG_PCI_MSIX),
> > + .chip = &mobiveil_msi_irq_chip,
> > +};
> > +
> > +static void mobiveil_compose_msi_msg(struct irq_data *data, struct
> msi_msg *msg)
> > +{
> > + struct mobiveil_pcie *pcie = irq_data_get_irq_chip_data(data);
> > + phys_addr_t addr = virt_to_phys((void *)pcie->msi.msi_pages +
> > + (data->hwirq * sizeof(int)));
> > +
> > + msg->address_lo = lower_32_bits(addr);
> > + msg->address_hi = upper_32_bits(addr);
> > + msg->data = data->hwirq;
> > +
> > + dev_dbg(&pcie->pdev->dev, "msi#%d address_hi %#x address_lo %#x\n",
> > + (int)data->hwirq, msg->address_hi, msg->address_lo);
> > +}
> > +
> > +static int mobiveil_msi_set_affinity(struct irq_data *irq_data,
> > + const struct cpumask *mask, bool force)
> > +{
> > + return -EINVAL;
> > +}
> > +
> > +static struct irq_chip mobiveil_msi_bottom_irq_chip = {
> > + .name = "Mobiveil MSI",
> > + .irq_compose_msi_msg = mobiveil_compose_msi_msg,
> > + .irq_set_affinity = mobiveil_msi_set_affinity,
> > +};
> > +
> > +static int mobiveil_irq_msi_domain_alloc(struct irq_domain *domain,
> > + unsigned int virq, unsigned int nr_irqs, void *args)
> > +{
> > + struct mobiveil_pcie *pcie = domain->host_data;
> > + struct mobiveil_msi *msi = &pcie->msi;
> > + unsigned long bit;
> > +
> > + WARN_ON(nr_irqs != 1);
> > + mutex_lock(&msi->lock);
> > +
> > + bit = find_first_zero_bit(msi->msi_irq_in_use,
> msi->num_of_vectors);
> > + if (bit >= msi->num_of_vectors) {
> > + mutex_unlock(&msi->lock);
> > + return -ENOSPC;
> > + }
> > +
> > + set_bit(bit, msi->msi_irq_in_use);
> > +
> > + mutex_unlock(&msi->lock);
> > +
> > + irq_domain_set_info(domain, virq, bit,
> &mobiveil_msi_bottom_irq_chip,
> > + domain->host_data, handle_simple_irq,
> > + NULL, NULL);
> > + return 0;
> > +}
> > +
> > +static void mobiveil_irq_msi_domain_free(struct irq_domain *domain,
> > + unsigned int virq, unsigned int nr_irqs)
> > +{
> > + struct irq_data *d = irq_domain_get_irq_data(domain, virq);
> > + struct mobiveil_pcie *pcie = irq_data_get_irq_chip_data(d);
> > + struct mobiveil_msi *msi = &pcie->msi;
> > +
> > + mutex_lock(&msi->lock);
> > +
> > + if (!test_bit(d->hwirq, msi->msi_irq_in_use)) {
> > + dev_err(&pcie->pdev->dev, "trying to free unused
> MSI#%lu\n",
> > + d->hwirq);
> > + } else {
> > + __clear_bit(d->hwirq, msi->msi_irq_in_use);
> > + }
> > +
> > + mutex_unlock(&msi->lock);
> > +}
> > +
> > +static const struct irq_domain_ops msi_domain_ops = {
> > + .alloc = mobiveil_irq_msi_domain_alloc,
> > + .free = mobiveil_irq_msi_domain_free,
> > +};
> > +
> > +static int mobiveil_allocate_msi_domains(struct mobiveil_pcie *pcie)
> > +{
> > + struct device *dev = &pcie->pdev->dev;
> > + struct fwnode_handle *fwnode = of_node_to_fwnode(dev->of_node);
> > + struct mobiveil_msi *msi = &pcie->msi;
> > +
> > + mutex_init(&pcie->msi.lock);
> > + msi->dev_domain = irq_domain_add_linear(NULL, msi->num_of_vectors,
> > + &msi_domain_ops, pcie);
> > + if (!msi->dev_domain) {
> > + dev_err(dev, "failed to create IRQ domain\n");
> > + return -ENOMEM;
> > + }
> > +
> > + msi->msi_domain = pci_msi_create_irq_domain(fwnode,
> > + &mobiveil_msi_domain_info,
> msi->dev_domain);
> > + if (!msi->msi_domain) {
> > + dev_err(dev, "failed to create MSI domain\n");
> > + irq_domain_remove(msi->dev_domain);
> > + return -ENOMEM;
> > + }
> > + return 0;
> > +}
> > +
> > static int mobiveil_pcie_init_irq_domain(struct mobiveil_pcie *pcie)
> > {
> > struct device *dev = &pcie->pdev->dev;
> > @@ -535,6 +746,13 @@ static int mobiveil_pcie_init_irq_domain(struct
> mobiveil_pcie *pcie)
> > return -ENODEV;
> > }
> >
> > +#ifdef CONFIG_PCI_MSI
>
> Useless #ifdef
>
> > + /* setup MSI */
> > + ret = mobiveil_allocate_msi_domains(pcie);
> > + if (ret)
> > + return ret;
> > +#endif
> > +
> > return 0;
> > }
> >
> >
>
> Now, there is something that I find a bit annoying: This code looks very
> similar to drivers/pci/host/pcie-altera-msi.c, to the extent that I
> suspect this is the same IP.
>
>
Its a different IP.
> I suggest you investigate whether you can reuse the existing code
> instead of adding yet another MSI driver to the kernel.
>
> Yes, Since the hardware architecture is similar so they do look similar.
> Thanks,
>
> M.
> --
> Jazz is not dead. It just smells funny...
>
Thanks,
Subrahmanya
[-- Attachment #2: Type: text/html, Size: 23907 bytes --]
^ permalink raw reply
* Re: [PATCH v5 3/3] PCI: mobiveil: Add MSI support for Mobiveil PCIe Host
From: Subrahmanya Lingappa @ 2017-12-22 8:57 UTC (permalink / raw)
To: Marc Zyngier
Cc: linux-pci-u79uwXL29TY76Z2rM5mHXA, Bjorn Helgaas,
Lorenzo Pieralisi, robh-DgEjT+Ai2ygdnm+yROfE0A,
devicetree-u79uwXL29TY76Z2rM5mHXA, Mingkai Hu, Peter W Newton,
M.h. Lian, Raj Raina, Rajan Kapoor, Prabhjot Singh
In-Reply-To: <23b886bf-b21e-8e8c-460c-42316469f989-5wv7dgnIgG8@public.gmane.org>
Re-sending the mail in Plain text mode.
Marc,
On Fri, Dec 15, 2017 at 9:43 PM, Marc Zyngier <marc.zyngier-5wv7dgnIgG8@public.gmane.org> wrote:
>
> On 13/12/17 16:08, Subrahmanya Lingappa wrote:
> > Adds MSI support for Mobiveil PCIe Host Bridge IP driver
> >
> > Signed-off-by: Subrahmanya Lingappa <l.subrahmanya-DTHOJn6Rh8lhmhkoCovsdw@public.gmane.org>
> > Cc: Bjorn Helgaas <bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
> > Cc: Lorenzo Pieralisi <lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org>
> > Cc: Marc Zyngier <marc.zyngier-5wv7dgnIgG8@public.gmane.org>
> > Cc: linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > ---
> > drivers/pci/host/pcie-mobiveil.c | 222 ++++++++++++++++++++++++++++++++++++++-
> > 1 file changed, 220 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/pci/host/pcie-mobiveil.c b/drivers/pci/host/pcie-mobiveil.c
> > index 8611aaa..39818d5 100644
> > --- a/drivers/pci/host/pcie-mobiveil.c
> > +++ b/drivers/pci/host/pcie-mobiveil.c
> > @@ -14,6 +14,7 @@
> > #include <linux/irqdomain.h>
> > #include <linux/kernel.h>
> > #include <linux/module.h>
> > +#include <linux/msi.h>
> > #include <linux/of_address.h>
> > #include <linux/of_irq.h>
> > #include <linux/of_platform.h>
> > @@ -55,6 +56,7 @@
> > #define PAB_INTP_AMBA_MISC_ENB 0x0b0c
> > #define PAB_INTP_AMBA_MISC_STAT 0x0b1c
> > #define PAB_INTP_INTX_MASK 0x1e0
> > +#define PAB_INTP_MSI_MASK 0x8
> >
> > #define PAB_AXI_AMAP_CTRL(win) PAB_REG_ADDR_16(0x0ba0, win)
> > #define WIN_ENABLE_SHIFT 0
> > @@ -85,8 +87,19 @@
> >
> > /* supported number of interrupts */
> > #define PCI_NUM_INTX 4
> > +#define PCI_NUM_MSI 16
> > #define PAB_INTA_POS 5
> >
> > +/* MSI registers */
> > +#define MSI_BASE_LO_OFFSET 0x04
> > +#define MSI_BASE_HI_OFFSET 0x08
> > +#define MSI_SIZE_OFFSET 0x0c
> > +#define MSI_ENABLE_OFFSET 0x14
> > +#define MSI_STATUS_OFFSET 0x18
> > +#define MSI_DATA_OFFSET 0x20
> > +#define MSI_ADDR_L_OFFSET 0x24
> > +#define MSI_ADDR_H_OFFSET 0x28
> > +
> > /* outbound and inbound window definitions */
> > #define WIN_NUM_0 0
> > #define WIN_NUM_1 1
> > @@ -105,11 +118,22 @@
> > #define UINT64_MAX (u64)(~((u64)0))
> > #endif
> >
> > +struct mobiveil_msi { /* MSI information */
> > + struct mutex lock; /* protect bitmap variable */
> > + struct irq_domain *msi_domain;
> > + struct irq_domain *dev_domain;
> > + phys_addr_t msi_pages_phys;
> > + int *msi_pages;
> > + int num_of_vectors;
> > + DECLARE_BITMAP(msi_irq_in_use, PCI_NUM_MSI);
> > +};
> > +
> > struct mobiveil_pcie {
> > struct platform_device *pdev;
> > struct list_head resources;
> > void __iomem *config_axi_slave_base; /* endpoint config base */
> > void __iomem *csr_axi_slave_base; /* root port config base */
> > + void __iomem *apb_csr_base; /* MSI register base */
> > struct irq_domain *intx_domain;
> > int irq;
> > int apio_wins;
> > @@ -118,6 +142,7 @@ struct mobiveil_pcie {
> > int ib_wins_configured; /* configured inbound windows */
> > struct resource *ob_io_res;
> > char root_bus_nr;
> > + struct mobiveil_msi msi;
> > };
> >
> > static inline void csr_writel(struct mobiveil_pcie *pcie, const u32 value,
> > @@ -202,11 +227,18 @@ static void mobiveil_pcie_isr(struct irq_desc *desc)
> > struct irq_chip *chip = irq_desc_get_chip(desc);
> > struct mobiveil_pcie *pcie = irq_desc_get_handler_data(desc);
> > struct device *dev = &pcie->pdev->dev;
> > - u32 intr_status;
> > + struct mobiveil_msi *msi = &pcie->msi;
> > + u32 msi_data, msi_addr_lo, msi_addr_hi;
> > + u32 intr_status, msi_status;
> > unsigned long shifted_status;
> > u32 bit, virq;
> > u32 val, mask;
> >
> > + /*
> > + * The core provides a single interrupt for both INTx/MSI messages.
> > + * So we'll read both INTx and MSI status
> > + */
> > +
> > chained_irq_enter(chip, desc);
> >
> > /* read INTx status */
> > @@ -241,6 +273,41 @@ static void mobiveil_pcie_isr(struct irq_desc *desc)
> > } while ((shifted_status >> PAB_INTA_POS) != 0);
> > }
> >
> > + /* read extra MSI status register */
> > + msi_status = readl(pcie->apb_csr_base + MSI_STATUS_OFFSET);
>
> You are using the non-relaxed accessors here, while the rest of the
> driver used the _relaxed version. Why is that so?
>
i
t was a slip, I will correct it to use relaxed order.
>
> > +
> > + /* handle MSI interrupts */
> > + if ((intr_status & PAB_INTP_MSI_MASK) || (msi_status & 1)) {
> > + do {
> > + msi_data = readl(pcie->apb_csr_base + MSI_DATA_OFFSET);
> > +
> > + /*
> > + * MSI_STATUS_OFFSET gets updated to zero once we have
> > + * popped not only the data but also address from MSI
> > + * hardware FIFO.so keeping these following two dummy
> > + * reads.
> > + */
> > + msi_addr_lo = readl(pcie->apb_csr_base +
> > + MSI_ADDR_L_OFFSET);
> > + msi_addr_hi = readl(pcie->apb_csr_base +
> > + MSI_ADDR_H_OFFSET);
>
> Is that really valid? Don't you have to issue a 64bit access?
>
Seems like its valid, because its just a pair of DWORD
accesses to config register space to read MSI data captured inside
bridge hardware FIFO.
is there any reason you think its invalid?
>
> > + dev_dbg(dev,
> > + "MSI registers, data: %08x, addr: %08x:%08x\n",
> > + msi_data, msi_addr_hi, msi_addr_lo);
> > +
> > + if (msi_data) {
> > + virq = irq_find_mapping(msi->dev_domain,
> > + msi_data);
> > + if (virq)
> > + generic_handle_irq(virq);
> > + } else
> > + dev_err_ratelimited(dev, "MSI data null\n");
>
> Braces on both sides of the else statement.
>
> Also, why is msi_data==0 not valid? You can definitely allocate it from
> your bitmap, and I'm expecting that there is a strong correlation
> between what you read from MSI_DATA_OFFSET and the payload that the
> endpoint writes.
>
Agreed msi_data==0 should also be valid. will be fixed.
>
> > +
> > + msi_status = readl(pcie->apb_csr_base +
> > + MSI_STATUS_OFFSET);
> > + } while (msi_status & 1);
> > + }
> > +
> > csr_writel(pcie, intr_status, PAB_INTP_AMBA_MISC_STAT);
> > chained_irq_exit(chip, desc);
> > }
> > @@ -274,6 +341,12 @@ static int mobiveil_pcie_parse_dt(struct mobiveil_pcie *pcie)
> > if (IS_ERR(pcie->csr_axi_slave_base))
> > return PTR_ERR(pcie->csr_axi_slave_base);
> >
> > + /* map MSI config resource */
> > + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "apb_csr");
> > + pcie->apb_csr_base = devm_pci_remap_cfg_resource(dev, res);
> > + if (IS_ERR(pcie->apb_csr_base))
> > + return PTR_ERR(pcie->apb_csr_base);
> > +
> > /* read the number of windows requested */
> > if (!pcie->apio_wins &&
> > of_property_read_u32(node, "apio-wins", &pcie->apio_wins)) {
> > @@ -430,6 +503,27 @@ static int mobiveil_bringup_link(struct mobiveil_pcie *pcie)
> > return -ETIMEDOUT;
> > }
> >
> > +static void mobiveil_pcie_enable_msi(struct mobiveil_pcie *pcie)
> > +{
> > + phys_addr_t msg_addr;
> > + struct mobiveil_msi *msi = &pcie->msi;
> > +
> > +
> > + pcie->msi.num_of_vectors = PCI_NUM_MSI;
> > +
> > + msi->msi_pages = (void *)__get_free_pages(GFP_DMA, 0);
>
> That old trick again... Do you really need to carve out a RAM page for
> this? Can't you use just some dummy physical address instead? The base
> address of your PCIe RC, for example.
>
Due to the current hardware bug
we do need a real RAM location to write this MSI data into, as we cant
use any dummy address for now.
>
> > + msg_addr = virt_to_phys((void *)msi->msi_pages);
> > + msi->msi_pages_phys = (phys_addr_t)msg_addr;
> > +
> > + writel_relaxed(lower_32_bits(msg_addr),
> > + pcie->apb_csr_base + MSI_BASE_LO_OFFSET);
> > + writel_relaxed(upper_32_bits(msg_addr),
> > + pcie->apb_csr_base + MSI_BASE_HI_OFFSET);
> > + writel_relaxed(4096, pcie->apb_csr_base + MSI_SIZE_OFFSET);
> > + writel_relaxed(1,
> > + pcie->apb_csr_base + MSI_ENABLE_OFFSET);
>
> nit: No need to break all these writes, each of them can fit on a single
> line.
>
> > +}
> > +
> > static int mobiveil_host_init(struct mobiveil_pcie *pcie)
> > {
> > u32 value;
> > @@ -465,7 +559,8 @@ static int mobiveil_host_init(struct mobiveil_pcie *pcie)
> > (1 << PEX_PIO_ENABLE_SHIFT),
> > PAB_CTRL);
> >
> > - csr_writel(pcie, PAB_INTP_INTX_MASK, PAB_INTP_AMBA_MISC_ENB);
> > + csr_writel(pcie, (PAB_INTP_INTX_MASK | PAB_INTP_MSI_MASK),
> > + PAB_INTP_AMBA_MISC_ENB);
> >
> > /* program PIO Enable Bit to 1 and Config Window Enable Bit to 1 in
> > * PAB_AXI_PIO_CTRL Register
> > @@ -503,6 +598,10 @@ static int mobiveil_host_init(struct mobiveil_pcie *pcie)
> > }
> > }
> >
> > + /* setup MSI hardware registers */
> > + if (IS_ENABLED(CONFIG_PCI_MSI))
>
> Your driver already depends on PCI_MSI_IRQ_DOMAIN, which depends on
> PCI_MSI. So this IS_ENABLED() is pointless.
>
as Lorenzo pointed out on the other thread, I will take out
PCI_MSI_IRQ_DOMAIN dependency.
So looks like better to follow other tested drivers and continue to keep it no ?
>
> > + mobiveil_pcie_enable_msi(pcie);
> > +
> > return err;
> > }
> >
> > @@ -520,6 +619,118 @@ static int mobiveil_pcie_intx_map(struct irq_domain *domain, unsigned int irq,
> > .map = mobiveil_pcie_intx_map,
> > };
> >
> > +static struct irq_chip mobiveil_msi_irq_chip = {
> > + .name = "Mobiveil PCIe MSI",
> > + .irq_mask = pci_msi_mask_irq,
> > + .irq_unmask = pci_msi_unmask_irq,
> > +};
> > +
> > +static struct msi_domain_info mobiveil_msi_domain_info = {
> > + .flags = (MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS |
> > + MSI_FLAG_PCI_MSIX),
> > + .chip = &mobiveil_msi_irq_chip,
> > +};
> > +
> > +static void mobiveil_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
> > +{
> > + struct mobiveil_pcie *pcie = irq_data_get_irq_chip_data(data);
> > + phys_addr_t addr = virt_to_phys((void *)pcie->msi.msi_pages +
> > + (data->hwirq * sizeof(int)));
> > +
> > + msg->address_lo = lower_32_bits(addr);
> > + msg->address_hi = upper_32_bits(addr);
> > + msg->data = data->hwirq;
> > +
> > + dev_dbg(&pcie->pdev->dev, "msi#%d address_hi %#x address_lo %#x\n",
> > + (int)data->hwirq, msg->address_hi, msg->address_lo);
> > +}
> > +
> > +static int mobiveil_msi_set_affinity(struct irq_data *irq_data,
> > + const struct cpumask *mask, bool force)
> > +{
> > + return -EINVAL;
> > +}
> > +
> > +static struct irq_chip mobiveil_msi_bottom_irq_chip = {
> > + .name = "Mobiveil MSI",
> > + .irq_compose_msi_msg = mobiveil_compose_msi_msg,
> > + .irq_set_affinity = mobiveil_msi_set_affinity,
> > +};
> > +
> > +static int mobiveil_irq_msi_domain_alloc(struct irq_domain *domain,
> > + unsigned int virq, unsigned int nr_irqs, void *args)
> > +{
> > + struct mobiveil_pcie *pcie = domain->host_data;
> > + struct mobiveil_msi *msi = &pcie->msi;
> > + unsigned long bit;
> > +
> > + WARN_ON(nr_irqs != 1);
> > + mutex_lock(&msi->lock);
> > +
> > + bit = find_first_zero_bit(msi->msi_irq_in_use, msi->num_of_vectors);
> > + if (bit >= msi->num_of_vectors) {
> > + mutex_unlock(&msi->lock);
> > + return -ENOSPC;
> > + }
> > +
> > + set_bit(bit, msi->msi_irq_in_use);
> > +
> > + mutex_unlock(&msi->lock);
> > +
> > + irq_domain_set_info(domain, virq, bit, &mobiveil_msi_bottom_irq_chip,
> > + domain->host_data, handle_simple_irq,
> > + NULL, NULL);
> > + return 0;
> > +}
> > +
> > +static void mobiveil_irq_msi_domain_free(struct irq_domain *domain,
> > + unsigned int virq, unsigned int nr_irqs)
> > +{
> > + struct irq_data *d = irq_domain_get_irq_data(domain, virq);
> > + struct mobiveil_pcie *pcie = irq_data_get_irq_chip_data(d);
> > + struct mobiveil_msi *msi = &pcie->msi;
> > +
> > + mutex_lock(&msi->lock);
> > +
> > + if (!test_bit(d->hwirq, msi->msi_irq_in_use)) {
> > + dev_err(&pcie->pdev->dev, "trying to free unused MSI#%lu\n",
> > + d->hwirq);
> > + } else {
> > + __clear_bit(d->hwirq, msi->msi_irq_in_use);
> > + }
> > +
> > + mutex_unlock(&msi->lock);
> > +}
> > +
> > +static const struct irq_domain_ops msi_domain_ops = {
> > + .alloc = mobiveil_irq_msi_domain_alloc,
> > + .free = mobiveil_irq_msi_domain_free,
> > +};
> > +
> > +static int mobiveil_allocate_msi_domains(struct mobiveil_pcie *pcie)
> > +{
> > + struct device *dev = &pcie->pdev->dev;
> > + struct fwnode_handle *fwnode = of_node_to_fwnode(dev->of_node);
> > + struct mobiveil_msi *msi = &pcie->msi;
> > +
> > + mutex_init(&pcie->msi.lock);
> > + msi->dev_domain = irq_domain_add_linear(NULL, msi->num_of_vectors,
> > + &msi_domain_ops, pcie);
> > + if (!msi->dev_domain) {
> > + dev_err(dev, "failed to create IRQ domain\n");
> > + return -ENOMEM;
> > + }
> > +
> > + msi->msi_domain = pci_msi_create_irq_domain(fwnode,
> > + &mobiveil_msi_domain_info, msi->dev_domain);
> > + if (!msi->msi_domain) {
> > + dev_err(dev, "failed to create MSI domain\n");
> > + irq_domain_remove(msi->dev_domain);
> > + return -ENOMEM;
> > + }
> > + return 0;
> > +}
> > +
> > static int mobiveil_pcie_init_irq_domain(struct mobiveil_pcie *pcie)
> > {
> > struct device *dev = &pcie->pdev->dev;
> > @@ -535,6 +746,13 @@ static int mobiveil_pcie_init_irq_domain(struct mobiveil_pcie *pcie)
> > return -ENODEV;
> > }
> >
> > +#ifdef CONFIG_PCI_MSI
>
> Useless #ifdef
>
> > + /* setup MSI */
> > + ret = mobiveil_allocate_msi_domains(pcie);
> > + if (ret)
> > + return ret;
> > +#endif
> > +
> > return 0;
> > }
> >
> >
>
> Now, there is something that I find a bit annoying: This code looks very
> similar to drivers/pci/host/pcie-altera-msi.c, to the extent that I
> suspect this is the same IP.
>
Its a different IP.
>
> I suggest you investigate whether you can reuse the existing code
> instead of adding yet another MSI driver to the kernel.
>
> Thanks,
>
> M.
> --
> Jazz is not dead. It just smells funny...
Thanks,
Subrahmanya
--
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 v5 06/11] thermal: armada: Add support for Armada AP806
From: Miquel RAYNAL @ 2017-12-22 9:17 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Mark Rutland, devicetree, Baruch Siach, Nadav Haklai, linux-pm,
Antoine Tenart, Eduardo Valentin, David Sniatkiwicz, Rob Herring,
Zhang Rui, Thomas Petazzoni, linux-arm-kernel
In-Reply-To: <87zi6dg0e1.fsf@free-electrons.com>
Hello Gregory,
On Wed, 20 Dec 2017 11:27:18 +0100
Gregory CLEMENT <gregory.clement@free-electrons.com> wrote:
> Hi Miquel,
>
> On mar., déc. 19 2017, Miquel Raynal
> <miquel.raynal@free-electrons.com> wrote:
>
> > From: Baruch Siach <baruch@tkos.co.il>
> >
> > The AP806 component is integrated in the Armada 8K and 7K lines of
> > processors.
> >
> > The thermal sensor sample field on the status register is a signed
> > value. Extend armada_get_temp() and the driver structure to handle
> > signed values.
> >
> > Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> > [<miquel.raynal@free-electrons.com>: Changes when applying over the
> > previous patches, including the register names changes, also
> > switched the coefficients values to s64 instead of unsigned long to
> > deal with negative values and used do_div instead of the
> > traditionnal '/'] Signed-off-by: Miquel Raynal
> > <miquel.raynal@free-electrons.com> Reviewed-by: Gregory CLEMENT
> > <gregory.clement@free-electrons.com> ---
> > drivers/thermal/armada_thermal.c | 74
> > ++++++++++++++++++++++++++++++++-------- 1 file changed, 59
> > insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/thermal/armada_thermal.c
> > b/drivers/thermal/armada_thermal.c index ceebabf45c53..c7dcac39cbf9
> > 100644 --- a/drivers/thermal/armada_thermal.c
> > +++ b/drivers/thermal/armada_thermal.c
> > @@ -47,6 +47,11 @@
> > #define CONTROL0_OFFSET 0x0
> > #define CONTROL1_OFFSET 0x4
> >
> > +/* TSEN refers to the temperature sensors within the AP */
> > +#define CONTROL0_TSEN_START BIT(0)
> > +#define CONTROL0_TSEN_RESET BIT(1)
> > +#define CONTROL0_TSEN_ENABLE BIT(2)
> > +
> > struct armada_thermal_data;
> >
> > /* Marvell EBU Thermal Sensor Dev Structure */
> > @@ -66,10 +71,11 @@ struct armada_thermal_data {
> > bool (*is_valid)(struct armada_thermal_priv *);
> >
> > /* Formula coeficients: temp = (b - m * reg) / div */
> > - unsigned long coef_b;
> > - unsigned long coef_m;
> > - unsigned long coef_div;
> > + s64 coef_b;
> > + s64 coef_m;
> > + u32 coef_div;
> > bool inverted;
> > + bool signed_sample;
> >
> > /* Register shift and mask to access the sensor
> > temperature */ unsigned int temp_shift;
> > @@ -155,6 +161,18 @@ static void armada380_init_sensor(struct
> > platform_device *pdev, }
> > }
> >
> > +static void armada_ap806_init_sensor(struct platform_device *pdev,
> > + struct armada_thermal_priv
> > *priv) +{
> > + u32 reg;
> > +
> > + reg = readl_relaxed(priv->control0);
> > + reg &= ~CONTROL0_TSEN_RESET;
> > + reg |= CONTROL0_TSEN_START | CONTROL0_TSEN_ENABLE;
> > + writel(reg, priv->control0);
> > + msleep(10);
> > +}
> > +
> > static bool armada_is_valid(struct armada_thermal_priv *priv)
> > {
> > u32 reg = readl_relaxed(priv->status);
> > @@ -166,8 +184,8 @@ static int armada_get_temp(struct
> > thermal_zone_device *thermal, int *temp)
> > {
> > struct armada_thermal_priv *priv = thermal->devdata;
> > - unsigned long reg;
> > - unsigned long m, b, div;
> > + u32 reg, div;
> > + s64 sample, b, m;
> >
> > /* Valid check */
> > if (priv->data->is_valid && !priv->data->is_valid(priv)) {
> > @@ -178,6 +196,11 @@ static int armada_get_temp(struct
> > thermal_zone_device *thermal,
> > reg = readl_relaxed(priv->status);
> > reg = (reg >> priv->data->temp_shift) &
> > priv->data->temp_mask;
> > + if (priv->data->signed_sample)
> > + /* The most significant bit is the sign bit */
> > + sample = sign_extend32(reg,
> > fls(priv->data->temp_mask) - 1);
> > + else
> > + sample = reg;
> >
> > /* Get formula coeficients */
> > b = priv->data->coef_b;
> > @@ -185,9 +208,12 @@ static int armada_get_temp(struct
> > thermal_zone_device *thermal, div = priv->data->coef_div;
> >
> > if (priv->data->inverted)
> > - *temp = ((m * reg) - b) / div;
> > + *temp = (m * sample) - b;
> > else
> > - *temp = (b - (m * reg)) / div;
> > + *temp = b - (m * sample);
> > +
> > + do_div(*temp, div);
>
> I wanted to test in on ARMv7 and this line failed to compile:
> In file included from arch/arm/include/asm/div64.h:127:0,
> from include/linux/kernel.h:173,
> from include/linux/list.h:9,
> from include/linux/kobject.h:20,
> from include/linux/device.h:17,
> from drivers/thermal/armada_thermal.c:16:
> drivers/thermal/armada_thermal.c: In function ‘armada_get_temp’:
> include/asm-generic/div64.h:208:28: warning: comparison of distinct
> pointer types lacks a cast (void)(((typeof((n)) *)0) == ((uint64_t
> *)0)); \ ^
> drivers/thermal/armada_thermal.c:247:2: note: in expansion of macro
> ‘do_div’ do_div(*temp, div);
> ^~~~~~
> In file included from include/linux/ioport.h:13:0,
> from include/linux/device.h:16,
> from drivers/thermal/armada_thermal.c:16:
> include/asm-generic/div64.h:221:25: warning: right shift count >=
> width of type [-Wshift-count-overflow] } else if (likely(((n) >> 32)
> == 0)) { \ ^
> include/linux/compiler.h:175:40: note: in definition of macro ‘likely’
> # define likely(x) __builtin_expect(!!(x), 1)
> ^
> drivers/thermal/armada_thermal.c:247:2: note: in expansion of macro
> ‘do_div’ do_div(*temp, div);
> ^~~~~~
> In file included from arch/arm/include/asm/div64.h:127:0,
> from include/linux/kernel.h:173,
> from include/linux/list.h:9,
> from include/linux/kobject.h:20,
> from include/linux/device.h:17,
> from drivers/thermal/armada_thermal.c:16:
> include/asm-generic/div64.h:225:22: error: passing argument 1 of
> ‘__div64_32’ from incompatible pointer type
> [-Werror=incompatible-pointer-types] __rem = __div64_32(&(n),
> __base); \ ^ drivers/thermal/armada_thermal.c:247:2: note: in
> expansion of macro ‘do_div’ do_div(*temp, div);
> ^~~~~~
> In file included from include/linux/kernel.h:173:0,
> from include/linux/list.h:9,
> from include/linux/kobject.h:20,
> from include/linux/device.h:17,
> from drivers/thermal/armada_thermal.c:16:
> arch/arm/include/asm/div64.h:33:24: note: expected ‘uint64_t * {aka
> long long unsigned int *}’ but argument is of type ‘int *’ static
> inline uint32_t __div64_32(uint64_t *n, uint32_t base)
>
Indeed, I also have this compilation error with a 32-bit toolchain but
not with the 64-bit one. Anyway I fixed it and tested on a 32-bit
platform also.
Thanks for reporting it.
Miquèl
_______________________________________________
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] ARM: dts: exynos: fix RTC interrupt for exynos5410
From: Krzysztof Kozlowski @ 2017-12-22 9:19 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Rob Herring, Mark Rutland, Kukjin Kim, Marek Szyprowski,
devicetree, linux-arm-kernel, linux-samsung-soc, linux-kernel,
Sylwester Nawrocki, Bartłomiej Żołnierkiewicz
In-Reply-To: <20171221213020.3080361-1-arnd@arndb.de>
On Thu, Dec 21, 2017 at 10:30 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> According to the comment added to exynos_dt_pmu_match[] in commit
> 8b283c025443 ("ARM: exynos4/5: convert pmu wakeup to stacked domains"),
> the RTC is not able to wake up the system through the PMU on Exynos5410,
> unlike Exynos5420.
>
> However, when the RTC DT node got added, it was a straight copy of
> the Exynos5420 node, which now causes a warning from dtc.
>
> This removes the incorrect interrupt-parent, which should get the
> interrupt working and avoid the warning.
>
> Fixes: e1e146b1b062 ("ARM: dts: exynos: Add RTC and I2C to Exynos5410")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> arch/arm/boot/dts/exynos5410.dtsi | 1 -
> 1 file changed, 1 deletion(-)
In my pull request thread [1] you mentioned that PMU should not be
interrupt controller for Exynos5410. Yes, I think you are right.
Regardless whether Exynos5410 really supports Suspend to RAM or not,
now it is not configured as IRQ controller so the RTC's should go
straight to GIC. I think your fix is correct and I should drop my
patch.
I do not have Exynos5410 anymore (Odroid XU was left at Samsung
Poland) so I cannot test it. Maybe guys in Poland can test it? Marek?
Sylwester? Bartlomiej?
BTW,
It annoys me so much that it is so difficult to get Samsung boards. I
was writing to Samsung many times - to HQ, Open Source Group, LSI,
Artik and nothing. They do not have any boards... or they do not want
to share. This is how Samsung's support for Open Source really looks
like.
>From the three boards I have, two of them I bought myself by my own
money, one was donated to me by Markus Reichl (Odroid U3, thanks!).
When I was working in Samsung Poland they provided me with boards
(thanks guys!) but only for the time of work there and I am not
Samsung employee anymore.
So except this board from Markus, all infrastructure I have was built
by my own money. Eh, it is not that expensive, one board costs like
50-70 USD with shipment, but come on! Seriously, damn big company,
with damn big marketing budget and plenty of people and they cannot
provide their own boards to open-source... It really pisses me off
sometimes...
Back to the topic - thanks for the patch!
Best regards,
Krzysztof
[1] https://www.spinics.net/lists/arm-kernel/msg624966.html
>
> diff --git a/arch/arm/boot/dts/exynos5410.dtsi b/arch/arm/boot/dts/exynos5410.dtsi
> index 06713ec86f0d..d2174727df9a 100644
> --- a/arch/arm/boot/dts/exynos5410.dtsi
> +++ b/arch/arm/boot/dts/exynos5410.dtsi
> @@ -333,7 +333,6 @@
> &rtc {
> clocks = <&clock CLK_RTC>;
> clock-names = "rtc";
> - interrupt-parent = <&pmu_system_controller>;
> status = "disabled";
> };
>
> --
> 2.9.0
>
^ permalink raw reply
* Re: [PATCH] devicetree: Add video bus switch
From: Pavel Machek @ 2017-12-22 9:24 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Sakari Ailus, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
devicetree-u79uwXL29TY76Z2rM5mHXA,
ivo.g.dimitrov.75-Re5JQEeQqe8AvxtiuMwx3w,
sre-DgEjT+Ai2ygdnm+yROfE0A, pali.rohar-Re5JQEeQqe8AvxtiuMwx3w,
linux-media-u79uwXL29TY76Z2rM5mHXA, galak-sgV2jX0FEOL9JmXXK+q4OQ,
mchehab-JPH+aEBZ4P+UEJcrhfAQsw,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <75694885.3PuLWzx4qN@avalon>
[-- Attachment #1: Type: text/plain, Size: 1945 bytes --]
Hi!
> > > I don't really object using g_endpoint_config() as a temporary solution;
> > > I'd like to have Laurent's opinion on that though. Another option is to
> > > wait, but we've already waited a looong time (as in total).
> >
> > Laurent, do you have some input here? We have simple "2 cameras
> > connected to one signal processor" situation here. We need some way of
> > passing endpoint configuration from the sensors through the switch. I
> > did this:
>
> Could you give me a bit more information about the platform you're targeting:
> how the switch is connected, what kind of switch it is, and what endpoint
> configuration data you need ?
Platform is Nokia N900, Ivaylo already gave pointer to schematics.
Switch is controlled using GPIO, and basically there's CSI
configuration that would normally be in the device tree, but now we
have two CSI configurations to select from...
> > 9) Highly reconfigurable hardware - Julien Beraud
> >
> > - 44 sub-devices connected with an interconnect.
> > - As long as formats match, any sub-device could be connected to any
> > - other sub-device through a link.
> > - The result is 44 * 44 links at worst.
> > - A switch sub-device proposed as the solution to model the
> > - interconnect. The sub-devices are connected to the switch
> > - sub-devices through the hardware links that connect to the
> > - interconnect.
> > - The switch would be controlled through new IOCTLs S_ROUTING and
> > - G_ROUTING.
> > - Patches available:
> > http://git.linuxtv.org/cgit.cgi/pinchartl/media.git/log/?h=xilinx-wip
> >
> > but the patches are from 2005. So I guess I'll need some guidance here...
>
> You made me feel very old for a moment. The patches are from 2015 :-)
Sorry about that :-).
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* [PATCH v6 00/11] Armada thermal: improvements and A7K/A8K SoCs support
From: Miquel Raynal @ 2017-12-22 9:32 UTC (permalink / raw)
To: Zhang Rui, Eduardo Valentin, Rob Herring, Mark Rutland
Cc: linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Thomas Petazzoni, Gregory Clement, Antoine Tenart, Nadav Haklai,
Miquel Raynal, Baruch Siach, David Sniatkiwicz
Hi,
This series takes over Baruch's series by integrating his patches about
supporting thermal on Armada 7K and 8K SoCs within a larger series with
several improvements on the armada_thermal.c driver.
For now, Armada 380 and CP110 compatibles share the same initialization
routine but this will probably change in the near future when adding
support for overheat interrupts.
DT bindings documentation is updated to match existing code.
Armada AP806 and CP110 DT are also updated with thermal nodes and have
already been accepted (thus absent in this series).
Thank you,
Miquèl
Changes since v5:
- Added Grogory's Tested-by tags for 64-bit platforms in patches:
"thermal: armada: Add support for Armada AP806"
"thermal: armada: Add support for Armada CP110"
- Fixed a compilation issue with 32-bit toolchains introduced in patch:
"thermal: armada: Add support for Armada AP806"
Baruch Siach (4):
dt-bindings: thermal: Describe Armada AP806 and CP110
thermal: armada: Use msleep for long delays
thermal: armada: Add support for Armada AP806
thermal: armada: Add support for Armada CP110
Miquel Raynal (7):
thermal: armada: Simplify the check of the validity bit
thermal: armada: Clarify control registers accesses
thermal: armada: Use real status register name
thermal: armada: Update Kconfig and module description
thermal: armada: Change sensors trim default value
thermal: armada: Wait sensors validity before exiting the init
callback
thermal: armada: Give meaningful names to the thermal zones
.../devicetree/bindings/thermal/armada-thermal.txt | 37 ++-
drivers/thermal/Kconfig | 4 +-
drivers/thermal/armada_thermal.c | 257 +++++++++++++++------
3 files changed, 218 insertions(+), 80 deletions(-)
--
2.11.0
--
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 v6 01/11] dt-bindings: thermal: Describe Armada AP806 and CP110
From: Miquel Raynal @ 2017-12-22 9:32 UTC (permalink / raw)
To: Zhang Rui, Eduardo Valentin, Rob Herring, Mark Rutland
Cc: linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Thomas Petazzoni, Gregory Clement, Antoine Tenart, Nadav Haklai,
Miquel Raynal, Baruch Siach, David Sniatkiwicz
In-Reply-To: <20171222093226.23456-1-miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
From: Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org>
Add compatible strings for AP806 and CP110 that are part of the Armada
8k/7k line of SoCs.
Add a note on the differences in the size of the control area in
different bindings. This is an existing difference between the Armada
375 binding and the other boards already supported. The new AP806 and
CP110 bindings are similar to the existing Armada 375 in this regard.
Signed-off-by: Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org>
[<miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>: reword, additional details]
Signed-off-by: Miquel Raynal <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
.../devicetree/bindings/thermal/armada-thermal.txt | 37 +++++++++++++++-------
1 file changed, 25 insertions(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/thermal/armada-thermal.txt b/Documentation/devicetree/bindings/thermal/armada-thermal.txt
index 24aacf8948c5..e0d013a2e66d 100644
--- a/Documentation/devicetree/bindings/thermal/armada-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/armada-thermal.txt
@@ -2,22 +2,35 @@
Required properties:
-- compatible: Should be set to one of the following:
- marvell,armada370-thermal
- marvell,armada375-thermal
- marvell,armada380-thermal
- marvell,armadaxp-thermal
+- compatible: Should be set to one of the following:
+ * marvell,armada370-thermal
+ * marvell,armada375-thermal
+ * marvell,armada380-thermal
+ * marvell,armadaxp-thermal
+ * marvell,armada-ap806-thermal
+ * marvell,armada-cp110-thermal
-- reg: Device's register space.
- Two entries are expected, see the examples below.
- The first one is required for the sensor register;
- the second one is required for the control register
- to be used for sensor initialization (a.k.a. calibration).
+- reg: Device's register space.
+ Two entries are expected, see the examples below. The first one points
+ to the status register (4B). The second one points to the control
+ registers (8B).
+ Note: The compatibles marvell,armada370-thermal,
+ marvell,armada380-thermal, and marvell,armadaxp-thermal must point to
+ "control MSB/control 1", with size of 4 (deprecated binding), or point
+ to "control LSB/control 0" with size of 8 (current binding). All other
+ compatibles must point to "control LSB/control 0" with size of 8.
-Example:
+Examples:
+ /* Legacy bindings */
thermal@d0018300 {
compatible = "marvell,armada370-thermal";
- reg = <0xd0018300 0x4
+ reg = <0xd0018300 0x4
0xd0018304 0x4>;
};
+
+ ap_thermal: thermal@6f8084 {
+ compatible = "marvell,armada-ap806-thermal";
+ reg = <0x6f808C 0x4>,
+ <0x6f8084 0x8>;
+ };
--
2.11.0
--
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 related
* [PATCH v6 02/11] thermal: armada: Use msleep for long delays
From: Miquel Raynal @ 2017-12-22 9:32 UTC (permalink / raw)
To: Zhang Rui, Eduardo Valentin, Rob Herring, Mark Rutland
Cc: linux-pm, devicetree, linux-arm-kernel, Thomas Petazzoni,
Gregory Clement, Antoine Tenart, Nadav Haklai, Miquel Raynal,
Baruch Siach, David Sniatkiwicz
In-Reply-To: <20171222093226.23456-1-miquel.raynal@free-electrons.com>
From: Baruch Siach <baruch@tkos.co.il>
Use msleep for long (> 10ms) delays, instead of the busy waiting mdelay.
All delays are called from the probe routine, where scheduling is
allowed.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/thermal/armada_thermal.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
index 706d74798cbe..6c4af2622d4f 100644
--- a/drivers/thermal/armada_thermal.c
+++ b/drivers/thermal/armada_thermal.c
@@ -113,7 +113,7 @@ static void armada370_init_sensor(struct platform_device *pdev,
reg &= ~PMU_TDC0_START_CAL_MASK;
writel(reg, priv->control);
- mdelay(10);
+ msleep(10);
}
static void armada375_init_sensor(struct platform_device *pdev,
@@ -127,11 +127,11 @@ static void armada375_init_sensor(struct platform_device *pdev,
reg &= ~A375_HW_RESETn;
writel(reg, priv->control + 4);
- mdelay(20);
+ msleep(20);
reg |= A375_HW_RESETn;
writel(reg, priv->control + 4);
- mdelay(50);
+ msleep(50);
}
static void armada380_init_sensor(struct platform_device *pdev,
@@ -143,7 +143,7 @@ static void armada380_init_sensor(struct platform_device *pdev,
if (!(reg & A380_HW_RESET)) {
reg |= A380_HW_RESET;
writel(reg, priv->control);
- mdelay(10);
+ msleep(10);
}
}
--
2.11.0
^ permalink raw reply related
* [PATCH v6 03/11] thermal: armada: Simplify the check of the validity bit
From: Miquel Raynal @ 2017-12-22 9:32 UTC (permalink / raw)
To: Zhang Rui, Eduardo Valentin, Rob Herring, Mark Rutland
Cc: linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Thomas Petazzoni, Gregory Clement, Antoine Tenart, Nadav Haklai,
Miquel Raynal, Baruch Siach, David Sniatkiwicz
In-Reply-To: <20171222093226.23456-1-miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
All Armada SoCs use one bit to declare if the sensor values are valid.
This bit moves across the versions of the IP.
The method until then was to do both a shift and compare with an useless
flag of "0x1". It is clearer and quicker to directly save the value that
must be ANDed instead of the bit position and do a single bitwise AND
operation.
Signed-off-by: Miquel Raynal <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Reviewed-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
drivers/thermal/armada_thermal.c | 14 ++++++--------
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
index 6c4af2622d4f..f350d7efd35a 100644
--- a/drivers/thermal/armada_thermal.c
+++ b/drivers/thermal/armada_thermal.c
@@ -24,8 +24,6 @@
#include <linux/of_device.h>
#include <linux/thermal.h>
-#define THERMAL_VALID_MASK 0x1
-
/* Thermal Manager Control and Status Register */
#define PMU_TDC0_SW_RST_MASK (0x1 << 1)
#define PMU_TM_DISABLE_OFFS 0
@@ -67,7 +65,7 @@ struct armada_thermal_data {
/* Register shift and mask to access the sensor temperature */
unsigned int temp_shift;
unsigned int temp_mask;
- unsigned int is_valid_shift;
+ u32 is_valid_bit;
};
static void armadaxp_init_sensor(struct platform_device *pdev,
@@ -149,9 +147,9 @@ static void armada380_init_sensor(struct platform_device *pdev,
static bool armada_is_valid(struct armada_thermal_priv *priv)
{
- unsigned long reg = readl_relaxed(priv->sensor);
+ u32 reg = readl_relaxed(priv->sensor);
- return (reg >> priv->data->is_valid_shift) & THERMAL_VALID_MASK;
+ return reg & priv->data->is_valid_bit;
}
static int armada_get_temp(struct thermal_zone_device *thermal,
@@ -199,7 +197,7 @@ static const struct armada_thermal_data armadaxp_data = {
static const struct armada_thermal_data armada370_data = {
.is_valid = armada_is_valid,
.init_sensor = armada370_init_sensor,
- .is_valid_shift = 9,
+ .is_valid_bit = BIT(9),
.temp_shift = 10,
.temp_mask = 0x1ff,
.coef_b = 3153000000UL,
@@ -210,7 +208,7 @@ static const struct armada_thermal_data armada370_data = {
static const struct armada_thermal_data armada375_data = {
.is_valid = armada_is_valid,
.init_sensor = armada375_init_sensor,
- .is_valid_shift = 10,
+ .is_valid_bit = BIT(10),
.temp_shift = 0,
.temp_mask = 0x1ff,
.coef_b = 3171900000UL,
@@ -221,7 +219,7 @@ static const struct armada_thermal_data armada375_data = {
static const struct armada_thermal_data armada380_data = {
.is_valid = armada_is_valid,
.init_sensor = armada380_init_sensor,
- .is_valid_shift = 10,
+ .is_valid_bit = BIT(10),
.temp_shift = 0,
.temp_mask = 0x3ff,
.coef_b = 1172499100UL,
--
2.11.0
--
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 related
* [PATCH v4 0/2] Initial Allwinner V3s CSI Support
From: Yong Deng @ 2017-12-22 9:32 UTC (permalink / raw)
To: "Maxime Ripard
Cc: Mauro Carvalho Chehab, Rob Herring, Mark Rutland, Chen-Yu Tsai,
David S. Miller, Greg Kroah-Hartman, Randy Dunlap, Hans Verkuil,
Stanimir Varbanov, Hugues Fruchet, Yannick Fertre, Philipp Zabel,
Arnd Bergmann, Benjamin Gaignard, Ramesh Shanmugasundaram,
Sakari Ailus, Rick Chang, linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Yong
This patchset add initial support for Allwinner V3s CSI.
Allwinner V3s SoC have two CSI module. CSI0 is used for MIPI interface
and CSI1 is used for parallel interface. This is not documented in
datasheet but by testing and guess.
This patchset implement a v4l2 framework driver and add a binding
documentation for it.
Currently, the driver only support the parallel interface. And has been
tested with a BT1120 signal which generating from FPGA. The following
fetures are not support with this patchset:
- ISP
- MIPI-CSI2
- Master clock for camera sensor
- Power regulator for the front end IC
Thanks for Ondřej Jirman's help.
Changes in v4:
* Deal with the CSI 'INNER QUEUE'.
CSI will lookup the next dma buffer for next frame before the
the current frame done IRQ triggered. This is not documented
but reported by Ondřej Jirman.
The BSP code has workaround for this too. It skip to mark the
first buffer as frame done for VB2 and pass the second buffer
to CSI in the first frame done ISR call. Then in second frame
done ISR call, it mark the first buffer as frame done for VB2
and pass the third buffer to CSI. And so on. The bad thing is
that the first buffer will be written twice and the first frame
is dropped even the queued buffer is sufficient.
So, I make some improvement here. Pass the next buffer to CSI
just follow starting the CSI. In this case, the first frame
will be stored in first buffer, second frame in second buffer.
This mothed is used to avoid dropping the first frame, it
would also drop frame when lacking of queued buffer.
* Fix: using a wrong mbus_code when getting the supported formats
* Change all fourcc to pixformat
* Change some function names
Changes in v3:
* Get rid of struct sun6i_csi_ops
* Move sun6i-csi to new directory drivers/media/platform/sunxi
* Merge sun6i_csi.c and sun6i_csi_v3s.c into sun6i_csi.c
* Use generic fwnode endpoints parser
* Only support a single subdev to make things simple
* Many complaintion fix
Changes in v2:
* Change sunxi-csi to sun6i-csi
* Rebase to media_tree master branch
Following is the 'v4l2-compliance -s -f' output, I have test this
with both interlaced and progressive signal:
# ./v4l2-compliance -s -f
v4l2-compliance SHA : 6049ea8bd64f9d78ef87ef0c2b3dc9b5de1ca4a1
Driver Info:
Driver name : sun6i-video
Card type : sun6i-csi
Bus info : platform:csi
Driver version: 4.15.0
Capabilities : 0x84200001
Video Capture
Streaming
Extended Pix Format
Device Capabilities
Device Caps : 0x04200001
Video Capture
Streaming
Extended Pix Format
Compliance test for device /dev/video0 (not using libv4l2):
Required ioctls:
test VIDIOC_QUERYCAP: OK
Allow for multiple opens:
test second video open: OK
test VIDIOC_QUERYCAP: OK
test VIDIOC_G/S_PRIORITY: OK
test for unlimited opens: OK
Debug ioctls:
test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
test VIDIOC_LOG_STATUS: OK (Not Supported)
Input ioctls:
test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
test VIDIOC_ENUMAUDIO: OK (Not Supported)
test VIDIOC_G/S/ENUMINPUT: OK
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 1 Audio Inputs: 0 Tuners: 0
Output ioctls:
test VIDIOC_G/S_MODULATOR: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_ENUMAUDOUT: OK (Not Supported)
test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
test VIDIOC_G/S_AUDOUT: OK (Not Supported)
Outputs: 0 Audio Outputs: 0 Modulators: 0
Input/Output configuration ioctls:
test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
test VIDIOC_G/S_EDID: OK (Not Supported)
Test input 0:
Control ioctls:
test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
test VIDIOC_QUERYCTRL: OK (Not Supported)
test VIDIOC_G/S_CTRL: OK (Not Supported)
test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
Standard Controls: 0 Private Controls: 0
Format ioctls:
test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
test VIDIOC_G/S_PARM: OK (Not Supported)
test VIDIOC_G_FBUF: OK (Not Supported)
test VIDIOC_G_FMT: OK
test VIDIOC_TRY_FMT: OK
test VIDIOC_S_FMT: OK
test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
test Cropping: OK (Not Supported)
test Composing: OK (Not Supported)
test Scaling: OK (Not Supported)
Codec ioctls:
test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
test VIDIOC_G_ENC_INDEX: OK (Not Supported)
test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)
Buffer ioctls:
test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
test VIDIOC_EXPBUF: OK
Test input 0:
Streaming ioctls:
test read/write: OK (Not Supported)
test MMAP: OK
test USERPTR: OK (Not Supported)
test DMABUF: Cannot test, specify --expbuf-device
Stream using all formats:
test MMAP for Format HM12, Frame Size 1280x720:
Stride 1920, Field None: OK
test MMAP for Format NV12, Frame Size 1280x720:
Stride 1920, Field None: OK
test MMAP for Format NV21, Frame Size 1280x720:
Stride 1920, Field None: OK
test MMAP for Format YU12, Frame Size 1280x720:
Stride 1920, Field None: OK
test MMAP for Format YV12, Frame Size 1280x720:
Stride 1920, Field None: OK
test MMAP for Format NV16, Frame Size 1280x720:
Stride 2560, Field None: OK
test MMAP for Format NV61, Frame Size 1280x720:
Stride 2560, Field None: OK
test MMAP for Format 422P, Frame Size 1280x720:
Stride 2560, Field None: OK
Total: 54, Succeeded: 54, Failed: 0, Warnings: 0
Yong Deng (2):
dt-bindings: media: Add Allwinner V3s Camera Sensor Interface (CSI)
media: V3s: Add support for Allwinner CSI.
.../devicetree/bindings/media/sun6i-csi.txt | 51 ++
MAINTAINERS | 8 +
drivers/media/platform/Kconfig | 1 +
drivers/media/platform/Makefile | 2 +
drivers/media/platform/sunxi/sun6i-csi/Kconfig | 9 +
drivers/media/platform/sunxi/sun6i-csi/Makefile | 3 +
drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c | 878 +++++++++++++++++++++
drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h | 147 ++++
.../media/platform/sunxi/sun6i-csi/sun6i_csi_reg.h | 203 +++++
.../media/platform/sunxi/sun6i-csi/sun6i_video.c | 752 ++++++++++++++++++
.../media/platform/sunxi/sun6i-csi/sun6i_video.h | 60 ++
11 files changed, 2114 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/sun6i-csi.txt
create mode 100644 drivers/media/platform/sunxi/sun6i-csi/Kconfig
create mode 100644 drivers/media/platform/sunxi/sun6i-csi/Makefile
create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h
create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi_reg.h
create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_video.c
create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_video.h
--
1.8.3.1
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ 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