* Re: [PATCH] i2c: core: helper function to detect slave mode
From: Andy Shevchenko @ 2017-01-06 21:32 UTC (permalink / raw)
To: Luis Oliveira
Cc: Wolfram Sang, Rob Herring, Mark Rutland, Jarkko Nikula,
Andy Shevchenko, Mika Westerberg,
linux-i2c-u79uwXL29TY76Z2rM5mHXA, devicetree,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Ramiro.Oliveira-HKixBCOQz3hWk0Htik3J/w, Joao Pinto,
CARLOS.PALMINHA-HKixBCOQz3hWk0Htik3J/w
In-Reply-To: <c73ee9ab-64a1-0419-314d-21d4575ca7bf-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
On Fri, Jan 6, 2017 at 7:46 PM, Luis Oliveira
<Luis.Oliveira-HKixBCOQz3hWk0Htik3J/w@public.gmane.org> wrote:
> On 06-Jan-17 17:17, Andy Shevchenko wrote:
>> On Fri, Jan 6, 2017 at 7:15 PM, Luis Oliveira
>> <Luis.Oliveira-HKixBCOQz3hWk0Htik3J/w@public.gmane.org> wrote:
>>> On 06-Jan-17 16:29, Andy Shevchenko wrote:
>>>> On Thu, Jan 5, 2017 at 7:24 PM, Luis Oliveira
>>
>>>> Please, add kernel doc description here, important thing is to explain
>>>> return codes in Return: section of it.
>>>>
>>>>> +int i2c_slave_mode_detect(struct device *dev)
>>
>> Just to make sure you didn't miss this one.
>>
>>
> Yes, I saw it. You were talking of something like this, right?
>
> /**
> * i2c_slave_mode_detect - detect operation mode
> * @dev: The device owning the bus
> *
> * This checks the device nodes for a I2C slave by checking the address
a -> an
> * used.
> *
> * Returns true if a I2C slave is detected, otherwise returns false.
It has int type and I would reword this accordingly.
Something like
* Return:
* 1 when an I2C slave is detected, 0 for I2C master mode,
* and negative error otherwise.
> */
--
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v5 5/5] arm64: dts: exynos: Add tm2 touchkey node
From: Chanwoo Choi @ 2017-01-06 21:31 UTC (permalink / raw)
To: Andi Shyti
Cc: Dmitry Torokhov, Rob Herring, Mark Rutland, Catalin Marinas,
Will Deacon, Kukjin Kim, Krzysztof Kozlowski,
Javier Martinez Canillas, Chanwoo Choi, Beomho Seo,
linux-arm-kernel, linux-input, devicetree, linux-kernel,
linux-samsung-soc, Jaechul Lee, Andi Shyti, Jaechul Lee
In-Reply-To: <20170106134350.32428-6-andi.shyti@samsung.com>
Hi,
2017-01-06 22:43 GMT+09:00 Andi Shyti <andi.shyti@samsung.com>:
> From: Jaechul Lee <jcsing.lee@samsung.com>
>
> Add DT node support for TM2 touchkey device.
>
> Signed-off-by: Beomho Seo <beomho.seo@samsung.com>
> Signed-off-by: Jaechul Lee <jcsing.lee@samsung.com>
> Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
> Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
> ---
> arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> index 2449266b268f..92fcc4ec8319 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> @@ -18,6 +18,19 @@
> compatible = "samsung,tm2", "samsung,exynos5433";
> };
>
> +&hsi2c_9 {
> + status = "okay";
> +
> + touchkey@20 {
> + compatible = "samsung,tm2-touchkey";
> + reg = <0x20>;
> + interrupt-parent = <&gpa3>;
> + interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
> + vcc-supply = <&ldo32_reg>;
> + vdd-supply = <&ldo33_reg>;
> + };
> +};
> +
> &ldo31_reg {
> regulator-name = "TSP_VDD_1.85V_AP";
> regulator-min-microvolt = <1850000>;
Looks good to me.
Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
--
Best Regards,
Chanwoo Choi
^ permalink raw reply
* Re: [PATCH v5 2/5] arm64: dts: exynos: make tm2 and tm2e independent from each other
From: Chanwoo Choi @ 2017-01-06 21:26 UTC (permalink / raw)
To: Andi Shyti
Cc: Dmitry Torokhov, Rob Herring, Mark Rutland, Catalin Marinas,
Will Deacon, Kukjin Kim, Krzysztof Kozlowski,
Javier Martinez Canillas, Chanwoo Choi, Beomho Seo,
linux-arm-kernel, linux-input, devicetree, linux-kernel,
linux-samsung-soc, Jaechul Lee, Andi Shyti, Jaechul Lee
In-Reply-To: <20170106134350.32428-3-andi.shyti@samsung.com>
Hi Andi,
2017-01-06 22:43 GMT+09:00 Andi Shyti <andi.shyti@samsung.com>:
> Currently tm2e dts includes tm2 but there are some differences
> between the two boards and tm2 has some properties that tm2e
> doesn't have.
>
> That's why it's important to keep the two dts files independent
> and put all the commonalities in a tm2-common.dtsi file.
>
> At the current status the only two differences between the two
> dts files (besides the board name) are ldo31 and ldo38.
>
> Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
> Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
> ---
> ...ynos5433-tm2.dts => exynos5433-tm2-common.dtsi} | 21 +-
> arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 1150 +-------------------
> arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts | 2 +-
> 3 files changed, 42 insertions(+), 1131 deletions(-)
> copy arch/arm64/boot/dts/exynos/{exynos5433-tm2.dts => exynos5433-tm2-common.dtsi} (98%)
> rewrite arch/arm64/boot/dts/exynos/exynos5433-tm2.dts (98%)
Looks good to me.
Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
[snip]
--
Best Regards,
Chanwoo Choi
^ permalink raw reply
* Re: [PATCH v3 4/4] phy: qcom-qmp: new qmp phy driver for qcom-chipsets
From: Bjorn Andersson @ 2017-01-06 21:17 UTC (permalink / raw)
To: Vivek Gautam
Cc: robh+dt, kishon, sboyd, linux-kernel, devicetree, mark.rutland,
srinivas.kandagatla, linux-arm-msm
In-Reply-To: <e83564d4-d731-44dd-40d1-e36fa56f4920@codeaurora.org>
On Fri 06 Jan 01:47 PST 2017, Vivek Gautam wrote:
> > > +static int qcom_qmp_phy_com_init(struct qcom_qmp_phy *qphy)
> > > +{
> > > + const struct qmp_phy_cfg *cfg = qphy->cfg;
> > > + void __iomem *serdes = qphy->serdes;
> > > + int ret;
> > > +
> > > + mutex_lock(&qphy->phy_mutex);
> > > + if (qphy->init_count++) {
> > > + mutex_unlock(&qphy->phy_mutex);
> > > + return 0;
> > > + }
> > As far as I can see phy_init() and phy_exit() already keep reference
> > count on the initialization and you only call this function from
> > phy_ops->init, so you should be able to drop this.
> This is an intermediary function that does the common block initialization.
> PHYs like PCIe have a separate common block (apart from SerDes)
> for all phy channels. We shouldn't program this common block
> multiple times for each channel. That's why this init_count.
>
You're right!
Unfortunately it took me several minutes to wrap my head around the phy
vs multi-lane and I have a really hard time keeping "qcom_qmp_phy" and
"qmp_phy_desc" apart throughout the driver.
If I understand correctly the qcom_qmp_phy is the context representing a
"QMP block", while this is a PHY block it's not actually the phy in
Linux eyes. The qcom_phy_desc represents a "QMP lane", which in Linux
eyes is the phys, but as we think of QMP as the PHY this confused me.
How about naming them "struct qmp" and "struct qmp_lane" (or possibly
qmp_phy) instead? That way we remove the confusion of QMP PHY vs Linux
PHY and we make the lane part explicit.
Regards,
Bjorn
^ permalink raw reply
* [PATCH v3 2/2] backlight arcxcnn devicetree bindings for ArcticSand
From: Olimpiu Dejeu @ 2017-01-06 20:48 UTC (permalink / raw)
To: robh-DgEjT+Ai2ygdnm+yROfE0A
Cc: lee.jones-QSEj5FYQhm4dnm+yROfE0A,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
jingoohan1-Re5JQEeQqe8AvxtiuMwx3w, bdodge-eV7fy4qpoLhpLGFMi4vTTA,
Olimpiu Dejeu
backlight: Add devicetree bindings for the Arctic Sand backlight driver
This patch provides devicetree bindings for the Arctic Sand
driver submitted in the previous patch
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Signed-off-by: Olimpiu Dejeu <olimpiu-eV7fy4qpoLhpLGFMi4vTTA@public.gmane.org>
---
v2 => v3:
- Version updated to match other patch in set. No other changes.
v1 => v2:
- Version updated to match other patch in set. No other changes.
.../bindings/leds/backlight/arcxcnn_bl.txt | 31 ++++++++++++++++++++++
1 file changed, 31 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
diff --git a/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt b/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
new file mode 100644
index 0000000..a7b6ff2
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
@@ -0,0 +1,33 @@
+Binding for ArcticSand arc2c0608 LED driver
+
+Required properties:
+- compatible: should be "arc,arc2c0608"
+- reg: slave address
+
+Optional properties:
+- default-brightness: brightness value on boot, value from: 0-4095
+- label: The name of the backlight device
+ See Documentation/devicetree/bindings/leds/common.txt
+- led-sources: List of enabled channels from 0 to 5.
+ See Documentation/devicetree/bindings/leds/common.txt
+
+- arc,led-config-0: setting for register ILED_CONFIG_0
+- arc,led-config-1: setting for register ILED_CONFIG_1
+- arc,dim-freq: PWM mode frequence setting (bits [3:0] used)
+- arc,comp-config: setting for register CONFIG_COMP
+- arc,filter-config: setting for register FILTER_CONFIG
+- arc,trim-config: setting for register IMAXTUNE
+
+Note: Optional properties not specified will default to values in IC EPROM
+
+Example:
+
+arc2c0608@30 {
+ compatible = "arc,arc2c0608";
+ reg = <0x30>;
+ default-brightness = <500>;
+ label = "lcd-backlight";
+ linux,default-trigger = "backlight";
+ led-sources = <0 1 2 5>;
+};
+
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v3 1/2] backlight arcxcnn add support for ArcticSand devices
From: Olimpiu Dejeu @ 2017-01-06 20:48 UTC (permalink / raw)
To: robh-DgEjT+Ai2ygdnm+yROfE0A
Cc: lee.jones-QSEj5FYQhm4dnm+yROfE0A,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
jingoohan1-Re5JQEeQqe8AvxtiuMwx3w, bdodge-eV7fy4qpoLhpLGFMi4vTTA,
Olimpiu Dejeu
backlight: Add support for Arctic Sand LED backlight driver chips
This driver provides support for the Arctic Sand arc2c0608 chip,
and provides a framework to support future devices.
Signed-off-by: Olimpiu Dejeu <olimpiu-eV7fy4qpoLhpLGFMi4vTTA@public.gmane.org>
---
v2 => v3:
- Renamed variables to comply with conventions on naming
- Corrected device name in arcxcnn.h
v1 => v2:
- Removed "magic numbers" to initialize registers
- Cleaned up device tree bindings
- Fixed code style to address comments and pass "checkpatch"
- Removed unneeded debug and testing code
drivers/video/backlight/Kconfig | 7 +
drivers/video/backlight/Makefile | 1 +
drivers/video/backlight/arcxcnn_bl.c | 458 +++++++++++++++++++++++++++++++++++
include/linux/i2c/arcxcnn.h | 51 ++++
4 files changed, 517 insertions(+)
create mode 100644 drivers/video/backlight/arcxcnn_bl.c
create mode 100644 include/linux/i2c/arcxcnn.h
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index 5ffa4b4..4e1d2ad 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -460,6 +460,13 @@ config BACKLIGHT_BD6107
help
If you have a Rohm BD6107 say Y to enable the backlight driver.
+config BACKLIGHT_ARCXCNN
+ tristate "Backlight driver for the Arctic Sands ARCxCnnnn family"
+ depends on I2C
+ help
+ If you have an ARCxCnnnn family backlight say Y to enable
+ the backlight driver.
+
endif # BACKLIGHT_CLASS_DEVICE
endif # BACKLIGHT_LCD_SUPPORT
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index 16ec534..8905129 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -55,3 +55,4 @@ obj-$(CONFIG_BACKLIGHT_SKY81452) += sky81452-backlight.o
obj-$(CONFIG_BACKLIGHT_TOSA) += tosa_bl.o
obj-$(CONFIG_BACKLIGHT_TPS65217) += tps65217_bl.o
obj-$(CONFIG_BACKLIGHT_WM831X) += wm831x_bl.o
+obj-$(CONFIG_BACKLIGHT_ARCXCNN) += arcxcnn_bl.o
diff --git a/drivers/video/backlight/arcxcnn_bl.c b/drivers/video/backlight/arcxcnn_bl.c
new file mode 100644
index 0000000..fcebbd6
--- /dev/null
+++ b/drivers/video/backlight/arcxcnn_bl.c
@@ -0,0 +1,458 @@
+/*
+ * Backlight driver for ArcticSand ARC_X_C_0N_0N Devices
+ *
+ * Copyright 2016 ArcticSand, Inc.
+ * Author : Brian Dodge <bdodge-eV7fy4qpoLhpLGFMi4vTTA@public.gmane.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.
+ *
+ * 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/backlight.h>
+#include <linux/err.h>
+#include <linux/i2c.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/slab.h>
+
+#include "linux/i2c/arcxcnn.h"
+
+#define ARCXCNN_CMD 0x00 /* Command Register */
+#define ARCXCNN_CMD_STDBY 0x80 /* I2C Standby */
+#define ARCXCNN_CMD_RESET 0x40 /* Reset */
+#define ARCXCNN_CMD_BOOST 0x10 /* Boost */
+#define ARCXCNN_CMD_OVP_MASK 0x0C /* --- Over Voltage Threshold */
+#define ARCXCNN_CMD_OVP_XXV 0x0C /* <rsvrd> Over Voltage Threshold */
+#define ARCXCNN_CMD_OVP_20V 0x08 /* 20v Over Voltage Threshold */
+#define ARCXCNN_CMD_OVP_24V 0x04 /* 24v Over Voltage Threshold */
+#define ARCXCNN_CMD_OVP_31V 0x00 /* 31.4v Over Voltage Threshold */
+#define ARCXCNN_CMD_EXT_COMP 0x01 /* part (0) or full (1) ext. comp */
+
+#define ARCXCNN_CONFIG 0x01 /* Configuration */
+#define ARCXCNN_STATUS1 0x02 /* Status 1 */
+#define ARCXCNN_STATUS2 0x03 /* Status 2 */
+#define ARCXCNN_FADECTRL 0x04 /* Fading Control */
+#define ARCXCNN_ILED_CONFIG 0x05 /* ILED Configuration */
+#define ARCXCNN_ILED_DIM_PWM 0x00 /* config dim mode pwm */
+#define ARCXCNN_ILED_DIM_INT 0x04 /* config dim mode internal */
+#define ARCXCNN_LEDEN 0x06 /* LED Enable Register */
+#define ARCXCNN_LEDEN_ISETEXT 0x80 /* Full-scale current set extern */
+#define ARCXCNN_LEDEN_MASK 0x3F /* LED string enables mask */
+#define ARCXCNN_LEDEN_BITS 0x06 /* Bits of LED string enables */
+#define ARCXCNN_LEDEN_LED1 0x01
+#define ARCXCNN_LEDEN_LED2 0x02
+#define ARCXCNN_LEDEN_LED3 0x04
+#define ARCXCNN_LEDEN_LED4 0x08
+#define ARCXCNN_LEDEN_LED5 0x10
+#define ARCXCNN_LEDEN_LED6 0x20
+
+#define ARCXCNN_WLED_ISET_LSB 0x07 /* LED ISET LSB (in upper nibble) */
+#define ARCXCNN_WLED_ISET_LSB_SHIFT 0x04 /* ISET LSB Left Shift */
+#define ARCXCNN_WLED_ISET_MSB 0x08 /* LED ISET MSB (8 bits) */
+
+#define ARCXCNN_DIMFREQ 0x09
+#define ARCXCNN_COMP_CONFIG 0x0A
+#define ARCXCNN_FILT_CONFIG 0x0B
+#define ARCXCNN_IMAXTUNE 0x0C
+#define ARCXCNN_ID_MSB 0x1E
+#define ARCXCNN_ID_LSB 0x1F
+
+#define MAX_BRIGHTNESS 4095
+
+static int no_reset_on_remove;
+module_param_named(noreset, no_reset_on_remove, int, 0644);
+MODULE_PARM_DESC(noreset, "No reset on module removal");
+
+static int ibright = 60;
+module_param_named(ibright, ibright, int, 0644);
+MODULE_PARM_DESC(ibright, "Initial brightness (when no plat data)");
+
+static int ileden = ARCXCNN_LEDEN_MASK;
+module_param_named(ileden, ileden, int, 0644);
+MODULE_PARM_DESC(ileden, "Initial LED String Enables (when no plat data)");
+
+struct arcxcnn {
+ char chipname[64];
+ struct i2c_client *client;
+ struct backlight_device *bl;
+ struct device *dev;
+ struct arcxcnn_platform_data *pdata;
+};
+
+static int arcxcnn_update_bit(struct arcxcnn *lp, u8 reg, u8 mask, u8 data)
+{
+ int ret;
+ u8 tmp;
+
+ ret = i2c_smbus_read_byte_data(lp->client, reg);
+ if (ret < 0) {
+ dev_err(lp->dev, "failed to read 0x%.2x\n", reg);
+ return ret;
+ }
+
+ tmp = (u8)ret;
+ tmp &= ~mask;
+ tmp |= data & mask;
+
+ return i2c_smbus_write_byte_data(lp->client, reg, tmp);
+}
+
+static int arcxcnn_set_brightness(struct arcxcnn *lp, u32 brightness)
+{
+ int ret;
+ u8 val;
+
+ /* lower nibble of brightness goes in upper nibble of LSB register */
+ val = (brightness & 0xF) << ARCXCNN_WLED_ISET_LSB_SHIFT;
+ ret = i2c_smbus_write_byte_data(lp->client, ARCXCNN_WLED_ISET_LSB, val);
+ if (ret < 0)
+ return ret;
+
+ /* remaining 8 bits of brightness go in MSB register */
+ val = (brightness >> 4);
+ ret = i2c_smbus_write_byte_data(lp->client, ARCXCNN_WLED_ISET_MSB, val);
+
+ return ret;
+}
+
+static int arcxcnn_bl_update_status(struct backlight_device *bl)
+{
+ struct arcxcnn *lp = bl_get_data(bl);
+ u32 brightness = bl->props.brightness;
+
+ if (bl->props.state & (BL_CORE_SUSPENDED | BL_CORE_FBBLANK))
+ brightness = 0;
+
+ arcxcnn_set_brightness(lp, brightness);
+
+ /* set power-on/off/save modes */
+ if (bl->props.power == 0)
+ /* take out of standby */
+ arcxcnn_update_bit(lp, ARCXCNN_CMD, ARCXCNN_CMD_STDBY, 0);
+ else
+ /* place in low-power standby mode */
+ arcxcnn_update_bit(lp, ARCXCNN_CMD,
+ ARCXCNN_CMD_STDBY, ARCXCNN_CMD_STDBY);
+ return 0;
+}
+
+static const struct backlight_ops arcxcnn_bl_ops = {
+ .options = BL_CORE_SUSPENDRESUME,
+ .update_status = arcxcnn_bl_update_status,
+};
+
+static int arcxcnn_backlight_register(struct arcxcnn *lp)
+{
+ struct backlight_properties *props;
+ const char *name = lp->pdata->name ? : "arctic_bl";
+
+ props = devm_kzalloc(lp->dev, sizeof(*props), GFP_KERNEL);
+ if (!props)
+ return -ENOMEM;
+
+ memset(props, 0, sizeof(props));
+ props->type = BACKLIGHT_PLATFORM;
+ props->max_brightness = MAX_BRIGHTNESS;
+
+ if (lp->pdata->initial_brightness > props->max_brightness)
+ lp->pdata->initial_brightness = props->max_brightness;
+
+ props->brightness = lp->pdata->initial_brightness;
+
+ lp->bl = devm_backlight_device_register(lp->dev, name, lp->dev, lp,
+ &arcxcnn_bl_ops, props);
+
+ if (IS_ERR(lp->bl))
+ return PTR_ERR(lp->bl);
+
+ return 0;
+}
+
+static ssize_t arcxcnn_chip_id_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct arcxcnn *lp = dev_get_drvdata(dev);
+
+ return scnprintf(buf, PAGE_SIZE, "%s\n", lp->chipname);
+}
+
+static ssize_t arcxcnn_leden_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct arcxcnn *lp = dev_get_drvdata(dev);
+
+ return scnprintf(buf, PAGE_SIZE, "%02X\n", lp->pdata->leden);
+}
+
+static ssize_t arcxcnn_leden_store(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t len)
+{
+ struct arcxcnn *lp = dev_get_drvdata(dev);
+ unsigned long leden;
+
+ if (kstrtoul(buf, 0, &leden))
+ return 0;
+
+ if (leden != lp->pdata->leden) {
+ /* don't allow 0 for leden, use power to turn all off */
+ if (leden == 0)
+ return -EINVAL;
+ lp->pdata->leden = leden & ARCXCNN_LEDEN_MASK;
+ arcxcnn_update_bit(lp, ARCXCNN_LEDEN,
+ ARCXCNN_LEDEN_MASK, lp->pdata->leden);
+ }
+
+ return len;
+}
+
+static DEVICE_ATTR(chip_id, 0444, arcxcnn_chip_id_show, NULL);
+static DEVICE_ATTR(leden, 0664, arcxcnn_leden_show, arcxcnn_leden_store);
+
+static struct attribute *arcxcnn_attributes[] = {
+ &dev_attr_chip_id.attr,
+ &dev_attr_leden.attr,
+ NULL,
+};
+
+static const struct attribute_group arcxcnn_attr_group = {
+ .attrs = arcxcnn_attributes,
+};
+
+static void arcxcnn_parse_dt(struct arcxcnn *lp)
+{
+ struct device *dev = lp->dev;
+ struct device_node *node = dev->of_node;
+ u32 prog_val, num_entry, entry, sources[ARCXCNN_LEDEN_BITS];
+ int ret;
+
+ /* device tree entry isn't required, defaults are OK */
+ if (!node)
+ return;
+
+ ret = of_property_read_string(node, "label", &lp->pdata->name);
+ if (ret < 0)
+ lp->pdata->name = NULL;
+
+ ret = of_property_read_u32(node, "default-brightness", &prog_val);
+ if (ret == 0)
+ lp->pdata->initial_brightness = prog_val;
+
+ ret = of_property_read_u32(node, "arc,led-config-0", &prog_val);
+ if (ret == 0)
+ lp->pdata->led_config_0 = (u8)prog_val;
+
+ ret = of_property_read_u32(node, "arc,led-config-1", &prog_val);
+ if (ret == 0)
+ lp->pdata->led_config_1 = (u8)prog_val;
+
+ ret = of_property_read_u32(node, "arc,dim-freq", &prog_val);
+ if (ret == 0)
+ lp->pdata->dim_freq = (u8)prog_val;
+
+ ret = of_property_read_u32(node, "arc,comp-config", &prog_val);
+ if (ret == 0)
+ lp->pdata->comp_config = (u8)prog_val;
+
+ ret = of_property_read_u32(node, "arc,filter-config", &prog_val);
+ if (ret == 0)
+ lp->pdata->filter_config = (u8)prog_val;
+
+ ret = of_property_read_u32(node, "arc,trim-config", &prog_val);
+ if (ret == 0)
+ lp->pdata->trim_config = (u8)prog_val;
+
+ ret = of_property_count_u32_elems(node, "led-sources");
+ if (ret < 0) {
+ lp->pdata->leden = ARCXCNN_LEDEN_MASK; /* all on is default */
+ } else {
+ num_entry = ret;
+ if (num_entry > ARCXCNN_LEDEN_BITS)
+ num_entry = ARCXCNN_LEDEN_BITS;
+
+ ret = of_property_read_u32_array(node, "led-sources", sources,
+ num_entry);
+ if (ret < 0) {
+ dev_err(dev, "led-sources node is invalid.\n");
+ } else {
+ u8 onbit;
+
+ lp->pdata->leden = 0;
+
+ /* for each enable in source, set bit in led enable */
+ for (entry = 0; entry < num_entry; entry++) {
+ onbit = 1 << sources[entry];
+ lp->pdata->leden |= onbit;
+ }
+ }
+ }
+}
+
+static int arcxcnn_probe(struct i2c_client *cl, const struct i2c_device_id *id)
+{
+ struct arcxcnn *lp;
+ int ret;
+ u8 regval;
+ u16 chipid;
+
+ if (!i2c_check_functionality(cl->adapter, I2C_FUNC_SMBUS_BYTE_DATA))
+ return -EIO;
+
+ lp = devm_kzalloc(&cl->dev, sizeof(*lp), GFP_KERNEL);
+ if (!lp)
+ return -ENOMEM;
+
+ lp->client = cl;
+ lp->dev = &cl->dev;
+ lp->pdata = dev_get_platdata(&cl->dev);
+
+ /* reset the device */
+ i2c_smbus_write_byte_data(lp->client,
+ ARCXCNN_CMD, ARCXCNN_CMD_RESET);
+
+ /* read device ID */
+ regval = i2c_smbus_read_byte_data(lp->client, ARCXCNN_ID_MSB);
+ chipid = regval;
+ chipid <<= 8;
+
+ regval = i2c_smbus_read_byte_data(lp->client, ARCXCNN_ID_LSB);
+ chipid |= regval;
+
+ snprintf(lp->chipname, sizeof(lp->chipname),
+ "%s-%04X", id->name, chipid);
+
+ if (!lp->pdata) {
+ lp->pdata = devm_kzalloc(lp->dev,
+ sizeof(*lp->pdata), GFP_KERNEL);
+ if (!lp->pdata)
+ return -ENOMEM;
+
+ /* Setup defaults based on power-on defaults */
+ lp->pdata->name = NULL;
+ lp->pdata->initial_brightness = ibright;
+ lp->pdata->leden = ileden;
+
+ lp->pdata->led_config_0 = i2c_smbus_read_byte_data(
+ lp->client, ARCXCNN_FADECTRL);
+
+ lp->pdata->led_config_1 = i2c_smbus_read_byte_data(
+ lp->client, ARCXCNN_ILED_CONFIG);
+ /* insure dim mode is not default pwm */
+ lp->pdata->led_config_1 |= ARCXCNN_ILED_DIM_INT;
+
+ lp->pdata->dim_freq = i2c_smbus_read_byte_data(
+ lp->client, ARCXCNN_DIMFREQ);
+
+ lp->pdata->comp_config = i2c_smbus_read_byte_data(
+ lp->client, ARCXCNN_COMP_CONFIG);
+
+ lp->pdata->filter_config = i2c_smbus_read_byte_data(
+ lp->client, ARCXCNN_FILT_CONFIG);
+
+ lp->pdata->trim_config = i2c_smbus_read_byte_data(
+ lp->client, ARCXCNN_IMAXTUNE);
+
+ if (IS_ENABLED(CONFIG_OF))
+ arcxcnn_parse_dt(lp);
+ }
+
+ i2c_set_clientdata(cl, lp);
+
+ /* constrain settings to what is possible */
+ if (lp->pdata->initial_brightness > MAX_BRIGHTNESS)
+ lp->pdata->initial_brightness = MAX_BRIGHTNESS;
+
+ /* set initial brightness */
+ arcxcnn_set_brightness(lp, lp->pdata->initial_brightness);
+
+ /* set other register values directly */
+ i2c_smbus_write_byte_data(lp->client, ARCXCNN_FADECTRL,
+ lp->pdata->led_config_0);
+ i2c_smbus_write_byte_data(lp->client, ARCXCNN_ILED_CONFIG,
+ lp->pdata->led_config_1);
+ i2c_smbus_write_byte_data(lp->client, ARCXCNN_DIMFREQ,
+ lp->pdata->dim_freq);
+ i2c_smbus_write_byte_data(lp->client, ARCXCNN_COMP_CONFIG,
+ lp->pdata->comp_config);
+ i2c_smbus_write_byte_data(lp->client, ARCXCNN_FILT_CONFIG,
+ lp->pdata->filter_config);
+ i2c_smbus_write_byte_data(lp->client, ARCXCNN_IMAXTUNE,
+ lp->pdata->trim_config);
+
+ /* set initial LED Enables */
+ arcxcnn_update_bit(lp, ARCXCNN_LEDEN,
+ ARCXCNN_LEDEN_MASK, lp->pdata->leden);
+
+ ret = arcxcnn_backlight_register(lp);
+ if (ret) {
+ dev_err(lp->dev,
+ "failed to register backlight. err: %d\n", ret);
+ return ret;
+ }
+
+ ret = sysfs_create_group(&lp->dev->kobj, &arcxcnn_attr_group);
+ if (ret) {
+ dev_err(lp->dev, "failed to register sysfs. err: %d\n", ret);
+ return ret;
+ }
+
+ backlight_update_status(lp->bl);
+
+ return 0;
+}
+
+static int arcxcnn_remove(struct i2c_client *cl)
+{
+ struct arcxcnn *lp = i2c_get_clientdata(cl);
+
+ if (!no_reset_on_remove) {
+ /* disable all strings */
+ i2c_smbus_write_byte_data(lp->client,
+ ARCXCNN_LEDEN, 0x00);
+ /* reset the device */
+ i2c_smbus_write_byte_data(lp->client,
+ ARCXCNN_CMD, ARCXCNN_CMD_RESET);
+ }
+ lp->bl->props.brightness = 0;
+
+ backlight_update_status(lp->bl);
+
+ sysfs_remove_group(&lp->dev->kobj, &arcxcnn_attr_group);
+
+ return 0;
+}
+
+static const struct of_device_id arcxcnn_dt_ids[] = {
+ { .compatible = "arc,arc2c0608" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, arcxcnn_dt_ids);
+
+static const struct i2c_device_id arcxcnn_ids[] = {
+ {"arc2c0608", ARC2C0608},
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, arcxcnn_ids);
+
+static struct i2c_driver arcxcnn_driver = {
+ .driver = {
+ .name = "arcxcnn_bl",
+ .of_match_table = of_match_ptr(arcxcnn_dt_ids),
+ },
+ .probe = arcxcnn_probe,
+ .remove = arcxcnn_remove,
+ .id_table = arcxcnn_ids,
+};
+module_i2c_driver(arcxcnn_driver);
+
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Brian Dodge <bdodge-eV7fy4qpoLhpLGFMi4vTTA@public.gmane.org>");
+MODULE_DESCRIPTION("ARCXCNN Backlight driver");
diff --git a/include/linux/i2c/arcxcnn.h b/include/linux/i2c/arcxcnn.h
new file mode 100644
index 0000000..e378d63
--- /dev/null
+++ b/include/linux/i2c/arcxcnn.h
@@ -0,0 +1,51 @@
+/*
+ * Backlight driver for ArcticSand ARCXCNN Devices
+ *
+ * Copyright 2016 ArcticSand, Inc.
+ * Author : Brian Dodge <bdodge-eV7fy4qpoLhpLGFMi4vTTA@public.gmane.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.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef _ARCXCNN_H
+#define _ARCXCNN_H
+
+enum arcxcnn_chip_id {
+ ARC2C0608
+};
+
+/**
+ * struct arcxcnn_platform_data
+ * @name : Backlight driver name (NULL will use default)
+ * @initial_brightness : initial value of backlight brightness
+ * @leden : initial LED string enables, upper bit is global on/off
+ * @led_config_0 : fading speed (period between intensity steps)
+ * @led_config_1 : misc settings, see datasheet
+ * @dim_freq : pwm dimming frequency if in pwm mode
+ * @comp_config : misc config, see datasheet
+ * @filter_config : RC/PWM filter config, see datasheet
+ * @trim_config : full scale current trim, see datasheet
+ */
+struct arcxcnn_platform_data {
+ const char *name;
+ u16 initial_brightness;
+ u8 leden;
+ u8 led_config_0;
+ u8 led_config_1;
+ u8 dim_freq;
+ u8 comp_config;
+ u8 filter_config;
+ u8 trim_config;
+};
+
+#endif
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH 6/9] dt/bindings: Add a serial/UART attached device binding
From: Rob Herring @ 2017-01-06 20:41 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Greg Kroah-Hartman, Marcel Holtmann, Jiri Slaby,
Sebastian Reichel, Dr . H . Nikolaus Schaller, Peter Hurley,
Andy Shevchenko, Alan Cox, Loic Poulain, Pavel Machek, NeilBrown,
Linus Walleij, open list:BLUETOOTH DRIVERS,
linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <3363597.IVJfReRkL0@wuerfel>
On Fri, Jan 6, 2017 at 1:21 PM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> On Friday, January 6, 2017 10:26:32 AM CET Rob Herring wrote:
>> +Optional Properties:
>> +
>> +- reg : A single cell representing the port/line number of the
>> + host UART. Only used if the host UART is a single node
>> + with multiple ports.
>> +
>
> If there is a 'reg' property in the child, I guess we should also
> document a #address-cells/#size-cells value for the parent.
>
> Can you give an example of a multi-port serial device we support?
A 16550 DUART chip. Not sure if we have any bindings for one though.
Maybe the chip would be the parent node containing 2 child ns16550
nodes.
> I was expecting that we already need a device node per port anyway,
> to make the console work.
Yes, good point. I think I'll just drop it for now.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 6/9] dt/bindings: Add a serial/UART attached device binding
From: Arnd Bergmann @ 2017-01-06 19:21 UTC (permalink / raw)
To: Rob Herring
Cc: Greg Kroah-Hartman, Marcel Holtmann, Jiri Slaby,
Sebastian Reichel, Dr . H . Nikolaus Schaller, Peter Hurley,
Andy Shevchenko, Alan Cox, Loic Poulain, Pavel Machek, NeilBrown,
Linus Walleij, linux-bluetooth, linux-serial, linux-kernel,
Mark Rutland, devicetree
In-Reply-To: <20170106162635.19677-7-robh@kernel.org>
On Friday, January 6, 2017 10:26:32 AM CET Rob Herring wrote:
> +Optional Properties:
> +
> +- reg : A single cell representing the port/line number of the
> + host UART. Only used if the host UART is a single node
> + with multiple ports.
> +
If there is a 'reg' property in the child, I guess we should also
document a #address-cells/#size-cells value for the parent.
Can you give an example of a multi-port serial device we support?
I was expecting that we already need a device node per port anyway,
to make the console work.
Arnd
^ permalink raw reply
* Re: [PATCH 0/5] Use mmio-sram driver for Keystone MSMC RAM
From: Santosh Shilimkar @ 2017-01-06 19:13 UTC (permalink / raw)
To: Suman Anna
Cc: devicetree, linux-kernel, Vitaly Andrianov, Russell King,
Tero Kristo, Rob Herring, Murali Karicheri, Santosh Shilimkar,
linux-arm-kernel
In-Reply-To: <b49bfb08-292f-ee26-b385-fdba304571b0@ti.com>
On 1/6/2017 11:10 AM, Suman Anna wrote:
> Hi Santosh,
>
>>> OK. Its good to add the code at least with one active user of it.
>>> Since this has to anyway wait for another merge window, please post the
>>> users of it so that I can pull the combined patchset.
>>>
>> Are you going to post new patchset or you dropped this series ?
>>
>> If you want me to include it for next merge window, please post
>> refreshed patchset.
>
> No, haven't dropped the series, will post it today. You prefer the
> series on -rc1 or -rc2, not that it makes a difference.
>
Right. rc1 is just fine.
Regards,
Sasntosh
^ permalink raw reply
* Re: Congratulation_stephen iiFH
From: stephen Hildebran @ 2017-01-06 19:12 UTC (permalink / raw)
To: David Lechner
Cc: Sekhar Nori, Kevin Hilman, Rob Herring, Mark Rutland, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <1483677228-2325-4-git-send-email-david@lechnology.com>
[-- Attachment #1: Type: text/plain, Size: 390 bytes --]
Leave me alone
Sent from my iPhone
> On Jan 5, 2017, at 11:33 PM, David Lechner <david@lechnology.com> wrote:
>
> zdg
> Congratulations_stephen,
>
>
> The_Home_Warranty_Limited_time_event.
>
>
> Never_pay_for_covered_home_repairs_again!
>
>
> Your_Roof_is_CoveredFREE!
>
>
> Click_ _Here
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ,.u 'n 5^ *u :b
> 0' p- .,t 't - o *u ' t
[-- Attachment #2: Type: text/html, Size: 1632 bytes --]
^ permalink raw reply
* Re: [PATCH 0/5] Use mmio-sram driver for Keystone MSMC RAM
From: Suman Anna @ 2017-01-06 19:10 UTC (permalink / raw)
To: santosh.shilimkar@oracle.com
Cc: devicetree, linux-kernel, Vitaly Andrianov, Russell King,
Tero Kristo, Rob Herring, Murali Karicheri, Santosh Shilimkar,
linux-arm-kernel
In-Reply-To: <3abc3c7d-2f45-f5dd-e6f5-c03008d22d56@oracle.com>
Hi Santosh,
>
> On 9/7/16 9:25 AM, Santosh Shilimkar wrote:
>> On 9/7/2016 9:22 AM, Suman Anna wrote:
>>> Hi Santosh,
>>>
>>> On 09/07/2016 11:11 AM, Santosh Shilimkar wrote:
>>>> Hi Suman,
>>>>
>>>> On 9/1/2016 3:58 PM, Suman Anna wrote:
>>>>> Hi,
>>>>>
>>>>> The Keystone 2 family of SoCs have an on-chip RAM called the
>>>>> Multicore Shared Memory (MSM) RAM. This RAM is accessible through
>>>>> the Multicore Shared Memory Controller (MSMC). This series represents
>>>>> these on-chip RAMs as sram nodes so that the memory allocations
>>>>> can be managed by the in-kernel mmio-sram driver.
>>>>>
>>>>> The first 4 patches adds the basic SRAM nodes on each of the SoCs,
>>>>> and the last patch enables the generic on-chip SRAM driver for
>>>>> keystone defconfig.
>>>>>
>>>> The series looks good in general but I would like to understand
>>>> the users of this memory in kernel. Is that going to be posted
>>>> as a follow up patch ? Is the Power controller going to make
>>>> use of this SRAM for PM code ?
>>>
>>> Yes, the users will eventually follow. Power Controller code is not
>>> gonna be using this SRAM, it has its own RAM. This memory is gonna be
>>> split between various functional features like IPC, OPTEE integration,
>>> we already have the Boot Monitor code using this. We will have the
>>> memory split by either having static child nodes or drivers requesting
>>> the memory using gen_pool API.
>>>
>> OK. Its good to add the code at least with one active user of it.
>> Since this has to anyway wait for another merge window, please post the
>> users of it so that I can pull the combined patchset.
>>
> Are you going to post new patchset or you dropped this series ?
>
> If you want me to include it for next merge window, please post
> refreshed patchset.
No, haven't dropped the series, will post it today. You prefer the
series on -rc1 or -rc2, not that it makes a difference.
regards
Suman
^ permalink raw reply
* Re: [PATCH v2 15/19] media: imx: Add MIPI CSI-2 Receiver subdev driver
From: Steve Longerbeam @ 2017-01-06 18:58 UTC (permalink / raw)
To: Vladimir Zapolskiy, shawnguo, kernel, fabio.estevam, robh+dt,
mark.rutland, linux, mchehab, gregkh, p.zabel
Cc: devel, devicetree, Steve Longerbeam, linux-kernel,
linux-arm-kernel, linux-media
In-Reply-To: <ecfcd8e5-01bd-b9a4-8653-7bbbdece4231@mentor.com>
On 01/04/2017 07:05 AM, Vladimir Zapolskiy wrote:
> On 01/03/2017 10:57 PM, Steve Longerbeam wrote:
>> Adds MIPI CSI-2 Receiver subdev driver. This subdev is required
>> for sensors with a MIPI CSI2 interface.
>>
>> Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
>> ---
>> drivers/staging/media/imx/Makefile | 1 +
>> drivers/staging/media/imx/imx-mipi-csi2.c | 509 ++++++++++++++++++++++++++++++
>> 2 files changed, 510 insertions(+)
>> create mode 100644 drivers/staging/media/imx/imx-mipi-csi2.c
>>
>> diff --git a/drivers/staging/media/imx/Makefile b/drivers/staging/media/imx/Makefile
>> index fe9e992..0decef7 100644
>> --- a/drivers/staging/media/imx/Makefile
>> +++ b/drivers/staging/media/imx/Makefile
>> @@ -9,3 +9,4 @@ obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx-ic.o
>> obj-$(CONFIG_VIDEO_IMX_CAMERA) += imx-csi.o
>> obj-$(CONFIG_VIDEO_IMX_CAMERA) += imx-smfc.o
>> obj-$(CONFIG_VIDEO_IMX_CAMERA) += imx-camif.o
>> +obj-$(CONFIG_VIDEO_IMX_CAMERA) += imx-mipi-csi2.o
>> diff --git a/drivers/staging/media/imx/imx-mipi-csi2.c b/drivers/staging/media/imx/imx-mipi-csi2.c
>> new file mode 100644
>> index 0000000..84df16e
>> --- /dev/null
>> +++ b/drivers/staging/media/imx/imx-mipi-csi2.c
>> @@ -0,0 +1,509 @@
>> +/*
>> + * MIPI CSI-2 Receiver Subdev for Freescale i.MX5/6 SOC.
>> + *
>> + * Copyright (c) 2012-2014 Mentor Graphics Inc.
>> + *
>> + * 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.
>> + */
>> +#include <linux/module.h>
>> +#include <linux/export.h>
>> +#include <linux/types.h>
>> +#include <linux/init.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/err.h>
>> +#include <linux/delay.h>
>> +#include <linux/interrupt.h>
>> +#include <linux/io.h>
>> +#include <linux/clk.h>
>> +#include <linux/list.h>
>> +#include <linux/irq.h>
>> +#include <linux/of_device.h>
>> +#include <media/v4l2-device.h>
>> +#include <media/v4l2-of.h>
>> +#include <media/v4l2-subdev.h>
>> +#include <media/v4l2-async.h>
> Please sort the list of headers alphabetically.
done.
>
>> +#include <asm/mach/irq.h>
> Why do you need to include this header?
good question. In fact this include list was in need of a lot of pruning,
so I paired it down to the essentials.
>> +static int imxcsi2_s_stream(struct v4l2_subdev *sd, int enable)
>> +{
>> + struct imxcsi2_dev *csi2 = sd_to_dev(sd);
>> + int i, ret = 0;
>> +
>> + if (!csi2->src_sd)
>> + return -EPIPE;
>> + for (i = 0; i < CSI2_NUM_SRC_PADS; i++) {
>> + if (csi2->sink_sd[i])
>> + break;
>> + }
>> + if (i >= CSI2_NUM_SRC_PADS)
>> + return -EPIPE;
>> +
>> + v4l2_info(sd, "stream %s\n", enable ? "ON" : "OFF");
>> +
>> + if (enable && !csi2->stream_on) {
>> + clk_prepare_enable(csi2->pix_clk);
> It can complicate the design for you, but in general clk_prepare_enable()
> can return an error.
I added an error check and reorganized a little.
>> +
>> +static int imxcsi2_parse_endpoints(struct imxcsi2_dev *csi2)
>> +{
>> + struct device_node *node = csi2->dev->of_node;
>> + struct device_node *epnode;
>> + struct v4l2_of_endpoint ep;
>> + int ret = 0;
>> +
>> + epnode = of_graph_get_next_endpoint(node, NULL);
>> + if (!epnode) {
>> + v4l2_err(&csi2->sd, "failed to get endpoint node\n");
>> + return -EINVAL;
>> + }
>> +
>> + v4l2_of_parse_endpoint(epnode, &ep);
> Do of_node_put(epnode) here and remove 'out' goto label.
done.
>> +static const struct of_device_id imxcsi2_dt_ids[] = {
>> + { .compatible = "fsl,imx-mipi-csi2", },
>> + { /* sentinel */ }
>> +};
>> +MODULE_DEVICE_TABLE(of, imxcsi2_dt_ids);
>> +
>> +static struct platform_driver imxcsi2_driver = {
>> + .driver = {
>> + .name = DEVICE_NAME,
>> + .owner = THIS_MODULE,
> Please drop .owner assignment.
done.
Steve
^ permalink raw reply
* Re: [PATCH 0/5] Use mmio-sram driver for Keystone MSMC RAM
From: santosh.shilimkar @ 2017-01-06 18:56 UTC (permalink / raw)
To: Suman Anna
Cc: devicetree, linux-kernel, Vitaly Andrianov, Russell King,
Tero Kristo, Rob Herring, Murali Karicheri, Santosh Shilimkar,
linux-arm-kernel
In-Reply-To: <287b7e1d-1453-2832-515d-e7e51373a3bc@oracle.com>
Hi Suman,
On 9/7/16 9:25 AM, Santosh Shilimkar wrote:
> On 9/7/2016 9:22 AM, Suman Anna wrote:
>> Hi Santosh,
>>
>> On 09/07/2016 11:11 AM, Santosh Shilimkar wrote:
>>> Hi Suman,
>>>
>>> On 9/1/2016 3:58 PM, Suman Anna wrote:
>>>> Hi,
>>>>
>>>> The Keystone 2 family of SoCs have an on-chip RAM called the
>>>> Multicore Shared Memory (MSM) RAM. This RAM is accessible through
>>>> the Multicore Shared Memory Controller (MSMC). This series represents
>>>> these on-chip RAMs as sram nodes so that the memory allocations
>>>> can be managed by the in-kernel mmio-sram driver.
>>>>
>>>> The first 4 patches adds the basic SRAM nodes on each of the SoCs,
>>>> and the last patch enables the generic on-chip SRAM driver for
>>>> keystone defconfig.
>>>>
>>> The series looks good in general but I would like to understand
>>> the users of this memory in kernel. Is that going to be posted
>>> as a follow up patch ? Is the Power controller going to make
>>> use of this SRAM for PM code ?
>>
>> Yes, the users will eventually follow. Power Controller code is not
>> gonna be using this SRAM, it has its own RAM. This memory is gonna be
>> split between various functional features like IPC, OPTEE integration,
>> we already have the Boot Monitor code using this. We will have the
>> memory split by either having static child nodes or drivers requesting
>> the memory using gen_pool API.
>>
> OK. Its good to add the code at least with one active user of it.
> Since this has to anyway wait for another merge window, please post the
> users of it so that I can pull the combined patchset.
>
Are you going to post new patchset or you dropped this series ?
If you want me to include it for next merge window, please post
refreshed patchset.
Regards,
Santosh
^ permalink raw reply
* Re: [PATCH v4 2/5] mfd: lm3533: Support initialization from Device Tree
From: Bjorn Andersson @ 2017-01-06 18:54 UTC (permalink / raw)
To: Lee Jones
Cc: Rob Herring, Mark Rutland, Jonathan Cameron, Hartmut Knaack,
Lars-Peter Clausen, Peter Meerwald-Stadler, Richard Purdie,
Jacek Anaszewski, Pavel Machek, Jingoo Han, devicetree,
linux-kernel, linux-iio, linux-leds, Bjorn Andersson
In-Reply-To: <20170106095349.GE9851@dell>
On Fri 06 Jan 01:53 PST 2017, Lee Jones wrote:
> On Thu, 05 Jan 2017, Bjorn Andersson wrote:
>
> > On Wed 04 Jan 23:49 PST 2017, Lee Jones wrote:
> >
> > > On Wed, 04 Jan 2017, Bjorn Andersson wrote:
> > >
> > > > On Wed 04 Jan 03:54 PST 2017, Lee Jones wrote:
> > > >
> > > > > On Mon, 26 Dec 2016, Bjorn Andersson wrote:
> > > > >
> > > > > > From: Bjorn Andersson <bjorn.andersson@sonymobile.com>
> > > > > >
> > > > > > Implement support for initialization of the lm3533 driver core and
> > > > > > probing child devices from Device Tree.
> > > > > >
> > > >
> > > > [..]
> > > >
> > > > > > @@ -512,6 +514,11 @@ static int lm3533_device_init(struct lm3533 *lm3533)
> > > > > > lm3533_device_bl_init(lm3533);
> > > > > > lm3533_device_led_init(lm3533);
> > > > > >
> > > > > > + if (lm3533->dev->of_node) {
> > > > > > + of_platform_populate(lm3533->dev->of_node, NULL, NULL,
> > > > > > + lm3533->dev);
> > > > > > + }
> > > > >
> > > > > I think it's save to call of_platform_populate(), even if !of_node.
> > > > > It will just fail and return an error code, which you are ignoring
> > > > > anyway.
> > > > >
> > > >
> > > > I thought so too, but that's apparently how you trigger probing children
> > > > of the root node. So we're stuck with a conditional.
> > >
> > > Ah, so this is to protect against the case where DT is present, but a
> > > node for this device is not (or is disabled), so is left unprobed.
> > > Then the bind is initiated via I2C? Or something else?
> > >
> >
> > In the event that a new lm3533 is spawned from sysfs we would not have
> > platform_data when entering lm3533_device_init() and just bail early.
> >
> > Therefor, this issue would be limited to the odd case of lm3533 being
> > initiated from code (e.g. a board file) on a DT enabled system. In which
> > case it will create and probe new devices from the root of the DT.
>
> Eewww, do we really want to support that?
>
As long as we support non-DT probing of the driver this is a possible
scenario. And with modern ARM being DT-centric I think that if anyone
uses this driver with a modern version of the Linux kernel it's likely
that they would have this kind of hybrid solution.
So, although ugly, I think we should keep this conditional and hope that
anyone using the driver will transition to use the DT binding.
Regards,
Bjorn
^ permalink raw reply
* Re: [PATCH 1/6] ARM: dts: am335x-phycore-som: Update NAND partition table
From: Tony Lindgren @ 2017-01-06 18:43 UTC (permalink / raw)
To: Brian Norris
Cc: Adam Ford, Teresa Remmet, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA, Brian Norris, Rob Herring,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Benoît Cousson,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20170106182052.GA127120-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
* Brian Norris <briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> [170106 10:21]:
> On Fri, Jan 06, 2017 at 08:14:22AM -0800, Tony Lindgren wrote:
> > * Adam Ford <aford173-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> [170106 08:06]:
> > > On Fri, Jan 6, 2017 at 10:02 AM, Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> wrote:
> > > > * Teresa Remmet <t.remmet-guT5V/WYfQezQB+pC5nmwQ@public.gmane.org> [170106 01:28]:
> > > >> Am Donnerstag, den 05.01.2017, 09:56 -0800 schrieb Brian Norris:
> > > >> > On Thu, Jan 05, 2017 at 09:18:45AM -0800, Tony Lindgren wrote:
> > > >> > > I'm suggesting we leave the kernel nodes empty and let u-boot
> > > >> > > populate them, so maybe you guys can discuss this on the related
> > > >> > > lists.
> > > >> > That's an option. I've worked with platforms that did something like
> > > >> > this, and that's really one of the only ways you can handle putting
> > > >> > partition information in the device tree. You're really hamstringing
> > > >> > yourself when you put all the partition information in the device
> > > >> > tree.
> > > >> > And it's just dumb once that gets codified in the kernel source tree.
> > > >> >
> > > >>
> > > >> In our case the bootloader does pass the partition table to the kernel.
> > > >> So it gets overwritten anyway. This was just more for backup,
> > > >> if someone uses a different bootloader. But I'm fine with removing the
> > > >> nand partition table completely from the kernel device tree.
> > > >> Same with the SPI nor partition table.
>
> Ah, well if these are essentially just a backup, then why do they need
> changed at all? To be more precise about my "dumb" statement: it seems
> unwise to assume that all systems using a particular board will have the
> same partition layout. So *relying* on the in-kernel DTS(I) files to
> have a universal partition layout would likely cause problems.
>
> I don't have much problem with keeping a sample layout there as a
> backup, if you find it useful. But it seems like it will be hard to
> argue that you can ever change it in the future.
>
> Anyway, the ofpart mechanism is there, and it's fine to use it, but it's
> up to you to understand the implications and manage the backwards
> compatibility problems :)
>
> > > >> I will send patches for this.
> > > >
> > > > OK thanks! Also thank you Brian for your comments.
> > > >
> > >
> > > Tony - I tested leaving the partition info as-is with the updates from
> > > the bootloader and it works. Would you prefer that I match Brian and
> > > remove the partition table completely, or should I just leave my board
> > > alone?
> > >
> > > I am good either way.
> >
> > OK. How about let's remove the partitions from kernel for v4.11 as
> > clean-up then for cases where the bootloader might change them?
>
> I don't have much stake in this but...if there were any systems using
> the backup layout (i.e., the in-kernel partition layout), wouldn't that
> break them? Is there a problem with just leaving them alone?
Yeah I guess it depends on the device and it's bootloader versions.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 14/19] media: imx: Add Camera Interface subdev driver
From: Steve Longerbeam @ 2017-01-06 18:42 UTC (permalink / raw)
To: Vladimir Zapolskiy, shawnguo, kernel, fabio.estevam, robh+dt,
mark.rutland, linux, mchehab, gregkh, p.zabel
Cc: devel, devicetree, Steve Longerbeam, linux-kernel,
linux-arm-kernel, linux-media
In-Reply-To: <4a893d70-f34a-9fb1-401f-bcb954e3a2cb@mentor.com>
On 01/04/2017 06:55 AM, Vladimir Zapolskiy wrote:
> On 01/03/2017 10:57 PM, Steve Longerbeam wrote:
>>
>> diff --git a/drivers/staging/media/imx/Makefile b/drivers/staging/media/imx/Makefile
>> index d2a962c..fe9e992 100644
>> --- a/drivers/staging/media/imx/Makefile
>> +++ b/drivers/staging/media/imx/Makefile
>> @@ -8,4 +8,4 @@ obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx-ic.o
>>
>> obj-$(CONFIG_VIDEO_IMX_CAMERA) += imx-csi.o
>> obj-$(CONFIG_VIDEO_IMX_CAMERA) += imx-smfc.o
>> -
>> +obj-$(CONFIG_VIDEO_IMX_CAMERA) += imx-camif.o
> obj-$(CONFIG_VIDEO_IMX_CAMERA) += imx-camif.o imx-csi.o imx-smfc.o
>
> as an option.
I prefer to keep on separate lines as explained earlier.
>
>> diff --git a/drivers/staging/media/imx/imx-camif.c b/drivers/staging/media/imx/imx-camif.c
>> new file mode 100644
>> index 0000000..3cf167e
>> --- /dev/null
>> +++ b/drivers/staging/media/imx/imx-camif.c
>> @@ -0,0 +1,1010 @@
>> +/*
>> + * Video Camera Capture Subdev for Freescale i.MX5/6 SOC
>> + *
>> + * Copyright (c) 2012-2016 Mentor Graphics Inc.
>> + *
>> + * 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.
>> + */
>> +#include <linux/module.h>
>> +#include <linux/delay.h>
>> +#include <linux/fs.h>
>> +#include <linux/timer.h>
>> +#include <linux/sched.h>
>> +#include <linux/slab.h>
>> +#include <linux/spinlock.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/pinctrl/consumer.h>
>> +#include <linux/of_platform.h>
>> +#include <media/v4l2-device.h>
>> +#include <media/v4l2-ioctl.h>
>> +#include <media/videobuf2-dma-contig.h>
>> +#include <media/v4l2-subdev.h>
>> +#include <media/v4l2-of.h>
>> +#include <media/v4l2-ctrls.h>
>> +#include <media/v4l2-event.h>
> Please sort the list of headers alphabetically.
done.
>> +#include <video/imx-ipu-v3.h>
>> +#include <media/imx.h>
>> +#include "imx-media.h"
>> +
>> +#define DEVICE_NAME "imx-media-camif"
> I would propose to drop this macro.
done.
>> +
>> +#define CAMIF_DQ_TIMEOUT 5000
> Add a comment about time unit?
actually that was ancient and no longer used, removed.
>
>> +
>> +struct camif_priv;
>> +
> This is a leftover apparently.
ditto, removed.
>> +
>> + ret = v4l2_async_register_subdev(&priv->sd);
>> + if (ret)
>> + goto free_ctrls;
>> +
>> + return 0;
>> +free_ctrls:
>> + v4l2_ctrl_handler_free(&priv->ctrl_hdlr);
>> + return ret;
> A shorter version:
>
> if (ret)
> v4l2_ctrl_handler_free(&priv->ctrl_hdlr);
>
> return ret;
done.
>> +
>> +static struct platform_driver imx_camif_driver = {
>> + .probe = camif_probe,
>> + .remove = camif_remove,
>> + .driver = {
>> + .name = DEVICE_NAME,
>> + .owner = THIS_MODULE,
> Please drop the owner assignment.
done.
Steve
^ permalink raw reply
* Re: [PATCH v2 13/19] media: imx: Add IC subdev drivers
From: Steve Longerbeam @ 2017-01-06 18:34 UTC (permalink / raw)
To: Vladimir Zapolskiy, shawnguo-DgEjT+Ai2ygdnm+yROfE0A,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ, fabio.estevam-3arQi8VN3Tc,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, mchehab-DgEjT+Ai2ygdnm+yROfE0A,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-media-u79uwXL29TY76Z2rM5mHXA,
devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b, Steve Longerbeam
In-Reply-To: <96684048-c5ad-3e64-0fbc-61dcaf184519-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
On 01/04/2017 06:48 AM, Vladimir Zapolskiy wrote:
> On 01/03/2017 10:57 PM, Steve Longerbeam wrote:
>
>> +
>> + ret = ic_ops[priv->task_id]->init(priv);
>> + if (ret)
>> + return ret;
>> +
>> + ret = v4l2_async_register_subdev(&priv->sd);
>> + if (ret)
>> + goto remove;
>> +
>> + return 0;
>> +remove:
>> + ic_ops[priv->task_id]->remove(priv);
>> + return ret;
> if (ret)
> ic_ops[priv->task_id]->remove(priv);
>
> return ret;
>
> as an alternative.
done.
>
>
> +
> +static struct platform_driver imx_ic_driver = {
> + .probe = imx_ic_probe,
> + .remove = imx_ic_remove,
> + .id_table = imx_ic_ids,
> + .driver = {
> + .name = "imx-ipuv3-ic",
> + .owner = THIS_MODULE,
> Please drop .owner assignment.
done.
>> diff --git a/drivers/staging/media/imx/imx-ic-pp.c b/drivers/staging/media/imx/imx-ic-pp.c
>> new file mode 100644
>> index 0000000..5ef0581
>> --- /dev/null
>> +++ b/drivers/staging/media/imx/imx-ic-pp.c
>> @@ -0,0 +1,636 @@
>> +/*
>> + * V4L2 IC Post-Processor Subdev for Freescale i.MX5/6 SOC
>> + *
>> + * Copyright (c) 2014-2016 Mentor Graphics Inc.
>> + *
>> + * 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.
>> + */
>> +#include <linux/module.h>
>> +#include <linux/delay.h>
>> +#include <linux/fs.h>
>> +#include <linux/timer.h>
>> +#include <linux/sched.h>
>> +#include <linux/slab.h>
>> +#include <linux/interrupt.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/pinctrl/consumer.h>
>> +#include <media/v4l2-device.h>
>> +#include <media/v4l2-ioctl.h>
>> +#include <media/videobuf2-dma-contig.h>
>> +#include <media/v4l2-subdev.h>
>> +#include <media/v4l2-of.h>
>> +#include <media/v4l2-ctrls.h>
> Please sort the list of headers alphabetically.
done.
>
>>
>> +
>> + priv->out_run = kzalloc(IMX_MEDIA_MAX_RING_BUFS *
>> + sizeof(*priv->out_run), GFP_KERNEL);
>> + if (!priv->out_run) {
>> + v4l2_err(&ic_priv->sd, "failed to alloc src ring runs\n");
> In OOM situation the core will report it, probably you can drop the message.
with a backtrace? I can't remember, if not I'd like to keep this.
>> diff --git a/drivers/staging/media/imx/imx-ic-prpenc.c b/drivers/staging/media/imx/imx-ic-prpenc.c
>> new file mode 100644
>> index 0000000..e17216b
>> --- /dev/null
>> +++ b/drivers/staging/media/imx/imx-ic-prpenc.c
>> @@ -0,0 +1,1037 @@
>> +/*
>> + * V4L2 Capture IC Encoder Subdev for Freescale i.MX5/6 SOC
>> + *
>> + * This subdevice handles capture of video frames from the CSI, which
>> + * are routed directly to the Image Converter preprocess encode task,
>> + * for resizing, colorspace conversion, and rotation.
>> + *
>> + * Copyright (c) 2012-2016 Mentor Graphics Inc.
>> + *
>> + * 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.
>> + */
>> +#include <linux/module.h>
>> +#include <linux/delay.h>
>> +#include <linux/fs.h>
>> +#include <linux/timer.h>
>> +#include <linux/sched.h>
>> +#include <linux/slab.h>
>> +#include <linux/interrupt.h>
>> +#include <linux/spinlock.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/pinctrl/consumer.h>
>> +#include <media/v4l2-device.h>
>> +#include <media/v4l2-ioctl.h>
>> +#include <media/videobuf2-dma-contig.h>
>> +#include <media/v4l2-subdev.h>
>> +#include <media/v4l2-of.h>
>> +#include <media/v4l2-ctrls.h>
> Please sort the list of headers alphabetically.
done.
>
>> +static irqreturn_t prpenc_eof_interrupt(int irq, void *dev_id)
>> +{
>> + struct prpenc_priv *priv = dev_id;
>> + struct imx_media_dma_buf *done, *next;
>> + struct ipuv3_channel *channel;
>> + unsigned long flags;
>> +
>> + spin_lock_irqsave(&priv->irqlock, flags);
> Here spin_lock(&priv->irqlock) should be sufficient.
done.
>> +
>> + ret = media_entity_pads_init(&sd->entity, PRPENC_NUM_PADS, priv->pad);
>> + if (ret)
>> + goto free_ctrls;
>> +
>> + return 0;
>> +free_ctrls:
>> + v4l2_ctrl_handler_free(&priv->ctrl_hdlr);
>> + return ret;
> if (ret)
> v4l2_ctrl_handler_free(&priv->ctrl_hdlr);
>
> return ret;
>
> version is shorter.
done.
>
> diff --git a/drivers/staging/media/imx/imx-ic-prpvf.c
> b/drivers/staging/media/imx/imx-ic-prpvf.c
>> new file mode 100644
>> index 0000000..53ce006
>> --- /dev/null
>> +++ b/drivers/staging/media/imx/imx-ic-prpvf.c
>> @@ -0,0 +1,1180 @@
>> +/*
>> + * V4L2 IC Deinterlacer Subdev for Freescale i.MX5/6 SOC
>> + *
>> + * Copyright (c) 2014-2016 Mentor Graphics Inc.
>> + *
>> + * 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.
>> + */
>> +#include <linux/module.h>
>> +#include <linux/delay.h>
>> +#include <linux/fs.h>
>> +#include <linux/timer.h>
>> +#include <linux/sched.h>
>> +#include <linux/slab.h>
>> +#include <linux/interrupt.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/pinctrl/consumer.h>
>> +#include <media/v4l2-device.h>
>> +#include <media/v4l2-ioctl.h>
>> +#include <media/videobuf2-dma-contig.h>
>> +#include <media/v4l2-subdev.h>
>> +#include <media/v4l2-of.h>
>> +#include <media/v4l2-ctrls.h>
> Please sort the list of headers alphabetically.
done.
>
>> +/* prpvf_out_ch EOF interrupt (progressive frame ready) */
>> +static irqreturn_t prpvf_out_eof_interrupt(int irq, void *dev_id)
>> +{
>> + struct prpvf_priv *priv = dev_id;
>> + struct imx_media_dma_buf *done;
>> + unsigned long flags;
>> +
>> + spin_lock_irqsave(&priv->irqlock, flags);
>
> Here spin_lock(&priv->irqlock) should be sufficient.
done.
>
>> diff --git a/drivers/staging/media/imx/imx-ic.h b/drivers/staging/media/imx/imx-ic.h
>> new file mode 100644
>> index 0000000..9aed5f5
>> --- /dev/null
>> +++ b/drivers/staging/media/imx/imx-ic.h
>> @@ -0,0 +1,36 @@
>> +/*
>> + * V4L2 Image Converter Subdev for Freescale i.MX5/6 SOC
>> + *
>> + * Copyright (c) 2016 Mentor Graphics Inc.
>> + *
>> + * 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.
>> + */
>> +#ifndef _IMX_IC_H
>> +#define _IMX_IC_H
>> +
> Please add header files or declarations of all used structs.
done (it only needs v4l2-subdev.h).
Steve
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/2] phy: rockchip-emmc: try to get drive impedance from DT
From: Doug Anderson @ 2017-01-06 18:29 UTC (permalink / raw)
To: Shawn Lin
Cc: Kishon Vijay Abraham I, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
open list:ARM/Rockchip SoC..., Heiko Stuebner,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <669c85b1-f0fb-c58e-90a8-3aeac3118656-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Hi,
On Thu, Jan 5, 2017 at 5:09 PM, Shawn Lin <shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org> wrote:
> On 2017/1/6 8:51, Doug Anderson wrote:
>>
>> Hi,
>>
>> On Thu, Jan 5, 2017 at 1:31 AM, Shawn Lin <shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
>> wrote:
>>>
>>> Try to get drive impedance from DT and use it, otherwise
>>> use 50ohm by default in order not to break the existing boards
>>> as 50ohm works fine for them already.
>>>
>>> Signed-off-by: Shawn Lin <shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
>>> ---
>>>
>>> drivers/phy/phy-rockchip-emmc.c | 29 ++++++++++++++++++++++++++++-
>>> 1 file changed, 28 insertions(+), 1 deletion(-)
>>
>>
>> I could have sworn that you somehow needed to make sure that the eMMC
>> part itself needed to also be updated to be told the matching drive
>> impedance so you don't get a mismatch. How do you make that work?
>
>
> No I didn't. So that means the eMMC part itself still couldn't be
> updated. The intention for me to introduce this only for emmc phy is
> that I got report that the default drive impedance of one eMMC is not
> 50ohms, so now we haven't been able to update it for eMMC part but maybe
> we could just update it for the phy itself to match them in between.
Interesting. ...the eMMC spec says that 50 Ohm is mandatory, so we
know that 50 Ohm must be supported.
...and even if the default isn't 50 Ohm then wouldn't it get set to 50
OHm when we set the HS_TIMING ?
-Doug
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 2/2] cpufreq: brcmstb-cpufreq: CPUfreq driver for older Broadcom STB SoCs
From: Markus Mayer @ 2017-01-06 18:26 UTC (permalink / raw)
To: Viresh Kumar
Cc: Markus Mayer, Michael Turquette, Stephen Boyd, Rob Herring,
Mark Rutland, Rafael J . Wysocki, Arnd Bergmann,
Broadcom Kernel List, Linux Clock List, Power Management List,
Device Tree List, ARM Kernel List, Linux Kernel Mailing List
In-Reply-To: <20170106041442.GD21926@vireshk-i7>
On 5 January 2017 at 20:14, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 20-12-16, 14:55, Markus Mayer wrote:
>> From: Markus Mayer <mmayer@broadcom.com>
>>
>> This CPUfreq driver provides basic frequency scaling for older Broadcom
>> STB SoCs that do not use AVS firmware with DVFS support. There is no
>> support for voltage scaling.
>>
>> Signed-off-by: Markus Mayer <mmayer@broadcom.com>
>> ---
>> drivers/cpufreq/Kconfig.arm | 12 ++
>> drivers/cpufreq/Makefile | 1 +
>> drivers/cpufreq/brcmstb-cpufreq.c | 377 ++++++++++++++++++++++++++++++++++++++
>> 3 files changed, 390 insertions(+)
>> create mode 100644 drivers/cpufreq/brcmstb-cpufreq.c
>
> I am fine with this patch as I have already Acked V3 of it. But please fix the
> bindings improvement suggested by Stephen first.
Yes, that is on my list of things to do. I will send an update
hopefully next week.
Thanks,
-Markus
^ permalink raw reply
* Re: [PATCH 1/6] ARM: dts: am335x-phycore-som: Update NAND partition table
From: Brian Norris @ 2017-01-06 18:20 UTC (permalink / raw)
To: Tony Lindgren
Cc: Mark Rutland, devicetree, linux-omap, Rob Herring, linux-mtd,
Benoît Cousson, Teresa Remmet, Brian Norris, Adam Ford,
linux-arm-kernel
In-Reply-To: <20170106161421.GD2630@atomide.com>
On Fri, Jan 06, 2017 at 08:14:22AM -0800, Tony Lindgren wrote:
> * Adam Ford <aford173@gmail.com> [170106 08:06]:
> > On Fri, Jan 6, 2017 at 10:02 AM, Tony Lindgren <tony@atomide.com> wrote:
> > > * Teresa Remmet <t.remmet@phytec.de> [170106 01:28]:
> > >> Am Donnerstag, den 05.01.2017, 09:56 -0800 schrieb Brian Norris:
> > >> > On Thu, Jan 05, 2017 at 09:18:45AM -0800, Tony Lindgren wrote:
> > >> > > I'm suggesting we leave the kernel nodes empty and let u-boot
> > >> > > populate them, so maybe you guys can discuss this on the related
> > >> > > lists.
> > >> > That's an option. I've worked with platforms that did something like
> > >> > this, and that's really one of the only ways you can handle putting
> > >> > partition information in the device tree. You're really hamstringing
> > >> > yourself when you put all the partition information in the device
> > >> > tree.
> > >> > And it's just dumb once that gets codified in the kernel source tree.
> > >> >
> > >>
> > >> In our case the bootloader does pass the partition table to the kernel.
> > >> So it gets overwritten anyway. This was just more for backup,
> > >> if someone uses a different bootloader. But I'm fine with removing the
> > >> nand partition table completely from the kernel device tree.
> > >> Same with the SPI nor partition table.
Ah, well if these are essentially just a backup, then why do they need
changed at all? To be more precise about my "dumb" statement: it seems
unwise to assume that all systems using a particular board will have the
same partition layout. So *relying* on the in-kernel DTS(I) files to
have a universal partition layout would likely cause problems.
I don't have much problem with keeping a sample layout there as a
backup, if you find it useful. But it seems like it will be hard to
argue that you can ever change it in the future.
Anyway, the ofpart mechanism is there, and it's fine to use it, but it's
up to you to understand the implications and manage the backwards
compatibility problems :)
> > >> I will send patches for this.
> > >
> > > OK thanks! Also thank you Brian for your comments.
> > >
> >
> > Tony - I tested leaving the partition info as-is with the updates from
> > the bootloader and it works. Would you prefer that I match Brian and
> > remove the partition table completely, or should I just leave my board
> > alone?
> >
> > I am good either way.
>
> OK. How about let's remove the partitions from kernel for v4.11 as
> clean-up then for cases where the bootloader might change them?
I don't have much stake in this but...if there were any systems using
the backup layout (i.e., the in-kernel partition layout), wouldn't that
break them? Is there a problem with just leaving them alone?
Brian
^ permalink raw reply
* [PATCH v2] i2c: core: helper function to detect slave mode
From: Luis Oliveira @ 2017-01-06 18:14 UTC (permalink / raw)
To: wsa, robh+dt, mark.rutland, jarkko.nikula, andriy.shevchenko,
mika.westerberg, linux-i2c, devicetree, linux-kernel
Cc: Luis.Oliveira, Ramiro.Oliveira, Joao.Pinto, CARLOS.PALMINHA
This function has the purpose of mode detection by checking the
device nodes for a reg matching with the I2C_OWN_SLAVE_ADDREESS flag.
Currently only checks using OF functions (ACPI slave not supported yet).
Signed-off-by: Luis Oliveira <lolivei@synopsys.com>
Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
---
Changes V1->V2:
- Kernel doc added to i2c-core. (@Andy)
- Moved the definitions to the OF branch. (@Andy)
- Changed the return type from int to bool. (@Rob)
drivers/i2c/i2c-core.c | 28 ++++++++++++++++++++++++++++
include/linux/i2c.h | 1 +
2 files changed, 29 insertions(+)
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 3de95a29024c..937605e65976 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -3691,6 +3691,34 @@ int i2c_slave_unregister(struct i2c_client *client)
return ret;
}
EXPORT_SYMBOL_GPL(i2c_slave_unregister);
+
+/**
+ * i2c_slave_mode_detect - detect operation mode
+ * @dev: The device owning the bus
+ *
+ * This checks the device nodes for a I2C slave by checking the address
+ * used.
+ *
+ * Returns true if a I2C slave is detected, otherwise returns false.
+ */
+bool i2c_slave_mode_detect(struct device *dev)
+{
+ if (IS_BUILTIN(CONFIG_OF) && dev->of_node) {
+ struct device_node *child;
+ u32 reg;
+
+ for_each_child_of_node(dev->of_node, child) {
+ of_property_read_u32(child, "reg", ®);
+ if (reg & I2C_OWN_SLAVE_ADDRESS)
+ return true;
+ }
+ } else if (IS_BUILTIN(CONFIG_ACPI) && ACPI_HANDLE(dev)) {
+ dev_dbg(dev, "ACPI slave is not supported yet\n");
+ }
+ return false;
+}
+EXPORT_SYMBOL_GPL(i2c_slave_mode_detect);
+
#endif
MODULE_AUTHOR("Simon G. Vogl <simon@tk.uni-linz.ac.at>");
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index b2109c522dec..bfc3e0cee57e 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -282,6 +282,7 @@ enum i2c_slave_event {
extern int i2c_slave_register(struct i2c_client *client, i2c_slave_cb_t slave_cb);
extern int i2c_slave_unregister(struct i2c_client *client);
+extern bool i2c_slave_mode_detect(struct device *dev);
static inline int i2c_slave_event(struct i2c_client *client,
enum i2c_slave_event event, u8 *val)
--
2.11.0
^ permalink raw reply related
* Re: [PATCH v2 12/19] media: imx: Add SMFC subdev driver
From: Steve Longerbeam @ 2017-01-06 18:11 UTC (permalink / raw)
To: Vladimir Zapolskiy, shawnguo, kernel, fabio.estevam, robh+dt,
mark.rutland, linux, mchehab, gregkh, p.zabel
Cc: devel, devicetree, Steve Longerbeam, linux-kernel,
linux-arm-kernel, linux-media
In-Reply-To: <13ff9579-ce8e-9272-ee44-9b597631f6b5@mentor.com>
On 01/04/2017 06:23 AM, Vladimir Zapolskiy wrote:
> On 01/03/2017 10:57 PM, Steve Longerbeam wrote:
>> This is a media entity subdevice driver for the i.MX Sensor Multi-FIFO
>> Controller module. Video frames are received from the CSI and can
>> be routed to various sinks including the i.MX Image Converter for
>> scaling, color-space conversion, motion compensated deinterlacing,
>> and image rotation.
>>
>> Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
>> ---
>> drivers/staging/media/imx/Makefile | 1 +
>> drivers/staging/media/imx/imx-smfc.c | 739 +++++++++++++++++++++++++++++++++++
>> 2 files changed, 740 insertions(+)
>> create mode 100644 drivers/staging/media/imx/imx-smfc.c
>>
>> diff --git a/drivers/staging/media/imx/Makefile b/drivers/staging/media/imx/Makefile
>> index 133672a..3559d7b 100644
>> --- a/drivers/staging/media/imx/Makefile
>> +++ b/drivers/staging/media/imx/Makefile
>> @@ -5,4 +5,5 @@ obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx-media.o
>> obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx-media-common.o
>>
>> obj-$(CONFIG_VIDEO_IMX_CAMERA) += imx-csi.o
>> +obj-$(CONFIG_VIDEO_IMX_CAMERA) += imx-smfc.o
> May be
>
> obj-$(CONFIG_VIDEO_IMX_CAMERA) += imx-csi.o imx-smfc.o
I'd prefer to keep them on separate lines, to indicate they
are all built as separate modules.
>
>>
>> diff --git a/drivers/staging/media/imx/imx-smfc.c b/drivers/staging/media/imx/imx-smfc.c
>> new file mode 100644
>> index 0000000..565048c
>> --- /dev/null
>> +++ b/drivers/staging/media/imx/imx-smfc.c
>> @@ -0,0 +1,739 @@
>> +/*
>> + * V4L2 Capture SMFC Subdev for Freescale i.MX5/6 SOC
>> + *
>> + * This subdevice handles capture of raw/unconverted video frames
>> + * from the CSI, directly to memory via the Sensor Multi-FIFO Controller.
>> + *
>> + * Copyright (c) 2012-2016 Mentor Graphics Inc.
>> + *
>> + * 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.
>> + */
>> +#include <linux/module.h>
>> +#include <linux/delay.h>
>> +#include <linux/fs.h>
>> +#include <linux/timer.h>
>> +#include <linux/sched.h>
>> +#include <linux/slab.h>
>> +#include <linux/interrupt.h>
>> +#include <linux/spinlock.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/pinctrl/consumer.h>
>> +#include <media/v4l2-device.h>
>> +#include <media/v4l2-ioctl.h>
>> +#include <media/videobuf2-dma-contig.h>
>> +#include <media/v4l2-subdev.h>
>> +#include <media/v4l2-of.h>
>> +#include <media/v4l2-ctrls.h>
> Please sort the list of headers alphabetically.
done.
>
>> +static irqreturn_t imx_smfc_eof_interrupt(int irq, void *dev_id)
>> +{
>> + struct imx_smfc_priv *priv = dev_id;
>> + struct imx_media_dma_buf *done, *next;
>> + unsigned long flags;
>> +
>> + spin_lock_irqsave(&priv->irqlock, flags);
> spin_lock(&priv->irqlock) should be sufficient.
yes thanks.
>
>> +
>> +static const struct platform_device_id imx_smfc_ids[] = {
>> + { .name = "imx-ipuv3-smfc" },
>> + { },
>> +};
>> +MODULE_DEVICE_TABLE(platform, imx_smfc_ids);
>> +
>> +static struct platform_driver imx_smfc_driver = {
>> + .probe = imx_smfc_probe,
>> + .remove = imx_smfc_remove,
>> + .id_table = imx_smfc_ids,
>> + .driver = {
>> + .name = "imx-ipuv3-smfc",
>> + .owner = THIS_MODULE,
> You can drop owner assignment.
done.
Steve
^ permalink raw reply
* Re: [PATCH v2 11/19] media: imx: Add CSI subdev driver
From: Steve Longerbeam @ 2017-01-06 18:05 UTC (permalink / raw)
To: Vladimir Zapolskiy, shawnguo-DgEjT+Ai2ygdnm+yROfE0A,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ, fabio.estevam-3arQi8VN3Tc,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, mchehab-DgEjT+Ai2ygdnm+yROfE0A,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-media-u79uwXL29TY76Z2rM5mHXA,
devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b, Steve Longerbeam
In-Reply-To: <21b54a7b-1254-a14f-767c-c92feed7433d-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
On 01/04/2017 05:44 AM, Vladimir Zapolskiy wrote:
>
>> diff --git a/drivers/staging/media/imx/imx-csi.c b/drivers/staging/media/imx/imx-csi.c
>> new file mode 100644
>> index 0000000..975eafb
>> --- /dev/null
>> +++ b/drivers/staging/media/imx/imx-csi.c
>> @@ -0,0 +1,638 @@
>> +/*
>> + * V4L2 Capture CSI Subdev for Freescale i.MX5/6 SOC
>> + *
>> + * Copyright (c) 2014-2016 Mentor Graphics Inc.
>> + *
>> + * 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.
>> + */
>> +#include <linux/module.h>
>> +#include <linux/platform_device.h>
>> +#include <media/v4l2-device.h>
>> +#include <media/v4l2-subdev.h>
>> +#include <media/videobuf2-dma-contig.h>
>> +#include <media/v4l2-of.h>
>> +#include <media/v4l2-ctrls.h>
> Please add the headers alphabetically ordered.
done.
>> +
>> +static int csi_start(struct csi_priv *priv)
>> +{
>> + int ret;
>> +
>> + if (!priv->sensor) {
>> + v4l2_err(&priv->sd, "no sensor attached\n");
>> + return -EINVAL;
>> + }
>> +
>> + ret = csi_setup(priv);
>> + if (ret)
>> + return ret;
>> +
>> + /* start the frame interval monitor */
>> + ret = imx_media_fim_set_stream(priv->fim, priv->sensor, true);
>> + if (ret)
>> + return ret;
>> +
>> + ret = ipu_csi_enable(priv->csi);
>> + if (ret) {
>> + v4l2_err(&priv->sd, "CSI enable error: %d\n", ret);
>> + return ret;
>> + }
>> +
>> + return 0;
> if (ret)
> v4l2_err(&priv->sd, "CSI enable error: %d\n", ret);
>
> return ret;
I failed to cleanup in this path, so it is now:
ret = ipu_csi_enable(priv->csi);
if (ret) {
v4l2_err(&priv->sd, "CSI enable error: %d\n", ret);
goto fim_off;
}
return 0;
fim_off:
if (priv->fim)
imx_media_fim_set_stream(priv->fim, priv->sensor, false);
return ret;
>> +
>> +static int csi_link_setup(struct media_entity *entity,
>> + const struct media_pad *local,
>> + const struct media_pad *remote, u32 flags)
>> +{
>> + struct v4l2_subdev *sd = media_entity_to_v4l2_subdev(entity);
>> + struct csi_priv *priv = v4l2_get_subdevdata(sd);
>> + struct v4l2_subdev *remote_sd;
>> +
>> + dev_dbg(priv->dev, "link setup %s -> %s", remote->entity->name,
>> + local->entity->name);
>> +
>> + remote_sd = media_entity_to_v4l2_subdev(remote->entity);
>> +
>> + if (local->flags & MEDIA_PAD_FL_SINK) {
>> + if (flags & MEDIA_LNK_FL_ENABLED) {
>> + if (priv->src_sd)
>> + return -EBUSY;
>> + priv->src_sd = remote_sd;
>> + } else {
>> + priv->src_sd = NULL;
>> + return 0;
> You can remove the return above.
right, fixed.
>
>> +
>> + ret = v4l2_async_register_subdev(&priv->sd);
>> + if (ret)
>> + goto free_ctrls;
>> +
>> + return 0;
>> +free_ctrls:
>> + v4l2_ctrl_handler_free(&priv->ctrl_hdlr);
>> + return ret;
> This is a functionally equal and simplified version:
>
> if (ret)
> v4l2_ctrl_handler_free(&priv->ctrl_hdlr);
>
> return ret;
thanks, done.
>> +
>> +static struct platform_driver imx_csi_driver = {
>> + .probe = imx_csi_probe,
>> + .remove = imx_csi_remove,
>> + .id_table = imx_csi_ids,
>> + .driver = {
>> + .name = "imx-ipuv3-csi",
>> + .owner = THIS_MODULE,
> Please drop .owner.
ok, I tested this and there are no regressions, done
for all modules.
Steve
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 5/5] ARM: dts: Add LEGO MINDSTORMS EV3 dts
From: kbuild test robot @ 2017-01-06 18:04 UTC (permalink / raw)
Cc: kbuild-all-JC7UmRfGjtg, Sekhar Nori, David Lechner, Kevin Hilman,
Rob Herring, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1483677228-2325-6-git-send-email-david-nq/r/kbU++upp/zk7JDF2g@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1010 bytes --]
Hi David,
[auto build test ERROR on linus/master]
[also build test ERROR on v4.10-rc2 next-20170106]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/David-Lechner/Support-for-LEGO-MINDSTORMS-EV3/20170107-002649
config: arm-at91_dt_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All errors (new ones prefixed by >>):
>> Error: arch/arm/boot/dts/da850-lego-ev3.dts:378.1-6 Label or path usb1 not found
FATAL ERROR: Syntax error parsing input tree
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 22125 bytes --]
^ permalink raw reply
* Re: [PATCH 7/7] ARM: dts: NSP: Add SD/MMC support
From: Florian Fainelli @ 2017-01-06 17:48 UTC (permalink / raw)
To: bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w, Jon Mason,
Rob Herring
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1481652831-2744-8-git-send-email-jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
On Tue, 13 Dec 2016 13:13:51 -0500, Jon Mason <jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> wrote:
> Add SD/MMC support to the Broadcom NSP SVK and XMC.
>
> Signed-off-by: Jon Mason <jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> ---
Applied, thanks!
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox