* Re: [PATCH v2 1/3] arm64: dts: exynos: Add missing unit name to Exynos7 SoC node
From: Krzysztof Kozlowski @ 2017-01-10 18:47 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: Mark Rutland, devicetree, linux-samsung-soc, Rob Herring,
Catalin Marinas, Will Deacon, linux-kernel, Andi Shyti,
Chanwoo Choi, Kukjin Kim, Krzysztof Kozlowski, linux-arm-kernel
In-Reply-To: <1484069912-6534-2-git-send-email-javier@osg.samsung.com>
On Tue, Jan 10, 2017 at 02:38:30PM -0300, Javier Martinez Canillas wrote:
> This patch fixes the following DTC warning about a mismatch
> between a device node reg property and its unit name:
>
> Node /soc has a reg or ranges property, but no unit name
>
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
> ---
>
> arch/arm64/boot/dts/exynos/exynos7.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi b/arch/arm64/boot/dts/exynos/exynos7.dtsi
> index 80aa60e38237..0d2fedc6ac2f 100644
> --- a/arch/arm64/boot/dts/exynos/exynos7.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
> @@ -69,7 +69,7 @@
> method = "smc";
> };
>
> - soc: soc {
> + soc: soc@0 {
This looks unnatural, like a fix just to silence the DTC. Mostly de do
not enumerate soc node, although there are few exceptions.
I would prefer ignore the warning... however I am happy to hear other opinions.
Best regards,
Krzysztof
> compatible = "simple-bus";
> #address-cells = <1>;
> #size-cells = <1>;
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH v2 1/2] iio: distance: srf08: add trivial DT binding
From: Andreas Klinger @ 2017-01-10 18:47 UTC (permalink / raw)
To: jic23, knaack.h, lars, pmeerw, linux-iio, linux-kernel, ktsai,
wsa, robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak,
trivial, mranostay, linux-i2c, devicetree
Cc: ak
Add DT binding for devantech,srf08
Add vendor devantech to vendor list
Signed-off-by: Andreas Klinger <ak@it-klinger.de>
---
Documentation/devicetree/bindings/i2c/trivial-devices.txt | 1 +
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
2 files changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
index 539874490492..86c6930c3c91 100644
--- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
+++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
@@ -36,6 +36,7 @@ dallas,ds1775 Tiny Digital Thermometer and Thermostat
dallas,ds3232 Extremely Accurate I²C RTC with Integrated Crystal and SRAM
dallas,ds4510 CPU Supervisor with Nonvolatile Memory and Programmable I/O
dallas,ds75 Digital Thermometer and Thermostat
+devantech,srf08 Devantech SRF08 ultrasonic ranger
dlg,da9053 DA9053: flexible system level PMIC with multicore support
dlg,da9063 DA9063: system PMIC for quad-core application processors
epson,rx8010 I2C-BUS INTERFACE REAL TIME CLOCK MODULE
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 4696bb5c2198..80325e602403 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -65,6 +65,7 @@ dallas Maxim Integrated Products (formerly Dallas Semiconductor)
davicom DAVICOM Semiconductor, Inc.
delta Delta Electronics, Inc.
denx Denx Software Engineering
+devantech Devantech, Ltd.
digi Digi International Inc.
digilent Diglent, Inc.
dlg Dialog Semiconductor
--
2.1.4
^ permalink raw reply related
* [PATCH v2 2/2] iio: distance: srf08: add IIO driver for us ranger
From: Andreas Klinger @ 2017-01-10 18:48 UTC (permalink / raw)
To: jic23, knaack.h, lars, pmeerw, linux-iio, linux-kernel, ktsai,
wsa, robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak,
trivial, mranostay, linux-i2c, devicetree
Cc: ak
This is the IIO driver for devantech srf08 ultrasonic ranger which can be
used to measure the distances to an object.
The sensor supports I2C with some registers.
Supported Features include:
- read the distance in ranging mode in centimeters
- output of the driver is directly the read value
- together with the scale the driver delivers the distance in meters
- only the first echo of the nearest object is delivered
- set max gain register; userspace enters analogue value
- set range registers; userspace enters range in millimeters in 43 mm steps
Features not supported by this driver:
- ranging mode in inches or in microseconds
- ANN mode
- change I2C address through this driver
- light sensor
The driver was added in the directory "proximity" of the iio subsystem
in absence of another directory named "distance".
There is also a new submenu "distance"
Signed-off-by: Andreas Klinger <ak@it-klinger.de>
---
drivers/iio/proximity/Kconfig | 15 ++
drivers/iio/proximity/Makefile | 1 +
drivers/iio/proximity/srf08.c | 362 +++++++++++++++++++++++++++++++++++++++++
3 files changed, 378 insertions(+)
create mode 100644 drivers/iio/proximity/srf08.c
diff --git a/drivers/iio/proximity/Kconfig b/drivers/iio/proximity/Kconfig
index ef4c73db5b53..7b10a137702b 100644
--- a/drivers/iio/proximity/Kconfig
+++ b/drivers/iio/proximity/Kconfig
@@ -46,3 +46,18 @@ config SX9500
module will be called sx9500.
endmenu
+
+menu "Distance sensors"
+
+config SRF08
+ tristate "Devantech SRF08 ultrasonic ranger sensor"
+ depends on I2C
+ help
+ Say Y here to build a driver for Devantech SRF08 ultrasonic
+ ranger sensor. This driver can be used to measure the distance
+ of objects.
+
+ To compile this driver as a module, choose M here: the
+ module will be called srf08.
+
+endmenu
diff --git a/drivers/iio/proximity/Makefile b/drivers/iio/proximity/Makefile
index 9aadd9a8ee99..e914c2a5dd49 100644
--- a/drivers/iio/proximity/Makefile
+++ b/drivers/iio/proximity/Makefile
@@ -5,4 +5,5 @@
# When adding new entries keep the list in alphabetical order
obj-$(CONFIG_AS3935) += as3935.o
obj-$(CONFIG_LIDAR_LITE_V2) += pulsedlight-lidar-lite-v2.o
+obj-$(CONFIG_SRF08) += srf08.o
obj-$(CONFIG_SX9500) += sx9500.o
diff --git a/drivers/iio/proximity/srf08.c b/drivers/iio/proximity/srf08.c
new file mode 100644
index 000000000000..f38c74ed0933
--- /dev/null
+++ b/drivers/iio/proximity/srf08.c
@@ -0,0 +1,362 @@
+/*
+ * srf08.c - Support for Devantech SRF08 ultrasonic ranger
+ *
+ * Copyright (c) 2016 Andreas Klinger <ak@it-klinger.de>
+ *
+ * This file is subject to the terms and conditions of version 2 of
+ * the GNU General Public License. See the file COPYING in the main
+ * directory of this archive for more details.
+ *
+ * For details about the device see:
+ * http://www.robot-electronics.co.uk/htm/srf08tech.html
+ */
+
+#include <linux/err.h>
+#include <linux/i2c.h>
+#include <linux/delay.h>
+#include <linux/module.h>
+#include <linux/bitops.h>
+#include <linux/iio/iio.h>
+#include <linux/iio/sysfs.h>
+
+/* registers of SRF08 device */
+#define SRF08_WRITE_COMMAND 0x00 /* Command Register */
+#define SRF08_WRITE_MAX_GAIN 0x01 /* Max Gain Register: 0 .. 31 */
+#define SRF08_WRITE_RANGE 0x02 /* Range Register: 0 .. 255 */
+#define SRF08_READ_SW_REVISION 0x00 /* Software Revision */
+#define SRF08_READ_LIGHT 0x01 /* Light Sensor during last echo */
+#define SRF08_READ_ECHO_1_HIGH 0x02 /* Range of first echo received */
+#define SRF08_READ_ECHO_1_LOW 0x03 /* Range of first echo received */
+
+#define SRF08_CMD_RANGING_CM 0x51 /* Ranging Mode - Result in cm */
+
+#define SRF08_DEFAULT_GAIN 1025 /* max. analogue value of Gain */
+#define SRF08_DEFAULT_RANGE 11008 /* max. value of Range in mm */
+
+struct srf08_data {
+ struct i2c_client *client;
+ int gain; /* Max Gain */
+ int range_mm; /* Range in mm */
+ struct mutex lock;
+};
+
+static const int srf08_gain[] = {
+ 94, 97, 100, 103, 107, 110, 114, 118,
+ 123, 128, 133, 139, 145, 152, 159, 168,
+ 177, 187, 199, 212, 227, 245, 265, 288,
+ 317, 352, 395, 450, 524, 626, 777, 1025 };
+
+static int srf08_read_ranging(struct srf08_data *data)
+{
+ struct i2c_client *client = data->client;
+ int ret, i;
+
+ mutex_lock(&data->lock);
+
+ ret = i2c_smbus_write_byte_data(data->client,
+ SRF08_WRITE_COMMAND, SRF08_CMD_RANGING_CM);
+ if (ret < 0) {
+ dev_err(&client->dev, "write command - err: %d\n", ret);
+ mutex_unlock(&data->lock);
+ return ret;
+ }
+
+ /*
+ * normally after 65 ms the device should have the read value
+ * we round it up to 100 ms
+ *
+ * we read here until a correct version number shows up as
+ * suggested by the documentation
+ */
+ for (i = 0; i < 5; i++) {
+ ret = i2c_smbus_read_byte_data(data->client,
+ SRF08_READ_SW_REVISION);
+
+ /* check if a valid version number is read */
+ if (ret < 255 && ret > 0)
+ break;
+ msleep(20);
+ }
+
+ if (ret >= 255 || ret <= 0) {
+ dev_err(&client->dev, "device not ready\n");
+ mutex_unlock(&data->lock);
+ return -EIO;
+ }
+
+ ret = i2c_smbus_read_word_swapped(data->client,
+ SRF08_READ_ECHO_1_HIGH);
+ if (ret < 0) {
+ dev_err(&client->dev, "cannot read distance: ret=%d\n", ret);
+ mutex_unlock(&data->lock);
+ return ret;
+ }
+
+ mutex_unlock(&data->lock);
+
+ return ret;
+}
+
+static int srf08_read_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *channel, int *val,
+ int *val2, long mask)
+{
+ struct srf08_data *data = iio_priv(indio_dev);
+ int ret;
+
+ if (channel->type != IIO_DISTANCE)
+ return -EINVAL;
+
+ switch (mask) {
+ case IIO_CHAN_INFO_RAW:
+ ret = srf08_read_ranging(data);
+ if (ret < 0)
+ return ret;
+ *val = ret;
+ return IIO_VAL_INT;
+ case IIO_CHAN_INFO_SCALE:
+ /* 1 LSB is 1 cm */
+ *val = 0;
+ *val2 = 10000;
+ return IIO_VAL_INT_PLUS_MICRO;
+ default:
+ return -EINVAL;
+ }
+}
+
+static ssize_t srf08_show_range_mm_available(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ int i, len = 0;
+
+ for (i = 0; i < 256; i++)
+ len += scnprintf(buf + len, PAGE_SIZE - len,
+ "%d ", (i + 1) * 43);
+
+ buf[len - 1] = '\n';
+
+ return len;
+}
+
+static IIO_DEVICE_ATTR(range_mm_available, S_IRUGO,
+ srf08_show_range_mm_available, NULL, 0);
+
+static ssize_t srf08_show_range_mm(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct iio_dev *indio_dev = dev_to_iio_dev(dev);
+ struct srf08_data *data = iio_priv(indio_dev);
+
+ return sprintf(buf, "%d\n", data->range_mm);
+}
+
+/*
+ * set the range of the sensor to an even multiple of 43 mm
+ * which corresponds to 1 LSB in the register
+ *
+ * register value corresponding range
+ * 0x00 43 mm
+ * 0x01 86 mm
+ * 0x02 129 mm
+ * ...
+ * 0xFF 11008 mm
+ */
+static ssize_t srf08_write_range_mm(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t len)
+{
+ struct iio_dev *indio_dev = dev_to_iio_dev(dev);
+ struct srf08_data *data = iio_priv(indio_dev);
+ struct i2c_client *client = data->client;
+ int ret;
+ unsigned int val, mod;
+ u8 regval;
+
+ ret = kstrtouint(buf, 10, &val);
+ if (ret)
+ return ret;
+
+ ret = val / 43 - 1;
+ mod = val % 43;
+
+ if (mod || (ret < 0) || (ret > 255))
+ return -EINVAL;
+
+ regval = ret;
+
+ mutex_lock(&data->lock);
+
+ ret = i2c_smbus_write_byte_data(data->client,
+ SRF08_WRITE_RANGE, regval);
+ if (ret < 0) {
+ dev_err(&client->dev, "write_range - err: %d\n", ret);
+ mutex_unlock(&data->lock);
+ return ret;
+ }
+
+ data->range_mm = val;
+
+ mutex_unlock(&data->lock);
+
+ return len;
+}
+
+static IIO_DEVICE_ATTR(range_mm, S_IRUGO | S_IWUSR,
+ srf08_show_range_mm, srf08_write_range_mm, 0);
+
+static ssize_t srf08_show_gain_available(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ int i, len = 0;
+
+ for (i = 0; i < ARRAY_SIZE(srf08_gain); i++)
+ len += sprintf(buf + len, "%d ", srf08_gain[i]);
+
+ len += sprintf(buf + len, "\n");
+
+ return len;
+}
+
+static IIO_DEVICE_ATTR(gain_available, S_IRUGO,
+ srf08_show_gain_available, NULL, 0);
+
+static ssize_t srf08_show_gain(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct iio_dev *indio_dev = dev_to_iio_dev(dev);
+ struct srf08_data *data = iio_priv(indio_dev);
+ int len;
+
+ len = sprintf(buf, "%d\n", data->gain);
+
+ return len;
+}
+
+static ssize_t srf08_write_gain(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t len)
+{
+ struct iio_dev *indio_dev = dev_to_iio_dev(dev);
+ struct srf08_data *data = iio_priv(indio_dev);
+ struct i2c_client *client = data->client;
+ int ret, i;
+ unsigned int val;
+ u8 regval;
+
+ ret = kstrtouint(buf, 10, &val);
+ if (ret)
+ return ret;
+
+ for (i = 0; i < ARRAY_SIZE(srf08_gain); i++)
+ if (val == srf08_gain[i]) {
+ regval = i;
+ break;
+ }
+
+ if (i >= ARRAY_SIZE(srf08_gain))
+ return -EINVAL;
+
+ mutex_lock(&data->lock);
+
+ ret = i2c_smbus_write_byte_data(data->client,
+ SRF08_WRITE_MAX_GAIN, regval);
+ if (ret < 0) {
+ dev_err(&client->dev, "write_gain - err: %d\n", ret);
+ mutex_unlock(&data->lock);
+ return ret;
+ }
+
+ data->gain = val;
+
+ mutex_unlock(&data->lock);
+
+ return len;
+}
+
+static IIO_DEVICE_ATTR(gain, S_IRUGO | S_IWUSR,
+ srf08_show_gain, srf08_write_gain, 0);
+
+static struct attribute *srf08_attributes[] = {
+ &iio_dev_attr_range_mm.dev_attr.attr,
+ &iio_dev_attr_range_mm_available.dev_attr.attr,
+ &iio_dev_attr_gain.dev_attr.attr,
+ &iio_dev_attr_gain_available.dev_attr.attr,
+ NULL,
+};
+
+static const struct attribute_group srf08_attribute_group = {
+ .attrs = srf08_attributes,
+};
+
+static const struct iio_chan_spec srf08_channels[] = {
+ {
+ .type = IIO_DISTANCE,
+ .info_mask_separate =
+ BIT(IIO_CHAN_INFO_RAW) |
+ BIT(IIO_CHAN_INFO_SCALE),
+ },
+};
+
+static const struct iio_info srf08_info = {
+ .read_raw = srf08_read_raw,
+ .attrs = &srf08_attribute_group,
+ .driver_module = THIS_MODULE,
+};
+
+static int srf08_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ struct iio_dev *indio_dev;
+ struct srf08_data *data;
+
+ if (!i2c_check_functionality(client->adapter,
+ I2C_FUNC_SMBUS_READ_BYTE_DATA |
+ I2C_FUNC_SMBUS_WRITE_BYTE_DATA |
+ I2C_FUNC_SMBUS_READ_WORD_DATA))
+ return -ENODEV;
+
+ indio_dev = devm_iio_device_alloc(&client->dev, sizeof(*data));
+ if (!indio_dev)
+ return -ENOMEM;
+
+ data = iio_priv(indio_dev);
+ i2c_set_clientdata(client, indio_dev);
+ data->client = client;
+
+ /*
+ * set default values of device here
+ * these values are already set on the hardware after power on
+ */
+ data->gain = SRF08_DEFAULT_GAIN;
+ data->range_mm = SRF08_DEFAULT_RANGE;
+
+ indio_dev->name = dev_name(&client->dev);
+ indio_dev->dev.parent = &client->dev;
+ indio_dev->modes = INDIO_DIRECT_MODE;
+ indio_dev->info = &srf08_info;
+ indio_dev->channels = srf08_channels;
+ indio_dev->num_channels = ARRAY_SIZE(srf08_channels);
+
+ mutex_init(&data->lock);
+
+ return devm_iio_device_register(&client->dev, indio_dev);
+}
+
+static const struct i2c_device_id srf08_id[] = {
+ { "srf08", 0 },
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, srf08_id);
+
+static struct i2c_driver srf08_driver = {
+ .driver = {
+ .name = "srf08",
+ },
+ .probe = srf08_probe,
+ .id_table = srf08_id,
+};
+module_i2c_driver(srf08_driver);
+
+MODULE_AUTHOR("Andreas Klinger <ak@it-klinger.de>");
+MODULE_DESCRIPTION("Devantech SRF08 ultrasonic ranger driver");
+MODULE_LICENSE("GPL");
--
2.1.4
^ permalink raw reply related
* Re: [PATCH v2 3/3] arm64: dts: exynos: Remove unneeded unit names in Exynos5433 nodes
From: Krzysztof Kozlowski @ 2017-01-10 18:51 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: Mark Rutland, devicetree, linux-samsung-soc, Rob Herring,
Catalin Marinas, Will Deacon, linux-kernel, Andi Shyti,
Chanwoo Choi, Kukjin Kim, Krzysztof Kozlowski, linux-arm-kernel
In-Reply-To: <1484069912-6534-4-git-send-email-javier@osg.samsung.com>
On Tue, Jan 10, 2017 at 02:38:32PM -0300, Javier Martinez Canillas wrote:
> The "samsung,exynos5433-mipi-video-phy" and "samsung,exynos5250-dwusb3"
> DT bindings don't specify a reg property for these nodes, so having a
> unit name leads to the following DTC warnings:
>
> Node /soc/video-phy@105c0710 has a unit name, but no reg property
> Node /soc/usb@15400000 has a unit name, but no reg property
> Node /soc/usb@15a00000 has a unit name, but no reg property
>
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
>
> ---
>
> arch/arm64/boot/dts/exynos/exynos5433.dtsi | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> index 3695ddaf2e04..17e5dafd392c 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> @@ -706,7 +706,7 @@
> interrupts = <GIC_PPI 9 0xf04>;
> };
>
> - mipi_phy: video-phy@105c0710 {
> + mipi_phy: video-phy {
> compatible = "samsung,exynos5433-mipi-video-phy";
> #phy-cells = <1>;
> samsung,pmu-syscon = <&pmu_system_controller>;
> @@ -1285,7 +1285,7 @@
> status = "disabled";
> };
>
> - usbdrd30: usb@15400000 {
> + usbdrd30: usb-0 {
How about "usbdrd" instead of "usb-0"? It would be still quite a generic
description of a class.
> compatible = "samsung,exynos5250-dwusb3";
> clocks = <&cmu_fsys CLK_ACLK_USBDRD30>,
> <&cmu_fsys CLK_SCLK_USBDRD30>;
> @@ -1332,7 +1332,7 @@
> status = "disabled";
> };
>
> - usbhost30: usb@15a00000 {
> + usbhost30: usb-1 {
usbhost?
Best regards,
Krzysztof
> compatible = "samsung,exynos5250-dwusb3";
> clocks = <&cmu_fsys CLK_ACLK_USBHOST30>,
> <&cmu_fsys CLK_SCLK_USBHOST30>;
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH] gpio: pca953x: Add optional reset gpio control
From: Steve Longerbeam @ 2017-01-10 18:57 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Linus Walleij, Alexandre Courbot, Rob Herring, Mark Rutland,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, devicetree,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Steve Longerbeam
In-Reply-To: <CAHp75VeCKPy4B51P_N9Bp03zPUbRodKzitc-n16ZRKJWcEF4fA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 01/03/2017 03:37 PM, Andy Shevchenko wrote:
> On Mon, Jan 2, 2017 at 11:07 PM, Steve Longerbeam <slongerbeam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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).
done.
>
>> #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
done.
Steve
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 3/3] arm64: dts: exynos: Remove unneeded unit names in Exynos5433 nodes
From: Javier Martinez Canillas @ 2017-01-10 19:03 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Mark Rutland, devicetree, linux-samsung-soc, Rob Herring,
Catalin Marinas, Will Deacon, linux-kernel, Andi Shyti,
Chanwoo Choi, Kukjin Kim, linux-arm-kernel
In-Reply-To: <20170110185109.n3x25yxbaarzikcd@kozik-lap>
Hello Krzysztof,
On 01/10/2017 03:51 PM, Krzysztof Kozlowski wrote:
[snip]
>>
>> - usbdrd30: usb@15400000 {
>> + usbdrd30: usb-0 {
>
> How about "usbdrd" instead of "usb-0"? It would be still quite a generic
> description of a class.
>
>> compatible = "samsung,exynos5250-dwusb3";
>> clocks = <&cmu_fsys CLK_ACLK_USBDRD30>,
>> <&cmu_fsys CLK_SCLK_USBDRD30>;
>> @@ -1332,7 +1332,7 @@
>> status = "disabled";
>> };
>>
>> - usbhost30: usb@15a00000 {
>> + usbhost30: usb-1 {
>
> usbhost?
>
Indeed, these sounds better so I'll change for them.
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* Re: [PATCH v3 1/3] arm64: dts: exynos5433: add DECON_TV node
From: Krzysztof Kozlowski @ 2017-01-10 19:09 UTC (permalink / raw)
To: Andrzej Hajda
Cc: linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA, Krzysztof Kozlowski,
Bartlomiej Zolnierkiewicz, Marek Szyprowski, Inki Dae,
Rob Herring, Mark Rutland, Javier Martinez Canillas,
devicetree-u79uwXL29TY76Z2rM5mHXA, Andi Shyti, Chanwoo Choi
In-Reply-To: <1484036664-15951-1-git-send-email-a.hajda-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
On Tue, Jan 10, 2017 at 09:24:22AM +0100, Andrzej Hajda wrote:
> DECON_TV is 2nd display controller on Exynos5433, used in HDMI path
> or 2nd DSI path.
>
> Signed-off-by: Andrzej Hajda <a.hajda-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> Reviewed-by: Javier Martinez Canillas <javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
> Reviewed-by: Chanwoo Choi <cw00.choi-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> Tested-by: Hoegeun Kwon <hoegeun.kwon-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> ---
>
> Hi Krzysztof,
>
> These patches are based on latest patches separating tm2 and tm2e and
> touchscreen patches. I hope this is good base.
> Thanks all for quick response/review.
>
> Regards
> Andrzej
>
> v2:
> - replaced magic numbers with macros,
> - removed power domains,
> - removed 0x prefixes from node names
>
> v3:
> - order nodes by address
> ---
> arch/arm64/boot/dts/exynos/exynos5433.dtsi | 43 ++++++++++++++++++++++++++++++
> 1 file changed, 43 insertions(+)
>
First, I applied your fix for unit addresses. Then I wanted to apply
these... no, it does not apply.
Okay, so maybe unit address confuses git-am (it is not that smart as
cherry-pick etc) - let's try the other way. I applied these three
patches, fixed that damned subject in each commit and I wanted to apply
the fix for unit address. Nope. It won't apply.
I do not know how you rebased your work.
As of now, the fix is applied. Please fix the subject and rebase.
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Re: [PATCH 3/6] clk: sunxi-ng: Add H5 clocks
From: Maxime Ripard @ 2017-01-10 19:10 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Rob Herring, Andre Przywara, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Linus Walleij,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Chen-Yu Tsai,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170109161500.Ep9GCmIb-8ttnI0T0xQU0PDqKvflMoHmW9unr2Ajn@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1533 bytes --]
On Mon, Jan 09, 2017 at 09:13:12PM +0800, Icenowy Zheng wrote:
>
> 2017年1月9日 下午7:01于 Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>写道：
> >
> > On Fri, Jan 06, 2017 at 06:48:31AM +0800, Icenowy Zheng wrote:
> > >
> > > 2017年1月6日 06:04于 Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>写道：
> > > >
> > > > On Tue, Dec 27, 2016 at 12:25:15AM +0800, Icenowy Zheng wrote:
> > > > > Add the H5 CCU clocks set based on the H3 one.
> > > > >
> > > > > Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
> > > >
> > > > Is there any difference with H3's?
> > >
> > > One more Transport Stream controller, so one more bus gate and bus
> > > reset for it.
> >
> > There's no need to duplicate more than 1000 lines of code just for
> > that then. Just add a new compatible and reuse the clocks already
> > defined.
>
> How can I do this? Add them in ccu-sun8i-h3.c ?
Yes, you can have a look at how I did it for sun5i for example if you
want.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
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.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] gpio: pca953x: Add optional reset gpio control
From: Steve Longerbeam @ 2017-01-10 19:10 UTC (permalink / raw)
To: Andy Shevchenko, Vladimir Zapolskiy
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: <CAHp75Vey4R8o+7h3DuBJ9FiciGSHfvRWjs_0d3ZWeTm+cB4WrA@mail.gmail.com>
On 01/04/2017 02:31 AM, Andy Shevchenko wrote:
>
>>>> + 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/
>> There is no devm_gpiod_get_optional_exclusive(), probably you confuse
>> the function with devm_reset_control_get_optional_exclusive().
> Perhaps it's time to add
> drivers/reset/reset-gpio.c ?
Yeah, looks like a GPIO based reset controller driver would need to be
implemented in order to go this route. The max7310 nodes in
imx6qdl-sabreauto.dtsi could then refer to that reset controller by the
'resets' phandle.
There are many many devices that would benefit from a GPIO reset
controller, I count 143 nodes under arch/arm/boot/dts that specify a
'reset-gpios' property.
But I don't have the time to write such a driver. So I would propose just
keeping the devm_gpiod_get_optional() call here. When such a gpio reset
controller is written, the work can begin to convert all the gpio reset
users
to make use of it.
Steve
^ permalink raw reply
* Re: [PATCH] gpio: pca953x: Add optional reset gpio control
From: Steve Longerbeam @ 2017-01-10 19:13 UTC (permalink / raw)
To: Vladimir Zapolskiy, linus.walleij, gnurou, robh+dt, mark.rutland
Cc: linux-gpio, devicetree, linux-kernel, Steve Longerbeam
In-Reply-To: <e043cb00-9b8e-edec-0949-b23fbed6e2c5@mentor.com>
On 01/04/2017 02:25 AM, Vladimir Zapolskiy wrote:
> Hi Steve,
>
> On 01/02/2017 11:07 PM, Steve Longerbeam wrote:
>> Add optional reset-gpios pin control. If present, de-assert the
>> specified reset gpio pin to bring the chip out of reset.
>>
>> Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
>> Cc: Linus Walleij <linus.walleij@linaro.org>
>> Cc: Alexandre Courbot <gnurou@gmail.com>
>> Cc: linux-gpio@vger.kernel.org
>> Cc: linux-kernel@vger.kernel.org
>> ---
>> Documentation/devicetree/bindings/gpio/gpio-pca953x.txt | 4 ++++
>> drivers/gpio/gpio-pca953x.c | 11 +++++++++++
>> 2 files changed, 15 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt b/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt
>> index 08dd15f..da54f4c 100644
>> --- a/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt
>> +++ b/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt
>> @@ -29,6 +29,10 @@ Required properties:
>> onsemi,pca9654
>> exar,xra1202
>>
>> +Optional properties:
>> + - reset-gpios: GPIO specification for the RESET input
>> +
>> +
> Drop the surplus empty line above.
done.
>
>> Example:
>>
>>
>> diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
>> index d5d72d8..ca2ddea 100644
>> --- 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>
>>
>> #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 */
>> + reset_gpio = devm_gpiod_get_optional(&client->dev, "reset",
>> + GPIOD_OUT_LOW);
>> + if (IS_ERR(reset_gpio)) {
>> + dev_err(&client->dev, "request for reset pin failed\n");
> I'm not confident that the error message is wanted here, you may consider either
> to remove it or at least print it out if (PTR_ERR(reset_gpio) != -EPROBE_DEFER).
no problem, I just removed it.
Steve
^ permalink raw reply
* Re: [PATCH v2 6/6] arm64: allwinner: a64: Increase the MMC max frequency
From: Maxime Ripard @ 2017-01-10 19:15 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: devicetree, Ulf Hansson, Andre Przywara,
linux-mmc@vger.kernel.org, linux-kernel, Rob Herring,
linux-arm-kernel
In-Reply-To: <CAGb2v67JoOAtHjMJboNUdCDX=+=Hf+zOWr234rT7GEiUmPb=nQ@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1707 bytes --]
Hi,
On Tue, Jan 10, 2017 at 01:01:20AM +0800, Chen-Yu Tsai wrote:
> On Tue, Jan 10, 2017 at 12:46 AM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > All the controllers can have a maximum frequency of 200MHz.
> >
> > Since older SoCs cannot go that high, we cannot change the default maximum
> > frequency, but fortunately for us we have a property for that in the DT.
> >
> > This also has the side effect of allowing to use the MMC HS200 mode for the
> > boards that support it (with either 1.2v or 1.8v IOs).
> >
> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> > ---
> > arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 3 +++
> > 1 file changed, 3 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > index 8e149498e096..f46ae965cf5b 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > @@ -332,6 +332,7 @@
> > resets = <&ccu RST_BUS_MMC0>;
> > reset-names = "ahb";
> > interrupts = <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
> > + max-frequency = <200000000>;
>
> You also have to set one of MMC_CAP2_HS200* in the driver,
> or mmc-hs200-1_8v or mmc-hs200-1_2v in the device tree to
> actually use HS200, right?
Yes, but that requires a board with 1.8V IOs to work properly, which
not all board use, so it's probably best to enable it in the board
DTS.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/5] pinctrl: core: Use delayed work for hogs
From: Tony Lindgren @ 2017-01-10 19:19 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linus Walleij, Haojian Zhuang, Masahiro Yamada, Grygorii Strashko,
Nishanth Menon, linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-omap@vger.kernel.org, Linux-Renesas
In-Reply-To: <20170110153045.GS2630@atomide.com>
* Tony Lindgren <tony@atomide.com> [170110 07:32]:
> * Geert Uytterhoeven <geert@linux-m68k.org> [170110 06:09]:
> > Hi Tony,
> >
> > On Tue, Dec 27, 2016 at 6:19 PM, Tony Lindgren <tony@atomide.com> wrote:
> > > Having the pin control framework call pin controller functions
> > > before it's probe has finished is not nice as the pin controller
> > > device driver does not yet have struct pinctrl_dev handle.
> > >
> > > Let's fix this issue by adding deferred work for late init. This is
> > > needed to be able to add pinctrl generic helper functions that expect
> > > to know struct pinctrl_dev handle. Note that we now need to call
> > > create_pinctrl() directly as we don't want to add the pin controller
> > > to the list of controllers until the hogs are claimed. We also need
> > > to pass the pinctrl_dev to the device tree parser functions as they
> > > otherwise won't find the right controller at this point.
> > >
> > > Signed-off-by: Tony Lindgren <tony@atomide.com>
> >
> > I believe this patch causes a regression on r8a7740/armadillo, where the
> > pin controller is also a GPIO controller, and lcd0 needs a hog
> > (cfr. arch/arm/boot/dts/r8a7740-armadillo800eva.dts):
> >
> > -GPIO line 176 (lcd0) hogged as output/high
> > -sh-pfc e6050000.pfc: r8a7740_pfc handling gpio 0 -> 211
> > +gpiochip_add_data: GPIOs 0..211 (r8a7740_pfc) failed to register
> > +sh-pfc e6050000.pfc: failed to init GPIO chip, ignoring...
> > sh-pfc e6050000.pfc: r8a7740_pfc support registered
> >
> > Hence all drivers using GPIOs fail to initialize because their GPIOs never
> > become available.
> >
> > Adding debug prints to the failure paths shows that the call to
> > of_pinctrl_get() in of_gpiochip_add_pin_range() fails with -EPROBE_DEFER.
> > Adding a debug print to the top of gpiochip_add_data() makes the problem go
> > away, presumably because it introduces a delay that allows the delayed work
> > to kick in...
>
> OK. What if we added also an optional pinctrl function that the pin
> controller driver could call to initialize hogs? Then the pin controller
> driver could call it during or after probe as needed. That is after
> there's a valid struct pinctrl_dev handle.
...
> We could also pass some flag if should always call pinctrl_late_init()
> directly. But that does not remove the problem of struct pinctrl_dev handle
> being uninitialized when the pin controller driver functionas are called.
Looks like we need both a flag and a way for the pin controller driver
to start things.
Below is an experimental fix to intorduce pinctrl_start() that I've
tested with pinctrl-single. Then we should probably make all pin controller
drivers call pinctrl_start() to properly fix the issue of struct pinctrl_dev
handle not being initialized before driver functions are called.
Or do you guys have any better ideas?
Regards,
Tony
8< --------------------------------
diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -1962,6 +1962,17 @@ static void pinctrl_late_init(struct work_struct *work)
pinctrl_init_device_debugfs(pctldev);
}
+int pinctrl_start(struct pinctrl_dev *pctldev)
+{
+ if (!IS_ERR(pctldev->p))
+ return -EEXIST;
+
+ pinctrl_late_init(&pctldev->late_init.work);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(pinctrl_start);
+
/**
* pinctrl_register() - register a pin controller device
* @pctldesc: descriptor for this pin controller
@@ -2035,9 +2046,14 @@ struct pinctrl_dev *pinctrl_register(struct pinctrl_desc *pctldesc,
/*
* If the device has hogs we want the probe() function of the driver
* to complete before we go in and hog them and add the pin controller
- * to the list of controllers. If it has no hogs, we can just complete
- * the registration immediately.
+ * to the list of controllers. If the pin controller driver initializes
+ * hogs, or the pin controller instance has no hogs, we can just
+ * complete the registration immediately.
*/
+
+ if (pctldesc->flags & PINCTRL_DRIVER_START)
+ return pctldev;
+
if (pinctrl_dt_has_hogs(pctldev))
schedule_delayed_work(&pctldev->late_init, 0);
else
diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -1741,6 +1741,7 @@ static int pcs_probe(struct platform_device *pdev)
pcs->desc.pmxops = &pcs_pinmux_ops;
if (PCS_HAS_PINCONF)
pcs->desc.confops = &pcs_pinconf_ops;
+ pcs->desc.flags = PINCTRL_DRIVER_START;
pcs->desc.owner = THIS_MODULE;
ret = pcs_allocate_pin_table(pcs);
@@ -1754,6 +1755,10 @@ static int pcs_probe(struct platform_device *pdev)
goto free;
}
+ ret = pinctrl_start(pcs->pctl);
+ if (ret)
+ goto free;
+
ret = pcs_add_gpio_func(np, pcs);
if (ret < 0)
goto free;
diff --git a/drivers/pinctrl/sh-pfc/pinctrl.c b/drivers/pinctrl/sh-pfc/pinctrl.c
--- a/drivers/pinctrl/sh-pfc/pinctrl.c
+++ b/drivers/pinctrl/sh-pfc/pinctrl.c
@@ -815,7 +815,15 @@ int sh_pfc_register_pinctrl(struct sh_pfc *pfc)
pmx->pctl_desc.confops = &sh_pfc_pinconf_ops;
pmx->pctl_desc.pins = pmx->pins;
pmx->pctl_desc.npins = pfc->info->nr_pins;
+ pmx->pctl_desc.flags = PINCTRL_DRIVER_START;
pmx->pctl = devm_pinctrl_register(pfc->dev, &pmx->pctl_desc, pmx);
- return PTR_ERR_OR_ZERO(pmx->pctl);
+ if (IS_ERR(pmx->pctl))
+ return PTR_ERR(pmx->pctl);
+
+ ret = pinctrl_start(pmx->pctl);
+ if (ret)
+ return ret;
+
+ return 0;
}
diff --git a/include/linux/pinctrl/pinctrl.h b/include/linux/pinctrl/pinctrl.h
--- a/include/linux/pinctrl/pinctrl.h
+++ b/include/linux/pinctrl/pinctrl.h
@@ -104,6 +104,8 @@ struct pinctrl_ops {
struct pinctrl_map *map, unsigned num_maps);
};
+#define PINCTRL_DRIVER_START BIT(0)
+
/**
* struct pinctrl_desc - pin controller descriptor, register this to pin
* control subsystem
@@ -112,6 +114,8 @@ struct pinctrl_ops {
* this pin controller
* @npins: number of descriptors in the array, usually just ARRAY_SIZE()
* of the pins field above
+ * @flags: Optional pin controller feature flags
+ * handling is needed in the pin controller driver.
* @pctlops: pin control operation vtable, to support global concepts like
* grouping of pins, this is optional.
* @pmxops: pinmux operations vtable, if you support pinmuxing in your driver
@@ -129,6 +133,7 @@ struct pinctrl_desc {
const char *name;
const struct pinctrl_pin_desc *pins;
unsigned int npins;
+ unsigned int flags;
const struct pinctrl_ops *pctlops;
const struct pinmux_ops *pmxops;
const struct pinconf_ops *confops;
@@ -149,6 +154,7 @@ extern struct pinctrl_dev *devm_pinctrl_register(struct device *dev,
void *driver_data);
extern void devm_pinctrl_unregister(struct device *dev,
struct pinctrl_dev *pctldev);
+extern int pinctrl_start(struct pinctrl_dev *pctldev);
extern bool pin_is_valid(struct pinctrl_dev *pctldev, int pin);
extern void pinctrl_add_gpio_range(struct pinctrl_dev *pctldev,
--
2.11.0
^ permalink raw reply
* Re: [RFC 1/3] iommu/arm-smmu: Add support to opt-in to stalling
From: Rob Clark @ 2017-01-10 19:20 UTC (permalink / raw)
To: Will Deacon
Cc: Mark Rutland, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-arm-msm,
Jordan Crouse,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
In-Reply-To: <20170110175219.GK527-5wv7dgnIgG8@public.gmane.org>
On Tue, Jan 10, 2017 at 12:52 PM, Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org> wrote:
> Hi Rob,
>
> On Fri, Jan 06, 2017 at 11:26:49AM -0500, Rob Clark wrote:
>> On Thu, Jan 5, 2017 at 10:49 AM, Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org> wrote:
>> > On Thu, Jan 05, 2017 at 10:27:27AM -0500, Rob Clark wrote:
>> >> I'm not sure if the better solution then would be to have two fault
>> >> callbacks, one immediately from the IRQ and a later one from wq. Or
>> >> let the driver handle the wq business and give it a way to tell the
>> >> IOMMU when to resume.
>> >>
>> >> I kinda think we should punt on the worker thread for now until we are
>> >> ready to resume faulting transactions, because I guess a strong chance
>> >> that whatever way we do it now will be wrong ;-)
>> >
>> > I guess what I'm after is for you to change the interrupt handlers to be
>> > threaded, like they are for SMMUv3. I *think* you can do that with a NULL
>> > thread_fn for now, and just call report_iommu_fault from the handler.
>> > The return value of that could, in theory, be used to queued the paging
>> > request and wake the paging thread in future.
>>
>> If we only pass in the non-threaded irq fxn, I'm not really sure how
>> that changes anything.. or maybe I'm not understanding what you mean.
>>
>> But yeah, I guess we could use request_threaded_irq() to get both IRQ
>> context notification and a later thread context notification rather
>> than doing the wq thing. Either way the iommu API has to change
>> slightly.
>>
>> >> > I wonder if this should also be predicated on the compatible string, so
>> >> > that the "arm,smmu-enable-stall" property is ignored (with a warning) if
>> >> > the compatible string isn't specific enough to identify an implementation
>> >> > with the required SS behaviour? On the other hand, it feels pretty
>> >> > redundant and a single "stalling works" property is all we need.
>> >>
>> >> We could also drop the property and key the behavior on specific
>> >> compat strings I guess. Having both seems a bit odd. Anyways, I'll
>> >> defer to DT folks about what the cleaner approach is.
>> >
>> > As Robin pointed out, we do need to be able to distinguish the integration
>> > of the device from the device itself. For example, MMU-9000 might be capable
>> > of stalling, but if it's bolted to a PCI RC, it's not safe to do so.
>>
>> Hmm, well we install the fault handler on the iommu_domain.. perhaps
>> maybe a combo of dts property (or deciding based on more specific
>> compat string), plus extra param passed in to
>> iommu_set_fault_hander(). The dts property or compat string to
>> indicate whether the iommu (and how it is wired up) can handle stalls,
>> and enable_stall param when fault handler is registered to indicate
>> whether the device itself can cope.. if either can't do stalling, then
>> don't set CFCFG.
>
> I thought about this some more, and I think you're right. Having
> iommu_set_fault_handler take a flags parameter indicating that, for example,
> the fault handler can deal with paging, is all we need to implement the
> per-master opt-in functionality for stalling faults. There's no real
> requirement to standardise a generic firmware property for that (but
> we still need *something* that says stalling is usable on the SMMU --
> perhaps just the compatible string is ok).
btw, it occurred to me that maybe it should be flags param to
iommu_attach_device() (just in case fault handler not installed?)
otoh stalling without a fault handler is silly, but I guess we need it
to infer whether stalling can be supported by other devices on same
iommu.. tbh I'm on a bit shaky ground when it comes to multiple
devices per iommu since the SoC's I'm familiar with do it the other
way around. But I guess you have thought more about the multi-device
case, so figured I should suggest it..
> Taking this further, there's then no need for the threaded IRQ function
> in the SMMUv2 driver after all. Instead, we pass a continuation function
> pointer and opaque token from the SMMU driver to the fault handler in
> IRQ context (this will be in thread context for SMMUv3, but that should
> be fine). The fault handler can then stash these someplace, and signal
> a wakeup for its own threaded handler, which ultimately calls the SMMU
> continuation function with the opaque token as a parameter when it's done
> with the fault. I think that's enough to get things rolling without adding
> lots of infrastructure to the SMMU driver initially. If a pattern emerges
> amongst users of the interface, then we could consolidate some of the work
> handling back into IOMMU core.
>
> What do you think? It should all be pretty straightforward for what you
> want to do.
yeah, that makes sense to me.. I can give it a try.
BR,
-R
> Will
^ permalink raw reply
* Re: [PATCH] gpio: pca953x: Add optional reset gpio control
From: Steve Longerbeam @ 2017-01-10 19:21 UTC (permalink / raw)
To: Rob Herring
Cc: linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
gnurou-Re5JQEeQqe8AvxtiuMwx3w, mark.rutland-5wv7dgnIgG8,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Steve Longerbeam
In-Reply-To: <20170104132231.jlhqwngaeza7duoo@rob-hp-laptop>
On 01/04/2017 05:22 AM, Rob Herring wrote:
> On Mon, Jan 02, 2017 at 01:07:51PM -0800, Steve Longerbeam wrote:
>> Add optional reset-gpios pin control. If present, de-assert the
>> specified reset gpio pin to bring the chip out of reset.
>>
>> Signed-off-by: Steve Longerbeam <steve_longerbeam-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
>> Cc: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>> Cc: Alexandre Courbot <gnurou-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> Cc: linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> ---
>> Documentation/devicetree/bindings/gpio/gpio-pca953x.txt | 4 ++++
>> drivers/gpio/gpio-pca953x.c | 11 +++++++++++
>> 2 files changed, 15 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt b/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt
>> index 08dd15f..da54f4c 100644
>> --- a/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt
>> +++ b/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt
>> @@ -29,6 +29,10 @@ Required properties:
>> onsemi,pca9654
>> exar,xra1202
>>
>> +Optional properties:
>> + - reset-gpios: GPIO specification for the RESET input
> Need to specify active high or low.
done (it's an active low signal).
Steve
--
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 v2] pca953x: Add optional reset gpio control
From: Steve Longerbeam @ 2017-01-10 19:29 UTC (permalink / raw)
To: linus.walleij, gnurou, robh+dt, mark.rutland
Cc: linux-gpio, devicetree, linux-kernel, Steve Longerbeam
In version 2:
- Specify that reset signal to PCA953x chip is active low, in
binding doc.
- reorder includes in gpio-pca953x.c.
- remove dev_err() on devm_gpiod_get_optional() error return.
Steve Longerbeam (1):
gpio: pca953x: Add optional reset gpio control
Documentation/devicetree/bindings/gpio/gpio-pca953x.txt | 4 ++++
drivers/gpio/gpio-pca953x.c | 9 +++++++++
2 files changed, 13 insertions(+)
--
2.7.4
^ permalink raw reply
* [PATCH v2] gpio: pca953x: Add optional reset gpio control
From: Steve Longerbeam @ 2017-01-10 19:29 UTC (permalink / raw)
To: linus.walleij, gnurou, robh+dt, mark.rutland
Cc: linux-gpio, devicetree, linux-kernel, Steve Longerbeam
In-Reply-To: <1484076591-20834-1-git-send-email-steve_longerbeam@mentor.com>
Add optional reset-gpios pin control. If present, de-assert the
specified reset gpio pin to bring the chip out of reset.
Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: linux-gpio@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
--
v2:
- Specify that reset signal to PCA953x chip is active low, in
binding doc.
- reorder includes in gpio-pca953x.c.
- remove dev_err() on devm_gpiod_get_optional() error return.
---
Documentation/devicetree/bindings/gpio/gpio-pca953x.txt | 4 ++++
drivers/gpio/gpio-pca953x.c | 9 +++++++++
2 files changed, 13 insertions(+)
diff --git a/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt b/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt
index 08dd15f..e639357 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt
@@ -29,6 +29,10 @@ Required properties:
onsemi,pca9654
exar,xra1202
+Optional properties:
+ - reset-gpios: GPIO specification for the RESET input. This is an
+ active low signal to the PCA953x.
+
Example:
diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index d5d72d8..d44232a 100644
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -14,6 +14,7 @@
#include <linux/module.h>
#include <linux/init.h>
#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
#include <linux/interrupt.h>
#include <linux/i2c.h>
#include <linux/platform_data/pca953x.h>
@@ -754,8 +755,16 @@ 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 */
+ reset_gpio = devm_gpiod_get_optional(&client->dev, "reset",
+ GPIOD_OUT_LOW);
+ if (IS_ERR(reset_gpio))
+ return PTR_ERR(reset_gpio);
}
chip->client = client;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v4 1/2] arm64: dts: rockchip: add "rockchip, grf" property for RK3399 PMUCRU/CRU
From: Heiko Stübner @ 2017-01-10 19:46 UTC (permalink / raw)
To: Doug Anderson
Cc: Mark Rutland, devicetree@vger.kernel.org, Elaine Zhang,
Xing Zheng, Catalin Marinas, Shawn Lin, Brian Norris, Will Deacon,
linux-kernel@vger.kernel.org, open list:ARM/Rockchip SoC...,
Rob Herring, David Wu, Jianqun Xu,
linux-arm-kernel@lists.infradead.org, Caesar Wang
In-Reply-To: <CAD=FV=Wwu3q_LqwYUWcJQRvp5neVOS9szgsYFONWTRJ0X8hRTA@mail.gmail.com>
Am Dienstag, 10. Januar 2017, 10:45:48 schrieb Doug Anderson:
> Hi,
>
> On Mon, Jan 9, 2017 at 10:15 PM, Xing Zheng <zhengxing@rock-chips.com>
wrote:
> > The structure rockchip_clk_provider needs to refer the GRF regmap
> > in somewhere, if the CRU node has not "rockchip,grf" property,
> > calling syscon_regmap_lookup_by_phandle will return an invalid GRF
> > regmap, and the MUXGRF type clock will be not supported.
> >
> > Therefore, we need to add them.
> >
> > Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
> > ---
> >
> > Changes in v4:
> > - separte the binding patch
> >
> > Changes in v3:
> > - add optional roperty rockchip,grf in rockchip,rk3399-cru.txt
> >
> > Changes in v2:
> > - referring pmugrf for PMUGRU
> > - fix the typo "invaild" in COMMIT message
> >
> > arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 ++
> > 1 file changed, 2 insertions(+)
>
> This seems fine to me, so:
>
> Reviewed-by: Douglas Anderson <dianders@chromium.org>
>
> ...but I will say that before you actually add any real "MUXGRF"
> clocks on rk3399 you _might_ need to rework the code to make things
> truly "optional". If it turns out that any existing clocks that
> already exist today already go through one of these muxes in the GRF
> and we've always been assuming one setting of the mux, we'll need to
> make sure we keep assuming that setting of the mux even if the "grf"
> isn't specified.
I guess I see that a bit more relaxed :-) .
I.e. the GRF being optional is a remnant of syscons not being available when
the clocks get set up- so were coming in later or not at all. For the rk3288 I
converted, there we never really had the case of the GRF missing.
And the GRF mux for the vcodec now present is not being used by anything yet
(neither driver nor binding), so no old devicetree can break.
> As I understand it, your motivation for this patch is to eventually be
> able to model the EDP reference clock which can either be xin24 or
> "edp osc". Presumably the eDP "reference clock" isn't related to any
> of the pre-existing eDP clocks so that one should be safe.
Same here, so far we don't even have edp or even any other graphical output on
the rk3399, so again there is no old devicetree that could break when the grf
is not specified.
So, for me that looks good.
Heiko
^ permalink raw reply
* Re: [PATCH] of: alloc anywhere from memblock if range not specified
From: Laura Abbott @ 2017-01-10 19:49 UTC (permalink / raw)
To: Leonard Crestez, Vinayak Menon
Cc: devicetree, linux-kernel, robh+dt, vinayakm.list,
Octavian Purdila, frowand.list, linux-arm-kernel, m.szyprowski
In-Reply-To: <717b117d-9b8b-d4e9-6135-3c52afd635c8@gmail.com>
On 01/10/2017 08:16 AM, Leonard Crestez wrote:
> Hello,
>
> I have some trouble with this patch.
>
> It seems the intention is to allow CMA to be placed in highmem. If the CMA area is
> larger than highmem and no alloc-ranges is specified (just a size) it is possible
> to end up allocating a area that spans from multiple zones. This later breaks
> checks in cma_activate_area and makes most dma allocations fail.
>
> Am I missing something or this a bug?
>
This has been discussed in previous threads
https://marc.info/?l=linux-kernel&m=147990760506179&w=2
https://marc.info/?l=linux-kernel&m=147928325113103&w=2
I haven't seen any follow up since then though.
> On Mon, Feb 22, 2016 at 3:45 PM, Vinayak Menon <vinmenon@codeaurora.org> wrote:
>>
>> early_init_dt_alloc_reserved_memory_arch passes end as 0 to
>> __memblock_alloc_base, when limits are not specified. But
>> __memblock_alloc_base takes end value of 0 as MEMBLOCK_ALLOC_ACCESSIBLE
>> and limits the end to memblock.current_limit. This results in regions
>> never being placed in HIGHMEM area, for e.g. CMA.
>> Let __memblock_alloc_base allocate from anywhere in memory if limits are
>> not specified.
>>
>> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
>> Signed-off-by: Vinayak Menon <vinmenon@codeaurora.org>
>> ---
>> drivers/of/of_reserved_mem.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
>> index 1a3556a..ed01c01 100644
>> --- a/drivers/of/of_reserved_mem.c
>> +++ b/drivers/of/of_reserved_mem.c
>> @@ -32,11 +32,13 @@ int __init __weak early_init_dt_alloc_reserved_memory_arch(phys_addr_t size,
>> phys_addr_t align, phys_addr_t start, phys_addr_t end, bool nomap,
>> phys_addr_t *res_base)
>> {
>> + phys_addr_t base;
>> /*
>> * We use __memblock_alloc_base() because memblock_alloc_base()
>> * panic()s on allocation failure.
>> */
>> - phys_addr_t base = __memblock_alloc_base(size, align, end);
>> + end = !end ? MEMBLOCK_ALLOC_ANYWHERE : end;
>> + base = __memblock_alloc_base(size, align, end);
>> if (!base)
>> return -ENOMEM;
>>
>> --
>> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
>> member of the Code Aurora Forum, hosted by The Linux Foundation
>>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 6/9] dt/bindings: Add a serial/UART attached device binding
From: One Thousand Gnomes @ 2017-01-10 19:50 UTC (permalink / raw)
To: Rob Herring
Cc: Greg Kroah-Hartman, Marcel Holtmann, Jiri Slaby,
Sebastian Reichel, Arnd Bergmann, Dr . H . Nikolaus Schaller,
Peter Hurley, Andy Shevchenko, Loic Poulain, Pavel Machek,
NeilBrown, Linus Walleij, linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
linux-serial-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170106162635.19677-7-robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
On Fri, 6 Jan 2017 10:26:32 -0600
Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> Add a common binding for describing serial/UART attached devices. Common
> examples are Bluetooth, WiFi, NFC and GPS devices.
>
> Serial attached devices are represented as child nodes of a UART node.
> This may need to be extended for more complex devices with multiple
> interfaces, but for the simple cases a child node is sufficient.
>
> Signed-off-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> ---
> .../devicetree/bindings/serial/slave-device.txt | 34 ++++++++++++++++++++++
> 1 file changed, 34 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/serial/slave-device.txt
>
> diff --git a/Documentation/devicetree/bindings/serial/slave-device.txt b/Documentation/devicetree/bindings/serial/slave-device.txt
> new file mode 100644
> index 000000000000..9b7c2d651345
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/serial/slave-device.txt
> @@ -0,0 +1,34 @@
> +Serial Slave Device DT binding
> +
> +This documents the binding structure and common properties for serial
> +attached devices. Common examples include Bluetooth, WiFi, NFC and GPS
> +devices.
> +
> +qSerial
Stray 'q' ??
^ permalink raw reply
* Re: [PATCH] iio: accel: st_accel: handle deprecated bindings
From: Jonathan Cameron @ 2017-01-10 19:55 UTC (permalink / raw)
To: Rob Herring, Linus Walleij
Cc: linux-iio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170109181645.lntlvawt26vsp4l2@rob-hp-laptop>
On 09/01/17 18:16, Rob Herring wrote:
> On Thu, Jan 05, 2017 at 02:32:33PM +0100, Linus Walleij wrote:
>> The earlier deployed LIS3LV02DL driver had already defined a few
>> DT bindings that need to be supported by the new more generic
>> driver and listed as compatible but deprecated bindings in the
>> documentation.
>>
>> After this we can start to activate the new driver with the old
>> systems where applicable.
>>
>> As part of this enablement: make us depend on the old drivers
>> not being in use so we don't get a kernel with two competing
>> drivers.
>>
>> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> Signed-off-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>> ---
>> Documentation/devicetree/bindings/iio/accel/lis302.txt | 2 +-
>> Documentation/devicetree/bindings/iio/st-sensors.txt | 2 ++
>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Added as I haven't pushed this out as a non rebasing branch yet.
Thanks,
Jonathan
>
>> drivers/iio/accel/Kconfig | 2 ++
>> drivers/iio/accel/st_accel_i2c.c | 5 +++++
>> drivers/iio/accel/st_accel_spi.c | 9 +++++++++
>> 5 files changed, 19 insertions(+), 1 deletion(-)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH v2 1/3] arm64: dts: exynos: Add missing unit name to Exynos7 SoC node
From: Javier Martinez Canillas @ 2017-01-10 19:55 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Mark Rutland, devicetree, linux-samsung-soc, Rob Herring,
Catalin Marinas, Will Deacon, linux-kernel, Andi Shyti,
Chanwoo Choi, Kukjin Kim, linux-arm-kernel
In-Reply-To: <20170110184728.2nff4r634ics4wb3@kozik-lap>
Hello Krzysztof,
On 01/10/2017 03:47 PM, Krzysztof Kozlowski wrote:
> On Tue, Jan 10, 2017 at 02:38:30PM -0300, Javier Martinez Canillas wrote:
>> This patch fixes the following DTC warning about a mismatch
>> between a device node reg property and its unit name:
>>
>> Node /soc has a reg or ranges property, but no unit name
>>
>> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
>> ---
>>
>> arch/arm64/boot/dts/exynos/exynos7.dtsi | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi b/arch/arm64/boot/dts/exynos/exynos7.dtsi
>> index 80aa60e38237..0d2fedc6ac2f 100644
>> --- a/arch/arm64/boot/dts/exynos/exynos7.dtsi
>> +++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
>> @@ -69,7 +69,7 @@
>> method = "smc";
>> };
>>
>> - soc: soc {
>> + soc: soc@0 {
>
> This looks unnatural, like a fix just to silence the DTC. Mostly de do
> not enumerate soc node, although there are few exceptions.
>
Yes, but OTOH arm32 Exynos SoCs just have an empty "ranges" property in their
soc device node (parent and child address space is the same, no translation)
so DTC doesn't complain about the unit address in those.
But others SoCs DTSI with a non-empty ranges property have an unit name in
their soc nodes, i.e for arm64 and arm32:
arch/arm64/boot/dts/marvell/berlin4ct.dtsi
arch/arm/boot/dts/da850.dtsi
> I would prefer ignore the warning... however I am happy to hear other opinions.
>
If is wrong/unnatural to have addresses for soc nodes then I think DTC should
be patched to ignore these (like it will be the case for the OPP nodes AFAIU).
> Best regards,
> Krzysztof
>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* Re: [PATCH v4 1/2] arm64: dts: rockchip: add "rockchip, grf" property for RK3399 PMUCRU/CRU
From: Heiko Stübner @ 2017-01-10 19:58 UTC (permalink / raw)
To: Doug Anderson
Cc: Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Elaine Zhang, Xing Zheng, Catalin Marinas, Shawn Lin,
Brian Norris, Will Deacon,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
open list:ARM/Rockchip SoC..., Rob Herring, David Wu, Jianqun Xu,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Caesar Wang
In-Reply-To: <8683375.pL9J7LxuT0@diego>
Hi Doug,
Am Dienstag, 10. Januar 2017, 20:46:12 schrieb Heiko Stübner:
> Am Dienstag, 10. Januar 2017, 10:45:48 schrieb Doug Anderson:
> > Hi,
> >
> > On Mon, Jan 9, 2017 at 10:15 PM, Xing Zheng <zhengxing-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
>
> wrote:
> > > The structure rockchip_clk_provider needs to refer the GRF regmap
> > > in somewhere, if the CRU node has not "rockchip,grf" property,
> > > calling syscon_regmap_lookup_by_phandle will return an invalid GRF
> > > regmap, and the MUXGRF type clock will be not supported.
> > >
> > > Therefore, we need to add them.
> > >
> > > Signed-off-by: Xing Zheng <zhengxing-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> > > ---
> > >
> > > Changes in v4:
> > > - separte the binding patch
> > >
> > > Changes in v3:
> > > - add optional roperty rockchip,grf in rockchip,rk3399-cru.txt
> > >
> > > Changes in v2:
> > > - referring pmugrf for PMUGRU
> > > - fix the typo "invaild" in COMMIT message
> > >
> > > arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 ++
> > > 1 file changed, 2 insertions(+)
> >
> > This seems fine to me, so:
> >
> > Reviewed-by: Douglas Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> >
> > ...but I will say that before you actually add any real "MUXGRF"
> > clocks on rk3399 you _might_ need to rework the code to make things
> > truly "optional". If it turns out that any existing clocks that
> > already exist today already go through one of these muxes in the GRF
> > and we've always been assuming one setting of the mux, we'll need to
> > make sure we keep assuming that setting of the mux even if the "grf"
> > isn't specified.
>
> I guess I see that a bit more relaxed :-) .
>
> I.e. the GRF being optional is a remnant of syscons not being available when
> the clocks get set up- so were coming in later or not at all. For the
> rk3288 I converted, there we never really had the case of the GRF missing.
>
> And the GRF mux for the vcodec now present is not being used by anything yet
> (neither driver nor binding), so no old devicetree can break.
>
> > As I understand it, your motivation for this patch is to eventually be
> > able to model the EDP reference clock which can either be xin24 or
> > "edp osc". Presumably the eDP "reference clock" isn't related to any
> > of the pre-existing eDP clocks so that one should be safe.
>
> Same here, so far we don't even have edp or even any other graphical output
> on the rk3399, so again there is no old devicetree that could break when
> the grf is not specified.
reading all of the above again, it feels like you essentially also said
similar things already in your original reply and I misread some of it.
But again, I don't see the need for any more code right now, as hopefully the
simple stuff we currently only support does not have any grf-based muxes in
it. Xing + Rockchip people, please correct me if I'm wrong here :-)
Heiko
^ permalink raw reply
* Re: [PATCH v2] gpio: pca953x: Add optional reset gpio control
From: Andy Shevchenko @ 2017-01-10 20:01 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: <1484076591-20834-2-git-send-email-steve_longerbeam@mentor.com>
On Tue, Jan 10, 2017 at 9:29 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.
>
> Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Alexandre Courbot <gnurou@gmail.com>
> Cc: linux-gpio@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> --
>
> v2:
> - Specify that reset signal to PCA953x chip is active low, in
> binding doc.
> - reorder includes in gpio-pca953x.c.
> - remove dev_err() on devm_gpiod_get_optional() error return.
This should go after delimiter.
FWIW:
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> ---
> Documentation/devicetree/bindings/gpio/gpio-pca953x.txt | 4 ++++
> drivers/gpio/gpio-pca953x.c | 9 +++++++++
> 2 files changed, 13 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt b/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt
> index 08dd15f..e639357 100644
> --- a/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt
> +++ b/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt
> @@ -29,6 +29,10 @@ Required properties:
> onsemi,pca9654
> exar,xra1202
>
> +Optional properties:
> + - reset-gpios: GPIO specification for the RESET input. This is an
> + active low signal to the PCA953x.
> +
> Example:
>
>
> diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
> index d5d72d8..d44232a 100644
> --- a/drivers/gpio/gpio-pca953x.c
> +++ b/drivers/gpio/gpio-pca953x.c
> @@ -14,6 +14,7 @@
> #include <linux/module.h>
> #include <linux/init.h>
> #include <linux/gpio.h>
> +#include <linux/gpio/consumer.h>
> #include <linux/interrupt.h>
> #include <linux/i2c.h>
> #include <linux/platform_data/pca953x.h>
> @@ -754,8 +755,16 @@ 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 */
> + reset_gpio = devm_gpiod_get_optional(&client->dev, "reset",
> + GPIOD_OUT_LOW);
> + if (IS_ERR(reset_gpio))
> + return PTR_ERR(reset_gpio);
> }
>
> chip->client = client;
> --
> 2.7.4
>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 4/4] ARM: dts: sun8i: add OTG function to Lichee Pi Zero
From: Bin Liu @ 2017-01-10 20:24 UTC (permalink / raw)
To: Icenowy Zheng
Cc: devicetree, linux-usb, linux-kernel, Kishon Vijay Abraham I,
Chen-Yu Tsai, Maxime Ripard, linux-arm-kernel
In-Reply-To: <20170103152534.20118-5-icenowy@aosc.xyz>
On Tue, Jan 03, 2017 at 11:25:34PM +0800, Icenowy Zheng wrote:
> Lichee Pi Zero features a USB OTG port.
>
> Add support for it.
>
> Note: in order to use the Host mode, the board must be powered via the
> +5V and GND pins.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> ---
> arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
> index 0099affc6ce3..3d9168cbaeca 100644
> --- a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
> +++ b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
> @@ -71,3 +71,13 @@
> pinctrl-names = "default";
> status = "okay";
> };
> +
> +&usb_otg {
> + dr_mode = "otg";
Why not set this default mode in dtsi instead?
Regards,
-Bin.
> + status = "okay";
> +};
> +
> +&usbphy {
> + usb0_id_det-gpio = <&pio 5 6 GPIO_ACTIVE_HIGH>;
> + status = "okay";
> +};
> --
> 2.11.0
>
^ permalink raw reply
* Re: [PATCH V7 1/4] Documentation/devicetree/bindings: b850v3_lvds_dp
From: Laurent Pinchart @ 2017-01-10 21:04 UTC (permalink / raw)
To: dri-devel
Cc: Peter Senna Tschudin, Rob Herring, Mark Rutland, Daniel Vetter,
Peter Senna Tschudin, Takashi Iwai, Yakir Yang, Jiri Slaby,
Martyn Welch, Ian Campbell, Russell King, Peter Senna Tschudin,
Javier Martinez Canillas, Thierry Reding, Guenter Roeck,
martin.donnelly, devicetree@vger.kernel.org, Pawel Moll,
Mauro Carvalho Chehab
In-Reply-To: <74f0-58704480-5-27259840@173563636>
Hi Peter,
On Saturday 07 Jan 2017 01:29:52 Peter Senna Tschudin wrote:
> On 04 January, 2017 21:39 CET, Rob Herring wrote:
> > On Tue, Jan 3, 2017 at 5:34 PM, Peter Senna Tschudin wrote:
> >> On 03 January, 2017 23:51 CET, Rob Herring <robh@kernel.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@collabora.co.uk>
> >>>> Cc: Martin Donnelly <martin.donnelly@ge.com>
> >>>> Cc: Javier Martinez Canillas <javier@dowhile0.org>
> >>>> Cc: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> >>>> Cc: Philipp Zabel <p.zabel@pengutronix.de>
> >>>> Cc: Rob Herring <robh@kernel.org>
> >>>> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> >>>> Signed-off-by: Peter Senna Tschudin <peter.senna@collabora.com>
> >>>> ---
> >>>> There was an Acked-by from Rob Herring <robh@kernel.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?
> >
> > Humm, b850v3 is the board name? This node should be the name of the bridge
> > chip.
>
> From the cover letter:
>
> -- // --
> There are two physical bridges on the video signal pipeline: a STDP4028(LVDS
> to DP) and a STDP2690(DP to DP++). The hardware and firmware made it
> complicated for this binding to comprise two device tree nodes, as the
> design goal is to configure both bridges based on the LVDS signal, which
> leave the driver powerless to control the video processing pipeline. The
> two bridges behaves as a single bridge, and the driver is only needed for
> telling the host about EDID / HPD, and for giving the host powers to ack
> interrupts. The video signal pipeline is as follows:
>
> Host -> LVDS|--(STDP4028)--|DP -> DP|--(STDP2690)--|DP++ -> Video output
> -- // --
You forgot to prefix your patch series with [HACK] ;-)
How about fixing the issues that make the two DT nodes solution difficult ?
What are they ?
--
Regards,
Laurent Pinchart
^ 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