Re: [PATCH v3 1/2] dt: bindings: add wl18xx wireless device

[Luca Coelho]

On Thu, 2015-02-19 at 18:13 +0200, Eliad Peller wrote:
> Add device tree binding documentation for TI's wl18xx
> wlan chip.
> 
> Signed-off-by: Eliad Peller 
> ---

If, as I said in the other thread, you use the work I did earlier,
support for wl12xx will also be included...

--
Luca.

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] wlcore: add basic device-tree support

[Luca Coelho]

Hi,

On Sun, 2015-02-15 at 13:09 +0200, Eliad Peller wrote:
> When running with device-tree, we no longer have a board file
> that can set up the platform data for wlcore.
> Allow this data to be passed from DT.
> 
> For now, parse only the irq used. Other (optional) properties
> can be added later on.
> 
> Signed-off-by: Ido Yariv 
> Signed-off-by: Eliad Peller 
> ---

I don't really care much, but why not just finalize the work I did a
couple of years ago?

http://mid.gmane.org/1375189476-21557-1-git-send-email-coe...@ti.com
http://mid.gmane.org/1375215668-29171-1-git-send-email-coe...@ti.com

IIRC there were just some minor comments there, but I never really got
to it because I left TI.

--
Luca.

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] leds: Add ktd2692 flash LED driver

[Ingi Kim]

hi

On 2015년 02월 27일 12:36, Varka Bhadram wrote:
> On 02/27/2015 06:31 AM, Ingi Kim wrote:
>> This patch adds a driver to support the ktd2692 flash LEDs.
>> ktd2692 can control flash current by ExpressWire interface.
>>
>> Signed-off-by: Ingi Kim 
>> ---
>>   drivers/leds/Kconfig|8 ++
>>   drivers/leds/Makefile   |1 +
>>   drivers/leds/leds-ktd2692.c |  245 
>> +++
>>   3 files changed, 254 insertions(+)
>>   create mode 100644 drivers/leds/leds-ktd2692.c
>>
> (...)
> 
>> +static struct ktd2692_context *ktd2692_parse_dt(struct device *dev)
>> +{
>> + struct device_node *np = dev->of_node;
>> + struct ktd2692_context *led;
>> +
>> + led = devm_kzalloc(dev, sizeof(struct ktd2692_context), GFP_KERNEL);
>> + if (!led)
>> + return ERR_PTR((long)led);
> 
> What about using sizeof(*led) in place of sizeof(struct ktd2692_context)..?
> 
> Also the error return for devm_kzalloc() should be -ENOMEM.
> 

Thanks, I'll check and change sizeof() and error return style.

>> +
>> + led->strobe_gpio = of_get_named_gpio(np, "strobe-gpio", 0);
>> + if (!gpio_is_valid(led->strobe_gpio)) {
>> + dev_err(dev, "no strobe_gpio property found\n");
>> + return ERR_PTR(led->strobe_gpio);
>> + }
>> +
>> + return led;
>> +}
>> +
>> +static int ktd2692_probe(struct platform_device *pdev)
>> +{
>> + struct device *dev = &pdev->dev;
>> + struct ktd2692_context *led;
>> + int ret;
>> +
>> + if (!dev->of_node)
>> + return -ENODEV;
>> +
>> + led = ktd2692_parse_dt(dev);
>> + if (IS_ERR(led))
>> + return PTR_ERR(led);
>> +
>> + led->cdev.name = KTD2692_DEFAULT_NAME;
>> + led->cdev.brightness = LED_OFF;
>> + led->cdev.max_brightness = LED_FULL;
>> + led->cdev.flags |= LED_CORE_SUSPENDRESUME;
>> + led->cdev.brightness_set = ktd2692_brightness_set;
>> + led->cdev.brightness_get = ktd2692_brightness_get;
>> + led->mode = KTD2692_REG_MODE_BASE | KTD2692_MODE_DISABLE;
>> +
>> + platform_set_drvdata(pdev, led);
>> +
>> + ret = led_classdev_register(&pdev->dev, &led->cdev);
>> + if (ret) {
>> + dev_err(dev, "couldn't register LED %s\n", led->cdev.name);
>> + return ret;
>> + }
>> +
>> + ret = ktd2692_brightness_set_gpio(led);
>> + if (ret) {
>> + led_classdev_unregister(&led->cdev);
>> + return ret;
>> + }
>> +
>> + ktd2692_expresswire_reset(led);
>> +
>> + return ret;
> 
> return 0 instead of ret...?
> 
> 
> 

I'll check and try
Thanks,
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v11 5/6] devicetree: Add vendor prefix for Skyworks Solutions, Inc.

[gyungoh]

From: Gyungoh Yoo 

Signed-off-by: Gyungoh Yoo 
Acked-by: Lee Jones 
---
Changes v11:
Nothing

Changes v10:
Nothing

Changes v9:
Nothing

Changes v8:
Nothing

Changes v7:
Nothing

Changes v6:
Nothing

Changes v5:
Nothing

Changes v4:
Nothing

Changes v3:
Nothing

Changes v2:
Added vendor prefix for Skyworks Solutions, Inc.

 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 389ca13..c4fe9cc 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -165,6 +165,7 @@ sii Seiko Instruments, Inc.
 silergySilergy Corp.
 sirf   SiRF Technology, Inc.
 sitronix   Sitronix Technology Corporation
+skyworks   Skyworks Solutions, Inc.
 smsc   Standard Microsystems Corporation
 snps   Synopsys, Inc.
 solidrun   SolidRun
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v11 6/6] devicetree: Add SKY81452 to the Trivial Devices list

[gyungoh]

From: Gyungoh Yoo 

Signed-off-by: Gyungoh Yoo 
---
Changes v11:
Nothing

Changes v10:
Nothing

Changes v9:
Nothing

Changes v8:
Nothing

Changes v7:
Nothing

Changes v6:
Nothing

Changes v5:
Nothing

Changes v4:
Nothing

Changes v3:
Nothing

Changes v2:
Add SKY81452 to the Trivial Devices list

 Documentation/devicetree/bindings/i2c/trivial-devices.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt 
b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
index aaa8325..003bd77 100644
--- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
+++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
@@ -89,6 +89,7 @@ ricoh,rv5c386 I2C bus SERIAL INTERFACE REAL-TIME 
CLOCK IC
 ricoh,rv5c387a I2C bus SERIAL INTERFACE REAL-TIME CLOCK IC
 samsung,24ad0xd1   S524AD0XF1 (128K/256K-bit Serial EEPROM for Low Power)
 sii,s35390a2-wire CMOS real-time clock
+skyworks,sky81452  Skyworks SKY81452: Six-Channel White LED Driver with 
Touch Panel Bias Supply
 st-micro,24c256i2c serial eeprom  (24cxx)
 stm,m41t00 Serial Access TIMEKEEPER
 stm,m41t62 Serial real-time clock (RTC) with alarm
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v11 2/6] backlight: Add support Skyworks SKY81452 backlight driver

[gyungoh]

From: Gyungoh Yoo 

Signed-off-by: Gyungoh Yoo 
Acked-by: Jingoo Han 
Acked-by: Bryan Wu 
---
Changes v11:
Renamed 'skyworks,en-channels' property to led-sources.

Changes v10:
Removed trivial get_brightness implementations

Changes v9:
Nothing

Changes v8:
Renamed property names for backlight with vendor prefix
Modified gpio-enable property to generic property for GPIO

Changes v7:
Modified licensing text to GPLv2

Changes v6:
Added new line character at the end of line of dev_err()

Changes v5:
Move sky81452-backlight.h to include/linux/platform_data

Changes v4:
Reordering header files for readability
Removed calling to backlight_device_unregister()
Removed MODULE_VERSION()
Modified license to GPLv2

Changes v3:
Modified DBG messages

Changes v2:
Added 'compatible' attribute in the driver
Added message for exception or errors

 drivers/video/backlight/Kconfig  |  10 +
 drivers/video/backlight/Makefile |   1 +
 drivers/video/backlight/sky81452-backlight.c | 353 +++
 include/linux/platform_data/sky81452-backlight.h |  46 +++
 4 files changed, 410 insertions(+)
 create mode 100644 drivers/video/backlight/sky81452-backlight.c
 create mode 100644 include/linux/platform_data/sky81452-backlight.h

diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index efb0904..2d9923a 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -408,6 +408,16 @@ config BACKLIGHT_PANDORA
  If you have a Pandora console, say Y to enable the
  backlight driver.
 
+config BACKLIGHT_SKY81452
+   tristate "Backlight driver for SKY81452"
+   depends on BACKLIGHT_CLASS_DEVICE && MFD_SKY81452
+   help
+ If you have a Skyworks SKY81452, say Y to enable the
+ backlight driver.
+
+ To compile this driver as a module, choose M here: the module will
+ be called sky81452-backlight
+
 config BACKLIGHT_TPS65217
tristate "TPS65217 Backlight"
depends on BACKLIGHT_CLASS_DEVICE && MFD_TPS65217
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index fcd50b73..d67073f 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -50,6 +50,7 @@ obj-$(CONFIG_BACKLIGHT_PANDORA)   += pandora_bl.o
 obj-$(CONFIG_BACKLIGHT_PCF50633)   += pcf50633-backlight.o
 obj-$(CONFIG_BACKLIGHT_PWM)+= pwm_bl.o
 obj-$(CONFIG_BACKLIGHT_SAHARA) += kb3886_bl.o
+obj-$(CONFIG_BACKLIGHT_SKY81452)   += sky81452-backlight.o
 obj-$(CONFIG_BACKLIGHT_TOSA)   += tosa_bl.o
 obj-$(CONFIG_BACKLIGHT_TPS65217)   += tps65217_bl.o
 obj-$(CONFIG_BACKLIGHT_WM831X) += wm831x_bl.o
diff --git a/drivers/video/backlight/sky81452-backlight.c 
b/drivers/video/backlight/sky81452-backlight.c
new file mode 100644
index 000..052fa1b
--- /dev/null
+++ b/drivers/video/backlight/sky81452-backlight.c
@@ -0,0 +1,353 @@
+/*
+ * sky81452-backlight.cSKY81452 backlight driver
+ *
+ * Copyright 2014 Skyworks Solutions Inc.
+ * Author : Gyungoh Yoo 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* registers */
+#define SKY81452_REG0  0x00
+#define SKY81452_REG1  0x01
+#define SKY81452_REG2  0x02
+#define SKY81452_REG4  0x04
+#define SKY81452_REG5  0x05
+
+/* bit mask */
+#define SKY81452_CS0xFF
+#define SKY81452_EN0x3F
+#define SKY81452_IGPW  0x20
+#define SKY81452_PWMMD 0x10
+#define SKY81452_PHASE 0x08
+#define SKY81452_ILIM  0x04
+#define SKY81452_VSHRT 0x03
+#define SKY81452_OCP   0x80
+#define SKY81452_OTMP  0x40
+#define SKY81452_SHRT  0x3F
+#define SKY81452_OPN   0x3F
+
+#define SKY81452_DEFAULT_NAME "lcd-backlight"
+#define SKY81452_MAX_BRIGHTNESS(SKY81452_CS + 1)
+
+#define CTZ(b) __builtin_ctz(b)
+
+static int sky81452_bl_update_status(struct backlight_device *bd)
+{
+   const struct sky81452_bl_platform_data *pdata =
+   dev_get_platdata(bd->dev.parent);
+   const unsigned int brightness = (unsigned int)bd->props.brightness;
+   struct regmap *regmap = bl_get_data(bd);
+   int ret;
+
+   if (brightness > 0) {
+   ret = regmap_write(regmap, SKY81452_REG0, brightness - 1);
+   if (IS_ERR_VALUE(ret))
+   return ret;
+

[PATCH v11 0/6] Add Skyworks SKY81452 device drivers

[gyungoh]

From: Gyungoh Yoo 

This patch set includes regulator and backlight driver for SKY81452.
Also it includes documents for device tree and module.
sky81452-regulator was already applied. So this series doesn't
include it.

v11:
Renamed 'skyworks,en-channels' property to led-sources.
Removed unused property 'skyworks,ovp-level'.

v10:
Removed trivial get_brightness implementations for sky81452-backlight

v9:
Removed the change to remove MODULE_VERSION() for sky81452-regulator

v8:
Renamed property names for backlight with vendor prefix
Modified gpio-enable property to generic property for GPIO
Made up the example for backlight DT
Changed the DT parsing of regulator using regulator_node and of_match

v7:
Modified licensing text to GPLv2
Split Kconfig renaming from DT patch

v6:
Added new line character at the end of line of dev_err()

v5:
Changed DT for regulator : 'lout' node should be defined under 'regulator'
Removed compatible string from sky81452-regulator driver
Modified sky81452-regulator to return EINVAL when of_node is NULL
Move sky81452-backlight.h to include/linux/platform_data

v4:
Removed MODULE_VERSION()
Modified license to GPLv2
Removed calling to backlight_device_unregister() in sky81452-backlight

v3:
Cleaned-up DBG messages
Cleaned-up DT
Fixed the backlight name from 'sky81452-bl' to 'sky81452-backlight'
Assigned mfd_cell.of_compatible for binding device node
Modified error messages
Modified sky81452-regulator to return ENODATA when of_node is NULL

v2:
Split the patches for each sub-system
Added 'reg' attribute for I2C address in device tree documents
Added 'compatible' attribute in child drivers
Renamed CONFIG_SKY81452 to CONFIG_MFD_SKY81452
Changed the dependency from I2C=y to I2C, for CONFIG_MFD_SKY81452
Added message for exception or errors.
Added vendor prefix for Skyworks Solutions, Inc.
Add SKY81452 to the Trivial Devices list

Gyungoh Yoo (6):
  mfd: Add support for Skyworks SKY81452 driver
  backlight: Add support Skyworks SKY81452 backlight driver
  devicetree: Add new SKY81452 mfd binding
  devicetree: Add new SKY81452 backlight binding
  devicetree: Add vendor prefix for Skyworks Solutions, Inc.
  devicetree: Add SKY81452 to the Trivial Devices list

 .../devicetree/bindings/i2c/trivial-devices.txt|   1 +
 Documentation/devicetree/bindings/mfd/sky81452.txt |  35 ++
 .../devicetree/bindings/vendor-prefixes.txt|   1 +
 .../video/backlight/sky81452-backlight.txt |  29 ++
 drivers/mfd/Kconfig|  12 +
 drivers/mfd/Makefile   |   1 +
 drivers/mfd/sky81452.c | 108 +++
 drivers/video/backlight/Kconfig|  10 +
 drivers/video/backlight/Makefile   |   1 +
 drivers/video/backlight/sky81452-backlight.c   | 353 +
 include/linux/mfd/sky81452.h   |  31 ++
 include/linux/platform_data/sky81452-backlight.h   |  46 +++
 12 files changed, 628 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/sky81452.txt
 create mode 100644 
Documentation/devicetree/bindings/video/backlight/sky81452-backlight.txt
 create mode 100644 drivers/mfd/sky81452.c
 create mode 100644 drivers/video/backlight/sky81452-backlight.c
 create mode 100644 include/linux/mfd/sky81452.h
 create mode 100644 include/linux/platform_data/sky81452-backlight.h

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v11 1/6] mfd: Add support for Skyworks SKY81452 driver

[gyungoh]

From: Gyungoh Yoo 

Signed-off-by: Gyungoh Yoo 
Acked-by: Lee Jones 
---
Changes v11:
Nothing

Changes v10:
Nothing

Changes v9:
Nothing

Changes v8:
Nothing

Changes v7:
Modified licensing text to GPLv2

Changes v6:
Added new line character at the end of line of dev_err()

Changes v5:
Move sky81452-backlight.h to include/linux/platform_data

Changes v4:
Removed MODULE_VERSION()
Modified license to GPLv2

Changes v3:
Fixed the backlight name from 'sky81452-bl' to 'sky81452-backlight'
Assigned mfd_cell.of_compatible for binding device node
Modified error messages

Changes v2:
Renamed CONFIG_SKY81452 to CONFIG_MFD_SKY81452
Changed the dependency from I2C=y to I2C, for CONFIG_MFD_SKY81452
Added message for exception or errors

 drivers/mfd/Kconfig  |  12 +
 drivers/mfd/Makefile |   1 +
 drivers/mfd/sky81452.c   | 108 +++
 include/linux/mfd/sky81452.h |  31 +
 4 files changed, 152 insertions(+)
 create mode 100644 drivers/mfd/sky81452.c
 create mode 100644 include/linux/mfd/sky81452.h

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 38356e3..bc3b540 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -753,6 +753,18 @@ config MFD_SM501_GPIO
 lines on the SM501. The platform data is used to supply the
 base number for the first GPIO line to register.
 
+config MFD_SKY81452
+   tristate "Skyworks Solutions SKY81452"
+   select MFD_CORE
+   select REGMAP_I2C
+   depends on I2C
+   help
+ This is the core driver for the Skyworks SKY81452 backlight and
+ voltage regulator device.
+
+ This driver can also be built as a module.  If so, the module
+ will be called sky81452.
+
 config MFD_SMSC
bool "SMSC ECE1099 series chips"
depends on I2C=y
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 19f3d74..75b3ffb 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -178,6 +178,7 @@ obj-$(CONFIG_MFD_MENF21BMC) += menf21bmc.o
 obj-$(CONFIG_MFD_HI6421_PMIC)  += hi6421-pmic-core.o
 obj-$(CONFIG_MFD_DLN2) += dln2.o
 obj-$(CONFIG_MFD_RT5033)   += rt5033.o
+obj-$(CONFIG_MFD_SKY81452) += sky81452.o
 
 intel-soc-pmic-objs:= intel_soc_pmic_core.o intel_soc_pmic_crc.o
 obj-$(CONFIG_INTEL_SOC_PMIC)   += intel-soc-pmic.o
diff --git a/drivers/mfd/sky81452.c b/drivers/mfd/sky81452.c
new file mode 100644
index 000..b0c9b04
--- /dev/null
+++ b/drivers/mfd/sky81452.c
@@ -0,0 +1,108 @@
+/*
+ * sky81452.c  SKY81452 MFD driver
+ *
+ * Copyright 2014 Skyworks Solutions Inc.
+ * Author : Gyungoh Yoo 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static const struct regmap_config sky81452_config = {
+   .reg_bits = 8,
+   .val_bits = 8,
+};
+
+static int sky81452_probe(struct i2c_client *client,
+   const struct i2c_device_id *id)
+{
+   struct device *dev = &client->dev;
+   const struct sky81452_platform_data *pdata = dev_get_platdata(dev);
+   struct mfd_cell cells[2];
+   struct regmap *regmap;
+   int ret;
+
+   if (!pdata) {
+   pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+   if (!pdata)
+   return -ENOMEM;
+   }
+
+   regmap = devm_regmap_init_i2c(client, &sky81452_config);
+   if (IS_ERR(regmap)) {
+   dev_err(dev, "failed to initialize.err=%ld\n", PTR_ERR(regmap));
+   return PTR_ERR(regmap);
+   }
+
+   i2c_set_clientdata(client, regmap);
+
+   memset(cells, 0, sizeof(cells));
+   cells[0].name = "sky81452-backlight";
+   cells[0].of_compatible = "skyworks,sky81452-backlight";
+   cells[0].platform_data = pdata->bl_pdata;
+   cells[0].pdata_size = sizeof(*pdata->bl_pdata);
+   cells[1].name = "sky81452-regulator";
+   cells[1].platform_data = pdata->regulator_init_data;
+   cells[1].pdata_size = sizeof(*pdata->regulator_init_data);
+
+   ret = mfd_add_devices(dev, -1, cells, ARRAY_SIZE(cells), NULL, 0, NULL);
+   if (ret)
+   dev_err(dev, "failed to add child devices. err=%d\n", ret);
+
+   return ret;
+}
+
+static int sky81452_remove(struct i2c_client *client)
+{
+   mfd_remove_devices(&client->dev);
+   return 0;
+}
+
+static const struct

[PATCH v11 3/6] devicetree: Add new SKY81452 mfd binding

[gyungoh]

From: Gyungoh Yoo 

Signed-off-by: Gyungoh Yoo 
Acked-by: Lee Jones 
---
Changes v11:
Renamed 'skyworks,en-channels' property to led-sources.
Removed unused property 'skyworks,ovp-level'.

Changes v10:
Nothing

Changes v9:
Nothing

Changes v8:
Made up the example for backlight DT

Changes v7:
Nothing

Changes v6:
Nothing

Changes v5:
Changed DT for regulator : 'lout' node should be defined under 'regulator'
Removed compatible string from sky81452-regulator driver

Changes v4:
Nothing

Changes v3:
Nothing

Changes v2:
Added reg attribute for I2C slave address

 Documentation/devicetree/bindings/mfd/sky81452.txt | 35 ++
 1 file changed, 35 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/sky81452.txt

diff --git a/Documentation/devicetree/bindings/mfd/sky81452.txt 
b/Documentation/devicetree/bindings/mfd/sky81452.txt
new file mode 100644
index 000..3518179
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/sky81452.txt
@@ -0,0 +1,35 @@
+SKY81452 bindings
+
+Required properties:
+- compatible   : Must be "skyworks,sky81452"
+- reg  : I2C slave address
+
+Required child nodes:
+- backlight: container node for backlight following the binding
+   in video/backlight/sky81452-backlight.txt
+- regulator: container node for regulators following the binding
+   in regulator/sky81452-regulator.txt
+
+Example:
+
+   sky81452@2c {
+   compatible = "skyworks,sky81452";
+   reg = <0x2c>;
+
+   backlight {
+   compatible = "skyworks,sky81452-backlight";
+   name = "pwm-backlight";
+   led-sources = <0 1 2 3 6>;
+   skyworks,ignore-pwm;
+   skyworks,phase-shift;
+   skyworks,current-limit = <2300>;
+   };
+
+   regulator {
+   lout {
+   regulator-name = "sky81452-lout";
+   regulator-min-microvolt = <450>;
+   regulator-max-microvolt = <800>;
+   };
+   };
+   };
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v11 4/6] devicetree: Add new SKY81452 backlight binding

[gyungoh]

From: Gyungoh Yoo 

Signed-off-by: Gyungoh Yoo 
Acked-by: Bryan Wu 
---
Changes v11:
Renamed 'skyworks,en-channels' property to led-sources.
Removed unused property 'skyworks,ovp-level'.

Changes v10:
Nothing

Changes v9:
Nothing

Changes v8:
Renamed property names for backlight with vendor prefix
Modified gpio-enable property to generic property for GPIO
Made up the example for backlight DT

Changes v7:
Nothing

Changes v6:
Nothing

Changes v5:
Nothing

Changes v4:
Nothing

Changes v3:
Nothing

Changes v2:
Added reg attribute for I2C slave address

 .../video/backlight/sky81452-backlight.txt | 29 ++
 1 file changed, 29 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/video/backlight/sky81452-backlight.txt

diff --git 
a/Documentation/devicetree/bindings/video/backlight/sky81452-backlight.txt 
b/Documentation/devicetree/bindings/video/backlight/sky81452-backlight.txt
new file mode 100644
index 000..8bf2940
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/backlight/sky81452-backlight.txt
@@ -0,0 +1,29 @@
+SKY81452-backlight bindings
+
+Required properties:
+- compatible   : Must be "skyworks,sky81452-backlight"
+
+Optional properties:
+- name : Name of backlight device. Default is 'lcd-backlight'.
+- gpios: GPIO to use to EN pin.
+   See Documentation/devicetree/bindings/gpio/gpio.txt
+- led-sources  : List of enabled channels from 0 to 5.
+   See Documentation/devicetree/bindings/leds/common.txt
+- skyworks,ignore-pwm  : Ignore both PWM input
+- skyworks,dpwm-mode   : Enable DPWM dimming mode, otherwise Analog dimming.
+- skyworks,phase-shift : Enable phase shift mode
+- skyworks,short-detection-threshold-volt
+   : It should be one of 4, 5, 6 and 7V.
+- skyworks,current-limit-mA
+   : It should be 2300mA or 2750mA.
+
+Example:
+
+   backlight {
+   compatible = "skyworks,sky81452-backlight";
+   name = "pwm-backlight";
+   led-sources = <0 1 2 5>;
+   skyworks,ignore-pwm;
+   skyworks,phase-shift;
+   skyworks,current-limit-mA = <2300>;
+   };
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 1/3] dmaengine: Add support for APM X-Gene SoC DMA engine driver

[Rameshwar Sahu]

Hi


On Fri, Feb 27, 2015 at 9:39 AM, Rameshwar Sahu  wrote:
> Hi,
>
>
> On Thu, Feb 26, 2015 at 7:55 PM, Ben Dooks  wrote:
>> On 26/02/15 12:31, Rameshwar Sahu wrote:
>>> Hi Vinod,
>>>
>>>
>>> On Tue, Feb 24, 2015 at 6:23 PM, Rameshwar Prasad Sahu  
>>> wrote:
 This patch implements the APM X-Gene SoC DMA engine driver. The APM X-Gene
 SoC DMA engine consists of 4 DMA channels for performing DMA operations.
 These DMA operations include memory copy and scatter-gather memory copy
 offloading.

 Signed-off-by: Rameshwar Prasad Sahu 
 Signed-off-by: Loc Ho 
 ---
  drivers/dma/Kconfig |8 +
  drivers/dma/Makefile|1 +
  drivers/dma/xgene-dma.c | 1738 
 +++
  3 files changed, 1747 insertions(+)
  create mode 100755 drivers/dma/xgene-dma.c

 diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
 index a874b6e..0e05831 100644
 --- a/drivers/dma/Kconfig
 +++ b/drivers/dma/Kconfig
 @@ -425,6 +425,14 @@ config IMG_MDC_DMA
 help
   Enable support for the IMG multi-threaded DMA controller (MDC).

 +config XGENE_DMA
 +   tristate "APM X-Gene DMA support"
 +   depends on ARCH_XGENE
 +   select DMA_ENGINE
 +   select ASYNC_TX_ENABLE_CHANNEL_SWITCH
 +   help
 + Enable support for the APM X-Gene SoC DMA engine.
 +
  config DMA_ENGINE
 bool

 diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
 index f915f61..06c1576 100644
 --- a/drivers/dma/Makefile
 +++ b/drivers/dma/Makefile
 @@ -51,3 +51,4 @@ obj-$(CONFIG_INTEL_MIC_X100_DMA) += mic_x100_dma.o
  obj-$(CONFIG_NBPFAXI_DMA) += nbpfaxi.o
  obj-$(CONFIG_DMA_SUN6I) += sun6i-dma.o
  obj-$(CONFIG_IMG_MDC_DMA) += img-mdc-dma.o
 +obj-$(CONFIG_XGENE_DMA) += xgene-dma.o
 diff --git a/drivers/dma/xgene-dma.c b/drivers/dma/xgene-dma.c
 new file mode 100755
 index 000..e736c2e
 --- /dev/null
 +++ b/drivers/dma/xgene-dma.c
 @@ -0,0 +1,1738 @@
 +/*
 + * Applied Micro X-Gene SoC DMA engine Driver
 + *
 + * Copyright (c) 2015, Applied Micro Circuits Corporation
 + * Authors: Rameshwar Prasad Sahu 
 + * Loc Ho 
 + *
 + * 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.
 + *
 + * You should have received a copy of the GNU General Public License
 + * along with this program.  If not, see .
 + *
 + * NOTE: PM support is currently not available.
 + */
 +
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +
 +#include "dmaengine.h"
 +
 +/* DMA ring csr registers and bit definations */
 +#define DMA_RING_CONFIG0x04
 +#define DMA_RING_ENABLEBIT(31)
 +#define DMA_RING_ID0x08
 +#define DMA_RING_ID_SETUP(v)   ((v) | BIT(31))
 +#define DMA_RING_ID_BUF0x0C
 +#define DMA_RING_ID_BUF_SETUP(v)   (((v) << 9) | BIT(21))
 +#define DMA_RING_THRESLD0_SET1 0x30
 +#define DMA_RING_THRESLD0_SET1_VAL 0X64
 +#define DMA_RING_THRESLD1_SET1 0x34
 +#define DMA_RING_THRESLD1_SET1_VAL 0xC8
 +#define DMA_RING_HYSTERESIS0x68
 +#define DMA_RING_HYSTERESIS_VAL0x
 +#define DMA_RING_STATE 0x6C
 +#define DMA_RING_STATE_WR_BASE 0x70
 +#define DMA_RING_NE_INT_MODE   0x017C
 +#define DMA_RING_NE_INT_MODE_SET(m, v) \
 +   ((m) = ((m) & ~BIT(31 - (v))) | BIT(31 - (v)))
 +#define DMA_RING_NE_INT_MODE_RESET(m, v)   \
 +   ((m) &= (~BIT(31 - (v
 +#define DMA_RING_CLKEN 0xC208
 +#define DMA_RING_SRST  0xC200
 +#define DMA_RING_MEM_RAM_SHUTDOWN  0xD070
 +#define DMA_RING_BLK_MEM_RDY   0xD074
 +#define DMA_RING_BLK_MEM_RDY_VAL   0x
 +#define DMA_RING_DESC_CNT(v)   (((v) & 0x0001FFFE) >> 1)
 +#define DMA_RING_ID_GET(owner, num)(((owner) << 6) | (num))
 +#define DMA_RING_DST_ID(v) ((1 << 10) | (v))
 +#define DMA_RING_CMD_OFFSET0x2C
 +#define DMA_RING_CMD_BASE_OFFSET(v)((v) << 6)
 +#define DMA_R

Re: [PATCH 0/7] OPP: Introduce OPP bindings V2 and supporting code

[Viresh Kumar]

On 11 February 2015 at 13:46, Viresh Kumar  wrote:
> Now that I have received an verbal Ack from Rob Herring (in a personal
> conversation) about the bindings, I am showing how the code looks like with
> these new bindings.
>
> Some part is still now done:

s/now/not

> - Interface for adding new detailed OPPs from platform code instead of DT
> - Providing cpufreq helpers for the next OPPs
> - Providing regulator helpers for the target/min/max ranges
>
> Please provide feedback on how this looks like..

Can we have some reviews of the code changes please ?

--
viresh
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 1/3] dmaengine: Add support for APM X-Gene SoC DMA engine driver

[Rameshwar Sahu]

Hi,


On Thu, Feb 26, 2015 at 7:55 PM, Ben Dooks  wrote:
> On 26/02/15 12:31, Rameshwar Sahu wrote:
>> Hi Vinod,
>>
>>
>> On Tue, Feb 24, 2015 at 6:23 PM, Rameshwar Prasad Sahu  wrote:
>>> This patch implements the APM X-Gene SoC DMA engine driver. The APM X-Gene
>>> SoC DMA engine consists of 4 DMA channels for performing DMA operations.
>>> These DMA operations include memory copy and scatter-gather memory copy
>>> offloading.
>>>
>>> Signed-off-by: Rameshwar Prasad Sahu 
>>> Signed-off-by: Loc Ho 
>>> ---
>>>  drivers/dma/Kconfig |8 +
>>>  drivers/dma/Makefile|1 +
>>>  drivers/dma/xgene-dma.c | 1738 
>>> +++
>>>  3 files changed, 1747 insertions(+)
>>>  create mode 100755 drivers/dma/xgene-dma.c
>>>
>>> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
>>> index a874b6e..0e05831 100644
>>> --- a/drivers/dma/Kconfig
>>> +++ b/drivers/dma/Kconfig
>>> @@ -425,6 +425,14 @@ config IMG_MDC_DMA
>>> help
>>>   Enable support for the IMG multi-threaded DMA controller (MDC).
>>>
>>> +config XGENE_DMA
>>> +   tristate "APM X-Gene DMA support"
>>> +   depends on ARCH_XGENE
>>> +   select DMA_ENGINE
>>> +   select ASYNC_TX_ENABLE_CHANNEL_SWITCH
>>> +   help
>>> + Enable support for the APM X-Gene SoC DMA engine.
>>> +
>>>  config DMA_ENGINE
>>> bool
>>>
>>> diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
>>> index f915f61..06c1576 100644
>>> --- a/drivers/dma/Makefile
>>> +++ b/drivers/dma/Makefile
>>> @@ -51,3 +51,4 @@ obj-$(CONFIG_INTEL_MIC_X100_DMA) += mic_x100_dma.o
>>>  obj-$(CONFIG_NBPFAXI_DMA) += nbpfaxi.o
>>>  obj-$(CONFIG_DMA_SUN6I) += sun6i-dma.o
>>>  obj-$(CONFIG_IMG_MDC_DMA) += img-mdc-dma.o
>>> +obj-$(CONFIG_XGENE_DMA) += xgene-dma.o
>>> diff --git a/drivers/dma/xgene-dma.c b/drivers/dma/xgene-dma.c
>>> new file mode 100755
>>> index 000..e736c2e
>>> --- /dev/null
>>> +++ b/drivers/dma/xgene-dma.c
>>> @@ -0,0 +1,1738 @@
>>> +/*
>>> + * Applied Micro X-Gene SoC DMA engine Driver
>>> + *
>>> + * Copyright (c) 2015, Applied Micro Circuits Corporation
>>> + * Authors: Rameshwar Prasad Sahu 
>>> + * Loc Ho 
>>> + *
>>> + * 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.
>>> + *
>>> + * You should have received a copy of the GNU General Public License
>>> + * along with this program.  If not, see .
>>> + *
>>> + * NOTE: PM support is currently not available.
>>> + */
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +#include "dmaengine.h"
>>> +
>>> +/* DMA ring csr registers and bit definations */
>>> +#define DMA_RING_CONFIG0x04
>>> +#define DMA_RING_ENABLEBIT(31)
>>> +#define DMA_RING_ID0x08
>>> +#define DMA_RING_ID_SETUP(v)   ((v) | BIT(31))
>>> +#define DMA_RING_ID_BUF0x0C
>>> +#define DMA_RING_ID_BUF_SETUP(v)   (((v) << 9) | BIT(21))
>>> +#define DMA_RING_THRESLD0_SET1 0x30
>>> +#define DMA_RING_THRESLD0_SET1_VAL 0X64
>>> +#define DMA_RING_THRESLD1_SET1 0x34
>>> +#define DMA_RING_THRESLD1_SET1_VAL 0xC8
>>> +#define DMA_RING_HYSTERESIS0x68
>>> +#define DMA_RING_HYSTERESIS_VAL0x
>>> +#define DMA_RING_STATE 0x6C
>>> +#define DMA_RING_STATE_WR_BASE 0x70
>>> +#define DMA_RING_NE_INT_MODE   0x017C
>>> +#define DMA_RING_NE_INT_MODE_SET(m, v) \
>>> +   ((m) = ((m) & ~BIT(31 - (v))) | BIT(31 - (v)))
>>> +#define DMA_RING_NE_INT_MODE_RESET(m, v)   \
>>> +   ((m) &= (~BIT(31 - (v
>>> +#define DMA_RING_CLKEN 0xC208
>>> +#define DMA_RING_SRST  0xC200
>>> +#define DMA_RING_MEM_RAM_SHUTDOWN  0xD070
>>> +#define DMA_RING_BLK_MEM_RDY   0xD074
>>> +#define DMA_RING_BLK_MEM_RDY_VAL   0x
>>> +#define DMA_RING_DESC_CNT(v)   (((v) & 0x0001FFFE) >> 1)
>>> +#define DMA_RING_ID_GET(owner, num)(((owner) << 6) | (num))
>>> +#define DMA_RING_DST_ID(v) ((1 << 10) | (v))
>>> +#define DMA_RING_CMD_OFFSET0x2C
>>> +#define DMA_RING_CMD_BASE_OFFSET(v)((v) << 6)
>>> +#define DMA_RING_COHERENT_SET(m)   (((u32 *)(m))[2] |= BIT(4))
>>> +#define DMA_RING_ADDRL_SET(m, v)   (((u32 *)(m))[2] |= (((v) >> 8) << 
>>> 5))
>>> +#define DMA_RING_ADDRH_SET(m, v)   (((u32 *)(m))[3] |= ((v)

Re: [PATCH] arm64: dts: Fix GIC reg sizes for APM X-Gene

[Pranavkumar Sawargaonkar]

Hi Rob,

On Tue, Feb 24, 2015 at 8:00 PM, Rob Herring  wrote:
> On Tue, Feb 24, 2015 at 12:34 AM, Pranavkumar Sawargaonkar
>  wrote:
>> Hi Rob,
>>
>> On Mon, Feb 23, 2015 at 10:09 PM, Rob Herring  wrote:
>>> On Mon, Feb 23, 2015 at 6:07 AM, Christoffer Dall
>>>  wrote:
 On Sat, Feb 21, 2015 at 03:56:17PM -0600, Rob Herring wrote:
> On Thu, Feb 19, 2015 at 1:03 PM, Christoffer Dall
>  wrote:
> > On Thu, Feb 19, 2015 at 12:23:15PM -0600, Rob Herring wrote:
> >> On Tue, Jan 27, 2015 at 1:03 AM, Pranavkumar Sawargaonkar
> >>  wrote:
> >> > In APM X-Gene, GIC register space is 64K aligned while the sizes 
> >> > mentioned
> >> > in the dt are 4K aligned. This breaks KVM when kernel is built with 
> >> > 64K page
> >> > size due to size alignment checking in vgic driver for VCPU Control 
> >> > and
> >> > VCPU register.
> >> >
> >> > This patch corrects the sizes to be inline with the hardware spec.
> >>
> >> This does not make sense. The GIC regions are still only 4 or 8KB and
> >> the h/w description should reflect that. For implementations using
> >> gic-400 and the addressing decode trick, the rest of the register
> >> range is also not safe to access given it is multiple mapped. Also,
> >> this wastes virtual space, but I guess we don't care on 64-bit.
> >>
> >> KVM should be fixed to only check base address alignment. Size
> >> alignment does not matter (if it does, then you need to fix all
> >> register blocks).
> >>
> > It matters if you want to ensure that the 64K page you are assigning to
> > a guest for the GIC virtual CPU interface contains only GIC virtual CPU
> > mappings, and not other random stuff that the guest is not allowed to
> > touch.
>
> Good point.
>
> > How else should this be enforced?
>
> Rely on correct h/w design? You'll have to repeat this every time you
> want to do pass-thru of a device.
>
> What do you do if 64K mapping is not supported? Fallback to emulation
> of the CPU interface?

 Agree with Peter on these two points.

>
> Are there other DTSs that need to be fixed?
>
 Not sure really, AMD Seattle works with 64K pages IIRC.
>>>
>>> Well, looks we have been inconsistent here:
>>>
>>> arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi-   reg = <0x0
>>> 0xe111 0 0x1000>,
>>> arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi- <0x0
>>> 0xe112f000 0 0x2000>,
>>> arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi- <0x0
>>> 0xe114 0 0x1>,
>>> arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi- <0x0
>>> 0xe116 0 0x1>;
>>>
>>> arch/arm64/boot/dts/arm/juno.dts-   reg = <0x0 0x2c01 0 
>>> 0x1000>,
>>> arch/arm64/boot/dts/arm/juno.dts- <0x0 0x2c02f000 0 
>>> 0x2000>,
>>> arch/arm64/boot/dts/arm/juno.dts- <0x0 0x2c04f000 0 
>>> 0x2000>,
>>> arch/arm64/boot/dts/arm/juno.dts- <0x0 0x2c06f000 0 
>>> 0x2000>;
>>>
>>> If we are going to use 64K sizes, can we have some consistency here
>>> please. Which ranges really need 64KB sizes? It should only be the
>>> VCPU interface. right? Why does XGene need 128K? If XGene is doing
>>> address swizzling, then the CPU and VCPU base addresses are wrong.
>>> Seattle is also wrong for the VCPU, but no one has noticed because we
>>> don't use the DIR register IIRC.
>>>
>>> XGene should also add an "arm,gic-400" compatible string or something
>>> XGene specific if in fact it is not GIC-400.
>>
>> X-Gene has gic-400 as an interrupt controller.
>> Only thing is GIC pages are mapped at 64K boundary (with 64K page size)
>> Hence CPU, VCPU interfaces has a size of 128K (2GIC pages)
>> Regarding GICC_DIR, yes there is a problem which needs to be solved
>> since the first page size is 64K.
>> In XEN we already have a small fix to access GICC_DIR with 64K page
>> offset instead of standard 4K.
>
> Right, and in order for this to work, you should use the last 4K alias
> for the cpu interface(s). This is why other platforms use xxxf000 as
> their cpu interface base.
>
> It is of course possible that xgene does not properly do the address
> swizzling and therefore you have to use 64K aligned addresses. But in
> that case you need a unique compatible string.
>
>> I remember a small discussion in this regard in past
>> (http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/266468.html)
>> which was deferred at that time.
>> Once this patch is accepted we can post RFC patch to address GICC_DIR
>> and discuss further.
>
> No, let's get this right now and not keep changing the dts.
>

So should we add some string specific to apm/xgnene (something like
apm,cortex-a15-gic) or specific to 64K GIC page size
(arm,cortex-a15-gic-64Kpg) ?
Also till 3.19, I am not sure if any code is accessing GICC_DIR so for
now only thing which seems to be needed is a new dt 

Re: [PATCH 3/3] leds: Add ktd2692 flash LED driver

[Varka Bhadram]

On 02/27/2015 06:31 AM, Ingi Kim wrote:
> This patch adds a driver to support the ktd2692 flash LEDs.
> ktd2692 can control flash current by ExpressWire interface.
>
> Signed-off-by: Ingi Kim 
> ---
>   drivers/leds/Kconfig|8 ++
>   drivers/leds/Makefile   |1 +
>   drivers/leds/leds-ktd2692.c |  245 
> +++
>   3 files changed, 254 insertions(+)
>   create mode 100644 drivers/leds/leds-ktd2692.c
>
(...)

> +static struct ktd2692_context *ktd2692_parse_dt(struct device *dev)
> +{
> + struct device_node *np = dev->of_node;
> + struct ktd2692_context *led;
> +
> + led = devm_kzalloc(dev, sizeof(struct ktd2692_context), GFP_KERNEL);
> + if (!led)
> + return ERR_PTR((long)led);

What about using sizeof(*led) in place of sizeof(struct ktd2692_context)..?

Also the error return for devm_kzalloc() should be -ENOMEM.

> +
> + led->strobe_gpio = of_get_named_gpio(np, "strobe-gpio", 0);
> + if (!gpio_is_valid(led->strobe_gpio)) {
> + dev_err(dev, "no strobe_gpio property found\n");
> + return ERR_PTR(led->strobe_gpio);
> + }
> +
> + return led;
> +}
> +
> +static int ktd2692_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct ktd2692_context *led;
> + int ret;
> +
> + if (!dev->of_node)
> + return -ENODEV;
> +
> + led = ktd2692_parse_dt(dev);
> + if (IS_ERR(led))
> + return PTR_ERR(led);
> +
> + led->cdev.name = KTD2692_DEFAULT_NAME;
> + led->cdev.brightness = LED_OFF;
> + led->cdev.max_brightness = LED_FULL;
> + led->cdev.flags |= LED_CORE_SUSPENDRESUME;
> + led->cdev.brightness_set = ktd2692_brightness_set;
> + led->cdev.brightness_get = ktd2692_brightness_get;
> + led->mode = KTD2692_REG_MODE_BASE | KTD2692_MODE_DISABLE;
> +
> + platform_set_drvdata(pdev, led);
> +
> + ret = led_classdev_register(&pdev->dev, &led->cdev);
> + if (ret) {
> + dev_err(dev, "couldn't register LED %s\n", led->cdev.name);
> + return ret;
> + }
> +
> + ret = ktd2692_brightness_set_gpio(led);
> + if (ret) {
> + led_classdev_unregister(&led->cdev);
> + return ret;
> + }
> +
> + ktd2692_expresswire_reset(led);
> +
> + return ret;

return 0 instead of ret...?



-- 
Thanks,
Varka Bhadram.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 4/4] phy: add phy-hi6220-usb

[Peter Chen]

On Thu, Feb 26, 2015 at 04:48:30PM +0800, zhangfei wrote:
> Hi, Roger
> 
> On 02/24/2015 06:13 PM, Roger Quadros wrote:
> >>>On Sat, Feb 21, 2015 at 11:03:05PM +0800, zhangfei wrote:
> +static void hi6220_start_peripheral(struct hi6220_priv *priv, bool 
> on)
> +{
> +struct usb_otg *otg = priv->phy.otg;
> +
> +if (!otg->gadget)
> +return;
> +
> +if (on)
> +usb_gadget_connect(otg->gadget);
> +else
> +usb_gadget_disconnect(otg->gadget);
> >>>
> >>>why is the PHY fiddling with pullups ?
> >>
> >>We use this to enable/disable otg gadget mode.
> >
> >I got that, but the pullups don't belong to the PHY, they belong to the
> >gadget.
> >
> >>The gpio_id & gpio_vbus are used to distinguish otg gadget mode or
> >>host mode.
> >>When micro usb or otg device attached to otg, gpio_vbus falling down.
> >>And gpio_id = 1 is micro usb, gpio_id = 0 is otg device.
> >
> >all of that I understood clearly :-)
> >
> >>So when micro usb attached, we enable gadget mode; while micro usb
> >>detached, we disable gadget mode, and dwc2 will automatically set to
> >>host mode.
> >
> >that's all fine, I'm concerned about letting the PHY fiddle with
> >something it doesn't own. If I am to change pullups rules in udc-core,
> >this is likely to break down miserably and I don't want to have to go
> >through that.
> 
> Thanks for the clarifying.
> >>>
> >>>no problem.
> >>>
> How about using usb_gadget_vbus_connect/disconnect, which are used in many
> files under drivers/usb/phy.
> There is no vbus_session in dwc2/gadget.c, I thought it would be same as
> pullup.
> 
> However, usb_gadget_vbus_connect still need para gadget, where should we 
> put
> this file, drivers/usb/phy or drivers/phy
> >>>
> >>>drivers/phy, if the framework misses anything you need, it's a great
> >>>opportunity to give back to the community by extending the framework.
> >>
> >>Sorry, I am a little confused.
> >>I need some concrete suggestion for the next step of this patch, which is 
> >>required for the community board, hikey board.
> >>
> >>Do you mean in the future we need use hsotg->phy instead of hsotg->uphy.
> >> struct phy *phy;
> >> struct usb_phy *uphy;
> >>usb_phy has many members that struct phy does not have, including otg.
> >>struct usb_otg  *otg;
> >>Is that mean we need port such member from usb_phy to phy.
> >
> >In my opinion otg structure should belong to the USB core part that takes 
> >care
> >of the OTG/DRD state machine. We still don't have a clear solution here and
> >I'm currently investigating this.
> >My current work is to get Dual role functionality working with DWC3 
> >controller and TI
> >platforms.
> >
> >Currently phy drivers take care of OTG operation themselves but there is an 
> >opportunity
> >to share code and centralize USB role switching.
> >The USB core should be the owner of the Host controller, Gadget controller 
> >and the OTG phy
> >and should take care of the that.
> 
> Good idea.
> If you have any patch, I will be very happy to verify.
> 
> How about adding these things in drivers/phy/phy-core.c, it is also
> sharable, though not in usb core.
> 
> Just tried adding one member struct usb_otg otg to struct phy, since
> not find any good member can hold usb_otg.
> In drivers/phy/phy-core.c, adding extcon_register_interest,
> phy_vbus_notifier, phy_set_peripheral, it works for me, dwc2 on
> hikey board.

Just thinking if we can follow struct usb_hcd and struct ehci_hcd design
way, the generic phy just like hcd, and the usb phy like ehci hcd which
is a private data for hcd. zhangfei, maybe you can have a try.

-- 

Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 4/7] clk: Add clock driver for mb86s7x

[Mike Turquette]

Quoting Vincent Yang (2015-02-05 18:10:49)
> From: Jassi Brar 
> 
>  The CRG11 clock controller is managed by remote f/w.
> This driver simply maps Linux CLK ops onto mailbox api.
> 
> Signed-off-by: Jassi Brar 
> Signed-off-by: Andy Green 
> Signed-off-by: Vincent Yang 
> Signed-off-by: Tetsuya Nuriya 
> ---
>  .../bindings/clock/fujitsu,mb86s70-crg11.txt   |  26 ++
>  drivers/clk/Makefile   |   1 +
>  drivers/clk/clk-mb86s7x.c  | 386 
> +
>  3 files changed, 413 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/clock/fujitsu,mb86s70-crg11.txt
>  create mode 100644 drivers/clk/clk-mb86s7x.c
> 
> diff --git 
> a/Documentation/devicetree/bindings/clock/fujitsu,mb86s70-crg11.txt 
> b/Documentation/devicetree/bindings/clock/fujitsu,mb86s70-crg11.txt
> new file mode 100644
> index 000..3323962
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/fujitsu,mb86s70-crg11.txt
> @@ -0,0 +1,26 @@
> +Fujitsu CRG11 clock driver bindings
> +---
> +
> +Required properties :
> +- compatible : Shall contain "fujitsu,mb86s70-crg11"
> +- #clock-cells : Shall be 3 {cntrlr domain port}
> +
> +The consumer specifies the desired clock pointing to its phandle.
> +
> +Example:
> +
> +   clock: crg11 {
> +   compatible = "fujitsu,mb86s70-crg11";
> +   #clock-cells = <3>;
> +   };
> +
> +   mhu: mhu0@2b1f {
> +   #mbox-cells = <1>;
> +   compatible = "arm,mhu";
> +   reg = <0 0x2B1F 0x1000>;
> +   interrupts = <0 36 4>, /* LP Non-Sec */
> +<0 35 4>, /* HP Non-Sec */
> +<0 37 4>; /* Secure */
> +   clocks = <&clock 0 2 1>; /* Cntrlr:0 Domain:2 Port:1 */

Some preprocessor definitions would be better than hardcoding the values
for Cntrlr, Domain and Port. The DT include chroot should help you
here. Doing so will help you maintain this stuff into the future :-)

Regards,
Mike
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/3] leds: Add ktd2692 flash LED driver

[Ingi Kim]

This patch adds a driver to support the ktd2692 flash LEDs.
ktd2692 can control flash current by ExpressWire interface.

Signed-off-by: Ingi Kim 
---
 drivers/leds/Kconfig|8 ++
 drivers/leds/Makefile   |1 +
 drivers/leds/leds-ktd2692.c |  245 +++
 3 files changed, 254 insertions(+)
 create mode 100644 drivers/leds/leds-ktd2692.c

diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 25b320d..f8870db 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -526,6 +526,14 @@ config LEDS_VERSATILE
  This option enabled support for the LEDs on the ARM Versatile
  and RealView boards. Say Y to enabled these.
 
+config LEDS_KTD2692
+   tristate "LED support for the KTD2692 Driver"
+   depends on LEDS_CLASS
+   depends on GPIOLIB
+   help
+ This option enables support for the KTD2692 connected through
+ ExpressWire Interface. Say Y to enable these.
+
 comment "LED Triggers"
 source "drivers/leds/trigger/Kconfig"
 
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index cbba921..289513b 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -58,6 +58,7 @@ obj-$(CONFIG_LEDS_BLINKM) += leds-blinkm.o
 obj-$(CONFIG_LEDS_SYSCON)  += leds-syscon.o
 obj-$(CONFIG_LEDS_VERSATILE)   += leds-versatile.o
 obj-$(CONFIG_LEDS_MENF21BMC)   += leds-menf21bmc.o
+obj-$(CONFIG_LEDS_KTD2692) += leds-ktd2692.o
 
 # LED SPI Drivers
 obj-$(CONFIG_LEDS_DAC124S085)  += leds-dac124s085.o
diff --git a/drivers/leds/leds-ktd2692.c b/drivers/leds/leds-ktd2692.c
new file mode 100644
index 000..9c98689
--- /dev/null
+++ b/drivers/leds/leds-ktd2692.c
@@ -0,0 +1,245 @@
+/*
+ * Kinetic Technologies KTD2692 Flash LED Driver
+ *
+ * Copyright (C) 2015 Samsung Electronics
+ * Ingi Kim 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define GET_BIT(bit, val)  (((val) >> (bit)) & 0x01)
+
+/* Adjust a multiple of brightness */
+#define KTD2692_BRIGHTNESS_RANGE_255_TO_16(x)  (((x) >> 4) & 0x0F)
+#define KTD2692_BRIGHTNESS_RANGE_255_TO_8(x)   (((x) >> 5) & 0x0F)
+#define KTD2692_BRIGHTNESS_RANGE_255_TO_4(x)   (((x) >> 6) & 0x0F)
+
+/* Base register address */
+#define KTD2692_REG_LVP_BASE   0x00
+#define KTD2692_REG_FLASH_TIMEOUT_BASE 0x20
+#define KTD2692_REG_MIN_CURRENT_SET_BASE   0x40
+#define KTD2692_REG_MOVIE_CURRENT_BASE 0x60
+#define KTD2692_REG_FLASH_CURRENT_BASE 0x80
+#define KTD2692_REG_MODE_BASE  0xA0
+
+/* Set bit coding time for expresswire interface */
+#define KTD2692_TIME_RESET_US  700
+#define KTD2692_TIME_DATA_START_TIME_US10
+#define KTD2692_TIME_HIGH_END_OF_DATA_US   350
+#define KTD2692_TIME_LOW_END_OF_DATA_US10
+#define KTD2692_TIME_SHORT_BITSET_US   4
+#define KTD2692_TIME_LONG_BITSET_US12
+
+/* KTD2692 default length of name */
+#define KTD2692_NAME_LENGTH20
+
+/* KTD2692 default name */
+#define KTD2692_DEFAULT_NAME   "ktd2692"
+
+enum ktd2692_mode {
+   KTD2692_MODE_DISABLE = 0,
+   KTD2692_MODE_MOVIE,
+   KTD2692_MODE_FLASH,
+};
+
+enum ktd2692_bitset {
+   KTD2692_LOW = 0,
+   KTD2692_HIGH,
+};
+
+struct ktd2692_context {
+   struct led_classdev cdev;
+   u8 mode;
+   int strobe_gpio;
+};
+
+static int ktd2692_brightness_set_gpio(struct ktd2692_context *led)
+{
+   int ret;
+
+   ret = devm_gpio_request_one(led->cdev.dev,
+   led->strobe_gpio, GPIOF_INIT_LOW, "strobe-gpio");
+
+   if (ret)
+   dev_err(led->cdev.dev,
+   "failed to request strobe-gpio %d error %d\n",
+   led->strobe_gpio, ret);
+
+   return ret;
+}
+
+static void ktd2692_expresswire_start(struct ktd2692_context *led)
+{
+   gpio_set_value(led->strobe_gpio, KTD2692_HIGH);
+   udelay(KTD2692_TIME_DATA_START_TIME_US);
+}
+
+static void ktd2692_expresswire_reset(struct ktd2692_context *led)
+{
+   gpio_set_value(led->strobe_gpio, KTD2692_LOW);
+   udelay(KTD2692_TIME_RESET_US);
+}
+
+static void ktd2692_expresswire_end(struct ktd2692_context *led)
+{
+   gpio_set_value(led->strobe_gpio, KTD2692_LOW);
+   udelay(KTD2692_TIME_LOW_END_OF_DATA_US);
+   gpio_set_value(led->strobe_gpio, KTD2692_HIGH);
+   udelay(KTD2692_TIME_HIGH_END_OF_DATA_US);
+}
+
+static void ktd2692_expresswire_set_bit(struct ktd2692_context *led, bool bit)
+{
+   if (bit) {
+   gpio_set_value(led->strobe_gpio, KTD2692_LOW);
+   udelay(KTD2692_TIME_SHORT_BITSET_US);
+   gpio_set_value(led->strobe_gpio, KTD

Re: [PATCH v2 1/2] Input: touchscreen-iproc: Add Broadcom iProc touchscreen driver

[Jonathan Richardson]

Hi Dmitry,

Thanks. I'll go through his patch and make the appropriate changes to
our driver.

Jon

On 15-02-24 03:18 PM, Dmitry Torokhov wrote:
> Jonathan,
> 
> 
> On Wed, Feb 11, 2015 at 10:45:34AM -0800, Jonathan Richardson wrote:
>> Pinging maintainers... Am I ok to go ahead with the current rotation
>> implementation? I haven't heard anything further. Any feedback on naming
>> conventions from DT people?
>>
> 
> I believe we should go with touchscreen-inverted-x,
> touchscreen-inverted-y and touchscreen-swapped-x-y properties since
> rotation can't really describe all permutations of potential
> connections.
> 
> I'll be taking Hans de Goede's patch adding this new property to the
> bindings (adjusting the name slightly).
> 
> Thanks.
> 
>> Thanks!
>>
>> On 15-01-15 11:51 AM, Jonathan Richardson wrote:
>>> Hi Dmitry,
>>>
>>> On 15-01-14 10:07 PM, Dmitry Torokhov wrote:
 On Wed, Jan 14, 2015 at 09:44:39PM -0800, Scott Branden wrote:
> On 15-01-14 05:02 PM, Dmitry Torokhov wrote:
>> Hi Jonathan,
>>
>> On Fri, Dec 19, 2014 at 02:17:49PM -0800, Jonathan Richardson wrote:
>>> +   if (of_property_read_u32(np, "scanning_period", &val) >= 0) {
>>> +   if (val < 1 || val > 256) {
>>> +   dev_err(dev, "scanning_period must be 
>>> [1-256]\n");
>>> +   return -EINVAL;
>>> +   }
>>> +   priv->cfg_params.scanning_period = val;
>>> +   }
>>> +
>>> +   if (of_property_read_u32(np, "debounce_timeout", &val) >= 0) {
>>> +   if (val < 0 || val > 255) {
>>> +   dev_err(dev, "debounce_timeout must be 
>>> [0-255]\n");
>>> +   return -EINVAL;
>>> +   }
>>> +   priv->cfg_params.debounce_timeout = val;
>>> +   }
>>> +
>>> +   if (of_property_read_u32(np, "settling_timeout", &val) >= 0) {
>>> +   if (val < 0 || val > 11) {
>>> +   dev_err(dev, "settling_timeout must be 
>>> [0-11]\n");
>>> +   return -EINVAL;
>>> +   }
>>> +   priv->cfg_params.settling_timeout = val;
>>> +   }
>>> +
>>> +   if (of_property_read_u32(np, "touch_timeout", &val) >= 0) {
>>> +   if (val < 0 || val > 255) {
>>> +   dev_err(dev, "touch_timeout must be [0-255]\n");
>>> +   return -EINVAL;
>>> +   }
>>> +   priv->cfg_params.touch_timeout = val;
>>> +   }
>>> +
>>> +   if (of_property_read_u32(np, "average_data", &val) >= 0) {
>>> +   if (val < 0 || val > 8) {
>>> +   dev_err(dev, "average_data must be [0-8]\n");
>>> +   return -EINVAL;
>>> +   }
>>> +   priv->cfg_params.average_data = val;
>>> +   }
>>> +
>>> +   if (of_property_read_u32(np, "fifo_threshold", &val) >= 0) {
>>> +   if (val < 0 || val > 31) {
>>> +   dev_err(dev, "fifo_threshold must be [0-31]\n");
>>> +   return -EINVAL;
>>> +   }
>>> +   priv->cfg_params.fifo_threshold = val;
>>> +   }
>>
>> I think these are dveice specific and thus should have "brcm," prefix.
> I'm confused as to why we need the brcm prefix?  Other device tree
> bindings we have for other drivers do not need such prefix.

 Properties that are not standard on the system (reg, interrupts,
 clkocks, etc) or subsystem level customarily carry the vendor prefix so
 that they do not clash with newly added global or subsystem properties.

>  Is this
> convention documented somewhere?

 Not sure. I glanced through Documentation/devicetree and do not see it
 spelled out. Device tree overlords, what say you?
>>>
>>> Let me know. I haven't seen this before either. I will change the
>>> entries to use dashes though instead of underscores but will wait until
>>> these other issues are decided on before sending out another patch.
>>>

>>
>>> +
>>> +   priv->ts_rotation = TS_ROTATION_0;
>>> +   if (of_property_read_u32(np, "ts-rotation", &val) >= 0) {
>>> +   priv->ts_rotation = val;
>>> +   dev_dbg(dev, "ts rotation [%d] degrees\n",
>>> +   90 * priv->ts_rotation);
>>> +   }
>>
>> This I am not quite sure about - if we want rotation or swap+invert. You
>> are CCed on another email (tsc2007) that talks about need of generic
>> touchscreen transforms in input core/of bindings.
> Does such generic binding exist today?  If not, I would like to go
> with this implementation and update to the new binding if/when it
> exists?

 Not yet but there 

[PATCH 0/3] Add ktd2692 Flash LED driver

[Ingi Kim]

This patch supports KTD2692 flash LED driver

Ingi Kim (3):
  of: Add vendor prefix for Kinetic technologies
  leds: ktd2692: add device tree bindings for ktd2692
  leds: Add ktd2692 flash LED driver

 .../devicetree/bindings/leds/leds-ktd2692.txt  |   19 ++
 .../devicetree/bindings/vendor-prefixes.txt|1 +
 drivers/leds/Kconfig   |8 +
 drivers/leds/Makefile  |1 +
 drivers/leds/leds-ktd2692.c|  245 
 5 files changed, 274 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/leds/leds-ktd2692.txt
 create mode 100644 drivers/leds/leds-ktd2692.c

-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/3] of: Add vendor prefix for Kinetic technologies

[Ingi Kim]

This patch adds vendor prefix for Kinetic technologies

Signed-off-by: Ingi Kim 
---
 .../devicetree/bindings/vendor-prefixes.txt|1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 389ca13..de9e126 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -98,6 +98,7 @@ isee  ISEE 2007 S.L.
 isil   Intersil
 karo   Ka-Ro electronics GmbH
 keymileKeymile GmbH
+kinetic Kinetic Technologies
 lacie  LaCie
 lantiq Lantiq Semiconductor
 lenovo Lenovo Group Ltd.
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/3] leds: ktd2692: add device tree bindings for ktd2692

[Ingi Kim]

This patch adds the device tree bindings for ktd2692 flash LEDs

Signed-off-by: Ingi Kim 
---
 .../devicetree/bindings/leds/leds-ktd2692.txt  |   19 +++
 1 file changed, 19 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/leds/leds-ktd2692.txt

diff --git a/Documentation/devicetree/bindings/leds/leds-ktd2692.txt 
b/Documentation/devicetree/bindings/leds/leds-ktd2692.txt
new file mode 100644
index 000..b68faa6
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-ktd2692.txt
@@ -0,0 +1,19 @@
+* Kinetic Technologies - KTD2692 Flash LED Driver
+
+KTD2692 is the ideal power solution for high-power flash LEDs.
+It uses ExpressWire single-wire programming for maximum flexibility.
+
+Required properties:
+   - compatible: "kinetic,ktd2692"
+   - strobe-gpio: gpio pin to control movie mode current level.
+   - torch-gpio: gpio pin to control ON/OFF flash mode
+as a higher priority over strobe-gpio.
+
+Example:
+
+flash-led {
+   compatible = "kinetic,ktd2692";
+   strobe-gpio = <&gpc0 1 0>;
+   torch-gpio = <&gpc0 2 0>;
+   status = "okay";
+};
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 0/1] Synopsis 8250 serial port driver fix

[Jonathan Richardson]

Hi,

This patchset fixes a bug in the Synopsis 8250 serial driver which causes the
driver to hang. The bug occurs on simple 2 wire serial ports when modem control
signalling has been enabled. It can be reproduced from user space by enabling
modem control signals (stty -clocal), then opening a serial port and polling for
data available to read with a timeout. A properly implemented driver will
ignore the control signals and the call to poll will return. The current
version of the driver hangs forever on the call to poll despite the timeout.

Jon

Changes from v1:
- Changed DT properties from strings to booleans as suggested by Arnd. 
  Documentation updated accordingly.

Desmond Liu (1):
  serial: 8250_dw: Fix get_mctrl behaviour

 .../bindings/serial/snps-dw-apb-uart.txt   |   16 ++
 drivers/tty/serial/8250/8250_dw.c  |   32 
 2 files changed, 48 insertions(+)

-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/1] serial: 8250_dw: Fix get_mctrl behaviour

[Jonathan Richardson]

From: Desmond Liu 

Fixed behaviour of get_mctrl() serial driver function as documented in:
https://www.kernel.org/doc/Documentation/serial/driver

Added device-tree properties 'dcd-override', 'dsr-override',
'cts-override', and 'ri-override' specific to the Synopsis 8250
DesignWare UART driver. Allows one to force Data Carrier Detect,
Clear To Send, and Data Set Ready signals to permanently be reported as
active. The Ring indicator can be forced to be reported as inactive.

It is possible that if modem control signalling is enabled on a port
that doesn't have these pins (e.g. - a simple two wire Tx/Rx port), the
driver can hang indefinitely waiting for the state to change. The new
DT properties allow the driver to ignore the state of these pins on
serial ports that don't support them, as recommended in the kernel
documentation.

Reviewed-by: JD (Jiandong) Zheng 
Signed-off-by: Jonathan Richardson 
---
 .../bindings/serial/snps-dw-apb-uart.txt   |   16 ++
 drivers/tty/serial/8250/8250_dw.c  |   32 
 2 files changed, 48 insertions(+)

diff --git a/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.txt 
b/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.txt
index 7f76214..289c40e 100644
--- a/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.txt
+++ b/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.txt
@@ -21,6 +21,18 @@ Optional properties:
 - reg-io-width : the size (in bytes) of the IO accesses that should be
   performed on the device.  If this property is not present then single byte
   accesses are used.
+- dcd-override : Override the DCD modem status signal. This signal will always
+  be reported as active instead of being obtained from the modem status
+  register. Define this if your serial port does not use this pin.
+- dsr-override : Override the DTS modem status signal. This signal will always
+  be reported as active instead of being obtained from the modem status
+  register. Define this if your serial port does not use this pin.
+- cts-override : Override the CTS modem status signal. This signal will always
+  be reported as active instead of being obtained from the modem status
+  register. Define this if your serial port does not use this pin.
+- ri-override : Override the RI modem status signal. This signal will always be
+  reported as inactive instead of being obtained from the modem status 
register.
+  Define this if your serial port does not use this pin.
 
 Example:
 
@@ -31,6 +43,10 @@ Example:
interrupts = <10>;
reg-shift = <2>;
reg-io-width = <4>;
+   dcd-override;
+   dsr-override;
+   cts-override;
+   ri-override;
};
 
 Example with one clock:
diff --git a/drivers/tty/serial/8250/8250_dw.c 
b/drivers/tty/serial/8250/8250_dw.c
index 555de07..1f1d2e6 100644
--- a/drivers/tty/serial/8250/8250_dw.c
+++ b/drivers/tty/serial/8250/8250_dw.c
@@ -59,6 +59,8 @@ struct dw8250_data {
u8  usr_reg;
int last_mcr;
int line;
+   int msr_mask_on;
+   int msr_mask_off;
struct clk  *clk;
struct clk  *pclk;
struct reset_control*rst;
@@ -81,6 +83,12 @@ static inline int dw8250_modify_msr(struct uart_port *p, int 
offset, int value)
value &= ~UART_MSR_DCTS;
}
 
+   /* Override any modem control signals if needed */
+   if (offset == UART_MSR) {
+   value |= d->msr_mask_on;
+   value &= ~d->msr_mask_off;
+   }
+
return value;
 }
 
@@ -334,6 +342,30 @@ static int dw8250_probe_of(struct uart_port *p,
if (id >= 0)
p->line = id;
 
+   if (of_property_read_bool(np, "dcd-override")) {
+   /* Always report DCD as active */
+   data->msr_mask_on |= UART_MSR_DCD;
+   data->msr_mask_off |= UART_MSR_DDCD;
+   }
+
+   if (of_property_read_bool(np, "dsr-override")) {
+   /* Always report DSR as active */
+   data->msr_mask_on |= UART_MSR_DSR;
+   data->msr_mask_off |= UART_MSR_DDSR;
+   }
+
+   if (of_property_read_bool(np, "cts-override")) {
+   /* Always report DSR as active */
+   data->msr_mask_on |= UART_MSR_DSR;
+   data->msr_mask_off |= UART_MSR_DDSR;
+   }
+
+   if (of_property_read_bool(np, "ri-override")) {
+   /* Always report Ring indicator as inactive */
+   data->msr_mask_off |= UART_MSR_RI;
+   data->msr_mask_off |= UART_MSR_TERI;
+   }
+
/* clock got configured through clk api, all done */
if (p->uartclk)
return 0;
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@v

Re: [PATCH] regulator: qcom-rpm: Rework for single device

[Stephen Boyd]

On 02/26/15 16:00, Stephen Boyd wrote:
> The RPM regulators are not individual devices. Creating platform
> devices for each regulator bloats the kernel's runtime memory
> footprint by ~12k. Let's rework this driver to be a single
> platform device for all the RPM regulators. This makes the
> DT match the schematic/datasheet closer too because now the
> regulators node contains a list of supplies at the package level
> for a particular PMIC model.
>
> Signed-off-by: Stephen Boyd 
> ---
>


This is the RPM node I used for testing so you can see the resulting DT.

rpm@108000 {
compatible  = "qcom,rpm-apq8064";
reg = <0x108000 0x1000>;
qcom,ipc= <&l2cc 0x8 2>;

interrupts  = <0 19 0>, <0 21 0>, <0 22 0>;
interrupt-names = "ack", "err", "wakeup";

regulators {
compatible = "qcom,rpm-pm8921-regulators";
vin_l1_l2_l12_l18-supply = <&pm8921_s4>;
vin_lvs_1_3_6-supply = <&pm8921_s4>;
vin_lvs_4_5_7-supply = <&pm8921_s4>;
vin_ncp-supply = <&pm8921_l6>;
vin_lvs2-supply = <&pm8921_s4>;
vin_l24-supply = <&pm8921_s1>;
vin_l25-supply = <&pm8921_s1>;
vin_l27-supply = <&pm8921_s7>;
vin_l28-supply = <&pm8921_s7>;

/* Buck SMPS */
pm8921_s1: s1 {
regulator-always-on;
regulator-min-microvolt = <1225000>;
regulator-max-microvolt = <1225000>;
qcom,switch-mode-frequency = <320>;
bias-pull-down;
};

pm8921_s2: s2 {
regulator-min-microvolt = <130>;
regulator-max-microvolt = <130>;
qcom,switch-mode-frequency = <160>;
bias-pull-down;
};

pm8921_s3: s3 {
regulator-min-microvolt = <50>;
regulator-max-microvolt = <115>;
qcom,switch-mode-frequency = <480>;
bias-pull-down;
};

pm8921_s4: s4 {
regulator-always-on;
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
qcom,switch-mode-frequency = <160>;
bias-pull-down;
qcom,force-mode = 
;
};

pm8921_s7: s7 {
regulator-min-microvolt = <130>;
regulator-max-microvolt = <130>;
qcom,switch-mode-frequency = <320>;
};

pm8921_s8: s8 {
regulator-min-microvolt = <220>;
regulator-max-microvolt = <220>;
qcom,switch-mode-frequency = <160>;
};

/* PMOS LDO */
pm8921_l1: l1 {
regulator-always-on;
regulator-min-microvolt = <110>;
regulator-max-microvolt = <110>;
bias-pull-down;
};

pm8921_l2: l2 {
regulator-min-microvolt = <120>;
regulator-max-microvolt = <120>;
bias-pull-down;
};

pm8921_l3: l3 {
regulator-min-microvolt = <3075000>;
regulator-max-microvolt = <3075000>;
bias-pull-down;
};

  

[PATCH] regulator: qcom-rpm: Rework for single device

[Stephen Boyd]

The RPM regulators are not individual devices. Creating platform
devices for each regulator bloats the kernel's runtime memory
footprint by ~12k. Let's rework this driver to be a single
platform device for all the RPM regulators. This makes the
DT match the schematic/datasheet closer too because now the
regulators node contains a list of supplies at the package level
for a particular PMIC model.

Signed-off-by: Stephen Boyd 
---

On 02/24, Bjorn Andersson wrote:
> On Wed 18 Feb 18:29 PST 2015, Stephen Boyd wrote:
> 
> > On 02/18/15 13:08, Bjorn Andersson wrote:
> > > On Wed, Feb 18, 2015 at 12:28 PM, Stephen Boyd  
> > > wrote:
> 
> After taking a deeper look at this I've come to the following
> conclusion:
> 
> We can save 2100 bytes of data by spreading out the magic numbers from
> the rpm resource tables into the regulator, clock and bus drivers. At
> the cost of having this rpm-specific information spread out.
> 
> Separate of that we could rewrite the entire regulator implementation to
> define all regulators in platform specific tables in the regulators.
> This would save about 12-15k of ram.

Cool I started doing that.

> 
> This can however be done in two ways:
> 1) We modify the mfd driver to instatiate 3 mfd_cells; one of them
> being "qcom,rpm-regulators". We modify the regulator driver to have
> tables of the regulators for each platform and matching regulator
> parameters by of_node name and registering these.
> 
> 2) We stick with this binding, we then go ahead and do the same
> modification to the mfd as above - passing the rpm of_node to the
> regulator driver, that walks the children and match that to the current
> compatible list. (in other words, we replace of_platform_populate with
> our own mechamism).
> 
> 
> The benefit of 2 is that we can use the code that was posted 10 months
> ago and merged 3 months ago until someone prioritize those 12kb.

I did (1) without modifying the MFD driver.

> 
> 
> To take either of these paths the issue at the bottom has to be
> resolved first.

Right. I think that's resolved now.

> 
> 
> More answers follows inline:
> 
> > 
> > We're already maintaining these tables in qcom-rpm.c. I'm advocating for
> > removing those tables from the rpm driver and putting the data into the
> > regulator driver. Then we don't have to index into a sparse table to
> > figure out what values the RPM wants to use. Instead we have the data at
> > hand for a particular regulator based on the of_regulator_match.
> > 
> 
> I do like the "separation of concerns" between the rpm driver and the
> children, but you're right in that we're wasting almost 3kb in doing so:
> 
> (gdb) p sizeof(apq8064_rpm_resource_table) + 
> sizeof(msm8660_rpm_resource_table) + sizeof(msm8960_rpm_resource_table)
> $2 = 6384
> 
> vs
> 
> (gdb) p sizeof(struct qcom_rpm_resource) * (77 + 74 + 73)
> $3 = 3584
> 
> The alternative would be to spread those magic constants out in the
> three client drivers.
> 
> Looking at this from a software design perspective I stand by the
> argument that the register layout of the rpm is not a regulator driver
> implementation detail and is better kept separate.
> 
> As we decided to define the regulators in code but the actual
> composition in dt it was not possible to put the individual numbers in
> DT. Having reg = <165 68 48> does not make any sense, unless we perhaps
> maintain said table in the dt binding documentation.

For now I've left it so that the #define is used in C code.

> 
> > From what I can tell, that data is split in two places. The regulator
> > type knows how big the data we want to send is (1 or 2) and that is
> > checked in the RPM driver to make sure that the two agree (this part
> > looks like over-defensive coding).
> 
> Yeah, after debugging production code for years I like to be slightly on
> the defensive side. But the size could of course be dropped from the
> resource-tables; reducing the savings of your suggestion by another 800
> bytes...

Sounds good. We should probably do it.

> 
> > Then the DT has a made up number that
> > maps to 3 different numbers in the RPM driver.
> 
> Reading the following snippet in my dts file makes imidiate sense:
> 
> reg = 
> 
> the following doesn't make any sense:
> 
> reg = <116 31 30>;
> 
> Maybe it's write-once in a dts so it doesn't matter that much - as long
> as the node is descriptive. But I like the properties to be human
> understandable.

Wouldn't a

 #define QCOM_RPM_PM8921_SMPS1 116 31 30

suffice? That looks to be the same readability.

> 
> > If the RPM was moving these offsets
> > around within the same compatible string it would make sense to put that
> > in DT and figure out dynamically what the offsets are because they
> > really can be different.
> 
> The proposed binding states the following:
> 
> - compatible:
> Usage: required
> Value type: 
> Definition: must be one of:
> "qcom,rpm-pm8058-smps"
> "qcom,rpm-pm8901-f

Re: [PATCH 00/10] omap3 crypto fixes

[Aaro Koskinen]

Hi,

On Thu, Feb 26, 2015 at 02:49:50PM +0100, Pali Rohár wrote:
> This patch series fix crypto support for omap3 devices which use DT.
> 
> It enables AES and SHAM on N9/N950 and SHAM on N900. AES is still disabled 
> for N900.

(Please format your lines somewhere near < 76 chars, especially in
commit logs, otherwise "git log" looks ugly on 80 char terminals.)

I tested these with stock bootloaders, and devices boot normally
and I can now modprobe omap-aes (on N9 and N950) and omap-sham
(on all three):

omap-aes 480c5000.aes: OMAP AES hw accel rev: 2.6
omap-sham 480c3000.sham: hw accel on OMAP rev 0.9

However I get these when CONFIG_CRYPTO_MANAGER_DISABLE_TESTS is not set:

alg: hash: Chunking test 1 failed for omap-sha1
alg: hash: Chunking test 1 failed for omap-md5
alg: hash: Chunking test 1 failed for omap-hmac-sha1
alg: hash: Chunking test 1 failed for omap-hmac-md5

But that's probably unrelated to this series. For patches 1-8,
feel free to add:

Tested-by: Aaro Koskinen 

A.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/2] hwrng: iproc-rng200 - Add Broadcom IPROC RNG driver

[Scott Branden]

Hi Arnd,

Latency is 32 us for 32bits of data - commented inline.  What delay call 
do you recommend in this case?


On 15-02-26 12:15 PM, Arnd Bergmann wrote:

On Thursday 26 February 2015 11:37:20 Scott Branden wrote:

Response inline.

On 15-02-25 11:17 AM, Arnd Bergmann wrote:

On Wednesday 25 February 2015 10:16:24 Scott Branden wrote:

This adds a driver for random number generator present on Broadcom
IPROC devices.

Reviewed-by: Ray Jui 
Signed-off-by: Scott Branden 


The driver looks reasonable overall, I have just one question about
something that sticks out:


+while ((num_remaining > 0) && time_before(jiffies, idle_endtime)) {

...

+
+/* Are there any random numbers available? */
+if ((ioread32(rng_base + RNG_FIFO_COUNT_OFFSET) &
+RNG_FIFO_COUNT_RNG_FIFO_COUNT_MASK) > 0) {

...

+} else {
+if (!wait)
+/* Cannot wait, return immediately */
+return max - num_remaining;
+
+/* Can wait, give others chance to run */
+cpu_relax();
+}
+}
+


It looks like you do a busy-loop around cpu_relax here if asked to wait.
Is this intentional? I would normally expect either cond_resched() or
some msleep() instead.


This code was following examples of other open source drivers - bcm2835
and exynos both use cpu_relax.  I'll have to look into this more to
understand.



The majority of the driver apparently use udelay(10) to wait, which is
not much better but at least consistent. The cpu_relax() call probably
gives better throughput.

I don't understand why none of the drivers actually attempts to
msleep(), but that may be because the delay is much too long.

Can you find out what the expected latency is for new data to
become available on your hardware?

RNG generates at a nominal 1 Mbps.  So to generate 32 bits of data takes
approximately 32 us.



Arnd



--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] soc: ti: Add wkup_m3_ipc driver

[Tony Lindgren]

* Dave Gerlach  [150226 12:05]:
> Tony,
> On 01/05/2015 04:51 PM, Tony Lindgren wrote:
> > * Dave Gerlach  [150105 14:51]:
> >> Felipe,
> >> On 01/02/2015 02:16 PM, Felipe Balbi wrote:
> >>> On Fri, Jan 02, 2015 at 02:00:16PM -0600, Dave Gerlach wrote:
>  Introduce a wkup_m3_ipc driver to handle communication between the MPU
>  and Cortex M3 wkup_m3 present on am335x.
> 
>  This driver is responsible for actually booting the wkup_m3_rproc and
>  also handling all IPC which is done using the IPC registers in the 
>  control
>  module, a mailbox, and a separate interrupt back from the wkup_m3. A 
>  small
>  API is exposed for executing specific power commands, which include
>  configuring for low power mode, request a transition to a low power mode,
>  and status info on a previous transition.
> 
>  Signed-off-by: Dave Gerlach 
>  ---
>   drivers/soc/ti/Kconfig   |  11 ++
>   drivers/soc/ti/Makefile  |   1 +
>   drivers/soc/ti/wkup_m3_ipc.c | 451 
>  +++
>   include/linux/wkup_m3_ipc.h  |  33 
>   4 files changed, 496 insertions(+)
>   create mode 100644 drivers/soc/ti/wkup_m3_ipc.c
>   create mode 100644 include/linux/wkup_m3_ipc.h
> 
>  diff --git a/drivers/soc/ti/Kconfig b/drivers/soc/ti/Kconfig
>  index 7266b21..61cda85 100644
>  --- a/drivers/soc/ti/Kconfig
>  +++ b/drivers/soc/ti/Kconfig
>  @@ -28,4 +28,15 @@ config KEYSTONE_NAVIGATOR_DMA
>   
> If unsure, say N.
>   
>  +config WKUP_M3_IPC
>  +bool "TI AM33XX Wkup-M3 IPC Driver"
> >>>
> >>> tristate ?
> >>
> >> If we want to allow this and the rproc driver to be built as modules than 
> >> we can
> >> change this.
> > 
> > Yes please, the PM is never needed early, and should be optional.
> > And doing that will make it a lot easier for you to do further work
> > on your driver ;)
> > 
> > And it will also make it easier to add support for other SoCs as
> > it seems the same M3 is used at least on am437x.
> >  
> 
> I can not build the PM code as a module at this time due to many mach-omap
> function calls it uses which are not exported, so I need handles to all five
> functions in this driver used in pm33xx to call from built-in PM code. Do you
> have a preference on how these function handles get passed?

OK, you can pass the function pointers in platform_data. Care to
list those functions? That might allow us to make other omap PM
code into loadable modules in drivers/* :)
 
> I currently have added a pdata-quirks implementation that passes a function to
> the wkup_m3_ipc driver through it's pdata which it then calls at probe to 
> pass a
> struct containing all used function pointers to the pm code that were 
> previously
> called directly. Is that what you would prefer or something else? I had also
> looked at making the struct of function pointers in the driver global and just
> picking it up from the pm code with an extern declaration or even putting a 
> bus
> notifier in the PM code and watching for the wkup_m3_ipc driver to be bound.

Yeah pdata-quirks.c is probably OK for populating the function pointers.
We may have already some place in the PM code to pass it too.
 
> Thought I would see what you prefer and possibly avoid an unnecessary re-spin.

Sounds like we're getting close to getting am335x/am437x PM code working :)

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RESEND] coresight-stm: Bindings for System Trace Macrocell

[Rob Herring]

On Thu, Feb 26, 2015 at 10:14 AM, Mathieu Poirier
 wrote:
> The System Trace Macrocell (STM) is an IP block falling under the
> CoreSight umbrella.  It's main purpose it so expose stimulus channels
> to any system component for the purpose of information logging.
>
> Bindings for this IP block adds a couple of items to the current
> mandatory definition for CoreSight components.  The driver has been posted
> here[1].
>
> [1]. https://lkml.org/lkml/2015/2/25/743
>
> Signed-off-by: Mathieu Poirier 

Seems reasonable, but a couple minor comments below. Merge this with the driver:

Acked-by: Rob Herring 

> ---
>  .../devicetree/bindings/arm/coresight.txt  | 25 
> ++
>  1 file changed, 25 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/coresight.txt 
> b/Documentation/devicetree/bindings/arm/coresight.txt
> index a3089359aaa6..854127578718 100644
> --- a/Documentation/devicetree/bindings/arm/coresight.txt
> +++ b/Documentation/devicetree/bindings/arm/coresight.txt
> @@ -17,6 +17,7 @@ its hardware characteristcs.
> - "arm,coresight-tmc", "arm,primecell";
> - "arm,coresight-funnel", "arm,primecell";
> - "arm,coresight-etm3x", "arm,primecell";
> +   - "arm,coresight-stm", "arm,primecell";

No versions of STM?

> * reg: physical base address and length of the register
>   set(s) of the component.
> @@ -31,6 +32,14 @@ its hardware characteristcs.
>   layout using the generic DT graph presentation found in
>   "bindings/graph.txt".
>
> +* Additional required properly for System Trace Macrocells (STM):
> +   * reg: along with the physical base address and length of the register
> + set as described above, another entry is required to describe the
> + mapping of the extended stimulus port area.
> +
> +   * reg-names: the only acceptable values are "stm-base" and
> + "stm-channel-base", each corresponding to the areas defined in 
> "reg".

It is not really clear that "extended stimulus port area" corresponds
to "stm-channel-base".

> +
>  * Required properties for devices that don't show up on the AMBA bus, such as
>non-configurable replicators:
>
> @@ -198,3 +207,19 @@ Example:
> };
> };
> };
> +
> +4. STM
> +   stm@2010 {
> +   compatible = "arm,coresight-stm", "arm,primecell";
> +   reg = <0 0x2010 0 0x1000>,
> + <0 0x2800 0 0x18>;
> +   reg-names = "stm-base", "stm-channel-base";
> +
> +   clocks = <&soc_smc50mhz>;
> +   clock-names = "apb_pclk";
> +   port {
> +   stm_out_port: endpoint {
> +   remote-endpoint = <&main_funnel_in_port2>;
> +   };
> +   };
> +   };
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: SPDX-License-Identifier

[Pavel Machek]

On Thu 2015-02-26 10:26:50, One Thousand Gnomes wrote:
> > So that GPL header at begining of each file becomes one line... and so
> > that if it is BSD/GPL dual licensed is plain to see, and I don't have
> > to read the notices saying "oh this is gpl.. but if you want to,
> > delete gpl above and use license below".
> 
> That won't happen though. You'd require every single corporate legal
> department of every large company that touched the file to agree that the
> SPDX was equivalent to the content, and some of them probably won't.
> Lawyers don't seem to believe in #include 

Umm. I'd still like to see SPDX where corporate lawyers allow that,
and for new files.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: SPDX-License-Identifier

[Pavel Machek]

On Wed 2015-02-25 16:00:47, Felipe Balbi wrote:
> On Wed, Feb 25, 2015 at 10:49:51PM +0100, Pavel Machek wrote:
> > Hi!
> > 
> > > > >Is one tag per directory sufficient?  Is one tag per file sufficient?
> > > > >How about one tag per package?  If package, then isn't a single tag for
> > > > >the whole kernel source tree sufficient, as we all know the overall
> > > > >license for the kernel source tree.
> > > > 
> > > > We really need one tag per file.
> > > 
> > > I fail to see the justification for this, why?  Why not per directory?
> > > Why not per function?  Why not per driver?  Why not per line?  Why not
> > > per project?  Who has dictated this seemingly arbitrary rule?
> > 
> > That's how licenses are done today.
> > 
> > Why would I like to see SPDX?
> > 
> > So that GPL header at begining of each file becomes one line... and so
> > that if it is BSD/GPL dual licensed is plain to see, and I don't have
> > to read the notices saying "oh this is gpl.. but if you want to,
> > delete gpl above and use license below".
> 
> why isn't git grep -e 'MODULE_LICENSE' enough ? It's also a single line
> and gives you the license for that driver.
> 
> > > Our DCO process ensures that.
> > > 
> > > > - Some parts of the Linux source code are also used by other projects.
> > > >   Or are derived from other projects. Because of this they are
> > > >   explicitly licensed under different licenses than the GPLv2
> > > >   (compatible to it though of course). Or are dual-licensed. So that
> > > >   they can be used by these other projects.
> > > 
> > > That's fine, we encourage that and want to see that happen.  How will
> > > SPDX change that at all?  It's obvious as to the license of the files
> > > that this happens with, why do anything extra?
> > 
> > Well, sometimes parsing license agreements at the top of file is
> > interesting, that's where SPDX would help, and that's why having
> > single SPDX per linux kernel would not work.
> 
> if you can parse SPDX, why can't you parse MODULE_LICENSE() ?

Not all sources are modules. And yes, MODULE_LICENSE() helps, but spdx
would help, too: This would become one line.

Pavel

 * This software is available to you under a choice of one of two
  * licenses.  You may choose to be licensed under the terms of the
  * GNU
   * General Public License (GPL) Version 2, available from the file
* COPYING in the main directory of this source tree, or the
 * OpenIB.org BSD license below:
  *
   * Redistribution and use in source and binary forms, with
  * or
   * without modification, are permitted provided that the
  * following
   * conditions are met:
*
 *  - Redistributions of source code must retain the above
  *copyright notice, this list of conditions and the
  * following
   *disclaimer.
*
 *  - Redistributions in binary form must reproduce the above
  *copyright notice, this list of conditions and the
  * following
   *disclaimer in the documentation and/or other materials
*provided with the distribution.
 *
  * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
  * KIND,
   * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
  * OF
   * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
* NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
  * HOLDERS
   * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN
  * AN
   * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
* CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
 * SOFTWARE.
 



-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/8] i2c: mux-pinctrl: Rework to honor disabled child nodes

[Stephen Warren]

On 02/17/2015 11:52 AM, Sebastian Hesselbarth wrote:

I2C mux pinctrl driver currently determines the number of sub-busses by
counting available pinctrl-names. Unfortunately, this requires each
incarnation of the devicetree node with different available sub-busses
to be rewritten.

This patch reworks i2c-mux-pinctrl driver to count the number of
available sub-nodes instead. The rework should be compatible to the old
way of probing for sub-busses and additionally allows to disable unused
sub-busses with standard DT property status = "disabled".

This also amends the corresponding devicetree binding documentation to
reflect the new functionality to disable unused sub-nodes. While at it,
also fix two references to binding documentation files that miss an "i2c-"
prefix.


Tested-by: Stephen Warren 

(Both the HDMI and LCD panel DDC busses on NVIDIA Tegra 
Springbank/Seaboard, running next-20150224)

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 01/12] ARM: dts: apq8064: add RPM regulators support

[Bjorn Andersson]

On Thu, Feb 26, 2015 at 12:11 PM, Stephen Boyd  wrote:
> On 02/26/15 12:09, Srinivas Kandagatla wrote:
>>
>>
>> On 26/02/15 19:31, Stephen Boyd wrote:
>>> On 02/22/15 23:54, Srinivas Kandagatla wrote:
 +pm8921_s5: pm8921-s5 {
 +compatible= "qcom,rpm-pm8921-ftsmps";
 +reg= ;
 +};
 +
 +pm8921_s6: pm8921-s6 {
 +compatible= "qcom,rpm-pm8921-ftsmps";
 +reg= ;
 +};
 +
>>>
>>> There's no RPM control for S5 and S6. Please remove. Also, has this been
>>> tested?
>>>
>> Ahh. these are SAW regulators, I will remove it from the list.
>> Obviously, I did not test all the regulators.
>
> There are some more that don't seem to match what we have downstream.
> L26 is also SAW related, and the usb and hdmi switches are "locally"
> controlled via ssbi pmic writes.
>

According to msm-3.4 all three are controlled by pm8xxx-regulator, but
they are also exposed through the RPM - which I think I tested (a year
ago or so).

Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/8] Add proper support for Compulab CM-A510/SBC-A510

[Sebastian Hesselbarth]

On 26.02.2015 21:01, Stephen Warren wrote:

On 02/26/2015 12:39 PM, Sebastian Hesselbarth wrote:

On 26.02.2015 18:55, Gregory CLEMENT wrote:

On 17/02/2015 19:52, Sebastian Hesselbarth wrote:

This patch set improves current mainline support for the Compulab
CM-A510 System-on-Module (SoM) and its default Compulab SBC-A510
base board. Thanks to Gabriel Dobato who agreed to remote debug and
test the provided DT changes.

[...]

Sebastian Hesselbarth (8):
   i2c: mux-pinctrl: Rework to honor disabled child nodes
   devicetree: vendor-prefixes: Add CompuLab to known vendors
   ARM: dts: dove: Fix uart[23] reg property
   ARM: dts: dove: Always include gpio and interrupt-controller headers
   ARM: dts: dove: Add node labels for PCIe ports 0 and 1
   ARM: dts: dove: Add some more common pinctrl settings
   ARM: dts: dove: Add internal i2c multiplexer node
   ARM: dts: dove: Add proper support for Compulab CM-A510/SBC-A510


Patches 3 to 6 applied on mvebu/dt

If I understood well patches 7 and 8 depend on patch 1 which had not
been
taken yet.


Correct. Once I get a Tested-by from Stephen, I'll resend the 4
remaining patches.


Me? For which patch? I thought there was going to be a v2 of the i2c mux
driver patch given the comments on it, but perhaps I'm misremembering?


AFAIKS, your concerns were addressed to the wording of the binding doc
changes. You don't need that ones to be taken care of before you can
give the i2c-mux-pinctrl driver a functional test, do you? ;)

FWIW, it would be great if you can give patch 1 a test run on one of
the tegra boards using i2c-mux-pinctrl. I'll address the wording
comments if there is no issues with the driver changes.

Sebastian

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 03/11] drm: add driver for simple vga encoders

[Rob Herring]

On Sat, Jan 31, 2015 at 10:32 AM, Heiko Stuebner  wrote:
> There exist simple vga encoders without any type of management interface
> and just maybe a simple gpio for turning it on or off. Examples for these
> are the Analog Devices ADV7123, Chipsea CS7123 or Micronas SDA7123.
>
> Add a generic encoder driver for those that can be used by drm drivers
> using the component framework.

What makes this specific to VGA other than DRM_MODE_CONNECTOR_VGA?
Seems like with match data you could generalize this to any simple
encoder chip.

Rob

>
> Signed-off-by: Heiko Stuebner 
> ---
>  drivers/gpu/drm/i2c/Kconfig  |   6 +
>  drivers/gpu/drm/i2c/Makefile |   2 +
>  drivers/gpu/drm/i2c/vga-simple.c | 325 
> +++
>  3 files changed, 333 insertions(+)
>  create mode 100644 drivers/gpu/drm/i2c/vga-simple.c
>
> diff --git a/drivers/gpu/drm/i2c/Kconfig b/drivers/gpu/drm/i2c/Kconfig
> index 22c7ed6..319f2cb 100644
> --- a/drivers/gpu/drm/i2c/Kconfig
> +++ b/drivers/gpu/drm/i2c/Kconfig
> @@ -31,4 +31,10 @@ config DRM_I2C_NXP_TDA998X
> help
>   Support for NXP Semiconductors TDA998X HDMI encoders.
>
> +config DRM_VGA_SIMPLE
> +   tristate "Generic simple vga encoder"
> +   help
> + Support for vga encoder chips without any special settings
> + and at most a power-control gpio.
> +
>  endmenu
> diff --git a/drivers/gpu/drm/i2c/Makefile b/drivers/gpu/drm/i2c/Makefile
> index 2c72eb5..858961f 100644
> --- a/drivers/gpu/drm/i2c/Makefile
> +++ b/drivers/gpu/drm/i2c/Makefile
> @@ -10,3 +10,5 @@ obj-$(CONFIG_DRM_I2C_SIL164) += sil164.o
>
>  tda998x-y := tda998x_drv.o
>  obj-$(CONFIG_DRM_I2C_NXP_TDA998X) += tda998x.o
> +
> +obj-$(CONFIG_DRM_VGA_SIMPLE) += vga-simple.o
> diff --git a/drivers/gpu/drm/i2c/vga-simple.c 
> b/drivers/gpu/drm/i2c/vga-simple.c
> new file mode 100644
> index 000..bb9d19c
> --- /dev/null
> +++ b/drivers/gpu/drm/i2c/vga-simple.c
> @@ -0,0 +1,325 @@
> +/*
> + * Simple vga encoder driver
> + *
> + * Copyright (C) 2014 Heiko Stuebner 
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * 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 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define connector_to_vga_simple(x) container_of(x, struct vga_simple, 
> connector)
> +#define encoder_to_vga_simple(x) container_of(x, struct vga_simple, encoder)
> +
> +struct vga_simple {
> +   struct drm_connector connector;
> +   struct drm_encoder encoder;
> +
> +   struct device *dev;
> +   struct i2c_adapter *ddc;
> +
> +   struct regulator *vaa_reg;
> +   struct gpio_desc *enable_gpio;
> +
> +   struct mutex enable_lock;
> +   bool enabled;
> +};
> +
> +/*
> + * Connector functions
> + */
> +
> +enum drm_connector_status vga_simple_detect(struct drm_connector *connector,
> +   bool force)
> +{
> +   struct vga_simple *vga = connector_to_vga_simple(connector);
> +
> +   if (!vga->ddc)
> +   return connector_status_unknown;
> +
> +   if (drm_probe_ddc(vga->ddc))
> +   return connector_status_connected;
> +
> +   return connector_status_disconnected;
> +}
> +
> +void vga_simple_connector_destroy(struct drm_connector *connector)
> +{
> +   drm_connector_unregister(connector);
> +   drm_connector_cleanup(connector);
> +}
> +
> +struct drm_connector_funcs vga_simple_connector_funcs = {
> +   .dpms = drm_helper_connector_dpms,
> +   .fill_modes = drm_helper_probe_single_connector_modes,
> +   .detect = vga_simple_detect,
> +   .destroy = vga_simple_connector_destroy,
> +};
> +
> +/*
> + * Connector helper functions
> + */
> +
> +static int vga_simple_connector_get_modes(struct drm_connector *connector)
> +{
> +   struct vga_simple *vga = connector_to_vga_simple(connector);
> +   struct edid *edid;
> +   int ret = 0;
> +
> +   if (!vga->ddc)
> +   return 0;
> +
> +   edid = drm_get_edid(connector, vga->ddc);
> +   if (edid) {
> +   drm_mode_connector_update_edid_property(connector, edid);
> +   ret = drm_add_edid_modes(connector, edid);
> +   kfree(edid);
> +   }
> +
> +   return ret;
> +}
> +
> +static int vga_simple_connector_mode_valid(struct drm_connector *connector,
> +   struct drm_display_mode *mode)
> +{
> +   return MODE_OK;
> +}
> +
> +static struct drm_encoder
> +*vga_simple_connector_best_encoder(st

Re: [PATCH 01/12] ARM: dts: apq8064: add RPM regulators support

[Srinivas Kandagatla]

On 26/02/15 19:00, Bjorn Andersson wrote:

On Sun, Feb 22, 2015 at 11:54 PM, Srinivas Kandagatla
 wrote:

This patch adds rpm node to apq8064 dt as rpm would be used by other
devices for regulator support. Also adds all the regulators in the rpm.



This looks good, with Kumars suggestion of GIT defines
Reviewed-by: Bjorn Andersson 


Thanks Bjorn for Review.


However, this binding is not merged yet and Stephen have requesting a
complete redesign of the binding as well as the code. So that has to
be concluded first, I presume.

Hmm, I know, It does not make sense to keep these patches locally 
waiting for something to change in future, Am not sure when those new 
changes be actually merged into the mainline?


IMHO, we should merge this patches as they are perfectly applicable to 
whats on linus-tree. And fix if required when the new design is accepted.




Separate of that, as it's highly likely that everyone will follow the
pcb design guidelines for apq8064 the vin-supplies should be okay to
specify at this level (and not in all board files). Perhaps also the
switching frequencies for the SMPSs?


I will investigate on this and see If I can add some more useful 
contents to the nodes.


Thanks,
srini


Regards,
Bjorn


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/2] hwrng: iproc-rng200 - Add Broadcom IPROC RNG driver

[Arnd Bergmann]

On Thursday 26 February 2015 11:37:20 Scott Branden wrote:
> Response inline.
> 
> On 15-02-25 11:17 AM, Arnd Bergmann wrote:
> > On Wednesday 25 February 2015 10:16:24 Scott Branden wrote:
> >> This adds a driver for random number generator present on Broadcom
> >> IPROC devices.
> >>
> >> Reviewed-by: Ray Jui 
> >> Signed-off-by: Scott Branden 
> >
> > The driver looks reasonable overall, I have just one question about
> > something that sticks out:
> >
> >> +while ((num_remaining > 0) && time_before(jiffies, idle_endtime)) {
> > ...
> >> +
> >> +/* Are there any random numbers available? */
> >> +if ((ioread32(rng_base + RNG_FIFO_COUNT_OFFSET) &
> >> +RNG_FIFO_COUNT_RNG_FIFO_COUNT_MASK) > 0) {
> > ...
> >> +} else {
> >> +if (!wait)
> >> +/* Cannot wait, return immediately */
> >> +return max - num_remaining;
> >> +
> >> +/* Can wait, give others chance to run */
> >> +cpu_relax();
> >> +}
> >> +}
> >> +
> >
> > It looks like you do a busy-loop around cpu_relax here if asked to wait.
> > Is this intentional? I would normally expect either cond_resched() or
> > some msleep() instead.
> 
> This code was following examples of other open source drivers - bcm2835 
> and exynos both use cpu_relax.  I'll have to look into this more to 
> understand.
> 

The majority of the driver apparently use udelay(10) to wait, which is
not much better but at least consistent. The cpu_relax() call probably
gives better throughput.

I don't understand why none of the drivers actually attempts to
msleep(), but that may be because the delay is much too long.

Can you find out what the expected latency is for new data to
become available on your hardware?

Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 01/12] ARM: dts: apq8064: add RPM regulators support

