* Re: [PATCH] v4l: async: make v4l2 coexists with devicetree nodes in a dt overlay
From: Javi Merino @ 2016-11-23 16:03 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: linux-media, linux-kernel, devicetree, Pantelis Antoniou,
Mauro Carvalho Chehab, Sakari Ailus
In-Reply-To: <cf31105b-e8c1-4379-cd03-0bdcbdea64d6@osg.samsung.com>
On Wed, Nov 23, 2016 at 11:25:39AM -0300, Javier Martinez Canillas wrote:
> Hello Javi,
>
> On 11/23/2016 07:09 AM, Javi Merino wrote:
> > In asd's configured with V4L2_ASYNC_MATCH_OF, if the v4l2 subdev is in
> > a devicetree overlay, its of_node pointer will be different each time
> > the overlay is applied. We are not interested in matching the
> > pointer, what we want to match is that the path is the one we are
> > expecting. Change to use of_node_cmp() so that we continue matching
> > after the overlay has been removed and reapplied.
> >
>
> I'm still not that familiar with DT overlays (and I guess others aren't
> either) so I think that including an example of a base tree and overlay
> DTS where this is an issue, could make things more clear in the commit.
>
> IIUC, it should be something like this?
>
> -- base tree --
>
> &i2c1 {
> camera: camera@10 {
> reg = <0x10>;
> port {
> cam_ep: endpoint {
> ...
> };
> };
> };
> };
>
> &media_bridge {
> ...
> ports {
> port@0 {
> reg = <0>;
> ep: endpoint {
> remote-endpoint = <&cam_ep>;
> };
> };
> };
> };
>
> -- overlay --
>
> /plugin/;
> / {
> ...
> fragment@0 {
> target = <&camera>;
> __overlay__ {
> compatible = "foo,bar";
> ...
> port {
> cam_ep: endpoint {
> ...
> };
> };
> };
> }
> }
Yes, that's right. What I have is that the whole camera can be
plugged or unplugged, so the overlay adds/removes the camera node:
/ {
fragment@0 {
target-path = "/i2c0";
__overlay__ {
my_cam {
compatible = "foo,bar";
port {
camera0: endpoint {
remote-endpoint = <&vin2a>;
...
};
};
};
};
};
I will add it to the commit message.
> > Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
> > Cc: Javier Martinez Canillas <javier@osg.samsung.com>
> > Cc: Sakari Ailus <sakari.ailus@linux.intel.com>
> > Signed-off-by: Javi Merino <javi.merino@kernel.org>
> > ---
> > Hi,
> >
> > I feel it is a bit of a hack, but I couldn't think of anything better.
> > I'm ccing devicetree@ and Pantelis because there may be a simpler
> > solution.
> >
>
> I also couldn't think a better way to do this, since IIUC the node's name is
> the only thing that doesn't change, and is available at the time the bridge
> driver calls v4l2_async_notifier_register() when parsing the base tree.
>
> > drivers/media/v4l2-core/v4l2-async.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/media/v4l2-core/v4l2-async.c b/drivers/media/v4l2-core/v4l2-async.c
> > index 5bada20..d33a17c 100644
> > --- a/drivers/media/v4l2-core/v4l2-async.c
> > +++ b/drivers/media/v4l2-core/v4l2-async.c
> > @@ -42,7 +42,8 @@ static bool match_devname(struct v4l2_subdev *sd,
> >
> > static bool match_of(struct v4l2_subdev *sd, struct v4l2_async_subdev *asd)
> > {
> > - return sd->of_node == asd->match.of.node;
> > + return !of_node_cmp(of_node_full_name(sd->of_node),
> > + of_node_full_name(asd->match.of.node));
> > }
> >
> > static bool match_custom(struct v4l2_subdev *sd, struct v4l2_async_subdev *asd)
> >
>
> Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
>
> Best regards,
> --
> Javier Martinez Canillas
> Open Source Group
> Samsung Research America
^ permalink raw reply
* Re: [PATCH v2 4/5] arm: dts: am57xx-beagle-x15-common: Add overide powerhold property
From: Tony Lindgren @ 2016-11-23 16:08 UTC (permalink / raw)
To: Keerthy
Cc: Lee Jones, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-gpio-u79uwXL29TY76Z2rM5mHXA, nm-l0cyMroinI0,
t-kristo-l0cyMroinI0
In-Reply-To: <3a05871c-0512-8a84-4ac3-889c661c8638-l0cyMroinI0@public.gmane.org>
* Keerthy <j-keerthy-l0cyMroinI0@public.gmane.org> [161123 00:33]:
> On Wednesday 23 November 2016 02:03 PM, Lee Jones wrote:
> > On Wed, 23 Nov 2016, Keerthy wrote:
> > > On Tuesday 15 November 2016 05:38 AM, Tony Lindgren wrote:
> > > > * Keerthy <j-keerthy-l0cyMroinI0@public.gmane.org> [161109 21:10]:
> > > > > The PMICs have POWERHOLD set by default which prevents PMIC shutdown
> > > > > even on DEV_CTRL On bit set to 0 as the Powerhold has higher priority.
> > > > > So to enable pmic power off this property lets one over ride the default
> > > > > value and enable pmic power off.
> > > >
> > > > This should not cause merge conflicts so probably best to merge along
> > > > with the driver changes:
> > > >
> > > > Acked-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
> > > >
> > > > If you guys want me to pick up this separately let me know.
> > >
> > > Hi Lee Jones,
> > >
> > > Are you planning to pull DT and Documentation patches as well?
> >
> > No need. They can be safely applied to their own subsystems.
>
> Okay. Thanks for the response.
>
> Tony,
>
> Hope you can pull the DT patches.
Applying both into omap-for-v4.10/dt thanks. Please send dts changes
seprately next time if there are no dependencies. This leaves out
the second guessing who should apply what.
Regards,
Tony
--
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] v4l: async: make v4l2 coexists with devicetree nodes in a dt overlay
From: Javi Merino @ 2016-11-23 16:15 UTC (permalink / raw)
To: Sakari Ailus
Cc: linux-media, linux-kernel, devicetree, Pantelis Antoniou,
Mauro Carvalho Chehab, Javier Martinez Canillas, Sakari Ailus
In-Reply-To: <20161123151042.GD16630@valkosipuli.retiisi.org.uk>
On Wed, Nov 23, 2016 at 05:10:42PM +0200, Sakari Ailus wrote:
> Hi Javi,
Hi Sakari,
> On Wed, Nov 23, 2016 at 10:09:57AM +0000, Javi Merino wrote:
> > In asd's configured with V4L2_ASYNC_MATCH_OF, if the v4l2 subdev is in
> > a devicetree overlay, its of_node pointer will be different each time
> > the overlay is applied. We are not interested in matching the
> > pointer, what we want to match is that the path is the one we are
> > expecting. Change to use of_node_cmp() so that we continue matching
> > after the overlay has been removed and reapplied.
> >
> > Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
> > Cc: Javier Martinez Canillas <javier@osg.samsung.com>
> > Cc: Sakari Ailus <sakari.ailus@linux.intel.com>
> > Signed-off-by: Javi Merino <javi.merino@kernel.org>
> > ---
> > Hi,
> >
> > I feel it is a bit of a hack, but I couldn't think of anything better.
> > I'm ccing devicetree@ and Pantelis because there may be a simpler
> > solution.
>
> First I have to admit that I'm not an expert when it comes to DT overlays.
>
> That said, my understanding is that the sub-device and the async sub-device
> are supposed to point to the exactly same DT node. I wonder if there's
> actually anything wrong in the current code.
>
> If the overlay has changed between probing the driver for the async notifier
> and the async sub-device, there should be no match here, should there? The
> two nodes actually point to a node in a different overlay in that case.
Overlays are parts of the devicetree that can be added and removed.
When the overlay is applied, the camera driver is probed and does
v4l2_async_register_subdev(). However, v4l2_async_belongs() fails.
The problem is with comparing pointers. I haven't looked at the
implementation of overlays in detail, but what I see is that the
of_node pointer changes when you remove and reapply an overlay (I
guess it's dynamically allocated and when you remove the overlay, it's
freed).
Cheers,
Javi
> >
> > drivers/media/v4l2-core/v4l2-async.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/media/v4l2-core/v4l2-async.c b/drivers/media/v4l2-core/v4l2-async.c
> > index 5bada20..d33a17c 100644
> > --- a/drivers/media/v4l2-core/v4l2-async.c
> > +++ b/drivers/media/v4l2-core/v4l2-async.c
> > @@ -42,7 +42,8 @@ static bool match_devname(struct v4l2_subdev *sd,
> >
> > static bool match_of(struct v4l2_subdev *sd, struct v4l2_async_subdev *asd)
> > {
> > - return sd->of_node == asd->match.of.node;
> > + return !of_node_cmp(of_node_full_name(sd->of_node),
> > + of_node_full_name(asd->match.of.node));
> > }
> >
> > static bool match_custom(struct v4l2_subdev *sd, struct v4l2_async_subdev *asd)
>
> --
> Kind regards,
>
> Sakari Ailus
> e-mail: sakari.ailus@iki.fi XMPP: sailus@retiisi.org.uk
^ permalink raw reply
* Re: [PATCH v2] ARM: dts: da850: add the mstpri and ddrctl nodes
From: David Lechner @ 2016-11-23 16:19 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Kevin Hilman, Michael Turquette, Sekhar Nori, Rob Herring,
Frank Rowand, Mark Rutland, Peter Ujfalusi, Russell King,
linux-devicetree, David Airlie, LKML, linux-drm, Tomi Valkeinen,
Jyri Sarha, arm-soc, Laurent Pinchart
In-Reply-To: <CAMpxmJVqog0Fno_DO0NQKmVNvzu5d=3GOLk145wBmB-V70BLeg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 11/23/2016 04:27 AM, Bartosz Golaszewski wrote:
> 2016-11-22 23:23 GMT+01:00 David Lechner <david-nq/r/kbU++upp/zk7JDF2g@public.gmane.org>:
>> On 11/15/2016 05:00 AM, Bartosz Golaszewski wrote:
>>>
>>> Add the nodes for the MSTPRI configuration and DDR2/mDDR memory
>>> controller drivers to da850.dtsi.
>>>
>>> Signed-off-by: Bartosz Golaszewski <bgolaszewski-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
>>> ---
>>> v1 -> v2:
>>> - moved the priority controller node above the cfgchip node
>>> - renamed added nodes to better reflect their purpose
>>>
>>> arch/arm/boot/dts/da850.dtsi | 8 ++++++++
>>> 1 file changed, 8 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
>>> index 1bb1f6d..412eec6 100644
>>> --- a/arch/arm/boot/dts/da850.dtsi
>>> +++ b/arch/arm/boot/dts/da850.dtsi
>>> @@ -210,6 +210,10 @@
>>> };
>>>
>>> };
>>> + prictrl: priority-controller@14110 {
>>> + compatible = "ti,da850-mstpri";
>>> + reg = <0x14110 0x0c>;
>>
>>
>> I think we should add status = "disabled"; here and let boards opt in.
>>
>>> + };
>>> cfgchip: chip-controller@1417c {
>>> compatible = "ti,da830-cfgchip", "syscon",
>>> "simple-mfd";
>>> reg = <0x1417c 0x14>;
>>> @@ -451,4 +455,8 @@
>>> 1 0 0x68000000 0x00008000>;
>>> status = "disabled";
>>> };
>>> + memctrl: memory-controller@b0000000 {
>>> + compatible = "ti,da850-ddr-controller";
>>> + reg = <0xb0000000 0xe8>;
>>
>>
>> same here. status = "disabled";
>>
>>> + };
>>> };
>>>
>
> Hi David,
>
> I did that initially[1][2] and it was rejected by Kevin[3] and Laurent[4].
>
> FYI this patch has already been queued by Sekhar.
Thanks. I did not see those threads.
FYI to maintainers, having these enabled by default causes error
messages in the kernel log for other boards that are not supported by
the drivers. Since there is only one board that is supported and soon to
be 2 that are not, I would rather have this disabled by default to avoid
the error messages.
>
> Best regards,
> Bartosz Golaszewski
>
> [1] https://www.spinics.net/lists/arm-kernel/msg539638.html
> [2] http://www.spinics.net/lists/devicetree/msg148575.html
> [3] http://www.spinics.net/lists/devicetree/msg148667.html
> [4] http://www.spinics.net/lists/devicetree/msg148655.html
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 0/2] minor GXL and GXM improvements
From: Martin Blumenstingl @ 2016-11-23 16:20 UTC (permalink / raw)
To: linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
khilman-rdvid1DuHRBWk0Htik3J/w, carlo-KA+7E9HrN00dnm+yROfE0A
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, will.deacon-5wv7dgnIgG8,
catalin.marinas-5wv7dgnIgG8, mark.rutland-5wv7dgnIgG8,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, Martin Blumenstingl
This series adds SCPI support to GXL and GXM SoCs by moving the nodes
to meson-gx.dtsi. Additionally this updates the compatible string to
match the recent changes, see [0]
Now that we have SCPI support for GXM we can also use it to configure
the CPU cores using the SCPI DVFS clocks.
[0] http://lists.infradead.org/pipermail/linux-amlogic/2016-November/001632.html
Martin Blumenstingl (2):
ARM64: dts: meson-gx: move the SCPI and SRAM nodes to meson-gx
ARM64: dts: meson-gxm: add SCPI configuration for GXM
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 45 +++++++++++++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 57 -----------------------------
arch/arm64/boot/dts/amlogic/meson-gxm.dtsi | 9 +++++
3 files changed, 54 insertions(+), 57 deletions(-)
--
2.10.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 1/2] ARM64: dts: meson-gx: move the SCPI and SRAM nodes to meson-gx
From: Martin Blumenstingl @ 2016-11-23 16:20 UTC (permalink / raw)
To: linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
khilman-rdvid1DuHRBWk0Htik3J/w, carlo-KA+7E9HrN00dnm+yROfE0A
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, will.deacon-5wv7dgnIgG8,
catalin.marinas-5wv7dgnIgG8, mark.rutland-5wv7dgnIgG8,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, Martin Blumenstingl
In-Reply-To: <20161123162040.24843-1-martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
SCPI and SRAM are identical on GXBB and GXL. Moving the corresponding
nodes to meson-gx adds support for the thermal sensor on GXL based
devices.
While here, also rename the second compatible string because
"arm,legacy-scpi" was replaced by "arm,scpi-pre-1.0".
Signed-off-by: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
---
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 45 +++++++++++++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 57 -----------------------------
2 files changed, 45 insertions(+), 57 deletions(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index fc033c0..47ab306 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -65,6 +65,7 @@
reg = <0x0 0x0>;
enable-method = "psci";
next-level-cache = <&l2>;
+ clocks = <&scpi_dvfs 0>;
};
cpu1: cpu@1 {
@@ -73,6 +74,7 @@
reg = <0x0 0x1>;
enable-method = "psci";
next-level-cache = <&l2>;
+ clocks = <&scpi_dvfs 0>;
};
cpu2: cpu@2 {
@@ -81,6 +83,7 @@
reg = <0x0 0x2>;
enable-method = "psci";
next-level-cache = <&l2>;
+ clocks = <&scpi_dvfs 0>;
};
cpu3: cpu@3 {
@@ -89,6 +92,7 @@
reg = <0x0 0x3>;
enable-method = "psci";
next-level-cache = <&l2>;
+ clocks = <&scpi_dvfs 0>;
};
l2: l2-cache0 {
@@ -153,6 +157,28 @@
};
};
+ scpi {
+ compatible = "amlogic,meson-gxbb-scpi", "arm,scpi-pre-1.0";
+ mboxes = <&mailbox 1 &mailbox 2>;
+ shmem = <&cpu_scp_lpri &cpu_scp_hpri>;
+
+ clocks {
+ compatible = "arm,scpi-clocks";
+
+ scpi_dvfs: scpi_clocks@0 {
+ compatible = "arm,scpi-dvfs-clocks";
+ #clock-cells = <1>;
+ clock-indices = <0>;
+ clock-output-names = "vcpu";
+ };
+ };
+
+ scpi_sensors: sensors {
+ compatible = "arm,scpi-sensors";
+ #thermal-sensor-cells = <1>;
+ };
+ };
+
soc {
compatible = "simple-bus";
#address-cells = <2>;
@@ -264,6 +290,25 @@
#address-cells = <0>;
};
+ sram: sram@c8000000 {
+ compatible = "amlogic,meson-gxbb-sram", "mmio-sram";
+ reg = <0x0 0xc8000000 0x0 0x14000>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x0 0xc8000000 0x14000>;
+
+ cpu_scp_lpri: scp-shmem@0 {
+ compatible = "amlogic,meson-gxbb-scp-shmem";
+ reg = <0x13000 0x400>;
+ };
+
+ cpu_scp_hpri: scp-shmem@200 {
+ compatible = "amlogic,meson-gxbb-scp-shmem";
+ reg = <0x13400 0x400>;
+ };
+ };
+
aobus: aobus@c8100000 {
compatible = "simple-bus";
reg = <0x0 0xc8100000 0x0 0x100000>;
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
index ac5ad3b..76465e7 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
@@ -50,28 +50,6 @@
/ {
compatible = "amlogic,meson-gxbb";
- scpi {
- compatible = "amlogic,meson-gxbb-scpi";
- mboxes = <&mailbox 1 &mailbox 2>;
- shmem = <&cpu_scp_lpri &cpu_scp_hpri>;
-
- clocks {
- compatible = "arm,scpi-clocks";
-
- scpi_dvfs: scpi_clocks@0 {
- compatible = "arm,scpi-dvfs-clocks";
- #clock-cells = <1>;
- clock-indices = <0>;
- clock-output-names = "vcpu";
- };
- };
-
- scpi_sensors: sensors {
- compatible = "arm,scpi-sensors";
- #thermal-sensor-cells = <1>;
- };
- };
-
soc {
usb0_phy: phy@c0000000 {
compatible = "amlogic,meson-gxbb-usb2-phy";
@@ -93,25 +71,6 @@
status = "disabled";
};
- sram: sram@c8000000 {
- compatible = "amlogic,meson-gxbb-sram", "mmio-sram";
- reg = <0x0 0xc8000000 0x0 0x14000>;
-
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0 0x0 0xc8000000 0x14000>;
-
- cpu_scp_lpri: scp-shmem@0 {
- compatible = "amlogic,meson-gxbb-scp-shmem";
- reg = <0x13000 0x400>;
- };
-
- cpu_scp_hpri: scp-shmem@200 {
- compatible = "amlogic,meson-gxbb-scp-shmem";
- reg = <0x13400 0x400>;
- };
- };
-
usb0: usb@c9000000 {
compatible = "amlogic,meson-gxbb-usb", "snps,dwc2";
reg = <0x0 0xc9000000 0x0 0x40000>;
@@ -138,22 +97,6 @@
};
};
-&cpu0 {
- clocks = <&scpi_dvfs 0>;
-};
-
-&cpu1 {
- clocks = <&scpi_dvfs 0>;
-};
-
-&cpu2 {
- clocks = <&scpi_dvfs 0>;
-};
-
-&cpu3 {
- clocks = <&scpi_dvfs 0>;
-};
-
&cbus {
spifc: spi@8c80 {
compatible = "amlogic,meson-gxbb-spifc";
--
2.10.2
--
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 2/2] ARM64: dts: meson-gxm: add SCPI configuration for GXM
From: Martin Blumenstingl @ 2016-11-23 16:20 UTC (permalink / raw)
To: linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
khilman-rdvid1DuHRBWk0Htik3J/w, carlo-KA+7E9HrN00dnm+yROfE0A
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, will.deacon-5wv7dgnIgG8,
catalin.marinas-5wv7dgnIgG8, mark.rutland-5wv7dgnIgG8,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, Martin Blumenstingl
In-Reply-To: <20161123162040.24843-1-martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
This adds the SCPI DVFS clock index and configures the CPU cores
accordingly.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
---
arch/arm64/boot/dts/amlogic/meson-gxm.dtsi | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
index c1974bb..2b1d276e 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
@@ -85,6 +85,7 @@
reg = <0x0 0x100>;
enable-method = "psci";
next-level-cache = <&l2>;
+ clocks = <&scpi_dvfs 1>;
};
cpu5: cpu@101 {
@@ -93,6 +94,7 @@
reg = <0x0 0x101>;
enable-method = "psci";
next-level-cache = <&l2>;
+ clocks = <&scpi_dvfs 1>;
};
cpu6: cpu@102 {
@@ -101,6 +103,7 @@
reg = <0x0 0x102>;
enable-method = "psci";
next-level-cache = <&l2>;
+ clocks = <&scpi_dvfs 1>;
};
cpu7: cpu@103 {
@@ -109,6 +112,12 @@
reg = <0x0 0x103>;
enable-method = "psci";
next-level-cache = <&l2>;
+ clocks = <&scpi_dvfs 1>;
};
};
};
+
+&scpi_dvfs {
+ clock-indices = <0 1>;
+ clock-output-names = "vbig", "vlittle";
+};
--
2.10.2
--
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 2/3] pinctrl: New driver for TI DA8XX/OMAP-L138/AM18XX pinconf
From: David Lechner @ 2016-11-23 16:21 UTC (permalink / raw)
To: Sekhar Nori, Linus Walleij, Rob Herring, Mark Rutland,
Kevin Hilman
Cc: linux-gpio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Axel Haslam,
Alexandre Bailon, Bartosz Gołaszewski
In-Reply-To: <88b3d16b-6e5b-ea75-d770-35d9adc6c677-l0cyMroinI0@public.gmane.org>
On 11/23/2016 05:04 AM, Sekhar Nori wrote:
> On Wednesday 23 November 2016 08:59 AM, David Lechner wrote:
>> This adds a new driver for pinconf on TI DA8XX/OMAP-L138/AM18XX. These
>
> s/DA8XX/DA850/
>
>> SoCs have a separate controller for controlling pullup/pulldown groups.
>>
>> Signed-off-by: David Lechner <david-nq/r/kbU++upp/zk7JDF2g@public.gmane.org>
>
>> +static const char *da850_pupd_get_get_group_name(struct pinctrl_dev *pctldev,
>> + unsigned int selector)
>> +{
>> + return da850_pupd_group_names[selector];
>> +}
>> +
>> +static int da850_pupd_get_get_group_pins(struct pinctrl_dev *pctldev,
>> + unsigned int selector,
>> + const unsigned int **pins,
>> + unsigned int *num_pins)
>> +{
>> + *num_pins = 0;
>> +
>> + return 0;
>> +}
>
> usage of get_get_ in the function names above is odd.
Will fix (copy/paste error)
>
> Thanks,
> Sekhar
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 3/3] ARM: dts: da850: Add node for pullup/pulldown pinconf
From: David Lechner @ 2016-11-23 16:24 UTC (permalink / raw)
To: Sekhar Nori, Linus Walleij, Rob Herring, Mark Rutland,
Kevin Hilman
Cc: devicetree, Axel Haslam, Bartosz Gołaszewski, linux-kernel,
linux-gpio, Alexandre Bailon, linux-arm-kernel
In-Reply-To: <8c3e6535-4b79-9731-f801-c13f007e48ab@ti.com>
On 11/23/2016 05:12 AM, Sekhar Nori wrote:
> On Wednesday 23 November 2016 08:59 AM, David Lechner wrote:
>> This SoC has a separate pin controller for configuring pullup/pulldown
>> bias on groups of pins.
>>
>> Signed-off-by: David Lechner <david@lechnology.com>
>> ---
>> arch/arm/boot/dts/da850.dtsi | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
>> index 8945815..1c0224c 100644
>> --- a/arch/arm/boot/dts/da850.dtsi
>> +++ b/arch/arm/boot/dts/da850.dtsi
>> @@ -210,6 +210,11 @@
>> };
>>
>> };
>> + pinconf: pin-controller@22c00c {
>> + compatible = "ti,da850-pupd";
>> + reg = <0x22c00c 0x8>;
>> + status = "disabled";
>> + };
>
> Can you please place this below the i2c1 node. I am trying to keep the
> nodes sorted by unit address. I know thats broken in many places today,
> but lets add the new ones where they should eventually end up.
I can do this, but it seems that the predominant sorting pattern here is
to keep subsystems together (e.g. all i2c are together, all uart are
together, etc.)
Would a separate patch to sort everything by unit address to get this
cleaned up be acceptable?
>
> Thanks,
> Sekhar
>
^ permalink raw reply
* Applied "regulator: max77620: add documentation for MPOK property" to the regulator tree
From: Mark Brown @ 2016-11-23 16:31 UTC (permalink / raw)
Cc: Rob Herring, Lee Jones, Mark Brown
In-Reply-To: <1479297161-7705-2-git-send-email-vreddytalla-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
The patch
regulator: max77620: add documentation for MPOK property
has been applied to the regulator tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 983779235a4d08f94e8cda073200423e0ff01d2e Mon Sep 17 00:00:00 2001
From: Venkat Reddy Talla <vreddytalla-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Date: Thu, 17 Nov 2016 23:24:36 +0530
Subject: [PATCH] regulator: max77620: add documentation for MPOK property
Adding documentation for maxim,power-ok-control dts property
Signed-off-by: Venkat Reddy Talla <vreddytalla-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Acked-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Signed-off-by: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
Documentation/devicetree/bindings/mfd/max77620.txt | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/max77620.txt b/Documentation/devicetree/bindings/mfd/max77620.txt
index 2ad44f7e4880..9c16d51cc15b 100644
--- a/Documentation/devicetree/bindings/mfd/max77620.txt
+++ b/Documentation/devicetree/bindings/mfd/max77620.txt
@@ -106,6 +106,18 @@ Here supported time periods by device in microseconds are as follows:
MAX77620 supports 40, 80, 160, 320, 640, 1280, 2560 and 5120 microseconds.
MAX20024 supports 20, 40, 80, 160, 320, 640, 1280 and 2540 microseconds.
+-maxim,power-ok-control: configure map power ok bit
+ 1: Enables POK(Power OK) to control nRST_IO and GPIO1
+ POK function.
+ 0: Disables POK control.
+ if property missing, do not configure MPOK bit.
+ If POK mapping is enabled for GPIO1/nRST_IO then,
+ GPIO1/nRST_IO pins are HIGH only if all rails
+ that have POK control enabled are HIGH.
+ If any of the rails goes down(which are enabled for POK
+ control) then, GPIO1/nRST_IO goes LOW.
+ this property is valid for max20024 only.
+
For DT binding details of different sub modules like GPIO, pincontrol,
regulator, power, please refer respective device-tree binding document
under their respective sub-system directories.
--
2.10.2
--
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
* Applied "regulator: max77620: add support to configure MPOK" to the regulator tree
From: Mark Brown @ 2016-11-23 16:31 UTC (permalink / raw)
Cc: Lee Jones, Mark Brown
In-Reply-To: <1479405276-26452-1-git-send-email-vreddytalla@nvidia.com>
The patch
regulator: max77620: add support to configure MPOK
has been applied to the regulator tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 383d0fca7035a12f1201277d33e8fc87c9d60c9a Mon Sep 17 00:00:00 2001
From: Venkat Reddy Talla <vreddytalla@nvidia.com>
Date: Thu, 17 Nov 2016 23:24:35 +0530
Subject: [PATCH] regulator: max77620: add support to configure MPOK
Adding support to configure regulator POK mapping bit
to control nRST_IO and GPIO1 POK function.
In tegra based platform which uses MAX20024 pmic, when
some of regulators are configured FPS_NONE(flexible power sequencer)
causes PMIC GPIO1 to go low which lead to various other rails turning off,
to avoid this MPOK bit of those regulators need to be set to 0
so that PMIC GPIO1 will not go low.
Signed-off-by: Venkat Reddy Talla <vreddytalla@nvidia.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
drivers/regulator/max77620-regulator.c | 46 ++++++++++++++++++++++++++++++++++
include/linux/mfd/max77620.h | 2 ++
2 files changed, 48 insertions(+)
diff --git a/drivers/regulator/max77620-regulator.c b/drivers/regulator/max77620-regulator.c
index c39a56b41901..d088a7c79e60 100644
--- a/drivers/regulator/max77620-regulator.c
+++ b/drivers/regulator/max77620-regulator.c
@@ -80,6 +80,7 @@ struct max77620_regulator_pdata {
int suspend_fps_pd_slot;
int suspend_fps_pu_slot;
int current_mode;
+ int power_ok;
int ramp_rate_setting;
};
@@ -350,11 +351,48 @@ static int max77620_set_slew_rate(struct max77620_regulator *pmic, int id,
return 0;
}
+static int max77620_config_power_ok(struct max77620_regulator *pmic, int id)
+{
+ struct max77620_regulator_pdata *rpdata = &pmic->reg_pdata[id];
+ struct max77620_regulator_info *rinfo = pmic->rinfo[id];
+ struct max77620_chip *chip = dev_get_drvdata(pmic->dev->parent);
+ u8 val, mask;
+ int ret;
+
+ switch (chip->chip_id) {
+ case MAX20024:
+ if (rpdata->power_ok >= 0) {
+ if (rinfo->type == MAX77620_REGULATOR_TYPE_SD)
+ mask = MAX20024_SD_CFG1_MPOK_MASK;
+ else
+ mask = MAX20024_LDO_CFG2_MPOK_MASK;
+
+ val = rpdata->power_ok ? mask : 0;
+
+ ret = regmap_update_bits(pmic->rmap, rinfo->cfg_addr,
+ mask, val);
+ if (ret < 0) {
+ dev_err(pmic->dev, "Reg 0x%02x update failed %d\n",
+ rinfo->cfg_addr, ret);
+ return ret;
+ }
+ }
+ break;
+
+ default:
+ break;
+ }
+
+ return 0;
+}
+
static int max77620_init_pmic(struct max77620_regulator *pmic, int id)
{
struct max77620_regulator_pdata *rpdata = &pmic->reg_pdata[id];
int ret;
+ max77620_config_power_ok(pmic, id);
+
/* Update power mode */
ret = max77620_regulator_get_power_mode(pmic, id);
if (ret < 0)
@@ -594,6 +632,12 @@ static int max77620_of_parse_cb(struct device_node *np,
np, "maxim,suspend-fps-power-down-slot", &pval);
rpdata->suspend_fps_pd_slot = (!ret) ? pval : -1;
+ ret = of_property_read_u32(np, "maxim,power-ok-control", &pval);
+ if (!ret)
+ rpdata->power_ok = pval;
+ else
+ rpdata->power_ok = -1;
+
ret = of_property_read_u32(np, "maxim,ramp-rate-setting", &pval);
rpdata->ramp_rate_setting = (!ret) ? pval : 0;
@@ -806,6 +850,8 @@ static int max77620_regulator_resume(struct device *dev)
for (id = 0; id < MAX77620_NUM_REGS; id++) {
reg_pdata = &pmic->reg_pdata[id];
+ max77620_config_power_ok(pmic, id);
+
max77620_regulator_set_fps_slots(pmic, id, false);
if (reg_pdata->active_fps_src < 0)
continue;
diff --git a/include/linux/mfd/max77620.h b/include/linux/mfd/max77620.h
index 3ca0af07fc78..ad2a9a852aea 100644
--- a/include/linux/mfd/max77620.h
+++ b/include/linux/mfd/max77620.h
@@ -180,6 +180,7 @@
#define MAX77620_SD_CFG1_FPWM_SD_MASK BIT(2)
#define MAX77620_SD_CFG1_FPWM_SD_SKIP 0
#define MAX77620_SD_CFG1_FPWM_SD_FPWM BIT(2)
+#define MAX20024_SD_CFG1_MPOK_MASK BIT(1)
#define MAX77620_SD_CFG1_FSRADE_SD_MASK BIT(0)
#define MAX77620_SD_CFG1_FSRADE_SD_DISABLE 0
#define MAX77620_SD_CFG1_FSRADE_SD_ENABLE BIT(0)
@@ -187,6 +188,7 @@
/* LDO_CNFG2 */
#define MAX77620_LDO_POWER_MODE_MASK 0xC0
#define MAX77620_LDO_POWER_MODE_SHIFT 6
+#define MAX20024_LDO_CFG2_MPOK_MASK BIT(2)
#define MAX77620_LDO_CFG2_ADE_MASK BIT(1)
#define MAX77620_LDO_CFG2_ADE_DISABLE 0
#define MAX77620_LDO_CFG2_ADE_ENABLE BIT(1)
--
2.10.2
^ permalink raw reply related
* Re: [PATCH v2 1/2] regulator: max77620: add support to configure MPOK
From: Mark Brown @ 2016-11-23 16:40 UTC (permalink / raw)
To: Lee Jones
Cc: Venkat Reddy Talla, lgirdwood, robh+dt, mark.rutland, devicetree,
linux-kernel, ldewangan, svelpula
In-Reply-To: <20161121131121.GE3917@dell>
[-- Attachment #1: Type: text/plain, Size: 1291 bytes --]
On Mon, Nov 21, 2016 at 01:11:21PM +0000, Lee Jones wrote:
> Mark if you want to take this patch, feel free.
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git tags/regulator-max77620-mpok
for you to fetch changes up to 983779235a4d08f94e8cda073200423e0ff01d2e:
regulator: max77620: add documentation for MPOK property (2016-11-23 16:27:42 +0000)
----------------------------------------------------------------
regulator: max77620: Implement support for MPOK bit
Allow systems to configure the MPOK bit, controlling power OK signalling
from the device.
----------------------------------------------------------------
Venkat Reddy Talla (3):
regulator: max77620: remove unused variable
regulator: max77620: add support to configure MPOK
regulator: max77620: add documentation for MPOK property
Documentation/devicetree/bindings/mfd/max77620.txt | 12 ++++++
drivers/regulator/max77620-regulator.c | 47 +++++++++++++++++++++-
include/linux/mfd/max77620.h | 2 +
3 files changed, 60 insertions(+), 1 deletion(-)
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply
* Re: [PATCH 1/7] add binding for stm32 multifunctions timer driver
From: Benjamin Gaignard @ 2016-11-23 17:02 UTC (permalink / raw)
To: Lee Jones
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, Mark Rutland,
alexandre.torgue-qxv4g6HH51o, devicetree-u79uwXL29TY76Z2rM5mHXA,
Linux Kernel Mailing List, Thierry Reding,
linux-pwm-u79uwXL29TY76Z2rM5mHXA, jic23-DgEjT+Ai2ygdnm+yROfE0A,
knaack.h-Mmb7MZpHnFY, Lars-Peter Clausen, Peter Meerwald-Stadler,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Fabrice Gasnier, Gerald Baeza, Arnaud Pouliquen, Linus Walleij,
Linaro Kernel Mailman List, Benjamin Gaignard
In-Reply-To: <20161123092148.GO10134-Re9dqnLqz4GzQB+pC5nmwQ@public.gmane.org>
2016-11-23 10:21 GMT+01:00 Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>:
> On Wed, 23 Nov 2016, Benjamin Gaignard wrote:
>
>> 2016-11-22 17:52 GMT+01:00 Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>:
>> > On Tue, 22 Nov 2016, Benjamin Gaignard wrote:
>> >
>> >> Add bindings information for stm32 timer MFD
>> >>
>> >> Signed-off-by: Benjamin Gaignard <benjamin.gaignard-qxv4g6HH51o@public.gmane.org>
>> >> ---
>> >> .../devicetree/bindings/mfd/stm32-timer.txt | 53 ++++++++++++++++++++++
>> >> 1 file changed, 53 insertions(+)
>> >> create mode 100644 Documentation/devicetree/bindings/mfd/stm32-timer.txt
>> >>
>> >> diff --git a/Documentation/devicetree/bindings/mfd/stm32-timer.txt b/Documentation/devicetree/bindings/mfd/stm32-timer.txt
>> >> new file mode 100644
>> >> index 0000000..3cefce1
>> >> --- /dev/null
>> >> +++ b/Documentation/devicetree/bindings/mfd/stm32-timer.txt
>> >> @@ -0,0 +1,53 @@
>> >> +STM32 multifunctions timer driver
>> >
>> > "STM32 Multi-Function Timer/PWM device bindings"
>> >
>> > Doesn't this shared device have a better name?
>>
>> In SoC documentation those hardware blocks are named "advanced-control
>> timers", "general purpose timers" or "basic timers"
>> "stm32-timer" name is already used for clock source driver, that why I
>> have prefix it with mfd
>
> MFD is a Linuxisum and has no place in hardware description.
>
> Please used one of the names you mentioned above.
I will go for "st,stm32-advanced-timer"
>
> Hopefully the one that best fits.
>
>> >> +stm32 timer MFD allow to handle at the same time pwm and IIO timer devices
>> >
>> > No need for this sentence.
>> >
>> OK
>>
>> >> +Required parameters:
>> >> +- compatible: must be one of the follow value:
>> >> + "st,stm32-mfd-timer1"
>> >> + "st,stm32-mfd-timer2"
>> >> + "st,stm32-mfd-timer3"
>> >> + "st,stm32-mfd-timer4"
>> >> + "st,stm32-mfd-timer5"
>> >> + "st,stm32-mfd-timer6"
>> >> + "st,stm32-mfd-timer7"
>> >> + "st,stm32-mfd-timer8"
>> >> + "st,stm32-mfd-timer9"
>> >> + "st,stm32-mfd-timer10"
>> >> + "st,stm32-mfd-timer11"
>> >> + "st,stm32-mfd-timer12"
>> >> + "st,stm32-mfd-timer13"
>> >> + "st,stm32-mfd-timer14"
>> >
>> > We don't normally number devices.
>> >
>> > What's stopping you from simply doing:
>> >
>> > pwm1: pwm1@40010000 {
>> > compatible = "st,stm32-pwm";
>> > };
>> > pwm2: pwm1@40020000 {
>> > compatible = "st,stm32-pwm";
>> > };
>> > pwm3: pwm1@40030000 {
>> > compatible = "st,stm32-pwm";
>> > };
>> >
>>
>> Because each instance of the hardware is slightly different: number of
>> pwm channels, triggers capabilities, etc ..
>> so I need to distinguish them.
>> Since it look to be a problem I will follow your suggestion and add a
>> property this driver to be able to identify each instance.
>> Do you think that "id" parameter (integer for 1 to 14) is acceptable ?
>
> Unfortunately not. IDs aren't allowed in DT.
>
> What about "pwm-chans" and "trigger"?
>
> pwm-chans : Number of available channels available
For pwm I need those 4 properties:
st,pwm-number: the number of PWM devices
st,complementary: if exist have complementary ouput
st,32bit-counter: if exist have 32 bits counter
st,breakinput-polarity: if set enable break input feature.
Is it acceptable from pwm maintainer point of view ?
> trigger : Boolean value specifying whether a timer is present
Following our discussion on IRC I will try to code for your proposal:
advanced-timer@40010000 {
compatible = "st,stm32-advanced-timer";
reg = <0x40010000 0x400>;
clocks = <&rcc 0 160>;
clock-names = "clk_int";
pwm@0 {
compatible = "st,stm32-pwm";
st,pwm-number= <4>;
st,complementary;
st,breakinput;
};
timer@0 {
reg = <1>;
compatible = "st,stm32-iio-timer";
interrupts = <27>;
triggers = <5 2 3 4>;
};
};
triggers parameter will be used to know which trigger are valid for
the IIO device
[snip]
^ permalink raw reply
* Re: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06
From: Arnd Bergmann @ 2016-11-23 17:07 UTC (permalink / raw)
To: Gabriele Paoloni
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
mark.rutland-5wv7dgnIgG8@public.gmane.org,
benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org,
catalin.marinas-5wv7dgnIgG8@public.gmane.org,
liviu.dudau-5wv7dgnIgG8@public.gmane.org, Linuxarm,
lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org, xuwei (O),
Jason Gunthorpe,
linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
minyard-HInyCGIudOg@public.gmane.org,
will.deacon-5wv7dgnIgG8@public.gmane.org, John Garry, zourongrong
In-Reply-To: <EE11001F9E5DDD47B7634E2F8A612F2E1F931E08@lhreml507-mbx>
On Wednesday, November 23, 2016 3:22:33 PM CET Gabriele Paoloni wrote:
> From: Arnd Bergmann [mailto:arnd-r2nGTMty4D4@public.gmane.org]
> > On Friday, November 18, 2016 5:03:11 PM CET Gabriele Paoloni wrote:
> > > I think this is effectively what we are doing so far with patch 2/3.
> > > The problem with this patch is that we are carving out a "forbidden"
> > > IO tokens range that goes from 0 to PCIBIOS_MIN_IO.
> > >
> > > I think that the proper solution would be to have the LPC driver to
> > > set the carveout threshold used in pci_register_io_range(),
> > > pci_pio_to_address(), pci_address_to_pio(), but this would impose
> > > a probe dependency on the LPC itself that should be probed before
> > > the PCI controller (or before any other devices calling these
> > > functions...)
> >
> > Why do you think the order matters? My point was that we should
> > be able to register any region of logical port numbers for any
> > bus here.
>
> Maybe I have not followed well so let's roll back to your previous
> comment...
>
> "we need to associate a bus address with a logical Linux port number,
> both in of_address_to_resource and in inb()/outb()"
>
> Actually of_address_to_resource() returns the port number to used
> in inb/outb(); inb() and outb() add the port number to PCI_IOBASE
> to rd/wr to the right virtual address.
Correct.
> Our LPC cannot operate on the virtual address and it operates on
> a bus address range that for LPC is also equal to the cpu address
> range and goes from 0 to 0x1000.
There is no "cpu address" here, otherwise this is correct.
> Now as I understand it is risky and not appropriate to reserve
> the logical port numbers from 0 to 0x1000 or to whatever other
> upper bound because existing systems may rely on these port numbers
> retrieved by __of_address_to_resource().
Right again.
> In this scenario I think the best thing to do would be
> in the probe function of the LPC driver:
> 1) call pci_register_io_range() passing [0, 0x1000] (that is the
> range for LPC)
pci_register_io_range() takes a physical address, not a port number,
so that would not be appropriate as you say above. We can however
add a variant that reserves a range of port numbers in io_range_list
for an indirect access method.
> 2) retrieve the logical port numbers associated to the LPC range
> by calling pci_address_to_pio() for 0 and 0x1000 and assign
> them to extio_ops_node->start and extio_ops_node->end
Again, calling pci_address_to_pio() doesn't seem right here, because
we don't have a phys_addr_t address
> 3) implement the LPC accessors to operate on the logical ports
> associated to the LPC range (in practice in the accessors
> implementation we will call pci_pio_to_address to retrieve
> the cpu address to operate on)
Please don't proliferate the use of
pci_pio_to_address/pci_address_to_pio here, computing the physical
address from the logical address is trivial, you just need to
subtract the start of the range that you already use when matching
the port number range.
The only thing we need here is to make of_address_to_resource()
return the correct logical port number that was registered for
a given host device when asked to translate an address that
does not have a CPU address associated with it.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/2] gpio: axp209: add pinctrl support
From: kbuild test robot @ 2016-11-23 17:13 UTC (permalink / raw)
Cc: kbuild-all, linus.walleij, gnurou, robh+dt, mark.rutland, wens,
Quentin Schulz, linux-gpio, devicetree, linux-kernel,
thomas.petazzoni
In-Reply-To: <20161123132749.11666-3-quentin.schulz@free-electrons.com>
[-- Attachment #1: Type: text/plain, Size: 17845 bytes --]
Hi Quentin,
[auto build test ERROR on gpio/for-next]
[also build test ERROR on v4.9-rc6 next-20161123]
[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/Quentin-Schulz/add-support-for-AXP209-GPIOs-functions/20161124-003102
base: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git for-next
config: i386-randconfig-i0-201647 (attached as .config)
compiler: gcc-4.8 (Debian 4.8.4-1) 4.8.4
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All error/warnings (new ones prefixed by >>):
>> drivers/gpio/gpio-axp209.c:60:27: error: field 'pin' has incomplete type
struct pinctrl_pin_desc pin;
^
>> drivers/gpio/gpio-axp209.c:95:2: error: field name not in record or union initializer
AXP20X_PIN(AXP20X_PINCTRL_PIN(0, "GPIO0", (void *)AXP20X_GPIO0_CTRL),
^
drivers/gpio/gpio-axp209.c:95:2: error: (near initialization for 'axp209_pins[0].pin')
>> drivers/gpio/gpio-axp209.c:95:2: error: field name not in record or union initializer
drivers/gpio/gpio-axp209.c:95:2: error: (near initialization for 'axp209_pins[0].pin')
>> drivers/gpio/gpio-axp209.c:95:2: error: field name not in record or union initializer
drivers/gpio/gpio-axp209.c:95:2: error: (near initialization for 'axp209_pins[0].pin')
drivers/gpio/gpio-axp209.c:100:2: error: field name not in record or union initializer
AXP20X_PIN(AXP20X_PINCTRL_PIN(1, "GPIO1", (void *)AXP20X_GPIO1_CTRL),
^
drivers/gpio/gpio-axp209.c:100:2: error: (near initialization for 'axp209_pins[1].pin')
drivers/gpio/gpio-axp209.c:100:2: error: field name not in record or union initializer
drivers/gpio/gpio-axp209.c:100:2: error: (near initialization for 'axp209_pins[1].pin')
drivers/gpio/gpio-axp209.c:100:2: error: field name not in record or union initializer
drivers/gpio/gpio-axp209.c:100:2: error: (near initialization for 'axp209_pins[1].pin')
drivers/gpio/gpio-axp209.c:105:2: error: field name not in record or union initializer
AXP20X_PIN(AXP20X_PINCTRL_PIN(2, "GPIO2", (void *)AXP20X_GPIO2_CTRL),
^
drivers/gpio/gpio-axp209.c:105:2: error: (near initialization for 'axp209_pins[2].pin')
drivers/gpio/gpio-axp209.c:105:2: error: field name not in record or union initializer
drivers/gpio/gpio-axp209.c:105:2: error: (near initialization for 'axp209_pins[2].pin')
drivers/gpio/gpio-axp209.c:105:2: error: field name not in record or union initializer
drivers/gpio/gpio-axp209.c:105:2: error: (near initialization for 'axp209_pins[2].pin')
drivers/gpio/gpio-axp209.c: In function 'axp20x_gpio_get_direction':
>> drivers/gpio/gpio-axp209.c:131:49: error: request for member 'drv_data' in something not a structure or union
int pin_reg = (int)pctl->desc->pins[offset].pin.drv_data;
^
drivers/gpio/gpio-axp209.c: In function 'axp20x_gpio_set':
drivers/gpio/gpio-axp209.c:158:49: error: request for member 'drv_data' in something not a structure or union
int pin_reg = (int)pctl->desc->pins[offset].pin.drv_data;
^
drivers/gpio/gpio-axp209.c: In function 'axp20x_gpio_input':
>> drivers/gpio/gpio-axp209.c:168:2: error: implicit declaration of function 'pinctrl_gpio_direction_input' [-Werror=implicit-function-declaration]
return pinctrl_gpio_direction_input(chip->base + offset);
^
drivers/gpio/gpio-axp209.c: In function 'axp20x_pmx_set':
>> drivers/gpio/gpio-axp209.c:182:9: error: implicit declaration of function 'pinctrl_dev_get_drvdata' [-Werror=implicit-function-declaration]
struct axp20x_pctl *pctl = pinctrl_dev_get_drvdata(pctldev);
^
>> drivers/gpio/gpio-axp209.c:182:29: warning: initialization makes pointer from integer without a cast [enabled by default]
struct axp20x_pctl *pctl = pinctrl_dev_get_drvdata(pctldev);
^
drivers/gpio/gpio-axp209.c:183:49: error: request for member 'drv_data' in something not a structure or union
int pin_reg = (int)pctl->desc->pins[offset].pin.drv_data;
^
drivers/gpio/gpio-axp209.c: In function 'axp20x_pmx_func_cnt':
drivers/gpio/gpio-axp209.c:191:29: warning: initialization makes pointer from integer without a cast [enabled by default]
struct axp20x_pctl *pctl = pinctrl_dev_get_drvdata(pctldev);
^
drivers/gpio/gpio-axp209.c: In function 'axp20x_pmx_func_name':
drivers/gpio/gpio-axp209.c:199:29: warning: initialization makes pointer from integer without a cast [enabled by default]
struct axp20x_pctl *pctl = pinctrl_dev_get_drvdata(pctldev);
^
drivers/gpio/gpio-axp209.c: In function 'axp20x_pmx_func_groups':
drivers/gpio/gpio-axp209.c:209:29: warning: initialization makes pointer from integer without a cast [enabled by default]
struct axp20x_pctl *pctl = pinctrl_dev_get_drvdata(pctldev);
^
drivers/gpio/gpio-axp209.c: In function 'axp20x_pinctrl_desc_find_func_by_name':
>> drivers/gpio/gpio-axp209.c:228:23: error: request for member 'name' in something not a structure or union
if (!strcmp(pin->pin.name, group)) {
^
>> drivers/gpio/gpio-axp209.c:228:3: warning: passing argument 1 of 'strcmp' from incompatible pointer type [enabled by default]
if (!strcmp(pin->pin.name, group)) {
^
In file included from arch/x86/include/asm/string.h:2:0,
from include/linux/string.h:18,
from arch/x86/include/asm/page_32.h:34,
from arch/x86/include/asm/page.h:13,
from arch/x86/include/asm/processor.h:17,
from include/linux/mutex.h:19,
from include/linux/kernfs.h:13,
from include/linux/sysfs.h:15,
from include/linux/kobject.h:21,
from include/linux/device.h:17,
from drivers/gpio/gpio-axp209.c:14:
arch/x86/include/asm/string_32.h:21:12: note: expected 'const char *' but argument is of type 'const struct axp20x_desc_pin *'
extern int strcmp(const char *cs, const char *ct);
^
drivers/gpio/gpio-axp209.c: In function 'axp20x_pmx_set_mux':
drivers/gpio/gpio-axp209.c:253:29: warning: initialization makes pointer from integer without a cast [enabled by default]
struct axp20x_pctl *pctl = pinctrl_dev_get_drvdata(pctldev);
^
drivers/gpio/gpio-axp209.c: In function 'axp20x_pctl_desc_find_func_by_pin':
>> drivers/gpio/gpio-axp209.c:276:15: error: request for member 'number' in something not a structure or union
if (pin->pin.number == offset) {
^
>> drivers/gpio/gpio-axp209.c:276:23: warning: comparison between pointer and integer [enabled by default]
if (pin->pin.number == offset) {
^
drivers/gpio/gpio-axp209.c: At top level:
>> drivers/gpio/gpio-axp209.c:293:7: warning: 'struct pinctrl_gpio_range' declared inside parameter list [enabled by default]
unsigned int offset, bool input)
^
>> drivers/gpio/gpio-axp209.c:293:7: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]
drivers/gpio/gpio-axp209.c: In function 'axp20x_pmx_gpio_set_direction':
drivers/gpio/gpio-axp209.c:295:29: warning: initialization makes pointer from integer without a cast [enabled by default]
struct axp20x_pctl *pctl = pinctrl_dev_get_drvdata(pctldev);
^
drivers/gpio/gpio-axp209.c: At top level:
>> drivers/gpio/gpio-axp209.c:311:21: error: variable 'axp20x_pmx_ops' has initializer but incomplete type
static const struct pinmux_ops axp20x_pmx_ops = {
^
>> drivers/gpio/gpio-axp209.c:312:2: error: unknown field 'get_functions_count' specified in initializer
.get_functions_count = axp20x_pmx_func_cnt,
^
>> drivers/gpio/gpio-axp209.c:312:2: warning: excess elements in struct initializer [enabled by default]
drivers/gpio/gpio-axp209.c:312:2: warning: (near initialization for 'axp20x_pmx_ops') [enabled by default]
>> drivers/gpio/gpio-axp209.c:313:2: error: unknown field 'get_function_name' specified in initializer
.get_function_name = axp20x_pmx_func_name,
^
drivers/gpio/gpio-axp209.c:313:2: warning: excess elements in struct initializer [enabled by default]
drivers/gpio/gpio-axp209.c:313:2: warning: (near initialization for 'axp20x_pmx_ops') [enabled by default]
>> drivers/gpio/gpio-axp209.c:314:2: error: unknown field 'get_function_groups' specified in initializer
.get_function_groups = axp20x_pmx_func_groups,
^
drivers/gpio/gpio-axp209.c:314:2: warning: excess elements in struct initializer [enabled by default]
drivers/gpio/gpio-axp209.c:314:2: warning: (near initialization for 'axp20x_pmx_ops') [enabled by default]
>> drivers/gpio/gpio-axp209.c:315:2: error: unknown field 'set_mux' specified in initializer
.set_mux = axp20x_pmx_set_mux,
^
drivers/gpio/gpio-axp209.c:315:2: warning: excess elements in struct initializer [enabled by default]
drivers/gpio/gpio-axp209.c:315:2: warning: (near initialization for 'axp20x_pmx_ops') [enabled by default]
vim +/pin +60 drivers/gpio/gpio-axp209.c
8 * under the terms of the GNU General Public License as published by the
9 * Free Software Foundation; either version 2 of the License, or (at your
10 * option) any later version.
11 */
12
13 #include <linux/bitops.h>
> 14 #include <linux/device.h>
15 #include <linux/gpio/driver.h>
16 #include <linux/init.h>
17 #include <linux/interrupt.h>
18 #include <linux/kernel.h>
19 #include <linux/mfd/axp20x.h>
20 #include <linux/module.h>
21 #include <linux/of.h>
22 #include <linux/platform_device.h>
23 #include <linux/regmap.h>
24 #include <linux/slab.h>
25 #include <linux/pinctrl/pinctrl.h>
26 #include <linux/pinctrl/pinmux.h>
27 #include <linux/pinctrl/pinconf-generic.h>
28
29 #define AXP20X_GPIO_FUNCTIONS 0x7
30 #define AXP20X_GPIO_FUNCTION_OUT_LOW 0
31 #define AXP20X_GPIO_FUNCTION_OUT_HIGH 1
32 #define AXP20X_GPIO_FUNCTION_INPUT 2
33
34 #define AXP20X_PINCTRL_PIN(_pin_num, _pin, _regs) \
35 { \
36 .number = _pin_num, \
37 .name = _pin, \
38 .drv_data = _regs, \
39 }
40
41 #define AXP20X_PIN(_pin, ...) \
42 { \
43 .pin = _pin, \
44 .functions = (struct axp20x_desc_function[]) { \
45 __VA_ARGS__, { } }, \
46 }
47
48 #define AXP20X_FUNCTION(_val, _name) \
49 { \
50 .name = _name, \
51 .muxval = _val, \
52 }
53
54 struct axp20x_desc_function {
55 const char *name;
56 u8 muxval;
57 };
58
59 struct axp20x_desc_pin {
> 60 struct pinctrl_pin_desc pin;
61 struct axp20x_desc_function *functions;
62 };
63
64 struct axp20x_pinctrl_desc {
65 const struct axp20x_desc_pin *pins;
66 int npins;
67 unsigned int pin_base;
68 };
69
70 struct axp20x_pinctrl_function {
71 const char *name;
72 const char **groups;
73 unsigned int ngroups;
74 };
75
76 struct axp20x_pinctrl_group {
77 const char *name;
78 unsigned long config;
79 unsigned int pin;
80 };
81
82 struct axp20x_pctl {
83 struct pinctrl_dev *pctl_dev;
84 struct device *dev;
85 struct gpio_chip chip;
86 struct regmap *regmap;
87 const struct axp20x_pinctrl_desc *desc;
88 struct axp20x_pinctrl_group *groups;
89 unsigned int ngroups;
90 struct axp20x_pinctrl_function *functions;
91 unsigned int nfunctions;
92 };
93
94 static const struct axp20x_desc_pin axp209_pins[] = {
> 95 AXP20X_PIN(AXP20X_PINCTRL_PIN(0, "GPIO0", (void *)AXP20X_GPIO0_CTRL),
96 AXP20X_FUNCTION(0x0, "gpio_out"),
97 AXP20X_FUNCTION(0x2, "gpio_in"),
98 AXP20X_FUNCTION(0x3, "ldo"),
99 AXP20X_FUNCTION(0x4, "adc")),
100 AXP20X_PIN(AXP20X_PINCTRL_PIN(1, "GPIO1", (void *)AXP20X_GPIO1_CTRL),
101 AXP20X_FUNCTION(0x0, "gpio_out"),
102 AXP20X_FUNCTION(0x2, "gpio_in"),
103 AXP20X_FUNCTION(0x3, "ldo"),
104 AXP20X_FUNCTION(0x4, "adc")),
> 105 AXP20X_PIN(AXP20X_PINCTRL_PIN(2, "GPIO2", (void *)AXP20X_GPIO2_CTRL),
106 AXP20X_FUNCTION(0x0, "gpio_out"),
107 AXP20X_FUNCTION(0x2, "gpio_in")),
108 };
109
110 static const struct axp20x_pinctrl_desc axp20x_pinctrl_data = {
111 .pins = axp209_pins,
112 .npins = ARRAY_SIZE(axp209_pins),
113 };
114
115 static int axp20x_gpio_get(struct gpio_chip *chip, unsigned offset)
116 {
117 struct axp20x_pctl *pctl = gpiochip_get_data(chip);
118 unsigned int val;
119 int ret;
120
121 ret = regmap_read(pctl->regmap, AXP20X_GPIO20_SS, &val);
122 if (ret)
123 return ret;
124
125 return !!(val & BIT(offset + 4));
126 }
127
128 static int axp20x_gpio_get_direction(struct gpio_chip *chip, unsigned offset)
129 {
130 struct axp20x_pctl *pctl = gpiochip_get_data(chip);
> 131 int pin_reg = (int)pctl->desc->pins[offset].pin.drv_data;
132 unsigned int val;
133 int ret;
134
135 ret = regmap_read(pctl->regmap, pin_reg, &val);
136 if (ret)
137 return ret;
138
139 /*
140 * This shouldn't really happen if the pin is in use already,
141 * or if it's not in use yet, it doesn't matter since we're
142 * going to change the value soon anyway. Default to output.
143 */
144 if ((val & AXP20X_GPIO_FUNCTIONS) > 2)
145 return 0;
146
147 /*
148 * The GPIO directions are the three lowest values.
149 * 2 is input, 0 and 1 are output
150 */
151 return val & 2;
152 }
153
154 static void axp20x_gpio_set(struct gpio_chip *chip, unsigned int offset,
155 int value)
156 {
157 struct axp20x_pctl *pctl = gpiochip_get_data(chip);
> 158 int pin_reg = (int)pctl->desc->pins[offset].pin.drv_data;
159
160 regmap_update_bits(pctl->regmap, pin_reg,
161 AXP20X_GPIO_FUNCTIONS,
162 value ? AXP20X_GPIO_FUNCTION_OUT_HIGH
163 : AXP20X_GPIO_FUNCTION_OUT_LOW);
164 }
165
166 static int axp20x_gpio_input(struct gpio_chip *chip, unsigned int offset)
167 {
> 168 return pinctrl_gpio_direction_input(chip->base + offset);
169 }
170
171 static int axp20x_gpio_output(struct gpio_chip *chip, unsigned int offset,
172 int value)
173 {
174 chip->set(chip, offset, value);
175
176 return 0;
177 }
178
179 static int axp20x_pmx_set(struct pinctrl_dev *pctldev, unsigned int offset,
180 u8 config)
181 {
> 182 struct axp20x_pctl *pctl = pinctrl_dev_get_drvdata(pctldev);
183 int pin_reg = (int)pctl->desc->pins[offset].pin.drv_data;
184
185 return regmap_update_bits(pctl->regmap, pin_reg, AXP20X_GPIO_FUNCTIONS,
186 config);
187 }
188
189 static int axp20x_pmx_func_cnt(struct pinctrl_dev *pctldev)
190 {
191 struct axp20x_pctl *pctl = pinctrl_dev_get_drvdata(pctldev);
192
193 return pctl->nfunctions;
194 }
195
196 static const char *axp20x_pmx_func_name(struct pinctrl_dev *pctldev,
197 unsigned int selector)
198 {
> 199 struct axp20x_pctl *pctl = pinctrl_dev_get_drvdata(pctldev);
200
201 return pctl->functions[selector].name;
202 }
203
204 static int axp20x_pmx_func_groups(struct pinctrl_dev *pctldev,
205 unsigned int selector,
206 const char * const **groups,
207 unsigned int *num_groups)
208 {
> 209 struct axp20x_pctl *pctl = pinctrl_dev_get_drvdata(pctldev);
210
211 *groups = pctl->functions[selector].groups;
212 *num_groups = pctl->functions[selector].ngroups;
213
214 return 0;
215 }
216
217 static struct axp20x_desc_function *
218 axp20x_pinctrl_desc_find_func_by_name(struct axp20x_pctl *pctl,
219 const char *group, const char *func)
220 {
221 const struct axp20x_desc_pin *pin;
222 struct axp20x_desc_function *desc_func;
223 int i;
224
225 for (i = 0; i < pctl->desc->npins; i++) {
226 pin = &pctl->desc->pins[i];
227
> 228 if (!strcmp(pin->pin.name, group)) {
229 desc_func = pin->functions;
230
231 while (desc_func->name) {
232 if (!strcmp(desc_func->name, func))
233 return desc_func;
234 desc_func++;
235 }
236
237 /*
238 * Pins are uniquely named. Groups are named after one
239 * pin name. If one pin matches group name but its
240 * function cannot be found, no other pin will match
241 * group name.
242 */
243 return NULL;
244 }
245 }
246
247 return NULL;
248 }
249
250 static int axp20x_pmx_set_mux(struct pinctrl_dev *pctldev,
251 unsigned int function, unsigned int group)
252 {
> 253 struct axp20x_pctl *pctl = pinctrl_dev_get_drvdata(pctldev);
254 struct axp20x_pinctrl_group *g = pctl->groups + group;
255 struct axp20x_pinctrl_function *func = pctl->functions + function;
256 struct axp20x_desc_function *desc_func =
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 20700 bytes --]
^ permalink raw reply
* Re: [PATCH] ARM: dts: sunxi: Enable UEXT related nodes for Olimex A20 SOM EVB
From: Emmanuel Vadot @ 2016-11-23 17:16 UTC (permalink / raw)
To: Maxime Ripard
Cc: mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
wens-jdAy2FN1RRM, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20161123080350.fstwdfndghk7c5xx@lukather>
On Wed, 23 Nov 2016 09:03:50 +0100
Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> On Mon, Nov 21, 2016 at 05:49:11PM +0100, Emmanuel Vadot wrote:
> > UEXT are Universal EXTension connector from Olimex. They embed i2c, spi
> > and uart pins along power in one connector and are found on most,
> > if not all, Olimex boards.
> > The Olimex A20 SOM EVB have two UEXT connector so enable the nodes found on
> > those two connectors.
> >
> > Signed-off-by: Emmanuel Vadot <manu-xXdDKFdH5B3kFDPD4ZthVA@public.gmane.org>
>
> Fixed the indentation of the spi pinctrl cells, and applied.
>
> Please note that I'm note planning to send any new pull request, so
> this will likely end up in 4.11.
>
> Thanks!
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
Sorry about the indentation, I'll be more carefull next time.
Thank you.
--
Emmanuel Vadot <manu-xXdDKFdH5B3kFDPD4ZthVA@public.gmane.org> <manu-h+KGxgPPiopAfugRpC6u6w@public.gmane.org>
--
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] ARM: dts: exynos: specify snps,dwmac in compatible string for gmac
From: Krzysztof Kozlowski @ 2016-11-23 17:19 UTC (permalink / raw)
To: Niklas Cassel
Cc: Rob Herring, Mark Rutland, Russell King, Kukjin Kim,
Krzysztof Kozlowski, Javier Martinez Canillas, Niklas Cassel,
devicetree, linux-arm-kernel, linux-samsung-soc, linux-kernel
In-Reply-To: <1479911091-19812-1-git-send-email-niklass@axis.com>
On Wed, Nov 23, 2016 at 03:24:51PM +0100, Niklas Cassel wrote:
> From: Niklas Cassel <niklas.cassel@axis.com>
>
> devicetree binding for stmmac states:
> - compatible: Should be "snps,dwmac-<ip_version>", "snps,dwmac"
> For backwards compatibility: "st,spear600-gmac" is also supported.
>
> No functional change intended.
>
> Signed-off-by: Niklas Cassel <niklas.cassel@axis.com>
> ---
> arch/arm/boot/dts/exynos5440.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Thanks, applied.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] ARM: dts: exynos: remove the cd-gpios property for eMMC of odroid-xu3/4
From: Krzysztof Kozlowski @ 2016-11-23 17:20 UTC (permalink / raw)
To: Jaehoon Chung
Cc: Andrzej Hajda, Krzysztof Kozlowski, linux-samsung-soc,
linux-kernel, devicetree, kgene, cw00.choi, robh+dt, mark.rutland,
catalin.marinas, will.deacon, m.szyprowski, jy0922.shim
In-Reply-To: <00c4e163-98ed-fcc5-2248-22c697967032@samsung.com>
On Tue, Nov 22, 2016 at 05:19:30PM +0900, Jaehoon Chung wrote:
> On 11/22/2016 04:51 PM, Andrzej Hajda wrote:
> > On 22.11.2016 02:24, Jaehoon Chung wrote:
> >> On 11/22/2016 02:06 AM, Krzysztof Kozlowski wrote:
> >>> On Mon, Nov 21, 2016 at 04:10:32PM +0900, Jaehoon Chung wrote:
> >>>> Odroid-xu3/4 didn't need to use the cd-gpios for detecting card.
> >>>> Because Host controller has the CDETECT register through SDx_CDN line.
> >>>> Host controller can know whether card is inserted or not with this
> >>>> register.
> >>>>
> >>>> When i have checked the Odroid-xu3/4, they are using CDETECT register.
> >>>> (Not using exteranl cd-gpio.)
> >>> Makes sense. Just one question: the sd0_cd pinctrl setting should stay,
> >>> right?
Thanks, applied with removal of Fixes tag because commit description did
not mention any issue, error or wrong behavior to fix.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/2] gpio: axp209: add pinctrl support
From: kbuild test robot @ 2016-11-23 17:21 UTC (permalink / raw)
Cc: kbuild-all, linus.walleij, gnurou, robh+dt, mark.rutland, wens,
Quentin Schulz, linux-gpio, devicetree, linux-kernel,
thomas.petazzoni
In-Reply-To: <20161123132749.11666-3-quentin.schulz@free-electrons.com>
[-- Attachment #1: Type: text/plain, Size: 2834 bytes --]
Hi Quentin,
[auto build test WARNING on gpio/for-next]
[also build test WARNING on v4.9-rc6 next-20161123]
[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/Quentin-Schulz/add-support-for-AXP209-GPIOs-functions/20161124-003102
base: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git for-next
config: x86_64-randconfig-i0-201647 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
drivers/gpio/gpio-axp209.c: In function 'axp20x_gpio_get_direction':
>> drivers/gpio/gpio-axp209.c:131:16: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
int pin_reg = (int)pctl->desc->pins[offset].pin.drv_data;
^
drivers/gpio/gpio-axp209.c: In function 'axp20x_gpio_set':
drivers/gpio/gpio-axp209.c:158:16: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
int pin_reg = (int)pctl->desc->pins[offset].pin.drv_data;
^
drivers/gpio/gpio-axp209.c: In function 'axp20x_pmx_set':
drivers/gpio/gpio-axp209.c:183:16: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
int pin_reg = (int)pctl->desc->pins[offset].pin.drv_data;
^
drivers/gpio/gpio-axp209.c: At top level:
drivers/gpio/gpio-axp209.c:348:21: error: 'pinconf_generic_dt_node_to_map_group' undeclared here (not in a function)
.dt_node_to_map = pinconf_generic_dt_node_to_map_group,
^
drivers/gpio/gpio-axp209.c:349:18: error: 'pinconf_generic_dt_free_map' undeclared here (not in a function)
.dt_free_map = pinconf_generic_dt_free_map,
^
vim +131 drivers/gpio/gpio-axp209.c
115 static int axp20x_gpio_get(struct gpio_chip *chip, unsigned offset)
116 {
117 struct axp20x_pctl *pctl = gpiochip_get_data(chip);
118 unsigned int val;
119 int ret;
120
121 ret = regmap_read(pctl->regmap, AXP20X_GPIO20_SS, &val);
122 if (ret)
123 return ret;
124
125 return !!(val & BIT(offset + 4));
126 }
127
128 static int axp20x_gpio_get_direction(struct gpio_chip *chip, unsigned offset)
129 {
130 struct axp20x_pctl *pctl = gpiochip_get_data(chip);
> 131 int pin_reg = (int)pctl->desc->pins[offset].pin.drv_data;
132 unsigned int val;
133 int ret;
134
135 ret = regmap_read(pctl->regmap, pin_reg, &val);
136 if (ret)
137 return ret;
138
139 /*
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 33990 bytes --]
^ permalink raw reply
* Re: [PATCH] arm64: dts: exynos: enable hs400 mode for eMMC for TM2
From: Krzysztof Kozlowski @ 2016-11-23 17:29 UTC (permalink / raw)
To: Jaehoon Chung
Cc: linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, kgene-DgEjT+Ai2ygdnm+yROfE0A,
krzk-DgEjT+Ai2ygdnm+yROfE0A, cw00.choi-Sze3O3UU22JBDgjK7y7TUQ,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
catalin.marinas-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8,
m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ
In-Reply-To: <20161123074334.27784-1-jh80.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
On Wed, Nov 23, 2016 at 04:43:34PM +0900, Jaehoon Chung wrote:
> TM2 can support the HS400 mode, but eMMC is working as the lowest mode.
> This patch added the properties for HS400 and other modes.
>
> Signed-off-by: Jaehoon Chung <jh80.chung-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> ---
> arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 3 +++
> 1 file changed, 3 insertions(+)
>
Thanks, applied.
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] ALSA SoC MAX98927 driver - Initial release
From: kbuild test robot @ 2016-11-23 17:51 UTC (permalink / raw)
To: Ryan Lee
Cc: kbuild-all, lgirdwood, broonie, robh+dt, mark.rutland, perex,
tiwai, arnd, michael, oder_chiou, yesanishhere, jacob,
Damien.Horsley, bardliao, kuninori.morimoto.gx, petr, lars, nh6z,
ryans.lee, alsa-devel, devicetree, linux-kernel
In-Reply-To: <1479877026-5172-1-git-send-email-RyanS.Lee@maximintegrated.com>
[-- Attachment #1: Type: text/plain, Size: 6423 bytes --]
Hi Ryan,
[auto build test ERROR on asoc/for-next]
[also build test ERROR on v4.9-rc6 next-20161123]
[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/Ryan-Lee/ALSA-SoC-MAX98927-driver-Initial-release/20161124-004840
base: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
config: i386-allmodconfig (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
All error/warnings (new ones prefixed by >>):
>> sound/soc/codecs/max98927.c:755:2: error: unknown field 'dapm_routes' specified in initializer
.dapm_routes = max98927_audio_map,
^
>> sound/soc/codecs/max98927.c:755:17: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
.dapm_routes = max98927_audio_map,
^~~~~~~~~~~~~~~~~~
sound/soc/codecs/max98927.c:755:17: note: (near initialization for 'soc_codec_dev_max98927.remove')
>> sound/soc/codecs/max98927.c:756:2: error: unknown field 'num_dapm_routes' specified in initializer
.num_dapm_routes = ARRAY_SIZE(max98927_audio_map),
^
In file included from include/linux/delay.h:10:0,
from sound/soc/codecs/max98927.c:13:
>> include/linux/kernel.h:53:25: warning: initialization makes pointer from integer without a cast [-Wint-conversion]
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr))
^
>> sound/soc/codecs/max98927.c:756:21: note: in expansion of macro 'ARRAY_SIZE'
.num_dapm_routes = ARRAY_SIZE(max98927_audio_map),
^~~~~~~~~~
include/linux/kernel.h:53:25: note: (near initialization for 'soc_codec_dev_max98927.suspend')
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr))
^
>> sound/soc/codecs/max98927.c:756:21: note: in expansion of macro 'ARRAY_SIZE'
.num_dapm_routes = ARRAY_SIZE(max98927_audio_map),
^~~~~~~~~~
>> sound/soc/codecs/max98927.c:757:2: error: unknown field 'dapm_widgets' specified in initializer
.dapm_widgets = max98927_dapm_widgets,
^
sound/soc/codecs/max98927.c:757:18: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
.dapm_widgets = max98927_dapm_widgets,
^~~~~~~~~~~~~~~~~~~~~
sound/soc/codecs/max98927.c:757:18: note: (near initialization for 'soc_codec_dev_max98927.resume')
>> sound/soc/codecs/max98927.c:758:2: error: unknown field 'num_dapm_widgets' specified in initializer
.num_dapm_widgets = ARRAY_SIZE(max98927_dapm_widgets),
^
In file included from include/linux/delay.h:10:0,
from sound/soc/codecs/max98927.c:13:
>> include/linux/kernel.h:53:25: warning: initialization makes pointer from integer without a cast [-Wint-conversion]
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr))
^
sound/soc/codecs/max98927.c:758:22: note: in expansion of macro 'ARRAY_SIZE'
.num_dapm_widgets = ARRAY_SIZE(max98927_dapm_widgets),
^~~~~~~~~~
include/linux/kernel.h:53:25: note: (near initialization for 'soc_codec_dev_max98927.component_driver.name')
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr))
^
sound/soc/codecs/max98927.c:758:22: note: in expansion of macro 'ARRAY_SIZE'
.num_dapm_widgets = ARRAY_SIZE(max98927_dapm_widgets),
^~~~~~~~~~
>> sound/soc/codecs/max98927.c:759:2: error: unknown field 'controls' specified in initializer
.controls = max98927_snd_controls,
^
sound/soc/codecs/max98927.c:759:14: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
.controls = max98927_snd_controls,
^~~~~~~~~~~~~~~~~~~~~
sound/soc/codecs/max98927.c:759:14: note: (near initialization for 'soc_codec_dev_max98927.set_sysclk')
>> sound/soc/codecs/max98927.c:760:2: error: unknown field 'num_controls' specified in initializer
.num_controls = ARRAY_SIZE(max98927_snd_controls),
^
In file included from include/linux/delay.h:10:0,
from sound/soc/codecs/max98927.c:13:
>> include/linux/kernel.h:53:25: warning: initialization makes pointer from integer without a cast [-Wint-conversion]
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr))
^
sound/soc/codecs/max98927.c:760:18: note: in expansion of macro 'ARRAY_SIZE'
.num_controls = ARRAY_SIZE(max98927_snd_controls),
^~~~~~~~~~
include/linux/kernel.h:53:25: note: (near initialization for 'soc_codec_dev_max98927.set_pll')
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr))
^
sound/soc/codecs/max98927.c:760:18: note: in expansion of macro 'ARRAY_SIZE'
.num_controls = ARRAY_SIZE(max98927_snd_controls),
^~~~~~~~~~
>> sound/soc/codecs/max98927.c:753:67: warning: missing braces around initializer [-Wmissing-braces]
static const struct snd_soc_codec_driver soc_codec_dev_max98927 = {
^
sound/soc/codecs/max98927.c:753:67: note: (near initialization for 'soc_codec_dev_max98927')
cc1: some warnings being treated as errors
vim +/dapm_routes +755 sound/soc/codecs/max98927.c
747
748 max98927_handle_pdata(codec);
749
750 return ret;
751 }
752
> 753 static const struct snd_soc_codec_driver soc_codec_dev_max98927 = {
754 .probe = max98927_probe,
> 755 .dapm_routes = max98927_audio_map,
> 756 .num_dapm_routes = ARRAY_SIZE(max98927_audio_map),
> 757 .dapm_widgets = max98927_dapm_widgets,
> 758 .num_dapm_widgets = ARRAY_SIZE(max98927_dapm_widgets),
> 759 .controls = max98927_snd_controls,
> 760 .num_controls = ARRAY_SIZE(max98927_snd_controls),
761 };
762
763 static const struct regmap_config max98927_regmap = {
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 56946 bytes --]
^ permalink raw reply
* [PATCHv7 4/5] USB: ohci: da8xx: Add devicetree bindings
From: Axel Haslam @ 2016-11-23 18:06 UTC (permalink / raw)
To: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, nsekhar-l0cyMroinI0,
khilman-rdvid1DuHRBWk0Htik3J/w, david-nq/r/kbU++upp/zk7JDF2g,
ptitiano-rdvid1DuHRBWk0Htik3J/w
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, Axel Haslam,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161123180649.6438-1-ahaslam-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
This patch documents the device tree bindings required for
the ohci controller found in TI da8xx family of SoC's
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org
Cc: mark.rutland-5wv7dgnIgG8@public.gmane.org
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Signed-off-by: Axel Haslam <ahaslam-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
---
.../devicetree/bindings/usb/ohci-da8xx.txt | 23 ++++++++++++++++++++++
1 file changed, 23 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/ohci-da8xx.txt
diff --git a/Documentation/devicetree/bindings/usb/ohci-da8xx.txt b/Documentation/devicetree/bindings/usb/ohci-da8xx.txt
new file mode 100644
index 0000000..2dc8f67
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/ohci-da8xx.txt
@@ -0,0 +1,23 @@
+DA8XX USB OHCI controller
+
+Required properties:
+
+ - compatible: Should be "ti,da830-ohci"
+ - reg: Should contain one register range i.e. start and length
+ - interrupts: Description of the interrupt line
+ - phys: Phandle for the PHY device
+ - phy-names: Should be "usb-phy"
+
+Optional properties:
+ - vbus-supply: phandle of regulator that controls vbus power / over-current
+
+Example:
+
+ohci: usb@0225000 {
+ compatible = "ti,da830-ohci";
+ reg = <0x225000 0x1000>;
+ interrupts = <59>;
+ phys = <&usb_phy 1>;
+ phy-names = "usb-phy";
+ vbus-supply = <®_usb_ohci>;
+};
--
2.9.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 related
* Re: [PATCH v2 1/5] ARM: memory: da8xx-ddrctl: new driver
From: Frank Rowand @ 2016-11-23 18:13 UTC (permalink / raw)
To: Sekhar Nori, Bartosz Golaszewski, Kevin Hilman, Michael Turquette,
Rob Herring, Mark Rutland, Peter Ujfalusi, Russell King
Cc: LKML, arm-soc, linux-drm, linux-devicetree, Jyri Sarha,
Tomi Valkeinen, David Airlie, Laurent Pinchart, Sudeep Holla
In-Reply-To: <b668871c-2b54-0a2f-0d68-afaa50e17e63-l0cyMroinI0@public.gmane.org>
On 11/22/16 21:55, Sekhar Nori wrote:
> On Tuesday 22 November 2016 11:51 PM, Frank Rowand wrote:
>> Please note that the compatible property might contain several strings, not just
>> a single string.
>
> So I guess the best thing to do is to use
> of_property_read_string_index() and print the sting at index 0.
>
> Thanks,
> Sekhar
If you want to print just one compatible value, you could use that method.
To give all of the information needed to understand the problem, the error
message would need to include all of the strings contained in the compatible
property and all of the .board values in the da8xx_ddrctl_board_confs[] array
(currently only one entry, but coded to allow additional entries in the
future).
It is hard to justify an error message that complex.
I would just print an error that no match was found.
-Frank
--
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] ALSA SoC MAX98927 driver - Initial release
From: kbuild test robot @ 2016-11-23 18:13 UTC (permalink / raw)
To: Ryan Lee
Cc: kbuild-all-JC7UmRfGjtg, lgirdwood-Re5JQEeQqe8AvxtiuMwx3w,
broonie-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, perex-/Fr2/VpizcU, tiwai-IBi9RG/b67k,
arnd-r2nGTMty4D4, michael-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/,
oder_chiou-Rasf1IRRPZFBDgjK7y7TUQ,
yesanishhere-Re5JQEeQqe8AvxtiuMwx3w,
jacob-EZCvousvhKUZux3j3Bed6dkegs52MxvZ,
Damien.Horsley-1AXoQHu6uovQT0dZR+AlfA,
bardliao-Rasf1IRRPZFBDgjK7y7TUQ,
kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ,
petr-Qh/3xLP0EvwAvxtiuMwx3w, lars-Qo5EllUWu/uELgA04lAiVw,
nh6z-fFIq/eER6g8, ryans.lee-zxKO94PEStzToO697jQleEEOCMrvLtNR,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1479877026-5172-1-git-send-email-RyanS.Lee-zxKO94PEStzToO697jQleEEOCMrvLtNR@public.gmane.org>
Hi Ryan,
[auto build test WARNING on asoc/for-next]
[also build test WARNING on v4.9-rc6 next-20161123]
[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/Ryan-Lee/ALSA-SoC-MAX98927-driver-Initial-release/20161124-004840
base: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
coccinelle warnings: (new ones prefixed by >>)
>> sound/soc/codecs/max98927.c:941:3-8: No need to set .owner here. The core will do it.
Please review and possibly fold the followup patch.
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] fix platform_no_drv_owner.cocci warnings
From: kbuild test robot @ 2016-11-23 18:13 UTC (permalink / raw)
To: Ryan Lee
Cc: kbuild-all, lgirdwood, broonie, robh+dt, mark.rutland, perex,
tiwai, arnd, michael, oder_chiou, yesanishhere, jacob,
Damien.Horsley, bardliao, kuninori.morimoto.gx, petr, lars, nh6z,
ryans.lee, alsa-devel, devicetree, linux-kernel
In-Reply-To: <1479877026-5172-1-git-send-email-RyanS.Lee@maximintegrated.com>
sound/soc/codecs/max98927.c:941:3-8: No need to set .owner here. The core will do it.
Remove .owner field if calls are used which set it automatically
Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
CC: Ryan Lee <RyanS.Lee@maximintegrated.com>
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
---
max98927.c | 1 -
1 file changed, 1 deletion(-)
--- a/sound/soc/codecs/max98927.c
+++ b/sound/soc/codecs/max98927.c
@@ -938,7 +938,6 @@ MODULE_DEVICE_TABLE(of, max98927_of_matc
static struct i2c_driver max98927_i2c_driver = {
.driver = {
.name = "max98927",
- .owner = THIS_MODULE,
.of_match_table = of_match_ptr(max98927_of_match),
.pm = NULL,
},
^ 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