* Re: [PATCH/RFC v2 1/2] arm64: dts: r8a7795: Add support for R-Car H3 ES2.0
From: Simon Horman @ 2017-03-29 8:45 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Laurent Pinchart, Geert Uytterhoeven, Magnus Damm,
Yoshihiro Shimoda, Kuninori Morimoto, Wolfram Sang, Rob Herring,
Mark Rutland, Linux-Renesas, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAMuHMdWvR71V_JyR6273KmdtGfrrT_vaU2vcDTpNt2MAG0WdLg@mail.gmail.com>
On Wed, Mar 29, 2017 at 10:31:02AM +0200, Geert Uytterhoeven wrote:
> Hi Simon,
>
> On Wed, Mar 29, 2017 at 10:13 AM, Simon Horman <horms@verge.net.au> wrote:
> > On Mon, Mar 27, 2017 at 11:48:12AM +0300, Laurent Pinchart wrote:
> >> On Friday 24 Mar 2017 14:37:44 Geert Uytterhoeven wrote:
> >> > Update r8a7795.dtsi so it corresponds to R-Car H3 ES2.0 or later:
> >> > - The following devices no longer exist on ES2.0, and are thus removed:
> >> > fcpf2, fcpvd3, fcpvi2, fdp1-2, usb3-if1, vspd3, vspi2.
> >> > - The DU <-> VSPD topology is different on ES2.0, hence remove the
> >> > "vsps" property from the DU node until the driver can handle this.
> >>
> >> I think I'll need a different compatible string between ES1.x and ES2 for the
> >> DU. It could make sense to move the whole DU node to *-es1.dtsi. We can decide
> >> about that later when I'll have a DU driver prototype ready.
> >
> > That makes sense to me.
> >
> > Geert, will you respin this?
>
> Sure. The DTS parts are definitely not v4.12 material.
> - For ES2.0, they depend on clk/pfc/rcar-sysc updates.
> - For ES1.x, I don't want to break people's setup (scripts copying
> r8a7795-salvator-x.dtb) prematurely.
Ok.
^ permalink raw reply
* [REPOST PATCH] ARM: dts: imx6qp-nitrogen6_som2: add Quad Plus variant of the SOM
From: Gary Bisson @ 2017-03-29 8:45 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, fabio.estevam-3arQi8VN3Tc,
shawnguo-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
Gary Bisson
In-Reply-To: <20170327160601.12871-1-gary.bisson-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>
https://boundarydevices.com/product/nit6x-som-v2/
Reviewed-by: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
Signed-off-by: Gary Bisson <gary.bisson-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>
---
Hi,
This is just a re-post to LAKML as suggested by Shawn [1].
Also include the Review tag from Fabio [2].
Regards,
Gary
[1] http://www.spinics.net/lists/devicetree/msg170732.html
[2] http://www.spinics.net/lists/devicetree/msg170354.html
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6qp-nitrogen6_som2.dts | 55 +++++++++++++++++++++++++++++
2 files changed, 56 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6qp-nitrogen6_som2.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 011808490fed..6190afe94371 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -426,6 +426,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6q-wandboard.dtb \
imx6q-wandboard-revb1.dtb \
imx6qp-nitrogen6_max.dtb \
+ imx6qp-nitrogen6_som2.dtb \
imx6qp-sabreauto.dtb \
imx6qp-sabresd.dtb
dtb-$(CONFIG_SOC_IMX6SL) += \
diff --git a/arch/arm/boot/dts/imx6qp-nitrogen6_som2.dts b/arch/arm/boot/dts/imx6qp-nitrogen6_som2.dts
new file mode 100644
index 000000000000..011726c836cd
--- /dev/null
+++ b/arch/arm/boot/dts/imx6qp-nitrogen6_som2.dts
@@ -0,0 +1,55 @@
+/*
+ * Copyright 2017 Boundary Devices, Inc.
+ *
+ * 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 "imx6qp.dtsi"
+#include "imx6qdl-nitrogen6_som2.dtsi"
+
+/ {
+ model = "Boundary Devices i.MX6 Quad Plus Nitrogen6_SOM2 Board";
+ compatible = "boundary,imx6qp-nitrogen6_som2", "fsl,imx6qp";
+};
+
+&sata {
+ status = "okay";
+};
--
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
* Re: [PATCH v6 02/39] [media] dt-bindings: Add bindings for i.MX media driver
From: Russell King - ARM Linux @ 2017-03-29 8:39 UTC (permalink / raw)
To: Rob Herring
Cc: Steve Longerbeam, Mark Rutland, Shawn Guo,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org, Fabio Estevam,
Mauro Carvalho Chehab, Hans Verkuil, Nick Dyer,
markus.heiser-m1Uo1GnMJf0b1SvskN2V4Q, Philipp Zabel,
Laurent Pinchart, Benoit Parrot, Geert Uytterhoeven,
Arnd Bergmann, Sudip Mukherjee, Minghsiu Tsai, tiffany lin,
Jean-Christophe Trotin, Simon Horman <horms+renesas@
In-Reply-To: <CAL_JsqJm_JjuVPcOBERCqsnjTDdNoKr9xRE9MXMO4ivxGath2Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, Mar 28, 2017 at 07:21:34PM -0500, Rob Herring wrote:
> On Mon, Mar 27, 2017 at 7:40 PM, Steve Longerbeam <slongerbeam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > Add bindings documentation for the i.MX media driver.
> >
> > Signed-off-by: Steve Longerbeam <steve_longerbeam-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
> > ---
> > Documentation/devicetree/bindings/media/imx.txt | 74 +++++++++++++++++++++++++
> > 1 file changed, 74 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/media/imx.txt
> >
> > diff --git a/Documentation/devicetree/bindings/media/imx.txt b/Documentation/devicetree/bindings/media/imx.txt
> > new file mode 100644
> > index 0000000..3059c06
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/imx.txt
> > @@ -0,0 +1,74 @@
> > +Freescale i.MX Media Video Device
> > +=================================
> > +
> > +Video Media Controller node
> > +---------------------------
> > +
> > +This is the media controller node for video capture support. It is a
> > +virtual device that lists the camera serial interface nodes that the
> > +media device will control.
> > +
> > +Required properties:
> > +- compatible : "fsl,imx-capture-subsystem";
> > +- ports : Should contain a list of phandles pointing to camera
> > + sensor interface ports of IPU devices
> > +
> > +example:
> > +
> > +capture-subsystem {
> > + compatible = "fsl,imx-capture-subsystem";
> > + ports = <&ipu1_csi0>, <&ipu1_csi1>;
> > +};
> > +
> > +fim child node
> > +--------------
> > +
> > +This is an optional child node of the ipu_csi port nodes. If present and
> > +available, it enables the Frame Interval Monitor. Its properties can be
> > +used to modify the method in which the FIM measures frame intervals.
> > +Refer to Documentation/media/v4l-drivers/imx.rst for more info on the
> > +Frame Interval Monitor.
> > +
> > +Optional properties:
> > +- fsl,input-capture-channel: an input capture channel and channel flags,
> > + specified as <chan flags>. The channel number
> > + must be 0 or 1. The flags can be
> > + IRQ_TYPE_EDGE_RISING, IRQ_TYPE_EDGE_FALLING, or
> > + IRQ_TYPE_EDGE_BOTH, and specify which input
> > + capture signal edge will trigger the input
> > + capture event. If an input capture channel is
> > + specified, the FIM will use this method to
> > + measure frame intervals instead of via the EOF
> > + interrupt. The input capture method is much
> > + preferred over EOF as it is not subject to
> > + interrupt latency errors. However it requires
> > + routing the VSYNC or FIELD output signals of
> > + the camera sensor to one of the i.MX input
> > + capture pads (SD1_DAT0, SD1_DAT1), which also
> > + gives up support for SD1.
> > +
> > +
> > +mipi_csi2 node
> > +--------------
> > +
> > +This is the device node for the MIPI CSI-2 Receiver, required for MIPI
> > +CSI-2 sensors.
> > +
> > +Required properties:
> > +- compatible : "fsl,imx6-mipi-csi2", "snps,dw-mipi-csi2";
>
> As I mentioned in v5, there's a DW CSI2 binding in progress. This
> needs to be based on that.
Maybe someone can provide some kind of reference to it, and it's
associated driver?
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
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/RFC v2 1/2] arm64: dts: r8a7795: Add support for R-Car H3 ES2.0
From: Geert Uytterhoeven @ 2017-03-29 8:31 UTC (permalink / raw)
To: Simon Horman
Cc: Laurent Pinchart, Geert Uytterhoeven, Magnus Damm,
Yoshihiro Shimoda, Kuninori Morimoto, Wolfram Sang, Rob Herring,
Mark Rutland, Linux-Renesas, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20170329081352.GF6512@verge.net.au>
Hi Simon,
On Wed, Mar 29, 2017 at 10:13 AM, Simon Horman <horms@verge.net.au> wrote:
> On Mon, Mar 27, 2017 at 11:48:12AM +0300, Laurent Pinchart wrote:
>> On Friday 24 Mar 2017 14:37:44 Geert Uytterhoeven wrote:
>> > Update r8a7795.dtsi so it corresponds to R-Car H3 ES2.0 or later:
>> > - The following devices no longer exist on ES2.0, and are thus removed:
>> > fcpf2, fcpvd3, fcpvi2, fdp1-2, usb3-if1, vspd3, vspi2.
>> > - The DU <-> VSPD topology is different on ES2.0, hence remove the
>> > "vsps" property from the DU node until the driver can handle this.
>>
>> I think I'll need a different compatible string between ES1.x and ES2 for the
>> DU. It could make sense to move the whole DU node to *-es1.dtsi. We can decide
>> about that later when I'll have a DU driver prototype ready.
>
> That makes sense to me.
>
> Geert, will you respin this?
Sure. The DTS parts are definitely not v4.12 material.
- For ES2.0, they depend on clk/pfc/rcar-sysc updates.
- For ES1.x, I don't want to break people's setup (scripts copying
r8a7795-salvator-x.dtb) prematurely.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH V6 4/7] mfd: da9061: MFD core support
From: Lee Jones @ 2017-03-29 8:30 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Steve Twiss, kbuild test robot,
kbuild-all-JC7UmRfGjtg@public.gmane.org, LINUX-KERNEL, DEVICETREE,
Dmitry Torokhov, Eduardo Valentin, Guenter Roeck, LINUX-INPUT,
LINUX-PM, LINUX-WATCHDOG, Liam Girdwood, Mark Brown, Mark Rutland,
Rob Herring, Support Opensource, Wim Van Sebroeck, Zhang Rui
In-Reply-To: <CAMuHMdU-kaAZ-Reji2v3jSypoDSiwYEWqD0vyYWwJpr6+rAPOA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, 28 Mar 2017, Geert Uytterhoeven wrote:
> Hi Steve,
>
> On Tue, Mar 28, 2017 at 12:42 PM, Steve Twiss
> <stwiss.opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org> wrote:
> > On 28 March 2017 09:37, Geert Uytterhoeven wrote:
> >> Subject: Re: [PATCH V6 4/7] mfd: da9061: MFD core support
> >> On Tue, Mar 28, 2017 at 10:21 AM, Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> >> >> [auto build test WARNING on ljones-mfd/for-mfd-next]
> >> >> [also build test WARNING on v4.11-rc4 next-20170327]
> >> >> base: https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git for-mfd-next
> >> >> config: x86_64-randconfig-x009-201713 (attached as .config)
> >> >> compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
> >> >> reproduce:
> >> >> # save the attached .config to linux build tree
> >> >> make ARCH=x86_64
> >> >>
> >> >> All warnings (new ones prefixed by >>):
> >> >>
> >> >> drivers//mfd/da9062-core.c: In function 'da9062_i2c_probe':
> >> >> >> drivers//mfd/da9062-core.c:845:21: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
> >> >> chip->chip_type = (int)match->data;
> >> >> ^
> >> >
> >> > Please use longs or enums.
> >>
> >> Enums would still give a warning on 64-bit.
> >> The simple fix is change the cast from (int) to (uintptr_t).
> >
> > Hi Lee and Geert,
> >
> > How about this? Fix by redefining the enum chip_type to be an int.
> > Then, just use substitution:
> > #define COMPAT_TYPE_DA9061 1
> > #define COMPAT_TYPE_DA9062 2
> >
> > That would be simple.
> > Are there any reasons this would not be acceptable?
>
> I don't see how that can help.
> The warning is caused by casting the "void *" (which is either 32-bit or
> 64-bit) in of_device_if.data to an integer or enum (which is always 32-bit).
>
> The right fix is to cast it to uintptr_t intead of int, like other drivers do.
That's a hack though, isn't it? chip->chip_type is not of type
uintptr_t, so all you're doing here is making the compiler happy.
I see people using (int)(uintptr_t), which I guess keeps the
compiler happy in the first instance and actually culminates in a
correct cast to the right type.
So how about something like (enum da9062_compatible_types)(long)?
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 6/8] regulator: arizona-micbias: Add regulator driver for Arizona micbiases
From: Charles Keepax @ 2017-03-29 8:30 UTC (permalink / raw)
To: broonie, lee.jones
Cc: mark.rutland, devicetree, alsa-devel, patches, lgirdwood,
linux-kernel, robh+dt
In-Reply-To: <201703291403.z4sFz6z9%fengguang.wu@intel.com>
On Wed, Mar 29, 2017 at 02:18:23PM +0800, kbuild test robot wrote:
> Hi Charles,
>
> [auto build test WARNING on regulator/for-next]
> [also build test WARNING on v4.11-rc4 next-20170328]
> [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/Charles-Keepax/regulator-arizona-micsupp-Avoid-potential-memory-leak-reading-init_data/20170329-112224
> base: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next
> config: i386-randconfig-x0-03291136 (attached as .config)
> compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=i386
>
Hmm... this is due to the tree missing the patch that Lee already
applied from version 1. I guess perhaps we should pull that back
into this series or he could make an immutable branch you can pull
in?
Thanks,
Charles
^ permalink raw reply
* Re: [PATCH v8 3/3] ARM: dts: imx6q-icore: Add touchscreen node
From: Shawn Guo @ 2017-03-29 8:22 UTC (permalink / raw)
To: Jagan Teki
Cc: linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Jagan Teki, Dmitry Torokhov,
Domenico Acri, Matteo Lisi, Michael Trimarchi
In-Reply-To: <1490209518-20790-3-git-send-email-jagan-oRp2ZoJdM/RWk0Htik3J/w@public.gmane.org>
On Thu, Mar 23, 2017 at 12:35:18AM +0530, Jagan Teki wrote:
> From: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
>
> max11801 touchscreen on Engicam iCoreM6 Quad module is
> connected via i2c1, so add max11801: touchscreen@48 on i2c1.
>
> Cc: Dmitry Torokhov <dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Cc: Domenico Acri <domenico.acri-4s7YQHO/iPVBDgjK7y7TUQ@public.gmane.org>
> Cc: Matteo Lisi <matteo.lisi-4s7YQHO/iPVBDgjK7y7TUQ@public.gmane.org>
> Cc: Michael Trimarchi <michael-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
> Cc: Shawn Guo <shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
Applied, thanks.
--
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/RFC v2 1/2] arm64: dts: r8a7795: Add support for R-Car H3 ES2.0
From: Simon Horman @ 2017-03-29 8:13 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Geert Uytterhoeven, Magnus Damm, Yoshihiro Shimoda,
Kuninori Morimoto, Wolfram Sang, Rob Herring, Mark Rutland,
linux-renesas-soc, devicetree, linux-arm-kernel
In-Reply-To: <1612430.SNEha5n02K@avalon>
On Mon, Mar 27, 2017 at 11:48:12AM +0300, Laurent Pinchart wrote:
> Hi Geert,
>
> Thank you for the patch.
>
> On Friday 24 Mar 2017 14:37:44 Geert Uytterhoeven wrote:
> > Update r8a7795.dtsi so it corresponds to R-Car H3 ES2.0 or later:
> > - The following devices no longer exist on ES2.0, and are thus removed:
> > fcpf2, fcpvd3, fcpvi2, fdp1-2, usb3-if1, vspd3, vspi2.
> > - The DU <-> VSPD topology is different on ES2.0, hence remove the
> > "vsps" property from the DU node until the driver can handle this.
>
> I think I'll need a different compatible string between ES1.x and ES2 for the
> DU. It could make sense to move the whole DU node to *-es1.dtsi. We can decide
> about that later when I'll have a DU driver prototype ready.
That makes sense to me.
Geert, will you respin this?
^ permalink raw reply
* Re: [PATCH] ARM: dts: r7s72100: add power-domains to sdhi
From: Simon Horman @ 2017-03-29 8:09 UTC (permalink / raw)
To: Chris Brandt
Cc: Geert Uytterhoeven, Magnus Damm, Rob Herring, Mark Rutland,
devicetree@vger.kernel.org, Linux-Renesas
In-Reply-To: <SG2PR06MB116573C9325106B5ED4580578A3E0@SG2PR06MB1165.apcprd06.prod.outlook.com>
On Fri, Mar 24, 2017 at 11:17:25AM +0000, Chris Brandt wrote:
> On Friday, March 24, 2017, Geert Uytterhoeven wrote:
> > > The fixes tag above indicates this is a fix for v4.10, however, when I
> > > tried to apply it on top of v4.11-rc1 there was a conflict. So I
> > > think a backport will be required if we want it to be considered for
> > > v4.11 and be considered for and in turn v4.10-stable.
> >
> > That's because of commit 3d2abda02ad2d06d
> > ("ARM: dts: r7s72100: update sdhi clock bindings")
>
>
> Between the two, "update sdhi clock bindings" is more important this this patch ("add power-domains").
> Without "update sdhi clock bindings", the SDHI /might/ not work.
>
>
> But, "update sdhi clock bindings", also relies on the driver update 34a1654706c6 ("mmc: sh_mobile_sdhi: add support for 2 clocks").
> That one is in v4.11-rc1, but not in 4.10.5.
>
> I just noticed now that 34a1654706c6 does not have "Fixes" in the commit log, so it is probably not marked to go into v4.10-stable, so in that case backporting the dtsi is pointless.
We could try to coordinate getting 34a1654706c6 and the dtsi changes into
v4.10-stable if you it is sufficiently important. What are your thoughts on
that?
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: Document the STM32 MDMA bindings
From: M'boumba Cedric Madianga @ 2017-03-29 8:07 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, devicetree@vger.kernel.org, Alexandre Torgue,
Vinod Koul, linux-kernel@vger.kernel.org, Maxime Coquelin,
dmaengine, Dan Williams, linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAL_JsqLMn7W=r+JRX51zOScs9N04PcTtX8EFy2eacwadCxwaRg@mail.gmail.com>
Hi Rob,
> stm32 is not a specific SoC. Compatible strings should be specific to
> an SoC (with fallback strings to whatever they are compatible with) so
> you can handle SoC specific differences or errata.
Ok I see. I will add a more specific SoC description in my compatible.
Thanks.
> I still don't understand. Is the difference in DMA addresses vs. CPU
> addresses? If so, you should dma-ranges to translate these.
Not really.
In fact, the MDMA controller provides a master AXI interface for
memories like DDR/SRAM and peripheral registers access (system access
port).
It also provides a master AHB interface only for Cortex-M7 TCM memory
access (TCM access port).
So the goal of this st,ahb-addr-masks property is to list all TCM
addresses avalaible in the SoC, in order to correctly configure the
MDMA as an AHB master in that particular case.
For all other cases (other memories or peripheral registers access),
the MDMA will act as AXI master.
Hope it helps to understand.
BR,
Cedric
^ permalink raw reply
* Re: [PATCH v3 3/9] arm: fix return value of parse_cpu_capacity
From: Juri Lelli @ 2017-03-29 8:06 UTC (permalink / raw)
To: Vincent Guittot
Cc: linux-kernel, linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
LAK, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Peter Zijlstra, Rob Herring, Mark Rutland,
Russell King - ARM Linux, Sudeep Holla, Lorenzo Pieralisi,
Catalin Marinas, Will Deacon, Morten Rasmussen, Dietmar Eggemann,
Mark Brown,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org
In-Reply-To: <CAKfTPtCswVBMCaEUzBF4w_GZf-2iLORsS5S0HhGD94ps4+J1Xg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 29/03/17 09:37, Vincent Guittot wrote:
> On 27 March 2017 at 15:18, Juri Lelli <juri.lelli-5wv7dgnIgG8@public.gmane.org> wrote:
> > parse_cpu_capacity() has to return 0 on failure, but it currently returns
> > 1 instead if raw_capacity kcalloc failed.
> >
> > Fix it by removing the negation of the return value.
> >
> > Cc: Russell King <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
> > Reported-by: Morten Rasmussen <morten.rasmussen-5wv7dgnIgG8@public.gmane.org>
> > Fixes: 06073ee26775 ('ARM: 8621/3: parse cpu capacity-dmips-mhz from DT')
> > Signed-off-by: Juri Lelli <juri.lelli-5wv7dgnIgG8@public.gmane.org>
> > ---
> > arch/arm/kernel/topology.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c
> > index f8a3ab82e77f..4e4af809606a 100644
> > --- a/arch/arm/kernel/topology.c
> > +++ b/arch/arm/kernel/topology.c
> > @@ -166,7 +166,7 @@ static int __init parse_cpu_capacity(struct device_node *cpu_node, int cpu)
> > if (!raw_capacity) {
> > pr_err("cpu_capacity: failed to allocate memory for raw capacities\n");
> > cap_parsing_failed = true;
> > - return !ret;
> > + return ret;
>
> Why not directly returning 0 ? whatever the value of ret, the parse of
> cpu capacity has failed in this case
>
Sure, can change that.
Thanks,
- Juri
--
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: [PATCHv4] mfd: cpcap: implement irq sense helper
From: Lee Jones @ 2017-03-29 8:04 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Tony Lindgren, Dmitry Torokhov, Rob Herring, Mark Rutland,
linux-input, devicetree, linux-kernel
In-Reply-To: <20170328145415.td4xeqxedem5yjen@earth>
On Tue, 28 Mar 2017, Sebastian Reichel wrote:
> Hi Lee,
>
> On Tue, Mar 28, 2017 at 11:27:16AM +0100, Lee Jones wrote:
> > > +int cpcap_sense_virq(struct regmap *regmap, int virq)
> > > +{
> > > + struct regmap_irq_chip_data *d = irq_get_chip_data(virq);
> > > + int base = regmap_irq_chip_get_base(d);
> >
> > What base is this?
>
> This function takes an Linux irq number. That number is a virtual
> irq number, which has nothing to do with the hardware. For example
> a platform could look like this:
>
> linux irq device base device irq
> ---------------------------------------------
> 0-63 SoC 0 0-63
> 64-127 SoC-GPIO 64 0-63
> 128-191 CPCAP 128 0-63
>
> For the above example the function would map 128-191 to 0-63 as
> used by the device.
In which case may I suggest that you rename the variable, since 'base'
is commonly used in the kernel to mean base of a particular IP's
memory block.
> > Could it be used to avoid some calculations in cpcap_sense_irq()?
>
> No.
>
> > > + return cpcap_sense_irq(regmap, virq - base);
> > > +}
> > > +EXPORT_SYMBOL_GPL(cpcap_sense_virq);
>
> -- Sebastian
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH 1/2] ARM: dts: r8a7792: add IMR-L[S]X3 clocks
From: Simon Horman @ 2017-03-29 8:04 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Mark Rutland, devicetree, Magnus Damm, Russell King,
linux-renesas-soc, Rob Herring, linux-arm-kernel
In-Reply-To: <a802018c-9943-22e5-0f78-28b8ab9689d9@cogentembedded.com>
On Tue, Mar 21, 2017 at 11:14:43PM +0300, Sergei Shtylyov wrote:
> On 03/21/2017 11:08 PM, Sergei Shtylyov wrote:
>
> >Still not cover letter but I think it's better now, so I won't retry...
> >The patches are against Simon Horman's 'renesas.git' repo,
> >'renesas-devel-20170321-v4.11-rc3' tag.
>
> The patches depend on the IMR driver patches adding the IMR-L[S]X3
> support for the "compatible" values.
I have marked these patches as deferred accordingly.
^ permalink raw reply
* Re: [PATCH v3 05/11] Documentation: DT: bindings: input: touschcreen: remove sun4i documentation
From: Lee Jones @ 2017-03-29 7:58 UTC (permalink / raw)
To: Quentin Schulz
Cc: dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, jic23-DgEjT+Ai2ygdnm+yROfE0A,
knaack.h-Mmb7MZpHnFY, lars-Qo5EllUWu/uELgA04lAiVw,
pmeerw-jW+XmwGofnusTnJN9+BGXg,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
linux-input-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, icenowy-ymACFijhrKM
In-Reply-To: <20170321153611.16228-6-quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On Tue, 21 Mar 2017, Quentin Schulz wrote:
> This patch removes the sun4i touchscreen controller binding
> documentation since it has been merged with the sun4i GPADC binding
> documentation.
>
> Signed-off-by: Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> ---
>
> added in v2
>
> .../bindings/input/touchscreen/sun4i.txt | 38 ----------------------
Just an Input Ack missing here.
> 1 file changed, 38 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/input/touchscreen/sun4i.txt
>
> diff --git a/Documentation/devicetree/bindings/input/touchscreen/sun4i.txt b/Documentation/devicetree/bindings/input/touchscreen/sun4i.txt
> deleted file mode 100644
> index 89abecd..0000000
> --- a/Documentation/devicetree/bindings/input/touchscreen/sun4i.txt
> +++ /dev/null
> @@ -1,38 +0,0 @@
> -sun4i resistive touchscreen controller
> ---------------------------------------
> -
> -Required properties:
> - - compatible: "allwinner,sun4i-a10-ts", "allwinner,sun5i-a13-ts" or
> - "allwinner,sun6i-a31-ts"
> - - reg: mmio address range of the chip
> - - interrupts: interrupt to which the chip is connected
> - - #thermal-sensor-cells: shall be 0
> -
> -Optional properties:
> - - allwinner,ts-attached : boolean indicating that an actual touchscreen
> - is attached to the controller
> - - allwinner,tp-sensitive-adjust : integer (4 bits)
> - adjust sensitivity of pen down detection
> - between 0 (least sensitive) and 15
> - (defaults to 15)
> - - allwinner,filter-type : integer (2 bits)
> - select median and averaging filter
> - samples used for median / averaging filter
> - 0: 4/2
> - 1: 5/3
> - 2: 8/4
> - 3: 16/8
> - (defaults to 1)
> -
> -Example:
> -
> - rtp: rtp@01c25000 {
> - compatible = "allwinner,sun4i-a10-ts";
> - reg = <0x01c25000 0x100>;
> - interrupts = <29>;
> - allwinner,ts-attached;
> - #thermal-sensor-cells = <0>;
> - /* sensitive/noisy touch panel */
> - allwinner,tp-sensitive-adjust = <0>;
> - allwinner,filter-type = <3>;
> - };
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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
* Re: [PATCH v4 01/18] dt-bindings: power: battery: add constant-charge-current property
From: Quentin Schulz @ 2017-03-29 7:54 UTC (permalink / raw)
To: Liam Breck; +Cc: Sebastian Reichel, robh+dt, linux-pm, devicetree
In-Reply-To: <CAKvHMgSFNBmr3fU-biHDo5tzCDV7QaCpFnbChgn4wgSN_1FBig@mail.gmail.com>
Hi,
On 29/03/2017 09:39, Liam Breck wrote:
> On Wed, Mar 29, 2017 at 12:09 AM, Quentin Schulz
> <quentin.schulz@free-electrons.com> wrote:
>> Hi Liam,
>>
>> On 29/03/2017 08:55, Liam Breck wrote:
>>> Hi Quentin,
>>>
>>> On Thu, Mar 16, 2017 at 12:42 AM, Liam Breck <liam@networkimprov.net> wrote:
>>>> On Thu, Mar 16, 2017 at 12:03 AM, Quentin Schulz
>>>> <quentin.schulz@free-electrons.com> wrote:
>>>>> Hi Liam,
>>>>>
>>>>> On 16/03/2017 07:27, Liam Breck wrote:
>>>>>> Hi Rob,
>>>>>>
>>>>>> On Wed, Mar 15, 2017 at 6:10 AM, Quentin Schulz
>>>>>> <quentin.schulz@free-electrons.com> wrote:
>>>>>>> Hi Liam,
>>>>>>>
>>>>>>> On 15/03/2017 13:08, Liam Breck wrote:
>>>>>>>> I dropped most of the CCs, pls re-add anyone essential. Use Cc lines
>>>>>>>> in patch description to direct a patch to interested parties and
>>>>>>>> relevant lists. I don't want to see all 19 patches in this series.
>>>>>>>>
>>>>>>>> On Wed, Mar 15, 2017 at 3:55 AM, Quentin Schulz
>>>>>>>> <quentin.schulz@free-electrons.com> wrote:
>>>>>>>>> This adds the constant-charge-current property to the list of optional
>>>>>>>>> properties of the battery.
>>>>>>>>>
>>>>>>>>> The constant charge current is critical for batteries as they can't
>>>>>>>>> handle all charge currents.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
>>>>>>>>> Acked-by: Rob Herring <robh@kernel.org>
>>>>>>>>> ---
>>>>>>>>>
>>>>>>>>> v4:
>>>>>>>>> - switch from constant-charge-current-microamp to constant-charge-microamp,
>>>>>>
>>>>>> Sebastian is on record supporting name alignment between DT:battery
>>>>>> properties and enum power_supply_property.
>>>>>>
>>>>>> Could you OK a change back to constant-charge-current-microamp in this patch?
>>>>>>
>>>>>> Note that the following could appear in DT:battery in future:
>>>>>>
>>>>>> constant-charge-current-microamp
>>>>>> constant-charge-current-max-microamp
>>>>>
>>>>> OK. I am actually setting max constant charge current and constant
>>>>> current charge with the same DT property so I might need to adapt my
>>>>> patches.
>>>>
>>>> I suspect you should set battery:*-current-max with DT, as -current is
>>>> "programmed by charger" so seems to be a stat, not a fixed
>>>> characteristic.
>>>
>>> Did you resolve this issue?
>>>
>>
>> Sorry, completely missed your first mail.
>>
>> Constant charge current is actually what I set in the PMIC. The maximum
>> constant charge current is completely PMIC-agnostic in my driver as it
>> is used to tell the user that (s)he shouldn't really have a constant
>> charge current over the maximum limit as the battery might not be able
>> to handle such high current.
>>
>> What I suggest is to have both properties in DT. I'll set the maximum as
>> I do today and we can give the user the ability to set a "default"
>> constant charge current (below maximum constant charge current) in the
>> DT. Maybe we do not want to recharge your battery with the maximum value
>> by default?
>
> The scope here is just static battery characteristics. For the battery
> node, I think constant-charge-current-max-microamp is the relevant
> term.
If it's only for static battery characteristics, I agree.
> If we added both properties, one would be an alias for the
> other, which doesn't seem useful.
>
Hum. Not really an alias. In my driver, I have a maximum which avoids to
set a constant charge current higher than what the battery is supposed
to be able to handle. The maximum can be increased via sysfs if ever the
user decides to go wild (or if (s)he changes the battery for example).
The maximum is never input in any of PMIC registers, it is not dealing
with the PMIC at all.
If I have only the max constant charge current in the DT, I'll set the
max and constant charge current with the same DT entry. That's perfectly
fine.
However, what I was thinking is to have a "default" value taken from DT
for constant charge current (which will be below maximum ccc) if ever
someone wants to set a maximum but use a lower ccc value. Anyway, I
guess it's more a "fancy" feature than a requirement (unlike max-ccc).
> The pmic can report both independently of the battery characteristic,
> and take a driver-specific DT property for
> constant-charge-current-microamp which it applies if less than the
> battery's -max setting.
Indeed.
> Or you could set that in userspace via
> /sys/class.../constant_charge_current.
The goal is to have both. The DT for default values (given by the
vendor/upstream) and sysfs for custom values (interesting if you don't
want to/can't recompile a DT.
> The charger's -max value would
> be a characteristic of its regulator.
>
I don't really understand what you mean by that.
> Or am I missing something...?
>
>>> Rob & Sebastian want me to merge all items for
>>> bindings/power/supply/battery.txt. If I do that I'll also roll up
>>> their counterparts in power_supply_core.c and submit a patchset for
>>> those two files.
>>>
>>
>> I guess that adding the two properties make sense, don't you think?
>>
>> Also, could you Cc me on your next version of your patches? So I know
>> when to rebase and slightly rework my patches once your patch series is
>> merged.
>
> Surely.
>
>> Thanks,
>> Quentin
>>
>>>> You may program your charger's -current with the battery's
>>>> -current-max, of course.
>>>>
>>>> Note that your charger also has a -current-max characteristic, likely
>>>> different than your battery. You may not need that in DT tho.
>>>>
>>>>>> constant-charge-voltage-microvolt
>>>>>> constant-charge-voltage-max-microvolt
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>>>> Must be constant-charge-current-microamp for the reasons discussed in
>>>>>>>> battery.txt - consistency with sysfs names.
>>>>>>>>
>>>>>>>
>>>>>>> Hum. Just nitpicking, but I disagree with the use of 'must'. IIRC there
>>>>>>> is nothing in the code that would require the property to be named after
>>>>>>> a property from the enum power_supply_property.
>>>>>>>
>>>>>>> I would say that you _want_ it to be named like that because it
>>>>>>> underlines the relation between the DT property and the actual impacted
>>>>>>> property in the power supply subsystem. I'm fine with this reason but in
>>>>>>> the end, the maintainer's opinion prevails (if (s)he does not want it,
>>>>>>> (s)he will not take it). So, basically, I actually don't mind either
>>>>>>> option and I see arguments on each side.
>>>>>>>
>>>>>>> So, just waiting for maintainer's opinion to make the final version of
>>>>>>> this patch.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Quentin
>>>>>>>
>>>>>>>> Also applies to power_supply_core.c patch.
>>>>>>>>
>>>>>>>> Rob: enum power_supply_property also lists constant-charge-voltage,
>>>>>>>> hence the -current
>>>>>>>>
>>>>>>>>
>>>>>>>>> added in v3
>>>>>>>>>
>>>>>>>>> Documentation/devicetree/bindings/power/supply/battery.txt | 2 ++
>>>>>>>>> 1 file changed, 2 insertions(+)
>>>>>>>>>
>>>>>>>>> diff --git a/Documentation/devicetree/bindings/power/supply/battery.txt b/Documentation/devicetree/bindings/power/supply/battery.txt
>>>>>>>>> index 0278617..9594e1e 100644
>>>>>>>>> --- a/Documentation/devicetree/bindings/power/supply/battery.txt
>>>>>>>>> +++ b/Documentation/devicetree/bindings/power/supply/battery.txt
>>>>>>>>> @@ -7,6 +7,7 @@ Optional Properties:
>>>>>>>>> - voltage-min-design-microvolt: drained battery voltage
>>>>>>>>> - energy-full-design-microwatt-hours: battery design energy
>>>>>>>>> - charge-full-design-microamp-hours: battery design capacity
>>>>>>>>> + - constant-charge-microamp: battery constant charge current
>>>>>>>>>
>>>>>>>>> Because drivers surface properties in sysfs using names derived
>>>>>>>>> from enum power_supply_property, e.g.
>>>>>>>>> @@ -30,6 +31,7 @@ Example:
>>>>>>>>> voltage-min-design-microvolt = <3200000>;
>>>>>>>>> energy-full-design-microwatt-hours = <5290000>;
>>>>>>>>> charge-full-design-microamp-hours = <1430000>;
>>>>>>>>> + constant-charge-microamp = <300000>;
>>>>>>>>> };
>>>>>>>>>
>>>>>>>>> charger: charger@11 {
>>>>>>>>> --
>>>>>>>>> 2.9.3
>>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Quentin Schulz, Free Electrons
>>>>>>> Embedded Linux and Kernel engineering
>>>>>>> http://free-electrons.com
>>>>>
>>>>> --
>>>>> Quentin Schulz, Free Electrons
>>>>> Embedded Linux and Kernel engineering
>>>>> http://free-electrons.com
>>
>> --
>> Quentin Schulz, Free Electrons
>> Embedded Linux and Kernel engineering
>> http://free-electrons.com
--
Quentin Schulz, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [RFC PATCH 2/3] iio: adc: sun4i-gpadc-iio: add support for H3 thermal sensor
From: Lee Jones @ 2017-03-29 7:54 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Quentin Schulz, Zhang Rui, linux-pm-u79uwXL29TY76Z2rM5mHXA,
Rob Herring, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Jonathan Cameron,
Maxime Ripard, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Chen-Yu Tsai
In-Reply-To: <20170329065717.D0AF37C1EFF-Y9/x5g2N/Tt0ykcd9G8QkxTxI0vvWBSX@public.gmane.org>
On Wed, 29 Mar 2017, Icenowy Zheng wrote:
>
> 2017年3月29日 14:54于 Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>写道：
> >
> > Hi,
> >
> > On 28/03/2017 19:30, Icenowy Zheng wrote:
> > > This adds support for the Allwinner H3 thermal sensor.
> > >
> > > Allwinner H3 has a thermal sensor like the one in A33, but have its
> > > registers nearly all re-arranged, sample clock moved to CCU and a pair
> > > of bus clock and reset added. It's also the base of newer SoCs' thermal
> > > sensors.
> > >
> > > An option is added to gpadc_data struct, to indicate whether this device
> > > is a new-generation Allwinner thermal sensor.
> > >
> > > The thermal sensors on A64 and H5 is like the one on H3, but with of
> > > course different formula factors.
> > >
> > > Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
> > > ---
> > > drivers/iio/adc/sun4i-gpadc-iio.c | 130 ++++++++++++++++++++++++++++++++------
> > > include/linux/mfd/sun4i-gpadc.h | 33 +++++++++-
> > > 2 files changed, 141 insertions(+), 22 deletions(-)
How have you managed to reply un-threaded?
Please ensure you mailer attaches your reply to the rest of the
thread, or things will become very confusing, very quickly.
> > > diff --git a/drivers/iio/adc/sun4i-gpadc-iio.c b/drivers/iio/adc/sun4i-gpadc-iio.c
> > > index 74705aa37982..7512b1cae877 100644
> > > --- a/drivers/iio/adc/sun4i-gpadc-iio.c
> > > +++ b/drivers/iio/adc/sun4i-gpadc-iio.c
> > > @@ -22,6 +22,7 @@
> > > * shutdown for not being used.
> > > */
> > >
> > > +#include <linux/clk.h>
> > > #include <linux/completion.h>
> > > #include <linux/interrupt.h>
> > > #include <linux/io.h>
> > > @@ -31,6 +32,7 @@
> > > #include <linux/platform_device.h>
> > > #include <linux/pm_runtime.h>
> > > #include <linux/regmap.h>
> > > +#include <linux/reset.h>
> > > #include <linux/thermal.h>
> > > #include <linux/delay.h>
> > >
> > > @@ -56,6 +58,7 @@ struct gpadc_data {
> > > unsigned int tp_adc_select;
> > > unsigned int (*adc_chan_select)(unsigned int chan);
> > > unsigned int adc_chan_mask;
> > > + bool gen2_ths;
> > > };
> > >
> >
> > Instead of a boolean, give the TEMP_DATA register address.
> >
> > > static const struct gpadc_data sun4i_gpadc_data = {
> > > @@ -88,7 +91,20 @@ static const struct gpadc_data sun6i_gpadc_data = {
> > > static const struct gpadc_data sun8i_a33_gpadc_data = {
> > > .temp_offset = -1662,
> > > .temp_scale = 162,
> > > - .tp_mode_en = SUN8I_GPADC_CTRL1_CHOP_TEMP_EN,
> > > + .tp_mode_en = SUN8I_A23_GPADC_CTRL1_CHOP_TEMP_EN,
> > > +};
> >
> > Separate patch for this?
> >
> > > +
> > > +static const struct gpadc_data sun8i_h3_gpadc_data = {
> > > + /*
> > > + * The original formula on the datasheet seems to be wrong.
> > > + * These factors are calculated based on the formula in the BSP
> > > + * kernel, which is originally Tem = 217 - (T / 8.253), in which Tem
> > > + * is the temperature in Celsius degree and T is the raw value
> > > + * from the sensor.
> > > + */
> > > + .temp_offset = -1791,
> > > + .temp_scale = -121,
> > > + .gen2_ths = true,
> > > };
> > >
> > > struct sun4i_gpadc_iio {
> > > @@ -103,6 +119,9 @@ struct sun4i_gpadc_iio {
> > > atomic_t ignore_temp_data_irq;
> > > const struct gpadc_data *data;
> > > bool no_irq;
> > > + struct clk *ths_bus_clk;
> > > + struct clk *ths_clk;
> > > + struct reset_control *reset;
> > > /* prevents concurrent reads of temperature and ADC */
> > > struct mutex mutex;
> > > };
> > > @@ -274,7 +293,11 @@ static int sun4i_gpadc_temp_read(struct iio_dev *indio_dev, int *val)
> > > if (info->no_irq) {
> > > pm_runtime_get_sync(indio_dev->dev.parent);
> > >
> > > - regmap_read(info->regmap, SUN4I_GPADC_TEMP_DATA, val);
> > > + if (info->data->gen2_ths)
> > > + regmap_read(info->regmap, SUN8I_H3_GPADC_TEMP_DATA,
> > > + val);
> > > + else
> > > + regmap_read(info->regmap, SUN4I_GPADC_TEMP_DATA, val);
> > >
> >
> > Instead of gen2_ths, use the TEMP_DATA register address.
> >
> > > pm_runtime_mark_last_busy(indio_dev->dev.parent);
> > > pm_runtime_put_autosuspend(indio_dev->dev.parent);
> > > @@ -386,10 +409,15 @@ static int sun4i_gpadc_runtime_suspend(struct device *dev)
> > > {
> > > struct sun4i_gpadc_iio *info = iio_priv(dev_get_drvdata(dev));
> > >
> > > - /* Disable the ADC on IP */
> > > - regmap_write(info->regmap, SUN4I_GPADC_CTRL1, 0);
> > > - /* Disable temperature sensor on IP */
> > > - regmap_write(info->regmap, SUN4I_GPADC_TPR, 0);
> > > + if (info->data->gen2_ths) {
> > > + /* Disable temperature sensor */
> > > + regmap_write(info->regmap, SUN8I_H3_GPADC_CTRL2, 0);
> > > + } else {
> > > + /* Disable the ADC on IP */
> > > + regmap_write(info->regmap, SUN4I_GPADC_CTRL1, 0);
> > > + /* Disable temperature sensor on IP */
> > > + regmap_write(info->regmap, SUN4I_GPADC_TPR, 0);
> > > + }
> > >
> >
> > Either use another register address or add a suspend function to struct
> > gpadc_data which will be different for each version of the IP.
> >
> > > return 0;
> > > }
> > > @@ -398,19 +426,36 @@ static int sun4i_gpadc_runtime_resume(struct device *dev)
> > > {
> > > struct sun4i_gpadc_iio *info = iio_priv(dev_get_drvdata(dev));
> > >
> > > - /* clkin = 6MHz */
> > > - regmap_write(info->regmap, SUN4I_GPADC_CTRL0,
> > > - SUN4I_GPADC_CTRL0_ADC_CLK_DIVIDER(2) |
> > > - SUN4I_GPADC_CTRL0_FS_DIV(7) |
> > > - SUN4I_GPADC_CTRL0_T_ACQ(63));
> > > - regmap_write(info->regmap, SUN4I_GPADC_CTRL1, info->data->tp_mode_en);
> > > - regmap_write(info->regmap, SUN4I_GPADC_CTRL3,
> > > - SUN4I_GPADC_CTRL3_FILTER_EN |
> > > - SUN4I_GPADC_CTRL3_FILTER_TYPE(1));
> > > - /* period = SUN4I_GPADC_TPR_TEMP_PERIOD * 256 * 16 / clkin; ~0.6s */
> > > - regmap_write(info->regmap, SUN4I_GPADC_TPR,
> > > - SUN4I_GPADC_TPR_TEMP_ENABLE |
> > > - SUN4I_GPADC_TPR_TEMP_PERIOD(800));
> > > + if (info->data->gen2_ths) {
> > > + regmap_write(info->regmap, SUN8I_H3_GPADC_CTRL2,
> > > + SUN8I_H3_GPADC_CTRL2_TEMP_SENSE_EN |
> > > + SUN8I_H3_GPADC_CTRL2_T_ACQ1(31));
> > > + regmap_write(info->regmap, SUN4I_GPADC_CTRL0,
> > > + SUN4I_GPADC_CTRL0_T_ACQ(31));
> > > + regmap_write(info->regmap, SUN8I_H3_GPADC_CTRL3,
> > > + SUN4I_GPADC_CTRL3_FILTER_EN |
> > > + SUN4I_GPADC_CTRL3_FILTER_TYPE(1));
> > > + regmap_write(info->regmap, SUN8I_H3_GPADC_INTC,
> > > + SUN8I_H3_GPADC_INTC_TEMP_PERIOD(800));
> > > + } else {
> > > + /* clkin = 6MHz */
> > > + regmap_write(info->regmap, SUN4I_GPADC_CTRL0,
> > > + SUN4I_GPADC_CTRL0_ADC_CLK_DIVIDER(2) |
> > > + SUN4I_GPADC_CTRL0_FS_DIV(7) |
> > > + SUN4I_GPADC_CTRL0_T_ACQ(63));
> > > + regmap_write(info->regmap, SUN4I_GPADC_CTRL1,
> > > + info->data->tp_mode_en);
> > > + regmap_write(info->regmap, SUN4I_GPADC_CTRL3,
> > > + SUN4I_GPADC_CTRL3_FILTER_EN |
> > > + SUN4I_GPADC_CTRL3_FILTER_TYPE(1));
> > > + /*
> > > + * period = SUN4I_GPADC_TPR_TEMP_PERIOD * 256 * 16 / clkin;
> > > + * ~0.6s
> > > + */
> > > + regmap_write(info->regmap, SUN4I_GPADC_TPR,
> > > + SUN4I_GPADC_TPR_TEMP_ENABLE |
> > > + SUN4I_GPADC_TPR_TEMP_PERIOD(800));
> > > + }
> > >
> >
> > Same here as suspend function?
> >
> > > return 0;
> > > }
> > > @@ -494,6 +539,10 @@ static const struct of_device_id sun4i_gpadc_of_id[] = {
> > > .compatible = "allwinner,sun8i-a33-ths",
> > > .data = &sun8i_a33_gpadc_data,
> > > },
> > > + {
> > > + .compatible = "allwinner,sun8i-h3-ths",
> > > + .data = &sun8i_h3_gpadc_data,
> > > + },
> > > { /* sentinel */ }
> > > };
> > >
> > > @@ -529,6 +578,43 @@ static int sun4i_gpadc_probe_dt(struct platform_device *pdev,
> > > return ret;
> > > }
> > >
> > > + if (info->data->gen2_ths) {
> > > + info->reset = devm_reset_control_get(&pdev->dev, NULL);
> > > + if (IS_ERR(info->reset)) {
> > > + ret = PTR_ERR(info->reset);
> > > + return ret;
> > > + }
> > > +
> > > + ret = reset_control_deassert(info->reset);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + info->ths_bus_clk = devm_clk_get(&pdev->dev, "bus");
> > > + if (IS_ERR(info->ths_bus_clk)) {
> > > + ret = PTR_ERR(info->ths_bus_clk);
> > > + return ret;
> > > + }
> > > +
> > > + ret = clk_prepare_enable(info->ths_bus_clk);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + info->ths_clk = devm_clk_get(&pdev->dev, "ths");
> > > + if (IS_ERR(info->ths_clk)) {
> > > + ret = PTR_ERR(info->ths_clk);
> > > + return ret;
> > > + }
> > > +
> > > + /* Running at 6MHz */
> > > + ret = clk_set_rate(info->ths_clk, 6000000);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + ret = clk_prepare_enable(info->ths_clk);
> > > + if (ret)
> > > + return ret;
> > > + }
> > > +
> > > if (!IS_ENABLED(CONFIG_THERMAL_OF))
> > > return 0;
> > >
> > > @@ -691,6 +777,12 @@ static int sun4i_gpadc_remove(struct platform_device *pdev)
> > > if (!info->no_irq && IS_ENABLED(CONFIG_THERMAL_OF))
> > > iio_map_array_unregister(indio_dev);
> > >
> > > + if (info->data->gen2_ths) {
> > > + clk_disable_unprepare(info->ths_clk);
> > > + clk_disable_unprepare(info->ths_bus_clk);
> > > + reset_control_deassert(info->reset);
> > > + }
> > > +
> >
> > I'm not really fond of using this boolean as I don't see it being
> > possibly reused for any other SoCs that has a GPADC or THS.
>
> Because you didn't care new SoCs :-)
>
> All SoCs after H3 (A64, H5, R40) uses the same THS architecture with H3.
>
> >
> > Here, you could make use of a list/array of clk which then can be reused
> > for other SoCs just by changing the list. Add a default rate to the
> > gpadc_data structure and you're go to go.
> >
> > > return 0;
> > > }
> > >
> > > diff --git a/include/linux/mfd/sun4i-gpadc.h b/include/linux/mfd/sun4i-gpadc.h
> > > index 139872c2e0fe..f794a2988a93 100644
> > > --- a/include/linux/mfd/sun4i-gpadc.h
> > > +++ b/include/linux/mfd/sun4i-gpadc.h
> > > @@ -38,9 +38,12 @@
> > > #define SUN6I_GPADC_CTRL1_ADC_CHAN_SELECT(x) (GENMASK(3, 0) & BIT(x))
> > > #define SUN6I_GPADC_CTRL1_ADC_CHAN_MASK GENMASK(3, 0)
> > >
> > > -/* TP_CTRL1 bits for sun8i SoCs */
> > > -#define SUN8I_GPADC_CTRL1_CHOP_TEMP_EN BIT(8)
> > > -#define SUN8I_GPADC_CTRL1_GPADC_CALI_EN BIT(7)
> > > +/* TP_CTRL1 bits for sun8i A23/A33 SoCs */
> > > +#define SUN8I_A23_GPADC_CTRL1_CHOP_TEMP_EN BIT(8)
> > > +#define SUN8I_A23_GPADC_CTRL1_GPADC_CALI_EN BIT(7)
> > > +
> >
> > Different patch for these?
> >
> > Thanks,
> > Quentin
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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] irqchip: mtk-cirq: Add mediatek mtk-cirq implement
From: Mars Cheng @ 2017-03-29 7:53 UTC (permalink / raw)
To: Marc Zyngier
Cc: Youlin Pei, Rob Herring, Matthias Brugger, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA,
hongkun.cao-NuS5LvNUpcJWk0Htik3J/w, Jason Cooper,
srv_heupstream-NuS5LvNUpcJWk0Htik3J/w,
erin.lo-NuS5LvNUpcJWk0Htik3J/w,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Russell King,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
yong.wu-NuS5LvNUpcJWk0Htik3J/w, Thomas Gleixner,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <499f9186-82c1-cb5a-91de-754c89bcdd3d-5wv7dgnIgG8@public.gmane.org>
Hi Marc
comments inline
On Fri, 2017-03-24 at 16:22 +0000, Marc Zyngier wrote:
> On 14/02/17 02:56, Youlin Pei wrote:
> > In Mediatek SOCs, the CIRQ is a low power interrupt controller
> > designed to works outside MCUSYS which comprises with Cortex-Ax
> > cores,CCI and GIC.
> >
> > The CIRQ controller is integrated in between MCUSYS( include
> > Cortex-Ax, CCI and GIC ) and interrupt sources as the second
> > level interrupt controller. The external interrupts which outside
> > MCUSYS will feed through CIRQ then bypass to GIC. CIRQ can monitors
> > all edge trigger interupts. When an edge interrupt is triggered,
> > CIRQ can record the status and generate a pulse signal to GIC when
> > flush command executed.
> >
> > When system enters sleep mode, MCUSYS will be turned off to improve
> > power consumption, also GIC is power down. The edge trigger interrupts
> > will be lost in this scenario without CIRQ.
> >
> > This commit provides the CIRQ irqchip implement.
> >
> > Signed-off-by: Youlin Pei <youlin.pei-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> > ---
> > drivers/irqchip/Makefile | 2 +-
> > drivers/irqchip/irq-mtk-cirq.c | 288 ++++++++++++++++++++++++++++++++++++++++
> > 2 files changed, 289 insertions(+), 1 deletion(-)
> > create mode 100644 drivers/irqchip/irq-mtk-cirq.c
> >
> > diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
> > index 0e55d94..db9acd1 100644
> > --- a/drivers/irqchip/Makefile
> > +++ b/drivers/irqchip/Makefile
> > @@ -61,7 +61,7 @@ obj-$(CONFIG_BCM7120_L2_IRQ) += irq-bcm7120-l2.o
> > obj-$(CONFIG_BRCMSTB_L2_IRQ) += irq-brcmstb-l2.o
> > obj-$(CONFIG_KEYSTONE_IRQ) += irq-keystone.o
> > obj-$(CONFIG_MIPS_GIC) += irq-mips-gic.o
> > -obj-$(CONFIG_ARCH_MEDIATEK) += irq-mtk-sysirq.o
> > +obj-$(CONFIG_ARCH_MEDIATEK) += irq-mtk-sysirq.o irq-mtk-cirq.o
> > obj-$(CONFIG_ARCH_DIGICOLOR) += irq-digicolor.o
> > obj-$(CONFIG_RENESAS_H8300H_INTC) += irq-renesas-h8300h.o
> > obj-$(CONFIG_RENESAS_H8S_INTC) += irq-renesas-h8s.o
> > diff --git a/drivers/irqchip/irq-mtk-cirq.c b/drivers/irqchip/irq-mtk-cirq.c
> > new file mode 100644
> > index 0000000..b5cf506
> > --- /dev/null
> > +++ b/drivers/irqchip/irq-mtk-cirq.c
> > @@ -0,0 +1,288 @@
> > +/*
> > + * Copyright (c) 2016 MediaTek Inc.
> > + * Author: Youlin.Pei <youlin.pei-NuS5LvNUpcJWk0Htik3J/w@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 version 2 as
> > + * published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#include <linux/interrupt.h>
> > +#include <linux/io.h>
> > +#include <linux/irq.h>
> > +#include <linux/irqchip.h>
> > +#include <linux/irqdomain.h>
> > +#include <linux/of.h>
> > +#include <linux/of_irq.h>
> > +#include <linux/of_address.h>
> > +#include <linux/slab.h>
> > +#include <linux/syscore_ops.h>
> > +
> > +#define CIRQ_ACK 0x40
> > +#define CIRQ_MASK_SET 0xc0
> > +#define CIRQ_MASK_CLR 0x100
> > +#define CIRQ_SENS_SET 0x180
> > +#define CIRQ_SENS_CLR 0x1c0
> > +#define CIRQ_POL_SET 0x240
> > +#define CIRQ_POL_CLR 0x280
> > +#define CIRQ_CONTROL 0x300
> > +
> > +#define CIRQ_EN 0x1
> > +#define CIRQ_EDGE 0x2
> > +#define CIRQ_FLUSH 0x4
> > +
> > +struct mtk_cirq_chip_data {
> > + void __iomem *base;
> > + unsigned int ext_irq_start;
> > + unsigned int ext_irq_end;
> > + struct irq_domain *domain;
> > +};
> > +
> > +static struct mtk_cirq_chip_data *cirq_data;
>
> Question in relation to the sysirq patches that have been queued for
> 4.12: Are we going to see something similar with this driver, where
> you're going to have to support multiple non-contiguous register sets?
> I'd rather have this kind of thing from day one, instead of adding that
> at a later time...
>
> Specially given that the platform that is using this driver does also
> have a sysirq controller.
sysirq is kind of special design which mediatek's HW guys put the bases
in a range with other misc usages. so sysirq might happen to have
several bases.
cirq is like other normal controller which has its own base and range.
We have all cirq design with single base.
Also asked our HW guys to allocate sysirq with single base as possible
in the future even they put it in misc address range.
Thanks.
>
> > +
> > +static void mtk_cirq_write_mask(struct irq_data *data, unsigned int offset)
> > +{
> > + struct mtk_cirq_chip_data *chip_data = data->chip_data;
> > + unsigned int cirq_num = data->hwirq;
> > + u32 mask = 1 << (cirq_num % 32);
> > +
> > + writel_relaxed(mask, chip_data->base + offset + (cirq_num / 32) * 4);
> > +}
> > +
> > +static void mtk_cirq_mask(struct irq_data *data)
> > +{
> > + mtk_cirq_write_mask(data, CIRQ_MASK_SET);
> > + irq_chip_mask_parent(data);
> > +}
> > +
> > +static void mtk_cirq_unmask(struct irq_data *data)
> > +{
> > + mtk_cirq_write_mask(data, CIRQ_MASK_CLR);
> > + irq_chip_unmask_parent(data);
> > +}
> > +
> > +static int mtk_cirq_set_type(struct irq_data *data, unsigned int type)
> > +{
> > + int ret;
> > +
> > + switch (type & IRQ_TYPE_SENSE_MASK) {
> > + case IRQ_TYPE_EDGE_FALLING:
> > + mtk_cirq_write_mask(data, CIRQ_POL_CLR);
> > + mtk_cirq_write_mask(data, CIRQ_SENS_CLR);
> > + break;
> > + case IRQ_TYPE_EDGE_RISING:
> > + mtk_cirq_write_mask(data, CIRQ_POL_SET);
> > + mtk_cirq_write_mask(data, CIRQ_SENS_CLR);
> > + break;
> > + case IRQ_TYPE_LEVEL_LOW:
> > + mtk_cirq_write_mask(data, CIRQ_POL_CLR);
> > + mtk_cirq_write_mask(data, CIRQ_SENS_SET);
> > + break;
> > + case IRQ_TYPE_LEVEL_HIGH:
> > + mtk_cirq_write_mask(data, CIRQ_POL_SET);
> > + mtk_cirq_write_mask(data, CIRQ_SENS_SET);
> > + break;
> > + default:
> > + break;
> > + }
> > +
> > + data = data->parent_data;
> > + ret = data->chip->irq_set_type(data, type);
> > + return ret;
> > +}
> > +
> > +static struct irq_chip mtk_cirq_chip = {
> > + .name = "MT_CIRQ",
> > + .irq_mask = mtk_cirq_mask,
> > + .irq_unmask = mtk_cirq_unmask,
> > + .irq_eoi = irq_chip_eoi_parent,
> > + .irq_set_type = mtk_cirq_set_type,
> > + .irq_retrigger = irq_chip_retrigger_hierarchy,
> > +#ifdef CONFIG_SMP
> > + .irq_set_affinity = irq_chip_set_affinity_parent,
> > +#endif
> > +};
> > +
> > +static int mtk_cirq_domain_translate(struct irq_domain *d,
> > + struct irq_fwspec *fwspec,
> > + unsigned long *hwirq,
> > + unsigned int *type)
> > +{
> > + if (is_of_node(fwspec->fwnode)) {
> > + if (fwspec->param_count != 3)
> > + return -EINVAL;
> > +
> > + /* No PPI should point to this domain */
> > + if (fwspec->param[0] != 0)
> > + return -EINVAL;
> > +
> > + /* cirq support irq number check */
> > + if (fwspec->param[1] < cirq_data->ext_irq_start ||
> > + fwspec->param[1] > cirq_data->ext_irq_end)
> > + return -EINVAL;
> > +
> > + *hwirq = fwspec->param[1] - cirq_data->ext_irq_start;
> > + *type = fwspec->param[2] & IRQ_TYPE_SENSE_MASK;
> > + return 0;
> > + }
> > +
> > + return -EINVAL;
> > +}
> > +
> > +static int mtk_cirq_domain_alloc(struct irq_domain *domain, unsigned int virq,
> > + unsigned int nr_irqs, void *arg)
> > +{
> > + int ret;
> > + irq_hw_number_t hwirq;
> > + unsigned int type;
> > + struct irq_fwspec *fwspec = arg;
> > + struct irq_fwspec parent_fwspec = *fwspec;
> > +
> > + ret = mtk_cirq_domain_translate(domain, fwspec, &hwirq, &type);
> > + if (ret)
> > + return ret;
> > +
> > + if (WARN_ON(nr_irqs != 1))
> > + return -EINVAL;
> > +
> > + irq_domain_set_hwirq_and_chip(domain, virq, hwirq,
> > + &mtk_cirq_chip,
> > + domain->host_data);
> > +
> > + parent_fwspec.fwnode = domain->parent->fwnode;
> > + return irq_domain_alloc_irqs_parent(domain, virq, nr_irqs,
> > + &parent_fwspec);
> > +}
> > +
> > +static const struct irq_domain_ops cirq_domain_ops = {
> > + .translate = mtk_cirq_domain_translate,
> > + .alloc = mtk_cirq_domain_alloc,
> > + .free = irq_domain_free_irqs_common,
> > +};
> > +
> > +#ifdef CONFIG_PM_SLEEP
> > +static int mtk_cirq_suspend(void)
> > +{
> > + u32 value, mask;
> > + unsigned int irq, hwirq_num;
> > + bool pending, masked;
> > + int i, pendret, maskret;
> > +
> > + hwirq_num = cirq_data->ext_irq_end - cirq_data->ext_irq_start + 1;
> > + for (i = 0; i < hwirq_num; i++) {
> > + irq = irq_find_mapping(cirq_data->domain, i);
> > + if (irq) {
> > + pendret = irq_get_irqchip_state(irq,
> > + IRQCHIP_STATE_PENDING,
> > + &pending);
> > +
> > + maskret = irq_get_irqchip_state(irq,
> > + IRQCHIP_STATE_MASKED,
> > + &masked);
> > +
> > + if (pendret == 0 && maskret == 0 &&
> > + (pending && !masked))
> > + continue;
> > + }
> > +
> > + mask = 1 << (i % 32);
> > + writel_relaxed(mask, cirq_data->base + CIRQ_ACK + (i / 32) * 4);
> > + }
>
> It would be worth documenting exactly what this is for. I had to go back
> to our previous discussion in November to remember it.
>
> > +
> > + /* set edge_only mode, record edge-triggerd interrupts */
> > + /* enable cirq */
> > + value = readl_relaxed(cirq_data->base + CIRQ_CONTROL);
> > + value |= (CIRQ_EDGE | CIRQ_EN);
> > + writel_relaxed(value, cirq_data->base + CIRQ_CONTROL);
> > +
> > + return 0;
> > +}
> > +
> > +static void mtk_cirq_resume(void)
> > +{
> > + u32 value;
> > +
> > + /* flush recored interrupts, will send signals to parent controller */
> > + value = readl_relaxed(cirq_data->base + CIRQ_CONTROL);
> > + writel_relaxed(value | CIRQ_FLUSH, cirq_data->base + CIRQ_CONTROL);
> > +
> > + /* disable cirq */
> > + value = readl_relaxed(cirq_data->base + CIRQ_CONTROL);
> > + value &= ~(CIRQ_EDGE | CIRQ_EN);
> > + writel_relaxed(value, cirq_data->base + CIRQ_CONTROL);
> > +}
> > +
> > +static struct syscore_ops mtk_cirq_syscore_ops = {
> > + .suspend = mtk_cirq_suspend,
> > + .resume = mtk_cirq_resume,
> > +};
> > +
> > +static void mtk_cirq_syscore_init(void)
> > +{
> > + register_syscore_ops(&mtk_cirq_syscore_ops);
> > +}
> > +#else
> > +static inline void mtk_cirq_syscore_init(void) {}
> > +#endif
> > +
> > +static int __init mtk_cirq_of_init(struct device_node *node,
> > + struct device_node *parent)
> > +{
> > + struct irq_domain *domain, *domain_parent;
> > + unsigned int irq_num;
> > + int ret;
> > +
> > + domain_parent = irq_find_host(parent);
> > + if (!domain_parent) {
> > + pr_err("mtk_cirq: interrupt-parent not found\n");
> > + return -EINVAL;
> > + }
> > +
> > + cirq_data = kzalloc(sizeof(*cirq_data), GFP_KERNEL);
> > + if (!cirq_data)
> > + return -ENOMEM;
> > +
> > + cirq_data->base = of_iomap(node, 0);
> > + if (!cirq_data->base) {
> > + pr_err("mtk_cirq: unable to map cirq register\n");
> > + ret = -ENXIO;
> > + goto out_free;
> > + }
> > +
> > + ret = of_property_read_u32_index(node, "mediatek,ext-irq-range", 0,
> > + &cirq_data->ext_irq_start);
> > + if (ret)
> > + goto out_unmap;
> > +
> > + ret = of_property_read_u32_index(node, "mediatek,ext-irq-range", 1,
> > + &cirq_data->ext_irq_end);
> > + if (ret)
> > + goto out_unmap;
> > +
> > + irq_num = cirq_data->ext_irq_end - cirq_data->ext_irq_start + 1;
> > + domain = irq_domain_add_hierarchy(domain_parent, 0,
> > + irq_num, node,
> > + &cirq_domain_ops, cirq_data);
> > + if (!domain) {
> > + ret = -ENOMEM;
> > + goto out_unmap;
> > + }
> > + cirq_data->domain = domain;
> > +
> > + mtk_cirq_syscore_init();
> > +
> > + return 0;
> > +
> > +out_unmap:
> > + iounmap(cirq_data->base);
> > +out_free:
> > + kfree(cirq_data);
> > + return ret;
> > +}
> > +
> > +IRQCHIP_DECLARE(mtk_cirq, "mediatek,mtk-cirq", mtk_cirq_of_init);
> >
>
> It otherwise looks much better than the previous iteration.
>
> Thanks,
>
> M.
--
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 v4 01/18] dt-bindings: power: battery: add constant-charge-current property
From: Liam Breck @ 2017-03-29 7:39 UTC (permalink / raw)
To: Quentin Schulz; +Cc: Sebastian Reichel, robh+dt, linux-pm, devicetree
In-Reply-To: <659fb6a3-d49d-5429-8770-88917e4fd0b3@free-electrons.com>
On Wed, Mar 29, 2017 at 12:09 AM, Quentin Schulz
<quentin.schulz@free-electrons.com> wrote:
> Hi Liam,
>
> On 29/03/2017 08:55, Liam Breck wrote:
>> Hi Quentin,
>>
>> On Thu, Mar 16, 2017 at 12:42 AM, Liam Breck <liam@networkimprov.net> wrote:
>>> On Thu, Mar 16, 2017 at 12:03 AM, Quentin Schulz
>>> <quentin.schulz@free-electrons.com> wrote:
>>>> Hi Liam,
>>>>
>>>> On 16/03/2017 07:27, Liam Breck wrote:
>>>>> Hi Rob,
>>>>>
>>>>> On Wed, Mar 15, 2017 at 6:10 AM, Quentin Schulz
>>>>> <quentin.schulz@free-electrons.com> wrote:
>>>>>> Hi Liam,
>>>>>>
>>>>>> On 15/03/2017 13:08, Liam Breck wrote:
>>>>>>> I dropped most of the CCs, pls re-add anyone essential. Use Cc lines
>>>>>>> in patch description to direct a patch to interested parties and
>>>>>>> relevant lists. I don't want to see all 19 patches in this series.
>>>>>>>
>>>>>>> On Wed, Mar 15, 2017 at 3:55 AM, Quentin Schulz
>>>>>>> <quentin.schulz@free-electrons.com> wrote:
>>>>>>>> This adds the constant-charge-current property to the list of optional
>>>>>>>> properties of the battery.
>>>>>>>>
>>>>>>>> The constant charge current is critical for batteries as they can't
>>>>>>>> handle all charge currents.
>>>>>>>>
>>>>>>>> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
>>>>>>>> Acked-by: Rob Herring <robh@kernel.org>
>>>>>>>> ---
>>>>>>>>
>>>>>>>> v4:
>>>>>>>> - switch from constant-charge-current-microamp to constant-charge-microamp,
>>>>>
>>>>> Sebastian is on record supporting name alignment between DT:battery
>>>>> properties and enum power_supply_property.
>>>>>
>>>>> Could you OK a change back to constant-charge-current-microamp in this patch?
>>>>>
>>>>> Note that the following could appear in DT:battery in future:
>>>>>
>>>>> constant-charge-current-microamp
>>>>> constant-charge-current-max-microamp
>>>>
>>>> OK. I am actually setting max constant charge current and constant
>>>> current charge with the same DT property so I might need to adapt my
>>>> patches.
>>>
>>> I suspect you should set battery:*-current-max with DT, as -current is
>>> "programmed by charger" so seems to be a stat, not a fixed
>>> characteristic.
>>
>> Did you resolve this issue?
>>
>
> Sorry, completely missed your first mail.
>
> Constant charge current is actually what I set in the PMIC. The maximum
> constant charge current is completely PMIC-agnostic in my driver as it
> is used to tell the user that (s)he shouldn't really have a constant
> charge current over the maximum limit as the battery might not be able
> to handle such high current.
>
> What I suggest is to have both properties in DT. I'll set the maximum as
> I do today and we can give the user the ability to set a "default"
> constant charge current (below maximum constant charge current) in the
> DT. Maybe we do not want to recharge your battery with the maximum value
> by default?
The scope here is just static battery characteristics. For the battery
node, I think constant-charge-current-max-microamp is the relevant
term. If we added both properties, one would be an alias for the
other, which doesn't seem useful.
The pmic can report both independently of the battery characteristic,
and take a driver-specific DT property for
constant-charge-current-microamp which it applies if less than the
battery's -max setting. Or you could set that in userspace via
/sys/class.../constant_charge_current. The charger's -max value would
be a characteristic of its regulator.
Or am I missing something...?
>> Rob & Sebastian want me to merge all items for
>> bindings/power/supply/battery.txt. If I do that I'll also roll up
>> their counterparts in power_supply_core.c and submit a patchset for
>> those two files.
>>
>
> I guess that adding the two properties make sense, don't you think?
>
> Also, could you Cc me on your next version of your patches? So I know
> when to rebase and slightly rework my patches once your patch series is
> merged.
Surely.
> Thanks,
> Quentin
>
>>> You may program your charger's -current with the battery's
>>> -current-max, of course.
>>>
>>> Note that your charger also has a -current-max characteristic, likely
>>> different than your battery. You may not need that in DT tho.
>>>
>>>>> constant-charge-voltage-microvolt
>>>>> constant-charge-voltage-max-microvolt
>>>>>
>>>>> Thanks!
>>>>>
>>>>>>> Must be constant-charge-current-microamp for the reasons discussed in
>>>>>>> battery.txt - consistency with sysfs names.
>>>>>>>
>>>>>>
>>>>>> Hum. Just nitpicking, but I disagree with the use of 'must'. IIRC there
>>>>>> is nothing in the code that would require the property to be named after
>>>>>> a property from the enum power_supply_property.
>>>>>>
>>>>>> I would say that you _want_ it to be named like that because it
>>>>>> underlines the relation between the DT property and the actual impacted
>>>>>> property in the power supply subsystem. I'm fine with this reason but in
>>>>>> the end, the maintainer's opinion prevails (if (s)he does not want it,
>>>>>> (s)he will not take it). So, basically, I actually don't mind either
>>>>>> option and I see arguments on each side.
>>>>>>
>>>>>> So, just waiting for maintainer's opinion to make the final version of
>>>>>> this patch.
>>>>>>
>>>>>> Thanks,
>>>>>> Quentin
>>>>>>
>>>>>>> Also applies to power_supply_core.c patch.
>>>>>>>
>>>>>>> Rob: enum power_supply_property also lists constant-charge-voltage,
>>>>>>> hence the -current
>>>>>>>
>>>>>>>
>>>>>>>> added in v3
>>>>>>>>
>>>>>>>> Documentation/devicetree/bindings/power/supply/battery.txt | 2 ++
>>>>>>>> 1 file changed, 2 insertions(+)
>>>>>>>>
>>>>>>>> diff --git a/Documentation/devicetree/bindings/power/supply/battery.txt b/Documentation/devicetree/bindings/power/supply/battery.txt
>>>>>>>> index 0278617..9594e1e 100644
>>>>>>>> --- a/Documentation/devicetree/bindings/power/supply/battery.txt
>>>>>>>> +++ b/Documentation/devicetree/bindings/power/supply/battery.txt
>>>>>>>> @@ -7,6 +7,7 @@ Optional Properties:
>>>>>>>> - voltage-min-design-microvolt: drained battery voltage
>>>>>>>> - energy-full-design-microwatt-hours: battery design energy
>>>>>>>> - charge-full-design-microamp-hours: battery design capacity
>>>>>>>> + - constant-charge-microamp: battery constant charge current
>>>>>>>>
>>>>>>>> Because drivers surface properties in sysfs using names derived
>>>>>>>> from enum power_supply_property, e.g.
>>>>>>>> @@ -30,6 +31,7 @@ Example:
>>>>>>>> voltage-min-design-microvolt = <3200000>;
>>>>>>>> energy-full-design-microwatt-hours = <5290000>;
>>>>>>>> charge-full-design-microamp-hours = <1430000>;
>>>>>>>> + constant-charge-microamp = <300000>;
>>>>>>>> };
>>>>>>>>
>>>>>>>> charger: charger@11 {
>>>>>>>> --
>>>>>>>> 2.9.3
>>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Quentin Schulz, Free Electrons
>>>>>> Embedded Linux and Kernel engineering
>>>>>> http://free-electrons.com
>>>>
>>>> --
>>>> Quentin Schulz, Free Electrons
>>>> Embedded Linux and Kernel engineering
>>>> http://free-electrons.com
>
> --
> Quentin Schulz, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
^ permalink raw reply
* Re: [PATCH v3 4/9] arm: remove wrong CONFIG_PROC_SYSCTL ifdef
From: Vincent Guittot @ 2017-03-29 7:39 UTC (permalink / raw)
To: Juri Lelli
Cc: linux-kernel, linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
LAK, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Peter Zijlstra, Rob Herring, Mark Rutland,
Russell King - ARM Linux, Sudeep Holla, Lorenzo Pieralisi,
Catalin Marinas, Will Deacon, Morten Rasmussen, Dietmar Eggemann,
Mark Brown,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org
In-Reply-To: <20170327131825.32134-5-juri.lelli-5wv7dgnIgG8@public.gmane.org>
On 27 March 2017 at 15:18, Juri Lelli <juri.lelli-5wv7dgnIgG8@public.gmane.org> wrote:
> The sysfs cpu_capacity entry for each CPU has nothing to do with
> PROC_FS, nor it's in /proc/sys path.
>
> Remove such ifdef.
>
> Cc: Russell King <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
> Reported-and-suggested-by: Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org>
> Fixes: 7e5930aaef5d ('ARM: 8622/3: add sysfs cpu_capacity attribute')
> Signed-off-by: Juri Lelli <juri.lelli-5wv7dgnIgG8@public.gmane.org>
Acked-by: Vincent Guittot <vincent.guittot-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> arch/arm/kernel/topology.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c
> index 4e4af809606a..162c82aeed96 100644
> --- a/arch/arm/kernel/topology.c
> +++ b/arch/arm/kernel/topology.c
> @@ -57,7 +57,6 @@ static void set_capacity_scale(unsigned int cpu, unsigned long capacity)
> per_cpu(cpu_scale, cpu) = capacity;
> }
>
> -#ifdef CONFIG_PROC_SYSCTL
> static ssize_t cpu_capacity_show(struct device *dev,
> struct device_attribute *attr,
> char *buf)
> @@ -114,7 +113,6 @@ static int register_cpu_capacity_sysctl(void)
> return 0;
> }
> subsys_initcall(register_cpu_capacity_sysctl);
> -#endif
>
> #ifdef CONFIG_OF
> struct cpu_efficiency {
> --
> 2.10.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
* Re: [PATCH v3 3/9] arm: fix return value of parse_cpu_capacity
From: Vincent Guittot @ 2017-03-29 7:37 UTC (permalink / raw)
To: Juri Lelli
Cc: linux-kernel, linux-pm@vger.kernel.org, LAK,
devicetree@vger.kernel.org, Peter Zijlstra, Rob Herring,
Mark Rutland, Russell King - ARM Linux, Sudeep Holla,
Lorenzo Pieralisi, Catalin Marinas, Will Deacon, Morten Rasmussen,
Dietmar Eggemann, Mark Brown, gregkh@linuxfoundation.org
In-Reply-To: <20170327131825.32134-4-juri.lelli@arm.com>
On 27 March 2017 at 15:18, Juri Lelli <juri.lelli@arm.com> wrote:
> parse_cpu_capacity() has to return 0 on failure, but it currently returns
> 1 instead if raw_capacity kcalloc failed.
>
> Fix it by removing the negation of the return value.
>
> Cc: Russell King <linux@arm.linux.org.uk>
> Reported-by: Morten Rasmussen <morten.rasmussen@arm.com>
> Fixes: 06073ee26775 ('ARM: 8621/3: parse cpu capacity-dmips-mhz from DT')
> Signed-off-by: Juri Lelli <juri.lelli@arm.com>
> ---
> arch/arm/kernel/topology.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c
> index f8a3ab82e77f..4e4af809606a 100644
> --- a/arch/arm/kernel/topology.c
> +++ b/arch/arm/kernel/topology.c
> @@ -166,7 +166,7 @@ static int __init parse_cpu_capacity(struct device_node *cpu_node, int cpu)
> if (!raw_capacity) {
> pr_err("cpu_capacity: failed to allocate memory for raw capacities\n");
> cap_parsing_failed = true;
> - return !ret;
> + return ret;
Why not directly returning 0 ? whatever the value of ret, the parse of
cpu capacity has failed in this case
> }
> }
> capacity_scale = max(cpu_capacity, capacity_scale);
> --
> 2.10.0
>
^ permalink raw reply
* Re: [PATCH v2 2/7] dt-bindings: pinctrl: Add RZ/A1 bindings doc
From: Geert Uytterhoeven @ 2017-03-29 7:35 UTC (permalink / raw)
To: Linus Walleij
Cc: jacopo, Jacopo Mondi, Geert Uytterhoeven, Laurent Pinchart,
Chris Brandt, Rob Herring, Mark Rutland, Russell King,
Linux-Renesas, linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <CACRpkdbZS72xkHaM5P-Zw==A_V_BxeszLPmc0_Zy0-RRjvAbNA@mail.gmail.com>
Hi Linus,
On Wed, Mar 29, 2017 at 4:30 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Tue, Mar 28, 2017 at 4:38 PM, <jacopo@jmondi.org> wrote:
>>> The fact that historically all the early adopters of pinctrl in device
>>> tree
>>> have these funky custom bindings is unfortunate but just something
>>> that we need to live with.
>>
>> To avoid any confusion, please bear with me and clarify this once and for
>> all,
>> since I'm not certain I fully got you here.
>>
>> Are you suggesting:
>>
>> 1) Use "pins" property with the currently implemented ABI (which slightly
>> differs
>> from the standard documented one as explained above. Not sure it is fine
>> overriding
>> it or not)
>
> Correction: you should be using the property "pinmux", because you
> are setting group and function at the same time.
OK.
> See for example:
> include/dt-bindings/pinctrl/mt65xx.h
>
> And how that is used in:
> arch/arm/boot/dts/mt2701-pinfunc.h
> arch/arm/boot/dts/mt2701-evb.dts
>
> The docs are here:
> Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt
All of the above pack the information for a pin into a single 32-bit integer.
Is that what you want us to use, too?
Currently we use two integers: 1) pin index, and 2) function/flags combo.
> I'm sorry that "pinmux" is not part of the generic documentation, it'd be
> great if you would like to add it with a patch.
That would mean pinmux could be an array of single values, or tuples.
Is that OK?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v3 1/7] pinctrl: Renesas RZ/A1 pin and gpio controller
From: Geert Uytterhoeven @ 2017-03-29 7:30 UTC (permalink / raw)
To: Linus Walleij
Cc: Jacopo Mondi, Geert Uytterhoeven, Laurent Pinchart, Chris Brandt,
Rob Herring, Mark Rutland, Russell King, Linux-Renesas,
linux-gpio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <CACRpkdYjZJ7e0tJy6_jfpRT+UDFWqnu8ZX18-gaAHVZLgW-prA@mail.gmail.com>
Hi Linus,
On Fri, Mar 24, 2017 at 4:42 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Fri, Mar 24, 2017 at 4:22 PM, Jacopo Mondi <jacopo+renesas@jmondi.org> wrote:
>
> I assume Geert will queue this driver even if it is outside of sh-pfc?
OK for me, thanks. I was actually wondering about that ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v8 1/3] Input: max11801_ts: Add missing of_match_table
From: Dmitry Torokhov @ 2017-03-29 7:26 UTC (permalink / raw)
To: Jagan Teki
Cc: linux-input, linux-arm-kernel, devicetree, linux-kernel,
Jagan Teki, Shawn Guo, Matteo Lisi, Michael Trimarchi
In-Reply-To: <1490209518-20790-1-git-send-email-jagan@openedev.com>
On Thu, Mar 23, 2017 at 12:35:16AM +0530, Jagan Teki wrote:
> From: Jagan Teki <jagan@amarulasolutions.com>
>
> Added missing of_match_table for max11801_ts driver with
> compatible as "maxim,max11801_ts"
>
> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Matteo Lisi <matteo.lisi@engicam.com>
> Cc: Michael Trimarchi <michael@amarulasolutions.com>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Applied, thank you.
> ---
> Changes for v8:
> - use the compatible as maxim,max11801 with remove suffix _ts since
> i2c node follow the same.
> Changes for v7:
> - newly added patch
>
> drivers/input/touchscreen/max11801_ts.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/input/touchscreen/max11801_ts.c b/drivers/input/touchscreen/max11801_ts.c
> index a595ae5..d3c7fc0 100644
> --- a/drivers/input/touchscreen/max11801_ts.c
> +++ b/drivers/input/touchscreen/max11801_ts.c
> @@ -224,9 +224,16 @@ static int max11801_ts_probe(struct i2c_client *client,
> };
> MODULE_DEVICE_TABLE(i2c, max11801_ts_id);
>
> +static const struct of_device_id max11801_ts_dt_ids[] = {
> + { .compatible = "maxim,max11801" },
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, max11801_ts_dt_ids);
> +
> static struct i2c_driver max11801_ts_driver = {
> .driver = {
> .name = "max11801_ts",
> + .of_match_table = max11801_ts_dt_ids,
> },
> .id_table = max11801_ts_id,
> .probe = max11801_ts_probe,
> --
> 1.9.1
>
--
Dmitry
^ permalink raw reply
* Re: [PATCH v8 2/3] dt-bindings: input: touchscreen: Add max11801-ts binding
From: Dmitry Torokhov @ 2017-03-29 7:26 UTC (permalink / raw)
To: Rob Herring
Cc: Jagan Teki, linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Jagan Teki, Mark Rutland,
Shawn Guo, Michael Trimarchi
In-Reply-To: <20170329015755.zi77exu7tpne3g3n@rob-hp-laptop>
On Tue, Mar 28, 2017 at 08:57:55PM -0500, Rob Herring wrote:
> On Thu, Mar 23, 2017 at 12:35:17AM +0530, Jagan Teki wrote:
> > From: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
> >
> > Add missing documentation of max11801-ts dt-binding details.
> >
> > Cc: Dmitry Torokhov <dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
> > Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> > Cc: Shawn Guo <shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> > Cc: Michael Trimarchi <michael-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
> > Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
> > ---
> > Changes for v8:
> > - Use IRQ_TYPE_EDGE_FALLING for interrupt trigger type.
> > Changes for v7:
> > - add vendor prefix as maxim
> > Changes for v6:
> > - Replace the lable and name of the node
> > ts: max11801 => max11801: touchscreen@48
> > Changes for v5:
> > - Newly added patch
> >
> > .../bindings/input/touchscreen/max11801-ts.txt | 18 ++++++++++++++++++
> > 1 file changed, 18 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/input/touchscreen/max11801-ts.txt
>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Applied, thank you.
--
Dmitry
--
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] ARM: dts: sun5i: Add interrupt for display backend
From: Chen-Yu Tsai @ 2017-03-29 7:26 UTC (permalink / raw)
To: Maxime Ripard
Cc: Chen-Yu Tsai, David Airlie, Rob Herring, Mark Rutland, dri-devel,
devicetree, linux-arm-kernel, linux-kernel, linux-sunxi
In-Reply-To: <20170329071303.ft7oukmhczihy2xb@lukather>
On Wed, Mar 29, 2017 at 3:13 PM, Maxime Ripard
<maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> On Mon, Mar 27, 2017 at 10:38:47PM +0800, Chen-Yu Tsai wrote:
>> The display backend on sun5i shares the same interrupt line as the
>> display frontend. Add it.
>>
>> Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
>
> And ideally, patches prefix shouldn't have dts here too. I've dropped
> it and applied, thanks!
Seems like this was a recent policy change? Or almost everyone was getting
it wrong in the past.
>> This won't directly apply to old releases. We may want to backport
>> them though?
>
> Yep, probably. Do you want to send it to stable?
It won't apply, due to the recent sun5i merger. We could wait until
it lands in Linus' tree, then send a backport patch to stable, to
keep the noise to a minimum.
ChenYu
^ 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