[Stephen Boyd]

On 02/26/15 12:09, Srinivas Kandagatla wrote:
>
>
> On 26/02/15 19:31, Stephen Boyd wrote:
>> On 02/22/15 23:54, Srinivas Kandagatla wrote:
>>> +pm8921_s5: pm8921-s5 {
>>> +compatible= "qcom,rpm-pm8921-ftsmps";
>>> +reg= ;
>>> +};
>>> +
>>> +pm8921_s6: pm8921-s6 {
>>> +compatible= "qcom,rpm-pm8921-ftsmps";
>>> +reg= ;
>>> +};
>>> +
>>
>> There's no RPM control for S5 and S6. Please remove. Also, has this been
>> tested?
>>
> Ahh. these are SAW regulators, I will remove it from the list.
> Obviously, I did not test all the regulators.

There are some more that don't seem to match what we have downstream.
L26 is also SAW related, and the usb and hdmi switches are "locally"
controlled via ssbi pmic writes.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/8] Add proper support for Compulab CM-A510/SBC-A510

[Stephen Warren]

On 02/26/2015 12:39 PM, Sebastian Hesselbarth wrote:

On 26.02.2015 18:55, Gregory CLEMENT wrote:

On 17/02/2015 19:52, Sebastian Hesselbarth wrote:

