* Re: [PATCH RESEND v6 0/6] provide power off support for iMX6 with external PMIC
From: Shawn Guo @ 2017-12-21 8:12 UTC (permalink / raw)
To: Mark Brown
Cc: Oleksij Rempel, Linus Torvalds, Rob Herring, Mark Rutland,
Michael Turquette, Stephen Boyd, Fabio Estevam, Russell King,
kernel, devicetree, linux-arm-kernel, linux-clk, linux-kernel,
Andrew Morton, Liam Girdwood, Leonard Crestez
In-Reply-To: <20171206184844.uqbu6rmj4bponpuw@sirena.org.uk>
On Wed, Dec 06, 2017 at 06:48:44PM +0000, Mark Brown wrote:
> On Wed, Dec 06, 2017 at 08:23:56AM +0100, Oleksij Rempel wrote:
> > 2017.12.06:
> > Adding Linus. Probably there is no maintainer for this patch set.
> > No changes are made, tested on v4.15-rc1.
>
> Have any of the i.MX maintainers said anything about this? I was about
> to reply to this asking if they were ever going to review it as it keeps
> on getting resent but I'm not seeing any interest from any of them but
> the main immediate audience is i.MX systems.
I will be happy to take the dts changes, after kernel/reboot and
regulator get accepted (ideally landed on mainline).
Shawn
^ permalink raw reply
* RE: [PATCH][v3] dt-bindings: ifc: Update endianness usage
From: Prabhakar Kushwaha @ 2017-12-21 8:09 UTC (permalink / raw)
To: Prabhakar Kushwaha, Rob Herring
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
mark.rutland-5wv7dgnIgG8@public.gmane.org,
shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <HE1PR04MB12413F48FF7E083FD8E0FD36973D0-6LN7OEpIatU9TB6uw0n1oM9NdZoXdze2vxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
Hi Rob,
> -----Original Message-----
> From: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org [mailto:devicetree-
> owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org] On Behalf Of Prabhakar Kushwaha
> Sent: Tuesday, December 05, 2017 2:45 PM
> To: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; mark.rutland-5wv7dgnIgG8@public.gmane.org;
> shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org; linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> Subject: RE: [PATCH][v3] dt-bindings: ifc: Update endianness usage
>
>
> > -----Original Message-----
> > From: Rob Herring [mailto:robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org]
> > Sent: Tuesday, December 05, 2017 2:17 AM
> > To: Prabhakar Kushwaha <prabhakar.kushwaha-3arQi8VN3Tc@public.gmane.org>
> > Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; mark.rutland-5wv7dgnIgG8@public.gmane.org;
> > shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org; linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> > Subject: Re: [PATCH][v3] dt-bindings: ifc: Update endianness usage
> >
> > On Thu, Nov 30, 2017 at 01:36:36PM +0530, Prabhakar Kushwaha wrote:
> > > IFC controller version < 2.0 support IFC register access as
> > > big endian. These controller version also require IFC NOR signals to
> > > be connected in reverse order with NOR flash.
> > >
> > > IFC >= 2.0 is other way around.
> > >
> > > So updating IFC binding to take care of both using endianness field.
> > >
> > > Signed-off-by: Prabhakar Kushwaha <prabhakar.kushwaha-3arQi8VN3Tc@public.gmane.org>
> > > ---
> > > Changes for v2: updated subject
> > > Changes for v3: fixed typo for "big-endian"
> > >
> > > Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt | 6
> ++++--
> > > 1 file changed, 4 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/memory-
> controllers/fsl/ifc.txt
> > b/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt
> > > index 89427b0..824a2ca 100644
> > > --- a/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt
> > > +++ b/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt
> > > @@ -18,8 +18,10 @@ Properties:
> > > interrupt (NAND_EVTER_STAT). If there is only one,
> > > that interrupt reports both types of event.
> > >
> > > -- little-endian : If this property is absent, the big-endian mode will
> > > - be in use as default for registers.
> > > +- little-endian or big-endian : It represents how IFC registers to be accessed.
> > > + It also represents connection between controller and
> > > + NOR flash. If this property is absent, the big-endian
> > > + mode will be in use as default.
> >
> > My question on the prior version remains. I think if you need to handle
> > more than just register endianness, that should be done with the
> > compatible string.
> >
>
> I may not able to use compatible string as this information will also be used it
> drivers/mtd/maps/physmap_of_core.c other than drivers/memory/fsl_ifc.c.
> I am trying to avoid controller specific details in generic file.
>
> This is the reason endianness property is being used.
>
Please let me know if I am not able to address your review comment
--prabhakar
--
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: imx: Add memory node unit name
From: Lothar Waßmann @ 2017-12-21 8:07 UTC (permalink / raw)
To: Marco Franchi
Cc: shawnguo, devicetree, linux-kernel, robh+dt, festevam,
linux-arm-kernel
In-Reply-To: <1512575989-15627-1-git-send-email-marcofrk@gmail.com>
Hi,
On Wed, 6 Dec 2017 13:59:49 -0200 Marco Franchi wrote:
> Fix the following warnings from dtc by adding the unit name to memory
> nodes:
>
> Warning (unit_address_vs_reg): Node /memory has a reg or ranges property, but no unit name
>
> Converted using the following command:
>
> perl -p0777i -e 's/memory \{\n\t\treg = \<0x+([0-9a-f])/memory\@$1$\0000000 \{\n\t\treg = <0x$1/m' `find ./arch/arm/boot/dts -name "imx*"`
>
> The files below were manually fixed:
> -imx1-ads.dts
> -imx1-apf9328.dts
>
The imx*.dtsi files all have this:
| memory { device_type = "memory"; reg = <0 0>; };
Thus you will end up with a 'memory' node with a reg = <0 0> entry and
an additional 'memory@...' node with the correct 'reg' values.
Lothar Waßmann
^ permalink raw reply
* Re: [PATCH resend] arm: dts: ls1021a: Specify interrupt-affinity for pmu node
From: Shawn Guo @ 2017-12-21 8:06 UTC (permalink / raw)
To: Rasmus Villemoes
Cc: Rob Herring, Mark Rutland, Russell King, Esben Haabendal,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1512462145-12664-1-git-send-email-rasmus.villemoes-rjjw5hvvQKZaa/9Udqfwiw@public.gmane.org>
On Tue, Dec 05, 2017 at 09:22:25AM +0100, Rasmus Villemoes wrote:
> From: Esben Haabendal <eha-/iRVSOupHO4@public.gmane.org>
>
> From: Esben Haabendal <eha-/iRVSOupHO4@public.gmane.org>
Dropped the extra From line, fixed prefix and applied patch.
Shawn
>
> This avoids the warning
>
> hw perfevents: no interrupt-affinity property for /pmu, guessing.
>
> Signed-off-by: Esben Haabendal <eha-/iRVSOupHO4@public.gmane.org>
> [RV: adapt commit log to the warning emitted in current mainline]
> Signed-off-by: Rasmus Villemoes <rasmus.villemoes-rjjw5hvvQKZaa/9Udqfwiw@public.gmane.org>
> ---
> arch/arm/boot/dts/ls1021a.dtsi | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
> index 02a266faec9b..96dc1a29fc64 100644
> --- a/arch/arm/boot/dts/ls1021a.dtsi
> +++ b/arch/arm/boot/dts/ls1021a.dtsi
> @@ -106,6 +106,7 @@
> compatible = "arm,cortex-a7-pmu";
> interrupts = <GIC_SPI 138 IRQ_TYPE_LEVEL_HIGH>,
> <GIC_SPI 139 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-affinity = <&cpu0>, <&cpu1>;
> };
>
> reboot {
> --
> 2.7.4
>
--
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 resend] arm: dts: ls1021a: Add label to USB controllers
From: Shawn Guo @ 2017-12-21 8:06 UTC (permalink / raw)
To: Rasmus Villemoes
Cc: Rob Herring, Mark Rutland, Russell King, Esben Haabendal,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1512461794-12309-1-git-send-email-rasmus.villemoes-rjjw5hvvQKZaa/9Udqfwiw@public.gmane.org>
On Tue, Dec 05, 2017 at 09:16:33AM +0100, Rasmus Villemoes wrote:
> From: Esben Haabendal <eha-/iRVSOupHO4@public.gmane.org>
>
> Add usb2 and usb3 labels to USB2 and USB3 controller device tree nodes,
> for easier modification in board dts files.
>
> Signed-off-by: Esben Haabendal <eha-/iRVSOupHO4@public.gmane.org>
> Signed-off-by: Rasmus Villemoes <rasmus.villemoes-rjjw5hvvQKZaa/9Udqfwiw@public.gmane.org>
Fixed prefix and applied the patch.
Shawn
--
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 resend] arm: dts: ls1021a: add reboot node to .dtsi
From: Shawn Guo @ 2017-12-21 8:05 UTC (permalink / raw)
To: Rasmus Villemoes
Cc: Rob Herring, Mark Rutland, Russell King,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1512461568-12102-1-git-send-email-rasmus.villemoes-rjjw5hvvQKZaa/9Udqfwiw@public.gmane.org>
On Tue, Dec 05, 2017 at 09:12:47AM +0100, Rasmus Villemoes wrote:
> The LS1021A can be reset via the dcfg regmap in the same way as the
> arm64 layerscape SoCs, so add the corresponding DT node.
>
> Signed-off-by: Rasmus Villemoes <rasmus.villemoes-rjjw5hvvQKZaa/9Udqfwiw@public.gmane.org>
We use "ARM: ..." instead of "arm: ..." as prefix for DTS patches going
through i.MX tree.
I fixed prefix up and applied the patch.
Shawn
--
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/4] ARM: dts: split trats2 DTS in preparation for midas boards
From: Krzysztof Kozlowski @ 2017-12-21 7:57 UTC (permalink / raw)
To: Simon Shields
Cc: Rob Herring, linux-samsung-soc, Kukjin Kim, devicetree,
Marek Szyprowski, Bartłomiej Żołnierkiewicz
In-Reply-To: <20171221015415.GB23568@lineageos.org>
On Thu, Dec 21, 2017 at 2:54 AM, Simon Shields <simon@lineageos.org> wrote:
> Hi Rob,
>
> On Wed, Dec 20, 2017 at 12:19:08PM -0600, Rob Herring wrote:
>> On Wed, Dec 20, 2017 at 03:05:18PM +0100, Krzysztof Kozlowski wrote:
>> > On Mon, Dec 18, 2017 at 1:38 PM, Simon Shields <simon@lineageos.org> wrote:
>> > > The midas boards share a lot with trats2. Split the common parts
>> > > out of trats2 into a common midas dtsi and a common "galaxy s3" dts.
>> > >
>> > > Signed-off-by: Simon Shields <simon@lineageos.org>
>> > > ---
>> > > arch/arm/boot/dts/exynos4412-galaxy-s3.dtsi | 145 ++
>> > > ...exynos4412-trats2.dts => exynos4412-midas.dtsi} | 117 +-
>> > > arch/arm/boot/dts/exynos4412-trats2.dts | 1446 +-------------------
>> > > 3 files changed, 184 insertions(+), 1524 deletions(-)
>> > > create mode 100644 arch/arm/boot/dts/exynos4412-galaxy-s3.dtsi
>> > > copy arch/arm/boot/dts/{exynos4412-trats2.dts => exynos4412-midas.dtsi} (92%)
>> > > rewrite arch/arm/boot/dts/exynos4412-trats2.dts (97%)
>> > >
>> > > diff --git a/arch/arm/boot/dts/exynos4412-galaxy-s3.dtsi b/arch/arm/boot/dts/exynos4412-galaxy-s3.dtsi
>> > > new file mode 100644
>> > > index 000000000000..2806236484a6
>> > > --- /dev/null
>> > > +++ b/arch/arm/boot/dts/exynos4412-galaxy-s3.dtsi
>> > > @@ -0,0 +1,145 @@
>> > > +/*
>> > > + * Samsung's Exynos4412 based Galaxy S3 board device tree source
>> > > + *
>> > > + * Copyright (c) 2013 Samsung Electronics Co., Ltd.
>> > > + * http://www.samsung.com
>> > > + *
>> > > + * Device tree source file for Samsung's Galaxy S3 boards which are based on
>> > > + * Samsung's Exynos4412 SoC.
>> > > + *
>> > > + * 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.
>> > > + */
>> >
>> > One new line to make it consistent with others.
>>
>> If you're going to change it, use an SPDX tag.
>>
>
> I initially did this in v2[1], but Krzysztof said to keep
> the trats2 copyright header, since the galaxy-s3 dts is a
> subset of the old trats2 DTS. Is adding the SPDX tag and
> keeping the Samsung copyright stanza the preferred approach
> here?
>
> [1]: https://patchwork.kernel.org/patch/10111971/
>> Rob
Yes, but I was referring only to copyright header. The SPDX tag
replaces the license, not the copyright.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/2][v2] ARM: dts: Add big-endian for IFC on LS1021A
From: Shawn Guo @ 2017-12-21 7:32 UTC (permalink / raw)
To: Prabhakar Kushwaha
Cc: mark.rutland-5wv7dgnIgG8@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, Alison Wang,
Jagdish Gediya,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <HE1PR04MB1241243DE5FE86833DD0B509970D0-6LN7OEpIatU9TB6uw0n1oM9NdZoXdze2vxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
On Thu, Dec 21, 2017 at 07:19:12AM +0000, Prabhakar Kushwaha wrote:
> Are you referring to this discussion https://patchwork.ozlabs.org/patch/842543/?
> Due to which binding are not ACK-ed.
Hmm, I'm talking about Rob's comment below.
https://www.spinics.net/lists/arm-kernel/msg620518.html
In any case, I cannot apply the dts change before the bindings part gets
ACK-ed by DT maintainer.
Shawn
--
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][v2] ARM: dts: Add big-endian for IFC on LS1021A
From: Prabhakar Kushwaha @ 2017-12-21 7:19 UTC (permalink / raw)
To: Shawn Guo
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
mark.rutland-5wv7dgnIgG8@public.gmane.org, Alison Wang,
Jagdish Gediya,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <20171221071056.GF3766@dragon>
Hi Shawn,
> -----Original Message-----
> From: Shawn Guo [mailto:shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org]
> Sent: Thursday, December 21, 2017 12:41 PM
> To: Prabhakar Kushwaha <prabhakar.kushwaha-3arQi8VN3Tc@public.gmane.org>
> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org; mark.rutland-5wv7dgnIgG8@public.gmane.org;
> Alison Wang <alison.wang-3arQi8VN3Tc@public.gmane.org>; Jagdish Gediya
> <jagdish.gediya-3arQi8VN3Tc@public.gmane.org>; linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> Subject: Re: [PATCH 1/2][v2] ARM: dts: Add big-endian for IFC on LS1021A
>
> On Thu, Dec 21, 2017 at 05:14:36AM +0000, Prabhakar Kushwaha wrote:
> > Hi Shawn,
> >
> > > -----Original Message-----
> > > From: Prabhakar Kushwaha [mailto:prabhakar.kushwaha-3arQi8VN3Tc@public.gmane.org]
> > > Sent: Thursday, November 30, 2017 9:12 AM
> > > To: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org; mark.rutland-5wv7dgnIgG8@public.gmane.org;
> > > shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org
> > > Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; Jagdish Gediya
> > > <jagdish.gediya-3arQi8VN3Tc@public.gmane.org>; Alison Wang <alison.wang-3arQi8VN3Tc@public.gmane.org>;
> Prabhakar
> > > Kushwaha <prabhakar.kushwaha-3arQi8VN3Tc@public.gmane.org>
> > > Subject: [PATCH 1/2][v2] ARM: dts: Add big-endian for IFC on LS1021A
> > >
> > > From: Jagdish Gediya <jagdish.gediya-3arQi8VN3Tc@public.gmane.org>
> > >
> > > For the patch to update struct map_info's swap field based on device
> > > characteristics defined in device tree, big-endian parameter is added
> > > for LS1021A.
> > >
> > > Signed-off-by: Alison Wang <alison.wang-3arQi8VN3Tc@public.gmane.org>
> > > Signed-off-by: Jagdish Gediya <jagdish.gediya-3arQi8VN3Tc@public.gmane.org>
> > > Signed-off-by: Prabhakar Kushwaha <prabhakar.kushwaha-3arQi8VN3Tc@public.gmane.org>
> > > ---
> > > Changes for v2: updated subject
> > >
> > > arch/arm/boot/dts/ls1021a.dtsi | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
> > > index 9319e1f..babb086 100644
> > > --- a/arch/arm/boot/dts/ls1021a.dtsi
> > > +++ b/arch/arm/boot/dts/ls1021a.dtsi
> > > @@ -145,6 +145,7 @@
> > > ifc: ifc@1530000 {
> > > compatible = "fsl,ifc", "simple-bus";
> > > reg = <0x0 0x1530000 0x0 0x10000>;
> > > + big-endian;
> > > interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>;
> > > };
> > >
> > > --
> > > 1.9.1
> >
> > There are no review comments on this patch.
> >
> > Can you please accept this patch
>
> It seems that the bindings hasn't been ACK-ed by DT maintainer.
>
Are you referring to this discussion https://patchwork.ozlabs.org/patch/842543/?
Due to which binding are not ACK-ed.
--pk
--
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][v2] ARM: dts: ls1021aqds: Add nand node for ifc controller
From: Shawn Guo @ 2017-12-21 7:14 UTC (permalink / raw)
To: Prabhakar Kushwaha
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, robh-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Jagdish Gediya
In-Reply-To: <1512013344-4042-3-git-send-email-prabhakar.kushwaha-3arQi8VN3Tc@public.gmane.org>
On Thu, Nov 30, 2017 at 09:12:24AM +0530, Prabhakar Kushwaha wrote:
> LS1021AQDS support NAND flash on IFC chip-select 2.
>
> So add NAND node in device tree for IFC controller.
>
> Signed-off-by: Jagdish Gediya <jagdish.gediya-3arQi8VN3Tc@public.gmane.org>
> Signed-off-by: Prabhakar Kushwaha <prabhakar.kushwaha-3arQi8VN3Tc@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 1/2][v2] ARM: dts: Add big-endian for IFC on LS1021A
From: Shawn Guo @ 2017-12-21 7:10 UTC (permalink / raw)
To: Prabhakar Kushwaha
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
mark.rutland-5wv7dgnIgG8@public.gmane.org, Alison Wang,
Jagdish Gediya,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <HE1PR04MB1241E7538E97597B76606FF4970D0-6LN7OEpIatU9TB6uw0n1oM9NdZoXdze2vxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
On Thu, Dec 21, 2017 at 05:14:36AM +0000, Prabhakar Kushwaha wrote:
> Hi Shawn,
>
> > -----Original Message-----
> > From: Prabhakar Kushwaha [mailto:prabhakar.kushwaha-3arQi8VN3Tc@public.gmane.org]
> > Sent: Thursday, November 30, 2017 9:12 AM
> > To: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org; mark.rutland-5wv7dgnIgG8@public.gmane.org;
> > shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org
> > Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; Jagdish Gediya
> > <jagdish.gediya-3arQi8VN3Tc@public.gmane.org>; Alison Wang <alison.wang-3arQi8VN3Tc@public.gmane.org>; Prabhakar
> > Kushwaha <prabhakar.kushwaha-3arQi8VN3Tc@public.gmane.org>
> > Subject: [PATCH 1/2][v2] ARM: dts: Add big-endian for IFC on LS1021A
> >
> > From: Jagdish Gediya <jagdish.gediya-3arQi8VN3Tc@public.gmane.org>
> >
> > For the patch to update struct map_info's swap field based on device
> > characteristics defined in device tree, big-endian parameter is added
> > for LS1021A.
> >
> > Signed-off-by: Alison Wang <alison.wang-3arQi8VN3Tc@public.gmane.org>
> > Signed-off-by: Jagdish Gediya <jagdish.gediya-3arQi8VN3Tc@public.gmane.org>
> > Signed-off-by: Prabhakar Kushwaha <prabhakar.kushwaha-3arQi8VN3Tc@public.gmane.org>
> > ---
> > Changes for v2: updated subject
> >
> > arch/arm/boot/dts/ls1021a.dtsi | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
> > index 9319e1f..babb086 100644
> > --- a/arch/arm/boot/dts/ls1021a.dtsi
> > +++ b/arch/arm/boot/dts/ls1021a.dtsi
> > @@ -145,6 +145,7 @@
> > ifc: ifc@1530000 {
> > compatible = "fsl,ifc", "simple-bus";
> > reg = <0x0 0x1530000 0x0 0x10000>;
> > + big-endian;
> > interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>;
> > };
> >
> > --
> > 1.9.1
>
> There are no review comments on this patch.
>
> Can you please accept this patch
It seems that the bindings hasn't been ACK-ed by DT maintainer.
Shawn
--
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/4] dma: fsl-qdma: add devicetree documentation for qDMA driver.
From: Wen He @ 2017-12-21 7:09 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Jiafei Pan,
Jiaheng Fan
In-Reply-To: <20171220184304.ywr3nopucgubgxwz@rob-hp-laptop>
Hi Rob,
> -----Original Message-----
> From: Rob Herring [mailto:robh@kernel.org]
> Sent: 2017年12月21日 2:43
> To: Wen He <wen.he_1@nxp.com>
> Cc: devicetree@vger.kernel.org
> Subject: Re: [PATCH 2/4] dma: fsl-qdma: add devicetree documentation for
> qDMA driver.
>
> On Tue, Dec 19, 2017 at 02:41:57PM +0800, Wen He wrote:
>
> Need a commit message.
>
Got it, Thanks.
> > Signed-off-by: Wen He <wen.he_1@nxp.com>
> > ---
> > Documentation/devicetree/bindings/dma/fsl-qdma.txt | 42
> > ++++++++++++++++++++++
> > 1 file changed, 42 insertions(+)
> > create mode 100644
> Documentation/devicetree/bindings/dma/fsl-qdma.txt
> >
> > diff --git a/Documentation/devicetree/bindings/dma/fsl-qdma.txt
> > b/Documentation/devicetree/bindings/dma/fsl-qdma.txt
> > new file mode 100644
> > index 000000000000..b076177b4863
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/dma/fsl-qdma.txt
> > @@ -0,0 +1,42 @@
> > +* Freescale queue Direct Memory Access Controller(qDMA) Controller
> > +
> > + The qDMA controller transfers blocks of data between one source and
> > + one or more
>
> Why the indentation?
>
I did it by referring to Documentation/devicetree/bindings/dma/fsl-edma.txt, is it ok?
> > +destinations. The blocks of data transferred can be represented in
> > +memory as contiguous or non-contiguous using scatter/gather table(s).
> > +Channel virtualization is supported through enqueuing of DMA jobs to,
> > +or dequeuing DMA jobs from, different work queues.
> > +
> > +* qDMA Controller
> > +Required properties:
> > +- compatible :
>
> Add "Should be one of:"
>
> > + - "fsl,ls1021a-qdma",
> > + Or "fsl,ls1043a-qdma" followed by "fsl,ls1021a-qdma",
>
> Then remove the "Or" and replace " followed by" with a comma (like dts
> source).
>
- compatible : Should be "fsl,ls1021a-qdma" or "fsl,ls1043a-qdma", "fsl,ls1021a-qdma"
Is that ok?
> > +- reg : Specifies base physical address(s) and size of the qDMA registers.
> > + The region is qDMA control register's address and size.
> > +- interrupts : A list of interrupt-specifiers, one for each entry in
> > + interrupt-names.
> > +- interrupt-names : Should contain:
> > + "qdma-error" - the error interrupt
> > + "qdma-queue" - the queue interrupt
> > +- channels : Number of channels supported by the controller
>
> dma-channels is the standard name.
>
Okay, got it.
> > +- queues : Number of queues supported by driver
>
> Needs a vendor prefix.
>
Where do I put the vendor prefix?
> > +
> > +Optional properties:
> > +- big-endian: If present registers and hardware scatter/gather descriptors
> > + of the qDMA are implemented in big endian mode, otherwise in little
> > + mode.
> > +
> > +
> > +Examples:
> > +
> > + qdma: qdma@8390000 {
>
> Use standard node names:
>
> dma-controller@...
>
Okay,got it, thanks.
> > + compatible = "fsl,ls1021a-qdma";
> > + reg = <0x0 0x8398000 0x0 0x2000 /* Controller registers */
> > + 0x0 0x839a000 0x0 0x2000>; /* Block registers */
> > + interrupts = <GIC_SPI 185 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH>;
> > + interrupt-names = "qdma-error", "qdma-queue";
> > + channels = <8>;
> > + queues = <2>;
> > + big-endian;
> > + };
> > --
> > 2.14.1
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe devicetree"
> > in the body of a message to majordomo@vger.kernel.org More majordomo
> > info at
> >
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fvger
> > .kernel.org%2Fmajordomo-info.html&data=02%7C01%7Cwen.he_1%40nxp
> .com%7C
> >
> add4f366ab4d4e0d044108d547d98413%7C686ea1d3bc2b4c6fa92cd99c5c30
> 1635%7C
> >
> 0%7C0%7C636493921907553084&sdata=cKidY%2FNVuPfFytKiILGAX1sQm69
> xI%2FdDv
> > BeGxYf7sbg%3D&reserved=0
^ permalink raw reply
* Re: [PATCH v2 2/2] PCI: mediatek: Fixup class type for MT7622
From: Honghui Zhang @ 2017-12-21 7:01 UTC (permalink / raw)
To: Yong Wu
Cc: bhelgaas, matthias.bgg, linux-arm-kernel, linux-mediatek,
linux-pci, linux-kernel, devicetree, yingjoe.chen, eddie.huang,
ryder.lee, lorenzo.pieralisi, hongkun.cao, youlin.pei, yt.shen,
sean.wang, xinping.qian, yu.yu
In-Reply-To: <1513838476.23174.3.camel@mhfsdcap03>
On Thu, 2017-12-21 at 14:41 +0800, Yong Wu wrote:
> On Thu, 2017-12-21 at 10:11 +0800, honghui.zhang@mediatek.com wrote:
> > From: Honghui Zhang <honghui.zhang@mediatek.com>
> >
> > The host bridge of MT7622 has hardware code the class code to an
> > arbitrary, meaningless value, fix that.
> >
> > Signed-off-by: Honghui Zhang <honghui.zhang@mediatek.com>
> > ---
> > drivers/pci/host/pcie-mediatek.c | 12 ++++++++++++
> > 1 file changed, 12 insertions(+)
> >
> > diff --git a/drivers/pci/host/pcie-mediatek.c b/drivers/pci/host/pcie-mediatek.c
> > index 3248771..ae8d367 100644
> > --- a/drivers/pci/host/pcie-mediatek.c
> > +++ b/drivers/pci/host/pcie-mediatek.c
> > @@ -1174,3 +1174,15 @@ static struct platform_driver mtk_pcie_driver = {
> > },
> > };
> > builtin_platform_driver(mtk_pcie_driver);
> > +
> > +/* The host bridge of MT7622 advertises the wrong device class. */
> > +static void mtk_fixup_class(struct pci_dev *dev)
> > +{
> > + dev->class = PCI_CLASS_BRIDGE_PCI << 8;
> > +}
> > +
> > +/*
> > + * The HW default value of vendor id and device id for mt7622 are 0x0e8d,
> > + * 0x3258, which are arbitrary, meaningless values.
> > + */
>
> What's the right vendor id and device id? is it possible to fix them
> too?
Vendor ID is managed by PCI-SIG, you may get the assigned vendor ID
from:
https://pci-ids.ucw.cz/read/PC?restrict=
The vendor ID for Mediatek Corp. should be 14c3.
Device ID is something like vendor-defined.
Those values are in the configuration space and are read-only defined by
spec, it's been stored at the pci_dev, we may change the vendor and
device values in pci_dev, but I don't think it's necessary to change
that.
BTW, Does anyone really cares about the vendor ID and device ID except
the device's driver?
thanks.
>
> > +DECLARE_PCI_FIXUP_EARLY(0x0e8d, 0x3258, mtk_fixup_class);
>
>
^ permalink raw reply
* [PATCH v17 5/5] dt-bindings: watchdog: Add bindings for RAVE SP watchdog driver
From: Andrey Smirnov @ 2017-12-21 6:51 UTC (permalink / raw)
To: Lee Jones
Cc: Andrey Smirnov, linux-kernel, devicetree, linux-watchdog, cphealy,
Lucas Stach, Nikita Yushchenko, Greg Kroah-Hartman, Pavel Machek,
Andy Shevchenko, Guenter Roeck, Rob Herring, Johan Hovold,
Mark Rutland, Sebastian Reichel, Philippe Ombredanne
In-Reply-To: <20171221065118.29726-1-andrew.smirnov@gmail.com>
Add Device Tree bindings for RAVE SP watchdog drvier - an MFD cell of
parent RAVE SP driver (documented in
Documentation/devicetree/bindings/mfd/zii,rave-sp.txt).
Cc: linux-kernel@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: linux-watchdog@vger.kernel.org
Cc: cphealy@gmail.com
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
Cc: Lee Jones <lee.jones@linaro.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Rob Herring <robh@kernel.org>
Cc: Johan Hovold <johan@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Cc: Philippe Ombredanne <pombredanne@nexb.com>
Acked-by: Philippe Ombredanne <pombredanne@nexb.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Acked-by: Rob Herring <robh@kernel.org>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
---
.../bindings/watchdog/zii,rave-sp-wdt.txt | 39 ++++++++++++++++++++++
1 file changed, 39 insertions(+)
create mode 100644 Documentation/devicetree/bindings/watchdog/zii,rave-sp-wdt.txt
diff --git a/Documentation/devicetree/bindings/watchdog/zii,rave-sp-wdt.txt b/Documentation/devicetree/bindings/watchdog/zii,rave-sp-wdt.txt
new file mode 100644
index 000000000000..3de96186e92e
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/zii,rave-sp-wdt.txt
@@ -0,0 +1,39 @@
+Zodiac Inflight Innovations RAVE Supervisory Processor Watchdog Bindings
+
+RAVE SP watchdog device is a "MFD cell" device corresponding to
+watchdog functionality of RAVE Supervisory Processor. It is expected
+that its Device Tree node is specified as a child of the node
+corresponding to the parent RAVE SP device (as documented in
+Documentation/devicetree/bindings/mfd/zii,rave-sp.txt)
+
+Required properties:
+
+- compatible: Depending on wire protocol implemented by RAVE SP
+ firmware, should be one of:
+ - "zii,rave-sp-watchdog"
+ - "zii,rave-sp-watchdog-legacy"
+
+Optional properties:
+
+- wdt-timeout: Two byte nvmem cell specified as per
+ Documentation/devicetree/bindings/nvmem/nvmem.txt
+
+Example:
+
+ rave-sp {
+ compatible = "zii,rave-sp-rdu1";
+ current-speed = <38400>;
+
+ eeprom {
+ wdt_timeout: wdt-timeout@8E {
+ reg = <0x8E 2>;
+ };
+ };
+
+ watchdog {
+ compatible = "zii,rave-sp-watchdog";
+ nvmem-cells = <&wdt_timeout>;
+ nvmem-cell-names = "wdt-timeout";
+ };
+ }
+
--
2.14.3
^ permalink raw reply related
* [PATCH v17 0/5] ZII RAVE platform driver
From: Andrey Smirnov @ 2017-12-21 6:51 UTC (permalink / raw)
To: Lee Jones
Cc: Andrey Smirnov, Pavel Machek, Greg Kroah-Hartman,
cphealy-Re5JQEeQqe8AvxtiuMwx3w, Andy Shevchenko, Lucas Stach,
Nikita Yushchenko, Guenter Roeck, Rob Herring, Mark Rutland,
Johan Hovold, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Sebastian Reichel,
Philippe Ombredanne
Everyone:
This patch series is v17 of the driver for supervisory processor found
on RAVE series of devices from ZII. Supervisory processor is a PIC
microcontroller connected to various electrical subsystems on RAVE
devices whose firmware implements protocol to command/qery them.
NOTE:
* This driver dependends on crc_ccitt_false(), added by
2da9378d531f8cc6670c7497f20d936b706ab80b in 'linux-next', the patch
was pulled in by Andrew Morton and is currently avaiting users, so
this series might have to go in through Andrew's tree
Changes since [v16]:
- Fixed commentary style for SPDX tags in .c files
- Collected Ack from Philippe
Changes since [v15]:
- Adopted SPDX tags for licensing information per Philippe's
request
Changes since [v14]:
- Fixed a bug in deframer code where byte processing loop was not
being terminated early is it should've been. This would result,
among other things, in packets of maximum valid length being
incorrectly reported as tool long.
- Increased command timeout value in support other valid commands
that are outsied of scope for this patch set.
- Converted watchdog driver to differentiate between variants
based on its own compatiblity string as opposed to relying on
that of parent MFD device (as per request by Johan and Lee).
NOTE: This change didn't seem to change DT bingins enough to
warrant dropping any Acks for patches affected, so I kept
them. If anyone wants to rescind their Ack, please let me know.
- Collected Acked-by from Pavel
- Collected Acked-by from Lee (for patch 3/5)
Changes since [v13]:
- Fixed incorrect MFD driver menuconfig entry placement
Changes since [v12]:
- Minor comment inconsistencies fixes in rave-sp.c
Changes since [v11]:
- Fix incorrect include in rave-sp-wdt.c as uncovered by kernel
test robot
Changes since [v10]:
- Collected Acked-by from Rob and Reviewed-by from Guenter
- Incorporated watchdog driver feedback from Gunter and Johan
- Incorporated Johan's feedback for the rest of the code
Changes since [v9]:
- Converted watchdog driver to use watchdog_active() instead of
watchdog_hw_running() and replaced WARN_ON with a regular error
message as per feedback from Guenter
- Changed rave_sp_wdt_start() to set WDOG_HW_RUNNING only if
communicating with hardware was sucessful
- Collected Reviewd-by from Sebastian (for serdev related patches)
- Collected Acked-by from Rob (for watchdog DT bindings)
Changes since [v8]:
- Driver moved from drivers/platform to drivers/mfd
- Collected Reviewed-by from Guenter (for patches 1, 2 and 3)
- Incorporated feedback from Guenter into watchdog driver
- Incorporated feedback from Rob into watchdog DT bindings
- Removed struct rave_sp_rsp_status, which was a leftover from v5
-> v6 code removal.
- Fixed minor problems reported by checkpatch
Changes since [v7]:
- Added watchdog driver to the patchset, so it would be easier to
understand how parent/children drivers are tied together
- Added serdev patches to implement devm_serdev_device_open() and make .remove optional
- "Added" missing serdev_device_close() by converting the driver
to use devm_serdev_device_open()
- Converted the driver to use devm_of_platform_populate()
- Removed needless dependency on MFD_CORE
- Removed dependency on SERIAL_DEV_CTRL_TTYPORT
Changes since [v6]:
- Patch 2/2 has been applied by Lee so it is no longer a part of the series
- Removed all sysfs and debugfs attribute to reduce the scope of
the driver propsed for inclusion. This is not a critical to have
feature and can be added/discussed later.
Changes since [v5]:
- Fixed a build break, introduced by a last minute change in [v5]
- Moved majority of attributes that were exposed over sysfs to debugfs
- Document remaining sysfs attributes in Documentation/ABI/testing/sysfs-platform-rave-sp
Changes since [v4]:
- Replaced usage of DEVICE_ATTR with DEVICE_ATTR_RW
- Fixed a number of warnings produces by sparse tool
- Incorporated event more feedback from Andy Shevchenko
- Collected Reviewed-by from Andy
Changes since [v3]:
- Re-collected lost Acked-by from Rob
- Incorporated further feedback from Andy Shevchenko
- Dropped useless change (stray newline) to drivers/mfd/Makefile
Changes since [v2]:
- Fixed swapped command codes in rave_sp_common_get_boot_source()
and rave_sp_common_set_boot_source() revealed by further testing
of the code
- Incorporated feedback from Andy Shevchenko
Changes since [v1]:
- Updated wording in DT-bindings as per Rob's request.
- Collected Rob's Acked-by for patch 2/2
Feedback is greatly appreciated!
Thanks,
Andrey Smirnov
[v16] lkml.kernel.org/r/20171220204517.28313-1-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
[v15] lkml.kernel.org/r/20171220040017.7605-1-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
[v14] lkml.kernel.org/r/20171207162735.25873-1-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
[v13] lkml.kernel.org/r/20171204161118.19558-1-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
[v12] lkml.kernel.org/r/20171109160556.17018-1-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
[v11] lkml.kernel.org/r/20171106152935.16920-1-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
[v10] lkml.kernel.org/r/20171031163656.24552-1-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
[v9] lkml.kernel.org/r/20171025190421.18415-1-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
[v8] lkml.kernel.org/r/20171018170136.12347-1-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
[v7] lkml.kernel.org/r/20171013061321.31252-2-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
[v6] lkml.kernel.org/r/20170828163131.24815-2-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
[v5] lkml.kernel.org/r/20170728142704.11156-1-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
[v4] lkml.kernel.org/r/20170725184450.13171-1-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
[v3] lkml.kernel.org/r/20170724150915.4824-1-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
[v2] lkml.kernel.org/r/20170718175604.11735-1-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
[v1] lkml.kernel.org/r/20170710170449.4544-1-andrew.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
Andrey Smirnov (5):
serdev: Make .remove in struct serdev_device_driver optional
serdev: Introduce devm_serdev_device_open()
mfd: Add driver for RAVE Supervisory Processor
watchdog: Add RAVE SP watchdog driver
dt-bindings: watchdog: Add bindings for RAVE SP watchdog driver
.../bindings/watchdog/zii,rave-sp-wdt.txt | 39 ++
Documentation/driver-model/devres.txt | 3 +
drivers/mfd/Kconfig | 8 +
drivers/mfd/Makefile | 2 +
drivers/mfd/rave-sp.c | 710 +++++++++++++++++++++
drivers/tty/serdev/core.c | 31 +-
drivers/watchdog/Kconfig | 7 +
drivers/watchdog/Makefile | 1 +
drivers/watchdog/rave-sp-wdt.c | 337 ++++++++++
include/linux/mfd/rave-sp.h | 60 ++
include/linux/serdev.h | 1 +
11 files changed, 1197 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/watchdog/zii,rave-sp-wdt.txt
create mode 100644 drivers/mfd/rave-sp.c
create mode 100644 drivers/watchdog/rave-sp-wdt.c
create mode 100644 include/linux/mfd/rave-sp.h
--
2.14.3
--
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/7] soc: mediatek: Add USB wakeup driver
From: Chunfeng Yun @ 2017-12-21 6:50 UTC (permalink / raw)
To: Rob Herring
Cc: Felipe Balbi, Matthias Brugger, Mathias Nyman, Mark Rutland,
Greg Kroah-Hartman, Catalin Marinas, Will Deacon, Jean Delvare,
Sean Wang, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20171215205550.dkiymkok6arheidg@rob-hp-laptop>
On Fri, 2017-12-15 at 14:55 -0600, Rob Herring wrote:
> On Sat, Dec 09, 2017 at 04:45:30PM +0800, Chunfeng Yun wrote:
> > This driver is used to support usb wakeup which is controlled by
> > the glue layer between SSUSB and SPM. Usually the glue layer is put
> > into a system controller, such as pericfg module, which is
> > represented by a syscon node in DTS.
> > Due to the glue layer may vary on different SoCs, it's useful to
> > extract a separated driver to simplify usb controller drivers.
> >
> > Signed-off-by: Chunfeng Yun <chunfeng.yun-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> > ---
> > drivers/soc/mediatek/Kconfig | 8 +
> > drivers/soc/mediatek/Makefile | 1 +
> > drivers/soc/mediatek/mtk-usb-wakeup.c | 519 ++++++++++++++++++++++++++
> > include/dt-bindings/soc/mediatek,usb-wakeup.h | 15 +
>
> This belongs in the binding patch and that should come first.
>
> > include/linux/soc/mediatek/usb-wakeup.h | 88 +++++
> > 5 files changed, 631 insertions(+)
> > create mode 100644 drivers/soc/mediatek/mtk-usb-wakeup.c
> > create mode 100644 include/dt-bindings/soc/mediatek,usb-wakeup.h
> > create mode 100644 include/linux/soc/mediatek/usb-wakeup.h
>
> > +++ b/drivers/soc/mediatek/mtk-usb-wakeup.c
> > @@ -0,0 +1,519 @@
> > +/*
> > + * Copyright (c) 2017 MediaTek Inc.
> > + * Author: Chunfeng Yun <chunfeng.yun-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> > + *
> > + * SPDX-License-Identifier: GPL-2.0
>
> This should be the first line of the file and use a // style comment.
>
> [...]
>
> > diff --git a/include/dt-bindings/soc/mediatek,usb-wakeup.h b/include/dt-bindings/soc/mediatek,usb-wakeup.h
> > new file mode 100644
> > index 0000000..2461795
> > --- /dev/null
> > +++ b/include/dt-bindings/soc/mediatek,usb-wakeup.h
> > @@ -0,0 +1,15 @@
> > +/*
> > + * Copyright (c) 2017 MediaTek Inc.
> > + * Author: Chunfeng Yun <chunfeng.yun-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> > + *
> > + * SPDX-License-Identifier: GPL-2.0
>
> ditto. Except headers use /* */ comments...
modify it next version. 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 0/7] Add USB remote wakeup driver
From: Chunfeng Yun @ 2017-12-21 6:48 UTC (permalink / raw)
To: Rob Herring
Cc: Felipe Balbi, Matthias Brugger, Mathias Nyman, Mark Rutland,
Greg Kroah-Hartman, Catalin Marinas, Will Deacon, Jean Delvare,
Sean Wang, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20171215205504.r6ol7fbbeyghb73w@rob-hp-laptop>
On Fri, 2017-12-15 at 14:55 -0600, Rob Herring wrote:
> On Sat, Dec 09, 2017 at 04:45:29PM +0800, Chunfeng Yun wrote:
> > These patches introduce the SSUSB and SPM glue layer driver which is
> > used to support usb remote wakeup. Usually the glue layer is put into
> > a system controller, such as PERICFG module.
> > The old way to support usb wakeup is put into SSUSB controller drivers,
> > including xhci-mtk driver and mtu3 driver, but there are some problems:
> > 1. can't disdinguish the relation between glue layer and SSUSB IP
> > when SoCs supports multi SSUSB IPs;
> > 2. duplicated code for wakeup are put into both xhci-mtk and mtu3
> > drivers;
> > 3. the glue layer may vary on different SoCs with SSUSB IP, and will
> > make SSUSB controller drivers complicated;
> > In order to resolve these problems, it's useful to make the glue layer
> > transparent by extracting a seperated driver, meanwhile to reduce the
> > duplicated code and simplify SSUSB controller drivers.
>
> Both the driver and binding look overly complicated to me when it looks
> like you just have 2 versions of enable/disable functions which modify
> a single register. The complexity may be justified if this was a common
> binding and driver, but it is not.
>
> You already have a phandle to the system controller. Can't you add cells
> to it to handle any differences between instances? That and SoC specific
> compatible strings should be enough to handle differences.
Yes, adding cells will also work well, I'll try it, thanks a lot
>
> Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 2/2] PCI: mediatek: Fixup class type for MT7622
From: Yong Wu @ 2017-12-21 6:41 UTC (permalink / raw)
To: honghui.zhang
Cc: youlin.pei, devicetree, hongkun.cao, ryder.lee, yu.yu, linux-pci,
sean.wang, linux-kernel, yt.shen, matthias.bgg, lorenzo.pieralisi,
linux-mediatek, xinping.qian, bhelgaas, yingjoe.chen, eddie.huang,
linux-arm-kernel
In-Reply-To: <1513822277-18329-3-git-send-email-honghui.zhang@mediatek.com>
On Thu, 2017-12-21 at 10:11 +0800, honghui.zhang@mediatek.com wrote:
> From: Honghui Zhang <honghui.zhang@mediatek.com>
>
> The host bridge of MT7622 has hardware code the class code to an
> arbitrary, meaningless value, fix that.
>
> Signed-off-by: Honghui Zhang <honghui.zhang@mediatek.com>
> ---
> drivers/pci/host/pcie-mediatek.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/pci/host/pcie-mediatek.c b/drivers/pci/host/pcie-mediatek.c
> index 3248771..ae8d367 100644
> --- a/drivers/pci/host/pcie-mediatek.c
> +++ b/drivers/pci/host/pcie-mediatek.c
> @@ -1174,3 +1174,15 @@ static struct platform_driver mtk_pcie_driver = {
> },
> };
> builtin_platform_driver(mtk_pcie_driver);
> +
> +/* The host bridge of MT7622 advertises the wrong device class. */
> +static void mtk_fixup_class(struct pci_dev *dev)
> +{
> + dev->class = PCI_CLASS_BRIDGE_PCI << 8;
> +}
> +
> +/*
> + * The HW default value of vendor id and device id for mt7622 are 0x0e8d,
> + * 0x3258, which are arbitrary, meaningless values.
> + */
What's the right vendor id and device id? is it possible to fix them
too?
> +DECLARE_PCI_FIXUP_EARLY(0x0e8d, 0x3258, mtk_fixup_class);
^ permalink raw reply
* [PATCH 5/5] regulator: add PM suspend and resume hooks
From: Chunyan Zhang @ 2017-12-21 6:25 UTC (permalink / raw)
To: Mark Brown, Rob Herring
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Chunyan Zhang
In-Reply-To: <1513837506-26543-1-git-send-email-zhang.chunyan-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
In this patch, consumers are allowed to set suspend voltage, and this
actually just set the "uV" in constraint::regulator_state, when the
regulator_suspend_late() was called by PM core through callback when
the system is entering into suspend, the regulator device would act
suspend activity then.
And it assumes that if any consumer set suspend voltage, the regulator
device should be enabled in the suspend state. And if the suspend
voltage of a regulator device for all consumers was set zero, the
regulator device would be off in the suspend state.
This patch also provides a new function hook to regulator devices for
resuming from suspend states.
Signed-off-by: Chunyan Zhang <zhang.chunyan-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
drivers/regulator/core.c | 251 +++++++++++++++++++++++++++++++++-----
drivers/regulator/of_regulator.c | 12 ++
include/linux/regulator/driver.h | 2 +
include/linux/regulator/machine.h | 16 ++-
4 files changed, 249 insertions(+), 32 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 080c233..3f4d3aa 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -236,6 +236,12 @@ static int regulator_check_voltage(struct regulator_dev *rdev,
return 0;
}
+/* return 0 if the state is valid */
+static int regulator_check_states(suspend_state_t state)
+{
+ return (state > PM_SUSPEND_MAX || state == PM_SUSPEND_TO_IDLE);
+}
+
/* Make sure we select a voltage that suits the needs of all
* regulator consumers
*/
@@ -327,6 +333,24 @@ static int regulator_mode_constrain(struct regulator_dev *rdev,
return -EINVAL;
}
+static inline struct regulator_state *
+regulator_get_suspend_state(struct regulator_dev *rdev, suspend_state_t state)
+{
+ if (rdev->constraints == NULL)
+ return NULL;
+
+ switch (state) {
+ case PM_SUSPEND_STANDBY:
+ return &rdev->constraints->state_standby;
+ case PM_SUSPEND_MEM:
+ return &rdev->constraints->state_mem;
+ case PM_SUSPEND_MAX:
+ return &rdev->constraints->state_disk;
+ default:
+ return NULL;
+ }
+}
+
static ssize_t regulator_uV_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
@@ -734,9 +758,14 @@ static int drms_uA_update(struct regulator_dev *rdev)
}
static int suspend_set_state(struct regulator_dev *rdev,
- struct regulator_state *rstate)
+ suspend_state_t state)
{
int ret = 0;
+ struct regulator_state *rstate;
+
+ rstate = regulator_get_suspend_state(rdev, state);
+ if (rstate == NULL)
+ return -EINVAL;
/* If we have no suspend mode configration don't set anything;
* only warn if the driver implements set_suspend_voltage or
@@ -779,28 +808,8 @@ static int suspend_set_state(struct regulator_dev *rdev,
return ret;
}
}
- return ret;
-}
-/* locks held by caller */
-static int suspend_prepare(struct regulator_dev *rdev, suspend_state_t state)
-{
- if (!rdev->constraints)
- return -EINVAL;
-
- switch (state) {
- case PM_SUSPEND_STANDBY:
- return suspend_set_state(rdev,
- &rdev->constraints->state_standby);
- case PM_SUSPEND_MEM:
- return suspend_set_state(rdev,
- &rdev->constraints->state_mem);
- case PM_SUSPEND_MAX:
- return suspend_set_state(rdev,
- &rdev->constraints->state_disk);
- default:
- return -EINVAL;
- }
+ return ret;
}
static void print_constraints(struct regulator_dev *rdev)
@@ -1069,7 +1078,7 @@ static int set_machine_constraints(struct regulator_dev *rdev,
/* do we need to setup our suspend state */
if (rdev->constraints->initial_state) {
- ret = suspend_prepare(rdev, rdev->constraints->initial_state);
+ ret = suspend_set_state(rdev, rdev->constraints->initial_state);
if (ret < 0) {
rdev_err(rdev, "failed to set suspend state\n");
return ret;
@@ -2898,6 +2907,35 @@ static int _regulator_do_set_voltage(struct regulator_dev *rdev,
return ret;
}
+static int _regulator_do_set_suspend_voltage(struct regulator_dev *rdev,
+ int min_uV, int max_uV, suspend_state_t state)
+{
+ struct regulator_state *rstate;
+ int uV, sel;
+
+ rstate = regulator_get_suspend_state(rdev, state);
+ if (rstate == NULL)
+ return -EINVAL;
+
+ if (!rstate->changeable)
+ return -EINVAL;
+
+ if (min_uV < rstate->min_uV)
+ min_uV = rstate->min_uV;
+ if (max_uV > rstate->max_uV)
+ max_uV = rstate->max_uV;
+
+ sel = regulator_map_voltage(rdev, min_uV, max_uV);
+ if (sel < 0)
+ return sel;
+
+ uV = rdev->desc->ops->list_voltage(rdev, sel);
+ if (uV >= min_uV && uV <= max_uV)
+ rstate->uV = uV;
+
+ return 0;
+}
+
static int regulator_set_voltage_unlocked(struct regulator *regulator,
int min_uV, int max_uV,
suspend_state_t state)
@@ -2993,7 +3031,11 @@ static int regulator_set_voltage_unlocked(struct regulator *regulator,
}
}
- ret = _regulator_do_set_voltage(rdev, min_uV, max_uV);
+ if (state == PM_SUSPEND_ON)
+ ret = _regulator_do_set_voltage(rdev, min_uV, max_uV);
+ else
+ ret = _regulator_do_set_suspend_voltage(rdev, min_uV,
+ max_uV, state);
if (ret < 0)
goto out2;
@@ -3049,6 +3091,92 @@ int regulator_set_voltage(struct regulator *regulator, int min_uV, int max_uV)
}
EXPORT_SYMBOL_GPL(regulator_set_voltage);
+static inline int regulator_suspend_toggle(struct regulator_dev *rdev,
+ suspend_state_t state, bool en)
+{
+ struct regulator_state *rstate;
+
+ rstate = regulator_get_suspend_state(rdev, state);
+ if (rstate == NULL)
+ return -EINVAL;
+
+ if (!rstate->changeable)
+ return -EINVAL;
+
+ rstate->enabled = en;
+
+ return 0;
+}
+
+static int regulator_suspend_enable(struct regulator_dev *rdev,
+ suspend_state_t state)
+{
+ return regulator_suspend_toggle(rdev, state, true);
+}
+
+static int regulator_suspend_disable(struct regulator_dev *rdev,
+ suspend_state_t state)
+{
+ struct regulator *regulator;
+ struct regulator_voltage *voltage;
+
+ /*
+ * if any consumer wants this regulator device keeping on in
+ * suspend states, don't set it as disabled.
+ */
+ list_for_each_entry(regulator, &rdev->consumer_list, list) {
+ voltage = ®ulator->voltage[state];
+ if (voltage->min_uV || voltage->max_uV)
+ return 0;
+ }
+
+ return regulator_suspend_toggle(rdev, state, false);
+}
+
+static int _regulator_set_suspend_voltage(struct regulator *regulator,
+ int min_uV, int max_uV,
+ suspend_state_t state)
+{
+ int ret;
+ struct regulator_dev *rdev = regulator->rdev;
+
+ /*
+ * We assume users want to switch off the regulator device for
+ * suspend state when setting min_uV and max_uV all with zero.
+ */
+ if (min_uV == 0 && max_uV == 0) {
+ regulator->voltage[state].min_uV = 0;
+ regulator->voltage[state].max_uV = 0;
+ return regulator_suspend_disable(rdev, state);
+ }
+
+ ret = regulator_suspend_enable(rdev, state);
+ if (ret < 0)
+ return ret;
+
+ return regulator_set_voltage_unlocked(regulator, min_uV, max_uV, state);
+}
+
+int regulator_set_suspend_voltage(struct regulator *regulator, int min_uV,
+ int max_uV, suspend_state_t state)
+{
+ int ret = 0;
+
+ /* PM_SUSPEND_ON is handled by regulator_set_voltage() */
+ if (regulator_check_states(state) || state == PM_SUSPEND_ON)
+ return -EINVAL;
+
+ regulator_lock_supply(regulator->rdev);
+
+ ret = _regulator_set_suspend_voltage(regulator, min_uV,
+ max_uV, state);
+
+ regulator_unlock_supply(regulator->rdev);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(regulator_set_suspend_voltage);
+
/**
* regulator_set_voltage_time - get raise/fall time
* @regulator: regulator source
@@ -3923,12 +4051,6 @@ static void regulator_dev_release(struct device *dev)
kfree(rdev);
}
-static struct class regulator_class = {
- .name = "regulator",
- .dev_release = regulator_dev_release,
- .dev_groups = regulator_dev_groups,
-};
-
static void rdev_init_debugfs(struct regulator_dev *rdev)
{
struct device *parent = rdev->dev.parent;
@@ -4179,7 +4301,76 @@ void regulator_unregister(struct regulator_dev *rdev)
}
EXPORT_SYMBOL_GPL(regulator_unregister);
+static int _regulator_suspend_late(struct device *dev, void *data)
+{
+ struct regulator_dev *rdev = dev_to_rdev(dev);
+ suspend_state_t *state = data;
+ int ret;
+ mutex_lock(&rdev->mutex);
+ ret = suspend_set_state(rdev, *state);
+ mutex_unlock(&rdev->mutex);
+
+ return ret;
+}
+
+/**
+ * regulator_suspend_late - prepare regulators for system wide suspend
+ * @state: system suspend state
+ *
+ * Configure each regulator with it's suspend operating parameters for state.
+ */
+static int regulator_suspend_late(struct device *dev)
+{
+ suspend_state_t state = pm_suspend_target_state;
+
+ return class_for_each_device(®ulator_class, NULL, &state,
+ _regulator_suspend_late);
+}
+static int _regulator_resume_early(struct device *dev, void *data)
+{
+ int ret = 0;
+ struct regulator_dev *rdev = dev_to_rdev(dev);
+ suspend_state_t *state = data;
+ struct regulator_state *rstate;
+
+ rstate = regulator_get_suspend_state(rdev, *state);
+ if (rstate == NULL)
+ return -EINVAL;
+
+ mutex_lock(&rdev->mutex);
+
+ if (rdev->desc->ops->resume_early &&
+ (rstate->enabled == ENABLE_IN_SUSPEND ||
+ rstate->enabled == DISABLE_IN_SUSPEND))
+ ret = rdev->desc->ops->resume_early(rdev);
+
+ mutex_unlock(&rdev->mutex);
+
+ return ret;
+}
+
+static int regulator_resume_early(struct device *dev)
+{
+ suspend_state_t state = pm_suspend_target_state;
+
+ return class_for_each_device(®ulator_class, NULL, &state,
+ _regulator_resume_early);
+}
+
+static const struct dev_pm_ops __maybe_unused regulator_pm_ops = {
+ .suspend_late = regulator_suspend_late,
+ .resume_early = regulator_resume_early,
+};
+
+static struct class regulator_class = {
+ .name = "regulator",
+ .dev_release = regulator_dev_release,
+ .dev_groups = regulator_dev_groups,
+#ifdef CONFIG_PM_SLEEP
+ .pm = ®ulator_pm_ops,
+#endif
+};
/**
* regulator_has_full_constraints - the system has fully specified constraints
*
diff --git a/drivers/regulator/of_regulator.c b/drivers/regulator/of_regulator.c
index 41dad42..7dc8fd2 100644
--- a/drivers/regulator/of_regulator.c
+++ b/drivers/regulator/of_regulator.c
@@ -188,6 +188,18 @@ static void of_get_regulation_constraints(struct device_node *np,
"regulator-suspend-microvolt", &pval))
suspend_state->uV = pval;
+ if (!of_property_read_u32(np, "regulator-suspend-min-microvolt",
+ &pval))
+ suspend_state->min_uV = pval;
+
+ if (!of_property_read_u32(np, "regulator-suspend-max-microvolt",
+ &pval))
+ suspend_state->max_uV = pval;
+
+ if (of_property_read_bool(suspend_np,
+ "regulator-changeable-in-suspend"))
+ suspend_state->changeable = true;
+
if (i == PM_SUSPEND_MEM)
constraints->initial_state = PM_SUSPEND_MEM;
diff --git a/include/linux/regulator/driver.h b/include/linux/regulator/driver.h
index 94417b4..4c00486 100644
--- a/include/linux/regulator/driver.h
+++ b/include/linux/regulator/driver.h
@@ -214,6 +214,8 @@ struct regulator_ops {
/* set regulator suspend operating mode (defined in consumer.h) */
int (*set_suspend_mode) (struct regulator_dev *, unsigned int mode);
+ int (*resume_early)(struct regulator_dev *rdev);
+
int (*set_pull_down) (struct regulator_dev *);
};
diff --git a/include/linux/regulator/machine.h b/include/linux/regulator/machine.h
index b4ddb56..f60ec1f 100644
--- a/include/linux/regulator/machine.h
+++ b/include/linux/regulator/machine.h
@@ -42,7 +42,12 @@ struct regulator;
#define REGULATOR_CHANGE_DRMS 0x10
#define REGULATOR_CHANGE_BYPASS 0x20
-/* operations in suspend mode */
+/*
+ * operations in suspend mode
+ * DO_NOTHING_IN_SUSPEND - the default value
+ * DISABLE_IN_SUSPEND - turn off regulator in suspend states
+ * ENABLE_IN_SUSPEND - keep regulator on in suspend states
+ */
#define DO_NOTHING_IN_SUSPEND (-1)
#define DISABLE_IN_SUSPEND 0
#define ENABLE_IN_SUSPEND 1
@@ -61,17 +66,24 @@ enum regulator_active_discharge {
* state. One of enabled or disabled must be set for the
* configuration to be applied.
*
- * @uV: Operating voltage during suspend.
+ * @uV: Default operating voltage during suspend, it can be adjusted
+ * among <min_uV, max_uV>
+ * @min_uV: Minimum suspend voltage may be set.
+ * @max_uV: Maximum suspend voltage may be set.
* @mode: Operating mode during suspend.
* @enabled: operations during suspend.
* - DO_NOTHING_IN_SUSPEND
* - DISABLE_IN_SUSPEND
* - ENABLE_IN_SUSPEND
+ * @changeable: Is this state can be changed.
*/
struct regulator_state {
int uV; /* suspend voltage */
+ int min_uV;
+ int max_uV;
unsigned int mode; /* suspend regulator operating mode */
int enabled; /* is regulator enabled in this suspend state */
+ bool changeable;
};
/**
--
2.7.4
--
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 4/5] drivers: regulator: empty the old suspend functions
From: Chunyan Zhang @ 2017-12-21 6:25 UTC (permalink / raw)
To: Mark Brown, Rob Herring
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Chunyan Zhang
In-Reply-To: <1513837506-26543-1-git-send-email-zhang.chunyan-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Regualtor suspend/resume functions should only be called by PM suspend
core via registering dev_pm_ops, and regulator devices should implement
the callback functions. Thus, any regulator consumer shouldn't call
the regulator suspend/resume functions directly.
In order to avoid compile errors, two empty functions with the same name
still be left for the time being.
Signed-off-by: Chunyan Zhang <zhang.chunyan-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
drivers/regulator/core.c | 74 ---------------------------------------
include/linux/regulator/machine.h | 5 ++-
2 files changed, 2 insertions(+), 77 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 5ea80e9..080c233 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -4179,80 +4179,6 @@ void regulator_unregister(struct regulator_dev *rdev)
}
EXPORT_SYMBOL_GPL(regulator_unregister);
-static int _regulator_suspend_prepare(struct device *dev, void *data)
-{
- struct regulator_dev *rdev = dev_to_rdev(dev);
- const suspend_state_t *state = data;
- int ret;
-
- mutex_lock(&rdev->mutex);
- ret = suspend_prepare(rdev, *state);
- mutex_unlock(&rdev->mutex);
-
- return ret;
-}
-
-/**
- * regulator_suspend_prepare - prepare regulators for system wide suspend
- * @state: system suspend state
- *
- * Configure each regulator with it's suspend operating parameters for state.
- * This will usually be called by machine suspend code prior to supending.
- */
-int regulator_suspend_prepare(suspend_state_t state)
-{
- /* ON is handled by regulator active state */
- if (state == PM_SUSPEND_ON)
- return -EINVAL;
-
- return class_for_each_device(®ulator_class, NULL, &state,
- _regulator_suspend_prepare);
-}
-EXPORT_SYMBOL_GPL(regulator_suspend_prepare);
-
-static int _regulator_suspend_finish(struct device *dev, void *data)
-{
- struct regulator_dev *rdev = dev_to_rdev(dev);
- int ret;
-
- mutex_lock(&rdev->mutex);
- if (rdev->use_count > 0 || rdev->constraints->always_on) {
- if (!_regulator_is_enabled(rdev)) {
- ret = _regulator_do_enable(rdev);
- if (ret)
- dev_err(dev,
- "Failed to resume regulator %d\n",
- ret);
- }
- } else {
- if (!have_full_constraints())
- goto unlock;
- if (!_regulator_is_enabled(rdev))
- goto unlock;
-
- ret = _regulator_do_disable(rdev);
- if (ret)
- dev_err(dev, "Failed to suspend regulator %d\n", ret);
- }
-unlock:
- mutex_unlock(&rdev->mutex);
-
- /* Keep processing regulators in spite of any errors */
- return 0;
-}
-
-/**
- * regulator_suspend_finish - resume regulators from system wide suspend
- *
- * Turn on regulators that might be turned off by regulator_suspend_prepare
- * and that should be turned on according to the regulators properties.
- */
-int regulator_suspend_finish(void)
-{
- return class_for_each_device(®ulator_class, NULL, NULL,
- _regulator_suspend_finish);
-}
-EXPORT_SYMBOL_GPL(regulator_suspend_finish);
/**
* regulator_has_full_constraints - the system has fully specified constraints
diff --git a/include/linux/regulator/machine.h b/include/linux/regulator/machine.h
index e50519f..b4ddb56 100644
--- a/include/linux/regulator/machine.h
+++ b/include/linux/regulator/machine.h
@@ -231,12 +231,12 @@ struct regulator_init_data {
#ifdef CONFIG_REGULATOR
void regulator_has_full_constraints(void);
-int regulator_suspend_prepare(suspend_state_t state);
-int regulator_suspend_finish(void);
#else
static inline void regulator_has_full_constraints(void)
{
}
+#endif
+
static inline int regulator_suspend_prepare(suspend_state_t state)
{
return 0;
@@ -245,6 +245,5 @@ static inline int regulator_suspend_finish(void)
{
return 0;
}
-#endif
#endif
--
2.7.4
--
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 3/5] drivers: regulator: leave one item to record whether regulator is enabled
From: Chunyan Zhang @ 2017-12-21 6:25 UTC (permalink / raw)
To: Mark Brown, Rob Herring; +Cc: devicetree, linux-kernel, Chunyan Zhang
In-Reply-To: <1513837506-26543-1-git-send-email-zhang.chunyan@linaro.org>
The items "disabled" and "enabled" are a little redundant, since only one
of them would be set to record if the regulator device should keep on
or be switched to off in suspend states.
So in this patch, the "disabled" was removed, only leave the "enabled":
- enabled == 1 for regulator-on-in-suspend
- enabled == 0 for regulator-off-in-suspend
- enabled == -1 means do nothing when entering suspend mode.
Signed-off-by: Chunyan Zhang <zhang.chunyan@linaro.org>
---
drivers/regulator/core.c | 14 ++++++--------
drivers/regulator/of_regulator.c | 6 ++++--
include/linux/regulator/machine.h | 12 +++++++++---
3 files changed, 19 insertions(+), 13 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 97bc9f7..5ea80e9 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -742,21 +742,19 @@ static int suspend_set_state(struct regulator_dev *rdev,
* only warn if the driver implements set_suspend_voltage or
* set_suspend_mode callback.
*/
- if (!rstate->enabled && !rstate->disabled) {
+ if (rstate->enabled != ENABLE_IN_SUSPEND &&
+ rstate->enabled != DISABLE_IN_SUSPEND) {
if (rdev->desc->ops->set_suspend_voltage ||
rdev->desc->ops->set_suspend_mode)
rdev_warn(rdev, "No configuration\n");
return 0;
}
- if (rstate->enabled && rstate->disabled) {
- rdev_err(rdev, "invalid configuration\n");
- return -EINVAL;
- }
-
- if (rstate->enabled && rdev->desc->ops->set_suspend_enable)
+ if (rstate->enabled == ENABLE_IN_SUSPEND &&
+ rdev->desc->ops->set_suspend_enable)
ret = rdev->desc->ops->set_suspend_enable(rdev);
- else if (rstate->disabled && rdev->desc->ops->set_suspend_disable)
+ else if (rstate->enabled == DISABLE_IN_SUSPEND &&
+ rdev->desc->ops->set_suspend_disable)
ret = rdev->desc->ops->set_suspend_disable(rdev);
else /* OK if set_suspend_enable or set_suspend_disable is NULL */
ret = 0;
diff --git a/drivers/regulator/of_regulator.c b/drivers/regulator/of_regulator.c
index 14637a0..41dad42 100644
--- a/drivers/regulator/of_regulator.c
+++ b/drivers/regulator/of_regulator.c
@@ -177,10 +177,12 @@ static void of_get_regulation_constraints(struct device_node *np,
if (of_property_read_bool(suspend_np,
"regulator-on-in-suspend"))
- suspend_state->enabled = true;
+ suspend_state->enabled = ENABLE_IN_SUSPEND;
else if (of_property_read_bool(suspend_np,
"regulator-off-in-suspend"))
- suspend_state->disabled = true;
+ suspend_state->enabled = DISABLE_IN_SUSPEND;
+ else
+ suspend_state->enabled = DO_NOTHING_IN_SUSPEND;
if (!of_property_read_u32(suspend_np,
"regulator-suspend-microvolt", &pval))
diff --git a/include/linux/regulator/machine.h b/include/linux/regulator/machine.h
index 9cd4fef..e50519f 100644
--- a/include/linux/regulator/machine.h
+++ b/include/linux/regulator/machine.h
@@ -42,6 +42,11 @@ struct regulator;
#define REGULATOR_CHANGE_DRMS 0x10
#define REGULATOR_CHANGE_BYPASS 0x20
+/* operations in suspend mode */
+#define DO_NOTHING_IN_SUSPEND (-1)
+#define DISABLE_IN_SUSPEND 0
+#define ENABLE_IN_SUSPEND 1
+
/* Regulator active discharge flags */
enum regulator_active_discharge {
REGULATOR_ACTIVE_DISCHARGE_DEFAULT,
@@ -58,14 +63,15 @@ enum regulator_active_discharge {
*
* @uV: Operating voltage during suspend.
* @mode: Operating mode during suspend.
- * @enabled: Enabled during suspend.
- * @disabled: Disabled during suspend.
+ * @enabled: operations during suspend.
+ * - DO_NOTHING_IN_SUSPEND
+ * - DISABLE_IN_SUSPEND
+ * - ENABLE_IN_SUSPEND
*/
struct regulator_state {
int uV; /* suspend voltage */
unsigned int mode; /* suspend regulator operating mode */
int enabled; /* is regulator enabled in this suspend state */
- int disabled; /* is the regulator disabled in this suspend state */
};
/**
--
2.7.4
^ permalink raw reply related
* [PATCH 2/5] regulator: make regulator voltage be an array to support more states
From: Chunyan Zhang @ 2017-12-21 6:25 UTC (permalink / raw)
To: Mark Brown, Rob Herring
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Chunyan Zhang
In-Reply-To: <1513837506-26543-1-git-send-email-zhang.chunyan-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Some regulator consumers would like to make the regulator device
keeping a voltage range output when the system entering into
suspend states.
Making regulator voltage be an array can allow consumers to set voltage
for normal state as well as for suspend states through the same code.
Signed-off-by: Chunyan Zhang <zhang.chunyan-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
drivers/regulator/core.c | 63 ++++++++++++++++++++++++--------------------
drivers/regulator/internal.h | 18 +++++++++++--
2 files changed, 51 insertions(+), 30 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index b64b791..97bc9f7 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -240,22 +240,25 @@ static int regulator_check_voltage(struct regulator_dev *rdev,
* regulator consumers
*/
static int regulator_check_consumers(struct regulator_dev *rdev,
- int *min_uV, int *max_uV)
+ int *min_uV, int *max_uV,
+ suspend_state_t state)
{
struct regulator *regulator;
+ struct regulator_voltage *voltage;
list_for_each_entry(regulator, &rdev->consumer_list, list) {
+ voltage = ®ulator->voltage[state];
/*
* Assume consumers that didn't say anything are OK
* with anything in the constraint range.
*/
- if (!regulator->min_uV && !regulator->max_uV)
+ if (!voltage->min_uV && !voltage->max_uV)
continue;
- if (*max_uV > regulator->max_uV)
- *max_uV = regulator->max_uV;
- if (*min_uV < regulator->min_uV)
- *min_uV = regulator->min_uV;
+ if (*max_uV > voltage->max_uV)
+ *max_uV = voltage->max_uV;
+ if (*min_uV < voltage->min_uV)
+ *min_uV = voltage->min_uV;
}
if (*min_uV > *max_uV) {
@@ -1356,9 +1359,9 @@ static struct regulator *create_regulator(struct regulator_dev *rdev,
debugfs_create_u32("uA_load", 0444, regulator->debugfs,
®ulator->uA_load);
debugfs_create_u32("min_uV", 0444, regulator->debugfs,
- ®ulator->min_uV);
+ ®ulator->voltage[PM_SUSPEND_ON].min_uV);
debugfs_create_u32("max_uV", 0444, regulator->debugfs,
- ®ulator->max_uV);
+ ®ulator->voltage[PM_SUSPEND_ON].max_uV);
debugfs_create_file("constraint_flags", 0444,
regulator->debugfs, regulator,
&constraint_flags_fops);
@@ -2898,9 +2901,11 @@ static int _regulator_do_set_voltage(struct regulator_dev *rdev,
}
static int regulator_set_voltage_unlocked(struct regulator *regulator,
- int min_uV, int max_uV)
+ int min_uV, int max_uV,
+ suspend_state_t state)
{
struct regulator_dev *rdev = regulator->rdev;
+ struct regulator_voltage *voltage = ®ulator->voltage[state];
int ret = 0;
int old_min_uV, old_max_uV;
int current_uV;
@@ -2911,7 +2916,7 @@ static int regulator_set_voltage_unlocked(struct regulator *regulator,
* should be a noop (some cpufreq implementations use the same
* voltage for multiple frequencies, for example).
*/
- if (regulator->min_uV == min_uV && regulator->max_uV == max_uV)
+ if (voltage->min_uV == min_uV && voltage->max_uV == max_uV)
goto out;
/* If we're trying to set a range that overlaps the current voltage,
@@ -2921,8 +2926,8 @@ static int regulator_set_voltage_unlocked(struct regulator *regulator,
if (!regulator_ops_is_valid(rdev, REGULATOR_CHANGE_VOLTAGE)) {
current_uV = _regulator_get_voltage(rdev);
if (min_uV <= current_uV && current_uV <= max_uV) {
- regulator->min_uV = min_uV;
- regulator->max_uV = max_uV;
+ voltage->min_uV = min_uV;
+ voltage->max_uV = max_uV;
goto out;
}
}
@@ -2940,12 +2945,12 @@ static int regulator_set_voltage_unlocked(struct regulator *regulator,
goto out;
/* restore original values in case of error */
- old_min_uV = regulator->min_uV;
- old_max_uV = regulator->max_uV;
- regulator->min_uV = min_uV;
- regulator->max_uV = max_uV;
+ old_min_uV = voltage->min_uV;
+ old_max_uV = voltage->max_uV;
+ voltage->min_uV = min_uV;
+ voltage->max_uV = max_uV;
- ret = regulator_check_consumers(rdev, &min_uV, &max_uV);
+ ret = regulator_check_consumers(rdev, &min_uV, &max_uV, state);
if (ret < 0)
goto out2;
@@ -2982,7 +2987,7 @@ static int regulator_set_voltage_unlocked(struct regulator *regulator,
if (supply_change_uV > 0) {
ret = regulator_set_voltage_unlocked(rdev->supply,
- best_supply_uV, INT_MAX);
+ best_supply_uV, INT_MAX, state);
if (ret) {
dev_err(&rdev->dev, "Failed to increase supply voltage: %d\n",
ret);
@@ -2996,7 +3001,7 @@ static int regulator_set_voltage_unlocked(struct regulator *regulator,
if (supply_change_uV < 0) {
ret = regulator_set_voltage_unlocked(rdev->supply,
- best_supply_uV, INT_MAX);
+ best_supply_uV, INT_MAX, state);
if (ret)
dev_warn(&rdev->dev, "Failed to decrease supply voltage: %d\n",
ret);
@@ -3007,8 +3012,8 @@ static int regulator_set_voltage_unlocked(struct regulator *regulator,
out:
return ret;
out2:
- regulator->min_uV = old_min_uV;
- regulator->max_uV = old_max_uV;
+ voltage->min_uV = old_min_uV;
+ voltage->max_uV = old_max_uV;
return ret;
}
@@ -3037,7 +3042,8 @@ int regulator_set_voltage(struct regulator *regulator, int min_uV, int max_uV)
regulator_lock_supply(regulator->rdev);
- ret = regulator_set_voltage_unlocked(regulator, min_uV, max_uV);
+ ret = regulator_set_voltage_unlocked(regulator, min_uV, max_uV,
+ PM_SUSPEND_ON);
regulator_unlock_supply(regulator->rdev);
@@ -3138,6 +3144,7 @@ EXPORT_SYMBOL_GPL(regulator_set_voltage_time_sel);
int regulator_sync_voltage(struct regulator *regulator)
{
struct regulator_dev *rdev = regulator->rdev;
+ struct regulator_voltage *voltage = ®ulator->voltage[PM_SUSPEND_ON];
int ret, min_uV, max_uV;
mutex_lock(&rdev->mutex);
@@ -3149,20 +3156,20 @@ int regulator_sync_voltage(struct regulator *regulator)
}
/* This is only going to work if we've had a voltage configured. */
- if (!regulator->min_uV && !regulator->max_uV) {
+ if (!voltage->min_uV && !voltage->max_uV) {
ret = -EINVAL;
goto out;
}
- min_uV = regulator->min_uV;
- max_uV = regulator->max_uV;
+ min_uV = voltage->min_uV;
+ max_uV = voltage->max_uV;
/* This should be a paranoia check... */
ret = regulator_check_voltage(rdev, &min_uV, &max_uV);
if (ret < 0)
goto out;
- ret = regulator_check_consumers(rdev, &min_uV, &max_uV);
+ ret = regulator_check_consumers(rdev, &min_uV, &max_uV, 0);
if (ret < 0)
goto out;
@@ -4424,8 +4431,8 @@ static void regulator_summary_show_subtree(struct seq_file *s,
switch (rdev->desc->type) {
case REGULATOR_VOLTAGE:
seq_printf(s, "%37dmV %5dmV",
- consumer->min_uV / 1000,
- consumer->max_uV / 1000);
+ consumer->voltage[PM_SUSPEND_ON].min_uV / 1000,
+ consumer->voltage[PM_SUSPEND_ON].max_uV / 1000);
break;
case REGULATOR_CURRENT:
break;
diff --git a/drivers/regulator/internal.h b/drivers/regulator/internal.h
index 66a8ea0..aba8e414 100644
--- a/drivers/regulator/internal.h
+++ b/drivers/regulator/internal.h
@@ -16,10 +16,25 @@
#ifndef __REGULATOR_INTERNAL_H
#define __REGULATOR_INTERNAL_H
+#include <linux/suspend.h>
+
+#define REGULATOR_STATES_NUM (PM_SUSPEND_MAX + 1)
+
+struct regulator_voltage {
+ int min_uV;
+ int max_uV;
+};
+
/*
* struct regulator
*
* One for each consumer device.
+ * @voltage - a voltage array for each state of runtime, i.e.:
+ * PM_SUSPEND_ON
+ * PM_SUSPEND_TO_IDLE
+ * PM_SUSPEND_STANDBY
+ * PM_SUSPEND_MEM
+ * PM_SUSPEND_MAX
*/
struct regulator {
struct device *dev;
@@ -27,8 +42,7 @@ struct regulator {
unsigned int always_on:1;
unsigned int bypass:1;
int uA_load;
- int min_uV;
- int max_uV;
+ struct regulator_voltage voltage[REGULATOR_STATES_NUM];
const char *supply_name;
struct device_attribute dev_attr;
struct regulator_dev *rdev;
--
2.7.4
--
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 1/5] bindings: regulator: added support for suspend states
From: Chunyan Zhang @ 2017-12-21 6:25 UTC (permalink / raw)
To: Mark Brown, Rob Herring
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Chunyan Zhang
In-Reply-To: <1513837506-26543-1-git-send-email-zhang.chunyan-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Documented a few new added properties which are used for supporting
regulator suspend states.
Signed-off-by: Chunyan Zhang <zhang.chunyan-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
Documentation/devicetree/bindings/regulator/regulator.txt | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/regulator/regulator.txt b/Documentation/devicetree/bindings/regulator/regulator.txt
index 378f6dc..618a322 100644
--- a/Documentation/devicetree/bindings/regulator/regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/regulator.txt
@@ -42,8 +42,15 @@ Optional properties:
- regulator-state-[mem/disk] node has following common properties:
- regulator-on-in-suspend: regulator should be on in suspend state.
- regulator-off-in-suspend: regulator should be off in suspend state.
- - regulator-suspend-microvolt: regulator should be set to this voltage
- in suspend.
+ - regulator-suspend-min-microvolt: minimum voltage may be set in
+ suspend state.
+ - regulator-suspend-max-microvolt: maximum voltage may be set in
+ suspend state.
+ - regulator-suspend-microvolt: the default voltage which regulator
+ should be set in suspend, this can be adjusted among
+ <regulator-suspend-min-microvolt, regulator-suspend-max-microvolt>
+ - regulator-changeable-in-suspend: whether the default voltage and
+ the regulator on/off in suspend can be changed in runtime.
- regulator-mode: operating mode in the given suspend state.
The set of possible operating modes depends on the capabilities of
every hardware so the valid modes are documented on each regulator
--
2.7.4
--
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 0/5] Add regulator suspend and resume support
From: Chunyan Zhang @ 2017-12-21 6:25 UTC (permalink / raw)
To: Mark Brown, Rob Herring
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Chunyan Zhang
Some systems need to set regulators to specific states when they enter low
power modes, especially around CPUs.
Currently the regulator driver, for suspend and resume features, provides
two functions which are exported for being called directly by any modules
or subsystems when they thought the regulator should be entering into
suspend states.
This patchset adds hooks to PM suspend core and provides suspend/resume
callback functions to regulator device, for those who can be switched
off or set low voltage in suspend states only need to implement the
callback functions in the driver, and set the right configurations for
suspend states via device tree and the APIs which regulator core
driver provides.
Those drivers who use the old interfaces - i.e. regulator_suspend_prepare()
and regulator_suspend_finish() should stop using that, since we leave these
two functions empty and plan to remove them one day in the future.
Any comments would be greatly appreciated.
Thanks,
Chunyan
Chunyan Zhang (5):
bindings: regulator: added support for suspend states
regulator: make regulator voltage be an array to support more states
drivers: regulator: leave one item to record whether regulator is
enabled
drivers: regulator: empty the old suspend functions
regulator: add PM suspend and resume hooks
.../devicetree/bindings/regulator/regulator.txt | 11 +-
drivers/regulator/core.c | 342 ++++++++++++++-------
drivers/regulator/internal.h | 18 +-
drivers/regulator/of_regulator.c | 18 +-
include/linux/regulator/driver.h | 2 +
include/linux/regulator/machine.h | 31 +-
6 files changed, 299 insertions(+), 123 deletions(-)
--
2.7.4
--
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] Documentation: binding: Update endianness usage
From: Prabhakar Kushwaha @ 2017-12-21 5:20 UTC (permalink / raw)
To: Prabhakar Kushwaha, Scott Wood,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: dedekind1-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
In-Reply-To: <HE1PR04MB124174461F845000614CDAA197320-6LN7OEpIatU9TB6uw0n1oM9NdZoXdze2vxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
Hi Scott,
> -----Original Message-----
> From: devicetree-owner@vger.kernel.org [mailto:devicetree-
> owner@vger.kernel.org] On Behalf Of Prabhakar Kushwaha
> Sent: Wednesday, December 06, 2017 4:29 PM
> To: Scott Wood <oss@buserror.net>; linux-mtd@lists.infradead.org;
> devicetree@vger.kernel.org
> Cc: dedekind1@gmail.com; computersforpeace@gmail.com
> Subject: RE: [PATCH] Documentation: binding: Update endianness usage
>
>
>
> > -----Original Message-----
> > From: Prabhakar Kushwaha
> > Sent: Wednesday, December 06, 2017 4:05 PM
> > To: 'Scott Wood' <oss@buserror.net>; linux-mtd@lists.infradead.org;
> > devicetree@vger.kernel.org
> > Cc: dedekind1@gmail.com; computersforpeace@gmail.com
> > Subject: RE: [PATCH] Documentation: binding: Update endianness usage
> >
> >
> > > -----Original Message-----
> > > From: Scott Wood [mailto:oss@buserror.net]
> > > Sent: Wednesday, December 06, 2017 1:38 AM
> > > To: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; linux-
> > > mtd@lists.infradead.org; devicetree@vger.kernel.org
> > > Cc: dedekind1@gmail.com; computersforpeace@gmail.com
> > > Subject: Re: [PATCH] Documentation: binding: Update endianness usage
> > >
> > > On Tue, 2017-12-05 at 09:45 +0000, Prabhakar Kushwaha wrote:
> > > > > -----Original Message-----
> > > > > From: Scott Wood [mailto:oss@buserror.net]
> > > > > Sent: Tuesday, December 05, 2017 8:16 AM
> > > > > To: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; linux-
> > > > > mtd@lists.infradead.org; devicetree@vger.kernel.org
> > > > > Cc: dedekind1@gmail.com; computersforpeace@gmail.com
> > > > > Subject: Re: [PATCH] Documentation: binding: Update endianness usage
> > > > >
> > > > > I now see your patch to of_flash_probe... where is the non-IFC-specific
> > > > > binding that says the *parent* of a CFI node should be looked at for this?
> > > > > Where in general are endian properties kept in the parent of the node
> with
> > > > > "reg"? The right answer is to add endianness to mtd-physmap.txt.
> > > > >
> > > >
> > > > Flashes are always littler endian.
> > >
> > > We wouldn't be having this discussion if that were true... This is about how
> > > it presents to the CPU, not about how the actual pins on the chip are
> > > numbered.
> > >
> >
> > Got your point :)
> >
> > > > It is because of IFC controller behavior, endianness is required.
> > > > So as per my understanding, this info should go in IFC binding.
> > >
> > > If the info should go in the IFC binding why is the code in a non-IFC-specific
> > > place?
> > >
> >
> > Now I understand your point.
> > So I should be moving endianness property detail in mtd-physmap.txt.
> >
> > Is my understanding correct?
> >
>
> A second thought,
> IFC binding was updated because there is no IFC-NOR driver. It uses generic Flash
> framework.
>
> I am just trying to get more understanding.
>
Do you have any comment/concern on this patch.
May I go ahead and request for the merger of updated patch i.e. https://patchwork.kernel.org/patch/10084331/
--prabhakar
^ 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