* Re: [PATCH linux 5/6] hwmon: occ: Add hwmon implementation for the P8 OCC
From: Rob Herring @ 2017-01-03 22:45 UTC (permalink / raw)
To: eajames.ibm
Cc: linux, jdelvare, corbet, mark.rutland, wsa, andrew, joel,
devicetree, linux-doc, linux-hwmon, linux-i2c, linux-kernel,
Edward A. James
In-Reply-To: <1483120568-21082-6-git-send-email-eajames.ibm@gmail.com>
On Fri, Dec 30, 2016 at 11:56:07AM -0600, eajames.ibm@gmail.com wrote:
> From: "Edward A. James" <eajames@us.ibm.com>
>
> Add code to tie the hwmon sysfs code and the POWER8 OCC code together, as
> well as probe the entire driver from the I2C bus. I2C is the communication
> method between the BMC and the P8 OCC.
>
> Signed-off-by: Edward A. James <eajames@us.ibm.com>
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
> ---
> .../devicetree/bindings/i2c/i2c-ibm-occ.txt | 13 ++
bindings/i2c/ is generally for host controllers. bindings/hwmon perhaps.
> drivers/hwmon/occ/Kconfig | 14 ++
> drivers/hwmon/occ/Makefile | 1 +
> drivers/hwmon/occ/p8_occ_i2c.c | 141 +++++++++++++++++++++
> 4 files changed, 169 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/i2c/i2c-ibm-occ.txt
> create mode 100644 drivers/hwmon/occ/p8_occ_i2c.c
>
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-ibm-occ.txt b/Documentation/devicetree/bindings/i2c/i2c-ibm-occ.txt
> new file mode 100644
> index 0000000..b0d2b36
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i2c/i2c-ibm-occ.txt
> @@ -0,0 +1,13 @@
> +HWMON I2C driver for IBM POWER CPU OCC (On Chip Controller)
> +
> +Required properties:
> + - compatible: must be "ibm,p8-occ-i2c"
> + - reg: physical address
> +
> +Example:
> +i2c3: i2c-bus@100 {
> + occ@50 {
> + compatible = "ibm,p8-occ-i2c";
> + reg = <0x50>;
> + };
> +};
> diff --git a/drivers/hwmon/occ/Kconfig b/drivers/hwmon/occ/Kconfig
> index cdb64a7..3a5188f 100644
> --- a/drivers/hwmon/occ/Kconfig
> +++ b/drivers/hwmon/occ/Kconfig
> @@ -13,3 +13,17 @@ menuconfig SENSORS_PPC_OCC
>
> This driver can also be built as a module. If so, the module
> will be called occ.
> +
> +if SENSORS_PPC_OCC
> +
> +config SENSORS_PPC_OCC_P8_I2C
> + tristate "POWER8 OCC hwmon support"
> + depends on I2C
> + help
> + Provide a hwmon sysfs interface for the POWER8 On-Chip Controller,
> + exposing temperature, frequency and power measurements.
> +
> + This driver can also be built as a module. If so, the module will be
> + called p8-occ-i2c.
> +
> +endif
> diff --git a/drivers/hwmon/occ/Makefile b/drivers/hwmon/occ/Makefile
> index a6881f9..9294b58 100644
> --- a/drivers/hwmon/occ/Makefile
> +++ b/drivers/hwmon/occ/Makefile
> @@ -1 +1,2 @@
> obj-$(CONFIG_SENSORS_PPC_OCC) += occ.o occ_sysfs.o
> +obj-$(CONFIG_SENSORS_PPC_OCC_P8_I2C) += occ_scom_i2c.o occ_p8.o p8_occ_i2c.o
> diff --git a/drivers/hwmon/occ/p8_occ_i2c.c b/drivers/hwmon/occ/p8_occ_i2c.c
> new file mode 100644
> index 0000000..0c65894
> --- /dev/null
> +++ b/drivers/hwmon/occ/p8_occ_i2c.c
> @@ -0,0 +1,141 @@
> +/*
> + * p8_occ_i2c.c - hwmon OCC driver
> + *
> + * This file contains the i2c layer for accessing the P8 OCC over i2c bus.
> + *
> + * Copyright 2016 IBM Corp.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/err.h>
> +#include <linux/module.h>
> +#include <linux/init.h>
> +#include <linux/slab.h>
> +#include <linux/i2c.h>
> +#include <linux/err.h>
> +#include <linux/of.h>
> +#include <linux/kernel.h>
> +#include <linux/device.h>
> +
> +#include "scom.h"
> +#include "occ_scom_i2c.h"
> +#include "occ_p8.h"
> +#include "occ_sysfs.h"
> +
> +#define P8_OCC_I2C_NAME "p8-occ-i2c"
> +
> +static char *caps_sensor_names[] = {
> + "curr_powercap",
> + "curr_powerreading",
> + "norm_powercap",
> + "max_powercap",
> + "min_powercap",
> + "user_powerlimit"
> +};
> +
> +int p8_i2c_getscom(void *bus, u32 address, u64 *data)
> +{
> + /* P8 i2c slave requires address to be shifted by 1 */
> + address = address << 1;
> +
> + return occ_i2c_getscom(bus, address, data);
> +}
> +
> +int p8_i2c_putscom(void *bus, u32 address, u32 data0, u32 data1)
> +{
> + /* P8 i2c slave requires address to be shifted by 1 */
> + address = address << 1;
> +
> + return occ_i2c_putscom(bus, address, data0, data1);
> +}
> +
> +static struct occ_bus_ops p8_bus_ops = {
> + .getscom = p8_i2c_getscom,
> + .putscom = p8_i2c_putscom,
> +};
> +
> +static struct occ_sysfs_config p8_sysfs_config = {
> + .num_caps_fields = ARRAY_SIZE(caps_sensor_names),
> + .caps_names = caps_sensor_names,
> +};
> +
> +static int p8_occ_probe(struct i2c_client *client,
> + const struct i2c_device_id *id)
> +{
> + struct occ *occ;
> + struct occ_sysfs *hwmon;
> +
> + occ = p8_occ_start(&client->dev, client, &p8_bus_ops);
> + if (IS_ERR(occ))
> + return PTR_ERR(occ);
> +
> + hwmon = occ_sysfs_start(&client->dev, occ, &p8_sysfs_config);
> + if (IS_ERR(hwmon))
> + return PTR_ERR(hwmon);
> +
> + i2c_set_clientdata(client, hwmon);
> +
> + return 0;
> +}
> +
> +static int p8_occ_remove(struct i2c_client *client)
> +{
> + int rc;
> + struct occ_sysfs *hwmon = i2c_get_clientdata(client);
> + struct occ *occ = hwmon->occ;
> +
> + rc = occ_sysfs_stop(&client->dev, hwmon);
> +
> + rc = rc || p8_occ_stop(occ);
> +
> + return rc;
> +}
> +
> +/* used by old-style board info. */
> +static const struct i2c_device_id occ_ids[] = {
> + { P8_OCC_I2C_NAME, 0 },
> + {}
> +};
> +MODULE_DEVICE_TABLE(i2c, occ_ids);
> +
> +/* used by device table */
> +static const struct of_device_id occ_of_match[] = {
> + { .compatible = "ibm,p8-occ-i2c" },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, occ_of_match);
> +
> +/*
> + * i2c-core uses i2c-detect() to detect device in below address list.
> + * If exists, address will be assigned to client.
> + * It is also possible to read address from device table.
> + */
> +static const unsigned short normal_i2c[] = {0x50, 0x51, I2C_CLIENT_END };
> +
> +static struct i2c_driver p8_occ_driver = {
> + .class = I2C_CLASS_HWMON,
> + .driver = {
> + .name = P8_OCC_I2C_NAME,
> + .pm = NULL,
> + .of_match_table = occ_of_match,
> + },
> + .probe = p8_occ_probe,
> + .remove = p8_occ_remove,
> + .id_table = occ_ids,
> + .address_list = normal_i2c,
> +};
> +
> +module_i2c_driver(p8_occ_driver);
> +
> +MODULE_AUTHOR("Eddie James <eajames@us.ibm.com>");
> +MODULE_DESCRIPTION("BMC P8 OCC hwmon driver");
> +MODULE_LICENSE("GPL");
> --
> 1.9.1
>
^ permalink raw reply
* Re: [PATCH V7 1/4] Documentation/devicetree/bindings: b850v3_lvds_dp
From: Rob Herring @ 2017-01-03 22:51 UTC (permalink / raw)
To: Peter Senna Tschudin
Cc: airlied-cv59FeDIM0c, architt-sgV2jX0FEOL9JmXXK+q4OQ,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b, daniel.vetter-/w4YWyX8dFk,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, devicetree-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ,
eballetbo-Re5JQEeQqe8AvxtiuMwx3w, galak-sgV2jX0FEOL9JmXXK+q4OQ,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
heiko-4mtYJXux2i+zQB+pC5nmwQ,
ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg,
javier-0uQlZySMnqxg9hUCZPvPmw, jslaby-AlSwsSmVLrQ,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-0h96xk9xTtrk1uMJSBkQmQ, mark.rutland-5wv7dgnIgG8,
martin.donnelly-JJi787mZWgc, martyn.welch-ZGY8ohtN/8pPYcu2f3hruQ,
mchehab-JPH+aEBZ4P+UEJcrhfAQsw, pawel.moll-5wv7dgnIgG8,
peter.senna-Re5JQEeQqe8AvxtiuMwx3w,
p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ,
thierry.reding-Re5JQEeQqe8AvxtiuMwx3w,
rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw,
shawnguo-DgEjT+Ai2ygdnm+yROfE0A, tiwai-IBi9RG/b67k,
treding-DDmLM1+adcrQT0dZR+AlfA, ykk
In-Reply-To: <21ea1b0795bdaa30ca475d6ce675b620b2b644ed.1483301745.git.peter.senna-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
On Sun, Jan 01, 2017 at 09:24:29PM +0100, Peter Senna Tschudin wrote:
> Devicetree bindings documentation for the GE B850v3 LVDS/DP++
> display bridge.
>
> Cc: Martyn Welch <martyn.welch-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>
> Cc: Martin Donnelly <martin.donnelly-JJi787mZWgc@public.gmane.org>
> Cc: Javier Martinez Canillas <javier-0uQlZySMnqxg9hUCZPvPmw@public.gmane.org>
> Cc: Enric Balletbo i Serra <enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
> Cc: Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> Cc: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
> Signed-off-by: Peter Senna Tschudin <peter.senna-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
> ---
> There was an Acked-by from Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> for V6, but I changed
> the bindings to use i2c_new_secondary_device() so I removed it from the commit
> message.
>
> .../devicetree/bindings/ge/b850v3-lvds-dp.txt | 39 ++++++++++++++++++++++
Generally, bindings are not organized by vendor. Put in
bindings/display/bridge/... instead.
> 1 file changed, 39 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt
>
> diff --git a/Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt b/Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt
> new file mode 100644
> index 0000000..1bc6ebf
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt
> @@ -0,0 +1,39 @@
> +Driver for GE B850v3 LVDS/DP++ display bridge
> +
> +Required properties:
> + - compatible : should be "ge,b850v3-lvds-dp".
Isn't '-lvds-dp' redundant? The part# should be enough.
> + - reg : should contain the main address which is used to ack the
> + interrupts and address for edid.
> + - reg-names : comma separeted list of register names. Valid values
s/separeted/separated/
> + are "main", and "edid".
> + - interrupt-parent : phandle of the interrupt controller that services
> + interrupts to the device
> + - interrupts : one interrupt should be described here, as in
> + <0 IRQ_TYPE_LEVEL_HIGH>.
> + - port : should describe the video signal connection between the host
> + and the bridge.
> +
> +Example:
> +
> +&mux2_i2c2 {
> + status = "okay";
> + clock-frequency = <100000>;
> +
> + b850v3-lvds-dp-bridge@73 {
> + compatible = "ge,b850v3-lvds-dp";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + reg = <0x73 0x72>;
> + reg-names = "main", "edid";
> +
> + interrupt-parent = <&gpio2>;
> + interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
> +
> + port {
> + b850v3_dp_bridge_in: endpoint {
> + remote-endpoint = <&lvds0_out>;
> + };
> + };
> + };
> +};
> --
> 2.5.5
>
--
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 02/10] dt-bindings: hisi: Add Hisilicon HiP05/06/07 Djtag dts bindings
From: Rob Herring @ 2017-01-03 22:56 UTC (permalink / raw)
To: Anurup M
Cc: mark.rutland-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
anurup.m-hv44wF8Li93QT0dZR+AlfA,
zhangshaokun-C8/M+/jPZTeaMJb+Lgu22Q,
tanxiaojun-hv44wF8Li93QT0dZR+AlfA, xuwei5-C8/M+/jPZTeaMJb+Lgu22Q,
sanil.kumar-C8/M+/jPZTeaMJb+Lgu22Q,
john.garry-hv44wF8Li93QT0dZR+AlfA,
gabriele.paoloni-hv44wF8Li93QT0dZR+AlfA,
shiju.jose-hv44wF8Li93QT0dZR+AlfA,
wangkefeng.wang-hv44wF8Li93QT0dZR+AlfA,
linuxarm-hv44wF8Li93QT0dZR+AlfA, shyju.pv-hv44wF8Li93QT0dZR+AlfA
In-Reply-To: <1483339743-23881-1-git-send-email-anurup.m-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
On Mon, Jan 02, 2017 at 01:49:03AM -0500, Anurup M wrote:
> From: Tan Xiaojun <tanxiaojun-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
>
> Add Hisilicon HiP05/06/07 Djtag dts bindings for CPU and IO Die
>
> Signed-off-by: Tan Xiaojun <tanxiaojun-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> Signed-off-by: Anurup M <anurup.m-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> ---
> .../devicetree/bindings/arm/hisilicon/djtag.txt | 41 ++++++++++++++++++++++
> 1 file changed, 41 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt b/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
> new file mode 100644
> index 0000000..bbe8b45
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
> @@ -0,0 +1,41 @@
> +The Hisilicon Djtag is an independent component which connects with some other
> +components in the SoC by Debug Bus. The djtag is available in CPU and IO dies
> +in the chip. The djtag controls access to connecting modules of CPU and IO
> +dies.
> +The various connecting components in CPU die (like L3 cache, L3 cache PMU etc.)
> +are accessed by djtag during real time debugging. In IO die there are connecting
> +components like RSA. These components appear as devices attached to djtag bus.
> +
> +Hisilicon HiP05/06/07 djtag for CPU and IO die
> +Required properties:
> + - compatible : The value should be as follows
> + (a) "hisilicon,hip05-djtag-v1" for CPU and IO die which use v1 hw in
> + HiP05 chipset.
You don't need to distinguish the CPU and IO blocks?
> + (b) "hisilicon,hip06-djtag-v1" for CPU die which use v1 hw in HiP06 chipset.
> + (c) "hisilicon,hip06-djtag-v2" for IO die which use v2 hw in HiP06 chipset.
> + (d) "hisilicon,hip07-djtag-v2" for CPU and IO die which use v2 hw in
> + HiP07 chipset.
> + - reg : Register address and size
> + - hisi-scl-id : The Super Cluster ID for CPU or IO die
Still needs a vendor prefix. i.e. hisilicon,scl-id
> +
> +Example 1: Djtag for CPU die
> +
> + /* for Hisilicon HiP05 djtag for CPU Die */
> + djtag0: djtag@80010000 {
> + compatible = "hisilicon,hip05-djtag-v1";
> + reg = <0x0 0x80010000 0x0 0x10000>;
> + hisi-scl-id = <0x02>;
> +
> + /* All connecting components will appear as child nodes */
> + };
> +
> +Example 2: Djtag for IO die
> +
> + /* for Hisilicon HiP05 djtag for IO Die */
> + djtag1: djtag@d0000000 {
> + compatible = "hisilicon,hip05-djtag-v1";
> + reg = <0x0 0xd0000000 0x0 0x10000>;
> + hisi-scl-id = <0x01>;
> +
> + /* All connecting components will appear as child nodes */
> + };
> --
> 2.1.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
* [PATCH V5 1/3] dt-bindings: document common IEEE 802.11 frequency limit property
From: Rafał Miłecki @ 2017-01-03 22:57 UTC (permalink / raw)
To: Johannes Berg, linux-wireless-u79uwXL29TY76Z2rM5mHXA
Cc: Martin Blumenstingl, Felix Fietkau, Arend van Spriel,
Arnd Bergmann, devicetree-u79uwXL29TY76Z2rM5mHXA,
Rafał Miłecki
From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
This new file should be used for properties that apply to all wireless
devices.
Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
---
V2: Switch to a single ieee80211-freq-limit property that allows specifying
*multiple* ranges. This resolves problem with more complex rules as pointed
by Felx.
Make description implementation agnostic as pointed by Arend.
Rename node to wifi as suggested by Martin.
V3: Use more real-life frequencies in the example.
V5: Describe hardware design as possible use for this property
---
.../devicetree/bindings/net/wireless/ieee80211.txt | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/wireless/ieee80211.txt
diff --git a/Documentation/devicetree/bindings/net/wireless/ieee80211.txt b/Documentation/devicetree/bindings/net/wireless/ieee80211.txt
new file mode 100644
index 0000000..1c82c16
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/wireless/ieee80211.txt
@@ -0,0 +1,20 @@
+Common IEEE 802.11 properties
+
+This provides documentation of common properties that are valid for all wireless
+devices.
+
+Optional properties:
+ - ieee80211-freq-limit : list of supported frequency ranges in KHz. This can be
+ used to specify extra hardware limitations caused by e.g. used antennas
+ or power amplifiers.
+
+Example:
+
+pcie@0,0 {
+ reg = <0x0000 0 0 0 0>;
+ wifi@0,0 {
+ reg = <0x0000 0 0 0 0>;
+ ieee80211-freq-limit = <2402000 2482000>,
+ <5170000 5250000>;
+ };
+};
--
2.10.1
^ permalink raw reply related
* [PATCH V5 2/3] cfg80211: move function checking range fit to util.c
From: Rafał Miłecki @ 2017-01-03 22:57 UTC (permalink / raw)
To: Johannes Berg, linux-wireless-u79uwXL29TY76Z2rM5mHXA
Cc: Martin Blumenstingl, Felix Fietkau, Arend van Spriel,
Arnd Bergmann, devicetree-u79uwXL29TY76Z2rM5mHXA,
Rafał Miłecki
In-Reply-To: <20170103225715.14072-1-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
It is needed for another cfg80211 helper that will be out of reg.c so
move it to common util.c file and make it non-static.
Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
---
V5: Add this patch as suggested by Arend
---
net/wireless/core.h | 3 +++
net/wireless/reg.c | 27 +++++++--------------------
net/wireless/util.c | 15 +++++++++++++++
3 files changed, 25 insertions(+), 20 deletions(-)
diff --git a/net/wireless/core.h b/net/wireless/core.h
index af6e023..bc8ba6e 100644
--- a/net/wireless/core.h
+++ b/net/wireless/core.h
@@ -430,6 +430,9 @@ int cfg80211_change_iface(struct cfg80211_registered_device *rdev,
void cfg80211_process_rdev_events(struct cfg80211_registered_device *rdev);
void cfg80211_process_wdev_events(struct wireless_dev *wdev);
+bool cfg80211_does_bw_fit_range(const struct ieee80211_freq_range *freq_range,
+ u32 center_freq_khz, u32 bw_khz);
+
/**
* cfg80211_chandef_dfs_usable - checks if chandef is DFS usable
* @wiphy: the wiphy to validate against
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 5dbac37..753efcd 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -748,21 +748,6 @@ static bool is_valid_rd(const struct ieee80211_regdomain *rd)
return true;
}
-static bool reg_does_bw_fit(const struct ieee80211_freq_range *freq_range,
- u32 center_freq_khz, u32 bw_khz)
-{
- u32 start_freq_khz, end_freq_khz;
-
- start_freq_khz = center_freq_khz - (bw_khz/2);
- end_freq_khz = center_freq_khz + (bw_khz/2);
-
- if (start_freq_khz >= freq_range->start_freq_khz &&
- end_freq_khz <= freq_range->end_freq_khz)
- return true;
-
- return false;
-}
-
/**
* freq_in_rule_band - tells us if a frequency is in a frequency band
* @freq_range: frequency rule we want to query
@@ -1070,7 +1055,7 @@ freq_reg_info_regd(u32 center_freq,
if (!band_rule_found)
band_rule_found = freq_in_rule_band(fr, center_freq);
- bw_fits = reg_does_bw_fit(fr, center_freq, bw);
+ bw_fits = cfg80211_does_bw_fit_range(fr, center_freq, bw);
if (band_rule_found && bw_fits)
return rr;
@@ -1138,11 +1123,13 @@ static uint32_t reg_rule_to_chan_bw_flags(const struct ieee80211_regdomain *regd
max_bandwidth_khz = reg_get_max_bandwidth(regd, reg_rule);
/* If we get a reg_rule we can assume that at least 5Mhz fit */
- if (!reg_does_bw_fit(freq_range, MHZ_TO_KHZ(chan->center_freq),
- MHZ_TO_KHZ(10)))
+ if (!cfg80211_does_bw_fit_range(freq_range,
+ MHZ_TO_KHZ(chan->center_freq),
+ MHZ_TO_KHZ(10)))
bw_flags |= IEEE80211_CHAN_NO_10MHZ;
- if (!reg_does_bw_fit(freq_range, MHZ_TO_KHZ(chan->center_freq),
- MHZ_TO_KHZ(20)))
+ if (!cfg80211_does_bw_fit_range(freq_range,
+ MHZ_TO_KHZ(chan->center_freq),
+ MHZ_TO_KHZ(20)))
bw_flags |= IEEE80211_CHAN_NO_20MHZ;
if (max_bandwidth_khz < MHZ_TO_KHZ(10))
diff --git a/net/wireless/util.c b/net/wireless/util.c
index 2cf7df8..62dc214 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -1847,6 +1847,21 @@ void cfg80211_free_nan_func(struct cfg80211_nan_func *f)
}
EXPORT_SYMBOL(cfg80211_free_nan_func);
+bool cfg80211_does_bw_fit_range(const struct ieee80211_freq_range *freq_range,
+ u32 center_freq_khz, u32 bw_khz)
+{
+ u32 start_freq_khz, end_freq_khz;
+
+ start_freq_khz = center_freq_khz - (bw_khz / 2);
+ end_freq_khz = center_freq_khz + (bw_khz / 2);
+
+ if (start_freq_khz >= freq_range->start_freq_khz &&
+ end_freq_khz <= freq_range->end_freq_khz)
+ return true;
+
+ return false;
+}
+
/* See IEEE 802.1H for LLC/SNAP encapsulation/decapsulation */
/* Ethernet-II snap header (RFC1042 for most EtherTypes) */
const unsigned char rfc1042_header[] __aligned(2) =
--
2.10.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH V5 3/3] cfg80211: support ieee80211-freq-limit DT property
From: Rafał Miłecki @ 2017-01-03 22:57 UTC (permalink / raw)
To: Johannes Berg, linux-wireless-u79uwXL29TY76Z2rM5mHXA
Cc: Martin Blumenstingl, Felix Fietkau, Arend van Spriel,
Arnd Bergmann, devicetree-u79uwXL29TY76Z2rM5mHXA,
Rafał Miłecki
In-Reply-To: <20170103225715.14072-1-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
This patch adds a helper for reading that new property and applying
limitations or supported channels specified this way.
It may be useful for specifying single band devices or devices that
support only some part of the whole band. It's common that tri-band
routers have separated radios for lower and higher part of 5 GHz band.
Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
---
V2: Put main code in core.c as it isn't strictly part of regulatory - pointed
by Arend.
Update to support ieee80211-freq-limit (new property).
V3: Introduce separated wiphy_read_of_freq_limits function.
Add extra sanity checks for DT data.
Move code back to reg.c as suggested by Johannes.
V4: Move code to of.c
Use one helper called at init time (no runtime hooks)
Modify orig_flags
V5: Make wiphy_read_of_freq_limits return void as there isn't much point of
handling errors.
---
include/net/cfg80211.h | 25 +++++++++
net/wireless/Makefile | 1 +
net/wireless/of.c | 138 +++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 164 insertions(+)
create mode 100644 net/wireless/of.c
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index ca2ac1c..a58cdc9 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -311,6 +311,31 @@ struct ieee80211_supported_band {
struct ieee80211_sta_vht_cap vht_cap;
};
+/**
+ * wiphy_read_of_freq_limits - read frequency limits from device tree
+ *
+ * @wiphy: the wireless device to get extra limits for
+ *
+ * Some devices may have extra limitations specified in DT. This may be useful
+ * for chipsets that normally support more bands but are limited due to board
+ * design (e.g. by antennas or extermal power amplifier).
+ *
+ * This function reads info from DT and uses it to *modify* channels (disable
+ * unavailable ones). It's usually a *bad* idea to use it in drivers with
+ * shared channel data as DT limitations are device specific.
+ *
+ * As this function access device node it has to be called after set_wiphy_dev.
+ * It also modifies channels so they have to be set first.
+ */
+#ifdef CONFIG_OF
+void wiphy_read_of_freq_limits(struct wiphy *wiphy);
+#else /* CONFIG_OF */
+static inline void wiphy_read_of_freq_limits(struct wiphy *wiphy)
+{
+}
+#endif /* !CONFIG_OF */
+
+
/*
* Wireless hardware/device configuration structures and methods
*/
diff --git a/net/wireless/Makefile b/net/wireless/Makefile
index 4c9e39f..95b4c09 100644
--- a/net/wireless/Makefile
+++ b/net/wireless/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_WEXT_PRIV) += wext-priv.o
cfg80211-y += core.o sysfs.o radiotap.o util.o reg.o scan.o nl80211.o
cfg80211-y += mlme.o ibss.o sme.o chan.o ethtool.o mesh.o ap.o trace.o ocb.o
+cfg80211-$(CONFIG_OF) += of.o
cfg80211-$(CONFIG_CFG80211_DEBUGFS) += debugfs.o
cfg80211-$(CONFIG_CFG80211_WEXT) += wext-compat.o wext-sme.o
cfg80211-$(CONFIG_CFG80211_INTERNAL_REGDB) += regdb.o
diff --git a/net/wireless/of.c b/net/wireless/of.c
new file mode 100644
index 0000000..70b21e0
--- /dev/null
+++ b/net/wireless/of.c
@@ -0,0 +1,138 @@
+/*
+ * Copyright (C) 2017 Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
+ *
+ * Permission to use, copy, modify, and/or distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include <linux/of.h>
+#include <net/cfg80211.h>
+#include "core.h"
+
+static bool wiphy_freq_limits_valid_chan(struct wiphy *wiphy,
+ struct ieee80211_freq_range *freq_limits,
+ unsigned int n_freq_limits,
+ struct ieee80211_channel *chan)
+{
+ u32 bw = MHZ_TO_KHZ(20);
+ int i;
+
+ for (i = 0; i < n_freq_limits; i++) {
+ struct ieee80211_freq_range *limit = &freq_limits[i];
+
+ if (cfg80211_does_bw_fit_range(limit,
+ MHZ_TO_KHZ(chan->center_freq),
+ bw))
+ return true;
+ }
+
+ return false;
+}
+
+static void wiphy_freq_limits_apply(struct wiphy *wiphy,
+ struct ieee80211_freq_range *freq_limits,
+ unsigned int n_freq_limits)
+{
+ enum nl80211_band band;
+ int i;
+
+ if (WARN_ON(!n_freq_limits))
+ return;
+
+ for (band = 0; band < NUM_NL80211_BANDS; band++) {
+ struct ieee80211_supported_band *sband = wiphy->bands[band];
+
+ if (!sband)
+ continue;
+
+ for (i = 0; i < sband->n_channels; i++) {
+ struct ieee80211_channel *chan = &sband->channels[i];
+
+ if (chan->orig_flags & IEEE80211_CHAN_DISABLED)
+ continue;
+
+ if (!wiphy_freq_limits_valid_chan(wiphy, freq_limits,
+ n_freq_limits,
+ chan)) {
+ pr_debug("Disabling freq %d MHz as it's out of OF limits\n",
+ chan->center_freq);
+ chan->orig_flags |= IEEE80211_CHAN_DISABLED;
+ }
+ }
+ }
+}
+
+void wiphy_read_of_freq_limits(struct wiphy *wiphy)
+{
+ struct device *dev = wiphy_dev(wiphy);
+ struct device_node *np;
+ struct property *prop;
+ struct ieee80211_freq_range *freq_limits;
+ unsigned int n_freq_limits;
+ const __be32 *p;
+ int len, i;
+ int err = 0;
+
+ if (!dev)
+ return;
+ np = dev_of_node(dev);
+ if (!np)
+ return;
+
+ prop = of_find_property(np, "ieee80211-freq-limit", &len);
+ if (!prop)
+ return;
+
+ if (!len || len % sizeof(u32) || len / sizeof(u32) % 2) {
+ dev_err(dev, "ieee80211-freq-limit wrong format");
+ return;
+ }
+ n_freq_limits = len / sizeof(u32) / 2;
+
+ freq_limits = kcalloc(n_freq_limits, sizeof(*freq_limits), GFP_KERNEL);
+ if (!freq_limits) {
+ err = -ENOMEM;
+ goto out_kfree;
+ }
+
+ p = NULL;
+ for (i = 0; i < n_freq_limits; i++) {
+ struct ieee80211_freq_range *limit = &freq_limits[i];
+
+ p = of_prop_next_u32(prop, p, &limit->start_freq_khz);
+ if (!p) {
+ err = -EINVAL;
+ goto out_kfree;
+ }
+
+ p = of_prop_next_u32(prop, p, &limit->end_freq_khz);
+ if (!p) {
+ err = -EINVAL;
+ goto out_kfree;
+ }
+
+ if (!limit->start_freq_khz ||
+ !limit->end_freq_khz ||
+ limit->start_freq_khz >= limit->end_freq_khz) {
+ err = -EINVAL;
+ goto out_kfree;
+ }
+ }
+
+ wiphy_freq_limits_apply(wiphy, freq_limits, n_freq_limits);
+
+out_kfree:
+ kfree(freq_limits);
+ if (err)
+ dev_err(dev, "Failed to get limits: %d\n", err);
+}
+EXPORT_SYMBOL(wiphy_read_of_freq_limits);
--
2.10.1
^ permalink raw reply related
* [PATCH V5 4/3] brcmfmac: use wiphy_read_of_freq_limits to respect extra limits
From: Rafał Miłecki @ 2017-01-03 22:57 UTC (permalink / raw)
To: Johannes Berg, linux-wireless-u79uwXL29TY76Z2rM5mHXA
Cc: Martin Blumenstingl, Felix Fietkau, Arend van Spriel,
Arnd Bergmann, devicetree-u79uwXL29TY76Z2rM5mHXA,
Rafał Miłecki
In-Reply-To: <20170103225715.14072-1-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
There are some devices (e.g. Netgear R8000 home router) with one chipset
model used for different radios, some of them limited to subbands. NVRAM
entries don't contain any extra info on such limitations and firmware
reports full list of channels to us. We need to store extra limitation
info on DT to support such devices properly.
Now there is a cfg80211 helper for reading such info use it in brcmfmac.
This patch adds check for channel being disabled with orig_flags which
is how this wiphy helper works.
Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
---
This patch should probably go through wireless-driver-next which is why
it got weird number 4/3. I'm sending it just as a proof of concept.
It was succesfully tested on SmartRG SR400ac with BCM43602.
V4: Respect IEEE80211_CHAN_DISABLED in orig_flags
V5: Update commit message
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index ccae3bb..f95e316 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -5886,6 +5886,9 @@ static int brcmf_construct_chaninfo(struct brcmf_cfg80211_info *cfg,
band->band);
channel[index].hw_value = ch.control_ch_num;
+ if (channel->orig_flags & IEEE80211_CHAN_DISABLED)
+ continue;
+
/* assuming the chanspecs order is HT20,
* HT40 upper, HT40 lower, and VHT80.
*/
@@ -6477,6 +6480,7 @@ static int brcmf_setup_wiphy(struct wiphy *wiphy, struct brcmf_if *ifp)
wiphy->bands[NL80211_BAND_5GHZ] = band;
}
}
+ wiphy_read_of_freq_limits(wiphy);
err = brcmf_setup_wiphybands(wiphy);
return err;
}
--
2.10.1
^ permalink raw reply related
* Re: [PATCH v3 03/10] dt-bindings: perf: hisi: Add Devicetree bindings for Hisilicon SoC PMU
From: Rob Herring @ 2017-01-03 22:59 UTC (permalink / raw)
To: Anurup M
Cc: mark.rutland-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
anurup.m-hv44wF8Li93QT0dZR+AlfA,
zhangshaokun-C8/M+/jPZTeaMJb+Lgu22Q,
tanxiaojun-hv44wF8Li93QT0dZR+AlfA, xuwei5-C8/M+/jPZTeaMJb+Lgu22Q,
sanil.kumar-C8/M+/jPZTeaMJb+Lgu22Q,
john.garry-hv44wF8Li93QT0dZR+AlfA,
gabriele.paoloni-hv44wF8Li93QT0dZR+AlfA,
shiju.jose-hv44wF8Li93QT0dZR+AlfA,
wangkefeng.wang-hv44wF8Li93QT0dZR+AlfA,
linuxarm-hv44wF8Li93QT0dZR+AlfA, shyju.pv-hv44wF8Li93QT0dZR+AlfA
In-Reply-To: <1483339761-23927-1-git-send-email-anurup.m-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
On Mon, Jan 02, 2017 at 01:49:21AM -0500, Anurup M wrote:
> 1) Device tree bindings for Hisilicon SoC PMU.
> 2) Add example for Hisilicon L3 cache and MN PMU.
> 3) Add child nodes of L3C and MN in djtag bindings example.
>
> Signed-off-by: Anurup M <anurup.m-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> Signed-off-by: Shaokun Zhang <zhangshaokun-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org>
> ---
> .../devicetree/bindings/arm/hisilicon/djtag.txt | 25 ++++++
> .../devicetree/bindings/arm/hisilicon/pmu.txt | 100 +++++++++++++++++++++
> 2 files changed, 125 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/hisilicon/pmu.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt b/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
> index bbe8b45..653fdb7 100644
> --- a/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
> +++ b/Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
> @@ -27,6 +27,31 @@ Example 1: Djtag for CPU die
> hisi-scl-id = <0x02>;
>
> /* All connecting components will appear as child nodes */
> +
> + pmul3c0 {
> + compatible = "hisilicon,hip05-pmu-l3c-v1";
> + hisi-module-id = <0x04 0x02>;
> + };
> +
> + pmul3c1 {
> + compatible = "hisilicon,hip05-pmu-l3c-v1";
> + hisi-module-id = <0x04 0x04>;
> + };
> +
> + pmul3c2 {
> + compatible = "hisilicon,hip05-pmu-l3c-v1";
> + hisi-module-id = <0x04 0x01>;
> + };
> +
> + pmul3c3 {
> + compatible = "hisilicon,hip05-pmu-l3c-v1";
> + hisi-module-id = <0x04 0x08>;
> + };
> +
> + pmumn0 {
> + compatible = "hisilicon,hip05-pmu-mn-v1";
> + hisi-module-id = <0x0b>;
> + };
> };
>
> Example 2: Djtag for IO die
> diff --git a/Documentation/devicetree/bindings/arm/hisilicon/pmu.txt b/Documentation/devicetree/bindings/arm/hisilicon/pmu.txt
> new file mode 100644
> index 0000000..fceef8d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/hisilicon/pmu.txt
> @@ -0,0 +1,100 @@
> +Hisilicon SoC HiP05/06/07 ARMv8 PMU
> +===================================
> +
> +The Hisilicon SoC chips like HiP05/06/07 etc. consist of various independent
> +system device PMUs such as L3 cache (L3C) and Miscellaneous Nodes(MN). These
> +PMU devices are independent and have hardware logic to gather statistics and
> +performance information.
> +
> +HiSilicon SoC chip is encapsulated by multiple CPU and IO dies. The CPU die
> +is called as Super CPU cluster (SCCL) which includes 16 cpu-cores. Every SCCL
> +in HiP05/06/07 chips are further grouped as CPU clusters (CCL) which includes
> +4 cpu-cores each.
> +e.g. In the case of HiP05/06/07, each SCCL has 1 L3 cache and 1 MN PMU device.
> +The L3 cache is further grouped as 4 L3 cache banks in a SCCL.
> +
> +The Hisilicon SoC PMU DT node bindings for uncore PMU devices are as below.
> +For PMU devices like L3 cache. MN etc. which are accessed using the djtag,
> +the parent node will be the djtag node of the corresponding CPU die (SCCL).
> +
> +L3 cache
> +---------
> +The L3 cache is dedicated for each SCCL. Each SCCL in HiP05/06/07 chips have 4
> +L3 cache banks. Each L3 cache bank have separate DT nodes.
> +
> +Required properties:
> +
> + - compatible : This value should be as follows
> + (a) "hisilicon,hip05-pmu-l3c-v1" for v1 hw in HiP05 chipset
> + (b) "hisilicon,hip06-pmu-l3c-v1" for v1 hw in HiP06 chipset
> + (c) "hisilicon,hip07-pmu-l3c-v2" for v2 hw in HiP07 chipset
> +
> + - hisi-module-id : This property is a combination of two values in the below order.
Vendor prefix: hisilicon,module-id
> + a) Module ID: The module identifier for djtag.
> + b) Instance or Bank ID: This will identify the L3 cache bank
> + or instance.
> +
> +Optional properties:
> +
> + - interrupt-parent : A phandle indicating which interrupt controller
> + this PMU signals interrupts to.
> +
> + - interrupts : Interrupt line used by this L3 cache bank.
> +
> + *The counter overflow IRQ is not supported in v1 hardware (HiP05/06).
> +
> +Miscellaneous Node
> +------------------
> +The MN is dedicated for each SCCL and hence there are separate DT nodes for MN
> +for each SCCL.
> +
> +Required properties:
> +
> + - compatible : This value should be as follows
> + (a) "hisilicon,hip05-pmu-mn-v1" for v1 hw in HiP05 chipset
> + (b) "hisilicon,hip06-pmu-mn-v1" for v1 hw in HiP06 chipset
> + (c) "hisilicon,hip07-pmu-mn-v2" for v2 hw in HiP07 chipset
> +
> + - hisi-module-id : Module ID to input for djtag.
ditto
> +
> +Optional properties:
> +
> + - interrupt-parent : A phandle indicating which interrupt controller
> + this PMU signals interrupts to.
> +
> + - interrupts : Interrupt line used by this PMU.
> +
> + *The counter overflow IRQ is not supported in v1 hardware (HiP05/06).
> +
> +Example:
> +
> + djtag0: djtag@80010000 {
> + compatible = "hisilicon,hip05-djtag-v1";
> + reg = <0x0 0x80010000 0x0 0x10000>;
> + scl-id = <0x02>;
> +
> + pmul3c0 {
> + compatible = "hisilicon,hip05-pmu-l3c-v1";
> + hisi-module-id = <0x04 0x02>;
> + };
> +
> + pmul3c1 {
> + compatible = "hisilicon,hip05-pmu-l3c-v1";
> + hisi-module-id = <0x04 0x04>;
> + };
> +
> + pmul3c2 {
> + compatible = "hisilicon,hip05-pmu-l3c-v1";
> + hisi-module-id = <0x04 0x01>;
> + };
> +
> + pmul3c3 {
> + compatible = "hisilicon,hip05-pmu-l3c-v1";
> + hisi-module-id = <0x04 0x08>;
> + };
> +
> + pmumn0 {
> + compatible = "hisilicon,hip05-pmu-mn-v1";
> + hisi-module-id = <0x0b>;
> + };
> + };
> --
> 2.1.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 V4 1/2] dt-bindings: document common IEEE 802.11 frequency limit property
From: Rob Herring @ 2017-01-03 23:08 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Johannes Berg, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
Martin Blumenstingl, Felix Fietkau, Arend van Spriel,
Arnd Bergmann, devicetree-u79uwXL29TY76Z2rM5mHXA,
Rafał Miłecki
In-Reply-To: <20170103110340.23249-1-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Tue, Jan 03, 2017 at 12:03:38PM +0100, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
>
> This new file should be used for properties that apply to all wireless
> devices.
The commit msg should answer the questions I asked on v1.
> Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
> ---
> V2: Switch to a single ieee80211-freq-limit property that allows specifying
> *multiple* ranges. This resolves problem with more complex rules as pointed
> by Felx.
> Make description implementation agnostic as pointed by Arend.
> Rename node to wifi as suggested by Martin.
> V3: Use more real-life frequencies in the example.
> ---
> .../devicetree/bindings/net/wireless/ieee80211.txt | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/wireless/ieee80211.txt
>
> diff --git a/Documentation/devicetree/bindings/net/wireless/ieee80211.txt b/Documentation/devicetree/bindings/net/wireless/ieee80211.txt
> new file mode 100644
> index 0000000..0cd1219
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/wireless/ieee80211.txt
> @@ -0,0 +1,18 @@
> +Common IEEE 802.11 properties
> +
> +This provides documentation of common properties that are valid for all wireless
> +devices.
> +
> +Optional properties:
> + - ieee80211-freq-limit : list of supported frequency ranges in KHz
> +
> +Example:
> +
> +pcie@0,0 {
> + reg = <0x0000 0 0 0 0>;
> + wifi@0,0 {
> + reg = <0x0000 0 0 0 0>;
> + ieee80211-freq-limit = <2402000 2482000>,
> + <5170000 5250000>;
> + };
> +};
> --
> 2.10.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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 1/7] [media] dt-bindings: Add a binding for Video Data Order Adapter
From: Rob Herring @ 2017-01-03 23:18 UTC (permalink / raw)
To: Michael Tretter
Cc: linux-media-u79uwXL29TY76Z2rM5mHXA, Philipp Zabel,
devicetree-u79uwXL29TY76Z2rM5mHXA, Hans Verkuil,
Mauro Carvalho Chehab, kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
Philipp Zabel
In-Reply-To: <20170102132352.23669-2-m.tretter-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On Mon, Jan 02, 2017 at 02:23:46PM +0100, Michael Tretter wrote:
> From: Philipp Zabel <philipp.zabel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>
> Add a DT binding documentation for the Video Data Order Adapter (VDOA)
> of the Freescale i.MX6 SoC.
>
> Also, add the compatible property and correct clock to the device tree
> to match the documentation.
>
> Signed-off-by: Philipp Zabel <philipp.zabel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Signed-off-by: Michael Tretter <m.tretter-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> ---
> .../devicetree/bindings/media/fsl-vdoa.txt | 21 +++++++++++++++++++++
> arch/arm/boot/dts/imx6qdl.dtsi | 2 ++
> 2 files changed, 23 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/fsl-vdoa.txt
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@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 01/22] dt-bindings: iio: adc: add AXP20X/AXP22X ADC DT binding
From: Rob Herring @ 2017-01-03 23:20 UTC (permalink / raw)
To: Quentin Schulz
Cc: mark.rutland, devicetree, lars, linux-pm, linux-iio, linux-kernel,
sre, linux, wens, linux-arm-kernel, pmeerw, knaack.h,
maxime.ripard, bonbons, lee.jones, thomas.petazzoni, jic23,
icenowy
In-Reply-To: <20170102163723.7939-2-quentin.schulz@free-electrons.com>
On Mon, Jan 02, 2017 at 05:37:01PM +0100, Quentin Schulz wrote:
> The X-Powers AXP20X and AXP22X PMICs have multiple ADCs. They expose the
> battery voltage, battery charge and discharge currents, AC-in and VBUS
> voltages and currents, 2 GPIOs muxable in ADC mode and PMIC temperature.
>
> This adds the device tree binding documentation for the X-Powers AXP20X
> and AXP22X PMICs ADCs.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
> ---
> .../devicetree/bindings/iio/adc/axp20x_adc.txt | 24 ++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/adc/axp20x_adc.txt
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/axp20x_adc.txt b/Documentation/devicetree/bindings/iio/adc/axp20x_adc.txt
> new file mode 100644
> index 0000000..1b60065
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/axp20x_adc.txt
> @@ -0,0 +1,24 @@
> +X-Powers AXP20X and AXP22X PMIC Analog to Digital Converter (ADC)
> +
> +The X-Powers AXP20X and AXP22X PMICs have multiple ADCs. They expose the
> +battery voltage, battery charge and discharge currents, AC-in and VBUS
> +voltages and currents, 2 GPIOs muxable in ADC mode and PMIC temperature.
> +
> +The AXP22X PMICs do not have all ADCs of the AXP20X though.
> +
> +Required properties:
> + - compatible, one of:
> + "x-powers,axp209-adc"
> + "x-powers,axp221-adc"
> + - #io-channel-cells = <1>;
> +
> +This is a subnode of the AXP20X PMIC.
> +
> +Example:
> +
> +&axp209 {
> + axp209_adc: axp209_adc {
Use 'adc' for node name:
With that,
Acked-by: Rob Herring <robh@kernel.org>
> + compatible = "x-powers,axp209-adc";
> + #io-channel-cells = <1>;
> + };
> +};
> --
> 2.9.3
>
^ permalink raw reply
* Re: [PATCH V7 1/4] Documentation/devicetree/bindings: b850v3_lvds_dp
From: Peter Senna Tschudin @ 2017-01-03 23:34 UTC (permalink / raw)
To: Rob Herring
Cc: jslaby-AlSwsSmVLrQ, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
martyn.welch-ZGY8ohtN/8pPYcu2f3hruQ, tiwai-IBi9RG/b67k,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, galak-sgV2jX0FEOL9JmXXK+q4OQ,
peter.senna-Re5JQEeQqe8AvxtiuMwx3w,
architt-sgV2jX0FEOL9JmXXK+q4OQ, Fabio Estevam,
ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, mark.rutland-5wv7dgnIgG8,
rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw, kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ,
mchehab-JPH+aEBZ4P+UEJcrhfAQsw, Peter Senna Tschudin,
treding-DDmLM1+adcrQT0dZR+AlfA,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
javier-0uQlZySMnqxg9hUCZPvPmw, devicetree-u79uwXL29TY76Z2rM5mHXA,
martin.donnelly-JJi787mZWgc, shawnguo-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
eballetbo-Re5JQEeQqe8AvxtiuMwx3w, pawel.moll-5wv7dgnIgG8,
airlied-cv59FeDIM0c
In-Reply-To: <20170103225127.jn36tatufdfz2k5q@rob-hp-laptop>
Hi Rob,
Thank you for the review.
On 03 January, 2017 23:51 CET, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Sun, Jan 01, 2017 at 09:24:29PM +0100, Peter Senna Tschudin wrote:
> > Devicetree bindings documentation for the GE B850v3 LVDS/DP++
> > display bridge.
> >
> > Cc: Martyn Welch <martyn.welch-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>
> > Cc: Martin Donnelly <martin.donnelly-JJi787mZWgc@public.gmane.org>
> > Cc: Javier Martinez Canillas <javier-0uQlZySMnqxg9hUCZPvPmw@public.gmane.org>
> > Cc: Enric Balletbo i Serra <enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
> > Cc: Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> > Cc: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> > Cc: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
> > Signed-off-by: Peter Senna Tschudin <peter.senna-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
> > ---
> > There was an Acked-by from Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> for V6, but I changed
> > the bindings to use i2c_new_secondary_device() so I removed it from the commit
> > message.
> >
> > .../devicetree/bindings/ge/b850v3-lvds-dp.txt | 39 ++++++++++++++++++++++
>
> Generally, bindings are not organized by vendor. Put in
> bindings/display/bridge/... instead.
Will change that.
>
> > 1 file changed, 39 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt
> >
> > diff --git a/Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt b/Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt
> > new file mode 100644
> > index 0000000..1bc6ebf
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt
> > @@ -0,0 +1,39 @@
> > +Driver for GE B850v3 LVDS/DP++ display bridge
> > +
> > +Required properties:
> > + - compatible : should be "ge,b850v3-lvds-dp".
>
> Isn't '-lvds-dp' redundant? The part# should be enough.
b850v3 is the name of the product, this is why the proposed name. What about, b850v3-dp2 dp2 indicating the second DP output?
>
> > + - reg : should contain the main address which is used to ack the
> > + interrupts and address for edid.
> > + - reg-names : comma separeted list of register names. Valid values
>
> s/separeted/separated/
argh, sorry for this. Will fix it.
>
> > + are "main", and "edid".
> > + - interrupt-parent : phandle of the interrupt controller that services
> > + interrupts to the device
> > + - interrupts : one interrupt should be described here, as in
> > + <0 IRQ_TYPE_LEVEL_HIGH>.
> > + - port : should describe the video signal connection between the host
> > + and the bridge.
> > +
> > +Example:
> > +
> > +&mux2_i2c2 {
> > + status = "okay";
> > + clock-frequency = <100000>;
> > +
> > + b850v3-lvds-dp-bridge@73 {
> > + compatible = "ge,b850v3-lvds-dp";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + reg = <0x73 0x72>;
> > + reg-names = "main", "edid";
> > +
> > + interrupt-parent = <&gpio2>;
> > + interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
> > +
> > + port {
> > + b850v3_dp_bridge_in: endpoint {
> > + remote-endpoint = <&lvds0_out>;
> > + };
> > + };
> > + };
> > +};
> > --
> > 2.5.5
> >
--
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] gpio: pca953x: Add optional reset gpio control
From: Andy Shevchenko @ 2017-01-03 23:37 UTC (permalink / raw)
To: Steve Longerbeam
Cc: Linus Walleij, Alexandre Courbot, Rob Herring, Mark Rutland,
linux-gpio@vger.kernel.org, devicetree,
linux-kernel@vger.kernel.org, Steve Longerbeam
In-Reply-To: <1483391271-17304-2-git-send-email-steve_longerbeam@mentor.com>
On Mon, Jan 2, 2017 at 11:07 PM, Steve Longerbeam <slongerbeam@gmail.com> wrote:
> Add optional reset-gpios pin control. If present, de-assert the
> specified reset gpio pin to bring the chip out of reset.
> --- a/drivers/gpio/gpio-pca953x.c
> +++ b/drivers/gpio/gpio-pca953x.c
> @@ -22,6 +22,7 @@
> #include <linux/of_platform.h>
> #include <linux/acpi.h>
> #include <linux/regulator/consumer.h>
> +#include <linux/gpio/consumer.h>
Please, try to put it somehow alphabetically ordered (yes, I see it's
not in general, but try to squeeze it into longest part which is
ordered).
>
> #define PCA953X_INPUT 0
> #define PCA953X_OUTPUT 1
> @@ -754,8 +755,18 @@ static int pca953x_probe(struct i2c_client *client,
> invert = pdata->invert;
> chip->names = pdata->names;
> } else {
> + struct gpio_desc *reset_gpio;
> +
> chip->gpio_start = -1;
> irq_base = 0;
> +
> + /* see if we need to de-assert a reset pin */
see -> See
> + reset_gpio = devm_gpiod_get_optional(&client->dev, "reset",
> + GPIOD_OUT_LOW);
Shouldn't be _optional_exclusive?
See this recent discussion https://patchwork.ozlabs.org/patch/706002/
> + if (IS_ERR(reset_gpio)) {
> + dev_err(&client->dev, "request for reset pin failed\n");
> + return PTR_ERR(reset_gpio);
> + }
> }
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH v5 1/4] soc: zte: Add header for PM domains specifiers
From: Baoyou Xie @ 2017-01-04 0:19 UTC (permalink / raw)
To: jun.nie, robh+dt, mark.rutland, gregkh, davem, geert+renesas,
akpm, mchehab, linux, krzk, arnd, linus.walleij, pankaj.dubey,
yangbo.lu, f.fainelli, claudiu.manoil, laurent.pinchart+renesas
Cc: linux-kernel, linux-arm-kernel, devicetree, shawnguo, baoyou.xie,
xie.baoyou, chen.chaokai, wang.qiang01
This patch adds header with values used for ZTE 2967
SoC's power domain driver.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
Reviewed-by: Shawn Guo <shawn.guo@linaro.org>
---
include/dt-bindings/soc/zte,pm_domains.h | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
create mode 100644 include/dt-bindings/soc/zte,pm_domains.h
diff --git a/include/dt-bindings/soc/zte,pm_domains.h b/include/dt-bindings/soc/zte,pm_domains.h
new file mode 100644
index 0000000..01e9abc
--- /dev/null
+++ b/include/dt-bindings/soc/zte,pm_domains.h
@@ -0,0 +1,23 @@
+/*
+ * Copyright (C) 2017 Linaro Ltd.
+ *
+ * Author: Baoyou Xie <baoyou.xie@linaro.org>
+ * License terms: GNU General Public License (GPL) version 2
+ */
+#ifndef _DT_BINDINGS_SOC_ZTE_PM_DOMAINS_H
+#define _DT_BINDINGS_SOC_ZTE_PM_DOMAINS_H
+
+#define DM_ZX296718_SAPPU 0
+#define DM_ZX296718_VDE 1 /* g1v6 */
+#define DM_ZX296718_VCE 2 /* h1v6 */
+#define DM_ZX296718_HDE 3 /* g2v2 */
+#define DM_ZX296718_VIU 4
+#define DM_ZX296718_USB20 5
+#define DM_ZX296718_USB21 6
+#define DM_ZX296718_USB30 7
+#define DM_ZX296718_HSIC 8
+#define DM_ZX296718_GMAC 9
+#define DM_ZX296718_TS 10
+#define DM_ZX296718_VOU 11
+
+#endif /* _DT_BINDINGS_SOC_ZTE_PM_DOMAINS_H */
--
2.7.4
^ permalink raw reply related
* [PATCH v5 2/4] soc: zte: pm_domains: Prepare for supporting ARMv8 zx2967 family
From: Baoyou Xie @ 2017-01-04 0:19 UTC (permalink / raw)
To: jun.nie-QSEj5FYQhm4dnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
davem-fT/PcQaiUtIeIZ0/mPfg9Q,
geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
mchehab-DgEjT+Ai2ygdnm+yROfE0A, linux-0h96xk9xTtrk1uMJSBkQmQ,
krzk-DgEjT+Ai2ygdnm+yROfE0A, arnd-r2nGTMty4D4,
linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
pankaj.dubey-Sze3O3UU22JBDgjK7y7TUQ, yangbo.lu-3arQi8VN3Tc,
f.fainelli-Re5JQEeQqe8AvxtiuMwx3w, claudiu.manoil-3arQi8VN3Tc,
laurent.pinchart+renesas-ryLnwIuWjnjg/C1BVhZhaw
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
shawnguo-DgEjT+Ai2ygdnm+yROfE0A,
baoyou.xie-QSEj5FYQhm4dnm+yROfE0A,
xie.baoyou-Th6q7B73Y6EnDS1+zs4M5A,
chen.chaokai-Th6q7B73Y6EnDS1+zs4M5A,
wang.qiang01-Th6q7B73Y6EnDS1+zs4M5A
In-Reply-To: <1483489157-10782-1-git-send-email-baoyou.xie-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
The ARMv8 zx2967 family (296718, 296716 etc) uses different value
for controlling the power domain on/off registers, Choose the
value depending on the compatible.
Multiple domains are prepared for the family, this patch prepares
the common functions.
Signed-off-by: Baoyou Xie <baoyou.xie-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Reviewed-by: Shawn Guo <shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Reviewed-by: Jun Nie <jun.nie-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
drivers/soc/Kconfig | 1 +
drivers/soc/Makefile | 1 +
drivers/soc/zte/Kconfig | 13 ++++
drivers/soc/zte/Makefile | 4 ++
drivers/soc/zte/zx2967_pm_domains.c | 139 ++++++++++++++++++++++++++++++++++++
drivers/soc/zte/zx2967_pm_domains.h | 46 ++++++++++++
6 files changed, 204 insertions(+)
create mode 100644 drivers/soc/zte/Kconfig
create mode 100644 drivers/soc/zte/Makefile
create mode 100644 drivers/soc/zte/zx2967_pm_domains.c
create mode 100644 drivers/soc/zte/zx2967_pm_domains.h
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index f31bceb..f09023f 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -11,5 +11,6 @@ source "drivers/soc/tegra/Kconfig"
source "drivers/soc/ti/Kconfig"
source "drivers/soc/ux500/Kconfig"
source "drivers/soc/versatile/Kconfig"
+source "drivers/soc/zte/Kconfig"
endmenu
diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
index 50c23d0..05eae52 100644
--- a/drivers/soc/Makefile
+++ b/drivers/soc/Makefile
@@ -16,3 +16,4 @@ obj-$(CONFIG_ARCH_TEGRA) += tegra/
obj-$(CONFIG_SOC_TI) += ti/
obj-$(CONFIG_ARCH_U8500) += ux500/
obj-$(CONFIG_PLAT_VERSATILE) += versatile/
+obj-$(CONFIG_ARCH_ZX) += zte/
diff --git a/drivers/soc/zte/Kconfig b/drivers/soc/zte/Kconfig
new file mode 100644
index 0000000..20bde38
--- /dev/null
+++ b/drivers/soc/zte/Kconfig
@@ -0,0 +1,13 @@
+#
+# ZTE SoC drivers
+#
+menuconfig SOC_ZTE
+ bool "ZTE SoC driver support"
+
+if SOC_ZTE
+
+config ZX2967_PM_DOMAINS
+ bool "ZX2967 PM domains"
+ depends on PM_GENERIC_DOMAINS
+
+endif
diff --git a/drivers/soc/zte/Makefile b/drivers/soc/zte/Makefile
new file mode 100644
index 0000000..8a37f2f
--- /dev/null
+++ b/drivers/soc/zte/Makefile
@@ -0,0 +1,4 @@
+#
+# ZTE SOC drivers
+#
+obj-$(CONFIG_ZX2967_PM_DOMAINS) += zx2967_pm_domains.o
diff --git a/drivers/soc/zte/zx2967_pm_domains.c b/drivers/soc/zte/zx2967_pm_domains.c
new file mode 100644
index 0000000..a215875
--- /dev/null
+++ b/drivers/soc/zte/zx2967_pm_domains.c
@@ -0,0 +1,139 @@
+/*
+ * Copyright (C) 2017 ZTE Ltd.
+ *
+ * Author: Baoyou Xie <baoyou.xie-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
+ * License terms: GNU General Public License (GPL) version 2
+ */
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/of.h>
+
+#include "zx2967_pm_domains.h"
+
+#define PCU_DM_CLKEN(zpd) ((zpd)->reg_offset[REG_CLKEN])
+#define PCU_DM_ISOEN(zpd) ((zpd)->reg_offset[REG_ISOEN])
+#define PCU_DM_RSTEN(zpd) ((zpd)->reg_offset[REG_RSTEN])
+#define PCU_DM_PWREN(zpd) ((zpd)->reg_offset[REG_PWREN])
+#define PCU_DM_PWRDN(zpd) ((zpd)->reg_offset[REG_PWRDN])
+#define PCU_DM_ACK_SYNC(zpd) ((zpd)->reg_offset[REG_ACK_SYNC])
+
+static void __iomem *pcubase;
+
+int zx2967_power_on(struct generic_pm_domain *domain)
+{
+ struct zx2967_pm_domain *zpd = (struct zx2967_pm_domain *)domain;
+ unsigned long loop = 1000;
+ u32 val;
+
+ val = readl_relaxed(pcubase + PCU_DM_PWREN(zpd));
+ if (zpd->polarity == PWREN)
+ val |= BIT(zpd->bit);
+ else
+ val &= ~BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_PWREN(zpd));
+
+ do {
+ udelay(1);
+ val = readl_relaxed(pcubase + PCU_DM_ACK_SYNC(zpd))
+ & BIT(zpd->bit);
+ } while (--loop && !val);
+
+ if (!loop) {
+ pr_err("Error: %s %s fail\n", __func__, domain->name);
+ return -EIO;
+ }
+
+ val = readl_relaxed(pcubase + PCU_DM_RSTEN(zpd));
+ val |= BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_RSTEN(zpd));
+ udelay(5);
+
+ val = readl_relaxed(pcubase + PCU_DM_ISOEN(zpd));
+ val &= ~BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_ISOEN(zpd));
+ udelay(5);
+
+ val = readl_relaxed(pcubase + PCU_DM_CLKEN(zpd));
+ val |= BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_CLKEN(zpd));
+ udelay(5);
+
+ pr_debug("normal poweron %s\n", domain->name);
+
+ return 0;
+}
+
+int zx2967_power_off(struct generic_pm_domain *domain)
+{
+ struct zx2967_pm_domain *zpd = (struct zx2967_pm_domain *)domain;
+ unsigned long loop = 1000;
+ u32 val;
+
+ val = readl_relaxed(pcubase + PCU_DM_CLKEN(zpd));
+ val &= ~BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_CLKEN(zpd));
+ udelay(5);
+
+ val = readl_relaxed(pcubase + PCU_DM_ISOEN(zpd));
+ val |= BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_ISOEN(zpd));
+ udelay(5);
+
+ val = readl_relaxed(pcubase + PCU_DM_RSTEN(zpd));
+ val &= ~BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_RSTEN(zpd));
+ udelay(5);
+
+ val = readl_relaxed(pcubase + PCU_DM_PWREN(zpd));
+ if (zpd->polarity == PWREN)
+ val &= ~BIT(zpd->bit);
+ else
+ val |= BIT(zpd->bit);
+ writel_relaxed(val, pcubase + PCU_DM_PWREN(zpd));
+
+ do {
+ udelay(1);
+ val = readl_relaxed(pcubase + PCU_DM_ACK_SYNC(zpd))
+ & BIT(zpd->bit);
+ } while (--loop && val);
+
+ if (!loop) {
+ pr_err("Error: %s %s fail\n", __func__, domain->name);
+ return -EIO;
+ }
+
+ pr_debug("normal poweroff %s\n", domain->name);
+
+ return 0;
+}
+
+int zx2967_pd_probe(struct platform_device *pdev,
+ struct generic_pm_domain **zx_pm_domains,
+ int domain_num)
+{
+ struct genpd_onecell_data *genpd_data;
+ struct resource *res;
+ int i;
+
+ genpd_data = devm_kzalloc(&pdev->dev, sizeof(*genpd_data), GFP_KERNEL);
+ if (!genpd_data)
+ return -ENOMEM;
+
+ genpd_data->domains = zx_pm_domains;
+ genpd_data->num_domains = domain_num;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ pcubase = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(pcubase)) {
+ dev_err(&pdev->dev, "ioremap fail.\n");
+ return PTR_ERR(pcubase);
+ }
+
+ for (i = 0; i < domain_num; ++i)
+ pm_genpd_init(zx_pm_domains[i], NULL, false);
+
+ of_genpd_add_provider_onecell(pdev->dev.of_node, genpd_data);
+ dev_info(&pdev->dev, "powerdomain init ok\n");
+ return 0;
+}
diff --git a/drivers/soc/zte/zx2967_pm_domains.h b/drivers/soc/zte/zx2967_pm_domains.h
new file mode 100644
index 0000000..81ad4d6
--- /dev/null
+++ b/drivers/soc/zte/zx2967_pm_domains.h
@@ -0,0 +1,46 @@
+/*
+ * Header for ZTE's Power Domain Driver support
+ *
+ * Copyright (C) 2017 ZTE Ltd.
+ *
+ * Author: Baoyou Xie <baoyou.xie-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
+ * License terms: GNU General Public License (GPL) version 2
+ */
+
+#ifndef __ZTE_ZX2967_PM_DOMAIN_H
+#define __ZTE_ZX2967_PM_DOMAIN_H
+
+#include <linux/platform_device.h>
+#include <linux/pm_domain.h>
+
+enum {
+ REG_CLKEN,
+ REG_ISOEN,
+ REG_RSTEN,
+ REG_PWREN,
+ REG_PWRDN,
+ REG_ACK_SYNC,
+
+ /* The size of the array - must be last */
+ REG_ARRAY_SIZE,
+};
+
+enum zx2967_power_polarity {
+ PWREN,
+ PWRDN,
+};
+
+struct zx2967_pm_domain {
+ struct generic_pm_domain dm;
+ const u16 bit;
+ const enum zx2967_power_polarity polarity;
+ const u16 *reg_offset;
+};
+
+extern int zx2967_power_on(struct generic_pm_domain *domain);
+extern int zx2967_power_off(struct generic_pm_domain *domain);
+extern int zx2967_pd_probe(struct platform_device *pdev,
+ struct generic_pm_domain **zx_pm_domains,
+ int domain_num);
+
+#endif /* __ZTE_ZX2967_PM_DOMAIN_H */
--
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 v5 3/4] soc: zte: pm_domains: Add support for zx296718 board
From: Baoyou Xie @ 2017-01-04 0:19 UTC (permalink / raw)
To: jun.nie, robh+dt, mark.rutland, gregkh, davem, geert+renesas,
akpm, mchehab, linux, krzk, arnd, linus.walleij, pankaj.dubey,
yangbo.lu, f.fainelli, claudiu.manoil, laurent.pinchart+renesas
Cc: devicetree, xie.baoyou, linux-kernel, chen.chaokai, wang.qiang01,
baoyou.xie, shawnguo, linux-arm-kernel
In-Reply-To: <1483489157-10782-1-git-send-email-baoyou.xie@linaro.org>
This patch introduces the power domain driver of zx296718
which belongs to zte's zx2967 family.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
Reviewed-by: Shawn Guo <shawnguo@kernel.org>
Reviewed-by: Jun Nie <jun.nie@linaro.org>
---
drivers/soc/zte/Makefile | 2 +-
drivers/soc/zte/zx296718_pm_domains.c | 194 ++++++++++++++++++++++++++++++++++
2 files changed, 195 insertions(+), 1 deletion(-)
create mode 100644 drivers/soc/zte/zx296718_pm_domains.c
diff --git a/drivers/soc/zte/Makefile b/drivers/soc/zte/Makefile
index 8a37f2f..f399553 100644
--- a/drivers/soc/zte/Makefile
+++ b/drivers/soc/zte/Makefile
@@ -1,4 +1,4 @@
#
# ZTE SOC drivers
#
-obj-$(CONFIG_ZX2967_PM_DOMAINS) += zx2967_pm_domains.o
+obj-$(CONFIG_ZX2967_PM_DOMAINS) += zx2967_pm_domains.o zx296718_pm_domains.o
diff --git a/drivers/soc/zte/zx296718_pm_domains.c b/drivers/soc/zte/zx296718_pm_domains.c
new file mode 100644
index 0000000..626e6ce
--- /dev/null
+++ b/drivers/soc/zte/zx296718_pm_domains.c
@@ -0,0 +1,194 @@
+/*
+ * Copyright (C) 2017 ZTE Ltd.
+ *
+ * Author: Baoyou Xie <baoyou.xie@linaro.org>
+ * License terms: GNU General Public License (GPL) version 2
+ */
+#include <dt-bindings/soc/zte,pm_domains.h>
+#include "zx2967_pm_domains.h"
+
+static u16 zx296718_offsets[REG_ARRAY_SIZE] = {
+ [REG_CLKEN] = 0x18,
+ [REG_ISOEN] = 0x1c,
+ [REG_RSTEN] = 0x20,
+ [REG_PWREN] = 0x24,
+ [REG_ACK_SYNC] = 0x28,
+};
+
+enum {
+ PCU_DM_VOU = 0,
+ PCU_DM_SAPPU,
+ PCU_DM_VDE,
+ PCU_DM_VCE,
+ PCU_DM_HDE,
+ PCU_DM_VIU,
+ PCU_DM_USB20,
+ PCU_DM_USB21,
+ PCU_DM_USB30,
+ PCU_DM_HSIC,
+ PCU_DM_GMAC,
+ PCU_DM_TS,
+};
+
+static struct zx2967_pm_domain vou_domain = {
+ .dm = {
+ .name = "vou_domain",
+ .power_off = zx2967_power_off,
+ .power_on = zx2967_power_on,
+ },
+ .bit = PCU_DM_VOU,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+static struct zx2967_pm_domain sappu_domain = {
+ .dm = {
+ .name = "sappu_domain",
+ .power_off = zx2967_power_off,
+ .power_on = zx2967_power_on,
+ },
+ .bit = PCU_DM_SAPPU,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+static struct zx2967_pm_domain vde_domain = {
+ .dm = {
+ .name = "vde_domain",
+ .power_off = zx2967_power_off,
+ .power_on = zx2967_power_on,
+ },
+ .bit = PCU_DM_VDE,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+static struct zx2967_pm_domain vce_domain = {
+ .dm = {
+ .name = "vce_domain",
+ .power_off = zx2967_power_off,
+ .power_on = zx2967_power_on,
+ },
+ .bit = PCU_DM_VCE,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+static struct zx2967_pm_domain hde_domain = {
+ .dm = {
+ .name = "hde_domain",
+ .power_off = zx2967_power_off,
+ .power_on = zx2967_power_on,
+ },
+ .bit = PCU_DM_HDE,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+
+static struct zx2967_pm_domain viu_domain = {
+ .dm = {
+ .name = "viu_domain",
+ .power_off = zx2967_power_off,
+ .power_on = zx2967_power_on,
+ },
+ .bit = PCU_DM_VIU,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+static struct zx2967_pm_domain usb20_domain = {
+ .dm = {
+ .name = "usb20_domain",
+ .power_off = zx2967_power_off,
+ .power_on = zx2967_power_on,
+ },
+ .bit = PCU_DM_USB20,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+static struct zx2967_pm_domain usb21_domain = {
+ .dm = {
+ .name = "usb21_domain",
+ .power_off = zx2967_power_off,
+ .power_on = zx2967_power_on,
+ },
+ .bit = PCU_DM_USB21,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+static struct zx2967_pm_domain usb30_domain = {
+ .dm = {
+ .name = "usb30_domain",
+ .power_off = zx2967_power_off,
+ .power_on = zx2967_power_on,
+ },
+ .bit = PCU_DM_USB30,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+static struct zx2967_pm_domain hsic_domain = {
+ .dm = {
+ .name = "hsic_domain",
+ .power_off = zx2967_power_off,
+ .power_on = zx2967_power_on,
+ },
+ .bit = PCU_DM_HSIC,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+static struct zx2967_pm_domain gmac_domain = {
+ .dm = {
+ .name = "gmac_domain",
+ .power_off = zx2967_power_off,
+ .power_on = zx2967_power_on,
+ },
+ .bit = PCU_DM_GMAC,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+static struct zx2967_pm_domain ts_domain = {
+ .dm = {
+ .name = "ts_domain",
+ .power_off = zx2967_power_off,
+ .power_on = zx2967_power_on,
+ },
+ .bit = PCU_DM_TS,
+ .polarity = PWREN,
+ .reg_offset = zx296718_offsets,
+};
+struct generic_pm_domain *zx296718_pm_domains[] = {
+ [DM_ZX296718_SAPPU] = &sappu_domain.dm,
+ [DM_ZX296718_VDE] = &vde_domain.dm,
+ [DM_ZX296718_VCE] = &vce_domain.dm,
+ [DM_ZX296718_HDE] = &hde_domain.dm,
+ [DM_ZX296718_VIU] = &viu_domain.dm,
+ [DM_ZX296718_USB20] = &usb20_domain.dm,
+ [DM_ZX296718_USB21] = &usb21_domain.dm,
+ [DM_ZX296718_USB30] = &usb30_domain.dm,
+ [DM_ZX296718_HSIC] = &hsic_domain.dm,
+ [DM_ZX296718_GMAC] = &gmac_domain.dm,
+ [DM_ZX296718_TS] = &ts_domain.dm,
+ [DM_ZX296718_VOU] = &vou_domain.dm,
+};
+
+static int zx296718_pd_probe(struct platform_device *pdev)
+{
+ return zx2967_pd_probe(pdev,
+ zx296718_pm_domains,
+ ARRAY_SIZE(zx296718_pm_domains));
+}
+
+static const struct of_device_id zx296718_pm_domain_matches[] = {
+ { .compatible = "zte,zx296718-pcu", },
+ { },
+};
+
+static struct platform_driver zx296718_pd_driver = {
+ .driver = {
+ .name = "zx-powerdomain",
+ .owner = THIS_MODULE,
+ .of_match_table = zx296718_pm_domain_matches,
+ },
+ .probe = zx296718_pd_probe,
+};
+
+static int __init zx296718_pd_init(void)
+{
+ return platform_driver_register(&zx296718_pd_driver);
+}
+subsys_initcall(zx296718_pd_init);
--
2.7.4
^ permalink raw reply related
* [PATCH v5 4/4] MAINTAINERS: add zx2967 SoC drivers to ARM ZTE architecture
From: Baoyou Xie @ 2017-01-04 0:19 UTC (permalink / raw)
To: jun.nie, robh+dt, mark.rutland, gregkh, davem, geert+renesas,
akpm, mchehab, linux, krzk, arnd, linus.walleij, pankaj.dubey,
yangbo.lu, f.fainelli, claudiu.manoil, laurent.pinchart+renesas
Cc: devicetree, xie.baoyou, linux-kernel, chen.chaokai, wang.qiang01,
baoyou.xie, shawnguo, linux-arm-kernel
In-Reply-To: <1483489157-10782-1-git-send-email-baoyou.xie@linaro.org>
Add the ZTE SoC drivers as maintained by ARM ZTE
architecture maintainers, as they're parts of the core IP.
By the way, this patch adds the maintainer for ARM
ZTE architecture to Baoyou Xie.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
MAINTAINERS | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index ad199da..64f04df 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1975,12 +1975,16 @@ F: arch/arm/mach-pxa/include/mach/z2.h
ARM/ZTE ARCHITECTURE
M: Jun Nie <jun.nie@linaro.org>
+M: Baoyou Xie <baoyou.xie@linaro.org>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
F: arch/arm/mach-zx/
F: drivers/clk/zte/
+F: drivers/soc/zte/
F: Documentation/devicetree/bindings/arm/zte.txt
F: Documentation/devicetree/bindings/clock/zx296702-clk.txt
+F: Documentation/devicetree/bindings/soc/zte/
+F: include/dt-bindings/soc/zx*.h
ARM/ZYNQ ARCHITECTURE
M: Michal Simek <michal.simek@xilinx.com>
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 3/5] arm64: dts: sun50i: add MMC nodes
From: André Przywara @ 2017-01-04 0:22 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Maxime Ripard, Ulf Hansson, Hans De Goede, Icenowy Zheng,
Mark Rutland, Rob Herring, devicetree,
linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel, linux-sunxi, linux-kernel
In-Reply-To: <CAGb2v65GAvyDn1oMXy2cpOD5PFRoYYOk-VbsMPAX3SNFz2ukLg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 03/01/17 13:28, Chen-Yu Tsai wrote:
> On Tue, Jan 3, 2017 at 6:48 PM, André Przywara <andre.przywara@arm.com> wrote:
>> On 03/01/17 02:52, Chen-Yu Tsai wrote:
Hi Chen-Yu,
>>> On Tue, Jan 3, 2017 at 7:03 AM, Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org> wrote:
>>>
>>> A commit message explaining the mmc controllers would be nice.
>>
>> OK.
>>
>>>> Signed-off-by: Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org>
>>>> ---
>>>> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 67 +++++++++++++++++++++++++++
>>>> 1 file changed, 67 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>>>> index e0dcab8..c680566 100644
>>>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>>>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>>>> @@ -150,6 +150,32 @@
>>>> pins = "PB8", "PB9";
>>>> function = "uart0";
>>>> };
>>>> +
>>>> + mmc0_pins: mmc0@0 {
>>>> + pins = "PF0", "PF1", "PF2", "PF3", "PF4", "PF5";
>>>> + function = "mmc0";
>>>> + drive-strength = <30>;
>>>> + };
>>>> +
>>>> + mmc0_default_cd_pin: mmc0_cd_pin@0 {
>>>> + pins = "PF6";
>>>> + function = "gpio_in";
>>>> + bias-pull-up;
>>>> + };
>>>
>>> We are starting to drop pinmux nodes for gpio usage.
>>
>> And replacing them with what?
>> Or do you mean they go in the individual board .dts files?
>> In this case I believe having a default pin defined here would help to
>> define it in every .dts.
>
> Nope. I meant dropping them. Pinmux and gpio are orthogonal. One should not
> need to specify a gpio pinmux to use it as a gpio. We added them because in
> the past nothing was preventing someone from claiming an already muxed pin
> as a gpio. On some platforms this is fine. For sunxi, this breaks the system,
> as the gpio functions are muxed in.
>
> The idea moving forward is that these cases should be guarded in the driver.
Ah, OK, you mean just referencing the pin like:
cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
in the board DT is enough? And the driver claiming it will (eventually?)
prevent users from using them via the sysfs interface then?
> Of course we would have to deal with existing dtbs, but lets not add any more.
>
>>>> +
>>>> + mmc1_pins: mmc1@0 {
>>>> + pins = "PG0", "PG1", "PG2", "PG3", "PG4", "PG5";
>>>> + function = "mmc1";
>>>> + drive-strength = <30>;
>>>> + };
>>>> +
>>>> + mmc2_pins: mmc2@0 {
>>>> + pins = "PC1", "PC5", "PC6", "PC8", "PC9",
>>>> + "PC10", "PC11", "PC12", "PC13", "PC14",
>>>> + "PC15", "PC16";
>>>> + function = "mmc2";
>>>> + drive-strength = <30>;
>>>> + };
>>>
>>> Moreover I think you should split out the pinmux nodes to a separate patch.
>>
>> I can surely do, just wondering what's the rationale is behind that?
>
> More or less the "do one thing in one patch" rationale. Of course you can
> claim these are the defaults used in the reference design and pretty much
> every board out there. Then it makes sense to do them together. :)
Mmmh, probably a misunderstanding, but:
Those pins are the possible pins that expose the MMC interface. Those
nodes here name them to allow easy and concise reference by a board DT
(as in the following patch).
And in fact in case of the A64 there are _no_ alternative muxes for the
three MMC controllers: SDC0 is only on PF0-5, SDC1 on PG0-PG5 and SDC2
on PC1-PC16.
So it's not a board design question, apart from using a controller or not.
That's why I rather keep them together with the MMC controller nodes.
>>>
>>>> };
>>>>
>>>> uart0: serial@1c28000 {
>>>> @@ -240,6 +266,47 @@
>>>> #size-cells = <0>;
>>>> };
>>>>
>>>> + mmc0: mmc@1c0f000 {
>>>> + compatible = "allwinner,sun50i-a64-mmc",
>>>> + "allwinner,sun5i-a13-mmc";
>>>
>>> Given that sun5i doesn't support mmc delay timings, and the A64 has
>>> calibration and delay timings, I wouldn't call them compatible.
>>>
>>> Or are you claiming that for the A64 has a delay of 0 for the
>>> currently supported speeds, so the calibration doesn't really
>>> matter? If so this should be mentioned in the commit message.
>>
>> Yes, that's my observation: Driving it with sun5-a13-mmc just works.
>> This sun5i driver version does not (and will never) support higher
>> transfer modes anyway, so for that subset they are compatible. This
>> opens up the door to other operating systems not having a particular
>> driver for the A64, for instance, also older Linux kernels.
>> I know that sunxi doesn't use this compatible feature much, but IMHO we
>> should really start thinking about the DT not just being Linux specific
>> - or even being specific to a certain Linux version. And this case here
>> is a good example: An A13 MMC driver can drive this device - if there is
>> no better driver (an A64 one) available.
>
> Cool. Please put this in the commit log. :)
Noted for a repost.
>>
>>>
>>>> + reg = <0x01c0f000 0x1000>;
>>>> + clocks = <&ccu 31>, <&ccu 75>;
>>>
>>> The clock / reset index macros are in the tree now.
>>> Please switch to them.
>>
>> The include file is in the tree, but it isn't used in the current HEAD
>> (as in #included and the actual macros being used in the .dtsi).
>> So I was wondering if there is a patch pending for that?
>
> Not yet I think. Perhaps Maxime will do one once he gets back from vacation?
Seems like everybody hopes for it and nobody bothers with this rather
trivial patch ;-)
Frankly I am not overly keen on having all those defines in the DTs,
which rely on a bunch of include files scattered over the Linux include
tree. This makes it unnecessarily complicated to compile this out of
tree or move it over to some other piece of software (other OS, U-Boot).
Also it gives people the impression that it's fine to change the
definition in the include file at will (because it looks like Linux
territory).
Eventually some file has to hold the actual hardware information, I
don't see why this shouldn't be the one .dtsi file. Reading that the
clock for MMC controller 0 is MMC0_CLK isn't very informative.
Cheers,
Andre.
>>>> + clock-names = "ahb", "mmc";
>>>> + resets = <&ccu 8>;
>>>> + reset-names = "ahb";
>>>> + interrupts = <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
>>>> + status = "disabled";
>>>> + #address-cells = <1>;
>>>> + #size-cells = <0>;
>>>> + };
>>>> +
>>>> + mmc1: mmc@1c10000 {
>>>> + compatible = "allwinner,sun50i-a64-mmc",
>>>> + "allwinner,sun5i-a13-mmc";
>>>> + reg = <0x01c10000 0x1000>;
>>>> + clocks = <&ccu 32>, <&ccu 76>;
>>>> + clock-names = "ahb", "mmc";
>>>> + resets = <&ccu 9>;
>>>> + reset-names = "ahb";
>>>> + interrupts = <GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>;
>>>> + status = "disabled";
>>>> + #address-cells = <1>;
>>>> + #size-cells = <0>;
>>>> + };
>>>> +
>>>> + mmc2: mmc@1c11000 {
>>>> + compatible = "allwinner,sun50i-a64-emmc";
>>>> + reg = <0x01c11000 0x1000>;
>>>> + clocks = <&ccu 33>, <&ccu 77>;
>>>> + clock-names = "ahb", "mmc";
>>>> + resets = <&ccu 10>;
>>>> + reset-names = "ahb";
>>>> + interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>;
>>>> + status = "disabled";
>>>> + #address-cells = <1>;
>>>> + #size-cells = <0>;
>>>> + };
>>>> +
>>>> gic: interrupt-controller@1c81000 {
>>>> compatible = "arm,gic-400";
>>>> reg = <0x01c81000 0x1000>,
>>>> --
>>>> 2.8.2
>>>>
>>
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH 2/4] ARM: dts: Add am335x-boneblack-wireless
From: Tony Lindgren @ 2017-01-04 0:41 UTC (permalink / raw)
To: Jason Kridner
Cc: Jason Kridner, Robert Nelson, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-omap-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CA+T6QPnTS-XyV0G9X78hAh=D79TkZkU+evN2RA6VF3f_jyBtkA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
* Jason Kridner <jkridner-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> [170103 12:58]:
> Asked-by: Jason Kridner <jdk-l0cyMroinI0@public.gmane.org>
>
> Sorry for the phone mailer (HTML).
OK fixed that to Acked-by :) Applied into omap-for-v4.11/dt and pushed
out.
BBB Green Wireless seems to work nicely for WLAN out of the box with
these patches :)
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
* [PATCH 0/3] GPIO: Add driver for ThunderX and OCTEON-TX SoCs
From: David Daney @ 2017-01-04 0:55 UTC (permalink / raw)
To: Linus Walleij, Alexandre Courbot, Rob Herring, Mark Rutland,
linux-gpio, devicetree, linux-kernel
Cc: David Daney
From: David Daney <david.daney@cavium.com>
The subject says it all. The Cavium ThunderX and OCTEON-TX family of
SoCs have on-chip GPIO lines. This patch set adds a driver for these.
David Daney (3):
dt-bindings: gpio: Add binding documentation for gpio-thunderx
gpio: Add gpio driver support for ThunderX and OCTEON-TX
MAINTAINERS: Add entry for THUNDERX GPIO Driver.
.../devicetree/bindings/gpio/gpio-thunderx.txt | 33 ++
MAINTAINERS | 5 +
drivers/gpio/Kconfig | 7 +
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-thunderx.c | 467 +++++++++++++++++++++
5 files changed, 513 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-thunderx.txt
create mode 100644 drivers/gpio/gpio-thunderx.c
--
1.8.3.1
^ permalink raw reply
* [PATCH 1/3] dt-bindings: gpio: Add binding documentation for gpio-thunderx
From: David Daney @ 2017-01-04 0:55 UTC (permalink / raw)
To: Linus Walleij, Alexandre Courbot, Rob Herring, Mark Rutland,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: David Daney
In-Reply-To: <1483491334-167095-1-git-send-email-ddaney.cavm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: David Daney <david.daney-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
Signed-off-by: David Daney <david.daney-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
---
.../devicetree/bindings/gpio/gpio-thunderx.txt | 33 ++++++++++++++++++++++
1 file changed, 33 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-thunderx.txt
diff --git a/Documentation/devicetree/bindings/gpio/gpio-thunderx.txt b/Documentation/devicetree/bindings/gpio/gpio-thunderx.txt
new file mode 100644
index 0000000..ba3cdae
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-thunderx.txt
@@ -0,0 +1,33 @@
+Cavium ThunderX/OCTEON-TX GPIO controller bindings
+
+Required Properties:
+- reg: The controller bus address.
+- gpio-controller: Marks the device node as a GPIO controller.
+- #gpio-cells: Must be 2.
+ - First cell is the GPIO pin number relative to the controller.
+ - Second cell is standard of_gpio_flags:
+ 1 - Active Low.
+ 2 - Single Ended.
+
+Optional Properties:
+- compatible: "cavium,thunder-8890-gpio", unused as PCI driver binding is used.
+- interrupt-controller: Marks the device node as an interrupt controller.
+- #interrupt-cells: Must be present and have value of 2 if
+ "interrupt-controller" is present.
+ - First cell is the GPIO pin number relative to the controller.
+ - Second cell is triggering flags, one of:
+ 1 - Edge Rising
+ 2 - Edge Falling
+ 4 - Level High
+ 8 - Level Low
+
+Example:
+
+gpio_6_0: gpio0@6,0 {
+ compatible = "cavium,thunder-8890-gpio";
+ reg = <0x3000 0 0 0 0>; /* DEVFN = 0x30 (6:0) */
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+};
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 2/3] gpio: Add gpio driver support for ThunderX and OCTEON-TX
From: David Daney @ 2017-01-04 0:55 UTC (permalink / raw)
To: Linus Walleij, Alexandre Courbot, Rob Herring, Mark Rutland,
linux-gpio, devicetree, linux-kernel
Cc: David Daney
In-Reply-To: <1483491334-167095-1-git-send-email-ddaney.cavm@gmail.com>
From: David Daney <david.daney@cavium.com>
Cavium ThunderX and OCTEON-TX are arm64 based SoCs. Add driver for
the on-chip GPIO pins.
Signed-off-by: David Daney <david.daney@cavium.com>
---
drivers/gpio/Kconfig | 7 +
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-thunderx.c | 467 +++++++++++++++++++++++++++++++++++++++++++
3 files changed, 475 insertions(+)
create mode 100644 drivers/gpio/gpio-thunderx.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index ed37e59..6655477 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -421,6 +421,13 @@ config GPIO_TS4800
help
This driver support TS-4800 FPGA GPIO controllers.
+config GPIO_THUNDERX
+ tristate "Cavium ThunderX/OCTEON-TX GPIO"
+ depends on ARCH_THUNDER || (64BIT && COMPILE_TEST)
+ help
+ Say yes here to support the on-chip GPIO lines on the ThunderX
+ and OCTEON-TX families of SoCs.
+
config GPIO_TZ1090
bool "Toumaz Xenif TZ1090 GPIO support"
depends on SOC_TZ1090
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index d074c22..ab387bf 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -107,6 +107,7 @@ obj-$(CONFIG_GPIO_SYSCON) += gpio-syscon.o
obj-$(CONFIG_GPIO_TB10X) += gpio-tb10x.o
obj-$(CONFIG_GPIO_TC3589X) += gpio-tc3589x.o
obj-$(CONFIG_GPIO_TEGRA) += gpio-tegra.o
+obj-$(CONFIG_GPIO_THUNDERX) += gpio-thunderx.o
obj-$(CONFIG_GPIO_TIMBERDALE) += gpio-timberdale.o
obj-$(CONFIG_GPIO_PALMAS) += gpio-palmas.o
obj-$(CONFIG_GPIO_TPIC2810) += gpio-tpic2810.o
diff --git a/drivers/gpio/gpio-thunderx.c b/drivers/gpio/gpio-thunderx.c
new file mode 100644
index 0000000..7830f4d
--- /dev/null
+++ b/drivers/gpio/gpio-thunderx.c
@@ -0,0 +1,467 @@
+/*
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file "COPYING" in the main directory of this archive
+ * for more details.
+ *
+ * Copyright (C) 2016 Cavium Inc.
+ */
+
+#include <linux/interrupt.h>
+#include <linux/spinlock.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/gpio.h>
+#include <linux/irq.h>
+#include <linux/pci.h>
+#include <linux/io.h>
+
+
+#define GPIO_RX_DAT 0x0
+#define GPIO_TX_SET 0x8
+#define GPIO_TX_CLR 0x10
+#define GPIO_CONST 0x90
+#define GPIO_CONST_GPIOS_MASK 0xff
+#define GPIO_BIT_CFG 0x400
+#define GPIO_BIT_CFG_TX_OE BIT(0)
+#define GPIO_BIT_CFG_PIN_XOR BIT(1)
+#define GPIO_BIT_CFG_INT_EN BIT(2)
+#define GPIO_BIT_CFG_INT_TYPE BIT(3)
+#define GPIO_BIT_CFG_FIL_CNT_SHIFT 4
+#define GPIO_BIT_CFG_FIL_SEL_SHIFT 8
+#define GPIO_BIT_CFG_TX_OD BIT(12)
+#define GPIO_BIT_CFG_PIN_SEL_MASK GENMASK(25, 16)
+#define GPIO_INTR 0x800
+#define GPIO_INTR_INTR BIT(0)
+#define GPIO_INTR_INTR_W1S BIT(1)
+#define GPIO_INTR_ENA_W1C BIT(2)
+#define GPIO_INTR_ENA_W1S BIT(3)
+#define GPIO_2ND_BANK 0x1400
+
+#define GLITCH_FILTER_400NS ((4ull << GPIO_BIT_CFG_FIL_SEL_SHIFT) | \
+ (9ull << GPIO_BIT_CFG_FIL_CNT_SHIFT))
+
+/*
+ * The address offset of the GPIO configuration register for a given
+ * line.
+ */
+static unsigned int bit_cfg_reg(unsigned int line)
+{
+ return 8 * line + GPIO_BIT_CFG;
+}
+
+static unsigned int intr_reg(unsigned int line)
+{
+ return 8 * line + GPIO_INTR;
+}
+
+struct thunderx_gpio;
+
+struct thunderx_irqdev {
+ struct thunderx_gpio *gpio;
+ char *name;
+ unsigned int line;
+};
+
+struct thunderx_gpio {
+ struct gpio_chip chip;
+ u8 __iomem *register_base;
+ struct msix_entry *msix_entries;
+ struct thunderx_irqdev *irqdev_entries;
+ raw_spinlock_t lock;
+ unsigned long invert_mask[2];
+ unsigned long od_mask[2];
+ int base_msi;
+};
+
+static bool thunderx_gpio_is_gpio(struct thunderx_gpio *gpio, unsigned int line)
+{
+ u64 bit_cfg = readq(gpio->register_base + bit_cfg_reg(line));
+ bool rv = (bit_cfg & GPIO_BIT_CFG_PIN_SEL_MASK) == 0;
+
+ WARN_RATELIMIT(!rv, "Pin %d not available for GPIO\n", line);
+
+ return rv;
+}
+
+static int thunderx_gpio_dir_in(struct gpio_chip *chip, unsigned int line)
+{
+ struct thunderx_gpio *gpio = container_of(chip, struct thunderx_gpio, chip);
+
+ if (!thunderx_gpio_is_gpio(gpio, line))
+ return -EIO;
+
+ raw_spin_lock(&gpio->lock);
+ clear_bit(line, gpio->invert_mask);
+ clear_bit(line, gpio->od_mask);
+ writeq(GLITCH_FILTER_400NS, gpio->register_base + bit_cfg_reg(line));
+ raw_spin_unlock(&gpio->lock);
+ return 0;
+}
+
+static void thunderx_gpio_set(struct gpio_chip *chip, unsigned int line,
+ int value)
+{
+ struct thunderx_gpio *gpio = container_of(chip, struct thunderx_gpio, chip);
+ int bank = line / 64;
+ int bank_bit = line % 64;
+
+ void __iomem *reg = gpio->register_base +
+ (bank * GPIO_2ND_BANK) + (value ? GPIO_TX_SET : GPIO_TX_CLR);
+
+ writeq(1ull << bank_bit, reg);
+}
+
+static int thunderx_gpio_dir_out(struct gpio_chip *chip, unsigned int line,
+ int value)
+{
+ struct thunderx_gpio *gpio = container_of(chip, struct thunderx_gpio, chip);
+ u64 bit_cfg = GPIO_BIT_CFG_TX_OE;
+
+ if (!thunderx_gpio_is_gpio(gpio, line))
+ return -EIO;
+
+ raw_spin_lock(&gpio->lock);
+
+ thunderx_gpio_set(chip, line, value);
+
+ if (test_bit(line, gpio->invert_mask))
+ bit_cfg |= GPIO_BIT_CFG_PIN_XOR;
+
+ if (test_bit(line, gpio->od_mask))
+ bit_cfg |= GPIO_BIT_CFG_TX_OD;
+
+ writeq(bit_cfg, gpio->register_base + bit_cfg_reg(line));
+
+ raw_spin_unlock(&gpio->lock);
+ return 0;
+}
+
+static int thunderx_gpio_set_single_ended(struct gpio_chip *chip,
+ unsigned int line,
+ enum single_ended_mode mode)
+{
+ struct thunderx_gpio *gpio = container_of(chip, struct thunderx_gpio, chip);
+
+ if (mode == LINE_MODE_OPEN_SOURCE)
+ return -ENOTSUPP;
+
+ if (!thunderx_gpio_is_gpio(gpio, line))
+ return -EIO;
+
+ raw_spin_lock(&gpio->lock);
+ if (mode == LINE_MODE_OPEN_DRAIN) {
+ set_bit(line, gpio->invert_mask);
+ set_bit(line, gpio->od_mask);
+ } else {
+ clear_bit(line, gpio->invert_mask);
+ clear_bit(line, gpio->od_mask);
+ }
+ raw_spin_unlock(&gpio->lock);
+
+ return 0;
+}
+
+static int thunderx_gpio_get(struct gpio_chip *chip, unsigned int line)
+{
+ struct thunderx_gpio *gpio = container_of(chip, struct thunderx_gpio, chip);
+ int bank = line / 64;
+ int bank_bit = line % 64;
+ u64 read_bits = readq(gpio->register_base + (bank * GPIO_2ND_BANK) + GPIO_RX_DAT);
+
+ read_bits >>= bank_bit;
+
+ if (test_bit(line, gpio->invert_mask))
+ return !(read_bits & 1);
+ else
+ return read_bits & 1;
+}
+
+static void thunderx_gpio_set_multiple(struct gpio_chip *chip,
+ unsigned long *mask, unsigned long *bits)
+{
+ int bank;
+ u64 set_bits, clear_bits;
+ struct thunderx_gpio *gpio = container_of(chip, struct thunderx_gpio, chip);
+
+ for (bank = 0; bank <= (chip->ngpio / 64); bank++) {
+ set_bits = bits[bank] & mask[bank];
+ clear_bits = ~bits[bank] & mask[bank];
+ writeq(set_bits, gpio->register_base + (bank * GPIO_2ND_BANK) + GPIO_TX_SET);
+ writeq(clear_bits, gpio->register_base + (bank * GPIO_2ND_BANK) + GPIO_TX_CLR);
+ }
+}
+
+static irqreturn_t thunderx_gpio_chain_handler(int irq, void *dev)
+{
+ struct thunderx_irqdev *irqdev = dev;
+ int chained_irq;
+ int ret;
+
+ chained_irq = irq_find_mapping(irqdev->gpio->chip.irqdomain, irqdev->line);
+ if (!chained_irq)
+ return IRQ_NONE;
+
+ ret = generic_handle_irq(chained_irq);
+
+ return ret ? IRQ_NONE : IRQ_HANDLED;
+}
+
+static int thunderx_gpio_irq_request_resources(struct irq_data *data)
+{
+ struct gpio_chip *chip = irq_data_get_irq_chip_data(data);
+ struct thunderx_gpio *gpio = container_of(chip, struct thunderx_gpio, chip);
+ unsigned int line = data->hwirq;
+ struct thunderx_irqdev *irqdev;
+ int err;
+
+ if (!thunderx_gpio_is_gpio(gpio, line))
+ return -EIO;
+
+ irqdev = gpio->irqdev_entries + line;
+
+ irqdev->gpio = gpio;
+ irqdev->line = line;
+ irqdev->name = devm_kasprintf(chip->parent, GFP_KERNEL, "gpio-%d", line + chip->base);
+
+ writeq(GPIO_INTR_ENA_W1C, gpio->register_base + intr_reg(line));
+
+ err = devm_request_irq(chip->parent, gpio->msix_entries[line].vector,
+ thunderx_gpio_chain_handler, IRQF_NO_THREAD, irqdev->name, irqdev);
+ return err;
+}
+
+static void thunderx_gpio_irq_release_resources(struct irq_data *data)
+{
+ struct gpio_chip *chip = irq_data_get_irq_chip_data(data);
+ struct thunderx_gpio *gpio = container_of(chip, struct thunderx_gpio, chip);
+ unsigned int line = data->hwirq;
+ struct thunderx_irqdev *irqdev;
+
+ irqdev = gpio->irqdev_entries + line;
+
+ devm_free_irq(chip->parent, gpio->msix_entries[line].vector, irqdev);
+
+ writeq(GPIO_INTR_ENA_W1C, gpio->register_base + intr_reg(line));
+
+ devm_kfree(chip->parent, irqdev->name);
+}
+
+static void thunderx_gpio_irq_ack(struct irq_data *data)
+{
+ struct gpio_chip *chip = irq_data_get_irq_chip_data(data);
+ struct thunderx_gpio *gpio = container_of(chip, struct thunderx_gpio, chip);
+ unsigned int line = data->hwirq;
+
+ writeq(GPIO_INTR_INTR,
+ gpio->register_base + intr_reg(line));
+}
+
+static void thunderx_gpio_irq_mask(struct irq_data *data)
+{
+ struct gpio_chip *chip = irq_data_get_irq_chip_data(data);
+ struct thunderx_gpio *gpio = container_of(chip, struct thunderx_gpio, chip);
+ unsigned int line = data->hwirq;
+
+ writeq(GPIO_INTR_ENA_W1C, gpio->register_base + intr_reg(line));
+}
+
+static void thunderx_gpio_irq_mask_ack(struct irq_data *data)
+{
+ struct gpio_chip *chip = irq_data_get_irq_chip_data(data);
+ struct thunderx_gpio *gpio = container_of(chip, struct thunderx_gpio, chip);
+ unsigned int line = data->hwirq;
+
+ writeq(GPIO_INTR_ENA_W1C | GPIO_INTR_INTR,
+ gpio->register_base + intr_reg(line));
+}
+
+static void thunderx_gpio_irq_unmask(struct irq_data *data)
+{
+ struct gpio_chip *chip = irq_data_get_irq_chip_data(data);
+ struct thunderx_gpio *gpio = container_of(chip, struct thunderx_gpio, chip);
+ unsigned int line = data->hwirq;
+
+ writeq(GPIO_INTR_ENA_W1S, gpio->register_base + intr_reg(line));
+}
+
+static int thunderx_gpio_irq_set_type(struct irq_data *data,
+ unsigned int flow_type)
+{
+ struct gpio_chip *chip = irq_data_get_irq_chip_data(data);
+ struct thunderx_gpio *gpio = container_of(chip, struct thunderx_gpio, chip);
+ unsigned int line = data->hwirq;
+ u64 bit_cfg;
+
+ irqd_set_trigger_type(data, flow_type);
+
+ bit_cfg = GLITCH_FILTER_400NS | GPIO_BIT_CFG_INT_EN;
+
+ if (flow_type & IRQ_TYPE_EDGE_BOTH) {
+ irq_set_handler_locked(data, handle_edge_irq);
+ bit_cfg |= GPIO_BIT_CFG_INT_TYPE;
+ } else {
+ irq_set_handler_locked(data, handle_level_irq);
+ }
+
+ raw_spin_lock(&gpio->lock);
+ if (flow_type & (IRQ_TYPE_EDGE_FALLING | IRQ_TYPE_LEVEL_LOW)) {
+ bit_cfg |= GPIO_BIT_CFG_PIN_XOR;
+ set_bit(line, gpio->invert_mask);
+ } else {
+ clear_bit(line, gpio->invert_mask);
+ }
+ clear_bit(line, gpio->od_mask);
+ writeq(bit_cfg, gpio->register_base + bit_cfg_reg(line));
+ raw_spin_unlock(&gpio->lock);
+
+ return IRQ_SET_MASK_OK;
+}
+
+static struct irq_chip thunderx_gpio_irq_chip = {
+ .name = "GPIO",
+ .irq_enable = thunderx_gpio_irq_unmask,
+ .irq_disable = thunderx_gpio_irq_mask,
+ .irq_ack = thunderx_gpio_irq_ack,
+ .irq_mask = thunderx_gpio_irq_mask,
+ .irq_mask_ack = thunderx_gpio_irq_mask_ack,
+ .irq_unmask = thunderx_gpio_irq_unmask,
+ .irq_set_type = thunderx_gpio_irq_set_type,
+ .irq_request_resources = thunderx_gpio_irq_request_resources,
+ .irq_release_resources = thunderx_gpio_irq_release_resources,
+ .flags = IRQCHIP_SET_TYPE_MASKED
+};
+
+static int thunderx_gpio_probe(struct pci_dev *pdev,
+ const struct pci_device_id *id)
+{
+ void __iomem * const *tbl;
+ struct device *dev = &pdev->dev;
+ struct thunderx_gpio *gpio;
+ struct gpio_chip *chip;
+ int ngpio, i;
+ int err = 0;
+
+ gpio = devm_kzalloc(&pdev->dev, sizeof(*gpio), GFP_KERNEL);
+ if (!gpio)
+ return -ENOMEM;
+
+ raw_spin_lock_init(&gpio->lock);
+ chip = &gpio->chip;
+
+ pci_set_drvdata(pdev, gpio);
+
+ err = pcim_enable_device(pdev);
+ if (err) {
+ dev_err(dev, "Failed to enable PCI device: err %d\n", err);
+ goto out;
+ }
+
+ err = pcim_iomap_regions(pdev, 1 << 0, KBUILD_MODNAME);
+ if (err) {
+ dev_err(dev, "Failed to iomap PCI device: err %d\n", err);
+ goto out;
+ }
+
+ tbl = pcim_iomap_table(pdev);
+ gpio->register_base = tbl[0];
+ if (!gpio->register_base) {
+ dev_err(dev, "Cannot map PCI resource\n");
+ err = -ENOMEM;
+ goto out;
+ }
+
+ if (pdev->subsystem_device == 0xa10a) {
+ /* CN88XX has no GPIO_CONST register*/
+ ngpio = 50;
+ gpio->base_msi = 48;
+ } else {
+ u64 c = readq(gpio->register_base + GPIO_CONST);
+
+ ngpio = c & GPIO_CONST_GPIOS_MASK;
+ gpio->base_msi = (c >> 8) & 0xff;
+ }
+
+ gpio->msix_entries = devm_kzalloc(&pdev->dev, sizeof(struct msix_entry) * ngpio, GFP_KERNEL);
+ if (!gpio->msix_entries) {
+ err = -ENOMEM;
+ goto out;
+ }
+
+ gpio->irqdev_entries = devm_kzalloc(&pdev->dev, sizeof(struct thunderx_irqdev) * ngpio, GFP_KERNEL);
+ if (!gpio->irqdev_entries) {
+ err = -ENOMEM;
+ goto out;
+ }
+
+ for (i = 0; i < ngpio; i++)
+ gpio->msix_entries[i].entry = gpio->base_msi + (2 * i);
+
+ err = pci_enable_msix(pdev, gpio->msix_entries, ngpio);
+ if (err < 0)
+ goto out;
+
+ chip->label = KBUILD_MODNAME;
+ chip->parent = &pdev->dev;
+ chip->owner = THIS_MODULE;
+ chip->base = -1; /* System allocated */
+ chip->can_sleep = false;
+ chip->ngpio = ngpio;
+ chip->direction_input = thunderx_gpio_dir_in;
+ chip->get = thunderx_gpio_get;
+ chip->direction_output = thunderx_gpio_dir_out;
+ chip->set = thunderx_gpio_set;
+ chip->set_multiple = thunderx_gpio_set_multiple;
+ chip->set_single_ended = thunderx_gpio_set_single_ended;
+ err = gpiochip_add(chip);
+ if (err)
+ goto msix_out;
+
+ err = gpiochip_irqchip_add(chip, &thunderx_gpio_irq_chip, 0,
+ handle_level_irq, IRQ_TYPE_NONE);
+ if (err) {
+ dev_err(dev, "gpiochip_irqchip_add failed: %d\n", err);
+ goto irqchip_out;
+ }
+
+ dev_info(&pdev->dev, "ThunderX GPIO: %d lines with base %d.\n",
+ ngpio, chip->base);
+ return 0;
+
+irqchip_out:
+ gpiochip_remove(chip);
+
+msix_out:
+ pci_disable_msix(pdev);
+
+out:
+ pci_set_drvdata(pdev, NULL);
+ return err;
+}
+
+static void thunderx_gpio_remove(struct pci_dev *pdev)
+{
+ struct thunderx_gpio *gpio = pci_get_drvdata(pdev);
+
+ pci_disable_msix(pdev);
+ gpiochip_remove(&gpio->chip);
+ pci_set_drvdata(pdev, NULL);
+}
+
+static const struct pci_device_id thunderx_gpio_id_table[] = {
+ { PCI_DEVICE(PCI_VENDOR_ID_CAVIUM, 0xA00A) },
+ { 0, } /* end of table */
+};
+
+MODULE_DEVICE_TABLE(pci, thunderx_gpio_id_table);
+
+static struct pci_driver thunderx_gpio_driver = {
+ .name = KBUILD_MODNAME,
+ .id_table = thunderx_gpio_id_table,
+ .probe = thunderx_gpio_probe,
+ .remove = thunderx_gpio_remove,
+};
+
+module_pci_driver(thunderx_gpio_driver);
+
+MODULE_DESCRIPTION("Cavium Inc. ThunderX/OCTEON-TX GPIO Driver");
+MODULE_LICENSE("GPL");
--
1.8.3.1
^ permalink raw reply related
* [PATCH 3/3] MAINTAINERS: Add entry for THUNDERX GPIO Driver.
From: David Daney @ 2017-01-04 0:55 UTC (permalink / raw)
To: Linus Walleij, Alexandre Courbot, Rob Herring, Mark Rutland,
linux-gpio, devicetree, linux-kernel
Cc: David Daney
In-Reply-To: <1483491334-167095-1-git-send-email-ddaney.cavm@gmail.com>
From: David Daney <david.daney@cavium.com>
Signed-off-by: David Daney <david.daney@cavium.com>
---
MAINTAINERS | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 63cefa6..41c3208 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10660,6 +10660,11 @@ M: Andreas Noever <andreas.noever@gmail.com>
S: Maintained
F: drivers/thunderbolt/
+THUNDERX GPIO DRIVER
+M: David Daney <david.daney@cavium.com>
+S: Maintained
+F: drivers/gpio/gpio-thunderx.c
+
TI BQ27XXX POWER SUPPLY DRIVER
R: Andrew F. Davis <afd@ti.com>
F: include/linux/power/bq27xxx_battery.h
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH v2 9/9] ARM: sunxi: Convert pinctrl nodes to generic bindings
From: André Przywara @ 2017-01-04 2:16 UTC (permalink / raw)
To: Chen-Yu Tsai, Maxime Ripard
Cc: devicetree, Linus Walleij, linux-kernel,
linux-gpio@vger.kernel.org, linux-arm-kernel
In-Reply-To: <CAGb2v67_4iriM2WS33hUWzNZY8R2WvGjqzntGBPGmNkr1Ryr_w@mail.gmail.com>
On 18/10/16 08:43, Chen-Yu Tsai wrote:
Hi Maxime, Chen-Yu,
I just stumbled over this patch in Maxime's -next tree and think I
missed it before. I guess it's a bit late, but I just wanted to express
my concerns and write out the issues with the current DT approach:
> On Tue, Oct 11, 2016 at 11:46 PM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
>> Now that we can handle the generic pinctrl bindings, convert our DT to it.
Do we really want to do this? This makes the new DTs incompatible to
older kernels, for no good reasons. Or are there any? Does this "lock
muxed pins" functionality (users cannot export GPIOs which are used by a
driver) rely on the new binding?
Anyway ...
I understand that in sunxi world a kernel is always accompanied by a
matching .dtb, but we should really get away from this, as this doesn't
scale and more importantly creates big headaches in arm64 world:
1) Scaling: Providing a board .dtb together with a kernel puts the
burden of board support to each distribution, which means that _every_
distribution needs to ship matching DTs for _every_ board. There are a
lot of Allwinner boards (around 100 these days?), I am not sure every
distribution seriously wants to put every .dtb into some bootloader
accessible directory. Also this kind of defeats the original DT idea,
where the .dtb is provided by firmware and a generic kernel just works
with whatever it gets presented.
Either distributions will not support certain boards because of this or
there is a lot of maintenance churn in distros.
Yes, arm(32) has lived with this for years, but that doesn't mean we
need to keep it this way.
2) Firmware DT: We start to see more and more Allwinner boards with SPI
flash now, which is supposed to hold some firmware bits. This gives the
ultimate opportunity to store the DT in there as well. BUT this relies
on there being _one_ DT (to rule them all). I don't see issues with
older DTs not having full functionality on newer kernels (this would be
a reason for a firmware update), but there should at any given time _one
best_ DT which is a candidate for being burned into the flash.
Otherwise people are stuck with a certain kernel version (range).
As an example in this case: Kernel 4.9 is LTS and will probably be
elected by Debian to be _the_ kernel for the next release and supported
over several years. But it relies on an old style DT (allwinner,pins
properties), newer pinctrl DT nodes will be rejected by the driver.
But for new features (upcoming HDMI support for H3, for instance) to be
usable a newer DT is required, even if an old kernel will ignore those
features. So if the flash provides a new DT, we cannot boot stable
Debian, whereas if the flash provides a legacy DT, we cannot use new
features in newer kernels.
Not changing the DT in a way that breaks forward compatibility can be
done, for instance we just drop this patch here. For new SoCs (like A64
or H5, where there are no backward compatibility issues) we can happily
use the new bindings in the official DTs, but for anything already
supported by older kernels we just stick which what we have. We have to
keep the old support code in anyway.
Yes, providing both forward and backward compatibility is not going to
be a walk in the park, but is inevitable if we want to get those board
out of the toy area. Other platform can cope with this.
3) On EFI setups the generation(!) of the DT is actually done in EFI
firmware (very much like in the original PowerPC OF setup). It is
expected that the generation relies on a static DT scaffold, but
firmware is free to add or remove nodes. Providing different DTs for
each kernel is hard to integrate into this approach.
4) Generic boot images: On the x86 side everybody expects this just to
work: You put in a generic USB stick with one (or two) generic kernels
and it just boots, without this installation having to know each
supported machine beforehand. It even works with machines newer than the
distro. While the last is hard work, it can be done, but only if the DT
is provided by firmware, which requires there to be one best DT for each
board.
5) arm64: Distributions providing support for arm64 machines generally
do not seem to provide DTs, because most platform do not require them
to. It is not clear that every distribution will do so for the sake or
supporting Allwinner boards.
6) Other OSes (or U-Boot) are affected by this as well. Eventually this
will lead them to create their own DTs (and their own bindings?), which
makes this situation really a mess. We can hardly request them to stick
with the Linux bindings if we break them regularly.
7) Dynamic DT alteration (by firmware/U-Boot and using overlays, for
instance), will be much easier if the DT is originally stored in the
firmware and snippets are stored there as well. This is for instance a
use case for the (optional) WiFi module on the Pine64.
8) Those patches also create a lot of potential merge conflicts, since
they touch almost every sunxi DT file. They are trivial to solve,
probably, but still tend to create a lot of work and cause nuisance for
other people (as proven with the A64 CCU driver in this cycle).
So can I ask that we start taking this seriously and stop doing things
which prevent Allwinner boards from being supported properly?
Which would first involve dropping this very patch?
Having done breakage in the past (with "allwinner,sun7i-a20-mmc", for
instance) is no excuse for doing it again. And especially I want to
avoid this habit creeping into the arm64 world (thinking about the H5
here, which may be impacted by this very patch, for instance).
Cheers,
Andre.
^ permalink raw reply
* RE: [PATCH v3 2/3] USB3/DWC3: Add property "snps, incr-burst-type-adjustment" for INCR burst type
From: Jerry Huang @ 2017-01-04 2:24 UTC (permalink / raw)
To: Rob Herring
Cc: balbi-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
mark.rutland-5wv7dgnIgG8@public.gmane.org,
catalin.marinas-5wv7dgnIgG8@public.gmane.org,
will.deacon-5wv7dgnIgG8@public.gmane.org,
linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <CAL_JsqJuifiSQAt-6FgtYYSukAnjzOLuTGEsO-Spn5LxkU-iwQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi, Rob,
> -----Original Message-----
> From: Rob Herring [mailto:robh@kernel.org]
> Sent: Wednesday, January 04, 2017 5:24 AM
> To: Jerry Huang <jerry.huang@nxp.com>
> Cc: balbi@kernel.org; mark.rutland@arm.com; catalin.marinas@arm.com;
> will.deacon@arm.com; linux@armlinux.org.uk; devicetree@vger.kernel.org;
> linux-usb@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
> kernel@lists.infradead.org
> Subject: Re: [PATCH v3 2/3] USB3/DWC3: Add property "snps, incr-burst-
> type-adjustment" for INCR burst type
>
> On Thu, Dec 22, 2016 at 8:52 PM, Jerry Huang <jerry.huang@nxp.com> wrote:
> > Hi, Rob,
> >> -----Original Message-----
> >> From: Rob Herring [mailto:robh@kernel.org]
> >> Sent: Friday, December 23, 2016 2:45 AM
> >> To: Jerry Huang <jerry.huang@nxp.com>
> >> Cc: balbi@kernel.org; mark.rutland@arm.com; catalin.marinas@arm.com;
> >> will.deacon@arm.com; linux@armlinux.org.uk;
> >> devicetree@vger.kernel.org; linux-usb@vger.kernel.org;
> >> linux-kernel@vger.kernel.org; linux-arm- kernel@lists.infradead.org
> >> Subject: Re: [PATCH v3 2/3] USB3/DWC3: Add property "snps,
> >> incr-burst- type-adjustment" for INCR burst type
> >>
> >> On Mon, Dec 19, 2016 at 05:25:53PM +0800, Changming Huang wrote:
> >> > New property "snps,incr-burst-type-adjustment = <x>, <y>" for
> >> > USB3.0
> >> DWC3.
> >> > Field "x": 1/0 - undefined length INCR burst type enable or not;
> >> > Field
> >> > "y": INCR4/INCR8/INCR16/INCR32/INCR64/INCR128/INCR256 burst type.
> >> >
> >> > While enabling undefined length INCR burst type and INCR16 burst
> >> > type, get better write performance on NXP Layerscape platform:
> >> > around 3% improvement (from 364MB/s to 375MB/s).
> >> >
> >> > Signed-off-by: Changming Huang <jerry.huang@nxp.com>
> >> > ---
> >> > Changes in v3:
> >> > - add new property for INCR burst in usb node.
> >> >
> >> > Documentation/devicetree/bindings/usb/dwc3.txt | 5 +++++
> >> > arch/arm/boot/dts/ls1021a.dtsi | 1 +
> >> > arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 3 +++
> >> > arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 2 ++
> >> > 4 files changed, 11 insertions(+)
> >> >
> >> > diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
> >> > b/Documentation/devicetree/bindings/usb/dwc3.txt
> >> > index e3e6983..8c405a3 100644
> >> > --- a/Documentation/devicetree/bindings/usb/dwc3.txt
> >> > +++ b/Documentation/devicetree/bindings/usb/dwc3.txt
> >> > @@ -55,6 +55,10 @@ Optional properties:
> >> > fladj_30mhz_sdbnd signal is invalid or incorrect.
> >> >
> >> > - <DEPRECATED> tx-fifo-resize: determines if the FIFO *has* to be
> >> reallocated.
> >> > + - snps,incr-burst-type-adjustment: Value for INCR burst type of
> >> GSBUSCFG0
> >> > + register, undefined length INCR burst type enable and INCRx type.
> >> > + First field is for undefined length INCR burst type enable or not.
> >> > + Second field is for largest INCRx type enabled.
> >>
> >> Why do you need the first field? Is the 2nd field used if the 1st is 0?
> >> If not, then just use the presence of the property to enable or not.
> > The first field is one switch.
> > When it is 1, means undefined length INCR burst type enabled, we can use
> any length less than or equal to the largest-enabled burst length of
> INCR4/8/16/32/64/128/256.
> > When it is zero, means INCRx burst mode enabled, we can use one fixed
> burst length of 1/4/8/16/32/64/128/256 byte.
> > So, the 2nd field is used if the 1st is 0, we need to select one largest burst
> length the USB controller can support.
> > If we don't want to change the value of this register (use the default value),
> we don't need to add this property to usb node.
>
> Just make this a single value with 0 meaning INCR and 4/8/16/etc being INCRx.
Maybe, I didn't describe it clearly.
According to DWC3 spec, the value "0" of field INCRBrstEna means INCRx burst mode, 1 means INCR burst mode.
Regardless of the value of INCRBrstEna [bit0], we need to modify the other field bit[1,2,3,4,5,6,7] to one INCR burst type for the platform supported.
Ad you mentioned, if we just use a single value with 0 meaning INCR and 4/8/16/etc being INCRx.
I understand totally that when it is none-zero, we can use it for INCR burst mode.
Then, when it is 0, how to select the INCRx value?
So, I think we still need two vaue to specify INCRBrstEna and INCRx burst type.
^ 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