This patch set improves current mainline support for the Compulab
CM-A510 System-on-Module (SoM) and its default Compulab SBC-A510
base board. Thanks to Gabriel Dobato who agreed to remote debug and
test the provided DT changes.

[...]

Sebastian Hesselbarth (8):
   i2c: mux-pinctrl: Rework to honor disabled child nodes
   devicetree: vendor-prefixes: Add CompuLab to known vendors
   ARM: dts: dove: Fix uart[23] reg property
   ARM: dts: dove: Always include gpio and interrupt-controller headers
   ARM: dts: dove: Add node labels for PCIe ports 0 and 1
   ARM: dts: dove: Add some more common pinctrl settings
   ARM: dts: dove: Add internal i2c multiplexer node
   ARM: dts: dove: Add proper support for Compulab CM-A510/SBC-A510


Patches 3 to 6 applied on mvebu/dt

If I understood well patches 7 and 8 depend on patch 1 which had not been
taken yet.


Correct. Once I get a Tested-by from Stephen, I'll resend the 4
remaining patches.


Me? For which patch? I thought there was going to be a v2 of the i2c mux 
driver patch given the comments on it, but perhaps I'm misremembering?

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 01/12] ARM: dts: apq8064: add RPM regulators support

[Srinivas Kandagatla]

On 26/02/15 19:31, Stephen Boyd wrote:

On 02/22/15 23:54, Srinivas Kandagatla wrote:

+   pm8921_s5: pm8921-s5 {
+   compatible  = "qcom,rpm-pm8921-ftsmps";
+   reg = ;
+   };
+
+   pm8921_s6: pm8921-s6 {
+   compatible  = "qcom,rpm-pm8921-ftsmps";
+   reg = ;
+   };
+


There's no RPM control for S5 and S6. Please remove. Also, has this been
tested?


Ahh. these are SAW regulators, I will remove it from the list.
Obviously, I did not test all the regulators.

--srini
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH_V3 1/3] dt-bindings: dma: Add binding for jz4780-dma

[Alex Smith]

Hi Zubair,

On 26 February 2015 at 12:43, Zubair Lutfullah Kakakhel
 wrote:
> From: Alex Smith 
>
> Add device tree bindings for the DMA controller on JZ4780 SoCs, used by
> the dma-jz4780 driver.
>
> Signed-off-by: Alex Smith 
> Signed-off-by: Zubair Lutfullah Kakakhel 
>
> ---
> V3 -> V2
> Changed binding.
> Used to be 3 DMA cells required. <&dma TX_type RX_type Reserved>
> Now 2 DMA cells are required. <&dma Transfer_type Reserved>
>
> This is more common in DMA bindings.
> And I couldn't figure any reason that 3 cells were used.

There are different request type numbers for transfers to/from the
same device (see the JZ4780 programmers manual, page 505). While only
having the option to specify one transfer type is OK when the driver
is using separate channels for read/writes, I recall seeing/writing
some other drivers which use a single channel for both reads and
writes. This would not be possible if we can only specify one transfer
type, you'd have to have them separate.

Thanks,
Alex

>
> V1 -> V2 None
> ---
>  .../devicetree/bindings/dma/jz4780-dma.txt | 56 
> ++
>  1 file changed, 56 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/dma/jz4780-dma.txt
>
> diff --git a/Documentation/devicetree/bindings/dma/jz4780-dma.txt 
> b/Documentation/devicetree/bindings/dma/jz4780-dma.txt
> new file mode 100644
> index 000..f25feee
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dma/jz4780-dma.txt
> @@ -0,0 +1,56 @@
> +* Ingenic JZ4780 DMA Controller
> +
> +Required properties:
> +
> +- compatible: Should be "ingenic,jz4780-dma"
> +- reg: Should contain the DMA controller registers location and length.
> +- interrupts: Should contain the interrupt specifier of the DMA controller.
> +- interrupt-parent: Should be the phandle of the interrupt controller that
> +- clocks: Should contain a clock specifier for the JZ4780 PDMA clock.
> +- #dma-cells: Must be <2>. Number of integer cells in the dmas property of
> +  DMA clients (see below).
> +
> +Optional properties:
> +
> +- ingenic,reserved-channels: Bitmask of channels to reserve for devices that
> +  need a specific channel. These channels will only be assigned when 
> explicitly
> +  requested by a client. The primary use for this is channels 0 and 1, which
> +  can be configured to have special behaviour for NAND/BCH when using
> +  programmable firmware.
> +
> +Example:
> +
> +dma: dma@1342 {
> +   compatible = "ingenic,jz4780-dma";
> +   reg = <0x1342 0x1>;
> +
> +   interrupt-parent = <&intc>;
> +   interrupts = <10>;
> +
> +   clocks = <&cgu JZ4780_CLK_PDMA>;
> +
> +   #dma-cells = <2>;
> +
> +   ingenic,reserved-channels = <0x3>;
> +};
> +
> +DMA clients must use the format described in dma.txt, giving a phandle to the
> +DMA controller plus the following 2 integer cells:
> +
> +1. Request type: The DMA request type for transfers to/from the device on
> +   the allocated channel, as defined in the SoC documentation.
> +
> +2. Channel: If set to 0x, any available channel will be allocated for
> +   the client. Otherwise, the exact channel specified will be used. The 
> channel
> +   should be reserved on the DMA controller using the 
> ingenic,reserved-channels
> +   property.
> +
> +Example:
> +
> +uart0: serial@1003 {
> +   ...
> +   dmas = <&dma 0x14 0x
> +   &dma 0x15 0x>;
> +   dma-names = "tx", "rx";
> +   ...
> +};
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] soc: ti: Add wkup_m3_ipc driver

[Dave Gerlach]

Tony,
On 01/05/2015 04:51 PM, Tony Lindgren wrote:
> * Dave Gerlach  [150105 14:51]:
>> Felipe,
>> On 01/02/2015 02:16 PM, Felipe Balbi wrote:
>>> On Fri, Jan 02, 2015 at 02:00:16PM -0600, Dave Gerlach wrote:
 Introduce a wkup_m3_ipc driver to handle communication between the MPU
 and Cortex M3 wkup_m3 present on am335x.

 This driver is responsible for actually booting the wkup_m3_rproc and
 also handling all IPC which is done using the IPC registers in the control
 module, a mailbox, and a separate interrupt back from the wkup_m3. A small
 API is exposed for executing specific power commands, which include
 configuring for low power mode, request a transition to a low power mode,
 and status info on a previous transition.

 Signed-off-by: Dave Gerlach 
 ---
  drivers/soc/ti/Kconfig   |  11 ++
  drivers/soc/ti/Makefile  |   1 +
  drivers/soc/ti/wkup_m3_ipc.c | 451 
 +++
  include/linux/wkup_m3_ipc.h  |  33 
  4 files changed, 496 insertions(+)
  create mode 100644 drivers/soc/ti/wkup_m3_ipc.c
  create mode 100644 include/linux/wkup_m3_ipc.h

 diff --git a/drivers/soc/ti/Kconfig b/drivers/soc/ti/Kconfig
 index 7266b21..61cda85 100644
 --- a/drivers/soc/ti/Kconfig
 +++ b/drivers/soc/ti/Kconfig
 @@ -28,4 +28,15 @@ config KEYSTONE_NAVIGATOR_DMA
  
  If unsure, say N.
  
 +config WKUP_M3_IPC
 +  bool "TI AM33XX Wkup-M3 IPC Driver"
>>>
>>> tristate ?
>>
>> If we want to allow this and the rproc driver to be built as modules than we 
>> can
>> change this.
> 
> Yes please, the PM is never needed early, and should be optional.
> And doing that will make it a lot easier for you to do further work
> on your driver ;)
> 
> And it will also make it easier to add support for other SoCs as
> it seems the same M3 is used at least on am437x.
>  

I can not build the PM code as a module at this time due to many mach-omap
function calls it uses which are not exported, so I need handles to all five
functions in this driver used in pm33xx to call from built-in PM code. Do you
have a preference on how these function handles get passed?

I currently have added a pdata-quirks implementation that passes a function to
the wkup_m3_ipc driver through it's pdata which it then calls at probe to pass a
struct containing all used function pointers to the pm code that were previously
called directly. Is that what you would prefer or something else? I had also
looked at making the struct of function pointers in the driver global and just
picking it up from the pm code with an extern declaration or even putting a bus
notifier in the PM code and watching for the wkup_m3_ipc driver to be bound.

Thought I would see what you prefer and possibly avoid an unnecessary re-spin.

Regards,
Dave

>>>
 +  depends on WKUP_M3_RPROC
 +  select MAILBOX
 +  select OMAP2PLUS_MBOX
>>>
>>> selects are usually frowned upon.
>>
>> Followed example set by OMAP_REMOTEPROC which selects the mailbox, thought 
>> that
>> would be alright.
> 
> The select should be only done if the option selected is a silen
> Kconfig option where it's never selectable by the user. Otherwise
> you will errors sooner or later with make randconfig builds as the
> dependencies change. Using depends on is better for those cases.
> 
> Regards,
> 
> Tony 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/8] Add proper support for Compulab CM-A510/SBC-A510

[Sebastian Hesselbarth]

On 26.02.2015 18:55, Gregory CLEMENT wrote:

On 17/02/2015 19:52, Sebastian Hesselbarth wrote:

This patch set improves current mainline support for the Compulab
CM-A510 System-on-Module (SoM) and its default Compulab SBC-A510
base board. Thanks to Gabriel Dobato who agreed to remote debug and
test the provided DT changes.

[...]

Sebastian Hesselbarth (8):
   i2c: mux-pinctrl: Rework to honor disabled child nodes
   devicetree: vendor-prefixes: Add CompuLab to known vendors
   ARM: dts: dove: Fix uart[23] reg property
   ARM: dts: dove: Always include gpio and interrupt-controller headers
   ARM: dts: dove: Add node labels for PCIe ports 0 and 1
   ARM: dts: dove: Add some more common pinctrl settings
   ARM: dts: dove: Add internal i2c multiplexer node
   ARM: dts: dove: Add proper support for Compulab CM-A510/SBC-A510


Patches 3 to 6 applied on mvebu/dt

If I understood well patches 7 and 8 depend on patch 1 which had not been
taken yet.


Correct. Once I get a Tested-by from Stephen, I'll resend the 4
remaining patches.

Thanks,
  Sebastian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/2] hwrng: iproc-rng200 - Add Broadcom IPROC RNG driver

[Scott Branden]

Response inline.

On 15-02-25 11:17 AM, Arnd Bergmann wrote:

On Wednesday 25 February 2015 10:16:24 Scott Branden wrote:

This adds a driver for random number generator present on Broadcom
IPROC devices.

Reviewed-by: Ray Jui 
Signed-off-by: Scott Branden 


The driver looks reasonable overall, I have just one question about
something that sticks out:


+   while ((num_remaining > 0) && time_before(jiffies, idle_endtime)) {

...

+
+   /* Are there any random numbers available? */
+   if ((ioread32(rng_base + RNG_FIFO_COUNT_OFFSET) &
+   RNG_FIFO_COUNT_RNG_FIFO_COUNT_MASK) > 0) {

...

+   } else {
+   if (!wait)
+   /* Cannot wait, return immediately */
+   return max - num_remaining;
+
+   /* Can wait, give others chance to run */
+   cpu_relax();
+   }
+   }
+


It looks like you do a busy-loop around cpu_relax here if asked to wait.
Is this intentional? I would normally expect either cond_resched() or
some msleep() instead.


This code was following examples of other open source drivers - bcm2835 
and exynos both use cpu_relax.  I'll have to look into this more to 
understand.




Arnd



--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 01/12] ARM: dts: apq8064: add RPM regulators support

[Stephen Boyd]

On 02/22/15 23:54, Srinivas Kandagatla wrote:
> + pm8921_s5: pm8921-s5 {
> + compatible  = "qcom,rpm-pm8921-ftsmps";
> + reg = ;
> + };
> +
> + pm8921_s6: pm8921-s6 {
> + compatible  = "qcom,rpm-pm8921-ftsmps";
> + reg = ;
> + };
> +

There's no RPM control for S5 and S6. Please remove. Also, has this been
tested?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: kexec: Relax SMP validation to improve DT compatibility

[Geert Uytterhoeven]

On Thu, Feb 26, 2015 at 8:00 PM, Stephen Warren  wrote:
> On 02/26/2015 10:42 AM, Russell King - ARM Linux wrote:
>>
>> On Thu, Feb 26, 2015 at 11:37:08AM +0100, Geert Uytterhoeven wrote:
>>>
>>> When trying to kexec into a new kernel on a platform where multiple CPU
>>> cores are present, but no SMP bringup code is available yet, the
>>> kexec_load system call fails with:
>>>
>>>  kexec_load failed: Invalid argument
>>>
>>> The SMP test added to machine_kexec_prepare() in commit 2103f6cba61a8b8b
>>> ("ARM: 7807/1: kexec: validate CPU hotplug support") wants to prohibit
>>> kexec on SMP platforms where it cannot disable secondary CPUs.
>>> However, this test is too strict: if the secondary CPUs couldn't be
>>> enabled in the first place, there's no need to disable them later at
>>> kexec time.  Hence skip the test in the absence of SMP bringup code.
>>
>>
>> Hmm.  I don't think we should relax it in this manner - I think there's
>> an easier solution to this.
>>
>>> diff --git a/arch/arm/kernel/machine_kexec.c
>>> b/arch/arm/kernel/machine_kexec.c
>>> index de2b085ad7535da7..8bf3b7c098881b95 100644
>>> --- a/arch/arm/kernel/machine_kexec.c
>>> +++ b/arch/arm/kernel/machine_kexec.c
>>> @@ -46,7 +46,8 @@ int machine_kexec_prepare(struct kimage *image)
>>>  * and implements CPU hotplug for the current HW. If not, we
>>> won't be
>>>  * able to kexec reliably, so fail the prepare operation.
>>>  */
>>> -   if (num_possible_cpus() > 1 && !platform_can_cpu_hotplug())
>>> +   if (num_possible_cpus() > 1 && platform_can_secondary_boot() &&
>>> +   !platform_can_cpu_hotplug())
>>
>>
>> if (num_online_cpus() > 1 && !platform_can_cpu_hotplug())
>
> I can't remember the call stack here. Is num_online_cpus() guaranteed not to
> change from this point through to when the kexec actually happens?

Yeah, I had similar thoughts when I added the new test.

include/linux/cpumask.h:
 * cpu_possible_mask- has bit 'cpu' set iff cpu is populatable
 * cpu_present_mask - has bit 'cpu' set iff cpu is populated
 * cpu_online_mask  - has bit 'cpu' set iff cpu available to scheduler
 * cpu_active_mask  - has bit 'cpu' set iff cpu available to migration

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC 2/3] power: mxs_power: add driver for mxs power subsystem

[Stefan Wahren]

Hi,

> Sebastian Reichel  hat am 23. Februar 2015 um 16:38
> geschrieben:
>
>
> On Fri, Feb 20, 2015 at 11:57:41AM +0100, Stefan Wahren wrote:
> > > power: power@80044000 {
> > > compatible = "fsl,imx28-power"; /* handled by mxs_power.c */
> > > #address-cells = <1>;
> > > #size-cells = <1>;
> > > reg = <0x80044000 0x2000>;
> > > interrupts = <6>;
> > > switching-frequency = <2400>; /* new property */
> > > ranges;
> > >
> > > reg_vddd: regulator@80044040 {
> > > reg = <0x80044040 0x10>,
> > > <0x80044010 0x10>,
> > > <0x800440c0 0x10>;
> > > reg-names = "base-address",
> > > "v5ctrl-address",
> > > "status-address";
> > > compatible = "fsl,imx28-vddd"; /* handled by mxs-regulator.c */
> > > regulator-name = "vddd";
> > > regulator-min-microvolt = <135>;
> > > regulator-max-microvolt = <155>;
> > > vddd-supply = <®_vdda>;
> > > };
> > >
> > > reg_vdda: regulator@80044050 {
> > > reg = <0x80044050 0x10>,
> > > <0x80044010 0x10>,
> > > <0x800440c0 0x10>;
> > > reg-names = "base-address",
> > > "v5ctrl-address",
> > > "status-address";
> > > compatible = "fsl,imx28-vdda"; /* handled by mxs-regulator.c */
> > > regulator-name = "vdda";
> > > regulator-min-microvolt = <1725000>;
> > > regulator-max-microvolt = <195>;
> > > vdda-supply = <®_vddio>;
> > > };
> > >
> > > reg_vddio: regulator@80044060 {
> > > reg = <0x80044060 0x10>,
> > > <0x80044010 0x10>,
> > > <0x800440c0 0x10>;
> > > reg-names = "base-address",
> > > "v5ctrl-address",
> > > "status-address";
> > > compatible = "fsl,imx28-vddio"; /* handled by mxs-regulator.c */
> > > regulator-name = "vddio";
> > > regulator-min-microvolt = <300>;
> > > regulator-max-microvolt = <3575000>;
> > > regulator-microvolt-offset = <8>;
> > > };
> > > };
> > >
> > > Please correct me if i'm wrong.
> > >
> > > Stefan
> >
> > Gentle Ping.
>
> The binding looks ok to me. It would be nice to get an ACK of a DT
> binding maintainer, though.

any objections about implementing DC-DC switching frequency as a DT property
instead of module parameter?

Stefan
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 01/12] ARM: dts: apq8064: add RPM regulators support

[Bjorn Andersson]

On Thu, Feb 26, 2015 at 11:00 AM, Bjorn Andersson  wrote:
> On Sun, Feb 22, 2015 at 11:54 PM, Srinivas Kandagatla
>  wrote:
>> This patch adds rpm node to apq8064 dt as rpm would be used by other
>> devices for regulator support. Also adds all the regulators in the rpm.
>>
>
> This looks good, with Kumars suggestion of GIT defines

"GIC", stupid manual autocomplete.

Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 01/12] ARM: dts: apq8064: add RPM regulators support

[Bjorn Andersson]

On Thu, Feb 26, 2015 at 10:25 AM, Kumar Gala  wrote:
>
> On Feb 23, 2015, at 1:54 AM, Srinivas Kandagatla 
>  wrote:
>
>> This patch adds rpm node to apq8064 dt as rpm would be used by other
>> devices for regulator support. Also adds all the regulators in the rpm.
>>
>> Signed-off-by: Srinivas Kandagatla 
[..]
>> + interrupts  = <0 19 0>, <0 21 0>, <0 22 0>;
>> + interrupt-names = "ack", "err", "wakeup";
>> +
>
> Can you use the defines for GIC for the interrupts.  Also, I think the last 
> property should probably be level high instead of 0.
>

The code sets it to rising, but better move that to the dt (as you suggest).

Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 01/12] ARM: dts: apq8064: add RPM regulators support

[Bjorn Andersson]

On Sun, Feb 22, 2015 at 11:54 PM, Srinivas Kandagatla
 wrote:
> This patch adds rpm node to apq8064 dt as rpm would be used by other
> devices for regulator support. Also adds all the regulators in the rpm.
>

This looks good, with Kumars suggestion of GIT defines
Reviewed-by: Bjorn Andersson 

However, this binding is not merged yet and Stephen have requesting a
complete redesign of the binding as well as the code. So that has to
be concluded first, I presume.


Separate of that, as it's highly likely that everyone will follow the
pcb design guidelines for apq8064 the vin-supplies should be okay to
specify at this level (and not in all board files). Perhaps also the
switching frequencies for the SMPSs?

Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: kexec: Relax SMP validation to improve DT compatibility

[Stephen Warren]

On 02/26/2015 10:42 AM, Russell King - ARM Linux wrote:

On Thu, Feb 26, 2015 at 11:37:08AM +0100, Geert Uytterhoeven wrote:

When trying to kexec into a new kernel on a platform where multiple CPU
cores are present, but no SMP bringup code is available yet, the
kexec_load system call fails with:

 kexec_load failed: Invalid argument

The SMP test added to machine_kexec_prepare() in commit 2103f6cba61a8b8b
("ARM: 7807/1: kexec: validate CPU hotplug support") wants to prohibit
kexec on SMP platforms where it cannot disable secondary CPUs.
However, this test is too strict: if the secondary CPUs couldn't be
enabled in the first place, there's no need to disable them later at
kexec time.  Hence skip the test in the absence of SMP bringup code.


Hmm.  I don't think we should relax it in this manner - I think there's
an easier solution to this.


diff --git a/arch/arm/kernel/machine_kexec.c b/arch/arm/kernel/machine_kexec.c
index de2b085ad7535da7..8bf3b7c098881b95 100644
--- a/arch/arm/kernel/machine_kexec.c
+++ b/arch/arm/kernel/machine_kexec.c
@@ -46,7 +46,8 @@ int machine_kexec_prepare(struct kimage *image)
 * and implements CPU hotplug for the current HW. If not, we won't be
 * able to kexec reliably, so fail the prepare operation.
 */
-   if (num_possible_cpus() > 1 && !platform_can_cpu_hotplug())
+   if (num_possible_cpus() > 1 && platform_can_secondary_boot() &&
+   !platform_can_cpu_hotplug())


if (num_online_cpus() > 1 && !platform_can_cpu_hotplug())


I can't remember the call stack here. Is num_online_cpus() guaranteed 
not to change from this point through to when the kexec actually happens?





return -EINVAL;


Neither test is actually accurate though: when we have implementations
where the secondary CPUs spin inside the kernel when they're "unplugged"
that is not sufficient to be able to kexec.

We should probably fix that, and make platform_can_cpu_hotplug() report
whether it really is possible to hotplug all secondary CPUs into such
a state that kexec can work.



--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 04/11] dt-bindings: Add documentation for rockchip lvds

[Laurent Pinchart]

Hi Heiko,

Thank you for the patch.

