[PATCH v2 07/10] hwmon: Support sensors exported via ARM SCP interface
Create a driver to add support for SoC sensors exported by the System
Control Processor (SCP) via the System Control and Power Interface
(SCPI). The supported sensor types is one of voltage, temperature,
current, and power.
The sensor labels and values provided by the SCP are exported via the
hwmon sysfs interface.
Signed-off-by: Punit Agrawal punit.agra...@arm.com
Cc: Jean Delvare jdelv...@suse.de
Cc: Guenter Roeck li...@roeck-us.net
Cc: Sudeep Holla sudeep.ho...@arm.com
---
Documentation/hwmon/scpi-hwmon | 33
drivers/hwmon/Kconfig | 8 ++
drivers/hwmon/Makefile | 1 +
drivers/hwmon/scpi-hwmon.c | 183 +
4 files changed, 225 insertions(+)
create mode 100644 Documentation/hwmon/scpi-hwmon
create mode 100644 drivers/hwmon/scpi-hwmon.c
diff --git a/Documentation/hwmon/scpi-hwmon b/Documentation/hwmon/scpi-hwmon
new file mode 100644
index 000..4cfcdf2d
--- /dev/null
+++ b/Documentation/hwmon/scpi-hwmon
@@ -0,0 +1,33 @@
+Kernel driver scpi-hwmon
+
+
+Supported chips:
+ * Chips based on ARM System Control Processor Interface
+ Addresses scanned: -
+ Datasheet:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0922b/index.html
+
+Author: Punit Agrawal punit.agra...@arm.com
+
+Description
+---
+
+This driver supports hardware monitoring for SoC's based on the ARM
+System Control Processor (SCP) implementing the System Control
+Processor Interface (SCPI). The following sensor types are supported
+by the SCP -
+
+ * temperature
+ * voltage
+ * current
+ * power
+
+The SCP interface provides an API to query the available sensors and
+their values which are then exported to userspace by this driver.
+
+Usage Notes
+---
+
+The driver relies on device tree node to indicate the presence of SCPI
+support in the kernel. See
+Documentation/devicetree/bindings/arm/arm,scpi.txt for details of the
+devicetree node.
\ No newline at end of file
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 4943c3c..c9714b0 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1551,6 +1551,14 @@ config SENSORS_VEXPRESS
the ARM Ltd's Versatile Express platform. It can provide wide
range of information like temperature, power, energy.
+config SENSORS_ARM_SCPI
+ tristate ARM SCPI Sensors
+ depends on ARM_SCPI_PROTOCOL
+ help
+ This driver provides support for temperature, voltage, current
+ and power sensors available on ARM Ltd's SCP based platforms. The
+ actual number and type of sensors exported depend the platform.
+
config SENSORS_VIA_CPUTEMP
tristate VIA CPU temperature sensor
depends on X86
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 8aba87f..4961710 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -150,6 +150,7 @@ obj-$(CONFIG_SENSORS_TMP421)+= tmp421.o
obj-$(CONFIG_SENSORS_TWL4030_MADC)+= twl4030-madc-hwmon.o
obj-$(CONFIG_SENSORS_V2M_JUNO) += v2m-juno.o
obj-$(CONFIG_SENSORS_VEXPRESS) += vexpress.o
+obj-$(CONFIG_SENSORS_ARM_SCPI) += scpi-hwmon.o
obj-$(CONFIG_SENSORS_VIA_CPUTEMP)+= via-cputemp.o
obj-$(CONFIG_SENSORS_VIA686A) += via686a.o
obj-$(CONFIG_SENSORS_VT1211) += vt1211.o
diff --git a/drivers/hwmon/scpi-hwmon.c b/drivers/hwmon/scpi-hwmon.c
new file mode 100644
index 000..7e7e06b
--- /dev/null
+++ b/drivers/hwmon/scpi-hwmon.c
@@ -0,0 +1,183 @@
+/*
+ * System Control and Power Interface(SCPI) based hwmon sensor driver
+ *
+ * Copyright (C) 2015 ARM Ltd.
+ * Punit Agrawal punit.agra...@arm.com
+ *
+ * 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 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 linux/hwmon.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/scpi_protocol.h
+#include linux/slab.h
+#include linux/sysfs.h
+
+struct sensor_data {
+ struct scpi_sensor_info info;
+ struct device_attribute dev_attr_input;
+ struct device_attribute dev_attr_label;
+ char input[20];
+ char label[20];
+};
+
+struct scpi_sensors {
+ struct scpi_ops *scpi_ops;
+ struct sensor_data *data;
+ struct attribute **attrs;
+ struct attribute_group group;
+ const struct attribute_group *groups[2];
+};
+
+/* hwmon callback functions */
+static ssize_t
+scpi_show_sensor(struct device *dev, struct device_attribute *attr, char *buf)
+{
+ struct scpi_sensors *scpi_sensors = dev_get_drvdata(dev);
+ struct scpi_ops *scpi_ops = scpi_sensors-scpi_ops;
+ struct sensor_data *sensor;
+
[PATCH v2 09/10] arm64: dts: Add sensor node to Juno dt
The SCP firmware on Juno provides access to SoC sensors via the
SCPI. Add the sensor nodes to the device tree to enable this support.
Signed-off-by: Punit Agrawal punit.agra...@arm.com
Cc: Rob Herring robh...@kernel.org
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Liviu Dudau liviu.du...@arm.com
Cc: Sudeep Holla sudeep.ho...@arm.com
---
arch/arm64/boot/dts/arm/juno-base.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/arm/juno-base.dtsi
b/arch/arm64/boot/dts/arm/juno-base.dtsi
index c624208..dd5158e 100644
--- a/arch/arm64/boot/dts/arm/juno-base.dtsi
+++ b/arch/arm64/boot/dts/arm/juno-base.dtsi
@@ -96,6 +96,11 @@
clock-output-names = pxlclk0, pxlclk1;
};
};
+
+ scpi_sensors0: sensors {
+ compatible = arm,scpi-sensors;
+ #thermal-sensor-cells = 1;
+ };
};
/include/ juno-clocks.dtsi
--
2.1.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 v2 04/10] thermal: Fix thermal_zone_of_sensor_register to match documentation
thermal_zone_of_sensor_register is documented as returning a pointer
to either a valid thermal_zone_device on success, or a corresponding
ERR_PTR() value.
In contrast, the function returns NULL when THERMAL_OF is configured
off. Fix this.
Signed-off-by: Punit Agrawal punit.agra...@arm.com
Cc: Guenter Roeck li...@roeck-us.net
Cc: Eduardo Valentin edubez...@gmail.com
Cc: Zhang Rui rui.zh...@intel.com
---
include/linux/thermal.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index 037e9df..a47b34a 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -364,7 +364,7 @@ static inline struct thermal_zone_device *
thermal_zone_of_sensor_register(struct device *dev, int id, void *data,
const struct thermal_zone_of_device_ops *ops)
{
- return NULL;
+ return ERR_PTR(-ENOSYS);
}
static inline
--
2.1.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 v2 05/10] Documentation: add DT bindings for ARM SCPI sensors
The System Control Processor (SCP) provides access to SoC sensors via
the System Control and Power Interface (SCPI) Message Protocol. Add
bindings to allow probing of these sensors. Also support referencing
of the sensors for setting up thermal zones via the thermal DT
bindings.
Signed-off-by: Punit Agrawal punit.agra...@arm.com
Cc: Rob Herring robh...@kernel.org
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Sudeep Holla sudeep.ho...@arm.com
---
Documentation/devicetree/bindings/arm/arm,scpi.txt | 15 +++
1 file changed, 15 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt
b/Documentation/devicetree/bindings/arm/arm,scpi.txt
index e309249..8ead68a 100644
--- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
+++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
@@ -72,8 +72,18 @@ Required sub-node properties:
- compatible : should be arm,juno-scp-shmem for Non-secure SRAM based
shared memory on Juno platforms
+Sensor bindings for the sensors based on SCPI Message Protocol
+--
+SCPI provides an API to access the various sensors on the SoC.
+
+Required properties:
+- compatible : should be arm,scpi-sensors.
+- #thermal-sensor-cells: should be set to 1. This property follows the
+thermal device tree bindings[2].
+
[0]
http://community.arm.com/servlet/JiveServlet/download/8401-45-18326/DUI0922B_scp_message_interface.pdf
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+[2] Documentation/devicetree/bindings/thermal/thermal.txt
Example:
@@ -122,6 +132,11 @@ scpi_protocol: scpi@2e00 {
clock-output-names = pxlclk0, pxlclk1;
};
};
+
+ scpi_sensors0: sensors {
+ compatible = arm,scpi-sensors;
+ #thermal-sensor-cells = 1;
+ };
};
cpu@0 {
--
2.1.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
RE: [PATCH v3 4/6] power: da9150: Add DT bindings documentation for Fuel-Gauge
On July 24, 2015 23:01, Sebastian Reichel wrote:
Hi,
On Tue, Jul 07, 2015 at 05:34:21PM +0100, Adam Thomson wrote:
diff --git a/Documentation/devicetree/bindings/power/da9150-fg.txt
b/Documentation/devicetree/bindings/power/da9150-fg.txt
new file mode 100644
index 000..c3c76eb
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/da9150-fg.txt
@@ -0,0 +1,23 @@
+Dialog Semiconductor DA9150 Fuel-Gauge Power Supply bindings
+
+Required properties:
+- compatible: dlg,da9150-fg for DA9150 Fuel-Gauge Power Supply
^
s/dlg,da9150-fg/dlg,da9150-fuel-gauge/g
Ok, can do.
+Optional properties:
+- dlg,update-interval: Interval time (milliseconds) between battery level
checks.
+- dlg,warn-soc-level: Battery discharge level (%) where warning event
raised.
+ [1 - 100]
+- dlg,crit-soc-level: Battery discharge level (%) where critical event
raised.
+ This value should be lower than the warning level.
+ [1 - 100]
+
+
+Example:
+
+ da9150-fg {
Make this just fuel-gauge.
No problem.
+ compatible = dlg,da9150-fg;
^
here too ;)
Consider it done. :)
+
+ dlg,update-interval = 1;
+ dlg,warn-soc-level = /bits/ 8 15;
+ dlg,crit-soc-level = /bits/ 8 5;
+ };
-- Sebastian
N�r��yb�X��ǧv�^�){.n�+���z��z��z)w* jg��� �ݢj/���z�ޖ��2�ޙ�)ߡ�a���� �G���h��j:+v���w��٥
[PATCH v2 02/10] cpufreq-dt: Supply power coefficient when registering cooling devices
Support registering cooling devices with dynamic power coefficient
where provided by the device tree. This allows OF registered cooling
devices driver to be used with the power_allocator thermal governor.
Signed-off-by: Punit Agrawal punit.agra...@arm.com
Acked-by: Viresh Kumar viresh.ku...@linaro.org
Cc: Eduardo Valentin edubez...@gmail.com
---
drivers/cpufreq/cpufreq-dt.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
index 528a82bf..1d1f61a 100644
--- a/drivers/cpufreq/cpufreq-dt.c
+++ b/drivers/cpufreq/cpufreq-dt.c
@@ -344,8 +344,13 @@ static void cpufreq_ready(struct cpufreq_policy *policy)
* thermal DT code takes care of matching them.
*/
if (of_find_property(np, #cooling-cells, NULL)) {
- priv-cdev = of_cpufreq_cooling_register(np,
-policy-related_cpus);
+ u32 power_coefficient = 0;
+
+ of_property_read_u32(np, dynamic-power-coefficient,
+power_coefficient);
+
+ priv-cdev = of_cpufreq_power_cooling_register(np,
+ policy-related_cpus, power_coefficient, NULL);
if (IS_ERR(priv-cdev)) {
dev_err(priv-cpu_dev,
running cpufreq without cooling device: %ld\n,
--
2.1.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 v2 00/10] Platform support for thermal management on Juno
Hi, The series adds support for thermal management on ARM Juno development platform. As part of this development, common infrastructure is added to support registering cpu cooling devices that work with the power allocator thermal governor. Patch 1 extends the CPU nodes binding to provide an optional dynamic power coefficient which can be used to create a dynamic power model for the CPUs. This model is used to constrain device power consumption (using power_allocator governor) when the system is thermally constrained. Patches 2-3 extends the cpufreq-dt and arm_big_little driver to register cpu cooling devices with the dynamic coefficient when provided. Patch 4 is a fix that aligns the behaviour of thermal_zone_of_sensor_register with it's documented return value when THERMAL_OF is configured off. Patches 5-8 create a hwmon sensor driver for sensors provided by SCPI firmware. Patch 7 adds support for the temperature sensors to register with the thermal framework. This allows setting up platform thermals using OF thermal bindings. The last two patches add support for the sensors and the thermal zones in the Juno device tree. The Juno specific patches depend on SCPI and cpufreq patches[0] from Sudeep. The SCPI protocol document with details of the sensor interface can be found at [1], [2]. Thanks, Punit Changes v1-v2 - added documentation for the scpi-hwmon driver - replaced static allocation of platform structure in scpi-hwmon.c with dynamic allocation - re-structured registering of thermal zones to better handle error conditions - reduced chattiness in scpi-hwmon.c - corrected sensor numbering to align with hwmon documentation - dynamic allocation of attributes and attribute groups [0] http://thread.gmane.org/gmane.linux.kernel/2009735 [1] http://community.arm.com/servlet/JiveServlet/download/8401-45-18326/DUI0922B_scp_message_interface.pdf [2] https://wiki.linaro.org/ARM/Juno?action=AttachFiledo=gettarget=DUI0922B_scp_message_interface.pdf v1: http://thread.gmane.org/gmane.linux.kernel/2002152 Punit Agrawal (10): devicetree: bindings: Add optional dynamic-power-coefficient property cpufreq-dt: Supply power coefficient when registering cooling devices cpufreq: arm_big_little: Add support to register a cpufreq cooling device thermal: Fix thermal_zone_of_sensor_register to match documentation Documentation: add DT bindings for ARM SCPI sensors firmware: arm_scpi: Extend to support sensors hwmon: Support sensors exported via ARM SCP interface hwmon: Support registration of thermal zones for SCP temperature sensors arm64: dts: Add sensor node to Juno dt arm64: dts: Create SoC thermal zone for Juno Documentation/devicetree/bindings/arm/arm,scpi.txt | 15 ++ Documentation/devicetree/bindings/arm/cpus.txt | 15 ++ Documentation/hwmon/scpi-hwmon | 33 +++ arch/arm64/boot/dts/arm/juno-base.dtsi | 5 + arch/arm64/boot/dts/arm/juno.dts | 50 drivers/cpufreq/arm_big_little.c | 52 +++- drivers/cpufreq/cpufreq-dt.c | 9 +- drivers/firmware/arm_scpi.c| 60 + drivers/hwmon/Kconfig | 8 + drivers/hwmon/Makefile | 1 + drivers/hwmon/scpi-hwmon.c | 284 + include/linux/scpi_protocol.h | 17 ++ include/linux/thermal.h| 2 +- 13 files changed, 546 insertions(+), 5 deletions(-) create mode 100644 Documentation/hwmon/scpi-hwmon create mode 100644 drivers/hwmon/scpi-hwmon.c -- 2.1.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 v2 06/10] firmware: arm_scpi: Extend to support sensors
ARM System Control Processor (SCP) provides an API to query and use
the sensors available in the system. Extend the SCPI driver to support
sensor messages.
Signed-off-by: Punit Agrawal punit.agra...@arm.com
Cc: Sudeep Holla sudeep.ho...@arm.com
---
drivers/firmware/arm_scpi.c | 60 +++
include/linux/scpi_protocol.h | 17
2 files changed, 77 insertions(+)
diff --git a/drivers/firmware/arm_scpi.c b/drivers/firmware/arm_scpi.c
index cb75c75..321680e 100644
--- a/drivers/firmware/arm_scpi.c
+++ b/drivers/firmware/arm_scpi.c
@@ -219,6 +219,21 @@ struct dvfs_set {
u8 index;
} __packed;
+struct sensor_capabilities {
+ __le16 sensors;
+} __packed;
+
+struct _scpi_sensor_info {
+ __le16 sensor_id;
+ u8 class;
+ u8 trigger_type;
+ char name[20];
+};
+
+struct sensor_value {
+ __le32 val;
+} __packed;
+
static struct scpi_drvinfo *scpi_info;
static int scpi_linux_errmap[SCPI_ERR_MAX] = {
@@ -481,6 +496,48 @@ static struct scpi_dvfs_info *scpi_dvfs_get_info(u8 domain)
return info;
}
+static int scpi_sensor_get_capability(u16 *sensors)
+{
+ struct sensor_capabilities cap_buf;
+ int ret;
+
+ ret = scpi_send_message(SCPI_CMD_SENSOR_CAPABILITIES, NULL, 0, cap_buf,
+ sizeof(cap_buf));
+ if (!ret)
+ *sensors = le16_to_cpu(cap_buf.sensors);
+
+ return ret;
+}
+
+static int scpi_sensor_get_info(u16 sensor_id, struct scpi_sensor_info *info)
+{
+ __le16 id = cpu_to_le16(sensor_id);
+ struct _scpi_sensor_info _info;
+ int ret;
+
+ ret = scpi_send_message(SCPI_CMD_SENSOR_INFO, id,
+sizeof(id), _info, sizeof(_info));
+ if (!ret) {
+ memcpy(info, _info, sizeof(*info));
+ info-sensor_id = le16_to_cpu(_info.sensor_id);
+ }
+
+ return ret;
+}
+
+int scpi_sensor_get_value(u16 sensor, u32 *val)
+{
+ struct sensor_value buf;
+ int ret;
+
+ ret = scpi_send_message(SCPI_CMD_SENSOR_VALUE, sensor, sizeof(sensor),
+ buf, sizeof(buf));
+ if (!ret)
+ *val = le32_to_cpu(buf.val);
+
+ return ret;
+}
+
static struct scpi_ops scpi_ops = {
.get_version = scpi_get_version,
.clk_get_range = scpi_clk_get_range,
@@ -489,6 +546,9 @@ static struct scpi_ops scpi_ops = {
.dvfs_get_idx = scpi_dvfs_get_idx,
.dvfs_set_idx = scpi_dvfs_set_idx,
.dvfs_get_info = scpi_dvfs_get_info,
+ .sensor_get_capability = scpi_sensor_get_capability,
+ .sensor_get_info = scpi_sensor_get_info,
+ .sensor_get_value = scpi_sensor_get_value,
};
struct scpi_ops *get_scpi_ops(void)
diff --git a/include/linux/scpi_protocol.h b/include/linux/scpi_protocol.h
index e7169cd..80af3cd 100644
--- a/include/linux/scpi_protocol.h
+++ b/include/linux/scpi_protocol.h
@@ -28,6 +28,20 @@ struct scpi_dvfs_info {
struct scpi_opp *opps;
};
+enum scpi_sensor_class {
+ TEMPERATURE,
+ VOLTAGE,
+ CURRENT,
+ POWER,
+};
+
+struct scpi_sensor_info {
+ u16 sensor_id;
+ u8 class;
+ u8 trigger_type;
+ char name[20];
+} __packed;
+
/**
* struct scpi_ops - represents the various operations provided
* by SCP through SCPI message protocol
@@ -52,6 +66,9 @@ struct scpi_ops {
int (*dvfs_get_idx)(u8);
int (*dvfs_set_idx)(u8, u8);
struct scpi_dvfs_info *(*dvfs_get_info)(u8);
+ int (*sensor_get_capability)(u16 *sensors);
+ int (*sensor_get_info)(u16 sensor_id, struct scpi_sensor_info *);
+ int (*sensor_get_value)(u16, u32 *);
};
#if IS_ENABLED(CONFIG_ARM_SCPI_PROTOCOL)
--
2.1.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
Re: [PATCH v2 3/4] touchscreen: colibri-vf50-ts: Add touchscreen support for Colibri VF50
Hello Dmitry,
On 15-07-21 10:20:44, Dmitry Torokhov wrote:
Hi Stefan,
On Tue, Jul 21, 2015 at 04:43:36PM +0200, Stefan Agner wrote:
Hi Dmitry,
As the original author of the driver I have some remarks to your review
On 2015-07-18 01:42, Dmitry Torokhov wrote:
+/*
+ * If touch pressure is too low, stop measuring and
reenable
+ * touch detection
+ */
+if (val_p min_pressure || val_p 2000)
+break;
This is where the modules touch pressure is used to stop the measurement
process and switch back to interrupt mode. See my remarks at the end.
+
+/*
+ * The pressure may not be enough for the first x and
the
+ * second y measurement, but, the pressure is ok when
the
+ * driver is doing the third and fourth measurement. To
+ * take care of this, we drop the first measurement
always.
+ */
+if (discard_val_on_start) {
+discard_val_on_start = false;
+} else {
+/*
+ * Report touch position and sleep for
+ * next measurement
+ */
+input_report_abs(vf50_ts-ts_input,
+ABS_X, VF_ADC_MAX - val_x);
+input_report_abs(vf50_ts-ts_input,
+ABS_Y, VF_ADC_MAX - val_y);
+input_report_abs(vf50_ts-ts_input,
+ABS_PRESSURE, val_p);
+input_report_key(vf50_ts-ts_input, BTN_TOUCH,
1);
+input_sync(vf50_ts-ts_input);
+}
+
+msleep(10);
+}
+
+/* Report no more touch, reenable touch detection */
+input_report_abs(vf50_ts-ts_input, ABS_PRESSURE, 0);
+input_report_key(vf50_ts-ts_input, BTN_TOUCH, 0);
+input_sync(vf50_ts-ts_input);
+
+vf50_ts_enable_touch_detection(vf50_ts);
+
+/* Wait for the pull-up to be stable on high */
+msleep(10);
+
+/* Reenable IRQ to detect touch */
+enable_irq(vf50_ts-pen_irq);
+
+dev_dbg(dev, Reenabled touch detection interrupt\n);
+}
+
+static irqreturn_t vf50_ts_touched(int irq, void *dev_id)
+{
+struct vf50_touch_device *vf50_ts = (struct vf50_touch_device
*)dev_id;
+struct device *dev = vf50_ts-pdev-dev;
+
+dev_dbg(dev, Touch detected, start worker thread\n);
+
+disable_irq_nosync(irq);
+
+/* Disable the touch detection plates */
+gpiod_set_value(vf50_ts-gpio_ym, 0);
+
+/* Let the platform mux to default state in order to mux as ADC
*/
+pinctrl_pm_select_default_state(dev);
+
+queue_work(vf50_ts-ts_workqueue, vf50_ts-ts_work);
If you convert this to a threaded interrupt you won't need to
disable/reenable interrupt or queue work. You should also be able to use
gpiod_set_value_cansleep() extending the range of ways the controller
could be connected to systems.
I'm not sure if a threaded interrupt is the right thing here. While the
pen is on the touchscreen (which can be for several seconds)
measurements have to be made in a continuous loop. Is it ok for a
threaded interrupt to run that long?
Yes, why not? Threaded interrupt is simply a kernel thread that is woken
when hard interrupt handler tells it to wake up. Very similar to
interrupt + work queue, except that the kernel manages interactions
properly for you. There are several drivers in kernel that do that, for
example auo-pixcir-ts.c or tsc2007.c
I'm also not sure if it is really safe to _not_ disable the pen down
GPIO interrupt. If we get a interrupt while measuring, we should ignore
that interrupt.
The interrupt management core (you'll have to annotate it as
IRQF_ONESHOT) will make sure it stays masked properly until the threaded
handler completes so you do not need to disable it explicitly.
After working some more on threaded irq implementation, if IRQ_ONESHOT
flag is used while requesting threaded irq, on entering the IRQ handler
the vf610_gpio_irq_mask is not called and vf610_gpio_irq_unmask is not
called on exiting the thread function, not something we expected.
In contrast, using explicit disable_irq_nosync and enable_irq in the IRQ
handler and thread respectively results in the respective mask and unmask
function being called.
The vf610_gpio_irq_*mask functions are in the gpio driver for Vybrid in
drivers/gpio/gpio-vf610.c.
Can you point me in the right direction?
Thanks Regards,
Re: [PATCH v2 04/10] thermal: Fix thermal_zone_of_sensor_register to match documentation
On 08/03/2015 08:22 AM, Punit Agrawal wrote:
thermal_zone_of_sensor_register is documented as returning a pointer
to either a valid thermal_zone_device on success, or a corresponding
ERR_PTR() value.
In contrast, the function returns NULL when THERMAL_OF is configured
off. Fix this.
Signed-off-by: Punit Agrawal punit.agra...@arm.com
Cc: Guenter Roeck li...@roeck-us.net
Cc: Eduardo Valentin edubez...@gmail.com
Cc: Zhang Rui rui.zh...@intel.com
Acked-by: Guenter Roeck li...@roeck-us.net
---
include/linux/thermal.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index 037e9df..a47b34a 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -364,7 +364,7 @@ static inline struct thermal_zone_device *
thermal_zone_of_sensor_register(struct device *dev, int id, void *data,
const struct thermal_zone_of_device_ops *ops)
{
- return NULL;
+ return ERR_PTR(-ENOSYS);
}
static inline
--
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] dtb: Create a common home for cross-architecture dtsi files.
On Mon, Aug 3, 2015 at 3:55 AM, Ian Campbell ian.campb...@citrix.com wrote:
Commit 9ccd608070b6 (arm64: dts: add device tree for ARM SMM-A53x2 on
LogicTile Express 20MG) added a new dts file to arch/arm64 which
included ../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi, i.e. a
.dtsi supplied by arch/arm.
Unfortunately this causes some issues for the split device tree
repository[0], since things get moved around there. In that context
the new .dts ends up at src/arm64/arm/vexpress-v2f-1xv7-ca53x2.dts
while the include is at src/arm/vexpress-v2m-rs1.dtsi.
The sharing of the .dtsi is legitimate since the baseboard is the same
for various vexpress systems whatever processor they use.
Rather than using ../../ tricks to pickup .dtsi files from another
arch this patch creates a new directory kernel/dts as a home for such
cross-arch .dtsi files, arranges for it to be in the include path when
the .dts files are processed by cpp and switches the .dts files to use
cpp #include instead of /include/. The dtsi file itself is moved into
a vendor subdir in this case arm (the vendor, not the ARCH=).
Sigh, it was not the include path I was referring to being wrong
although that was too. It was the part about using #include instead of
/include/.
Rob
[0]
https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-rebasing.git/
Signed-off-by: Ian Campbell ian.campb...@citrix.com
Cc: Rob Herring robh...@kernel.org
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Kumar Gala ga...@codeaurora.org
Cc: Liviu Dudau liviu.du...@arm.com
Cc: Sudeep Holla sudeep.ho...@arm.com
Cc: Lorenzo Pieralisi lorenzo.pieral...@arm.com
Cc: Russell King li...@arm.linux.org.uk
Cc: Catalin Marinas catalin.mari...@arm.com
Cc: Will Deacon will.dea...@arm.com
Cc: Kristina Martsenko kristina.martse...@arm.com
Cc: Kevin Hilman khil...@linaro.org
Cc: devicetree@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kbu...@vger.kernel.org
Acked-by: Mark Rutland mark.rutl...@arm.com
Acked-by: Rob Herring r...@kernel.org
Acked-by: Liviu Dudau liviu.du...@arm.com
Reviewed-by: Masahiro Yamada yamada.masah...@socionext.com
---
v2: Move to include/dt-dtsi and introduce a per-vendor subdirectory.
v3: Move to kernel/dts.
Include new directory in DTC include path as well as cpp path, and
therefore switch back to /include/.
Update MAINTAINERS
v4: Change path in changelog too.
Add ()s to title of 9ccd608070b6.
---
Documentation/devicetree/bindings/arm/vexpress.txt | 2 +-
MAINTAINERS | 1 +
arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts | 2 +-
arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts | 2 +-
arch/arm/boot/dts/vexpress-v2p-ca5s.dts | 2 +-
arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts| 2 +-
{arch/arm/boot/dts = kernel/dts/arm}/vexpress-v2m-rs1.dtsi | 0
scripts/Makefile.lib| 3 ++-
8 files changed, 8 insertions(+), 6 deletions(-)
rename {arch/arm/boot/dts = kernel/dts/arm}/vexpress-v2m-rs1.dtsi (100%)
diff --git a/Documentation/devicetree/bindings/arm/vexpress.txt
b/Documentation/devicetree/bindings/arm/vexpress.txt
index 39844cd..b6031d9 100644
--- a/Documentation/devicetree/bindings/arm/vexpress.txt
+++ b/Documentation/devicetree/bindings/arm/vexpress.txt
@@ -223,7 +223,7 @@ Example of a VE tile description (simplified)
/* Active high IRQ 0 is connected to GIC's SPI0 */
interrupt-map = 0 0 0 gic 0 0 4;
- /include/ vexpress-v2m-rs1.dtsi
+ /include/ arm/vexpress-v2m-rs1.dtsi
};
};
diff --git a/MAINTAINERS b/MAINTAINERS
index a226416..1941078 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7537,6 +7537,7 @@ S:Maintained
F: Documentation/devicetree/
F: arch/*/boot/dts/
F: include/dt-bindings/
+F: kernel/dts/
OPEN FIRMWARE AND DEVICE TREE OVERLAYS
M: Pantelis Antoniou pantelis.anton...@konsulko.com
diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
b/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
index 9420053..b144092 100644
--- a/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
+++ b/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
@@ -278,6 +278,6 @@
0 0 41 gic 0 41 4,
0 0 42 gic 0 42 4;
- /include/ vexpress-v2m-rs1.dtsi
+ /include/ arm/vexpress-v2m-rs1.dtsi
};
};
diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
index 17f63f7..350f402 100644
--- a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
+++ b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
@@ -636,6 +636,6 @@
0 0 41 gic 0 41 4,
0 0 42 gic 0 42
[PATCH v2 08/10] hwmon: Support registration of thermal zones for SCP temperature sensors
Add support to create thermal zones based on the temperature sensors
provided by the SCP. The thermal zones can be defined using the
thermal DT bindings and should refer to the SCP sensor id to select
the sensor.
Signed-off-by: Punit Agrawal punit.agra...@arm.com
Cc: Jean Delvare jdelv...@suse.de
Cc: Guenter Roeck li...@roeck-us.net
Cc: Eduardo Valentin edubez...@gmail.com
---
drivers/hwmon/scpi-hwmon.c | 103 -
1 file changed, 102 insertions(+), 1 deletion(-)
diff --git a/drivers/hwmon/scpi-hwmon.c b/drivers/hwmon/scpi-hwmon.c
index 7e7e06b..d96a3e5 100644
--- a/drivers/hwmon/scpi-hwmon.c
+++ b/drivers/hwmon/scpi-hwmon.c
@@ -20,6 +20,7 @@
#include linux/scpi_protocol.h
#include linux/slab.h
#include linux/sysfs.h
+#include linux/thermal.h
struct sensor_data {
struct scpi_sensor_info info;
@@ -29,14 +30,39 @@ struct sensor_data {
char label[20];
};
+struct scpi_thermal_zone {
+ struct list_head list;
+ int sensor_id;
+ struct scpi_sensors *scpi_sensors;
+ struct thermal_zone_device *tzd;
+};
+
struct scpi_sensors {
struct scpi_ops *scpi_ops;
struct sensor_data *data;
+ struct list_head thermal_zones;
struct attribute **attrs;
struct attribute_group group;
const struct attribute_group *groups[2];
};
+static int scpi_read_temp(void *dev, long *temp)
+{
+ struct scpi_thermal_zone *zone = dev;
+ struct scpi_sensors *scpi_sensors = zone-scpi_sensors;
+ struct scpi_ops *scpi_ops = scpi_sensors-scpi_ops;
+ struct sensor_data *sensor = scpi_sensors-data[zone-sensor_id];
+ u32 value;
+ int ret;
+
+ ret = scpi_ops-sensor_get_value(sensor-info.sensor_id, value);
+ if (ret)
+ return ret;
+
+ *temp = value;
+ return 0;
+}
+
/* hwmon callback functions */
static ssize_t
scpi_show_sensor(struct device *dev, struct device_attribute *attr, char *buf)
@@ -66,6 +92,24 @@ scpi_show_label(struct device *dev, struct device_attribute
*attr, char *buf)
return sprintf(buf, %s\n, sensor-info.name);
}
+static void
+unregister_thermal_zones(struct platform_device *pdev,
+struct scpi_sensors *scpi_sensors)
+{
+ struct list_head *pos;
+
+ list_for_each(pos, scpi_sensors-thermal_zones) {
+ struct scpi_thermal_zone *zone;
+
+ zone = list_entry(pos, struct scpi_thermal_zone, list);
+ thermal_zone_of_sensor_unregister(pdev-dev, zone-tzd);
+ }
+}
+
+static struct thermal_zone_of_device_ops scpi_sensor_ops = {
+ .get_temp = scpi_read_temp,
+};
+
static int scpi_hwmon_probe(struct platform_device *pdev)
{
u16 nr_sensors, i;
@@ -157,10 +201,66 @@ static int scpi_hwmon_probe(struct platform_device *pdev)
scpi_sensors-group.attrs = scpi_sensors-attrs;
scpi_sensors-groups[0] = scpi_sensors-group;
+ platform_set_drvdata(pdev, scpi_sensors);
+
hwdev = devm_hwmon_device_register_with_groups(dev,
scpi_sensors, scpi_sensors, scpi_sensors-groups);
- return PTR_ERR_OR_ZERO(hwdev);
+ if (IS_ERR(hwdev))
+ return PTR_ERR(hwdev);
+
+ /*
+* Register the temperature sensors with the thermal framework
+* to allow their usage in setting up the thermal zones from
+* device tree.
+*
+* NOTE: Not all temperature sensors maybe used for thermal
+* control
+*/
+ INIT_LIST_HEAD(scpi_sensors-thermal_zones);
+ for (i = 0; i nr_sensors; i++) {
+ struct sensor_data *sensor = scpi_sensors-data[i];
+ struct scpi_thermal_zone *zone;
+
+ if (sensor-info.class != TEMPERATURE)
+ continue;
+
+ zone = devm_kzalloc(pdev-dev, sizeof(*zone), GFP_KERNEL);
+ if (!zone) {
+ ret = -ENOMEM;
+ goto unregister_tzd;
+ }
+
+ zone-sensor_id = i;
+ zone-scpi_sensors = scpi_sensors;
+ zone-tzd = thermal_zone_of_sensor_register(dev, i, zone,
+ scpi_sensor_ops);
+ /*
+* The call to thermal_zone_of_sensor_register returns
+* an error for sensors that are not associated with
+* any thermal zones.
+*/
+ if (IS_ERR(zone-tzd)) {
+ devm_kfree(dev, zone);
+ continue;
+ }
+ list_add(zone-list, scpi_sensors-thermal_zones);
+ }
+
+ return 0;
+
+unregister_tzd:
+ unregister_thermal_zones(pdev, scpi_sensors);
+ return ret;
+}
+
+static int scpi_hwmon_remove(struct platform_device *pdev)
+{
+ struct scpi_sensors *scpi_sensors = platform_get_drvdata(pdev);
+
+
[PATCH v2 01/10] devicetree: bindings: Add optional dynamic-power-coefficient property
The dynamic power consumption of a device is proportional to the
square of voltage (V) and the clock frequency (f). It can be expressed as
Pdyn = dynamic-power-coefficient * V^2 * f.
The dynamic-power-coefficient property represents an indicative
running time dynamic power coefficient in fundamental units of
mw/MHz/uVolt^2 and can be used in the above formula to calculate the
dynamic power in mW.
Signed-off-by: Punit Agrawal punit.agra...@arm.com
Cc: Rob Herring robh...@kernel.org
Cc: Mark Rutland mark.rutl...@arm.com
---
Documentation/devicetree/bindings/arm/cpus.txt | 15 +++
1 file changed, 15 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/cpus.txt
b/Documentation/devicetree/bindings/arm/cpus.txt
index d6b794c..c32bfac 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -239,6 +239,21 @@ nodes to be present and contain the properties described
below.
Definition: Specifies the syscon node controlling the cpu core
power domains.
+ - dynamic-power-coefficient
+ Usage: optional
+ Value type: prop-encoded-array
+ Definition: A u32 value that represents an indicative
+ running time dynamic power coefficient in
+ fundamental units of mW/MHz/uVolt^2.
+
+ The dynamic energy consumption of the CPU
+ is proportional to the square of the
+ Voltage (V) and the clock frequency (f).
+
+ Pdyn = dynamic-power-coefficient * V^2 * f
+
+ where voltage is in uV, frequency is in MHz.
+
Example 1 (dual-cluster big.LITTLE system 32-bit):
cpus {
--
2.1.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 v2 10/10] arm64: dts: Create SoC thermal zone for Juno
Setup a thermal zone driven by the SoC temperature sensor on Juno
r0. Create passive trip points and bind them to cpufreq cooling
devices that support the power extensions.
Signed-off-by: Punit Agrawal punit.agra...@arm.com
Cc: Rob Herring robh...@kernel.org
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Liviu Dudau liviu.du...@arm.com
Cc: Sudeep Holla sudeep.ho...@arm.com
---
arch/arm64/boot/dts/arm/juno.dts | 50
1 file changed, 50 insertions(+)
diff --git a/arch/arm64/boot/dts/arm/juno.dts b/arch/arm64/boot/dts/arm/juno.dts
index d2e67f3..664961c 100644
--- a/arch/arm64/boot/dts/arm/juno.dts
+++ b/arch/arm64/boot/dts/arm/juno.dts
@@ -9,6 +9,7 @@
/dts-v1/;
#include dt-bindings/interrupt-controller/arm-gic.h
+#include dt-bindings/thermal/thermal.h
/ {
model = ARM Juno development board (r0);
@@ -90,6 +91,8 @@
next-level-cache = A57_L2;
clocks = scpi_dvfs 0;
cpu-idle-states = CPU_SLEEP_0 CLUSTER_SLEEP_0;
+ #cooling-cells = 2;
+ dynamic-power-coefficient = 530;
};
A57_1: cpu@1 {
@@ -100,6 +103,8 @@
next-level-cache = A57_L2;
clocks = scpi_dvfs 0;
cpu-idle-states = CPU_SLEEP_0 CLUSTER_SLEEP_0;
+ #cooling-cells = 2;
+ dynamic-power-coefficient = 530;
};
A53_0: cpu@100 {
@@ -110,6 +115,8 @@
next-level-cache = A53_L2;
clocks = scpi_dvfs 1;
cpu-idle-states = CPU_SLEEP_0 CLUSTER_SLEEP_0;
+ #cooling-cells = 2;
+ dynamic-power-coefficient = 140;
};
A53_1: cpu@101 {
@@ -120,6 +127,8 @@
next-level-cache = A53_L2;
clocks = scpi_dvfs 1;
cpu-idle-states = CPU_SLEEP_0 CLUSTER_SLEEP_0;
+ #cooling-cells = 2;
+ dynamic-power-coefficient = 140;
};
A53_2: cpu@102 {
@@ -130,6 +139,8 @@
next-level-cache = A53_L2;
clocks = scpi_dvfs 1;
cpu-idle-states = CPU_SLEEP_0 CLUSTER_SLEEP_0;
+ #cooling-cells = 2;
+ dynamic-power-coefficient = 140;
};
A53_3: cpu@103 {
@@ -140,6 +151,8 @@
next-level-cache = A53_L2;
clocks = scpi_dvfs 1;
cpu-idle-states = CPU_SLEEP_0 CLUSTER_SLEEP_0;
+ #cooling-cells = 2;
+ dynamic-power-coefficient = 140;
};
A57_L2: l2-cache0 {
@@ -167,5 +180,42 @@
A53_3;
};
+ thermal-zones {
+ soc_thermal {
+ polling-delay = 1000;
+ polling-delay-passive = 100;
+ sustainable-power = 2500;
+
+ thermal-sensors = scpi_sensors0 3;
+
+ trips {
+ threshold: trip-point@0 {
+ temperature = 55000;
+ hysteresis = 1000;
+ type = passive;
+ };
+ target: trip-point@1 {
+ temperature = 65000;
+ hysteresis = 1000;
+ type = passive;
+ };
+ };
+
+ cooling-maps {
+ map0 {
+ trip = target;
+ cooling-device = A53_0
THERMAL_NO_LIMIT THERMAL_NO_LIMIT;
+ contribution = 2048;
+ };
+ map1 {
+ trip = target;
+ cooling-device = A57_0
THERMAL_NO_LIMIT THERMAL_NO_LIMIT;
+ contribution = 1024;
+ };
+
+ };
+ };
+ };
+
#include juno-base.dtsi
};
--
2.1.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
RE: [PATCH v3 3/6] power: Add support for DA9150 Fuel-Gauge
On July 25, 2015 18:27, Sebastian Reichel wrote:
Hi Adam,
The driver looks mostly fine. I have a few comments, though:
On Tue, Jul 07, 2015 at 05:34:19PM +0100, Adam Thomson wrote:
Signed-off-by: Adam Thomson adam.thomson.opensou...@diasemi.com
Please add a short description to the commit message.
Ok, I can add something. Didn't feel like it needed to be too descriptive, but
can make it a little more verbose.
[...]
+config FG_DA9150
Please name the config entry BATTERY_DA9150 to be consistent with
the other fuel gauges.
Ok no problem.
[...]
+#include linux/kernel.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/of.h
+#include linux/of_platform.h
+#include linux/slab.h
+#include linux/interrupt.h
+#include linux/delay.h
+#include linux/power_supply.h
+#include linux/list.h
+#include asm/div64.h
+#include linux/mfd/da9150/core.h
+#include linux/mfd/da9150/registers.h
I wonder if the depends CHARGER_DA9150 in Kconfig should be
depends MFD_DA9150 instead.
I did think about this, but it felt like it was a bit pointless having the
fuel-gauge driver without the charger driver, as they're intrinsically tied in
HW. I guess if you don't want the charging reporting but still wanted fuel-gauge
information then maybe. I don't mind making the change you mention as there
should be no functional impact.
[...]
+
+/* Power Supply attributes */
+static int da9150_fg_capacity(struct da9150_fg *fg,
+ union power_supply_propval *val)
+{
+ da9150_fg_read_sync_start(fg);
+ val-intval = da9150_fg_read_attr(fg, DA9150_QIF_SOC_PCT,
+ DA9150_QIF_SOC_PCT_SIZE);
+ da9150_fg_read_sync_end(fg);
Create a wrapper function for this. Reading a single value
with sync guards is done multiple times.
da9150_fg_read_attr_sync(fg, ...) {
da9150_fg_read_sync_start(fg);
da9150_fg_read_attr(fg, ...);
da9150_fg_read_sync_end(fg);
}
Yep, fair point. Can add something for the single attribute accesses.
+ if (val-intval 100)
+ val-intval = 100;
+
+ return 0;
+}
+
[...]
+ DA9150_QIF_E_FG_STATUS_SIZE);
+
+ /* Handle warning/critical threhold events */
+ if ((DA9150_FG_IRQ_LOW_SOC_MASK | DA9150_FG_IRQ_HIGH_SOC_MASK)
+ e_fg_status)
Please make this (e_fg_status CONSTANT_MASK).
Fine, not a problem.
+ da9150_fg_soc_event_config(fg);
+
+ /* Clear any FG IRQs */
+ da9150_fg_write_attr(fg, DA9150_QIF_E_FG_STATUS,
+DA9150_QIF_E_FG_STATUS_SIZE, e_fg_status);
+
+ return IRQ_HANDLED;
+}
+
[...]
+static int da9150_fg_probe(struct platform_device *pdev)
+{
+ struct device *dev = pdev-dev;
+ struct da9150 *da9150 = dev_get_drvdata(dev-parent);
+ struct da9150_fg_pdata *fg_pdata = dev_get_platdata(dev);
+ struct da9150_fg *fg;
+ int ver, irq, ret;
+
+ fg = devm_kzalloc(dev, sizeof(*fg), GFP_KERNEL);
+ if (fg == NULL)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, fg);
+ fg-da9150 = da9150;
+ fg-dev = dev;
+
+ mutex_init(fg-io_lock);
+
+ /* Enable QIF */
+ da9150_set_bits(da9150, DA9150_CORE2WIRE_CTRL_A,
DA9150_FG_QIF_EN_MASK,
+ DA9150_FG_QIF_EN_MASK);
+
+ fg-battery = power_supply_register(dev, fg_desc, NULL);
+ if (IS_ERR(fg-battery)) {
+ ret = PTR_ERR(fg-battery);
+ return ret;
+ }
Please use devm_power_supply_register(...) to simplify the driver.
+ ver = da9150_fg_read_attr(fg, DA9150_QIF_FW_MAIN_VER,
+ DA9150_QIF_FW_MAIN_VER_SIZE);
+ dev_info(dev, Version: 0x%x\n, ver);
+
+ /* Handle DT data if provided */
+ if (dev-of_node) {
+ fg_pdata = da9150_fg_dt_pdata(dev);
+ dev-platform_data = fg_pdata;
+ }
+
+ /* Handle any pdata provided */
+ if (fg_pdata) {
+ fg-interval = fg_pdata-update_interval;
+
+ if (fg_pdata-warn_soc_lvl 100)
+ dev_warn(dev, Invalid SOC warning level provided,
Ignoring);
+ else
+ fg-warn_soc = fg_pdata-warn_soc_lvl;
+
+ if ((fg_pdata-crit_soc_lvl 100) ||
+ (fg_pdata-crit_soc_lvl = fg_pdata-warn_soc_lvl))
+ dev_warn(dev, Invalid SOC critical level provided,
Ignoring);
+ else
+ fg-crit_soc = fg_pdata-crit_soc_lvl;
+
+
+ }
+
+ /* Configure initial SOC level events */
+ da9150_fg_soc_event_config(fg);
+
+ /*
+* If an interval period has been provided then setup repeating
+* work for reporting data updates.
+*/
+ if (fg-interval) {
+ INIT_DELAYED_WORK(fg-work, da9150_fg_work);
+ schedule_delayed_work(fg-work,
+
Re: [PATCH v2 4/9] clocksource: mediatek: Use GPT as sched clock source
On 05/16/2015 09:58 AM, Yingjoe Chen wrote: When cpu is in deep idle, arch timer will stop counting. Setup GPT as sched clock source so it can keep counting in idle. Signed-off-by: Yingjoe Chen yingjoe.c...@mediatek.com --- Acked-by: Daniel Lezcano daniel.lezc...@linaro.org -- http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro Facebook | http://twitter.com/#!/linaroorg Twitter | http://www.linaro.org/linaro-blog/ Blog -- 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] PCI: Store PCIe bus address in struct of_pci_range
On 2015. 8. 1., at AM 12:09, Gabriele Paoloni gabriele.paol...@huawei.com wrote: -Original Message- From: Kishon Vijay Abraham I [mailto:kis...@ti.com] Sent: Friday, July 31, 2015 3:57 PM To: Gabriele Paoloni; Rob Herring Cc: Bjorn Helgaas; a...@arndb.de; lorenzo.pieral...@arm.com; Wangzhou (B); robh...@kernel.org; james.mo...@arm.com; liviu.du...@arm.com; linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; devicetree@vger.kernel.org; Yuanzhichang; Zhudacai; zhangjukuo; qiuzhenfa; Liguozhu (Kenneth); Jingoo Han; Pratyush Anand; Arnd Bergmann; Arnd Bergmann Subject: Re: [PATCH v6] PCI: Store PCIe bus address in struct of_pci_range +Arnd Hi, On Friday 31 July 2015 07:55 PM, Gabriele Paoloni wrote: [+cc Kishon] -Original Message- From: linux-pci-ow...@vger.kernel.org [mailto:linux-pci- ow...@vger.kernel.org] On Behalf Of Rob Herring Sent: Thursday, July 30, 2015 9:42 PM To: Gabriele Paoloni Cc: Bjorn Helgaas; a...@arndb.de; lorenzo.pieral...@arm.com; Wangzhou (B); robh...@kernel.org; james.mo...@arm.com; liviu.du...@arm.com; linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; devicetree@vger.kernel.org; Yuanzhichang; Zhudacai; zhangjukuo; qiuzhenfa; Liguozhu (Kenneth); Jingoo Han; Pratyush Anand Subject: Re: [PATCH v6] PCI: Store PCIe bus address in struct of_pci_range On Thu, Jul 30, 2015 at 12:34 PM, Gabriele Paoloni gabriele.paol...@huawei.com wrote: -Original Message- From: Bjorn Helgaas [mailto:bhelg...@google.com] Sent: 30 July 2015 18:15 On Thu, Jul 30, 2015 at 04:50:55PM +, Gabriele Paoloni wrote: -Original Message- From: linux-pci-ow...@vger.kernel.org [mailto:linux-pci- ow...@vger.kernel.org] On Behalf Of Bjorn Helgaas Sent: Thursday, July 30, 2015 5:15 PM On Thu, Jul 30, 2015 at 01:52:13PM +, Gabriele Paoloni wrote: [...] I don’t think we should rely on [CPU] addresses...what if the intermediate translation layer changes the lower significant bits of the bus address to translate into a cpu address? Is it really a possiblity that the lower bits could be changed? I've checked all the current deignware users DTs except pci- layerscape that I could not find: spear1310.dtsi spear1340.dtsi dra7.dtsi imx6qdl.dtsi imx6sx.dtsi keystone.dtsi exynos5440.dtsi None of them modifies the lower bits. To be more precise the only guy that provides another translation layer is dra7.dtsi: axi0 http://lxr.free- electrons.com/source/arch/arm/boot/dts/dra7.dtsi#L207 axi1 http://lxr.free- electrons.com/source/arch/arm/boot/dts/dra7.dtsi#L241 For this case masking the top 4bits (bits28 to 31) should make the job. IMO, we should just fix this case. After further study, I don't think this is a DW issue, but rather an SOC integration issue. I believe you can just fixup the address in the pp-ops-host_init hook. Yep, it is SOC specific code for dra7. This is NOT a DW issue. Yes I guess that I could just assign pp-(*)_mod_base to the CPU address in DW and mask it out in dra7xx_pcie_host_init()... Kishon, would you be ok with that? Initially I was using *base-mask* property from dt. Me and Arnd (cc'ed) had this discussion [1] before we decided the current approach. It'll be good to check with Arnd too. [1] - http://lists.infradead.org/pipermail/linux-arm-kernel/2014- May/253528.html In this patch you use the mask into designwareinstead the approach proposed by Rob means to have the mask declared in the dra7 driver and you modified the pp members in dra7xx_pcie_host_init by masking them... I want to move that code to dra7 driver, because that code is dra7-specific. Best regards, Jingoo Han BTW good to have Arnd opinion too.. Thanks Kishon -- 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] dtb: Create a common home for cross-architecture dtsi files.
On Mon, 2015-08-03 at 10:55 -0500, Rob Herring wrote: On Mon, Aug 3, 2015 at 3:55 AM, Ian Campbell ian.campb...@citrix.com wrote: Commit 9ccd608070b6 (arm64: dts: add device tree for ARM SMM-A53x2 on LogicTile Express 20MG) added a new dts file to arch/arm64 which included ../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi, i.e. a .dtsi supplied by arch/arm. Unfortunately this causes some issues for the split device tree repository[0], since things get moved around there. In that context the new .dts ends up at src/arm64/arm/vexpress-v2f-1xv7-ca53x2.dts while the include is at src/arm/vexpress-v2m-rs1.dtsi. The sharing of the .dtsi is legitimate since the baseboard is the same for various vexpress systems whatever processor they use. Rather than using ../../ tricks to pickup .dtsi files from another arch this patch creates a new directory kernel/dts as a home for such cross-arch .dtsi files, arranges for it to be in the include path when the .dts files are processed by cpp and switches the .dts files to use cpp #include instead of /include/. The dtsi file itself is moved into a vendor subdir in this case arm (the vendor, not the ARCH=). Sigh, it was not the include path I was referring to being wrong although that was too. It was the part about using #include instead of /include/. Damn, how did I miss that! v5 coming up, sorry :-/ -- 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 v4] dtb: Create a common home for cross-architecture dtsi files.
Commit 9ccd608070b6 (arm64: dts: add device tree for ARM SMM-A53x2 on
LogicTile Express 20MG) added a new dts file to arch/arm64 which
included ../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi, i.e. a
.dtsi supplied by arch/arm.
Unfortunately this causes some issues for the split device tree
repository[0], since things get moved around there. In that context
the new .dts ends up at src/arm64/arm/vexpress-v2f-1xv7-ca53x2.dts
while the include is at src/arm/vexpress-v2m-rs1.dtsi.
The sharing of the .dtsi is legitimate since the baseboard is the same
for various vexpress systems whatever processor they use.
Rather than using ../../ tricks to pickup .dtsi files from another
arch this patch creates a new directory kernel/dts as a home for such
cross-arch .dtsi files and arranges for it to be in the include path
for both dtc and cpp. The dtsi file itself is moved into a vendor
subdir in this case arm (the vendor, not the ARCH=).
[0]
https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-rebasing.git/
Signed-off-by: Ian Campbell ian.campb...@citrix.com
Cc: Rob Herring robh...@kernel.org
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Kumar Gala ga...@codeaurora.org
Cc: Liviu Dudau liviu.du...@arm.com
Cc: Sudeep Holla sudeep.ho...@arm.com
Cc: Lorenzo Pieralisi lorenzo.pieral...@arm.com
Cc: Russell King li...@arm.linux.org.uk
Cc: Catalin Marinas catalin.mari...@arm.com
Cc: Will Deacon will.dea...@arm.com
Cc: Kristina Martsenko kristina.martse...@arm.com
Cc: Kevin Hilman khil...@linaro.org
Cc: devicetree@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kbu...@vger.kernel.org
Acked-by: Mark Rutland mark.rutl...@arm.com
Acked-by: Rob Herring r...@kernel.org
Acked-by: Liviu Dudau liviu.du...@arm.com
Reviewed-by: Masahiro Yamada yamada.masah...@socionext.com
---
v2: Move to include/dt-dtsi and introduce a per-vendor subdirectory.
v3: Move to kernel/dts.
Include new directory in DTC include path as well as cpp path, and
therefore switch back to /include/.
Update MAINTAINERS
v4: Change path in changelog too.
Add ()s to title of 9ccd608070b6.
v5: Remove stale reference to switching from /include/ to #include.
---
Documentation/devicetree/bindings/arm/vexpress.txt | 2 +-
MAINTAINERS | 1 +
arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts | 2 +-
arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts | 2 +-
arch/arm/boot/dts/vexpress-v2p-ca5s.dts | 2 +-
arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts| 2 +-
{arch/arm/boot/dts = kernel/dts/arm}/vexpress-v2m-rs1.dtsi | 0
scripts/Makefile.lib| 3 ++-
8 files changed, 8 insertions(+), 6 deletions(-)
rename {arch/arm/boot/dts = kernel/dts/arm}/vexpress-v2m-rs1.dtsi (100%)
diff --git a/Documentation/devicetree/bindings/arm/vexpress.txt
b/Documentation/devicetree/bindings/arm/vexpress.txt
index 39844cd..b6031d9 100644
--- a/Documentation/devicetree/bindings/arm/vexpress.txt
+++ b/Documentation/devicetree/bindings/arm/vexpress.txt
@@ -223,7 +223,7 @@ Example of a VE tile description (simplified)
/* Active high IRQ 0 is connected to GIC's SPI0 */
interrupt-map = 0 0 0 gic 0 0 4;
- /include/ vexpress-v2m-rs1.dtsi
+ /include/ arm/vexpress-v2m-rs1.dtsi
};
};
diff --git a/MAINTAINERS b/MAINTAINERS
index a226416..1941078 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7537,6 +7537,7 @@ S:Maintained
F: Documentation/devicetree/
F: arch/*/boot/dts/
F: include/dt-bindings/
+F: kernel/dts/
OPEN FIRMWARE AND DEVICE TREE OVERLAYS
M: Pantelis Antoniou pantelis.anton...@konsulko.com
diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
b/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
index 9420053..b144092 100644
--- a/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
+++ b/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
@@ -278,6 +278,6 @@
0 0 41 gic 0 41 4,
0 0 42 gic 0 42 4;
- /include/ vexpress-v2m-rs1.dtsi
+ /include/ arm/vexpress-v2m-rs1.dtsi
};
};
diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
index 17f63f7..350f402 100644
--- a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
+++ b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
@@ -636,6 +636,6 @@
0 0 41 gic 0 41 4,
0 0 42 gic 0 42 4;
- /include/ vexpress-v2m-rs1.dtsi
+ /include/ arm/vexpress-v2m-rs1.dtsi
};
};
diff --git a/arch/arm/boot/dts/vexpress-v2p-ca5s.dts
b/arch/arm/boot/dts/vexpress-v2p-ca5s.dts
index d2709b7..585ced0 100644
--- a/arch/arm/boot/dts/vexpress-v2p-ca5s.dts
+++ b/arch/arm/boot/dts/vexpress-v2p-ca5s.dts
@@
Re: [PATCH V3 2/6] of/slimbus: OF helper for SLIMbus
On Mon, Aug 3, 2015 at 1:59 AM, Sagar Dharia sdha...@codeaurora.org wrote:
OF helper routine scans the SLIMbus DeviceTree, allocates resources,
and creates slim_devices according to the hierarchy.
Signed-off-by: Sagar Dharia sdha...@codeaurora.org
---
Documentation/devicetree/bindings/slimbus/bus.txt | 46 ++
drivers/slimbus/slim-core.c | 75
+++
2 files changed, 121 insertions(+)
create mode 100644 Documentation/devicetree/bindings/slimbus/bus.txt
diff --git a/Documentation/devicetree/bindings/slimbus/bus.txt
b/Documentation/devicetree/bindings/slimbus/bus.txt
new file mode 100644
index 000..a79ed7a
--- /dev/null
+++ b/Documentation/devicetree/bindings/slimbus/bus.txt
@@ -0,0 +1,46 @@
+SLIM(Serial Low Power Interchip Media Bus) bus
+
+SLIMbus is a 2-wire bus, and is used to communicate with peripheral
+components like audio-codec.
+
+Controller is a normal device using binding for whatever bus it is
+on (e.g. platform bus).
+Required property for SLIMbus controller node:
+- compatible - name of SLIMbus controller following generic names
+ recommended practice.
+- #address-cells - should be 6 (number of cells required to define
+ enumeration address of the device on SLIMbus)
+- #size-cells - should be 0
+
+No other properties are required in the SLIMbus controller bus node.
+
+Child nodes:
+Every SLIMbus controller node can contain zero or more child nodes
+representing slave devices on the bus. Every SLIMbus slave device is
+uniquely determined by the 6 byte enumeration address.
+
+Required property for SLIMbus child node:
+- reg - 6 byte enumeration address of the slave
6 cell... I don't think it is a big deal to use 6 words to store 6
bytes, but is there some reason not to pack the address into 2 cells?
+
+Optional:
+- compatible - Slave devices can use compatible field to have a name.
+ If this field is missing, name of the device will be
+ determined using slave's enumeration address.
+ (e.g. in the example below, slave's name will be:
+ 0x217:0x60:0x1:0x0)
Are devices discoverable and uniquely identifiable? This would be
something like a VID/PID which can be read in a generic way. It looks
like the address contains this info, but can you discover the
addresses of devices on the bus? If not compatible should not be
optional.
+
+SLIMbus example for Qualcomm's slimbus manager compoent:
typo.
+
+ slim@2808 {
+ compatible = qcom,slim-msm;
+ reg = 0x2808 0x2000,
+ reg-names = slimbus_physical;
Pretty pointless to have names with a single element.
+ interrupts = 0 33 0;
+ interrupt-names = slimbus_irq;
+ clocks = lcc SLIMBUS_SRC, lcc AUDIO_SLIMBUS_CLK;
+ clock-names = iface_clk, core_clk;
+
+ slim_codec_slave {
You should have unit address here. Probably with . in between fields
of the address that have defined meaning. So that may be something
like 0217.0060.01.00 based on what you do with the address bytes
below.
+ reg = 00 01 60 00 17 02;
+ };
+ };
diff --git a/drivers/slimbus/slim-core.c b/drivers/slimbus/slim-core.c
index ee80c1b..d3fa28b 100644
--- a/drivers/slimbus/slim-core.c
+++ b/drivers/slimbus/slim-core.c
@@ -18,6 +18,7 @@
#include linux/idr.h
#include linux/pm_runtime.h
#include linux/slimbus.h
+#include linux/of.h
static DEFINE_MUTEX(slim_lock);
static DEFINE_IDR(ctrl_idr);
@@ -289,6 +290,79 @@ static LIST_HEAD(board_list);
static LIST_HEAD(slim_ctrl_list);
static DEFINE_MUTEX(board_lock);
+#if IS_ENABLED(CONFIG_OF)
+/* OF helpers for SLIMbus */
+static void of_register_slim_devices(struct slim_controller *ctrl)
+{
+ struct device_node *node;
+ struct slim_boardinfo *temp, *binfo = NULL;
+ int n = 0;
+
+ if (!ctrl-dev.of_node)
+ return;
+
+ for_each_child_of_node(ctrl-dev.of_node, node) {
+ int ret;
+ u32 ea[6];
+ struct slim_device *slim;
+ char *name;
+
+ ret = of_property_read_u32_array(node, reg, ea, 6);
+ if (ret) {
+ dev_err(ctrl-dev, of_slim: E-addr err:%d\n, ret);
+ continue;
+ }
+ name = kcalloc(SLIMBUS_NAME_SIZE, sizeof(char), GFP_KERNEL);
+ if (!name)
+ goto of_slim_err;
+
+ slim = kzalloc(sizeof(struct slim_device), GFP_KERNEL);
+ if (!slim) {
+ kfree(name);
+ goto of_slim_err;
+ }
+ slim-e_addr.manf_id = (u16)((ea[5] 8) | ea[4]);
+ slim-e_addr.prod_code = (u16)((ea[3] 8) | ea[2]);
+
Re: [PATCH 2/3] iio: temperature: add max6675 thermocouple converter driver
On Mon, Aug 3, 2015 at 1:56 PM, Matt Porter mpor...@konsulko.com wrote:
Add a driver for the MAX6675 thermocouple converter. This
device interfaces with K-type thermocouples and provides
cold-junction compensated temperature readings via a
SPI interface.
Signed-off-by: Matt Porter mpor...@konsulko.com
---
drivers/iio/temperature/Kconfig | 11 +++
drivers/iio/temperature/Makefile | 1 +
drivers/iio/temperature/max6675.c | 155
++
3 files changed, 167 insertions(+)
create mode 100644 drivers/iio/temperature/max6675.c
diff --git a/drivers/iio/temperature/Kconfig b/drivers/iio/temperature/Kconfig
index 21feaa4..b73fbf4 100644
--- a/drivers/iio/temperature/Kconfig
+++ b/drivers/iio/temperature/Kconfig
@@ -3,6 +3,17 @@
#
menu Temperature sensors
+config MAX6675
+ tristate MAX6675 thermocouple converter
+ depends on SPI
+ help
+ If you say yes here you get support for the Maxim
+ MAX6675 thermocouple converter connected with SPI.
+
+ This driver can also be built as a module. If so, the module will
+ be called max6675.
+
+
config MLX90614
tristate MLX90614 contact-less infrared sensor
depends on I2C
diff --git a/drivers/iio/temperature/Makefile
b/drivers/iio/temperature/Makefile
index 40710a8..d67ef40 100644
--- a/drivers/iio/temperature/Makefile
+++ b/drivers/iio/temperature/Makefile
@@ -2,5 +2,6 @@
# Makefile for industrial I/O temperature drivers
#
+obj-$(CONFIG_MAX6675) += max6675.o
obj-$(CONFIG_MLX90614) += mlx90614.o
obj-$(CONFIG_TMP006) += tmp006.o
diff --git a/drivers/iio/temperature/max6675.c
b/drivers/iio/temperature/max6675.c
new file mode 100644
index 000..2d1fda2
--- /dev/null
+++ b/drivers/iio/temperature/max6675.c
@@ -0,0 +1,155 @@
+/*
+ * max6675.c - MAX6675 thermocouple converter driver
+ *
+ * Copyright (C) 2015 Konsulko Group, Matt Porter mpor...@konsulko.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include linux/acpi.h
+#include linux/init.h
+#include linux/module.h
+#include linux/of.h
+#include linux/iio/iio.h
+#include linux/spi/spi.h
+
+struct max6675_state {
+ struct spi_device *spi;
+};
+
+static const struct iio_chan_spec max6675_channels[] = {
+ {
+ .type = IIO_TEMP,
+ .info_mask_separate =
+ BIT(IIO_CHAN_INFO_RAW) |
+ BIT(IIO_CHAN_INFO_SCALE),
+ },
+};
+
+static int max6675_read(struct max6675_state *st, int *val)
+{
+ int ret;
+
+ ret = spi_read(st-spi, val, 2);
+ if (ret 0)
+ return ret;
+
+ /* Temperature is bits 14..3 */
+ *val = (*val 3) 0xfff;
+
+ return ret;
+}
+
+static int max6675_read_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+ int *val,
+ int *val2,
+ long m)
+{
+ struct max6675_state *st = iio_priv(indio_dev);
+ int ret;
+
+ if (m == IIO_CHAN_INFO_RAW) {
+ *val2 = 0;
+ ret = max6675_read(st, val);
+ if (ret)
+ return ret;
+ } else if (m == IIO_CHAN_INFO_SCALE) {
+ *val = 250;
+ *val2 = 0;
+ } else
+ return -EINVAL;
+
+ return IIO_VAL_INT;
+}
+
+static const struct iio_info max6675_info = {
+ .driver_module = THIS_MODULE,
+ .read_raw = max6675_read_raw,
+};
+
+static int max6675_probe(struct spi_device *spi)
+{
+ struct iio_dev *indio_dev;
+ struct max6675_state *st;
+ int ret = 0;
+
+ indio_dev = devm_iio_device_alloc(spi-dev, sizeof(*st));
+ if (!indio_dev)
+ return -ENOMEM;
+
+ st = iio_priv(indio_dev);
+ st-spi = spi;
+
+ spi-mode = SPI_MODE_1;
+ spi-bits_per_word = 16;
Have this error or display a warning when it doesn't match the passed
DT binding settings. Otherwise it may get confusing why other SPI
modes and word sizes don't work.
+
+ spi_set_drvdata(spi, indio_dev);
+
+ indio_dev-dev.parent = spi-dev;
+ indio_dev-name = spi_get_device_id(spi)-name;
+ indio_dev-channels = max6675_channels;
+ indio_dev-num_channels = ARRAY_SIZE(max6675_channels);
+ indio_dev-modes = INDIO_DIRECT_MODE;
+
Re: [PATCH v8 00/23] usb gadget update for OTG 2.0
On Thu, Jul 30, 2015 at 09:10:06AM -0500, Felipe Balbi wrote: On Thu, Jul 30, 2015 at 09:46:58AM +0800, Li Jun wrote: On Wed, Jul 29, 2015 at 09:11:41PM -0500, Felipe Balbi wrote: On Thu, Jul 30, 2015 at 07:24:03AM +0800, Li Jun wrote: On Wed, Jul 29, 2015 at 10:04:27AM -0500, Felipe Balbi wrote: On Mon, Jul 27, 2015 at 03:21:59PM +0800, Peter Chen wrote: On Thu, Jul 23, 2015 at 11:37:24AM +0800, Li Jun wrote: Change for v8: - Add Peter's ACk for chipidea driver; and Roger's Reviewed-by for patch 07, 21~23. - Add ci-is_otg condition before enable ci-gadget.is_otg for chipidea driver in patch 8. Hi Felipe, For chipidea patches in this series, help to queue them in your tree please, thanks. all there, please make sure they're correct. There were so many versions of this series that I might have picked up the wrong one :-p Patch [8/23]: usb: chipidea: set usb otg capabilities, you picked up the V7, I have a small change for V8, others are correct. Can you send an incremental diff, please ? diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c index 61fde89..c6d1595 100644 --- a/drivers/usb/chipidea/udc.c +++ b/drivers/usb/chipidea/udc.c @@ -1838,8 +1838,8 @@ static int udc_start(struct ci_hdrc *ci) ci-gadget.name = ci-platdata-name; ci-gadget.otg_caps = otg_caps; - if (otg_caps-hnp_support || otg_caps-srp_support || - otg_caps-adp_support) + if (ci-is_otg (otg_caps-hnp_support || otg_caps-srp_support || + otg_caps-adp_support)) ci-gadget.is_otg = 1; INIT_LIST_HEAD(ci-gadget.ep_list); I need it as a real patch with Signed-off-by and all, so I can apply :-) Hi Felipe, I have sent it out as a formal patch for this incremental diff, but still not in your next tree. [PATCH] usb: chipidea: add ci-is_otg condition for otg judgement https://www.mail-archive.com/linux-usb@vger.kernel.org/msg62227.html Li Jun -- balbi -- 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/5] clk: hisi: refine parameter checking for init
On 08/03, Leo Yan wrote: *of_iomap()* will check the device node pointer, and if the pointer is NULL it will return error code. So refine clock's init flow by checking the device node with this simple way; and polish a little for the print out message. Signed-off-by: Leo Yan leo@linaro.org --- Applied to clk-next -- 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 v3] ARM: shmobile: silk: initial device tree
On Mon, Aug 03, 2015 at 06:13:38PM +0300, Sergei Shtylyov wrote:
Hello.
On 08/03/2015 04:00 PM, Geert Uytterhoeven wrote:
--- /dev/null
+++ renesas/arch/arm/boot/dts/r8a7794-silk.dts
@@ -0,0 +1,51 @@
+/ {
+ model = SILK;
+ compatible = renesas,silk, renesas,r8a7794;
WARNING: DT compatible string renesas,silk appears un-documented --
check ./Documentation/devicetree/bindings/
Do you plan to update Documentation/devicetree/bindings/arm/shmobile.txt?
No, I had no idea I should record the board names somewhere too...
Sergei, please submit a parch as suggested by Geert.
--
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] irqchip: bcm2836: Use a CPU notifier enable IPIs.
Thomas Gleixner t...@linutronix.de writes:
On Mon, 27 Jul 2015, Eric Anholt wrote:
+/* Unmasks the IPI on the CPU wen it's first brought online. */
when
+static int bcm2836_arm_irqchip_cpu_notify(struct notifier_block *nfb,
+ unsigned long action, void *hcpu)
+{
+unsigned int cpu = (unsigned long)hcpu;
+unsigned int int_reg = LOCAL_MAILBOX_INT_CONTROL0;
+unsigned int mailbox = 0;
+
+if (action == CPU_STARTING || action == CPU_STARTING_FROZEN)
+bcm2836_arm_irqchip_unmask_per_cpu_irq(int_reg, mailbox, cpu);
Shouldn't you mask the irq on CPU_DYING?
I was just following what other drivers were doing. Is CPU_DYING the
only thing that needs masking?
signature.asc
Description: PGP signature
Re: [PATCH v2 06/10] usb: chipidea: add ahb burst configuration interface
On Mon, Aug 03, 2015 at 09:04:27AM -0500, Rob Herring wrote:
On Sun, Aug 2, 2015 at 11:47 PM, Peter Chen peter.c...@freescale.com wrote:
The users can change it through dts or platform data if they
want to change the default value.
Signed-off-by: Peter Chen peter.c...@freescale.com
---
drivers/usb/chipidea/bits.h | 3 +++
drivers/usb/chipidea/core.c | 14 ++
include/linux/usb/chipidea.h | 2 ++
3 files changed, 19 insertions(+)
diff --git a/drivers/usb/chipidea/bits.h b/drivers/usb/chipidea/bits.h
index 831a8f6..462ad02 100644
--- a/drivers/usb/chipidea/bits.h
+++ b/drivers/usb/chipidea/bits.h
@@ -25,6 +25,9 @@
#define VERSION (0xF 25)
#define CIVERSION(0x7 29)
+/* SBUSCFG */
+#define AHBBRST_MASK 0x7
+
/* HCCPARAMS */
#define HCCPARAMS_LEN BIT(17)
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 38bd036..f60cbf6 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -439,6 +439,9 @@ void ci_platform_configure(struct ci_hdrc *ci)
hw_write(ci, OP_USBCMD, 0xff, ci-platdata-itc_setting 16);
+ if (ci-platdata-flags CI_HDRC_OVERRIDE_AHB_BURST)
+ hw_write_id_reg(ci, ID_SBUSCFG, AHBBRST_MASK,
+ ci-platdata-ahb_burst_config);
}
/**
@@ -647,6 +650,17 @@ static int ci_get_platdata(struct device *dev,
}
}
+ if (of_find_property(dev-of_node, ahb-burst-config, NULL)) {
+ ret = of_property_read_u32(dev-of_node, ahb-burst-config,
+ platdata-ahb_burst_config);
+ if (ret) {
+ dev_err(dev,
+ failed to get ahb-burst-config\n);
+ return ret;
+ }
+ platdata-flags |= CI_HDRC_OVERRIDE_AHB_BURST;
+ }
+
This can be simplified to:
ret = of_property_read_u32(dev-of_node, ahb-burst-config,
platdata-ahb_burst_config);
if (!ret)
platdata-flags |= CI_HDRC_OVERRIDE_AHB_BURST;
The error condition can't really happen.
Rob
Thanks, I will change others accordingly.
--
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 2/3] iio: temperature: add max6675 thermocouple converter driver
On Mon, Aug 03, 2015 at 03:39:00PM -0700, Matt Ranostay Matt Ranostay wrote:
On Mon, Aug 3, 2015 at 1:56 PM, Matt Porter mpor...@konsulko.com wrote:
...
+static int max6675_probe(struct spi_device *spi)
+{
+ struct iio_dev *indio_dev;
+ struct max6675_state *st;
+ int ret = 0;
+
+ indio_dev = devm_iio_device_alloc(spi-dev, sizeof(*st));
+ if (!indio_dev)
+ return -ENOMEM;
+
+ st = iio_priv(indio_dev);
+ st-spi = spi;
+
+ spi-mode = SPI_MODE_1;
+ spi-bits_per_word = 16;
Have this error or display a warning when it doesn't match the passed
DT binding settings. Otherwise it may get confusing why other SPI
modes and word sizes don't work.
Ok, good point. The only thing here is that I've specified that spi-cpha
is required in the binding, indicating that Mode 1 will be used. I need
this driver to be instantiated via three methods: ACPI, DT, and board
file so for the latter I'm hardcoding in the driver the mode. The
device only works in Mode 1 so this seems sane, it's not configurable.
I don't parse that mode from either DT or ACPI data since it's not
needed. About the only thing I could do is pedantically check for
spi-cpha and if not present complain..but I think it's fine to simply
not parse at all given that we've hardcoded this for the allowed mode.
There's no property for bits_per_word, it's configured on a per-transfer
basis. In this case, this configures the default to do a 16-bit transfer
as required by the device. There is no way to modify this by a client of
this driver.
-Matt
--
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 v3 0/2] iio: proximity: add PulsedLight LIDAR sensor support
PulsedLight blue label v2 LIDAR sensor can be polled over 100HZ with the sysfs + hrtimer iio trigger, or using single raw measurment. This patchset adds support for this range finding LIDAR module, and reports distance back in meters to centimeter resolution with +/- 2.5 CM of accuracy at ~40 meters. Changes from v2: * Add of_match_table for dt lookup * Return error if timeout happens in reading measurement * Document why i2c_smbus_read_byte_data can't be used * Add pulsedlight,lidar to trivial-devices.txt Matt Ranostay (2): devicetree: add PulsedLight vendor + device docs iio: proximity: add support for PulsedLight LIDAR .../devicetree/bindings/i2c/trivial-devices.txt| 1 + .../devicetree/bindings/vendor-prefixes.txt| 1 + drivers/iio/proximity/Kconfig | 12 + drivers/iio/proximity/Makefile | 1 + drivers/iio/proximity/lidar.c | 295 + 5 files changed, 310 insertions(+) create mode 100644 drivers/iio/proximity/lidar.c -- 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 v3 1/2] devicetree: add PulsedLight vendor + device docs
Add pulsedlight vendor to vendor-prefixes.txt, and LIDAR device documentation to trivial-devices.txt Signed-off-by: Matt Ranostay mranos...@gmail.com --- Documentation/devicetree/bindings/i2c/trivial-devices.txt | 1 + Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 2 files changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt b/Documentation/devicetree/bindings/i2c/trivial-devices.txt index d77d412..9d0e781 100644 --- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt +++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt @@ -80,6 +80,7 @@ oki,ml86v7667 OKI ML86V7667 video decoder ovti,ov5642OV5642: Color CMOS QSXGA (5-megapixel) Image Sensor with OmniBSI and Embedded TrueFocus pericom,pt7c4338 Real-time Clock Module plx,pex864848-Lane, 12-Port PCI Express Gen 2 (5.0 GT/s) Switch +pulsedlight,lidar Pulsedlight LIDAR range-finding sensor ramtron,24c64 i2c serial eeprom (24cxx) ricoh,r2025sd I2C bus SERIAL INTERFACE REAL-TIME CLOCK IC ricoh,r2221tl I2C bus SERIAL INTERFACE REAL-TIME CLOCK IC diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 6284568..0f318c3 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -164,6 +164,7 @@ phytec PHYTEC Messtechnik GmbH picochip Picochip Ltd plathome Plat'Home Co., Ltd. pixcir PIXCIR MICROELECTRONICS Co., Ltd +pulsedlightPulsedLight, Inc powervrPowerVR (deprecated, use img) qcaQualcomm Atheros, Inc. qcom Qualcomm Technologies, Inc -- 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 v3 2/2] iio: proximity: add support for PulsedLight LIDAR
Add support for the PulsedLight LIDAR rangefinder sensor which allows
high speed (over 300Hz) distance measurements using Barker Coding within
40 meter range.
Support only tested on the blue label rev 2, but may work using low
sample frequencies on the original version.
Signed-off-by: Matt Ranostay mranos...@gmail.com
---
drivers/iio/proximity/Kconfig | 12 ++
drivers/iio/proximity/Makefile | 1 +
drivers/iio/proximity/lidar.c | 295 +
3 files changed, 308 insertions(+)
create mode 100644 drivers/iio/proximity/lidar.c
diff --git a/drivers/iio/proximity/Kconfig b/drivers/iio/proximity/Kconfig
index 41a8d8f..e64fc5b 100644
--- a/drivers/iio/proximity/Kconfig
+++ b/drivers/iio/proximity/Kconfig
@@ -20,6 +20,18 @@ endmenu
menu Proximity sensors
+config LIDAR
+ tristate PulsedLight LIDAR sensor
+ select IIO_BUFFER
+ select IIO_TRIGGERED_BUFFER
+ depends on I2C
+ help
+ Say Y to build a driver for PulsedLight LIDAR range finding
+ sensor.
+
+ To compile this driver as a module, choose M here: the
+ module will be called lidar.
+
config SX9500
tristate SX9500 Semtech proximity sensor
select IIO_BUFFER
diff --git a/drivers/iio/proximity/Makefile b/drivers/iio/proximity/Makefile
index 9818dc5..36a95f3 100644
--- a/drivers/iio/proximity/Makefile
+++ b/drivers/iio/proximity/Makefile
@@ -4,4 +4,5 @@
# When adding new entries keep the list in alphabetical order
obj-$(CONFIG_AS3935) += as3935.o
+obj-$(CONFIG_LIDAR)+= lidar.o
obj-$(CONFIG_SX9500) += sx9500.o
diff --git a/drivers/iio/proximity/lidar.c b/drivers/iio/proximity/lidar.c
new file mode 100644
index 000..133e016
--- /dev/null
+++ b/drivers/iio/proximity/lidar.c
@@ -0,0 +1,295 @@
+/*
+ * lidar.c - Support for PulsedLight LIDAR range finding sensor
+ *
+ * Copyright (C) 2015 Matt Ranostay mranos...@gmail.com
+ *
+ * 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.
+ *
+ * TODO: runtime pm, interrupt mode, and signal strength reporting
+ *
+ */
+
+#include linux/err.h
+#include linux/init.h
+#include linux/i2c.h
+#include linux/delay.h
+#include linux/mutex.h
+#include linux/module.h
+#include linux/iio/iio.h
+#include linux/iio/sysfs.h
+#include linux/iio/buffer.h
+#include linux/iio/trigger.h
+#include linux/iio/triggered_buffer.h
+#include linux/iio/trigger_consumer.h
+
+#define LIDAR_REG_CONTROL 0x00
+#define LIDAR_REG_CONTROL_ACQUIRE BIT(2)
+
+#define LIDAR_REG_STATUS 0x01
+#define LIDAR_REG_STATUS_INVALID BIT(3)
+#define LIDAR_REG_STATUS_READY BIT(0)
+
+#define LIDAR_REG_DATA_HBYTE 0x0f
+#define LIDAR_REG_DATA_LBYTE 0x10
+
+#define LIDAR_DRV_NAME lidar
+
+struct lidar_data {
+ struct mutex lock;
+ struct iio_dev *indio_dev;
+ struct i2c_client *client;
+
+ u16 buffer[5]; /* 2 byte distance + 8 byte timestamp */
+};
+
+static const struct iio_chan_spec lidar_channels[] = {
+ {
+ .type = IIO_DISTANCE,
+ .info_mask_separate =
+ BIT(IIO_CHAN_INFO_RAW) | BIT(IIO_CHAN_INFO_SCALE),
+ .scan_index = 0,
+ .scan_type = {
+ .sign = 'u',
+ .realbits = 16,
+ .storagebits = 16,
+ },
+ },
+ IIO_CHAN_SOFT_TIMESTAMP(1),
+};
+
+static int lidar_read_byte(struct lidar_data *data, int reg)
+{
+ struct i2c_client *client = data-client;
+ int ret;
+
+ ret = i2c_smbus_write_byte(client, reg);
+ if (ret 0) {
+ dev_err(client-dev, cannot write addr value);
+ return ret;
+ }
+
+ ret = i2c_smbus_read_byte(client);
+ if (ret 0) {
+ dev_err(client-dev, cannot read data value);
+ return ret;
+ }
+
+ return ret;
+}
+
+static inline int lidar_write_control(struct lidar_data *data, int val)
+{
+ return i2c_smbus_write_byte_data(data-client, LIDAR_REG_CONTROL, val);
+}
+
+static int lidar_read_measurement(struct lidar_data *data, u16 *reg)
+{
+ int ret;
+ int val;
+
+ /*
+* Device needs a STOP condition between address write, and data read
+* so in turn i2c_smbus_read_byte_data cannot be used
+*/
+
+ ret = lidar_read_byte(data, LIDAR_REG_DATA_HBYTE);
+ if (ret 0)
+ return ret;
+ val = ret 8;
+
+ ret = lidar_read_byte(data,
[PATCH] ARM64: dts: mt6795: enable basic SMP bringup for MT6795
This patch adds support SMP on MediaTek MT6795 Cortex-A53 Octa-core SoC.
The patch is based on v4.2-rc1 and following patch series:
(1) Mars Cheng's Add mt6795 basic chip support [1]
[1] https://lkml.org/lkml/2015/7/14/63
Signed-off-by: Scott Shu scott@mediatek.com
---
arch/arm64/boot/dts/mediatek/mt6795.dtsi | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt6795.dtsi
b/arch/arm64/boot/dts/mediatek/mt6795.dtsi
index da200e7..c85659d 100644
--- a/arch/arm64/boot/dts/mediatek/mt6795.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt6795.dtsi
@@ -20,6 +20,11 @@
#address-cells = 2;
#size-cells = 2;
+ psci {
+ compatible = arm,psci-0.2;
+ method = smc;
+ };
+
cpus {
#address-cells = 1;
#size-cells = 0;
@@ -27,48 +32,56 @@
cpu0: cpu@0 {
device_type = cpu;
compatible = arm,cortex-a53;
+ enable-method = psci;
reg = 0x000;
};
cpu1: cpu@1 {
device_type = cpu;
compatible = arm,cortex-a53;
+ enable-method = psci;
reg = 0x001;
};
cpu2: cpu@2 {
device_type = cpu;
compatible = arm,cortex-a53;
+ enable-method = psci;
reg = 0x002;
};
cpu3: cpu@3 {
device_type = cpu;
compatible = arm,cortex-a53;
+ enable-method = psci;
reg = 0x003;
};
cpu4: cpu@100 {
device_type = cpu;
compatible = arm,cortex-a53;
+ enable-method = psci;
reg = 0x100;
};
cpu5: cpu@101 {
device_type = cpu;
compatible = arm,cortex-a53;
+ enable-method = psci;
reg = 0x101;
};
cpu6: cpu@102 {
device_type = cpu;
compatible = arm,cortex-a53;
+ enable-method = psci;
reg = 0x102;
};
cpu7: cpu@103 {
device_type = cpu;
compatible = arm,cortex-a53;
+ enable-method = psci;
reg = 0x103;
};
};
--
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
Re: [PATCH v5] powerpc/rcpm: add RCPM driver
On Tue, Aug 4, 2015 at 4:23 AM, Scott Wood scottw...@freescale.com
wrote:
On Mon, 2015-08-03 at 19:14 +0800, Chenhui Zhao wrote:
On Sat, Aug 1, 2015 at 8:45 AM, Scott Wood scottw...@freescale.com
wrote:
On Fri, 2015-06-26 at 15:44 +0800,
Yuantian.Tang@freescale.comwrote:
+static void rcpm_v1_set_ip_power(bool enable, u32 *mask)
+{
+ if (enable)
+ setbits32(rcpm_v1_regs-ippdexpcr, *mask);
+ else
+ clrbits32(rcpm_v1_regs-ippdexpcr, *mask);
+}
+
+static void rcpm_v2_set_ip_power(bool enable, u32 *mask)
+{
+ if (enable)
+ setbits32(rcpm_v2_regs-ippdexpcr[0], *mask);
+ else
+ clrbits32(rcpm_v2_regs-ippdexpcr[0], *mask);
+}
Why do these take u32 *mask instead of u32 mask?
-Scott
I think it can be used in the case where there are several mask
values.
When would that be?
-Scott
So far, only use one register, even though the register name is
IPPDEXPCRn (has n suffix) in T4 RM.
OK. Just change the parameter to u32 mask.
-Chenhui
--
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] PCI: Store PCIe bus address in struct of_pci_range
On 2015. 8. 3., at PM 8:18, Gabriele Paoloni gabriele.paol...@huawei.com
wrote:
Rob, Kishon what about the following solution?
---
drivers/pci/host/pci-dra7xx.c | 12
drivers/pci/host/pcie-designware.c | 9 +++--
Hi Paoloni,
OK, it looks good.
I want you to revert the following patch.
commit f4c55c5a3f7f (PCI: designware: Program ATU with untranslated address)
Would you remove all '*_mode_base's?
Best regards,
Jingoo Han
2 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
index 80db09e..bb2635f 100644
--- a/drivers/pci/host/pci-dra7xx.c
+++ b/drivers/pci/host/pci-dra7xx.c
@@ -61,6 +61,7 @@
#definePCIECTRL_DRA7XX_CONF_PHY_CS0x010C
#defineLINK_UPBIT(16)
+#define CPU_TO_BUS_ADDR 0x0FFF
struct dra7xx_pcie {
void __iomem*base;
@@ -138,6 +139,17 @@ static void dra7xx_pcie_enable_interrupts(struct
pcie_port *pp)
static void dra7xx_pcie_host_init(struct pcie_port *pp)
{
+if (pp-io_mod_base)
+pp-io_mod_base = CPU_TO_BUS_ADDR;
+
+if (pp-mem_mod_base)
+pp-mem_mod_base = CPU_TO_BUS_ADDR;
+
+if (pp-cfg0_mod_base) {
+pp-cfg0_mod_base = CPU_TO_BUS_ADDR;
+pp-cfg1_mod_base = CPU_TO_BUS_ADDR;
+}
+
dw_pcie_setup_rc(pp);
dra7xx_pcie_establish_link(pp);
if (IS_ENABLED(CONFIG_PCI_MSI))
diff --git a/drivers/pci/host/pcie-designware.c
b/drivers/pci/host/pcie-designware.c
index 69486be..06c682b 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -416,8 +416,7 @@ int dw_pcie_host_init(struct pcie_port *pp)
pp-io_base = range.cpu_addr;
/* Find the untranslated IO space address */
-pp-io_mod_base = of_read_number(parser.range -
- parser.np + na, ns);
+pp-io_mod_base = range.cpu_addr;;
}
if (restype == IORESOURCE_MEM) {
of_pci_range_to_resource(range, np, pp-mem);
@@ -426,8 +425,7 @@ int dw_pcie_host_init(struct pcie_port *pp)
pp-mem_bus_addr = range.pci_addr;
/* Find the untranslated MEM space address */
-pp-mem_mod_base = of_read_number(parser.range -
- parser.np + na, ns);
+pp-mem_mod_base = range.cpu_addr;
}
if (restype == 0) {
of_pci_range_to_resource(range, np, pp-cfg);
@@ -437,8 +435,7 @@ int dw_pcie_host_init(struct pcie_port *pp)
pp-cfg1_base = pp-cfg.start + pp-cfg0_size;
/* Find the untranslated configuration space address */
-pp-cfg0_mod_base = of_read_number(parser.range -
- parser.np + na, ns);
+pp-cfg0_mod_base = range.cpu_addr;
pp-cfg1_mod_base = pp-cfg0_mod_base +
pp-cfg0_size;
}
--
1.9.1
-Original Message-
From: linux-pci-ow...@vger.kernel.org [mailto:linux-pci-
ow...@vger.kernel.org] On Behalf Of Rob Herring
Sent: Friday, July 31, 2015 5:53 PM
To: Kishon Vijay Abraham I
Cc: Gabriele Paoloni; Bjorn Helgaas; a...@arndb.de;
lorenzo.pieral...@arm.com; Wangzhou (B); robh...@kernel.org;
james.mo...@arm.com; liviu.du...@arm.com; linux-...@vger.kernel.org;
linux-arm-ker...@lists.infradead.org; devicetree@vger.kernel.org;
Yuanzhichang; Zhudacai; zhangjukuo; qiuzhenfa; Liguozhu (Kenneth);
Jingoo Han; Pratyush Anand; Arnd Bergmann
Subject: Re: [PATCH v6] PCI: Store PCIe bus address in struct
of_pci_range
On Fri, Jul 31, 2015 at 9:57 AM, Kishon Vijay Abraham I kis...@ti.com
wrote:
+Arnd
Hi,
On Friday 31 July 2015 07:55 PM, Gabriele Paoloni wrote:
[+cc Kishon]
-Original Message-
From: linux-pci-ow...@vger.kernel.org [mailto:linux-pci-
ow...@vger.kernel.org] On Behalf Of Rob Herring
Sent: Thursday, July 30, 2015 9:42 PM
To: Gabriele Paoloni
Cc: Bjorn Helgaas; a...@arndb.de; lorenzo.pieral...@arm.com;
Wangzhou
(B); robh...@kernel.org; james.mo...@arm.com; liviu.du...@arm.com;
linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
devicetree@vger.kernel.org; Yuanzhichang; Zhudacai; zhangjukuo;
qiuzhenfa; Liguozhu (Kenneth); Jingoo Han; Pratyush Anand
Subject: Re: [PATCH v6] PCI: Store PCIe bus address in struct
of_pci_range
On Thu, Jul 30, 2015 at 12:34 PM, Gabriele Paoloni
gabriele.paol...@huawei.com wrote:
-Original Message-
From: Bjorn Helgaas [mailto:bhelg...@google.com]
Sent: 30 July 2015 18:15
On Thu, Jul 30, 2015 at 04:50:55PM +, Gabriele Paoloni wrote:
-Original Message-
From: linux-pci-ow...@vger.kernel.org [mailto:linux-pci-
ow...@vger.kernel.org] On Behalf Of Bjorn Helgaas
Sent: Thursday, July 30, 2015 5:15 PM
On Thu, Jul 30, 2015 at 01:52:13PM +, Gabriele Paoloni
wrote:
[...]
I don’t think we should rely on [CPU] addresses...what if the
Re: [PATCH v3 1/6] mmc: sdhci-esdhc-imx: add imx7d support and support HS400
On Wed, Jul 29, 2015 at 05:03:52PM +0800, Haibo Chen wrote:
The imx7d usdhc is derived from imx6sx, the difference is that
imx7d support HS400.
So introduce a new compatible string for imx7d and add HS400
support for imx7d usdhc.
Signed-off-by: Haibo Chen haibo.c...@freescale.com
---
drivers/mmc/host/sdhci-esdhc-imx.c | 66
++
1 file changed, 66 insertions(+)
diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c
b/drivers/mmc/host/sdhci-esdhc-imx.c
index c6b9f64..b441eed 100644
--- a/drivers/mmc/host/sdhci-esdhc-imx.c
+++ b/drivers/mmc/host/sdhci-esdhc-imx.c
@@ -44,6 +44,7 @@
#define ESDHC_MIX_CTRL_EXE_TUNE (1 22)
#define ESDHC_MIX_CTRL_SMPCLK_SEL (1 23)
#define ESDHC_MIX_CTRL_FBCLK_SEL(1 25)
+#define ESDHC_MIX_CTRL_HS400_EN (1 26)
/* Bits 3 and 6 are not SDHCI standard definitions */
#define ESDHC_MIX_CTRL_SDHCI_MASK 0xb7
/* Tuning bits */
@@ -60,6 +61,16 @@
#define ESDHC_TUNE_CTRL_MIN 0
#define ESDHC_TUNE_CTRL_MAX ((1 7) - 1)
+/* strobe dll register */
+#define ESDHC_STROBE_DLL_CTRL0x70
+#define ESDHC_STROBE_DLL_CTRL_ENABLE (1 0)
+#define ESDHC_STROBE_DLL_CTRL_RESET (1 1)
+#define ESDHC_STROBE_DLL_CTRL_SLV_DLY_TARGET_SHIFT 3
+
+#define ESDHC_STROBE_DLL_STATUS 0x74
+#define ESDHC_STROBE_DLL_STS_REF_LOCK(1 1)
+#define ESDHC_STROBE_DLL_STS_SLV_LOCK0x1
+
#define ESDHC_TUNING_CTRL0xcc
#define ESDHC_STD_TUNING_EN (1 24)
/* NOTE: the minimum valid tuning start tap for mx6sl is 1 */
@@ -120,6 +131,8 @@
#define ESDHC_FLAG_ERR004536 BIT(7)
/* The IP supports HS200 mode */
#define ESDHC_FLAG_HS200 BIT(8)
+/* The IP supports HS400 mode */
+#define ESDHC_FLAG_SUP_HS400 BIT(9)
struct esdhc_soc_data {
u32 flags;
@@ -156,6 +169,12 @@ static struct esdhc_soc_data usdhc_imx6sx_data = {
| ESDHC_FLAG_HAVE_CAP1 | ESDHC_FLAG_HS200,
};
+static struct esdhc_soc_data usdhc_imx7d_data = {
+ .flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_STD_TUNING
+ | ESDHC_FLAG_HAVE_CAP1 | ESDHC_FLAG_HS200
+ | ESDHC_FLAG_SUP_HS400,
Better to use ESDHC_FLAG_HS400 to keep align with exist ESDHC_FLAG_HS200.
Regards
Dong Aisheng
--
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 R8A7794 GPIO DT support
Hello. Here's the set of 2 patches against Simon Horman's 'renesas.git' repo, 'renesas-devel-20150803-v4.2-rc5' tag. Here we add the GPIO device tree support for the R8A7794 SoC. [1/2] ARM: shmobile: r8a7794: add GPIO clocks [2/2] ARM: shmobile: r8a7794: add GPIO DT support WBR, Sergei -- 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 4/5] clk: Hi6220: add stub clock driver
On 08/03, Leo Yan wrote:
diff --git a/drivers/clk/hisilicon/clk-hi6220-stub.c
b/drivers/clk/hisilicon/clk-hi6220-stub.c
new file mode 100644
index 000..0931666
--- /dev/null
+++ b/drivers/clk/hisilicon/clk-hi6220-stub.c
@@ -0,0 +1,279 @@
+/*
+ * Hi6220 stub clock driver
+ *
+ * Copyright (c) 2015 Hisilicon Limited.
+ * Copyright (c) 2015 Linaro Limited.
+ *
+ * Author: Leo Yan leo@linaro.org
+ *
+ * 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 linux/clkdev.h
Is this include used?
+#include linux/clk-provider.h
+#include linux/clk.h
Is this include used?
+#include linux/err.h
+#include linux/mfd/syscon.h
+#include linux/mailbox_client.h
+#include linux/of.h
+#include linux/of_device.h
+#include linux/regmap.h
+#include linux/slab.h
+#include linux/kernel.h
+
+#include dt-bindings/clock/hi6220-clock.h
+
+/* Stub clocks id */
+#define HI6220_STUB_ACPU00
+#define HI6220_STUB_ACPU11
+#define HI6220_STUB_GPU 2
+#define HI6220_STUB_DDR 5
+
+/* Mailbox message */
+#define HI6220_MBOX_MSG_LEN 8
+
+#define HI6220_MBOX_FREQ (0xA)
+#define HI6220_MBOX_CMD_SET (0x3)
+#define HI6220_MBOX_OBJ_AP (0x0)
+
+/* CPU dynamic frequency scaling */
+#define ACPU_DFS_FREQ_MAX(0x1724)
+#define ACPU_DFS_CUR_FREQ(0x17CC)
+#define ACPU_DFS_FLAG(0x1B30)
+#define ACPU_DFS_FREQ_REQ(0x1B34)
+#define ACPU_DFS_FREQ_LMT(0x1B38)
+#define ACPU_DFS_LOCK_FLAG (0xAEAEAEAE)
We don't need parenthesis around single values in these macros.
+
+#define to_stub_clk(hw) container_of(hw, struct hi6220_stub_clk, hw)
+
+struct hi6220_stub_clk {
+ u32 id;
+ u32 rate;
+
+ struct device *dev;
+ struct clk_hw hw;
+
+ struct regmap *dfs_map;
+ struct mbox_client cl;
+ struct mbox_chan *mbox;
+};
+
+struct hi6220_mbox_msg {
+ unsigned char type;
+ unsigned char cmd;
+ unsigned char obj;
+ unsigned char src;
+ unsigned char para[4];
+};
+
+union hi6220_mbox_data {
+ unsigned int data[HI6220_MBOX_MSG_LEN];
+ struct hi6220_mbox_msg msg;
+};
+
+static unsigned int hi6220_acpu_get_freq(struct hi6220_stub_clk *stub_clk)
+{
+ unsigned int freq;
+
+ regmap_read(stub_clk-dfs_map, ACPU_DFS_CUR_FREQ, freq);
+ return freq;
+}
+
+static int hi6220_acpu_set_freq(struct hi6220_stub_clk *stub_clk,
+ unsigned int freq)
+{
+ union hi6220_mbox_data data;
+
+ stub_clk-mbox = mbox_request_channel(stub_clk-cl, 0);
Why not request the channel once in probe?
+ if (IS_ERR(stub_clk-mbox)) {
+ dev_err(stub_clk-dev, failed get mailbox channel\n);
+ return PTR_ERR(stub_clk-mbox);
+ };
+
+ /* set the frequency in sram */
+ regmap_write(stub_clk-dfs_map, ACPU_DFS_FREQ_REQ, freq);
+
+ /* compound mailbox message */
+ data.msg.type = HI6220_MBOX_FREQ;
+ data.msg.cmd = HI6220_MBOX_CMD_SET;
+ data.msg.obj = HI6220_MBOX_OBJ_AP;
+ data.msg.src = HI6220_MBOX_OBJ_AP;
+
+ mbox_send_message(stub_clk-mbox, data);
+ mbox_free_channel(stub_clk-mbox);
+ return 0;
+}
+
+static int hi6220_acpu_round_freq(struct hi6220_stub_clk *stub_clk,
+ unsigned int freq)
+{
+ unsigned int limit_flag, limit_freq = UINT_MAX;
+ unsigned int max_freq;
+
+ /* check the constrainted frequency */
s/constrainted/constrained/ ?
+ regmap_read(stub_clk-dfs_map, ACPU_DFS_FLAG, limit_flag);
+ if (limit_flag == ACPU_DFS_LOCK_FLAG)
+ regmap_read(stub_clk-dfs_map, ACPU_DFS_FREQ_LMT, limit_freq);
+
+ /* check the supported maximum frequency */
+ regmap_read(stub_clk-dfs_map, ACPU_DFS_FREQ_MAX, max_freq);
+
+ /* calculate the real maximum frequency */
+ max_freq = min(max_freq, limit_freq);
+
+ if (WARN_ON(freq max_freq))
+ freq = max_freq;
+
+ return freq;
+}
+
+static unsigned long hi6220_stub_clk_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ u32 rate = 0;
+ struct hi6220_stub_clk *stub_clk = to_stub_clk(hw);
+
+ switch (stub_clk-id) {
+ case HI6220_STUB_ACPU0:
+ rate = hi6220_acpu_get_freq(stub_clk);
+
+ /* convert from KHz to Hz */
s/KHz/kHz/ ?
+ rate *= 1000;
+ break;
+
+ default:
+ dev_err(stub_clk-dev, %s: un-supported clock id %d\n,
+ __func__, stub_clk-id);
+ break;
+ }
+
+ return rate;
+}
+
+static int hi6220_stub_clk_set_rate(struct clk_hw *hw, unsigned long rate,
+
[PATCH v2 1/2] ARM: shmobile: r8a7794: add GPIO clocks
Describe the GPIO clocks in the R8A7794 device tree.
Based on the original patch by Koji Matsuoka koji.matsuoka...@renesas.com.
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
Acked-by: Geert Uytterhoeven geert+rene...@glider.be
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
Changes in version 2:
- refreshed the patch;
- added Geert's and Laurent's ACKs.
arch/arm/boot/dts/r8a7794.dtsi | 22 ++
1 file changed, 14 insertions(+), 8 deletions(-)
Index: renesas/arch/arm/boot/dts/r8a7794.dtsi
===
--- renesas.orig/arch/arm/boot/dts/r8a7794.dtsi
+++ renesas/arch/arm/boot/dts/r8a7794.dtsi
@@ -720,16 +720,22 @@
mstp9_clks: mstp9_clks@e6150994 {
compatible = renesas,r8a7794-mstp-clocks,
renesas,cpg-mstp-clocks;
reg = 0 0xe6150994 0 4, 0 0xe61509a4 0 4;
- clocks = cpg_clocks R8A7794_CLK_QSPI, hp_clk,
hp_clk,
- hp_clk, hp_clk, hp_clk, hp_clk;
+ clocks = cp_clk, cp_clk, cp_clk, cp_clk,
+cp_clk, cp_clk, cp_clk,
+cpg_clocks R8A7794_CLK_QSPI, hp_clk,
hp_clk,
+hp_clk, hp_clk, hp_clk, hp_clk;
#clock-cells = 1;
- clock-indices =
- R8A7794_CLK_QSPI_MOD R8A7794_CLK_I2C5
R8A7794_CLK_I2C4
- R8A7794_CLK_I2C3 R8A7794_CLK_I2C2
R8A7794_CLK_I2C1
- R8A7794_CLK_I2C0
- ;
+ clock-indices = R8A7794_CLK_GPIO6 R8A7794_CLK_GPIO5
+R8A7794_CLK_GPIO4 R8A7794_CLK_GPIO3
+R8A7794_CLK_GPIO2 R8A7794_CLK_GPIO1
+R8A7794_CLK_GPIO0 R8A7794_CLK_QSPI_MOD
+R8A7794_CLK_I2C5 R8A7794_CLK_I2C4
+R8A7794_CLK_I2C3 R8A7794_CLK_I2C2
+R8A7794_CLK_I2C1 R8A7794_CLK_I2C0;
clock-output-names =
- qspi_mod, i2c5, i2c4, i2c3, i2c2,
i2c1, i2c0;
+ gpio6, gpio5, gpio4, gpio3, gpio2,
+ gpio1, gpio0, qspi_mod,
+ i2c5, i2c4, i2c3, i2c2, i2c1, i2c0;
};
mstp11_clks: mstp11_clks@e615099c {
compatible = renesas,r8a7794-mstp-clocks,
renesas,cpg-mstp-clocks;
--
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] ARM: shmobile: r8a7794: add GPIO DT support
Describe GPIO[0-6] controllers in the R8A7794 device tree.
Based on original patch by Hisashi Nakamura hisashi.nakamura...@renesas.com.
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
Acked-by: Geert Uytterhoeven geert+rene...@glider.be
---
Changes in version 2:
- fixed gpio-ranges property's last value for GPIO1/5/6;
- added Geert's ACK.
arch/arm/boot/dts/r8a7794.dtsi | 84 +
1 file changed, 84 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7794.dtsi
===
--- renesas.orig/arch/arm/boot/dts/r8a7794.dtsi
+++ renesas/arch/arm/boot/dts/r8a7794.dtsi
@@ -50,6 +50,90 @@
interrupts = 1 9 (GIC_CPU_MASK_SIMPLE(2) |
IRQ_TYPE_LEVEL_HIGH);
};
+ gpio0: gpio@e605 {
+ compatible = renesas,gpio-r8a7794, renesas,gpio-rcar;
+ reg = 0 0xe605 0 0x50;
+ interrupts = 0 4 IRQ_TYPE_LEVEL_HIGH;
+ #gpio-cells = 2;
+ gpio-controller;
+ gpio-ranges = pfc 0 0 32;
+ #interrupt-cells = 2;
+ interrupt-controller;
+ clocks = mstp9_clks R8A7794_CLK_GPIO0;
+ };
+
+ gpio1: gpio@e6051000 {
+ compatible = renesas,gpio-r8a7794, renesas,gpio-rcar;
+ reg = 0 0xe6051000 0 0x50;
+ interrupts = 0 5 IRQ_TYPE_LEVEL_HIGH;
+ #gpio-cells = 2;
+ gpio-controller;
+ gpio-ranges = pfc 0 32 26;
+ #interrupt-cells = 2;
+ interrupt-controller;
+ clocks = mstp9_clks R8A7794_CLK_GPIO1;
+ };
+
+ gpio2: gpio@e6052000 {
+ compatible = renesas,gpio-r8a7794, renesas,gpio-rcar;
+ reg = 0 0xe6052000 0 0x50;
+ interrupts = 0 6 IRQ_TYPE_LEVEL_HIGH;
+ #gpio-cells = 2;
+ gpio-controller;
+ gpio-ranges = pfc 0 64 32;
+ #interrupt-cells = 2;
+ interrupt-controller;
+ clocks = mstp9_clks R8A7794_CLK_GPIO2;
+ };
+
+ gpio3: gpio@e6053000 {
+ compatible = renesas,gpio-r8a7794, renesas,gpio-rcar;
+ reg = 0 0xe6053000 0 0x50;
+ interrupts = 0 7 IRQ_TYPE_LEVEL_HIGH;
+ #gpio-cells = 2;
+ gpio-controller;
+ gpio-ranges = pfc 0 96 32;
+ #interrupt-cells = 2;
+ interrupt-controller;
+ clocks = mstp9_clks R8A7794_CLK_GPIO3;
+ };
+
+ gpio4: gpio@e6054000 {
+ compatible = renesas,gpio-r8a7794, renesas,gpio-rcar;
+ reg = 0 0xe6054000 0 0x50;
+ interrupts = 0 8 IRQ_TYPE_LEVEL_HIGH;
+ #gpio-cells = 2;
+ gpio-controller;
+ gpio-ranges = pfc 0 128 32;
+ #interrupt-cells = 2;
+ interrupt-controller;
+ clocks = mstp9_clks R8A7794_CLK_GPIO4;
+ };
+
+ gpio5: gpio@e6055000 {
+ compatible = renesas,gpio-r8a7794, renesas,gpio-rcar;
+ reg = 0 0xe6055000 0 0x50;
+ interrupts = 0 9 IRQ_TYPE_LEVEL_HIGH;
+ #gpio-cells = 2;
+ gpio-controller;
+ gpio-ranges = pfc 0 160 28;
+ #interrupt-cells = 2;
+ interrupt-controller;
+ clocks = mstp9_clks R8A7794_CLK_GPIO5;
+ };
+
+ gpio6: gpio@e6055400 {
+ compatible = renesas,gpio-r8a7794, renesas,gpio-rcar;
+ reg = 0 0xe6055400 0 0x50;
+ interrupts = 0 10 IRQ_TYPE_LEVEL_HIGH;
+ #gpio-cells = 2;
+ gpio-controller;
+ gpio-ranges = pfc 0 192 26;
+ #interrupt-cells = 2;
+ interrupt-controller;
+ clocks = mstp9_clks R8A7794_CLK_GPIO6;
+ };
+
cmt0: timer@ffca {
compatible = renesas,cmt-48-gen2;
reg = 0 0xffca 0 0x1004;
--
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: [linux-sunxi] [PATCH] ARM: dts: sunxi: Raise minimum CPU voltage for sun7i-a20 to a level all boards can supply
On Mon, Aug 03, 2015 at 10:37:51AM +0200, Timo Sigurdsson wrote: Hi Julian, Julian Calaby schrieb am 03.08.2015 01:35: sun7i-a20.dtsi contains an cpufreq operating point at 0.9 volts. Most A20 boards (or all?), however, do not allow the voltage to go below 1.0V. Thus, raise the voltage for the lowest operating point to 1.0V so all boards can actually use it. Surely it wouldn't be added here if some could supply 0.9v. Maybe. I just know some boards don't (e.g. Cubieboard 2, Cubietruck, BananaPi) and don't know of any that does. But that's not my point. I think that a common minimum operating point, defined on the SOC level, should be defined in a way that works on all boards. All of them can supply it. The DCDC2 regulator they use for the CPU can go as low as 0.7V. The question is whether the CPU itself can work at such a low voltage. And the operating limits for the CPU is documented to be 1V - 1.4V. Anything else is either over or underclocking, which might or might not work on individual SoCs. So it's not something that we're going to support. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [linux-sunxi] [PATCH] ARM: dts: sunxi: Raise minimum CPU voltage for sun7i-a20 to a level all boards can supply
Hi Maxime, On Mon, Aug 3, 2015 at 7:34 PM, Maxime Ripard maxime.rip...@free-electrons.com wrote: On Mon, Aug 03, 2015 at 11:03:52AM +0200, Timo Sigurdsson wrote: Hi again, Julian Calaby schrieb am 03.08.2015 06:22: My only real objection here is are there boards that can go down to 0.9v and if so, won't this change make them less power efficient in the almost-idle case? And are those power savings enough to justify not accepting this patch? It will probably make those boards less power efficient, yes. On the other hand, boards that have their CPU regulator set to min. 1.0V might also draw more power because the lowest frequency is not available, even though the savings due to frequency are likely to be lower than the savings due to voltage. Guys, isn't this whole discussion a bit moot? We're not doing any kind of power management but cpufreq, so maybe there's a lot more to do before we actually can have these kind of arguments? Plus this OPP has never been used anyway, so this patch is not going to increase the power consumption either. Oh, I didn't know that. Therefore I withdraw my objections, patch away! Thanks, -- Julian Calaby Email: julian.cal...@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ -- 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 0/8] ARM64: juno: add SCPI mailbox protocol, clock and CPUFreq support
On Fri, Jul 31, 2015 at 06:43:03PM +0100, Sudeep Holla wrote: Hi ARM-SoC guys, It has been on the list for a while and have got all the necessary ACKs. Can you please pull this series for v4.3 ? Regards, Sudeep This patch series adds support for: 1. SCPI(System Control and Power Interface) mailbox protocol driver. It uses ARM MHU mailbox controller driver on Juno but can work with any mailbox controllers using standard mailbox APIs 2. Add support for clocks provided by SCP firmware through the SCPI interface 3. Using the existing arm_big_little cpufreq driver and the newly added SCPI clock driver, it also adds support for CPU DVFS on ARM64 JUNO development platforms. Hi Sudeep, Is there a branch where I can pull this series from? Best regards, Liviu The SCPI protocol document is available @[1],[2] Changes v5-v6: - Minor review comments on clock bindings and clock driver - Added all the ACKs necessary Changes v4-v5: - Updated the SCPI clock bindings to correct the clock specifier usage and other minor updates as per review feedback - Updated clock driver to use SCPI specifier clock specifier decode function - Minor reshuffling in Juno DTS files, no functionality change Changes v3-v4: - Updated the SCPI binding based on MarkR's feedback - Updated SCPI clock driver to incorporate Stephen Boyd's review comments + used clk_set_rate_range to limit the clock range - Since no major changes are expected in SCPI DT, updated the Juno DTS to support SCPI and dependent device nodes. Changes v2-v3: - Minor fix in SCPI driver and added Tixy's reviewed-by tag - Updated scpi clock driver to incorporate all the comments from Stephen - Added Viresh's ack Changes v1-v2: - Updated the token handling in scpi driver as per Tixy's suggestion along with other review comments - Removed multiple drivers in scpi clock as Lorenzo suggested - Added free_opp_table in scpi-cpufreq as Viresh suggested - Separated the DT binding document - Moved SCPI protocol driver to drivers/firmware [1] http://community.arm.com/servlet/JiveServlet/download/8401-45-18326/DUI0922B_scp_message_interface.pdf [2] https://wiki.linaro.org/ARM/Juno?action=AttachFiledo=gettarget=DUI0922B_scp_message_interface.pdf v1: https://lkml.org/lkml/2015/4/27/232 v2: https://lkml.org/lkml/2015/5/14/470 v3: https://lkml.org/lkml/2015/5/27/220 v4: https://lkml.org/lkml/2015/6/8/178 v5: https://lkml.org/lkml/2015/7/23/270 Cc: devicetree@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: linux...@vger.kernel.org Sudeep Holla (8): Documentation: add DT binding for ARM System Control and Power Interface(SCPI) protocol firmware: add support for ARM System Control and Power Interface(SCPI) protocol clk: add support for clocks provided by SCP(System Control Processor) clk: scpi: add support for cpufreq virtual device cpufreq: arm_big_little: add SCPI interface driver arm64: dts: add SRAM, MHU mailbox and SCPI support on Juno arm64: dts: add CPU topology on Juno arm64: dts: add clock support for all the cpus Documentation/devicetree/bindings/arm/arm,scpi.txt | 150 + MAINTAINERS| 10 + arch/arm64/boot/dts/arm/juno-base.dtsi | 54 ++ arch/arm64/boot/dts/arm/juno-r1.dts| 32 + arch/arm64/boot/dts/arm/juno.dts | 32 + drivers/clk/Kconfig| 10 + drivers/clk/Makefile | 1 + drivers/clk/clk-scpi.c | 325 ++ drivers/cpufreq/Kconfig.arm| 9 + drivers/cpufreq/Makefile | 1 + drivers/cpufreq/scpi-cpufreq.c | 124 drivers/firmware/Kconfig | 19 + drivers/firmware/Makefile | 1 + drivers/firmware/arm_scpi.c| 711 + include/linux/scpi_protocol.h | 61 ++ 15 files changed, 1540 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/arm,scpi.txt create mode 100644 drivers/clk/clk-scpi.c create mode 100644 drivers/cpufreq/scpi-cpufreq.c create mode 100644 drivers/firmware/arm_scpi.c create mode 100644 include/linux/scpi_protocol.h -- 1.9.1 -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ツ)_/¯ -- 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 v4 5/6] iommu/mediatek: Add mt8173 IOMMU driver
This patch adds support for mediatek m4u (MultiMedia Memory Management Unit). Signed-off-by: Yong Wu yong...@mediatek.com --- drivers/iommu/Kconfig | 13 + drivers/iommu/Makefile| 1 + drivers/iommu/mtk_iommu.c | 714 ++ 3 files changed, 728 insertions(+) create mode 100644 drivers/iommu/mtk_iommu.c diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig index 3abd066..f0ae553e 100644 --- a/drivers/iommu/Kconfig +++ b/drivers/iommu/Kconfig @@ -386,4 +386,17 @@ config ARM_SMMU_V3 Say Y here if your system includes an IOMMU device implementing the ARM SMMUv3 architecture. +config MTK_IOMMU + bool MTK IOMMU Support + depends on ARCH_MEDIATEK || COMPILE_TEST + select IOMMU_API + select IOMMU_DMA + select IOMMU_IO_PGTABLE_SHORT + select MEMORY + select MTK_SMI + help + Support for the IOMMUs on certain Mediatek SOCs. + + If unsure, say N here. + endif # IOMMU_SUPPORT diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile index 06df3e6..f4f2f2c 100644 --- a/drivers/iommu/Makefile +++ b/drivers/iommu/Makefile @@ -21,6 +21,7 @@ obj-$(CONFIG_ROCKCHIP_IOMMU) += rockchip-iommu.o obj-$(CONFIG_TEGRA_IOMMU_GART) += tegra-gart.o obj-$(CONFIG_TEGRA_IOMMU_SMMU) += tegra-smmu.o obj-$(CONFIG_EXYNOS_IOMMU) += exynos-iommu.o +obj-$(CONFIG_MTK_IOMMU) += mtk_iommu.o obj-$(CONFIG_SHMOBILE_IOMMU) += shmobile-iommu.o obj-$(CONFIG_SHMOBILE_IPMMU) += shmobile-ipmmu.o obj-$(CONFIG_FSL_PAMU) += fsl_pamu.o fsl_pamu_domain.o diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c new file mode 100644 index 000..3c4f1b5 --- /dev/null +++ b/drivers/iommu/mtk_iommu.c @@ -0,0 +1,714 @@ +/* + * Copyright (c) 2014-2015 MediaTek Inc. + * Author: Yong Wu yong...@mediatek.com + * + * 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. + */ +#include linux/io.h +#include linux/interrupt.h +#include linux/platform_device.h +#include linux/iommu.h +#include linux/dma-mapping.h +#include linux/dma-iommu.h +#include linux/of_iommu.h +#include linux/of_address.h +#include linux/of_irq.h +#include linux/of_platform.h +#include linux/list.h +#include linux/clk.h +#include linux/iopoll.h +#include asm/cacheflush.h +#include soc/mediatek/smi.h + +#include io-pgtable.h + +#define REG_MMU_PT_BASE_ADDR 0x000 + +#define REG_MMU_INVALIDATE 0x020 +#define F_ALL_INVLD0x2 +#define F_MMU_INV_RANGE0x1 + +#define REG_MMU_INVLD_START_A 0x024 +#define REG_MMU_INVLD_END_A0x028 + +#define REG_MMU_INV_SEL0x038 +#define F_INVLD_EN0BIT(0) +#define F_INVLD_EN1BIT(1) + +#define REG_MMU_STANDARD_AXI_MODE 0x048 +#define REG_MMU_DCM_DIS0x050 + +#define REG_MMU_CTRL_REG 0x110 +#define F_MMU_PREFETCH_RT_REPLACE_MOD BIT(4) +#define F_MMU_TF_PROTECT_SEL(prot) (((prot) 0x3) 5) +#define F_COHERENCE_EN BIT(8) + +#define REG_MMU_IVRP_PADDR 0x114 +#define F_MMU_IVRP_PA_SET(pa) ((pa) 1) + +#define REG_MMU_INT_CONTROL0 0x120 +#define F_L2_MULIT_HIT_EN BIT(0) +#define F_TABLE_WALK_FAULT_INT_EN BIT(1) +#define F_PREETCH_FIFO_OVERFLOW_INT_EN BIT(2) +#define F_MISS_FIFO_OVERFLOW_INT_ENBIT(3) +#define F_PREFETCH_FIFO_ERR_INT_EN BIT(5) +#define F_MISS_FIFO_ERR_INT_EN BIT(6) +#define F_INT_L2_CLR_BIT BIT(12) + +#define REG_MMU_INT_MAIN_CONTROL 0x124 +#define F_INT_TRANSLATION_FAULTBIT(0) +#define F_INT_MAIN_MULTI_HIT_FAULT BIT(1) +#define F_INT_INVALID_PA_FAULT BIT(2) +#define F_INT_ENTRY_REPLACEMENT_FAULT BIT(3) +#define F_INT_TLB_MISS_FAULT BIT(4) +#define F_INT_MISS_TRANSATION_FIFO_FAULT BIT(5) +#define F_INT_PRETETCH_TRANSATION_FIFO_FAULT BIT(6) + +#define REG_MMU_CPE_DONE 0x12C + +#define REG_MMU_FAULT_ST1 0x134 + +#define REG_MMU_FAULT_VA 0x13c +#define F_MMU_FAULT_VA_MSK 0xf000 +#define F_MMU_FAULT_VA_WRITE_BIT BIT(1) +#define F_MMU_FAULT_VA_LAYER_BIT BIT(0) + +#define REG_MMU_INVLD_PA 0x140 +#define
[PATCH v4 2/6] dt-bindings: mediatek: Add smi dts binding
This patch add smi binding document.
Signed-off-by: Yong Wu yong...@mediatek.com
---
.../memory-controllers/mediatek,smi-larb.txt | 25 ++
.../bindings/memory-controllers/mediatek,smi.txt | 24 +
2 files changed, 49 insertions(+)
create mode 100644
Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
create mode 100644
Documentation/devicetree/bindings/memory-controllers/mediatek,smi.txt
diff --git
a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
new file mode 100644
index 000..55ff3b7
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
@@ -0,0 +1,25 @@
+SMI (Smart Multimedia Interface) Local Arbiter
+
+The hardware block diagram please check bindings/iommu/mediatek,iommu.txt
+
+Required properties:
+- compatible : must be mediatek,mt8173-smi-larb
+- reg : the register and size of this local arbiter.
+- mediatek,smi : a phandle to the smi_common node.
+- power-domains : a phandle to the power domain of this local arbiter.
+- clocks : Must contain an entry for each entry in clock-names.
+- clock-names: must contain 2 entries, as follows:
+ - apb : Advanced Peripheral Bus clock, It's the clock for setting
+ the register.
+ - smi : It's the clock for transfer data and command.
+
+Example:
+ larb1: larb@1601 {
+ compatible = mediatek,mt8173-smi-larb;
+ reg = 0 0x1601 0 0x1000;
+ mediatek,smi = smi_common;
+ power-domains = scpsys MT8173_POWER_DOMAIN_VDEC;
+ clocks = vdecsys CLK_VDEC_CKEN,
+vdecsys CLK_VDEC_LARB_CKEN;
+ clock-names = apb, smi;
+ };
diff --git
a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi.txt
b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi.txt
new file mode 100644
index 000..f54e91c
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi.txt
@@ -0,0 +1,24 @@
+SMI (Smart Multimedia Interface)
+
+The hardware block diagram please check bindings/iommu/mediatek,iommu.txt
+
+Required properties:
+- compatible : must be mediatek,mt8173-smi
+- reg : the register and size of the SMI block.
+- power-domains : a phandle to the power domain of this local arbiter.
+- clocks : Must contain an entry for each entry in clock-names.
+- clock-names : must contain 2 entries, as follows:
+ - apb : Advanced Peripheral Bus clock, It's the clock for setting
+ the register.
+ - smi : It's the clock for transfer data and command.
+ They may be the same if both source clock are the same.
+
+Example:
+ smi_common: smi@14022000 {
+ compatible = mediatek,mt8173-smi;
+ reg = 0 0x14022000 0 0x1000;
+ power-domains = scpsys MT8173_POWER_DOMAIN_MM;
+ clocks = mmsys CLK_MM_SMI_COMMON,
+mmsys CLK_MM_SMI_COMMON;
+ clock-names = apb, smi;
+ };
--
1.8.1.1.dirty
--
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 v4 3/6] iommu: add ARM short descriptor page table allocator.
This patch is for ARM Short Descriptor Format.
Signed-off-by: Yong Wu yong...@mediatek.com
---
drivers/iommu/Kconfig| 18 +
drivers/iommu/Makefile | 1 +
drivers/iommu/io-pgtable-arm-short.c | 813 +++
drivers/iommu/io-pgtable-arm.c | 3 -
drivers/iommu/io-pgtable.c | 4 +
drivers/iommu/io-pgtable.h | 14 +
6 files changed, 850 insertions(+), 3 deletions(-)
create mode 100644 drivers/iommu/io-pgtable-arm-short.c
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index f1fb1d3..3abd066 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -39,6 +39,24 @@ config IOMMU_IO_PGTABLE_LPAE_SELFTEST
If unsure, say N here.
+config IOMMU_IO_PGTABLE_SHORT
+ bool ARMv7/v8 Short Descriptor Format
+ select IOMMU_IO_PGTABLE
+ depends on ARM || ARM64 || COMPILE_TEST
+ help
+ Enable support for the ARM Short-descriptor pagetable format.
+ This allocator supports 2 levels translation tables which supports
+ a memory map based on memory sections or pages.
+
+config IOMMU_IO_PGTABLE_SHORT_SELFTEST
+ bool Short Descriptor selftests
+ depends on IOMMU_IO_PGTABLE_SHORT
+ help
+ Enable self-tests for Short-descriptor page table allocator.
+ This performs a series of page-table consistency checks during boot.
+
+ If unsure, say N here.
+
endmenu
config IOMMU_IOVA
diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
index c6dcc51..06df3e6 100644
--- a/drivers/iommu/Makefile
+++ b/drivers/iommu/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_IOMMU_API) += iommu-traces.o
obj-$(CONFIG_IOMMU_API) += iommu-sysfs.o
obj-$(CONFIG_IOMMU_IO_PGTABLE) += io-pgtable.o
obj-$(CONFIG_IOMMU_IO_PGTABLE_LPAE) += io-pgtable-arm.o
+obj-$(CONFIG_IOMMU_IO_PGTABLE_SHORT) += io-pgtable-arm-short.o
obj-$(CONFIG_IOMMU_IOVA) += iova.o
obj-$(CONFIG_OF_IOMMU) += of_iommu.o
obj-$(CONFIG_MSM_IOMMU) += msm_iommu.o msm_iommu_dev.o
diff --git a/drivers/iommu/io-pgtable-arm-short.c
b/drivers/iommu/io-pgtable-arm-short.c
new file mode 100644
index 000..56f5480
--- /dev/null
+++ b/drivers/iommu/io-pgtable-arm-short.c
@@ -0,0 +1,813 @@
+/*
+ * Copyright (c) 2014-2015 MediaTek Inc.
+ * Author: Yong Wu yong...@mediatek.com
+ *
+ * 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.
+ */
+#define pr_fmt(fmt)arm-short-desc io-pgtable: fmt
+
+#include linux/err.h
+#include linux/slab.h
+#include linux/iommu.h
+#include linux/errno.h
+#include io-pgtable.h
+
+typedef u32 arm_short_iopte;
+
+struct arm_short_io_pgtable {
+ struct io_pgtable iop;
+ struct kmem_cache *pgtable_cached;
+ size_t pgd_size;
+ void*pgd;
+};
+
+#define io_pgtable_to_data(x) \
+ container_of((x), struct arm_short_io_pgtable, iop)
+
+#define io_pgtable_ops_to_data(x) \
+ io_pgtable_to_data(io_pgtable_ops_to_pgtable(x))
+
+#define io_pgtable_cfg_to_pgtable(x) \
+ container_of((x), struct io_pgtable, cfg)
+
+#define io_pgtable_cfg_to_data(x) \
+ io_pgtable_to_data(io_pgtable_cfg_to_pgtable(x))
+
+#define ARM_SHORT_PGDIR_SHIFT 20
+#define ARM_SHORT_PAGE_SHIFT 12
+#define ARM_SHORT_PTRS_PER_PTE \
+ (1 (ARM_SHORT_PGDIR_SHIFT - ARM_SHORT_PAGE_SHIFT))
+#define ARM_SHORT_BYTES_PER_PTE\
+ (ARM_SHORT_PTRS_PER_PTE * sizeof(arm_short_iopte))
+
+/* level 1 pagetable */
+#define ARM_SHORT_PGD_TYPE_PGTABLE BIT(0)
+#define ARM_SHORT_PGD_TYPE_SECTION BIT(1)
+#define ARM_SHORT_PGD_BBIT(2)
+#define ARM_SHORT_PGD_CBIT(3)
+#define ARM_SHORT_PGD_PGTABLE_NS BIT(3)
+#define ARM_SHORT_PGD_SECTION_XN BIT(4)
+#define ARM_SHORT_PGD_IMPLEBIT(9)
+#define ARM_SHORT_PGD_RD_WR(3 10)
+#define ARM_SHORT_PGD_RDONLY BIT(15)
+#define ARM_SHORT_PGD_SBIT(16)
+#define ARM_SHORT_PGD_nG BIT(17)
+#define ARM_SHORT_PGD_SUPERSECTION BIT(18)
+#define ARM_SHORT_PGD_SECTION_NS BIT(19)
+
+#define ARM_SHORT_PGD_TYPE_SUPERSECTION\
+ (ARM_SHORT_PGD_TYPE_SECTION | ARM_SHORT_PGD_SUPERSECTION)
+#define ARM_SHORT_PGD_SECTION_TYPE_MSK \
+ (ARM_SHORT_PGD_TYPE_SECTION | ARM_SHORT_PGD_SUPERSECTION)
+#define
[PATCH v4 4/6] memory: mediatek: Add SMI driver
This patch add SMI(Smart Multimedia Interface) driver. This driver
is responsible to enable/disable iommu and control the clocks of each
local arbiter
Signed-off-by: Yong Wu yong...@mediatek.com
---
drivers/memory/Kconfig | 8 ++
drivers/memory/Makefile| 1 +
drivers/memory/mtk-smi.c | 285 +
include/soc/mediatek/smi.h | 60 ++
4 files changed, 354 insertions(+)
create mode 100644 drivers/memory/mtk-smi.c
create mode 100644 include/soc/mediatek/smi.h
diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
index 8406c668..c0e1607 100644
--- a/drivers/memory/Kconfig
+++ b/drivers/memory/Kconfig
@@ -100,6 +100,14 @@ config JZ4780_NEMC
the Ingenic JZ4780. This controller is used to handle external
memory devices such as NAND and SRAM.
+config MTK_SMI
+ bool
+ depends on ARCH_MEDIATEK || COMPILE_TEST
+ help
+ This driver is for the Memory Controller module in MediaTek SoCs,
+ mainly help enable/disable iommu and control the clock for each
+ local arbiter.
+
source drivers/memory/tegra/Kconfig
endif
diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
index b670441..f854e40 100644
--- a/drivers/memory/Makefile
+++ b/drivers/memory/Makefile
@@ -14,5 +14,6 @@ obj-$(CONFIG_FSL_IFC) += fsl_ifc.o
obj-$(CONFIG_MVEBU_DEVBUS) += mvebu-devbus.o
obj-$(CONFIG_TEGRA20_MC) += tegra20-mc.o
obj-$(CONFIG_JZ4780_NEMC) += jz4780-nemc.o
+obj-$(CONFIG_MTK_SMI) += mtk-smi.o
obj-$(CONFIG_TEGRA_MC) += tegra/
diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
new file mode 100644
index 000..e62cceb
--- /dev/null
+++ b/drivers/memory/mtk-smi.c
@@ -0,0 +1,285 @@
+/*
+ * Copyright (c) 2014-2015 MediaTek Inc.
+ * Author: Yong Wu yong...@mediatek.com
+ *
+ * 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.
+ */
+#include linux/io.h
+#include linux/platform_device.h
+#include linux/clk.h
+#include linux/err.h
+#include linux/slab.h
+#include linux/of_address.h
+#include linux/of_irq.h
+#include linux/of_platform.h
+#include linux/pm_runtime.h
+#include soc/mediatek/smi.h
+
+#define SMI_LARB_MMU_EN0xf00
+#define F_SMI_MMU_EN(port) BIT(port)
+
+struct mtk_smi_common {
+ struct clk *clk_apb;
+ struct clk *clk_smi;
+};
+
+struct mtk_smi_larb {
+ void __iomem*base;
+ struct clk *clk_apb;
+ struct clk *clk_smi;
+ struct device *smi;
+};
+
+struct mtk_larb_mmu {
+ u32 mmu;
+};
+
+static int mtk_smi_common_get(struct device *smidev)
+{
+ struct mtk_smi_common *smipriv = dev_get_drvdata(smidev);
+ int ret;
+
+ ret = pm_runtime_get_sync(smidev);
+ if (ret 0)
+ return ret;
+
+ ret = clk_prepare_enable(smipriv-clk_apb);
+ if (ret) {
+ dev_err(smidev, Failed to enable the apb clock\n);
+ goto err_put_pm;
+ }
+ ret = clk_prepare_enable(smipriv-clk_smi);
+ if (ret) {
+ dev_err(smidev, Failed to enable the smi clock\n);
+ goto err_disable_apb;
+ }
+ return ret;
+
+err_disable_apb:
+ clk_disable_unprepare(smipriv-clk_apb);
+err_put_pm:
+ pm_runtime_put(smidev);
+ return ret;
+}
+
+static void mtk_smi_common_put(struct device *smidev)
+{
+ struct mtk_smi_common *smipriv = dev_get_drvdata(smidev);
+
+ clk_disable_unprepare(smipriv-clk_smi);
+ clk_disable_unprepare(smipriv-clk_apb);
+ pm_runtime_put(smidev);
+}
+
+int mtk_smi_larb_get(struct device *larbdev)
+{
+ struct mtk_smi_larb *larbpriv = dev_get_drvdata(larbdev);
+ struct mtk_larb_mmu *mmucfg = larbdev-archdata.iommu;
+ int ret;
+
+ ret = mtk_smi_common_get(larbpriv-smi);
+ if (ret)
+ return ret;
+
+ ret = pm_runtime_get_sync(larbdev);
+ if (ret 0)
+ goto err_put_smicommon;
+
+ ret = clk_prepare_enable(larbpriv-clk_apb);
+ if (ret) {
+ dev_err(larbdev, Failed to enable the apb clock\n);
+ goto err_put_pm;
+ }
+
+ ret = clk_prepare_enable(larbpriv-clk_smi);
+ if (ret) {
+ dev_err(larbdev, Failed to enable the smi clock\n);
+ goto err_disable_apb;
+ }
+
+ /* config iommu */
+ writel_relaxed(mmucfg-mmu, larbpriv-base + SMI_LARB_MMU_EN);
+
+ return ret;
+
+err_disable_apb:
+
Re: [PATCH v3 5/6] mmc: sdhci-esdhc-imx: config watermark level and burst length
On Fri, Jul 31, 2015 at 04:13:45PM +0100, Russell King - ARM Linux wrote:
On Fri, Jul 31, 2015 at 10:51:41PM +0800, Dong Aisheng wrote:
On Wed, Jul 29, 2015 at 05:03:56PM +0800, Haibo Chen wrote:
i.MX7D support eMMC HS400 mode, this mode can run in 8 bit,200MHZ
DDR mode. So the I/O speed improve a lot compare to SD3.0
The default burst length is 8, if we don't change this value, in
HS400 mode, when we do eMMC read operation, we can find that the
clock signal will stop for a period of time. This means the speed
of data moving on AHB bus is slower than I/O speed. So we should
improve the speed of data moving on AHB bus.
For imx7d usdhc, this patch set the burst length as 16, and set
watermark level as 64. The test result is the clock signal has
no stop during the eMMC HS400 operation. For other imx usdhc, remain
the default value: burst length as 8, watermark level as 16.
Signed-off-by: Haibo Chen haibo.c...@freescale.com
---
drivers/mmc/host/sdhci-esdhc-imx.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c
b/drivers/mmc/host/sdhci-esdhc-imx.c
index 158f93b..37d0095 100644
--- a/drivers/mmc/host/sdhci-esdhc-imx.c
+++ b/drivers/mmc/host/sdhci-esdhc-imx.c
@@ -239,6 +239,11 @@ static inline int is_imx6q_usdhc(struct
pltfm_imx_data *data)
return data-socdata == usdhc_imx6q_data;
}
+static inline int is_imx7d_usdhc(struct pltfm_imx_data *data)
+{
+ return data-socdata == usdhc_imx7d_data;
+}
Can we using flag to check instead of adding more is_imx_usdhc()?
No, not more flags. Do the job properly and parameterise the differences.
Hi Russell,
Thanks for the review.
I mean using the exist flag to do like:
if (imx_data-socdata-flags ESDHC_FLAG_SUP_HS400)
writel(0x10401040, host-ioaddr + ESDHC_WTMK_LVL);
else
writel(0x08100810, host-ioaddr + ESDHC_WTMK_LVL);
Not adding another new flag.
ESDHC_FLAG_SUP_HS400 represents the new feature support of HS400 which is
already added in patch
[PATCH v3 1/6] mmc: sdhci-esdhc-imx: add imx7d support and support HS400
static inline int esdhc_is_usdhc(struct pltfm_imx_data *data)
{
return !!(data-socdata-flags ESDHC_FLAG_USDHC);
@@ -1145,7 +1150,11 @@ static int sdhci_esdhc_imx_probe(struct
platform_device *pdev)
* to something insane. Change it back here.
*/
if (esdhc_is_usdhc(imx_data)) {
- writel(0x08100810, host-ioaddr + ESDHC_WTMK_LVL);
+ if (is_imx7d_usdhc(imx_data))
+ writel(0x10401040, host-ioaddr + ESDHC_WTMK_LVL);
+ else
+ writel(0x08100810, host-ioaddr + ESDHC_WTMK_LVL);
So the value to be written to this register should come from the
driver data, which is already used as a struct esdhc_soc_data to
extrapolate out the differences.
Going down the flag path will lead you to an even more of a stinking
shitpile than sdhci already is - if another version of the SoC requires
a different value there, what are you going to do? Add yet another
flag for the next value? What are you going to do when you have 16
different values? Use 16 different flags? Clearly that path is insane.
I understand your concern for the potential bad situation.
Here the watermark level setting of mx7d is dependant on the new feature
of HS400, so it seems make senese to use that flag to set value and does
not need adding new flag.
Actually that is the current approach for uSDHC driver to distinguish
the difference between register offset/settings by checking feature flags.
e.g. ESDHC_FLAG_USDHC, ESDHC_FLAG_STD_TUNING, ESDHC_FLAG_HS200 and etc.
This approach can save us a lot more flags for SoC checking for common
feature part. And up till now, things seem good.
If really new SoC comes while it requires a different value, if it's feature
dependant, we may still use feature flag for it.
If not, probably a quirk may be needed if it's IP limitation.
If it's normal situation and such situation happened too many in the future,
we may choose to parameterise all these normal feature independent settings
into esdhc_soc_data to avoid adding meaningless flags.
e.g.
static struct esdhc_soc_data usdhc_imx6sx_data = {
.flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_STD_TUNING
| ESDHC_FLAG_HAVE_CAP1 | ESDHC_FLAG_HS200,
.wml = 32,
};
static struct esdhc_soc_data usdhc_imx7d_data = {
.flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_STD_TUNING
| ESDHC_FLAG_HAVE_CAP1 | ESDHC_FLAG_HS200,
.wml = 64,
};
But currently i still did not see such urgent requirement to do it for only
water mark level settings.
Regards
Dong Aisheng
--
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
[PATCH v4] dtb: Create a common home for cross-architecture dtsi files.
Commit 9ccd608070b6 (arm64: dts: add device tree for ARM SMM-A53x2 on
LogicTile Express 20MG) added a new dts file to arch/arm64 which
included ../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi, i.e. a
.dtsi supplied by arch/arm.
Unfortunately this causes some issues for the split device tree
repository[0], since things get moved around there. In that context
the new .dts ends up at src/arm64/arm/vexpress-v2f-1xv7-ca53x2.dts
while the include is at src/arm/vexpress-v2m-rs1.dtsi.
The sharing of the .dtsi is legitimate since the baseboard is the same
for various vexpress systems whatever processor they use.
Rather than using ../../ tricks to pickup .dtsi files from another
arch this patch creates a new directory kernel/dts as a home for such
cross-arch .dtsi files, arranges for it to be in the include path when
the .dts files are processed by cpp and switches the .dts files to use
cpp #include instead of /include/. The dtsi file itself is moved into
a vendor subdir in this case arm (the vendor, not the ARCH=).
[0]
https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-rebasing.git/
Signed-off-by: Ian Campbell ian.campb...@citrix.com
Cc: Rob Herring robh...@kernel.org
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Kumar Gala ga...@codeaurora.org
Cc: Liviu Dudau liviu.du...@arm.com
Cc: Sudeep Holla sudeep.ho...@arm.com
Cc: Lorenzo Pieralisi lorenzo.pieral...@arm.com
Cc: Russell King li...@arm.linux.org.uk
Cc: Catalin Marinas catalin.mari...@arm.com
Cc: Will Deacon will.dea...@arm.com
Cc: Kristina Martsenko kristina.martse...@arm.com
Cc: Kevin Hilman khil...@linaro.org
Cc: devicetree@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kbu...@vger.kernel.org
Acked-by: Mark Rutland mark.rutl...@arm.com
Acked-by: Rob Herring r...@kernel.org
Acked-by: Liviu Dudau liviu.du...@arm.com
Reviewed-by: Masahiro Yamada yamada.masah...@socionext.com
---
v2: Move to include/dt-dtsi and introduce a per-vendor subdirectory.
v3: Move to kernel/dts.
Include new directory in DTC include path as well as cpp path, and
therefore switch back to /include/.
Update MAINTAINERS
v4: Change path in changelog too.
Add ()s to title of 9ccd608070b6.
---
Documentation/devicetree/bindings/arm/vexpress.txt | 2 +-
MAINTAINERS | 1 +
arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts | 2 +-
arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts | 2 +-
arch/arm/boot/dts/vexpress-v2p-ca5s.dts | 2 +-
arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts| 2 +-
{arch/arm/boot/dts = kernel/dts/arm}/vexpress-v2m-rs1.dtsi | 0
scripts/Makefile.lib| 3 ++-
8 files changed, 8 insertions(+), 6 deletions(-)
rename {arch/arm/boot/dts = kernel/dts/arm}/vexpress-v2m-rs1.dtsi (100%)
diff --git a/Documentation/devicetree/bindings/arm/vexpress.txt
b/Documentation/devicetree/bindings/arm/vexpress.txt
index 39844cd..b6031d9 100644
--- a/Documentation/devicetree/bindings/arm/vexpress.txt
+++ b/Documentation/devicetree/bindings/arm/vexpress.txt
@@ -223,7 +223,7 @@ Example of a VE tile description (simplified)
/* Active high IRQ 0 is connected to GIC's SPI0 */
interrupt-map = 0 0 0 gic 0 0 4;
- /include/ vexpress-v2m-rs1.dtsi
+ /include/ arm/vexpress-v2m-rs1.dtsi
};
};
diff --git a/MAINTAINERS b/MAINTAINERS
index a226416..1941078 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7537,6 +7537,7 @@ S:Maintained
F: Documentation/devicetree/
F: arch/*/boot/dts/
F: include/dt-bindings/
+F: kernel/dts/
OPEN FIRMWARE AND DEVICE TREE OVERLAYS
M: Pantelis Antoniou pantelis.anton...@konsulko.com
diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
b/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
index 9420053..b144092 100644
--- a/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
+++ b/arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts
@@ -278,6 +278,6 @@
0 0 41 gic 0 41 4,
0 0 42 gic 0 42 4;
- /include/ vexpress-v2m-rs1.dtsi
+ /include/ arm/vexpress-v2m-rs1.dtsi
};
};
diff --git a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
index 17f63f7..350f402 100644
--- a/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
+++ b/arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts
@@ -636,6 +636,6 @@
0 0 41 gic 0 41 4,
0 0 42 gic 0 42 4;
- /include/ vexpress-v2m-rs1.dtsi
+ /include/ arm/vexpress-v2m-rs1.dtsi
};
};
diff --git a/arch/arm/boot/dts/vexpress-v2p-ca5s.dts
b/arch/arm/boot/dts/vexpress-v2p-ca5s.dts
index d2709b7..585ced0 100644
--- a/arch/arm/boot/dts/vexpress-v2p-ca5s.dts
+++
Re: [linux-sunxi] [PATCH] ARM: dts: sunxi: Raise minimum CPU voltage for sun7i-a20 to a level all boards can supply
On Mon, Aug 03, 2015 at 09:35:51AM +1000, Julian Calaby wrote: Hi Timo, On Mon, Aug 3, 2015 at 5:23 AM, Timo Sigurdsson public_tim...@silentcreek.de wrote: sun7i-a20.dtsi contains an cpufreq operating point at 0.9 volts. Most A20 boards (or all?), however, do not allow the voltage to go below 1.0V. Thus, raise the voltage for the lowest operating point to 1.0V so all boards can actually use it. Surely it wouldn't be added here if some could supply 0.9v. Is the code that uses this smart enough to sensibly switch between two operating points with the same frequency and different voltages? If so, maybe just add a 144MHz @ 1.0v operating point? And how would it choose between the two exactly ? Switch to the 144MHz @ 0.9V and see if it works ? If it doesn't you might have screwed your system already, and might not be able to recover from it at all. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH v10 2/5] mtd: nand: vf610_nfc: add hardware BCH-ECC support
Hi Brian,
On 2015-08-03 11:27, Stefan Agner wrote:
snip
+static inline int vf610_nfc_correct_data(struct mtd_info *mtd, uint8_t *dat,
+ uint8_t *oob, int oob_loaded)
+{
+ struct vf610_nfc *nfc = mtd_to_nfc(mtd);
+ u8 ecc_status;
+ u8 ecc_count;
+ int flip;
+
+ ecc_status = __raw_readb(nfc-regs + ECC_SRAM_ADDR * 8 + ECC_OFFSET);
+ ecc_count = ecc_status ECC_ERR_COUNT;
+
+ if (!(ecc_status ECC_STATUS_MASK))
+ return ecc_count;
+
+ if (!oob_loaded)
+ vf610_nfc_read_buf(mtd, oob, mtd-oobsize);
+
+ /*
+ * On an erased page, bit count (including OOB) should be zero or
+ * at least less then half of the ECC strength.
+ */
+ flip = count_written_bits(dat, nfc-chip.ecc.size, ecc_count);
+ flip += count_written_bits(oob, mtd-oobsize - nfc-chip.ecc.bytes,
+ecc_count);
With ECC the controller seems to clear the ECC bytes in SRAM buffer.
This is a dump of 64 Bit OOB with the 32-error ECC mode which requires
60 bytes of OOB for ECC:
[ 22.190273] ff ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 22.209698] vf610_nfc_correct_data, flips 1
Not sure if this is acceptable, but I now only count the bits in the
non-ECC area of the OOB.
Btw, if the ECC check fails, the controller seems kind of count the
amount of bitflips. It works for most devices reliable, but we had
devices for which that number was not accurate, see:
http://thread.gmane.org/gmane.linux.ports.arm.kernel/357439
--
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: [linux-sunxi] [PATCH] ARM: dts: sunxi: Raise minimum CPU voltage for sun7i-a20 to a level all boards can supply
On Mon, Aug 03, 2015 at 11:03:52AM +0200, Timo Sigurdsson wrote: Hi again, Julian Calaby schrieb am 03.08.2015 06:22: My only real objection here is are there boards that can go down to 0.9v and if so, won't this change make them less power efficient in the almost-idle case? And are those power savings enough to justify not accepting this patch? It will probably make those boards less power efficient, yes. On the other hand, boards that have their CPU regulator set to min. 1.0V might also draw more power because the lowest frequency is not available, even though the savings due to frequency are likely to be lower than the savings due to voltage. Guys, isn't this whole discussion a bit moot? We're not doing any kind of power management but cpufreq, so maybe there's a lot more to do before we actually can have these kind of arguments? Plus this OPP has never been used anyway, so this patch is not going to increase the power consumption either. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
[PATCH] ARM: dts: imx6ul: enable GPC as extended interrupt controller
Enable GPC as extended interrupt controller of
GIC, as GPC needs to manage wakeup source for
low power modes.
Signed-off-by: Anson Huang b20...@freescale.com
---
arch/arm/boot/dts/imx6ul.dtsi | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx6ul.dtsi b/arch/arm/boot/dts/imx6ul.dtsi
index 138309a..af865d3 100644
--- a/arch/arm/boot/dts/imx6ul.dtsi
+++ b/arch/arm/boot/dts/imx6ul.dtsi
@@ -124,7 +124,7 @@
#address-cells = 1;
#size-cells = 1;
compatible = simple-bus;
- interrupt-parent = intc;
+ interrupt-parent = gpc;
ranges;
pmu {
@@ -414,7 +414,10 @@
gpc: gpc@020dc000 {
compatible = fsl,imx6ul-gpc, fsl,imx6q-gpc;
reg = 0x020dc000 0x4000;
+ interrupt-controller;
+ #interrupt-cells = 3;
interrupts = GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH;
+ interrupt-parent = intc;
};
iomuxc: iomuxc@020e {
--
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 v2 3/5] pci: altera: Add Altera PCIe MSI driver
On Fri, Jul 31, 2015 at 8:12 PM, Marc Zyngier marc.zyng...@arm.com wrote:
On 31/07/15 11:15, Ley Foon Tan wrote:
This patch adds Altera PCIe MSI driver. This soft IP supports configurable
number of vectors, which is a dts parameter.
I've reviewed the initial drop of this code; basic courtesy would be to
keep me CCed on the follow-up series.
Will keep you in CC for the following revision. Sorry about this.
Signed-off-by: Ley Foon Tan lf...@altera.com
---
drivers/pci/host/Kconfig | 7 +
drivers/pci/host/Makefile | 1 +
drivers/pci/host/pcie-altera-msi.c | 324
+
3 files changed, 332 insertions(+)
create mode 100644 drivers/pci/host/pcie-altera-msi.c
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index 108500a..51d0468 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -153,4 +153,11 @@ config PCIE_ALTERA
Say Y here if you want to enable PCIe controller support for Altera
SoCFPGA family of SoCs.
+config PCIE_ALTERA_MSI
+ bool Altera PCIe MSI feature
+ depends on PCI_MSI
+ help
+ Say Y here if you want PCIe MSI support for the Altera SocFPGA SoC.
+ This MSI driver supports Altera MSI to GIC controller IP.
+
endmenu
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 6954f76..6c4913d 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -18,3 +18,4 @@ obj-$(CONFIG_PCIE_IPROC) += pcie-iproc.o
obj-$(CONFIG_PCIE_IPROC_PLATFORM) += pcie-iproc-platform.o
obj-$(CONFIG_PCIE_IPROC_BCMA) += pcie-iproc-bcma.o
obj-$(CONFIG_PCIE_ALTERA) += pcie-altera.o
+obj-$(CONFIG_PCIE_ALTERA_MSI) += pcie-altera-msi.o
diff --git a/drivers/pci/host/pcie-altera-msi.c
b/drivers/pci/host/pcie-altera-msi.c
new file mode 100644
index 000..6014719
--- /dev/null
+++ b/drivers/pci/host/pcie-altera-msi.c
@@ -0,0 +1,324 @@
+/*
+ * Copyright Altera Corporation (C) 2013-2015. All rights reserved
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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 http://www.gnu.org/licenses/.
+ */
+#include linux/interrupt.h
+#include linux/irqchip/chained_irq.h
+#include linux/module.h
+#include linux/msi.h
+#include linux/of_address.h
+#include linux/of_irq.h
+#include linux/of_pci.h
+#include linux/pci.h
+#include linux/platform_device.h
+#include linux/slab.h
+
+#define MSI_STATUS 0x0
+#define MSI_ERROR0x4
+#define MSI_INTMASK 0x8
+
+#define MAX_MSI_VECTORS 32
+struct altera_msi {
+ DECLARE_BITMAP(used, MAX_MSI_VECTORS);
+ struct mutexlock; /* proctect used variable */
+ struct platform_device *pdev;
+ struct irq_domain *msi_domain;
+ struct irq_domain *inner_domain;
+ void __iomem*csr_base;
+ void __iomem*vector_base;
+ phys_addr_t vector_phy;
+ u32 num_of_vectors;
+ int irq;
+};
+
+static inline void msi_writel(struct altera_msi *msi, u32 value, u32 reg)
+{
+ writel_relaxed(value, msi-csr_base + reg);
+}
+
+static inline u32 msi_readl(struct altera_msi *msi, u32 reg)
+{
+ return readl_relaxed(msi-csr_base + reg);
+}
+
+static void altera_msi_isr(unsigned int irq, struct irq_desc *desc)
+{
+ struct irq_chip *chip = irq_desc_get_chip(desc);
+ struct altera_msi *msi;
+ unsigned long status;
+ u32 num_of_vectors;
+ u32 bit;
+
+ chained_irq_enter(chip, desc);
+ msi = irq_desc_get_handler_data(desc);
+ num_of_vectors = msi-num_of_vectors;
+
+ do {
+ status = msi_readl(msi, MSI_STATUS);
+ if (!status)
+ break;
+
+ do {
+ bit = find_first_bit(status, num_of_vectors);
+ /* Dummy read from vector to clear the interrupt */
+ readl_relaxed(msi-vector_base + (bit * sizeof(u32)));
+
+ irq = irq_find_mapping(msi-inner_domain, bit);
Use of irq is a bit confusing, as this is a parameter describing the
chaining interrupt. Consider using a different name for this variable.
Okay, will change it to 'virq'.
+ if (irq) {
+ if (test_bit(bit, msi-used))
+ generic_handle_irq(irq);
+
Re: [PATCH v2 3/5] pci: altera: Add Altera PCIe MSI driver
On 03/08/15 11:37, Ley Foon Tan wrote:
On Fri, Jul 31, 2015 at 8:12 PM, Marc Zyngier marc.zyng...@arm.com wrote:
On 31/07/15 11:15, Ley Foon Tan wrote:
This patch adds Altera PCIe MSI driver. This soft IP supports configurable
number of vectors, which is a dts parameter.
I've reviewed the initial drop of this code; basic courtesy would be to
keep me CCed on the follow-up series.
Will keep you in CC for the following revision. Sorry about this.
Signed-off-by: Ley Foon Tan lf...@altera.com
---
drivers/pci/host/Kconfig | 7 +
drivers/pci/host/Makefile | 1 +
drivers/pci/host/pcie-altera-msi.c | 324
+
3 files changed, 332 insertions(+)
create mode 100644 drivers/pci/host/pcie-altera-msi.c
[...]
+
+ msg-address_lo = lower_32_bits(addr);
+ msg-address_hi = upper_32_bits(addr);
+ msg-data = data-hwirq;
+
+ mask = msi_readl(msi, MSI_INTMASK);
+ mask |= 1 data-hwirq;
+ msi_writel(msi, mask, MSI_INTMASK);
It feels a bit weird to unmask the interrupt when you compose the
message. I'd expect this to be done in the mask/unmask methods.
Do you refer to these 2 callbacks?
.irq_mask = pci_msi_mask_irq,
.irq_unmask = pci_msi_unmask_irq,
How about we move this INTMASK code above to altera_irq_domain_alloc()?
We have unmask code in altera_irq_domain_free() now.
Either you move the mask/unmask code to local irq_mask/irq_unmask
methods (and call pci_msi_(un)mask_irq from there), or you move it
entierely to alloc/free.
Some level of symmetry helps following what is going on in the code.
[...]
+static int altera_irq_domain_alloc(struct irq_domain *domain, unsigned int
virq,
+ unsigned int nr_irqs, void *args)
+{
+ struct altera_msi *msi = domain-host_data;
+ int bit;
+
+ mutex_lock(msi-lock);
+
+ bit = find_first_zero_bit(msi-used, msi-num_of_vectors);
+ if (bit msi-num_of_vectors)
+ set_bit(bit, msi-used);
+
+ mutex_unlock(msi-lock);
+
+ if (bit 0)
+ return bit;
How can bit be negative here? find_first_zero_bit returns an unsigned
long... You probably want to change the type of bit to reflect that.
Okay, will change to unsigned long type.
+ else if (bit = msi-num_of_vectors)
Useless else anyway.
I think we still need to check for failing case, if we don't have
available unused bit.
This could be rewritten as below:
bit = find_first_zero_bit(msi-used, msi-num_of_vectors);
if (bit msi-num_of_vectors)
set_bit(bit, msi-used);
else
return -ENOSPC;
The more logical to write this is:
if (bit = msi-num_of_vectors)
return -ENOSPC;
set_bit(bit, msi-used);
which gets rid of the error case early and streamlines the normal case.
+ return -ENOSPC;
+
+ irq_domain_set_info(domain, virq, bit, altera_msi_bottom_irq_chip,
+ domain-host_data, handle_simple_irq,
+ NULL, NULL);
+ set_irq_flags(virq, IRQF_VALID);
+
+ return 0;
+}
Thanks,
M.
--
Jazz is not dead. It just smells funny...
--
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 3/5] pci: altera: Add Altera PCIe MSI driver
On Mon, Aug 3, 2015 at 6:53 PM, Marc Zyngier marc.zyng...@arm.com wrote:
On 03/08/15 11:37, Ley Foon Tan wrote:
+ msg-address_lo = lower_32_bits(addr);
+ msg-address_hi = upper_32_bits(addr);
+ msg-data = data-hwirq;
+
+ mask = msi_readl(msi, MSI_INTMASK);
+ mask |= 1 data-hwirq;
+ msi_writel(msi, mask, MSI_INTMASK);
It feels a bit weird to unmask the interrupt when you compose the
message. I'd expect this to be done in the mask/unmask methods.
Do you refer to these 2 callbacks?
.irq_mask = pci_msi_mask_irq,
.irq_unmask = pci_msi_unmask_irq,
How about we move this INTMASK code above to altera_irq_domain_alloc()?
We have unmask code in altera_irq_domain_free() now.
Either you move the mask/unmask code to local irq_mask/irq_unmask
methods (and call pci_msi_(un)mask_irq from there), or you move it
entierely to alloc/free.
Some level of symmetry helps following what is going on in the code.
Okay, will move it to alloc/free.
[...]
+static int altera_irq_domain_alloc(struct irq_domain *domain, unsigned
int virq,
+ unsigned int nr_irqs, void *args)
+{
+ struct altera_msi *msi = domain-host_data;
+ int bit;
+
+ mutex_lock(msi-lock);
+
+ bit = find_first_zero_bit(msi-used, msi-num_of_vectors);
+ if (bit msi-num_of_vectors)
+ set_bit(bit, msi-used);
+
+ mutex_unlock(msi-lock);
+
+ if (bit 0)
+ return bit;
How can bit be negative here? find_first_zero_bit returns an unsigned
long... You probably want to change the type of bit to reflect that.
Okay, will change to unsigned long type.
+ else if (bit = msi-num_of_vectors)
Useless else anyway.
I think we still need to check for failing case, if we don't have
available unused bit.
This could be rewritten as below:
bit = find_first_zero_bit(msi-used, msi-num_of_vectors);
if (bit msi-num_of_vectors)
set_bit(bit, msi-used);
else
return -ENOSPC;
The more logical to write this is:
if (bit = msi-num_of_vectors)
return -ENOSPC;
set_bit(bit, msi-used);
which gets rid of the error case early and streamlines the normal case.
Yes, will change to this way.
Thanks.
Regards
Ley Foon
--
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 v10 2/5] mtd: nand: vf610_nfc: add hardware BCH-ECC support
This adds hardware ECC support using the BCH encoder in the NFC IP.
The ECC encoder supports up to 32-bit correction by using 60 error
correction bytes. There is no sub-page ECC step, ECC is calculated
always accross the whole page (up to 2k pages). Raw writes writes
are possible through the common nand_write_page_raw implementation,
however raw reads are not possible since the hardware ECC mode need
to be enabled at command time.
Signed-off-by: Bill Pringlemeir bpringlem...@nbsps.com
Signed-off-by: Stefan Agner ste...@agner.ch
---
drivers/mtd/nand/Kconfig | 6 +-
drivers/mtd/nand/vf610_nfc.c | 206 ++-
2 files changed, 209 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 8550b14..e05f53c 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -469,8 +469,10 @@ config MTD_NAND_VF610_NFC
help
Enables support for NAND Flash Controller on some Freescale
processors like the VF610, MPC5125, MCF54418 or Kinetis K70.
- The driver supports a maximum 2k page size. The driver
- currently does not support hardware ECC.
+ The driver supports a maximum 2k page size. With 2k pages and
+ 64 bytes or more of OOB, hardware ECC with up to 32-bit error
+ correction is supported. Hardware ECC is only enabled through
+ device tree.
config MTD_NAND_MXC
tristate MXC NAND support
diff --git a/drivers/mtd/nand/vf610_nfc.c b/drivers/mtd/nand/vf610_nfc.c
index 5c8dfe8..247f06a 100644
--- a/drivers/mtd/nand/vf610_nfc.c
+++ b/drivers/mtd/nand/vf610_nfc.c
@@ -19,6 +19,8 @@
* - Untested on MPC5125 and M54418.
* - DMA not used.
* - 2K pages or less.
+ * - Only 2K page w. 64+ OOB and hardware ECC.
+ * - Raw page reads not implemented when using ECC.
*/
#include linux/module.h
@@ -73,6 +75,8 @@
/* NFC ECC mode define */
#define ECC_BYPASS 0
+#define ECC_45_BYTE6
+#define ECC_60_BYTE7
/*** Register Mask and bit definitions */
@@ -125,6 +129,21 @@
#define CMD_DONE_CLEAR_BIT BIT(18)
#define IDLE_CLEAR_BIT BIT(17)
+/* ECC status placed at end of buffers. */
+#define ECC_SRAM_ADDR ((PAGE_2K + 256 - 8) 3)
+#define ECC_STATUS_MASK0x80
+#define ECC_ERR_COUNT 0x3F
+
+/*
+ * ECC status is stored at NFC_CFG[ECCADD] +4 for little-endian
+ * and +7 for big-endian SoCs.
+ */
+#ifdef __LITTLE_ENDIAN
+#define ECC_OFFSET 4
+#else
+#define ECC_OFFSET 7
+#endif
+
struct vf610_nfc {
struct mtd_info mtd;
struct nand_chip chip;
@@ -139,10 +158,40 @@ struct vf610_nfc {
#define ALT_BUF_STAT 2
#define ALT_BUF_ONFI 3
struct clk *clk;
+ bool use_hw_ecc;
+ u32 ecc_mode;
};
#define mtd_to_nfc(_mtd) container_of(_mtd, struct vf610_nfc, mtd)
+static struct nand_ecclayout vf610_nfc_ecc45 = {
+ .eccbytes = 45,
+ .eccpos = {19, 20, 21, 22, 23,
+ 24, 25, 26, 27, 28, 29, 30, 31,
+ 32, 33, 34, 35, 36, 37, 38, 39,
+ 40, 41, 42, 43, 44, 45, 46, 47,
+ 48, 49, 50, 51, 52, 53, 54, 55,
+ 56, 57, 58, 59, 60, 61, 62, 63},
+ .oobfree = {
+ {.offset = 2,
+.length = 17} }
+};
+
+static struct nand_ecclayout vf610_nfc_ecc60 = {
+ .eccbytes = 60,
+ .eccpos = { 4, 5, 6, 7, 8, 9, 10, 11,
+ 12, 13, 14, 15, 16, 17, 18, 19,
+ 20, 21, 22, 23, 24, 25, 26, 27,
+ 28, 29, 30, 31, 32, 33, 34, 35,
+ 36, 37, 38, 39, 40, 41, 42, 43,
+ 44, 45, 46, 47, 48, 49, 50, 51,
+ 52, 53, 54, 55, 56, 57, 58, 59,
+ 60, 61, 62, 63 },
+ .oobfree = {
+ {.offset = 2,
+.length = 2} }
+};
+
static inline u32 vf610_nfc_read(struct vf610_nfc *nfc, uint reg)
{
return readl(nfc-regs + reg);
@@ -285,6 +334,13 @@ static void vf610_nfc_addr_cycle(struct vf610_nfc *nfc,
int column, int page)
ROW_ADDR_SHIFT, page);
}
+static inline void vf610_nfc_ecc_mode(struct vf610_nfc *nfc, int ecc_mode)
+{
+ vf610_nfc_set_field(nfc, NFC_FLASH_CONFIG,
+ CONFIG_ECC_MODE_MASK,
+ CONFIG_ECC_MODE_SHIFT, ecc_mode);
+}
+
static inline void vf610_nfc_transfer_size(struct vf610_nfc *nfc, int size)
{
vf610_nfc_write(nfc, NFC_SECTOR_SIZE, size);
@@ -303,13 +359,20 @@ static void vf610_nfc_command(struct mtd_info *mtd,
unsigned command,
case NAND_CMD_SEQIN:
/* Use valid column/page from preread... */
vf610_nfc_addr_cycle(nfc, column, page);
+ nfc-buf_offset = 0;
+
/*
* SEQIN = data = PAGEPROG sequence is done by the controller
* hence we do not
[PATCH v10 3/5] mtd: nand: vf610_nfc: add device tree bindings
Signed-off-by: Bill Pringlemeir bpringlem...@nbsps.com
Acked-by: Shawn Guo shawn...@kernel.org
Reviewed-by: Brian Norris computersforpe...@gmail.com
Signed-off-by: Stefan Agner ste...@agner.ch
---
.../devicetree/bindings/mtd/vf610-nfc.txt | 45 ++
1 file changed, 45 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/vf610-nfc.txt
diff --git a/Documentation/devicetree/bindings/mtd/vf610-nfc.txt
b/Documentation/devicetree/bindings/mtd/vf610-nfc.txt
new file mode 100644
index 000..cae5f25
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/vf610-nfc.txt
@@ -0,0 +1,45 @@
+Freescale's NAND flash controller (NFC)
+
+This variant of the Freescale NAND flash controller (NFC) can be found on
+Vybrid (vf610), MPC5125, MCF54418 and Kinetis K70.
+
+Required properties:
+- compatible: Should be set to fsl,vf610-nfc
+- reg: address range of the NFC
+- interrupts: interrupt of the NFC
+- nand-bus-width: see nand.txt
+- nand-ecc-mode: see nand.txt
+- nand-on-flash-bbt: see nand.txt
+- assigned-clocks: main clock from the SoC, for Vybrid clks VF610_CLK_NFC;
+- assigned-clock-rates: The NAND bus timing is derived from this clock
+rate and should not exceed maximum timing for any NAND memory chip
+in a board stuffing. Typical NAND memory timings derived from this
+clock are found in the SoC hardware reference manual. Furthermore,
+there might be restrictions on maximum rates when using hardware ECC.
+
+- #address-cells, #size-cells : Must be present if the device has sub-nodes
+ representing partitions.
+
+Required properties for hardware ECC:
+- nand-ecc-strength: supported strengths are 24 and 32 bit (see nand.txt)
+- nand-ecc-step-size: step size equals page size, currently only 2k pages are
+supported
+
+Example:
+
+ nfc: nand@400e {
+ compatible = fsl,vf610-nfc;
+ #address-cells = 1;
+ #size-cells = 1;
+ reg = 0x400e 0x4000;
+ interrupts = GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH;
+ clocks = clks VF610_CLK_NFC;
+ clock-names = nfc;
+ assigned-clocks = clks VF610_CLK_NFC;
+ assigned-clock-rates = 3300;
+ nand-bus-width = 8;
+ nand-ecc-mode = hw;
+ nand-ecc-strength = 32;
+ nand-ecc-step-size = 2048;
+ nand-on-flash-bbt;
+ };
--
2.5.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
Re: [PATCH v2] usb: phy: msm: Add D+/D- lines route control
On Tue, Jul 28, 2015 at 10:10 AM, Ivan T. Ivanov ivan.iva...@linaro.org wrote:
--- a/Documentation/devicetree/bindings/usb/msm-hsusb.txt
+++ b/Documentation/devicetree/bindings/usb/msm-hsusb.txt
@@ -52,6 +52,10 @@ Required properties:
Optional properties:
- dr_mode: One of host, peripheral or otg. Defaults to otg
+- switch-gpio: A phandle + gpio-specifier pair. Some boards are using Dual
+SPDT USB Switch, witch is cotrolled by GPIO to de/multiplex
which is controlled
+D+/D- USB lines between connectors.
+
- qcom,phy-init-sequence: PHY configuration sequence values. This is related
to Device
Mode Eye Diagram test. Start address at which these values
will be
written is ULPI_EXT_VENDOR_SPECIFIC. Value of -1 is reserved
as
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 v10 0/5] mtd: nand: vf610_nfc: Freescale NFC for VF610
Hi Stefan, Le Mon, 3 Aug 2015 11:27:25 +0200, Stefan Agner ste...@agner.ch a écrit : The 10th revision includes some more review comments, including an improved handling of empty NAND pages with hardware ECC. More information and the full test log of earlier patchset version can be found in the cover letter of the last revision v6: http://thread.gmane.org/gmane.linux.kernel/1979868 Changes since v9: - Remove inline of vf610_nfc_done - Add __iomem to src argument of vf610_nfc_memcpy - Handle return value of mtd_device_parse_register correctly - Count bits in OOB too (only non-ECC bits) - Return bitflips in ecc.read_page callback vf610_nfc_read_page - Fall-through ALT_BUF_ONFI - Use BIT macros Changes since v8: - Fix 16-Bit NAND flash support by splitting up initialization (introduce vf610_nfc_preinit_controller) - Updated comments in initialziation functions Changes since v7: - vf610-twr.dts: Moved NFC pinmux into the existing iomuxc node and sort new nfc node behind the existing iomuxc node as well. - vf610-twr.dts/vf-colibri.dtsi: Dropped _1 suffixes Changes since v6: - Rebased ontop of l2-mtd/master (v4.2-rc1 based) - Removed HAVE_NAND_VF610_NFC and use depends on. This made [PATCH v6 4/6] ARM: vf610: enable NAND Flash Controller unnecessary Changes since v5: - Removed fsl,mpc5125-nfc compatible string - Removed readl/writel_relaxed - Change interface of vf610_nfc_transfer_size to match other accessors Changes since v4: - Rebased ontop of l2-mtd/master (v4.1-rc4 based) - Eliminate unnecessary page read (NAND_CMD_SEQIN) since the driver does not support sub-page writes anyway (improves write performance) - Support ONFI by enabling READID command with offset and parameter page reads (CMD_PARAM) - Change to dedicated read_page/write_page function, enables raw writes - Use __LITTLE_ENDIAN to distingush between LE/BE relevant statements - Eliminated vf610_nfc_probe_dt in favor of common DT init code - Use wait_for_completion_timeout - Some style fixes (spaces, etc.) Changes since v3: - Make the driver selectable when COMPILE_TEST is set - Fix compile error due to superfluous ECC_STATUS configuration in initial patch (without ECC correction ECC_STATUS does not need to be configured) - Remove custom BBT pattern and switch to in-band BBT in the initial patch - Include two bug fixes, for details see the corresponding U-Boot patches: http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/215802 Changes since v2: - Updated binding documentation Changes since v1: - Nest nfc_config struct within the main nfc struct - Use assigned clock binding to specify NFC clock - Rebased ontop of MSCM IR patchset (driver parts have been merged) - Split out arch Kconfig in a separate config - Fix module license - Updated MAINTAINERS Changes since RFC (Bill Pringlemeir): - Renamed driver from fsl_nfc to vf610_nfc - Use readl/writel for all register in accessor functions - Optimized field accessor functions - Implemented PM (suspend/resume) functions - Implemented basic support for ECC strength/ECC step size from dt - Improved performance of count_written_bits by using hweight32 - Support ECC with 60-bytes to correct up to 32 bit errors - Changed to in-band BBT (NAND_BBT_NO_OOB) which also allows ECC modes which uses up to 60 bytes on 64 byte OOB - Removed custom (downstream) BBT pattern since BBT table won't be compatible anyway (due to the change above) For the sake of regression testing: Tested-by: Albert ARIBAUD albert.arib...@3adev.fr Still works fine here on a Vybrid and 16-bit Micron NAND. Cordialement, Albert ARIBAUD 3ADEV -- 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/5] pci:host: Add Altera PCIe host controller driver
On Fri, Jul 31, 2015 at 8:34 PM, Marc Zyngier marc.zyng...@arm.com wrote:
On 31/07/15 11:15, Ley Foon Tan wrote:
This patch adds the Altera PCIe host controller driver.
Signed-off-by: Ley Foon Tan lf...@altera.com
---
drivers/pci/host/Kconfig | 8 +
drivers/pci/host/Makefile | 1 +
drivers/pci/host/pcie-altera.c | 526
+
3 files changed, 535 insertions(+)
create mode 100644 drivers/pci/host/pcie-altera.c
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index 675c2d1..108500a 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -145,4 +145,12 @@ config PCIE_IPROC_BCMA
Say Y here if you want to use the Broadcom iProc PCIe controller
through the BCMA bus interface
+config PCIE_ALTERA
+ tristate Altera PCIe controller
+ depends on ARCH_SOCFPGA
+ select PCI_MSI_IRQ_DOMAIN if PCI_MSI
Why would you select this here? MSI support is in another driver, so I
don't see the point.
Will move select PCI_MSI_IRQ_DOMAIN to config PCIE_ALTERA_MSI section.
+ help
+ Say Y here if you want to enable PCIe controller support for Altera
+ SoCFPGA family of SoCs.
+
endmenu
+static const struct irq_domain_ops intx_domain_ops = {
+ .map = altera_pcie_intx_map,
+};
+
+static irqreturn_t altera_pcie_isr(int irq, void *arg)
+{
+ struct altera_pcie *pcie = arg;
+ u32 status, i;
+
+ status = cra_readl(pcie, P2A_INT_STATUS) P2A_INT_STS_ALL;
+
+ /* clear interrupts */
+ cra_writel(pcie, status, P2A_INT_STATUS);
+
+ for (i = 0; i INTX_NUM; i++) {
+ if (status (1 i))
find_first/next_set_bit?
Yes, change this to find_first_bit().
+ generic_handle_irq(irq_find_mapping(pcie-irq_domain,
+ i + 1));
Rule of thumb: if you're calling generic_handle_irq from an interrupt
handler, this is a chained IRQ controller. Please implement it as such.
Okay, will change this to chained_irq_enter/chained_irq_exit implementation.
+ }
+
+ return IRQ_HANDLED;
+}
+
+static void altera_pcie_release_of_pci_ranges(struct altera_pcie *pcie)
+{
+ pci_free_resource_list(pcie-resources);
+}
+
+static int altera_pcie_parse_request_of_pci_ranges(struct altera_pcie *pcie)
+{
+ int err, res_valid = 0;
+ struct device *dev = pcie-pdev-dev;
+ struct device_node *np = dev-of_node;
+ resource_size_t iobase;
+ struct resource_entry *win;
+ int offset = 0;
+
+ err = of_pci_get_host_bridge_resources(np, 0, 0xff, pcie-resources,
+iobase);
+ if (err)
+ return err;
+
+ resource_list_for_each_entry(win, pcie-resources) {
+ struct resource *parent, *res = win-res;
+
+ switch (resource_type(res)) {
+ case IORESOURCE_MEM:
+ parent = iomem_resource;
+ res_valid |= !(res-flags IORESOURCE_PREFETCH);
+ cra_writel(pcie, res-start,
+ A2P_ADDR_MAP_LO0 + offset);
+ cra_writel(pcie, 0,
+ A2P_ADDR_MAP_HI0 + offset);
+ offset += ATT_ENTRY_SIZE;
+ break;
+ default:
+ continue;
+ }
+
+ err = devm_request_resource(dev, parent, res);
+ if (err)
+ goto out_release_res;
+ }
+
+ if (!res_valid) {
+ dev_err(dev, non-prefetchable memory resource required\n);
+ err = -EINVAL;
+ goto out_release_res;
+ }
+
+ return 0;
+
+out_release_res:
+ altera_pcie_release_of_pci_ranges(pcie);
+ return err;
+}
+
+static void altera_pcie_free_irq_domain(struct altera_pcie *pcie)
+{
+ int i;
+ u32 irq;
+
+ for (i = 0; i INTX_NUM; i++) {
+ irq = irq_find_mapping(pcie-irq_domain, i);
+ if (irq 0)
+ irq_dispose_mapping(irq);
+ }
+
+ irq_domain_remove(pcie-irq_domain);
+}
+
+static int altera_pcie_init_irq_domain(struct altera_pcie *pcie)
+{
+ struct device *dev = pcie-pdev-dev;
+ struct device_node *node = dev-of_node;
+
+ /* Setup INTx */
+ pcie-irq_domain = irq_domain_add_linear(node, INTX_NUM,
+ intx_domain_ops, pcie);
+ if (!pcie-irq_domain) {
+ dev_err(dev, Failed to get a INTx IRQ domain\n);
+ return PTR_ERR(pcie-irq_domain);
+ }
+
+ return 0;
+}
+
+static int altera_pcie_parse_dt(struct altera_pcie *pcie)
+{
+ struct resource *cra;
+ int ret;
+ struct platform_device *pdev = pcie-pdev;
+
+ cra = platform_get_resource_byname(pdev, IORESOURCE_MEM, Cra);
+ pcie-cra_base =
Re: [PATCH 1/3] Docs: dt: add generic MSI bindings
On 27/07/15 10:46, Mark Rutland wrote:
On Mon, Jul 27, 2015 at 09:02:46AM +0100, Marc Zyngier wrote:
Hi Mark,
Hi,
On 23/07/15 17:52, Mark Rutland wrote:
Currently msi-parent is used in a couple of drivers despite being fairly
underspecified. This patch adds a generic binding for MSIs (including
the existing msi-parent property) enabling the description of platform
devices capable of using MSIs.
While MSIs are primarily distinguished by doorbell and payload, some MSI
controllers (e.g. the GICv3 ITS) also use side-band information
accompanying the write to identify the master which originated the MSI,
to allow for sandboxing. This sideband information is non-probeable and
needs to be described in the DT. Other MSI controllers may have
additional configuration details which need to be described per-master.
This patch adds a generic msi-parent binding document, extending the
de-facto standard with a new (optional) #msi-cells which can be used to
express any per-master configuration and/or sideband data. This is
sufficient to describe non-hotpluggable devices.
For busses where sideband data may be derived from some bus-specific
master ID scheme, other properties will be required to describe the
mapping.
Signed-off-by: Mark Rutland mark.rutl...@arm.com
---
.../bindings/interrupt-controller/msi.txt | 135
+
1 file changed, 135 insertions(+)
create mode 100644
Documentation/devicetree/bindings/interrupt-controller/msi.txt
diff --git a/Documentation/devicetree/bindings/interrupt-controller/msi.txt
b/Documentation/devicetree/bindings/interrupt-controller/msi.txt
new file mode 100644
index 000..c60c034
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/msi.txt
@@ -0,0 +1,135 @@
+This document describes the generic device tree binding for MSI
controllers and
+their master(s).
+
+Message Signaled Interrupts (MSIs) are a class of interrupts generated by a
+write to an MMIO address.
+
+MSIs were originally specified by PCI (and are used with PCIe), but may
also be
+used with other busses, and hence a mechanism is required to relate
devices on
+those busses to the MSI controllers which they are capable of using,
+potentially including additional information.
+
+MSIs are distinguished by some combination of:
+
+- The doorbell (the MMIO address written to).
+
+ Devices may be configured by software to write to arbitrary doorbells
which
+ they can address. An MSI controller may feature a number of doorbells.
+
+- The payload (the value written to the doorbell).
+
+ Devices may be configured to write an arbitrary payload chosen by
software.
+ MSI controllers may have restrictions on permitted payloads.
+
+- Sideband information accompanying the write.
+
+ Typically this is neither configurable nor probeable, and depends on the
path
+ taken through the memory system (i.e. it is a property of the
combination of
+ MSI controller and device rather than a property of either in isolation).
+
+
+MSI controllers:
+
+
+An MSI controller signals interrupts to a CPU when a write is made to an
MMIO
+address by some master. An MSI controller may feature a number of
doorbells.
+
+Required properties:
+
+
+- msi-controller: Identifies the node as an MSI controller.
+
+Optional properties:
+
+
+- #msi-cells: The number of cells in an msi-specifier, required if not
zero.
+
+ Typically this will encode information related to sideband data, and will
+ not encode doorbells or payloads as these can be configured dynamically.
+
+ The meaning of the msi-specifier is defined by the device tree binding of
+ the specific MSI controller.
+
+
+MSI clients
+===
+
+MSI clients are devices which generate MSIs. For each MSI they wish to
+generate, the doorbell and payload may be configured, though sideband
+information may not be configurable.
+
+Required properties:
+
+
+- msi-parent: A list of phandle + msi-specifier pairs, one for each MSI
+ controller which the device is capable of using.
+
+ This property is unordered, and MSIs may be allocated from any
combination of
+ MSI controllers listed in the msi-parent property.
+
+ If a device has restrictions on the allocation of MSIs, these
restrictions
+ must be described with additional properties.
+
+ When #msi-cells is non-zero, busses with an msi-parent will require
+ additional properties to describe the relationship between devices on
the bus
+ and the set of MSIs they can potentially generate.
+
+
+Example
+===
+
+/ {
+ #address-cells = 1;
+ #size-cells = 1;
+
+ msi_a: msi-controller@a {
+ reg = 0xa 0xf00;
+ compatible = vendor-a,some-controller;
+ msi-controller;
+ /* No sideband data, so #msi-cells omitted */
+ };
+
+
Re: [PATCH] ARM: dts: sunxi: Raise minimum CPU voltage for sun7i-a20 to a level all boards can supply
On Sun, Aug 02, 2015 at 09:23:06PM +0200, Timo Sigurdsson wrote: sun7i-a20.dtsi contains an cpufreq operating point at 0.9 volts. Most A20 boards (or all?), however, do not allow the voltage to go below 1.0V. Thus, raise the voltage for the lowest operating point to 1.0V so all boards can actually use it. This is not a property of a board, but is the actual limit documented by Allwinner for the A20. Some individual SoCs might have wider tolerances, but that's not a property of a board, it's really a property of a single SoC, and we cannot make any assumption on the board. (and please make sure to run checkpatch before sending your patches) Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
[PATCH v10 1/5] mtd: nand: vf610_nfc: Freescale NFC for VF610, MPC5125 and others
This driver supports Freescale NFC (NAND flash controller) found on Vybrid (VF610), MPC5125, MCF54418 and Kinetis K70. The driver has been tested on 8-bit and 16-bit NAND interface and supports ONFI parameter page reading. Limitations: - DMA and pipelining not used - Pages larger than 2k are not supported - No hardware ECC The driver has only been tested on Vybrid SoC VF610 and VF500. Some paths have been hand-optimized and evaluated by measurements made using mtd_speedtest.ko on a 100MB MTD partition. Colibri VF50 eb write % eb read % page write % page read % rel/opt 5175 115374560 11039 opt 5164 -0.21 11420 -1.01 4737 +3.88 10918 -1.10 none5113 -1.20 11352 -1.60 4490 -1.54 10865 -1.58 Colibri VF61 eb write % eb read % page write % page read % rel/opt 5766 130965459 12846 opt 5883 +2.03 13064 -0.24 5561 +1.87 12802 -0.34 none5701 -1.13 12980 -0.89 5488 +0.53 12735 -0.86 rel = using readl_relaxed/writel_relaxed in optimized paths opt = hand-optimized by combining multiple accesses into one read/write The measurements have not been statistically verfied, hence use them with care. The author came to the conclusion that using the relaxed variants of readl/writel are not worth the additional code. Signed-off-by: Bill Pringlemeir bpringlem...@nbsps.com Tested-by: Albert ARIBAUD albert.arib...@3adev.fr Signed-off-by: Stefan Agner ste...@agner.ch --- MAINTAINERS | 6 + drivers/mtd/nand/Kconfig | 9 + drivers/mtd/nand/Makefile| 1 + drivers/mtd/nand/vf610_nfc.c | 645 +++ 4 files changed, 661 insertions(+) create mode 100644 drivers/mtd/nand/vf610_nfc.c diff --git a/MAINTAINERS b/MAINTAINERS index 9567329..59975c7 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -10835,6 +10835,12 @@ S: Maintained F: Documentation/fb/uvesafb.txt F: drivers/video/fbdev/uvesafb.* +VF610 NAND DRIVER +M: Stefan Agner ste...@agner.ch +L: linux-...@lists.infradead.org +S: Supported +F: drivers/mtd/nand/vf610_nfc.c + VFAT/FAT/MSDOS FILESYSTEM M: OGAWA Hirofumi hirof...@mail.parknet.co.jp S: Maintained diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig index 5b2806a..8550b14 100644 --- a/drivers/mtd/nand/Kconfig +++ b/drivers/mtd/nand/Kconfig @@ -463,6 +463,15 @@ config MTD_NAND_MPC5121_NFC This enables the driver for the NAND flash controller on the MPC5121 SoC. +config MTD_NAND_VF610_NFC + tristate Support for Freescale NFC for VF610/MPC5125 + depends on (SOC_VF610 || COMPILE_TEST) + help + Enables support for NAND Flash Controller on some Freescale + processors like the VF610, MPC5125, MCF54418 or Kinetis K70. + The driver supports a maximum 2k page size. The driver + currently does not support hardware ECC. + config MTD_NAND_MXC tristate MXC NAND support depends on ARCH_MXC diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile index 1f897ec..a490af8 100644 --- a/drivers/mtd/nand/Makefile +++ b/drivers/mtd/nand/Makefile @@ -45,6 +45,7 @@ obj-$(CONFIG_MTD_NAND_SOCRATES) += socrates_nand.o obj-$(CONFIG_MTD_NAND_TXX9NDFMC) += txx9ndfmc.o obj-$(CONFIG_MTD_NAND_NUC900) += nuc900_nand.o obj-$(CONFIG_MTD_NAND_MPC5121_NFC) += mpc5121_nfc.o +obj-$(CONFIG_MTD_NAND_VF610_NFC) += vf610_nfc.o obj-$(CONFIG_MTD_NAND_RICOH) += r852.o obj-$(CONFIG_MTD_NAND_JZ4740) += jz4740_nand.o obj-$(CONFIG_MTD_NAND_GPMI_NAND) += gpmi-nand/ diff --git a/drivers/mtd/nand/vf610_nfc.c b/drivers/mtd/nand/vf610_nfc.c new file mode 100644 index 000..5c8dfe8 --- /dev/null +++ b/drivers/mtd/nand/vf610_nfc.c @@ -0,0 +1,645 @@ +/* + * Copyright 2009-2015 Freescale Semiconductor, Inc. and others + * + * Description: MPC5125, VF610, MCF54418 and Kinetis K70 Nand driver. + * Jason ported to M54418TWR and MVFA5 (VF610). + * Authors: Stefan Agner stefan.ag...@toradex.com + * Bill Pringlemeir bpringlem...@nbsps.com + * Shaohui Xie b21...@freescale.com + * Jason Jin jason@freescale.com + * + * Based on original driver mpc5121_nfc.c. + * + * This 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. + * + * Limitations: + * - Untested on MPC5125 and M54418. + * - DMA not used. + * - 2K pages or less. + */ + +#include linux/module.h +#include linux/bitops.h +#include linux/clk.h +#include linux/delay.h +#include linux/init.h +#include linux/interrupt.h +#include linux/io.h +#include linux/mtd/mtd.h +#include
Re: [linux-sunxi] [PATCH] ARM: dts: sunxi: Raise minimum CPU voltage for sun7i-a20 to a level all boards can supply
On Mon, Aug 03, 2015 at 02:22:13PM +1000, Julian Calaby wrote: Is the code that uses this smart enough to sensibly switch between two operating points with the same frequency and different voltages? If so, maybe just add a 144MHz @ 1.0v operating point? You could try. Though I really don't see much to gain here. From what I recall, lower frequency = less power usage, though my experience is from x86 laptops, not ARM SoCs and I'm sure I'm missing a lot of details. This is the sort of thing that requires thorough testing on a dev board. Not on *a* dev board. On virtually all the A20 SoCs ever produced. If you have a setting that works better for *your* SoC, fine, patch your DT, but that's not going to be a default if it's outside of the SoC operating range. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
[PATCH v10 4/5] ARM: dts: vf610twr: add NAND flash controller peripherial
This adds the NAND flash controller (NFC) peripherial. The driver
supports the SLC NAND chips found on Freescale's Vybrid Tower System
Module. The Micron NAND chip on the module needs 4-bit ECC per 512
byte page. Use 24-bit ECC per 2k page, which is supported by the
driver.
Signed-off-by: Bill Pringlemeir bpringlem...@nbsps.com
Reviewed-by: Brian Norris computersforpe...@gmail.com
Signed-off-by: Stefan Agner ste...@agner.ch
---
arch/arm/boot/dts/vf610-twr.dts | 40
arch/arm/boot/dts/vfxxx.dtsi| 8
2 files changed, 48 insertions(+)
diff --git a/arch/arm/boot/dts/vf610-twr.dts b/arch/arm/boot/dts/vf610-twr.dts
index 375ab23..2a278a2 100644
--- a/arch/arm/boot/dts/vf610-twr.dts
+++ b/arch/arm/boot/dts/vf610-twr.dts
@@ -237,6 +237,33 @@
;
};
+ pinctrl_nfc: nfcgrp {
+ fsl,pins =
+ VF610_PAD_PTD31__NF_IO150x28df
+ VF610_PAD_PTD30__NF_IO140x28df
+ VF610_PAD_PTD29__NF_IO130x28df
+ VF610_PAD_PTD28__NF_IO120x28df
+ VF610_PAD_PTD27__NF_IO110x28df
+ VF610_PAD_PTD26__NF_IO100x28df
+ VF610_PAD_PTD25__NF_IO9 0x28df
+ VF610_PAD_PTD24__NF_IO8 0x28df
+ VF610_PAD_PTD23__NF_IO7 0x28df
+ VF610_PAD_PTD22__NF_IO6 0x28df
+ VF610_PAD_PTD21__NF_IO5 0x28df
+ VF610_PAD_PTD20__NF_IO4 0x28df
+ VF610_PAD_PTD19__NF_IO3 0x28df
+ VF610_PAD_PTD18__NF_IO2 0x28df
+ VF610_PAD_PTD17__NF_IO1 0x28df
+ VF610_PAD_PTD16__NF_IO0 0x28df
+ VF610_PAD_PTB24__NF_WE_B0x28c2
+ VF610_PAD_PTB25__NF_CE0_B 0x28c2
+ VF610_PAD_PTB27__NF_RE_B0x28c2
+ VF610_PAD_PTC26__NF_RB_B0x283d
+ VF610_PAD_PTC27__NF_ALE 0x28c2
+ VF610_PAD_PTC28__NF_CLE 0x28c2
+ ;
+ };
+
pinctrl_pwm0: pwm0grp {
fsl,pins =
VF610_PAD_PTB0__FTM0_CH00x1582
@@ -274,6 +301,19 @@
};
};
+nfc {
+ assigned-clocks = clks VF610_CLK_NFC;
+ assigned-clock-rates = 3300;
+ nand-bus-width = 16;
+ nand-ecc-mode = hw;
+ nand-ecc-step-size = 2048;
+ nand-ecc-strength = 24;
+ nand-on-flash-bbt;
+ pinctrl-names = default;
+ pinctrl-0 = pinctrl_nfc;
+ status = okay;
+};
+
pwm0 {
pinctrl-names = default;
pinctrl-0 = pinctrl_pwm0;
diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index 4aa3351..2f4b04d 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -520,6 +520,14 @@
status = disabled;
};
+ nfc: nand@400e {
+ compatible = fsl,vf610-nfc;
+ reg = 0x400e 0x4000;
+ interrupts = 83 IRQ_TYPE_LEVEL_HIGH;
+ clocks = clks VF610_CLK_NFC;
+ clock-names = nfc;
+ status = disabled;
+ };
};
};
};
--
2.5.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 v10 5/5] ARM: dts: vf-colibri: enable NAND flash controller
Enable NAND access by adding pinmux and NAND flash controller node
to device tree. The NAND chips currently used on the Colibri VF61
requires 8-bit ECC per 512 byte page, hence specify 32-bit ECC
strength per 2k page size.
Reviewed-by: Brian Norris computersforpe...@gmail.com
Signed-off-by: Stefan Agner ste...@agner.ch
---
arch/arm/boot/dts/vf-colibri.dtsi | 32
1 file changed, 32 insertions(+)
diff --git a/arch/arm/boot/dts/vf-colibri.dtsi
b/arch/arm/boot/dts/vf-colibri.dtsi
index 68ca125..ab2e74b 100644
--- a/arch/arm/boot/dts/vf-colibri.dtsi
+++ b/arch/arm/boot/dts/vf-colibri.dtsi
@@ -52,6 +52,19 @@
pinctrl-0 = pinctrl_i2c0;
};
+nfc {
+ assigned-clocks = clks VF610_CLK_NFC;
+ assigned-clock-rates = 3300;
+ nand-bus-width = 8;
+ nand-ecc-mode = hw;
+ nand-ecc-step-size = 2048;
+ nand-ecc-strength = 32;
+ nand-on-flash-bbt;
+ pinctrl-names = default;
+ pinctrl-0 = pinctrl_nfc;
+ status = okay;
+};
+
pwm0 {
pinctrl-names = default;
pinctrl-0 = pinctrl_pwm0;
@@ -156,6 +169,25 @@
;
};
+ pinctrl_nfc: nfcgrp {
+ fsl,pins =
+ VF610_PAD_PTD23__NF_IO7 0x28df
+ VF610_PAD_PTD22__NF_IO6 0x28df
+ VF610_PAD_PTD21__NF_IO5 0x28df
+ VF610_PAD_PTD20__NF_IO4 0x28df
+ VF610_PAD_PTD19__NF_IO3 0x28df
+ VF610_PAD_PTD18__NF_IO2 0x28df
+ VF610_PAD_PTD17__NF_IO1 0x28df
+ VF610_PAD_PTD16__NF_IO0 0x28df
+ VF610_PAD_PTB24__NF_WE_B0x28c2
+ VF610_PAD_PTB25__NF_CE0_B 0x28c2
+ VF610_PAD_PTB27__NF_RE_B0x28c2
+ VF610_PAD_PTC26__NF_RB_B0x283d
+ VF610_PAD_PTC27__NF_ALE 0x28c2
+ VF610_PAD_PTC28__NF_CLE 0x28c2
+ ;
+ };
+
pinctrl_pwm0: pwm0grp {
fsl,pins =
VF610_PAD_PTB0__FTM0_CH00x1182
--
2.5.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
Re: [PATCH v2] ARM: dts: sunxi: Add regulators for LeMaker BananaPi
On Sun, Aug 02, 2015 at 06:18:25PM +0200, Timo Sigurdsson wrote:
sun7i-a20-bananapi.dts doesn't contain regulator nodes for the AXP209 PMU
driver, so add them to allow for voltage-scaling with cpufreq-dt.
Signed-off-by: Timo Sigurdsson public_tim...@silentcreek.de
---
Changes since v1 (RFC):
- Dropped the changes to the cpufreq operating points and renamed the patch
accordingly
- Limited the CPU voltage range so it doesn't exceed the SOC specifications
---
arch/arm/boot/dts/sun7i-a20-bananapi.dts | 35
1 file changed, 31 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/sun7i-a20-bananapi.dts
b/arch/arm/boot/dts/sun7i-a20-bananapi.dts
index 9f7b472..74382f3 100644
--- a/arch/arm/boot/dts/sun7i-a20-bananapi.dts
+++ b/arch/arm/boot/dts/sun7i-a20-bananapi.dts
@@ -92,6 +92,10 @@
status = okay;
};
+cpu0 {
+ cpu-supply = reg_dcdc2;
+};
+
ehci0 {
status = okay;
};
@@ -119,13 +123,9 @@
status = okay;
axp209: pmic@34 {
- compatible = x-powers,axp209;
reg = 0x34;
interrupt-parent = nmi_intc;
interrupts = 0 IRQ_TYPE_LEVEL_LOW;
-
- interrupt-controller;
- #interrupt-cells = 1;
};
};
@@ -182,6 +182,33 @@
};
};
+#include axp209.dtsi
+
+reg_dcdc2 {
+ regulator-always-on;
+ regulator-min-microvolt = 100;
+ regulator-max-microvolt = 140;
+ regulator-name = vdd-cpu;
+};
+
+reg_dcdc3 {
+ regulator-always-on;
+ regulator-min-microvolt = 100;
+ regulator-max-microvolt = 140;
+ regulator-name = vdd-int-dll;
+};
+
+reg_ldo1 {
+ regulator-name = vdd-rtc;
+};
+
+reg_ldo2 {
+ regulator-always-on;
+ regulator-min-microvolt = 300;
+ regulator-max-microvolt = 300;
+ regulator-name = avcc;
+};
What regulator provides the 3.3V regulator used in the rest of this DT
then (MMC, GMAC) ?
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
[PATCH v4 1/6] dt-bindings: iommu: Add binding for mediatek IOMMU
This patch add mediatek iommu dts binding document.
Signed-off-by: Yong Wu yong...@mediatek.com
---
.../devicetree/bindings/iommu/mediatek,iommu.txt | 61
include/dt-bindings/memory/mt8173-larb-port.h | 105 +
2 files changed, 166 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
create mode 100644 include/dt-bindings/memory/mt8173-larb-port.h
diff --git a/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
b/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
new file mode 100644
index 000..691739a
--- /dev/null
+++ b/Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
@@ -0,0 +1,61 @@
+* Mediatek IOMMU Architecture Implementation
+
+ Mediatek Socs may contain a implementation of Multimedia Memory
+Management Unit(M4U),which use ARM Short-descriptor translation table
+to achieve address translation.
+
+ The IOMMU Hardware Block Diagram, please check below:
+
+ EMI (External Memory Interface)
+ |
+ m4u (Multimedia Memory Management Unit)
+ |
+ smi (Smart Multimedia Interface)
+ |
++---+---
+| |
+| |
+vdec larb disp larb ... SoCs have different local arbiter(larb).
+| |
+| |
+ ++++-+-+
+ |||| | |...
+ |||| | |...
+ |||| | |...
+ MC PP VLD OVL0 RDMA0 WDMA0 ... There are different ports in each larb.
+
+ As above, The Multimedia HW will go through SMI and M4U while it
+access EMI. SMI is a brige between m4u and the Multimedia HW. It contain
+smi local arbiter and smi common. It will control whether the Multimedia
+HW should go though the m4u for translation or bypass it and talk
+directly with EMI. And also SMI help control the clocks for each
+local arbiter.
+ Normally we specify a local arbiter(larb) for each multimedia HW
+like display, video decode, and camera. And there are different ports
+in each larb. Take a example, There are some ports like MC, PP, VLD in the
+video decode local arbiter, all the ports are according to the video HW.
+
+Required properties:
+- compatible : must be mediatek,mt8173-m4u.
+- reg : m4u register base and size.
+- interrupts : the interrupt of m4u.
+- clocks : must contain one entry for each clock-names.
+- clock-names : must be bclk, It is the block clock of m4u.
+- mediatek,larb : List of phandle to the local arbiters in the current Socs.
+ Refer to bindings/memory-controllers/mediatek,smi-larb.txt. It must sort
+ according to the local arbiter index, like larb0, larb1, larb2...
+- iommu-cells : must be 2. There are 2 cells needed to enable/disable iommu.
+ The first one is local arbiter index(larbid), and the other is port
+ index(portid) within local arbiter. Specifies the larbid and portid as
+ defined in dt-binding/memory/mt8173-larb-port.h.
+
+Example:
+ iommu: mmsys_iommu@10205000 {
+ compatible = mediatek,mt8173-m4u;
+ reg = 0 0x10205000 0 0x1000;
+ interrupts = GIC_SPI 139 IRQ_TYPE_LEVEL_LOW;
+ clocks = infracfg CLK_INFRA_M4U;
+ clock-names = bclk;
+ mediatek,larb = larb0 larb1 larb2 larb3 larb4 larb5;
+ #iommu-cells = 2;
+ };
diff --git a/include/dt-bindings/memory/mt8173-larb-port.h
b/include/dt-bindings/memory/mt8173-larb-port.h
new file mode 100644
index 000..7517087
--- /dev/null
+++ b/include/dt-bindings/memory/mt8173-larb-port.h
@@ -0,0 +1,105 @@
+/*
+ * Copyright (c) 2014-2015 MediaTek Inc.
+ * Author: Yong Wu yong...@mediatek.com
+ *
+ * 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.
+ */
+#ifndef __DTS_IOMMU_PORT_MT8173_H
+#define __DTS_IOMMU_PORT_MT8173_H
+
+#define M4U_LARB0_ID 0
+#define M4U_LARB1_ID 1
+#define M4U_LARB2_ID 2
+#define M4U_LARB3_ID 3
+#define M4U_LARB4_ID 4
+#define M4U_LARB5_ID 5
+
+/* larb0 */
+#defineM4U_PORT_DISP_OVL0 0
+#defineM4U_PORT_DISP_RDMA0 1
+#defineM4U_PORT_DISP_WDMA0 2
+#defineM4U_PORT_DISP_OD_R 3
+#defineM4U_PORT_DISP_OD_W 4
+#defineM4U_PORT_MDP_RDMA0 5
+#defineM4U_PORT_MDP_WDMA 6
+#defineM4U_PORT_MDP_WROT0
[PATCH v4 0/6] MT8173 IOMMU SUPPORT
This patch set adds support for m4u(Multimedia Memory Management Unit), Currently it only support the m4u with 2 levels of pagetable on mt8173. It's based on Robin Murphy's arm64 DMA-v5[1] and Robin's allow DMA API use in io-pgtable-arm[2]. The dsti is based on MTK clock patch[3]. Please check the hardware block diagram of Mediatek IOMMU. EMI (External Memory Interface) | m4u (Multimedia Memory Management Unit) | smi (Smart Multimedia Interface) | +---+--- | | | | vdec larb disp larb ... SoCs have different local arbiter(larb). | | | | ++++-+-+ |||| | |... |||| | |... |||| | |... MC PP VLD OVL0 RDMA0 WDMA0 ... There are different ports in each larb. Normally we specify a local arbiter(larb) for each multimedia hardware like display, video decode, video encode and camera. And there are different ports in each larb. Take a example, there are some ports like MC, PP, UFO, VLD, AVC_MV, PRED_RD in video larb, all the ports are according to the video hardware. From the diagram, all the multimedia module connect with m4u via smi. SMI is responsible to enable/disable iommu and control the clocks for each local arbiter. If we should enable the iommu of video decode, it should config the video's ports. And if the video hardware work whether enable/disable iommu, it should enable the clock of its larb's clock. And smi also help bandwidth control for each local. So we add a special driver for smi and locate it drivers/memory. v4: -use only one iommu domain here based on the Robin's DMA-v5. -remove flush_pgtable. -change writel to writel_relaxed. -about Short-descriptor: move dma_map_single into io-pgtable-arm-short. Improve the flow of free pgtable and add NO_XN+NO_PERMS quirk following Will's suggestion. -Change two sytle issues in dtsi according to Daniel's suggestion. v3: http://lists.linuxfoundation.org/pipermail/iommu/2015-July/013632.html -rebased onto v4.2-rc1 -improve iommu flow based on the Robin's DMA v3[4]. -change mtk iommu-cells from 1 to 2. -about Short-descriptor: add split function; add self-test; add some other bits like nG, XN according to the spec; add SUPERSECTION and MTK quirk; move io_pgtable_ops_to_pgtable out from LPAE to the header file. -about SMI: move from driver/soc/mediatek to driver/memory; change the clocks from clk[2] to clk_apb and clk_smi; add pm. -add iommu suspend/resume to backup/restore register. v2: http://lists.linuxfoundation.org/pipermail/iommu/2015-May/013028.html -add arm short descriptor support. -seperate smi common from smi and change the clock-names according to smi HW. -delete the hardcode of the port-names in mt8173. replace this with larb-portes-nr in dtsi. -fix some coding style issues. v1: http://lists.infradead.org/pipermail/linux-mediatek/2015-March/58.html -initial version. [1]: http://lists.linuxfoundation.org/pipermail/iommu/2015-July/013900.html [2]: http://lists.linuxfoundation.org/pipermail/iommu/2015-July/013876.html [3]: http://lists.infradead.org/pipermail/linux-mediatek/2015-July/001800.html [4]: http://lists.linuxfoundation.org/pipermail/iommu/2015-July/013597.html Yong Wu (6): dt-bindings: iommu: Add binding for mediatek IOMMU dt-bindings: mediatek: Add smi dts binding iommu: add ARM short descriptor page table allocator. memory: mediatek: Add SMI driver iommu/mediatek: Add mt8173 IOMMU driver dts: mt8173: Add iommu/smi nodes for mt8173 .../devicetree/bindings/iommu/mediatek,iommu.txt | 61 ++ .../memory-controllers/mediatek,smi-larb.txt | 25 + .../bindings/memory-controllers/mediatek,smi.txt | 24 + arch/arm64/boot/dts/mediatek/mt8173.dtsi | 81 ++ drivers/iommu/Kconfig | 31 + drivers/iommu/Makefile | 2 + drivers/iommu/io-pgtable-arm-short.c | 811 + drivers/iommu/io-pgtable-arm.c | 3 - drivers/iommu/io-pgtable.c | 4 + drivers/iommu/io-pgtable.h | 14 + drivers/iommu/mtk_iommu.c | 714 ++ drivers/memory/Kconfig | 8 + drivers/memory/Makefile| 1 + drivers/memory/mtk-smi.c | 285 include/dt-bindings/memory/mt8173-larb-port.h | 105 +++ include/soc/mediatek/smi.h | 60 ++ 16 files changed, 2226 insertions(+), 3 deletions(-) create mode 100644 Documentation/devicetree/bindings/iommu/mediatek,iommu.txt create mode 100644 Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt create mode 100644
[PATCH v4 6/6] dts: mt8173: Add iommu/smi nodes for mt8173
This patch add the iommu/larbs nodes for mt8173
Signed-off-by: Yong Wu yong...@mediatek.com
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 81
1 file changed, 81 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 6c3f047..a92956d 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -14,6 +14,7 @@
#include dt-bindings/clock/mt8173-clk.h
#include dt-bindings/interrupt-controller/irq.h
#include dt-bindings/interrupt-controller/arm-gic.h
+#include dt-bindings/memory/mt8173-larb-port.h
#include dt-bindings/power/mt8173-power.h
#include dt-bindings/reset-controller/mt8173-resets.h
#include mt8173-pinfunc.h
@@ -265,6 +266,17 @@
reg = 0 0x10200620 0 0x20;
};
+ iommu: iommu@10205000 {
+ compatible = mediatek,mt8173-m4u;
+ reg = 0 0x10205000 0 0x1000;
+ interrupts = GIC_SPI 139 IRQ_TYPE_LEVEL_LOW;
+ clocks = infracfg CLK_INFRA_M4U;
+ clock-names = bclk;
+ mediatek,larb = larb0 larb1 larb2
+larb3 larb4 larb5;
+ #iommu-cells = 2;
+ };
+
apmixedsys: clock-controller@10209000 {
compatible = mediatek,mt8173-apmixedsys;
reg = 0 0x10209000 0 0x1000;
@@ -501,29 +513,98 @@
#clock-cells = 1;
};
+ larb0: larb@14021000 {
+ compatible = mediatek,mt8173-smi-larb;
+ reg = 0 0x14021000 0 0x1000;
+ mediatek,smi = smi_common;
+ power-domains = scpsys MT8173_POWER_DOMAIN_MM;
+ clocks = mmsys CLK_MM_SMI_LARB0,
+mmsys CLK_MM_SMI_LARB0;
+ clock-names = apb, smi;
+ };
+
+ smi_common: smi@14022000 {
+ compatible = mediatek,mt8173-smi;
+ reg = 0 0x14022000 0 0x1000;
+ power-domains = scpsys MT8173_POWER_DOMAIN_MM;
+ clocks = mmsys CLK_MM_SMI_COMMON,
+mmsys CLK_MM_SMI_COMMON;
+ clock-names = apb, smi;
+ };
+
+ larb4: larb@14027000 {
+ compatible = mediatek,mt8173-smi-larb;
+ reg = 0 0x14027000 0 0x1000;
+ mediatek,smi = smi_common;
+ power-domains = scpsys MT8173_POWER_DOMAIN_MM;
+ clocks = mmsys CLK_MM_SMI_LARB4,
+mmsys CLK_MM_SMI_LARB4;
+ clock-names = apb, smi;
+ };
+
imgsys: clock-controller@1500 {
compatible = mediatek,mt8173-imgsys, syscon;
reg = 0 0x1500 0 0x1000;
#clock-cells = 1;
};
+ larb2: larb@15001000 {
+ compatible = mediatek,mt8173-smi-larb;
+ reg = 0 0x15001000 0 0x1000;
+ mediatek,smi = smi_common;
+ power-domains = scpsys MT8173_POWER_DOMAIN_ISP;
+ clocks = imgsys CLK_IMG_LARB2_SMI,
+imgsys CLK_IMG_LARB2_SMI;
+ clock-names = apb, smi;
+ };
+
vdecsys: clock-controller@1600 {
compatible = mediatek,mt8173-vdecsys, syscon;
reg = 0 0x1600 0 0x1000;
#clock-cells = 1;
};
+ larb1: larb@1601 {
+ compatible = mediatek,mt8173-smi-larb;
+ reg = 0 0x1601 0 0x1000;
+ mediatek,smi = smi_common;
+ power-domains = scpsys MT8173_POWER_DOMAIN_VDEC;
+ clocks = vdecsys CLK_VDEC_CKEN,
+vdecsys CLK_VDEC_LARB_CKEN;
+ clock-names = apb, smi;
+ };
+
vencsys: clock-controller@1800 {
compatible = mediatek,mt8173-vencsys, syscon;
reg = 0 0x1800 0 0x1000;
#clock-cells = 1;
};
+ larb3: larb@18001000 {
+ compatible = mediatek,mt8173-smi-larb;
+ reg = 0 0x18001000 0 0x1000;
+ mediatek,smi = smi_common;
+ power-domains = scpsys MT8173_POWER_DOMAIN_VENC;
+ clocks = vencsys CLK_VENC_CKE1,
+vencsys CLK_VENC_CKE0;
+
Re: [PATCH v4 0/8] Goodix touchscreen enhancements
On Fri, 2015-07-31 at 20:42 +0300, Irina Tirdea wrote: Add several enhancements to the Goodix touchscreen driver. It's going to be a couple of weeks before I have the time to sit down and test most of those. Also note that I'll be using a different device (WinBook TW100), though the new owner of the Onda v975w should be able to run tests as well. Cheers -- 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 0/8] ARM64: juno: add SCPI mailbox protocol, clock and CPUFreq support
On 03/08/15 11:18, Liviu Dudau wrote: On Fri, Jul 31, 2015 at 06:43:03PM +0100, Sudeep Holla wrote: Hi ARM-SoC guys, It has been on the list for a while and have got all the necessary ACKs. Can you please pull this series for v4.3 ? Regards, Sudeep This patch series adds support for: 1. SCPI(System Control and Power Interface) mailbox protocol driver. It uses ARM MHU mailbox controller driver on Juno but can work with any mailbox controllers using standard mailbox APIs 2. Add support for clocks provided by SCP firmware through the SCPI interface 3. Using the existing arm_big_little cpufreq driver and the newly added SCPI clock driver, it also adds support for CPU DVFS on ARM64 JUNO development platforms. Hi Sudeep, Is there a branch where I can pull this series from? Yes, you can pull from git://linux-arm.org/linux-skn.git juno_dvfs Regards, Sudeep -- 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] clk: mediatek: Export CPU mux clocks for CPU frequency control
On Wed, Jul 15, 2015 at 02:38:46PM +0800, Pi-Cheng Chen wrote:
From: pi-cheng.chen pi-cheng.c...@linaro.org
This patch adds CPU mux clocks which are used by Mediatek cpufreq driver
for intermediate clock source switching.
Hi Mike and Stephen,
since the MT8173 cpufreq driver is likely going to be merged[1] and we still
need the CPU MUX clocks consumed by MT8173 cpufreq driver, may I have some
comments from you to get this patch moving forwards so that MT8173 cpufreq
driver could work completely?
Or the regmap supported basic clock type[2] is the prefered way?
Thanks.
Best Regards,
Pi-Cheng
[1] http://marc.info/?l=linux-pmm=143850044118837w=2
[2] http://marc.info/?l=linux-kernelm=143835585905028w=2
Signed-off-by: Pi-Cheng Chen pi-cheng.c...@linaro.org
Reviewed-by: Daniel Kurtz djku...@chromium.org
---
Changes in v4:
- Address comments for v3
- Rebase to the patch that adds 13mhz clock for MT8173[1]
Changes in v3:
- Rebase to 4.2-rc1
- Fix some issues of v2
Changes in v2:
- Remove use of .determine_rate callback
[1] http://patchwork.kernerl.xyz/patch/6777041/
---
drivers/clk/mediatek/Makefile | 2 +-
drivers/clk/mediatek/clk-cpumux.c | 127
+
drivers/clk/mediatek/clk-cpumux.h | 22 ++
drivers/clk/mediatek/clk-mt8173.c | 23 ++
include/dt-bindings/clock/mt8173-clk.h | 4 +-
5 files changed, 176 insertions(+), 2 deletions(-)
create mode 100644 drivers/clk/mediatek/clk-cpumux.c
create mode 100644 drivers/clk/mediatek/clk-cpumux.h
diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile
index 8e4b2a4..299917a 100644
--- a/drivers/clk/mediatek/Makefile
+++ b/drivers/clk/mediatek/Makefile
@@ -1,4 +1,4 @@
-obj-y += clk-mtk.o clk-pll.o clk-gate.o
+obj-y += clk-mtk.o clk-pll.o clk-gate.o clk-cpumux.o
obj-$(CONFIG_RESET_CONTROLLER) += reset.o
obj-y += clk-mt8135.o
obj-y += clk-mt8173.o
diff --git a/drivers/clk/mediatek/clk-cpumux.c
b/drivers/clk/mediatek/clk-cpumux.c
new file mode 100644
index 000..fb04fe1
--- /dev/null
+++ b/drivers/clk/mediatek/clk-cpumux.c
@@ -0,0 +1,127 @@
+/*
+ * Copyright (c) 2015 Linaro Ltd.
+ * Author: Pi-Cheng Chen pi-cheng.c...@linaro.org
+ *
+ * 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.
+ */
+
+#include linux/clk-provider.h
+#include linux/mfd/syscon.h
+#include linux/slab.h
+
+#include clk-mtk.h
+#include clk-cpumux.h
+
+struct mtk_clk_cpumux {
+ struct clk_hw hw;
+ struct regmap *regmap;
+ u32 reg;
+ u32 mask;
+ u8 shift;
+};
+
+static inline struct mtk_clk_cpumux *to_clk_mux(struct clk_hw *_hw)
+{
+ return container_of(_hw, struct mtk_clk_cpumux, hw);
+}
+
+static u8 clk_cpumux_get_parent(struct clk_hw *hw)
+{
+ struct mtk_clk_cpumux *mux = to_clk_mux(hw);
+ int num_parents = __clk_get_num_parents(hw-clk);
+ unsigned int val;
+
+ regmap_read(mux-regmap, mux-reg, val);
+
+ val = mux-shift;
+ val = mux-mask;
+
+ if (val = num_parents)
+ return -EINVAL;
+
+ return val;
+}
+
+static int clk_cpumux_set_parent(struct clk_hw *hw, u8 index)
+{
+ struct mtk_clk_cpumux *mux = to_clk_mux(hw);
+ u32 mask, val;
+
+ val = index mux-shift;
+ mask = mux-mask mux-shift;
+
+ return regmap_update_bits(mux-regmap, mux-reg, mask, val);
+}
+
+static const struct clk_ops clk_cpumux_ops = {
+ .get_parent = clk_cpumux_get_parent,
+ .set_parent = clk_cpumux_set_parent,
+};
+
+static struct clk __init *mtk_clk_register_cpumux(const struct mtk_composite
*mux,
+struct regmap *regmap)
+{
+ struct mtk_clk_cpumux *cpumux;
+ struct clk *clk;
+ struct clk_init_data init;
+
+ cpumux = kzalloc(sizeof(*cpumux), GFP_KERNEL);
+ if (!cpumux)
+ return ERR_PTR(-ENOMEM);
+
+ init.name = mux-name;
+ init.ops = clk_cpumux_ops;
+ init.parent_names = mux-parent_names;
+ init.num_parents = mux-num_parents;
+ init.flags = mux-flags;
+
+ cpumux-reg = mux-mux_reg;
+ cpumux-shift = mux-mux_shift;
+ cpumux-mask = BIT(mux-mux_width) - 1;
+ cpumux-regmap = regmap;
+ cpumux-hw.init = init;
+
+ clk = clk_register(NULL, cpumux-hw);
+ if (IS_ERR(clk))
+ kfree(cpumux);
+
+ return clk;
+}
+
+int __init mtk_clk_register_cpumuxes(struct device_node *node,
+ const struct mtk_composite *clks, int num,
+
Re: [PATCH v6 0/3] Add MediaTek display PWM driver
On Fri, 2015-07-24 at 17:10 +0800, YH Huang wrote: On Fri, 2015-07-24 at 10:42 +0200, Matthias Brugger wrote: On Monday, July 20, 2015 04:17:14 PM YH Huang wrote: This patch series add the use of display PWM driver, documentation and device tree for Mediatek SoCs. The driver is used to support the backlight of the panel. This is based on v4.2-rc1. The clock definitions (CLK_MM_DISP_PWM*) are added by James Liao's patch: clk: mediatek: Add subsystem clocks of MT8173 Change in v6: 1. Enable clocks in the pwm_enable function 2. Remove suspend/resume code since pwm-backlight driver has done the same things 3. Revise some code to make it easier to read Can you please provide the whole change log for all versions the next time. It's easier this way to understand the evolution of the series. Change in v6: 1. Enable clocks in the pwm_enable function. 2. Remove suspend/resume code since pwm-backlight driver has done the same things. 3. Revise some code to make it easier to read. Change in v5: 1. Configure PWM output via pinctrl. 2. Fix the parameter name in dtsi. Change in v4: 1. Codebase is on v4.2-rc1. 2. Add the PWM node in dtsi. 3. Change the dependency in Kconfig. 4. Rewrite some code for readability. Change in v3: 1. Add suspend/resume function. 2. Fix the formula for high_width calculation. 3. Rewrite some code to make it easier to read. 4. Add more information in the commit message. Change in v2: 1. Rewrite descriptions for driver in kconfig to make it much clear. 2. Rename the driver from pwm-mediatek-disp to pwm-mtk-disp. 3. Disable clocks in the error path. 4. Change the shift values in decimal instead of hex. 5. Rename and add some variables or function name for consistency and readability. 6. Drop unnecessary parentheses, spaces, variables and add newlines to make the code easiler to read. Thanks for your suggestion. Hi Thierry, Do you have any suggestions? Maybe we could apply the patch? Regards, YH Huang -- 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 V3 3/6] slimbus: Add messaging APIs to slimbus framework
Slimbus devices use value-element, and information elements to
control device parameters (e.g. value element is used to represent
gain for codec, information element is used to represent interrupt
status for codec when codec interrupt fires).
Messaging APIs are used to set/get these value and information
elements. Slimbus specification uses 8-bit transaction IDs for
messages where a read-value is anticipated. Framework uses a table
of pointers to store those TIDs and responds back to the caller in
O(1).
Caller can opt to do synchronous, or asynchronous reads/writes. For
asynchronous operations, the callback will be called from atomic
context.
Signed-off-by: Sagar Dharia sdha...@codeaurora.org
Tested-by: Naveen Kaje nk...@codeaurora.org
---
drivers/slimbus/Makefile | 2 +-
drivers/slimbus/slim-core.c | 44 +
drivers/slimbus/slim-messaging.c | 378 +++
include/linux/slimbus.h | 226 +++
4 files changed, 649 insertions(+), 1 deletion(-)
create mode 100644 drivers/slimbus/slim-messaging.c
diff --git a/drivers/slimbus/Makefile b/drivers/slimbus/Makefile
index aa9c147..d95a0a2 100644
--- a/drivers/slimbus/Makefile
+++ b/drivers/slimbus/Makefile
@@ -1,4 +1,4 @@
#
# Makefile for kernel slimbus framework.
#
-obj-$(CONFIG_SLIMBUS) += slim-core.o
+obj-$(CONFIG_SLIMBUS) += slim-core.o slim-messaging.o
diff --git a/drivers/slimbus/slim-core.c b/drivers/slimbus/slim-core.c
index d3fa28b..9d104ee 100644
--- a/drivers/slimbus/slim-core.c
+++ b/drivers/slimbus/slim-core.c
@@ -17,6 +17,7 @@
#include linux/completion.h
#include linux/idr.h
#include linux/pm_runtime.h
+#include linux/dma-mapping.h
#include linux/slimbus.h
#include linux/of.h
@@ -454,7 +455,37 @@ int slim_register_controller(struct slim_controller *ctrl)
ctrl-min_cg = SLIM_MIN_CLK_GEAR;
if (!ctrl-max_cg)
ctrl-max_cg = SLIM_MAX_CLK_GEAR;
+
mutex_init(ctrl-m_ctrl);
+ spin_lock_init(ctrl-tx.lock);
+ spin_lock_init(ctrl-rx.lock);
+
+ ctrl-pending_wr = kcalloc((ctrl-tx.n - 1),
+ sizeof(struct slim_pending),
+ GFP_KERNEL);
+ if (!ctrl-pending_wr) {
+ ret = -ENOMEM;
+ goto wr_alloc_failed;
+ }
+
+ sema_init(ctrl-tx_sem, (ctrl-tx.n - 1));
+
+ ctrl-tx.base = dma_alloc_coherent(ctrl-dev.parent,
+ (ctrl-tx.sl_sz * ctrl-tx.n),
+ ctrl-tx.phy, GFP_KERNEL);
+ if (!ctrl-tx.base) {
+ ret = -ENOMEM;
+ goto tx_alloc_failed;
+ }
+
+ ctrl-rx.base = dma_alloc_coherent(ctrl-dev.parent,
+ (ctrl-rx.sl_sz * ctrl-rx.n),
+ ctrl-rx.phy, GFP_KERNEL);
+ if (!ctrl-rx.base) {
+ ret = -ENOMEM;
+ goto rx_alloc_failed;
+ }
+
ret = device_register(ctrl-dev);
if (ret)
goto out_list;
@@ -472,10 +503,19 @@ int slim_register_controller(struct slim_controller *ctrl)
err_workq_failed:
device_unregister(ctrl-dev);
+ dma_free_coherent(ctrl-dev.parent, (ctrl-rx.sl_sz * ctrl-rx.n),
+ ctrl-rx.base, ctrl-rx.phy);
+rx_alloc_failed:
+ dma_free_coherent(ctrl-dev.parent, (ctrl-tx.sl_sz * ctrl-tx.n),
+ ctrl-tx.base, ctrl-tx.phy);
+tx_alloc_failed:
+ kfree(ctrl-pending_wr);
+wr_alloc_failed:
out_list:
mutex_lock(slim_lock);
idr_remove(ctrl_idr, ctrl-nr);
mutex_unlock(slim_lock);
+ dev_err(ctrl-dev, slimbus controller registration failed:%d, ret);
return ret;
}
EXPORT_SYMBOL_GPL(slim_register_controller);
@@ -527,6 +567,10 @@ int slim_del_controller(struct slim_controller *ctrl)
wait_for_completion(ctrl-dev_released);
list_del(ctrl-list);
destroy_workqueue(ctrl-wq);
+ dma_free_coherent(ctrl-dev.parent, (ctrl-rx.sl_sz * ctrl-rx.n),
+ ctrl-rx.base, ctrl-rx.phy);
+ dma_free_coherent(ctrl-dev.parent, (ctrl-tx.sl_sz * ctrl-tx.n),
+ ctrl-tx.base, ctrl-tx.phy);
/* free bus id */
mutex_lock(slim_lock);
idr_remove(ctrl_idr, ctrl-nr);
diff --git a/drivers/slimbus/slim-messaging.c b/drivers/slimbus/slim-messaging.c
new file mode 100644
index 000..09ea850
--- /dev/null
+++ b/drivers/slimbus/slim-messaging.c
@@ -0,0 +1,378 @@
+/* Copyright (c) 2011-2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only 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
[PATCH V3 2/6] of/slimbus: OF helper for SLIMbus
OF helper routine scans the SLIMbus DeviceTree, allocates resources,
and creates slim_devices according to the hierarchy.
Signed-off-by: Sagar Dharia sdha...@codeaurora.org
---
Documentation/devicetree/bindings/slimbus/bus.txt | 46 ++
drivers/slimbus/slim-core.c | 75 +++
2 files changed, 121 insertions(+)
create mode 100644 Documentation/devicetree/bindings/slimbus/bus.txt
diff --git a/Documentation/devicetree/bindings/slimbus/bus.txt
b/Documentation/devicetree/bindings/slimbus/bus.txt
new file mode 100644
index 000..a79ed7a
--- /dev/null
+++ b/Documentation/devicetree/bindings/slimbus/bus.txt
@@ -0,0 +1,46 @@
+SLIM(Serial Low Power Interchip Media Bus) bus
+
+SLIMbus is a 2-wire bus, and is used to communicate with peripheral
+components like audio-codec.
+
+Controller is a normal device using binding for whatever bus it is
+on (e.g. platform bus).
+Required property for SLIMbus controller node:
+- compatible - name of SLIMbus controller following generic names
+ recommended practice.
+- #address-cells - should be 6 (number of cells required to define
+ enumeration address of the device on SLIMbus)
+- #size-cells - should be 0
+
+No other properties are required in the SLIMbus controller bus node.
+
+Child nodes:
+Every SLIMbus controller node can contain zero or more child nodes
+representing slave devices on the bus. Every SLIMbus slave device is
+uniquely determined by the 6 byte enumeration address.
+
+Required property for SLIMbus child node:
+- reg - 6 byte enumeration address of the slave
+
+Optional:
+- compatible - Slave devices can use compatible field to have a name.
+ If this field is missing, name of the device will be
+ determined using slave's enumeration address.
+ (e.g. in the example below, slave's name will be:
+ 0x217:0x60:0x1:0x0)
+
+SLIMbus example for Qualcomm's slimbus manager compoent:
+
+ slim@2808 {
+ compatible = qcom,slim-msm;
+ reg = 0x2808 0x2000,
+ reg-names = slimbus_physical;
+ interrupts = 0 33 0;
+ interrupt-names = slimbus_irq;
+ clocks = lcc SLIMBUS_SRC, lcc AUDIO_SLIMBUS_CLK;
+ clock-names = iface_clk, core_clk;
+
+ slim_codec_slave {
+ reg = 00 01 60 00 17 02;
+ };
+ };
diff --git a/drivers/slimbus/slim-core.c b/drivers/slimbus/slim-core.c
index ee80c1b..d3fa28b 100644
--- a/drivers/slimbus/slim-core.c
+++ b/drivers/slimbus/slim-core.c
@@ -18,6 +18,7 @@
#include linux/idr.h
#include linux/pm_runtime.h
#include linux/slimbus.h
+#include linux/of.h
static DEFINE_MUTEX(slim_lock);
static DEFINE_IDR(ctrl_idr);
@@ -289,6 +290,79 @@ static LIST_HEAD(board_list);
static LIST_HEAD(slim_ctrl_list);
static DEFINE_MUTEX(board_lock);
+#if IS_ENABLED(CONFIG_OF)
+/* OF helpers for SLIMbus */
+static void of_register_slim_devices(struct slim_controller *ctrl)
+{
+ struct device_node *node;
+ struct slim_boardinfo *temp, *binfo = NULL;
+ int n = 0;
+
+ if (!ctrl-dev.of_node)
+ return;
+
+ for_each_child_of_node(ctrl-dev.of_node, node) {
+ int ret;
+ u32 ea[6];
+ struct slim_device *slim;
+ char *name;
+
+ ret = of_property_read_u32_array(node, reg, ea, 6);
+ if (ret) {
+ dev_err(ctrl-dev, of_slim: E-addr err:%d\n, ret);
+ continue;
+ }
+ name = kcalloc(SLIMBUS_NAME_SIZE, sizeof(char), GFP_KERNEL);
+ if (!name)
+ goto of_slim_err;
+
+ slim = kzalloc(sizeof(struct slim_device), GFP_KERNEL);
+ if (!slim) {
+ kfree(name);
+ goto of_slim_err;
+ }
+ slim-e_addr.manf_id = (u16)((ea[5] 8) | ea[4]);
+ slim-e_addr.prod_code = (u16)((ea[3] 8) | ea[2]);
+ slim-e_addr.dev_index = (u8)ea[1];
+ slim-e_addr.instance = (u8)ea[0];
+
+ ret = of_modalias_node(node, name, SLIMBUS_NAME_SIZE);
+ if (ret 0) {
+ /* use device address for name, if not specified */
+ snprintf(name, SLIMBUS_NAME_SIZE, 0x%x:0x%x:0x%x:0x%x,
+slim-e_addr.manf_id, slim-e_addr.prod_code,
+slim-e_addr.dev_index, slim-e_addr.instance);
+ }
+
+ temp = krealloc(binfo, (n + 1) * sizeof(struct slim_boardinfo),
+ GFP_KERNEL);
+ if (!temp) {
+ kfree(name);
+ kfree(slim);
+ goto of_slim_err;
+ }
+ binfo = temp;
+
Re: [PATCH v3] dtb: Create a common home for cross-architecture dtsi files.
On Sat, 2015-08-01 at 15:43 +0900, Masahiro Yamada wrote: 2015-08-01 15:21 GMT+09:00 Masahiro Yamada yamada.masah...@socionext.com : 2015-07-31 23:31 GMT+09:00 Ian Campbell ian.campb...@citrix.com: Commit 9ccd608070b6 arm64: dts: add device tree for ARM SMM-A53x2 on LogicTile Express 20MG added a new dts file to arch/arm64 which included ../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi, i.e. a .dtsi supplied by arch/arm. Unfortunately this causes some issues for the split device tree repository[0], since things get moved around there. In that context the new .dts ends up at src/arm64/arm/vexpress-v2f-1xv7-ca53x2.dts while the include is at src/arm/vexpress-v2m-rs1.dtsi. Typo? src/arm64 - arch/arm64 src/arm- arch/arm I retract this comment with my apology. (I was seeing the kernel tree, not devicetree-rebasing) Right ;-) I fixed the commit formatting and took your Reviewed-by. I shall post v4 shortly. Thanks, Ian. -- 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 V3 5/6] slimbus: Add support for 'clock-pause' feature
Per slimbus specification, a reconfiguration sequence known as
'clock pause' needs to be broadcast over the bus while entering low-
power mode. Clock-pause is initiated by the controller driver.
To exit clock-pause, controller typically wakes up the framer device.
Since wakeup precedure is controller-specific, framework calls it via
controller's function pointer to invoke it.
Signed-off-by: Sagar Dharia sdha...@codeaurora.org
---
drivers/slimbus/Makefile | 2 +-
drivers/slimbus/slim-core.c | 2 +
drivers/slimbus/slim-sched.c | 121 +++
include/linux/slimbus.h | 65 +++
4 files changed, 189 insertions(+), 1 deletion(-)
create mode 100644 drivers/slimbus/slim-sched.c
diff --git a/drivers/slimbus/Makefile b/drivers/slimbus/Makefile
index 574a892..cc0d20a 100644
--- a/drivers/slimbus/Makefile
+++ b/drivers/slimbus/Makefile
@@ -1,5 +1,5 @@
#
# Makefile for kernel slimbus framework.
#
-obj-$(CONFIG_SLIMBUS) += slim-core.o slim-messaging.o
+obj-$(CONFIG_SLIMBUS) += slim-core.o slim-messaging.o
slim-sched.o
obj-$(CONFIG_SLIM_QCOM_CTRL) += slim-qcom-ctrl.o
diff --git a/drivers/slimbus/slim-core.c b/drivers/slimbus/slim-core.c
index 9d104ee..5d27ff2 100644
--- a/drivers/slimbus/slim-core.c
+++ b/drivers/slimbus/slim-core.c
@@ -459,6 +459,8 @@ int slim_register_controller(struct slim_controller *ctrl)
mutex_init(ctrl-m_ctrl);
spin_lock_init(ctrl-tx.lock);
spin_lock_init(ctrl-rx.lock);
+ mutex_init(ctrl-sched.m_reconf);
+ init_completion(ctrl-sched.pause_comp);
ctrl-pending_wr = kcalloc((ctrl-tx.n - 1),
sizeof(struct slim_pending),
diff --git a/drivers/slimbus/slim-sched.c b/drivers/slimbus/slim-sched.c
new file mode 100644
index 000..e44922d
--- /dev/null
+++ b/drivers/slimbus/slim-sched.c
@@ -0,0 +1,121 @@
+/* Copyright (c) 2011-2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only 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.
+ */
+
+#include linux/errno.h
+#include linux/slimbus.h
+/**
+ * slim_ctrl_clk_pause: Called by slimbus controller to enter/exit 'clock
pause'
+ * Slimbus specification needs this sequence to turn-off clocks for the bus.
+ * The sequence involves sending 3 broadcast messages (reconfiguration
+ * sequence) to inform all devices on the bus.
+ * To exit clock-pause, controller typically wakes up active framer device.
+ * @ctrl: controller requesting bus to be paused or woken up
+ * @wakeup: Wakeup this controller from clock pause.
+ * @restart: Restart time value per spec used for clock pause. This value
+ * isn't used when controller is to be woken up.
+ * This API executes clock pause reconfiguration sequence if wakeup is false.
+ * If wakeup is true, controller's wakeup is called.
+ * For entering clock-pause, -EBUSY is returned if a message txn in pending.
+ */
+int slim_ctrl_clk_pause(struct slim_controller *ctrl, bool wakeup, u8 restart)
+{
+ int i, ret = 0;
+ unsigned long flags;
+ struct slim_sched *sched = ctrl-sched;
+ struct slim_val_inf msg = {0, 0, NULL, NULL, NULL, NULL};
+
+ DEFINE_SLIM_BCAST_TXN(txn, SLIM_MSG_MC_BEGIN_RECONFIGURATION,
+ 3, SLIM_LA_MANAGER, msg);
+
+ if (wakeup == false restart SLIM_CLK_UNSPECIFIED)
+ return -EINVAL;
+ mutex_lock(sched-m_reconf);
+ if (wakeup) {
+ if (sched-clk_state == SLIM_CLK_ACTIVE) {
+ mutex_unlock(sched-m_reconf);
+ return 0;
+ }
+ /**
+* Fine-tune calculation based on clock gear,
+* message-bandwidth after bandwidth management
+*/
+ ret = wait_for_completion_timeout(sched-pause_comp,
+ msecs_to_jiffies(100));
+ if (!ret) {
+ mutex_unlock(sched-m_reconf);
+ pr_err(Previous clock pause did not finish);
+ return -ETIMEDOUT;
+ }
+ ret = 0;
+ /**
+* Slimbus framework will call controller wakeup
+* Controller should make sure that it sets active framer
+* out of clock pause
+*/
+ if (sched-clk_state == SLIM_CLK_PAUSED ctrl-wakeup)
+ ret = ctrl-wakeup(ctrl);
+ if (!ret)
+ sched-clk_state =
RE: [PATCH v2 2/2] powerpc/mpc85xx: Add FSL QorIQ DPAA FMan support to the SoC device tree(s)
Regards,
Igal Liberman.
-Original Message-
From: Wood Scott-B07421
Sent: Thursday, July 30, 2015 11:12 PM
To: Liberman Igal-B31950
Cc: devicetree@vger.kernel.org; linuxppc-...@lists.ozlabs.org; Bucur
Madalin-Cristian-B32716; linux-ker...@vger.kernel.org
Subject: Re: [PATCH v2 2/2] powerpc/mpc85xx: Add FSL QorIQ DPAA FMan
support to the SoC device tree(s)
On Thu, 2015-07-30 at 07:33 +0300, Igal.Liberman wrote:
@@ -307,4 +307,117 @@
reg = 0xe 0x1000;
fsl,has-rstcr;
};
+
+ fman@10{
+ #address-cells = 1;
+ #size-cells = 1;
+ cell-index = 0;
+ ranges = 0 0x10 0x10;
+ compatible = fsl,fman;
+ reg = 0x10 0x10;
+ interrupts = 24 2 0 0, 16 2 1 30;
+ clock-frequency = 0;
+ fsl,qman-channel-range = 0x40 0x7;
fman is supposed to have clocks/clock-names, not clock-frequency.
The new clock binding doesn't support P1023 yet.
I'll drop P1023 from this submission, it's not supported currently by the
driver, we'll re-add it later.
-Scott
Re: [PATCH 2/2] iio: proximity: add support for PulsedLight LIDAR
On 08/02/2015 11:28 PM, Matt Ranostay wrote:
On Sun, Aug 2, 2015 at 2:42 AM, Lars-Peter Clausen l...@metafoo.de wrote:
On 08/01/2015 05:58 AM, Matt Ranostay wrote:
[...]
+
+struct lidar_data {
+ struct mutex lock;
+ struct iio_dev *indio_dev;
+ struct i2c_client *client;
+
+ /* config */
+ int calib_bias;
+
+ u16 buffer[5]; /* 2 byte distance + 8 byte timestamp */
Needs to be in its own cacheline to avoid issues if the I2C controller is
using DMA.
Ah though this was only needed for SPI.
At least some I2C master drivers directly use the buffer for DMA. But I was
being stupid here anyway, you don't actually pass the buffer itself to the
I2C transfer functions so everything is fine as it was.
u16 buffer[5] cacheline_aligned;
+};
[...]
+static inline int lidar_read_byte(struct lidar_data *data, int reg)
I'd drop the inline. The compiler is smart enough to figure out whether it
makes sense to inline it or not.
Got it.
+{
+ struct i2c_client *client = data-client;
+ int ret;
+
+ ret = i2c_smbus_write_byte(client, reg);
+ if (ret 0) {
+ dev_err(client-dev, cannot write addr value);
+ return ret;
+ }
+
+ ret = i2c_smbus_read_byte(client);
+ if (ret 0) {
+ dev_err(client-dev, cannot read data value);
+ return ret;
+ }
Instead of using a write_byte/read_byte combination rather use
i2c_smbus_read_byte_data(). I think that will do the same, but in one atomic
operation.
Yes I would normally do that but this device doesn't seem to support
that functionally, always returns zeros.
That's an interesting device. Maybe add a comment explaining the oddity. I'm
sure I'm not the only one who'll wonder about this.
[...]
+static struct i2c_driver lidar_driver = {
+ .driver = {
+ .name = LIDAR_DRV_NAME,
+ .owner = THIS_MODULE,
You added a DT vendor prefix, but there is no of match table for the driver.
So without of_match_table it isn't needed to have a vendor id?
pulsedlight,lidar maps to the i2c_device_id
I thinking the other way around. If you intend to instantiate the device via
devicetree it is better to explicit add a of_device_id table rather than
relying on the implicit mechanism that uses i2c_device_id.
You should also add an entry for the device to
Documentation/devicetree/bindings/i2c/trivial-devices.txt
--
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/2] iio: proximity: add support for PulsedLight LIDAR
On Mon, Aug 3, 2015 at 1:00 AM, Lars-Peter Clausen l...@metafoo.de wrote:
On 08/02/2015 11:28 PM, Matt Ranostay wrote:
On Sun, Aug 2, 2015 at 2:42 AM, Lars-Peter Clausen l...@metafoo.de wrote:
On 08/01/2015 05:58 AM, Matt Ranostay wrote:
[...]
+
+struct lidar_data {
+ struct mutex lock;
+ struct iio_dev *indio_dev;
+ struct i2c_client *client;
+
+ /* config */
+ int calib_bias;
+
+ u16 buffer[5]; /* 2 byte distance + 8 byte timestamp */
Needs to be in its own cacheline to avoid issues if the I2C controller is
using DMA.
Ah though this was only needed for SPI.
At least some I2C master drivers directly use the buffer for DMA. But I was
being stupid here anyway, you don't actually pass the buffer itself to the
I2C transfer functions so everything is fine as it was.
Will back that change out in v3 :).
u16 buffer[5] cacheline_aligned;
+};
[...]
+static inline int lidar_read_byte(struct lidar_data *data, int reg)
I'd drop the inline. The compiler is smart enough to figure out whether it
makes sense to inline it or not.
Got it.
+{
+ struct i2c_client *client = data-client;
+ int ret;
+
+ ret = i2c_smbus_write_byte(client, reg);
+ if (ret 0) {
+ dev_err(client-dev, cannot write addr value);
+ return ret;
+ }
+
+ ret = i2c_smbus_read_byte(client);
+ if (ret 0) {
+ dev_err(client-dev, cannot read data value);
+ return ret;
+ }
Instead of using a write_byte/read_byte combination rather use
i2c_smbus_read_byte_data(). I think that will do the same, but in one atomic
operation.
Yes I would normally do that but this device doesn't seem to support
that functionally, always returns zeros.
That's an interesting device. Maybe add a comment explaining the oddity. I'm
sure I'm not the only one who'll wonder about this.
Ok will do. It seems to need a STOP condition between the read and
write. Hence why i2c_smbus_read_byte_data doesn't work.
[...]
+static struct i2c_driver lidar_driver = {
+ .driver = {
+ .name = LIDAR_DRV_NAME,
+ .owner = THIS_MODULE,
You added a DT vendor prefix, but there is no of match table for the driver.
So without of_match_table it isn't needed to have a vendor id?
pulsedlight,lidar maps to the i2c_device_id
I thinking the other way around. If you intend to instantiate the device via
devicetree it is better to explicit add a of_device_id table rather than
relying on the implicit mechanism that uses i2c_device_id.
You should also add an entry for the device to
Documentation/devicetree/bindings/i2c/trivial-devices.txt
Ok seems logical will do in v3.
--
To unsubscribe from this list: send the line unsubscribe linux-iio 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 00/17] omap_hsmmc: regulator usage cleanup and fixes
Hi Kishon, Thanks for taking a look at the regulator code. Do you have a public git repository so I can pull your patches instead of cherry picking 1-by-1? /Andi 2015-07-29 13:09 GMT+02:00 Kishon Vijay Abraham I kis...@ti.com: This patch series does the following *) Uses devm_regulator_get_optional() for vmmc and then removes the CONFIG_REGULATOR check altogether. *) return on -EPROBE_DEFER *) enable/disable vmmc_aux regulator based on prior state This series is in preparation for implementing the voltage switch sequence so that UHS cards can be supported. Did basic read/write test in J6, J6 Eco, Beagle-x15, AM437x EVM, Beaglebone black, OMAP5 uEVM and OMAP4 PANDA. Kishon Vijay Abraham I (16): mmc: host: omap_hsmmc: use devm_regulator_get_optional() for vmmc mmc: host: omap_hsmmc: return error from omap_hsmmc_reg_get on -EPROBE_DEFER mmc: host: omap_hsmmc: cleanup omap_hsmmc_reg_get() mmc: host: omap_hsmmc: use the ocrmask provided by the vmmc regulator mmc: host: omap_hsmmc: use mmc_host's vmmc and vqmmc mmc: host: omap_hsmmc: remove unnecessary pbias set_voltage mmc: host: omap_hsmmc: return error if any of the regulator APIs fail mmc: host: omap_hsmmc: add separate functions for enable/disable supply mmc: host: omap_hsmmc: add separate function to set pbias mmc: host: omap_hsmmc: avoid pbias regulator enable on power off mmc: host: omap_hsmmc: don't use -set_power to set initial regulator state ARM: dts: am57xx-beagle-x15: Fix regulator populated in MMC1 dt node mmc: host: omap_hsmmc: enable/disable vmmc_aux regulator based on prior state mmc: host: omap_hsmmc: use regulator_is_enabled to find pbias status mmc: host: omap_hsmmc: use ios-vdd for setting vmmc voltage mmc: host: omap_hsmmc: remove CONFIG_REGULATOR check Roger Quadros (1): mmc: host: omap_hsmmc: use mmc_of_parse_voltage to get ocr_avail .../devicetree/bindings/mmc/ti-omap-hsmmc.txt |2 + arch/arm/boot/dts/am57xx-beagle-x15.dts|1 - drivers/mmc/host/omap_hsmmc.c | 333 +--- 3 files changed, 216 insertions(+), 120 deletions(-) -- 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
RE: [PATCH v2 1/2] powerpc/mpc85xx: Create dts components for the FSL QorIQ DPAA FMan
Regards,
Igal Liberman.
-Original Message-
From: Wood Scott-B07421
Sent: Thursday, July 30, 2015 11:00 PM
To: Liberman Igal-B31950
Cc: devicetree@vger.kernel.org; linuxppc-...@lists.ozlabs.org; Bucur
Madalin-Cristian-B32716; linux-ker...@vger.kernel.org
Subject: Re: [PATCH v2 1/2] powerpc/mpc85xx: Create dts components for
the FSL QorIQ DPAA FMan
On Thu, 2015-07-30 at 07:32 +0300, Igal.Liberman wrote:
+fman0: fman@40{
+ #address-cells = 1;
+ #size-cells = 1;
+ cell-index = 0;
+ compatible = fsl,fman;
+ ranges = 0 0x40 0x10;
+ reg = 0x40 0x10;
+ interrupts = 96 2 0 0, 16 2 1 1;
+ clocks = clockgen 3 0;
+ clock-names = fm0clk;
clock-names should be fmanclk as per the binding. And why would you
want the driver to have to encode the fman index into the name in order to
look the clock up by name?
Well, yes, this should be fmanclk. The driver doesn't need to know the index.
I'll fix that and re-submit.
Igal.
-Scott
N�r��yb�X��ǧv�^�){.n�+���z��z��z)w* jg��� �ݢj/���z�ޖ��2�ޙ�)ߡ�a���� �G���h��j:+v���w��٥
Re: [linux-sunxi] [PATCH] ARM: dts: sunxi: Raise minimum CPU voltage for sun7i-a20 to a level all boards can supply
Hi Julian, Julian Calaby schrieb am 03.08.2015 01:35: sun7i-a20.dtsi contains an cpufreq operating point at 0.9 volts. Most A20 boards (or all?), however, do not allow the voltage to go below 1.0V. Thus, raise the voltage for the lowest operating point to 1.0V so all boards can actually use it. Surely it wouldn't be added here if some could supply 0.9v. Maybe. I just know some boards don't (e.g. Cubieboard 2, Cubietruck, BananaPi) and don't know of any that does. But that's not my point. I think that a common minimum operating point, defined on the SOC level, should be defined in a way that works on all boards. Is the code that uses this smart enough to sensibly switch between two operating points with the same frequency and different voltages? If so, maybe just add a 144MHz @ 1.0v operating point? I never tried and I probably won't have time to test that before the weekend. The current behaviour is this, though: On boards that set their minimum CPU voltage to 1.0V, the lowest operating point will simply not be available to the user. (Alternatively, would it make sense to modify the code that uses this to use frequencies with voltages specified that are lower than can be supplied with the lowest voltage it can?) Considering OPPv2 is in the works, maybe not? Thanks, Timo -- 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 V3 6/6] slim: qcom: Add runtime-pm support using clock-pause feature
Slimbus HW mandates that clock-pause sequence has to be executed
before disabling relevant interface and core clocks.
Runtime-PM's autosuspend feature is used here to enter/exit low
power mode for Qualcomm's Slimbus controller. Autosuspend feature
enables driver to avoid changing power-modes too frequently since
entering clock-pause is an expensive sequence
Signed-off-by: Sagar Dharia sdha...@codeaurora.org
---
drivers/slimbus/slim-qcom-ctrl.c | 149 ++-
drivers/slimbus/slim-qcom.h | 1 +
2 files changed, 149 insertions(+), 1 deletion(-)
diff --git a/drivers/slimbus/slim-qcom-ctrl.c b/drivers/slimbus/slim-qcom-ctrl.c
index 7ff0536..45023a6 100644
--- a/drivers/slimbus/slim-qcom-ctrl.c
+++ b/drivers/slimbus/slim-qcom-ctrl.c
@@ -20,6 +20,7 @@
#include linux/clk.h
#include linux/of.h
#include linux/slimbus.h
+#include linux/pm_runtime.h
#include slim-qcom.h
#define MSM_SLIM_NAME msm_slim_ctrl
@@ -210,6 +211,7 @@ rx_ret_irq:
if (q_rx)
queue_work(dev-rxwq, dev-wd);
}
+ pm_runtime_mark_last_busy(dev-dev);
/**
* All interrupts are handled: complex RX messages requiring more work
* are queued to work-queue, others are handled above
@@ -237,6 +239,28 @@ static void msm_slim_wait_retry(struct msm_slim_ctrl *dev)
msleep(msec_per_frm);
}
+static int msm_clk_pause_wakeup(struct slim_controller *ctrl)
+{
+ struct msm_slim_ctrl *dev = slim_get_ctrldata(ctrl);
+
+ clk_prepare_enable(dev-hclk);
+ clk_prepare_enable(dev-rclk);
+ writel_relaxed(1, dev-base + FRM_WAKEUP);
+ /* Make sure framer wakeup write goes through before ISR fires */
+ mb();
+ /**
+* HW Workaround: Currently, slave is reporting lost-sync messages
+* after slimbus comes out of clock pause.
+* Transaction with slave fail before slave reports that message
+* Give some time for that report to come
+* Slimbus wakes up in clock gear 10 at 24.576MHz. With each superframe
+* being 250 usecs, we wait for 5-10 superframes here to ensure
+* we get the message
+*/
+ usleep_range(1250, 2500);
+ return 0;
+}
+
static int msm_xfer_msg(struct slim_controller *ctrl, struct slim_msg_txn *txn,
void *pbuf)
{
@@ -245,6 +269,22 @@ static int msm_xfer_msg(struct slim_controller *ctrl,
struct slim_msg_txn *txn,
u32 *head = (u32 *)pbuf;
u8 *puc = (u8 *)pbuf;
u8 la = txn-la;
+ enum slim_clk_state cur_clk_state = ctrl-sched.clk_state;
+
+ if (cur_clk_state == SLIM_CLK_ENTERING_PAUSE) {
+ if (txn-mc != SLIM_MSG_MC_BEGIN_RECONFIGURATION
+ txn-mc != SLIM_MSG_MC_RECONFIGURE_NOW
+ txn-mc != SLIM_MSG_MC_NEXT_PAUSE_CLOCK)
+ return -EBUSY;
+ } else {
+ int ret = pm_runtime_get_sync(dev-dev);
+
+ if (ret 0) {
+ pm_runtime_set_suspended(dev-dev);
+ dev_err(dev-dev, runtime-pm vote failed:%d\n, ret);
+ return ret;
+ }
+ }
/* HW expects length field to be excluded */
txn-rl--;
@@ -273,6 +313,9 @@ static int msm_xfer_msg(struct slim_controller *ctrl,
struct slim_msg_txn *txn,
if (txn-msg txn-msg-wbuf)
memcpy(puc, txn-msg-wbuf, txn-msg-num_bytes);
+ if (cur_clk_state != SLIM_CLK_ENTERING_PAUSE)
+ pm_runtime_put(dev-dev);
+
return msm_slim_queue_tx(dev, head, txn-rl, MGR_TX_MSG);
}
@@ -296,13 +339,19 @@ static int msm_set_laddr(struct slim_controller *ctrl,
buf[5] = ead-instance;
/* Logical address for this EA */
buf[6] = laddr;
+
+ ret = pm_runtime_get_sync(dev-dev);
+ if (ret 0) {
+ pm_runtime_set_suspended(dev-dev);
+ dev_err(dev-dev, runtime-pm vote failed:%d\n, ret);
+ return ret;
+ }
/**
* Retries are needed since bus may lose sync when multiple devices
* are coming up and reporting present
*/
msg.wbuf = buf;
msg.num_bytes = 7;
-
retry_laddr:
ret = slim_processtxn(dev-ctrl, txn);
@@ -317,6 +366,7 @@ retry_laddr:
dev_err(dev-dev, set LADDR failed:ret:%d\n, ret);
}
}
+ pm_runtime_put(dev-dev);
return ret;
}
@@ -444,6 +494,8 @@ static int msm_slim_probe(struct platform_device *pdev)
dev-ctrl.set_laddr = msm_set_laddr;
dev-ctrl.xfer_msg = msm_xfer_msg;
+ dev-ctrl.wakeup = msm_clk_pause_wakeup;
+
dev-ctrl.tx.n = MSM_TX_MSGS;
dev-ctrl.rx.n = MSM_RX_MSGS;
dev-ctrl.tx.sl_sz = SLIM_MSGQ_BUF_LEN;
@@ -541,6 +593,12 @@ static int msm_slim_probe(struct platform_device *pdev)
*/
mb();
+ pm_runtime_use_autosuspend(pdev-dev);
+
[PATCH V3 1/6] SLIMbus: Device management on SLIMbus
SLIMbus (Serial Low Power Interchip Media Bus) is a specification developed by MIPI (Mobile Industry Processor Interface) alliance. SLIMbus is a 2-wire implementation, which is used to communicate with peripheral components like audio-codec. SLIMbus uses Time-Division-Multiplexing to accommodate multiple data channels, and control channel. Control channel has messages to do device-enumeration, messages to send/receive control-data to/from slimbus devices, messages for port/channel management, and messages to do bandwidth allocation. The framework supports multiple instances of the bus (1 controller per bus), and multiple slave devices per controller. This patch does device enumeration, logical address assignment, informing device when the device reports present/absent etc. Reporting present may need the driver to do the needful (e.g. turning on voltage regulators powering the device). So probe is called if the device is added to board-info list for a controller. Additionally device is probed when it reports present if that device doesn't need any such steps mentioned above. Signed-off-by: Sagar Dharia sdha...@codeaurora.org --- Documentation/slimbus/summary | 109 ++ drivers/Kconfig | 2 + drivers/Makefile| 1 + drivers/slimbus/Kconfig | 11 + drivers/slimbus/Makefile| 4 + drivers/slimbus/slim-core.c | 734 include/linux/mod_devicetable.h | 13 + include/linux/slimbus.h | 389 + 8 files changed, 1263 insertions(+) create mode 100644 Documentation/slimbus/summary create mode 100644 drivers/slimbus/Kconfig create mode 100644 drivers/slimbus/Makefile create mode 100644 drivers/slimbus/slim-core.c create mode 100644 include/linux/slimbus.h diff --git a/Documentation/slimbus/summary b/Documentation/slimbus/summary new file mode 100644 index 000..73d86e9 --- /dev/null +++ b/Documentation/slimbus/summary @@ -0,0 +1,109 @@ +Overview of Linux kernel SLIMbus support + + +What is SLIMbus? + +SLIMbus (Serial Low Power Interchip Media Bus) is a specification developed by +MIPI (Mobile Industry Processor Interface) alliance. The bus uses master/slave +configuration, and is a 2-wire multi-drop implementation (clock, and data). + +Currently, SLIMbus is used to interface between application processors of SoCs +(System-on-Chip) and peripheral components (typically codec).SLIMbus uses +Time-Division-Multiplexing to accommodate multiple data channels, and +a control channel. + +The control channel is used for various control functions such as bus +management, configuration and status updates.These messages can be unicast (e.g. +reading/writing device specific values), or multicast (e.g. data channel +reconfiguration sequence is a broadcast message announced to all devices) + +A data channel is used for data-transfer between 2 Slimbus devices. Data +channel uses dedicated ports on the device. + +Hardware description: +- +Slimbus specification has different types of device classifications based on +their capabilities. +A manager device is responsible for enumeration, configuration, and dynamic +channel allocation. Every bus has 1 active manager. + +A generic device is a device providing application functionality (e.g. codec). + +Framer device is responsible for clocking the bus, and transmitting frame-sync +and framing information on the bus. + +Each SLIMbus component has an interface device for monitoring physical layer. + +Typically each SoC contains SLIMbus component having 1 manager, 1 framer device, +1 generic device (for data channel support), and 1 interface device. +External peripheral SLIMbus component usually has 1 generic device (for +functionality/data channel support), and an associated interface device. +The generic device's registers are mapped as 'value elements' so that they can +be written/read using Slimbus control channel exchanging control/status type of +information. +In case there are multiple framer devices on the same bus, manager device is +responsible to select the active-framer for clocking the bus. + +Per specification, Slimbus uses clock gears to do power management based on +current frequency and bandwidth requirements. There are 10 clock gears and each +gear changes the Slimbus frequency to be twice its previous gear. + +Each device has a 6-byte enumeration-address and the manager assigns every +device with a 1-byte logical address after the devices report presence on the +bus. + +Software description: +- +There are 2 types of SLIMbus drivers: + +slim_controller represents a 'controller' for SLIMbus. This driver should +implement duties needed by the SoC (manager device, associated +interface device for monitoring the layers and reporting errors, default +framer device). + +slim_device represents the 'generic device/component' for SLIMbus, and a
[PATCH V3 4/6] slim: qcom: Add Qualcomm Slimbus controller driver
This controller driver programs manager, interface, and framer
devices for Qualcomm's slimbus HW block.
Manager component currently implements logical address setting,
and messaging interface.
Interface device reports bus synchronization information, and framer
device clocks the bus from the time it's woken up, until clock-pause
is executed by the manager device.
Signed-off-by: Sagar Dharia sdha...@codeaurora.org
---
.../devicetree/bindings/slimbus/slim-qcom-ctrl.txt | 42 ++
drivers/slimbus/Kconfig| 10 +
drivers/slimbus/Makefile | 1 +
drivers/slimbus/slim-qcom-ctrl.c | 587 +
drivers/slimbus/slim-qcom.h| 65 +++
5 files changed, 705 insertions(+)
create mode 100644 Documentation/devicetree/bindings/slimbus/slim-qcom-ctrl.txt
create mode 100644 drivers/slimbus/slim-qcom-ctrl.c
create mode 100644 drivers/slimbus/slim-qcom.h
diff --git a/Documentation/devicetree/bindings/slimbus/slim-qcom-ctrl.txt
b/Documentation/devicetree/bindings/slimbus/slim-qcom-ctrl.txt
new file mode 100644
index 000..5dd6e0f
--- /dev/null
+++ b/Documentation/devicetree/bindings/slimbus/slim-qcom-ctrl.txt
@@ -0,0 +1,42 @@
+Qualcomm SLIMBUS controller
+qcom,slim-msm: This controller is used if applications processor
+ driver is controlling slimbus master component. This driver is
+ responsible for communicating with slave HW directly using
+ messaging interface, and doing data channel management.
+
+Required properties:
+
+ - reg : Offset and length of the register region(s) for the device
+ - reg-names : Register region name(s) referenced in reg above
+Required register resource entries are:
+slimbus_physical: Physical adderss of controller register blocks
+slimbus_bam_physical: Physical address of Bus Access Module (BAM)
+for this controller
+ - compatible : should be qcom,slim-msm if this is master component driver
+ - interrupts : Interrupt numbers used by this controller
+ - interrupt-names : Required interrupt resource entries are:
+ slimbus_irq : Interrupt for SLIMBUS core
+ - clocks : Interface and core clocks used by this slimbus controller
+ - clock-names : Required clock-name entries are:
+ iface_clk : Interface clock for this controller
+ core_clk : Interrupt for controller core's BAM
+
+Optional property:
+ - reg entry for slew rate : If slew rate control register is provided, this
+ entry should be used.
+ - reg-name for slew rate: slimbus_slew_reg
+
+Example:
+ slim@2808 {
+ compatible = qcom,slim-msm;
+ reg = 0x2808 0x2000,
+ reg-names = slimbus_physical;
+ interrupts = 0 33 0;
+ interrupt-names = slimbus_irq;
+ clocks = lcc SLIMBUS_SRC, lcc AUDIO_SLIMBUS_CLK;
+ clock-names = iface_clk, core_clk;
+
+ slim_codec_slave {
+ enumeration-addr = [00 01 60 00 17 02];
+ };
+ };
diff --git a/drivers/slimbus/Kconfig b/drivers/slimbus/Kconfig
index f0b118a..afe15b3 100644
--- a/drivers/slimbus/Kconfig
+++ b/drivers/slimbus/Kconfig
@@ -9,3 +9,13 @@ menuconfig SLIMBUS
If unsure, choose N.
+if SLIMBUS
+config SLIM_QCOM_CTRL
+ tristate Qualcomm Slimbus Manager Component
+ depends on SLIMBUS
+ default n
+ help
+ Select driver if Qualcomm's Slimbus Manager Component is
+ programmed using Linux kernel.
+
+endif
diff --git a/drivers/slimbus/Makefile b/drivers/slimbus/Makefile
index d95a0a2..574a892 100644
--- a/drivers/slimbus/Makefile
+++ b/drivers/slimbus/Makefile
@@ -2,3 +2,4 @@
# Makefile for kernel slimbus framework.
#
obj-$(CONFIG_SLIMBUS) += slim-core.o slim-messaging.o
+obj-$(CONFIG_SLIM_QCOM_CTRL) += slim-qcom-ctrl.o
diff --git a/drivers/slimbus/slim-qcom-ctrl.c b/drivers/slimbus/slim-qcom-ctrl.c
new file mode 100644
index 000..7ff0536
--- /dev/null
+++ b/drivers/slimbus/slim-qcom-ctrl.c
@@ -0,0 +1,587 @@
+/* Copyright (c) 2011-2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only 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.
+ */
+#include linux/irq.h
+#include linux/kernel.h
+#include linux/init.h
+#include linux/slab.h
+#include linux/io.h
+#include linux/interrupt.h
+#include linux/platform_device.h
+#include linux/delay.h
+#include linux/clk.h
+#include linux/of.h
+#include linux/slimbus.h
+#include slim-qcom.h
+
+#define MSM_SLIM_NAME
[PATCH V3 0/6] Introduce framework for SLIMbus device drivers
Changes since V2: * Multiple files to represent corresponding functionality of the framework per Srini's suggestion * Documentation/slimbus/summary to capture documentation * register_controller now adds slave devices as well for that controller (rather than additional step) per Mark's suggestion * Changed framework to make sure synchronous transactions are waited- for in framework itself per Mark's suggestion * Addressed other inline comments. Sagar Dharia (6): SLIMbus: Device management on SLIMbus of/slimbus: OF helper for SLIMbus slimbus: Add messaging APIs to slimbus framework slim: qcom: Add Qualcomm Slimbus controller driver slimbus: Add support for 'clock-pause' feature slim: qcom: Add runtime-pm support using clock-pause feature Documentation/devicetree/bindings/slimbus/bus.txt | 46 ++ .../devicetree/bindings/slimbus/slim-qcom-ctrl.txt | 42 + drivers/Kconfig| 2 + drivers/Makefile | 1 + drivers/slimbus/Kconfig| 21 + drivers/slimbus/Makefile | 5 + drivers/slimbus/slim-core.c| 855 + drivers/slimbus/slim-messaging.c | 378 + drivers/slimbus/slim-qcom-ctrl.c | 734 ++ drivers/slimbus/slim-qcom.h| 66 ++ drivers/slimbus/slim-sched.c | 121 +++ include/linux/mod_devicetable.h| 13 + include/linux/slimbus.h| 678 13 files changed, 2962 insertions(+) create mode 100644 Documentation/devicetree/bindings/slimbus/bus.txt create mode 100644 Documentation/devicetree/bindings/slimbus/slim-qcom-ctrl.txt create mode 100644 drivers/slimbus/Kconfig create mode 100644 drivers/slimbus/Makefile create mode 100644 drivers/slimbus/slim-core.c create mode 100644 drivers/slimbus/slim-messaging.c create mode 100644 drivers/slimbus/slim-qcom-ctrl.c create mode 100644 drivers/slimbus/slim-qcom.h create mode 100644 drivers/slimbus/slim-sched.c create mode 100644 include/linux/slimbus.h -- 1.8.2.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 RESENT] powerpc: dts: don't fall back to fsl,pq3-gpio for fsl,mpc8572-gpio devices
On Fri, Jul 31, 2015 at 11:16 AM, Uwe Kleine-König u.kleine-koe...@pengutronix.de wrote: While the handling of fsl,pq3-gpio and fsl,mpc8572-gpio is done in the same driver and the two hardly differ, the latter controller needs a workaround for an erratum in the gpio_get callback. To make this difference more explicit remove fsl,pq3-gpio from the list of compatibles for mpc8572 machines. Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de Acked-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij -- 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: [linux-sunxi] [PATCH] ARM: dts: sunxi: Raise minimum CPU voltage for sun7i-a20 to a level all boards can supply
Hi again, Julian Calaby schrieb am 03.08.2015 06:22: My only real objection here is are there boards that can go down to 0.9v and if so, won't this change make them less power efficient in the almost-idle case? And are those power savings enough to justify not accepting this patch? It will probably make those boards less power efficient, yes. On the other hand, boards that have their CPU regulator set to min. 1.0V might also draw more power because the lowest frequency is not available, even though the savings due to frequency are likely to be lower than the savings due to voltage. However, Stefan Monnier (added to CC) mentioned in an earlier discussion that the savings for the lowest opp are rather small and thus the benefit of the 144MHz opp would be questionable. Unfortunately, I don't have measurement equipment precise enough to test this myself and haven't found a way to read power consumption internally via the PMU in mainline yet. Thanks, Timo -- 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 v14 1/3] drm/i2c: tda998x: Add support of a DT graph of ports
On 05/08/15 11:18, Jean-Francois Moine wrote:
Two kinds of ports may be declared in a DT graph of ports: video and audio.
This patch accepts the port value from a video port as an alternative
to the video-ports property.
It also accepts audio ports in the case the transmitter is not used as
a slave encoder.
The new file include/sound/tda998x.h prepares to the definition of
a tda998x CODEC.
Signed-off-by: Jean-Francois Moine moin...@free.fr
---
.../devicetree/bindings/drm/i2c/tda998x.txt| 51
drivers/gpu/drm/i2c/tda998x_drv.c | 90 +++---
include/sound/tda998x.h| 8 ++
3 files changed, 140 insertions(+), 9 deletions(-)
create mode 100644 include/sound/tda998x.h
diff --git a/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
b/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
index e9e4bce..35f6a80 100644
--- a/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
+++ b/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
@@ -16,6 +16,35 @@ Optional properties:
- video-ports: 24 bits value which defines how the video controller
output is wired to the TDA998x input - default: 0x230145
+ This property is not used when ports are defined.
+
+Optional nodes:
+
+ - port: up to three ports.
+ The ports are defined according to [1].
+
+Video port.
+ There may be only one video port.
+ This one must contain the following property:
+
+ - port-type: must be rgb
+
+ and may contain the optional property:
+
+ - reg: 24 bits value which defines how the video controller
+ output is wired to the TDA998x input (video pins)
+ When absent, the default value is 0x230145.
Using reg property for something else than for address of some kind
seems confusing to me. Should we just add an explicit property rgb mapping?
+
+Audio ports.
+ There may be one or two audio ports.
+ These ones must contain the following properties:
+
+ - port-type: must be i2s or spdif
+
+ - reg: 8 bits value which defines how the audio controller
+ output is wired to the TDA998x input (audio pins)
+
Here I do not even understand what what the values 3 ad 4 stand for.
Also when trying to make a device file following the above binding I get
errors related the different widths of for the register property values
(I do not have the exact error at hand right now), but that prevented me
from using these patches when I last tried them.
Anyway having some clearly defined property that explicitly defines the
audio pins would make more sense to me. Even if that is not possible due
lack of proper documentation it would be better not add to the confusion
by unusual usage of reg property.
Best regards,
Jyri
ps. Did you ever give my generic hdmi codec patch a try?
+[1] Documentation/devicetree/bindings/graph.txt
Example:
@@ -26,4 +55,26 @@ Example:
interrupts = 27 2; /* falling edge */
pinctrl-0 = pmx_camera;
pinctrl-names = default;
+
+ port@230145 {
+ port-type = rgb;
+ reg = 0x230145;
+ hdmi_0: endpoint {
+ remote-endpoint = lcd0_0;
+ };
+ };
+ port@3 {/* AP1 = I2S */
+ port-type = i2s;
+ reg = 0x03; explicit
+ tda998x_i2s: endpoint {
+ remote-endpoint = audio1_i2s;
+ };
+ };
+ port@4 { /* AP2 = S/PDIF */
+ port-type = spdif;
+ reg = 0x04;
+ tda998x_spdif: endpoint {
+ remote-endpoint = audio1_spdif1;
+ };
+ };
};
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
index 424228b..0952eac 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -27,6 +27,7 @@
#include drm/drm_edid.h
#include drm/drm_of.h
#include drm/i2c/tda998x.h
+#include sound/tda998x.h
#define DBG(fmt, ...) DRM_DEBUG(fmt\n, ##__VA_ARGS__)
@@ -47,6 +48,8 @@ struct tda998x_priv {
wait_queue_head_t wq_edid;
volatile int wq_edid_wait;
struct drm_encoder *encoder;
+
+ struct tda998x_audio audio;
};
#define to_tda998x_priv(x) ((struct tda998x_priv
*)to_encoder_slave(x)-slave_priv)
@@ -774,6 +777,8 @@ static void tda998x_encoder_set_config(struct tda998x_priv
*priv,
(p-mirr_f ? VIP_CNTRL_2_MIRR_F : 0);
priv-params = *p;
+ priv-audio.port_types[0] = p-audio_format;
+ priv-audio.ports[0] = p-audio_cfg;
} explicit
static void
Re: [PATCH v3] ARM: shmobile: silk: initial device tree
Hello.
On 08/03/2015 04:00 PM, Geert Uytterhoeven wrote:
--- /dev/null
+++ renesas/arch/arm/boot/dts/r8a7794-silk.dts
@@ -0,0 +1,51 @@
+/ {
+ model = SILK;
+ compatible = renesas,silk, renesas,r8a7794;
WARNING: DT compatible string renesas,silk appears un-documented --
check ./Documentation/devicetree/bindings/
Do you plan to update Documentation/devicetree/bindings/arm/shmobile.txt?
No, I had no idea I should record the board names somewhere too...
Thanks!
Gr{oetje,eeting}s,
Geert
MBR, Sergei
--
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] ARM: shmobile: silk: initial device tree
Hi Sergei,
On Mon, Aug 3, 2015 at 5:13 PM, Sergei Shtylyov
sergei.shtyl...@cogentembedded.com wrote:
On 08/03/2015 04:00 PM, Geert Uytterhoeven wrote:
--- /dev/null
+++ renesas/arch/arm/boot/dts/r8a7794-silk.dts
@@ -0,0 +1,51 @@
+/ {
+ model = SILK;
+ compatible = renesas,silk, renesas,r8a7794;
WARNING: DT compatible string renesas,silk appears un-documented --
check ./Documentation/devicetree/bindings/
Do you plan to update Documentation/devicetree/bindings/arm/shmobile.txt?
No, I had no idea I should record the board names somewhere too...
All compatible values should be documented before being used in a
.dts(i) file.
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 v3 00/16] ARM: shmobile: Add CPG/MSTP Clock Domain
On Wed, Jul 22, 2015 at 3:00 PM, Ulf Hansson ulf.hans...@linaro.org wrote:
On 1 July 2015 at 17:57, Geert Uytterhoeven geert+rene...@glider.be wrote:
This patch series adds Clock Domain support to the Clock Pulse Generator
(CPG) Module Stop (MSTP) Clocks driver using the generic PM Domain, to
be used on shmobile SoCs without device power domains (R-Car Gen1 and
Gen2, RZ). This allows to power-manage the module clocks of SoC devices
that are part of the CPG/MSTP Clock Domain using Runtime PM, or for
system suspend/resume, similar to SoCs with device power domains
(SH-Mobile and R-Mobile).
[...]
Unless it's too late; for the series - feel free to add:
Reviewed-by: Ulf Hansson ulf.hans...@linaro.org
Thank you.
I have to respin anyway, as new nodes have been added to various .dtsi files.
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
[PATCH 3/3] MIPS: ath79: Add the reset controller to the AR9132 dtsi
Signed-off-by: Alban Bedel al...@free.fr
---
arch/mips/boot/dts/qca/ar9132.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/mips/boot/dts/qca/ar9132.dtsi
b/arch/mips/boot/dts/qca/ar9132.dtsi
index 4759cff..fb7734e 100644
--- a/arch/mips/boot/dts/qca/ar9132.dtsi
+++ b/arch/mips/boot/dts/qca/ar9132.dtsi
@@ -115,6 +115,14 @@
interrupt-controller;
#interrupt-cells = 1;
};
+
+ rst: reset-controller@1806001c {
+ compatible = qca,ar9132-reset,
+ qca,ar7100-reset;
+ reg = 0x1806001c 0x4;
+
+ #reset-cells = 1;
+ };
};
spi@1f00 {
--
2.0.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
Re: [PATCH 1/2] ARM: dts: keystone: fix the clock node for mdio
On 08/03/2015 02:11 PM, Murali Karicheri wrote: Currently the MDIO clock is pointing to clkpa instead of clkcpgmac. MDIO is part of the ethss and the clock should be clkcpgmac. Signed-off-by: Murali Karicheri m-kariche...@ti.com --- arch/arm/boot/dts/keystone.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/keystone.dtsi b/arch/arm/boot/dts/keystone.dtsi index e7a6f6d..6245a17 100644 --- a/arch/arm/boot/dts/keystone.dtsi +++ b/arch/arm/boot/dts/keystone.dtsi @@ -273,7 +273,7 @@ #size-cells = 0; reg = 0x02090300 0x100; status = disabled; - clocks = clkpa; + clocks = clkcpgmac; clock-names = fck; bus_freq= 250; }; Santosh, This is a big fix and needs to go in v4.2-rc. So please review and apply asap. v4.2 is the first release that has netcp driver fully functional and I want to fix as many known bugs as possible. Thanks. -- Murali Karicheri Linux Kernel, Keystone -- 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] MIPS: ath79: Add the reset controller to the AR9132 dtsi
On Mon, Aug 03, 2015 at 07:23:53PM +0200, Alban Bedel wrote: Acked-by: Ralf Baechle r...@linux-mips.org Philipp, Feel free to take this through the reset tree. Or I can carry this in the MIPS tree which is probably better for testing. Just lemme know. Ralf -- 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/2] ARM: dts: keystone: fix the clock node for mdio
On 08/03/2015 02:30 PM, santosh.shilim...@oracle.com wrote: On 8/3/15 11:22 AM, Murali Karicheri wrote: On 08/03/2015 02:11 PM, Murali Karicheri wrote: Currently the MDIO clock is pointing to clkpa instead of clkcpgmac. MDIO is part of the ethss and the clock should be clkcpgmac. Signed-off-by: Murali Karicheri m-kariche...@ti.com --- arch/arm/boot/dts/keystone.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/keystone.dtsi b/arch/arm/boot/dts/keystone.dtsi index e7a6f6d..6245a17 100644 --- a/arch/arm/boot/dts/keystone.dtsi +++ b/arch/arm/boot/dts/keystone.dtsi @@ -273,7 +273,7 @@ #size-cells = 0; reg= 0x02090300 0x100; status = disabled; -clocks = clkpa; +clocks = clkcpgmac; clock-names = fck; bus_freq= 250; }; Santosh, This is a big fix and needs to go in v4.2-rc. So please review and apply asap. v4.2 is the first release that has netcp driver fully functional and I want to fix as many known bugs as possible. Do you have more fixes ? If yes, please post them so that I can include them along with these two. I will try to send them up next week. I think we have got most of the know issues fixed in the netcp driver and dts for v4.2-rc. Another lingering issue is the one with multiple clock handling not supported in run time pm API causing us to use the work around 'clk_ignore_unused'. Probably this needs to be addressed in the future as fixing this is not trivial. Generic PD support would partially solve the issue for Keystone, but also needs to handle multiple clocks for keystone. Another option is to fix the NetCP and QMSS/KNAV driver for now in v4.0-rc using explicit clock APIs so that we don't have to use 'clk_ignore_unused'. And then migrate all of the drivers to run time PM API later when proper framework is implemented along with K2G support. Does this make sense? Anyways, please submit these patches at your earliest opportunity. Thanks Murali Thanks !! Regards, Santosh -- Murali Karicheri Linux Kernel, Keystone -- 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/2] ARM: dts: keystone: fix the clock node for mdio
On 8/3/15 11:50 AM, Murali Karicheri wrote: On 08/03/2015 02:30 PM, santosh.shilim...@oracle.com wrote: On 8/3/15 11:22 AM, Murali Karicheri wrote: On 08/03/2015 02:11 PM, Murali Karicheri wrote: Currently the MDIO clock is pointing to clkpa instead of clkcpgmac. MDIO is part of the ethss and the clock should be clkcpgmac. Signed-off-by: Murali Karicheri m-kariche...@ti.com --- arch/arm/boot/dts/keystone.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/keystone.dtsi b/arch/arm/boot/dts/keystone.dtsi index e7a6f6d..6245a17 100644 --- a/arch/arm/boot/dts/keystone.dtsi +++ b/arch/arm/boot/dts/keystone.dtsi @@ -273,7 +273,7 @@ #size-cells = 0; reg= 0x02090300 0x100; status = disabled; -clocks = clkpa; +clocks = clkcpgmac; clock-names = fck; bus_freq= 250; }; Santosh, This is a big fix and needs to go in v4.2-rc. So please review and apply asap. v4.2 is the first release that has netcp driver fully functional and I want to fix as many known bugs as possible. Do you have more fixes ? If yes, please post them so that I can include them along with these two. I will try to send them up next week. I think we have got most of the know issues fixed in the netcp driver and dts for v4.2-rc. Another lingering issue is the one with multiple clock handling not supported in run time pm API causing us to use the work around 'clk_ignore_unused'. Probably this needs to be addressed in the future as fixing this is not trivial. Generic PD support would partially solve the issue for Keystone, but also needs to handle multiple clocks for keystone. Yeah. I was also wondering on what happened to that work which was active at some point of time. Another option is to fix the NetCP and QMSS/KNAV driver for now in v4.0-rc using explicit clock APIs so that we don't have to use 'clk_ignore_unused'. And then migrate all of the drivers to run time PM API later when proper framework is implemented along with K2G support. Does this make sense? Multiple clock node support work which was started needs to be revived. Direct clock isn't the way to go about it. Anyways, please submit these patches at your earliest opportunity. Sure. Regards, Santosh -- 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/2] ARM: dts: keystone: fix the clock node for mdio
On 8/3/15 11:22 AM, Murali Karicheri wrote: On 08/03/2015 02:11 PM, Murali Karicheri wrote: Currently the MDIO clock is pointing to clkpa instead of clkcpgmac. MDIO is part of the ethss and the clock should be clkcpgmac. Signed-off-by: Murali Karicheri m-kariche...@ti.com --- arch/arm/boot/dts/keystone.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/keystone.dtsi b/arch/arm/boot/dts/keystone.dtsi index e7a6f6d..6245a17 100644 --- a/arch/arm/boot/dts/keystone.dtsi +++ b/arch/arm/boot/dts/keystone.dtsi @@ -273,7 +273,7 @@ #size-cells = 0; reg= 0x02090300 0x100; status = disabled; -clocks = clkpa; +clocks = clkcpgmac; clock-names = fck; bus_freq= 250; }; Santosh, This is a big fix and needs to go in v4.2-rc. So please review and apply asap. v4.2 is the first release that has netcp driver fully functional and I want to fix as many known bugs as possible. Do you have more fixes ? If yes, please post them so that I can include them along with these two. I will try to send them up next week. Thanks !! Regards, Santosh -- 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/2] mfd: s2mps11: Add manual shutdown method for Odroid XU3
Hi Krzysztof,
On 3 August 2015 at 18:07, Krzysztof Kozlowski k.kozlowsk...@gmail.com wrote:
On Odroid XU3 board (with S2MPS11 PMIC) the PWRHOLD bit in CTRL1
register must be manually set to 0 before initiating power off sequence.
One of usual power down methods for Exynos based devices looks like:
1. PWRHOLD pin of PMIC is connected to PSHOLD of Exynos.
2. Exynos holds up this pin during system operation.
3. ACOKB pin of PMIC is pulled up to VBATT and optionally to pin in
other device.
4. When PWRHOLD/PSHOLD goes low, the PMIC will turn off the power if
ACOKB goes high.
On Odroid XU3 family the difference is in (3) - the ACOKB is grounded.
This means that PMIC must manually set PWRHOLD field to low and then
wait for signal from Application Processor (the usual change in
PWRHOLD/PSHOLD pin will actually cut off the power).
The patch adds respective binding allowing Odroid XU3 device to be
powered off.
Signed-off-by: Krzysztof Kozlowski k.kozlowsk...@gmail.com
Reported-by: Anand Moon linux.am...@gmail.com
---
Patch is losely based on patch in Hardkernel repository [0] and previous
work of Anand Moon [1].
[0]
https://github.com/hardkernel/linux/commit/6897e62ba328bd1c8c095d918101863250cd73e7
[1] http://www.spinics.net/lists/linux-samsung-soc/msg45959.html
---
Documentation/devicetree/bindings/mfd/s2mps11.txt | 4 +++
drivers/mfd/sec-core.c| 31
+++
include/linux/mfd/samsung/core.h | 2 ++
include/linux/mfd/samsung/s2mps11.h | 1 +
4 files changed, 38 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/s2mps11.txt
b/Documentation/devicetree/bindings/mfd/s2mps11.txt
index 57a045016fca..90eaef393325 100644
--- a/Documentation/devicetree/bindings/mfd/s2mps11.txt
+++ b/Documentation/devicetree/bindings/mfd/s2mps11.txt
@@ -15,6 +15,10 @@ Optional properties:
- interrupt-parent: Specifies the phandle of the interrupt controller to
which
the interrupts from s2mps11 are delivered to.
- interrupts: Interrupt specifiers for interrupt sources.
+- samsung,s2mps11-acokb-ground: Indicates that ACOKB pin of S2MPS11 PMIC is
+ connected to the ground so the PMIC must manually set PWRHOLD bit in CTRL1
+ register to turn off the power. Usually the ACOKB is pulled up to VBATT so
+ when PWRHOLD pin goes low, the rising ACOKB will trigger power off.
Optional nodes:
- clocks: s2mps11, s2mps13 and s5m8767 provide three(AP/CP/BT) buffered
32.768
diff --git a/drivers/mfd/sec-core.c b/drivers/mfd/sec-core.c
index d206a3e8fe87..a56ab2102a32 100644
--- a/drivers/mfd/sec-core.c
+++ b/drivers/mfd/sec-core.c
@@ -278,6 +278,8 @@ static struct sec_platform_data
*sec_pmic_i2c_parse_dt_pdata(
* not parsed here.
*/
+ pd-manual_poweroff = of_property_read_bool(dev-of_node,
+
samsung,s2mps11-acokb-ground);
return pd;
}
#else
@@ -440,6 +442,34 @@ static int sec_pmic_remove(struct i2c_client *i2c)
return 0;
}
+static void sec_pmic_shutdown(struct i2c_client *i2c)
+{
+ struct sec_pmic_dev *sec_pmic = i2c_get_clientdata(i2c);
+ unsigned int reg, mask;
+
+ if (!sec_pmic-pdata-manual_poweroff)
+ return;
+
+ switch (sec_pmic-device_type) {
+ case S2MPS11X:
+ reg = S2MPS11_REG_CTRL1;
+ mask = S2MPS11_CTRL1_PWRHOLD_MASK;
+ break;
+ default:
+ /*
+* Currently only one board with S2MPS11 needs this, so just
+* ignore the rest.
+*/
+ dev_warn(sec_pmic-dev,
+ Unsupported device %lu for manual power off\n,
+ sec_pmic-device_type);
+ return;
+ }
+
+ regmap_update_bits(sec_pmic-regmap_pmic, reg, mask, 0);
+}
+
+
#ifdef CONFIG_PM_SLEEP
static int sec_pmic_suspend(struct device *dev)
{
@@ -491,6 +521,7 @@ static struct i2c_driver sec_pmic_driver = {
},
.probe = sec_pmic_probe,
.remove = sec_pmic_remove,
+ .shutdown = sec_pmic_shutdown,
.id_table = sec_pmic_id,
};
diff --git a/include/linux/mfd/samsung/core.h
b/include/linux/mfd/samsung/core.h
index 75115384f3fc..aa78957e092f 100644
--- a/include/linux/mfd/samsung/core.h
+++ b/include/linux/mfd/samsung/core.h
@@ -132,6 +132,8 @@ struct sec_platform_data {
int buck2_init;
int buck3_init;
int buck4_init;
+ /* Whether or not manually set PWRHOLD to low during shutdown. */
+ boolmanual_poweroff;
};
/**
diff --git a/include/linux/mfd/samsung/s2mps11.h
b/include/linux/mfd/samsung/s2mps11.h
index 7981a9d77d3f..b288965e8101 100644
---