On Saturday 31 January 2015 17:32:57 Heiko Stuebner wrote:
> From: Mark Yao 
> 
> Add binding documentation for Rockchip SoC LVDS driver.
> 
> Signed-off-by: Mark Yao 
> Signed-off-by: Heiko Stuebner 
> ---
>  .../devicetree/bindings/video/rockchip-lvds.txt| 59 +++
>  1 file changed, 59 insertions(+)
>  create mode 100644
> Documentation/devicetree/bindings/video/rockchip-lvds.txt
> 
> diff --git a/Documentation/devicetree/bindings/video/rockchip-lvds.txt
> b/Documentation/devicetree/bindings/video/rockchip-lvds.txt new file mode
> 100644
> index 000..1616d7e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/rockchip-lvds.txt
> @@ -0,0 +1,59 @@
> +Rockchip RK3288 LVDS interface
> +
> +
> +Required properties:
> +- compatible: "rockchip,rk3288-lvds";
> +
> +- reg: physical base address of the controller and length
> + of memory mapped region.
> +- clocks: must include clock specifiers corresponding to entries in the
> + clock-names property.
> +- clock-names: must contain "pclk_lvds"
> +
> +- avdd1v0-supply: regulator phandle for 1.0V analog power
> +- avdd1v8-supply: regulator phandle for 1.8V analog power
> +- avdd3v3-supply: regulator phandle for 3.3V analog power
> +
> +- rockchip,grf: phandle to the general register files syscon
> +- rockchip,panel: phandle to a panel node as described by
> + Documentation/devicetree/bindings/panel/*

Doesn't this duplicate the information provided by the ports ?

> +- rockchip,data-mapping: should be "vesa" or "jeida",
> + This describes how the color bits are laid out in the
> + serialized LVDS signal.
> +- rockchip,data-width : should be <18> or <24>;
> +- rockchip,output: should be "rgb", "lvds" or "duallvds",
> + This describes the output face.

Isn't all this panel-dependent ? Could we query the information from the panel 
at runtime instead ?

> +- ports: contain a port node with endpoint definitions as defined in
> + Documentation/devicetree/bindings/media/video-interfaces.txt.
> +
> +Example:
> + lvds: lvds@ff96c000 {
> + compatible = "rockchip,rk3288-lvds";
> + rockchip,grf = <&grf>;
> + reg = <0xff96c000 0x4000>;
> + clocks = <&cru PCLK_LVDS_PHY>;
> + clock-names = "pclk_lvds";
> + avdd1v0-supply = <&vdd10_lcd>;
> + avdd1v8-supply = <&vcc18_lcd>;
> + avdd3v3-supply = <&vcca_33>;
> + rockchip,panel = <&panel>;
> + rockchip,data-mapping = "jeida";
> + rockchip,data-width = <24>;
> + rockchip,output = "rgb";
> + ports {
> + lvds_in: port {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + lvds_in_vopb: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <&vopb_out_lvds>;
> + };
> + lvds_in_vopl: endpoint@1 {
> + reg = <1>;
> + remote-endpoint = <&vopl_out_lvds>;
> + };
> + };
> + };
> + };

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 03/11] drm: add driver for simple vga encoders

[Laurent Pinchart]

Hi Heiko,

Thank you for the patch.

On Saturday 31 January 2015 17:32:56 Heiko Stuebner wrote:
> There exist simple vga encoders without any type of management interface
> and just maybe a simple gpio for turning it on or off. Examples for these
> are the Analog Devices ADV7123, Chipsea CS7123 or Micronas SDA7123.
> 
> Add a generic encoder driver for those that can be used by drm drivers
> using the component framework.

The rcar-du driver already handles the adi,adv7123 compatible string used by 
this driver. A generic driver is in my opinion a very good idea, but we can't 
break the existing support. Porting the rcar-du driver to the component model 
is needed.

> Signed-off-by: Heiko Stuebner 
> ---
>  drivers/gpu/drm/i2c/Kconfig  |   6 +
>  drivers/gpu/drm/i2c/Makefile |   2 +
>  drivers/gpu/drm/i2c/vga-simple.c | 325 

drivers/gpu/drm/i2c/ feels wrong for a platform device.

>  3 files changed, 333 insertions(+)
>  create mode 100644 drivers/gpu/drm/i2c/vga-simple.c
> 
> diff --git a/drivers/gpu/drm/i2c/Kconfig b/drivers/gpu/drm/i2c/Kconfig
> index 22c7ed6..319f2cb 100644
> --- a/drivers/gpu/drm/i2c/Kconfig
> +++ b/drivers/gpu/drm/i2c/Kconfig
> @@ -31,4 +31,10 @@ config DRM_I2C_NXP_TDA998X
>   help
> Support for NXP Semiconductors TDA998X HDMI encoders.
> 
> +config DRM_VGA_SIMPLE
> + tristate "Generic simple vga encoder"
> + help
> +   Support for vga encoder chips without any special settings
> +   and at most a power-control gpio.
> +
>  endmenu
> diff --git a/drivers/gpu/drm/i2c/Makefile b/drivers/gpu/drm/i2c/Makefile
> index 2c72eb5..858961f 100644
> --- a/drivers/gpu/drm/i2c/Makefile
> +++ b/drivers/gpu/drm/i2c/Makefile
> @@ -10,3 +10,5 @@ obj-$(CONFIG_DRM_I2C_SIL164) += sil164.o
> 
>  tda998x-y := tda998x_drv.o
>  obj-$(CONFIG_DRM_I2C_NXP_TDA998X) += tda998x.o
> +
> +obj-$(CONFIG_DRM_VGA_SIMPLE) += vga-simple.o
> diff --git a/drivers/gpu/drm/i2c/vga-simple.c
> b/drivers/gpu/drm/i2c/vga-simple.c new file mode 100644
> index 000..bb9d19c
> --- /dev/null
> +++ b/drivers/gpu/drm/i2c/vga-simple.c
> @@ -0,0 +1,325 @@
> +/*
> + * Simple vga encoder driver
> + *
> + * Copyright (C) 2014 Heiko Stuebner 
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * 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 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define connector_to_vga_simple(x) container_of(x, struct vga_simple,
> connector) +#define encoder_to_vga_simple(x) container_of(x, struct
> vga_simple, encoder) +
> +struct vga_simple {
> + struct drm_connector connector;
> + struct drm_encoder encoder;
> +
> + struct device *dev;
> + struct i2c_adapter *ddc;
> +
> + struct regulator *vaa_reg;
> + struct gpio_desc *enable_gpio;
> +
> + struct mutex enable_lock;
> + bool enabled;
> +};
> +
> +/*
> + * Connector functions
> + */
> +
> +enum drm_connector_status vga_simple_detect(struct drm_connector
> *connector, + bool force)
> +{
> + struct vga_simple *vga = connector_to_vga_simple(connector);
> +
> + if (!vga->ddc)
> + return connector_status_unknown;
> +
> + if (drm_probe_ddc(vga->ddc))
> + return connector_status_connected;
> +
> + return connector_status_disconnected;
> +}
> +
> +void vga_simple_connector_destroy(struct drm_connector *connector)
> +{
> + drm_connector_unregister(connector);
> + drm_connector_cleanup(connector);
> +}
> +
> +struct drm_connector_funcs vga_simple_connector_funcs = {
> + .dpms = drm_helper_connector_dpms,
> + .fill_modes = drm_helper_probe_single_connector_modes,
> + .detect = vga_simple_detect,
> + .destroy = vga_simple_connector_destroy,
> +};
> +
> +/*
> + * Connector helper functions
> + */
> +
> +static int vga_simple_connector_get_modes(struct drm_connector *connector)
> +{
> + struct vga_simple *vga = connector_to_vga_simple(connector);
> + struct edid *edid;
> + int ret = 0;
> +
> + if (!vga->ddc)
> + return 0;
> +
> + edid = drm_get_edid(connector, vga->ddc);
> + if (edid) {
> + drm_mode_connector_update_edid_property(connector, edid);
> + ret = drm_add_edid_modes(connector, edid);
> + kfree(edid);
> + }
> +
> + return ret;
> +}
> +
> +static int vga_simple_connector_mode_valid(struct drm_connector *connector,
> + struct drm_display_mode *mode)
> +{
> +

Re: [PATCH 00/12] ARM: dts: apq8064 dt patches.

[Srinivas Kandagatla]

On 26/02/15 18:29, Kumar Gala wrote:


On Feb 23, 2015, at 1:53 AM, Srinivas Kandagatla 
 wrote:


Hi Kumar,
Now that the rpm header file dependency is resolved, Could you
queue these dt patches for rc2.


Thanks,
srini

Nicolas Dechesne (3):
  ARM: DT: apq8064: add pci support in CM QS600
  ARM: DT: apq8064: Add usb host support to CM QS-600
  ARM: DT: apq8064: Add USB OTG support for CM QS-600

Pramod Gurav (1):
  ARM: qcom: Add DT alias for serial port

Rob Clark (1):
  ARM: dts: APQ8064: Add MDP support

Srinivas Kandagatla (7):
  ARM: dts: apq8064: add RPM regulators support
  ARM: dts: apq8064: Add usb host support.
  ARM: dts: apq8064: Add USB OTG support
  ARM: dts: apq8064: Add SATA controller support.
  ARM: dts: apq8064: Remove incorrect gsbi2 node.
  ARM: dts: Move i2c1 pinctrl to apq8064.dtsi
  ARM: dts: apq8064 add i2c3 node for panel.

arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts |  49 +++
arch/arm/boot/dts/qcom-apq8064-ifc6410.dts  |  98 +-
arch/arm/boot/dts/qcom-apq8064.dtsi | 499 +++-
3 files changed, 629 insertions(+), 17 deletions(-)


Can you scrub all the patches for interrupt usage such that we use GIC_SPI 
define and I think any IRQ type of 0 or NONE should really be 
IRQ_TYPE_LEVEL_HIGH


Yes, I will fix it.

--srini


- k


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/12] ARM: dts: apq8064 dt patches.

[Kumar Gala]

On Feb 23, 2015, at 1:53 AM, Srinivas Kandagatla 
 wrote:

> Hi Kumar, 
> Now that the rpm header file dependency is resolved, Could you
> queue these dt patches for rc2.
> 
> 
> Thanks,
> srini
> 
> Nicolas Dechesne (3):
>  ARM: DT: apq8064: add pci support in CM QS600
>  ARM: DT: apq8064: Add usb host support to CM QS-600
>  ARM: DT: apq8064: Add USB OTG support for CM QS-600
> 
> Pramod Gurav (1):
>  ARM: qcom: Add DT alias for serial port
> 
> Rob Clark (1):
>  ARM: dts: APQ8064: Add MDP support
> 
> Srinivas Kandagatla (7):
>  ARM: dts: apq8064: add RPM regulators support
>  ARM: dts: apq8064: Add usb host support.
>  ARM: dts: apq8064: Add USB OTG support
>  ARM: dts: apq8064: Add SATA controller support.
>  ARM: dts: apq8064: Remove incorrect gsbi2 node.
>  ARM: dts: Move i2c1 pinctrl to apq8064.dtsi
>  ARM: dts: apq8064 add i2c3 node for panel.
> 
> arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts |  49 +++
> arch/arm/boot/dts/qcom-apq8064-ifc6410.dts  |  98 +-
> arch/arm/boot/dts/qcom-apq8064.dtsi | 499 +++-
> 3 files changed, 629 insertions(+), 17 deletions(-)

Can you scrub all the patches for interrupt usage such that we use GIC_SPI 
define and I think any IRQ type of 0 or NONE should really be 
IRQ_TYPE_LEVEL_HIGH

- k

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 03/12] ARM: dts: apq8064: Add USB OTG support

[Kumar Gala]

On Feb 23, 2015, at 1:55 AM, Srinivas Kandagatla 
 wrote:

> This patch adds USB OTG support on USB1 of APQ8064 SOC.
> Tested on IFC6410 with ethernet gadget.
> 
> Signed-off-by: Srinivas Kandagatla 
> ---
> arch/arm/boot/dts/qcom-apq8064-ifc6410.dts | 22 
> arch/arm/boot/dts/qcom-apq8064.dtsi| 32 ++
> 2 files changed, 54 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts 
> b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
> index 40657a4..1723cdf 100644
> --- a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
> +++ b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
> @@ -61,12 +61,25 @@
>   regulator-max-microvolt = <330>;
>   };
> 
> + pm8921_l4: pm8921-l4 {
> + regulator-min-microvolt = <100>;
> + regulator-max-microvolt = <180>;
> + };
> +
>   pm8921_l23: pm8921-l23 {
>   regulator-min-microvolt = <170>;
>   regulator-max-microvolt = <190>;
>   };
>   };
> 
> + /* OTG */
> + usb1_phy: phy@1250 {
> + status  = "okay";
> + vddcx-supply= <&pm8921_s3>;
> + v3p3-supply = <&pm8921_l3>;
> + v1p8-supply = <&pm8921_l4>;
> + };
> +
>   usb3_phy: phy@1252 {
>   status  = "okay";
>   vddcx-supply= <&pm8921_s3>;
> @@ -81,6 +94,15 @@
>   v1p8-supply = <&pm8921_l23>;
>   };
> 
> + gadget1: gadget@1250 {
> + status = "okay";
> + };
> +
> + /* OTG */
> + usb1: usb@1250 {
> + status = "okay";
> + };
> +
>   usb3: usb@1252 {
>   status = "okay";
>   };
> diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi 
> b/arch/arm/boot/dts/qcom-apq8064.dtsi
> index e33eb03..c251c72 100644
> --- a/arch/arm/boot/dts/qcom-apq8064.dtsi
> +++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
> @@ -488,6 +488,21 @@
>   };
>   };
> 
> + usb1_phy: phy@1250 {
> + compatible  = "qcom,usb-otg-ci";
> + reg = <0x1250 0x400>;
> + interrupts  = <0 100 IRQ_TYPE_NONE>;

Same comments about 0 -> GIC_SPI, and IRQ_TYPE_NONE -> IRQ_TYPE_LEVEL_HIGH

> + status  = "disabled";
> + dr_mode = "host";
> +
> + clocks  = <&gcc USB_HS1_XCVR_CLK>,
> +   <&gcc USB_HS1_H_CLK>;
> + clock-names = "core", "iface";
> +
> + resets  = <&gcc USB_HS1_RESET>;
> + reset-names = "link";
> + };
> +
>   usb3_phy: phy@1252 {
>   compatible  = "qcom,usb-otg-ci";
>   reg = <0x1252 0x400>;
> @@ -518,6 +533,23 @@
>   reset-names = "link";
>   };
> 
> + gadget1: gadget@1250 {
> + compatible  = "qcom,ci-hdrc";
> + reg = <0x1250 0x400>;
> + status  = "disabled";
> + dr_mode = "peripheral";
> + interrupts  = <0 100 IRQ_TYPE_NONE>;
> + usb-phy = <&usb1_phy>;
> + };
> +
> + usb1: usb@1250 {
> + compatible  = "qcom,ehci-host";
> + reg = <0x1250 0x400>;
> + interrupts  = <0 100 IRQ_TYPE_NONE>;
> + status  = "disabled";
> + usb-phy = <&usb1_phy>;
> + };
> +
>   usb3: usb@1252 {
>   compatible  = "qcom,ehci-host";
>   reg = <0x1252 0x400>;
> -- 
> 1.9.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 02/12] ARM: dts: apq8064: Add usb host support.

[Kumar Gala]

On Feb 23, 2015, at 1:55 AM, Srinivas Kandagatla 
 wrote:

> This patch adds device tree nodes to support two usb hosts on APQ8064
> SOC.
> 
> Signed-off-by: Srinivas Kandagatla 
> ---
> arch/arm/boot/dts/qcom-apq8064-ifc6410.dts | 40 +
> arch/arm/boot/dts/qcom-apq8064.dtsi| 47 ++
> 2 files changed, 87 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts 
> b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
> index e641001..40657a4 100644
> --- a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
> +++ b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
> @@ -49,6 +49,46 @@
>   };
>   };
> 
> + rpm@108000 {
> + pm8921_s3: pm8921-s3 {
> + regulator-min-microvolt = <100>;
> + regulator-max-microvolt = <140>;
> + qcom,switch-mode-frequency  = <480>;
> + };
> +
> + pm8921_l3: pm8921-l3 {
> + regulator-min-microvolt = <305>;
> + regulator-max-microvolt = <330>;
> + };
> +
> + pm8921_l23: pm8921-l23 {
> + regulator-min-microvolt = <170>;
> + regulator-max-microvolt = <190>;
> + };
> + };
> +
> + usb3_phy: phy@1252 {
> + status  = "okay";
> + vddcx-supply= <&pm8921_s3>;
> + v3p3-supply = <&pm8921_l3>;
> + v1p8-supply = <&pm8921_l23>;
> + };
> +
> + usb4_phy: phy@1253 {
> + status  = "okay";
> + vddcx-supply= <&pm8921_s3>;
> + v3p3-supply = <&pm8921_l3>;
> + v1p8-supply = <&pm8921_l23>;
> + };
> +
> + usb3: usb@1252 {
> + status = "okay";
> + };
> +
> + usb4: usb@1253 {
> + status = "okay";
> + };
> +
>   amba {
>   /* eMMC */
>   sdcc1: sdcc@1240 {
> diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi 
> b/arch/arm/boot/dts/qcom-apq8064.dtsi
> index db5fc59..e33eb03 100644
> --- a/arch/arm/boot/dts/qcom-apq8064.dtsi
> +++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
> @@ -2,6 +2,7 @@
> 
> #include "skeleton.dtsi"
> #include 
> +#include 
> #include 
> #include 
> #include 
> @@ -487,6 +488,52 @@
>   };
>   };
> 
> + usb3_phy: phy@1252 {
> + compatible  = "qcom,usb-otg-ci";
> + reg = <0x1252 0x400>;
> + interrupts  = <0 188 IRQ_TYPE_NONE>;

I think the IRQ_TYPE should be IRQ_TYPE_LEVEL_HIGH (same for all other 
interrupts)

Also can we use GIC_SPI

> + status  = "disabled";
> + dr_mode = "host";
> +
> + clocks  = <&gcc USB_HS3_XCVR_CLK>,
> +   <&gcc USB_HS3_H_CLK>;
> + clock-names = "core", "iface";
> +
> + resets  = <&gcc USB_HS3_RESET>;
> + reset-names = "link";
> + };
> +
> + usb4_phy: phy@1253 {
> + compatible  = "qcom,usb-otg-ci";
> + reg = <0x1253 0x400>;
> + interrupts  = <0 215 IRQ_TYPE_NONE>;
> + status  = "disabled";
> + dr_mode = "host";
> +
> + clocks  = <&gcc USB_HS4_XCVR_CLK>,
> +   <&gcc USB_HS4_H_CLK>;
> + clock-names = "core", "iface";
> +
> + resets  = <&gcc USB_HS4_RESET>;
> + reset-names = "link";
> + };
> +
> + usb3: usb@1252 {
> + compatible  = "qcom,ehci-host";
> + reg = <0x1252 0x400>;
> + interrupts  = <0 188 IRQ_TYPE_NONE>;
> + status  = "disabled";
> + usb-phy = <&usb3_phy>;
> + };
> +
> + usb4: usb@1253 {
> + compatible  = "qcom,ehci-host";
> + reg = <0x1253 0x400>;
> + interrupts  = <0 215 IRQ_TYPE_NONE>;
> + status  = "disabled";
> + usb-phy = <&usb4_phy>;
> + };
> +
>   /* Temporary fixed regulator */
>   vsdcc_fixed: vsdcc-regulato

Re: [PATCH 01/12] ARM: dts: apq8064: add RPM regulators support

[Kumar Gala]

On Feb 23, 2015, at 1:54 AM, Srinivas Kandagatla 
 wrote:

> This patch adds rpm node to apq8064 dt as rpm would be used by other
> devices for regulator support. Also adds all the regulators in the rpm.
> 
> Signed-off-by: Srinivas Kandagatla 
> ---
> arch/arm/boot/dts/qcom-apq8064.dtsi | 241 
> 1 file changed, 241 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi 
> b/arch/arm/boot/dts/qcom-apq8064.dtsi
> index b3154c0..db5fc59 100644
> --- a/arch/arm/boot/dts/qcom-apq8064.dtsi
> +++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
> @@ -3,6 +3,7 @@
> #include "skeleton.dtsi"
> #include 
> #include 
> +#include 
> #include 
> #include 
> 
> @@ -246,6 +247,246 @@
>   #reset-cells = <1>;
>   };
> 
> + l2cc: clock-controller@2011000 {
> + compatible  = "syscon";
> + reg = <0x2011000 0x1000>;
> + };
> +
> + rpm@108000 {
> + compatible  = "qcom,rpm-apq8064";
> + reg = <0x108000 0x1000>;
> + qcom,ipc= <&l2cc 0x8 2>;
> +
> + interrupts  = <0 19 0>, <0 21 0>, <0 22 0>;
> + interrupt-names = "ack", "err", "wakeup";
> +

Can you use the defines for GIC for the interrupts.  Also, I think the last 
property should probably be level high instead of 0.

- k
-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 01/12] ARM: dts: apq8064: add RPM regulators support

[Srinivas Kandagatla]

On 26/02/15 18:25, Kumar Gala wrote:


On Feb 23, 2015, at 1:54 AM, Srinivas Kandagatla 
 wrote:


This patch adds rpm node to apq8064 dt as rpm would be used by other
devices for regulator support. Also adds all the regulators in the rpm.

Signed-off-by: Srinivas Kandagatla 
---
arch/arm/boot/dts/qcom-apq8064.dtsi | 241 
1 file changed, 241 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi 
b/arch/arm/boot/dts/qcom-apq8064.dtsi
index b3154c0..db5fc59 100644
--- a/arch/arm/boot/dts/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -3,6 +3,7 @@
#include "skeleton.dtsi"
#include 
#include 
+#include 
#include 
#include 

@@ -246,6 +247,246 @@
#reset-cells = <1>;
};

+   l2cc: clock-controller@2011000 {
+   compatible  = "syscon";
+   reg = <0x2011000 0x1000>;
+   };
+
+   rpm@108000 {
+   compatible  = "qcom,rpm-apq8064";
+   reg = <0x108000 0x1000>;
+   qcom,ipc= <&l2cc 0x8 2>;
+
+   interrupts  = <0 19 0>, <0 21 0>, <0 22 0>;
+   interrupt-names = "ack", "err", "wakeup";
+


Can you use the defines for GIC for the interrupts.  Also, I think the last 
property should probably be level high instead of 0.

Yep, I will fix it.

--srini




- k


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 02/11] drm: add bindings for simple vga encoders

[Laurent Pinchart]

Hi Heiko,

Thank you for the patch.

On Saturday 31 January 2015 17:32:55 Heiko Stuebner wrote:
> Add the necessary devicetree binding document for simple vga encoders.
> 
> Signed-off-by: Heiko Stuebner 
> ---
>  .../devicetree/bindings/drm/i2c/vga-simple.txt | 18 +++
>  1 file changed, 18 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/drm/i2c/vga-simple.txt
> 
> diff --git a/Documentation/devicetree/bindings/drm/i2c/vga-simple.txt
> b/Documentation/devicetree/bindings/drm/i2c/vga-simple.txt new file mode
> 100644
> index 000..271df9a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/drm/i2c/vga-simple.txt
> @@ -0,0 +1,18 @@
> +Device-Tree bindings for generic vga encoders
> +
> +Required properties;
> +  - compatible: must be "adi,adv7123"

Bindings already exist for that device, they have been added in commit 
8d0f1956f7c11202 ("video: Add ADV7123 DT bindings documentation").

> +Optional properties:
> +  - ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
> +  - enable-gpio: GPIO pin to enable or disable the encoder
> +  - vaa-supply: regulator for the analog power supply
> +
> +Example:
> +
> + adv7123: vga-encoder {
> + compatible = "adi,adv7123";
> + ddc-i2c-bus = <&i2c4>;
> + vaa-supply = <&vcc_io>;
> + enable-gpio = <&gpio0 17 GPIO_ACTIVE_HIGH>;
> + };

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/8] Add proper support for Compulab CM-A510/SBC-A510

[Gregory CLEMENT]

Hi Sebastian,

On 17/02/2015 19:52, Sebastian Hesselbarth wrote:
> This patch set improves current mainline support for the Compulab
> CM-A510 System-on-Module (SoM) and its default Compulab SBC-A510
> base board. Thanks to Gabriel Dobato who agreed to remote debug and
> test the provided DT changes.
> 
> On the way to proper support, we
> - Rework i2c-mux-pinctrl to honor disabled sub-bus nodes
> - Add missing "compulab" vendor prefix
> - Fix broken uart[23] reg properties
> - Beautify Dove's dtsi files by adding gpio/irq includes, node
>   labels for pcie, and some additional pinctrl settings
> - Add a node for the internal i2c mux mechanism on Dove SoCs
> 
> And finally add a DT include for the Compulab CM-A510 SoM and a DT
> board file for the SBC-A510 base board.
> 
> Patches are based on stable v3.19 and are indended for the next
> merge window (either v3.21 or v4.1). Compulab related changes have
> been tested by Gabriel Dobato, I tested on SolidRun CuBox that it
> does not break existing Dove boards.
> 
> For the i2c-mux-pinctrl, a Tested-by from any user of Tegra20
> Seaboard, Tamonten, or Ventana would be nice to see if it is fully
> compatible.
> 
> I have added MVEBU maintainers to all patches, Wolfram for i2c and
> Stephen as the i2c-mux-pinctrl author i2c-mux-pinctrl related patches,
> and corresponding lists. As there is no important DT work in here,
> I decided to not explicitly add each of the DT maintainers except for
> the vendor prefix patch.
> 
> Sebastian Hesselbarth (8):
>   i2c: mux-pinctrl: Rework to honor disabled child nodes
>   devicetree: vendor-prefixes: Add CompuLab to known vendors
>   ARM: dts: dove: Fix uart[23] reg property
>   ARM: dts: dove: Always include gpio and interrupt-controller headers
>   ARM: dts: dove: Add node labels for PCIe ports 0 and 1
>   ARM: dts: dove: Add some more common pinctrl settings
>   ARM: dts: dove: Add internal i2c multiplexer node
>   ARM: dts: dove: Add proper support for Compulab CM-A510/SBC-A510

Patches 3 to 6 applied on mvebu/dt

If I understood well patches 7 and 8 depend on patch 1 which had not been
taken yet.


Thanks,

Gregory


> 
>  .../devicetree/bindings/i2c/i2c-mux-pinctrl.txt|  28 +--
>  .../devicetree/bindings/vendor-prefixes.txt|   1 +
>  arch/arm/boot/dts/Makefile |   5 +-
>  arch/arm/boot/dts/dove-cm-a510.dts |  38 
>  arch/arm/boot/dts/dove-cm-a510.dtsi| 195 
> +
>  arch/arm/boot/dts/dove-sbc-a510.dts| 182 +++
>  arch/arm/boot/dts/dove.dtsi| 103 ++-
>  drivers/i2c/muxes/i2c-mux-pinctrl.c|  70 +---
>  8 files changed, 537 insertions(+), 85 deletions(-)
>  delete mode 100644 arch/arm/boot/dts/dove-cm-a510.dts
>  create mode 100644 arch/arm/boot/dts/dove-cm-a510.dtsi
>  create mode 100644 arch/arm/boot/dts/dove-sbc-a510.dts
> 
> ---
> Cc: Jason Cooper 
> Cc: Andrew Lunn 
> Cc: Gregory Clement 
> Cc: Gabriel Dobato 
> Cc: Wolfram Sang 
> Cc: Stephen Warren 
> Cc: linux-...@vger.kernel.org
> Cc: devicetree@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-ker...@vger.kernel.org
> 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv3] mvebu: add Linksys WRT1900AC (Mamba) support

[Gregory CLEMENT]

Hi Imre,

On 23/02/2015 19:43, Imre Kaloz wrote:
> Hi Gregory,
> 
> On Mon, 23 Feb 2015 19:32:53 +0100, Gregory CLEMENT  
>  wrote:
> 
> ...
> 
>>> @@ -0,0 +1,348 @@
>>> +/*
>>> + * Device Tree file for the Linksys WRT1900AC (Mamba).
>>> + *
>>> + * Note: this board is shipped with a new generation boot loader that
>>> + * remaps internal registers at 0xf100. Therefore, if earlyprintk
>>> + * is used, the CONFIG_DEBUG_MVEBU_UART_ALTERNATE option should be
>>
>> This symbol name has been removed and DEBUG_MVEBU_UART0_ALTERNATE would
>> be used instead.
>>
>> Besides this,
>>
>> Acked-by: Gregory CLEMENT 
>>
>> You don't have to resend a new version for this, I can amend
>> your patch while applying it. So unless there is new comments
>> I will add your patch to the mvebu tree in a couple of days.
> 
> I knew I will forget something - this has been noted by Andrew back then  
> :) Thank you for taking care of this.


Now applied (amended) on mvebu/dt
Thanks,

Gregory

> 
> 
> Best,
> 
> Imre
> 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: kexec: Relax SMP validation to improve DT compatibility

[Russell King - ARM Linux]

On Thu, Feb 26, 2015 at 11:37:08AM +0100, Geert Uytterhoeven wrote:
> When trying to kexec into a new kernel on a platform where multiple CPU
> cores are present, but no SMP bringup code is available yet, the
> kexec_load system call fails with:
> 
> kexec_load failed: Invalid argument
> 
> The SMP test added to machine_kexec_prepare() in commit 2103f6cba61a8b8b
> ("ARM: 7807/1: kexec: validate CPU hotplug support") wants to prohibit
> kexec on SMP platforms where it cannot disable secondary CPUs.
> However, this test is too strict: if the secondary CPUs couldn't be
> enabled in the first place, there's no need to disable them later at
> kexec time.  Hence skip the test in the absence of SMP bringup code.

Hmm.  I don't think we should relax it in this manner - I think there's
an easier solution to this.

> diff --git a/arch/arm/kernel/machine_kexec.c b/arch/arm/kernel/machine_kexec.c
> index de2b085ad7535da7..8bf3b7c098881b95 100644
> --- a/arch/arm/kernel/machine_kexec.c
> +++ b/arch/arm/kernel/machine_kexec.c
> @@ -46,7 +46,8 @@ int machine_kexec_prepare(struct kimage *image)
>* and implements CPU hotplug for the current HW. If not, we won't be
>* able to kexec reliably, so fail the prepare operation.
>*/
> - if (num_possible_cpus() > 1 && !platform_can_cpu_hotplug())
> + if (num_possible_cpus() > 1 && platform_can_secondary_boot() &&
> + !platform_can_cpu_hotplug())

if (num_online_cpus() > 1 && !platform_can_cpu_hotplug())

>   return -EINVAL;

Neither test is actually accurate though: when we have implementations
where the secondary CPUs spin inside the kernel when they're "unplugged"
that is not sufficient to be able to kexec.

We should probably fix that, and make platform_can_cpu_hotplug() report
whether it really is possible to hotplug all secondary CPUs into such
a state that kexec can work.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/4] Add support for IPROC SDHCI controller

[Scott Branden]

Hi Chris,

I have not heard any more feedback on this patchset.  Is it in your 
queue to review or merge into your tree?


Thanks,
 Scott

On 15-02-09 04:06 PM, Scott Branden wrote:

This series of patchsets contains the IPROC SDHCI driver used
in a series of Broadcom SoCs
Quirks are also added to support this controller.

Corneliu Doban (1):
   mmc: sdhci: do not set AUTO_CMD12 for multi-block CMD53

Scott Branden (3):
   mmc: sdhci: add quirk for ACMD23 broken
   mmc: sdhci-iproc: add IPROC SDHCI driver
   mmc: sdhci-iproc: add device tree bindings

  .../devicetree/bindings/mmc/brcm,sdhci-iproc.txt   |  23 ++
  drivers/mmc/host/Kconfig   |  14 ++
  drivers/mmc/host/Makefile  |   1 +
  drivers/mmc/host/sdhci-iproc.c | 241 +
  drivers/mmc/host/sdhci.c   |   7 +-
  include/linux/mmc/sdhci.h  |   2 +
  6 files changed, 286 insertions(+), 2 deletions(-)
  create mode 100644 Documentation/devicetree/bindings/mmc/brcm,sdhci-iproc.txt
  create mode 100644 drivers/mmc/host/sdhci-iproc.c



--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: kexec: Relax SMP validation to improve DT compatibility

[Stephen Warren]

On 02/26/2015 03:37 AM, Geert Uytterhoeven wrote:

When trying to kexec into a new kernel on a platform where multiple CPU
cores are present, but no SMP bringup code is available yet, the
kexec_load system call fails with:

 kexec_load failed: Invalid argument

The SMP test added to machine_kexec_prepare() in commit 2103f6cba61a8b8b
("ARM: 7807/1: kexec: validate CPU hotplug support") wants to prohibit
kexec on SMP platforms where it cannot disable secondary CPUs.
However, this test is too strict: if the secondary CPUs couldn't be
enabled in the first place, there's no need to disable them later at
kexec time.  Hence skip the test in the absence of SMP bringup code.

This allows to add all CPU cores to the DTS from the beginning, without
having to implement SMP bringup first, improving DT compatibility.


Acked-by: Stephen Warren 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] ARM: dts: am335x-lxm: Use rmii-clock-ext

[George McCollister]

Use external clock for RMII since the internal clock doesn't meet the
jitter requirements.

Signed-off-by: George McCollister 
---
 arch/arm/boot/dts/am335x-lxm.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/am335x-lxm.dts b/arch/arm/boot/dts/am335x-lxm.dts
index 7266a00..5c5667a 100644
--- a/arch/arm/boot/dts/am335x-lxm.dts
+++ b/arch/arm/boot/dts/am335x-lxm.dts
@@ -328,6 +328,10 @@
dual_emac_res_vlan = <3>;
 };
 
+&phy_sel {
+   rmii-clock-ext;
+};
+
 &mac {
pinctrl-names = "default", "sleep";
pinctrl-0 = <&cpsw_default>;
-- 
2.2.2

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/3] Add initial DT support for Qualcomm SPMI PMIC devices

[Ivan T. Ivanov]

Hi Stephan, 

Sorry for delayed answer.

On Thu, 2015-02-19 at 16:49 -0800, Stephen Boyd wrote:
> On 02/03/15 04:17, Ivan T. Ivanov wrote:
> > Following set of patches add initial DT support for PMIC devices
> > found on recent Quqalcomm chipsets. Details for SPMI bus and PMIC arbiter
> > could be found here [1].
> 
> Can you please put the specific compatible strings for the pmic model
> into the nodes in addition to the generic "qcom,spmi-pmic"? We may want
> to have regmap config tables in the future that describe the
> cache/read/write abilities of the regsiters. If all we have is the
> generic binding then we don't have a way to populate these tables.
> Unless the plan there is to use the revid registers?
> 

I would really like that we can use "revid" registers, but I don't know... 

>From what I can see usually in one physical PMIC chip they
are 2 USID devices.

I can successfully discover following USID's on APQ8074 boards:

pmic-spmi 0-00: qcom,pm8941-v1.0 detected
pmic-spmi 0-01: qcom,pm8941-v1.0 detected
pmic-spmi 0-04: qcom,pm8841-v0.0 detected
pmic-spmi 0-05: qcom,pm8841-v0.0 detected

Unfortunately on PM8916 only one device is detected, with USID 0.
But they should be two, judging by downstream DTS files, right?

pmic-spmi 0-00: qcom,pm8916-v0.0 detected 
pmic-spmi 0-01: unknown device

For communication with PM8916 I am using recent patches from Gilad [1].
Maybe there are still some issues with these patches, which can cause
this behavior or PM8916 just didn't have these registers for USID 1?

Regards,
Ivan 

[1] https://lkml.org/lkml/2015/2/19/453

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2 14/15] ARM: mvebu: add Device Tree files for Armada 39x SoC and board

[Gregory CLEMENT]

Hi Thomas,

On 20/02/2015 18:04, Thomas Petazzoni wrote:
> This commit adds the Device Tree files for the Armada 39x family of
> processors, as well as one Armada 398 Development Board.
> 
> Like for other Marvell EBU families, a common armada-39x.dtsi contains
> the description of the common features of all Armada 39x SoCs, while
> armada-390.dtsi and armada-398.dtsi respectively describe the
> specificities of those SoCs.
> 
> Finally, an armada-398-db.dts file is added to describe the Armada 398
> Development Board itself.
> 
> So far, the following features are supported:
> 
>  * SMP: dual Cortex-A9
>  * Basic ARM IPs: SCU, timer, GIC
>  * Basic Marvell IPs: pin-muxing, clocks, system controller, MBus
>controller, MPIC interrupt controller, timer, CPU reset for SMP,
>PMSU.
>  * I2C
>  * UART
>  * PCIe
> 
> Additional features will be supported in the future.

These device trees seem OK, I only found a small typo in the mpic node,
see below.

I also booted the kernel and I got the following error:
L2C: failed to init: -19

Actually it seems that the L2 cache controller node is missing.
Is it intentional?

If for now you don't want to add the support for the L2 cache controller then
you should remove the initialization of the l2c_aux_val and l2c_aux_mask field
in the machine_desc structure.


> 
> Signed-off-by: Thomas Petazzoni 
> ---
>  arch/arm/boot/dts/Makefile  |   2 +
>  arch/arm/boot/dts/armada-390.dtsi   |  57 +
>  arch/arm/boot/dts/armada-398-db.dts | 154 +++
>  arch/arm/boot/dts/armada-398.dtsi   |  60 +
>  arch/arm/boot/dts/armada-39x.dtsi   | 494 
> 
>  5 files changed, 767 insertions(+)
>  create mode 100644 arch/arm/boot/dts/armada-390.dtsi
>  create mode 100644 arch/arm/boot/dts/armada-398-db.dts
>  create mode 100644 arch/arm/boot/dts/armada-398.dtsi
>  create mode 100644 arch/arm/boot/dts/armada-39x.dtsi
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 968bc7a..64886fb 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -540,6 +540,8 @@ dtb-$(CONFIG_MACH_ARMADA_38X) += \
>   armada-388-db.dtb \
>   armada-388-gp.dtb \
>   armada-388-rd.dtb
> +dtb-$(CONFIG_MACH_ARMADA_39X) += \
> + armada-398-db.dtb
>  dtb-$(CONFIG_MACH_ARMADA_XP) += \
>   armada-xp-axpwifiap.dtb \
>   armada-xp-db.dtb \
> diff --git a/arch/arm/boot/dts/armada-390.dtsi 
> b/arch/arm/boot/dts/armada-390.dtsi
> new file mode 100644
> index 000..094e39c
> --- /dev/null
> +++ b/arch/arm/boot/dts/armada-390.dtsi
> @@ -0,0 +1,57 @@
> +/*
> + * Device Tree Include file for Marvell Armada 390 SoC.
> + *
> + * Copyright (C) 2015 Marvell
> + *
> + * Thomas Petazzoni 
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This file is distributed in the hope that it will be useful
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +#include "armada-39x.dtsi"
> +
> +/ {
> + soc {
> + internal-regs {
> + pinctrl@18000 {
> + compatible = "marvell,mv88f6920-pinctrl";
> +  

Re: [PATCH 1/2] Input: bcm-keypad: add device tree bindings

[Scott Branden]

Hi Dmitry,

Thanks for the update of no need to change any of dt-binding prefixes. 
I just sent out a v2 patch addressing all of your other comments.


On 15-02-23 09:49 AM, Dmitry Torokhov wrote:

Hi Scott,

On Sun, Feb 15, 2015 at 09:17:51PM -0800, Dmitry Torokhov wrote:

On Sat, Feb 14, 2015 at 08:49:15AM -0800, Scott Branden wrote:

On 15-02-09 04:51 PM, Dmitry Torokhov wrote:

On Mon, Feb 09, 2015 at 04:07:40PM -0800, Scott Branden wrote:

+
+- col-debounce-filter-period: The debounce period for the Column filter.
+
+   KEYPAD_DEBOUNCE_1_ms=   0
+   KEYPAD_DEBOUNCE_2_ms=   1
+   KEYPAD_DEBOUNCE_4_ms=   2
+   KEYPAD_DEBOUNCE_8_ms=   3



+   KEYPAD_DEBOUNCE_16_ms   =   4
+   KEYPAD_DEBOUNCE_32_ms   =   5
+   KEYPAD_DEBOUNCE_64_ms   =   6
+   KEYPAD_DEBOUNCE_128_ms  =   7
+
+- status-debounce-filter-period: The debounce period for the Status filter.
+
+   KEYPAD_DEBOUNCE_1_ms=   0
+   KEYPAD_DEBOUNCE_2_ms=   1
+   KEYPAD_DEBOUNCE_4_ms=   2
+   KEYPAD_DEBOUNCE_8_ms=   3
+   KEYPAD_DEBOUNCE_16_ms   =   4
+   KEYPAD_DEBOUNCE_32_ms   =   5
+   KEYPAD_DEBOUNCE_64_ms   =   6
+   KEYPAD_DEBOUNCE_128_ms  =   7


I could swear device-specific properties should be in form of
, to ensure it won't clash with changes on
subsystem level later on. Device-tree folks, what say you?

I see examples with and without vendor-prefix.
qcom,pm8xxx-keypad.txt does not have prefixes
st-keyscan.txt does have a prefix

I can't find any documented guidelines for this.


As I mentioned I'll try to get clarification on this.


I have chatted with a couple of people on this and it is acceptable to
omit vendor prefix in bindings when we are using a specific driver like
we have here (i.e. when driver's compatible string already includes
vendor prefix). Vendor prefixes on properties are required when we
augment a generic driver's binding.

So the above 2 entries are fine as is.

Thanks.



--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH RESEND] coresight-stm: Bindings for System Trace Macrocell

[Mathieu Poirier]

The System Trace Macrocell (STM) is an IP block falling under the
CoreSight umbrella.  It's main purpose it so expose stimulus channels
to any system component for the purpose of information logging.

Bindings for this IP block adds a couple of items to the current
mandatory definition for CoreSight components.  The driver has been posted
here[1].

[1]. https://lkml.org/lkml/2015/2/25/743

Signed-off-by: Mathieu Poirier 
---
 .../devicetree/bindings/arm/coresight.txt  | 25 ++
 1 file changed, 25 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/coresight.txt 
b/Documentation/devicetree/bindings/arm/coresight.txt
index a3089359aaa6..854127578718 100644
--- a/Documentation/devicetree/bindings/arm/coresight.txt
+++ b/Documentation/devicetree/bindings/arm/coresight.txt
@@ -17,6 +17,7 @@ its hardware characteristcs.
- "arm,coresight-tmc", "arm,primecell";
- "arm,coresight-funnel", "arm,primecell";
- "arm,coresight-etm3x", "arm,primecell";
+   - "arm,coresight-stm", "arm,primecell";
 
* reg: physical base address and length of the register
  set(s) of the component.
@@ -31,6 +32,14 @@ its hardware characteristcs.
  layout using the generic DT graph presentation found in
  "bindings/graph.txt".
 
+* Additional required properly for System Trace Macrocells (STM):
+   * reg: along with the physical base address and length of the register
+ set as described above, another entry is required to describe the
+ mapping of the extended stimulus port area.
+
+   * reg-names: the only acceptable values are "stm-base" and
+ "stm-channel-base", each corresponding to the areas defined in "reg".
+
 * Required properties for devices that don't show up on the AMBA bus, such as
   non-configurable replicators:
 
@@ -198,3 +207,19 @@ Example:
};
};
};
+
+4. STM
+   stm@2010 {
+   compatible = "arm,coresight-stm", "arm,primecell";
+   reg = <0 0x2010 0 0x1000>,
+ <0 0x2800 0 0x18>;
+   reg-names = "stm-base", "stm-channel-base";
+
+   clocks = <&soc_smc50mhz>;
+   clock-names = "apb_pclk";
+   port {
+   stm_out_port: endpoint {
+   remote-endpoint = <&main_funnel_in_port2>;
+   };
+   };
+   };
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 0/2] Add support for Broadcom keypad controller

[Scott Branden]

This series of patchsets contains the Broadcom keypad controller driver
and device tree binding documentation.

Changes from v1:
- updated dt documentation to remove to matrix-keymap.txt
- removed bcm_kp_remove as it is not necessary
- removed key-interrupt-trigger-type dt binding
- added bcm_kp_report_keys and call to process key registers

Scott Branden (2):
  Input: bcm-keypad: add device tree bindings
  Input: bcm-keypad: Add Broadcom keypad controller

 .../devicetree/bindings/input/brcm,bcm-keypad.txt  | 108 +
 drivers/input/keyboard/Kconfig |  10 +
 drivers/input/keyboard/Makefile|   1 +
 drivers/input/keyboard/bcm-keypad.c| 464 +
 4 files changed, 583 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/input/brcm,bcm-keypad.txt
 create mode 100644 drivers/input/keyboard/bcm-keypad.c

-- 
2.3.0

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 2/2] Input: bcm-keypad: Add Broadcom keypad controller

[Scott Branden]

Add driver for Broadcom's keypad controller.

Broadcom Keypad controller is used to interface a SoC with a matrix-type
keypad device. The keypad controller supports multiple row and column lines.
A key can be placed at each intersection of a unique row and a unique column.
The keypad controller can sense a key-press and key-release and report the
event using a interrupt to the cpu.

Reviewed-by: Ray Jui 
Signed-off-by: Scott Branden 
---
 drivers/input/keyboard/Kconfig  |  10 +
 drivers/input/keyboard/Makefile |   1 +
 drivers/input/keyboard/bcm-keypad.c | 464 
 3 files changed, 475 insertions(+)
 create mode 100644 drivers/input/keyboard/bcm-keypad.c

diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index a5d9b3f..3a0c0f2 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -676,4 +676,14 @@ config KEYBOARD_CAP11XX
  To compile this driver as a module, choose M here: the
  module will be called cap11xx.
 
+config KEYBOARD_BCM
+   tristate "Broadcom keypad driver"
+   select INPUT_MATRIXKMAP
+   default ARCH_BCM_CYGNUS
+   help
+ Say Y here if you want to use Broadcom keypad.
+
+ To compile this driver as a module, choose M here: the
+ module will be called bcm-keypad.
+
 endif
diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile
index febafa5..3cff8f6 100644
--- a/drivers/input/keyboard/Makefile
+++ b/drivers/input/keyboard/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_KEYBOARD_ADP5589)+= 
adp5589-keys.o
 obj-$(CONFIG_KEYBOARD_AMIGA)   += amikbd.o
 obj-$(CONFIG_KEYBOARD_ATARI)   += atakbd.o
 obj-$(CONFIG_KEYBOARD_ATKBD)   += atkbd.o
+obj-$(CONFIG_KEYBOARD_BCM) += bcm-keypad.o
 obj-$(CONFIG_KEYBOARD_BFIN)+= bf54x-keys.o
 obj-$(CONFIG_KEYBOARD_CAP11XX) += cap11xx.o
 obj-$(CONFIG_KEYBOARD_CLPS711X)+= clps711x-keypad.o
diff --git a/drivers/input/keyboard/bcm-keypad.c 
b/drivers/input/keyboard/bcm-keypad.c
new file mode 100644
index 000..f229ac0
--- /dev/null
+++ b/drivers/input/keyboard/bcm-keypad.c
@@ -0,0 +1,464 @@
+/*
+ * Copyright (C) 2014 Broadcom Corporation
+ *
+ * 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 version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DEFAULT_CLK_HZ  31250
+/* Repeat period (ms) */
+#define KEY_REPEAT_PERIOD   100
+/* First time press dly (ms) */
+#define KEY_REPEAT_DELAY400
+#define MAX_ROWS8
+#define MAX_COLS8
+
+/* Register/field definitions */
+#define KPCR_OFFSET  0x0080
+#define KPCR_MODE   0x0002
+#define KPCR_MODE_SHIFT 1
+#define KPCR_MODE_MASK  1
+#define KPCR_ENABLE 0x0001
+#define KPCR_STATUSFILTERENABLE 0x8000
+#define KPCR_STATUSFILTERTYPE_SHIFT  12
+#define KPCR_COLFILTERENABLE0x0800
+#define KPCR_COLFILTERTYPE_SHIFT 8
+#define KPCR_ROWWIDTH_SHIFT  20
+#define KPCR_COLUMNWIDTH_SHIFT   16
+
+#define KPIOR_OFFSET 0x0084
+#define KPIOR_ROWOCONTRL_SHIFT   24
+#define KPIOR_ROWOCONTRL_MASK0xFF00
+#define KPIOR_COLUMNOCONTRL_SHIFT16
+#define KPIOR_COLUMNOCONTRL_MASK 0x00FF
+#define KPIOR_COLUMN_IO_DATA_SHIFT   0
+
+#define KPEMR0_OFFSET0x0090
+#define KPEMR1_OFFSET0x0094
+#define KPEMR2_OFFSET0x0098
+#define KPEMR3_OFFSET0x009C
+#define KPEMR_EDGETYPE_BOTH 3
+
+#define KPSSR0_OFFSET0x00A0
+#define KPSSR1_OFFSET0x00A4
+#define KPSSRN_OFFSET(reg_n) (KPSSR0_OFFSET + (4 * reg_n))
+#define KPIMR0_OFFSET0x00B0
+#define KPIMR1_OFFSET0x00B4
+#define KPICR0_OFFSET0x00B8
+#define KPICR1_OFFSET0x00BC
+#define KPICRN_OFFSET(reg_n) (KPICR0_OFFSET + (4 * reg_n))
+#define KPISR0_OFFSET0x00C0
+#define KPISR1_OFFSET0x00C4
+
+#define KPCR

[PATCH v2 1/2] Input: bcm-keypad: add device tree bindings

[Scott Branden]

Documents the Broadcom keypad controller device tree bindings.

Reviewed-by: Ray Jui 
Signed-off-by: Scott Branden 
---
 .../devicetree/bindings/input/brcm,bcm-keypad.txt  | 108 +
 1 file changed, 108 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/input/brcm,bcm-keypad.txt

diff --git a/Documentation/devicetree/bindings/input/brcm,bcm-keypad.txt 
b/Documentation/devicetree/bindings/input/brcm,bcm-keypad.txt
new file mode 100644
index 000..e16bb2d
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/brcm,bcm-keypad.txt
@@ -0,0 +1,108 @@
+* Broadcom Keypad Controller device tree bindings
+
+Broadcom Keypad controller is used to interface a SoC with a matrix-type
+keypad device. The keypad controller supports multiple row and column lines.
+A key can be placed at each intersection of a unique row and a unique column.
+The keypad controller can sense a key-press and key-release and report the
+event using a interrupt to the cpu.
+
+This binding is based on the matrix-keymap binding with the following
+changes:
+
+keypad,num-rows and keypad,num-columns are required.
+
+Required SoC Specific Properties:
+- compatible: should be "brcm,bcm-keypad"
+
+- reg: physical base address of the controller and length of memory mapped
+  region.
+
+- interrupts: The interrupt number to the cpu.
+
+Board Specific Properties:
+- keypad,num-rows: Number of row lines connected to the keypad
+  controller.
+
+- keypad,num-columns: Number of column lines connected to the
+  keypad controller.
+
+- col-debounce-filter-period: The debounce period for the Column filter.
+
+   KEYPAD_DEBOUNCE_1_ms=   0
+   KEYPAD_DEBOUNCE_2_ms=   1
+   KEYPAD_DEBOUNCE_4_ms=   2
+   KEYPAD_DEBOUNCE_8_ms=   3
+   KEYPAD_DEBOUNCE_16_ms   =   4
+   KEYPAD_DEBOUNCE_32_ms   =   5
+   KEYPAD_DEBOUNCE_64_ms   =   6
+   KEYPAD_DEBOUNCE_128_ms  =   7
+
+- status-debounce-filter-period: The debounce period for the Status filter.
+
+   KEYPAD_DEBOUNCE_1_ms=   0
+   KEYPAD_DEBOUNCE_2_ms=   1
+   KEYPAD_DEBOUNCE_4_ms=   2
+   KEYPAD_DEBOUNCE_8_ms=   3
+   KEYPAD_DEBOUNCE_16_ms   =   4
+   KEYPAD_DEBOUNCE_32_ms   =   5
+   KEYPAD_DEBOUNCE_64_ms   =   6
+   KEYPAD_DEBOUNCE_128_ms  =   7
+
+- row-output-enabled: An optional property indicating whether the row or
+  column is being used as output. If specified the row is being used
+  as the output. Else defaults to column.
+
+- pull-up-enabled: An optional property indicating the Keypad scan mode.
+  If specified implies the keypad scan pull-up has been enabled.
+
+- linux,keypad-no-autorepeat: An optional property indicating to
+  not enable autorepeat feature.
+
+- linux,keymap: The keymap for keys as described in the binding document
+  devicetree/bindings/input/matrix-keymap.txt.
+
+Example:
+#include "dt-bindings/input/input.h"
+
+/ {
+   keypad: keypad@180ac000 {
+   /* Required SoC specific properties */
+   compatible = "brcm,bcm-keypad";
+
+   /* Required Board specific properties */
+   keypad,num-rows = <5>;
+   keypad,num-columns = <5>;
+   status = "okay";
+
+   linux,keymap = ;
+
+   /* Optional board specific properties */
+   col-debounce-filter-period = <5>;
+   row-output-enabled;
+   pull-up-enabled;
+
+   };
+};
-- 
2.3.0

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/3] powerpc/mpc85xx: Add FMan clock nodes

[Emil Medve]

From: Igal Liberman 

Signed-off-by: Igal Liberman 
---
 arch/powerpc/boot/dts/fsl/b4si-post.dtsi| 11 +++
 arch/powerpc/boot/dts/fsl/p2041si-post.dtsi |  8 
 arch/powerpc/boot/dts/fsl/p3041si-post.dtsi |  8 
 arch/powerpc/boot/dts/fsl/p4080si-post.dtsi | 16 
 arch/powerpc/boot/dts/fsl/p5020si-post.dtsi | 13 +
 arch/powerpc/boot/dts/fsl/p5040si-post.dtsi | 26 ++
 arch/powerpc/boot/dts/fsl/t1040si-post.dtsi |  8 
 arch/powerpc/boot/dts/fsl/t2081si-post.dtsi | 11 +++
 arch/powerpc/boot/dts/fsl/t4240si-post.dtsi | 20 
 9 files changed, 121 insertions(+)

diff --git a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi 
b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
index f8c325e..38621ef 100644
--- a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
@@ -395,6 +395,17 @@
reg = <0xe 0xe00>;
fsl,has-rstcr;
fsl,liodn-bits = <12>;
+
+   fm0clk: fm0-clk-mux {
+   #clock-cells = <0>;
+   compatible = "fsl,fman-clk-mux";
+   clocks = <&pll0 0>, <&pll0 1>, <&pll0 2>, <&pll0 3>,
+<&platform_pll 0>, <&pll1 1>, <&pll1 2>;
+   clock-names = "pll0", "pll0-div2", "pll0-div3",
+ "pll0-div4", "platform-pll", "pll1-div2",
+ "pll1-div3";
+   clock-output-names = "fm0-clk";
+   };
};
 
 /include/ "qoriq-clockgen2.dtsi"
diff --git a/arch/powerpc/boot/dts/fsl/p2041si-post.dtsi 
b/arch/powerpc/boot/dts/fsl/p2041si-post.dtsi
index 1f18b8b..60f63dc 100644
--- a/arch/powerpc/boot/dts/fsl/p2041si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p2041si-post.dtsi
@@ -316,6 +316,14 @@
fsl,has-rstcr;
#sleep-cells = <1>;
fsl,liodn-bits = <12>;
+
+   fm0clk: fm0-clk-mux {
+   #clock-cells = <0>;
+   compatible = "fsl,fman-clk-mux";
+   clocks = <&platform_pll 1>, <&pll1 1>;
+   clock-names = "platform-pll-div2", "pll1-div2";
+   clock-output-names = "fm0-clk";
+   };
};
 
pins: global-utilities@e0e00 {
diff --git a/arch/powerpc/boot/dts/fsl/p3041si-post.dtsi 
b/arch/powerpc/boot/dts/fsl/p3041si-post.dtsi
index a555d24..d4e6677 100644
--- a/arch/powerpc/boot/dts/fsl/p3041si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p3041si-post.dtsi
@@ -343,6 +343,14 @@
fsl,has-rstcr;
#sleep-cells = <1>;
fsl,liodn-bits = <12>;
+
+   fm0clk: fm0-clk-mux {
+   #clock-cells = <0>;
+   compatible = "fsl,fman-clk-mux";
+   clocks = <&platform_pll 1>, <&pll1 1>;
+   clock-names = "platform-pll-div2", "pll1-div2";
+   clock-output-names = "fm0-clk";
+   };
};
 
pins: global-utilities@e0e00 {
diff --git a/arch/powerpc/boot/dts/fsl/p4080si-post.dtsi 
b/arch/powerpc/boot/dts/fsl/p4080si-post.dtsi
index 0fe7281..d1cb691 100644
--- a/arch/powerpc/boot/dts/fsl/p4080si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p4080si-post.dtsi
@@ -363,6 +363,22 @@
fsl,has-rstcr;
#sleep-cells = <1>;
fsl,liodn-bits = <12>;
+
+   fm0clk: fm0-clk-mux {
+   #clock-cells = <0>;
+   compatible = "fsl,fman-clk-mux";
+   clocks = <&platform_pll 1>, <&pll2 1>;
+   clock-names = "platform-pll-div2", "pll2-div2";
+   clock-output-names = "fm0-clk";
+   };
+
+   fm1clk: fm1-clk-mux {
+   #clock-cells = <0>;
+   compatible = "fsl,fman-clk-mux";
+   clocks = <&platform_pll 1>, <&pll2 1>;
+   clock-names = "platform-pll-div2", "pll2-div2";
+   clock-output-names = "fm1-clk";
+   };
};
 
pins: global-utilities@e0e00 {
diff --git a/arch/powerpc/boot/dts/fsl/p5020si-post.dtsi 
b/arch/powerpc/boot/dts/fsl/p5020si-post.dtsi
index a34ca20..9f3049d 100644
--- a/arch/powerpc/boot/dts/fsl/p5020si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p5020si-post.dtsi
@@ -348,6 +348,15 @@
fsl,has-rstcr;
#sleep-cells = <1>;
fsl,liodn-bits = <12>;
+
+   fm0clk: fm0-clk-mux {
+   #clock-cells = <0>;
+   compatible = "fsl,fman-clk-mux";
+   clocks = <&platform_pll 1>, <&pll1 1>, <&pll1 2>;
+   clock-names = "platform-pll-div2", "pll1-div2",
+ "pll1-div4";
+  

Re: [PATCH v4 2/8] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC

[Arnd Bergmann]

On Thursday 26 February 2015 17:18:41 Chanwoo Choi wrote:
> I add following aliases and serial_1/serial_3 dt node in board dtsi:
> I tested that change the alias of serial_x node.
> 
> aliases {
> serial0 = &serial_1;
> serial1 = &serial_3;
> };
> 
> /* Add 'linux,stdout-path' property to print kernel log by using 
> ealycon */
> chosen {
> linux,stdout-path = &serial_1;
> };
> 
> [snip]
> 
> /* serial_1 is used for printing kernel log throught JIG cable */
> &serial_1 {
> status = "okay";
> };
> 
> &serial_3 {
> status = "okay";
> };
> 
> In result, serial driver create the /dev/ttySAC0 for serial_1 and 
> /dev/ttySAC1 for serial_3.
> But, I cannot complete the kernel booting and stop it with following kernel 
> log
> 
> [0.00] Booting Linux on physical CPU 0x100
> [0.00] Initializing cgroup subsys cpuset
> [0.00] Initializing cgroup subsys cpu
> [0.00] Initializing cgroup subsys cpuacct
> [0.00] Linux version 4.0.0-rc1-00066-g49bfcec-dirty (cwchoi00@chan) 
> (gcc version 4.9.2 20140904 (prerelease) (crosstool-NG l5
> [snip]
> [0.00] Kernel command line: console=ttySAC1,115200 
> earlycon=exynos4210,0x14C2

What is the "earlycon=exynos4210,0x14C2" doing here? Should that not just be
"earlycon=exynos" or something like that when you set the correct stdout-path?

> [snip]
> [0.651647] dma-pl330 1561.pdma: Loaded driver for PL330 DMAC-341330
> [0.651851] dma-pl330 1561.pdma: DBUFF-32x4bytes Num_Chans-8 
> Num_Peri-32 Num_Events-32
> [0.658566] dma-pl330 1560.pdma: Loaded driver for PL330 DMAC-341330
> [0.662872] dma-pl330 1560.pdma: DBUFF-32x4bytes Num_Chans-8 
> Num_Peri-32 Num_Events-32
> [0.672487] dma-pl330 1142.adma: Loaded driver for PL330 DMAC-341330
> [ 8466.414900] dma-pl330 1142.adma: DBUFF-8x8bytes Num_Chans-8 
> Num_Peri-16 Num_Events-8
> [ 8466.481648] 14c2.serial: ttySAC0 at MMIO 0x14c2 (irq = 21, 
> base_baud = 0) is a S3C6400/10
> (dont' print any kernel log)
> 
> So, I change the kernel command line about ('console' bootparam) as following:
> because tty framework must use the 'console' bootparam to print kernel log.
> - original : Kernel command line: console=ttySAC1,115200 ... (cannot the 
> kernel log from serial driver probed)
> - modification : Kernel command line: console=ttySAC0,115200 ... (got the 
> successful kernel booting)
> 
> After modification, I got the successful kernel booting.
> 
> If should use the serial_0 device and then modify the 'aliases' as following:
> I have to modify the commandline of bootloader if the commandline of 
> bootloader is used
> instad of default kernel command line.
> 
> aliases {
> serial0 = &serial_0;
> serial1 = &serial_1;
> serial2 = &serial_3;
> };

If you need the numbers to match, maybe there is still a bug in the serial port
driver and it uses some arbitrary number (e.g. probe order, or ascending
MMIO address) for the console instead of the alias?

Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] Documentation: DT: omap_serial: document missing properties and add an example

[Matt Porter]

The omap_serial.txt binding documentation lacks a number of properties
that are used in DTS files for platforms incorporating this peripheral.
Fix this by documenting the missing required and optional fields and
add an example.

Signed-off-by: Matt Porter 
---
 .../devicetree/bindings/serial/omap_serial.txt   | 20 
 1 file changed, 20 insertions(+)

diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt 
b/Documentation/devicetree/bindings/serial/omap_serial.txt
index 342eedd..54c2a15 100644
--- a/Documentation/devicetree/bindings/serial/omap_serial.txt
+++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
@@ -4,7 +4,27 @@ Required properties:
 - compatible : should be "ti,omap2-uart" for OMAP2 controllers
 - compatible : should be "ti,omap3-uart" for OMAP3 controllers
 - compatible : should be "ti,omap4-uart" for OMAP4 controllers
+- reg : address and length of the register space
+- interrupts or interrupts-extended : Should contain the uart interrupt
+  specifier or both the interrupt
+  controller phandle and interrupt
+  specifier.
 - ti,hwmods : Must be "uart", n being the instance number (1-based)
 
 Optional properties:
 - clock-frequency : frequency of the clock input to the UART
+- dmas : DMA specifier, consisting of a phandle to the DMA controller
+ node and a DMA channel number.
+- dma-names : "rx" for receive channel, "tx" for transmit channel.
+
+Example:
+
+uart4: serial@49042000 {
+compatible = "ti,omap3-uart";
+reg = <0x49042000 0x400>;
+interrupts = <80>;
+dmas = <&sdma 81 &sdma 82>;
+dma-names = "tx", "rx";
+ti,hwmods = "uart4";
+clock-frequency = <4800>;
+};
-- 
1.8.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/3] powerpc/mpc85xx: Create dts components for the FSL QorIQ DPAA FMan

[Emil Medve]

From: Igal Liberman 

Based on prior work by Andy Fleming 

Signed-off-by: Igal Liberman 
Signed-off-by: Shruti Kanetkar 
Signed-off-by: Emil Medve 
---
 arch/powerpc/boot/dts/fsl/qoriq-fman-0-10g-0.dtsi  |  62 
 arch/powerpc/boot/dts/fsl/qoriq-fman-0-1g-0.dtsi   |  69 ++
 arch/powerpc/boot/dts/fsl/qoriq-fman-0-1g-1.dtsi   |  68 +
 arch/powerpc/boot/dts/fsl/qoriq-fman-0-1g-2.dtsi   |  68 +
 arch/powerpc/boot/dts/fsl/qoriq-fman-0-1g-3.dtsi   |  68 +
 arch/powerpc/boot/dts/fsl/qoriq-fman-0-1g-4.dtsi   |  68 +
 arch/powerpc/boot/dts/fsl/qoriq-fman-0.dtsi| 101 
 arch/powerpc/boot/dts/fsl/qoriq-fman-1-10g-0.dtsi  |  61 
 arch/powerpc/boot/dts/fsl/qoriq-fman-1-1g-0.dtsi   |  68 +
 arch/powerpc/boot/dts/fsl/qoriq-fman-1-1g-1.dtsi   |  68 +
 arch/powerpc/boot/dts/fsl/qoriq-fman-1-1g-2.dtsi   |  68 +
 arch/powerpc/boot/dts/fsl/qoriq-fman-1-1g-3.dtsi   |  68 +
 arch/powerpc/boot/dts/fsl/qoriq-fman-1-1g-4.dtsi   |  68 +
 arch/powerpc/boot/dts/fsl/qoriq-fman-1.dtsi| 101 
 arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-0.dtsi |  61 
 arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-1.dtsi |  61 
 arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-0.dtsi  |  62 
 arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-1.dtsi  |  62 
 arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-2.dtsi  |  62 
 arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-3.dtsi  |  62 
 arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-4.dtsi  |  62 
 arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-5.dtsi  |  62 
 arch/powerpc/boot/dts/fsl/qoriq-fman3-0.dtsi   | 106 +
 arch/powerpc/boot/dts/fsl/qoriq-fman3-1-10g-0.dtsi |  61 
 arch/powerpc/boot/dts/fsl/qoriq-fman3-1-10g-1.dtsi |  61 
 arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-0.dtsi  |  62 
 arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-1.dtsi  |  62 
 arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-2.dtsi  |  62 
 arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-3.dtsi  |  62 
 arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-4.dtsi  |  62 
 arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-5.dtsi  |  62 
 arch/powerpc/boot/dts/fsl/qoriq-fman3-1.dtsi   | 106 +
 32 files changed, 2206 insertions(+)
 create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-fman-0-10g-0.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-fman-0-1g-0.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-fman-0-1g-1.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-fman-0-1g-2.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-fman-0-1g-3.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-fman-0-1g-4.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-fman-0.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-fman-1-10g-0.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-fman-1-1g-0.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-fman-1-1g-1.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-fman-1-1g-2.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-fman-1-1g-3.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-fman-1-1g-4.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-fman-1.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-0.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-fman3-0-10g-1.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-0.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-1.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-2.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-3.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-4.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-fman3-0-1g-5.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-fman3-0.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-fman3-1-10g-0.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-fman3-1-10g-1.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-0.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-1.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-2.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-3.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-4.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-fman3-1-1g-5.dtsi
 create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-fman3-1.dtsi

diff --git a/arch/powerpc/boot/dts/fsl/qoriq-fman-0-10g-0.dtsi 
b/arch/powerpc/boot/dts/fsl/qoriq-fman-0-10g-0.dtsi
new file mode 100644
index 000..2ba842c
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/qoriq-fman-0-10g-0.dtsi
@@ -0,0 +1,62 @@
+/*
+ * QorIQ FMan 10g port #0 

[PATCH 3/3] powerpc/mpc85xx: Add FSL QorIQ DPAA FMan support to the SoC device tree(s)

[Emil Medve]

From: Igal Liberman 

Based on prior work by Andy Fleming 

Signed-off-by: Igal Liberman 
Signed-off-by: Shruti Kanetkar 
Signed-off-by: Emil Medve 
---
 arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi  |   9 ++-
 arch/powerpc/boot/dts/fsl/b4860si-post.dtsi |  20 -
 arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi  |  12 ++-
 arch/powerpc/boot/dts/fsl/b4si-post.dtsi|  31 +++-
 arch/powerpc/boot/dts/fsl/p1023si-post.dtsi | 115 +++-
 arch/powerpc/boot/dts/fsl/p1023si-pre.dtsi  |   5 +-
 arch/powerpc/boot/dts/fsl/p2041si-post.dtsi |  29 ++-
 arch/powerpc/boot/dts/fsl/p2041si-pre.dtsi  |  10 ++-
 arch/powerpc/boot/dts/fsl/p3041si-post.dtsi |  29 ++-
 arch/powerpc/boot/dts/fsl/p3041si-pre.dtsi  |  10 ++-
 arch/powerpc/boot/dts/fsl/p4080si-post.dtsi |  48 +++-
 arch/powerpc/boot/dts/fsl/p4080si-pre.dtsi  |  15 +++-
 arch/powerpc/boot/dts/fsl/p5020si-post.dtsi |  29 ++-
 arch/powerpc/boot/dts/fsl/p5020si-pre.dtsi  |  10 ++-
 arch/powerpc/boot/dts/fsl/p5040si-post.dtsi |  56 +-
 arch/powerpc/boot/dts/fsl/p5040si-pre.dtsi  |  17 +++-
 arch/powerpc/boot/dts/fsl/t1040si-post.dtsi |  31 
 arch/powerpc/boot/dts/fsl/t104xsi-pre.dtsi  |   9 ++-
 arch/powerpc/boot/dts/fsl/t2081si-post.dtsi |  43 +++
 arch/powerpc/boot/dts/fsl/t208xsi-pre.dtsi  |  11 +++
 arch/powerpc/boot/dts/fsl/t4240si-post.dtsi |  88 -
 arch/powerpc/boot/dts/fsl/t4240si-pre.dtsi  |  22 +-
 22 files changed, 629 insertions(+), 20 deletions(-)

diff --git a/arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi 
b/arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi
index 338af7e..70e2096 100644
--- a/arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi
@@ -1,7 +1,7 @@
 /*
  * B4420 Silicon/SoC Device Tree Source (pre include)
  *
- * Copyright 2012 Freescale Semiconductor, Inc.
+ * Copyright 2012 - 2015 Freescale Semiconductor, Inc.
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions are met:
@@ -54,8 +54,13 @@
dma0 = &dma0;
dma1 = &dma1;
sdhc = &sdhc;
-   };
 
+   fman0 = &fman0;
+   ethernet0 = &enet0;
+   ethernet1 = &enet1;
+   ethernet2 = &enet2;
+   ethernet3 = &enet3;
+   };
 
cpus {
#address-cells = <1>;
diff --git a/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi 
b/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi
index 02ccde6..006e95c 100644
--- a/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi
@@ -1,7 +1,7 @@
 /*
  * B4860 Silicon/SoC Device Tree Source (post include)
  *
- * Copyright 2012 - 2014 Freescale Semiconductor Inc.
+ * Copyright 2012 - 2015 Freescale Semiconductor Inc.
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions are met:
@@ -260,6 +260,24 @@
compatible = "fsl,b4860-rcpm", "fsl,qoriq-rcpm-2.0";
};
 
+/include/ "qoriq-fman3-0-1g-4.dtsi"
+/include/ "qoriq-fman3-0-1g-5.dtsi"
+/include/ "qoriq-fman3-0-10g-0.dtsi"
+/include/ "qoriq-fman3-0-10g-1.dtsi"
+   fman@40 {
+   enet4: ethernet@e8000 {
+   };
+
+   enet5: ethernet@ea000 {
+   };
+
+   enet6: ethernet@f {
+   };
+
+   enet7: ethernet@f2000 {
+   };
+   };
+
L2: l2-cache-controller@c2 {
compatible = "fsl,b4860-l2-cache-controller";
};
diff --git a/arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi 
b/arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi
index 1948f73..0fbda72 100644
--- a/arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi
@@ -1,7 +1,7 @@
 /*
  * B4860 Silicon/SoC Device Tree Source (pre include)
  *
- * Copyright 2012 Freescale Semiconductor Inc.
+ * Copyright 2012 - 2015 Freescale Semiconductor Inc.
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions are met:
@@ -54,6 +54,16 @@
dma0 = &dma0;
dma1 = &dma1;
sdhc = &sdhc;
+
+   fman0 = &fman0;
+   ethernet0 = &enet0;
+   ethernet1 = &enet1;
+   ethernet2 = &enet2;
+   ethernet3 = &enet3;
+   ethernet4 = &enet4;
+   ethernet5 = &enet5;
+   ethernet6 = &enet6;
+   ethernet7 = &enet7;
};
 
 
diff --git a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi 
b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
index 38621ef..b2ff0cb 100644
--- a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
@@ -1,7 +1,7 @@
 /*
  * B4420 Silicon/SoC Device Tree Source (post include)
  *
- * Copyrig

Re: [PATCH v5 1/6] mfd: fsl imx25 Touchscreen ADC driver

[Markus Pargmann]

On Wed, Feb 18, 2015 at 12:08:44PM +, Lee Jones wrote:
> On Wed, 18 Feb 2015, Fabio Estevam wrote:
> 
> > On Wed, Feb 18, 2015 at 6:01 AM, Lee Jones  wrote:
> > > On Tue, 17 Feb 2015, Fabio Estevam wrote:
> > >
> > >> On Mon, Feb 16, 2015 at 11:38 AM, Lee Jones  wrote:
> > >>
> > >> >> +static int mx25_tsadc_setup_irq(struct platform_device *pdev,
> > >> >> + struct mx25_tsadc *tsadc)
> > >> >> +{
> > >> >> + struct device *dev = &pdev->dev;
> > >> >> + struct device_node *np = dev->of_node;
> > >> >> + int irq;
> > >> >> +
> > >> >> + irq = platform_get_irq(pdev, 0);
> > >> >> + if (irq < 0) {
> > >> >
> > >> > What if 0 is returned?
> > >>
> > >> Then  imx25.dtsi would be passing irq=0 for the ADC, which would be
> > >> totally wrong.
> > >
> > > Exactly, so it should be <=.
> > 
> > imx25.dtsi passes interrupts = <46>; for the touch screen controller,
> > so the irq number will never be zero.
> 
> It doesn't matter what happens to be passed at the moment.  The
> correct thing to do is enforce correct/full error checking.  Yes <0 is
> an error, but so is =0, so encompass it in the checks.

I now changed all irq < 0 checks to irq <= 0 under the assumption that
irq 0 is always an error.

Thanks,

Markus

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |


signature.asc
Description: Digital signature

Re: [PATCH v6 5/8] iio: adc: fsl,imx25-gcq driver

[Markus Pargmann]

Hi,

On Wed, Feb 04, 2015 at 04:48:35PM +, Jonathan Cameron wrote:
> On 29/01/15 14:09, Markus Pargmann wrote:
> > This is a conversion queue driver for the mx25 SoC. It uses the central
> > ADC which is used by two seperate independent queues. This driver
> > prepares different conversion configurations for each possible input.
> > For a conversion it creates a conversionqueue of one item with the
> > correct configuration for the chosen channel. It then executes the queue
> > once and disables the conversion queue afterwards.
> > 
> > The reference voltages are configurable through devicetree subnodes,
> > depending on the connections of the ADC inputs.
> > 
> > Signed-off-by: Markus Pargmann 
> > Signed-off-by: Denis Carikli 
> > Signed-off-by: Markus Pargmann 
> Some really small bits and bobs inline...
> Only non trivial one is that I'd prefer that the need for a regulator
> in the event of an external reference being specified was explicitly enforced.
> > ---
> >  drivers/iio/adc/Kconfig |   7 +
> >  drivers/iio/adc/Makefile|   1 +
> >  drivers/iio/adc/fsl-imx25-gcq.c | 361 
> > 
> >  include/dt-bindings/iio/adc/fsl-imx25-gcq.h |  18 ++
> >  4 files changed, 387 insertions(+)
> >  create mode 100644 drivers/iio/adc/fsl-imx25-gcq.c
> >  create mode 100644 include/dt-bindings/iio/adc/fsl-imx25-gcq.h
> > 
> > diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> > index 0f79e4725763..fccbb4bf44cc 100644
> > --- a/drivers/iio/adc/Kconfig
> > +++ b/drivers/iio/adc/Kconfig
> > @@ -143,6 +143,13 @@ config EXYNOS_ADC
> >   of SoCs for drivers such as the touchscreen and hwmon to use to share
> >   this resource.
> >  
> > +config FSL_MX25_ADC
> > +   tristate "Freescale MX25 ADC driver"
> > +   depends on MFD_MX25_TSADC
> > +   help
> > + Generic Conversion Queue driver used for general purpose ADC in the
> > + MX25. This driver supports single measurements using the MX25 ADC.
> > +
> >  config LP8788_ADC
> > tristate "LP8788 ADC driver"
> > depends on MFD_LP8788
> > diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> > index 701fdb7c96aa..acab8d956371 100644
> > --- a/drivers/iio/adc/Makefile
> > +++ b/drivers/iio/adc/Makefile
> > @@ -16,6 +16,7 @@ obj-$(CONFIG_AD799X) += ad799x.o
> >  obj-$(CONFIG_AT91_ADC) += at91_adc.o
> >  obj-$(CONFIG_AXP288_ADC) += axp288_adc.o
> >  obj-$(CONFIG_EXYNOS_ADC) += exynos_adc.o
> > +obj-$(CONFIG_FSL_MX25_ADC) += fsl-imx25-gcq.o
> >  obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
> >  obj-$(CONFIG_MAX1027) += max1027.o
> >  obj-$(CONFIG_MAX1363) += max1363.o
> > diff --git a/drivers/iio/adc/fsl-imx25-gcq.c 
> > b/drivers/iio/adc/fsl-imx25-gcq.c
> > new file mode 100644
> > index ..398e40c0e4fd
> > --- /dev/null
> > +++ b/drivers/iio/adc/fsl-imx25-gcq.c
> > @@ -0,0 +1,361 @@
> > +/*
> > + * Copyright 2014 Markus Pargmann, Pengutronix 
> > + *
> > + * The code contained herein is licensed under the GNU General Public
> > + * License. You may obtain a copy of the GNU General Public License
> > + * Version 2 or later at the following locations:
> > + *
> > + * http://www.opensource.org/licenses/gpl-license.html
> > + * http://www.gnu.org/copyleft/gpl.html
> > + *
> > + * This is the driver for the imx25 GCQ (Generic Conversion Queue)
> > + * connected to the imx25 ADC.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define MX25_GCQ_TIMEOUT (msecs_to_jiffies(2000))
> > +
> > +enum mx25_gcq_cfgs {
> > +   MX25_CFG_XP = 0,
> > +   MX25_CFG_YP,
> > +   MX25_CFG_XN,
> > +   MX25_CFG_YN,
> > +   MX25_CFG_WIPER,
> > +   MX25_CFG_INAUX0,
> > +   MX25_CFG_INAUX1,
> > +   MX25_CFG_INAUX2,
> > +   MX25_NUM_CFGS,
> > +};
> > +
> > +struct mx25_gcq_priv {
> > +   struct regmap *regs;
> > +   struct completion completed;
> > +   unsigned int settling_time;
> > +   struct clk *clk;
> > +   int irq;
> > +   struct regulator *ext_vref;
> > +   u32 channel_vref_mv[MX25_NUM_CFGS];
> > +};
> > +
> > +#define MX25_CQG_CHAN(chan, id) {\
> > +   .type = IIO_VOLTAGE,\
> > +   .indexed = 1,\
> > +   .channel = chan,\
> > +   .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),\
> > +   .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE),\
> > +   .datasheet_name = id,\
> > +}
> > +
> > +static const struct iio_chan_spec mx25_gcq_channels[MX25_NUM_CFGS] = {
> > +   MX25_CQG_CHAN(0, "xp"),
> > +   MX25_CQG_CHAN(1, "yp"),
> > +   MX25_CQG_CHAN(2, "xn"),
> > +   MX25_CQG_CHAN(3, "yn"),
> > +   MX25_CQG_CHAN(4, "wiper"),
> > +   MX25_CQG_CHAN(5, "inaux0"),
> > +   MX25_CQG_CHAN(6, "inaux1"),
> > +   MX25_CQG_CHAN(7, "inaux2"),
> > +};
> > +
> I'd be tempted to not bother separating out the next two given they
> are only used in one place each..

I removed the wrapping functions.

> > +static void mx25_gcq_disable_eoq(struct mx25_gcq_priv *priv)
> > 

Re: [RFC PATCH 1/3] eeprom: Add a simple EEPROM framework

[Srinivas Kandagatla]

On 26/02/15 13:21, Maxime Ripard wrote:

On Thu, Feb 26, 2015 at 09:16:27AM +, Srinivas Kandagatla wrote:

I think we are making simple eeprom framework too smart which will
break in future.

IMHO, Anything on top of eeprom interface that interprets the data should
not go into the eeprom framework itself, it can either live some parsers/SOC
specific drivers/interfaces.


True, but that doesn't mean that this parser support can't be built
within the framework itself.
I was more of thinking parsers/interpreters as a layer on top of this 
framework. Allowing the simplest users direct access to framework. Also 
just eeprom_read() apis would not cater for all the parsers and I think 
it would be very difficult to come up with abstracted consumer apis for 
all the parsers which could be iterator or link-lists parsers or 
something very different.





As Stephen pointed out earlier lets start with something like this, which
would provide a better abstraction to the discussed use cases like
serial-number and packed data in eeprom.

qfprom@100 {
   reg = <0x100 0x1000>;
   ranges = <0 0x100 0x1000>;
   compatible = "qcom,qfprom-msm8960"

   pvs-data: pvs-data@40 {
 compatible = "qcom,pvs-a";
 reg = <0x40 0x20>,
   };

tsens-data: tmdata@10 {
 reg = <0x10 40>;
   };

   serial-number: serial@50 {
 compatible = "qcom,serial-msm8960";
 reg = <0x50 4>, <0x60 4>;
   };

};


And I'm sorry, but I still don't get why the compatibles are needed
here.
This is an optional property, only purpose of this would be to serve as 
parser/soc-specific identifier.





and then on the consumer side:

device {
eeproms = <&serial-number>;
eeprom-names = "soc-rev-id";
};

driver side:

eeprom_get_cell()
eeprom_read();


Looks good otherwise.

thanks
--srini


Maxime


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH RFC 1/6] drm/tilcdc: Fix module unloading

[Jyri Sarha]

Force crtc dpms off before destroying the crtc instead of just
checking the dpms state. This fixes warning message and frozen picture
after tilcdc module unloading.

Signed-off-by: Jyri Sarha 
---
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index c735884..c2d5980 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -135,11 +135,12 @@ static void stop(struct drm_crtc *crtc)
tilcdc_clear(dev, LCDC_RASTER_CTRL_REG, LCDC_RASTER_ENABLE);
 }
 
+static void tilcdc_crtc_dpms(struct drm_crtc *crtc, int mode);
 static void tilcdc_crtc_destroy(struct drm_crtc *crtc)
 {
struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
 
-   WARN_ON(tilcdc_crtc->dpms == DRM_MODE_DPMS_ON);
+   tilcdc_crtc_dpms(crtc, DRM_MODE_DPMS_OFF);
 
drm_crtc_cleanup(crtc);
drm_flip_work_cleanup(&tilcdc_crtc->unref_work);
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH RFC 2/6] drm/tilcdc: Remove tilcdc slave support for tda998x driver

[Jyri Sarha]

Remove tilcdc slave support for tda998x driver. The tilcdc slave
support would conflicts with componentized use of tda998x.

Signed-off-by: Jyri Sarha 
---
 .../devicetree/bindings/drm/tilcdc/slave.txt   |  18 -
 drivers/gpu/drm/tilcdc/Makefile|   1 -
 drivers/gpu/drm/tilcdc/tilcdc_drv.c|  13 -
 drivers/gpu/drm/tilcdc/tilcdc_drv.h|   1 -
 drivers/gpu/drm/tilcdc/tilcdc_slave.c  | 411 -
 drivers/gpu/drm/tilcdc/tilcdc_slave.h  |  26 --
 6 files changed, 470 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/drm/tilcdc/slave.txt
 delete mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave.c
 delete mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave.h

diff --git a/Documentation/devicetree/bindings/drm/tilcdc/slave.txt 
b/Documentation/devicetree/bindings/drm/tilcdc/slave.txt
deleted file mode 100644
index 3d2c524..000
--- a/Documentation/devicetree/bindings/drm/tilcdc/slave.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-Device-Tree bindings for tilcdc DRM encoder slave output driver
-
-Required properties:
- - compatible: value should be "ti,tilcdc,slave".
- - i2c: the phandle for the i2c device the encoder slave is connected to
-
-Recommended properties:
- - pinctrl-names, pinctrl-0: the pincontrol settings to configure
-   muxing properly for pins that connect to TFP410 device
-
-Example:
-
-   hdmi {
-   compatible = "ti,tilcdc,slave";
-   i2c = <&i2c0>;
-   pinctrl-names = "default";
-   pinctrl-0 = <&nxp_hdmi_bonelt_pins>;
-   };
diff --git a/drivers/gpu/drm/tilcdc/Makefile b/drivers/gpu/drm/tilcdc/Makefile
index 7d2eefe..44485f9 100644
--- a/drivers/gpu/drm/tilcdc/Makefile
+++ b/drivers/gpu/drm/tilcdc/Makefile
@@ -6,7 +6,6 @@ endif
 tilcdc-y := \
tilcdc_crtc.o \
tilcdc_tfp410.o \
-   tilcdc_slave.o \
tilcdc_panel.o \
tilcdc_drv.o
 
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 095fca9..0f1e099 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -20,13 +20,11 @@
 #include "tilcdc_drv.h"
 #include "tilcdc_regs.h"
 #include "tilcdc_tfp410.h"
-#include "tilcdc_slave.h"
 #include "tilcdc_panel.h"
 
 #include "drm_fb_helper.h"
 
 static LIST_HEAD(module_list);
-static bool slave_probing;
 
 void tilcdc_module_init(struct tilcdc_module *mod, const char *name,
const struct tilcdc_module_ops *funcs)
@@ -42,11 +40,6 @@ void tilcdc_module_cleanup(struct tilcdc_module *mod)
list_del(&mod->list);
 }
 
-void tilcdc_slave_probedefer(bool defered)
-{
-   slave_probing = defered;
-}
-
 static struct of_device_id tilcdc_of_match[];
 
 static struct drm_framebuffer *tilcdc_fb_create(struct drm_device *dev,
@@ -620,10 +613,6 @@ static int tilcdc_pdev_probe(struct platform_device *pdev)
return -ENXIO;
}
 
-   /* defer probing if slave is in deferred probing */
-   if (slave_probing == true)
-   return -EPROBE_DEFER;
-
return drm_platform_init(&tilcdc_driver, pdev);
 }
 
@@ -654,7 +643,6 @@ static int __init tilcdc_drm_init(void)
 {
DBG("init");
tilcdc_tfp410_init();
-   tilcdc_slave_init();
tilcdc_panel_init();
return platform_driver_register(&tilcdc_platform_driver);
 }
@@ -664,7 +652,6 @@ static void __exit tilcdc_drm_fini(void)
DBG("fini");
platform_driver_unregister(&tilcdc_platform_driver);
tilcdc_panel_fini();
-   tilcdc_slave_fini();
tilcdc_tfp410_fini();
 }
 
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.h 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
index 7596c14..6336512 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.h
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
@@ -116,7 +116,6 @@ struct tilcdc_module {
 void tilcdc_module_init(struct tilcdc_module *mod, const char *name,
const struct tilcdc_module_ops *funcs);
 void tilcdc_module_cleanup(struct tilcdc_module *mod);
-void tilcdc_slave_probedefer(bool defered);
 
 /* Panel config that needs to be set in the crtc, but is not coming from
  * the mode timings.  The display module is expected to call
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_slave.c 
b/drivers/gpu/drm/tilcdc/tilcdc_slave.c
deleted file mode 100644
index 3775fd4..000
--- a/drivers/gpu/drm/tilcdc/tilcdc_slave.c
+++ /dev/null
@@ -1,411 +0,0 @@
-/*
- * Copyright (C) 2012 Texas Instruments
- * Author: Rob Clark 
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License version 2 as published by
- * the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
- * more details.
- *
- * You sho

[PATCH RFC 6/6] ARM: dts: am335x-boneblack: Use new binding for HDMI

[Jyri Sarha]

Use new binding for the external tda19988 HDMI encoder.

Signed-off-by: Jyri Sarha 
---
 arch/arm/boot/dts/am335x-boneblack.dts | 20 +++-
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/am335x-boneblack.dts 
b/arch/arm/boot/dts/am335x-boneblack.dts
index 5c42d25..eadbba3 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -68,16 +68,26 @@
 
 &lcdc {
status = "okay";
+   port {
+   lcdc_0: endpoint@0 {
+   remote-endpoint = <&hdmi_0>;
+   };
+   };
 };
 
-/ {
-   hdmi {
-   compatible = "ti,tilcdc,slave";
-   i2c = <&i2c0>;
+&i2c0 {
+   tda19988 {
+   compatible = "nxp,tda998x";
+   reg = <0x70>;
pinctrl-names = "default", "off";
pinctrl-0 = <&nxp_hdmi_bonelt_pins>;
pinctrl-1 = <&nxp_hdmi_bonelt_off_pins>;
-   status = "okay";
+
+   port {
+   hdmi_0: endpoint@0 {
+   remote-endpoint = <&lcdc_0>;
+   };
+   };
};
 };
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH RFC 5/6] drm/tilcdc: Force building of DRM_TILCDC_INIT

[Jyri Sarha]

If I read Documentation/kbuild/makefiles.txt section 3.6 right, this
patch should not be needed. However, without this patch the objects
needed for DRM_TILCDC_INIT are not linked, if DRM_TILCDC is built as
module.

Signed-off-by: Jyri Sarha 
---
 drivers/gpu/drm/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 2c239b9..62c6158 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -60,6 +60,7 @@ obj-$(CONFIG_DRM_RCAR_DU) += rcar-du/
 obj-$(CONFIG_DRM_SHMOBILE) +=shmobile/
 obj-$(CONFIG_DRM_OMAP) += omapdrm/
 obj-$(CONFIG_DRM_TILCDC)   += tilcdc/
+obj-$(CONFIG_DRM_TILCDC_INIT)  += tilcdc/
 obj-$(CONFIG_DRM_QXL) += qxl/
 obj-$(CONFIG_DRM_BOCHS) += bochs/
 obj-$(CONFIG_DRM_MSM) += msm/
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH RFC 3/6] drm/tilcdc: Add support for external compontised DRM encoder

[Jyri Sarha]

Add support for an external compontised DRM encoder. The external
encoder can be connected to tilcdc trough device tree graph binding.
The binding document for tilcdc has been updated. The support has only
been tested with tda998x encoder, but other encoders should work too
with a little tweaking.

I got the idea and some lines of code from Jean-Francois Moine's
"drm/tilcdc: Change the interface with the tda998x driver"-patch.

Signed-off-by: Jyri Sarha 
---
 .../devicetree/bindings/drm/tilcdc/tilcdc.txt  |  27 ++
 drivers/gpu/drm/tilcdc/Makefile|   1 +
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c   |  33 +++
 drivers/gpu/drm/tilcdc/tilcdc_drv.c|  56 ---
 drivers/gpu/drm/tilcdc/tilcdc_drv.h|   2 +
 drivers/gpu/drm/tilcdc/tilcdc_external.c   | 105 +
 drivers/gpu/drm/tilcdc/tilcdc_external.h   |  24 +
 7 files changed, 235 insertions(+), 13 deletions(-)
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_external.c
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_external.h

diff --git a/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt 
b/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt
index fff10da..2136ee8 100644
--- a/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt
+++ b/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt
@@ -18,6 +18,12 @@ Optional properties:
  - max-pixelclock: The maximum pixel clock that can be supported
by the lcd controller in KHz.
 
+Optional nodes:
+
+ - port/ports: to describe a connection to an external encoder. The
+   binding follows Documentation/devicetree/bindings/graph.txt and
+   suppors a single port with a single endpoint.
+
 Example:
 
fb: fb@4830e000 {
@@ -26,4 +32,25 @@ Example:
interrupt-parent = <&intc>;
interrupts = <36>;
ti,hwmods = "lcdc";
+
+   port {
+   lcdc_0: endpoint@0 {
+   remote-endpoint = <&hdmi_0>;
+   };
+   };
+   };
+
+   tda19988: tda19988 {
+   compatible = "nxp,tda998x";
+   reg = <0x70>;
+
+   pinctrl-names = "default", "off";
+   pinctrl-0 = <&nxp_hdmi_bonelt_pins>;
+   pinctrl-1 = <&nxp_hdmi_bonelt_off_pins>;
+
+   port {
+   hdmi_0: endpoint@0 {
+   remote-endpoint = <&lcdc_0>;
+   };
+   };
};
diff --git a/drivers/gpu/drm/tilcdc/Makefile b/drivers/gpu/drm/tilcdc/Makefile
index 44485f9..e1f738b 100644
--- a/drivers/gpu/drm/tilcdc/Makefile
+++ b/drivers/gpu/drm/tilcdc/Makefile
@@ -7,6 +7,7 @@ tilcdc-y := \
tilcdc_crtc.o \
tilcdc_tfp410.o \
tilcdc_panel.o \
+   tilcdc_external.o \
tilcdc_drv.o
 
 obj-$(CONFIG_DRM_TILCDC)   += tilcdc.o
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index c2d5980..7d07733 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -37,6 +37,9 @@ struct tilcdc_crtc {
 
/* for deferred fb unref's: */
struct drm_flip_work unref_work;
+
+   /* Only set if an external encoder is connected */
+   bool simulate_vesa_sync;
 };
 #define to_tilcdc_crtc(x) container_of(x, struct tilcdc_crtc, base)
 
@@ -214,6 +217,28 @@ static bool tilcdc_crtc_mode_fixup(struct drm_crtc *crtc,
const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode)
 {
+   struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
+
+   if (!tilcdc_crtc->simulate_vesa_sync)
+   return true;
+
+   /*
+* tilcdc does not generate VESA-compliant sync but aligns
+* VS on the second edge of HS instead of first edge.
+* We use adjusted_mode, to fixup sync by aligning both rising
+* edges and add HSKEW offset to fix the sync.
+*/
+   adjusted_mode->hskew = mode->hsync_end - mode->hsync_start;
+   adjusted_mode->flags |= DRM_MODE_FLAG_HSKEW;
+
+   if (mode->flags & DRM_MODE_FLAG_NHSYNC) {
+   adjusted_mode->flags |= DRM_MODE_FLAG_PHSYNC;
+   adjusted_mode->flags &= ~DRM_MODE_FLAG_NHSYNC;
+   } else {
+   adjusted_mode->flags |= DRM_MODE_FLAG_NHSYNC;
+   adjusted_mode->flags &= ~DRM_MODE_FLAG_PHSYNC;
+   }
+
return true;
 }
 
@@ -534,6 +559,14 @@ void tilcdc_crtc_set_panel_info(struct drm_crtc *crtc,
tilcdc_crtc->info = info;
 }
 
+void tilcdc_crtc_set_simulate_vesa_sync(struct drm_crtc *crtc,
+   bool simulate_vesa_sync)
+{
+   struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
+
+   tilcdc_crtc->simulate_vesa_sync = simulate_vesa_sync;
+}
+
 void tilcdc_crtc_update_clk(struct drm_crtc *crtc)
 {
struct tilcdc_crtc *tilcd

[PATCH RFC 4/6] drm/tilcdc: Add DRM_TILCDC_INIT for "ti,tilcdc,slave" binding support

[Jyri Sarha]

Adds a DRM_TILCDC_INIT module for "ti,tilcdc,slave" node
conversion. The implementation is in tilcdc_boot_init.c and it uses
tilcdc_slave_convert.dts as a basis for creating a DTS overlay. The
DTS overlay adds an external tda998x encoder to tilcdc that
corresponds to the old tda998x based slave encoder.

Signed-off-by: Jyri Sarha 
---
 drivers/gpu/drm/tilcdc/Kconfig  |   6 +
 drivers/gpu/drm/tilcdc/Makefile |   2 +
 drivers/gpu/drm/tilcdc/tilcdc_boot_init.c   | 270 
 drivers/gpu/drm/tilcdc/tilcdc_slave_convert.dts |  70 ++
 4 files changed, 348 insertions(+)
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_boot_init.c
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave_convert.dts

diff --git a/drivers/gpu/drm/tilcdc/Kconfig b/drivers/gpu/drm/tilcdc/Kconfig
index 8394a0b..c35d088 100644
--- a/drivers/gpu/drm/tilcdc/Kconfig
+++ b/drivers/gpu/drm/tilcdc/Kconfig
@@ -1,3 +1,8 @@
+config DRM_TILCDC_INIT
+   select OF_RESOLVE
+   select OF_OVERLAY
+   bool
+
 config DRM_TILCDC
tristate "DRM Support for TI LCDC Display Controller"
depends on DRM && OF && ARM && HAVE_DMA_ATTRS
@@ -8,6 +13,7 @@ config DRM_TILCDC
select VIDEOMODE_HELPERS
select BACKLIGHT_CLASS_DEVICE
select BACKLIGHT_LCD_SUPPORT
+   select DRM_TILCDC_INIT
help
  Choose this option if you have an TI SoC with LCDC display
  controller, for example AM33xx in beagle-bone, DA8xx, or
diff --git a/drivers/gpu/drm/tilcdc/Makefile b/drivers/gpu/drm/tilcdc/Makefile
index e1f738b..fa184a5 100644
--- a/drivers/gpu/drm/tilcdc/Makefile
+++ b/drivers/gpu/drm/tilcdc/Makefile
@@ -3,6 +3,8 @@ ifeq (, $(findstring -W,$(EXTRA_CFLAGS)))
ccflags-y += -Werror
 endif
 
+obj-$(CONFIG_DRM_TILCDC_INIT) += tilcdc_boot_init.o tilcdc_slave_convert.dtb.o
+
 tilcdc-y := \
tilcdc_crtc.o \
tilcdc_tfp410.o \
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_boot_init.c 
b/drivers/gpu/drm/tilcdc/tilcdc_boot_init.c
new file mode 100644
index 000..08f3110
--- /dev/null
+++ b/drivers/gpu/drm/tilcdc/tilcdc_boot_init.c
@@ -0,0 +1,270 @@
+/*
+ * Copyright (C) 2015 Texas Instruments
+ * Author: Jyri Sarha 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ */
+
+/*
+ * To support the old "ti,tilcdc,slave" binding the binding has to be
+ * transformed to the new external encoder binding.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct kfree_table {
+   int total;
+   int num;
+   void **table;
+};
+
+static int __init kfree_table_init(struct kfree_table *kft)
+{
+   kft->total = 128;
+   kft->num = 0;
+   kft->table = kmalloc(kft->total * sizeof(*kft->table),
+GFP_KERNEL);
+   if (!kft->table)
+   return -ENOMEM;
+
+   return 0;
+}
+
+static int __init kfree_table_add(struct kfree_table *kft, void *p)
+{
+   if (kft->num == kft->total) {
+   void *old = kft->table;
+
+   kft->total *= 2;
+   kft->table = krealloc(old, kft->total * sizeof(*kft->table),
+ GFP_KERNEL);
+   if (!kft->table) {
+   kft->table = old;
+   kfree(p);
+   return -ENOMEM;
+   }
+   }
+   kft->table[kft->num++] = p;
+   return 0;
+}
+
+static void __init kfree_table_free(struct kfree_table *kft)
+{
+   int i;
+
+   for (i = 0; i < kft->num; i++)
+   kfree(kft->table[i]);
+
+   kfree(kft->table);
+}
+
+static
+struct property * __init tilcdc_prop_dup(const struct property *prop,
+struct kfree_table *kft)
+{
+   struct property *nprop;
+
+   nprop = kzalloc(sizeof(*nprop), GFP_KERNEL);
+   if (!nprop || kfree_table_add(kft, nprop))
+   return NULL;
+
+   nprop->name = kstrdup(prop->name, GFP_KERNEL);
+   if (!nprop->name || kfree_table_add(kft, nprop->name))
+   return NULL;
+
+   nprop->value = kmemdup(prop->value, prop->length, GFP_KERNEL);
+   if (!nprop->value || kfree_table_add(kft, nprop->value))
+   return NULL;
+
+   nprop->length = prop->length;
+
+   return nprop;
+}
+
+static void __init tilcdc_copy_props(struct device_node *from,
+struct device_node *to,
+const char * const props[],
+struct kfree_table *kft)
+{
+   struct property *prop;
+   int i;
+
+   for (i = 0; props[i]; i++) {
+   prop = of_find_property(from, props[i], NULL);
+   if (!prop)
+   continue;
+
+   prop = tilcdc_prop_dup(prop, kft);
+   if

[PATCH RFC 0/6] Use DRM component API in tilcdc to connect to tda998x

[Jyri Sarha]

Remove tilcdc slave support and connect to tda998x trough its
component DRM API. For dtb backward compatibility the code creates at
boot time a DT overlay based on the earlier binding. The overlay
conforms to the new graph based binding.

The first patch is just a bugfix and can be applied or dropped
independenty.

Jyri Sarha (6):
  drm/tilcdc: Fix module unloading
  drm/tilcdc: Remove tilcdc slave support for tda998x driver
  drm/tilcdc: Add support for external compontised DRM encoder
  drm/tilcdc: Add DRM_TILCDC_INIT for "ti,tilcdc,slave" binding support
  drm/tilcdc: Force building of DRM_TILCDC_INIT
  ARM: dts: am335x-boneblack: Use new binding for HDMI

 .../devicetree/bindings/drm/tilcdc/slave.txt   |  18 -
 .../devicetree/bindings/drm/tilcdc/tilcdc.txt  |  27 ++
 arch/arm/boot/dts/am335x-boneblack.dts |  20 +-
 drivers/gpu/drm/Makefile   |   1 +
 drivers/gpu/drm/tilcdc/Kconfig |   6 +
 drivers/gpu/drm/tilcdc/Makefile|   4 +-
 drivers/gpu/drm/tilcdc/tilcdc_boot_init.c  | 270 ++
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c   |  36 +-
 drivers/gpu/drm/tilcdc/tilcdc_drv.c|  69 ++--
 drivers/gpu/drm/tilcdc/tilcdc_drv.h|   3 +-
 drivers/gpu/drm/tilcdc/tilcdc_external.c   | 105 ++
 drivers/gpu/drm/tilcdc/tilcdc_external.h   |  24 ++
 drivers/gpu/drm/tilcdc/tilcdc_slave.c  | 411 -
 drivers/gpu/drm/tilcdc/tilcdc_slave.h  |  26 --
 drivers/gpu/drm/tilcdc/tilcdc_slave_convert.dts|  70 
 15 files changed, 601 insertions(+), 489 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/drm/tilcdc/slave.txt
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_boot_init.c
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_external.c
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_external.h
 delete mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave.c
 delete mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave.h
 create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave_convert.dts

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 3/3] of: support passing console options with stdout-path

[Andrew Lunn]

> Sorry if I was unclear. My question was not _whether_ to fix this
> for earlycon, but rather _how_.
> 
> IOW, is the ':' character accepted as a path terminator for
> 1. all nodes, so fix this in fdt_path_offset();
> 2. only chosen nodes;
> 3. unique to stdout-path, so fix this in early_init_dt_scan_chosen_serial()?

Ah, sorry.

The ':' character is accepted as a path terminator for stdout-path and
stdin-path within chosen node. It does not appear to be mentioned
anywhere else in the standard.

 Andrew
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 6/6] hwmon: pwm-fan: Code for using PWM FAN as a cooling device

[Lukasz Majewski]

Hi Guenter,

> On 02/26/2015 05:59 AM, Lukasz Majewski wrote:
> > The PWM FAN device can now be used as a thermal cooling device.
> > Necessary infrastructure has been added in this commit.
> >
> > Signed-off-by: Lukasz Majewski 
> > Acked-by: Eduardo Valentin 
> > ---
> > Changes for v2:
> > - Replace pwm_fan_cooling_states with pwm_fan_cooling_levels
> > - Update ctx->pwm_fan_state when correct data from device tree is
> > available
> > - Using therma_cdev_update() when thermal is ready for controlling
> > the fan Changes for v3:
> > - Rename patch heading
> > - pwm_fan_of_get_cooling_data() now returns -EINVAL when no
> > "cooling-levels" property defined
> > - register of cooling device only when proper cooling data is
> > present Changes for v4:
> > - None
> > Changes for v5:
> > - Check for IS_ENABLED(CONFIG_THERMAL) has been added to prevent
> > from executing thermal_* specific functions
> > Changes for v6:
> > - Adding missing ctx == NULL check in pwm_fan_get_max_state()
> > - Call to thermal_cooling_device_unregister(ctx->cdev); at
> > pwm_fan_remove()
> > - struct thermal_cooling_device *cdev; added to struct pwm_fan_ctx
> > ---
> >   drivers/hwmon/pwm-fan.c | 89
> > - 1 file changed,
> > 88 insertions(+), 1 deletion(-)
> [ ... ]
> >
> > @@ -200,6 +286,7 @@ static int pwm_fan_remove(struct
> > platform_device *pdev) {
> > struct pwm_fan_ctx *ctx = platform_get_drvdata(pdev);
> >
> > +   thermal_cooling_device_unregister(ctx->cdev);
> 
> Unfortunately there is still no prototype for this if CONFIG_THERMAL
> is not configured.

Yes... since Nishanth Menon's changes are now only in
linux-soc-thermal/fixes

> 
> Two options: Yet another revision, or wait a week until the prototypes
> are (hopefully) available and submit a patch without the conditionals.

No problem, I will wait a bit and resend this patch set.

> 
> Guenter
> 

-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 6/8] input: touchscreen: imx25 tcq driver

[Markus Pargmann]

Hi,

On Mon, Feb 02, 2015 at 09:51:34AM -0800, Dmitry Torokhov wrote:
> On Mon, Feb 02, 2015 at 05:05:39PM +0100, Markus Pargmann wrote:
> > Hi,
> > 
> > On Fri, Jan 30, 2015 at 10:57:21AM -0800, Dmitry Torokhov wrote:
> > > On Thu, Jan 29, 2015 at 07:56:40PM +0530, Varka Bhadram wrote:
> > > > Hi,
> > > > 
> > > > On Thursday 29 January 2015 07:39 PM, Markus Pargmann wrote:
> > > > >This is a driver for the imx25 ADC/TSC module. It controls the
> > > > >touchscreen conversion queue and creates a touchscreen input device.
> > > > >The driver currently only supports 4 wire touchscreens. The driver uses
> > > > >a simple conversion queue of precharge, touch detection, X measurement,
> > > > >Y measurement, precharge and another touch detection.
> > > > >
> > > > >This driver uses the regmap from the parent to setup some touch 
> > > > >specific
> > > > >settings in the core driver and setup a idle configuration with touch
> > > > >detection.
> > > > >
> > > > >Signed-off-by: Markus Pargmann 
> > > > >Signed-off-by: Denis Carikli 
> > > > >Acked-by: Dmitry Torokhov 
> > > > >Signed-off-by: Markus Pargmann 
> > > > >---
> > > > >  drivers/input/touchscreen/Kconfig |   6 +
> > > > >  drivers/input/touchscreen/Makefile|   1 +
> > > > >  drivers/input/touchscreen/fsl-imx25-tcq.c | 587 
> > > > > ++
> > > > >  3 files changed, 594 insertions(+)
> > > > >  create mode 100644 drivers/input/touchscreen/fsl-imx25-tcq.c
> > > > >
> > > > (...)
> > > > 
> > > > >+  ret = request_threaded_irq(priv->irq, mx25_tcq_irq, 
> > > > >mx25_tcq_irq_thread,
> > > > >+ IRQF_ONESHOT, pdev->name, priv);
> > > > 
> > > > We can use devres API for request_thread_irq()...
> > > > 
> > > > >+  if (ret) {
> > > > >+  dev_err(dev, "Failed requesting IRQ\n");
> > > > >+  goto err_clk_unprepare;
> > > > >+  }
> > > > >+
> > > > >+  ret = mx25_tcq_init(priv);
> > > > >+  if (ret) {
> > > > >+  dev_err(dev, "Failed to init tcq\n");
> > > > >+  goto error_free_irq;
> > > > >+  }
> > > > >+
> > > > >+  platform_set_drvdata(pdev, priv);
> > > > >+
> > > > >+  return 0;
> > > > >+
> > > > >+error_free_irq:
> > > > >+  free_irq(priv->irq, priv);
> > > > 
> > > > This is not required if we use devres API
> > > 
> > > Yes it does - you do not really want to stop clocks in the middle of
> > > servicing interrupt.
> > 
> > Thanks, I missed the clocks. I will not use devm here then.
> 
> Actually, you still can if you move clock enabling/disabling and
> mx25_tcq_init() into input_dev->open() and ->close() callbacks. Close
> will be called during input device un-registration which happens (given
> your current sequence) after freeing irq by devm.

Thank you. I now moved that code into open() and close(), replaced the
irq_request() with devm_irq_request. mx25_tcq_remove() is gone now.

> 
> By the way, I used my old @vmware address by accident. Can you please
> replace the original acked by with:
> 
> Acked-by: Dmitry Torokhov 

Replaced it.

Thanks,

Markus

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |


signature.asc
Description: Digital signature

Re: [PATCH v6 1/3] dmaengine: Add support for APM X-Gene SoC DMA engine driver

[Ben Dooks]

On 26/02/15 12:31, Rameshwar Sahu wrote:
> Hi Vinod,
> 
> 
> On Tue, Feb 24, 2015 at 6:23 PM, Rameshwar Prasad Sahu  wrote:
>> This patch implements the APM X-Gene SoC DMA engine driver. The APM X-Gene
>> SoC DMA engine consists of 4 DMA channels for performing DMA operations.
>> These DMA operations include memory copy and scatter-gather memory copy
>> offloading.
>>
>> Signed-off-by: Rameshwar Prasad Sahu 
>> Signed-off-by: Loc Ho 
>> ---
>>  drivers/dma/Kconfig |8 +
>>  drivers/dma/Makefile|1 +
>>  drivers/dma/xgene-dma.c | 1738 
>> +++
>>  3 files changed, 1747 insertions(+)
>>  create mode 100755 drivers/dma/xgene-dma.c
>>
>> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
>> index a874b6e..0e05831 100644
>> --- a/drivers/dma/Kconfig
>> +++ b/drivers/dma/Kconfig
>> @@ -425,6 +425,14 @@ config IMG_MDC_DMA
>> help
>>   Enable support for the IMG multi-threaded DMA controller (MDC).
>>
>> +config XGENE_DMA
>> +   tristate "APM X-Gene DMA support"
>> +   depends on ARCH_XGENE
>> +   select DMA_ENGINE
>> +   select ASYNC_TX_ENABLE_CHANNEL_SWITCH
>> +   help
>> + Enable support for the APM X-Gene SoC DMA engine.
>> +
>>  config DMA_ENGINE
>> bool
>>
>> diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
>> index f915f61..06c1576 100644
>> --- a/drivers/dma/Makefile
>> +++ b/drivers/dma/Makefile
>> @@ -51,3 +51,4 @@ obj-$(CONFIG_INTEL_MIC_X100_DMA) += mic_x100_dma.o
>>  obj-$(CONFIG_NBPFAXI_DMA) += nbpfaxi.o
>>  obj-$(CONFIG_DMA_SUN6I) += sun6i-dma.o
>>  obj-$(CONFIG_IMG_MDC_DMA) += img-mdc-dma.o
>> +obj-$(CONFIG_XGENE_DMA) += xgene-dma.o
>> diff --git a/drivers/dma/xgene-dma.c b/drivers/dma/xgene-dma.c
>> new file mode 100755
>> index 000..e736c2e
>> --- /dev/null
>> +++ b/drivers/dma/xgene-dma.c
>> @@ -0,0 +1,1738 @@
>> +/*
>> + * Applied Micro X-Gene SoC DMA engine Driver
>> + *
>> + * Copyright (c) 2015, Applied Micro Circuits Corporation
>> + * Authors: Rameshwar Prasad Sahu 
>> + * Loc Ho 
>> + *
>> + * 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.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program.  If not, see .
>> + *
>> + * NOTE: PM support is currently not available.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include "dmaengine.h"
>> +
>> +/* DMA ring csr registers and bit definations */
>> +#define DMA_RING_CONFIG0x04
>> +#define DMA_RING_ENABLEBIT(31)
>> +#define DMA_RING_ID0x08
>> +#define DMA_RING_ID_SETUP(v)   ((v) | BIT(31))
>> +#define DMA_RING_ID_BUF0x0C
>> +#define DMA_RING_ID_BUF_SETUP(v)   (((v) << 9) | BIT(21))
>> +#define DMA_RING_THRESLD0_SET1 0x30
>> +#define DMA_RING_THRESLD0_SET1_VAL 0X64
>> +#define DMA_RING_THRESLD1_SET1 0x34
>> +#define DMA_RING_THRESLD1_SET1_VAL 0xC8
>> +#define DMA_RING_HYSTERESIS0x68
>> +#define DMA_RING_HYSTERESIS_VAL0x
>> +#define DMA_RING_STATE 0x6C
>> +#define DMA_RING_STATE_WR_BASE 0x70
>> +#define DMA_RING_NE_INT_MODE   0x017C
>> +#define DMA_RING_NE_INT_MODE_SET(m, v) \
>> +   ((m) = ((m) & ~BIT(31 - (v))) | BIT(31 - (v)))
>> +#define DMA_RING_NE_INT_MODE_RESET(m, v)   \
>> +   ((m) &= (~BIT(31 - (v
>> +#define DMA_RING_CLKEN 0xC208
>> +#define DMA_RING_SRST  0xC200
>> +#define DMA_RING_MEM_RAM_SHUTDOWN  0xD070
>> +#define DMA_RING_BLK_MEM_RDY   0xD074
>> +#define DMA_RING_BLK_MEM_RDY_VAL   0x
>> +#define DMA_RING_DESC_CNT(v)   (((v) & 0x0001FFFE) >> 1)
>> +#define DMA_RING_ID_GET(owner, num)(((owner) << 6) | (num))
>> +#define DMA_RING_DST_ID(v) ((1 << 10) | (v))
>> +#define DMA_RING_CMD_OFFSET0x2C
>> +#define DMA_RING_CMD_BASE_OFFSET(v)((v) << 6)
>> +#define DMA_RING_COHERENT_SET(m)   (((u32 *)(m))[2] |= BIT(4))
>> +#define DMA_RING_ADDRL_SET(m, v)   (((u32 *)(m))[2] |= (((v) >> 8) << 
>> 5))
>> +#define DMA_RING_ADDRH_SET(m, v)   (((u32 *)(m))[3] |= ((v) >> 35))
>> +#define DMA_RING_ACCEPTLERR_SET(m) (((u32 *)(m))[3] |= BIT(19))
>> +#define DMA_RING_SIZE_SET(m, v)(((u32 *)(m))[3] |= ((v) << 
>> 23))
>> +#defin

Re: [PATCH v6 6/6] hwmon: pwm-fan: Code for using PWM FAN as a cooling device

[Guenter Roeck]

On 02/26/2015 05:59 AM, Lukasz Majewski wrote:

The PWM FAN device can now be used as a thermal cooling device. Necessary
infrastructure has been added in this commit.

Signed-off-by: Lukasz Majewski 
Acked-by: Eduardo Valentin 
---
Changes for v2:
- Replace pwm_fan_cooling_states with pwm_fan_cooling_levels
- Update ctx->pwm_fan_state when correct data from device tree is available
- Using therma_cdev_update() when thermal is ready for controlling the fan
Changes for v3:
- Rename patch heading
- pwm_fan_of_get_cooling_data() now returns -EINVAL when no "cooling-levels"
   property defined
- register of cooling device only when proper cooling data is present
Changes for v4:
- None
Changes for v5:
- Check for IS_ENABLED(CONFIG_THERMAL) has been added to prevent from
   executing thermal_* specific functions
Changes for v6:
- Adding missing ctx == NULL check in pwm_fan_get_max_state()
- Call to thermal_cooling_device_unregister(ctx->cdev); at pwm_fan_remove()
- struct thermal_cooling_device *cdev; added to struct pwm_fan_ctx
---
  drivers/hwmon/pwm-fan.c | 89 -
  1 file changed, 88 insertions(+), 1 deletion(-)

[ ... ]


@@ -200,6 +286,7 @@ static int pwm_fan_remove(struct platform_device *pdev)
  {
struct pwm_fan_ctx *ctx = platform_get_drvdata(pdev);

+   thermal_cooling_device_unregister(ctx->cdev);


Unfortunately there is still no prototype for this if CONFIG_THERMAL
is not configured.

Two options: Yet another revision, or wait a week until the prototypes
are (hopefully) available and submit a patch without the conditionals.

Guenter

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6 2/6] ARM: dts: Add pwm-fan node to the Odroid-U3 board

[Lukasz Majewski]

From: Kamil Debski 

Add pwm-fan node to the Odroid-U3 board file to enable PWM control of the
cooling fan. In addition, add the "pwm" label to the pwm@139D node
in the exynos4412.dtsi.

Signed-off-by: Kamil Debski 
Signed-off-by: Lukasz Majewski 
---
Changes since v1:
- added pwm label to the pwm@139D node in exynos4.dtsi
- use the pwm label in the exynos4412-odroidu3.dts
- change order or properties in the pwn-fan node, to be sorted
  in alphabetical order
Changes for v5:
- Adding Signed-off-by: Lukasz Majewski 
- status = "okay"; dropped from the patch
Changes for v6:
- None

---
 arch/arm/boot/dts/exynos4.dtsi|  2 +-
 arch/arm/boot/dts/exynos4412-odroidu3.dts | 12 
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 690f56c..a93f5ca5 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -599,7 +599,7 @@
status = "disabled";
};
 
-   pwm@139D {
+   pwm: pwm@139D {
compatible = "samsung,exynos4210-pwm";
reg = <0x139D 0x1000>;
interrupts = <0 37 0>, <0 38 0>, <0 39 0>, <0 40 0>, <0 41 0>;
diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts 
b/arch/arm/boot/dts/exynos4412-odroidu3.dts
index 44684e5..4c04837 100644
--- a/arch/arm/boot/dts/exynos4412-odroidu3.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts
@@ -31,6 +31,18 @@
linux,default-trigger = "heartbeat";
};
};
+
+   pwm-fan {
+   compatible = "pwm-fan";
+   pwms = <&pwm 0 1 0>;
+   };
+};
+
+&pwm {
+   pinctrl-0 = <&pwm0_out>;
+   pinctrl-names = "default";
+   samsung,pwm-outputs = <0>;
+   status = "okay";
 };
 
 &usb3503 {
-- 
2.0.0.rc2

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6 1/6] Documentation: dts: Documentation entry to explain how to use PWM FAN as a cooling device

[Lukasz Majewski]

Explanation of several properties, which allow PWM fan working as a cooling
device, have been embraced in this commit.

Signed-off-by: Lukasz Majewski 
Acked-by: Eduardo Valentin 
---
Changes for v2:
- Rename cooling-pwm-values to cooling-levels
- Remove default-pulse-width property and stick to default hwmon policy
Changes for v3:
- Changing commit title from "hwmon: dts: Doc:" to "Documentation: dts"
- Remove unnecessary properties
- Set maximal cooling level to 230 instead of 255
Changes for v4:
- None
Changes for v5:
- Move thermal-zones description to example section
- Extending example section
Changes for v6:
- cooling-{min|max}-state properties added to pwm-fan binding
- Mandatory properties for thermal-zones added
- Indentation fixed
---
 .../devicetree/bindings/hwmon/pwm-fan.txt  | 29 --
 1 file changed, 27 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/hwmon/pwm-fan.txt 
b/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
index 610757c..c6d5332 100644
--- a/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
+++ b/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
@@ -3,10 +3,35 @@ Bindings for a fan connected to the PWM lines
 Required properties:
 - compatible   : "pwm-fan"
 - pwms : the PWM that is used to control the PWM fan
+- cooling-levels  : PWM duty cycle values in a range from 0 to 255
+   which correspond to thermal cooling states
 
 Example:
-   pwm-fan {
+   fan0: pwm-fan {
compatible = "pwm-fan";
-   status = "okay";
+   cooling-min-state = <0>;
+   cooling-max-state = <3>;
+   #cooling-cells = <2>;
pwms = <&pwm 0 1 0>;
+   cooling-levels = <0 102 170 230>;
};
+
+   thermal-zones {
+   cpu_thermal: cpu-thermal {
+thermal-sensors = <&tmu 0>;
+polling-delay-passive = <0>;
+polling-delay = <0>;
+trips {
+   cpu_alert1: cpu-alert1 {
+   temperature = <10>; /* 
millicelsius */
+   hysteresis = <2000>; /* 
millicelsius */
+   type = "passive";
+   };
+};
+cooling-maps {
+   map0 {
+   trip = <&cpu_alert1>;
+   cooling-device = <&fan0 0 
1>;
+   };
+};
+   };
-- 
2.0.0.rc2

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6 3/6] ARM: dts: Add properties to use pwm-fan device as a cooling device in Odroid U3

[Lukasz Majewski]

With those bindings it is possible to use pwm-fan device available in
Odroid U3 as a cooling device.

Signed-off-by: Lukasz Majewski 
Acked-by: Eduardo Valentin 
---
Changes for v2:
- Rename cooling-pwm-values property to cooling-levels
Changes for v3:
- Change patch's topic to "ARM dts"
- Reduce maximal cooling-level to 230 from 255
Changes for v4:
- None
Changes for v5:
- None
Changes for v6:
- None
---
 arch/arm/boot/dts/exynos4412-odroidu3.dts | 33 ++-
 1 file changed, 32 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts 
b/arch/arm/boot/dts/exynos4412-odroidu3.dts
index 4c04837..abcfa3c 100644
--- a/arch/arm/boot/dts/exynos4412-odroidu3.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts
@@ -32,9 +32,40 @@
};
};
 
-   pwm-fan {
+   fan0: pwm-fan {
compatible = "pwm-fan";
pwms = <&pwm 0 1 0>;
+   cooling-min-state = <0>;
+   cooling-max-state = <3>;
+   #cooling-cells = <2>;
+   cooling-levels = <0 102 170 230>;
+   };
+
+   thermal-zones {
+   cpu_thermal: cpu-thermal {
+   cooling-maps {
+   map0 {
+trip = <&cpu_alert1>;
+cooling-device = <&cpu0 7 7>;
+   };
+   map1 {
+trip = <&cpu_alert2>;
+cooling-device = <&cpu0 13 13>;
+   };
+   map2 {
+trip = <&cpu_alert0>;
+cooling-device = <&fan0 0 1>;
+   };
+   map3 {
+trip = <&cpu_alert1>;
+cooling-device = <&fan0 1 2>;
+   };
+   map4 {
+trip = <&cpu_alert2>;
+cooling-device = <&fan0 2 3>;
+   };
+   };
+   };
};
 };
 
-- 
2.0.0.rc2

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 3/3] of: support passing console options with stdout-path

[Peter Hurley]

Hi Andrew,

On 02/26/2015 08:46 AM, Andrew Lunn wrote:
> On Thu, Feb 26, 2015 at 06:55:22AM -0500, Peter Hurley wrote:
>> On 11/27/2014 12:56 PM, Leif Lindholm wrote:
>>> Support specifying console options (like with console=ttyXN,)
>>> by appending them to the stdout-path property after a separating ':'.
>>>
>>> Example:
>>> stdout-path = "uart0:115200";
>>
>> This format breaks DT earlycon because libfdt doesn't recognize ':' as a
>> path terminator.
>>
>> It's simple enough to fix this directly in early_init_dt_scan_chosen_serial()
>> but perhaps it would better to teach fdt_path_offset() to recognize ':'?
> 
> Hi Peter
> 
> ePAPR says for stdout-path in Chosen:
> 
> A string that specifies the full path to the node representing the
> device to be used for boot console output. If the character ":" is
> present in the value it terminates the path. The value may be an
> alias.
> 
> So it is probably wise to implement this properly.

Sorry if I was unclear. My question was not _whether_ to fix this
for earlycon, but rather _how_.

IOW, is the ':' character accepted as a path terminator for
1. all nodes, so fix this in fdt_path_offset();
2. only chosen nodes;
3. unique to stdout-path, so fix this in early_init_dt_scan_chosen_serial()?

Regards,
Peter Hurley

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6 6/6] hwmon: pwm-fan: Code for using PWM FAN as a cooling device

[Lukasz Majewski]

The PWM FAN device can now be used as a thermal cooling device. Necessary
infrastructure has been added in this commit.

Signed-off-by: Lukasz Majewski 
Acked-by: Eduardo Valentin 
---
Changes for v2:
- Replace pwm_fan_cooling_states with pwm_fan_cooling_levels
- Update ctx->pwm_fan_state when correct data from device tree is available
- Using therma_cdev_update() when thermal is ready for controlling the fan
Changes for v3:
- Rename patch heading
- pwm_fan_of_get_cooling_data() now returns -EINVAL when no "cooling-levels"
  property defined
- register of cooling device only when proper cooling data is present
Changes for v4:
- None
Changes for v5:
- Check for IS_ENABLED(CONFIG_THERMAL) has been added to prevent from
  executing thermal_* specific functions
Changes for v6:
- Adding missing ctx == NULL check in pwm_fan_get_max_state()
- Call to thermal_cooling_device_unregister(ctx->cdev); at pwm_fan_remove()
- struct thermal_cooling_device *cdev; added to struct pwm_fan_ctx
---
 drivers/hwmon/pwm-fan.c | 89 -
 1 file changed, 88 insertions(+), 1 deletion(-)

diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm-fan.c
index e6ed353..7c83dc4 100644
--- a/drivers/hwmon/pwm-fan.c
+++ b/drivers/hwmon/pwm-fan.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define MAX_PWM 255
 
@@ -34,6 +35,7 @@ struct pwm_fan_ctx {
unsigned int pwm_fan_state;
unsigned int pwm_fan_max_state;
unsigned int *pwm_fan_cooling_levels;
+   struct thermal_cooling_device *cdev;
 };
 
 static int  __set_pwm(struct pwm_fan_ctx *ctx, unsigned long pwm)
@@ -68,6 +70,17 @@ exit_set_pwm_err:
return ret;
 }
 
+static void pwm_fan_update_state(struct pwm_fan_ctx *ctx, unsigned long pwm)
+{
+   int i;
+
+   for (i = 0; i < ctx->pwm_fan_max_state; ++i)
+   if (pwm < ctx->pwm_fan_cooling_levels[i + 1])
+   break;
+
+   ctx->pwm_fan_state = i;
+}
+
 static ssize_t set_pwm(struct device *dev, struct device_attribute *attr,
   const char *buf, size_t count)
 {
@@ -82,6 +95,7 @@ static ssize_t set_pwm(struct device *dev, struct 
device_attribute *attr,
if (ret)
return ret;
 
+   pwm_fan_update_state(ctx, pwm);
return count;
 }
 
@@ -103,6 +117,62 @@ static struct attribute *pwm_fan_attrs[] = {
 
 ATTRIBUTE_GROUPS(pwm_fan);
 
+/* thermal cooling device callbacks */
+static int pwm_fan_get_max_state(struct thermal_cooling_device *cdev,
+unsigned long *state)
+{
+   struct pwm_fan_ctx *ctx = cdev->devdata;
+
+   if (!ctx)
+   return -EINVAL;
+
+   *state = ctx->pwm_fan_max_state;
+
+   return 0;
+}
+
+static int pwm_fan_get_cur_state(struct thermal_cooling_device *cdev,
+unsigned long *state)
+{
+   struct pwm_fan_ctx *ctx = cdev->devdata;
+
+   if (!ctx)
+   return -EINVAL;
+
+   *state = ctx->pwm_fan_state;
+
+   return 0;
+}
+
+static int
+pwm_fan_set_cur_state(struct thermal_cooling_device *cdev, unsigned long state)
+{
+   struct pwm_fan_ctx *ctx = cdev->devdata;
+   int ret;
+
+   if (!ctx || (state > ctx->pwm_fan_max_state))
+   return -EINVAL;
+
+   if (state == ctx->pwm_fan_state)
+   return 0;
+
+   ret = __set_pwm(ctx, ctx->pwm_fan_cooling_levels[state]);
+   if (ret) {
+   dev_err(&cdev->device, "Cannot set pwm!\n");
+   return ret;
+   }
+
+   ctx->pwm_fan_state = state;
+
+   return ret;
+}
+
+static const struct thermal_cooling_device_ops pwm_fan_cooling_ops = {
+   .get_max_state = pwm_fan_get_max_state,
+   .get_cur_state = pwm_fan_get_cur_state,
+   .set_cur_state = pwm_fan_set_cur_state,
+};
+
 int pwm_fan_of_get_cooling_data(struct device *dev, struct pwm_fan_ctx *ctx)
 {
struct device_node *np = dev->of_node;
@@ -145,8 +215,9 @@ int pwm_fan_of_get_cooling_data(struct device *dev, struct 
pwm_fan_ctx *ctx)
 
 static int pwm_fan_probe(struct platform_device *pdev)
 {
-   struct device *hwmon;
+   struct thermal_cooling_device *cdev;
struct pwm_fan_ctx *ctx;
+   struct device *hwmon;
int duty_cycle;
int ret;
 
@@ -193,6 +264,21 @@ static int pwm_fan_probe(struct platform_device *pdev)
if (ret)
return ret;
 
+   ctx->pwm_fan_state = ctx->pwm_fan_max_state;
+   if (IS_ENABLED(CONFIG_THERMAL)) {
+   cdev = thermal_of_cooling_device_register(pdev->dev.of_node,
+ "pwm-fan", ctx,
+ &pwm_fan_cooling_ops);
+   if (IS_ERR(cdev)) {
+   dev_err(&pdev->dev,
+   "Failed to register pwm-fan as cooling device");
+   pwm_disable(ctx->pwm);
+   r

[PATCH v6 4/6] hwmon: pwm-fan: Extract __set_pwm() function to only modify PWM duty cycle

[Lukasz Majewski]

It was necessary to decouple code handling writing to sysfs from the one
responsible for setting PWM of the fan.
Due to that, new __set_pwm() method was extracted, which is responsible for
only setting new PWM duty cycle.

Signed-off-by: Lukasz Majewski 
---
Changes for v2:
- None
Changes for v3:
- The commit headline has been reedited.
Changes for v4:
- Protect "if (ctx->pwm_value == pwm)" with ctx lock
- Initialize ret with zero
Changes for v5:
- None
Changes for v6:
- None
---
 drivers/hwmon/pwm-fan.c | 33 +
 1 file changed, 21 insertions(+), 12 deletions(-)

diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm-fan.c
index 1991d903..bd42d39 100644
--- a/drivers/hwmon/pwm-fan.c
+++ b/drivers/hwmon/pwm-fan.c
@@ -33,20 +33,14 @@ struct pwm_fan_ctx {
unsigned char pwm_value;
 };
 
-static ssize_t set_pwm(struct device *dev, struct device_attribute *attr,
-  const char *buf, size_t count)
+static int  __set_pwm(struct pwm_fan_ctx *ctx, unsigned long pwm)
 {
-   struct pwm_fan_ctx *ctx = dev_get_drvdata(dev);
-   unsigned long pwm, duty;
-   ssize_t ret;
-
-   if (kstrtoul(buf, 10, &pwm) || pwm > MAX_PWM)
-   return -EINVAL;
+   unsigned long duty;
+   int ret = 0;
 
mutex_lock(&ctx->lock);
-
if (ctx->pwm_value == pwm)
-   goto exit_set_pwm_no_change;
+   goto exit_set_pwm_err;
 
if (pwm == 0) {
pwm_disable(ctx->pwm);
@@ -66,13 +60,28 @@ static ssize_t set_pwm(struct device *dev, struct 
device_attribute *attr,
 
 exit_set_pwm:
ctx->pwm_value = pwm;
-exit_set_pwm_no_change:
-   ret = count;
 exit_set_pwm_err:
mutex_unlock(&ctx->lock);
return ret;
 }
 
+static ssize_t set_pwm(struct device *dev, struct device_attribute *attr,
+  const char *buf, size_t count)
+{
+   struct pwm_fan_ctx *ctx = dev_get_drvdata(dev);
+   unsigned long pwm;
+   int ret;
+
+   if (kstrtoul(buf, 10, &pwm) || pwm > MAX_PWM)
+   return -EINVAL;
+
+   ret = __set_pwm(ctx, pwm);
+   if (ret)
+   return ret;
+
+   return count;
+}
+
 static ssize_t show_pwm(struct device *dev,
struct device_attribute *attr, char *buf)
 {
-- 
2.0.0.rc2

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html